=== mup_ is now known as mup [05:01] morning [05:06] PR snapd#5360 closed: tests: fix shellcheck 0.5.0 warnings [05:54] good morning [05:54] I will be here shortly [05:58] zyga: hey [06:12] hey, just getting a coffee [06:22] can I get an ack for https://github.com/snapcore/snapd/pull/5347 [06:22] ready and green just needs a review [06:22] well [06:22] an ack [06:22] PR #5347: data: remove /bin/sh from snapd.sh [06:30] PR snapd#5347 closed: data: remove /bin/sh from snapd.sh [06:38] hey sil2100 [06:50] mborzecki: can you have a quick look at https://github.com/snapcore/snapd/pull/5355 [06:51] PR #5355: data/complete: fix three out of four shellcheck warnings in data/complete [07:07] anyone wants to do a 2nd review on #5359 ? [07:07] PR #5359: spread-shellcheck: use a whitelist of files that are allowed to fail validation [07:12] once this lands i have another pr that uses shellcheck from snap, although in --devmode because of our setup [07:14] I can :) [07:14] I restarted various failed PRs from yesterday [07:16] mborzecki: can I add type annotations to spread-shellcheck? [07:16] in a follow-up [07:16] and make it mypy clean? [07:16] nothing like static typing : [07:16] :) [07:17] zyga: pfff, you work on interfaces for core ;) [07:17] core18 [07:17] mvo: yes, that's almost done though :) [07:17] but good point :P [07:17] zyga: aha! thats cool [07:17] zyga: first the chores, then the fun :P [07:18] zyga: sure [07:18] mornings [07:18] zyga: but thats great to hear, I look forrward to working tests and then we can run spread again on core18 [07:18] hey pstolowski ! good morning [07:19] hey pawel [07:20] mvo: hi, could you re-review 5352 when you have a bit some time [07:20] btw. it'd be nice to have an interface that allows access to arbitrary paths, and have those paths added/configured as a list per connection [07:20] mborzecki: I had something like this planned a while ago [07:20] pedronis pstolowski: morning guys [07:20] pedronis: absoutely, thank you! [07:20] pedronis: and good morning :) [07:20] my desire then was to have an snapctl api where a snap could talk to snapd and create interfaces [07:21] so "hot plug" like but snap (not snapd) driven [07:21] pedronis: its even green! how did you manage that given the stormy spread weather we had :) ? [07:21] that idea died though, we could do something different with a new interface [07:22] mborzecki: the problem is that unless we tied it down in the snap declaration (but gets annoying), is really access to any path [07:23] pedronis: my idea was that you could only select a subset of home [07:23] so it would be like scoped home [07:24] ok, that's different from what mborzecki proposed [07:24] though [07:25] mvo: thanks, marked it blocked until I can discuss something with the store people, mostly wondering if there's a chance client StoreAccount and then one internal/from store can diverge [07:26] pedronis: heh, I almost merged it. good that I was unusually not trigger happy this morning [07:26] mvo: nothing too bad if it was merged, mostly wondering if we need to StoreAccounts or using just one is ok [07:27] in most uses of client should be immaterial either way [07:27] s/to/two/ [07:27] * mvo nods [07:29] mvo: when will we cut 2.34 ? from discussions from yesterday it seems there was a couple of things still desired for it [07:30] pstolowski: did you got a chance to play a bit with 5356, i.e. the bits we brainstormed yesterday to figure out why exactly its is not working [07:30] pedronis: I think early next week [07:30] pedronis: we need a 2.33.1 with some adt fixes [07:30] ok [07:30] pedronis: so maybe middle next week even [07:30] pedronis: what is pending from your pov? [07:31] mvo: afaiu understand work to get better errors if a snap is missing from arch or channel, and expanding searches to other risks [07:31] mvo: no, i wanted to have full spread tests suite run first (which wasn't possible due to gce) [07:31] mvo: the first bit should be in store prod now, the 2nd soon [07:31] but need snapd work [07:32] mvo: and I have my gadget connect PR that needs a review from you :) [07:32] pedronis: thats exciting - is the store read for the better errors? [07:32] pedronis: aha, you replied, cool [07:32] pedronis: yeah, I need to do that review, will do it this morning [07:33] pstolowski: heh, yeah, a bit of a storm yesterday [07:33] pstolowski: thank you [07:33] pedronis: I'm quite excited about the error messages, where can I learn more where we stand and what changed? [07:35] mvo: we have a bit of a problem there though, related to our own API errors, we set Value just to snapName in the relevant errors, so a bit unclear where to stick the extra info... we can put in the better message but is not ideal for all clients [07:36] zyga: pedronis: hm i thought about arbitrary, user set, paths, as in something that neither fits the removable-media, nor home interfaces and the location is kind of oustide of your control [07:37] mborzecki: as I said, it's doable but unless we have corresponding control in the snap-declaration, is really a blank check. the developer controls what goes into her snap.yaml [07:37] in case of shellchecks, shellcheck snap comes with home and removable media interfaces, but the tests are run as root and the source code is at /home/gopath, i could probably hack around with some bind mount or just use --devmode (and open up everything?) [07:38] mborzecki: ah, user set [07:38] mmh, we don't have anything like that [07:38] it would add quite a bit complexity to the machinary [07:38] pedronis: yes [07:39] we can discuss it over a glass of beer while in BRU :) [07:47] mvo: about your question, we get a bit like this: 'extra': { [07:47] 'releases': [{'architecture': 'amd64', [07:47] 'channel': 'beta'}]} [07:47] }, [07:47] in revision-not-found errors [07:48] pedronis: nice! [07:49] mvo: as I said, the problem is that we don't have a place to stick it in our own API errors [07:50] mvo: https://github.com/snapcore/snapd/blob/master/daemon/response.go#L368 the way we set directly Value: snapName is the problem, changing that is backward incompatible [07:51] pedronis: in our own snapd api errors? hm, hm, ok. could we just invent an "extra" field as well (just thinking out loud)? [07:51] yes, but it a bit of a kludge, basically we had one (Value) but we used it a bit naively [07:52] pedronis: could we invent new types? errorKindSnapRevisionNotAvailableWrong{Arch,Channel} - I guess old clients would not show a nice error with that but usually snap/snapd will be in sync so its just ugly for a minority ? [07:52] we can also do that [07:53] pedronis: what approach do you like best :)? [07:54] none :) [07:54] heh [07:54] * mvo scratches head then [07:55] pedronis: sounds like something to talk about during the standup to figure out the least disliked option [07:55] yes [07:58] mborzecki: can you take another look at https://github.com/snapcore/snapd/pull/5323 ? [07:58] PR #5323: ifacestate: prevent running interface hooks twice when self-connecting on autoconnect === mborzeck1 is now known as mborzecki [08:09] mvo: fwiw snapd-glib doesn't support yet explicity snap-revision-not-available [08:09] also doesn't seem to use "value" at all from errors [08:10] zyga: good morning. Chinese is not a language. [08:11] yeah I know, it's a simplification ;) [08:11] zyga: :) [08:11] how do I spell the M... thing? [08:11] zyga: Mandarin [08:11] zyga: unless you meant Mapudungun [08:11] hehe [08:11] does it have as many users? :) [08:11] fixed [08:12] zyga: Mapudungun has 260k native speakers [08:12] approx [08:12] that's still more than the people who refuse to use systemd ;P [08:14] zyga: but like the non-systemd users, they're being oppressed [08:14] ok that turned the wrong way and I shall go sit in silence and think about my sins for a bit [08:15] zyga: how hard would it be to have a script that you ran on a system and it told you all the ways in that snapd would fail to run? [08:15] Chipaca: that's interesting, [08:15] well, some of that is in the new self-test work that mvo started [08:15] no systemd, wonky kernel [08:15] like, "your apparmor was not shipped in slackware 1.0 because it was too old", etc [08:16] old apparmor userspace is another thing to check for [08:16] or "Slackware hates systemd, sorry" [08:16] non-linux kernel [08:16] are you after a shell script? [08:16] over golang? [08:16] zyga: ideally :) [08:17] android userspace [08:17] mmm [08:17] mvo: tried to answer your questions [08:17] 2MB usable ram [08:17] Chipaca: we could try [08:17] Chipaca: eventually that script could wget snapd.snap ;) [08:17] ssshhh [08:18] all the squashfs stuff, the mount crashes fixes [08:18] dunno how to test for the latter [08:19] anyway. Good morning. [08:19] good morning :) [08:19] * Chipaca brought donuts to the office [08:19] oh, you are at the office today? [08:19] … ok, my bedroom [08:19] FINE [08:19] ah :( [08:19] well [08:19] * zyga looks around at his "office" [08:19] :) [08:19] I just envied you for a brief moment [08:20] ah, no, i'm happy like this, mostly [08:20] PR snapd#5323 closed: ifacestate: prevent running interface hooks twice when self-connecting on autoconnect [08:20] I sometime miss the office [08:20] if we had one in Warsaw I'd use it a few days a week [08:20] (lugging my iMac on the bus ;) [08:20] me too, but it takes one morning to commute in and i'm over it [08:20] (every ~6 months or so) [08:21] I need to try [08:21] I'll find some cheap flight to UK and commute once ;) [08:21] OTOH, I could totally build an office in a van and go visit people [08:21] hahaha [08:21] pedronis: thank you! as for the second resolveSnapIDToname, I was mostly wondering if we should have a gadget-connect test that uses the "system" name explicitly but maybe overkill [08:22] Chipaca: feel like tackling the traveling salesman problem irl? [08:22] mborzecki: I suck at sales [08:22] mborzecki: but other than that, sure :) [08:22] mvo: well, it is explicit for that level of code, already the parsing makes all entries non empty [08:22] pedronis: ok [08:23] "yeah i'm here to show you this thing we built, which is cool, it's got all these issues [ three hours later ] pay me [08:23] mvo: that is code from the previous PR [08:23] slot is really system:network-control at that point of the code [08:24] pedronis: aha, that was the missing piece then - I remember now [08:24] mvo: adding the comment, I need to merge master anyway because of Name vs InstanceName [08:25] pedronis: thank you [08:26] zyga: in distros that don't have /snap/bin, what's added to PATH? [08:26] Chipaca: /var/lib/snapd/snap/bin [08:26] it's the same [08:26] I mean, the same script [08:26] ugly, no? [08:27] zyga: dunno if you're talking about #5355 but I was [08:27] PR #5355: data/complete: fix three out of four shellcheck warnings in data/complete [08:27] ah [08:27] I'll do that [08:27] thanks, I'll push this branch in a moment [08:28] I'm moving all suse machines from drive to drive so they are suspend now [08:32] zyga: you have way too much fun for it to be legal [08:33] such as? [08:33] zyga: moving suse machines around [08:34] I can hear the disks clicking [08:34] PR snapd#5351 closed: packaging/opensuse: build position-independent binaries [08:35] zyga, dammit I'm blind [08:35] oh? [08:35] https://github.com/snapcore/snapd/commit/e21034320459354b8acd9d1c194946ceda363a6e#diff-36a23153f5bbd7bffd11c24597ac50fdR146 [08:35] I don't know _how_ that's valid shell [08:35] it should have barfed again this time [08:35] thanks! [08:36] I'll fix it... in about 10 minutes when the copy is over [08:36] haha [08:44] PR snapd#5363 opened: snap: introduce the instance key field [08:45] pedronis: this should be fairly uncontroversial ^^ [08:51] gnome shell actively not taking input because it's too busy dumping backtraces from js :( [09:02] PR snapd#5364 opened: packaging/opensuse: fix typo, missing assignment [09:06] mborzecki: review on https://github.com/snapcore/snapd/pull/5363#pullrequestreview-130726810 [09:06] Pharaoh_Atem: fixed, thank you! [09:06] PR #5363: snap: introduce the instance key field [09:07] zyga: thanks! [09:08] PR snapd#5359 closed: spread-shellcheck: use a whitelist of files that are allowed to fail validation [09:10] PR snapd#5357 closed: firstboot: mark essential snaps as "Required" in the state [09:11] reviews for 5361 would be great, should be straightforward and unblocks some more spread runs [09:12] 5339 is also updated but that is a bit annoying to reivew (too much shell) :/ [09:15] Chipaca: one final look at https://github.com/snapcore/snapd/pull/5355/ [09:15] PR #5355: data/complete: fix three out of four shellcheck warnings in data/complete [09:16] pedronis: a quick look my comment in 5331 would be great, if it captures enough information why we sort snapd first [09:19] mvo: which reminds that sorting is not enough [09:24] mborzecki: thanks for the inisght into systemd seeded PR [09:24] mvo: we need to tweak also the code here https://github.com/snapcore/snapd/blob/master/overlord/snapstate/snapstate.go#L806 [09:24] to consider snapd in both sides of the if [09:25] pstolowski: iirc we stop all snapd* services in prepare, maybe that's why it's inactive/dead in your test [09:26] pedronis: indeed [09:31] mvo: done [09:32] zyga: thank you [09:33] mvo: conflict on https://github.com/snapcore/snapd/pull/5358 [09:33] PR #5358: tests: add spread test to ensure snapd/core18 are not removable [09:33] zyga: thanks, looking [09:35] mborzecki: thank you as well for the review! [09:35] PR snapd#5353 closed: data/completion: fix inconsistency in +x and shebang [09:35] PR snapd#5365 opened: spread-shellcheck: use the latest shellcheck available from snaps [09:44] PR snapd#5317 closed: overlord: introduce a gadget-connect task and use it at first boot [09:45] pstolowski: hi, I merged my gadget-connect branch, that means I fear conflicts for the disconnect hooks one [09:46] pedronis: ack, thanks for heads up [09:49] 5361 needs a second revie wnow [09:49] (really simple :) [09:51] PR core18#24 closed: Add the systemd-sysv package for tools like shutdown and reboot [09:55] zyga: you asked about locales all - when I just add this package the snap grows by 12mb [09:55] yeah, sil2100 did the experiment yesterday [09:55] zyga: aha, I missed the results [09:55] I would like to consider it, for the sake of making locale not suck again [09:56] snap authors cannot really do it inside snaps, from what I know [09:56] I'll try looking into slimming down the core18 snap [09:56] Maybe then we'll feel less sad with the additional 11-12MB [09:57] (hello btw. o/) [09:58] sil2100: yay, please do [09:58] sil2100: is the new data _solely_ inside /usr/share/locale? [09:58] sil2100: a diff of list of files would be awesome if you have one handy [09:59] zyga: yes, it's just /usr/lib/locale/* [10:00] * sil2100 goes AFK now to argue with some bad people [10:00] zyga: and its massive, du -s | sort -n shows that its a whole lot of 1-3mb files [10:01] mvo: iff 11MB is what we need to make snaps talk languages maybe that's not _so_ bad [10:01] I mean, the size is tiny in comparison to anything modern, just the download size is a problem [10:08] we should have a hello-i18n snap [10:08] that uses python and get text [10:08] or something that was problematic lately [10:08] (or actually have one set of .mo files and use many implementations to test stuff) [10:09] zyga, unrelated, but... [10:09] yeah? [10:09] from #fedora-devel: [10:09] [05:58:33 AM] the selinux kernel code is slowly growing support for namespaces, so we might see policies in flatpak sometime in the future. i think the existing container-selinux package could be used to create flatpak-specific policies though, but would probably need some upstream support to determine how you label the process [10:09] pstolowski: 5356 seems to be failing, I guess that is on your radar? [10:09] pstolowski: the fix for snapd.seeded [10:09] zyga, my understanding is that namespaced labels are the key to making selinux confined snaps work [10:09] mvo: yes i'm looking at right now. it's interesting [10:10] pstolowski: (sorry for being a bit pushy here) [10:10] Son_Goku: no, I don't think that's critical [10:10] no? [10:10] Son_Goku: note that apparmor and namespaced labels are not important either [10:10] just when you have multiple containers [10:10] then it is important [10:10] wouldn't it be necessary for running LXD or Docker as a snap? [10:10] the most important first step on the topic of snapd and selinux is how the hell to get started :) [10:11] Son_Goku: I don't know [10:11] well, mvo, lvrabec, and pmoore are in a mail convo about that [10:11] though mvo has been bad about not responding to them :/ [10:11] I finally bit the bullet and did yet another response that I feel was probably not terribly helpful :/ [10:11] zyga: iirc we've discussed overlayfs some time ago [10:12] Son_Goku: yes - sorry for that [10:12] zyga, the SELinux warnings and denials have reached the point that the Red Hat SELinux guys would like to help us [10:12] but I can't do anything to make this better, because I'm too incompetent to figure out how the security model works [10:13] and I'm stretched really thinly right now [10:14] Son_Goku: oh, interesting, [10:14] Son_Goku: do you have any names I could ping? [10:14] mvo has them [10:14] cool, I didn't know about this [10:14] mvo, please reply to them with some useful info and CC zyga [10:14] eventually we could patch our test suite so that no _new_ warnings are introduced [10:14] zyga, are you not following selinux@ and devel@ on lists.fp.o? [10:15] Son_Goku: I'm subscribed but man, I'm not following my inbox much [10:15] too many things lately [10:16] zyga: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org/thread/U6JJ3IIJNNGGDZECSIMZC5UODAECCWPT/ [10:30] mborzecki, mvo: what about instance installation of snapd? [10:30] zyga: what do you mean? [10:30] can we snap install snapd_foo [10:30] and if so, what shall that mean? [10:30] no, it will be blocked [10:31] kernel, gadget, core & snapd snaps are non parallel installable [10:31] s/core/os/ [10:32] mborzecki: but you can parallel-install base snaps? [10:35] i suppose not, don't think that would be useful [10:37] mborzecki: maybe just clamp it to apps and "" [10:37] I think you're inviting trouble with instance installs of snaps [10:38] what problem are you trying to solve here? [10:39] Son_Goku: it's our 3rd most requested feature afaik [10:39] Son_Goku: after world peas and universal healthcare [10:39] I don't know if we should make "world peas" [10:39] :) [10:40] :D [10:40] Son_Goku: split pea and ham soup tho [10:40] haha [10:40] or just split pea soup [10:42] mvo: what was the failure with parsing losetup output? [10:42] ohh [10:42] mvo: fun issue [10:42] https://www.irccloud.com/pastebin/ACep9bL8/ [10:42] base policy needs love now [10:46] mvo: to fix this it would be _really_ nice to have slot-snap-type: snapd [10:47] that is, a dedicated type for snapd snap [10:47] WDYT? [10:47] pedronis: ^ [10:47] zyga, can I not have a snapd snap installed? [10:47] it's going to be dead code on my system [10:47] Son_Goku: no, it's mandatory because otherwise the code would be even more hairy [10:48] and it's not dead code entirely, as it interacts with snap-exec and snapctl at runtime [10:48] (they are taken from the snapd snap) [10:48] but using the snapd you guys build breaks things :/ [10:48] that's why we have to disable re-exec for every distro except Ubuntu [10:48] mborzecki: it will give me /dev/loop4 but I need /dev/mapper/loop4p3 [10:48] we won't use snapd but we will use other files from the snapd.snap [10:49] does that mean that patches against those binaries on the host are basically ineffective, then? [10:49] they are today [10:49] :/ [10:49] there's a lot of non-trivial stuff involved [10:49] and edge cases that are easy to miss [10:50] zyga: we need to discuss, adding a type like that doesn't make a lot of sense. really in that context "core" means system [10:50] mborzecki: don't get me wrong, I'm not opposed to fix it, just want to get this PR landed to make the followups smaller (and its not worse than before arguable at least) [10:50] pedronis: it's that or patching the policy checker to imply that snap name "snapd" has magic type "core" [10:51] zyga: well, we cannot use the name [10:51] ? [10:51] we really need to use the snap id at that level [10:51] woah, so what can we use? [10:51] that won't fly [10:51] mvo: no worries, just wondered if there's something fishin in losetup output there, and if so i can take a look at it later [10:51] store changes and all that [10:51] I mean, staging vs prod [10:51] I really like the simplicity of snap type [10:51] if name is a no-go then we need to discuss how this ought to work [10:52] snap type needs store changes too [10:52] and review-tools changes [10:52] when I said store changes I meant snapd talking to prod store or staging store [10:52] I agree that a new type needs store side changes [10:52] I know [10:52] hmm [10:52]