| gsilvapt | 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 |
|---|---|---|
| gsilvapt | Did I do something wrong? | 00:15 |
| ikey | https://plus.google.com/+Solus-Project/posts/5Cn3P26tbtK <- coolness :D | 00:17 |
| ikey | first soul to run lsi on ubuntu | 00:17 |
| ikey | gsilvapt, from what i understand, if the name in apps: matches the snap name, the original name is preserved | 00:18 |
| ikey | if the app name is different, and no automatic aliasing is permitted for it (by vote), it'll go to $snap.$app | 00:18 |
| gsilvapt | I just tried that and I think it is not working | 00:18 |
| gsilvapt | I will try keep $snap and $app name equal and add bin/hello to the command field | 00:18 |
| ikey | right | 00:18 |
| mup | PR snapcraft#1727 closed: integration tests: remove ruby version <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1727> | 00:19 |
| gsilvapt | Nope, I get "[...] hello can be found in following packages[...]" error | 00:19 |
| ikey | ah right so the alias thing | 00:19 |
| ikey | the name exists in the ubuntu archive so it wont alias it | 00:20 |
| ikey | is my understanding | 00:20 |
| gsilvapt | well, it should somehow, that's why the tutorials mentions it | 00:20 |
| ikey | probably best to poke one of the proper snap guys when they're around, timezones permitting | 00:20 |
| gsilvapt | 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:21 |
| diddledan | the app needs to be named the same as the snap for it to use that name as the command | 00:22 |
| diddledan | so snapcraft.yaml: | 00:22 |
| diddledan | https://www.irccloud.com/pastebin/RaiHmrXU/ | 00:22 |
| diddledan | note the position of the hello | 00:23 |
| gsilvapt | Please, let me know where they differ because I can't tell the difference: https://pastebin.com/kkrEKGnT | 00:23 |
| gsilvapt | I've also tried removing the bin part in the command | 00:23 |
| diddledan | your command isn't "hello" | 00:23 |
| diddledan | your command is "gsilva-test-snap" | 00:23 |
| diddledan | so trying to run "hello" won't work | 00:24 |
| gsilvapt | the only way it works is gsilva-test-snap.hello | 00:24 |
| gsilvapt | and that configuration doesn't even work | 00:24 |
| ikey | the snap would need to be named hello too, right? | 00:24 |
| diddledan | no. in that yaml your snap will install a command in /snap/bin called "gsilva-test-snap" | 00:24 |
| gsilvapt | gsilva-test-snap.hello only works if apps: hello: command: hello is there | 00:24 |
| ikey | sure but it'd just be "hello" if all those were "hello" | 00:25 |
| diddledan | the command: bit doesn't affect the name of the command it installs | 00:25 |
| diddledan | command: is to tell snapd which executable to call when "gsilva-test-snap" is run | 00:26 |
| gsilvapt | diddledan, then you're basically telling snapcraft changed its functionality along the way and all guides are out-dated? | 00:26 |
| diddledan | 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:26 |
| diddledan | no | 00:27 |
| diddledan | I'm not saying that at all | 00:27 |
| gsilvapt | 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:27 |
| diddledan | https://www.irccloud.com/pastebin/ArgrTEEO/ | 00:28 |
| gsilvapt | Moreover, if I change the snap name to hello, then the command hello works alone | 00:28 |
| gsilvapt | AHH | 00:28 |
| gsilvapt | I think I got it | 00:28 |
| ikey | ow i didnt realise that snapd bind mounts the nvidia driver into the target on multiarch | 00:28 |
| diddledan | ouch | 00:29 |
| ikey | thats gonna slightly ruin my plans for /var/lib/snapd/gl/32 on ubuntu | 00:29 |
| ikey | er lib/gl/32 | 00:29 |
| diddledan | that sounds like something to be changed in snapd to support cores other than ubuntu? | 00:29 |
| ikey | well right now the mount-support-nvidia.c only exposes 64-bit driver to the "guest" | 00:30 |
| diddledan | it's an assumption of filesystem layout which shouldn't be assumed | 00:30 |
| ikey | i could perhaps change to something like.. | 00:30 |
| ikey | /var/lib/snapd/lib/gl/vulkan /var/lib/snapd/lib/gl32 /var/lib/snapd/lib/gl | 00:30 |
| ikey | er | 00:31 |
| ikey | *lib/vulkan | 00:31 |
| gsilvapt | Thanks for the help, diddledan and ikey | 00:31 |
| ikey | np | 00:32 |
| ikey | yep i think i like that schema more | 00:32 |
| ikey | in which case ill pull my PRs and send new ones | 00:32 |
| ikey | and do both multiarch + biarch together | 00:32 |
| mup | PR snapd#4199 closed: cmd/snap-confine: Add support for 32-bit NVIDIA on biarch <Created by ikeydoherty> <Closed by ikeydoherty> <https://github.com/snapcore/snapd/pull/4199> | 00:36 |
| mup | PR snapd#4206 closed: cmd/snap-confine: Make the vulkan ICD definition available <Created by ikeydoherty> <Closed by ikeydoherty> <https://github.com/snapcore/snapd/pull/4206> | 00:36 |
| robert_ancell | jamesh: Perhaps you might be able to help in https://bugzilla.redhat.com/show_bug.cgi?id=1509586 | 00:41 |
| ikey | what sounds better, "/var/lib/snapd/lib/gl32" or "/var/lib/snapd/lib/gl.x86" ? | 00:45 |
| * ikey is tending towards gl32 | 00:46 | |
| ikey | can't start monday without a bit of bikeshedding :p | 00:46 |
| robert_ancell | 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 |
| King_InuYasha | robert_ancell: I'm still here | 00:47 |
| King_InuYasha | I've just been playing a video game for the last few hours :) | 00:48 |
| robert_ancell | Don't let me interrupt you then :) | 00:48 |
| King_InuYasha | is there a new polkit config I'm supposed to add | 00:48 |
| King_InuYasha | ? | 00:48 |
| King_InuYasha | because this sounds like something new no one told me about | 00:48 |
| robert_ancell | King_InuYasha: yes. This means we no longer need snapd-login-service 9o/ | 00:48 |
| King_InuYasha | oooo | 00:48 |
| King_InuYasha | that'd be nice | 00:48 |
| King_InuYasha | would you be willing to throw the deets into the bugzilla bug so that I can fix it later? | 00:49 |
| robert_ancell | King_InuYasha: already there | 00:49 |
| robert_ancell | I'm struggling to understand the SELinux stuff though, you might know better there | 00:49 |
| King_InuYasha | I suspect that the introduction of snap-seccomp is probably breaking things | 00:50 |
| King_InuYasha | 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:50 |
| King_InuYasha | 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 | |
| King_InuYasha | it's things like this that make me reticent to ship snapd in EPEL | 00:51 |
| King_InuYasha | like, what's the _point_ in shipping snapd for CentOS if I know everything is going to be broken | 00:52 |
| King_InuYasha | 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:53 | |
| King_InuYasha | 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:54 |
| robert_ancell | King_InuYasha: just keep iterating until it works? | 00:55 |
| * King_InuYasha sighs | 00:56 | |
| King_InuYasha | yeah, basically | 00:56 |
| King_InuYasha | it's exhausting, though | 00:56 |
| King_InuYasha | and it's so bloody tedious | 00:56 |
| King_InuYasha | this is the shit work that makes me wonder if it's worth doing all this | 00:57 |
| King_InuYasha | because _no one_ ever helps | 00:57 |
| King_InuYasha | robert_ancell: anyway, it's not your fault | 00:58 |
| robert_ancell | :( | 00:58 |
| King_InuYasha | you've been pretty helpful whenever I've encountered issues with snapd-glib, so for that I thank you | 00:59 |
| King_InuYasha | but snapd is *hard* | 00:59 |
| King_InuYasha | and on top of this, I *still* need to do the work on snapcraft | 00:59 |
| King_InuYasha | but where's the time? | 00:59 |
| robert_ancell | King_InuYasha: what's the challenges with snapcraft? | 01:00 |
| King_InuYasha | writing the DNF backend to complement the APT one takes time and effort | 01:01 |
| robert_ancell | oh, for pulling in deps | 01:01 |
| King_InuYasha | and it's not helping that Snapcraft does weird things with packages | 01:01 |
| King_InuYasha | 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:01 |
| King_InuYasha | without a working lxd, snapcraft cleanbuild is broken | 01:02 |
| robert_ancell | I see | 01:02 |
| King_InuYasha | there's already somebody packaging it in COPR (equivalent to PPA), but it should be migrated to the main Fedora repositories | 01:03 |
| King_InuYasha | but the problem is that I'm just one person, and I have so many things I need to do | 01:03 |
| robert_ancell | oh, at least there's that | 01:03 |
| King_InuYasha | and more stuff keeps piling up | 01:03 |
| robert_ancell | Sure, please don't burn out! You've been a huge help getting everything working in the Fedora/RH land | 01:04 |
| King_InuYasha | I'm drowning... | 01:04 |
| King_InuYasha | 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:04 |
| King_InuYasha | and nowadays, I don't even have zyga | 01:05 |
| robert_ancell | King_InuYasha: where's the snapd packaging stored? I'll try and write the polkit patch for it | 01:06 |
| King_InuYasha | https://src.fedoraproject.org/rpms/snapd | 01:06 |
| King_InuYasha | 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 |
| ikey | ubuntu has /usr/lib32 right? | 01:07 |
| King_InuYasha | ikey: no | 01:07 |
| ikey | as a link | 01:07 |
| King_InuYasha | it shouldn't anymore | 01:08 |
| ikey | https://github.com/solus-project/linux-steam-integration/issues/35#issuecomment-343777346 | 01:08 |
| King_InuYasha | unless your system is old as shit and you've been upgrading from pre-debplatformlibdirs | 01:08 |
| ikey | because the nvidia bit looks for "/usr/lib/nvidia-%d" and im tryna figure out how to get the 32-bit equivalent | 01:08 |
| King_InuYasha | you can't | 01:09 |
| ikey | i suspect it means directly prodding "/usr/lib/i386-linux-gnu" or some nonsense | 01:09 |
| King_InuYasha | yes | 01:09 |
| King_InuYasha | if it's installed there, it'll be there | 01:09 |
| King_InuYasha | 32-bit libraries go into nonsense /usr/lib/<platform-triple> | 01:09 |
| ikey | that person is on ubuntu 17.10 | 01:09 |
| King_InuYasha | yeah, so the {multiarch} keyword in AppArmor should already take care of that | 01:10 |
| ikey | i dont think that qualifies as "old as shit" | 01:10 |
| ikey | thats apparmor | 01:10 |
| ikey | not C | 01:10 |
| ikey | i need the actual directory | 01:10 |
| King_InuYasha | oh fuck me | 01:10 |
| ikey | the fuck is your problem? | 01:10 |
| ikey | some attitude on you | 01:10 |
| King_InuYasha | something just broke on my end | 01:10 |
| ikey | ill work it out myself | 01:10 |
| King_InuYasha | my UPS just died | 01:10 |
| King_InuYasha | ... and there goes my beefy rig :/ | 01:11 |
| King_InuYasha | ikey: anyway, the ubuntu multiarch *should* be /usr/lib/i386-linux-gnu | 01:11 |
| King_InuYasha | it *could* also be i686-linux-gnu since Debian did that transition between jessie and stretch | 01:11 |
| King_InuYasha | lemme check real quick | 01:11 |
| King_InuYasha | nah, it's i386-linux-gnu | 01:12 |
| ikey | https://packages.ubuntu.com/artful/amd64/nvidia-384/filelist | 01:12 |
| King_InuYasha | ugh | 01:12 |
| ikey | it would appear someone made a legacy-jank-concession | 01:12 |
| King_InuYasha | yeah | 01:12 |
| King_InuYasha | I suspect they didn't realize that it was supposed to go into $(LIBDIR) not $(LIBEXECDIR) | 01:13 |
| ikey | i feel offended for it and i dont even use multiarch | 01:13 |
| King_InuYasha | so they accidentally borked it for multiarch | 01:13 |
| King_InuYasha | so unfortunately, this is an Ubuntu problem | 01:14 |
| King_InuYasha | 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:14 |
| ikey | hm | 01:15 |
| King_InuYasha | In Debian, you're supposed to use platform libdirs to make this work correctly | 01:16 |
| ikey | ok so i could prod lib and allow fail, and prod lib32, and allow fail | 01:16 |
| King_InuYasha | yeah | 01:16 |
| ikey | and in apparmor allow lib{,32} | 01:16 |
| ikey | because apparmor is nice for that | 01:16 |
| * King_InuYasha shrugs | 01:16 | |
| King_InuYasha | you'd also want to allow lib64, right? | 01:16 |
| ikey | eehm | 01:16 |
| King_InuYasha | or is that already allowed? | 01:16 |
| ikey | multiarch is debian only | 01:16 |
| ikey | really | 01:16 |
| ikey | and its already doing from "just lib" | 01:16 |
| ikey | for the biarch stuff then yeah sure | 01:17 |
| King_InuYasha | right, that's what I mean | 01:17 |
| ikey | we want lib{,32,64} | 01:17 |
| King_InuYasha | and it's not like /usr/lib64 doesn't exist in Debian | 01:17 |
| ikey | right | 01:17 |
| King_InuYasha | it just only has one library in it | 01:17 |
| ikey | im thinking something like this | 01:17 |
| ikey | /var/lib/snapd/lib/gl{,32}/** rm, | 01:17 |
| ikey | and on the nvidia code mount the 32-bit and 64-bit directories | 01:18 |
| ikey | on the biarch you'd get two tmpfs's | 01:18 |
| ikey | with symlink farms | 01:18 |
| King_InuYasha | right | 01:18 |
| ikey | as opposed to my old method of /32 subdir | 01:18 |
| ikey | which.. was somewhat short sighted | 01:18 |
| ikey | now i think of it | 01:18 |
| King_InuYasha | and on deb platform libdirs, you get a single tmpfs | 01:18 |
| ikey | yeah | 01:18 |
| ikey | ok so this "allow all the 32bits" should be technically trivial and i think my change is sane | 01:18 |
| ikey | and ill do vulkan separate | 01:18 |
| * King_InuYasha gives ikey a thumbs-up | 01:19 | |
| ikey | because thats probably gonna be a copy the icds into tmpfs jobby | 01:19 |
| King_InuYasha | how do you deal with UsrSplit? | 01:19 |
| ikey | so biarch in the nvidia code means "/usr/lib" "/usr/lib32" | 01:19 |
| King_InuYasha | aka, the arbitrary moving of libs between / and /usr? | 01:19 |
| ikey | i.e.: | 01:20 |
| ikey | "/usr/lib/libEGL.so*", | 01:20 |
| ikey | we're only dealing with those dudes there | 01:20 |
| ikey | so no potential for /lib vs /usr/lib jank | 01:20 |
| ikey | fwiw solus only has ld-linux symlinks in /lib for libraries | 01:20 |
| ikey | and everything else is in /usr/lib64 (lib -> lib64 link) | 01:20 |
| King_InuYasha | right | 01:20 |
| King_InuYasha | and you have /usr/lib32 for your i686 libs, iirc | 01:21 |
| ikey | right | 01:21 |
| ikey | all of this for darned steam eh | 01:21 |
| King_InuYasha | meh | 01:21 |
| King_InuYasha | it's Valve's fault :D | 01:22 |
| ikey | mm | 01:22 |
| King_InuYasha | they should fix it | 01:22 |
| ikey | https://hastebin.com/yatafacebe.cs <- seems half sane | 01:22 |
| ikey | ill need to actually compile it now and test but ya | 01:22 |
| King_InuYasha | to clarify, there should never be a case of /lib/gl64? | 01:22 |
| ikey | nah | 01:22 |
| ikey | "lib" is considered "native arch" | 01:22 |
| ikey | in this context | 01:22 |
| ikey | and "lib32" is "oh hey i found a lib32 variant lets add him too" | 01:22 |
| ikey | on 32-bit system "lib" would be 32-bit and lib32 would never mount | 01:23 |
| ikey | cuz it wouldnt exist | 01:23 |
| King_InuYasha | ... you'd hope | 01:23 |
| ikey | well i mean it'd be harmless if it did | 01:23 |
| King_InuYasha | technically, on 32-bit Debian and Ubuntu, it does | 01:23 |
| ikey | lets say someone got cocky on i686 and symlinked lib32 to lib | 01:23 |
| ikey | so it exists twice | 01:23 |
| King_InuYasha | nothing bad really happens then | 01:23 |
| ikey | worst case scenario you now have the same tmpfs twice | 01:23 |
| ikey | and its in LD_LIBRARY_PATH | 01:23 |
| ikey | well SNAP_LIBRARY_PATH and *potentially* LD_LIBRARY_PATH | 01:23 |
| ikey | but totally harmless | 01:23 |
| ikey | ld will just break at the first usable dude | 01:24 |
| King_InuYasha | right | 01:24 |
| ikey | and for all the other nastiness, liblsi-intercept.so can kick it in the face and say "no" | 01:24 |
| King_InuYasha | :) | 01:24 |
| King_InuYasha | sounds like a plan | 01:24 |
| ikey | i can add a sanity test to LSI on entry too | 01:25 |
| ikey | 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 |
| ikey | if we're 32-bit, complain that store wont work | 01:25 |
| ikey | if we're 64-bit - complain that nothing will work | 01:25 |
| ikey | instead of steams entirely unhelpful "libGL.so.1" error dialog | 01:25 |
| robert_ancell | King_InuYasha: what command do you use to build from git src branches? | 01:27 |
| robert_ancell | and what's the equivalent of dch? | 01:34 |
| King_InuYasha | robert_ancell: the tool fedpkg is what you're looking for | 01:34 |
| King_InuYasha | and as for bumping changelogs, that rpmdev-bumpspec | 01:34 |
| King_InuYasha | "sudo dnf install /usr/bin/fedpkg /usr/bin/rpmdev-bumpspec" | 01:34 |
| robert_ancell | King_InuYasha: ta | 01:35 |
| King_InuYasha | for reference: https://www.mankier.com/1/fedpkg & https://www.mankier.com/1/rpmdev-bumpspec | 01:35 |
| robert_ancell | King_InuYasha: and the equivalent of apt build-dep? | 01:37 |
| robert_ancell | ah dnf builddep | 01:39 |
| King_InuYasha | yep | 01:50 |
| King_InuYasha | though you can do clean chroot builds by using fedpkg mockbuild when you're in the git repo top dir | 01:50 |
| King_InuYasha | ahh, a couple of hours of Sonic Forces have made me feel a lot better :) | 01:53 |
| * ikey flinches at mere mention of games | 01:58 | |
| ikey | cmd/configure:1183:55: "includ" is a misspelling of "include" | 01:59 |
| ikey | Crushing failure and despair. | 01:59 |
| ikey | *snort* | 01:59 |
| ikey | the tests dislike a dirty tree :p | 02:00 |
| King_InuYasha | haha | 02:01 |
| King_InuYasha | ikey: well, if it makes you feel better, Sonic Forces isn't a Linux game | 02:01 |
| King_InuYasha | I have it on Nintendo Switch :) | 02:01 |
| ikey | aah ok | 02:01 |
| King_InuYasha | I do wish SEGA would release Sonic games for Linux | 02:02 |
| King_InuYasha | but it's unlikely to happen unless someone has an "in" with SEGA | 02:02 |
| * King_InuYasha stares intently at ikey | 02:02 | |
| ikey | xD | 02:02 |
| ikey | nah not me | 02:02 |
| King_InuYasha | :'( | 02:03 |
| King_InuYasha | you don't secretly have someone who knows someone who works on Sonic Team in your back pocket? :P | 02:03 |
| ikey | naaah | 02:04 |
| ikey | besides i wouldnt wanna be in my back pocket when i sit down.. | 02:04 |
| ikey | "ln -s /home/ufee1dead/Projects/snapd src/github.com/snapcore/." | 02:04 |
| ikey | >_> | 02:04 |
| Son_Goku | haha | 02:04 |
| ikey | go doesn't know... shhh :p | 02:05 |
| Son_Goku | it's the dumbest part about go | 02:05 |
| ikey | FAILgithub.com/snapcore/snapd/cmd/snap-seccomp1.255s | 02:05 |
| ikey | Crushing failure and despair. | 02:05 |
| ikey | aw what | 02:05 |
| Son_Goku | sometimes I wonder what the fuck Google was thinking when they made that language | 02:05 |
| ikey | user: unknown user daemon | 02:06 |
| ikey | sudo useradd daemon -s /bin/true -c "lol" -g daemon | 02:06 |
| ikey | >_> | 02:06 |
| ikey | Son_Goku, they played it safe tbh | 02:08 |
| Son_Goku | >_< | 02:08 |
| ikey | oh cmon seccomp cruft | 02:08 |
| ikey | this is just silly now | 02:08 |
| ikey | now i get https://hastebin.com/raw/omukojuzok | 02:08 |
| ikey | and i had to create that daemon user | 02:09 |
| ikey | so - im just gonna ignore all seccomp failures from hereon out | 02:09 |
| ikey | ^_^ | 02:09 |
| ikey | ok that change actually works nicely, now to test its apparmor side is ok | 02:19 |
| ikey | then to stick on vulkan and opencl | 02:19 |
| ikey | and we're all happy | 02:19 |
| ikey | bash-4.3$ ls /var/lib/snapd/lib/vulkan | 02:37 |
| ikey | 10_nvidia.json10_nvidia_wayland.json | 02:37 |
| ikey | \o/ | 02:37 |
| ikey | gah denials.. :D | 02:37 |
| mup | PR snapd#4207 opened: Flesh out NVIDIA support for biarch and multiarch systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4207> | 04:15 |
| mup | PR snapcraft#1728 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1728> | 05:53 |
| mborzecki | morning guys | 05:57 |
| mborzecki | mvo: hi | 07:01 |
| mvo | hey mborzecki, good morning | 07:03 |
| mborzecki | how was your weekend? | 07:03 |
| mvo | mborzecki: good, weather was a bit annoying, gray and rainy but everything else was fine :) | 07:04 |
| mborzecki | great | 07:04 |
| mvo | mborzecki: and yours? | 07:04 |
| mborzecki | we had indenepdence day on the 11th, unfortunately the weather was so bad :/ a bit of rain, a bit of snow and windy | 07:06 |
| mborzecki | didn't even try to take my kids to see the festivities | 07:07 |
| mvo | mborzecki: meh, sounds like we had about the same weather (except no snow here :) | 07:10 |
| mborzecki | 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:13 |
| mvo | mborzecki: ask zyga about that, he might have some ideas ;) | 07:14 |
| mborzecki | malta should be nice this time of year | 07:15 |
| mvo | mborzecki: yeah, gosh, malta is nice | 07:19 |
| mvo | mborzecki: don't tempt me, when I look outside I really want to fly immediately :) | 07:20 |
| mborzecki | hahaha | 07:20 |
| zyga-ubuntu | I will send kids to school and I'll be back soon | 07:22 |
| mvo | zyga-ubuntu: do you know if 4202 needs a jamie review still? | 07:23 |
| zyga-ubuntu | looking | 07:25 |
| zyga-ubuntu | mvo: I think so, he had a look already | 07:25 |
| mvo | ok | 07:26 |
| zyga-ubuntu | mvo: today I will do some code reviews and I'll return to 14.04 / lxd issue | 07:27 |
| zyga-ubuntu | mvo: I also plan to resume looking at brave browser not working on 14.04 | 07:28 |
| mvo | zyga-ubuntu: sounds good, lets try to fix this for 2.30 | 07:28 |
| mborzecki | zyga-ubuntu: posted SNAPD_DEBUG from running brave browser | 07:29 |
| zyga-ubuntu | mborzecki: thank you, at the forum? | 07:29 |
| mborzecki | yup | 07:29 |
| zyga-ubuntu | I see it now | 07:29 |
| zyga-ubuntu | I tried running it but it didn't crash outright | 07:30 |
| zyga-ubuntu | but it didn't start up either | 07:30 |
| zyga-ubuntu | needs some more digging | 07:30 |
| mborzecki | also, have you seen the problem with teleconsole that popey had? | 07:30 |
| zyga-ubuntu | mborzecki: no, I have not | 07:31 |
| mborzecki | https://forum.snapcraft.io/t/brave-and-other-apps-dont-launch-on-arch/2770/9 | 07:31 |
| zyga-ubuntu | mborzecki: well, I'll be busy today :) | 07:32 |
| mborzecki | he's running it in a vm, I tried running in locally and works just fine | 07:32 |
| zyga-ubuntu | mborzecki: I wonder if that is CPU age difference | 07:32 |
| zyga-ubuntu | mborzecki: perhaps you just have the specific instruction implemented | 07:32 |
| mborzecki | yup, my rough guess is that ld.so does some optimized mmx/sse/avx code and it's not there in the vm | 07:32 |
| mborzecki | anyways, it's super weird | 07:33 |
| mup | PR snapd#4208 opened: packaging/arch: do not quote MAKEFLAGS <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4208> | 07:49 |
| zyga-ubuntu | mvo: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1679191 | 08:08 |
| mup | Bug #1679191: Download snap "conjure-up" from channel "stable" (snap not found) <snapd (Ubuntu):New> <https://launchpad.net/bugs/1679191> | 08:08 |
| ikey | zyga-ubuntu, got some toys uploaded :p | 08:10 |
| zyga-ubuntu | ikey: oh? :-) | 08:11 |
| ikey | i scrapped my 2 PRs and did another last night | 08:11 |
| zyga-ubuntu | I saw two closed | 08:11 |
| ikey | which adds multiarch nvidia support | 08:11 |
| ikey | https://github.com/snapcore/snapd/pull/4207 | 08:11 |
| mup | PR #4207: Flesh out NVIDIA support for biarch and multiarch systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4207> | 08:11 |
| zyga-ubuntu | I didn't go through all of github.com/notifications yet | 08:11 |
| ikey | it just fixes up nvidia into a nice state | 08:11 |
| zyga-ubuntu | aha, nice, I'll have a look soon | 08:11 |
| ikey | i added a link there to the snaps built against that PR if anyone fancies testing them and playing around at some point | 08:11 |
| ikey | (quite literally "playing" :)) | 08:12 |
| zyga-ubuntu | haha | 08:12 |
| zyga-ubuntu | nice, I don't have anything beefy for gaming though | 08:12 |
| zyga-ubuntu | well, not nvidia | 08:12 |
| ikey | 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 |
| ikey | oh fwiw open sauce drivers will Just Work ™ on master | 08:12 |
| ikey | as it contains its own mesa etc | 08:12 |
| zyga-ubuntu | ikey: we made sure we can now test nvidia a little bit more than before | 08:12 |
| ikey | oh ok | 08:13 |
| * ikey is rocking a 1060 on the laptop so gets to test that stuff | 08:13 | |
| zyga-ubuntu | ikey: both mvo and me have oldish nvidia GPUs for testing | 08:13 |
| ikey | ah ok | 08:13 |
| ikey | well if you ever need me to prod anything with a new gpu lemme know | 08:13 |
| zyga-ubuntu | thank you, I think we will test each candidate core snap this way from now on | 08:14 |
| zyga-ubuntu | to avoid issues like we had during the last release | 08:14 |
| ikey | yea | 08:14 |
| ikey | gonna pick your brains at some point about execution permissions on mount points under snap | 08:14 |
| ikey | or "why i get EPERM on hostfs mounts" | 08:14 |
| ikey | but not on ~ | 08:14 |
| ikey | its gotta be the lower apparmor stuff | 08:14 |
| zyga-ubuntu | sure | 08:15 |
| ikey | but > some point | 08:15 |
| zyga-ubuntu | I'll do my best to help | 08:15 |
| ikey | i just watched a god awful film and cant brain | 08:15 |
| zyga-ubuntu | which one? | 08:15 |
| ikey | "Fallen" | 08:15 |
| ikey | its on netflix atm | 08:15 |
| ikey | stinks like a fanfilm of twilight | 08:15 |
| ikey | and maybe written by a 12 year old | 08:15 |
| zyga-ubuntu | ikey: I just checked, not available in .pl on netflix | 08:16 |
| zyga-ubuntu | ikey: likely a feature then :) | 08:16 |
| ikey | lol ya | 08:16 |
| * zyga-ubuntu didn't realize ubuntu had a /usr/lib32 directory | 08:17 | |
| ikey | yeah we were all a bit astonished by that one | 08:17 |
| zyga-ubuntu | I wish someone wrote a blog explaining the semantics of the FS | 08:17 |
| ikey | the nvidia driver packages have the lib32 dirs | 08:17 |
| zyga-ubuntu | is it all just a bunch of legacy | 08:17 |
| ikey | i was expecting multiarch stuff | 08:17 |
| zyga-ubuntu | and more legacy | 08:18 |
| zyga-ubuntu | and compat glue and symlinks on top? | 08:18 |
| jamesh | lib32 is for the x32 pseudo-architecture, IIRC | 08:18 |
| ikey | nah thats libx32 | 08:18 |
| zyga-ubuntu | jamesh: yeah, that's not x32 | 08:18 |
| * zyga-ubuntu played with x32 last week for some pet project | 08:18 | |
| ikey | https://packages.ubuntu.com/zesty/amd64/nvidia-375/filelist | 08:18 |
| ikey | *shrug* | 08:19 |
| jamesh | zyga-ubuntu: I think I've got everything addressed in my snap-update-ns PR. It now removes even more lines of code | 08:19 |
| mborzecki | huh, weren't these supposed to be under /lib/<arch-tuple> ? | 08:19 |
| ikey | im guessing theres a reason for it | 08:19 |
| ikey | more than likely due to the subdirring | 08:19 |
| ikey | and update-alternatives and all that junk | 08:19 |
| ikey | or the more elegant name of "compounded beastliness" | 08:20 |
| ikey | on the other hand it made my PR a whole bunch simpler :P | 08:20 |
| ikey | fwiw i figured these changes will allow me to follow up with a very simple cuda/opencl enabling PR at some point when i have the ocl-icd patch ready | 08:23 |
| ikey | as it'll be a clone almost of the vulkan change | 08:23 |
| ikey | then we can enable opencl/cuda in snaps trivially | 08:23 |
| ikey | (handy for games and blender / nvcc etc) | 08:23 |
| zyga-ubuntu | jamesh: hey, I'll gladly look shortly | 08:26 |
| mwhudson | zyga-ubuntu: i finally poked at snapd 2.29.3 for debian, turns out we need a newer golang-dbus but that should be easy enough | 08:28 |
| zyga-ubuntu | mwhudson: thank you! I have my debian box back but I wasn't doing any packaging for a good while now | 08:29 |
| ikey | wondering if i could export some parts of LSI shim as part of an entry point for normal snaps.. | 08:31 |
| ikey | ive seen the desktop-helper bash scripts.. | 08:31 |
| ikey | got quite a bit of bootstrap code here https://github.com/solus-project/linux-steam-integration/blob/master/src/shim/shim.c#L189 | 08:32 |
| ikey | might come in useful | 08:32 |
| zyga-ubuntu | ikey: entry point .. hmm | 08:34 |
| zyga-ubuntu | ikey: you could just put that in a base snap and provide something like lsi-run ... | 08:34 |
| ikey | yeah | 08:34 |
| ikey | ive been considering an lsi-exec fwiw | 08:34 |
| ikey | for other non-steam stuff | 08:35 |
| ikey | mostly for fixing old busted stuff and for the shim side of it.. | 08:35 |
| ikey | its certainly been an interesting experience really getting into the guts of how all this works | 08:35 |
| ikey | like figuring out how to make .desktop files actually work work | 08:35 |
| ikey | without snapcraft | 08:35 |
| zyga-ubuntu | yeah :-) | 08:36 |
| zyga-ubuntu | I really like the largely free-form of packaging this offers | 08:36 |
| ikey | we're doing a bit of evil in building our snaps atm | 08:36 |
| ikey | we're using the solus tooling to emit the roots and then snap packing them | 08:37 |
| zyga-ubuntu | nothing is evil there | 08:37 |
| ikey | but then we can do this: https://github.com/solus-project/runtime-snaps/tree/master/support_packages | 08:37 |
| ikey | and we're overlaying even the normal solus pkgs | 08:37 |
| ikey | so we stuck a brand new mesa in, some compat libs, etc | 08:37 |
| ikey | and fwiw, the "make this root good for snapd" isn't that hard | 08:38 |
| ikey | https://github.com/solus-project/runtime-snaps/blob/master/round1.sh#L28 | 08:39 |
| ikey | that one function cleans it up and makes it appropriate for use | 08:39 |
| ikey | i reversed the lib64 directories to make the apparmor stuff happy for now | 08:39 |
| ikey | im confident i could modify that script to spit out a base for any given distro | 08:40 |
| zyga-ubuntu | darn, this brave snap doesn't work anywhere | 08:42 |
| mborzecki | anywhere, but my laptop | 08:43 |
| zyga-ubuntu | mborzecki: I get nothing, ranging from "some spewing errors" to exiting silently | 08:43 |
| mborzecki | I get a bunch of logs and a browser window | 08:44 |
| zyga-ubuntu | woot | 08:45 |
| zyga-ubuntu | mborzecki: it just started on 17.10 natively on nvidia | 08:45 |
| zyga-ubuntu | that's interesting | 08:45 |
| zyga-ubuntu | but it failed on 17.10 with much more recent cpu on intel!?! | 08:45 |
| * zyga-ubuntu looks | 08:45 | |
| zyga-ubuntu | the old one is i7 though | 08:45 |
| zyga-ubuntu | the new one is i5 | 08:45 |
| mborzecki | 'snap run brave' vs 'brave' shouldn't be a problem? | 08:46 |
| zyga-ubuntu | mborzecki: no, it's the same thing | 08:46 |
| zyga-ubuntu | brave is "curious" | 08:47 |
| zyga-ubuntu | it gets brave-download.globa.ssl.fastly.net/multi-channel/releases/dev/0.19.89/linux64/Brave.tar.bz2 | 08:47 |
| mborzecki | https://i.imgur.com/AR0oW6U.png | 08:48 |
| mborzecki | would that be much of a problem if run-checks became #!/bin/bash rather than #!/bin/sh script? | 08:49 |
| zyga-ubuntu | mborzecki: I think it's fine | 08:49 |
| zyga-ubuntu | mborzecki: but consider /bin/env/python3 :) | 08:49 |
| mborzecki | you could make it a go script :) #!/usr/bin/env go run | 08:49 |
| ikey | is it just arch that its busted on? | 08:49 |
| zyga-ubuntu | ikey: no, it works on arch | 08:50 |
| mborzecki | for once | 08:50 |
| ikey | o | 08:50 |
| zyga-ubuntu | ikey: I think it's only affected by CPU features | 08:50 |
| ikey | works here on solus fwiw | 08:50 |
| zyga-ubuntu | ikey: it's a strictly confined snap | 08:50 |
| ikey | https://ibin.co/3h8KV3PWG8Qr.png | 08:50 |
| * zyga-ubuntu is still digging | 08:50 | |
| ikey | --edge, w: | 08:50 |
| zyga-ubuntu | how do you do those pictures? | 08:50 |
| ikey | CPU: Quad core Intel Core i7-7700HQ (-HT-MCP-) cache 6144 KB | 08:50 |
| ikey | clock speeds max 3800 MHz 1 3701 MHz 2 3609 MHz 3 3502 MHz 4 3703 MHz 5 3799 MHz 6 3600 MHz | 08:50 |
| ikey | 7 3601 MHz 8 3600 MHz | 08:50 |
| ikey | Graphics: Card NVIDIA GP106M [GeForce GTX 1060 Mobile 6GB] | 08:50 |
| ikey | Display Server x11 (X.Org 1.18.4 ) driver nvidia Resolution 1920x1080@60.00hz | 08:50 |
| ikey | OpenGL renderer GeForce GTX 1060/PCIe/SSE2 version 4.5.0 NVIDIA 384.98 | 08:50 |
| ikey | imagebin.ca for le pics | 08:50 |
| zyga-ubuntu | 7700HQ, faaast | 08:51 |
| ikey | this is a laptop believe it or not | 08:51 |
| ikey | xD | 08:51 |
| ikey | terrified to unplug it | 08:51 |
| === JoshStrobl|zzz is now known as JoshStrobl | ||
| zyga-ubuntu | I'm on Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz | 08:51 |
| ikey | ah nice | 08:52 |
| zyga-ubuntu | but... | 08:52 |
| ikey | does look like brave has some bugs though tbh | 08:52 |
| zyga-ubuntu | something is fishy | 08:52 |
| zyga-ubuntu | as fish and chips | 08:52 |
| zyga-ubuntu | ;-) | 08:52 |
| ikey | my terminal spam is cranky | 08:52 |
| zyga-ubuntu | on my W510 it runs in 17.10 native | 08:53 |
| zyga-ubuntu | and doesn't start in a 16.04 vm | 08:53 |
| ikey | ive learned to not expect quality from anything that based itself around chromium | 08:53 |
| zyga-ubuntu | on that same box | 08:53 |
| ikey | error handling is a lost artform | 08:53 |
| zyga-ubuntu | G | 08:54 |
| zyga-ubuntu | I'm sleepy | 08:54 |
| zyga-ubuntu | it was 14.04 | 08:54 |
| ikey | heh | 08:54 |
| zyga-ubuntu | ok, I'll look at 16.04 | 08:54 |
| ikey | chromium error handling ~= java error handling.. | 08:54 |
| ikey | try { noShitsGiven(); } catch (Error e) { /* Still not caring */ } | 08:54 |
| ikey | exception, w/e it is | 08:55 |
| * ikey has been lucky to not java in a long time :P | 08:55 | |
| zyga-ubuntu | err := doStuff() | 08:55 |
| ikey | if err != nil .. | 08:55 |
| ikey | lol | 08:55 |
| zyga-ubuntu | if err != nil { err = nil } // suck it | 08:55 |
| ikey | or my fav | 08:55 |
| ikey | if err != nil { err2 = err } | 08:55 |
| ikey | for the deferred return error swaps | 08:55 |
| * ikey shudders a bit | 08:56 | |
| * ikey hugs C | 08:56 | |
| zyga-ubuntu | I'll look at debian sid now | 08:56 |
| zyga-ubuntu | and then go to 16.04 | 08:56 |
| zyga-ubuntu | yeah, I love C too | 08:56 |
| ikey | :D | 08:56 |
| mwhudson | zyga-ubuntu: lolwhut | 08:56 |
| mwhudson | (sid-amd64)root@aeglos:/build/snapd-CzeWTt/snapd-2.29.3.1# strings _build/bin/snapd|grep -E "public-key-sha3-384: [a-zA-Z0-9_-]{64}" | 08:56 |
| mwhudson | public-key-sha3-384: d-JcZF9nD9eBw7bwMnH61x-bklnQOhQud1Is6o_cn2wTj8EYDi9musrIT9z2MdAa | 08:56 |
| mwhudson | public-key-sha3-384: -CvQKAwRQ5h3Ffn10FILJoEZUXOv6km9FwA80-Rcj-f-6jadQ89VRswHNiEB9Lxk | 08:56 |
| ikey | "if you blow your foot off, its your own damn fault. you told me to" = C | 08:56 |
| zyga-ubuntu | mm? | 08:57 |
| zyga-ubuntu | there are two keys now | 08:57 |
| zyga-ubuntu | one for generic something something | 08:57 |
| zyga-ubuntu | and one root key | 08:57 |
| zyga-ubuntu | something something is something that pedronis is deeply familiar with | 08:57 |
| mup | PR snapd#4209 opened: run-checks, tests/lib/snaps/: shellcheck fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4209> | 08:57 |
| mwhudson | zyga-ubuntu: ah ok so this is a change i need to bring over to my d/rules i guess | 08:58 |
| zyga-ubuntu | mwhudson: yes, it's a desired thing | 08:58 |
| ikey | does it make you cry a bit inside having to package up something intended for easy packaging, with something as god awful as debian/rules? | 08:59 |
| ikey | xD | 08:59 |
| zyga-ubuntu | man, I need to find a better VGA cable | 08:59 |
| * ikey ducks out | 08:59 | |
| zyga-ubuntu | ikey: snappy is the $MESSIAH of packaging | 09:00 |
| zyga-ubuntu | endure the pain once | 09:00 |
| zyga-ubuntu | bring salvation to everyone | 09:00 |
| ikey | oooo idk i think i got you beat there | 09:00 |
| zyga-ubuntu | oh | 09:01 |
| zyga-ubuntu | shiny | 09:01 |
| ikey | whatdat? | 09:02 |
| zyga-ubuntu | https://twitter.com/zygoon/status/929997883583160320 | 09:02 |
| ikey | wow | 09:02 |
| ikey | yknow thats systemd speak for "I have no idea what I'm doing anymore, I'm kinda hoping udev is gonna bail me out here" | 09:03 |
| zyga-ubuntu | "jinle bells jingle bells, system-s up-to-date" | 09:03 |
| zyga-ubuntu | this is the offline update | 09:03 |
| ikey | oh what fun it is to write | 09:03 |
| zyga-ubuntu | I just never saw it before | 09:03 |
| mvo | zyga-ubuntu: hrm, hrm, second test this morning that exceededthe time limit for jobs, maybe we need to do something about it | 09:03 |
| zyga-ubuntu | hehe | 09:03 |
| ikey | how much you love systemd on void linux forums | 09:03 |
| ikey | jingle bells.. | 09:03 |
| zyga-ubuntu | mvo: maybe we need to bump the number of machines again? | 09:04 |
| mup | PR snapd#4201 closed: tests/lib: handle distro specific grub-editenv naming <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4201> | 09:04 |
| mvo | zyga-ubuntu: yeah, lets see if it was a fluke, otherwise its a topic for the standup | 09:05 |
| zyga-ubuntu | agreed | 09:05 |
| mup | PR snapd#4191 closed: cmd/snap-update-ns: do not assume 'nogroup' exists <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4191> | 09:05 |
| * ikey goes to bed.. damn timezone switch | 09:14 | |
| zyga-ubuntu | ikey: o/ | 09:15 |
| ikey | \o | 09:15 |
| zyga-ubuntu | ikey: not in europe anymore? | 09:15 |
| ikey | i am | 09:16 |
| ikey | 4 years working for a US employer and being on their timezones will permanently screw your internal clock | 09:16 |
| zyga-ubuntu | mvo: when do we promote 2.29.3? | 09:16 |
| zyga-ubuntu | hmmm | 09:18 |
| mvo | zyga-ubuntu: depends on cachio and CE giving us green light | 09:18 |
| zyga-ubuntu | 2.27.6 in debian doesn't work very well now | 09:18 |
| zyga-ubuntu | (in sid) | 09:18 |
| mvo | zyga-ubuntu: but hopefully today or tomorrow | 09:19 |
| pstolowski | mvo, hey, #4177 needs your re-review, I think it's very close to land | 09:20 |
| mup | PR #4177: state: add change.LaneTasks helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/4177> | 09:20 |
| zyga-ubuntu | mvo: debian is broken now | 09:29 |
| zyga-ubuntu | mvo: we probably didn't notice because our image is really tracking debian-9 | 09:29 |
| mwhudson | wow snapd.postrm is lots of fun | 09:29 |
| zyga-ubuntu | mwhudson: I just posted about debian on the forum | 09:29 |
| zyga-ubuntu | mwhudson: I wonder if it's any better with 2.29.3? | 09:29 |
| mwhudson | oh apparmor | 09:30 |
| mwhudson | well 2.29 _should_ be better right | 09:30 |
| mwhudson | ? | 09:30 |
| mwhudson | it has all that graceful apparmor degradation stuff | 09:31 |
| mwhudson | i'm a bit surprised because snap-confine was working with apparmor enabled | 09:31 |
| zyga-ubuntu | mwhudson: well, not sure, the "graceful" aspect was for apps, not snap-confine | 09:31 |
| mwhudson | but i guess a new kernel enforces more rules now? | 09:31 |
| zyga-ubuntu | mwhudson: what does it do for you? | 09:32 |
| mwhudson | eh i haven't tried it in a while | 09:32 |
| zyga-ubuntu | mwhudson: note that this is still 4.13, 4.14 will have more features | 09:32 |
| mwhudson | zyga-ubuntu: yes, everyone in the whole world saw the enormous flamewar about that | 09:32 |
| zyga-ubuntu | mwhudson: you mean "security and linus" thread or something else? | 09:33 |
| mwhudson | i guess i don't mean a flamewar, i mean linus shouting at people yes | 09:35 |
| zyga-ubuntu | right, I just wanted to ensure there's nothing _else_ :-) | 09:36 |
| zyga-ubuntu | it's not a flamewar when you are being nuked from orbit | 09:36 |
| mup | PR snapd#4177 closed: state: add change.LaneTasks helper <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4177> | 09:46 |
| pstolowski | mvo, thanks! | 09:46 |
| mvo | pstolowski: thank you! | 09:46 |
| mwhudson | zyga-ubuntu: yeah i get the same denials | 09:50 |
| zyga-ubuntu | mwhudson: thank you for confirming that | 09:50 |
| zyga-ubuntu | mwhudson: looks like we need some love there | 09:50 |
| mwhudson | zyga-ubuntu: we could go back to the hack that installs an empty /etc/apparmor.d/usr.lib.snapd.snap-confine.real | 09:53 |
| mwhudson | but i don't want to | 09:53 |
| mup | PR snapd#4208 closed: packaging/arch: do not quote MAKEFLAGS <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4208> | 09:54 |
| mup | PR snapd#4152 closed: snapd: fix snap cookie bugs <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4152> | 09:55 |
| mwhudson | zyga-ubuntu: the installed file looks like it's trying to grant snap-confine the ability to ptrace things :/ | 09:55 |
| mwhudson | zyga-ubuntu: is it possible the debian kernel maintainers screwed something up? | 09:56 |
| mwhudson | zyga-ubuntu: maybe you can ask jd-strand in a few hours? | 09:56 |
| mwhudson | :) | 09:56 |
| zyga-ubuntu | mwhudson: I think this is how the old kernel reacts to open /proc/1/ns/mnt | 10:00 |
| zyga-ubuntu | mwhudson: I'll try to fix this today | 10:00 |
| mvo | zyga-ubuntu: hey, quick question, do you have an opinion about the question here https://github.com/snapcore/snapd/pull/4161#discussion_r149996883 ? | 10:00 |
| mup | PR #4161: snapstate: add support for refresh.schedule=managed <Created by mvo5> <https://github.com/snapcore/snapd/pull/4161> | 10:00 |
| zyga-ubuntu | looking | 10:01 |
| zyga-ubuntu | mvo: replied | 10:02 |
| mvo | ta | 10:02 |
| mvo | zyga-ubuntu: thanks, I like the reply :) | 10:02 |
| zyga-ubuntu | JamieBennett: man, that is one interesting thread | 10:05 |
| zyga-ubuntu | thank you for sharing | 10:05 |
| JamieBennett | zyga-ubuntu: Indeed, AppArmor on Debian will be great. | 10:06 |
| mborzecki | is it possible to update review sprint page withouth niemeyer around? | 10:16 |
| zyga-ubuntu | mborzecki: no, I think not | 10:16 |
| zyga-ubuntu | AFAIK there's a cron thing that refreshes it | 10:16 |
| zyga-ubuntu | but ask gustavo later today | 10:16 |
| mborzecki | zyga-ubuntu: did you get a chance to look at? https://github.com/snapcore/snapd/pull/4185#issuecomment-343520761 :) | 10:17 |
| mup | PR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185> | 10:17 |
| andyrock | hey are snaps mounted always under /snap | 10:19 |
| andyrock | ? | 10:19 |
| zyga-ubuntu | mborzecki: not yet | 10:20 |
| zyga-ubuntu | andyrock: hey | 10:20 |
| zyga-ubuntu | andyrock: no, not always | 10:20 |
| zyga-ubuntu | andyrock: some distributions don't like that and move the mount point to /var/lib/snap | 10:20 |
| zyga-ubuntu | andyrock: however for all snaps that are not using classic confinement, at runtime, the snap will be mounted in /snap/ | 10:20 |
| andyrock | zyga-ubuntu mmm I'm working on a fix to hide the snap loop devices from gnome-disk-utility | 10:21 |
| zyga-ubuntu | andyrock: I see | 10:21 |
| zyga-ubuntu | andyrock: we can add a mount option, perhaps, that would say "dont show me" | 10:21 |
| zyga-ubuntu | andyrock: but I'm not aware of any | 10:21 |
| zyga-ubuntu | andyrock: x-app-container x-snapd.snap, or somthing like that | 10:22 |
| zyga-ubuntu | *something | 10:22 |
| andyrock | zyga-ubuntu: 'x-app-container x-snapd.snap' didn't get this part | 10:25 |
| zyga-ubuntu | andyrock: ah, sorry, there's a trend to annotate mount entries using mount options named x-... | 10:25 |
| zyga-ubuntu | andyrock: they don't do anything for the kernel but they are picked up by userspace | 10:25 |
| zyga-ubuntu | andyrock: for instance, gnome-disks makes heavy use of this | 10:26 |
| zyga-ubuntu | andyrock: allowing the use of specific mount flags to choose how the mount point is represented in the UI | 10:26 |
| zyga-ubuntu | andyrock: (icons, labels, show/hide, etc) | 10:26 |
| andyrock | oh nice | 10:26 |
| andyrock | yeah that would be useful | 10:26 |
| andyrock | let me check | 10:26 |
| zyga-ubuntu | I was proposing that we simply come up with a "this is not a filesystem users care about" flag | 10:26 |
| zyga-ubuntu | maybe there is one we can reuse already, I didn't look | 10:27 |
| andyrock | let me ask upstream | 10:27 |
| zyga-ubuntu | andyrock: thank you, let me know if there's something we can adapt in snapd to make this easier | 10:32 |
| * zyga-ubuntu will soon go AFK to relocate to a different site | 10:33 | |
| mvo | pedronis: hey, good morning. a quick question, I'm looking at https://github.com/snapcore/snapd/pull/4161#discussion_r149998237 right now (for the refresh.schedule=managed branch) and assertstate is a circular import from snapstate. should I create overlord/assertstate/db and move the ReplaceDB,DB code in there and import from snapstate? (similar to what we did for the iface repo access)? | 10:51 |
| mup | PR #4161: snapstate: add support for refresh.schedule=managed <Created by mvo5> <https://github.com/snapcore/snapd/pull/4161> | 10:51 |
| popey | zyga-ubuntu: is there a typo in https://forum.snapcraft.io/t/brave-browser-snap-on-14-04-wont-launch/2767/7 ? | 11:08 |
| popey | "Arch starts", did you mean the snap starts? | 11:08 |
| zyga-ubuntu | popey: yes | 11:08 |
| zyga-ubuntu | popey: I'll edit the post with some new data soon, I'm still working on this | 11:08 |
| popey | kk | 11:09 |
| zyga-ubuntu | popey: question for you, what was the CPU you used? | 11:09 |
| popey | it's a vm | 11:09 |
| popey | so whatever virtualbox makes available? | 11:09 |
| popey | I can cat cpuinfo in the vm if that helps? | 11:09 |
| zyga-ubuntu | popey: yes | 11:09 |
| zyga-ubuntu | popey: though outside can help too | 11:10 |
| popey | added to the thread | 11:11 |
| zyga-ubuntu | popey: hmm, you have a much newer CPU than I do | 11:12 |
| zyga-ubuntu | popey: so I don't think I'm missing instructions | 11:12 |
| zyga-ubuntu | s/I'm/you are/ | 11:12 |
| pedronis | mvo: I don't know, it's a bit a unclear what belongs where | 11:14 |
| zyga-ubuntu | ok I need to get going | 11:15 |
| zyga-ubuntu | ttyl | 11:16 |
| mvo | pedronis: ok, I ignore it for now while working on a spread test | 11:17 |
| mvo | pedronis: we can talk later | 11:17 |
| pedronis | mvo: I added a comment to the PR about what I think | 11:19 |
| mvo | ta | 11:24 |
| niemeyer | mborzecki: That's how it ought to work.. I'm waiting for timer services to get this somewhere else..(wink wink) | 11:52 |
| niemeyer | mborzecki: There's also a small issue with not publishing my key in a random machine, but that's easy to solve by creating a user just for that | 11:53 |
| niemeyer | mborzecki: It was updated half an hour ago or so, btw | 11:54 |
| zyga-ubuntu | re | 12:00 |
| zyga-ubuntu | :-) | 12:00 |
| niemeyer | Hellos :) | 12:00 |
| zyga-ubuntu | niemeyer: hey :) | 12:02 |
| zyga-ubuntu | niemeyer: it's raining but I decided not to stay indoors, there's some noise around and it was driving me nuts | 12:02 |
| zyga-ubuntu | I'm in a coffee shop nearby, really nice mood with lots of laptop-bearing people | 12:03 |
| zyga-ubuntu | I wonder if they are all remote workers like me | 12:03 |
| niemeyer | Nice | 12:04 |
| niemeyer | I may still build an open-ended co-working place around me some day | 12:05 |
| niemeyer | Quite like the idea | 12:05 |
| zyga-ubuntu | niemeyer: ara did that back a few years ago | 12:05 |
| zyga-ubuntu | niemeyer: she used to run the place for a few years | 12:05 |
| niemeyer | Wow, nice.. didn't know that.. would like to have asked her about details | 12:05 |
| niemeyer | (in person) | 12:05 |
| niemeyer | I've been to places elsewhere that I quite enjoyed for the atmosphere and facilities | 12:06 |
| zyga-ubuntu | yeah, I recall she said people matter a lot, I mean having a group of people that want to do this and would be the inhabitants | 12:07 |
| zyga-ubuntu | it seems obvious perhaps but the people make it or break it | 12:07 |
| zyga-ubuntu | as if just that :) | 12:07 |
| zyga-ubuntu | re, had to reboot for my modem suddently died | 12:17 |
| zyga-ubuntu | jdstrand: hey | 12:25 |
| zyga-ubuntu | jdstrand: I have two questions for you today: | 12:26 |
| zyga-ubuntu | jdstrand: first of all, I recall the recent changes to SUBSYSTEM=usb vs SUBSYSTEMS=usb, we did that for some interfaces but not all of them, is this intentional? | 12:26 |
| zyga-ubuntu | jdstrand: second question is how do you think we should proceed on debian as sid has recently enabled apparmor by default and the profile for snap-confine no longer works (ironically I think this is related to linus' opinion on breaking userspace) | 12:27 |
| zyga-ubuntu | jdstrand: the question is: should we generate an extra snippet for "4.13 vanilla" for snap-confine so that things still work or should we instead alter the profile to be more permissive in general? | 12:28 |
| zyga-ubuntu | jdstrand: I'd like to fix this as soon as we can and include it with 2.29.3 update that mwhudson is working on | 12:28 |
| ogra_ | or fix linus :) | 12:28 |
| zyga-ubuntu | ogra_: I'll buy him a mac and a gameboy | 12:28 |
| ogra_ | haha | 12:28 |
| ogra_ | i didnt say "bribe" | 12:29 |
| zyga-ubuntu | no no, it's just a gift to keep him busy | 12:29 |
| zyga-ubuntu | look at this new zelda episode | 12:29 |
| ogra_ | heh | 12:29 |
| zyga-ubuntu | 100 hours of gameplay | 12:29 |
| zyga-ubuntu | ;-) | 12:29 |
| zyga-ubuntu | use the wiimote to aling the frying pan while you make scrambled eggs in the wilderness | 12:29 |
| === JoshStrobl is now known as JoshStrobl|Store | ||
| mup | PR snapcraft#1729 opened: sources: use arfile to extract debs <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1729> | 12:31 |
| zyga-ubuntu | sergiusens: oh, going low-level I see | 12:31 |
| ogra_ | hardcore ! | 12:31 |
| zyga-ubuntu | sergiusens: did you implement arfile? | 12:31 |
| zyga-ubuntu | I had a copy somewhere... | 12:31 |
| sergiusens | zyga-ubuntu I reused the one in debian | 12:31 |
| sergiusens | zyga-ubuntu the debian python pkg that is | 12:31 |
| zyga-ubuntu | ah, it's in debian module nowadays, easy | 12:31 |
| zyga-ubuntu | I impemented one in python2.x days for command-not-found | 12:32 |
| zyga-ubuntu | (eons ago) | 12:32 |
| sergiusens | zyga-ubuntu import DebFile loads up apt_inst for some "$reason" which expects /etc/apt to exist | 12:32 |
| zyga-ubuntu | sergiusens: is that package easy to install on !ubuntu? | 12:32 |
| sergiusens | zyga-ubuntu according to Son_Goku it is in fedora | 12:33 |
| zyga-ubuntu | sergiusens: interesting, cool | 12:33 |
| sergiusens | zyga-ubuntu but this is mostly a problem when we run as a snap | 12:33 |
| Son_Goku | geez: https://apps.fedoraproject.org/packages/python3-debian | 12:33 |
| Son_Goku | it's not even hard to verify | 12:33 |
| Son_Goku | you say it as if you don't believe me | 12:33 |
| * zyga-ubuntu hugs Son_Goku | 12:34 | |
| sergiusens | Son_Goku no, I say it as you being the point of verification ;-) | 12:34 |
| ogra_ | you didnt bribe him enough ... | 12:34 |
| Son_Goku | the problem is that our apt is too old to support python-apt | 12:34 |
| zyga-ubuntu | ogra_: but he already has a gameboy :( | 12:34 |
| Son_Goku | so python-debian is a bit gimped | 12:34 |
| ogra_ | zyga-ubuntu, but no mac | 12:34 |
| Son_Goku | after all, this is the apt we have: https://apps.fedoraproject.org/packages/apt | 12:34 |
| zyga-ubuntu | ogra_: what do you mean, he uses a mac all the time | 12:35 |
| ogra_ | uh | 12:35 |
| zyga-ubuntu | last time I looked at least | 12:35 |
| zyga-ubuntu | ogra_: not macos though :) | 12:35 |
| sergiusens | I really hope we could get rid of this apt stuff in our code, it is somewhat messy | 12:35 |
| * ogra_ sdmittedly didnt pay attention to that | 12:35 | |
| sergiusens | but I am not sure we'd do a better job going down our own path | 12:35 |
| ogra_ | *admittedly | 12:35 |
| * ogra_ hands bitbake and meta-debian to sergiusens | 12:36 | |
| * sergiusens rejects any offering of more work | 12:36 | |
| jdstrand | zyga-ubuntu: re SUBSYSTEM vs SUBSYSTEMS> it was all in how we used SUBSYSTEMS. I checked for other wrong uses of it and there were none that I saw. SUBSYSTEMS is a perfectly valid directive with the right usage; where I changed it we were using it wrong. in other words, I don't think there is anything else we need to worry about wrt that | 12:36 |
| zyga-ubuntu | jdstrand: thank you for clarifying that | 12:37 |
| zyga-ubuntu | CC mvo ^ you asked about that a while ago | 12:37 |
| zyga-ubuntu | mvo: tl;dr version is that we're okay and no action is required for 2.29.3 | 12:37 |
| jdstrand | zyga-ubuntu: I'd like to see the denial for snap-confine to decide | 12:37 |
| sergiusens | zyga-ubuntu read you used gnome boxes, does solus work for you on it? I can get through a live session installing, but x doesn't seem to be coming up correctly after the install | 12:38 |
| zyga-ubuntu | jdstrand: it's right here: https://forum.snapcraft.io/t/snapd-2-27-6-2-in-debian-sid-blocked-on-apparmor-in-kernel-4-13-0-1/2813/3 | 12:38 |
| zyga-ubuntu | sergiusens: solus is native for me | 12:38 |
| zyga-ubuntu | sergiusens: as for gnome-boxes | 12:38 |
| zyga-ubuntu | sergiusens: it's all _rough_, install virt-manager | 12:38 |
| zyga-ubuntu | sergiusens: and change display type to virtio (from qlx) | 12:39 |
| zyga-ubuntu | sergiusens: then things work better | 12:39 |
| zyga-ubuntu | sergiusens: some of my VMs work with qxl (is it qxl or qls) some don't | 12:39 |
| zyga-ubuntu | sergiusens: the rest work ok with virtio | 12:39 |
| zyga-ubuntu | sergiusens: it's a hit/miss, sometimes switching virtual VTs around helps | 12:39 |
| zyga-ubuntu | sergiusens: but in general nothing I tried failed when I used the fallback | 12:40 |
| zyga-ubuntu | sergiusens: I use it for a range of systems now, having abandoned vmware | 12:40 |
| jdstrand | zyga-ubuntu: I'm puzzled why snap-confine is ptracing itself | 12:40 |
| zyga-ubuntu | sergiusens: vmware was much more mature if you are on windows or on older LTS | 12:40 |
| zyga-ubuntu | jdstrand: it's not, this is, IMO, the open/stat on /proc/1/ns/mnt | 12:41 |
| zyga-ubuntu | jdstrand: I recall seeing this | 12:41 |
| zyga-ubuntu | jdstrand: as we were implemeting the feature | 12:41 |
| jdstrand | no, it is | 12:41 |
| zyga-ubuntu | jdstrand: of breaking out of snap ns | 12:41 |
| jdstrand | there are different things about ptrace, but it is doing 'trace' and 'tracedby' | 12:41 |
| jdstrand | ptrace read/readby I might've expected | 12:42 |
| zyga-ubuntu | jdstrand: it's also doing that on /proc/self/ns/mnt | 12:42 |
| zyga-ubuntu | jdstrand: so maybe _that_ is causing itt? | 12:42 |
| mborzecki | + echo 'ERROR: test-snapd-requires-base should not be installable without test-snapd-base' | 12:42 |
| mborzecki | ERROR: test-snapd-requires-base should not be installable without test-snapd-base | 12:42 |
| zyga-ubuntu | jdstrand: in general it's trivial to reproduce, sid just always triggers it now and any snap is good to test | 12:42 |
| mborzecki | expected?? ^ | 12:42 |
| zyga-ubuntu | mborzecki: probably no, mvo's topic I think | 12:42 |
| jdstrand | it might be that the kernel reorganized things to group that open/stat into tracec/tracedby | 12:42 |
| jdstrand | zyga-ubuntu: this says it is with 2.27.6. what about a modern snap-confine? | 12:43 |
| zyga-ubuntu | jdstrand: interestingly it's 4.13 bit without out-of-tree apparmor patch | 12:43 |
| zyga-ubuntu | jdstrand: same | 12:43 |
| zyga-ubuntu | jdstrand: mwhudson confirmed that shortly after I reported it | 12:43 |
| zyga-ubuntu | (on IRC) | 12:43 |
| zyga-ubuntu | s/bit/but/ | 12:44 |
| zyga-ubuntu | jdstrand: so "same as ubuntu exept for patch" ~~ mostly | 12:44 |
| jdstrand | zyga-ubuntu: I think we should have Tyler or jj weigh in. they would probably be able to comment better on the missing out of tree patches | 12:44 |
| zyga-ubuntu | jdstrand: ack, I'll look out for them | 12:44 |
| zyga-ubuntu | jdstrand: I'd like to fix this as it will affect every distribution that is on the same kernel and pulls in apparmor | 12:45 |
| ogra_ | andyrock, did you consider hiding the snap loop mounts on a lower level ... i.e. udev ... like it does for vendor recovery partitions etc in /lib/udev/rules.d/80-udisks2.rules | 12:45 |
| zyga-ubuntu | jdstrand: jjohansen ^^ can you please comemnt on https://forum.snapcraft.io/t/snapd-2-27-6-2-in-debian-sid-blocked-on-apparmor-in-kernel-4-13-0-1/2813 -- the context is that debian is now shipping apparmor and enabled by default and we are seeing some unexpected denials on their stock 4.13 kernel; we are looking for possible solutions to overcome the problem but would like your insight into what may | 12:46 |
| jdstrand | zyga-ubuntu: is it not using mount-namespace-capture-helper for some reason? | 12:46 |
| zyga-ubuntu | be causing the trace/tracedby mediation there | 12:46 |
| zyga-ubuntu | jdstrand: it definitely does that but that's later | 12:46 |
| zyga-ubuntu | jdstrand: this stage is before we even fork, to see if we are in the right ns | 12:46 |
| jdstrand | zyga-ubuntu: we have 'ptrace trace peer=unconfined,' for that now | 12:47 |
| zyga-ubuntu | jdstrand: is the peer confined if we are tracing ourselves? | 12:47 |
| jdstrand | # allow snap-confine to read /proc/1/ns/mnt | 12:47 |
| jdstrand | ptrace trace peer=unconfined, | 12:47 |
| zyga-ubuntu | I mean, snap-confine does look at itself then | 12:47 |
| zyga-ubuntu | (after looking at PID 1) | 12:47 |
| jdstrand | zyga-ubuntu: the peer is us if we are ptracing ourselves, so, yes | 12:47 |
| zyga-ubuntu | jdstrand: so ptrace trace peer=$LIBEXECDIR/snapd/snap-confine, | 12:48 |
| zyga-ubuntu | ? | 12:48 |
| jdstrand | the rule would be: | 12:48 |
| jdstrand | ptrace (trace, tracedby) peer=$LIBEXECDIR/snapd/snap-confine, | 12:49 |
| zyga-ubuntu | I'll test that | 12:49 |
| jdstrand | but why doesn't Ubuntu need the patch if that has always been the case? | 12:49 |
| zyga-ubuntu | it looks like something to go into the regular profile | 12:49 |
| zyga-ubuntu | yes, I was wondering that myself | 12:49 |
| zyga-ubuntu | I was about to ask | 12:49 |
| zyga-ubuntu | can we see via --some-magic-option | 12:49 |
| zyga-ubuntu | when apparmor_parser says, yeah fine but not understood/implemented so I'll skip this rule | 12:50 |
| zyga-ubuntu | this question came up in the debian thread | 12:50 |
| jdstrand | I don't know, we need jjohansen to comment now I think. 4.13 and Ubuntu shouldn't be acting differently in this regard I don't think. there seems to be a bug somewhere | 12:50 |
| zyga-ubuntu | and I was wondering if you know if that's accurate enough to find bugs in our profile | 12:50 |
| jdstrand | zyga-ubuntu: oh | 12:50 |
| zyga-ubuntu | jdstrand: yes, looks like so | 12:50 |
| jdstrand | zyga-ubuntu: so on Debian with 4.13, the ptrace rule is not recognized? | 12:51 |
| jdstrand | zyga-ubuntu: by the parser? | 12:51 |
| zyga-ubuntu | jdstrand: not sure, I didn't try as I found about that that in the opposite order | 12:51 |
| zyga-ubuntu | jdstrand: I found the bug and then read on the thread that jamie bennett linked to | 12:51 |
| zyga-ubuntu | jdstrand: I just made the connection now recalling this | 12:51 |
| jdstrand | zyga-ubuntu: I didn't read all of your comment. there is no option like that, no | 12:52 |
| zyga-ubuntu | (my ram is a bit used up by 16.04/lxd experiment but I can try shortly) | 12:52 |
| zyga-ubuntu | jdstrand: I see | 12:52 |
| jdstrand | what the parser does is look at the sysfs and makes decisions. you could mock up a sysfs without the ptrace rule if you wanted, but I'm not sure why that is interesting for this | 12:52 |
| zyga-ubuntu | jdstrand: I'll look around, I have two more debugging runs to do | 12:53 |
| zyga-ubuntu | jdstrand: lxd is top priority for now | 12:53 |
| zyga-ubuntu | jdstrand: then weird works on 16.04, breaks on 14.04 for strict snap | 12:53 |
| zyga-ubuntu | jdstrand: btw, as we are talking, I could use your review on https://github.com/snapcore/snapd/pull/4163 | 12:54 |
| mup | PR #4163: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} <Created by zyga> <https://github.com/snapcore/snapd/pull/4163> | 12:54 |
| zyga-ubuntu | jdstrand: it's just a re-factor but I wanted to make sure you ack it | 12:54 |
| zyga-ubuntu | jdstrand: I need it to build other features on top | 12:54 |
| zyga-ubuntu | (not a refactor just for the sake of it) | 12:54 |
| zyga-ubuntu | it has two +1s alredy | 12:54 |
| jdstrand | zyga-ubuntu: yes, this is the one from last week that is at the top of my list | 12:56 |
| zyga-ubuntu | jdstrand: thank you | 12:56 |
| zyga-ubuntu | jdstrand: I commented on the debian thread and I'll look into it again today to verify if the extra rule makes things work | 12:57 |
| andyrock | ogra_: UDISKS_IGNORE is ignored by gnome-disk-utilities | 13:03 |
| ogra_ | andyrock, uuh, why is that ? | 13:03 |
| andyrock | it makes sense | 13:04 |
| andyrock | UDISKS_IGNORE is used on a bunch of partitions | 13:04 |
| ogra_ | to be able to wipe something essential ? | 13:04 |
| zyga-ubuntu | andyrock: is that a variable we have the udev tag it with | 13:04 |
| zyga-ubuntu | andyrock: or something we can set in the mount option? | 13:04 |
| jdstrand | jjohansen: to summarize backscroll, see https://forum.snapcraft.io/t/snapd-2-27-6-2-in-debian-sid-blocked-on-apparmor-in-kernel-4-13-0-1/2813/3 | 13:05 |
| jdstrand | jjohansen: a ptrace rule is popping out in vanilla 4.13 on Debian and not on Ubuntu 4.13 on Ubuntu | 13:05 |
| andyrock | ogra_: UDISKS_IGNORE is used e.g. on windows recovery partitions | 13:05 |
| andyrock | and other partitions that should be shown | 13:05 |
| ogra_ | zyga-ubuntu, ît is used by udisks2 to actually hide something like "dell recovery" and other super essential vendor stuff ... take a look at the bottom of /lib/udev/rules.d/80-udisks2.rules | 13:06 |
| andyrock | I tried to propose this solution upstream but they will not accept it | 13:06 |
| zyga-ubuntu | ogra_: that's ok, we can piggy back on this | 13:06 |
| zyga-ubuntu | andyrock: what did upstream say? | 13:06 |
| ogra_ | zyga-ubuntu, right, that was my suggestion | 13:06 |
| andyrock | zyga-ubuntu: upstream is ok with a x-gdu-hide/ignore whatever option | 13:07 |
| ogra_ | zyga-ubuntu, its a pretty common mechanism, but if gnome-disk-utilities ignores it it wont help much | 13:07 |
| zyga-ubuntu | andyrock: is one supported now? | 13:07 |
| zyga-ubuntu | andyrock: or is that something we need to implement and send upstream | 13:07 |
| andyrock | nope but I can implement and send without problem | 13:07 |
| andyrock | that's what they told | 13:08 |
| zyga-ubuntu | andyrock: that's great | 13:08 |
| zyga-ubuntu | andyrock: please document this on the forum, we need to do something to mount units anyway and that fits in nicely | 13:08 |
| * ogra_ would still do it on a udev level instead of a mount option ... the latter smells slightly hackish | 13:09 | |
| ogra_ | i.e. introdusce a new udev variable and make that one actually accepted by gnome-disk-utilities | 13:09 |
| andyrock | ogra_: how do you specify that at udev level? | 13:09 |
| ogra_ | via a rules file that snapd can ship then | 13:09 |
| andyrock | like how do you are sure that what you're hiding is actually a snap partitions | 13:10 |
| andyrock | *partition | 13:10 |
| andyrock | for what I know you can just say | 13:10 |
| andyrock | ok if it's a loop device and it's a squashfs | 13:10 |
| andyrock | than hide it | 13:10 |
| andyrock | but there is no other way to say, if the mount point is in /snap | 13:11 |
| ogra_ | KERNEL "loop" ... then check for filesystem and for /var/lib/snap in the source mount | 13:11 |
| ogra_ | and ignore the target | 13:11 |
| ogra_ | not all distros use /snap | 13:11 |
| andyrock | is the source mount available? | 13:11 |
| ogra_ | i guess there is an attribute with the path somewhere ... | 13:12 |
| andyrock | just monitoring the events I was not able to find it | 13:12 |
| ogra_ | there is ENV{ID_FS_TYPE} ... so i guess there is also a path somewhere | 13:12 |
| andyrock | https://www.irccloud.com/pastebin/HFhhonyX/ | 13:17 |
| andyrock | e.g. this is what I get | 13:17 |
| === JoshStrobl|Store is now known as JoshStrobl | ||
| ogra_ | hmm, funny, it actually sets UDISKS_IGNORE=1 | 13:18 |
| ogra_ | you could build on top of that ... | 13:19 |
| ogra_ | if "UDISKS_IGNORE=1" and "loop" and "squashfs" it is most likely a snap ... so set "GDISKS_IGNORE=1" and have gnome-disk-utilities catch that | 13:20 |
| ogra_ | or if you want it really exact you wrap in a script ... like: | 13:22 |
| ogra_ | ogra@styx:~$ losetup -l /dev/loop4 -n -O BACK-FILE | 13:22 |
| ogra_ | /var/lib/snapd/snaps/core_2898.snap | 13:22 |
| ogra_ | (to wrap a script into the udev rule you use: IMPORT{program} "/bin/sh -c 'losetup -l ENV{DEVANME} -n -O BACK-FILE'" or some such ) | 13:25 |
| andyrock | ogra_: it sets that because I had a rule to do that\ | 13:25 |
| ogra_ | ah | 13:25 |
| ogra_ | well, then go without it | 13:26 |
| andyrock | but I want that upstream | 13:26 |
| ogra_ | why ? it is a snapd thing ... so have snapd ship a rule that sets your var | 13:26 |
| ogra_ | all you need upstream is to have gnome-disk-utilities use that var to ignore the mounts | 13:26 |
| andyrock | sorry I didn't read everthing | 13:26 |
| andyrock | reading now | 13:27 |
| zyga-ubuntu | koza: bluetooth still doesn't let me switch to a2dp | 13:27 |
| zyga-ubuntu | koza: on artful | 13:27 |
| ogra_ | zyga-ubuntu, use wried speakers ... better quality anyway :P | 13:27 |
| zyga-ubuntu | ogra_: one less cable while on the go | 13:27 |
| zyga-ubuntu | ogra_: and being a gunea pig helps others :) | 13:27 |
| zyga-ubuntu | ogra_: not everyone knows a BT developer | 13:28 |
| koza | zyga-ubuntu, i know, still remember about this one. it is in the queue just after the commercial related things | 13:28 |
| zyga-ubuntu | koza: AFAIK you said it should work, it's just the default is wrong | 13:28 |
| zyga-ubuntu | if this is still expected unfixed then no news :) | 13:28 |
| koza | zyga-ubuntu, it should not crash, this was fixed last time | 13:28 |
| zyga-ubuntu | koza: it doesn't crash, just doesn't switch | 13:29 |
| koza | zyga-ubuntu, it will however mess the hsp/a2dp things | 13:29 |
| zyga-ubuntu | aha | 13:29 |
| zyga-ubuntu | ok | 13:29 |
| zyga-ubuntu | :-) | 13:29 |
| koza | zyga-ubuntu, this is still being worked on, hopefully PA 11 will land in bionic which should improve things | 13:29 |
| zyga-ubuntu | koza: I'll gladly switch when that is there | 13:30 |
| koza | anyways regardless of the PA version in bionic this one will be tackled as well | 13:30 |
| ogra_ | FWIW https://forum.snapcraft.io/t/connecting-bluetooth-audio-devices-pulseaudio-bluez/2669 | 13:31 |
| ogra_ | (we recently landed the PA changes) | 13:31 |
| ogra_ | (but that wont help with the general issue of messing hsp/a2dp ... only with the pulse snap using BT audio in general) | 13:33 |
| * zyga-ubuntu heads back home, see you shortly | 13:40 | |
| === anewman_ is now known as anewman | ||
| mborzecki | zyga-ubuntu: pushed a commit to https://github.com/snapcore/snapd/pull/4185 hopefully this will resolve the concerns of stat()ing /etc/shadow frequently | 14:15 |
| mup | PR #4185: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185> | 14:15 |
| zyga-ubuntu | mborzecki: sure, I'll look now | 14:16 |
| zyga-ubuntu | pstolowski: two unanswered questions on https://github.com/snapcore/snapd/pull/4108#discussion_r150541232 | 14:16 |
| mup | PR #4108: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <https://github.com/snapcore/snapd/pull/4108> | 14:16 |
| mborzecki | i'm leaving to pick up my kids and then on to a 3h drive to wroclaw | 14:16 |
| pstolowski | zyga-ubuntu, sorry, meant to answer those and forgot. doing | 14:17 |
| === Trevinho|off is now known as Trevinho | ||
| zyga-ubuntu | mborzecki: commented on 4185 now | 14:22 |
| mup | PR snapd#4173 closed: corecfg: validate refresh.schedule when it is applied <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4173> | 14:46 |
| sergiusens | elopio you around ? | 14:47 |
| mup | PR snapd#4209 closed: run-checks, tests/lib/snaps/: shellcheck fixes <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4209> | 14:57 |
| elopio | sergiusens: I'm here | 15:02 |
| sergiusens | zyga-ubuntu btw, I edited '.config/libvirt/qemu/snapshot/boxes-unknown' andchanged te value from qqxl to virtio in the xml i there and got it going.. my machine crawling now though (I canoot see what I am typing at the moment ;-) ) | 15:04 |
| sergiusens | elopio snapcraft#1717, mind just making the change yourself wrt location? | 15:10 |
| mup | PR snapcraft#1717: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717> | 15:10 |
| elopio | sergiusens: sure | 15:16 |
| sergiusens | elopio also, any update on that ruby issue? | 15:17 |
| elopio | sergiusens: oh no, this needs the bigger refactor. Otherwise adding a catkin plugin to the plugins suite can get us back to timing out. | 15:17 |
| elopio | that's why kyrofa and I haven't moved it. | 15:17 |
| elopio | sergiusens: for ruby I'm setting up my rpi. The permission error doesn't make any sense to me. | 15:18 |
| elopio | it worked on arm64 on the dragonboard, so it's not likely that we don't support the arch. | 15:18 |
| zyga-ubuntu | elopio: what issue are you seeing? | 15:19 |
| zyga-ubuntu | ikey: hey, can you please "make fmt" in https://github.com/snapcore/snapd/pull/4207 | 15:19 |
| mup | PR #4207: Flesh out NVIDIA support for biarch and multiarch systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4207> | 15:19 |
| sergiusens | elopio snapcraft#1729 could use a peek as well | 15:21 |
| mup | PR snapcraft#1729: sources: use arfile to extract debs <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1729> | 15:21 |
| sergiusens | elopio oh, your comment was somewhat loosely phrased then | 15:22 |
| elopio | zyga-ubuntu: http://paste.ubuntu.com/25954649/ | 15:23 |
| sergiusens | snappy-m-o autopkgtest 1717 xenial:armhf artful:amd64 | 15:25 |
| snappy-m-o | sergiusens: I've just triggered your test. | 15:25 |
| zyga-ubuntu | elopio: where is this running? | 15:25 |
| zyga-ubuntu | elopio: do you see any apparmor denials? | 15:25 |
| elopio | zyga-ubuntu: it's running on autopkgtest infrastructure, armhf. It's running the snapcraft deb, so I would expect no denials, but I could make a branch to collect more information. | 15:27 |
| zyga-ubuntu | elopio: didn't we recently changed how those run? | 15:28 |
| zyga-ubuntu | elopio: perhaps cjwatson knows more | 15:28 |
| zyga-ubuntu | elopio: please try to collect apparmor denials if you can | 15:28 |
| mup | Issue snapcraft#1448 closed: snapcraft build using manifest.yaml <design-required> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1448> | 15:31 |
| mup | Issue snapcraft#1628 closed: record lxc image used <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1628> | 15:31 |
| mup | PR snapcraft#1633 closed: recording: record information from the image in container builds <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1633> | 15:31 |
| cjwatson | zyga-ubuntu: autopkgtests aren't me. Try Laney | 15:32 |
| cjwatson | elopio: ^- | 15:32 |
| pstolowski | damn, my spread test issue with service restarts tasks taking too long is fixed with st.EnsureBefore(0) after all.. | 15:32 |
| sergiusens | zyga-ubuntu also, why do you assume apparmor? :-) | 15:32 |
| zyga-ubuntu | cjwatson: thank you! | 15:32 |
| zyga-ubuntu | sergiusens: permission denied is now engraved in my mind | 15:33 |
| sergiusens | zyga-ubuntu I think this is a much more mundane error related to gems and lack of testing on arm | 15:33 |
| zyga-ubuntu | wow, so I'm on 17.10 | 15:38 |
| zyga-ubuntu | and I don't have $DISPLAY set | 15:38 |
| zyga-ubuntu | no qemu sdl | 15:38 |
| zyga-ubuntu | wow, that's a new thing for me | 15:38 |
| jdstrand | sergiusens: I'm curious if maybe something started as root and then later accessed as the user | 15:40 |
| jdstrand | elopio: ^ | 15:41 |
| jdstrand | just putting it out there-- I have no particular insight (just sorta looks like that) | 15:41 |
| * zyga-ubuntu -> dinner | 15:42 | |
| === JanC_ is now known as JanC | ||
| sergiusens | jdstrand yeah, maybe; but I would suspect it would affect amd64 as well unless we have quirked the system and put ourselves into a corner | 16:05 |
| pstolowski | pedronis, zyga addressed your comment to 4163, I think it can land | 16:19 |
| pedronis | pstolowski: fine by me | 16:19 |
| andyrock | SUBSYSTEM=="block", KERNEL=="loop*", IMPORT{program}="/bin/sh -c '/sbin/losetup -l $env{DEVNAME} -n -O BACK-FILE | /bin/grep -c ^/var/lib/snapd/snaps/ | /bin/sed s/.*/GDISKS_IGNORE=\\0/'" | 16:24 |
| andyrock | ogra_: ^^^ this is the only way I found to make it work | 16:24 |
| andyrock | there are several limitations with udev rules | 16:24 |
| zyga-ubuntu | andyrock: note that we can generate some rules from snapd itself | 16:25 |
| mup | PR snapd#4163 closed: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4163> | 16:25 |
| zyga-ubuntu | andyrock: and ideally we could do something at systemd.mount level | 16:25 |
| ogra_ | yeah | 16:25 |
| ogra_ | but good to see that it is possible even with that slightly hackish approach | 16:25 |
| zyga-ubuntu | pstolowski: jdstrand wanted to review that but that's not a big problem, I'll wait for the review and address anything that may come up | 16:25 |
| pstolowski | zyga-ubuntu, arghh, a second too late | 16:26 |
| andyrock | zyga-ubuntu: I don't mind how the rule is generated :D | 16:26 |
| andyrock | just that can be generated | 16:27 |
| pstolowski | zyga-ubuntu, just landed this and 4166 | 16:27 |
| mup | PR snapd#4166 closed: cmd/snap-update-ns: detect and report read-only filesystems <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4166> | 16:27 |
| pstolowski | zyga-ubuntu, sorry | 16:27 |
| ogra_ | zyga-ubuntu, i wonder if just adding an environment stanza to the systemd.mount unit would do (udev might just pick it up so you could check for the var in the env then) | 16:27 |
| zyga-ubuntu | pstolowski: no worries :) | 16:28 |
| zyga-ubuntu | pstolowski: thank you, no worries :) | 16:28 |
| ogra_ | (there must be some advantage of the close systemd and udev integration ) | 16:28 |
| zyga-ubuntu | ogra_: worth a try :) | 16:28 |
| pstolowski | 1 PR left to get down to 1 page ;) | 16:28 |
| zyga-ubuntu | ogra_: yeah, bugs go to the same person ;) | 16:28 |
| ogra_ | lol | 16:28 |
| andyrock | ogra_: zyga-ubuntu let me give it a try | 16:31 |
| mup | PR snapd#4205 closed: add spread test for allocating TUN/TAP devices with network-control <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4205> | 16:34 |
| zyga-ubuntu | pstolowski: btw, https://github.com/snapcore/snapd/pull/4169 is a nicer and shorter diff to review now | 16:43 |
| mup | PR #4169: cmd/snap-update-ns: add secureMkfileAll <Created by zyga> <https://github.com/snapcore/snapd/pull/4169> | 16:43 |
| pstolowski | zyga-ubuntu, great, will take a look | 16:46 |
| zyga-ubuntu | pstolowski: thank you | 16:46 |
| mup | PR core#63 closed: 25-create-generic-initrd.chroot: use symlink instead of copy <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/63> | 16:47 |
| andyrock | ogra_,zyga-ubuntu if you want to use sytemd.mount at this point is better to use the mount options | 16:58 |
| andyrock | mount options can be easily retrieved using udisk2 | 16:59 |
| zyga-ubuntu | andyrock: yep, I agree | 17:00 |
| andyrock | are /etc/systemd/system/snap*.mount generated or what? | 17:00 |
| zyga-ubuntu | andyrock: yes | 17:01 |
| zyga-ubuntu | andyrock: well, "generated" not via systemd-generate or anyrthing | 17:02 |
| zyga-ubuntu | andyrock: snapd manintains those | 17:02 |
| andyrock | kk | 17:02 |
| niemeyer | sergiusens: Heya | 17:05 |
| niemeyer | sergiusens: Curious about two updates: | 17:05 |
| niemeyer | sergiusens: The clean behavior improvements | 17:05 |
| niemeyer | sergiusens: and the interpreter fix for classic snaps | 17:06 |
| niemeyer | sergiusens: How're those going? | 17:06 |
| zyga-ubuntu | wow, PRs fit one one page :D | 17:07 |
| zyga-ubuntu | just a little more and we'll be under 20 :D | 17:07 |
| niemeyer | And I'm still way behind | 17:08 |
| zyga-ubuntu | niemeyer: but we have interesting rsync /snap posts that saw some eye-opening comments :) | 17:09 |
| niemeyer | zyga-ubuntu: I wonder how to make that more clear, or at least more well known | 17:15 |
| niemeyer | zyga-ubuntu: I've seen multiple people going from disappointment to awe just by being enlightened about that point | 17:15 |
| zyga-ubuntu | niemeyer: yeah, I was thinking if there's a way for rsync to say "OMG multiple filesystems" and bail out or something | 17:15 |
| niemeyer | zyga-ubuntu: Well, we won't be able to touch rsync or du which are the tools people normally use for that | 17:16 |
| niemeyer | zyga-ubuntu: Not in a way that solves the perception problem | 17:16 |
| zyga-ubuntu | niemeyer: /snap/bin/du ;-) | 17:16 |
| zyga-ubuntu | just sayn ';-) | 17:16 |
| zyga-ubuntu | niemeyer: I think it's a problem of doing something new and finding that people are not familiar with the concept | 17:16 |
| zyga-ubuntu | niemeyer: hard to say if there's a technical solution | 17:16 |
| niemeyer | zyga-ubuntu: Perhaps a /snap/NO_THAT_SPACE_IS_NOT_BEING_CONSUMED as a text file | 17:16 |
| zyga-ubuntu | actually | 17:17 |
| zyga-ubuntu | /snap/README.txt could go a very long way | 17:17 |
| zyga-ubuntu | it could have a paragraph of text in 5 most popular language and a forum link | 17:17 |
| niemeyer | Or /snap/DISK-SPACE | 17:17 |
| niemeyer | zyga-ubuntu: But yeah, /snap/README is likely more friendly | 17:18 |
| zyga-ubuntu | niemeyer: something we could manage and update over time, not packaged I assume | 17:18 |
| niemeyer | zyga-ubuntu: Yes, synched on snapd runs | 17:18 |
| zyga-ubuntu | right | 17:18 |
| zyga-ubuntu | niemeyer: I may just do that quickly | 17:18 |
| zyga-ubuntu | niemeyer: I'm bored by reviews and it's late | 17:18 |
| niemeyer | zyga-ubuntu: +1 | 17:18 |
| niemeyer | sergiusens I promise to send you a cake if the clean "High priority" bug becomes two years old | 17:20 |
| niemeyer | sergiusens: Actually, I'll deliver it personally in the next sprint | 17:21 |
| zyga-ubuntu | niemeyer: the cake is a lie | 17:25 |
| zyga-ubuntu | niemeyer: but I want pics if you do | 17:25 |
| niemeyer | zyga-ubuntu: A lie? | 17:25 |
| kyrofa | niemeyer, you've never played Portal? | 17:27 |
| kyrofa | I'm disappointed in you | 17:27 |
| niemeyer | kyrofa: Oh, I did.. but way too long ago | 17:27 |
| kyrofa | Hahaha | 17:28 |
| niemeyer | kyrofa: I didn't play the sequel, though | 17:28 |
| niemeyer | Is it any good? | 17:28 |
| ogra_ | https://www.gnu.org/software/guix/ | 17:28 |
| ogra_ | hmmm | 17:28 |
| zyga-ubuntu | niemeyer: it's very very good | 17:28 |
| zyga-ubuntu | niemeyer: if you have debian commit access you can get a copy for free | 17:28 |
| kyrofa | They're both great, although I only ever did the coop version (of both), not sure if it's different | 17:28 |
| ogra_ | "in addition to standard package management features, supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and more." | 17:28 |
| zyga-ubuntu | niemeyer: valve use do thave a promo for all debian developers and maintainers | 17:28 |
| niemeyer | ogra_: Gnu luck | 17:29 |
| niemeyer | I mean.. good luck | 17:29 |
| ogra_ | heh | 17:29 |
| zyga-ubuntu | lol | 17:29 |
| * ogra_ only just stumbled over it | 17:29 | |
| zyga-ubuntu | This is GNU luck, there is no warranty | 17:29 |
| zyga-ubuntu | so meta | 17:29 |
| ogra_ | stallman snaps .... | 17:30 |
| ogra_ | stall-snaps | 17:30 |
| ogra_ | or is it flat-stall | 17:30 |
| niemeyer | snap stall | 17:31 |
| niemeyer | OMG, we should have an alias | 17:31 |
| ogra_ | lol | 17:31 |
| niemeyer | snap stall --man | 17:31 |
| ogra_ | is that the long version of "snap rms" ? | 17:32 |
| sergiusens | niemeyer the clean bug has many subtasks hidden in comments, the just clean dependent parts that need cleaning is done; the re-pull and un-pull stuff has not started | 17:34 |
| zyga-ubuntu | niemeyer: I can smell the LWN article already | 17:34 |
| zyga-ubuntu | niemeyer: ubuntu taunts the father of free software with snapd, tied to proprietary store ;-) | 17:34 |
| sergiusens | niemeyer interpreter fix should be on track, but I cannot provide tangible updates as we are still trying to cut a release | 17:34 |
| zyga-ubuntu | and OMG SKY IS FALLING | 17:35 |
| niemeyer | sergiusens: It's going to be two years soon.. it's really time to tackle it | 17:35 |
| mup | PR snapcraft#1722 closed: unit tests: reset log level after test <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1722> | 17:35 |
| niemeyer | sergiusens: Being able to clean a cache is a fundamental part of any cache implementation | 17:35 |
| ogra_ | you mean over print("buy bigger disk !!!") ? | 17:36 |
| niemeyer | sergiusens: We need to look for the intuitive behavior in those areas | 17:36 |
| niemeyer | sergiusens: We should probably not even do "rebuild" | 17:37 |
| niemeyer | sergiusens: The intuitive action is simply to do the action in the first place | 17:37 |
| niemeyer | sergiusens: So "snapcraft pull foobar" should pull it | 17:37 |
| niemeyer | sergiusens: Cached or not | 17:37 |
| niemeyer | sergiusens: We're all used to the warts, but I regularly see people stumbling upon just making things work at all, which is a typical issue with caching that is on the way | 17:38 |
| niemeyer | Was reminded of that again by https://forum.snapcraft.io/t/use-of-home-and-network-plugs/2587/33 | 17:39 |
| sergiusens | niemeyer so `snapcraft pull` would basically redo and leave you in that state? I thought the bigger problem was local sources changing and running `snapcraft` with no specific target which is another task we are working on | 17:39 |
| sergiusens | but working on this will put us behind on some roadmap items | 17:40 |
| niemeyer | sergiusens: Note that initially the poster apparently had no idea that there was even caching involved.. the report is "snapcraft refuses to work" | 17:40 |
| niemeyer | sergiusens: Yes, snapcraft would basically do what is on the label | 17:41 |
| niemeyer | sergiusens: pull pulls | 17:41 |
| niemeyer | sergiusens: build builds | 17:41 |
| niemeyer | sergiusens: If you want caching of step X then don't ask to run step X | 17:41 |
| niemeyer | sergiusens: Right now we're harshly responding "Nope!" when asked to do a step | 17:42 |
| sergiusens | ok, I'll update you next week on the progress of that item | 17:42 |
| niemeyer | sergiusens: Thanks, and sorry for the joke.. we should really just fix this | 17:43 |
| * sergiusens starts making his way to physiotherapy | 17:43 | |
| sergiusens | niemeyer no worries | 17:43 |
| kyrofa | elopio, talk to me about adt. I see pexpect timeouts on armhf and arm64 on the beta PR. Were you able to reproduce the Ruby issues there? | 17:46 |
| kyrofa | Should I fire up my rpi? | 17:46 |
| sergiusens | kyrofa yes! | 17:46 |
| kyrofa | sergiusens, you were able to reproduce them? | 17:46 |
| sergiusens | no, I was focusing on other items ;-) | 17:47 |
| kyrofa | Okay, I'll try to reproduce | 17:47 |
| elopio | kyrofa: yes please, my sd cards make everything hard. | 17:52 |
| elopio | kyrofa: I ran in dragonboard with no issues. | 17:53 |
| * ikey has mental image of a DBZ surfboard | 17:55 | |
| kyrofa | I'm flashing now | 17:56 |
| * ogra_ shades his eyes | 17:57 | |
| * zyga-ubuntu implemented the readme thing, waiting for spread | 18:06 | |
| kyrofa | Hmm... it seems snapd isn't running on my newly flashed rpi. I can't create an initial user as a result | 18:09 |
| kyrofa | I'll try rebooting | 18:09 |
| kyrofa | Huh. Still no luck | 18:11 |
| kyrofa | zyga-ubuntu, did you make any headway with the lxd issue? | 18:17 |
| kyrofa | Last I heard, you thought you had a solution, but it didn't work? | 18:21 |
| zyga-ubuntu | kyrofa: yes, but I had some network issues that wreaked havoc in my iteration | 18:22 |
| zyga-ubuntu | kyrofa: I tried and failed with two approaches | 18:22 |
| zyga-ubuntu | kyrofa: and I got a 3rd one going that is likely to work | 18:22 |
| zyga-ubuntu | kyrofa: stay tuned, I'm still working on this | 18:23 |
| kyrofa | zyga-ubuntu, alright, any sort of estimated timeline? | 18:24 |
| zyga-ubuntu | kyrofa: I'll tell you tomorrow | 18:24 |
| zyga-ubuntu | kyrofa: if it works it's in 2.30 | 18:24 |
| kyrofa | Alright, thanks zyga-ubuntu :) | 18:24 |
| ikey | uploaded some new LSI images which should have compatibility with ubuntu nvidia libraries now.. | 18:25 |
| ikey | we were missing `pthread_setname_np`@GLIBC_2.0 ... | 18:25 |
| ikey | ABI. fun and games. :D | 18:25 |
| zyga-ubuntu | ikey: this project of yours is such a fantastic learning experience for me | 18:26 |
| ikey | oh and me | 18:26 |
| ikey | finding all those weird corner cases | 18:26 |
| ikey | does show how malleable linux can be though | 18:26 |
| ikey | (with the right hammer) | 18:26 |
| ikey | ive dropped the vendored glibc ABI version to 3.2.0 which should be compatible with ubuntu now | 18:28 |
| zyga-ubuntu | ikey: you just need a couple of kilos of unobtanium | 18:28 |
| zyga-ubuntu | aka documentation | 18:28 |
| ikey | lol yea | 18:28 |
| ikey | for the whole "how to create a snap" bit or the lsi bit or all of it? | 18:28 |
| ikey | s/snap/base snap. | 18:28 |
| ikey | gdi keyboard | 18:28 |
| zyga-ubuntu | for the low level libc and linker magic mostly | 18:29 |
| ikey | aah abusing glibc for fun and profit | 18:29 |
| ikey | fwiw i tried to create a rudimentary LD_AUDIT module a few months back (or more) and it failed miserably | 18:30 |
| ikey | this is the 2nd time doing it | 18:30 |
| zyga-ubuntu | niemeyer: https://github.com/snapcore/snapd/pull/4210 | 18:31 |
| mup | PR #4210: many: add magic /snap/README file <Created by zyga> <https://github.com/snapcore/snapd/pull/4210> | 18:31 |
| zyga-ubuntu | niemeyer: just a RFC | 18:31 |
| zyga-ubuntu | :-) | 18:31 |
| mup | PR snapd#4210 opened: many: add magic /snap/README file <Created by zyga> <https://github.com/snapcore/snapd/pull/4210> | 18:31 |
| niemeyer | Looking | 18:32 |
| zyga-ubu1tu | niemeyer: the text is mostly a placeholder, please wordsmith | 18:32 |
| zyga-ubu1tu | niemeyer: there's also a forum link there that needs smilar treatment | 18:32 |
| kyrofa | elopio, while this is going, are there other failures I can help look into? | 18:46 |
| niemeyer | zyga-ubu1tu: Check it out | 18:47 |
| kyrofa | elopio, all the other arm adt results seem to be pexpect timeouts | 18:48 |
| kyrofa | Should I propose bumping them up? | 18:50 |
| zyga-ubu1tu | niemeyer: I think there's some issue on github, your text is empty | 18:55 |
| zyga-ubu1tu | niemeyer: now it's there, reading | 18:56 |
| niemeyer | zyga-ubu1tu: No, there'a an issue with Gustavo | 18:57 |
| zyga-ubu1tu | I'll update the text | 18:57 |
| niemeyer | I can't believe the day is going by that fast.. | 19:09 |
| niemeyer | Can I get some extra hours please? | 19:09 |
| kyrofa | sergiusens, elopio alright, I'm able to duplicate here. Looking at it now | 19:20 |
| kyrofa | Kinda slow going, obviously :P | 19:21 |
| sergiusens | kyrofa question is. Did it ever work? If not I would expect failure on the test and carry on if it becomes too time consuming | 19:21 |
| kyrofa | sergiusens, given the error, I doubt it. Want me to just expect failure, then? | 19:22 |
| kyrofa | sergiusens, I think I know what the problem is | 19:25 |
| kyrofa | Should be an easy fix. I'll try it, but keep an eye on the time. If things don't work out, I'll expect | 19:26 |
| kyrofa | (failure) | 19:26 |
| zyga-ubu1tu | niemeyer: tell me that | 19:27 |
| zyga-ubu1tu | niemeyer: it's alreday DARK outside for about 5 hours | 19:27 |
| zyga-ubu1tu | niemeyer: days run out faster than time at a roller-coaster | 19:27 |
| kyrofa | Reminds me when I used to work in a windowless lab during the winter. I left home when it was dark, and left the lab when it was dark | 19:28 |
| zyga-ubu1tu | kyrofa: welcome to the submarine | 19:29 |
| kyrofa | No kidding | 19:29 |
| === zyga-ubu1tu is now known as zyga-ubuntu | ||
| ikey | https://www.youtube.com/watch?v=3m3JfmExzsQ | 19:35 |
| ikey | xD | 19:35 |
| zyga-ubuntu | ok | 19:41 |
| zyga-ubuntu | so I need someone who speaks Mandarin or Spanish | 19:42 |
| zyga-ubuntu | to translate a tiny snippet of text :) | 19:42 |
| genii | Maybe someone in #ubuntu-locoteams or #ubuntu-cn would | 19:54 |
| sergiusens | kyrofa so what is the suspicion? | 20:18 |
| kyrofa | sergiusens, ruby has a super convoluted arch detection when it comes to generating its arch-specific libdirs | 20:18 |
| kyrofa | sergiusens, and the pattern is inconsistent depending on arch | 20:19 |
| kyrofa | So we're not setting up the RUBYLIB correctly on arm | 20:19 |
| kyrofa | thus it can't find files | 20:19 |
| sergiusens | kyrofa hah, so it probably never worked on $arch ;-) | 20:19 |
| kyrofa | Indeed | 20:19 |
| kyrofa | Probably only amd64 and i386 | 20:19 |
| kyrofa | Which means we haven't run adt on those archs since ruby landed... ages ago | 20:19 |
| * genii ponders aarch64 vs arm64 | 20:20 | |
| sergiusens | kyrofa we probably have, no one was looking ;-) | 20:20 |
| sergiusens | kyrofa can I get a veridict on #1729 ? | 20:21 |
| mup | PR #1729: tests: spread all-snap test cleanup <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1729> | 20:21 |
| sergiusens | the snapcraft one though | 20:21 |
| sergiusens | :-) | 20:21 |
| kyrofa | sergiusens, yeah, I just need to actually test it, it's next | 20:23 |
| kyrofa | Code looks good, though | 20:23 |
| sergiusens | tell you what, I'll make it easy. Hey ikey do you still get a crash if you `snap refresh snapcraft --channel stable/pr-1729`? I don't on solus, but triple confirmation is always better :-) | 20:25 |
| ikey | omg --help works | 20:26 |
| ikey | ..big help xD | 20:26 |
| ikey | ty! | 20:26 |
| mwhudson | morning | 20:27 |
| sergiusens | ikey thanks for corroborating; turns out running `import debian.debfile` causes that as it loads apt_inst which expects /etc/apt to exist (I might be repeating myself here, sorry if I am) | 20:34 |
| mup | PR snapcraft#1730 opened: ruby plugin: be smarter about arch-specific paths <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1730> | 21:18 |
| kyrofa | elopio, I just got the ""GET /v2/snaps HTTP/1.1" 200 79" failure again | 21:34 |
| kyrofa | sergiusens, elopio ^ that however should fix the ruby issues no arm | 21:34 |
| kyrofa | s/no/on/ | 21:35 |
| kyrofa | snappy-m-o, autopkgtest 1730 xenial:armhf | 21:37 |
| snappy-m-o | kyrofa: I've just triggered your test. | 21:37 |
| === cprov_ is now known as cprov | ||
| === icey_ is now known as icey | ||
| === cwayne_ is now known as cwayne | ||
| === arosales_ is now known as arosales | ||
| === Trevinho_ is now known as Trevinho | ||
| === jero is now known as Guest42538 | ||
| ikey | sergiusens, oh cool | 22:01 |
| ikey | sorry was afk there for podcast cruft | 22:01 |
| sergiusens | okey sad that to use the logic to extract an ar archive one would need the full apt machinery by default | 22:04 |
| sergiusens | Oops autocorrect | 22:04 |
| elopio | kyrofa: did you get the "GET" print on the same test? | 22:07 |
| sergiusens | kyrofa what do libdirs look like on armhf and arm64? | 22:08 |
| kyrofa | sergiusens, lib/ruby/2.4.0/armv7l-linux-eabihf, on amd64 it's lib/ruby/2.4.0/x86_64-linux | 22:10 |
| kyrofa | sergiusens, so we made the assumption it was <machine>-<linux> but it's not. I dug into Ruby's autotools stuff and it's... yucky | 22:10 |
| kyrofa | sergiusens, not sure what it is on arm64, but elopio said it worked | 22:11 |
| kyrofa | So I'm guessing aarch64-linux | 22:15 |
| kyrofa | elopio, snapcraft.tests.test_lifecycle.ExecutionTestCase.test_dependency_recursed_correctly | 22:20 |
| kyrofa | elopio, I'm having trouble remember which one it was last time, but I know it was in the lifecycle tests | 22:20 |
| elopio | kyrofa: yes, that's the same one. :/ Maybe we should try your fix, but I'm still not understanding what's going on. | 22:31 |
| kyrofa | Me neither :( | 22:32 |
| elopio | my experiment with the nuke argument was not successful, because by default we are nuking. | 22:32 |
| kyrofa | I rebased on top of my fix and it's running fine now, though | 22:32 |
| kyrofa | If I'm the only one hitting it I can continue to do that | 22:32 |
| elopio | it's working for me, but might be luck. | 22:33 |
| === dontbeadick is now known as CoderEurope | ||
| kyrofa | elopio, are there any other known issues that I could be looking at? All the arm failures I see are pexpect timeouts, so I don't know what the current issues are | 22:44 |
| ikey | is snapd forcing a host os-release into the snap? | 22:48 |
| gsilvapt | Any tips on finding the needed files to implement a change suggested in LP? For instance, https://bugs.launchpad.net/snapcraft/+bug/1590349. How do I know (as an outsider and unfamiliar person to the project) where this section lives? | 23:16 |
| mup | Bug #1590349: snapcraft should have a 'version' command <bitesize> <ui> <Snapcraft:Triaged> <https://launchpad.net/bugs/1590349> | 23:16 |
| kyrofa | elopio, ever seen this before? https://pastebin.ubuntu.com/25957073/ | 23:18 |
| kyrofa | We tease out all sorts of fun things running in lxc | 23:18 |
| kyrofa | Hey there gsilvapt | 23:28 |
| gsilvapt | hi kyrofa | 23:28 |
| kyrofa | gsilvapt, really the only way to determine where things are is to start hacking on things until you get a good idea of it, haha | 23:28 |
| kyrofa | gsilvapt, or ask one of us to point you in the right direction until you get enough experience with the codebase to know | 23:29 |
| gsilvapt | Hum, I figured that could be a possibility. It's just that I feel lost looking at any code base like this and I thought there could be some pro tips I could ask for from you guys | 23:29 |
| kyrofa | gsilvapt, for that one, start with the snapcraft/cli package | 23:29 |
| kyrofa | gsilvapt, yeah anyone feels lots on a new large project, don't feel overwhelmed. Typically I start by grepping for a string I know if part of the problem, then tracing around in the code from there | 23:30 |
| gsilvapt | Are you telling just from experience or are there any pointers right out of the box? | 23:30 |
| kyrofa | gsilvapt, I just gave you one. Here's the flow I'd take for that particular issue | 23:32 |
| kyrofa | $ grep -r "\-\-version" * | 23:32 |
| gsilvapt | Ok, lets try figuring out where is that package | 23:32 |
| kyrofa | That will return several things, one of which is an entry in the changelog. Interesting! | 23:32 |
| kyrofa | So let's look for that string in `git log` | 23:32 |
| kyrofa | That leads us to commit be4a92ad709e98975301a19a15025154bd10d8b2 | 23:33 |
| kyrofa | `git show be4a92ad709e98975301a19a15025154bd10d8b2` would give you a great start toward what files are involved in this | 23:34 |
| kyrofa | gsilvapt, see what I mean? | 23:34 |
| gsilvapt | Yes, I'm following | 23:34 |
| kyrofa | That brings you to the snapcraft/cli package that I mentioned | 23:35 |
| kyrofa | Look at a few files in there, you'll see how other commands are structured | 23:36 |
| kyrofa | You'll also see how --version works, and you should be able to sort of combine the two | 23:36 |
| gsilvapt | So the file to be changed is actually snapcraft/__init__.py | 23:37 |
| gsilvapt | is that correct? | 23:37 |
| mup | PR snapcraft#1729 closed: sources: use arfile to extract debs <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1729> | 23:42 |
| kyrofa | No, maybe snapcraft/cli/__init__.py, but more likely snapcraft/cli/help.py or create a new file in there | 23:42 |
| kyrofa | (I would suggest a new file) | 23:43 |
| sergiusens | ikey in devmode and strict you are pivot rooting into the base snap, so os release would be what that is (unless I got your question wrong) | 23:44 |
| ikey | yeah its not | 23:44 |
| sergiusens | kyrofa elopio the correct fix for the logging is to use a named logger and not getdefaultLogger | 23:44 |
| ikey | someone testing my snap is showing a report of Ubuntu 17.10 from steam | 23:45 |
| kyrofa | sergiusens, named logger where? In the log package? | 23:45 |
| sergiusens | kyrofa https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/log.py#L55 make sure logger_name is not None there | 23:47 |
| gsilvapt | kyrofa, considering the method to retrieve snapcraft version exists when --version is passed in as arguments, is it bad practice if we change it to just be version? | 23:47 |
| sergiusens | kyrofa for the callers of that | 23:47 |
| kyrofa | sergiusens, ah, I see | 23:48 |
| gsilvapt | Or rather, version and --version should return the same value. They both exist so we could adjust the respective code bits, right? | 23:48 |
| sergiusens | kyrofa but this is not an easy fix, as all the random getLogger calls would need to change as well | 23:48 |
| sergiusens | then, setting a log level will only affect our stuff | 23:48 |
| kyrofa | gsilvapt, according to the bug, looks like both --version and version are desired | 23:49 |
| sergiusens | kyrofa your fix is fine, but I'd do it at the start of the tests and not at the end | 23:49 |
| sergiusens | kyrofa baseline the loglevel for all the tests | 23:49 |
| kyrofa | sergiusens, fair enough. Shall I repropose and log a bug about the loggers? | 23:49 |
| gsilvapt | kyrofa, yes, both are desired to print the version of snapcraft and not the snap itself. Again, if both methods exist, why not convert them to return the same value? | 23:51 |
| kyrofa | gsilvapt, hmm, I'm a bit confused-- they don't both exist. But I agree that, when we add `version` it should return the same value as `--version` | 23:51 |
| sergiusens | kyrofa sounds good, but lets get this release out of the way; also, we should stop checking for strict output | 23:52 |
| gsilvapt | Hum, I thought version would return the snap's version | 23:52 |
| gsilvapt | So basically it needs a new class. Ok, this could be tricky for me to implement and it is getting late but I will sketch something to work this one out | 23:52 |
| kyrofa | gsilvapt, check the bug again, that discussion was had there | 23:52 |
| kyrofa | sergiusens, agreed on both counts, although this is sort of FOR this release since it's in the way of my running adt locally, but we can hack around it for now | 23:53 |
| sergiusens | ikey is this written somewhere? some people run things straight from the innards of things (which makes me think sometimes that we should blackbox the snap itself by default...) | 23:53 |
| gsilvapt | Yes, I just thought both existed but did different things. They both should return the same thing which is the snapcraft version number. | 23:54 |
| sergiusens | kyrofa we are almost there https://github.com/snapcore/snapcraft/milestone/10 (I am not sleeping until this is tagged btw) | 23:55 |
| kyrofa | gsilvapt, you got it-- `snapcraft version` doesn't exist today | 23:55 |
| kyrofa | sergiusens, nice | 23:56 |
| gsilvapt | Ok, I will work on this for the next couple of days. Need to read a bit more about how is this feature working before implementing a new one | 23:57 |
| gsilvapt | Thanks for helping, kyrofa | 23:57 |
| kyrofa | sergiusens, elopio do we to move all the catkin integration tests into snapd tests? | 23:59 |
| kyrofa | do we WANT rather | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
