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