[05:39] hi all [05:39] my launchpad snap builds fail for a while for unknown reason ... [05:40] https://launchpad.net/~jkraehemann/+snap/gsequencer [05:40] ilasc: please check this ^^ [06:22] Hi joelkraehemann [06:22] hi [06:23] I had a look, it is failing indeed [06:23] this looks like an issue that occurred before most likely as a result of a breezy upgrade (has been moving away from file-ids), workaround was to move to a Git source: https://bugs.launchpad.net/launchpad/+bug/1983654 [06:23] Launchpad bug 1983654 in Launchpad itself "OOPS when requesting snap builds for 0ad" [High, Triaged] [06:23] yeah, I have got another snap failing [06:25] ilasc: I need to abandon bazar? [06:26] https://launchpad.net/~jkraehemann/+snap/nongnu-gsequencer [06:26] ^^ here is the other snap [06:26] that was the temporary workaround adopted by the user who reported that bug yes [06:26] I've seen the second snap failing in your snap packages list [06:27] yes, both have the same error [06:29] indeed they do, it is the same as the one reported in the bug I've shared, I will bring this up in the team meeting today to discuss how we can priorities it, for right now I can tell you this is known and the only workaround was to create the snap recipe based on a Git repo [06:34] I will updates you here as soon as I have anything apart from the workaround and you can also subscribe to the bug to see updates on this [07:56] cjwatson: I'm trying to understand why mvn-based snap fails to build on launchpad, allow_internet is True, the output from snapcraft is not show so I have little idea as to exactly what is failing. Have you heard reports of similar failures before? [07:56] sample log https://launchpadlibrarian.net/620247596/buildlog_snap_ubuntu_jammy_amd64_hawkbit_BUILDING.txt.gz [07:56] since this is failing on pull I suspect the culprit is this line: mvn dependency:go-offline [07:57] this has a lot of traffic to repo.maven.apache.org and maven.vaadin.com [07:58] since the snap builds fine locally the only explanation I can think of, would be the network proxy [07:58] if you have any idea why this may behave this way I would appreciate your thoughts === schopin_ is now known as schopin [09:00] zyga[m]: Hard to say with the lack of output. That's a snapcraft bug (https://bugs.launchpad.net/snapcraft/+bug/1981072) [09:00] Launchpad bug 1981072 in Snapcraft "Core22 Snap builds don't output error logs" [Undecided, New] [09:00] yes, I know, I spoke to sergio about that [09:00] but whatever that bug is masking must be specific to launchpad [09:01] Yeah, but I'm a little reluctant to spend lots of time investigating something that would get a lot easier to investigate once snapcraft is fixed [09:02] I understand [09:03] Maven has always been a problem, but IIRC that snap has worked before? [09:03] I'll check with sergio, perhaps there's some way to avoid that bug [09:05] I can investigate if I have to, but it's time-consuming. [09:06] We can see that it isn't successfully talking to either repo.maven.apache.org or maven.vaadin.com at all. [09:07] So perhaps snapcraft's proxy-handling code isn't working properly for maven? [09:11] zyga[m]: Ah, now I see your snap is calling mvn directly. Doesn't that mean it would need something like https://github.com/snapcore/snapcraft/blob/main/snapcraft_legacy/plugins/v1/maven.py#L229 in order to work via a proxy? [09:13] cjwatson: let me look [09:13] the maven plugin is dead [09:13] I don't know how to do that nicely. Worst case transcribe that into shell, I guess ... [09:13] so I do call maven manually [09:13] Right, so you'd need to do the same thing [09:14] do I need to respect http_proxy/https_proxy? [09:14] Yes, you must [09:14] (convey that form environment to mvn settings) [09:14] Unfortunately AFAIK maven doesn't have a way to do that without piles of XML [09:14] perfect, that's clear then [09:14] damn, maven is so annoying [09:14] why cannot it just read environment [09:14] java is a world of crazy :/ [09:14] thank you so much :) [09:14] Yeah, for real [09:14] this is a huge unblocker [09:15] It's probably going to be a pain to do in shell, I'm afraid! [09:16] heredoc for the rescue [09:16] (not perfect but probably good enough) [09:23] There is MAVEN_OPTS and MAVEN_CLI_OPTS which may be useful for your situation; you can use this to pass -D parameters to the JVM, and one of the available parameters allows you to configure an HTTP proxy [09:24] let me google a little [09:28] Here's a clear description: https://www.baeldung.com/maven-behind-proxy [10:02] That's true, -Djava.net.useSystemProxies=true seems at least worth a shot [10:02] (Does that honour the environment? The docs I could find weren't quite clear) [10:04] That is nicer than my shell splitting url to host/port pairs [10:04] I'll try that shortly [10:05] Pehrpas launchpad could stick that into JAVA_OPTS if it works [10:05] More stuff would just work === Droid is now known as Maik [10:52] nope, that only works with gsettings [10:52] + if [ -n "$http_proxy" ]; then... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/186fbb2c5bdee0926c93802e54c2c68fdcbc4a5e) [10:52] that's my current patch [10:53] * ``` [10:53] * ```... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/82ef9140fdfe3668051f38d0aa96152ee40b64ef) [10:54] not terrible, not great [10:54] at least not parsing in shell [10:55] It might be possible to set that in launchpad-buildd, but I kind of have The Fear of breaking some other inscrutable bit of Java nonsense in the process [10:56] And then if we're playing with JAVA_OPTS it'd be more inarguably our fault [11:01] it doesn't work though :/ [11:01] I'll try passing this to maven explicitly [11:01] what a mess, I may have to emit settings xml instead [11:01] Does MAVEN_OPTS and/or MAVEN_CLI_OPTS instead work better? [11:02] trying [11:08] MAVEN_OPTS_CLI didn't work [11:08] I feel like I'm doing this blind [11:16] MAVEN_OPTS is suspiciously not failing yet, perhaps that is the magic value [11:18] it failed in override-build, so pull must have worked, this is great [11:19] Phew [11:20] some more cleanup to make it nice to use but this is very promising [11:26] hmm, it still fails but that could be something else [11:27] cjwatson: what are the memory limits on each x86_64 build? this hawkbit thing has heavy tests that need 12GB of ram IIRC [11:30] cjwatson: alternatively, is there a way to know launchpad is building the snap? I can disable tests this way [11:47] zyga[m]: 8G RAM and 8G swap IIRC [11:47] So you should be OK for 12G, if a bit slow [11:47] thank you, it built with skipped tests [11:47] excellent [11:47] some cleanup needed but this is perfect [11:48] (There's an issue where swap is supposed to be configured on all architectures but is missing on arm64/ppc64el due to some OpenStack nonsense, but that doesn't affect amd64 AFAIK) === ginggs_ is now known as ginggs [13:17] If anyone has been wondering about Rust-based snap builds getting stuck on armhf, that should be fixed now [13:18] Was quite a weird problem, see https://github.com/lxc/lxcfs/issues/553 [13:18] Issue 553 in lxc/lxcfs "arm64: /proc/cpuinfo doesn't honour personality inside LXD container" [Open]