| -queuebot:#ubuntu-release- New binary: mrtrix3 [amd64] (focal-proposed/universe) [3.0~rc3+git135-g2b8e7d0c2-4] (no packageset) | 00:14 | |
| ddstreet | vorlon updated sru template for lp #1845909 and added comment re: patch 1 | 01:30 |
|---|---|---|
| ubot5 | Launchpad bug 1845909 in systemd (Ubuntu Focal) "[SRU] IPv6 link local address is assigned even when LinkLocalAddressing=no|ipv4" [Medium,In progress] https://launchpad.net/bugs/1845909 | 01:30 |
| doko | vorlon: I'll pick itup | 05:41 |
| === paride6 is now known as paride | ||
| doko | vorlon: please build ruby2.7 for i386 as well, or it will block the transition | 05:43 |
| vorlon | doko: added to the packageset; getting it built requires either a reupload of ruby2.7 or whatever magic infinity does to create a build record for it after the fact | 06:15 |
| vorlon | infinity: ^^ want to build ruby2.7/i386? | 06:15 |
| doko | I'll re-upload | 06:15 |
| vorlon | ok | 06:15 |
| -queuebot:#ubuntu-release- Packageset: Added libregexp-pattern-perl to i386-whitelist in focal | 06:39 | |
| -queuebot:#ubuntu-release- Packageset: Added ruby2.7 to i386-whitelist in focal | 06:39 | |
| mwhudson | vorlon: isn't the magic to get a build record just copying it over itself? | 07:26 |
| === bdmurray_ is now known as bdmurray | ||
| -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (bionic-proposed) [1.8+18.04ubuntu2] | 07:59 | |
| infinity | mwhudson: That might also work, but wasn't the magic he was referring to (LP has an internal DB-level script to check for missing builds and create them) | 08:20 |
| mwhudson | ah ok | 08:26 |
| -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-76.86~16.04.1] | 09:05 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-76.86~16.04.1] | 09:05 | |
| RikMills | Laney: if a test trigger is in main, but the package to be tested in in Kubuntu packageset, then I should be able to run the test/retry yes? | 09:10 |
| * apw thinks it is in 'or', if you can upload either one you can test that combination | 09:11 | |
| -queuebot:#ubuntu-release- New binary: rustc [s390x] (focal-proposed/universe) [1.39.0+dfsg1+llvm-3ubuntu1] (i386-whitelist) | 09:11 | |
| RikMills | if so, does the same go for trigger = main package = universe for someone with MOTU? | 09:11 |
| RikMills | because that is refused ^ | 09:11 |
| RikMills | which seem illogical | 09:12 |
| Laney | https://git.launchpad.net/autopkgtest-cloud/tree/webcontrol/request/submit.py#n120 | 09:13 |
| Laney | that's the code to do it | 09:13 |
| RikMills | Laney: not ANDs to refuse, so looks like you should be blocked only if you can't upload both? | 09:15 |
| Laney | right | 09:16 |
| RikMills | if so, that isn't working for my MOTU permissions in universe | 09:16 |
| Laney | what is the message you see? | 09:17 |
| RikMills | "You submitted an invalid request: You are not allowed to upload openscad or mesa to Ubuntu, thus you are not allowed to use this service." | 09:18 |
| RikMills | ^ just an example. I know that test is futile to try | 09:18 |
| -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.37 => 2.525.38] (desktop-core) | 09:25 | |
| -queuebot:#ubuntu-release- New binary: linux-signed-5.4 [ppc64el] (focal-proposed/main) [5.4.0-12.15] (no packageset) | 09:26 | |
| -queuebot:#ubuntu-release- New binary: linux-signed-5.4 [s390x] (focal-proposed/main) [5.4.0-12.15] (no packageset) | 09:26 | |
| -queuebot:#ubuntu-release- New binary: linux-signed-5.4 [amd64] (focal-proposed/main) [5.4.0-12.15] (no packageset) | 09:27 | |
| -queuebot:#ubuntu-release- New binary: linux-signed-5.4 [arm64] (focal-proposed/main) [5.4.0-12.15] (no packageset) | 09:27 | |
| Laney | ah, I see it | 09:27 |
| * apw waits in anticipation | 09:28 | |
| * RikMills also | 09:29 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed-5.4 [amd64] (focal-proposed) [5.4.0-12.15] | 09:29 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed-5.4 [ppc64el] (focal-proposed) [5.4.0-12.15] | 09:29 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed-5.4 [arm64] (focal-proposed) [5.4.0-12.15] | 09:29 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed-5.4 [s390x] (focal-proposed) [5.4.0-12.15] | 09:29 | |
| Laney | maybe I'll let you figure it out first :-) | 09:30 |
| -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.38] | 09:32 | |
| RikMills | grrr | 09:33 |
| apw | Laney, component | 09:35 |
| RikMills | component = self.is_valid_package_version(release, trigsrc, trigver) | 09:38 |
| RikMills | apw that? | 09:38 |
| apw | RikMills, that is uses that component for both can_upload checks, not the appropriate one for the package | 09:38 |
| apw | RikMills, so if your permissions are in universe and the trigger is in main, it checks if you can upload your package in main and you cannot | 09:39 |
| RikMills | apw: but if in kubuntu set one of the last 2 conditions allows it? | 09:40 |
| Laney | YEP! | 09:43 |
| Laney | APW GOT IT! | 09:43 |
| apw | RikMills, nope neither of those is related to packagesets, they are both local relaxations | 09:44 |
| Laney | also the check with relation to trigsrc is kind of shonky | 09:44 |
| Laney | it only checks the last of them or something | 09:44 |
| -queuebot:#ubuntu-release- New binary: rustc [ppc64el] (focal-proposed/universe) [1.39.0+dfsg1+llvm-3ubuntu1] (i386-whitelist) | 09:47 | |
| RikMills | Laney: it has in no way been a huge issue, just puzzling. so I thought before Xmas I would bring it up in the new year :) | 09:53 |
| apw | RikMills, i've see the complaint in various forms and people bodge round it and it gets forgotten; so good you did | 09:54 |
| Laney | https://paste.debian.net/1127081/ review pls | 10:09 |
| mwhudson | Laney: "We're" i assume? | 10:13 |
| Laney | yup | 10:14 |
| mwhudson | that's enough being helpful for tonight | 10:14 |
| * mwhudson goes to bed | 10:14 | |
| Laney | thanks :> | 10:15 |
| apw | Laney, is there not an |= operator ... | 10:16 |
| cjwatson | Why is it doing component checka at all, rather than using LP's "can this person upload this package" API? | 10:17 |
| cjwatson | disclaimer: haven't actually read the code, just that diff | 10:18 |
| cjwatson | also *checks | 10:18 |
| Laney | it's using checkUpload but passing that a component parameter | 10:18 |
| Laney | apw: that doesn't appear to do short circuiting | 10:18 |
| apw | Laney, oh how stupid :) | 10:19 |
| cjwatson | ah ok | 10:19 |
| apw | Laney, then given the code it looks ok to me | 10:19 |
| Laney | mmm, comopnent appears to be required | 10:20 |
| * apw wonders what the default for strict_component is and what it does :) | 10:20 | |
| cjwatson | bit peculiar that component is required | 10:20 |
| cjwatson | strict_component: defaults to true, and https://git.launchpad.net/launchpad/tree/lib/lp/soyuz/interfaces/archive.py#n888 | 10:23 |
| apw | so junk in component and strict_component=False might work | 10:26 |
| apw | not sure if you could supply component as None, that might might also work to my reading | 10:27 |
| cjwatson | The webservice interface won't allow it at the moment. I think it would probably be correct to change the interface so that it does allow component=None, and that that would be an improvement | 10:29 |
| cjwatson | Somebody should probably file a bug :) | 10:29 |
| apw | cjwatson, will do :) | 10:29 |
| apw | cjwatson, against launchpad itself i assume | 10:29 |
| cjwatson | yes please | 10:29 |
| Laney | thanks | 10:29 |
| Laney | I'll subscribe and we can fix this if and when that happens | 10:30 |
| apw | i assume this thing really should be using devel not 1.0 | 10:30 |
| cjwatson | yes | 10:30 |
| Laney | ideally | 10:30 |
| cjwatson | the versioning system never worked very well, and it doesn't make sense at all for things that aren't hard to update | 10:31 |
| cjwatson | not that we're in the habit of making API-breaking changes even in devel | 10:31 |
| Laney | RikMills: that should be updated now | 10:31 |
| -queuebot:#ubuntu-release- Unapproved: mesa (eoan-proposed/main) [19.2.1-1ubuntu1 => 19.2.8-0ubuntu0~19.10.1] (core, xorg) | 10:31 | |
| apw | always add new better apis and migrate people to them ... stylee | 10:31 |
| Laney | if someone wants to contribute... :))) | 10:33 |
| apw | https://bugs.launchpad.net/launchpad/+bug/1860533 | 10:35 |
| ubot5 | Ubuntu bug 1860533 in Launchpad itself "archive.checkUpload() should allow component to be None" [Undecided,New] | 10:35 |
| RikMills | Laney: thank you :) | 10:35 |
| -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (bionic-proposed/restricted) [390.116-0ubuntu0.18.04.2 => 390.116-0ubuntu0.18.04.3] (ubuntu-desktop) | 10:53 | |
| -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-390 [source] (bionic-proposed) [390.116-0ubuntu0.18.04.3] | 10:59 | |
| -queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1036.41] (no packageset) | 11:13 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1036.41] | 11:21 | |
| -queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [19.2.1-1ubuntu1~18.04.1 => 19.2.8-0ubuntu0~18.04.1] (core, xorg) | 11:22 | |
| sil2100 | tjaalton: hey! The new mesa ^ is that also for .4? | 11:37 |
| tjaalton | sil2100: your call. they are bugfix releases, and there was a radeonsi regression filed where an opencl app no longer works, so I'll ask him to try a ppa upload first | 11:39 |
| tjaalton | "they".. it's the same release, but anyway | 11:40 |
| tjaalton | it's the last of the series, released last week | 11:40 |
| tjaalton | huh no, is older | 11:41 |
| tjaalton | sil2100: but the ati/amdgpu fix has been verified, maybe fine to fast-track it to updates? | 11:46 |
| tjaalton | it/them | 11:46 |
| sil2100 | tjaalton: yeah, will fast-track those - and I'll take a look at mesa and see if maybe we can stuff it in as well | 11:47 |
| tjaalton | I've pushed mesa to the x-updates ppa to get community testing too | 11:48 |
| -queuebot:#ubuntu-release- New binary: rustc [i386] (focal-proposed/universe) [1.39.0+dfsg1+llvm-3ubuntu1] (i386-whitelist) | 11:55 | |
| -queuebot:#ubuntu-release- Packageset: Added linux-5.4 to kernel in focal | 12:09 | |
| -queuebot:#ubuntu-release- Packageset: Added linux-meta-5.4 to kernel in focal | 12:09 | |
| -queuebot:#ubuntu-release- Packageset: Added linux-restricted-modules-5.4 to kernel in focal | 12:09 | |
| -queuebot:#ubuntu-release- Packageset: Added linux-signed-5.4 to kernel in focal | 12:09 | |
| Laney | think I figured out the gscan2pdf/arm64 hanging problem (autopkgtest-cloud side, *not* the problem in the package) | 12:19 |
| -queuebot:#ubuntu-release- New binary: rustc [amd64] (focal-proposed/universe) [1.39.0+dfsg1+llvm-3ubuntu1] (i386-whitelist) | 12:21 | |
| tjaalton | Laney: oh? | 12:56 |
| Laney | some stupid interaction with timeouts | 12:57 |
| Laney | someone is still going to need to poke at why it started hanging in the build though | 12:57 |
| -queuebot:#ubuntu-release- Unapproved: horizon (eoan-proposed/main) [3:16.0.0-0ubuntu1 => 3:16.0.0-0ubuntu1.1] (openstack, ubuntu-server) | 13:45 | |
| -queuebot:#ubuntu-release- New binary: rustc [arm64] (focal-proposed/universe) [1.39.0+dfsg1+llvm-3ubuntu1] (i386-whitelist) | 13:55 | |
| -queuebot:#ubuntu-release- New: accepted pop-gtk-theme [source] (focal-proposed) [5.0.0~1576602011~19.10~7760154~ubuntu1] | 14:01 | |
| RAOF | Wow, you weren't lying when you said it had a weird version. | 14:02 |
| -queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.21 => 1:2.11+dfsg-1ubuntu7.22] (ubuntu-server, virt) | 14:03 | |
| -queuebot:#ubuntu-release- Unapproved: qemu (eoan-proposed/main) [1:4.0+dfsg-0ubuntu9.2 => 1:4.0+dfsg-0ubuntu9.3] (ubuntu-server, virt) | 14:03 | |
| -queuebot:#ubuntu-release- New binary: pop-gtk-theme [amd64] (focal-proposed/universe) [5.0.0~1576602011~19.10~7760154~ubuntu1] (no packageset) | 14:03 | |
| -queuebot:#ubuntu-release- New binary: rustc [armhf] (focal-proposed/universe) [1.39.0+dfsg1+llvm-3ubuntu1] (i386-whitelist) | 14:09 | |
| doko | please could you have a look at libuv1/i386 ? | 14:11 |
| rbalint | sil2100, could you please merge that? https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/377891 | 14:14 |
| LocutusOfBorg | can any AA please remove fw4spl from the archive? removed in debian, #948369 | 14:25 |
| LocutusOfBorg | https://bugs.debian.org/948369 | 14:25 |
| ubot5 | Debian bug 948369 in ftp.debian.org "RM: fw4spl -- ROM; fw4spl is replaced by sight" [Serious,Open] | 14:25 |
| tjaalton | sil2100: another one to fast-track is nvidia-390, which now builds against 5.3 and is verified | 14:32 |
| -queuebot:#ubuntu-release- New binary: vcversioner [amd64] (focal-proposed/universe) [2.16.0.0-2ubuntu1] (no packageset) | 14:44 | |
| -queuebot:#ubuntu-release- New: accepted mrtrix3 [amd64] (focal-proposed) [3.0~rc3+git135-g2b8e7d0c2-4] | 14:48 | |
| -queuebot:#ubuntu-release- New: accepted rustc [amd64] (focal-proposed) [1.39.0+dfsg1+llvm-3ubuntu1] | 14:48 | |
| -queuebot:#ubuntu-release- New: accepted rustc [armhf] (focal-proposed) [1.39.0+dfsg1+llvm-3ubuntu1] | 14:48 | |
| -queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (focal-proposed) [1.39.0+dfsg1+llvm-3ubuntu1] | 14:48 | |
| -queuebot:#ubuntu-release- New: accepted vcversioner [amd64] (focal-proposed) [2.16.0.0-2ubuntu1] | 14:48 | |
| -queuebot:#ubuntu-release- New: accepted pop-gtk-theme [amd64] (focal-proposed) [5.0.0~1576602011~19.10~7760154~ubuntu1] | 14:48 | |
| -queuebot:#ubuntu-release- New: accepted rustc [i386] (focal-proposed) [1.39.0+dfsg1+llvm-3ubuntu1] | 14:48 | |
| -queuebot:#ubuntu-release- New: accepted rustc [arm64] (focal-proposed) [1.39.0+dfsg1+llvm-3ubuntu1] | 14:48 | |
| -queuebot:#ubuntu-release- New: accepted rustc [s390x] (focal-proposed) [1.39.0+dfsg1+llvm-3ubuntu1] | 14:48 | |
| sil2100 | tjaalton: sure | 14:56 |
| sil2100 | rbalint: looking | 14:56 |
| -queuebot:#ubuntu-release- New binary: cctools [amd64] (focal-proposed/universe) [7.0.9-5ubuntu1] (no packageset) | 15:26 | |
| -queuebot:#ubuntu-release- New binary: cctools [s390x] (focal-proposed/universe) [7.0.9-5ubuntu1] (no packageset) | 15:26 | |
| -queuebot:#ubuntu-release- New binary: cctools [ppc64el] (focal-proposed/universe) [7.0.9-5ubuntu1] (no packageset) | 15:26 | |
| -queuebot:#ubuntu-release- New binary: cctools [arm64] (focal-proposed/universe) [7.0.9-5ubuntu1] (no packageset) | 15:27 | |
| -queuebot:#ubuntu-release- New binary: cctools [armhf] (focal-proposed/universe) [7.0.9-5ubuntu1] (no packageset) | 15:27 | |
| -queuebot:#ubuntu-release- New: rejected pop-icon-theme [source] (focal-proposed) [2.1.0~1571158475~19.10~6bf9347~ubuntu1] | 15:30 | |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-meta (bionic-proposed/main) [1.417.3 => 1.417.4] (core) | 15:32 | |
| sil2100 | rbalint: hey! I'll be doing a few SRU reviews for bionic, mostly things useful for .4 | 15:39 |
| Laney | sil2100: ubuntu-meta is for .4 | 15:40 |
| Laney | and I was wondering how much of https://launchpadlibrarian.net/461682085/ubuntu-settings_19.10.4_20.04.1.diff.gz I should upload as SRU | 15:41 |
| Laney | definitely the .gsettings-override change, but how much of the rest? | 15:41 |
| -queuebot:#ubuntu-release- New: accepted cctools [amd64] (focal-proposed) [7.0.9-5ubuntu1] | 15:42 | |
| -queuebot:#ubuntu-release- New: accepted cctools [armhf] (focal-proposed) [7.0.9-5ubuntu1] | 15:42 | |
| -queuebot:#ubuntu-release- New: accepted cctools [s390x] (focal-proposed) [7.0.9-5ubuntu1] | 15:42 | |
| -queuebot:#ubuntu-release- New: accepted cctools [arm64] (focal-proposed) [7.0.9-5ubuntu1] | 15:42 | |
| -queuebot:#ubuntu-release- New: accepted cctools [ppc64el] (focal-proposed) [7.0.9-5ubuntu1] | 15:42 | |
| sil2100 | Laney: ACK o/ | 15:45 |
| sil2100 | rbasak: uh, by accident I pinged rbalint, so let me re-ping properly | 15:48 |
| sil2100 | rbasak: hey! I'll be doing a few SRU reviews for bionic, mostly things useful for .4 | 15:48 |
| sil2100 | If you don't mind | 15:48 |
| sil2100 | For now I'm looking at mesa and ubuntu-meta | 15:49 |
| rbasak | sil2100: sure, plase do. The only SRU-related item I've managed so far is to look at u-boot for Dave but I want to check with someone else (infinity?) on some details | 15:50 |
| rbasak | dpkg triggers, Breaks, etc. | 15:50 |
| Laney | for bionic, maybe I should just upload the default setting change and leave the package around | 15:51 |
| -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (eoan-proposed) [19.2.8-0ubuntu0~19.10.1] | 15:52 | |
| -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (bionic-proposed) [19.2.8-0ubuntu0~18.04.1] | 15:53 | |
| sil2100 | rbasak: thanks, the u-boot SRU is critical for .4, without it the whole pi4 story can't move forward - maybe vorlon could also help in case infinity is not around? | 15:53 |
| Laney | sil2100: going to upload https://paste.ubuntu.com/p/NHzBJNm3dB/ I think - making an empty binary package, hope that's ok | 16:21 |
| Laney | feels safer than dropping it or conflicting it off or anything like that | 16:21 |
| sil2100 | Laney: ah, so meta drops it from the new images, but for existing users it would simply be changed to an empty binary package, yes? | 16:23 |
| Laney | right | 16:23 |
| Laney | if update-manager works nicely it should be presented as a candidate for autoremoval too, but would be ideal not to rely on that | 16:23 |
| sil2100 | Not a big fan of empty binary packages, but considering how many moving parts are in this SRU, I'm more than happy to pick this safe option | 16:23 |
| sil2100 | ;) | 16:23 |
| Laney | great, thanks | 16:23 |
| -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (bionic-proposed) [1.417.4] | 16:25 | |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-settings (bionic-proposed/main) [18.04.6 => 18.04.7] (ubuntu-desktop) | 16:26 | |
| Laney | ok there's the other half | 16:27 |
| Laney | see you o/ | 16:27 |
| sil2100 | Thanks, will look at it in a moment | 16:29 |
| vorlon | mwhudson: unfortunately no | 16:35 |
| sil2100 | rbasak: hey! Did you get the necessary clarification regarding u-boot? | 16:41 |
| rbasak | sil2100: I'm still waiting to talk to someone, but otp right now | 16:43 |
| rbasak | infinity: around? | 16:43 |
| rbasak | I assume vorlon is unavailable to chat? | 16:43 |
| sil2100 | vorlon: hey! Do you have a moment by any chance? Robie would need to consult the u-boot packaging with someone experienced, it's critical for our pi4 .4 story | 16:46 |
| vorlon | sil2100, rbasak: should I just review it myself? I've got a couple of other things in flight at the moment so I can't look at it just this moment but I should be able to get to it this morning | 17:01 |
| rbasak | I'm fine with that | 17:01 |
| rbasak | https://git.launchpad.net/~waveform/ubuntu/+source/u-boot/log/?h=bionic-sru-pi4 and https://git.launchpad.net/~waveform/ubuntu/+source/u-boot/log/?h=focal-sru-pi4 | 17:02 |
| vorlon | ah so this is still for sponsorship, it's not in the queue yet for SRU review? | 17:03 |
| rbasak | My concern is the upgrade path from Bionic to Focal, the dpkg trigger, the Breaks, and how flash-kernel is supposed to be invoked. | 17:03 |
| rbasak | Correct | 17:03 |
| rbasak | sil2100: my understanding is that someone also needs to do the SRU review? | 17:03 |
| rbasak | It may be that a bunch of use cases I'm concerned about don't need to be maintained | 17:03 |
| rbasak | One problem is that this is all unclear | 17:03 |
| rbasak | But AFAICT, since u-boot-rpi doesn't depend on flash-kernel, the postinst can't rely on it being present | 17:04 |
| vorlon | true | 17:04 |
| rbasak | And even with a Breaks, that might mean that during upgrade from Bionic to Focal flash-kernel will be unavailable | 17:04 |
| vorlon | true | 17:04 |
| sil2100 | rbasak: yeah | 17:05 |
| rbasak | And after flash-kernel is upgraded reconfigured, flash-kernel will then never actually run, since waveform tells me that flash-kernel.postinst doesn't itself invoke itself. | 17:05 |
| rbasak | I think we're agreed that the whole thing needs cleaning up | 17:05 |
| waveform | vorlon, if you need additional context I'm happy to jump on a call and fill in any blanks (if you prefer) | 17:05 |
| rbasak | But we're talking about SRUing this | 17:05 |
| rbasak | So what do we need to support in Bionic | 17:05 |
| rbasak | ? | 17:05 |
| rbasak | And what use cases are we not allowed to break? | 17:06 |
| -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-settings [source] (bionic-proposed) [18.04.7] | 17:09 | |
| vorlon | "upgrading" | 17:10 |
| vorlon | :) | 17:10 |
| rbasak | :) | 17:10 |
| rbasak | Do we modify flash-kernel then? | 17:10 |
| rbasak | Have it run itself on postinst? | 17:10 |
| rbasak | And would that break anything in a Bionic SRU? | 17:10 |
| vorlon | I haven't followed the chain of the argument here, sorry. why wouldn't we just make u-boot-rpi depend on flash-kernel, if it invokes it? | 17:11 |
| rbasak | Yes, that would also work | 17:11 |
| rbasak | I think | 17:11 |
| vorlon | I'd be worried about changing the behavior of flash-kernel, which is used for many devices that aren't rpi (though how many of those still work on bionic, I'm not sure) | 17:11 |
| rbasak | Since with the Breaks, we'd be certain to have the newer flash-kernel configured at the time u-boot-rpi.postinst runs I believe, unless there's a dependency loop | 17:12 |
| rbasak | Part of the reason I wanted someone else to look at this was to confirm that my understanding is correct. | 17:12 |
| rbasak | Is it possible that someone on Bionic is using u-boot-rpi but not flash-kernel - for the binary, say, and with manual updates on the SD card? | 17:13 |
| rbasak | If so, do we care about that use case? | 17:13 |
| vorlon | rbasak: well, what I was going to want to check was whether the u-boot-rpi is installed during image builds etc in contexts where trying to run flash-kernel would be the wrong thing | 17:28 |
| vorlon | I think /depending/ on flash-kernel should be fine in any case | 17:28 |
| vorlon | rbasak, waveform: shouldn't there be a version guard around the invocation of rpi-config-migration in the postinst, so that we ensure we only run it once? | 17:33 |
| vorlon | also: it has a shebang but is being sourced instead of executed in the postinst | 17:34 |
| vorlon | ah I see there's a version check inside the rpi-config-migration code | 17:36 |
| vorlon | (rather, in the postinst where it invokes the function from the sourced file) | 17:37 |
| waveform | vorlon, good point on the #! - will drop that | 17:39 |
| waveform | (probably left over from testing) | 17:39 |
| -queuebot:#ubuntu-release- New binary: qgis [s390x] (focal-proposed/universe) [3.4.15+dfsg-1] (no packageset) | 18:08 | |
| -queuebot:#ubuntu-release- New binary: qgis [ppc64el] (focal-proposed/universe) [3.4.15+dfsg-1] (no packageset) | 18:27 | |
| -queuebot:#ubuntu-release- New binary: qgis [amd64] (focal-proposed/universe) [3.4.15+dfsg-1] (no packageset) | 18:32 | |
| infinity | vorlon, waveform: Man, I hope flash-kernel only running itself in postinst triggered and not in configure isn't a bug introduced by me almost a decade ago, but I have a deep suspicion it might be. :P | 18:34 |
| infinity | vorlon, waveform: I don't think "it's been like that since triggers were invented" is in any way an indication that it's correct. | 18:35 |
| waveform | infinity, my assumption was "it's probably incorrect, but deliberate to avoid running flash-kernel redundantly when it's been upgraded and the kernel hasn't because that's as annoying as update-initramfs running lots and lots of times" :) | 18:35 |
| waveform | so ... I was loathe to change it when that's a change for lots of platforms and I'm just tinkering with supporting one additional platform on an LTS release | 18:36 |
| infinity | waveform: Except that updating initramfs-tools or flash-kernel both could imply that we're also changing/fixing your boot process in ways where we want/need the tool to run. | 18:38 |
| waveform | infinity, yes - flash-kernel does after all contain all the u-boot scripts (and handles merging those with u-boot in a wide variety of interesting ways for an equally wide variety of platforms ... now including an entire custom method for raspberry pis :) | 18:39 |
| infinity | waveform: If you look at initramfs-tools' postinst, it triggers itself for $1 != triggered, and does an untriggering run for $1 = triggered. | 18:40 |
| infinity | You can sort of see the evolution of thought there, as I suspect I wrote or was involved in both of those. :/ | 18:41 |
| infinity | The initramfs-tools one is cleaner, using a dpkg-internal variable to determine it it's happening in a postinst context, unlike flash-kernel which has a home-brew detection var. | 18:41 |
| infinity | But both work well enough. Just need the other case for flash-kernel. | 18:42 |
| waveform | ah yes, FLASH_KERNEL_NOTRIGGER=y :) | 18:42 |
| rbasak | infinity: so what do you want for Bionic? u-boot-rpi Depends on flash-kernel, or the flash-kernel.postinst change? | 18:42 |
| rbasak | Or is there a third option? | 18:43 |
| infinity | The flash-kernel change is correct. It'll need some testing in a few contexts to make sure it doesn't break expectations (especially because silly NO_TRIGGER var is silly, and we abuse it in image build scripts), but historically, u-boot variants haven't had external dependencies, and it'd be nice if they didn't start. | 18:44 |
| infinity | On the other hand, it sounds like there's a new and exciting mess since back when I did armhf/fk/uboot stuff, cause u-boot never used to copy its own binaries around at all. | 18:45 |
| infinity | Which is clearly also a mistake. | 18:45 |
| infinity | Having two different things fiddling with that is fragile. | 18:45 |
| waveform | absolutely agreed - would I be right in thinking flash-kernel ought to be taking care of that too? | 18:45 |
| rbasak | I think we all agree on all of that. | 18:45 |
| rbasak | But the question is what's acceptable for an SRU | 18:45 |
| infinity | waveform: Yeah, flash-kernel should know which u-boot images belong to which board descriptions and have a copy file A to boot:B semantic in the board stanza. | 18:46 |
| infinity | waveform: Obviously not today, though. | 18:46 |
| waveform | infinity, yup - that's precisely my thoughts | 18:46 |
| infinity | rbasak: I think fixing the f-k postinst is acceptable for an SRU. A bit scary, but still acceptable. It's entirely wrong that upgrading a bootloader doesn't upgrade the bootloader (and f-k is a bootloader even though it's not a bootloader) | 18:47 |
| waveform | well, it's at least a bootloader *script* ... so part bootloader :) | 18:47 |
| rbasak | infinity: fight that out with vorlon then please? :) | 18:47 |
| infinity | I mean, adding the dependency is also "fine". Except that it might pull f-k in weird places if there are build-deps on said u-boot or whatever. | 18:51 |
| infinity | It's not a concern for image-building, where f-k will be there anyway, and image builds are already called with NO_TRIGGER to avoid the fact that f-k is braindead. | 18:51 |
| infinity | At the end of the day, it's still wrong is upgrading flash-kernel to fix a bug in, say, a boot script, doesn't actually fix a bug in a boot script. :P | 18:52 |
| infinity | But one could argue that if we've lived with that bug since precise or whatever, clearly no one cares, or the people who care have learned to work around it. | 18:52 |
| * infinity shrugs. | 18:52 | |
| infinity | (Personally, I find "the affected people aren't whiny enough" isn't a particularly compelling reason to not fix a bug that's staring you in the face.) | 18:53 |
| waveform | okay - is the consensus to fix flash-kernel "properly" for the SRU and ditch my horrid u-boot trigger? I'm happy to bash that together tonight if that's the consensus? | 19:00 |
| infinity | waveform: I need to run out, but I can help this afternoon if we want to fix f-k. If adding the dep is determined to get you over the hump and you're time-constrained, doing that for now is probably also fine. | 19:01 |
| -queuebot:#ubuntu-release- New binary: bibtexparser [amd64] (focal-proposed/universe) [1.1.0+ds-2ubuntu1] (no packageset) | 19:01 | |
| waveform | my impression is we're definitely time constrained - but I'm sufficiently familiar with all the bits now (I've been hacking on flash-kernel too for bionic) that I can throw all that together pretty quickly if that's the call | 19:01 |
| infinity | I'm personally too time-constrained right now to put down my foot and "make a call", was just throwing some pennies in the ring. | 19:02 |
| * infinity runs. | 19:02 | |
| waveform | heh - okay, vorlon: ^^ | 19:02 |
| rbasak | I'm happy to review and sponsor whatever method infinity and vorlon say is acceptable. | 19:04 |
| waveform | in lieu of a decision I'm going to go ahead and put together another branch with the "clean" version: flash-kernel being called when $1 != triggered, no horrid extra trigger in u-boot, but u-boot still copying itself onto the boot part. (because that's a step too far for now), and update my current branch to include the dep on flash-kernel - when a decision is made we can pick the appropriate branch | 19:18 |
| ahasenack | hi release team, please consider merging https://code.launchpad.net/~ahasenack/britney/gscan2pdf-badtest/+merge/377955 to badtest gscan2pdf, it's blocking many packages on a very flaky arm64 dep8 suite | 20:39 |
| ahasenack | vorlon: ^seems you are actively looking at hints | 21:01 |
| -queuebot:#ubuntu-release- New binary: qgis [armhf] (focal-proposed/universe) [3.4.15+dfsg-1] (no packageset) | 21:06 | |
| infinity | waveform: So, +1 on fixing flash-kernel from me. Looks like configure) needs the same logic as triggered), namely it needs to run flash-kernel only if FLASH_KERNEL_SKIP isn't set. | 21:08 |
| infinity | waveform: That should keep image builds safe, but fix the bug. | 21:08 |
| infinity | waveform: Ideally, the way this should work is that flash-kernel will effectively be triggering itself, so if you just reinstall it on top of itself, you'll see it first trigger/defer, then see the trigger fire. | 21:10 |
| -queuebot:#ubuntu-release- Unapproved: casper (bionic-proposed/main) [1.394.1 => 1.394.2] (desktop-core, ubuntu-server) | 21:11 | |
| mwhudson | vorlon, infinity: could one of you look at this casper upload? | 21:12 |
| infinity | mwhudson: One of me certainly can. | 21:12 |
| mwhudson | mwhudson@anduril:~/src/pkg$ tar tvf casper_1.394.2.tar.xz | grep 57poll | 21:13 |
| mwhudson | -rwxr-xr-x 0/0 495 2020-01-16 23:39 casper-1.394.2/scripts/casper-bottom/57pollinate | 21:13 |
| mwhudson | ^ because launchpad's diff will not actually be helpful | 21:13 |
| infinity | waveform: I'm not sure what you mean by "no horrid extra trigger in u-boot", though. If running flash-kernel after u-boot is upgraded is a good thing, then it's remains a good thing. f-k internally triggers anyway if you call it from a maintscript, so it can be as simple as [ ! -x /usr/sbin/flash-kernel ] || flash-kernel | 21:14 |
| infinity | mwhudson: In your copious free time, want to make debdiff spit out git-formatted patches so we can see mode changes? :P | 21:16 |
| mwhudson | infinity: i was wondering about that | 21:16 |
| mwhudson | is it in devscripts? | 21:16 |
| infinity | It is. | 21:16 |
| infinity | Would also be nice for symlinks (which diff just shows as added files, eww) and deletions. | 21:17 |
| mwhudson | oh yeah the behaviour around symlinks has thrown me off so many times | 21:17 |
| infinity | I believe patch(1) has been able to apply git patches for many years now, so we're probably approaching a point where debdiff generating them would be okay. | 21:17 |
| mwhudson | infinity: oh heh i found this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907126 and then found that I FILED IT | 21:20 |
| ubot5 | Debian bug 907126 in devscripts "debdiff: please show mode changes when comparing source packages" [Wishlist,Open] | 21:20 |
| infinity | mwhudson: Hah. | 21:20 |
| waveform | infinity, okay - FLASH_KERNEL_SKIP changes make sense - I'll get those done and building in a mo. On the "horrid extra trigger in u-boot": the issue was that if u-boot and flash-kernel were both upgraded simultaneously (as it extremely likely in the bionic case), if u-boot calls flash-kernel in its postinst-configure, that trigger is lost when flash-kernel upgrades (won't matter now that flash-kernel calls itself in its own configure, but | 21:21 |
| waveform | otherwise I was using the kernel's method of working around this: a trigger in u-boot to trigger the flash-kernel .. erm .. trigger) | 21:21 |
| infinity | mwhudson: Followup, does this script exist in eoan and/or focal, and is the mode already correct there? | 21:21 |
| mwhudson | infinity: it's in focal and yes | 21:21 |
| mwhudson | (because casper in focal actually has tests!!!omg | 21:21 |
| mwhudson | ) | 21:21 |
| infinity | Fancy. | 21:22 |
| infinity | waveform: Right, the trigger possibly being lost is fine because we assume the package being triggered will trigger itself in that case. | 21:22 |
| infinity | waveform: That assumption was wrong here, but that's because f-k is broken. | 21:23 |
| infinity | waveform: Fixing f-k doesn't mean removing other triggers, cause we still want it triggered when f-k isn't being installed/upgraded. | 21:23 |
| waveform | infinity, precisely - with flash-kernel callilng itself, no need for my horrid trigger-to-trigger-a-trigger hack :) | 21:23 |
| waveform | in other words, this was an entirely new trigger just to work around f-k not calling itself; if it was pre-existing I would certainly leave it alone | 21:23 |
| infinity | waveform: I don't follow your logic. Unless your trigger was literally only needed in the case when both are being upgraded together... | 21:24 |
| waveform | yes, precisely that | 21:24 |
| infinity | waveform: Okay. So, in the general case, upgrading u-boot-whatevs doesn't need an f-k run? | 21:24 |
| infinity | waveform: (Though, it will when we move the copying logic to f-k where it belongs) | 21:24 |
| waveform | yes and yes | 21:24 |
| infinity | waveform: Sound like we both understand it the same? | 21:24 |
| waveform | yup - you've got it :) | 21:25 |
| infinity | waveform: Kay. Then yes, +1 on your proposed changes. | 21:25 |
| infinity | mwhudson: Acceptiferated. | 21:26 |
| mwhudson | infinity: merci | 21:26 |
| -queuebot:#ubuntu-release- Unapproved: accepted casper [source] (bionic-proposed) [1.394.2] | 21:26 | |
| infinity | mwhudson: Ahh, so I see your bug requested a result, but didn't offer a solution (a good bug, by most estimates, but I find offering solutions can help smooth things along in the Debian world). | 21:28 |
| mwhudson | infinity: er what's the best way of generating git format patches? diff(1) doesn't seem to support that | 21:28 |
| infinity | mwhudson: Now that git's deeply entrenched in everyone's workflow, I'd suggest that devscripts depending on git and using "git diff dir1 dir2" would not be terrible. | 21:28 |
| mwhudson | oh does that work? | 21:29 |
| infinity | mwhudson: Unfortunately, the high speed interdiff path for v1 source packages won't be helped there, but it's probably long past time to deprecate or even entirely remove that code. | 21:29 |
| infinity | mwhudson: It very much works. It's how I verified your upload before accepting. | 21:29 |
| mwhudson | infinity: i guess that also pointed out the trailing space in changelog huh | 21:30 |
| infinity | mwhudson: I don't know if it's had the same level of security scrutiny as diff(1) has, for eg infinite loops and reverse path traversals, but no time like the present to force that issue. :P | 21:30 |
| mwhudson | (i'm not sure how i do that so often, must be something in how i use vim) | 21:30 |
| mwhudson | infinity: oh yeah, which package was it that used to make launchpad diff generation eat itself? | 21:30 |
| infinity | udev | 21:31 |
| infinity | Which got "solved" by systemd eating it and shuffling the tree a bit. | 21:31 |
| infinity | Not sure if the diff bug was ever actually solved. | 21:31 |
| infinity | Might have. | 21:31 |
| infinity | mwhudson: As for trailing spaces in changelogs, learn to use "A". | 21:32 |
| mwhudson | behold the mightily extreme fix https://paste.ubuntu.com/p/5V6VH7TkrT/ | 21:32 |
| mwhudson | (devscripts already depends on git) | 21:33 |
| infinity | mwhudson: When you dch -i, you get dumped on the new line, but on the end char. If you [i]nsert, you'll have a space after your entry. If you [A]ppend, you end up at the end. | 21:33 |
| mwhudson | infinity: ah that is probably it | 21:33 |
| infinity | I'd argue that it's a dch bug that it doesn't dump you in append mode by default, but I suspect changing that behaviour 20+ years in might break a whole lot of brains. | 21:36 |
| infinity | mwhudson: Anyhow, learning to use 'A' more in vi is a solid habit to get into anyway. "I want to type at the very end of the line I'm on" is a pretty common programmer ask, but people's vi larnin' usually stops with "I learned how to insert, and after much cursing and some googling, I got out of the editor, done now." | 21:38 |
| waveform | listchars might also be worth a look (to visually show trailing whitespace / tabs / etc.) - I find that quite handy | 21:40 |
| infinity | Yeah, I show tabs/spaces/CF/LF, but I do them with printable chars because I had too many crap terminals in my life at one point, so they're a bit confusing at times in some more complex source. | 21:41 |
| infinity | I should revisit that to use more unique unicode chars now that I live in a less 1975 world. | 21:41 |
| waveform | infinity, https://github.com/waveform80/dotfiles/blob/master/vimrc#L122 | 21:41 |
| infinity | s/CF/CR/ | 21:42 |
| infinity | waveform: Ahh, that's not a terrible solution. | 21:43 |
| infinity | waveform: I'd suggest the utf-8 trailing space should be U+1F4A9, but maybe that's better reserved for carriage returns. | 21:43 |
| waveform | I probably wanted something minimal because occasionally I have to bite my tongue and deal with something that's riddled with trailing spaces :) | 21:45 |
| -queuebot:#ubuntu-release- New binary: qgis [arm64] (focal-proposed/universe) [3.4.15+dfsg-1] (no packageset) | 21:47 | |
| infinity | waveform: Yeah. It's been a while since I've met something CRLF formatted, but there was a point whwre my vim config would just colour the whole thing red which, it turns out, can make a man irrationally angry. | 21:51 |
| waveform | heh - sounds like an eminently rational reaction to me :) | 21:52 |
| vorlon | infinity, waveform: where did the two of you land on the question of whether the u-boot SRU should be dependent on a change to flash-kernel also landing? | 22:12 |
| vorlon | I'm usually wary of making SRUs interdependent on one another, especially when they're critical-path for a point release as is the case here | 22:13 |
| waveform | vorlon, either way this landed the flash-kernel and u-boot SRUs would be dependent on each other (at least for the case of pi4 support in bionic, which is kind of the point here - updates to both are required for that end state) | 22:32 |
| waveform | vorlon, I'm just putting together a flash-kernel which runs itself on upgrade (as it should), and a u-boot which doesn't have my horrid added trigger just to deal with running f-k when f-k upgrades - which is where infinity (and I) agreed (I believe?) the line should be drawn (for now; ultimately more changes are desired to u-boot and f-k but not for the bionic SRU) | 22:37 |
| waveform | I've still got my original branches in case you don't like these changes, but frankly they're looking cleaner than my original proposition - I'll test them out on a real pi2/3/3+ upgrade once everything's built in the PPA | 22:38 |
| waveform | vorlon, all done and pushed - it'll take a while to build and test the various upgrade scenarios, should I ping once that's all done or do you want to have a look in advance? | 22:46 |
| cjwatson | infinity: The underlying diff bug was https://bugs.launchpad.net/ubuntu/+source/diffutils/+bug/314436 and AFAIK has never been fixed. LP applies resource limits nowadays as a mitigation. | 23:28 |
| ubot5 | Ubuntu bug 314436 in diffutils (Ubuntu) "package-diff can generate infinite output" [High,Confirmed] | 23:28 |
| cjwatson | [note, not actually infinite, just exponential] | 23:29 |
| infinity | cjwatson: Neat. I suspect switching to git diff would accidentally fix that only because it understands what a symlink is. It would likely still fail for kernel filesystems where there are O(lots) of paths to the same node, but maybe those have mostly been fixed to "look" like links by now too. | 23:34 |
| infinity | (But also, following links out of tree is bad, and hopefully it also would never do that) | 23:34 |
| infinity | I guess the first point (it detects links and represents them as links, not the target) would imply it can't go out of tree. | 23:35 |
| infinity | So, win-win. | 23:35 |
| -queuebot:#ubuntu-release- New binary: openbabel [amd64] (focal-proposed/universe) [3.0.0+dfsg-2] (kubuntu) | 23:37 | |
| -queuebot:#ubuntu-release- New binary: openbabel [s390x] (focal-proposed/universe) [3.0.0+dfsg-2] (kubuntu) | 23:48 | |
| vorlon | waveform: please give me a pointer :) | 23:58 |
| -queuebot:#ubuntu-release- New binary: openbabel [ppc64el] (focal-proposed/universe) [3.0.0+dfsg-2] (kubuntu) | 23:59 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!