| zyga | mvo: good morning | 06:18 |
|---|---|---|
| zyga | fun test failure | 06:18 |
| zyga | no void directory on core18 https://www.irccloud.com/pastebin/hjyPHGW5/ | 06:18 |
| mvo | zyga: uh, fun indeed | 06:18 |
| mvo | zyga: and easy to fix | 06:18 |
| mvo | zyga: thanks for finding this! | 06:18 |
| zyga | mvo: so | 06:19 |
| zyga | mvo: I have a problem | 06:19 |
| zyga | mvo: how do we fix this? | 06:19 |
| zyga | by hacking core18/ | 06:19 |
| zyga | mvo: can we create a package that is designed for core18-like systems? | 06:19 |
| zyga | mvo: that has the right startup core and mounting points | 06:19 |
| zyga | mvo: I would rather not have this conversation in core20 | 06:20 |
| mvo | zyga: I would add it to the build tree of UC18, this will become the build tree of UC20 | 06:20 |
| zyga | mvo: if we make the right package it will be simply inistalled in core18 systems and that will be enough | 06:20 |
| zyga | mvo: add it how? I'm arguing that it should be a standalone package built out of snapd source package, that is then installed in core18 system | 06:21 |
| mvo | zyga: yeah, it could be snap-skeleton-dirs or something but I'm not sure this is more robust, we might also forgot add things there instead of in the main snapd package just like we could forgot adding things to the UC18/uc20 snaps. or do you have something different in midn? | 06:22 |
| mvo | mind | 06:22 |
| zyga | mvo: we can very well forget but if we fix it the fix goes to core16, core18 and core20 | 06:22 |
| zyga | mvo: in one patch | 06:22 |
| zyga | mvo: and it would be in the snapd repo, not somewhere else | 06:22 |
| mvo | zyga: how would that look like in pratcise? what would the package be called and what would the dependencies be? | 06:24 |
| zyga | mvo: it would not depend on anything but it would conflict with snapd.deb | 06:24 |
| zyga | mvo: the name is irrelevant, maybe snapd-bootstrap-and-skeleton? | 06:24 |
| zyga | mvo: it would ship /var/lib/snapd structure, the /bin/snap symlink, the /usr/lib/snapd mount point and perhaps your bootstrap script | 06:25 |
| zyga | mvo: (anything appropriate) | 06:25 |
| mvo | zyga: it would be separate from the main package snapd which (afaics) has the same risk of getting our of getting out of sync. maybe we pull something from snapd git in to create the dirs/perms and use exactly this in the main snapd package build(s)? | 06:26 |
| zyga | mvo: hmm? | 06:28 |
| zyga | mvo: the snapd source package would have snapd.deb binary package and snapd-skeleton.deb binary (arch all) package | 06:29 |
| zyga | mvo: is that sufficient or do I misundertand your worry? | 06:29 |
| zyga | *misunderstand | 06:29 |
| * zyga preps breakfast for kids, responses may be slower | 06:29 | |
| mvo | zyga: snapd/snapd-skeleton may get out of sync if we are not careful | 06:31 |
| mvo | zyga: because we add a new dir (or something) to snapd but forget to add it to snapd-skeleton | 06:32 |
| mvo | zyga: so we need something that ensures that this can't happen, one way would be to use a makefile/script/whatever as part of the snapd package build and use exactly the same script as part of the uc18/uc20 build | 06:32 |
| mvo | zyga: alternatively we could create some of these missing dirs ourselfs maybe? /var/lib/snapd is fully writable | 06:35 |
| mvo | zyga: (create them if missing) | 06:35 |
| mvo | zyga: I actually like this as it means its easier if people try to run snapd from a snapd git checkout etc (slightly easier I admit :) | 06:35 |
| mborzecki | morning | 06:38 |
| mborzecki | wow, some prs are actually green | 06:40 |
| zyga | hmmm | 06:41 |
| zyga | I'm not sure | 06:41 |
| mborzecki | zyga: hey | 06:41 |
| zyga | this shoud run before snap | 06:41 |
| zyga | before snapd | 06:42 |
| mvo | hey mborzecki | 06:44 |
| mborzecki | mvo: hey | 06:44 |
| mborzecki | zyga: idk if you noticed, but there's quite a few directories missing under /var/lib/snapd between core and core18 | 07:00 |
| mvo | mborzecki: yeah, zyga and I discussed ways to fix this, zyga had some ideas how to make sure we have the layout inside our tree somehow so that its used in uc18/uc20 and we are exploring which one is the best | 07:06 |
| zyga | funny that we noticed just now | 07:14 |
| mborzecki | in most cases those are created on demand | 07:14 |
| mvo | yeah, I think on demand-creation is a nice way out of this | 07:15 |
| mvo | and it has the advantage of making it easy to run from e.g. checkouts | 07:15 |
| mvo | but *shrug* there are downsides too | 07:16 |
| zyga | mvo: I don't disagree in principle but not everything can be created on demand | 07:16 |
| mborzecki | iirc void has some special permissions too, so this would have to be accounted for when we create it on the fly | 07:16 |
| zyga | mborzecki: can you do a 2nd review on https://github.com/snapcore/snapd/pull/6645 please? | 07:19 |
| mborzecki | haha looking at it just now :) | 07:19 |
| zyga | thank you :) | 07:19 |
| zyga | I want the rush of adrenalin from landing a PR | 07:19 |
| mborzecki | still, suprising usb.ids doesn't list oneplus | 07:20 |
| zyga | maybe it's a fake request? | 07:20 |
| mborzecki | zyga: no, i found some pages describing the process of getting oneplus working on linux and they list the same vendor id | 07:20 |
| zyga | aha, that's a good find | 07:21 |
| * zyga reviews https://github.com/snapcore/snapd/pull/6634 | 07:21 | |
| mvo | mborzecki: silly question - what is needed for 6606 ? a second review or is there more ? | 07:23 |
| mborzecki | mvo: 2nd review | 07:24 |
| mborzecki | zyga: added some links under 6645 in case you're curious, there's even a patch from lineageos | 07:26 |
| zyga | mborzecki: looking | 07:26 |
| mvo | mborzecki: thanks, maybe pstolowski can do a second review on 6606, it looks pretty much ready to me | 07:27 |
| mvo | mborzecki: added my .0002¢ I think its fine but would feel better if pstolowski could do a final pass on 6606 | 07:31 |
| mborzecki | mvo: thanks! | 07:31 |
| zyga | brb, coffee | 07:47 |
| zyga | https://github.com/snapcore/snapd/pull/6597 <- 2nd review needed in case someone wants to look | 07:48 |
| mvo | just a quick service announcement - we have an updated systemd in the edge core with a race fix, if anyone notices anything strange in the tests related to systemd please shout | 07:48 |
| mvo | zyga: I can look | 07:48 |
| zyga | mvo: thank you | 07:50 |
| zyga | mvo: alternatively look at https://github.com/snapcore/snapd/pull/6621/files | 07:50 |
| zyga | it's much smaller | 07:50 |
| zyga | and more on the critical path | 07:50 |
| zyga | mvo: ack, about systemd, thank you for that! | 07:50 |
| mvo | zyga: ha! thanks, I take 6621 I think :) | 07:50 |
| mvo | zyga: the other one is *big* it seem | 07:51 |
| mvo | zyga: hopefully both, but for that I need more tea | 07:51 |
| zyga | yeah, this one is very small, just tests and a few lines of new code | 07:51 |
| mvo | pedronis: do you want to review 6630 again (snap warnings yamlish) or can I merge? john addressed your review points | 07:59 |
| pstolowski | morning | 08:03 |
| mvo | pstolowski: good morning! | 08:05 |
| mborzecki | pstolowski: heya | 08:05 |
| * dot-tobias says hi | 08:35 | |
| pedronis | mvo: hi, please merge | 08:36 |
| mvo | pedronis: ta | 08:38 |
| abeato | ppisati, morning! | 09:09 |
| abeato | ppisati, which is the apparmor status for 4.9 kernels? Is there any patch needed to run ubuntu core/snapd with it? | 09:09 |
| ppisati | abeato: not that i'm aware | 09:11 |
| zyga | mvo I will merge 6605 after adding the extra comment | 09:12 |
| ppisati | abeato: *none, that i'm aware of | 09:12 |
| zyga | mvo: just wrapping up a small new branch you asked for | 09:12 |
| zyga | mvo: thank you for the review! | 09:12 |
| abeato | ppisati, ok, thanks | 09:14 |
| pstolowski | pedronis: i've debugged the ssh.disabled issue | 09:16 |
| mvo | zyga: ta | 09:18 |
| pstolowski | pedronis: we don't support dotted notation at the nested level of the defaults definition, we expand dotted path at the root level only, e.g. that would work (works in a unit test i made): | 09:23 |
| pstolowski | defaults: | 09:23 |
| pstolowski | test-snap-ididididididididididid: | 09:23 |
| pstolowski | service.ssh.disabled: true | 09:23 |
| pedronis | pstolowski: it sounds like we should error or do something though ? | 09:24 |
| pedronis | we don't support dots in name in principle? | 09:24 |
| pedronis | pstolowski: where is ther relevant code? | 09:24 |
| pstolowski | pedronis: and consequently, with the config that Sergio created you end up with unexpanded key in the config: map[string]interface {}{"ssh.disabled":true} | 09:24 |
| pedronis | yea, that looks wrong | 09:25 |
| pstolowski | pedronis: also, this works fine in unit test: | 09:26 |
| pstolowski | defaults: | 09:26 |
| pstolowski | test-snap-ididididididididididid: | 09:26 |
| pstolowski | service: | 09:26 |
| pstolowski | ssh: | 09:26 |
| pstolowski | disabled: true | 09:26 |
| pedronis | that I know | 09:27 |
| pstolowski | pedronis: we do support dots in name, but it needs to start at the root level. you cannot define map and then have dotted path deep inside | 09:27 |
| pedronis | pstolowski: I understand, you said it already | 09:27 |
| pstolowski | and yes we should error out i suppose | 09:28 |
| pedronis | yes, "ssh.disabled" should't be a valid key | 09:28 |
| pedronis | we should not get there | 09:28 |
| pstolowski | let me see if i can find where it happens exactly in the code | 09:28 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/6650 :-) | 09:34 |
| pedronis | zyga: shouldn't we try to land 6583 first? | 09:36 |
| pstolowski | pedronis: i think the important bit is the "for key, value := range patch" loop in func (h *configureHandler) Before(). we call tr.Set there for top-level patch entries, but inside transaction's Set we only ParseKey once (for that top level) | 09:39 |
| pedronis | pstolowski: so we are missing a check for dots in key (where unexpected) somewhere? | 09:40 |
| zyga | pedronis: I will be working on that today | 09:42 |
| pedronis | zyga: you have 17 open PRs , that's not a feature :) | 09:42 |
| zyga | pedronis: I know but many of them are very close to landing | 09:43 |
| pedronis | zyga: then please try to land before opening new ones | 09:43 |
| pedronis | or I will start to close new ones | 09:43 |
| zyga | pedronis: with regards to landing: we need a decision on what to do here https://github.com/snapcore/snapd/pull/6642#discussion_r268780713 | 09:44 |
| pedronis | zyga: I agree with jdstrand if there's a way to keep it working without security issues it's better, we have been bitten already by taking stuff away from people | 09:46 |
| zyga | pedronis: so moving to void if we cannot stay in the current directory due to permission checks? | 09:46 |
| pedronis | yes | 09:47 |
| zyga | ok, I'll make the change | 09:47 |
| zyga | thanks, can you add a comment saying that in the PR, it will be easier for jamie to see | 09:47 |
| pedronis | done | 09:48 |
| zyga | Thanks | 09:48 |
| pstolowski | pedronis: yes, you could say that. i think we could support that in PatchConfig, although the fix is not immediately obvious | 09:53 |
| pedronis | pstolowski: anyway is not quite a priority right now, but we should plan to do something at some point | 09:54 |
| pstolowski | pedronis: ack | 09:54 |
| pedronis | pstolowski: I'm also not sure if it's better to error or to make it work | 09:54 |
| pedronis | (but splitting on dot9 | 09:54 |
| pedronis | (by splitting on dots) | 09:54 |
| pedronis | mvo: do we use the standup ? | 09:59 |
| zyga | pedronis: https://github.com/snapcore/snapd/pull/6649 is a low hanging fruit | 09:59 |
| pedronis | ok | 10:00 |
| pedronis | degville: do you know where the meeting is? | 10:03 |
| degville | pedronis: nope. standup location? mvo is running a little late. | 10:03 |
| === chihchun_afk is now known as chihchun | ||
| zyga | https://forum.snapcraft.io/t/ubuntu-18-04-fresh-install-default-snaps-are-updated-but-runtime-isnt/10579 this is interesting in a bad way | 10:24 |
| mborzecki | damn, Failed for "golang.org/x/crypto/cast5" (failed to clone repo): exit status 128 | 10:25 |
| mborzecki | shal we land https://github.com/snapcore/snapd/pull/6623 ? | 10:27 |
| pedronis | mborzecki: seems so | 10:29 |
| mborzecki | it's sufficiently ripe :) | 10:29 |
| pedronis | it has a jdstrand +1 and other reviews | 10:30 |
| pedronis | at some point it sounded it needed to touch snap-confine, but is not the case | 10:30 |
| mborzecki | landed | 10:31 |
| zyga | eh | 10:34 |
| zyga | my tests also failed | 10:35 |
| zyga | 50 minutes of wasted time | 10:35 |
| zyga | fatal: unable to access 'https://go.googlesource.com/crypto/': Failed to connect to 2607:f8b0:400c:c06::52: Network is unreachable | 10:35 |
| zyga | this is why we need spread --fail-fast | 10:35 |
| zyga | this just sucks | 10:35 |
| * Chipaca hates all of the interfaces-many- spread tests | 11:11 | |
| pstolowski | zyga: +1 | 11:13 |
| niemeyer | mup_: So.. what's up with you? | 11:16 |
| niemeyer | mup: How're you doing now? | 11:24 |
| mup | niemeyer: I apologize, but I'm pretty strict about only responding to known commands. | 11:24 |
| mborzecki | 2019-03-26 10:33:46 Cannot allocate google:debian-sid-64: cannot perform Google request: Get https://www.googleapis.com/compute/v1/projects/computeengine/zones: oauth2: cannot fetch token: Post https://accounts.google.com/o/oauth2/token: dial tcp 74.125.126.84:443: i/o timeout | 11:51 |
| mborzecki | hmmm | 11:51 |
| mborzecki | gcp broke? | 11:52 |
| Chipaca | mborzecki: nevah! | 12:05 |
| Chipaca | also, spread takes too long, so: while true; do printf "\u$(printf "%x" $((0x2571 + RANDOM%2)))"; done | 12:05 |
| mborzecki | heh, and i got into a little mess with the 'gadget' package, some code is on review right now, and merging the branches breaks all of it :P | 12:07 |
| mborzecki | aand another job hit the time limit | 12:08 |
| mborzecki | it's quite intersting, so prepare fails on some nodes because golang.org is flaky and times out, then the nodes that actually made it execute all the tests and the job hits travis time limits | 12:09 |
| mborzecki | maybe it's because of https://twitter.com/MehreenKhn/status/1110509604176384000 | 12:14 |
| * zyga goes to the doctor | 12:19 | |
| zyga | ttyl | 12:19 |
| mup | PR snapcraft#2515 closed: build providers: support for provider setup <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2515> | 12:22 |
| Chipaca | mvo: question about the snapd snap when you have a bit | 12:24 |
| cachio | pstolowski, https://api.travis-ci.org/v3/job/511064184/log.txt | 12:25 |
| Chipaca | mvo: the question is whether building with snapcraft from the snap (instead of from the deb), and adding -b -Zgzip to the dpkg-buildpackage in the plugin, make sense to you | 12:25 |
| cachio | this is the log for the ssh.disable: true | 12:25 |
| Chipaca | mvo: the first is because otherwise it leaves behind a bunch of packages that break the invariant | 12:25 |
| Chipaca | mvo: the second is because 300s → 90s | 12:26 |
| Chipaca | mvo: (I could just change the first, the second is merely opportunistic) | 12:26 |
| pstolowski | cachio: i know, i debugged it in the morning and discussed with pedronis; we don't currently support dotted paths nested deep inside defaults; it would work only from top-level, e.g. service.ssh.disabled: true. we should at the very least provide a meaningful error message or make it smarter | 12:30 |
| mvo | Chipaca: +1 on the second, I'm not fully getting the first one, sorry (probably a bit slow today) | 12:32 |
| pstolowski | cachio: btw i think it found the cause of interfaces-daemon-notify failure in my nested vm PR; i think it fails because of "plan: n1-standard-2" (?!); i run this single test a couple of times today with and without this change (also with just master) and it seems to be it. if that plan is enabled, then "journalctl -u snap.test-snapd-daemon-notify.notify.service" that we execute at the end of the test doesn't return any | 12:34 |
| pstolowski | output for that service. i debugged this manually and when it fails, system log has the expected "Permission denied" errors in it, it's just not reported by journalctl for whatever reasons. systemd/journalctl versions appear to be the same both with and without that plan. | 12:34 |
| pstolowski | i've juse reverted this plan from https://github.com/snapcore/snapd/pull/6491 and it passed | 12:35 |
| mup | PR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491> | 12:35 |
| pstolowski | pedronis: ^ is green | 12:36 |
| pedronis | cachio: I'll comment in the PR when I have a bit of time today | 12:36 |
| pedronis | (about ssh.disable) | 12:36 |
| Chipaca | mvo: only builds the binary deb, uses gzip to compress it (instead of also building source and using xz) | 12:36 |
| Chipaca | mvo: oh wait | 12:36 |
| Chipaca | mvo: the first one, changing deb for snap, because 'apt install snapcraft" pulls in e.g. python3-crypto, which autoremove can't | 12:37 |
| Chipaca | can't autoremove i mean | 12:37 |
| Chipaca | because things recommend it or maybe suggest it i guess | 12:37 |
| cachio | pstolowski, which is the PR? | 12:37 |
| mvo | Chipaca: +1 | 12:37 |
| cachio | pedronis, thanks | 12:37 |
| mvo | Chipaca: oh, so "snap install snapcraft"? | 12:38 |
| Chipaca | mvo: yar | 12:38 |
| pstolowski | cachio: #6491 | 12:38 |
| mvo | Chipaca: this is the change? if so, yes, lets do it | 12:38 |
| Chipaca | ok | 12:38 |
| mup | PR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491> | 12:38 |
| mvo | Chipaca: thank you! I think htis is just old code from the time when we had no snap (ironically) | 12:38 |
| Chipaca | mvo: it'll be part of the invariant pr unless you'd rather it went in alone | 12:38 |
| mvo | Chipaca: and nice idea on the dpkg-buildpackage one | 12:38 |
| pstolowski | cachio: can you think on any reason why this more performant plan makes that test fail? any difference in the images? | 12:38 |
| mvo | Chipaca: fine for me | 12:38 |
| Chipaca | k | 12:38 |
| mvo | Chipaca: its not a big change :) | 12:38 |
| mvo | Chipaca: thank you! | 12:38 |
| cachio | pstolowski, did you change the plan? | 12:40 |
| cachio | I didn't see that | 12:40 |
| pstolowski | cachio: yes i reverted that change innym PR to make it pass | 12:58 |
| pstolowski | cachio: see last commit | 12:58 |
| pstolowski | cachio: just apply it on master and it should fail the interfaces-daemon-notify test | 13:00 |
| mup | PR snapd#6651 opened: tests: all the systems for google backend with 6 workers <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6651> | 13:00 |
| * zyga off to the doctor | 13:01 | |
| * Chipaca off to have lunch | 13:02 | |
| Chipaca | zyga: lunch > doctor | 13:02 |
| * Chipaca wins | 13:02 | |
| cachio | pstolowski, mmmm, ok | 13:03 |
| cachio | pstolowski, we can't change the plan | 13:03 |
| zyga | What is the status of spread / cloud? | 13:05 |
| zyga | Did we run out of money? | 13:05 |
| === ricab is now known as ricab|lunch | ||
| pstolowski | cachio: hmm hey not? How Is It affecting 14.04? | 13:08 |
| mup | PR snapd#6606 closed: selinux, systemd: support mount contexts for snap images <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6606> | 13:12 |
| mborzecki | zyga: do you want to take a look at https://github.com/snapcore/snapd/pull/6485 ? | 13:13 |
| mup | PR #6485: interfaces/seccomp: regenerate changed profiles only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485> | 13:13 |
| dot-tobias | jdstrand: Is there a way to force an NTP resync using the timezone-control DBus interface? https://www.freedesktop.org/wiki/Software/systemd/timedated/ indicates that SetNTP() method restarts systemd-timedated, but timedatectl still reports “NTP in sync: no”. Use case: Our device is offline until configured via an access point, so the device is booting without network. System does not seem to pick up the available network connection in the | 13:29 |
| dot-tobias | minutes after its established. | 13:29 |
| zyga | back from doctor | 13:32 |
| zyga | bikes are amazing :) | 13:32 |
| zyga | mborzecki: sure, looking | 13:32 |
| * Chipaca ⇝ cuppa | 13:56 | |
| mup | PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38> | 14:00 |
| mup | PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83> | 14:00 |
| mup | PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38> | 14:01 |
| mup | PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83> | 14:01 |
| jdstrand | dot-tobias: I'm not an expert on timedated. If I were to guess, I'd guess the clock is maybe too far off or that your device is unable to communicate with the configured server. you might also check your logs for policy violations, but it sounds like timedatectl is working ok and it is something else | 14:05 |
| dot-tobias | jdstrand: Yes, the clock was off > 12h because that's the time when the image was created. Didn't know that in order to sync the clock has to be near the actual date. Will look into workarounds how to get in re-sync. | 14:07 |
| dot-tobias | jdstrand: Thanks! | 14:07 |
| mup | PR snapd#6329 closed: cmd/snap-confine, packaging: support SELinux <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6329> | 14:08 |
| jdstrand | dot-tobias: cool. ogra may have some thoughts on that as well | 14:11 |
| zyga | hey jdstrand :) | 14:14 |
| zyga | jdstrand: I'm glad you noticed "goto the void" :-) | 14:14 |
| zyga | initially it was an else statement but then it was too good to pass :-) | 14:14 |
| jdstrand | zyga: hey, yeah :) | 14:17 |
| zyga | :-) | 14:17 |
| zyga | jdstrand: we also managed to uncover that core18 is missing some directories in that test, it's better late than never | 14:17 |
| jdstrand | zyga: I saw that, wild :) | 14:18 |
| zyga | jdstrand: I implemented the next branch but I will defer until my set of open PRs shrinks sufficiently | 14:21 |
| zyga | jdstrand: btw, not sure if you saw https://github.com/snapcore/snapd/pull/6649 | 14:21 |
| mup | PR #6649: snap: reject layouts to /lib/{firmware,modules} <Created by zyga> <https://github.com/snapcore/snapd/pull/6649> | 14:21 |
| === ricab|lunch is now known as ricab | ||
| mup | PR snapd#6652 opened: sanity: use proper SELinux mount context when sanity checking squashfs mounts <SELinux> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6652> | 14:49 |
| * zyga -> tea / coffee | 14:50 | |
| mborzecki | super simple selinux PR ^^ | 14:51 |
| ogra | zyga, mvo, do you gys know if anyone actually tested pi core18 images with wlan ? seems i dont get proper DNS resolution to finish console-conf here (network is up and i can ping the board but user creation times out with DNS issues finding the login.u.c api stuff) | 15:06 |
| ogra | this is with the stable released image... | 15:07 |
| mvo | ogra: I'm not sure we did, sorry. is this the dragonboard or pi3? | 15:08 |
| ogra | jdstrand, in case dot-tobias comes back while i'm not around ... https://github.com/ogra1/ntpcontrol | 15:08 |
| mvo | ogra: or both? | 15:08 |
| ogra | mvo, pi image on a pi 3 A+ | 15:08 |
| ogra | core 16 works fine | 15:09 |
| ogra | (i resorted to that in the end) | 15:09 |
| mvo | ogra: we need to look into this, in a meeting now unfortunately | 15:12 |
| ogra | mvo, all fine, just wanted to check if it was tested before | 15:13 |
| ogra | i also resoted to core16 for the project i needed the board for ... but i have another A+ for any tests if required | 15:13 |
| mvo | ogra: added to test/debug this to our trello, thanks for reporting | 15:18 |
| mup | PR snapd#6649 closed: snap: reject layouts to /lib/{firmware,modules} <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6649> | 15:22 |
| === cwayne_ is now known as cwayne | ||
| * cachio lunch | 15:34 | |
| cwayne | ogra: sorry if this message is doubled, my ircs been weird but we do test wlan on Pi's, but using nm | 15:35 |
| ogra | well, that wont help much if NM isnt preinstalled :P | 15:35 |
| ogra | (also ... does console-conf actually support NM ??) | 15:35 |
| === chihchun is now known as chihchun_afk | ||
| niemeyer | cachio: spread#75 reviewed again | 16:13 |
| mup | PR spread#75: Make spread tests for spread project run on google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/75> | 16:13 |
| mup | PR snapcraft#2516 opened: readme: add snap store badge <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2516> | 16:17 |
| zyga | s pedronis renamed https://github.com/snapcore/snapd/pull/6621 | 16:19 |
| mup | PR #6621: overlord/snapstate: track time of postponed refreshes <Created by zyga> <https://github.com/snapcore/snapd/pull/6621> | 16:19 |
| zyga | pedronis: to "inhibit" | 16:20 |
| zyga | it is green so I'm very tempted to merge it :) | 16:20 |
| zyga | everyone: I need 2nd review for https://github.com/snapcore/snapd/pull/6597 | 16:20 |
| mup | PR #6597: cmd/snap-update-ns: refactor of profile application (1/N) <Created by zyga> <https://github.com/snapcore/snapd/pull/6597> | 16:20 |
| pedronis | zyga: it doesn't have 2 +1 | 16:20 |
| zyga | pedronis: I know :) | 16:20 |
| zyga | that's why I'm saying | 16:20 |
| zyga | if that was your only reservation I'd love to get a 2nd one | 16:20 |
| pedronis | zyga: I asked Chipaca to review it | 16:21 |
| zyga | great, I'll wait for the review then | 16:22 |
| pedronis | Chipaca: could you look at #6621 | 16:22 |
| mup | PR #6621: overlord/snapstate: track time of postponed refreshes <Created by zyga> <https://github.com/snapcore/snapd/pull/6621> | 16:22 |
| pedronis | when you have time | 16:22 |
| Chipaca | yes | 16:22 |
| cachio | niemeyer, thanks | 16:40 |
| ijohnson | fyi to anybody using the go remote part, I just updated it in the wiki, so if anything breaks ping me | 16:41 |
| zyga | thank you ijohnson | 16:41 |
| Chipaca | huh | 16:42 |
| zyga | Chipaca: hmm? | 16:43 |
| Chipaca | zyga: what permissions should snap-confine have? | 16:43 |
| zyga | Chipaca: as in UNIX? | 16:43 |
| Chipaca | zyga: ye | 16:43 |
| zyga | for now u+rwXs,g+rXs,o:+rX | 16:44 |
| zyga | though I will drop the g+S part | 16:44 |
| zyga | why? | 16:44 |
| Chipaca | zyga: because it starts at 06755, as you say | 16:45 |
| Chipaca | zyga: but snap-confine-from-core sets it to 04755 | 16:45 |
| zyga | wait, what? | 16:45 |
| zyga | why? | 16:45 |
| * zyga hugs Chipaca for fixing the tests | 16:45 | |
| Chipaca | restore: | | 16:46 |
| Chipaca | echo "Restoring host snap-confine" | 16:46 |
| Chipaca | chmod 4755 /usr/lib/snapd/snap-confine | 16:46 |
| Chipaca | zyga: ^ | 16:46 |
| zyga | la la la | 16:46 |
| zyga | man | 16:47 |
| zyga | ... | 16:47 |
| zyga | what just happened | 16:47 |
| zyga | I spent 10 minutes debugging | 16:47 |
| zyga | why snapd doesn't build | 16:47 |
| zyga | on ... macos | 16:47 |
| Chipaca | zyga: snap does :-) but not snapd :-( | 16:47 |
| zyga | wrong terminal tab on a common shared source | 16:47 |
| zyga | lol | 16:47 |
| * Chipaca is still happy that snap does :-) | 16:47 | |
| zyga | I aborted a rebase in progress because I got fed up with this and wanted to think why everything is broken | 16:47 |
| Chipaca | zyga: what was it telling you wasn't implemented? | 16:48 |
| zyga | /Users/zyga/go/src/github.com/snapcore/snapd/interfaces/mount/backend.go:97:84: undefined: osutil.MountEntry | 16:48 |
| zyga | I totally ignored the path | 16:49 |
| * Chipaca nods | 16:50 | |
| mborzecki | fwiw there was this crazy linux distro that didn't use the usual / layout, they could have had /User too | 16:51 |
| Chipaca | it's just noise | 16:51 |
| Chipaca | noise][1: no offense | 16:51 |
| Chipaca | :-) | 16:51 |
| zyga | mborzecki: yeah, I used it once | 16:51 |
| zyga | it had /Users and /Applications like on macos | 16:51 |
| pedronis | mborzecki: I did a pass over the gadget validation PR | 16:53 |
| mborzecki | pedronis: thanks, sorry for it being so long | 16:54 |
| pedronis | mborzecki: we'll need another layer of validation that looks at actual content for sizes as well? | 16:55 |
| mborzecki | pedronis: yes, that will need to access actual snap data | 16:55 |
| pedronis | ok | 16:56 |
| pedronis | zyga: are you waiting for review from me on anything but #6642 atm ? | 17:02 |
| mup | PR #6642: cmd/snap-confine: prevent cwd restore permission bypass <Created by zyga> <https://github.com/snapcore/snapd/pull/6642> | 17:02 |
| zyga | checking | 17:02 |
| zyga | we need to look at https://github.com/snapcore/snapd/pull/6583 | 17:03 |
| mup | PR #6583: cmd/snap-confine: move ubuntu-core fallback checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6583> | 17:03 |
| zyga | but perhaps tomorrow morning | 17:03 |
| pedronis | I'm not entirely happy with the code I saw the there the last time I looked | 17:03 |
| pedronis | we can chat tomorrow | 17:03 |
| zyga | today I want to finish mending existing branches that I know what needs to happen wiht | 17:03 |
| zyga | ok | 17:03 |
| pedronis | I'll try to still look at 6642 tonight | 17:04 |
| zyga | thank you! | 17:05 |
| zyga | it should go green once I fix core18 later today | 17:05 |
| mup | PR snapcraft#2516 closed: readme: add snap store badge <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2516> | 17:05 |
| mup | PR snapd#6485 closed: interfaces/seccomp: regenerate changed profiles only <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6485> | 17:13 |
| Chipaca | zyga: how is having RefreshInhibitedTime be zero on success useful? | 17:13 |
| zyga | it is useful because that is correct | 17:13 |
| zyga | we had refreshed | 17:13 |
| zyga | whee | 17:13 |
| zyga | kill the inhibit time value, if we had any set | 17:13 |
| zyga | next time when refresh is inhibited we can check for non-zero inhibit time | 17:14 |
| zyga | and if the time of initial inhibition goes beyond certain duration | 17:14 |
| Chipaca | hold on | 17:14 |
| zyga | we can take action (kill apps etc) | 17:14 |
| Chipaca | if the refresh wasn't inhibited, the task will be Done | 17:15 |
| zyga | and? | 17:15 |
| Chipaca | zyga: currently, if a refresh is inhibited, the task doesn't reach Done, right? | 17:17 |
| zyga | it's not implemented in this branch but something along those lines, correct | 17:17 |
| zyga | we don't get to create those tasks in some cases | 17:17 |
| zyga | things just bail out early | 17:17 |
| zyga | sometimes we will create tasks and bail out late | 17:18 |
| Chipaca | zyga: where do you track the inhibited time when you don't create the task? | 17:18 |
| zyga | it's in the snap state all along | 17:18 |
| zyga | it's not tracked in tasks | 17:18 |
| zyga | the one in tasks is just for undo handler | 17:18 |
| zyga | Chipaca: does it make sense? | 17:22 |
| Chipaca | zyga: if you don't create the task, won't the refresh by retried much much later than intended? | 17:22 |
| Chipaca | zyga: why would you not download the snap i mean | 17:23 |
| mup | PR snapd#6646 closed: interfaces/adb-support: account for hubs on sysfs path <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6646> | 17:23 |
| Chipaca | zyga: but yes, the code makes sense now, I somehow thought you were keeping it in the task (d'oh) | 17:23 |
| Chipaca | I didn't realie this was super-task | 17:23 |
| zyga | Chipaca: initially not creating the tasks is the easy way out | 17:23 |
| Chipaca | I'm not sure how that works though (hence my last question) | 17:24 |
| zyga | Chipaca: I will download the revision as an update to that flow | 17:24 |
| zyga | Chipaca: but I want to have the basic version in first | 17:24 |
| zyga | Chipaca: I will use the soft check (in another PR) to determine if we create tasks or not | 17:24 |
| zyga | Chipaca: then the hard check after stopping services to see if we abort or not | 17:25 |
| Chipaca | after stopping services? | 17:25 |
| zyga | Chipaca: then if soft or hard checks go over $MAGIC_DURATION we carry on regardless | 17:25 |
| zyga | Chipaca: ah, sorry, before | 17:25 |
| Chipaca | ah | 17:25 |
| zyga | (in this model it is before) | 17:25 |
| zyga | no, no wait | 17:25 |
| zyga | after | 17:25 |
| zyga | yeah, I was right the first time | 17:26 |
| zyga | we do a hard check after stopping services because this is the moment we can migrate the data safely | 17:26 |
| zyga | though I may be tired and talk nonsense, that part is not proposed yet and I haven't ran it in weeks | 17:26 |
| pstolowski | pedronis: zyga can we land https://github.com/snapcore/snapd/pull/6491 ? | 17:29 |
| mup | PR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491> | 17:29 |
| Chipaca | buuuuh, github is being silly | 17:30 |
| zyga | pstolowski: looking | 17:31 |
| Chipaca | zyga: I tried to +1 with a "blocked" tag, but github isn't letting me | 17:31 |
| Chipaca | zyga: so I set it to 'changes requested', because i do request changes in fact, but my bigger concern is not landing it before the pr that uses it is ready to land | 17:32 |
| zyga | Chipaca: why is that a concern? | 17:32 |
| Chipaca | zyga: because without that, it's just cruft :) | 17:32 |
| zyga | I wanted to land this deliberately before so that in case someone turns the feature off the data in state is correct | 17:32 |
| Chipaca | it does nothing useful on its own | 17:32 |
| Chipaca | ? | 17:33 |
| Chipaca | wat | 17:33 |
| zyga | when the rest of the code lands that new chunk will be behind a feature flag | 17:33 |
| zyga | but that's fine, it can land later | 17:33 |
| Chipaca | zyga: what in the state would be incorrect if somebody enabled and then disabled this? | 17:34 |
| === pstolowski is now known as pstolowski|afk | ||
| zyga | Chipaca: if this ships but the rest is in edge, going to stable will give you correct state | 17:34 |
| zyga | Chipaca: though I agree it's a bit silly and not strictly tied to the follow up branch being present | 17:35 |
| Chipaca | zyga: if that is a concern, you need an epoch | 17:35 |
| zyga | Chipaca: I will work on the follow up as soon as the hard/soft branch lands | 17:35 |
| zyga | Chipaca: no, it's not a concern, just pedantry | 17:35 |
| Chipaca | zyga: what happens if they enable this, get the flag in state, go back to stable, time passes, and they get the feature? | 17:36 |
| Chipaca | zyga: and they had something inhibited when they went back to stable | 17:37 |
| Chipaca | what happens then | 17:37 |
| zyga | if the inhibit time is zero | 17:37 |
| zyga | nothing | 17:37 |
| zyga | if they had some value they may get a forced refresh if it goes over 90 days or something similar | 17:37 |
| Chipaca | doesn't sound too bad. OTOH you could zero them in a subpatch | 17:38 |
| Chipaca | ? | 17:38 |
| zyga | yeah | 17:39 |
| zyga | once we enable the feature perhaps/ | 17:39 |
| zyga | Chipaca: fixed, thank you | 17:46 |
| zyga | pstolowski|afk: I will review it again, sorry for the lagg | 17:46 |
| mup | PR snapd#6653 opened: tests: try to be a little bit invariant <Created by chipaca> <https://github.com/snapcore/snapd/pull/6653> | 18:04 |
| === chrisccoulson_ is now known as chrisccoulson | ||
| om26er | Is this channel still connected to Slack ? if so, what technology is used for the bridge ? | 19:17 |
| mup | PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10> | 19:25 |
| mup | PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11> | 19:25 |
| mup | PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10> | 19:26 |
| mup | PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11> | 19:26 |
| zyga | om26er: I don't believe it ever was | 19:27 |
| om26er | zyga, ok, I think I confused it with another channel | 19:27 |
| zyga | jdstrand: please enqueue https://github.com/snapcore/snapd/pull/6605 if you have some time, it has 2 +1s and just needs your review | 20:22 |
| mup | PR #6605: cmd/libsnap,osutil: fix parsing of mountinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/6605> | 20:22 |
| juliank | hmm, how does snapctl work? | 21:27 |
| juliank | sudo snapctl stop radicale | 21:27 |
| juliank | error: error running snapctl: cannot stop without a context | 21:27 |
| juliank | $ sudo snapctl services | 21:27 |
| juliank | error: error running snapctl: cannot query services without a context | 21:27 |
| ijohnson | juliank: are you using snapctl outside of a snap? | 21:27 |
| juliank | ah, it's just for use by snaps? | 21:28 |
| ijohnson | it's only usable inside a snap | 21:28 |
| juliank | it should maybe say so :) | 21:28 |
| ijohnson | outside of a snap you should just use `snap` | 21:28 |
| ijohnson | i.e. snap stop radicale | 21:28 |
| juliank | So I did sudo snap stop --disable radicale.daemon | 21:30 |
| juliank | will that persist after an upgrade of the snap? | 21:30 |
| ijohnson | it is supposed to but there's currently a bug where refreshes always re-enable services | 21:30 |
| juliank | Because with my local testing snap, if I do snap install my.snap --dangerous, it would override it :) | 21:30 |
| juliank | hmm | 21:31 |
| juliank | that's suboptimal | 21:31 |
| ijohnson | see https://bugs.launchpad.net/snapd/+bug/1818306 | 21:31 |
| mup | Bug #1818306: disabled daemons are started after refresh <snapd:New> <https://launchpad.net/bugs/1818306> | 21:31 |
| juliank | I'm thinking about running radicale for caldav/carddav on my server, so I sanpped the current version - but I don't wanna run the daemon as root (even in strict confinement), so I wanted to disable the daemon and just run it as a user program (well, from a systemd service) | 21:32 |
| juliank | I do want to ship the daemon because duh, that's more useful for the store :) | 21:33 |
| ijohnson | how would you run it as a user program from a systemd service? | 21:33 |
| juliank | I don't know, I have not tried yet | 21:33 |
| juliank | Exec=/snap/bin/radicale I guess? | 21:34 |
| juliank | with User=radicale | 21:34 |
| ijohnson | hmm I guess that would probably work | 21:34 |
| ijohnson | there is upcoming snapd work that would allow the daemon to drop from root to a specific "daemon" user instead, but that's not done yet | 21:34 |
| juliank | it would confine it to access to ~radicale/snap/common instead of /var/snap/radicale/common, but that's fine | 21:35 |
| juliank | (it's a strict snap :D) | 21:35 |
| juliank | ijohnson: I read about that | 21:36 |
| juliank | (the only plug it needs is network-bind :D) | 21:37 |
| * cachio afk | 21:37 | |
| jdstrand | zyga: ack | 22:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!