[05:39] <joelkraehemann> hi all
[05:39] <joelkraehemann> my launchpad snap builds fail for a while for unknown reason ...
[05:40] <joelkraehemann> https://launchpad.net/~jkraehemann/+snap/gsequencer
[05:40] <joelkraehemann> ilasc: please check this ^^
[06:22] <ilasc> Hi joelkraehemann 
[06:22] <joelkraehemann> hi
[06:23] <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] <joelkraehemann> yeah, I have got another snap failing
[06:25] <joelkraehemann> ilasc: I need to abandon bazar?
[06:26] <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:27] <joelkraehemann> yes, both have the same error
[06:29] <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:34] <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 
[07:56] <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:57] <zyga[m]> this has a lot of traffic to repo.maven.apache.org and maven.vaadin.com 
[07:58] <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 
[09:00] <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] <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:01] <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:02] <zyga[m]> I understand
[09:03] <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:05] <cjwatson> I can investigate if I have to, but it's time-consuming.
[09:06] <cjwatson> We can see that it isn't successfully talking to either repo.maven.apache.org or maven.vaadin.com at all.
[09:07] <cjwatson> So perhaps snapcraft's proxy-handling code isn't working properly for maven?
[09:11] <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:13] <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:14] <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:15] <cjwatson> It's probably going to be a pain to do in shell, I'm afraid!
[09:16] <zyga[m]> heredoc for the rescue
[09:16] <zyga[m]> (not perfect but probably good enough)
[09:23] <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:24] <zyga[m]> let me google a little
[09:28] <clinton-fung> Here's a clear description: https://www.baeldung.com/maven-behind-proxy
[10:02] <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:04] <zyga[m]> That is nicer than my shell splitting url to host/port pairs 
[10:04] <zyga[m]> I'll try that shortly 
[10:05] <zyga[m]> Pehrpas launchpad could stick that into JAVA_OPTS if it works 
[10:05] <zyga[m]> More stuff would just work 
[10:52] <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:53] <zyga[m]>  * ```
[10:53] <zyga[m]>  * ```... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/82ef9140fdfe3668051f38d0aa96152ee40b64ef)
[10:54] <zyga[m]> not terrible, not great
[10:54] <zyga[m]> at least not parsing in shell
[10:55] <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:56] <cjwatson> And then if we're playing with JAVA_OPTS it'd be more inarguably our fault
[11:01] <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:02] <zyga[m]> trying
[11:08] <zyga[m]> MAVEN_OPTS_CLI didn't work 
[11:08] <zyga[m]> I feel like I'm doing this blind
[11:16] <zyga[m]> MAVEN_OPTS is suspiciously not failing yet, perhaps that is the magic value
[11:18] <zyga[m]> it failed in override-build, so pull must have worked, this is great
[11:19] <cjwatson> Phew
[11:20] <zyga[m]> some more cleanup to make it nice to use but this is very promising
[11:26] <zyga[m]> hmm, it still fails but that could be something else
[11:27] <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:30] <zyga[m]> cjwatson: alternatively, is there a way to know launchpad is building the snap? I can disable tests this way
[11:47] <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:48] <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)
[13:17] <cjwatson> If anyone has been wondering about Rust-based snap builds getting stuck on armhf, that should be fixed now
[13:18] <cjwatson> Was quite a weird problem, see https://github.com/lxc/lxcfs/issues/553