=== JanC_ is now known as JanC
[08:33] <bluca> andersson123, bdmurray: getting 403 forbidden today on systemd autopkgtest http submissions, is that a known issue?
=== esembee_ is now known as esembee
[12:03] <ahasenack> checking in for +1 maintenance duty, last day
[12:03] <ahasenack> I'll check rust, haskell, and my curl upload
[12:07] <tjaalton> ahasenack: btw, is there a plan to remove tomcat9 for 24.04?
[12:08] <ahasenack> tjaalton: no plan, just follow debian afaik
[12:08] <tjaalton> ack
[12:08] <ahasenack> and debian has removed it already I think, I don't know what they did with dogtag-pki
[12:08] <tjaalton> removed from testing
[12:08] <ahasenack> yes
[12:09] <ahasenack> I synced tomcat9 the other day (the original delta was my doing), and it now only builds some library, and it won't migrate because of dogtag-pki
[12:09] <ahasenack> so for mantic we will likely ship both tomcat9 and tomcat10
[12:10] <tjaalton> okay
[12:11] <tjaalton> I'll look into vendoring some bits inside dogtag, libtomcat9-java should be mostly what it needs
[12:11] <tjaalton> didn't have time for that before it got removed from bookworm some weeks before release..
[12:12] <ahasenack> wasn't there another package, something css
[12:12] <ahasenack> or jss, jcss
[12:12] <ahasenack> letters
[12:12] <tjaalton> tomcatjss
[12:12] <ahasenack> yeah
[12:12] <tjaalton> it just needs the java lib
[12:34] <bluca> ahasenack: I've updated bug 2025400 as requested FYI
[12:34] -ubottu:#ubuntu-devel- Bug 2025400 in libzypp (Ubuntu Lunar) "zypper often fails to download packages when using HTTPS" [Undecided, Confirmed] https://launchpad.net/bugs/2025400
[12:38] <ahasenack> bluca: thanks, I'll take a look
[12:38] <ahasenack> oh, I had tried with -m, but the wrong url apparently
[12:39] <rbasak> juliank: around? I have someone trying to use add-apt-repository with a sources.list line that uses [signed-by=...], which fails. I think this is because https://git.launchpad.net/ubuntu/+source/python-apt/tree/aptsources/sourceslist.py#n355 doesn't support signed-by. Do you have any opinion on this?
[12:40] <rbasak> This is on Jammy, but looks like it affects Mantic as well.
[12:45] <juliank> rbasak: that's correct, yes. They should just write the file directly IMO, lots of gaps there.
[12:47] <juliank> The deb822 support has arbitrary field support
[12:49] <juliank> The classic sources.list doesn't have a way to store arbitrary fields and never added support for other fields than those
[12:49] <juliank> Well the classic... support in python
[13:10] <rbasak> juliank: OK thanks
[13:31] <bluca> anybody online who can help with the cloud autopkgtest infrastructure?
[13:31] <bluca> we are getting HTTP Error 403: FORBIDDEN when sending systemd jobs
[13:31] <bluca> since yesterday evening more or less
[13:32] <ahasenack> paride: ^?
[13:33] <paride> hi bluca, checking
[13:33] <bluca> thanks! can provide more details if needed
[13:33] <bluca> see this both on the github webhook on PR, and manually with the retry script
[14:22] <bdmurray> bluca: Could you give us the a list of some of http requests you are submitting where you see 403s?
[14:35] <bluca> in terms of payload url?
[14:37] <bluca> Request URL: https://autopkgtest.ubuntu.com/request.cgi?release=jammy&arch=amd64&package=systemd-upstream&build-git=https%3A%2F%2Fsalsa.debian.org%2Fsystemd-team%2Fsystemd.git%23upstream-ci&ppa=upstream-systemd-ci/systemd-ci&env=CFLAGS=-O0%3BDEB_BUILD_PROFILES=noudeb%
[14:39] <bluca> or using the 'retry-github-test' which I lifted from your launchpad cloud autopkgtest repo:
[14:40] <bluca> retry-github-test https://api.github.com/repos/systemd/systemd/pulls/28799 'https://autopkgtest.ubuntu.com/request.cgi?release=jammy&arch=amd64&package=systemd-upstream&build-git=https%3A%2F%2Fsalsa.debian.org%2Fsystemd-team%2Fsystemd.git%23upstream-ci&ppa=upstream-systemd-ci/systemd-ci&env=UPSTREAM_REPO=https%3A%2F%2Fgithub.com%2Fsystemd%2Fsystemd.git%3BCFLAGS=-O0%3BDEB_BUILD_PROFILES=noudeb%3BTEST_UPSTREAM=1%3BCONFFLAGS_UPSTREAM=
[14:40] <bluca> --werror%20-Dslow-tests%3Dtrue' <secretfile>
[14:50] <andersson123> Are you using retry github test for a test that is currently running or queued?
[14:51] <andersson123> 403 is expected response code for a duplicate request that's why I ask
[15:03] <bluca> interesting - I do not see a test running for the one I tried
[15:03] <bluca> on the PR page
[15:04] <bdmurray> we suspect we are missing something in the url / test request that makes it unique
[15:04] <bluca> https://github.com/systemd/systemd/pull/28799 shows nothing in the CI status
[15:04] -ubottu:#ubuntu-devel- Pull 28799 in systemd/systemd "core: some fixlets" [Open]
[15:05] <bluca> ah, but https://autopkgtest.ubuntu.com/running#pkg-systemd-upstream does show runs for 28799
[15:05] <bluca> so it looks like you are right and I was confused by the missing job listing
[15:05] <bluca> so the issue is that reporting back to GH is not working for some reason?
[15:07] <andersson123> Maybe attempting to retrigger a test causes github to lose track of the original test url?
[15:09] <andersson123> could you perhaps spin up a new PR to trigger a test (not duplicate) and see if you can see a test running?
[15:11] <bluca> this was just opened and I haven't touched it: https://github.com/systemd/systemd/pull/28801
[15:11] -ubottu:#ubuntu-devel- Pull 28801 in systemd/systemd "test: check if sd-shutdown works properly in shutdown initrd" [Open]
[15:11] <bluca> still no reports
[15:13] <bluca> on github's webhook page, in the log I see a 403 for that PR that says: You submitted an invalid request: </p><p>Requested test is already running
[15:14] <bluca> the timestamp coincides with the PR having been opened the first time
[15:15] <bluca> so it can't be duplicated?
[15:15] <bluca> now it's been force-pushed, and a 'synchronize' event from github triggering a webhook got another 403
[15:17] <bdmurray> I'm going to disable the duplicate check for github requests now while we continue to investigate it.
[15:18] <bluca> thanks - if I have to update the webhooks in any way please let me know
[16:02] <bdmurray> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: bdmurray
[19:21] <bdrung> xnox, I don't get your response on https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2019435 "it does feel too many[...]"
[19:21] -ubottu:#ubuntu-devel- Launchpad bug 2019435 in initramfs-tools (Ubuntu) "Default initramfs is missing qcom_geni_serial module" [Undecided, New]
[19:22] <bdrung> xnox, do you agree to add the module or do you disagree?
[20:03] <Amin> Hi all!
[20:03] <Amin> Posting here due to #ubuntu-boot #ubuntu-{boot,installer,iso} being empty. If this is not the right place, please point me to it.
[20:03] <Amin> Can someone please point me to how the installer ISOs are generated? -- with what script? I'm trying to replicate but am failing to trigger subiquity to start upon boot.
[20:03] <Amin> E.g.: https://releases.ubuntu.com/22.04/ubuntu-22.04.3-desktop-amd64.iso
[20:07] <dbungert> Amin: there is no easy answer for that, best to modify an existing ISO.  https://github.com/mwhudson/livefs-editor may help.  Also, Subiquity is not used on 22.04.x desktop, you want the server iso for 22.04.x or to use the 23.04 desktop iso.
[20:10] <Eickmeyer> Amin: This might answer, made by the Lubuntu team: https://phab.lubuntu.me/w/release-team/iso-building/
[20:12] <bdmurray> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: N/A
[20:14] <Amin> dbungert: Thanks! I linked the wrong thing it seems --- I want to do this for Ubuntu Server.
[20:14] <Amin> I have looked into that, and my current solution does involve using a prebuilt ISO, but I would like to be able to generate the whole thing entirely.
[20:14] <Amin> More precisely, I'm trying to netboot from 1/multiple Squashfs files (built else-way).
[20:15] <Amin> Also thanks @eickm
[20:15] <Amin> Also thanks Eickmeyer
[20:16] <Amin> I did look into the Lubuntu docs and into debian-cd but could not figure it out. WIll give it another shot!
[20:17] <dbungert> Amin: if you were to arrange the files in the correct way, /usr/share/cd-boot-images-amd64/xorriso-cmd.txt has a reasonable iso creation command
[20:17] <dbungert> found in package cd-boot-images-amd64
[20:20] <Amin> dbungert Thanks! I had not seen this one. Could you also tell me the process that led to finding it? (so that I can fish instead of asking for fishes :D)
[20:24] <dbungert> sadly I do not remember, Amin.  I'd share if I knew