[03:51] <mup> PR snapcraft#2132 closed: errors: generic exception for common.run[_output] <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2132>
[04:03] <ryan___> hi
[04:03] <ryan___> How might I be able to deploy snaps without going to the snap store?
[04:04] <ryan___> Like I have built snaps, but I'd like to distribute it only to specific users whom should be able to download it
[04:57] <mborzecki> morning
[05:15] <mborzecki> much fun when the gnome session dies out of the blue
[05:21] <zyga> Hey
[05:29] <mborzecki> zyga: hey
[05:29] <mborzecki> zyga: so today we merge everything that's green right?
[05:32] <mborzecki> omg, today must be some gnome shell love day
[05:33] <mvo> hey mborzecki
[05:34] <mvo> mborzecki: just saw your helper to corrupt an image, nice!
[05:34] <mborzecki> mvo: hey, yeah took some time, fat is super annoying to parse
[05:34] <mborzecki> all that legacy cruft :/
[05:36] <mvo> mborzecki: I'm totally with you here :)
[05:38] <mvo> mborzecki: I just verified that https://github.com/dosfstools/dosfstools/pull/83 works with the corrupted image created from your script. this is really nice
[05:38] <mup> PR dosfstools/dosfstools#83: [RFS] check.c: do lfn_remove  on auto_rename() <Created by mvo5> <https://github.com/dosfstools/dosfstools/pull/83>
[05:38] <mborzecki> yay
[05:39] <mborzecki> mvo: any word from maintainers of dosfstools?
[05:44] <mvo> mborzecki: unfortunatly not, I will try a debian bugreport next, maybe he reads those
[05:48] <zyga> mborzecki: Yes, that is the plan
[05:48] <mvo> zyga: good morning!
[05:48] <mvo> zyga, mborzecki what did I miss fri/mon ? where are we standing?
[05:49] <zyga> Man, it is so cold today
[05:49] <zyga> Mvo, nothing major. Just lots of catch up with PRs
[05:49] <mvo> zyga: cool
[05:49] <zyga> I have a question about
[05:49] <zyga> Your fixes for 8
[05:50] <zyga> There is a new service there
[05:50] <mvo> zyga: sure
[05:50] <zyga> But there are no changes to packaging
[05:50] <mvo> zyga: you mean core-fixup?
[05:50] <zyga> Yes
[05:50] <mvo> zyga: its an existing service
[05:50] <mvo> zyga: I just extended it
[05:50] <zyga> Ahh
[05:50] <zyga> Ok
[05:50] <zyga> I must have mistress
[05:50] <zyga> Misread
[05:50] <mvo> zyga: conveniently we had an issue before
[05:50] <mvo> zyga: lol@mistress
[05:50] <zyga> I did a compare against 6
[05:50] <zyga> Because 7 didn’t have a tarball
[05:51] <zyga> Yeah, phone is fun ;-)
[05:51] <mvo> zyga: yeah .7 was very short lived, sorry for that
[05:51] <zyga> Taking the dog out
[05:51] <mvo> zyga: I should have waited a bit longer
[05:51] <mvo> zyga: heh, enjoy!
[05:51] <zyga> No worries, just wanted to double check
[05:51] <mvo> zyga: thank you for this
[05:52] <mvo> zyga: I will go over the PRs now and see what comments need addressing, iirc I left some small ones so that I don't have to wait for tests. now is a good time to address them
[06:01] <zyga> I need to work from downtown today
[06:01] <zyga> Need to go to a government office for some paperwork
[06:02] <mborzecki> uhh
[06:02] <mborzecki> zyga: good luck
[06:02] <mborzecki> reminds me i need to replace the my car registration
[06:03] <mborzecki> btw. i'll have a longer break ~1030, my daughter has an athletic tournament at her school, going there to cheer for her
[06:03] <zyga> Woot, nice :-)
[06:04] <zyga> I will be home soon, grab my gear and commute
[06:13] <mup> PR snapd#5156 opened: core-fixup: address review feedback from #5147 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5156>
[07:00] <pstolowski> morning
[07:02] <mborzecki> pstolowski: hey
[07:24] <mborzecki> #5156 travis job timed out, restarted it
[07:24] <mup> PR #5156: core-fixup: address review feedback from #5147 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5156>
[07:26]  * zyga is on a bus, commuting feels weird now
[07:26] <zyga> Weird and inefficient
[07:27] <mborzecki> zyga: no tram lines going near your destination?
[07:28] <zyga> No, not even close
[07:28] <zyga> Closest tram is the subway
[07:32] <zyga> re
[07:32] <zyga> I specifically took the slower bus to be able to sit and work on the way :)
[07:33] <zyga> at this time the rush hour is over and bus is rather empty
[07:37] <zyga> oh drat
[07:37] <zyga> no 2fa :(
[07:37] <zyga> well
[07:42] <pedronis> mvo: hi
[07:43] <pedronis> mvo: seems autopkgtest tests sometimes fail over a flaky snapstate test
[07:43] <mvo> pedronis: good morning! do you have a link with the particular failure?
[07:44] <pedronis> mvo:  https://launchpadlibrarian.net/370203382/buildlog_ubuntu-xenial-armhf.snapd_2.32.8+git720.9dc7b89~ubuntu16.04.1_BUILDING.txt.gz
[07:44] <pedronis> it's one of the prereq tests
[07:44] <mvo> pedronis: aha, looks like the autopkgtest vms are very slow
[07:45] <mvo> pedronis: I have a look and will improve
[07:50] <mborzecki> any PRs that need attention?
[07:51] <pedronis> mborzecki: #4844 is now green
[07:51] <mup> PR #4844: overlord/snapstate: allow core defaults configuration via 'system' key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4844>
[07:52] <mborzecki> pedronis: merge or do you want to have one last look?
[07:52] <pedronis> I approved it
[07:52] <mborzecki> very well, merging then :)
[07:52] <mup> PR snapd#4844 closed: overlord/snapstate: allow core defaults configuration via 'system' key <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4844>
[07:53] <mborzecki> pedronis: would you like to take a look at https://github.com/snapcore/snapd/pull/5091 too? you were the last to modify the auto refresh code and know ins and outs of this
[07:53] <mup> PR #5091: many: hold refresh when on metered connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5091>
[07:54] <pedronis> will do in a little bit
[07:56] <mborzecki> pedronis: thanks!
[08:03] <diddledan> does anyone know where the gnome-system-monitor snap source is? I want to investigate to see if anything special is done for localisations
[08:03] <mborzecki> zyga: https://paste.ubuntu.com/p/wSN7fZCn6Q/ nice!
[08:12] <zyga> mborzecki: yeah, now just convince people to enable apparmor
[08:12] <mborzecki> hahaha
[08:15] <mborzecki> zyga: fwiw there's both apparmor and selinux enabled kernel packages in aur, plus a bunch of userland packages in respective flavors, still bugs me why would one want to rebuild that much of the base system and not just use some other distro
[08:18] <mup> PR snapd#5157 opened: many: improve `snap wait` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/5157>
[08:21] <mborzecki> afk for 1-2h
[08:22]  * zyga arrived close to the office
[08:22] <mup> Bug #1771299 opened: snap is a total failure, drop it <Snappy:New> <https://launchpad.net/bugs/1771299>
[08:22] <zyga> need to check where to deliver the papers
[08:22] <zyga> but I can enjoy a cup of coffee and work some more from a restaurant now
[08:29] <diddledan> this is a delightful morning message: https://github.com/snapcrafters/gimp/issues/27
[08:32] <Chipaca> diddledan: https://giphy.com/embed/nPTXD4lJmDSTe
[08:32] <diddledan> haha
[08:32] <diddledan> gotta love crab ideas
[08:33] <zyga> yeah
[08:33] <zyga> crab is good cooked
[08:33] <zyga> ;-)
[08:33] <Chipaca> diddledan: also, https://giphy.com/embed/26mfgW5tgmbV7wkUg
[08:33] <zyga> I love that I've seen this guy on various forums
[08:33] <zyga> spewing toxic waste from his mouth
[08:33] <Chipaca> zyga: s/his/their/
[08:34] <mup> PR snapd#5158 opened: boot,partition: improve tests/docs around SetNextBoot() <Created by mvo5> <https://github.com/snapcore/snapd/pull/5158>
[08:34] <zyga> also the LP issue about crabs
[08:34] <mup> Bug #1771299 changed: snap is a total failure, drop it <Snappy:Won't Fix> <https://launchpad.net/bugs/1771299>
[08:34] <mvo> sorry for all those PRs, its leftovers from the madness last week, hopefully super trivial to review
[08:35] <Chipaca> zyga: if you go to the github's user's homepage, it's illuminating
[08:35] <zyga> oh?
[08:35]  * zyga looks
[08:35] <Chipaca> also, they're german. So it's mvo's fault.
[08:35] <zyga> Chipaca: what's illuminating?
[08:35] <mvo> hm, yeah, some crabs are german
[08:35] <zyga> the crab picture :D
[08:36] <zyga> mvo: crabs are an international exterretorial nation ;)
[08:37] <Chipaca> zyga: to my prejudiced eyes, that's a website created by an agry 13-year-old
[08:37] <Chipaca> angry, also
[08:37] <zyga> https://translate.google.com/translate?sl=de&tl=en&js=y&prev=_t&hl=pl&ie=UTF-8&u=http%3A%2F%2Fschwender-beyer.de%2F&edit-text=&act=url
[08:37] <diddledan> I love the icons all crossed-out
[08:37] <zyga> well
[08:37]  * zyga gets back to work
[08:37] <zyga> <insert no crab emoji>
[08:39] <Chipaca> zyga: 🦀̸
[08:40] <mvo> Chipaca: what website is this?
[08:40] <zyga> where is no-space combining strike-through glyph
[08:40] <mvo> Chipaca: I just saw the bugreport?
[08:40] <Chipaca> mvo: starting from this *other* bug report by the same crabby person: https://github.com/snapcrafters/gimp/issues/27
[08:40] <Chipaca> zyga: U+0338
[08:41] <Chipaca> zyga: all combinings are zero-width, fwiw
[08:41] <zyga> Chipaca: this bug report is zero-value, all crab
[08:41] <Chipaca> zyga: https://www.youtube.com/watch?v=PhM4VQFkw04
[08:42]  * zyga looked at twitter and ...
[08:42] <zyga> https://twitter.com/nixcraft/status/996283804527378432
[08:42] <Chipaca> zyga: fwiw i'd've set it to 'opinion' more than 'won't fix'
[08:43] <zyga> Chipaca: thanks, though I doubt we will fix this guy
[08:43] <Chipaca> zyga: "won't fix" means you think they have a point :-)
[08:43] <zyga> I think they lost the point a long time ago :)
[08:43] <zyga> mvo: ^ that's the vfat issue
[08:43] <mvo> zyga: "opinion" might be best, otoh its fine, one open bug is enough
[08:44] <Chipaca> mvo: rationale*
[08:44] <Chipaca> :-)
[08:44] <mvo> zyga: this is briliant
[08:44] <mvo> Chipaca: *cough* thank you
[08:45] <mvo> Chipaca: I should have written that in GH, then I could edit it ;)
[08:45] <Chipaca> mvo: ikr
[08:45] <zyga>  github is doubleplusgood
[08:45] <mvo> zyga: thanks for your comments in the PRs \o/
[08:45] <zyga> mvo: I'm going through it
[08:45] <zyga> I was thinking if it would be better to use present tesnse
[08:45] <zyga> rather than snapd will do this and that
[08:46] <zyga> I can propose one on top once this lands
[08:46] <mvo> cachio: hey, good morning! how is the QA for .8 looking? I heard there might be issues ?
[08:46] <mvo> zyga: sure
[08:47]  * diddledan spies popey is awake
[08:49] <zyga> mvo: https://github.com/snapcore/snapd/pull/5158/files#r188209242
[08:49] <mup> PR #5158: boot,partition: improve tests/docs around SetNextBoot() <Created by mvo5> <https://github.com/snapcore/snapd/pull/5158>
[08:50] <zyga> https://github.com/anordal/shellharden/blob/master/how_to_do_things_safely_in_bash.md
[08:50] <zyga> ^ ^ ^ interesting read
[09:09] <kjackal> hey zyga, just read you did some cuda tinkering with snaps, is any of your work public somewhere?
[09:09] <zyga> kjackal: hey
[09:09] <zyga> kjackal: I didn't get anything operational
[09:09] <zyga> kjackal: unfortunately I no longer have nvidia hardware
[09:10] <kjackal> thats fine, I am looking for some guidance
[09:10] <zyga> (or one that works with current cuda)
[09:10] <kjackal> How would cuda integration work?
[09:10] <zyga> kjackal: cuda is just some userspace stuff really
[09:10] <zyga> kjackal: the opengl interface today should give you access to nvidia character devices
[09:10] <kjackal> How did you manage the cuda-drivers installation?
[09:11] <zyga> kjackal: make a cuda hello world
[09:11] <zyga> kjackal: that was long ago, I don't recall that anymore
[09:11] <zyga> kjackal: my advice is as follows:
[09:11] <zyga> kjackal: 1) build the simplest cuda program you can
[09:11] <zyga> kjackal: 2) ldd it, print that out
[09:11] <zyga> kjackal: 3) snap it manually, use the opengl interface
[09:11] <zyga> kjackal: 4) run it and see what happens
[09:12] <zyga> kjackal: put that on a forum and CC mborzeck1
[09:12] <zyga> he has the recent hardware and should be able to help you out
[09:12] <Chipaca> mvo: when you have a moment, can we talk about #1739097?
[09:12] <mup> Bug #1739097: "This leaves <snap> tracking edge." <snapd:In Progress> <https://launchpad.net/bugs/1739097>
[09:12] <zyga> we correctly put all the things inside the sandbox now
[09:12] <zyga> so the only possibly missing thin is a userspace library bit
[09:12] <zyga> we should copy all of those but nobody tested that
[09:13] <kjackal> zyga: I am not sure I can follow that path, I need to make the nvidia-docker working :(
[09:13] <zyga> kjackal: nvidia-docker?
[09:13] <zyga> how is that related
[09:14] <zyga> E: Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily unavailable)
[09:14] <zyga> E: Unable to lock directory /var/lib/apt/lists/
[09:14] <zyga> wasn't this fixed yesterday ^ ?
[09:14] <zyga> mvo: please fetch origin and rebase your latest PRs
[09:14] <zyga> kjackal: I don't know anything about nvidia-docker
[09:14] <kjackal> zyga: nvidia-docker needs the cuda drivers installed on the host machine
[09:14] <zyga> kjackal: I can help you with snaps, not docker
[09:15] <kjackal> sure, forget anything I said about docker
[09:15] <kjackal> the question is how do I deploy the cuda-drivers deb package ?
[09:15] <zyga> I don't know
[09:16] <zyga> do you mean install?
[09:16] <zyga> I assumed you just install that and that's it
[09:16] <kjackal> apt-get install cuda-drivers
[09:18] <kjackal> zyga, I hope the missing link is the cuda-drivers, the rest of the stack seems to be working, but I will know if i get cuda working
[09:18] <kjackal> zyga: I get this error: /snap/microk8s/x1/usr/bin/nvidia-container-cli --load-kmods configure --ldconfig=@/sbin/ldconfig.real --device=all
[09:18] <kjackal> --utility
[09:18] <kjackal> --pid=3426 /var/snap/microk8s/x1/lib/docker/overlay2/8e97d76a3e4a0b2d05f11d4744b805ab91bad8caa62c39a942d2f110f9fc7d68/merged]\\\\nnvidia-container-cli:
[09:18] <kjackal> initialization error: load library failed: libnvidia-fatbinaryloader.so.390.30
[09:19] <zyga> I don't know what this is or what you are doing
[09:19] <zyga> are you running inside docker inside a snap?
[09:19] <zyga> can you rewind to just plain system with nvidia and cuda working and move from there
[09:20] <kjackal> lets forget about docker, I have a binary inside my snap that needs to load libnvidia-fatbinaryloader.so.390.30 that comes with cuda-drivers
[09:20] <zyga> do you get any denials?
[09:20] <zyga> where is the library relative to the root of the snap
[09:21] <kjackal> I am in classic confinement
[09:21] <zyga> oh
[09:21] <zyga> that's even more messy then
[09:21] <kjackal> :) it is
[09:22] <mvo> Chipaca: sure, didn't we fix the message a while ago?
[09:22] <Chipaca> mvo: that's why we're having this conversation :-)
[09:22] <mvo> zyga: I can rebase/repush, I thought my master was up-to-date, let me double check
[09:22] <Chipaca> mvo: it was fixed to be unambiguous, yes
[09:22] <Chipaca> mvo: unambiguously wrong :-D
[09:22] <zyga> mvo: then the fix for apt unattended upgrades is wrong
[09:22] <kjackal> I was thinking that during the install hook I could apt-install cuda-drivers and then update the LD_LIBRARY_PATH of my wrapper. But this does not sound right. zyga?
[09:23] <Chipaca> mvo: sorry i missed this, to be fair you did tag me and i missed it
[09:23] <zyga> kjackal: that's all crazy IMO
[09:23] <zyga> kjackal: if your snap's hook uses apt it is not a good snap IMO
[09:23] <mvo> Chipaca: oh, so this means "Snap %q is *now* tracking %v"?
[09:23] <mvo> Chipaca: or in what way is it wrong?
[09:23] <zyga> kjackal: can you please go back
[09:23] <Chipaca> mvo: the message is printed when the snap is tracking channel X, but the revision is from channel Y
[09:23] <zyga> kjackal: run a hello-world cuda app outside all magic
[09:23] <zyga> kjackal: share that
[09:23] <zyga> kjackal: and let's iterate
[09:24] <mvo> zyga: what fix was that? did it happen in one of the recent PRs?
[09:24] <zyga> kjackal: can you get that part to work?
[09:24] <zyga> mvo: I don't know, cachio fixed it
[09:24] <mvo> zyga: ok
[09:24] <kjackal> what would that giveme zyga? What would be the next steps?
[09:24] <mvo> Chipaca: what will happen in this case? the snap keeps tracking channel X ?
[09:24] <zyga> kjackal: that would give you a binary
[09:24] <Chipaca> mvo: the snap is tracking channel X, yes
[09:24] <zyga> kjackal: you can inspect that binary, strace it
[09:24] <zyga> see what it loads
[09:24] <zyga> kjackal: see what it needs to operate
[09:25] <zyga> kjackal: then you can put that binary (built binary) into a snap you made
[09:25] <zyga> kjackal: run it there
[09:25] <zyga> see what braks
[09:25] <Chipaca> mvo: if a revision is released to channel X it'll grab that, it's only getting things from Y because X is closed
[09:25] <zyga> *breaks
[09:25] <zyga> see why, iterate
[09:25] <zyga> eventually you will be able to run that built binary inside your snap
[09:25] <zyga> kjackal: I suspect you will do more things after that but before this is achieved I don't know what we are doing
[09:25] <mvo> Chipaca: ok, I see. sorry for this
[09:26] <Chipaca> mvo: it's not a very clear corner case
[09:26] <Chipaca> mvo: in the bug report i suggest "this revision is from channel %s; we'll continue to check channel %s for updates"
[09:26] <Chipaca> mvo: but i don't know if that is clear
[09:26] <Chipaca> also the royal we is probably not what we want
[09:27] <mup> PR snapd#5159 opened: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159>
[09:27] <mvo> Chipaca: yeah, the message looks like the right direction though
[09:27] <zyga> https://github.com/snapcore/snapd/pull/5159 is simple, will let me build the tests  that jdstrand requested
[09:27] <mup> PR #5159: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159>
[09:27] <zyga> anyone wants to look quickly?
[09:27] <Chipaca> popey: you're good with words, sometimes, can you think of a better way of saying this?
[09:27]  * Chipaca only used "sometimes" to not trigger the "aw shucks" response
[09:28]  * zyga goes to the goverment office to do paperwork, ttyl
[09:28] <zyga> kjackal: I'll be connected but I won't reply for a while, let's keep chatting, I find this topic interesting (if only I had correct HW)
[09:30] <Chipaca> zyga: kjackal: for extra fun, you can run cuda stuff on PRIME hardware when the intel card has the con
[09:31] <kjackal> :)
[09:31] <Chipaca> zyga: and that might royally mess up the detection stuff
[09:31] <Chipaca> dunno
[09:31] <popey> Chipaca: hello. what words in particular, and where?
[09:31] <Chipaca> popey: when you 'snap install --edge foo' but edge is closed right now
[09:32] <Chipaca> popey: so you get it from, say, beta instead
[09:32] <Chipaca> popey: right now we print something that's incorrect, so looking at fixing that
[09:32] <Chipaca> popey: so far best attempt is "this revision is from channel %s; we'll continue to check channel %s for updates"
[09:32] <Chipaca> popey: but we don't use the 'we' elsewhere :-)
[09:32] <popey> "$channel for $snap is closed, forwarding to $channel+1"
[09:33] <Chipaca> popey: that does not convey the 'as soon as something is pushed to edge you'll get it instead of this beta crud'
[09:33] <popey> you will?
[09:33] <popey> I thought you get bumped to the next channel down and stay there
[09:33] <Chipaca> that's what tracking means
[09:33] <Chipaca> nope
[09:33] <popey> like, if you were on beta, and I close it, you're now in stable
[09:34] <popey> if I re-open beta, you flip back to beta?
[09:34] <Chipaca> yes
[09:34] <popey> wow
[09:34] <diddledan> who understands why gimp isn't picking up localisations? because I sure as chocolate don't understand it
[09:34] <popey> this is not well known
[09:34] <Chipaca> popey: not even the whole snapd team was aware of it :-)
[09:34] <popey> loooolz
[09:34] <diddledan> I found this post https://forum.snapcraft.io/t/lack-of-compiled-locales-breaks-gettext-based-localisation/3758/14 but that claims it's fixed
[09:35] <Chipaca> diddledan: doesn't everybody speak esperanto already?
[09:35] <diddledan> if they speak esperanto they'll not get the UI in their language, instead it'll be en_US
[09:35] <Chipaca> diddledan: i thought en_US was esperanto 2.0
[09:40] <kjackal> zyga: what will we do with the strace of the cuda program?
[09:40] <Chipaca> popey: "$trackingChannel for $snap is closed, temporarily forwarding to $snapChannel"?
[09:41] <popey> better
[09:41] <Chipaca> k
[09:41] <kjackal> We will be able to identify libraries needed for a cuda program to function, right? Then what?
[09:43] <mup> PR snapd#5160 opened: snapstate: make TestDoPrereqRetryWhenBaseInFlight less brittle <Created by mvo5> <https://github.com/snapcore/snapd/pull/5160>
[09:46] <zyga> kjackal: look at the ser of files being accessed
[09:46] <zyga> kjackal: then we check if current nvidia integration handles all of them
[09:47] <niemeyer> Moins
[09:47] <zyga> Hey
[09:47]  * zyga waits in line to file paperwork, 60 people in front, ouch
[09:50] <kjackal> "current nvidia integration" ?
[09:51] <Riddell> 'support all snap apps, including "classic" apps'  what are classic apps?
[09:51] <mvo> pedronis: the above pr is to make the issue in the handlers_prereq_test.go:247: more robust
[09:52] <zyga> kjackal: we have special code that bridges nvidia driver to snap space
[09:52] <zyga> kjackal: but it doesn’t apply to classic confinement
[09:53] <zyga> Riddell: classic confinement is the way we describe snaps that run without a special mount namespace and with little to no confinement
[09:53] <zyga> Like typical classic packages
[09:53] <zyga> Hence the name
[09:53] <Chipaca> Riddell: i don't know what classic apps are in that context; classic snaps are what zyga just said
[09:54] <Riddell> I'm writing the KDE Plasma 5.13 and this is what I have for Plasma Discover changes  'Snap support now follows Snap application permissions and it's possible to use classic Snap formats.'
[09:55] <Chipaca> Riddell: I literally can't even :-)
[09:55] <Chipaca> Riddell: you're going to have to ask the author for clarification i'm afraid
[09:56] <Chipaca> i don't know what "classic Snap formats" are, and I can only guess at what "Snap application permissions" are
[09:57] <zyga> Those are probably worded incorrectly
[09:57] <Chipaca> yes
[09:57] <zyga> They should be “snaps using classic confinement” and “snap interfaces”
[09:57] <zyga> Not permissions
[09:58] <Chipaca> zyga: _if_ that's what they meant
[09:58] <Chipaca> I guess I fall back to "refusing to guess" too easily (but it's saved me in the pasts)
[09:58] <Chipaca> past*
[09:58] <zyga> Well, if they meant something else I’d like to see those patches b cause we don’t have such features
[09:59] <Chipaca> man, i wish you could toggle a spread run to debug
[10:04] <mup> PR snapd#5161 opened: cmd/snap: fix the message when snap.channel != snap.tracking <Created by chipaca> <https://github.com/snapcore/snapd/pull/5161>
[10:09] <zyga> Chipaca reviewed
[10:09] <pedronis> Chipaca: could you look at #5077 ?
[10:09] <mup> PR #5077: overlord/snapstate,overlord/auth,store: coalesce no auth user refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/5077>
[10:10] <Chipaca> zyga: the truncated bit is because the fake store replies with "" for tracking channel
[10:10] <Chipaca> zyga: (there's an ad hoc comment on the test)
[10:10] <zyga> Ah
[10:11] <Chipaca> zyga: but you're right about the i18n thing, will fix
[10:11] <zyga> Thanks
[10:11] <Chipaca> zyga: also, will reply there
[10:11] <Chipaca> why am i doing it here
[10:11] <zyga> Ack :-)
[10:11] <Chipaca> just to make your life harder
[10:16] <Chipaca> pedronis: nice PR
[10:18] <zyga> Yeah, reading too
[10:20] <Riddell> zyga: thanks changed to 'Snap support now follows Snap interfaces and it's possible to use the Snaps using classic confinement.'
[10:21] <zyga> What does “follows” here mean?
[10:21] <zyga> Otherwise it reads ok
[10:21] <Riddell> good question
[10:22] <Riddell> 'uses Snap interfaces'?  'allows Snap interfaces'?
[10:22] <Chipaca> Riddell: is this talking about a GUI?
[10:23] <Riddell> Chipaca: yes
[10:23] <Chipaca> does it mean that it now exposes toggles to connect interfaces?
[10:23] <Riddell> Chipaca: that sounds likely
[10:23] <Riddell> toggle is a real term? I love that
[10:23] <Chipaca> if so, then maybe saying that ("now allows toggling interface connections") might be preferably, although i might be too deep in the argot
[10:24] <Chipaca> Riddell: it's a verb and a noun :-)
[10:24] <Chipaca> you just need a place name and you can go all 'buffalo buffalo buffalo' on it
[10:25] <Chipaca> preferable*
[10:25] <Chipaca> my language is shot (toady?) :-/
[10:26] <Riddell> thanks, I've used that in https://www.kde.org/announcements/plasma-5.12.90.php#discover
[10:27] <Chipaca> Riddell: nice
[10:28] <zyga> Thanks Riddell
[10:28] <popey> that's awesome
[10:28] <popey> Riddell: is the snap plugin for kde discover installed by default - my kde neon is some months old and I manually installed it iirc
[10:31] <Riddell> popey: no I don't think so, probably because last time i tried it I couldn't get it to work because it needs some newer snap library.  plasma-discover-snap-backend is the package.  but I'm mostly waiting on us moving to 18.04 before looking at snaps again
[10:35] <thresh> what can I subscribe to to receive snapcraft/snapd changelogs/release notes etc?  I'm mostly interested in theming advancements, though.
[10:35] <popey> Riddell: great, should work fine in 18.04. Happy to help with testing etc. :)
[10:36] <Wimpress> Riddell: I need to schedule the next KDE catchup with Aleix and Harald, would you like an invite?
[10:36] <Riddell> Wimpress: sure
[10:37] <Wimpress> OK. Expect an invite soon :-)
[10:39] <mborzeck1> re
[10:40] <zyga> thresh: there should be a topic on the forum that you can subscribe to
[10:40] <zyga> I’m relocating now so I cannot easily share
[10:52] <zyga> thresh: so looking for themes I can see several topics
[10:52] <zyga> thresh: but the one to follow, IMO, is this one https://forum.snapcraft.io/t/supporting-desktop-themes-via-the-content-interface/4122
[10:53] <zyga> thresh: as the person posting is also working on the feature
[10:54] <zyga> thresh: you can bookmark the topic to easily return to it (a forum bookmark, not browser one)
[10:55]  * zyga reads https://blog.ubuntu.com/2018/05/15/trust-and-security-in-the-snap-store
[10:55] <zyga> well written :)
[10:55] <thresh> many thanks
[10:55] <pedronis> mborzeck1: hi,  #5091 looks good,  mostly some suggestions to fold some things more into helpers
[10:55] <mup> PR #5091: many: hold refresh when on metered connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5091>
[10:56] <Chipaca> mborzeck1: how did you fix the 'could not get lock' problem you were having yesterday?
[10:56] <zyga> Chipaca: AFAIK chacio changed something in the image
[10:56] <Chipaca> zyga: i just got the same thing again
[10:56] <zyga> Chipaca: it is the bionic update kicking in that is doing that from what he told me
[10:56] <Chipaca> https://api.travis-ci.org/v3/job/379141529/log.txt
[10:57] <zyga> Chipaca: yeah, me too
[10:57] <zyga> I'd like to see what the fix did
[10:57] <mborzeck1> pedronis: thanks for the review
[10:57] <zyga> I didn't see any PRs, perhaps the image was edited
[10:57] <mborzeck1> Chipaca: it's gone now, all i need to know ;)
[10:57] <Chipaca> mborzeck1: 's not :-)
[10:57] <Chipaca> bah, maybe i need to merge master
[10:57] <Chipaca> (but i did before starting...?)
[10:58] <mborzecki> i thought this was 'image' related
[10:58] <mborzecki> saw a commit with related message pushed to spread-images
[10:58] <mborzecki> Chipaca: https://github.com/snapcore/spread-images/pull/10/commits/a84f101cd538da1a63da4da513aca436dce5b15f
[10:58] <mup> PR spread-images#10: New task to add debian-sid as a gce image <Created by sergiocazzolato> <https://github.com/snapcore/spread-images/pull/10>
[11:02] <zyga> cachio: we are still seeing the issue
[11:03] <zyga> cachio: perhaps we should drop unattended-upgrades from the image?
[11:05]  * zyga resumes reviews
[11:05] <pstolowski> pedronis: i've addressed your comments to #4510 (and the test failure is unrelated, it's what zyga just mentioned i think)
[11:05] <mup> PR #4510: asserts: use Attrer in policy checks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4510>
[11:05] <zyga> gaah
[11:06] <zyga> is there a tool that fixes this automatically
[11:06] <zyga> testutil/lowlevel_test.go:663: github.com/snapcore/snapd/testutil.CallResult composite literal uses unkeyed fields
[11:06] <pedronis> pstolowski: thx, I saw the mails passing by, I will look in a little bit
[11:12] <mborzecki> hm isn't apt smart enough to not block on prompt when stdin is not a tty? https://github.com/snapcore/spread-images/pull/10/commits/a84f101cd538da1a63da4da513aca436dce5b15f#diff-91d7306570fb598492422cd22f1aebfdR43
[11:12] <mup> PR spread-images#10: New task to add debian-sid as a gce image <Created by sergiocazzolato> <https://github.com/snapcore/spread-images/pull/10>
[11:12] <mborzecki> iirc dpkg-reconfigure does it already
[11:13] <zyga> mborzecki: I bet it is using a tty
[11:13] <zyga> mborzecki: the whole session runs in a ptty
[11:13] <zyga> mborzecki: and the issue is not prompting, is it?
[11:13] <zyga> it's running "apt-get update"
[11:13] <mborzecki> no clue, that's what the commit message is fixing
[11:14] <mborzecki> s/message//
[11:16] <mborzecki> #5156 timeouted again
[11:16] <mup> PR #5156: core-fixup: address review feedback from #5147 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5156>
[11:17] <zyga> hmm hmm
[11:17] <zyga> Chipaca: do you know of a tool that automatically adds struct field names to literals?
[11:17] <Chipaca> zyga: I do not
[11:18]  * zyga does *not* fancy adding 100s of those by hand
[11:18] <Chipaca> zyga: what PR is that?
[11:18] <zyga> https://github.com/snapcore/snapd/pull/5159
[11:18] <mup> PR #5159: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159>
[11:18] <zyga> hmm
[11:19] <zyga> I could make it a [2]interface{}
[11:19] <zyga> it would work, no?
[11:19] <zyga> (the type)
[11:19] <zyga> then the literal would be OK
[11:19]  * zyga tries
[11:19] <Chipaca> zyga: plz no :-)
[11:20] <zyga> http://paste.ubuntu.com/p/hSgWFpPby2/
[11:20] <zyga> that's the whole diff and it passes go vet
[11:20] <zyga> I think typing those Call/Result field headers will drive people mad
[11:22] <Chipaca> zyga: so, RCalls() is nice because you get to see the whole thing
[11:22] <Chipaca> zyga: and you have Calls()  that returns jut the names
[11:22] <zyga> yeah, for backwards compat
[11:22] <Chipaca> zyga: why not have CallResults() that returns just the values?
[11:22] <zyga> I plan to drop (at least) the usage of Calls
[11:22] <mborzecki> zyga: func callResult(call string, result interface{}) CallResult { return CallResult{Call: call, Result: result} } ?
[11:22] <zyga> Chipaca: beause it's not easy to use then
[11:23] <zyga> Chipaca: if a test has 50 syscalls that's not readable
[11:23] <Chipaca> zyga: and mborzecki's option? ^
[11:23] <zyga> mborzecki: that's still passing that in every single line of tests that checks this, vs not passing anything new
[11:23] <zyga> the real application will be for code like ...
[11:23] <Chipaca> []CallResult{{...}, {...}, ...}
[11:24] <zyga> https://github.com/snapcore/snapd/blob/master/cmd/snap-update-ns/secure_bindmount_test.go#L80
[11:24] <mborzecki> hmm
[11:24] <zyga> https://github.com/snapcore/snapd/blob/master/cmd/snap-update-ns/secure_bindmount_test.go#L176 is even better (fits my whole screen)
[11:24] <zyga> I have that already patched to use Rcall
[11:24] <zyga> I just didn't run vet before :/
[11:24] <Chipaca> zyga: FWIW I think the long things are more readable with the named fields
[11:25] <zyga> https://github.com/snapcore/snapd/blob/master/cmd/snap-update-ns/change_test.go#L1194 <- imagine if this was filled with Call Result
[11:25] <zyga> how is that helping?
[11:26] <Chipaca> zyga: do you have it with the results already?
[11:26] <Chipaca> zyga: just the names alone is a quagmire to read
[11:26] <zyga> yeah, one sec
[11:26] <Chipaca> zyga: with the values it's probably worse
[11:26] <Chipaca> but, show me
[11:26] <zyga> http://paste.ubuntu.com/p/dZYBgDMfVs/
[11:27] <zyga> a fragment, I have it split into some branches because it was written slightly ahead of master
[11:27] <zyga> FYI: the code has both calls/rcalls
[11:27] <zyga> I plan to drop calls, this is just to prove that it works
[11:27] <zyga> I will keep calls in testutil/lowlevel_test.go only
[11:28] <zyga> oh
[11:28] <zyga> one thing I could do is to make the return value optional to reduce the number of nil's
[11:28] <zyga> not sure if worth doing
[11:28] <zyga> Chipaca: also interesting to see how we mount things if you didn't know that before
[11:31] <zyga> Chipaca: shall I push http://paste.ubuntu.com/p/zTXJnJjsqh/
[11:31] <zyga>  
[11:31] <Chipaca> zyga: my 5¢ is that it is not less readable with the labels, and in some cases might be more, and you get to drop th enils
[11:31] <zyga> Chipaca: ok, let me think how to rewrite that
[11:31] <Chipaca> but, you spend a lot more time looking at this than I do
[11:32] <Chipaca> zyga: I can do it for you after lunch if you'd rather not
[11:32] <Chipaca> sounds like a fun bit of perl :-)
[11:32] <zyga> Chipaca: fun and perl is only true if perl is EOLd and debian tools are rewritten in rust
[11:32] <zyga> ;)
[11:32] <zyga> Chipaca: as a compromise
[11:32] <zyga> C and R
[11:32] <Chipaca> maybe it's just that i need lunch
[11:32] <zyga> instead of Call Result?
[11:33] <zyga> then it's shorter but still explicit
[11:33] <Chipaca> sure
[11:33] <zyga> jdstrand: offtopic, are you back today?
[11:33] <zyga> Chipaca: thanks, I'll do this
[11:33] <zyga> Chipaca: drop your feedback there so that others know we discussed this
[11:37] <zyga> Chipaca: FYI, I just used sublime's multi-line cursor to edit that qucikly
[11:39] <zyga> Chipaca: should I split R: into R: E:
[11:39] <zyga> result/error
[11:40] <Chipaca> zyga: is it ever not an error or nil?
[11:40] <Chipaca> i guess when it's a fd and stuff
[11:40] <Chipaca> eh
[11:40] <zyga> it's either an error or it is whatever the syscall returns
[11:40] <Chipaca> zyga: probably yes
[11:40] <zyga> this would allow me to improve one other thing
[11:40] <zyga> I have a checker for syscall lists
[11:40] <zyga> because the DeepEquals one is garbage
[11:40] <zyga> it could use ErrorMatches on error implicitly
[11:41] <zyga> so error traces would be less repetetive
[11:47] <pedronis> zyga: is #5159 motivated by some open PR ?
[11:47] <mup> PR #5159: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159>
[11:48] <zyga> yes, jamie asked me to write tests that show the file descriptor values clearlyt
[11:48] <zyga> as many of the branches related to layout fixes had tests like that
[11:48] <pedronis> ok, thx
[11:49] <zyga> *clearly
[11:56] <zyga> Chipaca: pushed now
[11:58] <zyga> and I should move
[11:58] <zyga> I will resume reviews soon
[11:59] <zyga> mvo: interesting failure
[11:59] <zyga> + echo 'ERROR: test-snapd-requires-base should not be installable without test-snapd-base'
[11:59] <zyga> ERROR: test-snapd-requires-base should not be installable without test-snapd-base
[11:59] <zyga> this is on https://github.com/snapcore/snapd/pull/5160
[11:59] <mup> PR #5160: snapstate: make TestDoPrereqRetryWhenBaseInFlight less brittle <Created by mvo5> <https://github.com/snapcore/snapd/pull/5160>
[11:59] <zyga> maybe a real bug?
[12:00]  * zyga walks
[12:08] <zyga> The agenda for the Fedora server SIG is interesting this week
[12:08] <zyga> We have one topic requiring discussion this week: whether we will ship a Fedora base snap under the Fedora Server umbrella. Please see the earlier email to this list for further details.
[12:09] <Chipaca> :-D
[12:19] <mborzecki> tests/main/base-snaps failing in Chipaca's and mvo's PRs
[12:19] <zyga> Yes, I commented on one of the PRs
[12:20] <mborzecki> zyga: yeah, it was in mvo's pr which was semi-related, but Chipaca's PR is unrelated
[12:21] <zyga> I think it is either a racy test or racy bug
[12:21] <mborzecki> #5160 and #5161
[12:21] <mup> PR #5160: snapstate: make TestDoPrereqRetryWhenBaseInFlight less brittle <Created by mvo5> <https://github.com/snapcore/snapd/pull/5160>
[12:21] <mup> PR #5161: cmd/snap: fix the message when snap.channel != snap.tracking <Created by chipaca> <https://github.com/snapcore/snapd/pull/5161>
[12:22] <jdstrand> kjackal: hey, responding now since I was on holiday. I'll try to answer all your questions I see in backscroll
[12:24] <jdstrand> kjackal: there is not a way to edit the apparmor profiles and reload them from a hook as the security policy would disallow that. for a classic snap, it may be possible, but not sure which hook could be used (this isn't something that is typically done)
[12:26] <jdstrand> kjackal: there is actually a way to provide your own profile though. you use --security-opt apparmor=some-profile. see https://docs.docker.com/engine/security/apparmor/
[12:26] <mvo> mborzecki, zyga ups, I know why its failing, let me fix it
[12:27] <Chipaca> mvo: tell me more! (mine's also failing)
[12:27] <jdstrand> kjackal: however, you can't create your own profiles (see previous answer), but you could specify one from your snap
[12:28] <mvo> Chipaca: I relesed test-snapd-base to stable which breaks exiting tests
[12:28] <jdstrand> kjackal: you'd really want to copy docker-default then add the signal rule to allow your snap to send signals to it
[12:28] <mvo> Chipaca: I undid that now
[12:28] <Chipaca> mvo: lel
[12:29] <Chipaca> mvo: as punishment now you must review #5161
[12:29] <mup> PR #5161: cmd/snap: fix the message when snap.channel != snap.tracking <Created by chipaca> <https://github.com/snapcore/snapd/pull/5161>
[12:29] <mvo> Chipaca, zyga, mborzecki should be good again, sorry for that. I will tweak my other PR to work somehow
[12:29] <Chipaca> mvo: :-D
[12:29] <jdstrand> kjackal: for a docker from a deb, this would be your best option and a manual step. modifying docker-default is going to be tricky as dockerd will regenerate it on daemon start
[12:32] <jdstrand> kjackal: an option is to ship your own dockerd and plugs 'docker-support'. another option is for you to have the docker snap (rather than deb) installed and then make snapd add the peer rules ala https://forum.snapcraft.io/t/htop-snap-unable-to-signal-aa-enforced-processes/5222/2
[12:34] <jdstrand> cprov: hi! still seeing the 504s with the public store so I filed https://bugs.launchpad.net/snapstore/+bug/1771333
[12:34] <mup> Bug #1771333: frequent 504s when accessing (at least) public store reviews page <Snap Store:New> <https://launchpad.net/bugs/1771333>
[12:36] <cachio> Son_Goku, hey
[12:37] <cprov> jdstrand: I've commented on your public bug, the fix is coming, slightly more involving that we thought.
[12:38] <Son_Goku> cachio, yo
[12:39] <cachio> Son_Goku, for fedora 28 we need google_compute_engine and google_compute_engine_init too
[12:39] <Son_Goku> cachio, gah, okay
[12:40] <cachio> Son_Goku, and oslogin which is already done
[12:40] <cachio> thanks for that
[12:40]  * Son_Goku grumbles about how much he hates monorepos
[12:40] <Son_Goku> cachio, I'll tackle those later today
[12:40] <Son_Goku> hopefully have them ready for you during my lunch time
[12:41] <cachio> Son_Goku, awesome, thanks
[12:50] <kjackal> thank you jdstrand
[12:53] <zyga> I’m on the subway now. Will likely miss standup
[12:55] <mborzecki> kjackal: regarding cuda, libnvidia-fatbinaryloader is what you're missing?
[12:56] <kjackal> that was the first missing lib reported mborzecki
[12:57] <mborzecki> kjackal: it should be picked up by our glob code in snap-confine, is libnvidia-gl also installed on the machine?
[12:57] <mborzecki> kjackal: oh, and what distro is it?
[12:57] <zyga> My update today is simple: catchup on reviews and gardening my PRs
[12:58] <zyga> Heads up: I will be gone on Thursday , Friday and till Wednesday next week
[12:58] <zyga> I will send details on the forum
[12:58] <kjackal> mborzecki: I am on 16.04 and the snap is in classic confinement
[12:59] <kjackal> mborzecki: why are you asking about libnvidia-gl? how would this affect you?
[12:59] <mborzecki> kjackal: hm if it's classic then there should be nothing stopping it from using host libs
[13:01] <mborzecki> kjackal: the detection code in snap-confine checks if nvidia lib (libnvidia-glcore.so.<driver-version>) is in arch directory, but you are on 16.04 (libs were under /usr/lib/nvidia-..) and have a classic snap, so none of this should matter
[13:01] <kjackal> mborzecki: yes, I was thinking I could deploy cuda-drivers on the host, but that would not work towards a strict confinement
[13:03] <jdstrand> cprov: thanks! :)
[13:04] <mborzecki> kjackal: can you ldd the binary that does cuda?
[13:05] <jdstrand> kjackal (cc mborzecki): to be super clear, are you classic confined or devmode confined?
[13:06] <kjackal> jdstrand: classic confined. We also updated the forum request to go through a review
[13:06] <jdstrand> (I ask cause I thought we discussed devmode at the sprint, but classic is being discussed here)
[13:07] <kjackal> jdstrand: with devmode we had the problem that pods do not get killed. So we moved to classic confinement for now
[13:07] <jdstrand> kjackal: I've not caught up on forum email yet, but will
[13:07] <jdstrand> kjackal: I see
[13:08] <jdstrand> kjackal: I'm still suprised that you are sending signals directly to the containers rather than using 'docker ...'
[13:08] <jdstrand> kjackal: but I guess if that is how it works...
[13:12] <kjackal> mborzecki: Here is the ldd: https://pastebin.ubuntu.com/p/M3QxnZ6vhj/
[13:25] <mvo> mborzecki: how do I run shellcheck on my spread tests
[13:25] <mborzecki> mvo: ./spread-shellcheck <path-to-task.yaml>
[13:26] <mborzecki> mvo: pip install --user yq
[13:38] <mborzecki> kjackal: that's just nvidia-container-cli, does not seem that it's missing any lib though
[13:40] <mvo> mborzecki: have you tried ./spread-shellcheck with the yq snap? I get some strange errors here with that
[13:40] <mborzecki> mvo: that's not the same yq
[13:40] <mvo> mborzecki: uh, that explains it :)
[13:40] <mborzecki> same name, different 'modus operandi'
[13:40] <mvo> mborzecki: :(
[13:40] <mvo> mborzecki: you are using the github kislyuk/yq?
[13:41] <mborzecki> i was thinking about dropping yq and using pyaml directly
[13:41] <mborzecki> mvo: https://pypi.org/project/yq/
[13:42] <mvo> mborzecki: might not be a bad idea. I would rather like to have a snap or a deb of the yq we use. I can create a snap I think
[13:42] <mborzecki> mvo: i think that moving this to spread-shellcheck will be easier/faster, it's just pyaml that we really need
[13:44] <mvo> mborzecki: ok, I think you are right, it looks straightforward, will you look into it or shall I?
[13:44] <mborzecki> mvo: i can do it
[13:45] <mvo> mborzecki: thanks! how far are we from running this by default ? i.e. how many unfixed things are still left in the tree?
[13:47] <mborzecki> mvo: all of the tests are fixed in my branch, but i'm pushing this to master in batches of 20 tests, so far we've merged 1 batch, 2nd is waiting for review sprint to finish
[13:47] <mvo> mborzecki: aha, cool
[13:48] <mborzecki> mvo: fwiw the check is running by default now, the tests are whitelisted by adding them to tests/unit/spread-shellcheck/must
[14:09] <mborzecki> xenial apt locking thing also observable on master branch jobs
[14:10] <mup> PR snapd#5162 opened: overlord/hookstate: support undo for hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/5162>
[14:14] <cachio_> Chipaca, the apt-daily.service is locking now
[14:24] <Chipaca> cachio_: disable it in the image
[14:26] <Chipaca> cachio_: sudo systemctl disable --now apt-daily{,-upgrade}.{timer,service}
[14:26] <Chipaca> cachio_: or systemctl disable --now apt-<alt+asterisk>
[14:27] <Chipaca> probably
[14:29] <cachio_> Chipaca, yes, I created a new image
[14:29] <cachio_> I am testing it
[14:29] <cachio_> Chipaca, try rexecuting your branches
[14:29] <Chipaca> cachio_: i should try right now?
[14:30] <cachio_> Chipaca, yes
[14:32] <Chipaca> ok
[14:33] <cachio_> Chipaca, I made few runs and seems to be gone the problem
[14:33] <Chipaca> cachio_: tests are running, will let you know
[14:34] <cachio_> Chipaca, tx
[14:35] <pstolowski> zyga: can you take another look at #4510
[14:35] <mup> PR #4510: asserts: use Attrer in policy checks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4510>
[14:35] <pstolowski> ?
[14:36] <zyga> Yes, in a sieć
[14:36] <zyga> Just got home now
[14:37] <Chipaca> jdstrand: if you're back from your holidays, what's your take on the mandb/libpipeline work? If you're not back, go away.
[14:39] <mup> PR snapcraft#2042 closed: many: implement vendoring support <do-not-merge-yet> <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2042>
[14:43] <zyga> re :-)
[14:44] <zyga> back home, after lunch
[14:45] <mup> PR snapcraft#2138 opened: ci: resurrect codecov <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2138>
[14:45]  * zyga reads 4510
[15:03] <Chipaca> cachio_: all good
[15:03] <cachio_> Chipaca, yes
[15:04] <mup> PR snapd#5161 closed: cmd/snap: fix the message when snap.channel != snap.tracking <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5161>
[15:06] <Chipaca> mvo: wrt #4600, is it ready for a re-review?
[15:06] <mup> PR #4600: configstate: validate known core.* options <Created by mvo5> <https://github.com/snapcore/snapd/pull/4600>
[15:11] <cachio_> zyga, about using jq to query the cursor_id
[15:11] <zyga> yes
[15:12] <cachio_> the problem there is that we don't have jq on ubuntu core
[15:12] <cachio_> so, I should install/remove jq just for querying that
[15:12] <cachio_> that's why I did a mix
[15:12] <cachio_> between jq and the --export
[15:12] <cachio_> any ideas?
[15:14] <cachio_> mborzecki, ideas?
[15:14] <mborzecki> cachio_: iirc there's jq in a snap
[15:14] <mborzecki> meaning, packaged as snap
[15:15] <mborzecki> i saw some tests installing it
[15:15] <cachio_> mborzecki, yes, but all the snaps are removed during the reset
[15:15] <cachio_> so I should install it for each test
[15:15] <cachio_> something that I can do is to skip removing jq
[15:15] <cachio_> as we do with the core, kernel, etc
[15:16] <mborzecki> aah right, it's in the helpers now
[15:17] <zyga> cachio_: can we use the export version everywhere?
[15:17] <zyga> cachio_: or the jq version everywhere?
[15:17] <zyga> I only opposed using two similar code paths
[15:17] <zyga> if we can get jq let's use it
[15:17] <cachio_> jq  yes
[15:17] <zyga> if we cannot then the shell variant looked very good
[15:17] <cachio_> but I have to add a small change to avoid removing jq during the reset
[15:18] <cachio_> zyga, does it make sense?
[15:18] <zyga> cachio_: use the shell version
[15:18] <zyga> it's a one liner
[15:18] <zyga> no complexity
[15:18] <mvo> Chipaca: I'm just working on this one, the "changes()" code is incomplete and needs some tweaks
[15:19] <cachio_> zyga, sorry, which shell version?
[15:19] <zyga> cachio_: you had two code paths
[15:19] <zyga> right?
[15:19] <zyga> one if you had jq
[15:19] <zyga> and another if you didn
[15:19] <zyga> is that correct?
[15:20] <cachio_> yes
[15:20] <mborzecki> cachio_: this one https://github.com/snapcore/snapd/pull/5151/files#diff-c900b6adcccb98df1880eff34e415f2cR9
[15:20] <mup> PR #5151: tests: use journalctl cursors instead rotating logs <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5151>
[15:20] <cachio_> the --export fails in bionic
[15:21] <cachio_> zyga, mborzecki this is failing on bionic
[15:21] <mborzecki> cachio_: w8, what? --output=export does not work?
[15:21] <cachio_> the --export is generating a binary output
[15:21] <zyga> cachio_: so why do you need two variants? just use the simpler one without jq
[15:22] <cachio_> zyga, the shell one was not working for bionic
[15:22] <zyga> ah
[15:22] <zyga> I didn't see that
[15:22] <zyga> what was the issue with it on bionic?
[15:22] <cachio_> because on bionic it is --export generates a binary output
[15:23] <mborzecki> cachio_: --output-fields=__CURSOR --output=export ?
[15:23] <cachio_> mborzecki, let me try that
[15:23] <cachio_> I tried similat things
[15:23] <Chipaca> zyga: is there any case where you _can't_ install something with --devmode?
[15:24] <zyga> cachio_: I don't think so
[15:25] <Chipaca> zyga: was that to me
[15:25] <zyga> er, yes
[15:25] <mborzecki> cachio_: if that fails you can try grep --binary-files=text perhaps
[15:25] <zyga> sorry, distracted
[15:26] <cachio_> mborzecki, ok, let me try those alternatives
[15:27] <cachio_> mborzecki, journalctl: unrecognized option '--output-fields'
[15:28] <mborzecki> cachio_: ok, so we're left with grep --binary-files=text then
[15:28] <cachio_> journalctl: unrecognized option '--binary-files'
[15:29] <cachio_> mborzecki, this is on xenial
[15:29] <cachio_> mborzecki, main problem that I see is the compatibility of the different versions
[15:30] <cachio_> otherwise I can install jq snap durint the prepare and then skip the uninstall
[15:30] <mborzecki> cachio_: that's for grep
[15:30] <mborzecki> cachio_: --binary-files=text
[15:30] <cachio_> ah, sorry
[15:31] <mborzecki> cachio_: journalctl --output=export -n1 |grep --binary-files=text -o '__CURSOR=.*' | sed -e 's/^__CURSOR=//'
[15:33] <cachio_> mborzecki, testing on trusty and bionic
[15:35] <cachio_> mborzecki, works
[15:35] <cachio_> I'll update the PR with that
[15:35] <cachio_> thanks!!
[15:37] <mvo> Chipaca: 4600 is ready now I think
[15:40] <Chipaca> mvo: +1
[15:42]  * mvo hugs Chipaca 
[16:00] <mborzecki> pedronis: i've updated #5091
[16:00] <mup> PR #5091: many: hold refresh when on metered connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5091>
[16:04] <jdstrand> Chipaca: I am back but I would have to come back up to speed on it. is the most up to date discussion in the forum?
[16:05] <Chipaca> jdstrand: I don't think so, I'm not aware of a trail beyond https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877199
[16:05] <jdstrand> cprov (cc ratliff): fyi, I've been trying to access the public store review url for hours and only getting 504s today. not sure when the fix will be rolled out, but at this point, manual reviews are blocked
[16:06] <sparkiegeek> Chipaca, jdstrand: https://forum.snapcraft.io/t/support-for-man-pages/2299 has some more discussion
[16:07] <pedronis> mborzecki: looks good, don't know if you discussed the option name with Gustavo
[16:07] <Chipaca> sparkiegeek: you are correct, but that's AFAIK prior to the last entry in the bug report where it says it's Done
[16:08] <Chipaca> but i might be wrong on the sequencing
[16:08] <sparkiegeek> Chipaca: well, both things are threads. The Debian bug was last touched Feb 4th, and was summarised to the forum in https://forum.snapcraft.io/t/support-for-man-pages/2299/5
[16:08] <sparkiegeek> there's further discussion beyond that
[16:09] <sparkiegeek> i.e. does snapd NIH it and make 'snap man' or do we try and push MANPATH fixes
[16:10] <zyga> sparkiegeek: as a data point I was thinking about implementing a concept of "exports"
[16:10] <zyga> sparkiegeek: where a snap exports data to classic world
[16:10] <zyga> sparkiegeek: like we exports apps and services today
[16:10] <zyga> sparkiegeek: we could export man pages, images (wallpapers) themes and what not
[16:10] <sparkiegeek> zyga: right, sounds promising
[16:10] <Chipaca> sparkiegeek: jdstrand: re-reading the forum topic, maybe it's all on us at the JFDI end, i.e. it's in integrator's hands
[16:11] <Chipaca> i dunno why i thought it was otherwise, given i proposed a plan of action and gustavo +1'ed it and jdstrand +1[security]'ed it
[16:12] <zyga> sparkiegeek: I think we should do special support for man pages (however agreed) and eventually migrate it into the exports mechanism
[16:13] <Chipaca> zyga: read the forum topic :-)
[16:13] <zyga> we're on slashdot :) https://news.slashdot.org/story/18/05/15/157259/canonical-addresses-ubuntu-linux-snap-stores-security-failure
[16:13]  * zyga reads 
[16:13] <Chipaca> zyga: i think all the bits are in place, at least for bionic
[16:14] <mup> PR snapd#5163 opened: tests: build spread in the autopkgtests with a more recent go <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5163>
[16:14] <mvo> pedronis: ^- the above PR fixes autopkgtests with spread 1.6. we talked about it last week iirc that we need to do something about it
[16:14] <mvo> pedronis: (just fyi)
[16:15] <cachio_> zyga, #5151 ready
[16:15] <mup> PR #5151: tests: use journalctl cursors instead rotating logs <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5151>
[16:15] <zyga> cachio_: thank you
[16:15] <zyga> looking
[16:16] <cachio_> tx
[16:23] <mup> PR snapd#4970 closed: Add SocketUser and SocketGroup options <Blocked> <Created by guilhem> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4970>
[16:23] <zyga> cachio_: reviewed
[16:24] <Chipaca> zyga: you requested changes on #4562, i think they're done, could you check?
[16:24] <mup> PR #4562: debian: add a zenity|kdialog suggests <Reviewed> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4562>
[16:24] <Chipaca> zyga: no, wait, i got that wrong, they're not done
[16:24] <zyga> ack
[16:24] <Chipaca> at all
[16:24] <Chipaca> heh
[16:24] <zyga> heh
[16:24] <zyga> ok :)
[16:25] <zyga> the packaging changes, right?
[16:25] <Chipaca> zyga: yeah, i jumped to conclusions way too fast htere
[16:26] <Chipaca> zyga: OTOH we could totally do it in separate PRs
[16:26] <zyga> yes
[16:26] <Chipaca> no reason to block the deb work just because the rpm work isn't done
[16:26] <Chipaca> also this is _just_ for ubuntu, not even debian
[16:26] <cachio_> zyga, tx
[16:26] <Chipaca> oto²h i'm not sure debian packaging uses this
[16:26] <Chipaca> mwhudson tried to do work in this area but we kinda crapped out on him
[16:28] <mup> PR snapd#4873 closed: many: delay classic registration until first store interaction <Blocked> <Squash-merge> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/4873>
[16:29] <Chipaca> pedronis: ?
[16:47] <jdstrand> niemeyer: hi! two things: 1) perhaps I should simply submit an exporatory PR for https://forum.snapcraft.io/t/htop-snap-unable-to-signal-aa-enforced-processes/5222 implementing what I think is best? this would help kjackal/tvansteenburgh with microk8s too
[16:48] <jdstrand> niemeyer: 2) would you mind quickly looking at https://forum.snapcraft.io/t/classic-confinement-request-communitheme-set-default/5146/7 ?
[16:49] <niemeyer> jdstrand: Looking at both
[16:56] <pedronis> Chipaca: ?
[16:57] <thresh> is there a way to tell snapd not to update snaps when using certain wireless nets?
[16:57] <thresh> and/or when the connectivity is via wwan device
[16:58] <niemeyer> jdstrand: Second one sounds like the anbox installer again
[17:00] <diddledan> popey: is there a signal-desktop snap, and if there is who publishes it? there's an advisory about it so I wanted to make sure it's fixed... seclists.org/fulldisclosure/2018/May/39
[17:00] <popey> me
[17:00] <popey> i pushed a new version this morning
[17:00] <diddledan> yey
[17:00] <popey> :)
[17:00] <popey> Thanks! :D
[17:01] <diddledan> I thought it was but I'm on Windows right now so couldn't check
[17:01] <jdstrand> niemeyer: yes but with very limited scope per didrocks
[17:02] <cachio_> mvo, this is the issue I see in the pi3 https://paste.ubuntu.com/p/VCfTJVPNVr/
[17:02] <jdstrand> niemeyer: so that make it harder (for me)
[17:02] <niemeyer> jdstrand: I can't quite trace that line.. it's just a tool doing system manipulation on behalf of a third snap.. it's the sort of stuff we should be thinking about interfaces for
[17:02] <cachio_> always trying to remofe test-snapd-servoce
[17:03] <cachio_> mvo, it removes the snap but fails with timeout
[17:03] <niemeyer> jdstrand: I've asked for some further info in the topic.. let's see if we can pinpoint what the need is and whether we might offer the real snap a proper interface to do that job
[17:03] <cachio_> mvo, it failed in rgular and refresh scenarios for the pi3
[17:04] <popey> diddledan: https://snapcraft.io/signal-desktop - click "Show versions" button :)
[17:04] <jdstrand> niemeyer: it sounds like he wants to be able to modify the update-alternatives mechanism. This is a Debianism and I'm not sure what an interface for that would look like. I mean, I guess we could probe the system and expose the interface dynamically, similar to hotplug...
[17:04] <jdstrand> niemeyer: asking in the forum sounds great
[17:04] <jdstrand> niemeyer: thanks!
[17:05] <niemeyer> jdstrand: Cool, let's follow up there so the discussion isn't lost
[17:05]  * jdstrand nods
[17:06] <diddledan> yikes, popey , you're right about gimp being popular!
[17:06] <popey> ikr
[17:06] <popey> :)
[17:07] <diddledan> the adoption rate of 2.10 is impressive, too
[17:07] <thresh> are there open stats on packages popularity?
[17:07] <popey> no, but as diddledan is the uploader for gimp, he sees some stats
[17:07] <popey> same as you see for vlc
[17:08] <diddledan> is "active"
[17:08] <diddledan> err, try again
[17:08] <thresh> popey, sure that's why I asked :)
[17:08] <popey> yeah, gimp has some way to catch up with vlc :D
[17:08] <diddledan> is "active devices" the number that are actually launching the app, or just reporting metrics?
[17:09] <popey> install base, we have no idea if people run it
[17:09] <diddledan> gotcha
[17:19] <niemeyer> jdstrand: Responded to the other issue
[17:28] <zyga> jdstrand: hey
[17:28] <zyga> jdstrand: do you have a moment
[17:30] <jdstrand> zyga: if it is about the abd udev rules, I already commented
[17:30] <mborzecki> thresh: https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001 is this what's you're looking for?
[17:30] <zyga> jdstrand: it's about something else: https://github.com/snapcore/snapd/pull/5159
[17:30] <mup> PR #5159: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159>
[17:31] <zyga> jdstrand: also an ack here https://github.com/snapcore/snapd/pull/5090
[17:31] <jdstrand> zyga: what about it?
[17:31] <mup> PR #5090: cmd/snap-update-ns: poke holes when creating source paths for layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/5090>
[17:31] <zyga> I think this is doing what you asked for now
[17:31] <jdstrand> I have both of these on my todo
[17:31] <zyga> super
[17:31] <zyga> I'll resume hacking then
[17:36] <zyga> niemeyer: can you please look at https://github.com/snapcore/snapd/pull/4889 again
[17:36] <mup> PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>
[17:36] <zyga> it should be ready now and needs your re-review
[17:38] <niemeyer> zyga: Thanks for the fixed.. looking again
[17:38] <niemeyer> fixes
[17:41] <niemeyer> zyga: Can you clarify this point:
[17:41] <niemeyer>  +	// Note that we allow /var/snap instead of /var/snap/$SNAP_NAME because
[17:41] <niemeyer> zyga: What can write on /var/snap more specifically?
[17:42] <zyga> the point is that if snaps foo and bar want to content share via $SNAP_COMMON (for example)
[17:43] <zyga> then because we don't know the name of the "far side" of the connection here we cannot scope the permission to just /var/snap/foo and /var/snap/bar
[17:43] <zyga> so we allow /var/snap
[17:43] <zyga> so that content interface can create both /var/snap/foo/common/shared and /var/snap/bar/common/incoming (for example)
[17:48] <mup> PR snapd#5164 opened: tests: increase timeouts to make tests reliable on slow boards <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5164>
[17:49] <niemeyer> zyga: Where would those permissions end more specifically?
[17:50] <zyga> niemeyer: can you rephrase, are you asking about how is this used by Secure.MkDir and all kinds of other helpers?
[17:50] <zyga> those are telling snap-update-ns when to go ahead and write to the real filesystem and when to create a writable mimic and write to tmpfs instead
[17:50] <niemeyer> zyga: Is that allowance just for the inner workings of snap-update-ns?
[17:51] <zyga> yes
[17:51] <niemeyer> zyga: Where do we block the remote snap from actually putting the layout on those places?  snpad?
[17:51] <zyga> yes
[17:51] <zyga> in snap/validate.go
[17:51] <niemeyer> Ack, thanks
[18:05] <mvo> cachio_: hm, hm, it looks like the timeout is a bit too tight, could you please set the kill-timeout to 6m and re-run the test?
[18:06] <mvo> cachio_: and thanks for digging into this!
[18:06] <cachio_> mvo, I created a pr to move it to 5
[18:06] <cachio_> it is working fine with 5m
[18:07] <cachio_> mvo, #5164
[18:07] <mup> PR #5164: tests: increase timeouts to make tests reliable on slow boards <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5164>
[18:07] <mvo> cachio_: \o/
[18:08] <mvo> a second review for 5163 would be awesome
[18:08] <mvo> this is important because our current SRU is blocked on failing autopkgtests
[18:09] <cachio_> mvo, sure
[18:11] <mup> PR snapd#5163 closed: tests: build spread in the autopkgtests with a more recent go <Critical> <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5163>
[18:12] <niemeyer> zyga: Reviewed, asked some more questions
[18:12] <zyga> ack, looking
[18:13] <mvo> cachio_: do you think .8 is ready for candidate?
[18:13] <mvo> cachio_: thanks for merging 5163
[18:13] <cachio_> I am reviewing another teest and we need confirmation from cwayne
[18:13] <cachio_> mvo, our part is ok
[18:14] <mvo> cachio_: great, thank you
[18:14] <cachio_> but still waiting to see if there is an issue on caracalla
[18:14] <cwayne> cachio_: mvo said earlier he let you know we were ok to push
[18:14] <mvo> ok
[18:15] <mvo> cwayne: indeed, sorry I think I pasted wrong
[18:15] <cachio_> cwayne, ah, ok, in this case I'll promote in few minutes
[18:15] <cachio_> re-running a test in pi2
[18:15] <cwayne> ah np sorry then, thought it was taken care of :)
[18:46] <cprov> jdstrand: review pages should not timeout now, still slow, but at least you are not blocked.
[18:52] <mup> PR snapd#4805 closed: daemon: add confinement-options to /v2/system-info <Created by robert-ancell> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4805>
[18:53] <jdstrand> cprov: nice! that makes the full fix way less urgent (to me anyway)
[18:53] <jdstrand> ratliff: fyi ^
[18:54] <ratliff> jdstrand: great news, thanks cprov!
[18:56] <cprov> jdstrand, ratliff: np, sorry for the trouble the queue has grown a bit :-/
[19:02]  * cachio_ afk
[19:04] <jdstrand> cprov: yeah-- we're trying to get people to look at the gadgets and kernels too
[19:09] <Chipaca> ok, EOD for me
[19:09] <Chipaca> o/
[19:52] <mup> PR snapcraft#2138 closed: ci: resurrect codecov <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2138>
[20:10] <mup> PR snapcraft#2139 opened: ci: remove unused cron tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2139>
[20:41] <mup> PR snapd#5151 closed: tests: use journalctl cursors instead rotating logs <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5151>
[20:45] <mup> PR snapd#5146 closed: tests: fix user mounts test for external systems <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5146>
[20:45] <mup> PR snapd#5165 opened: tests: fix user mounts test for external systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5165>
[20:53] <thresh> is there a way to fetch all possible version of a snap? e.g. revisions?
[20:57] <noise][> thresh: as a publisher, you can get download links for all revisions from the snap revision pages on dashboard.snapcraft.io
[20:58] <thresh> right.  what about other snaps?
[20:58] <thresh> I'm mostly interested in trying out older core snaps
[20:59] <noise][> generally not, you can access the revisions currently in the various channels
[20:59] <thresh> I mean since some time ago I've started having issues with VLC on KDE, which I thought is due to my changes
[20:59] <thresh> but apparently (trying out the stable which didnt have issues at the time) it's not me
[20:59] <thresh> but something changed in snap/apparmor or something
[21:00] <thresh> so I wanted to bisect a bit
[21:00] <noise][> interesting, i'd suggest opening a topic on the forum - since it's the core snap you are after it shouldn't be a problem to help you get older revs
[21:01] <noise][> the restriction is in place mainly to respect publisher wishes of "what should be available" for their snaps
[21:02] <thresh> ah, undestandable
[21:05] <noise][> thresh: i'm at end of day, but post a topic and we can get someone to help out with that
[21:06] <noise][> you can @ me (noise on the forum)
[21:09] <Pharaoh_Atem> niemeyer, it's happening: https://meetbot.fedoraproject.org/fedora-meeting-1/2018-05-15/serversig.2018-05-15-19.59.html
[21:10] <niemeyer> \o/
[21:10] <niemeyer> Pharaoh_Atem: Congratulations, and thank you!
[21:11] <Pharaoh_Atem> niemeyer: this means we _gotta_ put some focus on getting things in place
[21:11] <Pharaoh_Atem> the goal is to have all this ready by Fedora 29
[21:12] <Pharaoh_Atem> zyga and I will probably submit an official self-contained change (https://fedoraproject.org/wiki/Changes/Policy) for this once we've determined the work needed
[21:22] <niemeyer> Pharaoh_Atem: Sounds great, and that aligns well with the focus of snapcraft work that we are going to have this cycle
[21:22]  * zyga mentioned that during the meeting
[21:22] <niemeyer> By the end of the cycle we want to have a very smooth  multi-base experience
[22:28] <mwhudson> a little bird tells me that snap info will start reporting the last update of a track/risk soon, is there some place i can track this?