[00:24] <slangasek> xnox: bug #1002277> mountall already fscks all filesystems before mounting, when it can and needs to
[00:25] <slangasek> xnox: for btrfs root, isn't the first problem going to be that fsck.btrfs isn't available in the initramfs?
[00:25] <xnox> slangasek: great, close it as invalid. From quick look at the source code, I didn't work it out. Then only some testing left on my part and we can have update btrfs package with fsck.btrfs in the initramfs ;-)
[00:25] <xnox> wait...
[00:25] <xnox> just wil fsck.btrfs
[00:26] <xnox> or is it...
[00:27] <xnox> nope it's not. And by the time you can access fsck.btrfs, your btrfs root is already mounted *sigh*
[00:27] <slangasek> right... but that's not a mountall issue, at least not until you have an event-based initramfs
[00:28] <slangasek> first problem is to solve fsck.btrfs not being in the initramfs
[00:28] <slangasek> but really, shouldn't we expect fsck.btrfs to be smarter?
[00:28] <slangasek> and be usable on a ro-mounted fs?
[00:30]  * xnox after skimming through neverending btrfs threads on CEPH mailing list, I wouldn't expect much
[00:31] <xnox> do we want fsck.btrfs for all initramfs or only for those who have it as rootfs?
[00:32]  * xnox btw current patched edition of fsck.btrfs in the WIP branch should do nothing and exit with 0 if the filesystem is mounted.
[00:32] <slangasek> s/expect/demand/, then ;)
[00:33] <slangasek> yeah, I think it definitely should only go in the initramfs when the rootfs is btrfs
[00:33] <slangasek> (rootfs or /usr partition)
[00:36]  * xnox from now own `rootfs' is a variable which stores a list of required partition(s)
[00:37] <psusi> xnox, the initramfs has no fsck of any kind... the root fs has always been mounted ro, then if fsck fixes things, you reboot, if not, you fsck the other filesystems and mount them
[00:38] <xnox> psusi: true, given a sensible filesystem. btrfs is special =(
[00:39] <psusi> xnox, how so?  last I heard btrfsck doesn't actually do hardly anything anyhow, and it is a design goal to never need it... i.e. just mounting the fs should recover from crashes, like ext3/4
[00:40] <xnox> Latest btrfs-progs (c. 26 Mar 2012)
[00:40] <xnox> btrfsck can now repair some forms of filesystem breakage
[00:40] <xnox> A new data recovery tool (btrfs-restore) is available. This program doesn't attempts to repair the filesystem, it only tries to pull files from damaged filesystems and copy them to a safe location. Also, the Btrfs filesystem checker (aka fsck) can now repair extent allocation tree corruptions (more repair modes in progress).
[00:41] <xnox> http://kernelnewbies.org/Linux_3.4
[00:41] <xnox> https://btrfs.wiki.kernel.org/index.php/Main_Page
[00:41] <slangasek> psusi: replaying the journal is not the only function of fsck for ext3/4
[00:42] <psusi> slangasek, right... but if the fs is so damaged that it can't be mounted, you probably need to boot from other media anyhow, and fortunately, that kind of thing almost never happens... so I'm not sure why you would want to put fsck in the initramfs
[00:43] <psusi> can't be mounted read-only anyhow
[00:45] <slangasek> psusi: the point isn't to fsck a fs that couldn't otherwise be mounted, the point is that once the btrfs is mounted (ro or otherwise) it's too late to fsck
[00:45] <psusi> btrfsck can't run on a ro mounted fs?
[00:46] <slangasek> correct, that's what we're discussing
[00:46] <psusi> ohh... that's a bug in btrfsck then...
[00:49] <slangasek> feel free to fix it? ;)
[00:49] <psusi> since it's still early beta, I'm sure it will get worked out ;)
[00:51] <psusi> if the kernel can manage to shrink a mounted btrfs filesystem while it is mounted, I'm sure btrfsck will figure out how to fsck it while mounted ro ;)
[01:39] <ritz> jasoncwarner_, ping
[03:00] <doko> hi
[03:46] <pitti> Good morning
[05:07] <mjr> running a local ubuntu-based derivative, why would do-release-upgrade not recognize that it's running on lucid/lts and therefore offer a lucid upgrade? lsb_release -a seems fine... it does offer maverick if Prompt=normal.
[05:08] <broder> mjr: lts -> lts upgrades aren't offered until the first point release of the new lts comes out (roughly 3 months after release)
[05:08] <broder> lucid users aren't being prompted to upgrade yet
[05:08] <broder> (though i believe they will if they pass -d to do-release-upgrade)
[05:10] <mjr> Right. Thanks, that was it. Silly me. Have to do some testing of the upgrade process and verify it works with our tunings, see.
[05:27] <micahg> @pilot in
[06:33] <hrw> hi
[06:34] <hrw> can someone take gcc-4.7-arm{el,hf}-cross out of NEW queue?
[06:40] <micahg> slangasek: what's the general position on SRUing for multiarch support?
[06:50] <pitti> micahg: we discussed it the other day, and deemed it ok for precise, with due care applied
[06:51] <pitti> micahg: as there were a few packages where it would really help (especially for third-party apps which still need the old gnomevfs or similar)
[06:51] <micahg> pitti: ok, are udebs supposed to be multiarched?
[06:51] <micahg> slangasek: unpin
[06:52] <pitti> micahg: I don't see how that would be useful
[06:52] <micahg> ok, that's what I figured
[06:52] <pitti> micahg: they might end up in /lib/<arch>/, but perhaps more as a side effect?
[06:52] <pitti> i. e. when configuring the package with that libdir, then they just end up that way in debian/tmp/, and I guess the udeb makes no special effort of moving them back
[06:53] <pitti> but we certainly wouldn't make a deliberate effort on multiarching them
[06:53] <micahg> right, but if the lib is being multiarched for other reasons, the udeb rides along for free?
[06:55] <pitti> yes, AFAICS
[06:55] <pitti> otherwise you'd have to modify their *.install files to say things like "lib/*/<name>.so lib/<name>.so" which is unnecessarily error prone
[06:55] <pitti> (and requires hardcoding the library name, too)
[06:56] <micahg> this udeb has files in /usr/lib for some reason
[06:57] <pitti> I don't know the policy enough to say whether they should be in /lib, or whether it doesn't matter
[06:58] <micahg> right, I don't know either :)
[06:58] <pitti> technically it seems to me that it doesn't matter, as for install environments we don't need to be concerned about a separate /usr/
[07:00] <micahg> heh, so, Debian has the udeb being installed in /usr/lib
[07:02]  * micahg follows Debian's lead
[07:07] <dholbach> good morning
[07:16] <dholbach> DMB folks: could it be that bencer is still missing in ~ubuntu-dev?
[07:17] <micahg> dholbach: there's some work involved still
[07:18] <dholbach> aha?
[07:18] <dholbach> so you're waiting on the packageset creation?
[07:18] <micahg> dholbach: but he'll get there (actions items are documented)
[07:18] <micahg> yeah
[07:18] <micahg> actually, he won't go in ubuntu-dev, but into a team which is a member of it
[07:18] <dholbach> ok - I was just wondering
[07:18] <micahg> I'll get it sorted this week
[07:19] <dholbach> great
[08:10] <micahg> pitti: do you know if static libs count as a shared library for use of ${misc:Pre-Depends}?
[08:11] <pitti> micahg: for Pre-Depends: multiarch-support ?
[08:11] <micahg> yeah
[08:12] <pitti> micahg: my gut feeling is "no", as these are only searched at build time
[08:12] <pitti> I'm not entirely sure whether gcc uses ld.so's lookup paths; if so, we need it, if not, we don't
[08:13] <pitti> that whole pre-depends thing is pretty much obsolete now post-precise anyway
[08:13]  * micahg saw that Debian didn't include it in libxkbfile
[08:13] <pitti> but we will still have some for Debian, as they didn't yet do a release with multiarch
[08:14] <micahg> this one is an SRU for precise (although I'm looking at another one for quantal ATM)
[08:14]  * micahg guesses he can hold onto these until morning
[08:14] <vibhav> Could https://bugs.launchpad.net/ubuntu/+source/munin/+bug/598385 and https://bugs.launchpad.net/ubuntu/+source/munin/+bug/1000678 be nominated for oneiric?
[08:15] <micahg> vibhav: looking
[08:15] <dupondje> pitti: dunno if you could add your recommendations on https://wiki.ubuntu.com/JeanLouisDupond/MOTUApplication ? :)
[08:15] <pitti> dupondje: sure! do you happen to have a list of packages that I sponsored for you?
[08:17] <micahg> vibhav: oneiric has a different version, are you sure it's affected?
[08:17] <dupondje> pitti: http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=*&sponsor_search=name&sponsoree=Jean-Louis+Dupond&sponsoree_search=name
[08:18] <vibhav> micahg: I cant see the fixed code in oneiric
[08:21] <micahg> vibhav: done
[08:21] <vibhav> micahg: thanks!
[08:23] <vibhav> jamespage: ping
[08:23] <micahg> vibhav: can I help you with something (currently piloting)
[08:24] <vibhav> micahg: Since the problem involves munin, munin-node and exim4 , shouldnt they be be affected too
[08:25] <vibhav> Im talking about LP: #598385
[08:25] <micahg> vibhav: not unless there's something to fix there
[08:25] <vibhav> ah
[08:50] <doko> siretart, ping
[08:50] <siretart> doko: hi
[08:58] <micahg> @pilot out
[09:08] <pitti> tseliot: good morning
[09:08] <tseliot> pitti: good morning to you
[09:08] <pitti> tseliot: it's working quite nicely now :) http://paste.ubuntu.com/1000413/
[09:09] <pitti> tseliot: i. e. driver lookup behind a nice upstream compatible API
[09:09] <tseliot> pitti: very nice :)
[09:09] <pitti> I also wrote a performance test case
[09:09] <pitti> performance of 1000 lookups in a single query ... [24 msec] ok
[09:09] <tseliot> pitti: wow, do you have a pull request too?
[09:09] <pitti> tseliot: that should be quite a bit faster than the 30 seconds or so current jockey takes to detect drivers
[09:10]  * tseliot nods
[09:10] <tseliot> :)
[09:10] <tseliot> excellent work!
[09:10] <pitti> tseliot: not yet, still test-building in a PPA, and I needed that aptdaemon upload to make the tests succeed
[09:10] <pitti> tseliot: but it's of course still far from a jockey replacement
[09:10] <pitti> just starting with the lower-level functionality
[09:11] <tseliot> pitti: yes, of course. It's still good progress though
[09:53] <c10ud> hello there, not sure if this is the proper channel (if not please tell me which is). I have an issue with pygi (i think) --ubuntu specific they tell me-- which leads the app to segfault. i send the report with apport but i don't know where it's stored. any help?
[09:54] <c10ud> pitti, sorry to ping you directly, please see above ^ (i think youre the mantainer?)
[09:54] <pitti> c10ud: I need some more details, I'm afraid -- which pacakge crashed?
[09:55] <c10ud> pitti it's not in the archives, we're porting our app (emesene) to gtk3
[09:55] <pitti> c10ud: they go to https://errors.ubuntu.com/ FYI
[09:55] <pitti> c10ud: ah, then it probably shouldn't have sent the report in the first place -- I guess it assigned it to "python2.7" then
[09:56] <c10ud> oh, i thought it opened a bug so we could see and comment out
[09:56] <pitti> c10ud: that's what happens during development releases, but not for stables any more
[09:57] <c10ud> anyway, Jose Rostagno (he sent you some pygicompat patches) says it works good in arch (he's the guy behind the porting) hence my "ubuntu-specific" thought
[09:57] <pitti> c10ud: what you can do is to install the apport-retrace package, then reproduce the crash, and when apport pops up, click on "Examine locally"
[09:57] <pitti> c10ud: this will throw you into a gdb session with all debug symbols available, so a "bt full" there would help quite a bit
[09:57] <c10ud> ok
[09:57] <pitti> c10ud: are you using python2 or 3?
[09:58] <c10ud> python2
[09:58] <c10ud> cool thing is, issue is random
[09:58] <pitti> c10ud: so, at this point it would be best if you could open a Launchpad bug against pygobject and attach a test case
[09:58] <c10ud> sometimes it crashes, sometimes it does not
[09:58] <pitti> sounds like garbage collection/ref count/transfer annotation issue
[09:59] <c10ud> this also appears: Gtk:ERROR:/build/buildd/gtk+3.0-3.4.2/./gtk/gtkstylecontext.c:739:timeline_finished_cb: assertion failed: (info != NULL)
[09:59] <c10ud> anyway i'll try the apport trick now
[10:00] <pitti> ah, please include that in the bug report
[10:00] <pitti> probably the ref count sometimes goes to zero and info gets freed (whatever info that is)
[10:04] <popey> bdmurray / didrocks I don't appear to be able to nominate bugs (like bug 1000577) for series precise..?
[10:04] <didrocks> doing
[10:05] <didrocks> popey: are you on the downstream task?
[10:05] <popey> also bug the "nominate for series" button disappears when I login to lp
[10:05] <popey> s/button/link/
[10:05] <didrocks> popey: first, the downstream task is unity, it should be bamf
[10:06] <didrocks> can you change that?
[10:06] <popey> can we hangout? :D
[10:07] <didrocks> sure
[10:09] <popey> invited..
[10:09] <c10ud> downloading LOTS of dbg packages, thank god i have a new hdd
[10:11] <pitti> c10ud: note, if you do this more regularly, have a look at "man apport-retrace" and its --cache argument
[10:12] <pitti> c10ud: oh, nevermind; the "Examine locally.." button uses ~/.cache/apport/retrace by default
[10:12] <c10ud> i hope it's the only one time :p
[10:12] <pitti> so it should be much quicker in subsequent times
[10:13] <c10ud> that's what python's for, right? leaving the dirty job to someone else ;)
[10:13] <pitti> hehe
[10:38] <c10ud> pitti, https://bugs.launchpad.net/ubuntu/+source/pygobject/+bug/1002792
[10:39] <pitti> c10ud: ah, so it's not a segfault, and really "just" the assertion; this makes it a bit easier
[10:40] <c10ud> ah i said segfault, whoops
[10:40] <pitti> c10ud: is that code public somewhere, or do you have another reproducer?
[10:41] <c10ud> unfortunately it's quite a big codebase, i'm not really sure on what's the culprit, i suspect the gif animation..
[10:41] <c10ud> anyway you can checkout git master and launch the app with USE_GI=1 set
[10:41] <c10ud> a sec
[10:42] <c10ud>  wget https://github.com/emesene/emesene/zipball/master
[10:42] <c10ud> extract
[10:42] <c10ud> USE_GI=1 ./emesene
[10:43] <c10ud> then select "dummy" session, put some random acc/pwd and connect
[10:44] <c10ud> since it doesn't happen everytime you can check autologin and ctrl+c from terminal when you see the fake contact list
[11:10] <xnox> Please accept/nominate bug 957494 for Quantal & 12.04.1
[11:12] <ogra_> xnox, done
[11:12] <xnox> ogra_: thanks ;-)
[11:41] <dupondje> slangasek: question about cryptsetup. You think its clean to include upstart scripts and add some if dist == ubuntu in debian/rules? Or just keep merging it?
[11:41] <ogra_> shouldnt dh_installinit DTRT actually  ?
[11:42] <ogra_> without having to special case dist in a maintainer script
[11:42] <ogra_> (or in rules)
[11:42] <dupondje> well in Ubuntu we need a init script (for stopping) and an upstart script for starting
[11:42] <dupondje> so other initlevels also
[11:43] <ogra_> why do youu need the init script for stopping ?
[11:43] <dupondje> to cleanly stop the crypt mapper
[11:44] <ogra_> the upstart job should be capable of doing so, no  ?
[11:44] <dupondje> upstart doesn't handle stopping afaik?
[11:44]  * xnox is interesting in cryptsetup. What bit of code are you discussing ? =))))
[11:45] <dupondje> xnox: init/upstart scripts :)
[11:46] <ogra_> what do you think the "stop on" directive is for then ? :)
[11:47] <dupondje> tought this was discussed before, and the conclusion was upstart could not handle it (yet).
[11:47] <dupondje> mmmm :)
[11:49] <ogra_> "stop on" and a script should be ablee to deal with most cases ... you can even define when exactly the script should run (pre-start, post-start, pre-stop etc)
[11:49] <dupondje> upstart doesn't send a signal on umount? Cause cryptsetup needs to stop between umount & for example lvm stop
[11:50] <xnox> dupondje: don't you want to listen on udev event in the upstart job in that case?
[11:53] <dupondje> for shutdown?
[12:01] <hallyn> is there a way in ubuntu's live-build to use packages from a ppa?  not seeing it in manpages anywhere
[12:02] <vibhav> Anybody from the ubuntu-sru tea,?
[12:03] <ogra_> hallyn, i think #linaro uses it all the time that way
[12:03] <hallyn> thanks, theni should ask there :)
[12:12] <xnox> robert_ancell: ?!
[12:12]  * xnox patch pilot dropped out from #ubuntu-devel =)
[12:14] <ogra_> he didnt use his belt !
[12:14] <superm1> hallyn: ubuntu-defaults-builder has an option
[12:15] <hallyn> superm1: interesting package
[12:18] <xnox> Can somebody please set https://code.launchpad.net/~dmitrij.ledkov/ubuntu/quantal/bogl/merge/+merge/104578 as rejected or something.
[12:18] <xnox> it is superseeded
[12:18] <xnox> by a new merge proposal
[12:20] <pitti> xnox: done
[12:20] <xnox> Pici: thanks.
[12:20] <xnox> pitti: thanks
[12:20]  * xnox damn autocomplete
[12:21] <vibhav> Could somebody check my SRU for oneiric at https://bugs.launchpad.net/ubuntu/+source/munin/+bug/598385/comments/10
[12:21] <seb128> xnox, if you pilot you can @pilot in
[12:22] <xnox> seb128: =) i'm not piloting, I'm adding my own items to the sponsorship queue ;-)
[12:22] <cjwatson> merges.ubuntu.com is back up
[12:22]  * xnox \0/
[12:22] <seb128> xnox, ok ;-)
[12:22] <geser> \o/ MoM is back
[12:23] <pitti> in the meantime, thanks to http://people.ubuntuwire.com/~lucas/merges.html for sustaining us so far
[12:24] <cjwatson> Let me know if you see any weirdness; the variables include new hardware, now running on precise, python2.5 -> python2.7, various code changes that were effectively undeployed for a while, and I had to roll out my change to make it set DEB_VENDOR while unpacking in order to get it to complete successfully
[12:24] <geser> cjwatson: in that case, can you take the note from the MoM start page out again?
[12:24] <cjwatson> Oh, yeah, I forgot about the index
[12:24] <cjwatson> done
[12:25] <cjwatson> I'll do a timing run shortly, but I think it should manage to complete more frequently now as well
[12:25] <vibhav> doesnt MoM stand for Merge-o-Matic?
[12:25] <cjwatson> Yes
[12:25] <vibhav> ok
[12:28] <dupondje> cjwatson: GREAT! :)
[12:56] <pitti> apw: is linux-firmware-nonfree in some git repo, or can I hack on it?
[12:57] <pitti> apw: I'd like to add a script to debian/rules that iterates over all modules, picks out their firmware:, and add the module's modaliases to the package's Modaliases: package header
[12:57] <pitti> apw: (for the firmware files shipped in l-f-nonfree)
[12:58] <pitti> apw: that fits into our current way of driver installation and gets rid of special-casing it
[13:01] <dupondje> pitti: don't forget my endorsment please :) Want to drop alot of merges in the pipeline soon :)
[13:01] <pitti> dupondje: it's on my list
[13:02] <dupondje> ok thx
[13:10] <apw> pitti, blimey ... erm ... i don't recall ever seeing a repo for it no, it would be tgardner who would know for sure, but as there isn't one on zinc i'd say its 95% likely not
[13:10] <pitti> apw: ok, then I'll just use the normal UDD branch
[13:11] <apw> pitti, if there is someone will have to figure it out :) and clean up after you, and i'll blame tim :)
[13:21] <vibhav> the patch pilot is not online :(
[13:21] <pitti> dupondje: sent now
[13:22] <pitti> vibhav: yes, Robert is in Australia and apparently forgot to sign off here before going to bed
[13:22] <vibhav> :(
[13:23] <dupondje> thanks!
[13:23] <robert_ancell> @pilot out
[13:24] <seb128> confusion cleared ;-)
[13:24] <pitti> lol
[13:24] <pitti> seb128: nice trick :)
[13:24] <vibhav> wut?
[13:24]  * vibhav waits for another patch pilot to sign in
[13:24] <seb128> vibhav, the bot doesn't do any smart authentification, you can change nick to change the topic
[13:25] <Laney> can't you just edit the topic?
[13:25] <Laney> @pilot in
[13:25] <vibhav> oh
[13:25] <seb128> vibhav, the calendar says you want barry
[13:25] <Laney> @pilot in
[13:25] <Laney> @pilot out
[13:25] <Laney> :P
[13:25] <pitti> cjwatson: out of interest, why do we need the less delta still? (gz data compression)
[13:26] <pitti> Laney: what was that about?
[13:26] <seb128> Laney, oh ok, I though the topic was locked down
[13:26] <Laney> just testing the bot, sorry for spam
[13:26] <seb128> i.e it used that you needed to be op or registered to be able to change it
[13:26] <xnox> Laney: is that you done with piloting for today? =)
[13:26] <Laney> ah, no
[13:26] <Laney> xnox: I'll send my report now!
[13:27]  * vibhav sits in the corner
[13:27] <pitti> Laney: you know it says "4 hours", not "4 seconds", right? :-)
[13:30] <cjwatson> pitti: breaks debootstrap
[13:31] <pitti> cjwatson: ah, our debootstrap covers less? curious, it's important/not-essential
[13:31] <cjwatson> pitti: debootstrap installs prio required/important by default
[13:32] <cjwatson> --variant minbase is prio required + apt
[13:33] <ogra_> +apt ?
[13:33] <ogra_> i thought it was -apt
[13:34] <pitti> cjwatson: thanks
[13:35] <cjwatson> ogra_: it's +apt
[13:35] <ogra_> i thought adam had to hack that in for -core ... but apparently i misunderstood
[13:40] <xnox> is acceptable to request sponsorship reviews from ubuntu-foundations-team for some of my sponsorship requests? e.g. sudo, btrfs-tools, mdadm
[13:47] <vibhav> When the Debian Import Freeze Happen?
[13:47] <ogra_> look at the release schedule ?
[13:48] <geser> vibhav: around June 21st
[13:58] <chrisccoulson> can we exterminate powerpc yet? :-D
[14:09] <vibhav> jamespage: ping
[14:10] <cjwatson> Eek, I'm TIL on sendmail, that was careless of me
[14:17] <directhex> why is sendmail still shipped? i can't imagine anyone would *want* to maintain it, and the kind of person who wants to maintain sendmail should really be sectioned
[14:18] <cjwatson> the Debian maintainer apparently wants to maintain it
[14:20] <ScottK> We'd need libmilter in any case for postfix.
[14:20] <ScottK> So you can't kill it all off regardless.
[14:21] <cjwatson> Anyway as a general rule I find thinking about removals inordinately stressful compared to just fixing things ...
[14:23] <vibhav> Can https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/644578 be nominated for oneiric?
[14:24] <vibhav> I mean the Ubuntu bug
[14:24] <vibhav> bdmurray: ^^^
[14:25] <vibhav> This was apparaently fixed in precise
[14:25] <dupondje> cjwatson: on the MoM, check samba4. Package is in sync for 3 weeks with debian, but still it shows the Precise version in teh MoM page.
[14:27] <cjwatson> In fact it's showing the oneiric version.
[14:27] <cjwatson> I'll have a look, thanks.
[14:28] <dupondje> hmz indeed :) thanks for looking
[14:43] <vibhav> :(
[14:43] <didrocks> barry: hey
[14:44] <didrocks> barry: do you know if we have any package in main that can convert some pyrex syntax to C? (there is cython that we used but it's in universe and the build-dep should be in main for my specific case)
[14:54] <barry> didrocks: off hand, no unfortunately.  i wonder if you can convert it and commit the converted code to the package?
[14:54] <didrocks> barry: there is this pyrexc command line, isn't it? from the man, I don't see the difference with cython?
[14:56] <barry> didrocks: the cython faq has some answers: http://wiki.cython.org/FAQ
[14:56] <hrw> can someone take gcc-4.7-arm{el,hf}-cross out of NEW queue?
[14:57] <tmus> during boot, what operation should cause pam_start session to be called? - i've added pam_limits.so to /etc/pam.d/common-session, but limits does not appear to be applied for services started automatically during boot AND running as root... Am I miserably wrong here?
[14:57] <tmus> tested on lucic btw
[14:57] <tmus> lucid even
[14:59] <didrocks> barry: ok, so fortunately, the binding only use the pyrexc syntax and we can switch to it
[14:59] <barry> didrocks: cool
[15:00] <didrocks> I'm quite confident, the upstream compiz source used to use pyrexc and it seems to have switch for no other reason than you can "import cython" in setup.py
[15:01] <barry> didrocks: what are they using from the cython module?
[15:02] <didrocks> barry: if I grep -ri cython *:
[15:02] <didrocks> setup.py:    from Cython.Distutils import build_ext
[15:02] <didrocks> setup.py:            from Cython.Compiler.Main import compile as cython_compile
[15:02] <didrocks> setup.py:            cython_compile ("src/compizconfig.pyx")
[15:02] <didrocks> and that's it
[15:02] <didrocks> so I think they are in fact just using pyrex
[15:03] <barry> ah
[15:04] <jamespage> vibhav, pong
[15:06] <slangasek> dupondje: please just keep merging it for now.  Upstart support should go upstream to Debian in the next month or so
[15:06] <dupondje> slangasek: debian goes upstart also ?
[15:07] <slangasek> Debian will have upstart support
[15:07] <hrw> dupondje: debian also has upstart package ;)
[15:07] <ogra_> depends on the package maintainer i would say :)
[15:07] <ogra_> if he listens to people filing bugs about missing upstart support :)
[15:08] <cjwatson> dupondje: ah, it's because it gets a bit confused by what it perceives as removals, because samba4 isn't in testing
[15:08] <hrw> ~curse bluez for failing installation when it can not start
[15:08] <cjwatson> dupondje: the sanest fix/workaround is probably to just switch MoM back over to unstable, so I'll do that
[15:08] <dupondje> ok :)
[15:09] <dupondje> slangasek: but after that we can just include upstart script in debian? What about the init script that is used now to stop?
[15:10] <slangasek> dupondje: some tuning may be required
[15:11] <dupondje> but i'm right we can't use upstart atm to stop cryptsetup?
[15:13] <slangasek> dupondje: I believe that's correct, we currently don't... why do we care about stopping it, though?
[15:15] <dupondje> to correctly close the handle, so lvm etc can also be stopped.
[15:16] <ogra_> hmm, does upstart prse "emits" from sysvinit scripts ? would be a one line change to add something to emit that info to umountroot
[15:16] <ogra_> *parse
[15:17] <slangasek> we don't stop lvm either :)
[15:17] <slangasek> we unmount filesystems, which TTBOMK is the only part we have to tear down before reboot in order to protect data
[15:19] <dupondje> So it should be safe to just remove the init script (which only is there for stopping atm in ubuntu)
[15:20] <slangasek> dupondje: which init script do you mean?
[15:21] <mvo> slangasek: just fyi, the quantal apt merge is prepared in the apt bzr ubuntu branch (just mentioning it to avoid duplication of effort)
[15:22] <dupondje> slangasek: now we have: cryptdisks-early & cryptdisks (init scripts) and cryptdisks-enable & cryptdisks-udev (upstart)
[15:37] <vibhav> jamespage: Ive created a SRU for oneiric, would you like to see it?
[15:37] <jamespage> vibhav, for munin?
[15:39] <vibhav> jamespage: yeah
[15:40] <mterry> Is anyone familiar with FTBFS errors like "error: inlining failed in call to always_inline 'vsyslog': function not inlinable" with quantal's compiler?
[15:45] <bdmurray> could some lptools hacker merge my branch? https://code.launchpad.net/~brian-murray/lptools/grab-descriptions/+merge/106469
[16:07] <slangasek> mvo: apt> great, thanks :)  and good to see apt is updated in unstable as well :)
[16:08] <slangasek> dupondje: right; so it's probably safe to remove those init scripts, but also not necessary in Ubuntu... and as we wouldn't be removing them in Debian that would probably be introducing more delta than we need to
[16:10] <mvo> slangasek: yeah we are pretty close to upstream again, if I don't see any regression on my box I will upload tomorrow or the day after tomorrow
[16:49] <jono> hey folks
[16:49] <jono> quick question
[16:50] <jono> in my app I would like to allow the user to start a process when they log in
[16:50] <jono> what is the best way of doing this on Ubuntu?
[16:52] <mlankhorst> jono: just follow standards :-)
[16:52] <jono> mlankhorst, what are the standards?
[16:52] <jono> :-)
[16:52] <jono> I have no idea how this is done
[16:52] <apw> cjwatson, i need to update the grub-gfxpayload-lists, but am struggling to find the master bzr branch for it, any idea where its at ?
[16:53] <cjwatson> apw: UDD - lp:ubuntu/grub-gfxpayload-lists
[16:53] <cjwatson> hmm, though it's apparently out of date there
[16:53] <mlankhorst> jono: xdg-ish
[16:53] <Laney> jono: http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html
[16:53] <Laney> jono: drop a desktop file in the appropriate directory
[16:54] <cjwatson> apw: ask the last uploader :)  that'd be RAOF
[16:54] <jono> Laney, aha!
[16:54] <apw> cjwatson, well at least i was looking in the right place ... OI RAOF wheres the lists at :)
[16:55] <apw> cjwatson, if the commit is missing, is it normal to reconstruct it and continue ?
[16:55] <mlankhorst> Laney: oh nice, was already looking
[16:55] <apw> cjwatson, on the assumption it was not found of course
[16:55] <cjwatson> apw: best to talk with RAOF first in case he can just push
[16:55] <cjwatson> but that's a fallback, yes
[16:55] <cjwatson> dunno why the importer didn't sort it out
[16:56] <apw> yeah who owns that so i can moan
[16:56] <jono> thanks Laney
[16:56] <cjwatson> apw: launchpad.net/udd
[16:56] <Laney> np
[16:56] <cjwatson> http://package-import.ubuntu.com/status/grub-gfxpayload-lists.html
[16:57] <cjwatson> which I think is the stock "if you push --overwrite, it gets upset" reason - maxb may be able to sort that out
[16:57] <apw> cjwatson, thanks
[16:57]  * cjwatson comments on the bug
[17:04] <maxb> hmm, hello
[17:06] <dupondje> slangasek: or we fix in debian package it only installs the upstart scripts on Ubuntu, then we can sync :)
[17:07] <slangasek> dupondje: fix what exactly?
[17:08] <dupondje> well ship the upstart files in the debian package also, but only install them on Ubuntu. No merge needed then
[17:08] <slangasek> no
[17:09] <dupondje> why not?
[17:09] <slangasek> why would you put the upstart files in the debian package and not ship them in the package?
[17:09] <ogra_> dupondje,you want to  install the upstart jobs in debian too
[17:10] <ogra_>  /etc/init/ will be a no-op if upstart isnt installed ... *if* it is installed you want the jobs to be used from there though
[17:10] <maxb> apw: I've overridden the importer's freak-out over someone replacing a version in the branch and initiated a new run
[17:10] <apw> maxb, thanks thats most helpful
[17:10] <dupondje> ogra_: well, if you install them in the debian package, there will be a depend on upstart
[17:11] <dupondje> which is not always wanted
[17:11] <slangasek> no, there won't
[17:11] <ogra_> there shouldnt
[17:12] <dupondje> so dh_installinit should be able to handle it correctly ? lets try it out
[17:16] <maxb> apw: Hm, it's done the silly thing where it rolls back all of cjwatson's commits and recommits them; it's because the bzr branch contains some files (.bzrignore, debian/bzr-builddeb.conf) which are not in the archiver
[17:20] <apw> maxb, hmmm that sounds like "andy don't touch it yet"
[17:23] <apw> maxb, the branch looks ok within some limits, is it as good as it is going to get?
[17:26] <dupondje> https://launchpad.net/ubuntu/+source/imvirt/0.9.4-2/+build/3509707 hmz :)
[17:32] <maxb> apw: Ah, yeah, don't touch it yet. I'm going to roll back what the importer did and fiddle
[17:41] <maxb> What fun#
[17:42] <maxb> Have run some SQL at the importer db to convince it that cjwatson's revisions can be trusted, really, and kicked it off again
[18:16] <apw> maxb, sounds like spagetti fun
[18:49] <xnox> Someone, please accept the quantal task in bug 978012 and assign to me ( dmitrij.ledkov )
[18:51] <infinity> xnox: We don't tend to nominate tasks for the development release.  An upload to the dev release will close the parent Ubuntu task.
[18:51] <xnox> infinity: ok, sorry.
[18:51] <xnox> (it's the sru-s only that matter, gotcha)
[18:57] <barry> kenvandine: \o/  i've removed python-egenix-mxdatetime from the porting spreadsheet.  thanks for merging it away :)
[18:57] <xnox> barry: =)))
[18:58] <kenvandine> barry, thank you!
[18:59] <kenvandine> barry, any more info on libpeas?
[18:59] <barry> kenvandine: not yet.  :/
[18:59] <barry> @pilot in
[18:59] <kenvandine> damn
[18:59] <dobey> libpeas is another very difficult problem to deal with
[19:00] <barry> dobey: what do you know about it?
[19:00] <dobey> barry: i know that porting every plug-in in the archive for anything in gnome is going to be painful :)
[19:01] <dobey> barry: i suspect making libpeas itself use python3 probably shouldn't be too hard. but porting all the plug-ins written in python for gedit/rhythmbox/whatever else, will be very tedious
[19:02]  * kenvandine wants to add a new dependency to it :)
[19:02] <barry> dobey: no doubt.  but if we have libpeas for both py2 and py3 (if that's even feasible), then i suppose we can at least limit it to all the plugins for a specific application
[19:03] <dobey> barry: i susepect that loading both python runtimes in the same process is just asking for a punch in the face :)
[19:03] <dobey> symbol conflicts all over the place
[19:03] <barry> dobey: a punch in the face if you're lucky :)
[19:04] <dobey> barry: so maybe it's not so bad, but you'd have to port everything in the default install at least
[19:04] <dobey> barry: and probably add new API to libpeas
[19:05] <barry> yeah.  sounds like fun
[19:05] <dobey> barry: the python loader is actually a plug-in to libpeas itself. so having a separate for python3 does seem feasible
[19:05] <dobey> but it would require new API i think, to say "enable loading of python3 plug-ins", and both loaders would have to explicitly prevent the other from loading
[19:08] <mterry> doko, are you familiar with FTBFS errors like "error: inlining failed in call to always_inline 'vsyslog': function not inlinable" with quantal's compiler?
[19:21] <seb128> cjwatson, ev: we have a diff in avahi over Debian to add udeb with this rational "so that we can use them for Eucalyptus integration in the installer." ... do you know if those are still needed? I guess the installer changed since we went to openstack
[19:25] <seb128> cjwatson, ev: context is https://code.launchpad.net/~laney/ubuntu/quantal/avahi/merge-0.6.31-1/+merge/105636 if you feel like commenting there
[19:26] <seb128> Laney, ^ fyi
[19:28] <stgraber> seb128: sounds like server team would know best. AFAIK we don't use that anywhere else
[19:29] <seb128> well, I figured that installers guys would know better, but yeah, I should have pinged you as well ;-)
[19:29] <cjwatson> seb128: I don't think it's still needed, but check rdepends (you might need to grep the d-i Packages file directly) and check with Daviey
[19:29] <seb128> Daviey, ^
[19:30] <seb128> cjwatson, thanks
[19:30] <Daviey> hmm, yeah.. it's still used. sorry. :(
[19:31] <cjwatson> ah, yes, maas-enlist-udeb
[19:32] <cjwatson> so the use of it just moved to the new cloudy hotness
[19:32] <Daviey> hawt
[19:32] <highvoltage> hot clouds make for stormy weather.
[19:33] <tgardner> bryceh, I've uploaded Quantal kernel and meta package backports to https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
[19:33] <seb128> Daviey, no worry, I figured I would check, any chance to lower delta over Debian ;-)
[19:34] <Daviey> seb128: i don't think the DM was ever asked to introduce a udeb fwiw.
[19:34] <seb128> cjwatson, I blame you a bit for not sending that change to Debian though, not sure if they would taken it but stil it would have increased chances to lower the delta between the distro
[19:34] <seb128> Daviey, seems not, I've checked the BTS, or the bug timed out or something
[19:35] <cjwatson> sure
[19:35] <Daviey> seb128: Well, based on situations such as, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673618 .. i'm not sure it'll gave taken grasp.
[19:35] <cjwatson> Daviey: oh please, not all Debian maintainers are the same faceless borganism
[19:36] <seb128> Daviey, that happens, but at least you knwo why you carry the diff ;-)
[19:36] <seb128> in the avahi case it seems that the request,patch was just never sent to Debian
[19:36] <Daviey> cjwatson: i know, using any opportunity i can to moan.
[19:36] <cjwatson> seb128: yes, my bad
[19:36] <seb128> Laney, maybe you could try to send it the avahi udeb patch to Debian since you are doing the merge?
[19:36] <cjwatson> I can't do it now, I can deal with it tomorrow if you like
[19:37] <seb128> cjwatson, no worry, it happens to all of us
[19:37] <seb128> cjwatson, no hurry but I would appreciate if Laney (who is doing the merge) or you would send it to the BTS
[19:38] <seb128> cjwatson, thanks
[20:15] <maxb> apw: I got called away from the computer, but it looks like the importer has done something sane this time
[20:15] <bryceh> tgardner, thanks
[20:16] <maxb> you'll see it has removed a couple of files in its commit - because they are not uploaded in the archive source
[20:16] <mlankhorst> bryceh: we should discuss with raof :-)
[20:17] <maxb> I'm not sure what we should be doing about that.
[20:17] <bryceh> mlankhorst, yeah we need to put our heads together on the packaging snafu's you ran into
[20:17] <apw> maxb, thanks ...
[20:19] <mlankhorst> bryceh: what time do you want to do it?
[20:20] <bryceh> mlankhorst, I've got a morning meeting with Intel (8am my time) so should be around early if you want to do it then
[20:20] <mlankhorst> utc please :P
[20:20] <bryceh> however raof won't be on until later (he usually comes on 1-2 hrs from now)
[20:20] <mlankhorst> yeah was thinking of just s taying awake a bit longer
[20:23] <mlankhorst> just ping me, off to do other stuff :-)
[20:25] <bryceh> yeah I'm going to be in and out the rest of the day.  Plan tomorrow ~2100-2200
[20:25] <bryceh> RAOF, ^^
[20:26] <mlankhorst> bryceh: ugh utc please XD
[20:26] <bryceh> mlankhorst, :-P that is utc
[20:26] <mlankhorst> oh sure
[20:27] <mlankhorst> ok with me, but keep in mind 22 utc is midnight for me :-)
[20:28] <bryceh> mlankhorst, well if you'd prefer, just meet with each of us separately
[20:29] <mlankhorst> bryceh: nah its fine, i just wont be as awake
[20:39] <slangasek> cjwatson: bug #1003100 makes me sad; I figured out how to use po2debconf for merging multi-paragraph description fields, and am rewarded by the appearance of mis-translations of variable names.  I don't suppose you have any ideas how to suppress this being offered as a source string in the .pot?
[21:14] <dupondje> barry: just a small thing about the canto package. I noticed indeed debian still had python-support build-dep. Just tought it wasn't a reason to keep the diff. As this change nothing to the functionality
[21:15] <barry> dupondje: we're more aggressive in switching to dhpy2 than debian is.  jwilk followed up on the debian bug about why that bd is there.  i'll switch it to dhpy2 for debian and file a separate bug.
[21:17] <dupondje> well the build-depend was just forgotten it seems, as they adjusted debian/rules in the last commits
[21:26] <barry> dupondje: do you mean a later commit switched to dh_py2?
[21:27] <dupondje> http://anonscm.debian.org/viewvc/python-apps/packages/canto/trunk/debian/rules?r1=7597&r2=7623 they switched here to default version
[21:27] <dupondje> not yet to dh_py2
[21:29] <cjwatson> slangasek: that's creative abuse of po-debconf, given that these aren't actually templates files :-)
[21:29] <slangasek> I know... ;)
[21:29] <slangasek> but it's the only thing I found that would do multi-paragraph translations correctly
[21:29] <slangasek> but #flag:translate! doesn't work here for whatever reason, boo
[21:30] <cjwatson> because you aren't using po-debconf to create the .pot file, but rather intltool-extract
[21:30] <slangasek> ah, hmm
[21:30] <cjwatson> this may be possible with i-e; let me cogitate a bit
[21:30] <slangasek> cool, thanks
[21:31] <slangasek> in the meantime I'm just going to slam a correct null translation in so we can get on with the SRU
[21:34] <cjwatson> slangasek: you might consider carrying the abuse all the way and using debconf-updatepo to generate a POT file for those files, which you then merge into the overall one
[21:34] <cjwatson> the Makefile integration would be exciting
[21:34] <slangasek> right
[21:34] <slangasek> I have considered that
[21:34] <slangasek> I just found it unspeakable so did not mention it ;)
[21:34] <cjwatson> but that way, I think #flag:translate! would actually work
[21:34] <slangasek> but yeah, it may ultimately be the correct thing to do here
[21:35] <cjwatson> the only other approach I can think of is a hacked intltool-extract wrapper that postprocesses the generated .h wrapper
[21:35] <cjwatson> I think that's probably even more foul
[21:35] <cjwatson> s/ wrapper$//
[21:35] <slangasek> heh
[21:36] <cjwatson> slangasek: it's possible it would be easier to have two separate sets of .pot/.po files
[21:37] <slangasek> hmm, point
[21:37] <slangasek> I think that's probably the winner
[21:37] <slangasek> will take me a bit to work through though, blah
[21:37] <cjwatson> might require a bit of rosetta bodging
[21:37] <slangasek> oh, really?
[21:37] <slangasek> might be simpler to just merge .pot then
[21:38] <cjwatson> only a tiny bit
[21:38] <cjwatson> somebody'd have to approve the new paths, basically, iirc
[21:38] <cjwatson> I think that's a good tradeoff for reduced build system insanity
[21:38] <slangasek> well, but then you also have the ongoing requirement to re-import two sets of .po files into the source
[21:39] <slangasek> so a little bit of build-time insanity we never have to look at again until the next time may be simpler overall
[21:40] <cjwatson> one set of .po files in Debian and the other not?
[21:40] <cjwatson> the flip side of *that* is that you might get to not have to merge one of those sets of .po files
[21:41] <slangasek> oh, well, I was planning on upstreaming this interface to Debian once it had settled out :)
[22:06] <cjwatson> dupondje: I've verified that samba4 is sorted, btw
[22:06] <cjwatson> (on merges)
[22:07] <dupondje> I saw already, thanks for fixing it :)
[22:07] <dupondje> 435 merges todo in Universe, alot
[22:38] <ScottK> broder: I gather you decided on changes in backports versioning at UDS.  I think this would be a nice topic for a mail to u-d-a (in addition to documentation updates).
[22:38] <broder> ScottK: this was a recommendation from cjwatson which seemed quite reasonable to me. but fair enough
[22:39] <ScottK> broder: I think it's a reasonable change, but it needs to be communicated.
[22:39]  * broder nods
[22:39]  * broder adds it to the ever-growing todo list :)
[22:43] <barry> zul: ping
[22:44]  * micahg would have liked an e-mail to ubuntu-backports@l.u.c
[22:47] <broder> yeah, that's reasonable; there probably should have been one
[22:48] <broder> i guess i was sort of waiting until we got the issues with backporter-executed backports sorted out
[22:48] <broder> and then i flaked on doing that
[22:55] <zul> barry: pong
[22:56] <barry> zul: hi.  i have a quick question about python-tz.  in 2011k-0ubuntu4 the test suite was enabled, but then it was disabled almost immediately in 0ubuntu5.  do you remember why it was re-disabled?
[22:57] <zul> barry: because it didnt actually testsuite didnt actually test python-tz
[22:57] <barry> zul: oh, that's unfortunate.  what was it testing? ;)
[23:00] <zul> barry: afaik timeones but i dont remember
[23:02] <barry> zul: cool, thanks
[23:02] <zul> np
[23:16] <barry> @pilot out