| mup | PR snapcraft#1879 opened: extractors: replace desktop file ids with paths <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1879> | 02:00 |
|---|---|---|
| niemeyer | Morning all | 05:42 |
| niemeyer | Saviq: I've added the additional machines you requested on Spread, should be accessible to you already | 05:42 |
| === chihchun_afk is now known as chihchun | ||
| Saviq | niemeyer: fantastic, thank you | 06:26 |
| mborzecki | morning | 06:31 |
| mup | PR snapd#4464 closed: overlord/snapstate: do a minimal sanity check on containers <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4464> | 07:40 |
| mvo_ | cachio: everything ready in the beta channel for validation. as yesterday no new snapd, just package updates (see http://people.canonical.com/~mvo/core-changes/html/beta/ for details) | 07:45 |
| mborzecki | mvo_: morning | 07:47 |
| mvo_ | hey mborzecki ! | 07:49 |
| mborzecki | mvo_: do you know if snapcraft also needs to do some work on https://forum.snapcraft.io/t/snap-service-start-ordering/1470/ ? | 07:49 |
| mborzecki | mvo_: that's also what pedronis suggested, what leaves me wondering if i should poke someone from the snapcraft | 07:50 |
| mborzecki | team | 07:50 |
| mvo_ | mborzecki: I think it does, it has a yaml schema for everything that can go into snapcraft.yaml. so the new things need to be added there iirc | 07:53 |
| mvo_ | mborzecki: you can poke sergiusens (at a sprint) or kalikiana | 07:53 |
| mborzecki | ok, thanks | 07:53 |
| mvo_ | mborzecki: probably relatively easy, you could give it a stab yourself | 07:53 |
| zyga-ubuntu | good morning | 07:55 |
| mborzecki | zyga-ubuntu: hey | 07:55 |
| zyga-ubuntu | how are you all feeling? :) | 07:55 |
| kalikiana | hey mborzecki | 07:58 |
| kalikiana | I can give you some pointers if needed | 07:59 |
| kalikiana | adding that should be pretty straightforward | 07:59 |
| kalikiana | assuming you'll want basically the same yaml as in the snap.yaml | 08:00 |
| sergiusens | mvo_ mborzecki we got guidance at the sprint that the user docs need to be written first before proceeding on features so a PR against the docs would be nice to see | 08:05 |
| zyga-ubuntu | sergiusens: interesting, thanks for sharing | 08:05 |
| * zyga-ubuntu enjoys morning coffee | 08:06 | |
| pstolowski | mornings! | 08:08 |
| zyga-ubuntu | o/ | 08:08 |
| mup | PR snapd#4492 closed: spread: try to enable Fedora once more <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4492> | 08:39 |
| mup | PR snapd#4504 opened: snap, wrappers: systemd WatchdogSec support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4504> | 08:39 |
| mborzecki | figured i might as well add support for the watchdog if i'm to update snapcraft and the docs | 08:40 |
| mvo_ | mborzecki: +1 | 08:44 |
| mup | PR snapd#4500 closed: snapstate: make no autorefresh message clearer <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4500> | 09:13 |
| zyga-ubuntu | 4499 needs a 2nd review | 09:13 |
| zyga-ubuntu | pstolowski: perhaps? | 09:14 |
| zyga-ubuntu | trivial | 09:14 |
| pstolowski | loooooking, but github is sooo slooow atm | 09:16 |
| * Chipaca waves | 09:16 | |
| zyga-ubuntu | mborzecki: does this need a gustavo approval? https://github.com/snapcore/snapd/pull/4487 | 09:17 |
| mup | PR #4487: cmd/snap: snap refresh --timer, hide --time <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487> | 09:17 |
| zyga-ubuntu | Chipaca: o/ \o \o/ | 09:17 |
| mborzecki | zyga-ubuntu: yes, probably | 09:17 |
| Chipaca | mvo_: I'd added the "sleep 1" thinking that the reason it wasn't seeing the messages in the journal was a race, when in the end it was git being a git | 09:17 |
| zyga-ubuntu | k | 09:17 |
| Chipaca | mvo_: so i was able to drop the sleep 1 \o/ | 09:17 |
| mborzecki | asked niemeyer to take a look at both #4487 and #4476 | 09:18 |
| mup | PR #4487: cmd/snap: snap refresh --timer, hide --time <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487> | 09:18 |
| mup | PR #4476: overlord/{snapstate,configstate}, daemon: introduce refresh.timer, fallback to refresh.schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4476> | 09:18 |
| pstolowski | uhm no github for me atm, anyone else having problems? | 09:22 |
| zyga-ubuntu | pstolowski: works for me | 09:24 |
| mvo_ | Chipaca: yeah, I noticed | 09:25 |
| * zyga-ubuntu solicits reviews for https://github.com/snapcore/snapd/pull/4471 | 09:25 | |
| mup | PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471> | 09:25 |
| mvo_ | mborzecki: I added a suggestion to the 4467, maybe a personal thing, but I found it slighly easier this way. please check it out. | 09:26 |
| mborzecki | mvo_: it's much cleaner indeed, thanks | 09:28 |
| Chipaca | hurray for enabling opensuse spread tests again, but … they're failing again? :-( | 09:33 |
| mvo_ | mborzecki: thank you | 09:37 |
| mvo_ | Chipaca: yeah, tests are a bit unstable again :/ | 09:37 |
| Chipaca | with the EOF thing I thought was my fault in the user pr! | 09:37 |
| Chipaca | that one was driving me crazy(er) | 09:37 |
| Chipaca | good luck :-D | 09:37 |
| mvo_ | mborzecki: thanks for working on 4504! quick question: aiui for watchdogSec to work the app must call sd_notify() which needs to talk to a system socket - does that mean this pr also needs apparmor rules so that the app can access this socket? | 09:39 |
| Chipaca | mvo_: hah! i just commented trying to point mborzecki along those lines :-D | 09:40 |
| Chipaca | get out of my head :-p | 09:40 |
| mborzecki | mvo_: yeah, this was mentioned by Chipaca in https://forum.snapcraft.io/t/expose-a-more-consistent-subset-of-systemds-service-directives/2268 | 09:40 |
| * mvo_ hugs Chipaca (from the inside) | 09:40 | |
| mborzecki | anways, i'm about to find out the hard way :) | 09:40 |
| mvo_ | mborzecki: haaha | 09:40 |
| * Chipaca installing every app in /var/cache/snapd/names to check for validation problems | 09:42 | |
| Chipaca | s|app|snap with type:app| | 09:43 |
| mvo_ | mborzecki: its slightly annoying that the NOTIFY_SOCKET is set via an env, it seems it is currently /run/systemd/notify it seems there is no grantee about this | 09:43 |
| === chihchun is now known as chihchun_afk | ||
| mvo_ | Chipaca: what is annoying is that 4503 failed three times already for different reasons :( | 09:49 |
| Chipaca | mvo_: if you've restarted it 3 times, then it's been restarted at least 5 | 09:53 |
| zyga-ubuntu | oh, I restarted it too | 09:55 |
| mvo_ | Chipaca: *weep* | 09:55 |
| mvo_ | lol | 09:55 |
| zyga-ubuntu | that's one unlucky bastard then | 09:55 |
| mvo_ | and also *moreweep* | 09:55 |
| zyga-ubuntu | maybe it will be around when we hit PR 10K | 09:55 |
| mup | PR #10: Update README.md <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/10> | 09:55 |
| Chipaca | we should have a 'carbon footprint per PR' competition | 09:55 |
| mvo_ | pr #100 | 09:55 |
| mup | PR #100: Ongoing work on the capability APIs <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/100> | 09:55 |
| mvo_ | pr #1000 | 09:55 |
| mup | PR #1000: debian: use sudo in setup of the proxy environment <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1000> | 09:55 |
| mvo_ | pr #1 | 09:56 |
| Chipaca | showoff | 09:56 |
| Chipaca | :-) | 09:56 |
| mvo_ | Chipaca: heh, pretty even, no? 10: you, 100: zyga, 1000: me | 09:56 |
| mvo_ | pr 1 | 09:56 |
| mvo_ | *pff* no pr 1? | 09:56 |
| Chipaca | nope | 09:57 |
| Chipaca | it was probably an issue | 09:57 |
| zyga-ubuntu | bug #1 ;-) | 09:57 |
| mup | Bug #1: Microsoft has a majority market share <canonical> <iso-testing> <microsoft> <package-qa-testing> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <LibreOffice:New> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Confirmed for ramvi> | 09:57 |
| mup | <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux:New> <Linux Mint:In Progress> <The Linux OS Project:In Progress> <Neobot:New> <Novabot:New> <OpenOffice:In Progress by lh-maviya> <ReactOS Core Operating System:Incomplete> <Tabuntu:Invalid by | 09:57 |
| mup | tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:Invalid> <Ubuntu Malaysia LoCo Team:In Progress by apogee> <Wine:Confirmed> <Ubuntu:Fix Released> <Arch Linux:New> | 09:57 |
| mup | <Baltix:Confirmed> <Debian:In Progress> <Fedora:Confirmed> <Fluxbuntu:Confirmed> <openSUSE:In Progress> <Tilix:New> <https://launchpad.net/bugs/1> | 09:57 |
| * zyga-ubuntu gets back to work | 09:57 | |
| Saviq | jdstrand: fwiw, it's just a case of installing xrdp and a desktop environment, and putting the session name (like "mate-session") in ~/.xsession | 10:03 |
| zyga-ubuntu | kind ping about 4471 | 10:15 |
| zyga-ubuntu | it's blocking everything for me | 10:15 |
| zyga-ubuntu | please halp | 10:15 |
| ogra | mvo_, i have some weird behaviour of core on one of my boards here, seems it auto-refreshed to the beta one even though it tracks edge | 10:17 |
| mvo_ | ogra: what do you see in "snap changes"? | 10:19 |
| ogra | mvo_, https://paste.ubuntu.com/26409733/ | 10:19 |
| ogra | tracking: edge | 10:19 |
| ogra | installed: 16-2.30 (3872) 71MB core | 10:19 |
| mvo_ | ogra: I switched edge/beta around a bit in the morning, so maybe you see effects from this | 10:19 |
| ogra | in the morning ? ... thats 3:30am ! | 10:20 |
| mvo_ | ogra: this an non i386/amd64 system, right? | 10:20 |
| ogra | (admittedly in technical sense that is "morning" indeed :P ) | 10:20 |
| ogra | mvo_, armhf | 10:21 |
| mvo_ | ogra: heh :) yeah, I did not mess around with things at this time | 10:21 |
| mvo_ | ogra: when is the next auto-refresh (snap refresh --time)? | 10:21 |
| ogra | $ snap refresh --time | 10:21 |
| ogra | schedule: 00:00-05:59/6:00-11:59/12:00-17:59/18:00-23:59 | 10:21 |
| ogra | last: 2018-01-18T06:21:00Z | 10:21 |
| ogra | next: 2018-01-18T15:55:00Z | 10:21 |
| mvo_ | ogra: I wonder if the next auto-refresh will push you back to a +git version | 10:21 |
| ogra | the revision is lower now ... | 10:22 |
| ogra | (in edge( | 10:22 |
| ogra | i could run a manual refresh ... | 10:22 |
| mvo_ | ogra: yeah, this is what I did this morning, moved edge back to a git version | 10:22 |
| mvo_ | ogra: yeah, just snap refresh should bring you back. I think its "expected" (in an unexpected way) | 10:22 |
| ogra | (should not be different from auto, right ?) | 10:22 |
| ogra | and so it does ... | 10:23 |
| ogra | Make snap "core" (3852) available to the system | 10:23 |
| ogra | ... | 10:23 |
| mvo_ | ogra: i.e. yesterday edge was "2.30" and there was a core snap build in the night which also had 2.30, then later your board refrehsed to 2.30 and in my morning I pushed edge back into +git land and now it should refresh to this (does that make sense) | 10:23 |
| ogra | yeah, makes complete sense | 10:24 |
| ogra | thanks for clearing the myth :) | 10:24 |
| mvo_ | ogra: its all (more) confusing because no auto-builds, everything need to be manually approved for building | 10:25 |
| ogra | (i only noticed because i had put the revision into a release note for a customer ... and was just shocked that i typoed 3852 for 3872 when i looked at it this morning :P ) | 10:25 |
| ogra | mean that the revisions were so similar :) | 10:26 |
| mvo_ | heh | 10:26 |
| mvo_ | ok | 10:26 |
| ads20000 | Speaking of `beta`s...the beta is a different revision to candidate/stable but the same version number? Seems confusing...what happened there? | 10:51 |
| ads20000 | Was it just because you were switching them around? : | 10:51 |
| ads20000 | * :P | 10:51 |
| ogra | version numbers in snaps are shallow | 10:54 |
| ogra | they are just a string in snapcraft.yaml ... | 10:54 |
| ogra | revisions are what counts | 10:54 |
| Chipaca | well | 10:54 |
| ogra | that said ... | 10:54 |
| Chipaca | versions are for human consumption :-) | 10:55 |
| ogra | it is likely the content is actually the same in the case of core | 10:55 |
| Chipaca | and are merely descriptive | 10:55 |
| ogra | (unless some of the additional packages changed ... the core snapcraft.yaml actually generates the version from the snapd version) | 10:55 |
| zyga-ubuntu | Chipaca: it failed again | 11:16 |
| zyga-ubuntu | on fedora | 11:16 |
| mup | PR snapd#4503 closed: osutil/sys: ppc has 32-bit getuid already <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4503> | 11:27 |
| zyga-ubuntu | mvo_: was it green in the end/ | 11:31 |
| mvo_ | zyga-ubuntu: no, i merged it anyway | 11:31 |
| mvo_ | zyga-ubuntu: I need to get a deb build to see if it fixes the build failure | 11:32 |
| Chipaca | "contact develper" | 11:33 |
| * Chipaca looks for a brown paper bag | 11:33 | |
| mvo_ | *cough* | 11:33 |
| Chipaca | and i only realised when writing https://forum.snapcraft.io/t/snapd-is-now-doing-a-little-sanity-check-on-install/3566 | 11:34 |
| zyga-ubuntu | hmm? | 11:47 |
| zyga-ubuntu | what is contact developer about? | 11:47 |
| mvo_ | zyga-ubuntu: "develper" | 11:51 |
| zyga-ubuntu | ah | 11:51 |
| zyga-ubuntu | typo | 11:51 |
| jdstrand | zyga-ubuntu: fyi, I reviewd 4472 | 11:54 |
| jdstrand | reviewed even | 11:54 |
| zyga-ubuntu | thank you!@ | 11:58 |
| zyga-ubuntu | thanks! I'll update the rules and merge | 11:59 |
| zyga-ubuntu | jdstrand: I'm working on layouts now, while they won't work (apparmor) they are now applied to mount profile, the PR will need some discussion but it looks like a good start | 11:59 |
| * pstolowski lunch | 12:01 | |
| jdstrand | greyback: ok, so, in thinking about this, I think we want to adjust the *mir*ConnectedPlugAppArmor policy to have '/{dev,run}/shm/\#* mrw,', then have your snap plugs mir and x11 | 12:02 |
| jdstrand | greyback: the idea is that if your snap snips xwayland, it is a mir client, so needs to 'plugs: [mir]', then the thing that talks to x11 needs to 'plugs: [x11]' | 12:04 |
| greyback | jdstrand: xwayland is a wayland client, it's not using the mirclient libraries | 12:05 |
| jdstrand | greyback: this is slightly odd because the app is really the slot for x11 though | 12:05 |
| greyback | yeah I know | 12:05 |
| jdstrand | greyback: the shm access is really a mir thing though, no? | 12:05 |
| greyback | is having a separate xwayland snap, which has the x11 slot, too much? | 12:06 |
| greyback | jdstrand: that is something I've never quite figured out | 12:06 |
| greyback | perhaps I should, to get things straight | 12:06 |
| jdstrand | greyback: in terms of policy, the shm access is only in mir | 12:06 |
| greyback | true | 12:07 |
| jdstrand | I was extrapolating from there when I suggested adjusting mir | 12:07 |
| greyback | yep, understood | 12:07 |
| jdstrand | I also understand the the shm access within the context of mir is considered safe | 12:07 |
| greyback | let me ask around and try verify that | 12:08 |
| greyback | or at least figure out exactly what in /dev/shm is needed | 12:08 |
| greyback | and by what | 12:08 |
| jdstrand | greyback: ftr, having a separate xwayland snap would not be required. you could embed it; your snap would just slots x11 (assuming we had that policy) | 12:09 |
| jdstrand | so you slot it to yourself | 12:09 |
| jdstrand | but, let me read something back you said a minute ago | 12:09 |
| greyback | I didn't know you could slot to yourself | 12:09 |
| greyback | that would do the trick | 12:10 |
| jdstrand | let's assume that xwayland is one command in your snap and chromium another | 12:10 |
| jdstrand | (for clarity) | 12:10 |
| jdstrand | if xwaland is a wayland client, it should plugs wayland (let's not worry about shm for the moment) | 12:10 |
| jdstrand | chromium is not a wayland client, so it should plugs x11 | 12:11 |
| jdstrand | xwayland command is providing x11 | 12:11 |
| jdstrand | so xwayland slots x11 | 12:11 |
| jdstrand | so | 12:11 |
| jdstrand | the x11 interface grows the slot side (perhaps we can put the shm access in PermanentSlotAppArmor...) | 12:12 |
| greyback | right so ar | 12:12 |
| greyback | far | 12:12 |
| jdstrand | the you have | 12:12 |
| jdstrand | name: foo | 12:12 |
| jdstrand | apps: | 12:12 |
| jdstrand | chromium: | 12:13 |
| jdstrand | plugs: [ x11 ] | 12:13 |
| jdstrand | xwayland: | 12:13 |
| jdstrand | slots: [ x11 ] | 12:13 |
| jdstrand | plugs: [ wayland ] | 12:13 |
| jdstrand | greyback: I think that aligns with how you described how xwayland works | 12:14 |
| mvo_ | Chipaca: and another ppc failure: https://paste.ubuntu.com/26410328/ - this time in boltdb | 12:14 |
| greyback | jdstrand: yes that makes sense | 12:14 |
| greyback | I'll give that a go | 12:15 |
| greyback | jdstrand: thanks for the advice | 12:15 |
| jdstrand | greyback: *today* a full on Xorg xserver wouldn't be able to run with the slot policy you right for x11, but that is ok. if that ever comes up, we can adjust the policy. this way you can focus just on the xwayland bits | 12:15 |
| mup | PR snapd#4505 opened: interfaces/mount,snap: early support for snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4505> | 12:15 |
| jdstrand | right? | 12:15 |
| jdstrand | s/right/write/? | 12:16 |
| jdstrand | (what an ugly typo) | 12:16 |
| zyga-ubuntu | Chipaca: ^ early PR for layouts, | 12:16 |
| zyga-ubuntu | mvo_: ^ | 12:16 |
| mvo_ | ta | 12:16 |
| greyback | jdstrand: heh, silly english with homonyms | 12:16 |
| zyga-ubuntu | small, just for quick feedback on the idea | 12:17 |
| jdstrand | greyback: for your testing, perhaps just tuck the shm access into the PermamentSlotAppArmor bit of x11 and add a TODO comment to investigate. before we merge, you investigate. it might be that we adjust mirConnectedPlugAppArmor to have the shm access and xwayland to plugs: [ wayland, mir ] since *this* wayland client happens to need it cause of some mir thing | 12:19 |
| jdstrand | obviously depending on your investigation | 12:19 |
| greyback | jdstrand: *nod* | 12:19 |
| greyback | that's a plan | 12:19 |
| jdstrand | greyback: ok, sorry for the lagginess on this. I'll be back from sprinting next week | 12:19 |
| greyback | jdstrand: not at all, thank you for the help | 12:20 |
| jdstrand | np | 12:20 |
| mup | PR snapd#4506 opened: iterate on the container sanity check: patch typo, move to snap, add to pack <Created by chipaca> <https://github.com/snapcore/snapd/pull/4506> | 12:51 |
| zyga-ubuntu | Chipaca: sorry to bug you but could you please (perhaps) split that PR into distinct commits that can be reviwed earliy | 12:55 |
| zyga-ubuntu | *easily | 12:55 |
| zyga-ubuntu | Chipaca: maybe one for typo, one for mv, more for extra features | 12:56 |
| zyga-ubuntu | otherwise that's a 1K diff | 12:56 |
| Chipaca | zyga-ubuntu: I can. Most of the diff is the move from snapstate to snap, i guess | 12:56 |
| Chipaca | lemme close that | 12:56 |
| Chipaca | before it chomps up a travis | 12:56 |
| zyga-ubuntu | thanks | 12:57 |
| zyga-ubuntu | oh drat, standup | 12:57 |
| zyga-ubuntu | ... quick coffeee | 12:57 |
| zyga-ubuntu | eeeeeeeeeeee | 12:57 |
| mup | PR snapd#4506 closed: iterate on the container sanity check: patch typo, move to snap, add to pack <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4506> | 12:58 |
| Chipaca | zyga-ubuntu: there you go | 13:01 |
| mup | PR snapd#4506 opened: iterate on the container sanity check: patch typo, move to snap, add to pack <Created by chipaca> <https://github.com/snapcore/snapd/pull/4506> | 13:02 |
| mup | PR snapd#4499 closed: packaging/14.04: move linux-generic-lts-xenial to recommends <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4499> | 13:06 |
| mborzecki | cachio: do you the version of fedora kernel used on linode? | 13:16 |
| * kalikiana time for lunch | 13:32 | |
| zyga-ubuntu | woot, one branch merged :) | 13:34 |
| mup | PR snapd#4472 closed: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4472> | 13:35 |
| zyga-ubuntu | pstolowski: about 4358, how to approach it? | 13:35 |
| zyga-ubuntu | pstolowski: any advice on how to review it? | 13:35 |
| tyhicks | zyga-ubuntu: hey - I never saw if you got the apparmor label query issue straightened out? | 13:40 |
| zyga-ubuntu | tyhicks: yes and no | 13:41 |
| zyga-ubuntu | tyhicks: I drowned in dbus, iteration is a pain | 13:41 |
| zyga-ubuntu | tyhicks: but mvo added a label that jdstrand suggested that fixed the problem | 13:42 |
| zyga-ubuntu | tyhicks: (labeling the snap userd service as unconfined) | 13:42 |
| tyhicks | zyga-ubuntu: do I need to fix a bug caused by that upstream change? | 13:42 |
| zyga-ubuntu | tyhicks: it looks like the bug is real but it's not a pressing issue for us now | 13:42 |
| zyga-ubuntu | tyhicks: I think so, it will affect other things | 13:42 |
| zyga-ubuntu | (not just snapd) | 13:42 |
| tyhicks | zyga-ubuntu: what's a simple reproducer? attempt to query a label of a peer connection in bionic? | 13:43 |
| zyga-ubuntu | tyhicks: on bionic, revert mvo's change (I'll give you a link in a moment), install gimp (probably works with other snaps but this works for sure); snap run --shell gimp; xdg-open http://example.org | 13:44 |
| zyga-ubuntu | tyhicks: the logs indicate that there's no peer label information and thus the rule for peer=unconfined doesn't apply and the activation is denied | 13:44 |
| pstolowski | zyga-ubuntu, it would probably make sense to start by getting the understanding of the associated spread test and its 2 test snaps and their hooks | 13:44 |
| zyga-ubuntu | tyhicks: it's *just* activation that is broken | 13:44 |
| zyga-ubuntu | tyhicks: once activated it works correctly | 13:45 |
| zyga-ubuntu | pstolowski: thank you, let's see | 13:45 |
| zyga-ubuntu | tyhicks: I attached logs on the forum if you need those | 13:46 |
| zyga-ubuntu | (and some advice on how to collect them) | 13:46 |
| zyga-ubuntu | tyhicks: I think activation should happen regardless and not bail out on lack of the label | 13:46 |
| zyga-ubuntu | tyhicks: or activation should carry implicit confinement "unconfined" | 13:47 |
| zyga-ubuntu | tyhicks: reading the code it seems that activation should fail (by design) only on explicit deny rules | 13:47 |
| zyga-ubuntu | tyhicks: that was the intent | 13:47 |
| zyga-ubuntu | tyhicks: but this is not how it behaves | 13:47 |
| pstolowski | zyga-ubuntu, then repo.go and doConnect handler. policy and connection.go changes last | 13:48 |
| tyhicks | zyga-ubuntu: thanks - that helps a lot to understand the problem | 13:51 |
| tyhicks | zyga-ubuntu: I have some ideas about how to do this correctly | 13:51 |
| zyga-ubuntu | tyhicks: the branch to revert, once it lands, is https://github.com/snapcore/snapd/pull/4495 | 13:54 |
| mup | PR #4495: data/dbus: add AssumedAppArmorLabel=unconfined <Created by mvo5> <https://github.com/snapcore/snapd/pull/4495> | 13:54 |
| jdstrand | tyhicks: bug #1742687 | 13:55 |
| mup | Bug #1742687: Launching URLs in snapped applications no longer works in 18.04 <AppArmor:Invalid> <D-Bus:New> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1742687> | 13:55 |
| seb128 | jdstrand, zyga-ubuntu, is there really a bug there? to be it looks like that dbus/apparmor enforces more checking that it used to and that the autoactivated services that AssumedAppArmorLabel info by design | 14:05 |
| * zyga-ubuntu lunch | 14:06 | |
| zyga-ubuntu | seb128: yes, I think so | 14:06 |
| zyga-ubuntu | seb128: reading the code and patch descriptions seems to imply it should not behave this way | 14:06 |
| zyga-ubuntu | seb128: I'll defer to tyhicks's decision | 14:06 |
| seb128 | zyga-ubuntu, you should report it upstream, they might just fix it for us | 14:07 |
| zyga-ubuntu | seb128: yeah, I can do that, good idea | 14:08 |
| seb128 | zyga-ubuntu, thanks | 14:10 |
| zyga-ubuntu | ok, let's review things | 14:31 |
| zyga-ubuntu | then let's file that bug | 14:31 |
| zyga-ubuntu | and then, let's ... not sure yet :) | 14:31 |
| kalikiana | re | 14:31 |
| zyga-ubuntu | mborzecki: https://github.com/snapcore/snapd/pull/4505 | 14:31 |
| mup | PR #4505: interfaces/mount,snap: early support for snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4505> | 14:31 |
| zyga-ubuntu | mborzecki: would the group / user thing be a problem on arch? | 14:31 |
| mborzecki | zyga-ubuntu: there's a 'nobody' group around here only | 14:33 |
| mborzecki | zyga-ubuntu: the uids in tests are hardcoded too | 14:37 |
| mborzecki | zyga-ubuntu: maybe it would be best to guess nobody/nogroup the same way we deal with directories | 14:39 |
| mborzecki | zyga-ubuntu: li.Group is coming from the snap right? | 14:40 |
| zyga-ubuntu | mborzecki: hymm | 14:41 |
| zyga-ubuntu | mborzecki: yes | 14:42 |
| zyga-ubuntu | mborzecki: I think that I need to tweak that to contain a fixed mapping | 14:42 |
| zyga-ubuntu | mborzecki: this mapping must make sense on the inside, not for classic host | 14:42 |
| zyga-ubuntu | mborzecki: and we only support 'root' and 'nobody' | 14:42 |
| zyga-ubuntu | Chipaca: did you see 4506 failures? | 14:56 |
| Chipaca | zyga-ubuntu: i saw your comment | 14:56 |
| Chipaca | i'll dig in a bit | 14:56 |
| Chipaca | (that pr is a backburner one) | 14:57 |
| jdstrand | seb128 (cc zyga-ubuntu and tyhicks): tyhicks and I talked about it. it is fine that dbus is offering more mediation, but the way it is doing it is a bit weird. tyhicks will comment in the bug | 14:57 |
| zyga-ubuntu | k | 14:57 |
| seb128 | jdstrand, thanks | 14:58 |
| * kalikiana really, really hates regex today | 15:24 | |
| * kalikiana getting more tea | 15:24 | |
| zyga-ubuntu | kalikiana: regex is your friend, imagine if you had to do it by hand | 15:31 |
| zyga-ubuntu | kalikiana: btw, do you knof about regex derivatives? | 15:32 |
| zyga-ubuntu | kalikiana: I found that interesting a while back | 15:32 |
| zyga-ubuntu | kalikiana: https://en.wikipedia.org/wiki/Brzozowski_derivative | 15:32 |
| mvo_ | Chipaca: looks like we need https://paste.ubuntu.com/26411304/ in upstream bolt (funny enough this seems to be not fixed in the coreos fork either - ppc seems to be not super popular) | 15:36 |
| zyga-ubuntu | mvo_: before it blows up, can we check if this builds on other fringe arches? | 15:36 |
| mvo_ | zyga-ubuntu: which one do you have in mind? | 15:38 |
| zyga-ubuntu | mvo_: s390 and all the other ones nobody has but will block us in next package build in the archive | 15:41 |
| Chipaca | ooh, just got a very helpful email, trying to sell me email listings of redhat users | 15:46 |
| kalikiana | zyga-ubuntu: hmmm I did not know that! will have to read up on it | 15:47 |
| * Chipaca considers forwarding it to info@centos.org :-p | 15:47 | |
| zyga-ubuntu | kalikiana: it's not useful very often as it's not something implemented in any standard library I know | 15:50 |
| zyga-ubuntu | kalikiana: but since I love that topic, I wanted to share it :) | 15:50 |
| zyga-ubuntu | Chipaca: how much? | 15:50 |
| kalikiana | zyga-ubuntu: usually I adore the concept as well, just not today when I'm fighting with a tricky case :-P | 15:51 |
| zyga-ubuntu | kalikiana: what is the case? I will be your garden dwarf friend | 15:51 |
| zyga-ubuntu | kalikiana: explain the problem to me | 15:52 |
| cachio | niemeyer, when you have some time, could you please take a look to https://github.com/snapcore/spread/pull/49 | 15:54 |
| mup | PR spread#49: send keepalive packets every 10 seconds to avoid losing the connection <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/49> | 15:54 |
| kyrofa | kalikiana, I also find rubular.com to be helpful | 15:55 |
| zyga-ubuntu | pstolowski: some early feedback on 4358 | 15:55 |
| Chipaca | zyga-ubuntu: no idea | 15:55 |
| zyga-ubuntu | pstolowski: marked as requeste changes because I'm still going through it and I have more questions pending | 15:55 |
| zyga-ubuntu | pstolowski: sorry about that but if you follow the diff from the end and go up the order of my questions will be more logical | 15:56 |
| * zyga-ubuntu reads diffs from the other end usually | 15:56 | |
| pstolowski | zyga-ubuntu, ty! | 15:56 |
| pstolowski | :) | 15:56 |
| zyga-ubuntu | can I ask for firmer vote on https://github.com/snapcore/snapd/pull/4502 | 15:57 |
| mup | PR #4502: interfaces/builtin: add support for content "source" section (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4502> | 15:57 |
| zyga-ubuntu | pstolowski: sorry for the needs fixing, I don't see anything strongly broken, just want to understand it | 15:57 |
| zyga-ubuntu | pstolowski: what's the idea with the new interface btw? are we adding a new interface designed for testing? | 15:57 |
| pstolowski | zyga-ubuntu, sure, no worries | 15:57 |
| Chipaca | here's an initeresting test to do: set up a long loop that installs and removes the same snap. compare how long it takes to install the 2nd time, vs the Nth time. | 15:58 |
| zyga-ubuntu | Chipaca: what's the result you got? | 15:58 |
| pstolowski | zyga-ubuntu, yes, this is something I brought up on the standup (limited testatibility with existing ifaces) and Gustavo suggested to created a new interface just for testing | 15:58 |
| kalikiana | zyga-ubuntu, kyrofa: I'm staring at this `\A(on)\s+([^,\s](?:,?[^,\s]+)*)(\s(to)\s+([^,\s](?:,?\S+)*)|)\Z` which rejects "on i386, ubuntu to armhf" as invalid. due to the extra space after the comma. Except we *want* to parse it so we can show a special error. Now if I remove the change the two `[^,\s]` to `[^,]` it parses but the groups are merged in one | 15:58 |
| Chipaca | on this machine, subjectively (because i didn't start out to measure this) it looks like as changes hit 10k, things get a lot slower | 15:58 |
| zyga-ubuntu | pstolowski: should it be in a different file name? | 15:58 |
| zyga-ubuntu | pstolowski: er, should the file have a different name | 15:58 |
| * kalikiana finds https://regex101.com/ quite nice but sadly it can't extrapolate the intended use case | 15:59 | |
| zyga-ubuntu | pstolowski: test_... go is not usually built, rightt? | 15:59 |
| Chipaca | I don't think I'll have time to run that test today, but i might tomorrow :-) | 15:59 |
| zyga-ubuntu | kalikiana: looking | 15:59 |
| pstolowski | zyga-ubuntu, i'm open to renaming it. I if the only expectation is about display name, it should clearly indicate it's not an interface for normal use | 15:59 |
| pstolowski | d/I if/ | 16:00 |
| zyga-ubuntu | pstolowski: yes, i would add some provisions for hiding it (though not needed now) | 16:00 |
| zyga-ubuntu | kalikiana: man, that could use the mode that enables whitespace and comments | 16:01 |
| zyga-ubuntu | kalikiana: did you think about using a lexer and parser to make things like that easier to follow? | 16:01 |
| zyga-ubuntu | kalikiana: can you please remind me what \A and \Z does in the engine you are working with (I presume python) | 16:02 |
| Chipaca | zyga-ubuntu: start and end of string | 16:03 |
| kalikiana | zyga-ubuntu: start and end of the string | 16:03 |
| kalikiana | and yes, it's Python | 16:03 |
| zyga-ubuntu | kalikiana: are those different from ^ and $? | 16:04 |
| Chipaca | zyga-ubuntu: the m modifier changes ^ and $ to start of lines inside the string, so you need a bigger anchor | 16:04 |
| zyga-ubuntu | ah | 16:04 |
| zyga-ubuntu | I see | 16:04 |
| Chipaca | or was it the s modifier | 16:04 |
| Chipaca | one of 'em two | 16:04 |
| zyga-ubuntu | I think it's 'm' | 16:04 |
| zyga-ubuntu | kalikiana: ok and the (?: ) syntax, what does that introduce? | 16:04 |
| kalikiana | zyga-ubuntu: it ignores the group in the results | 16:05 |
| zyga-ubuntu | ok, | 16:05 |
| zyga-ubuntu | kalikiana: that's dangerous perhaps | 16:05 |
| zyga-ubuntu | kalikiana: it can cause states to be combined in the resulting DFA | 16:05 |
| zyga-ubuntu | I'm not sure how much nfa->dfa action happens in python tho | 16:05 |
| * zyga-ubuntu experiments | 16:05 | |
| Chipaca | zyga-ubuntu: it's like () but without capture | 16:05 |
| Chipaca | zyga-ubuntu: which is nice, because (foo)+ is weird | 16:06 |
| zyga-ubuntu | perfect, thank you | 16:06 |
| zyga-ubuntu | kalikiana: and what would you like this to match, in geral | 16:11 |
| zyga-ubuntu | *general | 16:11 |
| zyga-ubuntu | kalikiana: do you have a spec of what is valid (in english) | 16:11 |
| zyga-ubuntu | kalikiana: I'll be back, I need to walk outside for an hour, see you later (just write the spec please) | 16:14 |
| kalikiana | zyga-ubuntu: enjoy! | 16:15 |
| Chipaca | mvo_: I subscribed you to #1744113 because I thought you might have something to add to the discussion | 16:16 |
| mup | Bug #1744113: should the /names endpoint include kernels, gadgets, cores? <Snap Store:New> <https://launchpad.net/bugs/1744113> | 16:16 |
| kalikiana | kyrofa: if you wanna have a look wrt the refactor, to re-uses on now in snapcraft#1800 - aside from my fighting with the regex the code works | 16:19 |
| mup | PR snapcraft#1800: grammar: on..to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1800> | 16:19 |
| Chipaca | mvo_: dear IT worker, Good work. | 16:22 |
| Chipaca | mvo_: that doesn't happen often! :-) | 16:22 |
| mup | PR snapd#4336 closed: spread.yaml: add fedora 27 <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4336> | 16:22 |
| kalikiana | kyrofa: I've found an interesting problem btw. having both `to armhf` and `on i386 to armhf` will be counted as duplicates. I'm not sure how to address that... the refactoring is turning out to be a little less straightforward | 16:23 |
| kyrofa | kalikiana, well they kind of are, aren't they? | 16:24 |
| kyrofa | It's possible for them both to match | 16:25 |
| kyrofa | elopio, what's on your docket for today? Looks like I owe you a few reviews | 16:28 |
| elopio | kyrofa: I want to finish collecting all the existing translations for the repo, and start the docs that Sergio requested. | 16:30 |
| elopio | kyrofa: I am on vacations tomorrow, so it would be nice to finish the PRs today too. | 16:30 |
| kalikiana | kyrofa: I found myself trying out `on amd64 to amd64` because why not, and that's an error. Which is probably fine since it's somewhat pointless. But separate `on amd64` statements probably do make sense in some cases. | 16:31 |
| cachio | zyga-ubuntu, please take a look to #4351 when you have a time | 16:33 |
| mup | PR #4351: tests: new test to validate location control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4351> | 16:33 |
| blackboxsw | good day folks, I'm looking at creating a snapd/seed directory for curtin & cloud-init and wanted to chat about what I might be missing. Is it preferable for me to start a forum post for that? | 16:34 |
| * kalikiana going to wrap up for today in a bit | 16:40 | |
| kyrofa | kalikiana, curious to hear what cases | 16:41 |
| kyrofa | I can't think of any cases where they couldn't be merged | 16:42 |
| kyrofa | Hahaha snapcraft#1877 is hilarious | 16:44 |
| mup | PR snapcraft#1877: tests: move test files out of the snapcraft dir <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1877> | 16:44 |
| kyrofa | Easiest review ever, close my eyes and +1 | 16:44 |
| kyrofa | elopio, any chance you made sure autopkgtests ran correctly as well (since those are effected by this as well)? | 16:45 |
| kalikiana | kyrofa: Yeah. Arguably it's totally okay to fail like that. I just wanted to be sure to bring it up. Could still add that later in any case. | 16:47 |
| blackboxsw | also quick question on snap auto-import. Is this command line utility which is actually searching for /var/lib/snapd/seed ? | 16:48 |
| kyrofa | kalikiana, yeah it's part of the initial yaml spec, which may not grow quite as well as we would hope | 16:48 |
| kyrofa | Not yaml spec, sorry, grammar spec | 16:48 |
| elopio | kyrofa: we can get the bot to do that | 16:48 |
| kyrofa | elopio, oh wait, amd64 is back huh? | 16:48 |
| kyrofa | elopio, I've just been assuming everything was still down | 16:49 |
| elopio | snappy-m-o autopkgtest 1877 xenial:amd64 | 16:49 |
| snappy-m-o | Computer says nooo. See logs for details: | 16:49 |
| snappy-m-o | Command '['/tmp/tmp02uqh_h1/retry_autopkgtest.sh', '1877', 'xenial:amd64']' returned non-zero exit status 1 | 16:49 |
| kyrofa | :( | 16:49 |
| mvo_ | Chipaca: sure, looking | 16:52 |
| mvo_ | Chipaca: re dear it works> where did you see that? | 16:53 |
| Chipaca | mvo_: #1743079 | 16:53 |
| mup | Bug #1743079: apparmor exit code 123 <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1743079> | 16:53 |
| kyrofa | elopio, I assume you have access to those logs? | 16:54 |
| elopio | kyrofa: yes, checking. | 16:55 |
| elopio | It would be more useful if the bot made a summary of the exception, instead of just exit 1 | 16:55 |
| mvo_ | Chipaca: haha - right | 16:59 |
| mvo_ | Chipaca: I guess I will make this my new job title "IT worker" | 17:00 |
| * Chipaca bbiab | 17:02 | |
| mup | PR snapcraft#1874 closed: kbuild: pick up CROSS_COMPILE only if it's not empty <Created by piso77> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1874> | 17:03 |
| elopio | kyrofa: it's replying with a 500, so not yet. | 17:03 |
| elopio | I'll give them a try here. | 17:04 |
| kyrofa | Uh oh | 17:04 |
| cjwatson | kyrofa: Surprising that GH doesn't handle that. I fixed that kind of thing in LP a while back AFAIK (https://bugs.launchpad.net/turnip/+bug/1712754) | 17:21 |
| mup | Bug #1712754: git diffs do not track renames <canonical-is> <turnip:Fix Released by cjwatson> <https://launchpad.net/bugs/1712754> | 17:21 |
| zyga-ubuntu | back now | 17:22 |
| zyga-ubuntu | cachio: approved | 17:24 |
| cachio | zyga-ubuntu, tx | 17:24 |
| blackboxsw | 17:38 | |
| zyga-ubuntu | so now that we have slack | 17:38 |
| zyga-ubuntu | is there a slack for snappy? | 17:38 |
| zyga-ubuntu | hmm | 17:39 |
| mup | PR snapd#4507 opened: advisor: use forked bolt to make it work on ppc <Created by mvo5> <https://github.com/snapcore/snapd/pull/4507> | 17:53 |
| kyrofa | elopio, I really only have one issue with snapcraft#1879 | 17:55 |
| mup | PR snapcraft#1879: extractors: replace desktop file ids with paths <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1879> | 17:55 |
| lotuspsychje | good evening to all | 18:15 |
| lotuspsychje | i have a wish for a snap command, whats the prefered way to do this? bug/wishlist? | 18:16 |
| zyga-ubuntu | lotuspsychje: try opening a forum topic on forum.snapcraft.io | 18:16 |
| lotuspsychje | zyga-ubuntu: ok thank you | 18:16 |
| zyga-ubuntu | lotuspsychje: pleasure :) | 18:17 |
| lotuspsychje | zyga-ubuntu: https://forum.snapcraft.io/t/req-snap-list-command-to-see-latest-added-snaps/3581 | 18:26 |
| zyga-ubuntu | lotuspsychje: nice! I commented alreay | 18:28 |
| zyga-ubuntu | *already | 18:28 |
| lotuspsychje | zyga-ubuntu: nice thank you! | 18:29 |
| lotuspsychje | zyga-ubuntu: sudo snap find lists a few but not all right | 18:37 |
| zyga-ubuntu | lotuspsychje: yes, those are "curated snaps" (not really curated much ATM) | 18:37 |
| zyga-ubuntu | lotuspsychje: but a feed of recently added or refreshed snaps would be interesting | 18:37 |
| lotuspsychje | zyga-ubuntu: atm i always have to go to the store website and filter recently added | 18:39 |
| mvo_ | Chipaca: my bbolt (coreos fork) PR for fixing ppc got merged within 30min, that is quite impressive | 18:42 |
| Chipaca | mvo_: niice | 19:05 |
| Chipaca | mvo_: tag me on the pr, i'll look at it later tonight | 19:05 |
| Chipaca | bye for now | 19:05 |
| Chipaca | mvo_: i mean on the pr to move to the fork, if there is one :-) | 19:05 |
| smiso | hi: Any one who any ideeas how to persistent add ip forwarding to ubuntu core? | 19:29 |
| zyga-ubuntu | smiso: hey | 19:30 |
| zyga-ubuntu | smiso: you can implement that in a snap that uses the network-control interface | 19:30 |
| zyga-ubuntu | let me check | 19:30 |
| zyga-ubuntu | smiso: you may need either or both network-control and firewall-control | 19:31 |
| zyga-ubuntu | and then you should be able to set that up yourself (in your snap) | 19:31 |
| zyga-ubuntu | I don't think we offer any default way to manage that today | 19:31 |
| zyga-ubuntu | only as interfaces to snap applications | 19:31 |
| cachio | zyga-ubuntu, any idea why netlink-audit interface could be denying the connection https://paste.ubuntu.com/26412541/ | 19:53 |
| cachio | zyga-ubuntu, this is executed with the interface connected https://github.com/sergiocazzolato/snapd/blob/tests-interface-netlink-audit/tests/lib/snaps/test-snapd-netlink-audit/bin/bind | 19:58 |
| Snapdragon | Hello | 21:31 |
| === epod is now known as luk3yx | ||
| blackboxsw | hrm. snap known --remote model series=16 model=generic-classic brand-id=generic returns an ill-formed yaml file for sign-key-sha3-384 value the multi-line value doesn't use | 22:46 |
| blackboxsw | nevermind.... not supposed to be yaml | 22:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!