[01:40] <infinity> cjwatson: Kay, wasn't sure if this race was known.  Do we ever do a DB sweep to detect such things and fix them?  Seems a bit broken if we have double-accepted binaries and (obviously) only one can be the one on disk.
[06:33] <pitti> infinity: yes, I noticed; on my todo list; for some reason there were tons of timeouts on the autopkgtest.u.c. host when reading swift, maybe some effect of the post-release networking flood
[09:24] <LocutusOfBorg> doko, ^^^ please, fixing the build issue (I uploaded 0.4-1.3 in debian too, will be autosyncd)
[09:54] <xnox> doko, i think we should remove osmium (deprecated) in favor of libosmium (the new one)
[10:08] <xnox> we are still frozen?! =(
[10:11] <LocutusOfBorg> yes, until tonight or tomorrow I guess
[10:12] <apw> i believe we are waiting for soem -fpic issue to be resolved
[10:15] <apw> though i would defer to doko for details
[10:31] <cjwatson> doko: ghc/{amd64,ppc64el} seems to be building more happily now.  Procedure was simple once I thought of it: copy your yakkety source to xenial in a PPA configured to build for amd64 and ppc64el, then use the result to supply build-deps for the yakkety build.
[10:55] <cjwatson> doko: I guess you're fixing https://launchpad.net/ubuntu/+source/gcc-5/5.3.1-15ubuntu6 ?
[11:09] <doko> ahh, forgot to upload
[12:50] <xnox> doko, infinity, apw : ^ icu transition bug-fix
[12:51] <xnox> the russian transliteration rules changed from fancy quotes to regularish quotes
[12:53] <doko> xnox, ahh, but please file a bug report, this is ci-train stuff (or ping sil2100)
[12:54] <xnox> doko, dee development stopped long time ago.
[12:54] <xnox> it's a unity7 thing only.
[12:55] <doko> ahh
[13:50] <xnox> doko, ^ this fixes compile error of the test-suite. There is still operator< test suite failure when comparing shared pointers to node objects.
[13:51] <xnox> i'm not sure how that at all works in c++, or why it is failing. Somehow I suspect operator< shouldn't be declared inline in the templates.... but i really don't know the C++ standards/specs to understand where the bug is.
[14:01] <xnox> doko, haha, i bet pointers are compared wrong way around on big-endian.
[14:01] <xnox> or rather they are compared wrong way on little-endian platforms
[14:01] <xnox> osmium built on powerpc and nowhere else.
[14:14] <xnox> Mirv, in yakkety qtbase-opensource-src fails to rebuild with new libpng due to test-suite errors e.g. https://launchpadlibrarian.net/256001809/buildlog_ubuntu-yakkety-amd64.qtbase-opensource-src_5.5.1+dfsg-16ubuntu8_BUILDING.txt.gz
[14:14] <xnox> do you know if there are any patches in qt to support new libpng?
[14:17] <doko> xnox, cjwatson: how did you bootstrap ocaml for pie? https://launchpad.net/ubuntu/+source/ocaml/4.02.3-6ubuntu1  seems to be ok on ppc64el, but fails on amd64
[14:19] <xnox> maybe there is extra code on amd64 that is not available / not compiled on other arches?
[14:19] <cjwatson> I have no idea
[14:20] <xnox> ok osmium is baffling me with success on powerpc & armhf, but not other platforms.
[14:20] <xnox> https://launchpad.net/ubuntu/+source/osmium/0.0~20160124-b30afd3-1ubuntu1
[14:22] <cjwatson> Maybe it only matters on arches where ocaml has a native compiler
[14:22] <cjwatson> (utter guesswork)
[14:22] <cjwatson> I'm not sure I totally believe that looking at the source.  Compare build logs I guess
[14:24] <cjwatson> s390x seems to be able to link objinfo_helper happily.  Is -Wl,-Bstatic -lbfd -Wl,-Bdynamic portable with PIE?
[14:26] <cjwatson> Or, put differently, is it possible for libbfd.a to contain PIC code on amd64?
[14:26] <cjwatson> Might be enough to just disable PIE for objinfo_helper, if not
[15:02] <doko> xnox, I demoted osmium to proposed, so not a blocker anymore
[15:03] <xnox> tah
[15:03] <xnox> doko, so qt left and 4 haskell things?
[15:05] <doko> the 3 haskell things are wip, and I think I fixed the ocaml thing
[15:22] <xnox> doko, and then we open?
[15:22] <xnox> doko, or do we open, whenever infinity wants to?
[15:23] <doko> xnox, well, I'd like to have working toolchains again ... so ocaml, ghc, hopefully the icu transition in time.
[15:23] <doko> xnox, sbeattie isn't here, so maybe scan his pie archive for stuff which needs a rebuild
[15:24] <doko> xnox, or do a qt upload with the tests disabled ...
[15:24] <xnox> doko, we could build qt against old libpng.
[15:24] <xnox> it looks like it is libpng induced failures, which are real, not imaginary.
[15:25] <doko> xnox, sure, that would help with icu
[15:27] <doko> xnox, can you do that?
[15:27] <xnox> let me fiddle with that.
[17:22] <doko> xnox, hmm, we would need to promote libpng12 again if you build qt with it
[17:43] <wxl> so we have images but no testcases?
[17:51] <infinity> doko: It's never been demoted.
[17:52] <doko> ohh, not yet ...
[17:52] <infinity> Not while the transition is still ongoing, no.
[17:53] <doko> heh, haskell-text-icu accepted for release with icu 57 still in proposed
[17:54] <infinity> Yay, static linking. :/
[18:04] <doko> xnox, hmm, that png12 road is cursed ... can't install the other b-d's anymore
[18:20] <knome> wxl, lubuntu should be set now
[18:20] <wxl> knome: thank you :)
[18:22] <knome> np
[18:26] <bdmurray> infinity: What is happening with that dpkg SRU?
[18:28] <infinity> bdmurray: I'm doing it through the secutity PPA.
[18:28] <infinity> bdmurray: In a few minutes.
[18:30] <bdmurray> infinity: So I could upload a new ubuntu-release-upgrader shortly which depends on it?
[18:31] <infinity> bdmurray: Yeah.  We'll need to verify the SRU, despite the fix being "obvious", but that shouldn't be too hard to expedite.
[18:31] <bdmurray> infinity: what bug is this?
[18:31] <infinity> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1574285
[18:32] <infinity> http://anonscm.debian.org/cgit/dpkg/dpkg.git/diff/?id=ca5c108
[19:03] <LocutusOfBorg> doko, I uploaded a "fixed" crossguid, I don't know why debian has a symbol for ppc64el that disappeared on Ubuntu, I did a "arch=!ppc64el" it should work, and unblock kodi
[19:03] <LocutusOfBorg> also flashplugin-nonfree is fixed, but you already know that :)
[19:04] <doko> LocutusOfBorg, -O3 on ppc64el
[19:05] <LocutusOfBorg> so, what is the best fix? change the optimization level or ignore that symbol?
[19:06] <doko> ignore or mark it as optional. c++ symbols files suck in any case ...
[19:07] <infinity> LocutusOfBorg: The better fix for flashplugin is to not list libpng at all, it's not a direct dep.  (if it was a direct dep, your fix would be broken).
[19:07] <infinity> LocutusOfBorg: The dep list should be reconciled with the output from 'readelf -a /usr/lib/flashplugin-installer/libflashplayer.so | grep NEEDED'
[19:09] <LocutusOfBorg> indeed, I didn't download the package :(
[19:17] <doko> hmm, did somebody already remove libgccjit-5-dbg, libgcj-doc from proposed?
[19:19] <doko> ahh, crap. remove-package always wants a -b for binary packages, which is inconsistent with other commands
[19:21] <LocutusOfBorg> infinity, do you want me to upload flashplugin without libpng runtime dependency?
[19:25] <LocutusOfBorg> well, uploaded
[19:47] <LocutusOfBorg> Rejected:
[19:47] <LocutusOfBorg> polybori 0.8.3-5.1 in stretch (same version already has published binaries in the destination archive)
[19:47] <LocutusOfBorg> wgrant, ^^^
[19:48] <LocutusOfBorg> I can't sync it
[19:48] <LocutusOfBorg> uploading now a 0.8.3-5.1build1
[19:48] <cjwatson> LocutusOfBorg: err stop
[19:49] <LocutusOfBorg> ETOOLATE :(
[19:49]  * cjwatson manages to reject it in time
[19:49] <cjwatson> let me see what actually happened
[19:49] <infinity> I delete 5.1 from xenial-proposed
[19:49] <LocutusOfBorg> the source seems there https://launchpad.net/ubuntu/+source/polybori/0.8.3-5.1/+build/9540992
[19:49] <LocutusOfBorg> not sure what happened, I leave the checks to you
[19:49] <LocutusOfBorg> thanks
[19:50] <cjwatson> LocutusOfBorg: look at https://launchpad.net/ubuntu/+source/polybori/+publishinghistory
[19:50] <cjwatson> LocutusOfBorg: I can copy it back in from there, but is there any reason to believe that the FTBFS on armhf has been fixed?
[19:51] <infinity> Well, it would need a -5.1build1 regardless.
[19:51] <infinity> If the intent is to transition.
[19:51] <infinity> The one in xenial was pre-transition.
[19:51] <LocutusOfBorg> yep, the rationale is: we removed armhf in debian
[19:52] <LocutusOfBorg> so, please let me transition it :)
[19:53] <LocutusOfBorg> would be nice to copy it back then, at least to fix the libpng stuff
[19:54] <infinity> bdmurray: ^-- There's your dpkg SRU.
[19:54]  * LocutusOfBorg will fix the FTBFS probably in the next few days
[19:55] <doko> crap, hhvm still ftbfs https://launchpadlibrarian.net/256053682/buildlog_ubuntu-yakkety-amd64.hhvm_3.12.1+dfsg-1ubuntu1_BUILDING.txt.gz
[19:55] <cjwatson> all right; I just wanted to make sure that it was actually investigated rather than doing a knee-jerk upload as a workaround.
[19:56] <doko> LocutusOfBorg, mia and lightspark ftbfs
[20:05] <doko> LocutusOfBorg, polybori ftbfs
[20:51] <doko> slangasek, infinity, pitti, xnox, sbeattie: about archive opening ... ghc is fixed, I'm not sure about ocaml on amd64. I still would like to see icu migrate before we open the archive. from my point of view ocaml is a blocker, icu is a point of discussion.
[20:51] <doko> I'll be afk tomorow for most of the day, so I can't help with issues
[20:53] <infinity> doko: Finishing the icu transition so it doesn't get tied up with autosync transitions might be nice.  What's the ocaml/amd64 issue?
[20:53]  * infinity spots the ocaml rdep build failures.
[20:53] <doko> infinity, look at the hhvm fbfs. now demoted to proposed
[20:54] <infinity> doko: Right, and ocamlimages, mldonkey...
[20:54] <doko> ocaml itself builds again, but maybe this addition of -fPIC was not good enough
[20:55] <infinity> + ocamlfind ocamlopt -package lablgtk2,graphics,unix -w A-4-9-40-42-44-45-37-41-48 -I . -I ../../src -linkall -o monochrome.opt ../../src/camlimages_core.cmxa ../../src/camlimages_all_formats.cmxa monochrome.cmx -linkpkg
[20:55] <infinity> /usr/bin/ld: /usr/lib/ocaml/libasmrun.a(startup.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
[20:55] <infinity> Looks like it's not creating PICish objects?
[20:55] <doko> yeah, might be this flag missing from some ocaml infrastructure
[20:56] <infinity> I'm going to grab lunch and then I'll download ocaml and see if I can make sense of the C parts while ignoring the ocaml parts. ;)
[20:58] <infinity> It could also be that this change has cascaded into needing a full ocaml transition.
[21:04] <xnox> infinity, i currently believe qtbase-opensource-src test-suite failures are due to switch to libpng16-dev, tried rebuilding with libpng12-dev to get the icu abi bump, without libpng abi bump -> no dice
[21:04] <xnox> libpng12-dev is not installable in yakkety.
[21:04] <xnox> and i don't want to rebuild in xenial with wrong toolchain =/
[21:07] <doko> xnox, scratch this. I uploaded the package ignoring the test results
[21:08] <doko> you can't build using png12 anymore
[21:15] <infinity> Ignoring the testsuite doesn't seem like the right answer.
[21:18] <doko> agreed, it's a temporary work-around which needs fixing for the release
[21:40] <bdmurray> infinity/slangasek: I'm planning on making this change to the release upgrader http://pastebin.ubuntu.com/16056888/. Seem reasonable?
[21:42] <infinity> bdmurray: Assuming that actually does what it seems to be saying it should do.
[21:42] <slangasek> bdmurray: what's the context for this change?  This means that an SRU will need to be installed on either trusty or wily before upgrading, is that correct?
[21:42] <bdmurray> slangasek: Yeah, to make sure bug 1560797 is fixed.
[21:42] <slangasek> fun
[21:43] <bdmurray> that and bug 1574285 for trusty
[21:43] <slangasek> bdmurray: then it seems ok to me
[21:43] <infinity> So, we need to test and expedite that dpkg SRU, but I can figure out a small testcase tonight and push it out.
[21:44] <infinity> (Honestly, the fix is obviously correct regardless, but...)
[21:45] <bdmurray> I'll work on getting this uploaded, if the dpkg change is slow it'll just stop upgrades from T to X for a bit.
[21:45] <infinity> bdmurray: I don't intend for it to be slow.
[21:46] <bdmurray> I guess I assumed tonight was hours away for you like it is for me.
[21:47] <infinity> Well, I said "tonight" because I have plans between 4:30 and 6:30, so "right now" is less realistic.
[21:47] <infinity> But it'll still be soon enough.
[21:52] <bdmurray> Should I make a separate bug for this or just refer to the existing two?
[21:53] <infinity> bdmurray: Don't care, as long as you test to make sure it DTRT.
[21:57] <bdmurray> infinity: I view the right thing as not upgrading w/o those packages.
[21:58] <infinity> bdmurray: Does that setting also force an upgrade (or at least ask nicely), or does it stop hard?
[21:59] <infinity> bdmurray: We have a small issue that that apt isn't in trusty-security (and shouldn't be copied there because it wasn't built against only security, like my dpkg just was)
[21:59] <bdmurray> infinity: it stops hard just complaining about an unmet dependency
[21:59] <infinity> bdmurray: So, we might need a no-change apt SRU via security (or to examine the deps and make sure it's clean to copy) to resolve that.
[22:00] <infinity> bdmurray: I'll delve deeper into this when I return from my early evening shenanigans.
[22:01] <infinity> bdmurray: But go ahead and upload.  We'll sort out how to make sure everything's good before we release.
[22:04] <LocutusOfBorg> doko, polybori seems an issue boost related
[22:04] <LocutusOfBorg> xnox, ^^
[22:05] <LocutusOfBorg> mia boost related
[22:05] <LocutusOfBorg> lightspark needs llvm 3.6
[22:16] <xnox> most "boost related" bugs are actually just bad c++ =)
[22:18] <LocutusOfBorg> xnox, unfortunately I have not a strong boost knowledge (unless you provide me some "upgrade from 1.58 manual")
[22:18] <LocutusOfBorg> I would prefer to spend my time in libpng related failures
[22:18] <LocutusOfBorg> and then look at what broke elsewhere
[22:20] <xnox> LocutusOfBorg, looks like a case of a missing ';' =)
[22:21] <xnox> the compiler is now more strict.
[22:21] <LocutusOfBorg> you all say qtbase-opensource-src doesn't pass the testsuite with new libpng
[22:21] <LocutusOfBorg> https://buildd.debian.org/status/package.php?p=qtbase-opensource-src&suite=unstable
[22:21] <LocutusOfBorg> why debian is green then?
[22:22] <LocutusOfBorg> xnox, I will look at them as soon as I finish the current stuff :)
[22:22] <tyhicks> infinity: can you reject the grub2 and grub2-signed uploads? we just noticed that grub2 FTBFS on ppc64el
[22:22] <LocutusOfBorg> thanks for now
[22:23] <tyhicks> sbeattie is looking into the reason for the FTBFS and then we'll test again and do another upload
[22:24] <infinity> tyhicks: You have a log?
[22:24] <tyhicks> infinity: https://launchpadlibrarian.net/256038626/buildlog_ubuntu-yakkety-ppc64el.grub2_2.02~beta2-36ubuntu4_BUILDING.txt.gz
[22:25]  * LocutusOfBorg sleeps
[22:25] <infinity> tyhicks: Not your fault, doko broke the compiler.
[22:25] <infinity> tyhicks: Will upload a fix.
[22:25] <tyhicks> heh
[22:25] <tyhicks> sbeattie: ^
[22:31] <infinity> tyhicks: https://launchpad.net/ubuntu/+source/gcc-5/5.3.1-16ubuntu2
[22:32] <infinity> tyhicks: If you still have that source in the PPA you copied from, you can retry the build once that compiler's published.
[22:32] <sbeattie> infinity: oh, phew. I was worried it was pie related.
[22:33] <infinity> tyhicks: (If you don't, you can revive it with copy-package --force-same-destination --from=ppa:foo/bar --to=ppa:foo/bar --from-suite=yakkety --to-suite=yakkety -e $version grub2)
[22:33] <infinity> Err, add a -b
[22:33] <tyhicks> infinity: thanks!
[22:33]  * infinity runs out.
[22:33] <sbeattie> infinity: we still have it, but thanks.