[00:34] Bug #1878307 opened: Consider replacing math/rand with crypto/rand in snapd [00:44] PR snapcraft#3119 closed: elf: fix string format for debug log [01:29] PR snapcraft#3120 opened: spread: only run in LXD with the google/multipass provider for repo === Psi-Jack is now known as Guest9815 === Guest9815 is now known as Psi-Jack [05:15] morning [05:59] mborzecki: hi, I have a question in https://github.com/snapcore/snapd/pull/8647 [05:59] PR #8647: cmd/snap-bootstrap: tweak recovery trigger log messages [06:09] pedronis: hi, let me see [06:12] pedronis: those are log messages [06:19] mborzecki: ok, because Ian suggestion sounded instruction like, I suppose it works for a log too but got me confused [06:27] PR snapd#8647 closed: cmd/snap-bootstrap: tweak recovery trigger log messages [06:39] #8649 needs review (it's relatively short) [06:39] PR #8649: usersession,tests: clean ups for userd/settings.go and move xdgopenproxy under usersession [06:55] mvo: hey [06:57] mborzecki: good morning [06:58] PR snapd#7728 closed: cmd: implement snap run --explain [06:58] mvo: hi [06:59] hey pedronis ! good morning [07:00] 8652 needs a second review, pretty simple fwiw [07:03] 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] PR #8653: asserts: make clearer that with label we mean a serialized label [07:03] pedronis: sure [07:04] PR snapd#8653 closed: asserts: make clearer that with label we mean a serialized label [07:04] pedronis: yeah, just looked at it, this could have been done with skip-skpead even [07:04] pedronis: anyway, merged :) [07:06] mvo: thanks [07:11] good morning [07:13] zyga: hey [07:14] good morning zyga [07:15] morning [07:16] and good morning pstolowski [07:20] hey pstolowski [07:21] zyga: hi, #8655 failed differently, it seems the fix as is, is too blunt [07:21] PR #8655: tests: remove generated session-agent units [07:22] I noticed, I think I know why [07:23] My fix was tailored for core 16 and not generic enough [07:27] I will have to check [07:29] mborzecki: thanks for the reviews, fwiw I pushed this: https://github.com/snapcore/snapd/pull/8649/commits/a98339435069517eb7a2997d4802bf926bc322b7 [07:29] PR #8649: usersession,tests: clean ups for userd/settings.go and move xdgopenproxy under usersession [07:29] pedronis: thanks! [07:31] I send a follow up [07:31] 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] the problem was that snapd-failover test runs on all systems but only core16 needs the workaround [07:32] classic systems gain the extra services via snapd.{deb,rpm} [07:32] core systems, apart from core16, have snapd snap used in general and the services do not need to be removed [07:32] only core16 is special here [07:32] let's see if it passes [07:33] pedronis: I also noticed I need to update the permissions for core20 - the test user does not have journal access there [07:33] that is a different path so needs special treatment (test user setup on core20) [07:34] pedronis: hi, i've read it just now [07:37] 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] pstolowski: thank you [07:45] * zyga found the missing core20 test user setup [07:58] PR snapd#8660 opened: tests: test user belongs to systemd-journald, on core20 [07:58] zyga: some comments under https://github.com/snapcore/snapd/pull/8656 [07:58] PR #8656: snap-mgmt: perform cleanup of user services [08:00] thanks! [08:00] good ideas indeed [08:29] * zyga eagerly checks if https://github.com/snapcore/snapd/pull/8655 is green now [08:29] PR #8655: tests: remove generated session-agent units [08:33] mborzecki: we don't support user-level timers, do we? [08:35] zyga: hm looking at the code, seems like we do [08:35] zyga: and not sure we have a spread test for it either [08:36] Ah, I understand now [08:36] Timers bind to apps [08:37] And apps have scope [08:45] PR snapd#8658 closed: cmd/snap-bootstrap/initramfs-mounts: cosmetic changes in prep for future work [08:52] 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] jamesh: hey [09:10] hi [09:10] sure, in a moment [09:11] jamesh: done [09:17] zyga: thanks! [09:50] hi everyone [09:50] im in need of some help [09:50] 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] ill show you the part related in gadget.yaml [09:52] https://pastebin.com/ee2zXpjC [09:52] are we not allowed to try rename the writable partition ? [09:55] clmsy, nope, while this might be different in core20 images, until core18 the existence of a "writable" labeled partition is essential [09:56] 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] oh, and looking at your paste you seem to define two targets for the same thing ... i dount that can work [09:58] ... and your target: entry is also not properly indented [09:59] it was i think pastebin related [09:59] the original file is properly indented [09:59] hmm [09:59] is it ? [09:59] (tabs vs spaces ?) [10:00] the paste show the other indents just fine [10:00] *shows [10:00] yes it broke when i pasted there and i just hand changed it quickly to look ok :) [10:00] yeah i understand the issue, so im not allowed to do what im trying to do [10:00] which is trouble [10:01] what exactly *are* you trying to do ? :) [10:01] there are probably ways, just not the one you're walking ;) [10:02] i would love to know if thats possible because it looks like i just couldnt find a way [10:02] can you check pm for a second pretty please [10:11] PR snapd#8247 closed: .travis.yml: enable arm64 again as unstable <⛔ Blocked> [10:11] PR snapd#8400 closed: osutil: make the TestWriter() test less racy [10:14] PR snapd#8612 closed: sysconfig: use new _writable_defaults dir to create cloud config [10:18] mborzecki: I updated https://github.com/snapcore/snapd/pull/8656/files based on your suggestion [10:18] PR #8656: snap-mgmt: perform cleanup of user services [10:18] I'll add some test code now [10:20] https://github.com/snapcore/snapd/pull/8655 passed but I think there's still something fishy going on there [10:20] PR #8655: tests: remove generated session-agent units [10:20] I wonder if I should merge and see broader results [10:20] or run some more and try to get it to break [10:20] mvo: ^ how do you feel about this? [10:22] zyga: thanks, will take a look in a bit [10:26] zyga: yeah, it seems ok to land this [10:26] ok [10:26] 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] still [10:27] pedronis: I fixed the thing you noticed, my fault for testing on core-16 only [10:27] 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] pedronis: it passed now (but perhaps due to luck) [10:28] 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] I'll merge it and let's see what this brings [10:28] pedronis: yes (about units) [10:29] PR snapd#8655 closed: tests: remove generated session-agent units [10:29] pstolowski: unless we are making images for lxd itself, at which point we need to think [10:29] but it's its own tasks [10:29] pedronis: i see [10:30] mvo: sorry about #8400, I did make a proposal, I can try to look at it again when I have a moment [10:30] PR #8400: osutil: make the TestWriter() test less racy [10:33] 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] PR #8568: asserts: rest of the Pool API [10:35] mborzecki: expanded snap-mgmt test and checking what that shows [10:35] it now covers user services, sockets and timers [10:37] I need a 2nd review on https://github.com/snapcore/snapd/pull/8566 to make progress on refresh app awareness [10:37] PR #8566: c/snaplock/runinhibit: add run inhibition operations [10:56] Hello [10:57] I am trying to get our slurm snap live [10:58] hello bdx [10:58] Z [10:58] zyga, hello! [11:00] 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] i need auto connect granted for physical-memory-control and network-control for slurm [11:01] as well as the capability to push to the snap store [11:02] Zyga , is there anyway we can take care of this now? [11:02] bdx: hey, I cannot grant such permissions [11:02] you can make your snap live without them at any time, it's entirely up to you [11:02] dah, ok [11:02] as for the auto connect, you must follow the process on the forum [11:03] I can’t though ... the store won’t let me publish it ... telling me that I need approval [11:03] there's usually a small queue but I cannot speak about that as I'm not directly involved in the process [11:03] I see [11:03] bdx: what's the store message? [11:03] perhaps your snap is stuck in manual review [11:03] I think it may be [11:03] physcical memory control is a privileged interface [11:03] so probably that's why [11:03] I see [11:03] do you really need it? Just checking [11:04] it's rarely required [11:04] I mean ... is this usually what it takes? Lol [11:04] ? [11:04] I'm not familiar with your snap, can you explain? [11:05] 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] you don't need physical-memory-control to allocate memory [11:06] do you explicitly need to write to /dev/mem? [11:06] Yes [11:06] (forgive me if I misunderstand what slur is doing, I never heard about it before) [11:06] *slurm [11:07] slurm is a workload manager for HPC [11:08] https://slurm.schedmd.com/ [11:08] * pstolowski lunch [11:08] slurm is the software that many enterprise organizations use to run their hpc workloads [11:08] we are trying to deliver this software to one of the enterprises [11:09] and many more in the furure [11:10] bdx: are you following the forum process for permission access? [11:10] by requesting it via discourse? yea [11:10] is there something else I should be doing? [11:11] I think only clarifying how the interface permissions are required for the application and then waiting [11:11] got it [11:11] and using the right forum category [11:11] awesome [11:11] bdx: and also the right people should be coming online in a couple of hours i believe [11:12] bdx: btw, can you feed my curiosity please, how is /dev/mem used by your application? [11:12] PR snapcraft#3120 closed: spread: only run in LXD with the google/multipass provider for repo [11:12] mborzecki: I found a funny/weird bug [11:12] mborzecki: well, probably a feature actually :) [11:13] zyga, are you saying I should repost my original post ? [11:13] snap names matter more than file names :D [11:13] bdx: if you have a link I'll gladly read it [11:13] bdx: I'm just curious, [11:13] never had to use /dev/mem in my work before [11:13] https://forum.snapcraft.io/t/slurm-snap/15595/6 [11:13] 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] 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] 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] got it [11:17] PR snapd#8661 opened: configcore: add "system.console-conf.disable" config option [11:19] PR snapd#8662 opened: tests: run core/snap-set-core-config on uc20 too [11:21] bdx: I responded on the forum [11:25] mvo: what's the status of #8531 ? [11:25] PR #8531: secboot,cmd/snap-bootstrap: add model to pcr protection profile [11:26] oops, not that one [11:26] mvo: I meand #8351 [11:26] PR #8351: config: apply vitality-hint immediately when the config changes [11:26] zyga, thanks [11:27] I catching the errors produced by not having the physical-memory-control plug created [11:27] https://paste.ubuntu.com/p/D2BVBkwyyj/ [11:27] ^ the big one [11:27] 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] 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] mvo: ok, I'll try to look at it when I have a moment [11:31] pedronis: thank you [11:31] mvo: it's probably a good idea to do a master merge as well [11:31] pedronis: I can double check after lunch if you prefer [11:31] pedronis: good point [11:31] it doesn't have conflict but things might have changed in that area [11:33] 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] hmm [11:35] something weird is going on [11:35] * zyga investigates [11:40] zyga: I reviewed #8578 [11:40] PR #8578: interfaces: add system-packages-doc interface [11:40] pedronis: thanks, looking [11:44] zyga, yeah that is the strange thing, nothing is showing up in dmesg [11:48] that link was the incorrect traceback - my apologies [11:48] I'm working on regenerating the error now [11:49] I'll post it discourse here shortly when I figure it out, thanks [11:54] thanks bdx [11:59] meh, running uc20 spread tests is so sloooow [12:09] * zyga ran into a shell trap [12:09] shell never ceases to surprise [12:14] zyga: surprise in the worst sense i guess ;) [12:14] smurf gift box surprise [12:17] morning folks [12:38] ijohnson: good morning [12:38] hey mborzecki [12:39] hey Ian, how are you? [12:41] doing fine mostly, how bout yourself? [12:41] * ijohnson -> coffee [12:44] ijohnson: yeah, feeling better, my back is not so bad today [12:54] PR snapcraft#3121 opened: spread tests: improvements for python-hello-with-stage-package-dep [13:34] PR snapd#8662 closed: tests: run core/snap-set-core-config on uc20 too [13:38] cachio: the label was set later, after the PR was opened, perhaps that is relevant [13:38] zyga, but I restarted all the jobs [13:38] and it is running again the tests [13:38] yes, but perhaps that's not how it works [13:39] we definitely used this label with workflows [13:39] zyga, ok [13:39] it is ok in that case [13:40] I'll wait until tests finish to merge it and publish the new bionic image [13:40] zyga, I'll ping you once it is ready [13:40] sure [13:52] 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] and why does snap.d have a daemon? actually wait let me see if they have a channel [13:55] Psil0Cybin: hello, we call it "snapd", there's a daemon because it has an API layer that various things talk to [13:55] gotchya so this daemon has to always be on? [13:56] 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] or snapd..is it a new aged marketplace for all linux distro? [13:56] it's a packaging manager that's quite different from classic packaging systems [13:56] 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] okay, is it safe to use at the moment? [13:57] could it cause flaws in my system by installing and having the daemon always run? [13:57] since its "constantly" communicating? [13:58] 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] pstolowski: can you do a 2nd review for a trivial test change: https://github.com/snapcore/snapd/pull/8660 [13:58] PR #8660: tests: test user belongs to systemd-journald, on core20 [14:00] 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] good luck :) [14:00] 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] PR #8578: interfaces: add system-packages-doc interface [14:01] once I have a suggestion I'll adjust it and that branch will be good to go [14:01] zyga: will do! [14:02] thank you :) [14:07] 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] PR #8657: tests: disable mount-ns test [14:08] cachio: otherwise the tag info is not present in the gh even that gets evaluated as action context [14:08] maybe we should restore the old way, the current setup is bit inflexible [14:09] mborzecki, ah, nice, thanks for the explanation [14:15] mborzecki: hehe, found a bug [14:15] - 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] 2980 [14:15] mborzecki: user services do not operate on 14.04 at all [14:15] and installing snaps fails [14:15] mvo, pedronis: ^ advice on what we should do, refuse to install early on? [14:16] we have a systemd version check now too [14:17] mborzecki: what do you men about "restore the old way?" [14:17] zyga, thanks just wanted some input [14:17] was i am intersted in snapd, and this is the first time i heard of it [14:17] Psil0Cybin: sure [14:17] from the software. [14:17] so thank you for your oppnions. :) [14:17] Psil0Cybin: you can read the source code for snapd, it's up on github.com/snapcore/snapd [14:18] 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] ah, I see [14:18] maybe it's a bug, worth asking about it [14:18] I kind of like this way more than the old version [14:19] 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] thank you zyga. [14:19]