| === jaggz| is now known as jaggz | ||
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#3617 opened: Using udev tagging for snap interfaces <Created by adglkh> <https://github.com/snapcore/snapd/pull/3617> | 05:36 |
|---|---|---|
| === sdrobertw is now known as nchip | ||
| === nchip is now known as sdrobertw | ||
| didrocks | sergiusens_: kyrofa: hey, any idea what's happening on https://build.snapcraft.io/user/ubuntu/ubuntu-make/59531 ? Local build works (on artful), and the only change with latest successful build on amd64 (https://build.snapcraft.io/user/ubuntu/ubuntu-make/56636) is changing a README.md… | 06:10 |
| didrocks | sergiusens_: kyrofa: as build.snapcraft.io doesn't have a way to retrigger any build, I did a small edit on README.md, but the failure is reproducible: https://build.snapcraft.io/user/ubuntu/ubuntu-make/59842 | 06:10 |
| didrocks | cjwatson: hey, btw, do you know if there is a hidden way to retrigger a build on b.snapcraft.io? ^ | 06:10 |
| mup | PR snapd#3618 opened: Merge release/2.26 back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/3618> | 06:27 |
| mvo | stgraber: hey, I'm looking into https://forum.snapcraft.io/t/snapcraft-cannot-cleanbuild-in-snapped-lxd/1424/ right now and wonder where i can find the lxd snapcraft.yaml and the source of the snap? | 06:32 |
| mvo | pedronis: unless you think gustavo should have a look as well, I'm keen to merge 3496. sorry for the long delay with the review. | 06:43 |
| mvo | pedronis: if you could update 3560 once its in, that would be great, then the diff is smaller :) | 06:43 |
| pedronis | mvo: hi, I think it's ok to merge | 07:23 |
| * pedronis has breakfast | 07:23 | |
| mup | PR snapd#3496 closed: cmd/snap-repair: start of Runner, implement first pass of Peek and Fetch <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3496> | 07:24 |
| pedronis | I'll update the descendants after | 07:24 |
| mvo | pedronis: thank you! I can also do that I think | 07:25 |
| mvo | pedronis: but its fine, I will wait for you (enjoy breakfast) - I am in the middle of a different branch right now anyway :) | 07:25 |
| pedronis | mvo: might be better if I do it, I used rebased in at least on of them at some point, fear it might get confusing | 07:26 |
| pedronis | for me | 07:26 |
| mvo | pedronis: sounds good, thank you | 07:26 |
| pedronis | mvo: done with snapd#3560 , the later ones are based on that one | 07:43 |
| mup | PR snapd#3560: cmd/snap-repair: implement most logic to get the next repair to run/retry in a brand sequence <Created by pedronis> <https://github.com/snapcore/snapd/pull/3560> | 07:43 |
| mup | PR snapd#3616 closed: cmd/snap-repair: implement Runner.Verify and use it to check signatures of repairs from Next <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3616> | 07:54 |
| === chihchun is now known as chihchun_afk | ||
| zyga-ubuntu | good morning | 08:03 |
| * zyga-ubuntu waves from very very rainy warsaw | 08:03 | |
| zyga-ubuntu | hey Chipaca | 08:14 |
| Chipaca | zyga-ubuntu: \o! | 08:14 |
| * zyga-ubuntu is working from the quiet national library today | 08:15 | |
| Chipaca | zyga-ubuntu: i've got the ideal thing for you then! | 08:22 |
| Chipaca | zyga-ubuntu: https://www.youtube.com/watch?v=yf0Amcgxot8&t=79 | 08:22 |
| zyga-ubuntu | Chipaca: well | 08:24 |
| zyga-ubuntu | Chipaca: no sound allowed in here :) | 08:24 |
| mvo | zyga-ubuntu: hey, good morning! | 08:24 |
| mvo | Chipaca: hey, good morning! | 08:25 |
| Chipaca | zyga-ubuntu: https://www.youtube.com/watch?v=g4mHPeMGTJM :-( | 08:25 |
| Chipaca | mvo: o/! | 08:25 |
| zyga-ubuntu | Chipaca: I'll watch it back home | 08:25 |
| zyga-ubuntu | Chipaca: or at the 2nd library | 08:25 |
| * zyga-ubuntu is sad that none of the libraries actually allow you to borrow books anymore | 08:25 | |
| zyga-ubuntu | just read on site | 08:25 |
| Chipaca | zyga-ubuntu: whaat :-( | 08:26 |
| zyga-ubuntu | they should be called more appropriately | 08:26 |
| zyga-ubuntu | Chipaca: yep | 08:26 |
| Chipaca | zyga-ubuntu: that speaks badly of y'awl | 08:26 |
| zyga-ubuntu | Chipaca: both the national library and the university library | 08:26 |
| zyga-ubuntu | at least for regular mere non-PHD folks like me | 08:26 |
| Chipaca | zyga-ubuntu: wellp, time to work on your phd then | 08:26 |
| * Chipaca runs | 08:26 | |
| zyga-ubuntu | yes, just need to find a lottery ticket that lets me not work for 5 years | 08:27 |
| zyga-ubuntu | then 5 more | 08:27 |
| zyga-ubuntu | ^_^ | 08:27 |
| zyga-ubuntu | but yeah, otherwise very much what I want tod o | 08:28 |
| Chipaca | zyga-ubuntu: it's really easy, i have a 2-step plan for you | 08:31 |
| Chipaca | zyga-ubuntu: 1. be rich; 2. don't be poor | 08:31 |
| zyga-ubuntu | Chipaca: ah and you forgot one thing | 08:31 |
| zyga-ubuntu | Chipaca: 3 be young and pretty | 08:31 |
| Chipaca | zyga-ubuntu: i counted that under 'rich' | 08:32 |
| zyga-ubuntu | Chipaca: in the mean time https://github.com/snapcore/snapd/pull/3619 | 08:32 |
| mup | PR snapd#3619: interfaces/builtin: reduce duplication and remove cruft in Sanitize{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3619> | 08:32 |
| zyga-ubuntu | some gardening | 08:32 |
| zyga-ubuntu | files changed, 52 | 08:32 |
| mup | PR snapd#3619 opened: interfaces/builtin: reduce duplication and remove cruft in Sanitize{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3619> | 08:32 |
| Chipaca | zyga-ubuntu: i'll do that next then | 08:32 |
| zyga-ubuntu | but lots of red in it :) | 08:32 |
| zyga-ubuntu | just cruft lifting | 08:32 |
| zyga-ubuntu | let me go and see if the book I'm interested in is available now | 08:32 |
| mvo | Chipaca: any news on the profile.d stuff from last night? sorry for nagging | 08:39 |
| Chipaca | mvo: no :-( | 08:39 |
| mvo | Chipaca: can I help in any way, happy to poke at this too, high priority for me currently | 08:40 |
| mup | PR snapd#3616 opened: cmd/snap-repair: implement Runner.Verify and use it to check signatures of repairs from Next <Created by pedronis> <https://github.com/snapcore/snapd/pull/3616> | 08:40 |
| Chipaca | mvo: so... one thing we _could_ do | 08:41 |
| Chipaca | mvo: but makes me uncomfortable to think about too much on my own | 08:41 |
| Chipaca | mvo: is to make snap tweak the user's bashrc | 08:41 |
| pedronis | mmh | 08:42 |
| Chipaca | mvo: it could be either forwards, adding a 'source profile.sh # added by snap' line | 08:42 |
| Chipaca | mvo: ir negative, seeking out the broken 'source bash-completion' and commenting it out | 08:42 |
| zyga-ubuntu | re | 08:43 |
| Chipaca | mvo: i like 0 of these -- but it'd get the job done | 08:43 |
| zyga-ubuntu | on the upside I got the book :) | 08:43 |
| zyga-ubuntu | and I can work here all day | 08:43 |
| zyga-ubuntu | so win-win | 08:43 |
| zyga-ubuntu | (and it's quiet) | 08:43 |
| pedronis | Chipaca: sounds a strange idea (tweaking bashrc); I supose everything else is worse? | 08:44 |
| Chipaca | pedronis: more like nothing else works | 08:44 |
| Chipaca | that i could think of at least | 08:44 |
| Chipaca | but i'm an egg | 08:44 |
| pedronis | because ? | 08:44 |
| Chipaca | pedronis: there's a bug in … debian i guess? | 08:45 |
| Chipaca | pedronis: there's /etc/profile.d/bash_completion.sh | 08:45 |
| pedronis | but nothing uses it? | 08:45 |
| Chipaca | pedronis: that loads the bash completion work | 08:45 |
| Chipaca | pedronis: that gets loaded by /etc/profle, along with everything else in profile.d | 08:46 |
| Chipaca | pedronis: but then the default .bashrc, from /etc/skel, loads it _again_ | 08:46 |
| Chipaca | pedronis: our profile snipped needs to load after bash completion is loaded | 08:46 |
| Chipaca | snippet* | 08:46 |
| pedronis | I see bashrc ends up loading: /usr/share/bash-completion/bash_completion | 08:46 |
| Chipaca | yes | 08:47 |
| Chipaca | so, there's a number of ways that we can make it work | 08:47 |
| Chipaca | if we patch bash-completion itself | 08:47 |
| zyga-ubuntu | Chipaca: step 1: fix debial stable | 08:47 |
| zyga-ubuntu | Chipaca: ^_^ | 08:48 |
| Chipaca | but if we can't do that, then we're stuck | 08:48 |
| zyga-ubuntu | but at least you can hope to fix that ;) | 08:48 |
| Chipaca | zyga-ubuntu: aw bless | 08:48 |
| Chipaca | the easiest way to fix bash completion is to make it not load the default completer if there is one already | 08:48 |
| zyga-ubuntu | Chipaca: one more, this time fully red: https://github.com/snapcore/snapd/pull/3620 | 08:49 |
| mup | PR snapd#3620: interfaces/builtin: discard empty Validate{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3620> | 08:49 |
| mup | PR snapd#3620 opened: interfaces/builtin: discard empty Validate{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3620> | 08:50 |
| pedronis | Chipaca: fwiw it seems to source stuff from /etc/bash_completion.d but as back compat thing | 08:51 |
| Chipaca | pedronis: yes | 08:51 |
| pedronis | and then ~/.bash_completion | 08:52 |
| zyga-ubuntu | mvo: did you see latest comments on https://bugs.launchpad.net/snappy/+bug/1674193 | 08:56 |
| mup | Bug #1674193: core snap's configuration hangs on debian | openSUSE | mainline kernel <Snappy:Fix Committed by morphis> <snapd (Debian):Fix Committed> <snapd (Fedora):Fix Committed by morphis> <snapd (openSUSE):Fix Released by morphis> <https://launchpad.net/bugs/1674193> | 08:56 |
| zyga-ubuntu | mvo: I fail to see how that is possible since that is exactly what was fixed last week | 08:56 |
| mvo | Chipaca: modifying the users .bashrc makes me uneasy. the other thing is that is tricky is when/how do we do it? iterate over all users? do it in snap run (which is too late)? other? | 08:57 |
| mvo | zyga-ubuntu: looking | 08:57 |
| Chipaca | mvo: thank you | 08:57 |
| mvo | Chipaca: sorry :/ | 08:57 |
| Chipaca | mvo: no, really thank you :-) | 08:57 |
| Chipaca | mvo: easiest way to kill something that makes me uneasy to think about doing is by pointing out it wouldn't work :-) | 08:58 |
| zyga-ubuntu | mvo: unless we are missing something and people start with not-up-to-date debian 9 | 08:58 |
| mvo | Chipaca: heh :) | 08:59 |
| mvo | zyga-ubuntu: yeah, its very confusing, I download an image now | 08:59 |
| pedronis | Chipaca: so we need to ship a different bash_completion ? with some bits added? | 09:03 |
| mvo | zyga-ubuntu: aha, I think I know what is happening there. on undo we will not restart into the old snapd. so I guess what happend is: snapd-2.21 refreshes, restarts into 2.26.14, something fails (configure hook?), things are undone. snapd 2.26.14 keeps running, however there is no 2.26.14 snap anymore. | 09:11 |
| zyga-ubuntu | mvo: oh | 09:12 |
| zyga-ubuntu | mvo: did you manage to reproduce it? | 09:12 |
| zyga-ubuntu | mvo: and didn't we ignore configure hook on core errors? | 09:12 |
| mvo | zyga-ubuntu: strange enough - I got a configure hang on debina9 though, then it fails with cannot stat /var/lib/snapd/seccomp: no such file or directory | 09:13 |
| zyga-ubuntu | (errors in the configure hook when running on the core snap) | 09:13 |
| mvo | zyga-ubuntu: yes, we ignore those I suspect the issue is that it starts from 2.21 but I need to double check | 09:14 |
| cjwatson | didrocks: there is not | 09:14 |
| mvo | zyga-ubuntu: ok, this is confusing - the configure hook (snap-confine to be precise) is waiting for /var/lib/snapd/seccomp/bpf/snap.core.hook.configure.bin to show up. it *does* show up in the host, however strace shows me that snap-confine (the configure hook) is not seeing this. we are not doing any namespace stuff on debian, right? so why would it not see it? | 09:24 |
| zyga-ubuntu | mvo: we do namespace stuff on debian just the same but I believe we read the bpf parts before that *and* even if I'm wrong /var/lib/snapd is shared with the host | 09:25 |
| zyga-ubuntu | mvo: there's systemd in your system, right/ | 09:25 |
| mvo | zyga-ubuntu: let me check, this is a stock skretch install | 09:27 |
| mvo | zyga-ubuntu: yes, systemd is there | 09:27 |
| zyga-ubuntu | hmm mhm | 09:28 |
| zyga-ubuntu | magic | 09:28 |
| zyga-ubuntu | and why didn't it ever happen in spread? | 09:28 |
| mvo | zyga-ubuntu: spread uses sid, right ? maybe its rleated to stretch | 09:29 |
| mvo | zyga-ubuntu: anyway, puzzling | 09:29 |
| mvo | zyga-ubuntu: what was the nsenter magic again to get inside the env of the core configure hook? | 09:29 |
| zyga-ubuntu | mvo: I think spread uses sid, yes | 09:29 |
| zyga-ubuntu | mvo: but spread qemu is stretch | 09:29 |
| zyga-ubuntu | mvo: nsenter -m/run/snapd/ns/core.mnt | 09:30 |
| mvo | zyga-ubuntu: /var/lib/snapd is empty in there | 09:30 |
| mvo | zyga-ubuntu: like completely empty | 09:31 |
| mvo | zyga-ubuntu: but mount claims /var/lib/snapd is mounted (type ext4 etc) | 09:31 |
| zyga-ubuntu | mvo: can you pastebin /proc/self/mountinfo | 09:32 |
| zyga-ubuntu | (from that namespace) | 09:32 |
| zyga-ubuntu | and from outside | 09:32 |
| mvo | zyga-ubuntu: mountinfo says /var/lib/snapd//detleted /var/lib/snapd | 09:32 |
| zyga-ubuntu | and pastebin both to the forum | 09:32 |
| zyga-ubuntu | oh | 09:32 |
| zyga-ubuntu | cute!?! (not) | 09:32 |
| zyga-ubuntu | anyway, let's do this in the forum | 09:32 |
| zyga-ubuntu | very interesting I must say | 09:32 |
| mvo | zyga-ubuntu: created the topic now | 09:39 |
| * zyga-ubuntu looks | 09:41 | |
| zyga-ubuntu | mvo: did you pure snapd at any time? | 09:42 |
| zyga-ubuntu | mvo: maybe what happened is that the core.mnt namespace sticks around | 09:42 |
| zyga-ubuntu | you purge snapd | 09:42 |
| zyga-ubuntu | and re-install | 09:43 |
| zyga-ubuntu | and we use a stale core.mnt file | 09:43 |
| zyga-ubuntu | (hence //deleted) | 09:43 |
| zyga-ubuntu | do a quick test please | 09:43 |
| zyga-ubuntu | unmount /run/snapd/ns/core.mnt | 09:43 |
| zyga-ubuntu | and install core again | 09:43 |
| mvo | zyga-ubuntu: sure, one sec | 09:44 |
| * zyga-ubuntu found the power plug and is happy not to live on a ticking clock anymore | 09:44 | |
| zyga-ubuntu | but whatever it is, my fix for stale mount namespace needs to include //deleted checks | 09:44 |
| zyga-ubuntu | mvo: any luck with unmounted core.mnt? | 09:50 |
| mvo | zyga-ubuntu: I was just trying to reproduce it again | 09:50 |
| mvo | zyga-ubuntu: I did reboot into a different kernel for testing in the meantime | 09:51 |
| mvo | zyga-ubuntu: hrm, hrm, now I cannot reproduce it anymore, even when I purge snapd | 09:51 |
| zyga-ubuntu | mvo: replied | 09:52 |
| zyga-ubuntu | mvo: run conifugre hook, purge, run configure hook | 09:52 |
| pedronis | Chipaca: naming is hard(tm) | 09:55 |
| mvo | zyga-ubuntu: did this now, not breaking | 09:55 |
| Chipaca | (╯°□°）╯︵ ┻━┻ | 09:55 |
| zyga-ubuntu | mvo: I must say it is interesting how many edges we found to be rough over the months/year | 09:55 |
| zyga-ubuntu | Chipaca: huh? | 09:55 |
| mvo | zyga-ubuntu: yes, the re-exec thing from arbitrary starting points makes things complicated | 09:56 |
| Chipaca | zyga-ubuntu: that was to pedronis :-) | 09:56 |
| Chipaca | ┬─┬ ノ( ゜-゜ノ) sorry | 09:56 |
| * zyga-ubuntu wonders how many other fantastic emjoji we'd have if the table could include a teapot or a plant | 09:57 | |
| Chipaca | zyga-ubuntu: ┬─┬⃰͡ (ᵔᵕᵔ͜ ) | 09:58 |
| Chipaca | zyga-ubuntu: it's just too small for your eyes to see | 09:58 |
| zyga-ubuntu | hahah | 09:59 |
| zyga-ubuntu | nice :) | 09:59 |
| zyga-ubuntu | mvo: can you use snapshots in your vm? | 09:59 |
| zyga-ubuntu | mvo: maybe start with a pristine image, snapshot that | 09:59 |
| zyga-ubuntu | mvo: install snapd, snapshot that (separately) | 09:59 |
| zyga-ubuntu | mvo: and try to get into the problem | 09:59 |
| zyga-ubuntu | mvo: then whatever you have can be inspected forever | 09:59 |
| mvo | zyga-ubuntu: yeah, too late now, whatever I did I did not snapshot :( | 09:59 |
| mvo | zyga-ubuntu: and can not get back into currently | 10:00 |
| zyga-ubuntu | mvo: since now you said purging doesn't make it broken I wonder if that shoots my hypothesis | 10:00 |
| mvo | zyga-ubuntu: like - now it is working | 10:00 |
| mvo | zyga-ubuntu: I think your hypothesis is good, maybe it was not a purge, maybe it was something else (an upgrade?) | 10:00 |
| mvo | zyga-ubuntu: I took a somewhat old VM, apt full-upgraded, dpkg --purge snapd (because it had core already); snap install --edge core; BOOM | 10:01 |
| zyga-ubuntu | mvo: do we remove /run/snapd/ns on purge? | 10:01 |
| zyga-ubuntu | if we do then purge is not the thing | 10:01 |
| zyga-ubuntu | because that thing cannot be stale when it is gone | 10:01 |
| mvo | zyga-ubuntu: we do umount /run7snapd/ns on purge | 10:02 |
| zyga-ubuntu | mvo: in that case it must have been something else | 10:03 |
| zyga-ubuntu | mvo: is dpkg doing some fancy things when it updates packages? any directory changes? | 10:03 |
| zyga-ubuntu | mvo: did the apt-get --dist-upgrade include snapd? | 10:04 |
| pedronis | mvo: when did we start to do that though? (unmount /run/snapd/ns in purge? ) | 10:07 |
| mvo | pedronis: I see message related to it on my debian box, I need to check when exactly we started doing that | 10:09 |
| mvo | zyga-ubuntu: yes, snapd was upgraded 2.21-2, 2.21-2+b1 | 10:10 |
| mvo | zyga-ubuntu: /me tries to reproduce using upgrade | 10:10 |
| zyga-ubuntu | mvo: aha, interesting | 10:11 |
| zyga-ubuntu | mvo: I doubt dpkg would do something that would cause the package update to remove a directory like /var/lib/snapd though | 10:11 |
| zyga-ubuntu | mvo: but if you can try the 2.21-2 -> 2.21-2+b1 update again | 10:11 |
| zyga-ubuntu | that would be a useful data point | 10:11 |
| zyga-ubuntu | I recall that //deleted shows up when the backing store goes away | 10:12 |
| zyga-ubuntu | I moved my kernel sources to my desktop so I cannot cross reference locally, let me check something online | 10:12 |
| mvo | zyga-ubuntu: hrm, hrm, upgrade, purge, install, upgrade, no boom, just works | 10:14 |
| zyga-ubuntu | mvo: http://elixir.free-electrons.com/linux/latest/source/fs/dcache.c#L3363 and http://elixir.free-electrons.com/linux/latest/source/fs/proc_namespace.c#L130 | 10:19 |
| === sergiusens_ is now known as sergiusens | ||
| ogra_ | cjwatson, did anything change with the builders last night ? all (except s390x it seems) my daily builds of the core snap suddenly fail with: | 10:34 |
| ogra_ | P: Begin bootstrapping system... | 10:34 |
| ogra_ | [2017-07-25 04:17:00] lb_testroot | 10:34 |
| ogra_ | E: need root privileges | 10:34 |
| ogra_ | P: Begin unmounting filesystems... | 10:34 |
| ogra_ | P: Saving caches... | 10:34 |
| ogra_ | chroot: cannot change root directory to 'chroot': No such file or directory | 10:34 |
| ogra_ | cjwatson, https://launchpad.net/~snappy-dev/+snap/core for details | 10:34 |
| cjwatson | ogra_: fix for https://bugs.launchpad.net/launchpad-buildd/+bug/1702656 was (mostly) rolled out | 10:35 |
| mup | Bug #1702656: Run snapcraft as non-root (with passwordless sudo) <launchpad-buildd:Fix Committed by cjwatson> <https://launchpad.net/bugs/1702656> | 10:35 |
| ogra_ | cjwatson, ah, thanks | 10:35 |
| cjwatson | ogra_: can you just run with sudo? | 10:35 |
| ogra_ | cjwatson, is that configured passwordless in the buildd ? | 10:38 |
| cjwatson | ogra_: yes | 10:39 |
| mvo | zyga-ubuntu: thanks, I give up on this for now and have lunch. slightly frustrating | 10:40 |
| cjwatson | ogra_: I think just changing "ENV := PROJECT=ubuntu-core ..." to "ENV := sudo PROJECT=ubuntu-core ..." would do the trick | 10:40 |
| cjwatson | Maybe with SUDO := sudo and $(SUDO) if you want a bit of extra configurability | 10:40 |
| ogra_ | thanks! will add that | 10:41 |
| ogra_ | (though it might need more, the check and install targets in the makefile touch the chroot as well) | 10:42 |
| zyga-ubuntu | mvo: I'll check it myself back home | 10:42 |
| zyga-ubuntu | mvo: one interesting fact is that snap-confine (which may run in classic snap environment) now needs to run snap-update-ns | 10:42 |
| zyga-ubuntu | mvo: so if the rabbit hole wasn't deep enough I just brough a new shovel | 10:42 |
| zyga-ubuntu | (now as in litterally right now on my disk in a new branch) | 10:42 |
| niemeyer | Hello all | 10:52 |
| zyga-ubuntu | niemeyer: o/ | 10:52 |
| cjwatson | ogra_: ah, right, yeah | 10:53 |
| cjwatson | ogra_: would appreciate confirmation when you get a result, as we ought to do manual upgrades of s390x | 10:53 |
| ogra_ | cjwatson, will let you know | 10:53 |
| cjwatson | ta | 10:54 |
| Chipaca | mvo: i have good news: on fedora 25 the profile.d approach would work | 10:54 |
| mup | PR core#51 opened: use sudo to work around LP: #1702656 <Created by ogra1> <https://github.com/snapcore/core/pull/51> | 11:08 |
| ogra_ | mvo, zyga-ubuntu ^^^^ can i get two acks to actually test-build in the LP buildd | 11:19 |
| ogra_ | (travis passes fine but wont help since the LP env is different now) | 11:19 |
| zyga-ubuntu | yep | 11:26 |
| zyga-ubuntu | ogra_: +1 | 11:26 |
| ogra_ | thx | 11:26 |
| mvo | ogra_: yes, go for it | 11:27 |
| mvo | Chipaca: oh, nice. what is the difference? | 11:27 |
| ogra_ | thanks ! | 11:27 |
| mup | PR core#51 closed: use sudo to work around LP: #1702656 <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core/pull/51> | 11:27 |
| * ogra_ triggers test builds and crosses fingers that he catched all occurences | 11:28 | |
| cjwatson | ogra_: sorry for the disruption, I test-built various things but totally forgot about core being a special snowflake | 11:28 |
| mup | PR snapd#3618 closed: Merge release/2.26 back into master <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3618> | 11:28 |
| cjwatson | I think it's long-term better this way | 11:28 |
| ogra_ | cjwatson, well there is more in my set of snaps that uses chroots in chroots etc ... but now that i know about it i can adapt ... no prob | 11:29 |
| ogra_ | ppisati, ^^^ you might need to look into this too for the kernel snap builds (adding sudo to the commands that actually require root ... like the chroot and debootstrap commands in the Makefile) | 11:31 |
| ogra_ | grrr ... forgot to sync Gh to LP before hitting the build button ... | 11:37 |
| ogra_ | bah ... needs more sudo it seems | 11:43 |
| ogra_ | rm -f config/hooks/* | 11:43 |
| ogra_ | rm: cannot remove 'config/hooks/00-uid-gid-fix.chroot_early': Permission denied | 11:43 |
| ogra_ | rm: cannot remove 'config/hooks/01-divert-grub-install.chroot_early': Permission denied | 11:43 |
| ogra_ | rm: cannot remove 'config/hooks/01-setup_user.chroot': Permission denied | 11:43 |
| ogra_ | ... | 11:43 |
| ogra_ | funny, i wouldnt have expected that to be root owned | 11:44 |
| ogra_ | (given the unprivileged snapcraft did put it in place originally) | 11:44 |
| mup | PR core#52 opened: also use sudo for all file operations <Created by ogra1> <https://github.com/snapcore/core/pull/52> | 11:49 |
| ogra_ | mvo, zyga-ubuntu ^^^^ one more please | 11:50 |
| ogra_ | (it should be fine then) | 11:51 |
| zyga-ubuntu | ogra_: looking | 11:51 |
| zyga-ubuntu | ogra_: done | 11:51 |
| ogra_ | thx | 11:51 |
| mvo | +1 | 11:51 |
| * ogra_ waits for travis ... | 11:52 | |
| Chipaca | mvo: they don't do bash completion in .bashrc :-) | 11:53 |
| Chipaca | mvo: they just have the /etc/profile.d/bash_completion.sh | 11:53 |
| niemeyer | Chipaca: More comments on snapd#3614.. let me know if you'd like to talk about those | 11:54 |
| mup | PR snapd#3614: daemon, client, cmd/snap: implement "snap status" <Created by chipaca> <https://github.com/snapcore/snapd/pull/3614> | 11:54 |
| Chipaca | niemeyer: i've seen them come in, yes | 11:54 |
| Chipaca | i'm beyond the point of talking about this stuff. I'll just do whatever you say. | 11:54 |
| mvo | Chipaca: aha, nice | 11:55 |
| niemeyer | Chipaca: Okay, so let's keep that in the PR queue until you're ready to talk about it again | 11:55 |
| Chipaca | niemeyer: i've been working on this same bit of functionality for over a month, i'm ready to be done with it | 11:56 |
| niemeyer | Chipaca: Or somebody else is.. we need someone that is willing to think through the points made so we can have a shared idea of the problem | 11:56 |
| mup | PR snapd#3621 opened: cmd/snap-{confine,update-ns}: apply mount proifles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621> | 11:57 |
| zyga-ubuntu | first WIP branch on snap-update-ns/snap-confine and layouts | 11:57 |
| zyga-ubuntu | ignore it for now, I mainly pushed it to see if tests pass and discuss something with jdstrand later | 11:57 |
| niemeyer | Chipaca: In fairness, many of the points I made are exactly the same as a month ago | 11:57 |
| Chipaca | i'm going to go have lunch | 11:58 |
| niemeyer | Nice.. | 11:58 |
| zyga-ubuntu | I'm past starving now, so I can spend some time to collect notes and then have a call with everyone | 11:58 |
| niemeyer | zyga-ubuntu: Tests are broken on snapd#3620 | 11:59 |
| mup | PR snapd#3620: interfaces/builtin: discard empty Validate{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3620> | 11:59 |
| mup | PR core#52 closed: also use sudo for all file operations <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core/pull/52> | 12:01 |
| niemeyer | cachio: In #3604, why is it increasing the number of workers? | 12:02 |
| niemeyer | mvo: Can you have a look at snapd#3604 when you have a moment, specifically on the #cgo statement on snap-seccomp, to see if it looks okay considering the issues we know about | 12:03 |
| mup | PR snapd#3604: tests: enable main suite for opensuse <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3604> | 12:03 |
| zyga-ubuntu | niemeyer: oh, thanks | 12:04 |
| zyga-ubuntu | cachio, fgimenez: random error on interface-cups-control: https://travis-ci.org/snapcore/snapd/builds/257218359?utm_source=github_status&utm_medium=notification | 12:11 |
| zyga-ubuntu | sorry, interfaces-cups-control | 12:11 |
| zyga-ubuntu | let me know if you want to collect the long | 12:11 |
| zyga-ubuntu | *log | 12:11 |
| zyga-ubuntu | and if not I'll re-trigger this | 12:11 |
| zyga-ubuntu | "Error - scheduler not responding" | 12:12 |
| ogra_ | cjwatson, ... hmm the build succeeds, but the staging step in snapcraft falls over when it tries to make use of the resulting dir ... https://launchpad.net/~snappy-dev/+snap/core/+build/59965/+files/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz | 12:13 |
| ogra_ | (since it is all root owned ... ) | 12:13 |
| fgimenez | zyga-ubuntu: thanks! indeed, lpr scheduler not working, have you seen it on other archs? | 12:17 |
| zyga-ubuntu | nope, first time I saw this | 12:19 |
| zyga-ubuntu | and I suspsect it's not related to the PR | 12:19 |
| zyga-ubuntu | fgimenez: btw, I noticed that we have a disparity in debian testing | 12:19 |
| zyga-ubuntu | fgimenez: the qemu image tests debian 9 | 12:19 |
| ogra_ | cjwatson, snapcraft itself would have to run the staging step under sudo, i dont think i can do anything on the snap side for this ... :/ | 12:19 |
| zyga-ubuntu | fgimenez: but the linode machine tracks sid | 12:19 |
| zyga-ubuntu | fgimenez: we should keep those separate as sid is moving | 12:20 |
| ogra_ | cjwatson, couldnt you make the sudo behaviour conditional based on the snap type in snapcraft.yaml so that "type: os" and "type: kernel" simple keep the old behaviour ? | 12:21 |
| ogra_ | *simply | 12:21 |
| ogra_ | (and run the build as root) | 12:21 |
| niemeyer | snapd#3568 has a review.. any takes for the second review? | 12:31 |
| mup | PR snapd#3568: snapctl: add new `snapctl internal configure-core` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3568> | 12:31 |
| zyga-ubuntu | niemeyer: I can do that after standup, on my way to find anything edible that doens't run away | 12:33 |
| niemeyer | zyga-ubuntu: Thanks! | 12:34 |
| niemeyer | zyga-ubuntu: and good luck :) | 12:34 |
| cjwatson | ogra_: Hmm. Ugly, but I guess we may have no alternative. | 12:37 |
| sergiusens | niemeyer: mvo I've been pinged about https://bugs.launchpad.net/juju/+bug/1705988 (error is -> run hook "configure": cannot change profile for the next exec call: No such file or directory) | 12:37 |
| mup | Bug #1705988: snap install --classic juju fails <canonical-is> <juju:Incomplete> <snapd:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1705988> | 12:37 |
| cjwatson | ogra_: What about gadget? | 12:39 |
| ogra_ | cjwatson, usually doesnt need root | 12:39 |
| cjwatson | ogra_: It'd mean we have to start parsing snapcraft.yaml directly in launchpad-buildd, which has previously been unnecessary. | 12:39 |
| Chipaca | niemeyer: 'm back from lunch. Less grumpy now. | 12:39 |
| Chipaca | niemeyer: let me rephrase what I said: I think you're right on most of the points, and on the points I don't, I haven't been able to convince you otherwise. I'll be implementing your suggestions as I understand them, and we can iterate. | 12:40 |
| niemeyer | Chipaca: Thank you! | 12:40 |
| ogra_ | cjwatson, yeah ... understood ... os has always been special though ... since you have a full root that includes /dev and all ... not sure if there is any way to do it differently ... | 12:41 |
| niemeyer | Chipaca: You'll also see some self-conflict on the comments.. which means I'm also trying to figure that stuff out | 12:41 |
| cjwatson | ogra_: I'm inclined to just revert this launchpad-buildd change for now. | 12:41 |
| ogra_ | i'm fine with that as well ... :) | 12:41 |
| pedronis | mvo: you already branched 2.27 a while ago right? you will not take a new snapshot? | 12:41 |
| cjwatson | ev probably won't be, but such is life ... | 12:41 |
| ogra_ | cjwatson, doesnt lp-buildd actually call snapcraft step-wise ? (i.e. not plain snapcraft but each step) | 12:42 |
| cjwatson | ogra_: Only in that it calls pull separately. | 12:42 |
| ogra_ | cjwatson, then "snapcraft stage" could simply always run as root while all other steps keep the dropped privs | 12:42 |
| ogra_ | ah, k ... | 12:43 |
| cjwatson | ogra_: Yeah, that's one viable option for the future. I think it requires more testing than I want to put into a "stop the bleeding" change, though. | 12:43 |
| ogra_ | yeah | 12:43 |
| cjwatson | ogra_: I'll update the bug with some ideas once I've reverted. | 12:43 |
| ogra_ | snapcraft snap would likely also fall over on the /dev permissions | 12:44 |
| ogra_ | so it'd be more | 12:44 |
| ogra_ | cjwatson, can you keep the passwordless sudo in though ? ten i dont need to change core back :) | 12:45 |
| ogra_ | *then | 12:45 |
| cjwatson | ogra_: sudo should be fine if it's already running as root. | 12:45 |
| cjwatson | ogra_: I don't think you'll need to change core back. | 12:46 |
| ogra_ | oh, indeed, i call it as root | 12:47 |
| mvo | pedronis: anything specially you want to see in 2.27, I would like to start of rc3 (mostly to avoid too much churn, we already have a ton) | 12:51 |
| pedronis | mvo: no, I misread some code, what I was interested in, is already there, sorry for the bother | 12:51 |
| mvo | pedronis: no problem | 12:52 |
| * Chipaca reads https://medium.com/@Raedwulf/6-go-tips-you-should-probably-not-use-b252dfd0a3c4 and laughs maniacally | 12:54 | |
| Chipaca | exhibit A: https://github.com/bouk/monkey | 12:54 |
| Son_Goku | morning | 12:55 |
| didrocks | Chipaca: excellent! :) | 12:57 |
| * didrocks goes and rewrite code right away | 12:58 | |
| zyga-ubuntu | ooops | 13:01 |
| zyga-ubuntu | niemeyer: start without me please | 13:01 |
| zyga-ubuntu | niemeyer: I'm still stuck in the library :/ | 13:01 |
| zyga-ubuntu | lost track of time | 13:01 |
| zyga-ubuntu | niemeyer: my update for today is: pushed inital work towards layouts that moves late initialization to snap-update-ns | 13:02 |
| zyga-ubuntu | niemeyer: pushed some cleanups to interfaces | 13:02 |
| zyga-ubuntu | niemeyer: plan for the day: re-assemble my fedora box and fix fedora i386 build back home | 13:02 |
| zyga-ubuntu | niemeyer: and eat something | 13:02 |
| * zyga-ubuntu is still starving | 13:02 | |
| zyga-ubuntu | niemeyer: next up: chipaca | 13:03 |
| zyga-ubuntu | :D | 13:03 |
| Son_Goku | you're going to eat Chipaca? | 13:06 |
| Son_Goku | what did he ever do to you? | 13:06 |
| zyga-ubuntu | with all due respect I think Chipaca doesn't work as a sushi | 13:06 |
| niemeyer | zyga-ubuntu: Can you leave fedora to cachio, so you can focus on layouts and open PRs? | 13:07 |
| zyga-ubuntu | niemeyer: I'll try that #define _FILE_OFFSET_BITS 64 and if that doesn't work I'll give that to cachio | 13:10 |
| niemeyer | zyga-ubuntu: +1 | 13:11 |
| zyga-ubuntu | Son_Goku: https://fedoraproject.org/wiki/Changes/Platform_Python_Stack is pretty interesting | 13:17 |
| * Son_Goku reads | 13:25 | |
| Son_Goku | oh boy | 13:25 |
| Son_Goku | the issue I see right up front is how do we handle upgrading the platform python stack? | 13:25 |
| Son_Goku | the reason we can do it without breaking the world in Python is because all the paths are versioned, including the interpreter itself | 13:25 |
| zyga-ubuntu | Son_Goku: it seems like "in one big swoop during offline update" is the answer | 13:26 |
| zyga-ubuntu | Son_Goku: and one big swoop says that *all* the packages follow | 13:26 |
| Son_Goku | yeah | 13:26 |
| zyga-ubuntu | Son_Goku: another answer is, not to | 13:26 |
| Son_Goku | right, but that's dumb | 13:26 |
| zyga-ubuntu | Son_Goku: as the platfrom python can say on 3.6 for decades | 13:26 |
| zyga-ubuntu | Son_Goku: yes but it is also valid | 13:26 |
| cjwatson | ogra_: https://portal.admin.canonical.com/104572 FYI | 13:27 |
| Son_Goku | from a maint point of view, especially since sensitive tools would depend on it, it'd be very stupid | 13:27 |
| zyga-ubuntu | s/decates/across Fx -> F(x+1) updates | 13:27 |
| zyga-ubuntu | Son_Goku: well, it can stay on patched 3.6 for a long time with no issues | 13:27 |
| Son_Goku | sure | 13:27 |
| zyga-ubuntu | Son_Goku: backport any relevant patches but otherwise leave it be | 13:27 |
| Son_Goku | yes, but at that point, why not just use micropython or something else actively maintained but fixed to specific lang version? | 13:28 |
| zyga-ubuntu | Son_Goku: what it says is that new fedora and old fedora can share tooling easily (ish)) | 13:28 |
| Son_Goku | sure | 13:28 |
| ppisati | ogra_: got it, ta | 13:28 |
| zyga-ubuntu | Son_Goku: not sure if this is designed so that F27 can download F28 update tool | 13:28 |
| Son_Goku | and that's what I'm concerned about | 13:28 |
| Son_Goku | I'm not sure that is particularly addressed | 13:28 |
| zyga-ubuntu | Son_Goku: but anyway, I found it interesting because traditionally it was not the case on any linux-based platfomr | 13:28 |
| zyga-ubuntu | Son_Goku: *platfomr | 13:28 |
| zyga-ubuntu | boy | 13:28 |
| zyga-ubuntu | *platform | 13:29 |
| zyga-ubuntu | Son_Goku: but it is the case on macos | 13:29 |
| pedronis | niemeyer: as I mentioned, it would be good to get some initial feedback on snapd#3573 , seems it was also a topic last week | 13:29 |
| mup | PR snapd#3573: overlord: always try to get a serial, be lazy on classic with no special store, nor any snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/3573> | 13:29 |
| Son_Goku | zyga-ubuntu, yes, historically it's that way on macos, but when mac bumps the stack, applications get broken | 13:30 |
| Son_Goku | Apple literally does not care | 13:30 |
| zyga-ubuntu | Son_Goku: indeed | 13:30 |
| zyga-ubuntu | Son_Goku: though AFAIR the upstream python installers for mac are installing a separate copy | 13:31 |
| Son_Goku | yes | 13:31 |
| Son_Goku | but most people don't do that | 13:31 |
| zyga-ubuntu | Son_Goku: I'll look forward to platform-{shell,perl,awk,sed,...} next ;) | 13:31 |
| Son_Goku | that would be dumb | 13:31 |
| zyga-ubuntu | well | 13:31 |
| Son_Goku | we'll probably have a platform perl | 13:31 |
| zyga-ubuntu | more or just the same? | 13:31 |
| Son_Goku | but shell/awk/sed etc are already specified as part of the core platform | 13:32 |
| Son_Goku | zyga-ubuntu: https://github.com/fedora-modularity/hp | 13:32 |
| === LarreaMikel1 is now known as LarreaMikel | ||
| mvo | niemeyer: we talked about the "empty" base snap - is the name "empty-base" good? or would you prefer something else? I want to upload one to the store now for easier testing/validation | 14:08 |
| niemeyer | mvo: Hmm | 14:10 |
| niemeyer | mvo: How about "bare"? | 14:12 |
| zyga-ubuntu | mvo: note that we're not quite ready to work in an empty base, unless empty actually has stuff inside :) | 14:13 |
| mvo | zyga-ubuntu: well, I want to have it so that we can make it ready :) | 14:14 |
| mvo | niemeyer: bare works for me | 14:14 |
| zyga-ubuntu | mvo: understood | 14:14 |
| niemeyer | mvo: It might not end up completely empty in the end.. we might want at least the mount points for /dev, /proc, /sys, ... | 14:15 |
| zyga-ubuntu | right | 14:15 |
| zyga-ubuntu | with a few of those it should soon work OK | 14:15 |
| zyga-ubuntu | I need to introduce a few more small changes to make certain things non-fatal | 14:16 |
| mvo | ok, "bare" it is and I created a bunch of stub dirs, lets see how this goes | 14:16 |
| Chipaca | mvo: aw, am i too late to suggest calling it "classic-core"? | 14:19 |
| zyga-ubuntu | Chipaca: uncore ;) | 14:31 |
| * zyga-ubuntu cannot wait for busybox core | 14:31 | |
| zyga-ubuntu | in fact, I may just make one | 14:31 |
| ogra_ | cjwatson, hmm, looks like the revert only landed in amd64, the other arches still have the former code | 14:32 |
| zyga-ubuntu | it would be cool if we could have a base snap where if stuff fails we can go to "emergency" mode and just drop into a busybox rootfs | 14:32 |
| ogra_ | zyga-ubuntu, doesnt sound very secure though :) | 14:33 |
| ogra_ | (trigger a failure and you get root shell access) | 14:33 |
| zyga-ubuntu | ogra_: I'm sure there's a way to make it sanely there (for development needs) | 14:34 |
| zyga-ubuntu | ogra_: I agre having it in production is probably unnecessary | 14:34 |
| ogra_ | yeah, a toggle to turn it on/off manually would be good (defaulting to off) | 14:35 |
| cjwatson | ogra_: It takes time | 14:37 |
| ogra_ | ah, k, i forgot ... always working with snaps pretty much spolied me ;) | 14:37 |
| * zyga-ubuntu goes to eat breakfast | 14:45 | |
| cjwatson | ogra_: it's not about debs, it's that the image update job is a periodic thing and there's one per arch | 14:53 |
| cjwatson | (ish) | 14:53 |
| ogra_ | ah | 14:53 |
| ogra_ | i thought it was promotion | 14:53 |
| ogra_ | s/promotion/publishing/ | 14:54 |
| jdstrand | mvo: hey, is 'type: base' now a thing? ie, should I update the review tools? | 14:55 |
| mvo | jdstrand: I think so, well, it should still emit a warning, i.e. we don't want to allow bases in without review | 14:56 |
| mvo | jdstrand: if you could approve my busybox-static-mvo, that would be great. that is a snap with only the "bare" (empty) base | 14:56 |
| jdstrand | mvo: sure, I can take care of all that, just wanted to make sure that the yaml is finalized | 14:56 |
| jdstrand | mvo: so there is 'empty-base' and 'bare' and your 'busybox-static-mvo' | 14:57 |
| jdstrand | mvo: ? | 14:57 |
| mvo | jdstrand: empty-base can be removed. bare and busybox-static-mvo I would love to have | 14:57 |
| jdstrand | mvo: ok | 14:58 |
| jdstrand | mvo: 'base: foo'. foo must be a string? | 15:12 |
| mvo | jdstrand: yes | 15:12 |
| jdstrand | k | 15:12 |
| jdstrand | mvo: fyi, I approved busybox-static-mvo. bare was already approved. updating the review tools now | 15:13 |
| jdstrand | mvo: is 'base: foo' valid only for 'type: app'? | 15:16 |
| mvo | jdstrand: so far yes | 15:21 |
| zyga-ubuntu | o/ | 15:21 |
| zyga-ubuntu | what's up guys | 15:21 |
| zyga-ubuntu | tests hate me today | 15:21 |
| zyga-ubuntu | econnreset | 15:22 |
| zyga-ubuntu | classic-ubuntu-core-transition-auth | 15:22 |
| zyga-ubuntu | and more ... | 15:22 |
| zyga-ubuntu | is it just me? | 15:22 |
| mvo | zyga-ubuntu: no, seems master is equally unhappy | 15:23 |
| zyga-ubuntu | but there is hope | 15:24 |
| zyga-ubuntu | I found my breakfast | 15:24 |
| niemeyer | zyga-ubuntu: Sent an update on the interfaces PR | 15:24 |
| zyga-ubuntu | niemeyer: thank you! | 15:24 |
| niemeyer | zyga-ubuntu: A bit long, but tried to provide concrete ideas that should unblock it | 15:25 |
| niemeyer | zyga-ubuntu: I'll step out for lunch.. please let me know how you feel about them later so we can be in sync | 15:25 |
| zyga-ubuntu | niemeyer: fantastic feedback, thank you! | 15:28 |
| zyga-ubuntu | niemeyer: I'm still reading but I think it's all appropriate and good; thank you for taking care about the big picture in the code :) | 15:29 |
| niemeyer | zyga-ubuntu: Sweet, glad you like it! | 15:29 |
| zyga-ubuntu | jdstrand: FYI https://github.com/snapcore/snapd/pull/3621 | 15:35 |
| mup | PR snapd#3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621> | 15:35 |
| zyga-ubuntu | jdstrand: some very early code there | 15:35 |
| zyga-ubuntu | jdstrand: particularly one doing Ux | 15:35 |
| zyga-ubuntu | jdstrand: I'm going to look at what would it take to move more of the startup logic to snap-update-ns | 15:35 |
| zyga-ubuntu | jdstrand: and how we can do per-snap layout confinement profiles (just made that term up) | 15:36 |
| zyga-ubuntu | jdstrand: as for the actual profile names, can I, say, use snap.foo.bar as the main apparmor profile and then do stuff like snap.foo.bar//layout as a sub-profile that applies to snap-update-ns? | 15:36 |
| zyga-ubuntu | jdstrand: just syntax wise | 15:37 |
| zyga-ubuntu | jdstrand: or do I need to encode that in some other way | 15:37 |
| zyga-ubuntu | jdstrand: in each case snap-update-ns will run after pivot_root (I think pivot_root cannot move to goland easily) | 15:37 |
| stgraber | mvo: https://github.com/lxc/lxd-pkg-snap | 15:40 |
| zyga-ubuntu | jdstrand: anyway, I'm off | 15:40 |
| zyga-ubuntu | jdstrand: lets sync later | 15:40 |
| Chipaca | niemeyer: let me know when you have 15' to go over stuff? | 15:47 |
| Chipaca | wtf, why is _everything_ breaking in spread :-( | 15:48 |
| Chipaca | oh | 15:55 |
| Chipaca | FTR, the store had a fairly bad hiccup ~1h ago | 15:58 |
| Chipaca | so that's why | 15:58 |
| niemeyer | Chipaca: Back just now | 16:17 |
| pedronis | Chipaca: yes, being fixed since | 16:26 |
| Chipaca | niemeyer: so, working from the commandline in, "snap status" as it stands in the PR is OK, yes? | 16:28 |
| niemeyer | Chipaca: Double checking | 16:30 |
| Chipaca | niemeyer: thank you | 16:30 |
| niemeyer | Chipaca: The output sounds sane.. I'm just wondering a bit about the command name itself | 16:32 |
| niemeyer | Chipaca: I wonder if it feels too much like "snap status" would result in what we have as "snap list" | 16:32 |
| niemeyer | Chipaca: (the status of snaps in the system) | 16:33 |
| niemeyer | Chipaca: WDYT? | 16:33 |
| Chipaca | niemeyer: a little bit, yes | 16:33 |
| Chipaca | niemeyer: OTOH we decided against "snap service status" AFAIK | 16:34 |
| Chipaca | niemeyer: and if "snap status" feels like this, I reckon so will "snap restart" | 16:34 |
| niemeyer | Chipaca: Indeed, and we have the same sort of ambiguity on enable/disable | 16:35 |
| niemeyer | Chipaca: I guess status is fine from that angle, and the analogy of systemctl is definitely a plus | 16:37 |
| niemeyer | Chipaca: Were you thinking about something specific when you asked? | 16:37 |
| Chipaca | niemeyer: no, just walking over the changes i need to make to be sure | 16:37 |
| Chipaca | layer by layer i mean | 16:38 |
| niemeyer | Chipaca: I think we're good on that one.. I do wonder how we'll represent timers when they come | 16:38 |
| niemeyer | Chipaca: Sounds like it'd make some sense to have them there.. | 16:38 |
| Chipaca | niemeyer: I don't understand your concern there, but that might be because I don't know what timers are for snapd | 16:38 |
| Chipaca | I know what they are in systemd | 16:38 |
| niemeyer | Chipaca: I think that's exactly my concern :) | 16:39 |
| niemeyer | Chipaca: (the fact we don't have a clear view, which might lead to awkward corners soon) | 16:39 |
| pedronis | well people asked to have systemd(-like) timers supported for snaps | 16:40 |
| jdstrand | roadmr: hi! can you pull r891 of the review tools? it isn't super-urgent | 16:40 |
| roadmr | jdstrand: sure! | 16:40 |
| Chipaca | niemeyer: timers can be active and enabled too, fwiw | 16:40 |
| jdstrand | mvo: ^ that has the base snap stuff and an override to allow 'bare' to pass automated review | 16:40 |
| niemeyer | Chipaca: Right, that sounds sane | 16:40 |
| niemeyer | and may be stopped/etc | 16:41 |
| Chipaca | niemeyer: anyway, going one step further in, we'd have an Apps method on clients, that takes a list of things, and an options struct | 16:41 |
| niemeyer | Chipaca: Yeah, singular I think | 16:41 |
| cjwatson | ogra_: Any new snap build will start with a version of launchpad-buildd without that bug now. | 16:41 |
| niemeyer | AppOptions? | 16:41 |
| Chipaca | niemeyer: singular...? | 16:42 |
| ogra_ | cjwatson, ok | 16:42 |
| niemeyer | I think that's what we do on other cases.. double checking | 16:42 |
| Chipaca | niemeyer: and, here i'm not so sure: the options struct has an All bool, which if false means just services? | 16:42 |
| niemeyer | Argh.. we have ChangesOptions.. we should really fix that one :( | 16:42 |
| Chipaca | why? | 16:42 |
| Chipaca | it's <method name>Options | 16:42 |
| niemeyer | Yeah, maybe | 16:43 |
| Chipaca | especially given that we used to have Change and Changes, ChangesOptions and ChangeOptions are clearly different beasts | 16:43 |
| niemeyer | Yeah, that's actually the issue | 16:44 |
| niemeyer | Often those option methods are useful in the context of a single thing | 16:44 |
| niemeyer | Let me try to find an example | 16:44 |
| niemeyer | func (client *Client) Install(name string, options *SnapOptions) (changeID string, err error) { | 16:44 |
| niemeyer | vs. | 16:44 |
| niemeyer | func (client *Client) InstallMany(names []string, options *SnapOptions) (changeID string, err error) { | 16:44 |
| niemeyer | The options are snap-related, the thing, rather than method-specific | 16:45 |
| niemeyer | thus ChangeOptions, AppOptions, etc | 16:45 |
| niemeyer | Similarly, although we have ChangesOptions, we call it ChangeSelector in one of its fields | 16:47 |
| niemeyer | With that background, yeah, indeed I'd suggest going with the singular, and eventually fixing ChangesOptions to agree | 16:47 |
| Chipaca | So Apps([]string, AppOptions)? | 16:48 |
| niemeyer | Yeah | 16:48 |
| Chipaca | ok | 16:48 |
| Chipaca | niemeyer: and would the options struct has an All bool, which if false means just services? | 16:48 |
| niemeyer | Chipaca: The opposite case feels more natural: return all by default as it's an /apps endpoint, and allow constraining to services by providing {Service: true} | 16:50 |
| Chipaca | ok | 16:50 |
| niemeyer | Chipaca: That opens the door for us to have a special kind of service which is hidden as well | 16:50 |
| Chipaca | niemeyer: and that translates to select="", "all", and "services" (with the two first ones being synonymous) | 16:51 |
| niemeyer | Chipaca: and which we uncloak via a future All field | 16:51 |
| niemeyer | Chipaca: Similar to what we do with snaps | 16:51 |
| Chipaca | ah, so no select=all as synonymous for ="" | 16:51 |
| Chipaca | niemeyer: ok so far? | 16:53 |
| niemeyer | Chipaca: Yeah, I'd keep just "" and "service" (again singular due to precedence in /v2/snap's refresh) | 16:53 |
| niemeyer | s/refresh/select | 16:53 |
| niemeyer | Chipaca: For that latter use case, perhaps just "" and "service" | 16:53 |
| niemeyer | Chipaca: Again singular (precedence in /v2/snaps's select | 16:53 |
| niemeyer | Thanks irccloud | 16:53 |
| Chipaca | niemeyer: precedent, not precedence, i assume | 16:53 |
| niemeyer | It told me it couldn't send my messages, and then did it later | 16:53 |
| Chipaca | ok | 16:54 |
| Chipaca | but note that snaps uses adjectives | 16:54 |
| Chipaca | bah, not even | 16:54 |
| Chipaca | in snap's select it's "refresh" or "private" | 16:54 |
| Chipaca | uhm | 16:54 |
| Chipaca | sorry, that's in find | 16:54 |
| niemeyer | Chipaca: Sort of.. I think it's a similar use case.. "the snap is a refresh.. the snap is private.. the app is a service" | 16:55 |
| Chipaca | in snap it's "all" or "enabled" | 16:55 |
| niemeyer | Chipaca: Sorry, I was really thinking of find | 16:55 |
| Chipaca | ok, singular | 16:56 |
| Chipaca | niemeyer: then, inside daemon, there's the call to the helper that right now has a struct. I think I'll change that to mirror the client's options, for less surprises. | 16:56 |
| niemeyer | Chipaca: Looking | 16:58 |
| niemeyer | Chipaca: You mean the wantedAppInfo? | 16:58 |
| Chipaca | yeap | 16:58 |
| niemeyer | Chipaca: +1 | 16:59 |
| niemeyer | Chipaca: I'm tempted to suggest "snap services".. I've been dueling with myself for the past 30 minutes on it | 17:02 |
| niemeyer | Chipaca: Part of the question is: are timers services as well? | 17:04 |
| niemeyer | I suspect that as far as systemd is concerned, they are not | 17:05 |
| Chipaca | niemeyer: they are distinct | 17:06 |
| niemeyer | Chipaca: So will we have a {Timer: true} flag? | 17:06 |
| Chipaca | niemeyer: although in systemd a timer is associated with a service of the same name | 17:06 |
| niemeyer | /o\ | 17:07 |
| Chipaca | niemeyer: that is, the timer is _just_ a timer | 17:07 |
| Chipaca | niemeyer: when it fires, it runs the service with the same name | 17:07 |
| pedronis | I doubt we would model it that way though | 17:07 |
| Chipaca | correct | 17:07 |
| Chipaca | niemeyer: (you can change which unit it fires, but the default is the one with the same name) | 17:08 |
| niemeyer | I guess the app would be a timer _and_ a service then? | 17:08 |
| Chipaca | niemeyer: an app would be … Daemon: timer ? | 17:08 |
| Chipaca | probably not because the service will have its own daemon: | 17:09 |
| Chipaca | niemeyer: a daemon can have a timer? | 17:09 |
| niemeyer | Chipaca: I was thinking of just having something like Schedule: <timing spec> | 17:09 |
| niemeyer | Chipaca: Or simliar | 17:09 |
| Chipaca | yup | 17:09 |
| Chipaca | so a service would have a timer / schedule / thing | 17:09 |
| Chipaca | makes sense to me | 17:09 |
| niemeyer | Chipaca: We might imply "Daemon: timer" in that case perhaps? | 17:09 |
| Chipaca | niemeyer: no because the service can be one-shot or notify or … | 17:10 |
| niemeyer | Chipaca: Or would it make sense for something to be a daemon *and* a timer? | 17:10 |
| niemeyer | Chipaca: Ah, okay, combined even in that sense.. nice | 17:10 |
| Chipaca | niemeyer: man systemd.timer fwiw | 17:11 |
| Chipaca | niemeyer: also | 17:11 |
| niemeyer | Chipaca: Yeah, I'm friends with that one.. have been trying to find a good syntax for ourselves | 17:11 |
| Chipaca | niemeyer: systemctl list-timers | 17:11 |
| niemeyer | Chipaca: Thanks, hadn't seen that one | 17:12 |
| Chipaca | niemeyer: and i'd expect we'd want something similar, maybe under 'snap timers' | 17:12 |
| Chipaca | but, dunno | 17:13 |
| niemeyer | Chipaca, pedronis: Okay, so, what's the experience we want? Do we show timers on "snap status/services" output? | 17:13 |
| Chipaca | because, dunno what timers are for snap :-D | 17:13 |
| niemeyer | Chipaca: +1 on "snap timers" | 17:13 |
| Chipaca | niemeyer: if a service has a schedule, maybe include a "last run" or "next run" column? | 17:14 |
| Chipaca | niemeyer: or a "see snap timers"? | 17:14 |
| Chipaca | i mean | 17:14 |
| Chipaca | no, i wouldn't show timers as lines in 'snap status' output | 17:14 |
| Chipaca | I'd show the services the timers fire, though | 17:15 |
| niemeyer | Chipaca: Or perhaps just "Schedule", with the actual string, and leave the specialized output for "snap timers" | 17:15 |
| Chipaca | niemeyer: that sounds reasonable | 17:17 |
| niemeyer | Chipaca: Okay, thanks, that gives much better understanding of what's to come.. so back to your original question: | 17:17 |
| niemeyer | Chipaca: I think the output is mostly fine.. a couple of points to ponder about: | 17:18 |
| niemeyer | 1. Should we always have the first field? That makes it more tooling-friendly (think awk, grep, ...) | 17:18 |
| niemeyer | 2. Would it be useful to have Daemon with the value of that field? | 17:19 |
| niemeyer | 3. I'm slightly conflicted about the name of the "Service" header.. not sure if "App" would make it more clear or more confusing | 17:20 |
| Chipaca | 1. i think yes, although i'm not sure it makes sense for it to be split | 17:20 |
| Chipaca | 2. i don't think Daemon tells the user of the app anything they need to know, no | 17:21 |
| Chipaca | 3. i think Service is a little clearer than App, but not by a wide margin | 17:22 |
| niemeyer | Okay.. for 1, should we just have it always then? | 17:22 |
| niemeyer | For 2, sounds good | 17:22 |
| Chipaca | 1., yes i think so | 17:22 |
| niemeyer | 3. Okay | 17:22 |
| niemeyer | Chipaca: Sounds like we have a plan then! | 17:23 |
| Chipaca | niemeyer: one last question: about the split of AppInfo and ServiceInfo in the client libs. It's mainly driven by the desire for the json to be nice and clean for non-service apps, and nice and explicit for service apps | 17:23 |
| niemeyer | Chipaca: I understand, but I also see value in the conceptual flattening.. we've already decided to make them look alike long ago, and it earned us many bonus points in terms of having plugs/etc handling not care, being able to have commands and services, etc | 17:25 |
| niemeyer | Chipaca: I think this is just being more honest about that internal representation, and passing the advantage of that flattening on to the client | 17:25 |
| niemeyer | Chipaca: It's analogous to systemd's "units", if you see what I mean | 17:25 |
| niemeyer | I'm sure somebody complained about "starting a mount point", but hey, the flat CLI is nice | 17:26 |
| Chipaca | hmm | 17:27 |
| Chipaca | niemeyer: in systemd, status of a unit (that is, the common ancestor of services, mountpoints, timers, ...) makes sense | 17:28 |
| Chipaca | niemeyer: whereas our apps are very distinct beasts | 17:28 |
| Chipaca | but, i'll flatten it | 17:28 |
| Chipaca | no worries | 17:28 |
| niemeyer | Chipaca: Not really.. we do have a bunch of common ground for apps | 17:28 |
| niemeyer | Chipaca: plugs and slots, security profiles, etc etc | 17:28 |
| niemeyer | Chipaca: Thanks! | 17:29 |
| niemeyer | Chipaca: Ah, and I suggest going with "snap services", given all of that useful background | 17:29 |
| Chipaca | ok | 17:30 |
| Chipaca | but not right now. Right now, time to walk the dog, and think of dinner, and maybe a beer | 17:30 |
| Chipaca | o/ | 17:30 |
| niemeyer | Chipaca: Sounds great, thanks for the chat.. I'll copy that conversation into the forum | 17:30 |
| Chipaca | tks | 17:30 |
| Chipaca | that's another thing that's harder to do in a hangout :-D | 17:30 |
| === JanC_ is now known as JanC | ||
| pedronis | niemeyer: did you get a chance to look at that branch? do you want to do a quick HO instead? | 19:36 |
| niemeyer | pedronis: I didn't manage to look yet, sorry, but it's definitely on my queue of things for today.. a HO might help | 19:45 |
| mup | PR snapcraft#1418 opened: nodejs plugin: fix incorrect symlinks <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1418> | 19:48 |
| pedronis | niemeyer: let me know I'm available for another couple of hours | 19:51 |
| niemeyer | pedronis: Sounds good.. give me ~10 mins and I'll be with you | 19:52 |
| pedronis | ok | 19:52 |
| niemeyer | pedronis: Heading to the standup HO | 20:07 |
| mvo | jdstrand: thank you! :) | 20:12 |
| jdstrand | mvo: the strace? | 20:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!