[05:57] <mup> PR snapd#7745 opened: snap-bootstrap: add go-flags cmdline parsing and tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/7745>
[06:25] <mborzecki> morning
[06:29] <zyga> Hey
[06:29] <mborzecki> zyga: hey
[06:30] <mvo> hey zyga
[06:31] <mborzecki> zyga: taking swap days?
[06:32] <zyga> Need to decide when first
[06:32] <zyga> mvo: how is your jet lag today?
[06:32] <mvo> zyga: horrendous
[06:33] <zyga> I feel I can only sleep for two or three hours at a time
[06:33] <mvo> zyga: couldn't sleep most of the night
[06:33] <zyga> Barely slept last night
[06:33] <mvo> zyga: same here, super nasty
[06:33] <zyga> I had dinner at 4am
[06:34] <zyga> I need to sort out my stuff and pick up the laptop from service
[06:34] <zyga> I will do H-BS-R training today if you don’t mind
[06:34] <mvo> zyga: lol@training
[06:34] <mvo> zyga: sure, go for it
[06:35] <mvo> zyga: I try to start with some simple uc20 things, like the initramfs mount helper stuff we talked about with xnox, I hope to have an initial PR up today
[06:36] <mborzecki> zyga: want to talk about the mount thing from last week later today? (i'm sitting at mcdonald's right now, car in the shop)
[06:54] <zyga> mborzecki: yeah
[06:54] <zyga> I have a 121 at 10:00
[06:54] <zyga> When would be a good time?
[06:55] <mborzecki> zyga: 12?
[06:55] <zyga> Sounds good
[06:55] <mborzecki> zyga: i should be back home around 1030 hopefully
[06:55] <zyga> I need a moment before I start work today
[06:56] <zyga> Maybe an hour of sleep
[06:58] <mborzecki> hmm wonder whther cachio managed to update the arch images on friday
[07:02] <mup> PR snapd#7739 closed: tests: moving arch linux to unstable <Created by sergiocazzolato> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7739>
[07:10] <mborzecki> duh, our spread images of debian sid have fwupd-refresh.service enabled :/
[07:10] <mvo> mborzecki: there are prs for this
[07:10] <mvo> mborzecki: 7742 fixes debian to be less unstable
[07:11] <mborzecki> mvo: right, though, we don't really need fwupd running :P
[07:11] <mvo> mborzecki: yeah, it seems to be running on a lot of the images
[07:11] <mvo> mborzecki: but yeah, I'm all for killing it :)
[07:11] <mvo> mborzecki: arch works currently btw, the degraded test is disabled there. but yeah, revreting this would be nice
[07:12] <mvo> mborzecki: fwiw, 7745 is green (fresh from this morning) and should be a super simple review *nudge* :)
[07:12] <mborzecki> mvo: already got it opened in a tab
[07:12] <mborzecki> mvo: going trough ian's PR first
[07:15] <mvo> mborzecki: sure, there is no hurry for mine, the followup will be more interessting hopefully
[07:28] <mborzecki> mvo: think we can land #7742 ?
[07:28] <mup> PR #7742: tests: reset failing "fwupd-refresh.service" if needed <Created by mvo5> <https://github.com/snapcore/snapd/pull/7742>
[07:30] <mvo> mborzecki: yeah, lets unblock the world and then fix it
[07:30] <mvo> mborzecki: I think sergio can just remove the package from the images hopefully
[07:31] <mup> PR snapd#7742 closed: tests: reset failing "fwupd-refresh.service" if needed <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7742>
[07:32] <mborzecki> mvo: yeah, not much use for fwupd in the cloud, though there might be a spread test that checks fwupd, so just disabling/masking fwupd-refresh should be enough
[07:44] <mvo> mborzecki: +1
[07:44] <mvo> mborzecki: ok
[07:51] <mborzecki> mvo: https://paste.ubuntu.com/p/8f2MyCMSdr/ duh
[07:57] <mvo> mborzecki: fun
[07:57] <mvo> mborzecki: I think there was a recent merge for some motd-fixes, looks like the fix does not work. tests ftw!
[08:02] <pstolowski> morning
[08:10] <mborzecki> pstolowski: hey
[08:14] <pstolowski> hey mborzecki
[08:14] <pstolowski> mvo: welcome back!
[08:14] <mvo> hey pstolowski - good morning!
[08:15] <pstolowski> oh wow, i really love my flight option to frankfurt, and it is cheap
[08:29] <mborzecki> pstolowski: heh, wish they didn't kill all flights to/from LCJ
[08:29] <mborzecki> off to pick up the car and driving back home
[09:48] <mup> PR snapd#7737 closed: overlord: mock device serial in gadget remodel unit tests <Simple 😃> <Test Robustness> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7737>
[10:18] <mborzecki> re
[10:21] <mvo> welcome back mborzecki
[10:29] <mborzecki> still wondering why people would have both docker.io and docker snap installed on a single host
[10:29] <ogra> mvo, zyga, i see some very weird system-files interface behaviour here ... i tried locally building an app using system-files giving access to a file in /etc/systemd ... connected the interface wrote the file ... purged the snap ... then i changed the snap to use a layout instead and dropped the interface completely ... the layout worked and didnt complain
[10:30] <ogra> mvo, zyga, trying teh same snap on another machine rightly complains that layouts in /etc/systemd affect the host ... yet there is no system-files interface to be seen anywhere
[10:30] <mborzecki> interesting question in the forum: https://forum.snapcraft.io/t/ubuntu-core-vs-yocto-and-resinos/5266/13
[10:30] <ogra> i.e. the interface doesnt seem to have been disconnected when i purged the package on the original machine
[10:30] <ogra> and snap conenctions does not show it anymore
[10:31] <mup> PR snapd#7746 opened: snap-bootstrap: implement "snap-bootstrap initramfs-mounts" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7746>
[10:32] <ogra> ... but i can still fully access the file on this machine
[10:32] <mvo> xnox: hey, are you around today?
[10:41] <mvo> ogra: uh, that sounds like a interessting question - maybe pstolowski can have a look, I'm way too jetlagged today. or I can dig later this weeek
[10:46] <pstolowski> mvo, ogra sure, i can take a look. ogra, can you grab state.json and apparmor profile of that snap from the original machine? can you share the snap so i can try it?
[10:58] <mborzecki> pstolowski: some comments under #7686
[10:58] <mup> PR #7686: systemd: handle preseed mode <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7686>
[10:59] <pstolowski> mborzecki: ty
[11:05] <mup> PR snapd#7730 closed: spread: fix typo in spread suite <Created by sparkiegeek> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7730>
[11:09] <ogra> pstolowski, https://github.com/slimjim777/logsync/pull/1 i first added the top three commits ... the issue occured with the fourth commit of this PR (when i found i can use a layout (which wasnt really true))
[11:09] <mup> PR slimjim777/logsync#1: some fixes  <Created by ogra1> <https://github.com/slimjim777/logsync/pull/1>
[11:10] <pstolowski> ogra: ack
[11:11] <mup> PR pc-amd64-gadget#24 opened: gadget.yaml: do not use CamelCase for names <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/24>
[11:12] <ogra> pstolowski, https://people.canonical.com/~ogra/snappy/state.json
[11:14] <pstolowski> ogra: uh, that reveals your macaroon, better take it down
[11:15] <ogra> oops
[11:15] <mborzecki> or logout
[11:15] <pstolowski> yeah, and logout
[11:31] <ogra> cjwatson, i know there was a bug for this but i can not find it (though it might be a new issue) ... https://forum.snapcraft.io/t/getaddrinfo-enotfound-github-com-builds-failing-on-snapcraft-io-due-to-network-problems/14164
[11:31] <ogra> (seems npm doesnt pick up the proxy settings on the lp builders)
[11:36] <cjwatson> ogra: That just means some bit of their build system is ignoring the configured proxy
[11:36] <ogra> ah, so its an electron-packager bug then
[11:37] <cjwatson> Not specifically npm - you can see that registry.npmjs.org requests are working just fine and getting 200 responses
[11:37] <ogra> k
[11:37] <cjwatson> It'll be some random node module's postinstall script probably
[11:37] <cjwatson> Maybe electron-packager, I'm not sure
[11:38] <cjwatson> I'll respond on the forum
[11:38] <ogra> thanks !
[11:44] <popey> mbriza: hiya.
[11:46] <mbriza> popey: hi! i'm getting the 'system does not fully support snapd: cannot mount squashfs image using "squashfs": mount' error
[11:46] <popey> What OS?
[11:46] <mbriza> but i can't find the reason it's failing actually, there's just about 5 different possible reasons listed in the error message
[11:46] <mbriza> fedora 31
[11:47] <mbriza> is there a verbose mode or something
[11:48] <popey> there is SNAPD_DEBUG=1 and SNAPD_DEBUG_HTTP=7 for debugging store conversations.
[11:49] <popey> systemd.setenv=SNAPD_DEBUG=1  might do it?
[11:50] <ogra> well ... does that kernel actually have squashfs support ? (grep squash /proc/filesystems)
[11:51] <mbriza> ogra: yes, i googled it for a bit and i made sure squashfs and loop devices are available
[11:52] <ogra> also, does it support loop devices ... (ls /dev/loop-control ... or ls /dev/loop*)
[11:52] <ogra> ah, snap :)
[11:53] <mbriza> popey: https://paste.centos.org/view/0919773d this is the output when running install with SNAPD_DEBUG=1
[11:53] <mbriza> i also added it to the snapd service and restarted it but there doesn't seem to be anything very interesting in the journal
[11:53] <popey> ok, so you can ignore the reexec issue
[11:54] <mbriza> i'm also running with selinux in permissive mode to be sure
[11:54] <popey> are you able to manually mount a random squashfs file? (like your own home-created snap)?
[11:54] <ogra> did you try to manually mount a snap ?
[11:54] <ogra> haha
[11:54] <popey> you type too slow :)
[11:54]  * ogra shuts up now
[11:55] <mbriza> yes, i can
[11:56] <popey> which instructions are you using to install snapd?
[11:56] <mbriza> https://snapcraft.io/docs/installing-snap-on-fedora
[11:56] <popey> oh, also `snap version`?
[11:56] <mbriza> snap    2.42.1-1.fc31
[11:57] <popey> ok, installing fedora 31 on my big machine to test
[11:57] <mbriza> i had a completely different set of issues on my f31 machine on friday though... i was at least able to install snaps :D
[11:58] <mbriza> this is a different machine
[11:59] <popey> yeah, very odd
[11:59] <popey> well, virtualbox is broken for me on 19.10, so that stops that. Bah
[12:00] <ogra> i thought you said you'D install on your BIG computer ! https://pl.wikipedia.org/wiki/Cray_X-MP#/media/Plik:EPFL_CRAY-I_1.jpg
[12:00] <popey> mbriza: what version of snapcraft built the snap you're having trouble with?
[12:00] <popey> not that big, but it's heavy :)
[12:00] <mbriza> popey: i can't install any snap
[12:01] <popey> ok
[12:01] <popey> not even "snap install hello-world"
[12:01] <mbriza> yup
[12:01] <popey> https://www.entroware.com/store/athena  - big machine :D
[12:01] <popey> ok, this is more serious. Do you have a funky kernel, or a stock Fedora supplied one?
[12:02] <ogra> popey, yeah, but it has a keyboard on the seat !
[12:02] <mbriza> nothing funky, not even closed source graphics drivers or anything
[12:02] <mbriza> i just updated the machine this morning
[12:02] <popey> hmmm
[12:02] <ogra> do you know what exactly got updated ?
[12:03] <ogra> (and did it work at any point in time on that machine)
[12:03] <mbriza> basically everything, i was gone for almost 3 weeks :) i didn't have snap installed for quite some months but i remember it working at some point in the past
[12:04] <mbriza> i think i removed it either because of a package conflict between upgrades (i upgrade rather soon in the fedora devel cycle) or disk space
[12:06] <popey> Looks like I need virtualbox test build to get this working on linux 5.3. On that then installing fedora 31 and updates to see what happens here. Will take a while. Sorry.
[12:07] <mbriza> np, i'll just lurk here or on the forums to work this out
[12:07] <popey> actually, i can install clean on my x220. will do that from a usb key.
[12:07] <mbriza> anyway, there's nothing too funky about neither of my systems, i think i'm fairly capable of keeping the system in a workable state
[12:08] <mbriza> are there any conflicts with virtual machines or something like that?
[12:08] <mbriza> i'm running something in qemu-kvm most of the time
[12:09] <popey> no, I run in all manner of distros in vm's all the time
[12:10] <Chipaca> mbriza: I'm sorry if you already answered this: can you mount a snap by hand?
[12:10] <mbriza> Chipaca: i can
[12:11] <Chipaca> mbriza: what does dmesg say when you do?
[12:11] <mbriza> Chipaca: [ 2973.344224] SELinux: security_context_str_to_sid(system_u:object_r:snappy_snap_t:s0) failed for (dev loop1, type squashfs) errno=-22
[12:11] <mbriza> but i'm in permissive mode
[12:12] <mbriza> the error message from snap itself is extremely vague, listing like 5 different possible reasons why it could be failing... pretty hard to debug from my side
[12:12] <Chipaca> mbriza: mount is very vague with its errors
[12:13] <popey> (I'm inclined to agree with that. The error about re-exec not working should be informational, but it doesn't make that clear)
[12:13] <Chipaca> mbriza: which is why that check exists in the first place (getting that vague an error during install is even worse0
[12:14] <Chipaca> mbriza: are you also able to mount a snap by hand if you put that snap in /tmp ?
[12:14] <Chipaca> popey: which error about re-exec not working?
[12:14] <popey> https://paste.centos.org/view/0919773d
[12:14] <mbriza> Chipaca: yes
[12:14] <popey> that's mbriza's output
[12:15] <popey> (I am still confused why you're getting a _multi_ snap)
[12:15] <Chipaca> ah
[12:15] <popey> it should be amd64 for your machine. Must be erroneous binaries in there somehow
[12:15] <Chipaca> popey: you get multi when you have architectures: [amd64,i386], don't you
[12:15] <mbriza> i can fetch the other one but both of them worked on the laptop
[12:15] <mbriza> and both of the machines are amd64
[12:15] <Chipaca> popey: and you'd have that architectures when it was i386 binaries for example
[12:16] <mbriza> and then again, this is failing even when i try to install hello-snap from the store
[12:17] <Chipaca> mbriza: that error you get is not about the snap
[12:17] <Chipaca> mbriza: that error is from a sanity check performed before any operation is attempted
[12:17] <Chipaca> mbriza: did you go into permissive mode after starting snapd?
[12:17] <mbriza> i restarted snapd multiple times in the meantime
[12:19] <Chipaca> mbriza: as I say, that error comes from a sanity check, and what it's trying to do is just a 'mount -t squashfs /tmp/<a temp squashfs>'
[12:19] <Chipaca> mbriza: and that is failing, with the error from mount as reported to you
[12:20] <Chipaca> oh, oh
[12:20] <Chipaca> also maybe in selinux systems there's a context= appended?
[12:21] <Chipaca> mbriza: I don't know selinux enough to know what context that is
[12:21] <Chipaca> maybe mborzecki knows
[12:21] <mbriza> it's trying to access a file called 'snap-failure'
[12:22] <popey> How ironic :)
[12:22] <mbriza> which is i guess an error reporter?
[12:22] <Chipaca> that's a thing you don't need to worry about :-)
[12:22] <Chipaca> it's an auto-reverter for snapd
[12:23] <Chipaca> for (core, or) systems with reexec
[12:24] <ogra> is setting permissive mode a runtime thing (not an selinux user here) ... i.e. did you reboot after setting it to make sure the kernel picked it up ?
[12:24] <mbriza> there are 3 selinux alerts for the time of attempting to install a snap and all 3 point to this so i guess that's not relevant
[12:25] <mbriza> ogra: permissive mode is a runtime thing, selinux won't block anything in this mode but it will report detected... uhh, breaches? don't know how to call it
[12:25] <Chipaca> mbriza: at a guess, we're adding a context=<something> to mount, because selinux.ProbedLevel() isn't "unsupported", and that is getting into trouble because of it being permissive
[12:25] <ogra> ok
[12:25] <Chipaca> mbriza: but I know nothing about selinux :) so it's a question for mborzecki
[12:25] <mbriza> Chipaca: i can run in enforcing if that's a problem
[12:26] <mbriza> still the same error
[12:26] <Chipaca> mbriza: if you add -o context=<gibberish> to the mount of the .snap, does it still work?
[12:26] <Chipaca> that was really quick for enabling enforcing + restarting snapd + trying to install something
[12:27] <mbriza> Chipaca: the daemon is not really running, it's systemd socket-activated
[12:27] <mbriza> anyway, with gibberish in the mount command i'm getting the same error as above
[12:30] <mborzecki> mbriza: hm what about selinux?
[12:30] <pstolowski> ogra: hmm i cannot reproduce the issue you saw. on same host i got "cannot update snap namespace: cannot write to "/etc/systemd/journal-upload.conf" because it would affect the host in "/etc/systemd" when trying your snap with layouts, after installing and then removing the one with system-files interface
[12:30] <pstolowski> ogra: i'm on 19.10
[12:31] <mbriza> mborzecki: to be honest i'm not sure what the issue is - there's a lot of repetitive information but the gist is i'm not able to install any snap on fedora 31 because `mount` fails
[12:31] <mbriza> not even sure if it's related to systemd, it fails regardless of running in permissive/enforcing mode
[12:32] <pstolowski> ogra: i suspect something got stale on your box but it's unclear how. your state.json looks sane, it doesn't have system-files connection
[12:32] <mbriza> err i mean selinux
[12:32] <mborzecki> mbriza: reading backlog, looks like snappy_snap_t isn't defined? that'd be weird it's part of the policy shipped with the pacakge
[12:33] <pstolowski> ogra: is your first box still in this state (e.g. the snap with layout succesfully installed)?
[12:33] <mborzecki> mbriza: that's 31 right?
[12:33] <mbriza> mborzecki: yes
[12:33] <mborzecki> mbriza: ok, let me check rawhide first
[12:35] <ogra> pstolowski, i'm on 16.04 here and i think the machine is still in that state ...
[12:37] <pstolowski> ogra: good. could you get me /var/lib/snapd/apparmor/profiles/snap.logsync-james.upload profile?
[12:40] <mbriza> mborzecki: just reinstalled the snap packages and rebooted to be extra sure everything is up to date but install is still failing
[12:40] <mborzecki> mbriza: same thing in dmesg as you posted before?
[12:40] <mbriza> yes
[12:41] <ogra> pstolowski, just to prove it still works ... https://paste.ubuntu.com/p/7vtsXM3Kvm/ ...  one sec, getting the file
[12:42] <ogra> pstolowski, and the apparmor profile ... http://paste.ubuntu.com/p/gz5DfScfQ7/
[12:42] <pstolowski> ogra: did you use --devmode or try at any point?
[12:44] <ogra> only in the very first run i think ... then i removed the snap, re-built, re-installed and connected system-files ... then dropped system-files for layout, removed/purged the snap and installed with the layout
[12:44] <pstolowski> ogra: ok, so the profile has /etc/systemd/journal-upload.conf mrwklix, from the layout; but it doesn't have sytem-files interface anymore in the profile
[12:44] <mup> PR snapd#7738 closed: overlord/state: panic in MarkEdge() if task is nil <Simple 😃> <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7738>
[12:45] <pstolowski> it's weird it didn't complain
[12:45] <ogra> right ...
[12:45] <ogra> it complains if i copy the snap to another machine (also 16.04)
[12:46] <pstolowski> ogra: yep, got it. interesting. ok, i think i need to look at different place in the code now.. thanks
[12:46] <ogra> should oh also ...
[12:47] <ogra> ogra@anubis:~/datengrab/logsync:master$ sudo snap remove --purge logsync-james
[12:47] <ogra> logsync-james removed
[12:47] <ogra> ogra@anubis:~/datengrab/logsync:master$ cat /etc/systemd/journal-upload.conf
[12:47] <ogra> [Upload]
[12:47] <ogra> URL=http://www.example.com:19532
[12:47] <ogra> -should
[12:47] <ogra> shouldnt the file be removed whan the snap gets purged ?
[12:50] <mborzecki> mbriza: installing core snap
[12:51] <pstolowski> ogra: --purge is only for avoiding automatic snapshots, nothing else
[12:51] <ogra> well, yeah ... but remove should remove the file, or not ?
[12:52] <mborzecki> mbriza: and it installed fine, ok, so we need to debug your system
[12:52] <mborzecki> mbriza: anything useful ausearch -m AVC ?
[12:52] <ogra> i.e. i dnot think a layouted file should stay behind when removing the snap that used the layout
[12:53] <ogra> that will result in all kinds of cruft after a while
[12:53] <ogra> (at least in the case where the layout actually created the file from scratch)
[12:54] <pstolowski> ogra: yes i think you're right, i'm not sure why layout isn't cleaning after itself
[12:54] <mborzecki> mbriza: while at it, does seinfo -t |grep snappy_snap_t list anything?
[12:55] <pstolowski> ogra: something for zyga (maybe there was a reason it's like that)
[12:56] <mbriza> mborzecki: ausearch doesn't report anything new when running sudo snap install hello-world
[12:56] <mbriza> mborzecki: snappy_snap_t is not present in the output of seinfo .-t
[12:56] <mbriza> -t
[12:57] <pstolowski> ogra: one more question.. on the misbehaving box, is snapd at the current stable version?
[12:57] <ogra> checking
[12:57] <pstolowski> ogra: same version of snapd on both boxes?
[12:57] <mborzecki> mbriza: rpm -q snapd-selinux show anything?
[12:57] <ogra> ogra@anubis:~/datengrab/logsync:master$ snap version
[12:57] <ogra> snap    2.42.1
[12:57] <ogra> snapd   2.42.1
[12:57] <ogra> series  16
[12:57] <ogra> ubuntu  16.04
[12:57] <ogra> kernel  4.4.0-141-generic
[12:57] <ogra> kernel is a bit behind ... but the rest should be recent
[12:58] <ogra> the other box uses the hwe kernel but beyond this the same versions
[12:58] <mbriza> mborzecki: snapd-selinux-2.42.1-1.fc31.noarch
[12:58] <mbriza> mborzecki: there's this line in the journal though
[12:58] <mbriza> mborzecki: Nov 18 13:37:27 localhost.localdomain kernel: SELinux:  Context unconfined_u:object_r:snappy_home_t:s0 is not valid (left unmapped).
[12:58] <mborzecki> mbriza: seinfo -t snappy_home_t ?
[12:59] <mbriza> mborzecki: Types: 0
[12:59] <ogra> pstolowski, the main difference is that the system-files interface was never connected on the box that behaves correct
[12:59] <pstolowski> uhm
[12:59] <ogra> (well, i also have never used --devmode with this snap on the behaving machine)
[13:00] <mbriza> mborzecki: https://paste.centos.org/view/e51f0cc4 this is in the journal too
[13:00] <popey> fwiw, i just installed f31, and updated it to latest, and can install and run snaps fine
[13:01] <mborzeck1> wow, my really sucks today
[13:02] <mbriza> mborzeck1: https://paste.centos.org/view/e51f0cc4 this is in the journal too
[13:02] <mbriza> mborzeck1: also as for the output for seinfo-t snappy_home_t, it was Types: 0
[13:02] <mborzeck1> mbriza: right, so looks like the policy wasn't loaded for some reason
[13:03] <mborzeck1> mbriza: ok, can you try dnf history list snapd-selinux and then dnf history info <id> ?
[13:05] <mbriza> mborzecki: there's this little line in there, yes:
[13:05] <mbriza> mborzecki:   16 /usr/sbin/semodule:  Failed on /usr/share/selinux/packages/snappy.pp.bz2!
[13:05] <mbriza> mborzecki: and i get the same error when trying to reinstall the package
[13:06] <mborzecki> mbriza: yeah, i suppose if you do semodule -l |grep snappy there'll be nothing listed there
[13:06] <mbriza> mborzecki: semodule -l doesn't even start
[13:06] <mbriza> libsemanage.semanage_direct_get_module_info: Unable to read flatpak module lang ext file. (No such file or directory).
[13:07] <mbriza> now this is not related to snappy at all
[13:07] <mborzecki> mbriza: hm, did you upgrade 30 -> 31?
[13:07] <mbriza> yeah
[13:07] <mbriza> dnf reinstall *selinux*
[13:07] <mborzecki> mbriza: did you do distro-sync afterwards?
[13:08] <mbriza> mborzecki: i'm distro-syncing all the time
[13:08] <pstolowski> ogra: ok, i know what's going on and why it didn't work on second box
[13:08] <mborzecki> mbriza: tried with --allowerasing?
[13:08] <ogra> \o/
[13:09] <mborzecki> mbriza: btw. you need to use sudo/su to run semodule
[13:09] <mbriza> yeah, of course... seems there's something wrong about my selinux policies though
[13:09] <pstolowski> ogra: it only succeeds with layout-based snap if you already have /etc/systemd/journal-upload.conf in place (leftover from previous snap). trespassing-detection code is then happy. otherwise it complains. i'll pass it to zyga to decide what to do with iy
[13:09] <pstolowski> *it
[13:10] <ogra> yay, thanks
[13:10] <mborzecki> mbriza: can you post the output of sestatus somewhere?
[13:10] <ogra> so let me remoe that file ... to prove it ;)
[13:10] <mbriza> mborzecki: https://paste.centos.org/view/2e2c930d
[13:11] <ogra> ogra@anubis:~/datengrab/logsync:master$ sudo snap install --dangerous logsync-james_0.2_amd64.snap
[13:11] <ogra> error: cannot perform the following tasks:
[13:11] <ogra> - Run configure hook of "logsync-james" snap if present (run hook "configure":
[13:11] <ogra> -----
[13:11] <ogra> cannot update snap namespace: cannot write to "/etc/systemd/journal-upload.conf" because it would affect the host in "/etc/systemd"
[13:11] <ogra> snap-update-ns failed with code 1: File exists
[13:11] <ogra> -----)
[13:11] <ogra> yay !
[13:12] <ogra> yup ... touching the file before snap install then makes it work again
[13:14] <mborzecki> mbriza: doesn't feel like it's related to snapd policy in particular
[13:14] <mbriza> mborzecki: yeah, definitely somewhere else, thank you for helping me debug this
[13:14] <mbriza> and to the rest of the channel, too :)
[13:14] <mborzecki> mbriza: last thing, can you try installing flatpak-selinux, and see if it works?
[13:14] <mborzecki> mbriza: they also ship the policy in a separate module
[13:16] <mbriza> mborzecki: i have it but it (and mysql, too) complains
[13:16] <pstolowski> ogra: good, thanks for confirming
[13:16] <mbriza> ... even after reinstalling
[13:16] <zyga> ogra: it is a bug
[13:16] <zyga> Trespassing should never surface as an error
[13:17] <mborzecki> mbriza: yeah, i'd try checking in #fedora-devel, and maybe trying .autorelabel too
[13:17] <zyga> It is a duplicate of another bug on launchpad already
[13:17] <ogra> zyga, yeah, after two days cuddling with it i guessed that much :)
[13:17] <zyga> Give us some time, we have a plan that fixes a large class of those issues
[13:18] <ogra> yeah, no worries, i'm surely not in a hurry ... just ran into it and found it weird
[13:19] <ogra> pstolowski, one other (unrelated) thing ... should "listen-stream:" still be supported ? i was trying it yesterday and snapcraft complains about things like "listen-stream: 8080" not "being an object"
[13:20] <ogra> (iirc you initially implemented it)
[13:21] <Chipaca> ogra: listen-stream: <the path to a socket>
[13:22] <ogra> Chipaca, uhm, so network sockets got removed ?
[13:23] <ogra> https://snapcraft.io/docs/snapcraft-yaml-reference thinks <port> is a valid thing
[13:26] <mbriza> mborzecki: ha, after deleting the lang files in /var/lib/selinux/targeted/active/modules/200 and reinstalling the packages, i'm able to install snaps again
[13:26] <mbriza> thank you!
[13:27] <mborzecki> mbriza: does it still work when you reboot?
[13:28] <mbriza> i just reinstalled everything with 'selinux' in its name and there were no errors so i assume it'll be fine
[13:29] <mbriza> also my app actually starts on this machine when installed from snap
[13:29] <pstolowski> ogra: i quickly grepped the code and we have tests for listen-stream: <an integer>; should work. not sure why snapcraft rejects it
[13:30] <b_b> hi
[13:30] <mborzecki> mbriza: hah, that's a good sign ;)
[13:31] <b_b> is there a problem with latest stable base core18 ?
[13:31] <ogra> pstolowski, hmm, well, then it is most likely a snapcraft bug with the yaml parser ...
[13:31] <b_b> i'm getting error about this one since yesterday
[13:31] <b_b> error: unable to contact snap store
[13:31] <b_b> An error occurred when trying to execute 'sudo -i env SNAPCRAFT_HAS_TTY=True snap install --channel stable core18' with 'multipass': returned exit code 1.
[13:31] <ogra> $ SNAPCRAFT_BUILD_ENVIRONMENT=host snapcraft
[13:31] <ogra> Issues while validating snapcraft.yaml: The 'apps/remote/sockets/listen-stream' property does not match the required schema: 19532 is not of type 'object'
[13:31] <ogra> thats what i guess
[13:31] <pstolowski> zyga: re trespassing, shouldn't it behave consistently whether /etc/systemd/journal-upload.conf (that with bind via layout: bind-file: $SNAP_DATA/journal-upload.conf) exists or not? at the moment it is happy if it exists and you only get trespassing error if doesn't
[13:31] <ogra> *s/guess/get/
[13:32] <b_b> i've tried to clean all mutipass vms, and launched a clean snapcraft, no luck
[13:34] <ogra> aha ... https://bugs.launchpad.net/snapd/+bug/1612440
[13:34] <mup> Bug #1612440: Full systemd socket activation support <lxd> <Snapcraft:New> <snapd:Fix Released> <https://launchpad.net/bugs/1612440>
[13:34] <ogra> looks like the snapd task is fix-released but the snapcaft one is still new
[13:36] <mborzecki> cachio is off today, isn't he?
[13:39] <zyga> hey hey
[13:39] <zyga> pstolowski: it's a bug, it's actually diagnosed already AFAIK
[13:39] <zyga> pstolowski: yes but $COMPLEXITY
[13:39] <zyga> pstolowski: it's not what it seems at first
[13:40] <zyga> ogra: did you report a bug for this?
[13:40] <zyga> ogra: it would help with tracking
[13:40] <ogra> zyga, nope, not yet
[13:40] <zyga> ogra: no rush as I'm a zombie today
[13:40] <zyga> but please do later on
[13:40] <ogra> (it isnt only complex to splve, but also complex to explain :P )
[13:40] <zyga> yeah
[13:40] <ogra> *solve
[13:40] <ogra> ok, will do
[13:41] <zyga> thank you
[13:41] <zyga> I feel terrible today
[13:42] <ogra> must be the maple syrup withdrawal :)
[13:42] <mvo> zyga: yeah, its not a great day
[13:42] <zyga> mvo: I was sleeping between 8 and 1PM
[13:42] <mvo> zyga: uh, woah
[13:43] <mvo> I had a "short" nap in the morning of 2h, but I was already working at 4:30 or so (yay jetlag)
[13:49] <Chipaca> mborzecki: next week
[14:38] <b_b> weird, i can't get rid of this mutlipass error
[14:39] <b_b> sudo -i env SNAPCRAFT_HAS_TTY=True snap install --channel stable core18' with 'multipass': returned exit code 1
[14:39] <b_b> snap info core18 shows me than the stable channel have a different date than the others
[15:32] <oSoMoN> ijohnson, it looks like https://github.com/snapcore/snapd/pull/7731 is good to go now (tests passed), can it be merged?
[15:32] <mup> PR #7731: usersession/userd: add "apt" to the white list of URL schemes handled by xdg-open (LP: #1776873) <Created by oSoMoN> <https://github.com/snapcore/snapd/pull/7731>
[15:37] <b_b> see u ++
[15:39] <pstolowski> https://github.com/snapcore/snapd/pull/7727 needs 2nd review
[15:39] <mup> PR #7727: tests: improve TestDoPrereqRetryWhenBaseInFlight to fix occasional flakiness <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7727>
[16:11] <mup> PR snapcraft#2804 opened: conda plugin: simplify source url/checksum handling <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2804>
[17:04] <zyga> gosh, "ethics and code of conduct" is a long one
[18:00] <mup> PR pc-amd64-gadget#24 closed: gadget.yaml: do not use CamelCase for names <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/24>
[18:15] <mup> PR snapd#7747 opened: gadget: skip fakeroot if not needed <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7747>
[18:20] <Chipaca> zyga: looooooong
[18:20] <Chipaca> zyga: nominally 30-60mins but took me just under 2h
[18:21] <Chipaca> although it wasn't interruption-free
[19:06] <zyga> Chipaca: lol, "Resisting taking vacation time – fraud is often discovered while an employee is gone"
[19:07] <zyga> Chipaca: I wonder when people will start to incorporate remote workers into generic training material
[19:07] <zyga> I feel like a woman may have felt a few decades ago
[19:51] <mup> PR snapcraft#2805 opened: plugins: address type errors for mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2805>
[20:09] <mup> PR snapcraft#2806 opened: cli: address type errors for mypy uprev  <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2806>
[20:50] <mup> PR snapd#7748 opened: overlord: fix the get command help message <Simple 😃> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7748>
[21:07] <jkridner> ogra: I see you made an mjpg-streamer snap. have you thought about making one that includes the opencv filter features?
[21:17] <jkridner> hmmm... https://github.com/ogra1/mjpg-streamer/blob/master/snap/snapcraft.yaml#L36 seems to indicate you are pulling the sources with the opencv plugin.
[21:18] <jkridner> ah, https://github.com/ogra1/mjpg-streamer/blob/master/snap/snapcraft.yaml#L12
[21:51] <mup> PR snapcraft#2807 opened: meta: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2807>
[22:42] <mup> PR snapcraft#2808 opened: repo: fix fetch_binary()'s return type for deb repo <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2808>