[02:25] <arand> Is, or at what point is LTS → LTS upgrades scheduled to be available for testing (hardy→lucid)?
[02:30] <persia> Now.
[02:30] <persia> They may not work, but that just means it's worth filing bugs.
[02:30] <Tm_T> sooner the better
[02:32] <arand> persia: Ok, then how would I do one?
[02:33] <persia> Take an existing hardy install (or a new one).  Apply all the updates.  dist-upgrade.
[02:40] <arand> persia: nice, just saw the -d flag for do-release-upgrade, cheers.
[04:47] <RAOF> Ooof.  I'm surprised no one else seems to have noticed Tomboy crashing because of a liblaunchpad-integration-cil bug.
[04:48] <RAOF> Maybe everyone has liblaunchpad-integration-dev installed.
[05:02] <mdeslaur> ROAF: bug #518662
[05:02]  * RAOF shall play “merge the duplicates”
[05:04] <arand> RAOF: https://bugs.launchpad.net/ubuntu/+source/tomboy/+bug/516210 might be the main one?
[05:05] <Bsims> 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] <Bsims> smartmon says its clean, and I am running the long test now... anyone else see this after the last round of upgrades
[05:06] <RAOF> arand: No, it's not.  That's a different problem.
[05:06] <arand> RAOF: oh, ops.
[05:07] <RAOF> 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] <RAOF> 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:04] <StevenK> RAOF: To Lucid? Since some enterprising user has nominated it for every release from Hardy to Lucid and Dapper
[06:05] <StevenK> Oh. It's r12056
[06:05] <RAOF> I can't decline any of those, but only Lucid, yes.
[06:06] <RAOF> 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] <StevenK> That sounds good too
[06:07] <TheMuso> /c/c
[06:07] <RAOF> Which brings me to my next point.  Perl syntax is weird. :)
[06:07] <StevenK> RAOF: Every one of them declined
[06:08] <RAOF> Thanks muchly.
[06:08] <StevenK> Patch looks sane, too
[06:09] <RAOF> 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] <StevenK> RAOF: I think a FTBFS is a nice safe option, currently
[06:10] <RAOF> Yes.  And it's much easier to do.
[06:10] <StevenK> Even given that diff is fairly brittle
[06:11] <RAOF> The .config file doesn't change very frequently.
[06:13] <StevenK> RAOF: Uploaded.
[06:13] <RAOF> Thanks!
[06:29] <suji11>  Anyone Advocate/Review my package IOK http://revu.ubuntuwire.com/p/iok
[07:25] <shawnboy> 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] <dholbach> good morning
[07:50] <pitti> Good morning
[07:50] <pitti> hey dholbach, wie gehts?
[07:51] <dholbach> pitti: gut, noch etwas gejetlagged, aber zumindest kommt der Koffer nachher! und dir?
[07:51] <stefanlsd> gejetlagged isnt a word :)
[07:52] <d1b> good morning who is the maintainer of sane?
[07:52] <d1b>  / which people
[07:52] <pitti> dholbach: urgh, lost your luggage? that sucks
[07:52] <ogra> stefanlsd, dholbach just created it
[07:52] <ogra> :)
[07:52] <pitti> 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] <dholbach> pitti: after getting delayed in Portland, I had 20 minutes in Amsterdam to change planes :)
[07:53] <d1b> launchpad has it listed as
[07:53] <d1b> ubuntu-dev-team
[07:53] <pitti> dholbach: did that work out?
[07:53] <dholbach> pitti: for me yes, but not for the luggage :)
[07:53] <ogra> 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] <ogra> pitti, so you made it through washington ?
[07:54] <d1b> ogra: right but i have a general issue. also shouldn't they really be listed as the 'maintainer'.
[07:54] <ogra> d1b, nope, if he/she steps back the team is the right contact address
[07:54] <pitti> 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] <ogra> i though chicago was shut down as well ?
[07:55] <ogra> intresting
[07:56] <ogra> /bin/installer: line 48:   465 Segmentation fault      apt-get -y install oem-config
[07:56] <ogra> grrr !
[08:22] <mdke> 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] <d1b> 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] <crimsun> d1b: I'm looking at the merge as I type
[08:24] <crimsun> (as in I just did a "bzr clone lp:debian/squeeze/sane-backends")
[08:24] <d1b> crimsun: what...?
[08:24] <d1b> doesn't debian keep their backend in git?
[08:25] <d1b> 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] <crimsun> d1b: I'm referring to a system by which Ubuntu source merges are generated, not necessarily which VCS is used by Debian
[08:25] <d1b> crimsun: right.
[08:27] <d1b> crimsun: debian-squeeze also is missing this
[08:42] <pitti> d1b: got your mail
[08:43] <pitti> crimsun: oh, thanks; so you're on it?
[08:44] <d1b> yes he appears to be on it. i think the problem is due to sane not having a release since...
[08:44] <d1b> i have now filed a bug in debian. hoping to get that fixed up too.
[08:44] <crimsun> 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] <mdke> pitti: I wonder if you might be able to help with my ~sru question above?
[08:52] <pitti> mdke: uh, intrepid .. *blows the dust away*
[08:52] <pitti> mdke: I can have a look, but since it's quite out of fashion we usually only do OMGcritical fixes now
[08:59] <mdke> pitti: oh right. This isn't along those lines. i was just trying to get it off my bug list :)
[09:00] <mdke> pitti: if you say leave it, that's fine
[09:00] <pitti> mdke: I'll have a look; if it's harmless, we can as well accept it
[09:00] <mdke> pitti: ok. I have to leave irc now but I'll pick up on any emails - thanks for taking a look
[09:25] <crimsun> d1b: / pitti: will look after rest/work; I shouldn't be merging this time of night/morning
[09:25] <pitti> thanks; sleep well!
[09:45] <d1b> +1
[09:47] <ogra> 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] <ogra> oh my ...
[09:47]  * ogra tries to verify
[09:48] <mvo> ogra: so it works now?
[09:48] <ogra> just running a test ... will take 20-30min to do the two builds
[09:55]  * mvo nods
[09:56] <ogra> 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] <ogra> mvo, it still moans abour auth but at least finishes with --allow-unauthenticated
[10:16] <mvo> ogra: hm, if you have  branch available of the script I can have a look
[10:18] <ogra> mvo, https://code.launchpad.net/~project-rootstock-developers/project-rootstock/trunk
[10:29] <alkisg> 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] <james_w> cjwatson: do you have any problem with me upgrading lp:ubuntu/gfxboot-theme-ubuntu to 2a format?
[11:03] <directhex> has someone done a grub2 graphical theme yet
[11:03] <directhex> ?
[11:05] <persia> directhex: I thought I read in your blog that you did.
[11:05] <directhex> persia, nothing for the lucid graphical style
[11:06] <persia> Oh, specifically for lucid.  You might ask in #ubuntu-artwork, but otherwise I suspect one is welcome.
[11:06] <persia> Even just a framework that someone can tweak, unless it costs boot time.
[11:07] <directhex> 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] <ScottK> If it's not == 0, then the chances of it going into the default install are nil.
[11:09] <persia> 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] <csurbhi> asac, ping
[12:03] <ivoks> uuid-dev doesn't have /usr/lib/libuuid.la anymore?
[12:07] <persia> ivoks: .la files have been generally deprecated
[12:07] <persia> http://wiki.debian.org/ReleaseGoals/LAFileRemoval
[12:07] <ivoks> ok
[12:08] <ivoks> thanks, wasn't aware of that
[12:13] <suji11> 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] <soren> \sh: Quite possible, yes.
[13:13] <dantti> cjwatson: ping
[13:25] <OdyX> 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] <ogra> 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] <OdyX> ogra: Okay. My fixes are in testing :-> How late are we wrt to Ubuntu's freeeze ?
[13:27] <ogra> debian import freeze is on the 11th
[13:27] <ogra> should be fine if you file the request now
[13:27] <OdyX> oh. 3 days left then
[13:28] <OdyX> great.
[13:41] <Q-FUNK> hi! could anyone with core-dev upload priviledges please act on bug #493628 ?
[13:56] <pitti> mvo: do we still need this nasty $http_proxy hack in sudo?
[13:57] <TeTeT> mvo: it's important because of bug 432631
[13:57] <mvo> 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] <pitti> mvo: well, it's creating inconsistencies, as reported by TeTeT
[13:58] <persia> TeTeT: Isn't that intended behaviour?
[13:58] <pitti> and I'm not really keen on endlessly expanding the list
[13:59] <TeTeT> persia: makes it tough to use in certain proxy architectures, where you serve some from within your network, others from the Internet
[13:59] <pitti> mvo: but you can set the proxy on installation these days, can't you?
[13:59] <TeTeT> serve some=packages
[13:59] <mvo> 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] <mvo> yes, proxy can be set during install and via network capplet
[13:59] <mvo> but the user needs to remember to click on "apply for all users" (or somesuch) when he sets the proxy
[13:59] <pitti> mvo: aptdaemon gets it from where? it's not run through sudo
[14:00] <mvo> 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] <TeTeT> pitti: IMO the first admin user
[14:00] <mvo> pitti: aptdaemon gets it from the client (software-center) so that is fine
[14:00] <pitti> well, perfect
[14:00] <mvo>  I'm more concerned it people opening a terminal
[14:00] <pitti> (well, not perfect in fact, since it's the very same security problem)
[14:02] <pitti> a proxy just conceptually isn't something that should be a per-user setting
[14:02] <pitti> mvo: perhaps eventually the proxy capplet should _always_ apply system-wide?
[14:02] <mvo> we can make that happen, I guess, just check for admin group and not ask for a password
[14:02] <persia> 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] <TeTeT> isn't /etc/cron.daily/apt also taking the proxy environment from a user?
[14:03] <mvo> TeTeT: its doing that to work around the same problem
[14:03] <mvo> and only if there is no proxy set via apt conf or the root environment
[14:04] <TeTeT> ok, just saw the -z http_proxy
[14:05] <TeTeT> mvo + pitti : so there is no easy solution?
[14:05] <pitti> mvo: no, I meant "apply system-wide" should always be the default button
[14:05] <pitti> or action
[14:06] <pitti> ugh, how can the daily cron job take an user's env? which user's?
[14:06] <TeTeT> pitti: first admin user
[14:07] <persia> That requires all sorts of hackery.
[14:07] <pitti> urgh
[14:07] <pitti> we really need a system-wide setting for this
[14:07] <TeTeT> pitti: admin_user=$(getent group admin|cut -d: -f4|cut -d, -f1)
[14:08] <pitti> persia: while that might be true, I doubt that for the vast majority of use cases
[14:08] <pitti> we don't have per-user network connections either
[14:08] <pitti> and a proxy is very tightly tied to a network configuration
[14:09] <persia> 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] <pitti> and if one special application wants to talk through a proxy, it should ceratinly handle that internally instead of clobbering $http_proxy?
[14:09] <persia> I was thinking of the browser :)
[14:09] <TeTeT> persia: the browser can use it's on proxy setting per user without problem, IMO
[14:09] <mvo> 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] <pitti> that already has its own (and also I still don't believe that per-user settings are much sensible there)
[14:10] <mvo> 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] <pitti> mvo: OTOH that means if an user breaks his proxy settings, we break security updates system-wide?
[14:11] <mvo> its only the admin user and if he can no longer browse, he will notice
[14:11] <pitti> right, it's a case of "should've fixed that 5 years ago" :(
[14:11] <mvo> I mean, that is a bit of a theretical scenario, if he breaks his other network settings, the same hapepns
[14:12] <mvo> I think its just a unfortunate thing we inherited from the gnome control center
[14:13] <mvo> 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] <TeTeT> works for me
[14:15] <pitti> 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] <pitti> it's no worse than we do now, but woudl at least be an one-time migration
[14:15] <pitti> and if we do it in lucid, we aren't stuck with it for another 4 releases
[14:16] <mvo> its worse in the sense that it will not update the config
[14:16] <pitti> we have the "apply system wide" button
[14:16] <mvo> I mean, then we need to tell the user what we did if he has a different proxy on home/work
[14:16] <pitti> we could update the label in g-c-c?
[14:17] <mvo> oh, that is a good idea - update to indicate inconistency?
[14:17] <pitti> 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] <pitti> and if it's false, then we shouldn't have per-user settings in the first place
[14:17] <pitti> 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] <mvo> 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] <mvo> (apply once via postinst)
[14:18] <pitti> mvo: does apt just use $http_proxy as well? I. e. /etc/environment?
[14:18] <pitti> mvo: IOW, what does "apply system-wide" do? adding it to /etc/environment would make sense certainly?
[14:19] <mvo> pitti: apt has its own apt.conf setting, but the system-wide button also writes to /etc/environment
[14:19] <pitti> ah, I see
[14:19] <mvo> pitti: it does both, add to apt.conf and environment
[14:20] <pitti> mvo: AFAICS, /etc/cron.daily/apt only sets $http_proxy, though
[14:21] <mvo> right, it can go away entirely with the approach of apply+warn IMO
[14:21] <pitti> mvo: right, I meant apparently apt does check $http_proxy?
[14:21] <mvo> yes
[14:22] <pitti> it would make the entire system very consistent
[14:22] <pitti> i. e. system-wide $http_proxy, and users can change
[14:22] <pitti> ok, I'll summarize in the bug
[14:22] <pitti> mvo: thanks for discussion!
[14:22] <kitallis> 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] <mvo> pitti: sure, thanks as well, I think we have a good solution
[14:27] <pitti> mvo, TeTeT: bug 432631 updated; cross-check?
[14:27] <\sh> soren: I changed that but no change :(
[14:31] <mvo> pitti: thanks, done. I added the inconsitency check/warning. I think its important to ensure users keep updating the thing
[14:31] <pitti> thanks
[14:52] <smoser> anyone know why https://launchpad.net/ubuntu/+source/cloud-utils is still 'pending publication'
[14:52] <smoser> build took place 2 days ago
[14:53] <persia> smoser: Check the NEW queue.
[14:53] <persia> https://launchpad.net/ubuntu/lucid/+queue
[14:55] <smoser> persia, thanks
[15:21] <geser> any main sponsor free to review and sponsor bug #509900?
[15:54] <ogra> oh, when did we stop setting LANG in /etc/environment ?
[15:56] <pitti> did we ever?
[15:57] <pitti> /etc/default/locale
[15:57] <ogra> yes, tollef added that ages ago
[15:57] <ogra> pre dapper iirc
[15:57] <ogra> and it was always carried along
[15:57] <pitti> /etc/environment works
[15:57] <ogra> mine only has PATH
[15:57] <pitti> but we don't put it there by default
[15:57] <ogra> right
[15:57] <ogra> we used to though
[15:58] <alkisg> I think it changed in Interpid
[15:58] <ogra> that might be, my lappie was upgraded from intrepid originally until i did this renistall for the new HD
[16:01] <ogra> sigh ...
[16:02] <ogra> oem-config doesnt work at all here ... goes into an endless loop
[16:16] <smoser> is it normal for publish-to-archive to lag build by more than a day ?
[16:16] <smoser> https://edge.launchpad.net/ubuntu/+source/linux-ec2 build finished 44 hours ago, but its not in archive yet.
[16:18] <sistpoty|work> smoser: looks like it's in binary new: https://launchpad.net/ubuntu/lucid/+queue?start=30
[16:18] <superm1> 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] <superm1> ogra, what version of oem-config are you testing that's going into an endless loop?
[16:19] <ogra> superm1, well, i'm not sure i run it correctly or even set it up correctly, its the recent lucid version
[16:20] <smoser> hm..
[16:20] <superm1> 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] <ogra> 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] <sebner> Are there still problems with autosyncing debsrc3.0 packages?
[16:21] <smoser> i dont quite understand why linux-ec2 build would have produced "new" packages.
[16:21] <ogra> superm1, the above makes it start but gets me also tasksel and a lot of extra stuff i'd like to avoid
[16:21] <soren> smoser: New binary packages. ABI bump, right?
[16:22] <superm1> ogra, oh you're running the debconf frontend.... i'm not sure how stable it is at this point
[16:22] <ogra> superm1, ah, i'll try to do an X setup then
[16:22] <ogra> though i need both frontends
[16:22] <smoser> oh. ok. yeah. ther ewas an abi bump.  so each time kernel bumps abi they have a "new" package.
[16:22] <soren> smoser: Yes.
[16:22] <smoser> soren, you're right on abi bump.
[16:23] <soren> smoser: This happens all the times for kernels. Most of the time, you just don't notice :)
[16:23] <smoser> right.
[16:29] <smoser> 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] <james_w> smoser: it is
[16:36] <ogra> superm1, oem-config-enable doesnt setup the /var/lib/oem-config/run it only puts the rc scripts in place it seems
[16:37] <superm1> 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] <ogra> superm1, didnt happen here
[16:38] <ogra> hmm, and installing the xorg package in the chroot didnt get me the graphical version ... i wonder what i'm missing
[16:38] <smoser> james_w, could you do that for me then please ? thank you.
[16:42] <ogra> 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] <ogra> root@osiris:/# /usr/sbin/oem-config -q
[16:52] <ogra> debconf_ui
[16:52] <ogra> aha
[16:56] <geser> sebner: only with second autosyncs of packages using .orig.tar.bz2 (see bug #225151)
[16:57] <james_w> smoser: done
[16:57] <smoser> danke
[17:00] <sebner> geser: ah ic. thanks :)
[17:00] <dupondje> could somebody check https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 for me ? it needs sponsoring
[17:04] <dupondje> would be nice this fix gets into Lucid, as its broken since Karmic :(
[17:07] <superm1> ogra, you've gotta install a gtk or kde frontend to use one of those (oem-config-gtk or oem-config-kde)
[17:08] <ogra> oh, i thought that comes automatically with the new ubiquity dep
[17:08] <ogra> silly me
[17:08] <geser> dupondje: my C++ is a little bit rusty but don't you need to free(delete) the BlankLine allocation somewhere again?
[17:09] <dupondje> geser: I didn't touch the free's etc, only the size of the thing :)
[17:10] <tsimpson> it's allocated on the stack
[17:11] <ogra> wow, the gtk frontend pulls in fvwm ???
[17:12] <superm1> ogra, it pulls in a window manager.  i suppose fvwm is one of those possibilities
[17:13] <superm1> most cases it's used people already have metacity or xfwm4 installed
[17:13] <ogra> 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
[17:15] <ogra> 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] <tsimpson> dupondje: you really should use a patch, rather then directly modifying the source
[17:15] <dupondje> tsimpson: why exactly ? whats the difference ?
[17:16] <geser> 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] <tsimpson> 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] <tsimpson> and yes, you do need to "delete[] BlankLine;" somewhere (the destructor)
[17:18] <dupondje> ok thanks for the input
[17:18] <dupondje> will make a new debdiff
[17:20] <smoser> pitti, ping, your you have feedback on https://bugs.launchpad.net/ubuntu/+source/apport/+bug/513061 (last comment there)
[17:35] <ogra> no ui at all :/
[17:37] <ogra> 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] <ogra> *whine*
[17:43] <ogra> ah, i was trapped by recommends
[17:43] <ogra> still over 30M
[17:53] <ogra> superm1, ok, its trying to start but breaks then with subprocess.Popen(proc)
[17:54] <ogra> using 2.1.16 btw
[17:54] <superm1> ogasawara_, can you get a full BT?  It might have logged that BT to /var/log/oem-config.log already for you.
[17:54] <superm1> ogra, ^
[17:55] <ogra> i'll try to ... i sadly cant copy-paste from qemu
[17:55] <superm1> you should be able to at least scp that log file out hopefully to a real machine
[17:55] <superm1> or use something like pastebinit to get it out on the internets
[17:55] <ogra> yeah, indeed
[17:56] <ogra> woah
[17:56] <ogra> seems to be a pygtk issue actually
[18:08] <ogra> superm1, just fyi ... http://paste.ubuntu.com/371902/ i doubt its ubiquitys fault
[18:09] <superm1> ogra, yeah i agree.  have fun debugging that :)
[18:10] <ogra> heh
[18:10] <ogra> i'll probably give up on the UI part ... it pull sway to much into the rootfs anyway since the merge
[18:10] <ogra> the old oem-config was far better suited for that usecase
[18:11] <ogra> (which is why it was initially added to the spec :) )
[18:14] <jono> bdmurray, ping?
[18:14] <jono> ignore my msg :)
[18:19] <superm1> 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] <ogra> yeah
[18:20] <ogra> seems i need to have a lot of debconf stuff set in advance though
[18:20] <ogra> currently thats a plain debootstrapped system
[18:21] <ogra> superm1, do you know if we have any docs what oem-config expects or do i need to dig through the code ?
[18:22] <superm1> ogra, for the debconf ui, i've no idea.  for the other UI's, nothing needs to be set in advance normally
[18:22] <ogra> ok
[18:22] <ogra> well, then i'D expect the same for debconf actually
[18:22] <ogra> i'll wait until ev is back
[18:37] <apw> pitti, whats happening with the states on bug# 446146
[18:37] <apw> bug #446146, you and JFo seem to be arguing :)
[18:37]  * apw slaps ubottu 
[18:37] <apw> be more patient ubottu
[18:38] <JFo> heh
[18:38] <JFo> I keep getting timeouts too
[19:06] <czajkowski> be nice to the bot
[19:11] <smoser> 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] <smoser> 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] <smoser> (debian/schroot-common.install has 'debian/install/usr/share/locale usr/share')
[19:17] <smoser> i notice now the libsbuild-doc package is also not built
[19:18] <maxb> sbuild is commonly used for buildds. Therefore, I would be unsurprised if it defaulted to not building architecture=all packages.
[19:19] <smoser> maxb, thank you
[19:45] <geser> 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] <smoser> geser, yeah maxb suggested above, and was correct.  i had to run with --arch-all
[19:46] <smoser> but thank you
[19:46] <dupondje> tsimpson: geser: https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035
[19:46] <dupondje> added a new patch
[19:52] <geser> kees: Hi, thanks for your last commit to ubuntu-dev-tools. would you consider it as a fix for bug #518574?
[19:52] <kees> geser: oh, hrm
[19:52]  * kees reads
[19:53] <kees> geser: yeah, I guess it does.  I will adjust my commeit
[19:53] <kees> s/eit/it
[20:03] <dupondje> geser: could you check if its fully correct now ? :)
[20:03] <kirkland> slangasek: ping
[20:03] <slangasek> kirkland: hi
[20:03] <kirkland> slangasek: http://paste.ubuntu.com/371989/ <--- that's the pam patch I need for the improved ecryptfs functionality
[20:03] <kirkland> slangasek: i'm looking for guidance from you on the order of operations here
[20:03] <kirkland> slangasek: i'm prepping an email to upstream PAM
[20:04] <kirkland> slangasek: in what order should the patch be accepted, before I can upload it to Lucid?
[20:04] <kirkland> slangasek: ie, is upstream and debian acceptance pre-reqs for getting this patch into Lucid's pam soon?
[20:04] <geser> dupondje: looks ok as far as I can tell, you just need to wait for a main sponsor now
[20:05] <dupondje> geser: ok thx for looking :)
[20:05] <slangasek> 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] <kirkland> slangasek: hrm
[20:07] <kirkland> slangasek: this bit was written with dhowells
[20:08] <kirkland> slangasek: basically, we need pam_keyutils to establish the session keyring
[20:08] <kirkland> slangasek: whereas now, we're using the user keyring
[20:08] <slangasek> why are we expecting the session keyring to be established before the PAM session is opened? :)
[20:08] <dupondje> 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:09]  * kirkland thinks
[20:10] <slangasek> 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] <kirkland> slangasek: dhowells says that those are auto-reaped
[20:10] <slangasek> ok
[20:11] <kirkland> slangasek: okay, so pam_ecryptfs inserts the key in its pam_sm_authenticate()
[20:11] <kirkland> slangasek: which means the keyring must exist at that point
[20:11] <slangasek> why does it do that, rather than waiting until pam_sm_open_session() itself?
[20:12] <kirkland> slangasek: well, we need the passphrase the user actually entered
[20:12] <kirkland> slangasek: to unwrap the mount passphrase
[20:12] <slangasek> yes; which can be captured in the auth stage and stored as module data until the session stage
[20:12] <kirkland> slangasek: interesting...
[20:13] <slangasek> otherwise, what happens with a session-less service when you have pam_ecryptfs configured?
[20:13] <kees> dupondje: was that meant for someone else?
[20:14] <kirkland> slangasek: looking at the code ...
[20:14] <dupondje> kees: no, saw you had some change in aptitude. Just need somebody that wants to approve the patch.
[20:15] <kirkland> slangasek: pam_ecryptfs's session handler just does the mount, if necessary, and if possible
[20:15] <kirkland> slangasek: it expects the necessary keys to already be loaded
[20:15] <slangasek> well, I'm questioning that assumption :)
[20:15] <kirkland> slangasek: which happens at the auth stage
[20:15] <slangasek> i.e., why should the kernel setup be done at the auth stage, if it's really tied to a session
[20:16] <slangasek> consider a sessionless service that runs multiple user authentications in a single process
[20:16] <slangasek> (web services may fit this model)
[20:16] <slangasek> (or POP?)
[20:19] <kirkland> slangasek: hmm, so you're saying don't load the keys *unless* we're in a session
[20:19]  * slangasek nods
[20:19] <kirkland> slangasek: okay, well, i can't find a good argument why not
[20:20] <kirkland> slangasek: i think this originally landed in pam_auth so that we would have access to the password
[20:20] <slangasek> I think pam_krb5 is probably a good example to follow, here
[20:20] <kees> dupondje: oh, yeah, that was just an ABI bump.  check with mvo
[20:20] <kirkland> 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] <dupondje> kees: will do if he's around here somewhere :)
[20:20] <slangasek> (though I think pam_krb5 uses kerberos APIs to carry the creds between auth and session, instead of the PAM APIs)
[20:20] <kirkland> slangasek: i might need a good second set of eyes
[20:21] <slangasek> kirkland: I have several in my drawer
[21:23] <kirkland> cjwatson: any objections to this grub2 patch?  -> http://paste.ubuntu.com/372039/
[21:25] <jcole> ﻿﻿﻿where is the global firefox settings file? i want to set the global homepage
[21:28] <cr3> when I run debuild: 1. I get .bzr in the resulting tarball; 2. the top directory is $(basename $(pwd)), whereas it should be name-version. how can I solve these problems?
[21:31] <RAOF> cr3: It sounds like you probably want to run “bzr bd” rather than debuild.  Are you building from a bzr packaging branch?
[21:34] <cr3> RAOF: I'm not sure what is a bzr _packaging_ branch, it's just a bzr branch which happens to contain a debian directory for packaging purposes if that's what you mean
[21:35] <RAOF> cr3: Yeah; it's source package you grab via bzr.  You want to use bzr builddeb (or its alias, bzr bd) in the same way that you'd use svn-buildpackage or git-buildpackage.
[21:39] <cr3> RAOF: but this package doesn't necessary have an upstream version, so looking for upstream tarball won't work
[21:40] <RAOF> bzr bd will either (a) find a nice revision property to tell it how to construct a tarball, or (b) you can use --split to create an .orig.tar.gz from the source tree.
[21:50] <smoser> kees, ping.
[21:53] <kirkland> slangasek: dhowells joined us here to help answer some of your hard pam questions for me
[21:53] <kees> smoser: hi! what's up?
[21:53] <smoser> before knowing any better, i modified mk-sbuild-lv to support setting up schroot mounts with union-type=aufs
[21:53] <slangasek> dhowells: hello :)
[21:53] <dhowells> hi
[21:54] <smoser> (i say knowing any better because i think there might be already existing tools, but mk-sbuild-lv was all i was familiar with, and it had more smarts than i wanted to copy)
[21:54] <smoser> would accepting a patch be possible ?
[21:54] <smoser> or would you be uninterested in such a thing, kees
[21:54] <smoser> http://paste.ubuntu.com/372069/
[21:55] <slangasek> dhowells: I've posed the argument to kirkland that neither pam_keyinit nor pam_ecryptfs should be messing with the session keyring in the auth stage, because there are valid use cases for sessionless authentication where we don't want the PAM stack to be modifying the keyring of the calling process
[21:55] <dhowells> slangasek: sounds reasonable
[21:56] <slangasek> dhowells: and have proposed that he stow the creds in the auth stage with pam_set_data() and retrieve them in the session stage, at which point this patch to pam_keyinit is unnecessary
[21:56] <dhowells> slangasek: the main thing about pam_keyinit is that it needs to be invoked before any PAM module that wants to create keys and hang them off the session keyring
[21:57] <dhowells> slangasek: but it has to be called after "session pam_selinux open blah"
[21:57] <slangasek> interesting
[21:57] <slangasek> so doing this in the auth phase is definitely wrong...
[21:58] <dhowells> otherwise the keys and keyrings created by pam_keyinit, pam_ecryptfs, etc., don't get correct security labels
[21:58]  * slangasek nods
[22:01] <kees> smoser: one sec, I'll read that
[22:01] <dhowells> slangasek, kirkland: in fact, in can be argued that pam_ecryptfs shouldn't be reading the encrypted key files from the user's homedir until after pam_selinux has set the security label
[22:02] <smoser> kees, my feelings wont be hurt if you're not interested, prior to doing it i wasn't aware of a sbuild-createchroot.
[22:03] <kirkland> dhowells: that's possibly true; selinux never entered my consideration when doing the encrypted-home-directory work
[22:04] <smoser> does it seem to anyone else that schroot does not read files in /etc/schroot.conf/chroots.d/ like it says it does?
[22:05] <smoser> (err... chroot.d)
[22:06] <kees> smoser: on a call, so a bit lagged
[22:06] <smoser> no problem.
[22:09] <kirkland> slangasek: dhowells: so let me see where this leaves us ...
[22:10] <kirkland> slangasek strongly believes that we're doing stuff in auth that we should be doing in session
[22:10] <kirkland> burden is on kirkland to convince slangasek otherwise ;-)
[22:11] <kees> smoser: interesting.  I didn't know that schroot grew a "union-type".
[22:11] <smoser> in 1.4 and it is "preferred"
[22:11] <smoser> its faster and smaller than lvm
[22:12] <kees> very interesting.
[22:12] <persia> kees: If you're deeply interested, I ought have a refactoring that generates a mk-sbuild-tgz in a couple more hours.
[22:12] <persia> (and I'd appreciate your review)
[22:13] <kees> persia: does schroot handle tgz sanely (i.e. a target named -source that updates the tgz?)
[22:13] <kirkland> dhowells: i can *try* to move my pam_ecryptfs stuff to the session bit
[22:13] <persia> If you set union-type=aufs, to my understanding.  I'm still testing locally
[22:14] <kirkland> dhowells: slangasek: but i have no idea yet how to move the cleartext login passphrase from the auth to the session (will need to look at krb5 per slangasek)
[22:14] <smoser> kees, that was my understanding also.
[22:15] <smoser> i believe that you can even hvae a loopback filesystem as the source for a union type
[22:15] <kees> smoser: cool, yeah, I like this.  persia: I'm interested, for sure.
[22:15] <smoser> if you didn't like the filesystems sitting in /srv/chroots unpacked
[22:15] <slangasek> kirkland: pam_set_data() in auth, pam_get_data() in session will do the trick (taking care to set an appropriate cleanup function...)
[22:15] <kees> smoser: okay, let me shake this patch out a bit (there is at least one little bug) and I'll commit it.
[22:15] <persia> kees: OK.  I'll be breaking for food soon, but ought be able to push a branch for review by somewhere shortly after midnight UTC.
[22:15] <smoser> kees, note the rename
[22:15] <dhowells> slangasek: is there a chance that someone can steal the data?
[22:16] <smoser> if you think thats right.
[22:16] <kees> persia: let me get smoser's change in first, since that'll have the framework for "chroot type" in it.
[22:16] <persia> smoser: I'm putting tarballs in /var/lib/schroot/tarballs/ by default.  Does that also make sense to you?
[22:16] <kees> smoser: yeah, I think that's fine.
[22:16] <smoser> persia, i picked /srv/chroots, just as that was what was in the examples in man schroot
[22:16] <smoser> var/lib sounds reasonable.
[22:16] <kees> persia: that sounds good to me.  I'd like the chroots to be under there too (instead of /srv/*)
[22:17] <smoser> we can definitely have it support tgz, directory, and lvm by users preference.
[22:17] <kirkland> slangasek: i'll give that a shot
[22:17] <persia> smoser: Looking at your patch, I think we've been doing the same thing for the past while :)
[22:17] <kirkland> slangasek: assuming that works, then keyring creation should happen in the session
[22:17] <smoser> well, good, then i *completely* wasted my time :)
[22:18] <slangasek> dhowells: the same chance that someone would intercept the password while it's being input
[22:18] <smoser> persia, since you're kind of playing there, i would appreciate a sanity check...
[22:18] <smoser> for me, contrary to doc, files in /etc/schroot/chroot.d/ are ignored
[22:19] <persia> smoser: I'll let kees review the patch, since he's had lots more experience hacking that script than I :)  I split the scripts and refactored, rather than adding, but I like your approach better.  One note is that you might pull the lvm2 install out of the initialisation, and have a `dpkg -l lvm2 || sudo apt-get install lvm2` run only in cases where an lvm snapshot is requested.
[22:23] <smoser> i figured out the chroots.d, seems like there is a filter applied to filenames there that i wasnt passing. sbuild::is_valid_filename was filitering it out.
[22:23] <smoser> i have to run
[22:24] <smoser> kees, if we're dusting off that script, we really should write entries into /etc/schroot/chroots.d
[22:24] <persia> What does that directory do?  I'm not finding it in the docs.
[22:28] <persia> smoser: You may also want to consider rebasing off the mk-sbuild-lv in lucid.  It's similar, but has a few other changes.
[22:29] <Caesar> yofel: ping
[22:29] <yofel> pong
[22:30] <Caesar> yofel: bug #381753, I just want to make sure that marking it Fix Released isn't going to cause it to be overlooked for Hardy
[22:31] <yofel> Caesar: not sure (that's why I nominated it), but the bug is fixed in Ubuntu since Jaunty so it *is* fixed
[22:31] <Caesar> ok
[22:31] <Caesar> I can provide a patch if it helps, it's laughably small
[22:32] <persia> Caesar: Please do, if you have one.  It may not affect the fix time, but having it in a state where it only requires review rather than requiring development tends to smooth the path.
[22:33] <Caesar> I don't have one, but at the time I looked at what the fix was, and it was a one-liner
[22:33] <Caesar> So I can produce one relatively easily once I revisit the problem
[22:40] <kapdia> hello
[22:40] <kapdia> which option do i use on a live cd to only install a minimal system
[22:41]  * kapdia can't access #ubuntu or #ubuntu-support
[22:41] <RAOF> I don't think you do - for that I think you need the alternate CD.  Also, not really a question for #ubuntu-devel; #ubuntu or #ubuntu+1 would be the appropriate venue.
[22:41] <kapdia> thx RAOF
[23:04] <johnm> could anyone tell me if something has changed re: users being able to setuid root recently? in that, I can't :)
[23:11] <slangasek> what do you mean, "setuid root"?
[23:12] <johnm> slangasek: as in, setuid32(0).. but I've worked it out now I think.. been racking through it for a while now and its just been getting frustrating ;)
[23:13] <slangasek> ehm, I don't know why you would expect a user to be able to call that
[23:13] <johnm> on a setuid binary?
[23:18] <slangasek> if it's on a setuid binary, then it's not the user calling setuid() :)
[23:22] <tlyu> but if it's a setuid binary, not _all_ of UIDs get set on exec...
[23:25] <johnm> indeed, but as an example I was setuit root on the binary and then called setuid() and it was failing, but it was an apparmor profile blocking it.
[23:25] <johnm> something I thought I'd disabled :)
[23:30] <slangasek> aha :)