[06:10] <mborzecki> morning
[06:34] <mborzecki> mvo: hey
[06:38] <mvo> mborzecki: hey, good morning
[06:40] <mborzecki> mvo: in the context of https://forum.snapcraft.io/t/apps-not-in-desktop-search-menu/15275 do you recall why we didn't add a user env generator?
[06:41] <mvo> mborzecki: hm, I thought we had a generator
[06:41] <mborzecki> mvo: we have a system-env generator
[06:41] <mvo> mborzecki: indeed, I think there is no reason then
[06:42] <mvo> mborzecki: maybe it was because older systemds do not support this yet?
[06:42] <mborzecki> mvo: mhm, i'll add one and we can ship it selectively if needed
[06:44] <mvo> mborzecki: +1
[07:04] <zyga> Hello :-)
[07:05] <mborzecki> zyga: hey
[07:07] <mvo> hey zyga
[07:15] <mborzecki> zyga: do you still have that opensuse vm? https://forum.snapcraft.io/t/error-while-loading-shared-libraries-on-opensuse-tumbleweed/15285
[07:17] <mup> PR snapd#8073 closed: daemon: drop support for the DELETE method <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8073>
[07:53] <zyga> mborzecki: sure
[07:53]  * zyga is in the office now
[07:54] <zyga> weird
[07:56] <zyga> I'll try
[07:57] <zyga> mborzecki: offtopic, stuff from weekend: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1095r0.pdf
[07:59] <zyga> mvo: have you seen https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1861648
[07:59] <mup> Bug #1861648: When booting 20.04 an 'ld-2.23.so' process consumes 100% CPU for minutes <champagne> <focal> <performance> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1861648>
[07:59] <zyga> mvo: could that be fontconfg?
[07:59] <zyga>  (or related?)
[08:01] <pstolowski> morning
[08:02] <zyga> hey pawel, welcome back
[08:02] <mborzecki> pstolowski: hey, all rested?
[08:03] <mvo> zyga: it could be, slightly strange but possible
[08:03] <mvo> pstolowski: hey, welcome back! we missed you :)
[08:03] <mvo> pstolowski: (in a good way)
[08:04] <mborzecki> `error: too early for operation, device not yet seeded or device model not acknowledged` wonder if we could prouce something more friendly instead of this error message
[08:04] <zyga> mborzecki: oh yeah
[08:04] <zyga> I saw that a few times
[08:04] <zyga> and it's very precise and very useless
[08:05] <mborzecki> zyga: annoying when it happens on `snap install` right after you installed the snapd package
[08:05] <zyga> yeah, I wonder if snap <foo> from command line could block and hold while stuff like that happens
[08:05] <zyga> but that's a separate concern from just making a readable message
[08:06] <zyga> like "snapd is performing first-boot setup process, please wait (10%)"
[08:07] <zyga> mborzecki: updating suse (882 updates over weekend)
[08:07] <zyga> mborzecki: I'll try those snaps in a moment
[08:07] <pstolowski> hey guys! yep, rested, i had great time with my family; i only wish there was more snow
[08:08] <zyga> pstolowski: I think you had more snow than the rest of poland :)
[08:08] <zyga> but yeah, I wish this winter was better
[08:12] <zyga>  mborzecki wow
[08:12] <zyga> type=AVC msg=audit(1580717508.948:224): apparmor="DENIED" operation="mknod" profile="/usr/lib/snapd/snap-confine" name="/sys/fs/cgroup/devices/snap.poddr.poddr/cgroup.procs" pid=4155 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
[08:12] <zyga> type=AVC msg=audit(1580717508.948:225): apparmor="DENIED" operation="open" profile="/usr/lib/snapd/snap-confine" name="/sys/fs/cgroup/devices/snap.poddr.poddr/cgroup.procs" pid=4155 comm="snap-confine" requested_mask="wc" denied_mask="wc" fsuid=0 ouid=0
[08:13] <pstolowski> zyga: yeah.. but temperatures revolving around 0C (only) were not expected
[08:13] <zyga> mborzecki: we have ... denials?
[08:13] <zyga> ah. wait, maybe I have two profiles
[08:13] <zyga> one left over from work
[08:13] <zyga> sigh
[08:16] <zyga> mborzecki: replied there, I think leap may be broken, TW is okay
[08:27] <zyga> I need a 2nd +1 for https://github.com/snapcore/snapd/pull/8033
[08:27] <mup> PR #8033: tests: switch mount-ns test to differential data set <Created by zyga> <https://github.com/snapcore/snapd/pull/8033>
[08:27] <zyga> I'd like to merge it before it drifts
[08:45] <pstolowski> mvo: how was last week? anything remarkable?
[08:45] <pstolowski> pedronis: morning!
[08:47] <pedronis> pstolowski: hi
[09:08] <mborzecki> it'd be so nice if systemd manpages indicated whic version of systemd given feature first appeared in
[09:19] <pedronis> pstolowski: I will look at the preseed PRs later today, I fixed some conflicts on the first on Friday.
[09:20] <pedronis> pstolowski: maybe you could finish reviewing #8036 ?
[09:20] <mup> PR #8036: snapstate: refactor things to add the re-refresh task last <Created by pedronis> <https://github.com/snapcore/snapd/pull/8036>
[09:20] <pstolowski> pedronis: sure. and thanks for updating preseed PR
[09:24] <mborzecki> hmm, so we have /lib/environment.d and /etc/profile/snapd.sh but environment for zsh user is still not getting updated
[09:35] <pedronis> mborzecki: hi, I can do a follow up about that name, if there's a preference
[09:36] <mborzecki> pedronis: nah, it's ok, not worth another spread run
[09:38] <mborzecki> zyga: do you recall whether it's possible to start a user session in the tests somehow?
[09:46] <zyga> re
[09:46] <zyga> mborzecki: I think it is
[09:46] <zyga> mborzecki: I've done something -ish- like that
[09:46] <zyga> mborzecki: well, I didn't start a full user session but I did start a dbus session bus
[09:46] <zyga> mborzecki: what I found out is that some PAM / distro / i-dont-know-what settings do start a user session for the test user
[09:46] <zyga> mborzecki: because we observed that it runs stuff and shuts down asynchronously
[09:47] <mborzecki> quick errand, back in 30 or so
[09:48] <zyga> lp timeouts
[09:48] <zyga> oh well
[09:48] <zyga> back to work
[09:50] <pedronis> pstolowski: thanks
[09:50] <mup> PR snapd#8036 closed: snapstate: refactor things to add the re-refresh task last <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8036>
[09:59] <mvo> pstolowski: last week was interesting, 2.43 a wee bit delayed but hopefully just 1 week
[10:11] <pstolowski> mvo: uhm, just browsed last-week standup notes (they are very useful to catch up btw!)
[10:11] <mvo> pstolowski: yeah, when at the sprint I had the same feeling, very useful
[10:13] <mup> PR snapd#8080 opened: dirs: manjaro-arm is like manjaro <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8080>
[10:14] <zyga> mvo: in case 2.43.x will happen ^
[10:15] <mvo> zyga: thank you
[10:28] <mborzecki> re
[10:49]  * zyga goes offline for 2-3 hours
[10:58] <mup> PR snapd#8081 opened: tests/main/user-session-env: add test verifying environment variables inside the user session <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8081>
[10:58] <mborzecki> simple test ^^
[11:17] <mborzecki> still, something is off with zsh as indicated in https://bugs.launchpad.net/ubuntu/+source/zsh/+bug/1640514
[11:17] <mup> Bug #1640514: /snap/bin is not added to the PATH when using zsh <patch> <Snappy:Fix Released> <snapd (Ubuntu):Confirmed> <zsh (Ubuntu):Invalid> <snapd (Ubuntu
[11:17] <mup> Xenial):Confirmed> <zsh (Ubuntu Xenial):Invalid> <snapd (Ubuntu Bionic):Fix Released> <zsh (Ubuntu Bionic):Invalid> <https://launchpad.net/bugs/1640514>
[11:39] <mborzecki> zyga: little tweak in #8080
[11:39] <mborzecki> cachio: hey, welcome back!
[11:39] <mup> PR #8080: dirs: manjaro-arm is like manjaro <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8080>
[11:41] <cachio> mborzecki, heu, thanks
[11:42] <cachio> mborzecki, trying to start again :)
[11:47] <pstolowski> cachio: hi! have you seen my earlier email re nested vm, and comments under #8046 ?
[11:47] <mup> PR #8046: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
[11:47] <cachio> pstolowski, no yet
[11:47] <cachio> pstolowski, hello :)
[11:48] <pstolowski> cachio: ah, you were on vacation as well!
[11:48] <cachio> pstolowski, yes :)
[11:49] <cachio> caching up emails, logs and other stuff yet
[11:49] <cachio> pstolowski, I'll take a look to the PR
[11:49] <cachio> today for sure
[11:50] <pstolowski> cachio: i'll deconflict it in a moment
[11:54] <mup> PR snapd#8082 opened: data, packaging: Add sudoers snippet to allow snaps to be run with sudo <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/8082>
[12:05] <mvo> cachio: hey, welcome back!
[12:05] <cachio> mvo
[12:05] <cachio> hello
[12:05] <mup> PR snapd#8033 closed: tests: switch mount-ns test to differential data set <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8033>
[12:05] <cachio> mvo, reading logs for 43.2
[12:06] <cachio> mvo, is .1 going to stable? or we should go with .2?
[12:07] <mvo> cachio: we will need .2 instead, it's already in beta
[12:08] <mvo> cachio: so once beta validation is done it can go into candidate
[12:08] <mvo> cachio: and then we can release to stable in 1 week
[12:08] <cachio> mvo, ok
[12:09] <cachio> mvo, i'll continue with the beta validation in that case
[12:10] <zyga> mborzecki: thank you!
[12:10] <zyga> cachio: welcome back :)
[12:10] <mvo> cachio: thank you!
[12:11] <cachio> zyga, hi
[12:19] <Eighth_Doctor> blergh
[12:19]  * Eighth_Doctor waves
[12:20] <Eighth_Doctor> it's been a while since I've had to send a patch snapd upstream :P
[12:20] <Eighth_Doctor> mvo: it's been a while :)
[12:22] <Eighth_Doctor> mvo, zyga: by the way, I'm surprised you guys haven't reaped the Ubuntu 14.04 packaging from git
[12:22] <zyga> Eighth_Doctor: it's still supported
[12:22] <Eighth_Doctor> don't tell me you guys are still building for Ubuntu 14.04?!
[12:22] <zyga> Eighth_Doctor: have you heard of ESM?
[12:22] <zyga> Eighth_Doctor: we may have to
[12:22] <Eighth_Doctor> blergh
[12:22] <zyga> https://ubuntu.com/esm
[12:23] <Eighth_Doctor> somebody better giving you a huge bag of money for that
[12:23] <zyga> "Security updates for 14.04 LTS until 2022"
[12:23] <Eighth_Doctor> ugh
[12:23] <zyga> Eighth_Doctor: it's free for personal use
[12:24] <Eighth_Doctor> I can see that, and that deeply concerns me :(
[12:24] <zyga> why?
[12:24] <Eighth_Doctor> disincentive for upgrading
[12:25] <zyga> Eighth_Doctor: it's enterprise stuff
[12:25] <zyga> you can upgrade when you are ready
[12:25] <zyga> Eighth_Doctor: I'm sure that using ESM and paying for it
[12:25] <Eighth_Doctor> yeah, yeah
[12:25] <zyga> Eighth_Doctor: versus using the update for free
[12:26] <zyga> Eighth_Doctor: is a good incentive
[12:26] <zyga> plus, it keeps developers employed :)
[12:26] <Eighth_Doctor> heh, sure
[12:26] <Eighth_Doctor> the only difference between RH/SUSE and this model is that there's a "the first hit is free" thing like Oracle does...
[12:27] <Eighth_Doctor> I just think it probably introduces a stronger disincentive when it's possible to get it for free
[12:27] <Eighth_Doctor> zyga: I don't have a problem with the ESM thing, just the fact it is available for free for personal use
[12:27] <zyga> ah
[12:27] <zyga> well
[12:28] <zyga> you can always pay :)
[12:28] <zyga> you get cool stuff
[12:28] <Eighth_Doctor> haha
[12:28] <Eighth_Doctor> I don't have bags of money
[12:28] <zyga> like kernel live patch
[12:28] <zyga> it's not expensive
[12:28] <Eighth_Doctor> the livepatch stuff is interesting though
[12:28] <ogra> and you get a discount because you met zyga in person ;)
[12:28]  * Eighth_Doctor still has his legacy KSplice free subscription for Fedora
[12:29] <Eighth_Doctor> haha
[12:29] <Eighth_Doctor> sadly, I know how the sausage is made for kernel livepatches
[12:29] <ogra> shhhh
[12:29] <Eighth_Doctor> I try very hard to avoid them if I can ;)
[12:30]  * Eighth_Doctor was once asked to make kernel livepatches using kpatch
[12:31] <Eighth_Doctor> zyga: if I could afford to, I'd buy subs from all my favorite Linux distro companies :)
[12:31] <zyga> Eighth_Doctor: if you want to support, $25 gives you desktop ESM license
[12:31] <Eighth_Doctor> nice
[12:31] <zyga> you get fips, livepatch, some other fancy acronyms
[12:31] <Eighth_Doctor> I'll consider it
[12:31] <zyga> probably desirable in corporate world
[12:31] <zyga> for somewhat more you get phone support
[12:32] <zyga> prices for servers and vms are different though
[12:32] <zyga> but yeah
[12:32] <zyga> you can just use it for free because it's pretty damn cool :)
[12:32] <zyga> and it's meant to be adopted by personal users
[12:32] <zyga> because that makes everyone safer
[12:32] <Eighth_Doctor> fair
[12:32] <Eighth_Doctor> zyga: if you guys offered Fedora support... :P
[12:33] <zyga> Eighth_Doctor: you can run it in a container :)
[12:33] <Eighth_Doctor> hah
[12:33] <Eighth_Doctor> I don't think I've run Ubuntu as my desktop OS since 2012
[12:33] <zyga> Eighth_Doctor: but I think if you want to start supporting fedora IBM will look at you with The Eye
[12:33] <Eighth_Doctor> actually, they're super weird about this
[12:33] <zyga> Eighth_Doctor: I heard 20.04 is looking like a sweet system :)
[12:33] <Eighth_Doctor> they want more people to commercially support Fedora
[12:33] <pedronis> pstolowski: answered your question in 7590
[12:34] <pstolowski> thx
[12:34] <Eighth_Doctor> but some folks give you the stink-eye when you do it for CentOS
[12:34] <zyga> Eighth_Doctor: are you ubuntu community member? you can get it on up to 50 machines for $0
[12:34] <Eighth_Doctor> what does that mean?
[12:34] <zyga> Eighth_Doctor: the fedora/centos/rhel split is still making me dizzy
[12:34] <Eighth_Doctor> I have an Ubuntu account on LP
[12:35] <Eighth_Doctor> zyga: it's going to get less confusing in the near future
[12:35] <zyga> Eighth_Doctor: fedora/rhel would be better, if you had a way to get no-cost unsupported rhel
[12:35] <zyga> abyway
[12:35]  * zyga needs to focus
[12:35] <Eighth_Doctor> fedora -> centos -> rhel
[12:35] <zyga> fedora -> rhel -> centos?
[12:35] <zyga> or more like
[12:35] <Eighth_Doctor> going forward, fedora will branch into centos, and centos will branch into rhel
[12:35] <zyga> fedora <-> rhel <-> centos <- to fedora ->
[12:35] <Eighth_Doctor> that's starting with CentOS 8
[12:35] <Eighth_Doctor> with the CentOS Stream
[12:36] <Eighth_Doctor> which is essentially what RHers will tell you is rhel-rawhide
[12:36] <Eighth_Doctor> so Fedora is where the cool shit happens, CentOS Stream is where it stabilizes, RHEL/CentOS Linux is the end state
[12:37] <Eighth_Doctor> over the next ~6 months, the RHEL development process is being flipped public as part of the CentOS Stream infrastructure bringup
[12:38] <Eighth_Doctor> zyga: on another note, looking at my LP account, I created it shortly after Ubuntu 5.10 (breezy badger) released
[12:38] <pstolowski> pedronis: right, ty, i forgot it's for core
[12:39] <Eighth_Doctor> zyga: it actually predates my FAS account and my openSUSE account by two years ;)
[12:39] <Eighth_Doctor> https://launchpad.net/~ngompa13
[12:43] <mborzecki> cachio: can you take a look whther centos-8 is avaialble in gcp already?
[12:44] <cachio> mborzecki, sure, let me check
[12:44] <mborzecki> ijohnson: hi, already around? :P
[12:45] <cachio> mborzecki, it is available now
[12:45] <mborzecki> cachio: great, would it be possible for you to add it to the project then?
[12:45] <cachio> do you weant a pr to enable it ??
[12:45] <cachio> mborzecki, sure
[12:45] <mborzecki> cachio: i can open a PR once you tell me the image name
[12:46]  * pstolowski lunch
[12:47] <cachio> mborzecki, try with centos-8
[12:47] <mborzecki> cachio: thx
[12:47] <cachio> mborzecki, but I would need to add it to our pool
[12:48] <cachio> mborzecki, but in the meantime you can use that one
[12:54] <mborzecki> cachio: yay, it works             - centos-7-64:
[12:54] <mborzecki>                 workers: 4
[12:54] <mborzecki>                 image: centos-7-64
[12:54] <mborzecki> PRETTY_NAME="CentOS Linux 8 (Core)"
[12:55] <cachio> mborzecki, centos 7?
[12:55] <mborzecki> cachio: nah, wrong paste ;)
[12:56] <mborzecki> cachio: see the PRETTY_PRINT=.. line
[12:58] <cachio> mborzecki, which is this PRETTY_NAME ?
[12:58] <cachio> mborzecki, where do you see it?
[12:59] <mborzecki> cachio: PRETTY_NAME="CentOS Linux 8 (Core)" <--
[13:00] <mup> PR snapd#8083 opened: spread: add CentOS 8 <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8083>
[13:05] <cachio> mborzecki, does not work for us that version?
[13:05] <ijohnson> mborzecki: not quite yet :-)
[13:06] <cachio> mborzecki, well you said that works
[13:06] <mborzecki> cachio: i was able to boot a node, so a good sign (?), let's how spread tests will fare
[13:06] <mborzecki> ijohnson: haha, sure will poke you in a bit
[13:07] <cachio> mborzecki, nice, the only change we are doing to centos is to set selinux as permissive
[13:49] <mup> PR snapcraft#2893 closed: [legacy] meta: include environment in hook wrappers <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2893>
[13:49] <ijohnson> morning folks
[13:49] <mup> PR snapd#8084 opened: many,randutil: centralize and streamline our random value generation <Created by pedronis> <https://github.com/snapcore/snapd/pull/8084>
[13:55] <pstolowski> hey ijohnson !
[13:55] <ijohnson> hey pstolowski did you have a good vacation ?
[13:57] <pstolowski> ijohnson: yep, thanks for asking!
[13:57] <ijohnson> nice, I saw your picture of the mountains with the snow, very beautiful :-) it actually got really warm here over the weekend and a bunch of our snow melted
[13:59] <pstolowski> ijohnson: https://drive.google.com/file/d/1g9I2qGgGfpgYCyLWCHbrXlVzRnrRR_tN/view?usp=sharing
[14:00] <pstolowski> zyga,mborzecki ^ morskie oko :)
[14:02] <zyga> mmm
[14:02] <zyga> I want holidays with snow
[14:03] <ijohnson> pstolowski: awesome, I'm jealous we don't have mountains nearby me :-)
[14:10] <Eighth_Doctor> mvo, mborzecki: I think this is officially a sign that snapd has too many tests
[14:10] <Eighth_Doctor> when the tests fail because it takes too long to run (!)
[14:12] <mvo> Eighth_Doctor: in a meeting right now, sorry, will get back to you
[14:14] <mborzecki> Eighth_Doctor: hmm probably snap downloads taking too long
[14:15] <mborzecki> happens from time to time
[14:26] <ogra> stgraber, so i tried to build a preseeded image with lxd ... which seems to work fine but then console-conf doesnt allow me to add a default user to the core image at all anymore, seems lxd created a user that console-conf now considers the images system user ... https://imgur.com/a/fqu7xrS
[14:29] <ogra> stgraber, how did you test your daemon.preseed change ?  i cant really verify it that way ...
[14:33] <ogra> (this is most likely a console-conf bug, to not ignore such users (i bet docker is the same here) i'm just wondering how you verified the poatch without being able to log into the image)
[14:34] <ogra> *patch
[14:35] <cachio> mborzecki, do you need permisive mode on centos-8?
[14:36] <mborzecki> cachio: yes, we'll probably need it because most tests are not taking care of the labeling properly
[14:36] <cachio> mb
[14:36] <cachio> mborzecki, ok
[14:38] <ogra> pedronis, see above .. if i add lxd to required-snaps in the model (which creates an lxd user in the extrausers db), console-conf doesnt offer me to create a default user ... i assume snapd now considers the image managed, yet it isnt ... would that be a snapd bug, a console-conf one or ... ?
[14:39]  * ogra isnt sure if console-conf queries for "managed" here 
[14:39] <ogra> (or if that is even the right conclusion)
[14:40] <zyga> I figured out why mi microphone was not working
[14:40] <zyga> I was playing with the wireless headphone charging case
[14:40] <zyga> and flipping it open pairs the devices
[14:40] <zyga> so I kept switching the microphone back and forth
[14:40] <zyga> and that apparently confused hangouts
[14:54] <mborzecki> hangouts gets confused quite easily
[15:04] <roadmr> it's so confused it isn't even called hangouts anymore 😆
[15:05]  * zyga goes to check on his son
[15:05] <zyga> Janek has fever and stayed at home today
[15:06] <roadmr> zyga: my sympathies and a bowl of warm soup - fever sucks
[15:21] <zyga> yeah, we just gave him some meds to reduce the fever as it's been too long (since 6AM)
[15:40] <mup> PR snapd#8085 opened: [RFC] netutil: add default gateway monitor <Created by mvo5> <https://github.com/snapcore/snapd/pull/8085>
[15:40] <zyga> mvo: looking
[15:45] <mborzecki> ijohnson: 8082 hit the timeout again?
[15:45] <ijohnson> mborzecki: uh yes
[15:46] <ijohnson> did you already restart it before ?
[15:46] <mborzecki> ijohnson: yeah :/
[15:46] <ijohnson> I've got a bad feeling about this :-(
[15:46] <mborzecki> ijohnson: let's see, maybe 3rd time's the charm :P
[15:47] <zyga> mvo: reviewed
[15:47] <ijohnson> mborzecki: fingers crossed
[15:48] <cachio> mborzecki, centos-8 is failing to install yum install system-lsb-core
[15:49] <cachio> mborzecki, perhaps we could install redhat-lsb-core instead
[15:50] <zyga> mvo: do you have an LTE modem?
[15:50] <zyga> mvo: I think it would be great to test it on one
[15:50] <zyga> mvo: if you need I can test it locally with mine
[15:54]  * cachio lunch
[16:13] <mvo> zyga: I have one, haven't used it in a while, can do the test in a wee bit
[16:30] <zyga> back from lunch
[16:33] <zyga> mvo: cool, let me know if you want assistance, I can help as well
[16:56] <mup> PR snapd#8072 closed: daemon, store: better expose single action errors <Created by chipaca> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8072>
[17:02] <ijohnson> mmm I've got a really bad feeling about these tests that depend on the store
[17:03] <zyga> ijohnson: <chewie roar>
[17:04] <ijohnson> :-)
[17:39]  * zyga takes a coffee break
[17:53] <ijohnson> anybody have an idea why all of a sudden LP jobs can't git clone snapd ? https://pastebin.ubuntu.com/p/CDJG8DVyPV/
[17:54] <ijohnson> hmm I guess I can't clone the master branch in LP either
[17:59] <cjwatson> yes git.launchpad.net is down, see #is
[17:59] <cjwatson> ijohnson: ^-
[17:59] <ijohnson> cjwatson: ah thanks
[17:59] <cjwatson> (BTW I only see stuff here by chance - if you want LP staff to see stuff it's more reliable to ask in LP channels)
[18:00] <ijohnson> cjwatson: I checked is-outage and didn't see anything about it in the topic, perhaps #is is a better place to check
[18:00] <cjwatson> #is-outage isn't a place where customers of IS are supposed to report things, normally
[18:00] <cjwatson> so I don't :)
[18:01] <ijohnson> cjwatson: fair enough :-) also did you mean the internal launchpad channel or freenode one?
[18:01] <cjwatson> Either
[18:01] <cjwatson> #launchpad-ops on irc.c.c, #launchpad on freenode
[18:02] <cjwatson> Anyway, should be fixed soonish
[18:02] <ijohnson> great, thanks
[18:43] <mup> PR snapd#8082 closed: data, packaging: Add sudoers snippet to allow snaps to be run with sudo <Created by Conan-Kudo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8082>
[19:51] <pedronis> ijohnson: I did another pass on 8077
[19:53] <ijohnson> pedronis: thanks responding now
[20:00] <pedronis> ijohnson: I'm not sure whether revisions should error on incosistent trySnap vs status
[20:00] <pedronis> in general we should try not to get stuck
[20:01] <ijohnson> I guess it would be a question of where we would get stuck
[20:01] <pedronis> ijohnson: if we are trying or try but there's no try kernel
[20:02] <pedronis> I suppose we behave like status is just = ""
[20:02] <pedronis> we should clean it up
[20:02] <ijohnson> we would get stuck in InUse, and GetCurrentBoot it seems
[20:02] <pedronis> yea
[20:02] <pedronis> so no upgrades
[20:02] <pedronis> we should probably not error
[20:02] <ijohnson> I think cleaning up in GetCurrentBoot makes sense, but not so sure about InUse, seems odd if InUse auto-cleans things
[20:02] <pedronis> but make it a task for mark successful
[20:02] <pedronis> to clean it up
[20:02] <pedronis> ijohnson: well we always do a mark sucessful pass
[20:02] <pedronis> before doing other things
[20:03] <pedronis> it's run early in snapd
[20:03] <ijohnson> hmm
[20:03] <ijohnson> that would make sense
[20:03] <ijohnson> just to clarify, when you say "make it a task for mark successful" you don't mean an actual manager task right? just that mark successful should clean up ?
[20:03] <pedronis> yes
[20:03] <ijohnson> ok
[20:04] <pedronis> I think it has code already in that direction
[20:04] <pedronis> but in uc20
[20:04] <pedronis> we have links and status
[20:04] <pedronis> that are not quite in the same spot
[20:04] <pedronis> maybe the code is already there
[20:04] <pedronis> just a matter of having a test
[20:05] <ijohnson> I'll have a look at that as well
[20:05] <ijohnson> if you were curious I did go ahead and implement setting kernels in modeenv in bootstate20 quickly and this is the result: https://github.com/anonymouse64/snapd/commit/de7f8fe36cb83da51a400b05100dd37a1b19246f
[20:05] <ijohnson> it would be quite a bit less changes to the tests if we did it in coreKernel, but it's up to you
[20:06] <pedronis> that code seems to load modeenv twice for mark succeful?
[20:07] <pedronis> it's also not dropping them
[20:08] <ijohnson> pedronis: I don't think it's loading it twice
[20:08] <pedronis> anyway is probably best to get 8077 in first
[20:08] <ijohnson> pedronis: also yes that's my big question about when to drop them
[20:08] <ijohnson> we don't want to drop them in markSuccessful
[20:08] <pedronis> why not?
[20:08] <pedronis> ah because of possible undos?
[20:08] <ijohnson> because then the modeenv won't trust the kernel snap if we reboot?
[20:09] <ijohnson> yes undos basically
[20:10] <pedronis> but we never boot anything but the kernel or the try-kernel
[20:10] <pedronis> by definition
[20:11] <ijohnson> hmm I guess if we did an undo/revert then setNext() would still be called on the one we are reverting to
[20:11] <pedronis> so I think it's less complicated than we think
[20:11] <pedronis> but anyway we need to get 8077 right first
[20:12] <ijohnson> mmm yes I think you're right I was thinking we would need to be able to rollback further than what is in kernel.efi, but that isn't necessary actually
[20:12] <ijohnson> re 8077 yes I am refactoring that now
[20:15]  * cachio afk
[20:18] <sdhd-sascha> big, big thank you, to jhenstridge ... really great to build snap's on github now:
[20:18] <sdhd-sascha> https://github.com/sd-hd/termite-snap/runs/423070604
[20:18] <sdhd-sascha> Next, i hope we can "snap" some wayland-desktop ;-)
[20:19] <pedronis> mmh, the shellcheck version we use in travis is slightly old and seems to get confused about grep --exlude
[20:20] <ijohnson> do we not use shellcheck as a snap ?
[20:22] <pedronis> no, seems we use a package
[22:05] <mup> PR snapcraft#2901 closed: python plugin: do not leak snapcraft's site-packages <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2901>
[22:12] <sergiusens> ijohnson: fwiw, we have been using the snap for over a year
[22:14] <ijohnson> sergiusens: nice yes that what I use on my dev machine is the snap, probably safe enough to switch spread over to use the snap
[22:18] <pedronis> ijohnson: thanks for the changes, seem the suggestion made sense,  I made a couple more comments to maybe clean up some things a little bit more
[22:19] <ijohnson> pedronis ok looking now
[22:20]  * cachio eod
[22:35] <pedronis> ijohnson: going to call it a day
[22:36] <ijohnson> pedronis yes probably a good idea considering the time :-)