[03:26] 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] https://launchpad.net/ubuntu/+source/llvm-toolchain-9/1:9.0.1~+rc3-2/+build/18272581 [08:00] anybody knows what happened here? [08:01] the builder needs a kick [08:01] there were some issues yesterday === andrewc is now known as Guest42747 [08:09] thanks, I hope somebody can do it without having to restart the full build [08:09] * LocutusOfBorg leaves [08:47] 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] Launchpad bug 1856531 in libgit2 (Ubuntu) "Please RM julia arm64 and armhf binaries" [Undecided,New] https://launchpad.net/bugs/1856531 [08:47] julia binaries that is [09:25] sil2100: image built! \o/ [09:38] tjaalton: sweet! [09:39] RikMills: I'll try looking into that, but no promises [09:39] no problem. I expect steve will tonight if you can't [09:41] 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] I don't know why the current one in proposed used the version from cosmic [09:43] probably because it was uploaded 6mo ago [09:43] 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] sil2100: ^ just a rebuild and allows the dell team to move to an archive version [09:56] 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] 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] sil2100: yeah, probably [10:52] as ycheng already hit the bug it's supposed to fix [10:54] LocutusOfBorg: Sorry, ended up having to retry it [10:55] (Which was a bit unnecessary in fact, but I misdiagnosed because buildd-manager seemed otherwise functional) [10:55] 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] eh, I guess I'll accept bionic for now and see how the rest goes later today [10:56] cool [10:56] it's in focal at least [10:57] and eoan queue [10:58] Yeah, it's missing a fwupd-signed bump, but we can push that ourselves if needed [10:58] (in eoan) [10:58] right, I added a comment on the bug [10:58] Anyway, will poke Ken later today and probably accept the eoan ones too - if not, we'll just do that next year ;) [10:58] 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] 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] sil2100, could you please drop systemd from focal-proposed? LP: #1857123 [11:47] Launchpad bug 1857123 in systemd (Ubuntu) "IPv4 addresses are not assigned in LXC with systemd 244.1" [Undecided,New] https://launchpad.net/bugs/1857123 [11:47] sil2100, this may hold back the armhf queue [11:56] cjwatson, no problem at all! thanks for using the stick! [12:04] doko, could you please drop systemd from focal-proposed? [12:04] doko, ^^ [12:13] uh, ok [12:15] y [12:16] rbalint: should be done [12:21] sil2100, thanks! [12:37] armhf autopkgtest not looking good /o\ [12:44] * Laney smites the things [13:03] looks better [13:29] LocutusOfBorg: any ideas on the status of virtualbox migration? seth mentioned kopanocore blocking gsoap blocking virtualbox. how can I help? [13:30] right now, I am trying to reproduce the kopanocore failure with a debug shell so I can investigate [13:35] thanks [13:37] cascardo, vorlon just a side note: that smoke test has been changed in the version in proposed [13:37] so, the version in release is probably buggy too [13:37] oh. looks like xnox did an upload one hour ago [13:37] thanks! [13:38] 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] =) [13:38] do you plan also to forward to debian? [13:38] cascardo: only need to wait and see if it will work or not [13:38] btw thanks a ton, I couldn't figure out [13:38] LocutusOfBorg: once it is actually green and migrates, yes [13:39] thanks^2 [13:39] :D [13:39] in any case, the patch looks good even if it doens't work [13:39] but shouldn't apt being non-interactive generally in autopkgtests env? [13:40] xnox: Great! thanks a bunch! [13:40] vorlon, can we have python-envisage kicked out from release? reason is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937730 [13:40] Debian bug 937730 in src:python-envisage "python-envisage: Python2 removal in sid/bullseye" [Serious,Open] [13:41] I would like to have python-apptools migrate [13:51] xnox, http://autopkgtest.ubuntu.com/packages/k/kopanocore/focal/ppc64el [13:51] fail :/ [13:51] I'm trying a build too [14:26] sigh [14:26] LocutusOfBorg: yes it should be non-interactive, and it was failing for me when run interactively [14:27] it passed when frontend was interactive [14:27] LocutusOfBorg: also, isn't our default mysql, mysql itself? and not mariadb [14:29] apw cascardo: the other alternative is to badtest kopanocore => it does work. Which will let virtualbox to migrate, which will unblock kernel [14:41] xnox: I like the sound of that [14:42] 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. === andrewc is now known as Guest66497 [14:53] smoke SKIP unknown restriction skippable [14:53] sigh: [14:53] Remove the broken kopanocore from focal-proposed [14:53] Laney, considering that also the one in release is broken, I would prefer not doing it [14:53] I can workaround the test by removing that new check [14:53] better than going again python2 [14:53] :/ === hggdh is now known as QuosqueTandem [15:06] Laney: remove broken kopanocore; rebuild old kopanocore against new gsoap; let that lot migrate; put kopanocore back in; try to fix it? [15:06] Laney: i can prepare a rebuild of old kopanocore in a bileto ppa. [15:15] well I can't action that unfortunately, but seems better to me than letting an unknown thing migrate [15:15] on the other hand I reproduced the failure, here is what is in the journal: https://paste.ubuntu.com/p/Jf9jGCRxJ8/ [15:15] 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] 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] 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] probably if it was a proper unit systemd would at least be able to fall back to SIGKILLing it [15:23] 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] dear release wizards, [16:00] I would like to ask about current status of fuse vs fuse3 in ubuntu [16:01] I have been investigating something new from kde named kio-fuse [16:02] this thing, apparently requires fuse3 to be installed (it runs fusermount3, provided by fuse3 package) [16:03] this package, 'fuse3' is not co-installable with the 'fuse' package (which is version 2.x) [16:05] so I did an experimental kio-fuse package with 'fuse3' in 'Depends' [16:06] it works nice, but it uninstalls some other things which depend on 'fuse' [16:06] xdg-desktop-portal for instance iirc [16:07] so I checked the reverse depends of package 'fuse' and there's a fair amount of things affected [16:07] AND... [16:07] I found this: https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0 [16:08] see the "Note to Packagers" [16:09] 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] and this way, everything would be co-installable, no matter if it was built against libfuse 2 or 3 [16:11] what do you think? am I missing something? [16:12] related, see the last sshfs-fuse upload: https://launchpad.net/ubuntu/+source/sshfs-fuse [16:12] RikMills: ↑ [16:14] santa_: https://irclogs.ubuntu.com/2019/11/19/%23ubuntu-release.html#t18:55 [16:15] or perhaps fuse3 should have a "Provides: fuse" if that works the way I think it works [16:16] fuse3 does have a provides fuse. its still broken [16:16] rikMills, https://launchpad.net/ubuntu/+source/gvfs/1.42.1-1ubuntu1 [16:16] looks like fuse3 is the way to go and we should just MIR it and revert the gvfs change [16:20] seb128: would that be why iso builds broke when sshfs-fuse ported to fuse3? kdeconnect on kubuntu iso wants sshfs-fuse [16:20] rikMills, could be yes [16:21] RikMills: thanks for the info [16:22] so what would be the solution to this, just changing the depends of all the affected packages? [16:22] seb128: I reverted the sshfs-fuse port for now, so I can revert that revert, I would be happy :) [16:22] *if I can [16:23] someone needs to MIR fuse3 [16:23] what's MIR? [16:24] 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] A versioned Provides of fuse might help too? [16:32] (unversioned Provides don't satisfy versioned dependencies) [16:33] Dunno, I've only looked at this conversation and not anything more details [16:33] *detailed [16:43] 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] cjwatson: but they are not versioned depends, xdg-desktop-portal just depends of fuse, unversioned [16:43] (for example) [16:44] No idea then :) [16:52] sil2100, i've rebuild and copied binutils for eoan if you could take a look === ginggs_ is now known as ginggs [16:55] 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] so it seems the "Provides: fuse" actually works [16:59] ... to some extent [16:59] but it would be still a problem for the isos right RikMills ? [17:02] hmm the way I see it right now the correct solution for handling this upgrade in debian would have been: [17:02] - not providing the "fuse" bin package in src:fuse [17:03] - adding a transitional dummy package "fuse" which would install "fuse3" in src:fuse3 [17:06] infinity: any comment about this? ↑ since you mentioned you were going to work on it [17:09] santa_: something on the iso build wasn't happy with the fuse dep being provide by fuse3, that is for certain [17:10] I guess it confuses the package manager [17:13] gvfs not liking its fuse depends being replaced by something from universe sounds plausible. [17:19] 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] Laney: :i386 pins: yes, I've thought about it :) just haven't written it yet [17:24] nod [17:26] Laney: do you know what's up with armhf autopkgtest queues? [17:27] 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] I did fix it by rebooting all of the lxd-armhf* [17:27] ah k [17:28] 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] should have made that fall away too [17:28] RikMills: yep, I guess that "MIR" would be in place [17:33] vorlon, could you please review/accept binutils to eoan? [17:34] rbalint: looking. did the changelog/content mismatch get fixed? [17:34] 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] $ sru-review -s eoan binutils [17:34] ERROR: queue does not have a debdiff [17:35] vorlon, it is a bin copy from -security only bileto ppa [17:35] ugh [17:35] ok [17:35] vorlon, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3878/+packages [17:35] 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] === andrewc is now known as Guest11720 [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] xnox: any thoughts on that kopanocore issue? I wonder if virtualbox can work with the gsoap version in release [19:01] cascardo: we can rebuild virtualbox against gsoap from release pocket, and let virtualbox migrate [19:02] cascardo: that's no different to rebuilding old kopacore [19:02] cascardo: let's see if i can do that. [19:10] 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] https://launchpad.net/ubuntu/+source/virtualbox/6.1.0-dfsg-3build1 publishing [22:49] hopefully should test & migrate [22:49] once migrated will upload another no change rebuild against the new abi [23:38] 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] waveform, bdmurray: i.e. it's the one that was causing those weird boot issues on 3B [23:39] I think we'll have to have a fresh look on that after new year's [23:58] are SRUs likely to be released over the holidays? (I'm thinking of python-ldap to be specific) [23:58] not a rush, just want to set expectations correctly..