[03:55] sergiusens: That's interesting, I've done SRUs without a problem on the development release... [03:58] tjaalton: I guess you might be the person to ping about this, but there's been a bug that more and more Lubuntu users are reporting in 17.10, just want to make sure it's on someone's radar: bug 1724639 [03:58] bug 1724639 in linux (Ubuntu) "Bug in Kernel 4.13 : Intel Mobile Graphics 945 shows 80 % black screen" [Medium,Confirmed] https://launchpad.net/bugs/1724639 [04:18] tsimonq2: looks like khfeng is on it [04:32] tjaalton: Thanks. [05:56] -queuebot:#ubuntu-release- New binary: pysha3 [ppc64el] (bionic-proposed/universe) [1.0.2-2] (no packageset) [05:57] -queuebot:#ubuntu-release- New binary: pysha3 [amd64] (bionic-proposed/universe) [1.0.2-2] (no packageset) [05:57] -queuebot:#ubuntu-release- New binary: pysha3 [s390x] (bionic-proposed/universe) [1.0.2-2] (no packageset) [05:57] -queuebot:#ubuntu-release- New binary: pysha3 [i386] (bionic-proposed/universe) [1.0.2-2] (no packageset) [05:57] why is https://launchpad.net/ubuntu/+source/auctex in main? [05:58] -queuebot:#ubuntu-release- New binary: pysha3 [armhf] (bionic-proposed/universe) [1.0.2-2] (no packageset) [05:59] if I find that an autosync of something that I don't maintain broke something majorly with another package which I *do* maintain, is there a way to force a package to its prior revision because of the major regression? [05:59] -queuebot:#ubuntu-release- New binary: pysha3 [arm64] (bionic-proposed/universe) [1.0.2-2] (no packageset) [05:59] i ask this because a Universe-destined nginx-extras will FTBFS because LocutusOfBorg or someone broke libluajit [05:59] and therefore block nginx-core from landing in Main (as well as the other flavors) [06:01] teward: If it's already in bionic-release, I don't think so, although you could always upload an Ubuntu revision reverting the changes (provided that bugs are filed in Debian). [06:01] (while the "file bugs in Debian" thing is optional, it's the Right Thing To Do.) [06:01] tsimonq2: that's the odd thing, I can't find a recent upload of nginx that's affected by this upload. I'll have to spin a sid schroot and do testing. [06:01] but i am *certain* this is broken now in Ubuntu [06:02] because I just ran a local rebuild of 1.12.x nginx that's in bionic in sbuild [06:02] and it too exploded in my face [06:02] so... [06:04] I'm not pleased. [06:06] teward: Do you know if that regression is caused by LocutusOfBorg's upload specifically or the new upstream release? [06:07] tsimonq2: well, since he NMU'd this in Debian, he's the last person on the list so he's on my blame list now [06:07] rbasak: ^ FYI [06:07] teward: His NMU looks fairly innocent, to be honest. [06:07] tsimonq2: then upstream's update breaks it [06:08] but it's odd it breaks it *only* in those individual release [06:08] s [06:08] gah i can't type [06:10] What's the source package name? [06:10] luajit [06:10] for libluajit anyways. [06:10] yyou know the source package name for nginx :P [06:11] *goes to rebuild his debian Sid schroot* [06:11] * tsimonq2 -> sleep [06:12] rbasak: what's so odd is that it only breaks on 3 archs [06:12] Does nginx in Debian FTBFS in Debian now? [06:12] Or is that what you're testing now? [06:12] rbasak: that's what i'm testing [06:12] the last nginx update was a while ago, 1.13.6 was Oct. 10 [06:13] so that was before autosyncs were on here, and before the last upload in Debian it seems [06:13] that said, i have to rebuild the schroot because it explodified so blah. [06:13] once that's done i'll run a test of what's in Debian unstable through a local build [06:13] if it explodes, the same bug I already filed in Ubuntu gets sent to Debian as well [06:13] if it doesn't, then we have to determine what in Ubuntu actually broke it [06:14] and 1.12.1 that was in Artful is *way* before autosyncs and that was just copied over [06:15] *runs build test* [06:17] uhm... that's interesting [06:17] rbasak: it works without issue in Sid [06:18] so *something* in the package explodes here in Ubuntu [06:18] but not in Debian [06:18] (that said lintian piuparts exploded in the sbuild schroot but that's a different issue entirely) [06:19] rbasak: is it possible there's some kind of LD or toolchain things going on behind the scenes that could be affecting detection of libraries? [06:19] i know it sounds far-fetched, but... [06:21] I'm not sure. It'd take some investigation. [06:21] Or perhaps someone here is already aware of the relevant delta? [06:22] rbasak: what makes it even more odd is that it's *only* on amd64, i386, and armhf that it fails [06:23] and seems to work without issue on ppc64el and arm64 [06:28] teward: That's not surprising, given that arm64 and ppc64el don't build-depend on luajit. [06:29] teward: (Though they should, now that it's been enabled there) [06:29] ah, you're right, I forgot about that. [06:29] teward: Just rebuilding the current bionic nginx should be enough to show the issue? [06:29] * infinity does that while he goes for food. [06:31] infinity: i'll have to tweak the control file [06:31] Oh, that failed fast. Didn't get to leave the room. [06:31] infinity: so it blew up for you as well? [06:31] with luajit? [06:32] ./configure: error: ngx_http_lua_module requires the Lua library. [06:32] That? [06:32] infinity: and the inability to find LuaJIT in the few lines above it yes [06:32] That's probably going to be a trivial fix. [06:32] look up a few lines in the error and you'll see it doesn't find LuaJIT [06:32] even though it's looking [06:32] Seems not worth all the hand-wringing. [06:32] infinity: fix where [06:32] luajit or nginx? [06:33] My bet's nginx, but looking. [06:33] infinity: i should note I tested in Debian sid normally, and it works without issue [06:33] so it's *something* about how things're here in Ubuntu causing problems [06:34] but if the package luajit was autosynced from Debian it shouldn't be doing anything different during installation [06:34] *raise eyebrow* [06:34] infinity: let me get the sbuild logs here for sid [06:34] you'll see it doesn't blow up [06:34] I can test here, that's fine. [06:34] Maybe this one will take long enough for me to leave the house for food. [06:35] heh [06:35] teward: Anyhow, regardless of where the fault lies, "configure can't find ThingX" bugs are pretty easy to hunt down. [06:36] See what configure is trying to do, see why that used to work and why it no longer works, fix whichever side is broken. [06:36] probably the long-day-of-hell catching up to me then >.< [06:36] (My knee-jerk was to blame nginx because people often do version pattern matching, which fails on new versions of a dep) [06:36] But if it builds in sid, we'll see. Something else broke a thing. [06:36] uh, hm. [06:36] It does not, however, build in sid. [06:36] that's... interesting [06:36] So, you tested wrong? [06:36] infinity: i misspoke - as i said evilness. [06:37] Exactly the same failure in sid. [06:37] i forgot to mention 1.13 works fine [06:37] well [06:37] kinda [06:37] 1.13.6 from Unstable works fine [06:37] So, either nginx is looking for something versiony and doesn't love the new luajit version, or the new luajit isn't exporting a header/file/function/whatever that nginx is looking for. [06:37] 1.13.6 straight in fails [06:37] But simple enough to dig. [06:37] After I eat. [06:37] infinity: have fun. [06:37] I'm going to go let my head hit a pillow because i probably need rest [07:13] -queuebot:#ubuntu-release- New: accepted libbarcode-datamatrix-png-perl [amd64] (bionic-proposed) [0.04-1] [07:13] -queuebot:#ubuntu-release- New: accepted pysha3 [amd64] (bionic-proposed) [1.0.2-2] [07:13] -queuebot:#ubuntu-release- New: accepted pysha3 [armhf] (bionic-proposed) [1.0.2-2] [07:13] -queuebot:#ubuntu-release- New: accepted pysha3 [ppc64el] (bionic-proposed) [1.0.2-2] [07:13] -queuebot:#ubuntu-release- New: accepted revolt [amd64] (bionic-proposed) [0.0+git20170627.3f5112b-1] [07:13] -queuebot:#ubuntu-release- New: accepted xerces-c [arm64] (bionic-proposed) [3.2.0+debian-2] [07:13] -queuebot:#ubuntu-release- New: accepted xerces-c [i386] (bionic-proposed) [3.2.0+debian-2] [07:13] -queuebot:#ubuntu-release- New: accepted xerces-c [s390x] (bionic-proposed) [3.2.0+debian-2] [07:13] -queuebot:#ubuntu-release- New: accepted pysha3 [arm64] (bionic-proposed) [1.0.2-2] [07:13] -queuebot:#ubuntu-release- New: accepted pysha3 [s390x] (bionic-proposed) [1.0.2-2] [07:13] -queuebot:#ubuntu-release- New: accepted xerces-c [armhf] (bionic-proposed) [3.2.0+debian-2] [07:13] -queuebot:#ubuntu-release- New: accepted pysha3 [i386] (bionic-proposed) [1.0.2-2] [07:13] -queuebot:#ubuntu-release- New: accepted xerces-c [ppc64el] (bionic-proposed) [3.2.0+debian-2] [07:13] -queuebot:#ubuntu-release- New: accepted xerces-c [amd64] (bionic-proposed) [3.2.0+debian-2] [07:24] Laney: based on the RT discussion I've gone ahead and landed the changes to stand up s390x as a separate worker pool; but I notice that even though our quota for cores would currently accommodate both, our quota for instances would cut into the arm64 capacity right now, so I have it disabled until that's worked through [08:17] * LocutusOfBorg looks at luajit, and remembers his pull request https://github.com/Ettercap/ettercap/pull/825 [08:17] sergiusens: There's always a simple way out of the problem with different suites (and especially running LTS, but building newer stuff): Setup sbuild, and just rebuild the source in sbuild in the target distro. For example, sbuild --no-arch-any --source --dist=bionic path/to/source.dsc. Though, a useful thing might be to just backport testsuite-triggers to xenial, this way it would work for xenial SRUs actually built in xenial. The [08:17] patch is tiny. [08:22] That should be the entire debdiff: http://paste.ubuntu.com/25973017/ [08:22] This is the original commit: https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=90324cfa942ba23d5d44b28b1087fbd510340502 [08:36] -queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (artful-proposed/main) [1:5.4.1-0ubuntu1 => 1:5.4.2-0ubuntu0.17.10.1] (ubuntu-desktop) [08:38] -queuebot:#ubuntu-release- Unapproved: libreoffice (artful-proposed/main) [1:5.4.1-0ubuntu1 => 1:5.4.2-0ubuntu0.17.10.1] (kubuntu, ubuntu-desktop) [08:39] teward, I don't know the reasons for the Ubuntu delta, but Debian has a patch for the new luajit location debian/modules/patches/http-lua/discover-luajit-2.1.patch [08:41] I had to tweak the patch (not sure if it was bad, but since we strip non-needed libs, that patch can be wrong in Ubuntu) [08:41] -+ ngx_feature_libs="-L/usr/lib -lm -lluajit-5.1 -ldl" [08:41] ++ ngx_feature_libs="-L/usr/lib -lluajit-5.1 -lm -ldl" [08:41] but once you swap libraries in that file, everything seems to build correctly https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/8492525/+listing-archive-extra [08:49] the patch seems to apply cleanly to the ubuntu nginx package, but the nginx-lua module is not updated to the latest release Version: v0.10.10 VS Version: v0.10.7 (according to the two README.Modules-versions debian files) [08:56] teward, please steal this, copy to your ppa https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+sourcepub/8492554/+listing-archive-extra and let me forget this stuff, my eyes are now bleeding :( [08:56] infinity, if you want to runtime test it ^^ [09:10] LocutusOfBorg: what's with these all-proposed entries in the queue? [09:11] LocutusOfBorg, teward: thank you for investigating and taking care of this :) [09:54] sil2100, good morning! libreoffice 1:5.4.2-0ubuntu0.17.10.1 is in the artful queue (updated version number per your request) [09:59] Laney, new perl-foo migrated, triggering new autopkgtests for perl, making it not candidate again [09:59] they should be empty now [10:00] * LocutusOfBorg should really remember to remove that --all-proposed from the run, ctrl+r is bad sometimes [10:01] LocutusOfBorg: The ones I saw were duplicating existing jobs in the huge queue [10:04] that is the problem [10:04] perl won't become candidate again if new tests go in huge queue [10:06] queue's nearly done now [10:11] * LocutusOfBorg wonders how many minions you had to wake up to process it in one night [10:12] oSoMoN: thanks! Will get to it in a bit [10:13] slangasek: I'd like it if we could keep 40 for arm64 until the massive current queue is drained [10:13] So maybe we could get capacity for 60 instances until that's done [10:16] sil2100, cheers [10:32] infinity, want to take debhelper= [10:33] ? [10:33] slangasek: ah, the quota is at 56 now --- so, I'll enable the units and stop the lxc ones [10:33] apw: ^^^^ that should make you happy [10:41] Laney, thanks :) let me know when it is done as i have a test case :) [10:41] apw: 'tis [10:42] * LocutusOfBorg will upload debhelper in one hour if nobody complains, the debian fix is superior to my revert [10:43] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.29.3+17.10] [10:43] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.29.3+17.04] [10:44] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.29.3] [10:45] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.29.3~14.04] [10:48] LocutusOfBorg: is that ^ a threat? :) [10:50] lol :) I don't want to make infinity sad, but I prefer the current debhelper to go away soon [10:51] * LocutusOfBorg queues are empty, so debhelper is a nice timing to be done [10:55] who did accept xerces-c from new queue? :/ a new entangled transition? [11:06] -queuebot:#ubuntu-release- New sync: python-os-service-types (bionic-proposed/primary) [1.1.0-0ubuntu1] [11:10] not me [11:18] Not me [11:49] Laney: would you be prepared to badtest that verion of Konqueror? Konqueror is failing that and another test on KDE's own upstream CI https://build.kde.org/job/Applications%20konqueror%20kf5-qt5%20SUSEQt5.9/2/ [11:49] will report an upstream bug and aim to fix or disable for konqueror 17.08 or 17.12, whichever we ship in bionic [12:09] acheronuk: is it telling us that konqueror is broken or what? [12:11] Laney: the test is meant to detect a recurrence of this bug https://bugs.kde.org/show_bug.cgi?id=149736 which is a crash on right click on pages with certain scripts as far as I can see [12:11] KDE bug 149736 in khtml "window that closes by document.onmousedown and right-clicking into that window causes crash" [Crash,Resolved: fixed] [12:12] from old KDE4 days [12:12] I'm going to upgrade a VM to -proposed and Qt 5.9.2 and test [12:13] acheronuk: alrighty, well if you're happy then that's ok with me I guess [12:13] I'm trying to get qt to be a candidate [12:13] help this transition along a bit [12:14] dunno about the pyqt5 -> qscintilla2 thing [12:14] yep. that is great. thanks. [12:14] I'm not 'happy', but at least there is plenty of time to fix [12:15] if you have a bug # then I can put a comment with it [12:16] I'll file one once I tested to see if there is real brokenness, or just a test that needs fixing up [12:20] -queuebot:#ubuntu-release- New binary: trilinos [arm64] (bionic-proposed/universe) [12.12.1-1] (no packageset) [12:22] o/ sil2100 Would you have a moment to release percona-xtradb-cluster-5.6 in -updates for Xenial and Zesty ? (Note that Zesty has 4 autopkgtest regressions but I have documented it and reported a bug against diaspora about it, so all good for that SRU) [12:29] Laney: LP: #1732680 [12:29] Launchpad bug 1732680 in konqueror (Ubuntu Bionic) "konqueror 17.04.3 and above fails autotyests with Qt 5.92" [Undecided,New] https://launchpad.net/bugs/1732680 [12:30] thx [12:30] complete with typos! [12:30] I'll update with better details and upstream bug link when I have them [12:37] -queuebot:#ubuntu-release- New: accepted trilinos [amd64] (bionic-proposed) [12.12.1-1] [12:37] -queuebot:#ubuntu-release- New: accepted trilinos [ppc64el] (bionic-proposed) [12.12.1-1] [12:37] -queuebot:#ubuntu-release- New: accepted trilinos [arm64] (bionic-proposed) [12.12.1-1] [12:37] -queuebot:#ubuntu-release- New: accepted trilinos [s390x] (bionic-proposed) [12.12.1-1] [13:23] Laney: FYI if you are interested, Konqueror on some quick testing with Qt 5.9.2 seems to work just fine. on that bug anyway [13:26] I have no clue on qscintilla2 [13:28] * doko looks at the pythonqt bus error on armhf [14:45] -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-appindicator (artful-proposed/main) [17.10.2 => 17.10.3] (no packageset) [15:27] -queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (xenial-proposed/universe) [4.13.0-1008.9] (no packageset) [15:42] LocutusOfBorg: Wow, you gave me 10 minutes, in the middle of the night, to respond. [15:44] infinity, can you please answer then? sorry for doing it, but last time I didn't get if you want to take it from now on, or it was a "thanks for merging" [15:44] LocutusOfBorg: Can I please answer 5 hours ago? Sure. Let me grab my time machine. [15:44] last time IIRC you made a UK joke, I thought we were on the same TZ :) (and I waited more than one hour before uploading, I understand it is not enough, but I have bad connection) [15:47] can you enlight me for the future please? I can stop merging if needed, I just don't want it to be outdated, packages strictly depending on it, having to relax dependency and somewhat stuff in not going correctly in DEP-WAIT anymore, but failing instead, so it never gets retried unless somebody manually does it [15:47] LocutusOfBorg: The reason I said "please stop merging debhelper" after your last set of uploads is because you seem to care more about the latest version than about the consequences. I very intentionally let debhelper bake in Debian before merging. And then people steal the merge because they're impatient. :P [15:48] LocutusOfBorg: And there's no way that 10.0.5 was "too old" and forced you to merge 10.0.7 because of dep-waits. [15:48] LocutusOfBorg: And when you stole 10.0.5 from me, it was a similar middle-of-the-night impatience. [15:49] erm last time I did the merge and told that to you, but you did it anyway and uploaded IIRC, the intention is just to avoid other people loosing time, but if you want, I leave it to you, or better, I do it, upload in a ppa and ping you [15:50] we have different timezones, indeed, and I'm too impatient (specially when I finish my phone connection GB and I have to upload at 128kbps) :p when I find a good connection I try to be speedy in my daily contributions [15:51] Speedy and base packaging toolchain are a bad combination. [15:51] There's zero reason to constantly be in sync with sid. [15:51] Especially in a new DH branch. [15:52] It breaks a lot. One in 5 versions will migrate to testing. That's the one we want, usually. [15:52] LocutusOfBorg: But, please, just leave it to me. I've asked that more than once. [15:53] ack, btw, this version has some qmake fixes from mitya57 that might help qt5 packages [15:53] LocutusOfBorg: dep-wait> this is usually because of indirect build-dependencies, which can't be turned into a single coherent dep-wait (there's an explanation of this in lp:launchpad-buildd lpbuildd/binarypackage.py:BinaryPackageBuildManager.analyseDepWait). If you find something that doesn't fit that pattern then do let us know by way of a launchpad-buildd bug. [15:53] It's possible that some output has changed and confused the analysis code. [15:53] But it's also possible that it's one of the cases that can't be handled. [15:54] thanks! mapreri told me that there was an LP bug already [15:54] * LocutusOfBorg grabs the code [15:54] Not one I know of. [15:54] But feel free to correct me; I can't quite follow everything. [15:55] It's possible there's some incredibly general or old one that doesn't have much to do with the problem at hand. [15:55] thanks, it is clear, I'll report it [15:55] I remember some ocaml related stuff, qtplot or similar [15:55] but they were probably falling in the above case [15:56] We need extremely specific cases, ideally build links. [15:56] sad me that I didn't grab them when they happened, and it was mainly during the first autosync from unstable [15:56] haskell and ocaml generated a lot of that sadness [15:57] The Haskell cases are almost always indirect and can't be handled by simple dep-waits. [15:57] infinity, I commented the MoM output with a comment to leave it that to you, if the comment doesn't disappear... I'll remember it [15:57] A full dose-type analysis could deal with them, but that's much more difficult to do in the LP case than in the Debian case, because we have many more archives to consider. [15:58] and today's upload was a consequence of the last one, I reverted a commit, but the debian fix was "superior" and adding the qt fixes, it was worth an upload to me, sorry again [15:58] oh ok [15:58] I've considered doing it on the builder rather than centrally so that that would effectively be parallelised, but it would take a fair bit of code, and it'd mean that failures would take longer to process. Possibly swings and roundabouts. [15:59] I suspect the ocaml cases are the same, since that's usually what you get with the frequently-changing-ABI world. [16:06] btw if you have spare time (I know you have zero) LP: #1732400 might be something worth looking, I'm seeing more failures now with people upgrading their machines [16:06] Launchpad bug 1732400 in Launchpad itself "please upgrade pristine-tar to support version 3" [Undecided,New] https://launchpad.net/bugs/1732400 [16:09] Laney: \o/ [16:09] hey slangasek [16:09] slangasek: looks like instances are taking a while to get going for some reason [16:09] oh? [16:10] e.g. [16:10] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/p/python-os-win/20171116_160255_cb150@/log.gz (last s390x result on the index) [16:10] see the timestamps at the top [16:11] right [16:11] does that want a new RT then? [16:11] dunno, maybe we should look into it from our side first [16:11] like see if manual instances are slow [16:13] * Laney is hoping someone else can take a look at that [16:13] hmm, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/i386/p/python-structlog/20171116_160515_c240d@/log.gz too (i386) [16:15] this is https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/i386/p/python-structlog/20171116_160515_c240d@/log.gz [16:15] noooope [16:15] https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/tree/ssh-setup/nova#n166 [16:28] LocutusOfBorg: it isn't too far down my queue, but I have a non-LP-related deadline of next week which is top of my mind right now [16:42] slangasek, i believe postgresql will block icu migration, which is done apart from skytools3 which should imho be demoted to proposed. The rest of postgresql listed transition are false negatives, due to matching on haskel generated magic constants; or there are alternative dependencies. [16:42] https://bugs.launchpad.net/ubuntu/+source/skytools3/+bug/1732733 [16:42] Launchpad bug 1732733 in skytools3 (Ubuntu) "demote to proposed" [Undecided,New] [16:42] slangasek, infinity ^ [16:43] demoted to proposed> nack [16:43] slangasek, it's uninstallable with new postgresql-10... thus postgresql will not migrate. [16:43] slangasek, it's not clear that skytools3 is ported for 10 yet. [16:43] then it should be removed, not demoted [16:44] slangasek, ok [16:44] is there a bug (in Debian or Ubuntu) for its brokenness? [16:44] https://bugs.debian.org/878561 [16:44] Debian bug 878561 in src:skytools3 "skytools3 FTBFS with PostgreSQL 10" [Serious,Open] [16:45] slangasek, note that bug report is incomplete, as fixing debian/control doesn't make it build... [16:47] infinity, slangasek, when the time comes, and postgresql-10 is considered, and doesn't migrate because of skytools3, there is a bug for that. [16:48] that may or may not be soon. [16:48] depends on how well ADT goes for postgresql* and icu* [16:49] xnox: I've just removed skytools3 from bionic [16:49] tah [16:55] when I look at update_output, I find some packages that are just no longer built, but doesn't seem to appear on the NBS list, am I missing something? for example, rakudo-lib is no longer built by rakudo and doesn't look to have rdeps to me [16:55] that's not going to unblock a whole lot of things, but hey [16:55] oSoMoN: trying to make progress on the entangled transitions ... I'm uploading your LO package now, and we hope to make progress on the transitions tonight and tomorrow [16:55] slangasek, what about https://code.launchpad.net/~xnox/britney/hints-ubuntu/+merge/333813 ? cause i can't update systemd & util-linux.... [16:56] i have more fixes to ship now, and i'd rather see current batch migrate. [16:56] cyphermox: That won't show in a block that also tries to migrate rakudo. [16:56] doko, the one from my lo-test PPA? [16:57] cyphermox: However, rakudo isn't migrating because it's FTBFS on s390x. [16:58] Ahh, it always was. But arch:all->any grossness. [16:59] I wish britney was better at dealing with that. [16:59] Oh, wait. No. It wasn't FTBFS on s390x before. [16:59] Grr. [16:59] the output is scary [16:59] i do not know what perl is trying to tell me [16:59] perl Configure.pl --prefix=/usr --libdir=/usr/lib/perl6 --backends=moar [16:59] Unhandled exception: Bytecode validation error at offset 150, instruction 24: [16:59] out of range SC index 56283 [17:00] infinity: damnit, I didn't go look at that bit [17:00] I need to add checking for build state to update-output-helper [17:00] xnox: Endian bug. FTBFS with the same error on ppc, pcc64, and mips. [17:01] oSoMoN: yes, that one [17:01] slangasek, doko: ack [17:02] xnox: Oh, and Adrian already filed a bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880794 [17:02] Debian bug 880794 in src:rakudo "rakudo FTBFS on big endian: Unhandled exception: Bytecode validation error" [Serious,Open] [17:02] oSoMoN: fwiw libreoffice has sat ftbfs in -proposed long enough that additional library transitions have started and gotten entangled. What can we do to see such build failures addressed sooner? [17:02] Though, I'm dubious about it being a rakudo bug. [17:04] https://bugs.launchpad.net/ubuntu/+bug/1732742 [17:04] Launchpad bug 1732742 in Ubuntu "entangled transitions for bionic" [Undecided,New] [17:04] infinity, slangasek, cyphermox, xnox, Laney: ^^^ [17:04] slangasek, that's an upstream issue that we can do little about (except disabling a unit test, which is what I did, and what's being uploaded, but it's not a satisfactory solution) [17:05] oSoMoN: yes, but we have four months to fix that ... [17:05] oSoMoN: I keep your name on the upload, ok? [17:06] doko, yes, I'll keep an eye on the issue and will re-enable the test as soon as it's fixed upstream [17:06] doko, that's fine [17:06] xnox: My bet's on the bug being in moarvm or nqp, which both got updated to the same snapshot level as rakudo. Depending on the size of the diffs, diffing 2017.06 -> 2017.10 and looking for bad math might not be awful. [17:06] (It might be terrible) [17:07] seb128, FYI ^ [17:08] 140 files changed, 10099 insertions(+), 2711 deletions(-) [17:08] Ouch. [17:08] Active project... [17:08] infinity: ah, did we not actually land the corresponding ubuntu-cdimage change to account for the livefs name changes on ubuntu-core? [17:08] slangasek: if by "we", you mean "you", seems like not. :) [17:09] ISTR you said you were doing that [17:09] I sure didn't. [17:09] I can, though. [17:09] so can I [17:09] dibs [17:09] Go for it. [17:10] I was going to have to remind myself what we broke. [17:11] 276 files changed, 87840 insertions(+), 59757 deletions(-) [17:11] Ugh. [17:11] And that's likely where the bug is. [17:11] Okay, bad plan. [17:11] git bisect [17:11] Well, a gdb to figure out WHERE it's crashing would be a good start. [17:12] Then the diff might be enough. [17:12] And a bisect as a painful last resort. [17:12] Oh my, the magic. SO MUCH MAGIC. [17:12] -#define TINYMT64_MUL (1.0 / 18446744073709551616.0) [17:12] +#define TINYMT64_MUL (1.0 / 9007199254740992.0) [17:12] - return uint64_temper(random) * TINYMT64_MUL; [17:12] + return (uint64_temper(random) >> 11) * TINYMT64_MUL; [17:12] HALP. [17:12] WHAT DOES IT MEAN. [17:13] i have seen s390x divide things differently and have a slightly different answer to x86 [17:13] that's the most awful thing I've seen in the last 18 hours [17:14] xnox: In this case, it's not IBM math, it's just a straight up endian bug. Like I said, same result on ppc/ppc64 (okay, also IBM), and mips. [17:14] * cjwatson adds another entry to the "note to self: never be an -lm maintainer" pile [17:14] xnox: So it's just going to be some dork lopping off the top end of a long or something. [17:14] infinity: well obviously those numbers differ by a factor of 2048 ;P [17:14] oSoMoN, slangasek, the workaround is suboptimal since it's a real regression due to the new icu and code that needs updating, forcing something buggy in is not ideal but well that's an option if we need to unblock things [17:14] cjwatson, yeah, there was a new result calculated in c11 mode =/ [17:15] seb128: I don't want to force in broken things, but we can't leave -proposed in this state, it's already been multiple weeks that the transitions are stalled. Should we roll back the icu transition instead? [17:15] cjwatson: The worst part about -lm maintenance right now is dealing with users who are complaining that it's becoming more accurate. [17:16] slangasek, it seems a bit of an heavy hammer to roll back, none of the solutions are nice though... [17:16] slangasek, I guess forcing in a buggy libreoffice is the easiest one though, it still sucks [17:16] cjwatson: jsm28 has been on a warpath for the last few years trying to actually meet various ISO and IEEE standards and, like, do gooder math. Turns out that Linux users prefer bad math. [17:17] slangasek, maybe those transitions should be prepared out of proposed in the futur if the outcome of using proposed is that people arguing we need to force in buggy code because we can't hold things for too long [17:18] seb128: I generally take the view that we should be aggressive about rolling back things instead of letting things be broken in devel. [17:18] feel free to roll back the icu transitions if you feel it's a better way out [17:18] I was surprised that we did a second ICU transition before letting the other bigger transitions complete [17:18] infinity: Yeah, I'd seen. It's definitely in the category of "something I'm real happy that somebody else cares about". [17:18] I'm surprised we're doing icu transitions from experimental, period. [17:19] doko said the previous icu transition was also from experimental. This is not a rationale. [17:19] right [17:19] we did that in the past very often, boos/icu from experimental. so that's nothing new [17:20] "we did it before" is also not a rationale [17:20] slangasek: I mean, it's a rationale, it's just not necessarily a rational rationale. [17:20] well maybe it was no needed to do it now where it gets entangled with other transitions and creating problems [17:20] especially when libreoffice is in the way and has real issues and need upstream changes [17:21] experimental is the dumping ground for stuff that's not releasable. We shouldn't be syncing things from experimental unless we've taken an independent decision that it is releasable, for us [17:21] so this LO issue is about a hyphenation issue in URLs? could we please be realistic about the severity of this issue? [17:22] doko: I am realistic about the severity of you syncing icu from experimental without working out the answer to this question with the desktop team in advance [17:23] doko, what was the motivation to go with the experimental version rather than staying on the unstable one. [17:23] ? [17:24] new boost, and icu is a dependency of boost [17:25] slangasek: and yes, I had asked here on archive opening that we want to open with new boost/icu. and I asked both the server team and the desktop team as well about new stuff that they want to open with [17:25] boost1.62 is in unstable, not experimental [17:26] boost1.65.1 isn't even out of new yet in Debian, apparently? [17:26] the icu 59 transition completed successfully, it's icu 60 that got stuck and entangled [17:26] doko, where did you ask desktop? [17:27] here, or on desktop. can't remember. [17:27] jbicha: Although, icu59 was also a major PITA, due to us doing it before Debian. :P [17:27] (And I am still suffering PTSD from webkit hell) [17:28] doko, I don't think we saw that/gave a reply... [17:28] the net result is that we have a tangled mess of a bunch of transitions that aren't ready to go. Deciding that a bunch of transitions should be done at the beginning of the cycle, and then being unhappy about the work involved in untangling them, well... [17:28] I didn't do haskell ... [17:30] if that's directed at me, I didn't either, all I did is upload the fixes for the transitions already started by the syncs [17:30] xnox: FFS http://paste.ubuntu.com/25975534/ the validation is new code. The actual endian bug could be ancient. Oooor, it could be a type comparison issue literally right there. [17:30] * infinity digs. [18:05] -queuebot:#ubuntu-release- Unapproved: vmdk-stream-converter (xenial-updates/universe) [0.2-1 => 0.2-1] (no packageset) (sync) [18:25] xnox: your mp doesn't say why the kde4libs autopkgtest failure should be ignored [18:27] xnox: and this test doesn't appear to have been particularly racy in the past, and the failure when triggered by dbus is a different test failure [18:29] nut/s390x should just be a badtest [18:38] Laney: worker-s390x.conf on wendigo is clearly not current, it only knows up to zesty; is that cruft I should just nuke? [18:49] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (zesty-proposed) [2.441.9] [18:57] xnox: hmm, I was unaware systemd was doing nested KVM in its autopkgtests; I thought the general model was to set Restrictions: destroy-testbed or dont-smoke-in-bed or however it's spelled, and use autopkgtest's reboot hooks? === Guest7945 is now known as Spydar007 [19:04] thanks cjwatson for caring [19:11] Laney: am I missing something, or is there nothing in the autopkgtest logs that tells us what region a given test was dispatched to? [20:11] -queuebot:#ubuntu-release- Unapproved: juju-core (zesty-proposed/main) [2.2.6-0ubuntu0.17.04.2 => 2.2.6-0ubuntu0.17.04.3] (ubuntu-server) [20:12] -queuebot:#ubuntu-release- Unapproved: juju-core (xenial-proposed/main) [2.2.6-0ubuntu0.16.04.2 => 2.2.6-0ubuntu0.16.04.3] (ubuntu-server) [20:52] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.23] [20:58] -queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (zesty-proposed) [1:2.8+dfsg-3ubuntu2.8] [21:09] -queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.29~16.04.1 => 0.32~16.04.1] (no packageset) [21:09] -queuebot:#ubuntu-release- Unapproved: nplan (zesty-proposed/main) [0.29~17.04.1 => 0.32~17.04.1] (core) [21:11] bdmurray: are you done with SRU reviews for now? I would like to do some now and don't want to step on your toes [21:12] sil2100: gonna do ubuntu-drivers-common for xenial then will take a break [21:12] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (zesty-proposed) [1:0.4.22.2] [21:13] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (xenial-proposed) [1:0.4.17.4] [21:21] bdmurray: ok, I'll look at the queue now hten [21:21] -queuebot:#ubuntu-release- New binary: rdma-core [amd64] (bionic-proposed/universe) [15-2] (no packageset) [21:21] -queuebot:#ubuntu-release- New binary: rdma-core [i386] (bionic-proposed/universe) [15-2] (no packageset) [21:21] -queuebot:#ubuntu-release- New binary: rdma-core [s390x] (bionic-proposed/universe) [15-2] (no packageset) [21:21] -queuebot:#ubuntu-release- New binary: rdma-core [armhf] (bionic-proposed/universe) [15-2] (no packageset) [21:21] -queuebot:#ubuntu-release- New binary: rdma-core [ppc64el] (bionic-proposed/universe) [15-2] (no packageset) [21:22] -queuebot:#ubuntu-release- New binary: rdma-core [arm64] (bionic-proposed/universe) [15-2] (no packageset) [21:24] -queuebot:#ubuntu-release- New: rejected rdma-core [amd64] (bionic-proposed) [15-1] [21:24] -queuebot:#ubuntu-release- New: rejected rdma-core [i386] (bionic-proposed) [15-1] [21:24] -queuebot:#ubuntu-release- New: rejected rdma-core [s390x] (bionic-proposed) [15-1] [21:24] -queuebot:#ubuntu-release- New: rejected rdma-core [arm64] (bionic-proposed) [15-1] [21:24] -queuebot:#ubuntu-release- New: rejected rdma-core [ppc64el] (bionic-proposed) [15-1] [21:24] -queuebot:#ubuntu-release- New: accepted rdma-core [amd64] (bionic-proposed) [15-2] [21:24] -queuebot:#ubuntu-release- New: accepted rdma-core [armhf] (bionic-proposed) [15-2] [21:24] -queuebot:#ubuntu-release- New: accepted rdma-core [ppc64el] (bionic-proposed) [15-2] [21:24] -queuebot:#ubuntu-release- New: accepted rdma-core [arm64] (bionic-proposed) [15-2] [21:24] -queuebot:#ubuntu-release- New: accepted rdma-core [s390x] (bionic-proposed) [15-2] [21:24] -queuebot:#ubuntu-release- New: accepted rdma-core [i386] (bionic-proposed) [15-2] [21:25] there is a new python-os-service-types sync, but I don't see any new packages, where does it come from? [21:28] jamespage: please don't land NEW packages from a ppa ... you have to track down the source for these syncs before you can review [21:29] https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3033/+sourcepub/8489711/+listing-archive-extra [21:31] anyway, rejected. missing copyright holders [21:31] -queuebot:#ubuntu-release- New: rejected python-os-service-types [sync] (bionic-proposed) [1.1.0-0ubuntu1] [21:37] doko: for bileto PPAs it's a bit more convenient, at least when you look at it through launchpad, as you click on the sync, click on the PPA and the PPA description has a link to the bileto ticket - which always has a debdiff of the changes [21:37] True, that's more clicking here and there, but it's not as bad as regular PPAs [21:42] eh, libreoffice SRU debdiff still pending, LP is slow with this (package uploaded to the queue 13 hours ago) [21:46] sil2100: sometimes the diff never arrives. I'd suspect this is such a case [21:51] sil2100: I don't see the reason to introduce new packages via ci-train. if they need review, then the whole integrity test isn't valid anymore [22:01] -queuebot:#ubuntu-release- New source: python-os-service-types (bionic-proposed/primary) [1.1.0-0ubuntu2] [22:01] jamespage: fixed, and accepted into main [22:01] -queuebot:#ubuntu-release- New: accepted python-os-service-types [source] (bionic-proposed) [1.1.0-0ubuntu2] [22:01] sil2100, jamespage: MIR approval also is another reason you circumvent with that [22:02] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (artful-proposed) [3.26.2-0ubuntu0.1] [22:04] -queuebot:#ubuntu-release- New binary: python-os-service-types [amd64] (bionic-proposed/none) [1.1.0-0ubuntu2] (no packageset) [22:04] doko: yeah, I'm just saying that fetching the debdiff is not that bad for bileto, bileto is anyway a 'deprecated' tool I'd say right now [22:05] -queuebot:#ubuntu-release- New: accepted python-os-service-types [amd64] (bionic-proposed) [1.1.0-0ubuntu2] [22:05] jbicha: hey, looking at the gnome-settings-daemon artful SRU right now, just want to confirm something - the bug mentions that both this + gnome-control-center need to land for the fix to work [22:06] jbicha: just want to make sure that if both land separately, simply the fix won't work right? It's not like things will start crashing? [22:11] -queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (artful-proposed) [3.26.2-0ubuntu0.1] [22:14] -queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (artful-proposed) [1:3.26.2-0ubuntu0.1] [22:26] -queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (artful-proposed) [3.26.2-0ubuntu0.1] [22:37] Laney: s390x queues are definitely going the wrong direction; ppc64el is shrinking, s390x is growing, which tells me we're definitely slower than before. I struggle to understand any of the crazy interfaces around ssh-setup/nova to usefully analyze things in realtime [22:39] sil2100: Are you still doing reviews? [22:40] bdmurray: I'm reviewing libreoffice for artful and then I'm done [22:43] sil2100: okay [22:53] hm, I have issues approving libreoffice, sru-review keeps timing out [22:53] I'll try in some minutes [22:54] I've ran into timeouts during the approval process and thought we could use something just to do the commenting. [22:56] This is different, it seems to be timing out on the actual approval [22:56] Not sure what's going on [22:56] Anyway, going offline from IRC, will re-try in a bit and/or tomorrow [22:56] Right but you could click the button in LP and then manually comment with this other magic tool. [22:57] Oh, right [22:57] Will do that then [22:57] o/ [23:01] -queuebot:#ubuntu-release- Unapproved: accepted strongswan [source] (artful-proposed) [5.5.1-4ubuntu2.1] [23:03] -queuebot:#ubuntu-release- Unapproved: accepted casablanca [source] (artful-proposed) [2.9.1-1ubuntu2] [23:10] -queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (artful-proposed) [3.26.1-0ubuntu2.17.10.1] [23:20] -queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (artful-proposed) [1:2.10+dfsg-0ubuntu3.1] [23:24] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-appindicator [source] (artful-proposed) [17.10.3] [23:32] -queuebot:#ubuntu-release- Unapproved: accepted s3cmd [source] (artful-proposed) [2.0.1-1~ubuntu1.17.10.1] [23:45] -queuebot:#ubuntu-release- Unapproved: accepted libclc [source] (xenial-proposed) [0.2.0+git20170330-3~16.04.1] [23:47] -queuebot:#ubuntu-release- Unapproved: accepted libdrm [source] (xenial-proposed) [2.4.83-1~16.04.1] === s8321414_ is now known as s8321414 [23:54] -queuebot:#ubuntu-release- New binary: libdrm [amd64] (xenial-proposed/main) [2.4.83-1~16.04.1] (core, xorg) [23:54] -queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (xenial-proposed) [1.2.6-0ubuntu0.16.04.2] [23:56] -queuebot:#ubuntu-release- Unapproved: accepted libvirt-python [source] (xenial-proposed) [1.3.1-1ubuntu1.1]