| === mup_ is now known as mup | ||
| mborzecki | morning | 05:01 |
|---|---|---|
| mup | PR snapd#5360 closed: tests: fix shellcheck 0.5.0 warnings <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5360> | 05:06 |
| zyga | good morning | 05:54 |
| zyga | I will be here shortly | 05:54 |
| mborzecki | zyga: hey | 05:58 |
| zyga | hey, just getting a coffee | 06:12 |
| zyga | can I get an ack for https://github.com/snapcore/snapd/pull/5347 | 06:22 |
| zyga | ready and green just needs a review | 06:22 |
| zyga | well | 06:22 |
| zyga | an ack | 06:22 |
| mup | PR #5347: data: remove /bin/sh from snapd.sh <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5347> | 06:22 |
| mup | PR snapd#5347 closed: data: remove /bin/sh from snapd.sh <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5347> | 06:30 |
| zyga | hey sil2100 | 06:38 |
| zyga | mborzecki: can you have a quick look at https://github.com/snapcore/snapd/pull/5355 | 06:50 |
| mup | PR #5355: data/complete: fix three out of four shellcheck warnings in data/complete <Created by zyga> <https://github.com/snapcore/snapd/pull/5355> | 06:51 |
| mborzecki | anyone wants to do a 2nd review on #5359 ? | 07:07 |
| mup | PR #5359: spread-shellcheck: use a whitelist of files that are allowed to fail validation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5359> | 07:07 |
| mborzecki | once this lands i have another pr that uses shellcheck from snap, although in --devmode because of our setup | 07:12 |
| zyga | I can :) | 07:14 |
| zyga | I restarted various failed PRs from yesterday | 07:14 |
| zyga | mborzecki: can I add type annotations to spread-shellcheck? | 07:16 |
| zyga | in a follow-up | 07:16 |
| zyga | and make it mypy clean? | 07:16 |
| zyga | nothing like static typing : | 07:16 |
| zyga | :) | 07:16 |
| mvo | zyga: pfff, you work on interfaces for core ;) | 07:17 |
| mvo | core18 | 07:17 |
| zyga | mvo: yes, that's almost done though :) | 07:17 |
| zyga | but good point :P | 07:17 |
| mvo | zyga: aha! thats cool | 07:17 |
| mvo | zyga: first the chores, then the fun :P | 07:17 |
| mborzecki | zyga: sure | 07:18 |
| pstolowski | mornings | 07:18 |
| mvo | zyga: but thats great to hear, I look forrward to working tests and then we can run spread again on core18 | 07:18 |
| mvo | hey pstolowski ! good morning | 07:18 |
| zyga | hey pawel | 07:19 |
| pedronis | mvo: hi, could you re-review 5352 when you have a bit some time | 07:20 |
| mborzecki | 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 |
| zyga | mborzecki: I had something like this planned a while ago | 07:20 |
| mborzecki | pedronis pstolowski: morning guys | 07:20 |
| mvo | pedronis: absoutely, thank you! | 07:20 |
| mvo | pedronis: and good morning :) | 07:20 |
| zyga | my desire then was to have an snapctl api where a snap could talk to snapd and create interfaces | 07:20 |
| zyga | so "hot plug" like but snap (not snapd) driven | 07:21 |
| mvo | pedronis: its even green! how did you manage that given the stormy spread weather we had :) ? | 07:21 |
| zyga | that idea died though, we could do something different with a new interface | 07:21 |
| pedronis | mborzecki: the problem is that unless we tied it down in the snap declaration (but gets annoying), is really access to any path | 07:22 |
| zyga | pedronis: my idea was that you could only select a subset of home | 07:23 |
| zyga | so it would be like scoped home | 07:23 |
| pedronis | ok, that's different from what mborzecki proposed | 07:24 |
| pedronis | though | 07:24 |
| pedronis | 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:25 |
| mvo | pedronis: heh, I almost merged it. good that I was unusually not trigger happy this morning | 07:26 |
| pedronis | mvo: nothing too bad if it was merged, mostly wondering if we need to StoreAccounts or using just one is ok | 07:26 |
| pedronis | in most uses of client should be immaterial either way | 07:27 |
| pedronis | s/to/two/ | 07:27 |
| * mvo nods | 07:27 | |
| pedronis | mvo: when will we cut 2.34 ? from discussions from yesterday it seems there was a couple of things still desired for it | 07:29 |
| mvo | 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 |
| mvo | pedronis: I think early next week | 07:30 |
| mvo | pedronis: we need a 2.33.1 with some adt fixes | 07:30 |
| pedronis | ok | 07:30 |
| mvo | pedronis: so maybe middle next week even | 07:30 |
| mvo | pedronis: what is pending from your pov? | 07:30 |
| pedronis | 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 |
| pstolowski | mvo: no, i wanted to have full spread tests suite run first (which wasn't possible due to gce) | 07:31 |
| pedronis | mvo: the first bit should be in store prod now, the 2nd soon | 07:31 |
| pedronis | but need snapd work | 07:31 |
| pedronis | mvo: and I have my gadget connect PR that needs a review from you :) | 07:32 |
| mvo | pedronis: thats exciting - is the store read for the better errors? | 07:32 |
| mvo | pedronis: aha, you replied, cool | 07:32 |
| mvo | pedronis: yeah, I need to do that review, will do it this morning | 07:32 |
| mvo | pstolowski: heh, yeah, a bit of a storm yesterday | 07:33 |
| mvo | pstolowski: thank you | 07:33 |
| mvo | pedronis: I'm quite excited about the error messages, where can I learn more where we stand and what changed? | 07:33 |
| pedronis | 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:35 |
| mborzecki | 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:36 |
| pedronis | 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 |
| mborzecki | 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:37 |
| pedronis | mborzecki: ah, user set | 07:38 |
| pedronis | mmh, we don't have anything like that | 07:38 |
| pedronis | it would add quite a bit complexity to the machinary | 07:38 |
| mborzecki | pedronis: yes | 07:38 |
| mborzecki | we can discuss it over a glass of beer while in BRU :) | 07:39 |
| pedronis | mvo: about your question, we get a bit like this: 'extra': { | 07:47 |
| pedronis | 'releases': [{'architecture': 'amd64', | 07:47 |
| pedronis | 'channel': 'beta'}]} | 07:47 |
| pedronis | }, | 07:47 |
| pedronis | in revision-not-found errors | 07:47 |
| mvo | pedronis: nice! | 07:48 |
| pedronis | mvo: as I said, the problem is that we don't have a place to stick it in our own API errors | 07:49 |
| pedronis | 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:50 |
| mvo | 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 |
| pedronis | yes, but it a bit of a kludge, basically we had one (Value) but we used it a bit naively | 07:51 |
| mvo | 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 |
| pedronis | we can also do that | 07:52 |
| mvo | pedronis: what approach do you like best :)? | 07:53 |
| pedronis | none :) | 07:54 |
| mvo | heh | 07:54 |
| * mvo scratches head then | 07:54 | |
| mvo | pedronis: sounds like something to talk about during the standup to figure out the least disliked option | 07:55 |
| pedronis | yes | 07:55 |
| pstolowski | mborzecki: can you take another look at https://github.com/snapcore/snapd/pull/5323 ? | 07:58 |
| mup | PR #5323: ifacestate: prevent running interface hooks twice when self-connecting on autoconnect <Created by stolowski> <https://github.com/snapcore/snapd/pull/5323> | 07:58 |
| === mborzeck1 is now known as mborzecki | ||
| pedronis | mvo: fwiw snapd-glib doesn't support yet explicity snap-revision-not-available | 08:09 |
| pedronis | also doesn't seem to use "value" at all from errors | 08:09 |
| Chipaca | zyga: good morning. Chinese is not a language. | 08:10 |
| zyga | yeah I know, it's a simplification ;) | 08:11 |
| Chipaca | zyga: :) | 08:11 |
| zyga | how do I spell the M... thing? | 08:11 |
| Chipaca | zyga: Mandarin | 08:11 |
| Chipaca | zyga: unless you meant Mapudungun | 08:11 |
| zyga | hehe | 08:11 |
| zyga | does it have as many users? :) | 08:11 |
| zyga | fixed | 08:11 |
| Chipaca | zyga: Mapudungun has 260k native speakers | 08:12 |
| Chipaca | approx | 08:12 |
| zyga | that's still more than the people who refuse to use systemd ;P | 08:12 |
| Chipaca | zyga: but like the non-systemd users, they're being oppressed | 08:14 |
| Chipaca | ok that turned the wrong way and I shall go sit in silence and think about my sins for a bit | 08:14 |
| Chipaca | 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 |
| zyga | Chipaca: that's interesting, | 08:15 |
| zyga | well, some of that is in the new self-test work that mvo started | 08:15 |
| zyga | no systemd, wonky kernel | 08:15 |
| Chipaca | like, "your apparmor was not shipped in slackware 1.0 because it was too old", etc | 08:15 |
| zyga | old apparmor userspace is another thing to check for | 08:16 |
| zyga | or "Slackware hates systemd, sorry" | 08:16 |
| Chipaca | non-linux kernel | 08:16 |
| zyga | are you after a shell script? | 08:16 |
| zyga | over golang? | 08:16 |
| Chipaca | zyga: ideally :) | 08:16 |
| Chipaca | android userspace | 08:17 |
| zyga | mmm | 08:17 |
| pedronis | mvo: tried to answer your questions | 08:17 |
| Chipaca | 2MB usable ram | 08:17 |
| zyga | Chipaca: we could try | 08:17 |
| zyga | Chipaca: eventually that script could wget snapd.snap ;) | 08:17 |
| Chipaca | ssshhh | 08:17 |
| Chipaca | all the squashfs stuff, the mount crashes fixes | 08:18 |
| Chipaca | dunno how to test for the latter | 08:18 |
| Chipaca | anyway. Good morning. | 08:19 |
| zyga | good morning :) | 08:19 |
| * Chipaca brought donuts to the office | 08:19 | |
| zyga | oh, you are at the office today? | 08:19 |
| Chipaca | … ok, my bedroom | 08:19 |
| Chipaca | FINE | 08:19 |
| zyga | ah :( | 08:19 |
| zyga | well | 08:19 |
| * zyga looks around at his "office" | 08:19 | |
| Chipaca | :) | 08:19 |
| zyga | I just envied you for a brief moment | 08:19 |
| Chipaca | ah, no, i'm happy like this, mostly | 08:20 |
| mup | PR snapd#5323 closed: ifacestate: prevent running interface hooks twice when self-connecting on autoconnect <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5323> | 08:20 |
| zyga | I sometime miss the office | 08:20 |
| zyga | if we had one in Warsaw I'd use it a few days a week | 08:20 |
| zyga | (lugging my iMac on the bus ;) | 08:20 |
| Chipaca | me too, but it takes one morning to commute in and i'm over it | 08:20 |
| Chipaca | (every ~6 months or so) | 08:20 |
| zyga | I need to try | 08:21 |
| zyga | I'll find some cheap flight to UK and commute once ;) | 08:21 |
| Chipaca | OTOH, I could totally build an office in a van and go visit people | 08:21 |
| zyga | hahaha | 08:21 |
| mvo | 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:21 |
| mborzecki | Chipaca: feel like tackling the traveling salesman problem irl? | 08:22 |
| Chipaca | mborzecki: I suck at sales | 08:22 |
| Chipaca | mborzecki: but other than that, sure :) | 08:22 |
| pedronis | mvo: well, it is explicit for that level of code, already the parsing makes all entries non empty | 08:22 |
| mvo | pedronis: ok | 08:22 |
| Chipaca | "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 |
| pedronis | mvo: that is code from the previous PR | 08:23 |
| pedronis | slot is really system:network-control at that point of the code | 08:23 |
| mvo | pedronis: aha, that was the missing piece then - I remember now | 08:24 |
| pedronis | mvo: adding the comment, I need to merge master anyway because of Name vs InstanceName | 08:24 |
| mvo | pedronis: thank you | 08:25 |
| Chipaca | zyga: in distros that don't have /snap/bin, what's added to PATH? | 08:26 |
| zyga | Chipaca: /var/lib/snapd/snap/bin | 08:26 |
| zyga | it's the same | 08:26 |
| zyga | I mean, the same script | 08:26 |
| zyga | ugly, no? | 08:26 |
| Chipaca | zyga: dunno if you're talking about #5355 but I was | 08:27 |
| mup | PR #5355: data/complete: fix three out of four shellcheck warnings in data/complete <Created by zyga> <https://github.com/snapcore/snapd/pull/5355> | 08:27 |
| zyga | ah | 08:27 |
| zyga | I'll do that | 08:27 |
| zyga | thanks, I'll push this branch in a moment | 08:27 |
| zyga | I'm moving all suse machines from drive to drive so they are suspend now | 08:28 |
| Chipaca | zyga: you have way too much fun for it to be legal | 08:32 |
| zyga | such as? | 08:33 |
| Chipaca | zyga: moving suse machines around | 08:33 |
| zyga | I can hear the disks clicking | 08:34 |
| mup | PR snapd#5351 closed: packaging/opensuse: build position-independent binaries <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5351> | 08:34 |
| Son_Goku | zyga, dammit I'm blind | 08:35 |
| zyga | oh? | 08:35 |
| Son_Goku | https://github.com/snapcore/snapd/commit/e21034320459354b8acd9d1c194946ceda363a6e#diff-36a23153f5bbd7bffd11c24597ac50fdR146 | 08:35 |
| Son_Goku | I don't know _how_ that's valid shell | 08:35 |
| Son_Goku | it should have barfed again this time | 08:35 |
| zyga | thanks! | 08:35 |
| zyga | I'll fix it... in about 10 minutes when the copy is over | 08:36 |
| Son_Goku | haha | 08:36 |
| mup | PR snapd#5363 opened: snap: introduce the instance key field <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5363> | 08:44 |
| mborzecki | pedronis: this should be fairly uncontroversial ^^ | 08:45 |
| mborzecki | gnome shell actively not taking input because it's too busy dumping backtraces from js :( | 08:51 |
| mup | PR snapd#5364 opened: packaging/opensuse: fix typo, missing assignment <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5364> | 09:02 |
| zyga | mborzecki: review on https://github.com/snapcore/snapd/pull/5363#pullrequestreview-130726810 | 09:06 |
| zyga | Pharaoh_Atem: fixed, thank you! | 09:06 |
| mup | PR #5363: snap: introduce the instance key field <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5363> | 09:06 |
| mborzecki | zyga: thanks! | 09:07 |
| mup | PR snapd#5359 closed: spread-shellcheck: use a whitelist of files that are allowed to fail validation <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5359> | 09:08 |
| mup | PR snapd#5357 closed: firstboot: mark essential snaps as "Required" in the state <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5357> | 09:10 |
| mvo | reviews for 5361 would be great, should be straightforward and unblocks some more spread runs | 09:11 |
| mvo | 5339 is also updated but that is a bit annoying to reivew (too much shell) :/ | 09:12 |
| zyga | Chipaca: one final look at https://github.com/snapcore/snapd/pull/5355/ | 09:15 |
| mup | PR #5355: data/complete: fix three out of four shellcheck warnings in data/complete <Created by zyga> <https://github.com/snapcore/snapd/pull/5355> | 09:15 |
| mvo | pedronis: a quick look my comment in 5331 would be great, if it captures enough information why we sort snapd first | 09:16 |
| pedronis | mvo: which reminds that sorting is not enough | 09:19 |
| pstolowski | mborzecki: thanks for the inisght into systemd seeded PR | 09:24 |
| pedronis | mvo: we need to tweak also the code here https://github.com/snapcore/snapd/blob/master/overlord/snapstate/snapstate.go#L806 | 09:24 |
| pedronis | to consider snapd in both sides of the if | 09:24 |
| mborzecki | pstolowski: iirc we stop all snapd* services in prepare, maybe that's why it's inactive/dead in your test | 09:25 |
| mvo | pedronis: indeed | 09:26 |
| zyga | mvo: done | 09:31 |
| mvo | zyga: thank you | 09:32 |
| zyga | mvo: conflict on https://github.com/snapcore/snapd/pull/5358 | 09:33 |
| mup | PR #5358: tests: add spread test to ensure snapd/core18 are not removable <Created by mvo5> <https://github.com/snapcore/snapd/pull/5358> | 09:33 |
| mvo | zyga: thanks, looking | 09:33 |
| mvo | mborzecki: thank you as well for the review! | 09:35 |
| mup | PR snapd#5353 closed: data/completion: fix inconsistency in +x and shebang <Squash-merge> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5353> | 09:35 |
| mup | PR snapd#5365 opened: spread-shellcheck: use the latest shellcheck available from snaps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5365> | 09:35 |
| mup | PR snapd#5317 closed: overlord: introduce a gadget-connect task and use it at first boot <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5317> | 09:44 |
| pedronis | pstolowski: hi, I merged my gadget-connect branch, that means I fear conflicts for the disconnect hooks one | 09:45 |
| pstolowski | pedronis: ack, thanks for heads up | 09:46 |
| mvo | 5361 needs a second revie wnow | 09:49 |
| mvo | (really simple :) | 09:49 |
| mup | PR core18#24 closed: Add the systemd-sysv package for tools like shutdown and reboot <Created by sil2100> <Merged by mvo5> <https://github.com/snapcore/core18/pull/24> | 09:51 |
| mvo | zyga: you asked about locales all - when I just add this package the snap grows by 12mb | 09:55 |
| zyga | yeah, sil2100 did the experiment yesterday | 09:55 |
| mvo | zyga: aha, I missed the results | 09:55 |
| zyga | I would like to consider it, for the sake of making locale not suck again | 09:55 |
| zyga | snap authors cannot really do it inside snaps, from what I know | 09:56 |
| sil2100 | I'll try looking into slimming down the core18 snap | 09:56 |
| sil2100 | Maybe then we'll feel less sad with the additional 11-12MB | 09:56 |
| sil2100 | (hello btw. o/) | 09:57 |
| mvo | sil2100: yay, please do | 09:58 |
| zyga | sil2100: is the new data _solely_ inside /usr/share/locale? | 09:58 |
| zyga | sil2100: a diff of list of files would be awesome if you have one handy | 09:58 |
| sil2100 | zyga: yes, it's just /usr/lib/locale/* | 09:59 |
| * sil2100 goes AFK now to argue with some bad people | 10:00 | |
| mvo | zyga: and its massive, du -s | sort -n shows that its a whole lot of 1-3mb files | 10:00 |
| zyga | mvo: iff 11MB is what we need to make snaps talk languages maybe that's not _so_ bad | 10:01 |
| zyga | I mean, the size is tiny in comparison to anything modern, just the download size is a problem | 10:01 |
| zyga | we should have a hello-i18n snap | 10:08 |
| zyga | that uses python and get text | 10:08 |
| zyga | or something that was problematic lately | 10:08 |
| zyga | (or actually have one set of .mo files and use many implementations to test stuff) | 10:08 |
| Son_Goku | zyga, unrelated, but... | 10:09 |
| zyga | yeah? | 10:09 |
| Son_Goku | from #fedora-devel: | 10:09 |
| Son_Goku | [05:58:33 AM] <sfix>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 |
| mvo | pstolowski: 5356 seems to be failing, I guess that is on your radar? | 10:09 |
| mvo | pstolowski: the fix for snapd.seeded | 10:09 |
| Son_Goku | zyga, my understanding is that namespaced labels are the key to making selinux confined snaps work | 10:09 |
| pstolowski | mvo: yes i'm looking at right now. it's interesting | 10:09 |
| mvo | pstolowski: (sorry for being a bit pushy here) | 10:10 |
| zyga | Son_Goku: no, I don't think that's critical | 10:10 |
| Son_Goku | no? | 10:10 |
| zyga | Son_Goku: note that apparmor and namespaced labels are not important either | 10:10 |
| zyga | just when you have multiple containers | 10:10 |
| zyga | then it is important | 10:10 |
| Son_Goku | wouldn't it be necessary for running LXD or Docker as a snap? | 10:10 |
| zyga | the most important first step on the topic of snapd and selinux is how the hell to get started :) | 10:10 |
| zyga | Son_Goku: I don't know | 10:11 |
| Son_Goku | well, mvo, lvrabec, and pmoore are in a mail convo about that | 10:11 |
| Son_Goku | though mvo has been bad about not responding to them :/ | 10:11 |
| Son_Goku | I finally bit the bullet and did yet another response that I feel was probably not terribly helpful :/ | 10:11 |
| mborzecki | zyga: iirc we've discussed overlayfs some time ago | 10:11 |
| mvo | Son_Goku: yes - sorry for that | 10:12 |
| Son_Goku | zyga, the SELinux warnings and denials have reached the point that the Red Hat SELinux guys would like to help us | 10:12 |
| Son_Goku | but I can't do anything to make this better, because I'm too incompetent to figure out how the security model works | 10:12 |
| Son_Goku | and I'm stretched really thinly right now | 10:13 |
| zyga | Son_Goku: oh, interesting, | 10:14 |
| zyga | Son_Goku: do you have any names I could ping? | 10:14 |
| Son_Goku | mvo has them | 10:14 |
| zyga | cool, I didn't know about this | 10:14 |
| Son_Goku | mvo, please reply to them with some useful info and CC zyga | 10:14 |
| zyga | eventually we could patch our test suite so that no _new_ warnings are introduced | 10:14 |
| Son_Goku | zyga, are you not following selinux@ and devel@ on lists.fp.o? | 10:14 |
| zyga | Son_Goku: I'm subscribed but man, I'm not following my inbox much | 10:15 |
| zyga | too many things lately | 10:15 |
| Son_Goku | zyga: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org/thread/U6JJ3IIJNNGGDZECSIMZC5UODAECCWPT/ | 10:16 |
| zyga | mborzecki, mvo: what about instance installation of snapd? | 10:30 |
| mborzecki | zyga: what do you mean? | 10:30 |
| zyga | can we snap install snapd_foo | 10:30 |
| zyga | and if so, what shall that mean? | 10:30 |
| mborzecki | no, it will be blocked | 10:30 |
| mborzecki | kernel, gadget, core & snapd snaps are non parallel installable | 10:31 |
| mborzecki | s/core/os/ | 10:31 |
| Chipaca | mborzecki: but you can parallel-install base snaps? | 10:32 |
| mborzecki | i suppose not, don't think that would be useful | 10:35 |
| Chipaca | mborzecki: maybe just clamp it to apps and "" | 10:37 |
| Son_Goku | I think you're inviting trouble with instance installs of snaps | 10:37 |
| Son_Goku | what problem are you trying to solve here? | 10:38 |
| Chipaca | Son_Goku: it's our 3rd most requested feature afaik | 10:39 |
| Chipaca | Son_Goku: after world peas and universal healthcare | 10:39 |
| Son_Goku | I don't know if we should make "world peas" | 10:39 |
| Son_Goku | :) | 10:39 |
| Chipaca | :D | 10:40 |
| Chipaca | Son_Goku: split pea and ham soup tho | 10:40 |
| Son_Goku | haha | 10:40 |
| Chipaca | or just split pea soup | 10:40 |
| mborzecki | mvo: what was the failure with parsing losetup output? | 10:42 |
| zyga | ohh | 10:42 |
| zyga | mvo: fun issue | 10:42 |
| zyga | https://www.irccloud.com/pastebin/ACep9bL8/ | 10:42 |
| zyga | base policy needs love now | 10:42 |
| zyga | mvo: to fix this it would be _really_ nice to have slot-snap-type: snapd | 10:46 |
| zyga | that is, a dedicated type for snapd snap | 10:47 |
| zyga | WDYT? | 10:47 |
| zyga | pedronis: ^ | 10:47 |
| Son_Goku | zyga, can I not have a snapd snap installed? | 10:47 |
| Son_Goku | it's going to be dead code on my system | 10:47 |
| zyga | Son_Goku: no, it's mandatory because otherwise the code would be even more hairy | 10:47 |
| zyga | and it's not dead code entirely, as it interacts with snap-exec and snapctl at runtime | 10:48 |
| zyga | (they are taken from the snapd snap) | 10:48 |
| Son_Goku | but using the snapd you guys build breaks things :/ | 10:48 |
| Son_Goku | that's why we have to disable re-exec for every distro except Ubuntu | 10:48 |
| mvo | mborzecki: it will give me /dev/loop4 but I need /dev/mapper/loop4p3 | 10:48 |
| zyga | we won't use snapd but we will use other files from the snapd.snap | 10:48 |
| Son_Goku | does that mean that patches against those binaries on the host are basically ineffective, then? | 10:49 |
| zyga | they are today | 10:49 |
| Son_Goku | :/ | 10:49 |
| zyga | there's a lot of non-trivial stuff involved | 10:49 |
| zyga | and edge cases that are easy to miss | 10:49 |
| pedronis | 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 |
| mvo | 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 |
| zyga | pedronis: it's that or patching the policy checker to imply that snap name "snapd" has magic type "core" | 10:50 |
| pedronis | zyga: well, we cannot use the name | 10:51 |
| zyga | ? | 10:51 |
| pedronis | we really need to use the snap id at that level | 10:51 |
| zyga | woah, so what can we use? | 10:51 |
| zyga | that won't fly | 10:51 |
| mborzecki | 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 |
| zyga | store changes and all that | 10:51 |
| zyga | I mean, staging vs prod | 10:51 |
| zyga | I really like the simplicity of snap type | 10:51 |
| zyga | if name is a no-go then we need to discuss how this ought to work | 10:51 |
| pedronis | snap type needs store changes too | 10:52 |
| pedronis | and review-tools changes | 10:52 |
| zyga | when I said store changes I meant snapd talking to prod store or staging store | 10:52 |
| zyga | I agree that a new type needs store side changes | 10:52 |
| pedronis | I know | 10:52 |
| zyga | hmm | 10:52 |
| zyga | mvo: ^ this blocks further work for now unless there's some magic way I can patch the policy for now | 10:52 |
| zyga | virtual system snap was not blocked this way because it was never installed and thus never verified | 10:53 |
| mvo | zyga: hm, hm, ok, lets discuss in the standup, but that is unfortunate. I'm not familiar enough with the details yet so I'm not sure what to do. I guess we can't simply add an exception at this point? | 10:56 |
| mvo | zyga: special case I mean | 10:56 |
| zyga | not sure where | 10:56 |
| pedronis | we can cheat for a bit, but to be honest even the old system with type was a bit fragile | 10:56 |
| zyga | my plan was to simply allow snap name "snapd" | 10:56 |
| pedronis | the fact you can have different things installed | 10:56 |
| pedronis | in different cases | 10:56 |
| pedronis | doesn't make it better | 10:56 |
| zyga | mvo: I can add the snapd id of "snapd" to all the built-in interfaces for now | 10:57 |
| zyga | but that's ugh | 10:57 |
| pedronis | don't think we want to change the policies | 10:57 |
| pedronis | themselves | 10:57 |
| mvo | zyga: yeah, that sounds not nice(tm) | 10:58 |
| zyga | pedronis: do you mean the built-in policy? | 10:58 |
| pedronis | I mean whatever we do | 10:58 |
| pedronis | I don't think we want to change the snippets | 10:58 |
| pedronis | (too annoying) | 10:58 |
| zyga | pedronis: so what would you change? | 10:58 |
| mborzecki | zyga: where was that check for partial apparmor support on tumbleweed? | 10:59 |
| pedronis | zyga: we have lots of options | 10:59 |
| zyga | mborzecki: interfaces/apparmor/backend.go | 10:59 |
| zyga | pedronis: like? | 10:59 |
| mborzecki | zyga: got it, thanks! | 11:00 |
| pedronis | zyga: we can some change in policy/helpers.go | 11:03 |
| zyga | right, I was asking for the idea what to look for; my initial instinct was to just look at snap name but I think you said that would be invalid (since we cannot trust it) | 11:03 |
| zyga | one more idea is to perhaps tag implicit interfaces somehow | 11:04 |
| zyga | and skip validation | 11:04 |
| pedronis | zyga: you can use the relevant snap ids in the place we check for type | 11:04 |
| pedronis | will create problems for tests tough | 11:05 |
| zyga | so would that be hard-coding the well-known ID of snapd in the policy? | 11:05 |
| pedronis | zyga: not in the policy | 11:05 |
| pedronis | in the policy code | 11:05 |
| zyga | right | 11:05 |
| zyga | that's what I meant (policy/) | 11:05 |
| pedronis | for a bit at least | 11:05 |
| pedronis | we might in the end need a type | 11:05 |
| pedronis | then we just translate that type to core | 11:05 |
| pedronis | or the other way | 11:06 |
| pedronis | around | 11:06 |
| pedronis | or something | 11:06 |
| zyga | hmmm | 11:06 |
| zyga | I think we ought to either introduce snapd type or track and ignore implicit interfaces explicitly | 11:06 |
| pedronis | ingnore based on what? | 11:06 |
| pedronis | the name? | 11:06 |
| zyga | no no | 11:06 |
| zyga | if slotInfo.Implicit == true | 11:06 |
| zyga | just set Implicit on the interfaces we create | 11:06 |
| pedronis | ignore in the sense that any snap can get them? | 11:06 |
| zyga | (a new attribute) | 11:07 |
| pedronis | there is something fishy in this concept of ignore | 11:07 |
| zyga | and by ignore I mean skip the checks for _those_ interfaces | 11:07 |
| pedronis | that means any snap can get their slot | 11:07 |
| zyga | well, it's just formality, we add them, | 11:07 |
| zyga | no | 11:07 |
| pedronis | that doesn't make any sense | 11:07 |
| zyga | it's not an attribute | 11:07 |
| zyga | it's something only snapd could set | 11:07 |
| pedronis | yes, but if it's in the interface | 11:07 |
| pedronis | what prevent a random snap | 11:07 |
| pedronis | to declare the slot? | 11:07 |
| zyga | I mean in SlotInfo | 11:07 |
| zyga | not in Interface | 11:08 |
| pedronis | based on what again? | 11:08 |
| pedronis | the snap name | 11:08 |
| pedronis | we attach them based on name | 11:08 |
| pedronis | the checks right now though are on type | 11:08 |
| zyga | well, today we _add_ the implicit interfaces based on snapInfo.Name() == "snapd" | 11:08 |
| zyga | if we disagree about that we need to take a step back and fix that | 11:08 |
| pedronis | but it doesn't work | 11:08 |
| pedronis | because there are checks | 11:08 |
| zyga | once we agree there it's trivial to add mark the interfaces as implicit | 11:08 |
| pedronis | I disagree | 11:09 |
| pedronis | I think we need a little more than a name | 11:09 |
| zyga | why do you think so? | 11:09 |
| zyga | because of side-loading? | 11:09 |
| pedronis | no not sideloading | 11:09 |
| pedronis | because it gets very messy | 11:09 |
| pedronis | in the old world there was core snap and only one | 11:10 |
| pedronis | and it was hard not to have it | 11:11 |
| pedronis | now we are allowing various combinations | 11:11 |
| zyga | in the old world _any_ snap with type="core" would get the implicit interfaces | 11:11 |
| zyga | now I'm doing what we discussed yesterday | 11:11 |
| zyga | if we have snapd snap installed it gets the implicit interfaces, otherwise we do as before (any type="core" does) | 11:11 |
| pstolowski | i feel that what you're discussing is interesting for hotplug too, although i haven't followed all details... i'm currently adding hotplug slots to "core" | 11:13 |
| mvo | mborzecki: your comments on 5339 are not a +1 yet, right? it looks like it still needs a second review | 11:13 |
| zyga | pstolowski: yes, I asked this question yesterday on the standup but didn't realise you left by then | 11:13 |
| pstolowski | zyga: ah. ok. | 11:13 |
| zyga | hmmmm | 11:25 |
| zyga | one more twist | 11:25 |
| zyga | snap.Info.UseNick("core") returns "system" | 11:26 |
| zyga | and DropNick has the reverse logic | 11:26 |
| zyga | this is very annoying TBH | 11:26 |
| zyga | because it is stateless | 11:26 |
| zyga | mvo: ^ | 11:27 |
| zyga | so at the API level it's not any different | 11:27 |
| zyga | but "snap interface network" shows "system" as the slot | 11:27 |
| pedronis | zyga: that is what I was mentioning the other day, it was a bit unclear that we wouldn't need reverse translation in the repo, or extra code in the api | 11:28 |
| zyga | I think that since we tell the user "system" all the time that we should have used system as a snap, it's just cleaner | 11:28 |
| pedronis | zyga: anyway the change I have in mind in policy is not that big, also we never invoke policy code for snaps that don't have snap id | 11:30 |
| pedronis | (we assume dangerous) | 11:30 |
| zyga | that's a good point | 11:30 |
| zyga | pedronis: I didn't get your response on the previous question, how shall we identify snapd-the-snap in general | 11:30 |
| zyga | to add interfaces to it | 11:30 |
| zyga | if the name check is wrong what is the right check | 11:30 |
| pedronis | in policy, with the snap ids | 11:31 |
| pedronis | but we can hide that mostly in a helper | 11:31 |
| zyga | not in the policy | 11:31 |
| zyga | in the interface manager | 11:31 |
| zyga | since that's where it starts | 11:31 |
| pedronis | name is fine, given that it will be blocked by policy | 11:32 |
| pedronis | if it's not installed with dangerous | 11:32 |
| zyga | mmm, ok | 11:32 |
| Chipaca | I'm off to have lunch, and then I've got a meeting at the boys' school | 11:33 |
| Chipaca | I don't think I'll make it to the standup | 11:33 |
| Chipaca | let me know if I said "yes" to anything in my absence :-D | 11:33 |
| zyga | Chipaca: we'll tell you what you have volunteered to do tomorrow ;-) | 11:34 |
| pedronis | zyga: let me try to propose a diff of what I have in mind | 11:34 |
| zyga | pedronis: thanks, I'm looking at that code but if you have something that's super nice :) | 11:34 |
| pstolowski | Chipaca: we will assume "yes" to everything you don't explicitely nack | 11:35 |
| zyga | mvo: can you please merge https://github.com/snapcore/snapd/pull/5364 | 11:39 |
| mup | PR #5364: packaging/opensuse: fix typo, missing assignment <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5364> | 11:39 |
| zyga | it failed twice on random junk | 11:39 |
| === pstolowski is now known as pstolowski|lunch | ||
| pedronis | zyga: something like this is what I had in mind https://pastebin.ubuntu.com/p/KbsqbVN9by/ of course needs a couple of tests in policy_test.go to go with it | 11:42 |
| zyga | mmm, thanks, let's see where I can take this | 11:42 |
| mborzecki | heh, pushed to the wrong PR branch, quick reset & force push, maybe nobody will notice :) | 11:44 |
| mup | PR snapd#5366 opened: snap: helper for validating snap instance names <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5366> | 11:47 |
| mborzecki | mvo: shall we land #5362 ? | 11:54 |
| mup | PR #5362: tests: use "ss" instead of "netstat" (netstat is not available in core18) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5362> | 11:54 |
| zyga | mvo: what's the id of snapd snap in staging? | 11:58 |
| zyga | hmm, we don't restart snapd.service when installing snapd.snap yet, do we? | 12:01 |
| jamesh | zyga: I ran into this weird spread test failure in my PR: https://api.travis-ci.org/v3/job/394938067/log.txt -- I think it is down to incomplete cleanup in tests/main/xdg-open (it touches a file and then Arch's package manager refuses to overwrite it when I try to install a package) | 12:02 |
| zyga | mvo: with pedronis' patch I can install snapd and (since it doesn't restart) we get duplicated interfaces | 12:03 |
| zyga | after snapd restart things are ok | 12:03 |
| jamesh | so I wonder if that test is using a bit of an anti-pattern | 12:04 |
| zyga | jamesh: looking | 12:05 |
| zyga | hmmm | 12:07 |
| zyga | I'm puzzled | 12:07 |
| zyga | what's the xdg-open in the filesystem that this conflicts with? | 12:08 |
| jamesh | zyga: in tests/main/xdg-open, it touches /usr/bin/xdg-open and then bind mounts a fake version of the script over the top, and then undoes the bind mount in the restore script | 12:09 |
| zyga | ah | 12:09 |
| jamesh | presumably this is intended to make the test work on systems with or without xdg-open installed before hand | 12:09 |
| pedronis | zyga: I think we do have code to restarted but only if the model has a base | 12:09 |
| mborzecki | pacman refuses to overwrite files | 12:09 |
| zyga | IMO the main/xdg-open test must clean up after itself | 12:10 |
| zyga | instead of touching it could mv to .orig or something | 12:10 |
| mborzecki | zyga: it supposedly does | 12:10 |
| jamesh | but it means it leaves an empty file around if xdg-open wasn't around before hand | 12:10 |
| zyga | mborzecki: does it? | 12:10 |
| mborzecki | but does not remove the file if it wasn't there | 12:10 |
| zyga | mborzecki: I'm looking at the restore section | 12:10 |
| zyga | yes | 12:10 |
| zyga | exactly | 12:10 |
| === alan_g is now known as alan_g|afk | ||
| zyga | so to properly clean up it should unlink /usr/bin/xdg-open | 12:11 |
| mborzecki | i can do a quick fix | 12:11 |
| zyga | and if /usr/bin/xdg-open.orig exists mv it over | 12:11 |
| jamesh | alternatively, it could install xdg-utils to ensure a real xdg-open is available to bind mount over | 12:11 |
| zyga | this is safe regardless of whether xdg-open existed or not | 12:11 |
| mup | PR snapd#5339 closed: tests: initial core18 spread image building <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5339> | 12:13 |
| zyga | mvo: ping | 12:14 |
| mvo | zyga: pong | 12:16 |
| zyga | mvo: can you shed some light on the expected behaviour of snapd the process when one "snap install snapd" | 12:16 |
| zyga | should snapd restart? | 12:16 |
| mup | PR snapd#5364 closed: packaging/opensuse: fix typo, missing assignment <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5364> | 12:17 |
| mvo | zyga: a great question. I think today on !core18 it should do nothing but on core18 it should restart | 12:18 |
| mvo | zyga: iirc it will do that already (restart in core18) | 12:18 |
| mvo | mborzecki: re 5363 (ss instead of netstat) - if it looks good lets land it. it evolved a bit since your first review, sorry for that, the output is slightly different so I had to tweak a bunch of greps | 12:19 |
| mup | PR snapd#5355 closed: data/complete: fix three out of four shellcheck warnings in data/complete <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5355> | 12:19 |
| zyga | mvo: mmmmm | 12:21 |
| zyga | mvo: thank you | 12:21 |
| zyga | mvo: so | 12:21 |
| zyga | well, actually, so installing snapd.snap on classic | 12:21 |
| zyga | what does that do? | 12:22 |
| zyga | s/do/should do | 12:22 |
| zyga | in the world without core | 12:22 |
| mvo | zyga: in a future world it will restart into snapd | 12:22 |
| mvo | zyga: into the snapd snap | 12:22 |
| zyga | future as in far into the future | 12:22 |
| mvo | zyga: but we are not there yet | 12:22 |
| zyga | or soon (week) | 12:22 |
| mvo | zyga: ~4-6 weeks | 12:22 |
| zyga | k | 12:22 |
| mborzecki | jamesh: opening a PR in a minute | 12:22 |
| zyga | so then we need to discuss what to do about implicit interfaces again | 12:23 |
| zyga | should the new logic only apply if model.Base is core18? | 12:23 |
| zyga | and otherwise things are as they are now | 12:23 |
| mvo | zyga: I think for now we focus on model.Base != "" | 12:23 |
| zyga | I think with _that_ extra logic (and noting that no new tests are present) I could propose my branch to see what happens | 12:23 |
| mvo | zyga: but eventually we will be in a new world with core16 and no snapd in there on classic | 12:23 |
| zyga | ok, I'll do that | 12:23 |
| zyga | thanks | 12:23 |
| mvo | zyga: and a snapd snap on classic that will have the role of core | 12:24 |
| mvo | zyga: *but* one step at a time :) | 12:24 |
| zyga | hhmmm | 12:24 |
| zyga | hold on | 12:24 |
| zyga | actually, let me have lunch | 12:25 |
| mborzecki | wow, econnreset | 12:26 |
| mborzecki | https://api.travis-ci.org/v3/job/394933199/log.txt | 12:26 |
| pstolowski|lunch | 2018/06/21 12:14:46.074136 store.go:1555: DEBUG: Download succeeded in 4.935s (109MB/s) | 12:29 |
| === pstolowski|lunch is now known as pstolowski | ||
| mup | PR snapd#5367 opened: tests/main/xdg-open: restore or clean up xdg-open <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5367> | 12:31 |
| mborzecki | jamesh: zyga: ^^ | 12:31 |
| mborzecki | pstolowski: nice, that's fast :) | 12:31 |
| pstolowski | i guess iptables rule is not immediately effective (as suspected by mvo) | 12:33 |
| abeato | mvo, I'm getting some snapd errors related to not having GNU build ID in the binary, how can I add that to the binary? | 12:34 |
| mvo | abeato: those should just be warnings | 12:36 |
| mvo | abeato: did you see my comment in the PR? was that helpful? I also wanted to write a small spread test but I didn't had time yet, I think it would be a nice addition | 12:37 |
| abeato | mvo, hm, does not this have side effects?: https://paste.ubuntu.com/p/sdkwXp3nV4/ | 12:37 |
| abeato | mvo, yes, thanks for that, I have cherry-picked your commit and added it to the branch | 12:38 |
| mvo | abeato: those warnings are ok, it just means you get an unneeded profile-generation. maybe we need to phrase them differently so that they sound less scary | 12:38 |
| abeato | mvo, ok, was just wondering | 12:39 |
| abeato | thx | 12:39 |
| zyga | mvo: do you have some time to hop on the standup HO now and talk about core18? | 12:43 |
| mvo | zyga: yes, one minute, just finishing a small PR | 12:44 |
| zyga | ok | 12:44 |
| zyga | mvo: hmm, | 12:48 |
| zyga | hangouts/meet don't want to let me in | 12:48 |
| mup | PR snapd#5368 opened: tests: disable core tests on all core systems (16 and 18) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5368> | 12:48 |
| zyga | mvo: ok, managed to join via regular hangouts | 12:50 |
| mborzecki | pstolowski: ok if i restart that build with econnreset? | 12:50 |
| pstolowski | mborzecki: yep, i made a copy | 12:51 |
| mborzecki | ack | 12:51 |
| pstolowski | thanks | 12:51 |
| mborzecki | pstolowski: download is run by the client only right? snapd is not proxying anything there? | 12:52 |
| pstolowski | mborzecki: correct | 12:52 |
| pstolowski | mborzecki: (in this particula case, e.g. on 'snap download ..') | 12:53 |
| mborzecki | right | 12:53 |
| mvo | zyga: look at your video ;) | 12:53 |
| mup | PR snapd#5362 closed: tests: use "ss" instead of "netstat" (netstat is not available in core18) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5362> | 12:56 |
| === alan_g|afk is now known as alan_g | ||
| mup | PR snapd#5365 closed: spread-shellcheck: use the latest shellcheck available from snaps <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5365> | 13:47 |
| mup | PR snapd#5369 opened: overlord,interfaces,cmd: WIP early support for interfaces on core18 <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5369> | 13:53 |
| zyga | I need to break now and take the dog out | 13:53 |
| mvo | zyga: thank you! | 13:53 |
| zyga | mborzecki: I will resume suse work when I'm back, looking forward to your testing :) | 13:53 |
| mvo | zyga: anything you need in 2.33.1 for suse? | 14:03 |
| zyga | Hmmm, yes but i am afk | 14:05 |
| zyga | 32C now, ufff | 14:05 |
| mborzecki | zyga: at least you know that it's almost summer :) | 14:22 |
| mup | PR snapd#5370 opened: overlord/{config,snap}state: introduce parallel-installs feature flag <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5370> | 14:22 |
| mup | PR snapd#5371 opened: tests/main/interfaces-firewall-control: shellcheck fix <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5371> | 14:27 |
| mborzecki | mvo: ^^ | 14:27 |
| mvo | mborzecki: \o/ thank you | 14:40 |
| mup | PR snapd#5356 closed: packaging: require snapd.socket in snapd.seeded.service; make sure snapd.seeded.… <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5356> | 14:48 |
| mup | PR snapd#5372 opened: many: improve udev trigger on refresh experience (2.33) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5372> | 14:54 |
| mup | PR snapd#5372 closed: many: improve udev trigger on refresh experience (2.33) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5372> | 15:33 |
| zyga | re | 15:38 |
| * zyga tried to read a paper but ended up talking to mvo and then to family members | 15:38 | |
| zyga | anyway, back now | 15:38 |
| zyga | mvo: hey | 15:42 |
| zyga | did you look at the RFC PR yet? | 15:42 |
| zyga | it fails on core 18 with | 15:42 |
| zyga | + snap install --channel=edge snapd | 15:42 |
| zyga | error: cannot install "snapd": cannot install snapd snap on a model without a base snap yet | 15:42 |
| zyga | did I mess up or is the core18 somehow ending up without a model yt | 15:42 |
| zyga | *yet | 15:42 |
| zyga | in any case, please look at the branch, it's very small so far | 15:43 |
| zyga | I will focus on suse release for the rest of the day | 15:43 |
| mup | PR snapd#5373 opened: release: 2.33.1 <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5373> | 15:47 |
| zyga | pstolowski: https://github.com/snapcore/snapd/pull/5368 needs a 2nd review | 15:52 |
| mup | PR #5368: tests: disable core tests on all core systems (16 and 18) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5368> | 15:52 |
| pstolowski | looking | 15:53 |
| pstolowski | +1 | 15:56 |
| mup | PR snapd#5331 closed: snapstate: sort "snapd" first <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5331> | 15:56 |
| pedronis | as I remarked to mvo this morning 5331 is not sufficient to solve the related problems | 16:12 |
| zyga | pedronis: shall I revert it? | 16:18 |
| pedronis | it's not harmful by itself | 16:18 |
| pedronis | but I would like to understand if the other problem is being tracked | 16:18 |
| === pstolowski is now known as pstolowski|afk | ||
| sergiusens | mvo: pedronis is there any reason for why the actual snap file on /var/lib/snapd/snaps would be 600 when installed with --dangerous but 644 otherwise? | 16:27 |
| pedronis | I don't think is --dangerous | 16:30 |
| pedronis | is local vs from from store | 16:30 |
| pedronis | the involved files are created differently | 16:31 |
| pedronis | I see the 0644 | 16:31 |
| pedronis | the 0600 (for local installs) comes from ioutil.TempFile | 16:33 |
| niemeyer | pstolowski|afk: #5326 reviewed | 16:55 |
| mup | PR #5326: api/snapctl: allow -h and --help for regular users <Created by stolowski> <https://github.com/snapcore/snapd/pull/5326> | 16:55 |
| mvo | cachio: 2.33.1 is in the beta channel now - just fyi - mostly small fixes and test tweaks for autopkgtest | 17:01 |
| cachio | mvo, nice, I'll make a run today | 17:01 |
| mborzecki | wow, opensuse really hates my nvidia, the graphical installer refuses to start, textual yast wants to do something (besides being super inconvenient to use) but i doubt that matches what i want it to do, wish i could just mount the target fs and bootstrap everything by hand, probably possible just havent found the way yet | 17:08 |
| zyga | mvo: offtopic, did you know about git cherry-pick -m 1 ... | 17:10 |
| zyga | it's very useful, I found it by accident | 17:10 |
| zyga | pick a merge commit sha and cherry pick the whole lot | 17:10 |
| zyga | mborzecki: which release are you on? | 17:10 |
| zyga | mborzecki: try tumbleweed if you can, it's the most interesting to test for me | 17:11 |
| mborzecki | tw, pulled today's current | 17:11 |
| zyga | good | 17:11 |
| zyga | (and bad, sorry about your card) | 17:11 |
| mborzecki | i'm quite sure that vesa works, just no clue why it's not even tried | 17:11 |
| mvo | zyga: oh, neato, I was not aware of this | 17:15 |
| zyga | storm is coming! | 17:16 |
| zyga | 32C is falling quickly and it's all dark now | 17:17 |
| mborzecki | zyga: 16C here | 17:17 |
| zyga | !!! | 17:17 |
| zyga | how can it be twice as cold there as it was here a moment ago | 17:17 |
| zyga | it's barely an hour away | 17:17 |
| mup | PR snapd#5374 opened: tests: disable core tests on all core systems (16 and 18) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5374> | 17:18 |
| mup | PR snapd#5371 closed: tests/main/interfaces-firewall-control: shellcheck fix <Simple> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5371> | 17:25 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/5370 | 17:26 |
| mup | PR #5370: overlord/{config,snap}state: introduce parallel-installs feature flag <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5370> | 17:26 |
| mborzecki | zyga: hm? | 17:27 |
| zyga | look at my comment please | 17:27 |
| mup | PR snapd#5367 closed: tests/main/xdg-open: restore or clean up xdg-open <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5367> | 17:27 |
| mup | PR snapd#5368 closed: tests: disable core tests on all core systems (16 and 18) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5368> | 17:28 |
| mborzecki | zyga: restarted the build, it's alreayd fixed in master | 17:29 |
| zyga | Thank you! | 17:29 |
| zyga | mvo: the 2.33.1 PR fails for the same reason | 17:29 |
| zyga | + something that looks like journalctl skew | 17:29 |
| mborzecki | zyga: that test log is a bit misleading, the most interesting part is just the last few lines which gives a summary of what failed and why (expectedly/unexpectedly and so on) | 17:30 |
| zyga | aha | 17:37 |
| * Chipaca EODs and goes to find a place with a tv | 17:49 | |
| Chipaca | o/ | 17:49 |
| zyga | uh-oh | 17:50 |
| zyga | fire nearby | 17:50 |
| zyga | I see lots of smoke and hear the sirens | 17:50 |
| zyga | I have a love-hate relationship with "orc" | 18:01 |
| zyga | "osc" | 18:01 |
| zyga | it sucks as a VCS | 18:01 |
| zyga | but it really rocks as a builder | 18:01 |
| zyga | it's way too big (CLI is insanely complex) | 18:01 |
| zyga | but the build part is really flawless | 18:01 |
| zyga | smoke intensifies | 18:07 |
| zyga | I'll go to check it out | 18:08 |
| zyga | an old house is on fire | 18:12 |
| zyga | and a 2nd building now, a block of flats next to it, still under construction | 18:14 |
| zyga | I need to add three directory ownership lines to snapd.spec on opensuse | 18:16 |
| zyga | %dir /usr/lib/systemd/system-generators | 18:16 |
| zyga | %dir /usr/share/dbus-1 | 18:16 |
| zyga | %dir /usr/share/dbus-1/services | 18:16 |
| zyga | Pharaoh_Atem: ^ | 18:16 |
| zyga | first question, should I own them (build fails on leap without it, works on tumbleweed without them) | 18:16 |
| zyga | and second question, what's the abbreviated name for those (with variables and such) | 18:16 |
| zyga | mborzecki: ^ | 18:17 |
| zyga | more fire | 18:21 |
| zyga | and more sirens nearby | 18:21 |
| zyga | https://www.facebook.com/photo.php?fbid=1939797056064540&set=gm.10160553222185322&type=3&theater | 18:24 |
| zyga | mborzecki: I have this interesting output from the build service: | 18:26 |
| zyga | [ 132s] /usr/lib/snapd/snap-mgmt: line 25: systemd-escape: command not found | 18:26 |
| zyga | we have Requires: systemd | 18:26 |
| zyga | I wonder what else might be missing | 18:26 |
| mvo | zyga: yeah, the failure of the changelog PR is strange | 18:28 |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| zyga | I see this failure often while building the package | 18:32 |
| zyga | panic in snap state tests https://www.irccloud.com/pastebin/zP4C8oCp/ | 18:32 |
| mvo | is it just me or is travis very slow? | 18:38 |
| mvo | I mean, giving me data for the test results | 18:38 |
| zyga | mvo: it's unusably slow | 18:46 |
| zyga | the page is so js-heavy it renders very very slowly | 18:46 |
| zyga | I always click on the button to show raw log but even getting there is painful | 18:46 |
| zyga | mborzecki: do you have suse ready? | 18:46 |
| zyga | I sent my build to https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd | 18:47 |
| zyga | I will break now | 18:49 |
| zyga | after this builds I will test it on my machines | 18:49 |
| zyga | and update the forum | 18:49 |
| zyga | I still have a small diff to send | 18:49 |
| zyga | (to master) | 18:49 |
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| Pharaoh_Atem | zyga: %{_systemdgeneratordir} | 19:00 |
| Pharaoh_Atem | zyga: %{_datadir}/dbus-1/services | 19:01 |
| zyga | it would be awesome if some python script could do that | 19:03 |
| zyga | thank you! | 19:03 |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| zyga | Pharaoh_Atem: let me know if you need any testing on Fedora | 20:56 |
| Pharaoh_Atem | zyga: will do | 21:47 |
| Pharaoh_Atem | I'm planning on updating Fedora to 2.33.1 | 21:47 |
| Pharaoh_Atem | I'm trying to coordinate updating xdg-desktop-portal to 0.11 there too, though | 21:48 |
| zyga | Pharaoh_Atem: re | 22:59 |
| zyga | Pharaoh_Atem: do you have any idea what failed on https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd | 22:59 |
| zyga | the tumbleweed builds failed | 22:59 |
| zyga | they enable apparmor | 22:59 |
| zyga | I don't quite get it what happens at build time, is the build machinery somehow _executing_ scripts? (%post, etc) | 22:59 |
| zyga | ah | 23:22 |
| zyga | fixed it :) | 23:22 |
| zyga | sheesh | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!