[00:13] <lamont> so then.  y'all now have 8^W7 buildds for armel.
[00:35] <bdrung> am i allowed to upload a package with this fix: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578002 ?
[00:35] <ubottu> Debian bug 578002 in dpkg-dev "dpkg-dev: Please add Bug-Ubuntu entry to DEP-3 template" [Wishlist,Open]
[00:35] <bdrung> it's not RC critical, but the change is very small
[00:35] <slangasek> bdrung: upload dpkg, or upload a package that sets Bug-Ubuntu?
[00:36] <bdrung> slangasek: upload dpkg
[00:36] <slangasek> bdrung: I'm disinclined to accept that, the buildds have quite a bit to keep them busy already and it's not RC critical
[00:37] <bdrung> k
[00:37] <bdrung> slangasek: then i ask again once the buildds idle ;)
[00:38] <slangasek> bdrung: well, I don't think my answer will change closer to the release date
[00:40] <bdrung> slangasek: then i have to find a severe dpkg bug ;)
[00:40]  * slangasek hehs
[00:49] <slangasek> ubuntuone-client in the queue has string changes - bug #539676, which I don't think was ever actually given an exception; so please don't accept it without a resolution there
[00:49] <ubottu> Launchpad bug 539676 in ubuntuone-client "[Freeze Exception] Add instructional text to Ubuntu One Preferences application" [Medium,In progress] https://launchpad.net/bugs/539676
[07:42] <pitti> slangasek: please let me know if you have further questions about the udev upload, as the diff is a bit scary (there was some code moved around, etc.)
[07:59] <slangasek> pitti: ack - I've put off that review so far because it needs a bit of concentration to review properly, but I'll get to it "today"
[07:59] <pitti> slangasek: I realize that it's quite a major change, but it's the first version where everyone said "it works"
[07:59] <pitti> this thing has been driving me mad
[07:59] <pitti> until about a week ago nobody complained
[08:00] <pitti> and then we did a harmless upload, and things broke all over the place
[08:00] <slangasek> until a week ago, nobody was testing CDs? :)
[08:00] <pitti> turned out that there were two bugs leading to detecting too much due to uninit'ed memory and detecting too little due to ignored errors which just magically cancelled each other out most of the time
[08:00] <slangasek> heh
[08:00] <pitti> we did get some reports, but they were spurious and not really reproducible
[08:01] <pitti> slangasek: the other day, Marjo mentioned broken audio CDs
[08:01] <pitti> but yeah, CDs aren't that popular any more these days :)
[08:45] <apw> slangasek, hi
[08:48] <slangasek> apw: hiya
[08:51] <slangasek> apw: so AIUI we have no test information for the 515f PCI ID, right?  Wouldn't the conservative move be to only change behavior for the PCI ID we've tested?
[08:52] <apw> slangasek, on the second id, i had been given both as relevant by jjohansen so i included them, and my own lookup showed both applied to the same family of cards.  the ids are in a table so the risk of including both once one was tested code wise
[08:53] <apw> as the failure was deemed so awful it seemed 'better' to inclue both, but i do concur your position is the more safe
[08:53] <apw> i can make it so if you prefer the more minimal change
[08:56] <slangasek> do you give it better than 50% odds that the other PCI ID with the same name is also broken without this change?
[08:58] <apw> slangasek, actually i suspect its a coin toss, at 50%  i cannot tell from the original bug which id they have as it is not included, we know the one fixes all the ones we have ... so perhaps prudence says not
[09:01] <slangasek> well, a coin toss is 50% - so if those are the odds that this will /help/ them, the odds that it will significantly regress instead are much lower; in which case, since we're guessing either way, I think the conservative assumption is to treat the two PCI IDs the same
[09:02] <apw> that is essentially the position i was taking, if they don't need it they probabally won't notice
[09:02] <apw> if they do need it, they will notice a lot
[09:02] <apw> (won't notice that they got UMS instead)
[09:03] <slangasek> right; the risk of regression is that this other chip actually works fine with KMS, but turning off KMS breaks X
[09:04] <slangasek> accepted
[09:04] <apw> sorry for the confusion
[09:04] <slangasek> no confusion, just wanted to make sure we all know what we're in for with this chnage
[09:39] <ttx> slangasek: fwiw the ES1000 is a server-oriented chipset, which kinda mitigates the risk.
[09:39] <ttx> http://www.dvhardware.net/article4312.html
[09:40] <slangasek> ah, alright
[09:40] <ttx> though I suppose "thin clients" could be affected
[09:56] <apw> slangasek, i see that ia64 won't start till the 18th
[09:58]  * ScottK thinks doko__'s toolchain build perhaps ought to die an untimely death.
[09:59] <doko__> ScottK: already asked yesterday to kill the hooker build
[09:59] <ScottK> lamont: ^^^
[10:01] <slangasek> ah, ia64 is tied up with a PPA build?
[10:27] <seb128> somebody might want to do the sync on bug #563113
[10:27] <ubottu> Launchpad bug 563113 in epiphany-extensions-more "epiphany-extensions uninstallable in lucid (epiphany 2.30 conflicts with epiphany-extensions 2.29)" [Undecided,Invalid] https://launchpad.net/bugs/563113
[10:29] <pitti> ah yeah, it can hardly get any worse, syncing
[10:29] <seb128> danke
[10:29] <pitti> seb128: hm, the dependencies of e-extensions seem open enough to be installable
[10:30] <seb128> epiphany-browser breaks << 2.30
[10:30] <seb128> pitti, not sure what you mean there
[10:31] <pitti> Depends: epiphany-browser (>= 2.29.5), epiphany-browser (<< 2.31)
[10:31] <seb128> pitti, the abi version needs to match and it doesn't now, and the breaks used in epiphany doesn't allow to install e-e
[10:31] <pitti> ah, I see
[10:31] <seb128> pitti, well apt-cache show epiphany-browser | grep Breaks
[10:33] <pitti> (done)
[10:35] <seb128> pitti, danke
[11:32] <directhex> src:indicator-application is bugged, which breaks banshee-community-extensions compilation (and generally has bad dependency information going on). I've attached a bunch of fixes to a debdiff on bug #564506 - it looks like tedg isn't online right now, so i can't go through him... and it's in main.
[11:32] <ubottu> Launchpad bug 564506 in indicator-application "libappindicator-cil-dev's .pc file points to the wrong place" [Critical,In progress] https://launchpad.net/bugs/564506
[11:33] <directhex> which steps should i take next to ensure the package is all shiny and happy in time for lucid?
[11:33] <directhex> (i.e. should i be uploading random packages to main a fortnight before release?)
[11:59] <ScottK> slangasek: I'd appreciate it if you'd review rootstock and sssd (absolutely no rush).
[12:14] <lamont> doko__: asked where? (hooker build)
[12:15] <doko__> lamont: #soyuz
[12:16] <lamont> didn't see the request. :-(
[12:17] <mvo> slangasek: hi, so … here is a possilbe workaround for the mountall bug, details in #559582 on why it is needed, http://people.canonical.com/~mvo/tmp/initramfs-tools_0.92bubuntu74.debdiff what do you think
[12:20] <slangasek> mvo: if that works reliably, yeah, go for it
[12:20] <slangasek> (wow, libpng - of all things)
[12:21] <cjwatson> that dependency needs to be architecture-specific, or it'll break ia64
[12:21] <cjwatson> mvo: ^-
[12:22] <cjwatson>    libc0.1 |   2.10.2-6 |      unstable | kfreebsd-amd64, kfreebsd-i386
[12:22] <cjwatson>    libc0.3 |   2.10.2-5 |      unstable | hurd-i386
[12:22] <cjwatson>      libc6 |   2.10.2-6 |      unstable | amd64, armel, hppa, i386, mips, mipsel, powerpc, s390, sparc
[12:22] <cjwatson>    libc6.1 |   2.10.2-6 |      unstable | alpha, ia64
[12:23] <ogra> wow, what a naming mess
[12:23] <mvo> cjwatson: woah, thanks
[12:23] <mvo> I wonder if I can abuse shlibs.local for this somehow
[12:23] <slangasek> you could
[12:24] <slangasek> but I think the hard-coded dep is better
[12:24] <slangasek> because it avoids initramfs-tools-bin ending up later with a *too weak* dep
[12:27]  * mvo nods
[12:28] <lamont> on those occasions where it's been done, I've always seen the whole pile of the above, or been the one filing the bug telling them to fix it
[12:47] <mvo> slangasek, cjwatson: could you please review http://people.canonical.com/~mvo/tmp/initramfs-tools_0.92bubuntu7.debdiff2 ?
[12:47] <cjwatson> these days I think you can actually get away with using [arch] syntax in Depends fields, provided the package is architecture: any - dpkg-gencontrol expands it
[12:48] <mvo> oh, cool
[12:48] <cjwatson> also I don't think DEB_ARCH is defined
[12:48] <mvo> let me try that
[12:48] <cjwatson> oh, maybe cdbs defines it
[12:48] <mvo> cjwatson: cdbs should do that, no?
[12:48] <cjwatson> yeah, apparently so
[12:50] <mvo> but let me try the [arch] in deiban/control, that is certainly more elegant
[12:50] <cjwatson> as long as you don't accidentally use it in an architecture: all package; but then substvars wouldn't work in that context either
[12:57] <mvo> cjwatson: ok, final one (I hope): http://people.canonical.com/~mvo/tmp/initramfs-tools_0.92bubuntu74.debdiff3
[12:58] <james_w> oops, could someone reject upse please?
[12:58] <james_w> oh, I can do it can't I
[12:58] <james_w> was supposed to be ubuntu1
[12:58] <cjwatson> mvo: LGTM
[12:59] <cjwatson> oh, why the lower version on ia64?
[13:02] <mvo> cjwatson: thanks, hrm, i looked at the wrong rmadison output
[13:28] <mvo> cjwatson, slangasek: uploaded the workaround for the server upgrade issue, I tested it in kvm and before FAIL, after WORKS
[13:28] <mvo> so should be good
[13:33] <slangasek> ogra: KERNEL_IMG_REL=${KERNEL_IMG_REL/_*_armel.deb} - buggy; this is a /bin/sh script, not a bash script
[13:37] <slangasek> ogra: rejecting rootstock as a result - please fix this to work under dash, and test before reuploading
[13:38] <slangasek> (or drop that feature, if you prefer; I saw you discussed it with ScottK earlier)
[13:38] <slangasek> erm
[13:39] <slangasek> well, I was going to reject rootstock, but it looks like someone's accepted it then
[13:39] <slangasek> ogra: ^^ but please fix and reupload anyway :)
[13:58] <ogra> slangasek, hrm
[13:59] <ogra> slangasek, are you ok with the rest ? i can fix that bit
[13:59] <ogra> slangasek, oh, you let it through
[14:00] <slangasek> no, someone else let it through, but it still has a bug
[14:00]  * ogra was expecting a reject
[15:43] <lamont> slangasek: care to help me understand how the glib2.0 upload of 4 hours ago got a sparc build record?
[16:00] <pitti> ah, sweet; a lot of the old tetex-* dependencies are actually alternate ones
[16:00]  * pitti verifies tetex-base and removes it as NBS
[16:00] <james_w> pitti: yeah
[16:00] <james_w> I think I squished all the troublesome ones
[16:00]  * pitti checks the others
[16:01] <james_w> checkrdepends could really do with telling you this
[16:02] <cjwatson> I tried to fix it once but I got lost down the rabbit hole
[16:03] <james_w> the only troublesome NBS are audacious and sugar from what I can see
[16:03] <james_w> audacious has two packages that FTBFS against the new version
[16:03] <james_w> and sugar is half-way upgraded to the new upstream
[16:10] <doko__> slangasek, ubuntu-release: please reject the eglibc upload; one more patch coming
[16:10] <pitti> doko__, slangasek: ^ done
[16:14] <pitti> slangasek, ScottK: ok, confirmed that tetex-{bin,base,extra} NBS are all okay to remove, and removed \o/
[16:18] <james_w> thanks pitti
[16:18] <kirkland> slangasek: ping, re: https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/513273
[16:18] <ubottu> Launchpad bug 513273 in vgabios "kvm with -vga std is broken since karmic" [High,In progress]
[16:18] <kirkland> slangasek: we have a user who as regression tested vgabios against bochs
[16:18] <kirkland> slangasek: which is the remaining thing you asked for
[16:19] <kirkland> slangasek: i'm going to go ahead and upload vgabios again, and it can await your approval (again)
[16:19] <kirkland> slangasek: feel free to reject it, if there's more you want tested
[16:41] <cjwatson> ubiquity and hdparm both fix RC bugs
[17:01]  * pitti looks at hdparm
[17:01] <pitti> cjwatson: oh, thanks for fixing that
[17:01] <cjwatson> there's a little bit of controversy in the second bug; I confess I don't entirely understand Jerone's objection
[17:01] <cjwatson> so you might like to assess it somewhat independently
[17:02] <cjwatson> I mean obviously I think I'm right O:-)
[17:02] <pitti> ah, I only followed the first bug so far
[17:03] <pitti> cjwatson: with the workaround/fix in hdparm, the linux task certainly should't be lucid/critical any more, right?
[17:03] <cjwatson> I guess not
[17:03] <cjwatson> you'd still be able to break it by running hdparm by hand
[17:04] <pitti> right, that's why it looks more like a workaround
[17:04] <pitti> but it should stop the linux task from stopping the release
[17:05] <pitti> (especially since it's probably nontrivial to fix, and it might even be a problem in the firmware of those particular devices..)
[17:07] <lamont> ogra: still around?
[17:08] <ogra> lamont, yup
[17:09] <lamont> ogra: I'm figuring I'll kill off huito and jambul (the last of the pegatrons) - did you want a mass giveback after that to catch the rest of haskell pain?  or?
[17:09] <lamont> ogra: also, libgphoto2 is dying in doxygen on armel - infinite loop inside the app
[17:09] <ogra> might make sense
[17:10]  * ogra blames pitti ... he uploaded :P
[17:10] <pitti> hm?
[17:10] <pitti> oh, libgphoto2?
[17:10] <ogra> yeah
[17:10] <ogra> massive pain in aour rams butts
[17:10] <ogra> *arms
[17:11] <lamont> pitti: if you fixed it to not build all the arch-indep stuff on an arm...
[17:12] <pitti> sounds possible
[17:14] <cjwatson> pitti: oh, it's certainly an unashamed workaround
[17:14] <pitti> cjwatson: it looks like you just remove the -B option, while Jeroen's change disables hdparm altogether (hdparm-functions has other bits); but I believe -B is the only thing we actually ship by default
[17:14] <cjwatson> that was my assessment from reading the code
[17:14] <cjwatson> double-checking wouldn't hurt
[17:15] <pitti> cjwatson: it seems to be that the bug doesn't happen on that particular operation, but on the initial IDENTIFY DEVICE
[17:15] <pitti> (incidentally that's very similar to the recent udisks-probe-ata-smart bug)
[17:16] <pitti> cjwatson: so from what I can see, if an user would customize /etc/hdparm.conf to set other options than -B, they would again be done for firefire drives, too, and again break them?
[17:16] <cjwatson> I think so
[17:16] <pitti> (conversely, with Jeroen's variant you couldn't ever run custom hdparm commands on any firewire drive)
[17:16] <cjwatson> though hdparm.conf can be disk-specific
[17:16] <pitti> sounds like being between a rock and a hard place :(
[17:16] <pitti> ah, it can?
[17:16] <pitti> ok, then I prefer your fix indeed :)
[17:17] <pitti> ah, right, these come in /dev/foo { } blocks
[17:17] <cjwatson> such is my understanding
[17:17] <cjwatson> a release note mightn't hurt
[17:21] <lamont> ogra/pitti: if you wanna convince jocote's dchroot to not scream about mutex assertions, the chroot is current and has libgphoto build-deps.  Likewise, it's just a lucid chroot on a lucid system, to make things easier if you have either bbg3 or pegatron you control
[17:21]  * lamont afk for a bit
[17:22] <doko__> slangasek, ScottK: http://people.canonical.com/~doko/tmp/codecs.open.log
[17:23] <ScottK> doko__: That's a longer list than I'd hoped.
[17:42] <slangasek> lamont: glib2.0 build record> well, I have yet to figure out why we *don't* get build records for valgrind/armel and ltsp/armel, so I don't think I have much insight here
[17:47] <slangasek> kirkland: vgabios> if it's regression-tested with all the revdeps, that's all I asked for; will gladly accept it this time around
[17:50] <slangasek> doko__: codecs.open - thanks for gathering that data
[18:13] <kirkland> slangasek: i'm happy with it
[19:00] <doko__> slangasek: eglibc uploaded, will be away for the evening, reading backlog later
[20:00] <lamont> slangasek: really...  interesting (glib2.0)
[20:00] <lamont> https://bugs.edge.launchpad.net/soyuz/+bug/564759 <-- slangasek
[20:00] <ubottu> Launchpad bug 564759 in soyuz "PaS says not to build glib2.0 on sparc, but it's built anyway" [Low,Triaged]
=== highvolt1ge is now known as highvoltage