| mup | PR snapcraft#1902 closed: many: use in-snap unsquashfs and readelf if running from snap <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1902> | 00:07 |
|---|---|---|
| mup | PR snapcraft#1899 closed: elf: readelf dependency <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1899> | 00:10 |
| greyback | jdstrand: ack, thank you, I'll add comment tomorrow | 00:33 |
| jdstrand | greyback: thanks! | 00:36 |
| jjohansen | jdstrand: I am not sure I understand the question, but I'll give it a go. the bpf filesystem is registered during fs init on kernel boot | 02:34 |
| mup | PR snapcraft#1903 opened: elf: use surrogate escape when decoding readelf output <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1903> | 02:34 |
| mup | PR snapcraft#1885 closed: Release 2.39 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1885> | 02:40 |
| mup | PR snapd#4578 opened: Expose payment and account URLs in /v2/system-info <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/4578> | 03:50 |
| Ender__ | Hello | 05:11 |
| Ender__ | I love Snapcraft !! Does anyone else think this might be a revolutionary design idea ? | 05:12 |
| mborzecki | morning | 06:15 |
| mvo | zyga: good morning | 06:29 |
| mborzecki | mvo: zyga: morning guys | 06:29 |
| zyga | morning | 06:31 |
| zyga | prepping kids for school | 06:31 |
| mvo | hey mborzecki | 06:32 |
| zyga | aaand they've gone :-) | 06:49 |
| zyga | rain rain rain, but my mood is great today | 06:50 |
| zyga | mvo: did you restart https://github.com/snapcore/snapd/pull/4577 ? | 06:50 |
| mup | PR #4577: snap: fix command-not-found on core devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/4577> | 06:50 |
| mvo | zyga: yes | 06:56 |
| mvo | zyga: it had header timeout errors | 06:56 |
| mvo | zyga: what is gone? | 06:56 |
| zyga | mvo: ah, that was just a reference to my kids and wife, they've all gone to school | 07:01 |
| mvo | zyga: :) ok | 07:01 |
| zyga | greyback: hello | 07:12 |
| zyga | greyback: https://github.com/snapcore/snapd/pull/4572 can land, just add a comment | 07:12 |
| mup | PR #4572: mir: software clients need access to shared memory /dev/shm/#* <Created by gerboland> <https://github.com/snapcore/snapd/pull/4572> | 07:12 |
| zyga | hmmm | 07:22 |
| zyga | irc spam | 07:22 |
| zyga | that's new | 07:22 |
| zyga | error: cannot find snap "core": Get | 07:26 |
| zyga | https://api.snapcraft.io/api/v1/snaps/details/core?channel=stable&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Clicense%2Cbase%2Csupport_url%2Ccontact%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdev | 07:26 |
| zyga | eloper_id%2Cprivate%2Cconfinement%2Cchannel_maps_list: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) | 07:26 |
| mup | PR snapd#4568 closed: tests: new spead test for openvswitch-support interface <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4568> | 07:28 |
| mborzecki | zyga: can you try to install this snap locally? http://apps.syncloud.org/apps/rocketchat_180201_amd64.snap | 07:30 |
| mborzecki | zyga: i'm seeing this https://paste.ubuntu.com/26499308/ | 07:31 |
| mborzecki | core 16-2.31~rc2+git528.a129e36 3982 canonical core | 07:31 |
| zyga | mborzecki: sure, one moment | 07:32 |
| zyga | or... 20 minutes | 07:33 |
| zyga | slow server? | 07:33 |
| zyga | nah, ramping up | 07:33 |
| zyga | ~250KB/s | 07:33 |
| zyga | 8 minutes | 07:33 |
| mborzecki | tmaybe it's capped | 07:33 |
| mborzecki | anyway, take a look at the log, install hook fails, ale last line `cannot snap-exec: no such file or directory` | 07:34 |
| mvo | mborzecki: what does the install hook look like? a shell script? a binary? | 07:34 |
| mborzecki | omg, it's a python script, `#!/snap/platform/current/python/bin/python` | 07:35 |
| mborzecki | platform? | 07:35 |
| zyga | mborzecki: so, since we established that this hook depends on a snap called "platform" and thus won't work (it cannot execute anything from snaps other than itself) shall I still install it? | 07:51 |
| mborzecki | zyga: no, thanks though :) | 07:51 |
| zyga | mborzecki: actually, that's something that could be checked store-side | 08:00 |
| pstolowski | hey o/ | 08:01 |
| zyga | hey hey :) | 08:03 |
| zyga | reading your PR now :0 | 08:03 |
| kalikiana | morning | 08:04 |
| pstolowski | zyga, thanks! which one? | 08:22 |
| zyga | pstolowski: 4551 | 08:23 |
| mup | PR snapd#4577 closed: snap: fix command-not-found on core devices <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4577> | 08:31 |
| mvo | greyback: looks like 4572 is good except for this one comment that jamie asks for, once that it is added this can go in | 08:33 |
| mup | PR snapd#4459 closed: snap: add support for `snap advise-snap pkgName` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4459> | 08:41 |
| mvo | 4049 needs a second review | 08:44 |
| mup | PR snapd#3456 closed: many: add interfaces.SystemKey() helper <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3456> | 08:48 |
| mup | PR snapd#4579 opened: many: add interfaces.SystemKey() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4579> | 08:51 |
| greyback | mvo: I just pushed the requested comment to 4572 | 09:02 |
| zyga | thank you | 09:02 |
| greyback | thank you! | 09:02 |
| mup | PR snapd#4580 opened: tests: ensure disalbled services are masked <Created by mvo5> <https://github.com/snapcore/snapd/pull/4580> | 09:03 |
| mvo | ogra_: we have code that masks the rsyslog/ssh units, I added an explicit integration test above. if this does not work for you, I need to know the version of snapd and what command you use and the output of systemctl status rsyslog.service and the output of ls -l /etc/systemd/system | 09:04 |
| ogra_ | mvo, note that this install comes with rsyslog disabled from the gadget by default ... it definitely was off on fresh install so it must have enabled itself during an upgrade (running edge with locally built gadget and kernel) | 09:06 |
| ogra_ | mvo, https://paste.ubuntu.com/26499622/ | 09:09 |
| mvo | ogra_: was it an old install with a core that would not mask on diable? | 09:09 |
| ogra_ | nope, thats a few days old | 09:09 |
| mvo | ogra_: fwiw, because of "synced" for /etc/systemd/system when it is not masked it will come back | 09:10 |
| mvo | ogra_: is this fresh image available somehwere? i.e. I wonder if there is a way to boot it and then inspect the state right after boot | 09:10 |
| ogra_ | mvo, i know ... but i checked that it is off right after install ... so i'm confident it was originally off ... i didnt check the link explicitly though | 09:10 |
| mvo | ogra_: afaik the codepath for "snap set core service.rsyslog.disable=true" and the gadget disable is the same but maybe not | 09:10 |
| mvo | ogra_: also, the gadget.yaml would be great | 09:11 |
| ogra_ | mvo, you wouldnt have the HW to run it but i can push the rootfs somewhere | 09:11 |
| pedronis | Chipaca: I have some post-facto comments on #4575 | 09:11 |
| mup | PR #4575: config: add (Get|Set)SnapConfig to do bulk config e.g. from snapshots <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4575> | 09:11 |
| mvo | ogra_: in snap changes, did you see a core refresh around jan 28, 11:50 ? | 09:11 |
| Chipaca | pedronis: hm, i can do a followup | 09:12 |
| ogra_ | phew ... there were a bunch of refreshes ... /me checks | 09:12 |
| Chipaca | pedronis: is that why the other ones take *s? | 09:12 |
| pedronis | yes | 09:12 |
| pedronis | see snapstate.Set for example | 09:12 |
| mvo | ogra_: the mtime of the symlink looks different from most other times in this dir | 09:12 |
| Chipaca | ok, i'll take a stab at it | 09:12 |
| mvo | ogra_: so I suspect writable-path re-creating it | 09:12 |
| Chipaca | in a bit | 09:12 |
| mvo | ogra_: the rootfs will not be that useful as the disable will happen on firstboot | 09:13 |
| pedronis | Chipaca: I don't think element of config can be nil but good to double check | 09:13 |
| ogra_ | mvo, thats long scrolled off ... changes starts only at 2018-01-31 | 09:13 |
| mvo | ogra_: so just by looking at the rootfs I will not see much unfortunately | 09:13 |
| mvo | ogra_: ok | 09:13 |
| ogra_ | mvo, sadly non-registered devices spam changes very regular, changes is pretty unusable during development through that " Error 2018-02-01T09:10:37Z 2018-02-01T09:10:40Z Initialize device" every few mins | 09:14 |
| mvo | :/ | 09:14 |
| zyga | no exp backoff? | 09:14 |
| ogra_ | i'll have to do a re-install later today ... i'll see what i can do to trigger it again | 09:14 |
| mvo | zyga: sure, from seconds to minutes :P | 09:14 |
| mvo | ogra_: an ls -l /etc/systemd/system right after firstboot would be great. ideally using the image you had | 09:15 |
| mvo | ogra_: I mean the same image as you used for this one | 09:15 |
| ogra_ | ok | 09:15 |
| zyga | :) | 09:15 |
| pedronis | Chipaca: also notice that Get can give you nil bu Set will not take it, so it's probably a problem either way | 09:16 |
| pedronis | the lack of symmetry | 09:16 |
| ogra_ | mvo, oh, crap i just notice i have overwritten that specific image ... but i'll try the oldest one i have | 09:18 |
| Chipaca | pedronis: I don't need the * to make the nil check on save though | 09:18 |
| mvo | ogra_: no worries, iirc masking was added a little bit later, i.e. for a brief time there was a bug in our new corecfg when it did not mask, let me check when it was fixed | 09:19 |
| ogra_ | ah ! | 09:19 |
| pedronis | Chipaca: that's true | 09:19 |
| Chipaca | pedronis: a nil json.RawMessage is unserialisable, so I can just check that | 09:19 |
| pedronis | Chipaca: the code is broken right now though | 09:19 |
| mvo | ogra_: it was added 2017-11-30 | 09:19 |
| pedronis | if you pass a nil | 09:19 |
| ogra_ | mvo, well, the image was on auto-update and was definitely built this week ... | 09:20 |
| mvo | ogra_: the masking | 09:20 |
| pedronis | various things will likely end up unhappy | 09:20 |
| Chipaca | pedronis: yep, noticed that :-) was checking on the caller side | 09:20 |
| Chipaca | pedronis: will address in a followup and then tweak my callers | 09:20 |
| mvo | ogra_: one week indicates something else is going on, I look forward to your ls and servicectl output | 09:20 |
| ogra_ | mvo, that could match, i built it onday or tuesday morning | 09:20 |
| ogra_ | *monday | 09:20 |
| Chipaca | pedronis: do you remember why the cleanup task waited for an ensure run to kick in? (am I forgetting something non-obvious, or has it always been like this?) | 09:43 |
| pedronis | Chipaca: in which sense? | 09:44 |
| pedronis | all tasks get triggered by an Ensure cycle | 09:44 |
| Chipaca | pedronis: right, and in api.go we do an EnsureBefore(0) to kick them off | 09:46 |
| pedronis | yes | 09:46 |
| pedronis | but there is also logic in taskrunner | 09:46 |
| pedronis | to also do that | 09:46 |
| Chipaca | pedronis: but the cleanup task (one added with "AddCleanup") waits for the _next_ ensure before running | 09:46 |
| pedronis | if there are dependents | 09:46 |
| pedronis | Chipaca: might be missing a kick in task runner | 09:46 |
| pedronis | in some cases | 09:46 |
| pedronis | or maybe it's hard to decide | 09:47 |
| pedronis | to do the kick | 09:47 |
| Chipaca | pedronis: ok, when i can push to github i'll pester you about this again; i'm probably missing something silly :-) | 09:47 |
| pedronis | I know I have a test where this is an issue | 09:48 |
| pedronis | but there is more related to not having all the right managers | 09:48 |
| pedronis | around | 09:48 |
| pedronis | Chipaca: have you run run-checks --static locally recently? it logs a lot about tests/lib/snaps/test-snapd-validate-container-failures/hell | 09:58 |
| pedronis | it doesn't error but it's a bit on the noisy side | 09:58 |
| Chipaca | i put that thing there to stress test some checkers, but not sure which one is getting tricked in --static | 10:00 |
| pedronis | seems spell checking afaict | 10:01 |
| mup | PR snapd#4581 opened: overlord/configstate/config: make SetSnapConfig delete on empty <Created by chipaca> <https://github.com/snapcore/snapd/pull/4581> | 10:03 |
| Chipaca | pedronis: ^ | 10:04 |
| apply55gx | Hello, is there a way to transfer a snap with all of it's data to another server? | 10:14 |
| mborzecki | Chipaca: ^^ snapshots? | 10:14 |
| Chipaca | ish | 10:15 |
| Chipaca | yes :-) | 10:15 |
| Chipaca | except user data might make things weird | 10:15 |
| Chipaca | apply55gx: currently, in released snapd, you could do it manually with some care | 10:15 |
| apply55gx | @mborzecki do you mean whole server snapshots or is there a way to create a snapshot just of the snap? | 10:16 |
| Chipaca | apply55gx: I'm working on a feature to do snapshots of a snap | 10:16 |
| Chipaca | apply55gx: but it's not even up for review yet | 10:16 |
| Chipaca | so at least a month before it's on stable | 10:16 |
| apply55gx | Chipaca: Thank you for your answer. How would you manually do this? | 10:17 |
| mup | PR snapd#4582 opened: many: at seeding try to capture cloud information into core config under "cloud" <Created by pedronis> <https://github.com/snapcore/snapd/pull/4582> | 10:17 |
| Chipaca | apply55gx: assuming the snap is public, I'd install the snap in the new server, disable it (snap disable $thesnap) so it's there but the services are all stopped, and then rsync /var/snaps/<thesnap> over | 10:18 |
| apply55gx | Just copying it won't work, does it? | 10:18 |
| Chipaca | apply55gx: if the snap uses 'snap set' to do config there's an extra step | 10:19 |
| Chipaca | apply55gx: just copying the snap? it could; you'd need the assertion as well as the snap but you have it | 10:19 |
| Chipaca | apply55gx: simpler to just re-get it if you can, but otherwise yes you can just copy it and the assertion, then 'snap ack <the assertion>' and 'snap install <the .snap>' | 10:20 |
| Chipaca | apply55gx: if you don't want to figure out which assertion to ack, you _could_ copy everything and ack the whole lot :-) | 10:21 |
| Chipaca | apply55gx: that's /var/lib/snapd/assertions/asserts-v0/ | 10:21 |
| apply55gx | Chipaca: Ok, I'm gonna try getting the snap and just copy the /var/snap/ folder. The other thing seems a bit too complicated for me :-) | 10:21 |
| apply55gx | Chipaca: Thank you for your quick answer :) | 10:22 |
| Chipaca | apply55gx: if you're able and have the time to describe what you want to do as a feature request, it'd be neat to have it documented | 10:22 |
| Chipaca | apply55gx: but no rush for that :-) | 10:22 |
| Chipaca | it's just that as far as I know we don't currently have a user story for "copy this snap and all its data to that machine" | 10:23 |
| Chipaca | it'd be a step further down the snapshot road | 10:23 |
| Chipaca | and enable some nifty migrations, i reckon | 10:23 |
| Chipaca | anyhow, back to coding snapshots | 10:23 |
| apply55gx | Chipaca: I'll try to document it as good as possible :) Where should I put the documentation afterwards? | 10:24 |
| Chipaca | apply55gx: if it's story-ish, https://forum.snapcraft.io; if it's bug-ish, https://bugs.launchpad.net/snapd/+filebug | 10:25 |
| Chipaca | apply55gx: if in doubt, chose one at random and we'll sort it out :-) | 10:25 |
| apply55gx | Ok, thank you :-) | 10:25 |
| ogra_ | mvo, ok ... fresh re-install of the oldest image i have here (and in fact the core is from yesterday) ... https://paste.ubuntu.com/26499992/ | 10:39 |
| ogra_ | mvo, so i guess something with applying the gadget config on first boot goes wrong | 10:40 |
| mvo | ogra_: this is first-boot? | 10:40 |
| mvo | ogra_: i.e. nothing else was run yet? | 10:40 |
| ogra_ | only ran through console-conf yet ... didnt reboot | 10:40 |
| mvo | ogra_: what is the output of "snap changes"? | 10:40 |
| ogra_ | ogra@localhost:~$ snap changes | 10:40 |
| ogra_ | ID Status Spawn Ready Summary | 10:40 |
| ogra_ | 1 Done 2018-02-01T10:27:24Z 2018-02-01T10:28:13Z Initialize system state | 10:40 |
| ogra_ | 2 Error 2018-02-01T10:28:10Z 2018-02-01T10:29:24Z Initialize device | 10:40 |
| ogra_ | 3 Error 2018-02-01T10:34:24Z 2018-02-01T10:34:27Z Initialize device | 10:40 |
| mvo | ogra_: great, yeah, it looks like first-boot config is broken just not running, the output of journalctl -u snapd might be good | 10:41 |
| mvo | ogra_: *maybe* there is an error in there | 10:41 |
| ogra_ | mvo, nothing in journald https://paste.ubuntu.com/26500004/ | 10:42 |
| ogra_ | (the chopped off likes are just "installing kernel" and "installing gadget" | 10:43 |
| ogra_ | ) | 10:43 |
| * kalikiana coffee break | 10:43 | |
| mvo | ogra_: ta | 10:44 |
| mvo | ogra_: looks like a real bug :( | 10:46 |
| ogra_ | yes | 10:46 |
| greyback | any recommendation on how to give someone a custom snapd to test? | 10:52 |
| ogra_ | write it to a USB key ... get a padded envelope ... put stamps and an address on ... write a note with instructions and send it ? | 10:54 |
| mvo | greyback: a binary build for their target arch? push to a url, then ask $person to "wget $url", systemctl stop snapd.socket snapd.server; sudo cp custom-snapd /usr/lib/snapd/snapd; sudo systemctl start snapd.socket snapd.service | 10:56 |
| greyback | mvo: ok, so the obvious. Thanks | 10:57 |
| greyback | ogra_: you sir need some sugar, you're getting grumpy | 10:57 |
| ogra_ | lol | 10:57 |
| Chipaca | https://pastebin.ubuntu.com/26500106/ | 11:07 |
| * Chipaca might be having a little too much fun | 11:07 | |
| mborzecki | Chipaca: at least you're having fun :) | 11:08 |
| Chipaca | :-) | 11:08 |
| mborzecki | i like the 'probably *fine*' | 11:08 |
| === mup_ is now known as mup | ||
| === diddledan_ is now known as diddledan | ||
| ogra_ | mvo, https://bugs.launchpad.net/snapd/+bug/1746714 | 11:48 |
| mup | Bug #1746714: regression: gadget defaults are not applied with latest snapd <snapd:New> <https://launchpad.net/bugs/1746714> | 11:48 |
| mup | PR snapd#4583 opened: many: pull apart develoepr and publisher <Created by mvo5> <https://github.com/snapcore/snapd/pull/4583> | 11:48 |
| mvo | Chipaca: -^ we talked about the developer/publisher entanglement. the above may help, feedback welcome (cc pedronis) | 11:48 |
| mvo | ogra_: thanks, I have a look this afternoon, just wanted to finish the above PR | 11:48 |
| ogra_ | mvo, yeah, i just wanted a papertrail | 11:51 |
| Chipaca | mvo: have you talked with snapcraft and store people about that? | 11:58 |
| pedronis | mvo: developer_id in the store is the publisher ATM | 12:00 |
| pedronis | and we don't track the developer much really (it's an open task but I don't see it happen soon) | 12:01 |
| pedronis | mvo: basically without starting from the store this will just confuse us more | 12:02 |
| greyback | zyga: quick qn: I accidentally pushed a commit to my branch, and have commited a revert. Would you rather I redo the branch to have a cleaner history? (https://github.com/snapcore/snapd/pull/4545/commits) | 12:02 |
| mup | PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545> | 12:02 |
| zyga | greyback: nah, just --force push | 12:03 |
| zyga | greyback: drop that commit and push the right one | 12:04 |
| mvo | pedronis: uh, developer_id is publisher_id? and developer_name is also publisher_name? | 12:04 |
| pedronis | yes | 12:04 |
| pedronis | in the new APIs | 12:04 |
| pedronis | they will be called publisher | 12:04 |
| pedronis | basically I don't think this makes much sense | 12:04 |
| pedronis | until we have a new details API | 12:04 |
| mvo | pedronis: fair enough, I will extract the interessting bits from the PR and close it after | 12:05 |
| pedronis | mvo: the only place where we get the developer would be snap-revision, but that is also not true atm | 12:06 |
| pedronis | because of historical reasons | 12:06 |
| mvo | pedronis: what do we get there? | 12:06 |
| pedronis | again the publisher | 12:06 |
| mvo | /o\ | 12:06 |
| mvo | ok | 12:06 |
| pedronis | as I said until it is fixed/improved in the store | 12:07 |
| pedronis | adding the distinction in snapd is not super useful | 12:07 |
| pedronis | we could start adding publisher == developer in packages.go | 12:07 |
| pedronis | I suppose | 12:07 |
| pedronis | but not much else | 12:07 |
| mvo | pedronis: so you think we should not expose ddeveloper at all in the rest api? or just not yet ? | 12:08 |
| mvo | pedronis: I'm fine starting with developer = publisher for now and provide publisher via the rest api and then users can transition to the new field. does that make sense? | 12:08 |
| pedronis | yes, that make sense | 12:09 |
| pedronis | the changes in store/ are problematic | 12:09 |
| mvo | pedronis: great, I will update the PR accordingly and add some big explanation around this to avoid further confusion | 12:09 |
| mvo | pedronis: sure, I will revert those | 12:10 |
| mvo | pedronis: well, revert and add comments | 12:10 |
| mvo | pedronis: thanks for your input! | 12:10 |
| pedronis | it's a bit my fault | 12:11 |
| mup | PR snapd#4583 closed: many: pull apart develoepr and publisher <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4583> | 12:11 |
| pedronis | PublisherID | 12:11 |
| pedronis | and -info.PublisherID = d.DeveloperID | 12:11 |
| pedronis | at some point | 12:11 |
| pedronis | but didn't add a comment | 12:11 |
| * mvo nods | 12:11 | |
| pedronis | mvo: also we don't capture the string because we go from id to strings using the account assertion | 12:13 |
| mvo | pedronis: should we remove the string then? | 12:13 |
| pedronis | we didn't have it before | 12:13 |
| pedronis | there was no publisher | 12:14 |
| pedronis | I mean all of store changes need to be reverted | 12:14 |
| * zyga takes a break to lay down, back pain | 12:14 | |
| mvo | pedronis: aha,ok, I misunderstood | 12:14 |
| mvo | pedronis: yes, will do that | 12:14 |
| pedronis | and maybe added comments | 12:14 |
| pedronis | that means also some bit of snap/info.go go away | 12:14 |
| pedronis | as well | 12:14 |
| mvo | pedronis: thanks, I will do that (and revert bits in info.go too) | 12:18 |
| * zyga will skip standup today, not so fun from bed; I'm not feeling good for the last few hours and I'm trying to write docs and examples on new features | 12:39 | |
| kalikiana | zyga: clearly writing docs is bad for your health :-P | 12:42 |
| mup | PR snapd#4584 opened: Introduce LimitedWriter to limit the number of data read from the std… <Created by stolowski> <https://github.com/snapcore/snapd/pull/4584> | 12:57 |
| Odd_Bloke | I'm seeing some really weird issues trying to use snapcraft ATM. | 13:19 |
| Odd_Bloke | I have lxd installed as a deb, but `snapcraft cleanbuild` fails with: subprocess.CalledProcessError: Command '['lxc', 'file', 'push', '/home/daniel/snap/lxd/common/snapcraft_8v82248/core_3887.assert', 'local:snapcraft-paretically-cressiest-elana/run/core_3887.assert']' returned non-zero exit status 1. | 13:20 |
| Odd_Bloke | That path looks extremely suspicious. | 13:20 |
| Odd_Bloke | (Also, when using a remote lxd, there's no reason to believe that the local path will exist at all snap or otherwise.) | 13:21 |
| Odd_Bloke | So I think to myself, "fair enough, let's just build locally for now", and then pip segfaults: subprocess.CalledProcessError: Command '['/bin/sh', '/tmp/tmp9uadnku3', '/home/daniel/dev/cloud-test-framework/parts/cloud-test-framework/install/usr/bin/python2', '-m', 'pip']' died with <Signals.SIGSEGV: 11>. | 13:21 |
| Odd_Bloke | I see the lxd issue on both the edge and stable snaps; it looks like the stable snap might not have the local-build issue. | 13:26 |
| * kalikiana moving to coffee shop for lunch | 13:28 | |
| ackk | hi, is there a way to get locales to work in a snap? can they be included in the snap itself? | 13:52 |
| ogra_ | ackk, while this is a very old snap, the wrapper stuff should still work i the new world http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/nethack.sh | 13:56 |
| ogra_ | (check the stage-packages in snapcraft.yaml too) | 13:57 |
| ackk | ogra_, thanks | 13:58 |
| mup | PR snapd#4583 opened: many: pull apart develoepr and publisher <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4583> | 14:13 |
| * pstolowski lunch | 14:16 | |
| mborzecki | pstolowski: left you some comments in 4584 | 14:25 |
| mup | PR snapd#4585 opened: daemon: refactor snapFooMany helpers a little <Created by chipaca> <https://github.com/snapcore/snapd/pull/4585> | 14:30 |
| pstolowski | mborzecki, thanks | 14:31 |
| sergiusens | kalikiana please look into Odd_Bloke's issue with lxd | 14:31 |
| kalikiana | re | 14:34 |
| mup | PR snapd#4586 opened: cmd/snap: add completion conversion helper to increase DRY <Created by chipaca> <https://github.com/snapcore/snapd/pull/4586> | 14:35 |
| === juergh_ is now known as juergh | ||
| kalikiana | Odd_Bloke: Did you see any errors from lxc? That is, before the Python error message | 14:37 |
| kalikiana | Odd_Bloke: Also, what are you finding suspicious there? Snapcraft creates a temporary folder in ~/snap/lxd/common to store files that will be pushed into the container | 14:38 |
| sergiusens | kalikiana both kyrofa and popey saw this yesterday too | 14:49 |
| Odd_Bloke | kalikiana: Well, I don't have the lxd snap installed, so that's a weird path to use. | 14:50 |
| Odd_Bloke | (Also, this isn't the lxd snap, so that's a weird path to use even if I did have it installed.) | 14:51 |
| Odd_Bloke | Surely that should be in ~/snap/snapcraft... ? | 14:51 |
| mup | PR snapcraft#1904 opened: lxd: raw.idmap expects host and container id respectively <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1904> | 14:51 |
| Odd_Bloke | But also, the path it thinks should exist there doesn't, which is a definite problem. | 14:51 |
| kalikiana | Odd_Bloke: That path is used so the lxd snap can read the files despite confinement when you use it. It's removed after Snapcraft is done, so it would indeed be empty if you're looking for it afterwards | 14:56 |
| kalikiana | sergiusens: Is it related to bug 1746612 ? I tried it with the lxd in Xenial earlier. I still need to try with the backports version as well to see if that's different | 14:57 |
| mup | Bug #1746612: Snapcraft cleanbuild doesn't work if you're not using the LXD snap <Snapcraft:New> <https://launchpad.net/bugs/1746612> | 14:57 |
| Odd_Bloke | kalikiana: https://paste.ubuntu.com/26501059/ is the full log. | 14:59 |
| Odd_Bloke | Basically the file that snapcraft is telling lxd to use isn't present. | 14:59 |
| kalikiana | Odd_Bloke: Thanks! | 14:59 |
| kalikiana | Odd_Bloke: Actually, does ~/snap/lxd not exist at all? Snapcraft should be creating it | 14:59 |
| Odd_Bloke | It does. | 14:59 |
| kalikiana | Or is it empty? | 14:59 |
| Odd_Bloke | I wiped it out earlier, and it does still have stuff in there. | 15:00 |
| Odd_Bloke | /home/daniel/snap/lxd/common/snapcraftyu2pnqwq looks like it was just created by my cleanbuild run. | 15:00 |
| kalikiana | Odd_Bloke: It should've re-created folder regardless of the lxd snap being there | 15:01 |
| kalikiana | Although I can appreciate that it seems a little "odd" | 15:01 |
| kalikiana | Odd_Bloke: On my system I can see ~/snap/lxd/common with no contents even after removing ~/snap/lxd | 15:03 |
| kalikiana | Not sure if there's some other intermediary step I'm overlooking | 15:03 |
| kalikiana | Odd_Bloke: btw which version of lxd are you using? ie. `apt show lxd | grep Version` | 15:07 |
| Odd_Bloke | Why would ~/snap/lxd/common exist if you've removed ~/snap/lxd? | 15:08 |
| kalikiana | Odd_Bloke: Because Snapcraft creates it :-) | 15:08 |
| Odd_Bloke | That is all sorts of crazy, IMO. | 15:08 |
| Odd_Bloke | But whatever. | 15:08 |
| Odd_Bloke | I'm running lxd 2.21-0ubuntu2 (in bionic). | 15:09 |
| kalikiana | Odd_Bloke: If LXD is confined, it can't read arbitrary stuff in your ~ | 15:09 |
| Odd_Bloke | Sure, but my lxd isn't confined, nor is it even local, so snapcraft shouldn't create random folders in my filesystem. | 15:09 |
| Odd_Bloke | But I don't particularly care about that ATM, it doesn't work even doing that. :p | 15:10 |
| Odd_Bloke | kalikiana: OK, hold on, that file does exist locally. But /var/lib/snapd/hostfs/ is empty. | 15:11 |
| * kalikiana wishes Launchpad's search wasn't so terrible, trying to confirm if this is related to another known issue | 15:15 | |
| * kalikiana can't even find *this* bug report by searching for it... | 15:15 | |
| zyga | kalikiana: hey | 16:07 |
| zyga | zyga@fyke:~/content-interface-2.0/hub-app$ snapcraft | 16:07 |
| zyga | Issues while validating snapcraft.yaml: Additional properties are not allowed ('license' was unexpected) | 16:07 |
| zyga | where can I specify the license? | 16:07 |
| kalikiana | zyga: Where did you try to put it? It should be a toplevel item like summary or description | 16:11 |
| zyga | kalikiana: yeah, there | 16:11 |
| zyga | snapcraft, version 2.34+17.10 | 16:12 |
| zyga | kalikiana: I put | 16:12 |
| zyga | license: MIT | 16:12 |
| kalikiana | zyga: can you paste the YAML somewhere? then I can double-check if it works here | 16:14 |
| zyga | sure | 16:15 |
| zyga | http://paste.ubuntu.com/26501365/ | 16:15 |
| kalikiana | zyga: Doesn't seem to work indeed.... not sure tbh | 16:22 |
| zyga | seems like something that fits the overal license work now | 16:23 |
| zyga | niemeyer: ^ FYI (on license) | 16:31 |
| niemeyer | Can we please not have yet another thread here? We have two topics in the forum active right now on this topic. | 16:31 |
| zyga | niemeyer: not a thread, just pointing out that it seems setting license via snapcraft doesn't work | 16:32 |
| niemeyer | zyga: Sounds like something worth pointing out in the right topic, in the forum? | 16:32 |
| zyga | sure, I'll add it to snap-license-metadata thread | 16:33 |
| zyga | niemeyer: thank you! | 16:41 |
| * zyga feels better now, gets back to work | 16:41 | |
| * kalikiana feeling a little exhausted from all the debugging today, going to wrap up | 16:48 | |
| niemeyer | zyga: Thanks for reporting | 16:54 |
| greyback | anyone mind hitting merge on this, it should be good to go: https://github.com/snapcore/snapd/pull/4572 | 17:01 |
| mup | PR #4572: mir: software clients need access to shared memory /dev/shm/#* <Created by gerboland> <https://github.com/snapcore/snapd/pull/4572> | 17:01 |
| zyga | greyback: looking | 17:02 |
| zyga | ah | 17:02 |
| zyga | yes | 17:02 |
| zyga | merged :) | 17:03 |
| mup | PR snapd#4572 closed: mir: software clients need access to shared memory /dev/shm/#* <Created by gerboland> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4572> | 17:03 |
| zyga | thank you! :) | 17:03 |
| greyback | zyga: sweet, thank you | 17:03 |
| greyback | and I'll just leave https://github.com/snapcore/snapd/pull/4545 hovering in the background :) | 17:03 |
| mup | PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545> | 17:03 |
| jdstrand | jjohansen: thanks. I think tyhicks gave ogra_ the additional details he needed | 17:05 |
| zyga | greyback: will that shirnk when you merge master? | 17:05 |
| zyga | jdstrand: hey, do you have 2 minutes for a quick chat? | 17:05 |
| ogra_ | jdstrand, yeh, but i dont see the filesystem either way (though at least htis kernel now has syscall filtering enabled which is missing in the sample-kernels tree) | 17:05 |
| jdstrand | zyga: I think so | 17:06 |
| jdstrand | zyga: go ahead | 17:06 |
| greyback | zyga: no unfortunately | 17:06 |
| greyback | it's a non-trivial one | 17:06 |
| greyback | no rush though | 17:06 |
| zyga | ok | 17:07 |
| tyhicks | ogra_: what do you mean by "can't see the filesystem"? it isn't in /proc/filesystems or it isn't mounted at /sys/sys/bpf/ ? | 17:11 |
| ogra_ | tyhicks, /proc/filesystems | 17:11 |
| tyhicks | ogra_: what kernel version? | 17:11 |
| ogra_ | btw it is a 4.1 tree | 17:11 |
| tyhicks | ogra_: ah, I mentioned yesterday that the bpf filesystem first showed up in 4.4 | 17:12 |
| ogra_ | (and effectively a throw-away kernel ... we'll get a 4.4 later) | 17:12 |
| ogra_ | ah, ok | 17:12 |
| tyhicks | the code isn't there in 4.1 | 17:12 |
| mup | PR snapd#4587 opened: osutil: make MkdirAllChown clean the path passed in <Created by chipaca> <https://github.com/snapcore/snapd/pull/4587> | 17:12 |
| ogra_ | well, at least the missing of it in /proc/filesystems got me on the right track :) | 17:12 |
| tyhicks | :) | 17:12 |
| Chipaca | 4 small (biggest is ~100 lines) and easy (sez me) PRs up by me if you're feeling like doing reviews | 17:14 |
| cachio_ | pedronis, hey, I see this error on dragonboard after I refresh to beta from stable | 17:37 |
| cachio_ | https://paste.ubuntu.com/26501684/ | 17:37 |
| cachio_ | pedronis, any idea what could be causing that? | 17:38 |
| niemeyer | I've just found out that apparently "skype" and "snap" is a trigger for adult content in social media | 17:39 |
| mup | PR snapd#4588 opened: Snapshots! <Created by chipaca> <https://github.com/snapcore/snapd/pull/4588> | 17:41 |
| Chipaca | <<<<< ^^^^ >>>>>> | 17:41 |
| Chipaca | or something | 17:42 |
| * Chipaca goes for a cuppa tea | 17:42 | |
| Chipaca | before I go just let me say that <+2,226 −77> might be a little intimidating (but read the description) | 17:43 |
| * ogra_ finally runs "snap alias snapcraft sergiusens" | 17:44 | |
| Chipaca | ogra_: snap alias --internal install remove | 17:47 |
| * Chipaca runs to see about that tea | 17:47 | |
| ogra_ | uuuh, mean ! | 17:47 |
| ogra_ | (i was just reacting to niemeyer's typo and sergios funny comment here ) | 17:48 |
| mvo | Chipaca: wooo! | 17:48 |
| mup | PR snapd#4583 closed: many: pull apart develoepr and publisher <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4583> | 17:48 |
| niemeyer | ogra_: typo? | 17:51 |
| ogra_ | niemeyer, you called him "@snapcraft" ;) | 17:52 |
| ogra_ | freudian typo :) | 17:52 |
| ogra_ | (on the forum) | 17:52 |
| niemeyer | ogra_: I see.. "typo" :) | 17:59 |
| ogra_ | heh | 17:59 |
| niemeyer | Would be nice if snapcraft could respond.. would make things easier | 17:59 |
| ogra_ | well... all w need is a mycroft snap and teach it to react to "snapcraft" ... | 18:00 |
| mup | PR snapd#4589 opened: many: remove "content" argument from snaptest.MockSnap() <Created by mvo5> <https://github.com/snapcore/snapd/pull/4589> | 18:00 |
| * ogra_ looks forward to "voice based yaml validation" | 18:02 | |
| pedronis | cachio_: my guess is that something is off with the time on that board | 18:28 |
| mup | PR snapcraft#1905 opened: Remove dangling symlink from JDK plugin (LP Bug #1617296) <Created by ARostovsky> <https://github.com/snapcore/snapcraft/pull/1905> | 18:46 |
| zyga | FAIL: cmd_userd_test.go:62: userdSuite.TestUserd | 18:54 |
| zyga | cmd_userd_test.go:84: | 18:54 |
| zyga | c.Assert(err, IsNil) | 18:54 |
| zyga | ... value *errors.errorString = &errors.errorString{s:"cannot obtain bus name 'io.snapcraft.Launcher'"} ("cannot obtain bus name 'io.snapcraft.Launcher'") | 18:54 |
| zyga | hmm | 18:54 |
| mup | PR snapcraft#1903 closed: elf: use surrogate escape when decoding readelf output <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1903> | 19:31 |
| mup | PR snapcraft#1906 opened: remote_parts: handle connection errors <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1906> | 19:34 |
| mup | PR snapcraft#1907 opened: tests: setup the correct environment for adt <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1907> | 19:43 |
| bartkmq | how do i get firefox to open snap:// links (from snapcraft.io) on Arch? is that an ubuntu only feature? | 20:17 |
| kyrofa | Yeah that's typically handled by the software center | 20:18 |
| bartkmq | kyrofa, thanks for the tip, installing gnome-software fixed the problem | 20:51 |
| mup | PR snapd#4590 opened: cmd/snap-confine: allow constructing layouts (phase 1) <Created by zyga> <https://github.com/snapcore/snapd/pull/4590> | 21:15 |
| zyga | :-) | 21:21 |
| * zyga ends with working layouts :) | 21:21 | |
| zyga | I think it's time to EOD | 21:22 |
| zyga | kyrofa: hey | 21:22 |
| zyga | kyrofa: is LXD okay for you now? | 21:22 |
| zyga | bartkmq_: please open a forum topic, we'll get it to work on arch as well | 21:22 |
| zyga | bartkmq_: one of the snapd developers uses arch as his main system | 21:23 |
| zyga | we'll get it fixed | 21:23 |
| * zyga is super excited | 21:29 | |
| zyga | *layouts* | 21:29 |
| zyga | jjohansen: o/ | 21:31 |
| zyga | Chipaca: o/ | 21:41 |
| Chipaca | zyga: \o | 21:41 |
| Chipaca | zyga: you suck at EODing | 21:42 |
| zyga | yeah | 21:42 |
| zyga | have you EODed? | 21:42 |
| zyga | if not, would you like to eyeball that PR above? | 21:44 |
| jamesh | zyga: hi. I've been looking at trying to verify that a mount occurred as expected via /proc/self/mountinfo. It works for the simple cases, but seems to get tripped up when it gets called while creating writable mimics. | 22:38 |
| jamesh | zyga: I'm trying to work out if this code is a lost cause, and jdstrand suggested you might have an idea | 22:38 |
| zyga | jamesh: I'm about to close my laptop, can you please write me a small example (email/forum) and I will help you out tomorrow | 22:45 |
| zyga | jamesh: IMO it's hard | 22:45 |
| jamesh | zyga: sure. | 22:45 |
| zyga | jamesh: based on my experience and prior analysis | 22:46 |
| zyga | because the mountinfo shows what is mounted | 22:46 |
| zyga | not how it was achieved | 22:46 |
| zyga | while fstab-like entries show how to achieve something | 22:46 |
| zyga | but doesn't describe the prior state or capture how the state is tranformed | 22:46 |
| zyga | so it's non-trivial to answer a question "has <fstab-mount-entry> been mounted" | 22:47 |
| zyga | and that's why the design of update / undo logic in snap-update-ns is focused on the fstab profiles alone | 22:47 |
| zyga | and not on mountinfo as that is very complex (also because snap-confine does a lot of stuff) | 22:47 |
| zyga | but I may have misundertood your question as it's super late now | 22:48 |
| zyga | give me an example to work with and I'll help as much as I can | 22:48 |
| jdstrand | zyga: he's trying to verify we mounted correctly | 22:51 |
| jdstrand | zyga: the dst mountpoint is easy to verify since it has the full path of the mountpoint | 22:51 |
| jdstrand | zyga: but the source mount gets truncated in various scenarios. so, if he mount $XDG_RUNTIME_DIR/foo/bar, he might only see /foo/bar instead of /run/user/1000/foo/bar | 22:52 |
| zyga | jdstrand: ! | 22:52 |
| zyga | thanks | 22:52 |
| zyga | I see | 22:52 |
| zyga | how is mount source truncated | 22:53 |
| zyga | mount source is always <device,filesystem,subtree> | 22:53 |
| zyga | jdstrand: *thank you for the review* | 22:53 |
| jdstrand | zyga: so, XDG_RUNTIME_DIR is a tmpfs already which may be part of it. jamesh can give specific examples | 22:54 |
| jamesh | jdstrand: I was able to handle that case by combining the mount source with the mount destination of the parent mount | 22:55 |
| jdstrand | ah, cool | 22:55 |
| zyga | jdstrand: I replied on the review, I'll tweak the things that are simple but check one of the things I contended with | 22:56 |
| jamesh | it seems the be the writable mimic tmpfs that was causing the problem. I was expecting to compute "/snap/test-snapd-content-advanced-plug/x1" as a source and got "/tmp" | 22:56 |
| zyga | jamesh: how do oyu compute that? | 22:56 |
| zyga | jdstrand: about your main question, we could just abort startup if mount fails | 22:58 |
| zyga | jdstrand: not ignore and carry on | 22:58 |
| zyga | jdstrand: I'd like that actually | 22:58 |
| jamesh | zyga: I first search through mountinfo for an entry that matches the destination mount point. I then search for the parent mountinfo entry, and combine the parent's mount point with the original entry's root field | 22:58 |
| jamesh | that seemed to be enough for the simple cases | 22:58 |
| zyga | jamesh: hmm, I'm not sure yet; I will need an example with some data to read and think through | 22:59 |
| jamesh | zyga: I'll put together an email for you to read tomorrow | 22:59 |
| zyga | thank you | 22:59 |
| jamesh | it must be almost midnight for you | 23:00 |
| zyga | jdstrand: please recheck my responses | 23:02 |
| zyga | jdstrand: I think it's correct as-is unfortunately | 23:03 |
| jdstrand | zyga: abort startup would be fine. layouts aren't dynamic like content interface connections | 23:06 |
| zyga | jdstrand: I can tag layouts with x.snapd=mandatory | 23:06 |
| zyga | and abort on such entries | 23:06 |
| zyga | should we abort on content things as well? | 23:06 |
| zyga | I'm not sure why we didn't | 23:07 |
| jdstrand | zyga: aborting makes sense anyway-- if it doesn't get the layout it needs, it has little chance of working correctly | 23:07 |
| zyga | yeah | 23:07 |
| zyga | I think that's sensible | 23:07 |
| jamesh | it'd probably be simpler to abort on the other mount failures | 23:07 |
| zyga | and would be better in case if prior mount is a base for next operation | 23:07 |
| jdstrand | it is nice when logic and security go hand in hand :) | 23:07 |
| zyga | it's uncertain what happens in that case | 23:07 |
| jdstrand | btw, I responded to your comments | 23:08 |
| zyga | jamesh: Day changed to 02 lut 2018 | 23:08 |
| zyga | :) | 23:08 |
| * zyga checks | 23:08 | |
| zyga | jdstrand: I'm happy we got here | 23:09 |
| zyga | I wish we had more vocabulary in appamor | 23:09 |
| zyga | and I know it's not a 2.31 goal anymore | 23:09 |
| zyga | I think we need those per-snap profiles, yeah | 23:09 |
| zyga | otherwise this is very open and broad | 23:09 |
| jdstrand | apparmor is great, but yeah, like so many other parts of snapd, we are pushing the limits | 23:09 |
| zyga | jdstrand: on the other hand | 23:10 |
| jdstrand | zyga: per snap profiles would make this way more palatable, yes, but we can tightly control what is added | 23:10 |
| zyga | *it works* :) | 23:10 |
| jdstrand | because* | 23:10 |
| jdstrand | the fact that it works is excellent! | 23:10 |
| zyga | I wrote a test snap with layouts, I will use it as a base for spread test tomorrow | 23:11 |
| jdstrand | I wouldn't mind this being committed to master once the other points go through on the precondition that a 2.32 milestoned second PR adds snap-update-ns profiles | 23:11 |
| zyga | jdstrand: wait, which other points? | 23:11 |
| zyga | the comment? | 23:11 |
| jdstrand | we forgot to talk about what that would look like | 23:11 |
| zyga | and wait, are you saying it's okay to merge this for 2.31? | 23:12 |
| jdstrand | the comments and the fixes to the rules you agreed to. the small stuff | 23:12 |
| jdstrand | I am expressly *not* saying to merge this for 2.31 :) | 23:12 |
| jdstrand | I'm saying it is good for *master* now so long as 2.32 has a milestoned second PR to add per-snap s-u-n profiles | 23:12 |
| jdstrand | s/now/now, so long as the other bits are addressed/ | 23:13 |
| zyga | jdstrand: ah, I understand now | 23:13 |
| jdstrand | but I'll let mvo decide on that | 23:13 |
| zyga | jdstrand: can you please add a comment about which things require no changes (for me and mvo) | 23:13 |
| jdstrand | ok | 23:13 |
| zyga | thank you | 23:14 |
| zyga | jdstrand: so 2.32 will have per snap s-u-n profiles and will be ok for release, right? | 23:15 |
| zyga | (and now it's not) | 23:15 |
| zyga | http://paste.ubuntu.com/26502895/ | 23:17 |
| zyga | this is what I changed so far | 23:17 |
| zyga | (based on the discussion above) | 23:17 |
| jdstrand | zyga: +1 | 23:21 |
| zyga | pushed | 23:22 |
| jdstrand | zyga: I've commented in the PR. since it is so late for you, maybe we pick up on monday how to implement the per-snap s-u-n profiles? | 23:22 |
| zyga | jdstrand: if you tell me now it will be read tomorrow :) | 23:23 |
| zyga | (or just write it, I will read it again in the morning) | 23:24 |
| jdstrand | zyga: I think the only sane way is to create a template that removes the fixme rules (and any others that are too general), then construct it like the other profiles | 23:24 |
| jdstrand | zyga: ideally they would live in /var/lib/snapd/apparor/profiles, but that isn't a strict requirement | 23:25 |
| zyga | jdstrand: yeah, I plan to do that | 23:25 |
| zyga | jdstrand: we have a namespace | 23:25 |
| zyga | jdstrand: the tricky thing (for me, it's probably easy) is how to construct the header | 23:25 |
| zyga | and what's the apparmor C api to switch to a named profile (probably in the man page) | 23:26 |
| zyga | I would call the profiles "snap-update-ns for $SNAP_NAME" (with proper syntax, suggestions welcome) | 23:26 |
| jdstrand | zyga: you'll need to update the code to change_onexec/change_profile (I can't remember otoh which you are using) to this profile for the s-u-n operation | 23:26 |
| jdstrand | zyga: snap-update-ns.$SNAP_NAME ? | 23:27 |
| jdstrand | zyga: both on disk and the profile name | 23:27 |
| zyga | +1 | 23:28 |
| zyga | yeah, looks good and doesn't clash | 23:28 |
| zyga | and I would do it for *all* snaps | 23:28 |
| zyga | no need to fall back | 23:28 |
| jdstrand | you technically don't need to do it for all snaps. | 23:28 |
| zyga | mmm, | 23:29 |
| jdstrand | you *could* use the child profile for non-layouts snap-update-ns calls, and the other for layouts calls | 23:29 |
| zyga | but snap-confine will now have to *explicitly* set profile for snap-update-ns | 23:29 |
| jdstrand | but I think that is apremature optimization | 23:29 |
| zyga | yeah, I agree | 23:29 |
| jdstrand | if we find the number unreasonable or whatever, we can change to that | 23:29 |
| zyga | if those are identical will apparmor optimize those? | 23:30 |
| jdstrand | no | 23:30 |
| zyga | mm, ok | 23:30 |
| zyga | we could look at that then, just not in 1st branch | 23:31 |
| jdstrand | so there is compile time and kernel memory. at somepoint we'll have the ability to work with templates better, and sttitch things together | 23:31 |
| jdstrand | so you could load the template rules, and then say 'ad these' for foo and 'add these' for bar | 23:31 |
| jdstrand | then the size is template + foo + bar instead of template_ foo + template+ bar | 23:32 |
| jdstrand | size and compile time | 23:32 |
| zyga | yeah but for the simple case where profiles "foo" and "bar" are *identical* and not associated with a path | 23:32 |
| jdstrand | but we don't have that. it is planned | 23:32 |
| zyga | that will be the same blob to load | 23:32 |
| zyga | is that also not optimized? | 23:32 |
| jdstrand | no | 23:32 |
| zyga | ok | 23:32 |
| zyga | btw, what's the right header ? | 23:32 |
| jdstrand | they aren't actually identical-- the profile name is different :) | 23:33 |
| jdstrand | the contents are identical though | 23:33 |
| zyga | ahh, right | 23:33 |
| zyga | good point | 23:33 |
| jdstrand | e can achieve what you want there by doing what I said-- only using a child or otherwise named profile and transitioning to that. means added code complexity | 23:33 |
| jdstrand | as opposed to apparmor just doing it | 23:33 |
| jdstrand | it probably wouldn't be terrible to do that. think about it | 23:34 |
| zyga | k | 23:34 |
| zyga | @LIBEXECDIR@/snap-confine (attach_disconnected) { | 23:34 |
| zyga | so in the new profiles will that look like | 23:34 |
| zyga | snap-update-ns.hello (attach_disconnected) { ... } | 23:35 |
| jdstrand | so the profile change itself is the simple aa_change_onexec | 23:36 |
| jdstrand | zyga: yes | 23:36 |
| zyga | cool | 23:36 |
| zyga | I'll get it done first thing tomorrow | 23:36 |
| zyga | if rc3 comes along it _may_ be in 2.31 | 23:36 |
| zyga | 2.32 is in a month | 23:36 |
| jdstrand | zyga: instead of the Cx rules, you'll add to snap-confine's profile: change_profile -> snap-update-ns.*, | 23:37 |
| zyga | thank you, that's a good point | 23:37 |
| jdstrand | zyga: ok, I won't be able to review this until monday, but if it is there monday morning, I can do it first | 23:38 |
| zyga | that's okay | 23:38 |
| zyga | I will review the bulk of it with mvo and gustavo | 23:38 |
| zyga | and we'll see what to do about it | 23:38 |
| zyga | thank you, I think it's closer than ever now :) | 23:39 |
| mup | PR snapcraft#1880 closed: Provide stub for when /etc/os-release doesn't exist <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1880> | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!