User1: I'm building a snap by specifying the source as my local directory, which is a cloned git repository. Under the parts definition, I'm using the "source" key with value "./src". However I see that Snapcraft is also copying files that's outside the "src" directory, notably the .git folder. Is there any way to ignore these extra files?
User2: onyb_fr7, try using "source: ." and "source-subdir: src"
User2: also, always use relative paths without spomething like ./
User2: (i.e. just "src", not "./src")
User3: why is snapd denying opens on files shipped within core?! https://www.irccloud.com/pastebin/ozQJImar/
User3: surely if it's in core it should _never_ be denied
User4: User3 is that library in core?
User3: if it isn't then why does it try to load it there?
User4: (yes, it is)
User3: (there's many libraries in that paste)
User3: I'd like to hear arguments as to why it is desirable to deny access to libraries in core rather than not putting them in core to begin with
User3: doesn't the whole "let's put this in core" kinda suggest that you expect snaps to use it???
User2: why would it allow opening random libs ?
User3: why wouldn't it?
User3: they're in core ffs
User2: the apparmor default profile doesnt blindly grant access to everything
User3: core is "a shared platform that provides a base for all snaps" so if it isn't expected to read the libraries there then why are they there?
User2: especially if youo use /snap/foo/bar/12345/baz
User2: core is your / ...
User2: (from a snaps POV)
User2: why would apparmor allow any snap to access /snap/foo ?
User3: that doesn't make a difference whether it's / or /core/omgzor
User2: it surely does :)
User3: it's core ffs
User3: core is shared. it's meant to be shared.
User2: just open it via /lib/$ARCH ;)
User3: if you don't want us to access libraries from core then don't put them there
User2: yes, it is meant to be shared as your root as /
User2: not via /snap7core
User2: */snap/core
User3: then why is "random snap" trying to read libraries from there when "random snap" hasn't been configured to do so. because something in snapd or the default setup has obviously told it about that location
User2: dunno, missing LD_LIBRARY_PATH entry perhaps ?
User4: or incorrect LD_LIBRARY_PATH overriding existing
User3: how is "not including a path in LD_LIBRARY_PATH" going to make an application decide "oh, I can't find this library. for **ts and giggles I'll look in this completely random arbitrary location that nobody has told me exists"
User2: /snap/core/current/lib/x86_64-linux-gnu is definitely identical to /lib/x86_64-linux-gnu ... but apparmor will definitely block the first
User3: this is a snap that I built. I sure as hell did not tell it about /snap/core
User2: well, something did
User2: probably a bug, probably a missing or wrong LD_LIBRARY_PATH
User3: therefore something in snapd or the snapcraft default wrapper scripts HAS told it about that location. I did not. therefore when I see it accessing that location which I didn't tell it about I assume that snapd has
User3: if snapd is telling my application about a path then I expect that it be readable
User2: probably your snap ships a linker inside while it shouldnt and adds /snap/core to the lib search path
User2: i can only guess here
User3: you seem to assume I'm a newbie
User2: but the DENIAL is definitely correct
User2: you know i'm not :)
User2: but all i can judge here is the DENIAL ... and thats fine ... why you get into that situation is likely a matter of debugging
User3: you're spot on though. ld is included seemingly
User2: aha
User3: wtf did that come from?!
User2: snapcraft should have protected you (IMHO)
User3: yeah that should be a blacklisted thing
User2: just like libc
User3: https://www.irccloud.com/pastebin/bJzKmUo7/
User3: that's all the ld
User3: oh boy https://www.irccloud.com/pastebin/FjigITFo/
User3: so because I've got $SNAP/lib in LD_LIBRARY_PATH it's picking ld-2.23.so from there?
User3: darn and blast it
User4: ooh
User4: good debugging
 * diddledan yells at mycroft only to get no reply because he's got a random ld.so
User3: well foo
User3: I'm annoyed as much at myself as at snapcraft :-p
User3: this is painful :-p
 * diddledan moans more
User3: now to work out how to get mycroft semaphores working
User3: it's using the python multiprocessing module for something and getting permission denied which was what highlighted those others - the semaphore permission denied though doesn't appear to be causing a denied message in the logs :-(
 * diddledan goes to find consolation cookies
 * ogra hands diddledan some hot fresh coffee to have with the cookies
User3: \o/
User3: ...and calm
 * diddledan breathes methodically
User3: https://youtu.be/v30HUOx6SYk?t=50
User2: :D
User3: speaking of snapcraft - kyrofa and I discovered a really random edge case problem - keeping vscode open while compiling a large project that also depends on the alsa remote part I created will cause the build to die part-way through complaining that alsa changed on disk even though it didn't
User3: again that was mycroft that highlighted this one
User3: it seems that vscode will do something while it monitors for git changes that causes the .git folder timestamp to change. combine that with the alsa remote part which doesn't specify a source, therefore meaning `source: .` and you get snapcraft detecting that the source (.) for alsa changing
User2: grr, why does snapcraft close not take an --arch argument
snappy
Ubuntu IRC