[05:02] morning [05:16] hmm found an interesting error: `error: store.RevisionNotAvailable with 2 snaps` [05:21] well, nvidia seems to work just fine [05:37] apparmor denials are not logged in dmesg, so it's easy to miss those [05:37] type=AVC msg=audit(1529645643.115:406): apparmor="DENIED" operation="open" profile="snap.ohmygiraffe.ohmygiraffe" name="/etc/pulse/client.conf.d/" pid=10207 comm="love" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [05:50] hey [05:51] mborzecki-suse: hey [05:51] zyga: hey [05:52] I was up till 2AM iterating on the packaging [05:52] zyga: so far so good, no issues with package from your repo [05:52] found a few annoying bugs and fixed them [05:52] and learned a few things that we need to change in our build system [05:52] (not having a central build system sucks) [05:56] but man, textual yast installer is awful, didn't manage to install it the way i'd like, gave up and went with the defaults at some point, ended up with gpt partitioned disk, no efi, no luks, no lvm, btrfs on rootfs, xfs on home and non-blacklisted nouveau (what made xorg unusable) [05:57] hey [05:57] so how do I go about backing up a snap's data [05:57] Like nextcloud. [05:58] snaphelp: fantastic question [05:58] you can do it manually today [05:58] but we are also working on a feature that makes it easy [05:58] zyga: Snaps aren't auto updating are they? [05:58] don't know why people even bother building such installers, what i really need is creating partitions myself, mounting them in the layout i want, bootstrapping the system, update fstab, crypttab, rebuild initramfs, install some bs pacakges, install bootloader (the way i want) [05:58] all snap data is held in /var/snap/$SNAP_NAME and $HOME/snap/$SNAP_NAME [05:59] mborzecki-suse: hmm? [05:59] snaphelp: the upcoming feature will allow you to snapshot this state easily from the snap CLI [05:59] zyga: is the snap directory in my home directory just a symlink to /var/snap? [05:59] snaphelp: no [05:59] snaphelp: those are separate data sets, one is per user and the other is global for the system [06:00] hmm [06:00] zyga: just being grumpy about distro installers :| [06:02] hey mvo [06:02] mvo: morning [06:02] hey zyga and mborzecki [06:04] zyga: so the global data is in /var [06:04] and there's no auto updating correct? [06:05] snaphelp: per-snap global data is in /var/snap/$SNAP_NAME [06:05] snaphelp: I don't understand the question about auto-updating [06:05] Do snaps automagically update themselves [06:05] or is it snap update [06:06] snaphelp: it is snap refresh but you don't have to do it explicitly, snapd automatically refreshes everything periodically [06:07] Can I disable automatic refreshes? [06:07] you can set a schedule but you cannot turn it off [06:10] mvo: I'm a bit tired, I spent half of the night on this packaging [06:11] mvo: I will be sending patches when I'm consistently awake [06:11] zyga: any plans to allow disabling? [06:11] snaphelp: no, there are no such plans [06:11] hm [06:13] zyga: I'm torture testing a snap [06:14] heh wow it's handling being beat with 40gb of data [06:18] mvo: we need to have a makefile in data/ [06:18] and stop installing files by hand in packaging [06:18] it's easy to miss files [06:18] and it's silly to do this [06:21] need to go to kids school for a while, bbl [06:22] PR snapd#5352 closed: many: expose full publisher info over the snapd API [06:23] zyga: ok [06:53] PR snapd#5375 opened: packaging: put snapctl into /usr/lib/snapd and symlink in usr/bin [06:53] oh, interesting [06:57] PR core18#34 opened: hooks: make /usr/bin/snapctl available in the base [06:57] zyga: one more commit to 5375 (apparmor default update) [07:07] PR core18#34 closed: hooks: make /usr/bin/snapctl available in the base === pstolowski|afk is now known as pstolowski [07:13] morning [07:17] * zyga is super sleepy [07:18] sorry folks, this day will be hit-and-miss [07:18] hey pstolowski, good morning [07:28] PR snapd#5376 opened: tests: skip security-udev-input-subsystem without /dev/input/by-path [07:30] zyga: just get some rest :) it will be better i'm sure [07:35] PR snapd#5373 closed: release: 2.33.1 [07:36] mvo: thank you [07:36] I'm chopping final bits of packaging updates [07:36] thank you for 2.33.1 [07:43] re https://forum.snapcraft.io/t/gnome-calculator-failed-to-create-symbolic-link/5742/10 , the after-install seeding doesn't look good in cosmic, gets stuck on autoconnect and in the meantime an update of snapd arrives through deb and gets stuck on deb configure step [07:43] PR snapd#5377 opened: packaging/opensuse: remaining packaging updates for 2.33.1 [07:44] mborzecki: ^ [07:44] mborzecki: which distributions did you test? [07:44] popey: do you have a suse box for some testing? [07:45] popey: I'd like to update snapd in openSUSE [07:45] mborzecki: I also have one issue I don't know how to solve [07:45] mborzecki: the new snapd.apparmor.service needs to be enabled manually [07:45] mborzecki: I don't know what to do about it [08:01] mborzecki: could you please have a look at https://build.opensuse.org/request/show/618441 [08:02] Pharaoh_Atem: ^ if you have the time [08:02] Pharaoh_Atem: this syncs the package in system:snappy with the package in snapd master [08:03] remaning diff is: patches, small change in path used to get packaging overrides (we don't have a symlink for packaging/opensuse in 2.33 _yet_). [08:03] in 2.34 the delta should be empty === chihchun_afk is now known as chihchun [08:33] * zyga -> walk === chihchun is now known as chihchun_afk [08:45] mvo, pedronis it appears that seeding+prerequisites explode in cosmic on autoconnect, also with 2.33.1 (i've built the deb manually) [08:46] pstolowski: explode in which sense? [08:46] we have no support atm if the seeding is not sorted right [08:46] pedronis: autoconnect is in state Doing, never completes [08:47] pstolowski: is this a spread test or something else? [08:47] pedronis: there are 6 gnome packages + core in seed/ [08:47] pedronis: no, a fresh install of cosmic daily [08:47] if they are sorted wrong [08:48] no good [08:48] given that seeding is serial [08:49] we should teach seeding to do some sorting [08:49] but that hasn't really changed much === chihchun_afk is now known as chihchun [08:50] pstolowski: I'm not even sure what autoconnect code is exactly in 2.33.1 [08:50] I suppose is not like master [08:51] pedronis: correction, i actually build and tested with current master [08:51] pstolowski: can you print seed.yaml there [08:51] pstolowski: we might have made something worse [08:51] but it was probably working by chance [08:53] or I'm missing something, which could be [08:53] pedronis: http://pastebin.ubuntu.com/p/pPZkdHhp9B/ [08:54] themes is wrong [08:54] there was even a bug [08:54] we told them to move [08:54] not sure why is still like that [08:54] pedronis: i don't think we made it worse, i started with fresh cosmic image (it has 2.28.x), the problem was already visible [08:54] pedronis: oh ah [08:55] zyga: i have a suse vm, but not sure how much time i will have today to help test [08:55] morning all [08:55] * Chipaca having a weird day (but a good'un) [08:58] pstolowski: is still open, though there was a fix: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1772844 [08:58] bit confused [08:58] Bug #1772844: snapd didn't initialize all the seeded snaps

[09:01] pedronis: right, clearly not landed [09:02] pstolowski: we can teach either seeding or autoconnect to do something in that case, I want to have a clearer big picture related to conflicts before going there [09:02] though [09:03] the manual fix seems easy enough, not sure why is not landed [09:03] or is just different teams building different images [09:07] mvo: do you understand what is happening with that bug ? #1772844 [09:07] Bug #1772844: snapd didn't initialize all the seeded snaps

[09:09] re [09:09] took longer than i expected [09:57] Hi. I just installed snapd on Antergos from the AUR, and I set it up following the instructions for Arch. Installed the hello snap, and tried to run it. I get this error "cannot locate the core or legacy core snap (current symlink missing?): No such file or directory". snapd version 2.33, kernel 4.17.2-1-ARCH. Any ideas to what may be the issue? [09:58] searedvandal: does Antergos use systemd? [09:58] Chipaca, yes [09:59] phew [09:59] searedvandal: 'snap list' lists nothing? [09:59] searedvandal: can you pastebin the output of 'snap tasks --last=install' [10:00] searedvandal: and pacman -Qi snapd [10:00] Chipaca, https://ptpb.pw/_0LP [10:00] mborzecki, https://ptpb.pw/iJb7 [10:01] hmmmm [10:01] Chipaca, and snap list shows core and hello [10:02] searedvandal: yep. I'm guessing something is expecting /snap instead of /var/lib/snapd/snap or viceversa [10:02] mvo: there's somethign wrong with the 2.33.1 release on github [10:02] searedvandal: what's in /etc/os-release? [10:02] mvo: it doesn't have a tag (?) [10:03] Chipaca, my /etc/os-release https://ptpb.pw/xFrR [10:03] ID_LIKE=archlinux chceks out [10:03] mborzecki, the AUR has the 2.33 build, not the 2.33.1 [10:03] searedvandal: yeah, i'm updating to 2.33.1 now ;) [10:03] Mornings [10:04] mborzecki, ah :) [10:04] when I do 'snap version' the antergos line has this - , is that correct? https://ptpb.pw/rOFw [10:05] searedvandal: probably [10:05] alright [10:05] searedvandal: because it's a rollin' release [10:05] so no 'version' [10:05] ah, yeah [10:07] Chipaca, and I have the /snap directory and the /var/lib/snapd/snap directory [10:07] searedvandal: yes, it's the same on arch [10:07] searedvandal: /snap is just a symlink in your system right? [10:08] searedvandal: can you pastebin find /{var/lib/snapd/,}snap/ -maxdepth 2 -ls [10:09] mborzecki, Chipaca here is the paste https://ptpb.pw/Qp_i [10:10] searedvandal: ls -l / [10:10] mborzecki: that looks like /snap is not a symlink but the real thing [10:10] mborzecki: and /var/lib/snapd/snap has nothing [10:10] mborzecki, https://ptpb.pw/Pj_e [10:10] oh, you're right [10:11] that is very strange [10:11] something's askew (gesundheit) [10:11] searedvandal: yeah, the package ships with /var/lib/snapd/... only [10:11] strange. I have not created any directories or changed anything [10:11] it used to ship /snap -> /var/lib/snapd/snap symlink a while ago but we got rid of that [10:12] searedvandal: can you pacman -Qo /snap ? [10:12] mborzecki: I suspect distro detection being confuse [10:12] mborzecki, no package owns /snap [10:14] in hindsight, we should print a summary of directory info on startup, at least in debug [10:14] searedvandal: ok, if there's any snap mounted, unmount it and remove the package, remove /snap and install the package again [10:14] Chipaca: +1 [10:15] snap debug distro :) [10:16] and now i need to stop myself from doing that and getting back to figuring out why warnings has my snapd all panicky [10:19] mborzecki: let me check, it should have a tag [10:19] alright, you're right, it gets confused on os-detection. I removed a pacman hook that sets the antergos info and updated the filesystem package to revert to identifying as regular arch. now everything seems to work just fine [10:20] snap run hello gives me a nice hello world output [10:20] mvo: https://github.com/snapcore/snapd/releases/tag/untagged-ec50ee5bfb45daefc236 <-- untagged-... [10:22] searedvandal: yay [10:22] mborzecki: better now? sorry, no idea what happened there, github glitch [10:23] so snap doesn't like it when the system is identified as antergos, but when it's identified as arch it's all good :) [10:23] hm otoh we do release.DistroLike(..., "arch", ..) this should probably be "archlinux" to catch the derivatives [10:23] ah, probably :) [10:23] mvo, zyga, I just realized that next week will be the two year anniversary of me working on snappy on Fedora [10:23] mvo: yay! [10:23] :) [10:23] Time flies! [10:24] Son_Goku: we should get you some cake [10:24] two years ago next week, I agreed on a lark to go to the first snappy sprint [10:24] \o/ [10:24] I had received the email while (ironically) being at the Red Hat Summit [10:24] Son_Goku: woah, congrats \o/ [10:24] great to still have you here !! [10:24] * mvo hugs Son_Goku [10:25] and Josh Bressers and Thomas Cameron both told me I should go ahead and do it [10:25] so I did [10:25] (Josh: https://twitter.com/joshbressers; Thomas: https://twitter.com/thomasdcameron) [10:26] at the time, I was really unsure if I was the right person to go to this [10:27] of course, technically, I started two years ago next month, but... [10:27] searedvandal: could revert back to identifying as antegros and rebuild the package with this little fix https://ptpb.pw/Oo6u ? [10:27] because the Heidelberg sprint was July 22, 2016 [10:33] Interesting.. we're importing from the snap package inside client [10:34] This is something we should avoid as otherwise importing the client will depend on importing snapd entirely [10:34] Son_Goku: That reminds me that we need a dev sprint soon [10:35] niemeyer, I was wondering if we were going to go without one this year :) [10:36] PR snapd#5378 opened: dirs: improve identification of Arch Linux like systems [10:38] Son_Goku: We just need to think about what would be the best time and place.. we have non-dev sprints in July and September.. So either August or later in the year [10:39] so I'm going to be at DevConf.us Aug 17-19, so please don't schedule it then [10:39] searedvandal: just opened a PR with this change, if it works in our test suite I'll include it as a patch in 2.33.1 package, so your next rebuild should work fine [10:40] niemeyer, Flock is actually going on in Dresden, Germany on Aug 8-11: https://flocktofedora.org/ [10:40] if zyga wants to talk about snaps at Flock, now would be a good time ;) [10:41] Son_Goku: Ah, interesting [10:41] Very likely [10:41] Son_Goku: Are you going? [10:41] I can't afford to, so sadly no [10:42] niemeyer: we've been depending on snap from client for a long long time [10:42] zyga: almost anything goes for CfP: https://flocktofedora.org/#cfp [10:42] niemeyer: snap is where Revision and Epoch live [10:43] Chipaca: Yeah.. my memory is weak by now, but IIRC the agreement we got about this kind of thing was to revert the dependency, having such types in client itself [10:43] Chipaca: So that importing the client becomes isolated [10:44] Chipaca: The snapd/snap package by now spreads its legs through quite a few bits [10:44] As in, importing deps [10:44] niemeyer, but it'd be cool if Snapcraft was listed as a sponsor for Flock :P [10:44] Which is not a problem for it, to be clear.. it's just that the transitive dependency from client becomes weird [10:45] niemeyer: I thought it just used dirs and the different *util [10:45] Son_Goku: We can check that.. I haven't been involved in sponsorings for a while, so I'm not sure about what the current rules are [10:48] Son_Goku: this Flock is distinct from the flock that is a startup and an app? [10:48] yes... [10:48] Flock is the name for the Fedora contributor conference [10:48] which used to be called FUDCon [10:48] I can see how a contention mechanism is a better name than FUDCon [10:49] but it's not a wide margin :) [11:09] PR snapd#5378 closed: dirs: improve identification of Arch Linux like systems [11:11] mvo: i think the tag can be removed: [11:11] * [new tag] untagged-ec50ee5bfb45daefc236 -> untagged-ec50ee5bfb45daefc236 [11:12] suprising github actually allowed creating this [11:13] re [11:13] * zyga picked up the coffee he made at 7 [11:13] mborzecki, Pharaoh_Atem: can you please eyeball https://github.com/snapcore/snapd/pull/5377 [11:13] it's the last of the bunch [11:13] PR #5377: packaging/opensuse: remaining packaging updates for 2.33.1 [11:21] mvo: hey [11:21] did you have a chance to look at https://github.com/snapcore/snapd/pull/5369 [11:21] PR #5369: overlord,interfaces,cmd: WIP early support for interfaces on core18 [11:21] hey zyga [11:22] zyga: looking at it currently [11:22] :-D ok, let me know once you've read it [11:22] I'll write something on the forum now [11:22] oh my how smooth TrackMania runs, I'm impressed [11:23] zyga: ok [11:27] snap downloads capped at 100kBps again? [11:27] mborzecki: hmm, not for me [11:28] 7MB/s [11:28] hmm 2 times hit 100kBps, another restart and 1.2MB now [11:28] over my LTE link [11:29] I looked at stats and I still cannot stop being impressed by how I can effortlessly live on LTE with 100s of GB of data used monthly [11:29] for the price of a meal in spain [11:29] (one meal, for one person) === pstolowski is now known as pstolowski|lunch [11:36] PR snapd#5379 opened: overlord/snapstate: disallow installing snapd on baseless models [11:36] zyga: I split the snapd prevention bits (and added a trivial test) - I think we deefinitely want this [11:36] prevention bits? [11:36] the snapd.snap removal/installation? [11:36] zyga: disallow installing the snapd snap [11:37] note that it breaks the tests today :/ [11:45] zyga: it does? which one? [11:46] just look at the test failures, all the core 18 tests exploded [11:46] I asked if this was expected (perhaps the way we install snapd is not right) but we didn't talk about it since [11:46] zyga: aha, I will debug it :) [11:46] zyga: "all the core18 tests" - all two of them ;) ? [11:47] zyga: aha, I see what is going on [11:47] * mvo scratches head [11:49] zyga: testing a fix now, and then I will go over the rest. thanks in any case! [11:52] searedvandal: changes are in AUR now [11:52] mborzecki, nice, thanks! [11:55] mvo, wait, does that mean it'd be possible to make snapd snap either-or if a base snap provided snapd? [11:55] I'm confused what PR#5379 actually does [11:58] Son_Goku: we're transitioning from having snapd in core to having snapd in snapd [11:58] :/ [11:58] Son_Goku: we're special casing the special case so we can special case while we special case [11:58] Son_Goku: why :/? [11:58] because I don't understand what's going on here [11:59] I'm confused [11:59] Son_Goku: core 18 won't have snapd [11:59] rather [11:59] Son_Goku: because of core18 and core16 the idea of having snapd in _a_ core is gone [11:59] Son_Goku: core18 does not have snapd [11:59] Son_Goku: neither will core16 [11:59] so snapd moves to its own proper package [11:59] eventually the only snap that ships snapd will be snapd.snap [11:59] Son_Goku: today, core does; core will become core16 and snapd [11:59] hmm [11:59] this will simplify and unify various special cases [12:00] there were special cases? [12:00] and will make it natural to have bases [12:00] Son_Goku: but as core and core16 will co-exist, we want to put little yellow "don't step on the bubbling lava" signs [12:00] yeah, plenty of them [12:00] still are but this will help to remove it [12:00] core wil transition to core16 [12:00] Son_Goku: the end game is _less_ special cases, not more, fwiw [12:00] okay, I think I get it [12:00] Son_Goku: where there must be a snapd snap, but you can have any base (and that base evolves separately from snapd itself) [12:00] Son_Goku: snap-confine will hopefully shrink a little thanks to this [12:01] most of this doesn't really affect me though, since we don't allow re-exec on Fedora [12:01] and snap-run/snap-exec/snapd code will drop some if name == "core" code [12:01] since your snapd breaks things [12:01] * Chipaca hopes Son_Goku doesn't ask what base snapd will use [12:01] I think I have a feeling that snapd will use base snapd [12:01] or worse, base ubuntu-core16 [12:01] * Chipaca votes it uses base 'bo' [12:02] Son_Goku: snapd won't use any base [12:02] or maybe base 'politically-incorrect-inanimate-object' [12:02] it's not a snap that ships apps or services in the traditional sense [12:02] more like a vehicle for runtime bits for any base [12:03] (snap-confine/exec/snapctl chain) [12:03] so it pretty much doesn't affect me [12:03] since we don't use those bits [12:03] no, you are slightly mistaken [12:03] it'd only become a problem once we have a fedora bootable base :/ [12:03] you do use snap-exec and snapctl from core [12:03] that's always been the case [12:04] you don't use snap-confine from core when running snaps from the outside [12:04] Son_Goku: bootable fedora base is happening though, right? [12:04] that's something zyga and I are working toward, yes [12:04] I already know that we're in for hell because I can't swap the snapd :/ [12:04] Chipaca: yes, eventually, I think this cycle we will get fedora29 base for apps and future development though [12:05] * Son_Goku really wishes core16 / core18 would be ubuntu-core16 / ubuntu-core18 [12:05] that's what they actually are, after all [12:08] Son_Goku: I think it's that until there are other bases realistically out there being used, we don't want to have people think they're downloading all of ubuntu just to run tmnationsforever [12:08] well there's already other bases in use [12:08] at least ikey has the one for steam [12:08] * Chipaca misses ikey [12:09] and _a_ fedora base snap will be available by Fedora 29 GA [12:09] I can almost nearly guarantee it [12:10] primarily because I can make one whenever I want [12:10] Son_Goku: one good thing is that "core" will go away and become core{16,18} and those will shrink [12:10] the work zyga and I will be doing this development cycle is integrating this into the infra tooling so it's literally part of the compose [12:10] Son_Goku: I'll raise it in the standup (unless zyga does it first) [12:10] that is, part of the process to make all the release artifacts [12:10] we also considered (though not scheduled to do it) a bootless core which would be even smaller by a large amount [12:11] I think the bootless split was kicked to 20 [12:11] yeah [12:11] too many moving parts [12:11] yep [12:11] Chipaca: raise what exactly? [12:11] zyga: ubuntu-core18 instead of just core18 [12:11] zyga, what does snapd.seeded.service do? [12:11] Son_Goku: wait until snapd is seeded [12:12] Son_Goku: tells you that the system has installed all of the snaps that are in the seed (from the model) [12:12] Son_Goku: it basically tells you that it is ready after first boot [12:12] ah [12:12] so is this something we need to have enabled in the fedora preset? [12:12] before that snapd is busy doing stuff and not really responding [12:12] because right now, it ai't [12:12] *ain't [12:12] Son_Goku: it's useful as target of "after snapd is there" [12:12] Son_Goku: shouldn't hurt, and would let you play with seeds [12:12]