[00:08] <mup> PR snapcraft#2897 opened: meta: include environment in hook wrappers <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2897>
[00:14] <mup> PR snapcraft#2893 closed: [legacy] meta: include environment in hook wrappers <Created by kyrofa> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2893>
[01:17] <mup> PR snapcraft#2898 opened: meta: remove dead code from snap packaging <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2898>
[06:01] <mborzecki> morning
[06:03] <mvo> hey mborzecki ! good morning
[06:04] <mborzecki> mvo: hey!
[06:04] <mup> PR snapd#8049 closed: tests: fix revisions leaking from snapd-refresh test <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8049>
[06:19] <mup> PR snapd#8032 closed: boot, cmd/snap, cmd/snap-bootstrap: move run mode and system label detection to boot <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8032>
[06:23] <mup> PR snapd#8040 closed: gadget: skip update when raw structure content is unchanged <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8040>
[06:48] <mup> PR snapd#7993 closed: devicestate: enable encryption based on model grade <UC20> <Created by cmatsuoka> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7993>
[07:26] <zyga> Hey guys
[07:27] <zyga> I’m going to check my wrist
[07:27] <zyga> I have a visit at 9:30
[07:27] <zyga> I’ll be back later
[07:36] <mvo> zyga: good luck
[07:38] <mborzecki> zyga: hey
[07:49] <mborzecki> btw. played a little with gnome-builder yesterday, it'd be nice to have some snap integration there, looks like it supports building flatpaks ootb
[07:57] <jamesh> mborzecki: I did some work on that ages ago.  I set it aside, as I couldn't get things to work the way upstream wanted without changes to Snapcraft, and couldn't get buy-in to get those Snapcraft features done.
[08:00] <mborzecki> jamesh: interesting, thanks for the insight!
[08:01] <jamesh> mborzecki: my patch essentially introduced "Snapcraft" as a new build system.  What they wanted was to keep the underlying build system visible (i.e. automake, meson, etc), and allow Builder to invoke it
[08:03] <jamesh> The idea is that build system plugins could support operations like "add newfile.c to library X", and they would update the appropriate makefile or equivalent
[08:05] <jamesh> you also want to be able to determine compile flags for each source file in order to properly parse them for completion
[08:05] <jamesh> so if Snapcraft was build system, it would need to reimplement all of this for each of its supported build systems
[08:06] <mborzecki> jamesh: yeah, makes sense when you're working on your piece of software and snapcraft is really just a packaging method
[08:07] <mborzecki> jamesh: btw. have you worked with builtstream too?
[08:09] <jamesh> mborzecki: IIRC, the Flatpak plugin adds an early build step to download dependencies, and provides the appropriate environment to run the underlying build system.  There's also an extra step at the end to package up the result
[08:09] <jamesh> There is the risk that this could produce different results to a standard build, but it means you have incremental builds and all the IDE features
[08:09] <jamesh> I haven't looked at Buildstream
[08:23] <mup> PR snapd#8054 opened: snap: add `snap pack --compression=<comp>` options <Performance 🚀> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8054>
[09:05] <Chipaca> mo'in, all
[09:07] <mvo> hey Chipaca and pedronis ! good morning
[09:07] <pedronis> hi
[09:07] <Chipaca> mvo: had an adequate amount of rest? :-)
[09:09] <Chipaca> pedronis: I set up a short meeting to go over some things about manpages, either to clear the path for me to push a PR with it this week, or to spread the knowledge around of what needs doing later
[09:09] <pedronis> Chipaca: yes, saw it
[09:10] <Chipaca> mvo: pedronis: it just struck me that postUserCreateData's ForceManaged flag might be deprecated as well, I'm not clear what the use case was for it (ie should I leave it behind in the to-be-deprecated endpoint or carry it forwards as is currently done)
[09:11] <pedronis> Chipaca: it's a bit of an orthogonal concern, I think we do want to carry it forward
[09:11] <pedronis> even it's hopefully low usage
[09:12] <Chipaca> k
[09:14] <mvo> Chipaca: people seems to use the flag to create additional users on devices which seems to be a valid use-case. the name is a bit confusing though :/
[09:14] <mvo> Chipaca: thanks for setting up that meeting
[09:14] <Chipaca> mvo: should I add you to it? so far it's me, zyga, pedronis
[09:15] <Chipaca> mvo: working on the assumption that you don't love meetings _that_ much :-p
[09:16] <mvo> Chipaca: I'm fine not being part of it
[09:31] <zyga> I’ll be back soon
[09:31] <zyga> Hey pedronis, welcome back :-)
[09:31] <mborzecki> Chipaca: pedronis: hey
[09:32] <zyga> Hey mborzecki :-)
[09:33] <pedronis> mvo: zyga: shouldn't the disabling in 5512861442cbf containt TODO:UC20 ?
[09:35] <zyga> If that is the patch I think it is there was a follow up that adds the todo core 20 marker
[09:36] <zyga> (I’m still afk for a short while)
[09:38] <pedronis> mborzecki: in the doc comment for ModeAndRecoverySystemFromKernelCommandLine "returns the current run mode", I think we need to s/run/operating/
[09:39] <mvo> pedronis: I had the same comment about the todo:uc20 and it was added in pr 8050
[09:39] <mup> PR #8050: tests: add marker tag for core 20 test failure <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8050>
[09:39] <pedronis> ah ok
[09:39] <pedronis> good
[09:41] <mborzecki> pedronis: ack
[09:45] <mup> PR snapd#8055 opened: boot: tweak kernel cmdline helper docstring <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8055>
[09:45] <mborzecki> hm, it'd be cool if we could indicate that full spread run is unnecessary for PRs like that
[09:57] <pedronis> mborzecki: maybe there's a way to read via the api if a given label is applied to the PR
[09:59] <mborzecki> pedronis: that or just scrape the page, like we did with the PR title, as the API had limitations and required api key
[10:03] <mup> PR snapd#8056 opened: client: move user-related things to their own files <Simple 😃> <Created by chipaca> <https://github.com/snapcore/snapd/pull/8056>
[10:06] <Chipaca> mborzecki: pedronis: FWIW, https://gist.github.com/chipaca/911a8a4905b091c10caa9854bf7ea4b4 looks at labels on PRs
[10:06] <Chipaca> they're reasonably straightforward to get
[10:06] <Chipaca> (but yes without an api key we'd hit rate limits very fast)
[10:10] <pedronis> mvo: did you see this: https://forum.snapcraft.io/t/auto-import-assert-fails/15181
[10:11] <mvo> pedronis: have not seen it, will followup
[11:13] <zyga> brb
[11:27] <mup> PR snapd#8057 opened: overlord/auth: add RemoveUserByName <Simple 😃> <Created by chipaca> <https://github.com/snapcore/snapd/pull/8057>
[11:32] <zyga> Chipaca: reviewed
[11:32] <popey> Hm, anyone built an image with series:: "18"? ubuntu-image doesn't seem to like it
[11:32] <popey> https://tutorials.ubuntu.com/tutorial/create-your-own-core-image
[11:33] <zyga> popey: series 18 is not a thing
[11:33] <zyga> series is always 16
[11:33] <popey> oh
[11:33] <zyga> popey: and hi :)
[11:33] <popey> thats odd :)
[11:33] <Chipaca> popey: series is the restart-the-world generation switch
[11:34] <Chipaca> popey: if we change the series it's because we're starting over
[11:34] <zyga> we should have called it multiverse
[11:34] <Chipaca> popey: as in, nothing from series X works on series Y
[11:34] <Chipaca> popey: granted in retrospect we should've made it more internal-only, but we hadn't learned how to make things co-habitate back then
[11:34] <Chipaca> we thought we'd have to bump the series every lts
[11:34] <Chipaca> or something like that
[12:05] <popey> Is it possible to seed something to stop me having to do the U1 SSO dance on first boot of a core device?
[12:07] <mup> PR snapd#8058 opened: run-checks, travis: allow skippng spread jobs by adding a label <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8058>
[12:10] <mborzecki> anyone remember when cachio is coming back?
[12:10] <zyga> next week
[12:10] <mborzecki> ah, ok
[12:13] <zyga> focal with zfs
[12:13] <zyga> oh mhy
[12:14] <mup> PR snapd#8053 closed: osutil: implement deluser <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/8053>
[12:16] <mborzecki> zyga: is the oracle police already banging at your door trying to extort a fee? :)
[12:16] <mup> PR snapd#8055 closed: boot: tweak kernel cmdline helper docstring <Simple 😃> <Created by bboozzoo> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8055>
[12:18] <zyga> popey: you might know - nvidia experimental drivers for ubuntu?
[12:18] <zyga> popey: how do I get some
[12:19] <mup> PR snapd#8056 closed: client: move user-related things to their own files <Simple 😃> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8056>
[12:20] <popey> Possibly https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa  zyga
[12:26] <zyga> popey: thank you! :)
[12:31] <Chipaca> hmm, shouldn't ubuntu-20.04 no longer be unstable?
[12:35] <mup> PR snapd#8057 closed: overlord/auth: add RemoveUserByName <Simple 😃> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/8057>
[12:36] <mup> PR snapd#8059 opened: daemon: implement user removal <Created by chipaca> <https://github.com/snapcore/snapd/pull/8059>
[12:36]  * Chipaca goes out for a while
[13:03] <zyga> brb
[13:03] <zyga> need to make tea for Iza
[13:08] <mup> PR snapd#8060 opened: gadget: skip update when mounted filesystem content is identical <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8060>
[13:11] <mborzecki> off to pick up the kids from school
[13:44] <mborzecki> re
[13:44] <zyga> o/
[14:16] <zyga> ijohnson: without the window reflection https://twitter.com/zygoon/status/1177917609783808001/photo/1
[14:32] <ijohnson> zyga: very nice, it's so cleanly organized
[14:32] <ijohnson> my desktop has cables running everywhere and looks very messy generally
[14:34] <Chipaca> zyga: https://i.redd.it/4c9udy915qyy.jpg
[14:35] <mborzecki> ijohnson: had to address a similar problem, otherwise my vega 56 would run really hot (still runs quite warm under load, but UV keeps the temps in check)
[14:35] <Chipaca> zyga: (via https://www.reddit.com/r/cablefail/comments/6ccwaq/looked_tidy_until_the_side_fell_off_in_the_wind/ )
[14:35] <zyga> Chipaca: just add fire :D
[14:36] <ijohnson> Chipaca: how did you get a picture of the inside of my desktop ?!?! :-)
[14:36] <zyga> ijohnson: the other PC is also pretty tidy but not to that level
[14:36] <Chipaca> ijohnson: i had to resverse the polarity on your webcam, and the rest was easy
[14:37] <Chipaca> reverse*
[14:37] <Chipaca> tachion flux*
[14:37] <ijohnson> Chipaca: ah I knew I shouldn't have installed that 1.21 gigawatts power generator on my webcam
[14:38] <zyga> https://twitter.com/zygoon/status/1222166974802878464 :)
[14:38] <zyga> ugly cables going everywhere
[14:41] <ijohnson> https://usercontent.irccloud-cdn.com/file/MVvajfu5/IMG_20200128_083935.jpg
[14:42] <ijohnson> zyga: do you have a noctua cpu cooler on that? looks very similar to mine
[14:42] <zyga> with that carpet you could get great results buy just having feet and a dust filter
[14:42] <zyga> yeah
[14:42] <zyga> it's a 10+ year old PC
[14:42] <zyga> with a new case
[14:42] <zyga> 1st gen core i7
[14:43] <zyga> for the xmas refresh I will get a mobo/ram/gpu and go with something newer
[14:43] <zyga> but keep the outside the same
[14:43] <ijohnson> yeah mine could do better, but it works well enough, just need to blow out the dust every once and a while
[14:44] <ijohnson> there's a big fan on the top and on the side panel that aren't in the picture that keep the whole system quite cool
[14:44] <zyga> yeah, cooling in PCs is really hard to get wrong :)
[14:44] <zyga> lots of space
[14:45] <ijohnson> I wanted to do a water cooled system but I was a bit lazy
[14:48] <ijohnson> pedronis: do you have a minute to chat about snap-bootstrap re-execing into the snapd snap on first-boot? I agree that it is complicated but I think it would be very good to have
[14:48] <ijohnson> pedronis: I tried to make it work quickly, the most difficult thing I ran into was picking which snapd snap to mount snap-bootstrap from
[14:49] <zyga> degville: you didn't tell me you are making the corsair link snap!
[14:51] <degville> zyga: aha, yeah. I use it personally. I think there may be a permission issue I've not sorted out with the one I've pushed though, so it's not made it to stable (I've not looked at it in a while).
[14:51] <degville> zyga: I use it set my own fan profile for silent operation :)
[14:56] <zyga> degville: what are you controlling with it?
[14:56] <zyga> degville: the PSU?
[14:58] <degville> zyga: HX750i PSU and H100i GT v2 CPU water cooler.
[14:58] <zyga> mmm
[14:58] <zyga> I have the fan controller only
[14:59] <zyga> actually, no fan and RGB controller
[14:59] <zyga> and fan controller has more rgb and temp
[15:01] <degville> zyga: it does use a poorly documented syntax. I don't set the RGB (my box is under the table), but the syntax for my cooling profile is --device 1 --fan channel=1,mode=6,temps=0:35:45:50:55:60,speeds=0:0:55:60:75:100.
[15:22] <pedronis> ijohnson: that's why it's hard, we would need to put a snapd copy into ubuntu-boot
[15:22] <pedronis> with all that entails in terms of state and checks
[15:22] <ijohnson> pedronis: oh also I just realized that in the fde case ubuntu-data is encrypted too
[15:22] <pedronis> ijohnson: yes, ubuntu-data is encrypted
[15:23] <ijohnson> pedronis: okay I see why you would want snapd in ubuntu-boot too
[15:23] <ijohnson> pedronis: maybe this is too much, but maybe for the snapd snap specifically we could have a "extract snapd assets" function which would copy things like snap-bootstrap to ubuntu-boot when a snapd snap is installed?
[15:24] <pedronis> ijohnson: how do we check that that binary is good
[15:24] <pedronis> we don't sign single binaries that way
[15:25] <pedronis> ijohnson: I understand the appeal, I don't see a way to keep the complexity cost vs benefit under control
[15:25] <ijohnson> pedronis: hmm I suppose currently snap-bootstrap is part of the initramfs which is part of the kernel.efi and so thus is measured, but if it was just ran directly then it wouldn't be measured
[15:27] <ijohnson> yeah I guess I don't see a way to easily do it then without possibly waiting to re-exec until after ubuntu-data is decrypted perhaps, but that kind of defeats the purpose
[15:32] <pedronis> ijohnson: it needs to get stable and stay relatively simple
[15:32] <ijohnson> pedronis: yes another thing I just thought about is perhaps for our tests, we could re-build the initramfs for spread tests that way we can test changes in the PR without needing to wait for a new kernel snap?
[15:33] <pedronis> ijohnson: that should be possible in some way
[15:33] <pedronis> mvo: ^  thoughts on on that?
[15:33] <pedronis> patching initramfs in tests
[15:33] <zyga> pedronis: initramfs may need to be signed - is that a problem?
[15:33]  * zyga needs a coffee
[15:34] <pedronis> zyga: well , we'll special certs that we use in tests
[15:34] <ijohnson> zyga: not a problem for tests
[15:34] <pedronis> so that's should be the main problem for tests
[15:34] <pedronis> shouldn't be
[15:34] <zyga> in that case it feels okay
[15:34] <zyga> just like rebuilding core/snapd snaps
[15:34] <ijohnson> well it would be a problem if we do try to test FDE via spread
[15:35] <ijohnson> but I think we have other, related problems with testing that anyways
[15:35] <pedronis> ijohnson: we actually discussed some to have some kind unpack/repack mechanism for it
[15:35] <pedronis> not sure there was progress on that
[15:35] <ijohnson> yes I remember mvo mentioning that in SU a few weeks/months ago
[15:37]  * zyga goes upstairs for a while
[15:37] <ijohnson> well I think it's a reasonable suggestion so I'm gonna prototype out building a kernel snap for uc20 in the spread test with the right initramfs
[15:41] <Chipaca> raaahhh
[15:41]  * Chipaca rages a little
[15:41] <Chipaca> why do we have an endpoint that returns things or lists of things depending on the phase of the moon
[15:42]  * Chipaca spends a PR to fix it
[15:49] <pedronis> Chipaca: which one?
[15:49] <Chipaca> pedronis: /v2/create-user
[15:49] <pedronis> I wasn't aware of that
[15:49] <Chipaca> yeah
[15:50] <Chipaca> pedronis: it's got two modes, create a user, or create all known users
[15:50] <pedronis> ah
[15:50] <Chipaca> pedronis: so i'm changing users to return a list always, and hacking create-users to preserve behaviour
[15:50] <pedronis> Chipaca: +1
[15:51] <Chipaca> i'll also change remove from returning true to returning nil as the result, for the same reason
[15:52] <Chipaca> pedronis: at some later point you might want to consider login also being an action on users
[16:15] <mvo> ijohnson, pedronis rebuilding the initramfs sounds appealing to me. if it's not too much hassle I would love to have this. we have snakeoil signing keys so we can even make this work in the tpm case (sorry for the slow reply, was in a ad-hoc meeting)
[16:17] <ijohnson> mvo: ack I'll work on this then, not entirely sure how to use the snake oil keys for tpm, but I can just do the non-fde case right now easily enough
[16:18] <mvo> ijohnson: yeah, one step at a time :)
[16:18] <ijohnson> :-)
[16:20] <mup> PR snapd#8061 opened: daemon: make users result more consistent <Created by chipaca> <https://github.com/snapcore/snapd/pull/8061>
[16:21] <Chipaca> much nicer now :)
[16:47] <mvo> zyga: the release/2.43 is a bit of a nightmare because of all the conflicts in "mount-ns" PER-SNAP-* files. any hints for me, it looks like this changed quite a bit between 2.43 and master and the revert of the /writable view that needs to be undone in the merge again makes this all a bit messy
[16:51] <mvo> zyga: nevermind, I will just revert manually
[16:53] <zyga> mvo: hmm
[16:53] <zyga> mvo: re
[16:54] <zyga> mvo: I'm confused - I merged the 2.43 revert
[16:54] <zyga> mvo: in master it's good and we should not bring that patch to master
[16:55] <mvo> zyga: yes, that's my point :) but we merge the release/* branches into master so that was a bit of pain
[16:55] <mvo> zyga: it's all fine again
[16:55] <zyga> resolve with --theirs or --ours or whatever was the option
[16:55] <zyga> (don't take changes to that directory)
[16:55] <mup> PR snapd#8062 opened: release: 2.43.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8062>
[16:56] <zyga> or just cp it back from master :)
[16:56] <zyga> mvo: thank you for doing this; I'm sorry for the annoying merge
[16:56] <mvo> zyga: no worries
[16:56] <zyga> and that I didn't respond faster, I was having dinner
[16:56] <mvo> zyga: also no worries :)
[16:56] <zyga> there's a changelog conflict
[16:56] <mvo> zyga: oh, silly me
[16:57] <zyga> resolved
[16:57] <mvo> zyga: thank you!
[17:01] <Chipaca> current status of user work is https://github.com/snapcore/snapd/compare/master...chipaca:client-deluser … one more commit to go (in cmd/snap!) and it's Done(tm)
[17:01] <Chipaca> (if it all comes together without needing to go back and tweak things I'll be giving myself a putty medal)
[17:02] <Chipaca> now going to take a break
[17:02] <mvo> Chipaca: nice!
[17:03] <Chipaca> mvo: each of those commits becomes a PR, but I don't want to push them stacked (although i did do that for the last one)
[17:03] <Chipaca> actually, i lie, the first two commits are a PR, the others are a pr each
[17:03] <Chipaca> anyway, break time
[17:19] <Chipaca> travis is all kinds of sad
[17:20] <Chipaca> lots of 503s from the store
[17:20] <noise][> yeah, we are troubleshooting CDN issues
[17:20]  * Chipaca hugs noise][ 
[17:47] <Chipaca> hmm, hmm, hm
[17:47]  * Chipaca broke things
[17:47]  * Chipaca fixes things
[20:27] <mup> PR snapd#8062 closed: release: 2.43.2 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8062>
[20:29] <mup> PR snapcraft#2893 opened: [legacy] meta: include environment in hook wrappers <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2893>
[20:29] <mup> PR snapcraft#2899 opened: ci: publish the CI built snap to the Snap Store <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2899>
[20:31] <Chipaca> chipaca@jan282010-194967:~$ sudo snap remove-user chipaca
[20:31] <Chipaca> error: cannot delete user "chipaca": userdel: user chipaca is currently used by process 4865
[20:31]  * Chipaca counts that as winning
[20:49] <zyga> Chipaca: woot
[20:53]  * zyga installs a round of mac updates
[22:48] <mup> PR snapd#8063 opened: Remove users [DRAFT] <Created by chipaca> <https://github.com/snapcore/snapd/pull/8063>