[07:28] <FrancisANDRE> Hello Launchpad
[07:28] <FrancisANDRE> How can I get rid of this ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
[07:29] <FrancisANDRE> when building on launchpad
[08:15] <cjwatson> mapreri: That's carried over from bzr and will eventually be implemented, but it doesn't mean much yet.
[08:18] <cjwatson> mapreri: I mean, some minimal git subscription mails are implemented, just not anything that's per-commit.
[08:19] <mapreri> cjwatson: oh, I see.  Well, looking forward to it, then :)
[08:23] <cjwatson> FrancisANDRE: Hmm, that is a slightly unusual amount of noise.  Let's see ...
[08:24] <cjwatson> FrancisANDRE: OK, I believe it's because your package (possibly the build/rules/global file) is setting LD_LIBRARY_PATH and discarding any previous value, rather than prepending/appending to it
[08:26] <FrancisANDRE> Ah ok. so appending the old LD_LIBRARY_PATH at this point should solve the noise?
[08:26] <FrancisANDRE> I will bive a try
[08:34] <cjwatson> Should do
[10:34] <stub> Would it be possible for a source package to install a snap as a build dependency? Or would Launchpad likely choke on that due to build environment restrictions?
[10:39] <cjwatson> At present it'd choke.  It would require some thought.
[10:41] <cjwatson> It's not clear how it would work wrt chroots.
[10:44] <wgrant> Not to mention the technical questions, that would also totally destroy any kind of reproducibility.
[10:46] <cjwatson> It may be acceptable for builds of snaps themselves.
[10:46] <cjwatson> e.g. a snapcraft plugin that decided to install a snap
[10:47] <cjwatson> I think we talk to the store via the snap-proxy so it'd only be possible for snap builds anyway.
[10:47] <cjwatson> (I do wish snap builds did more pinning though.)
[10:49] <wgrant> Oh for snap builds maaaaaaybe, but not for source package builds.
[11:02] <stub> As an alternative approach, it might be possible to convert a .snap to a source package which builds to a binary package with the snap embedded and a install script that snap installs it
[11:03] <stub> goal here being to distribute software built with a snapped compiler via PPA
[11:05] <cjwatson> stub: The problem is that snap install is unlikely to work as it stands.
[11:05] <cjwatson> A binary package workaround doesn't help.
[11:06] <cjwatson> Snap builds can talk to the store (we did that for classic builds), but at present classic builds only need to be able to unpack the core snap to /snap/core/current/, not to actually have snap install working.
[11:06] <stub> At what point does it fail? The .snap should get passed through pristine to the point 'snap install' is run
[11:06] <cjwatson> snapd isn't running.
[11:06] <stub> The install would be run when the binary package is installed
[11:06] <cjwatson> Getting it running would require some acrobatics to make sure it's all shut down properly, etc.
[11:07] <stub> No snapd is needed when building the binary package
[11:07] <cjwatson> It sure is if you want snap install to work.
[11:08] <cjwatson> This binary package hack doesn't solve any existing problem on Launchpad builds.
[11:08] <cjwatson> So let's ignore it.
[11:08] <cjwatson> Well, I mean it might solve a PPA distribution problem, sure, that much would be OK.
[11:08] <stub> No, it is an alternative approach if we can't get builders to install snap dependencies
[11:08] <cjwatson> I think we're likely to need to solve that problem at some point.
[11:09] <stub> Ideally I'd like the equivalent in the snap store, and was just considering ugly hacks to avoid waiting.
[11:09] <cjwatson> But the PPA distribution approach still wouldn't allow those packages to be used as a build-dependency.
[11:10] <stub> Yes. And TBH we probably don't want to invest time in snaps as build-dependencies.
[11:11] <cjwatson> It would certainly be a ton of work.
[11:11] <cjwatson> I'd rather have the relationship be one-way, myself.
[11:12] <stub> +1