[02:39] <icedtea> Anyone know how to fix this? E: Couldn't download packages: python-minimal python2.7-minimal sysvinit-utils
[02:39] <icedtea> when running pbuilder create
[02:40] <icedtea> oh nevermind
[05:19] <pitti> Good morning
[05:27] <pitti> bdmurray: followed up to bug 1048059
[05:46] <pitti> Riddell: btw, did you see my response to your apport-kde patch? it's still dubious to me
[05:56] <pitti> ev: apport-retrace crash> reproduced in a test case, and fixed in http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2514
[05:57] <pitti> ev: you are running retracers out of trunk, I presume? so this should just work
[06:57] <dholbach> good morning
[07:22] <iulian> Morning dholbach.
[07:23] <dholbach> hey iulian
[07:56] <mvo> ev: quick question - I use the recoverable errors mechanism in software-center right now to learn about the failure that people get when installing stuff - I would like to break it down further, can I use a string like "resolve-failed", "no-policykit" etc for the error and send that as "Traceback" or does it need a real traceback, i.e. will I just have to make up a bunch of exception? the ration is that it current just sends a TransactionFaile
[07:56] <mvo> d which apparently put them all into the same bucket
[08:05] <mvo> ev: or can I have some other "signature" mechanism to help the thing that looks for the dupes to sort them into the right buckets?
[08:07] <mpt> mvo, while we're on that subject, can you explain the difference between what you're using RecoverableError for, and the built-in <https://wiki.ubuntu.com/ErrorTracker#install-fails>?
[08:08]  * mpt wonders if it's actually that the latter isn't implemented yet
[08:09] <mvo> mpt: the s-c mechanism will kick in even if no apt/dpkg is touched, i.e. if there is no policykit authentication agent running in the session or if there is a dependency resolve failure
[08:09] <Riddell> pitti: yeah I'm not entirely convinced by the apport change but it seemed to work
[08:09] <pitti> Riddell: but dropping the sys.exit() seems wrong, it always exits with 0 now?
[08:09] <mpt> mvo, does that mean it's possible for a single installation request to trigger both errors?
[08:11] <mpt> (ev is afk atm)
[08:11] <Riddell> pitti: I just copied what apport-gtk does, that has no sys.exit()
[08:11] <pitti> Riddell: hm; curious that the sys.exit() causes a problem
[08:11] <pitti> Riddell: what's the crash anyway? I do get an error message, but I get it no matter whether it calls sys.exit() or not
[08:12] <pitti> python3: Fatal IO error 2 (Datei oder Verzeichnis nicht gefunden) on X server :0.0.
[08:12] <pitti> Riddell: that's "(file or directory not found)"
[08:12] <tsdgeos> is there any chance the poppler 0.20.5 that i released yesterday finds it way to quantal? it has lots of crash fixes that could be CVE classified if we issued CVEs :D
[08:13] <mvo> mpt: I need to double check - it could be
[08:14] <Riddell> pitti: it's a crash somewhere in the python binding code, previously it ran sys.exit then it ran the qt mainloop which confused it
[08:14] <pitti> Riddell: the qt mainloop was dead code; sys.exit() doesn't return
[08:14] <cjwatson> apw: So, the desktop amd64 image should now boot with a signed kernel, assuming I got the scripting right at oh-god-o'clock last night, but the server image is a different story
[08:15] <cjwatson> apw: What do you think about having linux-signed emit a kernel-signed-image udeb?
[08:15] <espirit> Hello. ATI legacy driver is not working properly on toshiba l500. Unity is failing to start and screen resolution is broken.
[08:17] <apw> cjwatson, well i guess i'd have to make it manually (the udeb), but i guess its feasable
[08:18] <Riddell> pitti: hmm, and now I add it back the crash doesn't occur :(
[08:19] <cjwatson> apw: It'd basically be a vector for getting it into /dists/quantal/main/installer-amd64/current/images/
[08:20] <apw> cjwatson, is there somewhere i can read about what has to be in a udeb
[08:20] <cjwatson> Just ship /boot/vmlinuz-*
[08:20]  * apw pokes the nest to see what happens
[08:20] <cjwatson> There's doc/devel/modules.txt in the d-i source tree but it's probably not hugely useful for kernel stuff
[08:21] <cjwatson> Put Package-Type: udeb, Section: debian-installer, Priority: extra in the control stanza
[08:21] <cjwatson> Call it kernel-signed-image-$(ABI)-di
[08:21] <cjwatson> Should basically be it
[08:21] <apw> ok ... sounds doable ...
[08:31] <mvo> ev: aha! DuplicatesSignature is the one I can use I guess - I will try that nw
[08:32] <apw> cjwatson, http://people.canonical.com/~apw/misc/linux-signed-image-3.5.0-17-generic-di_3.5.0-17.28+signed2_amd64.udeb does that look like the sort of thing?
[08:33] <cjwatson> apw: linux-signed-image -> kernel-signed-image please to match the kernel-image udeb
[08:33] <infinity> apw: Except that, for whatever reason, the naming con... yeah.
[08:33] <cjwatson> Fairly historical but it would help my sanity some
[08:33] <apw> yeah no problem
[08:34] <apw> so dh seems to grok udebs, i am slightly supprised
[08:34] <cjwatson> Yeah, ages ago :)
[08:34] <infinity> debhelper and debian-installer both sprung from the same bearded mind, it would be odd if they didn't get along.
[08:34] <cjwatson> Most of the d-i packages tree is dh(1) with rather few overrides these days
[08:35] <cjwatson> apw: Possibly add "Provides: kernel-signed-image" for reasons to do with the d-i build system I haven't had enough coffee to explain properly :-)
[08:36] <apw> cjwatson, i am in your hands, whatever you need :)
[08:36] <cjwatson> (I can't remember if that's strictly needed but it would be regular and wouldn't hurt)
[08:36] <cjwatson> apw: Everything else looks fine
[08:36] <cjwatson> Though obviously the proof will be in actually managing to construct images using it
[08:37] <cjwatson> But probably simplest to do that with it in the archive - I see no other structural problems
[08:38] <infinity> cjwatson: Were you going to try to make netboot work with SB too, or is that way out of scope for the next N hours before you give up on quantal? :P
[08:38] <cjwatson> infinity: This should handle netboot as a side-effect
[08:38] <cjwatson> With any luck
[08:38] <infinity> Cute.
[08:38] <cjwatson> infinity: Well, the netboot mini.iso
[08:38] <Daviey> please don't break it :)
[08:38] <infinity> Yeah, I was thinking actual netboot.  I assume SB also diddles with PXE?
[08:39] <cjwatson> infinity: Actual netboot will take longer - I have a to-do item to test GRUB efinet
[08:39] <cjwatson> infinity: UEFI netbooting is a kind of separate thing with its own protocol stack
[08:39] <infinity> This doesn't surprised me.
[08:39] <infinity> Nor surprise.
[08:39] <cjwatson> I've only stuck my toe in it so far
[08:39] <infinity> But it doesn't also provide a PXE emulation layer?
[08:39] <Daviey> cjwatson: How well standardised to you expect it to be?
[08:40] <infinity> Oh, but maybe enabling such a beast wouldn't require signed images.
[08:40] <cjwatson> infinity,Daviey: no idea to either of those, would have to read the spec in detail
[08:40] <cjwatson> which I do not have time for right now :)
[08:40] <infinity> Daviey: It's bound to be more standardised than PXE.
[08:40] <apw> Daviey, that sounds like a server thing, i think i'd ask Daviey about it :)
[08:40] <cjwatson> My breakfast is more standardised than PXE.
[08:40] <infinity> Daviey: Which is basically just "the world attempting to mimick Intel's behaviour, badly".
[08:40] <Daviey> apw: he's a joker, who doesn't know jack.
[08:41] <apw> Daviey, we'll have to introduce him, jack is a nice fellow
[08:41] <Daviey> infinity: with arm doing it worse :)
[08:41] <infinity> cjwatson: Anyhoo.  Sounds like another d-i upload in the offing, there's an armadaxp ABI bump building, if you'd like to do that too.
[08:41] <cjwatson> infinity: So, if we're lucky, it works in the signed images, with some configuration yet to be determined.  If we're unlucky, R + quantal-updates.
[08:42] <cjwatson> infinity: Yeah, was on my list.
[08:42] <infinity> Daviey: u-boot's PXE emulation was a last-minute hacking "here, have this, cause you're a bunch of whiney gits who don't think that bootp+tftp is cool enough for you", don't complain about it. :P
[08:42] <infinity> Daviey: Real UNIX admins <3 bootp+tftp.
[08:42] <apw> infinity, it was a simpler time
[08:42] <Daviey> infinity: I was one of the whiney poeple that complained the pxelinux implementation didn't respect enough of the pxelinux standard :)
[08:42] <mlankhorst> infinity: yeah I set up my wndr3800 router for that, it points netboot to my boot server :-)
[08:43] <infinity> Daviey: It's almost kinda halfway functional now, thanks to all of the bugs/whining from your team.
[08:43] <mlankhorst> netboot ftw
[08:43] <infinity> Daviey: Nowhere near as feature-complete as actual PXE (and never will be), but it seems to mostly DTRT now.
[08:48] <apw> cjwatson, ok if you are happy i'll chuck this in the queue
[08:49] <cjwatson> apw: Yep
[08:50] <cjwatson> apw: Do you think there's any hope at all of bug 1065263 getting in, or are we toast at this point?
[08:50]  * apw will look at the fixes there next
[08:50] <cjwatson> Basically hunting for ways in which we might manage to QA the server image on SB
[08:51] <cjwatson> Though we may end up waiting for stgraber to unpack on Friday anyway
[08:52] <Daviey> cjwatson: I didn't think Server/SB was a requirement for 12.10?  Is it compelling to squeeze it in?
[08:53] <cjwatson> I'd been given to understand that some level of SB support was a requirement across the board for 12.10
[08:53] <cjwatson> Daviey: feel free to clarify with Rick
[08:53] <cjwatson> Plus, it should be nearly there anyway
[08:54] <cjwatson> (Except netboot, which is an unknown quantity)
[08:54] <Daviey> cjwatson: I'm not pushing against it.. I thought when we discussed it before, it was a Destkop deliverable for 12.10... :)
[08:54] <cjwatson> I guess I've run into bureaucracy again.
[08:54]  * cjwatson goes for breakfast and coffee
[08:54] <Daviey> But weehaaa, value added :)
[08:58] <mvo> mpt: I fixed that it would also report dpkg errors now, thanks for this hint
[08:59] <mpt> mvo, you mean that before it would, but now it won't?
[08:59] <mvo> mpt: yes
[08:59] <mpt> ok
[09:01] <cjwatson> Daviey: it's just, things I don't want to be doing a week before release rather than fixing RC bugs:
[09:01] <cjwatson>  * arguing about whether something is a required deliverable or not
[09:01] <cjwatson> if somebody else wants to do that and tell me the answer, awesome
[09:02] <Daviey> cjwatson: That is what i was /trying to help with.  If it's something that isn't needed, perhaps time is best spent elsewhere?
[09:02] <cjwatson> and you may well be right; but OTOH I'd be surprised if the efifb bug didn't show up in some desktop use cases too
[09:02] <Daviey> (shrug*
[09:02] <cjwatson> I really like to get the server installer working because it's a lot easier to debug than ubiquity, too
[09:03] <cjwatson> Plus don't like leaving jobs incomplete
[09:03] <Daviey> right!
[09:38] <Stecchino> unity-2d seems to mess with drag and drop within my Qt application. Anyone know how to prevent/fix this?
[09:39] <doko> pitti: would you care if I point some gnome/gtk/vala universe issues?
[09:39] <pitti> doko: I'd rather you send them #ubuntu-desktop-wards, TBH
[09:40] <pitti> I can look into an FTBFS or two, but I'm already doing more disto work than intended
[09:40] <cjwatson> doko: (pitti isn't desktop team any more)
[09:40] <doko> cjwatson, but vala specialist ;)
[09:40] <pitti> steep career -- touch vala once, and you are a specialist :)
[09:41] <cjwatson> If somebody could fix avant-window-navigator, I'm really reluctant to remove that since I get the impression it's widely used
[09:41] <cjwatson> That'd probably be one of the more valuable things to do
[09:42] <pitti> uh, I remember looking at that at the beginning of precise already
[09:42] <doko> cjwatson, I don't see the ftbfs ...
[09:43] <cjwatson> It doesn't fail right now, but it requires a version of vala that's slated for removal
[09:43] <cjwatson> It's on the ubuntu-archive bug list
[09:44] <Stecchino> my d'n'd problem is prevented when the dock is not hidden. Turned of auto-hide for now. But supprised there is no bugfix
[09:45] <lool> cjwatson: UEFI bricks Samsung laptop bug > I've attempted to identify x86 UEFI contacts at Samsung by pinging Samsung folks working on UEFI for ARM, but no luck so far; we're now passing the bug to their management in case they know someone but Samsung is so big...
[09:50] <cjwatson> Thanks
[10:00] <doko> sse2 isn't default, even for amd64???
[10:03] <doko> hmm, seems so
[10:18] <tsdgeos> what's the command to know which packaging branch a package has?
[10:26] <jml> pitti: btw, I've commented on your unittest blog post. I've got an answer that I think you might like.
[10:27] <tsdgeos> pitti: i have a patch for 0007-add-lightdm-support.patch in accountsservice that you originally did (or so says http://anonscm.debian.org/gitweb/?p=collab-maint/accountsservice.git;a=history;f=debian/patches/0007-add-lightdm-support.patch;h=da802bd00494292baa5c512adcb550a6f7b3b08b;hb=HEAD ) what do i do with it?
[10:28] <pitti> jml: hey, thanks; vila was just pointing out testtools as well, thanks!
[10:29] <pitti> jml: I'll mention this when I bring this up with upstream, whether they like that additional module
[10:29] <pitti> jml: it's indeed a lot more elegant
[10:30] <jml> pitti: thanks. all that is pretty much lifeless's design. now that I've been using it, it's very hard to go back.
[10:30] <pitti> tsdgeos: it's from mterry; I suggest you attach it to a bug, and then we assign that to Mike?
[10:30] <tsdgeos> ok, works for me
[10:30] <pitti> tsdgeos: thanks!
[10:30] <tsdgeos> tx
[10:30] <jml> pitti: making things out of composable pieces turns out to be a great idea
[10:31] <pitti> jml: indeed; and it would have been surprised if I were the first one to run into this
[10:31] <pitti> jml: *want in py3 by default*
[10:32] <jml> *sigh*
[10:32] <jml> I've had difficulty getting stuff into Python
[10:32] <jml> but very much support it in principle, and we've made sure the licenses are all good for that.
[10:36] <jml> I guess that's mostly because I've been lazy, and not super willing to engage on python-ideas.
[10:36] <xnox> jml: talk to barry and jobs done ;-)
[10:37] <pitti> jml: oh, http://pkgs.fedoraproject.org/cgit/python-testtools.git/
[10:37] <pitti> jml: so it's in Debian, Ubuntu, Fedora -- good 'nuff :)
[10:37] <pitti> jml: (but would still be nice, of course)
[10:37] <jml> pitti: oh neat.
[10:38] <pitti> jml: they don't seem to build it for py3, though
[10:39] <ev> mpt: the graph is fixed: http://poppy-dev.local/
[10:39] <jml> pitti: a shame.
[10:39] <jml> pitti: because we take Python 3 support pretty seriously
[10:40] <pitti> jml: yeah, and I write pretty much everything in py3 these days, so let's see how much that hurts with getting tests upstream ;)
[10:40] <ev> well, I still need to change the calculation to make "by 12.04 standards" be "all collected" - "recoverable problems", but the 5th is back to normal
[10:40] <jml> pitti: good grief, I think you're the first person I've heard say that.
[10:41] <pitti> jml: really? we have made great progress in py3-ification in quantal
[10:41] <mpt> ev, brilliant
[10:41] <pitti> jml: in a default install we are down to two packages that use py2 still, I think (systme-config-printer and ubuntuone)
[10:42] <jml> pitti: I guess most of the people I talk to don't target quantal for their work.
[10:42] <cjwatson> If launchpadlib were ported I'd use py3 for everything.
[10:43] <jml> cjwatson: oh. hmm. interesting. I've got a half-formed plan to burn launchpadlib and have some kind of phoenix rise from its ashes.
[10:44]  * cjwatson dislikes non-incremental plans :-)
[10:45] <jml> cjwatson: yeah, me too.
[10:45] <jml> cjwatson: but there seems to be a fad for porting things to new APIs and languages for incremental benefit
[10:46] <doko> infinity, cjwatson: did you give back google-glog this morning? failed again, but builds locally ;-/
[10:46] <cjwatson> doko: no
[10:46] <Daviey> can't we just have it in a non-python language ?
[10:46] <jml> Daviey: like Python 3? :P
[10:46] <mpt> ev, it won't matter once "by 12.04 standards" is dotted, but for now it might be clearer if "all collected" was layered on top instead of underneath.
[10:47] <Daviey> jml: No, like erlang.. or soemthing
[10:47]  * cjwatson looks sidelong at Daviey
[10:47] <jml> cjwatson: more seriously, writing testable code that performs well with launchpadlib is way trickier than it has to be, and I think that's a direct result of the Python API making network calls appear transparent.
[10:47] <cjwatson> jml: I think what concerns me is the ordering of your plan.
[10:48] <doko> pitti: if you want to help with systme-config-printer ... there's still a dependency which needs conversion
[10:48] <jml> cjwatson: ashes first, phoenix second?
[10:48] <cjwatson> Something new's all well and good, but launchpadlib is production code and we can't afford to have it die before any replacement is ready.
[10:48] <jml> cjwatson: oh yeah, sure, I didn't actually mean kill launchpadlib. I don't know how I would even do that or what it would mean.
[10:51] <jml> I guess a new release of launchpadlib that totally broke API compatibility would do the trick. I don't know why anyone would do that though.
[11:15] <ev> mpt: fixed
[11:16] <pitti> ev: hey Evan, how are you? did you see my apport ping this morning?
[11:16] <mpt> splendid
[11:16] <ev> pitti: I didn't until you mentioned it just now
[11:16] <ev> wonderful!
[11:16] <ev> thanks so much
[11:19] <pitti> no worries
[11:30] <ericbutters> hi. init: mounted-proc main process (1268) terminated with status 1
[11:30] <ericbutters> anyone?
[11:34] <barry> jml, pitti talk to me!  we're starting to look for fun projects for py3.4 :)
[11:34] <ericbutters> got that w/ 11.10 12.04.1 and 12.10 beta2
[11:34] <ericbutters> btw, ubuntu-core
[11:35] <jml> barry: put testtools & fixtures into core Python.
[11:35] <jml> barry: also, if you could make function definition an expression that'd be great too.
[11:37] <jml> barry: the bit of testtools under discussion here is the 'details' API, which allows attaching arbitrary content to test results.
[11:37] <barry> jml: the first two would be great.  the last would be cool too, but probably harder to get through the gauntlet.  but that's the kind of big ideas we're looking for.  have you seen the recent discussion on generator based concurrency?  we have a group of 4 dc pythonistas ready to sprint on big fun stuff
[11:38] <jml> barry: no, I haven't. I assume dash's post was relevant though <http://washort.twistedmatrix.com/2012/10/coroutines-reduce-readability.html>
[11:40] <jml> barry: oh, actually, if you want bonkers crazy big ideas, I've got two more:
[11:40] <jml> barry: persistent (i.e. immutable) data structures ala Clojure. (esp for dicts)
[11:42] <jml> barry: do something about the Python module system: http://washort.twistedmatrix.com/2011/01/modules-in-python-good-bad-and-ugly.html (see also follow-ups)
[11:45] <barry> jml: that's a very nice blog post.  current thinking is generator-based with 'yield from' being an enabling syntax in 3.3.  the examples i've seen so far are (imho) much easier to read and reason about than deferred/callback style.
[11:48] <jml> barry: so, with iterCallbacks at least, you can't easily express "do a & b concurrently, and when they are both done, do c"
[11:49] <jml> barry: and that's pretty important.
[11:52] <barry> the module post is interesting.  i think 3.3's switch to importlib provides a great opportunity for more experimentation.  there is almost no built-in magic any more (the sys caches are still there, but we have thoughts about how to get rid of some if not all of them.  to radical for 3.3, but maybe we can do something about them in 3.4)
[11:52] <barry> jml: these are all great ideas.  exactly the kind of thing we're collecting
[11:53] <jml> barry: glad you think so. :)
[11:54] <doko> jbicha, in June you synced google-glog, dropped ubuntu changes, and didn't look at the build failure :-/
[11:54] <jml> barry: re immutable data structures, that can be done easily enough without language changes, but to do it fast probably requires CPython extensions.
[11:55] <barry> jml: do you have a reference for that?
[11:55] <doko> now looking at the arm build failures too
[11:55] <jml> barry: and, also, you wouldn't believe how many things there are on PyPI that implement dict helpers.
[11:55] <jml> barry: reference for what exactly?
[11:56] <barry> clojure's immutable data structures
[11:58] <jml> barry: oh, umm, not really. it's a btree that shares structure. I think it's actually a solution to an exercise in Cormen's "Intro to Algorithms". https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentHashMap.java
[11:59] <jml> barry: and there's an explanation of how it works in _The Joy of Clojure_.
[12:00] <barry> jml: cool
[12:00] <jml> barry: actually, iirc, dash wrote a pure Python implementation.
[12:04] <doko> jtaylor, Riddell: could you have a look at the komposer ftbfs on i386?
[12:08] <Riddell> doko: despite its name, there's nothing KDE in that package :)
[12:08] <doko> ohh :-/
[12:09] <ScottK> You probably want micahg or someone that knows mozilla stuff.
[12:16] <ericbutters> anyone here use ubuntu-core armv7hfp?
[12:20] <ogra_> ericbutters, some do, its a cheap way of getting a chroot (not of much use for anything else since many bits are missing for a proper rootfs though)
[12:21] <ericbutters> where can i find xubuntu (xfce) or lubuntu for arm?
[12:21] <ogra_> we only build images for a few arches, on what SoC are you trying to run it ?
[12:21] <ericbutters> S5PV210 (samsung)
[12:22] <ericbutters> i got fedora-arm console image running
[12:22] <ericbutters> and installed lxde
[12:22] <ogra_> http://cdimage.ubuntu.com/lubuntu/daily-preinstalled/20121008/quantal-preinstalled-desktop-armhf+ac100.tar.gz has a lubuntu tarball ...
[12:23] <ericbutters> orga_ thank you.. i will try.. did you read my first post regarding mounted-proc?
[12:23] <ogra_> after untarring run: touch <dir or mountpoint>/var/lib/oem-config/run
[12:24] <ogra_> ericbutters, most likely you are missing config options,. the tarball is originally for the ac100, look in /boot/ for the configuartion file and compare it to your config options
[12:25] <ogra_> (modulo the arch specific oprions indeed)
[12:27] <ogra_> ericbutters, oh, and there is an #ubuntu-arm channel btw
[12:27] <ericbutters> ogra_ ui :) nice!
[13:10] <stgraber> cjwatson: oh, btw, one thing I noticed yesterday. We're adding memtest86 to grub even on EFI systems, but it requires linux16/initrd16 which don't exist
[13:12] <cjwatson> stgraber: awesome
[13:13] <cjwatson> stgraber: I'll fix that
[13:18] <stgraber> cjwatson: thanks
[13:20] <barry> mvo: i'm sorry, i'm not sure if we finished our discussion from yesterday about python-apt
[13:27] <ScottK> doko: For google-glog is there a reason you only changed the build-dep to add it for i386 and not arm* as well?
[13:27] <doko> ScottK, still ftbfs with it
[13:28] <ScottK> OK.  Thanks.
[13:58] <cjwatson> mvo: Does bug 1056752 still need to be open in Ubuntu?
[13:59] <mvo> cjwatson: closing it now, that is fixed and uploaded
[13:59] <cjwatson> Thanks
[14:20] <mvo> barry: I think I'm good with python-apt, thanks. I ran into another aptdaemon issue today and tracked it down to http://paste.ubuntu.com/1273298/ - py2 seems to be rather unhappy about unicode DBusExceptions()
[14:20] <mvo> barry: this seems to be the root behind bug #846044
[14:22] <barry> mvo: dang.  i cannot wait until we can kill py2 once and for all.  let me know if you want some input or help with that problem.
[14:22] <mvo> barry: I'm knocking up a patch right now (I hope)
[14:23] <barry> ;)
[14:31] <pitti> mvo: btw, you know that "to knock up" == "make pregnant" in US English, right? :-)
[14:32] <mvo> pitti: I had no idea!
[14:32] <pitti> mvo: better get a room, you and your patch!
[14:33]  * mvo will refrain from using that phrase again in the future
[14:33] <mvo> pitti: ;)
[14:33] <pitti> mvo: no worries, I fell into that trap as well
[14:33] <pitti> mvo: but after I learned about it I finally understood the title of that Futurama episode
[14:33] <mvo> pitti: not a happy story right now anyway me and my patch not sure that there is going to be a long term future
[14:33] <pitti> ("Kyf gets knocked up a notch")
[14:33] <mvo> pitti: haha
[14:33] <pitti> lol
[14:38] <ScottK> You could say "Knock together a patch" with no unfortunate connotations.
[14:41] <Laney> or "whip up"
[14:41] <ScottK> Whip up is good.
[14:44] <micahg> doko: I was tempted to file a removal request for kompozer, upstream is dead
[14:46] <cjwatson> OMG this package has per-function changelogs
[14:46] <cjwatson> verbose much
[14:49] <ScottK> micahg: Please do.
[14:53] <micahg> ScottK: Bug #1065547 , have fun :)
[14:53] <ScottK> thanks.
[14:53] <micahg> FWIW, the Debian maintainer is subscribed to the bugs, so maybe he'll fix it now :)
[14:54] <ScottK> I was thinking about not blacklisting since if it comes back, it'll surely be fixed ~somewhat.
[14:55] <micahg> RC bug filed 18 months ago with no NMU...doubtful
[14:56] <ScottK> OK.
[14:56] <Laney> still, doesn't seem a particular need to blacklist
[14:59] <micahg> ok, fine, skip the blacklist
[15:01] <cjwatson> Yeah, nowadays blacklisting is for "never in Ubuntu again, no really".
[15:01] <cjwatson> e.g. for kfreebsd-* it's quite reasonable
[15:01] <cjwatson> But because we used to have to use the blacklist much more, people are in the habit of massively overusing the blacklist and it creates a maintenance problem for the future.
[15:01] <hallyn> stgraber: will it matter for us at all if we take Dwight's patch to switch 0.8.0-rcX with 0.8.0.rcX ?
[15:04] <ScottK> micahg: Done.  Please fix the recommends in ezgo-network.
[15:05] <micahg> ScottK: is a missing recommends a problem? we have no diff ATM
[15:09] <bdmurray> pitti: thanks I commented on the bug too
[15:11] <cjwatson> hdf-eos5 is officially awful
[15:11] <cjwatson> Insanely repetitive code, and it seems to use memmove if and only if it doesn't need to
[15:19] <smoser> cjwatson, can you confirm that i should not need to specify anything special to have dpkg unsafe-io used during installs
[15:21] <cjwatson> smoser: confirmed
[15:22] <smoser> why does installaiton take so long.
[15:23] <smoser> i know, it is completely not helpful an di have no data. but it justseems like install takes longer than it should.
[15:27] <Daviey> cjwatson: In the last hour, i've just had two netinstalls fail to boot.  Do you think it is SB related?
[15:27] <Daviey> seemingly stuck at bios
[15:27] <cjwatson> It seems unlikely but I suppose I cannot rule it out
[15:28] <cjwatson> smoser: Why doesn't the server team profile it then
[15:28] <Daviey> It's two differ net
[15:28] <cjwatson> I can't do everything for you!
[15:28] <Daviey> It's two different machines, which were reliably working earlier today.. has anything changed
[15:28] <smoser> cjwatson, i cant be expected to give actual data!
[15:29] <smoser> i want to make arbitrary unsubstantiated claims!
[15:29] <cjwatson> Daviey: SB is the obvious thing, I suppose; they might object to the extra certificate data at the end of the kernel
[15:29] <Daviey> Oh
[15:29] <cjwatson> I did test in BIOS kvm but who knows
[15:29] <cjwatson> Daviey: We keep multiple versions of d-i images for this kind of reason
[15:29] <cjwatson> Daviey: Compare old and new kernels to see if that's all it is
[15:29] <Daviey> smoser: Do you want to try stripping some noise from the kernel command line?
[15:30] <smoser> noise?
[15:30] <Daviey> or that..
[15:30] <Daviey> smoser: Don't we have some essential things that can be removed
[15:30]  * Daviey needs to dash for 20-30 mins
[15:30] <cjwatson> The kernel command line hasn't changed recently
[15:30] <Daviey> cjwatson: Sorry, this is a MAAS based install. :)
[15:31] <cjwatson> Sorry, not my fault that you can't get your overly complex infrastructure to do a simple test
[15:31] <highvoltage> hie hie
[15:31] <cjwatson> Surely it can manage a different installer version
[15:31] <smoser> surely it cannot.
[15:32] <smoser> cjwatson, where would i get an older installer to start poking
[15:32] <cjwatson> http://archive.ubuntu.com/ubuntu/dists/quantal/main/installer-amd64/
[15:32] <cjwatson> 181 is unsigned kernel, 183 is signed kernel
[15:33] <cjwatson> I assume you know which bits under that you're using
[15:33] <cjwatson> probably something under images/netboot/
[15:34] <smoser> cjwatson, thanks. i can figure that out.
[15:34] <cjwatson> ok.  if that turns out to be it then I can either do a straight revert or else (preferably if I have the time) come up with something to ship unsigned for BIOS and signed for UEFI
[15:35] <cjwatson> smoser: fwiw if we didn't have to support minimalvm then the base squashfs could be much more extensive and I expect it would be rather quicker as a result.
[15:35] <cjwatson> it was that way during quantal for a while until we realised that it broke minimalvm.
[15:36] <cjwatson> (alternatively some kind of multi-squashfs scheme, but that's not been a road down which very much success has ever lain ...)
[15:37] <smoser> oh shoot.
[15:37] <smoser> ugh
[15:37] <cjwatson> hmm
[15:37] <cjwatson> (never mind, misread)
[15:37] <smoser> we *should* hvae been installing precise
[15:38] <cjwatson> in relation to slowness, or to boot failures?
[15:38] <smoser> actually both.
[15:39] <smoser> jus ignore me for the moment.
[15:42] <smoser> cjwatson, but for slowness, precise should still have unsafe-io, right?
[15:42] <cjwatson> smoser: Yeah
[15:43] <cjwatson> debootstrap rather than squashfs-base, though, which makes some difference
[15:43] <smoser> some.
[15:43] <smoser> but just watching syslog messages of install
[15:43] <smoser> just seems slower
[15:50] <micahg> cjwatson: is a missing recommends for kompozer a problem (it shows up on the NBS list), we're in sync on the package now (ezgo)
[15:51] <ScottK> micahg: Technically, yes, but if there's no diff, meh.
[15:51] <cjwatson> We can break missing Recommends if we need to
[15:51] <cjwatson> Better not to if possible, but yeah, what ScottK said
[15:51] <micahg> right
[15:51] <cjwatson> I'll NBS that now
[15:52] <micahg> thanks
[16:00] <tkamppeter> slangasek, hi
[16:03] <johanbr> Hi. What's the preferred method for submitting a bug if apport hangs while collecting the information? Just submit the bug manually?
[16:06] <slangasek> tkamppeter: hi there
[16:28] <tkamppeter> slangasek, does cups crash often for you? In which situation?
[16:30] <doko> Laney, https://launchpadlibrarian.net/119497991/buildlog_ubuntu-quantal-armhf.cabal-debian_1.25-1_FAILEDTOBUILD.txt.gz
[16:30] <slangasek> tkamppeter: it crashes once a day for me
[16:30] <doko> runhaskell not available on arm?
[16:31] <Laney> doko: indeed
[16:31] <doko> ok, thanks
[16:31] <Laney> you can use ghc manually
[16:33] <slangasek> tkamppeter: I had speculated that it might have been related to cron.daily and logrotate-based force-reload, but that doesn't seem to happen at the right time of the morning
[16:36] <tkamppeter> slangasek, does it happen once a day? At random time points? Always the same time?
[16:42] <slangasek> tkamppeter: I always get the crash notice in the morning; I don't know if it's always at exactly the same time; today's crash file has a timestamp of 8:04, the main cups process started running at 07:53; the access log appears to have been rotated at 07:48
[16:43] <slangasek> tkamppeter: testing to see if I can reproduce the crash by running invoke-rc.d force-reload
[16:45] <tkamppeter> slangasek, you can find the exact time point of the crash by the segfault message in /var/log/syslog.
[16:47] <tkamppeter> slangasek, if I run "sudo invoke-rc.d cups force-reload" I do not get a crash, but I also do not have a crash report every morning.
[16:47] <slangasek> tkamppeter: I haven't gotten a crash /yet/ after doing a force-reload; but that does not seem surprising, given the gap in time between the process starting and the crash file written
[16:48] <slangasek> tkamppeter: I don't have any mention of this crash in syslog (though, I'm not using the stock syslog config)
[16:49] <slangasek> tkamppeter: ok, I found it in /var/log/apport.log, apport was invoked at 7:53
[16:49] <slangasek> so something changed the timestamp on the crash file afterwards
[16:49] <slangasek> (I blame whoopsie)
[16:50] <slangasek> tkamppeter: so that corresponds to the time when the current cups process started; but there's still a gap of 5 minutes between when the log file was rotated and the crash happened, which doesn't make much sense
[16:51] <sarnold> slangasek: could you fiddle with the ulimits in the cups startup to let it dump core, so you could at least get a stack  trace out of it?
[16:51] <sarnold> (that might be tomorrow, of course, but a core in the morning is a good way to start the day...)
[16:51] <tkamppeter> slangasek, perhaps crash notices emitted by the kernel can also appear in kernel.log, dmesg, ... would be an alternative place for uses who suppress these messages in syslog.
[16:51] <slangasek> tkamppeter: also, the apport log shows that it did crash again in response to my most recent reload - apport just didn't re-report it
[16:52] <slangasek> sarnold: it *is* dumping core, to apport
[16:53] <sarnold> slangasek: ah, good :)
[16:54] <tkamppeter> slangasek, I have 3 bug reports now with similar stacktraces: bug 1034045, bug 1061457, and bug 1051799. Probably therefore Launchpad does not take more of these.
[16:55] <tkamppeter> slangasek, sarnold, the crash happens in D-Bus code called by Avahi code called by CUPS code. Within the D-Bus code the crash happens on different places but the path in the Avahi and CUPS code seems to always be the same.
[16:56] <tkamppeter> slangasek, sarnold, all other known CUPS crashes seem to be fixed with only this one remaining.
[16:57] <tkamppeter> slangasek, it seems probable that the problem is somewhere in Avahi or D-Bus.
[17:03] <tkamppeter> slangasek, sarnold, according to the stacktraces the problem happens for sure on the shutdown of CUPS (can also be the shutdown part of a reload).
[17:03]  * slangasek nods
[17:06] <smoser> anyone know what would be adding a foreign arch for me?
[17:06] <doko> unit222.pas(30067,17) Fatal: Procedure too complex, it requires too many registers
[17:06] <doko> nice compiler ...
[17:08] <slangasek> smoser: is the foreign arch i386?
[17:08] <smoser> yes
[17:08] <smoser> i take a cloud imge, which seems not to have it enabled, do some stuff (not including 'dpkg --add-architecture') and seems like now i have it.
[17:09] <smoser> yes. i know. i'm being very vague today.
[17:10] <slangasek> smoser: well, I would expect it to be enabled by default even on the cloud image
[17:10] <smoser> how does it get enabled?
[17:10] <smoser> it seems not enabled in our quantal images
[17:10] <smoser> but on precise it is
[17:10] <slangasek> hmm
[17:10] <slangasek> good question, I don't remember offhand
[17:14] <cjwatson> smoser,Daviey: any news / more detail on this netinstall failure?
[17:14] <smoser> well, it wasn't precise.
[17:15] <smoser> err... it wasn't quantal
[17:15] <Daviey> It was precise..
[17:15] <Daviey> So it clearly couldn't have been related. :/
[17:16] <cjwatson> That's a relief of sorts
[17:16] <cjwatson> Yeah, I'm pretty sure I didn't do anything that could have accidentally added SB to precise :)
[17:16] <cjwatson> (although come 12.04.2 ...)
[17:16] <smoser> well thats good.
[17:17] <slangasek> smoser: dpkg itself enables it on new installs
[17:17] <smoser> weird.
[17:17] <smoser> then i wonder why i dont get it.
[17:17] <smoser> it is something i'd *like* disabled.
[17:17] <smoser> :)
[17:18] <smoser> so i'm happy with that in the cloud images for now.
[17:18] <smoser> but i didn't understand it
[17:18] <smoser> in precise dpkg lays down the file in /etc/dpkg.d/multiarch
[17:18] <smoser> err.. /etc/dpkg/dpkg.cfg.d/multiarch
[17:34] <tkamppeter> slangasek, as I cannot reproduce the cups bug, I need as much info about your printing environment as possible. Which printers do you have which servers, which OSes, which connection types?
[17:35] <slangasek> tkamppeter: do you just want printers.conf attached to the bug?
[17:43] <tkamppeter> slangasek, yes, this would be a first step, but also tell which IP is your Quantal box, which IPs, OSes are the remote print servers and which printers are on which server.
[17:44] <slangasek> tkamppeter: doesn't printers.conf tell you which printers are on which server?
[17:46] <tkamppeter> slangasek, at least if all queues are defined there and not implicit queues appearing by CUPS Broadcasting/Browsing.
[17:48] <slangasek> tkamppeter: hmm; I assumed they all were, but it turns out all of them are there *except* for the default one (which is the only one that's live)
[17:48] <slangasek> tkamppeter: oh, no, that one's there too
[17:48] <slangasek> I missed <DefaultPrinter vs <Printer
[17:55] <tkamppeter> slangasek, so please attach your printers.conf.
[17:56] <slangasek> tkamppeter: done
[18:01] <tkamppeter> slangasek, you have two PSC-750 at home?
[18:03] <slangasek> tkamppeter: no, I have one printer with multiple queues
[18:03] <slangasek> only one of which is actually in use
[18:05] <tkamppeter> slangasek, Can you stop CUPS, move /etc/cups/printers.conf to another directory, do "sudo rm /var/cache/cups/*", and start CUPS again?
[18:06] <tkamppeter> After that clean out any traces from CUPS crashes (the stopping of CUPS could have caused one) and then force-reload CUPS. Does it crash now?
[18:08] <slangasek> tkamppeter: yes, still crashes
[18:15] <tkamppeter> slangasek, this means that the presence or absense of your print queues does not make any difference. Stop your CUPS daemoon again, move back your printers.conf and, clear the cache again and start CUPS again.
[18:16] <tkamppeter> slangasek, are you also sure that your observed crash is a fresh one and not a crash from before moving away printers.conf?
[18:17] <slangasek> tkamppeter: yes, absolutely certain; I'm tracking /var/log/apport.log
[18:17] <slangasek> tkamppeter: I'm afraid I don't have time to debug this further right now, though; if you have other things for me to try, can you send them to the bug and I'll pick it up later?
[18:18] <tkamppeter> slangasek, it is perhaps easier to identify crashes when starting the CUPS daemon manually, running "sudo stop cups" at first and then starting "/usr/sbin/cupsd -f".
[18:18] <tkamppeter> slangasek, OK.
[18:35] <jtaylor> are people aware of the grub not finding windows? there is someone reporting every other day in +1
[18:35] <jtaylor> not that we get another 10.10 situation
[18:35] <xnox> jtaylor: incorrect efi chainload?
[18:36] <jtaylor> no idea, fix seems to be to unmount windows before running update-grub
[18:36] <xnox> jtaylor: no idea. What was the 10.10 situation?
[18:37] <jtaylor> a similar issue was found a few days before release
[18:37] <jtaylor> and iso recreation takes ages
[18:37] <jtaylor> and it was the 10.10.2010 release so no delay possible :)
[18:38] <xnox> it surely was 9 or 11 somewhere anyway.
[18:39] <jtaylor> if I recall correctly iso respin took a couple days
[19:30] <slangasek> jtaylor: has anyone filed a bug report about this yet?
[19:31] <jtaylor> slangasek: bug 1051306 probably
[19:31] <slangasek> (+1 is not how to report bugs if you want the developers to know about them...)
[19:31] <slangasek> jtaylor: isn't that bug description the opposite of what you said above?
[19:31] <jtaylor> yes confused me too
[19:31] <jtaylor> there seem to be two issues
[19:32] <jtaylor> and I can't reproduce any of them
[19:32] <slangasek> hmm
[19:32] <slangasek> xnox: how's your os-prober-fu?
[19:33] <xnox> slangasek: well... i was poking it recently to fix reuse/reinstall options in quantal.
[19:33]  * slangasek nods
[19:33] <slangasek> xnox: can I assign this to you for investigation?
[19:33] <xnox> slangasek: why?
[19:33] <slangasek> bug #1051306
[19:34] <xnox> slangasek: I wonder if this is the same as windows is hybernated and everything is giving a fizzy fit mounting it under linux. Although we only want very read-only mode...
[19:35] <slangasek> xnox: wouldn't the 'mount -t auto' fail too in that case?
[19:35] <hallyn> SpamapS: upstart question.  What is supposed to stop a network-interface-security job for a particular interface?
[19:35] <hallyn> jdstrand: ^ you might also know
[19:35] <xnox> slangasek: yeah, it would have. Something odd is going on.
[19:36] <slangasek> hallyn: nothing, as written; why do you need it stopped?
[19:37] <SpamapS> Hm
[19:37] <hallyn> slangasek: because if you start and stop containers repeatedly, they become a nuisance?
[19:37] <hallyn> see bug 1065589
[19:37] <SpamapS> I could see a desire to run those steps again if the interface is brought down/up 
[19:37] <slangasek> hallyn: ah, heh
[19:37] <SpamapS> LOL
[19:37] <SpamapS> sorry
[19:37] <SpamapS> lol
[19:38] <SpamapS> given that the pre-start *also* has a guard in the first line..
[19:38] <slangasek> the guard is there to ensure that these tasks are run once before any network interface is brought up
[19:38] <slangasek> the whole purpose of the job is "apply apparmor policy before letting the network in"
[19:38] <SpamapS> seems logical that we would stop it on stopping network-interface INTERFACE=$INTERFACE
[19:39] <hallyn> shoudl it just be a task?
[19:39] <slangasek> so it's fine to stop it again on, say, 'stopped network-interface $INTERFACE'
[19:39] <SpamapS> actually yeah, why not a task if the guard is there?
[19:39] <slangasek> a task might work
[19:39] <SpamapS> it wouldn't change the semantics of anything depending on its started event, because it has no main process
[19:40] <SpamapS> in fact, one might wonder why its not a task and why it doesn't do its job in the main process
[19:40] <hallyn> slangasek: that would take care of 1/3 of the problem (per capita in terms of # left-over jobs :)
[19:40] <hallyn> uh, 2/3
[19:40] <slangasek> SpamapS: because nobody suggested that before now? :)
[19:41] <hallyn> there is still the problem that there is no net-device-down event for the veths that are passed into the container.
[19:41] <hallyn> but that's for either the kernel or lxc to tkae care of
[19:42]  * slangasek nods
[19:42] <hallyn> i'll go hang out in ubuntu-kernel tod iscuss that one :)
[19:42] <hallyn> slangasek: should i open a bug against upstart for that you think?
[19:42] <hallyn> the -security one
[19:42] <slangasek> hallyn: no, the job belongs to ifupdown
[19:43] <slangasek> :)
[19:43] <stgraber> hallyn: assign it to me, though I doubt that'll be fixed for 12.10 release, best I can do is zero-day SRU I guess (not that it's really that urgent, we've had that problem forever and only noticed it now)
[19:45] <hallyn> stgraber: right, and it can be worked around from userspace with a slow daemon :)
[19:45] <hallyn> thanks guys
[19:45] <stgraber> hallyn: right, we can easily write something looking at /sys/class/net and stopping the job for any interface that doesn't exist
[19:46] <hallyn> and (for the other 1/3) sending net-device-down signal
[19:48] <hallyn> bug 1065684
[19:49] <jibel> SpamapS, fyi, following yesterdays chat, I filed bug 1065434 . I haven't tried 3.6 yet
[19:50] <stgraber> doko: aren't our armel chroots/builders supposed to be armv5?
[19:51] <stgraber> doko: I'm trying to figure out what's going on with liburcu/ust. ust is trying to build with "dmb" and fails as it's not around on armv5 but looking at the configure, it thinks it's building on armv7
[19:52] <stgraber> doko: https://launchpadlibrarian.net/119499520/buildlog_ubuntu-quantal-armel.ust_2.0.4-1ubuntu1_FAILEDTOBUILD.txt.gz is the relevant build log
[21:26] <hallyn> stgraber: (and slangasek) well sadly just turning network-interface-security into a task doesn't work.  netdev doesn't come up on reboot when i do that.
[21:26] <slangasek> netdev?
[21:26] <hallyn> the network devices don't come up
[21:27] <slangasek> hallyn: did you also move it from 'pre-start script' to 'script', which IIRC was part of SpamapS' suggestion?
[21:27] <hallyn> nope
[21:27] <hallyn> didn't recall him saying that, but yes my guess was that pres-tart doesn't happen for task...
[21:27] <slangasek> that might help
[21:27] <hallyn> yeah
[21:27] <hallyn> will try.  (waiting for new instnace to spin up :)
[21:29] <hallyn> yeah that seems better  :)  thanks
[21:39] <doko> stgraber, enoclue. I love verbose build logs \o/
[21:47] <doko> stgraber:
[21:47] <doko> AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
[21:47] <doko> #ifndef __ARM_ARCH_5TEJ__
[21:47] <doko> #error "no arm5 here"
[21:47] <doko> #endif
[21:48] <doko> $ gcc -E -dM - < /dev/null | grep ARM_ARCH
[21:48] <doko> #define __ARM_ARCH_5T__ 1
[21:48] <mlankhorst> fail \o/
[21:48] <doko> stgraber, and there is another bogus test above
[21:54] <infinity> doko: That's awesome.  I can only assume that whoever wrote it didn't know what any of the letters meant.
[21:55] <infinity> doko: Cause, while I can see value in testing for 5TE (and, indeed, many people write for and require some insns that only E brings), does *anyone* wrote for Jazelle?
[21:55] <infinity> s/wrote/write/
[22:29] <YokoZar> stokachu: I just added about 97 "me too's" to https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/859600 for you ;)
[22:30] <YokoZar> stokachu: I'm wondering if I could get a status update, as I was considering starting work on it myself