[03:48] <brlin> I would like to ask if it's policy-wise possible to embed an external snapcraft recipe(e.g. from another repository, etc) to a source repo and trigger snap build from it.
[05:04] <wgrant> brlin: Can you explain in more detail what you're trying to do?
[05:09] <brlin> @wgrant Currently LP only supports building snaps which source repository contains the Snapcraft recipe, this is not applicable for the software which snapcraft recipe is store in another repository (either not upstreamed or stored separately upon upstream request).  It would be great if we can, for example, set up a code import on LP and set up snap build based on a recipe that is in another repository.
[05:10] <brlin> (Mostly for the benefit of automated snap building upon upstream code changes)
[05:11] <wgrant> brlin: snapcraft.yaml specifies where the source comes from. It's common to have it be the same tree as the one that contains snapcraft.yaml, but it's by no means required
[05:16] <brlin> @wgrant The problem is it's not an easy task to set up automated build if the recipe is separated from the target's source tree.  If external recipe is supported we can reuse the existing code import functionality to set up automated build on new code import.
[05:17] <wgrant> brlin: So your specific problem is that Launchpad won't automatically trigger builds based on changes in other repositories?
[05:18] <brlin> @wgrant Yes.
[05:18] <wgrant> It's best to make a problem statement rather than specifying a solution, because it's much more likely we'd solve the problem by having LP trigger builds based on other repositories perhaps extracted from snapcraft.yaml
[05:18] <brlin> Got it, thanks.
[05:23] <wgrant> brlin: A similar feature was prototyped in build.snapcraft.io, but it's not something that exists in Launchpad itself today. Let me see if we have an existing bug about it.
[05:24] <wgrant> I can't see one.
[05:25] <wgrant> brlin: Please file it at https://bugs.launchpad.net/launchpad/+filebug. Remember to state your use case, not just one potential solution.
[05:25] <brlin> Will do.
[06:24] <brlin> Here's the bug: https://bugs.launchpad.net/launchpad/+bug/1822721
[06:24] <ubot5`> Ubuntu bug 1822721 in Launchpad itself "No way to set up automated snap build on changes in another repository" [Undecided,New]
[10:53] <brlin> I would like to ask if it's difficult to set up an launchpad-buildd instance in a local environment?
[15:16] <hggdh> apt update is taking quite a long time to run now (at least for Disco); mine is downloading at 20kB/s (down from 7MB/s).Is there something going on?
[15:17] <hggdh> (this is for the main archive)
[15:18] <rbasak> hggdh: yes - discussed in #canonical-sysadmin
[15:20] <hggdh> rbasak: thank you sir. Did not think of #c-sysadmin (yeah, rather dumb)
[22:56] <Wimpress> wgrant: Is it possible to setup a PPA that has a real armhf builder, rather than arm64 with cross building?
[22:57] <wgrant> Wimpress: Launchpad doens't cross-build.
[22:57] <wgrant> Wimpress: Our arm64 hardware and arm64 kernels run armhf natively.
[22:57] <Wimpress> OK.
[22:57] <Wimpress> So there are not real armhf builders?
[22:58] <wgrant> No.
[22:58] <Wimpress> Bum.
[22:58] <wgrant> Wimpress: Why?
[22:58] <wgrant> There is never a requirement for them.
[22:58] <Wimpress> Super niche.
[22:58] <wgrant> No, wrong :)
[22:58] <Wimpress> I am building Chromium specifically optimised for the Raspberry Pi.
[22:59] <wgrant> Sure
[22:59] <wgrant> That'll work fine on our arm64 kernels.
[22:59] <Wimpress> Something of the host is leaking because a few components keep trying to link to 64 bit libs and those symbols are not available for libraspberrypi0.
[22:59] <wgrant> The build system is looking at things it shouldn't.
[23:00] <wgrant> We hack uname etc. so it looks like armhf.
[23:00] <Wimpress> I've been able to avoid this issue by disabling ARM Thumb but I've bumped into the same issue elsewhere in the code.
[23:00] <Wimpress> Wondered if I could avoid yet more build system hacking but building on real 32-bit arm host.
[23:01] <wgrant> No, it's best to track down the build system bug.
[23:01] <Wimpress> With 11 hours between build attempts, iteration is slow ;-)
[23:02] <Wimpress> If I build locally is it possible to upload all the assets to a PPA?
[23:02] <wgrant> You can always reproduce it locally with an armhf chroot on an arm64 kernel, with the compat_uts_name kernel commandline hack we use
[23:02] <wgrant> You can't upload binaries to a PPA, no.
[23:02] <wgrant> You should fix the build system bug.
[23:02] <Wimpress> Didn't think so.
[23:02] <Wimpress> Yeah, I am working on the build system. As you can imagine, lots of places to look/check for Chromium.
[23:03] <Wimpress> Wishful think there might be a cheat available :-)
[23:03] <wgrant> The entire Ubuntu archive is built on these, including Chromium, so we're not going to make exceptions for buggy build systems.
[23:05] <Wimpress> Yeah, this is due to patching Chromium to use libraspberrypi0. You can build Chromium just fine when the weirdness of those blobs is not a concern.
[23:06] <wgrant> Ah
[23:06] <wgrant> Wimpress: So hopefully it's easy enough to find the code that runs only in the scenario.
[23:07]  * wgrant just runs arm64 on all his Raspberry Pis
[23:07] <Wimpress> No if you want MMAL exposed you don't ;-)
[23:08] <wgrant> :(
[23:37] <Wimpress> wgrant: I was tryijng to clean up some git imports for Ubuntu MATE earlier. I was unable to delete any git repos in LP. Known issue?
[23:39] <Wimpress> Timeout Error
[23:39] <Wimpress> (Error ID: OOPS-ec138266e390c39a952394eb5c2f10ce)
[23:39] <ubot5`> https://oops.canonical.com/?oopsid=OOPS-ec138266e390c39a952394eb5c2f10ce
[23:40] <wgrant> Wimpress: https://bugs.launchpad.net/launchpad/+bug/1793266
[23:40] <ubot5`> Ubuntu bug 1793266 in Launchpad itself "Unable to delete repository" [Critical,In progress]
[23:40] <wgrant> A fix for the timeout is in progress
[23:40] <Wimpress> Ah OK. Cheers.