| mborzecki | morning | 05:20 |
|---|---|---|
| mvo | good morning! and yay, only 2 pages of open PRs :) | 06:35 |
| zyga | Good morning | 06:36 |
| zyga | I had a dream about a raspberry pi, booting over usb into uboot sent from a separate computer, then loading kernel and initrd over lan and booting into initrd for testing | 06:37 |
| zyga | Is that normal? | 06:37 |
| zyga | I will start by booting Fedora and testing the update | 06:39 |
| mvo | hey zyga ! good morning | 06:40 |
| mborzecki | zyga: mvo: hey | 06:43 |
| mvo | hey mborzecki | 06:43 |
| mborzecki | zyga: the lan part is doable (now even?), don't know about uboot from usb though | 06:45 |
| mvo | xnox: speaking of empty etc, may I interesst you in LP 1736744 | 06:50 |
| mvo | xnox: one tiny step forward (one less file there) | 06:50 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:03 |
| mborzecki | pstolowski: hey | 07:04 |
| zyga | mborzecki: yes, totally | 07:16 |
| mborzecki | zyga: heh, the dnf command in snapd page in bodhi does not install anything here, i guess mirrors aren't synced yet | 07:17 |
| zyga | Aha, I’ll check soon | 07:17 |
| zyga | Janek goes for a school trip | 07:17 |
| zyga | I will start at 10, need to go to school with him today | 07:17 |
| mborzecki | hm i should really fix the upgrade test on fedora, but since 39.1 is already in testing i could wait a little bit | 07:33 |
| zyga | back in the office | 07:56 |
| zyga | it's a **hot** day | 07:58 |
| ackk | mvo, hi, in the currently implemented work for https://forum.snapcraft.io/t/phase-1-of-opt-in-per-snap-users-groups-aka-the-daemon-user/10624, do you know if the daemon user also has a group it can be used in the snap? | 08:12 |
| mvo | ackk: iirc it will have a group as well ("daemon") but take it with a gain of salt, jdstrand is leading the implementation, he is the authority here :) | 08:15 |
| ackk | mvo, ok, thanks, will give it a try and see if it works :) | 08:15 |
| ackk | mvo, if you have a snap that's been installed from the store with --devmode and it gets updated (also from the store), how do you drop the devmode flag? | 08:30 |
| Chipaca | ackk: you remove it and reinstall it? | 08:32 |
| Chipaca | ackk: we have no --un-devmode | 08:32 |
| Chipaca | for any of those flags | 08:32 |
| ackk | Chipaca, ok, I thought so but wanted to confirm | 08:32 |
| Chipaca | ackk: if you have data, snapshot and restore will work | 08:32 |
| Chipaca | (automatic snapshot if your snapd is new enough) | 08:32 |
| ackk | Chipaca, currently the maas snap does some 'chown nobody:nogroup' in the configure hook, we'd have to transition that to the daemon user, but I guess it should be fine because if you're doing a clean install you won't need --devmode, and if you're upgrading from one that had devmode, you can still change the ownership | 08:33 |
| Chipaca | ackk: tell me more about this "upgrading devmode" | 08:34 |
| Chipaca | because AFAIK devmode still does not auto-refresh | 08:34 |
| ackk | Chipaca, wdym? | 08:34 |
| ackk | Chipaca, it doesn't? | 08:34 |
| Chipaca | (yes we have a TODO item to make that happen but AFAIK it does not) | 08:34 |
| ackk | Chipaca, note that the snap is not marked as devmode | 08:34 |
| ackk | (if that's what you mean) | 08:34 |
| Chipaca | ackk: snap install --devmode foo results in foo not getting refreshed | 08:34 |
| Chipaca | ackk: irrespective of whether the snap itself needs devmode | 08:35 |
| ackk | Chipaca, can you manually refresh via snap refresh <snap> ? | 08:35 |
| ackk | or do you have to snap install / | 08:35 |
| Chipaca | hmmmmmmm | 08:35 |
| Chipaca | we've dithered a bit on this so i'd have to check | 08:35 |
| Chipaca | AKshully, maybe a manual 'snap refresh thesnap' (without --devmode) drops the devmode flag | 08:36 |
| Chipaca | maybe | 08:36 |
| ackk | Chipaca, to clarify, the maas snap is published to the store and it's grade:stable confinement:strict, but it only works if you snap install --devmode maas | 08:36 |
| Chipaca | ackk: it looks like 'snap refresh' without --devmode, *as long as there actually is an update*, drops the devmode flag | 08:38 |
| Chipaca | ackk: um | 08:38 |
| Chipaca | ackk: to be clear, 'snap refresh thesnap', not a bare 'snap refresh' | 08:38 |
| Chipaca | I'll check if it's actually dropping devmode from the profiles, but if it's not then that's a bug :) | 08:38 |
| ackk | Chipaca, I see you can also snap refresh --devmode | 08:40 |
| Chipaca | ackk: yes, and that will preserve devmode for the refresh | 08:40 |
| Chipaca | so that's how you drop the devmode flag -- there is no --un-devmode, but if you can make it do an actual refresh you can do it this way | 08:41 |
| Chipaca | (it doesn't work with a no-op refresh) | 08:41 |
| ackk | Chipaca, that makes sense, thanks for clarifying | 08:41 |
| Chipaca | maybe it should | 08:41 |
| Chipaca | but that's one for pedronis :) | 08:41 |
| ackk | Chipaca, do epochs work if you're refreshing with/from devmode ? | 08:42 |
| Chipaca | ackk: always | 08:42 |
| Chipaca | ackk: epochs are orthogonal to the sandbox | 08:42 |
| Chipaca | ackk: devmode is about the sandbox | 08:42 |
| ackk | Chipaca, ok, so I guess since we need to move from nobody to the deamon user, we'll have to use an epoch and upgrade via --devmode to be able to make the chmod | 08:43 |
| ackk | err, chown | 08:43 |
| Chipaca | that sounds awful | 08:43 |
| Chipaca | :-/ | 08:43 |
| ackk | is there a better way? | 08:43 |
| Chipaca | ackk: what is it you need to do? | 08:43 |
| ackk | (it does sound awful) | 08:43 |
| Chipaca | ackk: currentl the snap only works with --devmode? | 08:43 |
| ackk | Chipaca, so i have $SNAP_DATA/foo which is nobody:nogroup (and the snap is --devmode) | 08:43 |
| ackk | Chipaca, correct | 08:44 |
| ackk | Chipaca, I need to chown that to daemon:daemon so we can use system-users: [daemon] and drop devmode | 08:44 |
| Chipaca | ackk: can't you switch the devmode snap to use the daemon user before using system-users? | 08:44 |
| ackk | Chipaca, how? | 08:44 |
| Chipaca | ackk: how is it today using nobody:nogroup? | 08:44 |
| ackk | Chipaca, ah yeah that's what I'm saying | 08:45 |
| Chipaca | ah | 08:45 |
| ackk | Chipaca, swithc to daeamon:daemon and then drop devmode | 08:45 |
| ackk | Chipaca, but that's an intermediate requires step | 08:45 |
| ackk | and you have to snap refresh --devmode to it | 08:45 |
| Chipaca | ackk: yeah | 08:45 |
| ackk | and then snap refresh without | 08:45 |
| ackk | then you're free | 08:45 |
| Chipaca | ackk: hmm | 08:45 |
| ackk | Chipaca, maybe it'd be easier to snap remove, restore the snapshot, reinstall and chown manually :) | 08:46 |
| Chipaca | ackk: you could have the non-devmode snap copy the data instead of chowning it | 08:46 |
| ackk | Chipaca, but that will leave files that the snap can't do anything with? | 08:46 |
| Chipaca | ackk: i mean: have an ad-hoc miration daemon | 08:47 |
| ackk | unless you can still chown in a confined snap from a different user to yours | 08:47 |
| Chipaca | ackk: that runs as root | 08:47 |
| Chipaca | ackk: that copies the data over, removes the old data, and kicks the new 'daemon' daemon | 08:47 |
| ackk | Chipaca, will root in the snap be able to chown? I thought it wouldn't | 08:47 |
| Chipaca | ackk: no, not chown, but copy | 08:47 |
| ackk | Chipaca, can it remove the old data? | 08:48 |
| Chipaca | should be able to yes | 08:48 |
| Chipaca | runs as root an' all | 08:48 |
| ackk | mhm yeah that might be easier yes | 08:48 |
| Chipaca | chown/chuid is forbidden but not r/w/chmod | 08:48 |
| Chipaca | so you shold be able to get it working | 08:48 |
| Chipaca | hmm hmm | 08:48 |
| Chipaca | ackk: is the old data world-readable? | 08:49 |
| ackk | Chipaca, it should be yes. I can give a try at copying | 08:51 |
| ackk | Chipaca, thanks | 08:51 |
| Chipaca | ackk: if the old data is world-readable, the 'daemon' daemon could do the copy | 08:53 |
| Chipaca | ackk: how much data is it? | 08:53 |
| ackk | Chipaca, mhm actually that's the problem, it's mostly the squid and postgres dirs | 08:54 |
| ackk | so, potentially a lot | 08:54 |
| Chipaca | yeah that might make it unworkable | 08:55 |
| Chipaca | ackk: TBH sounds like telling somebody to 'snap refresh --devmode maas && snap refresh maas' is about the same as 'chown -R daemon:daemon /the/data && snap refresh maas' and a lot less work for you | 08:56 |
| Chipaca | the latter is less work i mean | 08:56 |
| ackk | Chipaca, yeah, it's ugly either way, although the first one is "safer" as we can make sure the right commands are run | 09:00 |
| * Chipaca nods | 09:01 | |
| Chipaca | ackk: you can at least use epochs to raiload people through that | 09:02 |
| ackk | Chipaca, right | 09:02 |
| Chipaca | ackk: give the new devmode-needing snap an epoch of 1*, and the new strict snap an epoch of 1 | 09:02 |
| Chipaca | ackk: then people installing from scratch will get the epoch:1 one | 09:02 |
| ackk | Chipaca, right, that was my thinking | 09:03 |
| Chipaca | ackk: and people that are on the old no-epoch (ie epoch 0) snap can't go to the epoch:1 one | 09:03 |
| Chipaca | they need to go through the 1* one | 09:03 |
| Chipaca | tadaa, or something | 09:03 |
| Chipaca | :) | 09:03 |
| Chipaca | ackk: and, and, you can update the epoch:1* snap and not stomp on the epoch:1 snap in the same channel | 09:03 |
| ackk | Chipaca, heh. yeah we already need epochs anyway as the new snap has to upgrade the db (the current stable one has postgres9 , the new pg10) | 09:04 |
| Chipaca | (i.e. even if the last snap you pushed was the epoch:1* snap, people will still get the epoch:1 one | 09:04 |
| Chipaca | ) | 09:04 |
| Chipaca | people doing new installs* | 09:04 |
| Chipaca | mvo: pstolowski: do you know what uses the snap-install-hook-broken snap? (from tests/lib/snaps/) | 09:05 |
| Chipaca | mvo: pstolowski: because it fails to install for a completely different reason than what I suspect it means to fail to install | 09:05 |
| ackk | Chipaca, can you explain the last sentence? if you have a 1 and a 1* in the same channel, whhy would you get the 1 ? | 09:05 |
| ackk | (in a new install) | 09:05 |
| Chipaca | ackk: 1* is {read:[0,1] write:[1]} | 09:06 |
| Chipaca | ackk: 1 is {read:[1], write:[1]} | 09:06 |
| ackk | Chipaca, right, but why do you care on a new install? | 09:06 |
| pedronis | zyga: hi, did you see my comment in #6714 btw? | 09:06 |
| mvo | Chipaca: idk, I suspect its a leftover? | 09:06 |
| zyga | pedronis: hi, I haven't yet, looking | 09:07 |
| Chipaca | ackk: so the upgrade epoch path thing is 0 → 1* → 1 | 09:07 |
| zyga | I will try to return to that branch soon, thank you | 09:08 |
| Chipaca | ackk: when you install or refresh you always get the rightmost snap in that → series | 09:08 |
| pstolowski | Chipaca: hmmm apparently it's not used. wonder if it was replace by snap-hooks-bad-install | 09:08 |
| pstolowski | *replaced | 09:08 |
| Chipaca | ackk: the rightmost snap that you can use i mean | 09:08 |
| Chipaca | ackk: on a new install, that's always the rightmost one | 09:08 |
| ackk | Chipaca, right, so if you make a clean install you get "1" | 09:08 |
| ackk | Chipaca, ok, I thought you said you'd get 1* | 09:08 |
| Chipaca | ackk: exactly | 09:08 |
| Chipaca | ackk: independently of what the last snap you pushed to the channel was | 09:09 |
| Chipaca | ackk: that's important because otherwise a new user might get a 1* which is just a fix for a bug in a migration snap when the latest and greatest is 4 or something | 09:10 |
| ackk | Chipaca, aah I see you mean if you push 30: 1 and then 31: 1*, a new install still gets 30 | 09:10 |
| Chipaca | ackk: yep | 09:10 |
| ackk | Chipaca, I see yeah that wworks | 09:11 |
| Chipaca | pedronis: wdyt of in-cohort? | 09:16 |
| pedronis | Chipaca: sounds reasonable | 09:17 |
| Chipaca | k | 09:17 |
| * Chipaca gets on it | 09:18 | |
| pedronis | mborzecki: I did another pass on some of the gadget update PRs | 09:19 |
| mborzecki | pedronis: thanks | 09:19 |
| mborzecki | pedronis: i've udpated https://github.com/snapcore/snapd/pull/6836 with feedback from yesterday | 09:20 |
| pedronis | mborzecki: ok, I'll look again later, need to do some forum answering | 09:21 |
| mborzecki | pedronis: sure, thank you for taking time to do the reviews, there's a quite bunch of those :) | 09:22 |
| * zyga has a small breakthrough in ideas about mount propagation | 09:40 | |
| zyga | let's quickly code that | 09:40 |
| * Chipaca puts https://mobile.twitter.com/LightfootJaime/status/1135970988217249793 gently down and walks away whistling | 09:48 | |
| zyga | Chipaca: wow, that's cool | 09:53 |
| zyga | I love the front panel | 09:53 |
| Chipaca | zyga: I was going to point you at it directly but didn't want to interrupt :) | 09:54 |
| mborzecki_ | forum has spilled to reddit https://www.reddit.com/r/kde/comments/bwxij9/since_when_did_qtkde_snaps_become_better/ | 09:58 |
| === mborzecki_ is now known as mborzecki | ||
| zyga | oh? | 10:01 |
| mvo | cmatsuoka: hey, do we need to update the spike-tools repo ? I get a make error in e2fsprogrs right now but iirc you mentioned those are no longer needed ? | 10:22 |
| mvo | Chipaca: silly question - how long is the cohort key? | 10:34 |
| pedronis | mvo: ~148 | 10:37 |
| mvo | ta | 10:41 |
| mvo | pedronis: I guess there is a good reason for this, would love to hear a td;lr summary (maybe in the standup) | 10:48 |
| zyga | brb, coffee | 10:58 |
| cmatsuoka | mvo: yes, it should be in the writable-ramdisk branch as well | 11:19 |
| zyga | brb, rebooting | 11:22 |
| cmatsuoka | mvo: my plan is to add the recovery chooser today for install and recovery modes | 11:23 |
| mvo | cmatsuoka: what do I need to add/change to prepare.sh to get writable-ramdisk? is that from your core-build repo? | 11:23 |
| cmatsuoka | mvo: let me run it here in a clean dir, it was supposed to work | 11:24 |
| mvo | cmatsuoka: ok, maybe its my 19.04, I can try on a 18.04 | 11:26 |
| cmatsuoka | mvo: I don't know how sensitive it is to environment variations, but it's possible | 11:27 |
| cmatsuoka | my build box here is 18.04 | 11:28 |
| cmatsuoka | mvo: hmm, in fact mke2fs shouldn't be there since it's not needed anymore | 11:33 |
| jdstrand | ackk (cc mvo): there will be a group too | 11:34 |
| ackk | jdstrand, nice, thanks! | 11:34 |
| mvo | cmatsuoka: it builds on 18.04 | 11:35 |
| ackk | jdstrand, unrelated, not sure if it was mentioned at the sprint, but would it make sense to have an interface to allow reading /run/uuidd/request? | 11:35 |
| mvo | cmatsuoka: but if we don't need e2fs anyway, I can remove it | 11:36 |
| cmatsuoka | mvo: I just noticed that build-image.sh complains about go/snapd, you'll have to build it as well | 11:36 |
| cmatsuoka | I'm pushing an updated prepare | 11:36 |
| mvo | cmatsuoka: thank you! I check it after lunch | 11:36 |
| zyga | pstolowski: I will try to review https://github.com/snapcore/snapd/pull/6923 today | 11:52 |
| jdstrand | ackk: we did talk about it. it is in openvswitch-support, believe it or not, but @{PROC}/sys/kernel/random/uuid is already in the default template which is going to be more robust since uuidd may not (necessarily) be everywhere | 11:53 |
| pstolowski | zyga ty | 11:53 |
| lss8 | so, is there now a way to disable automatic snap update checks? | 11:54 |
| lss8 | I'd like to not auto update my snaps as this is a potential security issue | 11:55 |
| Chipaca | lss8: _updating_ your snaps is a security issue? | 12:08 |
| Chipaca | lss8: please explain? | 12:08 |
| Chipaca | lss8: if you have specific concerns, and are planning to test for these concerns in a controlled environment before releasing things to a large network, there are tools for this | 12:11 |
| Chipaca | lss8: but as i say, please explain | 12:13 |
| ackk | jdstrand, yeah I'm not sure what's actually using it in the maas snap, I've seen denials, but we don't use it explicitly | 12:25 |
| jdstrand | ackk: I think blake_r or roaksoax thought it was something in a python lib that could be switched out or something | 12:52 |
| mborzecki | pedronis: update gadget task handler also checks whether a snap is installed, we can do it in both places though | 12:53 |
| pedronis | mborzecki: yes, I think best it to do it both places | 12:53 |
| === ricab is now known as ricab|lunch | ||
| mborzecki | pedronis: ack | 12:58 |
| ackk | jdstrand, yeah not sure, afaik we always use the python uuid module, which does stuff on its own | 13:02 |
| kenvandine | cwayne: i haven't gotten a testflinger email lately | 13:02 |
| zyga | kenvandine: more fixes for mount profiles coming soon | 13:12 |
| kenvandine | zyga: great | 13:15 |
| Greyer | hi ppl, at monday I have installed recent snapd-2.39-1.el7.x86_64 on CentOS 7 (OS is with SELinux in Enforced mode) and after that my LXD was unavailable, I've looked into audit and saw lot of permission errors. Switching into Permissive regain me access to lxd daemon. Is this a known issue or I should create ticket in bugzilla for this? | 13:16 |
| mborzecki | pedronis: fakestore new-snap-revision --snap-rev-json right? | 13:16 |
| zyga | Greyer: hello | 13:17 |
| zyga | mborzecki: ^ | 13:17 |
| mborzecki | Greyer: hey | 13:17 |
| Greyer | hey :) | 13:17 |
| zyga | Greyer: based on what you just described it doesn't seem like the issue that we fixed yesterday but I will defer to mborzecki's opinion | 13:18 |
| mborzecki | Greyer: what's the problem? | 13:18 |
| Greyer | mborzecki: CentOS 7 in Selinux Enforced mode on newest snapd (snapd-2.39-1.el7.x86_64) gets LXD broken, lxd daemon pid is not available | 13:19 |
| zyga | Greyer: what kind of denials are you seeing? | 13:19 |
| mborzecki | Greyer: interesting, we have an integration test targeting this, let me check it locally | 13:19 |
| zyga | Greyer: is it broken straight away of after reboot? | 13:20 |
| zyga | perhaps it's the same bug | 13:20 |
| Greyer | zyga: straight away | 13:20 |
| Greyer | I've made yum update and lxc list stopped working saying that daemon is not available | 13:20 |
| Greyer | let me check | 13:20 |
| mborzecki | Greyer: installing now | 13:21 |
| pedronis | mborzecki: yes | 13:22 |
| Greyer | btw, I've jumped from snapd-2.38-1.el7.x86_64 to snapd-2.39-1.el7.x86_64 | 13:23 |
| Greyer | but I don't think there was any other version between in epel repository | 13:24 |
| Greyer | what is odd, my lxd containers were still running without problems, just I couldn't use the commands | 13:25 |
| mborzecki | Greyer: w8, so you had lxd installed, and updated to 2.39, that's when it broke, right? | 13:25 |
| Greyer | yes, lxd was installed, containers were running | 13:27 |
| Greyer | I have updated snapd from 2.38 to 2.39 (epel7 repository) | 13:27 |
| Greyer | and all lxc commands stopped working saying that lxd daemon is not working | 13:27 |
| Greyer | but containers were workin | 13:27 |
| Greyer | g | 13:27 |
| Greyer | I have downgraded to 2.38 everything worked again | 13:27 |
| Greyer | so reuptaded to 2.39 | 13:28 |
| Greyer | and again no permissions, then setenforce 0, lxc commands started working | 13:28 |
| Greyer | Jun 03 08:32:27 sheldon.szary.sh lxd.daemon[2215]: cmd_run.go:375: restoring default SELinux context of /root/snap | 13:31 |
| Greyer | Jun 03 08:32:27 sheldon.szary.sh lxd.daemon[2215]: execv failed: Permission denied | 13:31 |
| mborzecki | Greyer: can you upload `ausearch -m AVC -ts 08:32` somewhere? | 13:33 |
| Greyer | mborzecki: yes, sec | 13:35 |
| Greyer | mborzecki: I see only logs from today, audit.log was rotated, so let me change | 13:36 |
| Greyer | mborzecki: http://tmp.szary.sh/audit.log-20190603-0830-0840 | 13:43 |
| Greyer | here | 13:43 |
| mborzecki | Greyer: looking | 13:43 |
| mborzecki | Greyer: what does `mount |grep snap` show? | 13:44 |
| mborzecki | Greyer: for the record, when updating to 2.39 you need to reboot for the mount points to be recreated with proper selinux contexts | 13:47 |
| mborzecki | Greyer: it's a one off thing, we previously did not have any selinux contexts for mounted snaps, but now we have | 13:48 |
| mborzecki | Greyer: restarting mounts will likely not help, unless you can make sure that the mount point is not used in any mount ns, kernel denies remounting a block device with a different security context | 13:49 |
| Greyer | [root@sheldon.szary.sh] 15:42:06 ~ # mount | grep snap | column -t | 13:52 |
| Greyer | tmpfs on /run/snapd/ns type tmpfs (rw,nosuid,nodev,seclabel,mode=755) | 13:52 |
| Greyer | /var/lib/snapd/snaps/lxd_10601.snap on /var/lib/snapd/snap/lxd/10601 type squashfs (ro,nodev,relatime,seclabel) | 13:52 |
| Greyer | /var/lib/snapd/snaps/lxd_10756.snap on /var/lib/snapd/snap/lxd/10756 type squashfs (ro,nodev,relatime,seclabel) | 13:52 |
| Greyer | /var/lib/snapd/snaps/core_6673.snap on /var/lib/snapd/snap/core/6673 type squashfs (ro,nodev,relatime,context=system_u:object_r:snappy_snap_t:s0) | 13:52 |
| Greyer | /var/lib/snapd/snaps/core_6818.snap on /var/lib/snapd/snap/core/6818 type squashfs (ro,nodev,relatime,context=system_u:object_r:snappy_snap_t:s0) | 13:52 |
| Greyer | /var/lib/snapd/snaps/core_6964.snap on /var/lib/snapd/snap/core/6964 type squashfs (ro,nodev,relatime,context=system_u:object_r:snappy_snap_t:s0) | 13:52 |
| Greyer | /var/lib/snapd/snaps/lxd_10526.snap on /var/lib/snapd/snap/lxd/10526 type squashfs (ro,nodev,relatime,context=system_u:object_r:snappy_snap_ | 13:52 |
| Greyer | /var/lib/snapd/snaps/lxd_10526.snap on /var/lib/snapd/snap/lxd/10526 type squashfs (ro,nodev,relatime,context=system_u:object_r:snappy_snap_t:s0) | 13:52 |
| Greyer | proc on /run/snapd/ns/lxd.mnt type proc (rw,nosuid,nodev,noexec,relatime) | 13:52 |
| mborzecki | Greyer: looks good, you're on 2.39 now, right? | 13:54 |
| Greyer | mborzecki: so You advise to reboot? | 13:54 |
| Greyer | yes, I'm on 2.39 now with Permissive Selinux mode | 13:54 |
| Greyer | I can switch to Enforced and reboot to see if it'll work | 13:55 |
| mborzecki | Greyer: just to make sure, can you systemctl cat var-lib-snapd-snap-lxd-10756.mount ? there should be snappy_snap_t in mount options | 13:58 |
| mborzecki | Greyer: if it's there, then you can reboot | 13:59 |
| === ricab|lunch is now known as ricab | ||
| zyga | Greyer: any luck? | 14:22 |
| pedronis | mvo: pstolowski: seems the store has added the 'snapd' type already | 14:25 |
| pstolowski | pedronis: great! | 14:33 |
| ijohnson | davdunc: hi! have you considered making aws-cli a strict snap with the personal-files interface to access $HOME/.aws instead of classic? | 14:34 |
| Greyer | ah, mborzecki is out, I got dragged to solve issue | 14:37 |
| Greyer | there is snappy_snap_t in mount options | 14:38 |
| Greyer | I will reboot in a few minutes, first need to take kid from preschool | 14:39 |
| Eighth_Doctor | zyga: could you please test and give karma for F29 and EL7 snapd builds? | 14:44 |
| Eighth_Doctor | they need +2 in order to make it in the distro, and F29 has 0, while EL7 has +1 | 14:44 |
| zyga | Eighth_Doctor: sure, let me boot fedora | 14:48 |
| zyga | I noticed the ping in the morning but mborzecki said the update was not ready somehow yet | 14:48 |
| davdunc | ijohnson: I have. | 14:54 |
| Eighth_Doctor | it wasn't at his mirrors | 14:54 |
| Eighth_Doctor | but it has been pushed to the mirror network | 14:54 |
| davdunc | ijohnson: it's on my roadmap, just not completed. | 14:55 |
| pedronis | mvo: pstolowski: snapcraft doesn't though, we need to ask for that | 15:05 |
| zyga | re-running regressed test | 15:11 |
| zyga | I need to think some more but I think this will be good | 15:11 |
| pstolowski | ok | 15:16 |
| zyga | more work required :/ | 15:21 |
| zyga | the idea is good but the algo is simplistic | 15:21 |
| zyga | need to think | 15:21 |
| pedronis | mvo: I proposed #6957 | 15:39 |
| mvo | pedronis: thank you! | 15:41 |
| ogra | mvo, do we have any plans for a classic snap on UC18 ? (do we even ship the tarball with the removed files at all in 18 ?) | 15:42 |
| ackk | does each snap have a namespaced view of /dev/shm? | 15:43 |
| ogra | yes, but not under that node name IIRC | 15:44 |
| ogra | (there is a snap specific prefix) | 15:44 |
| mvo | ogra: have you tried "snap install classic --channel=18/edge" ? | 15:45 |
| ogra | mvo, ah, no, does it exist already ? | 15:45 |
| ogra | abeato, ^^^ | 15:45 |
| mvo | ogra: yes, I'm not sure how good and well tested it is | 15:45 |
| mvo | ogra: but we did some work on this a good while ago | 15:45 |
| mvo | ogra: its probably super out-of-date :( | 15:46 |
| ogra | awesome, i wasnt aware of the status | 15:46 |
| ackk | ogra, so I see https://paste.ubuntu.com/ on my machine, where those squid entries are from a squid in the snap. does that mean you can't run more than one? | 15:46 |
| mvo | ogra: I can look into this soon(ish) | 15:46 |
| ogra | mvo, well, alfonso asked for it, i use mostly lxd nowadays (but then i also rarely need gdb against the os itself) | 15:47 |
| ogra | (which classic makes easy) | 15:47 |
| ijohnson | davdunc: okay, thanks. I made a version of the snap using the personal-files interface a while ago but didn't push up to the store I could share with you if you're interested | 15:47 |
| abeato | ogra, mvo oh very nice, so there is something, that's a good start | 15:48 |
| mvo | abeato: please keep me posted, its been a while since I looked at this | 15:48 |
| ogra | abeato, yeah ... happy to help with fixes if there are anyy needed | 15:49 |
| abeato | sure | 15:49 |
| ackk | ogra, also if I ls /dev/shm from another confined snap, I do see those files | 15:52 |
| ogra | ackk, well, thats a jdstrand topic then :) | 15:56 |
| ogra | ackk, FWIW https://forum.snapcraft.io/t/shared-memory-in-dev-shm-rewriting/2023 | 15:57 |
| ackk | ogra, thanks | 15:57 |
| * cachio lunch | 16:08 | |
| === pstolowski is now known as pstolowski|afk | ||
| davdunc | ijohnson: that would be much appreciated. https://github.com/davdunc/aws-cli-snap | 16:15 |
| davdunc | I love it when there's less work for me to do to get to the same goal. | 16:16 |
| davdunc | and I appreciate all the help I have gotten so far. | 16:16 |
| ackk | ogra, thanks, the thing is I'm trying to fix the case where preexisting shm files exist | 16:17 |
| Saviq | jdstrand: hey, we've been getting more "outdated packages" emails recently and were wondering if we could somehow automate the rebuilds, is the data available somewhere other than in the email? could we get it ourselves in CI maybe? | 16:46 |
| === ricab is now known as ricab|bbiab | ||
| === ricab|bbiab is now known as ricab | ||
| jdstrand | Saviq: you might be interested in https://blog.strandboge.com/2019/02/01/monitoring-your-snaps-for-security-updates/ | 17:31 |
| Saviq | jdstrand: aha! pity that would require us to download the snaps from the store to run :/ | 17:33 |
| jdstrand | Saviq: ideally the store would provide something, but it doesn't and this is all separate atm | 17:42 |
| Chipaca | EOD from me 👋 | 17:46 |
| ijohnson | davdunc: I opened https://github.com/davdunc/aws-cli-snap/pull/3 to use the personal-files interface | 21:37 |
| davdunc | thanks. | 22:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!