[07:11] <zyga> good morning
[07:12] <mvo> doko: fyi - all adt tests on snapd are green except s390x, I take care of this one today
[07:12] <mvo> hey zyga, good morning
[07:50] <zyga> :)
[08:09] <pstolowski> morning
[09:33] <Chipaca> mo'in
[09:33] <Chipaca> mvo: EHLO
[09:33] <mup> PR snapcraft#2394 opened: build providers: fix osx non base and injection <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2394>
[09:34] <Chipaca> mvo: I haven't merged #6093 because I hear it's wanted in 2.36 and don't  know if we still need to squash-merge things that need that
[09:34] <mup> PR #6093: daemon: spool sideloaded snap into blob dir <Created by chipaca> <https://github.com/snapcore/snapd/pull/6093>
[09:34] <Chipaca> mvo: or should I write a separate PR and target it at the release branch?
[09:41] <mvo> Chipaca: thats fine, pedronis wanted to have a quick look at 6093 before it is merged
[09:41] <mvo> Chipaca: and once its in (ideally via squash merge) we can cherry pick
[09:42] <Chipaca> ok
[09:44] <pstolowski> Chipaca: hey! one question to your userid&snapshots fix, ready to re-approve once clarified
[09:47] <pedronis> mvo: Chipaca: looking at it now
[09:51] <mup> PR snapcraft#2393 closed: lifecycle: make snapcraft init template use > not | <Created by sparkiegeek> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2393>
[10:00] <mup> PR snapd#6102 closed: overlord/snapshots: survive an unknown user <Created by chipaca> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6102>
[10:02] <pedronis> mvo: Chipaca: commented. mostly nitpicks that could go in a follow up but a bit worried at the cost vs frequency of cleanupOldTemps
[10:04] <Chipaca> pedronis: ah, I'll add a time check thing
[10:04] <Chipaca> pedronis: i got confused because i have a different pr that has this already :-)
[10:04] <Chipaca> not pr, a commit
[10:04] <Chipaca> a stash even
[10:04] <Chipaca> the one with warnings for devmode things :-)
[10:11] <mborzecki> morning
[10:15] <pstolowski> hey mborzecki
[10:17] <zyga> hey mborzecki
[10:18] <mborzecki> stuck in a slightly boring talk, doing reviews :)
[10:19] <zyga> haha
[10:19] <pedronis> mvo: Chipaca:  https://github.com/snapcore/snapd/pull/6101 is green but doesn't have a description/motivation
[10:19] <mup> PR #6101: switch travis unit tests to xenial <Created by chipaca> <https://github.com/snapcore/snapd/pull/6101>
[10:19] <mborzecki> btw. there should be some video streams at http://codedive.pl/ in case anyone is interested
[10:26] <diddledan> desktop helpers part for the post-remote-parts world https://www.irccloud.com/pastebin/fwLMLqKc/
[10:33] <mup> PR snapcraft#2395 opened: Fixed Errors of macOS environment <Created by hsbt> <https://github.com/snapcore/snapcraft/pull/2395>
[10:40] <Chipaca> pedronis: i'll add motivation
[10:40] <Chipaca> pedronis: it's not a strong one right now :-) but will be someday
[10:40] <Chipaca> soon i hope
[10:43] <pedronis> Chipaca: thx
[10:57] <pedronis> Chipaca: ah, dist: xenial wasn't a thing until now
[10:57] <pedronis> ?
[10:57] <Chipaca> pedronis: it's not a thing until tomorrow, officially
[10:57] <pedronis> heh
[10:57] <pedronis> ok
[10:57] <pedronis> Chipaca: so we should not merge it until tomorrow?
[11:00] <Chipaca> pedronis: up to us :-)
[11:00] <Chipaca> pedronis: it's no big secret, tomorrow is when it's supported officially but we're sitting next to them today and tomorrow :-)
[11:00] <Chipaca> pedronis: we can also say "nah not worth it" and close the pr
[11:01] <pedronis> Chipaca: no, it's fine, just trying to understand
[11:33] <mup> PR snapcraft#2394 closed: build providers: fix osx non base and injection <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2394>
[11:36] <zyga> mvo: https://forum.snapcraft.io/t/lack-of-compiled-locales-breaks-gettext-based-localisation/3758/16
[11:36] <zyga> locale strikes back
[11:37] <zyga> I would love for us to include locale in core instead of having layers of hacks like that
[11:40] <zyga> br
[11:40] <zyga> brb
[11:48] <mup> PR snapcraft#2395 closed: Fixed Errors of macOS environment <Created by hsbt> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2395>
[11:51] <pedronis> Chipaca: I'm going to review your epochs PR, but if I understand correctly is not the full story, we should chat about epochs next week
[11:53] <cachio> mvo, hey, I see this often on core 18
[11:53] <cachio> https://paste.ubuntu.com/p/G6GFxSphzs/
[11:58] <Chipaca> pedronis: +1
[11:58] <Chipaca> pedronis: AIUI the bit missing is the refresh revving, but I might've missed something else
[11:58] <mup> PR snapd#6104 opened: snapctl: add "services" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6104>
[11:58] <Chipaca> pstolowski: ^^^ might be of interest to you.
[11:59] <Chipaca> also, hm, wut, missing services in -h
[12:00]  * Chipaca investigates
[12:01] <Chipaca> oh d'oh
[12:01] <Chipaca> also, also, d'oh² broke unit tests
[12:05] <pstolowski> Chipaca: thanks, will take a look
[12:05] <mvo> cachio: when you see this, what is the status of "systemctl status snapd"?
[12:05] <mvo> cachio: did you managed to reproduce it?
[12:05] <cachio> mvo, no
[12:05] <cachio> I cant reproduce it
[12:06] <mvo> :/
[12:06] <mvo> ok
[12:06] <cachio> I just see the error on travis
[12:06] <cachio> I can create a PR to force it
[12:06] <mvo> I need to look at this then and try to understand how it can happen, if its frequent it might be worthwhile to add debug: | for that
[12:06] <cachio> mvo, which debug info do yo uneed
[12:07] <cachio> just status for snapd¡
[12:07] <mvo> cachio: systemctl status snapd would be good for a start
[12:07] <mvo> cachio: maybe journalctl -u snapd as well just to be on the safe side
[12:07] <mvo> cachio: it might be that its just running too early and no snapd is around at all yet
[12:07] <mvo> cachio: in which case its probably harmless but let me look at the test again after lunch with fresh eyes
[12:07] <cachio> ok, I'll create a PR to for that
[12:08] <cachio> sure
[12:19] <mup> PR snapd#6105 opened: NOT REVIEW: New task to force error on degraded test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6105>
[12:28] <oSoMoN> zyga, on fedora with core18, xdg-open doesn't work, is that a known issue?
[12:28] <oSoMoN> "/usr/bin/xdg-open: 2: exec: snapctl: not found"
[12:28] <zyga> oSoMoN: no, I don't believe this is know
[12:28] <zyga> which snapd version?
[12:29] <zyga> there is an update: https://bodhi.fedoraproject.org/updates/FEDORA-2018-48cc10ba1d
[12:29] <zyga> could you please test it
[12:29] <zyga> and report on the update page
[12:29] <oSoMoN> zyga, ack, will do just after lunch and will keep you posted
[12:29] <zyga> thank you
[12:32] <pedronis> mvo: I added some comments to the originally dotfiles PR, about the name and the base declaration bits
[12:34] <mup> PR snapd#6106 opened: overlord/ifacestate: Handler for hotplug-update-slot tasks <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6106>
[13:22] <oSoMoN> zyga, the update fixes my issue with xdg-open \o/
[13:22] <oSoMoN> I'll report on the test page
[13:22] <zyga> whee, that's great
[13:22] <zyga> thank you
[13:28] <mvo> pedronis: thank you!
[13:41] <zyga> flock unit test randomly failing  https://www.irccloud.com/pastebin/eL5WynJ7/
[13:45] <andyrock> do snaps have access to /run ?
[13:47] <zyga> andyrock: to some parts of run, yes
[13:47] <zyga> it depends on specific path
[13:49] <andyrock> zyga: e.g. if there is a snap called "random-snap" can I access /run/random-snap ?
[13:49] <andyrock> otherwise how does it work?
[13:51] <zyga> andyrock: are you asking if some snap can access /run/random-snap?
[13:51] <zyga> in general the answer is no
[13:51] <zyga> in specific case the answer may be yes
[13:51] <zyga> it is defined by the snap interface system
[13:51] <zyga> by the set of plugs, slots and the connections between them
[13:52] <seb128> zyga, the real question is "what would it take to let the livepatch snap write it's status file in /run (so it's auto-cleaned on reboot)" I think
[13:52] <seb128> andyrock, ^ right?
[13:52] <seb128> jdstrand, ^
[13:53] <andyrock> zyga: yes, livepatch snap write a status file to communicate with update-notifier
[13:54] <zyga> seb128, andyrock a trivial tweak to the interface I suspect
[13:54]  * zyga looks
[13:54] <jdstrand> andyrock: the snap already has access to XDG_RUNTIME_DIR, if that is helpful:
[13:54] <jdstrand> $ sudo hello-world.env |grep XDG_RUNTIME_DIR
[13:54] <jdstrand> XDG_RUNTIME_DIR=/run/user/0/snap.hello-world
[13:54] <andyrock> right now that file is in /var/snapd/canonical-livepatch/current/status
[13:54] <zyga> ah, there's no live patch interface
[13:55]  * jdstrand is assuming it is the daemon that needs write access to it
[13:55] <andyrock> but considering that files applies to a boot session would be nice to have it under a "run" directory
[13:55] <jdstrand> XDG_RUNTIME_DIR still isn't created by anything, byt you can mkdir it and write it there
[13:56] <andyrock> *considering that the status file
[13:56] <jdstrand> andyrock: I suggest looking at XDG_RUNTIME_DIR. you don't need any changes to snapd for that
[14:00] <andyrock> jdstrand: is that directory accessible by the system?
[14:00] <jdstrand> andyrock: yes
[14:01] <andyrock> jdstrand: kk. It looks like it's what we need
[14:01] <andyrock> thx
[14:03] <jdstrand> oh hrmm, /run/user/0 doesn't exist and the snap can't create it. zyga, that really needs to be fixed somewhere
[14:03] <jdstrand> andyrock: ^
[14:04] <mup> PR snapd#6107 opened: cmd/snap, snapctl: add column selectors to services <Created by chipaca> <https://github.com/snapcore/snapd/pull/6107>
[14:04] <zyga> (standup)
[14:04] <jdstrand> zyga: I've always argued that the session manager (ie, systemd) should do it, but it isn't
[14:04] <zyga> jdstrand: I think we can do it now
[14:04] <jdstrand> for non-root it all works. we should probably have snapd just create it
[14:05] <jdstrand> or snap-confine, which is where I think you are going
[14:05] <zyga> yes
[14:05] <zyga> snap-update-ns specifically
[14:05] <jdstrand> andyrock: you will need some snapd support after all
[14:05] <zyga> anyway, I will think about it
[14:05] <zyga> andyrock, seb128: can you please file a bug on this
[14:05] <zyga> OR find one that exists
[14:05] <zyga> about XDG_RUNTIME_DIR for root
[14:05] <zyga> I'll assign that to myself
[14:05] <jdstrand> zyga: note, it needs to preserve the property that the host can see it
[14:05] <zyga> right
[14:05] <jdstrand> zyga: thanks!
[14:07] <seb128> jdstrand, zyga, those are created/destroyed with the corresponding user session, if root has no login/session that's why it doesn't exist
[14:08] <seb128> it would make more sense to have a /run/livepatch-status
[14:09] <seb128> but that might require a custom interface for livepath then...
[14:09] <seb128> unless there is a new rule to allow using "/run/<snap_name>"
[14:17] <zyga> seb128: I think we could do a custom interface as well
[14:18] <zyga> jdstrand: ^
[14:18] <zyga> seb128: there is no such rule today
[14:18] <seb128> right
[14:18] <zyga> seb128: perhaps we could add /run/snap.$SNAP_NAME
[14:18] <seb128> well either way it seems it needs changes in snapd
[14:18] <zyga> that might be a nice default
[14:18] <seb128> right
[14:18] <zyga> seb128: yes, for sure
[14:18] <seb128> I think it would be useful
[14:18] <seb128> for others snaps as well
[14:18] <zyga> I agree
[14:18] <zyga> and would be easier than a new interface
[14:18] <seb128> indeed
[14:18] <zyga> something for 2.36.1 perhaps
[14:18] <seb128> I like it
[14:19] <seb128> where should that wishlist be reported? github? forum?
[14:19] <zyga> seb128: I actually prefer a bug report but it can also be a forum
[14:19] <zyga> seb128: bug is something I can assign to myself
[14:19] <zyga> seb128: forum is nicer for discussion
[14:19] <seb128> k, so basically you want both :)
[14:20] <seb128> andyrock, want me to open those?
[14:20] <andyrock> seb128: as you prefer, otherwise I'll do that once I finish what I'm currently working on
[14:20] <seb128> andyrock, I'm doing it
[14:22] <zyga> thank you!
[14:33] <seb128> zyga, https://forum.snapcraft.io/t/snaps-can-not-write-to-run-by-default/8367 and https://bugs.launchpad.net/snapd/+bug/1802112
[14:33] <mup> Bug #1802112: Snaps can't write to /run by default <snapd:New> <https://launchpad.net/bugs/1802112>
[14:33] <zyga> thank you
[14:34] <zyga> pedronis: ^ can you look at this please - if there's agreement to allow snaps to write to /run/snap.$SNAP_NAME then it could be a trivial one liner change for 2.36.1 - the use case is live patch dropping a status file that some part of classic world can look at
[15:16] <pedronis> zyga: it does sound reasonable and aligned to other things we do, we do need jdstrand input on it tough
[15:19] <popey> jdstrand: is there a way in which a snap can set network configuration? Specifically setting a static IP address? On core?
[15:21] <pedronis> zyga: I answered in the bug
[15:22] <zyga> thank you
[15:22]  * pedronis break
[15:23] <zyga> jdstrand: can you please look at https://bugs.launchpad.net/snapd/+bug/1802112
[15:23] <mup> Bug #1802112: Snaps can't write to /run by default <snapd:New for zyga> <https://launchpad.net/bugs/1802112>
[15:25] <jdstrand> popey: network-control gives all the raw lowlevel stuff (eg, use of 'ip')
[15:26] <popey> jdstrand: even on core?
[15:26] <jdstrand> popey: yes
[15:26] <popey> awesome
[15:26] <jdstrand> popey: if you want netplan configuration, then look at network-setup-control
[15:27] <jdstrand> popey: or if they have network-manager installed, plugs network-manager
[15:27] <popey> jdstrand: thanks, this is a 'legacy'
[15:28] <jdstrand> popey: there may be some interplay with netplan that they'll need to work through when using network-control, but network-control will definitely allow them to do stuff. ogra might have tips
[15:29] <popey> ok, ta
[15:29] <ogra> popey, https://github.com/ogra1/dashkiosk-image-config netplan-import might be interesting
[15:30] <popey> the problem is this snap needs to run on core and non-core
[15:30] <popey> and could run on non-ubuntu
[15:30] <popey> so needs to special case all the random nonsense ways people set IP addresses etc
[15:30] <ogra> (copies any "netplan.yaml" file from a USB device you plug into the device and reboots with new network config)
[15:30] <ogra> oh, ok
[15:31] <ogra> popey, in any case network-setup-control is enough to replace the config in /etc/netplan ... you want the shutdown interface too and trigger a reboot for it to take effect (netplan generate/apply are not allowed atm)
[15:32] <pedronis> Chipaca: is #6107 something that was discussed at the summit?
[15:32] <ogra> to check for core just look for snap_core= in /proc/cmdline (shouldnt be restricted)
[15:32] <mup> PR #6107: cmd/snap, snapctl: add column selectors to services <Created by chipaca> <https://github.com/snapcore/snapd/pull/6107>
[15:32] <Chipaca> pedronis: yes
[15:33] <Chipaca> pedronis: gustavo's suggestion actually
[15:33] <Chipaca> pedronis: reasoning  being that the table output isn't too script-friendly
[15:35] <pedronis> Chipaca: I see, that's a bit true of a lot of our commands tough
[15:35] <pedronis> Chipaca: is this one particurly egregious?
[15:37] <pedronis> Chipaca: I mean, do we need a choose your column general strategy instead?
[15:37] <Chipaca> pedronis: this one is the only one in snapctl afaik
[15:37] <Chipaca> pedronis: I asked the same thing though,  --column=foo
[15:37] <Chipaca> pedronis: but, translations
[15:38] <pedronis> Chipaca: the only one, doesn't sound a statement that will be true forever
[15:38]  * Chipaca nods
[15:39] <pedronis> Chipaca: I understand that we tried something for snap list and it was a quagmire
[15:39] <Chipaca> pedronis: with --format you mean? yes
[15:39] <pedronis> yes
[15:41] <pedronis> Chipaca: I understand I'm not being super constructive, but I'm trying to understand if it's the start of a slippery slope
[15:41] <Chipaca> pedronis: I understand :-)
[15:45] <Chipaca> zyga: ping
[15:45] <zyga> yes sir
[15:45] <Chipaca> zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1802124
[15:45] <mup> Bug #1802124: Error installing chromium-mir-kiosk on RPi3/edge <snapd (Ubuntu):New> <https://launchpad.net/bugs/1802124>
[15:46] <Chipaca> zyga: does this mean we need to move those to per-arch code?
[15:46] <zyga> yes
[15:46] <Chipaca> zyga: note the lookup table thing is already per-arch
[15:46] <zyga> I though that was exactly what you did
[15:46] <zyga> aaah
[15:46] <Chipaca> zyga: ah indeed
[15:46] <zyga> I thought it was all per-arch
[15:46] <zyga> yes, I'm afraid that's needed
[15:46] <zyga> Chipaca: while I have you
[15:46]  * Chipaca is had by very few people
[15:47] <Croepha> does the snap environment use the core system's ld-linux-x86-64.so.2 or can you ship your own? having glibc version issues
[15:47] <zyga> quick question about this particular piece of code https://github.com/snapcore/snapd/blob/master/run-checks#L180
[15:47] <Chipaca> zyga: shoot
[15:48] <Chipaca> Croepha: why are you having glibc version issues
[15:48] <zyga> Chipaca: is it legitimately complaining about this usage: https://github.com/snapcore/snapd/pull/6095/files#diff-36a23153f5bbd7bffd11c24597ac50fdR238
[15:48] <mup> PR #6095: packaging/opensuse: stop using golang-packaging <Created by zyga> <https://github.com/snapcore/snapd/pull/6095>
[15:48] <Chipaca> Croepha: is your snap classic, or strict?
[15:51] <Croepha> Chipaca: im shipping a newer version of libpython and it requires a newer version of glibc than what is in core, I wasn't using strict, I was using try, right now im just using a chroot directory in my home while I do some development iterations
[15:52] <Chipaca> Croepha: you get glibc mismatches because you build against a different glibc than the one in the core you specify
[15:53] <Chipaca> Croepha: I seriously doubt libpython requires a  particular glibc version, although it's quite likely that a particular version of libpython is only available in a distribution with a newer glibc
[15:53] <Chipaca> Croepha: you can probably build the newer libpython against the older glibc
[15:53] <Chipaca> Croepha: or you can use a newer base
[15:54] <Chipaca> Croepha: or you can tell snapcraft to ship your own libc in the snap
[15:54] <Chipaca> Croepha: in general the last one is not a good idea
[15:54] <Chipaca> but, it's there if you need it
[15:54] <pedronis> mvo: question, do we check when installing if bases have actually type: base,  I looked around and didn't find such a check
[15:54] <Chipaca> (you probably don't need it)
[15:54] <Croepha> ok, thanks Chipaca
[15:54] <Chipaca> zyga: thinking about it
[15:54] <zyga> yes?
[15:55] <Chipaca> zyga: i mean, the usage is ok, although I don't know what an empty entry in GOPATH does
[15:55] <zyga> in this specific case it's never empty
[15:55] <zyga> suse is a bit looney that it sets GO{ARCH,OS,PATH,ROOT} for all users
[15:55] <zyga> there's a /etc/profile.d/go.sh
[15:56] <zyga> that contains values matching some compiler (via alternatives)
[15:56] <pedronis> zyga: are these layout docs:  https://forum.snapcraft.io/t/snap-layouts/7207 ? does it need to mention that the experimental flag is no more now
[15:56] <mvo> pedronis: not sure, I need to look. will do so after the meeting
[15:56] <pedronis> mvo: thank you
[15:56] <zyga> pedronis: that's correct,
[15:56] <zyga> pedronis: I will amend it to say that since snapcraft 3.0 that uses bases and since snapd 2.36 it is not experimental anymore
[15:57] <pedronis> thanks
[15:59] <Chipaca> zyga: so, i've got a fix for you
[16:00] <zyga> pedronis, degville: I edited https://forum.snapcraft.io/t/snap-layouts/7207 to account for the new reality (enabled since 2.36 and since snapcraft 3.0 with bases)
[16:00] <Chipaca> zyga: http://paste.ubuntu.com/p/zJPFQnRgX8/
[16:00] <Chipaca> zyga: bundle that in if you can
[16:00] <zyga> thank you!
[16:00] <zyga> yep, I will
[16:01] <degville> zyga: thanks for the heads-up!
[16:01] <pedronis> zyga: degville: should layout be a top level topic in the docs? either way I think snap format doc should mention them and link to this
[16:02] <pedronis> I'm talking about  https://docs.snapcraft.io/the-snap-format/698 -> layout docs
[16:02] <Chipaca> zyga: the hint was in what exactly was getting highlighted in the output :-)
[16:03] <zyga> pedronis: I think it should be referenced from the format spec
[16:03] <zyga> not otherwise top-level IMO
[16:03] <pedronis> ok
[16:04] <degville> pedronis, zyga : yep, I agree.
[16:05] <pedronis> zyga: degville: I left a note for you in the forum topic about this
[16:05] <degville> thanks!
[16:05] <pedronis> thank you
[16:10] <roadmr> Hello folks; we're currently investigating a snap store outage, snap requests may be slow or fail intermittently.
[16:10] <zyga> oh, thank you for the note roadmr
[16:41]  * zyga needs coffee
[16:43] <cachio> roadmr, thanks
[16:48] <roadmr> snap store should be back to normal now, folks. Thanks for your patience
[16:55] <pstolowski> Chipaca: re 6104, making it 2 separate PRs (1 PR to just move the old code around) would make review easier
[17:10] <cachio> mvo, https://travis-ci.org/snapcore/snapd/jobs/451975712#L1234
[17:10] <cachio> this is the error on degraded with extended debug info
[17:12] <cachio> mvo, I see some retries to get the catalod
[17:13] <doko> mvo: snapd failed to build on amd64
[17:13] <cachio> mvo, but nothins weird apart fo that
[17:14] <zyga> re
[17:14] <zyga> roadmr: thank you!
[17:14]  * zyga got involved in some homework
[17:28] <mvo> doko: looking
[17:29] <mvo> cachio: if you are on the system, can you please paste the output of "journalctl -u snapd.seeded.service" and "systemctl status snapd.seeded" ?
[17:32] <Chipaca> pstolowski|afk: noted
[17:34] <cachio> cachio, I am not but I'll trigger it again
[17:38] <cachio> zyga, updating scripts to create tumbleweed image
[17:39] <Chipaca> pstolowski|afk: not sure i'll be able to do it tonight though but i'll try
[17:39] <cachio> zyga, it should be ready soon
[17:39] <Chipaca> yesterday i fell asleep on the train and stuff
[17:39]  * Chipaca really tired by all this weird "human" interaction
[17:39] <mup> PR snapd#6108 opened: many: apparmor support for rpm distros <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6108>
[17:39] <Chipaca> :)
[17:40] <zyga> cachio: super, thanks
[19:10] <mup> PR snapd#6108 closed: many: apparmor support for non-AA rpm distros <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/6108>
[19:36] <zyga> jdstrand: FYI https://github.com/snapcore/snapd/pull/6108#issuecomment-436750366
[19:36] <mup> PR #6108: many: apparmor support for non-AA rpm distros <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/6108>
[19:36] <zyga> jdstrand: sorry,  if I knew you were interested in packaging I would have said something
[19:36] <zyga> I'm working on packaging for a few days now
[19:37] <zyga> jdstrand: I will propose the stuff I have as soon as https://github.com/snapcore/snapd/pull/6095 lands
[19:37] <mup> PR #6095: packaging/opensuse: stop using golang-packaging <Created by zyga> <https://github.com/snapcore/snapd/pull/6095>
[19:53] <mup> PR snapd#6095 closed: packaging/opensuse: stop using golang-packaging <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6095>
[19:59] <mup> PR snapd#6108 opened: many: apparmor support for non-AA rpm distros <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6108>
[20:02] <cachio> zyga, finally the image ready
[20:02] <cachio> zyga, and I could create a script to automate the process
[20:02] <zyga> cachio: super
[20:03] <zyga> I can run a tumbleweed test quickly
[20:03] <cachio> yes
[20:03] <cachio> just use image: opensuse-tumbleweed-64
[20:04] <zyga> thank you, I will report back
[20:04] <cachio> zyga, great, thanks
[23:37] <rogpeppe> what's the story about running external executables inside a snap? I'd like to publish a couple of snaps that work on Go source code, and these days the only way to do that is by invoking the go command. Should I package up the go compiler into my snaps too?