| mvo | could someone with a fedora system check the selinux label for /lib/firware for me please (stat /lib/firmware)? | 07:04 |
|---|---|---|
| mvo | pedronis, Chipaca good morning :) | 08:47 |
| mvo | pedronis: thanks for your review! | 08:47 |
| Chipaca | mvo: morning! i was here earlier but then needed to step away for a bit (and the laptop went to sleep :) ) | 08:48 |
| Chipaca | mvo: how's things? | 08:48 |
| pedronis | Chipaca: mvo: hi | 08:49 |
| mvo | Chipaca: things are looking good, very quiet in the morning with so many people on vac :) | 08:50 |
| Chipaca | mvo: let's set things on fire :-) | 08:51 |
| mvo | Chipaca: haha! | 08:51 |
| * mvo fetches his asbestos suite (its still warm from the latest flamewars) | 08:52 | |
| * Chipaca puts away the kindling | 08:52 | |
| Chipaca | yeah... ha! ha! | 08:52 |
| pedronis | I merged 7036 with a long commit message | 08:59 |
| mvo | pedronis: thanks for this | 09:00 |
| pedronis | Chipaca: as we talked about the various snapd type PRs are fou you to shepard from 6977 to 7086 (and 7092 but the last one needs snapcraft) | 09:12 |
| * Chipaca nods | 09:12 | |
| pedronis | I will try myself to look at and move forward some of Pawel's PRs | 09:13 |
| pedronis | my own PRs need reviews or 2nd reviews | 09:13 |
| ogra | pedronis, remind me ... did we eventually allow interface connections from gadget.yaml by name ? ( https://forum.snapcraft.io/t/connection-with-gadget-spidev0-plug/12281 ) | 09:33 |
| ogra | (i think i remember you said something along that line a while ago) | 09:34 |
| pedronis | ogra: we have a connections stanza in gadget.yaml | 09:35 |
| pedronis | https://forum.snapcraft.io/t/the-gadget-snap/696 | 09:37 |
| pedronis | mvo: another comment on 7105 | 09:45 |
| mvo | pedronis: thanks, looking | 09:46 |
| pedronis | mvo: is there anything else that is urgent for me to review? | 09:48 |
| ogra | pedronis, yes, but in the past (and apparently at present too) that only allowed connections per-ID i thought i remembered there were plans to allow connections by-name .... | 09:49 |
| mvo | pedronis: nothing urgent I think | 09:49 |
| pedronis | ogra: no, that hasn't changed | 09:49 |
| ogra | k, thanks | 09:50 |
| pedronis | we don't allow names in defaults eitehr | 09:50 |
| pedronis | *either | 09:50 |
| ogra | yeah, i know | 09:51 |
| Chipaca | mvo: can you confirm you're ok with the first snapd type pr now? | 10:44 |
| Chipaca | (i think your issues were addressed?) | 10:44 |
| Chipaca | I don't think I'll land it until they're all ready, but wanted to confirm | 10:45 |
| mvo | Chipaca: will check in a a wee bit | 10:45 |
| mvo | Chipaca: 6977 ? | 10:46 |
| Chipaca | mvo: yus | 10:46 |
| mvo | ta | 10:46 |
| Chipaca | kenvandine: do we have a bug # for the "seed.yaml wronk in eoan daily cdimage" thing? | 11:43 |
| Chipaca | kenvandine: because https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1836569 | 11:44 |
| Chipaca | dunno if it's actually the same as https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1828500 | 11:44 |
| * Chipaca goes to fix lunch | 11:45 | |
| mvo | Eighth_Doctor: hey, cgroup v2 is not yet enabled by default in fedora 31, is it? I am just playing with the livecd and it seems I still have v1 (?) | 11:59 |
| Eighth_Doctor | mvo: not yet, no | 11:59 |
| Eighth_Doctor | it'll likely get done next week | 12:00 |
| Eighth_Doctor | but you can test in v2 mode now if you want | 12:00 |
| Eighth_Doctor | mvo: almost everything in Fedora except snaps is ready for cgroups v2 | 12:02 |
| === ricab is now known as ricab|lunch | ||
| mvo | Eighth_Doctor: thanks! I'm looking into making sure snaps also work, this is why I was asking :) | 12:59 |
| mvo | Eighth_Doctor: I use "systemd.unified_cgroup_hierarchy" in the kernel cmdline | 12:59 |
| Eighth_Doctor | huh, then it might be enabled | 13:01 |
| Eighth_Doctor | if `systemd.unified_cgroup_hierarchy=1` is set as a boot parameter, then it will use cgroups v2 | 13:02 |
| Eighth_Doctor | there's limited automatic translation of cgroupsv1 terms to cgroupsv2 terms by systemd itself | 13:02 |
| mvo | Eighth_Doctor: thank you, I will keep poking (in a meeting right now) | 13:05 |
| kenvandine | Chipaca: i suspect that's the same as bug 1828500 | 13:15 |
| * Chipaca afk for a bit | 13:39 | |
| === ricab|lunch is now known as ricab | ||
| ackk | jdstrand, oh I had missed your message, thanks for the updated snapd package, will test now! | 13:54 |
| ijohnson | mvo: reviewed 7105 for you | 13:58 |
| mvo | ijohnson: thank you! | 14:00 |
| ijohnson | what's the most up to date way to get spread installed locally? maybe cachio do you know? | 14:52 |
| cachio | jutst download from .. | 14:52 |
| cachio | ijohnson, https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz | 14:53 |
| cachio | this is the officialbinary | 14:53 |
| cachio | also you can use the spread snap | 14:53 |
| ijohnson | cachio: ok, thanks | 14:56 |
| zyga | ijohnson: try spread.zygoon.pl for images | 14:57 |
| zyga | Greetings from almost Andorra | 14:57 |
| ijohnson | hey zyga | 14:59 |
| ijohnson | thanks I'll take a look there too | 14:59 |
| ijohnson | it would be nice if HACKING.md was updated to mention zyga's spread images | 15:01 |
| Chipaca | ijohnson: go for it | 15:08 |
| Chipaca | ijohnson: bah | 15:09 |
| Chipaca | ijohnson: check with zyga first? | 15:09 |
| ijohnson | maybe I will | 15:09 |
| Chipaca | ijohnson: he's mentioned them to me in private | 15:09 |
| ijohnson | ... check with zyga | 15:09 |
| Chipaca | ijohnson: not sure that url exists in a public place (meaning he might not want it crawled) | 15:09 |
| ijohnson | I see | 15:09 |
| ijohnson | I'll let zyga have his vacation and check on it next week | 15:10 |
| Chipaca | ijohnson: :-) | 15:10 |
| Chipaca | ijohnson: nah, message him, the photos he's posting to twitter are much too nice to let it pass | 15:10 |
| zyga | Chipaca: it is public | 15:19 |
| zyga | ijohnson: it is my new CDN setup, go for it please :-) | 15:24 |
| Eighth_Doctor | zyga, robert_ancell_, mvo: I need help? https://src.fedoraproject.org/rpms/gnome-software/pull-request/1 | 15:33 |
| Eighth_Doctor | it looks like the core is that they think Ubuntu isn't using GNOME Software anymore: https://src.fedoraproject.org/rpms/gnome-software/pull-request/1#comment-27692 | 15:34 |
| Eighth_Doctor | if they could be assured otherwise in the ticket, then they may let us put it back | 15:34 |
| ackk | Chipaca, is it possible to pass additional LD_PRELOAD to snapcraft-preload? | 15:40 |
| mvo | kenvandine, willcooke could you pleae have a look at the pr and lines from Eighth_Doctor above? not sure what exactly our plan so I don't feel qualified to comment myself | 15:41 |
| ackk | actually, I should ask sergiusens :) | 15:43 |
| jdstrand | msalvatore: hey, would you mind approving r79 through r84 of https://dashboard.snapcraft.io/snaps/test-snapd-daemon-user/ ? | 15:44 |
| jdstrand | msalvatore: it is a test snap where the the review-tools don't have the current iteration of the snap.yaml for the feature | 15:45 |
| msalvatore | jdstrand: ok, so they can be approved despite the warning? | 15:45 |
| jdstrand | msalvatore: yes. I updated the tools, but it isn't in prod yet | 15:46 |
| kenvandine | mvo: commented | 15:50 |
| jdstrand | msalvatore: thanks! | 15:53 |
| msalvatore | jdstrand: any time | 15:54 |
| mvo | kenvandine: thank you! | 15:54 |
| sergiusens | ackk: go ahead and ask :-) | 15:58 |
| ackk | sergiusens, looking at snapcraft-preload code (and my cpp is very poor) it seems ifyou have LD_PRELOAD set, it should get passed on to called binaries. it that correct? | 16:00 |
| sergiusens | ackk: the one snapcraft-preload sets, yes | 16:02 |
| ackk | sergiusens, no I mean, if you have LD_PRELOAD set in the env where snapcraft-preload is called | 16:02 |
| ackk | sergiusens, I see it looks at LD_PRELOAD in the env | 16:02 |
| ackk | sergiusens, https://paste.ubuntu.com/p/3k3SgJVFFC/ | 16:04 |
| ackk | sergiusens, basically I would need to pass my LD_PRELOAD down | 16:04 |
| sergiusens | ackk: as long as you do not use https://github.com/sergiusens/snapcraft-preload/blob/master/snapcraft-preload.in | 16:04 |
| sergiusens | and do the preload declaration yourself | 16:05 |
| ackk | environment: | 16:05 |
| ackk | LD_PRELOAD: $SNAP/usr/lib/stub_initgroups.so | 16:05 |
| ackk | sergiusens, ^ I have this in the snap app, and have command: bin/snapcraft-preload <mycommand> | 16:05 |
| ackk | sergiusens, but that's not working | 16:06 |
| sergiusens | ackk: well yeah, snapcraft-preload wipes your LD_PRELOAD as I just mentioned above | 16:06 |
| ackk | sergiusens, is there a way to combine them? | 16:07 |
| sergiusens | do not use the snapcraft-preload script seems like the first step and only LD_PRELOAD the library it creates | 16:08 |
| ackk | sergiusens, ah I see | 16:08 |
| ackk | sergiusens, thanks I'll try that way | 16:11 |
| mvo | Eighth_Doctor: do you think you could have a quick check for https://github.com/snapcore/snapd/pull/7104/files ? the selinux bits there? should be easy for someone with selinux skills, but everyone if have with them is currently not around :/ | 16:16 |
| Eighth_Doctor | mvo: I'll take a look in a bit :) | 16:17 |
| mvo | Eighth_Doctor: *thank you* | 16:18 |
| cachio | mvo, hey, core validation is done but dragonboard beta image doesn't boot | 17:10 |
| cachio | stable image with core rfom beta works well | 17:10 |
| cachio | but beta image doesn't | 17:10 |
| cachio | still debugging that | 17:10 |
| mvo | cachio: thank you! that is unexpected, curious about your findings | 17:56 |
| cachio | mvo, seems to be a problem wiht the image | 17:57 |
| cachio | mvo, I am testing a new one now | 17:57 |
| mvo | cachio: thank you | 18:00 |
| cachio | mvo, yaw | 18:01 |
| jdstrand | are there any tricks to make the 'prepare' step in spread to go faster? | 18:06 |
| jdstrand | I use -reuse, but all I really want to do is adjust the task.yaml and retry | 18:07 |
| * jdstrand wonders if he can run rerun a task.yaml while in -debug... | 18:08 | |
| ackk | jdstrand, ftr tested your 2.40-like build with daemon user, everything seems to work fine. thanks | 19:18 |
| leftyfb | on the assumption that we can install a snap from the snap package file as opposed to the snap stop, in doing so, does that prevent the snap from auto-updating? | 19:34 |
| jdstrand | ackk: great! fyi, I'm actively working on incorporating various feedback into the PR and will give you an updated deb when I have final approval on the snap.yaml. as it stand, it will change to 'system-users: [ snap_daemon ]', but that isn't *final* | 19:43 |
| jdstrand | ackk: (which means you'll need to s/daemon/snap_daemon/ in the other parts of your snap (that part is final)) | 19:44 |
| jdstrand | ackk: if you'd prefer, I can give you a deb that uses the above snap.yaml and finalized 'snap_daemon' user, with the understanding that the snap.yaml will change, or we can just wait | 19:45 |
| zyga | jdstrand: tip: use task.sh | 19:52 |
| zyga | jdstrand: and in task.yaml, execute it | 19:52 |
| zyga | jdstrand: it works best without prepare/restore inside task itself | 19:52 |
| zyga | (I'm not really here, greetings from hotel wifi) | 19:52 |
| jdstrand | zyga: ok, thanks, I'll play with that. and hello :) | 19:53 |
| zyga | jdstrand: hello :) | 19:54 |
| zyga | jdstrand: it also works nice with test-cleanup tool but that's just on my laptop, for now, it allows you to have prepare/restore like logic embedded inside task.sh+task.yaml | 19:54 |
| zyga | jdstrand: I'm in Andorra today | 19:54 |
| jdstrand | zyga: nice nice and cool :) | 19:55 |
| ackk | jdstrand, it doesn't really matter until it's final, as we won't merge the changes for the system user until we have that | 19:58 |
| jdstrand | ackk: that's what I figured. cool | 19:59 |
| ackk | jdstrand, so "snap_daemon" *is* final you mean? | 19:59 |
| ackk | just how you declare it isn't? | 19:59 |
| === msalvatore_ is now known as msalvatore | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!