=== s8321414_ is now known as s8321414
[01:00] <slangasek> krytarik: fwupdate no-change rebuild should actually not have been needed; what was needed was removal of the stale libsmbios2v5 binary
[01:36] <krytarik> slangasek: That would only have made it another way of uninstallable, because:-
[01:37] <krytarik> -Depends: libc6 (>= 2.22), libefiboot1 (>= 32), libefivar1 (>= 32), libsmbios2v5
[01:37] <krytarik> +Depends: libc6 (>= 2.22), libefiboot1 (>= 32), libefivar1 (>= 32), libsmbios-c2
[02:23] <tsimonq2> New nodejs incoming that bumps its major version.
[02:55] <krytarik> slangasek: "Provides: libsmbios2 (= 2.3.1-1), libsmbios2v5 (= 2.3.1-0ubuntu2)" - aha, ok. :D
[05:12] -queuebot:#ubuntu-release- New binary: node-pinkyswear [amd64] (bionic-proposed/none) [2.2.3+dfsg-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: centrifuge [i386] (bionic-proposed/none) [1.0.3~beta-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: centrifuge [amd64] (bionic-proposed/none) [1.0.3~beta-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: libodsstream [i386] (bionic-proposed/none) [0.4.12-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: libodsstream [amd64] (bionic-proposed/none) [0.4.12-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: libodsstream [ppc64el] (bionic-proposed/none) [0.4.12-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-mclust [amd64] (bionic-proposed/none) [5.4-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: libodsstream [s390x] (bionic-proposed/none) [0.4.12-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-mclust [i386] (bionic-proposed/none) [5.4-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-mclust [s390x] (bionic-proposed/none) [5.4-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: libodsstream [armhf] (bionic-proposed/universe) [0.4.12-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: r-cran-mclust [armhf] (bionic-proposed/universe) [5.4-1] (no packageset)
[05:16] -queuebot:#ubuntu-release- New binary: libodsstream [arm64] (bionic-proposed/universe) [0.4.12-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: r-cran-mclust [arm64] (bionic-proposed/universe) [5.4-1] (no packageset)
[05:22] -queuebot:#ubuntu-release- New binary: r-cran-mclust [ppc64el] (bionic-proposed/universe) [5.4-1] (no packageset)
[06:55]  * slangasek ponders LP: #783660
[06:55] <ubot5> Launchpad bug 783660 in linux (Ubuntu Oneiric) "linux-tools: perf should link statically to libbfd" [Low,Fix released] https://launchpad.net/bugs/783660
[07:42] -queuebot:#ubuntu-release- Unapproved: cockpit (artful-backports/universe) [160-1~ubuntu17.10.1 => 161-1~ubuntu17.10.1] (no packageset)
[07:57] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (artful-backports) [161-1~ubuntu17.10.1]
[07:59] -queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [160-1~ubuntu16.04.1 => 161-1~ubuntu16.04.1] (no packageset)
[08:02] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [161-1~ubuntu16.04.1]
[09:05] <doko> apw, sforshee: when will the "blocking bug" be remove for linux in bionic-proposed?
=== cjwatson changed the topic of #ubuntu-release to: Released: Xenial 16.04.3, Artful 17.10 | Archive: open | Bionic Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
[10:49] -queuebot:#ubuntu-release- New source: dptfxtract (bionic-proposed/primary) [1.2-0ubuntu1]
[11:08] <apw> doko, that is gated on ADT/SRU testing on that kernel normally, i will deferr to sforshee on the status of that
[11:16] <doko> apw: ok, but see what sl angasek mention about 783660 above
[11:41] -queuebot:#ubuntu-release- New binary: python-daiquiri [amd64] (bionic-proposed/universe) [1.3.0-3ubuntu1] (no packageset)
[11:45] <apw> doko, so we have fixed this before, sigh
[11:45] <apw> i hate things like that that find a way to go missing long after everyone has forgotten
[11:53] <xnox> apw, add an autopkgtest, that tests the .debs to not have bfd dependencies?!
[11:53]  * xnox had to fix 3 times in systemd, to not kill processes on exit...
[12:00] -queuebot:#ubuntu-release- New: accepted python-daiquiri [amd64] (bionic-proposed) [1.3.0-3ubuntu1]
[12:01] -queuebot:#ubuntu-release- New: accepted node-pinkyswear [amd64] (bionic-proposed) [2.2.3+dfsg-1]
[12:01] -queuebot:#ubuntu-release- New: accepted libodsstream [amd64] (bionic-proposed) [0.4.12-1]
[12:01] -queuebot:#ubuntu-release- New: accepted libodsstream [armhf] (bionic-proposed) [0.4.12-1]
[12:01] -queuebot:#ubuntu-release- New: accepted libodsstream [ppc64el] (bionic-proposed) [0.4.12-1]
[12:01] -queuebot:#ubuntu-release- New: accepted r-cran-mclust [amd64] (bionic-proposed) [5.4-1]
[12:01] -queuebot:#ubuntu-release- New: accepted r-cran-mclust [armhf] (bionic-proposed) [5.4-1]
[12:01] -queuebot:#ubuntu-release- New: accepted r-cran-mclust [ppc64el] (bionic-proposed) [5.4-1]
[12:01] -queuebot:#ubuntu-release- New: accepted libodsstream [arm64] (bionic-proposed) [0.4.12-1]
[12:01] -queuebot:#ubuntu-release- New: accepted libodsstream [s390x] (bionic-proposed) [0.4.12-1]
[12:01] -queuebot:#ubuntu-release- New: accepted r-cran-mclust [i386] (bionic-proposed) [5.4-1]
[12:01] -queuebot:#ubuntu-release- New: accepted libodsstream [i386] (bionic-proposed) [0.4.12-1]
[12:01] -queuebot:#ubuntu-release- New: accepted r-cran-mclust [s390x] (bionic-proposed) [5.4-1]
[12:01] -queuebot:#ubuntu-release- New: accepted r-cran-mclust [arm64] (bionic-proposed) [5.4-1]
[12:02] -queuebot:#ubuntu-release- New: accepted centrifuge [amd64] (bionic-proposed) [1.0.3~beta-1]
[12:02] -queuebot:#ubuntu-release- New: accepted centrifuge [i386] (bionic-proposed) [1.0.3~beta-1]
[12:08] <sil2100> oSoMoN: hey!
[12:08] <sil2100> oSoMoN: looking at the libreoffice artful SRU right now
[12:09] <oSoMoN> sil2100, thanks!
[12:09] <sil2100> oSoMoN: just wanted to get an idea if this is a problem or not: I see that the debian-l10n/config part has a "--with-build-version='1:5.4.4-0ubuntu0.17.10.1~ppa1'" in the diff instead of just 17.10.1
[12:09] <sil2100> oSoMoN: not sure how this flag is used so just wanted to poke you about it
[12:10] <sil2100> Is that still ok?
[12:14] <oSoMoN> sil2100, afaik that's used in the about dialog of LO to display the build version, but in any case the ~ppa1 doesn't look right, and I don't have it here in my local build, I wonder how it sneaked in
[12:14] <oSoMoN> let me check
[12:17] <oSoMoN> sil2100, okay, I think I know what's going on
[12:17] <oSoMoN> the source package for libreoffice-l10n is automatically generated from the source package for libreoffice
[12:18] <oSoMoN> what you see in debian-l10n/config is used to generate debian/config for libreoffice-l10n
[12:18] <oSoMoN> if you check the version number in libreoffice-l10n, it's correct
[12:18] <oSoMoN> for some reason debian-l10n/config has been committed with that ~ppa1 suffix, but it doesn't affect the resulting package
[12:18] <oSoMoN> so that should be safe
[12:18] <sil2100> Ah, ok, so this is just a leftover in libreoffice's debian-l10n/config and basically doesn't do anything as is
[12:19] <doko> xnox, apw: linux autopkg tests don't help. they always fail, and test results are ignored ;p
[12:19] <sil2100> Ok, I'll let it in, some people might get the wrong version when building l10n by themselves from the libreoffice source, but yeah, it's not a biggie
[12:22] <doko> Laney, slangasek: it might make sense to priotize http://autopkgtest.ubuntu.com/packages/o/octave-interval/bionic/armhf (mpfr4 transition)
[12:23] <sil2100> oSoMoN: grrr, libreoffice is causing my tools to timeout when accepting the SRU
[12:24] <sil2100> oSoMoN: anyway, I'll get it in today, but I'll have to do it manually after lunch
[12:24] <oSoMoN> sil2100, no they shouldn't get the wrong version, because they would run "debian/rules update-l10n" first to generate the libreoffice-l10n source package, and that would fix the version number
[12:24] <oSoMoN> sil2100, thanks!
[12:25] <sil2100> Ah, so even better
[12:40] <xnox> doko, har har
[13:26] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-115.139] (core, kernel)
[14:10] -queuebot:#ubuntu-release- New binary: sagemath [amd64] (bionic-proposed/universe) [8.1-3ubuntu1] (no packageset)
[14:13] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-115.139]
[14:22] -queuebot:#ubuntu-release- New binary: sagemath [arm64] (bionic-proposed/universe) [8.1-3ubuntu1] (no packageset)
[14:22] <xnox> slangasek, could you please RM two php packages, removed from testing, maintained "RC-autoremove them" rather them RM-ROM them. Blocking phpunit & php7.2 transitions.
[14:22] <xnox> https://bugs.launchpad.net/ubuntu/+source/php-guzzlehttp-psr7/+bug/1748904
[14:22] <ubot5> Ubuntu bug 1748904 in php-guzzlehttp-psr7 (Ubuntu) "RM: ROM Useless In debian, and in Ubuntu too" [Undecided,Confirmed]
[14:49] -queuebot:#ubuntu-release- Unapproved: pulseaudio (artful-proposed/main) [1:10.0-2ubuntu3 => 1:10.0-2ubuntu3.1] (core)
[14:50] -queuebot:#ubuntu-release- Unapproved: rejected pulseaudio [source] (artful-proposed) [1:10.0-2ubuntu3.1]
=== ChrisTownsend1 is now known as ChrisTownsend
[16:01] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (artful-proposed) [1:5.4.4-0ubuntu0.17.10.1]
[16:07] <oSoMoN> sil2100, thanks for reviewing and approving the LO SRU !
[16:07] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [source] (artful-proposed) [1:5.4.4-0ubuntu0.17.10.1]
[16:22] <sil2100> oSoMoN: yw!
[16:22] <sil2100> Finally went through
[16:22] <sil2100> (no LP timeouts)
[17:15] -queuebot:#ubuntu-release- New binary: django-ipware [amd64] (bionic-proposed/none) [2.0.1-1] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: golang-github-labstack-gommon [amd64] (bionic-proposed/none) [0.2.3-1] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: golang-github-gocarina-gocsv [amd64] (bionic-proposed/none) [0.0~git20180113.45cbb9c-1] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: assemblytics [amd64] (bionic-proposed/none) [0~20170131+ds-1] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: golang-rsc-qr [amd64] (bionic-proposed/none) [0.0~git20161121.48b2ede-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: git-publish [amd64] (bionic-proposed/none) [1.4.2-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: gmailieer [amd64] (bionic-proposed/none) [0.6-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: ignition-common [amd64] (bionic-proposed/none) [1.0.1-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: nanook [amd64] (bionic-proposed/none) [1.26+dfsg-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: python-etcd3gw [amd64] (bionic-proposed/none) [0.2.1-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: ignition-common [i386] (bionic-proposed/none) [1.0.1-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: python-bd2k [amd64] (bionic-proposed/none) [1.14~alpha1.43-1] (no packageset)
[17:21] <slangasek> doko: what's the resolution for linux-tools?  I can sort out octave-interval, but I haven't seen any decision yet on linux-tools which was the last blocker
[17:35]  * tsimonq2 checks to see how much the queues were swamped after nodejs
[17:37] <tsimonq2> Ah ok, might take a bit.
[17:42] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [17.2-30-gf7deaf15-0ubuntu1~16.04.1 => 17.2-35-gf576b2a2-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[17:42] -queuebot:#ubuntu-release- New binary: ignition-common [arm64] (bionic-proposed/none) [1.0.1-1] (no packageset)
[17:43] <tsimonq2> slangasek: Can you please process ubiquity-slideshow-ubuntu in Xenial Unapproved?
[17:43] <tsimonq2> Would be good to get that over with.
[17:44] -queuebot:#ubuntu-release- New binary: ignition-common [armhf] (bionic-proposed/none) [1.0.1-1] (no packageset)
[17:46] -queuebot:#ubuntu-release- New: accepted assemblytics [amd64] (bionic-proposed) [0~20170131+ds-1]
[17:46] -queuebot:#ubuntu-release- New: accepted git-publish [amd64] (bionic-proposed) [1.4.2-1]
[17:46] -queuebot:#ubuntu-release- New: accepted golang-github-gocarina-gocsv [amd64] (bionic-proposed) [0.0~git20180113.45cbb9c-1]
[17:46] -queuebot:#ubuntu-release- New: accepted golang-rsc-qr [amd64] (bionic-proposed) [0.0~git20161121.48b2ede-1]
[17:46] -queuebot:#ubuntu-release- New: accepted python-bd2k [amd64] (bionic-proposed) [1.14~alpha1.43-1]
[17:46] -queuebot:#ubuntu-release- New: accepted django-ipware [amd64] (bionic-proposed) [2.0.1-1]
[17:46] -queuebot:#ubuntu-release- New: accepted golang-github-labstack-gommon [amd64] (bionic-proposed) [0.2.3-1]
[17:46] -queuebot:#ubuntu-release- New: accepted python-etcd3gw [amd64] (bionic-proposed) [0.2.1-1]
[17:46] -queuebot:#ubuntu-release- New: accepted gmailieer [amd64] (bionic-proposed) [0.6-1]
[17:46] -queuebot:#ubuntu-release- New: accepted nanook [amd64] (bionic-proposed) [1.26+dfsg-1]
[17:47] -queuebot:#ubuntu-release- Unapproved: ceph (artful-proposed/main) [12.2.1-0ubuntu0.17.10.1 => 12.2.2-0ubuntu0.17.10.1] (kubuntu, ubuntu-desktop, ubuntu-server)
[17:47] -queuebot:#ubuntu-release- Unapproved: cloud-init (artful-proposed/main) [17.2-30-gf7deaf15-0ubuntu1~17.10.1 => 17.2-35-gf576b2a2-0ubuntu1~17.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[17:47] <xnox> tsimonq2, should the nodejs be actually a force sync, no?
[17:48] <xnox> tsimonq2, it's using ssl1.1 now, which has always been disabled in both debian and ubuntu builds of openssl1.1?
[17:48] <tsimonq2> xnox: No, that final bit of the delta is needed for autopkgtests to pass correctly.
[17:48] <xnox> tsimonq2, please explain.
[17:49] <ginggs> tsimonq2 xnox: probably not needed any more
[17:49] <xnox> tsimonq2, note this new nodejs, is no longer using openssl1.0, but is using openssl1.1
[17:49] <ginggs> tsimonq2: i asked you to test without it
[17:49] <tsimonq2> Ah ok, I was talking with ginggs last night and I thought the final patch was still needed for tests.
[17:50] -queuebot:#ubuntu-release- New binary: ignition-common [ppc64el] (bionic-proposed/none) [1.0.1-1] (no packageset)
[17:50] <tsimonq2> xnox: Right, but that was only one part of the delta.
[17:51] <xnox> tsimonq2, so in openssl1.0 in Ubuntu, we had sslv3 "visible" on the symbols and ABI level, but these were stub functions that did nothing. This was done in ubuntu to preserve ABI and not bump 1.0.0 to 1.0.2 like it was done in Debian.
[17:51] <tsimonq2> xnox: Ah ok.
[17:51] <xnox> with the 1.1.0 ABI neither Ubuntu nor Debian have sslv3 compiled, and we no longer ship the stub functions, thus it should be the same.
[17:51] <tsimonq2> Understood, I'll force sync on the next Debian upload.
[17:51] <xnox> tsimonq2, does nodejs pass the autopkgtests in debian ci?
[17:52] <tsimonq2> xnox: afair, yes.
[17:52] <xnox> cool.
[17:52] <tsimonq2> (I'm on mobile, ftr)
[17:52] <tsimonq2> So yeah, you know openssl better than I, I'll trust that the delta can be dropped :)
[17:53] <tsimonq2> Thanks ginggs and xnox
[18:07] -queuebot:#ubuntu-release- New binary: llvm-toolchain-4.0 [s390x] (bionic-proposed/universe) [1:4.0.1-9] (no packageset)
[18:09] -queuebot:#ubuntu-release- New binary: gnocchi [amd64] (bionic-proposed/universe) [4.2.0-0ubuntu1] (no packageset)
[18:15] <nacc> slangasek: so symfony is stuck in b-p because of several other packages, which Debian appears likely to RM. (LP: #1748941) We would need to change src:civicrm ahead of Debian, but it already is uninstallable there. Would it be reasonable to move it to -proposed while we wait to see what Debian does to it? I'm checking on further reverse-deps.
[18:15] <ubot5> Launchpad bug 1748941 in symfony (Ubuntu) "symfony 3.4.3+dfsg-1ubuntu4 stuck in bionic-propsed" [Undecided,New] https://launchpad.net/bugs/1748941
[18:27] <xnox> nacc, i also am pondering if we need to drop monolog and/or its tests, as they fail with new phpunit and i'm struggling to fix them.
[18:27] <xnox> upstream has stopped making releases; and their trunk is way ahead of what we currently ship.
[18:27] <xnox> or should I just ship a snapshot of monolog?
[18:27] <nacc> xnox: yeah i saw that :/
[18:28] <nacc> xnox: so evenn with the namespaced test class, the tests faill?
[18:28] <xnox> nacc, yes, and upstream checkout fails too.
[18:28] <nacc> sigh
[18:29] <xnox> missmatch of assertions thrown; no assertions made; etc.
[18:29] <xnox> or uplaod with disabled tests....
[18:29] <nacc> we'd need to patch symfony if we drop it, as it's a reverse-dep
[18:30] <nacc> but that's ok
[18:30] <slangasek> nacc: if the point is that we are not going to do the work to fix civicrm, which has an Ubuntu delta only because of the fixing we did of it for the *last* transition, then I would recommend just removing the package and letting it come back in only via Debian unstable
[18:30] <xnox> nacc, i have fixed php-email-validator php-enum.
[18:30] <nacc> xnox: thanks! i saw those go green :)
[18:30] <xnox> nacc, so i think symfony should undo monolog integration package; and we should drop monolog too.
[18:30] <nacc> xnox: i'm +1 on that
[18:30] <nacc> slangasek: ack
[18:30] <xnox> nacc, cause monolog and sabre-vobject-3 are the only two that are blocking phpunit at this point.
[18:31] <xnox> nacc, could you unwind symfony & monolog then? I am past end of day....
[18:31] <nacc> xnox: yep
[18:33] <nacc> slangasek: subscribed ~ubuntu-archive to that bug, and put in an ordered sequence of removals. I believe that will together let symfony through and then I can do a follow-on version for what xnox just said
[18:37] <nacc> xnox: in case you happen to still be EOD'd, did you already submit the retriggers for phpunit -> php-{enum,email-validator} ?
[18:37] <nacc> *EOD'ing
[18:38] <xnox> nacc, i can't remember. And i'm not seeing php-email-validator uploads anywhere, i must be blind and/or did not upload successfully.
[18:39] <nacc> xnox: ok, i can look too, was it an upstream update?
[18:39] <xnox> i believe so
[18:39] <nacc> xnox: ok, i'll track it down, thanks!
[18:58] -queuebot:#ubuntu-release- New binary: llvm-toolchain-4.0 [ppc64el] (bionic-proposed/universe) [1:4.0.1-9] (no packageset)
[18:58] <flexiondotorg> rbasak: Following on from earlier, is this in your remit?
[18:58] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/topmenu-gtk/+bug/1744912
[18:58] <ubot5> Ubuntu bug 1744912 in topmenu-gtk (Ubuntu) "Please remove topmenu-gtk from the Bionic archive" [Undecided,New]
[19:33] <nacc> flexiondotorg: no, that'd be an AA
[20:10] <slangasek> nacc: awl just needed the retry button hit on its build failure; awl and davical should both come back into bionic shortly
[20:11] -queuebot:#ubuntu-release- New binary: awl [amd64] (bionic-proposed/universe) [0.59-1] (no packageset)
[20:13] <slangasek> nacc: you said "Remove src:drupal7 (for completeness)" but you didn't open a bug task on drupal7 here
[20:16] <doko> slangasek: I pinged apw and sforshee, and apw deferred for sforshee for testing the kernels
[20:18] <slangasek> doko: and what about temporarily breaking the linux-tools packages?
[20:19] <slangasek> and what are the chances of properly fixing linux-tools again to statically link bfd+liberty instead of dynamically linking them?
[20:19] <slangasek> since this is biting us in two different ways right now
[20:23] <doko> I pinged them about it too
[20:23] <doko> slangasek: and sure, I'm fine to break linux-tools. it's just some perf stuff
[20:25] <nacc> slangasek: re: {awl,davical}, thanks! sorry for missing that
[20:26] <nacc> slangasek: re: drupal7, task opened
[20:27] <slangasek> sforshee, apw: ^^ I think doko and I are conspiring to leave the linux-tools-* packages broken in bionic release pocket until the new versions migrate.  And linux-tools should be re-fixed to statically link libbfd+libiberty instead of dynamically linking. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/783660
[20:27] <ubot5> Ubuntu bug 783660 in linux (Ubuntu Oneiric) "linux-tools: perf should link statically to libbfd" [Low,Fix released]
[20:31] <apw> slangasek: okies, I have a patch to stop tools using libbfd, is liberty also unversioned library nightmare?
[20:31] <slangasek> apw: stop using, or static linking?
[20:32] <apw> stop using, we have intended to all along but upstream stopped us from disabling it
[20:33] <apw> by changing and breaking the opt-out
[20:33] <slangasek> apw: it appears libbfd has the library versioning nightmare, libiberty does not
[20:33] <slangasek> (I think because libiberty is *only* available static?)
[20:33] <apw> but it continues to link liberty, then we ought to be OK
[20:34] <apw> I will send that out tommorrow when tested better
[20:34] <slangasek> confirmed, libiberty is static-only
[20:35] <slangasek> tsimonq2: ironically, the slideshow SRU is to update the screenshot used; but the screenshot is already stale wrt the current lubuntu.me website
[20:37] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (xenial-proposed) [113.1]
[20:58] <tsimonq2> slangasek: It's the one from Bionic, and while it is indeed a little bit outdated, it's better than nothing :)
[20:58] <slangasek> ok
[20:59] <tsimonq2> slangasek: What's your opinion irt waiting the usual 7 days?
[20:59] <tsimonq2> Keep it like the normal SRU policy or let it right in when confirmed?
[21:02] <slangasek> tsimonq2: the 7 day waiting period is a default, not a mandate; but also, this doesn't seem like an SRU that we need to hurry, since it only affects the installer and we're definitely not going to miss the point release
[21:04] <blackboxsw> infinity: I don't know if you have already been pinged on pending cloud-init SRU uploades for xenial & artful-proposed. If there is time today,  we've got a replacement for cloud-init 17.2.30 -> 17.2.35 which contains fixes discovered during SRU testing. So, we need to remove 17.2.30 from xenial/artful proposed and queue 17.2.35 instead.
[21:04] <blackboxsw> our SRU bug has been updated accordingly.https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1747059
[21:04] <ubot5> Ubuntu bug 1747059 in cloud-init (Ubuntu Artful) "sru cloud-init (17.1.46-g7acc9e86-0ubuntu1) update to 17.2.30-gf7deaf15-0ubuntu1" [Medium,Fix committed]
[21:25] <doko> apw, slangasek, yes libiberty is only static
[21:25] <apw> doko, ok then this ought to be sufficient
[21:28] <slangasek> apw: ok, in the meantime imma go break linux-tools-* now, thanks :)
[21:28] -queuebot:#ubuntu-release- New binary: golang-github-gokyle-twofactor [amd64] (bionic-proposed/universe) [0.0~git20170918.eaad188-1] (no packageset)
[21:29] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-35.39] (core, kernel)
[21:31] <doko> jbicha: any idea what keeps ruby* in main in -release? it already wants to demote in -proposed
[21:33] <infinity> slangasek: Of course, building linux-tools statically against binutils implies you'd also be adding a Built-Using header, which should lead to the same block, if britney were properly respecting Built-Using.
[21:34] <infinity> slangasek: (iow: this only fixes migration because you're taking advantage of bugs in the tools)
[21:35] <slangasek> infinity: Built-Using is important to reconcile for release, but I'm not sure it should gate migration
[21:35] <infinity> slangasek: It may still be correct to link bfd statically anyway (and if that's generally true, maybe it should stop providing a dynamic library to link against), but yeah, the kernel/binutils coupling in migration *should* exist regardless of static or dynamic linkage.
[21:36] <infinity> slangasek: Examining all built-using a few weeks before release and making sure they're all sane would probably also be fine-ish, but that's not something we've done either.
[21:36] <infinity> (note I say a few weeks, not a few days, because if a static link is lagging by months, it could take non-trivial time to unwind why and fix it)
[21:43] <jbicha> doko: see the Dec 6 changelog for https://tracker.debian.org/media/packages/t/texlive-bin/changelog-2018.20180119.46378-1
[21:44] <doko> jbicha: and?
[21:44] <doko> no ruby mentioned
[21:45] <jbicha> doko: "remove outdated deps on ruby, wish, python"
[21:45] <doko> ahh, that's 2017.20170613.44572-7
[21:46] <doko> and we should build with our recent poppler
[21:46] <doko> hmm, do we?
[22:08] <doko> slangasek: I'm not accepting the sagemath binaries in NEW (mpfr4 dependency)
[22:09] -queuebot:#ubuntu-release- New: accepted awl [amd64] (bionic-proposed) [0.59-1]
[22:09] -queuebot:#ubuntu-release- New: accepted gnocchi [amd64] (bionic-proposed) [4.2.0-0ubuntu1]
[22:10] -queuebot:#ubuntu-release- New: accepted golang-github-gokyle-twofactor [amd64] (bionic-proposed) [0.0~git20170918.eaad188-1]
[22:10] -queuebot:#ubuntu-release- New: accepted ignition-common [arm64] (bionic-proposed) [1.0.1-1]
[22:10] -queuebot:#ubuntu-release- New: accepted ignition-common [i386] (bionic-proposed) [1.0.1-1]
[22:10] -queuebot:#ubuntu-release- New: accepted ignition-common [amd64] (bionic-proposed) [1.0.1-1]
[22:10] -queuebot:#ubuntu-release- New: accepted ignition-common [ppc64el] (bionic-proposed) [1.0.1-1]
[22:10] -queuebot:#ubuntu-release- New: accepted ignition-common [armhf] (bionic-proposed) [1.0.1-1]
[22:13] <doko> ohh, there some times when I love mail spams ... [ubuntu/bionic] * (Accepted)  102 times :-)
[22:14] -queuebot:#ubuntu-release- New: accepted sagemath [amd64] (bionic-proposed) [8.1-3ubuntu1]
[22:14] -queuebot:#ubuntu-release- New: accepted sagemath [arm64] (bionic-proposed) [8.1-3ubuntu1]
[22:23] <slangasek> doko: should actually be fine to accept sagemath since it's currently not in bionic
[22:32] <acheronuk> slangasek: do you know if a autopkgtest for a package can be allocated to a builder with a larger disk space available. I have a new test in a package that "All benchmarks create a relatively large directory tree and then watch that recursively"
[22:33] <acheronuk> but it gets out of space fails
[22:34] <acheronuk> I'll probably disable it as even upstream CI seems to struggle. but I was curious
[22:36] <slangasek> acheronuk: no; the autopkgtest infrastructure relies, in the same way launchpad does, on having generic units for scalability
[22:37] <slangasek> acheronuk: actually, I take that back - we do have a whitelist of 'big packages' that take an m1.large instance instead of the default... I suspect those do have larger disk
[22:38] <tsimonq2> slangasek: To be specific, this little gem: https://cgit.kde.org/kcoreaddons.git/commit/autotests/kdirwatch_unittest.cpp?id=421e85344db729f1be3042245c70289643215ab0
[22:40] <slangasek> tsimonq2: is that actually a disk space problem?  a 'large directory tree' for inotify purposes shouldn't really require a lot of disk space, just a lot of inodes
[22:41] <slangasek> from the description, this test seems like a profiling aid to inform development, not something that should be run as a regression test
[22:42] <slangasek> like, the only circumstance under which this test should fail is if it's not a fit for the infrastructure (i.e. too small disk etc); so this test passing or failing tells you nothing about whether the package has been broken
[22:42] <slangasek> and in particular if this is an expensive test, it's bad design to include it in your CI in such a form
[22:43] <acheronuk> yes, which is why I was going towards disabling it.
[22:44]  * slangasek nods
[22:44] <tsimonq2> slangasek: Good question; I don't know much about the test, just providing context :)
[22:53] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-35.39]
[23:12] -queuebot:#ubuntu-release- New binary: psautohint [s390x] (bionic-proposed/none) [1.1.0-1] (no packageset)
[23:13] <tsimonq2> slangasek: SRU for ubiquity-slideshow-ubuntu> ah, just seeing this now, ack
[23:14] -queuebot:#ubuntu-release- New binary: psautohint [amd64] (bionic-proposed/none) [1.1.0-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: psautohint [i386] (bionic-proposed/none) [1.1.0-1] (no packageset)
[23:25] -queuebot:#ubuntu-release- New binary: psautohint [ppc64el] (bionic-proposed/none) [1.1.0-1] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: psautohint [arm64] (bionic-proposed/none) [1.1.0-1] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: psautohint [armhf] (bionic-proposed/none) [1.1.0-1] (no packageset)
[23:30] <tsimonq2> I just got the 65 day nag email about libindi. Fixing bug 1747306 will unstick that (and I filed it more than a week ago). Could someone please take a look?
[23:30] <ubot5> bug 1747306 in indi-apogee (Ubuntu) "RM: obsolete and Ubuntu-only" [High,New] https://launchpad.net/bugs/1747306
[23:34] <slangasek> tsimonq2: what about indi-sbig?
[23:35] <tsimonq2> slangasek: I haven't considered that because it doesn't seem to be directly blocking the libindi transition, but that should probably go too, yes.
[23:35]  * tsimonq2 checks rdeps real quick
[23:35] <tsimonq2> All clear it seems.
[23:35] <slangasek> tsimonq2: it does directly block it, but because it only exists on amd64+i386, depending on which architecture britney reports on first, you may not get info about it in update_output
[23:35] <tsimonq2> slangasek: ah ok
[23:35] <slangasek> tsimonq2: what does "part of the INDI modules source tarball" mean? Does this mean the indi-apogee package is redundant with something else in the archive?
[23:37] <tsimonq2> slangasek: From what I can tell, upstream these leaf modules are now part of one "3rd party" tarball instead of separate tarballs.
[23:37] <tsimonq2> slangasek: I haven't investigated this in a while, give me a min to see if there's a replacement in the archive :)
[23:38] <slangasek> tsimonq2: ok - I just wasn't sure if "indi modules source tarball" maybe meant it was now provided by libindi.  If it's not, that's fine too
[23:39] <tsimonq2> slangasek: nope, two separate tarballs
[23:40] <tsimonq2> slangasek: And it seems that these two packages (apogee and sbig) are the only ones in Ubuntu. The upstream author has a PPA, but none of these are in the archive with the exceptions of the aforementioned packages.
[23:40] <tsimonq2> To be honest, I haven't quite dug into whether or not multiple source packages sharing one tarball is possible, and if it is, if it's acceptable.
[23:41] <tsimonq2> (two separate tarballs meaning libindi and 3rdparty)
[23:41] <slangasek> generally you don't want two source packages sharing one tarball, you want one source package building multiple binary packages from that tarball
[23:42] <tsimonq2> Right, that's what I thought.
[23:42] <tsimonq2> I just don't know if that's in policy or not :)
[23:45] <slangasek> the only case where you might want to use the same tarball in two source packages is when the two source packages need to be in different archive components
[23:45] <slangasek> but we've thankfully gotten away from needing to do that most of the time
[23:46] <tsimonq2> I thought archive administrators could cherry pick specific binaries into specific components?
[23:46] <tsimonq2> I mean, with that existing, out of curiosity, in what scenario might that have to be done still?
[23:49] <slangasek> tsimonq2: in principle, no package in universe or main should depend on or build-depend on anything in multiverse.  So if you have a package which is free software but some of its binary packages need non-free bits in order to build, *maybe* you want to split that into universe and multiverse sources.
[23:50] <tsimonq2> slangasek: Ah, gotcha.
[23:52] <tsimonq2> slangasek: I get the build-depends part of that because that's shared for the whole source package, but couldn't you have a binary that needs something in multiverse in a main/universe source package be cherry-picked into multiverse?
[23:53] <slangasek> rbasak: do you happen to know any reason for rmysql to build-depend explicitly on mariadb instead of mysql-deafults?
[23:54] <slangasek> tsimonq2: it's possible, and that may have been done here and there, though it also doesn't make me comfortable
[23:54] <tsimonq2> slangasek: Me neither. :P
[23:54] <tsimonq2> slangasek: Ok, thanks.
[23:55] <tsimonq2> slangasek: indi-sbig> were you going to RM that too or should I file an additional bug?
[23:55] <doko> slangasek: please update the bad-test for mercurial, or because that succeeded only for the very first time, maybe reset it?
[23:57] <slangasek> doko: my mercurial hint is "testdep removed from the archive" on all archs, which is not the reason for the current failure on ppc64el
[23:58] <doko> slangasek: so I should add it that it fails again, and then you update the hint?
[23:59] <slangasek> doko: that's fine with me.  but if you want me to add a badtest hint for a different failure, I need analysis to go with it
[23:59] <doko> well, I retry, failing network test