[01:40] 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] 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 === pete-woods1 is now known as pete-woods [09:24] doko, ^^^ please, fixing the build issue (I uploaded 0.4-1.3 in debian too, will be autosyncd) [09:54] doko, i think we should remove osmium (deprecated) in favor of libosmium (the new one) [10:08] we are still frozen?! =( [10:11] yes, until tonight or tomorrow I guess [10:12] i believe we are waiting for soem -fpic issue to be resolved [10:15] though i would defer to doko for details [10:31] 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] doko: I guess you're fixing https://launchpad.net/ubuntu/+source/gcc-5/5.3.1-15ubuntu6 ? [11:09] ahh, forgot to upload === s8321414_ is now known as s8321414 [12:50] doko, infinity, apw : ^ icu transition bug-fix [12:51] the russian transliteration rules changed from fancy quotes to regularish quotes [12:53] xnox, ahh, but please file a bug report, this is ci-train stuff (or ping sil2100) [12:54] doko, dee development stopped long time ago. [12:54] it's a unity7 thing only. [12:55] ahh === flocculant_ is now known as flocculant [13:50] 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] 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] doko, haha, i bet pointers are compared wrong way around on big-endian. [14:01] or rather they are compared wrong way on little-endian platforms [14:01] osmium built on powerpc and nowhere else. [14:14] 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] do you know if there are any patches in qt to support new libpng? === jgrimm-afk is now known as jgrimm [14:17] 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] maybe there is extra code on amd64 that is not available / not compiled on other arches? [14:19] I have no idea [14:20] ok osmium is baffling me with success on powerpc & armhf, but not other platforms. [14:20] https://launchpad.net/ubuntu/+source/osmium/0.0~20160124-b30afd3-1ubuntu1 [14:22] Maybe it only matters on arches where ocaml has a native compiler [14:22] (utter guesswork) [14:22] I'm not sure I totally believe that looking at the source. Compare build logs I guess [14:24] s390x seems to be able to link objinfo_helper happily. Is -Wl,-Bstatic -lbfd -Wl,-Bdynamic portable with PIE? [14:26] Or, put differently, is it possible for libbfd.a to contain PIC code on amd64? [14:26] Might be enough to just disable PIE for objinfo_helper, if not === Laney is now known as trmsu === willcooke is now known as wllck [15:02] xnox, I demoted osmium to proposed, so not a blocker anymore [15:03] tah [15:03] doko, so qt left and 4 haskell things? [15:05] the 3 haskell things are wip, and I think I fixed the ocaml thing [15:22] doko, and then we open? [15:22] doko, or do we open, whenever infinity wants to? [15:23] xnox, well, I'd like to have working toolchains again ... so ocaml, ghc, hopefully the icu transition in time. [15:23] xnox, sbeattie isn't here, so maybe scan his pie archive for stuff which needs a rebuild [15:24] xnox, or do a qt upload with the tests disabled ... [15:24] doko, we could build qt against old libpng. [15:24] it looks like it is libpng induced failures, which are real, not imaginary. [15:25] xnox, sure, that would help with icu [15:27] xnox, can you do that? [15:27] let me fiddle with that. === trmsu is now known as Laney === nodoubleg is now known as nodoubleg-lunch [17:22] xnox, hmm, we would need to promote libpng12 again if you build qt with it [17:43] so we have images but no testcases? [17:51] doko: It's never been demoted. [17:52] ohh, not yet ... [17:52] Not while the transition is still ongoing, no. [17:53] heh, haskell-text-icu accepted for release with icu 57 still in proposed [17:54] Yay, static linking. :/ [18:04] xnox, hmm, that png12 road is cursed ... can't install the other b-d's anymore [18:20] wxl, lubuntu should be set now [18:20] knome: thank you :) [18:22] np [18:26] infinity: What is happening with that dpkg SRU? [18:28] bdmurray: I'm doing it through the secutity PPA. [18:28] bdmurray: In a few minutes. [18:30] infinity: So I could upload a new ubuntu-release-upgrader shortly which depends on it? [18:31] 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] infinity: what bug is this? [18:31] https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1574285 [18:31] Ubuntu bug 1574285 in libreoffice (Ubuntu Yakkety) "dpkg-maintscript-helper: prepare_dir_to_symlink can never succeed" [High,Confirmed] [18:32] http://anonscm.debian.org/cgit/dpkg/dpkg.git/diff/?id=ca5c108 [19:03] 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] also flashplugin-nonfree is fixed, but you already know that :) [19:04] LocutusOfBorg, -O3 on ppc64el [19:05] so, what is the best fix? change the optimization level or ignore that symbol? [19:06] ignore or mark it as optional. c++ symbols files suck in any case ... [19:07] 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] LocutusOfBorg: The dep list should be reconciled with the output from 'readelf -a /usr/lib/flashplugin-installer/libflashplayer.so | grep NEEDED' [19:09] indeed, I didn't download the package :( [19:17] hmm, did somebody already remove libgccjit-5-dbg, libgcj-doc from proposed? [19:19] ahh, crap. remove-package always wants a -b for binary packages, which is inconsistent with other commands [19:21] infinity, do you want me to upload flashplugin without libpng runtime dependency? [19:25] well, uploaded === nodoubleg-lunch is now known as nodoubleg [19:47] Rejected: [19:47] polybori 0.8.3-5.1 in stretch (same version already has published binaries in the destination archive) [19:47] wgrant, ^^^ [19:48] I can't sync it [19:48] uploading now a 0.8.3-5.1build1 [19:48] LocutusOfBorg: err stop [19:49] ETOOLATE :( [19:49] * cjwatson manages to reject it in time [19:49] let me see what actually happened [19:49] I delete 5.1 from xenial-proposed [19:49] the source seems there https://launchpad.net/ubuntu/+source/polybori/0.8.3-5.1/+build/9540992 [19:49] not sure what happened, I leave the checks to you [19:49] thanks [19:50] LocutusOfBorg: look at https://launchpad.net/ubuntu/+source/polybori/+publishinghistory [19:50] 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] Well, it would need a -5.1build1 regardless. [19:51] If the intent is to transition. [19:51] The one in xenial was pre-transition. [19:51] yep, the rationale is: we removed armhf in debian [19:52] so, please let me transition it :) [19:53] would be nice to copy it back then, at least to fix the libpng stuff [19:54] bdmurray: ^-- There's your dpkg SRU. [19:54] * LocutusOfBorg will fix the FTBFS probably in the next few days [19:55] crap, hhvm still ftbfs https://launchpadlibrarian.net/256053682/buildlog_ubuntu-yakkety-amd64.hhvm_3.12.1+dfsg-1ubuntu1_BUILDING.txt.gz [19:55] 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] LocutusOfBorg, mia and lightspark ftbfs [20:05] LocutusOfBorg, polybori ftbfs [20:51] 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] I'll be afk tomorow for most of the day, so I can't help with issues [20:53] 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] infinity, look at the hhvm fbfs. now demoted to proposed === NCommander is now known as mcasadevall [20:54] doko: Right, and ocamlimages, mldonkey... [20:54] ocaml itself builds again, but maybe this addition of -fPIC was not good enough [20:55] + 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] /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] Looks like it's not creating PICish objects? [20:55] yeah, might be this flag missing from some ocaml infrastructure [20:56] 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] It could also be that this change has cascaded into needing a full ocaml transition. [21:04] 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] libpng12-dev is not installable in yakkety. [21:04] and i don't want to rebuild in xenial with wrong toolchain =/ [21:07] xnox, scratch this. I uploaded the package ignoring the test results [21:08] you can't build using png12 anymore [21:15] Ignoring the testsuite doesn't seem like the right answer. [21:18] agreed, it's a temporary work-around which needs fixing for the release [21:40] infinity/slangasek: I'm planning on making this change to the release upgrader http://pastebin.ubuntu.com/16056888/. Seem reasonable? [21:42] bdmurray: Assuming that actually does what it seems to be saying it should do. [21:42] 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] slangasek: Yeah, to make sure bug 1560797 is fixed. [21:42] bug 1560797 in apt (Ubuntu Wily) "apt does not configure Pre-Depends: before depending package" [High,Fix released] https://launchpad.net/bugs/1560797 [21:42] fun [21:43] that and bug 1574285 for trusty [21:43] bug 1574285 in libreoffice (Ubuntu Yakkety) "dpkg-maintscript-helper: prepare_dir_to_symlink can never succeed" [High,Confirmed] https://launchpad.net/bugs/1574285 [21:43] bdmurray: then it seems ok to me [21:43] 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] (Honestly, the fix is obviously correct regardless, but...) [21:45] 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] bdmurray: I don't intend for it to be slow. [21:46] I guess I assumed tonight was hours away for you like it is for me. [21:47] Well, I said "tonight" because I have plans between 4:30 and 6:30, so "right now" is less realistic. [21:47] But it'll still be soon enough. [21:52] Should I make a separate bug for this or just refer to the existing two? [21:53] bdmurray: Don't care, as long as you test to make sure it DTRT. [21:57] infinity: I view the right thing as not upgrading w/o those packages. [21:58] bdmurray: Does that setting also force an upgrade (or at least ask nicely), or does it stop hard? [21:59] 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] infinity: it stops hard just complaining about an unmet dependency [21:59] 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] bdmurray: I'll delve deeper into this when I return from my early evening shenanigans. [22:01] bdmurray: But go ahead and upload. We'll sort out how to make sure everything's good before we release. [22:04] doko, polybori seems an issue boost related [22:04] xnox, ^^ [22:05] mia boost related [22:05] lightspark needs llvm 3.6 [22:16] most "boost related" bugs are actually just bad c++ =) [22:18] xnox, unfortunately I have not a strong boost knowledge (unless you provide me some "upgrade from 1.58 manual") [22:18] I would prefer to spend my time in libpng related failures [22:18] and then look at what broke elsewhere [22:20] LocutusOfBorg, looks like a case of a missing ';' =) [22:21] the compiler is now more strict. [22:21] you all say qtbase-opensource-src doesn't pass the testsuite with new libpng [22:21] https://buildd.debian.org/status/package.php?p=qtbase-opensource-src&suite=unstable [22:21] why debian is green then? [22:22] xnox, I will look at them as soon as I finish the current stuff :) [22:22] infinity: can you reject the grub2 and grub2-signed uploads? we just noticed that grub2 FTBFS on ppc64el [22:22] thanks for now [22:23] sbeattie is looking into the reason for the FTBFS and then we'll test again and do another upload [22:24] tyhicks: You have a log? [22:24] infinity: https://launchpadlibrarian.net/256038626/buildlog_ubuntu-yakkety-ppc64el.grub2_2.02~beta2-36ubuntu4_BUILDING.txt.gz [22:25] * LocutusOfBorg sleeps [22:25] tyhicks: Not your fault, doko broke the compiler. [22:25] tyhicks: Will upload a fix. [22:25] heh [22:25] sbeattie: ^ [22:31] tyhicks: https://launchpad.net/ubuntu/+source/gcc-5/5.3.1-16ubuntu2 [22:32] 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] infinity: oh, phew. I was worried it was pie related. [22:33] 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] Err, add a -b [22:33] infinity: thanks! [22:33] * infinity runs out. [22:33] infinity: we still have it, but thanks.