/srv/irclogs.ubuntu.com/2019/07/15/#ubuntu-release.txt

wxlinfinity, vorlon: any reason why lubuntu can't have usb-creator(-kde) in our packageset?01:53
vorlonwxl: implying that lubuntu devs would be able to upload usb-creator, a package for which the Lubuntu team are definitely not the current maintainers?02:02
vorlonLocutusOfBorg: reprotest/i386> yeah I was trying to figure out if that wasn't the result of a progression rather than a regression, but I see now that it isn't - hinting02:03
tewardvorlon: can you hand-wave a no-change rebuild in the SRU queue?  Or should I wait for the rest of the SRU team to address it?02:17
wxlvorlon: we do use usb-creator-kde in our flavor. perhaps that's insufficient?04:08
vorlonwxl: and usb-creator-gtk is seeded in ubuntu-desktop, ubuntukylin-desktop, and ubuntu-mate-desktop.  So ubuntu-desktop looks like the correct packageset to me04:55
vorlonteward: I'm not in a position to do SRU reviews this evening, sorry04:56
-queuebot:#ubuntu-release- New: accepted pdal [arm64] (eoan-proposed) [1.9.1+ds-1]04:56
-queuebot:#ubuntu-release- New: accepted pdal [armhf] (eoan-proposed) [1.9.1+ds-1]04:57
-queuebot:#ubuntu-release- New: accepted hypre [amd64] (eoan-proposed) [2.16.0-2]04:57
-queuebot:#ubuntu-release- New: accepted hypre [armhf] (eoan-proposed) [2.16.0-2]04:57
-queuebot:#ubuntu-release- New: accepted hypre [ppc64el] (eoan-proposed) [2.16.0-2]04:57
-queuebot:#ubuntu-release- New: accepted pdal [amd64] (eoan-proposed) [1.9.1+ds-1]04:57
-queuebot:#ubuntu-release- New: accepted pdal [ppc64el] (eoan-proposed) [1.9.1+ds-1]04:57
-queuebot:#ubuntu-release- New: accepted hypre [arm64] (eoan-proposed) [2.16.0-2]04:57
-queuebot:#ubuntu-release- New: accepted hypre [s390x] (eoan-proposed) [2.16.0-2]04:57
-queuebot:#ubuntu-release- New: accepted pdal [s390x] (eoan-proposed) [1.9.1+ds-1]04:57
-queuebot:#ubuntu-release- New: accepted hypre [i386] (eoan-proposed) [2.16.0-2]04:57
-queuebot:#ubuntu-release- New: accepted pdal [i386] (eoan-proposed) [1.9.1+ds-1]04:57
-queuebot:#ubuntu-release- New binary: python-pdal [amd64] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)06:14
-queuebot:#ubuntu-release- New binary: python-pdal [i386] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)06:15
-queuebot:#ubuntu-release- New binary: python-pdal [s390x] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)06:15
-queuebot:#ubuntu-release- New binary: python-pdal [ppc64el] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)06:15
-queuebot:#ubuntu-release- New binary: python-pdal [arm64] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)06:16
-queuebot:#ubuntu-release- New binary: python-pdal [armhf] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)06:16
-queuebot:#ubuntu-release- Unapproved: lasso (bionic-proposed/main) [2.5.1-0ubuntu1 => 2.5.1-0ubuntu1.1] (ubuntu-server)07:45
-queuebot:#ubuntu-release- Unapproved: lasso (disco-proposed/main) [2.6.0-2build1 => 2.6.0-2ubuntu0.1] (ubuntu-server)07:45
sil2100grrr, pending-sru page again is outdated, I'm running sru-report locally to determine if it's crashing or maybe it's just something with the runs on snakefruit07:48
sil2100Ok, it doesn't crash07:49
sil2100Laney, cjwatson: could one of you log into snakefruit and check what's up? The current report is "Generated: 2019-07-12 15:54:18 UTC"07:50
sil2100I was able to successfully run sru-report and get some meaningful output07:50
RikMillssil2100: morning. I need to do some more verification on the list of bugfixes, which I doubt I can finish today, but I assume it would be possible to get the Plasma SRU out later in the week?07:52
RikMillsI would like it to have some time in release pocket before we cook the 18.04.3 isos!07:53
sil2100RikMills: sure, +1 on that - just give me a poke once you feel we're good to go07:58
RikMillsthanks :)07:59
Laneysil2100: ok, done - that's the third time this has happened lately08:05
Laneydunno if you want to add some logging and find out where it's hanging, then make that part more resillient08:06
sil2100Laney: actually I saw compontent-mismatches outdated as well08:06
sil2100Like, the current component-mismatches is from 2019-07-12 20:3008:06
sil2100There's a .html.new from today, but it's like half-way generated?08:06
sil2100Weird things are happening lately08:07
sil2100Laney: anyway, thanks for running that, guess +1 on adding some logging - we never had frequent issues like that, so no one really needed any debugging08:08
Laneyactually I found this from component-mismatches08:09
Laneyhttps://paste.ubuntu.com/p/nhkGXGfcjk/08:09
sil2100huh08:24
Laneythanks freenodeâ„¢08:39
Laneythis person's display name is breaking it https://launchpad.net/~paelzer 😈08:40
cjwatsonhaha08:42
cjwatsonhopefully not too hard to fix08:42
apwoh the circle of friends; heh08:43
sil2100cpaelzer: ^ hah, it's you who broke the component-mismatches report!08:48
ograprobably time to switch it to utf8 then ;(08:48
ograerr08:48
ogra;)08:48
cpaelzersil2100: yes apw found that08:50
cpaelzerbut I have the UTF char so long that I wonder it broke now08:50
cpaelzeranyway thanks apw for fixing08:50
* apw hands the bottle of thanks to Laney08:51
=== pieq_ is now known as pieq
Laneysil2100: something like lp:~laney/ubuntu-archive-tools/cm-utf808:58
Laneythere's probably a strictly more complete / correct way to do that08:58
LaneyI can't commit to lp:ubuntu-archive-tools so please review and do it if you like it :-)08:59
cjwatsonI have horrible things at the start of various scripts I've written that force stdout to be UTF-809:00
cjwatsonThat sort of thing may do the job but note that I'm pretty certain it will break in Python 309:01
* cjwatson hunts09:02
cjwatsonLaney: https://bazaar.launchpad.net/~ubuntu-core-dev/debian-installer/ubuntu/view/head:/build/util/help-to-gfxboot.py#L14 maybe?09:02
Laneycjwatson: yeah OK, this is probably better than leaving a time-bomb behind09:03
Laneythanks09:03
cjwatson(The Python 3 hack there shouldn't be necessary in practice as of 3.7, since it was really just to deal with LC_CTYPE=C and 3.7 coerces that to UTF-8, but it should also still be harmless on 3.7)09:04
LocutusOfBorgvorlon, hello, how do you feel about merging iptables from unstable=?09:07
LocutusOfBorgand please don't look at my squid upload, thanks (I'm deeply sorry for the quality of the upload, but I couldn't fix it)09:15
LocutusOfBorg(I can say, such bugs are already there, gcc-9 is just showing them)09:17
* Laney pokes sil2100 09:52
* LocutusOfBorg pockes somebody to accept python-pdal09:56
-queuebot:#ubuntu-release- New: accepted python-pdal [amd64] (eoan-proposed) [2.1.8+ds-2]09:59
-queuebot:#ubuntu-release- New: accepted python-pdal [armhf] (eoan-proposed) [2.1.8+ds-2]09:59
-queuebot:#ubuntu-release- New: accepted python-pdal [ppc64el] (eoan-proposed) [2.1.8+ds-2]09:59
-queuebot:#ubuntu-release- New: accepted python-pdal [arm64] (eoan-proposed) [2.1.8+ds-2]09:59
-queuebot:#ubuntu-release- New: accepted python-pdal [s390x] (eoan-proposed) [2.1.8+ds-2]09:59
-queuebot:#ubuntu-release- New: accepted python-pdal [i386] (eoan-proposed) [2.1.8+ds-2]09:59
sil2100Laney: ugh! Looking ;)10:22
sil2100Ah, I see apw already merged it o/10:23
Laneyyeah10:24
LocutusOfBorgthanks nftables for not failing locally, on pbuilder, on sbuild on debomatic and failing on ubuntu archive with no reason :(10:26
sil2100Laney: btw. do you know if sru-report is hung again on snakefruit?10:29
Laneysil2100: no, should run soon10:30
sil2100Ah, ok, I see the .new there indeed, thanks10:31
Laneyyeah seems to be moving10:32
-queuebot:#ubuntu-release- Unapproved: wslu (bionic-proposed/main) [2.0.0-0ubuntu2~18.04.0 => 2.0.0-0ubuntu2~18.04.1] (no packageset)11:36
-queuebot:#ubuntu-release- Unapproved: wslu (xenial-proposed/main) [2.0.0-0ubuntu2~16.04.0 => 2.0.0-0ubuntu2~16.04.1] (no packageset)11:36
-queuebot:#ubuntu-release- Unapproved: wslu (disco-proposed/main) [2.0.0-0ubuntu2 => 2.0.0-0ubuntu2.19.04.0] (core)11:36
-queuebot:#ubuntu-release- New binary: nftables [amd64] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)11:41
-queuebot:#ubuntu-release- New binary: nftables [ppc64el] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)11:41
-queuebot:#ubuntu-release- New binary: nftables [i386] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)11:41
-queuebot:#ubuntu-release- New binary: nftables [s390x] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)11:41
-queuebot:#ubuntu-release- New binary: nftables [arm64] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)11:43
-queuebot:#ubuntu-release- New binary: nftables [armhf] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)11:43
LocutusOfBorghello, please accept nftables, I plan to transition it...12:48
tewardanyone on SRU today to handle the no change rebuild SRU for NGINX in the Bionic unapproved queue?  Just asking since theres TLS1.3 isms for managing TLS 1.3 proto and ciphers hat are ignored unless we build against 1.1.1 now in the repos there12:50
apwteward, can do12:51
-queuebot:#ubuntu-release- New: accepted nftables [amd64] (eoan-proposed) [0.9.1-2ubuntu2]12:51
-queuebot:#ubuntu-release- New: accepted nftables [armhf] (eoan-proposed) [0.9.1-2ubuntu2]12:51
-queuebot:#ubuntu-release- New: accepted nftables [ppc64el] (eoan-proposed) [0.9.1-2ubuntu2]12:51
-queuebot:#ubuntu-release- New: accepted nftables [arm64] (eoan-proposed) [0.9.1-2ubuntu2]12:51
tewardapw thank you kindly.12:51
-queuebot:#ubuntu-release- New: accepted nftables [s390x] (eoan-proposed) [0.9.1-2ubuntu2]12:51
-queuebot:#ubuntu-release- New: accepted nftables [i386] (eoan-proposed) [0.9.1-2ubuntu2]12:51
apwteward, and those are correctly in -security ?  the openssl updates12:55
apwteward, or are we actually trying to have nginx in -security with different support to those in -updates12:57
tewardapw: ask mdeslaur.  they never brought 1.1.1 into -security12:57
tewardso the repos are TECHNICALLY in a diverged state12:57
tewardand that was apparently Security's decision12:57
mdeslaurnono, we're still waiting for the last openssl SRU to go through before all the packages get copied to -security12:58
tewardso that is out of my hands to answer12:58
tewardso it sounds like the SRU queue needs more love and attention then?12:58
apwmdeslaur, so it is appropriate to have an nginx in -proposed built against 1.1.1 then, right ?12:59
mdeslaurnot sure why 1832919 isn't being released for bionic12:59
mdeslaurapw: yes12:59
mdeslaurapw: we can rebuild it in -security if/when we want12:59
apwmdeslaur, i can see no reason it is not released and some time ago13:00
apwmdeslaur, oh because its not released in disco13:01
mdeslaur:(13:01
apwxnox, your openssl upload is all lagging in disco ... for lack of validation on some of the 'other' bugs13:02
-queuebot:#ubuntu-release- Unapproved: accepted nginx [source] (bionic-proposed) [1.14.0-0ubuntu1.3]13:05
apwteward, anyhow ^ seems appropriate in the new world order, even if we cannot release it13:05
apw(though i believe we can to -updates only)13:05
tewardapw: ack.13:08
-queuebot:#ubuntu-release- Unapproved: accepted creduce [source] (disco-proposed) [2.10.0-1~19.04]13:11
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1014.15] (no packageset)13:11
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (disco-proposed) [2.6.1-4ubuntu2.2]13:21
-queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (disco-proposed) [4.18.0-1ubuntu2.1]13:36
-queuebot:#ubuntu-release- Unapproved: accepted creduce [source] (bionic-proposed) [2.10.0-1~18.04]13:41
-queuebot:#ubuntu-release- Unapproved: secureboot-db (bionic-proposed/main) [1.4~ubuntu0.18.04.1 => 1.5~ubuntu0.18.04.1] (core)13:47
-queuebot:#ubuntu-release- Unapproved: secureboot-db (xenial-proposed/main) [1.4~ubuntu0.16.04.1 => 1.5~ubuntu0.16.04.1] (core)13:47
-queuebot:#ubuntu-release- Unapproved: secureboot-db (disco-proposed/main) [1.4 => 1.5~ubuntu0.19.04.1] (core)13:47
-queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (disco-proposed) [2.0.0-0ubuntu2.19.04.0]13:49
-queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (bionic-proposed) [2.0.0-0ubuntu2~18.04.1]13:53
xnoxapw:  right, let me verify all the things then.14:06
coreycbsil2100: hello, if you have any cycles for your SRU rota today we have cinder and designate in the bionic unapproved queue that fix ftbfs in bionic-proposed. i've also synced with folks since to make sure we're on the same page with ensuring packages build successfully before hand.14:18
-queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (xenial-proposed) [2.0.0-0ubuntu2~16.04.1]14:22
sil2100coreycb: ok o/14:56
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (bionic-proposed) [2:12.0.7-0ubuntu2]15:10
-queuebot:#ubuntu-release- Unapproved: accepted designate [source] (bionic-proposed) [1:6.0.1-0ubuntu1.2]15:22
-queuebot:#ubuntu-release- Unapproved: cargo (disco-proposed/universe) [0.35.0-0ubuntu1~19.04.1 => 0.36.0-0ubuntu1~19.04.1] (no packageset) (sync)15:24
-queuebot:#ubuntu-release- Unapproved: rustc (disco-proposed/universe) [1.34.1+dfsg2+llvm-0ubuntu1~19.04.1 => 1.35.0+dfsg0.1+llvm-0ubuntu1~19.04.1] (no packageset) (sync)15:25
-queuebot:#ubuntu-release- Unapproved: cargo (bionic-proposed/universe) [0.35.0-0ubuntu1~18.04.1 => 0.36.0-0ubuntu1~18.04.1] (no packageset) (sync)15:26
-queuebot:#ubuntu-release- Unapproved: rustc (bionic-proposed/universe) [1.34.1+dfsg2+llvm-0ubuntu1~18.04.1 => 1.35.0+dfsg0.1+llvm-0ubuntu1~18.04.1] (no packageset) (sync)15:26
-queuebot:#ubuntu-release- Unapproved: cargo (xenial-proposed/universe) [0.35.0-0ubuntu1~16.04.1 => 0.36.0-0ubuntu1~16.04.1] (no packageset) (sync)15:26
-queuebot:#ubuntu-release- Unapproved: rustc (xenial-proposed/universe) [1.34.1+dfsg2+llvm-0ubuntu1~16.04.1 => 1.35.0+dfsg0.1+llvm-0ubuntu1~16.04.1] (no packageset) (sync)15:27
-queuebot:#ubuntu-release- Unapproved: accepted cargo [sync] (bionic-proposed) [0.36.0-0ubuntu1~18.04.1]15:29
-queuebot:#ubuntu-release- Unapproved: accepted rustc [sync] (bionic-proposed) [1.35.0+dfsg0.1+llvm-0ubuntu1~18.04.1]15:29
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1014.15]15:32
coreycbsil2100: thanks!15:37
-queuebot:#ubuntu-release- Unapproved: accepted cargo [sync] (disco-proposed) [0.36.0-0ubuntu1~19.04.1]15:41
-queuebot:#ubuntu-release- Unapproved: accepted cargo [sync] (xenial-proposed) [0.36.0-0ubuntu1~16.04.1]15:41
-queuebot:#ubuntu-release- Unapproved: accepted rustc [sync] (disco-proposed) [1.35.0+dfsg0.1+llvm-0ubuntu1~19.04.1]15:41
-queuebot:#ubuntu-release- Unapproved: accepted rustc [sync] (xenial-proposed) [1.35.0+dfsg0.1+llvm-0ubuntu1~16.04.1]15:41
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (disco-proposed) [13.2.6-0ubuntu0.19.04.2]15:47
xnoxapw:  about eoan - 5.2.0-8.9 looks all green on autopkgtests (retried a few things in the morning) is it good to unblock, or not yet?15:56
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (bionic-proposed) [12.2.12-0ubuntu0.18.04.1]15:57
apwxnox, do i have it blocked ?16:04
apwxnox, i thought sforshee had a couple of test failures; perhaps not16:04
apwxnox, or is it blocked on the bug ...16:04
sforsheeapw, xnox: yes blocked on the bug16:10
sforsheetrying to confirm that a network-manager test regression is not a kernel regression16:11
-queuebot:#ubuntu-release- Unapproved: rejected secureboot-db [source] (disco-proposed) [1.5~ubuntu0.19.04.1]16:13
-queuebot:#ubuntu-release- Unapproved: rejected secureboot-db [source] (bionic-proposed) [1.5~ubuntu0.18.04.1]16:13
Laneythe network-manager tests are in a fairly bad state atm unfortunately16:14
-queuebot:#ubuntu-release- Unapproved: rejected secureboot-db [source] (xenial-proposed) [1.5~ubuntu0.16.04.1]16:14
LaneyTill's been working on them16:14
Laneyrcj: could you review https://code.launchpad.net/~mvo/livecd-rootfs/+git/livecd-rootfs/+merge/370065 again pls?16:15
vorlonLaney: do you also intend to cherry-pick https://code.launchpad.net/~tobijk/livecd-rootfs/+git/livecd-rootfs/+merge/370096 to bionic or do you need tobikoch to submit a second MP?16:16
sforsheeLaney: I assume part of that is because it tries to build modules and the -fcf-protection thing is breaking that16:16
vorlonif that were so, the tests should be passing w/ linux 5.2 in -proposed16:17
sforsheeright, there are some IPv6 address assignment tests failing with 5.2 that look to be new failures16:17
Laneysforshee: They're broken independent of that16:17
sforsheealthough my laptop is getting an IPv6 address just fine16:18
LaneyI suppose you could run what you've seen past Till and he might be able to tell you if it's new or not16:18
vorlonanyway, 'AssertionError: 0 not greater than or equal to 2 : []' doesn't point to a kernel module issue ;)16:18
Laneyvorlon: I can do, once these changes are validated in eoan16:19
Laneywould be helpful if the bug(s) were proactively SRUified if they aren't already16:19
vorlonLaney: validated in eoan> since there seems to be a fair bit of urgency around this, I'd suggest not waiting for such verification before SRUing but doing it in parallel16:20
vorlontobikoch: ^^ could you fix up the bug report to add the appropriate SRU template?16:20
Laneyvorlon: well I'm not going to be able to get to it before finishing today, was planning to see tomorrow's ISOs and then backport16:20
vorlonok :)16:20
Laneyfeel free to take over though if you'd like16:21
vorlonprobably ENOTIME for that, just trying to make sure no one is blocked :)16:21
Laneynod16:21
sforsheetkamppeter: so Laney says you've been working on broken network-manager tests, I'm seeing a couple of failures with the kernel in eoan-proposed and it would be helpful to know if those are known to be broken or racy16:25
sforsheethe ones that are failing are:16:25
sforsheeethernet: manual connection, IPv6 with only RA, preferring public address16:25
sforsheeethernet: manual connection, IPv6 with only RA, preferring temp address16:25
sforsheeoh and this one shows up in one of the logs too, but only once - ethernet: auto-connection, IPv6 with DHCP16:28
sforsheethe others have appeared in multiple runs16:28
tkamppeterI was only aware of that some tests do not work.16:32
tkamppetersforshee, for further development on the test script (better debuggability) I have repeatedly run some of the tests. There I have also observed that the  ethernet: manual connection, IPv6 with only RA, preferring public address sometimes fails.16:33
tkamppetersforshee, the test system has kernel 5.0.0-20.16:34
sforsheetkamppeter: ok so that's something, though it has seemed to fail fairly consistently in adt with 5.216:34
sforsheebut maybe I'm just having bad luck16:34
sforsheeit's only happened on amd64 and i386 though which is also odd16:35
tkamppetersforshee, what is "adt"?16:36
sforsheetkamppeter: autopkgtest, I can't remember what that acronym was for (auto device test?) but I guess it is outdated16:37
cjwatsonIn the very early days it was autodebtest and the initialism persisted in command names for a while (partly because apt- wasn't a good prefix to use)16:38
cjwatsonNow the commands are just autopkgtest or autopkgtest-* though)16:38
sforsheeour kernel tooling still calls it adt, so that's what I tend to call it16:39
Laneyrcj: (I think that it's not the place you indicated it should be put in)16:40
tkamppeterIs there any known bug in network support in kernel 5.2? Or a known change of how some of its networking functionality works?16:51
Laney(commented)16:51
Laney(re: livecd-rootfs; going to upload without mvo's change now)16:52
tewardsil2100: autopkgtest fail due to internal test env networking issues is unrelated to NGINX SRU; retry queued16:53
sforsheetkamppeter: I'm not aware of any relevant networking bugs/changes from 5.2 right now, but every release has a lot of networking changes16:53
tewardinternal "unable to connect to ftpmaster" tends to be env related :P16:53
sforsheetkamppeter: I'm looking through the logs, it seems like the connection is getting activated so maybe it just isn't happening quickly enough16:55
sforsheethe inconsistency of which tests fail in a given run also support that as a possibility16:56
tkamppetersforshee, this is possible. for me it fails in the ethernet case (still with 5.0.x kernel) in the .add_and_activate_connection() step, this is also a reason why I continued improving the debuggability of the main loops.16:57
tkamppetersforshee, generally, the failures I observe happens rather rarely, perhaps once in 10 runs, so a timout or race issue is possible, probably not a general incompatibility, but note that I am still on 5.0.0-20.17:03
sforsheetkamppeter: yeah the thing that worries me is that I can't get any run with no failures at all17:04
tkamppetersforshee, does it fail always at the same place in the same way (=incompatibility of new kernel with current NM -> Need to contact NM upstream) or is the density of sporadic failures so high that the probability of all the tests passing is near zero?17:06
sforsheetkamppeter: it's that one or more of a small subset of tests fail every time, but which test varies from run to run17:15
tkamppetersforshee, if each test passes at least sometimes we have most probably no incompatibility but more some slowing factor.17:20
sforsheeyeah that's what I'm thinking17:20
tewardsil2100: autopkgtest regression for bug #1836366 cleared - the regression was entirely local to the test env with networking, no actual regression observed.17:32
ubot5bug 1836366 in nginx (Ubuntu Bionic) "[SRU] No Changes Rebuild in Bionic for OpenSSL compat reasons" [Medium,Fix committed] https://launchpad.net/bugs/183636617:32
-queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu1 => 1.2.10-1ubuntu1] (core)19:20
-queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu1 => 1.2.10-1ubuntu1] (core)19:21
-queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu1 => 1.2.10-1ubuntu1] (core)19:23
-queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu1 => 1.2.10-1ubuntu1] (core)19:24
=== msalvatore_ is now known as msalvatore
-queuebot:#ubuntu-release- New binary: plymouth [amd64] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)21:16
-queuebot:#ubuntu-release- New binary: plymouth [s390x] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)21:16
-queuebot:#ubuntu-release- New binary: plymouth [i386] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)21:17
-queuebot:#ubuntu-release- New binary: plymouth [ppc64el] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)21:17
-queuebot:#ubuntu-release- New binary: plymouth [armhf] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)21:21
-queuebot:#ubuntu-release- New binary: plymouth [arm64] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)21:26

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!