| zyga | good morning | 06:09 |
|---|---|---|
| * zyga preps kids for school | 06:09 | |
| mborzecki | morning | 06:15 |
| zyga | good morning everyone | 07:14 |
| zyga | https://forum.snapcraft.io/t/yes-snaps-are-cross-distribution/3906 <- cool stuff :) | 07:14 |
| mvo | zyga: good morning | 07:18 |
| mup | PR snapd#4637 opened: devicestate: fix the TestDoRequestSerialErrorsOnNoHost failing on artful/bionic <Created by mvo5> <https://github.com/snapcore/snapd/pull/4637> | 07:20 |
| zyga | huh? | 07:21 |
| zyga | mvo can you explain? | 07:21 |
| mborzecki | zyga: mvo: morning | 07:26 |
| mborzecki | zyga: iirc there's an ongoing story about pickign the right 'unresolvable' domain in the tests, *.test was suppsoed to be the answer, but my guess is some resolvers were trying to resolve it actually | 07:27 |
| mborzecki | zyga: /var/lib/snapd/mount is something that was introduced in 2.31 cycle? | 07:30 |
| zyga | no | 07:30 |
| zyga | far older | 07:30 |
| mborzecki | snap-mgmt --purge does not clean it up | 07:31 |
| mborzecki | i'm checking snapd aur package and noticed that /var/lib/snapd/mount was left behind when i removed snapd-git | 07:32 |
| zyga | mborzecki it's very very old, probably an omission then | 07:37 |
| zyga | mvo could we use something like http://unresolvable.snapcraft.io | 07:37 |
| zyga | and arrange with people so that it never resolves | 07:37 |
| zyga | I'm almost inclined to buy really-nowhere.com ;-) | 07:38 |
| mvo | zyga: ups, thanks. so the issue appaears to be that for some daemons artful/bionic returns SERVFAIL instead of NXDOMAIN | 07:43 |
| mvo | zyga: its not fully clear yet why, I'm looking into this. we see this on bionic autopkgtests and also on one of my two artful systems | 07:43 |
| zyga | mvo can I help somehow, I can setup nothing.zygoon.pl with any config desired | 07:44 |
| zyga | how are you testing this? | 07:44 |
| mvo | zyga: I have one machine where i can reproduce it | 07:44 |
| zyga | is it using systemd-resolved? | 07:44 |
| mup | PR snapd#4637 closed: devicestate: fix the TestDoRequestSerialErrorsOnNoHost failing on artful/bionic <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4637> | 07:44 |
| mvo | zyga: I think so, I switched to it a while ago there, I would consider it a fluke without the autopkgtest failure that looks similar | 07:45 |
| mvo | zyga: internally we handle SERVFAIL as a temporary error and retry | 07:45 |
| zyga | well, my offer stands, let me know if I can help | 07:45 |
| mvo | zyga: this is why we see a test failure, this test is expecting an error and it gets a "doing" | 07:45 |
| zyga | ack | 07:45 |
| mvo | zyga: thanks! I will dig a bit | 07:45 |
| * zyga looks for a color scheme appropriate for "gloomy polish morning" | 07:46 | |
| mborzecki | gloomy, it's fat thursday today | 07:46 |
| mborzecki | zyga: did you get your donut yet? | 07:47 |
| pedronis | mvo: hi, don't autopkgtest machines proxy http(s)? that probably gives a different kind of errors | 07:56 |
| zyga | mborzecki no, not today | 07:57 |
| zyga | mborzecki I will get one in a few days, today is the worst possible day to buy them (unless you make one at home0 | 07:58 |
| mvo | pedronis: thats an interessting idea, they do that | 08:03 |
| kalikiana | o/ | 08:03 |
| mvo | pedronis: it might be two issues :/ anyway, I get a SERVFAIL in a fresh bionic kvm (which we consider a temp error) so thats something to look into | 08:04 |
| pstolowski | morning | 08:04 |
| zyga | https://jordaneldredge.com/projects/winamp2-js/ :D | 08:33 |
| zyga | (drag and drop music to play) | 08:34 |
| mborzecki | zyga: i'll sync snapd-git aur PKGBUILD with that of snapd and open a PR to our repo to sync the recipe in packaging too | 08:34 |
| zyga | mborzecki sounds good, thank you | 08:35 |
| mup | PR snapd#4638 opened: devicestate: fix autopkgtest failure in TestDoRequestSerialErrorsOnNoHost <Created by mvo5> <https://github.com/snapcore/snapd/pull/4638> | 08:35 |
| zyga | anyone (sans chipaca who did) wants to look at https://github.com/snapcore/snapd/pull/4636 | 08:38 |
| mup | PR #4636: snap: understand directories in layout blacklist <Created by zyga> <https://github.com/snapcore/snapd/pull/4636> | 08:38 |
| wiking | i'm wondering snap is being used in the scenario of distributing a library itself. i.e. the package would contain a standalone app but a library? | 09:16 |
| zyga | wiking it's possible using the content interface | 09:18 |
| zyga | though we have a constraint that snaps can only share among one snap publisher | 09:18 |
| ikey | goooooooooooooooood mornin | 09:19 |
| zyga | if someone wants to maintain a snap that is used by others we need to allow that, it's essentially a promise to maintain something correctly | 09:19 |
| zyga | ikey happy pączki day :-) | 09:19 |
| zyga | wiking, for example there's a gnome platform snap (AFAIK) that anyone can use even though it's published by a third party | 09:19 |
| zyga | Chipaca morning :) | 09:20 |
| ikey | zyga, and thee | 09:20 |
| Chipaca | gnome-3-26-1604 | 09:20 |
| wiking | zyga, yeah i'm trying to avoid keep maintaining a deb/rpm package and possibly just switch to snap | 09:20 |
| Chipaca | zyga: moin | 09:20 |
| zyga | wiking though for libraries we recommend just making a part that anyone can use | 09:20 |
| zyga | parts can be easily embedded into an snap at build time | 09:20 |
| Chipaca | the gnome platform snap is gnome-3-26-1604 right now (the name encodes the abi and base libs to make it easier to pick and choose) | 09:21 |
| Chipaca | fwiw | 09:21 |
| wiking | zyga, ok so i guess i should be looking into 'Sharing a C-level library' | 09:22 |
| zyga | wiking so, who would consume your library? | 09:22 |
| wiking | anybody who wants to use it? :) | 09:22 |
| zyga | snaps, unlike classic packages, typically don't model runtime dependencies as distinct packages for end-users | 09:23 |
| zyga | I'm almost certain that you want to make a part instead of a snap | 09:23 |
| wiking | oh i see | 09:23 |
| zyga | wiking you can ask kalikiana about parts | 09:23 |
| zyga | wiking you can maintain a part on a shared pool of parts (I forgot the name) | 09:23 |
| zyga | and anyone can build a snap that references your part by name | 09:23 |
| wiking | https://docs.snapcraft.io/build-snaps/parts | 09:23 |
| wiking | i guess | 09:24 |
| zyga | parts are like -dev or -devel packages in classic systems | 09:24 |
| zyga | yes | 09:24 |
| wiking | k | 09:24 |
| wiking | cool thnx for the quick support :) | 09:24 |
| zyga | welcome, enjoy snaps :-) | 09:24 |
| wiking | thnx | 09:25 |
| * ikey needs to assault jdstrand's mindbrain today | 09:25 | |
| * zyga LOLs a little | 09:27 | |
| kalikiana | ikey: are you trying to break everyone else's brain by using that weird term? :-P | 09:41 |
| ikey | kinda. xD | 09:41 |
| mborzecki | #4615 and #4633 are in need of 2nd review | 09:45 |
| mup | PR #4615: overlord/snapstate/backend: perform cleanup if snap setup fails <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4615> | 09:45 |
| mup | PR #4633: snap: introduce timer service data types and validation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4633> | 09:45 |
| Chipaca | zyga: your blacklist checking code still has bugs i fear | 09:46 |
| zyga | yeah? | 09:46 |
| Chipaca | zyga: at least as I understand it | 09:47 |
| zyga | I implemented the thing we discussed last night, I'm adjusting tests to match | 09:47 |
| zyga | what's the bug? | 09:47 |
| Chipaca | zyga: should an entry of /foo stop a later entry of /foo/bar ? | 09:47 |
| zyga | if /foo is a file, no | 09:47 |
| zyga | if foo is a directory, yes | 09:47 |
| Chipaca | yes foo was a file iin this | 09:47 |
| Chipaca | why not? | 09:47 |
| zyga | I see what you are saying | 09:48 |
| zyga | technically it will just fail but it should be validated | 09:48 |
| zyga | hmm | 09:48 |
| zyga | but that's good, actually :) | 09:48 |
| zyga | it means validation gets easier | 09:48 |
| Chipaca | it's good that it'd fail, but my experience is the error is nicer if it's caught in a validation step | 09:48 |
| zyga | yep | 09:48 |
| Chipaca | zyga: does it? | 09:48 |
| zyga | thank you, I'll adjust | 09:48 |
| zyga | I think so | 09:48 |
| zyga | we'll see :) | 09:48 |
| Chipaca | you still don't want /foo to block /foolicious | 09:49 |
| zyga | sure | 09:49 |
| Chipaca | so for files it's "is this file a prefix of any complete prefix of this path" | 09:49 |
| Chipaca | where complete prefix is up to a / or o$ | 09:49 |
| Chipaca | or $* | 09:50 |
| * Chipaca is forgetting how to type | 09:50 | |
| * Chipaca goes to see if coffee is the answer | 09:50 | |
| * Son_Goku rises from the dead | 09:54 | |
| zyga | hey hey | 09:57 |
| Chipaca | pstolowski: what do you mean with "that's what we do in undoMountSnap"? | 10:05 |
| Chipaca | pstolowski: backend.UndoSetupSnap _is_ undoMountSnap | 10:05 |
| Chipaca | unless that is exactly what you mean | 10:06 |
| Chipaca | (thus my original phrasing) | 10:06 |
| * Chipaca seems to be in an argument with himself | 10:06 | |
| Chipaca | no i'm not | 10:06 |
| * Chipaca is too | 10:06 | |
| pstolowski | Chipaca, I mean, undoMountSnap calls backend.UndoSetupSnap, which does backend.RemoveSnapFiles | 10:08 |
| Chipaca | pstolowski: yes | 10:09 |
| Chipaca | ah | 10:09 |
| Chipaca | pstolowski: now i understood | 10:09 |
| Chipaca | pstolowski: and feel dumb :-) | 10:09 |
| pstolowski | Chipaca, so, it's the same cleanup that mborzecki does on error | 10:09 |
| Chipaca | yes | 10:10 |
| Chipaca | pstolowski: I got confused there, sorry, all sorted now (for now!) | 10:10 |
| pstolowski | no worries, happens all the time here ;) | 10:11 |
| Chipaca | but there's a big difference | 10:14 |
| Chipaca | i'll comment on the PR | 10:14 |
| mborzecki | Chipaca: please do | 10:16 |
| pstolowski | Chipaca, good! you get my curiosity | 10:17 |
| zyga | good morning niemeyer | 10:19 |
| zyga | you're up early :) | 10:19 |
| mborzecki | zyga: can you give 4571 another pass? | 10:20 |
| zyga | mmm | 10:20 |
| zyga | reading | 10:20 |
| zyga | @: :-) | 10:21 |
| zyga | I know what it does but ... autotools :) | 10:21 |
| zyga | btw, I meant to ask | 10:22 |
| zyga | why do we need another configre.ac there? (in data0 | 10:22 |
| zyga | I never used a tree with more than one | 10:22 |
| zyga | could those things be rolled into the main one? | 10:22 |
| zyga | mborzecki ^ | 10:25 |
| mborzecki | zyga: with paths going from cmd to ../data? hm don't know if out of source tree builds with work this way | 10:27 |
| zyga | yeah | 10:27 |
| mborzecki | zyga: nvm, i can try that | 10:28 |
| zyga | I'll read on | 10:28 |
| Son_Goku | mborzecki: they don't | 10:31 |
| Chipaca | mborzecki: I was wrong | 10:32 |
| mborzecki | mvo: RemainAfterExit=yes is interesting, ^C when systemctl start is waitig does not make the service exit, it keeps on working in the background, trying to start it again sort of hangs/hooks to the job that already runs | 10:34 |
| mvo | mborzecki: hm, so its not a solution for us? | 10:35 |
| Son_Goku | mborzecki: can we please make this so that --libexecdir=/usr/libexec works like it's supposed to? | 10:35 |
| Son_Goku | the only reason it doesn't currently is because of inconsistent implementations in makefiles/autofoo | 10:35 |
| zyga | mborzecki done | 10:36 |
| mborzecki | Son_Goku: have this in a separate branch now, quite a lot of changes, first i'd like to have autotools in data and then fix the libexec (would make the diff smaller also) | 10:36 |
| Son_Goku | and please use pkgconfig stuff | 10:37 |
| Son_Goku | it's already there since you've autotoolized it | 10:37 |
| Son_Goku | no reason not to | 10:37 |
| Chipaca | my typing *and* my language (and probably my diction!) are shot to hell today | 10:39 |
| mborzecki | mvo: feels like this setting should be exposed in snap.yaml instead, it will change the behavior of the unit a bit, once started it sort-of remains 'active' until you stop it, meaning when ExecStart exits it's still considered active | 10:39 |
| Chipaca | mborzecki: still, +1, and maybe even good news :-) | 10:39 |
| mborzecki | Chipaca: btw. i recall there was a lp bug about snap try that failed would leave some stuff behind and remember going through this code once already ;) (although i didn't know that undo is only run if task was successful) | 10:41 |
| zyga | Chipaca she sells sea shells on the ... | 10:42 |
| Chipaca | zyga: she sells sea shells on the sea shore // mollusc moltings mostly make measly money // the lady later lacks lucre and leans on loans // she barters her business to barely bypass bankruptcy // turns out tacky tourist trinkets turn in ten times the take // she shelves t-shirts by the sea shore. | 10:44 |
| zyga | wow, I didn't know most of them | 10:45 |
| Chipaca | zyga: that's a newer take on the old one | 10:45 |
| zyga | must write down for at-the-pub fun | 10:45 |
| Chipaca | zyga: https://www.smbc-comics.com/comic/2014-07-23 | 10:45 |
| Chipaca | zyga: the original is making fun of a very early (and mostly ignored) paleontologist, https://en.wikipedia.org/wiki/Mary_Anning | 10:47 |
| mborzecki | it'd be so nice if gnome-shell didn't log an exception every 3 seconds :/ | 10:48 |
| zyga | better not press ctrl-c | 10:48 |
| zyga | it's like "red... no blue YAAAH" | 10:48 |
| mborzecki | heh, use log is full of this BS: https://paste.ubuntu.com/26540491/ | 10:49 |
| mborzecki | and it's not even the extensions | 10:49 |
| Chipaca | mborzecki: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887082 / | 10:50 |
| Chipaca | ? | 10:50 |
| mborzecki | Chipaca: yup, that's the one | 10:52 |
| mup | PR snapd#4612 closed: snap: exclude `gettimeofday` from `snap run --strace` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4612> | 11:01 |
| mborzecki | mvo: i think we could run `systemctl start --no-block always`, if the unit files are bad (dependencies are wrong, format is incorrect) systemctl fails right away, and then we proceed to stop all the services in the cleanup phase | 11:25 |
| * pedronis lunch | 11:26 | |
| mvo | mborzecki: this does sound good to me | 11:29 |
| Chipaca | mborzecki: mvo: is this --no-block + poll? | 11:30 |
| mborzecki | mvo: we may consider waiting for a while to see if they do not enter a failed state, but this sounds like a compication and the 'while' may be hard to agree on | 11:31 |
| mborzecki | Chipaca: --no-block, with optional poll to see if ActiveState is not 'failed' | 11:32 |
| Chipaca | mborzecki: a'ight | 11:32 |
| mvo | mborzecki, Chipaca: what kinds of "gurantees" do we currently get from systemctl start? my understanding is that its not that much anyway but should not regress here of course | 11:33 |
| Chipaca | mvo: it comes back when the exec of the thing succeeded | 11:34 |
| Chipaca | mvo: or when the thing notified it was up, if it's a notifier | 11:34 |
| Chipaca | mvo: or when it finishes running, if it's a oneshot | 11:34 |
| Chipaca | mvo: or or or | 11:34 |
| Chipaca | :-) | 11:34 |
| Chipaca | mvo: that's part of the problem :-) | 11:34 |
| mvo | /o\ | 11:35 |
| mvo | indeed | 11:35 |
| Chipaca | no-block + poll lets _us_ decide the vagaries (and makes cancelling cleaner) | 11:36 |
| mborzecki | Chipaca: mvo: if i'm reading systemctl source code right, without --no-block, there will be a wait set up, for each of the jobs that failed, if any of those failed systemctl exits with error status | 12:04 |
| === verterok` is now known as verterok | ||
| mup | PR snapd#4619 closed: tests/main/user-data-handling: get rid of ordering bug <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4619> | 12:45 |
| zyga | Chipaca can you please have a 2nd look at 4636 | 12:51 |
| zyga | I implemented the thing we discussed last night | 12:51 |
| zyga | and you would be the perfect 2nd reviewer | 12:51 |
| Chipaca | zyga: i like it | 12:57 |
| Chipaca | zyga: i'll go deeper after the standup | 12:57 |
| zyga | thank you! | 12:57 |
| niemeyer | Chipaca: You coming? | 13:01 |
| Chipaca | niemeyer: nah | 13:03 |
| kyrofa | zyga, any ideas here? https://askubuntu.com/questions/1004203/installing-snapd-on-14-04-fails | 13:08 |
| zyga | yes | 13:09 |
| zyga | 3.13 | 13:09 |
| zyga | install snapd, reboot | 13:09 |
| zyga | it works | 13:09 |
| Chipaca | would now be a good moment to start freaking out because there's an ubuntu on its way to the asteroid belt | 13:09 |
| Chipaca | … and it's not going to be getting updates!!! /o\ | 13:09 |
| Chipaca | it's going to be _so_ rootkitted by the time it gets back | 13:10 |
| zyga | pesky space worms will eat it | 13:10 |
| Chipaca | zyga: https://i.imgur.com/vCrOo9e.gifv | 13:11 |
| verterok | ctrl-?meta-j29 | 13:16 |
| verterok | ups, ignore that | 13:17 |
| zyga | kyrofa I replied on the forum | 13:22 |
| * kalikiana going out for lunch, back later | 13:31 | |
| cachio_ | mvo, hey | 13:39 |
| mvo | cachio_: hey | 13:40 |
| cachio_ | mvo, I see this error compiling snapd on bionic https://paste.ubuntu.com/26541162/ | 13:40 |
| cachio_ | mvo, any guess? | 13:40 |
| pedronis | cachio_: hi, did you manage to start uploading some of those snaps that were missing in staging? | 13:41 |
| zyga | mvo oh btw, I didn't get that snap to work yesterday | 13:41 |
| cachio_ | pedronis, yes, the snaps are in the store | 13:41 |
| zyga | but it should be ok now | 13:41 |
| * pstolowski lunch | 13:41 | |
| zyga | I noticed that the build got done but upload failed because of stale auth | 13:42 |
| pedronis | cachio_: thx, I'll try again with the tests later today | 13:42 |
| cachio_ | pedronis, still working on some fixes | 13:42 |
| pedronis | ok | 13:42 |
| mvo | zyga: what snap was that? | 13:43 |
| pedronis | cachio_: let me know if I can help, also a couple we can just skip as discussed (lxd, canonical-livepatch and core transition) | 13:43 |
| mvo | cachio_: hm, I have not seen this yet | 13:43 |
| zyga | mvo the one you poked me about, snapd-hacker-toolbelt | 13:43 |
| Chipaca | zyga: #4606 could use your eyes | 13:43 |
| mup | PR #4606: snap: use custom unsquashfsStderrWriter for unsquashfs error detection <Created by mvo5> <https://github.com/snapcore/snapd/pull/4606> | 13:43 |
| mvo | zyga: aha, irght | 13:43 |
| mvo | zyga: right thanks | 13:43 |
| zyga | Chipaca sure, opened | 13:44 |
| mvo | cachio_: golang in bionic is on 1.9 now, maybe that is the problem, let me check | 13:44 |
| mvo | cachio_: hm, no, its like this for some time | 13:45 |
| zyga | niemeyer btw, I forced myself not to fullscreen any windows now | 13:45 |
| zyga | and I think I'm getting used to it | 13:45 |
| zyga | I can fit a few 1080p "big" windows easily and the habit of getting everything maximised is just that, a habit | 13:46 |
| mvo | cachio_: let me upgrade to bionic to test | 13:46 |
| cachio_ | mvo, nice, tx | 13:47 |
| cachio_ | pedronis, I uploaded 4 snaps | 13:47 |
| cachio_ | for amd64 and i386 | 13:48 |
| mvo | cachio_: hm, there was a new golang-1.9 upload during the night it seems | 13:50 |
| mvo | cachio_: so maybe/probably that is the reason | 13:51 |
| cachio_ | mvo, mmm | 13:51 |
| mvo | cachio_: but its a point release, should not break like this | 13:51 |
| mvo | "should" :) | 13:51 |
| mvo | anyway, once my upgrade is done I will know | 13:52 |
| cachio_ | mvo, btw I am using the cloud image that perhaps has some differences with yours installation | 13:52 |
| mvo | cachio_: I have a cloud image vm at hand too which I can try. I assume you did something like "sudo apt build-dep snapd" at some point, i.e. its not something like a missing pkgconfig or something like this (the error indicates its not) | 13:55 |
| === chihchun_afk is now known as chihchun | ||
| cachio_ | mvo, I updated the prepare-project script to use the external backend to test bionic | 13:57 |
| cachio_ | mvo, I am using the same code we have to build in linode but in the external backend | 13:58 |
| mvo | cachio_: ok | 13:59 |
| jdstrand | ikey: hey, steam-support is not forgotten! I traveled last week to the snapcraft sprint and a couple of other things came up, but as of last night, steam-support is back on top of the list so planned on working on it today | 13:59 |
| jdstrand | ikey: sorry for the delay | 13:59 |
| ikey | yeah no worries bud, just figured id prod | 14:00 |
| zyga | hey jdstrand | 14:00 |
| jdstrand | it wasn't going to make 2.31 anyway, so still no issues with 2.32 | 14:00 |
| ikey | yeah figures | 14:00 |
| jdstrand | hey zyga :) | 14:00 |
| zyga | I'm working on hardening, I won't push anything major for you to review today though | 14:02 |
| jdstrand | zyga: cool (on both counts) | 14:02 |
| zyga | landing existing stuff is fun enough :) | 14:03 |
| jdstrand | it's getting quite close :) | 14:03 |
| jdstrand | zyga: let me double check with you. your changes to the content interface recently were a) only about the slot side and b) add a new 'source' attribute that has read and write lists under it, which may not be specified alongside the legacy read and write attributes. read and write legacy attributes are still supported | 14:05 |
| jdstrand | zyga: is that a good summary? | 14:05 |
| zyga | yes | 14:05 |
| zyga | that's accurate | 14:05 |
| jdstrand | (I phrased that slightly weird, source is alone, read/write may continue to be used instead of source) | 14:06 |
| jdstrand | ok cool | 14:06 |
| mup | PR snapd#4639 opened: store: enable deltas for core devices too <Created by mvo5> <https://github.com/snapcore/snapd/pull/4639> | 14:06 |
| jdstrand | so, the review-tools now understand this :) (not in prod yet) | 14:06 |
| zyga | woot, great | 14:06 |
| mvo | cachio_: I can reproduce the error | 14:07 |
| cachio_ | mvo, good | 14:07 |
| jdstrand | I looked at the PR and it was clear enough, I just wanted to double check since the updated docs aren't there yet | 14:07 |
| cachio_ | mvo, yesterday I was using a prebuilt core | 14:07 |
| cachio_ | but then I tried to run all in the bionic and I got that error | 14:07 |
| zyga | Chipaca replied | 14:08 |
| cachio_ | pedronis, I see this errror https://paste.ubuntu.com/26541264/ | 14:08 |
| cachio_ | but the weird part is that test-snapd-base-bare snap is uploaded in the staging store | 14:08 |
| pedronis | cachio_: ah | 14:09 |
| * zyga returns to snapshots | 14:09 | |
| mvo | cachio_, mwhudson it looks like 1.9.4 #cgo LDFLAGS whitelisting broke snap-seccomp | 14:10 |
| cachio_ | pedronis, not sure which could be the reason | 14:10 |
| * Chipaca hugs zyga | 14:10 | |
| pedronis | cachio_: I dont't see that snap | 14:11 |
| pedronis | not in stable? | 14:11 |
| pedronis | no, sorry, mistyped | 14:12 |
| pedronis | cachio_: wondering if core is too old in that test | 14:12 |
| pedronis | cachio_: test-snapd-base-bare seems to have the wrong type, it says application and not base | 14:13 |
| pedronis | same in prod though | 14:14 |
| pedronis | mmh | 14:14 |
| mvo | cachio_, mwhudson https://github.com/golang/go/issues/23672 is the issue, our ldflags -Wl,-Bstatic are not longer allowed | 14:14 |
| zyga | hmm | 14:14 |
| zyga | mvo are we in trouble? | 14:14 |
| mvo | zyga: a bit | 14:14 |
| zyga | a little bit or the grammatical bit where it's really a bucket full of trouible | 14:15 |
| pedronis | mvo: any idea why base snaps would work with the production store, but not staging (I don't know what would be different) | 14:15 |
| zyga | *trouble | 14:15 |
| mvo | zyga: our static linking in snap-confine of libseecomp no longer works | 14:15 |
| zyga | hmmm hmmm | 14:15 |
| mvo | pedronis: work in the sense that snap install base-18 from staging does not work? | 14:15 |
| zyga | is that related to golang or to something else? | 14:15 |
| pedronis | mvo: this https://paste.ubuntu.com/26541264/ | 14:15 |
| mvo | zyga: golang upstream change | 14:15 |
| pedronis | from cachio_ | 14:15 |
| mvo | zyga: https://github.com/golang/go/issues/23672 | 14:15 |
| pedronis | the base snap is there in staging, with the wrong type fwiw, but it has the wrong type also in production afaict | 14:16 |
| mvo | cachio_, pedronis is test-snapd-base-bare published in staging into the stable channel? | 14:16 |
| zyga | mvo hold on but snap-confine is in pure c | 14:16 |
| zyga | or did you meant snap-seccomp | 14:16 |
| mvo | zyga: sorry, snap-seccomp | 14:16 |
| zyga | ahh | 14:16 |
| zyga | ok | 14:16 |
| zyga | well | 14:17 |
| zyga | that sucks | 14:17 |
| zyga | mvo let me know if you want to discuss options | 14:17 |
| zyga | we could dlopen libseccomp from core perhaps | 14:17 |
| cachio_ | mvo, yes | 14:17 |
| zyga | (that would be good on a few levels, at least) | 14:17 |
| cachio_ | mvo, in staging for all the archs in all the channels | 14:17 |
| pedronis | cachio_: what snapd version is in use there, I suppose master? | 14:18 |
| cachio_ | pedronis, yes | 14:18 |
| mvo | zyga: I need to think a little bit about it, but it sucks | 14:18 |
| pedronis | cachio_: I can try as well in a little bit, not sure what would be different in staging though | 14:19 |
| cachio_ | pedronis, it is weird because I can install test-snapd-base-bare | 14:21 |
| cachio_ | in the staging store | 14:22 |
| cachio_ | but if it used as base snap it cannot be found | 14:22 |
| mvo | cachio_: quite confusing | 14:23 |
| jdstrand | kyrofa: hi! weird: kernel: [1304675.438833] audit: type=1400 audit(1518072222.273:174): apparmor="DENIED" operation="exec" profile="snap.nextcloud.mysql" name="/bin/systemctl" pid=19425 comm="mysql.server" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 | 14:24 |
| jdstrand | kyrofa: I think it is falling back though, since I see: nextcloud.mysql[19403]: Shutting down MySQL | 14:25 |
| jdstrand | nextcloud.mysql[19403]: .. * | 14:25 |
| jdstrand | systemd[1]: Stopped Service for snap application nextcloud.mysql. | 14:25 |
| mborzecki | mvo: zyga: moving each -Wl into separate line does not help I guess? | 14:26 |
| mvo | mborzecki: I can try, I think its a whitelist | 14:26 |
| mborzecki | right: there's a review for --as-needed https://go-review.googlesource.com/c/go/+/92795 | 14:27 |
| mborzecki | mvo: and thre are environment variables too | 14:28 |
| mborzecki | mvo: https://go.googlesource.com/go/+/867fb18b6d5bc73266b68c9a695558a04e060a8a | 14:28 |
| mborzecki | this piece in particular: https://go.googlesource.com/go/+/867fb18b6d5bc73266b68c9a695558a04e060a8a%5E%21/#F3 | 14:29 |
| mborzecki | zyga: tried this in the autotools branch https://paste.ubuntu.com/26541368/ automake went down with some bs error, clearly confused about the relative paths | 14:34 |
| zyga | uh | 14:34 |
| zyga | mborzecki what if we moved those upstairs | 14:35 |
| zyga | that would work, right? | 14:35 |
| mborzecki | that would work, but it will also clutter the toplevel dir | 14:35 |
| greyback | is there a list of env vars available for use in snippits in snapcraft? (not for snaps themselves) | 14:35 |
| zyga | sure | 14:35 |
| zyga | Chipaca I added a review to snapshots (half of review really) | 14:36 |
| mborzecki | zyga: otoh, it's 3 files at most that need to be kept in the tree -> configure.ac, Makefile.am, autogen.sh, the rest is just temporary artifacts | 14:37 |
| zyga | yeah | 14:37 |
| zyga | maybe that's the solution | 14:37 |
| zyga | mborzecki so | 14:38 |
| zyga | mborzecki another idea | 14:38 |
| zyga | how about if we add .dot-dot symlink | 14:39 |
| zyga | and make data show up as cmd/.dot-dot/data | 14:39 |
| zyga | :D | 14:39 |
| mborzecki | hmm might work, let me try | 14:40 |
| zyga | looking at 4606 now | 14:41 |
| mborzecki | mvo: by the looks of it, the arch package does not build due to the go changes atm | 14:46 |
| mborzecki | right, pkg-config is broken now too | 14:49 |
| mborzecki | go build github.com/snapcore/snapd/cmd/snap-seccomp: invalid pkg-config package name: --static | 14:52 |
| mborzecki | zyga: can you take a look at https://github.com/bboozzoo/aur-snapd/pull/3 ? | 14:53 |
| mup | PR bboozzoo/aur-snapd#3: snapd: updates <Created by bboozzoo> <https://github.com/bboozzoo/aur-snapd/pull/3> | 14:53 |
| mup | Issue snapcraft#1921 opened: Evaluate contents of manifest.txt, add reasons and surface to the user during staging <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1921> | 14:53 |
| zyga | yes | 14:53 |
| mborzecki | i'll push another fix with a workaround for go1.9.4 in a minute | 14:53 |
| zyga | mborzecki done | 14:57 |
| mborzecki | zyga: thanks | 14:58 |
| zyga | Chipaca +1 | 15:03 |
| mup | PR snapd#4606 closed: snap: use custom unsquashfsStderrWriter for unsquashfs error detection <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4606> | 15:03 |
| zyga | pstolowski which PR should I review first for you? | 15:08 |
| pstolowski | zyga, #4401 please, thanks! | 15:09 |
| mup | PR #4401: snapstate/ifacestate: auto-connect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4401> | 15:09 |
| mup | PR snapd#4636 closed: snap: understand directories in layout blacklist <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4636> | 15:09 |
| jdstrand | davidcalle (cc sergiusens): hey did you see my comment yesterday about https://docs.snapcraft.io/deprecation-notices/dn5? | 15:16 |
| popey | jdstrand: is this the right report a bug against the snap review tools? https://bugs.launchpad.net/review-tools | 15:20 |
| jdstrand | popey: I'd prefer that, yes (at some point soonish we'll deprecate click-reviewers-tools bzr branch and use only the review-tools git banch, so it would be good to get used to it) | 15:23 |
| popey | it was the first hit when i googled, :) | 15:24 |
| popey | thanks | 15:24 |
| jdstrand | popey: before you file, perhaps you could say what the problem is now? quite a few updates are on their way to prod | 15:24 |
| popey | jdstrand: I wanted to suggest that we prevent "empty" snaps from landing in the stable channel. In the same way we don't allow grade: devel ones in stable. | 15:24 |
| popey | e.g. there is a snap which just landed in stable called "toto". It is entirely empty, contains only a snap.yaml, nothing else. | 15:25 |
| popey | this shouldn't be allowed to land in stable IMO | 15:25 |
| Chipaca | zyga: woo | 15:25 |
| jdstrand | popey: interesting. ok, file away :) | 15:25 |
| popey | ta | 15:25 |
| jdstrand | popey: note that the review tools aren't run on channel promotions, only the initial upload, so a change tot he review-tools would mean no empty snaps in any channel | 15:26 |
| * zyga breaks for back pain | 15:26 | |
| popey | awww | 15:26 |
| zyga | I'll continue reviewing 4401 | 15:26 |
| zyga | but later | 15:26 |
| jdstrand | popey: the snapstore could, in theory, peek back at a previous run for channel promotions. that would need some design and likely help from the review tools | 15:27 |
| jdstrand | popey: I'm not sure at what priority that would be. I'm guessing quite low for this particular issue | 15:28 |
| jdstrand | popey: tbh, an empty snap seems like it isn't valid in any channel though | 15:28 |
| popey | jdstrand: i think some might argue that it's not fair for a new developer to get punched in the face with words like "error" and "reject" as they're starting out with snaps | 15:31 |
| jdstrand | jjohansen: hey, do you have a moment to kick around an idea for organizing a new steam-support interface | 15:32 |
| jdstrand | popey: well, they'll face all those same words if they do other things wrong. why is that one special? | 15:33 |
| jdstrand | eg, the pick an invalid snap name | 15:33 |
| jdstrand | they* | 15:33 |
| popey | *shrug* emoji | 15:33 |
| jdstrand | popey: I'll put it this way. if you file the bug, I will fix it and this will apply to everything. if you don't, I'll conveniently forget about it. if you think the snapstore should support peeking back on channel promotions, then file it against the snapstore and add a review-tools task | 15:35 |
| popey | ok | 15:35 |
| === chihchun is now known as chihchun_afk | ||
| pstolowski | niemeyer, pedronis could you please take another look at #4401? | 15:41 |
| mup | PR #4401: snapstate/ifacestate: auto-connect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4401> | 15:41 |
| jjohansen | jdstrand: sorry, yeah I have a few minutes, /me is getting kids ready for school | 15:48 |
| niemeyer | pstolowski: SUre thing | 15:49 |
| pedronis | pstolowski: likely tomorrow morning | 15:49 |
| zyga | jjohansen o/ | 15:49 |
| pedronis | cachio_: mvo: I think the issue is that /details for test-snapd-busybox-static doesn't have base set | 15:50 |
| pedronis | in staging | 15:50 |
| jjohansen | hey zyga | 15:50 |
| pedronis | cachio_: mvo: I remember some discussion about needing backfilling for something, and decided it was not worth it, it probably needs to be uploaded again | 15:50 |
| pedronis | unless it was just uploaded in which case, something else is going on | 15:51 |
| cachio_ | pedronis, ok, I'll upload it | 15:54 |
| jdstrand | jjohansen: just ping me when ready. it might take up to 15 or so | 15:54 |
| jdstrand | maybe faster. I tripled what I thought it might take :) | 15:55 |
| pedronis | cachio_: it seems old even in staging, afaict | 15:56 |
| pedronis | so re-uploading from prod to staging should help or so I hope | 15:56 |
| cachio_ | pedronis, I planned to copy the one in prod to staging | 15:56 |
| pedronis | sounds good | 15:56 |
| cachio_ | pedronis, ok | 15:56 |
| cachio_ | mvo, could you please share test-snapd-busybox-static with me? | 15:57 |
| jjohansen | jdstrand: 15 min to discuss or implement? | 16:00 |
| jjohansen | :) | 16:00 |
| jdstrand | jjohansen: hehe | 16:00 |
| jjohansen | jdstrand: shoot I have 15 min | 16:01 |
| jdstrand | jjohansen: it's true, I could just say 'you get the wide-open classic template' and *boom* it works :P | 16:01 |
| jdstrand | jjohansen: ok, more seriously | 16:01 |
| mvo | cachio_: sure, one sec | 16:01 |
| jdstrand | jjohansen: architecture is this: steam has a steam client. the client allows you to buy, install, remove and launch games | 16:02 |
| cachio_ | mvo, tx | 16:02 |
| * zyga returns to being off, sorry :/ | 16:02 | |
| mvo | mborzecki: yeah, same problem everywhere I presume, the go change is a security update so I guess its applied everywhere :/ | 16:02 |
| jdstrand | jjohansen: many steam games use a process lifecycle where they will ptrace child processes | 16:02 |
| jdstrand | jjohansen: this is just how it goes (proprietary blobs) | 16:02 |
| jjohansen | jdstrand: have I mentioned how much I hate proprietary blobs lately | 16:03 |
| mborzecki | mvo: i've pushed a fix to arch package, so that it builds now :/ funny cause it was building in the morning (i was working on it a bit), then ~2pm they pushed an update of go and it broke | 16:03 |
| zyga | Chipaca I pushed 4640 with one more layout feature | 16:03 |
| mvo | cachio_: on your way | 16:04 |
| jdstrand | jjohansen: so I had the idea that it would be nice if the launcher was in one profile, and it would launch games in a different profile. we'll call the launcher profile the client profile and the games profile the game profile | 16:04 |
| mup | PR snapd#4640 opened: snap,interfaces: allow using bind-file layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4640> | 16:04 |
| mvo | mborzecki: what fix did you use? CGO_LDFLAGS_ALLOW=.* or similar :) ? | 16:04 |
| cachio_ | mvo, tx | 16:04 |
| jdstrand | jjohansen: the game profile would be under a different label, and it could ptrace itself (let's not worry about seccomp in <4.8 kernels for this discussion) but not the client | 16:04 |
| mborzecki | mvo: just this patch https://github.com/bboozzoo/snapd/commit/3286baf646fa7974c165efd9b63c690d08dff6b7 the rest seemd to build just fine | 16:05 |
| niemeyer | pstolowski: LGTM I think.. I've skimmed through it, and haven't spent as much time on it as last time, but if pedornis is happy and it works, I'm happy with the change | 16:05 |
| mvo | mborzecki: ok | 16:06 |
| mborzecki | mvo: and we did disable the static linking in arch anyway as libseccomp is only dynamic | 16:06 |
| niemeyer | It's certainly quite nice to have auto-connect on its own task | 16:06 |
| mvo | mborzecki: aha, ok | 16:06 |
| pstolowski | niemeyer, ty | 16:06 |
| jdstrand | jjohansen: so, that is the germ of the design. in terms of implementation, I really want to use a Px rule with a sibling profile, because of the way snapd is architected and generates profiles, that is convenient | 16:06 |
| jjohansen | jdstrand: ack, launcher, client, game A, game B, game C, profiles ... | 16:06 |
| jdstrand | jjohansen: but I ran into: https://bugs.launchpad.net/apparmor/+bug/1696552 | 16:06 |
| mup | Bug #1696552: syntax errors when specifying px rules with exec transitions that have '.' in the name <AppArmor:New> <https://launchpad.net/bugs/1696552> | 16:06 |
| mborzecki | ok, end of the week for me, cu all on monday | 16:07 |
| jjohansen | jdstrand: oh, sorry I meant to have that fixed already, I can add it to todays todo, its an easy fix | 16:07 |
| jdstrand | jjohansen: launcher/client are the same, games likely will share a profile in the initial implementation since the steam client (proprietary blob) has no concept of change_profile/etc | 16:07 |
| jdstrand | jjohansen: (I would use file rules to transition to the games profile) | 16:08 |
| === chihchun_afk is now known as chihchun | ||
| jdstrand | jjohansen: well, I was trying to think through that. yes we should clearly fix the parser. that is a given | 16:09 |
| jjohansen | jdstrand: that makes me a sad panda but ack | 16:09 |
| jdstrand | jjohansen: but, that means SRUs for Ubuntu (possible) and then updates for suse, solus, Ubuntu derivatives, etc (improbable for the whole list), which means that steam will work on some distros, bt not others (bad for snapd) | 16:10 |
| ikey | steam what now | 16:11 |
| ikey | ears twitched | 16:11 |
| jdstrand | jjohansen: re file rules> yeah. not terribly excited by that, but the secret hope is that if we can improve on steam's security story by preventing games from attacking the client, then maybe, just maybe, they'd be open to building something into their client down the line | 16:11 |
| jdstrand | jjohansen: perhaps a pipe-dream, but one can hope :) | 16:11 |
| ikey | not outside the realms of possibilities tbh | 16:12 |
| jjohansen | jdstrand: yes, sorry wish I could write bug free software, but I seem to be gifted with talents else where | 16:12 |
| ikey | we already know they flirted with flatpak in the past purely to look only at bubblewrap re: sandboxing | 16:12 |
| jdstrand | jjohansen: because of what I just mentioned with parser and other distros, I started exploring other ideas | 16:12 |
| jdstrand | jjohansen: haha, no need to apologize. apparmor is awesome! | 16:12 |
| jdstrand | ikey: hey, I was serious that steam-support was on the list for today :) | 16:13 |
| ikey | :D | 16:13 |
| ikey | kickin ass | 16:13 |
| jdstrand | jjohansen: so I came up with an idea to use a child profile | 16:13 |
| jjohansen | that can work | 16:14 |
| jdstrand | jjohansen: I have two choices with that. one I greatly prefer in terms of snapd architecture | 16:14 |
| jdstrand | it can. I did it | 16:14 |
| jdstrand | jjohansen: so, I can either generate profiles like this: | 16:14 |
| jdstrand | 'profile client { profile { game } }' or I can do 'profile client {} profile client//game {} | 16:15 |
| jdstrand | ' | 16:15 |
| jdstrand | the second is preferred in terms of how snapd is architected. again, I can do the first | 16:16 |
| jdstrand | note that in the second, 'client' and 'client//game' are in different files | 16:16 |
| jdstrand | which means that I need to be concerned about profile load and remove order | 16:17 |
| jjohansen | jdstrand: so the second is supported, you do need to be worried about order to a degree | 16:18 |
| jdstrand | I'm able to deal with load ok, but remove generates a parser error because if I unload 'client', it unloads 'client//game' so then when I unload 'client//game' there is an error | 16:18 |
| jjohansen | if you remove a parent before its child, the child should get repeated as well, and the 2nd remove should complain with ENOENT | 16:18 |
| jdstrand | precisely | 16:18 |
| jjohansen | right | 16:19 |
| jdstrand | I thought I tried it the other way.. | 16:19 |
| jdstrand | (too) | 16:19 |
| jdstrand | and I think the unload of the parent had a parser error cause the child was already removed | 16:19 |
| jdstrand | let me double check that | 16:19 |
| jjohansen | that should just work, if not there is a bug | 16:20 |
| jjohansen | I also need to fix the parser so that if they are both specified, it just does the right thing | 16:21 |
| jdstrand | that makes sense | 16:21 |
| jjohansen | it can figure it out, currently it doesn't | 16:21 |
| jdstrand | for the snapd case, currently it loads and removes one at a time | 16:21 |
| jdstrand | I can change snapd to do things of course | 16:22 |
| jjohansen | jdstrand: I need to step away, finish your dump and I'll answer when I get back | 16:22 |
| jdstrand | jjohansen: ok, good timing. I couldn't find my profiles so it'll take me a minute | 16:22 |
| zyga | jdstrand anything I can help with? | 16:22 |
| Chipaca | not for the first time i find myself trying to use markdown in a go comment | 16:22 |
| jdstrand | zyga: not at this time | 16:23 |
| ikey | Chipaca, backtick all the things | 16:24 |
| Chipaca | ikr | 16:24 |
| diddledan | flexiondotorg: I've just promoted audacity to candidate - tell the LNL crew that the last of their three desired snaps is snapped | 16:25 |
| ikey | lol | 16:25 |
| diddledan | oh ello ikey | 16:25 |
| diddledan | :-p | 16:25 |
| * diddledan tells ikey directly | 16:25 | |
| zyga | ikey I had that period where everything was pre-formatted and I could not stand otherwise | 16:25 |
| ikey | ello diddledan lol | 16:26 |
| ikey | zyga, i went so overboard on it i added a markdown parser to solus SC | 16:26 |
| ikey | and it has the markdown in the git tags | 16:26 |
| ikey | forms our changelogs :P | 16:26 |
| zyga | that's pretty nice | 16:26 |
| ikey | ref: https://dev.solus-project.com/R3571:37e7f17508ecdedf13f061cad974b2a09ee10687 | 16:27 |
| ikey | client side: https://ibin.co/3r15d94CbaGW.png | 16:27 |
| ikey | some stuff like the CVE IDs automatically link | 16:28 |
| jdstrand | jjohansen: ok, I was wrong: load parent, load child, unload child, unload parent works fine: https://paste.ubuntu.com/26541896/ | 16:32 |
| jdstrand | jjohansen: if I change the load or unload order, then I get ENOENT | 16:32 |
| jdstrand | jjohansen: which means, I can make this child approach work. I'll just need to adjust snapd to do something special with load/unload with this approach | 16:34 |
| * jdstrand now checks what apparmor does with the cache files | 16:34 | |
| jjohansen | jdstrand: the cache file is based on the file name that the child profile is in | 16:35 |
| jjohansen | so it will get its own cache file if its in a separate file | 16:36 |
| jjohansen | if you put them in the same cache file they will share | 16:36 |
| jjohansen | if the compiler merges them into a single cache file | 16:36 |
| jjohansen | you will get 2 symlinks to the merged file | 16:36 |
| jjohansen | note: you won't see that one happen yet | 16:37 |
| jdstrand | jjohansen: interesting. so I could keep the text profiles separate, but have a single cache file | 16:37 |
| jdstrand | ? | 16:37 |
| jjohansen | jdstrand: uh theoretically, the current parser don't actually handle that yet | 16:38 |
| jdstrand | heh, ok, then that is out | 16:38 |
| jdstrand | but yes, I could put both into the same text file | 16:39 |
| jjohansen | but you can cat the 2 binaries together to get a single, and it will work | 16:39 |
| jjohansen | jdstrand: another approach is to do | 16:39 |
| jjohansen | profile A { | 16:39 |
| jjohansen | ... | 16:39 |
| jjohansen | } | 16:39 |
| jjohansen | include "children" | 16:39 |
| jjohansen | that would put them in a single text file, and allow you to stash the children profiles in separate files that are out of the regular load path | 16:40 |
| jjohansen | err, not single text file, single cache file | 16:40 |
| jjohansen | jdstrand: the parser will pickup the ability to merge profiles into a single cache file when they are specified on the same parser invocation and they meet certain criteria, but there are a few other things I need to land first | 16:41 |
| jdstrand | jjohansen: so if I do 'profile parent {} profile child {}' in the same file, it doesn't work on unload (ENOENT), regardless of order. (load works both ways) | 16:42 |
| jjohansen | oh! that would be a parser bug, I wonder when that broke, and why arekm isn't yelling at me | 16:43 |
| jdstrand | jjohansen: to be clear, if I have the parent and child in different cache files, apparmor_parser will be sensitive to load order? | 16:43 |
| jdstrand | jjohansen: (this is artful btw) | 16:43 |
| jjohansen | jdstrand: yes separate cache files will be load order sensitive | 16:43 |
| jdstrand | ok. I *should* be able to lexically sort them for cache loading | 16:44 |
| jdstrand | and I *could* adjust snapd for handling load/unload order | 16:44 |
| ikey | doesn't apparmor_parser already do that? given that you can apparmor_parser load a directory that is purely a binary cache | 16:44 |
| jjohansen | sorry, I'll fix it in the parser too, but that will require and SRU which gets us back to the whole doesn't work every where problem | 16:44 |
| ikey | and no source files.. | 16:44 |
| jdstrand | the question for me then becomes, is that better than profile client { profile game{}} | 16:45 |
| jjohansen | dammit why didn't you point this out to me 5 years ago | 16:45 |
| jjohansen | :P | 16:45 |
| jdstrand | ikey: yes but different init scripts do different things | 16:45 |
| ikey | yeah i replaced them with aa-lsm-hook in solus | 16:45 |
| jdstrand | I need to make sure this works everywhere | 16:45 |
| ikey | for the betters | 16:45 |
| * jdstrand nods | 16:45 | |
| ikey | gotcha | 16:45 |
| jjohansen | jdstrand: what of | 16:45 |
| jjohansen | profile A { | 16:45 |
| jjohansen | include "children" | 16:45 |
| jjohansen | } | 16:45 |
| jjohansen | that should work | 16:46 |
| jdstrand | let me try that | 16:46 |
| jjohansen | and allow you to have the children in separate files | 16:46 |
| jdstrand | jjohansen: children is a dir? | 16:46 |
| jjohansen | jdstrand: that is up to you | 16:46 |
| jdstrand | let me try as a file | 16:46 |
| jjohansen | you could specify specific files, or have a dir you just drop stuff in | 16:46 |
| jjohansen | come to think of it, I think that is what arekm is doing now, and why he isn't yelling at me for the other being broken | 16:47 |
| jdstrand | jjohansen: I can't get that to work | 16:51 |
| jdstrand | jjohansen: https://paste.ubuntu.com/26542021/ | 16:53 |
| * jdstrand tries a dir | 16:54 | |
| jjohansen | jdstrand: in /tmp/child2 | 16:54 |
| jjohansen | lose #include <tunables/global> | 16:54 |
| jjohansen | and rename profile snap.steam-client.steam-client//game to just game | 16:54 |
| jdstrand | that makes sense | 16:55 |
| jdstrand | ok, that works | 16:55 |
| jdstrand | I only have to mess with the parent | 16:56 |
| ikey | like any good child would.. | 16:56 |
| jdstrand | it does mean I have to have snapd not do anything with the child profile though | 16:56 |
| jdstrand | (as in, load/unload it itself) | 16:57 |
| jdstrand | ok, so several options with the child | 16:57 |
| jdstrand | 1. embed the child in parent | 16:57 |
| jdstrand | 2. have child separate from parent, figure out load order in snapd | 16:57 |
| === chihchun is now known as chihchun_afk | ||
| jdstrand | 3. have child separate from parent via #include, adjust snapd to not fiddle with child in interface connections | 16:58 |
| jdstrand | these are options I can work through | 16:58 |
| jdstrand | jjohansen: my next question is: is there anything different I could try that we haven't discussed? | 16:59 |
| jdstrand | jjohansen: eg, apparmor namespace. I don't *think* so since the Px bug I mentioned was filed when playing with apparmor namespaces | 17:00 |
| jjohansen | jdstrand: you could use a namespace, I am not sure you want to atm | 17:01 |
| jjohansen | the scope isn't separated from the view, so once you enter the namespace | 17:01 |
| jdstrand | jjohansen: yeah, I kept trying to think through if that would help anything, but couldn't | 17:01 |
| jjohansen | you can't see the rest of the system profiles etc. It more like in a container or VM | 17:01 |
| jdstrand | plus, the status of namespace support across distros might make it problematic | 17:02 |
| jjohansen | loading into the namespace has the same issues | 17:02 |
| jdstrand | oh yeah, that would likely be a lot of trouble too | 17:02 |
| jdstrand | ok | 17:02 |
| jdstrand | jjohansen: thanks, this was very helpful | 17:02 |
| jjohansen | but you could get away with just tearing down the namespace to remove all its policy | 17:02 |
| mwhudson | mvo: doh | 17:02 |
| jdstrand | jjohansen: in terms of snapd, that change would not be terribly different that just dealing with the parent in option 3 | 17:03 |
| jjohansen | jdstrand: that said I very much would like snappy to use a namespace, I just need to land the scope work and have it propagate everywhere first :( | 17:03 |
| mwhudson | mvo: feel free to upload any fixes you need or tell me what i need to fix... | 17:03 |
| jjohansen | jdstrand: right | 17:03 |
| jdstrand | jjohansen: yeah. we'll get there | 17:03 |
| mvo | mwhudson: its a good question, I need to think about it and probably look at the go upstream diff | 17:04 |
| mvo | mwhudson: the change broke both our pkgconfig usage and our LDFLAGS | 17:04 |
| * mwhudson goes back to bed for a bit | 17:04 | |
| mvo | mwhudson: we use -Wl,-Bstatic | 17:04 |
| mvo | mwhudson: heh, do it, its not super urgent, I call it a day soon here | 17:05 |
| jdstrand | there is also a variation on one, where I modify snapd such that a snap command could end up as an embedded child profile | 17:05 |
| jdstrand | but anyway, that is for me to work through | 17:05 |
| jdstrand | jjohansen: thanks for all your help! | 17:05 |
| jjohansen | jdstrand: np | 17:05 |
| jdstrand | jjohansen: there is actually another option. we fix the parser for Px/px and make the use of the interface conditional on that fix being available | 17:10 |
| jdstrand | this way, anyone distro who wanted the fix could pull the patch into their parser | 17:11 |
| jdstrand | s/anyone/any/ | 17:11 |
| jdstrand | I'll bring this up to the snapd team | 17:11 |
| * kalikiana wrapping up for the day | 17:12 | |
| mvo | zyga: we will need is-nfs-home: [yes|no] as part of the system-key | 17:12 |
| zyga | mmm | 17:12 |
| zyga | yes | 17:12 |
| zyga | I think so | 17:12 |
| mvo | zyga: tests are breaking | 17:13 |
| mvo | zyga: without it | 17:13 |
| zyga | hmmm | 17:13 |
| jjohansen | jdstrand: that works for me too | 17:13 |
| mvo | zyga: I need to check, we have a bit of a recursive import problem, some of this code probably needs to go into osutil or something | 17:13 |
| zyga | mvo how did it break, I mean, we test this, right? | 17:13 |
| zyga | mvo, I forgot where I put the nfs code but yeah | 17:13 |
| mvo | zyga: yes, this is where it breaks, the test restarts snapd and assumes it re-genreates security profiles | 17:13 |
| mvo | zyga: and we no longer re-genreate on every restart | 17:14 |
| zyga | aha, so not broken in the wild, just in an upcoming branch? | 17:14 |
| zyga | or broken in the wild now | 17:14 |
| mvo | zyga: not broken in the wild | 17:14 |
| mvo | zyga: just in 4629 | 17:14 |
| zyga | ahh | 17:14 |
| zyga | god | 17:14 |
| zyga | good :) | 17:14 |
| zyga | I can fix that if you want | 17:14 |
| zyga | can you look at 4640 when you have some time? I will look at nfs part | 17:15 |
| mvo | zyga: I would not say no to this offer :) | 17:15 |
| zyga | thank you :) | 17:15 |
| mvo | zyga: probably in my morning but yeah, I have a look. I'm bit behind in reviews in general, maybe I can have a review-friday | 17:16 |
| mvo | zyga: I also wanted to stop pusing new PRs before my others are landed. but this is really hard | 17:16 |
| zyga | yeah | 17:16 |
| zyga | after this I only have layout spread PR (it depends on it now) and then I'll switch to hardening | 17:16 |
| zyga | Chipaca how about you? | 17:19 |
| Chipaca | zyga: what about me? | 17:19 |
| zyga | fancy doing 4640? | 17:20 |
| * zyga looks at nfs untangling | 17:20 | |
| Chipaca | zyga: doing it right now | 17:22 |
| zyga | thank you | 17:22 |
| zyga | I want that spread test out there | 17:22 |
| zyga | mvo any objections if I move more stuff to osutil? | 17:25 |
| zyga | like more of mount | 17:25 |
| zyga | I can move it to osutil/mount so that it doesn't cause a massive cluster of alterations if that makes it better | 17:25 |
| Chipaca | zyga: do you find "%[1]s %[1]s" % (a,) clearer than "%s %s" % (a, a)? | 17:42 |
| zyga | TBH, not really | 17:42 |
| Chipaca | zyga: then use the other ones :) | 17:43 |
| Chipaca | I mean, if you were passing around an enormous struct by value, it might be worth it? | 17:45 |
| Chipaca | but usually it's not | 17:45 |
| Chipaca | (in the common case of the thing being a poiner or a simple value, afaict it's more expensive in both memory and time to use the indexed version) | 17:45 |
| Chipaca | (add to that that it's less clear... ¯\_(ツ)_/¯ ) | 17:46 |
| Chipaca | like, 300ns vs 200ns for the two-args version | 17:46 |
| Chipaca | not that i'd be insane enough to have measured this | 17:46 |
| * Chipaca hides | 17:46 | |
| zyga | :) | 17:47 |
| zyga | hahah | 17:47 |
| zyga | thank you Chipaca | 18:06 |
| zyga | how long does "time go test ./..." in the root of the project take for you guys/ | 18:11 |
| zyga | mvo that will be one big branch | 18:19 |
| kyrofa | jdstrand, yeah I've looked into that one, even grepped the entire snap and can't find where it calls sytemctl. Wonder if it's in a binary somewhere | 18:21 |
| mvo | zyga: I like osutil/mount | 18:24 |
| zyga | I moved it to osutil now, we'll see how that looks like | 18:24 |
| jdstrand | kyrofa: just looking at the logs, seems to be coming from mysql | 18:25 |
| kyrofa | jdstrand, yeah, just none of its scripts. I'll take a quick grep of its src | 18:25 |
| mvo | zyga: ok, I was thinking it might be easier to use "mount" just like before but of course if we end up with two "mounts" (one in osutil one in interfaces) that sucks | 18:25 |
| zyga | yeah :/ | 18:25 |
| mvo | zyga: anyway, I will wait for the PR :) | 18:25 |
| zyga | I'm not done, let's see how it looks like in the end | 18:26 |
| jdstrand | ikey: I responded to the forum. I've pinged niemeyer to comment before I proceed | 18:27 |
| jdstrand | niemeyer: and I pre-apologize for the walls of text between https://forum.snapcraft.io/t/blowing-off-steam-lets-plan-steam-support-interface/3457/14 and https://forum.snapcraft.io/t/blowing-off-steam-lets-plan-steam-support-interface/3457/27, but we're pushing the envelope here | 18:28 |
| kyrofa | jdstrand, yeah nothing in the source either. No clue what's causing it | 18:29 |
| niemeyer | jdstrand: Appreciated! | 18:29 |
| jdstrand | greyback: hey, you probably say, but I reviewed pr 4545. lgtm for my stuff, but the changes from zyga prompted some discussion with him | 19:58 |
| mup | PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545> | 19:58 |
| jdstrand | s/say/saw/ | 19:58 |
| * zyga finished a very boring branch just now | 20:00 | |
| zyga | man | 20:00 |
| zyga | the things we have to do to make it compile ;-) | 20:00 |
| mup | PR snapd#4641 opened: many: move mount code to osutil <Created by zyga> <https://github.com/snapcore/snapd/pull/4641> | 20:03 |
| mup | PR snapd#4642 opened: many: add nfs-home flag to system-key <Created by zyga> <https://github.com/snapcore/snapd/pull/4642> | 20:07 |
| zyga | jdstrand hey, do you have a sec | 20:08 |
| jdstrand | zyga: what's up? | 20:08 |
| zyga | https://github.com/snapcore/snapd/pull/4640 | 20:08 |
| mup | PR #4640: snap,interfaces: allow using bind-file layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4640> | 20:08 |
| zyga | 65 lines :) | 20:08 |
| zyga | it's something I think we need for layouts and ... | 20:09 |
| zyga | ... :) | 20:09 |
| zyga | could you please look? | 20:09 |
| jdstrand | man github reviews are pretty ugly with the use of '%[1]s' | 20:11 |
| zyga | yeah, I will change that to %s %s | 20:11 |
| greyback | jdstrand: thanks, I'll wait to be told what to do :) | 20:12 |
| jdstrand | zyga: I wasn't necessarily saying that. personally I do find it easier to read as %s %s, but I can do either :) | 20:13 |
| jdstrand | that said, I'm fine if you change it :) | 20:13 |
| zyga | please review as-is, i'll do that separately | 20:13 |
| zyga | cool :-) | 20:13 |
| * jdstrand nods | 20:13 | |
| * ikey clicks the forums | 20:14 | |
| ikey | apologies for le delay | 20:14 |
| ikey | also the forums is making me think there is gonna be some kind of zombie event soon | 20:14 |
| ikey | massive letters "12 DAYS LATER" | 20:14 |
| zyga | jdstrand updated | 20:15 |
| jdstrand | ikey: hehe | 20:15 |
| zyga | ikey zombie event? | 20:15 |
| jdstrand | zyga: that is much easier on the eyes :) | 20:15 |
| ikey | zyga, 28 days later :P | 20:16 |
| ikey | yknow, rapid moving shoulder munchers | 20:16 |
| jdstrand | of course, where did my pending comments go... | 20:16 |
| zyga | ikey, you mean stress-eating during weekends? | 20:17 |
| zyga | ;-) | 20:17 |
| ikey | no i mean literal zombies :P | 20:17 |
| ikey | also its not "stress eating". its uhm.. *thinks*.. weekly hormone rebalance therapy. | 20:18 |
| ikey | yeaa... | 20:18 |
| zyga | "literal zombies" | 20:21 |
| * zyga turns the dishwasher on | 20:21 | |
| ikey | yeah they chase you and say things like "totally" until *you* groan | 20:21 |
| zyga | I think my kids are like zombies sometimes | 20:21 |
| zyga | jdstrand: after that PR I have spread test for layouts | 20:21 |
| ikey | probably a phone app to figure that one out.. ^^ | 20:21 |
| zyga | it's pushed, just waiting for the PR to land :) | 20:21 |
| zyga | jdstrand replied | 20:35 |
| zyga | actually edited my response, sorry | 20:37 |
| zyga | jdstrand if that's okay with you I will edit the symlink comment | 20:37 |
| zyga | eh | 20:38 |
| zyga | new golang broke -everything- | 20:38 |
| zyga | not a great tay | 20:38 |
| zyga | *day | 20:38 |
| zyga | jdstrand do you want me to add the examples you listed to unit tests? | 20:43 |
| jdstrand | zyga: please see me comment to your comment. yes, more tests please but note that I didn't enumerate everything in the review | 20:48 |
| zyga | jdstrand the one with 'more subtle' cannot be detected | 20:49 |
| zyga | as yaml will fold the old value and replace with the new one | 20:49 |
| zyga | as for remaining tests, I will add some more but the "bind-file" thing is identical in validation to "symlink" and those have a lot of tests already (though not added in that PR) | 20:50 |
| zyga | The case where the same source is treated differently is interesting, that is not handled yet | 20:51 |
| zyga | it will fail at runtime but it won't get caught by the validator | 20:51 |
| zyga | once master is fixed tomorrow I will add those | 20:51 |
| mup | PR snapcraft#1908 closed: tests: update tests to work in adt <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1908> | 20:54 |
| jdstrand | zyga: ok, so those are keys to a dictionary. That's fine then. we should have a test that shows only one happened imho | 21:04 |
| === ogasawara is now known as Guest91911 | ||
| mwhudson | hi when does snapd do the sd_notify thing to notify systemd that it has started up? | 22:49 |
| mwhudson | in particular wrt seeding on first boot | 22:52 |
| mwhudson | aha systemd.SdNotify("READY=1") | 22:52 |
| mwhudson | hm ok looks like it notifies before seeding is known to be done | 23:01 |
| mwhudson | hmm the idea of having snapd write the unit looks better i think | 23:03 |
| === Guest91911 is now known as ogasawara | ||
| === ogasawara is now known as Guest23352 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
