[01:18] PR snapd#7272 opened: [PATCH] interfaces/bluez: enable communication between bluetoothd and meshd via dbus [04:56] morning [05:22] brb, new kernel [05:23] re [06:11] Hejka [06:18] zyga: hey hey [06:42] mvo: hey [06:43] hey mborzecki [06:43] mvo: anything intersting happened on thu/fri last week? [06:44] mvo: https://github.com/snapcore/snapd/pull/7257 failed on 14.04 [06:45] PR #7257: packaging: fix symlink for snapd.session-agent.socket [06:46] mvo: hi, did you see my fix for the FindU/Gid spread problem, it was a silly issue [06:52] pedronis: aha, thanks! I noticed it failing but then had to leave and was a bit puzzled, thanks for sorting it out [06:53] pedronis: oh fun! now I see the fix, silly indeed [06:54] pedronis: thanks :) [06:56] mborzecki: I run it in spread with -debug now [06:58] re [06:58] * zyga looks after PRs from last week [07:01] thank you for iterating on https://github.com/snapcore/snapd/pull/7254 everyone! [07:01] PR #7254: cmd/snap-update-ns: fix pair of bugs affecting refresh of snap with layouts === pstolowski|afk is now known as pstolowski [07:15] morning [07:15] hey :) [07:16] hey zyga and pstolowski ! [07:17] pstolowski: hey [07:19] mvo: can you cherry-pick e864cd99affea16b8742a9f3b5257dfb5f65065f to 2.40? it's blocking https://github.com/snapcore/snapd/pull/7264 [07:19] PR #7264: packaging/fedora: build on RHEL8 (2.40) [07:21] mborzecki: sure [07:22] mborzecki: done [07:22] mvo: thank you [07:22] mvo: I merged master into #7124 and gave my +1, but I have a question there, that maybe you can answer too [07:22] PR #7124: many: create system-usernames user/group if both don't exist [07:23] pedronis: looking now [07:31] PR snapd#7263 closed: snap: cleanup some tests, clarify some errors [07:32] pedronis: I will work on your question about 7124 and push a fix (I think we need one but I double check now) [07:33] thx [07:33] zyga: can you finish the review of #7081? would be great to land it [07:33] PR #7081: ifacestate: optimize auto-connect by setting profiles once after all connects [07:33] pstolowski: sure, on it [07:35] thanks! [07:51] pedronis: I think we also need to delete the group, i'm checking now [07:53] pedronis: aha, no, nevermind [08:26] PR snapd#7267 closed: many: simpler access to snap-seccomp version-info === mborzeck1 is now known as mborzecki [08:55] this is new: 2019-08-19 07:56:22 Cannot allocate google:ubuntu-18.10-64: cannot allocate new Google server for ubuntu-18.10-64: the resource 'projects/ubuntu-os-cloud/global/images/family/ubuntu-1810' was not found [08:56] images are gone or what? [08:58] 1804 just worked for me fwiw [08:58] bah, 09:38:37, 20 minutes ago [08:58] 18.10 reached end of life at the end of July [08:59] maybe the official images got pulled to encourage upgrades? [08:59] duh [08:59] thought we copy those images to our project :/ [09:00] mborzecki: but we don't have 18.10 in google in our spread.yaml [09:00] Chipaca: that's a job for 2.40 branch [09:00] ah [09:00] hm an update neded then? :) [09:01] It's going to be interesting to see what GitHub Actions does to the CI service landscape in the next year [09:01] mborzecki: pull #7127 into 2.40 [09:01] PR #7127: tests: removing support for ubuntu cosmic on spread test suite [09:02] mborzecki: that's f2fa5ce91609d31b8263c92f5f46488d2eedd1f3 if it makes it any easier :) [09:02] mvo: can you cherry-pick f2fa5ce91609d31b8263c92f5f46488d2eedd1f3 ? [09:02] hehe [09:02] Chipaca: thanks! [09:23] mvo: did you see that snapd-master cannot be uploaded? [09:24] zyga: happy birthday! 🍺 🎁 [09:24] pstolowski: thank you :) [09:24] more gray hair to grow I guess :D [09:25] :) [09:25] mborzecki: sure, done [09:25] mvo: thank you [09:25] zyga: yes, the socket symlink fix will fix this [09:26] zyga: onces spread is green I think we can merge it [09:26] zyga: oh? I had no idea - HAPPY BIRTHDAY :-D [09:26] thank you everyone [09:28] zyga: 37? [09:28] yep [09:29] oh boy, you're young [09:29] zyga: happy almost-40 :) [09:29] pstolowski: are you older? [09:30] zyga: 42 [09:30] pstolowski: you look like 30 [09:43] :D [09:45] pedronis: hi, the renames we talked about https://github.com/snapcore/snapd/pull/7273 [09:45] PR snapd#7273 opened: gadget, overlord/devicestate: rename Position/Layout [09:45] PR #7273: gadget, overlord/devicestate: rename Position/Layout [09:47] mborzecki: thx, will look [10:03] mvo: I found a simpler way to solve the lxd problem https://github.com/snapcore/snapd/pull/7274 [10:03] PR snapd#7274 opened: tests: change cgroups so that LXD doesn't have to [10:03] PR #7274: tests: change cgroups so that LXD doesn't have to [10:04] does the store support searching for snaps by free/non-free license? [10:04] zyga: nice! good job [10:05] mvo: silly question: where is grub-editenv supposed to be in a core18 system? [10:06] Chipaca: we may not have it there, we don't need it for snapd, it handles all of this via the internal grubenv code [10:06] Chipaca: do you need it for tests? [10:06] ahh [10:06] mvo: maybe not [10:06] maybe i was just being lazy :) [10:07] heh, ok [10:15] pstolowski: I'm still going through [10:15] need a coffee, brb [10:57] how did one stop initramfs before it pivoted into the real thing? [10:57] something-bottom [10:57] Chipaca: break=bottom or break=top [10:57] Chipaca: in the kernel command line [10:57] thanks [10:57] my core18 is coming up mounted weird :) [10:57] * Chipaca debugs [10:58] Chipaca: weird how? [10:58] mborzecki: it's something i broke with my boot changes [10:59] weird as in not mounted? :) [10:59] but, mounted [10:59] no home [10:59] heisenmount [10:59] are we setting snap_core wrong ? [11:00] these are the questions i'm asking myself :) [11:11] there's some weird dependency that i'm not seeing, so i'm going to go back to plan C and redo this bit by bit [11:12] but first, a wild lunch appears! [11:12] * Chipaca is in the tall grass [11:18] pedronis: I added some comments to 7124, I think we want some more tests for check_snap.go otherwise just nitpicks. probably fine in a followup. I also broke the spread test - it looks like on arch groupdel is not actually working :/ at least that is what the error indicates [11:24] mvo: do you have more details about the problem on arch? [11:24] mborzecki: working on getting details, maybe just some different default [11:25] mborzecki: USERGROUPS_ENAB seems to be false on e.g. tumbleweed (zyga can you confirm) ? this is set in login.defs [11:27] mvo: 196:USERGROUPS_ENAB yes [11:27] mborzecki: ok, I look further [11:27] mvo: which spread test is that? [11:30] mvo: checking [11:30] mvo: USERGROUPS_ENAB is not an option listed in /proc/config.gz [11:30] perhaps the configuration has changed and is no longer there? [11:31] mborzecki: it was in 7124 but I think I made it robust enough now [11:31] this is on 5.2.5 [11:31] zyga: it's in /etc/login.defs [11:31] zyga: login.defs [11:32] ah, sorry [11:33] it's indeed set to "no" [11:42] zyga: thanks! I updated the test [11:51] btw. do user ids still start at 500 by default in opensuse? [11:51] zyga: ^^ [11:56] mborzecki: I don't think so [11:56] my id is 1000 [11:56] PR snapd#7269 closed: tests: add test for services disabled during refresh hook [11:57] mborzecki: UID_MIN is 1000 on TW [11:57] PR snapd#7268 closed: tests: add /var/cache/snapd to the snapd state to prevent error on the store [11:59] PR snapd#7236 closed: packaging/ubuntu-16.04: provide a way to reset snapd without purging [12:07] mvo: shall we land https://github.com/snapcore/snapd/pull/7109 ? [12:07] PR #7109: [RFC] snap-confine: fallback gracefully on a cgroup v2 only system [12:10] mborzecki: if it works well enough for fc31 then yes [12:10] (IMHO) [12:13] mvo: with this branch, the list of failing tests is here: https://forum.snapcraft.io/t/snapd-with-unified-cgroup-hierarchy/12528/2 === ricab is now known as ricab|lunch [12:40] Chipaca: what is 408? [12:40] https://www.irccloud.com/pastebin/2uUquJFw/ [12:47] zyga: request timeout [12:48] zyga: https://httpstatusdogs.com/408-request-timeout [12:48] er [12:48] zyga: https://httpstatusdogs.com/408 [12:53] zyga: note it's a _client_ error [12:54] these days using GPRS you'll hit a lot of 408s [13:01] 2fa [13:22] mborzecki: hmm, one test exploded on me on fedora [13:22] https://www.irccloud.com/pastebin/Q9PySGal/ [13:22] it's pretty odd, seems like random corruption and failure [13:22] (it didn't fail on the same code before) [13:22] sudo: unable to execute ./hightest: Permission denied [13:24] may be something I broke after all, please ignore me [13:24] zyga: iirc hightest only checks user id's in high values range [13:34] mvo: hey, thanks for the updates for 7124, shall I take over now (note, groupdel --force isn't available until newer releases, but I can fix that) [13:37] jdstrand, https://paste.ubuntu.com/p/TpynTdQv8Z/ ... adding time-control (which is a bit funny given the app doesnt have anything to do with time) makes the environment error go away due to teh explicit denial you added there ... wouldnt it make more sense to put that and the /proc/1/sched denial into some generic place instead ? [13:38] i assume we never want any snap app to read either anyway [13:38] jdstrand: lets have a quick sync with samuele - in a meeting right now [13:38] jdstrand: most of my comments are really just nitpicks [13:43] mvo: we need to fix the groupdel issue, so I'll fix that and small nits [13:44] jdstrand: \o/ thank you [13:44] mvo: and wait for you for other stuff [13:44] jdstrand: sorry, was not aware that --foce is not there :/ === ricab|lunch is now known as ricab [13:49] zyga: isn't that a default umask or sth? [13:54] AFK for cooking [13:56] jdstrand: ok, I just wait for your push and then we can do more stuff in a followup. I am happy to help if you want [14:08] ijohnson: hey! 7214 is green and has two +1 - can I merge it ? [14:08] * ijohnson looks [14:09] mvo: I made the changes that jdstrand requested, but I'm not sure if we need jdstrand to re-approve the changes before merging [14:19] ijohnson: I just now approved (for the security policy bits) [14:21] thanks jdstrand, then mvo yes I think it's good to be merged [14:22] ta [14:24] PR snapd#7214 closed: interfaces/network-setup-control: allow dbus netplan apply messages [14:34] zyga, i think i found a layouts bug :( [14:36] zyga, a snap that ises a layout can be installed fine (and teh layout works as expected) ... but if i try to upgrade it i get https://paste.ubuntu.com/p/KnbskvpwQ7/ [14:36] (and note that there is no /etc/libblockdev anywhere on the host, so the error is bogus) [14:37] s/ises/uses/ [14:40] note that snap remove/install works fine as well [14:50] ogra: hey [14:50] ogra: it was recently fixed, can you check edge [14:50] i will ... good to know it is known then [14:50] ogra: it was bug .... [14:50] yeah [14:51] https://bugs.launchpad.net/snapd/+bug/1808821 [14:51] Bug #1808821: snap with layout cannot be updated multiple times [14:51] btw, is there any possible way to layout something in /run ? [14:51] ogra: no, not to /run AFAIR [14:51] we NACK that for security reasons [14:51] i'm trying to package udisks2 and it tries to write to /run/mount/utab [14:51] there's an interface for that [14:52] but udisks and utab is a bit of a special case [14:52] it's complex to get right, I think utab is a bit of a lost case :/ [14:52] well, the snap uses the udisks interface [14:52] yeah [14:52] I can explain later after lunch, bbl [14:53] awe dropped the official udisks2 snap and i want to make at least a demo snap for people relying on auto-mounting on core ... so i'm trying my luck here :) [14:53] it automounts fine already [14:53] but sadly it never cleans up /media/root but instead adds dir after dir if utab isnt accessible [14:53] (one new one for each plug of a disk) [15:00] return fmt.Errorf("no not remove kernel assets: %s", err) [15:00] "no anything but that" [15:00] Chipaca: heh [15:00] Chipaca: where does this one comes from? [15:01] mvo: that's in the old (current master) boot/kernel_os.go's RemoveKernelAssets [15:03] #7135 is ready for reviews [15:03] PR #7135: image: support prepare-image --classic for snapd snap only images [15:05] stgraber: hey, is there any in-cloud lxd images mirror? in our spread tests for snapd (that run in gce) I saw that pulling an image sometimes gets ~60kb/sec download speeds only [15:05] mvo: just finishing up some unit tests [15:07] mvo: using ubuntu: as image remote? If so, we've been requesting it be served by more than a single machine in London for years... [15:08] mvo: you could use images:ubuntu/bionic which is our community image server that unlike the main Ubuntu one does have multiple distributed servers backing it [15:14] ijohnson: I commented briefly on 7270 [15:15] pedronis: but what about for the disable case? if we only save the info in the change and the change gets garbage collected we would lose that info when someone goes to enable a snap [15:15] ijohnson: ? [15:16] say someone disables a snap, we save the list of services in the change, they wait for xyz days and the change in state.json disappears [15:16] don't changes in state.json disappear? [15:16] ijohnson: I'm missing something here [15:16] what worries you? [15:16] (sorry responding to your comment on #7270, figured it would be quicker over IRC) [15:16] PR #7270: [RFC] overlord: save disabled snap svcs on unlink snap tasks [15:17] I'm worried about saving the list of disabled services inside a chance since changes aren't persistent [15:17] ... afaik [15:17] ijohnson: you are thinking of code that is not there yet [15:17] in the code is all about the change, no? [15:17] do you have a case were we need to remember across changes? [15:18] snap install xyz, snap stop --disable xyz.svc; snap disable xyz; sleep 10000000000; snap enable xyz [15:18] the enable and disable of the entire snap are different changes, no? [15:19] yes [15:19] so in that case if we saved the disabled services in the change we would lose it when we disable the entire snap and re-enable the snap [15:20] it would specifically not be available when we do the enable of the snap [15:22] mvo: ok, I made the adjustments where it was clear to me what was wanted. I didn't do the bit flags/options struct or invert error message [15:23] ijohnson: I see, problem is we don't do anything like that so far [15:23] and there are two approaches to this [15:24] mvo: I think this is what you had in mind for testing 'passing as expected': https://github.com/snapcore/snapd/pull/7124/commits/047c7bc64062d0938f1d7b152c540170d7e2f710 [15:24] PR #7124: many: create system-usernames user/group if both don't exist [15:24] ijohnson: we could remember the state as an "intention" when we actually get the enable/disable command [15:24] ignore what is really happening on disk [15:24] sorry I mean the enable/disable command for services (not for the snap) [15:25] mvo: please let me know what else you need [15:25] arg, a conflict [15:25] * jdstrand fixes [15:25] ijohnson: that would be more similar to what we do in general [15:26] it means tough we could stomp on the user doing things outside snapd [15:26] we don't really promise to always support that tough [15:26] ijohnson: 2nd approach, we can do what your code is doing, we need to think how to make clear that that state is different from all other state we keep tough [15:26] which is the part that confused everybody [15:27] because as I said we don't have state like that [15:27] so far [15:27] pedronis: hmm so in your first option would we really be "enabling"/"disabling" the service not in the systemd state, but rather inside snapd? [15:28] so the systemd unit would always show up as "enabled", but if the user disabled it with --disable, then `snap run the-svc` would never really run the service? [15:29] ijohnson: isn't that true with your code as well? [15:29] we remember exactly what the user did [15:29] mvo: ok, resolved conflict and merged [15:30] no that's different from how I was imagining it, in my case the state of the service is always in systemd, and just while the snap is inactive between revisions we save the disabled services [15:30] then on "link-snap", after generating the systemd services we go through that list and disable them and everything is normal [15:30] s/everything/everything else/ [15:30] ijohnson: yes, I understand [15:30] not sure how it relates to your point tough [15:31] do you think we need a meeting to discuss? I can explain my reasoning in a forum post if that would be helpful [15:32] jdstrand: I love your commit message "don't use --force with groupdel since it is only documented, not implemented" :) [15:32] ijohnson: no I think I understand you what you are saying, nothing stop us to show that snapd state and reality have diverged [15:32] though [15:32] re [15:32] anyway I'm just trying to make clear that there isn't only one way [15:32] sorry, kitchen emergency [15:32] to attack this [15:33] having just one place with state is appealing [15:33] hmm [15:33] mvo: I know right? I had to revert --force in one of my commits on this PR so I learned the hard way [15:33] but the current code in the PR is confusing [15:34] well from a user perspective I think this would be more confusing because now `snap run the-snap.the-svc` doesn't always actually run the snap [15:34] snap run doesn't work for service like that [15:34] anyway [15:34] ijohnson: I mean confusing code wise [15:35] 3 people have read and didn't get what was supposed to be going on [15:36] I understand that the code proposal was probably not along the same lines of what has done before, I can clean it up, but in the back of my mind it keeps nagging at me that systemd and snapd are no longer in sync with state [15:37] mvo: so, on later releases, --force doesn't work, but -f does but on earlier releases neither are documented or implemented. anyhoo, no --force for us :) [15:37] ijohnson: as I said, right now I'm holding both possiblities as viable [15:38] mvo: it is surprising with how mature those utilities are, how there are still changes and bugs for simple stuff [15:38] ijohnson: the problem with the code is generally SnapState is an absolute truth or intention about the snap [15:38] and the new field you added is neither [15:38] well in my mind, the new field is an absolute truth, but perhaps the name is wrong [15:39] the field is an absolute statement about the state of the services when the snap was unlinked, to be used when we re-link [15:39] ijohnson: that's the problem, as named you would think it's true also while that snap is active [15:39] but that's not true [15:40] it's not even reset [15:40] atm [15:40] I have more changes in the link-snap that would reset it, but I hadn't decoupled that from the change that actually fixes the bug with this state [15:41] I suppose I could add that change in link-snap to this PR and then rename it to be clear as to what state is being staved in SnapState [15:41] so DisabledServicesAsLastActive might be a better name [15:41] also it likely belongs to SnapState [15:41] and not the one of the SideInfos [15:42] we don't let mess much with a disable snap anyway [15:42] yeah I wasn't sure which one to put it in, SideInfo was the path of least resistance for me [15:43] okay, thanks pedronis I think I'm unblocked on this then I will refactor to make it clearer [15:45] ijohnson: basically it belongs close to the Active flag [15:51] pedronis: is SnapState saved per-revision? it seems like SnapState is saved only once per snap instance, when the state I need to track is per-revision [15:51] ijohnson: is per snap [15:52] why do you think you need to track this per revision? [15:52] well, imagine you have a snap that gets refreshed multiple times and you want to revert back to one of the previous revisions [15:53] each revision could hypothetically have different snap service names [15:54] that also at least handles service renames on revert, since if on rev 1 you have "svc1" and on rev 2 it gets renamed to "svc2", when you get to revision 3 you will only have saved "svc2" and lost the name of "svc1" [15:54] yes, but the service picture is only for the current one [15:54] what do you mean current one? I thought this flag was meant for only non-current snaps? [15:54] s/snaps/snap revisions/ [15:55] I mean you install a snap with svc1 and svc2 [15:55] you refresh it [15:55] same services [15:55] you disable svc2 [15:55] you revert [15:55] you want to keep svc2 disabled [15:55] I guess I didn't think that was a use case we cared about [15:57] I was more worried about: you install a snap with svc1 and svc2, svc2 doesn't work well, so you disable it, you refresh and now svc2 works better, you enable it, but then you revert and don't want to re-enable svc2 because it was broken in the previous revision [15:57] hmm I guess I'm not sure we can handle both cases automatically without choosing one use case over the other or having some kind of flag [15:58] I think, thinking of disable services as per revision [15:58] is a bit "too much" [15:58] I guess from the use case we had on the field team with edgex, it was more important for usability to not automatically re-enable services from previous revisions that were disabled [15:59] because for example on low power hardware you don't want some of those services running because they are resource intensive [15:59] well, disable again and revert after [16:00] hmm [16:00] how would you handle service renames in that situation? I don't think you could [16:01] if there renames is all up to the snap [16:01] or the admin [16:01] notice that if there is not admin [16:01] there is likely no disabled services either [16:01] I think for renames the refresh hook should have a chance to control services [16:01] at least in the per-revision version, you handle svc renames going backwards in time [16:02] zyga: yes the snap will always have post-refresh hook to control services [16:02] the problem is that is unclear that people expect that behavior [16:02] zyga: I just added a spread test to make sure that works/continues to work :-) [16:02] ijohnson: to explain, we have similar problem with connections [16:02] but connections are also not per revision [16:02] slot and plugs can come and go [16:02] hmm right I can see that [16:02] and be renamed [16:03] I guess my expectation is that the snap's hooks can handle renames going forward in time, but snapd should handle renames going backwards in time [16:03] but that's just my expectation [16:04] what do we do with connections on disable/enable? [16:04] they stay [16:05] ijohnson: anywway, what we can do is not reset any disable that has no current matching service [16:05] (that's a bit similar to what we do with manual disconnects) [16:05]