[02:55] <ScottK> xnox: What's your plan for quantlib?  Your upload's been sitting in saucy-proposed FTBFS for almost a month.
[03:20] <infinity> ScottK: I'm guessing that'll need some TLC to sort out why the testsuite is hanging. :/
[03:22] <infinity> ScottK: It's possible that reverting to gcc-4.7 might make it happy for now, at least, though that won't make doko happy.
[03:22]  * infinity tries that locall.
[03:22] <infinity> y
[03:38] <pitti> Good morning
[05:26] <didrocks> xnox: hey, I would prefer a step by step for https://wiki.ubuntu.com/DailyRelease/FAQ#I.27m_exposing_a_new_C.2B-.2B-_symbols_in_my_library.2C_it_seems_that_some_packaging_changes_are_needed.2BICY- as upstream doesn't really know what a symbol files is, so better to put all commands to guide them (and replace the version with 0replaceme for new symbols, how they can see them and so on)
[06:30] <tjaalton> pitti: if your arrandale laptop is on saucy there's a new mesa update available which hopefully fixes the slow blur properly :)
[06:30] <tjaalton> dash blur
[06:31] <pitti> tjaalton: oh, nice! I got some new Xorg-ish packages this morning, but haven't rebooted yet
[06:33] <tjaalton> yeah new -intel minor bump too
[07:09] <dholbach> good morning
[07:14] <tjaalton> pitti: looks like blur is slow on sandybridge again with the new mesa
[07:14] <tjaalton> so it's not actually fixed in the stable tree
[08:15] <ev> wgrant, StevenK: looks like we're nearly there with ddebs in the librarian (if LP bugs is any guide). Thanks for the hard work!
[08:33] <wgrant> ev: Yeah, just the one known issue left
[08:33] <ev> bug 1179329?
[08:34] <ev> and woohoo
[08:39] <ev> Does anyone know of a hackish way around "The build target must not do anything that might require root privilege." in 4.9 of Debian policy? As part of a package of test crash reports, I'm attempting to install a package that purposefully crashes in its postinst.
[08:45] <cjwatson> ev: manually run stuff in fakeroot?
[08:45] <cjwatson> ev: (note, you don't get real root in the binary target either)
[08:47] <ev> cjwatson: you mean with a chroot? dpkg isn't going to be happy that it cannot write to a number of places.
[08:48] <ev> even after I -o away the ones I can.
[08:48] <cjwatson> LD_PRELOAD
[08:48] <cjwatson> I mean, you can't do any better, if you want to do this in a package build
[08:48] <cjwatson> Leaving aside policy 4.9, you *don't have root* at any point in the build that you control ...
[08:48]  * ev nods
[08:49] <cjwatson> I know that it's possible to LD_PRELOAD dpkg sufficiently, because I did it in lp:click-package :-)
[08:49] <ev> all these years complaining about dpkg running maintainer scripts as root, I guess I deserve this ;)
[08:49] <cjwatson> You can borrow from that if it helps
[08:49] <ev> cjwatson: oooh, will do; thanks!
[08:50] <cjwatson> (There's some extra kind of mini-sandboxing stuff you don't need)
[08:51] <infinity> ev: fakechroot might be enough for what you want.
[08:51] <infinity> But installing a package during a package build just seems wonky on a few levels. :P
[08:55] <cjwatson> fakeroot fakechroot gets you most of the way there, yes.  I think it was (a) slightly inadequate for me in some way I forget and (b) slow to stack up all the external helpers, so I just rolled my own
[08:56]  * StevenK twitches at the memories of attempt to hack moblin-image-creator to work under fakeroot and fakechroot
[08:57] <cjwatson> infinity: Test suite, I expect
[08:58] <cjwatson> ev: Mind you, if you care about having the maintainer scripts actually run, you'd be better off using fakeroot and fakechroot than my stuff.  I had the luxury of being able to just turn off chroot and execvp.
[08:58] <infinity> cjwatson: Yeah, I assumed it was a testsuite, it still feels hackishly evil to require "root" in a testsuite. ;)
[08:59] <infinity> (Unless it's real root, which is entirely valid for some kernel testsuites and such)
[08:59] <infinity> Can't dep-8 specify wanting root for tests?
[09:00] <cjwatson> Yes.
[09:00] <infinity> ev: Might it not be better to just do a dep-8 test with real root, instead of trying to do this at build time?
[09:00] <cjwatson> I'd personally prefer doing things without requiring that, but each to their own.
[09:00] <infinity> ev: If it's going to blow up the dpkg DB, "Restrictions: needs-root breaks-testbed" looks appropriate.
[09:01] <pitti> however, ev's test-crashes package just lives in a PPA AFAIK, it's not actually in Ubuntu
[09:01] <pitti> we can run DEP-8 tests from selected PPAs, though, so it might still be an option
[09:02] <infinity> cjwatson: I'm of two minds.  I'm all for not requiring root to test things, but there's also the reality that when you abstract and synthesize a little too much, you lose all the fun corner cases of the original test conditions.
[09:02] <infinity> (And synthesizing root definitely can fall under that umbrella, since you end up faking a bunch of calls that you might otherwise have broken something with)
[09:14] <NikTh> Hello. Can someone tell me why the "~" character is not allowed in package name ? Read here another build failure of mine. https://launchpadlibrarian.net/140581585/buildlog_ubuntu-raring-amd64.linux_3.8.0-999~bfsbfq1_FAILEDTOBUILD.txt.gz
[09:14] <xnox> didrocks: the c++ specific symbols go right after the "how to add c symbols", I'm not sure it makes sense to copy & paste and repeat the same information twice. Hence the c++ answer starts with "similar to above,..."
[09:15] <didrocks> xnox: from my knowledge, upstream doesn't really go through and won't look at it. They are looking for step by step instructions
[09:15] <didrocks> it's already hard to have them reading the documentation (again illustrated yesterday :p)
[09:15] <didrocks> so let's make this as simple as possible for them
[09:17] <cjwatson> NikTh: Er, it just isn't
[09:17] <cjwatson> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source has the rules for package names
[09:19] <infinity> NikTh: If you make that 3.8.0-999.1~bfsbfq1, you'll be fine.
[09:19] <infinity> NikTh: Understanding how the kernel package does ABI/build numbering is helpful here.
[09:20] <infinity> NikTh: But might I also point out that you're perhaps doing a disservice to your users by jacking up the version number on -generic unless you intend to rebase for every single security upload as soon as we release...
[09:20] <infinity> NikTh: (A different flavour entirely, so they know what they're getting into might be better, I dunno)
[09:20] <NikTh> infinity: exactly. I thought this too. Because I have already uploaded a package with this.. tilda (I think is the name) character inside and I had no problem. 3.8.0-21.32nikth1~bfsbfq1
[09:21] <infinity> NikTh: 3.8.0-21 is the kernel ABI in that example, .32nikth1~bfsbfq1 is the build ID.
[09:21] <infinity> NikTh: The first part ends up in the binary package names, the latter part is only in the versions.
[09:21] <infinity> NikTh: It splits on the first '.' after the '-'
[09:21] <NikTh> I want to upload a completely different version, so I changed the ABI. I don't want users to upgrade the official ubuntu kernel with mine. I want to install it (if they want) by hand. Manually
[09:22] <infinity> NikTh: Notice how the official kernel packages are versions like: "3.8.0-21.32" and "3.8.0-21" is in the package name, but ".32" isn't.
[09:24] <NikTh> What name you suggest infinity
[09:25] <NikTh> infinity: to achieve my goal. Not upgrade the Ubuntu official kernel when users add my PPA, but install a new kernel instead
[09:25] <cjwatson> Haven't people suggested several times that for kernel-specific questions you should use #ubuntu-kernel, BTW?
[09:26] <cjwatson> (Because this line of questions is absolutely an artifact of things that are specific to the kernel packaging)
[09:26] <NikTh> cjwatson: I thought this was a debian package system error.  But I will ask there too. Thanks
[09:26] <cjwatson> It is not, it's kernel-specific.
[09:27] <cjwatson> As has been pretty much everything you've asked about over the last few days :)
[09:27] <cjwatson> The kernel has very complex packaging that needs to be tickled just right
[09:28] <mlankhorst> first sign of kernel developer, perceiving inanimate kernels as alive?
[09:29] <pitti> Don't anthropomorphize computers, they don't like that!
[09:29] <StevenK> pitti: Haha
[09:49] <xnox> didrocks: collapsed both c & c++ answers into a single symbols question on the wiki, with caveats and links to further reading.
[09:49] <didrocks> xnox: ok, will give a look later, thanks!
[10:15] <mpt> ev, any idea why Ubuntu 12.10's error rate has plummeted since the last week of April?
[10:16] <davmor2> mpt: every moved to 13.04 it's better
[10:16] <davmor2> mpt: everyone even
[10:17] <mpt> ooh, that might actually be it
[10:17] <mpt> People upgrading and the error tracker hasn't yet realized they aren't using 12.10 any more
[10:17] <ev> mpt: I'm not sure. It's surprising, given that awful "oh you want to upgrade? Sorry pal, not happening" bug.
[10:17] <mpt> ev, how does the ID work on upgrades? Does it stay the same?
[10:18] <ev> mpt: by ID do you mean at what point does the release change for new crash reports on the system during an upgrade?
[10:18] <mpt> That might also explain the (lesser) dip in 12.04's error rate when 12.10 came out
[10:19] <mpt> ev, no, at what point (if any) does the machine ID change.
[10:19] <ev> it never changes
[10:19] <ev> purposefully
[10:19] <ev> it's based off a value in the DMI tables
[10:19] <ev> the system uuid, sha512 hashed
[10:20] <mpt> ev, good, so, as soon as we get a report from a machine release N+1 do we remove it from the count of machines known to be running release N?
[10:21] <ev> mpt: in the calculation for the number of unique machines seen in a 90 day window?
[10:21] <mpt> ev, yes.
[10:21] <ev> mpt: no - I suppose we could take the set difference, working backwards
[10:22] <ev> so figure out the unique machines seen in Saucy in the past 90 days, hold those in memory, then figure out the machines seen in Raring in the past 90 days, removing any that are present in the Saucy list
[10:23] <mpt> something like that
[10:23] <ev> I'm just wondering if the 90 days part breaks that
[10:23] <ev> hmm
[10:25] <ev> no, I think we're okay. It's simply preventing double counting a machine against two releases.
[10:25] <ev> filing a bug
[10:25] <mpt> I'm already doing it :-)
[10:25] <ev> ah excellent
[10:26] <ev> I do wonder what the effect will be for issues like the upgrader bug
[10:26] <ev> we'd be counting those machines for Raring, even though the issue happened in Quantal
[10:26] <ev> because they were seen on that day as using Quantal, assuming they found a way around the upgrade problem
[10:28] <mpt> bug 1183759
[10:31] <mpt> If that's the cause of the 12.10 slump (and the bug isn't fixed first), the 12.10 error rate will return to ~0.05 towards the end of July.
[10:51] <cjwatson> RAOF: Could you merge libxfixes?  I'm touched-it-last, but only for a rebuild; the substantive changes are yours.
[10:56] <xnox> ev: how is release detected? i'm running a mixed saucy/raring install and I did not use upgrade-manager to upgrade.
[10:56]  * xnox 'd like to know if I am counted as raring or as saucy.
[10:57] <ev> xnox: whatever is in lsb-release/os-release, I imagine
[10:57] <xnox> saucy, all good.
[11:34] <cjwatson> I fear I may have temporarily made texlive-base uninstallable in the next publisher cycle.  It shouldn't be a big problem except for people installing saucy or upgrading to saucy in the relevant window (upgrades within saucy won't be affected, as far as I can make out), and it ought to fix itself after the next proposed-migration run and publisher cycle.
[11:34] <cjwatson> Sorry about that.
[12:18] <sil2100> cyphermox: hi! I just checked https://code.launchpad.net/network-manager and noticed that the importer failed importing for git over 5 times
[12:26] <maxb> sil2100: Check the logs:
[12:26] <maxb> 2013-05-22 11:48:25 INFO    Unable to import branch because of limitations in Bazaar.
[12:26] <maxb> 2013-05-22 11:48:25 INFO    The repository you are fetching from contains submodules, which are not yet supported.
[12:39] <pitti> cjwatson: wow, apologizing for 30 minutes of minor installability breakage in a cycle is a really nice testament to how far we've come!
[12:47] <cjwatson> Heh, yeah.  Hopefully it was just that; unfortunately once you break something proposed-migration will basically do whatever it takes to improve things, so it's hard to see what may have broken as a result.  The total uninstallable count appears to have gone up by one per architecture ...
[12:48] <cjwatson> Can't quite work out what though
[12:48] <cjwatson> Processing NBS to see if that helps
[12:52] <ev> drat. I got so far with a few fakeroot fakechroot lines and then hit the wall that is needing /proc in the chroot.
[12:52] <pitti> ev: you can create a /proc -> /proc symlink in the fakechroot
[12:52]  * ev beats his head on the desk
[12:52] <pitti> (at least that worked a few years ago when apport's retracers were still using fakechroot)
[12:52] <ev> thanks pitti
[12:53] <pitti> it looks recursive, but back then it was acting like pointing "outside" the fakechroot into the real fs
[13:31] <hallyn> when installing a new package which has preinst and postinst, as well as an upstart job, will the upstart job be started after preinst and before postinst?  (I should think so, but wanted to make sure)
[13:32] <pitti> that surely depends on the start condition?
[13:32] <pitti> jodh: ^
[13:42] <rbasak> Doesn't the upstart job get started _by_ the postinst, usualy courtesy of debhelper? Or does it work differently with upstart, or have I completely misunderstood the question?
[13:43] <cjwatson> The upstart job is indeed normally started by the postinst
[13:43] <hallyn> rbasak: no, that's the question...  the issue is lxc.preinst is setting up /etc/default so that the lxc-net.conf upstart job can start lxcbr0 - but lxcbr0 is not being started.
[13:43] <hallyn> until you reboot or manually restart lxc-net
[13:43] <cjwatson> It would be incorrect for it to be started before the postinst, in general, because the package is unconfigured then
[13:44] <cjwatson> hallyn: It's your postinst's responsibility to do that.  Is this an upstart-only job though?
[13:44] <cjwatson> Yeah, it is
[13:44] <cjwatson> I think there are some (unfiled?) problems with upstart-only jobs at the moment
[13:45] <cjwatson> 20:36 <infinity> slangasek: Does dh_installinit need a bit more mangling for the upstart-only case now that the upstart-job links disappeared?
[13:45] <hallyn> ah
[13:46] <rbasak> Ah - so nothing is starting the upstart-only job in hallyn's postinst?
[13:46] <hallyn> cjwatson: to be clear - the #DEBHELPER# should insert the necessary code if dh_installinit is being used, right?  I don't then ahve to manually do it in postinst?
[13:46]  * hallyn looks up
[13:46] <cjwatson> Indeed, you shouldn't have to do this manually, it's a debhelper bug
[13:47] <hallyn> is there an open bug for this?
[13:48] <cjwatson> I don't see one
[13:49] <cjwatson> Let me see, maybe it's not too hard
[13:49] <hallyn> ah, found the backlog.  Note everyone uses UTC for their irc log timestamps? :)
[13:49] <hallyn> cjwatson: just wanted to mark bug 1183807 a dup of it if there was one
[13:52] <cjwatson> I've added a debhelper task
[13:52] <cjwatson> lxc will need to be rebuilt after it's fixed though
[13:54] <hallyn> cjwatson: great, thanks
[13:56] <cjwatson> hallyn: Fancy trying http://paste.ubuntu.com/5697031/ ?
[14:01] <hallyn> building
[14:07] <hallyn> d'oh, clerical error.  retrying
[14:09] <hallyn> (had built debhelper, then built lxc... without installing the debhelper pkg :)
[14:10] <hallyn> alas, still no lxcbr0
[14:11] <hallyn> cjwatson: ^ :(
[14:11] <cjwatson> hallyn: Can you put the resulting .deb somewhere for me?
[14:12] <hallyn> cjwatson: but the test in http://paste.ubuntu.com/5697031 is for '-x /etc/init.d/*.conf', but none of those are executable
[14:12] <hallyn> sure, you mean the lxc deb right?
[14:13] <hallyn> cjwatson: http://people.canonical.com/~serge/lxc_0.9.0-0ubuntu9_amd64.deb
[14:18] <cjwatson> hallyn: No, the test is -e /etc/init/*.conf ...
[14:18] <cjwatson> (ignore the LHS)
[14:19] <cjwatson> oh, it's not being substituted properly
[14:21] <cjwatson> hallyn: http://paste.ubuntu.com/5697103/
[14:37] <aa10123> wedgwood:
[14:40] <hallyn> cjwatson: success!
[14:40] <hallyn> no wait
[14:41] <hallyn> yup, success
[14:47] <cjwatson> hallyn: OK, thanks - uploaded
[14:48] <bdmurray> doko: dobey mentions that bug 1171568 was fixed by a version of sqlite3 in saucy.  could we get that SRU'ed?
[14:49] <hallyn> cjwatson: so lxc needs a rebuild-only upload?
[14:51] <cjwatson> hallyn: It will do after debhelper has built and published
[14:53] <hallyn> great, thanks
[15:22] <xnox> bdmurray: I disagree, that it fixed anything.
[15:22] <xnox> still FTBFS in sbuild here.
[15:24] <xnox> commented on the bug report.
[15:27] <bdmurray> xnox: kay, thanks
[15:37] <tvoss> slangasek, ping
[15:42] <cjwatson> hallyn: you can safely upload lxc now
[15:42] <cjwatson> roaksoax: ^- you were asking about what turned out to be the debhelper part of bug 1183807 the other day too - fixed now
[15:47] <hallyn> cjwatson: oh, i misunderstood you before then.  ok, will upload
[15:48] <cjwatson> misunderstood how?  (out of interest)
[15:49] <roaksoax> cjwatson: awesome! thanks!
[15:50] <hallyn> cjwatson: "hallyn: It will do after debhelper has built and published" I thought you meant a rebuild will be triggered automatically
[15:50] <hallyn> :)
[15:50] <cjwatson> Oh I see
[15:50] <cjwatson> Sadly we don't have automatic rebuild support
[15:50] <cjwatson> So the best I could have done (but didn't) would have been cron.cjwatson ;-)
[15:53] <hallyn> :)  cool, pushed.
[15:53] <hallyn> still don't see why pull-lp-source is being so flaky for me, on several (but not all) hosts.  I'm just defaulting to dget from the launchpad publishing history
[16:29] <tvoss> slangasek, ping
[17:02] <alexbligh> When building stuff with pbuilder etc., how does it persuade debootstrap to use (e.g.) precise-updates as well as precise. IE how do you know you aren't building using a buggy version of gcc or against a buggy static library?
[17:03] <dobey> alexbligh: i run pbuilder-update before every build. but precise has -updates and -security enabled by default, so the chroot will also have them enabled by default. just run the update regularly
[17:06] <alexbligh> OK - so it relies on pbuilder-update. Thanks. I was hoping there was a way to persuade debootstrap to produce up to date builds out the box. Oh well. I think I need to try multistrap then.
[17:08] <cjwatson> I know pbuilder is hideously inefficient but it doesn't debootstrap every time.
[17:08] <cjwatson> That would be a bit much.
[17:08] <slangasek> tvoss: hi
[17:09] <alexbligh> cjwatson, nah I was seeing whether pbuilder had solved the problem I was looking at. I want to do a debootstrap (or better a cdebootstrap) to build an image using precise AND precise-updates. I was just hoping someone had fixed this for pbuilder.
[17:09] <slangasek> cjwatson, infinity: hmm, evidently I missed that dh_installinit question before... so under Debian policy, there should no longer be any "upstart-only" jobs, but I believe the dh_installinit bits were written to work anyway if you do have one
[17:10] <cjwatson> You definitely shouldn't use cdebootstrap for anything - it's obsolete.
[17:10] <cjwatson> The last useful innovation it introduced was incorporated into debootstrap in 2005.
[17:11] <alexbligh> cjwatson, the innovation I want is looking at more than one repo. But I don't think it does that either.
[17:11] <cjwatson> For debootstrap I'd probably just write a trivial wrapper which makes sources.list look the way you want it and then run an update.
[17:13] <alexbligh> that actually doesn't work well. Firstly, my image which I am trying to keep small ends up with the ghosts of packages removed. Secondly there are packages like linux-image-current-generic which are not actually in precise, but that's (obviously) exactly what you want to install. 2 kernel packages inflates the size of the image quite a lot.
[17:13] <alexbligh> I am trying to get away from running anything in the image (chroot or otherwise).
[19:05] <phillw> Hi, sorry about this, as I am sure I have asked before.. is the usage of xdg-open no longer suggested for 'quick-links' such as those on "Easy Install" https://help.ubuntu.com/community/RestrictedFormats
[19:16] <mterry> @pilot in
[19:38] <genii-around> I want to modify the !wubi factoid but would like to double-check here for facts...   as I understand, wubi is no longer supported from 13.04 onwards, but I still see it for instance at http://releases.ubuntu.com/raring/wubi.exe  . So: Is it in fact dropped, or no longer in the iso image? Also, does the wubi.exe for Raring work or is it some carryover from previous versions?
[19:39] <slangasek> genii-around: it was released with 13.04, but has been de-emphasized on the website due to the lack of support for Windows 8 / SecureBoot
[19:41] <genii-around> slangasek: OK, thanks. Will it be in Saucy ?
[19:41] <slangasek> genii-around: I expect it will be; there seem to be developers committed to keeping it in working order
[19:42] <genii-around> OK. Thanks again
[19:42] <phillw> hi slangasek sorry to attempt a kidnap, but is xdg-open no longer used?
[19:43] <slangasek> phillw: can't say I know the answer to that; I've never used it directly
[19:43] <slangasek> phillw: it's certainly still part of the ubuntu-desktop seed, so I don't know of any reason it would be "no longer used"
[19:44] <phillw> slangasek: so, I should report a bug as to it not working?
[19:44] <lifeless> phillw: of course
[19:44] <phillw> I'll try it in FFox and Chomium.
[19:46] <slangasek> phillw: if it's not working, then yes, that's a bug
[19:46] <slangasek> whether the bug is resolved by fixing the tool or removing it, is for the developers to decide
[20:05] <phillw> slangasek: It seems to be a chromium bug, Firefox does not report it. as ubuntu are considering using chromium I will report it against that. As ever, thanks for the input :)
[20:24] <TheLordOfTime> slangasek:  are you able to confirm that 'ubuntu-bug' is correctly checking versions of packages?  also, can you dig around on the saucy archive and confirm that the version of "chromium-browser" in saucy is 25.0.1364.160-0ubuntu3 ?
[20:25] <TheLordOfTime> slangasek:  phillw tried `ubuntu-bug chromium-browser`and it said they were using a third-party package.
[20:25] <cjwatson> Doesn't require any privilege to dig around.  $ rmadison -s saucy chromium-browser
[20:25] <cjwatson> chromium-browser | 25.0.1364.160-0ubuntu3 | saucy/universe | source, amd64, armhf, i386
[20:25] <cjwatson> (I'm not going to look at ubuntu-bug at the moment though, end-of-day)
[20:26] <TheLordOfTime> cjwatson:  no, but it needs access to the internet beyond what I can do via SSH-to-my-system-from-my-phone
[20:26] <TheLordOfTime> okay, that's what i thought, if ubuntu-bug had randomly broken, i'd be appalled and probably be the first to complain :P
[20:27] <shakaran> Hi, I notice that apport detects crashes in 13.10, but after send the report it nevers open the browser in launchpad. How I can trace/fix this wrong behaviour?
[20:27] <TheLordOfTime> i'm not as familiar with bug triage for "Update software to X.Y.Z" bugs, should this be Wishlist / Triaged, or at least "wishlist"?  https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1183086
[20:30] <TheLordOfTime> actually, regarding that bug there... has anyone tested the version of that in debian unstable on 13.04?
[20:30] <TheLordOfTime> according to packages.qa.debian.org, unstable has 27.0.1453.93-1 in unstable.
[20:30] <TheLordOfTime> s/13.04/13.10/
[20:30]  * TheLordOfTime groans at his fail.
[20:31]  * ScottK looks around for the LART.
[20:40] <stgraber> slangasek: hey, so I ended up being TIL on nfs-utils after sponsoring a small patch last cycle. I have done the merge here but can't easily test it and that's a new upstream version with quite a bunch of changes on the Debian side.
[20:41] <slangasek> stgraber: can you throw it up as a UDD mp for me to look at later?  Probably not until Monday evening - I won't get to it today and I'll be away from home all weekend
[20:41] <stgraber> slangasek: sure
[20:42] <shakaran> If there are some eclipse ubuntu maintainer here, just bumping this https://bugs.launchpad.net/eclipse-ubuntu/+bug/1183998
[21:05] <stgraber> slangasek: Launchpad encountered an internal error during the following operation: generating the diff for a merge proposal.  It was logged with id OOPS-69c17ff685621f498e8fd63388bec9ff.  Sorry for the inconvenience.
[21:06] <stgraber> slangasek: got that from LP after I sent the MP, so looks like you won't have a diff, sorry
[21:11] <slangasek> stgraber: heh, that's fine; I was going to pull it down and review+build+install anyway
[21:25] <stgraber> slangasek: oh, I see the problem, LP assumed I wanted to merge my branch into lp:debian/nfs-utils, will retarget the MP, that may end up fixing the diff as a side effect
[21:31] <mterry> @pilot out
[21:32] <slangasek> stgraber: ok, cool
[21:36] <infinity> Man, I wish compiz would crash more today, it's really exciting...
[21:49] <phillw> infinity: I can try in VM if there are any cases you wish testing
[21:59] <slangasek> infinity: bug #1181717? or another?
[22:00] <infinity> slangasek: That'd be the one.
[22:02] <slangasek> infinity: this looks suspiciously like a gobject/gint casting failure; are you on amd64 too?
[22:03] <infinity> slangasek: I am, yeah.
[22:03] <infinity> Bug #1181324 is driving me nuts too, but only in that "gah, apport, stop yelling at me" way, whereas the compiz one is actually preventing me from working. :P
[22:04] <infinity> Well, the second one's preventing me from watching movies after work which is, arguably, almost as important for my sanity.
[22:05] <slangasek> right
[22:07] <infinity> Also vaguely related, anyone know how to get my indicator panel back after a total unity explosion, or am I going to have to log out?
[22:08]  * infinity sucks it up and starts closing windows to log out.
[22:08] <slangasek> well, in my total explosions, compiz has died and left me with no control via X, so I've switched to vt1 and respawned it; that lets compiz run but doesn't have the right dbus environment for the rest
[22:08] <jcastro> infinity: `setsid unity` ftw
[22:08] <jcastro> always works for me
[22:09] <infinity> slangasek: Ctrl-Alt-T still worked enough for me to re-run unity.
[22:09] <slangasek> hmm
[22:09] <slangasek> so maybe Ctrl-Alt-T is also not giving the right environment?
[22:09] <slangasek> (such bugs have occurred before)
[22:09] <infinity> Possibly.
[22:09] <infinity> I find my lack of panels disturbing, at any rate.
[22:09] <infinity> It's creepy having a blank bar up there with no clock.
[22:10] <slangasek> ah, I haven't had that particular failure
[22:10] <slangasek> when it fails for me, I get no window decorations and no bar at all
[22:10] <infinity> That's what I had initially.
[22:10] <infinity> Then ctrl-alt-t and ran a new unity.
[22:11] <infinity> And now no menus or indicators.
[22:11] <infinity> Entirely possible that I failed to run unity in some sort of "I like having stuff" mode.
[22:11] <slangasek> right, I mean even after restarting compiz, I have window management (because I can click on a terminal), but no decorations
[22:11] <infinity> But also short on patience and will likely just reboot soon. :P
[22:12] <infinity> slangasek: Are you running compiz or unity?  I'd expect a raw compiz to land you about there (management, but no pretty).
[22:12] <slangasek> infinity: ah, I was running it as 'compiz', which DTRT when launched from within the X session
[22:13] <infinity> Anyhoo.  Advanced recovery of broken window managers is so 1998.  I think I'll just hope for a bug fix instead.
[22:14] <slangasek> so for my part, I can't see what package changed on my system recently that would correspond to this
[22:17] <infinity> slangasek: glib?
[22:18] <slangasek> seems unlikely
[22:18] <slangasek> given that nothing else is falling over
[22:18] <infinity> I've had nautilus crashing too.
[22:19] <slangasek> according to https://errors.ubuntu.com/problem/10d5e9a86a0f811a645c6fd60ca2dc94bf3c0462, this crash was seen as far back as Apr 27
[22:20] <infinity> slangasek: Hrm.  So could just be "new" to me because I rarely log out and/or reboot.
[22:21] <slangasek> right - it first showed up for me on May 19, my last reboot before that was May 17; so I'm trying to see what I upgraded in between that might be to blame
[22:21] <infinity> I have no idea when it first happened for me. :/
[22:22] <infinity> Does errors have a "look up everything I submitted" thing?
[22:22] <slangasek> I know when it first happened for me, because I filed a bug report immediately ;)
[22:22] <slangasek> infinity: if you know your UUID it might be queriable
[22:22] <slangasek> bdmurray: ^^ ?
[22:24] <psusi> cjwatson, in grub2, deviceiter.c seems to be in an ubuntu patch, restore_mkdevicemap.patch, which has no DEP3 header.. could you help me understand what this patch is for, and why deviceiter.c isn't part of upstream grub2?
[22:25] <slangasek> interesting, the first crash report from April 27 has a GNOME prerelease ppa enabled
[22:26] <cjwatson> psusi: Upstream deliberately removed device.map and all its evil works, but I had to glue it back in for a while to keep things like grub-pc.postinst and (IIRC) grub-installer working.  I'd like to remove it but those scripts need to be refactored in terms of ... something else first.
[22:27] <infinity> I'm liking the "I don't reboot often" argument less, given that last(1) shows I rebooted on May 3, 7, and 17.
[22:27] <infinity> And I always fully update before I reboot.
[22:27] <cjwatson> The version of deviceiter.c we're carrying is basically the last one before upstream removed it.
[22:27] <cjwatson> (And it's a Debian patch, not an Ubuntu one.)
[22:28] <psusi> cjwatson, ohh... I know we prefer not to have device.map anymore, but I didn't realize upstream had removed all support for it... I'm specifically looking at the part of it now that identifies dmraid devices.. it needs a fix.. but if upstream doesn't have this file at all, how would it identify dmraid devices?  I thought that this code was used to dynamically identify devices, with or without a device.map
[22:29] <cjwatson> psusi: There are other interfaces in GRUB that deal with finding devices without the particular form of interface in deviceiter.c
[22:29] <cjwatson> Which is "enumerate all devices we recognise that are provided by the OS"
[22:30] <psusi> so this other mechanism needs enhanced to detect dmraid disks for upstream to do so, and so we can drop that patch eh?  where is this other mechanism?
[22:30] <cjwatson> That isn't needed at boot time, and even most OS-side tools in GRUB only need to be able to come up with a stable way to refer to things
[22:31] <sarnold> infinity,slangasek, I believe this should do it: http://errors.ubuntu.com/user/`printf $(sudo cat /sys/class/dmi/id/product_uuid)|sha512sum`
[22:31] <sarnold> (though it finds nothing for me, which I find hard to believe. :)
[22:31] <cjwatson> Well, there's no other mechanism to enumerate all OS devices recognised by GRUB that I'm aware of
[22:31] <infinity> slangasek: So, the first three I checked all have an updated glib.  Going to keep poking...
[22:31] <cjwatson> We'd have to invent something that's less horrible than device.map was
[22:32] <cjwatson> And maybe refactor on top of things like blkid or other similar facilities, I don't know
[22:32] <cjwatson> It's not something I've given much thought to because that patch hasn't required very much maintenance
[22:32] <infinity> sarnold: Yeah, nothing for me either, so that seems like it's not right. ;)
[22:33] <sarnold> Darn. :)
[22:33] <slangasek> infinity: hmmm; I upgraded libglib on 15 May, so that's not a perfect fit for the timeline here
[22:33] <cjwatson> For the meantime the right answer is just to amend the Debian patch as needed
[22:34] <cjwatson> Happy to take patches to the DM-RAID code there as long as somebody explains why they're correct :-)
[22:36] <infinity> slangasek: But when did you restart compiz?
[22:36] <slangasek> infinity: no later than the 17th when I rebooted
[22:36] <slangasek> which is 2 days before my first bug hit
[22:36] <infinity> slangasek: Kay.  Well, I can't seem to find a single crash that doesn't involve glib 2.37 ... Could be a red herring, but it seems damning.
[22:36] <infinity> slangasek: And the graph takes a steep climb when that got uploaded to the archive.
[22:37] <infinity> slangasek: You could just have been lucky until your first hit?  It's not like it crashes every 20 seconds.
[22:37] <slangasek> infinity: right.  So, downgrade libglib and see?
[22:37] <cjwatson> Ubiquity needed a fix recently for a reference counting bug
[22:37] <cjwatson> Which started crashing in its testsuite, although it was definitely (in my assessment) ubiquity's problem and had basically always been wrong
[22:38] <cjwatson> This is ubiquity 2.15.3
[22:38] <cjwatson> So it's possible glib2.0 had a refleak fix which has exposed bugs in other things too
[22:38] <infinity> This doesn't sound implausible at all.
[22:39] <infinity> Given the name of the symbol with the segv. :P
[22:39] <slangasek> cjwatson: hmm.  The stack trace does look like a 32-bit "pointer" on a 64-bit system, though
[22:39] <cjwatson> Quite
[22:39] <infinity> slangasek: It's crashing on i386 too.
[22:39] <slangasek> ah
[22:39] <cjwatson> slangasek: Could be an artifact of memory having previously been cleaned up, though
[22:40]  * slangasek nods
[22:40] <cjwatson> I don't know, haven't looked at this crash in detail
[22:40] <cjwatson> But IIRC the Ubiquity one looked a bit like that at first glance too
[22:40] <infinity> Do we have a retraced version of this backtrace anywhere?
[22:41] <slangasek> the one on the bug report is retraced
[22:41] <infinity> Ahh, in the bug.
[22:41] <infinity> Yeah.
[22:42] <infinity> Oh, but no symbols for libunityshell.so, that sort of renders that useless.
[22:42] <slangasek> infinity: ?  https://launchpadlibrarian.net/140437248/Stacktrace.txt
[22:43] <infinity> Silly me, I was looking at the thread stack trace...
[22:43] <infinity> Or, no, I was just looking at an earlier one in the log.
[23:05] <psusi> cjwatson, yea... remember how I changed dmraid in 12.04 to use kpartx to activate the partitions since it supported dmraid?  it sets the uuid of the partition to "partN-DMRAID-uuid" and parted-probe is looking for it to start with "DMRAID-" still...
[23:05] <psusi> supported gpt rather
[23:06] <cjwatson> explain> not on IRC at local-midnight :-)
[23:07] <psusi> err, not parted-probe, grub-probe... pfft... how many mistakes can I cram into once line? ;)
[23:07] <cjwatson> Sounds easy enough to fix though
[23:08] <psusi> yea, guess I'll just change it to strstr
[23:08] <psusi> instead of strncmp
[23:08] <cjwatson> In my about-to-sleep state that sounds OK
[23:08] <psusi> just burns me that installs to fakeraids have been broken since 12.04 and I'm just now figuring this out
[23:10] <sarnold> psusi: is that related to this? https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1171945
[23:10] <cjwatson> Glad you looked at that, since I'd probably not have got there
[23:13] <psusi> sarnold, no, this has to do with dmraid/fakeraid, not mdadm
[23:14] <psusi> is there a release manager around that can open the precise task for me on bug #1183915?
[23:15] <cjwatson> psusi: done, and reassigned to grub2
[23:20] <sarnold> psusi: aha, thanks. :)