[06:40] <mborzecki> morning
[06:45] <mup> PR snapd#8289 opened: xdgopenproxy: forward requests to the desktop portal <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8289>
[06:58] <mborzecki> hmm the code in master isn't formatted according to gofmt 1.10?
[07:26] <mborzecki> jamesh: thanks for opening the PR! thre's some unit tests failures in the travis job
[07:26] <jamesh> mborzecki: yep.  Just looking into that (borrowing some logic from gio)
[07:27] <mup> PR snapd#8290 opened: run-checks: tweak formatting checks <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8290>
[07:30] <jamesh> mborzecki: I was adjusting the testing to run against a real bus rather than trying to mock everything
[07:32] <mborzecki> jamesh: right, userd tests did that too iirc
[07:41] <mborzecki> mvo: hey, a trivial PR to start your day with: https://github.com/snapcore/snapd/pull/8290
[07:41] <mup> PR #8290: run-checks: tweak formatting checks <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8290>
[07:42] <mvo> mborzecki: sure!
[07:44] <mup> PR snapd#8288 closed: release: 2.44 <Simple 😃> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8288>
[07:55] <zyga> good morning
[07:56] <mvo> good morning zyga
[07:56] <zyga> how is everyone?
[07:56] <zyga> it looks like a record-hot day today
[07:57] <zyga> I gave up and bought a disk for debian :/
[07:57] <zyga> I could not find any spare drives at home, that were not filled with stuff
[07:59] <zyga> did you guys noticed the github app went live yesterday
[07:59] <zyga> I tried it and it's pretty slick
[07:59] <zyga> it feels almost better than using the browser on a desktop
[08:05] <mborzecki> zyga: instead of just one browser you can run n instances now :)
[08:06] <pstolowski> morning
[08:06] <zyga> hey :)
[08:06] <zyga> pstolowski: still waiting?
[08:06] <pstolowski> zyga: yep; not even dispatched
[08:06] <zyga> it will come
[08:07] <zyga> just thinking about some stuff I talked about with mborzecki earlier
[08:07] <zyga> mborzecki: RGB HDD FTW
[08:11] <zyga> mvo: is 2.44 out?
[08:11] <mvo> zyga: yes, since last night in beta
[08:11] <zyga> woot
[08:11] <zyga> is that expected to be the 2.44 final that goes out to ISOs?
[08:12] <mvo> zyga: there will be a 2.44.1 that will probably go on the iso
[08:12] <mvo> zyga: with search v2
[08:12] <zyga> aha
[08:12] <zyga> ok
[08:12] <zyga> should I target fixes to it or to 2.45
[08:12] <zyga> thinking about stuff like EROFS from yesterday
[08:12] <mvo> zyga: fixes for 2.44
[08:12] <mvo> zyga: please mark everything that is worth for 2.44
[08:12] <zyga> https://github.com/snapcore/snapd/pull/8285 is like one
[08:12] <mup> PR #8285: cmd/snap-update-ns: ignore EROFS from rmdir/unlink <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8285>
[08:12] <mvo> zyga: we don't really have time for a 2.45 before the release
[08:13] <zyga> sure
[08:13] <zyga> I was thinking if we are doing any .1 or not at all
[08:13] <mvo> zyga: yeah, most likley a .1
[08:13] <mvo> zyga: (like ~95%)
[08:13] <mvo> zyga: I added the 2.44 milestone to you pr and will cherry-pick
[08:13] <zyga> I'll make a milestone on LP and retarget thebug
[08:14] <mborzecki> zyga:  haha rgb hdd, how about a transparent rgb hdd with a led platter  on top of the magnetic ones? :)
[08:15] <zyga> mborzecki: as soon as we have that transparent aluminum ;)
[08:15] <zyga> mborzecki: but I would totally buy an RGB HDD
[08:15] <zyga> because, why not :)
[08:41] <mborzecki> zyga: heh, already auto-filed https://bugzilla.redhat.com/show_bug.cgi?id=1814552
[08:41] <zyga> yeah I got the mail ping a moment ago
[08:41] <zyga> ITSABUGFIXITNOOOW
[08:42] <zyga> mvo: will you make the release tarballs?
[08:49] <zyga> brb
[08:54] <mvo> zyga: sure
[09:01] <zyga> thank you :)
[09:20] <mvo> pedronis: I pushed an update to the nocloud, probably needs a lot of naming tweaks
[09:22] <pedronis> mvo: #8278 ?
[09:22] <mup> PR #8278: devicestate: disable cloud-init by default on uc20 <Simple 😃> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8278>
[09:22] <mvo> pedronis: yes
[09:22] <pedronis> mvo: ok, I will look at it, looking at the next secboot PR atm
[09:23] <mvo> pedronis: no rush, thanks!
[09:26] <mvo> pedronis: actually let me tweak it a bit more, I think it's silly at this point to split it into two
[09:28] <mborzecki> i can't decide whether go allowing to embed `*type` and `type` is good or bad thing
[09:37] <pstolowski> zyga: question to the env fix PR
[09:41] <zyga> pstolowski: ok
[09:42] <pstolowski> zyga: ah, it's splitN, so it's fine
[09:42] <zyga> heh, I just replied the same :)
[09:42] <zyga> I believe this is also tested
[09:43] <zyga> there's a test like K=V=...
[09:43] <zyga> anyway
[09:43] <zyga> I need to take half day off
[09:43] <zyga> until we figure out home schooling
[09:43] <zyga> Lucy is constantly with me
[09:43] <zyga> crying if she is with grandparents
[09:43] <zyga> and I just cannot focus
[09:44] <zyga> until enough discipline and getting over the fact working at home is working is understood by older kids
[09:44] <zyga> sorry, I'll file the time off later :/
[09:44] <zyga> we're walking up and down the stairs all morning
[09:51] <mup> PR snapd#8234 closed: devicestate: support for "cloud.cfg.d" cloud-init in uc20 with grade: dangerous <Needs Samuele review> <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8234>
[09:55] <pedronis> mvo: I'm a bit unsure why you think is silly to split it? I asked it to be split that way
[10:02] <pedronis> mvo: what I mean, please don't merge 8234 into 8278
[10:04] <mvo> pedronis: ok, I will do them separately, sorry
[10:05] <mvo> pedronis: then 8278 should be ok for a first look, probably lots of tweaks still needed but hopefully it captures what we discussed
[10:06] <pedronis> mvo: 8278 is not that small anyway, with more stuff it would maybe >500 lines
[10:06] <mvo> pedronis: yeah, makes sense
[10:24] <pedronis> mborzecki: how close do you think is #8159, apart your comment?
[10:24] <mup> PR #8159: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159>
[10:24] <mborzecki> pedronis: it's just some nitpicks
[10:25] <mborzecki> pedronis: i think a helper called from Run() before CreateMising() that explicity mutates LaidOutVolume based on options would be fine there
[10:25] <pedronis> mborzecki: I see, I sort of feel there already too many helpers but maybe is just me
[10:28] <mborzecki> pedronis: perhaps that should even be something in gadget, since gadget is looked at from other places too (eg. boot assets update)
[10:28] <mborzecki> pedronis: wdyt?
[10:28] <ijohnson> morning folks
[10:29] <mborzecki> ijohnson: hey!
[10:29] <ijohnson> hey mborzecki o/
[10:29] <pedronis> mborzecki: I honestly wonder if overreding what the gadget says is worth the trobule
[10:30] <pedronis> the specs says anyway that the normal partitions can be luks
[10:30] <pedronis> afaiu
[10:30] <mborzecki> pedronis: leave a type as it is then?
[10:30] <pedronis> yes
[10:31] <pedronis> mborzecki: see here: https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
[10:31] <mborzecki> pedronis: mhm, cryptsetup open probably does not even look at the partition type in gpt/mbr
[10:32] <pedronis> it's cute to have the "right" type but atm it just seem grief
[10:32] <mborzecki> haha fair enough
[10:32] <pedronis> notice that I didn't request that
[10:32] <pedronis> also as you said, not sure other gadget code will be happy
[10:32] <pedronis> about the changed type
[10:34] <ijohnson> any idea why snap prepare-image would fail to find the account-key here: https://pastebin.ubuntu.com/p/Qz3RvprPK6/, this is from #8286
[10:34] <mup> PR #8286: tests: cleanup various uc20 boot tests from previous PR <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8286>
[10:41] <ackk> zyga, hi, is https://paste.ubuntu.com/p/Yv9dkYThZr/ the same issue with mounts you're fixing?
[10:41] <mvo> zyga: hrm, hrm, the debian package fails with https://paste.ubuntu.com/p/P674rpMTMB/ which in my pbuilder, which is super strange given that this is building travis, I wonder if we do something silly there like not excluding the vendor stuff or sillyness like this
[10:44] <mborzecki> pedronis: ok, let's discuss that with claudio after the standup maybe?
[10:47] <pedronis> mvo: I +1ed one 8278 but it needs a 2nd review given all the changes, also Opts name need to change. Lots of details are still unclear to me but shouldn't be a blocker for what is there currently
[10:47] <zyga> ackk: no, you cannot chown $SNAP
[10:47] <zyga> hmmm
[10:48] <ijohnson> pedronis: I'm reviewing 8278 right now
[10:48] <zyga> mvo: weird
[10:48] <zyga> is golang-evdev in the vendor tarball>
[10:48] <zyga> or are we de-vendoring?
[10:48] <zyga> I mean, are we really building the devendorized tarball in our spread runs?
[10:48] <pedronis> we shouldn't be building things that need on debian
[10:48] <pedronis> need it
[10:48] <pedronis> anyway
[10:48] <zyga> pedronis: good point
[10:48] <zyga> Lucy is asleep now but I think today is rather hectic :
[10:48] <pedronis> maybe we are because
[10:48] <zyga> :/
[10:49] <pedronis> mborzecki: I'm not sure there is more to discuss, that PR is open since forever
[10:49] <mvo> pedronis: yeah, I'm unhappy that we did not caught this, the sbuild nightly test is failing since days and it was not noticed
[10:50] <mborzecki> pedronis: ok, let me add a note that we drop the type chane
[10:50] <ackk> zyga, that's not $SNAP, it's $SNAP_DATA
[10:50] <ijohnson> mvo did you see my comment about cloud-init spread test on 8278 ?
[10:50] <ackk> zyga, oh wait, I'm dumb
[10:50] <zyga> ackk: snap/maas/current/usr/lib/postgresql/10/bin seems like $SNAP
[10:50] <ackk> zyga, I saw the "current" there and thought it was SNAP_DATA, sorry :)
[10:50] <pedronis> ijohnson: I think we need core 20 specific cloud-init tests, I suppose that's mvo plan
[10:50] <zyga> :D
[10:51] <zyga> mvo: do you know what is missing in our spread setup?
[10:51] <pedronis> ijohnson: given the behavior will be tied to grade etc
[10:51] <ijohnson> ok, sure I would still like to see a TODO:UC20: somewhere about that so that we remember to write that :-)
[10:51] <mvo> zyga: not sure yet, just checking one idea
[10:51] <pedronis> ijohnson: that's ok, my point is that the TODO should simply say re-enable this for UC20
[10:51] <pedronis> heh
[10:52] <pedronis> should not simply say
[10:52] <ijohnson> :-)
[10:52] <mvo> zyga: in any case, the nightly suite did notice the issue we just did not pay attention, I think we need alerting here
[10:52] <zyga> :/
[10:52] <mvo> ijohnson: yeah, sorry, need to reply, but I think we need special tests, uc20 behaves differently from the other oses we have
[10:52] <ijohnson> yes that's fine
[10:53]  * ijohnson just likes todos so we don't forget
[10:53] <pedronis> I like todos too
[10:53] <pedronis> I like to do todos sometimes too
[10:53] <pedronis> or even done todos too
[10:53] <pedronis> :)
[10:53] <ijohnson> haha nah I'm not much for that, I just like them to add up
[10:53] <ijohnson> :-)
[10:54] <ijohnson> there's a benjamin franklin quote something like "I love deadlines, I love the whooshing sound they make as they go by"
[10:54] <zyga> lol pedronis :D
[10:54] <zyga> we need to do do more todos
[11:52] <mup> PR snapd#8291 opened: packaging,tests: ensure debian-sid builds without vendor/ <Created by mvo5> <https://github.com/snapcore/snapd/pull/8291>
[11:53] <zyga> mvo: lol :)
[11:53] <zyga> sorry :)
[11:54] <zyga> mvo: approved
[11:55] <mvo> zyga: it's all very sad
[11:56]  * zyga elbow-hugs mvo 
[11:56] <zyga> not _all_ very sad :)
[11:56] <mup> PR snapd#8292 opened: travis.yml: run unit tests on master as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/8292>
[12:02] <zyga> mvo: small review for 8292
[12:03] <zyga> mvo: I also wonder if this bug is related https://bugs.launchpad.net/snapd/+bug/1867755
[12:03] <mup> Bug #1867755: snapd fails to build in focal, unit test clientSuite.TestClientFindFromPathErrIsWrapped fails <snapd:New> <https://launchpad.net/bugs/1867755>
[12:04] <mborzecki> kinda meh that dh_auto_build is so magical you need to remove parts of the source tree
[12:04] <zyga> mborzecki: when it works it is useful
[12:04] <zyga> no packaging is good
[12:11] <mup> PR snapd#8293 opened: packaging: add README.source for debian <Created by mvo5> <https://github.com/snapcore/snapd/pull/8293>
[12:14] <zyga> mborzecki: ha
[12:14] <zyga> mborzecki: check this out please
[12:14] <zyga> https://www.irccloud.com/pastebin/5hCE1Blq/
[12:14] <zyga> specifically line 4
[12:15] <mvo> zyga: 1867755 is fun, it seems to be a race
[12:15] <zyga> does it seem to you that dbus activation is somehow not working?
[12:15] <mvo> zyga: which is so strange - I saw it sometimes in a PPA build (rarely) and even once in travis I think
[12:16] <zyga> heh
[12:16] <zyga> mvo: use teasaiding they
[12:17] <cmatsuoka> mborzecki: for some reason I can't answer your review comment on #8159 but you're right, we're mutating external data that shouldn't be touched there
[12:17] <mup> PR #8159: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159>
[12:17] <mvo> zyga: can't parse that
[12:17] <zyga> mvo: use threads they said | scramble
[12:17] <mborzecki> cmatsuoka: left a note there, after discussing with pedronis it probably makes most sense to not update the type at all and leave what's defined in the gadget
[12:17] <mvo> zyga: hahahahaa
[12:18] <cmatsuoka> mborzecki: ok, will do it that way
[12:19] <mborzecki> zyga: hmm session systemd has no love for the session tool?
[12:19] <zyga> mborzecki: it fails on 18.04
[12:19] <zyga> but not in others somehow
[12:19] <zyga> I collected some more data, let me go through it
[12:20] <pedronis> ijohnson: as discussed apart the test renames #8208 seems good to go, it needs 2nd review though
[12:20] <mup> PR #8208: boot_test: add many boot robustness tests for UC20 kernel MarkBootSuccessul and SetNextBoot <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8208>
[12:27]  * cmatsuoka hates when you notice something strange in your code, check the branch to see if it's right (it is) and then realize you're on the wrong host
[12:35] <pedronis> ijohnson: I reviewed #8286, thanks for it
[12:35] <mup> PR #8286: tests: cleanup various uc20 boot tests from previous PR <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8286>
[12:36] <mup> PR snapd#8285 closed: cmd/snap-update-ns: ignore EROFS from rmdir/unlink <Bug> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8285>
[12:36] <mborzecki> ah, damn, should have squash merged
[12:42] <pedronis> #8292 (small) needs a 2nd review
[12:42] <mup> PR #8292: travis.yml: run unit tests on master as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/8292>
[12:45] <zyga> making progress :)
[12:46] <zyga> brb, I'll make coffee and check up on kids
[12:57] <cmatsuoka> ijohnson: did you change anything related to grubenv yesterday? cachio reports boot errors in the ci tests
[12:58] <cmatsuoka> ijohnson:  qemu-system-x86_64[62371]: error: file `/EFI/ubuntu/grubenv' not found.
[13:18] <pedronis> last things merged 2 days ago, was the start of uboot support
[13:18] <pedronis> shouldn't have broken amd64
[13:19] <pedronis> don't know if something was done to the gadget or somewhere else
[13:19] <zyga> ha, ok I think I got it
[13:19] <zyga> mborzecki: it works :)
[13:20] <zyga> now the only thing I need is to inject one more exec
[13:20] <zyga> as the pid I get is not the pid of the app
[13:20] <zyga> but of the intermediate bash
[13:29] <pedronis> zyga: not urgent, but if you could look at my changes to #8242 it could be otherwise be landable
[13:29] <mup> PR #8242: many: improve environment handling, fixing duplicate entries <Bug> <Needs Samuele review> <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/8242>
[13:30] <zyga> ack
[13:30] <pedronis> Pawel reviewed it as well
[13:30] <zyga> in a few minutes
[13:30] <zyga> I had a look originally but I need to read it again now as it paged out of my memory
[13:31] <zyga> oh, right. 2.44 is branched so we can land 2.45 things again
[13:44] <ijohnson> cmatsuoka: that sounds like the same issue you and cachio had at the sprint no?
[13:45] <sil2100> zyga, mvo, xnox: as part of my SRU verification for ubuntu-image, I just built an amd64 uc20 image, but I can't get a working system - I just get the grub menu, and whatever I select I get some errors, is that expected?
[13:45] <sil2100> I just want to know if it's ubuntu-image broken or something else
[13:45] <zyga> sil2100: I don't know
[13:46] <cmatsuoka> cachio: could you check for "bootloader files not found" messages in the system journal?
[13:46] <cmatsuoka> cachio: of see if the bootloader is actually there
[13:48] <cmatsuoka> ijohnson: that's a possibility, I asked sergio to confirm if that's the case
[13:48] <cmatsuoka> cachio: s/of/or/
[13:49] <cachio> cmatsuoka, what I see now is that the system is restarting in a loop
[13:49] <ijohnson> sil2100: what are the menu items in the grub you see
[13:50] <cachio> the last thing I see is Mar 18 13:49:05 mar181302-158658 qemu-system-x86_64[61560]: [   16.102470] systemd[1]: Started Create Static Device Nodes in /dev.
[13:50] <cachio> then allways restarts in install mode
[13:50] <cmatsuoka> cachio: that didn't happen with the bootloader error in the sprint, right?
[13:51] <cachio> cmatsuoka, I thinks it is not the same but not totally sure
[13:51] <cachio> cmatsuoka, sometimes I even see Mar 18 13:51:27 mar181302-158658 qemu-system-x86_64[61560]: Press enter to configure.
[13:51] <cachio> and then reboots again automatically
[13:52] <sil2100> ijohnson: 'Recover using /systems/*', 'Install using /systems/*' and 'System setup'
[13:53] <cachio> cmatsuoka, this is the last log v
[13:53] <cachio> https://paste.ubuntu.com/p/6bNqps9Np2/
[13:53] <cmatsuoka> cachio: that's very strange, what changed from the latest build that worked? is there a new kernel snap, or new ubuntu-image?
[13:55] <sil2100> There has not been a new ubuntu-image in stable since a while, 1.9 is the latest
[13:56] <cmatsuoka> sil2100: thanks for the information
[13:57] <cmatsuoka> cachio: so let's see what the differences are, something must be different
[13:58] <sil2100> cmatsuoka, cachio: when did you start noticing the problems? And are you using ubuntu-image from the snap or deb?
[13:59] <sil2100> That being said, I don't think we had any uc20 related changes to 1.9 even
[14:02] <cachio> sil2100, snap
[14:03] <cachio> cmatsuoka, I think the problem was already there
[14:03] <cachio> the system is restarting and restarting until at some point it does not restart
[14:03] <cachio> then it works
[14:04] <cmatsuoka> cachio: coming to SU?
[14:04] <sil2100> cachio: while we're at it, what's up with core18 the snap? I see it's not marked as ready for beta all the time, is something failing for the pi3?
[14:04] <cachio> it started failing now because I reduced the timeouts because I am tryting to speed up a bit the tests because it is taking like 40 minutes each test
[14:04] <sil2100> cwayne, plars: ^
[14:05] <cachio> sil2100, let me check
[14:06] <cachio> sil2100, this is the problem https://trello-attachments.s3.amazonaws.com/5da8bc830df86851446e9d4e/5e688b02c26ce805a8a979ef/8bb39aabc282ceb61f07f599cd7d72b6/core18_20200311_(1705)_pi3_arm32.log
[14:06] <cachio> the system fails to flash the image
[14:07] <sil2100> cachio: oh, so not really an issue with the snap itself - should we poke plars around it and see if he can help?
[14:08] <cachio> I think the issue is with the device in the lab
[14:08] <cachio> sil2100, not related to the image
[14:09] <cachio> I trigegred it again
[14:09] <cachio> lets see
[14:11] <ijohnson> sil2100: what error do you see when you try to use the `install using ...` menu item?
[14:14] <xnox> sil2100:  did you boot in UEFI mode, with secureboot, and snakeoil UEFI VARS?
[14:14] <xnox> using OVMF firmware?
[14:14] <xnox> sil2100:  if you see "*" it means you booted in bios mode
[14:14]  * xnox should push a grub change to print something sensible
[14:18] <cwayne> cachio: that doesnt make any sense, we use that image on that pi a lot
[14:21] <plars> cachio: cwayne: I can't even reach that device at the moment, so I have no idea, but it's dead now. My best guess is that something was wrong with the sd card on it, but I can't login to check
[14:25] <cachio> plars, ok
[14:26] <cachio> cwayne, I just tried to run smoke tests for core18 and that happend
[14:28] <Eighth_Doctor> mborzecki, zyga: so this is now a thing: https://docs.fedoraproject.org/en-US/ci/how-to-add-dist-git-test/
[14:28] <Eighth_Doctor> perhaps one day we could add some tests for snapd for fedora infra to run (similar to autopkgtests for debian)
[14:29] <mborzecki> Eighth_Doctor: oh nice, we had some ideads about testing packages before pushing to distros
[14:29] <zyga> nice, thank you
[14:30] <Eighth_Doctor> you can kind of thank pitti here, he pushed for this to become a thing, and learned from the mistakes in making autopkgtests
[14:31] <zyga> yay, so session tool can now track PIDs of the started processes
[14:32] <zyga> separately from the session manager
[14:32] <zyga> so that's good
[14:32] <zyga> I added that to the cgroup-tracking test
[14:32] <zyga> let's see what we get
[14:43] <zyga> Eighth_Doctor: can you ask him to push it back to Debian ;D
[14:45] <Eighth_Doctor> hah, you know as well as I do that debian doesn't do change :P
[14:49] <zyga> Eighth_Doctor: it does, in debian stable ;)
[14:58] <zyga> \o/
[14:58] <zyga> jdstrand: I reproduced the issue reliably in spread now
[14:58] <zyga> woot
[14:58] <zyga> Mar 18 14:56:41 mar181449-606426 systemd[20017]: snap.8661f9ab-6dbb-4fd5-bb75-9bb871f5dddc.test-snapd-sh.sh.scope: Failed to add PIDs to scope's control group: Permission denied
[14:59] <zyga> I can now push some simple fixes for session-tool
[14:59] <zyga> and start working on untangling this particular error
[14:59] <zyga> let me just quickly verify that it's not affecting other releaes
[14:59] <zyga> *releases
[15:00] <cachio> pedronis, mvo this is the log for the retries on uc20 https://paste.ubuntu.com/p/kjhYcqcmrw/
[15:01] <pedronis> it is saying:  error: file `/EFI/ubuntu/grubenv' not found.
[15:01] <pedronis> quite a bit
[15:01] <ijohnson> cmatsuoka: I had a look at the log for PR 8159, and if you merge master that snapd-failover issue should go away
[15:01] <mup> PR #8159: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159>
[15:02] <cmatsuoka> ijohnson: thanks, will do
[15:08] <zyga> 16.04 passes
[15:08] <zyga> I'm pretty sure 18.04 has a bug
[15:08] <zyga> that's not present in 20.04 or 16.04
[15:08] <zyga> ah, sorry 20.04 passed, 16.04 still running
[15:08] <pedronis> cachio: mvo: we don't even get to systemd in the first couple of those reboots
[15:09] <pedronis> afaict
[15:09] <mvo> pedronis: hm, yeah, this looks like initramfs snafu
[15:10] <pedronis> or something uefi related
[15:11] <pedronis> mvo: there first time we get to EFI Variables Facility v0.08 2004-May-17
[15:11] <pedronis> and then there's a reboot there
[15:12] <cachio> pedronis, could be related to the gadget snap version?
[15:12] <cachio> I am retrying with the edge version now, this run was using the stable version
[15:13] <mvo> cachio: yeah, that sounds like it could be
[15:16] <cachio> mvo, I'll have results soon
[15:16] <mvo> cool
[15:42] <mup> PR snapd#8294 opened: seed: make Brand() part of the Seed interface <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8294>
[15:49]  * cachio lunch
[15:57] <cachio> mvo, pedronis using gadget from edge I see the same
[15:58] <cachio> this is the full log https://paste.ubuntu.com/p/bsmwC5Q52b/
[15:58] <mvo> xnox: does https://paste.ubuntu.com/p/bsmwC5Q52b/ ring any bells?
[16:03] <mvo> xnox: the funny part is that after some reboots this goes away, is there maybe something in initramfs that looks for it, if it's missing the unit fails and reboots and sometimes we run stuff with the right timing and things work, would the initramfs reboot if a unit fails?
[16:04] <xnox> in a meeting
[16:04] <mvo> xnox: no worries, sry
[16:34] <xnox> mvo:  hey
[16:35] <xnox> mvo:  so that message about lack of grubenv is from grub. it failing to read and load grubenv, seems to indicate that this is not a UC20 boot? because UC20 gadget relies on grubenv to be present and valid.....
[16:36] <mvo> xnox: aha, that's interessting (cc cachio) - what's strange is that apprerntly for cachio it works after a bunch of reboots in his VM setup
[16:37] <xnox> mvo:  i am concerned on how you are starting the VM and whether or not you passed which disk is the expected correct bootdevice
[16:37] <xnox> mvo:  because it seems like your tpm state will be corrupted.
[16:38] <cachio> xnox, https://paste.ubuntu.com/p/JTGNRh7djq/
[16:39] <cachio> xnox, should I change anything in the command?
[16:39] <xnox> mvo:  the boot does not seemed to be complete. as the boot is in install mode, and the next one is as well.....
[16:39] <xnox> do the tests reboot twice correctly? and again, without grubenv being written correctly, it will not have pointer to boot into run mode.
[16:40] <xnox> cachio:  you have bootindex=1 set correctly there, so boot device is there.
[16:41] <cachio> xnox, do you want to inspect the image?
[16:41] <xnox> mvo:  cachio: i'd like to see the VM image ubuntu-core-new.img contents after it was created, but before it is booted. And the file listing of all files on all partitions, and contents of grubenv file.
[16:41] <xnox> =)
[16:41] <xnox> cachio:  we think alike ;-)
[16:41] <mborzecki> #8249 is super simple and needs a 2nd review ;)
[16:41] <mup> PR #8249: interfaces: make gpio robust against not-existing gpios in /sys <Reviewed> <Security-High> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8249>
[16:41] <mborzecki> heh
[16:42] <mborzecki> #8294 this one
[16:42] <mup> PR #8294: seed: make Brand() part of the Seed interface <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8294>
[16:45] <pedronis> mborzecki: could you review #8208 when you have time (is not simple)
[16:45] <mup> PR #8208: boot_test: add many boot robustness tests for UC20 kernel MarkBootSuccessul and SetNextBoot <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8208>
[16:47] <xnox> cachio:  mvo: the image looks quite small, i don't know if we have enough disk space to complete the install
[16:48] <xnox> it is 5.4GB big, and I usually locally make 8G/10G big images.
[16:49] <cachio> xnox, ahh, I can try with 10GB
[16:49] <cachio> does it makes sense?
[16:52] <xnox> mvo:  cachio: the failing to load grubenv is a red herring, and i should fix our grub.cfg to not print that pointlessly
[16:52] <xnox> cachio:  please try with a 10GB image, yes.
[16:53] <pstolowski> pedronis: #8270 updated with the extra fields, ready for review
[16:53] <mup> PR #8270: store: support for search API v2 <Needs Samuele review> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8270>
[16:53] <cachio> xnox, sure, running
[17:01] <pedronis> #8286 needs a 2nd review, it's simple (mostly adding tests and improving code behavior a bit)
[17:02] <mup> PR #8286: tests: cleanup various uc20 boot tests from previous PR <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8286>
[17:03] <xnox> cachio:  i'm afk / busy until end of day, sorry. Can chat tomorrow, if you will have uc20 logs from a bigger image.
[17:03] <cachio> xnox, sure, I'll try again and send you the logs in case it fails again
[17:03] <cachio> thanks for your help
[17:11] <zyga> jdstrand: hey
[17:11] <zyga> jdstrand: I've debugged the issue
[17:11] <mborzecki> pedronis: ack
[17:11] <zyga> jdstrand: dbus-user-session
[17:11] <zyga> jdstrand: the new app tracking feature depends on it and we just didn't notice because it's pre installed since eoan (on server)
[17:12] <zyga> jdstrand: I've expanded the test to completely cover running as user
[17:12] <zyga> and with this package it all passes
[17:12] <zyga> and without it it behaves just as your system did
[17:13] <zyga> jdstrand: a bionic desktop has it installed by default
[17:13] <zyga> jdstrand: but a bionic server does not
[17:13] <zyga> jdstrand: can you, if you remember, confirm where you were testing my branch at the time?
[17:13] <jdstrand> zyga: hi! (sorry, was doing 360s)
[17:14] <zyga> jdstrand: no worries :)
[17:14] <zyga> I'm so glad I made some progress on this branch
[17:15] <jdstrand> zyga: iirc, it was a bionic desktop amd64 vm, logging in over ssh
[17:15] <zyga> jdstrand: do you have dbus-user-session installed in that VM?
[17:15] <jdstrand> I'm checking now
[17:18] <jdstrand> zyga: it is installed. when I login I see this in the environ: DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
[17:18] <zyga> hmmm
[17:18] <zyga> ookay
[17:18] <zyga> that's interesting, and it's not installed recently?
[17:18] <zyga> I'll double check in any way
[17:18] <zyga> thank you
[17:19] <jdstrand> zyga: let me look at the PR again. I think I said what I was using
[17:19] <zyga> right now the tests do pass in all xenial+ systems
[17:19] <zyga> as root and as user
[17:19] <zyga> but not as user logged in via ssh
[17:19] <zyga> (I didn't write that test since it's all kind of remote)
[17:19] <zyga> but maybe it's a relevant factor
[17:22] <jdstrand> "Unfortunately, on (at least) bionic, when logged in via ssh or directly via the console"
[17:22] <zyga> ok, I'll get to it
[17:22] <zyga> I suspect something else is a factor then
[17:22] <zyga> but I'm closer, I think
[17:22] <jdstrand> zyga: sounds like you are getting there! :)
[17:23] <jdstrand> zyga: it's the feature that won't stop giving :)
[17:23] <zyga> oh yes
[17:24] <jdstrand> zyga: and for completeness, logging into a vt, DBUS_SESSION_BUS_ADDRESS was set on the console as well
[17:24] <jdstrand> I suspect that is logind for both
[17:24] <zyga> I took a snapshot of my 18.04 desktop vm and I'll dig in
[17:25] <zyga> yes, that's pam-systemd
[17:25] <zyga> though that's really
[17:25] <zyga> dbus-session-bus started in the session
[17:26] <zyga> jdstrand: is your desktop VM logged in as a desktop user?
[17:27] <jdstrand> zyga: the vm came up and is sitting at the gdm prompt. I did not login. I then ssh as the normal user (ie, the one I would use at the gdm login)
[17:28] <zyga> ok
[17:28] <zyga> thanks
[17:28] <zyga> I have the same setup now
[17:28] <zyga> and when you are logged in via ssh
[17:28] <mup> PR snapd#8295 opened: osutil: do not leave processes behind after the test run <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8295>
[17:28] <zyga> loginctl shows only two sessions?
[17:28] <zyga> one for gdm
[17:28] <jdstrand> zyga: I can say that /run/user/1000/bus exists and it is /lib/systemd/systemd --user that setup that socket
[17:28] <zyga> and one for your ssh
[17:29] <jdstrand> zyga: however, there is no dbus-daemon running under this user. just dbys-daemon --system (root) and dbus-daemon --session (gdm)
[17:29] <zyga> hmmm
[17:29] <zyga> I see
[17:29] <zyga> https://www.irccloud.com/pastebin/H3nx0PgY/
[17:29] <jdstrand> (well, there is also the accessibility bus for gdm)
[17:29] <zyga> zyga       1689  0.0  0.1  49792  3840 ?        Ss   18:26   0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
[17:30] <jdstrand> zyga: loginctl shows gdm and the user I logged in as
[17:31] <jdstrand> zyga: you have that running as 'zyga' without logging into gdm?
[17:31] <zyga> I ssh'd in
[17:31] <zyga> yes
[17:31] <zyga> but I have dbus-user-session installed
[17:31] <zyga> let me log out and double check PIDs recyce
[17:31] <zyga> oh wait
[17:31] <zyga> it's gone now
[17:32] <jdstrand> I have dbus-user-session installed, logged in via ssh and do *not* have the above in ps for my user
[17:32] <zyga> maybe it's just activated
[17:32] <zyga> ha
[17:32] <zyga> wait
[17:32] <zyga> it didn't
[17:32] <zyga> zyga@bionic-desktop:~$ systemd-run --user --scope ls
[17:32] <zyga> Job for run-re0d33bd5a3334fc39992748ea3053b88.scope failed.
[17:32] <zyga> See "systemctl status run-re0d33bd5a3334fc39992748ea3053b88.scope" and "journalctl -xe" for details.
[17:32] <zyga> that's exactly what you saw
[17:32] <zyga> what the...
[17:32] <zyga> I think my auto-login spawned dbus
[17:32] <zyga> and it was around
[17:32] <zyga> I logged out, killed that session
[17:32] <jdstrand> ah, yes, that would do it
[17:32] <zyga> logged out from ssh
[17:32] <zyga> logged back in
[17:32] <zyga> and no dbus
[17:32] <zyga> *progress*
[17:33] <jdstrand> \o/
[17:33] <zyga> thank you, I won't bother you anymore until I crack this
[17:33] <jdstrand> zyga: it feels so close! :)
[17:35] <zyga> mar 18 18:32:12 bionic-desktop systemd[2002]: run-re0d33bd5a3334fc39992748ea3053b88.scope: Failed to add PIDs to scope's control group: Permission denied
[17:43] <zyga> mvo: small review on 8295
[17:44] <zyga> mvo: will kill-sleeper work without job control in tty?
[17:46] <mvo> zyga: I don't know, I tested it locally and it was ok
[17:46] <zyga> locally it would have your pty
[17:46] <mvo> zyga: yeah
[17:46] <zyga> let's see what happens
[17:46] <zyga> mvo: I think exec sleep is better
[17:46] <zyga> then you can kill it
[17:47] <mvo> zyga: but I need the pid?
[17:47] <zyga> exec :D
[17:47] <zyga> h
[17:47] <zyga> ah
[17:47] <zyga> sorry
[17:47] <zyga> :/
[17:47] <zyga> missed that
[17:47] <mvo> zyga: :)
[17:47] <mvo> zyga: no worries
[17:47] <zyga> you could echo $$ > /tmp/pid
[17:47] <zyga> and kill that
[17:47] <zyga> but uck
[17:47] <mvo> zyga: happy about better ideas, feel free to push to the PR, it was the best I could think of
[17:47] <zyga> yeah, that's fine
[17:47] <zyga> let's see if it passes
[17:47] <zyga> I'm debugging systemd behavior now
[17:48] <zyga> but happy to look next
[17:48] <mvo> zyga: no worries, if it's good enough that would be nice if not we can iterate
[17:54] <zyga> I think I found the systemd bug
[17:54] <zyga> mkdir("/sys/fs/cgroup/pids/user.slice/user-1000.slice/user@1000.service/run-rbabf8a8b75af4ad68cf81da60da72a47.scope", 0755) = -1 EACCES (Permission denied)
[17:54] <zyga> https://bugzilla.redhat.com/show_bug.cgi?id=1413075
[17:54] <zyga> seems related
[18:52] <mup> PR snapd#8294 closed: seed: make Brand() part of the Seed interface <UC20> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8294>
[18:52] <zyga> I give up for today
[18:52] <zyga> I'm attached to systemd --user that exhibits the error
[18:52] <zyga> I have debug symbols and all that
[18:52] <zyga> I can reproduce the error at will
[18:53] <zyga> need to jump into this with fresh head tomorrow
[18:53] <zyga> jdstrand: ^ FYI
[18:53] <zyga> I also have the same setup with newer systemd on focal where it doesn't fail
[18:53] <zyga> that's all for today folks
[18:53] <zyga> o/
[18:55] <cmatsuoka> cachio: booting the test image it worked, but auto-import from /dev/sda failed (with exit code 127)
[18:57] <cachio> cmatsuoka, perhaps mvo knows about which other thing to check
[18:57] <cmatsuoka> cachio: auto-import.assert is indeed in /dev/sda
[18:58] <ijohnson> cmatsuoka: any more output from auto-import ?
[18:59] <cmatsuoka> ijohnson: not much, let me retrieve the actual log entries
[19:01] <cmatsuoka> ijohnson: https://pastebin.ubuntu.com/p/8B3JyXMsbx/
[19:02] <zyga> cmatsuoka: 127 is command-not-found IIRC
[19:02] <cmatsuoka> ijohnson: /dev/sda is where the assertion is, I mounted it and it's there
[19:02] <cmatsuoka> oh
[19:02] <zyga> so /bin/snap whatever is not tehre
[19:02] <cmatsuoka> that's embarrassing
[19:02] <zyga> ;D
[19:02] <ijohnson> well then
[19:02]  * zyga goes away
[19:03] <cmatsuoka> cachio: I think it's explained then, let me check the initramfs to see if the executable is there...
[19:04] <cmatsuoka> I mean
[19:04] <cmatsuoka> it's on the real system, right? so no, it's not tehre
[19:04] <cmatsuoka> there
[19:06] <mvo> cmatsuoka: this indicates that the snap command is not there, this usually happen on the very first boot when snapd is not seeded yet
[19:07] <cachio> cmatsuoka, do you see any error during the seeding?
[19:07] <cmatsuoka> mvo: ah yes, that makes sense
[19:07] <cmatsuoka> cachio: seeding seems good to me
[19:09] <cmatsuoka> cachio: no more auto-import messages later
[19:09] <cachio> if you restart it does it work?
[19:09] <zyga> does the auto-import service depend on seeded system?
[19:10] <zyga> it probably shold
[19:10] <zyga> *should
[19:10] <cmatsuoka> zyga: it seems that it doesn't but it should, from what we see here
[19:11] <pedronis> I think mvo has thoughts on it already
[19:11] <ijohnson> this is the same bug that came up during the sprint
[19:11] <pedronis> yes
[19:12] <pedronis> it's a known bug atm
[19:12] <mvo> cmatsuoka, pedronis yeah, I think we either need to just echo the device paths and catchup or do a udev scan of the block devices in snap.autoimport.service. it's mostly jfdi but I didn't manage to find the time for it yet
[19:13] <pedronis> it's not an immediate blocker, the cost is rebooting again
[19:13] <cachio> pedronis, in uc20 is taking so long to boot
[19:13] <cmatsuoka> ok then, now I see how this ties to the sprint conversation
[19:14] <cachio> we were researching why
[19:14] <pedronis> cachio: well, I new run reboot shouldn't take that longer
[19:14] <pedronis> cachio: isn't the issue the multiple reboots?
[19:14] <pedronis> or is this something else
[19:14] <pedronis> cachio: I mean, did we fix the issue you showed today, were we get a bunch of reboots
[19:14] <pedronis> that don't even reach systemd
[19:15] <cachio> it is something else, it was caused becuase the zise of the image was 5g and we needed 10g
[19:15] <cmatsuoka> cachio: anyway, in all my tests it booted correctly to run mode without any boot loops
[19:15] <pedronis> interesting, that seems big, do we know what's the space needed for?
[19:16] <cachio> I don't yet
[19:16] <pedronis> ok
[19:16] <cmatsuoka> pedronis: that's curious because the partition grow code is not there yet
[19:17] <cmatsuoka> so the partition sizes should stay the same
[19:18] <pedronis> do we have a weird bug in install code that makes a partition of the wrong sizes?
[19:19]  * zyga EODs
[19:19] <cmatsuoka> cachio: could you generate a 5G image for me?
[19:19] <cmatsuoka> cachio: so I can check if there's something funky in partitioning
[19:20] <cachio> sure
[19:21] <cachio> first, could you try restart that vm
[19:22] <cachio> in my case when I restart the vm it goes in a rrboot loop
[19:22] <cachio> and I see error: file `/EFI/ubuntu/grubenv' not found.
[19:25] <pedronis> do we know if it's in the image?
[19:26] <pedronis> it should be (at least we put one there end of Feb)
[19:27] <cachio> I am generating a new image to check again
[19:41] <pedronis> ijohnson: cachio: so I made an image and there's no grubenv, but that's expected I think, there will be one now with the new code
[19:42] <ijohnson> pedronis: there won't be a grubenv on the root ubuntu-seed grubenv
[19:42] <pedronis> yes
[19:43] <pedronis> not until we set mode to run
[19:43] <ijohnson> err sorry there won't be any variables set, I guess I don't know for certain whether there would be an empty grubenv or not
[19:43] <pedronis> there isn't one
[19:43] <ijohnson> yes when we run makeBootable20RunMode then we set grubenv on ubuntu-seed
[19:43] <pedronis> I just made an image and mouunted
[19:43] <ijohnson> iirc
[19:43] <pedronis> it
[19:46] <pedronis> https://paste.ubuntu.com/p/w3NbfYdt5V/
[20:20] <pedronis> cmatsuoka: is #8159 ready for a re-review ?
[20:20] <mup> PR #8159: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159>
[20:27] <cmatsuoka> pedronis: yes, I also fixed issues raised my maciek (the struct pointer issue and better attribute parsing)
[20:28] <pedronis> cmatsuoka: ok, thanks, I'll look at it in my morning
[20:29] <cmatsuoka> pedronis: I'm currently skipping partitions that have a type that's not in our list. the alternative would be to fail and abort installation
[21:03]  * cachio afk
[21:09] <mup> PR snapd#8296 opened: httputil/client_test.go: add two TLS version tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8296>
[21:10] <pedronis> ijohnson: seems here failover failed again, but it seems that PR got the latest code for that: https://api.travis-ci.org/v3/job/664035070/log.txt
[21:11] <ijohnson> pedronis: which pr
[21:11] <pedronis> ijohnson: your latest
[21:11] <ijohnson> 8287 ?
[21:11] <pedronis> #8286
[21:11] <mup> PR #8286: tests: cleanup various uc20 boot tests from previous PR <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8286>
[21:13] <pedronis> also the ubuntu-image test change breaks it
[21:13] <pedronis> su => session-tool
[21:13] <pedronis> s/ubuntu-image/prepare-image/
[21:13] <zyga> hmm?
[21:13] <zyga> session-tool broke something?
[21:13] <pedronis> I'm also not sure why using session-tool there
[21:14] <pedronis> it seems overkill, but I may be missing something
[21:14] <zyga> where?
[21:14] <zyga> I just came to check on something and noticed
[21:14] <pedronis> zyga: https://github.com/snapcore/snapd/pull/8286/files
[21:14] <mup> PR #8286: tests: cleanup various uc20 boot tests from previous PR <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8286>
[21:14] <pedronis> zyga: ijohnson replaced a su invocation with session-tool, do the test is just calling prepare-image, and things break
[21:14] <zyga> do you know why it is invoked as user in the first place?
[21:15] <ijohnson> mvo wrote the original test fwiw
[21:15] <pedronis> to check that it works
[21:15] <pedronis> as a normal user
[21:15] <zyga> aha
[21:15] <zyga> and how does it break/
[21:15] <pedronis> it's not finding an assertion, the breakage is strange
[21:15] <pedronis> anyway not sure it needs to use session-tool
[21:16] <pedronis> zyga: there's spread logs there
[21:16] <ijohnson> I mean isn't this why we have session-tool though ...
[21:16] <zyga> ok
[21:16] <ijohnson> zyga: https://pastebin.ubuntu.com/p/sJzvXy3dWw/
[21:16] <pedronis> ijohnson: do break working tests?
[21:16] <zyga> thanks!
[21:16] <pedronis> to break working tests?
[21:16] <zyga> pedronis: true always works ;)
[21:16] <ijohnson> no I mean to have a tool that "does all the right things"
[21:16] <ijohnson> su doesn't do all the right things
[21:17] <pedronis> what is right or wrong is very contextually dependent
[21:17] <zyga> hmm
[21:17] <zyga> is /home/test/tmp//model.assertion sensible
[21:17] <zyga> as in // that feels like something not expanded
[21:17] <pedronis> it's just a var ending in /
[21:17] <zyga> ah, $ROOT has / at the end
[21:17] <pedronis> anyway works with just su
[21:18] <ijohnson> it's easy enough to back out that change but it's just frustrating that we have these problems :-/
[21:18] <zyga> what places model.assertion there?
[21:19] <ijohnson> also the snapd-failover failure is very depressing tbh
[21:19] <pedronis> ijohnson: yes, that one is
[21:19] <pedronis> definitely
[21:19] <zyga> ijohnson: I made some improvements to session-tool, fixed some issues with quoting
[21:19] <zyga> but I don't suspect it's a factor in this case
[21:19] <pedronis> ijohnson: the other one I would just move back to su and be happy for a while
[21:19] <zyga> oh wait
[21:20] <zyga> hmm
[21:20] <pedronis> I'm quite all the other tests like this one use su anyway
[21:20] <pedronis> so we would have to change all or none
[21:20] <zyga> session-tool expects stuff normally, not as one big string
[21:20] <zyga> maybe my quoting fix would actually help
[21:20] <pedronis> and it doesn't seem a good use of time at this moment
[21:20] <zyga> ijohnson: yeah, leave it to me
[21:21] <zyga> I plan to do a pass
[21:21] <ijohnson> awesome, thanks zyga
[21:21] <ijohnson> I wonder if we should just stop snapd.socket then start it again rather than a restart
[21:21] <ijohnson> I just really really wish we understood why that keeps happening anyways
[21:23] <pedronis> I reverted to su for now
[21:24] <pedronis> we have 29 places using it still
[21:25] <zyga> I pushed some fixes to session tool
[21:25] <zyga> https://github.com/snapcore/snapd/pull/8297
[21:25] <mup> PR #8297: tests: session-tool improvements <Created by zyga> <https://github.com/snapcore/snapd/pull/8297>
[21:25] <pedronis> that's good, I don't think converting su to session-tool is somethign anybody should work on unless there is a good reason for specific tests at this point in time
[21:26] <pedronis> though
[21:26] <pedronis> too many other things
[21:26] <mup> PR snapd#8297 opened: tests: session-tool improvements <Created by zyga> <https://github.com/snapcore/snapd/pull/8297>
[21:26] <zyga> pedronis: I think it's that they are definitely not really testing the feature
[21:26] <pedronis> which feature?
[21:26] <zyga> pedronis: su is not representative of a user running the code
[21:26] <zyga> pedronis: anything
[21:27] <zyga> pedronis: it's really 90% root
[21:27] <zyga> pedronis: 10% user
[21:27] <pedronis> maybe
[21:27] <pedronis> it depends
[21:27] <zyga> pedronis: if the point of the test is to check if it runs for normal people
[21:27] <zyga> su is not it
[21:27] <zyga> it does depend
[21:27] <zyga> but we should generally not use su, because it depends is complicated
[21:27] <pedronis> is still not a good use of time all things considered
[21:27] <pedronis> at this point in time
[21:27] <zyga> sure, at some point it will though
[21:27] <pedronis> yea
[21:28] <pedronis> let's try to get there
[21:28] <zyga> indeed :)
[21:28]  * zyga wrote a comment on https://github.com/snapcore/snapd/pull/7825#issuecomment-600861003 that is sad but relevant
[21:28] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[21:28] <zyga> (not to this discussion though)
[21:29] <zyga> and I'm back to being away
[21:40] <mvo> zyga: we prefer "win the lottery" instead of "hit by bus" - just saying :)
[21:41] <zyga> mvo: if I win a lottery I will perpetually send patches for things I like and not worry about paycheck ;)
[21:41] <zyga> mvo: *then* you get the bus :)
[21:42] <zyga> I've installed buster now
[21:42] <zyga> and installing nvidia driver
[21:42] <ijohnson> haha
[21:44] <mvo> ha!
[21:44]  * mvo really calls it a day
[21:44] <zyga> mvo: can you dput to buster-backports?
[21:44]  * zyga wonder if he saw that
[21:54] <zyga> nvidia + debian = :(
[21:54] <zyga> + snaps
[22:41] <ppd> zyga: Not so nice to hear. Thanks for investigating the Nvidia problem though
[23:23] <cmatsuoka> cachio: #8260 tests failed
[23:23] <mup> PR #8260: tests: enable nested on core20 and test current branch <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8260>
[23:36] <cachio> cmatsuoka, I'll push a small change now to retrigger this
[23:36] <cachio> need to wait until tests pass here
[23:40] <cmatsuoka> it seems that tests are especially slow today