| dot-tobias | (Good morning) | 07:32 |
|---|---|---|
| onyb_fr7 | 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? | 10:09 |
| ogra | onyb_fr7, try using "source: ." and "source-subdir: src" | 10:18 |
| ogra | also, always use relative paths without spomething like ./ | 10:19 |
| ogra | (i.e. just "src", not "./src") | 10:19 |
| diddledan | why is snapd denying opens on files shipped within core?! https://www.irccloud.com/pastebin/ozQJImar/ | 16:03 |
| diddledan | surely if it's in core it should _never_ be denied | 16:03 |
| popey | diddledan: is that library in core? | 16:04 |
| diddledan | if it isn't then why does it try to load it there? | 16:04 |
| popey | (yes, it is) | 16:04 |
| diddledan | (there's many libraries in that paste) | 16:04 |
| diddledan | 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 | 16:05 |
| diddledan | doesn't the whole "let's put this in core" kinda suggest that you expect snaps to use it??? | 16:06 |
| ogra | why would it allow opening random libs ? | 16:07 |
| diddledan | why wouldn't it? | 16:07 |
| diddledan | they're in core ffs | 16:07 |
| ogra | the apparmor default profile doesnt blindly grant access to everything | 16:07 |
| diddledan | 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? | 16:07 |
| ogra | especially if youo use /snap/foo/bar/12345/baz | 16:08 |
| ogra | core is your / ... | 16:08 |
| ogra | (from a snaps POV) | 16:08 |
| ogra | why would apparmor allow any snap to access /snap/foo ? | 16:08 |
| diddledan | that doesn't make a difference whether it's / or /core/omgzor | 16:08 |
| ogra | it surely does :) | 16:08 |
| diddledan | it's core ffs | 16:09 |
| diddledan | core is shared. it's meant to be shared. | 16:09 |
| ogra | just open it via /lib/$ARCH ;) | 16:09 |
| diddledan | if you don't want us to access libraries from core then don't put them there | 16:09 |
| ogra | yes, it is meant to be shared as your root as / | 16:10 |
| ogra | not via /snap7core | 16:10 |
| ogra | */snap/core | 16:10 |
| diddledan | 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 | 16:11 |
| ogra | dunno, missing LD_LIBRARY_PATH entry perhaps ? | 16:11 |
| popey | or incorrect LD_LIBRARY_PATH overriding existing | 16:12 |
| diddledan | 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" | 16:12 |
| ogra | /snap/core/current/lib/x86_64-linux-gnu is definitely identical to /lib/x86_64-linux-gnu ... but apparmor will definitely block the first | 16:13 |
| diddledan | this is a snap that I built. I sure as hell did not tell it about /snap/core | 16:13 |
| ogra | well, something did | 16:13 |
| ogra | probably a bug, probably a missing or wrong LD_LIBRARY_PATH | 16:14 |
| diddledan | 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 | 16:14 |
| diddledan | if snapd is telling my application about a path then I expect that it be readable | 16:14 |
| ogra | probably your snap ships a linker inside while it shouldnt and adds /snap/core to the lib search path | 16:14 |
| ogra | i can only guess here | 16:14 |
| diddledan | you seem to assume I'm a newbie | 16:14 |
| ogra | but the DENIAL is definitely correct | 16:14 |
| ogra | you know i'm not :) | 16:15 |
| ogra | but all i can judge here is the DENIAL ... and thats fine ... why you get into that situation is likely a matter of debugging | 16:16 |
| diddledan | you're spot on though. ld is included seemingly | 16:16 |
| ogra | aha | 16:16 |
| diddledan | wtf did that come from?! | 16:16 |
| ogra | snapcraft should have protected you (IMHO) | 16:16 |
| diddledan | yeah that should be a blacklisted thing | 16:16 |
| ogra | just like libc | 16:16 |
| diddledan | https://www.irccloud.com/pastebin/bJzKmUo7/ | 16:17 |
| diddledan | that's all the ld | 16:17 |
| diddledan | oh boy https://www.irccloud.com/pastebin/FjigITFo/ | 16:17 |
| diddledan | so because I've got $SNAP/lib in LD_LIBRARY_PATH it's picking ld-2.23.so from there? | 16:18 |
| diddledan | darn and blast it | 16:19 |
| popey | ooh | 16:19 |
| popey | good debugging | 16:19 |
| * diddledan yells at mycroft only to get no reply because he's got a random ld.so | 16:19 | |
| diddledan | well foo | 16:20 |
| diddledan | I'm annoyed as much at myself as at snapcraft :-p | 16:20 |
| diddledan | this is painful :-p | 16:20 |
| * diddledan moans more | 16:20 | |
| diddledan | now to work out how to get mycroft semaphores working | 16:20 |
| diddledan | 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 :-( | 16:21 |
| * diddledan goes to find consolation cookies | 16:22 | |
| * ogra hands diddledan some hot fresh coffee to have with the cookies | 16:23 | |
| diddledan | \o/ | 16:24 |
| diddledan | ...and calm | 16:24 |
| * diddledan breathes methodically | 16:24 | |
| diddledan | https://youtu.be/v30HUOx6SYk?t=50 | 16:26 |
| ogra | :D | 16:31 |
| diddledan | 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 | 16:33 |
| diddledan | again that was mycroft that highlighted this one | 16:33 |
| diddledan | 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 | 16:35 |
| ogra | grr, why does snapcraft close not take an --arch argument | 20:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!