[00:54] <skaet> edited ~/cdimage/www/full/netboot/precise/index.html to point to precise's community instructions instead of oneiric's.
[00:54] <skaet> Hasn't picked up yet though, so wondering if there's a step I'm missing
[00:56] <slangasek> sync-mirror?
[02:45] <ScottK> skaet: I think Barry's proposed release note in Bug #954595  should be added.
[02:45] <ubot2> Launchpad bug 954595 in python2.7 "ImportError: cannot import name urandom from os" [Undecided,Invalid] https://launchpad.net/bugs/954595
[07:27] <skaet> ScottK,  read through it and agree.   Have gone in and added.  When you're adding a release-note project in future, could you be explicit by targetting it to series the release note applies to.   I've done it for this one now already, since I had to go in and update.   If they're release targetted, it becomes easier to find, and update for the release, as well as tracking those that may end up spanning multiple releases.
[07:27] <skaet> Thanks for flagging it.  :)
[07:33] <skaet> slangasek,  yup, that sorted it.  :)
[07:34] <skaet> Thanks!  :)
[08:07] <slangasek> skaet: ok, good
[08:07] <slangasek> cjwatson: debhelper merge uploaded
[16:07] <knome> somebody else who could answer questions about QA tracker/QA iki
[16:07] <knome> *else than stgraber :D
[17:18] <slangasek> infinity: hmm, I just hit that libc 'unexpected copy' nonsense on an amd64 sid chroot
[18:05] <infinity> slangasek: Yeah, I found some older reports of same here and there.  It's not new, but I'm not sure how to reproduce it.
[18:05] <infinity> slangasek: If your chroot is still in the broken state, could you tar it up for me?
[18:53] <slangasek> infinity: turns out my sid chroot was broken because I'd previously had a locally-installed multiarch dpkg, then "upgraded" to a new Debian version, and dpkg didn't know where libc6's files were
[18:53] <slangasek> infinity: once I manually fussed with /var/lib/dpkg/info, the upgrade worked.  It seems unlikely that this is the cause of elmo's powerpc issue
[18:54] <infinity> slangasek: Hrm.  Well, it's not a fequently-reported thing, so it could be dpkg sadness in other cases too.  I can't readily see how it would work for almost everyone, but not quite.
[18:57] <infinity> (I suppose one could argue that calling dpkg-query from maintainer scripts is bound to be fragile, and probably not sane in the first place)
[19:03] <elmo> infinity: I don't understand this - the package contains the directory it's complaining about
[19:03] <elmo> infinity:  unless I'm just blind/misreading the check
[19:04] <infinity> elmo: But does dpkg claim that libc6 owns the binary in question?
[19:06] <elmo> root@royal:/# dpkg -S /usr/lib/powerpc-linux-gnu/
[19:06] <elmo> libgdbm3, libgmp10, libmpc2, libc6-dev, libgomp1, libpciaccess0, libpcre3, libssl1.0.0, libtinfo5, libc6, fakeroot, libstdc++6, libmpfr4, libglib2.0-0, util-linux, libdb5.1, libdrm-intel1, libdrm-nouveau1a, libdrm-radeon1, libdrm2, libffi6, libelf1, liblzma5, libncurses5, libncursesw5: /usr/lib/powerpc-linux-gnu
[19:06] <elmo> infinity: ^--
[19:08] <infinity> Wait, didn't you file a bug about this?  Why can't I find it now?
[19:08] <infinity> But it should have been /lib/powerpc-linux-gnu/libc6.mumble, surely?
[19:08] <elmo> infinity: yeah, sorry
[19:08] <elmo> but
[19:09] <elmo> infinity: http://paste.ubuntu.com/955807/
[19:09] <elmo> dpkg -S doesn't claim it, I don't know if that's because the package is in a half-installed state or not
[19:09] <infinity> It shouldn't be hi, if it never got past the preinst.
[19:10] <infinity> If it is, then it was previously for some other broken reason...
[19:10] <elmo> yeah, you're right it's ii
[19:10] <elmo> oh
[19:10] <elmo> I see
[19:11] <elmo> infinity: http://paste.ubuntu.com/955812/
[19:11] <infinity> *blink*
[19:11] <infinity> But ou have 2.15 installed?
[19:11] <elmo> infinity: 2.15 is what I'm *trying* to install
[19:12] <elmo> and whose preinst is freaking out
[19:12] <infinity> Oh, err.  From 2.13 to 2.15.  That should work fine.  I'd still like a copy of that filesystem, if it's not way too much hassle.
[19:12] <elmo> infinity: ok, I'll do it later, I'm too latency-ified right now
[19:13] <infinity> Fair enough, I'm in a jetlag-induced haze of stupid right now.
[19:45] <cjwatson> slangasek: isn't this vaguely reminiscent of some of the problems Guillem was alluding to with the in-core dpkg db layout?
[19:45] <cjwatson> particularly disappearance of info files on upgrade from M-A none to M-A same
[19:46] <cjwatson> hm, that was M-A none config-files though, which seems a bit unlikely for libc6
[19:46] <cjwatson> maybe incorrect disappearance?
[19:55] <slangasek> cjwatson: yes certainly - but it was self-inflicted in this case, by installing an Ubuntu version of dpkg on Debian and then upgrading, which is not supported :)
[19:55] <slangasek> and by "upgrading" I mean "upgrading to a Debian version that still didn't support multiarch"
[19:57] <slangasek> so it went: install Ubuntu dpkg, causing the database format to be marked as using the multiarch layout; upgrade to Debian dpkg, which doesn't know about the database format at all; upgrade libc6 with the Debian dpkg, creating /var/lib/dpkg/info/libc6.list and friends; upgrade Debian dpkg to multiarch-aware version, with no database upgrade because the flag was already set; libc6 files missing
[22:41] <cjwatson> ^- mostly to clear NBS
[22:46] <tumbleweed> re the hdf5 sync earlier, that's to get the transition rolling with the first autosyncs. It'd be nice if that was published before autosyncs started
[22:47] <tumbleweed> I assume the archive will be open a day or so before we start autosyncing?
[22:50] <cjwatson> accepted hdf5
[22:50] <cjwatson> not sure yet, still waiting for results from my test-build of main with tweaked dpkg
[22:51] <tumbleweed> thanks, yeah I assumed we were still waiting on that
[22:54] <cjwatson> it's built 1897 source packages so far
[22:54] <cjwatson> maybe I should have filtered out kernels, compilers, and language packs; oh well
[22:56] <tumbleweed> you building everything in main?
[22:56] <cjwatson> yes
[22:57] <cjwatson> I ought to figure out some reasonable way to test all components; this was just a quick thing I could throw together in a few minutes at the tail-end of Friday
[22:57] <cjwatson> filtering down to only things that actually build shared libraries would have been a slightly cleverer start
[22:57] <tumbleweed> heh
[22:58] <cjwatson> but that involved more effort than grep-dctrl
[22:58] <tumbleweed> main is enough to give us an idea of the scale of breakage
[22:58] <cjwatson> unfortunately I didn't do a test-build with new debhelper + new cdbs, which would probably have helped, but meh
[23:00] <cjwatson> only one failure in my list so far, which was sbuild pre-emptively abandoning hope of having enough disk to build libreoffice
[23:01] <cjwatson> so I think that's presumptive evidence that this at least won't cause mass build failures
[23:03] <tumbleweed> sensible sbuild :)
[23:03] <tumbleweed> I assume you are also looking for lack of hardening?
[23:04] <cjwatson> I suppose I should just to check, but I believe we established that all the hardening flags that were dropped are already compiler default
[23:04] <cjwatson> s
[23:05] <tumbleweed> oh, I thought there was a gap
[23:05] <tumbleweed> great
[23:05] <cjwatson> we thought --param=ssp-buffer-size=4 was missing, but kees later found that that was present after all
[23:06] <cjwatson> but I can compare hardening-check output easily enough
[23:08] <cjwatson> of course, if I'm remembering the original purpose of -Bsymbolic-functions correctly, gaps in coverage of relatively little-used libraries won't make a big difference; most of the win was in core desktop stuff that's loaded frequently
[23:16] <infinity> cjwatson: I'm still hoping to finish off fpc and llvm/clang tonight, though neither is particularly critical to opening the archive.
[23:16] <infinity> (Just less effort for me if I do get it all sorted beforehand)
[23:19] <cjwatson> OK
[23:21] <cjwatson> Rough initial estimate: 733/6032 binary packages show differences in 'objdump -R' output with proposed dpkg change
[23:22] <cjwatson> I'll see what it looks like in the morning, I guess
[23:22] <cjwatson> Some of the changes are trivial/irrelevant
[23:23] <cjwatson> Like extra libc symbols showing up as dynamic relocs for whatever reason I can't be bothered to untangle
[23:23] <cjwatson> Maybe I should look only for removals
[23:36] <cjwatson> diffing hardening-check output is puzzling
[23:36] <cjwatson> some progressions, presumably due to stuff not built for a while being built with newer helpers
[23:37] <cjwatson> advancecomp shows regressions in stack-protector, fortify, relro despite apparently making use of dpkg-buildflags
[23:38] <cjwatson> oh, no, most of that is a cdbs bug that left out CPPFLAGS, fixed in quantal; but relro is puzzling since we thought that was the default
[23:39] <cjwatson> apg regresses relro despite it having been last built long before the dpkg-buildpackage hack
[23:39] <cjwatson> I wonder if the compiler has dropped relro-by-default or something?
[23:40] <cjwatson> actually the cdbs bug in question making any difference is a bit odd too, given the purported compiler defaults
[23:40] <cjwatson> bdfresize regresses fortify too
[23:41] <cjwatson> last built on amd64 in intrepid
[23:41] <cjwatson> and no sign of FORTIFY_SOURCE in that log
[23:47] <kees> cjwatson: _lost_ relro? that is alarming
[23:48] <kees> cjwatson: and you're building with the ubuntu compiler?
[23:48] <kees> cjwatson: the only thing that could mess with fortify is lacking -O1 or higher (otherwise it's ignored)
[23:48] <cjwatson> oh, hah, my check was backwards
[23:49] <cjwatson> so now I need to wonder what those progressions are instead :(
[23:50] <cjwatson> acct indeed seems to be lacking -Oanything and so regresses fortify
[23:50] <cjwatson> ditto amarok
[23:51] <cjwatson> acct appears to regress -fstack-protector too
[23:54] <cjwatson> kees: so sorry for false alarm, but still some things to check
[23:56] <cjwatson> kees: does -fstack-protector also require the optimiser in some cases, by any chance?
[23:56] <cjwatson> kees: this build is in a precise chroot with the only change being the removal of the env export hack from dpkg-buildpackage