mupPR snapd#7545 opened: cmd/model: don't show model with display-name inline w/ opts <Simple šŸ˜ƒ> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7545>00:42
mborzeckimvo: morning06:19
mupPR snapd#7540 closed: interfaces/seccomp: query apparmor sandbox helper rather than aggregate info <Simple šŸ˜ƒ> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7540>06:19
mvohey mborzecki !06:22
mvomborzecki: how are tests looking today?06:22
mborzeckimvo: not worse than usual06:24
mvook, just wondering as I see a few reds from the night06:25
=== tomreyn_ is now known as tomreyn
mvomborzecki: the timeout test failure is peculiar - do you have any idea why it happens? do we have more than 52s wait under certain conditions with our retry stratgy?06:30
mborzeckimvo: no clue yet, i can reproduce it with spread, but it doesn't make sense, there's snap find executed couple lines earlier and that works fine06:31
mvomborzecki: confusing!06:34
mvomborzecki: can you reproduce it by e.g. blocking the store with iptables and then running snap find locally?06:34
mvomborzecki: I wonder if we use a different retry strategy for some command or something crazy like this06:34
mborzeckimvo: but then, across all the restarts, it happened only on opensuse06:35
mborzeckimvo: hmm daemon.go:316: DEBUG: pid=9079;uid=0;socket=/run/snapd.socket; GET /v2/find?scope=wide&section=featured 1m0.45857103s 20006:39
mvomborzecki: oh, interessting!06:41
mborzeckiOct 02 06:36:47 oct020627-523151 snapd[8948]: retry.go:61: DEBUG: The retry loop for06:42
mborzeckier_name%2Cdeveloper_validation%2Cprivate%2Cconfinement%2Ccommon_ids&scope=wide&section=featured finished after 1 retries, elapsed time=1m0.45638716s, status: 20006:42
mborzeckimvo: hm so we don't really set a timeout for the store request context06:43
mborzeckitbh beats me why this consistently fails on opensuse06:43
zygaGooooood morning06:44
mborzeckizyga:  hey06:45
zygaThis feels like a good day06:45
zygaIā€™m taking Bit for a walk but I will be back shortly06:45
zygaToday is a cgroup day06:45
mborzeckimvo: i'll see if i can improve the error message maybe, 'context deadline exceeded' isn't really nice ux06:47
mborzeckimvo: and perhaps find should not use a timeout then06:47
mvomborzecki: yeah, the ux improvements would be more than welcome06:50
mvomborzecki: do we use no deadline when we do the store find api call in the daemon? or just a diffrent one?06:50
mborzeckimvo: hmmm, so we use httputil and set a http.Client.Timeout which is set in store.New() to 10s, yet the request somehow takes 1m07:02
mvomborzecki: thats confusing07:04
=== pstolowski|afk is now known as pstolowski
mvomborzecki: also there was no retry, right?07:04
mborzeckimvo: no retry, it finished after the first attempt which was successful07:05
mborzeckipstolowski: hey07:05
mvomborzecki: confusing++07:05
mvomborzecki: makes me wonder if our timeout is actually working07:05
pstolowskimborzecki: reviewing your schedule fix pr07:27
mborzeckipstolowski: thanks! better grab a coffe :P07:33
pstolowskimborzecki: yes, i'm on a 2nd coffee already ;)07:34
mborzeckimvo: trying with this snippet using httputil.Client https://paste.ubuntu.com/p/Xcc7bfxtKf/ timeout seems to work07:35
mvomborzecki: even more puzzling07:36
mvomborzecki: we use bundled deps on opensuse, right? it can't be some strange bug in some external go package packaged in opensuse?07:36
mborzeckimvo: so crazy thought, the search results are super long, and we run with SNAPD_HTTP_DEBUG=7, what if journald/systemd blocks reading from stderr?07:42
mvomborzecki: could be! an interessting idea. it would be quite a bug though07:44
pedronismvo: hi, I made some high-level comments again in #7536, I didn't look at detail of the gadget code07:45
mupPR #7536: gadget: accept system-seed role and ubuntu-data label <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7536>07:45
mvopedronis: thank you! yeah, it matches my understanding.07:48
mborzeckigoogle:opensuse-15.1-64 .../tests/main/searching# snap find --section=featured07:50
mborzeckierror: cannot list snaps: cannot communicate with server: Get http://localhost/v2/find?scope=wide&section=featured: context deadline exceeded07:50
mborzeckimvo:  ^^ heh07:50
mborzeckimvo: so, was able to trigger this by executing snap find a number of times in succession07:51
mvomborzecki: but *just* on opensuse?07:51
mborzeckimvo: well, i have debug shell on opensuse open now :P07:52
pstolowskimborzecki: some comments/questions08:18
mupBug #1647256 changed: snap create-user cannot add a new user to an existing ubuntu core device <Snappy:Won't Fix> <https://launchpad.net/bugs/1647256>08:20
zygamvo, pedronis, mborzecki: https://forum.snapcraft.io/t/enabling-new-snapd-features-on-next-boot/1349308:24
zygathis is a required intermediate step for refresh app awareness _and_ for parallel instances and perhaps also for parallel installs for classic08:25
zygaI'd like to start implementing this as I really need it to have the ability to do some of the cgroup operations reliably08:27
pedroniszyga: so are you saiyng that some featue even after set will be on only after a reboot?08:50
Chipacayes, yes he is08:52
pedroniszyga: also it is really reboot or restart of snapd?08:52
Chipacapedronis: AIUI it's a reboot because things need to be set up before apps / services are started08:58
mborzeckiehh, go errors are so bad09:00
Chipacamborzecki: -109:00
mborzeckialso our client error handling is kind of bad too, especially the retry thing, but if we start looking at the errors, trying to find out which one is temporary or not, we're again into go-errors-are-bad territory09:04
Chipacamborzecki: client as in snapd/client/ ? or as in snapd/store/ http client usage?09:05
mborzeckiChipaca: snapd/client09:05
Chipacamborzecki: ah. I'll be looking at the temporary vs not thing as part of download at some point09:05
Chipacawell, that was the plan, but if you're there already09:05
zygapedronis: it is about really reboot09:07
Chipacamborzecki: basically the retry thing should look at externalities (bah, the existence of the socket :) ) to know whether to actually retry or not09:07
mupPR snapd#7546 opened: daemon: add a 'prune' debug action <Simple šŸ˜ƒ> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7546>09:10
pedroniszyga: you need to explain why because I don't know it, that topic says a lot of things except why exactly09:11
pedronisit's very hard to judge if it's a good solution or not given the problem isn't clear09:12
pedronisit sounds very complicated for sure, that I can say09:12
zygapedronis: as I said on the post "The feature only really works reliably if enabled before anything using said feature is used". We need this to reliably track cgroups for all processes using the feature. We also need it to establish a tracking cgroup so that we can get release notification handlers set up.09:13
pedroniszyga: please write down the details of the things we need to have, anyway is it related to version of snap-confine? or only install time stuff? or only boot time stuff?09:14
zygapedronis: for parallel instances I think we need a new mount unit for /snap or we will have transition issues as well.09:14
pedroniszyga: parallel instances for classic? in general?09:15
pedroniszyga: as a principle it's better to check for precise things, that for something correlated to those things09:15
zygapedronis: it is really about system-level machinations we perform, either we do or we don't at all - then the model is simple. If we sometimes do and sometimes don't because snapd was updated and apps are already running then there's all kinds of messy complexity that this solution avoids09:15
pedroniszyga: this is not useful, your are talking about general principles09:16
zygapedronis: it involves systemd units, snap-confine behavior (applied consistently) and snapd behavior which relies on it09:16
pedronisI need the details of the single problems09:16
pedronisin the forum topic09:16
pedronisotherwise we are not going anywhere here09:16
zygapedronis: there are multiple distinct ones, an existing one is where refresh app awareness misbehaves if enabled without rebooting because it doesn't known about processes that were started before the tracking was established09:18
pedroniszyga: but tracking involves snap-confine code, no?09:18
zygapedronis: the /snap mount propagation changes must happen before any systemd mount unit is started so it cannot be really enabled mid-way once the system is up and running09:18
zygapedronis: yes, it involves snap-confine code09:19
pedroniszyga: so don't think the solution is appropriate09:19
zygapedronis: why?09:19
pedroniszyga: because I can switch around snap-confine version without reboots09:19
zygapedronis: note, it involves many other components as well, not just snap-confine09:19
zygapedronis: so?09:20
pedronisso the tracking gets broken09:20
zygapedronis: how?09:20
zygapedronis: I think you are trying to find a bug in the system09:20
zygapedronis: the bug is already there09:20
zygapedronis: this allows us to fix the bug once we want to _enable_ experimental features that are currently disabled when unset09:20
zygapedronis: this allows us to _reliably_ make _that_ specific change09:20
pedroniszyga: I disagree on the reliable part09:21
zygapedronis: can you explain please?09:21
pedroniszyga: please write in the forum info of the form. Feature x is reliable if :  mount unit z looks like this,  all currently running apps for snas where started by a snap-confine with tracking code etc09:22
pedronisthen we can disuss details09:23
Chipacapedronis: context switch! we currently sub core for core16, do we have plans of doing the converse someday?09:26
pedronisChipaca: I was asking myself the same question looking at your code yesterday09:26
pedronisChipaca: in principle maybe, but I would write code for that now, you can put a TODO somewhere though09:27
Chipacapedronis: the first generalization of baseUsedBy took a otherBases ...string, but I deemed it over-engineered for what we used it for09:27
pedronis*I wouldn't write09:27
Chipacayeah i gotcha09:27
zygapedronis, Chipaca: note that if we want to substitute core16 for core we need new logic09:31
zygain snap-confine at least09:32
Chipacazyga: in snapstate as well09:32
pedroniszyga: yes, I imagine we need various code everywhere09:32
zygathis also amplifies the effect of a bug that needs design resolution on the forum09:32
zyga(about snap tools)09:32
pedronisthat's why I said it doesn't make soon to add support for it just in Chipaca's new code09:32
zygayeah, I think that should be done only after core18 tooling situation is stable09:33
zygapedronis: as to your question, I'm responding to the forum thread but I will create a separate thread for the tracking features that in my eyes justify the need for such a system09:34
zygapedronis: I'll give you a link when I have that in written form09:34
zygapedronis: thank you for looking :)09:34
zygamvo: I just noticed your status update in yellow09:35
zygamvo: do you know if that was core18?09:35
mvozyga: that is a very good question - cachio will know, all I have is https://paste.ubuntu.com/p/WpNftfG5G2/ and that its not a regression09:39
* zyga looks09:39
Chipacapedronis: zyga: core installed in a core18 system, and install a snap with base:core16, and then install core16, and then go to remove core, how far do you need to run?09:40
zygathe bug is: we never ran system-shutdown09:40
zygamvo: ^09:40
zygamvo: please report that for tracking09:40
zygaor it will be lost in the rain09:40
zygamvo: probably the glue logic for shutdown is missing09:41
zygamvo: I forgot how we inject system-shutdown into initramfs09:41
zygaanyway, something for later09:41
zyganot for today09:41
zygatoday I really want to start this new feature work09:41
pedronismvo: I updated #7462 to Paris decisions09:41
Chipacamvo: what's that bastebin from?09:41
mupPR #7462: asserts: introduce explicit support for grade for Core 20 models <Created by pedronis> <https://github.com/snapcore/snapd/pull/7462>09:41
Chipacamvo: that's missing things :-(09:42
* mvo is in a meeting09:49
* Chipaca hugs mvo for protecting us all from meetings09:51
mvoChipaca: pastebin is from cachio09:53
mvozyga, Chipaca: do you already know whats missing ?09:58
Chipacamvo: I know what didn't happen, but I don't know what's missing without more context10:01
mvoChipaca: ok10:01
Chipacamvo: there's an involved little dance that needs to happen for the system shutdown helper to be called10:01
Chipacait hasn't been called10:01
Chipacaso the dance didn't happen, or didn't work10:01
Chipacaor _something_ :)10:02
mvoChipaca: ok10:02
mvoChipaca: still in a meeting so can't poke at this right :/10:03
Chipacamvo: time is immaterial, or of the essence10:03
mborzeckiChipaca:  pushed a small refactor to #7166 to actually make sense of the errors returned in the client. can you take another look?10:10
mupPR #7166: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>10:10
zygamvo: a hunch, I can confirm in 10 minutes10:11
Chipacamborzecki: lgtm10:14
mborzeckijamesh: thanks for the hint about cache, i've tweaked the mount namespace of the snap and mounted a clean tmpfs over /var/cache/fontconfig, the fonts appear correctly now (although at the cost of longer start time)10:15
Chipacamvo: zyga: core18 seems to not have /lib/systemd/system/snapd.system-shutdown.service10:15
Chipacathat's the service that does the dance10:15
Chipacawhy is it not there?10:15
Chipacait was there before, I remember checking for this in core1810:16
mborzeckiChipaca: thanks!10:16
jameshmborzecki: interestingly the snaps using gnome-3-26-1604 are running with newer fontconfig than those using gnome-3-28-180410:17
jameshIt is a bit annoying to see that 2.14 is going to be different yet again though10:17
mborzeckijamesh: hm, perhaps updating gnome-3-28-1804 would be enough?10:17
jameshmborzecki: the 3-26 platform snap was built with a backport of new desktop libraries to 16.04, while 3-28 is just packaging what was in vanilla 18.0410:19
jameshit's a bit harder to replace random libraries there10:19
Chipacamvo: zyga: oh, it's at /etc/systemd/system/snapd.system-shutdown.service in core1810:19
Chipacamvo: zyga: straange, but ok10:20
Chipacamvo: zyga: and if the pastebin is indeed from core18, I've just confirmed that core18 on amd64 does do the shutdown dance10:20
Chipacamvo: zyga: http://r.chipaca.com/core18-shutdown.png10:22
pedronisChipaca: sorry, https://github.com/snapcore/snapd/pull/7445/files#r33047475510:22
mupPR #7445: overlord/snapstate/policy, etc: introduce policy, move canRemove to it <Created by chipaca> <https://github.com/snapcore/snapd/pull/7445>10:22
mvoChipaca: nice, thank you! so we need cachio to help with details, I think this was a on a pi10:23
mvoChipaca: but that should not make a difference :/10:24
Chipacamvo: maybe it's a fake core image, and whatever does the dance to set up the snapd.system-shutdown.service unit is missing?10:24
Chipacabecause that unit is in /lib in core that setting up for a core system wouldn't be necessary10:25
zygaChipaca: that's interesting10:25
zygaChipaca: it would be fun if the following were true10:25
Chipacathe fact that it's in /etc in core18 means something is adding it10:25
zygaChipaca: system-shutdown is broken by our extra mount points set up to execute tests on core systems10:25
Chipacaseems like a strange decision10:25
zygaChipaca: but I think we need to get sergio to just tell us what was executed10:26
zygauntil then we know too little10:26
Chipacaspeak of the devil10:34
Chipacacachio: buen dĆ­a!10:34
Chipacapedronis: which "other request"?10:35
pedronisChipaca: to enumerate the keys being set10:35
Chipacapedronis: yeah, it's weird that you don't get to see that10:35
cachioChipaca, buen dia!10:35
Chipacacachio: we've been puzzling over https://paste.ubuntu.com/p/WpNftfG5G2/10:36
Chipacacachio: what is the system running there? because it's missing something :) maybe10:36
cachioChipaca, here you have more details https://paste.ubuntu.com/p/WmVCD8SvTz/10:37
cachioit is pi3 running core 1810:37
cachiothat one is more interesting10:37
cachioFailed unmounting /var/lib/snapd.10:37
Chipacacachio: that is expected10:38
Chipacacachio: i think10:38
Chipacacachio: but that pastebin is different from the other in a crucial way10:38
Chipacasnapd system-shutdown helper: started.10:38
Chipaca^ those lines10:38
Chipacacachio: that is: systemd _can't_ unmount everything cleanly because it's all very circular; only something completely static and mounted outside of /writable can do that. So the system-shutdown helper does that.10:40
cachioChipaca, the short pastebin is what I got from the screen doing copy&paste10:40
Chipacacachio: and the long one?10:40
cachiothe long one I used screen tool to log it10:40
cachiowith -L10:40
Chipacacachio: but it's not the same run, is it?10:40
Chipacai mean, the output is different10:40
cachioChipaca, no10:40
cachiodifferent runs10:40
Chipacacachio: so, the long one is fine AFAIK10:41
Chipacacachio: the short one is not10:41
Chipacacachio: what is the difference?10:41
cachioChipaca, the short one is after running the tests10:41
cachioChipaca, the long one is with a fresh image10:41
Chipacazyga: is that what you meant about the test bind mounts breaking things?10:42
cachioChipaca, is this expected? [FAILED] Failed unmounting /writable.10:42
Chipacacachio: yes, that is expected10:42
Chipacacachio: note further down: snapd system-shutdown helper: - was able to unmount writable cleanly10:42
zygaChipaca: yes, I suspect our test preparation breaks this mechanism10:43
ograChipaca, it would be cool if we could teach systemd to omit that /writable message ... users notice the red more than the later message of the shutdown helper10:44
ogra(orthogonal to your discussion indeed)10:44
Chipacaogra: I looked into that in the core timeline and didn't find a way10:45
Chipacaogra: there might be a way now but i haven't re-checked10:45
ograah, k10:45
ogra(perhaps we could omit the writable mount unit from the start ... ? after all we dont really need it, it is just the silly systemd policy of creating usints for everyhing in fstab that creates it)10:46
Chipacado we need it in fstab even10:47
ogragood question10:48
ogra(the initrd scripts generate fstab and add writable there ... someone would have to test if we could omit it)10:49
zygaogra, Chipaca: systemd doesn't need fstab, it understands mount table directly11:05
zygafstab is a way to convey extra options11:06
zygaideally we would change things a little so that we can boot with just systemd created mount table11:06
zygabut that ship has sailed AFAIK11:06
zygauntil perhaps core2011:06
zygamvo, xnox: is the experiment to boot with systemd in initrd still ongoing?11:06
xnoxzyga:  yes11:07
zygaxnox: is it promising?11:07
xnoxzyga:  however, systemd does require either -.mount or like / declared in fstab.11:08
xnoxzyga:  hence e.g. our lxd containers declare that in fstab11:08
zygaxnox: _or_ specific declaration in GPT11:08
zygaxnox: then you can boot without /etc11:08
xnoxzyga:  -.mount unit needs to exist, whether gpt-generator or fstab-generator created it, doesn't matter, that is true. or if -.mount is written in /usr/lib11:09
ograxnox, the prob we have is a loopback mounted / ... where on shutdown systemd tries to pull out the carpet underneath the rootfs by trying to unmount /writable11:09
zygaxnox: yeah, agreed11:09
xnoxogra:  well, use finalrd to pivot into shutdown initrd which then has everything in ram to kill all the things, and unmount all the things, cleanly. despite layering.11:10
xnoxogra:  or declare LazyUnmount=yes on /writable11:10
ograxnox, on shutdown you go back into intird nowadays?11:10
zygainitrd is removed on boot (as in removed from memory) but I may be mistaken11:11
ograhow would you declare LazyUnmount=yes  ? the mount unit is created by a generator ...11:11
ograso that generator would have to know that /writable is a special thing while creating the unit11:12
zygaogra: I think we don't need lazy, we need to describe how we actually booted in the first place -- I think then systemd should be able to undo that11:12
ogra(but that sounds like a possible solution actually)11:12
zygabut anyway, I have things to do, this is in good hands11:12
ograzyga, not sure because what we do is actually very hackish11:12
zygaogra: let's just make ubunt-core cloud native: let's boot core in a small container created by a regular system ;)11:13
ogras/regular system/initrd/ ...11:15
xnoxzyga:  ogra: not back into initrd, but pivot_root to /run/initramfs/ something that looks like initrd, is in ram, but has /shutdown instead of /init11:15
xnox$ apt install finalrd11:15
xnox$ sudo finalrd11:15
zygaxnox: this matches my memory11:15
xnoxand checkout what's in /run/initramfs/11:15
Chipacaxnox: zyga: ogra: snapd.system-shutdown.service does the run/initramfs thing11:16
Chipacanot initramfs but whatever11:16
Chipacait sets up things to be pivoted into11:16
Chipacathat bit is fine11:16
ograxnox, oooh, thats sexy ... ! whose baby is that, yours ?11:16
xnoxChipaca:  yeah, but as discussed with mvo need to check if that does everything / enought / right11:16
xnox(yesterday on a different call with shutdown issues)11:16
Chipacaxnox: i hadn't heard that, but ok11:17
Chipacamaybe LazyUnmount is all that's needed for the angry red to go away11:17
* Chipaca tries11:17
ograyeah, but how to get it into the unit ?11:17
ograyou'd have to hack the generator and special-case /writable11:18
xnoxChipaca can create /run/systemd/system/writable.mount.d/lazy.conf with [Mount] LazyUnmount=yes11:18
xnoxogra:  it's a unit.... and supports drop-ins..... like everything11:18
ograoh, indeed !11:18
Chipacayep am already trying that11:19
Chipacain /etc not /run but w/e11:19
Chipacaxnox: also also why is bash-completion not in core18 :-(11:20
ograthe question is ... does that at least call sync to make sure ram is flushed to disk ? so we dont end up with fs corruption11:20
Chipacaogra: system-shutdown helper does the actual unmounting11:20
ograChipaca, i know but in case of Lazy... would we still need the shutdown helper if systemd calls sync ?11:21
Chipacaogra: systemd can't unmount /writable11:22
Chipacait _can't_11:22
Chipacasystemd is _running_ from /writable11:22
Chipacafrom a loopback filesystem mounted from /writable to /11:22
ograwell, i know :)11:22
ograbut its fine to not unmount if you are able to flush everything to disk11:23
Chipacaadding LazyUnmount=yes to /writable leads to system-shutdown helper not being able to find it11:24
Chipacaso that one is a no11:25
Chipacamaybe i should let other people worry about this11:25
* Chipaca has other stuff to worry about11:25
xnoxChipaca:  what is your original issue? maybe i can take over it?11:27
Chipacaxnox: nothing serious: core18 (as core) prints a nasty WARNING about not being able to unmount /writable11:28
xnoxChipaca:  on shutdown, right?11:28
Chipacaxnox: that is worrisome for users11:28
xnoxChipaca:  i think that is fixable.11:28
Chipacaxnox: the system-shutdown helper then kicks in and makes sure everything is alright11:29
ChipacaOTOH, and the point where I would have to sink time into this, is whether this LazyUnmount thing actually does the right thing somehow?11:29
xnoxChipaca:  which is same as on live media today, when booted with casper. There are similar warnings about not being able to unmount /cdrom which is like the same thing.11:29
Chipacaif the shutdown helper is no longer needed, huzzzah :)11:29
Chipacaxnox: yeah11:30
xnoxChipaca:  the other alternatives i was looking at, is to declare [Unit] DefaultDependencies=no => such that initial run of unmounts, doesn't try to unmount writable at all.11:30
xnoxbut the later helper undoes it all11:30
Chipacaxnox: that does seem to work11:32
Chipacaat least wrt not printing the warning11:33
Chipacathe system-shutdown helper logging sometime doesn't make it to the terminal, for some reason, which is weird11:33
Chipacacachio: ^^^ that's relevant to your pastebin11:33
Chipacasometimes things don't appear where i expect them to be :-|11:33
cachioChipaca, i'll try to run tests 1 by 1 and reboot to see if at some point we see that11:45
pedronispstolowski: I reviewed #7518 , couple things look a bit off11:49
mupPR #7518: cmd/snap: sort tasks in snap debug timings output <Created by stolowski> <https://github.com/snapcore/snapd/pull/7518>11:49
pstolowskipedronis: ty11:50
Chipacalunch, you say?12:07
* Chipaca bows to the inevitable12:08
=== ricab is now known as ricab|lunch
mupPR snapd#7166 closed: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7166>13:17
mupPR snapd#7527 closed: interfaces/input: support confined snaps accessing keyboard and mouse directly <Created by AlanGriffiths> <Closed by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7527>13:30
Chipaca"take up running", they said. "it's healthy", they said.13:36
cwayneChipaca: who said that theyre dumb13:37
Chipacathat was my knee talking, you may disregard13:38
mupPR snapd#7546 closed: daemon: add a 'prune' debug action <Simple šŸ˜ƒ> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7546>14:11
=== ricab|lunch is now known as ricab
Chipacacachio: about the 'snap logs' issue, i think the test is buggy14:48
Chipacacachio: it assumes the only lines in the log come from the unit, but they can also be from systemd14:48
Chipacacachio: and the systemd ones happen 'at random' (not really random, but from the PoV of the test they are unpredictable)14:48
* Chipaca adds support for refresh.metered=hodl14:56
ograhodl !15:00
blake_ri submitted a form to register the "maas-cli" snap in snapcraft.io (being that its reserved), but I have not received a response and its been a few days15:01
blake_rdid I go about that the correct way?15:01
Chipacaroadmr: is that a you? ^15:02
* roadmr ducks behind the nearest shrub15:02
roadmrChipaca, blake_r : let me check the queue15:03
ograjust use Chipaca's hodl to hide behind15:03
roadmrblake_r: I see blake-maas-cli which is approved15:05
blake_rroadmr: yeah the form required me to use that name15:06
blake_rroadmr: but I really wanted maas-cli15:06
blake_rroadmr: if you could have it owned by Canonical, that would be good as well ;-)15:06
blake_rroadmr: as the "maas" snap is going to use a content interface to the maas-cli snap15:06
roadmrblake_r: I can't rename a snap; can you please request maas-cli again? if it asks you to file a dispute, please do so, then I can approve it and give you the name15:07
blake_ri tried that, but the form hit a validation error15:07
blake_rlet me try again15:07
roadmrblake_r: try this form: https://dashboard.snapcraft.io/register-snap/15:07
blake_rroadmr: hmm worked that time15:08
blake_rroadmr: should be there15:08
blake_rroadmr: can the blake-maas-cli be removed?15:08
roadmrblake_r: I can revoke it15:09
blake_rroadmr: can you also do "meta-maas-blake"?15:09
roadmrrevoke that one? sure15:09
blake_rroadmr: sure just to make my snapcraft account clean!15:09
blake_rroadmr: thank you15:09
blake_rroadmr: now how do I go about getting the maas-cli to be owned by Canonical15:09
blake_rroadmr: do I need to push a snap first?15:09
roadmrblake_r: we transfer it to the canonical account; we typically only do that once there's a snap there, preferrably on stable. Fine to keep under your account while the snap is still developer-grade15:10
roadmrblake_r: (to be clear, you ask us to transfer it, preferrably via snap-store-admins@lists.canonical.com)15:10
roadmrplease :)15:10
blake_rroadmr: will do15:11
roadmrthanks :)15:11
blake_rroadmr: thank you!15:11
zygapedronis_: running test with the new cgroup idea15:12
roadmrblake_r:  meta-maas-blake is in some weird state, it'll take me a bit to fix it.15:13
cachioChipaca, ok, so I'll update the test15:15
cachioChipaca, thanks for the info15:15
roadmrblake_r: I think I fixed meta-maas-blake15:20
blake_rroadmr: yeah I see its gone, thank!15:20
mupPR snapd#7547 opened: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>15:23
Chipacawho knows about the snap store proxy these days?15:25
mvozyga: nice, surprisingly small15:25
zygait has some clenaups that I can fork off and do separately15:26
zygastill working on it though :)15:26
mupPR snapd#7548 opened: tests: update snap logs to match for "test-snapd-service" instead of "running" <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7548>15:26
zygabut that's bulk of the idea15:26
joeubuntuI have an update to my snap, I incremented the version in the yaml, built a new snap and pushed it. But the version on the listing page did not increment. What is the correct way to do this ?15:27
zygaoh, github has added multi-line comments!15:27
zygajoeubuntu: what is the listing page?15:27
joeubuntuhey zyga https://snapcraft.io/teamtime15:28
Chipacajoeubuntu: did you release the pushed revision?15:28
ograsnap info temtime shows a revision from today in stable15:30
joeubuntuChipaca maybe :)15:30
Chipacaogra: yes but it's revision 115:30
* zyga is hungry for real lunch15:30
joeubuntuogra, but if I install it , it pushes the old version .15:30
zygathat breakfast-for-lunch was not a good idea15:30
Chipacajoeubuntu: the revision in stable is revision 115:30
Chipacajoeubuntu: that's not an update of anything :)15:30
joeubuntuChipaca , how would I increment that? I pushed a 2.0 up15:31
zygajoeubuntu: release15:31
ograzyga, try brunch-for-dinner instead ... way better ...15:31
Chipacajoeubuntu: snapcraft list-revisions teamtime15:31
Chipacajoeubuntu: identify the revision you want to be in stable15:31
Chipacajoeubuntu: then, snapcraft release teamtime <that revision> stable15:32
=== pedronis_ is now known as pedronis
Chipacajoeubuntu: there are flags on push to do this in a single step15:32
Chipacaie snapcraft push --release=<channel> the.snap15:32
joeubuntucool. it worked thanks Chipaca !15:32
Chipacashocking :)15:33
joeubuntugreat, thanks for the help.15:33
Chipacajoeubuntu: this was all a marketing ploy wasn't it15:33
joeubuntuI think looking at my revision history you'd see it took me at least 4 tries :)15:33
cachioChipaca, after running the snapd-failover test the reboot is not triggering the snapd system-shutdown helper anymore15:35
cachioChipaca, do you know if is it any way to restore it15:36
cachioso I don't need to reflash the sd card15:36
Chipacacachio: zyga was the one with insight into it not working i think15:43
Chipacawrt mounts?15:43
* zyga runs15:51
zygaI didn't look at specific15:51
zygajust said it felt like something we would break15:51
zygait may also15:51
zygathat there's a real bug15:51
zygaunrelated to the test itself15:51
zygafixed a bunch of silly stuff, trying again15:56
zygaI think refresh-app-awareness test will now pass15:56
zygathe management scripts may need tweaking to unmount that though15:56
* zyga adds a todo15:56
ijohnsonChipaca or mvo am I good to merge #7545 now? I fixed the issue with the spread test and it's green with 3 approvals16:01
mupPR #7545: cmd/model: don't show model with display-name inline w/ opts <Simple šŸ˜ƒ> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7545>16:01
cachiozyga, after run any test the is not triggering the snapd system-shutdown helper anymore16:02
mupPR snapd#7545 closed: cmd/model: don't show model with display-name inline w/ opts <Simple šŸ˜ƒ> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7545>16:02
cachiobut if I restart the board again16:02
mvoijohnson: I have not looked and I'm in a meeting but if it has 3 +1 - sounds like it16:02
ijohnsonah well pedronis merged it, thanks!16:02
cachiothe is not triggering the snapd system-shutdown helper is triggered16:03
zygacachio: probably something nukes the shutdown state16:03
cachiozyga, yes16:03
cachioI'll continue with this after lunch16:03
* cachio lunch16:03
=== pstolowski is now known as pstolowski|af
=== pstolowski|af is now known as pstolowski|afk
zygaand now it passes, cool16:29
zygaok, wrapping up soon16:29
zyganeed to adjust mount-ns test to reflect this16:30
zygabut I'm super positive this is the way forward16:30
=== ricab_ is now known as ricab
zygamvo: https://github.com/snapcore/snapd/pull/7547 pushed16:39
mupPR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>16:39
zygait should pass all tests (we'll see what happens)16:39
zygaI'll work with maciek on it tomorrow16:39
zygaprobably chop it into a smaller part to focus on the essential16:39
zygaand add some more tests16:39
zyganext up: the release agent :)16:39
zygathis is so cool16:40
zygapedronis: ^ if you want to take a peek16:46
zygapedronis: I added a TODO to the pull request16:46
* zyga EODs16:48
zygaenjoy your evenings :)16:48
=== ijohnson is now known as ijohnson|lunch
blake_ri got a content interface question18:12
blake_rso i created a content interface where i want to expose the maas-cli executable to the maas snap18:12
blake_rthe interface works correctly18:12
blake_rbut when the maas snap calls the maas-cli binary none of the SNAP_ are set for the maas-cli they are from the maas snap instead18:12
blake_rany ideas on how I can get the environment to be the maas-cli SNAP when calling the binary from the maas snap18:13
Chipacablake_r: sounds like a question for the forum18:14
Chipacablake_r: also note _most_ (but not all!) of the snapd core team is in eu timezone18:14
Chipacablake_r: but that question in particular is best answered by our tame polish horde18:14
Chipacaanyway, i'm not here, i'm having dinner18:15
blake_ryeah your messages are invisible ;-)18:15
blake_renjoy dinner18:15
zygablake_r: hey18:32
zygablake_r: can you take a step back18:33
zygablake_r: and tell me what you want to achieve18:33
blake_rgoal is to keep the "maas-cli" in its own snap18:33
blake_rwhen installing "maas" snap it will also install "maas-cli" using content interface18:33
zygablake_r: while you can change or just ignore SNAP_ environment variables it won't change what happens at runtime, the program will run with the permission of the snap it is used from, not the snap it is coming from18:33
blake_rzyga: is it possible to allow a strict snap to call another strict snaps executable? from the system root per say18:34
blake_rso like /snap/bin/maas to call /snap/bin/maas-cli ?18:35
ograyes, there are snaps doing that (the wine content snap comes to mind)18:37
blake_rokay I will give it a try18:38
blake_rthat might be all that is needed, if that is possible18:38
blake_rogra: doesn't seem possible18:43
mvorbasak: I guess I'm way too late but I was wondering if you might have a look at the snapd sru in the unapproved queue?18:47
zygablake_r: no, not today18:49
zygablake_r: you cannot do that with the usual semantics of "that other snap is running"18:49
zygablake_r: you can at most share the bits and run them as yourself18:49
blake_rzyga: okay, will try to get it to work by just importing the python library18:49
zygablake_r: if you need to share things more you need an API and you need to make requests to a service18:49
blake_rzyga: i think that will work, as that is all that is really needed18:49
ograperhaps try talking to @mmtrt on the forum ... https://forum.snapcraft.io/t/auto-connections-of-wine-base-stable-wine-base-devel-and-wine-base-staging/1122918:51
ograhe provides snaps that layer one on top of each other to make wine applications work via content sharing18:52
ogralike an onion :)18:52
ogra(might also make you cry ... not sure :) )18:53
=== ijohnson|lunch is now known as ijohnson
mupPR core18#140 opened: run-snapd-from-snap: check for snapd.service existing too <Created by anonymouse64> <https://github.com/snapcore/core18/pull/140>20:53
* cachio eOD21:26

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!