[00:13] <infinity> xnox: It doesn't need to be fixed in eglibc at all, stokachu was testing a fix I gave him for the hugetlbfs package.
[00:17] <infinity> slangasek: Yeah, as xnox said, the jenkins pass/fail seemed a reasonable enough test-case, despite the lack of SRU headers in the description to that effect.
[01:26] <slangasek> xnox, infinity: perfect, thanks
=== Ursinha is now known as Ursinha-afk
[03:56] <infinity> slangasek: I kinda want to close #1001904 with extreme prejudice, but I'm curious why you didn't do so, rather than triaging and assigning it.
[04:11] <slangasek> infinity: at this point I don't recall
[04:12] <infinity> Yeah.  I totally missed the assignment happening, just noticed it when wandering through bugs that were assigned to me.
[04:12] <infinity> But, it only happens if you mix-and-match precise and hardy.  And it's a by-product of apt freaking out and trying to install all the Essential packages you're missing.
[04:13] <infinity> Which is a handy and useful feature.
[04:13] <slangasek> infinity: I agree we don't support installation of hardy packages on later releases; and the pastebin is long gone now; grepping logs now
[04:13] <infinity> But not if you're silly enough to include ancient sources.
[04:13] <infinity> At least, I assume that's what's happening, cause I can't fathom anyone doing this to themselves on purpose.
[04:13]  * infinity tosses hardy in a precise chroot for a second to see.
[04:15] <slangasek> infinity: per the meeting logs, the reason people were doing this is because there's a sun-java package still in the hardy release pocket and they're trying to install it
[04:15] <infinity> Ahh.
[04:15] <infinity> Well, we could reintroduce the Replaces, but I really don't think we should carry it "forever" just for this odd use-case.
[04:16] <infinity> Or reintroduce the sysvutils transitional package.
[04:16] <slangasek> so if you have logs handy, there was a long discussion in #ubuntu-meeting on 2012-06-06
[04:16] <infinity> And yeah, just confirmed that adding hardy to sources.list and dist-upgrading pulls in sysvutils
[04:18] <slangasek> infinity: if you think wontfixing it is the thing to do, I don't have any objection; I think the bug assignment was "delegating" :)
[04:19] <infinity> Yeah.  I'm reading the log, and not sure we came to a conclusion, per se.
[04:19] <infinity> The other option is to reintroduce either the replaces or transitional package just for precise, since by the time 14.04 ships, hardy will be EOL, and people still doing this from old-release will be extra insane.
[04:20] <infinity> But the grumpy old man in me is more on the Won't Fix side of that fence.
=== chilicuil is now known as chilicuil_away
=== yofel_ is now known as yofel
=== henrix_ is now known as henrix
=== henrix is now known as henrix_
=== chilicuil_away is now known as chilicuil
=== chilicuil is now known as chilicuil_away
[23:06] <xnox> infinity: ok thanks. Unsubscribed sponsors from the eglibc bug in that case. Thanks for reducing the sponsorship queue \0/
[23:12] <stgraber> Riddell, ScottK: will Kubuntu do an alpha-1 release?
[23:27] <phillw> stgraber: do you know who is responsible for the naming of the daily build iso's via the cron job?
[23:30] <stgraber>  /win 43
[23:31] <stgraber> phillw: what are you referring to?
[23:32] <phillw> stgraber: I've had a bug reported... all the network iso's are called mini.iso
[23:32] <stgraber> and why is that a bug?
[23:32] <phillw> well, try loading two of them, then using zsync?
[23:32] <phillw> i686 / AMD64...
[23:33] <stgraber> just store them on your machine with a different filename?
[23:33] <phillw> http://archive.ubuntu.com/ubuntu/dists/raring/main/installer-amd64/20101020ubuntu195/images/netboot/mini.iso
[23:33] <stgraber> besides, you can't zsync them as they are on archive.ubuntu.com, not on cdimage
[23:33] <phillw> http://archive.ubuntu.com/ubuntu/dists/raring/main/installer-i386/20101020ubuntu195/images/netboot/mini.iso
[23:34] <stgraber> sure, that's the filename that debian-installer has always been using for the netboot images, changing that would break a lot of things for close to no benefit
[23:34] <phillw> So, they are being built daily, but in a totally different naming schedule to the all the isos?
[23:34] <stgraber> they're not built daily
[23:35] <stgraber> they're built as part of a debian-installer package build, so they're built whenever someone uploads a new debian-installer to the archive
[23:35] <phillw> okies, thanks.. i'll be able to reply to the tester for which the names are causing problems
[23:35] <stgraber> and they're built through the package build process, not through the image build process, that's why they're on archive.ubuntu.com as are all binary packages and not on cdimage.ubuntu.com
[23:35] <cjwatson> And it's perfectly possible to supply a different output file name when using zsync.
[23:36] <cjwatson> Or rsync or whatever.
[23:36] <xnox> phillw: zsync -o flag or wget -O flag.
[23:37] <cjwatson> I'm responsible for those file names and I won't change them.
[23:37] <phillw> I see that they only have direct (http) entry for download... sorry.. i didn't look deep enough into the issue reported by the tester.
[23:38] <phillw> cjwatson: is it possible to zsync when there is no zsync link?
[23:38] <xnox> phillw: yes.
[23:38] <cjwatson> If it is, it will provide no meaningful benefit over just using wget.
[23:38] <xnox> phillw: it will redownload the whole file =)
[23:39] <phillw> okies, I'll mark it down as "won't fix" :) Thanks for clearing it up.