[00:00] -queuebot:#ubuntu-release- New binary: ots [riscv64] (hirsute-proposed/universe) [0.5.0-6] (no packageset)
[05:27] -queuebot:#ubuntu-release- New binary: crashtest [amd64] (hirsute-proposed/none) [0.3.1-1] (no packageset)
[05:27] -queuebot:#ubuntu-release- New binary: graftcp [amd64] (hirsute-proposed/none) [0.3.1+ds1-1] (no packageset)
[05:28] -queuebot:#ubuntu-release- New binary: plotsauce [amd64] (hirsute-proposed/none) [0~0.1-1] (no packageset)
[05:28] -queuebot:#ubuntu-release- New binary: python-limits [amd64] (hirsute-proposed/none) [1.5.1-1] (no packageset)
[05:28] -queuebot:#ubuntu-release- New binary: libcomps [amd64] (hirsute-proposed/none) [0.1.15-4] (no packageset)
[05:28] -queuebot:#ubuntu-release- New binary: pyfuse3 [amd64] (hirsute-proposed/none) [3.2.0-1] (no packageset)
[05:29] -queuebot:#ubuntu-release- New binary: sphinx-prompt [amd64] (hirsute-proposed/none) [1.3.0-2] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: qbrz [amd64] (hirsute-proposed/universe) [0.23.2+bzr1633-1] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: libcomps [arm64] (hirsute-proposed/universe) [0.1.15-4] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: r-cran-sass [amd64] (hirsute-proposed/universe) [0.3.1+dfsg-1] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: libcomps [armhf] (hirsute-proposed/universe) [0.1.15-4] (no packageset)
[05:32] -queuebot:#ubuntu-release- New binary: libcomps [s390x] (hirsute-proposed/universe) [0.1.15-4] (no packageset)
[05:33] -queuebot:#ubuntu-release- New binary: plotsauce [armhf] (hirsute-proposed/universe) [0~0.1-1] (no packageset)
[05:33] -queuebot:#ubuntu-release- New binary: plotsauce [arm64] (hirsute-proposed/universe) [0~0.1-1] (no packageset)
[05:33] -queuebot:#ubuntu-release- New binary: pyfuse3 [s390x] (hirsute-proposed/universe) [3.2.0-1] (no packageset)
[05:33] -queuebot:#ubuntu-release- New binary: plotsauce [s390x] (hirsute-proposed/universe) [0~0.1-1] (no packageset)
[05:35] -queuebot:#ubuntu-release- New binary: r-cran-sass [s390x] (hirsute-proposed/universe) [0.3.1+dfsg-1] (no packageset)
[05:35] -queuebot:#ubuntu-release- New binary: pyfuse3 [arm64] (hirsute-proposed/universe) [3.2.0-1] (no packageset)
[05:39] -queuebot:#ubuntu-release- New binary: libcomps [ppc64el] (hirsute-proposed/universe) [0.1.15-4] (no packageset)
[05:39] -queuebot:#ubuntu-release- New binary: plotsauce [riscv64] (hirsute-proposed/universe) [0~0.1-1] (no packageset)
[05:40] -queuebot:#ubuntu-release- New binary: plotsauce [ppc64el] (hirsute-proposed/universe) [0~0.1-1] (no packageset)
[05:42] -queuebot:#ubuntu-release- New binary: r-cran-sass [armhf] (hirsute-proposed/universe) [0.3.1+dfsg-1] (no packageset)
[05:42] -queuebot:#ubuntu-release- New binary: pyfuse3 [ppc64el] (hirsute-proposed/universe) [3.2.0-1] (no packageset)
[05:42] -queuebot:#ubuntu-release- New binary: r-cran-sass [arm64] (hirsute-proposed/universe) [0.3.1+dfsg-1] (no packageset)
[05:44] -queuebot:#ubuntu-release- New binary: r-cran-sass [ppc64el] (hirsute-proposed/universe) [0.3.1+dfsg-1] (no packageset)
[05:45] -queuebot:#ubuntu-release- New binary: libcomps [riscv64] (hirsute-proposed/universe) [0.1.15-4] (no packageset)
[05:55] -queuebot:#ubuntu-release- New binary: pyfuse3 [riscv64] (hirsute-proposed/universe) [3.2.0-1] (no packageset)
[06:18] -queuebot:#ubuntu-release- New binary: r-cran-sass [riscv64] (hirsute-proposed/universe) [0.3.1+dfsg-1] (no packageset)
[07:45] -queuebot:#ubuntu-release- New: accepted libcomps [amd64] (hirsute-proposed) [0.1.15-4]
[07:45] -queuebot:#ubuntu-release- New: accepted libcomps [armhf] (hirsute-proposed) [0.1.15-4]
[07:45] -queuebot:#ubuntu-release- New: accepted libcomps [riscv64] (hirsute-proposed) [0.1.15-4]
[07:45] -queuebot:#ubuntu-release- New: accepted libcomps [arm64] (hirsute-proposed) [0.1.15-4]
[07:45] -queuebot:#ubuntu-release- New: accepted libcomps [s390x] (hirsute-proposed) [0.1.15-4]
[07:45] -queuebot:#ubuntu-release- New: accepted libcomps [ppc64el] (hirsute-proposed) [0.1.15-4]
[07:46] -queuebot:#ubuntu-release- New: accepted pyfuse3 [amd64] (hirsute-proposed) [3.2.0-1]
[07:46] -queuebot:#ubuntu-release- New: accepted pyfuse3 [ppc64el] (hirsute-proposed) [3.2.0-1]
[07:46] -queuebot:#ubuntu-release- New: accepted pyfuse3 [s390x] (hirsute-proposed) [3.2.0-1]
[07:46] -queuebot:#ubuntu-release- New: accepted pyfuse3 [arm64] (hirsute-proposed) [3.2.0-1]
[07:46] -queuebot:#ubuntu-release- New: accepted pyfuse3 [riscv64] (hirsute-proposed) [3.2.0-1]
[07:47] -queuebot:#ubuntu-release- New: accepted crashtest [amd64] (hirsute-proposed) [0.3.1-1]
[07:47] -queuebot:#ubuntu-release- New: accepted python-limits [amd64] (hirsute-proposed) [1.5.1-1]
[07:47] -queuebot:#ubuntu-release- New: accepted r-cran-sass [amd64] (hirsute-proposed) [0.3.1+dfsg-1]
[07:47] -queuebot:#ubuntu-release- New: accepted r-cran-sass [armhf] (hirsute-proposed) [0.3.1+dfsg-1]
[07:47] -queuebot:#ubuntu-release- New: accepted r-cran-sass [riscv64] (hirsute-proposed) [0.3.1+dfsg-1]
[07:47] -queuebot:#ubuntu-release- New: accepted sphinx-prompt [amd64] (hirsute-proposed) [1.3.0-2]
[07:47] -queuebot:#ubuntu-release- New: accepted graftcp [amd64] (hirsute-proposed) [0.3.1+ds1-1]
[07:47] -queuebot:#ubuntu-release- New: accepted r-cran-sass [arm64] (hirsute-proposed) [0.3.1+dfsg-1]
[07:47] -queuebot:#ubuntu-release- New: accepted r-cran-sass [s390x] (hirsute-proposed) [0.3.1+dfsg-1]
[07:47] -queuebot:#ubuntu-release- New: accepted qbrz [amd64] (hirsute-proposed) [0.23.2+bzr1633-1]
[07:47] -queuebot:#ubuntu-release- New: accepted r-cran-sass [ppc64el] (hirsute-proposed) [0.3.1+dfsg-1]
[07:47] -queuebot:#ubuntu-release- New: accepted ots [amd64] (hirsute-proposed) [0.5.0-6]
[07:47] -queuebot:#ubuntu-release- New: accepted ots [armhf] (hirsute-proposed) [0.5.0-6]
[07:47] -queuebot:#ubuntu-release- New: accepted ots [riscv64] (hirsute-proposed) [0.5.0-6]
[07:47] -queuebot:#ubuntu-release- New: accepted plotsauce [amd64] (hirsute-proposed) [0~0.1-1]
[07:47] -queuebot:#ubuntu-release- New: accepted plotsauce [armhf] (hirsute-proposed) [0~0.1-1]
[07:47] -queuebot:#ubuntu-release- New: accepted plotsauce [riscv64] (hirsute-proposed) [0~0.1-1]
[07:47] -queuebot:#ubuntu-release- New: accepted ots [arm64] (hirsute-proposed) [0.5.0-6]
[07:47] -queuebot:#ubuntu-release- New: accepted ots [s390x] (hirsute-proposed) [0.5.0-6]
[07:47] -queuebot:#ubuntu-release- New: accepted plotsauce [ppc64el] (hirsute-proposed) [0~0.1-1]
[07:47] -queuebot:#ubuntu-release- New: accepted ots [ppc64el] (hirsute-proposed) [0.5.0-6]
[07:47] -queuebot:#ubuntu-release- New: accepted plotsauce [s390x] (hirsute-proposed) [0~0.1-1]
[07:47] -queuebot:#ubuntu-release- New: accepted plotsauce [arm64] (hirsute-proposed) [0~0.1-1]
[07:48] -queuebot:#ubuntu-release- New: accepted libdap [amd64] (hirsute-proposed) [3.20.7-3]
[07:48] -queuebot:#ubuntu-release- New: accepted libdap [armhf] (hirsute-proposed) [3.20.7-3]
[07:48] -queuebot:#ubuntu-release- New: accepted libdap [riscv64] (hirsute-proposed) [3.20.7-3]
[07:48] -queuebot:#ubuntu-release- New: accepted libdap [arm64] (hirsute-proposed) [3.20.7-3]
[07:48] -queuebot:#ubuntu-release- New: accepted libdap [s390x] (hirsute-proposed) [3.20.7-3]
[07:48] -queuebot:#ubuntu-release- New: accepted libdap [ppc64el] (hirsute-proposed) [3.20.7-3]
[08:51] -queuebot:#ubuntu-release- Packageset: Removed discount from i386-whitelist in hirsute
[08:51] -queuebot:#ubuntu-release- Packageset: Removed libproc-processtable-perl from i386-whitelist in hirsute
[08:51] -queuebot:#ubuntu-release- Packageset: Removed libtext-markdown-discount-perl from i386-whitelist in hirsute
[08:51] -queuebot:#ubuntu-release- Packageset: Added llvm-toolchain-12 to i386-whitelist in hirsute
[09:09] <sil2100> handsome_feng: hey! I saw LP: #1914367 reported in kylin for .2 - it feels rather serious, is it something that happens on every install?
[10:07] -queuebot:#ubuntu-release- New: accepted linux-signed-oem-5.6 [amd64] (focal-proposed) [5.6.0-1046.50]
[10:08] <paride> xnox, hi! did you try to reproduce  https://bugs.launchpad.net/subiquity/+bug/1914285 ?
[10:08] <paride> I need a sanity check :)
[10:19] -queuebot:#ubuntu-release- Unapproved: python-oslo.messaging (bionic-proposed/main) [5.35.0-0ubuntu2 => 5.35.0-0ubuntu3] (openstack, ubuntu-server)
[10:20] <paride> now that the HWE kernel is included in the subiquity images we need to bump the max image size
[10:20] <paride> here: https://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/lib/cdimage/tree.py#L1878
[10:21] <paride> but this ^^ is buggy because "xenial" >= "bionic", but Ubuntu Xenial < Bionic
[10:22] <rbasak> HWE kernel is included in the subiquity images> that's new!
[10:22] <cjwatson> paride: No, config["DIST"] is a magic object
[10:22] <rbasak> Is that documented anywhere please?
[10:23] <cjwatson> paride: See cdimage.config.Series
[10:23] <paride> cjwatson, interesting, looking. thanks for the pointer!
[10:27] <paride> rbasak, we definitely need to mention it in the release notes. It isn't at the moment.
[10:27] <paride> rbasak, the default kernel is still the non-HWE one
[10:34] <rbasak> Ah, so booting the HWE kernel is an option now?
[10:38] <paride> rbasak, yes
[10:41] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-203.235]
[10:46] <paride> cjwatson, https://code.launchpad.net/~paride/ubuntu-cdimage/ubuntu-cdimage/+merge/397422
[10:50] <cjwatson> Yep, looks plausible to me but I'm not really doing cdimage stuff any more so probably better if somebody more active reviews it
[10:51] <sil2100> Looking
[10:51] <paride> bzr log points at sil2100
[10:51] <paride> there :)
[10:53] <sil2100> paride: hm, ok, I think it makes sense - of course we only have the HWE kernels for focal, not in groovy or hirsute, so it's not really >= focal - but that being said, I think a size bump of this magnitude is okay anyway
[10:53] <sil2100> Let me merge this
[10:54] <sil2100> paride: as for the subiquity reboot bug - how frequently does that happen? You think it's a blocker?
[10:54] <sil2100> I'll add it to bugs to watch for now
[10:59] <paride> sil2100, I couldn't reproduce it in a fully manual install, but I am a bit worried about it. Past week the bug was not there, then we had the problem with the image building scripts caused by the removal of the legacy image stuff, and that you fixed
[10:59] <paride> I don't think that's related, but the issue caused a hole of a few days in the automated testing
[10:59] <paride> then this monday I started seeing the intermittent failures the bug I filed is about
[11:00] <paride> I struggled to reproduce it locally, but in the end I managed to, so it's not something strictly related to the test harness
[11:01] <paride> let me see if I can eliminate another variable
[11:01]  * paride does a few more installs
[11:03] <paride> rbasak, and of course if you boot the installed with the hwe kernel then the installed system uses linux-generic-hwe-20.04 as its kernel
[11:04] <rbasak> That sounds really useful.
[11:04] <paride> so the hwe kernel has been added to both /casper (for the installer) and /pool, with all its .debs
[11:04] <rbasak> We should document that as a headline feature!
[11:09] <paride> sil2100, should the .OVERSIZED files be manually removed from https://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/pending/ now?
[11:09] <paride> they cause a big warning in the iso tracker
[11:14] <sil2100> paride: yeah, +1 on that
[12:09] <xnox> sil2100:  issue with riscv64 image......
[12:10] <xnox> sil2100:  on http://iso.qa.ubuntu.com/qatracker/milestones/420/builds/226356/testcases I cannot report that Unleashed & Qemu pass without bugs =)
[12:10] <xnox> sil2100:  cause qemu & unleashed board test cases are not there.
[12:24] <sil2100> We have no test cases!
[12:24] <sil2100> :)
[12:25] <sil2100> xnox: should I add some generic ones? Or do we actually ahve some riscv test cases present?
[12:25] <sil2100> xnox: anyway, it's still good to hear that the issue here is that there is no issue ;)
[12:28] <xnox> sil2100:  well it needs qemu boot; unleashed board boot => at least. not sure if there are any generic ones to use, given it is preinstalled image.
[12:29] <xnox> let me check what we have for pi
[12:30] <xnox> sil2100:  ubuntu-base riscv64 product is missing too
[12:31] <sil2100> Oh, ok, that one I forgot completely
[12:31] <sil2100> Let me add it
[12:33] <Laney> It'll need to be in etc/qa-products too if it's not already
[12:33] <Laney> looks like it is!
[12:40] -queuebot:#ubuntu-release- Builds: Ubuntu Base riscv64 [Focal 20.04.2] (20210201.1) has been added
[12:41] <sil2100> Ok, all added o/
[13:13] -queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [s390x] (hirsute-proposed/universe) [1:13~++20210129063721+010b176cdefb-1~exp1] (no packageset)
[13:25] -queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1051.53] (kernel)
[13:31] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [s390x] (hirsute-proposed) [1:13~++20210129063721+010b176cdefb-1~exp1]
[13:44] <sil2100> Ok, bad news, certification reported a blanket issue with one of the hardware: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1914374
[13:46] <sil2100> hm, guess we need a bit more info about that one
[13:46] <sil2100> jibel, Laney: JFYI ^
[13:49] -queuebot:#ubuntu-release- New binary: libvirt [s390x] (hirsute-proposed/main) [7.0.0-1ubuntu1] (ubuntu-server, virt)
[13:51] -queuebot:#ubuntu-release- New binary: libvirt [amd64] (hirsute-proposed/main) [7.0.0-1ubuntu1] (ubuntu-server, virt)
[13:52] -queuebot:#ubuntu-release- New binary: libvirt [ppc64el] (hirsute-proposed/main) [7.0.0-1ubuntu1] (ubuntu-server, virt)
[14:07] -queuebot:#ubuntu-release- New binary: libvirt [arm64] (hirsute-proposed/main) [7.0.0-1ubuntu1] (ubuntu-server, virt)
[14:07] -queuebot:#ubuntu-release- New binary: libvirt [armhf] (hirsute-proposed/main) [7.0.0-1ubuntu1] (ubuntu-server, virt)
[14:10] <Laney> come now, people need to use the proper tools to report bugs
[14:12] <sil2100> +1 on that
[14:19] <sil2100> hm, ok, we have some logs, weird
[14:19] <sil2100> Feels like what we fixed earlier?
[14:20] <Laney> it's claiming the desktop isn't launching, that would be something else
[14:22] <Laney> or is it the installed system?
[14:22] <Laney> in that case, no installer syslog
[14:25] <sil2100> Well, they attached some installer logs
[14:26] <sil2100> And there seemed to be some removals performed, looking at the logs now
[14:26] <Laney> ah
[14:26] <Laney> dang, just now
[14:26] <Laney> thanks 'hide' button!
[14:28] <icey> Hey, can an admin please reject the python-oslo.messaging from the bionic unapproved queue?
[14:28] <Laney> sil2100:
[14:28] <Laney> Feb  1 14:07:38 ubuntu apt-setup: This disc is called:
[14:28] <Laney> Feb  1 14:07:38 ubuntu apt-setup: 'Ubuntu 20.04.2 LTS _Focal Fossa_ - Release amd64 (20210201.1)'
[14:29] <handsome_feng> sil2100: Hi, I can't reproduce the bug here, and she (who is the member of our test team) can't reproduced it either, so I set the bug to Incomplete for more test, I think it won't block the 20.04.2 release
[14:32] <Laney> ah no, what, maybe I opened the wrong file, it is the right iso
[14:34] <sil2100> Laney: hm, still looking at it, but is there some problem and confusion because it installs linux-oem-5.6 and then removes the hwe kernel + bits? Maybe too much is removed?
[14:34] <rbasak> icey: done
[14:35] <icey> thanks rbasak - there will be a new upload shortly that we'll hopefully get through quickly (partial revert of previously accepted SRU)
[14:35] -queuebot:#ubuntu-release- Unapproved: rejected python-oslo.messaging [source] (bionic-proposed) [5.35.0-0ubuntu3]
[14:36] <sil2100> handsome_feng: ok, might be something specific to the given hardware
[14:36] <sil2100> handsome_feng: thanks for checking!
[14:37] <handsome_feng> sil2100:  nop :)
[14:39] <rbasak> icey: could you create a separate bug for the regresion please, tag it regression-updates, and close that bug from the changelog entry of your revert upload please, so that we can track it properly?
[14:39] <icey> rbasak: yes
[14:40] <rbasak> Thanks!
[14:41] -queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1051.53]
[14:45] -queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [ppc64el] (hirsute-proposed/universe) [1:13~++20210129063721+010b176cdefb-1~exp1] (no packageset)
[14:52] -queuebot:#ubuntu-release- New binary: libvirt [riscv64] (hirsute-proposed/main) [7.0.0-1ubuntu1] (ubuntu-server, virt)
[14:55] -queuebot:#ubuntu-release- New: accepted libvirt [amd64] (hirsute-proposed) [7.0.0-1ubuntu1]
[14:55] -queuebot:#ubuntu-release- New: accepted libvirt [armhf] (hirsute-proposed) [7.0.0-1ubuntu1]
[14:55] -queuebot:#ubuntu-release- New: accepted libvirt [riscv64] (hirsute-proposed) [7.0.0-1ubuntu1]
[14:55] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [ppc64el] (hirsute-proposed) [1:13~++20210129063721+010b176cdefb-1~exp1]
[14:55] -queuebot:#ubuntu-release- New: accepted libvirt [arm64] (hirsute-proposed) [7.0.0-1ubuntu1]
[14:55] -queuebot:#ubuntu-release- New: accepted libvirt [s390x] (hirsute-proposed) [7.0.0-1ubuntu1]
[14:55] -queuebot:#ubuntu-release- New: accepted libvirt [ppc64el] (hirsute-proposed) [7.0.0-1ubuntu1]
[15:07] -queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [amd64] (hirsute-proposed/universe) [1:13~++20210129063721+010b176cdefb-1~exp1] (no packageset)
[15:10] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [amd64] (hirsute-proposed) [1:13~++20210129063721+010b176cdefb-1~exp1]
[15:22] -queuebot:#ubuntu-release- Unapproved: rejected gnupg2 [source] (bionic-proposed) [2.2.4-1ubuntu1.4]
[15:24] <xnox> sil2100:  https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1914374 commented that the kernel removal highlighted is the expected one.
[15:24] <xnox> sil2100:  and asked if the oem v5.6 kernel is busted on that sku; if it should be using v5.6 oem kernel or the hwe v5.8 one.
[15:29] -queuebot:#ubuntu-release- Unapproved: dpdk (focal-proposed/main) [19.11.3-0ubuntu0.2 => 19.11.6-0ubuntu<IP_ADDRESS>] (kernel-dkms, ubuntu-server)
[15:32] -queuebot:#ubuntu-release- Unapproved: rejected dpdk [source] (focal-proposed) [19.11.6-0ubuntu<IP_ADDRESS>]
[16:01] <xnox> Laney:  is it intentional that we have -server nvidia graphics on the desktop iso available?
[16:05] <Laney> Dunno
[16:05] <Laney> Probably not
[16:06] <Laney> Is there some situation where you'd want that?
[16:09] <sil2100> How are those pulled in?
[16:13] <xnox> sil2100:  ship-live pattern.
[17:04] -queuebot:#ubuntu-release- Unapproved: python-oslo.messaging (bionic-proposed/main) [5.35.0-0ubuntu2 => 5.35.0-0ubuntu3] (openstack, ubuntu-server)
[17:10] <coreycb> rbasak, hello I've just uploaded python-oslo.messaging to the bionic unapproved queue and it deals with the regerssion-updates that icey mentioned earlier
[17:13] <paride> xnox, sil2100, I ran out of idea on https://bugs.launchpad.net/subiquity/+bug/1914285
[17:13] <paride> I tried a lot today to identify what's triggering it, but it's elusive
[17:14] <bdmurray> coreycb: If you don't have from Robie let me know and I can have a look.
[17:15] <bdmurray> s/have/hear/
[17:16] <rbasak> sil2100: can I accept dpdk into focal-proposed? AFAICT, it's seeded in supported-misc-servers only, though I'm confused by seeded-in-ubuntu listing it as "supported" by various flavours. I don't think it ends up on any ISO though?
[17:21] <rbasak> coreycb, icey: you're not reverting the first patch then? Are you hoping to land this in into -updates in a hurry, or can it wait the usual ageing period?
[17:22] <coreycb> rbasak: we're keeping the first patch. I'm going to ask seyeong, who tested the original SRU, if he can also test this version.
[17:23] <coreycb> I would like to get it out fast though, once tested
[17:24] <rbasak> coreycb: a straight revert of the entire SRU would minimise regression risk the most. Are we sure that the first patch won't interact in an unexpected way?
[17:24] <rbasak> I'm less sure about doing a partial revert in a hurry
[17:25] <rbasak> bdmurray: second opinion please?
[17:26] <coreycb> rbasak: pretty certain we're good with just having the first patch. the upstream approach was to only land the first patch in N-1 release and then add the 2nd/3rd patch in N release to minimize disruptiveness and we didn't follow that pattern in the first SRU in distro unfortunately. I've tested partial unattended-upgrades with this new bionic version from a PPA and it's not disruptive.
[17:28] <rbasak> coreycb: any special interaction for users already on 5.35.0-0ubuntu2 getting the revert?
[17:28] <coreycb> rbasak: the reason I want seyeong to test this new version is that the understanding is the first patch alone will fix the original bug.
[17:28] <bdmurray> rbasak: I'm in a metting at the moment, will look when it wraps up.
[17:29] <coreycb> rbasak: the easiest thing to do is to downgrade to 5.35.0-0ubuntu1 and restart neutron* services
[17:30] <coreycb> if they've already upgraded the entire cloud to 5.35.0-0ubuntu2 then the disruption goes away. it only is disruptive if parts of the cloud are at 5.35.0-0ubuntu1 and parts are at 5.35.0-0ubuntu2
[17:30] <rbasak> coreycb: my concern is just that in a hurry to fix a regression, further oversights can compound the problem, and so usually I'd prefer to see the whole thing reverted (usually that's lowest risk) and then to go around again with the full ageing period and normal level of QA/caution, rather than rush through an attempted further fix of the broken fix, IYSWIM.
[17:30] <rbasak> Let's see what Brian says.
[17:30] <rbasak> Apart from that point, your upload looks good.
[17:31] <coreycb> rbasak: ok thanks. I can revert everything too if it will help, and we can then put the single patch through more vigorous testing as a 3rd SRU.
[17:31] <rbasak> coreycb: wil it be disruptive if parts of the cloud are on 5.35.0-0ubuntu2 and parts on 5.35.0-0ubuntu3?
[17:32] <coreycb> rbasak: It shouldn't be a problem but that should be something we also test
[17:32] <coreycb> rbasak: for now, let me update the test case section with what needs testing before we'd release this
[17:36] -queuebot:#ubuntu-release- New binary: librepo [ppc64el] (hirsute-proposed/none) [1.12.1-4] (no packageset)
[17:38] <sil2100> rbasak: I think it should be ok for -proposed, but just be sure to not move it to -updates for now
[17:39] <bdmurray> coreycb: So given that some parts are on 5.35.0-0ubuntu1 how would that interact with 5.35.0-0ubuntu3?
[17:39] <coreycb> bdmurray: rbasak: I think I'll just revert all the patches and re-upload. There's no reason to rush the fix for the first sru, but there is reason to run the revert.
[17:39] <coreycb> s/run/rush/
[17:40] <bdmurray> Alirghty
[17:43] -queuebot:#ubuntu-release- New binary: librepo [s390x] (hirsute-proposed/universe) [1.12.1-4] (no packageset)
[17:47] <rbasak> sil2100: OK, thanks!
[17:48] -queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (groovy-proposed) [19.11.6-0ubuntu<IP_ADDRESS>]
[17:49] -queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (focal-proposed) [19.11.6-0ubuntu<IP_ADDRESS>]
[17:49] -queuebot:#ubuntu-release- Unapproved: python-oslo.messaging (bionic-proposed/main) [5.35.0-0ubuntu2 => 5.35.0-0ubuntu3] (openstack, ubuntu-server)
[17:50] -queuebot:#ubuntu-release- New binary: librepo [amd64] (hirsute-proposed/universe) [1.12.1-4] (no packageset)
[17:53] -queuebot:#ubuntu-release- Unapproved: rejected python-oslo.messaging [source] (bionic-proposed) [5.35.0-0ubuntu3]
[17:54] <rbasak> coreycb: thanks, and accepted. Please check for unexpected interactions with ubuntu2 before we release.
[17:54] -queuebot:#ubuntu-release- Unapproved: accepted python-oslo.messaging [source] (bionic-proposed) [5.35.0-0ubuntu3]
[17:57] -queuebot:#ubuntu-release- New binary: librepo [riscv64] (hirsute-proposed/universe) [1.12.1-4] (no packageset)
[18:02] -queuebot:#ubuntu-release- Unapproved: software-properties (groovy-proposed/main) [0.99.3 => <IP_ADDRESS>] (core)
[18:04] <coreycb> rbasak: will do, thank you
[18:11] -queuebot:#ubuntu-release- New binary: librepo [arm64] (hirsute-proposed/universe) [1.12.1-4] (no packageset)
[18:11] -queuebot:#ubuntu-release- New binary: librepo [armhf] (hirsute-proposed/universe) [1.12.1-4] (no packageset)
[18:20] -queuebot:#ubuntu-release- Unapproved: software-properties (focal-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (core)
[18:26] -queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (focal-proposed/main) [1:<IP_ADDRESS>~<IP_ADDRESS> => 1:<IP_ADDRESS>~<IP_ADDRESS>] (desktop-core, ubuntu-server)
[18:27] -queuebot:#ubuntu-release- Unapproved: gnupg2 (bionic-proposed/main) [2.2.4-1ubuntu1.3 => 2.2.4-1ubuntu1.4] (core)
[19:00] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (focal-proposed) [1:<IP_ADDRESS>~<IP_ADDRESS>]
[20:49] -queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (core)
[20:51] <sil2100> bdmurray: hey! Can you review the ubiquity upload ^? It's the real fix for the OEM bug ^
[20:52] <bdmurray> sil2100: Yes, how many people have worked on it?
[20:52] <sil2100> 3
[20:53] <bdmurray> That sounds rubber stampable then
[20:53] <bdmurray> ;-)
[20:53] <sil2100> hah, well, I could have still done some mistake when prepping the upload!
[20:53] <sil2100> So better if you take a look anyway
[20:53] <bdmurray> I am!
[20:54] <bdmurray> What are apt_installed and all_removed?
[20:55] <sil2100> hm, sadly I think we won't have the time to do *all* the testing of that in -proposed, so after a sanity test I'll just push it through to -updates and let the OEM guys check the RC images
[20:56] <sil2100> bdmurray: so apt_removed is the list of packages marked for removal during the installation - and there's actually two lists of that, apt_removed and apt_removed_recursive (packages that have been marked for recursive removal)
[20:56] <sil2100> So when excluding those from the list of apt_installed we want to get all packages from both those sets
[20:57] <bdmurray> Okay, and then the log line will have a large list in %s?
[20:57] <sil2100> Might, but most of the time it's either empty (so no message at all) or 1-2 packages
[20:58] <sil2100> In the case of the OEM bug it was basically one package
[21:07] <bdmurray> sil2100: Was it generated with -v?
[21:07] <sil2100> bdmurray: actually, wait! I see a problem
[21:07] <bdmurray> sil2100: oh, the old one is in -proposed and -updates
[21:07] <sil2100> bdmurray: please wait, I'll re-upload
[21:08] <bdmurray> sil2100: okay, standing by
[21:12] -queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (focal-proposed) [<IP_ADDRESS>]
[21:14] -queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (core)
[21:14] <sil2100> bdmurray: ok, new upload pushed
[21:15] <sil2100> bdmurray: should be good now - previously the line was too long and I didn't see it as I was not running the clean-tests
[21:22] <sil2100> bdmurray: does it look okayish to you?
[21:23] <bdmurray> sil2100: ish
[21:23] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (focal-proposed) [<IP_ADDRESS>]
[21:24] <sil2100> Thank you! Now for it to build, doing a quick sanity test and then off to -updates with it
[21:24] <sil2100> In the meantime I'll go a bit AFK
[22:08] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (groovy-proposed/main) [5.8.0-1021.22] (core, kernel)
[22:12] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (groovy-proposed) [5.8.0-1021.22]
[22:14] -queuebot:#ubuntu-release- New binary: linux-signed-oem-5.10 [amd64] (focal-proposed/main) [5.10.0-1014.15] (no packageset)
[22:58] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (groovy-proposed) [<IP_ADDRESS>]
[23:01] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (focal-proposed) [<IP_ADDRESS>]
[23:15] -queuebot:#ubuntu-release- New binary: linux-signed-kvm [amd64] (groovy-proposed/main) [5.8.0-1017.19] (core)
[23:27] -queuebot:#ubuntu-release- New: accepted linux-signed-kvm [amd64] (groovy-proposed) [5.8.0-1017.19]
[23:28] -queuebot:#ubuntu-release- New: accepted grub2.04-signed [source] (focal-proposed) [1.143]
[23:33] -queuebot:#ubuntu-release- New binary: grub2.04-signed [amd64] (focal-proposed/none) [1.143] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: grub2.04-signed [arm64] (focal-proposed/none) [1.143] (no packageset)
[23:49] -queuebot:#ubuntu-release- New: accepted grub2.04-signed [amd64] (focal-proposed) [1.143]
[23:49] -queuebot:#ubuntu-release- New: accepted grub2.04-signed [arm64] (focal-proposed) [1.143]


[07:41]  * jasonjang is away: 자리 비웁니다.
[07:46]  * jasonjang is back (gone 00:05:07)
[07:46]  * jasonjang is away: 자리 비웁니다.
[07:50] <nalioth> jasonjang: please disable that away script when you return.  Thanks  :)
[08:20]  * jasonjang is back (gone 00:33:45)
[08:20] <jasonjang> i'm sorry nalioth
[15:17] <padhu> Any classes?


[00:55] <kklimonda> we don't have any contact set for ~ubuntu-pl and, when owner tried to set<EMAIL_ADDRESS>as contact, it didn't work - a confirmation email never made it to ML. I've asked list admin and there aren't any messages in the moderation queue.. any ideas? :)
[13:09] <czajkowski> aloha can comeone help with https://answers.launchpad.net/launchpad-registry/+question/122827  please ?
[13:24] <sinzui> czajkowski, I'll assign your question to an admin who can make the change
[13:25] <czajkowski> sinzui: thanks
[13:25] <czajkowski> I never know who to poke
[14:20] <Laney> Is it feasible to have the PPA builders build distro packages when their queues are empty?
[14:21] <Laney> armel has a queue length of 62, but the PPA queue is currently at 0
[14:21] <bigjools> at some point yes
[14:21] <Laney> yeah
[14:22] <bigjools> we have other improvements coming first :)
[14:22] <persia> really?  Doesn't that require harmonising architecural models for PPAs and regular builders?  And wouldn't that require someone to write a virtualisation hypervisor for armel?
[14:22] <Laney> there are already armel ppa builders
[14:25] <persia> the armel PPA builds aren't hypervised, and seem to behave differently than the non-armel PPA builders (but I don't know the specifics)
[14:59] <weather15> ANyone know what to do about this: bzr: ERROR: Connection error: curl connection error (server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none) on https://launchpad.net/~webmaster-techhelper/%2Bsshkeys
[15:00] <weather15> The problem is on this network all traffic is routed through a proxy
[15:00] <weather15> includeing SSL traffic
[15:00] <weather15> The proxy server issues a certicate for every website using SSL
[15:00] <weather15> This causes the verification to fail
[15:06] <danilos> weather15, hi
[15:06] <weather15> Hi
[15:07] <danilos> weather15, what are you trying to do when you get that?
[15:07] <weather15> was reading for help it says to contact you
[15:07] <weather15> Login to Launchpad using bzr
[15:07] <danilos> weather15, using "bzr login"?
[15:07] <weather15> bzr launchpad-login
[15:07] <danilos> weather15, if the proxy server is rewriting security certificates, the communication is not really secure
[15:08] <weather15> Yes I understand that
[15:08] <weather15> This way the traffic gets filtered for viruses and such
[15:08] <danilos> weather15, so, it's expected that you can't log in
[15:08] <weather15> What can I do about it then
[15:09] <weather15> Considering I can login to home on VPN I guess I could work around
[15:09] <weather15> How ever I am using a proxy at home too which is the same thing but I think I can bypass the interception of the traffic
[15:09] <weather15> considering in the admin
[15:10] <weather15> That fixed the problem
[15:10] <danilos> weather15, you can either use anonymous access (http) or not use such a proxy
[15:10] <weather15> on this network the proxy is transparent so
[15:10] <weather15> not much i can do but login to home and change my transparent home proxy
[15:10] <weather15> Like i DID
[15:15] <weather15> Anyone else having trouble deleteing branches on Edge?
[15:18] <weather15> Keeps returning this error:   (Error ID: OOPS-1699EC1641)
[15:20] <weather15> I'm not sure if this is because there is a recipe attached
[15:20] <weather15> so I tried to delete the recipe and: (Error ID: OOPS-1699EC1655)
[15:55] <danilos> rockstar, abentley: hi, please look at the OOPSes weather15 is mentioning (having trouble deleting a branch with a recipe attached)
[15:58] <abentley> danilos, that's a bug that I don't think we have a workaround for.
[16:22] <danilos> abentley, right, thanks
[18:10] <ahasenack> hey guys, I'm getting this constantly: "Sorry, there was a problem connecting to the Launchpad server."
[18:10] <ahasenack> url is https://bazaar.launchpad.net/~ahasenack/landscape/qa-scripts/files
[18:10] <ahasenack> just doesn't open
[19:44] <ahasenack> hi guys, "http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/doc/examples/" isn't working, saying "Sorry, there was a problem connecting to the Launchpad server.", something going on in general or just me?
[20:03] <salgado> LOSA ping.  looks like codebrowse needs a kick (^)
[20:04] <mbarnett> salgado: yupyup... it has been starting up for about 3 minutes now
[20:04] <mbarnett> hopefully it will finish starting soon!
[20:04] <salgado> ahasenack, ^
[20:04] <salgado> thanks mbarnett
[20:04] <ahasenack> salgado: thanks
[20:10] <mbarnett> everything should be back to normal now.
[20:57] <micahg> is it my imagination or is the text in comments on LP large now?
[20:58] <BlackZ> micahg: no, it's isn't your imagination, that happens to me too, are you using edge.launchpad.net ?
[20:58] <micahg> BlackZ: yep
[20:58] <micahg> deryck: is the above worth filing a bug or a known issue?
[20:59] <deryck> micahg, already on it. for once. ;)
[20:59] <micahg> deryck: heh, ok :)
[20:59]  * deryck is getting bug number
[20:59] <deryck> micahg, bug 624666
[20:59] <micahg> deryck: I trust you :)
[21:00]  * micahg will increase the heat though :)
[21:01] <deryck> bring the heat!
[21:06] <fta> i wonder why each (ppa) builder gives so different build durations for almost identical packages
[21:06] <fta> http://people.ubuntu.com/~fta/ppa-build-durations.html
[21:07] <fta> (last 100 builds of chromium daily)
[21:10] <fta> hm, seems it's always hardy & jaunty taking twice the time as more recent dists, interesting


[00:05] <cyphermox> herton: right, we don't want to revert this, it's going to be in backported kernels too
[00:05] <cyphermox> I think I'll cherry-pick a patc
[00:05] <herton> ack
[00:05] <cyphermox> a patch from NM to fix up this detection code, should make everything work again.
[00:05] <cyphermox> (and will be future-proof)
[00:06] <herton> cyphermox, ok cool. I'll mark the linux tak invalid
[00:06] <herton> *task
[00:06] <cyphermox> herton: thanks
[05:14] <ppisati> moin
[06:26] <ppisati> brb
[07:07] <verwilst> apw, one gfs2 bug squashed, another one pops up :P
[07:18] <verwilst> i kinda feel like i'm the only ubuntu user that uses gfs2 :P
[07:18] <verwilst> ( which probably is pretty true :) )
[07:55] <apw> ppisati, moin
[09:03] <ppisati> i've a problem with my mutt setup: from time to time, it seems to hang there... grrrr...
[11:41]  * henrix -> lunch
[13:14] <ogasawara> rtg: I'm gonna prep an upload, anything you need to push before I kick off test builds?
[13:15] <rtg> ogasawara, do you think 3.5.3 will land today ?
[13:15] <ogasawara> rtg: I am expecting it soonish.  I do plan on doing another upload tuesday before beta-1 freeze, so we can pick it up then if it does land.
[13:16] <rtg> I guess if it does we can still upload next week
[13:16] <rtg> ogasawara, fire away
[14:19] <rtg> ogasawara, did I mention I pushed ubuntu-r v3.6-rc3 yesterday ? still got some armhf build problems that I'll go after today.
[14:19] <ogasawara> rtg: ah cool, thanks
[14:19] <rtg> ogasawara, should prolly sync with Quantal as well
[14:20] <ogasawara> rtg: I need to get back in the habit of pushing to both
[14:21] <rtg> ogasawara, I've got the checkpoint tag. I'll just go through and apply the relevant patches from Quantal
[14:38]  * ogasawara back in 20
[17:15] <herton> rtg, I'm still looking at that gso stuff. If I didn't got it wrong, netif_needs_gso is true if we are going to emulate the GSO stuff, that's why we return 1 there. But I think I was wrong about using the check inside netif_needs_gso for Lucid, seems the features flags from the device can also be used later, eg., inside dev_gso_segment->skb_gso_segment which also calls skb_gso_ok inside it
[17:17] <rtg> herton, I'm tempted to just dump the whole mess. I don't think it is really vulnerable, at least not like Precise and later are.
[17:19] <herton> rtg, seems to depend on the driver+hardware used for that CVE to be triggered
[17:19] <rtg> herton, agreed, so I'm not real concerned. its more of a PITA then its worth.
[17:20] <herton> rtg, only sfc is using that gso_max_segs, so probably is the only one affected
[17:23] <herton> actually, since other drivers don't set gso_max_segs, it seems only sfc is doing gso...
[17:49] <LoT> what's the latest Precise kernel that is not in -proposed?
[17:52] <bjf> LoT: 3.2.0-29.46
[17:52] <LoT> in the latest precise kernel, did a rss-counter bug (fixed in 3.4.x) get patched?
[17:53] <LoT> bjf:  that's what i found, from checking the repos.  see last message
[17:53] <bjf> LoT: you could check the git repo to see if the commit you are interested in is there
[17:53] <LoT> not even sure what the commit was
[17:54] <LoT> i'm not a kernel expert, i'm being stabbed by a user of my shell(s) who claims they are a kernel expert...
[17:54] <bjf> LoT: there are likely over 150+ commits
[17:54] <LoT> saying we should upgrade to 3.4.xx
[17:54] <LoT> i said to them to shut up :p
[17:55] <rtg> ogasawara, repushed Ubuntu-R-sync and ubunt-r. I'll get the LTS packaged and built after lunch
[17:55] <ogasawara> rtg: ack
[17:55]  * rtg -> lunch
[18:00]  * cking messes up an rbd snapshot and calls it a week. fail
[18:21]  * cking -~> EOD
[18:48] <infinity> bjf: Are armadaxp and ti-omap4 being invalidated and re-based for precise to catch the same bugfix as master?
[19:06]  * ogasawara lunch
[20:25] <bjf> infinity: since that is the point of the bug fix, i'm assuming so though i've not heard anything about them specifically
[20:25] <bjf> infinity: and since the folks responsible for those two flavours are gone for the day ...
[20:27] <herton> bjf, infinity: the bot at least will open new bugs for ti-omap4 and armadaxp once the current master precise packages built on the ppa, they should get notification this way also
[20:27] <herton> *are built
[20:27] <bjf> herton, good point, thanks
[20:32] <infinity> herton: That seems odd.  Shouldn't the bot be opening derivative bugs when the source is uploaded, not when the binaries build?
[20:32] <infinity> herton: Seems like some unnecessary lead time, there.
[20:34] <herton> infinity, it was just to ensure the packages build and there are no other problems on the branch before the rebase, already happened that we had packages that failed to build one or other time, but could be changed
[20:50]  * rtg -> EOW
[21:08] <DanMD> Hey there everyone :), is there anyone out there with any experience building the ubuntu-precise kernel?
[21:09] <DanMD> I have a very strange issue.. Basically I am compiling one of the tags in the ubuntu-precise git repo, I am able to install it and everything works fine. However, if I try and build a kernel module for it, the kernel module cannot be inserted
[21:11] <DanMD> insmod will simply give me a "Killed" message and a line in dmesg says "BUG: unable to handle kernel paging request at ffff8800e018105e"
[21:34] <mjg59> DanMD: There's a bug in your kernel module
[21:36] <DanMD> mjg59: Thank you so much for replying!! I was thinking that as well, but I created my own kernel module that does nothing but printk, it doesn't actually contain any code.
[21:36] <DanMD> mjg59: Other than the module_init and module_exit functions
[21:37] <DanMD> mjg59: It seems like any module I try and create with the linux-headers package that was created in the build fails this way
[21:59] <DanMD> mjg59: Could there possibly be anything wrong with how I built the kernel?
[22:36] <xnox> bug 1038055 is now believed to be kernel issue
[22:36] <ubot2`> Launchpad bug 1038055 in ubiquity "cannot unlock LUKS devices, in kvm with cirrus graphics" [Undecided,Invalid] https://launchpad.net/bugs/1038055
[22:37] <xnox> specifically graphics fail to initialise correctly
[23:12] <slangasek> jsalisbury: ^^ xnox's bug #1038055 is a rather significant issue for quantal VMs running under kvm; can you get it on The List?
[23:12] <ubot2`> Launchpad bug 1038055 in ubiquity "graphics fail to initialise correctly, in kvm with cirrus graphics (after LUKS install)" [Undecided,Invalid] https://launchpad.net/bugs/1038055


[01:35] <ubotu> New bug: #126748 in xserver-xorg-video-nv (main) "Occasional color map corruption with GeForce 6150" [Undecided,New]  https://launchpad.net/bugs/126748
[03:36] <ubotu> New bug: #37472 in linux-source-2.6.15 (main) "the keyboard don't work perfectly on laptops acer travelmate 2300 series with Dapper (dup-of: 39315)" [High,Incomplete]  https://launchpad.net/bugs/37472
[06:08] <ubotu> New bug: #119465 in xorg (main) "ati radeon cards won't work" [Undecided,New]  https://launchpad.net/bugs/119465
[07:22] <ubotu> New bug: #123266 in xorg (main) "[gutsy]  AGP not available, amd64_agp, drm" [Undecided,New]  https://launchpad.net/bugs/123266
[09:45] <ubotu> New bug: #123885 in xorg (main) "failed to start Ubuntu 7.10 Tribe 2 (radeon x800 xl pcie)" [Undecided,New]  https://launchpad.net/bugs/123885
[09:46] <ubotu> New bug: #126820 in xorg-server (main) "Xorg crashed with SIGSEGV in xf86XVRegetVideo" [Undecided,New]  https://launchpad.net/bugs/126820
[09:49] <ubotu> New bug: #119585 in xorg (main) ""out of range" message on monitor" [Undecided,Incomplete]  https://launchpad.net/bugs/119585
[10:17] <ubotu> New bug: #125902 in xorg (main) "X server crashed while gnome-session was checking for texture_from_pixmap support under VMWare" [Undecided,New]  https://launchpad.net/bugs/125902
[10:35] <ubotu> New bug: #126843 in xserver-xorg-driver-ati (main) "ATI Radeon 7200 + OpenGL Lockup with Gutsy Gibbon Tribe 2" [Undecided,New]  https://launchpad.net/bugs/126843
[10:57] <ubotu> New bug: #119357 in xorg (main) "[ gutsy ]  applications use wrong screen resolution" [Undecided,Incomplete]  https://launchpad.net/bugs/119357
[11:50] <ubotu> New bug: #126867 in xserver-xorg-video-savage (main) "please sync xserver-xorg-video-savage 2.1.2-6 from Debian unstable" [Undecided,New]  https://launchpad.net/bugs/126867


[12:07] <rmg51> Morning
[12:41] <JonathanD> hi
[12:41] <JonathanD> no laptop today.
[14:30] <rmg51> JonathanD, for me no laptop = no computer
[14:31] <rmg51> I gave up desktop ten years ago
[15:04] <JonathanD> rmg51: I onlu have my phone with me today.
[15:05] <rmg51> I can't even do that
[15:05] <rmg51> I have a phone phone
[15:06] <JonathanD> at home I do have a desktop for gaming.
[15:07] <rmg51> I never got unto gaming
[15:20] <KyleYankan> I bought my last desktop in 2005.
[15:39] <SamuraiAlba> Good bacon to all!
[16:05] <KyleYankan> Bacon is the worst.
[16:05]  * KyleYankan volunteers as tribute
[17:26] <pvl1> gaming is what got me into computers
[20:25] <waltman> pvl1: You'll know you've leveled up when you realize that programming IS the game.
[20:27] <pvl1> exactly
[20:27] <pvl1> runescape got me into java
[20:27] <pvl1> well the ida of programming
[20:31] <KyleYankan> runescape got me into aq nocturnal sleep schedule and wrist braces.
[20:31] <pvl1> same thing
[20:31] <pvl1> its how i found out my ti83 can program in basic
[20:32] <pvl1> and all of the sudden math class got a hell of a lot more challenging


[04:13] <RAOF[m]> xnox: huh! The Mir symbols mismatch is an interesting one!
[04:14] <RAOF[m]> xnox: I think it's plausibly a bug/missing feature in dpkg-gensymbols.
[04:14] <RAOF[m]> But it's also weird behaviour by the linker.
[04:17] <RAOF[m]> With LTO enabled, the linker emits debug symbols (but not the function symbols) for some otherwise-unexported symbols.
[04:18] <RAOF[m]> dpkg-gensymbols then complains that we're introducing new symbols.
[04:20] <RAOF[m]> But you can't actually *link* against those symbols; they're just the debug info. So they're irrelevant for the symbols file.
[04:20] <RAOF[m]> Hmmmm
[04:54] <RAOF[m]> And, of course, dh_strip gets them out of the DSO *anyway*, and the problem is only that the `check-miral-symbols` target gets run before `dh_strip` is.
[06:12] <mvo> infinity: hey, good morning, sorry for not getting back last night, real life interfered :/
[06:13] <mvo> infinity: I tried to reproduce in various ways yesterday but no luck, I try harder now
[06:40] <mvo> jibel: fwiw, I can reproduce it now with both snapd 2.33 and 2.34 :/
[06:40] <mvo> jibel: we are looking into it
[06:47] <mvo> jibel: after a bit of poking I think this is "just" a side-effect of the seed order issue
[06:47] <mvo> jibel: i.e. once the seed order is correct and the initial snap seeding works then gedit should install again
[08:59] <LocutusOfBorg> Laney, good morning, quick question: if gst-plugins-good1.0 builds correctly, does this mean I can sync gst-plugins-base?
[08:59] <LocutusOfBorg> see https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa for progresses :p
[09:04] <Laney> LocutusOfBorg: No, we have a change in -good to keep the qt5 stuff on armhf which requires that change in -base.
[09:04] <Laney> If you wanted to, you could check if all of those changes can be dropped (if the current mesa is fixed)
[09:04] <Laney> https://github.com/KhronosGroup/OpenGL-Registry/issues/162 this one was closed
[09:10] <Laney> are you doing the point release update?
[09:25] <xnox> RAOF[m], indeed the symbols to me looked weird.
[09:39] <LocutusOfBorg> Laney, I'm taking wrt cosmic, and the fact that we need to merge/sync gst...
[09:39] <Laney> I know you are
[09:40] <LocutusOfBorg> the -base plugin (new version) might have fixed that, that was the origin of the question
[09:40] <Laney> It'll be a fix in the headers that come with mesa
[09:40] <LocutusOfBorg> mmm they might have fixed in the plugin...
[09:40] <LocutusOfBorg> -#ifdef USE_EGL_RPI
[09:40] <LocutusOfBorg> +#if !GST_GL_HAVE_EGLUINT64KHR
[09:40] <LocutusOfBorg>  typedef khronos_uint64_t EGLuint64KHR;
[09:40] <LocutusOfBorg> this is what I'm seeing in the diff
[09:41] <LocutusOfBorg> maybe they workarounded it, without having to wait for mesa
[09:41] <LocutusOfBorg> so, this is the question: can I upload a sync if -good builds on arm*?
[09:41] <LocutusOfBorg> (this requires stealing your merge btw)
[09:42] <Laney> no, you have to keep my reverts in there
[09:43] <Laney> if it builds with the synced base and those reverts, that's the good state
[09:44] <Laney> (there -> -good)
[09:46] <LocutusOfBorg> Laney, I was talking about syncing base, I know the good needs a merge (and yes, here I kept the revert of course)
[09:47] <Laney> ok then
[09:47] <LocutusOfBorg> and it failed to build, so can I merge both? :)
[09:48] <LocutusOfBorg> tjaalton, mesa merge ping :p
[09:48] <Laney> sure, and -bad plz
[09:48] <Laney> if you could use the git repositories that would make me happy
[09:49] <LocutusOfBorg> I will
[09:51] <Laney> not sure newest mesa is fixed yet
[09:51] <Laney> https://salsa.debian.org/xorg-team/lib/mesa/blob/debian-unstable/include/GL/glext.h#L468 should be khronos_ssize_t etc
[09:53] <LocutusOfBorg> according to the debian bug seems not
[09:53] <LocutusOfBorg> I fail to see pull requests...
[09:54] <RAOF[m]> xnox: they're *meant* to be local:*'d away in the linker script (and, indeed, the actual text of the functions *is* not in the DSO), so it's *additionally* a ld.bfd bug. Which I'll file tomorrow.
[09:54] <Laney> I dunno what the process for those headers getting from khronos into mesa is; hopefully there is one
[10:15] <Laney> LocutusOfBorg: it'd be better if you would git merge properly rather than import-dsc
[10:16] <Laney> up until now those branches shared proper history with debian
[10:18] <LocutusOfBorg> oh... ok
[10:18] <LocutusOfBorg> should I force push?
[10:19]  * Laney looks the other way :-)
[10:19] <Laney> (yes, it's probably not been too long)
[10:24] <LocutusOfBorg> Laney, I don't get why you should look anywhere, looks like the history has never been pushed remotely
[10:25] <Laney> what?
[10:26] <LocutusOfBorg> the remote git repository is "clean" :)
[10:26]  * LocutusOfBorg feels dirty, as much as the remote is now clean
[10:27] <LocutusOfBorg> now I have time to properly do things...
[10:27] <LocutusOfBorg> in order to do it, I should: git merge debian/upstream pristine-tar and master, and then apply changes on top, right?
[10:29] <Laney> right
[10:29] <Laney> well upstream and pristine-tar will just be the same as what debian has, no commits there
[10:29] <Laney> you just push those branches and the upstream/xxx tag to launchpad
[10:30] <Laney> for the packaging branch, git merge the tag, which should keep our delta (may be some conflicts)
[10:30] <Laney> then check the various diffs
[10:30] <LocutusOfBorg> ack
[10:30] <LocutusOfBorg> will do after lunch maybe :D
[10:35] <LocutusOfBorg> Laney, can you please double-check?
[10:36] <Laney> LocutusOfBorg: ok, where should I look?
[10:38] <LocutusOfBorg> https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gst-plugins-base1.0?h=master
[10:38] <LocutusOfBorg> and so on
[10:38] <LocutusOfBorg> I did base good and bad
[10:38] <Laney> ok, I would expect pristine-tar to be 6f933d105fc6d371a55bf516eab60725fac43861 and upstream to be 248418e33dcd27b99493cc56cc92872d662db276
[10:38] <Laney> for -base
[10:39] <LocutusOfBorg> and they are?
[10:39] <LocutusOfBorg> https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gst-plugins-base1.0/log/?h=pristine-tar
[10:39] <Laney> let me check
[10:40] <Laney> looks good!
[10:41] <LocutusOfBorg> nice thanks! probably the force-push messed up a little bit the graphical page, it will refresh in some hours hopefully
[10:41] <Laney> then gbp buildpackage --git-tag-only
[10:41] <Laney> should give you the ubuntu/XXX tag to push once it's uploaded
[10:41] <LocutusOfBorg> I did that already
[10:42] <LocutusOfBorg> except for the good, because gbp.conf was badly set https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gst-plugins-good1.0/commit/?id=8cf9b8fc1672cba9ad6690272f97f6dfa6c82f6f
[10:42] <LocutusOfBorg> I fixed but won't upload just because of that change
[10:42] <Laney> thx, you can make the tag manually
[10:43] <Laney> I think I only started using ubuntu/ tags on those repositories recently
[10:45] <LocutusOfBorg> it is already tagged as debian/1.14.2-1ubuntu1
[10:45] <LocutusOfBorg> so... ok lets copy the tag
[10:45] <Laney> :3
[10:46] <Laney> doesn't matter too much though
[10:47] <LocutusOfBorg> it matters, because I did in a bash loop the following "git diff debian/1.14.2-1 ubuntu/1.14.2-1ubuntu1"
[10:47] <LocutusOfBorg> and it failed :p
[10:47] <LocutusOfBorg> so, more automation with that change!
[10:47] <Laney> heh
[12:39] <tjaalton> LocutusOfBorg: next week when I'm back
[12:58] <LocutusOfBorg> sure thanks themill
[12:59] <LocutusOfBorg> s/themill/tjalton
[12:59] <LocutusOfBorg> :)
[12:59] <themill> 1 out of 7
[14:30] <abeato> sil2100, hi, I have an implementation for the ubuntu-image changes to be able to use a roorfs instead of lb: https://github.com/CanonicalLtd/ubuntu-image/pull/155
[14:30] <abeato> sil2100, there are probably some tests missing, but it would be good if you can take a look toi give thumbs up/down to the general approach
[14:45] <sil2100> abeato: sure, but only after the point-releases
[14:45] <sil2100> Since we're busy with those right now
[14:46] <sil2100> Thanks!
[15:03] <abeato> sil2100, sure, np
[17:15] <LocutusOfBorg> Laney, I don't really understand the new gl failure for plugins-good... any hint?
[17:47] <coreycb> jamespage: doko_ : fyi the py3.7 threading deadlock has been narrowed down to monkeypatching of stdlib thread modules combined with use of ThreadPoolExecutor.  more details at: https://bugs.python.org/issue34173
[18:41] <mvo> infinity: just in case you don't know already - your seed.yaml reorder workaround works and snap install gedit now works as expected as well
[20:37] <caravena> https://bugs.launchpad.net/bugs/1783363
[23:56] <Unit193> mwhudson: Hrm, did the retry not fix it?