| mup | PR snapd#7151 closed: tests: remove local revision of core <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7151> | 00:31 |
|---|---|---|
| mup | PR snapcraft#2644 opened: Release changelog for 2.44 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2644> | 02:21 |
| mborzecki | morning | 05:09 |
| === morphis5 is now known as morphis | ||
| mborzecki | mvo: morning | 06:48 |
| mvo | hey mborzecki | 06:50 |
| mvo | mborzecki: lots of red PRs this morning it seems, anything in particular unhappy in the tests? | 06:50 |
| mborzecki | mvo: nope, nothing in particular | 06:54 |
| mborzecki | mvo: on the interesting-test-failures note, yesterday saw unit tests fail on travis (iirc it was daemon or cmd/snapd package) bc the port we tried to liste on was already busy | 06:55 |
| mborzecki | mvo: oh, and the lxd spread test failed in a weird way with cgroupv2 (AFAIK it's supported by lxd 3.x) | 06:56 |
| mvo | mborzecki: interessting | 06:56 |
| mborzecki | mvo: anyways, woke up with some ideas to try out on F31, will discuss those with zyga again probably :) | 06:58 |
| zyga | hello | 07:44 |
| zyga | sorry for being late, stopped at 3AM | 07:44 |
| mvo | hey zyga | 07:44 |
| zyga | hey :) | 07:44 |
| zyga | finishing coffee | 07:44 |
| zyga | I'm eager to run downstairs to see what the test results say | 07:44 |
| zyga | https://github.com/snapcore/snapd/pull/7155 <- lets merge it | 07:45 |
| mup | PR #7155: tests: remove locally installed core in more tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7155> | 07:45 |
| zyga | it's the same pattern as before, that got reviewed | 07:45 |
| === morphis4 is now known as morphis | ||
| zyga | see you at 10 | 07:46 |
| zyga | I'll get prepped | 07:46 |
| mvo | zyga: do you think you could have a look at https://github.com/snapcore/core/pull/105 ? | 07:59 |
| mup | PR core#105: hooks: empty the configure hook <Created by mvo5> <https://github.com/snapcore/core/pull/105> | 07:59 |
| mvo | zyga: should be pretty easy | 07:59 |
| zyga | `looking | 07:59 |
| zyga | mvo: done | 08:00 |
| zyga | mvo: let's merge https://github.com/snapcore/snapd/pull/7155 | 08:00 |
| mup | PR #7155: tests: remove locally installed core in more tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7155> | 08:00 |
| mup | PR core#105 closed: hooks: empty the configure hook <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/105> | 08:01 |
| mup | PR snapd#7155 closed: tests: remove locally installed core in more tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7155> | 08:13 |
| mup | PR core-build#48 opened: config: remove static files in etc,lib,usr,var <Created by mvo5> <https://github.com/snapcore/core-build/pull/48> | 08:25 |
| mup | PR snapd#7160 opened: tests: reformat and fix markdown in snapd-state.md <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7160> | 08:46 |
| zyga | a few trivial from my pool | 08:49 |
| mup | PR snapd#7161 opened: tests: show stderr only if it exists <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7161> | 08:49 |
| zyga | uff 29C in the morning | 08:54 |
| Chipaca | pro tip: if you're used to running in the evening, getting up early to run in the morning because the evening is not going to drop below 30 is not necessarily a good plan | 08:57 |
| Chipaca | mo'in all, sorry i'm late | 08:57 |
| zyga | mvo: is https://github.com/CanonicalLtd/netplan/compare/master...mvo5:dbus#diff-a084b794bc0759e7a6b77810e01874f2R2 something I can review in a PR? | 08:57 |
| zyga | Chipaca: hey :) | 08:57 |
| mvo | zyga: https://github.com/CanonicalLtd/netplan/pull/93 | 08:58 |
| zyga | Chipaca: heat wave all around | 08:58 |
| mup | PR CanonicalLtd/netplan#93: add dbus based "netplan apply" interface <Created by mvo5> <https://github.com/CanonicalLtd/netplan/pull/93> | 08:58 |
| mvo | zyga: that is the final one | 08:58 |
| zyga | it reached us now too | 08:58 |
| zyga | mvo: thank you | 08:58 |
| mvo | Chipaca: running> yeah heat is bad | 08:58 |
| Chipaca | oh, my takeaway is that the morning is bad :-0 | 08:59 |
| * zyga wonders what https://semaphoreci.com/cyphermox/netplan is | 08:59 | |
| mvo | Chipaca: yesterday and the day before the other side of my dsl line got a heat stroke at around 16:30. and it takes ages to talk to someone on the telco to reset it :/ | 08:59 |
| zyga | as in semaphore | 08:59 |
| pedronis | I marked a bunch of my PRs for 2.41 | 08:59 |
| mvo | pedronis: thank you | 08:59 |
| pedronis | I mean ideally we get all in, but those are the important ones (because they fix something) | 09:00 |
| Chipaca | mvo: if you can turn off your modem for ~5 minutes the port you're connected to gets returned to the pool, and you've got a chance of getting a new one | 09:00 |
| zyga | mvo: there is https://github.com/CanonicalLtd/netplan/blob/master/rpm/netplan.spec but I don't know if that is used for CI | 09:00 |
| zyga | mvo: also snap one https://github.com/CanonicalLtd/netplan/blob/master/snap/snapcraft.yaml | 09:00 |
| mvo | Chipaca: oh? that is interessting,I will try that today at ~16:30 when the line goes down again | 09:01 |
| pedronis | mvo: I think james #6954 is ready for merging, do you want to give a final look to the packaging/service bits? | 09:01 |
| mup | PR #6954: sessionagent: add a REST interface with socket activation <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6954> | 09:01 |
| mvo | zyga: yeah, they use something that I'm not familar with (semaphoreci) - no idea how to add deps there | 09:01 |
| mvo | pedronis: sure, let me check that | 09:02 |
| Chipaca | mvo: OTOH it might be your ISP telling you to work on your work/life balance | 09:02 |
| mvo | Chipaca: hahaha - do you have your hands in this ;) ? | 09:02 |
| * Chipaca whistles innocently | 09:02 | |
| jamesh | mvo: I think I got the packaging right in that PR (mostly just followed existing examples), but an extra set of eyes is welcome | 09:09 |
| pedronis | Chipaca: can you look at #7149 when you have a bit of time, especially output formatting in the command and api bits | 09:09 |
| mvo | jamesh: happy to do this | 09:09 |
| mup | PR #7149: [WIP] cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Remodel :train:> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7149> | 09:10 |
| Chipaca | pedronis: i have time now | 09:10 |
| * Chipaca looks | 09:10 | |
| mvo | jamesh: do you happen to know if there is a way to exit dbus services gracefully (and racefree) when they are not needed? context is https://github.com/CanonicalLtd/netplan/pull/93 which is a very simple service that I would like to stop if idle | 09:11 |
| mup | PR CanonicalLtd/netplan#93: add dbus based "netplan apply" interface <Created by mvo5> <https://github.com/CanonicalLtd/netplan/pull/93> | 09:11 |
| jamesh | mvo: is it problematic if two copies of the daemon run simultaneously for a while? | 09:13 |
| mvo | jamesh: I don't think so | 09:13 |
| jamesh | mvo: in that case, releasing the name and exiting after current requests complete should be enough | 09:14 |
| mvo | jamesh: nice! | 09:14 |
| jamesh | mvo: I'm not sure if there is a good example of that using the systemd dbus lib though | 09:14 |
| mvo | jamesh: no worries, I could change to gio | 09:15 |
| jamesh | mvo: I'm sure there is a good example, I just don't know where it is | 09:15 |
| mvo | jamesh: do you have one for gio? | 09:15 |
| jamesh | should have been "not sure where there is" | 09:15 |
| mvo | jamesh: but no worries, I can figure it out :) thanks for the hint! | 09:16 |
| jamesh | mvo: I know I dealt with this a while back for some of the unity-api projects, but can't really remember which | 09:17 |
| mvo | jamesh: no worries, thanks again | 09:17 |
| * mvo goes back to reviewing before diving into this | 09:17 | |
| jamesh | mvo: this code is using a bus_event_loop_with_idle() helper: https://github.com/systemd/systemd/blob/master/src/timedate/timedated.c | 09:19 |
| jamesh | that probably represents best practice with sd-dbus | 09:20 |
| mvo | jamesh: sweet! thanks a lot, this looks like what I need | 09:20 |
| Chipaca | hmm | 09:23 |
| Chipaca | cannot run daemon: state startup errors: [cannot obtain snap-seccomp version information: invalid format of version-info: "cca7be4711160d1b940e8a87b8d572c8cb18e3dd 2.4.1 8c73f36d3de1f71977107bf6687514f16787f639058b4db4c67b28dfdb2fd3af"] | 09:23 |
| Chipaca | what did i break now? :-| | 09:23 |
| jamesh | mvo: https://github.com/systemd/systemd/blob/master/src/shared/bus-util.c#L92 <- this is the utility function. It isn't part of libsystemd, but doesn't appear to be using private API | 09:25 |
| pedronis | Chipaca: your snapd and you snap-seccomp are out of sync? | 09:26 |
| Chipaca | pedronis: yeah that was it | 09:26 |
| mvo | Chipaca: add a symlink from your build-tree to ../snap-seccomp/snap-seccomp | 09:28 |
| mvo | jamesh: looking | 09:29 |
| Chipaca | ijohnson: you there? | 09:29 |
| mvo | Chipaca: probably not yet | 09:29 |
| mvo | Chipaca: 4:29 for him | 09:29 |
| Chipaca | the 'snap model' PR seems to panic | 09:29 |
| Chipaca | mvo: psh, so lazy | 09:30 |
| mvo | Chipaca: heh :) | 09:30 |
| zyga | tr | 09:39 |
| zyga | re | 09:39 |
| zyga | sorry, interrupts | 09:39 |
| zyga | (5200/5496) - no failures! | 09:40 |
| zyga | wow | 09:40 |
| zyga | with the mount-ns test as last (famous last words, it may still fail) | 09:40 |
| mup | PR core#106 opened: core: remove config test, this moved to the snapd code <Created by mvo5> <https://github.com/snapcore/core/pull/106> | 09:40 |
| mup | PR snapd#6954 closed: sessionagent: add a REST interface with socket activation <Needs Samuele review> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6954> | 09:44 |
| pedronis | Chipaca: it has no tests atm fwiw (I'm more of a write tests with the code sort of person) | 09:49 |
| Chipaca | yeah, this is unlandable as is | 09:50 |
| Chipaca | for several reasons | 09:51 |
| mvo | zyga: if you could review https://github.com/snapcore/core/pull/104 too that would be great. should be easy | 09:51 |
| mup | PR core#104: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104> | 09:51 |
| mup | PR core#106 closed: core: remove config test, this moved to the snapd code <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/106> | 09:52 |
| zyga | brb again | 09:55 |
| mvo | or maybe someone else can check 104 on core? its really simple :) | 09:56 |
| zyga | mvo: +1 | 10:00 |
| mvo | zyga: ta! | 10:00 |
| mup | PR core#104 closed: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/104> | 10:00 |
| mup | PR snapd#7161 closed: tests: show stderr only if it exists <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7161> | 10:11 |
| ogra | ppisati, if i use the kdefconfig option in snapcraft.yaml, is that using ./scripts/kconfig/merge_config.sh from the kernel tree in the back or does it simply call the different configs in order ? (i see some weird behaviour between a snap kernel and a manually built one that indicates the configs are different) | 10:12 |
| mup | PR snapd#7153 closed: gadget: select the right updater for given structure <Gadget update> <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7153> | 10:13 |
| mup | PR snapd#7162 opened: usersession: move userd package to usersession/userd <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7162> | 10:28 |
| mup | PR snapd#7163 opened: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7163> | 10:34 |
| ppisati | ogra: hold on | 10:36 |
| mborzecki | zyga: mvo: so lxd attempts some weird things on F31 with unified hierarchy: https://paste.ubuntu.com/p/Z4Qc4qq87v/ | 10:37 |
| zyga | mborzecki: what is fd=10 | 10:38 |
| mup | PR snapd#7164 opened: test: enable and run mount-ns test as last <Created by zyga> <https://github.com/snapcore/snapd/pull/7164> | 10:38 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/7163 | 10:39 |
| mup | PR #7163: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7163> | 10:39 |
| zyga | ideas welcome | 10:39 |
| zyga | Chipaca: ^ you as well, this is something similar to what you've built before | 10:39 |
| ppisati | ogra: 'make $kdefconfig[0] $kdefconfig[1] $kdefconfig[2] ...' | 10:40 |
| ppisati | ogra: but after the first one is expanded, it should call merge_config.sh by default - that's part of the kernel build rules | 10:41 |
| * Chipaca steals cookies | 10:41 | |
| * Chipaca steals biscuits also, for better i18n coverage | 10:42 | |
| ogra | ppisati, aha ... strange ... when using https://github.com/ogra1/pi4-kernel-hackery/blob/master/build-linux-5.1.sh#L10 vs https://github.com/ogra1/linux-raspberrypi-org/blob/master/snap/snapcraft.yaml#L30 i actually need to specify security=apparmor and apparmo=1 on the cmdline for the snap ... while the native build defaults to using apparmor ... | 10:43 |
| ogra | the patches and trees are absolutely identical | 10:44 |
| mup | PR snapd#7144 closed: tests: measure mount namespaces on Ubuntu 14.04 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7144> | 10:44 |
| Chipaca | mborzecki: https://www.redbubble.com/people/rodebubbel/works/31716594-i-use-arch?p=sticker | 10:47 |
| mborzecki | Chipaca: hahah | 10:47 |
| Chipaca | mborzecki: even better, https://www.stickermule.com/uk/products/unixstickers-pro-pack | 10:49 |
| mborzecki | Chipaca: aaand placed an order :) | 10:53 |
| Chipaca | mborzecki: <surprised zapdos> | 10:54 |
| mborzecki | mvo: zyga: https://forum.snapcraft.io/t/lxd-3-15-fails-with-unified-cgroup-hierarchy/12462 the lxd thing | 11:00 |
| mvo | mborzecki: thanks | 11:02 |
| Chipaca | how do you spell "ALL THE LUNCH" | 11:26 |
| * Chipaca all the lunches | 11:26 | |
| * zyga does reviews for a while | 11:37 | |
| mup | PR snapd#7160 closed: tests: reformat and fix markdown in snapd-state.md <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7160> | 11:37 |
| mborzecki | some unfortunate project name, can anyone try `go get github.com/ojii/gettext.go`? | 11:50 |
| mborzecki | the repo name causes a panic in fedora packaging tools :/ | 11:51 |
| zyga | mborzecki: perhaps we should fork it | 11:54 |
| zyga | I think the .go suffix on a project name is a bit unfortunate | 11:54 |
| mborzecki | zyga: hm there's a fork under snapcraft/go-gettext | 11:54 |
| zyga | is it up to date? | 11:54 |
| mborzecki | duh, snapcore/go-gettext | 11:54 |
| mborzecki | zyga: yeah, perhaps we should just package it, dropping all i18n support feels to heavy | 11:56 |
| zyga | yeah | 11:58 |
| zyga | I think so | 11:58 |
| zyga | we should craft a plan to support (maintain) our deps in Debian and Fedora | 11:58 |
| zyga | we really need that | 11:58 |
| zyga | mborzecki: can you look at https://github.com/snapcore/snapd/pull/7163 | 11:59 |
| mup | PR #7163: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7163> | 11:59 |
| zyga | it's super short and will hopefully open the path towards leakproof tests | 11:59 |
| zyga | and it found stuff I wasn't testing... 18.04 is full of fun | 12:16 |
| zyga | on it :) | 12:16 |
| mup | PR snapd#7163 closed: tests: measure testbed for leaking mountinfo entries <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7163> | 12:19 |
| mup | PR snapd#7164 closed: test: enable and run mount-ns test as last <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7164> | 12:22 |
| ijohnson | hey Chipaca | 12:43 |
| ijohnson | (and everyone else) | 12:44 |
| ijohnson | Chipaca: thanks for the detailed review, I have in fact been running that PR, but I have been cherrypicking the commits on top of the 2.39 branch because that was easier to test without dealing with the system-key format and I naively assumed that master would work the same as that branch | 12:48 |
| * Chipaca hands one of the cookies back | 12:49 | |
| pedronis | remodeling work has changed quite a few details about DeviceManager/devicestate | 12:50 |
| cmatsuoka | mvo: won't be at the standup today, there's an interesting session at the same time slot | 12:51 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/7165 | 12:52 |
| zyga | ijohnson: https://github.com/snapcore/snapd/pull/7165 :) | 12:52 |
| mup | PR #7165: tests: restore cpuset clone_children clobbered by lxd <Created by zyga> <https://github.com/snapcore/snapd/pull/7165> | 12:53 |
| zyga | ijohnson: I'm fighting tests that break the testbed by doing changes to the mount table | 12:53 |
| mup | PR snapd#7165 opened: tests: restore cpuset clone_children clobbered by lxd <Created by zyga> <https://github.com/snapcore/snapd/pull/7165> | 12:53 |
| pedronis | Chipaca: Model was taking the lock for you in 2.39, it doesn't anymore | 12:53 |
| pedronis | the older behavior had its reasons but was kind of weird (we don't take the lock for such small methods usually) | 12:53 |
| ijohnson | zyga: nice, I can take a look in a bit, still reading through all of my cmd/model comments that I will need to address | 12:54 |
| pedronis | ijohnson: 2.39 isv very different from master, if you look at changelog of 2.40 already lots have happened | 12:55 |
| zyga | ijohnson: no worries :) | 12:55 |
| * Chipaca grudgingly returns the rest of the cookies | 12:58 | |
| * Chipaca now needs to find his own | 12:58 | |
| ijohnson | Chipaca: costco near me sells a big box of 16 cookies for $4 | 13:00 |
| * ijohnson hands Chipaca some cookies | 13:00 | |
| * Chipaca discovered the meaning of win-win | 13:01 | |
| mup | PR snapd#7162 closed: usersession: move userd package to usersession/userd <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7162> | 13:27 |
| zyga | I'll grab some food and return to reviews | 13:36 |
| pedronis | a 2nd review for 7066 would be great (it's not urgent but it's old and there is one more on top) | 13:50 |
| zyga | fedora tests look good but core is full of nasties | 13:55 |
| mborzecki | zyga: mvo_: left a note under https://bugzilla.redhat.com/show_bug.cgi?id=1438079#c6 | 14:01 |
| zyga | I saw that :) | 14:01 |
| zyga | (mail notification ahead of IRC) | 14:02 |
| zyga | thank you | 14:02 |
| zyga | and good luck with flock | 14:02 |
| mborzecki | zyga: mvo_: also https://gist.github.com/bboozzoo/76b1535c93686a27bb7fdbaad0f560f7 got updated | 14:02 |
| zyga | mborzecki: note, freezer is available since 5.2 or 5.3 | 14:02 |
| zyga | as in the freeze feature | 14:02 |
| zyga | but as we discussed, we should switch to safe mount api | 14:03 |
| zyga | and not freeze | 14:03 |
| mborzecki | zyga: mhm, i doubt anyone on older kernels will switch to unified anyway :) | 14:03 |
| zyga | yeah, just saying | 14:03 |
| zyga | travis is starving us now | 14:12 |
| mup | PR snapcraft#2643 closed: project, cli: clean up snap asset messages <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2643> | 14:22 |
| zyga | pedronis: I did a pass over https://github.com/snapcore/snapd/pull/7066#pullrequestreview-266656756 | 14:37 |
| mup | PR #7066: overlord/assertstate: add Batch.Precheck to check for the full validity of the batch before Commit <Created by pedronis> <https://github.com/snapcore/snapd/pull/7066> | 14:37 |
| * zyga can smell lovely curry from the kitchen and goes for a break | 14:41 | |
| fgiulianiint | hi guys, i'm trying to install Ubuntu Core on an embedded computer with an i5 CPU. I copied the ubuntu-core-18-amd64.img.xz image on the mSata disk and the boot the PC. When I press enter to make the configuration I got an error: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 31.. etc.. and the PC promt again "press enter to c | 15:01 |
| fgiulianiint | onfigure"what can I do? | 15:01 |
| mup | PR snapd#7166 opened: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166> | 15:02 |
| Chipaca | fgiulianiint: ouch | 15:03 |
| zyga | fgiulianiint: hmmm, I think that image is DOA, where did you get it from? | 15:06 |
| ijohnson | is `make hack` still supposed to work/be used? | 15:07 |
| zyga | ijohnson: yes, though YMMV | 15:08 |
| zyga | ijohnson: send patches to improve it | 15:08 |
| zyga | I use it regularly | 15:08 |
| zyga | but I have a local patch that's hard to upstream, to make it work on suse | 15:08 |
| zyga | where the .real suffix is not used | 15:08 |
| ijohnson | ok, yeah I'll send a small patch to make it work when using the go snap, because it's using options that don't work with read-only go install | 15:08 |
| fgiulianiint | zyga: i downloaded from the official repo (at least I think) http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/?_ga=2.266211528.651887194.1563966098-1627888589.1561621113 | 15:09 |
| zyga | ijohnson: read-only go install? | 15:09 |
| ijohnson | the go snap? | 15:09 |
| zyga | ijohnson: I'm looking forward to the patch | 15:09 |
| ijohnson | go build runtime/cgo: open /snap/go/4100/pkg/linux_amd64/runtime/cgo.a: read-only file system | 15:09 |
| fgiulianiint | zyga: what DOA stands for? | 15:09 |
| zyga | fgiulianiint: ouch, not sure what to do about it, can you raise the topic on a forum and we can see what to do from there; p | 15:09 |
| zyga | dead on arrival | 15:10 |
| zyga | I think that image is busted | 15:10 |
| zyga | is the text localised in any way? | 15:10 |
| pedronis | zyga: thx, updated, I did something slightly different | 15:10 |
| zyga | +1 | 15:10 |
| fgiulianiint | zyga: yes, the only problem I can't copy the error becouse the monitor is cleared every time it prompts again "Press enter to configure" | 15:11 |
| zyga | fgiulianiint: no worries, that's okay | 15:11 |
| fgiulianiint | ok than | 15:12 |
| zyga | fgiulianiint: thank you for reporting that, I think we should check how that happened, there's supposed to be QA around that | 15:12 |
| zyga | mvo_: ^ who manages the images that are produced? | 15:13 |
| pedronis | zyga: thx, I'll land it if/when it gets green. from uc20 spike work I learned that we should probably make Batch more versatile and move it to asserts. something maybe to try during travel | 15:16 |
| zyga | +1 | 15:17 |
| zyga | pedronis: thank you | 15:17 |
| mup | PR snapd#7167 opened: cmd/Makefile.am: support building with the go snap <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7167> | 15:19 |
| ijohnson | zyga: see 7167 ^ | 15:20 |
| zyga | ijohnson: looking | 15:21 |
| ijohnson | thanks | 15:21 |
| zyga | +1 | 15:22 |
| ijohnson | btw is there a convenient "make unhack" to undo the changes from the make hack command? I just copied all of /usr/lib/snapd and was gonna re-copy it back when done | 15:23 |
| ijohnson | not sure if there's a more convenient way to do that | 15:23 |
| mup | PR snapd#7166 closed: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7166> | 15:28 |
| mup | PR snapcraft#2639 closed: deprecations: add deprecation notice for version-script (dn10) <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2639> | 15:29 |
| * cachio lunch | 15:29 | |
| zyga | ijohnson: no, just reinstall the package | 15:31 |
| zyga | ijohnson: it's a quick and easy fix | 15:31 |
| ijohnson | I see, I hadn't thought of that, but that sounds easy | 15:32 |
| zyga | :) | 15:32 |
| zyga | +1 on making that in make unhack | 15:32 |
| zyga | if you feel like wanting that | 15:32 |
| ijohnson | it would make it easy | 15:32 |
| ijohnson | I'm also gonna add some more info to HACKING.md since it is a little dusty I think | 15:32 |
| zyga | +1 | 15:33 |
| zyga | yeah, go for it :) | 15:33 |
| zyga | I wish we'll reach a point where the makefile won't have to hide in the cmd directory | 15:33 |
| zyga | one day | 15:33 |
| * zyga restarted some local tests and returns to the kitchen where it is cooler | 15:34 | |
| abeato | zyga, hey, I'm doing some testing by bind mounting snapd, but I found this error: | 15:36 |
| abeato | Jul 25 15:34:45 localhost snapd[5256]: cannot run daemon: state startup errors: [cannot obtain snap-seccomp version information: invalid format of version-info: "762c8972ff78d5e5d00275810e4dba7ae0ae0ea4 2.4.1 8c73f36d3de1f71977107bf6687514f16787f639058b4db4c67b28dfdb2fd3af"] | 15:36 |
| zyga | abeato: hmmmm | 15:36 |
| zyga | ah | 15:36 |
| ijohnson | hey abeato, I ran into the exact same thing | 15:36 |
| abeato | zyga, any idea on how can I workaround this? | 15:36 |
| zyga | yeah, new snapd needs matching snap-seccomp | 15:36 |
| ijohnson | I fixed it by doing make hack in cmd/ subdir | 15:37 |
| zyga | bind mount snap-seccomp in the _same_ directory as snapd | 15:37 |
| zyga | it uses /proc/self/exe | 15:37 |
| zyga | if you develop from source ijohnson's advice is good | 15:37 |
| zyga | make hack is your friend | 15:37 |
| abeato | ijohnson, nice, so then I need to bind mount snap-confine or other binaries? | 15:37 |
| zyga | abeato: make hack installs them | 15:37 |
| zyga | abeato: if you just care about snapd then just providing snap-seccomp is sufficient to get past that | 15:38 |
| ijohnson | abeato, go with what zyga says :-) | 15:38 |
| abeato | zyga, ok, will do that, I am compiling in a different machine to where I am testing, as it is an UC system | 15:38 |
| zyga | aha | 15:38 |
| zyga | yeah, a symlink would work too | 15:38 |
| zyga | whatever is convenient | 15:39 |
| zyga | just need a "recent enough" snap-seccomp | 15:39 |
| zyga | it's not that they have to be built together | 15:39 |
| abeato | ok, will try that thanks ijohnson and zyga | 15:39 |
| zyga | :) | 15:39 |
| mup | PR snapd#7165 closed: tests: restore cpuset clone_children clobbered by lxd <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7165> | 15:44 |
| mup | PR snapd#7168 opened: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7168> | 15:46 |
| * ijohnson goes to go look at a used car | 15:49 | |
| ogra | you have weird hobbies | 15:56 |
| mup | PR snapd#7166 opened: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166> | 15:56 |
| Chipaca | ok, I'm out | 16:34 |
| Chipaca | AC is no longer keeping up | 16:34 |
| Chipaca | send help | 16:34 |
| * Chipaca heads for the showers | 16:34 | |
| * zyga is running away from the office | 16:39 | |
| zyga | it's the hottest part of the house now | 16:39 |
| zyga | running another pass | 16:55 |
| zyga | I found another general class of leaky tests | 16:55 |
| zyga | core18 is often leaked on core systems | 16:55 |
| zyga | because cleanup is different there | 16:55 |
| zyga | this is now fixed, let's see what else is uncovered | 16:55 |
| zyga | meanwhile, I *really* need to run away from the office | 16:55 |
| zyga | ttyl | 16:55 |
| ijohnson | is it expected / by design that snaps cannot run when snapd is unable to start? | 17:10 |
| zyga | ijohnson: it's not exactly like that | 17:17 |
| zyga | ijohnson: in general snaps *can* almost always run without snapd | 17:17 |
| zyga | ijohnson: your case is different because you use a local build | 17:17 |
| zyga | ijohnson: in that case you always need snapd to compute matching security profiles | 17:17 |
| zyga | ijohnson: (matching to snap-run) | 17:17 |
| ijohnson | I should specify, this is for a classic snap | 17:17 |
| ijohnson | zyga: yes I know why my local snapd can't start | 17:18 |
| zyga | the logic doesn't check for snap confinement type | 17:18 |
| ijohnson | zyga: I'm just wondering if it's the case that something in snap-run/snap-confine needs to talk to snapd the daemon in order to continue | 17:18 |
| zyga | yes | 17:18 |
| zyga | but only in a specific case | 17:18 |
| zyga | snap run computes the "system key" | 17:18 |
| zyga | and if mismatches what's on disk (written by snapd) | 17:18 |
| zyga | it waits | 17:18 |
| zyga | or pokes snapd, I forgot | 17:19 |
| zyga | but it waits anywa | 17:19 |
| zyga | *anyway | 17:19 |
| ijohnson | I see, so if the system key matched, but snapd still couldn't start for some other reason the snap would be able to start? | 17:20 |
| zyga | no | 17:21 |
| ijohnson | okay, so it does look like it's at least expected that the snap wouldn't be able to run, but perhaps that's not an explicit design choice | 17:22 |
| ijohnson | I'm aware of the explicit design choice of snapd not blocking bootup and not getting in the way of other things running on the system | 17:22 |
| ijohnson | I wasn't sure if there was a similar thing for running snaps specifically | 17:22 |
| zyga | ijohnson: you are right with the design choice of not blocking startup | 17:23 |
| zyga | ijohnson: but except for kernel or snapd changes | 17:23 |
| zyga | ijohnson: and that's what's going on, effectively here | 17:24 |
| zyga | ijohnson: running snaps is in the same area, since the boot up problem is really "snapd needs to work for system to boot" | 17:24 |
| mup | PR snapd#7169 opened: tests: remove core18 if installed by tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7169> | 17:31 |
| mup | PR snapd#7170 opened: tests: fix typo "current" <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7170> | 17:32 |
| ijohnson | zyga: okay that makes sense | 17:35 |
| mup | PR snapd#7169 closed: tests: remove core18 if installed by tests <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7169> | 17:44 |
| mup | PR snapd#7066 closed: overlord/assertstate: add Batch.Precheck to check for the full validity of the batch before Commit <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7066> | 17:51 |
| mup | PR snapd#7171 opened: tests: improve how the system is restored when the upgrade-from-2.15 test fails <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7171> | 18:11 |
| * cachio afk | 18:20 | |
| zyga | found another bug, installing the "classic" snap clobbers the host | 18:43 |
| zyga | fun fun fun | 18:43 |
| zyga | uUUUUh | 18:51 |
| zyga | omg | 18:51 |
| zyga | man | 18:51 |
| zyga | this is bad | 18:51 |
| zyga | ah, wait | 18:53 |
| zyga | I misread | 18:53 |
| zyga | it's not bad | 18:53 |
| zyga | geez :| | 18:53 |
| sergiusens | zyga: chill! | 18:53 |
| sergiusens | hard to do with your heat wave, come down south to our cold weather :-) | 18:54 |
| zyga | sergiusens: polandball colors are somewhat appropriate now | 18:54 |
| zyga | (being upside down) | 18:54 |
| mup | Issue classic-snap#32 opened: Using classic clobbers /dev/pts on ubuntu-core 16 systems <Created by zyga> <https://github.com/snapcore/classic-snap/issue/32> | 19:21 |
| mup | PR snapd#7172 opened: tests: work around classic snap affecting the host <Created by zyga> <https://github.com/snapcore/snapd/pull/7172> | 19:44 |
| zyga | ogra: do you know who maintains the classic snap? | 19:45 |
| zyga | jdstrand: ^ interesting PR | 19:45 |
| zyga | jdstrand: tl;dr; security implication is that mounts that don't propagate to the other namespaces can still remount a mount point in the other namespaces if they have the permission (or attack vector) to do so | 19:45 |
| * zyga takes a break | 19:45 | |
| jdstrand | zyga: note devpts is special. I haven't read the code but it would surprise me if it honored propagation events. you just mount what you want at the place iirc and the kernel gives you that | 19:50 |
| jdstrand | zyga: and the classic snap is performing mount -o mode=666,ptmxmode=666 -t devpts devpts /dev/pts | 19:51 |
| zyga | jdstrand: that's odd, I tried "mounting over" but it would return EBUSY unless I passed -o remount | 19:51 |
| zyga | jdstrand: did you strace the classic snap or inferred this from the source code | 19:52 |
| zyga | jdstrand: as it does use -o remount in some if-then-else tree | 19:52 |
| zyga | but anyway, it's interesting and was non-obvious to me what is the cause of this | 19:52 |
| zyga | jdstrand: the mountinfo-tool work and the recent testbed-tool work is really paying off | 19:52 |
| jdstrand | classic is doing a weird: mount -o mode=666,ptmxmode=666 -t devpts devpts /dev/pts ; $SCRIPT && umount /dev/pts | 19:52 |
| zyga | note && is a bug most likely | 19:52 |
| zyga | it's horrible and should be rewritten away from shell IMO | 19:53 |
| jdstrand | zyga: as mentioned, I didn't look at anything. I just know that devpts is special in many ways and it wouldn't surprise me if this was one of them | 19:53 |
| zyga | jdstrand: ack, I'll read the kernel source to see what it does | 19:53 |
| zyga | I just wanted to share it because I was definitely not expecting this and I learned something today :) | 19:54 |
| zyga | jdstrand: in case you are interested where this is coming from: https://github.com/snapcore/snapd/pull/7168/files | 19:54 |
| mup | PR #7168: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7168> | 19:54 |
| jdstrand | zyga: it is interesting, but I don't consider it a security issue within snapd case the classic-support interface isn't meant to provide a security barrier and strict snaps can't do the mounting (and classic snaps are limited by DAC (which is only useful for non-root commands of course)) | 19:55 |
| jdstrand | ie, if you can do arbitrary devpts mounts, then well, I'm not surprised that can affect things | 19:56 |
| zyga | jdstrand: I wonder if our apparmor policy that allows a particular mount also allows you to remount, in other words, if you don't say options=(remount), do you have that? | 19:57 |
| zyga | jdstrand: or in other words, should way always say options=() to avoid having the effect of options=(*) | 19:57 |
| jdstrand | zyga: remount is a different rule | 19:58 |
| jdstrand | mount, umount, remount | 19:58 |
| zyga | really? I didn't know that | 19:58 |
| zyga | I recall we have some remount code | 19:58 |
| * zyga looks | 19:58 | |
| zyga | https://github.com/snapcore/snapd/blob/7721bb9df44a136f31920515fc5d1a3c2e1e9850/cmd/snap-confine/snap-confine.apparmor.in#L296 | 20:00 |
| zyga | we say options=(remount, ...) here | 20:00 |
| zyga | or did you mean that? | 20:00 |
| zyga | based on what you said I was expecting "remount ..." as a top-level rule | 20:00 |
| jdstrand | I do see options=(remount ro bind) etc in there | 20:00 |
| jdstrand | there is a remount rule | 20:00 |
| zyga | are they equivalent? | 20:01 |
| jdstrand | zyga: it probably depends on how it was mediated. I can say that we use options=(...) which means that the mount options must exactly match. you can't omit or inject | 20:04 |
| jdstrand | jjohansen: zyga and I were curious when 'remount ...' is used, vs 'mount options=(remount, ...)' | 20:05 |
| jdstrand | zyga: also note that systemd-run is in play with the classic snap, so it might've done something too | 20:09 |
| jdstrand | zyga: the classic snap is not using 'newinstance' either... | 20:10 |
| jdstrand | anyway, I need to get back to what I was working on | 20:10 |
| jjohansen | jdstrand: remount is the same as options=(remount,...) | 20:11 |
| jjohansen | its just a convenience keyword | 20:12 |
| ogra | zyga, classic should go away in favour of lxd | 20:13 |
| jdstrand | jjohansen: ack, thanks (cc zyga ^) | 20:13 |
| ogra | it comes from a time where we needed a quick way to use debs on core for development, it has never been more than a hack | 20:14 |
| ogra | zyga, also note that there has never been a stable release for a reason ;) | 20:16 |
| JordiGH | snapd ate all of my AWS CPU credits. It was running for several minutes. I restarted the VM. What was that thing doing? It made the VM unresponsive. | 20:19 |
| JordiGH | I'm not even using snaps on this VM. :-\ | 20:19 |
| JordiGH | It looks like it was doing a lot of IO 'cause some kernel disk process was topping the charts. | 20:19 |
| zyga | JordiGH: can you run "snap changes" to let us know? | 20:26 |
| zyga | systemd logs could also be useful (of snapd.service) | 20:26 |
| JordiGH | $ snap changes | 20:30 |
| JordiGH | error: no changes found | 20:30 |
| JordiGH | $ sudo journalctl -u snap.service | 20:30 |
| JordiGH | -- No entries -- | 20:30 |
| JordiGH | Oh, sorry, snapd. | 20:31 |
| JordiGH | Does this mean anything to you? http://paste.debian.net/1093102/ | 20:31 |
| zyga | looking | 20:33 |
| zyga | is snapd still using CPU? | 20:33 |
| zyga | so far all it did seems nurmal | 20:33 |
| zyga | *normal | 20:33 |
| JordiGH | No, it's not doing anything now. | 20:33 |
| JordiGH | But what could it possibly have been doing? | 20:33 |
| JordiGH | Is there some scheduled task? | 20:34 |
| zyga | initially it seeds snaps | 20:34 |
| zyga | snaps are on disk but are not installed | 20:34 |
| JordiGH | Even on a system that, afaict, has no snaps? | 20:34 |
| zyga | I see you have two snaps | 20:34 |
| zyga | snap list? | 20:34 |
| JordiGH | Oh, I do? | 20:34 |
| zyga | I think so | 20:34 |
| JordiGH | Ugh, Amazon has started to use snaps. | 20:34 |
| JordiGH | amazon-ssm-agent | 20:34 |
| zyga | so it installed the two snaps, the core is quick and easy but the amazon-ssm-agent might required some CPU startup time to configure the sandbox | 20:34 |
| JordiGH | That, eh? | 20:34 |
| zyga | yeah | 20:34 |
| zyga | *might have required | 20:35 |
| zyga | when you said it ate all your credits, what was the actual amount | 20:35 |
| roadmr | I believe those are baked into the images | 20:35 |
| zyga | did it run for minutes, hours? | 20:35 |
| JordiGH | I'm really worried that Ubuntu is really trying to get rid of or hide apt. | 20:35 |
| zyga | roadmr: yes | 20:35 |
| JordiGH | zyga: It ran for about 30 minutes before I noticed and terminated the instance. | 20:35 |
| zyga | JordiGH: we are doing neither, I can assure you; snaps do make a lot of sense for many payloads though | 20:35 |
| zyga | JordiGH: ouch! that's certainly bad | 20:36 |
| roadmr | was it snapd itself, or the agent snap? if the latter, this is probably best raised with amazon themselves, right? | 20:36 |
| zyga | JordiGH: can you share the details please: what kind of instance, which image, etc | 20:36 |
| zyga | JordiGH: so that we can reproduce and fix this | 20:36 |
| JordiGH | roadmr: I don't know, I saw snapd in top(1) as well as a kernel IO process. I'm not sure if it was kswapd. | 20:36 |
| roadmr | JordiGH: right, that doesn't look like the agent itself | 20:36 |
| JordiGH | Not the agent itself? Something other than snapd? | 20:37 |
| JordiGH | snapd was doing something that was doing a lot of disk writing. | 20:37 |
| zyga | JordiGH: ideally we can reproduce this and determine the cause | 20:37 |
| JordiGH | zyga: t2.large | 20:37 |
| JordiGH | zyga: I was told that yeah, the goal was to make people stop using apt. | 20:38 |
| zyga | JordiGH: can you collect this in a bug report please, I'll make sure the cloud people investigate this | 20:38 |
| JordiGH | Was I mislead? Canonical employees told me this. | 20:38 |
| zyga | JordiGH: who told you this? | 20:38 |
| roadmr | it wasn't me :) | 20:38 |
| zyga | I'm a canonical employee and I think both snaps and classic packages have their uses | 20:38 |
| JordiGH | yeah, apt is for building snaps, right? | 20:39 |
| JordiGH | Users should only use snaps. | 20:39 |
| zyga | it depends | 20:39 |
| JordiGH | I don't remember who said this. | 20:39 |
| zyga | it's not as simple as that | 20:39 |
| zyga | for some use cases one is more appropriate than the other | 20:39 |
| zyga | for end user applications, despite the relative immaturity, snaps do make a lot of sense | 20:39 |
| JordiGH | I thought the point is that Canonical was going to be spending all of its energy on making snap packages and make apt packaging secondary. | 20:40 |
| JordiGH | Anyway, what am I going to report and to whom? | 20:40 |
| zyga | for certain types of services and in headless consumer electronic stuff snaps make a lot of sense | 20:40 |
| zyga | JordiGH: I think whoever told you that was sharing his personal view and not a company policy | 20:40 |
| JordiGH | I don't have a lot of data. I don't even remember exactly what I was seeing in top(1). | 20:40 |
| zyga | JordiGH: please collect the information and report it either on forum.snapcraft.io or on bugs.launchpad.net/snapd | 20:40 |
| zyga | in either case please share the link, I'll get some eyes on it | 20:41 |
| JordiGH | Link to what? | 20:41 |
| zyga | JordiGH: region, instance type, image used, that should be enough to see if it happens all the time | 20:41 |
| zyga | to the bug report or forum post you make | 20:41 |
| JordiGH | I'm going to make a bug report? | 20:42 |
| zyga | please, if you can | 20:42 |
| JordiGH | eu-west-1a, t2.large, xenial-based image, | 20:42 |
| JordiGH | Where should I make a bug report? | 20:42 |
| zyga | xenial-based? | 20:42 |
| zyga | was it an official image or something custom? | 20:42 |
| zyga | I'm only asking to know if we can reproduce it on the stock one | 20:43 |
| JordiGH | We grab the xenial image, add stuff to it, and deploy VMs based on that. | 20:43 |
| zyga | I see | 20:43 |
| zyga | JordiGH: please report the bug on https://bugs.launchpad.net/snapd | 20:43 |
| jdstrand | ogra (cc zyga): is lxd viable for the workflow you described (ie, building things in an armhf container). are there official lxd images for armhf and arm64? | 20:44 |
| zyga | jdstrand: I'm sure there are | 20:44 |
| zyga | jdstrand: I used lxd on both | 20:45 |
| jdstrand | hmm.. I recall wanting them at one point and not having them | 20:45 |
| jdstrand | but that was a while ago | 20:45 |
| JordiGH | zyga: Can't remember my password, my email reminder isn't showing up, I'm already cross and don't want to bother with this anymore. | 20:45 |
| zyga | I think at this time you just install lxd and launch a container from it | 20:45 |
| JordiGH | If it happens again I'll come back. | 20:46 |
| zyga | JordiGH: thank you | 20:46 |
| zyga | JordiGH: if you want to, a forum post on forum.snapcraft.io is also useful | 20:46 |
| zyga | just anything that we can share with you as a way to continue the conversation | 20:46 |
| JordiGH | That probably also requires creating accounts, and I'm already short-tempered, ttyl! | 20:47 |
| jdstrand | zyga (cc ogra): sudo lxc launch ubuntu:16.04 xenial is working on arm65 | 20:48 |
| jdstrand | arm64* | 20:48 |
| zyga | jdstrand: cool :) | 20:48 |
| jdstrand | so, nm | 20:48 |
| zyga | jdstrand: I switched off my arm machines to (ironically) save some power today so I cannot ssh into anything to check quickly | 20:48 |
| jdstrand | heh | 20:48 |
| zyga | and I'm too lazy to go down and see the office today | 20:48 |
| zyga | it's 22:48 and here I am, working | 20:48 |
| jdstrand | zyga: you should stop that :) | 20:49 |
| zyga | I know but then we would not have this conversation about remount :) | 20:49 |
| jdstrand | heh | 20:52 |
| jdstrand | and sudo lxc launch ubuntu:16.04 xenial works on armhf too | 20:54 |
| zyga | jdstrand: btw, if you could comment on https://github.com/snapcore/snapd/pull/7172 I would love to fix this and carry on | 21:07 |
| mup | PR #7172: tests: work around classic snap affecting the host <Created by zyga> <https://github.com/snapcore/snapd/pull/7172> | 21:07 |
| zyga | the context is that there's a new tool that shouts loudly if a test clobbers the machine | 21:07 |
| zyga | so we get to see things like that easily | 21:07 |
| mup | PR snapd#7170 closed: tests: fix typo "current" <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7170> | 22:30 |
| ogra | jdstrand, yeah, absolutely, i use it every day | 22:44 |
| ogra | jdstrand, and if you add your user into /var/lib/extrausers/group to the lxd line you can even get away without sudo ;) | 22:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!