=== KindTwo is now known as KindOne
=== KindTwo is now known as KindOne
=== KindTwo is now known as KindOne
=== Ps1-Jack is now known as Psi-Jack
[09:20] <alazred> zyga: Hi there ! I made the install of snapd from scratch this morning.  There are a few things that seems off When you have a few min look at the step i took to install it. Thanks! https://pastebin.com/Mu53z5km
[09:21] <zyga> alazred: can you show me the packaging file, it seems some things are wrong
[09:21] <zyga> fontconfig bits are something mborzecki should look at next week
[09:21] <zyga> he's off today and tomorrow, can you show up on Monday and chat with him please?
[09:22] <alazred> zyga: the font config thig is an error related to telegram tho
[09:23] <alazred> zyga: Yeah1 I'll try to to seek him on Monday.
[09:24] <zyga> it's a more complex issue
[09:24] <zyga> fontconfig broke compatibility
[09:25] <zyga> and writes cache in different format without saying the version is different
[09:25] <zyga> there was some more differences that were a factor that got partially resolved recently and should be released soon
[09:27] <alazred> zyga: here is the PKGBUILD file https://gitlab.manjaro.org/manjaro-arm/packages/community/snapd/-/blob/master/PKGBUILD
[09:28] <alazred> zyga: Those are the change that has been made yesterday. https://gitlab.manjaro.org/manjaro-arm/packages/community/snapd/-/blob/master/snapd.install
[09:28] <alazred> reguarding starting the snapd.apparmor.service
[09:29] <zyga> ah
[09:29] <zyga> the post install feels wrong
[09:29] <zyga> the socket should be started, not the service
[09:29] <zyga> snapd.socket
[09:29] <alazred> that was my next question
[09:29] <zyga> and the other service should be *enabled*, not started
[09:30] <zyga> and it should not be restarted on upgrade
[09:30] <zyga> and is it snapd-apparmor.service or snapd.apparmor.service?
[09:30] <zyga> the snapd apparmor service only matters on boot
[09:30] <zyga> does not need to be restarted or anything
[09:30] <zyga> on upgrade snapd.service should be restarted
[09:30] <zyga> on install snapd.socket should be enabled and started
[09:30] <zyga> and snapd apparmor service should be enabled but not started (no need to)
[09:31] <zyga> compare with our first-party arch version: https://github.com/snapcore/snapd/blob/master/packaging/arch/snapd.install
[09:32] <alazred> Ok and snapd.service will get started when snapd.socket will be enabled. right ?
[09:32] <zyga> and even that is buggy as it doesn't mention snapd.apparmor.service
[09:32] <zyga> snapd.service is socket activated by snapd.socket
[09:33] <zyga> so it will start when needed
[09:33] <zyga> yeah, I need to talk to maciek
[09:33] <zyga> those are all low hanging fruit
[09:34] <alazred> Same for snapd.apparmor.service is handled by snapd.socket
[09:34] <zyga> oh?
[09:35] <zyga> what do you mean?
[09:35] <zyga> https://github.com/snapcore/snapd/blob/master/data/systemd/snapd.apparmor.service.in
[09:36] <alazred> I mean when .socket get enabled and started it handle snapd.service and snapd.apparmor.service  when it needs it
[09:38] <zyga> alazred: snapd.apparmor.service is different
[09:38] <zyga> it's not socket activated
[09:39] <zyga> it just needs to be enabled to run once on each boot
[09:39] <zyga> it's not needed after booting
[09:41] <alazred> ok all clear ! =)
[09:42] <alazred> So the change needed to be done to have a proper install are: enabling and starting snapd.socket and enabling snapd.apparmor.service.
[09:43] <zyga> yes
[09:43] <zyga> in addition there are some things done in the arch version that should be ported over
[09:43] <zyga> like handling reloading snapd
[09:43] <alazred> Perfect
[09:43] <zyga> I would sync with Maciek on Monday to discuss details as he knows this part better than I do
[09:44] <alazred> ok I'll refer that
[09:44] <alazred> Perfect thanks again for the help!
[09:44] <zyga> sure, it's a pleasure :)
[09:47] <alazred> zyga: One last thing. someting need to be done with the apparmor.service at all ?
[09:48] <zyga> I don't quite know what's the state of apparmor in manjaro but it has the same purpose as snapd.apparmor.service - it loads profiles on boot
[09:48] <zyga> apparmor profiles are text files
[09:48] <zyga> that are compiled and cached into a binary form
[09:48] <zyga> that is then loaded into the kernel to become effective
[09:48] <zyga> that service performs that step
[09:49] <alazred> ok so the snapd-apparmor.service should be sufficient
[09:49] <alazred> ?
[09:50] <zyga> it's not a replacement, it's just handling the part that snapd generated
[09:50] <zyga> both are needed, one loads system wide profiles from packages
[09:50] <zyga> and the other loads system wide profiles generated by snapd
[09:53] <alazred> OK.
[11:49] <mup> PR snapcraft#3168 opened: plugins: fix loading of catkin-tools <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3168>
[12:20] <cachio> ijohnson, when you have 10 minutes, could you please take a look to #8755?
[12:20] <mup> PR #8755: tests: fix classic ubuntu core transition auth <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8755>
[12:22] <cachio> ijohnson, jello
[12:22] <ijohnson> hallo
[12:23] <ijohnson> cachio: yes I will take a look at that test
[12:28] <cachio> ijohnson, thanks
[13:00] <pedronis> ijohnson: cachio: standup?
[13:01] <ijohnson> 2fa sry
=== alazred_ is now known as alazred
[13:44] <mup> PR snapcraft#3168 closed: plugins: fix loading of catkin-tools <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3168>
[14:08] <roadmr> jdstrand: hey sorry didn't tell you yesterday - review-tools from 2020-06-08 (the one with the 2.45 snapdecl changes) is now in prod
[14:23] <jdstrand> roadmr: nice, thanks! (cc emitorino)
[14:49]  * cachio lunch
[14:57] <emitorino> nice roadmr, thanks!
[15:56] <abeato> ijohnson, hey, if a kernel/core snap had a failed update, will snapd try to refresh again to the same revision that failed?
[15:58] <ogra> hopefully not ... you'd end up in an install loop
[15:58] <ogra> (because it is likely it will keep failing if it didnt change)
[15:59] <abeato> right... but I would like confirmation ;)
[16:03] <ijohnson> abeato: iirc it depends on how it failed, if it was something like a network error trying to download we should retry but if the device fails to boot from it and it got rolled back no it shouldn't try again, but let me double check the code for you
[16:04] <abeato> ijohnson, thanks - I'm talking here about the roll back case especifically
[16:13] <pedronis> ijohnson: afair we will retry, we need a different way to remember blocked to avoid that
[16:14] <ijohnson> pedronis: hmm maybe I was thinking of `snbap revert` ?
[16:14] <ijohnson> but also you're right I don't see that code anywhere right now :-/
[16:20] <ijohnson> actually I don't even know that a snap revert will prevent automatic refresh again
[16:21] <ijohnson> I seem to recall John telling me/explaining to me how snap revert marked snaps we reverted _from_ somehow so that they were garbage collected at some point but I can't find that code at all anymore
[16:21] <ijohnson> it's probably still there I just can't find it
[16:24] <pedronis> ijohnson: yes, snap revert does
[16:25] <ijohnson> pedronis: is that by manipulating the Sequence[] and then something else cleans up the Sequence ?
[16:25] <ijohnson> that's the only logic I can find in snapstate that seems like it would clean things up
[16:25] <pedronis> ijohnson: snapst.Blocked
[16:25] <pedronis> sorry
[16:26] <pedronis> ijohnson: I mean look at SnapState.Block
[16:26] <pedronis> but yes it relates to having Current not match the top of the Sequence
[16:27] <pedronis> but it doesn't help for a kernel that failed completely because that doesn't go into Sequence
[16:27] <ijohnson> hmmm
[16:28] <ijohnson> I must say how this garbage collection works is quite unintuitive and non-obvious :-/
[16:31] <ijohnson> yeah I see how it works now for snap revert and why it won't work for kernel/base snaps
[16:31] <ijohnson> abeato: so I was wrong we will retry even if the kernel failed to boot and was rolled back unfortunately
[16:31] <ijohnson> abeato: if there's not already a LP bug about this could you file one? unclear when we will be able to get around to it however
[16:31] <abeato> ijohnson, hm, I see...
[16:32] <abeato> ijohnson, yeah, I will do that, thanks for taking a look - it certainly feels like a bug
[16:32] <pedronis> it's definitely something we want to fix, but therer are some open questions around it
[16:33] <abeato> ijohnson, so when will it try again? which is the time between snap refreshes?
[16:34] <pedronis> 6 hours unless configured otherwise
[16:36] <ijohnson> abeato: what pedronis said
[16:38] <abeato> ijohnson, pedronis : https://bugs.launchpad.net/snapd/+bug/1883147 - thanks
[16:38] <mup> Bug #1883147: snapd does not blacklists rolled back kernel snaps <snapd:New> <https://launchpad.net/bugs/1883147>
[16:38] <ijohnson> thanks
[16:50] <pedronis> thx
[17:31] <ijohnson> degville: hey I just noticed that the uc20 release page doesn't have an html title for the specific page ?
[17:31] <ijohnson> i.e. https://docs.ubuntu.com/core/en/releases/uc20 shows up as just "| Ubuntu for IoT Developers documentation"
[17:38] <degville> ijohnson: ah, good spot - thanks - I'll fix it. Most of the pages do place their titles ahead of that IoT stanza. It's probably because I'd quite like to drop it entirely but haven't been brave enough.
[17:38] <ijohnson> :-)
[19:58] <mup> PR snapd#8850 opened: dirs: delete unused Cloud var, fix typo <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8850>
=== lfaraone_ is now known as lfaraone