| joelkraehemann | hi all | 05:39 |
|---|---|---|
| joelkraehemann | my launchpad snap builds fail for a while for unknown reason ... | 05:39 |
| joelkraehemann | https://launchpad.net/~jkraehemann/+snap/gsequencer | 05:40 |
| joelkraehemann | ilasc: please check this ^^ | 05:40 |
| ilasc | Hi joelkraehemann | 06:22 |
| joelkraehemann | hi | 06:22 |
| ilasc | I had a look, it is failing indeed | 06:23 |
| ilasc | 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 |
| ubottu | Launchpad bug 1983654 in Launchpad itself "OOPS when requesting snap builds for 0ad" [High, Triaged] | 06:23 |
| joelkraehemann | yeah, I have got another snap failing | 06:23 |
| joelkraehemann | ilasc: I need to abandon bazar? | 06:25 |
| joelkraehemann | https://launchpad.net/~jkraehemann/+snap/nongnu-gsequencer | 06:26 |
| joelkraehemann | ^^ here is the other snap | 06:26 |
| ilasc | that was the temporary workaround adopted by the user who reported that bug yes | 06:26 |
| ilasc | I've seen the second snap failing in your snap packages list | 06:26 |
| joelkraehemann | yes, both have the same error | 06:27 |
| ilasc | 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:29 |
| ilasc | 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 | 06:34 |
| zyga[m] | 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 |
| zyga[m] | sample log https://launchpadlibrarian.net/620247596/buildlog_snap_ubuntu_jammy_amd64_hawkbit_BUILDING.txt.gz | 07:56 |
| zyga[m] | since this is failing on pull I suspect the culprit is this line: mvn dependency:go-offline | 07:56 |
| zyga[m] | this has a lot of traffic to repo.maven.apache.org and maven.vaadin.com | 07:57 |
| zyga[m] | since the snap builds fine locally the only explanation I can think of, would be the network proxy | 07:58 |
| zyga[m] | if you have any idea why this may behave this way I would appreciate your thoughts | 07:58 |
| === schopin_ is now known as schopin | ||
| cjwatson | zyga[m]: Hard to say with the lack of output. That's a snapcraft bug (https://bugs.launchpad.net/snapcraft/+bug/1981072) | 09:00 |
| ubottu | Launchpad bug 1981072 in Snapcraft "Core22 Snap builds don't output error logs" [Undecided, New] | 09:00 |
| zyga[m] | yes, I know, I spoke to sergio about that | 09:00 |
| zyga[m] | but whatever that bug is masking must be specific to launchpad | 09:00 |
| cjwatson | 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:01 |
| zyga[m] | I understand | 09:02 |
| cjwatson | Maven has always been a problem, but IIRC that snap has worked before? | 09:03 |
| zyga[m] | I'll check with sergio, perhaps there's some way to avoid that bug | 09:03 |
| cjwatson | I can investigate if I have to, but it's time-consuming. | 09:05 |
| cjwatson | We can see that it isn't successfully talking to either repo.maven.apache.org or maven.vaadin.com at all. | 09:06 |
| cjwatson | So perhaps snapcraft's proxy-handling code isn't working properly for maven? | 09:07 |
| cjwatson | 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:11 |
| zyga[m] | cjwatson: let me look | 09:13 |
| zyga[m] | the maven plugin is dead | 09:13 |
| cjwatson | I don't know how to do that nicely. Worst case transcribe that into shell, I guess ... | 09:13 |
| zyga[m] | so I do call maven manually | 09:13 |
| cjwatson | Right, so you'd need to do the same thing | 09:13 |
| zyga[m] | do I need to respect http_proxy/https_proxy? | 09:14 |
| cjwatson | Yes, you must | 09:14 |
| zyga[m] | (convey that form environment to mvn settings) | 09:14 |
| cjwatson | Unfortunately AFAIK maven doesn't have a way to do that without piles of XML | 09:14 |
| zyga[m] | perfect, that's clear then | 09:14 |
| zyga[m] | damn, maven is so annoying | 09:14 |
| zyga[m] | why cannot it just read environment | 09:14 |
| zyga[m] | java is a world of crazy :/ | 09:14 |
| zyga[m] | thank you so much :) | 09:14 |
| cjwatson | Yeah, for real | 09:14 |
| zyga[m] | this is a huge unblocker | 09:14 |
| cjwatson | It's probably going to be a pain to do in shell, I'm afraid! | 09:15 |
| zyga[m] | heredoc for the rescue | 09:16 |
| zyga[m] | (not perfect but probably good enough) | 09:16 |
| clinton-fung | 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:23 |
| zyga[m] | let me google a little | 09:24 |
| clinton-fung | Here's a clear description: https://www.baeldung.com/maven-behind-proxy | 09:28 |
| cjwatson | That's true, -Djava.net.useSystemProxies=true seems at least worth a shot | 10:02 |
| cjwatson | (Does that honour the environment? The docs I could find weren't quite clear) | 10:02 |
| zyga[m] | That is nicer than my shell splitting url to host/port pairs | 10:04 |
| zyga[m] | I'll try that shortly | 10:04 |
| zyga[m] | Pehrpas launchpad could stick that into JAVA_OPTS if it works | 10:05 |
| zyga[m] | More stuff would just work | 10:05 |
| === Droid is now known as Maik | ||
| zyga[m] | nope, that only works with gsettings | 10:52 |
| zyga[m] | + if [ -n "$http_proxy" ]; then... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/186fbb2c5bdee0926c93802e54c2c68fdcbc4a5e) | 10:52 |
| zyga[m] | that's my current patch | 10:52 |
| zyga[m] | * ``` | 10:53 |
| zyga[m] | * ```... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/82ef9140fdfe3668051f38d0aa96152ee40b64ef) | 10:53 |
| zyga[m] | not terrible, not great | 10:54 |
| zyga[m] | at least not parsing in shell | 10:54 |
| cjwatson | 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:55 |
| cjwatson | And then if we're playing with JAVA_OPTS it'd be more inarguably our fault | 10:56 |
| zyga[m] | it doesn't work though :/ | 11:01 |
| zyga[m] | I'll try passing this to maven explicitly | 11:01 |
| zyga[m] | what a mess, I may have to emit settings xml instead | 11:01 |
| cjwatson | Does MAVEN_OPTS and/or MAVEN_CLI_OPTS instead work better? | 11:01 |
| zyga[m] | trying | 11:02 |
| zyga[m] | MAVEN_OPTS_CLI didn't work | 11:08 |
| zyga[m] | I feel like I'm doing this blind | 11:08 |
| zyga[m] | MAVEN_OPTS is suspiciously not failing yet, perhaps that is the magic value | 11:16 |
| zyga[m] | it failed in override-build, so pull must have worked, this is great | 11:18 |
| cjwatson | Phew | 11:19 |
| zyga[m] | some more cleanup to make it nice to use but this is very promising | 11:20 |
| zyga[m] | hmm, it still fails but that could be something else | 11:26 |
| zyga[m] | cjwatson: what are the memory limits on each x86_64 build? this hawkbit thing has heavy tests that need 12GB of ram IIRC | 11:27 |
| zyga[m] | cjwatson: alternatively, is there a way to know launchpad is building the snap? I can disable tests this way | 11:30 |
| cjwatson | zyga[m]: 8G RAM and 8G swap IIRC | 11:47 |
| cjwatson | So you should be OK for 12G, if a bit slow | 11:47 |
| zyga[m] | thank you, it built with skipped tests | 11:47 |
| zyga[m] | excellent | 11:47 |
| zyga[m] | some cleanup needed but this is perfect | 11:47 |
| cjwatson | (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) | 11:48 |
| === ginggs_ is now known as ginggs | ||
| cjwatson | If anyone has been wondering about Rust-based snap builds getting stuck on armhf, that should be fixed now | 13:17 |
| cjwatson | Was quite a weird problem, see https://github.com/lxc/lxcfs/issues/553 | 13:18 |
| ubottu | Issue 553 in lxc/lxcfs "arm64: /proc/cpuinfo doesn't honour personality inside LXD container" [Open] | 13:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!