[00:31] <mup> PR snapd#7151 closed: tests: remove local revision of core <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7151>
[02:21] <mup> PR snapcraft#2644 opened: Release changelog for 2.44 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2644>
[05:09] <mborzecki> morning
[06:48] <mborzecki> mvo: morning
[06:50] <mvo> hey mborzecki
[06:50] <mvo> mborzecki: lots of red PRs this morning it seems, anything in particular unhappy in the tests?
[06:54] <mborzecki> mvo: nope, nothing in particular
[06:55] <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:56] <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:58] <mborzecki> mvo: anyways, woke up with some ideas to try out on F31, will discuss those with zyga again probably :)
[07:44] <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:45] <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:46] <zyga> see you at 10
[07:46] <zyga> I'll get prepped
[07:59] <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
[08:00] <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:01] <mup> PR core#105 closed: hooks: empty the configure hook <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/105>
[08:13] <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:25] <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:46] <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:49] <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:54] <zyga> uff 29C in the morning
[08:57] <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:58] <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:59] <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
[09:00] <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:01] <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:02] <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:09] <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:10] <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:11] <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:13] <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:14] <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:15] <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:16] <mvo> jamesh: but no worries, I can figure it out :) thanks for the hint!
[09:17] <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:19] <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:20] <jamesh> that probably represents best practice with sd-dbus
[09:20] <mvo> jamesh: sweet! thanks a lot, this looks like what I need
[09:23] <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:25] <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:26] <pedronis> Chipaca: your snapd and you snap-seccomp are out of sync?
[09:26] <Chipaca> pedronis: yeah that was it
[09:28] <mvo> Chipaca: add a symlink from your build-tree to ../snap-seccomp/snap-seccomp
[09:29] <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:30] <Chipaca> mvo: psh, so lazy
[09:30] <mvo> Chipaca: heh :)
[09:39] <zyga> tr
[09:39] <zyga> re
[09:39] <zyga> sorry, interrupts
[09:40] <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:44] <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:49] <pedronis> Chipaca: it has no tests atm fwiw (I'm more of a write tests with the code sort of person)
[09:50] <Chipaca> yeah, this is unlandable as is
[09:51] <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:52] <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:55] <zyga> brb again
[09:56] <mvo> or maybe someone else can check 104 on core? its really simple :)
[10:00] <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:11] <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:12] <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:13] <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:28] <mup> PR snapd#7162 opened: usersession: move userd package to usersession/userd <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7162>
[10:34] <mup> PR snapd#7163 opened: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7163>
[10:36] <ppisati> ogra: hold on
[10:37] <mborzecki> zyga: mvo: so lxd attempts some weird things on F31 with unified hierarchy: https://paste.ubuntu.com/p/Z4Qc4qq87v/
[10:38] <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:39] <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:40] <ppisati> ogra: 'make $kdefconfig[0] $kdefconfig[1] $kdefconfig[2] ...'
[10:41] <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:42]  * Chipaca steals biscuits also, for better i18n coverage
[10:43] <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:44] <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:47] <Chipaca> mborzecki: https://www.redbubble.com/people/rodebubbel/works/31716594-i-use-arch?p=sticker
[10:47] <mborzecki> Chipaca: hahah
[10:49] <Chipaca> mborzecki: even better, https://www.stickermule.com/uk/products/unixstickers-pro-pack
[10:53] <mborzecki> Chipaca: aaand placed an order :)
[10:54] <Chipaca> mborzecki: <surprised zapdos>
[11:00] <mborzecki> mvo: zyga: https://forum.snapcraft.io/t/lxd-3-15-fails-with-unified-cgroup-hierarchy/12462 the lxd thing
[11:02] <mvo> mborzecki: thanks
[11:26] <Chipaca> how do you spell "ALL THE LUNCH"
[11:26]  * Chipaca all the lunches
[11:37]  * 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:50] <mborzecki> some unfortunate project name, can anyone try `go get github.com/ojii/gettext.go`?
[11:51] <mborzecki> the repo name causes a panic in fedora packaging tools :/
[11:54] <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:56] <mborzecki> zyga: yeah, perhaps we should just package it, dropping all i18n support feels to heavy
[11:58] <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:59] <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
[12:16] <zyga> and it found stuff I wasn't testing... 18.04 is full of fun
[12:16] <zyga> on it :)
[12:19] <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:22] <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:43] <ijohnson> hey Chipaca
[12:44] <ijohnson> (and everyone else)
[12:48] <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:49]  * Chipaca hands one of the cookies back
[12:50] <pedronis> remodeling work has changed quite a few details about DeviceManager/devicestate
[12:51] <cmatsuoka> mvo: won't be at the standup today, there's an interesting session at the same time slot
[12:52] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/7165
[12:52] <zyga> ijohnson: https://github.com/snapcore/snapd/pull/7165 :)
[12:53] <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:54] <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:55] <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:58]  * Chipaca grudgingly returns the rest of the cookies
[12:58]  * Chipaca now needs to find his own
[13:00] <ijohnson> Chipaca: costco near me sells a big box of 16 cookies for $4
[13:00]  * ijohnson hands Chipaca some cookies
[13:01]  * Chipaca discovered the meaning of win-win
[13:27] <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:36] <zyga> I'll grab some food and return to reviews
[13:50] <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:55] <zyga> fedora tests look good but core is full of nasties
[14:01] <mborzecki> zyga: mvo_: left a note under https://bugzilla.redhat.com/show_bug.cgi?id=1438079#c6
[14:01] <zyga> I saw that :)
[14:02] <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:03] <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:12] <zyga> travis is starving us now
[14:22] <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:37] <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:41]  * zyga can smell lovely curry from the kitchen and goes for a break
[15:01] <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:02] <mup> PR snapd#7166 opened: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>
[15:03] <Chipaca> fgiulianiint: ouch
[15:06] <zyga> fgiulianiint: hmmm, I think that image is DOA, where did you get it from?
[15:07] <ijohnson> is `make hack` still supposed to work/be used?
[15:08] <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:09] <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:10] <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:11] <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:12] <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:13] <zyga> mvo_: ^ who manages the images that are produced?
[15:16] <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:17] <zyga> +1
[15:17] <zyga> pedronis: thank you
[15:19] <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:20] <ijohnson> zyga: see 7167 ^
[15:21] <zyga> ijohnson: looking
[15:21] <ijohnson> thanks
[15:22] <zyga> +1
[15:23] <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:28] <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:29] <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:31] <zyga> ijohnson: no, just reinstall the package
[15:31] <zyga> ijohnson: it's a quick and easy fix
[15:32] <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:33] <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:34]  * zyga restarted some local tests and returns to the kitchen where it is cooler
[15:36] <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:37] <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:38] <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:39] <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:44] <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:46] <mup> PR snapd#7168 opened: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7168>
[15:49]  * ijohnson goes to go look at a used car
[15:56] <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>
[16:34] <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:39]  * zyga is running away from the office
[16:39] <zyga> it's the hottest part of the house now
[16:55] <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
[17:10] <ijohnson> is it expected / by design that snaps cannot run when snapd is unable to start?
[17:17] <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:18] <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:19] <zyga> or pokes snapd, I forgot
[17:19] <zyga> but it waits anywa
[17:19] <zyga> *anyway
[17:20] <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:21] <zyga> no
[17:22] <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:23] <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:24] <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:31] <mup> PR snapd#7169 opened: tests: remove core18 if installed by tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7169>
[17:32] <mup> PR snapd#7170 opened: tests: fix typo "current" <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7170>
[17:35] <ijohnson> zyga: okay that makes sense
[17:44] <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:51] <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>
[18:11] <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:20]  * cachio afk
[18:43] <zyga> found another bug, installing the "classic" snap clobbers the host
[18:43] <zyga> fun fun fun
[18:51] <zyga> uUUUUh
[18:51] <zyga> omg
[18:51] <zyga> man
[18:51] <zyga> this is bad
[18:53] <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:54] <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)
[19:21] <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:44] <mup> PR snapd#7172 opened: tests: work around classic snap affecting the host <Created by zyga> <https://github.com/snapcore/snapd/pull/7172>
[19:45] <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:50] <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:51] <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:52] <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:53] <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:54] <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:55] <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:56] <jdstrand> ie, if you can do arbitrary devpts mounts, then well, I'm not surprised that can affect things
[19:57] <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:58] <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
[20:00] <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:01] <zyga> are they equivalent?
[20:04] <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:05] <jdstrand> jjohansen: zyga and I were curious when 'remount ...' is used, vs 'mount options=(remount, ...)'
[20:09] <jdstrand> zyga: also note that systemd-run is in play with the classic snap, so it might've done something too
[20:10] <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:11] <jjohansen> jdstrand: remount is the same as options=(remount,...)
[20:12] <jjohansen> its just a convenience keyword
[20:13] <ogra> zyga, classic should go away in favour of lxd
[20:13] <jdstrand> jjohansen: ack, thanks (cc zyga ^)
[20:14] <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:16] <ogra> zyga, also note that there has never been a stable release for a reason ;)
[20:19] <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:26] <zyga> JordiGH: can you run "snap changes" to let us know?
[20:26] <zyga> systemd logs could also be useful (of snapd.service)
[20:30] <JordiGH> $ snap changes
[20:30] <JordiGH> error: no changes found
[20:30] <JordiGH> $ sudo journalctl -u snap.service
[20:30] <JordiGH> -- No entries --
[20:31] <JordiGH> Oh, sorry, snapd.
[20:31] <JordiGH> Does this mean anything to you? http://paste.debian.net/1093102/
[20:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <JordiGH> That probably also requires creating accounts, and I'm already short-tempered, ttyl!
[20:48] <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:49] <jdstrand> zyga: you should stop that :)
[20:49] <zyga> I know but then we would not have this conversation about remount :)
[20:52] <jdstrand> heh
[20:54] <jdstrand> and sudo lxc launch ubuntu:16.04 xenial works on armhf too
[21:07] <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
[22:30] <mup> PR snapd#7170 closed: tests: fix typo "current" <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7170>
[22:44] <ogra> jdstrand, yeah, absolutely, i use it every day
[22:45] <ogra> jdstrand, and if you add your user into /var/lib/extrausers/group to the lxd line you can even get away without sudo ;)


[11:05] <matv1> hi, will agps service still remain functional on ut after june? is there any timeframe set for that to end?
[11:29] <jnxd> Hello. can anyone help me with backing up my contacts locally? I plan to flash my bq to android. Thanks
[11:41] <davmor2> matv1: it will remain working as it is as far as I am aware.
[11:41] <davmor2> jnxd: why not just use google to sync it
[11:43] <jnxd> davmor2: Just to keep a local repo. Also, I have had some troubles with proxy and I'm not sure how well the sncing is happening
[11:44] <matv1> davmor2 thats good to hear. so does that mean even beyond 2017?
[11:45] <davmor2> matv1: no idea, but the package won't be removed it is on the device.  Might not be available to the updates from ubports though
[11:45] <davmor2> matv1: also depends on the backend service still being there which is here
[11:46] <davmor2> matv1: and them never changing their api
[11:53] <mcphail> jnxd: https://gurucubano.gitbooks.io/bq-aquaris-e-4-5-ubuntu-phone/content/en/chapter9.html
[12:10] <jnxd> mcphail: thanks. seems to have done the trick
[12:10] <jnxd> anyone else here who did something similar?
[12:11] <jnxd> I mean changed to android recently? did anyone use anything other than BQ's android rom?
[12:20] <mcphail> jnxd: i couldn't find an alternative for my e4.5
[12:20] <jnxd> mcphail: lineage only seems to exist for vegetalte
[12:21] <mcphail> yep. nothing for krillin
[12:22] <mcphail> the bq rom is old, but fairly stock. Install twrp, get root and enjoy. Works fairly well
[12:22] <jnxd_> mcphail: did you say anything? I got disconnected
[12:22] <mcphail> the bq rom is old, but fairly stock. Install twrp, get root and enjoy. Works fairly well
[12:24] <mcphail> with some of the apps2sd apps, the bq phones are powerful enough
[12:25] <mcphail> perhaps not so great from a security point of view
[12:54] <jnxdjnxd> Okay I was trusting the magic-device-tool to help me switch to android, but unfortunately it doesn't work. any instruction manual? for e5