[05:01] <mborzecki> morning
[05:06] <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:54] <zyga> good morning
[05:54] <zyga> I will be here shortly
[05:58] <mborzecki> zyga: hey
[06:12] <zyga> hey, just getting a coffee
[06:22] <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:30] <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:38] <zyga> hey sil2100
[06:50] <zyga> mborzecki: can you have a quick look at https://github.com/snapcore/snapd/pull/5355
[06:51] <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>
[07:07] <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:12] <mborzecki> once this lands i have another pr that uses shellcheck from snap, although in --devmode because of our setup
[07:14] <zyga> I can :)
[07:14] <zyga> I restarted various failed PRs from yesterday
[07:16] <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:17] <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:18] <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:19] <zyga> hey pawel
[07:20] <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:21] <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:22] <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:23] <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:24] <pedronis> ok, that's different from what mborzecki proposed
[07:24] <pedronis> though
[07:25] <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:26] <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:27] <pedronis> in most uses of client should be immaterial either way
[07:27] <pedronis> s/to/two/
[07:27]  * mvo nods
[07:29] <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:30] <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:31] <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:32] <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:33] <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:35] <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:36] <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:37] <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:38] <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:39] <mborzecki> we can discuss it over a glass of beer while in BRU :)
[07:47] <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:48] <mvo> pedronis: nice!
[07:49] <pedronis> mvo: as I said, the problem is that we don't have a place to stick it in our own API errors
[07:50] <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:51] <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:52] <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:53] <mvo> pedronis: what approach do you like best :)?
[07:54] <pedronis> none :)
[07:54] <mvo> heh
[07:54]  * mvo scratches head then
[07:55] <mvo> pedronis: sounds like something to talk about during the standup to figure out the least disliked option
[07:55] <pedronis> yes
[07:58] <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>
[08:09] <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:10] <Chipaca> zyga: good morning. Chinese is not a language.
[08:11] <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:12] <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:14] <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:15] <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:16] <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:17] <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:18] <Chipaca> all the squashfs stuff, the mount crashes fixes
[08:18] <Chipaca> dunno how to test for the latter
[08:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <mvo> pedronis: thank you
[08:26] <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:27] <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:28] <zyga> I'm moving all suse machines from drive to drive so they are suspend now
[08:32] <Chipaca> zyga: you have way too much fun for it to be legal
[08:33] <zyga> such as?
[08:33] <Chipaca> zyga: moving suse machines around
[08:34] <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:35] <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:36] <zyga> I'll fix it... in about 10 minutes when the copy is over
[08:36] <Son_Goku> haha
[08:44] <mup> PR snapd#5363 opened: snap: introduce the instance key field <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5363>
[08:45] <mborzecki> pedronis: this should be fairly uncontroversial ^^
[08:51] <mborzecki> gnome shell actively not taking input because it's too busy dumping backtraces from js :(
[09:02] <mup> PR snapd#5364 opened: packaging/opensuse: fix typo, missing assignment <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5364>
[09:06] <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:07] <mborzecki> zyga: thanks!
[09:08] <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:10] <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:11] <mvo> reviews for 5361 would be great, should be straightforward and unblocks some more spread runs
[09:12] <mvo> 5339 is also updated but that is a bit annoying to reivew (too much shell) :/
[09:15] <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:16] <mvo> pedronis: a quick look my comment in 5331 would be great, if it captures enough information why we sort snapd first
[09:19] <pedronis> mvo: which reminds that sorting is not enough
[09:24] <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:25] <mborzecki> pstolowski: iirc we stop all snapd* services in prepare, maybe that's why it's inactive/dead in your test
[09:26] <mvo> pedronis: indeed
[09:31] <zyga> mvo: done
[09:32] <mvo> zyga: thank you
[09:33] <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:35] <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:44] <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:45] <pedronis> pstolowski: hi, I merged my gadget-connect branch, that means I fear conflicts for the disconnect hooks one
[09:46] <pstolowski> pedronis: ack, thanks for heads up
[09:49] <mvo> 5361 needs a second revie wnow
[09:49] <mvo> (really simple :)
[09:51] <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:55] <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:56] <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:57] <sil2100> (hello btw. o/)
[09:58] <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:59] <sil2100> zyga: yes, it's just /usr/lib/locale/*
[10:00]  * 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:01] <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:08] <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:09] <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:10] <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:11] <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:12] <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:13] <Son_Goku> and I'm stretched really thinly right now
[10:14] <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:15] <zyga> Son_Goku: I'm subscribed but man, I'm not following my inbox much
[10:15] <zyga> too many things lately
[10:16] <Son_Goku> zyga: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org/thread/U6JJ3IIJNNGGDZECSIMZC5UODAECCWPT/
[10:30] <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:31] <mborzecki> kernel, gadget, core & snapd snaps are non parallel installable
[10:31] <mborzecki> s/core/os/
[10:32] <Chipaca> mborzecki: but you can parallel-install base snaps?
[10:35] <mborzecki> i suppose not, don't think that would be useful
[10:37] <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:38] <Son_Goku> what problem are you trying to solve here?
[10:39] <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:40] <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:42] <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:46] <zyga> mvo: to fix this it would be _really_ nice to have slot-snap-type: snapd
[10:47] <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:48] <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:49] <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:50] <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:51] <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:52] <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:53] <zyga> virtual system snap was not blocked this way because it was never installed and thus never verified
[10:56] <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:57] <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:58] <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:59] <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?
[11:00] <mborzecki> zyga: got it, thanks!
[11:03] <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:04] <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:05] <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:06] <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:07] <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:08] <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:09] <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:10] <pedronis> in the old world there was core snap and only one
[11:11] <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:13] <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:25] <zyga> hmmmm
[11:25] <zyga> one more twist
[11:26] <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:27] <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:28] <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:30] <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:31] <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:32] <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:33] <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:34] <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:35] <pstolowski> Chipaca: we will assume "yes" to everything you don't explicitely nack
[11:39] <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:42] <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:44] <mborzecki> heh, pushed to the wrong PR branch, quick reset & force push, maybe nobody will notice :)
[11:47] <mup> PR snapd#5366 opened: snap: helper for validating snap instance names <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5366>
[11:54] <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:58] <zyga> mvo: what's the id of snapd snap in staging?
[12:01] <zyga> hmm, we don't restart snapd.service when installing snapd.snap yet, do we?
[12:02] <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:03] <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:04] <jamesh> so I wonder if that test is using a bit of an anti-pattern
[12:05] <zyga> jamesh: looking
[12:07] <zyga> hmmm
[12:07] <zyga> I'm puzzled
[12:08] <zyga> what's the xdg-open in the filesystem that this conflicts with?
[12:09] <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:10] <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:11] <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:13] <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:14] <zyga> mvo: ping
[12:16] <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:17] <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:18] <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:19] <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:21] <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:22] <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:23] <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:24] <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:25] <zyga> actually, let me have lunch
[12:26] <mborzecki> wow, econnreset
[12:26] <mborzecki> https://api.travis-ci.org/v3/job/394933199/log.txt
[12:29] <pstolowski|lunch> 2018/06/21 12:14:46.074136 store.go:1555: DEBUG: Download succeeded in 4.935s (109MB/s)
[12:31] <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:33] <pstolowski> i guess iptables rule is not immediately effective (as suspected by mvo)
[12:34] <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:36] <mvo> abeato: those should just be warnings
[12:37] <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:38] <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:39] <abeato> mvo, ok, was just wondering
[12:39] <abeato> thx
[12:43] <zyga> mvo: do you have some time to hop on the standup HO now and talk about core18?
[12:44] <mvo> zyga: yes, one minute, just finishing a small PR
[12:44] <zyga> ok
[12:48] <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:50] <zyga> mvo: ok, managed to join via regular hangouts
[12:50] <mborzecki> pstolowski: ok if i restart that build with econnreset?
[12:51] <pstolowski> mborzecki: yep, i made a copy
[12:51] <mborzecki> ack
[12:51] <pstolowski> thanks
[12:52] <mborzecki> pstolowski: download is run by the client only right? snapd is not proxying anything there?
[12:52] <pstolowski> mborzecki: correct
[12:53] <pstolowski> mborzecki: (in this particula case, e.g. on 'snap download ..')
[12:53] <mborzecki> right
[12:53] <mvo> zyga: look at your video ;)
[12:56] <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>
[13:47] <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:53] <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 :)
[14:03] <mvo> zyga: anything you need in 2.33.1 for suse?
[14:05] <zyga> Hmmm, yes but i am afk
[14:05] <zyga> 32C now, ufff
[14:22] <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:27] <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:40] <mvo> mborzecki: \o/ thank you
[14:48] <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:54] <mup> PR snapd#5372 opened: many: improve udev trigger on refresh experience (2.33) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5372>
[15:33] <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:38] <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:42] <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:43] <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:47] <mup> PR snapd#5373 opened: release: 2.33.1 <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5373>
[15:52] <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:53] <pstolowski> looking
[15:56] <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>
[16:12] <pedronis> as I remarked to mvo this morning 5331 is not sufficient to solve the related problems
[16:18] <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:27] <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:30] <pedronis> I don't think is --dangerous
[16:30] <pedronis> is local vs from from store
[16:31] <pedronis> the involved files are created differently
[16:31] <pedronis> I see the 0644
[16:33] <pedronis> the 0600 (for local installs) comes from ioutil.TempFile
[16:55] <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>
[17:01] <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:08] <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:10] <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:11] <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:15] <mvo> zyga: oh, neato, I was not aware of this
[17:16] <zyga> storm is coming!
[17:17] <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:18] <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:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:37] <zyga> aha
[17:49]  * Chipaca EODs and goes to find a place with a tv
[17:49] <Chipaca> o/
[17:50] <zyga> uh-oh
[17:50] <zyga> fire nearby
[17:50] <zyga> I see lots of smoke and hear the sirens
[18:01] <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:07] <zyga> smoke intensifies
[18:08] <zyga> I'll go to check it out
[18:12] <zyga> an old house is on fire
[18:14] <zyga> and a 2nd building now, a block of flats next to it, still under construction
[18:16] <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:17] <zyga> mborzecki: ^
[18:21] <zyga> more fire
[18:21] <zyga> and more sirens nearby
[18:24] <zyga> https://www.facebook.com/photo.php?fbid=1939797056064540&set=gm.10160553222185322&type=3&theater
[18:26] <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:28] <mvo> zyga: yeah, the failure of the changelog PR is strange
[18:32] <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:38] <mvo> is it just me or is travis very slow?
[18:38] <mvo> I mean, giving me data for the test results
[18:46] <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:47] <zyga> I sent my build to https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd
[18:49] <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)
[19:00] <Pharaoh_Atem> zyga: %{_systemdgeneratordir}
[19:01] <Pharaoh_Atem> zyga: %{_datadir}/dbus-1/services
[19:03] <zyga> it would be awesome if some python script could do that
[19:03] <zyga> thank you!
[20:56] <zyga> Pharaoh_Atem: let me know if you need any testing on Fedora
[21:47] <Pharaoh_Atem> zyga: will do
[21:47] <Pharaoh_Atem> I'm planning on updating Fedora to 2.33.1
[21:48] <Pharaoh_Atem> I'm trying to coordinate updating xdg-desktop-portal to 0.11 there too, though
[22:59] <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)
[23:22] <zyga> ah
[23:22] <zyga> fixed it :)
[23:22] <zyga> sheesh