[00:02] <cjwatson> roaksoax: if you're going to ping me while I'm on vacation (or just generally, really), please at least tell me what it's about so I know whether I need to interrupt vacation for it ...
[00:02]  * cjwatson should dust off that old contentless_ping.pl IRC script
=== henrix is now known as henrix_
=== cpg|away is now known as cpg
=== lifeless_ is now known as lifeless
[05:32] <pitti_> Good morning
[05:33] <sladen> morgen
[05:34] <pitti_> smoser: can you please commit your apport changes to bzr?
[05:36] <ricotz> pitti_, good morning
[05:39] <ricotz> pitti_, i hope you have a moment to look at https://bugs.launchpad.net/ubuntu/+source/clutter-gst/+bug/1040930 ? it is already in the new queue
[05:39] <ubottu> Launchpad bug 1040930 in clutter-gst (Ubuntu) "FFe: Sync clutter-gst-2.0 1.9.90-1 (universe) from Debian experimental (main)" [Wishlist,Fix committed]
[05:41] <micahg> ricotz: he's not on the release team anymore IIRC
[05:42] <ricotz> micahg, Laney approved it, it just needs an archive admin to unlock it, i think
[05:43] <micahg> ah, ok
=== bradm_ is now known as bradm
[06:00] <pitti_> ricotz: you mean source NEW reviewing it?
[06:00] <pitti_> oh, it's a sync, c'est facile
[06:01] <ricotz> pitti_, yes, it is just a rename of clutter-gst with packaging adjustments so it is co-maintainable
[06:01] <pitti_> ricotz: I can't see clutter-gst-2.0 in experimental
[06:02] <pitti_> so it's not a sync?
[06:02] <ricotz> pitti_, it is still in the new queue of debian
[06:02]  * pitti_ NEW reviews
[06:02] <ricotz> the fake-sync package in the quantal new queue
=== pitti_ is now known as pitti
[06:03] <ricotz> pitti, thank you
[06:04] <pitti> ricotz: it's missing a few copyrights in debian/copyright
[06:04] <pitti> ./clutter-gst/clutter-gst-auto-video-sink.h -> Fluendo, ./clutter-gst/clutter-gst-video-sink.c -> RedHat, etc
[06:04] <pitti> licensecheck -r --copyright .
[06:05] <ricotz> pitti, i see, i feared that :\
[06:06] <ricotz> it didnt touch the copyright file
[06:06] <ricotz> s/it/i
[06:06] <pitti> ricotz: the rest looks fine to me; can you please add these two or three and reupload? (same version number is fine)
[06:06] <pitti> I'll accept it then
[06:07] <ricotz> pitti, ok, thanks
[06:15] <pitti> smoser: ah, found the diff on LP; I'll revert your changes to .bzr-builddeb and dropping .bzrignore, and commit the actual fix
[06:16] <pitti> smoser: committed; please use the Vcs-Bzr: branch next time
[06:21] <ricotz> pitti, http://people.ubuntu.com/~ricotz/clutter/
[06:22] <pitti> ricotz: debdiff LGTM, except
[06:22] <pitti> -  [ Iain Lane ]
[06:22] <pitti> +  [ Ian Lane ]
[06:22] <pitti> :)
[06:23] <ricotz> pitti, wow, sorry
[06:23] <ricotz> one sec
[06:24] <ricotz> pitti, fixed
[06:25] <pitti> ricotz: danke, please upload and I'll wave it through
[06:25] <ricotz> pitti, i can't upload it
[06:26] <pitti> oh? no MOTU yet? I'd vouch for you :)
[06:26] <ricotz> pitti, not yet :\, good to know :)
[06:31] <pitti> ricotz: accepted
[06:31] <ricotz> pitti, :)
[07:04] <dholbach> good morning
=== chrisccoulson_ is now known as chrisccoulson
[07:58] <jibel> pitti, guten Morgen
[07:58] <pitti> bonjour jibel
[07:59] <jibel> pitti, software-center tests triggered an apport crash
[07:59] <jibel> pitti, https://jenkins.qa.ubuntu.com/job/quantal-adt-software-center/14/ARCH=amd64,label=albali/artifact/results/_usr_share_apport_recoverable_problem.1000.crash
[08:00] <pitti> jibel: thanks, I'll fix it ASAP
[08:00] <jibel> pitti, thank you
[08:00] <jibel> mvo, https://jenkins.qa.ubuntu.com/job/quantal-adt-software-center/14/ARCH=amd64,label=albali/artifact/results/dsc0t-run-tests-stdout
[08:00] <jibel> mvo, only 4 failures left
[08:00] <pitti> progress!
[08:01] <jibel> mvo, pitti finally I fixed --user in autopkgtest
[08:01] <pitti> jibel: btw, I uploaded a new gvfs to fix the three failures, and added a new test; I asked #u-release to accept it
[08:01] <pitti> jibel: the chmod $TMPDIR? I saw the Debian bug you sent, merci!
[08:01] <jibel> pitti, does it sound reasonable http://paste.ubuntu.com/1176767/
[08:02] <pitti> jibel: is .. guaranteed to be created by adt-run? if so, yes
[08:02] <jibel> pitti, yes, it's the result of mktemp called earlier in the code
[08:23] <mvo> jibel: yipiee
[08:24] <mvo> jibel: I investigate now
=== henrix_ is now known as henrix
[09:06] <vibhav> Will gnomebuntu be maintained by Canonical?
[09:08] <seb128> no
[09:08] <seb128> it's a community maintained flavor
[09:08] <seb128> like kubunutu xubuntu lubuntu...
[09:08] <vibhav> ah, thanks
[09:11] <xnox> ev: are there reports against `glade' on e.u.c all generated by me ?
[09:27] <ev> xnox: :)
[09:28] <ev> xnox: stick the sha512 hash of your system uuid on the end of https://errors.ubuntu.com/user/
[09:28] <ev> and you can see all your reports
[09:28] <xnox> ev: awesome! where do I get the _salted_ sha512 of my system?!
[09:28] <ev> so something like printf $(sudo cat /sys/class/dmi/id/product_uuid) | sha512sum
[09:30] <mvo> jibel: fingers crossed, I commited what hopefully fixes the last test failure in the env
[09:30] <xnox> ev: I doubt that computers manufactured in Latvia have that unique.... half of my lspci says "TO BE FILED BY OEM"
[09:30] <ev> xnox: it's required for Windows logo certification
[09:31] <xnox> ev: and my product_uuid is 00020003-0004-0005-0006-000700080009   which has striking resemblance to 23456789
[09:31] <ev> but in Quantal we fall back to the sha512 hash of your mac address
[09:31] <xnox> ev: my laptop came without an OS, unformatted hard drive & BIOS
[09:32] <xnox> ev: hmmm... product_uuid didn't show any reports... lets try mac addresses
[09:36]  * cking notes that we do see a lot of DMI tables that have the default "TO BE FILLED BY OEM" DMI strings or even UUIDs such as "0A0A0A0A-0A0A-0A0A-0A0A-0A0A0A0A0A0A"
[09:40] <dupondje> any eta on kmod yet ?
=== doko__ is now known as doko
[10:00] <pitti> dupondje: apparently apw has packages in his PPA, but they weren't uploaded for some weeks; I'm a bit afraid it's too late now, with FF and all :(
[10:01] <apw> pitti, is it really a feature, its like for like
[10:01] <pitti> apw: it's not me saying "no" to it, I was just guessing :( (I'm not ~u-release any more)
[10:02] <apw> pitti, will ask the question, kernel has been a bit mad the last two weeks everything blowing up
[10:03] <pitti> apw: so, if it slips to R, I guess it's not a biggie
[10:03] <apw> pitti, if it does i'll make sure it goes in day one
[10:03] <pitti> we have a rather big plumbing backlog either way
[10:04] <pitti> (newer udev, XDG_RUNTIME_DIR, the systemd d-bus services, etc.)
=== mcclurmc_away is now known as mcclurmc
[10:30] <pitti> jibel: I reproduced that m..__file__ crash in a new test case in apport, looking at it now
[10:31] <jibel> pitti, good that adt find bugs :)
=== cpg is now known as cpg|away
[10:42] <pitti> jibel: fixed in trunk now, thanks for pointing out
[10:48] <dupondje> pitti: but we already have a depend on kmod ... :)
[10:48] <pitti> dupondje: this obviously cannot be true as we don't have kmod in the archive :)
[10:49] <dupondje> https://bugs.launchpad.net/ubuntu/+source/oss-compat/+bug/992991
[10:49] <ubottu> Launchpad bug 992991 in oss-compat (Ubuntu) "oss-compat uninstallable: depends on non-existent package kmod" [High,Triaged]
[11:50] <niq> Just trying to report a bug (missing packaging dependency), but I can't because I can't even guess the launchpad captcha
[11:50] <niq> any advice?
[11:50] <niq> The bug is, libnids-dev requires pcap-dev as a dependency
[12:11] <mitya57> niq: first, I think you meant "libpcap-dev" instead of "pcap-dev";
[12:11] <mitya57> second, both these packages come unchanged from Debian, so it's better to report this bug to bugs.debian.org
[12:18] <xnox> niq: launchpad does not have captcha.
[12:20] <niq> xnox: https://login.launchpad.net/ckGDxTf7g9gWHMvs/+new_account has an impossible captcha
[12:21] <niq> and it talks of OpenID, but won't accept OpenID :(
[12:22] <niq> mitya57: thanks, I hd wondered about that, but thought my first port of call should be the platform I encountered it on
=== _salem is now known as salem_
[12:23] <xnox> niq: launchpad is an openid provider, it does not offer to consume/login with other openids.
[12:24] <xnox> niq: this must be new. Click the small refresh icon until it's readable? I hate captchas =/
[12:25] <niq> xnox: yep, so it tells us.  It seems unhelpful to feature OpenID on a login page, as it misleads the reader into looking for how to use it to login
[12:25] <niq> Tried the refresh a few times, still can't do it
[12:25] <niq> tried the audio but it's silent (firefox on ubuntu)
[12:27] <xnox> niq: needs flash
[12:27] <niq> got flash
[12:43] <ev> mpt: I don't see this apport branch you've submitted
[12:44] <mpt> ev, pitti merged part of it I think (I haven't merged trunk to check yet). He disagreed with some of the terminology, and said it was past UI Freeze (even though I proposed for trunk, not for Q).
[12:44] <mpt> https://code.launchpad.net/~mpt/apport/warmer-text/+merge/121841
[12:45] <pitti> hello mpt
[12:45] <ev> ah excellent
[12:45] <pitti> I still don't like to break all translations for strings which do not really change meaning, TBH
[12:46] <pitti> and "a bit of a problem" really sounds quite sloppy to me
[12:46] <ev> pitti: I didn't think it was about changing the meaning? I thought the intent was the make the text warmer
[12:46] <ev> and more friendly
[12:46] <ev> since it's a fairly jarring experience as it is
[12:47] <ev> like what Mozilla does with it's "this is embarrassing" text
[12:47] <pitti> but perhaps not up to the point of being sneering?
[12:48] <ev> "a bit of a problem" comes across as sneering to you?
[12:48] <pitti> and I do not consider changing "application" to "app" any helpful, and it just breaks translations, things like that
[12:48] <pitti> ev: it certainly does, if the crash just ruined an hour's work or so
[12:48] <pitti> perhaps that's just me
=== tkamppeter_ is now known as tkamppeter
[12:49] <pitti> I merged some bits of that MP, for giving some extra advice with hangs, and fixing the string for CLI apps
[12:49] <pitti> where "closed" really doesn't make sense indeed
[12:50] <ev> I do see your point, but I think the general approach of making the text more friendly is the right one. So hopefully we can find a sentence that forms the right balance.
[12:50] <pitti> do you consider the current ones particuarly frightening?
[12:52]  * apw has just updated and has gsetting data conversion implode ... anyone else seen that?
[12:54] <smoser> pitti, :-( sorry.
[12:54] <ev> pitti: I think there's room for improvement, yes. The request itself came from people with much more experience in usability than myself.
[12:54] <xnox> ev: "this is embarrasing" is humorous "a bit of a problem" translates very bad into Latvian & Russian. It makes it sound more like "none of my business, your problem"
[12:54] <ev> pitti: while I have you here, might I ask what the historical reason is for not having ARM retracers?
[12:54] <ev> was it lack of space on ddebs?
[12:55] <ev> xnox: yikes
[12:55] <xnox> ev: ddebs should use $ xz -9
[12:55] <pitti> ev: we actually had had some for a while, but since then we just never got around to setting some up
[12:55] <pitti> ev: the main blocker is that RT ticket to move to a proper postgresql duplicate DB
[12:55] <pitti> ev: as we cannot share the sqlite one between different hosts
[12:55] <ev> right
[12:55] <pitti> ev: i. e. pretty much the same problem that we have between "your" and "my" retracers now
[12:56] <ev> so apport-retrace should be able to handle ARM just fine
[12:56] <ev> pitti: speaking of which…
[12:56] <pitti> yes, it does
[12:56] <ev> I was thinking a bit more about it when I wrote the first state of the error tracker email
[12:56] <ogra_> do the backends actually work nowadays ?
[12:56] <pitti> ogra_: backends?
[12:57] <pitti> the packaging backend is exactly the same for all arches
[12:57] <smoser> pitti, what did "revert your changes to .bzr-builddeb and dropping .bzrignore, and commit the actual fix" mean?
[12:57] <ev> as a shorter term solution, could we not just have errors.ubuntu.com create bugs and dup the matching apport bug for a given crash signature to them
[12:57]  * ogra_ remembers when NCommander maintained the arm retracers we simply didnt have any 
[12:57] <ogra_> pitti, doesnt the retracer need to run the package too ?
[12:57] <pitti> there is not much that's platform specific, except perhaps the crash analysis from the disassembl
[12:57] <pitti> y
[12:57] <ev> and then if errors already has a bug but finds one from apport the next time it syncs the duplicate_database.db, it just dups it then
[12:57] <pitti> smoser: see the diff: http://launchpadlibrarian.net/114069072/apport_2.5.1-0ubuntu3_2.5.1-0ubuntu4.diff.gz
[12:58] <pitti> smoser: I reverted the .bzr-builddeb/ and .bzrignore changes
[12:58] <pitti> ogra_: which package?
[12:58] <ogra_> pitti, dunno, any arm packages actually
[12:58] <pitti> ogra_: a retracer by and large needs a checkout of apport trunk, python-launchpadlib, and a good deal of CPU and IO capacity
[12:58] <pitti> ogra_: sure, but fortunately we have them in an archive? :-)
[12:59] <ev> I'm suspicious of this as I can't imagine it didn't come up in our previous discussion about uniting the retracers.
[12:59] <smoser> pitti, sorry. fwiw, i didn't do that. it must have been a result of 'bzr bd -S'
[12:59] <ev> can't imagine why*
[12:59] <pitti> ev: right, that would work
[12:59] <pitti> ev: crashdb.py already works like that
[12:59] <ev> pitti: and you're happy with that for the near term?
[12:59] <pitti> ev: i. e. if the DB says the master bug is #i, but that has been duped to #k, it updates the DB to #k
[13:00] <ev> yeah indeed
[13:00] <ev> I remember reading that when working on the shared duplicate db
[13:00] <ev> I guess my concerns revolved around it being real time?
[13:00] <pitti> ev: yes, absolutely; we really should stop having two retracer instances
[13:00] <ev> well this would still have two retracer instances
[13:01] <ev> but it would let us have bug numbers for the crash signatures that aren't in launchpad yet
[13:01] <ev> eventually yes, we absolutely should move retracing to one system
[13:01] <ev> or find some other way of reducing the duplication of work
[13:01] <pitti> oh, you mean have the LP retracers look at the cassandra DB for master bugs, too, instead of (just) the .sqlite file?
[13:01] <pitti> ev: ^
[13:01] <ev> no
[13:01] <ev> the lp retracers keep on doing their thing
[13:02] <pitti> ev: we indeed do not have code for that, but if that's easier than swithcing the errors.u.c. retracers to retracing LP bugs
[13:02] <ev> when errors.ubuntu.com encounters a signature that does not yet have a bug number associated with it
[13:02] <ev> it creates a bug
[13:02] <mpt> ev, sorry I don't have time to deal with this today. I'll explain to ivanka why it isn't fixed yet, and make another MP next Thursday.
[13:03] <ev> when it later syncs the launchpad duplicates database, any time it finds a crash signature where it already has a bug number it just dups the new bug to what it has already
[13:03] <ev> so no changes to crash-digger and friends
[13:03] <pitti> ev: ah, yes, that d' work
[13:03] <ev> excellent
[13:03] <ev> mpt: no worries and cheers
=== henrix is now known as henrix_
[13:04] <pitti> ev: the LP retracers need to deal with this anyway, as bug triagers also dupe/unify bugs, etc.; I'm fairly sure this works, it also has test cases
[13:04] <pitti> (and the LP backend test suite finally works again)
[13:04] <ev> mpt: maybe she can drive a conversation with you, me and pitti
[13:04] <ev> if she feels that there's a good argument to be made
[13:05] <ev> pitti: yeah, it builds on the existing design well, which I very much like :)
[13:05] <ev> and the real time stuff still happens
[13:05] <pitti> smoser: presumably you used lp:ubuntu/apport, not the Vcs-Bzr: one? the package importer might have screwed it up
[13:05] <smoser> pitti, yes.
[13:05] <pitti> ev: so yes, that seems like a good first step indeed
[13:06] <ev> because the errors.ubuntu.com bugs exist immediately. So if someone finds an issue via the website, fixes it and notes it in the upload, it doesn't matter if we're only syncing every 15 minutes or so with the apport db
[13:06] <ev> eventually everything will get sewn together
[13:06] <pitti> ev: and at some point we shoudl get rid of the LP ones altogether; the errors.u.c. retracers already seem a lot more powerful anyway
=== henrix_ is now known as henrix
[13:06] <ev> and we still get the nice path of crash signature -> 80 steps -> fixed binary package that we can then show users
[13:06] <ev> pitti: ja
[13:06] <ev> we just rolled out another machine for it
[13:06] <ev> though disk space is persistently tight
[13:06] <pitti> and the LP ones are still leeching on the porter boxes
[13:06] <ev> we were just talking this morning about easing back on the number of i386 retracers we have
[13:07] <ev> oh this reminds me
[13:07] <ev> we don't handle the situation where some sources are invalid in the retracer sources.list well
[13:07] <ev> we lost retracing for a while when the oneiric sources that were in the precise sources.list went away
[13:07] <ev> because python-apt considered that fatal or some such nonsense
[13:09] <ev> I'll file a bug for that now
[13:09] <pitti> ah, right
[13:09] <pitti> ev: the LP retracers fail due to that, stop themselves, and send me cron mail
[13:09] <xnox>  smoser, those files end up in package if the package is using 1.0 format & debuild -S was run in the bzr checkout, instead of using bzr bd -S. Or the original tarball had them =/
[13:09] <pitti> ev: so I immediately fixed up the configs
[13:09] <ev> ahh
[13:09] <ev> surely we can make python-apt do the right thing though
[13:09] <pitti> ev: that's why I use these lock files, so that we do not continue retracing/untagging/ruining bugs when there is something wrong
[13:09] <ev> right
[13:10] <pitti> ev: yeah, one of the gazillion settings in apt.conf might do
[13:10] <ev> I need to work on feeding failed retraces back through
[13:10] <ev> lol
[13:10] <pitti> ev: sorry that I had to kill so many ddebs for older releases, but we keep running out of space on macquarie
[13:10] <ev> no worries
[13:10] <smoser> xnox, i'm certain i didnot run debuild -S. I do recall for some reason that it complained of not havin the upstream tarball and prompting me.
[13:10] <pitti> and in doubt I'd rather sacrifice oneiric than the current dev release
[13:10] <smoser> which i should have just backed out at that point.
[13:10] <ev> pitti: remind me: do we have an RT for making ddebs less shoestring and gum?
[13:10] <smoser> anyway. sorry for the garbage.
[13:11] <xnox> smoser: hmm... =/ *sigh*
[13:11] <pitti> ev: there should be an entire spec for that somewhere, hang on
[13:11] <ev> pitti: I know I'm supposed to make apport-retrace fetch from the publisher, but slangasek was saying we still very much need ddebs.u.c for other stuff
[13:11] <xnox> pitti: ddebs should learn about xz -9 -extreme for space saving? =)
[13:11] <pitti> ev: I think we actually tried that, but LP apparently is still not ready to grab and put ddebs into the librarian
[13:12] <ev> ahh
[13:12] <ogra_> xnox, ddebs should be a binary patch against debs ;)
[13:12] <pitti> ev: OMG no, as soon as LP gets them, this ddeb-retriever abdomination should die and never come back
[13:12] <ev> silly launchpad, always getting in the way of progress
[13:12] <ev> pitti: maybe mention that to him? :) I'll try to remember to
[13:12] <xnox> ogra_: !0_0!
[13:12] <ev> pitti: elmo didn't seem to be a huge fan of ddebs.u.c either
[13:12] <pitti> of course it could still be called ddebs.u.c., but not with my manual mucking of apt-ftparchive and grabbing ddebs from buildd apaches over cron
[13:13] <ev> hahaha
[13:13]  * xnox reboot testing
[13:14] <dobey> it would be nice if the dbgsyms archives were signed with the same key as the main archives, and if they were installable in the main builders via Build-Depends
[13:14] <ev> pitti: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1044362
[13:14] <ubottu> Launchpad bug 1044362 in apport (Ubuntu) "Gracefully handle invalid apt sources in apport-retrace" [Undecided,New]
[13:16] <pitti> dobey: yes, but on macquarie I (rightfully) cannot access the secret archive key
[13:19] <pitti> ev: I think it's pretty much these: https://bugs.launchpad.net/launchpad/+bugs?field.tag=ddebs
[13:19] <pitti> plus, I believe there is still an unsolved problem of how to obsolete them, so currently they would quickly fill the librarian
[13:19] <pitti> wgrant: ^ ?
[13:20] <dobey> hrmm; in migrating from cdbs to plain dh, how does one specify dh_makeshlibs for a particular binary package? searching internet/wiki isn't helping
[13:22] <seb128> dobey,
[13:22] <seb128> override_dh_makeshlibs:
[13:22] <seb128>         dh_makeshlibs -plibmessaging-menu0 -V'libmessaging-menu0 (>= 12.10.0)' -- -c4
[13:22] <seb128>         dh_makeshlibs -Nlibmessaging-menu0
[13:22] <seb128>  
[13:22] <seb128> dobey, that's one example
[13:22] <dobey> ah ok
[13:23] <pitti> or more generally, dh_... --remaining-packages
[13:23] <dobey> N: Unable to locate package libmessaging-menu0
[13:23] <dobey> hmm :)
[13:24] <dobey> oh is that new in q?
[13:24] <pitti> --remaining-packages? no, that's been around since debhelper 7 or 8
[13:24] <dobey> no, libmessaging-menu0
[13:25] <pitti> apparently, according to rmadison libmessaging-menu0
[13:26] <pitti> cjwatson: btw, do you know why rmadison is so abysmally slow these days? it used to take a second or so until a couple of months/weeks ago
[13:26] <pitti> or is that just me?
[13:27] <ogra_> its like 10.20 secs for me
[13:27] <ogra_> 10-20
[13:27] <ogra_> thugh my desktop runs precise
[13:28] <pitti> judging by the time difference between dobey's and my replies, it was almost a minute for me
[13:28] <Laney> laney@iota> time rmadison -u debian gnome-terminal >/dev/null                                       ~/dev/canonical/packaging/desktop/pidgin
[13:28] <pitti> hm, of course it's fast now
[13:28] <Laney> rmadison -u debian gnome-terminal > /dev/null  0.08s user 0.01s system 10% cpu 0.784 total
[13:28] <Laney> laney@iota> time rmadison -u ubuntu gnome-terminal >|/dev/null                                      ~/dev/canonical/packaging/desktop/pidgin
[13:28] <Laney> rmadison -u ubuntu gnome-terminal >| /dev/null  0.06s user 0.04s system 3% cpu 2.606 total
[13:28] <seb128> dobey, pitti: sorry, that's indicator-messages in quantal
[13:29] <pitti> perhaps relatively few people use it, and I was the first one to try and now warmed up its cache
[13:30] <dobey> pitti: i didn't use rmadison; was using apt-cache show
[13:30] <dobey> pitti: anywya, what did you mean about --remaining-packages exactly? using that instead of -N for the second dh_makeshlibs in the override?
[13:31] <pitti> dobey: yes; you can run dh_* for a bunch of explicit -P with special arguments
[13:31] <pitti> and then dh_* --remaining-packages for all packages you haven't touched (with that particular dh_*) yet
[13:31] <pitti> see man debhelper
[13:31] <dobey> ah ok
[13:31] <pitti> -Npkg1 -Npkg2 ... works as well, of courese
[13:31] <pitti> "course"
[14:13] <ev> pitti: out of curiosity, how are you checking for retracers failing due to invalid sources.list files? apport-retrace doesn't use exit codes as far as I can see.
[14:14] <pitti> ev: IIRC, apport-retrace crashes with an exception, and crash-digger sees that the exit code is not 99, and does not remove the lock file
[14:14] <pitti> the exception appears on stderr, which I get cron-mailed
[14:14] <ev> oh interesting
[14:14] <ev> cheers
[14:16] <ev> pitti: 99 being apt having a transient network problem, right?
[14:17] <pitti> ev: any transient problem, but it's only being used for Launchpad exceptions ATM
[14:17] <ev> cool
[14:17] <pitti> since I got bored having to restart them whenever LP wants decides to have a boo-boo
[14:18] <pitti> s/decides//
=== salem_ is now known as _salem
[15:18] <xnox> pitti: thank you for the 'md0 -> md127' comment / pointer! How could I forget about the homehost.... =)
[15:18] <pitti> xnox: I didn't know about it either
[15:19] <xnox> pitti: I knew it, but I forget about it, cause most of my mdadm testing happens on the same $hostname across reboots.
=== _salem is now known as salem_
[16:03] <slangasek> SpamapS: where did we ever get to wrt events being emitted for each sysvinit job that starts/stops?
[16:05] <slangasek> SpamapS: I'm asking because the ifupdown-runlevel-1 bug is now sorta in the way of normalizing upstart in Debian
[16:09] <slangasek> SpamapS: aha, we have 'unmounted-remote-filesystems', ok
=== Quintasan_ is now known as Quintasan
=== mcclurmc is now known as mcclurmc_away
[16:29] <rbasak> I'm going to need linux 3.2.0-30 in precise-updates d-i netboot for maas to deploy highbank correctly. It's got an RTC fix I need, and is in precise-proposed at the moment. What's the policy on bumping d-i in a stable release in order to get a new kernel?
[17:33] <arges> infinity, hello. looking at the lucid fix for pad.lv/979003 right now. first is pad.lv/956051 considered a dup?
[17:34] <arges> infinity, second, stokachu  posted a debdiff for precise that builds, do i need to re-subscribe something to get this on the SRU list?
[17:35] <infinity> arges: They're not technically dupes.  One is AVX, the other is FMA4, but the fix for both comes from the same patchset.  What's not clear to me without having the right hardware to test is if the FMA4 bug even applies to lucid.
[17:35] <infinity> arges: lucid's glibc might be old enough that it doesn't even care (and therefor care incorrectly) about FMA4, in which case, the simpler AVX-only fix can be backported.
[17:36] <infinity> arges: As for precise, there's been a larger and more correct fix from me in the queue for weeks.
[17:36] <infinity> arges: (By "in the queue", I mean it's uploaded, just needs review and acceptance into proposed)
[17:36] <arges> infinity, ok. yea for the lucid one, I  proposed the original patch in 979003 that should just disable AVX if we don't detect support in the kernel
[17:37] <infinity> arges: See https://launchpad.net/ubuntu/precise/+queue?queue_state=1
[17:37] <infinity> arges: Yeah, the simple patch you proposed (the same as the one Debian's using, AFAIK) should do the "right" (rather violently) thing for Intel, I'm unsure about AMD without someone doing some testing.
[17:38] <arges> infinity, ok so need to track down some AMD hardware...
[17:38] <infinity> arges: It was definitely incomplete for precise (which is why I went with the much more complete fix), but older versions of glibc are missing half that code to start with. :P
[17:39] <infinity> arges: Carlos and I were going to sit down and work on proper 2.13 and 2.11 backports upstream, but I think we kinda burned out after the 2.16 and 2.15 fix-test-release cycle.
[17:40] <infinity> arges: To be fair, the "simple" patch may also need some fiddling for some corner cases.  But I *think* it'll just happily break AVX support completely even in cases when it shouldn't, which is marginally better than the other direction (sometimes keeping it on when it shouldn't).
[17:41] <arges> infinity, ok i'll build a test package and see if somebody can verify on AMD/AVX/Lucid
[17:41] <arges> with the first patch
[17:42] <infinity> arges: I'm running around between conference rooms right now, but can you make a note to discuss this mor in-depth with me on Tuesday?
[17:42] <infinity> arges: I agree that any fix is probably better than no fix at this point, but I also want to make sure it's as sane as we can get it.
[17:42] <arges> infinity, sure will do... are you at plumbers?
[17:42] <infinity> arges: Yeah.
[17:42] <arges> infinity, cool. Yea i'll set something up
[17:43] <infinity> arges: My gut feeling is that the FMA4 (AMD) bug shouldn't be an issue for lucid at all, cause I think the FMA4 code was introduced in 2.15.  Being able to test that for sure would be nice, though.
[17:44] <infinity> arges: So, basically, someone who can reproduce 956051 on precise, but not on lucid, would be a good datapoint.
[17:44] <arges> infinity, so that should just be bulldozer chips and later right?
[17:44] <arges> yes
[17:44] <infinity> arges: I've not paid attention to codename roadmaps in years, so not sure what a bulldozer is. :P
[17:45] <arges> infinity, i believe its the model that has those extensions... anyway i'll do a bit more digging and set up some time to chat on tuesday
[17:45] <infinity> arges: Spiffy, thanks.
[17:46] <infinity> arges: And I'll try to coordinate with an SRU/AA member who isn't me to make sure the precise upload actually gets reviewed and accepted, now that precise isn't frozen anymore.
[17:46] <infinity> arges: I missed the 12.04.1 window by just enough that we decided to delay it.
[18:04] <arges> cool
[18:20] <Logan_> jelmer or jml: ping
[18:25] <jelmer> Logan_, pong
[18:25] <Logan_> jelmer: could you please perform $ requeue_package.py --full empathy
[18:25] <Logan_> per https://bugs.launchpad.net/udd/+bug/714622 - it's one of the 199 packages that fails to import, and I want to fix a bug :P
[18:25] <ubottu> Launchpad bug 714622 in Ubuntu Distributed Development "import fails when lp branch has been push --overwrite'n" [High,Confirmed]
[18:31] <jelmer> Logan_, done, thanks to mgz
[18:32] <Logan_> jelmer: thank you :)
[18:33] <Logan_> jelmer: do you know when I'll be able to branch the newer version? will it take a while to import?
[18:34] <jelmer> Logan_, Martin said he used --priority so hopefully it will be pretty quick
[18:34] <Logan_> awesome - I'll try in about an hour
[18:34] <Logan_> thanks again!
=== henrix is now known as henrix_
=== cpg|away is now known as cpg
[20:12] <xnox> Is the circular dependency between grub-pc & grub-gfxpayload-lists well known on Lucid -> Precise upgrades?
[20:12] <xnox> bug 1044499
[20:12] <ubottu> Launchpad bug 1044499 in grub-gfxpayload-lists (Ubuntu) "package grub-gfxpayload-lists 0.6 failed to install/upgrade: dependency problems - leaving unconfigured" [Undecided,New] https://launchpad.net/bugs/1044499
[20:18] <slangasek> xnox: I don't think it is
[20:20] <xnox> slangasek: in grub-pc Conflicts: grub-gfxpayload-lists (<< 0.6)
[20:21] <xnox> this should make grub-gfxpayload-lists be removed -> grub-pc upgraded -> new grub-gfxpayload-lists pulled in?
[20:21] <xnox> or "new style" Brakes
[20:28] <slangasek> xnox: Conflicts: << are strongly discouraged; is there a reason you need it to not be on the filesystem at the same time as the unpacked (but not yet configured) grub-pc?
[20:40] <xnox> should be ok. as long as apt breaks the dependency cycle correctly with breaks.
[20:49] <xnox> Also my fix for bug 978464  got reverted to "work around" bug 1009294 . Should this be fixed.....
[20:49] <ubottu> Launchpad bug 978464 in grub2 (Ubuntu Quantal) "After LTS->LTS (lucid2precise) upgrade, upon reboot drops into grub recovery shell" [Critical,Fix released] https://launchpad.net/bugs/978464
[20:49] <ubottu> Launchpad bug 1009294 in Ubuntu Precise "Grub update breaks automated dist-upgrade scripts on AMI images" [High,Fix released] https://launchpad.net/bugs/1009294
[20:50] <xnox> wait....
[20:51] <xnox> ignore me, it was deleted from -proposed
=== salem_ is now known as _salem
=== cpg is now known as cpg|away
[22:22] <Slayz> Hi. I am thinking of creating my own distribution based on ubuntu. Do you want to give me some words for this journey?
[22:29] <cjohnston> good luck
=== cpg|away is now known as cpg
[22:33] <wjtaylor> How does gnome volume control interact with alsa?
[22:34] <wjtaylor> I can't unmute my recording inputs in gnome, but ALSA seems to be set up correctly. Can I make these changes manually from the CLI
=== Ursinha` is now known as Ursinha