=== jmarsden_ is now known as jmarsden [02:25] Is, or at what point is LTS → LTS upgrades scheduled to be available for testing (hardy→lucid)? [02:30] Now. [02:30] They may not work, but that just means it's worth filing bugs. [02:30] sooner the better [02:32] persia: Ok, then how would I do one? [02:33] Take an existing hardy install (or a new one). Apply all the updates. dist-upgrade. [02:40] persia: nice, just saw the -d flag for do-release-upgrade, cheers. === robbiew is now known as robbiew_ [04:47] Ooof. I'm surprised no one else seems to have noticed Tomboy crashing because of a liblaunchpad-integration-cil bug. [04:48] Maybe everyone has liblaunchpad-integration-dev installed. [05:02] ROAF: bug #518662 [05:02] Launchpad bug 518662 in tomboy "Unhandled Exception: System.DllNotFoundException: liblaunchpad-integration.so" [Undecided,New] https://launchpad.net/bugs/518662 [05:02] * RAOF shall play “merge the duplicates” [05:04] RAOF: https://bugs.launchpad.net/ubuntu/+source/tomboy/+bug/516210 might be the main one? [05:04] Ubuntu bug 516210 in ubuntuone-client "Can't start Tomboy on Lucid" [Undecided,Invalid] [05:05] Having HD issues... getting the following error messages: ata1: hard resetting link, sd 0:0:0:0: [sda] Unhandled error code, and lost page write due to I/O error on sda1 however when it does it sets /dev/sdb to read only [05:05] smartmon says its clean, and I am running the long test now... anyone else see this after the last round of upgrades [05:06] arand: No, it's not. That's a different problem. [05:06] RAOF: oh, ops. [05:07] arand: That one is about the notification-indicator patch, which I think has been disabled. The other one is about the launchpad-integration patch (well, actually about liblaunchpad-integration1-cil, which is broken). [06:03] I don't suppose there's an early-rising Do-using core-dev who could take care of sponsoring bug #516920 before too many other duplicates wander into my inbox? [06:03] Launchpad bug 516920 in gnome-desktop-sharp2 "gnome-do crashes when Preferences selected from menu" [High,Confirmed] https://launchpad.net/bugs/516920 [06:04] RAOF: To Lucid? Since some enterprising user has nominated it for every release from Hardy to Lucid and Dapper [06:05] Oh. It's r12056 [06:05] I can't decline any of those, but only Lucid, yes. [06:06] I've also got a patch to dh_clideps that will make these sort of problems cause a nice, clean FTBFS rather than silently breaking the archive. [06:06] That sounds good too [06:07] /c/c [06:07] Which brings me to my next point. Perl syntax is weird. :) [06:07] RAOF: Every one of them declined [06:08] Thanks muchly. [06:08] Patch looks sane, too [06:09] What would be even nicer is to properly rewrite the .config file to resolve -dev symlinks, but that's harder to do safely, I think. [06:10] RAOF: I think a FTBFS is a nice safe option, currently [06:10] Yes. And it's much easier to do. [06:10] Even given that diff is fairly brittle [06:11] The .config file doesn't change very frequently. [06:13] RAOF: Uploaded. [06:13] Thanks! [06:29] Anyone Advocate/Review my package IOK http://revu.ubuntuwire.com/p/iok [07:25] i'm looking for some opinions... a push in a direction. I'm a formally trained programmer, but from few yrs back (procedural). Looking for recommendations from Linux perspective on where to start to learn OO and what language. C? C++? Something else? [07:39] good morning [07:50] Good morning [07:50] hey dholbach, wie gehts? [07:51] pitti: gut, noch etwas gejetlagged, aber zumindest kommt der Koffer nachher! und dir? [07:51] gejetlagged isnt a word :) [07:52] good morning who is the maintainer of sane? [07:52] / which people [07:52] dholbach: urgh, lost your luggage? that sucks [07:52] stefanlsd, dholbach just created it [07:52] :) [07:52] dholbach: I'm reasonably well, got to bed at 2300 and woke up at 8 [07:53] * ogra quickly adds it to aspell and uploads :) [07:53] pitti: after getting delayed in Portland, I had 20 minutes in Amsterdam to change planes :) [07:53] launchpad has it listed as [07:53] ubuntu-dev-team [07:53] dholbach: did that work out? [07:53] pitti: for me yes, but not for the luggage :) [07:53] d1b, best to check for the last uploader then or check the changelog for the person that did the most uploads of it [07:54] pitti, so you made it through washington ? [07:54] ogra: right but i have a general issue. also shouldn't they really be listed as the 'maintainer'. [07:54] d1b, nope, if he/she steps back the team is the right contact address [07:54] ogra: no, I spent 45 mins on the phone on Friday to get rerouted; the Washington one got cancelled; went through Chicago and Munich instead [07:55] i though chicago was shut down as well ? [07:55] intresting [07:56] /bin/installer: line 48: 465 Segmentation fault apt-get -y install oem-config [07:56] grrr ! [08:22] if someone in ~ubuntu-sru could take a quick look at ubuntu-docs 8.10.3 in the queue for intrepid-proposed, that would be appreciated [08:23] pitti: hi. i have emailed you. the sane-backends package is really out of date vs git for files such as those which define working device ids for a backend. [08:24] d1b: I'm looking at the merge as I type [08:24] (as in I just did a "bzr clone lp:debian/squeeze/sane-backends") [08:24] crimsun: what...? [08:24] doesn't debian keep their backend in git? [08:25] crimsun: http://git.debian.org/?p=sane/sane-backends.git;a=commitdiff;h=f3e63b4e4df29342c1b84efe13b65a77f16ca5e5 is one of the commits / examples im talking about. [08:25] d1b: I'm referring to a system by which Ubuntu source merges are generated, not necessarily which VCS is used by Debian [08:25] crimsun: right. [08:27] crimsun: debian-squeeze also is missing this [08:42] d1b: got your mail [08:43] crimsun: oh, thanks; so you're on it? [08:44] yes he appears to be on it. i think the problem is due to sane not having a release since... [08:44] i have now filed a bug in debian. hoping to get that fixed up too. [08:44] yeah,I saw the bit in -bugs [08:49] <\sh> soren: ping vmbuilder, separate boot partition doesn't work somehow when starting up such a vm (kvm here) [08:50] <\sh> soren: could it be, that something is wrong with checking on "/boot/foo" in VMBuilder/disk.py ? [08:50] pitti: I wonder if you might be able to help with my ~sru question above? [08:52] mdke: uh, intrepid .. *blows the dust away* [08:52] mdke: I can have a look, but since it's quite out of fashion we usually only do OMGcritical fixes now [08:59] pitti: oh right. This isn't along those lines. i was just trying to get it off my bug list :) [09:00] pitti: if you say leave it, that's fine [09:00] mdke: I'll have a look; if it's harmless, we can as well accept it [09:00] pitti: ok. I have to leave irc now but I'll pick up on any emails - thanks for taking a look === tkamppeter__ is now known as tkamppeter [09:25] d1b: / pitti: will look after rest/work; I shouldn't be merging this time of night/morning [09:25] thanks; sleep well! [09:45] +1 [09:47] mvo, i had an additional apt-get clean in the code that deleted the packages after copying them into place ... that caused the auth issues i guess [09:47] oh my ... [09:47] * ogra tries to verify [09:48] ogra: so it works now? [09:48] just running a test ... will take 20-30min to do the two builds [09:55] * mvo nods [09:56] funny, it didnt require an apt-get update so the package lists were in place ... apt-get clean is just to quiet else i would have spotted it [10:01] * ogra goes offline for the offline build test [10:14] mvo, it still moans abour auth but at least finishes with --allow-unauthenticated [10:16] ogra: hm, if you have branch available of the script I can have a look [10:18] mvo, https://code.launchpad.net/~project-rootstock-developers/project-rootstock/trunk [10:29] In LTSP, if I install edubuntu-desktop in the chroot, then $CHROOT/proc is in use and can't be cleanly unmounted. We do dpkg-divert start-stop-daemon and initctl - what else could be using /proc? lsof doesn't help... [10:57] cjwatson: do you have any problem with me upgrading lp:ubuntu/gfxboot-theme-ubuntu to 2a format? [11:03] has someone done a grub2 graphical theme yet [11:03] ? [11:05] directhex: I thought I read in your blog that you did. [11:05] persia, nothing for the lucid graphical style [11:06] Oh, specifically for lucid. You might ask in #ubuntu-artwork, but otherwise I suspect one is welcome. [11:06] Even just a framework that someone can tweak, unless it costs boot time. [11:07] i don't know what the cost is going to be. evidently there's a cost associated with loading images & extra grub modules, but i don't know how much it is real-world [11:08] If it's not == 0, then the chances of it going into the default install are nil. [11:09] Or rather, the chances of having it enabled by default are nil. Having it available for those who choose to tweak their settings is a bit higher (but not extremely high). [11:10] asac, ping [12:03] uuid-dev doesn't have /usr/lib/libuuid.la anymore? [12:07] ivoks: .la files have been generally deprecated [12:07] http://wiki.debian.org/ReleaseGoals/LAFileRemoval [12:07] ok [12:08] thanks, wasn't aware of that [12:13] Hi , am having dictionary file for tamil, this going to be install to this directory /usr/share/myspell/dicts , for this how to create debian package? [13:10] \sh: Quite possible, yes. [13:13] cjwatson: ping === elpargo_ is now known as elpargo [13:25] Hi. I am the usb-modeswitch{-data} maintainer for Debian. It has some bugs on Ubuntu which are solved by new versions in Debian. Who is supposed to ask for a sync ? [13:26] OdyX, anyone can ask for a sync https://wiki.ubuntu.com/SyncRequestProcess ... note that we default to sync from testing for 10.04 though [13:27] ogra: Okay. My fixes are in testing :-> How late are we wrt to Ubuntu's freeeze ? [13:27] debian import freeze is on the 11th [13:27] should be fine if you file the request now [13:27] oh. 3 days left then [13:28] great. [13:41] hi! could anyone with core-dev upload priviledges please act on bug #493628 ? [13:41] Launchpad bug 493628 in mozvoikko "Please merge mozvoikko-1.0-4 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/493628 [13:56] mvo: do we still need this nasty $http_proxy hack in sudo? [13:57] mvo: it's important because of bug 432631 [13:57] Launchpad bug 432631 in sudo "sudo only preserves some, but not all proxy env vars" [Medium,Confirmed] https://launchpad.net/bugs/432631 [13:57] pitti: not strictly, but I would agree we should keep it. its just one entry in the environment whitelist, or do you talk about a different one? [13:58] mvo: well, it's creating inconsistencies, as reported by TeTeT [13:58] TeTeT: Isn't that intended behaviour? [13:58] and I'm not really keen on endlessly expanding the list [13:59] persia: makes it tough to use in certain proxy architectures, where you serve some from within your network, others from the Internet [13:59] mvo: but you can set the proxy on installation these days, can't you? [13:59] serve some=packages [13:59] my prevent approach would be to have them all in the whitelist then. we have all the bits&pieces in place to remove it, but it will be a inferiour user experience IMO [13:59] yes, proxy can be set during install and via network capplet [13:59] but the user needs to remember to click on "apply for all users" (or somesuch) when he sets the proxy [13:59] mvo: aptdaemon gets it from where? it's not run through sudo [14:00] without that, the proxy will only be in his session and if we remove the sudo support, then it will not be there in the terminal [14:00] pitti: IMO the first admin user [14:00] pitti: aptdaemon gets it from the client (software-center) so that is fine [14:00] well, perfect [14:00] I'm more concerned it people opening a terminal [14:00] (well, not perfect in fact, since it's the very same security problem) [14:02] a proxy just conceptually isn't something that should be a per-user setting [14:02] mvo: perhaps eventually the proxy capplet should _always_ apply system-wide? [14:02] we can make that happen, I guess, just check for admin group and not ask for a password [14:02] Um, why shouldn't proxies be per-user? I agree in the case of apt proxies, but I can imagine all kinds of other sorts of proxies being per-user. [14:02] isn't /etc/cron.daily/apt also taking the proxy environment from a user? [14:03] TeTeT: its doing that to work around the same problem [14:03] and only if there is no proxy set via apt conf or the root environment [14:04] ok, just saw the -z http_proxy [14:05] mvo + pitti : so there is no easy solution? [14:05] mvo: no, I meant "apply system-wide" should always be the default button [14:05] or action [14:06] ugh, how can the daily cron job take an user's env? which user's? [14:06] pitti: first admin user [14:07] That requires all sorts of hackery. [14:07] urgh [14:07] we really need a system-wide setting for this [14:07] pitti: admin_user=$(getent group admin|cut -d: -f4|cut -d, -f1) [14:08] persia: while that might be true, I doubt that for the vast majority of use cases [14:08] we don't have per-user network connections either [14:08] and a proxy is very tightly tied to a network configuration [14:09] Well, OK. I'm thinking of things like a shared machine where someone wants a UK proxy for BBC, but others don't need it, and the like. [14:09] and if one special application wants to talk through a proxy, it should ceratinly handle that internally instead of clobbering $http_proxy? [14:09] I was thinking of the browser :) [14:09] persia: the browser can use it's on proxy setting per user without problem, IMO [14:09] we have a way to set this system wide, the apt cron script checks gconf for the case when a user installed without proxy and never pressed "use system wide". this is only a precaution to ensure that e.g. security updates can get through [14:10] that already has its own (and also I still don't believe that per-user settings are much sensible there) [14:10] I'm in favour of removing all this, don't get me wrong, I'm just concerned that we break a lot of systems that used to work and will no longer work after the change [14:10] mvo: OTOH that means if an user breaks his proxy settings, we break security updates system-wide? [14:11] its only the admin user and if he can no longer browse, he will notice [14:11] right, it's a case of "should've fixed that 5 years ago" :( [14:11] I mean, that is a bit of a theretical scenario, if he breaks his other network settings, the same hapepns [14:12] I think its just a unfortunate thing we inherited from the gnome control center [14:13] my take on it would be: make it consistent for lucid (by adding https_proxy, ftp_proxy) and remove for lucid+1 with appropriate way of telling the user [14:15] works for me [14:15] couldn't we alternatively use the first admin user's proxy setting and write that into a system-wide conffile in a postinst? [14:15] it's no worse than we do now, but woudl at least be an one-time migration [14:15] and if we do it in lucid, we aren't stuck with it for another 4 releases [14:16] its worse in the sense that it will not update the config [14:16] we have the "apply system wide" button [14:16] I mean, then we need to tell the user what we did if he has a different proxy on home/work [14:16] we could update the label in g-c-c? [14:17] oh, that is a good idea - update to indicate inconistency? [14:17] I mean, if persia's objection of "per-user settings make sense" is true, then we _don't_ always want to apply those to apt [14:17] and if it's false, then we shouldn't have per-user settings in the first place [14:17] mvo: indicate inconsistency also sounds good; I meant, change the wording around "system wide" to point out "to also apply to package updates" [14:18] I guess that is a good way forward, apply once and when changed have a way to tell the users that its inconsistent [14:18] (apply once via postinst) [14:18] mvo: does apt just use $http_proxy as well? I. e. /etc/environment? [14:18] mvo: IOW, what does "apply system-wide" do? adding it to /etc/environment would make sense certainly? [14:19] pitti: apt has its own apt.conf setting, but the system-wide button also writes to /etc/environment [14:19] ah, I see [14:19] pitti: it does both, add to apt.conf and environment [14:20] mvo: AFAICS, /etc/cron.daily/apt only sets $http_proxy, though [14:21] right, it can go away entirely with the approach of apply+warn IMO [14:21] mvo: right, I meant apparently apt does check $http_proxy? [14:21] yes [14:22] it would make the entire system very consistent [14:22] i. e. system-wide $http_proxy, and users can change [14:22] ok, I'll summarize in the bug [14:22] mvo: thanks for discussion! [14:22] could these two bugs be caused by a similar flaw? https://bugs.launchpad.net/ubuntu/+source/gnome-utils/+bug/29894 & https://bugs.launchpad.net/notify-osd/+bug/500550 [14:23] Ubuntu bug 29894 in gnome-utils "can't take screenshot when menu on panel is opened" [Unknown,In progress] [14:23] pitti: sure, thanks as well, I think we have a good solution [14:27] mvo, TeTeT: bug 432631 updated; cross-check? [14:27] Launchpad bug 432631 in sudo "clean up system/per-user proxy handling" [Medium,In progress] https://launchpad.net/bugs/432631 [14:27] <\sh> soren: I changed that but no change :( [14:31] pitti: thanks, done. I added the inconsitency check/warning. I think its important to ensure users keep updating the thing [14:31] thanks === dholbach_ is now known as dholbach [14:52] anyone know why https://launchpad.net/ubuntu/+source/cloud-utils is still 'pending publication' [14:52] build took place 2 days ago [14:53] smoser: Check the NEW queue. [14:53] https://launchpad.net/ubuntu/lucid/+queue [14:55] persia, thanks [15:21] any main sponsor free to review and sponsor bug #509900? [15:21] Launchpad bug 509900 in vim "Merge vim 2:7.2.330-1 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/509900 [15:54] oh, when did we stop setting LANG in /etc/environment ? [15:56] did we ever? [15:57] /etc/default/locale [15:57] yes, tollef added that ages ago [15:57] pre dapper iirc [15:57] and it was always carried along [15:57] /etc/environment works [15:57] mine only has PATH [15:57] but we don't put it there by default [15:57] right [15:57] we used to though [15:58] I think it changed in Interpid [15:58] that might be, my lappie was upgraded from intrepid originally until i did this renistall for the new HD [16:01] sigh ... [16:02] oem-config doesnt work at all here ... goes into an endless loop === yofel_ is now known as yofel [16:16] is it normal for publish-to-archive to lag build by more than a day ? [16:16] https://edge.launchpad.net/ubuntu/+source/linux-ec2 build finished 44 hours ago, but its not in archive yet. [16:18] smoser: looks like it's in binary new: https://launchpad.net/ubuntu/lucid/+queue?start=30 [16:18] smoser, if you look closer at the build ( https://launchpad.net/ubuntu/+source/linux-ec2/2.6.32-302.6 ), you can see that it's got "New" binaries. that means an archive admin will have to accept them into the archive and adjust the component (main,restricted,universe,multiverse) accordingly [16:19] ogra, what version of oem-config are you testing that's going into an endless loop? [16:19] superm1, well, i'm not sure i run it correctly or even set it up correctly, its the recent lucid version [16:20] hm.. [16:20] ogra, well all there is to setting it up is "sudo oem-config-prepare", but the particulars on the version are important because there was some bugs that would cause that behavior within the last 2 versions or so, but should be resolved on the latest [16:21] superm1, essentially i only want user timezone kbd and language settings in a bare debootstrapped chroot system ... i installed oem-config and touched /var/lib/oem-config/run [16:21] Are there still problems with autosyncing debsrc3.0 packages? [16:21] i dont quite understand why linux-ec2 build would have produced "new" packages. [16:21] superm1, the above makes it start but gets me also tasksel and a lot of extra stuff i'd like to avoid [16:21] smoser: New binary packages. ABI bump, right? [16:22] ogra, oh you're running the debconf frontend.... i'm not sure how stable it is at this point [16:22] superm1, ah, i'll try to do an X setup then [16:22] though i need both frontends [16:22] oh. ok. yeah. ther ewas an abi bump. so each time kernel bumps abi they have a "new" package. [16:22] smoser: Yes. [16:22] soren, you're right on abi bump. [16:23] smoser: This happens all the times for kernels. Most of the time, you just don't notice :) [16:23] right. [16:29] is it proper for me to nag slangasek or james_w (per https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days) to approve https://launchpad.net/ubuntu/lucid/+queue?queue_state=0&queue_text=linux ? [16:31] smoser: it is [16:36] superm1, oem-config-enable doesnt setup the /var/lib/oem-config/run it only puts the rc scripts in place it seems [16:37] ogra, oem-config-prepare is what i had mentioned, but essentially it's just touching /var/lib/oem-config/run for the next boot [16:37] superm1, didnt happen here [16:38] hmm, and installing the xorg package in the chroot didnt get me the graphical version ... i wonder what i'm missing [16:38] james_w, could you do that for me then please ? thank you. [16:42] superm1, do you know if ubiquity or d-i put anything in place i have to add to my chroot/image to make it start ubiquitys oem-config instead of the text version ? as far as i understood its just supposed to come up as DM [16:52] root@osiris:/# /usr/sbin/oem-config -q [16:52] debconf_ui [16:52] aha [16:56] sebner: only with second autosyncs of packages using .orig.tar.bz2 (see bug #225151) [16:56] Launchpad bug 225151 in soyuz "Please add support for .orig.tar.bz2" [High,Triaged] https://launchpad.net/bugs/225151 [16:57] smoser: done [16:57] danke [17:00] geser: ah ic. thanks :) [17:00] could somebody check https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 for me ? it needs sponsoring [17:01] Ubuntu bug 391035 in aptitude "aptitude stops displaying downloads" [Low,Triaged] [17:04] would be nice this fix gets into Lucid, as its broken since Karmic :( === walters_ is now known as walters [17:07] ogra, you've gotta install a gtk or kde frontend to use one of those (oem-config-gtk or oem-config-kde) [17:08] oh, i thought that comes automatically with the new ubiquity dep [17:08] silly me [17:08] dupondje: my C++ is a little bit rusty but don't you need to free(delete) the BlankLine allocation somewhere again? [17:09] geser: I didn't touch the free's etc, only the size of the thing :) [17:10] it's allocated on the stack [17:11] wow, the gtk frontend pulls in fvwm ??? [17:12] ogra, it pulls in a window manager. i suppose fvwm is one of those possibilities [17:13] most cases it's used people already have metacity or xfwm4 installed [17:13] yeah, i guess i'm building a very special case atm ;) [17:14] * ogra is working on an offline rootfs build tool for armel systems === johanbr_ is now known as johanbr [17:15] and i thought it would be the easies to just pull in oem-config to set up user and pw ... but that effort gets wose and worse [17:15] dupondje: you really should use a patch, rather then directly modifying the source [17:15] tsimpson: why exactly ? whats the difference ? [17:16] dupondje: before it was on the stack and was cleared automatically, but now you use dynamic allocation (new) and should free it again (delete) else you get a memory leak [17:17] dupondje: several reasons, a couple of which are: 1) it's debian policy, 2) it's easy to see ubuntu changes, and 3) if upstream incorporate the patch, it's easy to remove our patch [17:17] and yes, you do need to "delete[] BlankLine;" somewhere (the destructor) [17:18] ok thanks for the input [17:18] will make a new debdiff [17:20] pitti, ping, your you have feedback on https://bugs.launchpad.net/ubuntu/+source/apport/+bug/513061 (last comment there) [17:20] Ubuntu bug 513061 in apport "apport reports 'not a genuine Ubuntu package' on fresh installation without apt cache" [Low,Triaged] [17:35] no ui at all :/ [17:37] argh and installing metacity would install 400MB ! [17:37] * ogra wants old oem-config back ! that ubiquity merge is a mess if you dont use it with a desktop image [17:40] *whine* [17:43] ah, i was trapped by recommends [17:43] still over 30M [17:53] superm1, ok, its trying to start but breaks then with subprocess.Popen(proc) [17:54] using 2.1.16 btw [17:54] ogasawara_, can you get a full BT? It might have logged that BT to /var/log/oem-config.log already for you. [17:54] ogra, ^ [17:55] i'll try to ... i sadly cant copy-paste from qemu [17:55] you should be able to at least scp that log file out hopefully to a real machine [17:55] or use something like pastebinit to get it out on the internets [17:55] yeah, indeed [17:56] woah [17:56] seems to be a pygtk issue actually [18:08] superm1, just fyi ... http://paste.ubuntu.com/371902/ i doubt its ubiquitys fault [18:09] ogra, yeah i agree. have fun debugging that :) [18:10] heh [18:10] i'll probably give up on the UI part ... it pull sway to much into the rootfs anyway since the merge [18:10] the old oem-config was far better suited for that usecase [18:11] (which is why it was initially added to the spec :) ) [18:14] bdmurray, ping? [18:14] ignore my msg :) [18:19] ogra, well the debconf frontend is probably still well suited for your case, just check with ev where it's at stability wise. [18:20] yeah [18:20] seems i need to have a lot of debconf stuff set in advance though [18:20] currently thats a plain debootstrapped system [18:21] superm1, do you know if we have any docs what oem-config expects or do i need to dig through the code ? [18:22] ogra, for the debconf ui, i've no idea. for the other UI's, nothing needs to be set in advance normally [18:22] ok [18:22] well, then i'D expect the same for debconf actually [18:22] i'll wait until ev is back [18:37] pitti, whats happening with the states on bug# 446146 [18:37] bug #446146, you and JFo seem to be arguing :) [18:37] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/446146) [18:37] * apw slaps ubottu [18:37] be more patient ubottu [18:38] heh [18:38] I keep getting timeouts too [19:06] be nice to the bot [19:11] maybe someone can help. i'm missing something and can't figure out what. I'm trying to backport schroot to karmic. I grabbed ubuntu source (lp:ubuntu/schroot) and applied changes at http://paste.ubuntu.com/371949/ [19:12] whenh i build with sbuild, it builds fine, but a schroot-common package is not built. I'm at a loss as to why, I see i nthe log that files are copied to debian/install/usr/share/locale [19:12] (debian/schroot-common.install has 'debian/install/usr/share/locale usr/share') [19:17] i notice now the libsbuild-doc package is also not built [19:18] sbuild is commonly used for buildds. Therefore, I would be unsurprised if it defaulted to not building architecture=all packages. [19:19] maxb, thank you === sabdfl1 is now known as sabdfl [19:45] smoser: I don't use sbuild but I heard that you need to pass an option to sbuild to also build the arch-indep packages, check the manpage in that direction [19:46] geser, yeah maxb suggested above, and was correct. i had to run with --arch-all [19:46] but thank you [19:46] tsimpson: geser: https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 [19:46] Ubuntu bug 391035 in aptitude "aptitude stops displaying downloads" [Low,Triaged] [19:46] added a new patch [19:52] kees: Hi, thanks for your last commit to ubuntu-dev-tools. would you consider it as a fix for bug #518574? [19:52] Launchpad bug 518574 in ubuntu-dev-tools "requestsync is dependent on a Debian batch process" [Undecided,New] https://launchpad.net/bugs/518574 [19:52] geser: oh, hrm [19:52] * kees reads [19:53] geser: yeah, I guess it does. I will adjust my commeit [19:53] s/eit/it [20:03] geser: could you check if its fully correct now ? :) [20:03] slangasek: ping [20:03] kirkland: hi [20:03] slangasek: http://paste.ubuntu.com/371989/ <--- that's the pam patch I need for the improved ecryptfs functionality [20:03] slangasek: i'm looking for guidance from you on the order of operations here [20:03] slangasek: i'm prepping an email to upstream PAM [20:04] slangasek: in what order should the patch be accepted, before I can upload it to Lucid? [20:04] slangasek: ie, is upstream and debian acceptance pre-reqs for getting this patch into Lucid's pam soon? [20:04] dupondje: looks ok as far as I can tell, you just need to wait for a main sponsor now [20:05] geser: ok thx for looking :) [20:05] kirkland: why does pam_ecryptfs need pam_keyinit in the auth stage? If you can tell me that, then I have no objection to it going into lucid first [20:07] slangasek: hrm [20:07] slangasek: this bit was written with dhowells [20:08] slangasek: basically, we need pam_keyutils to establish the session keyring [20:08] slangasek: whereas now, we're using the user keyring [20:08] why are we expecting the session keyring to be established before the PAM session is opened? :) [20:08] kees: I see you already uploaded patches for aptitude, is it maby possible to check https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 ? Would be nice if this gets into Lucid. Just did a build, and it works perfect :) [20:08] Ubuntu bug 391035 in aptitude "aptitude stops displaying downloads" [Low,Triaged] [20:09] * kirkland thinks [20:10] actually, looks to me like we're missing a corresponding pam_sm_close_session() call - is that going to leave extra session keyrings hanging around in the kernel? [20:10] slangasek: dhowells says that those are auto-reaped [20:10] ok [20:11] slangasek: okay, so pam_ecryptfs inserts the key in its pam_sm_authenticate() [20:11] slangasek: which means the keyring must exist at that point [20:11] why does it do that, rather than waiting until pam_sm_open_session() itself? [20:12] slangasek: well, we need the passphrase the user actually entered [20:12] slangasek: to unwrap the mount passphrase [20:12] yes; which can be captured in the auth stage and stored as module data until the session stage [20:12] slangasek: interesting... [20:13] otherwise, what happens with a session-less service when you have pam_ecryptfs configured? [20:13] dupondje: was that meant for someone else? [20:14] slangasek: looking at the code ... [20:14] kees: no, saw you had some change in aptitude. Just need somebody that wants to approve the patch. [20:15] slangasek: pam_ecryptfs's session handler just does the mount, if necessary, and if possible [20:15] slangasek: it expects the necessary keys to already be loaded [20:15] well, I'm questioning that assumption :) [20:15] slangasek: which happens at the auth stage [20:15] i.e., why should the kernel setup be done at the auth stage, if it's really tied to a session [20:16] consider a sessionless service that runs multiple user authentications in a single process [20:16] (web services may fit this model) [20:16] (or POP?) [20:19] slangasek: hmm, so you're saying don't load the keys *unless* we're in a session [20:19] * slangasek nods [20:19] slangasek: okay, well, i can't find a good argument why not [20:20] slangasek: i think this originally landed in pam_auth so that we would have access to the password [20:20] I think pam_krb5 is probably a good example to follow, here [20:20] dupondje: oh, yeah, that was just an ABI bump. check with mvo [20:20] slangasek: okay, well, my only concern is that this is a lot of code for me to muck around with at this point in Lucid [20:20] kees: will do if he's around here somewhere :) [20:20] (though I think pam_krb5 uses kerberos APIs to carry the creds between auth and session, instead of the PAM APIs) [20:20] slangasek: i might need a good second set of eyes [20:21]