[05:29] <dot-tobias> mvo: re saveenv issue (had to leave early yesterday, right after filing this): https://bugs.launchpad.net/snap-core18/+bug/1910094 → for uc20, uboot.env.in was removed in favor of u-boot-pi, so idk if this also applies for uc20.
[05:29] <mup> Bug #1910094: uboot fails to save env after core18 refresh <snap-core18:New> <https://launchpad.net/bugs/1910094>
[07:05] <mborzecki> morning
[07:07] <mup> PR snapd#9811 closed: tests: fix library path used for tests.pkgs <Simple 😃> <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9811>
[07:32] <mup> PR snapd#9808 closed: tests/main/snap-validate-basic: disable test on Fedora due to go-flags panics <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9808>
[07:33] <dot-tobias> morning mborzecki 👋
[07:34] <mborzecki> dot-tobias: hey
[07:39] <mborzecki> zyga: mvo: hey
[07:39] <zyga> good morning guys :)
[07:39] <mvo> good morning mborzecki and zyga
[07:50] <mborzecki> mvo: zyga: have i shared those over the holiday break? https://imgur.com/a/zddivon
[07:51] <zyga> yes, you did
[07:51] <zyga> the spike of mystery
[07:51] <mvo> mborzecki: I remember this one - wasn't the spike apparmor_parser running?
[07:52] <mborzecki> mvo: yes, the bottom two are apparmor_parser replaced with symlink to /bin/true, and the last one is both aa parser and snap-seccomp
[07:54] <mborzecki> mvo: zyga: added one more graph from just calling apparmor_parser -R for snap.hello-world profiles followed by apparmor_parser --replace <opts-we-use-in-snapd> /var/lib/snapd/apparmor/profiles/snap.hello-world.*
[07:56] <mvo> mborzecki: 50mb is a lot
[07:56] <mborzecki> not skipping cache makes the memory usage lower ofc, but iirc zyga explained there was a corner case when the timestamps are messed up or something and that breaks things
[07:56] <mvo> mborzecki: in this last graph, especially since hello-world is presumably a simple profile
[07:56] <mborzecki> mvo: well, it isn't that simple ;)
[07:57] <mborzecki> mvo: there's a lot of rules, and i wanted to try exploding rules such as `/{,usr/}bin/arch ixr` to see if that changes anything
[08:02] <mvo> mborzecki: oh, interessting
[08:02] <mup> PR snapd#9794 closed: daemon: start moving implementation to api_snaps.go <Cleanup :broom:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9794>
[08:03] <zyga> mborzecki, IIRC early pi boot sceniario
[08:03] <zyga> mborzecki, across rollback or something
[08:03] <zyga> mborzecki, we would reuse stale cache
[08:03] <zyga> mborzecki, in the end cache is still mtime based
[08:03] <zyga> mborzecki, this change came from jdstrand (IIRC, it was >2 years ago)
[08:04] <zyga> offtopic, this is the day when we are setting up mattermost/irc bridge
[08:04] <zyga> did that ever happen to canonical irc?
[08:04] <zyga> er
[08:04] <zyga> canonical mattermost
[08:05] <mborzecki> zyga: idk, i'm using mm chat in ff
[08:06] <zyga> mborzecki, yeah but for internal stuff
[08:06] <zyga> I'm curious to know if there is any channel on mattermost that got bridged to an irc channel
[08:06] <zyga> we're doing that so that the community space is not fractured
[08:16] <mborzecki> mvo: hah, i see your superpowers extend to ogra's repositories too :)
[08:17] <zyga> my new router arrives today, cannot wait to set that up after work
[08:17] <zyga> but now, last day of static analysis wrap up
[08:17] <zyga> o/
[08:17] <jamesh> zyga: I think don't think there is any server side ircd integration.  Some people use matterircd, but that is really a single-user bridge
[08:18] <zyga> jamesh, I think we use matterbridge (or want to)
[08:19] <zyga> but yeah, it looks like a way that's really meant for one user
[08:19] <zyga> we'll see
[08:22] <mvo> mborzecki: yeah, slightly surprised about this but I don't complain
[08:26] <jamesh> zyga: I guess it depends on what your goal is: allow a user to continue using their IRC client, or to bridge to an existing community of people who can't access the Mattermost server?
[08:27] <zyga> jamesh, our mattermost is open to all but we wanted to let people who hang around on IRC to not miss anything, lower barrier of entry
[08:30] <jamesh> zyga: understandable.  I guess that's the reason most public Canonical/Ubuntu stuff is on Freenode
[08:31] <zyga> jamesh, given we also use gitlab, mattermost integrations are valuable
[08:32] <zyga> so if those get to translate to irc, even imperfectly, it would be an added advantage
[08:33] <jamesh> zyga: I kind of wonder if some kind of limited guest account access to mattermost might solve that too.
[08:33] <zyga> jamesh, yeah but again our mattermost is not closed
[08:33] <zyga> it's just something that requires you to have _a_ account
[08:34] <zyga> so we wanted to lower the barrier of entry even more
[08:35] <jamesh> zyga: sure, but presumably I'd still need to create an account to ask a question.  If there was some kind of anonymous guest account system, that could be even more accessible than IRC
[08:35] <zyga> ah, I see what you mean now
[08:36] <zyga> yeah, but I don't know if mattermost supports that kind of thing
[08:37] <jamesh> If you're bridging to IRC, you're essentially allowing anonymous users into those mattermost channels anyway.
[08:37] <zyga> sure, the only question is if there's a better way of doing that
[08:39] <jamesh> zyga: it looks like a feature that is on their radar but unimplemented: https://docs.mattermost.com/overview/faq.html#does-mattermost-have-an-official-website-based-plugin-to-offer-anonymous-chat-to-visitors
[08:48] <mborzecki> mvo: there's a bug in postrm, we have an if that check whether we're running inside the container (closer to the end of the file), and unmounts /snap in such case, however, couple of lines before there's and attempt to rm -rf /snap which fails with EBUSY
[08:48] <mvo> mborzecki: oh, thanks for noticing. is there an easy fix? just reshuffle some lines? also I wonder why we did not find it in spread testing :/
[08:49] <mborzecki> mvo: this bit: https://github.com/snapcore/snapd/blob/master/packaging/ubuntu-16.04/snapd.postrm#L118-L142
[08:49] <mborzecki> mvo: yeah, stgraber pointed me to it in https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1903967 i'm working on a fix and a spread test
[08:49] <mup> Bug #1903967: Can't purge snapd: rm: cannot remove '/snap': Device or resource busy <lxd (Ubuntu):Invalid> <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1903967>
[08:49] <mvo> mborzecki: oh, so the discard lines need to be moved up?
[08:49] <mvo> mborzecki: \o/ thank you!
[08:49] <mborzecki> mvo: afaict none of the spread tests executed apt remove --purge snapd in a container
[08:50] <mvo> mborzecki: *nod*
[09:33] <mborzecki> mvo: https://github.com/snapcore/snapd/pull/9812
[09:33] <mup> PR #9812: packaging/deb, tests/main/lxd-postrm-purge: fix purge inside containers <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9812>
[09:33] <mvo> mborzecki: \o/
[09:33] <mup> PR snapd#9812 opened: packaging/deb, tests/main/lxd-postrm-purge: fix purge inside containers <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9812>
[09:43] <zyga> mborzecki, nice
[09:43] <zyga> mborzecki, 2/3 reviewed, one sec
[09:54] <zyga> mborzecki, reviewed
[09:54] <zyga> coffee and more meetings
[10:26] <zyga> mborzecki, +1
=== msalvatore_ is now known as msalvatore
[12:40] <mborzecki> go-flags feels like a mess tbh
[12:41] <mborzecki> actually validate has --forget option which has no hidden tag, but it does not show up either :/
[12:53] <mborzecki> funny thing, when parser is initialized with HelpFlag, there's no panic, and that's because when the option is present it collects information from all registered 'groups'
=== zyga_ is now known as zyga
[15:15] <mborzecki> the 'fix' in go-flags: https://github.com/jessevdk/go-flags/pull/354
[15:15] <mup> PR jessevdk/go-flags#354: fix a panic when generating help while the subcommand and all option groups are hidden <Created by bboozzoo> <https://github.com/jessevdk/go-flags/pull/354>
[15:30] <mborzecki> off to the the vet with my meowing furball
[16:33]  * cachio lunch
[16:35] <mup> PR snapd#9813 opened: tests: use os-query tool to check debian, trusty and tumbleweed <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9813>
[17:22] <mup> PR snapcraft#3399 closed: cli: do not require snapd deb for assertions <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3399>
[18:06] <ijohnson> cachio: shouldn't this line also check for aarch* for the is_arm function?
[18:06] <ijohnson> https://github.com/sergiocazzolato/snapd/blob/master/tests/lib/tools/os.query#L102
[18:06] <ijohnson> err I guess the right link is https://github.com/snapcore/snapd/blob/master/tests/lib/tools/os.query#L102
[18:12] <cachio> ijohnson, yes
[18:13] <cachio> ijohnson, I think we just have armv7 and armv8
[18:13] <cachio> but the check should be
[18:14] <cachio> uname -m | grep -qx '(^arm.*|^aarch*)'
[18:14] <cachio> ijohnson, right?
[18:17] <ijohnson> cachio: yes exactly
=== ijohnson is now known as ijohnson|lunch
[18:27] <cachio> ijohnson|lunch, I'll update that
[18:27] <cachio> thanks for that
[18:42] <mup> PR snapcraft#3400 opened: requirements: uprev python-apt <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3400>
[18:45] <mup> PR snapd#9814 opened: tests: update check to verify is the current system is arm <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9814>
[19:16]  * cachio afk7
[19:22] <mup> PR snapcraft#3400 closed: requirements: uprev python-apt <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3400>
[21:02] <hardwire> anybody have a good gadget/device config for pi zero w?
[21:02] <hardwire> for core20
=== ijohnson|lunch is now known as ijohnson
[21:24] <ijohnson> hardwire: ubuntu core 20 (well any ubuntu series) does not run on the pi zero w because that device is armv6 and ubuntu requires armv7
[21:51] <hardwire> armhf is a no go on that series?
[21:58] <hardwire> Mostly just an understanding issue on my side between pi os, debian os, ubuntu os and if the difference is due to minimum standards with ubuntu kernel configs and compatible gcc flags that are purposefully altered from debian upstream.. or if there's some other gap in my understanding that just isn't obvious right now.
[22:00] <hardwire> I'd like to use snap on these systems.. not sure if that means moving a bunch of this to an armv6 snap core.
[22:01] <hardwire> The big gotcha I think is that armhf would be a 'misnomer' for any ubuntu pools recompiled to support armv6
[22:01] <hardwire> Unfortunately I think that is what threw me off
[22:09] <hardwire> not even sure if uboot is set up to boot armv6 from those images either
[22:40] <ijohnson> hardwire: yes it's different for ubuntu vs debian in that respect ubuntu only supports armv7, whereas debian supports armv6 (or at least raspbian does)
[22:41] <ijohnson> unfortunately the issue is larger than just building an armv6 "core" snap, you would need to first compile ubuntu debian packages from the archive for armv6 and then use those to construct the core snap, since the current armhf core snap is built that way
[22:44] <hardwire> that would be a lot of no fun but possibly worth it.
[22:44] <hardwire> I think it may be more worth it to snaperize raspberry pi os.
[22:44] <hardwire> that's a real word I just made up.
[22:44] <ijohnson> you could look into using Raspberry Pi 3 Model A+ instead of the raspberry pi zero w
[22:45] <hardwire> Not with 3000+ Pi Zero W in the field.
[22:45] <ijohnson> not quite the same size, but smaller and cheaper than a normal raspberry pi
[22:45] <ijohnson> ah fair enough
[22:45] <hardwire> I'm consulting to help deal with a 'rushed to production' issue.
[22:46] <hardwire> Doing OTA without snap will be a pain.  I'm left with ostree or a very custom setup.
[22:46] <hardwire> I'd really like to target things so that the ext4 containing the mountable snaps was not also /writable as well.
[22:46] <ijohnson> yeah that is tough
[22:47] <ijohnson> you mean you want the .snap files on a different partition than the writable partition ?
[22:47] <hardwire> I do appreciate whoever padded the core20 images to 8gb
[22:47] <hardwire> that was useful.
[22:47] <ijohnson> ha that was a bug that they are padded like that, but glad it was helpful to someone :-)
[22:48] <hardwire> I typically made a sparse file and then use dd with notrunc to overlay the image.
[22:48] <hardwire> It took me a while to realize core20 was different than core18
[22:48] <hardwire> but I think it helps some folks not scratch their heads when the initial setup doesn't works so hot.
[22:51] <hardwire> so it looks like setting up a snap based project to create a core/kernel for arm6 might be the best solution.. pulling from "offical" pi upstreams.
[22:51] <hardwire> official even.
[22:51] <hardwire> there's gonna be a few gotchas for sure.
[22:51] <hardwire> I bet I'd get sued by either ubuntu or snapple if I called it snappleberry pi
[22:52] <hardwire> the initial tar for core18/core20 isn't too far a stretch from vanilla