| mborzecki | morning | 06:13 |
|---|---|---|
| mvo | hey mborzecki | 06:15 |
| mborzecki | mvo: hey | 06:15 |
| mup | PR snapd#6592 opened: cmd/snap-seccomp: version-info subcommand <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6592> | 06:47 |
| zyga | Hey guys :-) | 06:48 |
| mborzecki | zyga: hey | 06:48 |
| zyga | I missed that review | 06:48 |
| zyga | 1st thing today | 06:48 |
| mborzecki | zyga: which one? | 06:49 |
| zyga | Seccomp | 06:50 |
| pedronis | I asked to split it | 06:51 |
| pedronis | I put a comment in it about that | 06:53 |
| pedronis | now | 06:53 |
| mup | PR snapd#6593 opened: sandbox/seccomp: a helper package wrapping calls to snap-seccomp <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6593> | 06:56 |
| mborzecki | pedronis: thanks | 06:56 |
| mborzecki | zyga: i've pulled out the version-info subcommand and sandbox/seccomp into separate packages | 06:56 |
| mborzecki | zyga: left a comment under #6588 hopefully it makes sense for the discussion | 07:12 |
| mup | PR #6588: interfaces/apparmor: partial confinement on openSUSE <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6588> | 07:12 |
| zyga | ack, thank you | 07:14 |
| mvo | xnox: about the systemd sru - for bionic I prepared http://paste.ubuntu.com/p/gkm5MFpYXT/ - if this looks ok I will upload after my testing is complete | 07:40 |
| mup | PR snapd#6589 closed: daemon: support returning assertion information as JSON with the "json" query parameter <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6589> | 07:47 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 07:58 |
| zyga | hey pawel | 08:02 |
| mvo | hey pstolowski | 08:03 |
| dot-tobias | good morning everyone | 08:03 |
| pedronis | mborzecki: I did a pass on those split out PRs, I mostly have questions atm | 08:44 |
| mborzecki | pedronis: thanks | 08:45 |
| mup | PR snapd#6585 closed: tests: add undo test with hanging stop command <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6585> | 08:48 |
| * zyga breakfast | 08:51 | |
| zyga | re | 09:15 |
| zyga | ondra: hey, did you have the chance to file those bugs? | 09:25 |
| zyga | mborzecki: there's a potentially interesting bug or kernel "feature" | 09:25 |
| mborzecki | zyga: hm? which one? | 09:25 |
| zyga | mborzecki: ondra has the details but seems like inconsistency of what snap-discard-ns sees | 09:26 |
| zyga | I cannot explain it yet | 09:26 |
| ondra | zyga sorry, I have not, working on them now | 09:26 |
| zyga | thanks! | 09:26 |
| mborzecki | zyga: the thing with processes/thread still runnin in the cgroup? | 09:26 |
| zyga | mborzecki: no, with fstatfs saying one thing to snap-discard-ns and another to shell (which implies something is missing because this is unlikely) | 09:27 |
| mborzecki | oh | 09:27 |
| mborzecki | zyga: do you have more details? | 09:29 |
| zyga | mborzecki: snap-discard-ns fails because it gets EBUSY on unlink of .mnt file | 09:29 |
| zyga | mborzecki: having statted it, seeing it is a tmpfs so nothing to unmount | 09:29 |
| pedronis | Chipaca: hi | 09:33 |
| pedronis | Chipaca: I did pas over the epochs doc, here the texts in the boxes in the epochs svg diagram overflow them and also look smushed up, is that just my browser? | 09:35 |
| pedronis | Chipaca: degville: I confess, I made also some pedantic tweaks/additions | 09:36 |
| Chipaca | pedronis: can i see a screenshot? | 09:36 |
| Chipaca | pedronis: as I said yesterday, the whole thing is very disjointed right now so anything helps :-) | 09:36 |
| pedronis | well I added more info | 09:37 |
| pedronis | not sure that helps | 09:37 |
| Chipaca | pedronis: I'd originally pushed the diagram as a png, then re-pushed as an svg hoping it'd be clearer (hidpi being a thing) | 09:37 |
| pedronis | Chipaca: it renders better, just now, go figure but still not 100% | 09:37 |
| degville | pedronis: Chipaca: no problem. It all helps, but I was waiting until Chipaca had finished editing before I took a proper look. | 09:37 |
| Chipaca | degville: all the information is there (i think); i could come back to it in a couple of days if it still needs restructuring then :-) | 09:42 |
| Chipaca | need a couple of days head-space | 09:42 |
| Chipaca | dunno why | 09:42 |
| degville | Chipaca: honestly, that's exactly what I'm like. I think of it like composting my thoughts :) | 09:43 |
| Chipaca | :-) | 09:44 |
| pedronis | degville: as I said, I looked at it, I think most information is there now, it's not fluid as Chipaca mentioned | 09:44 |
| Chipaca | also it's not clear (to me) that the graphic adds anything to it :-) but it helps write it at least | 09:45 |
| degville | pedronis: yep, thanks. I'll take a look. | 09:45 |
| Chipaca | pedronis: did you mean to write "...a revert that snapd doesn't block", vs. "...a revert, that snapd doesn't lock"? | 09:45 |
| Chipaca | block* | 09:45 |
| pedronis | Chipaca: there's a which there, not a that. Maybe it needs a comma and a that | 09:52 |
| Chipaca | pedronis: a, which and that are (mostly) interchangeable; my point was about the comma | 09:52 |
| Chipaca | or lack of it | 09:52 |
| Chipaca | by which i mean | 09:52 |
| Chipaca | as it stands, it says that some reverts are blocked by snapd | 09:52 |
| Chipaca | or implies it at least | 09:52 |
| Chipaca | which might be fine, if we should block reverts at some point :-) | 09:53 |
| pedronis | I think we should | 09:53 |
| pedronis | when we implement that other plan | 09:53 |
| mborzecki | zyga: pedronis: i'll add a spread test to verify that list of syscalls | 09:54 |
| pedronis | mborzecki: it can be a follow, just trying to understand if we have a plan how to manage it | 09:55 |
| pedronis | Chipaca: feel free to add a comma if it helps | 09:55 |
| mborzecki | pedronis: i'm afradi that's the best we can do for now | 09:56 |
| mup | Bug #1819875 opened: base core16->core18 migration <Snappy:New> <https://launchpad.net/bugs/1819875> | 09:57 |
| ondra | zyga https://bugs.launchpad.net/snappy/+bug/1819875 | 09:58 |
| mup | Bug #1819875: base core16->core18 migration <Snappy:New> <https://launchpad.net/bugs/1819875> | 09:58 |
| mup | PR snapd#6594 opened: [RFC] tests: run smoke tests on (almost) pristine systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/6594> | 09:58 |
| ondra | zyga is this descriptive enough for core16->core18 bug | 09:58 |
| ondra | zyga now creating other bug | 09:58 |
| zyga | ondra: thank you | 09:58 |
| zyga | mvo: ^ that's a very important bug for core18 transition | 09:58 |
| mvo | cjwatson: hey, does https://code.launchpad.net/~mvo/ubuntu-archive-publishing/sync-cnf-metadata/+merge/356117 look ok now with the updated script? | 09:59 |
| mvo | zyga: looking | 09:59 |
| mvo | zyga: uh, ok | 09:59 |
| mvo | zyga: looks scary | 10:00 |
| zyga | I added a comment | 10:00 |
| mvo | zyga: ta | 10:01 |
| zyga | Saviq: ^ important bug for your knowledge on core18 migration | 10:06 |
| cjwatson | mvo: I think so, yes, thanks! I'll work on landing that today | 10:07 |
| mvo | cjwatson: thank you! | 10:07 |
| Saviq | zyga: aha, and was that Multipass that you encountered this with? | 10:14 |
| zyga | no, that's all thanks to ondra | 10:14 |
| zyga | but I recall you added a track to fix some migration issues | 10:14 |
| Saviq | also, would you then recommend to defer the migration until this is solved? | 10:14 |
| zyga | yes | 10:14 |
| zyga | it's a blocker IMO | 10:15 |
| Saviq | :'-| | 10:15 |
| Chipaca | zyga: we touched on this yesterday in the standup | 10:18 |
| Chipaca | fwiw | 10:18 |
| zyga | Chipaca: aha, thanks | 10:21 |
| pedronis | Chipaca: degville: a thing about the epoch docs, we are treating big/slow migration data and SNAP_COMMON (slightly) orthogonally but usually one implies the other, wondering if that can help simplify things a bit or not | 10:23 |
| mvo | xnox: new systemd for bionic is uploaded to -proposed, debdiff is unchanged | 10:24 |
| Chipaca | mvo: is there a reason to leave get-model as a POST? | 10:29 |
| Chipaca | mvo: as opposed to one of the GET options that were mentioned | 10:30 |
| mvo | Chipaca: no reason, I can make this a get of course | 10:30 |
| mvo | Chipaca: so GET and "model" ? | 10:30 |
| ondra | zyga second one with most logs I could collect https://bugs.launchpad.net/snappy/+bug/1819887 | 10:30 |
| mup | Bug #1819887: snap-discard-ns fails <Snappy:New> <https://launchpad.net/bugs/1819887> | 10:30 |
| zyga | ondra: thank you | 10:30 |
| ondra | zyga let me know if there was something missing | 10:30 |
| mvo | pedronis: I uploaded systemd with a fix for the systemctl race to the edge ppa, so the next core will have that package | 10:30 |
| zyga | I will review it | 10:30 |
| mup | Bug #1819887 opened: snap-discard-ns fails <Snappy:New for zyga> <https://launchpad.net/bugs/1819887> | 10:31 |
| Chipaca | mvo: or a GET on /v2/model (was it?) | 10:31 |
| pedronis | Chipaca: as I said that needs design | 10:31 |
| mvo | Chipaca: my understanding was that pedronis did not feel we are ready for this as an official api yet | 10:31 |
| Chipaca | pedronis: ah ok | 10:31 |
| Chipaca | mvo: yes, GET and 'model', i'd like it more | 10:31 |
| Chipaca | mvo: also that would let you not use sudo to get the model | 10:31 |
| Chipaca | mvo: which seems a'ight | 10:31 |
| pedronis | it's not hard design | 10:31 |
| pedronis | but I don't think this should block on that | 10:32 |
| mup | PR snapd#6590 closed: daemon/api: filter connections with hotplug-gone=true <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6590> | 10:38 |
| mup | PR snapd#6098 closed: interfaces/builtin: support hotplug for camera interface <Hotplug 🔌> <⛔ Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/6098> | 10:45 |
| pstolowski | zyga: hey, can you take a look at #6491 again when you have some time? | 10:46 |
| mup | PR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491> | 10:46 |
| zyga | hey, sure, enqueued for today | 10:46 |
| pstolowski | thanks | 10:48 |
| === Guest92 is now known as ewp | ||
| ewp | guys i'm struggling to work something out | 11:09 |
| ewp | as far as i understand it, a snap squashfs is readonly, so building a snapcraft.yaml with an app that has a command line cert-sync $SNAP/etc/ssl/certs/ca-certificates.crt seems like it won't be able to modify the filesystem when the snap is running, so I think running something which would modify the filesystem needs to executed during the build pr | 11:11 |
| ewp | ocess? | 11:11 |
| mup | PR snapcraft#2491 closed: Fix multipass error handling spread test <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2491> | 11:20 |
| mvo | the edge core now has the snapd snap with the updated systemd | 11:22 |
| Chipaca | ok, breaking for gym and lunch, ttfn | 11:29 |
| pstolowski | pedronis: I made a rough estimate for #6591, see last comment | 11:30 |
| mup | PR #6591: [RFC] managers: basic measurements <Created by stolowski> <https://github.com/snapcore/snapd/pull/6591> | 11:30 |
| pedronis | pstolowski: so it's half the size of my current state.json | 11:35 |
| mup | PR snapd#6595 opened: tests: add regression test for systemctl race fix <Created by mvo5> <https://github.com/snapcore/snapd/pull/6595> | 11:36 |
| pstolowski | pedronis: yes, not exactly small | 11:40 |
| mup | PR # closed: snapcraft#1649, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2470, snapcraft#2473, snapcraft#2479, snapcraft#2493, | 11:41 |
| mup | snapcraft#2495, snapcraft#2497, snapcraft#2500, snapcraft#2501 | 11:41 |
| pedronis | pstolowski: whare are these two lines about: | 11:42 |
| pedronis | 85.590985mssetup-profiles, Setup snap "htop" (1168) security profiles | 11:42 |
| pedronis | 85.367741mssetup profiles, setup profiles of snap "htop" | 11:42 |
| pedronis | they seem to say the same stuff? | 11:43 |
| pedronis | are they two entries? | 11:43 |
| pedronis | or just one but the printing repeats it | 11:43 |
| pstolowski | pedronis: we create Timings at the very start of the doSetupProfiles task handler; then we measure the call to m.setupProfilesForSnap(..), that's the second line and it's indented as it's under the task's Timings | 11:49 |
| pstolowski | pedronis: at the moment the structure of these timings more-less reflects call hierarchy in the code | 11:50 |
| pstolowski | that's a bit wasteful, yes. i thought it would make it easier to understand | 11:51 |
| pedronis | pstolowski: we need to be a bit careful because nesting is mental overhead | 12:02 |
| pedronis | though | 12:02 |
| mborzecki | pushing the spread test for syscalls in a bit | 12:05 |
| mborzecki | had to tweak the PR a bit | 12:05 |
| sergiusens | ewp: something like this might help https://docs.snapcraft.io/scriptlets/4892 | 12:09 |
| ewp | ace, looks promising- thank you | 12:09 |
| ewp | if i was going to *-override one of the steps, and wanted to `touch somefile` is there anything else i'd need to do for it to be pulled into the snap, other than just touch it? | 12:12 |
| ewp | i guess just touch in the prime-override step? | 12:13 |
| cachio | mvo, hey, is it ok to promote snapd snap 2.37.4 to stable? | 12:16 |
| pedronis | cachio: you did already, no? | 12:21 |
| pedronis | ah, snapd snap | 12:21 |
| pedronis | sorry | 12:21 |
| cachio | pedronis, :) | 12:25 |
| === ricab is now known as ricab|lunch | ||
| mvo | cachio: yes, if QA is green +1 | 12:30 |
| cachio | mvo, yes it is | 12:31 |
| mvo | cachio: then yes | 12:34 |
| sil2100 | ogra: hey! So pi3 gadget for 16 should have a new version in edge for testing | 12:34 |
| sil2100 | ogra: could you give it a spin? | 12:34 |
| * sil2100 needs to clean up branch permissions again one day | 12:34 | |
| mvo | pedronis: just FYI, I pulled the core snap with the xenial version of the systemd fix as it causes issues, I'm investigating but it seems to be only manifesting itself on core systems, part of the problem is that systemd 229->239 is quite a large jump so the diff is less obvious than its for the bionic verison | 12:35 |
| Wimpress | degville: We are having a Snapathon at Bluefin today. Basically the whole team helping get developers over then line with their snap. | 12:36 |
| Wimpress | It has been great to be able to link directly to our docs in the emails and GitHub issues today. | 12:37 |
| Wimpress | Thanks for all your hard work, it is making this way easier for us! | 12:37 |
| pedronis | mvo: ok, :( | 12:39 |
| pedronis | mborzecki: I made some comment about the compiler lookup, hope they make some sense | 12:39 |
| degville | Wimpress: thanks so much for letting me know - especially as I/we know there's still an awful lot to do, but I really appreciate the feedback. | 12:39 |
| mborzecki | pedronis: yup, saw that, thanks | 12:39 |
| mborzecki | pedronis: zyga: pushed the spread test that checks libseccomp syscalls list | 12:40 |
| cachio | mvo, snpad 2.37.4 in stable | 12:41 |
| cachio | pedronis, ~ | 12:41 |
| pedronis | thx | 12:41 |
| ogra | sil2100, will do (later today) and let you know | 12:41 |
| sil2100 | ogra: thanks o/ | 12:42 |
| cachio | mvo, pedronis I have a school meeting now, I'll try to be back for standup | 12:58 |
| cachio | perhaps I'll be joining late | 12:59 |
| * cachio afk | 13:02 | |
| mborzecki | off to pick up the kids, may arrive a bit late to the standup | 13:17 |
| mvo | cachio: thanks for letting us know | 13:51 |
| zyga | pedronis: I've split the refactoring into small logical chanegs | 13:52 |
| zyga | pedronis: I've kept all the tests in main, only adding new tests | 13:52 |
| zyga | pedronis: and left a few tiny tweaks that were beyond the refactoring | 13:52 |
| zyga | pedronis: I'll run a pass of spread over this | 13:52 |
| zyga | pedronis: then I can push the branch, any prefix of history is a good review candidate | 13:52 |
| pedronis | zyga: ok, this is about 6360 ? | 13:53 |
| zyga | pedronis: from one patch to roughly one third | 13:53 |
| zyga | yes | 13:53 |
| pedronis | zyga: it looked like it could be split in 2 or 3 | 13:53 |
| zyga | (had to double check the PR number :) | 13:53 |
| zyga | pedronis: I can easily make 2-3 PRs now | 13:53 |
| pedronis | ok | 13:53 |
| zyga | pedronis: I just kept the patch granularity smaller for better bisect / review / comments | 13:54 |
| zyga | pedronis: I've started a local spread run, I'll grab lunch and push the branch up and open the first review | 13:54 |
| pedronis | ok | 13:54 |
| pedronis | zyga: we should try to land the snap-confine ones, given it seem it will need further work soon | 13:55 |
| zyga | the things that are different from this version and the monolith are only the retantion of tests in main_test | 13:55 |
| zyga | pedronis: yes, that will be my next task | 13:55 |
| pedronis | ok | 13:55 |
| zyga | pedronis: and the small leak from future work on per-user mount persistence for what the assumptions should look like (harmless but I left it out since it belongs logically with the rest of the persistence work) | 13:56 |
| === ricab|lunch is now known as ricab | ||
| mvo | mborzecki: standup? | 14:03 |
| mborzecki | type=AVC msg=audit(1552471518.269:2577): avc: denied { read } for pid=23614 comm="sshd" name="gai.conf" dev="sda1" ino=594389 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file permissive=0 | 14:14 |
| mborzecki | do we mess with gai.conf in the tests? | 14:14 |
| mborzecki | heh we do | 14:15 |
| Chipaca | zyga, mborzecki: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1810027 | 14:18 |
| mup | Bug #1810027: Snaps won't start - stack smashing detected <snapd (Ubuntu):New> <https://launchpad.net/bugs/1810027> | 14:18 |
| mup | PR snapcraft#2497 closed: Improved error message for 'version' specific cases (type error and bad length) <Created by facundobatista> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2497> | 14:23 |
| pedronis | mborzecki: we do, or least did on linode, maybe we don't on gcloud, not sure | 14:44 |
| mup | PR snapd#6596 opened: spread: restore SELinux context when we mess with system files <SELinux> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6596> | 14:46 |
| mborzecki | super simple PR ^^ | 14:46 |
| ewp | really struggling to understand the snaps documentation. is the dump plugin able to copy files from outside the snapcraft directory? | 15:08 |
| mvo | pedronis: good news! my fixed fixed systemd for xenial boots now without segv | 15:12 |
| Chipaca | degville: https://mobile.twitter.com/damocrat/status/1105571463778709504 fwiw | 15:13 |
| pedronis | great | 15:13 |
| pedronis | mvo: ^ | 15:13 |
| Chipaca | mvo: where's the fun in a non-segv'ing pid 1? | 15:13 |
| degville | Chipaca: aha, thanks! | 15:13 |
| ondra | zyga not sure how urgent is this one as it's result of use of snap try | 15:13 |
| Chipaca | mvo: or split it after fun, and have a little poem | 15:14 |
| mvo | Chipaca: heh :) I'm fine with opting out of the fun, I had fun all morning | 15:14 |
| ondra | zyga but now I have snap installed, but not really there and I cannot remove it | 15:14 |
| mvo | Chipaca: lol | 15:14 |
| * mvo hugs john 'the poem' lenton | 15:14 | |
| ondra | zyga ERROR cannot discard snap namespace "opengrok", will retry in 3 mins: cannot discard preserved namespace of snap "opengrok": cannot unlink opengrok.mnt: Device or resource busy | 15:14 |
| mvo | the poet even | 15:14 |
| ondra | zyga I have got to this point few times before when using snap try and then deleting linked prime dir | 15:15 |
| ondra | zyga on one machine I eventually needed to edit state.json to get out of the trouble :) | 15:15 |
| zyga | ondra: I'm afk now, just reboot to fix it | 15:17 |
| zyga | ondra: but report things please | 15:17 |
| ondra | zyga yeah collecting logs | 15:18 |
| zyga | thanks | 15:18 |
| * zyga is now AFK | 15:18 | |
| mup | PR snapd#6597 opened: cmd/snap-update-ns: refactor of profile application (1/N) <Created by zyga> <https://github.com/snapcore/snapd/pull/6597> | 15:35 |
| Chipaca | hmmm | 15:43 |
| * cachio lunch | 15:45 | |
| mup | Issue # closed: core18#56, core18#86, core18#89, core18#117 | 16:05 |
| mup | PR # closed: core18#43, core18#63, core18#72, core18#90, core18#98, core18#120 | 16:05 |
| mup | Issue # opened: core18#56, core18#86, core18#89, core18#117 | 16:06 |
| mup | PR # opened: core18#43, core18#63, core18#72, core18#90, core18#98, core18#120 | 16:06 |
| mvo | xnox: fwiw, re systemd SRU, I created 1819278 and uploaded systemd for xenial,bionic into the unapproved queue, please let me know if it looks ok or if I was too trigger happy | 16:06 |
| mvo | pedronis: good news, fully spread test with new systemd was successful | 16:06 |
| mvo | so I think we have a winner | 16:07 |
| pstolowski | pedronis: any good name for interface for both Timings and Span? my current working name is Measurement | 16:07 |
| pedronis | pstolowski: I think Measurer though strange it's a more go patterned name | 16:08 |
| pstolowski | pedronis: right.. won't be the first.. we have Attrer already, and probably a few others | 16:09 |
| mup | PR snapd#6598 opened: overlord/snapstate, store: set a header when auto-refreshing <Created by chipaca> <https://github.com/snapcore/snapd/pull/6598> | 16:23 |
| pedronis | pstolowski: not a full review, but I skimmed the in progress PR and the direction looks good, probably we should stare at output/size again | 16:26 |
| pstolowski | pedronis: thanks; yes, i trimmed it quite a bit, will recheck the size | 16:27 |
| pstolowski | pedronis: i also plan to play with threshold in this PR | 16:29 |
| pedronis | pstolowski: added a couple of comments, one about one of you your questions | 16:30 |
| pstolowski | great | 16:30 |
| ewp | when snapcrafting, how would I go about targeting files into the user's home directory? | 16:48 |
| ewp | would like to move some files into ~ but not sure how to do this, could anyone point me in the right direction please | 16:49 |
| pedronis | Chipaca: some comments on the PR | 16:52 |
| pedronis | Chipaca: & thank you | 16:53 |
| mvo | pedronis: 6401 should address your points | 16:54 |
| mvo | I mean, it should be ready for a re-review | 16:54 |
| pedronis | mvo: thx, probably in the morning at this point | 16:55 |
| mvo | pedronis: thats fine, thanks | 16:57 |
| mup | PR # closed: core-build#11, core-build#22, core-build#26, core-build#37 | 17:01 |
| mup | PR # opened: core-build#11, core-build#22, core-build#26, core-build#37 | 17:02 |
| zyga | ewp: hey | 17:04 |
| ewp | hi | 17:04 |
| zyga | Snapcraft cannot package files into the users home directory | 17:05 |
| ewp | damn. useful to know- ok, thanks. | 17:05 |
| zyga | Can you tell me more about what you are trying to do? | 17:05 |
| zyga | You can write an install hook | 17:05 |
| ewp | think i'm a bit stuck then. mono (c#) uses (/home/user/.config/.mono/certs/) and (/usr/share/.mono/certs/) as the TLS root certificate store | 17:05 |
| zyga | But even then you should probably not copy stuff to any home location | 17:05 |
| zyga | Aha | 17:05 |
| ewp | but doesn't give us an option to change those paths, so i'm struggling to find a way to let stuff inside the package access the trusted root stores without breaking containment | 17:06 |
| zyga | So at runtime HOME is set to SNAP_USER_DATA | 17:06 |
| zyga | A simple workaround is to just copy the certificate store from the snap | 17:06 |
| zyga | Alternatively you may use layouts to make /use/share/.mono/certs contain a part of your snap | 17:07 |
| ewp | i've been trying this, but I think mono is trying to get at /usr/share/ which I'm assuming is not accessible in strict containment mode? | 17:07 |
| zyga | Look for “layouts” documentation on the forum | 17:07 |
| zyga | That should make it work | 17:07 |
| ewp | layouts! interesting, thank you that's a great pointer, i'll take a look | 17:08 |
| zyga | Good luck 🙂 | 17:08 |
| === pstolowski is now known as pstolowski|afk | ||
| ewp | thanks zyga ^_^ | 17:16 |
| ewp | zyga, i've setup layouts "/etc/ssl/certs:" to "bind: $SNAP/etc/ssl/certs" | 17:30 |
| ewp | i've installed the snap, and connected to the shell `snap run --shell my-snap` | 17:32 |
| ewp | ll /etc/ssl/certs gives me permission denied, but so does ll /snap/my-snap/x1/etc/ssl/certs | 17:32 |
| ewp | i'm not sure if this is expected behaviour, but it doesn't seem to give me (or mono) access to that certs directory | 17:33 |
| ewp | oops, had the path wrong. I can infact change directory into /snap/my-snap/x1/etc/ssl/certs, but 0 files contained, is the layout directive meant to populate that directory with the contents of /etc/ssl/certs ? | 17:37 |
| willcooke | Chipaca, ahoy! Want to do more debugging here? I'm happy to paste to the forum with anything relevant, but this might be quicker? | 17:48 |
| Chipaca | willcooke: as you wish :-) | 17:50 |
| Chipaca | willcooke: do you have anything mounted in /snap ? | 17:51 |
| Chipaca | willcooke: findmnt -t squashfs ? | 17:51 |
| willcooke | /var/lib/snapd/snaps/core_6405.snap on /snap/core/6405 type squashfs (ro,nodev,relatime,x-gdu.hide) | 17:52 |
| willcooke | $ findmnt -t squashfs | 17:52 |
| willcooke | TARGET SOURCE FSTYPE OPTIONS | 17:52 |
| willcooke | /snap/gnome-3-26-1604/82 /dev/loop0 squashfs ro,nodev,relatime | 17:52 |
| willcooke | /snap/core/6405 /dev/loop1 squashfs ro,nodev,relatime | 17:52 |
| Chipaca | willcooke: so, no gnome-calculator | 17:54 |
| willcooke | correct, no gnome-calc, or any of the other seeded snaps, except the platform snap and core | 17:54 |
| Chipaca | willcooke: what's in the seed? | 17:54 |
| Chipaca | mvo: are you around? | 17:55 |
| mup | PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502, | 17:55 |
| mup | snapd#6541, snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6592, snapd#6593, snapd#6594, snapd#6595, snapd#6596, snapd#6597, snapd#6598 | 17:55 |
| Chipaca | I'm suspecting the old "missing prerequisites in seed" | 17:56 |
| Chipaca | but, i dunno | 17:56 |
| willcooke | Desktop snaps: these also exist in ubuntu-release-upgrader's DistUpgradeQuirks.py for users who upgrade. | 17:56 |
| willcooke | * snap:gnome-3-26-1604 | 17:56 |
| willcooke | * snap:gtk-common-themes | 17:56 |
| willcooke | * snap:gnome-calculator | 17:56 |
| willcooke | * snap:gnome-characters | 17:56 |
| willcooke | * snap:gnome-logs | 17:56 |
| willcooke | * snap:gnome-system-monitor | 17:56 |
| willcooke | oh, hold on a sec | 17:56 |
| willcooke | that's the minimal file | 17:56 |
| mup | PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502, | 17:56 |
| mup | snapd#6541, snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6592, snapd#6593, snapd#6594, snapd#6595, snapd#6596, snapd#6597, snapd#6598 | 17:56 |
| willcooke | seb128, seeds for disco... | 17:57 |
| willcooke | http://people.canonical.com/~ubuntu-archive/seeds/ubuntu.disco/desktop-minimal | 17:57 |
| willcooke | http://people.canonical.com/~ubuntu-archive/seeds/ubuntu.disco/desktop | 17:57 |
| willcooke | The snaps only appear in the minimal file | 17:57 |
| willcooke | is that expected? | 17:57 |
| willcooke | I'd say it is, that the full layers on top of minimal | 17:58 |
| willcooke | but want to be sure | 17:58 |
| Chipaca | willcooke: so, the first thing I'd do, is check that those snaps are self-sufficient | 17:58 |
| Chipaca | willcooke: that is, if you start with an empty slate, and install those snaps in that order, that no other snaps get pulled in | 17:59 |
| Chipaca | but, I'd have to check with mvo about whether this is enough to break seeding | 18:00 |
| Chipaca | some work has gone into seeding since I last knew about it | 18:00 |
| willcooke | so install a vm for example, remove everything except core, and then install them one by one? | 18:00 |
| Chipaca | willcooke: apt purge snapd is probably quicker, but yes | 18:00 |
| willcooke | I dont think this is a seeding issue fwiw, since it seems that kenvandine can't recreate the issue on the same ISO. | 18:01 |
| Chipaca | OTOH snap remove alt-* shouldn't be too slow :-) | 18:01 |
| willcooke | lemme do taht | 18:01 |
| Chipaca | willcooke: if it's the old missing-prereq thing, snapd getting into a knot depends on when your network comes up | 18:01 |
| Chipaca | so it's racy and machine-dependent | 18:01 |
| kenvandine | oh... i'm doing a minimal install | 18:02 |
| kenvandine | maybe that's the diff | 18:02 |
| willcooke | ahhh | 18:02 |
| * kenvandine tries | 18:02 | |
| * Chipaca slowly steps back into the mist | 18:02 | |
| kenvandine | but willcooke's "snap tasks" output listed all the seeded snaps | 18:04 |
| Chipaca | kenvandine: yeah, it's definitely trying to seed | 18:05 |
| Chipaca | kenvandine: in the minimal install that worked, what's the output of 'snap list'? | 18:06 |
| kenvandine | i've already started a reinstall with normal | 18:06 |
| kenvandine | but i know what it listed | 18:06 |
| kenvandine | core, gnome-3-26-1604, gtk-common-themes, and the 4 seeded snaps | 18:07 |
| kenvandine | well... i'm pretty sure gtk-common-themes was listed | 18:07 |
| kenvandine | i know the others were | 18:07 |
| Chipaca | it's in the list to seed, so it should be | 18:07 |
| Chipaca | kenvandine: no core18? | 18:07 |
| kenvandine | no core18 | 18:07 |
| kenvandine | shoudn't be | 18:07 |
| kenvandine | yet | 18:07 |
| Chipaca | kenvandine: and no gnome-99-fancypants | 18:07 |
| kenvandine | gnome-3-26-1604 was there | 18:08 |
| Chipaca | gnome-3-28-1804? | 18:08 |
| kenvandine | nope | 18:08 |
| Chipaca | i guess that goes with core18 as well | 18:08 |
| kenvandine | yeah | 18:08 |
| Chipaca | hm | 18:08 |
| kenvandine | those shouldn't be there | 18:08 |
| Chipaca | then it's not the missing prereq thing | 18:08 |
| kenvandine | yeah | 18:11 |
| popey | Welcome valentind :) | 18:13 |
| valentind | Hey! | 18:13 |
| valentind | So I am pushing this "base" snap and because it is a base, it requires manual review. "snapcraft push" fails because of that. | 18:14 |
| valentind | I would like to know if it is possible to see if "snapcraft push" failed for another reason. | 18:14 |
| valentind | Because I want to push from a CI. | 18:15 |
| willcooke | kenvandine, Chipaca - full install in a vm - no snaps. Testing minimal now.... | 18:19 |
| Chipaca | valentind: you should have a list of reasons, if any beyond the fact that it's a base | 18:20 |
| pedronis | we changed seeding such that order should not be important anymore, but ideally all deps should be there | 18:22 |
| Chipaca | pedronis: right, but it looks like the prereqs are there | 18:23 |
| Chipaca | pedronis: dunno | 18:23 |
| pedronis | do we have snapd logs of when it fails? | 18:23 |
| Chipaca | pedronis: something's broken, and I'm being an egotist and hoping it's SEP | 18:23 |
| kenvandine | Chipaca: http://paste.ubuntu.com/p/2TvBgYqCj2 | 18:23 |
| valentind | Chipaca, Is there any way I can make the output easier to parse? Like a json or yaml outpput? | 18:23 |
| kenvandine | they are all there | 18:23 |
| kenvandine | on a normal install | 18:23 |
| willcooke | kenvandine, smells like a race | 18:24 |
| willcooke | kenvandine, did you do yours on a vm? | 18:24 |
| kenvandine | willcooke: but it works 100% of the time on my laptop :) | 18:24 |
| kenvandine | yes | 18:24 |
| kenvandine | all in a VM | 18:24 |
| pedronis | a race of what? | 18:24 |
| willcooke | dunno | 18:24 |
| pedronis | snapd seeding is sequential | 18:24 |
| willcooke | before snapd gets involved I expect | 18:24 |
| pedronis | (for predictability) | 18:24 |
| kenvandine | the output of snap tasks for willcooke's machine that failed looks like they all succeeded | 18:25 |
| ewp | could somebody quickly sense check my understanding of layouts please? https://docs.snapcraft.io/snap-layouts/7207 if I create a layout declaration with a target path of /usr/share/foo that maps to a relative path in my snap, then inside the snap running ls on that relative path should show the contents of /usr/share/foo ? | 18:25 |
| kenvandine | that smells of a snapd problem to me | 18:26 |
| seb128 | willcooke, yeah, I think the seed thing is expected, ubiquity/livecd-rootfs handle the snaps | 18:26 |
| willcooke | thx seb128 | 18:26 |
| pedronis | kenvandine: if all the tasks are Done and the changes Done, then things are a success | 18:28 |
| Chipaca | ewp: no, the other way around | 18:28 |
| pedronis | snapd is pretty boring about that | 18:28 |
| Chipaca | ewp: ls of /usr/share/foo would should stuff from inside your snap | 18:28 |
| kenvandine | pedronis: right... but "snap list" didn't list all the ones that said done | 18:28 |
| Chipaca | pedronis: things aren't mounted | 18:28 |
| pedronis | Chipaca: mounted | 18:28 |
| pedronis | I thought we added sanity checks about things not mounted | 18:29 |
| pedronis | did we lose them? | 18:29 |
| pedronis | do they get unmounted later | 18:29 |
| kenvandine | pedronis: however i can't reproduce this at all... but a couple others can reproduce it reliably | 18:29 |
| ewp | ohh, ok - i had that a bit backwards then, thanks. Is there a way to achieve what I described? | 18:29 |
| pedronis | anyway mounting brings in systemd | 18:29 |
| pedronis | our dear friend | 18:29 |
| pedronis | as well | 18:29 |
| pedronis | Chipaca: we had some crazy code that marked infos broken but continued nevertheless, but we fixed that I think | 18:30 |
| ewp | I'm trying to bring the contents of /usr/share/foo into the snap, not exactly sure what the best plugin to use for this is | 18:30 |
| ewp | so from inside the snap, an application can access "/usr/share/foo" and see the contents of that directory as it exists outside the snap | 18:31 |
| willcooke | Chipaca, this lack of messages in the journal is interesting... I have the same empty log on my broken system | 18:31 |
| willcooke | kenvandine, ^ | 18:31 |
| ewp | (reason: mono is looking for its certificate trust store in a hard-coded location) | 18:31 |
| kenvandine | willcooke: empty for me as well | 18:32 |
| kenvandine | but i have snaps listed | 18:32 |
| ewp | so i'm thinking the only way it can work is if code executing inside the snap can open('/usr/share/foo') | 18:32 |
| willcooke | ha. there goes that idea then | 18:33 |
| pedronis | Chipaca: this is the code: https://github.com/snapcore/snapd/blob/master/overlord/snapstate/handlers.go#L550 | 18:33 |
| Chipaca | willcooke: kenvandine: what's eating the logs? :-( | 18:34 |
| Chipaca | pedronis: https://forum.snapcraft.io/t/no-more-preinstalled-snap-on-ubuntu-19-04/10339?u=chipaca if you want the whole context | 18:36 |
| pedronis | Chipaca: I know, there is not a lot of useful logs there | 18:36 |
| pedronis | though | 18:36 |
| Chipaca | pedronis: see: missing logs :-( | 18:36 |
| Chipaca | :-) | 18:36 |
| pedronis | what eats the logs? and are they yummy? | 18:37 |
| pedronis | (are they a healthy diet?) | 18:37 |
| Chipaca | pedronis: https://i.imgur.com/ZjqZSse.jpg | 18:39 |
| pedronis | ah, maybe yummy, definitely not healthy | 18:40 |
| pedronis | Chipaca: anyway snaps are done but non mounted, empty logs, something is seriously off there, I doubt is just snapd | 18:42 |
| Chipaca | pedronis: same | 18:42 |
| Chipaca | pedronis: note not even the mount points exist | 18:42 |
| kenvandine | so i checked the media-info file on my last disco installed and it was installed from the 20190309 iso, which is what the forum post first referenced | 18:43 |
| willcooke | k, got some logs | 18:43 |
| willcooke | adding [Service] | 18:43 |
| willcooke | Environment=SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7 | 18:43 |
| willcooke | to the service file worked | 18:44 |
| willcooke | without that, nada | 18:44 |
| kenvandine | so logging isn't very verbose by default, i guess | 18:44 |
| pedronis | not verbose but in the end relatively chatty | 18:46 |
| * pedronis needs to stop | 19:00 | |
| kenvandine | well... i have reproduced it | 19:04 |
| kenvandine | willcooke, Chipaca: ^^ | 19:04 |
| willcooke | ah! | 19:04 |
| willcooke | I'm reintalling again | 19:04 |
| kenvandine | snap tasks 1 | 19:04 |
| willcooke | :) | 19:05 |
| kenvandine | shows all the tasks, looks all good | 19:05 |
| kenvandine | but only core and gnome-3-26-1604 listed in snap list | 19:05 |
| willcooke | kenvandine, what did you do to recreate? Just keep reinstalling? | 19:05 |
| willcooke | I see the same problem in the live session btw | 19:06 |
| kenvandine | well, i switched back to the iso from 20190311 | 19:08 |
| kenvandine | which i am sure i tried yesterday | 19:08 |
| kenvandine | my last few installs today was from the 20190309 iso | 19:08 |
| willcooke | k, Im going to try a different ISO | 19:08 |
| kenvandine | the forum post originally reported based on the 20190309 iso | 19:08 |
| * willcooke wonders if he wrote the wrong ISO to his USB stick | 19:09 | |
| kenvandine | shouldn't matter | 19:09 |
| kenvandine | it's definately busted in monday's iso | 19:09 |
| kenvandine | i'm downloading today's now | 19:09 |
| Chipaca | kenvandine: and what's in the logs? | 19:12 |
| kenvandine | Chipaca: the journal is empty | 19:12 |
| Chipaca | kenvandine: entirely? or just -u snapd? | 19:12 |
| popey | valentind: there is a snap called review-tools which you can find in the snap store. install that and then "snap-review (your snap)" | 19:15 |
| ewp | sorry i'm asking so many questions. is it possible to do something like this in the snapcraft file? ln -s /etc/ssl/certs $SNAP/etc/ssl/certs/ | 19:15 |
| popey | valentind: that will run the same snap review tool that the store runs | 19:15 |
| popey | valentind: saves you time by running it locally before pushing to the store | 19:16 |
| valentind | popey, Good to know. | 19:16 |
| kenvandine | Chipaca: just -u snapd | 19:18 |
| kenvandine | Chipaca: this must be related, but at the end of "snap tasks 1" it says waiting for restart | 19:19 |
| kenvandine | maybe it's failing to restart the daemon? | 19:19 |
| kenvandine | our friendly systemd :) | 19:19 |
| Chipaca | kenvandine: is there anything snapd-related in the journal without -u snapd? | 19:28 |
| pedronis | did you post tasks 1 somewhere? | 19:29 |
| willcooke | I purged snapd on a broken system. Reinstalled it, installed core, installed gnome-3-26-1604, installed gtk-common-themes, installed gnome-calculator | 19:44 |
| willcooke | restarted my session | 19:44 |
| willcooke | calculator works | 19:44 |
| willcooke | so afaict, installing the snaps as per the seeds file works as expected | 19:44 |
| Chipaca | willcooke: is there any way to set SNAPD_DEBUG in the cd such that it's already in debug at seed time? | 19:45 |
| Chipaca | ewp: what're you trying to do? | 19:45 |
| willcooke | Chipaca, I might be able to get in to the chroot and edit the service file before rebooting... lemme see | 19:45 |
| Chipaca | willcooke: it loads /etc/environment if that's easier | 19:46 |
| Chipaca | (you might see debug output from snap as well as from snapd, but eh) | 19:46 |
| willcooke | kk | 19:47 |
| kenvandine | Chipaca: journalctl |grep snap | 19:56 |
| kenvandine | returns nothing but udev events | 19:56 |
| kenvandine | nothing else | 19:56 |
| Chipaca | sñíg | 19:56 |
| willcooke | k, I edited /etc/environment, added those debug lines, nothing in the logs. Checked env and they are set | 20:02 |
| willcooke | grr | 20:03 |
| mwhudson | let's just skip 19.04, everyone can cope with waiting for 19.10 right? | 20:07 |
| mwhudson | willcooke: dmesg? maybe something is segfaulting | 20:08 |
| willcooke | looks ok | 20:09 |
| willcooke | I'll try editing the service file | 20:10 |
| Chipaca | i'm EODing | 20:16 |
| Chipaca | willcooke, kenvandine: forum or email with updates plz | 20:17 |
| Chipaca | or telegram if you're desperate | 20:17 |
| Chipaca | :-) | 20:17 |
| Chipaca | ttfn | 20:17 |
| willcooke | cheers Chipaca | 20:17 |
| kenvandine | cheers Chipaca | 20:17 |
| willcooke | I need to go soon too | 20:17 |
| willcooke | Still no logs. I need to admit defeat for today. Will try again tomorrow | 20:19 |
| willcooke | If anyone is interested in playing, it should be as easy as spinning up a new VM with todays disco ISO | 20:20 |
| willcooke | night all | 20:21 |
| mup | PR snapcraft#2501 closed: nodejs pluging: support for type str bin entries <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2501> | 20:25 |
| zyga | Back! | 20:54 |
| jdstrand | pedronis: hey, I've been trying for days to get PR 5644 to have a succesful test run, but haven't been able to. the weirdest is CLA check, which says: email: Invalid email 'zyga@xenial-server'. | 21:14 |
| jdstrand | --- | 21:14 |
| jdstrand | The command "./tests/lib/cla_check.py" exited with 1. | 21:14 |
| mup | PR #5644: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <⛔ Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5644> | 21:14 |
| jdstrand | pedronis: I made the changes, but you marked it as blocked, I guess cause the tests hadn't passed, but the failures seem unrelated... | 21:14 |
| * jdstrand will keep mashing buttons I guess | 21:15 | |
| jdstrand | pedronis: fwiw, the CLA failure seemed to happen after a recent merge with master | 21:16 |
| zyga | jdstrand: I know what that is | 21:40 |
| zyga | You need to rewrite history to fix my email | 21:41 |
| zyga | Sorry about that | 21:41 |
| jdstrand | zyga: huh? | 22:21 |
| sergiusens | jdstrand: the logic might be wonky, usually a rebase with master instead of a merge will fix it | 23:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
