[00:15] <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:17] <ikey> https://plus.google.com/+Solus-Project/posts/5Cn3P26tbtK <- coolness :D
[00:17] <ikey> first soul to run lsi on ubuntu
[00:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:31] <ikey> er
[00:31] <ikey> *lib/vulkan
[00:31] <gsilvapt> Thanks for the help, diddledan and ikey
[00:32] <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:36] <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:41] <robert_ancell> jamesh: Perhaps you might be able to help in https://bugzilla.redhat.com/show_bug.cgi?id=1509586
[00:45] <ikey> what sounds better, "/var/lib/snapd/lib/gl32" or "/var/lib/snapd/lib/gl.x86" ?
[00:46]  * ikey is tending towards gl32
[00:46] <ikey> can't start monday without a bit of bikeshedding :p
[00:47] <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:48] <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:49] <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:50] <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:51] <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:52] <King_InuYasha> like, what's the _point_ in shipping snapd for CentOS if I know everything is going to be broken
[00:53] <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:54] <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:55] <robert_ancell> King_InuYasha: just keep iterating until it works?
[00:56]  * 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:57] <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:58] <King_InuYasha> robert_ancell: anyway, it's not your fault
[00:58] <robert_ancell> :(
[00:59] <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?
[01:00] <robert_ancell> King_InuYasha: what's the challenges with snapcraft?
[01:01] <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:02] <King_InuYasha> without a working lxd, snapcraft cleanbuild is broken
[01:02] <robert_ancell> I see
[01:03] <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:04] <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:05] <King_InuYasha> and nowadays, I don't even have zyga
[01:06] <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:07] <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:08] <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:09] <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:10] <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:11] <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:12] <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:13] <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:14] <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:15] <ikey> hm
[01:16] <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:17] <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:18] <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:19]  * 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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:27] <robert_ancell> King_InuYasha: what command do you use to build from git src branches?
[01:34] <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:35] <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:37] <robert_ancell> King_InuYasha: and the equivalent of apt build-dep?
[01:39] <robert_ancell> ah dnf builddep
[01:50] <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:53] <King_InuYasha> ahh, a couple of hours of Sonic Forces have made me feel a lot better :)
[01:58]  * ikey flinches at mere mention of games
[01:59] <ikey> cmd/configure:1183:55: "includ" is a misspelling of "include"
[01:59] <ikey> Crushing failure and despair.
[01:59] <ikey> *snort*
[02:00] <ikey> the tests dislike a dirty tree :p
[02:01] <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:02] <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:03] <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:04] <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:05] <ikey> go doesn't know... shhh :p
[02:05] <Son_Goku> it's the dumbest part about go
[02:05] <ikey> FAIL	github.com/snapcore/snapd/cmd/snap-seccomp	1.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:06] <ikey> user: unknown user daemon
[02:06] <ikey> sudo useradd daemon -s /bin/true -c "lol" -g daemon
[02:06] <ikey> >_>
[02:08] <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:09] <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:19] <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:37] <ikey> bash-4.3$ ls /var/lib/snapd/lib/vulkan
[02:37] <ikey> 10_nvidia.json	10_nvidia_wayland.json
[02:37] <ikey> \o/
[02:37] <ikey> gah denials.. :D
[04:15] <mup> PR snapd#4207 opened: Flesh out NVIDIA support for biarch and multiarch systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4207>
[05:53] <mup> PR snapcraft#1728 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1728>
[05:57] <mborzecki> morning guys
[07:01] <mborzecki> mvo: hi
[07:03] <mvo> hey mborzecki, good morning
[07:03] <mborzecki> how was your weekend?
[07:04] <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:06] <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:07] <mborzecki> didn't even try to take my kids to see the festivities
[07:10] <mvo> mborzecki: meh, sounds like we had about the same weather (except no snow here :)
[07:13] <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:14] <mvo> mborzecki: ask zyga about that, he might have some ideas ;)
[07:15] <mborzecki> malta should be nice this time of year
[07:19] <mvo> mborzecki: yeah, gosh, malta is nice
[07:20] <mvo> mborzecki: don't tempt me, when I look outside I really want to fly immediately :)
[07:20] <mborzecki> hahaha
[07:22] <zyga-ubuntu> I will send kids to school and I'll be back soon
[07:23] <mvo> zyga-ubuntu: do you know if 4202 needs a jamie review still?
[07:25] <zyga-ubuntu> looking
[07:25] <zyga-ubuntu> mvo: I think so, he had a look already
[07:26] <mvo> ok
[07:27] <zyga-ubuntu> mvo: today I will do some code reviews and I'll return to 14.04 / lxd issue
[07:28] <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:29] <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:30] <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:31] <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:32] <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:33] <mborzecki> anyways, it's super weird
[07:49] <mup> PR snapd#4208 opened: packaging/arch: do not quote MAKEFLAGS <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4208>
[08:08] <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:10] <ikey> zyga-ubuntu, got some toys uploaded :p
[08:11] <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:12] <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:13] <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:14] <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:15] <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:16] <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:17]  * 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:18] <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:19] <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:20] <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:23] <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:26] <zyga-ubuntu> jamesh: hey, I'll gladly look shortly
[08:28] <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:29] <zyga-ubuntu> mwhudson: thank you! I have my debian box back but I wasn't doing any packaging for a good while now
[08:31] <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:32] <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:34] <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:35] <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:36] <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:37] <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:38] <ikey> and fwiw, the "make this root good for snapd" isn't that hard
[08:39] <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:40] <ikey> im confident i could modify that script to spit out a base for any given distro
[08:42] <zyga-ubuntu> darn, this brave snap doesn't work anywhere
[08:43] <mborzecki> anywhere, but my laptop
[08:43] <zyga-ubuntu> mborzecki: I get nothing, ranging from "some spewing errors" to exiting silently
[08:44] <mborzecki> I get a bunch of logs and a browser window
[08:45] <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:46] <mborzecki> 'snap run brave' vs 'brave' shouldn't be a problem?
[08:46] <zyga-ubuntu> mborzecki: no, it's the same thing
[08:47] <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:48] <mborzecki> https://i.imgur.com/AR0oW6U.png
[08:49] <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:50] <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:51] <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] <zyga-ubuntu> I'm on Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
[08:52] <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:53] <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:54] <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:55] <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:56]  * 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:57] <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:58] <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:59] <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
[09:00] <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:01] <zyga-ubuntu> oh
[09:01] <zyga-ubuntu> shiny
[09:02] <ikey> whatdat?
[09:02] <zyga-ubuntu> https://twitter.com/zygoon/status/929997883583160320
[09:02] <ikey> wow
[09:03] <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:04] <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:05] <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:14]  * ikey goes to bed.. damn timezone switch
[09:15] <zyga-ubuntu> ikey: o/
[09:15] <ikey> \o
[09:15] <zyga-ubuntu> ikey: not in europe anymore?
[09:16] <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:18] <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:19] <mvo> zyga-ubuntu: but hopefully today or tomorrow
[09:20] <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:29] <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:30] <mwhudson> oh apparmor
[09:30] <mwhudson> well 2.29 _should_ be better right
[09:30] <mwhudson> ?
[09:31] <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:32] <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:33] <zyga-ubuntu> mwhudson: you mean "security and linus" thread or something else?
[09:35] <mwhudson> i guess i don't mean a flamewar, i mean linus shouting at people yes
[09:36] <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:46] <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:50] <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:53] <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:54] <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:55] <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:56] <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> :)
[10:00] <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:01] <zyga-ubuntu> looking
[10:02] <zyga-ubuntu> mvo: replied
[10:02] <mvo> ta
[10:02] <mvo> zyga-ubuntu: thanks, I like the reply :)
[10:05] <zyga-ubuntu> JamieBennett: man, that is one interesting thread
[10:05] <zyga-ubuntu> thank you for sharing
[10:06] <JamieBennett> zyga-ubuntu: Indeed, AppArmor on Debian will be great.
[10:16] <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:17] <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:19] <andyrock> hey are snaps mounted always under /snap
[10:19] <andyrock> ?
[10:20] <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:21] <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:22] <zyga-ubuntu> andyrock: x-app-container x-snapd.snap, or somthing like that
[10:22] <zyga-ubuntu> *something
[10:25] <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:26] <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:27] <zyga-ubuntu> maybe there is one we can reuse already, I didn't look
[10:27] <andyrock> let me ask upstream
[10:32] <zyga-ubuntu> andyrock: thank you, let me know if there's something we can adapt in snapd to make this easier
[10:33]  * zyga-ubuntu will soon go AFK to relocate to a different site
[10:51] <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>
[11:08] <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:09] <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:10] <zyga-ubuntu> popey: though outside can help too
[11:11] <popey> added to the thread
[11:12] <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:14] <pedronis> mvo: I don't know, it's a bit a unclear what belongs where
[11:15] <zyga-ubuntu> ok I need to get going
[11:16] <zyga-ubuntu> ttyl
[11:17] <mvo> pedronis: ok, I ignore it for now while working on a spread test
[11:17] <mvo> pedronis: we can talk later
[11:19] <pedronis> mvo: I added a comment to the PR about what I think
[11:24] <mvo> ta
[11:52] <niemeyer> mborzecki: That's how it ought to work.. I'm waiting for timer services to get this somewhere else..(wink wink)
[11:53] <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:54] <niemeyer> mborzecki: It was updated half an hour ago or so, btw
[12:00] <zyga-ubuntu> re
[12:00] <zyga-ubuntu> :-)
[12:00] <niemeyer> Hellos :)
[12:02] <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:03] <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:04] <niemeyer> Nice
[12:05] <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:06] <niemeyer> I've been to places elsewhere that I quite enjoyed for the atmosphere and facilities
[12:07] <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:17] <zyga-ubuntu> re, had to reboot for my modem suddently died
[12:25] <zyga-ubuntu> jdstrand: hey
[12:26] <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:27] <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:28] <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:29] <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:31] <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:32] <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:33] <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:34]  * 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:35] <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:36]  * 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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <zyga-ubuntu> jdstrand: so ptrace trace peer=$LIBEXECDIR/snapd/snap-confine,
[12:48] <zyga-ubuntu> ?
[12:48] <jdstrand> the rule would be:
[12:49] <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:50] <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:51] <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:52] <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:53] <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:54] <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:56] <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:57] <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
[13:03] <andyrock> ogra_: UDISKS_IGNORE is ignored by gnome-disk-utilities
[13:03] <ogra_> andyrock, uuh, why is that ?
[13:04] <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:05] <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:06] <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:07] <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:08] <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:09]  * 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:10] <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:11] <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:12] <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:17] <andyrock> https://www.irccloud.com/pastebin/HFhhonyX/
[13:17] <andyrock> e.g. this is what I get
[13:18] <ogra_> hmm, funny, it actually sets UDISKS_IGNORE=1
[13:19] <ogra_> you could build on top of that ...
[13:20] <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:22] <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:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:31] <ogra_> FWIW https://forum.snapcraft.io/t/connecting-bluetooth-audio-devices-pulseaudio-bluez/2669
[13:31] <ogra_> (we recently landed the PA changes)
[13:33] <ogra_> (but that wont help with the general issue of messing hsp/a2dp ... only with the pulse snap using BT audio in general)
[13:40]  * zyga-ubuntu heads back home, see you shortly
[14:15] <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:16] <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:17] <pstolowski> zyga-ubuntu, sorry, meant to answer those and forgot. doing
[14:22] <zyga-ubuntu> mborzecki: commented on 4185 now
[14:46] <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:47] <sergiusens> elopio you around ?
[14:57] <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>
[15:02] <elopio> sergiusens: I'm here
[15:04] <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:10] <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:16] <elopio> sergiusens: sure
[15:17] <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:18] <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:19] <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:21] <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:22] <sergiusens> elopio oh, your comment was somewhat loosely phrased then
[15:23] <elopio> zyga-ubuntu: http://paste.ubuntu.com/25954649/
[15:25] <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:27] <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:28] <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:31] <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:32] <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:33] <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:38] <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:40] <jdstrand> sergiusens: I'm curious if maybe something started as root and then later accessed as the user
[15:41] <jdstrand> elopio: ^
[15:41] <jdstrand> just putting it out there-- I have no particular insight (just sorta looks like that)
[15:42]  * zyga-ubuntu -> dinner
[16:05] <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:19] <pstolowski> pedronis, zyga addressed your comment to 4163, I think it can land
[16:19] <pedronis> pstolowski: fine by me
[16:24] <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:25] <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:26] <pstolowski> zyga-ubuntu, arghh, a second too late
[16:26] <andyrock> zyga-ubuntu: I don't mind how the rule is generated :D
[16:27] <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:28] <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:31] <andyrock> ogra_: zyga-ubuntu let me give it a try
[16:34] <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:43] <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:46] <pstolowski> zyga-ubuntu, great, will take a look
[16:46] <zyga-ubuntu> pstolowski: thank you
[16:47] <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:58] <andyrock> ogra_,zyga-ubuntu if  you want to use sytemd.mount at this point is better to use the mount options
[16:59] <andyrock> mount options can be easily retrieved using udisk2
[17:00] <zyga-ubuntu> andyrock: yep, I agree
[17:00] <andyrock> are  /etc/systemd/system/snap*.mount generated or what?
[17:01] <zyga-ubuntu> andyrock: yes
[17:02] <zyga-ubuntu> andyrock: well, "generated" not via systemd-generate or anyrthing
[17:02] <zyga-ubuntu> andyrock: snapd manintains those
[17:02] <andyrock> kk
[17:05] <niemeyer> sergiusens: Heya
[17:05] <niemeyer> sergiusens: Curious about two updates:
[17:05] <niemeyer> sergiusens: The clean behavior improvements
[17:06] <niemeyer> sergiusens: and the interpreter fix for classic snaps
[17:06] <niemeyer> sergiusens: How're those going?
[17:07] <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:08] <niemeyer> And I'm still way behind
[17:09] <zyga-ubuntu> niemeyer: but we have interesting rsync /snap posts that saw some eye-opening comments :)
[17:15] <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:16] <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:17] <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:18] <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:20] <niemeyer> sergiusens I promise to send you a cake if the clean "High priority" bug becomes two years old
[17:21] <niemeyer> sergiusens: Actually, I'll deliver it personally in the next sprint
[17:25] <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:27] <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:28] <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:29] <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:30] <ogra_> stallman snaps ....
[17:30] <ogra_> stall-snaps
[17:30] <ogra_> or is it flat-stall
[17:31] <niemeyer> snap stall
[17:31] <niemeyer> OMG, we should have an alias
[17:31] <ogra_> lol
[17:31] <niemeyer> snap stall --man
[17:32] <ogra_> is that the long version of "snap rms" ?
[17:34] <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:35] <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:36] <ogra_> you mean over print("buy bigger disk !!!") ?
[17:36] <niemeyer> sergiusens: We need to look for the intuitive behavior in those areas
[17:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:46] <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:47] <sergiusens> no, I was focusing on other items ;-)
[17:47] <kyrofa> Okay, I'll try to reproduce
[17:52] <elopio> kyrofa: yes please, my sd cards make everything hard.
[17:53] <elopio> kyrofa: I ran in dragonboard with no issues.
[17:55]  * ikey has mental image of a DBZ surfboard
[17:56] <kyrofa> I'm flashing now
[17:57]  * ogra_ shades his eyes
[18:06]  * zyga-ubuntu implemented the readme thing, waiting for spread 
[18:09] <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:11] <kyrofa> Huh. Still no luck
[18:17] <kyrofa> zyga-ubuntu, did you make any headway with the lxd issue?
[18:21] <kyrofa> Last I heard, you thought you had a solution, but it didn't work?
[18:22] <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:23] <zyga-ubuntu> kyrofa: stay tuned, I'm still working on this
[18:24] <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:25] <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:26] <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:28] <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:29] <zyga-ubuntu> for the low level libc and linker magic mostly
[18:29] <ikey> aah abusing glibc for fun and profit
[18:30] <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:31] <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:32] <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:46] <kyrofa> elopio, while this is going, are there other failures I can help look into?
[18:47] <niemeyer> zyga-ubu1tu: Check it out
[18:48] <kyrofa> elopio, all the other arm adt results seem to be pexpect timeouts
[18:50] <kyrofa> Should I propose bumping them up?
[18:55] <zyga-ubu1tu> niemeyer: I think there's some issue on github, your text is empty
[18:56] <zyga-ubu1tu> niemeyer: now it's there, reading
[18:57] <niemeyer> zyga-ubu1tu: No, there'a an issue with Gustavo
[18:57] <zyga-ubu1tu> I'll update the text
[19:09] <niemeyer> I can't believe the day is going by that fast..
[19:09] <niemeyer> Can I get some extra hours please?
[19:20] <kyrofa> sergiusens, elopio alright, I'm able to duplicate here. Looking at it now
[19:21] <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:22] <kyrofa> sergiusens, given the error, I doubt it. Want me to just expect failure, then?
[19:25] <kyrofa> sergiusens, I think I know what the problem is
[19:26] <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:27] <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:28] <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:29] <zyga-ubu1tu> kyrofa: welcome to the submarine
[19:29] <kyrofa> No kidding
[19:35] <ikey> https://www.youtube.com/watch?v=3m3JfmExzsQ
[19:35] <ikey> xD
[19:41] <zyga-ubuntu> ok
[19:42] <zyga-ubuntu> so I need someone who speaks Mandarin or Spanish
[19:42] <zyga-ubuntu> to translate a tiny snippet of text :)
[19:54] <genii> Maybe someone in #ubuntu-locoteams or #ubuntu-cn would
[20:18] <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:19] <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:20]  * genii ponders aarch64 vs arm64
[20:20] <sergiusens> kyrofa we probably have, no one was looking ;-)
[20:21] <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:23] <kyrofa> sergiusens, yeah, I just need to actually test it, it's next
[20:23] <kyrofa> Code looks good, though
[20:25] <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:26] <ikey> omg --help works
[20:26] <ikey> ..big help xD
[20:26] <ikey> ty!
[20:27] <mwhudson> morning
[20:34] <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)
[21:18] <mup> PR snapcraft#1730 opened: ruby plugin: be smarter about arch-specific paths <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1730>
[21:34] <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:35] <kyrofa> s/no/on/
[21:37] <kyrofa> snappy-m-o, autopkgtest 1730 xenial:armhf
[21:37] <snappy-m-o> kyrofa: I've just triggered your test.
[22:01] <ikey> sergiusens, oh cool
[22:01] <ikey> sorry was afk there for podcast cruft
[22:04] <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:07] <elopio> kyrofa: did you get the "GET" print on the same test?
[22:08] <sergiusens> kyrofa what do libdirs look like on armhf and arm64?
[22:10] <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:11] <kyrofa> sergiusens, not sure what it is on arm64, but elopio said it worked
[22:15] <kyrofa> So I'm guessing aarch64-linux
[22:20] <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:31] <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:32] <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:33] <elopio> it's working for me, but might be luck.
[22:44] <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:48] <ikey> is snapd forcing a host os-release into the snap?
[23:16] <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:18] <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:28] <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:29] <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:30] <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:32] <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:33] <kyrofa> That leads us to commit be4a92ad709e98975301a19a15025154bd10d8b2
[23:34] <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:35] <kyrofa> That brings you to the snapcraft/cli package that I mentioned
[23:36] <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:37] <gsilvapt> So the file to be changed is actually snapcraft/__init__.py
[23:37] <gsilvapt> is that correct?
[23:42] <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:43] <kyrofa> (I would suggest a new file)
[23:44] <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:45] <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:47] <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:48] <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:49] <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:51] <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:52] <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:53] <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:54] <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:55] <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:56] <kyrofa> sergiusens, nice
[23:57] <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:59] <kyrofa> sergiusens, elopio do we to move all the catkin integration tests into snapd tests?
[23:59] <kyrofa> do we WANT rather