[07:04] <mvo> could someone with a fedora system check the selinux label for /lib/firware for me please (stat /lib/firmware)?
[08:47] <mvo> pedronis, Chipaca good morning :)
[08:47] <mvo> pedronis: thanks for your review!
[08:48] <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:49] <pedronis> Chipaca: mvo: hi
[08:50] <mvo> Chipaca: things are looking good, very quiet in the morning with so many people on vac :)
[08:51] <Chipaca> mvo: let's set things on fire :-)
[08:51] <mvo> Chipaca: haha!
[08:52]  * 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:59] <pedronis> I merged 7036 with a long commit message
[09:00] <mvo> pedronis: thanks for this
[09:12] <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:13] <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:33] <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:34] <ogra> (i think i remember you said something along that line a while ago)
[09:35] <pedronis> ogra: we have a connections stanza in gadget.yaml
[09:37] <pedronis> https://forum.snapcraft.io/t/the-gadget-snap/696
[09:45] <pedronis> mvo: another comment on 7105
[09:46] <mvo> pedronis: thanks, looking
[09:48] <pedronis> mvo: is there anything else that is urgent for me to review?
[09:49] <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:50] <ogra> k, thanks
[09:50] <pedronis> we don't allow names in defaults eitehr
[09:50] <pedronis> *either
[09:51] <ogra> yeah, i know
[10:44] <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:45] <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:46] <mvo> Chipaca: 6977 ?
[10:46] <Chipaca> mvo: yus
[10:46] <mvo> ta
[11:43] <Chipaca> kenvandine: do we have a bug # for the "seed.yaml wronk in eoan daily cdimage" thing?
[11:44] <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:45]  * Chipaca goes to fix lunch
[11:59] <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
[12:00] <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:02] <Eighth_Doctor> mvo: almost everything in Fedora except snaps is ready for cgroups v2
=== ricab is now known as ricab|lunch
[12:59] <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
[13:01] <Eighth_Doctor> huh, then it might be enabled
[13:02] <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:05] <mvo> Eighth_Doctor: thank you, I will keep poking (in  a meeting right now)
[13:15] <kenvandine> Chipaca: i suspect that's the same as bug 1828500
[13:39]  * Chipaca afk for a bit
=== ricab|lunch is now known as ricab
[13:54] <ackk> jdstrand, oh I had missed your message, thanks for the updated snapd package, will test now!
[13:58] <ijohnson> mvo: reviewed 7105 for you
[14:00] <mvo> ijohnson: thank you!
[14:52] <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:53] <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:56] <ijohnson> cachio: ok, thanks
[14:57] <zyga> ijohnson: try spread.zygoon.pl for images
[14:57] <zyga> Greetings from almost Andorra
[14:59] <ijohnson> hey zyga
[14:59] <ijohnson> thanks I'll take a look there too
[15:01] <ijohnson> it would be nice if HACKING.md was updated to mention zyga's spread images
[15:08] <Chipaca> ijohnson: go for it
[15:09] <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:10] <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:19] <zyga> Chipaca: it is public
[15:24] <zyga> ijohnson: it is my new CDN setup, go for it please :-)
[15:33] <Eighth_Doctor> zyga, robert_ancell_, mvo: I need help? https://src.fedoraproject.org/rpms/gnome-software/pull-request/1
[15:34] <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:40] <ackk> Chipaca,  is it possible to pass additional LD_PRELOAD to snapcraft-preload?
[15:41] <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:43] <ackk> actually, I should ask sergiusens :)
[15:44] <jdstrand> msalvatore: hey, would you mind approving r79 through r84 of https://dashboard.snapcraft.io/snaps/test-snapd-daemon-user/ ?
[15:45] <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:46] <jdstrand> msalvatore: yes. I updated the tools, but it isn't in prod yet
[15:50] <kenvandine> mvo: commented
[15:53] <jdstrand> msalvatore: thanks!
[15:54] <msalvatore> jdstrand: any time
[15:54] <mvo> kenvandine: thank you!
[15:58] <sergiusens> ackk: go ahead and ask :-)
[16:00] <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:02] <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:04] <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:05] <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:06] <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:07] <ackk> sergiusens, is there a way to combine them?
[16:08] <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:11] <ackk> sergiusens, thanks I'll try that way
[16:16] <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:17] <Eighth_Doctor> mvo: I'll take a look in a bit :)
[16:18] <mvo> Eighth_Doctor: *thank you*
[17:10] <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:56] <mvo> cachio: thank you! that is unexpected, curious about your findings
[17:57] <cachio> mvo, seems to be a problem wiht the image
[17:57] <cachio> mvo, I am testing a new one now
[18:00] <mvo> cachio: thank you
[18:01] <cachio> mvo, yaw
[18:06] <jdstrand> are there any tricks to make the 'prepare' step in spread to go faster?
[18:07] <jdstrand> I use -reuse, but all I really want to do is adjust the task.yaml and retry
[18:08]  * jdstrand wonders if he can run rerun a task.yaml while in -debug...
[19:18] <ackk> jdstrand, ftr tested your 2.40-like build with daemon user, everything seems to work fine. thanks
[19:34] <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:43] <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:44] <jdstrand> ackk: (which means you'll need to s/daemon/snap_daemon/ in the other parts of your snap (that part is final))
[19:45] <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:52] <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:53] <jdstrand> zyga: ok, thanks, I'll play with that. and hello :)
[19:54] <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:55] <jdstrand> zyga: nice nice and cool :)
[19:58] <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:59] <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?
=== msalvatore_ is now known as msalvatore