[01:13] <mup> PR snapcraft#2442 closed: cli: enable cleaning of parts <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2442>
[05:57] <mborzecki> mornig
[06:51] <mup> PR snapd#6416 closed: snap: really run the RunSuite <Simple 😃> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6416>
=== SlidingHorn is now known as BrassManTv
=== BrassManTv is now known as SlidingHorn
[07:17] <zyga> good morning
[07:17] <mvo> hey zyga
[07:17] <zyga> hey
[07:17] <zyga> debian drama dramas on
[07:18] <mvo> zyga: oh?
[07:18] <jamesh> zyga: hi.  When you have time, could you have a look at https://github.com/snapcore/snapd/pull/6313?  It adds some spread tests for xdg-desktop-portal/xdg-document-portal integration (only running on a subset of backends where I know it works currently)
[07:18] <mup> PR #6313: tests: add a tests for xdg-desktop-portal integration <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6313>
[07:18] <zyga> mvo: it failed to build in debian
[07:18] <zyga> mvo: unpackaged file
[07:19] <mvo> zyga: do you have a link?
[07:19] <zyga> jamesh: hello
[07:19] <jamesh> I know you were working on user mounts improvements, so this should ensure the behaviour I care about continues to work :-)
[07:19] <mvo> zyga: yeah, curious, we test build it
[07:19] <zyga> jamesh: I will look for sure, there are two high priority items still on my plate but I promise to review this by EOD
[07:19] <mborzecki> mvo: zyga: hey
[07:19] <zyga> mvo: I just ... no idea
[07:20] <jamesh> zyga: thanks.  I'd also like to talk about the user daemons/dbus activation PRs at some point
[07:20] <jamesh> (mainly about how to proceed forward with them)
[07:20] <zyga> jamesh: I think we should have a call with samuele to sync on where we are and what the challenges are
[07:21] <zyga> jamesh: we have some things in the roadmap that incresingly require session level interaction
[07:21] <mvo> hey mborzecki
[07:22] <jamesh> zyga: having our PRs closed without consultation irks me a bit.  Among other things, it cuts me off from CI.
[07:22] <zyga> jamesh: closed?
[07:23] <zyga> jamesh: that's understandable, I don't think we should close them out of the blue
[07:23] <jamesh> zyga: this one: https://github.com/snapcore/snapd/pull/5822
[07:23] <mup> PR #5822: wrappers: allow user mode systemd daemons <Created by jhenstridge> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/5822>
[07:23] <zyga> I see
[07:23] <zyga> I think you need to discuss with samuele, he has some catchup to do after last week and ubuflu but I'm sure we can have a reasonable conversation
[07:28] <jamesh> yeah.  I'll see if I can catch up with him later today.
[07:29] <zyga> good luck!
[07:44] <pedronis> jamesh: sorry, but we do close PRs from time to time if they cannot land, it's unclear when, and discussion is better not in them. I'm wary of having things that are "services" but don't fit the out whole services picture, for example what should "snap services" show about these? does it even work on the PR?
[07:44] <pedronis> jamesh: these things need a proper design on the forum
[07:54] <zyga> jamesh: do you have access to spread?
[07:55] <zyga> perhaps the real issue is that you just need a key to run spread tests and iterate at will locally
[07:55] <zyga> proposing only those chunks that are ready to be discussed / reviewed and are relatively close to landing
[07:59] <pedronis> zyga: to be clear I don't think until I  see a consistent whole picture, I wouldn't take chunks either
[08:00] <zyga> right, but I believe, based on what jamesh said above, that having open PRs is an important part of the workflow because that's his (apparently) only way to access CI
[08:12] <zyga> does https://groups.google.com/forum/m/#!topic/golang-announce/mVeX35iXuSw affect us?
[08:15] <mborzecki> zyga: don't think so
[08:54] <mup> PR snapd#6421 opened: spread: enable upgrade suite on fedora <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6421>
[08:54] <mborzecki> trivial PR ^^^
[08:57] <mborzecki> can't reproduce the mount problem using the usual install/remove loop
=== phoenix_firebrd is now known as murthy
[09:09] <mvo> mborzecki: thanks for looking into that again
[09:10] <mvo> mborzecki: this makes me wonder if something external is doing the systemctl reload during the tests
[09:10] <mborzecki> mvo: 50 loops of install remove with the script we use in the protocol error test
[09:10] <mborzecki> mvo: there is, on core 18, there's a job that's constatnlty failing and getting restarted
[09:10] <mborzecki> mvo: serial-console-conf@ttyS0.service keeps being restarted
[09:11] <mvo> mborzecki: oh, what job is that?
[09:11] <mvo> mborzecki: interessting
[09:11] <mvo> mborzecki: are all protcol errors we have observed recently on core18?
[09:12] <mborzecki> mvo: afaik yes
[09:12] <mvo> mborzecki: thats a very interssting clue then
[09:13] <mborzecki> mvo: though there's this note in the forum https://forum.snapcraft.io/t/unexplained-mount-failure-protocol-error-what-we-know-so-far/5682/27
[09:14] <mvo> mborzecki: interessting
[09:14] <mborzecki> mvo: otoh, the travis jobs i restarted were core18
[09:14] <mvo> mborzecki: well, if there is activity (e.g. apt installing stuff or unattended-upgrades) in the background
[09:14] <mvo> mborzecki: that may happen
[09:14] <mvo> mborzecki: and there is nothing we can do :(
[09:19] <mborzecki> Chipaca: morning sir
[09:19] <mborzecki> mvo: hm shouldn't we touch /var/lib/console-conf/complete when preparing core18 image for tests?
[09:20] <mvo> mborzecki: yes, is that missing?
[09:20] <mborzecki> mvo: it is
[09:20] <mvo> mborzecki: in practise it shouldn't make a difference but if it fixes the crash…
[09:21] <mborzecki> mvo: the unit has ConditionPathExists=!/var/lib/console-conf/complete so it should make it go away
[09:23] <Chipaca> mborzecki: mo'in
[09:32] <mvo> mborzecki: cool, lets add this in any case to our testsuite
[09:34] <jamesh> pedronis: sorry.  Was out for a ride before it gets dark.  My point is that when you close a PR there is no way for the author to reopen it, and Travis will no longer run tests if they update it
[09:34] <mborzecki> Chipaca: was your concern here https://github.com/snapcore/snapd/pull/6415#discussion_r250187805 that we accept BS channel input and let it reach the store eventually?
[09:35] <mup> PR #6415: snapstate, snap: allow update/switch requests with risk only channel to DTRT <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6415>
[09:35] <Chipaca> mborzecki: no, I want whatever works with --channel=stable to also work with --channel=stable/hotfix-1234
[09:36] <Chipaca> mborzecki: having --stable say "yeah you meant the pinned track" and --channel=stable/hotfix-1234 say "you can't change tracks what are you evil", is wrong imho
[09:36] <Chipaca> mborzecki: i'm going to get more coffee and then re-review your pr though
[09:37] <mborzecki> Chipaca: i see, i'm not sure then whether <risk>/<branch> would count as risk only request
[09:38] <mborzecki> Chipaca: i does sound reasonable to me, but maybe it's really a question for pedronis
[09:39] <pedronis> mborzecki: I agree with Chipaca here
[09:39] <pedronis> it's the consistent thing
[09:39] <mborzecki> pedronis: ok, sounds good to me
[09:48] <Chipaca> mborzecki: i'll hold off on that review then
[09:48] <mborzecki> ack
[10:06] <ogra> ondra, https://docs.snapcraft.io/architectures/4972
[10:15] <mup> PR snapd#6422 opened: tests/prepare: prevent console-conf from running <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6422>
[10:15] <mborzecki> mvo: ^^
[10:17] <ogra> mborzecki, wheee !!!! i love you !!!
[10:17] <ogra> (only took a year :P )
[10:17] <mborzecki> ogra: hahah so this was discussed before already?
[10:18] <ogra> mborzecki, https://forum.snapcraft.io/t/disabling-console-conf-from-gadget-or-core-config-option/4358
[10:20] <ogra> oh, your PR is only for the tests ... i thought it was also for runtime
[10:20] <mborzecki> ogra: don't want to disappoint you but the pr is only to workaround a problem we see in the tests
[10:20] <ogra> *snap*
[10:20] <ogra> :)
[10:20] <mborzecki> ogra: maybe try necrobumping the topic if it's a high priroity for you guys
[10:21] <pedronis> mborzecki: it's on the list of things to desing on the way to core20
[10:21] <pedronis> (how to opt out of console-conf)
[10:21] <mborzecki> ah, even better
[10:21] <ogra> it isnt super high, but when talking to security aware customers we get questions ... since yu can just attach a serial cable today and run through console conf to gain access
[10:22] <ogra> so hacks are required to disable it
=== cpaelzer__ is now known as cpaelzer
[10:31] <mborzecki> anyone with manjaro vm?
[10:34] <mup> PR snapcraft#2449 opened: Release changelog for 3.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2449>
[11:17] <Chipaca> mborzecki: locate -i manjaro finds only pull requests from you (and the kilimanjaro wonder from civ v)
[12:15] <mborzecki> hm a snap gets an interface auto connected, then it gets manually disconnected, now it's correctly shown as undersired, later i reconnect the interface, and the state information indicates that the connection is manual
[12:17] <popey> (also, when you refresh, your disconnected interface gets re-connected)
[12:19] <mborzecki> popey: that should have been fixed already
=== ricab is now known as ricab|lunch
[12:31] <zyga> break :)
[12:31] <zyga> but some good news :)
[12:44] <pedronis> mborzecki: did you see my question btw, https://forum.snapcraft.io/t/rfc-snap-connections-command/4296/15
[12:47] <mborzecki> pedronis: yes, but it's a snap command thing, so it'll end up in 6079
[12:47] <pedronis> mborzecki: well, it seems there was an ongoing discussion in the forum which seems good to try to conver in the forum
[12:47] <pedronis> *converge
[12:53] <mborzecki> 6421 spread run failed in tests/main/searching, looks like 'video' section is gone from the store?
[12:54] <mborzecki> we were unfortunate to do  `snap find --section=video vlc | MATCH vlc` in the test
[12:55] <mborzecki> pedronis: Chipaca: do you know anything about that?
[12:56] <pedronis> mborzecki: I think some sections have been renamed
[12:56] <mborzecki> looks like it's photo-and-video now
[12:57] <pedronis> yes
[13:00] <cachio> mborzecki, I'll update the test
[13:00] <mup> PR snapd#6423 opened: tests/main/searching: video section got renamed to photo-and-video <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6423>
[13:00] <mborzecki> cachio: opened a PR just now
[13:00] <mborzecki> ^^
[13:00] <cachio> mborzecki, great
[13:00] <cachio> I'll take a look in that case
[13:01] <mborzecki> off to pick up the kids
[13:05] <Chipaca> hmm
[13:05] <Chipaca> we could automate that kind of thing sooon
[13:10] <ondra> sergiusens is there any  variable I can use in custom pluging which will give me target architecture?
[13:10] <pedronis> Chipaca: some comment on #6389
[13:11] <mup> PR #6389: cmd/snap: small refactor of cmd_info's channel handling <Created by chipaca> <https://github.com/snapcore/snapd/pull/6389>
[13:11] <ondra> sergiusens when I will use architectures: build-on: amd64 run-on:arm64
[13:15] <Chipaca> pedronis: noted
[13:25] <ondra> sergiusens shall I expect self.project.kernel_arch to give me target arch of the device?
[13:36] <Saviq> hey, is it possible to use snapd with squashfuse? I'm in an unprivileged container so the loop device dance is prevented
[13:36] <Saviq> I may ask for some additional caps to the container, but would rather not if it can work without that
[13:40] <mup> PR snapd#6424 opened: tests: remove -o pipefail <Created by mvo5> <https://github.com/snapcore/snapd/pull/6424>
[13:41] <Chipaca> Saviq: yes, snapd uses squashfuse if it detects the need of it
[13:42] <Saviq> ok my container was missing /dev/fuse
[13:43] <Chipaca> Saviq: https://github.com/snapcore/snapd/blob/master/osutil/squashfs/fstype.go#L32
[13:46] <Saviq> Chipaca: yup, mount worked now, but it's a Debian kernel, Ubuntu container... how does snapd decide whether to enable apparmor confinement or not?
[13:46] <Chipaca> Saviq: black magic
[13:47] <Chipaca> or, maybe ask zyga :-)
[13:47] <Saviq> same thing, isn't it?
[13:47] <Chipaca> Saviq: snapd will print what it thinks it's got when it boots
[13:47] <Chipaca> Saviq: some of it is auto-detection, some of it is manual
[13:47] <Chipaca> AFAIR
[13:48] <Chipaca> Saviq: e.g., Jan 14 17:49:13 fleet snapd[1789]: AppArmor status: apparmor is enabled and all features are available
[13:48] <Saviq> AppArmor status: apparmor is enabled but some features are missing: dbus, network
[13:48] <Chipaca> Saviq: (from 'journalctl -u snapd')
[13:48] <Chipaca> that sounds like debian's kernel
[13:49] <Saviq> but then https://pastebin.ubuntu.com/p/GXt5yrBGgn/ :/
[13:54] <Chipaca> Saviq: zyga and/or jdstrand might know more about that
=== ricab|lunch is now known as ricab
[13:55] <mborzecki> cachio: i think you need to purge /var/cache/snapd/sections for snapd to grab the most recent list of sections in the store
[13:56] <Saviq> ack tx
[13:57] <cachio> mborzecki, ah
[13:57] <cachio> ok
[14:01] <sergiusens> ondra: look at the "project" object the plugin gets passed, it has deb_arch and arch_triplet properties
[14:07] <ondra> sergiusens self.project.arch_triplet: x86_64-linux-gnu self.project.deb_arch: amd64
[14:07] <ondra> sergiusens that seems wrong, since snap has only arm64 architecture as supported
[14:08] <sergiusens> I don't know how to connect those two statements
[14:09] <ondra> sergiusens I have this in snapcraft.yaml https://paste.ubuntu.com/p/kZwXp2ZKyG/
[14:10] <ondra> sergiusens when I build on amd64 to arm64
[14:10] <ondra> sergiusens I get https://paste.ubuntu.com/p/vNdtqsyJKd/
[14:20] <ondra> sergiusens basically even with that architecture statement, I still have to use --target-arch to get right result. Is there any variable which would reliably give me target architecture
[14:24] <ondra> sergiusens any thoughts?
[14:43] <mup> PR snapd#6383 closed: tests: provide a fake random device to the core images <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6383>
[14:57] <ondra> sergiusens shall I assume whole architecture: build-on run-on is half baked and not to be used?
[15:33] <cachio> mvo, hey, I tried the pipefail cahnge but debian sid still fails
[15:33] <cachio> mvo, is it needed something else
[15:33] <cachio> ?
[15:36] <sergiusens> ondra: the first part is for automated build systems, the latter is to tell consumers where it runs
[15:36] <sergiusens> but it is up to the developer to make the right thing happen wrt where it runs
[15:37] <ondra> sergiusens sure, but there should be way to tell what is target architecture
[15:37] <sergiusens> that is still not there, that is the from-to language which is not there
[15:38] <ondra> sergiusens I would expect project.target_arch to hold right value
[15:38] <ondra> sergiusens if I do not speciffy --target-arch it's empty
[15:40] <sergiusens> that might be a bug, but for now you can check if it is empty and use deb_arch instead
[15:40] <ondra> sergiusens deb_arch is set to host
[15:41] <ondra> sergiusens so without --target-arch it does not work
[15:42] <sergiusens> ondra: ok, please write up a detailed forum post, you are feeding me drops of information on what you want to do and it is micro interrupting a bit too much
[15:42] <ondra> sergiusens it gives wrong value
[15:42] <sergiusens> not sure if there is a complaint, an action or what...
[15:46] <ondra> sergiusens so there is no value which would give me snap target architecture and I would be able to use it in plugin?
[15:47] <ondra> sergiusens because this is really only thing I need
[15:47] <sergiusens> ondra: forum
[15:47] <ondra> sergiusens geee, this is really not helpful
[15:47] <ondra> sergiusens elt
[15:47] <sergiusens> ondra: bug then
[15:48] <ondra> sergiusens forum is slow for conversation, but let's see how quick you gonna reply there
[15:48] <sergiusens> ondra: I have a hard time understanding your objective every time I am pinged by you on IRC
[15:48] <sergiusens> well, I am doing other things now, so I am not really thinking about your problem
[15:48] <mborzecki> #6423 anyone? this will unblock the PRs
[15:48]  * cachio lunch
[15:49] <mup> PR #6423: tests/main/searching: video section got renamed to photo-and-video <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6423>
[15:49] <ondra> sergiusens simple question: is there value which would give me snap target architecture and I would be able to use it in custom plugin?
[15:49] <sergiusens> ondra: simple answer, I need to look at the code, from my point of view, cross compilation is experimental
[15:50] <ondra> sergiusens ok
[15:52] <narutowaifu> hi, I've installed "lxd" on my debian stable using snapd.    `snap --version` shows 2.36.3  and  `lxd --version` shows 3.6. The latest version however should be 3.9. If I run `snap refresh` it says  "All snaps up to date".  Why is it not updating to 3.9? Any help? Thanks
[15:54] <roadmr> narutowaifu: what does "snap info lxd" say? does it show 3.9 as available in the channel you're tracking?
[16:01] <mvo> cachio: oh, meh
[16:01] <mvo> cachio: let me check
[16:02] <Chipaca> narutowaifu: also, what does 'which lxd' say
[16:38] <mup> PR snapd#6423 closed: tests/main/searching: video section got renamed to photo-and-video <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6423>
[16:43] <narutowaifu> roadmr: snap info lxd => installed: 3.6, stable: 3.9       Chipaca: which lxd => /snap/bin/lxd
[16:44] <Chipaca> narutowaifu: snap info lxd | grep tracking
[16:46] <narutowaifu> Chipaca: tracking: stable
[16:46] <Chipaca> narutowaifu: ok. can you enable debug in snapd and do a refresh?
[16:47] <narutowaifu> how do i enable debug
[16:47] <Chipaca> narutowaifu: https://forum.snapcraft.io/t/extremely-slow-snap-downloads/4668/2?u=chipaca
[16:50] <mup> PR snapd#6425 opened: interfaces: add yubikey interface and allow reading /run/udev/data/+power_supply:* <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6425>
[16:52] <jdstrand> oSoMoN: there you go ^
[16:58] <narutowaifu> Chipaca: I can see the requests to api.snapcraft.io. What should I look for?
[17:01] <Chipaca> narutowaifu: after the request there should be a json thing that starts with DEBUG: < (it can span multiple journal lines)
[17:01] <Chipaca> narutowaifu: i'm interested in that
[17:02] <Chipaca> narutowaifu: that is the response from the POST request; you might have other requests that are updating assertions that i'm less concerned with
[17:03] <Chipaca> narutowaifu: do not pastebin the ones that start DEBUG: >, as those can contain macaroons
[17:03] <Chipaca> but, yeah, if you could  pastebin the store response, it might shed some light on what's going on
[17:04] <Chipaca> (the request could also, but i'd have to help you clean the macaroons out first)
[17:06] <narutowaifu> what are macaroons?
[17:06] <Chipaca> narutowaifu: like cookies, but more delicious
[17:07] <Chipaca> narutowaifu: in this case, cryptographically fancy cookies
[17:19] <oSoMoN> jdstrand, thanks! looking
[17:26] <cachio> mvo, I just pushed the change
[17:27] <cachio> mvo, I am adding more information to the documentation needed to run beta validation
[18:01] <zyga> https://tracker.debian.org/pkg/snapd
[18:01] <zyga> only too young exception1
[18:01] <zyga> great :)
[18:01] <popey> \o/ <3
[18:04] <mvo> cachio: thank you
[18:04] <mvo> zyga: yay
[18:04] <zyga> indeed, this is a good thing :0
[18:04] <zyga> :)
[18:05] <mvo> cachio: thanks for the removal of pipefail, I will watch how it fails
[18:05] <mvo> cachio: if it fails, maybe there is more, we will see
[18:06] <cachio> mvo, also a mount error on amazon-linux https://paste.ubuntu.com/p/qZkkh97gpW/
[18:07] <mvo> cachio: I had to also add some more bits to debian https://github.com/snapcore/snapd/pull/6413/commits  (the commits from today are relevant)
[18:07] <mup> PR #6413: packaging: import debian salsa packaging work and use in spead <Created by mvo5> <https://github.com/snapcore/snapd/pull/6413>
[18:07] <mvo> cachio: meh, thanks! the mount error is really unfortunate that its still there :( oh well
[18:08] <cachio> mvo, yes, it mutates like a virus :)
[18:10] <mvo> cachio: indeed, not pipefail :( I see the error with the missing match even without that now too
[18:13] <sergiusens> cachio: is there a way to have spread add a summary of what ran passed or failed and what was skipped at the end of a run? I am interested in knowing I did not accidentally filter anything out.
[18:15] <cachio> sergiusens, you want to see the skipped ones, right?
[18:16] <cachio> sergiusens, if you want that, with the current spread implementation is not possible
[18:18] <sergiusens> cachio: I bet you want that too to make sure you aren't messing up your filters by accident 🙂
[18:18] <sergiusens> and yes, that is exactly what I want to see
[18:19] <Chipaca> narutowaifu: FWIW, macaroons are https://ai.google/research/pubs/pub41892
[18:20] <mvo> cachio: I play with some ideas right now about journalctl, all a bit annoying
[18:20] <cachio> sergiusens, well, so far you need to create an script to check results
[18:21] <sergiusens> cachio: you have that? I might pick your brain during our flight to Malta. I do not want to duplicate work
[18:21] <cachio> sergiusens, hehe
[18:21] <cachio> I don't have it
[18:22] <cachio> I could create something but after my vacations
[18:22] <cachio> sergiusens, first should be nice to have the tests report branch merged
[18:22] <cachio> so it is possible to export the test restuls in json or xml format
[18:23] <cachio> then it is much easier to parse that
[18:24] <cwayne> We have some scripting around converting it to junit
[18:24] <cwayne> For our Jenkins jobs running spread
[18:25] <cachio> cwayne, I have a PR in spread for that too :(
[18:26] <cachio> I think we could make a session on malta to see which features are desired in spread
[18:27] <cwayne> +1
[18:29] <mup> PR snapcraft#2450 opened: pluginhandler: handle removal of inconsistent files <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2450>
=== ricab is now known as ricab|brb
[18:45] <mup> PR snapd#6426 opened: cmd/snap-confine: refactor and cleanup of seccomp loading <Created by zyga> <https://github.com/snapcore/snapd/pull/6426>
[18:47] <Chipaca> zyga: you around?
[18:48] <zyga> ish
[18:48] <zyga> scrambled eggs brb
[18:49] <cachio> mvo, is it ok to promote the core18 to candidate?
[18:49] <zyga> I'll make food for Iza and brb
=== ricab|brb is now known as ricab
[18:53] <mvo> cachio: did you check with foundations, I think they should do these promotions nowdays (core18)
[18:54] <cachio> mvo, I'll ping them to do it
[18:54] <cwayne> They have our +1 already
[18:54] <cachio> from our side and CE everything ok
[18:54] <cachio> ready
[18:54] <cwayne> cachio: sil2100 is your guy for that
[18:55] <cachio> cwayne, yes
[18:56] <mvo> cachio: great
[19:06] <Chipaca> zyga: mvo: looks like auto-refresh is busted for devmode distros
[19:06] <Chipaca> super easy to reproduce the bug
[19:06] <zyga> "fun"
[19:06] <zyga> totally busted/
[19:06] <Chipaca> 1. install debian
[19:07] <Chipaca> 2. install a snap that has different revisions in different channels
[19:07] <Chipaca> 3. snap switch the snap to a different channel (one that has a different revno)
[19:07] <Chipaca> 4. snap refresh
[19:07] <Chipaca> repeat 4 as many times as you want, it ain't gonna happen
[19:07] <Chipaca> explicitly saying 'snap refresh thesnap' works
[19:08] <Chipaca> all hail narutowaifu for finding it and pointing us to it, fwiw :-)
[19:09] <Chipaca> 2. is actually "apt install snapd && snap install thesnap"
[19:10] <zyga> Chipaca: if you have patches we should strive to land them for .1
[19:10] <zyga> and we should get debian out of devmode
[19:10] <zyga> to behave like opensuse
[19:10] <Chipaca> interestingly if you do 'apt install snapd && snap install core && snap install thesnap', it doesn't happen
[19:10] <zyga> broken reexec?
[19:10] <Chipaca> so it's a bug in the old snapd that debian ships, that's fixed in stable
[19:10] <Chipaca> zyga: reexec only works after it has something to reexec to
[19:11] <zyga> right
[19:11] <Chipaca> the old one is setting up the tasks wrong it seems
[19:11] <Chipaca> new one fixes
[19:11] <Chipaca> but doesn't know to fix old broken ones
[19:11] <Chipaca> so
[19:11] <Chipaca> er
[19:11] <Chipaca> stgraber: ping
[19:12] <zyga> offtopic, what's up with master?
[19:12] <Chipaca> stgraber: with your instructions to install lxd on debian, people won't ever get updates
[19:12] <zyga> is master red/
[19:12] <zyga> red red red
[19:12] <zyga> or just in my broken PRs?
[19:12] <zyga> Chipaca: it's good that 2.37-3 is heading to debian
[19:13] <Chipaca> stgraber: bug is on our side, but if you change your instructions for them to install 'core' explicitly before installing lxd, you work around it
[19:13] <Chipaca> stgraber: (yes we're fixing it but the problem is in the packaged snapd, so it's slow to release the fix)
[19:13] <Chipaca> zyga: wrt red, might it be because of the changed sections?
[19:13] <zyga> dunno, got a log that barfed on me
[19:13] <zyga> much too much stuff at once today
[19:14] <Chipaca> hmm
[19:14] <narutowaifu> ah stgraber is here? Thanks for adding the btrfs docs
[19:15] <mvo> zyga: you may need to merge master
[19:15] <zyga> mvo: aha
[19:15] <mvo> zyga: there was this category change today in the store that broke tests
[19:15] <zyga> thank you
[19:28] <sergiusens> cachio: cwayne please add me to that session
[20:04] <mvo> cachio: just fyi, with https://github.com/snapcore/snapd/pull/6413/commits/5a7d450f90e4d325b9463e1254819fa4fe644e8a debian-sid passed locally now, its still strange that export/grep is so unreliable in systemd 240
[20:04] <mup> PR #6413: packaging: import debian salsa packaging work and use in spead <Created by mvo5> <https://github.com/snapcore/snapd/pull/6413>
[20:05] <cachio> mvo, nice
[20:05] <cachio> I'll run it here too
[20:05] <cachio> thanks for that
[20:06] <mvo> cachio: I hope to find some time (tomorrow?) to look into this, it smeels like an upstream bug and shouldn't be too hard to reproduce (famous last words :)
[20:08] <cachio> mvo, yes, agree with that
[20:08] <cachio> mvo, I tried updating the journal and systemd config but didn't work
[20:09] <cachio> mvo, by know increasing the polling time works
[20:09] <cachio> but we need to figure out the problem
[20:09] <cachio> that should be temporal
[22:21] <mup> PR snapd#6427 opened: interfaces: add block devices interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6427>
=== phoenix_firebrd is now known as murthy
[23:20] <mup> PR snapd#6428 opened: interfaces: add display-control interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6428>