=== benfrancis8 is now known as benfrancis
mupPR 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>01:41
mupPR snapd#9388 closed: bootloader: lk cleanups <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9388>04:42
zygamvo: good morning05:01
mvozyga: good morning05:02
* zyga works while Lucy is sleeping05:02
* mvo works while still sleeping (or that's how it feels)05:06
zygahaha, that05:18
zygathat's how I often feel too ;)05:18
mvogood morning mborzecki06:12
mborzeckimvo: hey, i see you're working from 6am ;)06:12
mvomborzecki: yeah, teaching the kids to make breakfast for themself ;)06:13
mborzeckimvo: 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 :P06:14
mvomborzecki: yeah, usually I do this too but tried to shake up things today, I don't think it will last though :)06:15
mvomborzecki: I addressed your feedback on the snap debug show-recovery-key06:15
mborzeckimvo: ok, let me take a look06:15
mvomborzecki: but I'm not sure if it's woth a re-review yet before samuele had a look06:15
mvomborzecki: otoh, hopefully except for naming this should be fine(?)06:16
mborzeckididn't i +1 it already?06:16
* mvo looks again06:16
mvomborzecki: I don't see anything on the pr06:16
mvomborzecki: anything I can help you with?06:16
mborzeckimvo: hm so based on yday discussion, i'm putting that rpi recovery on hold, i've left notes in the doc06:17
mupPR snapd#9371 closed: o/snapstate: improve snapshot iteration <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9371>06:17
mborzeckimvo: now given that, anything else in the uc20 queue i should try to pick up now?06:17
mvomborzecki: 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 recovery06:20
mvomborzecki: or maybe poking at the snap run --experimental-gdbserver to see if we can make it no longer experimental06:21
mborzeckimvo: ok, let me look around a bit06:23
zygahttps://github.com/snapcore/snapd/pull/9384 is green as master currently allows06:26
mupPR #9384: overlord: export and use snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/9384>06:26
zygamborzecki: do you think we could have a call about ^^ to do a sanity check review?06:28
zygamborzecki: code sharing / overview thing06:29
zygamvo: I need to look after lucy still but I will start enabling r-a-a now06:30
mvozyga: ta06:30
mborzeckizyga: yup06:31
zygamborzecki: what time would work for you?06:33
mborzeckizyga: 9 sounds ok?06:33
zygagreat, thank you06:35
zyga-mbpmborzecki standup?07:02
mborzeckizyga-mbp: ok, joining07:02
zygaok, lucy is with grandparents07:45
pstolowskimvo: hey, thanks for pushing tweaks to snapshots PR; i tweaked one of the comments in #938907:57
mupPR #9389: o/snapshotstate: tweak comment regarding snapshot filename <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9389>07:57
mupPR snapd#9389 opened: o/snapshotstate: tweak comment regarding snapshot filename <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9389>07:57
mvopstolowski: nice! I added skip-spread07:58
mupPR 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:42
mborzeckimvo: trivial fix ^^08:44
mvomborzecki: \o/ in a meeting but will see what I can do08:44
mborzeckimvo: no rush08:44
zygamborzecki: I had a look but I'm so out of the uc20 loop I cannot review that08:50
mborzeckizyga: no worries08:51
mvomborzecki: looks good! would it make sense to have a spread test on core20 for that? just a smoke test basicly?09:00
pstolowskihmm, 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:02
pstolowskido we depend on libc?09:03
zygawe might be depending on libc as we built on 20.1009:05
zygaand then we put this into an environment with older libraries09:06
zygaI've never done this but we can probably pick a fixed symbol version somehow09:09
zygapstolowski: if this is a blocker I can look and try to help09:12
zygaI'm enabling r-a-a and changing tests to cope09:13
pstolowskizyga: r-a-a?09:18
zygarefresh app awarenes09:18
mborzeckihmm tumbleweed still fails09:18
zygamborzecki: yeah, pretty annoying - I plan to look at that later today09:18
pstolowskizyga: i think we don't require 20.10 for merging? in that sense it's not a blocker, but we need fix it09:18
zygato at least see what crashes09:18
zygapstolowski: correct09:19
pstolowskizyga: i'm not sure where to start with this, if you can help or advise that would be appreciated09:19
zygapstolowski: but may require changes to the build system09:19
mborzeckizyga: we should probably file a bug report (not that anyone will look at it, but still)09:19
zygapstolowski: we should build snapd snap once and repackage from a 16.04 build09:19
zygapstolowski: or learn the linker scripts09:19
zygabut with go it could be tricky09:19
zygawife is back,one sec09:22
zygamborzecki: do you think we can run into new issues with abi and exported host tools?09:41
mborzeckizyga: snapd snap is built on xenial (so old glibc), and if not reexecing, then relevant host tools are built statically09:44
zygamborzecki: right, I'm thinking about fedora09:44
zygafedora has explicitly disabled re-exec09:45
zyganow fedora's snap-exec will be used09:45
zygait's linked statically09:45
zygabut snap-confine is only partially static09:45
zygawe cannot avoid udev09:45
zygaunless we re-architect a small part of s-c to collect udev meta-data using ABI-independent methods09:46
zygamborzecki: to support cgroup2 we could re-think how we look at udev data09:47
zygaif snapd looks at udev, it's much much easier to have entirely static snap-confine09:48
mupPR 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
zygaor perhaps there must be a new tool, snap-udev09:48
zygawhich always runs on the host09:48
zygaand exposes that meta-data in a way that we can read from a fixed snap-confie09:48
zygalooking at r-a-a not that many tests are affected09:51
zygabut a few require more work09:51
pstolowskipedronis: i pushed first validation-set PR09:56
pedronispstolowski: thx10:01
pedronispstolowski: I might not get to it today though (lots of meetings)10:02
pstolowskipedronis: np. just a high-level look (at the 2 new structs would be good for starters)10:03
pstolowski020-09-22T08:29:11.1929785Z 2020-09-22 08:29:11 Failed tasks: 110:45
pstolowski2020-09-22T08:29:11.1979453Z     - google:ubuntu-16.04-64:tests/main/lxd:snapd_cgroup_both10:45
pstolowskii think we need to disable more of that10:45
mupPR 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>10:48
mupPR 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:08
zygapstolowski: reviewed11:11
mupPR snapd#9393 opened:  spread: drop vendor from the packed project archive <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9393>11:23
mborzeckiok, back to zyga's branch11:25
zygaoh thanks!11:25
zygajust made a tiny tweak to install11:25
zygahow does this look like:11:25
zygazyga@kaveri:~/go/src/github.com/snapcore/snapd/cmd/snap$ ./snap install11:25
zygaerror: which snap would you like to install?11:25
zygaoriginal message was something technical about zero snaps11:25
pedronisI don't think it explains what to do11:30
pedronisalso the tone doesn't match almost any of our other messages11:31
pedroniswe are not very consistent atm, and yes the curent message is not great either: https://paste.ubuntu.com/p/Qfh9FGkwHK/11:36
zygapedronis: fair enough, I just wanted to try making it different11:46
pedronismaybe degville has input on this11:46
degvillezyga / 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:50
pedronisyes, that is more like some other of our main commands11:52
zygadegville: I can use that message, I'll send a PR later12:06
zygapedronis: good call to check what remove says in this case!12:28
zygamvo: first tests passing with r-a-a enabled :)12:35
zyga(that were failing before)12:35
mvozyga nice12:36
=== zyga is now known as zyganice
mupPR 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>12:38
mupIssue core18#171 opened: core18 first login experience: out-of-the-blue reboot <Created by panlinux> <https://github.com/snapcore/core18/issues/171>13:09
ograabeato, is it known that "bluez.hcitool lescan" does not work ? (weem there is a capability missing in the apparmor profile)13:34
* ogra glares at his fingers13:34
ogragra@stream:~$ sudo bluez.hcitool lescan --duplicates13:34
ograSet scan parameters failed: Operation not permitted13:34
ograogra@stream:~$ dmesg | tail -113: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:34
abeatoogra, I don't think I've tried lescan before, so yes, probably we need more permissions in the interface13:35
ograyeah ... bluez has everything but home connected here ...13:36
ograhmm, interesting: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 properly13:37
ogranetwork-control is definitely connected ...13:37
=== zyganice is now known as zyga
zygaback from lunch14:19
=== alan_g is now known as alan_g_
pstolowskizyga: 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
mupBug #1895291: Error on content disconnect in autopkgtests <snapd:New> <https://launchpad.net/bugs/1895291>15:02
zygathis was reported relatively recently15:03
zygapstolowski: no idea15:04
* cachio lunch15:11
* zyga finally solved a blocker15:46
zygaI need coffee15:46
zygaor a nap15:46
* genii puts on a fresh pot of coffee15:47
* zyga runs all spread tests for 16.04 and goes for a coffee15:58
zygaand a small break15:58
zygathe hard part is done, now for some boring tweaks to a few tests15:58
zygaI didn't connect the usb3.0 front panel connector16:28
mupPR 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>16:34
mupPR 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:20
ijohnsonjdstrand: 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 well17:32
mupPR #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:32
=== ijohnson is now known as ijohnson|lunch
mupPR 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
mupPR 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:35
mupPR snapcraft#3293 opened: project loader: install dirmngr prior to configuring package repositories <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3293>17:38
jdstrandijohnson|lunch: whoa, I'm shocked at this development :)17:41
mupPR 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
mupPR snapcraft#3294 opened: project loader: install dirmngr prior to configuring package repositories <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3294>17:43
jdstrandijohnson|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 background17:44
=== ijohnson|lunch is now known as ijohnson
ijohnsonjdstrand: :-) 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 morning17:50
jdstrandijohnson: 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 that18:09
jdstrandemitorino: for simplicity, lets have a checklist that is to review the PR and to adjust the review-tools18:10
ijohnsonjdstrand: 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 overlap18:13
ijohnsonthis is for a brand store customer who is already using snapd-control to create users18:13
ijohnsonbut 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 posterity18:14
pedronisijohnson: 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:14
ijohnsonpedronis: yes I fixed that test18:15
ijohnsonpedronis: I broke out that into a separate pr18:15
jdstrandijohnson: 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 sense18:16
ijohnsonyes good point18:16
ijohnsoncachio: 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=115081493918:19
mupPR #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:19
emitorinoack jdstrand !18:22
cachioijohnson, well, fixed one issue but not that one18:29
cachiothis is the kernel issue which still not fixed18:29
jdstrandemitorino: 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 like18:29
emitorinosure jdstrand18:30
cachioijohnson, I was not able to boot tumbleweed last week18:31
ijohnsoncachio: ah so there were multiple tumbleweed issues you mean then?18:31
cachioijohnson, yes, now that's fixed, what I can do now is to skip the kernel which produces this problem18:32
cachioI'll do that today18:32
cachioafter I push the chagne for nested18:32
ijohnsonI se18:32
cachioijohnson, the weird part is that the nightly suite worked on tumbleweed https://travis-ci.org/github/snapcore/spread-cron/builds/729180440#L371518:37
cachiowith the change I did yesterday18:37
cachioijohnson, so, now I don't know18:37
ijohnsonyeah I dunno, we probably need somebody like zygmunt to take a look who knows more about tumbleweed18:38
cachioijohnson, yes, agree18:38
mupPR snapd#9397 opened: tests/nested: misc robustness fixes <Run nested> <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9397>18:50
cachiozyga, ijohnson when you have a time could you please take a look to #939819:21
mupPR #9398: tests: split the nested helper in 2 parts <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9398>19:21
ijohnsoncachio: sure probably not today though for me19:22
cachioijohnson, is a simple change but modifies everything in nested19:22
cachioijohnson, zyga when you review that please leave extra modifications for following pr, so I dont have to spend to much time doing manual merge19:23
cachioI'll collect all the improvements and apply them in another PR19:24
mupPR snapd#9398 opened: tests: split the nested helper in 2 parts <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9398>19:25
ijohnsontianon: 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 really19:37
* zyga checks on results and goes to bed20:13
zygar-a-a has some interesting container consequences20:13
zygaI've updated a few tests and running another pass20:14
zygaI'll deal with containers tomorrow20:14
* cachio afk a bit20:22
tianonijohnson: oh interesting, that sounds like a good idea20:34
ijohnsontianon: that may make it easier to maintain as well as accept contributions :-)20:39
tianonijohnson: for sure, launchpad's usability and friendliness is ... a barrier 😅20:40
tianonijohnson: maybe we should just ressurect https://github.com/docker-snap :)20:41
tianonwe 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 first20:42
tianonissues there are outdated enough it's probably worth archiving though20:44
ijohnsontianon: I see you created https://github.com/docker-snap/docker-snap :-)20:49
ijohnsonlgtm, thanks for that20:49
tianonyep :D20:49
tianongonna pull that PR in Soon(tm)20:49
tianonnow 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
ijohnsontianon: you could also adjust the contact link for the snap to point to this github repo too :-D20:53
tianonyep, that's the plan :)20:53
tianonmaybe we'll get github issues and I'll actually see them O:)20:54
Eighth_Doctormborzecki, zyga: have you folks seen https://github.com/containers/udica?20:58
Eighth_Doctorit 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 rules20:58
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:05
ijohnsontianon: 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.yml21:07
ijohnsontianon: 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 snap21:08
tianonijohnson: 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
ijohnsontianon: haha yes it is the shiny thing that is true21:09
tianonijohnson: so I think I'll keep jumping through GitHub hoops (I have an account I think I can use)21:09
tianonijohnson: snapcraft.io/build can do all the same arches, right?21:09
ijohnsontianon: yes21:09
ijohnsonit just can't do tracks21:09
tianonlooks like the main lost feature is in-progress build logs, but I'll just learn to be more patient :)21:30
mupPR snapd#9399 opened: snap help output refresh <Created by degville> <https://github.com/snapcore/snapd/pull/9399>23:01

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!