[05:17] <mborzecki> morning
[05:44] <zyga> Good morning
[05:47] <mborzecki> zyga: hey
[05:53] <zyga> mborzecki: how are you today?
[05:56] <zyga> mborzecki: we are moving again but this time relatively very little
[05:58] <mborzecki> zyga: changing places?
[05:58] <mborzecki> zyga: it's damn hot today again
[06:00] <zyga> mborzecki: yeah, we didn't rent a single place for the whole duration of our stay
[06:00] <zyga> (which is uncertain anyway)
[06:00] <zyga> mborzecki: here we have finally some clouds
[06:01] <zyga> mborzecki: it is just 23C and very very pleasant
[06:01] <zyga> I'll check my PRs, some are close to landing
[06:04] <zyga> mborzecki: do you think this will pass?
[06:04] <zyga> https://www.irccloud.com/pastebin/bVNC8zuG/
[06:05] <mborzecki> zyga: mhm, looks good to me
[06:06] <zyga> I've replicated the case for generic ubuntu that matches apparmor, starting spread
[06:06] <zyga> let's see
[06:06] <zyga> I just noticed the grass is still wet, wow it is really cold and cloudy today
[06:07] <mborzecki> zyga: isn't that /usr/bin/sh vs /bin/sh ?
[06:07] <zyga> mborzecki: yeah, I am pretty sure that is is
[06:07] <mborzecki> zyga: at laest on fedora/centos/amzn
[06:07] <zyga> mborzecki: we have a magic thing in our spec that disables the rewrite that normally happens
[06:07] <zyga> mborzecki: which makes me think that:
[06:07] <mborzecki> zyga: oh, right
[06:07] <zyga> 1) it was always broken for hotplug
[06:07] <zyga> 2) device cgroup was not tested on those systems effectively
[06:08] <zyga> 3) after fixing this we will kill two birds with one stone
[06:08] <zyga> mborzecki: I'll check that shortly
[06:08] <zyga> but it sounds plausible to me
[06:20] <mborzecki> mvo: morning, not taking a day off?
[06:22] <zyga> mvo: hello
[06:24] <mvo> hey zyga and mborzecki !
[06:25] <zyga> how are you doing?
[06:25] <zyga> good to be home?
[06:25] <mvo> mborzecki, zyga I will be here today, want to be part of the standup, talk about the sprint and also welcome ian today
[06:25] <mborzecki> mvo: yay, ijohnson is starting today?
[06:25] <mvo> zyga: yes, very good to be home, we had a network outage over the weekend, no phone or internet, so even a forced holiday from all digital things :)
[06:25] <mvo> mborzecki: yes
[06:26] <mvo> mborzecki: I think so at least, will double check for any last minute changes :)
[06:26] <mborzecki> mvo: great to have the team grow in size :)
[06:26] <mvo> mborzecki: yeah, I'm excited too
[06:27] <mvo> mborzecki, zyga how are you ? what did I miss? sorry for not joining the standup once, it was very busy
[06:27] <zyga> mvo: relatively quiet week; some excessive iteration on the lxd fix
[06:27] <zyga> mvo: but it now has two approvals and just a few comments to tweak
[06:28] <mvo> zyga: \o/ thanks for jumping on this one
[06:28] <mvo> zyga: and you made the trip and are "settled" now?
[06:28] <zyga> mvo: haha
[06:28] <zyga> mvo: we are moving today
[06:28] <zyga> but not far
[06:28] <zyga> so ...
[06:28] <mborzecki> mvo: landed some gadget updates bits, more on reviews still, but we're closing in
[06:28] <zyga> it's not the most stable work environment ;)
[06:29] <mvo> mborzecki: yay, thanks for this
[06:30] <zyga> mvo: I have some feedback from manjaro, one small fix to a shell script to send
[06:33] <mvo> zyga: cool!
[06:40] <zyga> mborzecki: I know why that trivial udev change didn't work, fixed, let's see if it passes now
[06:47] <mborzecki> got an errand to run, bbiab
[06:56] <ackk> hi, I'm having an issue building a python C extension in a snap (actually a dependency of what I'm snapping). I have a reproducer with a minimal snap that just builds the library: http://paste.ubuntu.com/p/qmxp7rBh6Z/. the error is http://paste.ubuntu.com/p/kgwcB673qf/ am I missing something in the build configuration?
[06:58] <zyga> mborzecki: it passed, pushed now
[06:59] <zyga> ackk: looks like lack of header
[07:00] <ackk> zyga, those headers are in the library itself
[07:01] <ackk> zyga, -Iast27/Include
[07:02] <ackk> zyga, needless to say that if I create a virtualenv and pip install typed-ast --no-binary=typed-ast it works
[07:05] <zyga> ackk: but is that path OK when in snapcraft?
[07:05] <zyga> it is a relative path, not sure if that is good here
[07:05] <ackk> mhm
[07:06] <ackk> zyga right but I think it's assumed to build from the base of the package
[07:06] <zyga> I don't know, just guessing based on what the errors said
[07:06] <ackk> not sure if snapcraft does something different, but it should just call pip ?
[07:10] <zyga> mvo: https://github.com/snapcore/snapd/pull/7048 needs a 2nd review and is super simple
[07:14] <zyga> mborzecki: final remark on https://github.com/snapcore/snapd/pull/7026 -- I would like not to enforce \n on the final line. I think it is too pedantic and doesn't win us anything while actively closing the utility of the parser down the line.
[07:14] <zyga> mborzecki: I pushed remaining tweaks and intend to merge when green
[07:14] <zyga> mborzecki: if you feel strongly about the newline please indicate so
[07:14] <zyga> mborzecki: since you are on an errand now I'll wait until you return
[07:15] <mvo> zyga: thanks, checking now
[07:16] <pstolowski> mornings!
[07:16] <pstolowski> welcome back mvo!
[07:16] <mvo> pstolowski: good morning! and thank you :)
[07:16] <mvo> pstolowski: feels good to be back :)
[07:20] <zyga> mvo: thank you :)
[07:20] <zyga> hello Pawel!
[07:29] <ackk> zyga, I wonder if it has to do with the fact that snapcraft calls "pip wheel" not "pip install", or because of environ
[07:29] <zyga> I really don't know, it would be good to see if you can reproduce the failure without snapcraft involved
[07:32]  * zyga jumps at https://github.com/snapcore/snapd/pull/6891 again
[07:42] <zyga> mvo: 1-2-1 in 15 minutes, right?
[07:47] <mvo> zyga: yes
[07:47] <diddledan> ackk: seemingly works when you remove `--no-binary=typed-ast` <-- I've never seen parameters passed this way and have no idea if that is even likely to work
[07:48] <ackk> diddledan, yes, because on amd64/i386 that library is available as binary. on other arches it fails because it tries to build it. to test it I'm passing --no-binary to reproduce the issue on amd64
[07:48] <ackk> diddledan, the original issue is that if you have no binary package for that library, it fails to build. I've seen similar issues with other libraries
[08:27] <mborzecki> re
[08:33] <mborzecki> zyga: for the sake of landing this fast and since we agreed on it on friday, let's maybe stick to \n for now
[08:44] <mborzecki> zyga: interestingly the PR with udev helper still fails on opensuse https://github.com/snapcore/snapd/pull/7049#issuecomment-507173763
[08:44] <zyga> I didn't change opensuse yet
[08:46] <mborzecki> zyga: take a look at the log, it's like a lib is missing
[08:52] <pedronis> mborzecki: hi, after the fact comment,  gadget.Partition probably merits a doc comment
[08:52] <mborzecki> pedronis: ok, will add
[08:54] <pedronis> thx
[09:00] <zyga> hello pedronis
[09:00] <zyga> welcome back!
[09:06] <pstolowski> oh well, snap config stuff is fun
[09:07] <Chipaca> pstolowski: orly
[09:09] <diddledan> ackk: it looks like the failure is induced by setting `CFLAGS="-I/usr/include/python3.6"`
[09:10] <ackk> diddledan, which is set by snapcraft?
[09:11] <diddledan> yes
[09:21] <mborzecki> microk8s uses a vm to start the node?
[09:22] <diddledan> no, it runs directly
[09:30]  * zyga could use a coffee
[09:30] <pedronis> mvo: hi, we still need to publish 2.39.3 to snapd, right?
[09:34] <mvo> pedronis: checking
[09:34] <pedronis> mvo: is not even in beta afaict
[09:34] <mvo> pedronis: it only affects devices so I think we don't need to SRU it, we should make it available on GH but no need for packaging updates either
[09:34] <mvo> pedronis: let me check that
[09:36] <mvo> pedronis: oh, the snapd snap - yes, need to check with sergio but yes, that needs to go out
[09:36]  * mvo prepares beta
[09:36] <pedronis> yes, the snapd snap
[09:36] <pedronis> sorry
[09:43]  * Chipaca takes a break
[09:56] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/7049
[09:58] <mborzecki> zyga: heh, so AA blocked that
[09:58] <zyga> yeah, I'm so happy we have that distro
[10:00] <zyga> brb, taking out the garbage
[10:15] <abeato> pedronis, hey, did you see latest comment from Jamie in https://github.com/snapcore/snapd/pull/5915 ? is that a thumbs up for implementing 'snapctl netplan-apply'?
[10:21] <zyga> re
[10:30] <Chipaca> mvo, pedronis, re some of the less serious things we talked about last week I finally heard back from my archiver :-p   http://dionecanali.hd.free.fr/~mdione/nikola-gallery/galleries/GrULiC/presentacion/
[10:30] <Chipaca> check out those super high resolution photos taken with an actual digital camera omgz
[10:34] <Chipaca> hmmmm
[10:34] <Chipaca> pstolowski: for automatic snapshots I suspect having 'expires=YYYY-mm-dd' instead of 'auto' might be more useful
[10:34] <Chipaca> pedronis: WDYT?
[10:36] <mvo> Chipaca: woah, when were these pics taken?
[10:36] <pstolowski> Chipaca: oh wow, who is this guy on 3rd photo? :)
[10:36] <Chipaca> mvo: '00 iirc
[10:36] <mvo> Chipaca: amazing :)
[10:37] <Chipaca> mvo: we were very proud of our server at the time: http://dionecanali.hd.free.fr/~mdione/nikola-gallery/galleries/GrULiC/machines/pv-1/
[10:37] <Chipaca> proud mostly in that we were able to afford it, and it actually booted and ran fine as long as you held down a certain capacitor on the main hdd during boot
[10:37] <Chipaca> :-)
[10:40] <Chipaca> (also that rickety shelf was actually a controlled atmosphere because it was in the atmo lab at the uni)
[10:42]  * Chipaca still puzzled about 'snap install --verbose'
[10:43] <ogra> you should make it read the output through speakers very loudly when --verbose is set ;)
[10:43] <pedronis> Chipaca: what's the question?
[10:43] <Chipaca> https://forum.snapcraft.io/t/how-to-run-a-snap-install-verbose-in-terminal/12100?u=chipaca
[10:44] <Chipaca> ogra: xsublim, but for pulseaudio
[10:45] <pedronis> abeato: we discussed that a bit more last week, I think there is some idea to do that but let "netplan apply" call it if inside a snap
[10:46] <ogra> Chipaca, lol
[10:47] <abeato> pedronis, you mean change netplan to call the snapd API to re-start daemons if it detects it is being run inside a snap?
[10:47] <pedronis> abeato: no, to call an api that does the full apply
[10:47] <pedronis> not just restart daemons
[10:47] <pedronis> well really call snapctl, not an api
[10:47] <pedronis> as low-tech as possible, basically
[10:48] <abeato> pedronis, ah, I thought that was what 'snapctl netpla-apply' was going to do
[10:48] <abeato> so no changes there
[10:48] <pedronis> abeato: yes, but saying the snap will just call netplan
[10:49] <abeato> pedronis, so the snap will call netplan and netplan will run snapctl netplan-apply?
[10:52] <pstolowski> Chipaca: expiration instead of auto sounds fine, it would reduce the need to read expiration time again on execution of the task. a side-effect of such change is obviously the effective expiration (calculated when the task is created vs when it's executed)
[10:52] <ogra> the snap will call snapctl and netplan itself will work aotomonously is what i understand from jamies comments
[10:52] <ogra> *autonomously
[10:52] <pstolowski> Chipaca: i'm not sure if it's an issue or not, probably is fine
[10:54] <pedronis> abeato: yes, something like that
[10:55] <abeato> ok, I guess that can work too
[10:56] <abeato> ogra, the wording is slightly confusing tbh, I think he wants to make all this transparent to the netplan caller
[10:57] <ogra> yeah, true
[10:57]  * pstolowski lunch
[10:58] <Chipaca> debian 9 is buster, yes?
[11:00] <Chipaca> hm, 9 is stretch
[11:00] <zyga> Chipaca: stretch
[11:00] <Chipaca> debian has re-exec?
[11:00] <zyga> https://en.wikipedia.org/wiki/Debian#Code_names
[11:00] <zyga> Chipaca: yes it does
[11:00] <mvo> pedronis: snapd 2.39.3 is now in beta, now sergio and cert need to jump on it :)
[11:00] <ogra> streched re-exec
[11:03] <pedronis> mvo: ok
[11:05] <Chipaca> zyga, degville: fwiw https://forum.snapcraft.io/t/cannot-install-snap-store-on-debian-9/12077?u=chipaca
[11:07] <degville> Chipaca: thanks for the heads-up, looking now.
[11:07] <mvo> pedronis: also did some investigation about a higher errors.u.c failure rate with the 2.39.3 release for sil2100  but it looks mostly under control (one unknown)
[11:12] <zyga> Chipaca: aha
[11:12] <Chipaca> zyga: oho
[11:12] <Chipaca> zyga: a … gruffalo?
[11:13] <zyga> whaat? :)
[11:13] <zyga> mborzecki: pushed to https://github.com/snapcore/snapd/pull/7026
[11:14] <zyga> I think it's 100% what all the reviewers wanted now
[11:14] <Chipaca> zyga: "Aha! Oho! A trail on the snow! // Whose is this trail and where does it go?"
[11:14] <Chipaca> note you need to pronounce 'snow' to rhyme with 'oho!' or you failed
[11:14] <Chipaca> (also with 'go!' :) )
[11:15] <Chipaca> zyga: https://en.calameo.com/read/000612803e258cbf5d447
[11:19] <sil2100> mvo: phew, thanks for the investigation!
[11:22] <zyga> mvo: replied on that shell script question
[11:29] <Chipaca> man the snapd package in debian 9 is old and bad and nasty :-(
[11:29] <mvo> zyga: thx
[11:29] <Chipaca> doesn't debian have SRUs?
[11:30] <cjwatson> it's certainly possible to update packages in stable releases.  I have no idea whether it would be possible to convince the stable RMs to take a wholesale update here
[11:31] <cjwatson> like Ubuntu, somebody would have to make the case for it.  unlike Ubuntu, you wouldn't have management leverage to apply :P
[11:31] <zyga> cjwatson: FYI, flatpack updates go to backports regularly
[11:31] <zyga> I think we could consider the same path
[11:32] <cjwatson> no harm in trying though
[11:32] <zyga> though our dependency chain may be problematic
[11:33] <mvo> backports is pretty open in general for updates (iirc)
[11:34] <Chipaca> almost had a heart attack because debian's snapd doesn't include the fix for the ucrednet vuln
[11:34] <Chipaca> … then realised it's so old, it doesn't even have the vulnerability
[11:35] <cjwatson> for backports it generally just needs to be in testing
[11:35] <cjwatson> and obviously be buildable etc.
[11:41] <Chipaca> aw man, we have management leverage to apply? somebody should've told us
[11:42] <Chipaca> maybe we were missing management fulcrum
[11:42] <mvo> cachio: hey, good morning. snapd 2.39.3 snap is in beta now, please give it a go :)
[11:55] <mvo> Chipaca: did you see the comment in 7025? should be an easy win and then this one can go in
[11:59]  * Chipaca looks
[11:59] <Chipaca> mvo: that i should add a spread test?
[12:05]  * zyga is hungry, brb
[12:05] <mvo> Chipaca: yeah, we can do it in a followup as well
[12:05] <mvo> Chipaca: its actually so simple its probably quicker if I do it instead of writing it here :/ but oh well :)
[12:06] <Chipaca> mvo: doing it now
[12:06] <mvo> Chipaca: \o/
[12:06] <Chipaca> hoping to get feedback from sergio also
[12:06]  * Chipaca has poked
[12:25] <Chipaca> zyga: how's your things-i-need-to-review plate? #6695 has a half review and i was wondering if you'd be able to finish it or if i should do it
[12:26] <zyga> Chipaca: go for it!
[12:26] <zyga> I'm debugging mount propagation
[12:26] <zyga> and feeling hungry while the folks go for lunch
[12:28]  * Chipaca is having lunch
[12:30] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/7049 is green!
[12:30] <zyga> mvo: ^ this will allow to have bash snaps that don't ship /bin/sh anymore
[12:30] <zyga> base snaps, not bash snaps
[12:31] <zyga> mvo: consider it for 2.40 if you want to
[12:34]  * Chipaca implements type:bash snaps
[12:37] <ogra> Chipaca, nooo ... make it type:POSIX !!!
[12:37] <Chipaca> ogra: name:posix, type:msdos
[12:37] <ogra> lol
[12:37]  * zyga waits for amiga people to chime in
[12:38] <zyga> and for spread to spawn
[12:38] <Chipaca> ships two apps
[12:38] <Chipaca> vms
[12:38] <Chipaca> and pcm
[12:38] <Chipaca> as in pc/m, not as in /dev/pcm
[12:41] <Chipaca> pedronis: 'cp'?
[12:42] <Chipaca> > cp, ln use --target-directory in full
[12:42] <Chipaca> ah
[12:42] <Chipaca> d'oh
[12:42] <Chipaca> pedronis: until I pasted it here I thought that said In, not ln
[12:42] <pedronis> Chipaca: I'm asking whether cutting it down to just dir is good style or not
[12:42] <Chipaca> pedronis: probably not
[12:42] <pedronis> not sure myself
[12:42] <Chipaca> target-directory all over coreutils
[12:43] <pedronis> to be fair, they let you use just '-t'
[12:43] <pedronis> otoh this thing will probably be used mostly by scripts/snapcraft
[12:43] <Chipaca> yeap
[12:44] <pedronis> so not sure it needs to be short vs clean
[12:44] <Chipaca> bah
[12:44] <Chipaca> --basename, for sure
[12:44] <Chipaca> --target-dir[ectory] was just free :-)
[12:45] <Chipaca> (and neatly avoids the awkwardness of having something called 'basename' including a directory)
[12:46] <pedronis> Chipaca: otoh ubuntu-image has -w DIRECTORY, --workdir DIRECTORY
[12:46] <cachio> mvo, hey, just arrived
[12:46] <cachio> I'll start with it
[12:46] <pedronis> and -O DIRECTORY, --output-dir DIRECTORY
[12:47] <sergiusens> pedronis: Chipaca I would argue that the descriptive long option is better in scripts/code as much as using descriptive non one letter variable names :-)
[12:47] <Chipaca> --directory-dir=ectory
[12:47] <Chipaca> sergiusens: agreed
[12:48] <Chipaca> sergiusens: I don't think you're arguing against the thing :-)
[12:48] <Chipaca> --target-directory is happening
[12:48] <sergiusens> coming in late, I guess the discussion is about the best long-option to use?
[12:50] <Chipaca> sergiusens: yeah, target-dir vs target-directory mostly
[12:52] <sergiusens> Chipaca: if it helps, the positional argument you have for `pack` is `[<target-dir>]`, so if you are looking for consistency, there is your answer
[12:52] <Chipaca> dammit :-)
[12:52] <pedronis> Chipaca: our helps tend to do <*-dir>
[12:52]  * Chipaca defenestrates a rabbit
[12:53] <pedronis> those are not option names, they are placeholders really
[12:53] <pedronis> though
[12:55] <Chipaca> pedronis: I think --target-directory is the right call
[12:56] <Chipaca> pedronis: it does jump out in the options though, it's very long, but that might be ok
[12:56] <pedronis> Chipaca: we do have --ignore-validation
[12:56] <Chipaca> pedronis: <target-dir> is probably fine as a placeholder but I wouldn't mind if we went full ectory there as well
[12:57] <pedronis> as far as I can tell the only option that abbreviates (not counting --devmode which is called like that everywhere) is --abs-time
[12:57] <Chipaca> psh, the longest options are --unicode=[auto|never|always] :)
[12:58] <Chipaca> download doesn't have that one yet though
[12:58] <Chipaca> (but i expect to make --unicode and --color global at _some_ point)
[13:00]  * Chipaca stands up
[14:07] <Chipaca> pedronis: i'm about to merge the 'snap download' pr, shout if i should hold off
[15:03]  * cachio lunch
[15:41] <Chipaca> this chipaca will spontaneously EOD in T-19 minutes
[16:28] <ackk> is it ok to start services in a post-refresh hook?
[17:28] <zyga> re
[17:28]  * zyga resumes PRs
[18:02] <Chipaca> ackk: yes
[18:15] <ardaguclu> hello, what is the usage purpose of snapctl?. It is an executable and as I understand some other executable starts it. Am I right?, or I miss something.
[18:28] <ackk> Chipaca, great, thanks. it did seem to work fine, but wanted to be sure it's really intended to be used
[18:29] <ackk> ardaguclu, snapctl is used inside snap hooks to interact with the snap system (like, get configs, manage services, ...) for the snap itself
[18:32] <ardaguclu> thanks.