-queuebot:#ubuntu-release- New binary: mrtrix3 [amd64] (focal-proposed/universe) [3.0~rc3+git135-g2b8e7d0c2-4] (no packageset)00:14
ddstreetvorlon updated sru template for lp #1845909 and added comment re: patch 101:30
ubot5Launchpad 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/184590901:30
dokovorlon: I'll pick itup05:41
=== paride6 is now known as paride
dokovorlon: please build ruby2.7 for i386 as well, or it will block the transition05:43
vorlondoko: 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 fact06:15
vorloninfinity: ^^ want to build ruby2.7/i386?06:15
dokoI'll re-upload06:15
-queuebot:#ubuntu-release- Packageset: Added libregexp-pattern-perl to i386-whitelist in focal06:39
-queuebot:#ubuntu-release- Packageset: Added ruby2.7 to i386-whitelist in focal06:39
mwhudsonvorlon: 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
infinitymwhudson: 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
mwhudsonah ok08: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
RikMillsLaney: 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 combination09:11
-queuebot:#ubuntu-release- New binary: rustc [s390x] (focal-proposed/universe) [1.39.0+dfsg1+llvm-3ubuntu1] (i386-whitelist)09:11
RikMillsif so, does the same go for trigger = main package = universe for someone with MOTU?09:11
RikMillsbecause that is refused ^09:11
RikMillswhich seem illogical09:12
Laneythat's the code to do it09:13
RikMillsLaney: not ANDs to refuse, so looks like you should be blocked only if you can't upload both?09:15
RikMillsif so, that isn't working for my MOTU permissions in universe09:16
Laneywhat 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 try09: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
Laneyah, I see it09:27
* apw waits in anticipation09:28
* RikMills also09: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
Laneymaybe 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
apwLaney, component09:35
RikMillscomponent = self.is_valid_package_version(release, trigsrc, trigver)09:38
RikMillsapw that?09:38
apwRikMills, that is uses that component for both can_upload checks, not the appropriate one for the package09:38
apwRikMills, 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 cannot09:39
RikMillsapw: but if in kubuntu set one of the last 2 conditions allows it?09:40
LaneyAPW GOT IT!09:43
apwRikMills, nope neither of those is related to packagesets, they are both local relaxations09:44
Laneyalso the check with relation to trigsrc is kind of shonky09:44
Laneyit only checks the last of them or something09:44
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (focal-proposed/universe) [1.39.0+dfsg1+llvm-3ubuntu1] (i386-whitelist)09:47
RikMillsLaney: 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
apwRikMills, i've see the complaint in various forms and people bodge round it and it gets forgotten; so good you did09:54
Laneyhttps://paste.debian.net/1127081/ review pls10:09
mwhudsonLaney: "We're" i assume?10:13
mwhudsonthat's enough being helpful for tonight10:14
* mwhudson goes to bed10:14
Laneythanks :>10:15
apwLaney, is there not an |= operator ...10:16
cjwatsonWhy is it doing component checka at all, rather than using LP's "can this person upload this package" API?10:17
cjwatsondisclaimer: haven't actually read the code, just that diff10:18
cjwatsonalso *checks10:18
Laneyit's using checkUpload but passing that a component parameter10:18
Laneyapw: that doesn't appear to do short circuiting10:18
apwLaney, oh how stupid :)10:19
cjwatsonah ok10:19
apwLaney, then given the code it looks ok to me10:19
Laneymmm, comopnent appears to be required10:20
* apw wonders what the default for strict_component is and what it does :)10:20
cjwatsonbit peculiar that component is required10:20
cjwatsonstrict_component: defaults to true, and https://git.launchpad.net/launchpad/tree/lib/lp/soyuz/interfaces/archive.py#n88810:23
apwso junk in component and strict_component=False might work10:26
apwnot sure if you could supply component as None, that might might also work to my reading10:27
cjwatsonThe 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 improvement10:29
cjwatsonSomebody should probably file a bug :)10:29
apwcjwatson, will do :)10:29
apwcjwatson, against launchpad itself i assume10:29
cjwatsonyes please10:29
LaneyI'll subscribe and we can fix this if and when that happens10:30
apwi assume this thing really should be using devel not 1.010:30
cjwatsonthe versioning system never worked very well, and it doesn't make sense at all for things that aren't hard to update10:31
cjwatsonnot that we're in the habit of making API-breaking changes even in devel10:31
LaneyRikMills: that should be updated now10:31
-queuebot:#ubuntu-release- Unapproved: mesa (eoan-proposed/main) [19.2.1-1ubuntu1 => 19.2.8-0ubuntu0~19.10.1] (core, xorg)10:31
apwalways add new better apis and migrate people to them ... stylee10:31
Laneyif someone wants to contribute... :)))10:33
ubot5Ubuntu bug 1860533 in Launchpad itself "archive.checkUpload() should allow component to be None" [Undecided,New]10:35
RikMillsLaney: 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
sil2100tjaalton: hey! The new mesa ^ is that also for .4?11:37
tjaaltonsil2100: 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 first11:39
tjaalton"they".. it's the same release, but anyway11:40
tjaaltonit's the last of the series, released last week11:40
tjaaltonhuh no, is older11:41
tjaaltonsil2100: but the ati/amdgpu fix has been verified, maybe fine to fast-track it to updates?11:46
sil2100tjaalton: yeah, will fast-track those - and I'll take a look at mesa and see if maybe we can stuff it in as well11:47
tjaaltonI've pushed mesa to the x-updates ppa to get community testing too11: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 focal12:09
-queuebot:#ubuntu-release- Packageset: Added linux-meta-5.4 to kernel in focal12:09
-queuebot:#ubuntu-release- Packageset: Added linux-restricted-modules-5.4 to kernel in focal12:09
-queuebot:#ubuntu-release- Packageset: Added linux-signed-5.4 to kernel in focal12:09
Laneythink 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
tjaaltonLaney: oh?12:56
Laneysome stupid interaction with timeouts12:57
Laneysomeone is still going to need to poke at why it started hanging in the build though12: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
RAOFWow, 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
dokoplease could you have a look at libuv1/i386 ?14:11
rbalintsil2100, could you please merge that? https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/37789114:14
LocutusOfBorgcan any AA please remove fw4spl from the archive? removed in debian, #94836914:25
ubot5Debian bug 948369 in ftp.debian.org "RM: fw4spl -- ROM; fw4spl is replaced by sight" [Serious,Open]14:25
tjaaltonsil2100: another one to fast-track is nvidia-390, which now builds against 5.3 and is verified14:32
-queuebot:#ubuntu-release- New binary: vcversioner [amd64] (focal-proposed/universe) [] (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) []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
sil2100tjaalton: sure14:56
sil2100rbalint: looking14: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
sil2100rbalint: hey! I'll be doing a few SRU reviews for bionic, mostly things useful for .415:39
Laneysil2100: ubuntu-meta is for .415:40
Laneyand I was wondering how much of https://launchpadlibrarian.net/461682085/ubuntu-settings_19.10.4_20.04.1.diff.gz I should upload as SRU15:41
Laneydefinitely 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
sil2100Laney: ACK o/15:45
sil2100rbasak: uh, by accident I pinged rbalint, so let me re-ping properly15:48
sil2100rbasak: hey! I'll be doing a few SRU reviews for bionic, mostly things useful for .415:48
sil2100If you don't mind15:48
sil2100For now I'm looking at mesa and ubuntu-meta15:49
rbasaksil2100: 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 details15:50
rbasakdpkg triggers, Breaks, etc.15:50
Laneyfor bionic, maybe I should just upload the default setting change and leave the package around15: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
sil2100rbasak: 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
Laneysil2100: going to upload https://paste.ubuntu.com/p/NHzBJNm3dB/ I think - making an empty binary package, hope that's ok16:21
Laneyfeels safer than dropping it or conflicting it off or anything like that16:21
sil2100Laney: 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
Laneyif update-manager works nicely it should be presented as a candidate for autoremoval too, but would be ideal not to rely on that16:23
sil2100Not 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 option16:23
Laneygreat, thanks16: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
Laneyok there's the other half16:27
Laneysee you o/16:27
sil2100Thanks, will look at it in a moment16:29
vorlonmwhudson: unfortunately no16:35
sil2100rbasak: hey! Did you get the necessary clarification regarding u-boot?16:41
rbasaksil2100: I'm still waiting to talk to someone, but otp right now16:43
rbasakinfinity: around?16:43
rbasakI assume vorlon is unavailable to chat?16:43
sil2100vorlon: 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 story16:46
vorlonsil2100, 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 morning17:01
rbasakI'm fine with that17:01
rbasakhttps://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-pi417:02
vorlonah so this is still for sponsorship, it's not in the queue yet for SRU review?17:03
rbasakMy 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
rbasaksil2100: my understanding is that someone also needs to do the SRU review?17:03
rbasakIt may be that a bunch of use cases I'm concerned about don't need to be maintained17:03
rbasakOne problem is that this is all unclear17:03
rbasakBut AFAICT, since u-boot-rpi doesn't depend on flash-kernel, the postinst can't rely on it being present17:04
rbasakAnd even with a Breaks, that might mean that during upgrade from Bionic to Focal flash-kernel will be unavailable17:04
sil2100rbasak: yeah17:05
rbasakAnd 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
rbasakI think we're agreed that the whole thing needs cleaning up17:05
waveformvorlon, if you need additional context I'm happy to jump on a call and fill in any blanks (if you prefer)17:05
rbasakBut we're talking about SRUing this17:05
rbasakSo what do we need to support in Bionic17:05
rbasakAnd 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
rbasakDo we modify flash-kernel then?17:10
rbasakHave it run itself on postinst?17:10
rbasakAnd would that break anything in a Bionic SRU?17:10
vorlonI 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
rbasakYes, that would also work17:11
rbasakI think17:11
vorlonI'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
rbasakSince 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 loop17:12
rbasakPart of the reason I wanted someone else to look at this was to confirm that my understanding is correct.17:12
rbasakIs 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
rbasakIf so, do we care about that use case?17:13
vorlonrbasak: 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 thing17:28
vorlonI think /depending/ on flash-kernel should be fine in any case17:28
vorlonrbasak, 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
vorlonalso: it has a shebang but is being sourced instead of executed in the postinst17:34
vorlonah I see there's a version check inside the rpi-config-migration code17:36
vorlon(rather, in the postinst where it invokes the function from the sourced file)17:37
waveformvorlon, good point on the #! - will drop that17: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
infinityvorlon, 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. :P18:34
infinityvorlon, 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
waveforminfinity, 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
waveformso ... 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 release18:36
infinitywaveform: 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
waveforminfinity, 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
infinitywaveform: If you look at initramfs-tools' postinst, it triggers itself for $1 != triggered, and does an untriggering run for $1 = triggered.18:40
infinityYou can sort of see the evolution of thought there, as I suspect I wrote or was involved in both of those. :/18:41
infinityThe 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
infinityBut both work well enough.  Just need the other case for flash-kernel.18:42
waveformah yes, FLASH_KERNEL_NOTRIGGER=y :)18:42
rbasakinfinity: so what do you want for Bionic? u-boot-rpi Depends on flash-kernel, or the flash-kernel.postinst change?18:42
rbasakOr is there a third option?18:43
infinityThe 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
infinityOn 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
infinityWhich is clearly also a mistake.18:45
infinityHaving two different things fiddling with that is fragile.18:45
waveformabsolutely agreed - would I be right in thinking flash-kernel ought to be taking care of that too?18:45
rbasakI think we all agree on all of that.18:45
rbasakBut the question is what's acceptable for an SRU18:45
infinitywaveform: 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
infinitywaveform: Obviously not today, though.18:46
waveforminfinity, yup - that's precisely my thoughts18:46
infinityrbasak: 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
waveformwell, it's at least a bootloader *script* ... so part bootloader :)18:47
rbasakinfinity: fight that out with vorlon then please? :)18:47
infinityI 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
infinityIt'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
infinityAt 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. :P18:52
infinityBut 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
waveformokay - 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
infinitywaveform: 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
waveformmy 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 call19:01
infinityI'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
waveformheh - okay, vorlon: ^^19:02
rbasakI'm happy to review and sponsor whatever method infinity and vorlon say is acceptable.19:04
waveformin 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 branch19:18
ahasenackhi 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 suite20:39
ahasenackvorlon: ^seems you are actively looking at hints21:01
-queuebot:#ubuntu-release- New binary: qgis [armhf] (focal-proposed/universe) [3.4.15+dfsg-1] (no packageset)21:06
infinitywaveform: 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
infinitywaveform: That should keep image builds safe, but fix the bug.21:08
infinitywaveform: 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
mwhudsonvorlon, infinity: could one of you look at this casper upload?21:12
infinitymwhudson: One of me certainly can.21:12
mwhudsonmwhudson@anduril:~/src/pkg$ tar tvf casper_1.394.2.tar.xz  | grep 57poll21:13
mwhudson-rwxr-xr-x 0/0             495 2020-01-16 23:39 casper-1.394.2/scripts/casper-bottom/57pollinate21:13
mwhudson^ because launchpad's diff will not actually be helpful21:13
infinitywaveform: 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-kernel21:14
infinitymwhudson: In your copious free time, want to make debdiff spit out git-formatted patches so we can see mode changes? :P21:16
mwhudsoninfinity: i was wondering about that21:16
mwhudsonis it in devscripts?21:16
infinityIt is.21:16
infinityWould also be nice for symlinks (which diff just shows as added files, eww) and deletions.21:17
mwhudsonoh yeah the behaviour around symlinks has thrown me off so many times21:17
infinityI 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
mwhudsoninfinity: oh heh i found this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907126 and then found that I FILED IT21:20
ubot5Debian bug 907126 in devscripts "debdiff: please show mode changes when comparing source packages" [Wishlist,Open]21:20
infinitymwhudson: Hah.21:20
waveforminfinity, 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, but21:21
waveformotherwise 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
infinitymwhudson: Followup, does this script exist in eoan and/or focal, and is the mode already correct there?21:21
mwhudsoninfinity: it's in focal and yes21:21
mwhudson(because casper in focal actually has tests!!!omg21:21
infinitywaveform: Right, the trigger possibly being lost is fine because we assume the package being triggered will trigger itself in that case.21:22
infinitywaveform: That assumption was wrong here, but that's because f-k is broken.21:23
infinitywaveform: 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
waveforminfinity, precisely - with flash-kernel callilng itself, no need for my horrid trigger-to-trigger-a-trigger hack :)21:23
waveformin 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 alone21:23
infinitywaveform: I don't follow your logic.  Unless your trigger was literally only needed in the case when both are being upgraded together...21:24
waveformyes, precisely that21:24
infinitywaveform: Okay.  So, in the general case, upgrading u-boot-whatevs doesn't need an f-k run?21:24
infinitywaveform: (Though, it will when we move the copying logic to f-k where it belongs)21:24
waveformyes and yes21:24
infinitywaveform: Sound like we both understand it the same?21:24
waveformyup - you've got it :)21:25
infinitywaveform: Kay.  Then yes, +1 on your proposed changes.21:25
infinitymwhudson: Acceptiferated.21:26
mwhudsoninfinity: merci21:26
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (bionic-proposed) [1.394.2]21:26
infinitymwhudson: 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
mwhudsoninfinity: er what's the best way of generating git format patches? diff(1) doesn't seem to support that21:28
infinitymwhudson: 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
mwhudsonoh does that work?21:29
infinitymwhudson: 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
infinitymwhudson: It very much works.  It's how I verified your upload before accepting.21:29
mwhudsoninfinity: i guess that also pointed out the trailing space in changelog huh21:30
infinitymwhudson: 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. :P21:30
mwhudson(i'm not sure how i do that so often, must be something in how i use vim)21:30
mwhudsoninfinity: oh yeah, which package was it that used to make launchpad diff generation eat itself?21:30
infinityWhich got "solved" by systemd eating it and shuffling the tree a bit.21:31
infinityNot sure if the diff bug was ever actually solved.21:31
infinityMight have.21:31
infinitymwhudson: As for trailing spaces in changelogs, learn to use "A".21:32
mwhudsonbehold the mightily extreme fix https://paste.ubuntu.com/p/5V6VH7TkrT/21:32
mwhudson(devscripts already depends on git)21:33
infinitymwhudson: 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
mwhudsoninfinity: ah that is probably it21:33
infinityI'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
infinitymwhudson: 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
waveformlistchars might also be worth a look (to visually show trailing whitespace / tabs / etc.) - I find that quite handy21:40
infinityYeah, 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
infinityI should revisit that to use more unique unicode chars now that I live in a less 1975 world.21:41
waveforminfinity, https://github.com/waveform80/dotfiles/blob/master/vimrc#L12221:41
infinitywaveform: Ahh, that's not a terrible solution.21:43
infinitywaveform: I'd suggest the utf-8 trailing space should be U+1F4A9, but maybe that's better reserved for carriage returns.21:43
waveformI 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
infinitywaveform: 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
waveformheh - sounds like an eminently rational reaction to me :)21:52
vorloninfinity, 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
vorlonI'm usually wary of making SRUs interdependent on one another, especially when they're critical-path for a point release as is the case here22:13
waveformvorlon, 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
waveformvorlon, 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
waveformI'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 PPA22:38
waveformvorlon, 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
cjwatsoninfinity: 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
ubot5Ubuntu bug 314436 in diffutils (Ubuntu) "package-diff can generate infinite output" [High,Confirmed]23:28
cjwatson[note, not actually infinite, just exponential]23:29
infinitycjwatson: 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
infinityI 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
infinitySo, 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
vorlonwaveform: 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!