mup | Bug #1878307 opened: Consider replacing math/rand with crypto/rand in snapd <crypto> <go> <snapd> <Snappy:New> <https://launchpad.net/bugs/1878307> | 00:34 |
---|---|---|
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> | 00:44 |
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> | 01:29 |
=== Psi-Jack is now known as Guest9815 | ||
=== Guest9815 is now known as Psi-Jack | ||
mborzecki | morning | 05:15 |
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> | 05:59 |
mborzecki | pedronis: hi, let me see | 06:09 |
mborzecki | pedronis: those are log messages | 06:12 |
pedronis | mborzecki: ok, because Ian suggestion sounded instruction like, I suppose it works for a log too but got me confused | 06:19 |
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:27 |
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:39 |
mborzecki | mvo: hey | 06:55 |
mvo | mborzecki: good morning | 06:57 |
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:58 |
mvo | hey pedronis ! good morning | 06:59 |
mvo | 8652 needs a second review, pretty simple fwiw | 07:00 |
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:03 |
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:04 |
pedronis | mvo: thanks | 07:06 |
zyga | good morning | 07:11 |
mborzecki | zyga: hey | 07:13 |
mvo | good morning zyga | 07:14 |
pstolowski | morning | 07:15 |
mborzecki | and good morning pstolowski | 07:16 |
mvo | hey pstolowski | 07:20 |
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:21 |
zyga | I noticed, I think I know why | 07:22 |
zyga | My fix was tailored for core 16 and not generic enough | 07:23 |
zyga | I will have to check | 07:27 |
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:29 |
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:31 |
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:32 |
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:33 |
pstolowski | pedronis: hi, i've read it just now | 07:34 |
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:37 |
pedronis | pstolowski: thank you | 07:38 |
* zyga found the missing core20 test user setup | 07:45 | |
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> | 07:58 |
zyga | thanks! | 08:00 |
zyga | good ideas indeed | 08:00 |
* 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:29 |
zyga | mborzecki: we don't support user-level timers, do we? | 08:33 |
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:35 |
zyga | Ah, I understand now | 08:36 |
zyga | Timers bind to apps | 08:36 |
zyga | And apps have scope | 08:37 |
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:45 |
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 | 08:52 |
zyga | jamesh: hey | 09:10 |
jamesh | hi | 09:10 |
zyga | sure, in a moment | 09:10 |
zyga | jamesh: done | 09:11 |
jamesh | zyga: thanks! | 09:17 |
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:50 |
clmsy | https://pastebin.com/ee2zXpjC | 09:52 |
clmsy | are we not allowed to try rename the writable partition ? | 09:52 |
ogra | clmsy, nope, while this might be different in core20 images, until core18 the existence of a "writable" labeled partition is essential | 09:55 |
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:56 |
ogra | oh, and looking at your paste you seem to define two targets for the same thing ... i dount that can work | 09:57 |
ogra | ... and your target: entry is also not properly indented | 09:58 |
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 ?) | 09:59 |
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:00 |
ogra | what exactly *are* you trying to do ? :) | 10:01 |
ogra | there are probably ways, just not the one you're walking ;) | 10:01 |
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:02 |
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:11 |
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:14 |
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:18 |
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:20 |
mborzecki | zyga: thanks, will take a look in a bit | 10:22 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
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:33 |
zyga | mborzecki: expanded snap-mgmt test and checking what that shows | 10:35 |
zyga | it now covers user services, sockets and timers | 10:35 |
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:37 |
bdx | Hello | 10:56 |
bdx | I am trying to get our slurm snap live | 10:57 |
zyga | hello bdx | 10:58 |
bdx | Z | 10:58 |
bdx | zyga, hello! | 10:58 |
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:00 |
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:01 |
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:02 |
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:03 |
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:04 |
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:05 |
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:06 |
bdx | slurm is a workload manager for HPC | 11:07 |
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:08 |
bdx | and many more in the furure | 11:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
mup | PR snapd#8661 opened: configcore: add "system.console-conf.disable" config option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661> | 11:17 |
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:19 |
zyga | bdx: I responded on the forum | 11:21 |
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:25 |
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:26 |
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:27 |
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:29 |
pedronis | mvo: ok, I'll try to look at it when I have a moment | 11:30 |
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:31 |
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:33 |
* mvo lunches first though | 11:34 | |
zyga | hmm | 11:35 |
zyga | something weird is going on | 11:35 |
* zyga investigates | 11:35 | |
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:40 |
bdx | zyga, yeah that is the strange thing, nothing is showing up in dmesg | 11:44 |
bdx | that link was the incorrect traceback - my apologies | 11:48 |
bdx | I'm working on regenerating the error now | 11:48 |
bdx | I'll post it discourse here shortly when I figure it out, thanks | 11:49 |
zyga | thanks bdx | 11:54 |
mborzecki | meh, running uc20 spread tests is so sloooow | 11:59 |
* zyga ran into a shell trap | 12:09 | |
zyga | shell never ceases to surprise | 12:09 |
mborzecki | zyga: surprise in the worst sense i guess ;) | 12:14 |
zyga | smurf gift box surprise | 12:14 |
ijohnson | morning folks | 12:17 |
mborzecki | ijohnson: good morning | 12:38 |
ijohnson | hey mborzecki | 12:38 |
zyga | hey Ian, how are you? | 12:39 |
ijohnson | doing fine mostly, how bout yourself? | 12:41 |
* ijohnson -> coffee | 12:41 | |
zyga | ijohnson: yeah, feeling better, my back is not so bad today | 12:44 |
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> | 12:54 |
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:34 |
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:38 |
zyga | we definitely used this label with workflows | 13:39 |
cachio | zyga, ok | 13:39 |
cachio | it is ok in that case | 13:39 |
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:40 |
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:52 |
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:55 |
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:56 |
Psil0Cybin | could it cause flaws in my system by installing and having the daemon always run? | 13:57 |
Psil0Cybin | since its "constantly" communicating? | 13:57 |
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> | 13:58 |
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:00 |
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:01 |
zyga | thank you :) | 14:02 |
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:07 |
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:08 |
cachio | mborzecki, ah, nice, thanks for the explanation | 14:09 |
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:15 |
mborzecki | we have a systemd version check now too | 14:16 |
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:17 |
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:18 |
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:19 |
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:20 |
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:23 |
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:26 |
=== cory_fu_ is now known as cory_fu | ||
zyga | +1 | 14:48 |
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:51 |
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:56 |
pedronis | it's all a bit confusing :) | 14:57 |
pedronis | did we change the wrapper? what writes /complete | 14:57 |
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:00 |
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:01 |
mborzecki | pedronis: yeah, i've created /var/lib/console-conf/complete and we directly get getty instead | 15:05 |
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:09 |
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:10 |
pedronis | mborzecki: yes, sounds we need to do something like that | 15:11 |
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:24 |
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:35 |
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:37 |
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:39 |
ijohnson | thanks zyga, so stgraber same question, just minus fedora 30 and add fedora 32 | 15:42 |
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:43 |
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:48 |
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:52 |
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> | 15:54 |
stgraber | ijohnson: yes | 16:07 |
ijohnson | perfect thank you stgraber | 16:07 |
stgraber | We test on most of those too | 16:07 |
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:10 |
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:12 |
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:13 |
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:14 |
cachio | zyga, the new bionic image is already promoted | 16:16 |
mvo | jdstrand: will fix | 16:17 |
mvo | jdstrand: thank you! | 16:17 |
mvo | jdstrand: thanks for this | 16:17 |
zyga | cachio: excellent | 16:18 |
zyga | cachio: looking now | 16:18 |
cachio | zyga, thanks | 16:18 |
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:19 |
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:21 |
* jdstrand nods | 16:22 | |
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:24 |
=== egeeirl1 is now known as egeeirl | ||
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:30 |
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:31 |
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:35 |
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:37 |
jdstrand | mvo: again, as fyi for any decisions you might make | 16:38 |
jdstrand | mvo: (dimitri uploaded that ~8 hours ago to the image ppa) | 16:39 |
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 | 16:40 |
=== ijohnson is now known as ijohnson|lunch | ||
mborzecki | pedronis: mvo: perhaps we should use /quit | 17:24 |
mborzecki | pedronis: sorry for the nice, had unfinished line in the buffer :) | 17:24 |
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:27 |
cachio | zyga, nice thanks!! | 17:28 |
zyga | errand 1h now, I'll send more fixes to my branches later | 17:28 |
zyga | o/ | 17:28 |
* cachio afk -> doc app | 17:44 | |
=== ijohnson|lunch is now known as ijohnson | ||
mup | Bug #1878307 changed: Consider replacing math/rand with crypto/rand in snapd <crypto> <go> <snapd> <Snappy:Opinion> <https://launchpad.net/bugs/1878307> | 18:46 |
zyga | re | 19:08 |
zyga | so cold but pretty outside | 19:08 |
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> | 19:59 |
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:02 |
zyga | right? :D | 20:03 |
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> | 20:06 |
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:37 |
mup | PR snapcraft#3122 opened: pluginhandler: make the build environment available to all steps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3122> | 22:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!