[00:34] <mup> Bug #1878307 opened: Consider replacing math/rand with crypto/rand in snapd <crypto> <go> <snapd> <Snappy:New> <https://launchpad.net/bugs/1878307>
[00:44] <mup> PR snapcraft#3119 closed: elf: fix string format for debug log <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3119>
[01:29] <mup> PR snapcraft#3120 opened: spread: only run in LXD with the google/multipass provider for repo <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3120>
[05:15] <mborzecki> morning
[05:59] <pedronis> mborzecki: hi, I have a question in https://github.com/snapcore/snapd/pull/8647
[05:59] <mup> PR #8647: cmd/snap-bootstrap: tweak recovery trigger log messages <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8647>
[06:09] <mborzecki> pedronis: hi, let me see
[06:12] <mborzecki> pedronis: those are log messages
[06:19] <pedronis> mborzecki: ok, because Ian suggestion sounded instruction like, I suppose it works for a log too but got me confused
[06:27] <mup> PR snapd#8647 closed: cmd/snap-bootstrap: tweak recovery trigger log messages <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8647>
[06:39] <pedronis> #8649 needs review (it's relatively short)
[06:39] <mup> PR #8649: usersession,tests: clean ups for userd/settings.go and move xdgopenproxy under usersession <Created by pedronis> <https://github.com/snapcore/snapd/pull/8649>
[06:55] <mborzecki> mvo: hey
[06:57] <mvo> mborzecki: good morning
[06:58] <mup> PR snapd#7728 closed: cmd: implement snap run --explain <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7728>
[06:58] <pedronis> mvo: hi
[06:59] <mvo> hey pedronis ! good morning
[07:00] <mvo> 8652 needs a second review, pretty simple fwiw
[07:03] <pedronis> mvo: could you land #8653 (it's a follow up to a previous review), it failed on user services issues. You can look at it/tests, it's all renames really.
[07:03] <mup> PR #8653: asserts: make clearer that with label we mean a serialized label <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8653>
[07:03] <mvo> pedronis: sure
[07:04] <mup> PR snapd#8653 closed: asserts: make clearer that with label we mean a serialized label <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8653>
[07:04] <mvo> pedronis: yeah, just looked at it, this could have been done with skip-skpead even
[07:04] <mvo> pedronis: anyway, merged :)
[07:06] <pedronis> mvo: thanks
[07:11] <zyga> good morning
[07:13] <mborzecki> zyga: hey
[07:14] <mvo> good morning zyga
[07:15] <pstolowski> morning
[07:16] <mborzecki> and good morning pstolowski
[07:20] <mvo> hey pstolowski
[07:21] <pedronis> zyga: hi, #8655 failed differently, it seems the fix as is, is too blunt
[07:21] <mup> PR #8655: tests: remove generated session-agent units <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8655>
[07:22] <zyga> I noticed, I think I know why
[07:23] <zyga> My fix was tailored for core 16 and not generic enough
[07:27] <zyga> I will have to check
[07:29] <pedronis> mborzecki: thanks for the reviews, fwiw I pushed this: https://github.com/snapcore/snapd/pull/8649/commits/a98339435069517eb7a2997d4802bf926bc322b7
[07:29] <mup> PR #8649: usersession,tests: clean ups for userd/settings.go and move xdgopenproxy under usersession <Created by pedronis> <https://github.com/snapcore/snapd/pull/8649>
[07:29] <mborzecki> pedronis: thanks!
[07:31] <zyga> I send a follow up
[07:31] <pedronis> pstolowski: hi, did you see Dimitri email?  afaict we check for /dev/mem as landmark, do you remember why we need /dev in general ?
[07:32] <zyga> the problem was that snapd-failover test runs on all systems but only core16 needs the workaround
[07:32] <zyga> classic systems gain the extra services via snapd.{deb,rpm}
[07:32] <zyga> core systems, apart from core16, have snapd snap used in general and the services do not need to be removed
[07:32] <zyga> only core16 is special here
[07:32] <zyga> let's see if it passes
[07:33] <zyga> pedronis: I also noticed I need to update the permissions for core20 - the test user does not have journal access there
[07:33] <zyga> that is a different path so needs special treatment (test user setup on core20)
[07:34] <pstolowski> pedronis: hi, i've read it just now
[07:37] <pstolowski> pedronis: right, i'm checking dev/mem among few other things in snap-preseed. i don't remember why anymore, need to run without it to see. i suppose something was failing somewhere, i think there was a reason i added it. will check in a moment
[07:38] <pedronis> pstolowski: thank you
[07:45]  * zyga found the missing core20 test user setup 
[07:58] <mup> PR snapd#8660 opened: tests: test user belongs to systemd-journald, on core20 <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8660>
[07:58] <mborzecki> zyga: some comments under https://github.com/snapcore/snapd/pull/8656
[07:58] <mup> PR #8656: snap-mgmt: perform cleanup of user services <Created by zyga> <https://github.com/snapcore/snapd/pull/8656>
[08:00] <zyga> thanks!
[08:00] <zyga> good ideas indeed
[08:29]  * zyga eagerly checks if https://github.com/snapcore/snapd/pull/8655 is green now
[08:29] <mup> PR #8655: tests: remove generated session-agent units <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8655>
[08:33] <zyga> mborzecki: we don't support user-level timers, do we?
[08:35] <mborzecki> zyga: hm looking at the code, seems like we do
[08:35] <mborzecki> zyga: and not sure we have a spread test for it either
[08:36] <zyga> Ah, I understand now
[08:36] <zyga> Timers bind to apps
[08:37] <zyga> And apps have scope
[08:45] <mup> PR snapd#8658 closed: cmd/snap-bootstrap/initramfs-mounts: cosmetic changes in prep for future work <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8658>
[08:52] <jamesh> zyga: could I trouble you to do another merge for one of the snappy-hub test-snapd-* branches? https://code.launchpad.net/~jamesh/snappy-hub/test-snapd-dbus-service/+merge/383854
[09:10] <zyga> jamesh: hey
[09:10] <jamesh> hi
[09:10] <zyga> sure, in a moment
[09:11] <zyga> jamesh: done
[09:17] <jamesh> zyga: thanks!
[09:50] <clmsy> hi everyone
[09:50] <clmsy> im in need of some help
[09:50] <clmsy> im trying to build an image using the ubuntu-image tool, i get this error ubuntu_image.parser.GadgetSpecificationError: `role: system-data` structure must have an implicit label, or 'writable': flasher
[09:50] <clmsy> ill show you the part related in gadget.yaml
[09:52] <clmsy> https://pastebin.com/ee2zXpjC
[09:52] <clmsy> are we not allowed to try rename the writable partition ?
[09:55] <ogra> clmsy, nope, while this might be different in core20 images, until core18 the existence of a "writable" labeled partition is essential
[09:56] <ogra> you can add additional ones as you like but there must be one called "writable" that carries the writable bits of the OS
[09:57] <ogra> oh, and looking at your paste you seem to define two targets for the same thing ... i dount that can work
[09:58] <ogra> ... and your target: entry is also not properly indented
[09:59] <clmsy> it was i think pastebin related
[09:59] <clmsy> the original file is properly indented
[09:59] <clmsy> hmm
[09:59] <ogra> is it ?
[09:59] <ogra> (tabs vs spaces ?)
[10:00] <ogra> the paste show the other indents just fine
[10:00] <ogra> *shows
[10:00] <clmsy> yes it broke when i pasted there and i just hand changed it quickly to look ok :)
[10:00] <clmsy> yeah i understand the issue, so im not allowed to do what im trying to do
[10:00] <clmsy> which is trouble
[10:01] <ogra> what exactly *are* you trying to do ? :)
[10:01] <ogra> there are probably ways, just not the one you're walking ;)
[10:02] <clmsy> i would love to know if thats possible because it looks like i just couldnt find a way
[10:02] <clmsy> can you check pm for a second pretty please
[10:11] <mup> PR snapd#8247 closed: .travis.yml: enable arm64 again as unstable <Skip spread> <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8247>
[10:11] <mup> PR snapd#8400 closed: osutil: make the TestWriter() test less racy <Simple 😃> <Skip spread> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8400>
[10:14] <mup> PR snapd#8612 closed: sysconfig: use new _writable_defaults dir to create cloud config <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8612>
[10:18] <zyga> mborzecki: I updated https://github.com/snapcore/snapd/pull/8656/files based on your suggestion
[10:18] <mup> PR #8656: snap-mgmt: perform cleanup of user services <Created by zyga> <https://github.com/snapcore/snapd/pull/8656>
[10:18] <zyga> I'll add some test code now
[10:20] <zyga> https://github.com/snapcore/snapd/pull/8655 passed but I think there's still something fishy going on there
[10:20] <mup> PR #8655: tests: remove generated session-agent units <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8655>
[10:20] <zyga> I wonder if I should merge and see broader results
[10:20] <zyga> or run some more and try to get it to break
[10:20] <zyga> mvo: ^ how do you feel about this?
[10:22] <mborzecki> zyga: thanks, will take a look in a bit
[10:26] <mvo> zyga: yeah, it seems ok to land this
[10:26] <zyga> ok
[10:26] <pedronis> zyga: well, the issue is regularly breaking master so if it's even a partial improvement it would be useful, unless you know it breaks on core != 16
[10:26] <pedronis> still
[10:27] <zyga> pedronis: I fixed the thing you noticed, my fault for testing on core-16 only
[10:27] <pstolowski> pedronis: hey, so /dev/mem is not needed, it was a silly check that /dev under mounted image is not empty, so i'm getting rid of that. what is really needed is loop devices for mounting squashfs. however i just learned after discussing with zyga that lxd needs fuse, but snap-preseed assumes squashfs when mounting snapd/core snap, so that needs fixing. and we clearly need a spread test under lxd, so i'm going to work on one too
[10:27] <zyga> pedronis: it passed now (but perhaps due to luck)
[10:28] <pedronis> pstolowski: we still need to emit units for squashfs but use fuse ourselves to be clear. yes sounds we need a spread test indeed
[10:28] <zyga> I'll merge it and let's see what this brings
[10:28] <pstolowski> pedronis: yes (about units)
[10:29] <mup> PR snapd#8655 closed: tests: remove generated session-agent units <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8655>
[10:29] <pedronis> pstolowski: unless we are making images for lxd itself, at which point we need to think
[10:29] <pedronis> but it's its own tasks
[10:29] <pstolowski> pedronis: i see
[10:30] <pedronis> mvo: sorry about #8400, I did make a proposal, I can try to look at it again when I have a moment
[10:30] <mup> PR #8400: osutil: make the TestWriter() test less racy <Simple 😃> <Skip spread> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8400>
[10:33] <pedronis> pstolowski: mborzecki: not urgent but when you have a moment #8568 is ready for review, rebased it but I also addressed your initial comment
[10:33] <mup> PR #8568: asserts: rest of the Pool API <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8568>
[10:35] <zyga> mborzecki: expanded snap-mgmt test and checking what that shows
[10:35] <zyga> it now covers user services, sockets and timers
[10:37] <zyga> I need a 2nd review on https://github.com/snapcore/snapd/pull/8566 to make progress on refresh app awareness
[10:37] <mup> PR #8566: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
[10:56] <bdx> Hello
[10:57] <bdx> I am trying to get our slurm snap live
[10:58] <zyga> hello bdx
[10:58] <bdx> Z
[10:58] <bdx> zyga, hello!
[11:00] <bdx> can you aid me in getting this snap live ? I feel like I’m spinning my wheels trying to Communicate about this through discourse
[11:01] <bdx> i need auto connect granted for physical-memory-control and network-control for slurm
[11:01] <bdx> as well as the capability to push to the snap store
[11:02] <bdx> Zyga , is there anyway we can take care of this now?
[11:02] <zyga> bdx: hey, I cannot grant such permissions
[11:02] <zyga> you can make your snap live without them at any time, it's entirely up to you
[11:02] <bdx> dah, ok
[11:02] <zyga> as for the auto connect, you must follow the process on the forum
[11:03] <bdx> I can’t though ... the store won’t let me publish it ... telling me that I need approval
[11:03] <zyga> there's usually a small queue but I cannot speak about that as I'm not directly involved in the process
[11:03] <bdx> I see
[11:03] <zyga> bdx: what's the store message?
[11:03] <zyga> perhaps your snap is stuck in manual review
[11:03] <bdx> I think it may be
[11:03] <zyga> physcical memory control is a privileged interface
[11:03] <zyga> so probably that's why
[11:03] <bdx> I see
[11:03] <zyga> do you really need it? Just checking
[11:04] <zyga> it's rarely required
[11:04] <bdx> I mean ... is this usually what it takes? Lol
[11:04] <zyga> ?
[11:04] <zyga> I'm not familiar with your snap, can you explain?
[11:05] <bdx> yeah we do , slurmrestd try’s to allocate memory for its endpoints ... it fails with cannot allocate errors without the physical-memory-control
[11:05] <zyga> you don't need physical-memory-control to allocate memory
[11:06] <zyga> do you explicitly need to write to /dev/mem?
[11:06] <bdx> Yes
[11:06] <zyga> (forgive me if I misunderstand what slur is doing, I never heard about it before)
[11:06] <zyga> *slurm
[11:07] <bdx> slurm is a workload manager for HPC
[11:08] <bdx> https://slurm.schedmd.com/
[11:08]  * pstolowski lunch
[11:08] <bdx> slurm is the software that many enterprise organizations use to run their hpc workloads
[11:08] <bdx> we are trying to deliver this software to one of the enterprises
[11:09] <bdx> and many more in the furure
[11:10] <zyga> bdx: are you following the forum process for permission access?
[11:10] <bdx> by requesting it via discourse? yea
[11:10] <bdx> is there something else I should be doing?
[11:11] <zyga> I think only clarifying how the interface permissions are required for the application and then waiting
[11:11] <bdx> got it
[11:11] <zyga> and using the right forum category
[11:11] <bdx> awesome
[11:11] <mborzecki> bdx: and also the right people should be coming online in a couple of hours i believe
[11:12] <zyga> bdx: btw, can you feed my curiosity please, how is /dev/mem used by your application?
[11:12] <mup> PR snapcraft#3120 closed: spread: only run in LXD with the google/multipass provider for repo <tooling> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3120>
[11:12] <zyga> mborzecki: I found a funny/weird bug
[11:12] <zyga> mborzecki: well, probably a feature actually :)
[11:13] <bdx> zyga, are you saying I should repost my original post ?
[11:13] <zyga> snap names matter more than file names :D
[11:13] <zyga> bdx: if you have a link I'll gladly read it
[11:13] <zyga> bdx: I'm just curious,
[11:13] <zyga> never had to use /dev/mem in my work before
[11:13] <bdx> https://forum.snapcraft.io/t/slurm-snap/15595/6
[11:13] <mborzecki> bdx: also, /dev/mem access can be limited by other factors that aren't snap related, such as kernel config, iirc core for instance has strict devmem enabled
[11:14] <pedronis> pstolowski: sounds we might not need to work on supporting fuse immediately, we should unblock the other thing so they can try further
[11:15] <zyga> bdx: that thread does not explain why specific permissions are required, it might help to explain to the reviewers what the use case is
[11:15] <bdx> got it
[11:17] <mup> PR snapd#8661 opened: configcore: add "system.console-conf.disable" config option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
[11:19] <mup> PR snapd#8662 opened: tests: run core/snap-set-core-config on uc20 too <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8662>
[11:21] <zyga> bdx: I responded on the forum
[11:25] <pedronis> mvo: what's the status of #8531 ?
[11:25] <mup> PR #8531: secboot,cmd/snap-bootstrap: add model to pcr protection profile <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8531>
[11:26] <pedronis> oops, not that one
[11:26] <pedronis> mvo: I meand #8351
[11:26] <mup> PR #8351: config: apply vitality-hint immediately when the config changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/8351>
[11:26] <bdx> zyga, thanks
[11:27] <bdx> I catching the errors produced by not having the physical-memory-control plug created
[11:27] <bdx> https://paste.ubuntu.com/p/D2BVBkwyyj/
[11:27] <bdx> ^ the big one
[11:27] <zyga> bdx: can you please provide apparmor denials instead, or a line number in that file where I should look specifically if that's easier
[11:29] <mvo> pedronis: should be ok to review, it has one known wart about the reload/restart iirc but maybe okay, it's not terrible
[11:30] <pedronis> mvo: ok, I'll try to look at it when I have a moment
[11:31] <mvo> pedronis: thank you
[11:31] <pedronis> mvo: it's probably a good idea to do a master merge as well
[11:31] <mvo> pedronis: I can double check after lunch if you prefer
[11:31] <mvo> pedronis: good point
[11:31] <pedronis> it doesn't have conflict but things might have changed in that area
[11:33] <mvo> pedronis: yeah, actually let me write one or two more unit tests, I see that the "merging" of old and new is in parts only covered by spread so I think it makes sense to add something more unit-testish first
[11:34]  * mvo lunches first though
[11:35] <zyga> hmm
[11:35] <zyga> something weird is going on
[11:35]  * zyga investigates
[11:40] <pedronis> zyga: I reviewed #8578
[11:40] <mup> PR #8578: interfaces: add system-packages-doc interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
[11:40] <zyga> pedronis: thanks, looking
[11:44] <bdx> zyga, yeah that is the strange thing, nothing is showing up in dmesg
[11:48] <bdx> that link was the incorrect traceback - my apologies
[11:48] <bdx> I'm working on regenerating the error now
[11:49] <bdx> I'll post it discourse here shortly when I figure it out, thanks
[11:54] <zyga> thanks bdx
[11:59] <mborzecki> meh, running uc20 spread tests is so sloooow
[12:09]  * zyga ran into a shell trap
[12:09] <zyga> shell never ceases to surprise
[12:14] <mborzecki> zyga: surprise in the worst sense i guess ;)
[12:14] <zyga> smurf gift box surprise
[12:17] <ijohnson> morning folks
[12:38] <mborzecki> ijohnson: good morning
[12:38] <ijohnson> hey mborzecki
[12:39] <zyga> hey Ian, how are you?
[12:41] <ijohnson> doing fine mostly, how bout yourself?
[12:41]  * ijohnson -> coffee
[12:44] <zyga> ijohnson: yeah, feeling better, my back is not so bad today
[12:54] <mup> PR snapcraft#3121 opened: spread tests: improvements for python-hello-with-stage-package-dep <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3121>
[13:34] <mup> PR snapd#8662 closed: tests: run core/snap-set-core-config on uc20 too <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8662>
[13:38] <zyga> cachio: the label was set later, after the PR was opened, perhaps that is relevant
[13:38] <cachio> zyga, but I restarted all the jobs
[13:38] <cachio> and it is running again the tests
[13:38] <zyga> yes, but perhaps that's not how it works
[13:39] <zyga> we definitely used this label with workflows
[13:39] <cachio> zyga, ok
[13:39] <cachio> it is ok in that case
[13:40] <cachio> I'll wait until tests finish to merge it and publish the new bionic image
[13:40] <cachio> zyga, I'll ping you once it is ready
[13:40] <zyga> sure
[13:52] <Psil0Cybin> morning yall, question since this is kind of just opinionated > what or why does certain software only have to be downloaded from snap.d?
[13:52] <Psil0Cybin> and why does snap.d have a daemon? actually wait let me see if they have a channel
[13:55] <zyga> Psil0Cybin: hello, we call it "snapd", there's a daemon because it has an API layer that various things talk to
[13:55] <Psil0Cybin> gotchya so this daemon has to always be on?
[13:56] <Psil0Cybin> I am just confused becuase only 1 piece of software I use is offered only via snapd,. but not from tar.gz and im just trying to understand what snappy really is
[13:56] <Psil0Cybin> or snapd..is it a new aged marketplace for all linux distro?
[13:56] <zyga> it's a packaging manager that's quite different from classic packaging systems
[13:56] <Psil0Cybin> as I am just interested why i need to get snapd, before my application and what benefit would this have for me in the future?
[13:56] <Psil0Cybin> okay, is it safe to use at the moment?
[13:57] <Psil0Cybin> could it cause flaws in my system by installing and having the daemon always run?
[13:57] <Psil0Cybin> since its "constantly" communicating?
[13:58] <zyga> it's not what you say as it's not constantly but we try to be very careful and we have a good security track record
[13:58] <zyga> pstolowski: can you do a 2nd review for a trivial test change: https://github.com/snapcore/snapd/pull/8660
[13:58] <mup> PR #8660: tests: test user belongs to systemd-journald, on core20 <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8660>
[14:00] <zyga> Psil0Cybin: software developers who make applications decide how they are distributed, please ask the makers of whatever the application you were interested in for their particular motivations - snapd is much easier to package software for, compared to traditional packages, and it also allows the same package to work in many environments
[14:00] <zyga> good luck :)
[14:00] <zyga> degville: could you please look at a one-sentence change that needs some improvement here https://github.com/snapcore/snapd/pull/8578#discussion_r424371602
[14:01] <mup> PR #8578: interfaces: add system-packages-doc interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
[14:01] <zyga> once I have a suggestion I'll adjust it and that branch will be good to go
[14:01] <degville> zyga: will do!
[14:02] <zyga> thank you :)
[14:07] <mborzecki> cachio: about spread tag in https://github.com/snapcore/snapd/pull/8657 the tag was added later, from what i've seen, with gh actions, you need to add the tag when creating the PR
[14:07] <mup> PR #8657: tests: disable mount-ns test <Skip spread> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8657>
[14:08] <mborzecki> cachio: otherwise the tag info is not present in the gh even that gets evaluated as action context
[14:08] <mborzecki> maybe we should restore the old way, the current setup is bit inflexible
[14:09] <cachio> mborzecki, ah, nice, thanks for the explanation
[14:15] <zyga> mborzecki: hehe, found a bug
[14:15] <zyga> - Make snap "test-snapd-user-service" (unset) available to the system ([--user --global --root / enable snap.test-snapd-user-service.test-snapd-user-service.service] failed with exit status 1: Operation failed: Invalid argument
[14:15] <zyga> 2980
[14:15] <zyga> mborzecki: user services do not operate on 14.04 at all
[14:15] <zyga> and installing snaps fails
[14:15] <zyga> mvo, pedronis: ^ advice on what we should do, refuse to install early on?
[14:16] <mborzecki> we have a systemd version check now too
[14:17] <zyga> mborzecki: what do you men about "restore the old way?"
[14:17] <Psil0Cybin> zyga, thanks just wanted some input
[14:17] <Psil0Cybin> was i am intersted in snapd, and this is the first time i heard of it
[14:17] <zyga> Psil0Cybin: sure
[14:17] <Psil0Cybin> from the software.
[14:17] <Psil0Cybin> so thank you for your oppnions. :)
[14:17] <zyga> Psil0Cybin: you can read the source code for snapd, it's up on github.com/snapcore/snapd
[14:18] <mborzecki> zyga: do the check in the job code by poking the PR url instead of getting gh actions engine evaluate the conditions itself
[14:18] <zyga> ah, I see
[14:18] <zyga> maybe it's a bug, worth asking about it
[14:18] <zyga> I kind of like this way more than the old version
[14:19] <mborzecki> zyga: i suppose the context that the job gets is what was set/present at the time the PR got created, so not a bug per se
[14:19] <Psil0Cybin> thank you zyga.
[14:19] <Psil0Cybin> you have more peaked my interest.
[14:20] <zyga> mborzecki: it depends on perception, I'm sure that's how it is implemented though
[14:20]  * zyga breaks for lunch and bike ride 
[14:20] <zyga> I'll adjust the postrm test not to install snaps that require 16.04+ systemd
[14:20] <zyga> but we should probably fix this so that it fails at installation stage
[14:20] <zyga> I'll send some code towards that later tonight
[14:23] <mup> PR snapd#8660 closed: tests: test user belongs to systemd-journald, on core20 <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8660>
[14:26] <pedronis> zyga: that's known (14.04 not working), we just need to have a reasonable and if possible early message
[14:26] <pedronis> we'll talk with jamesh tomorrow
[14:48] <zyga> +1
[14:51] <pedronis> mborzecki: mvo: I asked a question in #8661, bit confused
[14:51] <mup> PR #8661: configcore: add "service.console-conf.disable" config option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
[14:51] <mborzecki> pedronis: yeah, double checking this now
[14:56] <mborzecki> pedronis: so i can invoke the chooser after completing console conf & rebooting, but after a reboot /var/lib/console-conf/complete does not exist (even though i get the right prompt)
[14:57] <pedronis> it's all a bit confusing :)
[14:57] <pedronis> did we change the wrapper? what writes /complete
[15:00] <mborzecki> pedronis: iow, when there's /var/lib/console-conf/complete it actually indicates that console conf should not run and getty@ starts instead
[15:01] <mborzecki> pedronis: but without the file consoel conf starts, but presents the login details here: https://github.com/CanonicalLtd/subiquity/blob/master/bin/console-conf-wrapper#L33-L68 and block getty from starting
[15:01] <mborzecki> and wow it's a hack :)
[15:05] <mborzecki> pedronis: yeah, i've created /var/lib/console-conf/complete and we directly get getty instead
[15:09] <mup> PR snapd#8657 closed: tests: disable mount-ns test <Skip spread> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8657>
[15:10] <mborzecki> pedronis: mvo: we should that condition from the unit file and instead handle it directly in the code after we had a chance to invoke the chooser
[15:10] <mborzecki> afk for a bit
[15:11] <pedronis> mborzecki: yes, sounds we need to do something like that
[15:24] <ijohnson> stgraber: hey how well is lxd's cross-distro support? would you expect it to be able to launch containers on all supported snapd arches on the following distros: debian 9, debian sid, fedora 30, 31, arch linux, centos 7 and centos 8 and maybe even amazon linux ?
[15:35] <mvo> mborzecki: thanks, commented in #8661
[15:35] <mup> PR #8661: configcore: add "service.console-conf.disable" config option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
[15:37] <zyga> ijohnson: don't forget fedora 32
[15:37] <ijohnson> oh do we support that now too?
[15:37] <ijohnson> I was just going off what we have spread.yaml for systems
[15:39] <zyga> ijohnson: we ought to
[15:39] <zyga> we should stop supporting f30 as f32 is the current one and f31 will be out of support soon
[15:42] <ijohnson> thanks zyga, so stgraber same question, just minus fedora 30 and add fedora 32
[15:43] <zyga> :)
[15:43] <zyga> yeah, that's a great question ijohnson
[15:43] <zyga> it's about what a product, shipped as a snap, officially supports
[15:43] <zyga> products vs services
[15:48] <ijohnson> I'm sure it's probably documented somewhere I just didn't find it in about 60 seconds of googling so I figured I'd ask instead
[15:52] <zyga> ijohnson: I would not be surprised if it was a mental transition that we've yet have to do
[15:52] <zyga> as snaps can be consumed on !ubuntu just as easily
[15:54] <mup> Bug #1878374 opened: UC20 stuck at installing system on some Intel NUC systems with nvme <bot-comment> <core20> <snapd:New> <Snappy:Incomplete> <https://launchpad.net/bugs/1878374>
[16:07] <stgraber> ijohnson: yes
[16:07] <ijohnson> perfect thank you stgraber
[16:07] <stgraber> We test on most of those too
[16:10] <mup> PR snapd#8663 opened: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials <Simple 😃> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8663>
[16:12] <mup> PR snapd#8664 opened: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials - 2.45 <Simple 😃> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8664>
[16:13] <mup> PR snapd#8665 opened: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials - 2.44 <Simple 😃> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8665>
[16:14] <jdstrand> mvo: fyi, I noticed with snapd 2.44.5 a lot of log noise due to ^
[16:14] <jdstrand> mvo: I don't know if you are cutting another 2.44 (I see 2.44.5 is in candidate, not release), but you might want to pick that up
[16:16] <cachio> zyga, the new bionic image is already promoted
[16:17] <mvo> jdstrand: will fix
[16:17] <mvo> jdstrand: thank you!
[16:17] <mvo> jdstrand: thanks for this
[16:18] <zyga> cachio: excellent
[16:18] <zyga> cachio: looking now
[16:18] <cachio> zyga, thanks
[16:19] <mup> PR snapd#8649 closed: usersession,tests: clean ups for userd/settings.go and move xdgopenproxy under usersession <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8649>
[16:19] <jdstrand> mvo: np
[16:21] <jdstrand> mvo, zyga: fyi, still executing the "What's Jamie up to..." plan. I should move to step 4 this tomorrow/friday (PR reviews)
[16:21] <zyga> jdstrand: ok, I don't have much for you now, perhaps just the new interface PR
[16:21] <zyga> jdstrand: more will come next week
[16:21] <zyga> jdstrand: (the one with /usr/share/doc)
[16:21] <jdstrand> mvo: step 5 (2.45 policy updates) isn't until after that, but I thought this denial was important to do fast
[16:22]  * jdstrand nods
[16:24] <mvo> jdstrand: I hope we don't need another 2.44, especially since libseccomp is not quite ready so we may as well fix it as part of 2.45
[16:30] <jdstrand> mvo: I'll leave that up to you. I'm seeing this with 2.44.5 and can say there is a lot of noise that will only get worse as people start to install snaps that use icon sets
[16:31] <jdstrand> mvo: but how that weighs against the existing testing for 2.44.5 in candidate, I can't really say
[16:31] <jdstrand> but, you have the info :)
[16:35] <mvo> jdstrand: 2.44.5 is build against the libseccomp with the regression so that is a nono, it will at least need a rebuild. but aiui there is no fixed libseccomp yet so I'm leaning towards skipping it and moving to 2.45, the "only" reason it exists is the libseccomp fix on armhf
[16:37] <jdstrand> mvo: I sponsored an update from amurray to groovy for libseccomp that can be cherrypicked while the SRU is in progress. the ~uc1 libseccomp in the image ppa has 2.4.3 with the fix and should not have the regression
[16:38] <jdstrand> mvo: again, as fyi for any decisions you might make
[16:39] <jdstrand> mvo: (dimitri uploaded that ~8 hours ago to the image ppa)
[16:40] <jdstrand> mvo: anyway, I'm not trying to convince you of anything. having it in 2.45 is great. just want you to have all the info
[17:24] <mborzecki> pedronis: mvo: perhaps we should use /quit
[17:24] <mborzecki> pedronis: sorry for the nice, had unfinished line in the buffer :)
[17:27] <mvo> jdstrand: yep, much appreciated :)
[17:27] <mup> PR snapd#8666 opened: tests/mount-ns: update to reflect new UEFI boot mode <Created by zyga> <https://github.com/snapcore/snapd/pull/8666>
[17:27] <zyga> cachio: ^
[17:28] <cachio> zyga, nice thanks!!
[17:28] <zyga> errand 1h now, I'll send more fixes to my branches later
[17:28] <zyga> o/
[17:44]  * cachio afk -> doc app
[18:46] <mup> Bug #1878307 changed: Consider replacing math/rand with crypto/rand in snapd <crypto> <go> <snapd> <Snappy:Opinion> <https://launchpad.net/bugs/1878307>
[19:08] <zyga> re
[19:08] <zyga> so cold but pretty outside
[19:59] <zyga> ijohnson: if you have a moment, needs 2nd review, test update for UEFI boot https://github.com/snapcore/snapd/pull/8666
[19:59] <mup> PR #8666: tests/mount-ns: update to reflect new UEFI boot mode <Created by zyga> <https://github.com/snapcore/snapd/pull/8666>
[20:02] <ijohnson> zyga: sure will look now
[20:02] <zyga> thanks, just merge it if you are okay with it
[20:02] <ijohnson> sure, it is all green amazingly
[20:03] <zyga> right? :D
[20:06] <mup> PR snapd#8666 closed: tests/mount-ns: update to reflect new UEFI boot mode <Created by zyga> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8666>
[22:37] <mup> PR snapcraft#3121 closed: spread tests: improvements for python-hello-with-stage-package-dep <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3121>
[22:49] <mup> PR snapcraft#3122 opened: pluginhandler: make the build environment available to all steps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3122>