[00:00] <mwhudson> hah, that upload probably wouldn'
[00:01] <mwhudson> t have built anyway
[00:20] -queuebot:#ubuntu-release- Unapproved: live-build (focal-proposed/main) [3.0~a57-1ubuntu<IP_ADDRESS> => 3.0~a57-1ubuntu<IP_ADDRESS>] (desktop-core)
[00:54] -queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu27.2 => 2.20.11-0ubuntu27.3] (core, i386-whitelist)
[00:59] -queuebot:#ubuntu-release- Unapproved: rejected apport [source] (focal-proposed) [2.20.11-0ubuntu27.3]
[01:44] -queuebot:#ubuntu-release- New binary: pyqt5-sip [amd64] (groovy-proposed/universe) [12.8.0-1] (no packageset)
[01:45] -queuebot:#ubuntu-release- New binary: pyqt5-sip [arm64] (groovy-proposed/universe) [12.8.0-1] (no packageset)
[01:45] -queuebot:#ubuntu-release- New binary: pyqt5-sip [armhf] (groovy-proposed/universe) [12.8.0-1] (no packageset)
[01:58] -queuebot:#ubuntu-release- New binary: pyqt5-sip [ppc64el] (groovy-proposed/universe) [12.8.0-1] (no packageset)
[02:08] -queuebot:#ubuntu-release- Unapproved: memcached (eoan-proposed/main) [1.5.10-0ubuntu3 => 1.5.10-0ubuntu3.1] (ubuntu-server)
[02:08] -queuebot:#ubuntu-release- Unapproved: memcached (focal-proposed/main) [1.5.22-2 => 1.5.22-2ubuntu0.1] (ubuntu-server)
[02:22] -queuebot:#ubuntu-release- New binary: pyqt5-sip [s390x] (groovy-proposed/universe) [12.8.0-1] (no packageset)
[05:58] <LocutusOfBorg> can anybody please recreate and update ubuntu chroots? there is a bug fixed in debhelper, I can confirm the fix, but even with the fixed debhelper migrating in groovy release ppc64el is still sad
[05:59] <LocutusOfBorg> (please don't retry the build)
[05:59] <LocutusOfBorg> https://launchpadlibrarian.net/482665193/buildlog_ubuntu-groovy-ppc64el.telegram-purple_1.4.3-3_BUILDING.txt.gz
[05:59] <LocutusOfBorg> dpkg-genbuildinfo: error: cannot fstat file ../telegram-purple-dbgsym_1.4.3-3_ppc64el.ddeb: No such file or directory
[05:59] <LocutusOfBorg> looks like somewhere an old debhelper is used, not the one that is installed in the chroot
[05:59] <LocutusOfBorg> I tried a build from a newly created local ppc64el chroot and worked
[08:16] <cjwatson> LocutusOfBorg: That doesn't seem plausible.  There's nowhere that an old debhelper could live.  The problem is something else
[08:17] <cjwatson> LocutusOfBorg: Did your chroot have pkgbinarymangler in it?
[08:19] <cjwatson> LocutusOfBorg: Perhaps you could try the latest cpc-buildd image, which would be what we'd update the LP chroots to if we updated them: https://launchpad.net/~cloud-images/+livefs/ubuntu/groovy/cpc-buildd/+build/220089
[08:19] <cjwatson> (You want livecd.ubuntu-base.rootfs.tar.gz from that)
[08:34] <LocutusOfBorg> cjwatson, I don't have binarymangler, it was a pbuilder chroot
[08:35] <LocutusOfBorg> is it possible for an ubuntu-archive admin to kick out gnome-chemistry-utils because of debian bug: #947529? it can't be built since focal
[08:36] <cjwatson> LocutusOfBorg: I think it's necessary to try the candidate new chroot before stating that a new chroot will fix it; and this is the sort of thing where you need more accuracy than a pbuilder chroot will provide
[08:36] <doko> sil2100, apw, Laney, bdmurray: please ignore the rapmap autopkg test for any version, for any arch except for amd64. the package is only built there
[08:38] <LocutusOfBorg> cjwatson, actually I'm trying my new chroot with an added b-d on pkgbinarymangler :)
[08:39] <LocutusOfBorg> I know it might be not the same, but easier for me to test it
[08:41] <cjwatson> LocutusOfBorg: Anyway chances of a new chroot fixing this kind of thing seem quite negligible
[08:41] <cjwatson> It's very likely some other complicated interaction that doesn't show up in your less-accurate setup, I'm afraid
[08:42] <cjwatson> Normally all that new chroots might fix would be possibly some kind of build-dep installation failure, or of course slow build-dep installation
[08:42] <cjwatson> debhelper isn't even installed in the chroots to start with
[08:51] <Laney> doko: ok, pushed, fwiw a MP or even giving the text of a hint would make it a little bit easier
[08:51] <doko> "the package is only built there", but thanks
[08:52] <Laney> hm?
[09:05] <doko> tseliot: looking at primus-vk in -proposed, do the depends on the virtual packages need adjustments, or should the package not built at all?
[09:09] <tseliot> doko, do you have a link I can have a look at?
[09:10] <doko> tseliot: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#primus-vk
[09:16] <tseliot> doko, I think we can drop it, since it expects nvidia packages that quite different from ours
[09:17] <doko> tseliot: could you file a removal bug with the reasoning and assign it to ubuntu-archive?
[09:18] <doko> ginggs: fyi, ^^^
[09:19] <doko> LocutusOfBorg, tumbleweed: I see you gave back primer3/s390x. any follow-up on that?
[09:20] <tseliot> doko, I am going to have a closer look, and if I can't fix it easily, I'll file that bug report
[09:21] <doko> ta
[09:29] <LocutusOfBorg> doko, no idea for primer3, looks like an old endianess issue since 2 years or so
[09:32] <LocutusOfBorg> doko, I have an idea now
[09:35] <LocutusOfBorg> cjwatson, reproducible in pbuilder too, just we need to call dh_builddeb -a
[09:41] <LocutusOfBorg> let me find if pkgbinarymangler is responsible
[09:51] <doko> Trevinho: https://launchpadlibrarian.net/482050195/buildlog_ubuntu-groovy-amd64.nux_4.0.8+18.10.20180623-0ubuntu2_BUILDING.txt.gz
[09:51] <doko> you introduced these fallthrough comments before. could you have a look, orjust disabled -Werror?
[09:58] <LocutusOfBorg> cjwatson, confirmed pkgbinarymangler is the one to blame
[09:58] <cjwatson> Right
[10:00] <LocutusOfBorg> and only if dpkg-buildpackage is run with -B
[10:06] <apw> i don't suppose we get to blame p-itti any more
[10:08] -queuebot:#ubuntu-release- Unapproved: backport-iwlwifi-dkms (focal-proposed/universe) [8324-0ubuntu1 => 8324-0ubuntu3~20.04.1] (no packageset)
[10:15] -queuebot:#ubuntu-release- New sync: pocketsphinx-python (groovy-proposed/primary) [1:0.1.15-2]
[10:15] <LocutusOfBorg> can anybody please accept it? it hasn't been autosyncd because pocketsphinx was still needing a merge ^^
[10:23] -queuebot:#ubuntu-release- New binary: pocketsphinx [amd64] (groovy-proposed/universe) [0.8.0+real5prealpha+1-11ubuntu1] (no packageset)
[10:26] <RikMills> ubuntu-archive when convenient LP: #1880630
[10:30] <doko> RikMills: already done
[10:32] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (focal-proposed) [1.142.1]
[10:38] <RikMills> :)
[10:40] <LocutusOfBorg> cjwatson, I'm really sad...
[10:40] <LocutusOfBorg>         cp -p /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm /usr/share/perl5/Debian/Debhelper/Dh_Getopt.pm perl5/Ubuntu/PkgBinaryMangler/.
[10:40] <LocutusOfBorg>         sed -i 's/Debian::Debhelper::/Ubuntu::PkgBinaryMangler::/g' perl5/Ubuntu/PkgBinaryMangler/*.pm
[10:40] <LocutusOfBorg> this is done on pkgbinarymangle build, so we "embed" some code from debhelper, and without no-change rebuilds we still get the very same bugs over and over
[10:41] -queuebot:#ubuntu-release- Unapproved: accepted busybox [source] (focal-proposed) [1:1.30.1-4ubuntu6.1]
[10:41] <cjwatson> I have no objection to somebody working out how to improve the situation
[10:42] <LocutusOfBorg> I'm thinking about using the Debhelper one, it is just a copy-paste, but I'm pretty sure who did that had good reasons, and ENOPERL here :)
[10:42] <LocutusOfBorg> in the meanwhile I'm uploading a no-change rebuild (modulo some changes lol)
[10:43] <LocutusOfBorg> oh I might know the reason for that. pkgbinarymangler uses Dh_Lib but doesn't depend on debhelper
[10:44] <LocutusOfBorg> would add a new debhelper dependency generate some chicken and egg issue?
[10:45] <LocutusOfBorg> (oh we might have some cdbs old stuff still out there)
[10:48] <cjwatson> cdbs depends on debhelper ...
[10:48] <cjwatson> It means every build would end up with debhelper installed rather than just 99% of them
[10:48] <cjwatson> I would mildly prefer to avoid it since those builds are already weird in various ways
[10:49] <cjwatson> And I can imagine that it would increase the set of possible failure modes that would require manual intervention to get out of
[10:49] <cjwatson> Probably wouldn't be the absolute end of the world or anything but nice to avoid if possible
[10:50] <LocutusOfBorg> you mean to depend on debhelper?
[10:50] <cjwatson> Yes
[10:50] <cjwatson> Not sure I actually quite understand why it's needed in the first place though
[10:50] <cjwatson> Ubuntu::PkgBinaryMangler::Dh_Lib is only used by pkgbinarymangler's dh_builddeb wrapper
[10:51] <cjwatson> And that wrapper is only called by builds that use dh_builddeb, which must all already build-depend on debhelper
[10:52] <cjwatson> So I think (just by inspection) that it could just as well use Debian::Debhelper::Dh_Lib directly and drop its copies
[10:52] <cjwatson> That would be better than having it depend on debhelper - it would be a simplification in more ways
[10:53] <LocutusOfBorg> cjwatson, so you are suggesting my patch to directly use debhelper without depending on it?
[10:54] <cjwatson> Yes.  I suspect that the copies were introduced when pkgbinarymangler was shaped slightly differently
[10:57] <cjwatson> Specifically I'm suggesting (but entirely untested) https://paste.ubuntu.com/p/xS7D2P7cS4/
[11:05] <LocutusOfBorg> cjwatson, it is *exactly* the one I'm testing :)
[11:06] <LocutusOfBorg> modulo copyright changes :)
[11:06] <cjwatson> Heh
[11:07] <cjwatson> (I suspect that at one point this was used in something like a dpkg-deb wrapper that was used more broadly.  But I'm not sure, would need archaeology)
[11:09] <LocutusOfBorg> just to understand, we need to update chroots now, right?
[11:12] <xnox> doko:  i got a weird email from launchpad about urweb saying that it is rejected in groovy-proposed because binaries conflicting with the existing ones already exist or some such.
[11:12] <xnox> doko:  if it was you doing something with urweb, do check what's up. Maybe some other source package took over the binaries already?
[11:13] <xnox> doko:  or maybe it's a demotion race, and something needs to be copied again?
[11:13]  * xnox is not sure what was done.
[11:13] <xnox> do you want that email bounced to you?
[11:16] <cjwatson> LocutusOfBorg: I don't see why
[11:17] <cjwatson> LocutusOfBorg: pkgbinarymangler is installed as a package and we do a dist-upgrade at the start of the build
[11:17] <doko> xnox: I demoted that to proposed
[11:17] <doko> it was a fakesync, so importing the Debian version doesn't help
[11:22] <LocutusOfBorg> cjwatson, I found it out after asking :)
[11:22] <xnox> doko:  right, i'm not sure if demotion published in groovy-proposed or not.
[11:22] <xnox> doko:  because i got an email that it failed to publish into groovy-proposed. I guess something to double check in a couple of hours.
[11:32] <enyc> LocutusOfBorg: ooi do you know if  https://www.virtualbox.org/ticket/19496  got imported into the fixes of focal 20.04 virtualbox done just before release etc?
[11:33] -queuebot:#ubuntu-release- New binary: subversion [amd64] (groovy-proposed/universe) [1.14.0-1] (kubuntu)
[11:35] -queuebot:#ubuntu-release- New binary: subversion [s390x] (groovy-proposed/universe) [1.14.0-1] (kubuntu)
[11:38] -queuebot:#ubuntu-release- New binary: subversion [ppc64el] (groovy-proposed/universe) [1.14.0-1] (kubuntu)
[12:02] -queuebot:#ubuntu-release- New: accepted mandelbulber2 [amd64] (groovy-proposed) [2.20-2]
[12:02] -queuebot:#ubuntu-release- New: accepted mandelbulber2 [armhf] (groovy-proposed) [2.20-2]
[12:02] -queuebot:#ubuntu-release- New: accepted mandelbulber2 [riscv64] (groovy-proposed) [2.20-2]
[12:02] -queuebot:#ubuntu-release- New: accepted pocketsphinx-python [sync] (groovy-proposed) [1:0.1.15-2]
[12:02] -queuebot:#ubuntu-release- New: accepted mandelbulber2 [arm64] (groovy-proposed) [2.20-2]
[12:02] -queuebot:#ubuntu-release- New: accepted mandelbulber2 [s390x] (groovy-proposed) [2.20-2]
[12:02] -queuebot:#ubuntu-release- New: accepted mandelbulber2 [ppc64el] (groovy-proposed) [2.20-2]
[12:02] -queuebot:#ubuntu-release- New: accepted pocketsphinx [amd64] (groovy-proposed) [0.8.0+real5prealpha+1-11ubuntu1]
[12:02] -queuebot:#ubuntu-release- New: accepted pyqt5-sip [amd64] (groovy-proposed) [12.8.0-1]
[12:02] -queuebot:#ubuntu-release- New: accepted pyqt5-sip [armhf] (groovy-proposed) [12.8.0-1]
[12:02] -queuebot:#ubuntu-release- New: accepted pyqt5-sip [riscv64] (groovy-proposed) [12.8.0-1]
[12:02] -queuebot:#ubuntu-release- New: accepted pyqt5-sip [arm64] (groovy-proposed) [12.8.0-1]
[12:02] -queuebot:#ubuntu-release- New: accepted pyqt5-sip [s390x] (groovy-proposed) [12.8.0-1]
[12:02] -queuebot:#ubuntu-release- New: accepted pyqt5-sip [ppc64el] (groovy-proposed) [12.8.0-1]
[12:04] -queuebot:#ubuntu-release- New: accepted nomad-driver-lxc [amd64] (groovy-proposed) [0.1.0-1]
[12:04] -queuebot:#ubuntu-release- New: accepted nomad-driver-lxc [armhf] (groovy-proposed) [0.1.0-1]
[12:04] -queuebot:#ubuntu-release- New: accepted nomad-driver-lxc [s390x] (groovy-proposed) [0.1.0-1]
[12:04] -queuebot:#ubuntu-release- New: accepted nomad-driver-lxc [arm64] (groovy-proposed) [0.1.0-1]
[12:04] -queuebot:#ubuntu-release- New: accepted nomad-driver-lxc [ppc64el] (groovy-proposed) [0.1.0-1]
[12:06] -queuebot:#ubuntu-release- New: accepted cd-boot-images [source] (groovy-proposed) [1]
[12:08] <LocutusOfBorg> enyc, nope
[12:09] -queuebot:#ubuntu-release- New binary: cd-boot-images [amd64] (groovy-proposed/none) [1] (no packageset)
[12:09] -queuebot:#ubuntu-release- New binary: cd-boot-images [ppc64el] (groovy-proposed/none) [1] (no packageset)
[12:09] -queuebot:#ubuntu-release- New binary: cd-boot-images [arm64] (groovy-proposed/none) [1] (no packageset)
[12:10] -queuebot:#ubuntu-release- New: accepted cd-boot-images [amd64] (groovy-proposed) [1]
[12:10] -queuebot:#ubuntu-release- New: accepted cd-boot-images [ppc64el] (groovy-proposed) [1]
[12:10] -queuebot:#ubuntu-release- New: accepted cd-boot-images [arm64] (groovy-proposed) [1]
[12:16] -queuebot:#ubuntu-release- New binary: subversion [arm64] (groovy-proposed/universe) [1.14.0-1] (kubuntu)
[12:24] -queuebot:#ubuntu-release- New binary: subversion [armhf] (groovy-proposed/universe) [1.14.0-1] (kubuntu)
[12:30] <LocutusOfBorg> enyc, will do eventually :)
[14:08] -queuebot:#ubuntu-release- Unapproved: budgie-extras (focal-proposed/universe) [1.0.1-2 => 1.0.2-1] (personal-fossfreedom, ubuntu-budgie) (sync)
[14:21] -queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-440 [source] (bionic-proposed) [440.82-0ubuntu<IP_ADDRESS>]
[14:23] -queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-440 [source] (focal-proposed) [440.82.0-0ubuntu<IP_ADDRESS>]
[14:23] -queuebot:#ubuntu-release- New: rejected nvidia-graphics-drivers-418-server [source] (bionic-proposed) [418.126.02-0ubuntu<IP_ADDRESS>]
[14:23] -queuebot:#ubuntu-release- New: rejected nvidia-graphics-drivers-440-server [source] (bionic-proposed) [440.64.00-0ubuntu<IP_ADDRESS>]
[14:24] -queuebot:#ubuntu-release- New: rejected nvidia-graphics-drivers-418-server [source] (focal-proposed) [418.126.02-0ubuntu<IP_ADDRESS>]
[14:24] -queuebot:#ubuntu-release- New: rejected nvidia-graphics-drivers-440-server [source] (focal-proposed) [440.64.00-0ubuntu<IP_ADDRESS>]
[14:54] <juliank> Laney: are you rebasing britney? because the card is back in backlog, but I think you are?
[14:54] <juliank> https://trello.com/c/Fvi9ir6D/23-rebase-britney
[14:55] <Laney> juliank: yup
[14:55] <Laney> should be in progress
[14:55] <Laney> or started or whatever
[14:56] <Laney> about ready to try a test run actually :-o
[14:56] <Laney> just got to add force-reset-test back
[14:56] <juliank> Laney: nice
[14:58] <Laney> well then it'll probably explode in flames, but hey ho
[15:00] -queuebot:#ubuntu-release- Unapproved: accepted backport-iwlwifi-dkms [source] (focal-proposed) [8324-0ubuntu3~20.04.1]
[15:17] -queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (focal-proposed/multiverse) [6.1.6-1 => 6.1.8-1~ubuntu<IP_ADDRESS>] (no packageset)
[15:17] -queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (focal-proposed/multiverse) [6.1.6-dfsg-2ubuntu20.04.1 => 6.1.8-dfsg-2~ubuntu<IP_ADDRESS>] (no packageset)
[15:17] -queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (focal-proposed/multiverse) [6.1.6-1 => 6.1.8-1~ubuntu<IP_ADDRESS>] (no packageset)
[15:17] -queuebot:#ubuntu-release- Unapproved: virtualbox (focal-proposed/multiverse) [6.1.6-dfsg-1 => 6.1.8-dfsg-2~ubuntu<IP_ADDRESS>] (ubuntu-cloud)
[15:21] <LocutusOfBorg> sil2100, if you have spare time... ^^ thanks :D
[15:21] <LocutusOfBorg> (please wait for the groovy version to migrate first)
[15:32] -queuebot:#ubuntu-release- New: accepted subversion [amd64] (groovy-proposed) [1.14.0-1]
[15:32] -queuebot:#ubuntu-release- New: accepted subversion [armhf] (groovy-proposed) [1.14.0-1]
[15:32] -queuebot:#ubuntu-release- New: accepted subversion [s390x] (groovy-proposed) [1.14.0-1]
[15:32] -queuebot:#ubuntu-release- New: accepted subversion [arm64] (groovy-proposed) [1.14.0-1]
[15:32] -queuebot:#ubuntu-release- New: accepted subversion [ppc64el] (groovy-proposed) [1.14.0-1]
[16:09] <LocutusOfBorg> Hello, does anybody know why merge-o-matic page is not listing e.g. qemu
[16:09] <LocutusOfBorg> ?
[16:15] -queuebot:#ubuntu-release- New binary: subversion [riscv64] (groovy-proposed/universe) [1.14.0-1] (kubuntu)
[16:44] <xnox> sync-blacklist.txt:# stevenk, we don't want qemu from Debian, talk to kirkland
[16:44] <xnox> sync-blacklist.txt:qemu
[16:44] <xnox> LocutusOfBorg:  it's in sync-blacklist in https://wiki.ubuntu.com/ArchiveAdministration#Blacklisting / lp:~ubuntu-archive/+junk/sync-blacklist
[16:44] <xnox> LocutusOfBorg:  do not touch =)
[16:54] <LocutusOfBorg> xnox, I don't want to touch, I was just curious :)
[17:01] <Laney> hmm this commit is a bit complex, it interacts with the new neutral handling in interesting ways
[18:26] -queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.4.0-0ubuntu7.4 => 2:8.4.0-0ubuntu7.5] (openstack, ubuntu-server)
[19:10] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [19.4-33-gbb4131a2-0ubuntu1~16.04.1 => 20.2-45-g5f7825e2-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[19:32] -queuebot:#ubuntu-release- Unapproved: netplan.io (focal-proposed/main) [0.99-0ubuntu3~20.04.1 => 0.99-0ubuntu3~20.04.2] (core)
[19:38] -queuebot:#ubuntu-release- Unapproved: rejected netplan.io [source] (focal-proposed) [0.99-0ubuntu3~20.04.2]
[19:43] <blackboxsw> sil2100: if around today and available cloudinit has queued an sru for X B E and F releases per https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018
[19:43] -queuebot:#ubuntu-release- Unapproved: netplan.io (eoan-proposed/main) [0.99-0ubuntu3~19.10.1 => 0.99-0ubuntu3~19.10.2] (core)
[19:45] -queuebot:#ubuntu-release- Unapproved: rejected netplan.io [source] (eoan-proposed) [0.99-0ubuntu3~19.10.2]
[19:50] -queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (bionic-proposed) [0.99-0ubuntu3~18.04.3]
[19:51] -queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (eoan-proposed) [0.99-0ubuntu3~19.10.2]
[19:52] -queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (focal-proposed) [0.99-0ubuntu3~20.04.2]
[20:39] -queuebot:#ubuntu-release- Unapproved: gnome-shell (focal-proposed/main) [3.36.2-1ubuntu1~20.04.1 => 3.36.3-1ubuntu1~20.04.1] (desktop-extra, mozilla, ubuntu-desktop)
[22:34] -queuebot:#ubuntu-release- Unapproved: golang-1.14 (focal-proposed/main) [1.14.2-1ubuntu1 => 1.14.3-2ubuntu2~20.04.1] (no packageset)


 @wxl [<wxl> i mean arch is simple and lightweight......... but takes a fair amount of …], You can always get manjaro for a quick start. :)
[07:13] <ericjmorey_> I'm considering an upgrade to 19.10. Currently using 18.04 LTS. I've heard that LXQt has been significantly improved.
[07:17] <guiverc> ericjmorey_, fyi:  18.04 LTS to 18.10+ (LXDE -> LXQt) upgrades are not supported, "The most major and notable problem is that upgrading Lubuntu from 18.04 to 18.10 causes a fair amount of issues. Therefore, we are not officially supporting this upgrade path at this time, however we have prepared a page in the Lubuntu Manual which can help address the problems that arise after the upgrade." https://lubuntu.me/cosmic-released/    (they are
[07:17] <guiverc> possible yes; but problems can arise) .. I really like LXQt myself
[07:24] <ericjmorey_> I'm considering a clean install as part of my "get your act together and make proper backups" campaign
[07:24] <guiverc> :)
[07:26] <ericjmorey_> it's been a while. is Rufus still recommened for creating a bootable live USB?
[07:27] <guiverc> I've only ever written an ISO from GNU/Linux so have never used Rufus - this page of Manual has info on writing ISOs - https://manual.lubuntu.me/stable/1/1.2/booting_the_image.html  (writing/burning the image section)
[07:29] <guiverc> (it has info on writing for windows, mac & of course GNU/Linux)
[07:38] <ericjmorey_> cool. I'll probably use that.
 @ericjmorey_ [<ericjmorey_> it's been a while. is Rufus still recommened for creating a bootab …], Yup! Rufus works like magic. Aisi creates persistent USBs if you need.
 what's the network manager on lubuntu
 how to make it appear on the foreground
 i lost it on the try
 *tray
[10:32] <guiverc> @ctisme  it's `nm-tray` on my Lubuntu (20.04) but it's part of 'Status tray'  -- https://manual.lubuntu.me/stable/3/3.1/3.1.5/nm-tray.html
[10:33] <guiverc> (refer bottom of page for info that hopefully is helpful, my read of it implies a logout/login should restore it)
 @guiverc [<guiverc> (refer bottom of page for info that hopefully is helpful, my read of i …], noted
[13:08] <billd1973> good  morning all. lubuntu 18.04 fresh install asus 1001P all is well except keyboard and other minor function issues
[13:10] <billd1973> no left ctrl no backspace no hyphen/underscore missing about half of my F# keys particularly F1 F3 F5 F7 F11 F12.  hard to edit anything.
[13:11] <billd1973> have been trying to flash bios but for some reason its not recognizing the usb stick when I enter the flash utility (ALT+F2)  If I plug in a full size keyboard everything on it works
[13:15] <billd1973> added GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi=Linux" and ran sudo update-grub but it made no difference on the local keyboards functionality
[13:20] <billd1973> does the usb stick with the update ROM need to be "bootable" to be recognized by the bios?
 @billd1973 [<billd1973> good  morning all. lubuntu 18.04 fresh install asus 1001P all is wel …], Check keyboard layout in settings.


[10:39] <Laney> dear BTS, please give bug numbers faster
[10:41] <Unit193> 3
[11:24] <cpaelzer> sil2100: (for +1 maint) xnox (for boost in general): is one of you on src:mrs which is a FTFBS blocking boost1.71 (and thereby ICU as well)
[11:24] <cpaelzer> seems it was ignroed and removed in debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957567
[11:25] <cpaelzer> I was wondering if anyone looks already into that - and if not what you'd think for Ubuntu (removal as well, or trying to fix) would be the better approach
[11:25] <cpaelzer> I can give it some time to fix FTFBS and if it seems to complex file a removal  (as part of +1 duty), but wanted to avoid that this is already being worked on
[11:36] <cpaelzer> different question - I know if we have a source in Ubuntu the only way to prevent auto-sync from Debian is giving it a ubuntuX suffix. But if we don't have the src:package is there a way somewhere to block a given package from syncing?
[11:36] <cpaelzer> I'd want to check for a particular package if it is blocked there as well (and hopefully find a comment about the reasons)
[11:41] <cjwatson> cpaelzer: Are you thinking of https://code.launchpad.net/~ubuntu-archive/+junk/sync-blacklist ?
[11:41] <cpaelzer> sounds about right cjwatson - thanks
[11:41] <cpaelzer> I'll take a look there
[11:44] <cpaelzer> thanks that was it
[11:44] <cpaelzer> I knew such a thing existed, I even see changes in there by me - but I forgot the right paths to look at
[13:11] <xnox> cpaelzer:  what do you mean "blocking boost1.71"?
[13:12] <xnox> cpaelzer:  there is no boost transitions in progress.
[13:12] <seb128> xnox, https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#boost1.71 ?
[13:13] <slyon> Hey core-devs! Could somebody please review/sponsor my fix for bug #1889138 (debdiff attached) – so I can move forward with getting sbuild/dpkg migrated from -proposed?
[13:13] <xnox> seb128:  but that's not a transition, it is simply part of icu transition.
[13:13] <seb128> xnox, sorry I don't have the start of the discussion, but that's boost in proposed blocked by some items
[13:14] <seb128> so 'blocking' seems to apply
[13:15] <xnox> ok
[13:15] <juliank> Laney: I guess we can't teach britney to always add a grub2-signed trigger when it has a grub2 trigger (and vice versa)
[13:17] <seb128> xnox, reading irclog nobody said 'transition', I think saying boost is blocked in proposed due to mrs (and dart) was factual?
[13:25] <cpaelzer> xnox: yes what seb128 referenced is what I meant
[13:25] <cpaelzer> not a boost transition itself
[13:27] <cpaelzer> xnox: and the bug - as written in the description - is intentionally not (yet) an RM bug
[13:27] <cpaelzer> giving it a chance to be fixed and only then it becomes an RM
[13:34] <xnox> ok
[13:36] <xnox> cpaelzer:  i have separate questions about libvirt/virsh. I'm trying to write a restart tool. And when doing `systemctl restart libvirtd.service` it only restarts the main daemon, not any other processes it spawned due to KillMode=process"
[13:36] <xnox> cpaelzer:  so i'm working, is it safe to kill/restart the dnsmasq agents that are running under virsh? is there something like virsh net-restart command?
[13:36] <xnox> not working => so i'm wondering
[13:36] <xnox> or if restarting dnsmasq is not safe.
[13:37] <cpaelzer> xnox: no net-restart
[13:37] <cpaelzer> xnox: not that I know of
[13:37] <cpaelzer> xnox: you'd need to destroy + start
[13:38] <cpaelzer> xnox: if that is safe depends on the complexity of the network that you defined
[13:40] <cpaelzer> most of the time it is not safe (with guests up=
[13:41] <cpaelzer> xnox: the default net for example includes the definition of virbr0 - if you remove/start that guests likely will have connection issues
[13:41] <cpaelzer> xnox: but other configurations e.g. for existing bridges might have no issue at all
[13:43] <cpaelzer> xnox: this was discussed upstream a while ago btw https://bugzilla.redhat.com/show_bug.cgi?id=1597326
[13:43] <Laney> juliank: feels possible, would be best if we can do it in an upstreamable way
[13:44] <cpaelzer> xnox: how about "virsh net-update" - does that give you waht you need
[13:45] <cpaelzer> xnox: https://wiki.libvirt.org/page/Networking#Applying_modifications_to_the_network
[13:59] <xnox> cpaelzer:  it would, if it allowd "empty" updates. It tries to force me to actual make a change.
[13:59] <xnox> i.e. sudo virsh net-update --help
[14:00] <xnox> sudo virsh net-update --network vlan --command modify --xml '' --section ''
[14:00] <xnox> is not ok, because section & xml cannot be empty
[14:00] <xnox> =(
[14:02] <xnox> i kind of want to "just reexec dnsmasq" please
[14:08] <ahasenack> hi vorlon, about my question from friday about the corner case of user removing /etc/default/motd-news before upgrading to the new packages (which would reinstall that config file), did you get a change to think about it?
[14:10] <ahasenack> https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/388835/comments/1022886
[14:11] <ahasenack> apologies if you did and my  irc proxy bot was offline
[17:05] <realtime-neil> Does launchpad support the kind of pipeline that will host source, build source, and publish the resulting debian package(s)? If so, where can I learn more about this?
[17:06] <tumbleweed> realtime-neil: https://help.launchpad.net/Packaging/SourceBuilds
[17:08] <realtime-neil> tumbleweed: much thanks
[17:19] <rbasak> Anyone else with an XPS 9360 getting wifi lockups after suspend/resume, requiring reboot? I found a newer firmware than in linux-firmware. Trying that now.
[17:44] <realtime-neil> tumbleweed: is there a way to get launchpad to build things git-hosted elsewhere?
[17:44] <ahasenack> for recipes, the git repo needs to reside in lp afaik
[17:44] <ahasenack> you can setup a mirror, though
[17:45] <realtime-neil> ahasenack: how do I set up a mirror?
[17:45] <ahasenack> you have to create a project, then in the "code" tab you can setup a mirror I believe
[17:46] <realtime-neil> I tried to mirror https://github.com/torvalds/linux.git and got "This foreign branch URL is already specified for the imported repository ~lopin/linux/+git/linux."
[17:47] <ahasenack> are you lopin?
[17:47] <realtime-neil> I am not
[17:47] <ahasenack> then I don't know, sorry
[17:47] <realtime-neil> okay, thanks anyway
[17:49] <tumbleweed> looks like that import is timing out
[17:49] <tumbleweed> You can talk to the launchpad people about that, but I'm guessing the repo is simply too big
[17:53] <cjwatson> Kernel packaging tends to be rather too complicated to work well with fully-automated recipes anyway.
[18:13] <ricotz> rbalint, hi, is systemd 246-2ubuntu1 in groovy-proposed going to transition as it is?
[18:15] <ricotz> I upgraded to it last week and my system nearly dead-locked due to some high cpu usage in the upgrade itself and on the following restart, which rendered the system unusable
[18:16] <ricotz> downgraded to 245.7-1ubuntu1 again
[18:49] <ottok> Hi! I am a Debian developer trying to learn how to backport packages in Ubuntu. I followed docs and filed https://bugs.launchpad.net/bionic-backports/+bug/1873597 a month ago but there was no response. What shall I do next?
[18:53] <rbasak> ottok: unfortunately the backports process is mostly dead and there's no longer an active backports review team. Some background here: https://lists.ubuntu.com/archives/ubuntu-devel/2019-January/040575.html
[18:53] <rbasak> And continuation here
[18:53] <rbasak> https://lists.ubuntu.com/archives/ubuntu-devel/2019-February/040587.html
[18:55] <rbasak> I am in favour of its resurrection, FWIW. But it needs a committed team to drive process and resume reviews I think.
[18:55] <rbasak> teward: FYI ^
[18:59] <ottok> Thanks, skimmed through those emails, but it left it hanging in the air on what should be done now. Shall I send email to ubuntu-backports@ or just give up?
[18:59] <sarnold> rbasak: is there a way to give ottok backports priviliges "soon"? ie at the next dmb meeting or something? this is the most effort / activity I've seen put towards backports in ages, and ottok's surely demonstrated an ability and commitment
[19:00] <rbasak> sarnold: I'm in favour but it's not up to the DMB currently - the DMB isn't delegated management of the backports team currently
[19:00] <sarnold> rbasak: oh :( :( :(
[19:01] <rbasak> But separately, IMHO we need a reviewer for ottok's work as well as ottok himself contributing the upload
[19:01] <sil2100> !dmb-ping
[19:02] <rbasak> I think requiring backports _reviewers_ to be core dev or MOTU is probably appropriate
[19:03] <rbasak> And we need volunteers for that
[19:03] <rbasak> teward was such a volunteer in the past, but I'm not sure that he's still available
[19:03] <rbasak> Unfortunately review work is generally tedious and thankless, so few people volunteer
[19:05] <rbasak> ottok: maybe reply to the ubuntu-devel@ thread pointing out that you are volunteering a backport but have no reviewer? I think that'd be the most useful place to direct an email.
[19:05] <sarnold> rbasak: yeah, reviewers would definitely be nice -- and full ack on it being all work no play
[19:51] <teward> rbasak: sarnold: Laney and I Had also written up restrictions that it needs someone dedicated to maintain the backport
[19:51] <teward> sort of how you need a DM or be a Sponsored Maintainer in debian to upload for a given package
[19:51] <sarnold> teward: I can appreciate the sentiment but that's more than universe packages get now ..
[19:51] <teward> but chaos happened with COVID and everything so I haven't pursuded it much
[19:51] <teward> sarnold: well 'exceptions' exist :P
[19:52] <teward> but the problem with backports is "anyone can request"
[19:52] <sarnold> hah, yes, but no one actually bothers doing them -- until today, anyway ;)
[19:52] <teward> if we restrict that to devs are teh only ones who can file the request that solves that, the problem is backports is overwlelmed with crap
[19:52] <teward> and things that aren't good candidates, aren't tested, etc.
[19:53] <teward> but i'm currently recovering in the hospital
[19:53] <teward> so E:NOACTION from me for a few days
[19:53] <teward> appendicitis ia a pain
[19:53] <teward> but we caught it early now I'm just needing to relax and recover for a couple days
[19:54] <teward> sarnold: what's on the radar about the backport?
[19:54] <teward> s/about the/for/
[19:54] <teward> in this case
[19:55] <sarnold> teward: oh ugh :/ I hope you're back home soon :)
[19:56] <teward> sarnold: also backports requires coredev/MOTU I THINK to upload to -backports directly without sponsoring
[19:56] <sarnold> teward: in this case, ottok's trying to get this going https://bugs.launchpad.net/bionic-backports/+bug/1873597
[19:56] <teward> I can upload to -backports for example
[19:56] <teward> for Universe or Main or {ANY} because coredev
[19:56] <teward> but it needs approved/released regardless
[19:56] <teward> C D and E are dead righgt?
[19:57] <teward> C D E series*
[20:00] <teward> ottok: yeah, so
[20:00] <teward> backports process in terms of review is heavily stalled
[20:00] <teward> if not dead
[20:00] <teward> Laney's the only one who does backport reviews and has wanted things backported only that make sense
[20:00] <teward> what's your justification for needing it backported?  (just curious)
[20:01] <teward> rbasak: what's the status of mariadb in Xenial
[20:01] <teward> or is it nonexistent?
[20:01] <teward> they say in their backport bug that: Ubuntu Bionic has currently only galera-3 available. The new version galera-4 is required to run MariaDB 10.4 or newer.
[20:02] <teward> and unless people are using MariaDB 10.4+ on Xenial i'm *real* hesitant to do the second part of the backport which is a Xenial request
[20:03] <rbasak> teward: I would need to look. ottok will be more familiar with all that
[20:03] <teward> ok
[20:03] <teward> ottok: ^ same questions
[20:03] <teward> i assume they went AFK/AWOL
[20:03] <teward> rbasak: maraiadb 10.0 is in Xenial
[20:11] <teward> so the jump from 10.0 to 10.4 i'm not entirely sure why is needed/substantial
[20:12] <teward> if it's "just so we can use newer MariaDB" i'm... not entirely willing to review/sponsor for Xenial.
[20:34] <ottok> I noticed that there is also a user request to backport a package I maintain in Debian and already maintain backport in PPA: https://bugs.launchpad.net/bionic-backports/+bug/1876599
[20:34] <ottok> I promise to make the review very easy, since the backports are all no-changes backports and live along identical ones in Debian backports.
[20:35] <ottok> And I have a track record of maintaining my packages in both Debian and Ubuntu (unless an idividual package/pocket had some special case going on)
[20:37] <sarnold> teward: ^^
[20:43] <ottok> teward: I replied to your "review questions" on Launchpad in context.
[20:43] <ottok> teward: https://bugs.launchpad.net/bionic-backports/+bug/1873597
[21:30] <teward> ottok: i assume galera-3 and galera-4 are coinstallable then?
[21:30] <teward> or do they conflict?
[21:33] <teward> ottok: also: > Using the Ubuntu backported Galera 4 package would assure a good quality of packaging instead of using any alternative option,
[21:33] <teward> if and only if you also backport mariadb 10.4+ into the repos as well
[21:34] <teward> because mariadb isn't backported - so unless someone picks up MariaDB 10.4+ and backports it, adding the dependent library doesn't really seem like a necessary/useful step, *especially* since backports it not default-installable unless you specify it during apt calls or are installing things from -backports
[21:37] <teward> because any 'third party repository', PPA Upstream or Otherwise, would require (1) backports to be enabled, and (2) still be third party so vetting the mariadb code is still 'hard' (as sarnold and others on the sec team can admit to from experience)
[21:37] <teward> ottok: do you or someone else have the intent to also backport MariaDB 10.4+ into Bionic Backports as well?
[21:42] <teward> (posted to the bug as followup as well as my REJECT review for Xenial - xenial dies in the next year and MOST people are probably upgraded except for legacy applications, and I don't have any viable tests of whether MariaDB newer can actually *run* on Xenial so I have no basis for accept.
[21:43] <teward> Laney: if I get up off my lazy butt and backport NGINX, would you be willing to back me up on that backport to Bionic of the stable in focal-updates?
[23:08] <realtime-neil> How do I tell my launchpad recipe to checkout a git tag and not a git branch?
[23:11] <cjwatson> realtime-neil: What does your recipe look like at the moment?
[23:11] <realtime-neil> ```
[23:12] <realtime-neil> # git-build-recipe format 0.4 deb-version {debupstream}-0~{revtime}
[23:12] <realtime-neil> lp:test9001 v4.16
[23:12] <cjwatson> That ought to work, except that the lp:test9001 code import failed
[23:12] <cjwatson> And https://launchpadlibrarian.net/492765364/realtime-neil-test9001-+git-linux.log is somewhat unclear
[23:13] <cjwatson> Miiiiiight be helped by https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/373732 but I'm really not sure
[23:14] <realtime-neil> cjwatson: I feel like you're suggesting something but I'm too ignorant to understand.
[23:15] <cjwatson> I'm suggesting that this is broken right now
[23:15] <cjwatson> And it's not completely clear how to fix it
[23:15] <cjwatson> Your recipe syntax is correct in and of itself, but that doesn't help when https://code.launchpad.net/~realtime-robotics/test9001/+git/linux contains no branches
[23:16] <cjwatson> (or tags)
[23:17] <realtime-neil> cjwatson: if I have a fresh source repository that might still be syncing from an upstream source, would that explain the lack of branches and tags?
[23:17] <cjwatson> What fresh source repository exactly are you talking about?
[23:18] <cjwatson> (URL)
[23:18] <realtime-neil> cjwatson: I have a fork of github.com/torvalds/linux here: https://gitlab.com/realtime-robotics/linux
[23:19] <cjwatson> Whether that gitlab repository is still syncing from upstream is immaterial
[23:19] <cjwatson> This is a bug in Launchpad code imports that affects a small number of very large repositories
[23:19] <cjwatson> Probably the same as the tail-end of https://bugs.launchpad.net/launchpad/+bug/1642699
[23:20] <cjwatson> Need to get one of my colleagues to review my merge proposal above so we can see if it helps
[23:20] <realtime-neil> ah, okay; you're theorizing that, since this repository is so big, I might be hitting the bug you mentioned
[23:20] <cjwatson> It may not be precisely the same thing, but it's something along those sorts of lines
[23:21] <cjwatson> You can see the code import failure in the log above
[23:25] <cjwatson> The problem is that it spends five minutes without producing any output at all, which causes the code import monitor to assume it's got stuck and kill it
[23:25] <cjwatson> (I think it's five minutes anyway)
[23:26] <realtime-neil> cjwatson: okay, understood; how would you suggest I proceed? Smaller repository? Maybe try this with just a shallow copy of what I care about most?
[23:27] <cjwatson> The purpose of my branch above is to crank up the progress output so that we get some kind of output every so often to pacify the watchdog, but to throttle it so it doesn't produce an absurd amount of noise in the log
[23:28] <cjwatson> You could try a smaller repository, or you could try pushing it manually to Launchpad rather than using a code import
[23:28] <realtime-neil> lemme try the latter
[23:28] <cjwatson> "Smaller" may possibly be mainly "fewer refs"