[00:06] <BenC> Laney: What did you mean last week by "will work itself out" regarding all the haskell dep-waits and ftbfs on powerpc?
[00:07] <BenC> Is there a plan to get this worked through, or what?
[00:09] <infinity> BenC: Most of it will shake out via extensive give-backs.
[00:09] <infinity> BenC: Unless some bits are just plain broken and holding up the whole mess.
[00:10] <infinity> BenC: None of that's going to happen until the current insane backlog brought on by the weekend DC move is cleared, though.
[00:10] <BenC> infinity: It looks like a lot of dep-waits are on things that need ABI related recompiles (e.g., they compiled in the wrong order, against older modules with wrong ABI, and now that module is recompiled against a newer ABI, so uninstallable now, etc, etc)
[00:11] <infinity> BenC: In cases where order got broken, yeah, we'll need some no-change uploads.  Again.  I was hoping Laney was keeping an eye on that, though.
[00:11] <BenC> It's pretty horrid for powerpc :(
[00:12] <infinity> The GHC transition tracker doesn't seem to think PPC is an much worse shape than anyone else.
[00:12] <infinity> s/is an/is in/
[00:12] <BenC> Scrolling down the ftbfs listing gives me a different impression
[00:12] <infinity> Yes, but FTBFS doesn't mean broken, just means it might need some careful unsnagging or violent give-backs.
[00:13] <infinity> The tracker tracks uninstallability (in theory), and it shows all arches in pretty much the same boat for haskell packages.
[00:13] <infinity> So, either the tracker heuristic is wrong, or the situation isn't all that bad and we just need a bunch of give-backs in the right order.
[00:13] <BenC> infinity: Well, I only ever meant it in a sense of "my beautiful numbers are not slogging" :)
[00:13] <BenC> *now
[00:14] <BenC> infinity: where's the ghc tracker?
[00:16] <infinity> BenC: http://people.canonical.com/~ubuntu-archive/transitions/ghc.html
[00:17] <infinity> BenC: It may well be wrong.  I don't have the time to look at it much today, but fiddling with this transition was on my TODO.
[00:19] <BenC> infinity: the tracker shows things like haskell-algebra as being "X" on all platforms, but the ftbfs page only shows it being ftbfs on powerpc
[00:19] <BenC> Maybe I don't understand what X and Y is
[00:19] <BenC> err, X and check
[00:19] <BenC> Thanks for the page though, I'll just keep checking back
[00:21] <infinity> X is if the check deems it "broken" from the POV of the transition (in this case, if it's uninstallable).
[00:21] <infinity> Like I said, the check might also be broken.  But a package being built or not has no bearing on it having transitioned correctly.
[00:22] <infinity> Usually, these trackers use simple heuristics like "does it depend on the new or old SOVER", but the crackful wait GHC does ABI tracking makes this difficult. :P
[00:22] <infinity> s/wait/way/
[00:22] <infinity> Also, I can't type on Mondays.
[01:49] <infinity> tjaalton: Did xserver-xorg-core-udeb pick up a libdrm dependency it didn't used to have?
[01:51] <RAOF> infinity: It didn't used to have a libdrm dependency?
[01:51] <infinity> RAOF: Dunno, looking.
[01:51] <infinity>  Depends: xkb-data-udeb, x11-xkb-utils-udeb, udev-udeb (>= 149), libc6-udeb (>= 2.15), libpciaccess0-udeb (>= 0.12.902), libpixman-1-0-udeb (>= 0.21.6), libudev0-udeb (>= 147), libxau6-udeb, libxfont1-udeb (>= 1:1.4.2)
[01:51] <infinity>  Depends: xkb-data-udeb, x11-xkb-utils-udeb, udev-udeb (>= 149), libc6-udeb (>= 2.15), libdrm2 (>= 2.4.31), libpciaccess0-udeb (>= 0.12.902), libpixman-1-0-udeb (>= 0.25.2), libudev0-udeb (>= 147), libxau6-udeb, libxfont1-udeb (>= 1:1.4.2)
[01:52] <infinity> Obviously, the latter fails miserably, as that's a non-udeb dependency.
[01:52] <infinity> So, we need a libdrm2-udeb
[01:52] <infinity> Or we need xserver-core to not actually depend on it.
[01:52] <infinity> Pick on.
[01:52] <infinity> one
[01:54] <RAOF> Hm.
[01:54] <RAOF> I could look into why it's pulling in libdrm now.
[01:55] <infinity> Cool.
[01:55] <infinity> We may decide it's unavoidably, and you get to add udebbery to libdrm.
[01:55] <infinity> Either way, it's blocking d-i builds, which sucks a little.
[01:55] <infinity> unavoidable, too.
[02:02] <infinity> RAOF: We could also just not build those bits of d-i that I don't think we actually use in Ubuntu, but that discussion should involve cjwatson (and it probably needs investigating/fixing for Debian somehow anyway)
[02:27] <RAOF> infinity: Ok.
[02:28] <RAOF> infinity: The libdrm dependency is new, and it's due to the addition of hotplug support. Probably the correct action is to generate a libdrm2-udeb.
[02:28] <infinity> RAOF: Would it need to include all the hardware-specific modules in the udeb too, I wonder, or just the base library?
[02:29] <RAOF> Just the base library.
[02:29] <RAOF> X isn't doing anything funky; it just wants things like the “Yo! Is KMS supported?” function.
[02:30] <infinity> RAOF: Mmkay.  Then go forth and get me a libdrm udeb, and I'll heart you forever.
[02:30] <infinity> RAOF: And a new xorg-server upload that fixes the dep.
[02:31] <infinity> And then none of that will build because we're still in DC move hell.
[02:31] <jk-> i sure hope that function starts with yo_
[02:31] <RAOF> infinity: What's the urgency on that?
[02:32] <infinity> RAOF: Given that I can't build installers, and I blame you, I'd say moderately so.  Day or two, don't let it fall off the radar sort of urgency.
[02:33] <RAOF> Ok. One libdrm2-udeb coming right up.
[04:25] <infinity> RAOF: I'm going to see about getting us some buildds back again, which would then make the xorg/drm thing a bit more urgent in that we can actually fix it. :P
[04:35] <tjaalton> infinity: right, looks like it was added by dh_shlibdeps, so a rebuild after the libdrm update should be enough
[04:37] <infinity> tjaalton: One would hope, assuming the udebification of libdrm is done right.
[04:38] <tjaalton> yeah
[05:22] <RAOF> tjaalton: just finishing off the testing
[05:25] <infinity> RAOF: Good timing, we haz buildds again.
[05:26] <tjaalton> RAOF: nice
[05:34] <pitti> Good morning
[05:41] <infinity> Bah.  The disk in my local mirror just started dying.  It must be bedtime.
[05:53] <RAOF> infinity: One shiny new libdrm uploaded
[06:02] <infinity> RAOF: Thanks.  Scored those up a bit.  If you want to throw an xorg-server up with a versioned build-dep, you can just fire-and-forget.  Or I can do a no-change upload in the morning after I let these through NEW.
[06:03] <RAOF> I'll do a versioned build-dep upload.
[06:03] <RAOF> Now that Zoë's lying down.
[06:04] <infinity> RAOF: Did you verify that dpkg-shlibdeps DTRT when built against this version?
[06:04] <RAOF> Yes; I rebuilt xorg-server against it, and the -udeb had an appropriate dependency against libdrm2-udeb.
[06:05] <infinity> RAOF: Shiny.  Many thanks for the quick fix.
[06:53] <dholbach> good morning
[07:30] <dholbach> @pilot in
[07:31] <dholbach> Daviey, still piloting? :)
[07:48] <dholbach> can somebody please reject https://code.launchpad.net/~jm-leddy/ubuntu/precise/transmageddon/movepresets/+merge/117478
[07:53] <pitti> dholbach: *zap*(
[07:54] <dholbach> thanks :)
[08:25] <Laney> infinity: (Looks like BenC has gone): : I don't see anything out of the ordinary. It went on hold due to the move and associated backlog.
[08:25] <Laney> I'm honestly not sure why he's panicking so much
[08:27] <Daviey> @pilot out
[08:27] <Daviey> no :)
[08:37] <Laney> infinity: One thing to note is that the tracker is all-or-nothing since the archive changed to hold arch:all packages back when an arch is behind. Ben sees the older version and still thinks that the package is 'bad'.
[08:37] <Laney> that's happening with cmdargs for example, and has lead me and some others to spuriously rebuild it ;-)
[08:38] <tumbleweed> is that not solveable in the tracker?
[08:38] <Laney> well, the code is there, anything is possible :-)
[08:39] <Laney> it's a matter of applying the appropriate effort in its direction, y'know? :P
[08:40] <tumbleweed> you're the one who knows the codebase :)
[08:40] <Laney> only the parts that I had to change
[08:40] <Laney> a possibly easier fix (and one which may be necessary when it starts looking at proposed) is to pre-process its input
[08:41] <Laney> I'm kind of loathe to do anything about it until the new ben is deployed though
[08:41] <tumbleweed> yeah
[08:53] <seb128> hum
[08:53] <seb128> pitti, moving here
[08:54] <seb128> pitti, archive-reports returns after a few seconds and http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html is still not updated
[08:54] <seb128> something weird going on there
[08:55] <pitti> seb128: it compares timestamps of the previous run
[08:55] <pitti> and thus is likely to return early
[08:55]  * pitti starts run-britney manually
[08:56] <pitti> so yes, that doesn't seem to work either
[08:56] <seb128> pitti, the first time I ran it, I got some warnings
[08:56] <seb128> "$ archive-reports
[08:56] <seb128> file has vanished: "/home/ubuntu-archive/mirror/ubuntu/dists/quantal/universe/source/.Sources.gz.otVOT0"
[08:56] <seb128> rsync warning: some files vanished before they could be transferred (code 24) at main.c(1070) [sender=3.0.9]
[08:56] <seb128> "
[08:56] <pitti> I'm fairly sure we had that problem before
[08:56] <seb128> do you remember what it was,how you solved it?
[08:56] <pitti> I didn't; I think cjwatson debugged it
[08:56] <seb128> cjwatson, help! ;-)
[08:57] <seb128> pitti, danke
[08:57] <pitti> ah
[08:58] <pitti> http://paste.ubuntu.com/1158647/
[08:58] <pitti> seb128, cjwatson ^
[08:58] <pitti> lplib login_anonymously
[08:58] <seb128> hum, another corrupted cache issue?
[08:58] <pitti> ... crashes, splendid
[08:58]  * pitti purges cache and re-runs
[08:58] <seb128> pitti, rm .launchpadlib/api.launchpad.net/cache
[08:58] <seb128> and try again
[08:59] <pitti> does that happen often?
[08:59] <pitti> yeah, running now
[08:59] <seb128> to NBS, every day or so recently
[09:01] <seb128> pitti, cjwatson said it's a lazr.restfulclient bug and that we need the fix released and SRUed to stop those
[09:15] <pitti> seb128: it's updated now, BTW
[09:15] <pitti> still running for _outdate, tohugh
[09:16] <seb128> pitti, http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html looks much better on amd64, I guess another run for armhf to settle
[09:16] <seb128> pitti, danke
[09:31] <ogra_> gah, server images are broken
[09:32] <ogra_> oh, probably because there was a linux upload
[09:34] <Daviey> ogra_: yeah, 19 hours ago
[09:34] <ogra_> right, but d-i wasnt bumped yet
[09:34] <Daviey> ogra_: missing kernel modules?
[09:34] <ogra_> yeep
[09:35] <Daviey> yeah, same on the testing.
[09:35] <Daviey> cjwatson: do you have a d-i upload planned/
[09:35] <Daviey> ?
[09:35] <ogra_> yup (it was my automatic continous arm testing here that alarmed me :) )
[09:41] <pitti> it's not that hard -- check out bzr, bump the kernel versions (just look at the previous bump), and bzr bd -S; there's no extra magic
[09:43] <ogra_> pitti, well, the installer team rules require yuz to have CIA set up properly to announce your commits in the IRC channel :)
[09:43] <pitti> I did several d-i kernel bumps in the past without that and never got a complaint
[09:43] <ogra_> ah. well
[09:45] <ogra_> (documented on https://wiki.ubuntu.com/Installer/Development)
[09:48] <ogra_> hmm, seems infinity already did it
[09:48] <ogra_> ah, it FTBFS !
[09:49] <ogra_> The following packages have unmet dependencies:
[09:49] <ogra_>  xserver-xorg-core-udeb : Depends: libdrm2 (>= 2.4.31) but it is not installable
[09:49] <ogra_> E: Unable to correct problems, you have held broken packages.
[09:49] <pitti> should be good to retry now, not on http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html any more
[09:51] <ogra_> done
[09:52] <Daviey> pitti: I didn't claim it was hard, but if there is already one in the pipe... it makes sense to ask.
[09:53] <pitti> Daviey: oh, sure; I was just pointing out the procedure to avoid blocking on him
[09:55] <Daviey> what is more interesting to me, is why this happened.. before linux was pocket-copied, why wasn't there a d-i waiting to go in tandem?
[09:56] <Laney> FTBFSed again :-)
[09:56] <ogra_> same issue
[09:59]  * Daviey reviews the libdrm binaries 
[10:04] <ogra_> i wonder if that dependency is right
[10:04] <ogra_> libdrm2 builds libdrm2-udeb but xserver-xorg-core-udeb depends on libdrm2 not libdrm2-udeb
[10:10] <dholbach> can somebody please reject https://code.launchpad.net/~bcurtiswx/ubuntu/precise/telepathy-glib/0.18.2-0ubuntu1/+merge/117176?
[10:10] <pitti> dholbach: done
[10:10] <dholbach> thanks pitti
[10:13] <dholbach> pitti, oops - can you unreject? it was for precise /o\
[10:13] <pitti> dholbach: done
[10:19] <ogra_> https://launchpad.net/ubuntu/quantal/+source/xorg-server/2:1.12.99.904-0ubuntu2 is in dep-wait on most arches, that holds up d-i
[10:20] <tjaalton> shove libdrm through first
[10:20]  * ogra_ retries them 
[10:20] <ogra_> i thought libdrm was done
[10:20] <tjaalton> probably in NEW
[10:20] <tjaalton> hum no
[10:21] <pitti> libdrm is built everywhere
[10:21] <ogra_> https://launchpad.net/ubuntu/+source/libdrm/2.4.38-0ubuntu2/+build/3733603 say it was published
[10:21] <ogra_> *says
[10:21] <seb128> let's retry builds?
[10:21] <ogra_> right
[10:21] <pitti> but the buildd lag is quite severe, perhaps they just didn't get to it again
[10:21] <tjaalton> but libdrm2-udeb is in universe..
[10:21] <ogra_> on it :)
[10:21] <ogra_> oh !
[10:21] <pitti> moving libdrm2-udeb to main
[10:21] <ogra_> thx
[10:21] <pitti> (will need another publisher, though)
[10:22] <ogra_> well, shouldnt hold up xorg from building
[10:22] <pitti> seb128: btw, all the approved empathy stuff on http://people.canonical.com/~ubuntu-archive/component-mismatches.svg, should that be promoted?
[10:23] <seb128> ogra_, why would xorg-xserver depwaiting on all arch holds up d-i?
[10:23] <ogra_> if anyone wants to bunp scroes for all builds under https://launchpad.net/ubuntu/+source/xorg-server/2:1.12.99.904-0ubuntu2
[10:23] <pitti> ogra_: doing
[10:23] <seb128> pitti, yes, if jdstrand finally signed off that stack
[10:23] <ogra_> seb128, because d-i needs xserver-xorg-core-udeb which in turn depends on libdrm2-udeb in the newest upload
[10:23] <seb128> pitti, they were still discussing it yesterday, security team had issue with the increasing webkit use and maintainability and security
[10:24] <ogra_> seb128, the upload thats in the archive depended on libdrm2, not on libdrm2-udeb
[10:24] <seb128> ok
[10:24] <seb128> pitti, ok, https://bugs.launchpad.net/ubuntu/+source/libaccounts-glib/+bug/1029549/comments/32
[10:24] <seb128> pitti, seems like we can promote
[10:26] <ogra_> sigh
[10:26] <ogra_> there is still something wrong
[10:26] <ogra_> went into depwait on libdrm-dev (>= 2.4.38-0ubuntu2~) again
[10:27] <pitti> libdrm-dev | 2.4.32-1ubuntu1 |       precise | amd64, armel, armhf, i386, powerpc
[10:27] <pitti> that might explain it :)
[10:27] <ogra_> precise ?
[10:27] <pitti> err, sorry
[10:27] <ogra_> :)
[10:27] <pitti> libdrm-dev | 2.4.38-0ubuntu1 |       quantal | amd64, armel, armhf, i386, powerpc
[10:27] <pitti> ubuntu1 < ubuntu2~
[10:28] <seb128> when were the binaries NEWed?
[10:28] <seb128> we need a publisher run after NEWing to get the new version available
[10:28] <seb128> next publisher run I guess...
[10:28]  * ogra_ goes to twiddle thumbs in a corner then
[10:29] <seb128> ogra_, I can give you work if you want...
[10:29] <ogra_> lol
[10:29] <seb128> ogra_, NBS has plenty of material to keep you busy ;-)
[10:29] <ogra_> dont take my statements to literal :)
[10:30]  * ogra_ has enough to do :)
[10:30] <seb128> :-p
[12:25] <mitya57> pitti: hi, is there any policy for adding packages to jenkins autopkgtest section?
[12:25] <mitya57> pitti: is it possible to add there sphinx, for example?
[12:30] <mitya57> (my own interest is python-docutils, but version with DEP-8 tests is still in experimental because of a RC bug)
[12:34] <pitti> mitya57: sure! you just need to add autopkgtests, and add a "XS-Testsuite: autopkgtest" source header in debian/control
[12:34] <pitti> mitya57: it'll get picked up automatically then
[12:38] <mitya57> pitti: ah, great, is that header name already a standard?
[12:38] <pitti> mitya57: yes, I got that in some months ago
[12:39] <mitya57> pitti: great, so I'll now file some bugs to Debian about that header ;)
[12:43] <verwilst> hi, not sure if there's a kernel developer here i can talk to wrt a patch?
[12:44] <ogra_> try #ubuntu-kernel
[12:44] <cjwatson> #ubuntu-kerenl
[12:44] <cjwatson> Only with spelling
[12:44] <lifeless> #ubuntu-kerning might be fun.
[12:47] <ogra_> and finally we have a d-i
[12:52] <kwoot> I am making a ubuntu package to customize 1204 to our company network. How can I use my package to answer configuration questions about the krb5-config package upon which it depends?
[12:54] <ogra_> read about preseeding
[12:57] <Debolaz> Making the preseeding process easier would be a good step towards making Ubuntu more enterprise-friendly imho.
[12:59] <sil2100> Hi guys!
[12:59] <sil2100> Our compiz merges and builds all started failing on compiz due to some problem in latest librsvg
[12:59] <sil2100> /usr/include/librsvg-2.0/librsvg/rsvg-cairo.h:27:2: error: #warning "Including <librsvg/rsvg-cairo.h> directly is deprecated."
[12:59] <kwoot> but preseeding seems to be for doing a fresh install. I want to do a install using flashdisk and later on install my customization package. Or is that not the best way to go forward?
[12:59] <sil2100> We get this all the time
[12:59] <sil2100> Anyone knows who I should ping about this issue?
[13:00] <sil2100> Wait, acutally ;)
[13:00] <sil2100> Nevermind!
[13:00] <ogra_> Debolaz, whats wrong with it ? it even has a gui tool (system-config-kickstart) to manage it
[13:05] <xnox> kwoot: see late_command or equivalent for ubiquity.
[13:06] <xnox> kwoot: you can do most of the stuff with preseeding, e.g. answering any debconf installation questions etc.
[13:06] <xnox> kwoot: what do you want to customize in your "customisation package"
[13:09] <kwoot> xnox: well, kerberos and ldap config, printerdrivers install, configure loginwindow for non-local users, mount windows (sorry) shares, sudoers file. For starters :-)
[13:09] <xnox> kwoot: you would be better off with puppet than a customisation package.
[13:10] <xnox> kwoot: cause once all your machines are talking to puppet you can easily change/modify/increase configuration.
[13:10] <xnox> kwoot: debian packages should not touch files under /etc
[13:10] <kwoot> xnox: don't get me started, I know. Thing is, I am head of dev dept, and sysadmin dept wants to go all MS.
[13:10] <Debolaz> ogra_: That GUI lacks some necessary features, such as full disk encryption. But creating the preseed file isn't the biggest problem, its using it. Most tools for remastering an Ubuntu ISO are either difficult to use or just plain don't work with the most recent version of Ubuntu, forcing the user to hunt around.
[13:10] <xnox> kwoot: puppet can manage MS as well.
[13:11] <kwoot> xnos :-)
[13:11] <ogra_> Debolaz, why would you modify the iso for preseeding ?
[13:11] <cjwatson> Debolaz: I tend to agree, but unfortunately not enough hours in the day
[13:11] <ogra_> jusr use the url= kernel cmdline option
[13:11] <Debolaz> ogra_: Because you want it to work automatically, and doing that at the moment requires quite a bit of black magic if you're not integrating it into the ISO.
[13:11] <ogra_> *just
[13:12] <Debolaz> ogra_: I'm not arguing that it can't be done. I'm saying that it could be a lot better.
[13:12] <ogra_> oh, for sure it could be improved
[13:12] <ogra_> but then i also dont think its actually bad
[13:13] <Debolaz> Another difficulty for Ubuntu in the enterprise environment at the moment is Landscape. There's no way of getting it without a support contract, I don't even know what it looks like, where is my incentive to spend money on something I don't know if will solve a problem or not?
[13:14] <ogra_> oh, and if you install from USB the iso changing really isnt relevant :)
[13:14] <ogra_> (you can just cp your file in place)
[13:15] <ogra_> didnt landscape have a trial option ?
[13:15]  * Debolaz doesn't see that anywhere now.
[13:15] <Debolaz> If it's there, it's well hidden. :-)
[13:16] <ogra_> heh
[13:17] <Debolaz> ogra_: The Ubuntu documentation says you have to remake the initrd for the ISO, so it seems to be a little bit more effort than to just copy it over involved even for the USB option.
[13:17] <ogra_> i havent looked at landscape in years, dont ask me :) but i seem to remember there was a trial option
[13:17]  * Debolaz does actually remember the trial option himself now that you mention it.
[13:17] <Debolaz> Many, many years ago.
[13:18] <cjwatson> One problem is that we don't have any staff tech writers, so documentation is either as developers get round to it - and developers don't often make good documenters - or rather haphazard wiki pages
[13:18] <cjwatson> s/don't often/often don't/  wow, word order can produce quite different emphasis from what I intended
[13:19] <cjwatson> As it happens there's no need to rebuild the initrd just for preseeding, although it can be the easiest way to do preseeding of things early in the installation
[13:22] <Debolaz> I'm also in the situation that I simply do not have a lot of time to contribute, otherwise I'd probably take it on myself to make an "Enterprise Ubuntu" edition. :)
[13:22] <cjwatson> There's really no reason for it to be a separate edition
[13:23] <cjwatson> All the installer kind of stuff you mention is common
[13:23] <jocarter> cjwatson: isn't there an ubuntu business edition by canonical?
[13:23] <cjwatson> nowt to do with me :
[13:23] <cjwatson> :P
[13:23] <Daviey> Debolaz: I struggle with the thought that Ubuntu Server isn't already Enterprise suitable.
[13:23] <cjwatson> and anyway it doesn't make installer changes
[13:23] <cjwatson> (afaik)
[13:24] <jocarter> Debolaz: you could even get an evaluation version here! http://www.ubuntu.com/business/desktop/remix
[13:24] <Daviey> jocarter: There is a desktop remix, with less social apps etc, built in non-free components such as Flash and Java.. but that is entirely different for server
[13:25] <dupondje> xnox: thx for cryptsetup merge :)
[13:25] <Daviey> Server hasn't focused on "basement deployments" for some years.
[13:25] <lifeless> Daviey: http://www.baserock.com/
[13:26] <xnox> dupondje: np =) it was non-trivial. Most of the stuff did go into debian, but the 2 upstart jobs for Booting + 2 SysV init jobs for Shutdown is "interesting"
[13:26] <dupondje> xnox: there should exist a cleaner way imo ... :p
[13:27] <xnox> dupondje: well http://upstart.ubuntu.com/cookbook/#shutdown
[13:27] <xnox> dupondje: note how upstart is killed early, before rootfs unmount, and cryptsetup unmount should happen after rootfs is unmounted...
[13:27] <xnox> =/
[13:28] <seb128> pitti, did you say you would promote the empathy,signon stuff earlier or should I do it? the MIR got acked
[13:28] <pitti> ah, I didn't; I was just wondering about it, as I looked at c-m for that libdrm udeb
[13:29] <seb128> pitti, ok, doing it
[13:30] <xnox> dupondje: I presume jodh might know if there is a better way.... or simply work towards upstart handing *all* of the shutdown...
[13:31] <dupondje> xnox: guess thats the best goal :)
[13:31] <dupondje> or remove it :P
[13:31] <jodh> xnox, dupondje: yes, that is the plan.
[13:32] <ogra_> whats there to handle ? umount and halt ...
[13:32] <xnox> jodh: cool. Cause cryptsetup is in split situation now: booting with upstart jobs, shutdown with SysV init scripts ;-)
[13:32] <ogra_> :)
[13:33] <jodh> xnox: yeah - not ideal.
[13:33] <xnox> ogra_: yeah + networkfs, raid (dmraid, btrfs, mdadm), lvm, cryptsetup and then you are done =)
[13:33] <dupondje> now its dirty situation imo
[13:33] <xnox> jodh: it works without a hitch for now. So it's not critical.
[13:35] <Debolaz> Daviey: We have had Ubuntu servers in this company before, but managing them was always a very manual process, and there wasn't really obvious value in getting landscape. It seems this is a fairly common experience.
[13:35] <dupondje> xnox: 'it works' ... :) but its not clean imo
[13:35] <dupondje> 4 init scripts for 1 thing
[13:35]  * dupondje not like :)
[13:36] <Daviey> Debolaz: When did you last use Landscape?
[13:37] <Debolaz> Daviey: I actually remember trying it a few months after it was released. It may have been a lot of improvements since then, but none of those are communicated through the website.
[13:37] <Debolaz> Its a fairly expensive application after all.
[13:38] <dupondje> jodh: any eta on shutdown support in Upstart ?
[13:38] <jodh> dupondje: not this cycle unless you're offering to help? :)
[13:39] <dupondje> If I had enough time .. :)
[13:39] <jodh> dupondje: snap ;-D
[13:39] <Daviey> Debolaz: Landscape has been around since, what.. 2007?  I'd hope it has imporved since then..
[13:39] <smoser> cjwatson, caribou has a mp at https://code.launchpad.net/~louis-bouchard/ubuntu/precise/grub2/grub2-recordfail-timeout/+merge/120562 that looks straight forward enough.
[13:40] <smoser> due to 12.04.1, should i hold out on uploading?
[13:40] <Debolaz> Daviey: It was probably around 2008 that I tried it.
[13:40] <smoser> or just assume that entry into -proposed is gated anyway atm.
[13:46] <cjwatson> smoser: It's fine to upload to -proposed
[13:47] <smoser> k. thanks.
[13:50] <cjwatson> After all it'll land in the queue anyway
[13:50] <cjwatson> If nothing else
[13:59] <mitya57> pitti: does the Jenkins server run autopkgtest >= 2.2.0 (so that $ADTTMP is available)?
[13:59] <pitti> mitya57: it runs whatever is in quantal, which is 2.2.3
[14:00] <mitya57> pitti: great, I do now have lp:~mitya57/ubuntu/quantal/sphinx/autopkgtests, now will test it and propose the merge
[14:00] <pitti> nice!
[14:04] <ev> mpt: for bug https://bugs.launchpad.net/errors/+bug/1020580, what do you think of http://errors.ubuntu.com/filter/Ubuntu 12.04/software-center/5.3.7, http://errors.ubuntu.com/filter/software-center/5.3.7, http://errors.ubuntu.com/filter/software-center, ...
[14:08] <dholbach> @pilot out
[14:08]  * ogra_ hugs dholbach 
[14:08]  * dholbach hugs ogra_ back :)
[14:08] <pitti> apw: hey Andy, how are you?
[14:09] <pitti> apw: may I ask about the current status of kmod? at this point it's probably too late to package the systemd source for udev for quantal, so I guess for Q we are staying at our old stuff?
[14:10] <apw> pitti, hiya, good thanks, and uyou
[14:10] <seb128> pitti, come on, you have 2 days to ff, you can do it :p
[14:10] <Debolaz> Btw, would be interesting to see zram enabled by default on Ubuntu desktops with less than 2 GB RAM.
[14:10] <apw> pitti, oh dammit that got stalled, do we hold kmod now or do you think its worth putting in
[14:11] <ogra_> Debolaz, apt-get install zram-conf
[14:11] <Debolaz> ogra_: You missed a word. :)
[14:11] <Debolaz> "default"
[14:11] <Debolaz> It's zram-config btw.
[14:11] <ogra_> right, file a whishlist bug :)
[14:11] <pitti> apw: I still think it's worth putting in; it unblocks the packaging and gets rid of the old m-i-t at least
[14:11] <pitti> seb128: well, I can give it a try of course
[14:12] <seb128> pitti, I was mostly teasing you but it would be good to get that update in if we can
[14:12] <Debolaz> ogra_: I'm thinking it could be a good thing because when I tried it on my 1 GB desktop, it gave it a monumental performance boost. Probably wouldn't make much difference if you had a lot more memory, but I'd say anywhere under 2 GB is probably going to be worth it.
[14:15]  * xnox is sad over bug 460906
[14:15] <xnox> s/to snapshot/to a random snapshot/ would be more correct
[14:15]  * xnox *sigh*
[14:53] <jdstrand> infinity: hey, I have a weird situation with hardening options
[14:53] <jdstrand> infinity: so, sbeattie uploaded https://launchpad.net/ubuntu/precise/+source/squid3/3.1.19-1ubuntu3 to enable hardening options
[14:54] <jdstrand> infinity: it built fine and then I ran 'hardening-check /usr/sbin/squid3' and it shows that PIE and BIND_NOW are enabled
[14:54] <jdstrand> (great!)
[14:54] <jdstrand> infinity: then, https://launchpad.net/ubuntu/+source/squid3/3.1.19-1ubuntu3.12.04.1 comes along and only changes the upstart job
[14:55] <jdstrand> infinity: I run 'hardening-check /usr/sbin/squid3' and it shows that PIE and BIND_NOW are disabled
[14:55] <jdstrand> (not great)
[14:55] <jdstrand> let me see something
[14:56] <jdstrand> ok, so using quantal's hardening check on the precise-updates binary, it still shows as not enabled
[14:59] <jdstrand> kees: ^ could this be a bug in hardening-check?
[15:00] <jdstrand> well, readelf -dW definitely is not showing BIND_NOW for the squid3 in precise-updates
[15:02] <jdstrand> ah, interesting
[15:03] <jdstrand> /usr/sbin/squid3 has 'Elf file type is DYN (Shared object file)' for the old squid3, but doesn't for the new
[15:03] <jdstrand> infinity: nm
[15:03] <jdstrand> well, for the moment
[15:04] <jdstrand> yes, 'readelf -lW' is giving different results
[15:05] <jdstrand> 'Elf file type is EXEC' vs 'Elf file type is DYN'
[15:06] <jdstrand> well, hold on. that would mean that the compiler didn't make it pie
[15:06] <jdstrand> infinity: ok, I think I need you again :)
[15:07]  * jdstrand compares build logs
[15:08] <tjaalton> does the installer image still have a 700MB budget?
[15:09] <Laney> I think we decided on 850MiB? (and should update the cdimage scripts to know about that)
[15:11] <dobey> i thought it was 1G but try to keep it as small as possible still
[15:13] <tjaalton> ok, asking because updating mesa to still use a common libgallium.so to save space might still take some time, so we could upload what we have and use "some" more space.. (dunno how much, yet)
[15:16] <jdstrand> hrm, there is nothing in the buildlog
[15:16]  * jdstrand files a bug
[15:17] <slangasek> tjaalton: we certainly have space to play with right now; I for one would rather have the new mesa in and worry about the size after
[15:19] <tjaalton> slangasek: great
[15:21] <tjaalton> slangasek: I'll upload it later this evening after some tests
[15:22] <mpt> ev, as with Launchpad, for before-and-after-release URL persistence (and predictable consistency with Launchpad), it might be better to use the release codename
[15:22] <slangasek> tjaalton: huzzah :)
[15:23] <ogra_> tjaalton, does the package have llvmpipe for arm enabled ?
[15:24] <tjaalton> ogra_: no, should it?
[15:24] <tjaalton> it's enabled on fedora
[15:24] <tjaalton> disabled here becase "no-one has tested it"
[15:25] <ogra_> no idea, i olny heard bad stuff yet :) ... but if we want to test it broadly now would probably be the time to enable it ... that leaves us more time later if we need to disable it again
[15:25] <tjaalton> maybe best to enable, what could possibly go wrong (worse)
[15:25] <tjaalton> :)
[15:25] <ogra_> right
[15:25] <tjaalton> alright, will enable it as well
[15:25] <tjaalton> no afk ->
[15:25] <ogra_> we can drop it again in the next upload
[15:25] <tjaalton> *now
[15:25] <ogra_> if it shows to be a disaster :)
[15:25] <ogra_> (which i actually suspect)
[15:28] <jdstrand> infinity: I subscribed you to bug #1039593. can you take a look when you have a moment-- seems like it might be a build issue...
[15:29] <jdstrand> kees: fyi ^
[15:33] <xnox> slangasek: do you mind if I merge hdparm
[15:44] <infinity> jdstrand: Erm...
[15:44] <infinity> jdstrand: I hate to question your science here, but:
[15:44] <infinity> However, 3.1.19-1ubuntu3.12.04.1 lost PIE and BIND_NOW, even though the only change was to the upstart job (see attached debdiff):
[15:44] <infinity> [...]
[15:44] <infinity> $ dpkg-deb -x /var/cache/apt/archives/squid3_3.1.19-1ubuntu2_amd64.deb files
[15:45] <infinity> ^-- What's wrong with this picture?
[15:45] <jdstrand> ah, hrm
[15:45] <jdstrand> ok, hold on :)
[15:46]  * jdstrand looks funny at his schroot
[15:47] <slangasek> xnox: no objection
[15:48] <jdstrand> infinity: man, I am an idiot. so, my chroot didn't have updates enabled, and then assumptions went from there
[15:48] <xnox> slangasek: ok. will do sometime before the freeze & hopefully fix the other bug assigned to me about that package.
[15:48] <slangasek> xnox: btw, I see the cryptsetup merge leaves the upstart job names as-is - did you and dupondje reach an agreement on this?  I thought he still wanted to change them
[15:49] <jdstrand> infinity: thanks for the look :)
[15:49] <xnox> slangasek: yes. see earlier discussion with dupondje, jodh and myself. The upstart jobs are used at the start-up, at shutdown/reboot upstart is killed, and then the both SysV init scripts are used to unmound cryptfs. Hence we need all four.
[15:49] <jdstrand> infinity: and for questioning my 'science'
[15:50] <xnox> s/unmound/unmount/
[15:50]  * xnox can't type properly all day. I wonder if my keyboard's battery is flat.
[15:50] <xnox> slangasek: so for now I am keeping all 4. When upstart will handle *all* of the shutdown, we can fully migrate.
[16:24] <Andy80> hi
[16:25] <iainfarrell> hi!
[16:25] <Andy80> anyone knows why, even if I'm subscribed to ubuntu-devel mailing list, every time the message I send are kept for moderation? I get this reson: The reason it is being held: Post by non-developer to moderated list. - how do I become part of the developer group? Thanks.
[16:29] <cjwatson> Andy80: https://wiki.ubuntu.com/UbuntuDevelopers
[16:29] <cjwatson> It's quite intentional that posts from non-developers are moderated - that was part of the charter of the ubuntu-devel list, as opposed to ubuntu-devel-discuss
[16:29] <slangasek> Andy80: you become part of the developer group by getting involved in Ubuntu development; I would suggest that you should have a stronger reason for doing this than wanting your posts to not be moderated, before you start down that process :)
[16:29] <cjwatson> Indeed
[16:35] <cjwatson> Andy80: I've moderated your post
[16:59] <ev> mpt: for what it's worth, we'll need named parameters after all. As we need to map the parameters they give us in the URL to the fields in the HTML, so the view stays consistent with the data we're fetching.
[17:12] <Andy80> slangasek: cjwatson sorry, I was away from keyboard. You're perfectly right. Anyway I'm actually interested in being involved in Ubuntu development :)
[17:12] <Andy80> now I will read the wik in the mean time
[17:15] <Andy80> cjwatson: thanks for approving the message :)
[17:38] <kees> jdstrand: er, the backlog is confusing. was there a bug in hardening-check?
[17:38] <jdstrand> kees: no. it was a bug in my process
[17:39] <kees> jdstrand: ah, okay. :P anything I can do to hardening-check to help with that?
[17:40] <jdstrand> kees: not unless you want to add an option to it to enable -updates in the schroot. and then have it know that is exactly what I need when I need it even though I might not be thinking about it :P
[17:40] <kees> jdstrand: heheh, okay. I wasn't sure what the mode of failure was :)
[17:40] <jdstrand> that might be hard to code
[17:40] <jdstrand> and a bit of a corner-case
[17:41] <kees> if [ "$USER" = "jdstrand" ]; then echo "hey, did you include -updates?"; fi
[17:41] <jdstrand> hehe
[17:41] <jdstrand> I'll pass on in-archive targeted trojans... err, workarounds :P
[17:42] <kees> hehe
[17:43]  * xnox ponders to include an eastern egg just for kees
[17:44] <kees> heh. I still want my unity fire easter egg.
[17:47] <xnox> kees: i wonder if anybody would notice an lvm2 file trigger to divert theme update after 1st of april  to do something like that.
[17:47] <xnox> kees: I remember the bug report about "ubuntu virus" which plays music when openning.... a webbrowser.... with pacman-flash google doodle....
[18:00] <kees> xnox: yes! the pacman day was great!
[18:02] <xnox> kees: I have pinged you about lvm2 a while ago, it's sorted now. So no worries ;-)
[18:04] <mitya57> doko: hi, can you please accept the patch from bug 1001585?
[18:04] <mitya57> doko: (I believe this affects 3.2 and 3.3 as well)
[18:04] <kees> xnox: ah yes. I was going to ask about that. sorry I was high-latency :)
[18:05] <kees> xnox: will you be at Linux Plumber's next week?
[18:06] <xnox> kees: sorry no, a bit too far from London =) slangasek might be there (?!)
[18:07]  * xnox or probably somebody else....
[18:07] <infinity> kees: stgraber and I will be there.
[18:08]  * xnox mutters something about north americans hosting most of the events and always doing stuff together....
[18:08] <seb128> xnox, we had the best even of the year in Europe though (GUADEC), your fault if you didn't come
[18:08] <seb128> ;-)
[18:09] <seb128> but I guess people living in the u.k don't like the europeans either :p
[18:09] <xnox> seb128: desktop.... that's not where the fun is at ;-) I have emacs, I don't need desktop ;-)
[18:09]  * xnox is not british though
[18:09] <seb128> hehe
[18:16] <davmor2> seb128: I'll have you know we hate everyone the same, there are no favourites in this country ;)
[18:29] <infinity> xnox: There's always FOSDEM.
[18:30] <kees> infinity: sweeeet
[18:31] <Andy80> I've seen that LightDM has a lightdm-qt subfolder http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/files/head:/liblightdm-qt/ what is it used for? Was it used for Unity-2D or is it another thing?
[18:37] <davmor2> Andy80: KDE maybe?
[18:38] <penguin42> Andy80: lightdm-kde-greeter links against liblightdm-qt-2.so.0
[18:40] <Andy80> davmor2: penguin42 ah it's a binding to use lightdm from KDE, ok.
[19:02] <infinity> seb128: BTW, your libsecret uploaded probably wanted a build-dep on dobcook-xsl.  Which still will fail anyway later in the build with dh_install --fail-missing having a hissy fit about some files not being installed.
[19:03] <seb128> infinity, thanks, will fix that, it's on my list of things to look at
[19:03] <seb128> (hate xml and dtds)
[19:06] <infinity> seb128: Well, I thought I'd do the docbook-xsl fix since it was an obvious 2-minute fix, but as I pointed out, that just fails later with: http://paste.ubuntu.com/1159563/
[19:06] <infinity> seb128: So, I'll let you clean that up. :P
[19:08] <seb128> infinity, thanks, seems like a side effect of Laney fixing vala
[20:32] <alkisg> larsu: sorry for the ping, I'm affected by LP bug #842768 in precise with gnome-fallback, should I reopen the bug for indicator-printers? Maybe there was a regression somewhere? (didn't try if they show up in Unity or not)
[20:32] <alkisg> "Lars Uebernickel (larsu) wrote on 2012-03-07: In precise, indicator-printers handles notifications. It doesn't show a notification in this case at all."
[20:33] <larsu> alkisg, does gnome-fallback use indicator-printers?
[20:33] <alkisg> larsu: I see it on my processes list
[20:33] <larsu> "printer may not be connected" is probably coming from the printer plugin in gnome-settings-daemon
[20:33] <alkisg> alkisg    2894  0.0  0.2  61120  9316 ?        Sl   10:40   0:01 /usr/lib/indicator-printers/indicator-printers-service
[20:34] <larsu> which shouldn't run at the same time as indicator-printer
[20:34] <alkisg> What's I'm seeing is "Error: connecting-to-device"
[20:34] <alkisg> (while printing is fine)
[20:34] <alkisg> alkisg    2052  0.0  0.5 259328 22408 ?        Sl   10:40   0:24 /usr/lib/gnome-settings-daemon/gnome-settings-daemon
[20:34] <alkisg> alkisg    2425  0.0  0.1  49836  4180 ?        Sl   10:40   0:00 /usr/lib/gnome-settings-daemon/gsd-printer
[20:35] <alkisg> Hmm so the problem is deeper, that one of gnome-settings-daemon or indicator-printers should be running?
[20:36] <larsu> alkisg, yep, gsd-printer shouldn't be running
[20:36] <larsu> let me find out why it is
[20:36] <alkisg> Thank you
[20:42] <larsu> alkisg, do you have dconf-editor installed?
[20:42] <alkisg> larsu: yes
[20:43] <larsu> cool, set org.gnome.settings-daemon.plugins.print-notifications.active to false
[20:43] <alkisg> larsu: do I need to logout to test?
[20:44] <larsu> alkisg, don't know tbh :)
[20:44]  * alkisg tests directly first...
[20:44] <larsu> thanks
[20:44] <alkisg> Ouch apport window about gnome-settings-daemon
[20:45] <alkisg> (when I powered on the printer)
[20:45] <larsu> urgh
[20:45] <larsu> well I guess logout to test :)
[20:45] <alkisg> ok, brb
[20:45] <larsu> (definitely worth filing a bug, though)
[20:49] <alkisg> ...I think I got a different printer icon now in the notification area... and no message about printing, problem solved!
[20:50] <alkisg> Now to make gnome-fallback enforse that setting?
[20:51] <larsu> alkisg, cool. Can you post a comment on the bug please? (Because I don't know how to set that as default)
[20:51] <larsu> I'll ping the right people in the morning
[20:51] <alkisg> larsu: sure, thank you again
[20:51] <larsu> alkisg, np, glad I could help
[21:00] <verwilst> hello! could somebody put the status of the bugreport to confirmed here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1020207 i kinda messed up :(
[21:00] <verwilst> the fix isnt released ;)
[21:07] <tumbleweed> verwilst: done
[21:07] <verwilst> thanks tumbleweed :)
[21:10] <kenvandine> barry, FYI, that online-accounts branch is now merged into trunk
[21:10] <barry> kenvandine: great!  i'm still slowly but surely making progress on my branch.  probably won't be ready for ff though :/
[21:10] <kenvandine> ok
[21:11] <kenvandine> thanks!
[21:11] <barry> sure thing!  i have a few more dbus services to port and then it might be fun to try to integrate the front-end with the new gwibber-service
[21:12] <kenvandine> barry, I uploaded python3  fixes for the gi.overrides from libaccounts-glib and libsignon-glib today
[21:12] <kenvandine> those would have broken you for sure
[21:13] <kenvandine> not sure if you had hit those errors yet
[21:13] <barry> kenvandine: cool.  btw, is there documentation for those libraries available?
[21:13] <kenvandine> barry, you are funny...
[21:13] <barry> kenvandine: not yet
[21:13] <barry> ;)
[21:13] <kenvandine> there are gtk docs
[21:13] <kenvandine> libaccounts-glib-doc
[21:14] <kenvandine> libsignon-glib-doc
[21:14] <kenvandine> that is about it
[21:14] <kenvandine> so far
[21:14] <barry> hey, it's a start! :)
[21:18] <tjaalton> slangasek: need to push the mesa upload for tomorrow, some rpath issues remain
[21:18] <slangasek> tjaalton: anything I could help with?
[21:19] <tjaalton> slangasek: you can test build from git, the upstream libdricore implementation seems to use rpaths
[21:19] <slangasek> tjaalton: and this shows up as a lintian warning, or somewhere else?
[21:19] <tjaalton> yup
[21:19] <slangasek> ok
[21:19] <tjaalton> error actually
[21:22] <slangasek> tjaalton: interestingly, llvm is also needed for building the radeonsi driver; should the driver be made x86-only, or should the build-dep be added?
[21:22] <slangasek> (this is from an armhf test build just now - I know we'll add llvm-3.1 for armhf anyway for llvmpipe, but that's separate)
[21:22] <tjaalton> probably doesn't make sense to build it on arm
[21:23] <tjaalton> oh
[21:23] <tjaalton> right, the build-dep needs to be added
[21:23] <tjaalton> since ogra_ wanted to build llvmpipe for armhf
[21:23] <slangasek> yes
[21:24] <slangasek> but that's separate from whether we should build radeonsi on !x86
[21:24] <slangasek> I don't know what kind of device radeonsi is
[21:24]  * doko wonders if somebody maintains llvm for this kind of use ...
[21:24] <tjaalton> radeon southern island
[21:25] <tjaalton> some new chip gen
[21:26] <tjaalton> slangasek: it builds all kinds of silly drivers on archs that have never seen the hw.. :)
[21:27] <tjaalton> that said it's easy to make it build only on x86
[21:27] <slangasek> tjaalton: sure; generally the rule is that if it's physically *possible* to have the hardware on the arch, we should build it
[21:27] <slangasek> (the rule in Debian, anyway)
[21:28] <tjaalton> right, ok
[21:30] <tjaalton> slangasek: feel free to commit anything, I've had enough of this day :)
[21:30] <slangasek> ack :)
[21:31] <tjaalton> i'll check back in ~7h
[21:49] <adam_g> is there anything blocking bug #1021530 from release into precise-updates? i just re-targetted toward precise-updates (was previously targetted @ 12.04.1)
[21:58] <shadeslayer> hi, I was wondering if someone could point me to where ubiquity picks up the RELEASE variable?
[21:58] <slangasek> tjaalton: ok, it looks like the radeonsi driver is only buildable if using gallium llvm generally, so we don't really want that... I'll disable the driver on !x86 for now
[22:14] <xnox> shadeslayer: yeah good question.
[22:15] <xnox> shadeslayer: /cdrom/.disk/info
[22:15] <xnox> shadeslayer: see misc.py
[22:17] <shadeslayer> ah ok
[22:19] <TREllis> 10
[22:19] <TREllis> bah
[22:19] <TREllis> :)
[22:27] <shadeslayer> xnox: thanks
[22:27] <xnox> shadeslayer: your welcome
[22:28]  * shadeslayer goes off to find what casper-uuid-generic is
[22:30] <shadeslayer> cjwatson: any progress on the live build merge?
[22:56] <cjwatson> shadeslayer: almost done, but I found this afternoon that its handling of chroot hooks was broken, so I fixed that, started a test build, and then went out to dinner
[22:57] <shadeslayer> ah alright
[22:57] <shadeslayer> cjwatson: since the live build was broken, I've hacked my own scripts to do the customization
[22:57] <cjwatson> so should be able to upload that stack tomorrow morning
[22:57] <shadeslayer> now fiddling with casper-new-uuid
[22:57] <shadeslayer> awesome
[22:58] <cjwatson> I don't think there was much else broken, though I'll do another diff of file lists to make sure
[22:58] <shadeslayer> hmm, I hope it makes ISO's bootable
[22:59] <shadeslayer> though that'll mean throwing away the last 20 hours of work :P
[22:59] <cjwatson> I don't know, but I'll be happier to spend time investigating on the new base
[23:00] <shadeslayer> :)
[23:00] <shadeslayer> tried hexdumping the fedora ISO?
[23:00] <cjwatson> no
[23:00] <cjwatson> enotime as yet
[23:00] <shadeslayer> hehe :)
[23:25] <penguin42> what would cause a mismatch of -dbgsym for apparently matching package versions: warning: the debug information found in "/usr/lib/debug//usr/bin/chuck.alsa" does not match "/usr/bin/chuck.alsa" (CRC mismatch).
[23:31] <xnox> penguin42: version scew between package & dbgsym package.
[23:32] <xnox> penguin42: upgrade & try again
[23:32] <xnox> penguin42: or rebuild locally in sbuild to get the package & matchin dbgsym package
[23:32] <penguin42> xnox: Same version numbers on both, both freshly installed
[23:33] <xnox> penguin42: something diverted /usr/bin/chuck.alsa and now debug symbols do not match cause it's a different binary?
[23:33] <penguin42> xnox: It's possible the package does something odd to get the chuck.alsa and chuck.oss etc
[23:34] <xnox> penguin42: yes. there are packages that create bad -dbgsym package. In that case do open launchpad bug, to blacklist that package from generating dbgsym.
[23:35] <xnox> penguin42: DEB_BUILD_OPTIONS=nostrip ./debian/rules binary
[23:35] <xnox> penguin42: is your best option ;-)
[23:36] <penguin42> yeh, I might try buildign it locally; I was just triaging some ancient bugs - found this one which is a trivial seg - 3 years old and was still at new/undecided
[23:37] <penguin42> there are a few gems in the older bugs - lots and lots of package install and probably fixed bugs, but some fun ones