[05:07] <mborzecki> morning
[05:44] <zyga> good morning
[05:44] <mvo> hey zyga
[05:44] <zyga> wow, I had a good sleep today
[05:44] <zyga> I woke up, looked outside and noticed it's not dark anymore
[05:44] <zyga> and it was about 4AM
[05:45] <zyga> mvo: I have a small proposal in 5202
[05:45] <zyga> might make reviewing logs a little bit less frustrating
[05:45] <mvo> zyga: yeah, I saw that
[05:45] <mvo> zyga: was just about to comment
[05:49] <mup> PR snapd#5201 closed: interfaces/apparmor: use helper to load stray profile <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5201>
[05:49] <mborzecki> mvo: zyga: hey
[05:50] <mborzecki> zyga: thanks for doing the renames in 5199
[05:50] <zyga> :-)
[05:50] <zyga> ooooh!
[05:50] <zyga> finally!!!
[05:51]  * zyga got an email that his 3d printer has shipped
[05:51] <zyga> after months of waiting
[05:52] <zyga> I suspect this means that weekend will be spent on "some assembly required"
[05:53] <zyga> mborzecki: can you please have a 2nd look on 5155
[05:54] <mborzecki> looking
[05:54] <zyga>  I bought a USB-C power bank at the airport
[05:55] <zyga> it works with laptops and phones alike so I was looking forward to use it with my thinkpad
[05:55] <zyga> but obviously, there's a bug and the kernel doesn't say "hey, I'm a type-c power sink, gimme power" and it doesn't charge in linux
[05:55] <mvo> hey mborzecki good morning
[05:55] <zyga> the power bank has fantastic reviews all around and works everywhere else
[05:55] <zyga> a bit of a sigh :)
[05:56] <zyga> so I will go on a type-c bug hunt to see why
[05:56] <zyga> I just found this interesting that in the future, even charging needs a non-trivial stack of software that must work just right
[06:42] <mborzecki> pedronis: added tests for setup-profiles undo in #4996
[06:42] <mup> PR #4996: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <https://github.com/snapcore/snapd/pull/4996>
[06:48] <mup> PR snapd#5143 closed: tests: speed up save/restore snapd state for all-snap systems during tests execution <Squash-merge> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5143>
[06:49] <zyga> mvo: do you happen to remember if LTS to LTS update kicks in at the first point release? that is 16.04 will update but only to 18.04.1?
[06:50] <zyga> tests are rather red today
[06:50] <zyga> and often end with
[06:50] <zyga> The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over).
[06:50] <mvo> zyga: yes, first point release
[06:51] <zyga> ah, thanks for confirming that
[06:52] <mvo> zyga: testsuite> anything in particular you noticed? when I looked earlier it was some repo that could not be cloned
[06:52] <zyga> the thing is, I don't know, it's just red and overflowing logs
[06:52] <zyga> I've yet to find an efficient way to find what broke
[07:00] <zyga> eh
[07:01]  * zyga filed the bug on dh-golang only to notice (at the end of the report) that the email address is "zyga@debian-9"
[07:01] <mvo> bugs via email ftw :/
[07:01] <zyga> debian FTW
[07:02] <zyga> well, it should show up here, eventually: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=dh-golang;dist=unstable
[07:04] <mborzecki> new TLD debian-9 :)
[07:04] <mvo> hm, having .ubuntu as a TLD would be cool
[07:04] <pstolowski> morning
[07:05] <mvo> hey pstolowski
[07:05] <mborzecki> pstolowski: hey
[07:05] <mborzecki> mvo: ICANN awaits your application :P
[07:05] <zyga> morphis: hey, andbox-support PR needs some love
[07:05] <mvo> mborzecki: heh, maybe a bit too much work for my free evenings ;)
[07:06] <zyga> mvo: it's just 5000 and you own it
[07:06] <zyga> custom TLD were approved a while a go
[07:06] <mborzecki> zyga: 5000 of what currency?
[07:06] <zyga> USD AFAIK
[07:06] <mvo> zyga: yeah, but you also need to make some comitments technically iirc, no? I don't remember the details though
[07:07] <mborzecki> heh, doped to dogecoins :)
[07:07] <mborzecki> s/doped/hoped/
[07:07] <zyga> oh
[07:07] <zyga> it's more pricy than that
[07:09] <zyga> $185,000
[07:09] <zyga> ouch
[07:11] <mvo> autsch indeed
[07:35] <zyga> journal cursors break some tests
[07:35] <zyga> it looks like buffering is in theway
[07:36] <mborzecki> iirc there's a --sync flag but it didn't work on 14.04 or sth
[07:37] <mborzecki> anyways, in snapd-notify test, i think it'd be better to systemctl show -p SubState and ActiveState directly
[07:37] <zyga> it failed on a totally unrelated test now
[07:39] <morphis> zyga: hey! I know, but I am waiting for general feedback from jdstrand first before doing any further work. I have a side-channel conversation with him on this already.
[07:39] <zyga> morphis: ack
[07:39] <morphis> the PR might go into a completely different direction
[07:39] <zyga> you still need to add those tests
[07:39] <zyga> all interfaces need tests :)
[07:39] <zyga> so ... just saying
[07:40] <Moruy> Hi!
[07:40] <zyga> hey Moruy
[07:41] <Moruy> Can I set up a package mirror snap?
[07:42] <morphis> zyga: I know, but will skip that until we're at that point :-)
[07:42] <zyga> Moruy: would you like to mirror snap packages or install a snap that mirrors some other packages?
[07:44] <Moruy> I want to mirror that "https://api.snapcraft.io/", but it's locked in source code.
[07:45] <zyga> Moruy: you want to deploy this instead: https://forum.snapcraft.io/t/announcing-snap-enterprise-proxy-beta/4666
[07:45] <zyga> you cannot mirror api.snapcraft.io as it is not a static website
[07:48] <Moruy> Frankly, I want setup up a mirror that  similar with docker mirror.
[07:48] <zyga> you cannot mirror the snap store, the only supported configuration is local deployment of a snap proxy
[07:50] <Moruy> reverse proxy?
[07:50] <zyga> please read the post I linked to
[07:52] <Moruy> (ಥ⌣ಥ)
[07:52] <popey> Is there some way to purge old revisions of snaps in one go?
[07:52] <popey> I have run out of disk space, and the old revisions are eating a ton of it
[07:53] <zyga> popey: nope, I don't think there is
[07:53] <popey> :(
[07:54] <popey> 24G     /var/lib/snapd/snaps/
[07:54] <zyga> popey: find the top three using ncdu
[07:54] <zyga> and remove those specifically
[07:54] <popey> that's not very user friendly
[07:54] <popey> (and yes, I already did that)
[07:57] <Moruy> Enterprise Proxy is so complex and I will try reverse proxy to mirror it.
[07:57] <zyga> it won't work Moruy
[07:59] <popey> https://forum.snapcraft.io/t/configure-number-of-old-revisions-to-keep/2337/4
[07:59] <popey> :(
[08:02] <Moruy> api.snapcraft.io low download speed, it not has any CDN using.
[08:02] <zyga> Moruy: all downloads are using the CDN
[08:03] <mup> PR snapd#5204 opened: data: add helper that can generate/start/stop the snapd service <Created by mvo5> <https://github.com/snapcore/snapd/pull/5204>
[08:03] <mvo> zyga: ^- this is based on what we talked about yesterday
[08:03] <zyga> yep, looking
[08:03] <zyga> sigh
[08:03] <zyga> where are google credentials for spread stored?
[08:03]  * zyga cannot find them
[08:06] <Chipaca> moin moin
[08:07] <mborzecki> zyga: travis secrets maybe?
[08:07] <Chipaca> mvo: one thing that core18 needs, that I don't know a tidy way of getting it there short of forking, is the system-shutdown helper
[08:07] <zyga> no, it's that thing you need to keep somewhere on your disk
[08:08] <Chipaca> mvo: … although, it's copied every time, so maybe just copy it from the snapd snap
[08:08] <Chipaca> hmm
[08:09] <mvo> Chipaca: yeah, it seems like we can run it from the snapd snap
[08:09] <zyga> mvo: reviewed
[08:10] <mvo> zyga: thank you
[08:10] <mvo> Chipaca: the PR is just opened is about making our service work on bases, we probably need to plug it in there (also repairs and all the other services we use)
[08:10] <popey> How terrible is this? https://www.irccloud.com/pastebin/MMTaDh6u/purge_old_snap_revisions.sh
[08:10] <popey> ^ zyga / Chipaca - opinions?
[08:11] <Chipaca> popey: I have *lots* of opinions
[08:11]  * Chipaca clicks the link
[08:11] <zyga> I don't think you need to close all snaps
[08:11] <popey> what if I still have a snap running
[08:11] <zyga> disables snaps don't run
[08:11] <popey> like firefox which I have running for days, and it's refreshed already
[08:11] <zyga> *disabled
[08:11] <zyga> ahhh
[08:11] <zyga> bummer :)
[08:12] <Chipaca> popey: it  won't be happy if you do
[08:12] <Chipaca> popey: OTOH, we also do it
[08:12] <Chipaca> so, it won't be super sad either
[08:12] <popey> warning is really just ass-covering
[08:12] <popey> 12G     /var/lib/snapd/snaps/
[08:12] <popey> it's halved the amount of space used
[08:12] <popey> (I ran it before you reviewed it) :)
[08:13] <Chipaca> popey: the idea is sane
[08:13] <mvo> zyga: thanks for the review. I ran it on a core18 system. why? anything that looks suspicious?
[08:13] <popey> thanks
[08:13] <zyga> mvo: no, I just was curious since we don't have any automated feedback yet
[08:14] <Chipaca> popey: I'd criticise the shell, but if it works and it's just a personal tool it's probably fine
[08:14] <mvo> zyga: yeah, I was thinking what can be done, spread testing this at this point is hard :/ or a bit theoretical, i.e. I could very that the output looks vaguely correct but the real start is harder
[08:14] <popey> So you don't think it's a good idea to share it Chipaca ?
[08:14] <popey> (people *keep* asking for this feature)
[08:15] <Chipaca> popey: in its present state, yes don't share it
[08:15] <Chipaca> popey: making it robust and sharing it, … a little torn about it
[08:15] <zyga> making it a feature and releasing it
[08:15] <zyga> snap remove --disabled
[08:16] <mvo> would be nice to have a "snap set system.keep-revision=" option
[08:16] <Chipaca> yeah, i'd rather do that :-)
[08:16] <Chipaca> both things
[08:16] <Chipaca> in fact, today's friday, means we can do 20% stuff right?
[08:16] <popey> meanwhile, disks are ffilling up :)
[08:16] <zyga> ohh
[08:16] <zyga> Friday
[08:16] <zyga> coming back from holidays mid week is weird
[08:16] <zyga> I thought it is Tuesday
[08:16] <Chipaca> zyga: it's not friday for you! you've had too much fun
[08:16]  * Chipaca takes away zyga's friday rights
[08:17]  * Chipaca adds extra tails to his whip
[08:17] <zyga> Chipaca: I await the day when we are both at a bar in Spain and have a beer together watching the sea quietly shimmer outside
[08:17] <zyga> Chipaca: (the sea in Spain is oddly silent)
[08:18] <Chipaca> zyga: in barcelona, yeah
[08:18] <Chipaca> long beach
[08:18] <Chipaca> other places not so much
[08:19] <zyga> Chipaca: at this point the only question is "when"
[08:20] <Chipaca> zyga: either in the next month, or not for a ~year
[08:20] <Chipaca> judging by past performance of the home office
[08:21] <Chipaca> popey: how about: https://pastebin.ubuntu.com/p/6KWZXtJWwS/
[08:21] <pstolowski> mvo: one tiny tiny nitpick re 5183 (feel free to ignore)
[08:21]  * Moruy 
[08:22] <popey> Chipaca: oh, that's prettier. I like that. Thanks, learned something too :) <3
[08:22] <Chipaca> popey: shellcheck says I should use -r on the read,  but I don't know if that's portable
[08:22] <Chipaca> popey: also, it needs a comment about GDPR complaince just before 'set -eu'
[08:23] <popey> lulz
[08:23] <popey> Chipaca: https://askubuntu.com/questions/1036633/how-to-remove-disabled-unused-snap-packages-with-a-single-line-of-command
[08:23] <popey> earn some karma by pasting it there :)
[08:23] <mborzecki> Chipaca: you're clearly excluding 'eu', so no gdpr notice needed
[08:24] <mvo> pstolowski: thank you for the review. I think I can just remove those line and it makes sense to cleanup the control file too
[08:25] <zyga> Chipaca: LOL
[08:25]  * zyga googles for those google credentials
[08:28] <zyga> Chipaca: remember when I was playing with flatpak edit?
[08:28] <zyga> gedit
[08:28] <Chipaca> popey: https://askubuntu.com/a/1040131/711
[08:28] <zyga> I just noticed that left ~/.var on my disk
[08:29] <zyga> with lots of goo inside
[08:29]  * popey upvotes
[08:29] <popey> thanks Chipaca
[08:29] <pedronis> zyga: are you looking for ~/.config/gcloud/application_default_credentials.json   ? or something else
[08:29] <zyga> ah
[08:29] <zyga> yes, thank you pedronis !
[08:30] <Chipaca> popey: I dount this will get me over the 10k hump though :-)
[08:30] <popey> Chipaca: there are a thousand other snap questions you could answer :)
[08:30] <popey> which would
[08:31] <Chipaca> popey: I got very demotivated last time I did a round of questions there as there were a lot about how much my work sucks
[08:31] <Chipaca> popey: but i'll give it another go sometime soon (or you can point me at 'em)
[08:31] <popey> we have a bot in our slack channel which announces them all every morning to motivate us to answer them.
[08:33] <popey> https://askubuntu.com/unanswered/tagged/snap?tab=noanswers
[08:33] <popey> ones with no answers, tagged with snap.
[09:03] <Chipaca> popey: if you know somebody in jetbrains, maybe forward https://askubuntu.com/q/988315/711 to them
[09:05] <Chipaca> popey: in askubuntu, how do you flag something that should be a bug report instead?
[09:05] <Chipaca> it's not 'too broad' -- it's too narrow :-)
[09:06] <pedronis> mmh, pstolowski, I had forgotten but auto-connect was simply ignoring conflicts, it still seems right tbh
[09:06] <pedronis> so only reconnect could have this bug
[09:07] <pstolowski> looking
[09:09] <pstolowski> pedronis: hmm, yes and no.. we would never auto-connect in case of conflict, no?
[09:09] <pedronis> pstolowski: don't we have a test exactly about that?
[09:10] <Chipaca> jdstrand: if you're feeling lyrical, https://askubuntu.com/q/789231/711
[09:11]  * zyga takes the dog out
[09:16] <pstolowski> pedronis: indeed we have. now i wonder if the test is doing the right think, or if there is something else
[09:16] <pstolowski> *thing
[09:16] <pedronis> pstolowski: by definition  if we reached autoconnect we are done with our link-snap and setup-profiles, otoh the other side if it's conflicting hasn't
[09:16] <pstolowski> pedronis: right, that's it
[09:16] <pedronis> pstolowski: so it will do autoconnect later and shouldn't get a conflict
[09:17] <pstolowski> and it will actually prevent running everything twice i think
[09:17] <pedronis> yes
[09:18] <pstolowski> okay, so probabaly i shouldn't touch autoconnect logic
[09:18] <pedronis> but you changed ConnectOnInstall
[09:18] <pedronis> so you need to do something
[09:19] <pstolowski> yes
[09:19] <pedronis> pstolowski: btw the same logic would probably also have worked for reconnect
[09:19] <pedronis> except reconnect is less best-effort
[09:19] <pedronis> than autoconnect
[09:19] <pedronis> so not sure we can trust the fact that the other side will do reconnect
[09:21] <pedronis> also probably we care about errors more
[09:23] <pstolowski> yes
[09:25] <pedronis> pstolowski: otoh we wouldn't need the helper,   and also doing things twice is strange problematic on its own
[09:25] <pedronis> even for reconnect
[09:30] <pedronis> pstolowski: anyway I think we should indeed put back autoconnect to ignore error/conflicts
[09:30] <pedronis> pstolowski: keep the full new logic only for reconnect
[09:37] <pedronis> pstolowski: added a couple of comments about this
[09:37] <pstolowski> thanks
[09:42] <mup> PR snapd#5183 closed: snapcraft.yaml: add minimal snapcraft.yaml with custom build <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5183>
[09:46] <mup> PR snapd#5205 opened: packaging: fix description <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5205>
[09:47] <kjackal> is there a hook firing when a new revision is applied?
[09:48] <kjackal> I mean when a snap get refressed/upgraded can I run anything?
[09:52] <kjackal> its the configure hook
[10:00] <pedronis> pstolowski: question: on reconnect the hook see the dynamic attributes as set on connect, right? not just the static ones?
[10:01] <pstolowski> pedronis: yes, the will come from prepare- hook
[10:01] <pstolowski> *they
[10:01] <pedronis> pstolowski: no,  that is not what I mean
[10:01] <pedronis> I probably should look at the code
[10:02] <pstolowski> pedronis: it should see potentially new attributes as that's the goal of reconnect
[10:02] <pstolowski> but perhaps i misunderstand the question
[10:03] <pedronis> pstolowski: it doesn't
[10:03] <pedronis> pstolowski: I thought that on a reconnect we would set the dynamic attributes as their are on the connection that is redone
[10:03] <pedronis> but it seems we start from scratch
[10:03] <pstolowski> yes we start from scratch
[10:04] <pedronis> pstolowski: the issue is if the slot side reserve some resource on connect, it willl do it again on reconnect
[10:04] <pedronis> there should be a way for it to reuse the same resource
[10:04] <pedronis> one way would be to give the last set state of the dynamic attrs
[10:04] <pedronis> maybe there's another way
[10:04] <pedronis> but starting completely from scratch
[10:05] <pedronis> seems too simple
[10:06] <pstolowski> pedronis: perhaps we should run disconnect hooks then
[10:06] <pedronis> pstolowski: it it picks a new resources the slot wouldn't even know the old one is not in use anymore
[10:06] <pstolowski> otherwise we have same problem as discussed before with undoing stuff
[10:06] <pedronis> pstolowski: then it really becomes  disconnect/connect
[10:06] <pedronis> it would work, but seems inefficent
[10:06]  * zyga made some ice coffee 
[10:06] <zyga> today is a pretty hot day
[10:07] <mborzecki> pedronis: when validating uniqueness of appstream-ids, we'll bail out only during snap pack --check-skeleton, but when installing a snap we'd just log something, does that sound ok?
[10:07] <pstolowski> pedronis: yes it would definately be inefficient and add even more hooks run every time
[10:07] <pedronis> pstolowski: :(
[10:07] <pedronis> pstolowski: anyway, do you see the problem I'm describing?
[10:07] <pstolowski> pedronis: we can pass existing values, it just adds more complexity for hook authors
[10:07] <pstolowski> pedronis: yes yes
[10:08] <pedronis> mborzecki: do we have other things we treat like that? hard error on pack, just logged on install?
[10:09] <mborzecki> pedronis: i don't think so
[10:09] <pedronis> mborzecki: so maybe not
[10:09] <pedronis> just error
[10:09] <pedronis> in both cases
[10:09] <mborzecki> fair enough
[10:10] <mborzecki> i mean review tools should probably catch this, so such snap would not be in he store anyway
[10:10] <pedronis> mborzecki: yea, I pinged jdstrand in the forum about that
[10:10] <mborzecki> (hopefully?)
[10:10] <pedronis> mborzecki: anyway atm there are not many snaps with this set
[10:10] <mborzecki> yup, fair point
[10:11] <Chipaca> hmm, shouldn't "snap get system refresh.timer" work?
[10:11] <mborzecki> well, i know of telegram for sure, and there's also one that i just published tests-snapd-appstreamid
[10:11] <zyga> wow, some heavy rain
[10:11] <zyga> like in some jungle :)
[10:11] <mborzecki> maciek@galeon:~ sudo snap get system refresh.timer
[10:11] <mborzecki> 00:00-24:00/192
[10:11] <mborzecki> Chipaca: ^^
[10:12] <pedronis> mborzecki: it doesn't here
[10:12] <pedronis> did we stopped storing it in the config if it's the default?
[10:12] <Chipaca> and the error message is rather poor
[10:12] <mborzecki> Chipaca: what does it say?
[10:12] <Chipaca> $ snap get system refresh.keep-inactive
[10:12] <Chipaca> error: snap "core" has no "refresh" configuration option
[10:12] <pedronis> I don't have either schedule or timer
[10:13] <mborzecki> aah ok, you've never set it
[10:13] <pedronis> in my refresh config
[10:13] <Chipaca> er, well, same with .timer :-)
[10:13] <mborzecki> Chipaca: can you try set and then get ?
[10:13] <pedronis> Chipaca: snap refresh --time prints it though?
[10:13] <Chipaca> pedronis: yes
[10:13] <Chipaca> mborzecki: sure, if i set it it works
[10:14] <pedronis> mborzecki: the issue is that at some point at least for schedule we were setting it in the config even when we picked the default
[10:14] <mborzecki> Chipaca: or snap get system -d
[10:14] <mborzecki> pedronis: yeah, iirc it was set as in set-set, but then that went away when refresh timer was introduced with the comment that we should not set it if it's unset
[10:15] <pedronis> Chipaca: ^
[10:17] <mup> PR snapd#5206 opened: get-deps: work with an unset GOPATH too <Created by mvo5> <https://github.com/snapcore/snapd/pull/5206>
[10:21] <zyga> mvo your simple pr failed with
[10:21] <zyga> The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over).
[10:22] <mup> PR snapd#5207 opened: overlord/{config,snap}state: the number of inactive revisions is config <Created by chipaca> <https://github.com/snapcore/snapd/pull/5207>
[10:23] <Chipaca> ^ 'snap set system refresh.keep-inactive=99' (for popey)
[10:23] <zyga> can we get that -v filter-out PR merged?
[10:24] <pedronis> zyga: do we know it helps?  it's been -v since forever, what did change?
[10:25] <pedronis> I still find a bit too hackish
[10:25] <zyga> we spawn more machines
[10:25] <pedronis> ?
[10:25] <zyga> so if something fails early we see all the goo out of package building multiplied numerous times (per machine)
[10:25] <zyga> I ran dpkg-buildpackage and it's far shorter now
[10:25] <zyga> try it, it's really much more readable
[10:40] <Chipaca> zyga: I enjoyed getting all the emojis way too much
[10:40] <Chipaca> it's a high bar, but I will strive for it more often
[10:57] <mup> PR snapd#5208 opened: interface hooks: update old AutoConnect methods <Created by stolowski> <https://github.com/snapcore/snapd/pull/5208>
[11:02] <pedronis> pstolowski: do you need more input from me?   connect vs reconnect state is probably something to mention at the standup
[11:03] <pstolowski> pedronis: indeed; no, thank you for the review
[11:17] <pedronis> Chipaca: btw, do I remember correctly that we still need to give proper error codes to conflict errors?
[11:24] <pedronis> mvo: do have a SRU in progress for xenial?
[11:26] <pedronis> Chipaca: s/code/kind/
[11:30] <Chipaca> pedronis: possibly
[11:31] <Chipaca> pedronis: we also have not advanced returning error kinds on async jobs
[11:34] <pedronis> Chipaca: is that related?
[11:35] <Chipaca> pedronis: I don't know the context of your question :-) so, maybe
[11:35] <pedronis> Chipaca: we get conflict error because creating the changes, no?
[11:35] <pedronis> I do remember you had a case for returning errors on async
[11:35] <Chipaca> pedronis: s/because/before/ yes
[11:36] <Chipaca> so they should be async indeed
[11:36] <Chipaca> i mean sync
[11:36] <Chipaca> heh
[11:36] <pedronis> but I don't remember what it was
[11:37] <zyga> Chipaca: hey, question
[11:37] <zyga> how to debug completion tests?
[11:37] <zyga> better yet
[11:37] <zyga> I'm in the debug shell
[11:37] <zyga> how do I run them?
[11:37] <Chipaca> zyga: https://forum.snapcraft.io/t/debugging-tab-completion/4198 ?
[11:37] <Chipaca> zyga: ah
[11:38] <zyga> failure log https://www.irccloud.com/pastebin/yC9IEnv0/
[11:38] <Chipaca> zyga: expect -d -f thefailingthing.exp
[11:38] <Chipaca> zyga: or drop the -d to understand the error, then add it back to understand why the error
[11:40] <zyga> I need to export those variables?
[11:40] <Chipaca> zyga: which variables?
[11:40] <zyga> OUT, KEY etc
[11:40] <zyga> otherwise I get an error instantly
[11:41] <zyga> after setting some vars
[11:41] <zyga> more errors https://www.irccloud.com/pastebin/9NmWJCbi/
[11:41] <Chipaca> zyga: ah, sorry was looking at the main/completion
[11:42] <Chipaca> zyga: yes, look at task.yaml for that
[11:43] <Chipaca> zyga: that last one is an error?
[11:43] <Chipaca> that looks like success to me
[11:43] <Chipaca> maybe i'm missing something
[11:44] <zyga> does anything in https://api.travis-ci.org/v3/job/378833810/log.txt look like an error?
[11:44] <Chipaca> zyga: in the first thing you pasted there was an error
[11:44] <jdstrand> 05:10 < pedronis> mborzecki: yea, I pinged jdstrand in the forum about that
[11:44] <jdstrand> pedronis: I just came online, but may have missed it if it wasn't last night. what topic? ^
[11:44] <Chipaca> zyga: 'does <....> match <..>? no\n timed out'
[11:45] <Chipaca> zyga: that's what errors look like
[11:45] <mborzecki> jdstrand: https://forum.snapcraft.io/t/support-for-appstream-id/2327
[11:45] <zyga> Chipaca: honestly all those tests look like magic to me
[11:45] <zyga> and I have no idea why it fails
[11:45] <Chipaca> zyga: it failed because it completed nothing
[11:45] <Chipaca> zyga: why did it complete nothing? can you reproduce that?
[11:46] <pedronis> jdstrand: https://forum.snapcraft.io/t/support-for-appstream-id/2327/29
[11:46] <zyga> Chipaca: ... perhaps? tell me what to do
[11:46] <Chipaca> zyga: standing in that directory, type test-snapd-complexion <tab><tab>
[11:46] <zyga> the branch enables apparmor
[11:46] <zyga> but I don't see any denials
[11:46] <zyga> ok
[11:46] <pedronis> jdstrand: it's about review-tools   checking that common-id doesn't get repeated across apps in the same snap
[11:46] <Chipaca> zyga: it should offer 'a/   b/   bar  baz  d/   foo'
[11:46] <Chipaca> zyga: (same as 'ls <tab><tab>' would)
[11:47] <zyga> google:opensuse-42.3-64 .../tests/completion# test-snapd-complexion
[11:47] <zyga> test-snapd-complexion      test-snapd-complexion.two
[11:47] <zyga> it seems it doesn't
[11:47] <Chipaca> (i lied, ls wouldn't)
[11:47] <Chipaca> zyga: so, tab completion isn't working in opensuse
[11:47] <zyga> mmm
[11:47] <Chipaca> zyga: sadface
[11:47]  * zyga thinks
[11:47] <Chipaca> hold on
[11:47] <zyga> but it used to
[11:47] <zyga> it's just broken here in this branch
[11:48] <Chipaca> zyga: did you enabe tab completion in that shell
[11:48] <Chipaca> enable*
[11:48] <zyga> oh? no
[11:48] <zyga> how do I do that?
[11:49] <pedronis> jdstrand: here's the wip snapd check:  https://github.com/snapcore/snapd/pull/5199/commits/17d9cab6366de447c2aa8049a1fd10b05ab947d4
[11:49] <mup> PR #5199: many: expose AppStream IDs (AKA common ID) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5199>
[11:49] <zyga> jdstrand: I fixed 5203 for you
[11:50] <Chipaca> zyga: if you  ls <tab><tab>, does it list things for you?
[11:50] <zyga> Chipaca: yes
[11:50] <Chipaca> zyga: ok
[11:50] <zyga> also tab tab completed the command names above
[11:50] <zyga> so some part of it must work
[11:50] <Chipaca> zyga: you need to source one of the .complete files
[11:50] <pedronis> mborzecki: if the snap is already created you need to ask store admins to transfer it to canonical shared account
[11:50] <Chipaca> zyga: 1 sec
[11:50] <zyga> thanks!
[11:50] <jdstrand> zyga: oh, I was just looking at that
[11:50] <zyga> I really want to get to the bottom of that
[11:50] <zyga> to get apparmor operational in opensuse
[11:50] <zyga> and in general, in more distros that can just opt in
[11:50] <jdstrand> zyga: thanks
[11:51] <zyga> jdstrand: :-)
[11:51] <Chipaca> zyga: source hosts_n_dirs.complete
[11:51] <zyga> ack
[11:51] <zyga> done
[11:51] <Chipaca> zyga: now what does test-snapd-complexion <tab><tab> do
[11:51] <zyga> it is completing ... ip addresses?
[11:51] <zyga> google:opensuse-42.3-64 .../tests/completion# test-snapd-complexion
[11:51] <zyga> ::1               fe00::0           ff02::1           ff02::3           ipv6-allhosts     ipv6-allrouters   ipv6-localnet     ipv6-mcastprefix  simple/
[11:51] <zyga> data/             ff00::0           ff02::2           indirect/         ipv6-allnodes     ipv6-localhost    ipv6-loopback     localhost         snippets/
[11:52] <Chipaca> ah, right, 1 sec
[11:52] <Chipaca> zyga: look at hosts_n_dirs.sh
[11:52] <Chipaca> zyga: do that :-)
[11:52] <zyga> ah
[11:53] <Chipaca> zyga: to be clear, none of this involves apparmor or anything
[11:53] <zyga> # cat data/hosts.txt
[11:53] <zyga> 127.1.2.3 foo bar baz
[11:53] <Chipaca> zyga: at least from the 'simple' side of things, this is just sanity-checking the test suite
[11:53] <Chipaca> the 'indirect' one does the same via a snap
[11:54] <Chipaca> and that one does involve the whole dance
[11:54] <zyga> I see
[11:54] <zyga> and the .two app?
[11:54] <zyga> the .two app appears to complete stuff in practice
[11:55] <zyga> well, they both (main app and .two app) complete the exact same thing
[11:55] <Chipaca> zyga: that's expected
[11:56] <Chipaca> zyga: I'll go grab lunch
[11:56] <zyga> can I trigger the completion failure somehow from this interactive shell?
[11:56] <zyga> ok
[11:56] <Chipaca> zyga: i can dig into this after
[11:56] <zyga> I'll look at the non-completion tests
[11:56] <zyga> thanks!
[11:56] <Chipaca> zyga: my memory is stale, probably easier for me to debug it if it's reproducible
[11:56] <zyga> yeah, all the time
[11:56] <Chipaca> perfect
[12:04] <zyga> Chipaca: interestingly, only _some_ have failed
[12:04] <zyga> many of those work
[12:04] <Chipaca> zyga: list 'em for me :-)
[12:04] <zyga> one sec
[12:05] <zyga> trying to close all other instances
[12:05] <Chipaca> k
[12:06] <zyga> failed tests https://www.irccloud.com/pastebin/N38F51o6/
[12:08] <Chipaca> zyga: that's all the ones that go through (de)serialization
[12:08] <zyga> mmm
[12:08] <Chipaca> zyga: ie all the ones that talk to snap run
[12:08] <zyga> mm
[12:08] <zyga> I'll run the non-completion tests (well, running now) and see if there are any hints
[12:08] <zyga> maybe it's something simple and obviously missing/broken
[12:09] <Chipaca> ok
[12:09]  * Chipaca ~> lunch or death
[12:17] <mvo> pedronis: there is a SRU in progress for xenial, yes. do we need anything in there?
[12:19] <pedronis> mvo: no, just wondered, because I noticed snapd there doesn't have SNAPD_BASES_CHANNEL yet afaict
[12:19] <mvo> pedronis: yeah, its time that 2.33 gets out of the door :)
[12:19] <mup> PR snapd#5205 closed: packaging: fix description <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5205>
[12:20] <pedronis> mvo: I think is in one of the 2.33 already
[12:20] <pedronis> possibly
[12:20] <pedronis> but yea
[12:22] <zyga> cachio_: hey, what's the chance of us getting a tumbleweed image?
[12:22] <mup> PR snapd#5202 closed: packaging: filter out verbose flags from "dh-golang" <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5202>
[12:25] <zyga> Chipaca: don't waste your time please, I found the issue
[12:25]  * Chipaca ~> second lunch
[12:25] <Chipaca> :-D
[12:27] <mup> PR snapd#5155 closed: interfaces/apparmor: use strict template on openSUSE tumbleweed <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5155>
[12:27] <pedronis> heh, I meant 2.32
[12:28] <mvo> pedronis: indeed, 2.32.3.2 is where we are in xenial I need to chase sergio
[12:29] <mup> PR snapd#5118 closed: packaging/opensuse: build with apparmor <Squash-merge> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5118>
[12:30] <pedronis> pstolowski: btw,  I'm thinking a bit more, I'm coming to the conclusion that we need to conflict also on connect carefully, I mean the same exact connect should be added at most once to a change
[12:33] <zyga> cachio_: hey
[12:33] <zyga> cachio_: can you work with me for a moment, I'd like to build a tumbleweed image for opensuse
[12:35] <mup> PR snapd#5209 opened: packaging: add packaging for openSUSE Tumbleweed <Created by zyga> <https://github.com/snapcore/snapd/pull/5209>
[12:36] <mup> PR snapd#5210 opened: spread: openSUSE LEAP 42.2 was EOLd in January, remove it <Created by zyga> <https://github.com/snapcore/snapd/pull/5210>
[12:36] <pstolowski> pedronis: you mean when we do multiple Connects in a single change?
[12:41] <pedronis> pstolowski: yes,  I fear  we will get very confused if we are not careful
[12:41] <pedronis> because of state
[12:41] <pedronis> and hooks
[12:45] <pedronis> pstolowski: the connect-plug/slot-* hook cannot change the attributes anymore, is that right? only prepare can change them?
[12:48] <zyga> https://lwn.net/Articles/755238/  <- entitlements are a little bit like interfaces
[12:51] <mup> PR snapd#5206 closed: get-deps: work with an unset GOPATH too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5206>
[12:54] <pstolowski> pedronis: yes
[13:06] <Chipaca> mvo: ＭＡＧＩＣ
[13:08] <mvo> Chipaca: \o/
[13:15] <mup> PR snapd#5211 opened: snapcraft: use dpkg-buildpackage options that work in xenial <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5211>
[13:21] <mup> PR snapd#5200 closed: interfaces: reconnect, fix for autoconnect/reconnect conflict check <Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/5200>
[13:24] <mup> PR snapd#5196 closed: ifacestate: FindSnapsWaitingFor helper <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/5196>
[13:36] <pedronis> pstolowski: let me know if you want to discuss a bit about checking conflicts for connect/disconnect
[13:36] <pstolowski> pedronis: i've headache.. not the best moment :/
[13:36] <pedronis> pstolowski: let's do it on monday then
[13:36] <pstolowski> thanks
[13:36] <mup> PR snapd#5210 closed: spread: openSUSE LEAP 42.2 was EOLd in January, remove it <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5210>
[13:37] <pedronis> pstolowski: and get well!
[13:37] <pstolowski> will try to propose error handling improvement in the meantime
[13:37] <pstolowski> thanks1
[13:39] <mvo> pstolowski: yeah, get well!
[13:41] <pstolowski> thanks, it's not too bad
[13:45] <zyga> niemeyer: can you have a quick look at https://github.com/snapcore/snapd/pull/4889#discussion_r190898209
[13:45] <mup> PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>
[13:45] <niemeyer> Heads up: forum is about to go down for maintenance!
[13:47] <zyga> jdstrand: is there anything to do more on #5170
[13:47] <mup> PR #5170: interfaces/builtin: add adb-support interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>
[13:47] <niemeyer> zyga: I can, but not right now.. forum migration under way
[13:47] <jdstrand> zyga: I continue to have it on my list for today. keep in mind, it is still morning here ;)
[13:48] <zyga> jdstrand: no worries, thank you :-)
[13:53] <mup> PR snapd#5211 closed: snapcraft: use dpkg-buildpackage options that work in xenial <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5211>
[14:04] <mup> PR # closed: snapd#4416, snapd#4700, snapd#4767, snapd#4889, snapd#4917, snapd#4940, snapd#4951, snapd#4996, snapd#5030, snapd#5081, snapd#5091, snapd#5122, snapd#5162,
[14:04] <mup> snapd#5170, snapd#5176, snapd#5178, snapd#5184, snapd#5187, snapd#5197, snapd#5198, snapd#5199, snapd#5203, snapd#5204, snapd#5207, snapd#5208, snapd#5209
[14:05] <mup> PR # opened: snapd#4416, snapd#4700, snapd#4767, snapd#4889, snapd#4917, snapd#4940, snapd#4951, snapd#4996, snapd#5030, snapd#5081, snapd#5091, snapd#5122, snapd#5162,
[14:05] <mup> snapd#5170, snapd#5176, snapd#5178, snapd#5184, snapd#5187, snapd#5197, snapd#5198, snapd#5199, snapd#5203, snapd#5204, snapd#5207, snapd#5208, snapd#5209
[14:15] <mup> PR snapd#5212 opened: xdgopenproxy: skip TestOpenUnreadableFile when run as root <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5212>
[14:17] <niemeyer> Forum migration completed. You may need to hard-refresh or restart your browser for it to see the new IP address.
[14:30] <zyga> Chipaca, jdstrand: commented on https://askubuntu.com/questions/789231/how-are-snap-applications-being-protected/1040259#1040259
[14:30]  * popey upvotes
[14:37] <sil2100> mvo: is there any reason why we're running travis checks for core18 on trusty and not on xenial?
[14:37] <sil2100> Just curious
[14:37] <zyga> sil2100: travis sucks
[14:37] <zyga> sil2100: no, we should use xenial if we can (there's a switch AFAIK)
[14:47] <sil2100> zyga: ok, thanks ;)
[14:48] <sil2100> yay travis is now giving some useful info
[14:49] <zyga> popey: how can I mark one post as a duplicate of another (on askubuntu)
[14:50] <Pharaoh_Atem> zyga: it'd be interesting if snapd was wired up with centos ci to use spread
[14:50] <Pharaoh_Atem> https://wiki.centos.org/QaWiki/CI/GettingStarted
[14:50] <Pharaoh_Atem> https://wiki.centos.org/QaWiki/CI/GithubIntegration
[14:50] <zyga> what would be the point of that?
[14:51] <Pharaoh_Atem> some better/more reliable backends for CI
[14:52] <Pharaoh_Atem> the current CI stuff has been very hokey :/
[14:52] <zyga> yes but the problem is everyone has something and then every snapd developer needs to know how to use _each_ of those systems to work
[14:52] <zyga> yes, I would love to see a general way to build spread images for qemu, google or other systems
[14:57] <Chipaca> zyga: under the question, click on 'close'
[14:57] <Chipaca> zyga: there's a "is duplicate of..." option
[14:58] <zyga> thanks!
[14:58] <zyga> mvo:
[14:58] <zyga> what is this?
[14:58] <zyga> +ExecStartPre=/bin/touch /dev/iio:device0
[14:59] <zyga> this is from 73ff712a89aa3bd65ab8b5b23e956413294375c8
[14:59] <Chipaca> zyga: a hack to fake a device for a test
[14:59] <Chipaca> zyga: tests/main/interfaces-iiio
[14:59] <Chipaca> iio
[14:59] <Chipaca> io
[14:59] <Chipaca> o
[15:00] <zyga> why does this fail? https://www.irccloud.com/pastebin/v4Mm7FrG/
[15:00] <zyga> https://www.irccloud.com/pastebin/gywakiP4/
[15:00] <zyga> hmmhmmhmm
[15:13] <mvo> sil2100: no good reason, if we can switch to xenial I'm all for it
[15:14] <mup> PR snapd#5212 closed: xdgopenproxy: skip TestOpenUnreadableFile when run as root <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5212>
[15:15] <Pharaoh_Atem> mvo: travis still can't do xenial :/
[15:16] <sil2100> Seems to work here
[15:16] <mvo> sil2100: ohhhhh, nice
[15:16] <sil2100> I mean, it still segfaults, but running on xenial
[15:16] <sil2100> (investigating further)
[15:17] <mvo> sil2100: hm, sad that it still segfaults, I wonder if it works in a normal VM
[15:20] <sil2100> Let me test that
[15:21] <sil2100> Since there's nothing else obviously broken
[15:58] <popey> Chipaca: is there any caching when doing "snap find"?
[15:58] <popey> I have updated sections in the store and one isn't showing up for me
[15:59] <popey> snap find --section=server
[15:59] <popey> ^ that should work, but it doesn't
[16:10] <noise][> popey: two things at play - 1 hr cache on the store side (already refreshed) and i think snapd only refreshes the section list once per day
[16:12] <popey> noise][: thanks!
[16:28] <sil2100> mvo: I'm still looking into this, but interestingly it also segfaults on a xenial VM - from what I see it's segfaulting on executing the default override-stage scriptlet, which by default is handled by 'snapcraftctl stage'
[16:29] <sil2100> mvo: both for snapcraft as a snap and deb - but since I have a local reproducer I can finally dig into this properly
[16:41] <mup> PR snapd#5213 opened: snapcraft: run with DEB_BUILD_OPTIONS=nocheck <Created by mvo5> <https://github.com/snapcore/snapd/pull/5213>
[16:42] <mvo> sil2100: cool, I guess sergio will also want to know
[16:42] <mvo> another simple review to unblock the snap (finally) 5213
[16:59] <mup> Bug #1773416 opened: Interface from Thunderbird/Firefox to LibreOffice/VLC <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1773416>
[17:14] <kyrofa> Pharaoh_Atem, travis CAN do xenial, but it's pretty experimental right now
[17:17] <kyrofa> sil2100, I can't quite determine what you're talking about from the scrollback, but snapcraft segfaulting on trusty is a known issue
[17:17] <kyrofa> (for classic snaps anyway)
[17:17] <kyrofa> (normal ones should be fine)
[17:18] <kyrofa> But are you saying it's also segfaulting on xenial?
[17:32] <Chipaca> popey: snap find doesn't cache, but sections are
[17:32] <popey> Ok, good to know, thanks
[17:32] <Chipaca> popey: but only for completion
[17:33] <Chipaca> popey: if you type it, it should work
[17:33] <popey> uh
[17:33] <popey> nope
[17:33] <Chipaca> hm
[17:33] <Chipaca> hmm
[17:33] <popey> https://www.irccloud.com/pastebin/omgnsTv3/
[17:33] <Chipaca> hm³
[17:33] <Chipaca> yes, seeing same
[17:34] <Chipaca> hah
[17:34] <Chipaca> popey: I'm a lying liar
[17:34] <Chipaca> popey: of lies
[17:34] <popey> Noted
[17:34] <Chipaca> popey: also, this is arguably a bug
[17:34] <Chipaca> let's argue about it :-)
[17:34] <popey> Ok!
[17:35] <popey> It is a bug.
[17:35] <Chipaca> I agree.
[17:35] <Chipaca> dammit
[17:35] <Chipaca> how were arguments supposed to work
[17:35] <popey> I really am top of my game today
[17:35] <popey> Would you like me to file a bug somewhere (where?)?
[17:36] <Chipaca> popey: nah, i'll fush a pix right now
[17:36] <popey> \o/ <3
[17:36] <Chipaca> popey: as a workaround, sudo rm /var/cache/snapd/sections
[17:37] <popey> \o/ success
[17:38] <popey> Will everyone have to do that? (until the fix lands)?
[17:40] <noise][> Chipaca: presumably it updates regularly? daily? or is the bug that it is never updating?
[17:40] <Chipaca> noise][: it updates regularly
[17:41] <noise][> cool
[17:41] <Chipaca> noise][: the bug is just in the overzealous 'no such section' path
[17:41] <Chipaca> I get it's trying to be helpful, but it could check the store if the cache doesn't have it
[17:41] <Chipaca> that's what i'm implementing
[17:41] <Chipaca> ok?
[17:42] <Chipaca> check cache -> nope? check store
[17:42] <Chipaca> and just in the --section=<foo> path
[17:42] <Chipaca> hmm, OTOH the argument for it not being a bug is that sections are mostly static
[17:42] <Chipaca> and we control them
[17:42] <Chipaca> so we could just be patient :-D
[17:43] <Chipaca> (it refreshes once a day, fwiw)
[17:43] <popey> I want to do a social post to let everyone know about it
[17:43] <Chipaca> popey: yes
[17:43] <Chipaca> and I understand the motives for not having the section and not talking about it
[17:44] <Chipaca> you want to add a section, and talk about it straight away, and have it work for early adopters and etc
[17:44] <Chipaca> for teh buzz
[17:45] <kyrofa> Hey Chipaca, I've got a PR up to make sure snapcraft doesn't toast the prime directory if a dev has used `snap try` on it. It works, but I'm parsing mountinfo just to see if the priming area is bind-mounted. It would be handier if snapd just exposed the mountpoint for tried snaps in the REST API. Thoughts?
[17:45] <Chipaca> noise][: cprov: ok with you to hit the store if a user does 'snap find --section=xyzzy' and xyzzy is not in the cache?
[17:46] <kyrofa> Er, not mountpoint, but root
[17:46] <Chipaca> kyrofa: I agree! not sure how doable it is. Forum topic!
[17:46] <kyrofa> Alright, I'll make one
[17:46] <Chipaca> kyrofa: friday beer o'clock; cross-boundary problems are too deep
[17:47] <Chipaca> kyrofa: (and that one might involve asking systemd stuff)
[17:47] <Chipaca> or at least snapstate
[17:47] <Chipaca> anyway, not fit for my head now
[17:47]  * Chipaca wraps up the (un)cache one hoping to hear back from cprov and noise][ soonish
[17:49] <cprov> Chipaca: I don't have any objections, the store endpoint is cached for 1h. In theory, hitting the store for unknown section would give us some idea of which sections users are looking for.
[17:50] <Chipaca> cprov: profit :-)
[17:50] <cprov> Chipaca: exactly, thanks for working this out.
[17:51] <Chipaca> cprov: hold on
[17:51] <Chipaca> cprov: I'd not be hitting the store asking for one section
[17:51] <Chipaca> cprov: I'd be hitting it asking for all sections
[17:51] <Chipaca> there isn't an api for "is this a section"
[17:52] <popey> Chipaca: ok, will put the social post on hold for now until I get the nod.
[17:52] <Chipaca> popey: when was the section created?
[17:52] <cprov> Chipaca: you are right, there is no way to hint the store on this
[17:52] <popey> a few hours ago
[17:53] <Chipaca> cprov: 24 hours from that, everybody will have it
[17:53] <Chipaca> um
[17:53] <Chipaca> popey: ^
[17:53] <Chipaca> cprov: a lot of people will have it before then though
[17:53] <Chipaca> augh
[17:53] <popey> ok so a social post on sunday to be safe
[17:53] <Chipaca> popey: ^
[17:53] <popey> sound reasonable?
[17:53] <popey> (we want to try some weekend social posts)
[17:54] <Chipaca> popey: as this chance is going to master, and that's ~2 months from everybody getting it, next time something like this needs doing create the empty section first, and populate it for the news
[17:54] <Chipaca> capisce?
[17:55] <popey> Gotcha
[17:55] <popey> So one thing I'm not clear on. Right now, today as we stand, if I tell people on Sunday to "snap find --section=server" will that work?
[17:57] <Chipaca> popey: yes
[17:57] <popey> Ok, great! Thanks.
[17:58] <Chipaca> popey: snapd refreshes that on boot, and then every 24 hours
[18:04] <mup> PR snapd#5214 opened: cmd/snap: check with snapd for unknown sections <Created by chipaca> <https://github.com/snapcore/snapd/pull/5214>
[18:04] <Chipaca> popey: ^
[18:04] <popey> *hugs*
[18:05] <cprov> thanks, Chipaca
[18:05] <popey> cprov: i can't view sections in the web store can I?
[18:05] <Chipaca> now i'm off to make fugazzetta
[18:05] <Chipaca> o/
[18:05] <popey> o/
[18:06] <noise][> popey - not yet, is on the webteam's short-term todo though
[18:06] <popey> sweet
[18:06] <popey> It's coming togther :D
[18:16] <cprov> popey: no, but you can use `curl -s https://api.snapcraft.io/api/v1/snaps/sections | jq '._embedded["clickindex:sections"]'`
[18:16] <sil2100> kyrofa: yeah, segfaulting on xenial as well - I saw the issue you're talking about but I guess this might be different, as it's not during building a classic snap
[18:16] <popey> seamless :)
[18:16] <sil2100> kyrofa: anyway, I'll be digging into that more later
[18:16]  * sil2100 EODs for now
[18:16] <sil2100> o/
[19:05] <jdstrand> roadmr: hi! one more small request. can you pull r1079? it is also not urgent. it can come after the first or after the first two, whatever you want
[19:06] <niemeyer> zyga: You're hopefully not here anymore, but for monday, replied to that point
[19:07] <zyga> Thanks
[19:07] <zyga> I will check in some time
[19:07] <zyga> Building stuff with bolts and nuts now
[19:13] <pedronis> jdstrand: thanks for adding the common-id check
[19:14] <roadmr> ohi jdstrand
[19:15] <roadmr> jdstrand sure, r1079 will go to the queue, I'd like to roll out on Monday
[19:21]  * mvo would love a review for 5213 pretty simple and hopefully unblocks the snapd snap building
[20:05] <pedronis> mvo: have some comments there, I don't understand the non-main changes
[22:33] <erio> hello, has someone here snapped something with SDL2 ?
[22:40] <erio> is anyone alive ?