[00:15] Hello. I was running a Snapcraft tutorial to refresh my memory and for some reason it assumes the command is snap_name.the_name_I_wrote_In_yaml_file [00:15] Did I do something wrong? [00:17] https://plus.google.com/+Solus-Project/posts/5Cn3P26tbtK <- coolness :D [00:17] first soul to run lsi on ubuntu [00:18] gsilvapt, from what i understand, if the name in apps: matches the snap name, the original name is preserved [00:18] if the app name is different, and no automatic aliasing is permitted for it (by vote), it'll go to $snap.$app [00:18] I just tried that and I think it is not working [00:18] I will try keep $snap and $app name equal and add bin/hello to the command field [00:18] right [00:19] PR snapcraft#1727 closed: integration tests: remove ruby version [00:19] Nope, I get "[...] hello can be found in following packages[...]" error [00:19] ah right so the alias thing [00:20] the name exists in the ubuntu archive so it wont alias it [00:20] is my understanding [00:20] well, it should somehow, that's why the tutorials mentions it [00:20] probably best to poke one of the proper snap guys when they're around, timezones permitting [00:21] When you install the snap, it gives this error. Then you add the app part and it should work after "snapcraft prime" and "snap try" [00:22] the app needs to be named the same as the snap for it to use that name as the command [00:22] so snapcraft.yaml: [00:22] https://www.irccloud.com/pastebin/RaiHmrXU/ [00:23] note the position of the hello [00:23] Please, let me know where they differ because I can't tell the difference: https://pastebin.com/kkrEKGnT [00:23] I've also tried removing the bin part in the command [00:23] your command isn't "hello" [00:23] your command is "gsilva-test-snap" [00:24] so trying to run "hello" won't work [00:24] the only way it works is gsilva-test-snap.hello [00:24] and that configuration doesn't even work [00:24] the snap would need to be named hello too, right? [00:24] no. in that yaml your snap will install a command in /snap/bin called "gsilva-test-snap" [00:24] gsilva-test-snap.hello only works if apps: hello: command: hello is there [00:25] sure but it'd just be "hello" if all those were "hello" [00:25] the command: bit doesn't affect the name of the command it installs [00:26] command: is to tell snapd which executable to call when "gsilva-test-snap" is run [00:26] diddledan, then you're basically telling snapcraft changed its functionality along the way and all guides are out-dated? [00:26] if you change apps: gsilva-test-snap to apps: hello then your app name will be "hello" which differs from the name of your snap so it gets appended with a dot [00:27] no [00:27] I'm not saying that at all [00:27] diddledan, it doesn't work, I already mentioned that. When I put hello instead, the only way I can run the command is if I run gsilva-test-snap.hello - which is basically $snapName.$snapApp [00:28] https://www.irccloud.com/pastebin/ArgrTEEO/ [00:28] Moreover, if I change the snap name to hello, then the command hello works alone [00:28] AHH [00:28] I think I got it [00:28] ow i didnt realise that snapd bind mounts the nvidia driver into the target on multiarch [00:29] ouch [00:29] thats gonna slightly ruin my plans for /var/lib/snapd/gl/32 on ubuntu [00:29] er lib/gl/32 [00:29] that sounds like something to be changed in snapd to support cores other than ubuntu? [00:30] well right now the mount-support-nvidia.c only exposes 64-bit driver to the "guest" [00:30] it's an assumption of filesystem layout which shouldn't be assumed [00:30] i could perhaps change to something like.. [00:30] /var/lib/snapd/lib/gl/vulkan /var/lib/snapd/lib/gl32 /var/lib/snapd/lib/gl [00:31] er [00:31] *lib/vulkan [00:31] Thanks for the help, diddledan and ikey [00:32] np [00:32] yep i think i like that schema more [00:32] in which case ill pull my PRs and send new ones [00:32] and do both multiarch + biarch together [00:36] PR snapd#4199 closed: cmd/snap-confine: Add support for 32-bit NVIDIA on biarch [00:36] PR snapd#4206 closed: cmd/snap-confine: Make the vulkan ICD definition available [00:41] jamesh: Perhaps you might be able to help in https://bugzilla.redhat.com/show_bug.cgi?id=1509586 [00:45] what sounds better, "/var/lib/snapd/lib/gl32" or "/var/lib/snapd/lib/gl.x86" ? [00:46] * ikey is tending towards gl32 [00:46] can't start monday without a bit of bikeshedding :p [00:47] Son_Goku: I'm assuming you've gone? The Fedora issue is definitely in snapd, possibly due to missing polkit config (that definitely should be fixed) and some SELinux permissions needing updating? [00:47] robert_ancell: I'm still here [00:48] I've just been playing a video game for the last few hours :) [00:48] Don't let me interrupt you then :) [00:48] is there a new polkit config I'm supposed to add [00:48] ? [00:48] because this sounds like something new no one told me about [00:48] King_InuYasha: yes. This means we no longer need snapd-login-service 9o/ [00:48] oooo [00:48] that'd be nice [00:49] would you be willing to throw the deets into the bugzilla bug so that I can fix it later? [00:49] King_InuYasha: already there [00:49] I'm struggling to understand the SELinux stuff though, you might know better there [00:50] I suspect that the introduction of snap-seccomp is probably breaking things [00:50] what was *supposed* to happen (and is clearly not) is when stuff like this is introduced, something would flag zyga and myself about things like this that'd break snapd in SELinux [00:51] since snapd _still_ can't generate SELinux policies itself, I have to "unlock the gates" so to speak [00:51] * King_InuYasha is super annoyed that after a year, still no one has started working on supporting SELinux properly [00:51] it's things like this that make me reticent to ship snapd in EPEL [00:52] like, what's the _point_ in shipping snapd for CentOS if I know everything is going to be broken [00:53] and the malarkey about stacked LSMs isn't going to help me at all, because *even if* we stacked AppArmor on SELinux in Fedora, that still doesn't help me for RHEL/CentOS where they're *not* going to do that [00:53] * King_InuYasha has a bone to pick with the security people about this, as this is what keeps diverting attention towards even getting this resolved [00:54] robert_ancell: basically, at some point, I need to collect all the AVC denials _again_ and fill them back into the snapd SELinux policy [00:55] King_InuYasha: just keep iterating until it works? [00:56] * King_InuYasha sighs [00:56] yeah, basically [00:56] it's exhausting, though [00:56] and it's so bloody tedious [00:57] this is the shit work that makes me wonder if it's worth doing all this [00:57] because _no one_ ever helps [00:58] robert_ancell: anyway, it's not your fault [00:58] :( [00:59] you've been pretty helpful whenever I've encountered issues with snapd-glib, so for that I thank you [00:59] but snapd is *hard* [00:59] and on top of this, I *still* need to do the work on snapcraft [00:59] but where's the time? [01:00] King_InuYasha: what's the challenges with snapcraft? [01:01] writing the DNF backend to complement the APT one takes time and effort [01:01] oh, for pulling in deps [01:01] and it's not helping that Snapcraft does weird things with packages [01:01] and on top of it, someone needs to package LXD for Fedora because the lxd snap is garbage and it makes no sense that it isn't in Fedora [01:02] without a working lxd, snapcraft cleanbuild is broken [01:02] I see [01:03] there's already somebody packaging it in COPR (equivalent to PPA), but it should be migrated to the main Fedora repositories [01:03] but the problem is that I'm just one person, and I have so many things I need to do [01:03] oh, at least there's that [01:03] and more stuff keeps piling up [01:04] Sure, please don't burn out! You've been a huge help getting everything working in the Fedora/RH land [01:04] I'm drowning... [01:04] I've been asking for help in the last few sprints, but aside from that short period where morphis was helping zyga, I've got nothing [01:05] and nowadays, I don't even have zyga [01:06] King_InuYasha: where's the snapd packaging stored? I'll try and write the polkit patch for it [01:06] https://src.fedoraproject.org/rpms/snapd [01:07] I've been putting off the 2.29.x rebase for a while, because I know a whole bunch of things have changed [01:07] ubuntu has /usr/lib32 right? [01:07] ikey: no [01:07] as a link [01:08] it shouldn't anymore [01:08] https://github.com/solus-project/linux-steam-integration/issues/35#issuecomment-343777346 [01:08] unless your system is old as shit and you've been upgrading from pre-debplatformlibdirs [01:08] because the nvidia bit looks for "/usr/lib/nvidia-%d" and im tryna figure out how to get the 32-bit equivalent [01:09] you can't [01:09] i suspect it means directly prodding "/usr/lib/i386-linux-gnu" or some nonsense [01:09] yes [01:09] if it's installed there, it'll be there [01:09] 32-bit libraries go into nonsense /usr/lib/ [01:09] that person is on ubuntu 17.10 [01:10] yeah, so the {multiarch} keyword in AppArmor should already take care of that [01:10] i dont think that qualifies as "old as shit" [01:10] thats apparmor [01:10] not C [01:10] i need the actual directory [01:10] oh fuck me [01:10] the fuck is your problem? [01:10] some attitude on you [01:10] something just broke on my end [01:10] ill work it out myself [01:10] my UPS just died [01:11] ... and there goes my beefy rig :/ [01:11] ikey: anyway, the ubuntu multiarch *should* be /usr/lib/i386-linux-gnu [01:11] it *could* also be i686-linux-gnu since Debian did that transition between jessie and stretch [01:11] lemme check real quick [01:12] nah, it's i386-linux-gnu [01:12] https://packages.ubuntu.com/artful/amd64/nvidia-384/filelist [01:12] ugh [01:12] it would appear someone made a legacy-jank-concession [01:12] yeah [01:13] I suspect they didn't realize that it was supposed to go into $(LIBDIR) not $(LIBEXECDIR) [01:13] i feel offended for it and i dont even use multiarch [01:13] so they accidentally borked it for multiarch [01:14] so unfortunately, this is an Ubuntu problem [01:14] there's not really a nice way to deal with this, since they don't set this up correctly: https://packages.ubuntu.com/artful/i386/nvidia-384/filelist [01:15] hm [01:16] In Debian, you're supposed to use platform libdirs to make this work correctly [01:16] ok so i could prod lib and allow fail, and prod lib32, and allow fail [01:16] yeah [01:16] and in apparmor allow lib{,32} [01:16] because apparmor is nice for that [01:16] * King_InuYasha shrugs [01:16] you'd also want to allow lib64, right? [01:16] eehm [01:16] or is that already allowed? [01:16] multiarch is debian only [01:16] really [01:16] and its already doing from "just lib" [01:17] for the biarch stuff then yeah sure [01:17] right, that's what I mean [01:17] we want lib{,32,64} [01:17] and it's not like /usr/lib64 doesn't exist in Debian [01:17] right [01:17] it just only has one library in it [01:17] im thinking something like this [01:17] /var/lib/snapd/lib/gl{,32}/** rm, [01:18] and on the nvidia code mount the 32-bit and 64-bit directories [01:18] on the biarch you'd get two tmpfs's [01:18] with symlink farms [01:18] right [01:18] as opposed to my old method of /32 subdir [01:18] which.. was somewhat short sighted [01:18] now i think of it [01:18] and on deb platform libdirs, you get a single tmpfs [01:18] yeah [01:18] ok so this "allow all the 32bits" should be technically trivial and i think my change is sane [01:18] and ill do vulkan separate [01:19] * King_InuYasha gives ikey a thumbs-up [01:19] because thats probably gonna be a copy the icds into tmpfs jobby [01:19] how do you deal with UsrSplit? [01:19] so biarch in the nvidia code means "/usr/lib" "/usr/lib32" [01:19] aka, the arbitrary moving of libs between / and /usr? [01:20] i.e.: [01:20] "/usr/lib/libEGL.so*", [01:20] we're only dealing with those dudes there [01:20] so no potential for /lib vs /usr/lib jank [01:20] fwiw solus only has ld-linux symlinks in /lib for libraries [01:20] and everything else is in /usr/lib64 (lib -> lib64 link) [01:20] right [01:21] and you have /usr/lib32 for your i686 libs, iirc [01:21] right [01:21] all of this for darned steam eh [01:21] meh [01:22] it's Valve's fault :D [01:22] mm [01:22] they should fix it [01:22] https://hastebin.com/yatafacebe.cs <- seems half sane [01:22] ill need to actually compile it now and test but ya [01:22] to clarify, there should never be a case of /lib/gl64? [01:22] nah [01:22] "lib" is considered "native arch" [01:22] in this context [01:22] and "lib32" is "oh hey i found a lib32 variant lets add him too" [01:23] on 32-bit system "lib" would be 32-bit and lib32 would never mount [01:23] cuz it wouldnt exist [01:23] ... you'd hope [01:23] well i mean it'd be harmless if it did [01:23] technically, on 32-bit Debian and Ubuntu, it does [01:23] lets say someone got cocky on i686 and symlinked lib32 to lib [01:23] so it exists twice [01:23] nothing bad really happens then [01:23] worst case scenario you now have the same tmpfs twice [01:23] and its in LD_LIBRARY_PATH [01:23] well SNAP_LIBRARY_PATH and *potentially* LD_LIBRARY_PATH [01:23] but totally harmless [01:24] ld will just break at the first usable dude [01:24] right [01:24] and for all the other nastiness, liblsi-intercept.so can kick it in the face and say "no" [01:24] :) [01:24] sounds like a plan [01:25] i can add a sanity test to LSI on entry too [01:25] i.e. if /var/lib/snapd/lib/gl/libGL.so.1 exists, but /var/lib/snapd/lib/gl/32/libGL.so.1 *doesn't* exist, start complaining [01:25] if we're 32-bit, complain that store wont work [01:25] if we're 64-bit - complain that nothing will work [01:25] instead of steams entirely unhelpful "libGL.so.1" error dialog [01:27] King_InuYasha: what command do you use to build from git src branches? [01:34] and what's the equivalent of dch? [01:34] robert_ancell: the tool fedpkg is what you're looking for [01:34] and as for bumping changelogs, that rpmdev-bumpspec [01:34] "sudo dnf install /usr/bin/fedpkg /usr/bin/rpmdev-bumpspec" [01:35] King_InuYasha: ta [01:35] for reference: https://www.mankier.com/1/fedpkg & https://www.mankier.com/1/rpmdev-bumpspec [01:37] King_InuYasha: and the equivalent of apt build-dep? [01:39] ah dnf builddep [01:50] yep [01:50] though you can do clean chroot builds by using fedpkg mockbuild when you're in the git repo top dir [01:53] ahh, a couple of hours of Sonic Forces have made me feel a lot better :) [01:58] * ikey flinches at mere mention of games [01:59] cmd/configure:1183:55: "includ" is a misspelling of "include" [01:59] Crushing failure and despair. [01:59] *snort* [02:00] the tests dislike a dirty tree :p [02:01] haha [02:01] ikey: well, if it makes you feel better, Sonic Forces isn't a Linux game [02:01] I have it on Nintendo Switch :) [02:01] aah ok [02:02] I do wish SEGA would release Sonic games for Linux [02:02] but it's unlikely to happen unless someone has an "in" with SEGA [02:02] * King_InuYasha stares intently at ikey [02:02] xD [02:02] nah not me [02:03] :'( [02:03] you don't secretly have someone who knows someone who works on Sonic Team in your back pocket? :P [02:04] naaah [02:04] besides i wouldnt wanna be in my back pocket when i sit down.. [02:04] "ln -s /home/ufee1dead/Projects/snapd src/github.com/snapcore/." [02:04] >_> [02:04] haha [02:05] go doesn't know... shhh :p [02:05] it's the dumbest part about go [02:05] FAIL github.com/snapcore/snapd/cmd/snap-seccomp 1.255s [02:05] Crushing failure and despair. [02:05] aw what [02:05] sometimes I wonder what the fuck Google was thinking when they made that language [02:06] user: unknown user daemon [02:06] sudo useradd daemon -s /bin/true -c "lol" -g daemon [02:06] >_> [02:08] Son_Goku, they played it safe tbh [02:08] >_< [02:08] oh cmon seccomp cruft [02:08] this is just silly now [02:08] now i get https://hastebin.com/raw/omukojuzok [02:09] and i had to create that daemon user [02:09] so - im just gonna ignore all seccomp failures from hereon out [02:09] ^_^ [02:19] ok that change actually works nicely, now to test its apparmor side is ok [02:19] then to stick on vulkan and opencl [02:19] and we're all happy [02:37] bash-4.3$ ls /var/lib/snapd/lib/vulkan [02:37] 10_nvidia.json 10_nvidia_wayland.json [02:37] \o/ [02:37] gah denials.. :D [04:15] PR snapd#4207 opened: Flesh out NVIDIA support for biarch and multiarch systems [05:53] PR snapcraft#1728 opened: beta [05:57] morning guys [07:01] mvo: hi [07:03] hey mborzecki, good morning [07:03] how was your weekend? [07:04] mborzecki: good, weather was a bit annoying, gray and rainy but everything else was fine :) [07:04] great [07:04] mborzecki: and yours? [07:06] we had indenepdence day on the 11th, unfortunately the weather was so bad :/ a bit of rain, a bit of snow and windy [07:07] didn't even try to take my kids to see the festivities [07:10] mborzecki: meh, sounds like we had about the same weather (except no snow here :) [07:13] need to think of a scheme where you stay half a year in europe (the nicer half of the year) and then in the winter you move to southern hemisphere or at least somewhere south there it's cheap and warm [07:14] mborzecki: ask zyga about that, he might have some ideas ;) [07:15] malta should be nice this time of year [07:19] mborzecki: yeah, gosh, malta is nice [07:20] mborzecki: don't tempt me, when I look outside I really want to fly immediately :) [07:20] hahaha [07:22] I will send kids to school and I'll be back soon [07:23] zyga-ubuntu: do you know if 4202 needs a jamie review still? [07:25] looking [07:25] mvo: I think so, he had a look already [07:26] ok [07:27] mvo: today I will do some code reviews and I'll return to 14.04 / lxd issue [07:28] mvo: I also plan to resume looking at brave browser not working on 14.04 [07:28] zyga-ubuntu: sounds good, lets try to fix this for 2.30 [07:29] zyga-ubuntu: posted SNAPD_DEBUG from running brave browser [07:29] mborzecki: thank you, at the forum? [07:29] yup [07:29] I see it now [07:30] I tried running it but it didn't crash outright [07:30] but it didn't start up either [07:30] needs some more digging [07:30] also, have you seen the problem with teleconsole that popey had? [07:31] mborzecki: no, I have not [07:31] https://forum.snapcraft.io/t/brave-and-other-apps-dont-launch-on-arch/2770/9 [07:32] mborzecki: well, I'll be busy today :) [07:32] he's running it in a vm, I tried running in locally and works just fine [07:32] mborzecki: I wonder if that is CPU age difference [07:32] mborzecki: perhaps you just have the specific instruction implemented [07:32] yup, my rough guess is that ld.so does some optimized mmx/sse/avx code and it's not there in the vm [07:33] anyways, it's super weird [07:49] PR snapd#4208 opened: packaging/arch: do not quote MAKEFLAGS [08:08] mvo: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1679191 [08:08] Bug #1679191: Download snap "conjure-up" from channel "stable" (snap not found) [08:10] zyga-ubuntu, got some toys uploaded :p [08:11] ikey: oh? :-) [08:11] i scrapped my 2 PRs and did another last night [08:11] I saw two closed [08:11] which adds multiarch nvidia support [08:11] https://github.com/snapcore/snapd/pull/4207 [08:11] PR #4207: Flesh out NVIDIA support for biarch and multiarch systems [08:11] I didn't go through all of github.com/notifications yet [08:11] it just fixes up nvidia into a nice state [08:11] aha, nice, I'll have a look soon [08:11] i added a link there to the snaps built against that PR if anyone fancies testing them and playing around at some point [08:12] (quite literally "playing" :)) [08:12] haha [08:12] nice, I don't have anything beefy for gaming though [08:12] well, not nvidia [08:12] from my angle I can't see why this PR won't work on ubuntu but id love to have the confidence in that assertion [08:12] oh fwiw open sauce drivers will Just Work ™ on master [08:12] as it contains its own mesa etc [08:12] ikey: we made sure we can now test nvidia a little bit more than before [08:13] oh ok [08:13] * ikey is rocking a 1060 on the laptop so gets to test that stuff [08:13] ikey: both mvo and me have oldish nvidia GPUs for testing [08:13] ah ok [08:13] well if you ever need me to prod anything with a new gpu lemme know [08:14] thank you, I think we will test each candidate core snap this way from now on [08:14] to avoid issues like we had during the last release [08:14] yea [08:14] gonna pick your brains at some point about execution permissions on mount points under snap [08:14] or "why i get EPERM on hostfs mounts" [08:14] but not on ~ [08:14] its gotta be the lower apparmor stuff [08:15] sure [08:15] but > some point [08:15] I'll do my best to help [08:15] i just watched a god awful film and cant brain [08:15] which one? [08:15] "Fallen" [08:15] its on netflix atm [08:15] stinks like a fanfilm of twilight [08:15] and maybe written by a 12 year old [08:16] ikey: I just checked, not available in .pl on netflix [08:16] ikey: likely a feature then :) [08:16] lol ya [08:17] * zyga-ubuntu didn't realize ubuntu had a /usr/lib32 directory [08:17] yeah we were all a bit astonished by that one [08:17] I wish someone wrote a blog explaining the semantics of the FS [08:17] the nvidia driver packages have the lib32 dirs [08:17] is it all just a bunch of legacy [08:17] i was expecting multiarch stuff [08:18] and more legacy [08:18] and compat glue and symlinks on top? [08:18]