| cachio | ijohnson, hey | 00:24 |
|---|---|---|
| cachio | I left a comment in the PR | 00:24 |
| cachio | the issue can be reproduced | 00:24 |
| * cachio dinner | 00:35 | |
| mup | PR snapd#8150 closed: tests: ask tar to speak English <Simple π> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8150> | 01:02 |
| mup | PR snapcraft#2951 opened: snap-packaging: remove broken host-compatibility check for runner <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2951> | 02:21 |
| mup | PR snapd#8173 opened: tests: adding arch-linux execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8173> | 03:08 |
| mborzecki | morning | 06:19 |
| mborzecki | hm https://community.spotify.com/t5/Desktop-Linux/Spotify-Snap-randomly-stopped-working/td-p/4901987 | 06:39 |
| mup | PR snapd#8172 closed: snapcraft.yaml: add python3-apt, tzdata as build-deps for the snapd snap <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8172> | 07:33 |
| pedronis | mvo: hi, can you review or get a review for #8130 ? | 07:34 |
| mup | PR #8130: overlord, state: don't abort changes if spawn time before StartOfOperationTime (2/2) <Preseeding π> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8130> | 07:34 |
| pedronis | mborzecki: #8136 needs a 2nd review from you | 07:40 |
| mup | PR #8136: boot: write current_kernels in bootstate20, makebootable <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8136> | 07:40 |
| mborzecki | pedronis: hi, will do | 07:41 |
| mborzecki | mvo: morning, evdev sucks, golang-evdev and python-evdev are buggy ;) | 07:41 |
| mborzecki | i'm not sure how libinput author didn'g go crazy | 07:42 |
| mvo | pedronis: hey, good morning | 07:46 |
| mvo | pedronis: sure, let me review this | 07:46 |
| mvo | mborzecki: uh, oh no | 07:46 |
| mvo | mborzecki: even for our (relatively) simple use-case it sucks? | 07:47 |
| mborzecki | mvo: yeah, good to use different test systems, the laptop keybiard and VM input device behaves completely differntly than my other keyboard | 07:48 |
| mvo | mborzecki: oh, woah | 07:48 |
| mvo | mborzecki: I did test with vm and with my thinkpad keyboard and for the simple things I did it was ok but sad to hear that it's so annyoing | 07:49 |
| mborzecki | mvo: some devices emit repeated keys, some do not, so we need to sync the initial state, then we have to actually look at key up/down rather than repeating event | 07:49 |
| mborzecki | also, golang-evdev SetRepeatRate() is buggy and parameter meaning/order is swapped than what i see in the kernel code that interprets them ;) | 07:49 |
| mborzecki | (same for python-evdev) | 07:50 |
| mborzecki | nonetheless, SetRepeatRate() does nothing with my other keyboard, there's no repeat at all :P | 07:50 |
| pedronis | mborzecki: does any of this correlate with reported capabilities or it's random? | 07:50 |
| pedronis | I mean can we know from caps if it does repeat or not? | 07:51 |
| mborzecki | pedronis: no, there's no capability that states that you get repeat events | 07:51 |
| pedronis | ok | 07:51 |
| mborzecki | oh, and libinput ignores kernel autorepat events | 07:51 |
| mborzecki | like totally | 07:51 |
| pedronis | yesterady I was reading something and it sounded like there are hardware auto-repeat, and some at higher levels | 07:52 |
| mborzecki | https://gitlab.freedesktop.org/libinput/libinput/blob/master/src/evdev-fallback.c#L537 afaict they synthesize their own events | 07:52 |
| pedronis | and they might even interfere | 07:52 |
| mborzecki | e->value corrsponds to our KeyHold | 07:53 |
| zyga | good morning | 07:53 |
| mborzecki | pedronis: so i'm refactoring this to get the initial state of the keys as libinput does it, and then observe the up event and look at the time key is held | 07:54 |
| mborzecki | zyga: hey | 07:54 |
| zyga | are we low level input engineers now too? :) | 07:54 |
| mborzecki | and, fwiw the golang-evdev does not include a wrapper to get the initial state of keys :P so had to pull out the ioctls and do it myself | 07:54 |
| mvo | mborzecki: hm, if we only get up/down reliable that would make the UX really not nice | 07:54 |
| mborzecki | mvo: right, thus it's check initial state, then observe down if it appears and see if it's down for <n> amount of time | 07:55 |
| mborzecki | and the goroutine leaks, bc we have the same problem as with netlink socket | 07:56 |
| mvo | mborzecki: aha, nice | 07:56 |
| mvo | mborzecki: that makes sense | 07:56 |
| zyga | mborzecki: do you want my fix for that? | 07:56 |
| pedronis | mborzecki: which reminds me, can you review #8101 | 07:57 |
| mborzecki | zyga: it's not critical, it's a short lived process, but ultimately we'll need a fix, either yours or the Stopper thing | 07:57 |
| mup | PR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/8101> | 07:57 |
| zyga | ack | 07:57 |
| mborzecki | oh, and will have to step out for a bit late to some blood tests | 07:58 |
| pstolowski | morning | 08:01 |
| * zyga recalls he has to do blood tests as well but needs to get an appointment first | 08:02 | |
| zyga | hey pawel | 08:02 |
| pedronis | mborzecki: what's the status of #8081 ? | 08:05 |
| mup | PR #8081: tests/main/user-session-env: add test verifying environment variables inside the user session <Simple π> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8081> | 08:05 |
| mborzecki | pedronis: it should be good to go | 08:07 |
| mborzecki | let me merge master there | 08:07 |
| pedronis | mborzecki: so it works in other distros but not ubuntu/debian ? | 08:12 |
| mborzecki | pedronis: zsh? yes, there's a lp bug i linked there | 08:12 |
| mborzecki | fwiw zsh has a sh compat mode for loading /etc/profile, it's used on fedora, arch and and probably suse too | 08:14 |
| mborzecki | the downside is that there's no standard way to do drop-in files for zsh like /etc/profile.d, otherwise we could fix it easily | 08:15 |
| pedronis | yes, that bug doesn't seem to be going anywhere | 08:15 |
| mborzecki | and it's been there for a while now | 08:16 |
| zyga | hmm | 08:21 |
| zyga | mborzecki: I'm using zsh on my mac for a while | 08:21 |
| zyga | is there really not standard way? | 08:21 |
| * zyga looks at zsh in Ubuntu | 08:21 | |
| zyga | mborzecki: can you please review https://github.com/snapcore/snapd/pull/8171 -- the failover test is still causing some pain | 08:22 |
| mup | PR #8171: cmd/snap-failure/snapd: also rm snapd.socket if it still exists <Simple π> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8171> | 08:22 |
| mborzecki | zyga: added a note https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1640514/comments/30 | 08:28 |
| mup | Bug #1640514: /snap/bin is not added to the PATH when using zsh <patch> <Snappy:Fix Released> <snapd (Ubuntu):Confirmed> <zsh (Ubuntu):Invalid> <snapd (Ubuntu | 08:28 |
| mup | Xenial):Confirmed> <zsh (Ubuntu Xenial):Invalid> <snapd (Ubuntu Bionic):Fix Released> <zsh (Ubuntu Bionic):Invalid> <https://launchpad.net/bugs/1640514> | 08:28 |
| mborzecki | doubt this will help the bug move forward | 08:28 |
| zyga | mmm | 08:29 |
| zyga | yeah, I see | 08:30 |
| zyga | man, everything is hard | 08:30 |
| * mborzecki has 3 keyboards connected to his pc now | 08:33 | |
| pedronis | mvo: I reviewed #8142 | 08:33 |
| mup | PR #8142: client: add support for "ResumeToken", "HeaderPeek" to download <Created by mvo5> <https://github.com/snapcore/snapd/pull/8142> | 08:33 |
| mup | PR snapd#8130 closed: overlord, state: don't abort changes if spawn time before StartOfOperationTime (2/2) <Preseeding π> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8130> | 08:33 |
| mvo | pedronis: nice, thank you | 08:35 |
| pstolowski | yay, thanks for reviews | 08:35 |
| pstolowski | pedronis: would you like to take a quick look at https://github.com/snapcore/snapd/pull/8120 or can I land (has +2 already) | 08:36 |
| pstolowski | ? | 08:36 |
| mup | PR #8120: cmd/snap-preseed: snapd version check for the target <Preseeding π> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8120> | 08:36 |
| pedronis | pstolowski: I did skim it | 08:36 |
| pedronis | pstolowski: related to reviews, can you finish reviewing #8101 | 08:37 |
| mup | PR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/8101> | 08:37 |
| pstolowski | pedronis: i made 2 or 3 comments there | 08:38 |
| pedronis | pstolowski: I know, do you want to block it on them? | 08:40 |
| zyga | I need to fetch something, back in 30 | 08:40 |
| pstolowski | pedronis: no, it's fine as a potential followup (if the comments make sense at all) | 08:41 |
| pedronis | pstolowski: I expect the gc test to be a bit of a pain to write tbh | 08:41 |
| pstolowski | pedronis: i've never played with this aspect in go... wouldn't runtime.GC() make it deterministic for the test? | 08:45 |
| pedronis | pstolowski: possibly, somebody has to try | 08:45 |
| pedronis | about the comment, I'm happy to mention the GC in a follow up, if there no more comments | 08:46 |
| pedronis | I asked mborzecki to review #8101 | 08:46 |
| pedronis | as well | 08:46 |
| mup | PR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/8101> | 08:46 |
| pedronis | pstolowski: is not just the GC, is also finalizers, I don't remember in which thread they are run | 08:49 |
| pedronis | pstolowski: the docs have this to say: The finalizer is scheduled to run at some arbitrary time after the program can no longer reach the object to which obj points. | 08:50 |
| pstolowski | pedronis: i see, it's tricky, you probably looked at https://medium.com/a-journey-with-go/go-finalizers-786df8e17687 | 08:57 |
| pedronis | pstolowski: I meand, maybe it's trivial, maybe not | 08:58 |
| pedronis | mvo: you have a weird code typo in 8142 now, also made a nitpick suggestion given it needs at least another commit | 09:04 |
| mvo | pedronis: I just noticed and force pushed the typo thing, sorry for that | 09:06 |
| pedronis | mvo: +1, it needs a 2nd review now, maybe pawel or zygmunt | 09:12 |
| ackk | hi, is the snapd version which supports default tracks targeted to be in focal? | 09:16 |
| mvo | pedronis: thank you | 09:22 |
| mvo | ackk: yes, we plan to go with 2.44 | 09:22 |
| ackk | mvo, nice, thanks | 09:22 |
| * zyga looks forward to end of winter holidays on Monday | 09:26 | |
| zyga | mvo: which branch is that? | 09:26 |
| mvo | zyga: what branch? | 09:27 |
| zyga | to review | 09:27 |
| mup | PR snapd#8154 closed: tests: reset PS1 before possibly interactive dash <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8154> | 09:27 |
| mvo | zyga: 8142 | 09:27 |
| ackk | mvo, is there an ETA for that? asking since we'd like to have the maas transitional package point to the default track | 09:28 |
| zyga | hey ackk | 09:29 |
| ackk | hi zyga | 09:29 |
| zyga | I heard there is some progress on the issue you were long plagued by | 09:29 |
| zyga | I hope we can get to the bottom if ot | 09:29 |
| zyga | *of it | 09:29 |
| ackk | zyga, the snapfuse one? well I can't reproduce it on another machine with 20.04, I hope I can reinstall my laptop soon w/20.04 and test there | 09:30 |
| mvo | ackk: 4-5 weeks until it's in stable | 09:31 |
| ackk | otoh mvo sort of managed to reproduce it | 09:31 |
| ackk | mvo, will you also upload to focal? or will it just be in the snapd snap ? | 09:31 |
| mvo | ackk: we plan to upload to focal | 09:33 |
| ackk | mvo, awesome, thanks | 09:35 |
| zyga | mvo: done | 09:40 |
| mvo | zyga: thank you! | 09:41 |
| mborzecki | hmm so, the input seems ot be working | 09:43 |
| mvo | mborzecki: yay | 09:46 |
| mup | PR snapd#8101 closed: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8101> | 09:47 |
| mborzecki | mvo: heh, it's super ugly ;) | 09:49 |
| zyga | pstolowski: https://github.com/snapcore/snapd/pull/8170#discussion_r382491439 | 09:55 |
| mup | PR #8170: snap-preseed: support for preseeding of snapd and core18 <Preseeding π> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8170> | 09:55 |
| pstolowski | zyga: ty | 09:57 |
| mborzecki | damn, i'm late for the blood tests, got to go | 10:03 |
| mborzecki | pushed the changes to #8156 | 10:03 |
| mup | PR #8156: cmd/snap-bootstrap: subcommand to detect UC chooser trigger <UC20> <β Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8156> | 10:04 |
| pedronis | pstolowski: I made a comment in 8170 | 10:16 |
| pedronis | zyga: whats the status of 8133 ? | 10:17 |
| zyga | pedronis: I think it is non-essential but I want jamie to look at it first | 10:18 |
| zyga | pedronis: after 7614 lands it is no longer needed | 10:18 |
| zyga | pedronis: if it doesn't land it may be a factor for device assignment on arch | 10:18 |
| zyga | pedronis: but I didn't debug deeper to know | 10:19 |
| pedronis | what's the highest priority of these: https://github.com/snapcore/snapd/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+review-requested%3Ajdstrand+author%3Azyga | 10:20 |
| zyga | pedronis: currently 8123 - jamie was looking at yesterday evening but said he will finish in the morning as priority request came in and he had to stop | 10:21 |
| zyga | then 7614 | 10:21 |
| zyga | apart from that last one I'm no longer blocked | 10:21 |
| zyga | I'm iterating on 7825 and it will be ready soon | 10:22 |
| pedronis | I labeled the first and I'm tagging 7614 for 2.45 | 10:22 |
| zyga | thank you | 10:22 |
| zyga | that's great | 10:22 |
| zyga | https://www.irccloud.com/pastebin/eM7kmuRb/ | 10:23 |
| zyga | FAIL: overlord_test.go:694: overlordSuite.TestEnsureLoopPruneAbortsOld | 10:23 |
| pedronis | ah fun | 10:23 |
| pedronis | pstolowski: ^ | 10:24 |
| zyga | darn, my shell still sucks | 10:24 |
| zyga | brb, need to get coffee | 10:24 |
| zyga | pstolowski: the PR it failed on changes some C code, not related to any overlord bits | 10:24 |
| zyga | brb | 10:24 |
| pstolowski | pedronis,zyga : ah, overlordSuite.TestEnsureLoopPruneAbortsOld seems flaky, checking | 10:25 |
| pedronis | pstolowski switching to take control over the ticker channel is probably the best way forward | 10:26 |
| pedronis | if there's no easy fix | 10:26 |
| pstolowski | pedronis: i can prep a quick PR to bump sleep to 1500 (currently 1000) to match all other overlord tests. then will work on proper change in a followup? | 10:27 |
| pedronis | pstolowski: if that helps | 10:28 |
| pedronis | pstolowski: I made another comment in 8170 | 10:29 |
| pedronis | unrelatedly | 10:29 |
| pedronis | pstolowski: I made a nitpick comment in 8210, can be taken care in a follow up, I think it can be merged otherwise | 10:34 |
| zyga | back with coffee | 10:35 |
| pstolowski | pedronis: great, thanks, will do a followup | 10:35 |
| zyga | ok, let's fix that shell mistake | 10:36 |
| zyga | and land another big branch :) | 10:36 |
| mup | PR snapd#8174 opened: tests: bump sleep time of the new overlord tests <Simple π> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8174> | 10:49 |
| zyga | pstolowski: looking at preseed.sh | 10:51 |
| zyga | pstolowski: umount_ubuntu_image can be simplified | 10:51 |
| zyga | pstolowski: you can just umount -l "$IMAGE_MOUNTPOINT/sys" | 10:51 |
| zyga | pstolowski: or better yet, use mount-tool to iterate over them | 10:52 |
| zyga | pstolowski: just nitpick on the code | 10:52 |
| zyga | the part about qemu-nbd is interesting | 10:52 |
| zyga | I need to look at it closer later today if I can | 10:52 |
| zyga | pstolowski: and in setup_preseeding, I would add head -n 1 to ensure that find only gives us one result | 10:53 |
| pstolowski | zyga: nice, thanks, i can address this when later (and i didn't forget about the other issue you found in error path of service wrapers, on my list) | 10:53 |
| pstolowski | s/when// | 10:54 |
| zyga | pstolowski: sure, just looking at it because it said mount :) | 10:54 |
| pstolowski | heh | 10:54 |
| zyga | and I'm waiting for spread to prepare to see if my new shell expression is better | 10:54 |
| mup | PR snapd#8153 closed: [RFC] "snap run --explain" with different formating <Skip spread> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8153> | 10:55 |
| zyga | mvo: hey, what's going on with explain there? | 10:56 |
| zyga | mvo: I should be able to help soon | 10:57 |
| zyga | mvo: this looks important https://bugs.launchpad.net/snapd/+bug/1864096 | 10:59 |
| mup | Bug #1864096: Incomplete search path(s) for xdelta3 executable <snapd:New> <https://launchpad.net/bugs/1864096> | 10:59 |
| zyga | mvo: we may be hitting the store for more downloads than necessary | 10:59 |
| zyga | pedronis: ^ | 10:59 |
| mvo | zyga: it's not clear to me how to push this forward or if the pr I just closed is even the right direction so I closed it to avoid wasting ppls time | 10:59 |
| mvo | zyga: let me look | 11:00 |
| zyga | mvo: can we chat about it (explain) later today | 11:00 |
| zyga | mvo: just pull me into a call if you have a moment and feel like it | 11:00 |
| mvo | zyga: ok | 11:00 |
| mvo | zyga: do you look into this xdelta thing or should I ? should be a simple fix but yeah, agreed that it's annoying | 11:01 |
| zyga | mvo: let me, I'm waiting for another cycle of spread | 11:01 |
| zyga | yeah | 11:01 |
| zyga | mvo: and something for 2.44 | 11:01 |
| zyga | to save on all the bits over all the fiber | 11:01 |
| pedronis | mvo: zyga: there's little point discussion explain without me, I don't think mvo PR was too far off, but it's all in the details at this point | 11:01 |
| zyga | pedronis: aha | 11:02 |
| zyga | pedronis: is there something we can do to make it progress? | 11:02 |
| pedronis | it's probably best to just sketch the api somewhere with usage examples | 11:02 |
| pedronis | than modify the full PR | 11:02 |
| zyga | k | 11:02 |
| zyga | ok | 11:02 |
| pedronis | my issue with the last iteration, is mostly how you had to use explain and start_section independently to into a section, even though conceptually is one thing | 11:04 |
| mvo | zyga: if you want you have a look at my latest code, maybe you have creative ideas, anyway, we can have a quick brainstorm to sketch some api | 11:04 |
| pedronis | s/to into/to intro/ | 11:04 |
| mvo | pedronis: right, yeah, that's a problem | 11:05 |
| mvo | pedronis: there could be a _start_section(text) and "explain_indented()". but probaly needs a bit more time to sketch out something. anyway, having a brainstorm with zyga is probably a good idea and then we can get back to you | 11:06 |
| pedronis | ok | 11:07 |
| pedronis | mvo: also ideally there should be only one function to add a string entry and one for key: value. that probably needs some more state | 11:09 |
| mvo | zyga: can we close 8113 now that it looks like we go with 8123 ? | 11:09 |
| * zyga checks the numbers :) | 11:09 | |
| zyga | I don't remember branch names that well | 11:09 |
| zyga | mvo: I think so but jamie said he will review both today morning | 11:10 |
| zyga | mvo: let's wait one more morning please | 11:10 |
| zyga | mvo: he was looking into it last night but something urgent pulled him | 11:10 |
| mvo | pedronis: yeah, the in-list could be part of the state, we will explore that | 11:11 |
| pedronis | mvo: the point of that it should be hard to add a non "-" prefixed entry in the middle of a list, etc | 11:11 |
| mvo | pedronis: ok | 11:11 |
| mvo | pedronis: https://github.com/snapcore/snapd/pull/7728/files#diff-e4c8d0c72c7b412376e0a04e6ad4db41R37 is an example where this is mixed | 11:12 |
| mup | PR #7728: cmd: implement snap run --explain <Created by zyga> <https://github.com/snapcore/snapd/pull/7728> | 11:12 |
| mvo | i.e. - Creating new per-snap mount namespace | 11:12 |
| mvo | desired mount profile: /var/lib/snapd/mount/snap.test-snapd-sh.fstab | 11:12 |
| mvo | pedronis: but maybe the output should change | 11:12 |
| zyga | but that's by design | 11:12 |
| zyga | that was what the output was meant to look like | 11:13 |
| pedronis | mvo: I don't understand in which sense it's mixed | 11:13 |
| pedronis | there's a list that containts k: v sections | 11:13 |
| pedronis | these thing need to next to some extent | 11:14 |
| pedronis | s/next/nest/ | 11:14 |
| mvo | pedronis: the list-item has a different indent than the following line, that's what I mean | 11:16 |
| pedronis | mvo: I'm probably being obtuse, I still don't understand | 11:17 |
| mvo | pedronis: let me look at your suggestions with fresh eyes I'm probably just haven't thought it through yet | 11:18 |
| pedronis | mvo: I can try to write down a strawman of api signatures, if that helps | 11:21 |
| pedronis | mvo: https://paste.ubuntu.com/p/qRvD3thMdz/ | 11:30 |
| mup | PR snapd#8120 closed: cmd/snap-preseed: snapd version check for the target <Preseeding π> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8120> | 11:38 |
| mvo | pedronis: thank you | 11:43 |
| mborzecki | re | 11:51 |
| zyga | hey maciek | 11:54 |
| zyga | hmm | 11:57 |
| zyga | errtracker tests are failing for me on 20.04 | 11:58 |
| * zyga looks | 11:58 | |
| zyga | https://twitter.com/ubuntu/status/1230795310756245505 | 12:00 |
| mborzecki | brace yourselves, bug reports are coming? :) | 12:02 |
| zyga | brb, | 12:04 |
| mborzecki | hmm random unit test failure in overlord ensure loop? https://paste.ubuntu.com/p/3sxTTChNzh/ | 12:09 |
| sdhd-sascha | hey :-) | 12:14 |
| sdhd-sascha | Is there a way, to do something like that: | 12:14 |
| sdhd-sascha | ``` | 12:14 |
| sdhd-sascha | $ sudo snap install --dangerous --classic <(wget -q -O- https://github.com/sd-hd/runner-snap/releases/download/v2.165.2-19/runner-snap-v2.165.2-19) | 12:14 |
| sdhd-sascha | error: cannot open: "/dev/fd/63" | 12:14 |
| sdhd-sascha | ``` | 12:14 |
| sdhd-sascha | The problem here seems to be `sudo` | 12:14 |
| sdhd-sascha | With `root` it works. | 12:14 |
| zyga | mborzecki: PaweΕ sent a PR for that failure | 12:17 |
| mborzecki | ah, cool, my mind is still stuck with input and debuild/dpkg -i snapd & ubuntu-core-initramfs loop | 12:18 |
| sdhd-sascha | I can't find a option for sudo, to preserve the file descriptors on fork :-( | 12:25 |
| sdhd-sascha | Oh, i found it `sudo -C <num>` . Now i get `sudo: you are not permitted to use the -C option` | 12:28 |
| sdhd-sascha | Thank you. I will figure it out now. | 12:28 |
| pedronis | sdhd-sascha: either way, snap install takes only snap names or filenames, it doesn't install from stdin | 12:32 |
| mborzecki | haha, so got the chooser trigger and service into initramfs and in my vm, the initramfs pivots earlier than the trigger is fired ;) | 12:32 |
| sdhd-sascha | pedronis the `<( ... )` inside bash, creates a file descriptor | 12:32 |
| sdhd-sascha | pedronis: so it's like a local file. But wget is non `sudo/root` but `snap install` is uid=0... | 12:33 |
| sdhd-sascha | pedronis if often do this: `diff <(grep ....) <(grep ...) | 12:34 |
| sdhd-sascha | pedronis: this is nice: | 12:35 |
| sdhd-sascha | ``` | 12:35 |
| sdhd-sascha | $ ls -l <(echo "hello world") | 12:35 |
| sdhd-sascha | lr-x------ 1 sascha sascha 64 Feb 21 13:34 /dev/fd/63 -> 'pipe:[22821730]' | 12:35 |
| sdhd-sascha | ``` | 12:35 |
| zyga | hmm | 12:35 |
| zyga | anyone here using 20.04 | 12:35 |
| zyga | or otherwise, can anyone run errtracker tests? | 12:35 |
| zyga | they keep failing for me and I cannot see why | 12:35 |
| * zyga digs into that | 12:38 | |
| zyga | bah, another spread wasted on prune failure | 12:41 |
| sdhd-sascha | pedronis: i got it :-) | 12:55 |
| sdhd-sascha | I added this line to /etc/sudoers: `Defaults closefrom_override` | 12:55 |
| sdhd-sascha | Then this works: | 12:55 |
| sdhd-sascha | `sudo -C 99999 snap install --dangerous --classic <(wget -q -O- https://github.com/sd-hd/runner-snap/releases/download/v2.165.2-19/runner-snap-v2.165.2-19)` | 12:55 |
| sdhd-sascha | Thank you :-) | 12:55 |
| pstolowski | cachio: hi, have you enabled manual/preseed test in nightly? | 13:08 |
| zyga | gaah | 13:11 |
| zyga | I debugged it | 13:11 |
| zyga | missing mocking | 13:11 |
| mup | PR snapcraft#2948 closed: Regenerate the GDK pixbuf loaders cache file if for whatever reason it isn't there (LP: #1863801) <Created by oSoMoN> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2948> | 13:17 |
| zyga | lp times out | 13:19 |
| zyga | eh | 13:19 |
| zyga | ok | 13:19 |
| zyga | I'm parking this for now: https://bugs.launchpad.net/snapd/+bug/1864197 | 13:20 |
| mup | Bug #1864197: errtracker unit tests interact with real whoopsie.service <snapd:New> <https://launchpad.net/bugs/1864197> | 13:20 |
| === pedronis_ is now known as pedronis | ||
| sdhd-sascha | Can i give snapcraft a default configuration for a snap? Or better use hooks for setting them ? | 13:20 |
| sdhd-sascha | Wait. I ask on #snapcraft. Sorry | 13:22 |
| zyga | sdhd-sascha: 1) no 2) it could | 13:23 |
| sdhd-sascha | zyga: thank you :-) | 13:23 |
| mup | PR snapd#8175 opened: store: rely on CommandFromSystem snap to find xdelta3 <Created by zyga> <https://github.com/snapcore/snapd/pull/8175> | 13:28 |
| zyga | mvo: I opened https://github.com/snapcore/snapd/pull/8175 as draft, I have a small second patch that improves CommandFromSystemSnap but it's not essential | 13:29 |
| mup | PR #8175: store: rely on CommandFromSystemSnap to find xdelta3 <Created by zyga> <https://github.com/snapcore/snapd/pull/8175> | 13:29 |
| zyga | pstolowski: master is broken on TestEnsureLoopPruneAbortsOld | 13:30 |
| zyga | pstolowski: what's the state of your PR, I see it is yellow | 13:30 |
| pstolowski | zyga: PR is already up but fails on random stuff | 13:30 |
| zyga | which stuff? | 13:30 |
| pstolowski | zyga: timed out on prepare | 13:31 |
| zyga | aha | 13:31 |
| zyga | oh well :) | 13:31 |
| pedronis | mvo: I did a pass on #8100, the main issue there is how we name things | 13:36 |
| mup | PR #8100: httputil: add support for extra snapd certs <Created by mvo5> <https://github.com/snapcore/snapd/pull/8100> | 13:36 |
| zyga | pstolowski: do you know why it got worse? | 13:39 |
| zyga | I see it now even in travis-ran quick run of tests | 13:39 |
| zyga | even before spread starts | 13:39 |
| pstolowski | what do you see? the failure of TestEnsureLoopPruneAbortsOld? | 13:40 |
| zyga | yes | 13:40 |
| zyga | https://github.com/snapcore/snapd/pull/8175 look here https://travis-ci.org/snapcore/snapd/builds/653455121 | 13:40 |
| mup | PR #8175: store: rely on CommandFromSystemSnap to find xdelta3 <Created by zyga> <https://github.com/snapcore/snapd/pull/8175> | 13:40 |
| pstolowski | zyga: i didn't get worse, it landed yesterday and we probably were lucky. I used 1000ms timeout instead of 1500 like every other test does in this testsuite | 13:40 |
| zyga | mmmm | 13:41 |
| zyga | I see | 13:41 |
| zyga | ok | 13:41 |
| zyga | let's fix that with spread pass-through maybe | 13:41 |
| zyga | it's super annoying when master breaks and we restart everything like a stuck computer | 13:41 |
| pstolowski | zyga: ok, added the label although i wonder what happens after it already is in progress. perhaps it needs to pass anyway ;). it would only help on opening the pr? | 13:43 |
| zyga | dunno | 13:43 |
| zyga | we'll find out | 13:43 |
| zyga | thank you! :) | 13:43 |
| sdhd-sascha | Should `snapctl get <key>` return an error, if the key does not exist ? Maybe as additional param ? | 13:55 |
| sdhd-sascha | `parts/snapd/src/overlord/hookstate/ctlcmd/get.go` | 13:55 |
| sdhd-sascha | Then i could use on bash this: `user=$(snapctl get --errror-on-missing || echo "root")` | 13:55 |
| sdhd-sascha | i mean: `user=$(snapctl get --errror-on-missing userkey || echo "root")` | 13:55 |
| zyga | pstolowski: it is in | 14:00 |
| pstolowski | zyga: great; did it pass? | 14:00 |
| zyga | it got green | 14:01 |
| mup | PR snapd#8174 closed: tests: bump sleep time of the new overlord tests <Simple π> <Skip spread> <β Critical> <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8174> | 14:01 |
| zyga | but I didn't look | 14:01 |
| zyga | I just want it in, we can iterate more now | 14:01 |
| zyga | pstolowski: it did pass | 14:01 |
| zyga | pstolowski: it ran a full iteration of tests | 14:01 |
| pstolowski | good | 14:01 |
| pedronis | mborzecki: #6708 seems to have a real failure atm | 14:37 |
| mup | PR #6708: tests/main/buildmode: verify usability of PIE hardening for deb packages <β Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6708> | 14:37 |
| pedronis | ijohnson: what's the status with #8152, will push more to it? should we close it until it's more ready? | 14:38 |
| mup | PR #8152: managers_test: add uc20 kernel snap update happy and panic tests <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8152> | 14:38 |
| ijohnson | pedronis: it's fine to close it I need to push more changes to it, but it will likely look different | 14:38 |
| pedronis | ijohnson: then better to close it, there is still quite a chain behind it anyway | 14:39 |
| pedronis | afaiu | 14:39 |
| ijohnson | yes, also I'll close 8151 too | 14:39 |
| mup | PR snapd#8151 closed: cmd/snap-bootstrap/initramfs-mounts: only write modeenv if it changed <Simple π> <UC20> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8151> | 14:40 |
| ijohnson | pedronis: are you going to close it or should I? | 14:40 |
| jdstrand | zyga, pedronis: fyi, finish PR 8123 | 14:41 |
| mup | PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123> | 14:41 |
| zyga | jdstrand: ack | 14:41 |
| zyga | jdstrand: can we close the (a) variant now? | 14:41 |
| jdstrand | (I did PR 8113 yesterday) | 14:41 |
| mup | PR #8113: cmd/snap-confine: bring /var/lib/dhcp from host, if present (approach a) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8113> | 14:41 |
| jdstrand | zyga: I think you need to read my PR review :) | 14:41 |
| zyga | ok | 14:41 |
| zyga | jdstrand: this PR will create /var/lib/dhcp on the host when it exists | 14:42 |
| zyga | did you mean to say | 14:42 |
| zyga | when it not exists? | 14:42 |
| zyga | or do I parse that wrong? | 14:42 |
| jdstrand | zyga: typo, reload | 14:42 |
| zyga | ok | 14:42 |
| jdstrand | so, my opinion on closing 8113 is that it is up to you. 8123 can be made ok, but perhaps it should come later | 14:45 |
| zyga | I see, I have no strong preference to either - I did (b) based on a comment on (a) - | 14:45 |
| jdstrand | zyga: the future is definitely b | 14:46 |
| pedronis | on that agree | 14:46 |
| pedronis | we really want to move to the style of b | 14:46 |
| zyga | I only have one thing that I feel stronger about - if the interface promises write access to $foo and $foo is a read only empty place-holder in the core snap we have a problem - it needs to be resolved somehow | 14:46 |
| jdstrand | zyga: but up to your team's priorities on how to tackle it | 14:46 |
| pedronis | because things in snap-confine don't scale | 14:46 |
| zyga | I think in this case making the directory is the actual correct thing to do, even if that's perhaps a new thing snapd does | 14:46 |
| * ijohnson goes to close #8152 | 14:47 | |
| mup | PR #8152: managers_test: add uc20 kernel snap update happy and panic tests <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8152> | 14:47 |
| zyga | as for the rest, I'll read the feedback carefully | 14:47 |
| zyga | I'll discuss with pedronis and mvo as to what to do for 2.44 | 14:47 |
| zyga | and beyond | 14:47 |
| jdstrand | zyga: that bit about auto ns rules is just me thinking out loud | 14:47 |
| jdstrand | I feel pretty strongly that we shouldn't leak the dir creation to hostfs | 14:47 |
| zyga | jdstrand: but that's the actual intent, to interact with the host - that's how I understand the interface | 14:48 |
| zyga | otherwise access to /var/lib/dhcp is meaningless because there is nothing there | 14:48 |
| jdstrand | zyga: but the act is hollow. there is nothing on the host looking at /var/lib/dhcp | 14:48 |
| mup | PR snapd#8152 closed: managers_test: add uc20 kernel snap update happy and panic tests <Test Robustness> <UC20> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8152> | 14:48 |
| zyga | jdstrand: the question is time, yet, perhaps the snap will put files there and users will follow docs to go and find them | 14:49 |
| pedronis | jdstrand: notice though that the directory could be created in the host later than connection time | 14:49 |
| zyga | jdstrand: perhaps later on classic app goes to loop | 14:49 |
| zyga | jdstrand: it's not such clear cut IMO | 14:49 |
| jdstrand | zyga: the snap can put anything it wants there. the *host* is not looking at them | 14:49 |
| jdstrand | zyga: we aren't trying to create an alternate storage location, we're trying to let the snap interact with the host via things in this dir | 14:49 |
| zyga | jdstrand: perhaps a monitoring solution does, you can install dhcpd from a snap and tie it to something else; I think it's not out of the question that is a possible use case | 14:50 |
| jdstrand | zyga: a dhcpd snap is going to use content then | 14:50 |
| pedronis | well the interface gives rw access under there | 14:50 |
| zyga | I think we need to consider three options: 1) change the interface so that this is not a problem 2) do not create the directory 3) create the directory | 14:51 |
| zyga | and pick something sensible out of that set | 14:51 |
| pedronis | jdstrand: to be clear not creating it is fine, but what if it gets created in the host after the interface was connected? | 14:51 |
| jdstrand | I don't know how else to say it. the apparmor rules are there because at one time they meant something. on a system without /var/lib/dhcp, they don't mean anything | 14:52 |
| zyga | pedronis: interface connection creates it on the host | 14:52 |
| zyga | pedronis: it's really visible in /var/lib/dhcp that's the logic of (b) now | 14:52 |
| pedronis | zyga: yes, but jdstrand doesn't want that behavior | 14:52 |
| zyga | ah | 14:52 |
| pedronis | but what behavior does he want | 14:52 |
| zyga | sorry, I misunderstood your question | 14:52 |
| pedronis | in that case | 14:52 |
| jdstrand | eg, on a system with no /var/lib/dhcp, the snap starts, the dir is created, it puts a lease file in there. *nothing* on the host will do anything with *anything* the snap puts in there | 14:53 |
| jdstrand | it is a hollow act | 14:53 |
| zyga | jdstrand: sure but maybe that's good enough | 14:53 |
| zyga | jdstrand: because users are trained to look there | 14:53 |
| jdstrand | if the dir exists, the monitor might be looking for things in there that will *never* come | 14:53 |
| zyga | (e.g. admins) | 14:53 |
| jdstrand | huh? | 14:53 |
| zyga | jdstrand: I can install core system | 14:53 |
| zyga | jdstrand: install a dhcp solution there | 14:53 |
| zyga | jdstrand: and get it to operate my network | 14:53 |
| zyga | jdstrand: I can go to /var/lib/dhcp | 14:53 |
| zyga | and even though it wasn't there before, I see files the snap has put there | 14:54 |
| jdstrand | zyga: that is a totally different thing | 14:54 |
| zyga | logs, leases, etc | 14:54 |
| zyga | jdstrand: (on second though that system could be either core or classic) | 14:54 |
| jdstrand | zyga: this is about implied plugs, you are talking about a slot | 14:54 |
| mvo | zyga: in a meeting right now, will try to read backlog | 14:54 |
| zyga | jdstrand: I think I'm talking about neither - just the user experience of installing a snap and seeing lease files in a familiar location | 14:54 |
| zyga | jdstrand: but perhaps I don't understand your point of view | 14:54 |
| zyga | jdstrand: because I think I'm saying the same thing now | 14:55 |
| jdstrand | zyga: the user experience is already different on a system without a dhcpd solution. there is no /var/lib/dhcpd | 14:55 |
| jdstrand | zyga: that is the implied case, which is all network-control implements | 14:56 |
| jdstrand | zyga: a slot implementation for dhcpd would either need a new interface or network-control adjusted accordingly to be either implied or slot provided | 14:56 |
| zyga | jdstrand: I think the question is, if you have no /var/lib/$foo and a snap managing it is installed, should it see a private copy of $foo and the host is not altered or not | 14:57 |
| zyga | jdstrand: isn't dhcpd just a network socket? you can probably implement one with network-bind already | 14:57 |
| zyga | jdstrand: I can see a point where /var/lib/$foo is really stored in $SNAP_DATA | 14:57 |
| zyga | (and layouts can be used to make the per-snap view more familiar) | 14:58 |
| zyga | but I can also counter that to say that we give snaps host access for a reason (there are specific interfaces and implicit mounts performed by snap confine) | 14:58 |
| zyga | I really think it's not a correctness POV just a policy of what we want to do | 14:59 |
| zyga | either way is fine if we are consistent and it is documented well | 14:59 |
| pedronis | jdstrand: anyway, you haven't answered what is your expectation, if the directory gets created host side after a snap is connected. should we just ignore this, should we monitor creation and try to patch the rules and namespace after the fact? | 14:59 |
| jdstrand | jdstrand: ime, it doesn't make sense for an *implied* plugs interface to create a dir. the implied interface is about interacting with core or classic. by definition, if /var/lib/dhcp doesn't exist on core/classic, there can be no interaction with core/classic via /var/lib/dhcp | 14:59 |
| zyga | jdstrand: for the record, it does exist on core but some classic distributions do not have it in the images we use | 15:00 |
| jdstrand | pedronis: I put in the PR a suggestion. I think we need the equivalent behavior of .is_optional. ie, at runtime, snap-update-ns sees if it exists, if it does, cool, do what is in the PR now. if not, move along | 15:01 |
| jdstrand | zyga: that's fine. it is probably a bug on core if it ships the directory but isn't using it, but that is a different issue | 15:02 |
| zyga | jdstrand: we can do that, though creation on the host is not monitored by anything so it would not be "plugged" into the app at a later stage until some other mount operation did it by coincidence | 15:02 |
| zyga | jdstrand: it works on core16 + core16 because of implicit sharing | 15:02 |
| zyga | jdstrand: it is broken on core18 because then sharing is not automatic (hence (a) was quickly made) | 15:03 |
| zyga | that's just for context, it's not changing what you said | 15:03 |
| jdstrand | zyga: snap-update-ns may need to be updated then, sure. this is getting at why I thought 8113 first would at least fix the bug. we already have thought about this by introducing .is_optional btw. with 8123, we just need to think through what the right implementation would be for when to perform the mount | 15:04 |
| zyga | jdstrand: I understand, I think for that we'd need a component to monitor directories and react (snapd, inotify, etc) but it's somewhat fragile and racy by its very nature (100% uptime of said component) | 15:05 |
| zyga | but we could come up with something | 15:05 |
| jdstrand | zyga: basically, my suggestion is that the PR is as it is now, but with snap-update-ns being modified to know when to check for dir existence and skip the creation if it doesn't | 15:05 |
| zyga | I wonder what the snap should see before that directory exists on the host | 15:05 |
| zyga | an empty directory from the base? | 15:05 |
| jdstrand | zyga: I didn't see it as that complicated, but maybe I am being naive | 15:05 |
| zyga | jdstrand: I understane | 15:05 |
| zyga | *d | 15:06 |
| jdstrand | zyga: eg, snap-update-ns on first run/after discard does the check and skips if not there | 15:06 |
| jdstrand | zyga: that would by 'enough' for me to approve the PR. trying to handle avoiding a snap-discard-ns after someone installs dhcpd via deb/rpm could be a later step. of, snap-update-ns notices that it now exists but there is a mount namesapce, so it dtrt | 15:08 |
| pedronis | zyga: I don't think we need to monitor directories until somebody really needs it | 15:08 |
| jdstrand | s/of,/or,/ | 15:08 |
| pedronis | dchp is not such a case | 15:08 |
| zyga | mhm | 15:08 |
| jdstrand | pedronis: ? | 15:08 |
| pedronis | I was answering to: zyga> jdstrand: I understand, I think for that we'd need a component to monitor directories and react (snapd, inotify, etc) but it's somewhat fragile and racy by its very nature (100% uptime of said component) | 15:09 |
| jdstrand | I don't think we need a monitor | 15:09 |
| zyga | note that technically handling it like .is_optional is not hard, if that's the semantics we are after I can make the changes easily | 15:10 |
| zyga | if that's the agreement I will get to work | 15:10 |
| jdstrand | I mean maybe we could, it is not that different from connecting a content interface I guess, but it doesn't seem unreasonable to restart the snap if dhcpd is installed after the fact. that is up to you. we don't really doing anything that I am aware of with already running snaps when things change in other things exposed via implied interfaces | 15:11 |
| pedronis | I think it works for now, there may be use cases where it doesn't make sense, but shouldn't stop to progress a bit | 15:11 |
| jdstrand | (and by restart the snap, I am saying that is user-driven, not snapd) | 15:11 |
| pedronis | I mean that doing what is_optional does | 15:11 |
| zyga | ack | 15:11 |
| zyga | sure, I'll make that happen | 15:11 |
| pedronis | how close is a) to land? | 15:12 |
| zyga | a) could land now I guess | 15:12 |
| zyga | I can undo a) in an iteration of b) | 15:12 |
| zyga | let me double check | 15:12 |
| pedronis | jdstrand: I don't see a review by you in a) ? | 15:12 |
| pedronis | zyga: jdstrand: anyway I would be fine landing a) in 2.44 and trying to aim for b) in 2.45 | 15:13 |
| jdstrand | pedronis: I will approve now. I didn't yesterday (I left a comment) because I didn't want a second approval to accidentally imply 'merge me now' | 15:13 |
| zyga | ok | 15:13 |
| pedronis | assuming a) gets 2 +1 | 15:13 |
| zyga | that's fine with me, we fix the bug for 2.44 and make it nicer as we move on, most of the code in (b) is good, there's a small improvement on how some bits are computed that Jamie suggested and a few tweaks to implement is_optional semantics | 15:14 |
| zyga | and a revert of a) | 15:14 |
| zyga | and we should be able to have it next week | 15:14 |
| zyga | are we in agreement? | 15:14 |
| jdstrand | 8113 is approved | 15:14 |
| jdstrand | zyga: note, those auto-rules aren't a requirement. it just feels like a missed opportunity, but maybe with more thought, we can't (or we can only do some safely) | 15:15 |
| * jdstrand is fine with whatever you decide in terms of priorities | 15:16 | |
| zyga | I suspect we can. Your comment there was spot on. It will be hard to understand in a short while otherwise | 15:16 |
| pedronis | anyway that comment is why I think it feels like 2.45 material | 15:17 |
| jdstrand | that was my feeling as well, but again, I defer | 15:17 |
| pedronis | it would be good to make doing such things reasonable | 15:17 |
| pedronis | /readable | 15:17 |
| zyga | Yes I think thatβs a worthy goal :-) | 15:17 |
| zyga | Ok I think we are in agreement now | 15:18 |
| zyga | I take your silence as a yes | 15:18 |
| jdstrand | while we are in agreement, I will also mention since you said this is actually a cross-distro thing, that if snapd created /var/lib/dhcp, a fedora/arch/whoever user would probably file a bug asking why snapd is littering the filesystem | 15:20 |
| jdstrand | (I can almost read the report in my head ;) | 15:20 |
| jdstrand | so it is good to avoid that bug as well :) | 15:20 |
| pedronis | I moved b to 2.45 | 15:20 |
| zyga | jdstrand: Iβm not sure. Itβs just the package selection we have. Installing some other bit in those systems would create that directory | 15:20 |
| jdstrand | zyga: right, but if they *don't* install it but snapd is just putting it there, I can easily see someone complaining | 15:21 |
| zyga | Yeah, but only when connecting to something that might use it | 15:21 |
| zyga | Not just out of the box | 15:21 |
| jdstrand | regardless, we are in agreement for other reasons so my thoughts on avoided potential bugs doesn't really mean anything :) | 15:22 |
| zyga | Yes! | 15:22 |
| zyga | Iβll get to it after current branches move | 15:22 |
| * jdstrand has a *lot* of experience with rather, shall we say, opinionated users in dealing with triaging random bugs flagged as security in Ubuntu ;) | 15:23 | |
| jdstrand | perhaps I'm jaded... :) | 15:23 |
| * cachio lunch | 15:24 | |
| jdstrand | anyway, cool | 15:25 |
| jdstrand | again, sorry it took awhile to get to these. while 8113 and 8123 weren't terribly time consuming, they were behind 7825 and I needed a big hunk of time for that one that was really hard to find | 15:25 |
| jdstrand | 7980 needed a fair chunk as well | 15:26 |
| jdstrand | anyhoo, past all those. unfortunately, there are other big ones in my list... | 15:26 |
| jdstrand | but hey, it is all before 2.44 so... :) | 15:26 |
| jdstrand | (not to mention 8165 that floated in. coverity is really awesome, but investigating its findings takes time) | 15:28 |
| zyga | Oh, about that the Coverity is confusing and there are 3 things from the scan in 2017 | 15:32 |
| zyga | Iβll fix them next week | 15:32 |
| zyga | They are shown in a different list | 15:32 |
| zyga | back from dinner | 15:54 |
| mup | PR snapd#8113 closed: cmd/snap-confine: bring /var/lib/dhcp from host, if present (approach a) <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8113> | 15:56 |
| mup | PR snapd#8175 closed: store: rely on CommandFromSystemSnap to find xdelta3 <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8175> | 15:56 |
| zyga | jdstrand: one more thing, do you think you can quickly look at https://github.com/snapcore/snapd/pull/8133 and tell me if that's something we should even do - it pops up on arch with apparmor when using device assignment | 15:57 |
| mup | PR #8133: cmd/snap-confine: allow snap-confine to load nss libs <β Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/8133> | 15:57 |
| zyga | jdstrand: the diff is just 5 lines of snap-confine profile | 15:57 |
| jdstrand | yeah, I planned to | 15:57 |
| zyga | I'm somewhat meh, probably not worth it but I don't have arch and didn't see it myself | 15:57 |
| zyga | and it will go away with the changes in snap-confine anyway | 15:58 |
| zyga | thanks! | 15:58 |
| * zyga is down to 11 | 15:58 | |
| jdstrand | zyga: I have an opinion and context for it | 15:59 |
| * jdstrand is responding | 15:59 | |
| zyga | thanks! | 15:59 |
| zyga | https://github.com/snapcore/snapd/pull/8171 needs a 2nd review | 16:03 |
| mup | PR #8171: cmd/snap-failure/snapd: also rm snapd.socket if it still exists <Simple π> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8171> | 16:03 |
| zyga | cachio: can you rebase https://github.com/snapcore/snapd/pull/8173 | 16:04 |
| mup | PR #8173: tests: adding arch-linux execution <Simple π> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8173> | 16:04 |
| zyga | pedronis: I summarized the discussion on https://github.com/snapcore/snapd/pull/8123#issuecomment-589719128 | 16:07 |
| mup | PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123> | 16:07 |
| mborzecki | mvo: pedronis: slightly meh, but i added Before=console-conf@tty1 and changes the service to Type=oneshot, consoleconf now waits for trigger to exit, so we don't have to stop it explicitly, the downside its that console-conf start is delayed by the amount of time we wait for the trigger | 16:11 |
| mup | PR snapcraft#2951 closed: snap-packaging: remove broken host-compatibility check for runner <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2951> | 16:12 |
| mvo | mborzecki: I think that's not too bad, how long do we wait? | 16:12 |
| pedronis | mborzecki: yea, we'll need to rethink this but for now at least is correct | 16:12 |
| mborzecki | mvo: i can set the deafult timeout to say 10s, and the key must be held for 2s to trigger the event, upon which it exits right away, so if you hold the key the delay isn't as problematic | 16:13 |
| jdstrand | zyga: done | 16:13 |
| zyga | I read | 16:14 |
| zyga | thanks | 16:14 |
| zyga | that's my understanding as well | 16:14 |
| zyga | I'll flip it around and merge with your implicit approval, is that okay? | 16:14 |
| jdstrand | zyga: well, I requested changes. just ping me and I'll scan/approve | 16:15 |
| jdstrand | it is still morning here so I'm not going anywhere for a while :) | 16:15 |
| zyga | jdstrand: ack | 16:16 |
| zyga | I'll just do it now | 16:16 |
| zyga | jdstrand: done | 16:18 |
| jdstrand | zyga: well, sorry, but I'd prefer them at the every end with the other explicit denials. having it here clutters that section | 16:19 |
| zyga | jdstrand: sure | 16:20 |
| jdstrand | thanks! | 16:20 |
| * jdstrand is poised to approve | 16:20 | |
| zyga | done | 16:21 |
| ijohnson | cachio: let me know if you want me to remove the changes adding snap-auto-import-asserts-spools, snap-auto-import-asserts and snap-auto-mount tests for ARM devices, I'm happy to enable those later and land #8140 sooner, I'm adding your requested changes now | 16:21 |
| mup | PR #8140: tests: enable more tests for UC20/UC18 <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8140> | 16:21 |
| * zyga high-fives jdstrand for fast review cycles :) | 16:21 | |
| ijohnson | cachio: I made the other changes except for the uc20 arm model names, do we know what those model names will look like? will it be the same as the uc18 ones just with s/18/20/ ? | 16:24 |
| mup | PR snapcraft#2950 closed: meta: Snap to_dict() cleanup <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2950> | 16:27 |
| * zyga breaks for a moment to let the laptop charge and back up | 16:28 | |
| jdstrand | zyga: done | 16:30 |
| jdstrand | 5 | 16:30 |
| jdstrand | o/ | 16:30 |
| zyga | :-) | 16:36 |
| cachio | ijohnson, nice | 16:45 |
| cachio | yes, I prefer to enable those tests later for arm | 16:45 |
| ijohnson | cachio: ack | 16:50 |
| ijohnson | Did you see my questing about the name of the arm model | 16:50 |
| cachio | ijohnson, no yet, I am with amazon linux, I'll see that in 5 minutes | 16:52 |
| ijohnson | Sure no rush | 16:53 |
| zyga | pstolowski: https://github.com/snapcore/snapd/pull/8170/files#diff-eb9825aa18d9bbbcc41ca31728af8157R88 still needs work, right? | 16:55 |
| mup | PR #8170: snap-preseed: support for preseeding of snapd and core18 <Preseeding π> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8170> | 16:55 |
| zyga | I am on child care service now | 16:55 |
| zyga | fingers crossed she doesn't wake up for a few hours | 16:56 |
| zyga | $wife and $kids went for groceries now | 16:56 |
| pstolowski | zyga: yes, it needs work | 16:56 |
| zyga | ok | 16:56 |
| zyga | pedronis: does this ring a bell? | 17:07 |
| zyga | Feb 20 20:41:39 jbl-ThinkPad-P53 snapd[1101]: stateengine.go:150: state ensure error: devicemgr: cannot resolve prerequisite assertion: account (EH9A6Xg1QtCjYt4v3QlBVTPLAHDvEIn6) | 17:07 |
| cachio | ijohnson, answered | 17:08 |
| pedronis | zyga: what's the context | 17:08 |
| ijohnson | thanks cachio | 17:08 |
| cachio | but no idea | 17:09 |
| zyga | pedronis: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1864113 | 17:09 |
| mup | Bug #1864113: snapd.seeded.service never starts <amd64> <apport-bug> <focal> <rls-ff-incoming> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1864113> | 17:09 |
| zyga | pedronis: seeded never completes | 17:09 |
| pedronis | somebody didn't build the seed properly | 17:10 |
| zyga | this is focal server ISO | 17:10 |
| zyga | perhaps we need to ping foundations? | 17:10 |
| pedronis | yes | 17:11 |
| zyga | should I reach out to steve? | 17:11 |
| pedronis | I don't know, it's not snapd bug though | 17:11 |
| pedronis | it's an image bug | 17:11 |
| mborzecki | idk if it's related but built core20 and the install got stuck and never completed | 17:11 |
| cachio | ijohnson, perhaps we could just skip the test on uc20 until we have the names | 17:12 |
| ijohnson | cachio: I think I'll just have the test be skipped on uc20 arm | 17:12 |
| ijohnson | pedronis: zyga: sounds like the issue that was just reported in #snappy-internal a while ago | 17:13 |
| zyga | aha, thank you, I'll check | 17:13 |
| cachio | ijohnson, makes sense, thanks | 17:15 |
| mborzecki | wondering whether we should limit the chooser only to specific ttys eg. tty1 & ttyS0 | 17:16 |
| pedronis | mborzecki: that's what I asked | 17:16 |
| pedronis | it should be at least an option at some point | 17:17 |
| mborzecki | ok, so i've got the patches for subiquity, ubuntu-core-initramfs, core20 and snapd now | 17:18 |
| mborzecki | there's one weird sceanrio when i'm trying to invoke the chooser when the system boots right after install, for some reason the chooser-trigger service does not start consistenty | 17:19 |
| mborzecki | but it's just fine on subsequent boots | 17:19 |
| mborzecki | nvm, more on monday probably | 17:19 |
| mup | PR snapd#7980 closed: packaging,snap-confine: stop being setgid root <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7980> | 17:24 |
| zyga | that's in, woot | 17:29 |
| ijohnson | nice zyga so that's the last of the opensuse requested changes ? | 17:33 |
| zyga | ijohnson: close | 17:33 |
| zyga | ijohnson: there are a few more, I need to revisit | 17:33 |
| zyga | we need to fix SNAP_COOKIE | 17:33 |
| zyga | ijohnson: they also asked for a group to control snap-confine executability | 17:33 |
| ijohnson | zyga: ah right I remember this now too | 17:33 |
| zyga | so that it's group executable only | 17:33 |
| zyga | I think that's a low hanging fruit | 17:33 |
| zyga | jdstrand: ^ right? snap-confine being root:snapd-users and only g+x | 17:34 |
| zyga | ijohnson: I may apply that last bit in a suse specific patch though | 17:34 |
| zyga | and there's the issue of +s snap-confine in core | 17:34 |
| jdstrand | otoh, I do seem to remember that | 17:34 |
| mup | PR snapd#8176 opened: tests: adding amazon linux to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8176> | 17:35 |
| jdstrand | 4750 root:something | 17:35 |
| zyga | I need to look if I can mount core without setuid root | 17:35 |
| zyga | jdstrand: mhm | 17:35 |
| pedronis | zyga: I fixed SNAP_COOKIE | 17:35 |
| zyga | pedronis: oh, cool, I didn't know that | 17:35 |
| pedronis | I think | 17:35 |
| zyga | I'll go through their review next week and update the bug on monday | 17:35 |
| zyga | but I think this is a hell lot closer now :) | 17:36 |
| jdstrand | zyga: we probably need some niceties in snap run to fail gracefully in that environment for people not in the group | 17:36 |
| zyga | jdstrand: indeed | 17:36 |
| jdstrand | zyga: or at least, double check it :) | 17:36 |
| zyga | jdstrand: but fortunately that's in snap-run so not security critical and can be easily made to be nice | 17:36 |
| pedronis | zyga: jdstrand: https://github.com/snapcore/snapd/blob/master/overlord/snapstate/cookies.go#L152 | 17:36 |
| zyga | that's great! | 17:36 |
| zyga | Thanks for the reference, I'll use it in the review of their review | 17:37 |
| pedronis | and https://github.com/snapcore/snapd/blob/master/randutil/crypto.go | 17:37 |
| jdstrand | zyga: yep | 17:37 |
| * cachio afk - doc appointment | 17:37 | |
| mup | PR snapcraft#2932 closed: elf: resolve paths in `ldd()` to purge relative path components <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2932> | 18:27 |
| mup | PR snapd#8177 opened: cmd/snap-bootstrap/initramfs-mounts: mount the snapd snap in run-mode too <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8177> | 19:08 |
| mup | PR core20#22 opened: run-snapd-from-snap: don't try to load a snapd snap from the seed anymore <Created by anonymouse64> <https://github.com/snapcore/core20/pull/22> | 19:11 |
| sdeziel | hello, I'm trying to export a custom variable for a snap but can't find how/where to do that | 19:23 |
| ijohnson | sdeziel: you mean in a snap you are developing? | 19:25 |
| sdeziel | ijohnson: no, sorry I was not clear. I want to export it in a snap I *use* (chromium to be precise) | 19:30 |
| ijohnson | can you just do `VAR=thing chromium` ? | 19:30 |
| ijohnson | err is there a reason you can't just do that ? | 19:30 |
| sdeziel | ideally, it would work when I click the chromium's icon | 19:30 |
| sdeziel | ijohnson: I was thinking of something like /etc/environments in the snap's FS | 19:31 |
| ijohnson | AFAIK, /etc/environment should work for snaps too | 19:31 |
| sdeziel | right but that's system-wide, not snap specific | 19:32 |
| ijohnson | Hmm, I don't think we have something like that that's per-snap and per-installation. Since you want it when you click an icon, you might be able to fiddle with the desktop file | 19:34 |
| sdeziel | ijohnson: isn't the desktop file recreated on every snap refresh? | 19:36 |
| ijohnson | hmm perhaps they are. I'm not super familiar with how desktop files work, perhaps you could ask someone in #ubuntu-desktop ? | 19:39 |
| sdeziel | ijohnson: "MESA_GLSL_CACHE_DISABLE=true chromium" didn't run which I would be inclined to think is normal assuming there is some env scrubbing going on | 19:45 |
| sdeziel | s/didn't run/didn't work/ | 19:45 |
| ijohnson | hmm that's odd | 19:46 |
| ijohnson | that works for me: | 19:46 |
| ijohnson | https://www.irccloud.com/pastebin/v4uNy7Ru/ | 19:46 |
| ijohnson | and if I try that with the chromium snap it works too, at least with --shell. | 19:46 |
| ijohnson | it's possible that the chromium snap specifically is doing some sort of env scrubbing | 19:47 |
| sdeziel | ijohnson: my bad, I had another chromium instance running which prevented the flag to be picked | 19:47 |
| sdeziel | it does work to use that var=$val prefix | 19:47 |
| sdeziel | ijohnson: thanks for your help btw | 19:51 |
| ijohnson | np happy to help, good luck with the desktop icon thing | 19:52 |
| sdeziel | ijohnson: I do have a workaround but I still believe it's not a special edge case to want to export vars per-snap. Any idea where I could make that wishlist request? | 19:53 |
| ijohnson | you could file a bug at bugs.launchpad.net/snapd or you could make a forum post at forum.snapcraft.io about it | 19:53 |
| sdeziel | thx | 19:54 |
| sdeziel | to close the loop: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1864240 | 20:03 |
| mup | Bug #1864240: [wishlist] allow setting per-snap environment variables <snapd (Ubuntu):New> <https://launchpad.net/bugs/1864240> | 20:03 |
| sdeziel | thanks again ijohnson, have a nice weekend! | 20:04 |
| NickZ | pedronis: what's up with this? Are we getting this in the near future? https://github.com/snapcore/snapd/pull/7490 | 20:42 |
| mup | PR #7490: interfaces/app-launch: support confined snaps launching other snaps <Needs Samuele review> <Created by AlanGriffiths> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7490> | 20:42 |
| mup | PR snapcraft#2940 closed: build providers: remove use of cloud-init <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2940> | 20:54 |
| NickZ | I'm having issues with my snaps; It seems that it's not actually registering my apps with their associated file types, even though I have specified the Mime types in the desktop file. Has anyone else gotten this working? | 21:14 |
| zyga | jdstrand: store rejects new snap-confine mode | 21:29 |
| zyga | Just FYI | 21:29 |
| jdstrand | ah, yes, it would | 21:29 |
| * jdstrand adjusts tools | 21:29 | |
| jdstrand | zyga: where are you seeing this? core? core18? core20? snapd? all of the above? | 21:30 |
| zyga | I got a mail https://launchpad.net/~snappy-dev/+snap/snapd-master/+build/843779 | 21:31 |
| zyga | But probably snapd and core need rule updates | 21:31 |
| ijohnson | jdstrand: I assume that this will be for just snapd and core snaps, core18 and core20 don't ship snap-confine | 21:31 |
| zyga | Core18 and core20 are devoid of snapd | 21:31 |
| jdstrand | ijohnson: ah, yes. thanks | 21:32 |
| zyga | Thank you Jamie. I didnβt think about this beforehand | 21:32 |
| * cachio afk | 21:41 | |
| kinghat | snaps take a while to start up but subsequent launches of the same app are "snappy". does that mean they are held in memory or how does that work? | 21:52 |
| roadmr | kinghat: which snap? | 21:54 |
| zyga | kinghat: snap install snapd-hacker-toolbelt | 21:59 |
| zyga | kinghat: time snapd-hacker-toolbelt.busybox true | 21:59 |
| zyga | kinghat: time snapd-hacker-toolbelt.busybox true | 21:59 |
| zyga | kinghat: I can answer your questions later if you stay on IRC (or hop back tomorrow) | 21:59 |
| zyga | as it's 11PM here | 22:00 |
| kinghat | roadmr: most all of them. though i just started htop and it was "snappy". postman wasnt. | 22:00 |
| roadmr | π | 22:00 |
| roadmr | kinghat: well htop is a CLI application while postman is graphical (IIRC) and there were some issues with e.g. font caches needing regeneration for graphical snaps. So the slow first startup time is due to e.g. fonts being rebuilt, and subsequent runs are faster because fonts are built :) snaps are not cached in memory, at least not beyond possibly OS-managed disk caching | 22:01 |
| kinghat | chromium too. most of my snaps take time to load initially then are fine after until im in a new session. | 22:01 |
| roadmr | kinghat: note I say "were", as I thought it had been fixed | 22:01 |
| roadmr | https://forum.snapcraft.io/t/improving-first-run-performance-of-desktop-app-snaps/2944 | 22:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!