| koala_man | I've installed a snap that just has 'home' permissions. Can I choose to give it unfettered access to my filesystem? | 03:37 |
|---|---|---|
| zyga | Hello | 05:23 |
| mborzecki | morning | 06:12 |
| mborzecki | mvo: hey | 06:25 |
| mvo | mborzecki: good morning | 06:27 |
| mborzecki | mvo: have you heard from zyga or pedronis? | 06:28 |
| mvo | mborzecki: not yet | 06:28 |
| jamesh | zyga: hi. If you're looking at refactoring the user mounts code, I've got a PR with some new spread tests for the behaviour I care about: https://github.com/snapcore/snapd/pull/6313 | 06:30 |
| mup | PR #6313: tests: add a tests for xdg-desktop-portal integration <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6313> | 06:30 |
| jamesh | this is testing integration with the real xdg-desktop-portal/xdg-document-portal services for a few features | 06:31 |
| jamesh | should give coverage for bind mounting a fuse file system owned by a non-root user too | 06:32 |
| === robertliu_ is now known as robertliu | ||
| mup | PR snapd#6371 opened: tests: exclude some more slow tests from runs in autopkgtest <Created by mvo5> <https://github.com/snapcore/snapd/pull/6371> | 06:46 |
| mvo | sil2100: hey, good morning! do you happen to know what the autopkgtest test timeout on the autpkgtest servers for tests is. the source in lib/adt_testbed.py defines it as 10000s but I some logs where this seems to be exceeded on amd64 but then I also see logs where we hit a this timeout on i386. do you happen to know more about this? | 07:43 |
| mvo | sil2100: aha, correction, arm64 takes longer | 07:43 |
| mup | PR snapd#6371 closed: tests: exclude some more slow tests from runs in autopkgtest <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6371> | 07:51 |
| mup | PR snapd#6372 opened: [RFC] tests: define new "tests/smoke" suite and use that for autopkgtests <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6372> | 08:00 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 08:01 |
| mvo | hey pstolowski - good morning | 08:06 |
| mborzecki | pstolowski: hey | 08:18 |
| mborzecki | https://www.reddit.com/r/linux/comments/af9gjf/snap_flatpak_appimage_from_a_software_deployment/ | 08:31 |
| * Chipaca currently hunting for a tricky, racy failure in snapshots | 09:32 | |
| Chipaca | I know how to fix it, and I know what the bug is … but I can't trigger it | 09:32 |
| Chipaca | a user did instead | 09:32 |
| mborzecki | Chipaca: genuine race condition bug :) | 09:33 |
| Chipaca | yeah | 09:33 |
| mup | PR snapd#6373 opened: overlord/ifacestate: helper API to obtain the state of connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6373> | 09:34 |
| mborzecki | pstolowski: something for you ^^ | 09:34 |
| pstolowski | k | 09:35 |
| mborzecki | pstolowski: think i owe you a review too | 09:35 |
| pstolowski | mborzecki: oh yes, that would be great | 09:35 |
| mup | PR core18#112 opened: hook-tests: add test for the 002,008, 012, 014 hooks <Created by mvo5> <https://github.com/snapcore/core18/pull/112> | 09:36 |
| Chipaca | got it! | 09:45 |
| * Chipaca takes a break | 09:46 | |
| mborzecki | pstolowski: left a comment under #6113 not entirely convinced if it's worth the extra test though, so it's up to you | 10:24 |
| mup | PR #6113: overlord/ifacestate: handler for hotplug-connect task <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6113> | 10:24 |
| pstolowski | mborzecki: thank you, checking | 10:25 |
| pstolowski | mborzecki: i'll add a test for this as a followup ok? | 10:26 |
| mborzecki | pstolowski: works for me | 10:27 |
| pstolowski | mvo: would you like to take a look at #6113 as well (it got reviews from Samuele and Maciej), or can I land it? | 10:29 |
| Chipaca | mvo: is 2.37 branched already? if so I could add something to it? | 10:29 |
| mup | PR #6113: overlord/ifacestate: handler for hotplug-connect task <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6113> | 10:29 |
| mup | PR snapd#6374 opened: snapshotstate: don't task.Log without the lock <Created by chipaca> <https://github.com/snapcore/snapd/pull/6374> | 10:29 |
| Chipaca | ^^^ a crasher | 10:29 |
| mvo | Chipaca: it is branched | 10:30 |
| mvo | Chipaca: adding is easy, just tag for 2.37 | 10:30 |
| Chipaca | mvo: tagged | 10:30 |
| Chipaca | mvo: do i need a separate pr for 2.37? | 10:30 |
| mvo | Chipaca: I can cherry pick if its just 1-2 commits | 10:43 |
| Chipaca | mvo: I'll keep it to 1 | 10:43 |
| mvo | Chipaca: \o/ | 10:43 |
| * Chipaca equips a *glowing* rod of +3 force-push | 10:44 | |
| popey | When do we plan to add the feature to only update snaps if they're not running? | 10:47 |
| mvo | popey: this cycle, zyga is working on this | 10:48 |
| mvo | popey: conceptually working on it already, I don't think we have real code yet | 10:48 |
| popey | Ok, So the workaround for now is to defer updates, if you don't want something refreshed while you're using it? | 10:49 |
| mvo | popey: yeah, its unfortunate | 10:55 |
| popey | ok, thanks | 10:57 |
| cmatsuoka | is there an interface to allow a snap package to add entries to cron.d, systemd timers or something like that? | 11:06 |
| zyga | popey: yes, definitely this cycle | 11:08 |
| zyga | popey: we are going to discuss details later today | 11:08 |
| zyga | cmatsuoka: no but snaps can use timer units | 11:08 |
| zyga | cmatsuoka: you can just define a timer for a given app to run on a schedule | 11:08 |
| popey | zyga: ok, thanks. I have passed on the necessary details for deferring snap refresh as a workaround | 11:08 |
| zyga | popey: passed where? | 11:08 |
| cmatsuoka | zyga: ok thanks, I'll check that | 11:09 |
| ogra | cmatsuoka, https://forum.snapcraft.io/t/timer-string-format/6562 should help | 11:10 |
| zyga | cmatsuoka: https://docs.snapcraft.io/the-snap-format/698?_ga=2.240122053.717610322.1547464203-2031546527.1547290160 defines the general format | 11:10 |
| zyga | the link that ogra gave (thanks! :) is the specific format for timers | 11:10 |
| cmatsuoka | got it, thanks | 11:20 |
| mup | PR snapd#6374 closed: snapshotstate: don't task.Log without the lock <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6374> | 11:20 |
| mvo | Chipaca: ^- also cherry-picked now | 11:20 |
| zyga | mborzecki: some comment about connection state APIs: https://github.com/snapcore/snapd/pull/6373/files#r247456024 | 11:21 |
| mup | PR #6373: overlord/ifacestate: helper API to obtain the state of connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6373> | 11:21 |
| mborzecki | zyga: thanks | 11:21 |
| mup | PR snapd#6366 closed: cmd/snap-discard-ns: fix name of user fstab files <Per-user mount ns 🐎> <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6366> | 11:22 |
| mup | PR core18#110 closed: [RFC] hooks: add support for `.test` files and add some initial tests <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/110> | 11:27 |
| zyga | mborzecki: updated https://github.com/snapcore/snapd/pull/6365 | 11:32 |
| mup | PR #6365: cmd/snap-update-ns: manually implement isspace <Per-user mount ns 🐎> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6365> | 11:32 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/6365 updated with islower/isdigit now | 11:36 |
| mup | PR #6365: cmd/snap-update-ns: manually implement isspace <Per-user mount ns 🐎> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6365> | 11:36 |
| zyga | mvo: replied on https://github.com/snapcore/snapd/pull/6364 | 11:45 |
| mup | PR #6364: cmd/snap-update-ns: let the go parser know we are parsing -u <Per-user mount ns 🐎> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6364> | 11:45 |
| mvo | zyga: ta | 11:48 |
| zyga | mvo: I think travis is broken on https://github.com/snapcore/snapd/pull/6362 | 12:03 |
| mup | PR #6362: cmd/snap-update-ns: explicitly check for return value from parse_arg_u <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6362> | 12:03 |
| zyga | as in, there's no travis run even registered | 12:03 |
| zyga | not sure what to do on that branch | 12:03 |
| mvo | zyga: ok, I check it after lunch | 12:07 |
| popey | zyga: a prominent developer of applications in our store. Their end users were upset that the app fails when it's refreshed. | 12:08 |
| zyga | popey: what's the workaround? I was specifically asking about what the idea is, not who it is for | 12:09 |
| popey | defer updates to later when you're not working | 12:09 |
| popey | sorry, I thought I made that clear above. | 12:09 |
| zyga | thanks, all is good :) | 12:10 |
| popey | :) | 12:10 |
| pstolowski | mvo: would you like to take a look at #6113 (it got +2 from Samuele and Maciej), or can I land it? | 12:13 |
| mup | PR #6113: overlord/ifacestate: handler for hotplug-connect task <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6113> | 12:13 |
| cachio | mvo, hey | 12:31 |
| cachio | mvo, I finished the tests execution | 12:32 |
| cachio | but I found some errors related to gpio | 12:32 |
| cachio | like thi https://paste.ubuntu.com/p/dWkbxBjrGM/ | 12:32 |
| cachio | mvo, these are the logs http://paste.ubuntu.com/p/8hQpc94jWW/ | 12:33 |
| cachio | the interface is not available | 12:33 |
| cachio | it is easy to reproduce | 12:33 |
| mborzecki | mvo: intersting question, https://forum.snapcraft.io/t/stracing-a-configure-hook/9452 | 12:45 |
| mborzecki | off to get the kids | 13:05 |
| === ricab is now known as ricab|lunch | ||
| mvo | pstolowski: looking at it in a wee bit, can be merged today, promised :) | 13:28 |
| mvo | cachio: oh, interessting | 13:28 |
| mvo | mborzecki: interessting forum post indeed, thats food for thought | 13:29 |
| === cpaelzer__ is now known as cpaelzer | ||
| mvo | cachio: the gpio issue sounds like a regression :/ | 13:30 |
| cachio | mvo, yes | 13:30 |
| cachio | I though perhaps some change was missing to be merged on the 2.37 branch | 13:31 |
| mvo | cachio: needs digging, the test itself changed back in Nov, maybe its just a test issue | 13:32 |
| pstolowski | mvo: ok :) | 13:34 |
| cachio | mvo, but it pass in the regular google run | 13:34 |
| cachio | mvo, I'll give another look and I'll debug it | 13:34 |
| mvo | cachio: I think I have an idea | 13:34 |
| mvo | cachio: I think it was not run on the external backend before because it had a check for TRUST_TEST_KEYS in the past | 13:35 |
| mvo | cachio: however when this got refactored this check was removed | 13:35 |
| mvo | cachio: there is no reason for this check, however it indirectly helped it seems | 13:36 |
| mvo | cachio: I should have a fix soon(ish) | 13:36 |
| cachio | mvo, ahhh, that could be | 13:36 |
| zyga | re | 14:03 |
| popey | zyga / mvo: (q from developer) "is there a ticket / forum thread / anything else where we can watch for snapd progress" (on not updating/refreshing while open) ? | 14:07 |
| zyga | popey: yes, there is | 14:07 |
| zyga | popey: let me find it | 14:07 |
| popey | (also) " Is there a way for an application to be "pinged" about a new version? Or should it just poll the directory?" | 14:08 |
| popey | (it's a classic snap) | 14:08 |
| zyga | popey: https://forum.snapcraft.io/t/bug-saves-are-blocked-to-snap-user-data-if-snap-updates-when-it-is-already-running/3226/33 | 14:10 |
| zyga | but I'm inclined to create a new thread with the things we just discussed | 14:10 |
| zyga | popey: eventually yes, not initially | 14:10 |
| zyga | popey: it cannot poll anything by itself | 14:11 |
| popey | if you do, please link to that thread | 14:11 |
| zyga | certainly | 14:11 |
| popey | is there no environment variable which indicates you're on an 'old' version or something? | 14:11 |
| popey | SNAP_REVISION might help? | 14:12 |
| zyga | popey: no | 14:12 |
| zyga | popey: I mean, you can look at $SNAP_REVISION | 14:12 |
| zyga | popey: but that doesn't change in existing processes | 14:12 |
| zyga | popey: the snap will not be refreshed until the app is running | 14:13 |
| popey | and it's not robust to be looking in $SNAP/../ ? | 14:13 |
| zyga | popey: I will write down the current discussion soon, let's postpone the details until you read that | 14:13 |
| popey | ok | 14:13 |
| Chipaca | degville: https://pastebin.ubuntu.com/p/WMHpQCFXHm/ <- wdyt? | 14:23 |
| Chipaca | mborzecki: ^ also | 14:24 |
| Chipaca | things to note: it prints the warning only on install, and before the "done" message, and only once per install action | 14:24 |
| mborzecki | s/Warning/WARNING/ ? | 14:25 |
| === ricab|lunch is now known as ricab | ||
| mborzecki | Chipaca: maybe we should point to the docs instead? | 14:26 |
| Chipaca | mborzecki: I didn't want to get shouty (it'll be bold though) | 14:26 |
| Chipaca | I'll add a space between the warning and the "done" message | 14:28 |
| mborzecki | Chipaca: this topic mentions adding /snap/bin to $PATH | 14:28 |
| mborzecki | https://docs.snapcraft.io/commands-and-aliases/3950 | 14:28 |
| Chipaca | seems to help: https://i.imgur.com/YnB3EXV.png | 14:28 |
| mborzecki | Chipaca: mhm, nicer | 14:29 |
| Chipaca | mborzecki: I was thinking more of a "in this distro, this desktop, this shell, do this to get it on the path: <...> | 14:30 |
| Chipaca | " | 14:30 |
| mborzecki | Chipaca: sounds like something that could be put in the forum/docs page, once it's in the snap binary it'll be harder to update | 14:32 |
| degville | mborzecki, Chipaca: I think we should set up a specific forum topic, that way the comments can help too, especially if this is a common problem. I think that's what Chipaca is thinking anyway. | 14:33 |
| degville | But I'm a little worried that we're ignoring the original problem, which is that the snapd installation somehow didn't add it to the path (by just writing instructions on how to add it to the path). | 14:34 |
| Chipaca | degville: I'm hoping having the warning pointing to the forum will also tell us about distros that aren't getting the integration done | 14:35 |
| Chipaca | so we fix it there | 14:35 |
| degville | Chipaca: good point, yep. | 14:35 |
| Chipaca | or, say, if $random_shell needs some file in /etc, we could ship it | 14:35 |
| Chipaca | etc etc | 14:35 |
| mborzecki | Chipaca: something like 'include you $SHELL and distro when reporting a problem'? | 14:41 |
| Chipaca | mborzecki: in the forum topic, sure | 14:41 |
| ogra | just ask for "snap version" and add "$SHELL" to the snap version output ? ;) | 14:46 |
| Chipaca | snap debug environ | 14:49 |
| mup | PR snapd#6375 opened: tests: fix enable-disable-unit-gpio test on external boards <Created by mvo5> <https://github.com/snapcore/snapd/pull/6375> | 15:04 |
| mup | PR snapd#6364 closed: cmd/snap-update-ns: let the go parser know we are parsing -u <Per-user mount ns 🐎> <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6364> | 15:11 |
| mup | PR core18#112 closed: hook-tests: add test for the 002,008, 012, 014 hooks <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/112> | 15:13 |
| mup | PR snapd#6365 closed: cmd/snap-update-ns: manually implement isspace <Per-user mount ns 🐎> <Simple 😃> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6365> | 15:19 |
| mup | PR snapd#6350 closed: cmd/snap-confine: don't preemptively create .mnt files <Per-user mount ns 🐎> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6350> | 15:23 |
| mup | PR snapd#6344 closed: cmd/snap-confine: join freezer only after setting up user mount <Per-user mount ns 🐎> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6344> | 15:25 |
| mup | PR snapd#6113 closed: overlord/ifacestate: handler for hotplug-connect task <Hotplug 🔌> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6113> | 15:48 |
| ahasenack | hi, I asked this user to post to the forum, but here is the original report in case someone is interested: https://askubuntu.com/questions/1108780/permission-denied-when-running-snap-applications-on-ubuntu-16-04-as-a-ldap-use | 15:49 |
| mvo | pstolowski: I merged your PR, thanks again for this work! one question/idea inline though, not sure if its useful, I remember we talked about something similar in the past and there extracting common bits was considered unhelpful | 15:49 |
| Chipaca | ahasenack: I think the short answer to the user's question is "no" | 16:12 |
| Chipaca | ahasenack: the long answer is "no, sorry" | 16:12 |
| ahasenack | the home interface is really about /home/<user>, and not the actual home in the case it's different? | 16:13 |
| ahasenack | i.e., it's /home/<user>, and not $HOME? | 16:13 |
| zyga | mvo: based on our discussion before I'd like to merge https://github.com/snapcore/snapd/pull/6294 | 16:17 |
| mup | PR #6294: packaging/ubuntu: build with golang 1.10 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/6294> | 16:17 |
| Chipaca | ahasenack: the interface itself uses apparmor's idea of what home is | 16:17 |
| Chipaca | ahasenack: why? | 16:17 |
| Chipaca | there are other parts of the thing that don't understand homes outside of /home/ though | 16:18 |
| Chipaca | and nss in a snap won't be happy | 16:18 |
| Chipaca | but, I think jamesh mentioned that if you install nscd (or unscd) things should work | 16:19 |
| Chipaca | but I haven't tested it | 16:19 |
| ogra | also, $HOME is typically pointed to $SNAP_USER_DATA before the snap app is run ... (or did that change) ... so $HOME might not be what you expect | 16:19 |
| zyga | ogra: that has not changed | 16:21 |
| zyga | ogra: unless it's a snap using classic confinement | 16:21 |
| pstolowski | mvo: awesome, thank you! yes, there is probably some potential for extracting common bits. i'll take a look at this kind of refactoring when everything hotplug-related lands; there is almost definately some room for refactoring in unit tests. i'm refraining from it atm as it would only complicate things for my split PRs. might be easier to look at it (and review) as a whole when it's in master | 16:21 |
| * cachio lunch | 16:23 | |
| mvo | pstolowski: sounds good | 16:24 |
| mup | PR core18#113 opened: hook-tests: add more hook tests <Created by mvo5> <https://github.com/snapcore/core18/pull/113> | 16:25 |
| Chipaca | Wimpress: can you follow what this person is saying? https://forum.snapcraft.io/t/wp-office-no-internet-menu-shortcut-link-solved/9459 | 17:39 |
| cachio | snap list | 17:56 |
| `dw | is there some magic incantation to run a snap program under perf? e.g. 'perf stat snap run' output shows counters are not being inherited by the target application, i assume due to the setuid helper | 18:01 |
| === pstolowski is now known as pstolowski|afk | ||
| zyga | `dw: not that I know of, perhaps we want to support snap run --perf ... | 18:15 |
| `dw | well, the point of the exercise to measure cpu and delays of snap itself, not sure how much of that work exists pre-helper | 18:19 |
| `dw | i can accomplish the same with isolcpus=, its just a pain :) | 18:20 |
| `dw | hmm, perf's cgroup filter can probably do it, unless snap is fiddling with cgroups too | 18:27 |
| zyga | `dw: snapd uses cgroups but most snaps cannot use cgroups themselves | 19:13 |
| Trevinho | How a snapped application can know its confinement type at runtime? | 19:22 |
| Trevinho | checking freezer value to have /snap.* confinement is enough? | 19:23 |
| `dw | zyga: joyfully there is a perf_event cgroup that can be used with 'perf stat -G' | 19:29 |
| `dw | so after a little digging, it seems the answer to the question of why libreoffice takes twice as long and burns 3x as much cpu starting up than a regular install is due to squashfs. further digging reveals in order to save on memory, all requests to squashfs are serialized in the kernel at least on ubuntu, meaning my 8 thread nvme-equipped computer is entirely wasted for any snap app | 20:42 |
| `dw | digging futher on why squashfs at all, i'm hitting a bit of a blank. the snap format page claims it speeds installation and makes it impossible to modify the snap contents, but the speedup is only true during the one-time installation process, after which an extreme penalty is paid for every access (the common case), and it contributes nothing to the user's ability to mutate the snap file (he can just rebuil | 20:44 |
| `dw | the squashfs) | 20:44 |
| `dw | is there some better snapd design document or similar, or perhaps a better question, has anyone seriously proposed extricating squashfs entirely? its use here seems extremely costly for little gain | 20:44 |
| `dw | i noticed various relationships/interactions with lxd, but google doesn't seem to explain those well either | 20:45 |
| === daker_ is now known as daker | ||
| === popey_ is now known as popey | ||
| === cmagina_ is now known as cmagina | ||
| === AndyWojo_ is now known as AndyWojo | ||
| === souther_ is now known as souther | ||
| popey | `dw: that's interesting data, would you be able to put a forum post together for wider spread of the info and discussion? (I suspect many have ended for the day) | 21:14 |
| `dw | popey: yeah sure, will try to tidy up and post | 21:15 |
| popey | thanks so much! | 21:15 |
| popey | I know some of the team are looking at performance issues, and I'm sure they'd appreciate the additional data | 21:15 |
| `dw | for now i'm just avoiding the libreoffice snap, the difference is very noticeable | 21:16 |
| leinardi | Hi, I'm trying to build a Snap for a Gtk/Python3 app but I am having hard time to find some snapcraft.yaml from similar apps. The app builds with meson and requires GTK 3.24 (Gnome 3.30) and several Python dependencies all available on PyPI. Does someone know a similar project with a working snapcraft.yaml? | 21:22 |
| leinardi | is there a better place where I can look for help? I already tried on the forum but also there I got no answers... | 21:44 |
| mup | PR snapd#6376 opened: tests: split the test interfaces-many in 2 and remove snaps on restore <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6376> | 23:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
