[03:26] <doko> component-mismatches are out of date, last regenerated 2019-12-18 17:50	
[07:28] -queuebot:#ubuntu-release- New source: backport-iwlwifi-dkms (bionic-proposed/primary) [7906-0ubuntu3~18.04.1]
[08:00] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/llvm-toolchain-9/1:9.0.1~+rc3-2/+build/18272581
[08:00] <LocutusOfBorg> anybody knows what happened here?
[08:01] <tjaalton> the builder needs a kick
[08:01] <tjaalton> there were some issues yesterday
[08:09] <LocutusOfBorg> thanks, I hope somebody can do it without having to restart the full build
[08:09]  * LocutusOfBorg leaves
[08:47] <RikMills> sil2100 or apw: on LP: #1856531 could we get the armhf/arm64 release binaries removed now? gone in debian. plus cleanup in -proposed if needed
[08:47] <RikMills> julia binaries that is
[09:25] <tjaalton> sil2100: image built! \o/
[09:38] <sil2100> tjaalton: sweet!
[09:39] <sil2100> RikMills: I'll try looking into that, but no promises
[09:39] <RikMills> no problem. I expect steve will tonight if you can't
[09:41] <tjaalton> sil2100: one thing with the fwupd mess is that our dell team has used a newer version of fwupd-signed, so they're asking to bump it's version to match the one that built against fwupd 1.2.10. fwupd-signed itself has no other diff than the changelog between 1.2..1.9
[09:42] <tjaalton> I don't know why the current one in proposed used the version from cosmic
[09:43] <tjaalton> probably because it was uploaded 6mo ago
[09:43] <tjaalton> or something
[09:54] -queuebot:#ubuntu-release- Unapproved: fwupd-signed (bionic-proposed/main) [1.2~ubuntu18.04.1 => 1.10~ubuntu18.04.1] (no packageset)
[09:55] <tjaalton> sil2100: ^ just a rebuild and allows the dell team to move to an archive version
[09:56] <tjaalton> also allows upgrade to eoan, their version is newer than what's in disco..
[10:37] -queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu543.13 => 20101020ubuntu543.14] (core)
[10:39] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu543.14]
[10:51] <sil2100> tjaalton: I'm actually thinking about if maybe it wouldn't be a good idea to include the fwupd 1.2.10-1ubuntu2~ubuntu18.04.2 that's in the bionic queue first, and do the -signed bump for that version
[10:52] <tjaalton> sil2100: yeah, probably
[10:52] <tjaalton> as ycheng already hit the bug it's supposed to fix
[10:54] <cjwatson> LocutusOfBorg: Sorry, ended up having to retry it
[10:55] <cjwatson> (Which was a bit unnecessary in fact, but I misdiagnosed because buildd-manager seemed otherwise functional)
[10:55] <sil2100> Problem is, the later series don't have the fix yet, and accepting it would invalidate testing they did already on their -proposed versions
[10:55] <sil2100> eh, I guess I'll accept bionic for now and see how the rest goes later today
[10:56] <tjaalton> cool
[10:56] <tjaalton> it's in focal at least
[10:57] <tjaalton> and eoan queue
[10:58] <sil2100> Yeah, it's missing a fwupd-signed bump, but we can push that ourselves if needed
[10:58] <sil2100> (in eoan)
[10:58] <tjaalton> right, I added a comment on the bug
[10:58] <sil2100> Anyway, will poke Ken later today and probably accept the eoan ones too - if not, we'll just do that next year ;)
[10:58] <sil2100> Thanks!
[10:59] -queuebot:#ubuntu-release- Unapproved: fwupd-signed (bionic-proposed/main) [1.2~ubuntu18.04.1 => 1.10~ubuntu18.04.2] (no packageset)
[10:59] <tjaalton> excellent
[11:07] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [source] (bionic-proposed) [1.2.10-1ubuntu2~ubuntu18.04.2]
[11:11] -queuebot:#ubuntu-release- Unapproved: fwupd (bionic-proposed/main) [1.2.10-1ubuntu2~ubuntu18.04.2 => 1.2.10-1ubuntu2~ubuntu18.04.2] (desktop-core)
[11:11] -queuebot:#ubuntu-release- Unapproved: fwupd (bionic-proposed/main) [1.2.10-1ubuntu2~ubuntu18.04.2 => 1.2.10-1ubuntu2~ubuntu18.04.2] (desktop-core)
[11:12] -queuebot:#ubuntu-release- Unapproved: rejected fwupd-signed [source] (bionic-proposed) [1.10~ubuntu18.04.1]
[11:14] -queuebot:#ubuntu-release- Unapproved: fwupd (bionic-proposed/main) [1.2.10-1ubuntu2~ubuntu18.04.2 => 1.2.10-1ubuntu2~ubuntu18.04.2] (desktop-core)
[11:14] -queuebot:#ubuntu-release- Unapproved: fwupd (bionic-proposed/main) [1.2.10-1ubuntu2~ubuntu18.04.2 => 1.2.10-1ubuntu2~ubuntu18.04.2] (desktop-core)
[11:16] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (bionic-proposed) [1.2.10-1ubuntu2~ubuntu18.04.2]
[11:16] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (bionic-proposed) [1.2.10-1ubuntu2~ubuntu18.04.2]
[11:16] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (bionic-proposed) [1.2.10-1ubuntu2~ubuntu18.04.2]
[11:16] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [i386] (bionic-proposed) [1.2.10-1ubuntu2~ubuntu18.04.2]
[11:17] -queuebot:#ubuntu-release- Unapproved: accepted fwupd-signed [source] (bionic-proposed) [1.10~ubuntu18.04.2]
[11:47] <rbalint> sil2100, could you please drop systemd from focal-proposed? LP: #1857123
[11:47] <rbalint> sil2100, this may hold back the armhf queue
[11:56] <LocutusOfBorg> cjwatson, no problem at all! thanks for using the stick!
[12:04] <rbalint> doko, could you please drop systemd from focal-proposed?
[12:04] <rbalint> doko, ^^
[12:13] <sil2100> uh, ok
[12:15] <sil2100> y
[12:16] <sil2100> rbalint: should be done
[12:21] <rbalint> sil2100, thanks!
[12:37] <Laney> armhf autopkgtest not looking good /o\
[12:44]  * Laney smites the things
[13:03] <Laney> looks better
[13:29] <cascardo> LocutusOfBorg: any ideas on the status of virtualbox migration? seth mentioned kopanocore blocking gsoap blocking virtualbox. how can I help?
[13:30] <cascardo> right now, I am trying to reproduce the kopanocore failure with a debug shell so I can investigate
[13:35] <LocutusOfBorg> thanks
[13:37] <LocutusOfBorg> cascardo, vorlon just a side note: that smoke test has been changed in the version in proposed
[13:37] <LocutusOfBorg> so, the version in release is probably buggy too
[13:37] <LocutusOfBorg> oh. looks like xnox did an upload one hour ago
[13:37] <LocutusOfBorg> thanks!
[13:38] <xnox> cascardo:  i have been annoyed at kernel not migrating, chased it down to kopanocore this morning, and did an upload that should hopefully unbreak things
[13:38] <xnox> =)
[13:38] <LocutusOfBorg> do you plan also to forward to debian?
[13:38] <xnox> cascardo:  only need to wait and see if it will work or not
[13:38] <LocutusOfBorg> btw thanks a ton, I couldn't figure out
[13:38] <xnox> LocutusOfBorg:  once it is actually green and migrates, yes
[13:39] <LocutusOfBorg> thanks^2
[13:39] <LocutusOfBorg> :D
[13:39] <LocutusOfBorg> in any case, the patch looks good even if it doens't work
[13:39] <LocutusOfBorg> but shouldn't apt being non-interactive generally in autopkgtests env?
[13:40] <cascardo> xnox: Great! thanks a bunch!
[13:40] <LocutusOfBorg> vorlon, can we have python-envisage kicked out from release? reason is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937730
[13:41] <LocutusOfBorg> I would like to have python-apptools migrate
[13:51] <LocutusOfBorg> xnox, http://autopkgtest.ubuntu.com/packages/k/kopanocore/focal/ppc64el
[13:51] <LocutusOfBorg> fail :/
[13:51] <LocutusOfBorg> I'm trying a build too
[14:26] <xnox> sigh
[14:26] <xnox> LocutusOfBorg:  yes it should be non-interactive, and it was failing for me when run interactively
[14:27] <xnox> it passed when frontend was interactive
[14:27] <xnox> LocutusOfBorg:  also, isn't our default mysql, mysql itself? and not mariadb
[14:29] <xnox> apw cascardo:  the other alternative is to badtest kopanocore => it does work. Which will let virtualbox to migrate, which will unblock kernel
[14:41] <cascardo> xnox: I like the sound of that
[14:42] <xnox> apw:  can you please badtest kopanocore? the tests pass interactively, we are failing to reproduce locally / understand why it doesn't start in adt tests.
[14:53] <LocutusOfBorg> smoke                SKIP unknown restriction skippable
[14:53] <LocutusOfBorg> sigh:
[14:53] <Laney> Remove the broken kopanocore from focal-proposed
[14:53] <LocutusOfBorg> Laney, considering that also the one in release is broken, I would prefer not doing it
[14:53] <LocutusOfBorg> I can workaround the test by removing that new check
[14:53] <LocutusOfBorg> better than going again python2
[14:53] <LocutusOfBorg> :/
[15:06] <xnox> Laney:  remove broken kopanocore; rebuild old kopanocore against new gsoap; let that lot migrate; put kopanocore back in; try to fix it?
[15:06] <xnox> Laney:  i can prepare a rebuild of old kopanocore in a bileto ppa.
[15:15] <Laney> well I can't action that unfortunately, but seems better to me than letting an unknown thing migrate
[15:15] <Laney> on the other hand I reproduced the failure, here is what is in the journal: https://paste.ubuntu.com/p/Jf9jGCRxJ8/
[15:15] <Laney> it fails to stop and then the new one after the restart is busted
[15:15] -queuebot:#ubuntu-release- Unapproved: makedumpfile (eoan-proposed/main) [1:1.6.6-2ubuntu1 => 1:1.6.6-2ubuntu1.1] (core)
[15:16] <Laney> I added pkill -f -9 kopano-server, and then it passes
[15:16] -queuebot:#ubuntu-release- Unapproved: makedumpfile (bionic-proposed/main) [1:1.6.5-1ubuntu1~18.04.3 => 1:1.6.5-1ubuntu1~18.04.4] (core)
[15:16] <Laney> so the daemon does seem buggy in some way, to me
[15:17] -queuebot:#ubuntu-release- Unapproved: makedumpfile (xenial-proposed/main) [1:1.6.3-2~16.04.1 => 1:1.6.3-2~16.04.2] (core)
[15:22] <Laney> probably if it was a proper unit systemd would at least be able to fall back to SIGKILLing it
[15:23] <Laney> xnox: as you wish, to proceed with the removal / later fixup maybe ask seb12_8 to remove the pkg
[15:23]  * Laney is going to have super late lunch
[15:42] -queuebot:#ubuntu-release- New: accepted libglvnd [amd64] (focal-proposed) [1.3.0-4]
[15:42] -queuebot:#ubuntu-release- New: accepted libglvnd [armhf] (focal-proposed) [1.3.0-4]
[15:42] -queuebot:#ubuntu-release- New: accepted libglvnd [s390x] (focal-proposed) [1.3.0-4]
[15:42] -queuebot:#ubuntu-release- New: accepted libglvnd [arm64] (focal-proposed) [1.3.0-4]
[15:42] -queuebot:#ubuntu-release- New: accepted libglvnd [i386] (focal-proposed) [1.3.0-4]
[15:42] -queuebot:#ubuntu-release- New: accepted libglvnd [ppc64el] (focal-proposed) [1.3.0-4]
[15:42] -queuebot:#ubuntu-release- New: accepted mdp [amd64] (focal-proposed) [3.5-1.1]
[15:42] -queuebot:#ubuntu-release- New: accepted nitime [amd64] (focal-proposed) [0.8.1-2]
[15:42] -queuebot:#ubuntu-release- New: accepted python-skbio [amd64] (focal-proposed) [0.5.5-3]
[15:42] -queuebot:#ubuntu-release- New: accepted libxcrypt [amd64] (focal-proposed) [1:4.4.10-7]
[15:42] -queuebot:#ubuntu-release- New: accepted pbcopper [amd64] (focal-proposed) [1.3.0+dfsg-1]
[15:42] -queuebot:#ubuntu-release- New: accepted nitime [amd64] (focal-proposed) [0.8.1-1]
[15:51] -queuebot:#ubuntu-release- Unapproved: makedumpfile (disco-proposed/main) [1:1.6.5-1ubuntu1.3 => 1:1.6.5-1ubuntu1.4] (core)
[16:00] <santa_> dear release wizards,
[16:00] <santa_> I would like to ask about current status of fuse vs fuse3 in ubuntu
[16:01] <santa_> I have been investigating something new from kde named kio-fuse
[16:02] <santa_> this thing, apparently requires fuse3 to be installed (it runs fusermount3, provided by fuse3 package)
[16:03] <santa_> this package, 'fuse3' is not co-installable with the 'fuse' package (which is version 2.x)
[16:05] <santa_> so I did an experimental kio-fuse package with 'fuse3' in 'Depends'
[16:06] <santa_> it works nice, but it uninstalls some other things which depend on 'fuse'
[16:06] <santa_> xdg-desktop-portal for instance iirc
[16:07] <santa_> so I checked the reverse depends of package 'fuse' and there's a fair amount of things affected
[16:07] <santa_> AND...
[16:07] <santa_> I found this: https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0
[16:08] <santa_> see the "Note to Packagers"
[16:09] <santa_> reading that, I have the impression that the packages which depend on 'fuse' should actually depend on 'fuse3' (since it's suposed to be backwards compatible)
[16:10] <santa_> and this way, everything would be co-installable, no matter if it was built against libfuse 2 or 3
[16:11] <santa_> what do you think? am I missing something?
[16:12] <santa_> related, see the last sshfs-fuse upload: https://launchpad.net/ubuntu/+source/sshfs-fuse
[16:12] <santa_> RikMills: ↑
[16:14] <RikMills> santa_: https://irclogs.ubuntu.com/2019/11/19/%23ubuntu-release.html#t18:55
[16:15] <santa_> or perhaps fuse3 should have a "Provides: fuse" if that works the way I think it works
[16:16] <RikMills> fuse3 does have a provides fuse. its still broken
[16:16] <seb128> rikMills, https://launchpad.net/ubuntu/+source/gvfs/1.42.1-1ubuntu1
[16:16] <seb128> looks like fuse3 is the way to go and we should just MIR it and revert the gvfs change
[16:20] <RikMills> seb128: would that be why iso builds broke when sshfs-fuse ported to fuse3? kdeconnect on kubuntu iso wants sshfs-fuse
[16:20] <seb128> rikMills, could be yes
[16:21] <santa_> RikMills: thanks for the info
[16:22] <santa_> so what would be the solution to this, just changing the depends of all the affected packages?
[16:22] <RikMills> seb128: I reverted the sshfs-fuse port for now, so I can revert that revert, I would be happy :)
[16:22] <RikMills> *if I can
[16:23] <seb128> someone needs to MIR fuse3
[16:23] <santa_> what's MIR?
[16:24] <seb128> https://wiki.ubuntu.com/MainInclusionProcess
[16:24]  * RikMills hides
[16:24] -queuebot:#ubuntu-release- Unapproved: binutils (eoan-proposed/main) [2.33-2ubuntu1.1 => 2.33-2ubuntu1.2] (core) (sync)
[16:32] <cjwatson> A versioned Provides of fuse might help too?
[16:32] <cjwatson> (unversioned Provides don't satisfy versioned dependencies)
[16:33] <cjwatson> Dunno, I've only looked at this conversation and not anything more details
[16:33] <cjwatson> *detailed
[16:43] <Laney> vorlon: I had a look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/c/clutter-1.0/20191219_103907_849c1@/log.gz - it seems to be that :i386 pins aren't generated; have you thought about this?
[16:43] <santa_> cjwatson: but they are not versioned depends, xdg-desktop-portal just depends of fuse, unversioned
[16:43] <santa_> (for example)
[16:44] <cjwatson> No idea then :)
[16:52] <rbalint> sil2100, i've rebuild and copied binutils for eoan if you could take a look
[16:55] <santa_> hmm, sorry, correction: installing my kio-fuse experimental package doesn't uninstall xdg-desktop-portal, it's just that dpkg complains about it
[16:56] <santa_> so it seems the "Provides: fuse" actually works
[16:59] <santa_> ... to some extent
[16:59] <santa_> but it would be still a problem for the isos right RikMills ?
[17:02] <santa_> hmm the way I see it right now the correct solution for handling this upgrade in debian would have been:
[17:02] <santa_> - not providing the "fuse" bin package in src:fuse
[17:03] <santa_> - adding a transitional dummy package "fuse" which would install "fuse3" in src:fuse3
[17:06] <santa_> infinity: any comment about this? ↑ since you mentioned you were going to work on it
[17:09] <RikMills> santa_: something on the iso build wasn't happy with the fuse dep being provide by fuse3, that is for certain
[17:10] <santa_> I guess it confuses the package manager
[17:13] <RikMills> gvfs not liking its fuse depends being replaced by something from universe sounds plausible.
[17:19] <vorlon> LocutusOfBorg: python-envisage: done; and maybe you want to help figure out why this didn't get picked up on https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/rcbuggy-problem-packages.html
[17:21] <vorlon> Laney: :i386 pins: yes, I've thought about it :)  just haven't written it yet
[17:24] <Laney> nod
[17:26] <vorlon> Laney: do you know what's up with armhf autopkgtest queues?
[17:27] <vorlon> seems like it might be coming down now but not enough data points to know if that's an accident or if someone fixed something
[17:27] <Laney> I did fix it by rebooting all of the lxd-armhf*
[17:27] <vorlon> ah k
[17:28] <Laney> didn't find out exactly what broke them, but there was a dodgy systemd from rbalint which wasn't helping after they recovered :-)
[17:28] <Laney> should have made that fall away too
[17:28] <santa_> RikMills: yep, I guess that "MIR" would be in place
[17:33] <rbalint> vorlon, could you please review/accept binutils to eoan?
[17:34] <vorlon> rbalint: looking.  did the changelog/content mismatch get fixed?
[17:34] <rbalint> vorlon, aslo maybe pam to get it released early next year?
[17:34] -queuebot:#ubuntu-release- Unapproved: flash-kernel (bionic-proposed/main) [3.90ubuntu3.18.04.2 => 3.98ubuntu5.3~18.04.1] (core)
[17:34] <vorlon> $ sru-review -s eoan binutils
[17:34] <vorlon> ERROR: queue does not have a debdiff
[17:35] <rbalint> vorlon, it is a bin copy from -security only bileto ppa
[17:35] <vorlon> ugh
[17:35] <vorlon> ok
[17:35] <rbalint> vorlon, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3878/+packages
[17:35] <rbalint> vorlon, i forgot binutils and gccs are special, but sil2100 caught that
[17:36]  * vorlon nods
[17:42] -queuebot:#ubuntu-release- Unapproved: accepted binutils [sync] (eoan-proposed) [2.33-2ubuntu1.2]
[18:22] -queuebot:#ubuntu-release- Unapproved: mutter (eoan-proposed/main) [3.34.1+git20191107-1ubuntu1~19.10.1 => 3.34.2-1ubuntu1~19.10.1] (desktop-core, desktop-extra)
[18:26] -queuebot:#ubuntu-release- Unapproved: linux-firmware-raspi2 (bionic-proposed/multiverse) [1.20190215-0ubuntu0.18.04.1 => 1.20190819-0ubuntu0.18.04.1] (no packageset)
[18:56] <cascardo> xnox: any thoughts on that kopanocore issue? I wonder if virtualbox can work with the gsoap version in release
[19:01] <xnox> cascardo:  we can rebuild virtualbox against gsoap from release pocket, and let virtualbox migrate
[19:02] <xnox> cascardo:  that's no different to rebuilding old kopacore
[19:02] <xnox> cascardo:  let's see if i can do that.
[19:10] <cascardo> xnox: thanks!
[19:34] -queuebot:#ubuntu-release- Unapproved: u-boot (bionic-proposed/main) [2018.07~rc3+dfsg1-0ubuntu3~18.04.2 => 2019.07+dfsg-1ubuntu3~18.04.1] (core)
[22:49] <xnox> https://launchpad.net/ubuntu/+source/virtualbox/6.1.0-dfsg-3build1 publishing
[22:49] <xnox> hopefully should test & migrate
[22:49] <xnox> once migrated will upload another no change rebuild against the new abi
[23:38] <sil2100> waveform, bdmurray: I'm looking at the flash-kernel SRU and I'm a bit worried - so it seems like the bootscript that's in that SRU is actually that bootscript we have reverted for eoan?
[23:38] <sil2100> waveform, bdmurray: i.e. it's the one that was causing those weird boot issues on 3B
[23:39] <sil2100> I think we'll have to have a fresh look on that after new year's
[23:58] <gQuigs> are SRUs likely to be released over the holidays?  (I'm thinking of python-ldap to be specific)
[23:58] <gQuigs> not a rush, just want to set expectations correctly..