| mborzecki | morning | 05:00 |
|---|---|---|
| zyga | Gry | 06:27 |
| zyga | Hey | 06:27 |
| mborzecki | zyga: hey | 06:30 |
| mborzecki | zyga: can you look at #5421 there's something fishy there | 06:31 |
| mup | PR #5421: tests: replace MATCH by grep to check users created for ubuntu core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5421> | 06:31 |
| zyga | Yeah, in a moment. Barely waking up here | 06:31 |
| zyga | We found a curious bug last night | 06:32 |
| mborzecki | zyga: what curious bug? | 06:42 |
| mborzecki | this one? | 06:42 |
| zyga | First coffee | 06:42 |
| zyga | I stopped working after 10PM again | 06:42 |
| mvo | zyga: good morning! | 06:43 |
| mvo | zyga: how can I help :) | 06:43 |
| mborzecki | mvo: hey | 06:44 |
| zyga | Hey :-) | 06:44 |
| mvo | hey mborzecki | 06:44 |
| zyga | All good just need to wake fully | 06:44 |
| zyga | And we have a small patch to unbreak snappy in lxd | 06:44 |
| zyga | I will send it in 20 minutes, just need to clean the kitchen to make the coffee | 06:45 |
| mborzecki | coffee, splendid idea | 06:45 |
| mvo | 5419 is probably an easy win, has one review already and looks pretty straightforward | 06:46 |
| mborzecki | zyga: btw. that's my kde bug that caused no sound in hangouts: https://www.mail-archive.com/kde-bugs-dist@kde.org/msg249018.html | 06:46 |
| mvo | pstolowski|afk: good morning! when you have a chance, please check 5415, zyga has one suggestion there about the comment otherwise it is good to go (has two +1 etc) | 06:49 |
| zyga | re | 06:50 |
| zyga | ok, finally at the keyboard | 06:50 |
| zyga | mvo: looking | 06:50 |
| zyga | mvo: would you mind reviewing the apparmor change I sent a few days ago? | 06:51 |
| zyga | I'll get a 2nd review from jamie | 06:51 |
| mvo | zyga: sure, I'm just going over the list sequentially | 06:52 |
| zyga | mvo: going back to front helps in making sure we don't starve old PRs | 06:52 |
| mvo | 5409 is probably a super simple review btw | 06:54 |
| mvo | zyga: yeah, good point | 06:54 |
| mup | PR snapd#5404 closed: i18n: add canary checking to pot file extraction <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5404> | 06:56 |
| mup | PR snapd#5419 closed: many: switch to account validation: unproven|verified <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5419> | 06:57 |
| zyga | pedronis: https://github.com/snapcore/snapd/pull/5419#discussion_r198725202 (when you are around) | 06:58 |
| mup | PR #5419: many: switch to account validation: unproven|verified <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5419> | 06:58 |
| zyga | mvo: ^ | 06:59 |
| pedronis | zyga: ? | 07:00 |
| pedronis | of course we need to signe the new assertion (which means using the root key, so probably will not happen until the september sprint) | 07:01 |
| zyga | perhaps I'm reading the patch wrong | 07:01 |
| zyga | when is assembleAccount called? | 07:02 |
| pedronis | many places | 07:02 |
| pedronis | but yes you are reading the patch wrong | 07:02 |
| pedronis | is just changing what the accessors see | 07:03 |
| zyga | ah, that's good then | 07:03 |
| pedronis | we sign a text, not a struct | 07:03 |
| zyga | yeah, I know that, | 07:03 |
| zyga | I was worried that this is changing the data to be assembled into the text blob | 07:04 |
| pedronis | ? | 07:04 |
| pedronis | it changes only what comes out of the new Accessor | 07:04 |
| pedronis | Validation | 07:04 |
| zyga | ok | 07:04 |
| pedronis | as the comment tries to explain is really about preexisting stuff | 07:05 |
| pedronis | (until we can rev them) | 07:05 |
| mup | PR snapd#5400 closed: spread.yaml: enable main and regression suite on core18 systems <Core18> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5400> | 07:06 |
| zyga | mborzecki: commented on 5421 | 07:06 |
| zyga | I'm -1 on that | 07:07 |
| mup | PR snapd#5398 closed: tests: disable auto-refresh test on core18 <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5398> | 07:07 |
| mup | PR snapd#5322 closed: cmd/snap-confine: include CUDA runtime libraries <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5322> | 07:12 |
| mborzecki | zyga: yeah, looks fishy, idk maybe something with the storage again | 07:16 |
| mborzecki | zyga: if you look at the pastebin, the output that's logged there even matches | 07:16 |
| zyga | mborzecki: yeah | 07:17 |
| zyga | it is odd | 07:17 |
| zyga | especially that this is a file | 07:18 |
| mborzecki | hmm let me restart that travis job a couple of times | 07:18 |
| zyga | I'll play with MATCH | 07:19 |
| zyga | but first | 07:19 |
| zyga | fix the lxd bug | 07:19 |
| zyga | then finish coffee because I'm still fuzzy | 07:19 |
| zyga | then MATCH | 07:19 |
| mborzecki | fuzzy MATCH(ing) | 07:19 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:20 |
| mborzecki | pstolowski: hey | 07:20 |
| zyga | hehe | 07:20 |
| zyga | I'm very fuzzy matching today | 07:20 |
| zyga | on the upside I managed to convince the kids to help a little | 07:21 |
| mvo | zyga: help coding? good job man! | 07:21 |
| zyga | haha | 07:21 |
| zyga | I wish :D | 07:21 |
| mvo | zyga: no playing with the MATCH bug please, lets first attack the two core18 issues | 07:22 |
| zyga | mvo: that's fair | 07:23 |
| zyga | mborzecki: all yours | 07:23 |
| zyga | mvo: the lxd issue is tiny so I'll do that first if you don't mind | 07:23 |
| zyga | then back to core18 | 07:23 |
| mvo | zyga: sure, I don't want to boss you around :) | 07:24 |
| mvo | zyga: just a little ;) | 07:24 |
| mup | PR snapd#5230 closed: interfaces/udisks2: also implement implicit classic slot <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5230> | 07:32 |
| mup | PR snapd#5423 opened: cmd/snap-confine: fix nvidia support under lxd <Created by zyga> <https://github.com/snapcore/snapd/pull/5423> | 07:34 |
| zyga | mborzecki: this is something for you https://forum.snapcraft.io/t/lxd-snaps-nvidia/6134 :) | 07:36 |
| zyga | mvo: can we remove 2.33 milestone now | 07:36 |
| zyga | I don't know how to now that issues don't show up on github | 07:37 |
| mborzecki | zyga: i'll check it before the standup, 18.04 host is good enough? | 07:41 |
| zyga | yes | 07:41 |
| mborzecki | ok | 07:41 |
| zyga | mborzecki: but must use nvidia drivers and you need to perform the test in a container | 07:41 |
| zyga | I would recommend that you perform a baseline test first | 07:42 |
| zyga | to see the denial | 07:42 |
| zyga | and then use patched snap-confine | 07:42 |
| mborzecki | now got to find that usb with mu 18.04 install | 07:42 |
| mborzecki | yay found it :) | 07:47 |
| mborzecki | https://forum.snapcraft.io/t/search-by-common-id/6136 this involves some store work too? | 07:52 |
| mvo | zyga: with https://github.com/mvo5/snappy/tree/core18-all-fixes-all-tests we are down to only a few failure: http://paste.ubuntu.com/p/FsTMHB6fFs/ - this is why I'm so keen to fix the snap-disconnect (i.e. route core: to system) and the core mount namespace | 08:07 |
| zyga | mvo: I will have the latter done in ~ hour | 08:08 |
| zyga | so I think today we may see all green on that PR | 08:08 |
| mvo | zyga: the stop mode issue is still a bit mysterious, I think its a race but I don't know how to fix it yet | 08:09 |
| mvo | zyga: but yeah, would be awesome to get it to green | 08:09 |
| mup | PR snapd#5326 closed: api/snapctl: allow -h and --help for regular users <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5326> | 08:20 |
| mborzecki | google:ubuntu-core-16-64:tests/main/snapd-notify seems to be failing overly frequently | 08:25 |
| mborzecki | this test looks weird, any idea what it's about? all it's doing is systemctl status snapd.service | 08:32 |
| Chipaca | moin moin | 08:33 |
| Chipaca | hands up if you just messed up the last page of the paperwork and you need to take a break before reprinting it | 08:34 |
| * Chipaca finally done except for this bit that's like a checksum of all the above | 08:34 | |
| Chipaca | then i print that and i'm off to the postoffice and then i'm DONE | 08:34 |
| * Chipaca gets back to it | 08:40 | |
| mborzecki | hm i'll rework tests/main/snapd-notify to use systemctl show properties rather than looking for a debug message | 08:41 |
| zyga | mborzecki: my gut feeling is, logging failure | 08:41 |
| mborzecki | zyga: yeah, that's why looking at ExecMainStartTimestampMonotonic and ActiveEnterTimestampMonotonic makes more sense as it comes directly form systemd | 08:42 |
| mvo | pedronis: re the wait-for-auto-connect review - you ask about s.overlord.Settle() there. what is your suggestions? I was thinking about using s.overlord.SnapManager().Ensure() but that does not mix well with the Settles() we use in the tests elsewhere. what is your suggestion here? | 08:48 |
| pedronis | mmh | 08:52 |
| pedronis | mvo: my problem is not so much Settle but the loop etc, why doesn't the old code don't work anymore? | 08:53 |
| mvo | pedronis: settle never converges because auto-connect waits for the restart | 08:54 |
| mvo | pedronis: so the change is never "done" | 08:54 |
| pedronis | ? | 08:54 |
| pedronis | let me check | 08:55 |
| pedronis | something is different then | 08:55 |
| mvo | pedronis: you mean settle should work? | 08:55 |
| pedronis | yes | 08:55 |
| mvo | pedronis: even if the change does not go into done state? | 08:55 |
| mvo | pedronis: aha, ok. sorry, I was not aware of this, let me look | 08:55 |
| pedronis | settle doesn't check for done | 08:55 |
| pedronis | it checks for ensure scheduling | 08:55 |
| mvo | pedronis: don't worry in this case, I can dig into this, I had the wrong assumption | 08:55 |
| pedronis | mvo: btw, did we kill this test: https://github.com/snapcore/snapd/blob/release/2.32/overlord/managers_test.go#L969 ? | 08:57 |
| pedronis | we should maybe bring it back | 08:57 |
| pedronis | no, still there | 08:58 |
| pedronis | wondering what it does right now on master though | 08:58 |
| * mvo nods | 08:58 | |
| mvo | pedronis: aha, so I think the issue is that doAutoConnect returns retry errors. and this means that the taskrunner will schedule runing this task in the future and this is what settle looks at (are there tasks scheduled to run pending). does that make sense? | 09:06 |
| * Son_Goku groans to life | 09:09 | |
| mvo | pedronis: the TestInstallCoreSnapUpdatesBootloaderAndSplitsAcrossRestart works because the configure hook of core waits for a restart | 09:12 |
| mvo | pedronis: I can make the test smarter and ensure that the wait happens in the right place (at the auto-connect task) | 09:12 |
| Son_Goku | I guess it's more accurate that I was startled awake by thunderstorm... | 09:17 |
| pedronis | mvo: no, I'm still not understand, we had tests like that before | 09:17 |
| pedronis | mvo: remember the old code in setup-profiles was also like that | 09:21 |
| mvo | pedronis: ok, let me dig some more then | 09:22 |
| mvo | pedronis: I made the other test more targeted fwiw | 09:22 |
| pedronis | mvo: anyway, maybe we are talking past each other, I don't know how you are changing the other test | 09:28 |
| mvo | pedronis: I think you are spot on actually. I think the difference is that in the old code we did not restart, we had a check that if the same core is installed as the core that was booted we ignore the restart | 09:30 |
| mvo | pedronis: for core18 this is different right now (we can discuss if that is good or bad :) | 09:31 |
| mup | PR snapd#5424 opened: tests/main/snapd-notify: use systemd's service properties rater than the journal <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5424> | 09:31 |
| pedronis | mvo: it's the snapd always restarts stuff? | 09:31 |
| mvo | pedronis: its different because right now snapd in seeding mode is not fully installed but after it seeded itself it is fully installed, so it seems to make sense to restart into the fully installed one at this point | 09:32 |
| mvo | pedronis: yeah, its the snapd that triggeres the restart | 09:32 |
| pedronis | but the other test in managers_test | 09:32 |
| mvo | pedronis: the core18 will not trigger a restart as we use the same check if the revision is the same we booted we don't restart | 09:32 |
| pedronis | also has a restart | 09:32 |
| pedronis | but Settle is enough | 09:32 |
| mvo | pedronis: indeed, let me look what is going on there | 09:33 |
| * Chipaca returns, triumphant | 09:35 | |
| * Chipaca looks up the spelling of "pyrrhic" | 09:36 | |
| mvo | pedronis: still digging but yeah, something is different, its strange the old and the new code use the same retry but in the old one it does converge not in the new | 09:43 |
| mvo | pedronis: also strange - in both the new and old world the TestInstallCoreSnapUpdatesBootloaderAndSplitsAcrossRestart test works with settle | 09:45 |
| mvo | pedronis: aha! found it - so the difference is that the old code only waited for "core" with setup-profiles. but the new code waits for all snaps that are in auto-connect to restart | 09:50 |
| pedronis | mvo: yes, but they are done in order | 09:51 |
| pedronis | I'm still missing something | 09:51 |
| pedronis | mvo: the first settle should stop after snapd or core | 09:51 |
| pedronis | then you set the system as restarted and continue, no? | 09:51 |
| pedronis | what am I missing | 09:51 |
| mvo | pedronis: maybe something in the ordering is wrong, let me check | 09:52 |
| mvo | pedronis: I see that both snapd and core18 are in doing state for auto-connect - which should not be the case, right? | 09:52 |
| pedronis | yes | 09:52 |
| pedronis | that seems wrong | 09:52 |
| pedronis | something bad with the new snapd code | 09:52 |
| mvo | pedronis: thanks, let me re-read the wait code | 09:52 |
| mvo | pedronis: yeah, probably a missing WaitAll() in the new code | 09:52 |
| pedronis | we should install in order snapd core18 kernel gadget other snaps | 09:53 |
| pedronis | all sequentially | 09:53 |
| mvo | pedronis: indeed | 09:53 |
| pedronis | mvo: good I insisted because seems there's a real issue | 09:53 |
| mvo | pedronis: yes! | 09:53 |
| mvo | pedronis: this also explains why the other test is fine | 09:54 |
| mvo | pedronis: its probably a bug in the firstboot code only | 09:54 |
| mup | PR core18#43 opened: Remove manpages and other documentation, cleanup empty doc dirs <Created by sil2100> <https://github.com/snapcore/core18/pull/43> | 09:56 |
| mborzecki | #5242 is a trivial review if anyone's interested | 09:59 |
| mup | PR #5242: tests: new test for joystick interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5242> | 09:59 |
| mborzecki | duh, wrong number | 10:00 |
| mborzecki | #5424 is the trivial one | 10:00 |
| mup | PR #5424: tests/main/snapd-notify: use systemd's service properties rater than the journal <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5424> | 10:00 |
| mvo | pedronis: I pushed an update | 10:11 |
| pedronis | ah | 10:13 |
| pedronis | mvo: so, good, that was bad | 10:14 |
| mvo | pedronis: yes, thanks for the persitance in getting to the bottom of it | 10:14 |
| mvo | pedronis: there was also the unit test for the task ordering missing :( | 10:14 |
| mup | PR snapd#5415 closed: interfaces: moved normalize method to interfaces/utils and made it public <Reviewed> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5415> | 10:20 |
| pedronis | mvo: thx, some more small comments there but looks good overall | 10:22 |
| * Chipaca reading https://forum.snapcraft.io/t/5685 very slowly | 10:31 | |
| * zyga hands Chipaca a copy of for extra fun https://kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook-1c.2017.11.22a.pdf | 10:32 | |
| * Chipaca hands zyga the original documentation for tc | 10:33 | |
| * Chipaca notes it was only found in russian at first | 10:33 | |
| zyga | tc? | 10:33 |
| Chipaca | zyga: traffic control | 10:35 |
| mup | PR snapd#5417 closed: image: block installation of parallel snap instances <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5417> | 10:36 |
| mborzecki | anyone willing to take a look at #5389 ? | 10:39 |
| mup | PR #5389: snap: account for parallel installs in wrappers, place info and tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5389> | 10:39 |
| Chipaca | mborzecki: bring it on | 10:39 |
| mborzecki | Chipaca: thanks! | 10:47 |
| mborzecki | hmm WatchdogTimestampMonotonic=0 on 14.04 with systemd 204 | 10:54 |
| mvo | pedronis: thank you! | 10:54 |
| mvo | pedronis: I updated the pr again but no rpush with a review, need to have lunch now :) | 11:20 |
| pedronis | mborzecki: after #5389 will there be still nore changes in the snap package itself? | 11:20 |
| mup | PR #5389: snap: account for parallel installs in wrappers, place info and tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5389> | 11:20 |
| pedronis | s/nore/more/ | 11:21 |
| mborzecki | pedronis: there'll probably be more, the orignal branches introduced some extra helpers and renames, but those can come in later when needed | 11:22 |
| mborzecki | zyga: libzypp has download.max_silent_tries to auto retry downloads, i'm checking this now, if it doesn't break things i'll open a PR | 11:26 |
| zyga | oooh | 11:27 |
| zyga | yes please | 11:27 |
| zyga | that's a fantastic feature | 11:27 |
| zyga | (no pressure there apt/dnf) | 11:27 |
| mup | PR snapd#5414 closed: corecfg: added experimental.hotplug feature flag <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5414> | 11:35 |
| === pstolowski is now known as pstolowski|lunch | ||
| mup | PR snapd#5425 opened: spread: increase the number of auto retries for package downloads in opensuse <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5425> | 11:42 |
| mborzecki | zyga: ^^ | 11:43 |
| mborzecki | zyga: also if you could take a look at 5424 please | 11:43 |
| zyga | done | 11:45 |
| mborzecki | the tests are super frustrating today | 11:46 |
| mup | PR snapd#5426 opened: client, cmd/snap: pass snap instance name when installing from file <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5426> | 12:00 |
| mborzecki | carved out another piece from parallel installs branch ^^ | 12:00 |
| zyga | mvo: ha | 12:02 |
| zyga | mvo: did you think about this case: core18 system, snapd.snap, core.snap, you run an app that uses core.snap as base; which snap-confine is used? which snapctl is visible? | 12:02 |
| zyga | cleaning up snap-confine made me realise this is a bit weird now | 12:03 |
| pedronis | snapctl comes from where snap-confine comes | 12:04 |
| zyga | mmm, well, it should | 12:05 |
| zyga | but those are arranged differently | 12:05 |
| zyga | snap-confine is selected by snapd on the outside | 12:05 |
| zyga | snapctl is selected by snap-confine | 12:05 |
| pedronis | yes | 12:05 |
| zyga | and the logic is not the same | 12:05 |
| pedronis | how can it be | 12:05 |
| pedronis | snapctl is picked relative to snap-confine | 12:05 |
| mborzecki | switching to ubuntu to check the lxd thing | 12:06 |
| zyga | mmm? there's a bit of code in snap-confine that, if you are not using "core" as a base, does extra bind mounts | 12:06 |
| zyga | this handles snap-confine but snapctl is in another place | 12:07 |
| * zyga looks at what happens | 12:07 | |
| zyga | I think it's something to tidy | 12:07 |
| pedronis | in that case uses_base_snap is true, no ? you said core18 and snapd present | 12:09 |
| zyga | yes but that doesn't handle /usr/bin/snapctl as far as I can see | 12:09 |
| zyga | it just does nothing for it | 12:10 |
| zyga | there's a chunk of commented-out code there | 12:10 |
| pedronis | mmh, I thought snapctl was in /usr/lib/snapd | 12:11 |
| pedronis | that is my confusion | 12:11 |
| pedronis | we have code for that | 12:11 |
| zyga | yeah, it'd be easier | 12:11 |
| pedronis | https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support.c#L360 | 12:11 |
| zyga | could we ship a symlink /usr/bin/snapctl -> $libexecdir/snapd/snapctl | 12:11 |
| zyga | yeah, I'm looking at the exact same code now | 12:12 |
| zyga | anyway, I will add this to the core18 todo list for today | 12:12 |
| pedronis | sounds something to discuss with mvo | 12:14 |
| zyga | agreed | 12:14 |
| mvo | zyga: which snap-cofine/snapctl - the one from core18. I think we want to ensure the tooling is in sync with snapd | 12:25 |
| zyga | yes | 12:26 |
| zyga | mvo: let's HO if you want to chat quickly ahead of the standup | 12:26 |
| mvo | zyga: sure | 12:26 |
| mvo | zyga: I have a PR that moves snapctl into /usr/lib/snapd :) | 12:26 |
| zyga | oh, that's great | 12:26 |
| zyga | thank you for doing that | 12:26 |
| mvo | zyga: one min, just preparing a cup of tea | 12:26 |
| zyga | that's going to be a godsend | 12:26 |
| zyga | mvo: I had a crazy idea just now | 12:27 |
| zyga | snapd.deb that ships just snapd.snap + entrypoint | 12:27 |
| mvo | zyga: yeah, its a fun idea to explore | 12:27 |
| zyga | mvo: ready when you are | 12:32 |
| mborzecki | zyga: lxd from snaps too? | 12:36 |
| zyga | yes | 12:36 |
| pedronis | mvo: looking at 5392 seems I found an unrelated bug, left a comment there | 12:58 |
| === pstolowski|lunch is now known as pstolowski | ||
| mvo | pedronis: thanks, I work on this | 13:02 |
| mborzecki | zyga: dog slow container rootfs download, ~300kBps | 13:09 |
| mborzecki | zyga: replace snap-confine inside the container right? | 13:24 |
| zyga | yes | 13:24 |
| zyga | and disable reexec | 13:24 |
| zyga | and this will fail but that's fine, it will need an apparmor tweak that we can do as we see the denial | 13:24 |
| mborzecki | ok | 13:25 |
| mborzecki-ubuntu | btw, current master https://paste.ubuntu.com/p/7crJcmKcH7/ | 13:30 |
| zyga | I saw that too, I think this is timing/racy test | 13:31 |
| mborzecki-ubuntu | zyga: https://paste.ubuntu.com/p/Q855YBK6nm/ | 13:38 |
| zyga | that's perfect, thanks | 13:39 |
| zyga | can you change the apparmor profile for snap-confine | 13:39 |
| zyga | I will tell you where | 13:39 |
| zyga | hold on | 13:39 |
| zyga | on line 269 | 13:39 |
| zyga | there are a few "remount ro" things | 13:39 |
| zyga | change "remount ro bind" there | 13:39 |
| zyga | reload and try | 13:40 |
| zyga | thank you! | 13:40 |
| mborzecki-ubuntu | yup trying it already | 13:41 |
| mborzecki-ubuntu | zyga: i've edited snap-confine.real | 13:41 |
| zyga | that's good | 13:41 |
| mborzecki-ubuntu | zyga: https://paste.ubuntu.com/p/n9536fST8D/ hmm i should probably update lxd profile too | 13:46 |
| zyga | no, not the lxd profile | 13:48 |
| zyga | mborzecki-ubuntu: what's the profile you have now? | 13:48 |
| zyga | as a sanity check | 13:48 |
| zyga | copy paste the three lines | 13:48 |
| zyga | and have a variant with and without remount | 13:49 |
| zyga | in case the pattern requires all flags to be present | 13:49 |
| zyga | but hmm | 13:49 |
| ogra_ | mvo, hmm, does the pi-config stuff of snpd check the existence of values in config.txt at all ? | 13:57 |
| ogra_ | ogra@pi2:~$ snap set core pi-config.gpu-mem-512=true | 13:58 |
| ogra_ | ogra@pi2:~$ snap set core pi-config.gpu-mem-512=true | 13:58 |
| ogra_ | ogra@pi2:~$ snap set core pi-config.gpu-mem-512=true | 13:58 |
| ogra_ | ogra@pi2:~$ tail -10 /boot/uboot/config.txt | 13:58 |
| ogra_ | device_tree_address=0x02000000 | 13:58 |
| ogra_ | core_freq=250 | 13:58 |
| ogra_ | dtoverlay=vc4-kms-v3d | 13:58 |
| ogra_ | gpu_mem_512=true | 13:58 |
| ogra_ | gpu_mem_512=true | 13:58 |
| ogra_ | gpu_mem_512=true | 13:58 |
| ogra_ | gpu_mem_512=true | 13:58 |
| ogra_ | gpu_mem_512=true | 13:58 |
| ogra_ | gpu_mem_512=true | 13:58 |
| ogra_ | seems it completly blindly appends lines to it | 13:58 |
| zyga | mborzecki-ubuntu: let me know what you get and I'll be right back | 13:58 |
| ogra_ | (not sure if thats any different in stable, that pi runs edge atm) | 13:59 |
| ogra_ | uh ... even worse: | 13:59 |
| ogra_ | ogra@pi2:~$ snap set core pi-config.gpu-mem-512=false | 14:00 |
| ogra_ | ogra@pi2:~$ tail -10 /boot/uboot/config.txt | 14:00 |
| ogra_ | core_freq=250 | 14:00 |
| ogra_ | dtoverlay=vc4-kms-v3d | 14:00 |
| ogra_ | gpu_mem_512=true | 14:00 |
| ogra_ | gpu_mem_512=true | 14:00 |
| ogra_ | gpu_mem_512=true | 14:00 |
| ogra_ | gpu_mem_512=true | 14:00 |
| ogra_ | gpu_mem_512=true | 14:00 |
| ogra_ | gpu_mem_512=true | 14:00 |
| ogra_ | gpu_mem_512=false | 14:00 |
| ogra_ | it doesnt toggle the existing value at all but just appends and append for each snap set call | 14:00 |
| mborzecki-ubuntu | zyga: hm actually one denial is gone, if you look at the first log, there were to, one seemd like it's inside the container's namespace (?) | 14:00 |
| zyga | what's the current denial you see | 14:01 |
| mvo | ogra_: uhhh | 14:02 |
| ogra_ | yeah | 14:02 |
| mvo | ogra_: let me check | 14:02 |
| mborzecki-ubuntu | zyga: https://paste.ubuntu.com/p/n9536fST8D/ look below '<--- profile replaced --->' line | 14:03 |
| zyga | and the app fails to start, correct? | 14:04 |
| mborzecki-ubuntu | zyga: yes | 14:04 |
| zyga | do you have the vanilla profile somewhere, can you diff before/after | 14:04 |
| zyga | (and did you reload the profile (just checking)) | 14:04 |
| mvo | ogra_: hm,hm,we have tests that should ensure that things are not blindly appended but obviously reality disagrees, lets me find out what is going on | 14:05 |
| mborzecki-ubuntu | zyga: apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine.real | 14:05 |
| zyga | the file inherit parts are harmless, I think | 14:07 |
| zyga | only the last one is the problem | 14:07 |
| mborzecki-ubuntu | zyga: http://paste.ubuntu.com/p/KwgWCRgskx/ | 14:08 |
| mborzecki-ubuntu | zyga: tha's inside the container | 14:09 |
| ogra_ | mvo, thanks, need a bug ? | 14:09 |
| zyga | sorry my input froze | 14:09 |
| zyga | mborzecki-ubuntu: the denial now is from lxd indeed | 14:10 |
| zyga | that's interesting | 14:10 |
| zyga | let me look at the conversation last night | 14:10 |
| * ogra_ holds a flame under zyga's input | 14:10 | |
| mvo | ogra_: this is current edge I assume? | 14:10 |
| ogra_ | mvo, yeah, i havent tried stable ... | 14:10 |
| mvo | ogra_: no worries | 14:11 |
| ogra_ | (i can if it helps though) | 14:11 |
| ogra_ | (after a meeting i'm currently in) | 14:11 |
| mvo | ogra_: all good, just want to know if I can start with master when trying to reproduce | 14:11 |
| ogra_ | yeah | 14:11 |
| zyga | mborzecki-ubuntu: I think next lxd will fix it | 14:13 |
| zyga | https://github.com/lxc/lxd/pull/4704/files | 14:13 |
| mup | PR lxc/lxd#4704: lxd/apparmor: Allow ro bind-mounts and remounts <Created by stgraber> <Merged by brauner> <https://github.com/lxc/lxd/pull/4704> | 14:13 |
| zyga | mborzecki-ubuntu: can you re-write the profile again, so that snap-confine has just the extra "remount" there | 14:14 |
| zyga | reload that profile | 14:14 |
| zyga | and ensure this is consistent with the denial you had before | 14:14 |
| zyga | and finally add that to the PR 5423 | 14:15 |
| zyga | that that should be it | 14:15 |
| mup | PR #5423: cmd/snap-confine: fix nvidia support under lxd <Created by zyga> <https://github.com/snapcore/snapd/pull/5423> | 14:15 |
| mborzecki-ubuntu | zyga: wonder if lxd with this patch is in edge already | 14:16 |
| zyga | good idea, let's check :) | 14:18 |
| zyga | I need to take Bit for a walk | 14:19 |
| zyga | it's been too long already | 14:19 |
| zyga | mvo: I'll share what I have after I'm back | 14:20 |
| mup | PR snapd#5427 opened: configcore: fix incorrect handling of keys with nubmers (like gpu_mem_512) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5427> | 14:23 |
| pedronis | away _ | 14:25 |
| mvo | ogra_: -^ | 14:26 |
| stgraber | mborzecki-ubuntu: it should be, yes | 14:26 |
| mvo | ogra_: it just happens with key that have numbers in them | 14:26 |
| stgraber | mborzecki-ubuntu: and I've included it in candidate too | 14:26 |
| mvo | ogra_: still a bug of course, thanks for the report | 14:26 |
| mborzecki-ubuntu | zyga: lxd (edge) git-fe39a5a (7606) + snap-confine patch + apparmor profile update works | 14:26 |
| mborzecki-ubuntu | stgraber: ^^ | 14:26 |
| ogra_ | mvo, ah ! so i was just lucky to test the right key :) | 14:27 |
| mvo | ogra_: precisely | 14:27 |
| mvo | ogra_: the fix above should be fine, I look into removing the hand-made thing, I think we have a better library for this | 14:27 |
| ogra_ | i'll test once it merged | 14:27 |
| mvo | ogra_: should be fine, I added a regression test (famous last words) | 14:28 |
| ogra_ | :) | 14:28 |
| zyga | Thank you mborzecki | 14:31 |
| mborzecki-ubuntu | zyga: now that MS_BIND is added, apparmor rules for gl{,32} and glvnd need an update too, right? | 14:31 |
| zyga | Yes, all three | 14:32 |
| niemeyer | mvo: On the go-check tweak, does the + at the end make sense for the case of the diff output? | 14:37 |
| mvo | niemeyer: you mean when a struct compare fails? I can look into removing it, I think its redundant and looks a bit out of place | 14:39 |
| niemeyer | mvo: I'm trying to understand the consequence, but I can't quite put my finger on it given the examples | 14:39 |
| niemeyer | mvo: Line 90 at the very end of the PR diff looks suspect, though.. might be a consequence of it | 14:40 |
| mvo | niemeyer: yes, thats a consequence | 14:40 |
| niemeyer | mvo: The case demonstrated in the multiline test (TestMultiLineStringEqualFails) is super sweet, btw | 14:41 |
| niemeyer | mvo: Okay, this is my last remark then | 14:41 |
| niemeyer | LGTM otherwise | 14:41 |
| mborzecki-ubuntu | https://paste.ubuntu.com/p/QYwPQhcFfz/ heh each time i run the unit tests a new error comes up | 14:42 |
| mvo | niemeyer: thank you! on so many levels :) | 14:43 |
| mvo | niemeyer: I will see how I can get rid of the "+" then in the output, iirc this is something that kr/pretty generates | 14:43 |
| mvo | pedronis: I replied to your panic question in 5392 - happy to write another PR with a small unit test to be on the safe side | 14:47 |
| pedronis | mvo: notice that that code could be used on classic | 14:47 |
| pedronis | in that case there's no kernel and potentially no gadget | 14:48 |
| mvo | pedronis: then we are missing a test, let me add one | 14:48 |
| pedronis | mvo: yes, this is about classic mostly | 14:48 |
| niemeyer | mvo: np, and thanks again for the feature. It'll be great to have this! | 14:49 |
| mvo | pedronis: iirc we test the classic firstboot in a different place, let me dig into it | 14:49 |
| niemeyer | mvo: I don't think the + comes from pretty | 14:49 |
| niemeyer | mvo: See the format function | 14:50 |
| pedronis | mvo: yes, but this would be a strange tests with a seed.yaml that is empty or has empty snaps (not sure we have one like that) | 14:50 |
| niemeyer | mvo: If it did come from pretty, we'd have the "..." added by the format function | 14:50 |
| pedronis | mvo: we have one with no seed.yaml at all I suppose | 14:50 |
| mborzecki-ubuntu | zyga: i'll push to your branch | 14:50 |
| pedronis | but maybe I'm misremembering | 14:51 |
| niemeyer | mvo: But we don't.. it looks like a minor bug on the formatting itself | 14:51 |
| mvo | niemeyer: aha, ok | 14:51 |
| mvo | niemeyer: thanks again! | 14:51 |
| niemeyer | mvo: The + makes sense for the string case (see the multiline example) | 14:51 |
| niemeyer | mvo: We might even reuse the quote bool | 14:51 |
| niemeyer | mvo: np! | 14:52 |
| * niemeyer lunches | 14:52 | |
| mvo | pedronis: hm, firstboot_test.go has no test for classic. let me find those tests first then I will add it there | 14:52 |
| zyga | Thanks mborzecki | 14:52 |
| pedronis | mvo: I thought it had a couple | 14:52 |
| mborzecki-ubuntu | zyga: and pushed | 14:52 |
| mborzecki-ubuntu | zyga: also verified locally | 14:53 |
| mvo | pedronis: maybe I'm just too naive, I was looking for MockOnClassic in this file | 14:53 |
| pedronis | mvo: TestPopulateFromSeedOnClassicNoSeedYaml | 14:53 |
| mvo | pedronis: aha, there they are. thank you, I will add the test now | 14:53 |
| mborzecki-ubuntu | our nvidia spread test caught that too, yay! | 14:54 |
| pedronis | mvo: we have ClassicNoSeedYaml, we ClassicEmptySeedYaml I suppose | 14:54 |
| pedronis | *we need | 14:54 |
| mvo | pedronis: +1 | 14:54 |
| mup | PR snapd#5428 opened: devicestate: fix panic in firstboot code when no snaps are seeded <Created by mvo5> <https://github.com/snapcore/snapd/pull/5428> | 15:04 |
| mup | PR snapd#5429 opened: osutil: import go-udev <Created by stolowski> <https://github.com/snapcore/snapd/pull/5429> | 15:10 |
| mvo | niemeyer: you were quite right, a subtle thing in formatMultiLine, update, let me know if its to your liking | 15:16 |
| mup | PR snapd#5430 opened: tests: enable new fedora image with test dependencies installed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5430> | 15:37 |
| mup | PR snapd#5431 opened: interfaces: move ValidateName helper to utils <Created by stolowski> <https://github.com/snapcore/snapd/pull/5431> | 16:10 |
| zyga | jdstrand: hey | 16:24 |
| zyga | jdstrand: can you please look at https://github.com/snapcore/snapd/pull/5411 | 16:24 |
| mup | PR #5411: many: remove core-support interface <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5411> | 16:24 |
| zyga | it has two +1s but I didn't merge it because I wanted you to see | 16:24 |
| zyga | pstolowski: question | 16:24 |
| zyga | why interfaces/utils vs just interfaces/ | 16:25 |
| zyga | is it an import cycle if we use interfaces? | 16:25 |
| zyga | not a strong opinion, just curious | 16:25 |
| pstolowski | zyga: yes, i think i replied to that | 16:25 |
| pstolowski | zyga: cause interfaces/hotplug/... needs to import interfaces | 16:25 |
| zyga | thanks, this makes sense | 16:26 |
| popey | jdstrand: heads up, I just moved interfaces and assertions from the github wiki to the forum. | 16:26 |
| zyga | popey: interesting, thank you! | 16:26 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#5423 closed: cmd/snap-confine: fix nvidia support under lxd <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5423> | 16:35 |
| === chihchun is now known as chihchun_afk | ||
| zyga | mvo: comment on 5428 | 16:42 |
| === chihchun_afk is now known as chihchun | ||
| zyga | mvo: comment on 5427 | 16:50 |
| === chihchun is now known as chihchun_afk | ||
| mvo | zyga: yay, thank you | 16:56 |
| mvo | zyga: will work on it right after dinner | 16:57 |
| pstolowski | nooo, our checks don't like formatting of go-udev | 17:02 |
| * zyga hugs mvo | 17:05 | |
| zyga | pstolowski: can we add an exception | 17:06 |
| zyga | so that it is not checked | 17:06 |
| zyga | alternatively | 17:07 |
| pstolowski | zyga: i just did | 17:07 |
| zyga | go-fmt and send it upstream :) | 17:07 |
| zyga | it's only a patch | 17:07 |
| zyga | if they take it, it would be easier | 17:07 |
| sergiusens | mvo: did you have any luck with core16? | 17:07 |
| sergiusens | mvo: (or maybe zyga), why are xXX revisioned snaps read by root only? | 17:08 |
| zyga | sergiusens: hmm, no idea | 17:08 |
| sergiusens | in /var/lib/snapd/snaps I mean | 17:08 |
| zyga | well | 17:08 |
| zyga | right | 17:08 |
| sergiusens | can they be made 644? | 17:08 |
| zyga | the files are probably made this way | 17:08 |
| zyga | I don't think this is deliberate actually | 17:08 |
| zyga | Chipaca: ^ do you know why we chmod og-rw locally installed snaps? | 17:08 |
| Chipaca | zyga: we don't | 17:09 |
| Chipaca | zyga: at least, I don't think we do | 17:09 |
| Chipaca | zyga: it's just the defauts for tempfile | 17:09 |
| sergiusens | I just think it is on how the copy logic works out, but it is a bit of a pain to inject snaps with this in place | 17:09 |
| Chipaca | to be fair, who cares? :-) | 17:09 |
| Chipaca | sergiusens: why do you care? | 17:10 |
| sergiusens | Chipaca: we inject the local snaps into containers and into build VMs to not download again and to have the same version on the outside and the inside | 17:10 |
| Chipaca | sergiusens: ok | 17:10 |
| sergiusens | so, yes, we do care | 17:11 |
| Chipaca | sergiusens: no, you don't | 17:11 |
| Chipaca | sergiusens: or at least, your explanation hasn't explained to me why you do :-) | 17:11 |
| sergiusens | speaking of caring, can we make `snap install foo` not fail (with a --wait switch maybe) if there are pending auto refreshes? | 17:11 |
| Chipaca | sergiusens: haven't we had this conversation about 'snap watch --last=auto-refresh' ? | 17:12 |
| sergiusens | Chipaca: you had, but niemeyer said we should fix that | 17:13 |
| Chipaca | that == what? | 17:13 |
| Chipaca | not having it fail? | 17:13 |
| sergiusens | Chipaca: snap watch --last=auto-refresh | 17:13 |
| sergiusens | there's a chance for a race there too, isn't there? | 17:13 |
| Chipaca | of course | 17:13 |
| sergiusens | between that command returning and calling the new one | 17:14 |
| zyga | Chipaca: just an idea "snap install --queue foo" | 17:14 |
| zyga | it would wait for all conflicts to resolve and install | 17:14 |
| Chipaca | conflicts is about to get a thrashing | 17:15 |
| zyga | we could have a concept of idle tasks | 17:15 |
| zyga | those are picked up when snapd does nothing | 17:15 |
| Chipaca | zyga: stahp | 17:15 |
| zyga | just making hand-wavy things | 17:15 |
| zyga | can I wave some more | 17:15 |
| Chipaca | zyga: stop hand-waving more stuff on when we're trying to simplify it | 17:15 |
| zyga | I can also hold my hands above my head like a particular well-known Dilbert boss ;) | 17:15 |
| zyga | the idea is really simple ;-) | 17:15 |
| * zyga shutups | 17:16 | |
| sergiusens | Chipaca: and for the permissions thing, I want to avoid this ugly logic https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/lxd/_containerbuild.py#L285 | 17:16 |
| Chipaca | sergiusens: it finally clicked what you're trying to do | 17:17 |
| Chipaca | sergiusens: (why is that doing chown and not chmod?) | 17:18 |
| Chipaca | sergiusens: so | 17:20 |
| Chipaca | sergiusens: there's no strong reason for them being 0600 | 17:20 |
| Chipaca | sergiusens: but, we can fix it | 17:20 |
| Chipaca | sergiusens: but, fixing it retroactively would be trickier | 17:20 |
| sergiusens | Chipaca: I am rewriting that to just do a copy/chmod; but I will not change ownership of files I do not own on my own :-) | 17:20 |
| Chipaca | sergiusens: that is, even if the next snapd shipped made local snaps be 0444, you'd still need to handle snaps you can't read | 17:21 |
| sergiusens | Chipaca: fix it for the future, build VMs introduced will use this and that is where I care it is ok, by then snapcraft will be fine | 17:21 |
| Chipaca | sergiusens: but, feel free to chmod them meanwhile | 17:21 |
| Chipaca | no chown, just chmod | 17:22 |
| sergiusens | Chipaca: I'll keep the logic, but that sudo request is annoying and would be nice to make it a corner of a corner case | 17:22 |
| sergiusens | well, permissions or ownership me no touch | 17:22 |
| sergiusens | at the point in that snippet I shared it doesn't really matter as it is operating on the copy | 17:23 |
| niemeyer | I also don't get what the problem is | 17:24 |
| Chipaca | niemeyer: the problem is that snapcraft runs as the user | 17:24 |
| Chipaca | niemeyer: and it tries to copy locally-installed snaps into the vm | 17:24 |
| Chipaca | niemeyer: but it can't read them because they're 0600 | 17:24 |
| Chipaca | sergiusens: may i suggest, meanwhile: sudo cp --no-preserve=mode | 17:25 |
| niemeyer | sergiusens: How do you run the vm? | 17:25 |
| Chipaca | OTOH maybe snapcraft can talk to lxd and tell it to mount the snaps directory directly | 17:26 |
| Chipaca | no copying \o/ | 17:26 |
| niemeyer | Chipaca: It's qemu, but yes, that's the idea | 17:26 |
| * Chipaca decides it's beer o'clock | 17:27 | |
| Chipaca | brb | 17:27 |
| niemeyer | mvo: go-check PR is in | 17:31 |
| niemeyer | Thanks again | 17:31 |
| pstolowski | zyga: a bunch of formatting/nakered/spelling errors in go-udev. for now i fixed a few locally, added one exception and will propose a fix upstream but don't want to block on that for next few days (thus fixing them locally right now) | 17:31 |
| zyga | yeah, that's sensible | 17:32 |
| zyga | let's add an exception and fix what we can upstream | 17:32 |
| niemeyer | pstolowski: As long as we keep track of the delta, sounds good | 17:34 |
| zyga | I'd be surprised if upstream complained about typo fixes and use of go fmt | 17:34 |
| pstolowski | yep, the guy has been very friendly so far | 17:35 |
| === pstolowski is now known as pstolowski|afk | ||
| sergiusens | niemeyer: running the VM (for now with sudo), but it is an open still | 17:41 |
| niemeyer | sergiusens: Right.. it uses sudo, runs as root.. should be easy to, at least for now, expose the snap directory | 17:44 |
| niemeyer | sergiusens: As 9p | 17:44 |
| niemeyer | I would rather not change the snap permissions | 17:45 |
| niemeyer | As it encourages fiddling with backing data which does not have a well defined API | 17:46 |
| Chipaca | niemeyer: fwiw snap permissions are rather accidental right now | 17:54 |
| Chipaca | niemeyer: from store, they have 644, whereas local are 0600 | 17:54 |
| Chipaca | also snapd on master (on my machine right now) refuses to stop (?!?) | 17:54 |
| niemeyer | Chipaca: Ah, that sounds buggy indeed | 17:54 |
| niemeyer | Chipaca: On both counts :) | 17:54 |
| zyga | Chipaca: snapd --stubborn | 17:54 |
| Chipaca | systemd ends up kill-9ing it | 17:55 |
| zyga | only until snapd controls systemd (evil laughter) | 17:55 |
| Chipaca | zyga: I object | 17:57 |
| zyga | Chipaca: in soviet russia, snapd ships you ;) | 17:57 |
| * zyga really gets back to work | 17:57 | |
| Chipaca | zyga: you think systemd is hated, imagine if canonical had done it | 17:58 |
| zyga | yes | 17:58 |
| zyga | lennart would work for us and we would be universally hated (by the people who love to hate) | 17:58 |
| zyga | Chipaca: also at that rate systemctl would contain snapd by now | 17:59 |
| Chipaca | niemeyer: to be clear: would you be ok with a change that made all snaps be 0444, or would you prefer they all be 0400? | 18:06 |
| niemeyer | Chipaca: I don't have a strong opinion there | 18:08 |
| niemeyer | Chipaca: Other than we should fix the inconsistency | 18:09 |
| Chipaca | niemeyer: as I can't really 'fix' ioutil.TempFile to take a mode, and this is relatively minor (in that if the power goes out and the chmod is lost it's not a huge issue) i'll just add a chmod to the end of install and be done with it | 18:10 |
| niemeyer | Chipaca: I guess the argument of hiding them is weak as well.. one might argue about the case of private snaps, but these are mounted with their contents exposed anyway | 18:10 |
| niemeyer | Hmm.. although the perms are under the publisher's control | 18:12 |
| Chipaca | niemeyer: snap download tho | 18:13 |
| niemeyer | Chipaca: In theory that wouldn't give access to private snaps to which one doesn't have access | 18:13 |
| Chipaca | niemeyer: so you're concerned that a user that doesn't have root should not necessarily be able to read the files in a private snap | 18:15 |
| niemeyer | Chipaca: Yeah, it's something we haven't really accounted much for so far | 18:15 |
| Chipaca | mhmm | 18:15 |
| niemeyer | Chipaca: The private snap can control its internal perms.. it cannot control whether the snap file itself is made public | 18:16 |
| Chipaca | but i agree if that's something we care about, that'd be the reason to make it 0400 instead of 0444 | 18:16 |
| niemeyer | Chipaca: Makes the case for 0400 a bit more interesting | 18:16 |
| Chipaca | or just 0600 | 18:16 |
| niemeyer | Yeah | 18:16 |
| * cachio afk | 18:17 | |
| Chipaca | ok. 0600 everywhere is a one-line change (two because i'd add a comment). 0444 everywhere is bigger, but i've already got it | 18:17 |
| Chipaca | i'll shelve it until tomorrow so you can ponder this in the background | 18:17 |
| niemeyer | Chipaca: Thanks! | 18:18 |
| Chipaca | np | 18:18 |
| Chipaca | if we decide 0600 everywhere is the right thing, sergio is going to be sad | 18:18 |
| * Chipaca hugs sergiusens | 18:18 | |
| mvo | niemeyer: yay, thank you! | 18:19 |
| * Chipaca very EOD | 18:23 | |
| sergiusens | Chipaca: blimey, well that's that; we can tackle the wait for refresh thing tomorrow ;-) | 18:34 |
| mup | PR snapd#5425 closed: spread: increase the number of auto retries for package downloads in opensuse <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5425> | 18:48 |
| mup | PR snapd#5409 closed: tests: run "arp" tests only if arp is available <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5409> | 18:49 |
| mup | PR snapd#5381 closed: interfaces: make findSnapdPath smarter <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5381> | 18:50 |
| jdstrand | popey: thanks! did you do this in coordination with niemeyer? we were talking about it and hadn't done it yet | 18:52 |
| jdstrand | zyga: re 5411> ack | 18:52 |
| popey | No. It just seemed mad to have it be there. | 18:54 |
| popey | The rest API docs should move too as it's the last one left but it's more than 32k in size | 18:54 |
| popey | The forum balks at more than 32000 byte docs | 18:54 |
| jdstrand | zyga: fyi since mborzecki is away: https://github.com/snapcore/snapd/pull/5423/files#r198954092 | 19:12 |
| mup | PR #5423: cmd/snap-confine: fix nvidia support under lxd <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5423> | 19:12 |
| zyga | mmm | 19:12 |
| zyga | so the old rules _worked_ with old code outside of lxd | 19:13 |
| zyga | inside lxd there was a denial from apparmor profile of the container which disallowed filesystem remounts | 19:13 |
| zyga | stgraber changed the profile to allow _mount point_ remount | 19:14 |
| zyga | so the new rules also work fine with new code, but now inside and outside of lxd (though you need edge lxd to use it for now) | 19:14 |
| jdstrand | zyga: I guess the question is, do these rules only apply for that one line code change, or is there other code that the old rule covered? | 19:14 |
| zyga | we have a spread test that checks non-lxd case and it works (it failed before maciej updated the profile) | 19:14 |
| zyga | it's the only instance, we checked | 19:14 |
| jdstrand | ok, that's fine | 19:15 |
| zyga | we don't have a test that checks this inside lxd but this is a separate issue with just running the whole suite in lxd to see what _really _works vs adding special-cases in tests | 19:15 |
| zyga | we also ran this in practice on maciej's hardware with bionic host / guest and nvidia drivers and lxd from edge | 19:15 |
| jdstrand | zyga: thanks. I commented to myself | 19:17 |
| zyga | FYI, I added this as a response to the forum now | 19:17 |
| zyga | nice, thank you :) | 19:17 |
| jdstrand | (I did in the PR) | 19:17 |
| zyga | er, I meant the PR as well | 19:17 |
| zyga | not sure why I said about the forum | 19:17 |
| jdstrand | heh, it is late there. I meant for you to only see this when you came online tomorrow :) | 19:18 |
| zyga | I'm still here, trying to fix some issues in s-c | 19:18 |
| mvo | zyga: on the core/core18 thing? | 19:19 |
| zyga | yes | 19:19 |
| zyga | sorry, interrupts from IRL, daughter being grumpy about housework (literally one plate she used) and chatting with wife about weekend prep | 19:20 |
| zyga | mvo: I'm moving out for three weeks to spend the time with my parents (and the kids) | 19:20 |
| zyga | so some preparation required | 19:20 |
| mvo | zyga: heh, no worries | 19:23 |
| mvo | zyga: if you push what you have, maybe I can help? | 19:23 |
| zyga | sure | 19:23 |
| zyga | mvo: just pushed to branch named after your PR | 19:24 |
| zyga | with a WIP/commit on top | 19:24 |
| zyga | have a look, not too much really | 19:24 |
| zyga | I will try to focus now and finish this | 19:25 |
| zyga | but feedback welcome | 19:25 |
| mvo | zyga: cool, looking | 19:26 |
| mvo | zyga: thanks a bunch! | 19:26 |
| jdstrand | popey: ok, thanks! :) | 19:27 |
| zyga | trying locally now | 19:34 |
| zyga | it failed on some non-core systems, checking what I did again | 19:34 |
| zyga | bringing up the VM is veeeery slow | 19:58 |
| zyga | more timeouts, sigh | 20:08 |
| zyga | I switched to my laptop LTE | 20:08 |
| zyga | maybe my home link (different ISP) somehow sucks today | 20:08 |
| mvo | zyga: I'm running in parallel | 20:08 |
| zyga | it will fail but I want to see exactly how and focus on fixing it | 20:09 |
| zyga | did you eyeball the code | 20:09 |
| zyga | (please squash the last two WIP patches for better ideas) | 20:09 |
| mvo | yeah, looks reasonable | 20:09 |
| zyga | and _drat_ I didn't pass keep | 20:14 |
| zyga | well | 20:14 |
| zyga | ;) | 20:14 |
| zyga | mvo: ok, got it to fail now | 20:25 |
| zyga | I ran 16.04 classic | 20:25 |
| zyga | and it failed with: mount --move /var/lib/snapd /tmp/snapd.quirks_$random: EINVAL | 20:25 |
| zyga | hmmm! | 20:25 |
| mvo | zyga: I am almost there, I had an earlier failure that core18 did not work | 20:27 |
| zyga | I'll gdb to see what happens | 20:28 |
| zyga | gdb | 20:28 |
| zyga | the one thing I miss in go world | 20:28 |
| kyrofa | zyga, you don't need to lie about how much you secretly love C++ | 20:29 |
| zyga | I don't love C++ actually, I'm a huge fan of C | 20:29 |
| zyga | C++ not so much | 20:29 |
| zyga | uh, stripped | 20:33 |
| roadmr | is niemeyer around? | 20:35 |
| roadmr | C is nice, C++ is beyond my powers to grok haha | 20:35 |
| zyga | roadmr: I feel exactly the same | 20:35 |
| niemeyer | roadmr: He is | 20:35 |
| roadmr | niemeyer: +1 for referring to yourself in the third person. Are you OK to transfer travis over to kyrofa ? | 20:36 |
| roadmr | zyga: today I found https://www.emojicode.org/ | 20:36 |
| zyga | mvo: how terrible would it be if snap-confine-debug would be in snapd.snap? | 20:37 |
| zyga | 297K | 20:37 |
| niemeyer | roadmr: Yeah, major +1 for having a Travis CLI that doesn't involve building the gem from the ground up | 20:37 |
| mvo | zyga: for now it should be fine | 20:38 |
| roadmr | thanks niemeyer ! the transfer is now complete. Cheers! | 20:38 |
| zyga | mvo: I have supper now | 20:41 |
| mvo | zyga: ok, lets talk tomorrow | 20:41 |
| mvo | zyga: hm, hm, I merged my earlier spread test | 20:44 |
| mvo | and running test-snapd-tools.cat /etc/os-release gives me core-18 :( | 20:44 |
| mvo | zyga: how is debug mode? | 20:44 |
| mvo | zyga: anyway, tomorrow | 20:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!