| mwhudson | hi | 00:14 |
|---|---|---|
| mwhudson | is anyone around? | 00:14 |
| mwhudson | seeding the snaps on the latest bionic live-server daily is taking an extraordinary amount of time | 00:15 |
| mwhudson | like 4 minutes | 00:15 |
| mwhudson | does anyone know anything about this? | 00:15 |
| niemeyer | mwhudson: I haven't heard anything about it, and certainly not expected | 02:32 |
| mwhudson | niemeyer: i forumed https://forum.snapcraft.io/t/extremely-slow-seeding/5891 | 02:33 |
| niemeyer | mwhudson: Thanks! | 02:34 |
| mup | PR snapd#5313 opened: tests: enable fedora 28 again <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5313> | 03:01 |
| mborzecki | morning | 04:58 |
| Lin-Buo-Ren | https://forum.snapcraft.io/t/wildcard-syntax-in-organize-keyword/5895 | 04:58 |
| mup | PR snapd#5221 closed: snap: parse connect instructions in gadget.yaml <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5221> | 05:12 |
| zyga | o/ | 05:15 |
| zyga | good morning! | 05:15 |
| mborzecki | zyga: is pstolowski still collecting logs from econnreset? | 05:30 |
| mborzecki | pstolowski: https://paste.ubuntu.com/p/8BgX5gJdXj/ | 05:31 |
| zyga | not sure | 05:32 |
| zyga | getsockopt: connection refused | 05:33 |
| zyga | econreset is driving me crazy | 05:40 |
| mup | PR snapd#5304 closed: overlord/ifacestate: simplify checkConnectConflicts and also connect signature <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5304> | 05:41 |
| mup | PR snapd#5313 closed: tests: enable fedora 28 again <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5313> | 05:43 |
| mup | PR snapd#5292 closed: interfaces/docker-support: update for docker 18.05 <Created by anonymouse64> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5292> | 05:49 |
| mup | PR snapd#5285 closed: tests/main/{snap-repair,ubuntu-core-services}: add debug information <Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5285> | 05:53 |
| zyga | https://github.com/snapcore/snapd/pull/5230 needs a 2nd review | 05:54 |
| mup | PR #5230: interfaces/udisks2: also implement implicit classic slot <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5230> | 05:54 |
| * zyga goes out with the dog | 05:59 | |
| zyga | re | 06:44 |
| mvo | abeato: hey, nice work on the watchdog PR! how urgent is this for you? is 2.34 (~5 weeks away) ok? or do you need it quicker? | 06:51 |
| mvo | 5276 needs a second review | 06:51 |
| mvo | please :) | 06:51 |
| mup | PR snapd#5301 closed: snapstate,ifacestate: remove core-phase-2 handling <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5301> | 06:52 |
| abeato | mvo, it is fine to have it for 2.34, thanks for asking (we already have a working workaround and do not need this urgently, it is fine to have it in an update) | 06:53 |
| mborzecki | mvo: 5276 needs deconflicting | 06:53 |
| mvo | abeato: great, thank you | 06:54 |
| abeato | yw | 06:55 |
| mvo | mborzecki: indeed, done | 06:56 |
| pedronis | mvo: hi, did you see this: https://forum.snapcraft.io/t/extremely-slow-seeding/5891 | 07:03 |
| mvo | pedronis: not yet, let me check | 07:08 |
| mvo | mwhudson: hey, about your forum post about seeding being slow. is this a regression, i.e. was the previous snapd quicker? | 07:13 |
| pstolowski | morning | 07:18 |
| pstolowski | mborzecki: thanks for the log, i think i have enough logs now | 07:20 |
| pstolowski | i'll look at econnreset again now | 07:25 |
| mborzecki | mvo: +1 on 5276, also restarted the build as it failed with interfaces-calendar-.. (one that's know to randomly fail) | 07:28 |
| mvo | mborzecki: thank you | 07:28 |
| mvo | mborzecki: and thank you :) | 07:28 |
| pstolowski | pedronis: hey, is there any benefit of doing task.SetStatus(state.DoneStatus) at the very end of task handler? I remember moving it towards the end in the reviews, but now that i look at it i doubt it serves any purpose | 07:31 |
| pedronis | pstolowski: it's mostly for consistency, are you wondering if you need it, we do need it | 07:34 |
| pedronis | pstolowski: the reason we need is that we want to add th tasks/change to state in the same atomic write to state as we set the task to done, otherwise we risk having it done again (and add the tasks again) | 07:37 |
| pedronis | or fail because to add them forever because self-conflicts of some kind | 07:37 |
| pstolowski | pedronis: ok, i see; there are some comments in a few other places that do that but they don't tell whole story, thanks | 07:38 |
| pedronis | pstolowski: it's usually related to having the task change the state in a significant non idempotent way | 07:39 |
| pedronis | at which point we want to mark it done in the same atomic write | 07:39 |
| mwhudson | mvo: yes it's a regression, haven't tried for a couple of weeks though | 07:39 |
| pstolowski | pedronis: understood, thanks | 07:41 |
| mvo | mwhudson: thank you, I tried to reproduce but no luck so far (booted it just two times though). any hints what I could be missing? I used the amd64 image in a standard kvm vm with -m 1500 | 07:42 |
| mwhudson | mvo: i'm trying your command line and it's hanging for me | 07:42 |
| mwhudson | maybe i should reboot my system | 07:42 |
| mwhudson | (as in, my laptop) | 07:42 |
| mvo | mwhudson: what commandline did you use? I can try that one on my box | 07:43 |
| mwhudson | mvo: kvm -m 1500 -snapshot ~/isos/bionic-live-server-amd64.iso | 07:43 |
| zyga | what's the URL to the iso | 07:43 |
| mwhudson | earlier i was using -m 1024 so i was wondering if it was swapping in the system | 07:44 |
| zyga | I can try here for one more sample | 07:44 |
| mvo | mwhudson: heh, that looks eerily similar ;) | 07:44 |
| zyga | my network has higher latency than landlines | 07:44 |
| mvo | mwhudson: aha, I can try with smaller ram values | 07:44 |
| mwhudson | mvo: usually i use -cdrom $ISO -hda target.img | 07:44 |
| mvo | mwhudson: I was thinking if .au makes a difference | 07:44 |
| mwhudson | if it's hitting the network, i have other complaints :) | 07:44 |
| mwhudson | the cd is usually plenty fast here | 07:45 |
| mwhudson | *cdn | 07:45 |
| mvo | mwhudson: or .nz - yeah, I shouldn't | 07:45 |
| * mwhudson downloads a snap at 11MB/s | 07:46 | |
| pedronis | pstolowski: it's usually: do things that could error, change the state, mark it done | 07:46 |
| pedronis | pstolowski: if a task is fully idempotent it can rely on taskrunner marking it done | 07:46 |
| mwhudson | argh this vm booted after 4 mins but i forgot to pass -redir | 07:46 |
| mwhudson | pedronis, mvo: http://paste.ubuntu.com/p/BQGMG4pZdM/ <- snap tasks 2 | 07:48 |
| * mwhudson reboots the host | 07:48 | |
| mborzecki | mwhudson: have you tried using virtio for net and drive btw? | 07:49 |
| zyga | Done 2018-06-13T07:42:47Z 2018-06-13T07:44:35Z Mount snap "core" (4650) | 07:51 |
| zyga | this is certainly unexpected | 07:51 |
| zyga | is this an SD card? | 07:51 |
| zyga | unless this includes some waiting on other tasks | 07:51 |
| pedronis | zyga: you need to look at the ready before, not the spawn | 07:52 |
| pedronis | the spawn is not when they start running | 07:52 |
| pedronis | is when they are created | 07:52 |
| zyga | I see | 07:52 |
| zyga | in that case it's still around a minute of waiting for mount | 07:52 |
| zyga | that is curious | 07:52 |
| pedronis | yes, also the time between the spawn and the first ensure ready is strangely long | 07:53 |
| pedronis | 2018-06-13T07:42:47Z 2018-06-13T07:43:49Z | 07:53 |
| zyga | each mount is slow | 07:53 |
| zyga | mborzecki: what is the host storage like? is this a HDD or a SSD? which filesystem are you using | 07:53 |
| zyga | er | 07:54 |
| zyga | mwhudson: ^ | 07:54 |
| zyga | (bad tab) | 07:54 |
| mborzecki | heh ;) | 07:54 |
| mwhudson | baaaaaah rebooting my laptop fixed it | 07:56 |
| zyga | pedronis: question about seeding | 07:56 |
| zyga | pedronis: on line 28 we have "mark system seeded" | 07:56 |
| zyga | but then we have more tasks below | 07:56 |
| zyga | is that expected | 07:56 |
| mwhudson | mborzecki: yes, too lazy to remember command line syntax for virtio | 07:58 |
| mborzecki | mwhudson: fwiw it makes a huuge difference here ;) | 07:59 |
| mup | PR snapd#5276 closed: devicestate: support seeding from a base snap instead of core <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5276> | 08:00 |
| mwhudson | mborzecki: ok, i'll try to teach it to my bash history :) | 08:03 |
| Chipaca | moin moin | 08:17 |
| Chipaca | I'm en route to the dentist; connection might be flaky | 08:17 |
| mborzecki | zyga: https://www.youtube.com/watch?v=ofeCpN99FU8 | 08:18 |
| zyga | mborzecki: oh, nice, thank you | 08:19 |
| zyga | mborzecki: apparmor logo looks a little bit like our flag :) | 08:19 |
| Chipaca | zyga: mvo: anything else to note on the conncheck->info pr? | 08:19 |
| mborzecki | zyga: what happened to the the dope penguin with gas mask on? | 08:20 |
| Chipaca | asking because I wouldn't like to trigger a whole spread run for a small change only to then have to do it again :-) | 08:20 |
| zyga | mborzecki: whaaat, I didn't know that was the previous logo | 08:20 |
| mborzecki | zyga: https://gitlab.com/apparmor/apparmor this logo | 08:21 |
| Chipaca | ooh, 'Add Vulkan abstraction' commit in apparmor | 08:27 |
| Chipaca | (4 weeks ago) | 08:27 |
| pedronis | zyga: not completely, it seems related to how auto-connect works | 08:32 |
| pedronis | pstolowski: did you see: http://paste.ubuntu.com/p/BQGMG4pZdM/ the connects at the very end before mark seeded seems a bit wrong | 08:32 |
| pedronis | zyga: pstolowski: ah | 08:33 |
| pedronis | zyga: is the display that is off, they are sorted by id , not really time or sequence | 08:33 |
| zyga | oh drat! | 08:34 |
| zyga | indeed, I didn't see this | 08:34 |
| zyga | should we change that | 08:34 |
| pedronis | I don't know, is definetely more confusing now that we have tasks that add more tasks | 08:34 |
| pedronis | they will all show up like that at end | 08:35 |
| Chipaca | ttfn | 08:38 |
| pstolowski | pedronis: oh, do we run things twice? does this auto-connection make sense at all? | 08:41 |
| pedronis | pstolowski: it's because is a self autoconnection | 08:47 |
| pedronis | pstolowski: we probably can fix that in auto-connect itself | 08:47 |
| pstolowski | pedronis: i didn;t know we have self-autoconnection, what is it for? | 08:47 |
| pedronis | pstolowski: tbh it's a bit of a corner case, but is quite important, docker uses it for example | 08:48 |
| pedronis | pstolowski: it's usally when the server and the client of something are in the same snap, that's the docker case I think | 08:48 |
| pstolowski | pedronis: ok, what test is this? | 08:49 |
| pedronis | pstolowski: test? | 08:49 |
| pedronis | this is a real image | 08:49 |
| pstolowski | pedronis: ah, allright | 08:50 |
| pedronis | pstolowski: anyway, to fix this we would need to keep track of connection already requested in newconns using the connref ID | 08:51 |
| pedronis | pstolowski: it's actually a bug btw, not just an opt, because of the hooks (in this case they don't exist, do nothing) | 08:53 |
| pedronis | pstolowski: btw do we check in ifacestate.Connect if the connection already exist? | 08:56 |
| pedronis | pstolowski: I know at some point doConnect would do nothing if the connection already existed, is that still true? or did we change it | 08:56 |
| pstolowski | pedronis: performance review in a moment, will talk to you afterwards, i need to actually check hits | 08:57 |
| pstolowski | *this | 08:57 |
| pedronis | np | 08:58 |
| pstolowski | allright, i'm back | 09:06 |
| * zyga finished his self review | 09:10 | |
| pstolowski | pedronis: we don't check if connection already exists | 09:11 |
| pedronis | pstolowski: I think repo does, but because of the hooks is too late there | 09:11 |
| pedronis | pstolowski: we should also add that | 09:12 |
| pstolowski | pedronis: yes | 09:12 |
| pedronis | pstolowski: so we need a check in ifacestate.Connect and a check in doAutoConnect in the 2nd loop to make we don't add the same connection again | 09:13 |
| mvo | zyga: I added a mount unit to 5284 | 09:22 |
| zyga | \o/ | 09:22 |
| zyga | thank you | 09:22 |
| pstolowski | pedronis: i'll address this later today | 09:26 |
| pedronis | thx | 09:26 |
| jamesh | zyga: for https://github.com/snapcore/snapd/pull/5271, I think the only open question was yours about what to do about too-old versions of xdg-desktop-portal. | 09:30 |
| mup | PR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271> | 09:30 |
| * zyga looks | 09:30 | |
| jamesh | zyga: I don't have a good answer for that, but the PR doesn't introduce any new problems | 09:30 |
| jamesh | (there's no --version option for any of the daemons, so it'd probably need per-packaging system checks) | 09:31 |
| zyga | jamesh: ack | 09:37 |
| jamesh | zyga: for snapd delivered via distro packages, we can use a "Conflicts:" header, but that doesn't help when snapd is delivered by the core snap | 09:38 |
| zyga | jamesh: I think this is still a problem | 09:46 |
| zyga | AFAIK older portal implementation would not confine non-flatpack apps | 09:46 |
| zyga | so an older version of the portal is essentially a sandbox escape | 09:46 |
| zyga | (well, for files) | 09:46 |
| mvo | 5284 needs a second review (should be simple :) | 09:48 |
| jamesh | zyga: so, I think the old xdg-desktop-portal file chooser won't register files with the document portal when it thinks it is talking to unconfined apps (good), but our attempt to bind mount the document portal will fail because the application ID is in a different format (bad) | 09:52 |
| jamesh | the bind mount failing is bad because it will reveal the entire document portal tree, potentially giving access to any files registered to flatpak apps | 09:53 |
| zyga | mmmm | 09:57 |
| zyga | and if we fail and don't start the app this has other negative side effects | 09:57 |
| jamesh | we explicitly set the document portal mounts to ignore failures so it'd work when the portal code isn't present | 09:59 |
| zyga | I need to jump to a call | 09:59 |
| jamesh | okay | 09:59 |
| zyga | jamesh: if we ignore the failure, does that ever leave the portal wide open for the app to see? | 09:59 |
| zyga | could we fix that by perhaps bind mounting /var/lib/snapd/void there? | 10:00 |
| jamesh | zyga: the apparmor policy lets the app access that mount point, so it is open | 10:00 |
| jamesh | long term, I think it would be better to have a completely private $XDG_RUNTIME_DIR mounted at the usual /run/user/$uid | 10:01 |
| jamesh | so if we failed to mount something in, then it just wouldn't be present | 10:01 |
| Son_Goku | interesting | 10:06 |
| Son_Goku | what brought this conversation on? | 10:06 |
| Son_Goku | I was just having this convo with the Fedora Workstation guys | 10:06 |
| jamesh | Son_Goku: I've been (slowly) working to integrate xdg-desktop-portal with snapd | 10:06 |
| Son_Goku | yes, I saw the first bits land with snapd 2.33 | 10:07 |
| jamesh | Son_Goku: it works with xdg-desktop-portal 0.2 (patches have been accepted upstream), but fails open with 0.1. | 10:07 |
| Son_Goku | wait what | 10:07 |
| jamesh | if it failed closed, that would be okay | 10:07 |
| Son_Goku | I need an unreleased version of xdg-desktop-portal now? | 10:07 |
| Son_Goku | this is going to be a problem | 10:07 |
| jamesh | 0.2 is released | 10:07 |
| Son_Goku | this is the latest version: https://github.com/flatpak/xdg-desktop-portal/releases/tag/0.11 | 10:08 |
| jamesh | gah. getting versions mixed up | 10:08 |
| jamesh | 0.11 is the fixed version | 10:08 |
| Son_Goku | ah | 10:08 |
| jamesh | (not sure where 0.2 came from) | 10:08 |
| Son_Goku | at the moment, I can't ship snapd 2.33 to Fedora 27, which I'm trying to fix right now | 10:09 |
| jamesh | Son_Goku: I suspect it isn't as big a deal for Fedora, where we don't have AppArmor confinement in place | 10:09 |
| Son_Goku | well, snapd's confinement is mostly useless anyway, so it's not a big deal in that respect | 10:10 |
| Son_Goku | but it's still ugly since the document portal moved from flatpak into its own thing | 10:10 |
| Son_Goku | and that is required for xdg-desktop-portal 0.11 | 10:10 |
| jamesh | yeah. Alex moved it so the two services could share the same auth logic | 10:10 |
| Son_Goku | yep | 10:15 |
| Son_Goku | which means that flatpak in Fedora 27 has to be upgraded to... | 10:15 |
| Son_Goku | which they don't typically do if they don't need to | 10:15 |
| zyga | re | 10:24 |
| mup | PR snapd#5314 opened: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314> | 10:32 |
| === Son_Goku is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Son_Goku | ||
| mborzecki | pedronis: just-renames PR ^^ | 10:40 |
| zyga | mborzecki: I'll co-review | 11:02 |
| zyga | mborzecki: I haven't done it all yet but could we perhaps remove Name for a transition period so that no new code lands that uses Name vs InstanceName? | 11:04 |
| pedronis | mborzecki: will look | 11:06 |
| mborzecki | zyga: which Name? info.Name() is no more, it's been replaced by InstanceName() | 11:11 |
| zyga | ah perfect | 11:11 |
| zyga | that's exactly what I wantee | 11:12 |
| zyga | *wanted | 11:12 |
| zyga | to avoid API skew from PRs | 11:12 |
| zyga | I'm at 1/3 of the diff | 11:12 |
| mborzecki | zyga: happy scrolling :) and thanks for going though it | 11:12 |
| zyga | pleasure :) | 11:12 |
| zyga | Chipaca: ping | 11:19 |
| Chipaca | zyga: bonk | 11:19 |
| zyga | Chipaca: can you please look at the conversation on https://bugs.launchpad.net/snapd/+bug/1776295 | 11:19 |
| mup | Bug #1776295: `stop` and `disable` should kill all processes regardless of daemon stop-mode <snapd:Incomplete> <https://launchpad.net/bugs/1776295> | 11:19 |
| zyga | I think what is being asked for is not supported by systemd but I want a 2nd opinion | 11:19 |
| Chipaca | zyga: we can easily make explicit stop be harder than the systemd one, can't we? | 11:21 |
| zyga | define explicit stop? | 11:21 |
| zyga | is that something other than systemctl stop foo.service? | 11:21 |
| Chipaca | zyga: snap stop blah | 11:21 |
| zyga | mm | 11:21 |
| Chipaca | zyga: or snap remove blah | 11:21 |
| zyga | yes, that we can | 11:21 |
| zyga | we can definitely do that | 11:22 |
| Chipaca | behind the scenes we currently do systemctl stop | 11:22 |
| Chipaca | we could easily do killall --user $USER instead | 11:22 |
| Chipaca | that'll learn them to complain | 11:22 |
| zyga | pastebin ~/.ssh/id_rsa | 11:22 |
| zyga | yeah, it's good that we don't ) | 11:22 |
| zyga | anyway, this needs some thinking and discussion | 11:22 |
| Chipaca | zyga: forum time? | 11:23 |
| zyga | sounds good to me | 11:23 |
| Chipaca | basically it'd mean "stop-mode" is for "internal" stoppage, and perhaps also for "restart", but explicit "snap stop" or "snap remove" would slay the whole namespace or w/e | 11:23 |
| Chipaca | zyga: shall you, or should I? | 11:24 |
| zyga | Chipaca: I can | 11:24 |
| zyga | thank you :) | 11:24 |
| Chipaca | zyga: perfect :) | 11:24 |
| mborzecki | didn't we do systemctl kill --kill-who=all on snap stop? | 11:24 |
| Chipaca | mborzecki: #1776295 | 11:25 |
| mup | Bug #1776295: `stop` and `disable` should kill all processes regardless of daemon stop-mode <snapd:Incomplete> <https://launchpad.net/bugs/1776295> | 11:25 |
| Chipaca | mvo: was your "looks good" on #5312 a +1? | 11:26 |
| mup | PR #5312: store: switch connectivity check to use v2/info <Created by chipaca> <https://github.com/snapcore/snapd/pull/5312> | 11:26 |
| mborzecki | Chipaca: yes, that's i'm referring to, iirc this was discussed a bit while that change was introduced, basically systemctl stop stops all processes in cgroup, now since that no longer works because of stop mode, snap stop <service> was supposed to do the right thing | 11:29 |
| Chipaca | mborzecki: that bug says it doesn't (but I haven't confirmed this) | 11:30 |
| Chipaca | mborzecki: I also don't know if disable or remove dtrt | 11:30 |
| mborzecki | hmm | 11:30 |
| zyga | maybe I'm wrong | 11:30 |
| Chipaca | zyga: never! | 11:30 |
| zyga | but what I see is that there's a desire for different action on "systemctl stop" vs on "snap refresh" | 11:31 |
| Chipaca | zyga: yep | 11:31 |
| zyga | Chipaca: I need to tell my wife ;) | 11:31 |
| mborzecki | Chipaca: hmmm | 11:31 |
| Chipaca | zyga: you're never *locally* wrong | 11:31 |
| mborzecki | Chipaca: so when you do snap stop <...> it ends up in servicestate.Control() which calls systemctl stop ... ? | 11:31 |
| Chipaca | mhmm | 11:32 |
| zyga | mborzecki: done | 11:39 |
| mborzecki | zyga: as for apparmor & SNAP_NAME, jdstrand suggested introducing another variable in the templates and pick one depending on whether it's outside/inside mount ns | 11:41 |
| mborzecki | anyways, to be ironed out | 11:42 |
| zyga | mborzecki ack | 11:42 |
| zyga | mborzecki: can you do a simple review for me | 11:42 |
| zyga | 5315 | 11:42 |
| mup | PR snapd#5315 opened: cmd/snap-update-ns: introduce MimicRequiredError, make ReadOnlyFsErro… <Created by zyga> <https://github.com/snapcore/snapd/pull/5315> | 11:42 |
| zyga | I'm trying to shrink my main patch | 11:42 |
| * cachio afk | 11:46 | |
| niemeyer | Morning all | 11:55 |
| zyga | hey hey :) | 11:56 |
| niemeyer | mborzecki: #5030 needs love | 11:56 |
| mup | PR #5030: packaging/amzn2: initial packaging of 2.32.5 for Amazon Linux 2 <Reviewed> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5030> | 11:56 |
| mborzecki | niemeyer: i think it's ok to close it for now, it'll still be accessible and we can revive it (or build on what Son_Goku proposed) when needed | 11:57 |
| niemeyer | mborzecki: But is it not needed? | 11:57 |
| Son_Goku | for now, no | 11:57 |
| niemeyer | mborzecki: I mean, we do want it building fine there as well | 11:57 |
| Son_Goku | niemeyer, most likely, this will be obsoleted by eventual introduction of snapd into EPEL | 11:57 |
| niemeyer | Son_Goku: Heya | 11:57 |
| Son_Goku | niemeyer: Hi! | 11:58 |
| mvo | Chipaca: woah, that merge was quick, did you click merge right after I clicked "approve"? | 11:58 |
| mup | PR snapd#5312 closed: store: switch connectivity check to use v2/info <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5312> | 11:58 |
| niemeyer | Son_Goku: Sorry for not responding quickly enough yesterday.. it's my understanding that all of our g-s are submitted upstream as well.. | 11:58 |
| Chipaca | mvo: got a notification of your approve | 11:58 |
| Chipaca | mvo: mashed the merge button | 11:58 |
| Chipaca | mvo: yes | 11:58 |
| mvo | Chipaca: heh | 11:58 |
| niemeyer | Son_Goku: The maintainer was also in a sprint in London with us just a week ago or so | 11:58 |
| mvo | Chipaca: impressive | 11:58 |
| Chipaca | mvo: thank you for the +1 | 11:59 |
| niemeyer | Son_Goku: Unfortunately it's a bit tricky to get things flowing when there's so much interest yet a disjoint set of needs | 11:59 |
| Son_Goku | niemeyer, I'm mainly worried about the g-s plugin rotting to the point I'll be forced to disable it | 11:59 |
| Son_Goku | the experience is... not great | 11:59 |
| mvo | Chipaca: you did all the hard work! | 12:00 |
| Son_Goku | niemeyer, the main gaps are snap channels and basic perm management | 12:02 |
| Son_Goku | the snap channels one is a biggie, because it leads to a confusing experience in g-s | 12:02 |
| niemeyer | Son_Goku: Yeah | 12:03 |
| Son_Goku | the perm management is less important, because snapd confinement doesn't work in Fedora anyway | 12:03 |
| niemeyer | Son_Goku: One idea we've been considering is shipping a snap-only version of it as a snap | 12:03 |
| mup | PR snapd#5081 closed: interfaces/apparmor: add chopTree <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5081> | 12:03 |
| Son_Goku | niemeyer, yes, I saw the snap-master branch of g-s | 12:03 |
| Son_Goku | I'm not sure that's a good idea | 12:03 |
| Son_Goku | I think it might be better to create an independent DE-agnostic tool | 12:04 |
| Son_Goku | which would be useful for DEs that don't have a software center | 12:04 |
| zyga | there's an elementary app called Snapper or something similar but I think the experience there is not good at all :/ | 12:04 |
| Son_Goku | Snaptastic | 12:04 |
| niemeyer | Son_Goku: Best would be to have a single tool working everywhere with everything | 12:04 |
| Son_Goku | but yeah, it's kind of weird | 12:04 |
| zyga | snaptastic, thanks | 12:04 |
| Son_Goku | but it could be an interesting foundation for the concept | 12:05 |
| niemeyer | Son_Goku: But that's taking some time to sort out, and we want to make *something* available that sorts out the GUI side of things while we get the ideal in place | 12:05 |
| Son_Goku | zyga, one idea would be to use the libyui foundation libraries to build a UI agnostic frontend | 12:05 |
| Son_Goku | like what I did for DNF with dnfdragora: https://github.com/manatools/dnfdragora | 12:06 |
| Son_Goku | that would even give a reasonable experience for people who'd like an aptitude-like interface for snap management | 12:06 |
| Son_Goku | zyga: screenshots of dnfdragora are in https://blog.mageia.org/en/2017/07/21/dandifying-mageia-part-2/ | 12:07 |
| zyga | personally I don't think aptitude like approach is needed for snaps | 12:08 |
| zyga | simply because you don't have the zoo of weird packages like -common or -bin or whatever | 12:08 |
| Son_Goku | but you need a way for people to find and manage them | 12:08 |
| zyga | gnome software has pretty close idea to a proper app store | 12:09 |
| Son_Goku | well, then, get the snap channel support in g-s ;) | 12:09 |
| popey | We did some design work on g-s last week. | 12:11 |
| zyga | popey: cool, any mockups? :) | 12:15 |
| popey | loads of sketches, its over to design now to do that | 12:15 |
| mup | PR snapd#5284 closed: data/systemd/snapd.run-from-snap: ensure snapd tooling is available <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5284> | 12:17 |
| zyga | mvo: do we need to do anything about https://github.com/snapcore/snapd/pull/5284#pullrequestreview-128293170 | 12:18 |
| mup | PR #5284: data/systemd/snapd.run-from-snap: ensure snapd tooling is available <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5284> | 12:18 |
| mvo | zyga: you mean libexecdir? | 12:26 |
| zyga | yes | 12:27 |
| mvo | zyga: I replied iirc, is the reply unclear (or did I forgot to submit it :/ | 12:27 |
| zyga | I didn't see a reply | 12:27 |
| mvo | zyga: """Thanks for checking. This code only runs on ubuntu-core systems, so we can hardcode the (known) libexecdir here.""" <- maybe github ate it :( | 12:28 |
| zyga | +1 | 12:28 |
| zyga | I see it now | 12:28 |
| zyga | thanks | 12:28 |
| mvo | zyga: \o/ | 12:28 |
| mvo | zyga: thanks for your careful review | 12:28 |
| Son_Goku | :( | 12:28 |
| mup | PR snapd#5316 opened: store, et al: kill dead code that uses the bulk endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/5316> | 12:28 |
| Chipaca | ^^^^ if anybody enjoys reviewing a +99 -1333 PR, now's your chance! | 12:28 |
| * Chipaca -> lunch | 12:29 | |
| mborzecki | client.actionData.Name appears to be unused, anyone recalls what was the purpose of this field? | 12:52 |
| Son_Goku | Chipaca, less Go code in the world makes me happier :) | 12:56 |
| Chipaca | mborzecki: it was the name of the snap | 12:57 |
| mborzecki | Chipaca: 'was' ? | 12:57 |
| Chipaca | mborzecki: git show d01831fda7995cc0f2f207000adab192fb2fbf6d | 12:58 |
| mvo | Chipaca, zyga we are still in a meeting, might overrun a litle bit | 13:00 |
| zyga | ack | 13:00 |
| Chipaca | mborzecki: was removed in 15edad32e3d572a2ddd53df3f5b7a9eab4b23333 | 13:01 |
| Chipaca | mborzecki: it's ignored server-side, is probably why | 13:01 |
| Chipaca | mborzecki: KILL IT WITH FIRE | 13:01 |
| zyga | mvo: should we wait? | 13:02 |
| mborzecki | Chipaca: oh i won't do that ;) i plan to use it instead | 13:02 |
| zyga | mvo: or shall we get started? | 13:02 |
| mvo | zyga: go ahead I would say | 13:02 |
| niemeyer | zyga: Meeting running late here.. we'll be there in a moment | 13:02 |
| zyga | niemeyer: ack | 13:02 |
| mborzecki | Chipaca: actually added Instance to SnapOptions, just to find that Name field a bit later | 13:02 |
| Chipaca | mborzecki: ¯\_(ツ)_/¯ | 13:03 |
| Chipaca | mborzecki: removing it seems the saner thing to do i think | 13:03 |
| Chipaca | mborzecki: sorry i didn't see your comment about using it instead | 13:21 |
| Chipaca | mborzecki: that works also :-) | 13:21 |
| Chipaca | mborzecki: but | 13:22 |
| Chipaca | mborzecki: what would you use it for? | 13:22 |
| mborzecki | Chipaca: snap install foo.snap --instance foo_bar | 13:22 |
| Chipaca | mborzecki: the reason it's not used is because in doSnapAction, the name is already in the path | 13:22 |
| Chipaca | mborzecki: that is, it's a POST to /v2/snaps/<name> | 13:23 |
| Chipaca | mborzecki: so saying name in the body of the post is redundant | 13:23 |
| Chipaca | redolent | 13:23 |
| Chipaca | refulgent | 13:23 |
| mborzecki | Chipaca: right, but if you try to install it as an instance than i can either use another form field or reuse this | 13:24 |
| mborzecki | Chipaca: and it's also POST /v2/snaps, so the current name comes from the snap itself | 13:24 |
| Chipaca | mborzecki: /v2/snaps is doMultiSnapAction | 13:25 |
| mborzecki | Chipaca: i'm doing the variant which sideloads a snap file, hits the same endpoints but uploads a snap too | 13:29 |
| Chipaca | mborzecki: ah! a'ight | 13:31 |
| * zyga needs to feed the dog, brb | 13:40 | |
| zyga | re | 13:51 |
| === pstolowski is now known as pstolowski|lunch | ||
| mborzecki | Chipaca: seems to work now https://paste.ubuntu.com/p/3WJZthdSyY/ :P | 14:21 |
| zyga | jdstrand: hey | 14:40 |
| zyga | jdstrand: do you have a sec? | 14:40 |
| Chipaca | pedronis: in #5317 I have increased coverage of details.go while keeping to the spirit of the PR :-D | 14:47 |
| pedronis | Chipaca: ah | 14:57 |
| === pstolowski|lunch is now known as pstolowski | ||
| Chipaca | pedronis: perhaps not what you were hoping for :) | 14:57 |
| pedronis | let's see what we get when the test have run | 14:58 |
| Chipaca | pedronis: locally, coverage of store went from 88.3% (96.8% in details.go) to 87.9% (96.6% in details.go) | 15:01 |
| Chipaca | the same two lines are not uncovered | 15:01 |
| Chipaca | er, not covered* | 15:01 |
| mup | PR snapd#5317 opened: overlord: introduce a gadget-connect task and use it at first boot <Created by pedronis> <https://github.com/snapcore/snapd/pull/5317> | 15:03 |
| * zyga iret's from real-life interrupt | 15:11 | |
| pedronis | pstolowski: I will look at your disconnect hooks PR again in the morning | 15:16 |
| === jkridner is now known as jkridner|afk | ||
| * cachio lunch | 15:40 | |
| pstolowski | pedronis: ty | 15:42 |
| mup | PR snapd#5318 opened: interfaces/builtin: add new cuda-support interface <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5318> | 15:45 |
| diddledan | preview of what I'm working on https://usercontent.irccloud-cdn.com/file/h6uU1nG3/image.png | 15:58 |
| zyga | @diddledan I'd love if gog would itself distribute snaps | 15:59 |
| diddledan | yeah, they don't want to though | 15:59 |
| zyga | did we ask? | 15:59 |
| diddledan | last I saw they're "monitoring packaging systems" | 16:00 |
| zyga | diddledan: I know some people there (or I used to, I need to check) | 16:00 |
| zyga | pstolowski, mborzecki: can you guys give me a quick +1 on 5319 | 16:00 |
| zyga | it's a mv from package to package | 16:00 |
| mup | PR snapd#5319 opened: cmd/snap-update-ns,strutil: move PathIterator to strutil, add Depth helper <Created by zyga> <https://github.com/snapcore/snapd/pull/5319> | 16:00 |
| zyga | and a trivial one liner method | 16:00 |
| zyga | I can split those if you'd feel better | 16:00 |
| pstolowski | zyga: done | 16:03 |
| zyga | mvo: hey, do you want to have the call about core? | 16:03 |
| zyga | pstolowski: thank you! | 16:03 |
| pstolowski | zyga: maybe you will know: | 16:03 |
| zyga | yes? | 16:04 |
| pstolowski | zyga: when we run spread tests, do we ever reuse the test user home dir between runs of entire suite? | 16:04 |
| zyga | I think we never clean it | 16:04 |
| zyga | yes, we reuse it | 16:04 |
| zyga | I only recall seeing code that makes it | 16:05 |
| zyga | but then that's that | 16:05 |
| zyga | diddledan: gog has many similarities with steam | 16:05 |
| zyga | diddledan: so you may look at the (now closed) steam-support interface | 16:05 |
| zyga | as well as the surrounding discussions | 16:06 |
| pstolowski | zyga: just to be sure: i'm not talking about not cleaning it between individual tests; i mean possibility of having leftovers between executions of entire suite | 16:06 |
| zyga | pstolowski: I think it is the same | 16:06 |
| zyga | pstolowski: it is only clean before first test :) | 16:06 |
| zyga | after that, until the machine is recycled, we don't touch that | 16:06 |
| zyga | thank you! | 16:26 |
| * zyga just waits for green then proposes the next PR | 16:26 | |
| zyga | well, reopens the next PR | 16:26 |
| mvo | zyga: lets do it tomorrow morning (unless you have sometihng urgent) | 16:27 |
| zyga | mvo: no, nothing urgent | 16:27 |
| mvo | zyga: cool, lets do it around 9ish tomorrow? | 16:27 |
| zyga | sounds good | 16:27 |
| mvo | cool | 16:28 |
| om26er | popey: ping | 16:35 |
| zyga | eh, blasted fedora 28 failure | 16:35 |
| om26er | popey: regarding axel snap, do you think we can enable its auto builds now ? | 16:36 |
| popey | om26er: heya. it alreay is hooked up. I did it when I closed the bug report. | 16:39 |
| popey | om26er: but it fails to build https://build.snapcraft.io/user/snapcrafters/axel | 16:39 |
| popey | Can't exec "aclocal": No such file or directory at /usr/share/autoconf/Autom4te/FileUtils.pm line 326. | 16:39 |
| popey | https://launchpadlibrarian.net/373136884/buildlog_snap_ubuntu_xenial_amd64_1c7edf66b8a27bd4ca35886b0511f15e-xenial_BUILDING.txt.gz | 16:39 |
| om26er | woa, it fails on all arches | 16:40 |
| zyga | mborzecki: shall I change https://github.com/snapcore/snapd/pull/5315 | 16:41 |
| mup | PR #5315: cmd/snap-update-ns: introduce MimicRequiredError, make ReadOnlyFsErro… <Created by zyga> <https://github.com/snapcore/snapd/pull/5315> | 16:41 |
| zyga | mborzecki: I think only you can test this https://github.com/snapcore/snapd/pull/5318 | 16:43 |
| mup | PR #5318: interfaces/builtin: add new cuda-support interface <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5318> | 16:43 |
| cachio | mborzecki, hey | 17:03 |
| cachio | mborzecki, I created a new image for arch and when I run the tests I get https://paste.ubuntu.com/p/gWm7dzkKFN/ | 17:03 |
| cachio | mborzecki, it is checking for updates | 17:04 |
| cachio | but there are not new updates | 17:04 |
| mup | PR snapd#5319 closed: cmd/snap-update-ns,strutil: move PathIterator to strutil, add Depth helper <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5319> | 17:08 |
| mup | PR snapd#5081 opened: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081> | 17:10 |
| zyga | mborzecki, jdstrand, Chipaca: I updated https://github.com/snapcore/snapd/pull/5081 and it is ready for another review | 17:10 |
| mup | PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081> | 17:10 |
| mborzecki | cachio: let me take a quick look, don't know why it's not showing 'there is nothing to do' message | 17:17 |
| cachio | mborzecki, we should remove the update from the snapd test suite | 17:18 |
| mborzecki | cachio: pacman got updated recently, maybe it's showing different output when there are no updates now | 17:18 |
| cachio | I mean, we don't need to update all the packages for arch | 17:18 |
| cachio | mborzecki, I am updating the images every 3 weeks | 17:19 |
| cachio | mborzecki, what do you think? | 17:19 |
| mborzecki | cachio: well in theory we ought to be | 17:19 |
| mborzecki | cachio: i'll take a quick look, it's probably something trivial | 17:19 |
| mborzecki | cachio: can I use this image somehow, or have you replaced the one that we used before? | 17:20 |
| cachio | mborzecki, I already remove the image | 17:20 |
| cachio | I could create a new one | 17:21 |
| mborzecki | cachio: can you built it and name it differntly than the one we have now? i'll update spread.yaml locally to use it | 17:22 |
| cachio | mborzecki, sure | 17:22 |
| cachio | mborzecki, in progress | 17:23 |
| cachio | mborzecki, arch-linux-64-new-v20180613 | 17:31 |
| cachio | this is the image | 17:31 |
| mborzecki | cachio: thx | 17:33 |
| zyga | I’m going for a bike run | 17:46 |
| zyga | See you later | 17:47 |
| mborzecki | cachio: right, so the logic in prepare_project for arch is wrong, i'll try to do a quick fix | 17:53 |
| cachio | mborzecki, great, tx | 17:53 |
| === pstolowski is now known as pstolowski|afk | ||
| mborzecki | hmm my shellcheck got updated to 0.5.0 and it's rasing some issues in tests/lib/*.sh | 18:07 |
| mup | PR snapd#5320 opened: tests/lib/prepare-restore: fix upgrade/reboot handling on arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5320> | 18:11 |
| mborzecki | cachio: ^^ | 18:11 |
| cachio | mborzecki, tx | 18:18 |
| mup | PR snapd#5030 closed: packaging/amzn2: initial packaging of 2.32.5 for Amazon Linux 2 <Reviewed> <Created by bboozzoo> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5030> | 18:55 |
| zyga | re | 19:46 |
| * zyga is safely back from biking | 19:46 | |
| cachio | zyga, if you have 5 minutes #5320 | 19:57 |
| cachio | thanks | 19:57 |
| mup | PR #5320: tests/lib/prepare-restore: fix upgrade/reboot handling on arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5320> | 19:57 |
| mup | PR snapd#5320 closed: tests/lib/prepare-restore: fix upgrade/reboot handling on arch <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5320> | 20:01 |
| zyga | cachio: pleasure :-) | 20:01 |
| zyga | jdstrand: hey, around? | 20:01 |
| jdstrand | meeting | 20:02 |
| cachio | zyga, tx | 20:02 |
| Luke | guys when I do a ruby build in a build-override, how do I move those files into the stage then? | 20:19 |
| Chipaca | mbuahaha, got 'snap info' talking to v2/info \o/ | 20:24 |
| Chipaca | sergiusens: you around? | 20:25 |
| sergiusens | Chipaca: yup | 20:25 |
| Chipaca | sergiusens: two things | 20:25 |
| sergiusens | Luke: make sure they end up in `$SNAPCRAFT_PART_INSTALL` | 20:26 |
| sergiusens | Chipaca: one by one | 20:26 |
| Chipaca | sergiusens: one, building a cross-platform snap-pack turned out to be a lot more work than I thought it would be, so it's on my plate as a Thing (as opposed to something I slot in between the cracks) | 20:26 |
| Chipaca | sergiusens: two was Luke and you've done that :-) | 20:26 |
| Chipaca | sergiusens: as i see it i should be getting to work on it early next week | 20:27 |
| Chipaca | but I don't own my priorities :-) | 20:27 |
| sergiusens | Chipaca: oh neat, does that include replacing mksquashfs too or just snap? I wonder, not require 😉 | 20:28 |
| Chipaca | sergiusens: it does not include replacing mksquashfs | 20:29 |
| mup | PR snapd#5321 opened: tests: fix interfaces-contacts-service test retrying to remove share dir <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5321> | 20:29 |
| Luke | sergiusens: thanks. is that var documented somwhere? I couldn't find it in the docs | 20:29 |
| Chipaca | sergiusens: it's mostly a lot of careful separation of code into cross-platformy bits, but also a bunch of figuring out how to run a test suite on windows :-) | 20:29 |
| Chipaca | sergiusens: I need to be in a special mindset for that last bit | 20:30 |
| Chipaca | or hire somebody :-D | 20:30 |
| Chipaca | (number of times I've gone for "hire somebody" in that situation: 3) | 20:30 |
| sergiusens | Luke uses are describe on https://snapdocs.labix.org/scriptlets/4892 or https://docs.snapcraft.io/build-snaps/scriptlets | 20:30 |
| sergiusens | Chipaca: use appveyor, that is what we use | 20:31 |
| Luke | i saw the scriptlets docs before. there's no mention of $SNAPCRAFT_PART_INSTALL besides in passing in an example | 20:31 |
| Luke | i guess I'm looking for an explanation of the best practices/intended use of $SNAPCRAFT_PART_INSTALL etc | 20:32 |
| Luke | thanks btw | 20:32 |
| Chipaca | sergiusens: nice, i'll look that up | 20:32 |
| Chipaca | sergiusens: what happens every time I start is that I'm an hour into reading and I'm just adding to a stack of things to figure out :-) hence why i need to set aside time for it | 20:34 |
| Chipaca | sergiusens: for example, appveyor seems to boil down to "run msbuild for you" | 20:35 |
| Chipaca | so no i need to learn msbuild | 20:35 |
| Chipaca | etc :) | 20:35 |
| Chipaca | sergiusens: no worries, but not quick for me | 20:35 |
| Chipaca | i'll get to it next week | 20:35 |
| Chipaca | hopefully | 20:35 |
| zyga | jdstrand: if you still have time today please look at chopTree again | 20:39 |
| zyga | It now does what you asked for | 20:39 |
| Chipaca | zyga: if you've got beans after the bike run, #5316 :-D | 20:39 |
| mup | PR #5316: store, et al: kill dead code that uses the bulk endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/5316> | 20:39 |
| Chipaca | zyga: also 'bike run' seems like you're doing something wrong :-) | 20:40 |
| jdstrand | zyga: ok, it's on my list. it may be tomorrow | 20:44 |
| zyga | Chipaca: that explains the odd stare ;-) | 20:53 |
| zyga | I’ll read it first thing tomorrow | 20:54 |
| jdstrand | niemeyer: hi! can you add this to your queue to give some thought: https://forum.snapcraft.io/t/camera-raw-usb-plugs-auto-connect-for-qtchildid/2917/4 | 21:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
