[02:04] <BenC> cjwatson: Good news: I had to use video=ofonly, but the latest quantal-live ISO boots and installs on my iMac G5
[03:51] <TheMuso> jbicha: Urm, stuff in proposed will eventually be let out...
[03:57] <jbicha> TheMuso: yeah, I just get impatient though :(
[04:04] <TheMuso> jbicha: Well in teh case of those packages I uploaded to proposed and that you sponsored into quantal proper, it means the archive admins will now have to reject those.
[04:04] <TheMuso> WHich will probably make a little more work for them, as they probably accept from proposed on mass.
[04:18] <pitti> Good morning
[04:18] <sshaw> hi, I'm trying to build f-spot from source on ubuntu 12.04 and when I run the autogen.sh script I get this error: autogen.sh: 10: autogen.sh: Syntax error: "(" unexpected
[04:19] <sshaw> the function it errors out on is check_autotool_version
[04:19] <pitti> ev: yes, I think we can move the dependency to apport-gtk and apport-kde
[04:19] <sshaw> am I missing some gnome devel package
[04:20] <sshaw> or should this question be better asked in a different channel? #ubuntu?
[04:21] <pitti> ev: pushed to packaging branch
[04:30] <slangasek> pitti: morning
[04:31] <pitti> ah, we're unfrozen, nice! /me releases his staged -proposed uploads
[04:31] <slangasek> pitti: there seems to be a problem with glib2.0 and gobject-introspection in quantal... the latter has been copied to quantal and has a dependency on the former, which is still in -proposed?
[04:31] <slangasek> heh :)
[04:31] <pitti> hm, I'm not sure why someone copied one without the others
[04:32] <pitti> I'll leave the linux bits, I don't know about their state
[04:32] <TheMuso> jbicha: ^^^
[04:32] <slangasek> pitti: well if you're about to fix it, then that's fine ;)
[04:32] <TheMuso> Goes back to what I was saying.
[04:33] <pitti> erk @ http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html
[04:33] <pitti> http://people.canonical.com/~ubuntu-archive/testing/quantal-proposed_probs.html looks slightly better, but I guess linux still needs some love
[04:36] <slangasek> TheMuso: which packages need rejecting?
[06:56] <dholbach> good morning
[07:00] <iulian> Morning dholbach.
[07:00] <dholbach> hey iulian
[07:07] <cc11rocks> 10th Debian patch forwarded : http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=cc11rocks%40yahoo.com (1 pending upload, 9 outstanding)
[08:13] <tkamppeter> Someone around who can sync qpdf from Debian Experimental for me?
[08:22] <pitti> syncpackage doesn't work for you?
[08:22] <pitti> tkamppeter: does it need a FF etc. exception? or just bug fxies?
[08:28] <mpt> E: /var/cache/apt/archives/libgnome2-bin_2.32.1-2ubuntu2_i386.deb: trying to overwrite '/usr/bin/gnome-open', which is also in package libgnome2-0 2.32.1-2ubuntu1
[08:29] <ev> pitti: cheers!
[08:29] <didrocks> mpt: fixed
[08:29] <tkamppeter> pitti, it is part of a bug fix, for https://bugs.linuxfoundation.org/show_bug.cgi?id=1063.
[08:30] <davmor2> pitti: why does every release hate my Sansa fuse so, It's showing up but as a usb drive rather than a music player
[08:30] <mpt> didrocks, thanks. Anything I need to do to repair before installing next updates?
[08:30] <didrocks> mpt: should be nearly available: https://launchpad.net/ubuntu/+source/libgnome/2.32.1-2ubuntu3
[08:30] <pitti> davmor2: not sure; when did this start breaking again? it's not like we do a whole lot of m-p-i updates..
[08:30] <didrocks> mpt: the easiest way is to download this .deb package: https://launchpad.net/ubuntu/quantal/+package/libgnome2-bin
[08:31] <cjwatson> pitti: tkamppeter doesn't have upload access to qpdf, according to edit-acl
[08:31] <davmor2> pitti: it's the first time I've plugged it into Quantal so not sure
[08:31] <pitti> cjwatson: ah, thanks
[08:32] <tkamppeter> cjwatson, pitti, as QPDF serves mainly for printing and usually needs to be updated if there is a printing problem or change it should perhaps be added to my list.
[08:32] <mpt> didrocks, doing that says "Failed to satisfy all dependencies (broken cache)."
[08:34] <didrocks> mpt: ok, I thought that stokachu didn't put a strong dep in his new faulty -bin package, so the easiest way is to wait the fix to be published (should be in less than 30 minutes) or download this -bin package, libgnome2-common and libgnome2-0 + dpkg them
[08:34] <pitti> tkamppeter: ok, libqpdf8 does not have many rdepends, just cups-filters and "qpdf"; I guess you tested those wit 3.0.2?
[08:34] <didrocks> from https://launchpad.net/ubuntu/+source/libgnome/2.32.1-2ubuntu3
[08:34] <mpt> didrocks, I think I can avoid restarting for 30 minutes. :-) Thanks.
[08:35] <didrocks> yw :)
[08:36] <tkamppeter> pitti, qpdf was introduced only for cups-filters. The change in the new Debian package is only support for injecting comments into the PDF output. These comments are needed so that pdftopdf can communicate with pdftops, which the old pdftopdf to prevent N-up coming out as N*N-up.
[08:37] <pitti> tkamppeter: synced
[08:38] <tkamppeter> pitti, thanks.
[08:51] <Daviey> cjwatson: hey, i wanted to see what you thought about adding X-Fields to .changes files?  Thinking of adding an optional jenkins based gate to the archive to do pre-testing before pushing to the archive.. but want extra data on knowing what to do.
[08:52] <Daviey> So for example, "X-ON-SUCCESS-UPLOAD: True" or something.. totally useless to LP/Ubuntu, but purely for Jenkins to know if it should push the signed upload to the archive
[08:53] <dholbach> can somebody please reject https://code.launchpad.net/~vericalcroft/ubuntu/quantal/liborigin/typo-fix/+merge/122417?
[08:53] <cjwatson> Daviey: Once all the pieces are put together, you should be able to use DEP-8 tests for that, and have that control movement from -proposed - XS-Testsuite: autopkgtest
[08:54] <cjwatson> Daviey: In the meantime, sure, it's fine to use random X- fields
[08:54] <dholbach> https://code.launchpad.net/~bmanojkumar/ubuntu/quantal/gluas/typo-fix/+merge/122388 too please
[08:55] <Daviey> cjwatson: Yeah, we were looking to run DEP-8 tests
[08:55] <Daviey> cjwatson: ok, thanks.
[08:55] <cjwatson> XS-Testsuite: autopkgtest is the "official" X- field for that
[08:56] <dholbach> https://code.launchpad.net/~bmanojkumar/ubuntu/quantal/eikazo/typo-fix/+merge/122386 too please
[08:56] <cjwatson> And (AFAIK) our jenkins instance is already configured to automatically run tests for any packages that include that
[08:57] <jamespage> cjwatson, Daviey and I are working on this idea of a build/test pipeline pre-upload
[08:57] <cjwatson> jamespage: it's on the foundations-p-upload-intermediary plan
[08:57] <Daviey> cjwatson: so it does that as a reaction to uploads in the archive, rather than pre-testing?
[08:58] <cjwatson> Daviey: Yeah, we were intending to do it based on -proposed
[08:58]  * Daviey reads foundations-p-upload-intermediary
[08:58] <cjwatson> dholbach: done
[08:58] <dholbach> thanks a lot cjwatson
[08:58] <dholbach> the next few I'll pastebin
[08:59] <dholbach> I'm cleaning up the should've-gone-to-Debian ones
[08:59] <dholbach> and the bug-fixing article with a few examples is online now too
[08:59] <dholbach> I hope that'll prevent things like this in the future
[09:00] <Daviey> cjwatson: What would make me a happy bunny is if -proposed had /some/ promise of stability, so people wanting real craziness can run that.. with people wanting a little more stability running the release pocket.
[09:00] <cjwatson> Daviey: That isn't going to happen
[09:00] <cjwatson> I mean not with any kind of automatic promise
[09:01] <Daviey> cjwatson: why can't we consider gating?
[09:01] <cjwatson> Pre-testing isn't going to help when you can't even install the packages
[09:01] <Daviey> cjwatson: I mean, catching the real obvious crap that people seem to miss
[09:01] <cjwatson> Because scope
[09:01] <cjwatson> This project is already a cycle late
[09:02] <Daviey> cjwatson: We wanted to do this from a server-dev POV anyway.. But i don't want to duplicate work either.
[09:02] <cjwatson> Also doing autopkgtest after upload allows you to parallelise the builds required
[09:02] <cjwatson> If you want to layer some independent stuff on top just for server, be my guest
[09:03] <cjwatson> Obviously people are entitled to test their uploads as much as they like before pushing them to the archive
[09:04] <Daviey> right, that was the plan.  If it worked out well, i'd like to welcome others to use the same infrastructure
[09:06] <cjwatson> In general, I don't want to cause all XS-Testsuite: autopkgtest to use pre-testing because autopkgtest at least sometimes involves building the source package, and I want to be able to do that in parallel with the official builds so that we don't slow everything down too much
[09:06] <cjwatson> If you can manage some arrangement where developers can opt in on an upload-by-upload basis (perhaps by using a different dput upload target), cool
[09:06] <Daviey> ok
[09:07] <Daviey> cjwatson: yeah, that was the plan
[09:07] <Daviey> so i dput to jenkins, and if it passes, jenkins dputs to the archive for me.
[09:10] <cjwatson> So that's fine certainly, I just don't want it to turn into "developers are being irresponsible if they don't use this" in time, since there may very well be good reasons not to
[09:10] <cjwatson> And I don't think it's useful to have an expectation of "<devel>-proposed is usable" since it's solely intended as a location for staging automatic checks
[09:12] <Daviey> sorry, you mean.. -proposed IS a location for staging automatic checks.. or shoudln't be thought as such?
[09:12] <cjwatson> It is such a location, and the checks are intended to be such that it really doesn't make sense to "want real craziness" and bypass them
[09:13] <cjwatson> It would only be interesting to run -proposed if there were a delay, in the style of Debian propagation from unstable to testing - but I think all concerned (especially those with some experience of operating the Debian testing migrator) have agreed we don't want to do that
[09:16] <dholbach> shadeslayer, do you think you can have a look athttps://code.launchpad.net/~andreagrandi/ubuntu/quantal/kdevelop-custom-buildsystem/typo-fix/+merge/121225?
[09:16] <xnox> Daviey: upload to $(devel)-proposed, wait for everything to build & settle, (autopkgtests run and give OK), (britney runs & says it's installable and ok to transition), (britney moves the batch into $devel)
[09:17] <xnox> Daviey: apart from we don't have the bits in () yet....
[09:17] <cjwatson> I believe we have "autopkgtests run and give OK"
[09:17] <xnox> ok. cool.
[09:17] <xnox> one down =)
[09:18] <xnox> cjwatson: And $devel-proposed, even if you have it enabled does not auto-install from it? (like debian-backports)
[09:21] <Daviey> xnox: well, that is just a priority.
[09:21] <xnox> true.
[09:28] <cjwatson> xnox: There's a work item for that somewhere
[09:28] <cjwatson> xnox: But see https://code.launchpad.net/~laney/launchpad/proposed-notautomatic/+merge/113921
[09:29] <cjwatson> bug 1016776
[09:30] <cjwatson> Laney: *poke*
[09:32] <Laney> cjwatson: argh
[09:32] <Laney> that
[09:33] <Laney> it got blocked because I didn't see what to refactor in the area for LoC
[09:33] <Laney> should look harder
[09:35] <dholbach> can somebody reject http://paste.ubuntu.com/1190481/?
[09:38] <cjwatson> Laney: Next time I see something obvious I'll punt it your way, how about that
[09:38] <cjwatson> Laney: The usual no-imagination answer is to rewrite some doctests as unit tests, which tends to come out positive
[10:05] <xnox> what is GUdev and how is it different from udisks?!
[10:35] <davmor2> guys quick query I have a virtual box install in place I've go to additional drivers and I expect to see the vbox addition drivers in there but there is nothing
[10:35] <davmor2> should it appear there like it did in jockey?
[12:19] <pitti> xnox: GUdev is a glib wrapper around libudev; it's got nothing to do with udisks
[12:20] <xnox> pitti: thanks. got mislead.
[12:20] <pitti> xnox: i. e. it provides GLib main loop integration and an "uevent" signal which you can connect to for listening to hw changes
[12:20] <pitti> xnox: udisks is the dbus system service for managing disks
[12:21] <xnox> pitti: any idea why does thunar ignores udisks --inhibit and automounts stuff which it (presumambly) sniffed from uevents.
[12:21] <xnox> ?
[12:21] <pitti> xnox: hm, I had expected thunar to call udisks as well -- I'm not aware of another d-bus system service which provides mounting
[12:22] <pitti> xnox: one thing that could happen here is that we are talking about udisks vs. udisks2?
[12:22] <xnox> well. ubiquity is run under udisks --inhibit, yet thunar jumps in the middle and automounts partitions breaking the installer "partition is mounted....."
[12:23] <pitti> xnox: in ubuntu we use udisks2 now, and thunar recommends that as well
[12:23] <pitti> xnox: ooh -- presumably ubiquity needs to inhibit udisks2, not udisks
[12:23] <xnox> pitti: i have no idea =) I added a call to xfconf-query to flip automount off. And I presume udisks --inhibit is udisks2
[12:23] <xnox> pitti: ah =)
[12:23] <cjwatson> Yeah, probably
[12:23] <pitti> no, /usr/bin/udisks is udisks1
[12:24] <cjwatson> http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2008-04-12-desktop-automount-pain.html *whine*
[12:24] <cjwatson> DEAR EVERYONE PLEASE STOP CHANGING THIS
[12:24] <xnox> OK, so we should try udisks2, udisks1, devkit-disks, hal........
[12:24] <pitti> let me figure out the current equivalent
[12:24] <xnox> pitti: any ETA on udisks3?
[12:24] <cjwatson> We can probably afford to drop devkit-disks now
[12:24] <pitti> yeah, and hal as well
[12:24] <cjwatson> I kept that just in case since the package was still around
[12:25] <cjwatson> Needs to work on all flavours/derivatives no matter what mad stuff they do ...
[12:25] <pitti> as soon as usb-creator and checkbox get ported, udisks will fall off the CD
[12:25] <xnox> pitti: I am hoping to do usb-creator tomorrow as part of Global Jam
[12:25] <xnox> together with re-packaging to use python3 by default
[12:33] <pitti> xnox: oh, is that the "Stop thunar from auto-mounting, above didn't work?!" part in ./bin/ubiquity-wrapper?
[12:34] <pitti> xnox: right, your r5638
[12:34] <pitti> xnox: so yes, that should be replaced with an udisks2 inhibitor
[12:34] <xnox> pitti: that does work, but it's not ideal. I really don't want to care about xfce/lubuntu/gtk/kde/etc changing the names of their options.
[12:35] <pitti> xnox: there is no direct counterpart for this in udisks2, but how about I put a script for this (/usr/lib/udisks2/udisks2-inhibit) into our udisks package?
[12:35] <pitti> "udisks2" package, I mean
[12:35] <xnox> pitti: can i stop that dbus service? and restarted when I am done?
[12:36] <pitti> xnox: my current idea was to change the polkit rules to only allow changes for root, and nobody else
[12:36] <pitti> i. e. what udisks --inhibit did as well
[12:36] <pitti> that seems to be the most robust solution to me
[12:37] <xnox> hmm... is that what udisks did?
[12:37] <pitti> not with polkit, but with --inhibit it only allowed operations from root
[12:37] <xnox> it seemed to me that it also made dbus calls to return "inhibited" or something like that.
[12:38] <xnox> pitti: that should do it.
[12:38] <pitti> yes, org.freedesktop.UDisks.Error.Inhibited
[12:38] <pitti> with the temporary polkit rule you'd get a "no permission" error
[12:39] <xnox> the desktop is started as $user with passwordless sudo, so users could still screw the installer over
[12:39] <pitti> well, with "sudo command" you can always screw the instlaler
[12:39] <pitti> no need to talk to udisks, you can jsut directly "sudo mount", etc.
[12:39] <xnox> pitti: yes, please add that wrapper =) and please don't change it's name =)
[12:39] <xnox> and we can improve it later.
[12:40] <xnox> pitti: it would be awesome to have a package $inhibit-any which will inhibit udisk, udisk2, hal and what not =)
[12:40] <xnox> pitti: cause I'd use it in ubquity, usb-creator not sure about others.
[12:41] <pitti> just curious that this hasn't been discovered in testing so far
[12:41] <xnox> oh it has been.
[12:41] <xnox> the first xubuntu bug is from ~2011
[12:42] <cjwatson> I think I saw a bug on Ubuntu desktop amd64 from this testing cycle as well
[12:42] <cjwatson> Though that might be cognitive leakage from something else
[12:42] <xnox> on Ubuntu Desktop we have default settings in nautilus to prevent automounting, similar to how I now did it for thunar
[12:42] <cjwatson> Anyway this is the sort of bug that's pretty hard to track down if you don't recognise it
[12:58] <pitti> xnox: so http://paste.ubuntu.com/1190766/ is my first working iteration
[13:00] <pitti> xnox: however, not quit happy with the trap yet; I'll change it to an absolutely failsafe approach
[13:00] <xnox> ok. looks good.
[13:04] <pitti> oh what would I give for a mount -t tmpfs -o overlay
[13:04] <ogra_> ++
[13:05] <BenC> $ dpkg -S /debian
[13:05] <BenC> ubuntuone-client-gnome: /debian
[13:05] <BenC> Is that a known issue?
[13:05] <ogra_> lol
[13:05] <ogra_> sexy
[13:05] <pitti> dobey: ^ yay easter eggs!
[13:06] <dobey> err?
[13:07] <Laney> indeed
[13:07] <ogra_> (the shiniest new quantal feature ...  we're turning your rootfs into a sourcepackage you just "dpkg-buildpackage -rfakeroot -b" in / and you get a full backup alread packaged !)
[13:07] <ogra_> y
[13:07] <pitti> it's a binary package, though
[13:08] <dobey> wtf
[13:08] <iulian> ogra_: Heh.
[13:08] <ogra_> well, once cjwatson added .deb support to grob that will just work ;)
[13:08] <ogra_> *grub indeed
[13:08]  * cjwatson checks 2.00 feature set
[13:08] <cjwatson> You never know
[13:08] <ogra_> **
[13:08] <ogra_> err *g*
[13:09] <pitti> c'est vendredi, évidemment
[13:10] <didrocks> pitti: tout à fait! :)
[13:13] <dholbach> haha
[13:15] <tkamppeter> pitti, can you upload cups-filters to Debian and to Quantal? Thanks.
[13:16] <dobey> yay dpkg :-/
[13:17] <dobey> is the beta release done now so i can upload to quantal?
[13:17] <pitti> dobey: yes; and you could have uploaded before as well (it'll just get caught in unapproved)
[13:18] <pitti> tkamppeter: in a bit, sorry
[13:19] <dobey> right; just don't see a mail to devel-announce
[13:19] <pitti> xnox: ah, my trick with using unshare -m won't help, I'm afraid (the running polkitd won't see that); so, just tmpfs then
[13:20] <dobey> BenC: is there a bug for that?
[13:23] <ogra_> dobey, the release mail was cross posted to -release and -announce
[13:23] <ogra_> probably your filter dropped into -release (as mine did)
[13:24] <cjwatson> Exactly why I don't believe in automatic deduplication of mails :)
[13:24] <dobey> ogra_: i don't think i'm subscribed to -release, and i am not filtering the -announce mail so it should just go into my inbox; but i only see the "beta freeze now in effect mail" :)
[13:25] <cjwatson> Mm, there's nothing on https://lists.ubuntu.com/archives/ubuntu-devel-announce/
[13:25] <ogra_> weird
[13:25] <ogra_> i definitely see it in the mail header
[13:25] <cjwatson> Oh, -announce, not -devel-announce, perhaps
[13:25] <pitti> oh, où est xnox?
[13:25] <ogra_> yup
[13:25] <cjwatson> There ought to have been a separate mail to -devel-announce that the archive is open again
[13:25] <cjwatson> Oh well
[13:26] <dobey> right, i was expecting to see the archive mail :)
[13:26] <pitti> udisks2-inhibit: http://paste.ubuntu.com/1190807/ ; ugly, but working
[13:26] <pitti> more pairs of eyes appreciated
[13:26] <ogra_> well, you could have guessed by the traffic on -changes that its open again :)
[13:34] <BenC> dobey: I just noticed it, so no bug yet
[13:37] <dobey> BenC: ok, should i wait for a bug or just fix it?
[13:37] <BenC> dobey: Would take longer to file the bug :)
[13:37] <stgraber> dobey: just fix it please
[13:39] <pitti> tkamppeter: erledigt
[13:40] <jamespage> @pilot in
[13:45] <pitti> xnox: http://anonscm.debian.org/gitweb/?p=pkg-utopia/udisks2.git;a=commit;h=93ccffecb0
[13:46] <xnox> pitti: (1.99.0-4) UNRELEASED
[13:46]  * xnox =(
[13:46] <pitti> xnox: yes, I just committed it; I want to fix another bug, and will then upload
[13:46] <xnox> pitti: ping me when it's in quantal =)
[13:46] <xnox> pitti: I will fix up ubiquity then.
[13:46] <tumbleweed> dobey: BTW, lintian complains fairly loudly about that. Maybe pay a little more attention to it in future? :)
[13:46] <pitti> xnox: jsut in case you want to test it locally already
[13:47] <xnox> ok.
[13:47]  * dholbach hugs jamespage
[13:47] <dobey> tumbleweed: complains where?
[13:47] <xnox> pitti: 'testing ubiquity locally' is not a 30s setup =)
[13:47]  * xnox is deep in partman right now.
[13:47] <tumbleweed> dobey: when you run it on the binary. do you run lintian in your test builds?
[13:47] <pitti> xnox: no worries; I just gave you the URL in case you were waiting for it
[13:48] <xnox> thank you =)
[13:48] <pitti> xnox: (I usually test such stuff in a live system and edit files in-place)
[13:48] <dobey> tumbleweed: it isn't run automatically?
[13:48] <Laney> lintian your _arch.changes file after test building
[13:48] <Laney> or configure your build environment to do it for you
[13:49] <tumbleweed> lintian is run by default when you use debuild. But debuild -S only builds a source package
[13:49] <dobey> pbuilder/sbuild don't run it by default?
[13:49] <tumbleweed> pbuilder has an example hook that runs pbuilder after the build. And in sbuild It hink it does it by default
[13:50] <Laney> no I think it's false by default
[13:50] <tumbleweed> no, not by default, but you just set $run_lintian = 1;
[13:54] <dobey> set it where? i found http://askubuntu.com/questions/140697/how-do-i-run-lintian-from-pbuilder-dist which suggests i have to make a new directory in my home directory and copy things to it, then set it as the dir to use in ~/.pbuilderrc
[13:54] <tumbleweed> that all sounds right
[13:55] <dobey> and i see dh_lintian being run in the build log for the package, but no complaints from lintian, on lp
[13:55] <tumbleweed> dh_lintian copyies lintian overrides into a binary package
[13:55] <tumbleweed> nothing else
[13:55] <tkamppeter> pitti, thanks.
[13:55] <dobey> so i guess the archive builders aren't running lintian by default?
[13:56] <tumbleweed> no. But we do have an external lintian lab: lintian.ubuntuwire.org
[13:59] <didrocks> can anyone rejects https://code.launchpad.net/~logan/ubuntu/quantal/notify-osd/debian-merge/+merge/118465? thanks :)
[13:59] <pitti> didrocks: *zap*
[14:00]  * didrocks hugs pitti
[14:00] <didrocks> (beautiful zap btw ;))
[14:00] <pitti> didrocks: do you say "fini" for this, BTW?
[14:01] <didrocks> I would say "fait" rather
[14:06] <ogasawara> @pilot in
[14:07]  * dholbach hugs ogasawara :)
[14:07] <dholbach> it seems to be pilot friday
[14:09] <hualet> hello, guys, i'm developing an app now, but there's some problem...how can i make the .gschema file installed  while install the software?
[14:12] <smoser> does this seem wrong to anyone: http://paste.ubuntu.com/1190880/
[14:13] <jamespage> dholbach, I seem to be following you though bugs
[14:13] <smoser> err... try http://paste.ubuntu.com/1190881/
[14:13] <smoser> actually, yes it does seem wrong
[14:13] <dholbach> jamespage, I stopped :)
[14:15] <smoser> anyone have thoughts on how to figure out why an apt-get dist-upgrade on a cloud-image would pull in all those packages ?
[14:18] <zul> mterry:  ping
[14:19] <mterry> zul, I see it  :)
[14:19] <mterry> zul, urllib3 right?
[14:19] <zul> mterry:  how did you guess? :)
[14:19] <mterry> zul, email wins the race against IRC
[14:19] <zul> mterry:  yeah sorry im not fast enough
[14:20] <smoser> there it is.
[14:20] <smoser> i think
[14:21] <smoser> bdmurray, your fix for bug 1043725 seems to have added a ton of dependencies to cloud-images
[14:21] <smoser> http://paste.ubuntu.com/1190881/
[14:22] <mterry> zul, can you port the patch they had on their embedded urllib3 to our system one and forward on?  It seemed like a generally useful thing
[14:22] <zul> mterry:  for requests?
[14:23] <mterry> zul, yeah.  requests had a tiny patch for AppEngine support in their embedded urllib3
[14:23] <mterry> zul, just diff it with our system one to see it
[14:23] <zul> mterry: sure
[14:27] <SpamapS> are there people assigned to making Unity less battery hungry? since updating to quantal my MBA 4,1 has lost an entire hour of battery life. RIP unity2d...
[14:27] <smoser> SpamapS, that bug is [marked] fixed :)
[14:28] <smoser> https://bugs.launchpad.net/ubuntu-power-consumption/+bug/917210
[14:28] <zul> mterry:  are you talking about the ntlm stuff?
[14:30] <mterry> zul, http://pastebin.ubuntu.com/1190918/
[14:31] <zul> mterry:  ah ok...i can add that sure
[14:31] <mterry> zul, just don't want to regress as we move to a system urllib3
[14:31] <zul> right
[14:31] <pitti> cjwatson: bug 1039022 says it's being filed from a 64 bit platform; stat(2) says that EOVERFLOW should only occurr on 32 bit platforms; did you file this from the same computer than the one showing the error?
[14:35] <cjwatson> pitti: 64-bit kernel, 32-bit userspace.  Yes I did.
[14:35] <pitti> cjwatson: aah, missed the Architecture: field; thanks
[14:36] <cjwatson> Yep, I have a 32-bit installation I don't want to bother reinstalling, but I want to be able to use 64-bit chroots and VMs, so I run a 64-bit kernel with multiarch.
[14:38] <Daviey> bdmurray: bug 1043725 .. seems to have added gui stuff to server/cloud images
[14:38] <pitti> fortunately I just created a 32 bit chroot yesterday
[14:41] <dobey> /tmp/hooks/B90lintian: 6: /tmp/hooks/B90lintian: Bad substitution
[14:41] <dobey> awesome!
[14:41] <dobey> :(
[14:43] <Daviey> smoser: As bdmurray isn't around, Can you back out the fix for 1043725 please?
[14:44] <cjwatson> dobey: sbuild FTW
[14:44] <zul> mterry:  ping anything else...im just queueing up the upload for urllib3

[14:44] <smoser> Daviey, sure.
[14:44] <cjwatson> dobey: You could just run lintian foo.changes after your build anyway.
[14:45] <dobey> cjwatson: automation FTW
[14:45] <dobey> :)
[14:45] <mterry> zul, oh I haven't been looking through yet.  If you don't mind just holding on to that until I get to it
[14:45] <zul> mterry:  yeah i just did a quick check and its using python2 and it runs the testsuite
[14:46] <cjwatson> dobey: Absolutely, but I assumed if you hadn't already switched to sbuild you must have had some reason
[14:46] <cjwatson> Given that pbuilder is awful
[14:46] <dobey> cjwatson: mostly time
[14:46] <mterry> zul, you server people and your python2!  Living in the past, man
[14:46] <zul> mterry:  yeah well um...:P
[14:46] <Daviey> mterry: Did i just hear you volunteer to help port upstream code to py3?  I *think* i did.
[14:47] <Daviey> zul: did you hear that?
[14:47] <zul> Daviey: i did...mterry get on it ;)
[14:47] <mterry> Daviey, it's my foss-given right to bitch at other developers to do work I want to see done
[14:48] <Daviey> mterry: Hah, yes it is. :)
[14:48] <bdmurray> smoser: I'm here now are you working on it?
[14:48] <pitti> xnox: there, have a new udisks2 with an inhibit script: https://launchpad.net/ubuntu/+source/udisks2/1.99.0-4
[14:48] <xnox> pitti: thanks =)
[14:48] <smoser> i just branched the source so far.
[14:48] <smoser> so if you wanted to do that, i'd appreciate it.
[14:48] <bdmurray> smoser: okay, I'll fix it
[14:49]  * cjwatson wonders if installing https://code.launchpad.net/~cjwatson/ubuntu/quantal/grub2/2.00 on his laptop on a Friday afternoon is a Really Bad Idea
[14:50] <cjwatson> Maybe a VM test first would be the path of wisdom
[14:51] <Daviey> cjwatson: Oh, i thought you were brave.  Just. Do. It.  Man or Mouse?
[14:53] <Daviey> Unrelated, I just did a dist-upgrade on a Quantal server.. and it complained of FD leaks... now the partition seems fubar'd.  I don't know if it's just hardware failure, or something more serious.
[14:53] <cjwatson> FD leaks almost certainly nothing to do with anything of importance.
[14:53] <cjwatson> Daviey: mouse, when it comes to being able to work :P
[14:55] <Daviey> cjwatson: fdisk exited non-zero on subsequent boot, directly after.  I wondered more if it was an indicator of something more serious.. or just a boring disk failure.. which FD leaks were indicating
[14:55] <Daviey> *shrug*
[14:55] <cjwatson> That's not what an FD leak means.
[14:55] <shadeslayer> dholbach: ofcourse
[14:55] <cjwatson> It means that some process isn't being tidy about its file descriptors when forking some other process.  LVM likes to whine about this.
[14:56] <dholbach> shadeslayer, shukria
[14:56] <xnox> yeah I am annoyed at that myself.....
[14:56] <shadeslayer> :D
[14:56] <cjwatson> Once in a blue moon something actually cares (it can break debconf from time to time), but it's very rare and the symptom would be much more likely to be a hang or something, not data corruption.
[14:57] <xnox> well or python3 really disliking those
[14:57] <xnox> ev loves fixing leaked FDs =)
[14:57] <Daviey> cjwatson: right.. I could be entirely wrong.. but I wondered if a disk failing would block an app from closing it's FD.. hence run out?
[14:58] <shadeslayer> dholbach: there's a new KDevelop release as well
[14:58] <ev> xnox: :)
[14:58] <pitti> cjwatson: ah, I also understand it as a long-running process which is missing a close() and piles up open files, so that eventually your user hits the 1024 files ulimit
[14:58] <Daviey> anyway.. i just found it odd that a box failed to boot.. with that as it's only odd thing before it shutdown.
[14:58] <wookey> how practical is it to use only python3 in quantal?
[14:59] <dholbach> shadeslayer, ok cool I'll leave it with you then
[14:59] <wookey> 3.3 is already multiarched, so wondering if I can just use that for python build-deps rather than finishing mulitarching 2.7...
[14:59] <Daviey> wookey: As soon as you install someting, you'll probably end up with py2.  The intention was to keep py2 off the cd.. don't know if that has been achieved
[14:59] <wookey> Any idea how many builds would break due to 2/3 diffreences?
[14:59] <Daviey> but real world usage, will end up with py2.
[15:00] <wookey> I am doing this in a forked repo so can change build-deps
[15:00] <wookey> I'm just wondering if it is at all likely to actually work...
[15:00] <cjwatson> pitti: Oh, well, it depends on the exact message, but that's usually phrased as "out of FDs" rather than "FD leak"
[15:00] <cjwatson> Daviey: No, it would not cause that.
[15:00] <pitti> it's similar to a memleak in that regard
[15:01] <pitti> anyway, terms...
[15:01] <mterry> zul, go ahead and upload python-urllib3 with that tiny fix, looks fine to me
[15:01] <zul> mterry: k...it has a dependency of python-tornado when i just have a MIR for as well
[15:01] <pitti> meh, defining _LARGEFILE64_SOURCE doesn't seem to do the trick :(
[15:02] <mterry> zul, yeah I noticed, doing that nxt
[15:02] <cjwatson> Well.  You can get EIO from close().  But it would be astonishingly rare for the process in question not to fall over somewhere else afterwards; IOW you would certainly not see an FD leak as the only error in this case.
[15:02] <xnox> wookey: s/python2/python3/ will fail. code needs to be ported to python3.
[15:02] <xnox> wookey: 3.2 vs 3.3 should mostly work
[15:02] <cjwatson> pitti: You probably want -D_FILE_OFFSET_BITS=64
[15:02] <pitti> cjwatson: ah, thanks
[15:02] <cjwatson> _LARGEFILE64_SOURCE isn't generally your friend
[15:03] <Daviey> Ah, i think it was bad file descriptor.. not leak.. duh.
[15:03] <wookey> xnox: OK, that's what I thought, but wondering actually 'most' code might work anyway (for building purposes - I don;t care if it doesn;t install/run properly (much)
[15:03] <cjwatson> wookey: No.
[15:04] <cjwatson> Daviey: That usually indicates either a lack of correct error handling somewhere or corruption in some variable, not anything due to disk.
[15:04] <wookey> OK. I'll finish the 2.7 work then :-) cheers
[15:04] <cjwatson> wookey: It's possible to write code that works in both >= 2.6 and 3.x if you're careful, but most packages that have gone to that effort have already been ported to 3.x.
[15:04] <cjwatson> wookey: Anything that hasn't gone to that effort will almost certainly break immediately.
[15:05] <mitya57> wookey: to _build_ most python packages, you need python2 anyway (as it's rare case when the package supports only 3.x)
[15:05] <cjwatson> It's not even trying to be a drop-in replacement.
[15:05] <zul> mterry: done
[15:07] <cjwatson> wookey: I guess if all the build were doing was shuffling files around then you might get away with it; but many Python packages run tests too.  I doubt the small saving in up-front effort is worth debugging the consequential problems.
[15:09] <wookey> OK. I was just looking for a possible shortcut to test some other stuff. turning off the tests is easy. (assuming nocheck is properly supported). I think it's mostly done anyway, but I just know it'll fiddly getting it all right (not helped by my exceedingly week python-foo)
[15:10] <mterry> zul, tornado looks to have some kind of test suite, but nosetest doesn't seem to be the right way to run it.  Do you know how?
[15:10] <shadeslayer> cjwatson++
[15:10] <shadeslayer> cjwatson: yer fix works
[15:10] <zul> mterry:  no i dont
[15:10] <cjwatson> shadeslayer: Oh good
[15:10] <shadeslayer> :D
[15:11] <shadeslayer> cjwatson: what would be the right way to provide ubiquity the release name and what not via live buid though
[15:11] <cjwatson> wookey: Oh, in any case it will probably be explicitly using dh_python2 and the python3 packaging doesn't provide that.
[15:12] <shadeslayer> oh wait
[15:12] <shadeslayer> I can just put it in the binary folder
[15:12] <shadeslayer> and it'll end up on the binary ISO
[15:12] <cjwatson> shadeslayer: It should be picking it up from .disk/info on the image, which is written by lb_binary_disk.
[15:12] <cjwatson> Wait, is that right
[15:13] <cjwatson> Yeah
[15:13] <cjwatson> Just make .disk look vaguely like Ubuntu images
[15:13] <shadeslayer> right, my question is how? :P
[15:13] <shadeslayer> is there a config option in live build for that?
[15:15] <zul> mterry: server team is subscribed to the bug reports for both tornado and urllib3 btw
[15:15] <mterry> zul, cool.  I just added a comment to the tornado mir on how to run the test.  It should be enabled
[15:15] <zul> mterry: ack
[15:16] <cjwatson> shadeslayer: I don't know.  You'll have to investigate for yourself, I'm afraid.
[15:16] <cjwatson> I've moved on from live-build stuff and am trying to sort out grub2 now.
[15:17] <xnox> wookey: it will fail at ./debian/rules build, if not at resolving build-deps
[15:19] <mitya57> wookey: check http://developer.ubuntu.com/packaging/html/python-packaging.html if you need help with python packaging
[15:20] <shadeslayer> cjwatson: yeah np :)
[15:20] <shadeslayer> thanks for your live build fixes however
[15:21] <cjwatson> mitya57: I suspect wookey is working on cross-building, not packaging
[15:21] <cjwatson> I note that the debian/rules advice for Python 3 in that page is wrong
[15:21] <mitya57> cjwatson: which one?
[15:21] <zul> mterry:  adding
[15:21] <cjwatson> It will result in programs with #!/usr/bin/python3.2
[15:22] <cjwatson> (http://developer.ubuntu.com/packaging/html/python-packaging.html)
[15:22] <dobey> cjwatson: how does one avoid that?
[15:23] <cjwatson> You need something like https://bazaar.launchpad.net/~ubuntu-core-dev/software-properties/main/revision/794
[15:23] <cjwatson> Or you can look at germinate's debian/rules if you need to support both Python 2 and 3
[15:24] <dobey> hrmm, the suggested (documented) method also doesn't work on natty; but that may be a packaging issue with python3.1 there
[15:25] <cjwatson> Worrying about Python 3 on natty is a waste of time
[15:25] <dobey> yeah, i just noticed it in my nightlies builsd
[15:25] <dobey> builds
[15:25] <cjwatson> (Actually, software-properties supports Python 2 as well, but it doesn't have an override_dh_auto_test target so doesn't need to worry about the same things that germinate does)
[15:27] <zul> mterry: i dont think tornado testsuite is python3 ready yet http://pastebin.ubuntu.com/1191038/
[15:28] <mterry> zul, that's weird.  That's a line of code from tornado proper, which otherwise seemed pretty ready for python3
[15:28] <mterry> zul, (testing.py is a feature of tornado for writing test suites, which its own suite uses)
[15:29] <zul> mterry: odd
[15:29] <mterry> zul, if you change that one line is everything else fine?
[15:29] <mterry> wondering if that's just a small typo or a larger problem throughout
[15:29] <zul> mterry: i havent gotten that far yet (checking the tornado git tree)
[15:29]  * cjwatson files bug 1047457 for the above
[15:30] <zul> mterry:  can we accept on the condition that testsuite will be enabled and possibly fixed after?
[15:31] <mterry> zul, possibly.  If it's harder than that one fix, we can delay on the python3 one.  But we might as well enable the python2 tests now
[15:31] <zul> mterry: ok
[15:31] <zul> lemme poke at it
[15:32]  * cjwatson laughs at https://launchpad.net/ubuntu/+source/firefox/15.0.1+build1-0ubuntu2
[15:34] <mdeslaur> lol
[15:36] <zul> mterry:  testsuite ftbfs in a chroot
[15:36] <mterry> :(
[15:36] <mterry> zul, it needs internet access?
[15:37] <zul> mterry: http://pastebin.ubuntu.com/1191051/
[15:38] <mterry> Just one test! So close
[15:38] <dobey> hrmm
[15:38] <mterry> I wonder why that would be different in a chroot
[15:39] <dobey> if you do dh --with python3,python2 instead of python2,python3, will it run the setup.py install with python2 last?
[15:42] <cjwatson> No, debhelper has no code to run setup.py install with python3 at all right now
[15:42] <zul> mterry:  probably because it does some io thingy
[15:42] <cjwatson> Which is why we still need overrides for that
[15:43] <cjwatson> So you write your overrides to call the underlying dh_auto_* either first or last depending on what you want to do
[15:44] <mcclurmc> is there a way to do a requestsync from a launchpad PPA into quantal universe?
[15:44] <cjwatson> lifeless: I'm not quite ready yet, but do you think at some point you might be able to retest a PPA grub2 in quantal on the system where you encountered bug 803658?  Forward-porting that patch to 2.00 was non-trivial, and I dropped a piece which no longer applies and which I *think* is now unnecessary but I'm not totally susre.
[15:45] <cjwatson> mcclurmc: No, but if you write it out by hand then somebody with upload access can sync it for you.
[15:46] <mcclurmc> as in, write it out in IRC, right here?
[15:46] <cjwatson> Well, if they know how :-)  syncpackage won't do it
[15:46] <cjwatson> I meant in a bug really
[15:46] <mcclurmc> yeah, i've filed a bug
[15:46] <cjwatson> Is the PPA package not versioned in a PPAish kind of way, though?
[15:46] <mcclurmc> just marked it "committed"
[15:46] <mcclurmc> yes, it's got ~quantal on it
[15:46] <cjwatson> That's not normally appropriate for uploads to the archive
[15:46] <mcclurmc> so probably not good to sync as-is
[15:46] <mcclurmc> yea
[15:46] <cjwatson> Maybe just get somebody to reupload
[15:47] <mcclurmc> okay, should i email the ubuntu-server list? (it's a server-ish package)
[15:47] <cjwatson> Subscribe ~ubuntu-sponsors to the bug
[15:47] <mcclurmc> okay, thanks
[15:47] <jamespage> mcclurmc, or just ask a pilot - which bug?
[15:48] <cjwatson> Or that, yeah
[15:48] <mcclurmc> #1028135   https://bugs.launchpad.net/xcp/+bug/1028135
[15:48] <mcclurmc> what's a pilot? like an MOTU?
[15:49] <dobey> hmm
[15:49] <jamespage> mcclurmc, patch pilot - reviewing the sponsorship queue and sponsoring things/providing feedback
[15:50] <cjwatson> see /topic
[15:51] <dobey> cjwatson: would running dh_auto_install after all the python3 installs, result in it running the install with python2 last? (which i guess implies that page is wrong in that respect as well then as the resulting package would still default to /usr/bin/python for any scripts)
[15:52] <mcclurmc> jamespage: ah, i see ;)
[15:52] <dobey> hmm; what was that wiki page where i got the py3 packaging info from that i used in dirspec :-/
[15:53] <dobey> ah
[15:53] <dobey> http://wiki.debian.org/Python/LibraryStyleGuide
[15:53] <dobey> which is yet again slightly different
[15:56] <tumbleweed> there's more than one way to skin a cat :)
[15:57] <jamespage> mcclurmc, is this likely to land in experimental in Debian first - or are you targetting Ubuntu as we have the 3.5 kernel?
[15:57] <mcclurmc> the latter. when i started work on this bug, 3.5 wasn't yet in experimental
[15:57] <jamespage> ack
[15:57] <tumbleweed> dobey: but yes, that approach will have the same problem.
[15:57] <mcclurmc> i'm going to be working with my debian maintainer to get it in experimental, if experimental is ready for that
[15:59] <dobey> tumbleweed: in that the final "install" run will be with python2?
[15:59] <tumbleweed> dobey: will be run by python3.X
[15:59] <tumbleweed> rather than python3
[16:00] <dobey> tumbleweed: wouldn't the way dependencies are handled result in plain dh_auto_install being run last? and would that not run with python2 since it doesn't do the python3 bits automatically?
[16:00] <jamespage> mcclurmc, OK - so we need to stuff a 0ubuntu1 release into it somehow so syncs/upgrades work in the future
[16:01] <tumbleweed> dobey: I can't parse that
[16:01] <mcclurmc> jamespage: do you mean in the version number in the PPA?
[16:02] <jamespage> mcclurmc, almost
[16:03] <dobey> tumbleweed: override_dh_auto_install: $(PYTHON3:%=install-python%) <- this says the "install-python%" rule is depended on by the override_dh_auto_install, so the "install-python%" for every version of python3 would happen first, and then dh_auto_install would run last; and since dh_auto_install does not handle python3 automatically (hence the overrides for it, but not for python2), it will run the install step with python2, an
[16:03] <cjwatson> dobey: If you have an override_dh_auto_install target that runs dh_auto_install and then your additional commands to run setup.py install with python3, then that will work
[16:03] <mcclurmc> jamespage: lol. let me know what i need to do (if it's something i have control over)
[16:03] <tumbleweed> dobey: that clipped at "python2, an"
[16:03] <dobey> cjwatson: and running dh_auto_install last will result in scripts being installed with python2, right?
[16:04] <tumbleweed> dobey: the problem isn't wit hthe python2 / python3 ordering. It's simply that you need to do the install with python3. dh_python3 doesn't correct shebangs any more
[16:04] <dobey> tumbleweed: "python2, and it will run last, no?"
[16:05] <mitya57> cjwatson: will "s/PYTHON3=$(shell py3versions -r)/PYTHON3=$shell py3versions -r) python3/" be sufficient?
[16:05] <tumbleweed> or am I missing something. Do you have scripts that you are only installing with python3?
[16:05] <xnox> mitya57: should be.
[16:06] <dobey> tumbleweed: right, to install the files in the python3 dir it has to be run with python3; but what i want is to install the library code with python2 and python3, but have the scripts that are installed, have "#!/usr/bin/python" so they are still python2
[16:06] <cjwatson> mitya57: I think it's distinctly preferable to avoid calling the default one there, as my rules do.
[16:06] <dobey> tumbleweed: and verify that dh_auto_install running last would mean that
[16:06] <cjwatson> mitya57: I think that there is some odd corner-case bug that happens if you don't do that.
[16:06] <tumbleweed> dobey: ok. I misunderstood. sorry
[16:07] <cjwatson> dobey: Whichever one installs scripts last will win, yes.
[16:07] <tumbleweed> I tend to do this without using debian/tmp, but just installing straight into debian/pythonX-foo
[16:07] <dobey> cjwatson: and dh_auto_install currently will *always* be with python2, correct?
[16:07]  * tumbleweed shuts up and stops confusing people
[16:07] <mitya57> cjwatson: your rules have python3 at the end:
[16:07] <mitya57> PY3 := $(filter-out $(PY3DEFAULT),$(PY3REQUESTED)) python3
[16:07] <cjwatson> mitya57: I spent quite a while trying to get this right in germinate and settled on what I have, so I can't say I'd recommend changing that.
[16:07] <cjwatson> mitya57: Yes.  But they filter out the default version (py3versions -d) from the output of py3versions -r, which is important.
[16:07] <cjwatson> dobey: Yes.
[16:08] <mitya57> cjwatson: ah, I'll just copy that line
[16:08] <mitya57> should the same be done for $(PYTHON2)?
[16:08] <tumbleweed> dh doees the same thing for python2
[16:08] <cjwatson> In general you don't need to because debhelper already handles Python 2.
[16:09] <cjwatson> If you need to list Python 2 for some reason (e.g. tests) then, yes, you need this.
[16:09] <tumbleweed> it doesn't matter whether you run tests with python2.7 or python, thugh
[16:09] <dobey> cjwatson: then for the purposes of at least Ubuntu, that developer.ubuntu.com page is also wrong in that respect, as it seems we'd want the general case to be having the scripts installed with python3 last.
[16:10] <cjwatson> tumbleweed: No, but IIRC if you run them with python2.7 sometimes it can end up sticking that in #! lines and being hard to convince otherwise later.
[16:10] <dobey> cjwatson: i guess perhaps fixing your other complaint to follow the example you linked may also fix that, so long as the dh_auto_install and dh_auto_build are moved to be the first in the list
[16:10] <cjwatson> dobey: Depends on the audience.  A lot of the people reading developer.ubuntu.com will be developing for 12.04.
[16:11] <tumbleweed> cjwatson: yaeh. checking the substituted depends is always a good idea
[16:12] <dobey> cjwatson: then perhaps even further clarification is needed on that page, for this. :)
[16:12] <cjwatson> /usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm:setup_py is the implementation of this in debhelper.
[16:12] <cjwatson> dobey: Perhaps.  Other pages are probably better at explaining how to handle Python 3 ...
[16:13] <dobey> perhaps. i just noticed it when i saw the page, so thought i'd mention it.
[16:13] <dobey> anyway, thanks :)
[16:14] <dobey> need to go to lunch and an appointment now though
[16:19] <mterry> infinity, you have a couple small changes queued up in unity's packaging branch.  I'm assuming they are OK for release?
[16:19] <xnox> mvo: did you see debtagshw python3 port bug/patch? did you have time to review it or not yet?
[16:19] <smoser> slangasek, ping.
[16:20] <infinity> mterry: Those changes were me bringing the branch in line with the archive, I believe.
[16:21] <infinity> mterry: (ie: if you build from the branch and then debdiff with the archive, you'll find they're not "changes" at all)
[16:21] <mterry> infinity, ah..  OK, thanks
[16:32] <cjwatson> Oh, I remember what the problem that caused there to be a splash screen on server was.  The live-build refactoring has made it difficult to install the kernel without Recommends ...
[16:33] <mvo> xnox: I saw it but didn't really review it yet, sorry, I put it on my list for monday, ok?
[16:33] <xnox> mvo: ok.
[16:34] <jamespage> cjwatson, is that something that is fixable?
[16:34] <cjwatson> Or maybe this was always a problem and it just didn't matter for desktop.
[16:34] <cjwatson> jamespage: It's all software, it's fixable
[16:34] <cjwatson> I just need to think very hard :-)
[16:35] <cjwatson> Probably broken by the move to squashfs-base, then, thinking about it.
[16:36] <jamespage> cjwatson, I think the oversized minimal-virtual problem is probably caused by that as well - bug 1028453
[16:37] <cjwatson> You think?  It doesn't cause that much of a size increase.
[16:37] <cjwatson> Well, it means you unnecessarily get kernel heads.
[16:37] <cjwatson> *headers
[16:37] <cjwatson> Ah, wrong kernel might make a difference, sure
[16:37] <cjwatson> Mind if I take that bug?
[16:38] <jamespage> cjwatson, please do
[16:39] <jamespage> the automated testing validates 1) kernel == virtual 2) no ubuntu-standard and 3) the kernel module size is below 40M
[16:39] <jamespage> http://testcases.qa.ubuntu.com/Install/ServerMinimalVirtualInstall
[16:39] <cjwatson> I think perhaps the solution is to build with --linux-packages none and then install the (correct) kernel packages later in a hook or something.
[16:40] <jamespage> cjwatson, that might work better I think
[16:40] <cjwatson> Oh, you need kernel == virtual, hm
[16:40] <cjwatson> live-installer doesn't have kernel installation support right now
[16:40] <cjwatson> I guess that's fixable too
[16:40] <jamespage> cjwatson, yeah - but in todays kernel world its all the same base kernel right? we just drop some default modules for minimal-virtual
[16:41]  * jamespage wonders at his over-simplification of the world sometimes....
[16:42] <Daviey> jamespage / cjwatson: Server without kernel headers sucks.
[16:42] <Daviey> please keep them.
[16:43] <Daviey> dkms often did the wrong thing.
[16:43] <jamespage> Daviey: dkms always does the wrong thing with virtual
[16:43] <jamespage> I had pain with this for the mininet/openvswitch work I did this cycle
[16:44] <jamespage> Daviey, should we not really be maintaining the status quo for minimal-virtual and deciding what we should do with it at UDS for next release :-)
[16:44] <cjwatson> jamespage: It may be but it's a hell of a lot easier to have live-installer install the right one rather than to try to remove bits
[16:44] <cjwatson> jamespage: the status quo is wrong in ways other than minimal-virtual
[16:45] <cjwatson> What did minimal-virtual do wrt kernel headers in precise?  That's a more interesting status quo
[16:46] <jamespage> cjwatson, I don't believe it installed any kernel headers
[16:46]  * jamespage looks at the preseed
[16:46] <Daviey> yes, that is correct
[16:46] <Daviey> Oh, wait.. precise.. don;t know.. pre-precise.. it did not.
[16:47] <Daviey> dkms used to look for linux-headers-server.. but dkms installed -generic headers... symlinks all wrong. :)
[16:47] <cjwatson> Well, base-installer can install kernel headers or not, controlled by a preseeded question
[16:47] <cjwatson> So it's trivial to do either if live-installer calls the right function
[16:47] <jamespage> "d-i	base-installer/kernel/headers	boolean false"
[16:47] <cjwatson> Exactly
[16:48] <slangasek> smoser: hey there
[16:48] <smoser> so lets just say that i was kind of stuck... what options do i have for massaging/forcing virtual-filesystems event to occur before mounted / ?
[16:48] <cjwatson> I'm fine with dropping that preseed if you guys think it works out better
[16:48] <cjwatson> Not wild about waiting for UDS if it's wrong
[16:48] <jamespage> for referehnce http://paste.ubuntu.com/1191181/
[16:48] <jamespage> utlemming, do we install headers by default in the cloud images?
[16:48] <jamespage> I could check but feeling lazy
[16:49] <smoser> slangasek, i seem to be hitting the bad path for me consistently in our "ephemeral images" (which do iscsi overlay root).
[16:49] <utlemming> jameaspage: yup
[16:50] <slangasek> smoser: joy
[16:50] <smoser> i'm not certain that I *wasnt* hitting it before. it might have just happened to have been not so painful due to broken /etc/resolv.conf link in the imgaes.
[16:50] <smoser> joy of joys is that this is precise where i really need to fix it.
[16:50] <jamespage> @pilot out
[16:50] <slangasek> smoser: we can have a look at the necessary mountall changes next week, but definitely no sooner; and this is such a major semantic change that it would need to cook for a bit before going to SRU
[16:51] <jamespage> cjwatson, I would +1 installing headers just to make it consistent with the cloud-images
[16:51] <cjwatson> Righto
[16:51]  * jamespage puts them in the same class for some reason...
[16:51] <smoser> slangasek, i agree to that.
[16:51] <smoser> but, lets say i was *really* stuck
[16:51] <jamespage> thanks for that utlemming
[16:51] <Bluefoxicy> man somebody needs to fix printing.
[16:52] <Bluefoxicy> Print from chrome:  single sided
[16:52] <Bluefoxicy> print from Evince:  duplex.
[16:52] <Bluefoxicy> Cannot find an option anywhere.
[16:52] <smoser> although un-maintainable... how might i go about figuring out which things i need my initramfs to mount before executing init.
[16:53] <jamespage> smoser, FYI see above for conversation re minimal-virtual install - cjwatson took the bug
[16:53] <smoser> i know of /lib/init/fstab, but how do i determine which of these are "virtual" and which can be ignored (ie, my system has no 'spu' mount).
[16:53] <slangasek> smoser: parse /lib/init/fstab; for each filesystem there that has a filesystem of 'none', look if there are any overrides in /etc/fstab and incorporate them, then mount the filesystem
[16:53] <Bluefoxicy> oh for christ's sake
[16:53] <smoser> jamespage, right. i saw, and happily lurked. thanks.
[16:54] <Bluefoxicy> what moron removed the option to actually select a printer driver when adding a printer?
[16:54] <smoser> slangasek, how about "spu" ?
[16:54] <Bluefoxicy> It just adds it as "generic PCL6 printer"
[16:54] <slangasek> smoser: those are marked 'optional' in the mount options
[16:54] <smoser> what does optional mean?
[16:54] <smoser> try and if no fs support just go on with life ?
[16:54] <slangasek> smoser: so if the mount point doesn't exist, or the point exists but the mount fails, mountall ignores; but in your case you should ignore *all* failures and just get on with it
[16:55] <smoser> slangasek, thank you.
[16:55] <smoser> can you think of a better idea than this?
[16:55] <slangasek> smoser: well, I'm worried about whether this is even guaranteed to solve your problem
[16:55] <smoser> well, i think it will.
[16:56] <slangasek> smoser: basically, mountall *has* to emit virtual-filesystems before it emits mounted MOUNTPOINT=/
[16:56] <smoser> because if mountall finds alll virtual-filesystems mounted, and work to do on /
[16:56] <slangasek> and while getting the virtual filesystems mounted from the initramfs helps with this, I don't think the order is guaranteed
[16:56] <slangasek> smoser: it's probably deterministic in practice, so I'd say test it and see
[16:57] <slangasek> but there's a chance the deterministic order is still not the order you want :P
[16:57] <smoser> right.
[16:57] <smoser> start on starting mountall .... emit virtual-filesystems
[16:57] <smoser> :)
[16:57] <smoser> yuck.
[16:57] <smoser> thanks for your help, slangasek and i'd appreciate and chan offer some help with a less hackish fix.
[16:57] <slangasek> smoser: heh, well, you could do the emit virtual-filesystems from the cloud-init-nonet job instead
[16:57] <smoser> right.
[16:58] <smoser> after knowing that the initramfs fixd it
[16:58] <smoser> that would work too
[16:58] <slangasek> and that would replace the need for calling 'start networking', and be slightly less hackish
[16:58] <slangasek> the next step after that would be to have one of the cloud-init jobs *do* the mounting, instead of doing it in the initramfs
[16:58] <slangasek> which gives a tighter guarantee you're not emitting the signal incorrectly
[16:59] <smoser> well, i could just not emit blindly
[16:59] <smoser> do you think thats worth pursuing ?
[16:59] <smoser> over the initramfs solution?
[16:59] <slangasek> I think it's better to do it in-line in your upstart job, yeah
[17:00] <slangasek> that way there's 0 risk of initramfs skew breaking things on you
[17:00] <smoser> and how to avoid emitting if already emitted ?
[17:00] <slangasek> shouldn't matter
[17:00] <smoser> i guess a job that starts on it
[17:00] <smoser> and marks.
[17:00] <smoser> but ok. that can be sorted out.
[17:00] <smoser> thanks slangasek
[17:01] <slangasek> in practice, a double emit of v-f will cause a couple of spurious double-runs of jobs, but that's it
[17:01] <smoser> but it shouldn't be too hard to determine
[17:02] <smoser> oh..
[17:02] <smoser> bu tyoure saying that even if all that stuff was already mounted the event might not have been emitted.
[17:02] <cjwatson> Daviey: So of course fixing minimal-virtual is going to make the installation a bit slower again, because I'll have to pull standard and server out of the squashfs and have them installed from .debs
[17:02] <smoser> ok. i'll go play now.
[17:02] <slangasek> smoser: because mountall might process / before one or more of the virtual filesystems and thus deadlock the virtual-filesystems event, yeah
[17:02] <cjwatson> Daviey: It'll still be quicker than precise, and I suspect (but haven't checked) that standard and server make up a relatively small percentage of the time taken; but thought it was worth mentioning
[17:03] <smoser> cjwatson, Daviey do we have *any* data on how much faster our squashfs install is?
[17:03] <cjwatson> I did some ad-hoc experimentation at the time
[17:03] <cjwatson> I forget the results :-)
[17:03] <cjwatson> It was maybe a minute or two faster in my VM?
[17:03] <smoser> i think percentage improvement would be more useful than "1 minute"
[17:04] <cjwatson> I think it was on the order of 5 -> 3 minutes for base system install, or something like that.  May be wrong.  Memory unreliable.
[17:04] <cjwatson> Yeah I know, but I don't have details
[17:04] <cjwatson> Would be easy enough for somebody to try
[17:04] <smoser> yeah, just trying to know how slow your vm install was. cause 1 minute out of 120 isn't much.
[17:04] <smoser> it would.
[17:04] <smoser> i was just wondering if someone already did.
[17:04] <smoser> anyway, thanks, cjwatson
[17:04] <cjwatson> Maybe more like 10/15 minutes for the full VM install end to end.  Something like that.
[17:05] <cjwatson> Real hardware's more interesting for this anyway.
[17:07] <Daviey> cjwatson: FWIW, i'm not sure how much i care about minimal atm
[17:07] <Daviey> Can we discuss this Monday?
[17:38] <xnox> what is /etc/init.d/hplip ?
[17:38] <cjwatson> Daviey: *shrug* I'm probably going to make at least some of these changes anyway because they're clear regressions from precise, particularly the business about grub-pc being in the squashfs
[17:38] <xnox> or more precise what was hplip and what has it become?
[17:38] <cjwatson> Daviey: I'd rather get to a non-regressed state and then we can discuss what you do and don't care about from there
[17:45] <Daviey> cjwatson: ok, thanks
[18:13] <stgraber> ev: hey, a friend of mine just started hitting bug 991481 on 12.04, any idea what the problem might be?
[18:30] <smoser> anyone know why i have more than one udevd running on a system?
[18:31] <smoser> seems like i have about 3 "normally"
[18:36] <lamont> so I have some questions
[18:37] <lamont> 1) while it's funny, I'd just as soon not clutter up the panel with all of the proc and pts and shmmem filesystems mounted under the various build chroots... can that be configured?
[18:37] <lamont> (quantal beta)
[18:38] <lamont> 2) wtf have I and resolvconf and dnsmasq done to my system such that it fails to resolve hostnames?
[18:48] <slangasek> lamont: I presume what you have done is failed to fix the bug I filed against bind9 asking for it to properly dis-integrate from resolveconf on upgrade ;)
[18:48] <lamont> slangasek: that could well be
[18:49] <lamont> slangasek: execpt that my /etc/default/bind9 has RESOLVCONF=no
[18:49] <slangasek> ah
[18:49] <slangasek> lamont: so you are running bind9, but also have dnsmasq?
[18:49] <lamont> so... what have done:  dnsmasq.conf has listen=127.0.0.1, bind_interface (or so)
[18:50] <lamont> network mangler believes that it owns the devices
[18:50] <smoser> slangasek, so why do i not have /run/user mounted?
[18:50] <slangasek> smoser: have you rebooted since upgrading mountall?
[18:50] <smoser> ah. no then.
[18:50] <slangasek> smoser: I suppose I could make mountall do a run from the postinst or something to get it mounted
[18:50] <lamont> and then resolvconf redirects us off to 127.0.0.1, and well, there is not happiness
[18:51] <smoser> that was newly added. that makes sense. i was just testing my "what to mount" code, and it thought it should mount that.
[18:51] <slangasek> smoser: right :)
[18:51] <slangasek> lamont: so dnsmasq is misbehaving?  Is it running, does it have sensible config?
[18:52] <slangasek> (cat /var/run/nm-dns-dnsmasq.conf)
[18:52] <lamont> slangasek: I believe that it is actually bind misbehaving due to listen-on-v6 { any; }; and thereby hijacking dnsmasq's love
[18:52] <slangasek> ah
[18:53] <lamont> the file /var/run/nm-dns-dnsmasq.conf is empty
[18:53] <slangasek> mine too
[18:53] <slangasek> and I think that's a bug
[18:54] <lamont> grep ^listen /etc/dnsmasq.conf; lsof -ni :53 | grep dnsmasq.*127
[18:54] <lamont> listen-address=127.0.0.1
[18:54] <lamont> dnsmasq 3276          nobody    4u  IPv4  15900      0t0  UDP 127.0.1.1:domain
[18:54] <lamont> dnsmasq 3276          nobody    5u  IPv4  15901      0t0  TCP 127.0.1.1:domain (LISTEN)
[18:55] <lamont> help me understand why 127.0.1.1 is so much better than WHAT IT WAS TOLD TO DO
[18:55] <slangasek> /var/run/nm-dns-dnsmasq.conf is supposed to be the config that lists dnsmasq's forwarders
[18:55] <slangasek> lamont: oh, er, which dnsmasq.conf did you put this in?  Because NM configures its own instance
[18:55] <lamont>  /etc/dnsmasq.conf
[18:55] <slangasek> the system dnsmasq.conf is used for something else (or rather, for nothing, in the stock config)
[18:56] <slangasek> lamont: see network-manager changelog, 0.9.6.0-0ubuntu4
[18:56] <lamont> slangasek: this is all prompted by the simple need to be able to have BIND run, while still somehow not throwing out everything that distro has done to help the world be better by providing everyone with dnsmasq so that they don't need a local resolver
[18:57] <slangasek> the 127.0.1.1 is there *specifically* to avoid conflicts with other DNS servers...
[18:57] <slangasek> cyphermox: ^^ maybe you and lamont want to talk :)
[18:57] <smoser> slangasek, and what about /tmp ?
[18:57] <smoser> oh. type is 'none'. so that just means "skip" ?
[18:58] <slangasek> smoser: oh yes - the 'none' in the <type> field means "ignore this unless you find it defined in /etc/fstab"
[18:58] <smoser> ah.
[18:58] <smoser> k
[18:59] <lamont> slangasek: the launcher thingy on the left side of my screen... any thoughts on (a) getting rid of all the proc and such filesystems mounted in the chroots, or (b) wtf the package is and the thingy is, so that I can file a bug?
[18:59] <slangasek> lamont: udisks2
[18:59] <cyphermox> lamont: what's the full command line for that process 3276? it should have been started by NM
[18:59] <lamont> t
[18:59] <lamont> s
[18:59] <lamont> ta, even
[18:59] <slangasek> lamont: I haven't seen this behavior myself - the only wrong disk I get shown there is one of my NFS mounts that's mounted at boot time (chosen, AFAICS, at random from the set of NFS mounts)
[19:01] <lamont> grep -c ^proc /proc/mounts
[19:01] <lamont> 6
[19:01] <lamont> interestingly, I only get 3 of tem
[19:01] <lamont> them
[19:02] <lamont> cyphermox: it was
[19:03] <lamont> OTOH, resolvconf then happily tells resolv.conf that we should query 127.0.0.1
[19:04] <cyphermox> if dnsmasq is configured and running, yeah
[19:04] <cyphermox> I mean, as started by the init script
[19:05] <lamont> Sep  7 13:04:22 rover3 dnsmasq[2245]: using nameserver 127.0.0.1#53
[19:05] <lamont> otoh, there is no listner
[19:05] <lamont> this is after "service dnsmasq restart"
[19:09] <cyphermox> lamont: so dnsmasq has to be writing something to syslog saying it can't start
[19:09] <lifeless> cjwatson: that machine is still on precise; if I can install just grub2 from the ppa and give it a spin, sure.
[19:10] <smoser> slangasek, do you know why i commonly have more than one "udevd --daemon" running?
[19:10] <lamont> dnsmasq   9239  0.0  0.0  31064   960 ?        S    13:08   0:00 /usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -r /var/run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new
[19:10] <smoser> it appeared that multiple 'virtual-filesystem' events will cause more of these, so i wondered if more than one would be bad. turns out i'm already running more than one.
[19:10] <lamont> and no udp sockets open
[19:11] <cyphermox> lamont: ok. is listen-address the only thing set in your dnsmasq.conf?
[19:11] <cyphermox> because bind-dynamic would do this kind of thing I think; just wait until it's able to start and claim a port
[19:11] <lamont> grep -ve ^# -e ^$ /etc/dnsmasq.conf
[19:11] <lamont> listen-address=127.0.0.1
[19:11] <lamont> bind-interfaces
[19:11] <cyphermox> oh wait
[19:11] <cyphermox> /etc/dnsmasq.d/NetworkManager
[19:11] <cyphermox> drop except-interface
[19:12] <cyphermox> I really need to remove that one from the config file
[19:12] <lamont> oh hey look.  something on 127.0.0.1
[19:12] <lamont> and resolution
[19:12] <lamont> cyphermox: is this a bug I should file?
[19:13] <cyphermox> lamont: the issue is the default dnsmasq setup needs that except-interface, otherwise it tries to bind on all interfaces IIRC
[19:13] <cyphermox> yeah, file a bug against network-manager, I'll set this up again and try to see if there is a saner setting to keep
[19:13] <lamont> cyphermox: so are you telling me that the desktop install now has the very issue that I ran into as a bind developer?  and we solved it in a totally wrong way?
[19:14] <cyphermox> what issue|
[19:15] <cyphermox> the big issue here is that dnsmasq has a setting where it just binds to 0.0.0.0:53 by default when 'dnsmasq' (not -base) is installed, so there is just no way to start any other instance of dnsmasq
[19:16] <cyphermox> and what we're trying to make sure is that if you want to run dnsmasq on your system you can, and we don't break that default setup at least
[19:18] <slangasek> smoser: udev spawns worker threads
[19:19] <lifeless> cjwatson: its not impossible that I'll upgrade it to quantal v. soon, but it needs the proprietary ati drivers, and it needs to work, so I get rather protective of its availability.
[19:19] <smoser> but if i just run another one 'sudo udevd --daemon' it will stick around also
[19:24] <slangasek> smoser: sure, but it's the udev upstart job that does the locking
[19:24] <slangasek> so when you start it manually you're bypassing the standard mechanism
[19:25] <smoser> i dont see locking in /etc/init/udev.conf
[19:25] <slangasek> smoser: the job *is* the lock
[19:26] <slangasek> if the job is running, a second isn't started
[19:26] <smoser> ah.
[19:26] <smoser> k.
[19:33] <ev> stgraber: blame gnetworkmonitor
[19:34] <SpamapS> or canada
[19:34] <slangasek> SpamapS: essentially the same thing, gnetworkmonitor *is* Canadian after all
[19:35]  * SpamapS should have known by all the use of 'eh' in the man page.
[19:56] <lamont> who understands unity3d window title bar decorations?
[20:00] <xnox> lamont: isn't it plain compiz?
[20:00] <lamont> xnox: could be...
[20:00] <xnox> hence changing gtk theme makes no difference to it.....
[20:00] <lamont> I'm trying to undo something I did to that configuration back in natty time
[20:00]  * xnox giggles
[20:00] <lamont> and ccsm isn't helping me
[20:00] <xnox> lamont: unity --reset ?
[20:01] <lamont> is there a way to see what it will undo before I do that?
[20:01] <xnox> lamont: apt-get source unity ?
[20:02] <lamont> heh
[20:02] <lamont> remind me how to have focus-follows-mouse instead of click-to-focus/
[20:04] <xnox> lamont: impossible
[20:04] <xnox> lamont: due to global menus
[20:04] <xnox> lamont: i guess we do have HUD now.... but still impossible
[20:04] <lamont> xnox: then if unity --reset is going to turn that off, then I definitely don't want to run that command
[20:04] <infinity> Global menus can be disabled.
[20:05] <lamont> infinity: and worked around
[20:05] <infinity> Which is a bit of a prereq for FFM.
[20:05] <jbicha> unity --reset doesn't work in quantal by the way
[20:05] <lamont> infinity: nah... dragging the window to the top-panel when you care, is enough
[20:05] <lamont> mostly, I just use the keyboard shortcuts for menus
[20:05] <lamont> jbicha: NICE
[20:05] <lamont> jbicha: is there a bug filed for that?
[20:06] <xnox> lamont: keyboard shortcuts vs hud?
[20:07] <jbicha> lamont: not exactly a bug but https://code.launchpad.net/~didrocks/unity/unity-reset-removal/+merge/123112
[20:11] <lamont> jbicha: interesting
[20:15] <smoser> slangasek: http://paste.ubuntu.com/1191536/
[20:21] <ScottK> lamont: I guess you're safe from unity --reset turning anything off.
[20:22] <lamont> ScottK: HAHA
[20:41] <YokoZar> Is archive skew still a thing in Quantal?  I'm wondering if it could be responsible for https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/1016294  (ie, unequal i386/amd64 libraries)
[20:49] <infinity> YokoZar: It can still happen, yeah, most library uploads don't go through proposed yet.
[20:54] <xnox> anybody knows a good book about dbus......
[20:54] <xnox> ?
[21:03] <ogasawara> @pilot out
[21:14] <slangasek> YokoZar: if you're talking about bug #1016294 that you just commented on, no, libnspr4 hasn't had an upload since December 2011.
[21:15] <slangasek> YokoZar: at this point, the incidence of actual archive skew is so low that reports of ia32-libs uninstallability are almost always due to users having broken local libraries installed, and these reports are generally not worth pursuing
[21:17] <YokoZar> slangasek: ahh fair enough.  Do we plan on phasing out the ia32-libs-multiarch metapackage in general?
[21:17] <slangasek> YokoZar: at some point, yeah; I'm not in a hurry
[21:17] <slangasek> we should probably wait until Debian has a multiarch release before really pushing aggressively for it
[21:18] <YokoZar> reasonable
[21:47] <cjwatson> lifeless: not sure what shlibdeps will be like; it might only be necessary to create a quantal chroot, bind-mount /dev /proc /sys, upgrade grub-pc et al from PPA, and run the grub-probe command you quoted in the bug
[21:49] <lifeless> cjwatson: anyhow, drop me a whinge when its ready.
[21:49] <lifeless> cjwatson: if you feel kind, toss a build at /precise in the ppa just in case it works
[21:50] <cjwatson> mm, there's *probably* no reason it wouldn't
[21:50] <cjwatson> about to upgrade it on my laptop, let's see
[21:56] <cjwatson> Looks plausible in kvm -snapshot
[22:44] <tjaalton> 4â
[22:44] <tjaalton> wha