[01:41] <mup> PR snapd#9380 closed: tests: update to support nested kvm without reboots on UC20 <Run nested> <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9380>
[04:42] <mup> PR snapd#9388 closed: bootloader: lk cleanups <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9388>
[05:01] <zyga> mvo: good morning
[05:02] <mvo> zyga: good morning
[05:02]  * zyga works while Lucy is sleeping
[05:06]  * mvo works while still sleeping (or that's how it feels)
[05:18] <zyga> haha, that
[05:18] <zyga> that's how I often feel too ;)
[06:09] <mborzecki> morning
[06:12] <mvo> good morning mborzecki
[06:12] <mborzecki> mvo: hey, i see you're working from 6am ;)
[06:13] <mvo> mborzecki: yeah, teaching the kids to make breakfast for themself ;)
[06:14] <mborzecki> mvo: nice, mine are too sleepy to wrap their heads around the morning routine, so it's on me to have them fed, packed and ready for school :P
[06:15] <mvo> mborzecki: yeah, usually I do this too but tried to shake up things today, I don't think it will last though :)
[06:15] <mvo> mborzecki: I addressed your feedback on the snap debug show-recovery-key
[06:15] <mborzecki> mvo: ok, let me take a look
[06:15] <mvo> mborzecki: but I'm not sure if it's woth a re-review yet before samuele had a look
[06:16] <mvo> mborzecki: otoh, hopefully except for naming this should be fine(?)
[06:16] <mborzecki> didn't i +1 it already?
[06:16]  * mvo looks again
[06:16] <mvo> mborzecki: I don't see anything on the pr
[06:16] <mvo> mborzecki: anything I can help you with?
[06:17] <mborzecki> mvo: hm so based on yday discussion, i'm putting that rpi recovery on hold, i've left notes in the doc
[06:17] <mup> PR snapd#9371 closed: o/snapstate: improve snapshot iteration <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9371>
[06:17] <mborzecki> mvo: now given that, anything else in the uc20 queue i should try to pick up now?
[06:20] <mvo> mborzecki: there is the robustness work for grub.cfg, i.e. if normal boot keeps failing even after a rollback to the known good state boot into recovery
[06:21] <mvo> mborzecki: or maybe poking at the snap run --experimental-gdbserver to see if we can make it no longer experimental
[06:23] <mborzecki> mvo: ok, let me look around a bit
[06:25] <mvo> ta
[06:26] <zyga> re
[06:26] <zyga> https://github.com/snapcore/snapd/pull/9384 is green as master currently allows
[06:26] <mup> PR #9384: overlord: export and use snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/9384>
[06:28] <zyga> mborzecki: do you think we could have a call about ^^ to do a sanity check review?
[06:29] <zyga> mborzecki: code sharing / overview thing
[06:30] <zyga> mvo: I need to look after lucy still but I will start enabling r-a-a now
[06:30] <mvo> zyga: ta
[06:31] <mborzecki> zyga: yup
[06:33] <zyga> mborzecki: what time would work for you?
[06:33] <mborzecki> zyga: 9 sounds ok?
[06:35] <zyga> yeah
[06:35] <zyga> great, thank you
[06:56] <pstolowski> morning
[07:02] <zyga-mbp> mborzecki standup?
[07:02] <mborzecki> zyga-mbp: ok, joining
[07:45] <zyga> ok, lucy is with grandparents
[07:57] <pstolowski> mvo: hey, thanks for pushing tweaks to snapshots PR; i tweaked one of the comments in #9389
[07:57] <mup> PR #9389: o/snapshotstate: tweak comment regarding snapshot filename <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9389>
[07:57] <mup> PR snapd#9389 opened: o/snapshotstate: tweak comment regarding snapshot filename <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9389>
[07:58] <mvo> pstolowski: nice! I added skip-spread
[08:42] <mup> PR snapd#9390 opened: boot: fix debug bootloader variables dump on UC20 systems <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9390>
[08:44] <mborzecki> mvo: trivial fix ^^
[08:44] <mvo> mborzecki: \o/ in a meeting but will see what I can do
[08:44] <mborzecki> mvo: no rush
[08:50] <zyga> mborzecki: I had a look but I'm so out of the uc20 loop I cannot review that
[08:51] <mborzecki> zyga: no worries
[09:00] <mvo> mborzecki: looks good! would it make sense to have a spread test on core20 for that? just a smoke test basicly?
[09:02] <pstolowski> hmm, something broke on 20.10 in preseeding test: /tmp/snapd-preseed/usr/lib/snapd/snapd: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /tmp/snapd-preseed/usr/lib/snapd/snapd)
[09:03] <pstolowski> do we depend on libc?
[09:05] <zyga> oh
[09:05] <zyga> yes
[09:05] <zyga> we might be depending on libc as we built on 20.10
[09:06] <zyga> and then we put this into an environment with older libraries
[09:09] <mborzecki> pff
[09:09] <zyga> I've never done this but we can probably pick a fixed symbol version somehow
[09:12] <zyga> pstolowski: if this is a blocker I can look and try to help
[09:13] <zyga> I'm enabling r-a-a and changing tests to cope
[09:18] <pstolowski> zyga: r-a-a?
[09:18] <zyga> refresh app awarenes
[09:18] <zyga> awareness
[09:18] <mborzecki> hmm tumbleweed still fails
[09:18] <zyga> mborzecki: yeah, pretty annoying - I plan to look at that later today
[09:18] <pstolowski> zyga: i think we don't require 20.10 for merging? in that sense it's not a blocker, but we need fix it
[09:18] <zyga> to at least see what crashes
[09:19] <zyga> pstolowski: correct
[09:19] <pstolowski> zyga: i'm not sure where to start with this, if you can help or advise that would be appreciated
[09:19] <zyga> pstolowski: but may require changes to the build system
[09:19] <mborzecki> zyga: we should probably file a bug report (not that anyone will look at it, but still)
[09:19] <zyga> pstolowski: we should build snapd snap once and repackage from a 16.04 build
[09:19] <zyga> pstolowski: or learn the linker scripts
[09:19] <zyga> but with go it could be tricky
[09:22] <zyga> wife is back,one sec
[09:41] <zyga> mborzecki: do you think we can run into new issues with abi and exported host tools?
[09:44] <mborzecki> zyga: snapd snap is built on xenial (so old glibc), and if not reexecing, then relevant host tools are built statically
[09:44] <zyga> mborzecki: right, I'm thinking about fedora
[09:45] <zyga> fedora has explicitly disabled re-exec
[09:45] <zyga> now fedora's snap-exec will be used
[09:45] <zyga> it's linked statically
[09:45] <zyga> but snap-confine is only partially static
[09:45] <zyga> rigth?
[09:45] <zyga> we cannot avoid udev
[09:46] <zyga> unless we re-architect a small part of s-c to collect udev meta-data using ABI-independent methods
[09:47] <zyga> mborzecki: to support cgroup2 we could re-think how we look at udev data
[09:48] <zyga> if snapd looks at udev, it's much much easier to have entirely static snap-confine
[09:48] <mup> PR snapd#9391 opened: [RFC] o/assertstate: introduce ValidationTrackingKey/ValidationSetTracking and basic methods <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9391>
[09:48] <zyga> or perhaps there must be a new tool, snap-udev
[09:48] <zyga> which always runs on the host
[09:48] <zyga> and exposes that meta-data in a way that we can read from a fixed snap-confie
[09:48] <zyga> *confine
[09:51] <zyga> looking at r-a-a not that many tests are affected
[09:51] <zyga> but a few require more work
[09:56] <pstolowski> pedronis: i pushed first validation-set PR
[10:01] <pedronis> pstolowski: thx
[10:02] <pedronis> pstolowski: I might not get to it today though (lots of meetings)
[10:03] <pstolowski> pedronis: np. just a high-level look (at the 2 new structs would be good for starters)
[10:45] <pstolowski> 020-09-22T08:29:11.1929785Z 2020-09-22 08:29:11 Failed tasks: 1
[10:45] <pstolowski> 2020-09-22T08:29:11.1979453Z     - google:ubuntu-16.04-64:tests/main/lxd:snapd_cgroup_both
[10:45] <pstolowski> i think we need to disable more of that
[10:48] <mup> PR snapd#9389 closed: o/snapshotstate: tweak comment regarding snapshot filename <Simple 😃> <Skip spread> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9389>
[11:08] <mup> PR snapd#9392 opened: tests: disable part of the lxd test completely on 16.04 <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9392>
[11:11] <zyga> pstolowski: reviewed
[11:12] <pstolowski> ty
[11:23] <mup> PR snapd#9393 opened:  spread: drop vendor from the packed project archive <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9393>
[11:25] <mborzecki> ok, back to zyga's branch
[11:25] <zyga> oh thanks!
[11:25] <zyga> btw
[11:25] <zyga> just made a tiny tweak to install
[11:25] <zyga> how does this look like:
[11:25] <zyga> zyga@kaveri:~/go/src/github.com/snapcore/snapd/cmd/snap$ ./snap install
[11:25] <zyga> error: which snap would you like to install?
[11:25] <zyga> original message was something technical about zero snaps
[11:30] <pedronis> I don't think it explains what to do
[11:31] <pedronis> also the tone doesn't match almost any of our other messages
[11:36] <pedronis> we are not very consistent atm, and yes the curent message is not great either: https://paste.ubuntu.com/p/Qfh9FGkwHK/
[11:46] <zyga> pedronis: fair enough, I just wanted to try making it different
[11:46] <pedronis> maybe degville has input on this
[11:50] <degville> zyga / pedronis: I totally agree it needs to be improved. Maybe something more like help output: error: you need to specify one or more snaps to install. See snap help install.
[11:52] <pedronis> yes, that is more like some other of our main commands
[12:06] <zyga> degville: I can use that message, I'll send a PR later
[12:28] <zyga> pedronis: good call to check what remove says in this case!
[12:35] <zyga> mvo: first tests passing with r-a-a enabled :)
[12:35] <zyga> (that were failing before)
[12:35] <mvo> zyganice
[12:36] <mvo> zyga nice
[12:36] <zyganice> ;D\
[12:38] <mup> PR snapd#9392 closed: tests: disable part of the lxd test completely on 16.04 <⚠ Critical> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9392>
[13:09] <mup> Issue core18#171 opened: core18 first login experience: out-of-the-blue reboot <Created by panlinux> <https://github.com/snapcore/core18/issues/171>
[13:34] <ogra> abeato, is it known that "bluez.hcitool lescan" does not work ? (weem there is a capability missing in the apparmor profile)
[13:34] <ogra> s/weem/seems/
[13:34]  * ogra glares at his fingers
[13:34] <ogra> gra@stream:~$ sudo bluez.hcitool lescan --duplicates
[13:34] <ogra> Set scan parameters failed: Operation not permitted
[13:34] <ogra> ...
[13:34] <ogra> ogra@stream:~$ dmesg | tail -1
[13:34] <ogra> [175894.306074] audit: type=1400 audit(1600781361.500:106😞 apparmor="DENIED" operation="capable" profile="snap.bluez.hcitool" pid=3828 comm="hcitool" capability=13  capname="net_raw"
[13:35] <abeato> ogra, I don't think I've tried lescan before, so yes, probably we need more permissions in the interface
[13:36] <ogra> yeah ... bluez has everything but home connected here ...
[13:37] <ogra> hmm, interesting:
[13:37] <ogra> Suggestions:
[13:37] <ogra> * adjust program to not require 'CAP_NET_RAW' (see 'man 7 capabilities')
[13:37] <ogra> * add one of 'firewall-control, network-control, network-observe' to 'plugs'
[13:37] <ogra> * do nothing if program otherwise works properly
[13:37] <ogra> network-control is definitely connected ...
[14:19] <zyga> back from lunch
[15:02] <pstolowski> zyga: https://bugs.launchpad.net/snapd/+bug/1895291 is another namespace thing that looks familiar, do you recall a relevant bug where this could be linked to (if applicable)?
[15:02] <mup> Bug #1895291: Error on content disconnect in autopkgtests <snapd:New> <https://launchpad.net/bugs/1895291>
[15:02] <zyga> mmm
[15:03] <zyga> looking
[15:03] <zyga> this was reported relatively recently
[15:03] <zyga> hmm
[15:03] <zyga> hmm
[15:04] <zyga> pstolowski: no idea
[15:11]  * cachio lunch
[15:46]  * zyga finally solved a blocker
[15:46] <zyga> I need coffee
[15:46] <zyga> or a nap
[15:47]  * genii puts on a fresh pot of coffee
[15:58]  * zyga runs all spread tests for 16.04 and goes for a coffee
[15:58] <zyga> and a small break
[15:58] <zyga> the hard part is done, now for some boring tweaks to a few tests
[16:28] <zyga> drat
[16:28] <zyga> I didn't connect the usb3.0 front panel connector
[16:34] <mup> PR snapd#9394 opened: update-pot: ignore .go files inside .git when running xgettext-go <Simple 😃> <Skip spread> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9394>
[17:20] <mup> PR snapd#9395 opened:  o/snapstate/check_snap_test.go: mock osutil.Find{U,G}id to avoid bug in test <Bug> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9395>
[17:32] <ijohnson> jdstrand: this is not high priority, but I opened https://github.com/snapcore/snapd/pull/9396 and marked it blocked until you or maybe Emilia (who is not in the channel currently I notice) can take a look at it and confirm my understanding about the review-tools component as well
[17:32] <mup> PR #9396: snapstate/check_snap: add snap_docker to shared system-usernames <Needs security review> <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9396>
[17:35] <mup> PR snapd#9394 closed: update-pot: ignore .go files inside .git when running xgettext-go <Simple 😃> <Skip spread> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9394>
[17:35] <mup> PR snapd#9396 opened: snapstate/check_snap: add snap_docker to shared system-usernames <Needs security review> <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9396>
[17:38] <mup> PR snapcraft#3293 opened: project loader: install dirmngr prior to configuring package repositories <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3293>
[17:41] <jdstrand> ijohnson|lunch: whoa, I'm shocked at this development :)
[17:43] <mup> PR snapcraft#3293 closed: project loader: install dirmngr prior to configuring package repositories <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3293>
[17:43] <mup> PR snapcraft#3294 opened: project loader: install dirmngr prior to configuring package repositories <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3294>
[17:44] <jdstrand> ijohnson|lunch: so, I have a number of questions. I've added it to my todo. not sure when I'll have time to respond to the extent I would like, but I can be thinking about it in the background
[17:50] <ijohnson> jdstrand: :-) happy to answer any questions you might have, it's atm very specific to the docker case, but came about as a result of conversations just this morning
[18:09] <jdstrand> ijohnson: ack, I commented at a high level. emitorino can you add a card to trello in the snappy lane to review this PR? it should be either amurray, you or me to do that
[18:10] <jdstrand> emitorino: for simplicity, lets have a checklist that is to review the PR and to adjust the review-tools
[18:13] <ijohnson> jdstrand: thanks for the comment, yes that sounds good but unfortunately the docker use case is a bit more complicated than the udev case since there are no devices at play, just the dockerd socket, and my comment in the PR was more about the snapd API side of things that results in calling (eventually) `sudo adduser <user> snap_docker` but you are right there may be some overlap
[18:13] <ijohnson> this is for a brand store customer who is already using snapd-control to create users
[18:14] <ijohnson> but yes anyways can be discussed more in depth when someone gets a chance to look at the pr more in depth, I will respond to the pr comment as well for posterity
[18:14] <pedronis> ijohnson: notice that there's a skipped test as well related to that code, because it would fail on a system that already the user, maybe it's one you fixed?
[18:15] <ijohnson> pedronis: yes I fixed that test
[18:15] <ijohnson> pedronis: I broke out that into a separate pr
[18:16] <jdstrand> ijohnson: I wasn't saying there were devices in play for docker, just that when you start adding users to groups/etc, that is something that device access would also be doing, so considering that in the future design makes sense
[18:16] <ijohnson> yes good point
[18:19] <ijohnson> cachio: this morning in SU you said that you fixed the tumbleweed image in gce, but I still see failures preparing opensuse tumbleweed, for example see this one from this afternoon: https://github.com/snapcore/snapd/pull/9395/checks?check_run_id=1150814939
[18:19] <mup> PR #9395:  o/snapstate/check_snap_test.go: mock osutil.Find{U,G}id to avoid bug in test <Bug> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9395>
[18:22] <emitorino> ack jdstrand !
[18:29] <cachio> ijohnson, well, fixed one issue but not that one
[18:29] <cachio> this is the kernel issue which still not fixed
[18:29] <jdstrand> emitorino: thanks. we could get started on the snap_docker override if desired to go ahead of the PR landing. we can discuss that outside of this channel if you like
[18:30] <emitorino> sure jdstrand
[18:31] <cachio> ijohnson, I was not able to boot tumbleweed last week
[18:31] <ijohnson> cachio: ah so there were multiple tumbleweed issues you mean then?
[18:32] <cachio> ijohnson, yes, now that's fixed, what I can do now is to skip the kernel which produces this problem
[18:32] <cachio> I'll do that today
[18:32] <cachio> after I push the chagne for nested
[18:32] <ijohnson> I se
[18:32] <ijohnson> e
[18:37] <cachio> ijohnson, the weird part is that the nightly suite worked on tumbleweed https://travis-ci.org/github/snapcore/spread-cron/builds/729180440#L3715
[18:37] <ijohnson> huh
[18:37] <cachio> with the change I did yesterday
[18:37] <cachio> ijohnson, so, now I don't know
[18:38] <ijohnson> yeah I dunno, we probably need somebody like zygmunt to take a look who knows more about tumbleweed
[18:38] <cachio> ijohnson, yes, agree
[18:50] <mup> PR snapd#9397 opened: tests/nested: misc robustness fixes <Run nested> <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9397>
[19:21] <cachio> zyga, ijohnson when you have a time could you please take a look to #9398
[19:21] <mup> PR #9398: tests: split the nested helper in 2 parts <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9398>
[19:22] <ijohnson> cachio: sure probably not today though for me
[19:22] <cachio> ijohnson, is a simple change but modifies everything in nested
[19:23] <cachio> ijohnson, zyga when you review that please leave extra modifications for following pr, so I dont have to spend to much time doing manual merge
[19:24] <cachio> I'll collect all the improvements and apply them in another PR
[19:25] <mup> PR snapd#9398 opened: tests: split the nested helper in 2 parts <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9398>
[19:37] <ijohnson> tianon: hey regarding the docker snap being maintained on LP, maybe you could create a new github repo for it, and setup snapcraft.io/build to build the snap for you instead of using LP? since you're not using tracks for the docker snap at all anymore, there's no advantage to use lp anymore really
[20:13]  * zyga checks on results and goes to bed
[20:13] <zyga> r-a-a has some interesting container consequences
[20:14] <zyga> I've updated a few tests and running another pass
[20:14] <zyga> I'll deal with containers tomorrow
[20:22]  * cachio afk a bit
[20:34] <tianon> ijohnson: oh interesting, that sounds like a good idea
[20:39] <ijohnson> tianon: that may make it easier to maintain as well as accept contributions :-)
[20:40] <tianon> ijohnson: for sure, launchpad's usability and friendliness is ... a barrier 😅
[20:41] <tianon> ijohnson: maybe we should just ressurect https://github.com/docker-snap :)
[20:42] <tianon> we still share history with https://github.com/docker-snap/docker, can probably just push there and have things kinda work, although not sure whether anything external is attached; should probably audit settings first
[20:44] <tianon> issues there are outdated enough it's probably worth archiving though
[20:49] <ijohnson> tianon: I see you created https://github.com/docker-snap/docker-snap :-)
[20:49] <ijohnson> lgtm, thanks for that
[20:49] <tianon> yep :D
[20:49] <tianon> gonna pull that PR in Soon(tm)
[20:50] <ijohnson> nice
[20:53] <tianon> now the conundrum is that I don't/can't trust snapcraft.io with access to my GitHub auth :P (probably gonna make a dummy account to do the linking)
[20:53] <ijohnson> tianon: you could also adjust the contact link for the snap to point to this github repo too :-D
[20:53] <tianon> yep, that's the plan :)
[20:54] <tianon> maybe we'll get github issues and I'll actually see them O:)
[20:58] <Eighth_Doctor> mborzecki, zyga: have you folks seen https://github.com/containers/udica?
[20:58] <Eighth_Doctor> it seems broadly similar to what we were talking about a couple of years ago for how snapd would do SELinux policies to implement snap security rules
[21:05] <tianon> (looks like this has been discussed before, but not from the specific angle of not allowing snapcraft.io admin access to *all* my GitHub orgs, most of which aren't actually mine, so I added a necropost /o\  https://forum.snapcraft.io/t/build-snapcraft-io-support-webhook-build-trigger/8640/16?u=tianon)
[21:07] <ijohnson> tianon: one thing you could try is to still have the snap build recipes on LP, but trigger the LP snap build recipe from something like travis or github actions like this: https://github.com/siggiskulason/edgex-launchpad-build-action/blob/master/action.yml
[21:08] <ijohnson> tianon: obviously you wouldn't use the edgexfoundry snap there, but you could adjust the launchpadlib python to use the docker snap instead as well as add all the other architectures that are needed for the docker snap
[21:09] <tianon> ijohnson: that makes sense, but snapcraft.io/build is the new shiny and I don't have to hunt for the right URL when I use it O:)
[21:09] <ijohnson> tianon: haha yes it is the shiny thing that is true
[21:09] <tianon> ijohnson: so I think I'll keep jumping through GitHub hoops (I have an account I think I can use)
[21:09] <ijohnson> 👍
[21:09] <tianon> ijohnson: snapcraft.io/build can do all the same arches, right?
[21:09] <ijohnson> tianon: yes
[21:09] <ijohnson> it just can't do tracks
[21:10] <tianon> perf
[21:30] <tianon> looks like the main lost feature is in-progress build logs, but I'll just learn to be more patient :)
[23:01] <mup> PR snapd#9399 opened: snap help output refresh <Created by degville> <https://github.com/snapcore/snapd/pull/9399>