=== harrisj_ is now known as harrisj
[07:38] <pedronis> mvo: hi, you did a full pass on 7020 now?  I will address comments today or tomorrow
[07:42] <mvo> pedronis: yes
[09:22] <ackk> hi, we (maas) currently have some scripts that scan /sys to find info about the system (both ardware and configuration/modules/...). this currently doesn't work in the snap, it doesn't seem there is an interfaces that lets you read the whole /sys. Would it be possible to do that?
[09:24] <sparkiegeek> to add some flavour, and as a non-exhaustive example; we currently have `find /sys/devices/ -name sriov_numvfs`
[09:28] <ackk> sparkiegeek, that does't actually cause errors AFAICT, the main one that's failing is  'find /sys -name modalias'
[09:28] <ackk> but also we're using lshw/lscpu/lsusb/... and those don't work
[09:49] <sparkiegeek> pedronis: ^ thoughts?
[09:49] <Chipaca> doesn't hardware-observe give you those?
[09:50] <Chipaca> ackk, sparkiegeek?
[09:50] <ackk> Chipaca, so, for the find -name modalias I can see the files but the whole /sys is nobody:nogroup so I can't read them as root
[09:51] <ackk> Chipaca, https://paste.ubuntu.com/p/mkQprpncMQ/
[09:51] <ackk> (I assume that's the issue, at least)
[09:52] <ackk> Chipaca, (that snap does have hardware-observe connected)
[09:52] <Chipaca> why's it getting nobody'd?
[09:52] <Chipaca> it's root:root outside
[09:52] <Chipaca> on 1604 at least
[09:52] <Chipaca> it's root:root inside as well, in 1604
[09:54] <ackk> Chipaca, I wonder if it's because I'm using the daemon-enabled snapd from jdstrand?
[09:54] <Chipaca> ackk: is it also nobody:nogroup outside on the system you're looking at?
[09:54] <ackk> Chipaca, oh, it is
[09:54] <ackk> wth
[09:54] <ackk> (I'm in a lxd)
[09:55]  * ackk tries rebooting 
[09:55] <ackk> nope, also /dev files are nobody:nogroup
[09:56] <ackk> somethin is messed up here, I guess
[09:56] <pedronis> Chipaca: thanks for the review
[09:56] <Chipaca> pedronis: thanks for the code
[09:56] <Chipaca> pedronis: what do you mean in https://github.com/snapcore/snapd/pull/7083#issuecomment-511885260 ?
[09:56] <jibel> Hi, I just reported https://forum.snapcraft.io/t/cannot-launch-snaps-on-eoan/12341, is it known?
[09:57] <pedronis> Chipaca: mvo is looking into that. Now that what we check is the type, we need to make there's only one snap installed with that type (and called snapd)
[09:57] <pedronis> same logic we have/ad for core
[09:57] <pedronis> *make sure
[09:57] <pedronis> *have/had
[09:59] <Chipaca> easy way would be to enforce the name in install
[09:59] <Chipaca> ¯\_(ツ)_/¯
[10:00] <Chipaca> jibel: I don't know if it's known. I've asked for more info. Please do use preformatted-text for the output of commands (i've edited your post)
[10:02] <pedronis> Chipaca: that's what the check does
[10:03] <Chipaca> pedronis: :)
[10:03] <pedronis> I mean coreNameCheck is that check for core
[10:03] <jibel> Chipaca, done.
[10:04] <Chipaca> jibel: something is very broken
[10:04] <jibel> indeed :)
[10:05] <Chipaca> jibel: was there a new systemd since you booted last
[10:05] <Chipaca> I seem to remember somebody saying something about the latest systemd + kernel combo breaking mounts
[10:05] <Chipaca> not sure that was in eoan though, might've been fedora
[10:09] <jibel> Chipaca, list of updates before last reboot https://paste.ubuntu.com/p/wSvJmy4r3w/. There is no update of systemd
[10:11] <Chipaca> jibel: what do you get from zgrep systemd.*running.in.system.mode /var/log/syslog* ?
[10:11] <pedronis> Chipaca: it was arch, https://forum.snapcraft.io/t/snap-mounts-broken-with-kernel-5-2-and-systemd-242/12272
[10:11] <Chipaca> (hoping that still works in eoan)
[10:12] <Chipaca> things we should add to 'snap version': systemd version, and machine architecture
[10:13] <jibel> Chipaca, nothing, just very old stuff
[10:13] <Chipaca> jibel: what systemd version are you on _now_?
[10:13] <jibel> Chipaca, 240-6ubuntu9
[10:14] <Chipaca> jibel: it does look very similar to the thing on arch, but the systemd version is older so i dunno
[10:14] <Chipaca> maybe the problem is linux 5.2
[10:15] <jibel> I can boot on previous kernel
[10:15] <Chipaca> jibel: systemctl --all --failed |grep snapd
[10:15] <Chipaca> plz
[10:16] <jibel> Chipaca, nothing if I grep snapd however if I grep snap I get https://paste.ubuntu.com/p/hdr5qKQrh7/
[10:16]  * jibel reboots brb
[10:17] <Chipaca> yeah that's bad
[10:23] <jibel> Chipaca, it works with 5.0 and it's broken with 5.2
[10:23] <Chipaca> huzzah
[10:24]  * Chipaca hugs his 1604 to his chest
[10:24] <Chipaca> jibel: please add that to the forum topic
[10:24] <jibel> I did it
[10:25] <Chipaca> jibel: awesom
[10:25] <Chipaca> jibel: I've linked to your topic from the arch one
[10:25] <Chipaca> jibel: can you work with somebody from the kernel team to bisect this?
[10:26] <jibel> sure
[10:26]  * jibel moves -> #ubuntu-kernel
[10:29] <Chipaca> jibel: thank you!
[10:29]  * Chipaca hops on to that # also, out of curiosity
[10:40]  * Chipaca breaks a take
[11:19] <ogra> sil2100, hey ho, do you know if the CM3+ fix also made it into the classic images (if not, what does it take to update their FW ?)
[11:23] <sil2100> ogra: hey, it did, but only for disco and eoan, we didn't SRU it to bionic yet
[11:23] <ogra> sil2100, i assume thats planned ?
[11:24] <sil2100> It might be a good idea, but I don't think we explicitly talked about it - might be that we'd want that before the point release
[11:24] <sil2100> I'll poke Dave today
[11:24] <ogra> thanks !
=== ricab is now known as ricab|lunch
[12:00] <ackk> jdstrand, hi, fwiw instructions on  https://people.canonical.com/~jamie/snapd-daemon-user/README don't seem to work anymore for me. the test snap doesn't work, but my maas snap does. also the reported version is 2.39.3
[12:06] <pedronis> mvo: I did a pass over 7107, there's more work needed
[12:16] <ackk> Chipaca, fwiw https://paste.ubuntu.com/p/jKyKBmT4Jc/ is what I see
[12:19] <ackk> that's probably still ok since I think we could just search for modalias under /sys/devices
[12:19] <ackk> but not entirely sure
[12:40]  * diddledan pops it in here too for people to have a nosey: https://sc-jsonnet.readthedocs.io/
[12:40] <diddledan> err
[12:40] <diddledan> wrong url
[12:40] <diddledan> https://forum.snapcraft.io/t/yaml-code-sharing-and-reuse/12342
[12:40] <diddledan> (it was a related url anyway, but I wanted to share my forum post)
[12:43] <Chipaca> jibel: out of curiosity, what's 'snap list --all | wc -l' for you?
[12:44] <Chipaca> with 20+ snaps installed, on 5.2.x, with systemd 240, can't repro the issue
[12:55] <jibel> Chipaca, 22
[12:55] <jibel> Chipaca, 41
[12:55] <Chipaca> ah
[12:55] <Chipaca> small difference :)
[12:56] <jibel> Chipaca, https://paste.ubuntu.com/p/RnkKVNStZX/
[12:56] <Chipaca> ok, i'll ramp things up to that level and see
=== JanC is now known as Guest31310
[13:12] <Chipaca> yess
[13:12] <Chipaca> at 42 snaps installed, i got a broken mount
[13:12] <diddledan> nobody needs more than 42 - that's the perfect number
[13:12]  * roadmr hands 42 bytes of RAM to diddledan
[13:12] <roadmr> ah, snaps - sorry, was missing context :)
[13:12] <diddledan> hmm
[13:13] <diddledan> :-p
[13:13] <roadmr> yes, 42 is ideal
=== ricab|lunch is now known as ricab
=== JanC_ is now known as JanC
[13:28]  * dot-tobias says hi
[13:32] <sparkiegeek> diddledan: https://en.wikipedia.org/wiki/Perfect_number no it's not! :P
[13:34] <ackk> https://youtu.be/RyFr279K9TE?t=33
[13:35] <dot-tobias> zyga: I'm suddenly getting store rejections from failed layout target lintings. The previous revisions went through review just fine, I was mapping $SNAP/some/path to $SNAP_DATA/some/path. Is this expected?
[13:51] <Chipaca> YESSS i can reproduce the issue without snaps
[13:51] <Chipaca> wooo woo wo w
[13:52]  * Chipaca goes to sell it on the black market
[13:54] <diddledan> is it a kernel bug?
[13:55] <Chipaca> no, it's...
[13:55] <Chipaca> Mail server hit by UniSpammer.
[13:55] <Chipaca> no wait, it's
[13:55] <Chipaca> The file system is full of it
[13:55]  * Chipaca puts away the BOFH snap before it does any real harm
[13:56] <mvo> Chipaca: \o/
[13:57] <mvo> Chipaca: where can I read more? bugrport? forum?
[13:57] <Chipaca> mvo: i'm in the progress of writing the reproducer into a script, and then will add it to the forum, and then a bug
[13:57] <Chipaca> mvo: i'll let you know when it's a script you can run :-)
[13:58] <mvo> Chipaca: thank you!
[14:00] <seb128> mvo, Chipaca, is there any workaround atm? Till was asking because he uses chromium as his browser which was made into a snap by defualt in eoan and he's without a working webbrowser now which is a bit of an issue for work
[14:00] <jibel> boot with kernel 5.0
[14:01] <diddledan> eep
[14:04] <Chipaca> mvo: https://paste.ubuntu.com/p/VCpzGxvy6h/
[14:05] <Chipaca> seb128: snap list --all, for any broken snaps, if disabled remove, if enabled (== current) disable and enable
[14:05] <Chipaca> seb128: but beware dependencies
[14:06] <diddledan> worth checking if earlier systems have any problems running that reproducer, too
[14:06] <Chipaca> seb128: not sure if the bug is in the kernel or in util-linux, but it's in one of them two
[14:06] <Chipaca> so it could be a lot worse
[14:09] <dot-tobias> I'm trying to define a content interface for my snaps. Upon installation, I get this error: “INFO snap <snap-name> has bad plugs or slots: my-slot-name (unknown interface "my-slot-name")” I gathered from https://docs.snapcraft.io/content-interface that the slot name can be arbitrary?
[14:10] <diddledan> dot-tobias: you need to do two things: add a top-level slots: block which defines your slot, and then an app-level slots: block that ties your slot name to an app
[14:14] <dot-tobias> diddledan: Ok, thanks. Do you happen to have an example how the app-level stanza looks like? Just slots: [my-slot-name]?
[14:19] <Chipaca> #1836914
[14:19] <dot-tobias> diddledan: Hm, followed this example https://github.com/anbox/anbox/blob/cd829e9ccd3a5d654c8aa5e16e32f0d3915d54a8/snap/snapcraft.yaml#L34 but still getting the same error.
[14:27] <seb128> Chipaca, thx
[14:28] <diddledan> dot-tobias: did you also add the top-level item? https://github.com/anbox/anbox/blob/cd829e9ccd3a5d654c8aa5e16e32f0d3915d54a8/snap/snapcraft.yaml#L18
[14:47] <ijohnson> is there a clean way to do a type assertion with go-check? I want to check that an error is of a certain type
[14:48] <diddledan> ijohnson: https://tour.golang.org/methods/15?
[14:48] <ijohnson> diddledan: specifically with the go-check package: https://godoc.org/gopkg.in/check.v1
[14:48] <pedronis> ijohnson: look for FitsTypeOf
[14:49] <ijohnson> pedronis: ah perfect thanks
[14:49]  * diddledan goes back to lurkioing
[14:49]  * Chipaca would like FitsTypeOf to raise a TooLarge error :-p
[14:49] <ijohnson> pedronis: I was going to break out a small PR from netplan apply to make it easy to create hidden commands in snapctl
[14:50] <diddledan> Chipaca: what about returning Almost?
[14:50] <pedronis> ijohnson: sounds good
[14:50] <Chipaca> diddledan: you get it :)
[14:50] <diddledan> TryHarer?
[14:50] <diddledan> TryHarder**
[14:50] <Chipaca> MoreLubricant
[14:50] <Chipaca> GetAHammer
[14:50] <diddledan> haha
[14:50] <pedronis> ijohnson: otherwise of course you can also use a go type assertion, _, ok := x.(T) and check for ok
[14:51] <pedronis> depends a bit exactly what you need
[14:51] <diddledan> or IGuessItWorks
[14:51] <ijohnson> yeah I was hoping there was a go-check thing to use, and there is so that seems more "idiomatic snapd tests"
[14:52] <pedronis> yes
[14:57] <ackk> sergiusens, hi, around?
[15:03] <pedronis> ijohnson: forgot to mention, have you looked how adding hidden commands works in cmd/snap, we probably want the same
[15:03] <pedronis> or sameish
[15:04] <ijohnson> pedronis: I did not, is it different than using go-flags Command.Hidden flag?
[15:04] <pedronis> it's the same
[15:04] <pedronis> but there's a pattern there
[15:04] <pedronis> please look :)
[15:04] <ijohnson> sure, is there a hidden command off the top of your head you could point me to?
[15:05] <pedronis> ijohnson: interfaces nowadays
[15:06] <ijohnson> pedronis: ack, this actually looks very similar to what I have now
[16:18] <sergiusens> ackk: nope, travelling and packing with the family today
[16:19] <ackk> sergiusens, ah cool, enjoy then
[16:21] <pedronis> mvo: thanks for adding checkSnapdName. I reviewed 7086 , just one odd thing there (cc Chipaca)
[16:21] <pedronis> oops, I meant 7084
[16:21] <pedronis> heh, fail
[16:22] <pedronis> mvo: Chipaca: I meant actually really 7083 (3/4)
[16:22] <mvo> pedronis: no worries, I will check the feedback (either today or tomorrow morning)
[16:22] <pedronis> thx, I can tweak as well tomorrow if nobody gets to it before
[16:22]  * pedronis going to eod
[16:33] <pedronis> Chipaca: https://forum.snapcraft.io/t/snap-layouts/7207/21 this looks like it should be its own topic
[16:33] <pedronis> (it's not about the docs but a issue of usage/review tools)
[17:12] <ijohnson> pedronis: fyi I filed to do hidden snapctl cmds in https://github.com/snapcore/snapd/pull/7119
[17:13] <ijohnson> pedronis: I'm now working on another PR for passing through the exit code, etc. from the snapd daemon to the snapctl client as requested
[17:13] <ijohnson> may or may not get that PR finished today
[17:42] <pedronis> ijohnson: thx
[17:46] <jdstrand> ackk: ok, I needed to modify test-snapd-daemon-user and made it not work with the deb I gave you. let me update the deb and README
[17:52] <ackk> jdstrand, thanks!
[18:13] <jdstrand> ackk: ok, new deb and updated README are uploaded
[18:13] <jdstrand> ackk: you'll need to use 'system-usernames: [ snap_daemon ]' in your snap now after all
[18:14] <jdstrand> ackk: 'system-usernames' is subject to change still (should have a decision tomorrow), but 'snap_daemon' shouldn't change
[18:15] <jdstrand> (and it may not be a list, but the yaml is the easy part, you can be reasonably confident that changing the rest of your snap to use 'snap_daemon' will mean you're ready when the feature lands
[18:15] <jdstrand> )
[19:32] <jdstrand> roadmr: hey, I know this was a quick one, but can you pull 20190717-1931UTC?
[19:38] <roadmr> jdstrand: oh hehe :) sure
[20:38] <jdstrand> roadmr: thanks! :)
[21:51] <ackk> jdstrand, thanks!
[21:54] <diddledan> wanna see some voodoo? https://forum.snapcraft.io/t/yaml-code-sharing-and-reuse/12342