=== coreycb1 is now known as coreycb
[12:26] <paride> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: paride
[15:02] <amikhalitsyn> Dear colleagues, can someone help with sponsoring upload for Noble https://bugs.launchpad.net/ubuntu/+source/criu/+bug/2066148 ?
[15:02] -ubottu:#ubuntu-devel- Launchpad bug 2066148 in criu (Ubuntu) "Ubuntu Noble lacks of CRIU package" [Undecided, New]
[15:18] <ahasenack> does anybody know what is wrong with software-properties' DEP8 tests in noble?
[15:18] <ahasenack> 318s autopkgtest [06:54:20]: @@@@@@@@@@@@@@@@@@@@ apt-source software-properties
[15:18] <ahasenack> 324s autopkgtest [06:54:26]: ERROR: erroneous package: rules extract failed with exit code 1
[15:18] <ahasenack> 324s blame: software-properties
[15:18] <ahasenack> 324s badpkg: rules extract failed with exit code 1
[15:19] <ahasenack> between that and infra failures, it's been a bad week...
[15:48] <paride> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: N/A
[15:53] <paride> ahasenack, did that happen more than once?
[15:53] <paride> ahasenack, not that once is ok
[15:53] <ahasenack> yes, in multiple architectures
[15:54] <ahasenack> https://autopkgtest.ubuntu.com/packages/s/software-properties/noble/amd64 for example
[15:54] <paride> ahasenack, I just reproduced it locally
[15:56] <ahasenack> 0.99.48 extracted fine with apt-get source here, noble
[15:56] <paride> it tries to download a different version:\
[15:57] <paride> apt-get source -d -q --only-source software-properties=0.99.48.1
[15:57] <paride> and this fails: E: Can not find version '0.99.48.1' of package 'software-properties'
[15:57] <ahasenack> where is 0.99.48.1 coming from?
[15:57] <ahasenack> noble has 0.99.48, and noble-proposed has 0.99.49
[15:58] <paride> ahasenack, checking
[15:59] <ahasenack> juliank: do you know something abouv this? I vaguely remember a comment from you in an SRU that mfo was checking
[16:01] <juliank> paride, ahasenack So it gets confused by software-properties-qt temporarily existing in its own source package in a 0.99.48.1
[16:01] <juliank> Well I say temporarily but that is in the release pocket
[16:01] <juliank> and it seems to use that to determine the version of software-properties source package to download
[16:01] <dbungert1> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: dbungert1
=== dbungert1 is now known as dbungert
[16:01] <paride> I wonder if some changes I introduced locally to the "find source package to download" algorithm would work better
[16:02] <ahasenack> why would a different source package interfere here?
[16:02] <ahasenack> just because it's a substring match?
[16:02] <juliank> ahasenack: autopkgtest tries to find out the source version to download but it looks at the wrong binary package
[16:02] <paride> ahasenack, it is not that simple
[16:02] <juliank> something like that
[16:03] <paride> ahasenack, let me test from master, i.e. with https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/324 merged in
[16:03] -ubottu:#ubuntu-devel- Merge 324 in ci-team/autopkgtest "Truly honor pinning when looking for the source package to download" [Merged]
[16:03] <ahasenack> paride: ok
[16:04] <paride> ahasenack, still fail, same failure mode
[16:04] <paride> *fails
[16:11] <ahasenack> paride: looks like we need an autopkgtest bug, were you about to file one? If not, I can, with the info we have so far
[16:12] <paride> ahasenack, that's indeed a bug in autopkgtest and not an obvious one
[16:13] <paride> ahasenack, file against the autopkgtest ubuntu package or debian, as you prefer.
[16:14] <ahasenack> ok
[16:15] <krytarik> dbungert: Btw, with that nick change after piloting in, I don't think ubottu is going to handle your piloting out later on. >_<
[16:16] <ahasenack> paride: where did you see it trying to download the wrong version? Only locally, or also in the logs on the server?
[16:16] <paride> ahasenack, only locally
[16:16] <ahasenack> paride: what was the command, just run the tests from software-properties, nothing else?
[16:17] <paride> autopkgtest --debug -U software-properties -- qemu ~/path/to/autopkgtest-noble-amd64.img
=== dbungert is now known as dbungert1
[16:17] <ahasenack> ta
[16:17] <dbungert1> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: N/A
=== dbungert1 is now known as dbungert
[16:17] <dbungert> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: dbungert
[16:17] <dbungert> krytarik: thanks!
[16:18] <krytarik> XD
[16:21] <paride> ahasenack, I believe the fundamental inconsistency that tricks autopkgtes is that `apt-cache showsrc software-properties` has Package-List: software-properties-qt, but no bin:software-properties-qt package *from that source* is actually available
[16:22] <ahasenack> d/control has it
[16:22] <paride> fine, but autopkgtest looks at what apt knows
[16:22] <ahasenack> and something built on amd64: https://launchpad.net/ubuntu/+source/software-properties-qt/0.99.48.1
[16:23] <paride> so if on Noble you: `apt install software-properties-qt=0.99.48` it will error out: E: Version '0.99.48' for 'software-properties-qt' was not found
[16:23] <ahasenack> well, yes, it only exists at .1
[16:27] <paride> ahasenack, I have half of an idea on how to fix it
[16:27] <ahasenack> and I haven't finished filing the bug yet even :)
[16:28] <ahasenack> paride: here: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/2066290
[16:28] -ubottu:#ubuntu-devel- Launchpad bug 2066290 in autopkgtest (Ubuntu) "Attempts to fetch wrong version for package" [Undecided, New]
[16:28] <paride> ahasenack, thanks
[16:30] <ahasenack> so wait a second, src:software-properties in noble still builds bin:software-properties-qt, and noble also has a src:software-properties-qt that ALSO builds bin:software-properties-qt?
[16:31] <ahasenack> two different source packages building a binary package each with the same name
[16:36] <paride> ahasenack, yes, and apparently the one with the highest version makes the other disappear
[16:43] <ahasenack> brb, reboot
[16:59] <paride> ahasenack, upstream ci is still partially broken :( see https://salsa.debian.org/paride/autopkgtest/-/pipelines/680532
[17:00] <ahasenack> paride: is that debian/sid or what?
[17:01] <ahasenack> bookworm
[17:01] <paride> ahasenack, what is broken is the image used in the CI jobs. Then the jobs themselves test autopkgtest in different scenarios. for example test-lxc-old-testbed test on a trusty testbed
[17:01] <paride> as trusty is the oldest thing around
[17:02] <paride> ahasenack, I already pinged around about the broken ci images, but got no reply
[17:02] <ahasenack> would an apt -f install fix that, temporariluy?
[17:03] <paride> hmm, I don't think so
[17:03] <paride> ahasenack, you can try yourself by running: docker run -it registry.salsa.debian.org/salsa-ci-team/pipeline/autopkgtest
[17:03] <paride> and then apt-get update && apt-get install libc6-dev
[17:03] <ahasenack> hah, I just uninstalled docker
[17:03] <ahasenack> will get a vm
=== mfo_ is now known as mfo
=== coreycb1 is now known as coreycb
[19:44] <arraybolt3> juliank: random question for you if you're around and have time - do you have any idea what generates the file /boot/efi/EFI/ubuntu/grub.cfg? Is this something that an installer generates or is it something that a package has control over and creates via a postinst script or something?
[19:45] <juliank> arraybolt3: update-grub / grub-mkconfig creates thst
[19:45] <arraybolt3> not /boot/grub/grub.cfg, but /boot/efi/EFI/ubuntu/grub.cfg.
[19:45] <arraybolt3> It's a weird three-or-four line file that points GRUB to the real grub.cfg.
[19:46] <arraybolt3> and it does not seem to be updated when I run update-grub.
[19:47] <arraybolt3> just confirmed, I can move it to grub.cfg.bak and then run update-grub, and it is **not** regenerated.
[19:53] <juliank> Ah sorry
[19:53] <juliank> Grub-install creates that I believe when installing grub to the esp
[19:54] <arraybolt3> juliank: ah ok. Nothing ever updates it right?
[19:54] <arraybolt3> Asking because I'm designing a tool at my workplace that modifies that file for reasons, and I'm wanting to confirm that my changes won't be clobbered later
[19:54] <arraybolt3> though it sounds like a GRUB update might clobber it
[19:55] <arraybolt3> ah, `grub-install` does update it BUT it also regenerates it correctly. Fantastic. Thank you!
[21:41] <dbungert> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: N/A
=== bdmurray changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Noble | Patch Pilots: N/A