[03:49] <pitti> Good morning
[03:50] <pitti> infinity: pkgbinarymangler> yeah, catching up with a recent debhelper change
[03:51] <pitti> TheLordOfTime, SpamapS: the apport retracer does not use -proposed for quantal; we do not expect anyone to run quantal-proposed
[03:52] <lifeless> ev: https://bugs.launchpad.net/daisy/+bug/1052954/comments/2 - my thoughts
[03:52] <pitti> TheLordOfTime: it cannot currently handle multiple different versions within the same distro
[04:12] <pitti> infinity: do you know whether our arm builders changed in any way in the last couple of weeks? running stuff in parallel, or running several builds at once, or anything which would make them have a higher load?
[04:13] <pitti> infinity: I'm still stunned at how many timing tests in glib's test suite suddenly fail (I'm disabling most of them now on arm, it's hopeless)
[04:23] <infinity> pitti: Well, they all got upgraded to precise and, perhaps that's causing issues, but it shouldn't be...
[04:24] <pitti> infinity: ah, so at least there was _some_ change, and it's not totally inexplicable
[04:24]  * pitti now watches the umpteen version build
[04:24] <pitti> yesterday evening's crashed with an internal compiler error, but that seemed to be spurious
[04:25] <pitti> and this morning's managed to fail yet another timing test which hasn't before; I wish they could all fail at the same time instead of serially :)
[04:26] <infinity> pitti: It could be more related to differing aggressiveness of swappiness or something mostly unrelated.  Machines with low RAM and swap over USB are never going to play nicely when you're expecting to have 100% CPU to yourself.
[04:27] <pitti> right, but they weren't that unstable until a few weeks or so ago, and Debian's work rather fine as well; that's what made me wonder what changed
[04:28] <pitti> anyway, once this manages to build two or three times in a row, it should be fine again
[04:28] <pitti> it's enough to test the timing properties on the other arches
[04:35] <infinity> pitti: With any luck, we can back most/all of this mess out when we have "real server hardware".
[04:35] <infinity> pitti: Debian's buildds may be in better shape for two reasons: their armel buildds all have 2.5G of RAM, and their armhf ones, while only have 1G (and being slower in every other respect than the Pandas) are swapping over SATA, so don't waste a ton of CPU time on that.
[04:37] <pitti> ah, thanks; so yes, swapping and random I/O could indeed explain the ridiculously high times that some tests need
[05:30] <YokoZar> Will my upload of opus 1.0.1 turn heads due to its timing?  (opus is a new package in quantal and our current synced version is prerelease.  1.0.1 has been standardized as the reference implementation by RFC)
[05:32] <RAOF> YokoZar: It's unseeded and is bugfix?
[05:32] <YokoZar> RAOF: Yeah pretty much.
[05:33] <YokoZar> I think it's unseeded at least, it would be surprising if it were
[05:33] <RAOF> Should be fine
[05:36] <SpamapS> opus's binaries are not seeded.
[05:37] <SpamapS> YokoZar: I concur with RAOF. sync/upload away
[05:39] <YokoZar> SpamapS: We're jumping ahead of Debian actually.  I'm sending patches though :D
[06:55] <mlankhorst> heya
[06:55] <RAOF> Yo!
[07:05] <dholbach> good morning
[07:15] <doko> Laney, see http://sourceware.org/bugzilla/show_bug.cgi?id=14625
[07:47] <doko> Laney, seb128: see http://sourceware.org/bugzilla/show_bug.cgi?id=14625 looks like the webkit developers need to find another solution for their mega archive, maybe splitting it into smaller ones
[07:53] <Laney> doko: indeed, https://bugs.webkit.org/show_bug.cgi?id=94435
[07:54] <doko> and if it did work before, it was buggy ...
[07:55] <Laney> :-)
[08:00] <doko> Laney, and likely you won't need the make patch either ...
[08:00] <Laney> yes, indeed, same cause
[08:01] <doko> for bonus points, please backport to qt4-x11, so that we can get the thing built on arm too ...
[08:01] <Laney> when there's a working patch
[08:02] <doko> ahh, there's not?
[08:02] <Laney> look at the linked bug, the fix they added broke some other parts of the build so it was reverted
[08:03] <doko> looks like implicit template instantiations ...
[08:05] <doko> Laney, maybe http://gcc.gnu.org/PR54145
[08:19] <toabctl> is it possible to generate input events from the command line? but without the tools from the package xautomation. I need this for an embedded system without X. I tried "echo 60 > /dev/input/event0" but that does not work
[08:38] <doko> jodh, please could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3843612 ?
[08:38] <jodh> doko: looking...
[08:49] <doko> pitti, is ubuntu-drivers-common supposed to ftbfs on arm*?
[08:50] <pitti> doko: no, certainly not
[08:50] <doko> https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3843190
[08:50] <pitti> https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.2.69 looks fine, though
[08:50] <pitti> doko: ah, race condition again
[08:50] <pitti> utterly slow arm builders FTW
[08:50] <jodh> doko: looks like the failing test has hit the issue seen in the follow-on test: occasionally, the test fails to see the trailing '\n' or '\r', but only if the process is forcibly killed. Its either a very obscure Upstart logger bug or an even more obscure pty/tty layer kernel bug. In summary - I suspect re-running that build will pass, but ping me if this is repeatable as it might allow us to hone in on the root cause.
[08:56] <doko> jodh, given back
[09:02] <joeljacobson> when will postgresql 9.1.6 be released in -updates for ubuntu 12.04?
[09:02] <ev> lifeless: thank you!
[09:03] <obounaim> I need sponsoring here, can anybody review my branch?
[09:03] <joeljacobson> when are packages moved from -proposed to -updates, does it occur on certain days?
[09:06] <diwic> joeljacobson, I don't think so - it rather happens when there is positive verification on the relevant bug(s).
[09:10] <joeljacobson> diwic: ok, thanks, so I just have to wait
[09:12] <cjwatson> joeljacobson: is there a particular package you're interested in?
[09:12] <joeljacobson> cjwatson: postgresql 9.1.6
[09:12] <joeljacobson> maintained my Martin Pitt, https://launchpad.net/~pitti
[09:12] <joeljacobson> it's in -proposed now
[09:13] <cjwatson> joeljacobson: http://people.canonical.com/~ubuntu-archive/pending-sru.html shows that as still being much too recent (1 day)
[09:13] <geser> joeljacobson: you can also monitor bug #1055944
[09:13] <cjwatson> joeljacobson: the usual rule is that updates age for 7 days in -proposed to allow time for people to point out regressions
[09:14] <cjwatson> occasionally we waive that, but the circumstances have to be abnormal
[09:14] <diwic> 7 days, didn't know that, thanks
[09:16] <doko> stgraber, https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3822117
[09:16] <joeljacobson> ok, sounds like a reasonable time to wait, noone wanna be the first to upgrade :)
[09:19] <doko> jodh, rebuild did succeed
[09:22] <ev> seb128: it seems like it's a failed retrace, but I can't conclusively narrow it down to one in particular. I'm going to give more attention to https://bugs.launchpad.net/daisy/+bug/1044418 after (or maybe during) we sort out https://bugs.launchpad.net/daisy/+bug/1052954. There's a lot to consider though, so it wont be something that gets done this week. I will, however, keep you posted on the progress.
[09:23] <seb128> ev, ok, thanks
[09:23] <ev> sure thing
[09:23] <seb128> ev, do you know why the launchpad retracers work on that one but not the e.u.c ones?
[09:23] <seb128> ev, they should have access to the same binaries,
[09:24] <ev> yes, but the launchpad retracers deal a bit better with transient failure at the moment. I need to balance failing hard like the launchpad retracers do when they hit a problem in apport-retrace against webops' pagers going off
[09:25] <ev> I do have some improvements here that we had to back out about two weeks ago
[09:25] <ev> I'll revisit them this week
[09:26] <seb128> ok
[09:26] <seb128> ev, I'm just surprised because that bug got successfull retracing on launchpad for a timeframe higher than a week
[09:26] <seb128> so it shouldn't be a "transient" thing
[09:27] <seb128> we are in a somewhat established state
[09:27] <seb128> ev, do we have an estimation of what % of reports fail retracing atm?
[09:27] <ev> seb128: once we have a successful or failed retrace on daisy.ubuntu.com, we don't accept any more core dumps and don't do any more retracing on that particular signature
[09:28] <seb128> oh, ok, I see
[09:28] <seb128> that's unfortunate
[09:28] <ev> seb128: I can run a query for the percentage, sure
[09:28] <ev> seb128: yeah, it prevents us from continually asking for a core dump that will fail to retrace
[09:28] <ev> like when the ddebs needed are out of date
[09:29] <seb128> right, ideally we would have a line on e.u.c about the issue and the associated count at least
[09:29] <seb128> I'm concerned that we might miss quite a lot during unstable cycle
[09:30] <seb128> especially due to the dbgsym server nature
[09:30] <seb128> it updates every few hours
[09:30] <ev> we do
[09:30] <seb128> so the first retrace is likely to fail (and often does) because the dbgsym are not there yet
[09:30] <ev> any problem that's failed to retrace shows up on the main page (if it has a high enough count)
[09:30] <seb128> ok
[09:30] <ev> their identifiers start with "failed:"
[09:30] <seb128> I'm surprised that nautilus bug doesn't show there then
[09:31] <ev> way way way back when the website was first launched, we hid them
[09:31] <seb128> it got over 60 dups on the launchpad side
[09:31] <ev> but I was equally concerned about brushing the problem under the carpet
[09:31] <seb128> which by itself should be enough to make it one the top nautilus list of the month
[09:31] <seb128> one->on
[09:32] <ev> right, which is why I think it might be this:
[09:32] <ev> https://errors.ubuntu.com/bucket/?id=failed%3A%2Fusr%2Fbin%2Fnautilus%3A6%3Ai686%3A%5Bvdso%5D%2B424%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B2e1ef%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B31835%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B27095%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B27147%3A%2Fusr%2Flib%2Fi386-linux-gnu%2FlibX11.so.6.3.0%2B3750f%3A%2Fusr%2Flib%2Fi386-linux-gnu%2FlibX11.so.6.3.0%2B14e72%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2
[09:32] <ev> B6cbc5%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B4e840%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B4e8eb%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B16b19%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-3.so.0.400.2%2B558c0%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-3.so.0.400.2%2B3252d%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgtk-3.so.0.400.2%2B2e4c61%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2Bf1ec
[09:32] <ev> or this:
[09:32] <ev> https://errors.ubuntu.com/bucket/?id=failed%3A%2Fusr%2Fbin%2Fnautilus%3A6%3Ai686%3A%5Bvdso%5D%2B416%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B2e1ef%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B31835%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B27095%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B27147%3A%2Fusr%2Flib%2Fi386-linux-gnu%2FlibX11.so.6.3.0%2B3750f%3A%2Fusr%2Flib%2Fi386-linux-gnu%2FlibX11.so.6.3.0%2B14e72%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2
[09:32] <ev> B6cbc5%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B4e840%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B4e8eb%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B16b19%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-3.so.0.400.2%2B558c0%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-3.so.0.400.2%2B3252d%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgtk-3.so.0.400.2%2B2e4c61%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2Bf1ec
[09:32] <ev> heh, need to come up with shorter URLs
[09:32] <seb128> ;-)
[09:33] <seb128> ev, I doubt it's any of those
[09:33] <ev> oh?
[09:33] <seb128> it should have dbusmenu-gtk4.so in the top of the stacktrace
[09:33] <ev> what should I be looking for?
[09:33] <ev> ah, okay
[09:33] <ev> I'll see if I can dig one up that matches
[09:33] <ev> mpt: when you have a moment
[09:33] <seb128> sorry
[09:33] <seb128>  g_type_check_instance_cast () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
[09:33] <seb128>  ?? () from /usr/lib/x86_64-linux-gnu/libdbusmenu-gtk3.so.4
[09:33] <seb128>  g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
[09:34] <ev> unrelated :)
[09:34] <seb128> ev, ^ that's the top of the libs
[09:34] <ev> seb128: cheers
[09:34] <infinity> pitti: glib on ARM really seems to dislike you. :P
[09:34]  * pitti pulls his hair out
[09:35]  * pitti retries and prepares another upload
[09:37] <infinity> pitti: Check both logs, they failed different tests. :/
[09:37] <pitti> yes, I saw
[09:37] <joeljacobson> cjwatson: postgresql 9.1.6 is a quite serious bug fix, so perhaps the 7 days could be somewhat reduced, due to the urgency of the update?
[09:37] <infinity> pitti: Is it all really just timing stuff?  I didn't read mainloop/recursive_child_sources, but that could be a genuine bug?
[09:38] <pitti> it succeeded all the time since we had test failures FTBFS, and it doesn't happen every time either
[09:39] <infinity> Maybe I should start writing nice letters to everyone who makes ARM kit with 4G of RAM and begin begging.
[09:40] <infinity> Getting so very sick of all of this swap death.
[09:41] <seb128> glib 4 - 0 pitti
[09:41] <seb128> go pitti go ;-)
[09:41] <pitti> 4? it's 7 now!
[09:41] <seb128> crazy...
[09:42] <pitti> maybe until we have proper arm builders we should make the tests non-fatal again on arm, and keep them "on" on debian only
[09:42] <Laney> how come Debian's are better?
[09:42] <ogra_> infinity, we just need a properl beowulf hack to the kernel and can then use a battery of USB hubs to build clusters with these http://store.cstick.com/business/cotton-candy.html ;)
[09:43] <doko> infinity, it was better before ... and the not so nice thing is that the local builds do work
[09:43] <infinity> Laney: Debian's armel builders are ancient Marvell armv5 boards with 2.5G of RAM, and Debian's armhf buildds suffer similar swap pain, but swap to SATA, which might be mildly less CPU load.
[09:43] <doko> Sweetshark, packaged libvigraimpex 1.8.0 in doko/toolchain. please could you test build lo against it?
[09:44] <infinity> doko: Yeah, it's also possible that the precise kernels swap more aggressively or something, I haven't had the time to throw much science at it yet.
[09:44] <doko> do you know how to throw science?
[09:44]  * doko ducks
[09:44] <infinity> doko: Sadly, we need the precise kernels for OTHER reasons, but if they really have regressed from natty in this case, we should be able to sort it out with some fiddling.
[09:46] <cjwatson> joeljacobson: most SRUs are serious for one reason or another, but regressions are even worse
[09:46] <cjwatson> the test is "emergency" rather than "serious", really
[09:46] <cjwatson> pitti: ^- what do you think?
[09:47] <joeljacobson> well, it's not emergency, they advise "REINDEX at a convenient time"
[09:47] <joeljacobson> but feels a bit shaky to run a production database with potential index corruption, I would really like to upgrade yesterday
[09:48] <pitti> cjwatson: I do think that we shouldn't wait the full 7 days for this, but 1 day seems too rushed for me
[09:48] <joeljacobson> no new features in the minor postgres releases, so regressions shouldn't be a problem
[09:48] <infinity> I agree that it's urgent enough to waive the 7d wait, from my examination of it, but I do want to know it's well-tested first.
[09:48] <pitti> while regressions are rare, they did happen
[09:48] <amitk> infinity: fiddling with /proc/sys/vm/swappiness should allow you to confirm if it the swapping
[09:48] <pitti> I have quite a lot of people who use my PPA, and I'm watching the upstream bug list
[09:49] <cjwatson> joeljacobson: we're a little more paranoid than default since at scale you get regressions from all kinds of things; we've had regressions in other packages from no-change rebuilds before
[09:49] <cjwatson> hence the testing process
[09:49] <infinity> amitk: Indeed, and when I find some round tuits, I'll try to do some fiddling.  Sadly, reproducing the issues the buildds see isn't a particularly exact science to start with.
[09:49] <joeljacobson> I would say 3 days is accetpable, but 7 days will cause people like me to start considering compiling from source or adding -proposed to the apt sources
[09:49] <cjwatson> I'm fine to defer to pitti/infinity on waiving it down a bit, but yeah, 1 day is too quick
[09:49] <doko> joeljacobson, that would be one more tester ;)
[09:50] <infinity> joeljacobson: If you want/need it right now, please *do* install it from proposed and followup to the bug to let us know if it's working well (or not!), which helps us decide if it's ready to release to the world at large.
[09:50] <joeljacobson> doko: perhaps someone else who doesn't process millions of physical bank transactions can test first? :)
[09:50] <cjwatson> grr, d-i lowmem mode gives a black screen on amd64.  that's unhelpful
[09:51] <cjwatson> (in kvm)
[09:51] <infinity> joeljacobson: I'm going to assume that if you're in such an environment, you also perhaps have mirrors of production data that you can test with before blindly upgrading production machines? ;)
[09:52] <joeljacobson> infinity: the bug in 9.1.5 caused the hot-standby machines to fail swallowing the WAL-files, so no, I don't, well actually I do now since I've made a new pg_basebackup, and yes, of course I'll upgrade the slave first, that's standard procedure
[09:53] <joeljacobson> infinity: OK, I'll upgrade from -proposed, sounds good. How can I upgrade just postgresql from proposed? Adding it to apt sources will upgrade a lot of other stuff, won't it?
[09:53] <diwic> joeljacobson, out of curiousity, what company are you working for?
[09:54] <joeljacobson> diwic: Trustly Group AB in Sweden, we handle all bank payments for almost all gambling companies in the world
[09:55] <infinity> joeljacobson: You can either enable proposed, apt-get update, and then selectively "apt-get install foo libfoo foo-common libfoo-bin etc" or just grab the appropriate debs from https://launchpad.net/ubuntu/+source/postgresql-9.1/9.1.6-0ubuntu12.04/+build/3852858 and "dpkg -i foo.deb libfoo.deb etc"
[09:55] <diwic> joeljacobson, what are the current odds for your upgrade failing, I wanna bet ;-)
[09:55] <pitti> joeljacobson: I already ran the upstream and the p-common test suites against it, which have a fairly good coverage
[09:57] <joeljacobson> diwic: I'll give you 1000 times the money, but I would prefer to bet myself instead of laying a bet, to hedge against the consequences if something would go wrong
[09:57] <joeljacobson> pitti: ok, thanks, that's good to hear
[09:59] <diwic> joeljacobson, just kidding. Lycka till :-)
[10:01] <joeljacobson> diwic: hahah, are you Swedish?
[10:36] <doko> Sweetshark, see bug #1056759
[11:00] <Andy80> hi
[11:01] <Andy80> I was reading this http://benjaminkerensa.com/2012/09/25/technical-diagram-of-how-unity-shopping-lens-likely-works - do you confirm me that everything I enter in my dash is trasmitted to productsearch.ubuntu.com O_o ?!
[11:02] <cjwatson> #ubuntu-unity more likely to have accurate details
[11:03] <Andy80> cjwatson: ok thanks, I will ask there
[11:19] <cjwatson> barry,doko: heh, I just noticed that python (i.e. 2) is explicitly listed in the minimal seed
[11:19] <cjwatson> do we want that to be python3 now?
[11:20] <doko> sure, however I think we will still install python for a minimal/buildd install?
[11:24] <joeljacobson> apt-get install libpq5 postgresql-9.1 postgresql-client-9.1 postgresql-contrib-9.1 postgresql-plperl-9.1
[11:25] <joeljacobson> .... so far so good ... holding my thumbs :)
[11:26] <Laney> haha, is that the Swedish expression?
[11:26] <Laney> here we'd say "crossing my fingers" :-)
[11:29] <hrw> Laney: it sounds like direct translation of Polish phrase
[11:29] <hrw> (holding my thumbs one)
[11:29] <Laney> funny
[11:33] <cjwatson> doko: Well, we do right now, but should we?  Anything that needs it to build should build-depend on it, surely
[11:34] <cjwatson> Likewise I wonder if we should seed python3-minimal in required, not python-minimal
[11:35] <doko> the only thing I can think of are python scripts, without having a python dependency, which did escape dh_python2, or when dh_python2 wasn't used
[11:35] <doko> but probably uncommon
[11:36] <cjwatson> This would shrink debootstrap output by 9%, so not to be sneezed at
[11:36] <cjwatson> I dunno, if you think it's too risky we could do it first thing in R instead
[11:36] <cjwatson> I just hadn't read germinate output in a while and it stood out immediately
[11:38] <doko> cjwatson, no, I think it's fine. debian needs it as a dep in any case, so for the majority of packages it's no issue
[11:41] <doko> do we have any git experts?
[11:42] <cjwatson> doko: I think I'll do it after b2 then
[11:55] <quadrispro> hi all
[11:55] <mvo> xnox: do you mind if I have a look at #1015567?
[11:56] <xnox> bug 1015567
[11:56] <xnox> mvo: yes please. I had some pokes at it, but not much.
[11:57] <xnox> mvo: with recent/current dpkg I couldn't reproduce the state to trigger the bug, unless I did rm in dpkg/info.
[11:57] <mvo> xnox: it just happened to me on upgrade on of my boxes from precise->quanal and the system is in the broken state
[11:58] <xnox> mvo: nice.
[11:58] <mvo> xnox: and it seems like the only way to get out of this is to manually vi /var/lib/dpkg/status :)
[11:58] <mvo> xnox: so thats a good excuse for me to look at it a bit
[11:58] <Sweetshark> doko: thanks for the bug, will switch to internal for the next upload.
[11:59] <xnox> mvo: the infinity's idea is to make dpkg treat RC packages as multi-arched if needed. E.g. equivalent of adding Multi-arch: same headers to status.
[11:59] <doko> Sweetshark, always for the least effort, not the best solution?
[11:59] <xnox> mvo: except that dpkg's parsing and enumerating status is very interesting for an uninitiated developer like me.
[12:01] <mvo> xnox: yeah, I think that idea of infinity is a good one
[12:01] <mvo> xnox: *cough* s/an uninitiated/any/ ;)
[12:02]  * mvo makes more tea
[12:03] <Sweetshark> doko: gimme a team and I will start caring for vanities.
[12:03] <xnox> mvo: i was not sure you can safely do such substitution, without locking-> read/rewrite/fix status -> re-read the status -> continue. Since the counts of multiarch/non-multiarch packages was order depended in the status file as far as I could read it.
[12:04] <mvo> xnox: right, I need to look at it a bit, I have no real idea just yet
[12:48] <doko> Daviey, zul: is feedparser a server package?
[12:48] <zul> Daviey:  i believe so
[12:48] <zul> python-feedparser?
[12:49] <doko> yes
[12:49] <zul> i believe so
[12:49] <zul> why?
[12:49] <doko> test failures, see the test rebuild
[12:49] <zul> doko: cool ill have a look
[12:49] <doko> same errors in 5.1.2
[12:57] <TJ-> k3b on Quantal, Precise, Oneiric; the k3b i386 package is depending on libc6 >= 2.4 but libc6 is v2.15, so k3b cannot be installed. I've been looking at the build logs to confirm it. Am I missing something obvious here about the libc6 versions?
[12:58] <geser> TJ-: yes, 15 > 4 so 2.15 > 2.4 (the . is a delimiter not a decimal point)
[12:59] <cjwatson> Might be easier to post the full error messages rather than an interpretation of them
[13:00] <cjwatson> And remember that apt often doesn't follow the full chain when something goes wrong and has to be helped to produce the real error
[13:00] <TJ-> geser: Thanks. My brain must not have woken up yet! I totally confused myself over that :s
[13:01] <TJ-> geser: I think I transliterated 2.4 to 2.40
[13:11] <doko> zul: found out that the tests pass with libxml 2.9 from experimental
[13:12] <zul> doko:  thats not good..ill see if i can find a fix
[13:19] <stgraber> doko: hmm, yeah, I guess I'm touched-it-last on that one, though the real fix would be to kill it completely as it shouldn't be needed anymore...
[13:19] <stgraber> seb128, didrocks: is it still the plan to get rid of launchpad-integration completely this cycle? I see that the only rdepends remaining is quickly-ubuntu-template
[13:20] <stgraber> then we should be able to remove it from the archive completely
[13:20] <seb128> stgraber, quickly was fixed yesterday
[13:20] <doko> stgraber, do it!
[13:20] <seb128> there is also a ftbfs fixed version in the unapproved queue
[13:20] <seb128> of launchpad-integration
[13:20] <stgraber> seb128: oh, cool, then I guess we can unseed it and kill it for good then
[13:20] <seb128> it's in universe?
[13:21] <seb128> what do you mean unseed?
[13:21] <doko> zul: just rebuilt the libxml2 version in quantal. same errors, so it should be something in the upstream changes
[13:22] <zul> doko: gotcha
[13:22] <stgraber> seb128: seeded-in-ubuntu was telling me it was still seeded somehow, but it's just because we haven't rebuilt a dvd image in a long time, so all good to remove then
[13:23] <seb128> well, the reason I kept it is appdev
[13:23] <seb128> quickly was promoting it for a while
[13:23] <seb128> so I don't know if we should keep the binaries available for an extra cycle
[13:23] <seb128> e.g I don't know if out of the archive stuff still depends on it
[13:23] <stgraber> hmm, yeah, I guess that'd be reasonable
[13:23] <seb128> there is a version which fix the ftfbs in unapproved as said
[13:24] <seb128> I think it doesn't cost lot to keep it in universe for quantal
[13:24] <stgraber> right, let me accept the fixed version for now so doko is happy and I'll re-target bug 999413 to R
[13:25] <seb128> thanks
[13:25] <doko> stgraber, I'm only happy when http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20120922-quantal.html is empty
[13:26] <seb128> there is a fixed gtk2-engines as well in unapproved
[13:26] <stgraber> doko: you must be a pretty sad man then ;)
[13:26] <seb128> that package is not going to get cleaned a lot until we unfreeze I guess
[13:26] <seb128> I just hope people check unapproved before duplicating work
[13:33]  * doko loves colored non-verbose build logs ... elinks
[13:50] <doko> Riddell, ScottK: I'll leave the kubuntu ftbfs for you ...
[13:51] <ScottK> doko: What happened with https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3837464 - There's no log.
[13:54] <Laney> probably broke the buildd
[13:54] <Laney> that seems to be the failure mode
[13:57] <ScottK> Riddell or debfx: No idea how to troubleshoot that one.
[13:58] <Laney> doko has been complaining about that build for some time
[14:01] <ScottK> Any ideas why sudo do-release-upgrade -d says no new release found even though /etc/update-manager/release-upgrades is set to normal?
[14:01] <doko> ScottK, buildd issue. please don't give back. kills the cats
[14:02] <ScottK> OK.
[14:02] <ScottK> What if I don't like cats?
[14:02] <mvo> ScottK: no, that is unexpected, you can run "DEBUG_UPDATE_MANAGER=1 do-release-upgrade -d" to see if that outputs something useful
[14:03] <ScottK> Sure.
[14:07] <doko> didrocks, seb128: is there an easy work around for #warning "Including <librsvg/rsvg-cairo.h> directly is deprecated." ?
[14:08] <ScottK> mvo: http://paste.ubuntu.com/1228511/
[14:10] <mvo> ScottK: confusing, a 404 - is there anything between you and changelogs.ubuntu.com? like a proxy (transparent) or somesuch that might cause this?
[14:10] <ScottK> No.  Let me try it in a browser
[14:11] <ScottK> mvo: My fault.  I had redirected that url to a different IP address when we were doing testing and forgotten.  Sorry for the bother.
[14:13] <ScottK> Works fine once that's removed.
[14:13]  * ScottK shakes fist at Riddell.
[14:13] <mvo> ScottK: no worries
[14:13] <mvo> ScottK: happy to hear that it works now
[14:20] <Riddell> ScottK: what what?
[14:21] <ScottK> About the fact that I couldn't upgrade because I had changelogs.ubuntu.com redirected to your server for the precise upgrade test we did ...
[14:21] <ScottK> Not really you fault ...
[14:25] <Riddell> ScottK: oh I see :)
[14:25] <Riddell> doko: which kubuntu ftbfs?  in the build tests?
[14:26] <doko> Riddell, yes
[14:26] <Riddell> doko: yeah those are on my radar
[14:26] <doko> thanks
[14:36] <mvo> smoser: meh, I just ran into https://bugs.launchpad.net/ubuntu/+source/offlineimap/+bug/1015692 - this is more than just priority low to me :/
[14:36] <smoser> mvo...
[14:37] <Laney> that's an xnox package :P
[14:38] <smoser> mvo, i dont have a really good solution. as i said in that bug. its really upstream created issue.
[14:38] <xnox> mvo: I was considering to make system-wide ssl certs as defautl.
[14:38] <smoser> but now they're just causing failure when previously they just did not check certificates.
[14:38] <smoser> so in some sense its a feature
[14:38] <xnox> cause than it just works with gmail =)
[14:39] <mvo> xnox: what is stopping us? that sounds like the right thing to do
[14:39] <xnox> and is secure, cause if the system-wise ssl certs in /etc/ are busted.... then there are bigger problems than offlineimap.
[14:40] <xnox> mvo: nothing. Just need to find time to change that default and push it: upstream, debian & ubuntu as I have commit access everywhere.
[14:40] <mvo> xnox: cool
[14:41] <mvo> xnox: when I find a bit of time I will give it a go too, but keep an eye on it to ensure we don't duplicate work
[14:41] <xnox> mvo: ok.
[14:41] <xnox> mvo: I like your dpkg patch by the way. I will run against my fake test cases that I have in pbuilder somewhere to trigger it.
[14:42] <xnox> mvo: and the upload. It just seems like we will have to keep that fix..... forever.....
[14:42] <mvo> xnox: cool, let me know, I got no feedback from #debian-dpkg yet
[14:42] <mvo> xnox: yeah, we could make the count count single, multiple, conf, total, that would be a bit less hacky
[14:42] <xnox> mvo: you wouldn't, because it doesn't effect debian at all.
[14:43] <mvo> xnox: well, sometimes I still get feedbck for ubuntu only stuff because they are nice people
[14:43] <smoser> hm..
[14:43] <xnox> mvo: "broken multiarch was never part of debian" (tm)
[14:43] <smoser> are there not net-device-up events for bridge interfaces?
[14:43] <smoser> i configured a bridge in libvirt
[14:43] <smoser> and i was expecting to be able to
[14:43] <smoser> start on net-device-up INTERFACE=maasbr0
[14:44] <smoser> but i do not have evidence that that ran
[14:45] <smoser> slangasek, ^ ?
[14:45] <cjwatson> xnox: while you might be right, let's not assume failure in advance :)
[14:45] <slangasek> tjaalton: hi, bug #966744 is assigned to you and targeted to beta-2; despite being an old bug number, this has started becoming a huge problem for me just in the past couple of days.  Is this in progress?
[14:46] <cjwatson> and besides, "forever" is at most until the next LTS
[14:46] <cjwatson> *after the ...
[14:46] <xnox> cjwatson: ok. =)
[14:47] <xnox> cjwatson: as far as I understood that patch, it was changing the check to ignore rc state packages. So if there is an rc package that is not upgraded for more than one LTS, then you can still hit it.
[14:47] <slangasek> smoser: there are net-device-up events for those devices on whose behalf /etc/network/if-up.d/upstart is called, which should be all of them managed either in /etc/network/interfaces or by NM
[14:47] <xnox> mvo: or does that actually update status db?
[14:47] <tjaalton> slangasek: yes, I'm testing crack-o-day intel drm code (requested by upstream), also trying to figure out why it fails to boot
[14:47] <smoser> slangasek, ah. yeah. i koind of realized that.
[14:48] <smoser> do you have a suggestion on how i can start on that network device ?
[14:48] <smoser> (which is not managed by /etc/network/interfaces)
[14:48] <tjaalton> slangasek: not going to get fixed for beta2, that's for sure :/
[14:48] <slangasek> tjaalton: ok, thanks for the info
[14:48] <slangasek> smoser: fix libvirt to emit the event for you? :)
[14:49] <slangasek> smoser: or maybe it should be 'start on started libvirt-bin' or something?
[14:49] <smoser> i tried that, but it seemed racy.
[14:49] <slangasek> well, sounds like a bug in libvirt-bin startup
[14:49] <slangasek> because it shouldn't be racy
[14:49] <tjaalton> slangasek: btw, have you reviewed the acpi-support patch(es)?-)
[14:49] <mvo> xnox: no, just "fixes" the counting
[14:50] <slangasek> tjaalton: got about halfway into it before vacation hit... will revisit this week
[14:50] <tjaalton> slangasek: ok, thanks
[14:50] <smoser> slangasek, possibly. but the daemon is sstarted, just not all networks  up i think.
[14:51] <mvo> xnox: this is why it would be nice to "upstream" it
[14:52] <xnox> mvo: well the correct way is to actually rewrite the status db on lts upgrade and correct those. as the new dpkg will not generate inconsistent status db (well if it does it will be upstream bug as well).
[14:52] <xnox> mvo: that way it would really be just a patch to carry until lts.
[14:52] <xnox> mvo: I think we should apply your patch for quantal, and fix it with status db re-writing by 14.04. And then drop it after 14.04.
[14:53] <mvo> xnox: sounds good to me
[14:55] <smoser> slangasek, so you would think that 'started libvirt-bin' would mean that all of its 'auto' networks are up ?
[14:57] <slangasek> smoser: I would think that it would mean all the setup for libvirt is done, so that other services can start using those facilities, yes
[14:58] <slangasek> smoser: libvirt-bin even uses 'expect daemon', so there's no excuse not to - it's just a startup ordering question AFAICS
[14:58] <smoser> do you think the comment about 'net-device-up' is valid ?
[14:58] <smoser> ie, would it be reasonable for libvirt to emit those ?
[15:43] <ScottK> Laney: Did you intend Bug #1054746 to be about excluding online results or excluding commercial results (title says one and the body says the other).  I'd like to make sure we're solving the right bug.
[15:44] <seb128> ScottK, the bug is about stopping sending queries to Canonical servers
[15:44] <Laney> ScottK: I originally intended it to be a narrow fix for just that lens (and wrote a patch for that)
[15:44] <Laney> but then it got extended to cover all queries sent to C servers
[15:45] <ScottK> seb128: That's what I thought, but the U/I that's proposed talks about commercial/non-commercial.
[15:45] <Laney> which I think is nicer.
[15:46] <ScottK> Since there's been discussion of non-commercial online search support, I think that is not completely aligned with not doing online searches.
[15:46] <Laney> it's not about online services
[15:46] <Laney> you'll still have (for example) wikipedia and gwibber working
[15:47] <ScottK> Is that different than what seb128 just said?
[15:47] <ScottK> (or do those not go through Canonical servers?)
[15:47] <didrocks> ScottK: you have the gwibber lens fetching content from tweeter
[15:47] <Laney> It's not, but your response came after his.
[15:48] <didrocks> ScottK: or the excellent radio lens grabbing the available radio info from an online service ;)
[15:48] <ScottK> Right, but those are clearly online.
[15:48] <didrocks> indeed
[15:49] <ScottK> This issue, AIUI was automatically going online for searches when there was no indication that was the case.
[15:49] <Laney> So the bug isn't about disabling all online results. Commercial suggestions from partners was the wording that design came up with to describe what we're turning off.
[15:49] <Laney> which is intended to be the items causing concern
[15:50] <Laney> I understand it's supposed to be finessed more for the next cycle
[15:50] <ScottK> OK.  You might want to retitle the bug then.
[15:50] <ScottK> Because that's what got me started being confused.
[15:51] <Laney> there. how's that?
[15:51]  * ScottK notes for the record how much more convenient conversations like this are when they happen before feature freeze.
[15:51]  * ScottK looks.
[15:51] <ScottK> Sure.  Thanks.
[15:51] <Laney> yes, we know. We're trying to work within the constraints of our governance structure ...
[15:52] <ScottK> Well, something seems to come up every cycle.
[15:54] <ScottK> If someone bases their plans on "we'll get an exception", I don't think that's really working within the structure.  I understand that stuff happens, but when it's consistent, that's not what FFes are for.
[15:55] <ScottK> Strictly from a technical perspective, I think it'd be better to revert the whole thing and land it with a good design early in "R", but I get that's not going to happen.
[15:58] <tumbleweed> ScottK: I assume most of us agree
[16:02] <Laney> ScottK: I'm saying that getting the exception wasn't at issue, given the way the feature was driven.
[16:03] <ScottK> Laney: Yes.  I know.  I'm aware of how it was driven.  It's unfortunate that at this point we can't just focus on producing a quality release.
[16:04] <Laney> I'm hoping that I can turn this experience and other similar but less visible ones into some useful lessons
[16:09] <xnox> ScottK: ubiquity & datetime widgets send lookups to geoname-lookup.ubuntu.com
[16:09] <xnox> are those a concern as well?
[16:10] <ScottK> xnox: Yes.  That's completely beside the point.
[16:10] <xnox> @pilot in
[16:11] <ScottK> I'm not arguing about what should be done, I just found the bug report inconsistent and wanted to make sure we were fixing the right thing.
[16:30] <ev> seb128: I've written the first part of retrying failed retraces and have an outstanding RT for it. It wont fix the counts for days that have already past yet, but it will queue up the problems that it has successfully managed to retrace so we can process those once I've finished that part of the code
[16:31] <seb128> ev, great, thanks
[16:31] <ev> in the immediate term it will allow us to manually trigger daisy to ask for the core files for specific failed-to-retrace problems and bucket them appropriately
[16:31] <ev> sure thing
[16:31] <ev> I'll keep you posted
[16:47] <mitya57> xnox: lp:unity-mail is terribly outdated, so the diff is not what actually changed in this upload.
[16:49] <xnox> mitya57: I noticed, once the diff got generated, checked the package-import, realised it.... now reviewing by hand and deleted the merge proposal ;-)
[16:50] <mitya57> xnox: the actual diff is http://bazaar.launchpad.net/~mitya57/ubuntu/quantal/unity-mail/1.2/revision/11
[16:50] <xnox> mitya57: it's interesting that there are multiple templates successfully translated by launchpad...... I need to set this up for my project.
[17:38] <mitya57> xnox: in case you'll be looking at lp:~mitya57/ubuntu/quantal/libunity/lp1055019 — don't upload it, just merge
[17:38] <mitya57> thanks for unity-mail btw
[17:49] <mlankhorst> ogasawara: ping?
[17:56] <xnox> @pilot out
[17:57] <xnox> sconklin_: piloting for the second day now? =))))
[17:57] <sconklin_> xnox: thanks
[17:57] <sconklin_> @pilot out
[18:31] <ogasawara> mlankhorst: pong, sorry for the delay, was in a meeting
[18:46] <cr3> bryceh: hi there, might you happen to know where I should get piglit for precise? I thought it should be under ppa:ubuntu-x-swat/q-lts-backport but apt-cache search doesn't return anything for "piglit"
[18:50] <cr3> bryceh: tried to apt-file update, but got Ignoring source without Contents File: http://ppa.launchpad.net/ubuntu-x-swat/q-lts-backport/ubuntu/dists/precise/Contents-amd64.gz :(
[18:53] <iamfuzz> anybody here a debian-installer expert?  Trying to figure out how to run a command just after partman does its thing but while partman/early_command exists partman/late_command does not :-(
[19:10] <bryceh> cr3, presently it seems most effective to just check it out from upstream's git tree.  They don't do formal releases, and we are lax at packaging it.
[19:10] <bryceh> cr3, I'm hoping as more of us use piglit, we'll do better at packaging, but at the moment there aren't packages worth pointing you at.
[19:10] <|Anthony|> what is the plan regarding consolekit and udev considering they have been merged into systemd?
[19:10] <cr3> bryceh: is it packaged somewhere though? was I looking in the right place under ubuntu-x-swat?
[19:11] <|Anthony|> i see that they are both included in quantal
[19:11] <cr3> bryceh: would the package depend on anything else?
[19:11] <bryceh> cr3, there should be a ppa around, but it's an old version. lemme check
[19:12] <bryceh> https://launchpad.net/~xorg-edgers/+archive/piglit
[19:12] <bryceh> so, maybe not so old, that looks quite current
[19:13] <cr3> bryceh: awesome, thanks!
[19:13] <bryceh> cr3, also see https://launchpad.net/~sarvatt/+ppa-packages which has current packages; not sure how those two differ
[19:15] <Sarvatt> bryceh: https://launchpad.net/~canonical-hwe-team/+archive/piglit is the one checkbox is using because it needs rendercheck also, but yeah its in https://launchpad.net/~xorg-edgers/+archive/piglit also
[19:15] <Sarvatt> err, cr3: ^^
[19:16] <cr3> Sarvatt: thanks! it's really hard to search all ppas for a desired package :(
[19:19] <doko> pitti : glibc2.0 => 1 : 4
[19:20] <cr3> just learned something new, I can search launchpad ppas: https://launchpad.net/ubuntu/+ppas
[19:58] <|Anthony|> what is the plan regarding consolekit and udev considering they have been merged into systemd?
[19:58] <|Anthony|> i see that they are both included in quantal
[20:10] <slangasek> consolekit has not been merged into systemd
[20:17] <|Anthony|> slangasek, what does it say here: http://www.freedesktop.org/wiki/Software/ConsoleKit
[20:17] <|Anthony|> you're right, it doesn't say merged...
[20:18] <slangasek> outdated propaganda
[20:18] <|Anthony|> lol
[20:20] <|Anthony|> ok, so where is the current documentation. cause i just did a sdiff comparing 0.4.1 (from that site) and 0.4.5 (from /usr/share/doc) and they're the same
[20:20] <|Anthony|> :)
[20:20] <slangasek> current documentation of what?
[20:20] <|Anthony|> of consolekit
[20:23] <bryceh> can someone approve the two nvidia experimental packages in the New queue?  We're trying to get those out as SRUs for a game publisher, and their deadline is looming...
[20:26] <slangasek> |Anthony|: what exactly are you looking for documentation of?
[20:30] <|Anthony|> how to configure .seat files
[20:31] <|Anthony|> and if it is even possible yet as it has been in the works for idk how long
[20:32] <slangasek> |Anthony|: ah, I'm not aware of any progress on that feature
[20:32] <|Anthony|> argh
[20:33] <|Anthony|> sitting here trying to get a sane multiseat setup and pulseaudio can only be active on one seat at a time. something about an acl...
[20:34] <|Anthony|> but that is starting to get above my pay grade
[20:58] <infinity> bryceh: Looking at it right now.
[20:59] <infinity> bryceh: (literally)
[21:01] <bryceh> infinity, \o/ yay thanks
[21:13] <infinity> bryceh: The changelogs reference the wrong bug, so there will have to be some manual tracking. :/
[21:14] <infinity> bryceh: Also, the diff to debian/control between quantal and precise seems curious: http://paste.ubuntu.com/1229290/
[21:16] <infinity> bryceh: Not sure which version is "wrong" here (possibly both), since an nvidia driver claiming to "Provide" fglrx seems a bit fishy but, on the other hand, are those conflicts not required?
[21:20] <bryceh> infinity, looking at git logs, the fglrx additions look deliberate, although alberto didn't indicate why.  Guessing something to do with alternatives; both drivers provide their own glx library which would conflict if they're both installed I guess?
[21:21] <infinity> bryceh: Sure, it makes sense for conflicts, not for provides.
[21:21] <infinity> bryceh: Anyhow, the precise packaging, as you see, has none of that at all.
[21:22] <infinity> bryceh: So, if the Quantal one is verging on "correct", then the precise one really isn't.
[21:25] <infinity> bryceh: And if someone does want to re-upload to resolve that, referencing the correct bug (1047681) in the changelogs would be nice. :)
[21:26] <infinity> bryceh: Other than those two issues, it looks fine, so if you can push me a saner package (or explain why this one appears insane), I'm good to go to let it in.
[21:28] <bryceh> infinity, sure will do.  (I agree the diff looks odd, I'm not sure why that change was made but will track it down.)
[21:29] <infinity> bryceh: Thanks.  You guys can re-use the same version number, since stuff in NEW doesn't "exist" yet.
[21:29] <infinity> bryceh: Fixing the incorrect bug number in both packages would be nice, just so the SRU tracking is less annoying, but mostly, it's the debian/control thing I want either explained or fixed. ;)
[21:30] <bryceh> ok
[21:31] <bryceh> infinity, and then any issues with nvidia-settings-experimental?
[21:31] <infinity> bryceh: nvidia-settings was identical to the quantal upload, so I'm happy to let it in, but it does have the same "incorrect bug in the changelog" issue, so if -driver- is being reuploaded, may as well fix -settings- too.
[21:32] <bryceh> ok
[21:33] <infinity> bryceh: I'll just reject them both for now.  Pester me mercilessly when something new lands, since I have the context now to process this in a matter of seconds/minutes.
[21:38] <bryceh> infinity, I think I've figured out the debian/control file diff.  Looks like he modeled the precise-proposed control file off the one currently in precise rather than the one in quantal.
[21:39] <bryceh> infinity, but I'll get a definitive answer before I re-ping you.  Thanks again.
[21:39] <infinity> bryceh: Ahh, if this is what all the other nvidia drivers in precise look like, that may well be acceptable for now.
[21:40] <infinity> bryceh: (correct bugs in changelogs still would be nice, but any monkey with a text editor and upload rights can fix that) ;)
[21:44] <cjwatson> iamfuzz: Indeed, there's no partman/late_command.  Exactly what are you trying to do?
[21:45] <iamfuzz> cjwatson, trying to modify taskman tasks.  Found the section on hooks which seems to be the trick
[21:46] <cjwatson> iamfuzz: YM tasksel?  Not sure why partman/late_command would be any more useful than partman/early_command for that
[21:47] <iamfuzz> cjwatson, partman/early_command runs before /target has been populated with the base-install, no?
[21:47] <cjwatson> Sure, but so would a hypothetical partman/late_command.
[21:48] <cjwatson> A post-base-installer.d hook written out by a preseed/early_command script is probably indeed the right approach.
[21:48] <iamfuzz> cjwatson, testing just that now
[21:49] <cjwatson> (Or partman/early_command.  It makes little difference which.)
[22:47] <bryceh> infinity, I've added explanations of all the diffs to the Fix section of bug #1047681.
[22:49] <infinity> bryceh: Good enough for me.  Want to reupload both packages with the changelog bug references fixed, and I'll eyeball 'em and push them through?
[22:50] <infinity> bryceh: Or, I suppose I could just fix those two oversights and reupload, since I have the sources sitting here.
[22:50] <bryceh> infinity, yep uploading now
[22:51] <infinity> bryceh: Ahh, fantastic.
[22:53] <bryceh> infinity, both should be in now.  only thing changed should be the bug #
[22:54] <infinity> bryceh: I'm guessing we need nvidia-common and jockey for this to all work, too.  Anything else?
[22:55] <infinity> bryceh: Both of which also have issues.
[22:55] <infinity> bryceh: jockey references the wrong bug too.
[22:55] <infinity> bryceh: And nvidia-common includes a patch that patches debian/* (eek)
[23:06] <bryceh> infinity, the nvidia-common and jockey changes clean up the UI a bit.  The drivers  don't depend on those changes, so it's safe to put them in the unapproved queue independently.
[23:06] <infinity> bryceh: Well, I've already accepted the drivers, yes.  Would be nice to get the above issues sorted with those uploads too, so I can accept them as well, though.
[23:08] <bryceh> infinity, sure thing, will do
[23:55]  * bryceh waves to rickspencer3