mupPR snapd#7745 opened: snap-bootstrap: add go-flags cmdline parsing and tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/7745>05:57
mborzeckizyga: hey06:29
mvohey zyga06:30
mborzeckizyga: taking swap days?06:31
zygaNeed to decide when first06:32
zygamvo: how is your jet lag today?06:32
mvozyga: horrendous06:32
zygaI feel I can only sleep for two or three hours at a time06:33
mvozyga: couldn't sleep most of the night06:33
zygaBarely slept last night06:33
mvozyga: same here, super nasty06:33
zygaI had dinner at 4am06:33
zygaI need to sort out my stuff and pick up the laptop from service06:34
zygaI will do H-BS-R training today if you don’t mind06:34
mvozyga: lol@training06:34
mvozyga: sure, go for it06:34
mvozyga: 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 today06:35
mborzeckizyga: 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:36
zygamborzecki: yeah06:54
zygaI have a 121 at 10:0006:54
zygaWhen would be a good time?06:54
mborzeckizyga: 12?06:55
zygaSounds good06:55
mborzeckizyga: i should be back home around 1030 hopefully06:55
zygaI need a moment before I start work today06:55
zygaMaybe an hour of sleep06:56
mborzeckihmm wonder whther cachio managed to update the arch images on friday06:58
mupPR snapd#7739 closed: tests: moving arch linux to unstable <Created by sergiocazzolato> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7739>07:02
mborzeckiduh, our spread images of debian sid have fwupd-refresh.service enabled :/07:10
mvomborzecki: there are prs for this07:10
mvomborzecki: 7742 fixes debian to be less unstable07:10
mborzeckimvo: right, though, we don't really need fwupd running :P07:11
mvomborzecki: yeah, it seems to be running on a lot of the images07:11
mvomborzecki: but yeah, I'm all for killing it :)07:11
mvomborzecki: arch works currently btw, the degraded test is disabled there. but yeah, revreting this would be nice07:11
mvomborzecki: fwiw, 7745 is green (fresh from this morning) and should be a super simple review *nudge* :)07:12
mborzeckimvo: already got it opened in a tab07:12
mborzeckimvo: going trough ian's PR first07:12
mvomborzecki: sure, there is no hurry for mine, the followup will be more interessting hopefully07:15
mborzeckimvo: think we can land #7742 ?07:28
mupPR #7742: tests: reset failing "fwupd-refresh.service" if needed <Created by mvo5> <https://github.com/snapcore/snapd/pull/7742>07:28
mvomborzecki: yeah, lets unblock the world and then fix it07:30
mvomborzecki: I think sergio can just remove the package from the images hopefully07:30
mupPR 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:31
mborzeckimvo: 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 enough07:32
mvomborzecki: +107:44
mvomborzecki: ok07:44
mborzeckimvo: https://paste.ubuntu.com/p/8f2MyCMSdr/ duh07:51
mvomborzecki: fun07:57
mvomborzecki: I think there was a recent merge for some motd-fixes, looks like the fix does not work. tests ftw!07:57
=== pstolowski|afk is now known as pstolowski
mborzeckipstolowski: hey08:10
pstolowskihey mborzecki08:14
pstolowskimvo: welcome back!08:14
mvohey pstolowski - good morning!08:14
pstolowskioh wow, i really love my flight option to frankfurt, and it is cheap08:15
mborzeckipstolowski: heh, wish they didn't kill all flights to/from LCJ08:29
mborzeckioff to pick up the car and driving back home08:29
mupPR 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>09:48
mvowelcome back mborzecki10:21
mborzeckistill wondering why people would have both docker.io and docker snap installed on a single host10:29
ogramvo, 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 complain10:29
ogramvo, 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 anywhere10:30
mborzeckiinteresting question in the forum: https://forum.snapcraft.io/t/ubuntu-core-vs-yocto-and-resinos/5266/1310:30
ograi.e. the interface doesnt seem to have been disconnected when i purged the package on the original machine10:30
ograand snap conenctions does not show it anymore10:30
mupPR snapd#7746 opened: snap-bootstrap: implement "snap-bootstrap initramfs-mounts" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7746>10:31
ogra... but i can still fully access the file on this machine10:32
mvoxnox: hey, are you around today?10:32
mvoogra: 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 weeek10:41
pstolowskimvo, 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:46
mborzeckipstolowski: some comments under #768610:58
mupPR #7686: systemd: handle preseed mode <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7686>10:58
pstolowskimborzecki: ty10:59
=== mborzeck1 is now known as mborzecki
mupPR snapd#7730 closed: spread: fix typo in spread suite <Created by sparkiegeek> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7730>11:05
ograpstolowski, 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
mupPR slimjim777/logsync#1: some fixes  <Created by ogra1> <https://github.com/slimjim777/logsync/pull/1>11:09
pstolowskiogra: ack11:10
mupPR 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:11
ograpstolowski, https://people.canonical.com/~ogra/snappy/state.json11:12
pstolowskiogra: uh, that reveals your macaroon, better take it down11:14
mborzeckior logout11:15
pstolowskiyeah, and logout11:15
ogracjwatson, 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/1416411:31
ogra(seems npm doesnt pick up the proxy settings on the lp builders)11:31
cjwatsonogra: That just means some bit of their build system is ignoring the configured proxy11:36
ograah, so its an electron-packager bug then11:36
cjwatsonNot specifically npm - you can see that registry.npmjs.org requests are working just fine and getting 200 responses11:37
cjwatsonIt'll be some random node module's postinstall script probably11:37
cjwatsonMaybe electron-packager, I'm not sure11:37
cjwatsonI'll respond on the forum11:38
ograthanks !11:38
popeymbriza: hiya.11:44
mbrizapopey: hi! i'm getting the 'system does not fully support snapd: cannot mount squashfs image using "squashfs": mount' error11:46
popeyWhat OS?11:46
mbrizabut i can't find the reason it's failing actually, there's just about 5 different possible reasons listed in the error message11:46
mbrizafedora 3111:46
mbrizais there a verbose mode or something11:47
popeythere is SNAPD_DEBUG=1 and SNAPD_DEBUG_HTTP=7 for debugging store conversations.11:48
popeysystemd.setenv=SNAPD_DEBUG=1  might do it?11:49
ograwell ... does that kernel actually have squashfs support ? (grep squash /proc/filesystems)11:50
mbrizaogra: yes, i googled it for a bit and i made sure squashfs and loop devices are available11:51
ograalso, does it support loop devices ... (ls /dev/loop-control ... or ls /dev/loop*)11:52
ograah, snap :)11:52
mbrizapopey: https://paste.centos.org/view/0919773d this is the output when running install with SNAPD_DEBUG=111:53
mbrizai also added it to the snapd service and restarted it but there doesn't seem to be anything very interesting in the journal11:53
popeyok, so you can ignore the reexec issue11:53
mbrizai'm also running with selinux in permissive mode to be sure11:54
popeyare you able to manually mount a random squashfs file? (like your own home-created snap)?11:54
ogradid you try to manually mount a snap ?11:54
popeyyou type too slow :)11:54
* ogra shuts up now11:54
mbrizayes, i can11:55
popeywhich instructions are you using to install snapd?11:56
popeyoh, also `snap version`?11:56
mbrizasnap    2.42.1-1.fc3111:56
popeyok, installing fedora 31 on my big machine to test11:57
mbrizai had a completely different set of issues on my f31 machine on friday though... i was at least able to install snaps :D11:57
mbrizathis is a different machine11:58
popeyyeah, very odd11:59
popeywell, virtualbox is broken for me on 19.10, so that stops that. Bah11:59
ograi thought you said you'D install on your BIG computer ! https://pl.wikipedia.org/wiki/Cray_X-MP#/media/Plik:EPFL_CRAY-I_1.jpg12:00
popeymbriza: what version of snapcraft built the snap you're having trouble with?12:00
popeynot that big, but it's heavy :)12:00
mbrizapopey: i can't install any snap12:00
popeynot even "snap install hello-world"12:01
popeyhttps://www.entroware.com/store/athena  - big machine :D12:01
popeyok, this is more serious. Do you have a funky kernel, or a stock Fedora supplied one?12:01
ograpopey, yeah, but it has a keyboard on the seat !12:02
mbrizanothing funky, not even closed source graphics drivers or anything12:02
mbrizai just updated the machine this morning12:02
ogrado you know what exactly got updated ?12:02
ogra(and did it work at any point in time on that machine)12:03
mbrizabasically 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 past12:03
mbrizai think i removed it either because of a package conflict between upgrades (i upgrade rather soon in the fedora devel cycle) or disk space12:04
popeyLooks 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:06
mbrizanp, i'll just lurk here or on the forums to work this out12:07
popeyactually, i can install clean on my x220. will do that from a usb key.12:07
mbrizaanyway, there's nothing too funky about neither of my systems, i think i'm fairly capable of keeping the system in a workable state12:07
mbrizaare there any conflicts with virtual machines or something like that?12:08
mbrizai'm running something in qemu-kvm most of the time12:08
popeyno, I run in all manner of distros in vm's all the time12:09
Chipacambriza: I'm sorry if you already answered this: can you mount a snap by hand?12:10
mbrizaChipaca: i can12:10
Chipacambriza: what does dmesg say when you do?12:11
mbrizaChipaca: [ 2973.344224] SELinux: security_context_str_to_sid(system_u:object_r:snappy_snap_t:s0) failed for (dev loop1, type squashfs) errno=-2212:11
mbrizabut i'm in permissive mode12:11
mbrizathe 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 side12:12
Chipacambriza: mount is very vague with its errors12:12
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
Chipacambriza: which is why that check exists in the first place (getting that vague an error during install is even worse012:13
Chipacambriza: are you also able to mount a snap by hand if you put that snap in /tmp ?12:14
Chipacapopey: which error about re-exec not working?12:14
mbrizaChipaca: yes12:14
popeythat's mbriza's output12:14
popey(I am still confused why you're getting a _multi_ snap)12:15
popeyit should be amd64 for your machine. Must be erroneous binaries in there somehow12:15
Chipacapopey: you get multi when you have architectures: [amd64,i386], don't you12:15
mbrizai can fetch the other one but both of them worked on the laptop12:15
mbrizaand both of the machines are amd6412:15
Chipacapopey: and you'd have that architectures when it was i386 binaries for example12:15
mbrizaand then again, this is failing even when i try to install hello-snap from the store12:16
Chipacambriza: that error you get is not about the snap12:17
Chipacambriza: that error is from a sanity check performed before any operation is attempted12:17
Chipacambriza: did you go into permissive mode after starting snapd?12:17
mbrizai restarted snapd multiple times in the meantime12:17
Chipacambriza: 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
Chipacambriza: and that is failing, with the error from mount as reported to you12:19
Chipacaoh, oh12:20
Chipacaalso maybe in selinux systems there's a context= appended?12:20
Chipacambriza: I don't know selinux enough to know what context that is12:21
Chipacamaybe mborzecki knows12:21
mbrizait's trying to access a file called 'snap-failure'12:21
popeyHow ironic :)12:22
mbrizawhich is i guess an error reporter?12:22
Chipacathat's a thing you don't need to worry about :-)12:22
Chipacait's an auto-reverter for snapd12:22
Chipacafor (core, or) systems with reexec12:23
ograis 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
mbrizathere 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 relevant12:24
mbrizaogra: 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 it12:25
Chipacambriza: 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 permissive12:25
Chipacambriza: but I know nothing about selinux :) so it's a question for mborzecki12:25
mbrizaChipaca: i can run in enforcing if that's a problem12:25
mbrizastill the same error12:26
Chipacambriza: if you add -o context=<gibberish> to the mount of the .snap, does it still work?12:26
Chipacathat was really quick for enabling enforcing + restarting snapd + trying to install something12:26
mbrizaChipaca: the daemon is not really running, it's systemd socket-activated12:27
mbrizaanyway, with gibberish in the mount command i'm getting the same error as above12:27
mborzeckimbriza: hm what about selinux?12:30
pstolowskiogra: 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 interface12:30
pstolowskiogra: i'm on 19.1012:30
mbrizamborzecki: 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` fails12:31
mbrizanot even sure if it's related to systemd, it fails regardless of running in permissive/enforcing mode12:31
pstolowskiogra: i suspect something got stale on your box but it's unclear how. your state.json looks sane, it doesn't have system-files connection12:32
mbrizaerr i mean selinux12:32
mborzeckimbriza: reading backlog, looks like snappy_snap_t isn't defined? that'd be weird it's part of the policy shipped with the pacakge12:32
pstolowskiogra: is your first box still in this state (e.g. the snap with layout succesfully installed)?12:33
mborzeckimbriza: that's 31 right?12:33
mbrizamborzecki: yes12:33
mborzeckimbriza: ok, let me check rawhide first12:33
ograpstolowski, i'm on 16.04 here and i think the machine is still in that state ...12:35
pstolowskiogra: good. could you get me /var/lib/snapd/apparmor/profiles/snap.logsync-james.upload profile?12:37
mbrizamborzecki: just reinstalled the snap packages and rebooted to be extra sure everything is up to date but install is still failing12:40
mborzeckimbriza: same thing in dmesg as you posted before?12:40
ograpstolowski, just to prove it still works ... https://paste.ubuntu.com/p/7vtsXM3Kvm/ ...  one sec, getting the file12:41
ograpstolowski, and the apparmor profile ... http://paste.ubuntu.com/p/gz5DfScfQ7/12:42
pstolowskiogra: did you use --devmode or try at any point?12:42
ograonly 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 layout12:44
=== ricab is now known as ricab|lunch
pstolowskiogra: 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 profile12:44
mupPR 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:44
pstolowskiit's weird it didn't complain12:45
ograright ...12:45
ograit complains if i copy the snap to another machine (also 16.04)12:45
pstolowskiogra: yep, got it. interesting. ok, i think i need to look at different place in the code now.. thanks12:46
ograshould oh also ...12:46
ograogra@anubis:~/datengrab/logsync:master$ sudo snap remove --purge logsync-james12:47
ogralogsync-james removed12:47
ograogra@anubis:~/datengrab/logsync:master$ cat /etc/systemd/journal-upload.conf12:47
ograshouldnt the file be removed whan the snap gets purged ?12:47
mborzeckimbriza: installing core snap12:50
pstolowskiogra: --purge is only for avoiding automatic snapshots, nothing else12:51
ograwell, yeah ... but remove should remove the file, or not ?12:51
mborzeckimbriza: and it installed fine, ok, so we need to debug your system12:52
mborzeckimbriza: anything useful ausearch -m AVC ?12:52
ograi.e. i dnot think a layouted file should stay behind when removing the snap that used the layout12:52
ograthat will result in all kinds of cruft after a while12:53
ogra(at least in the case where the layout actually created the file from scratch)12:53
pstolowskiogra: yes i think you're right, i'm not sure why layout isn't cleaning after itself12:54
mborzeckimbriza: while at it, does seinfo -t |grep snappy_snap_t list anything?12:54
pstolowskiogra: something for zyga (maybe there was a reason it's like that)12:55
mbrizamborzecki: ausearch doesn't report anything new when running sudo snap install hello-world12:56
mbrizamborzecki: snappy_snap_t is not present in the output of seinfo .-t12:56
pstolowskiogra: one more question.. on the misbehaving box, is snapd at the current stable version?12:57
pstolowskiogra: same version of snapd on both boxes?12:57
mborzeckimbriza: rpm -q snapd-selinux show anything?12:57
ograogra@anubis:~/datengrab/logsync:master$ snap version12:57
ograsnap    2.42.112:57
ograsnapd   2.42.112:57
ograseries  1612:57
ograubuntu  16.0412:57
ograkernel  4.4.0-141-generic12:57
ograkernel is a bit behind ... but the rest should be recent12:57
ograthe other box uses the hwe kernel but beyond this the same versions12:58
mbrizamborzecki: snapd-selinux-2.42.1-1.fc31.noarch12:58
mbrizamborzecki: there's this line in the journal though12:58
mbrizamborzecki: 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
mborzeckimbriza: seinfo -t snappy_home_t ?12:58
mbrizamborzecki: Types: 012:59
ograpstolowski, the main difference is that the system-files interface was never connected on the box that behaves correct12:59
ogra(well, i also have never used --devmode with this snap on the behaving machine)12:59
mbrizamborzecki: https://paste.centos.org/view/e51f0cc4 this is in the journal too13:00
popeyfwiw, i just installed f31, and updated it to latest, and can install and run snaps fine13:00
mborzeck1wow, my really sucks today13:01
mbrizamborzeck1: https://paste.centos.org/view/e51f0cc4 this is in the journal too13:02
mbrizamborzeck1: also as for the output for seinfo-t snappy_home_t, it was Types: 013:02
mborzeck1mbriza: right, so looks like the policy wasn't loaded for some reason13:02
mborzeck1mbriza: ok, can you try dnf history list snapd-selinux and then dnf history info <id> ?13:03
=== mborzeck1 is now known as mborzecki
mbrizamborzecki: there's this little line in there, yes:13:05
mbrizamborzecki:   16 /usr/sbin/semodule:  Failed on /usr/share/selinux/packages/snappy.pp.bz2!13:05
mbrizamborzecki: and i get the same error when trying to reinstall the package13:05
mborzeckimbriza: yeah, i suppose if you do semodule -l |grep snappy there'll be nothing listed there13:06
mbrizamborzecki: semodule -l doesn't even start13:06
mbrizalibsemanage.semanage_direct_get_module_info: Unable to read flatpak module lang ext file. (No such file or directory).13:06
mbrizanow this is not related to snappy at all13:07
mborzeckimbriza: hm, did you upgrade 30 -> 31?13:07
mbrizadnf reinstall *selinux*13:07
mborzeckimbriza: did you do distro-sync afterwards?13:07
mbrizamborzecki: i'm distro-syncing all the time13:08
pstolowskiogra: ok, i know what's going on and why it didn't work on second box13:08
mborzeckimbriza: tried with --allowerasing?13:08
mborzeckimbriza: btw. you need to use sudo/su to run semodule13:09
mbrizayeah, of course... seems there's something wrong about my selinux policies though13:09
pstolowskiogra: 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 iy13:09
ograyay, thanks13:10
mborzeckimbriza: can you post the output of sestatus somewhere?13:10
ograso let me remoe that file ... to prove it ;)13:10
mbrizamborzecki: https://paste.centos.org/view/2e2c930d13:10
ograogra@anubis:~/datengrab/logsync:master$ sudo snap install --dangerous logsync-james_0.2_amd64.snap13:11
ograerror: cannot perform the following tasks:13:11
ogra- Run configure hook of "logsync-james" snap if present (run hook "configure":13:11
ogracannot update snap namespace: cannot write to "/etc/systemd/journal-upload.conf" because it would affect the host in "/etc/systemd"13:11
ograsnap-update-ns failed with code 1: File exists13:11
ograyay !13:11
ograyup ... touching the file before snap install then makes it work again13:12
mborzeckimbriza: doesn't feel like it's related to snapd policy in particular13:14
mbrizamborzecki: yeah, definitely somewhere else, thank you for helping me debug this13:14
mbrizaand to the rest of the channel, too :)13:14
mborzeckimbriza: last thing, can you try installing flatpak-selinux, and see if it works?13:14
mborzeckimbriza: they also ship the policy in a separate module13:14
mbrizamborzecki: i have it but it (and mysql, too) complains13:16
pstolowskiogra: good, thanks for confirming13:16
mbriza... even after reinstalling13:16
zygaogra: it is a bug13:16
zygaTrespassing should never surface as an error13:16
mborzeckimbriza: yeah, i'd try checking in #fedora-devel, and maybe trying .autorelabel too13:17
zygaIt is a duplicate of another bug on launchpad already13:17
ograzyga, yeah, after two days cuddling with it i guessed that much :)13:17
zygaGive us some time, we have a plan that fixes a large class of those issues13:17
ograyeah, no worries, i'm surely not in a hurry ... just ran into it and found it weird13:18
ograpstolowski, 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:19
ogra(iirc you initially implemented it)13:20
Chipacaogra: listen-stream: <the path to a socket>13:21
ograChipaca, uhm, so network sockets got removed ?13:22
ograhttps://snapcraft.io/docs/snapcraft-yaml-reference thinks <port> is a valid thing13:23
mbrizamborzecki: ha, after deleting the lang files in /var/lib/selinux/targeted/active/modules/200 and reinstalling the packages, i'm able to install snaps again13:26
mbrizathank you!13:26
mborzeckimbriza: does it still work when you reboot?13:27
mbrizai just reinstalled everything with 'selinux' in its name and there were no errors so i assume it'll be fine13:28
mbrizaalso my app actually starts on this machine when installed from snap13:29
pstolowskiogra: i quickly grepped the code and we have tests for listen-stream: <an integer>; should work. not sure why snapcraft rejects it13:29
mborzeckimbriza: hah, that's a good sign ;)13:30
b_bis there a problem with latest stable base core18 ?13:31
ograpstolowski, hmm, well, then it is most likely a snapcraft bug with the yaml parser ...13:31
b_bi'm getting error about this one since yesterday13:31
b_berror: unable to contact snap store13:31
b_bAn 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 snapcraft13:31
ograIssues 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
ograthats what i guess13:31
pstolowskizyga: 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't13:31
b_bi've tried to clean all mutipass vms, and launched a clean snapcraft, no luck13:32
ograaha ... https://bugs.launchpad.net/snapd/+bug/161244013:34
mupBug #1612440: Full systemd socket activation support <lxd> <Snapcraft:New> <snapd:Fix Released> <https://launchpad.net/bugs/1612440>13:34
ogralooks like the snapd task is fix-released but the snapcaft one is still new13:34
mborzeckicachio is off today, isn't he?13:36
zygahey hey13:39
zygapstolowski: it's a bug, it's actually diagnosed already AFAIK13:39
zygapstolowski: yes but $COMPLEXITY13:39
zygapstolowski: it's not what it seems at first13:39
zygaogra: did you report a bug for this?13:40
zygaogra: it would help with tracking13:40
ograzyga, nope, not yet13:40
zygaogra: no rush as I'm a zombie today13:40
zygabut please do later on13:40
ogra(it isnt only complex to splve, but also complex to explain :P )13:40
ograok, will do13:40
zygathank you13:41
zygaI feel terrible today13:41
ogramust be the maple syrup withdrawal :)13:42
mvozyga: yeah, its not a great day13:42
zygamvo: I was sleeping between 8 and 1PM13:42
mvozyga: uh, woah13:42
mvoI had a "short" nap in the morning of 2h, but I was already working at 4:30 or so (yay jetlag)13:43
Chipacamborzecki: next week13:49
=== ricab|lunch is now known as ricab
b_bweird, i can't get rid of this mutlipass error14:38
b_bsudo -i env SNAPCRAFT_HAS_TTY=True snap install --channel stable core18' with 'multipass': returned exit code 114:39
b_bsnap info core18 shows me than the stable channel have a different date than the others14:39
oSoMoNijohnson, it looks like https://github.com/snapcore/snapd/pull/7731 is good to go now (tests passed), can it be merged?15:32
mupPR #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:32
b_bsee u ++15:37
pstolowskihttps://github.com/snapcore/snapd/pull/7727 needs 2nd review15:39
mupPR #7727: tests: improve TestDoPrereqRetryWhenBaseInFlight to fix occasional flakiness <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7727>15:39
mupPR snapcraft#2804 opened: conda plugin: simplify source url/checksum handling <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2804>16:11
=== pstolowski is now known as pstolowski|afk
zygagosh, "ethics and code of conduct" is a long one17:04
mupPR 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:00
mupPR snapd#7747 opened: gadget: skip fakeroot if not needed <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7747>18:15
Chipacazyga: looooooong18:20
Chipacazyga: nominally 30-60mins but took me just under 2h18:20
Chipacaalthough it wasn't interruption-free18:21
zygaChipaca: lol, "Resisting taking vacation time – fraud is often discovered while an employee is gone"19:06
zygaChipaca: I wonder when people will start to incorporate remote workers into generic training material19:07
zygaI feel like a woman may have felt a few decades ago19:07
mupPR snapcraft#2805 opened: plugins: address type errors for mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2805>19:51
mupPR snapcraft#2806 opened: cli: address type errors for mypy uprev  <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2806>20:09
mupPR snapd#7748 opened: overlord: fix the get command help message <Simple πŸ˜ƒ> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7748>20:50
jkridnerogra: I see you made an mjpg-streamer snap. have you thought about making one that includes the opencv filter features?21:07
jkridnerhmmm... 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:17
jkridnerah, https://github.com/ogra1/mjpg-streamer/blob/master/snap/snapcraft.yaml#L1221:18
mupPR snapcraft#2807 opened: meta: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2807>21:51
mupPR snapcraft#2808 opened: repo: fix fetch_binary()'s return type for deb repo <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2808>22:42

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!