[04:40] <mup> PR snapd#8374 opened: .github: register a problem matcher to detect spread failures <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8374>
[05:39] <mup> PR snapd#8375 opened: github: always run the "Discard spread workers" step, even if the job fails <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8375>
[05:43] <mborzecki> morning
[06:15] <mborzecki> hmm core20 hangs in spread tests again?
[06:16] <mborzecki> looks like it's hitting job kill-timeout when rebooting during prepare
[06:21] <mborzecki> hmm perhaps https://github.com/snapcore/snapd/pull/8373 fixes that
[06:21] <mup> PR #8373: tests/lib/prepare.sh: use only initrd from the kernel snap <UC20> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8373>
[06:26] <zyga> o/
[06:26] <jamesh> morning zyga
[06:26] <zyga> hey james
[06:27] <jamesh> zyga: here's a simple PR for the github actions CI: https://github.com/snapcore/snapd/pull/8375
[06:27] <mup> PR #8375: github: always run the "Discard spread workers" step, even if the job fails <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8375>
[06:27] <jamesh> make the cleanup run even if the tests fail
[06:27] <zyga> super nice
[06:27] <zyga> thank you James
[06:27] <zyga> I didn't know about the implicit if
[06:28] <jamesh> I also had a go at adding a problem matcher: it adds the error to the annotation list, but doesn't jump to the log line as I thought it did: https://github.com/snapcore/snapd/pull/8374
[06:28] <jamesh> (maybe I was misremembering how that worked)
[06:28] <mup> PR #8374: .github: register a problem matcher to detect spread failures <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8374>
[06:28] <zyga> I love this :)
[06:29] <zyga> little by little but even this is so much better than what we had before
[06:29] <zyga> that's fantastic
[06:29] <zyga> I think we could move more stuff over this week
[06:29] <zyga> let's see what we can get
[06:30] <mborzecki> zyga: jamesh: hey
[06:30] <jamesh> hi mborzecki
[06:32] <mborzecki> wish the uc20 spread job actually worked
[06:32] <mborzecki> mvo: hey
[06:32] <zyga> hey mvo
[06:33]  * zyga is pre breakfast still so will go away for a while 
[06:33] <jamesh> zyga: Longer term, it might make sense to have Spread output error annotations when it thinks it is running under the Github runner
[06:33] <jamesh> it could provide extra info like the task file name
[06:34] <mborzecki> jamesh: hopefully the runner makes it easy to detect such scenario
[06:34] <zyga> jamesh: yeah, I think that would be great, spread has specific travis features, it could have github features
[06:34] <zyga> I think the goal should be to phase out travis
[06:34] <zyga> so that nobody is stuck waiting
[06:34] <zyga> then optimize
[06:34] <mborzecki> otherwise it's ugnly job level  env vars again or somesuch :/
[06:34] <jamesh> mborzecki: there are environment variables it is documented to set, similar to Travis
[06:36] <jamesh> https://help.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables says it will always set GITHUB_ACTIONS=true
[06:38] <mborzecki> ha nice
[06:38] <mvo> hey mborzecki and zyga !
[06:39] <zyga> how are you doing? it's quite cold today
[06:39] <zyga> yesterday was both +18 and -2 at night (and snow)
[06:40] <mborzecki> zyga: it was ~13C before noon, then 2 with a snow/rain mix in the afternoon here
[06:40] <mborzecki> felt like the afternoon was a completely different day
[06:51] <zyga> breakfast time
[06:53] <mup> PR snapd#8375 closed: github: always run the "Discard spread workers" step, even if the job fails <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8375>
[06:58] <mup> PR snapd#8365 closed: seed: add Info() method for seed.Snap <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8365>
[07:03] <pstolowski> morning
[07:04] <mvo> hey pstolowski - good morning
[07:04] <mvo> fwiw lxd tests are broken right now
[07:04] <mvo> not sure why yet, but it seems pretty consistent
[07:12] <mup> PR snapd#8374 closed: .github: register a problem matcher to detect spread failures <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8374>
[07:18] <jamesh> mvo: thanks for doing the merges.  I think the problem matcher is about as good as it can get: further improvements would probably need to happen in Spread itself
[07:19] <mvo> jamesh: yeah, I was thinking that we might need to modify spread
[07:19] <mvo> jamesh: that's fine, thanks again for this, it's so much better than what we had before
[07:19] <jamesh> mvo: e.g. it would be nice to tie the error to the task.yaml file, but the problem matcher can only use information present in the error message
[07:24] <mborzecki> power outage :/ moved to my parent's
[07:31] <mborzecki> travis job failed again in #8373
[07:31] <mup> PR #8373: tests/lib/prepare.sh: use only initrd from the kernel snap <UC20> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8373>
[07:31] <mvo> mborzecki: probably the lxd issue
[07:31] <mvo> mborzecki: also, does it have two reviews?
[07:31] <mborzecki> kill-timeout reached after mar300623-305765 (google:ubuntu-core-20-64:tests/regression/) reboot request
[07:32] <mborzecki> mvo: all test suites failed on uc20
[07:32] <mborzecki> (on prepare)
[07:32] <mvo> mborzecki: uh, no that then :)
[07:32] <mvo> mborzecki: right, because of the kernel/initramfs issue?
[07:32] <mborzecki> wish the console was easily accessible
[07:32] <mborzecki> mvo: yeah
[07:32] <mvo> mborzecki: does it only fail in gce or also with qemu?
[07:33] <mborzecki> mvo: haven't tried qemu yet, i'll try to obtain the image from gce
[07:33] <zyga> re
[07:33] <mvo> mborzecki: yeah, qemu should give a lot more visiblity into this, so we still don't know what is going on :( ?
[07:33] <zyga> sorry, it's hard to organize kids still
[07:58] <pedronis> mvo: hi, #8325 has a conflict now also as we know needs a bit more work
[07:58] <mup> PR #8325: snap-bootstrap: copy auth data from real ubuntu-data in recovery mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8325>
[07:59] <mvo> pedronis: thanks, look today (many meetings this morning unfortunately)
[08:29] <mborzecki> any clue why it's no longer possible to connect via ssh to a spread node?
[08:30] <mborzecki> spread can do it, but once i got the debug shell, i cannot establish any new ssh connections
[08:39] <pedronis> mborzecki: hi, I made a comment in the stand up notes about a thing that landed Friday, also did review some of your open PRs
[08:39] <mborzecki> pedronis: thanks!
[08:40] <zyga> re
[08:42] <mborzecki> pedronis: also wondering whether we should support GET on /v2/systems/{label}, but there does not seem to be any potential use cases atm
[08:42] <pedronis> mborzecki: we can add it later, but yes would leave it alone for now
[08:42] <mborzecki> ack
[08:48] <mup> PR snapd#8376 opened: daemon: make POST /v2/systems/<label> root only <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8376>
[08:52] <pedronis> degville: hi, could you look at this when you have a moment: https://github.com/snapcore/snapd/pull/8372#discussion_r400026498
[08:52] <mup> PR #8372: [RFC] devicestate: generate warning if seeding fails <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8372>
[08:54] <degville> pedronis: morning - looking now!
[09:08] <mborzecki> sooo when i apt install openssh-server to pull in the update of sshd, i can log in over ssh again
[09:28] <zyga> Brb
[09:35] <mborzecki> i pulled the uc20 image built from master branch and it seems to work
[09:58] <zyga> mborzecki: cgroup code I mentined yesterday is in 8377
[09:58] <mborzecki> zyga: ack
[09:58] <mup> PR snapd#8377 opened: sandbox/cgroup: add ProcessPathInTrackingCgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/8377>
[10:47] <zyga> I'll get some mint
[10:47] <zyga> brb
[10:52] <mborzecki> moving back home
[10:53] <zyga> shit, I forgot about the mint/tea
[10:53] <zyga> brb
[10:53] <zyga> really
[10:53] <zyga> I'll push a fix for session-tool, sorry for annoying failures everyone
[11:06] <mup> PR snapd#8378 opened: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
[11:12] <mborzecki> and back
[11:21]  * zyga stresses session-tool to see if the issue is gone
[11:43] <pedronis> mvo: commented on #8325 also there is stil a conflict
[11:43] <mup> PR #8325: snap-bootstrap: copy auth data from real ubuntu-data in recovery mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8325>
[11:55] <mup> PR snapcraft#2997 opened: specifications: progressive delivery <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2997>
[11:56]  * zyga is surpsised by the surge of snow outdoors!!!
[12:00] <thresh> since https://snapcraft.io/docs/personal-files-interface says it requires snapd 2.37+, how can I check for snapd version in the wrapper script that launches my app?
[12:00] <zyga> thresh: don't use assumes: [snapd2.37]
[12:01] <zyga> https://snapcraft.io/docs/snapcraft-yaml-reference and search for "assumes"
[12:01] <thresh> zyga, will that force user to upgrade to the needed version if they somehow fetch my snap on an older machine?
[12:01] <zyga> thresh: it will prevent installation on an older snapd
[12:01] <thresh> that is not something I would want, then
[12:01] <zyga> thresh: but we're not seeing old snapd's in the wild
[12:01] <zyga> thresh: why?
[12:02] <zyga> thresh: snapd has a self-update mechanism
[12:02] <thresh> OK
[12:02] <zyga> thresh: virtually everyone runs the current stable version
[12:02] <thresh> I mean, I assumed not everyone updates
[12:02] <thresh> Thanks
[12:02] <zyga> good luck :)
[12:02]  * zyga cannot reproduce session-tool failure on ubuntu, I'll try some other distro and send a PR next
[12:10] <mborzecki> well, there are those that use snapd from distro repositories
[12:10] <mborzecki> but most major distros should be covered and have something quite recent available
[12:12] <pedronis> mvo: this is fixed, right? https://bugs.launchpad.net/snapd/+bug/1867755
[12:13] <mup> Bug #1867755: snapd fails to build in focal, unit test clientSuite.TestClientFindFromPathErrIsWrapped fails <snapd:New> <https://launchpad.net/bugs/1867755>
[12:42] <mvo> pedronis: yes, let me close it
[12:42] <ijohnson> morning folks
[12:42]  * ijohnson is super tired today for some reason
[12:53] <cwayne> ijohnson: same here, but i think just cause it's rainy and gloomy and monday
[12:53] <ijohnson> cwayne: since this is happening to both of us I think it's totally fair to blame the CDG airport
[12:53] <cwayne> way ahead of you
[12:53] <ijohnson> (in addition to the mondayness of today)
[12:54] <cwayne> it is pretty peak monday
[12:54] <ijohnson> how's your treadmill working out
[12:55] <cwayne> not too badly, averaging about ~4mi per day so far on it i think
[12:55] <ijohnson> nice
[12:55] <cwayne> everyone laughed at me for panic buying a treadmill, then they closed the gyms the next day and now i'm supposed to stay home so HA
[12:55]  * ijohnson has gotten really bad at not exercising more with the lockdown and all
[12:56] <cwayne> i've been exercising more since hte lockdown, but ive also eaten everything on planet earth.
[12:56] <cwayne> like my wife keeps stockpiling food
[12:56] <cwayne> and them im like OH SHIT FOOD
[12:56] <cwayne> and then its gone.
[12:57] <ijohnson> it's a good thing you're not in MN otherwise we both would have eaten all the food here, it'll probably take us a while to eat our way through the eastern US and new england before there's none left
[12:59] <cwayne> christina goes "that should last us a week" and then im just like "lol sure watch this"
[12:59]  * ijohnson imagines cwayne going "hold my treadmill"
[13:00] <cwayne> total re-emergence of 2012 vintage fat cwayne
[13:00] <cwayne> fun times
[13:02] <mborzecki> cmatsuoka: cachio: standup is now ;) tz was switched over the weekend
[13:04] <cachio> ah
[13:04] <cachio> ok
[13:05] <cmatsuoka> oh ouch
[13:33] <mup> PR core20#22 closed: run-snapd-from-snap: don't try to load a snapd snap from the seed anymore <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/core20/pull/22>
[13:42] <zyga> brb, coffee
[13:42] <zyga> amazing sun + snow experience toda
[13:43] <ijohnson> mvo did you see that folks responded on the lxd bug ?
[13:56] <ijohnson> zyga: ackk what's the special mount ns experimental setting I need to set to let the maas snap refresh ?
[13:56] <ijohnson> `snap set system experimental.<something> true` ?
[13:57] <ijohnson> nvm I see that it's `robust-mount-namespace-updates`
[13:57] <zyga>  ijohnson snap set core experimental.robust-mount-namespace-updates=true
[13:57] <ijohnson> yep that's it
[13:58] <mvo> ijohnson: I did not, let me check
[14:03] <zyga> wall of snow outdoors!
[14:07] <roadmr> yay! I want snow, all we have had is 2 crappy days of rain (even indoors, stupid roof leak)
[14:24] <cachio> mvo, I tested the lxd test installing lxd from edge and hte error is the same
[14:25] <cachio> mvo, I still see + lxd.lxc exec my-nesting-ubuntu -- lxd.lxc exec my-inner-ubuntu -- echo from-the-INSIDE-inside
[14:25] <cachio> Error: EOF
[14:37] <mvo> cachio: nice, let's add this to the LP bugreport
[14:39] <cachio> I already did ti
[14:39] <cachio> it
[14:42] <cachio> mvo, I forgot to ask about 2.44.1 to stable today
[14:42] <cachio> it is ok to strart the pregressive release today?
[14:42] <mvo> cachio: either today or tomorrow, if all looks good
[14:43] <mvo> cachio: fine to start phasing today
[14:43] <cachio> mvo, nice, thanks
[15:00] <mborzecki> pedronis: we want /var/lib/snapd/seed RO, but /run/mnt/ubuntu-seed is TBD
[15:01] <pedronis> yes
[15:01] <mborzecki> ok, cool
[15:06] <mup> PR pc-amd64-gadget#39 opened: Drop no longer used snap_kernel fallback <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/39>
[15:22] <mup> PR snapd#8379 opened: many: comment or avoid cryptic snap-ids in tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/8379>
[15:23] <alan_g> cachio, looks like the rawhide image needs refreshing: https://api.travis-ci.com/v3/job/308689304/log.txt
[15:25] <cachio> alan_g, hui, fedora refresh is scheduled for today, it is gonna happen in few hours
[15:26] <cachio> alan_g, I'll let you know when it is ready
[15:26] <alan_g> :)
[15:32] <mup> Issue core20#29 opened: core20 ubuntu-seed mount point should be read only <Created by xnox> <https://github.com/snapcore/core20/issue/29>
[15:34] <mup> PR core20#30 opened: Make /var/lib/snapd/seed bind-mount ro <Created by xnox> <https://github.com/snapcore/core20/pull/30>
[15:35] <zyga> brbb
[15:50] <mup> Issue core20#29 closed: core20 ubuntu-seed mount point should be read only <Created by xnox> <Closed by xnox> <https://github.com/snapcore/core20/issue/29>
[15:50] <mup> PR core20#30 closed: Make /var/lib/snapd/seed bind-mount ro <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/30>
[15:51] <mup> PR pc-amd64-gadget#39 closed: Drop no longer used snap_kernel fallback <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/39>
[15:52] <thresh> so I've been rereading the snapcraft.yaml syntax docs, and found out I didnt set license: and title:.  I did, but now I get "Issues while validating snapcraft.yaml: Additional properties are not allowed ('title', 'license' were unexpected)"
[15:53] <thresh> yml is at https://code.videolan.org/thresh/vlc/-/blob/snap-fixes/extras/package/snap/snapcraft.yaml#L6
[15:56] <thresh> it's on snapcraft, version 2.43.1+18.4
[15:59] <thresh> and an unrelated question, do I need an avahi-observe interface if I already have network?
[16:02] <zyga> re
[16:02] <zyga> mborzecki: I've reduced the failing case and added logging to the tool itself
[16:03] <zyga> mborzecki: now it doesn't fail, I wonder if that's because of (perhaps) synchronization due to logging and set -x
[16:03] <zyga> thresh: I think license has a long-standing issue, as for title, I think it's gone (but I could be wrong)
[16:03]  * zyga goes away to eat dinner
[16:20] <zyga> re
[16:20] <zyga> INFURIATING it keeps working
[16:24] <zyga> mvo: as for debian snapd package, you didn't commit the change to vcs
[16:24] <zyga> mvo: the salsa git repo seems out of date (2.37 vs 2.44.1)
[16:27] <thresh> how do I set the license that is shown in snap info vlc then?
[16:27] <thresh> now it's "unset"
[16:27] <zyga> thresh: you can set it but I don't know if this will fly through the store,
[16:28] <zyga> CC degville ^ do you know if licenses work?
[16:28] <pedronis> it's meant to be set through the store atm
[16:28] <thresh> It's set in the store: License GPL-2.0+
[16:28] <thresh> as from https://snapcraft.io/vlc
[16:30] <degville> zyga / thresh: yeah, it's in the store page for a snap (https://snapcraft.io/docs/using-the-snap-store)
[16:32] <thresh> degville, thanks, I see it's set in the store: https://i.imgur.com/WKFIOLz.png, but I don't see it in "snap info vlc": https://i.imgur.com/uwIGcd8.png
[16:33] <mup> PR snapd#8380 opened: tests: add LXD_CHANNEL environment <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8380>
[16:33] <pedronis> thresh: snapd takes it from the snap
[16:34] <pedronis> not all the dots are connected here
[16:34] <thresh> that sounds like a mess :-)
[16:34] <thresh> where do I file a bug to get it fixed?
[16:35] <pedronis> thresh: well, snapcraft should let you set a license
[16:35] <pedronis> the snapd side is this: https://bugs.launchpad.net/snappy/+bug/1853670
[16:35] <mup> Bug #1853670: snap always shows license as 'unset' after install <Snappy:Triaged by pedronis> <https://launchpad.net/bugs/1853670>
[16:35] <pedronis> there's a long forum thread as well
[16:35] <pedronis> pointed by that bug
[16:36] <thresh> snapcraft doesnt let me set one, I get "Additional properties are not allowed" when providing it
[16:36] <thresh> so I guess the consensus moved to setting it on the store only
[16:36] <mvo> zyga: I did commit to my repo I think
[16:37] <mvo> zyga: and iirc there is a MP for my repo to the shared one
[16:37] <zyga> ah, I see
[16:37] <zyga> I guess that's why
[16:37] <pedronis> thresh: there is no final consesus yet
[16:37] <zyga> thresh: so I just checked
[16:37] <zyga> thresh: I made a snap last weekend
[16:37] <zyga> and I did set a license
[16:37] <zyga> when I don't have it
[16:37] <zyga> snap info ...
[16:38] <zyga> doesn't show the license (it says unknown)
[16:38] <zyga> when I install it
[16:38] <zyga> I *do* see the license
[16:39] <zyga> thresh: I set the top-level "license" field to a valid SPDX expression
[16:39] <mup> PR snapd#8381 opened: tests: skip lxd test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8381>
[16:39] <thresh> hmm
[16:40] <thresh> thanks for your help
[16:49] <ijohnson> thresh: also note that you may have an older version of snapcraft which doesn't understand new keys, are you using snapcraft from the deb or from the snap ?
[16:49] <zyga> ok, 20K iterations of the tool, I suspect there's something I did that fixed this bug
[16:49] <zyga> now let me think what I did
[16:49]  * zyga checks diff
[16:50] <thresh> ijohnson, I'm using the snapcraft version from Ubuntu bionic, 2.43.1+18.04
[16:50] <thresh> from a .deb
[16:50] <zyga> thresh: snap install snapcraft --classic
[16:51] <mup> PR snapd#8382 opened: packaging: detect broken seed during focal and disable it <Created by mvo5> <https://github.com/snapcore/snapd/pull/8382>
[16:51] <ijohnson> thresh: then your snapcraft is certainly out of date
[16:51] <ijohnson> see zyga's comment
[16:51] <thresh> not sure that's possible since my build environment is in a docker container
[16:52] <thresh> but we'll see
[16:52] <zyga> ah
[16:52] <zyga> then probably not
[16:52] <zyga> can you not use docker?
[16:52] <thresh> not really, VLC CI uses it extensively
[16:52] <zyga> hum
[16:52] <zyga> thresh: please ask in #snapcraft
[16:52] <zyga> I don't really know
[16:53] <ijohnson> thresh: there are ways to use modern snapcraft inside a docker container
[16:54] <zyga> I haven't tried docker in years
[16:54] <zyga> and not following the set of current trends
[16:54] <zyga> as to which fork to use
[16:55] <zyga> thresh: note that there _is_ one thing that may help you
[16:55] <zyga> thresh: snapcraft has a mode where it "destroys" the environment by installing deps directly onto the system
[16:55] <thresh> I assume those ways are: setting up systemd inside, and dropping all security boundaries docker (might) provide
[16:56] <zyga> thresh: but please ask in #snapcraft for details
[16:56] <thresh> thank you zyga!
[17:00]  * zyga reproduced the error and has more logs
[17:10] <zyga> ha
[17:10] <zyga> I see where it's failing in pam
[17:13] <zyga> enabled debug in pam_systemd.so and should see the "warning" that makes it fail
[17:13] <zyga> I'm so happy
[17:13] <zyga> I know why it fails :)
[17:14] <zyga> and better yet, I think I know how to fix it (or work around it at least)
[17:14] <zyga> I'll make one last coffee of the daty
[17:14] <zyga> *day
[17:35] <zyga> brb, going for that coffee now
[17:44] <ijohnson> thresh see https://snapcraft.io/docs/build-on-docker
[17:45] <ijohnson> sorry bad internet connection right now, keeps cutting out on me
[17:48] <thresh> ijohnson, thanks!  is that image already published somehwere on docker hub?
[17:58] <zyga> mvo: reading now
[18:00] <zyga> mvo: https://github.com/snapcore/snapd/pull/8382#pullrequestreview-384099150
[18:00] <mup> PR #8382: packaging: detect broken seed during focal and disable it <Created by mvo5> <https://github.com/snapcore/snapd/pull/8382>
[18:00] <mvo> zyga: looking
[18:00] <zyga> ha
[18:00] <zyga> I have the proof of what is failing
[18:01] <zyga> https://pastebin.ubuntu.com/p/sGjFSkdMJh/
[18:01] <zyga> session startup is cancelled
[18:02] <zyga> because of session termination
[18:02] <zyga> I've reduced my test case to simple session-tool -u test true # twice
[18:02] <zyga> without synchronization it will fail
[18:02] <zyga> adding synchronization fixes it
[18:03] <zyga> but I need to think how to expose that to session-tool
[18:03] <zyga> specifically since it is needed to run in the background for some tests
[18:03] <zyga> one way of solving that would be to alter the shutdown time
[18:03] <zyga> via logind configuration
[18:03] <zyga> this way session-tool -u test foo; session-tool -u test bar; could run in one session
[18:05] <zyga> uh, the relevant part was cut
[18:05] <zyga> er-l:session): Failed to create session: Start job for unit user-12345.slice failed with 'canceled'
[18:14] <mup> PR snapcraft#2997 closed: specifications: progressive delivery <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2997>
[18:20] <ijohnson> alright I'm back from lunch and hopefully my internet is stable again
[18:30] <mup> PR snapd#8270 closed: store: support for search API v2 <Needs Samuele review> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8270>
[18:32] <mup> PR snapd#8381 closed: tests: skip lxd test <Simple 😃> <Created by sergiocazzolato> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8381>
[18:33] <mup> PR snapd#8383 opened: store: support for search API v2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8383>
[18:38] <mup> PR snapd#8384 opened: tests: run "lxd" test again (reverts PR#8381) <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8384>
[18:39] <mup> PR snapd#8380 closed: tests: add LXD_CHANNEL environment <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8380>
[18:41] <mup> PR snapd#8379 closed: many: comment or avoid cryptic snap-ids in tests <Simple 😃> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8379>
[18:50] <cachio> zyga, hey, I see this in bionic https://paste.ubuntu.com/p/KfDCxsxTcS/
[18:50] <zyga> checking
[18:51] <cachio> this is the branch which tests the image weekly update
[18:51] <zyga> (except it does not load)
[18:52] <cachio> zyga, same errror for mount-ns:inherit
[18:52] <zyga> hmm
[18:52] <zyga> ok, now it loaded
[18:52] <ijohnson> zyga: cachio: looks like there's a new mount for efivars, is this with a new / different image ?
[18:52] <zyga> oh
[18:52] <zyga> efivars
[18:52] <zyga> you've booted a efi system
[18:53] <cachio> it is a new image
[18:53] <cachio> ijohnson, not sure if efi is enabled on that one
[18:53] <ijohnson> hmm I wonder if we need a different set of expected mount ns data files for this new bionic image
[18:53] <ijohnson> cachio: how is the bionic image different? is it just updated ?
[18:53] <mup> PR snapcraft#2998 opened: CODE_STYLE: update to reflect latest conventions <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2998>
[18:54] <cachio> I'll check because ubuntu cloud is enabling efi in many new images
[18:54] <zyga> cachio: were we booting in legacy bios before?
[18:54] <zyga> cachio: I'm pretty sure this is not specific to bionic
[18:54] <zyga> it's been there forever (since 2004) if you used efi
[18:54] <cachio> checking focal
[18:54] <zyga> I could be wrong but just check you systems
[18:54] <zyga> do you have that mounted?
[18:54] <ijohnson> hmm yeah if that's the case it's easier to change the singular bionic image dataset, it would be annoying though if we get different images and have to have different datasets
[18:55] <cachio> focal works well
[18:55] <zyga> I'm happy to have a efi vs legacy bios dataset for specific releases assuming it's a one way trend
[18:55] <ijohnson> I mean I have that mounted but I also use a UEFI system so I don't think that's representative
[18:55] <zyga> cachio: can you run "bootctl"
[18:55] <zyga> cachio: on that new image
[18:55] <zyga> and tell me what it prints?
[18:55] <ijohnson> cachio: is this happening on all bionic images now?
[18:56] <cachio> I just saw that in the new one
[18:56] <cachio> which I created to update the image
[18:56] <cachio> ijohnson, let me check on travis
[18:57] <zyga> cachio: can you please check bootctl
[18:57] <zyga> cachio: are images somehow packaged with information on how to boot them
[18:57] <zyga> ?
[18:57] <cachio> in that image, I am creating it again
[18:59] <cachio> zyga, I am starting the instance
[18:59] <cachio> to run bootctl
[18:59] <zyga> thanks
[18:59] <zyga> cachio: when you start the instance, do you use GCE dashboard?
[18:59] <zyga> cachio: I wonder if there's any information about how it boots there
[19:00] <zyga> (I'm not familiar with GCE)
[19:00] <cachio> I can check that
[19:00] <zyga> that FS would for sure not be mounted on legacy boto
[19:00] <zyga> *boot
[19:00] <zyga> and since we've never seen it before it's the only explanation I can think of
[19:00] <cachio> zyga, https://paste.ubuntu.com/p/yqqsVTRyPR/
[19:01] <zyga> yeah
[19:01] <zyga> this is botoed in efi mode
[19:01] <zyga> can you boot the previous image?
[19:01] <zyga> I mean, that's not bad, we can adjust the test to just expect this
[19:01] <zyga> if you want to take it forward in EFI mode
[19:01] <cachio> zyga, yes
[19:01] <zyga> please just let me know if we know how this happened
[19:01] <zyga> if this is something GCE changed
[19:01] <zyga> or we (ubuntu publishing the images) changed
[19:01] <zyga> or what?
[19:01] <zyga> and let me know
[19:02] <zyga> it's late so I won't touch this today
[19:02] <zyga> but I can adjust this easily tomorrow
[19:02] <cachio> ubuntu is publishing the images with that chagne
[19:02] <cachio> I just install some dependencies on top of that
[19:02] <zyga> can you ask the cloud team about this change
[19:02] <cachio> and do some other configurations
[19:02] <zyga> is this an accident
[19:02] <zyga> or something they did on purpose
[19:03] <cachio> zyga, this is the old one https://paste.ubuntu.com/p/nW94yvZKV6/
[19:04] <zyga> hmmm
[19:04] <zyga> so it's also booted with efi
[19:04] <cachio> zyga, do you know who is the main contact for asking that?
[19:04] <zyga> I don't know
[19:04] <zyga> but it seems that there's more to it than that
[19:04] <zyga> ah
[19:04] <zyga> sorry
[19:04] <zyga> I'm blind
[19:04] <zyga> wrong tab
[19:04] <zyga>     Not booted with EFI
[19:04] <zyga> so the old image was legacy
[19:04] <cachio> yes
[19:04] <zyga> new image is EFI
[19:05] <zyga> ask around in ubuntu-server maybe
[19:05] <zyga> or check the directory for a contact person that will redirect you
[19:05] <cachio> ok
[19:05] <zyga> you can file a bug and assign it to me to fix the test to handle EFI
[19:05] <zyga> just include that diff from the test
[19:05] <zyga> and if you can, a way to run against the new image to confirm
[19:05] <cachio> zyga, sure, thanks
[19:05] <zyga> thank you for bringing this up :)
[19:15] <mup> PR snapcraft#2998 closed: CODE_STYLE: update to reflect latest conventions <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2998>
[19:18]  * zyga fires up final test and goes home
[19:18]  * zyga waves
[19:18] <zyga> see you tomorrow ijohnson, cachio and cmatsuoka
[19:18] <ijohnson> have a good night zyga
[19:19] <cmatsuoka> good night zyga
[19:24] <cachio> zyga, see you
[19:24] <cachio> zyga, lp:1869788
[19:25] <cachio> thanks
[19:35]  * cachio afk
[20:00] <mup> PR snapcraft#2999 opened: requirements: uprev python-apt to 1.6.0 (bionic package) <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2999>
[20:57] <mup> PR snapcraft#3000 opened: repo: use python-apt's fetch_binary implementation <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3000>
[21:21] <mup> PR snapcraft#3001 opened: repo: type annotations and mypy fixes for base <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3001>
[21:30] <mup> PR snapcraft#3002 opened: repo: use functools.lru_cache for dpkg -L queries <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3002>
[22:36] <mup> PR snapcraft#3003 opened: repo: always use host source lists and remove those found in plugins <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3003>