| mwhudson | vorlon: have you tried beignet without lto? | 00:02 |
|---|---|---|
| vorlon | mwhudson: I don't remember. It's possible, but I haven't looked at it in over a month | 00:02 |
| mwhudson | i *think* lto is just making this harder to debug but ... | 00:03 |
| -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (focal-proposed) [1:0.9.0~0.20.04.7] | 00:10 | |
| -queuebot:#ubuntu-release- Unapproved: gnome-connections (jammy-proposed/universe) [42.0-1 => 42.1-1] (no packageset) (sync) | 00:14 | |
| mwhudson | vorlon: also beignet in jammy-proposed explicitly depends on llvm-9, is there a newer version in debian? | 00:15 |
| -queuebot:#ubuntu-release- Unapproved: accepted gnome-connections [sync] (jammy-proposed) [42.1-1] | 00:15 | |
| mwhudson | oh and this is why beignet is not in testing | 00:16 |
| vorlon | mwhudson: uh I thought the -proposed version was using newer llvm? | 00:20 |
| mwhudson | vorlon: doesn't look like it | 00:21 |
| vorlon | mwhudson: ok well, "unreleasable let's remove it" is one solution, thanks | 00:21 |
| mwhudson | (lto doesn't fix the build fwiw) | 00:21 |
| mwhudson | vorlon: ack | 00:21 |
| mwhudson | what does this software do anyway :) | 00:21 |
| mwhudson | opencl on intel gpus? | 00:22 |
| mwhudson | _old_ intel gpus | 00:22 |
| mwhudson | vorlon: huh mythv seems significantly less installable in jammy than impish, i wonder what is going on there | 00:48 |
| -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (impish-proposed) [1:0.9.2.4~0.21.10.2] | 01:00 | |
| -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (impish-proposed) [1:0.9.2.4~0.21.10.2] | 01:09 | |
| -queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (focal-proposed) [1.5.9-0ubuntu1~20.04.1] | 01:45 | |
| vorlon | mwhudson: I think there may have been some removals along the way, but I don't recall | 02:05 |
| -queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (focal-proposed) [20.10.12-0ubuntu2~20.04.1] | 02:14 | |
| -queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (impish-proposed) [20.10.12-0ubuntu2~21.10.1] | 02:18 | |
| -queuebot:#ubuntu-release- Unapproved: mythexport (jammy-proposed/multiverse) [2.2.4-0ubuntu6 => 2.2.4-0ubuntu7] (no packageset) | 02:20 | |
| -queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (impish-proposed) [1.5.9-0ubuntu1~21.10.1] | 02:21 | |
| -queuebot:#ubuntu-release- Unapproved: accepted mythexport [source] (jammy-proposed) [2.2.4-0ubuntu7] | 02:21 | |
| -queuebot:#ubuntu-release- Unapproved: python-dbusmock (jammy-proposed/universe) [0.27.3-1 => 0.27.5-1] (no packageset) (sync) | 05:17 | |
| -queuebot:#ubuntu-release- Unapproved: accepted python-dbusmock [sync] (jammy-proposed) [0.27.5-1] | 05:18 | |
| -queuebot:#ubuntu-release- Unapproved: cockpit-machines (focal-backports/universe) [263-1~bpo20.04.1 => 265-1~bpo20.04.1] (no packageset) | 05:19 | |
| -queuebot:#ubuntu-release- Unapproved: cockpit-machines (impish-backports/universe) [263-1~bpo21.10.1 => 265-1~bpo21.10.1] (no packageset) | 05:19 | |
| -queuebot:#ubuntu-release- Unapproved: accepted cockpit-machines [source] (focal-backports) [265-1~bpo20.04.1] | 05:20 | |
| -queuebot:#ubuntu-release- Unapproved: accepted cockpit-machines [source] (impish-backports) [265-1~bpo21.10.1] | 05:20 | |
| -queuebot:#ubuntu-release- Unapproved: intel-vc-intrinsics (jammy-proposed/universe) [0+git20210816-2 => 0.1.0-2] (no packageset) (sync) | 06:49 | |
| -queuebot:#ubuntu-release- Unapproved: accepted intel-vc-intrinsics [sync] (jammy-proposed) [0.1.0-2] | 06:49 | |
| -queuebot:#ubuntu-release- Unapproved: libx11 (jammy-proposed/main) [2:1.7.2-2build1 => 2:1.7.5-1] (core, i386-whitelist, xorg) (sync) | 07:28 | |
| -queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (jammy-proposed) [1:5.0.0~git2209-g5a7b9ce67-0ubuntu1] | 07:35 | |
| -queuebot:#ubuntu-release- Unapproved: accepted libx11 [sync] (jammy-proposed) [2:1.7.5-1] | 07:36 | |
| seb128 | hey there, any chance someone could review https://bugs.launchpad.net/ubuntu/+source/libarchive/+bug/1967127 ? | 07:40 |
| ubottu | Launchpad bug 1967127 in libarchive (Ubuntu) "[FFe] update libarchive to 3.6.0" [Undecided, New] | 07:40 |
| seb128 | it has been waiting for a week, that's making a difference in the testing it will get at this point of the cycle | 07:41 |
| -queuebot:#ubuntu-release- Unapproved: arc-theme (jammy-proposed/universe) [20220223-1 => 20220405-1] (lubuntu, personal-fossfreedom, ubuntu-budgie) (sync) | 07:41 | |
| -queuebot:#ubuntu-release- Unapproved: xf86-input-wacom (jammy-proposed/main) [1:0.39.0-0ubuntu3 => 1:1.0.0-3ubuntu1] (desktop-core, xorg) | 07:46 | |
| seb128 | would be nice if the bot was posting about FFe bug being reported and status changes | 07:47 |
| handsome_feng | sil2100: Hi, about LP: #1966321, can I upload the new ubuntukylin-meta? Since it cause the livefs build errors now: https://launchpadlibrarian.net/595097521/buildlog_ubuntu_jammy_arm64_ubuntukylin_BUILDING.txt.gz | 08:24 |
| ubottu | Launchpad bug 1966321 in ubuntukylin-meta (Ubuntu) "[FFe] Switch to fcitx5" [High, New] https://launchpad.net/bugs/1966321 | 08:24 |
| -queuebot:#ubuntu-release- Unapproved: libadwaita-1 (jammy-proposed/main) [1.1.0-1 => 1.1.0-1ubuntu1] (no packageset) | 08:57 | |
| -queuebot:#ubuntu-release- Unapproved: zsys (focal-proposed/main) [0.4.8 => 0.5.9] (no packageset) | 09:18 | |
| -queuebot:#ubuntu-release- Unapproved: rejected zsys [source] (focal-proposed) [0.5.9] | 09:30 | |
| -queuebot:#ubuntu-release- Unapproved: zsys (jammy-proposed/main) [0.5.8build2 => 0.5.9] (ubuntu-desktop) | 09:32 | |
| sil2100 | handsome_feng: yes! Please do! | 09:47 |
| sil2100 | Switched the FFe bug to Triaged | 09:47 |
| -queuebot:#ubuntu-release- Unapproved: dpkg (jammy-proposed/main) [1.21.1ubuntu1 => 1.21.1ubuntu2] (core, i386-whitelist) | 09:48 | |
| xnox | juliank: ^^^^ implementing reverted nmu in Ubuntu at least. | 09:52 |
| handsome_feng | sil2100: Got it, Thank you. | 09:54 |
| -queuebot:#ubuntu-release- Unapproved: iptables-netflow (focal-proposed/universe) [2.4-2ubuntu0.4 => 2.4-2ubuntu0.5] (kernel-dkms) | 09:55 | |
| -queuebot:#ubuntu-release- Unapproved: lttng-modules (focal-proposed/universe) [2.12.5-1ubuntu2~20.04.1 => 2.12.5-1ubuntu3~20.04.1] (kernel-dkms) | 10:00 | |
| -queuebot:#ubuntu-release- New source: linux-firmware-mediatek-aiot (focal-proposed/primary) [1-0ubuntu0~20.04.1] | 10:10 | |
| -queuebot:#ubuntu-release- Unapproved: openafs (focal-proposed/universe) [1.8.4~pre1-1ubuntu2.3 => 1.8.4~pre1-1ubuntu2.4] (kernel-dkms) | 10:19 | |
| juliank | xnox: thank you | 10:23 |
| xnox | apw: please reject focal-sru Notice(queuebot): Unapproved: lttng-modules (focal-proposed/universe) [2.12.5-1ubuntu2~20.04.1 => 2.12.5-1ubuntu3~20.04.1] (kernel-dkms) => after a discussion, we now think it is a bad version number. | 10:34 |
| xnox | or any other ubuntu-sru please. | 10:34 |
| apw | xnox, looking | 10:34 |
| -queuebot:#ubuntu-release- Unapproved: rejected lttng-modules [source] (focal-proposed) [2.12.5-1ubuntu3~20.04.1] | 10:35 | |
| xnox | tah | 10:36 |
| -queuebot:#ubuntu-release- Unapproved: rtl8812au (focal-proposed/universe) [4.3.8.12175.20140902+dfsg-0ubuntu13~20.04.3 => 4.3.8.12175.20140902+dfsg-0ubuntu13~20.04.4] (kernel-dkms) | 10:43 | |
| -queuebot:#ubuntu-release- New: rejected linux-firmware-mediatek-aiot [source] (focal-proposed) [1-0ubuntu0~20.04.1] | 10:53 | |
| -queuebot:#ubuntu-release- Unapproved: rtl8821ce (focal-proposed/universe) [5.5.2.1-0ubuntu4~20.04.4 => 5.5.2.1-0ubuntu4~20.04.5] (kernel-dkms) | 10:54 | |
| -queuebot:#ubuntu-release- New source: linux-firmware-mediatek-aiot (focal-proposed/primary) [1-0ubuntu0~20.04.1] | 10:55 | |
| -queuebot:#ubuntu-release- Unapproved: lttng-modules (focal-proposed/universe) [2.12.5-1ubuntu2~20.04.1 => 2.12.5-1ubuntu2~20.04.2] (kernel-dkms) | 10:55 | |
| -queuebot:#ubuntu-release- New: accepted linux-firmware-mediatek-aiot [source] (focal-proposed) [1-0ubuntu0~20.04.1] | 10:57 | |
| -queuebot:#ubuntu-release- New binary: linux-firmware-mediatek-aiot [arm64] (focal-proposed/none) [1-0ubuntu0~20.04.1] (no packageset) | 11:00 | |
| -queuebot:#ubuntu-release- New: accepted linux-firmware-mediatek-aiot [arm64] (focal-proposed) [1-0ubuntu0~20.04.1] | 11:09 | |
| -queuebot:#ubuntu-release- Unapproved: accepted arc-theme [sync] (jammy-proposed) [20220405-1] | 11:15 | |
| -queuebot:#ubuntu-release- Unapproved: accepted libadwaita-1 [source] (jammy-proposed) [1.1.0-1ubuntu1] | 11:15 | |
| -queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (jammy-proposed) [1.21.1ubuntu2] | 11:15 | |
| -queuebot:#ubuntu-release- Unapproved: accepted zsys [source] (jammy-proposed) [0.5.9] | 11:15 | |
| -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-qxl (jammy-proposed/main) [0.1.5+git20200331-2build1 => 0.1.5+git20200331-3] (desktop-core, xorg) (sync) | 11:23 | |
| -queuebot:#ubuntu-release- Unapproved: intel-graphics-compiler (jammy-proposed/universe) [1.0.8744-3 => 1.0.10778-1] (no packageset) (sync) | 11:24 | |
| -queuebot:#ubuntu-release- Unapproved: accepted intel-graphics-compiler [sync] (jammy-proposed) [1.0.10778-1] | 11:25 | |
| xnox | thank you laney | 11:25 |
| -queuebot:#ubuntu-release- Unapproved: ubuntukylin-meta (jammy-proposed/universe) [0.45 => 0.46] (ubuntukylin) | 11:26 | |
| laney | 💋 | 11:32 |
| tjaalton | xserver-xorg-video-qxl fixes bug 1967901 | 11:53 |
| ubottu | Bug 1967901 in linux (Ubuntu) "[qxl] Xorg fails to start with 'Screen(s) found, but none have a usable configuration.'" [Undecided, Incomplete] https://launchpad.net/bugs/1967901 | 11:53 |
| -queuebot:#ubuntu-release- Unapproved: rejected openssl [source] (bionic-proposed) [1.1.1-1ubuntu2.1~18.04.16] | 13:14 | |
| -queuebot:#ubuntu-release- New source: qemu-efi-noacpi (jammy-proposed/primary) [1.0] | 13:19 | |
| -queuebot:#ubuntu-release- Unapproved: accepted ddcci-driver-linux [source] (focal-proposed) [0.3.3-1ubuntu0.1] | 13:37 | |
| -queuebot:#ubuntu-release- Unapproved: accepted iptables-netflow [source] (focal-proposed) [2.4-2ubuntu0.5] | 13:38 | |
| -queuebot:#ubuntu-release- Unapproved: adsys (jammy-proposed/main) [0.8.3 => 0.8.4] (no packageset) | 13:42 | |
| -queuebot:#ubuntu-release- Unapproved: accepted openafs [source] (focal-proposed) [1.8.4~pre1-1ubuntu2.4] | 13:46 | |
| -queuebot:#ubuntu-release- Unapproved: accepted rtl8812au [source] (focal-proposed) [4.3.8.12175.20140902+dfsg-0ubuntu13~20.04.4] | 13:49 | |
| -queuebot:#ubuntu-release- Unapproved: accepted rtl8821ce [source] (focal-proposed) [5.5.2.1-0ubuntu4~20.04.5] | 13:50 | |
| -queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-meta [source] (jammy-proposed) [0.46] | 13:57 | |
| -queuebot:#ubuntu-release- Unapproved: accepted adsys [source] (jammy-proposed) [0.8.4] | 13:58 | |
| -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-qxl [sync] (jammy-proposed) [0.1.5+git20200331-3] | 13:59 | |
| xnox | laney: cjwatson: vorlon: should we land https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1921862 https://code.launchpad.net/~laney/ubuntu-archive-publishing/updates/+merge/402698 and https://code.launchpad.net/~jibel/livecd-rootfs/+git/livecd-rootfs/+merge/402585 such that we don't suffer promotions in -updates in jammy later on, again? | 14:06 |
| ubottu | Launchpad bug 1921862 in livecd-rootfs (Ubuntu Jammy) "Call germinate with -updates" [High, Triaged] | 14:06 |
| -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (jammy-proposed/main) [2.762 => 2.763] (desktop-core, i386-whitelist) | 14:13 | |
| laney | xnox: probably needs someone to take on driving it, that MP of mine wasn't a complete fix but maybe you want to work on the problem incrementally | 14:18 |
| -queuebot:#ubuntu-release- Unapproved: ubiquity (jammy-proposed/main) [22.04.11 => 22.04.12] (ubuntu-desktop) | 14:22 | |
| xnox | laney: =( | 14:29 |
| xnox | meanwhile uploading livecd-rootfs & ubiquity to hopefully have useful and usable installers finally | 14:29 |
| juliank | I have retried all test failures on amd64 | 14:32 |
| juliank | We just moved off lcy01 and everything to lgw01, that's making sure the move worked fine | 14:32 |
| juliank | If you need to run lots of tests, let me know and I'll go cancel mine .) | 14:33 |
| -queuebot:#ubuntu-release- Unapproved: openssl (bionic-proposed/main) [1.1.1-1ubuntu2.1~18.04.15 => 1.1.1-1ubuntu2.1~18.04.16] (core) | 14:36 | |
| xnox | vorlon: sil2100: juliank: dannf_: apw: Notice(queuebot): New source: qemu-efi-noacpi (jammy-proposed/primary) [1.0] -> is a package we'd want to use in autopkgtests when testing raspi kernels; as it would allow us to manipulate and make sure scalingstack instances can reboot into raspi kernel. | 14:40 |
| juliank | +100 | 14:41 |
| xnox | it would be nice to get that into jammy; as we will eventually backport that all the way to bionic. | 14:41 |
| juliank | xnox: can we just build it in -Zxz and binary copy it everywhere? | 14:41 |
| vorlon | ahasenack: was there going to be any more work this cycle to build libnfsidmap-regex from nfs-utils? I'm processing Debian removals right now so just checking | 14:42 |
| juliank | xnox: or build it in bionic and binary copy it up | 14:42 |
| juliank | xnox: avoids work :) | 14:42 |
| vorlon | juliank: binary copy it up> no | 14:42 |
| ahasenack | vorlon: no | 14:42 |
| vorlon | you get to do that for signed bootloaders, nothing else. | 14:42 |
| -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (jammy-proposed) [2.763] | 14:42 | |
| vorlon | xnox: why is this qemu a separate source package? | 14:43 |
| -queuebot:#ubuntu-release- Unapproved: accepted ldns [source] (impish-proposed) [1.7.1-2ubuntu0.1] | 14:43 | |
| -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (jammy-proposed) [22.04.12] | 14:43 | |
| juliank | vorlon: this is a EFI shell script that runs at boot and disables ACPI, nothing else | 14:43 |
| vorlon | ok | 14:43 |
| juliank | vorlon: Well a service that installs the script :) | 14:44 |
| vorlon | why a separate source package for that? | 14:44 |
| xnox | vorlon: because it is a descriptive name and doesn't have qemu inside it. it manipulates bootnext; manipulates files on BSP; and runs a script of EFI shell. it is meant to be a small package that one can install & remove, to boot with/without acpi, upon package install/removal. | 14:44 |
| juliank | vorlon: we only need it for autopkgtest-cloud to disable ACPI on the workers for the kernels that need it | 14:44 |
| vorlon | I'd rather see this as a separate binary package built from qemu than a small Ubuntu-specific source package prone to becoming abandonware | 14:44 |
| xnox | it is separate source package, to ensure it doesn't entagle with anything; and needs to be used as trigger= for all of adt-matrix tests that are triggered by raspi kernel | 14:44 |
| vorlon | hmm | 14:45 |
| juliank | xnox: I thought we'd put this in a PPA and then enable that from autopkgtest/adt-matrix | 14:45 |
| xnox | i do not want to pull in qemu from proposed, just because a test of raspi kernel is heppening. | 14:45 |
| juliank | xnox: But I guess britney also runs raspi kernel tests itself? | 14:45 |
| vorlon | ... there's no reason it would be in -proposed | 14:45 |
| xnox | juliank: we run a lot of adt tests with and without PPAs enabled. | 14:45 |
| juliank | yes, but you could run all of them with a PPA just for this enabled, was my idea | 14:46 |
| juliank | nobody else needs this? | 14:46 |
| xnox | vorlon: the alternative of it being a package; is something that build into src:autopkgtest or like into autopkgtest-cloud; doing it as a package looks like the cleanest integration | 14:46 |
| xnox | juliank: majority of our arm kernels do not have acpi enabled. | 14:46 |
| vorlon | well if it's in autopkgtest-cloud it doesn't require SRUing to multiple series | 14:46 |
| vorlon | and if it's only used internally to autopkgtest-cloud... | 14:47 |
| xnox | vorlon: but needs engineering time of people who can change and deploy changes to autopkgtest-cloud...... | 14:47 |
| vorlon | it certainly sounds less byzantine than our existing autopkgtest-cloud code for launching VMs | 14:47 |
| xnox | which juergh & xnox are not..... and so far foundations did not resolve this issue. | 14:47 |
| vorlon | xnox: that is not a less scarce resource than SRU team | 14:47 |
| xnox | true | 14:48 |
| juliank | We did not resolve this, because it was not on our agenda, but IS to align firmware | 14:48 |
| xnox | also our scalingstack cloud is a mess with mixed host os releases; and mixed firmwares; and they failed to align firmwares | 14:48 |
| vorlon | "did not resolve this issue" - sure, because I don't think it's a priority to test per-hardware kernel flavors in autopkgtest? | 14:48 |
| xnox | it blocks all sru cycles for years now | 14:48 |
| xnox | because half of nodes, cannot run and complete linux-raspi tests | 14:48 |
| juliank | vorlon: it is, because they retry until they get swirlix and block resources | 14:49 |
| xnox | which we retry ad-infinity until they hit the right node and pass | 14:49 |
| vorlon | juliank: that sounds like a kernel team bug | 14:49 |
| xnox | which we developed a fix for | 14:49 |
| juliank | vorlon: no that's what they do because they want this tested | 14:49 |
| vorlon | because what does testing on swirlix actually tell you | 14:49 |
| juliank | vorlon: it boots on swirlix because the firmware is older and always exposes dt | 14:49 |
| xnox | because is, bootstack, openstack teams fail to make a working cloud. | 14:49 |
| vorlon | it tells you nothing about whether the package will work on raspi | 14:49 |
| xnox | vorlon: the tests execute that dkms modules build & work with raspi kernel. | 14:50 |
| juliank | there's some alignment | 14:50 |
| vorlon | xnox: is the next package going to be one that makes nodes look like Azure so that kernel has meaningful tests? | 14:50 |
| juliank | it needs to boot and the modules need to build and load | 14:50 |
| juliank | :) | 14:50 |
| juliank | we actually really ought to have one that makes it look like azure cvm | 14:50 |
| vorlon | no we shouldn't :P | 14:50 |
| xnox | vorlon: instead we changed azure kernel config to have modules to boot off virtio drives, cause we have no place to test cvm at all without it. | 14:51 |
| juliank | well nullboot should have a an autopkgtest for it :) | 14:51 |
| xnox | vorlon: as nobody is giving us secret hyperv or access to upload test images ;-) | 14:51 |
| vorlon | "& work with raspi kernel" which requires running the kernel. Having your testing rely on whether the *hardware specific* kernel boots on openstack is inherently flaky | 14:51 |
| juliank | I agree with the kernel team that this provides valuable input that DKMS modules built and modprobe successfully (?) | 14:51 |
| xnox | vorlon: i am open to remove and migrate off qemu-efi-noacpi, as soon as a better solution is available to maintain testing baseline and no go off the rail and not testing things with autopkgtests at all. | 14:52 |
| vorlon | I agree /that this is a useful thing to ensure/ | 14:52 |
| vorlon | I do not agree that autopkgtest in openstack is the right place to do this | 14:52 |
| juliank | wrt foreign kernels booting on openstack, meh | 14:52 |
| juliank | it means the kernel team needs to commit to ensure they are compatible to that extend | 14:52 |
| juliank | and they do that | 14:52 |
| xnox | vorlon: this is how currently it is enforced for all in-archive Ubuntu kernel.s | 14:52 |
| juliank | * extent | 14:52 |
| juliank | xnox: So basically we add a new magic trigger qemu-efi-noacpi/0 and then patch autopkgtest to do those changes | 14:53 |
| xnox | vorlon: we would happily test these things outside of autopkgtest infrastructure; but at the moment autopkgtests is the only way to get onto scalingstack for this; and block migrating these kernels to updates. | 14:54 |
| juliank | xnox: can you test that yourself and wrap this in a setup script you can pass to autopkgtest? | 14:54 |
| xnox | nothing else at the moment exists that catches in-archive -proposed dkms migration & kernels | 14:54 |
| juliank | then we only need to remove the fake trigger and add a --setup-script command | 14:54 |
| vorlon | xnox: it didn't block SRU migrations before | 14:55 |
| xnox | vorlon: it does today | 14:55 |
| juliank | setup-command | 14:55 |
| vorlon | ... because the kernel team has chosen to make it a blocker | 14:55 |
| xnox | .... because we were told to by release team | 14:55 |
| juliank | rightfully so | 14:55 |
| xnox | because this one time kenrel migrated without fixed dkms modules and someone noticed and didn't like it | 14:55 |
| juliank | we don't want to get another kernel breaking everyone's dkms module | 14:55 |
| juliank | xnox: "someone" | 14:56 |
| vorlon | xnox: what do you mean, "By the release team"? | 14:56 |
| vorlon | who said this? | 14:56 |
| juliank | xnox: that was when shit was all over the place, including phoronix? | 14:56 |
| vorlon | I am cross that I have seen no high-level communication about this on any mailing lists | 14:57 |
| xnox | vorlon: at the moment all kernels are always blocked via britney hints. | 14:57 |
| vorlon | I mean, britney hints mean nothing for SRUs currently, but yes | 14:58 |
| xnox | vorlon: and bot automaticlaly unblocks each kernel if all migration criteria are satified. which is adt-matrix passing; cert testing passing; regression tests passing; etc. | 14:58 |
| vorlon | yes | 14:58 |
| xnox | vorlon: in $devel it actually blocks migration; and in $stable it blocks humans releasing kernel tracker as well. | 14:58 |
| vorlon | and previously, adt-matrix absolutely would unblock kernels without requiring them to pass a boot test in a non-representative environment | 14:58 |
| xnox | at the moment for half of ubuntu kernels on arm, half of arm nodes, fail to pass the adt-matrix tests, which are retried multiple times over. | 14:58 |
| xnox | because our cloud does not provided consistent VMs across all compute nodes | 14:59 |
| juliank | IMO long term we should have custom properties, and then kernel tests can mandate custom properties | 14:59 |
| xnox | and there are no ways to enforce consistent guests unless we do something like the above package does; | 14:59 |
| juliank | but this works *now*, it's a valid workaround | 14:59 |
| xnox | or contribute engineering to openstack to generate new instance flavour types with new parameters which we would then be able to deploy and use consistently from autopkgtest-cloud | 15:00 |
| vorlon | it's a valid workaround to enable something whose fundamental sanity I continue to question | 15:00 |
| juliank | I don't think we're going to get actual hardware for autopkgtest testing and like MAAS autopkgtest support | 15:01 |
| juliank | xnox: so i think the script provided is a valid setup-commands script, so we just need to drop it into the autopkgtest-cloud tree and do the magic trigger | 15:03 |
| -queuebot:#ubuntu-release- Unapproved: corosync (focal-proposed/main) [3.0.3-2ubuntu2.1 => 3.0.3-2ubuntu2.2] (i386-whitelist, ubuntu-desktop, ubuntu-server) | 15:04 | |
| -queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal-gnome (jammy-proposed/main) [42.0.1-1ubuntu1 => 42.0.1-1ubuntu2] (no packageset) | 15:06 | |
| juliank | xnox: https://paste.ubuntu.com/p/ZjPKgn2tNP/ | 15:08 |
| juliank | oops typo at the end | 15:08 |
| juliank | Need to add apt-get install efibootmgr at the start I suppose | 15:10 |
| juliank | but otherwise, this should work | 15:10 |
| juliank | or do we want that in autopkgtest itself so people can do it locally? | 15:10 |
| juliank | I guess locally people can just pass -no-acpi | 15:10 |
| juliank | I guess some patching needed to make it exit 0 if not on EFI | 15:11 |
| juliank | but meh | 15:12 |
| -queuebot:#ubuntu-release- New source: rpiboot (jammy-proposed/primary) [0~20220131+git693d5be-0ubuntu1] | 15:13 | |
| juliank | xnox: We could also pull the script from an external repo and give you all sorts of means really, like we git pull autopkgtest-package-configs | 15:14 |
| juliank | but if at all, not now :) | 15:15 |
| xnox | juliank: yes -no-acpi is the thing that is not a toggle in nova compute guest flavours that we were discussing with juergh to proposed to openstack upstream to support configuring instance types like that. | 15:19 |
| xnox | juliank: cause like then we could have (small/medium/large)x[acpi|noacpi] configured in our cloud region; or like just the ones that autopkgtest-cloud uses in its tenant and use those directly. | 15:20 |
| xnox | it is insane that our cloud provides random instance types under the same name | 15:20 |
| xnox | juliank: but also having that thing in the archive would be useful, for people to reproduce stuff within the same VM | 15:21 |
| juliank | xnox: So I deployed the change now | 15:21 |
| juliank | xnox: So I guess one should try if that works | 15:22 |
| juliank | everything cowboy deployed in the past weeks, because duh, need to get charm store login working again | 15:23 |
| juliank | three people tried to login to the charm store, none succeeded | 15:23 |
| juliank | $ charm login | 15:23 |
| juliank | ERROR cannot retrieve the authentication macaroon: unexpected response status from server: 404 NOT FOUND | 15:24 |
| xnox | fun | 15:24 |
| xnox | juliank: that trigger thing is nice; but might actually break adt-matrix if it starts triggering raspi tests with that trigger. | 15:24 |
| xnox | cause ideally we wanted to achieve these tests without extra visible trigger, but that's still better than nothing at all. | 15:25 |
| xnox | juliank: is efibootmgr installed on images? | 15:26 |
| juliank | xnox: I added a line | 15:26 |
| juliank | xnox: apt-get install -y efibootmgr | 15:26 |
| xnox | ok , i must be looking at an old pastebin, cool. | 15:27 |
| juliank | xnox: yeah, here's the commit https://git.launchpad.net/~ubuntu-release/autopkgtest-cloud/commit/?id=c8fa2a1fe07788038b0fd2f7e5ca656e76644395 | 15:27 |
| ubottu | Commit c8fa2a1 in ~ubuntu-release/autopkgtest-cloud "Provide a magic qemu-efi-noacpi/0 trigger to disable ACPIHEADmaster" | 15:27 |
| juliank | xnox: we can remove the trigger and look it up in a file in the package-configs repo | 15:27 |
| juliank | I don't have ACL for that though, needs release team members | 15:27 |
| juliank | xnox: or we can do it for all non-default arm64 kernels, but that might not be appropriate either | 15:28 |
| juliank | xnox: But try out that trigger with one package and see if it works, and then we can think more | 15:29 |
| xnox | ack. | 15:29 |
| xnox | juliank: it's very series & kernel flavour dependend. some of these things have unique names per series too | 15:30 |
| juliank | Then we add a file `noacpi` with one kernel source package trigger per line that should use noacpi | 15:30 |
| juliank | the files you can write linux-meta-raspi/arm64/jammy or stuff | 15:30 |
| xnox | juliank: You submitted an invalid request: qemu-efi-noacpi/0 is not published in jammy | 15:39 |
| xnox | https://autopkgtest.ubuntu.com/request.cgi/?release=jammy&arch=arm64&package=bbswitch&trigger=linux-meta-raspi%2F5.15.0.1005.5&trigger=qemu-efi-noacpi/0 | 15:39 |
| juliank | xnox: ah | 15:39 |
| xnox | am i doing it wrong? | 15:39 |
| juliank | xnox: one sec | 15:39 |
| xnox | (as in it's not allowed via request.cgi? or you can fix request.cgi?) | 15:39 |
| juliank | xnox: on it | 15:42 |
| juliank | xnox: try now | 15:43 |
| xnox | it went through | 15:44 |
| xnox | but now we need to know nova status of that machine run and if it was on a good or bad node. | 15:44 |
| juliank | xnox: what package? | 15:44 |
| xnox | cause if it is successful we will not know if the setup script worked or if the node was good one anyway | 15:44 |
| xnox | juliank: i did https://autopkgtest.ubuntu.com/request.cgi/?release=jammy&arch=arm64&package=bbswitch&trigger=linux-meta-raspi%2F5.15.0.1005.5&trigger=qemu-efi-noacpi/0 | 15:44 |
| juliank | xnox: OK, it's queued now, will have to wait until it rusn | 15:45 |
| xnox | juliank: it's running host juju-4d1272-prod-proposed-migration-4 | 15:52 |
| juliank | xnox: it's krusha | 15:53 |
| juliank | oh bad substitution in the script at line 26 | 15:53 |
| juliank | shell_bootnum=$(efibootmgr | grep -E '^Boot[0-9A-F]{4}\*? +EFI Internal Shell$' || true) | 15:54 |
| juliank | shell_bootnum=${shell_bootnum:4:4} | 15:54 |
| juliank | so the 2nd line failed | 15:54 |
| juliank | xnox: ah, hmm it's run by /bin/sh instead of bash | 15:55 |
| juliank | xnox: can we port that to posix shell? | 15:55 |
| juliank | silly autopkgtest should just run the file as is | 15:56 |
| xnox | juergh: ^ | 15:56 |
| xnox | juliank: i don't know why kernel team is obsessed with bashism =) i had to fix bashism in a few places already, which was trivial and more portable. | 15:57 |
| ginggs | vorlon: btw, esys-particle and csound do appear on the python3.10-only tracker, except they are green because they built successfully | 15:57 |
| xnox | juliank: make setup script do bash -c "...." ?! =) | 15:57 |
| juliank | nah it copies over the script content | 15:57 |
| juliank | or reads the file and then does /bin/sh -c? | 15:58 |
| juliank | I don't know for sure | 15:58 |
| juliank | anyway weird | 15:58 |
| ginggs | vorlon: and fwiw, the csound autopkgtest that fails on s390x was only added recently, so never passed on s390x | 15:58 |
| juliank | xnox: Can just add `| awk '{print $1}' | tail -c +5` instead of the subst I suppose | 16:02 |
| juliank | or something | 16:03 |
| juliank | one can write this nicer | 16:03 |
| xnox | juliank: we made a package that we tested; which has autopkgtest; which works ;-) | 16:08 |
| xnox | juliank: it might be nicer to accept the package then doing porting into autopkgtest-cloud scriptage | 16:09 |
| vorlon | seb128: focal and jammy desktop dailies are both oversized; is there work to be done to bring them down? | 16:11 |
| -queuebot:#ubuntu-release- Unapproved: lto-disabled-list (jammy-proposed/main) [23 => 24] (core, i386-whitelist) | 16:12 | |
| vorlon | ginggs: oh right, another thing that makes the transition tracker useless to me ;) | 16:12 |
| juliank | xnox: meh | 16:12 |
| vorlon | paride: and ubuntu-server/ppc64el in focal; do we expect this to come back down to size? | 16:13 |
| vorlon | ginggs: so we should neuter this csound test as XFAIL on s390x? | 16:15 |
| paride | vorlon, hi, yep I saw the warning but I still have to compare the images to see what got fatter | 16:19 |
| vorlon | paride: cheers | 16:19 |
| paride | vorlon, if I conclude it's normal I'll open a MP bumping the size limit | 16:19 |
| vorlon | juliank: libjpeg8-empty which you uploaded a no-change rebuild for ain't going anywhere, it's trying to take over libjpeg-progs which is built from libjpeg9; do you want to follow through on this? | 16:20 |
| vorlon | juliank: (visible at the top of https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt) | 16:20 |
| juliank | I guess drop the package? | 16:21 |
| juliank | I don#t understand why this happens | 16:22 |
| juliank | like when libjpeg9 took over libjpeg-progs when libjpeg8-empty still also had it, it's weird | 16:22 |
| juliank | xnox: so fixed script seems to have worked, stuff ran at boot: https://paste.ubuntu.com/p/frKND8q5WZ/ | 16:25 |
| juliank | xnox: but it ran on swirlix, so need to confirm it helps on other | 16:25 |
| vorlon | juliank: because they want the binary to be built against the latest version of libjpeg, not the old one? it's allowed in the archive (both Debian and Ubuntu) for this to happen, but it's the responsibility of the maintainer of the previously-owning package to fix up the source to not build it | 16:28 |
| vorlon | so yes, drop this binary package | 16:28 |
| vorlon | (and then we'll have to NBS it out of -proposed) | 16:28 |
| juliank | ack | 16:29 |
| juliank | xnox: running on krusha now | 16:29 |
| xnox | juliank: krusha host is not known to me..... | 16:33 |
| xnox | horum. | 16:33 |
| juliank | xnox: kernel fails to boot with IRQ exception | 16:34 |
| juliank | xnox: does that ocunt as success? | 16:34 |
| xnox | is there a full log, and node details? | 16:34 |
| juliank | xnox: Endless lines of "IRQ Exception at 0x000000009BC11F38" | 16:34 |
| xnox | juliank: it should have always booted everywhere | 16:34 |
| xnox | juergh: ^^^^ | 16:34 |
| juliank | maybe there was more | 16:34 |
| xnox | juliank: but IS never told me that krusha exists, and what that is. | 16:34 |
| juliank | maybe it's a fixed buffer size in openstack and it ran over | 16:35 |
| -queuebot:#ubuntu-release- Unapproved: udisks2 (jammy-proposed/main) [2.9.4-1build1 => 2.9.4-1ubuntu1] (core, i386-whitelist) | 16:35 | |
| juliank | xnox: ok now it did boot after all | 16:35 |
| juliank | xnox: Not sure where the IRQ exception happened | 16:36 |
| juliank | xnox: Like it was before the reset I suppose, so the old kernel did not shut down cleanly or whatever? | 16:36 |
| juliank | Setting up bbswitch-dkms (0.8-10ubuntu2) ... | 16:36 |
| juliank | autoinstall for dkms modules has been disabled. | 16:36 |
| juliank | dpkg: dependency problems prevent removal of dkms: | 16:36 |
| juliank | bbswitch-dkms depends on dkms (>= 2.1.0.0). | 16:36 |
| juliank | I don't understand how this is a pass | 16:36 |
| juliank | but still | 16:36 |
| juliank | it seems to work | 16:37 |
| juliank | At least the kernel booted | 16:37 |
| juliank | tests passing with failures is not my problem :D | 16:37 |
| xnox | juliank: the dkms autopkgtest is weird; it installs the module; then tries to remove dkms; to ensure that the dkms module (directly or indirectly) has dkms specified as a dep. | 16:38 |
| xnox | such that "dependency prevents removal of dkms" is expected and good | 16:38 |
| xnox | juliank: but old kernel is generic kernel and should be working "fine" | 16:38 |
| juliank | this is also a broken qemu I think | 16:39 |
| juliank | see cRT##131118 | 16:39 |
| juliank | xnox: So I deployed this to the other cloud worker now, and the trigger should be working now, we can turn this into a file tomorrow if you can build one, in the same format that autopkgtest-package-configs has for the other files | 16:41 |
| juliank | xnox: but in this case it will apply to the trigger, so if you have | 16:41 |
| juliank | linux-meta-raspi/arm64/jammy in noacpi, it will do this hack | 16:41 |
| juliank | and so on | 16:41 |
| juliank | you can use all in some places, but there's a bug | 16:42 |
| juliank | You can't use name/all/jammy | 16:42 |
| juliank | but that should be fine | 16:42 |
| vorlon | always nice to see a flavor metapackage in the archive that ./update fails on because update.cfg references jammy | 16:42 |
| juliank | (really ought to fix architecture wildcard + fixed release) | 16:43 |
| xnox | juliank: i think it is a success! | 16:43 |
| juliank | xnox: anyway I think that wraps up my day | 16:43 |
| xnox | juliank: thank you. | 16:44 |
| vorlon | juliank: not following closely, does the above mean the qeme-efi-noacpi package doesn't need accepted? | 16:44 |
| juliank | vorlon: yes, we now have a fake qeme-efi-noacpi/0 trigger (soon probably a list file of kernel packages rather than trigger) | 16:44 |
| vorlon | ok | 16:45 |
| vorlon | (hopefully soon; putting this in the trigger, blech) | 16:45 |
| juliank | with the package it would have been a trigger as well :) | 16:46 |
| vorlon | blechblech | 16:46 |
| xnox | vorlon: well, not a single person in the world will be able to discover or use the magic qemu-efi-noacpi trigger. | 16:55 |
| xnox | vorlon: so strictly it's not needed in the archive, but also not sure how to ensure people know about it. | 16:55 |
| cjwatson | juliank: charm login> the old charmstore became read-only - you'll need to use charmcraft and upload to charmhub | 16:55 |
| vorlon | xnox: I'm not worried about accidental usage, I'm bleching at the abuse of the trigger interface for this. The cleanup juliank describes would make me happy | 16:55 |
| xnox | =)))))))))))) | 16:56 |
| xnox | i would prefer the file-based-trigger to simply install package from the archive. | 16:56 |
| vorlon | mm | 16:56 |
| xnox | rather than do magic out of the blue from built-in source code but that's just me. | 16:56 |
| xnox | i have no opinion about that either. | 16:56 |
| xnox | i just fear that this thing will break whenever cloud gets upgrades. | 16:57 |
| xnox | but should be mostly harmless. | 16:57 |
| xnox | so like not break anything; but like stop making things happen. | 16:57 |
| ginggs | vorlon: yes, we could neuter the test, or hint it for now and i'll file a bug in debian | 16:57 |
| ginggs | would someone please accept lto-disabled-list/24 ? | 16:58 |
| vorlon | ginggs: given that the package previously had passing autopkgtests on s390x, which improves our quality coverage, my preference is always to neuter the test where feasible and keep it green | 16:58 |
| vorlon | looking | 16:58 |
| vorlon | ginggs: gyoto is making me angry btw. Something somewhere is embedding dpkg-buildflags output into a binary and using that when invoking g++ and then failing, and it's largely inscrutable | 16:59 |
| juliank | cjwatson: ugh, hopefully that's not a lot of work | 16:59 |
| juliank | The endless cycle of Migrate to new stuff, new stuff gets deprecated | 17:00 |
| vorlon | welcome to software engineering? :) | 17:01 |
| cjwatson | juliank: https://discourse.charmhub.io/t/charmhub-transition-faq/5636 may help | 17:03 |
| juliank | thanks cjwatson | 17:09 |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (jammy-proposed/universe) [0.91 => 0.92] (no packageset) | 17:17 | |
| -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (jammy-proposed) [0.92] | 17:18 | |
| -queuebot:#ubuntu-release- New: rejected qemu-efi-noacpi [source] (jammy-proposed) [1.0] | 17:28 | |
| vorlon | ginggs: so, lto-disabled-list; I'm surprised to see additions here as my understanding was this list was meant to be short-term and that further packages should be handled via debian/rules overrides, NOT via additions to this list | 17:29 |
| vorlon | ginggs: I can accept this now because it's not really all that material, but I'd like to make sure folks get on the same page wrt the correct practice here | 17:30 |
| vorlon | (cc: doko) | 17:30 |
| ginggs | i understood packages in universe should be added to lto-disabled-list | 17:30 |
| vorlon | why would it be different for universe? | 17:31 |
| ginggs | i imagine to reduce the maintenance burden of keeping the delta | 17:31 |
| -queuebot:#ubuntu-release- Unapproved: accepted lto-disabled-list [source] (jammy-proposed) [24] | 17:31 | |
| ginggs | https://wiki.ubuntu.com/ToolChain/LTO | 17:32 |
| ginggs | disclaimer, i wrote part of that page :) | 17:32 |
| vorlon | ginggs: right lol, I was just looking at the history because I had never seen this before and find that you added i | 17:33 |
| vorlon | t | 17:33 |
| vorlon | so I don't think it's part of what was communicated on ubuntu-devel | 17:33 |
| vorlon | if you and doko agree that this is the right thing to do, please communicate this change on ubuntu-devel | 17:34 |
| vorlon | also please clarify if it is *expected* that universe packages are only handled via lto-disabled-list or if it's optional | 17:34 |
| Eickmeyer | ginggs: I have questions on that. I have a package (carla) that I disabled the LTO on in d/rules because otherwise the binary crashes. Should this be added to the lto-disabled-list? | 17:36 |
| vorlon | tjaalton: hi, gonna need some additional documentation here for xf86-input-wacom jumping from upstream 0.39.0 to 1.0.0 post-FF including extensive changes to the debian packaging dir | 17:36 |
| ginggs | vorlon: ack, i'll discuss with doko about an announcement | 17:36 |
| vorlon | Eickmeyer: you only need to do one or the other, and see my question above wrt how strongly we want to encourage use of the lto-disabled-list package: ) | 17:37 |
| vorlon | ginggs: ta | 17:37 |
| Eickmeyer | vorlon: Thanks, good to know. Just wanted to cover my bases. | 17:37 |
| ginggs | Eickmeyer: carla is an ubuntu-only package, so i wouldn't put it in lto-disabled-list | 17:37 |
| ginggs | lto-disabled-list is to allow syncs from debian | 17:38 |
| Eickmeyer | ginggs: Thanks. There have been mentions of getting it in Debian, but so far nobody has done it or been brave enough. :) | 17:38 |
| tjaalton | vorlon: upstream jumped from 0.40 to 1.0 | 17:44 |
| tjaalton | vorlon: I can file an ffe tomorrow | 17:44 |
| vorlon | tjaalton: thanks | 18:01 |
| tjaalton | vorlon: feel free to reject, I'll amend the changelog with the bug# | 18:03 |
| -queuebot:#ubuntu-release- Unapproved: rejected xf86-input-wacom [source] (jammy-proposed) [1:1.0.0-3ubuntu1] | 18:05 | |
| seb128 | ginggs, why wouldn't the 'being able to sync from Debian is better' apply to main also? it is weird that the list is restricted to universe | 18:12 |
| vorlon | doko, ginggs: fyi the lack of an unversioned libgcc-dev (real or virtual) leads to things like intel-mkl hard-coding a test dep on libgcc-8-dev | libgcc-7-dev | libgcc-6-dev... | 18:15 |
| -queuebot:#ubuntu-release- Unapproved: intel-mkl (jammy-proposed/multiverse) [2020.4.304-2ubuntu1 => 2020.4.304-2ubuntu2] (no packageset) | 18:17 | |
| -queuebot:#ubuntu-release- Unapproved: accepted intel-mkl [source] (jammy-proposed) [2020.4.304-2ubuntu2] | 18:18 | |
| vorlon | jbicha: wpewebkit has versioned -dev package names (blech) and the reverse-dependencies don't appear to have been updated for this new upstream version you synced from experimental; please follow this through | 18:21 |
| jbicha | thanks | 18:22 |
| seb128 | I've pinged a few time in the past week about that but could someone review https://bugs.launchpad.net/ubuntu/+source/libarchive/+bug/1967127 ? | 18:26 |
| ubottu | Launchpad bug 1967127 in libarchive (Ubuntu) "[FFe] update libarchive to 3.6.0" [Undecided, New] | 18:26 |
| vorlon | seb128: looking | 18:26 |
| seb128 | it has been waiting for more than a week, which makes a difference in testing at this point of the cycle | 18:26 |
| seb128 | also unsure how or where to raise the issue about FFe reviews delays but it's really an issue imho | 18:27 |
| seb128 | vorlon, thanks | 18:27 |
| vorlon | seb128, jbicha: there are two upstream links provided for "changes" here; the first is a reasonably-compact summary, the second is a git log that I'm not going to attempt to read. Is there anything that could bite me as a result of *not* reading that? | 18:28 |
| seb128 | vorlon, I've reviewed the commits, though not in details, and I didn't spot anything concerning. Also the new version is in Debian testing now and no issue has been reported if that helps getting some confidence | 18:29 |
| * vorlon nods | 18:30 | |
| vorlon | cpaelzer: why does LP: #1953363 have an 'in progress' python-xmlschema task and an ubuntu-archive subscription? You appear to have promoted it to main already | 18:32 |
| ubottu | Launchpad bug 1953363 in python-xmlschema (Ubuntu) "[MIR] python-xmlschema, elementpath, importlib-resources" [High, In Progress] https://launchpad.net/bugs/1953363 | 18:32 |
| seb128 | vorlon, thanks | 18:32 |
| ginggs | seb128: i don't know the reason why lto-disabled-list was originally populated with packages not in main, but i'll try to get clarity and include it in the mail to ubuntu-devel | 18:41 |
| seb128 | thanks | 18:44 |
| knome | hello! it's super late in the cycle, but we really would like to upload a new wallpaper for xubuntu. i wonder if anybody from the release team could ack that for us, so we could get it uploaded asap. the freeze exception bug is here: https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1967940 | 19:27 |
| ubottu | Launchpad bug 1967940 in xubuntu-artwork (Ubuntu) "[UIFe] Xubuntu wallpaper for 22.04" [Undecided, New] | 19:27 |
| knome | bluesabre, ^ | 19:29 |
| -queuebot:#ubuntu-release- Unapproved: gudhi (jammy-proposed/universe) [3.5.0+dfsg-1ubuntu1 => 3.5.0+dfsg-1ubuntu2] (no packageset) | 19:30 | |
| -queuebot:#ubuntu-release- Unapproved: accepted gudhi [source] (jammy-proposed) [3.5.0+dfsg-1ubuntu2] | 19:31 | |
| knome | stgraber, *cough* ... hello? :) | 19:52 |
| -queuebot:#ubuntu-release- Unapproved: libadwaita-1 (jammy-proposed/main) [1.1.0-1ubuntu1 => 1.1.0-1ubuntu2] (no packageset) | 20:05 | |
| vorlon | jbicha: also, something is wonky with this package because the wpewebkit binaries are not showing up on https://people.canonical.com/~ubuntu-archive/nbs.html, have they done something horrible like continuing to list the packages in debian/control? | 20:37 |
| -queuebot:#ubuntu-release- Unapproved: pacemaker (focal-proposed/main) [2.0.3-3ubuntu4.3 => 2.0.3-3ubuntu4.4] (i386-whitelist, ubuntu-desktop, ubuntu-server) | 20:38 | |
| jbicha | vorlon: webkit is built twice, once for the libsoup2 API and once for the libsoup3 API 😒 | 20:39 |
| -queuebot:#ubuntu-release- Unapproved: intel-mkl (jammy-proposed/multiverse) [2020.4.304-2ubuntu2 => 2020.4.304-2ubuntu3] (no packageset) | 20:39 | |
| -queuebot:#ubuntu-release- Unapproved: accepted intel-mkl [source] (jammy-proposed) [2020.4.304-2ubuntu3] | 20:40 | |
| vorlon | jbicha: that does not explain to me why https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt correctly identifies libwpewebkit-1.0-dev and libwpewebkit-1.0-3 as not built from the current source package and therefore are candidates for removal, but https://people.canonical.com/~ubuntu-archive/nbs.html does not show this. That normally only happens if there are errors | 20:40 |
| vorlon | in debian/control | 20:40 |
| jbicha | ok, let me read more carefully | 20:40 |
| vorlon | $ grep Package: debian/control | 20:41 |
| vorlon | Package: libwpewebkit-1.0-dev | 20:41 |
| vorlon | Package: libwpewebkit-1.1-dev | 20:41 |
| vorlon | Package: libwpewebkit-1.0-3 | 20:41 |
| vorlon | Package: libwpewebkit-1.1-0 | 20:41 |
| vorlon | Package: wpewebkit-driver | 20:41 |
| vorlon | Package: libwpewebkit-1.0-doc | 20:41 |
| vorlon | yep | 20:41 |
| vorlon | this is wrong | 20:41 |
| jbicha | it's very creative packaging | 20:43 |
| vorlon | well that's a red flag | 20:43 |
| vorlon | ;) | 20:43 |
| jbicha | I don't need or want the libsoup3 versions in jammy so I think I ought to just enable the libsoup2 version and simplify the packaging for jammy | 20:44 |
| jbicha | not sure if the creative stuff is useful for Debian or not | 20:45 |
| -queuebot:#ubuntu-release- Unapproved: wpewebkit (jammy-proposed/universe) [2.36.0-2ubuntu2 => 2.36.0-2ubuntu3] (no packageset) | 20:53 | |
| -queuebot:#ubuntu-release- Unapproved: accepted wpewebkit [source] (jammy-proposed) [2.36.0-2ubuntu3] | 20:54 | |
| vorlon | waveform, jawn-smith: rpiboot - how does this relate to "piboot" we've discussed before which is the onboard firmware? I.e. why do these binary blobs need to be shipped in the Ubuntu archive? | 21:12 |
| jawn-smith | vorlon: rpiboot isn't a bootloader, but is rather a utility to put compute modules into MSD mode for flashing and configuring secure boot on compatible Pi 4 devices | 21:16 |
| knome | vorlon, thank you! | 21:19 |
| vorlon | waveform, jawn-smith: there's a GPL license file in the source but this license is not mentioned in debian/copyright | 21:19 |
| vorlon | (win32/LICENSE.txt) | 21:20 |
| waveform | vorlon, that's for the cygwin bits they're shipping in their windows output to get rpiboot working there but none of that ever winds up in the binary packages we produce -- does that still require mentioning in d/copyright? | 21:24 |
| vorlon | waveform: according to Debian policy it does, because debian/copyright is a description of the rights on the source package, not the binary packages | 21:33 |
| waveform | right, I'll get on with it | 21:37 |
| -queuebot:#ubuntu-release- New sync: hyperspy (jammy-proposed/primary) [1.6.1-1] | 23:28 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!