[08:19] -queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-installer [source] (disco-proposed) [0.04~19.04.1]
[08:23] -queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [source] (disco-proposed) [5.12.2+dfsg-4ubuntu1.1]
[08:48] <LocutusOfBorg> hello archive admins, how do you feel about kicking out from release captagent and opensips?
[08:48] <LocutusOfBorg> opensips is RC buggy and doesn't build with json-c
[08:49] <LocutusOfBorg> #904660 and #918393 (opensips has the same bug with FTBFS in launchpad)
[08:49] <LocutusOfBorg> captagent has #876301 #891532.
[08:50] <LocutusOfBorg> I mostly fixed everything else, json-c might even migrate today, if I can get rid of syslog-ng failures on i386 and s390x
[08:54] <LocutusOfBorg> they both have no reverse-deps and are out of buster
[09:22] -queuebot:#ubuntu-release- Unapproved: rejected qtbase-opensource-src [source] (bionic-proposed) [5.9.5+dfsg-0ubuntu2.2]
[09:22] -queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (bionic-proposed/main) [5.9.5+dfsg-0ubuntu2.1 => 5.9.5+dfsg-0ubuntu2.3] (kubuntu, qt5, ubuntu-desktop)
[09:22] -queuebot:#ubuntu-release- Unapproved: rejected qtbase-opensource-src [source] (bionic-proposed) [5.9.5+dfsg-0ubuntu2.3]
[09:41] -queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [source] (bionic-proposed) [5.9.5+dfsg-0ubuntu2.3]
[09:53] -queuebot:#ubuntu-release- Unapproved: python-eventlet (disco-proposed/main) [0.24.1-0ubuntu3 => 0.24.1-0ubuntu3.1] (openstack, ubuntu-server)
[10:45] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1011.11] (core, kernel)
[11:01] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1011.11]
[11:06] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.18.0-1024.25~18.04.1] (kernel)
[11:07] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1024.25] (kernel)
[11:08] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.18.0-1024.25~18.04.1]
[11:10] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1024.25]
[11:49] -queuebot:#ubuntu-release- Unapproved: accepted lvm2 [source] (bionic-proposed) [2.02.176-4.1ubuntu3.18.04.1]
[11:51] -queuebot:#ubuntu-release- Unapproved: accepted lvm2 [source] (xenial-proposed) [2.02.133-1ubuntu10.1]
[12:41] -queuebot:#ubuntu-release- Unapproved: accepted fonts-noto-cjk [source] (disco-proposed) [1:20190409+repack1-0ubuntu0.19.04]
[12:51] -queuebot:#ubuntu-release- Unapproved: language-selector (disco-proposed/main) [0.194 => 0.194.1] (core, personal-gunnarhj)
[12:52] -queuebot:#ubuntu-release- Unapproved: rejected language-selector [source] (disco-proposed) [0.194.1]
[12:52] -queuebot:#ubuntu-release- Unapproved: accepted language-selector [source] (disco-proposed) [0.194.1]
[13:02] -queuebot:#ubuntu-release- Unapproved: language-selector (bionic-proposed/main) [0.188.2 => 0.188.3] (core, personal-gunnarhj)
[13:05] <LocutusOfBorg> where is the right place to report an issue with the diff generation?
[13:06] <LocutusOfBorg> lots of packages on LP are diff from foo to foo+1 (pending)
[13:07] -queuebot:#ubuntu-release- Unapproved: s390-tools (eoan-proposed/main) [2.9.0-0ubuntu3 => 2.9.0-0ubuntu4] (core)
[13:07] <rbasak> LocutusOfBorg: #launchpad, though IIRC there was some talk about diffs being known to be behind
[13:07] <LocutusOfBorg> ack thanks
[13:08] <LocutusOfBorg> wow, s390x-tools went in unapproved... do we have freeze?
[13:08] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1050.55] (kernel)
[13:09] <rbasak> LocutusOfBorg: https://irclogs.ubuntu.com/2019/06/25/%23launchpad.html#t20:49 - it was a while ago
[13:10] <LocutusOfBorg> rbasak, seriously one week to recover for the worker? interesting, I would have expected it to be stuck again instead
[13:10] <rbasak> LocutusOfBorg: of course this is my opportunity to plug git-ubuntu through which you can get arbitrary diffs as you need :)
[13:10] <rbasak> LocutusOfBorg: maybe. With Launchpad I don't know - I'm just the messenger.
[13:10] -queuebot:#ubuntu-release- Unapproved: rejected language-selector [source] (bionic-proposed) [0.188.3]
[13:10] <LocutusOfBorg> rbasak, opening a webpage while you are waiting for a package to build is faster :D
[13:10] <LocutusOfBorg> I mean, I already have it open
[13:10] <LocutusOfBorg> but yes, I do manual debdiff for now
[13:11] <cjwatson> I'm not sure why this keeps going wrong.  We've had it stall a few times recently
[13:12] <cjwatson> It's supposed to have resource limits
[13:13] <cjwatson> Also monitoring doesn't seem to be firing
[13:13] -queuebot:#ubuntu-release- Unapproved: accepted fonts-noto-cjk [source] (bionic-proposed) [1:20190409+repack1-0ubuntu0.18.04]
[13:15] -queuebot:#ubuntu-release- Unapproved: accepted language-selector [source] (bionic-proposed) [0.188.3]
[13:19] <cjwatson> LocutusOfBorg: It's running again now, but I guess I'll have to keep an eye on it and look into the stalls
[13:21] <cjwatson> Any individual debdiff generation is supposed to be limited to no more than 10 minutes and 10 GiB of output
[13:26] <cjwatson> Unless something is installing a signal handler for SIGALRM behind our backs, but I can't think what would be doing that sort of thing
[13:26] <LocutusOfBorg> cjwatson, I can be your human checker
[13:26] <LocutusOfBorg> :)
[13:27] <cjwatson> Not anywhere near as effectively as I can when I have a window tailing the log :)
[13:28] <cjwatson> But thanks for letting us know
[13:28] <LocutusOfBorg> I hope it doesn't waste too much time! I prefer to waste mine ;)
[13:29] <LocutusOfBorg> thanks for having a look
[13:30] <cjwatson> The problem is that all you can tell is whether a given debdiff has or has not been generated; particularly in the case of a backlog, this isn't a good proxy for whether the system is doing anything
[13:48] -queuebot:#ubuntu-release- Unapproved: zfs-linux (bionic-proposed/main) [0.7.5-1ubuntu16.4 => 0.7.5-1ubuntu16.6] (core)
[13:49] -queuebot:#ubuntu-release- Unapproved: rejected zfs-linux [source] (bionic-proposed) [0.7.5-1ubuntu16.6]
[13:59] -queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (bionic-proposed) [0.7.5-1ubuntu16.6]
[14:06] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1050.55]
[14:51] <juliank> sil2100: We can remove the lvm2 upload from xenial, it turns out it was not needed and does not do anything
[14:51] <juliank> The broken code is in there, but we don't use it, we pass --disable-udev-systemd-background-jobs and it never gets inserted in the binary
[14:57] <sil2100> juliank: huh, I guess that's good then!
[14:58] <sil2100> juliank: yeah, I can drop the SRU in that case, as long as you are 100% sure that's the case
[14:59] <juliank> sil2100: I am
[15:00] <sil2100> juliank: ok, let me proceed with that after the DMB meeting
[15:25] <vorlon> anyone know what broke today's image builds?
[15:25] <Laney> some networking thing
[15:25] <Laney> should be fixed now
[15:30] <vorlon> ok
[15:33] <seb128> vorlon, hey, do you know who might know about unmkinitramfs and multiparts initrd (and maybe utah), I've been told that ubuntu desktop ISO promotion isn't happening since early june because of it and I'm trying to figure out who is the right person that can fix that now
[15:34] <vorlon> seb128: "I've been told" - who said this is the reason?  Do you have a link?
[15:34] <vorlon> (link to the failing tests, which don't get published to the iso tracker, so I can never find them again since the results are push)
[15:34] <seb128> vorlon, jibel wrote earlier "	it uses the wrong version of unmkinitramfs which doesn't support multipart initrds" but I didn't manage to get more details out of him (yet)
[15:35] <vorlon> ok
[15:35] <vorlon> powersj: ^^ we may need an upgrade to the unmkinitramfs in place on the utah testbed
[15:37] <jibel> vorlon, that's fine, it broke because the compression format of the initrd changed to lz4 which was not installed on the server.
[15:37] <vorlon> right
[15:37] <vorlon> yes, I had a conversation about that w/ xnox once already
[15:37] <jibel> it's green again now and images have been promoted
[15:37] <vorlon> oh
[15:37] <vorlon> \o/
[15:38] <seb128> jibel, so it's fixed now? (sorry dropped from IRC so maybe I missed some status update you might have posted, though I didn't see any on irclog)
[15:38] <seb128> vorlon, ok, sorry for the noise then, looks like we just failed at circulating the status update then
[15:38] <jibel> and I added email notification when jobs are failing so don't wait several days to notice a failure
[15:38] <seb128> who is getting them now?
[15:39] <jibel> me for a couple of days, just to make sure it doesn't spam my mailbox, then whoever you want
[15:39] <vorlon> powersj: ^^ sounds like it's handled, please ignore the ping
[15:41] <xnox> i wanted to say "multipart initrd have been supported for a while, since we included microcode early since a long time now" but yeah lz4 would have needed a manual install of a package.
[15:45] <Eickmeyer> sil2100: Thanks for the SRU on ubuntustudio-installer. Yes, you're correct, the test case is very simple for verification. That said, tested, tagged "verification-done-disco". Was simple to verify. :)
[15:48] <sil2100> \o/
[15:55] <LocutusOfBorg> anybody please accept s390-tools, its a no-change rebuild
[15:55] <LocutusOfBorg> whenever convenient, wrt freeze :)
[15:55] -queuebot:#ubuntu-release- New binary: zfs-linux [s390x] (eoan-proposed/main) [0.8.1-1ubuntu1] (core)
[15:56] -queuebot:#ubuntu-release- New binary: zfs-linux [amd64] (eoan-proposed/main) [0.8.1-1ubuntu1] (core)
[15:56] -queuebot:#ubuntu-release- New binary: zfs-linux [ppc64el] (eoan-proposed/main) [0.8.1-1ubuntu1] (core)
[15:56] -queuebot:#ubuntu-release- New binary: zfs-linux [i386] (eoan-proposed/main) [0.8.1-1ubuntu1] (core)
[15:56] <LocutusOfBorg> btw I would appreciate some bison folks, helping me understand https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931302 ?
[15:59] -queuebot:#ubuntu-release- New: accepted jsonnet [amd64] (eoan-proposed) [0.13.0+ds-1ubuntu1]
[15:59] -queuebot:#ubuntu-release- New: accepted jsonnet [armhf] (eoan-proposed) [0.13.0+ds-1ubuntu1]
[15:59] -queuebot:#ubuntu-release- New: accepted jsonnet [ppc64el] (eoan-proposed) [0.13.0+ds-1ubuntu1]
[15:59] -queuebot:#ubuntu-release- New: accepted jsonnet [arm64] (eoan-proposed) [0.13.0+ds-1ubuntu1]
[15:59] -queuebot:#ubuntu-release- New: accepted jsonnet [s390x] (eoan-proposed) [0.13.0+ds-1ubuntu1]
[15:59] -queuebot:#ubuntu-release- New: accepted jsonnet [i386] (eoan-proposed) [0.13.0+ds-1ubuntu1]
[16:06] -queuebot:#ubuntu-release- New binary: zfs-linux [arm64] (eoan-proposed/main) [0.8.1-1ubuntu1] (core)
[16:28] <cjwatson> LocutusOfBorg: https://code.launchpad.net/~cjwatson/launchpad/more-robust-debdiff-timeout/+merge/369535 may help (not expecting you to review it, just FYI)
[18:27] -queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (eoan-proposed) [2.9.0-0ubuntu4]
[20:19] <tsimonq2> infinity, vorlon: I would be curious to see the technical details related to removing the i386 arch from the archive. I have what I'd consider a smaller version of the wider archive set up with some PPAs (different PPAs acting as pockets) for Lubuntu's CI, and I'd like to remove i386 builds.
[20:21] <tsimonq2> I'm considering whether I should a) hint everything in, so the "release pocket" builds supersede all uploads with i386 builds, b) remove i386 builds from everything in the "proposed" and "release" pockets and hope Britney doesn't freak out, c) b, + removing it from the arches Britney cares about.
[20:22] <tsimonq2> I know it can be done a few ways, but I'm curious to see what the actual archive is doing so I can understand why the decision was made.
[20:29] <tsimonq2> Perhaps I am misunderstanding the timeline on the final removal, too. So, for whenever it is.
[20:35] <tsimonq2> @kc2bez: I bumped the Calamares changelog in ci/stable, fwiw.
[20:49] <vorlon> tsimonq2: have you seen the announcement amending the plan?  The specifics of what will be removed are TBD in consultation with the community. https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts
[20:50] <tsimonq2> vorlon: My understanding was that this was going to be done via an 18.04 LXD container.
[20:51] <tsimonq2> However, I've been corrected off-channel; only a few libraries will remain, yes?
[20:51] <vorlon> how many libraries remain is TBD
[20:52] <tsimonq2> My original question wasn't specific to i386 as much as it is working the tooling, and how y'all plan on doing that part of it.
[20:52] <tsimonq2> For at least some of the packages.
[20:52] <tsimonq2> (Well, am I correct to say a majority of packages in e.g. Universe will be removed?)
[20:53] <vorlon> TBD ;)
[20:53] <tsimonq2> ok :)
[20:54] <vorlon> we're currently gathering data to make an initial proposal of what we think needs to be kept in order to support the use cases identified in the discourse threads etc
[20:54] <vorlon> to support them natively on Ubuntu 19.10+, that is
[20:55] <vorlon> and that will have a public discussion
[20:55] <vorlon> and then this may translate into some sort of whitelist in launchpad
[20:56] <tsimonq2> Let me ask a more specific question then; when we do decide to remove packages, are the involved AAs simply going to go one by one and just remove the i386 binaries from devel-release?
[21:01] <vorlon> probably not one-by-one
[21:02] <tsimonq2> I guess I'm curious to see how it was done in the past with, let's say, armel.
[21:02] <vorlon> powerpc for a more recent example
[21:03] <tsimonq2> Fair.
[21:03] <vorlon> but I don't think I was directly involved in the dropping, so couldn't say how it was done
[21:03] <vorlon> those might've both been dropped at the opening of the cycle rather than mid-cycle which might(?) have made it easier
[21:04] <tsimonq2> What I'm going to do in my mini-archive (with PPAs) is, I'll remove i386 from arches Britney cares about, kick off a nightly, then kick off a Britney run, which should supersede all builds in the "release" PPA with builds that don't have i386.
[21:05] <tsimonq2> That would make sense.
[21:06] <tsimonq2> Oh, so in the archive, that would just mean a good amount of cruft is there. I thought I've seen a cleanup script for that. That'd make sense.
[21:19] <ginggs> vorlon tsimonq2: I assumed it would have been cleaner to bootstrap i386 from scratch with only the packages we want, hence my question some days ago about bumping the baseline
[21:19] <ginggs> I hoped that might make i386 less quirky
[21:20] <ginggs> and be perform better; last time I tried i386 on a netbook, a video call in google hangouts was a slideshow
[21:21] <ginggs> (it turned out the netbook in question actually supported amd64, but was shipped with win7 32-bit)
[23:03] <cjwatson> tsimonq2: There's no prior art for this.  All previous architecture drops have been done for an entire architecture at a time, not part of it, and we did the actual removal with manual SQL.
[23:04] <cjwatson> It is not clear that that will be the best approach here.  My instinct is that it won't be, but we'll see.
[23:05] <cjwatson> For example, dropping powerpc was done using https://paste.ubuntu.com/p/3bp4xsbVPM/ (repasting from internal pastebin) after removing the architecture from the series.
[23:31] -queuebot:#ubuntu-release- Unapproved: anki (disco-proposed/universe) [2.1.8+dfsg-1 => 2.1.8+dfsg-1ubuntu0.19.04.1] (no packageset)