| diddledan | yeah that's what I thought, too | 00:00 |
|---|---|---|
| diddledan | you might be right that it's due to unpacking the stage packages but it takes an inordinately long time | 00:00 |
| diddledan | something seems screwey because a single cpu core is pegged at 100% usage (not parallelised in any way) | 00:01 |
| kyrofa | Well, it uses the apt python API, so yeah, that sounds right | 00:04 |
| mwhudson | kyrofa: hey can i talk to you about patchelf? :) | 00:26 |
| mup | PR snapcraft#2060 opened: package: ensure all relevant files are in for sdist <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2060> | 01:26 |
| mborzecki | morning | 05:12 |
| zyga | hey hey | 05:17 |
| zyga | good morning | 05:17 |
| zyga | there's going to be a thunderstorm this evening :) | 05:17 |
| zyga | I cannot wait for that, I really missed them | 05:17 |
| mborzecki | yeah, relaly can't wait for the first power outage this year | 05:19 |
| zyga | ouch, do you think it will come to that? | 05:21 |
| zyga | I was used to power outages in Spain when it was raining | 05:21 |
| zyga | but not used to them here even when there's a very fierce storm | 05:21 |
| mborzecki | right where i live there's an outage almost every time there's a thunderstorm | 05:21 |
| mborzecki | otoh living in deep suburbs/almost country has some benefits too | 05:22 |
| mborzecki | someone raised a really nice idea in the forum: https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/102 | 05:23 |
| zyga | yes, that's a nice idea | 05:23 |
| zyga | mobile data == restrict downloads | 05:23 |
| mborzecki | need to look at the implementation, whether the setting is exposed over dbus and if so which bus it is | 05:24 |
| mborzecki | mvo: morning | 05:24 |
| zyga | mborzecki: it's dconf/gconf most likely | 05:24 |
| zyga | good morning mvo | 05:24 |
| mborzecki | zyga: looks like networkmanager https://bug792608.bugzilla-attachments.gnome.org/attachment.cgi?id=366968 | 05:24 |
| mborzecki | or libnm for that matter | 05:25 |
| * zyga goes to make breakfast for the kids | 05:26 | |
| mborzecki | that's nice, if it's nm, then we could poke it through dbus | 05:28 |
| mvo | hey mborzecki and zyga ! good morning | 05:30 |
| mup | PR snapd#5017 closed: daemon,overlord/hookstate: stop/wait for running hooks before closing the snapctl socket (2.32) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5017> | 05:39 |
| * zyga needs to pay some taxes but will be back to work shortly | 06:08 | |
| zyga | mvo: hey | 06:25 |
| mup | PR snapd#5019 closed: data/selinux: Give snapd access to more aspects of the system (2.32) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5019> | 06:26 |
| zyga | mvo: about 2.32.4, it seems we have some number of PRs open | 06:27 |
| zyga | is the goal to land that today? | 06:27 |
| mvo | pedronis: you mentioned the snap roadmap page on the forum was a bit outdated/confusing, I updated it now, let me know if there is anything left that looks inconsistent or wrong | 06:36 |
| mvo | zyga: not necessarily today but I think it would be good to prepare a 2.32.4 soon. we need to wait a little bit with the new api merge until we are sure that we don't need a .4 for .3 | 06:36 |
| mvo | zyga: (if that makes sense) | 06:37 |
| zyga | hehe, Yes | 06:37 |
| mborzecki | anyone wants to take a quick look at #5003, trivial change | 06:43 |
| mup | PR #5003: cmd/snap-seccomp: graceful handling of non-multilib host <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5003> | 06:43 |
| mborzecki | ? | 06:44 |
| mvo | mborzecki: sure | 06:45 |
| mborzecki | it'd be great if we could put it in .4 too, would allow me to drop a patch in the packacing | 06:45 |
| mborzecki | mvo: thanks :) | 06:45 |
| mborzecki | zyga: what is the version of fontconfig that breaks compatibility? | 06:50 |
| mborzecki | hmm btrfs on 4.14.26-54.32.amzn2.x86_64, shutting down lxc container produces this: kernel https://paste.ubuntu.com/p/kp842QyGng/ | 06:55 |
| zyga | mborzecki: 2.13 | 07:00 |
| zyga | mborzecki: I'm going afk now (dog) but once back I can give you a reference to thebug report | 07:00 |
| mborzecki | hm i have local/fontconfig 2.13.0+10+g58f5285-1 here | 07:00 |
| mborzecki | zyga: heh, see what you mean, https://paste.ubuntu.com/p/cyxSH6cwVB/ saw that earlier and assumed that it's something with spotify snap | 07:01 |
| mborzecki | zyga: it's not 'crashing' though | 07:03 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:11 |
| mup | PR snapd#5020 opened: errtracker: check for whoopsie.service instead of reading /etc/whoopsie <Created by mvo5> <https://github.com/snapcore/snapd/pull/5020> | 07:15 |
| kalikiana | good morning o/ | 07:16 |
| pstolowski | hey kalikiana | 07:21 |
| zyga | Mborzecki: the reporter on one arch derivative saw crashes | 07:25 |
| zyga | Hey kalikiana | 07:25 |
| mborzecki | zyga: maybe it's some specific snap, spotify seems to work | 07:25 |
| zyga | Perhaps | 07:26 |
| zyga | I’m still outside, I’ll sit in a coffee shop soon | 07:26 |
| mup | PR snapd#5014 closed: overlord/snapstate: introduce envvars to control the channels for bases and prereqs <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5014> | 07:41 |
| Chipaca | moin moin | 07:55 |
| zyga | Hey hey John | 07:56 |
| mup | PR snapd#5021 opened: overlord/snapstate: introduce envvars to control the channels for bases and prereqs (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5021> | 08:04 |
| pedronis | mvo: I created a backport of the envvars branch ^ | 08:04 |
| pedronis | #5018 needs a 2nd review | 08:05 |
| mup | PR #5018: overlord/snapstate: on multi-snap refresh make sure bases and core are finished before dependent snaps <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5018> | 08:05 |
| pedronis | mvo: about roadmap: I see a formatting problem with USB hotplug status emoji ... also in 2.32 feeding cloud-init and CDN aware are the same I think | 08:11 |
| zyga | re | 08:11 |
| zyga | pedronis: I'll review 5018 next | 08:15 |
| mborzecki | zyga: checking for metered connection should be easy, just loooking at this prop on the main nm object https://developer.gnome.org/NetworkManager/unstable/gdbus-org.freedesktop.NetworkManager.html#gdbus-property-org-freedesktop-NetworkManager.Metered | 08:16 |
| zyga | mborzecki: should snapd do that check directly? | 08:17 |
| mborzecki | zyga: yeah, that's there it makes most sense probably | 08:18 |
| zyga | what would happen on a core device that uses network-manager for networking | 08:18 |
| zyga | snapd would have to understand that that endpoint is down when the n-m snap is inactive for instance | 08:19 |
| mborzecki | zyga: the values of NMMeteres are somewhat funny https://developer.gnome.org/NetworkManager/unstable/nm-dbus-types.html#NMMetered, NM_METERED_GUESS_NO, heh | 08:19 |
| zyga | (or that a device may be only and always on metered connection) | 08:19 |
| pedronis | we would need some gadget config or core config to ignore this | 08:19 |
| pedronis | also there might be no NM as well | 08:19 |
| mborzecki | no NM is easy to handle | 08:20 |
| zyga | I wonder how it determines the guess | 08:20 |
| pedronis | anyway it sounds like it needs a design forum post | 08:21 |
| zyga | yes, definitely | 08:21 |
| zyga | feels like a "snap set system refresh.metered = "always | priority | never" thing | 08:22 |
| zyga | with gadget control as well | 08:22 |
| mborzecki | `connection.metered: unknown`, that's for my wifi connection | 08:23 |
| mborzecki | but i can explicitly mark it as metered | 08:24 |
| mborzecki | zyga: are you on a modem now? | 08:24 |
| Chipaca | mwhudson: yo | 08:24 |
| zyga | yes | 08:24 |
| mwhudson | Chipaca: hello | 08:25 |
| Chipaca | mwhudson: my go snap auto-refreshed and now sigsegvs | 08:25 |
| zyga | mborzecki: do you want me to check? | 08:25 |
| mborzecki | zyga: can you do 'nmcli c show --active', the pick the uuid and `nmcli c show <uuid>`, look for connection.metered | 08:25 |
| zyga | sure | 08:25 |
| mwhudson | Chipaca: refresh again and it should break | 08:25 |
| mwhudson | *unbreak | 08:25 |
| Chipaca | mwhudson: ok :-) how so? | 08:25 |
| mwhudson | Chipaca: patchelf is bad? | 08:25 |
| mwhudson | Chipaca: https://forum.snapcraft.io/t/patchelf-broke-my-binary/4928 | 08:25 |
| Chipaca | mwhudson: sigh. ok. | 08:26 |
| zyga | mborzecki: it's a bit dumb | 08:26 |
| mwhudson | it'll unbreak just because i published the old version again | 08:26 |
| zyga | nmcli being dumb about metered https://www.irccloud.com/pastebin/UbF7cxGb/ | 08:26 |
| zyga | mborzecki: I wonder if it is in any way confused by the presence of the LXD bridge | 08:26 |
| Chipaca | mwhudson: except now the store is timing out | 08:26 |
| Chipaca | (╯°□°）╯︵ ┻━┻ | 08:27 |
| zyga | mborzecki: I don't see any way to mark the connection as metered from the gui | 08:27 |
| mborzecki | zyga: hm, aren't you on gnome 3.28? | 08:27 |
| zyga | mborzecki: and I don't see why it would not be marked as metered, pretty much all GSM/3G/4G/LTE is metered some way | 08:27 |
| zyga | mborzecki: I'm on bionic now | 08:28 |
| zyga | that's 3.28 | 08:28 |
| mborzecki | zyga: hm `nmcli c modify <uuid> connection.metered true` should mark it | 08:28 |
| Chipaca | hmm, something's going on in the dc | 08:28 |
| mvo | pedronis: ok, thanks, I will fix that | 08:28 |
| mwhudson | yeah canonical irc is flapping | 08:29 |
| zyga | hmm | 08:29 |
| zyga | (process:14018): libnmc-CRITICAL **: 10:29:11.195: file clients/common/nm-meta-setting-desc.c: line 765 (<dropped>): should not be reached | 08:29 |
| Chipaca | that + the assertions endpoint timing out | 08:29 |
| zyga | mborzecki: ^ that's from "show" | 08:29 |
| zyga | mborzecki: after the manual change | 08:29 |
| zyga | metered connection (after manually tweaking the value) https://www.irccloud.com/pastebin/lBCN8dLI/ | 08:30 |
| mborzecki | zyga: woow ;) | 08:30 |
| mborzecki | zyga: can you do `busctl --system introspect org.freedesktop.NetworkManager /org/freedesktop/NetworkManager` and look for .Metered ? | 08:30 |
| zyga | sure | 08:30 |
| mwhudson | so i have this binary in stage, it works, the one in prime breaks | 08:30 |
| zyga | oh, busctl is a new thing to me | 08:30 |
| pedronis | Chipaca: is connectivity, I think they are making it worse to make it better, but it got worse than unexpected | 08:31 |
| pedronis | *than expected | 08:31 |
| zyga | systemd :0 | 08:31 |
| mborzecki | or `busctl --system get-property org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager Metered` | 08:31 |
| mwhudson | if i take the staged one and run strip --remove-section .note.go.buildid and patchelf --set-interpreter /snap/core/current/lib64/ld-linux-x86-64.so.2 it still works | 08:31 |
| mwhudson | wtf is going on | 08:31 |
| zyga | I wait for malware that is called something like ${crap}ctl to seem like another part of systemd | 08:31 |
| mborzecki | zyga: yeah, but it's easier to use than dbus-send | 08:31 |
| mwhudson | ah snapcraft does RPATH things as well | 08:31 |
| zyga | zyga@t470:~$ busctl --system introspect org.freedesktop.NetworkManager /org/freedesktop/NetworkManager | grep Metered | 08:32 |
| zyga | .Metered property u 1 emits-change | 08:32 |
| mborzecki | zyga: at least UX wise, just seems to do the right thing | 08:32 |
| zyga | mborzecki: yeah, no doubt about that | 08:32 |
| zyga | mborzecki: it's pretty nice | 08:32 |
| zyga | mborzecki: we could subscribe to changes of that property | 08:32 |
| zyga | mborzecki: read it | 08:32 |
| zyga | mborzecki: and then carry on | 08:32 |
| zyga | mborzecki: it feels like connectivty manager in overlord | 08:32 |
| mborzecki | ok, so now it's showing metered = 1 -> NM_METERED_YES according to the NM dbus spec | 08:32 |
| zyga | mborzecki: it could also monitor offline/online status | 08:32 |
| mwhudson | ok can repro | 08:33 |
| mborzecki | zyga: yes | 08:33 |
| zyga | and eventually it could understand the set of snaps responsible for network being up | 08:33 |
| mborzecki | zyga: i've actually used it in that camera boards i've shown you the photos of ;) | 08:33 |
| zyga | and expose that to snapmgr | 08:33 |
| zyga | yeah | 08:33 |
| zyga | mborzecki: ok, let me know if you need any more testing | 08:34 |
| zyga | mborzecki: as an intereseting use case | 08:34 |
| zyga | mborzecki: all off office.zygoon.pl is on a metered connection | 08:34 |
| zyga | mborzecki: from a router that has metered wifi | 08:34 |
| mborzecki | ha, wonder how it figured that out | 08:34 |
| zyga | well, the wifi/lan is metered as it is routerd through the LTE | 08:34 |
| zyga | mborzecki: nothing figures that out yet | 08:35 |
| zyga | but there's some part of the wifi spec that can convey this fact | 08:35 |
| zyga | perhaps through DHCP but I really don't know | 08:35 |
| zyga | but I read that gnome or maybe androind wants to support that | 08:35 |
| zyga | mborzecki: if you want to play on my office LAN I can make an account for you | 08:35 |
| mborzecki | (if it touches any of IEEE standards then it's better not to know) | 08:35 |
| mborzecki | zyga: thanks but no need for now ;) just wanted to get the general picture | 08:36 |
| zyga | sure :) | 08:37 |
| mborzecki | zyga: btw. i've updated #4989 | 08:37 |
| mup | PR #4989: tests: add arch to CI <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4989> | 08:37 |
| zyga | I'll finish review of 5018 and then start chopping my WIP user mounts branch | 08:37 |
| zyga | mborzecki: thanks, I'll check soon | 08:37 |
| zyga | http://omgfoss.com/install-spotify-linux-ubuntu-debian-fedora/ | 08:43 |
| zyga | this is cute :) | 08:43 |
| zyga | https://www.irccloud.com/pastebin/kAgEqb8f/ | 08:44 |
| Chipaca | zyga: funny how they skipped the 'snap install spotify' step | 08:46 |
| zyga | oh | 08:47 |
| zyga | indeed | 08:47 |
| zyga | hahaa | 08:47 |
| zyga | that's even more silly | 08:47 |
| popey | :) | 08:48 |
| Chipaca | pedronis: was playing with the performance of unserialising an entry of a json object last night | 08:48 |
| Chipaca | pedronis: I've got another reason to move to go 1.7+ | 08:48 |
| Chipaca | :-) | 08:48 |
| * zyga found the "chronic" utility from moreutils | 08:48 | |
| zyga | Caelum: I added LEAP 15 to https://build.opensuse.org/project/show/system:snappy | 08:57 |
| mborzecki | fmt.Println("baz == other type", foo["zed"] == "dez") | 08:58 |
| mborzecki | w8, but spotify is not a classic snap, no need for the symlink | 08:58 |
| mborzecki | aand copy pasted some random sample with comparing interfaces i was preparing for jdstrand's review :) | 08:58 |
| popey | no, but if you're installing snapd for the first time, you might want to do that for future classic snaps you may install | 08:59 |
| mborzecki | zyga: can we land #4980? | 08:59 |
| mup | PR #4980: Revert "spread.yaml: switch Fedora 27 tests to manual (#4962)" <Created by zyga> <https://github.com/snapcore/snapd/pull/4980> | 08:59 |
| zyga | mborzecki: yes | 08:59 |
| zyga | let's | 08:59 |
| zyga | this unblocks cachio's work on fedora-on-google | 09:00 |
| mup | PR snapd#4980 closed: Revert "spread.yaml: switch Fedora 27 tests to manual (#4962)" <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4980> | 09:00 |
| zyga | pedronis: reviewed 5018 | 09:05 |
| pedronis | thx, I expended the comments a bit | 09:27 |
| pedronis | heh, expanded | 09:32 |
| zyga | pedronis: thank you | 09:34 |
| pstolowski | how can I interrupt/restart travis job that's stuck somewhere since yesterday? https://github.com/snapcore/snapd/pull/4940 | 09:35 |
| mup | PR #4940: RFC: added UDevMonitor for future hotplug support <Created by stolowski> <https://github.com/snapcore/snapd/pull/4940> | 09:35 |
| mwhudson | Chipaca: well that was fun to chase down https://github.com/NixOS/patchelf/issues/146 | 09:42 |
| zyga | pstolowski: let me look | 09:43 |
| zyga | ah | 09:43 |
| zyga | that's more interesting, there's no link | 09:44 |
| Chipaca | mwhudson: nice spelunking | 09:44 |
| zyga | looks like travis broke there | 09:44 |
| zyga | can you se that branch via travis itself? | 09:44 |
| mwhudson | Chipaca: patchelf is .... interesting | 09:45 |
| Chipaca | mwhudson: do I want to know | 09:46 |
| Chipaca | :-) | 09:47 |
| mwhudson | /* !!! Why do we stop after a .dynstr section? I can't | 09:47 |
| mwhudson | remember! */ | 09:47 |
| mwhudson | for example | 09:47 |
| pedronis | loose specs and faulty memory | 09:48 |
| Chipaca | mwhudson: /* yolo */ | 09:48 |
| mwhudson | Chipaca: pretty much | 09:48 |
| mwhudson | pedronis: not so much "loose specs" as "it works on my machine" :/ | 09:49 |
| pedronis | mwhudson: well to be fair I expect elf and how it's used by compilers to be said, it worked with the binaries from baz | 09:49 |
| pedronis | s/to be said/to be loose/ | 09:49 |
| mwhudson | i wonder what patchelf would do with burneye and things like that | 09:49 |
| pedronis | maybe that's unfair though , and is not as bad as dwarf | 09:54 |
| Chipaca | we should all go back to a.out | 09:55 |
| Chipaca | :-) | 09:55 |
| pstolowski | zyga: ah, right, i can get to the branch/build from travis directly. the missing link confused me. thanks | 09:58 |
| mwhudson | pedronis: i've never had the courage to learn much about DWARF | 10:09 |
| === chihchun_afk is now known as chihchun | ||
| pedronis | mwhudson: well it's extensible, as usual if extensible format don't have way to convey this you can ignore or not, writing stable tooling is a nightmare | 10:10 |
| pedronis | mvo: zyga: we are getting handshake errors from linode, it means landing stuff to 2.32 is not easy, I wonder if we should back port the switch to gcloud | 10:11 |
| pedronis | otoh it might be travis network issues | 10:12 |
| zyga | I can try | 10:12 |
| pedronis | anyway: this is not fun: https://travis-ci.org/snapcore/snapd/builds/364488153?utm_source=github_status&utm_medium=notification | 10:12 |
| mup | PR snapd#5018 closed: overlord/snapstate: on multi-snap refresh make sure bases and core are finished before dependent snaps <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5018> | 10:14 |
| pedronis | so backporting 5018 requires the new api stuff, or a rework of the backend_test changes | 10:18 |
| mvo | pedronis: new api because of tests | 10:25 |
| mvo | pedronis: ? or because of the functionality? | 10:27 |
| === pstolowski is now known as pstolowski|lunch | ||
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapcraft#2061 opened: go: only use Go build package if not using the snap <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2061> | 10:53 |
| pedronis | mvo: because of tests | 11:06 |
| pedronis | mvo: backend_test.go is very different | 11:06 |
| * mvo nods | 11:07 | |
| pedronis | mvo: given that the plan is still to land the new api, I will prepare a backport on top of 5002 , instead of a direct one | 11:10 |
| pedronis | mvo: anyway we have troubles atm with tests on 2.32 because they still use linode and there seems to be travis->linode or linode problems | 11:10 |
| mvo | pedronis: yeah, porting to google seems like a good idea | 11:13 |
| mvo | zyga I got a report about snapd leaking threads, apparently for longer running snapd on bionic "ps -eTf|grep snapd" report very high numbers (in the 400s) for some people on bionic when it runs for ~2-3 days - you run bionic as well, is this something you see too? | 11:14 |
| cachio | mvo, CE has approved 32.3 to stable | 11:14 |
| zyga | Oh | 11:14 |
| mvo | cachio: brilliant! | 11:15 |
| zyga | No but i restart snapd for testing | 11:15 |
| mvo | cachio: so once the store is ready lets push it out :) | 11:15 |
| mup | PR snapd#5022 opened: overlord/snapstate: on multi-snap refresh make sure bases and core are finished before dependent snaps (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5022> | 11:15 |
| mvo | cachio: and fingers crossed for tihs version | 11:15 |
| cachio | mvo, sure | 11:15 |
| mvo | zyga: yeah, same here | 11:15 |
| mvo | pedronis: thanks for this PR! | 11:15 |
| mvo | zyga: no worries, I try to gather more data | 11:17 |
| pedronis | mvo: I'll try to make a PR for 2.32 with just the systems stanza from master, not sure if we need other changes | 11:18 |
| pedronis | I mean backends | 11:19 |
| mvo | pedronis: +1 | 11:19 |
| thresh | is snapcraft.io down? | 11:21 |
| mwhudson | thresh: looks like it | 11:22 |
| thresh | hopefully nothing serious then | 11:22 |
| mwhudson | thresh: i've pinged a sysadmin | 11:23 |
| * mwhudson goes to bed | 11:23 | |
| thresh | many thanks! | 11:23 |
| popey | https://status.snapcraft.io/ is handy fwiw | 11:24 |
| thresh | (I firstly assumed it's the nation-wide firewall that blocks the way here, but oh well) | 11:24 |
| mup | PR snapd#5023 opened: spread.yaml: try to switch to run tests on gcloud <Created by pedronis> <https://github.com/snapcore/snapd/pull/5023> | 11:32 |
| pedronis | let's see ^ | 11:33 |
| zyga | pedronis: thank you | 11:33 |
| zyga | sorry for not doing it before, I just got home now | 11:33 |
| zyga | I need to file some time off for today | 11:33 |
| zyga | the vet visit and other stuff was more walking than working | 11:33 |
| pedronis | it might not work | 11:34 |
| pedronis | I don't know if it we have other changes that were needed | 11:34 |
| pedronis | we'll see | 11:34 |
| zyga | pedronis: hmm, perhaps something in run-tests.sh? | 11:35 |
| pedronis | I don't know | 11:35 |
| pedronis | ah true | 11:36 |
| zyga | actually run-checks | 11:36 |
| zyga | spread google: linode: | 11:36 |
| mborzecki | wrote a test to check if the logging through journal stream sockets works correctly, and it's failing radomly because the journal is not flushed yet :/ | 11:36 |
| zyga | that's closer to master now | 11:36 |
| zyga | mvo: is there a report for the thread leak issue? | 11:36 |
| zyga | mvo: on my artful desktop I see this: | 11:37 |
| zyga | zyga@fyke:~/go/src/github.com/snapcore/snapd$ ps -eLf | grep '[s]napd' | wc -l => 23 | 11:37 |
| zyga | mvo: I am seeing this on my bionic laptop | 11:40 |
| zyga | zyga@t470:~/go/src/github.com/snapcore/snapd/cmd$ ps -eLf | grep '[s]napd' | wc -l => 122 | 11:40 |
| zyga | over 100 more threads | 11:40 |
| zyga | even though the deskop is a 8 core machine and the laptop is a 2 core machine | 11:40 |
| mup | PR snapd#5024 opened: systemd: add helper for opening stream file descriptors to the journal <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5024> | 11:46 |
| mborzecki | zyga: ps -eLf | grep '[s]napd' | wc -l => 36 on CPU(s): 16 | 11:48 |
| zyga | mborzecki: on arch or ubuntu? | 11:49 |
| Chipaca | oh snap, lunch | 11:49 |
| mborzecki | arch | 11:49 |
| zyga | interesting, that's golang 1.10? | 11:49 |
| mborzecki | 1.10.1 | 11:49 |
| mborzecki | package version is 2.32.2.r508.g629585a3f-1, let me rebuild the latest master | 11:50 |
| pedronis | Chipaca: there's a meeting in 10 minutes | 11:50 |
| zyga | same as in bionic (apart from probable patches) | 11:50 |
| mborzecki | pedronis: standup @ 3pm right? | 11:50 |
| Chipaca | pedronis: yeah. running. | 11:50 |
| Chipaca | mborzecki: yeah, meeting is about epochs | 11:50 |
| pedronis | mborzecki: yes, this is something else | 11:50 |
| mborzecki | okok | 11:50 |
| zyga | ah | 11:50 |
| zyga | uff :) | 11:50 |
| * Son_Goku groans to life | 11:52 | |
| === pstolowski|lunch is now known as pstolowski | ||
| Son_Goku | zyga, you should be able to re-enable fedora in CI now | 11:55 |
| zyga | Son_Goku: we already enabled and merged it | 11:55 |
| zyga | mborzecki: reviewed | 11:57 |
| mborzecki | zyga: thanks | 11:57 |
| mborzecki | heh, gofmt -s did not catch this | 11:58 |
| zyga | mborzecki: 5003 reviewed | 12:00 |
| mborzecki | zyga: ta :) | 12:01 |
| mborzecki | off to pick up the kids, be back for standup | 12:05 |
| zyga | cachio, mvo: 2.32.3 stable today? | 12:09 |
| * zyga installed the new "communitheme" snap | 12:14 | |
| zyga | it's pretty neat, so the snap is a dumb data carrier | 12:14 |
| zyga | and something in the desktop is picking up the snap's presence | 12:14 |
| cachio | zyga, yes | 12:16 |
| cachio | It should | 12:17 |
| zyga | mvo: interestingly the number of threads is pretty stable, after reboot I see 114 | 12:24 |
| zyga | reading snapstore docs | 12:30 |
| zyga | why is "sudo snapstore config store.domain="<domain>"" used over "snap set snapstore store.domain=... | 12:30 |
| mvo | zyga: 114? I just have 12 here, let me try in a clean VM | 12:32 |
| zyga | mvo: yes, this is vanilla beta | 12:32 |
| zyga | er, sorry, that's vanilla edge | 12:32 |
| mvo | zyga: I will try chocolate edge then | 12:33 |
| zyga | I wish golang tweaked each thread cmdline buffer to indicate what is going on | 12:33 |
| mup | PR snapd#5025 opened: interfaces/shutdown: allow calling SetWallMessage <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5025> | 12:42 |
| mup | PR snapd#5012 closed: snap: fix `snap advise-snap --command` output to match spec <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5012> | 12:43 |
| ogra_ | niemeyer, not sure if we have something like this on any snapd TODO yet ... (would be nice to have) https://forum.snapcraft.io/t/support-ask-for-reboot-via-sapcraft-yaml-and-snapd | 12:57 |
| ogra_ | niemeyer, heh, i guess we can merge that one with https://forum.snapcraft.io/t/allow-automatic-reboots-when-refreshing-a-snap/4935 (seems abeato and I had the same idea ) | 13:00 |
| * Chipaca will be a couple of minutes late to the standup (previous meeting overrun and I need a technical stop) | 13:01 | |
| zyga | Chipaca: ack | 13:04 |
| zyga | jdstrand: are we going to use the stash directory approach | 13:04 |
| zyga | jdstrand: or shall we go for the better option directly? | 13:04 |
| jdstrand | zyga: I think that is based in part on release timing. that said, since this didn't make 2.32, why not just go for the non-stash approach since it is approved | 13:06 |
| zyga | jdstrand: yeah, that sounds good to me, thank you | 13:07 |
| zyga | jdstrand: and I can use this immediately then | 13:07 |
| zyga | jdstrand: actually, can I merge both | 13:08 |
| zyga | I think it's just worth preserving in history | 13:09 |
| zyga | I'll merge the 1st approach | 13:09 |
| zyga | resolve conflicts | 13:09 |
| zyga | and merge the 2nd approach | 13:09 |
| zyga | if you don't mind I'd prefer that | 13:09 |
| jdstrand | zyga: I don't mind at all. it makes sense to me | 13:11 |
| zyga | perfect, thank you | 13:11 |
| niemeyer | It's quite unbelievable.. I just spent more than 10 minutes trying to join the meeting from an Android phone.. no go | 13:14 |
| niemeyer | Any hangout links send me to the application.. the application doesn't know what to do with it | 13:15 |
| niemeyer | zyga: How did you manage to join yesterday? | 13:15 |
| === chihchun_afk is now known as chihchun | ||
| niemeyer | Anyway.. see you soon | 13:15 |
| zyga | niemeyer: I have an iPhone | 13:16 |
| zyga | niemeyer: maybe we can dial you in with good old phone number | 13:16 |
| zyga | one sec | 13:16 |
| niemeyer | zyga: That's even more ironic | 13:17 |
| niemeyer | zyga: Can you send me a direct invite maybe? | 13:17 |
| zyga | niemeyer: I tried to dial you in from the hangout | 13:17 |
| zyga | but that doesn't work because we're out of credit | 13:17 |
| zyga | yes, sure | 13:17 |
| niemeyer | Hangouts seems able to do one-on-one.. maybe with an invite it'd wake up | 13:17 |
| zyga | sent | 13:18 |
| katnip | which hangouts | 13:19 |
| katnip | from G Suite? | 13:20 |
| niemeyer | It joined, and then the phone rebooted /o\ | 13:20 |
| niemeyer | zyga: Thanks, I'll continue the trip.. next time I'll use the laptop tethered | 13:21 |
| zyga | niemeyer: you connected for a se | 13:21 |
| zyga | you're still connected here | 13:21 |
| zyga | can you hear us? | 13:21 |
| zyga | ah | 13:22 |
| zyga | I just noticed your phone rebooted :? | 13:22 |
| zyga | man, that's not fun | 13:22 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapd#4868 closed: cmd/snap-update-ns: add secure bind mount implementation for use with user mounts <Squash-merge> <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4868> | 13:32 |
| zyga | mvo: https://docs.ubuntu.com/snap-enterprise-proxy/en/install | 13:36 |
| mup | PR snapcraft#1992 closed: tests: run integration tests on trusty <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1992> | 13:36 |
| mup | Bug #1620755 changed: x509: certificate signed by unknown authority <certificate> <proxy> <Snappy:Won't Fix> <https://launchpad.net/bugs/1620755> | 13:38 |
| mvo | zyga: thank you | 13:38 |
| diddledan | jdstrand: you're my hero today :-) webtorrent-desktop appears to be unblocked now thanks to confinement rules updates | 13:43 |
| jdstrand | diddledan: nice! :) | 13:43 |
| Chipaca | mvo: pedronis: fwiw I SIGQUITed snapd when it had 18 threads, and it only had ~4 goroutines | 13:55 |
| mborzecki | interesting | 13:56 |
| Chipaca | myeah | 13:56 |
| Chipaca | next I'll run it with the tracer and see what that says | 13:56 |
| mborzecki | then what are the other threads doing? :) | 13:57 |
| mvo | zyga: how many goroutines do you have if you SIGQUIT your 100ish threaded snapd? | 14:00 |
| mborzecki | afk, taking my son for a vaccination :/ | 14:00 |
| zyga | One sec | 14:00 |
| zyga | mvo: o, so just pkill SIGQUIT snapd | 14:02 |
| mvo | zyga: yeah | 14:02 |
| zyga | ok, done | 14:03 |
| zyga | I see tons of debug in journal | 14:03 |
| zyga | and I see 10 threads now | 14:03 |
| zyga | mvo: https://pastebin.ubuntu.com/p/kKkGJp2Hbb/ | 14:05 |
| Chipaca | zyga: can you 'grep -c "goroutine [0-9]"' that? | 14:05 |
| zyga | kwi 10 16:02:58 t470 snapd[1943]: goroutine 234 [syscall, 110 minutes]: | 14:06 |
| zyga | one sec | 14:06 |
| Chipaca | it seems go keeps the threads around once it's done with them | 14:07 |
| Chipaca | which makes sense :-) | 14:07 |
| zyga | 114 | 14:07 |
| Chipaca | zyga: whoa | 14:08 |
| Chipaca | zyga: is this reproducible? | 14:08 |
| zyga | yes | 14:08 |
| Chipaca | zyga: can you patch your snapd to run with the tracer, then? | 14:08 |
| zyga | it looks like most of this is read from htt | 14:08 |
| zyga | http | 14:08 |
| zyga | just tell me how sir | 14:08 |
| Chipaca | zyga: http://paste.ubuntu.com/p/PstYvgMygh/ | 14:08 |
| Chipaca | zyga: then run it (make sure it doesn't re-exec :) ) and when it gets to have that many threads, ctrl-c it | 14:09 |
| zyga | k | 14:09 |
| Chipaca | zyga: and put the /tmp/snapd.trace file somewhere :-) | 14:09 |
| Chipaca | (maybe compress it first) | 14:09 |
| mvo | zyga, Chipaca interessting, thats a lot of stuff | 14:11 |
| Chipaca | yus | 14:12 |
| zyga | patched snapd, disabled reexec | 14:12 |
| zyga | 15 threads | 14:12 |
| kyrofa | mwhudson, sorry, I was EOD by the time you pinged me, but yes, happy to talk about it! | 14:12 |
| zyga | _obviously_ | 14:12 |
| zyga | I'm watching the number of threads | 14:14 |
| zyga | installed a snap to do some activity | 14:14 |
| zyga | interesting | 14:15 |
| zyga | I installed tizonia | 14:15 |
| zyga | refreshed lxd to different channel | 14:15 |
| zyga | and I'm at 19 now | 14:15 |
| Chipaca | in that dump from your sigquit you've got a lot of things stuck on read | 14:15 |
| zyga | refreshed lxd back to stable, still 19 | 14:15 |
| zyga | yes | 14:15 |
| Chipaca | from (*ucrednetConn).Read( | 14:15 |
| Chipaca | I wonder if anything's changed with 1.10, there | 14:16 |
| zyga | hmmm https://www.irccloud.com/pastebin/JFpqggZU/ | 14:16 |
| zyga | is this expected | 14:16 |
| zyga | there's no core restart anymore | 14:16 |
| zyga | I stopped snapd.socket,service | 14:16 |
| zyga | started snapd manually with sudo | 14:16 |
| zyga | this is on master + the patch from chipaca about tracing | 14:17 |
| Chipaca | zyga: restart is done by systemd, not us | 14:17 |
| zyga | are we opening the snapctl socket ourselves? | 14:17 |
| Chipaca | zyga: snapd just goes away and comes back | 14:17 |
| zyga | Chipaca: but I don't refresh core now | 14:17 |
| zyga | Chipaca: and reexec is off | 14:17 |
| Chipaca | zyga: you're running snapd in another terminal, by hand, yes? | 14:18 |
| zyga | yes | 14:18 |
| Chipaca | zyga: what does the other terminal tell you :-) | 14:18 |
| zyga | 2018/04/10 16:14:11.222937 handlers.go:189: cannot get state of snap "no state entry for key": %!s(MISSING) | 14:18 |
| zyga | that's fun | 14:18 |
| zyga | rest of the snapd output https://www.irccloud.com/pastebin/Wyuc0qHX/ | 14:18 |
| Chipaca | zyga: you're running with debug on, yes? | 14:18 |
| * Chipaca looks | 14:18 | |
| zyga | no :) | 14:18 |
| zyga | sorry, just regular | 14:19 |
| zyga | but that handlers.go thing is a clear bug | 14:19 |
| Chipaca | zyga: https://github.com/chipaca/bin/blob/master/run-snapd-srv | 14:19 |
| zyga | man, ignore me | 14:20 |
| zyga | that's an old build | 14:20 |
| mup | PR snapd#5025 closed: interfaces/shutdown: allow calling SetWallMessage <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5025> | 14:20 |
| zyga | it's working on actually patched and compled snapd | 14:21 |
| zyga | *compiled | 14:21 |
| zyga | but still 17 threads | 14:21 |
| kyrofa | mwhudson, ah, I see you forum post now | 14:23 |
| zyga | and wayland crashed | 14:27 |
| zyga | I wish gnome-shell would not log errors every other second | 14:28 |
| Son_Goku | zyga, so looks like RHEL 7.5 arrived | 14:29 |
| Son_Goku | and with it, apparently GNOME was rebased to GNOME 3.26 | 14:29 |
| Son_Goku | I'll have to check and see if all the components of GNOME were rebased | 14:29 |
| zyga | mvo, Chipaca: no idea why the snap from core has all those weird threads | 14:29 |
| zyga | and this one does not | 14:30 |
| zyga | golang 1.6 vs 1.10.1? | 14:30 |
| zyga | Son_Goku: are you saying snapd for RHEL can now be a thing? | 14:30 |
| * zyga jokes about windows for warships | 14:30 | |
| pedronis | zyga: 1.6 on different kernel though | 14:30 |
| Son_Goku | probably not | 14:30 |
| zyga | pedronis: same kernel here | 14:30 |
| Son_Goku | but I can certainly try to rebase my current test packages | 14:30 |
| zyga | pedronis: I have the 100+ threads if I use the snapd from core | 14:31 |
| pedronis | zyga: I'm saying, on the xenial kernel, go 1.6 snapd I don't see tons of threds | 14:31 |
| zyga | ah | 14:31 |
| zyga | I see | 14:31 |
| pedronis | anyway we should really medidate how to stop using 1.6 for the snapd that goes into core | 14:31 |
| Chipaca | 1.10 would be nice :-) | 14:31 |
| pedronis | well something supported (by upstream) at least | 14:32 |
| zyga | pedronis: I think snapd.snap can be built on 18.04 | 14:32 |
| mvo | zyga: fwiw, I have a bionic vm (and my real system) where I don't see this amount of threads | 14:32 |
| zyga | and we sunset 1.6 support | 14:32 |
| Son_Goku | zyga: build the snapd.snap on Fedora :P | 14:32 |
| Son_Goku | be different :) | 14:32 |
| zyga | Son_Goku: well, I do build it on fedora, but people who ship it tell me they need to build it in the archive | 14:33 |
| zyga | ok, I'll keep my copy running, I need to get back to coding | 14:33 |
| koza | hey, folks what is the forecast on having the 2.32 in the stable channel? | 14:34 |
| pedronis | koza: plan is today | 14:34 |
| koza | awesome | 14:35 |
| mvo | cachio: any word from the store about the release | 14:35 |
| cachio | mvo, I'll ask now | 14:36 |
| Chipaca | so, an interesting thing is | 14:36 |
| Chipaca | once it starts a thread, it doesn't seem to let it go | 14:36 |
| Chipaca | (which is probably fine) | 14:36 |
| Chipaca | but the threads aren't doing anything | 14:37 |
| Chipaca | that is, in the trace they don't appear as busy | 14:37 |
| mvo | cachio: thank you | 14:38 |
| pedronis | Chipaca: I looked if we had interesting LockOSThread around, but seems we don't | 14:45 |
| pedronis | go itself might though | 14:46 |
| mvo | all crazy - i386 adt tests fail because of https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101 apparently. just in very non-obvious ways :( | 14:50 |
| mvo | I add code | 14:51 |
| pedronis | ah | 14:55 |
| zyga | mvo: man, that's nasty | 15:05 |
| zyga | maybe kernel leaks in apparmor profiles | 15:05 |
| zyga | wow | 15:06 |
| zyga | man that thread is golden | 15:06 |
| popey | jdstrand: brave have a problem with their latest build in edge (19). The previous build works fine. I see an apparmor fail in ibus... https://paste.ubuntu.com/p/gsYkbhX2kQ/ | 15:10 |
| popey | jdstrand: anything we have seen before, and can help? | 15:10 |
| mvo | zyga: yeah, I think there is a leak somewhere in the kernel and its especially bad on i386 | 15:10 |
| mvo | zyga: because the kernel uses lowmem only for whatever reason there | 15:11 |
| zyga | why not on arm? | 15:11 |
| mvo | zyga: I want to add a check in our restore code that checks for oom and errors hard | 15:11 |
| mvo | zyga: I don't know | 15:11 |
| jdstrand | popey: oSoMoN is working on that ibus bug. aiui, it is non-fatal | 15:24 |
| mvo | zyga: because right now the error is very indirect and also very unclear why it hangs journalctl | 15:25 |
| zyga | if journal is synicing and were OOM (and perhaps swapping already) maybe it is the IO load | 15:25 |
| popey | jdstrand: brave coredumps :( | 15:25 |
| zyga | but yeah, the memory leak looks like the issue behind it | 15:25 |
| mborzecki | Chipaca: yeah, there's just few goroutines doing 'real' stuff, the rest is parked https://paste.ubuntu.com/p/T2WJXWwnPF/ | 15:26 |
| jdstrand | popey: bluez is nothing to worry about. the /etc/opt/chrome they need to adjust something-- they don't have DAC write access to that anyway. I can add something for /sys/devices/system/memory/block_size_bytes | 15:26 |
| jdstrand | popey: it may core dump, but the ibus access is probably not what is causing that. that is coming from a library that doesn't check the return code: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1761585 | 15:27 |
| mup | Bug #1761585: ibus_bus_init does an unconditional call to chmod on $HOME/.config/ibus/bus <amd64> <apport-bug> <bionic> <verification-needed> <verification-needed-xenial> | 15:27 |
| mup | <ibus:Fix Released> <ibus (Ubuntu):Fix Released by osomon> <ibus (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1761585> | 15:27 |
| popey | jdstrand: ok | 15:28 |
| jdstrand | popey: you can add to the profile: 'owner @{HOME]/.config/ibus/bus/ w,' to prove that to yourself | 15:28 |
| jdstrand | popey: you can connect the bluez interface to get rid of that denial | 15:29 |
| popey | brave 18 works even with those denials | 15:29 |
| jdstrand | popey: you can add: '/sys/devices/system/memory/block_size_bytes r,' to see if that is it (again, I doubt it) | 15:29 |
| jdstrand | popey: right, that is what I figured | 15:29 |
| jdstrand | popey: the /etc/opt/chrome is possibly interesting. that needs to be $SNAP/etc/opt/chrome | 15:30 |
| popey | in brave rev 19 the gui appears then immediately disappears again | 15:31 |
| jdstrand | popey: it could be something is going on down in $SNAP_USER_DATA or $SNAP_COMMON such that on first start, things are ok, then on next run they aren't. unless you are saying on first run after a refresh it shows then dies. that might suggest a gl issue | 15:33 |
| jdstrand | SNAP_USER_COMMON* | 15:33 |
| * jdstrand adds /sys/devices/system/memory/block_size_bytes to list for next batch of updates | 15:34 | |
| popey | jdstrand: I have tested with a clean install (wiped out ~/snap/brave before running) | 15:34 |
| * zyga still has just 15 threads | 15:34 | |
| jdstrand | popey: gl is working ok elsewhere? | 15:34 |
| popey | yes, and rev 18 works | 15:34 |
| popey | i have also tested 18 vs 19 in a 16.04 VM, same issue. | 15:35 |
| popey | https://paste.ubuntu.com/p/PkrmcR7g62/ seeing that lot on console in 19, not in 18 | 15:37 |
| diddledan | is there a reasonable way of ensuring that xdg reports that the Downloads folder is in $SNAP_USER_COMMON instead of $SNAP_USER_DATA? | 15:40 |
| diddledan | this is probably a reasonable thing for many snaps | 15:41 |
| popey | For some snaps I set environment: "HOME": "$SNAP_USER_COMMON" in th apps section in the yaml | 15:42 |
| diddledan | e.g. why should downloads saved through firefox get versioned? | 15:42 |
| diddledan | thanks, popey , I'll try that | 15:42 |
| jdstrand | popey: maybe they updated browser_main_loop.cc without considering snapd, or series 16 stage-packages, or something in the desktop part. may need desktop team help | 15:43 |
| * jdstrand thought the desktop part setup symlinks from SNAP_USER_wherever to ~/Foo | 15:44 | |
| diddledan | no the desktop parts can't do that because they might be used on snaps that don't include the `home` plug | 15:45 |
| * zyga thinks we should have snapctl is-connected thing | 15:47 | |
| diddledan | bug. if you specify a remote part that you've not already cached, and try to run `snapcraft update` in the project that includes the remote part in an `after` clause, snapcraft doesn't actually fetch the updated definitions until you remove the `after` | 15:48 |
| jdstrand | zyga: if 'is-connected' is about network connectivity, if you add that and it needs some sort of specific access that the default doesn't allow, add it to network-status | 15:51 |
| diddledan | https://www.irccloud.com/pastebin/necbNhqK/ | 15:51 |
| zyga | jdstrand: we have is-connected command already? | 15:51 |
| diddledan | ^^^^ that's an attempt to fetch updated remote parts | 15:51 |
| popey | jdstrand: ugh, browser_main_loop.cc comes from chromium upstream. oSoMoN have you seen anything like this in chromium recently? https://paste.ubuntu.com/p/PkrmcR7g62/ | 15:52 |
| jdstrand | zyga: there is an interface that is meant to answer that question. it needs a slot implementation. I'm saying if you make core that slot implementation, add it there | 15:52 |
| oSoMoN | popey, no, that doesn't ring a bell | 15:52 |
| popey | oSoMoN: ok, thanks! | 15:52 |
| zyga | jdstrand: I mean in the "snap connect" sense | 15:52 |
| zyga | a way to check if a plug is connected | 15:52 |
| zyga | or a slot | 15:53 |
| zyga | it would be useful for apps to make simple decisions | 15:53 |
| jdstrand | zyga: oh, I thought you meant "am I online". ignore me | 15:53 |
| jdstrand | pstolowski probably would know best, iirc | 15:53 |
| jdstrand | I thought there were hooks for that, but maybe they are only planned | 15:54 |
| zyga | there are hooks | 15:54 |
| pedronis | mvo: mmh, it was lost in the other errors but #5021 also needs new api first, because of tests | 15:54 |
| mup | PR #5021: overlord/snapstate: introduce envvars to control the channels for bases and prereqs (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5021> | 15:54 |
| zyga | but this means you need to mirror state | 15:54 |
| zyga | if we can just ask | 15:55 |
| zyga | at runtime, at any moment | 15:55 |
| pstolowski | zyga jdstrand the hooks executed on connect haven't landed yet; and yes, a way to check if a plug/slot is connected via snapctl would be nice | 15:58 |
| skomorokh | Aha, here you are. FYI, it wasn't super clear on the webpage that this is the channel (so I wound up guessing wrong a couple times with #snapcraft and #snap) | 16:08 |
| pedronis | mborzecki: I reviewed your 'system' key in config defaults PR | 16:08 |
| === pstolowski is now known as pstolowski|afk | ||
| mvo | pedronis: thank you! ok, so lets land the new api soon (once we got the stable out without issues :) | 16:12 |
| JonelethIrenicus | any steam snaps | 16:15 |
| skomorokh | Is there an FAQ for curmudgeonly debian types that have questions/paranoia about telemetry/tracking/fingerprinting and the like? | 16:15 |
| kyrofa | skomorokh, haha, no, but perhaps there should be! | 16:16 |
| kyrofa | Do you have any specific concerns? | 16:16 |
| skomorokh | I trust Canonical more than Slack/Microsoft/Google so would like to switch to using snaps vs. vendor-supplied .debs ...excecpt now I wonder what this snapd is doing and what it's telling this central service about me :) | 16:17 |
| kyrofa | skomorokh, well, would looking at the snapd source code make you feel better? | 16:17 |
| zyga | skomorokh: there's a few things we tell | 16:17 |
| zyga | skomorokh: like /etc/os-release level info | 16:17 |
| skomorokh | I'd prefer an executive summary. | 16:17 |
| zyga | and the snaps you refresh | 16:17 |
| JonelethIrenicus | snap uses apparmor | 16:17 |
| zyga | and the version of snapd | 16:17 |
| skomorokh | Can it tell I'm the same user that installed a package last week? | 16:18 |
| zyga | skomorokh: we have some extra data sent when something fails (apparmor style error reporting) but this is configurable (PR is up for that) | 16:18 |
| skomorokh | eg. is there an identifier tying my usage of the system together? | 16:18 |
| zyga | skomorokh: yes, I believe it uses /etc/machine-id (needs checking) | 16:18 |
| skomorokh | Is that optional? | 16:18 |
| zyga | skomorokh: plus, if you log in that's that | 16:18 |
| zyga | I don't believe that's optional but I honestly don't remebmer | 16:18 |
| kyrofa | zyga, what is the use-case for the unique identifier? | 16:18 |
| zyga | I need to check if we really send that | 16:19 |
| zyga | maybe I'm mistaken | 16:19 |
| zyga | sorry | 16:19 |
| skomorokh | First thing I did was go to replace my slack deb with a slack snap, only to have it tell me I have to pass it a parameter to let it run unconfined. | 16:19 |
| zyga | we don't send that | 16:19 |
| skomorokh | Yay! I'm happy you don't! | 16:19 |
| nacc | skomorokh: right slack is a 'classic' snap still | 16:20 |
| skomorokh | And while I'm sad I can't sandbox slack out of the box, I'm happy that it told me it wants to be unconfined. | 16:20 |
| zyga | but we do use it | 16:20 |
| zyga | when an error happens | 16:20 |
| zyga | we hash the machine id | 16:20 |
| zyga | and send that hash | 16:20 |
| zyga | but error reporting is optional | 16:20 |
| kyrofa | zyga, I didn't know snapd had error reporting. Is it enabled by default? | 16:21 |
| kyrofa | How does one opt in or out? | 16:21 |
| zyga | kyrofa: yes, it is enabled by default but that may change soon | 16:21 |
| skomorokh | Is snapcraft.io optional? eg. can I use a different hub? | 16:21 |
| pedronis | kyrofa: it will follow whoopsie settings | 16:21 |
| zyga | kyrofa: this goes to the ubuntu error tracker | 16:21 |
| pedronis | at least on ubuntu | 16:21 |
| kyrofa | Ah, okay | 16:21 |
| zyga | and some people can see statistics | 16:22 |
| zyga | we used it a few times when bugs caused widespread errors in the field | 16:22 |
| zyga | and we were ignorant to that before we had the error tracker data | 16:22 |
| zyga | skomorokh: there's no hub in snapd, there's a store and each machine talks to exactly one store | 16:22 |
| mup | PR snapcraft#2062 opened: packaging: simplify snapcraft.yaml <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2062> | 16:22 |
| zyga | stores are configurable but you will realistically still only use either the official store or your private deployment of a store proxt | 16:22 |
| pedronis | kyrofa: it's not for all errors, or errors from snaps, is really errors on refresh or install | 16:23 |
| pedronis | of snaps | 16:23 |
| zyga | yes, it's when snapd malfunctions really | 16:23 |
| skomorokh | Is the code for the store public? | 16:23 |
| zyga | no, it is not | 16:23 |
| kyrofa | Whenever snapd panics, I expect | 16:23 |
| skomorokh | Aw. So if you turn evil or something the OSS community can fork away :( | 16:23 |
| skomorokh | *can't | 16:23 |
| kyrofa | skomorokh, note that all the APIs are documented | 16:24 |
| zyga | it's a matter of implementing the store side and starting a new root of strust (store is a root of trust in the snapd model) | 16:24 |
| zyga | so if we turn evil, there's some hope still ;-) | 16:24 |
| mup | PR snapd#5026 opened: tests: add check for OOM error after each test <Created by mvo5> <https://github.com/snapcore/snapd/pull/5026> | 16:24 |
| skomorokh | Right, but that's a big barrier, implementing that whole stack! | 16:24 |
| skomorokh | Or is it? I've only been thinking about snaps for a handful of minutes, maybe the store is quite lightweight? | 16:25 |
| mborzecki | pedronis: thanks | 16:25 |
| zyga | skomorokh: but also big advantage of having one place where apps come from, with sane securty, comprehensive snadbox (it's always something that can improve but I think we're doing pretty well) | 16:26 |
| zyga | skomorokh: I think it depends on one's perspective | 16:26 |
| skomorokh | Oh, I like that, that's why I want to use it. | 16:26 |
| skomorokh | I just want the option for the community to bail on you without starting over. | 16:26 |
| zyga | skomorokh: there are a few URLs we use to search, query and download snaps and assertions | 16:26 |
| skomorokh | Everyone maintaining snaps is investing into the ecosystem. | 16:26 |
| zyga | but I'm not an expert in that area | 16:26 |
| zyga | I think that option is there, if there's desire someone can always fork snapd, implement some simple store, deploy it and update the store URL | 16:27 |
| zyga | not saying it's easy but it's not impossible either, snapd is complex in general | 16:27 |
| skomorokh | I see snapd is developed in public. | 16:28 |
| zyga | having a store that scales, etc is another thign | 16:28 |
| zyga | yes | 16:28 |
| zyga | all work, code and design is public | 16:28 |
| skomorokh | I think that'd make it easier, having the commits, the issues, etc. | 16:28 |
| zyga | I'm a developer that works on execution layers for example | 16:29 |
| skomorokh | So I think being able to search the store counterpart would help. | 16:29 |
| zyga | snap find ... | 16:29 |
| zyga | funny that "snap find foo" finds so many foo snaps :) | 16:29 |
| skomorokh | I mean, search the history of development communications around the store too the way we can by searching snapd issues. | 16:29 |
| zyga | ah I see | 16:30 |
| zyga | well, store is not publuc | 16:30 |
| skomorokh | Ya exactly :) | 16:30 |
| zyga | most of the store changes are coming directly from snapd | 16:30 |
| zyga | and can be found in the snapd history | 16:30 |
| zyga | plus there's a lot on forum.snapcraft.io | 16:30 |
| noise][ | and there is discussion on store features https://forum.snapcraft.io/c/store | 16:30 |
| popey | The click store that pre-dates it wasn't either. The community founded an "open store" which has now taken over on Ubuntu phone. | 16:30 |
| * zyga hugs noise][ | 16:31 | |
| zyga | thank you! | 16:31 |
| skomorokh | Interesting. | 16:31 |
| popey | When Ubuntu Phone was dropped, the community rallied and have built a pipeline for apps in the open store | 16:31 |
| noise][ | also, you can always side-load snaps without a store | 16:31 |
| popey | It's more active now than when we maintained it ;) | 16:31 |
| zyga | popey: do you know I still use my reall retail ubuntu phone | 16:31 |
| skomorokh | 'cause so far I'm convinced I want to use this because it feels more trustable than dpkg which is basically "here's root, go nuts" | 16:31 |
| zyga | I still have it, it's running ubuntu with the open store | 16:32 |
| noise][ | you lose benefits but it's there as an option | 16:32 |
| popey | zyga: me too :) | 16:32 |
| skomorokh | But I'm not quite convinced I want to _advocate_ for it and maintain snaps etc. | 16:32 |
| zyga | skomorokh: yes, the sandbox is very interesting | 16:32 |
| popey | I have a bq 4.5 on my desk, updated it today | 16:32 |
| zyga | skomorokh: I'm also familiar with the sandbox in case you have questions | 16:32 |
| skomorokh | zyga: Can I sandbox things that don't want to be sandboxed? | 16:32 |
| popey | skomorokh: I work on the developer advocacy side. I'd welcome your feedback if you did look at making a snap. | 16:32 |
| zyga | skomorokh: try making some software and ensuring it is up-to-date (yourself) in 3 most common distros (and maybe 2-3 older releases that still have users) | 16:33 |
| zyga | skomorokh: then look at snaps again :) | 16:33 |
| zyga | it's a godsend | 16:33 |
| popey | skomorokh: we're always looking for people outside the project who have snapped something, to give us honest critical feedback. | 16:33 |
| zyga | jdstrand: do you want one last look at https://github.com/snapcore/snapd/pull/4957 before I merge it | 16:33 |
| mup | PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957> | 16:33 |
| skomorokh | Well, so far I'm leery about investing myself that much in it because the store is closed. | 16:34 |
| zyga | skomorokh: well, use it, try some snaps | 16:35 |
| zyga | skomorokh: package something, learn how that works | 16:35 |
| zyga | skomorokh: see how the interface systems looks like | 16:35 |
| skomorokh | I understand why it makes sense to have it centralised, but it feels sketchy to have something so closed aspire to become central to OSS | 16:35 |
| zyga | skomorokh: how the sandbox looks like | 16:36 |
| zyga | there's tons of great stuff in snapd | 16:36 |
| jdstrand | zyga: LGTM | 16:36 |
| zyga | thanks! | 16:36 |
| jdstrand | please commit | 16:36 |
| zyga | skomorokh: then people say how great android is because android is linux, this is way way way more open | 16:36 |
| zyga | for one,you can commit here | 16:36 |
| zyga | we don't throw code over the wall once in $RELEASE_CYCLE | 16:37 |
| zyga | you can discuss with the devs, not with press people | 16:37 |
| skomorokh | Good points! | 16:37 |
| zyga | you can influence the design, the code, everything really | 16:37 |
| zyga | there are business points (store) but that's actually good, it means it can sustain itself | 16:37 |
| zyga | it's not going to spy on you to make that money | 16:37 |
| popey | skomorokh: like github? :) | 16:38 |
| zyga | and unlike other solutions it is more complete | 16:38 |
| zyga | it's not limited to some class of apps | 16:38 |
| skomorokh | popey: Quite, hence gitlab :) | 16:38 |
| popey | :) | 16:39 |
| zyga | and doesn''t have hand-wave'y "optional security" that nobody actually uses and is actually not strong and sensible security | 16:39 |
| skomorokh | firejail is just handwavey? | 16:39 |
| * zyga made terrible allusions to other packaging systems | 16:39 | |
| zyga | use of firejail with <something else> is very handwave'y | 16:39 |
| zyga | and note one thing: the instruction on how to confine an app comes with the app | 16:40 |
| zyga | that's not useful | 16:40 |
| zyga | that's 15.05 snappy 1.x design | 16:40 |
| zyga | and it doesn | 16:40 |
| diddledan | I'm still randomly getting "invalid association handle" whenever I try to login to build.snapcraft.io via ubuntu sso | 16:40 |
| zyga | and it doesn't scale or work really | 16:40 |
| zyga | oh, and it is optional, so nobody uses it really | 16:41 |
| zyga | compare that to snapd sandbox and interface system, where everyone gets the same predictable non-optional sanbox | 16:41 |
| zyga | and there are well-defined ways to extend it | 16:41 |
| skomorokh | except slack gets to opt out and run as root | 16:41 |
| skomorokh | (which it wonderfully tells me about!) | 16:41 |
| zyga | where well-defined is that each snap uses the same definition, users can learn what that means | 16:41 |
| zyga | yes, but that's not sandboxed really | 16:42 |
| skomorokh | can I tell it to sandbox anyway? | 16:42 |
| zyga | and it's very honest about it as you noticed | 16:42 |
| zyga | yes but most software that requests this won't work | 16:42 |
| zyga | you can snap install --jail slack | 16:42 |
| zyga | er | 16:42 |
| zyga | --jailmode | 16:42 |
| zyga | it will just put it in a regular sandbox | 16:42 |
| zyga | but slack won't work then | 16:42 |
| zyga | eventually slack may opt into confinement | 16:43 |
| skomorokh | slack is just electron going to their webpage + stuff for facilitating the tray icon ya? | 16:43 |
| zyga | but they have not yet | 16:43 |
| zyga | I honestly don't know | 16:43 |
| skomorokh | Hm, so if I get really enthusiastic about snap and spend a bunch of time building a slack image that works in confined mode, can I publish that somehow? | 16:44 |
| skomorokh | I assume I can't redistribute their software, but can I maintain a patch to their packaging that lets me lock it down? | 16:45 |
| diddledan | hmm, who has registered the name `webtorrent-desktop` in the store? have they actually used that name at all or can snapcrafters nab it? :-p | 16:45 |
| zyga | skomorokh: yes, but it won't be called "slack", it would have to be something else | 16:45 |
| zyga | plus, I don't know if you have the right to modify their application | 16:45 |
| zyga | but you can install it on your machine, yes | 16:46 |
| zyga | sure | 16:46 |
| zyga | is *this* _supported_ in this __client__ **maybe**? | 16:46 |
| zyga | no | 16:46 |
| zyga | diddledan: how did you format webtorrent-desktop? | 16:46 |
| zyga | maybe like `this`? | 16:47 |
| zyga | yes | 16:47 |
| zyga | ah, nice | 16:47 |
| popey | diddledan: it was registered back in june 2016 | 16:47 |
| popey | diddledan: no uploads. | 16:47 |
| diddledan | is it owned by upstream or a random passer-by? | 16:47 |
| zyga | skomorokh: plus, snappy is pushing some boundaries, it's a very fun project to live in | 16:47 |
| popey | diddledan: upstream | 16:47 |
| zyga | from kernel side to linux desktop technology | 16:48 |
| diddledan | if it's upstream then I'll just file a PR against their repo and they can publish directly, but I wanted to get something out | 16:48 |
| popey | Feross registered it | 16:48 |
| noise][ | diddledan: appears to be upstream | 16:48 |
| diddledan | right-oh, I'll just file a PR against their repo then :-) | 16:48 |
| diddledan | thanks | 16:48 |
| skomorokh | How do snaps persist their local configs? They can access my home directory from their confinement? | 16:50 |
| zyga | skomorokh: there are more nice features that you may not know about (channels are so obviously missing from classic packaging) | 16:50 |
| zyga | skomorokh: snaps get their private place for storing data, that's $SNAP_DATA, $SNAP_USER_DATA | 16:50 |
| zyga | skomorokh: for services and apps | 16:50 |
| zyga | skomorokh: there's also SNAP_COMMON and SNAP_USER_COMMON for specialized use-cases | 16:51 |
| zyga | skomorokh: snaps don't see the real HOME variable so they have a mini-home elsewhere | 16:51 |
| zyga | skomorokh: that's in your real $HOME/snap/$SNAP_NAME/$SNAP_REVISION/ | 16:51 |
| skomorokh | So it copies my configs between versions as it updates? | 16:52 |
| zyga | skomorokh: snaps can read and write to most of your regular home if they use the "home" interface (run "snap interface home") | 16:52 |
| zyga | skomorokh: yes | 16:52 |
| zyga | skomorokh: we are working on integrating desktop portals so that portal-aware apps can use them too | 16:52 |
| skomorokh | Nice, so I can rollback to my previous config if I have issues with the new version. Does it clean up old ones or just suck up infinite space over time? | 16:52 |
| zyga | (so typical GTK apps will use portals for opening files from arbitrary places, under user's explicit choice) | 16:53 |
| skomorokh | Can I protect sensitive parts of my home directory eg. exclude ~/.ssh from the "home" interface? | 16:53 |
| zyga | skomorokh: that's done by default | 16:53 |
| zyga | skomorokh: all dot-files are off-limits | 16:53 |
| skomorokh | Ah, nice. | 16:53 |
| skomorokh | But not for classic, it does w/e? | 16:54 |
| zyga | no, classic confinement == no confinement | 16:54 |
| zyga | like in "classic linux systems" | 16:54 |
| skomorokh | Ya, so there's no light jail to give a false sense of security, it's proper confinement or no. | 16:54 |
| skomorokh | Seems sensible. | 16:54 |
| zyga | skomorokh: for instance this is the whole definition of the home interface: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/home.go | 16:55 |
| skomorokh | Oh sweet, it's go! | 16:55 |
| zyga | yes, we are trying not to run large complex C apps as root | 16:57 |
| zyga | you can see all the other interfaces here: https://github.com/snapcore/snapd/tree/master/interfaces/builtin | 16:57 |
| diddledan | ok, PR filed against webtorrent-desktop: https://github.com/webtorrent/webtorrent-desktop/pull/1353 | 16:57 |
| mup | PR webtorrent/webtorrent-desktop#1353: add snap packaging <Created by diddledan> <https://github.com/webtorrent/webtorrent-desktop/pull/1353> | 16:57 |
| skomorokh | Oh man, this is so close to everything I hoped it would be. | 16:58 |
| popey | diddledan: nice one! | 16:58 |
| zyga | interfaces cannot be added by apps so nobody will add "all access to everything" interface in a note taking app | 16:58 |
| * diddledan crosses his toes | 16:58 | |
| skomorokh | So I tried a snap, figured okular is a good one because it didn't want classic and so my pdf viewer is going to get some confinement. | 16:59 |
| skomorokh | Which is nice because it's handling random stuff from the internet so it's attack surface. | 16:59 |
| skomorokh | 'cept I can't purge okular's deb since kubuntu depends on it. | 17:00 |
| cachio | mvo, so far so good, 2.32.3 is stable now and smoke test passed | 17:00 |
| skomorokh | How do I tell it to prefer the snap? Does this tie in to update-alternatives? | 17:00 |
| nacc | skomorokh: /snap/bin in your PATH | 17:01 |
| nacc | skomorokh: that's provided by snapd into /etc/profile.d on Ubuntu | 17:01 |
| skomorokh | But not early enough since which okular is still showing /usr/bin | 17:01 |
| nacc | skomorokh: is /snap/bin in your PATH? | 17:01 |
| skomorokh | I assume it based on what you say. | 17:02 |
| nacc | skomorokh: are you on ubuntu? | 17:02 |
| skomorokh | Yup, kubuntu 17.10 | 17:02 |
| nacc | skomorokh: easy enough to check, to be sure, of course | 17:02 |
| nacc | skomorokh: /snap/bin is the last entry in PATH, iirc, so if you want to prefer snaps over debs, you need to edit the profile | 17:02 |
| zyga | cachio: good | 17:02 |
| zyga | skomorokh: hash -r | 17:02 |
| skomorokh | Ya, exactly. And I've confirmed. | 17:02 |
| zyga | skomorokh: which okular | 17:02 |
| nacc | /etc/profile.d/apps-bin-path.sh | 17:03 |
| zyga | skomorokh: you can always "snap run okular" | 17:03 |
| zyga | snap run --help has some extra options | 17:03 |
| skomorokh | heh, I need to connect it to more snaps. | 17:03 |
| zyga | skomorokh: play, explore, learn ask | 17:03 |
| zyga | welcome to the community! | 17:03 |
| skomorokh | Thanks! I definitely do feel welcome. | 17:04 |
| skomorokh | And I really appreciate the project, it's going to help make Linux easier to adopt for less technical users. | 17:05 |
| skomorokh | Plus help everyone be more secure. | 17:05 |
| zyga | and everyone can be in one boat of apps | 17:05 |
| zyga | not in fractured silos | 17:05 |
| zyga | chihchun_afk: hey | 17:05 |
| zyga | oh you're afk | 17:05 |
| skomorokh | That's got pros and cons. | 17:05 |
| zyga | mborzecki: around? | 17:05 |
| zyga | I'd like a 3rd review for https://github.com/snapcore/snapd/pull/4957 | 17:06 |
| mup | PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957> | 17:06 |
| zyga | skomorokh: snaps complement classic packages so each distribution can still innovate by itself | 17:06 |
| zyga | but innovation doesn't zero the app counter | 17:06 |
| skomorokh | And that's why I would hope there is more transparency around the store if it really does have a chance of being a central hub for OSS app developement. | 17:06 |
| zyga | and innovation doesn't mean apps need to be re-packaged every 6 months or whatever the release cycle is | 17:06 |
| zyga | oho, storm is coming | 17:08 |
| skomorokh | So I have a suggestion for the monetisation... I can't buy software with it because then I'd need to register an account with the snapd on my computer at which point I'm tying my behaviour to my identity. | 17:09 |
| zyga | skomorokh: when linux is 1% of your userbase, the last thing you want is to spend x5 effor to cover ubuntu, fedora and maybe something else | 17:09 |
| skomorokh | But I'd love to login to my account in a browser and conveniently contribute money to a project. | 17:10 |
| zyga | skomorokh: how would you then tell snapd that you can use a for-pay snap/ | 17:10 |
| skomorokh | I never will, for that reason. | 17:11 |
| skomorokh | Just like I subscribe to the guardian but don't login to my account. | 17:11 |
| zyga | but the guardian is available anyway | 17:11 |
| zyga | (I also subscribe btw :) | 17:11 |
| zyga | if a snap is free you can already use it | 17:11 |
| skomorokh | Right, that's why I subscribe ;) | 17:11 |
| zyga | note that the buy story is still in wraps | 17:11 |
| zyga | and there's plenty of room for improvement | 17:11 |
| skomorokh | I don't subscribe to papers I can't read without subscribing because then they learn what articles I read (hell, they learn how I move my mouse while I'm reading the article) | 17:12 |
| skomorokh | Is there any risk that associating an account with snapd will become mandatory? | 17:12 |
| skomorokh | I imagine there'd be some pressure to do that... | 17:12 |
| zyga | no, I doubt that | 17:13 |
| nacc | don't you already have to login to snapd? | 17:13 |
| zyga | it used to be | 17:13 |
| zyga | but we made it optional now | 17:13 |
| nacc | ah ok | 17:13 |
| nacc | zyga: good to know, thanks | 17:13 |
| zyga | it was just a matter of work, it's a 2.0 but still pretty early stages | 17:13 |
| skomorokh | That's a good direction but kinda worrisome it was ever like that. | 17:14 |
| zyga | it was like that because we didn't have polkit support and other things | 17:15 |
| zyga | again, very early days back then | 17:15 |
| zyga | you could always use sudo to do stuff | 17:15 |
| skomorokh | Even at a cursory glance it's clear this is a massive engineering effort. | 17:15 |
| zyga | ah, sorry, my memory is rusty | 17:15 |
| zyga | sudo was since forever | 17:15 |
| zyga | authorization was needed in GUI apps before we had polkit | 17:15 |
| zyga | now it's fully optional | 17:16 |
| zyga | because GUI apps are regular users (not root) talking to snapd | 17:16 |
| zyga | so there was no way to prove you can install / remove apps | 17:16 |
| zyga | when you sudo snap stuff we use peer credetnials over the socket to konw | 17:16 |
| zyga | *know | 17:16 |
| zyga | so that's why we had to login to the store | 17:17 |
| zyga | because once logged in you'd get a polkit prompt from the GUI and authenticate | 17:17 |
| zyga | and that was used as proof | 17:17 |
| skomorokh | Heh. | 17:17 |
| zyga | now it's all history | 17:17 |
| skomorokh | Can I selectively deny interfaces? | 17:19 |
| skomorokh | Awww vscode is classic too ;( | 17:20 |
| zyga | skomorokh: you can disconnect them | 17:20 |
| zyga | skomorokh: there's a forum thread about why IDEs are classic currently | 17:20 |
| skomorokh | ty, I'll look for that. | 17:20 |
| zyga | there's some missing technology to make them strict still | 17:20 |
| zyga | (without making them useless) | 17:21 |
| zyga | skomorokh: once you disconnect an automatically connected interface it won't auto-connect on that snap again | 17:21 |
| zyga | skomorokh: we have a policy system so that powerful interfaces are not auto connected | 17:21 |
| zyga | skomorokh: and some cannot even be declared at all | 17:21 |
| zyga | skomorokh: each snap has an assertion that is issued by the store | 17:21 |
| zyga | skomorokh: the assertion can grant access to some powerful interfaces on a per-snap basis | 17:22 |
| skomorokh | Can I install something without it ever being allowed to use an interface? | 17:22 |
| zyga | skomorokh: this is why you can install LXD as a snap | 17:22 |
| skomorokh | So even if it might be autoconnected I can choose to not let it be? | 17:22 |
| zyga | skomorokh: no, we don't have that right now, what would be your use case? | 17:22 |
| zyga | skomorokh: if it's about home that is a transitional interface that will be phased out over time | 17:22 |
| zyga | skomorokh: it's a matter of getting portals and momentum to use them | 17:22 |
| zyga | skomorokh: note that home is only auto-connected on "classic" devices (classic that they use regular packages as well) | 17:23 |
| zyga | skomorokh: on core devices (that only use snaps for everything on the system) this is no longer the case | 17:23 |
| skomorokh | Hypothetically I want to use vscode but want to be sure that Microsoft never learns that my current IP used it. | 17:23 |
| zyga | skomorokh: I see, well, network is granted by default so I don't think there's a way today | 17:23 |
| skomorokh | If it autoconnects to the interface that lets it connect to the internet, it alerts them that my IP uses it. | 17:23 |
| skomorokh | Whereas if I can snap install vscode --without-interface=internet | 17:24 |
| zyga | skomorokh: I'm not saying no, just that it's not a feature today | 17:24 |
| zyga | you can open a forum thread about it | 17:24 |
| skomorokh | The main reason my IDE would ever need to use the internet is updating, and if snap does that for me, tada! | 17:24 |
| popey | well, no | 17:24 |
| zyga | we can discuss it with the security team and with designers | 17:24 |
| popey | most modern IDEs have plugins | 17:24 |
| popey | vscode included | 17:24 |
| zyga | yeah | 17:24 |
| skomorokh | Yah, I know, vscode especially, actually. | 17:24 |
| zyga | sadly modern IDEs are pretty much mini-OSes (without confinement between plugins) | 17:24 |
| popey | vscode will go and get (for example) golang components when you're editing .go files | 17:24 |
| skomorokh | That's why this is a hypothetical. | 17:25 |
| skomorokh | But it's the one that came to mind. | 17:25 |
| zyga | I'm very much waiting for the first real attempt at a code editor with untrusted plugins | 17:25 |
| zyga | with proper sandboxing | 17:25 |
| popey | vscode oss is built without those features | 17:25 |
| zyga | it's a ticking time bomb | 17:25 |
| popey | so you could use that instead | 17:25 |
| skomorokh | However, if I was cool with just using the ones it came with, I'd like to be able to --without-internet it. | 17:25 |
| zyga | skomorokh: you can install it | 17:25 |
| zyga | skomorokh: disconnect network | 17:25 |
| zyga | and then run it | 17:25 |
| popey | unplug the network cable and snap diconnect network | 17:25 |
| zyga | note that if it had a confiugre hook or other install hook it would execute by that time | 17:26 |
| zyga | *configure | 17:26 |
| skomorokh | Ya, that's not making this super convenient though. | 17:26 |
| zyga | you can also make a network namespace | 17:26 |
| zyga | and run vscode there | 17:26 |
| zyga | I think it's a better solution for networking specifically as you have full control | 17:26 |
| skomorokh | Yeah, I'm interested in transparency as to what my applications do on the internet. | 17:27 |
| skomorokh | If snap is partitioning them somehow that I can differentiate which apps are generating which traffic that'd be neat. | 17:27 |
| skomorokh | Like an alias interface per snap so I can wireshark vscode alone? | 17:27 |
| zyga | snapd doesn't use the network namespace so networking is "real" | 17:28 |
| skomorokh | Aw. Well, one thing at a time. Is that an eventual goal? | 17:29 |
| zyga | no, that's not a goal now | 17:29 |
| zyga | maybe eventually but we have plenty of things to do for now | 17:30 |
| kyrofa | skomorokh, you want this: | 17:30 |
| kyrofa | https://forum.snapcraft.io/t/autoconnection-override/2465 | 17:30 |
| kyrofa | zyga, install and then disconnect doesn't cut it-- daemons are fired up first | 17:30 |
| zyga | yes, I agree | 17:30 |
| zyga | we have the way to represent that now | 17:30 |
| zyga | so it's just a matter of designing and making the UI | 17:31 |
| zyga | "UI" | 17:31 |
| skomorokh | (Just checking, that's overriding that you can represent just have no UI ...not per-snap network usage?) | 17:34 |
| zyga | skomorokh: not specific to network | 17:36 |
| zyga | skomorokh: you can put some stuff into the "state" /var/lib/snapd/state.json that will tell snapd not to auto-connect a given interface to a given snap | 17:36 |
| zyga | state is interesting too | 17:37 |
| skomorokh | Does snap use cgroups? | 17:37 |
| zyga | skomorokh: yes | 17:37 |
| skomorokh | So potentially that could give some visibility into which snap is associated with which network traffic? | 17:38 |
| zyga | skomorokh: we use seccomp bpf, apparmor (all of it+more than mainline), device and freezer cgroup | 17:38 |
| zyga | skomorokh: we only use the two cgroups I mentioned | 17:38 |
| skomorokh | Ohhh. | 17:38 |
| skomorokh | So not per-snap cgroup. | 17:38 |
| zyga | we have per-snap cgroups | 17:38 |
| zyga | but we only use device and freezer cgroups | 17:38 |
| zyga | and I don't believe you can do what you want with just them | 17:39 |
| zyga | we also use some other things but those are the "main" guys | 17:39 |
| zyga | all of the sandbox code is in interfaces/ directory in the tree | 17:39 |
| zyga | we use mount namespaces heavily | 17:39 |
| zyga | man, I didn't mention that | 17:39 |
| zyga | that's like my life now and I didn't mention that | 17:39 |
| pedronis | mvo: fyi, all my backport branches are green now, but we would need to start with 5002 once we feel ok about 2.32.3 | 17:41 |
| zyga | pedronis: mvo is offline | 17:41 |
| pedronis | I always forget there are people that do that :) | 17:42 |
| zyga | yeah | 17:42 |
| zyga | irc cloud is really great | 17:42 |
| skomorokh | Hm, but if all the processes for a snap are in its per-snap group ...it seems like that's all we need is already in net_filter? https://lwn.net/Articles/569678/ | 17:44 |
| skomorokh | Except it's confusing when you say you have per-snap cgroups but don't use them: | 17:45 |
| skomorokh | <zyga> we have per-snap cgroups | 17:45 |
| skomorokh | <zyga> but we only use device and freezer cgroups | 17:45 |
| zyga | sorry, I meant to say that we only use two cgroup _types_ | 17:46 |
| zyga | if xtables can do that that's cool, I wasn't aware of that | 17:46 |
| zyga | brb, dog.walk() | 17:47 |
| JonelethIrenicus | any steam snaps | 17:47 |
| popey | JonelethIrenicus: there isn't a steam snap from valve in the store currently. | 17:48 |
| skomorokh | lemme guess, --classic? | 17:49 |
| zyga | There is a steam runtime snap from ikey | 17:50 |
| zyga | WIP but promising and confined | 17:50 |
| skomorokh | Niiiice! | 17:50 |
| skomorokh | Is the sandboxing relatively new? | 17:51 |
| zyga | There is a interface review for steam specifically | 17:51 |
| zyga | Depends on which part | 17:51 |
| zyga | Some is old, some is still not in mainline | 17:51 |
| zyga | Man, this feels like summer | 17:53 |
| zyga | So warm outside | 17:53 |
| zyga | There was snow all around just a moment ago | 17:54 |
| kyrofa | I miss snow | 17:55 |
| kyrofa | Spring is the worst | 17:55 |
| zyga | The design of the sandbox is new IMO, | 17:55 |
| zyga | Whaaaat kyrofa how can you say that | 17:56 |
| skomorokh | Ok, so there's hope yet that slack, etc. will provide contained snaps? It's most they haven't got to it and things weren't ready when they first adopted the platform rather than they're refusing to go that way? | 17:56 |
| popey | It depends on the ISV | 17:57 |
| popey | We're talking to all of them. Some are motivated to get them confined, others are not. | 17:57 |
| zyga | I think it depends on the cost for them. If they see the sandbox as a cost for the people that support Linux | 17:57 |
| zyga | It’s all about users | 17:57 |
| popey | Worth noting that for some of the really big ISVs Linux represents a vanishingly tiny proportion of their userbase. | 17:57 |
| zyga | Confinement has some advantages | 17:58 |
| popey | So you get a tiny proportion of their time to work on it. | 17:58 |
| zyga | Snaps that are confined run in more places | 17:58 |
| zyga | So I think over time classic snaps will be rare | 17:58 |
| skomorokh | Well, I'm thinking specifically of slack/vscode so fairly developery things where presumably linux has a larger-than-usual marketshare. | 17:58 |
| zyga | Again, begging of the adoption curve, early adopters, etc | 17:58 |
| popey | Depends on your definition of large. | 17:58 |
| zyga | Yeah | 17:59 |
| zyga | It’s all subjective | 17:59 |
| zyga | Linux is not large IMO (and I use it since forever) | 17:59 |
| skomorokh | Well, I'd imagine that linux use is an order of magnitude more common in the developer community than the world at large. | 17:59 |
| popey | slack-term is in the store and is strictly confined btw ;) | 17:59 |
| popey | https://snapcraft.io/slack-term | 17:59 |
| katamo | [help please] building my first snap. need to read the output of a `cat` command. getting an error "Error: Can't read from stdin: read /dev/stdin: permission denied" from the cat command. snap was built and installed locally using the "--devmode --dangerous" flags | 18:00 |
| zyga | Slack is used by lots of people, not just developers | 18:00 |
| katamo | *everything works before being snapped | 18:00 |
| popey | katamo: hi, can you point us to your yaml somewhere online? | 18:00 |
| skomorokh | Is there a way I can browse snaps like the store but with added info about which are confined and which interfaces they require? | 18:00 |
| zyga | katamo: when you use —dangerous you disable enforcing confinement | 18:00 |
| popey | zyga: uh, you mean devmode? | 18:01 |
| zyga | skomorokh: gnome software, eventually | 18:01 |
| zyga | Yes popey | 18:01 |
| zyga | It implies devmode afair | 18:01 |
| katamo | skomorokh https://gitlab.com/kat.morgan/ScoutPlane/blob/master/snapcraft.yaml | 18:01 |
| skomorokh | zyga: but why would I need an app for browsing a catalogue, seems like a very web-suitable task? | 18:01 |
| katamo | *oops popey | 18:02 |
| popey | skomorokh: you can browse the store at snapcraft.io/store | 18:02 |
| zyga | skomorokh: store front can probably show this too | 18:02 |
| popey | skomorokh: not all features of the snap are shown currently, the web site is under constant redesign | 18:02 |
| katamo | popey to be specific, line 170 of build-img is failing with the stdin permission error https://gitlab.com/kat.morgan/ScoutPlane/blob/master/bin/build-img | 18:04 |
| katamo | popey snapcraft.yaml is here: https://gitlab.com/kat.morgan/ScoutPlane/blob/master/snapcraft.yaml | 18:04 |
| skomorokh | Ya, I don't see either of those pieces of info on the store and would hope to. | 18:04 |
| popey | skomorokh: yeah, it's not straightforward to expose at the moment | 18:05 |
| popey | katamo: lxc config is going to want to poke things in hidden in folders in your home directory, isn't it? That will be blocked by confinement? | 18:06 |
| skomorokh | Is there a tool to replicate my snap installs on another machine? | 18:06 |
| katamo | popey, hmmmm, good thing to consider. "--devmode --dangerous" would eliminate that for the sake of argument, right? | 18:07 |
| skomorokh | Since it's not just a flat list of snaps but also connections... | 18:07 |
| popey | skomorokh: not currently. | 18:07 |
| katamo | so far, i've been able to do everything with lxd from the snap except that one line | 18:07 |
| popey | katamo: hm, I don't know what's going on there then. | 18:07 |
| katamo | :/ grr, time for more digging. alrighty | 18:07 |
| popey | maybe try the forum for long form Q&A? | 18:08 |
| zyga | skomorokh: no, not at present | 18:09 |
| skomorokh | popey: Okay, I should get back to work anyhow. | 18:09 |
| popey | That's entirely scriptable though. "snap list" and "snap interfaces" on one end and "snap install" and "snap connect / disconnect" on the other | 18:09 |
| skomorokh | Thanks a lot for all the welcoming / super patient replies! And ya, epic software endeavour. | 18:09 |
| popey | Thanks for the friendly chat :) | 18:10 |
| zyga | skomorokh: good day and drop by again :) | 18:10 |
| zyga | pedronis: can you please do a 2nd review on https://github.com/snapcore/snapd/pull/5026 | 18:11 |
| mup | PR #5026: tests: add check for OOM error after each test <Created by mvo5> <https://github.com/snapcore/snapd/pull/5026> | 18:11 |
| skomorokh | ooo, actually, before I disappear | 18:12 |
| skomorokh | I sync my home dir between three machines using unison | 18:13 |
| skomorokh | That shouldn't be any more crazy with snaps, I think, because their local files are in ~/snap/snapname ...no generated uuids or anything | 18:13 |
| zyga | yeah | 18:14 |
| zyga | you may see some odd issues though | 18:14 |
| popey | might be a challenge if the machine apps get out of sync | 18:14 |
| zyga | when on machine-a you have snap foo at revision 1 | 18:14 |
| skomorokh | Does anything leap out at you as likely to blow up? | 18:14 |
| zyga | but on machine-b it will refresh and get to revision 2 | 18:14 |
| skomorokh | Ya, I carefully manage my updates to keep them in sync | 18:14 |
| zyga | skomorokh: snaps update automatically | 18:14 |
| skomorokh | ... | 18:14 |
| skomorokh | Can they not? | 18:14 |
| zyga | skomorokh: and you can use "snap revert" to go back to revision you had before | 18:15 |
| zyga | skomorokh: you can control when they refresh (very precisely) | 18:15 |
| zyga | but we don't want to add a global toggle because the vendors do the silly thing and turn that off and ship devices with no updates, ever | 18:15 |
| zyga | and we don't want that | 18:15 |
| skomorokh | So I can leave refresh at "never" and set it to "now" when I want updates? | 18:16 |
| zyga | no | 18:16 |
| skomorokh | It's my computer though :) | 18:16 |
| zyga | so we are very opinionated and try very hard to give lots of control without a way to for someone to turn it off forever | 18:16 |
| zyga | because then people are the victim of a vendor who does that | 18:16 |
| zyga | and most people are really comfortable with that already | 18:16 |
| zyga | (not all clearly) | 18:16 |
| zyga | it has to be refreshed at least once a month AFAIR | 18:16 |
| skomorokh | I'm uncomfortable with how many people are comfortable with that :) | 18:17 |
| zyga | you can also deploy an enterprise proxy and tie your specific device to that proxy | 18:17 |
| zyga | and control updates through the proxy | 18:17 |
| skomorokh | Well, I'm not interested in me. | 18:17 |
| popey | I'm uncomfortable with how many people run easily compromised out of date software on the internet | 18:17 |
| zyga | skomorokh: it's a tricky balance, if we give the off switch you will read an article about ubuntu routers being insecure and out of date when next major thing happens | 18:17 |
| zyga | because someone in china slaps ubuntu on a batch of no-brand machines and ships them for 15$ | 18:18 |
| skomorokh | True points. | 18:18 |
| zyga | skomorokh: so on your private deployment, you can and should use the enterprise proxy | 18:18 |
| zyga | skomorokh: if you have a super important snap that cannot break you can buy gating and control when core refreshes so that you are not broken by canonical shipping updated base libraries | 18:19 |
| zyga | skomorokh: you can schedule updates to go weekly on Tuesday night | 18:19 |
| zyga | but you cannot turn it off because then you would be fine but 1000s of others would suffer | 18:19 |
| skomorokh | I just don't like the general notion that end users are so fully conditioned that software is something managed externally. | 18:19 |
| skomorokh | That either you are full-time devops and that's your life or you let your most sensitive affairs be managed by one of a small handful of vendors. | 18:20 |
| skomorokh | It feels like there is room for a level of autonomy between OS X and Gentoo :) | 18:21 |
| skomorokh | At any rate, for my actual use case it sounds fine because I assume I can trigger a refresh on demand? And thus update my laptop to current before I sync things over. | 18:23 |
| popey | you can "snap refresh" any time | 18:34 |
| petan | some idea? https://pastebin.com/MWSkCdde this crash I get when I run snapcraft :( | 18:34 |
| mup | PR snapd#5023 closed: spread.yaml: try to switch to run tests on gcloud (2.32) <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/5023> | 18:44 |
| mup | PR snapcraft#2060 closed: package: ensure all relevant files are in for sdist <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2060> | 19:08 |
| mvo | cachio: yay, thank you | 19:09 |
| zyga | hey mvo | 19:10 |
| zyga | still trying to release | 19:10 |
| cachio | mvo, yaw | 19:10 |
| mvo | zyga: we released | 19:11 |
| mvo | zyga: its all great! | 19:11 |
| zyga | wooooot | 19:11 |
| zyga | thank /dev/urandom | 19:11 |
| zyga | that's great | 19:11 |
| zyga | thank you for getting us here | 19:11 |
| zyga | mvo: do you have 3 more minutes? | 19:12 |
| mvo | zyga: yeah, not 100% | 19:12 |
| zyga | https://github.com/snapcore/snapd/pull/4957 | 19:13 |
| mup | PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957> | 19:13 |
| zyga | do you want to do a 3rd review | 19:13 |
| zyga | it's small | 19:13 |
| mvo | zyga: I have a look in a little bit | 19:13 |
| zyga | mvo: can I help with anything release-wise? | 19:14 |
| mvo | zyga: I think its all good, I will do the SRU in my morning and we need to keep an eye on bugs | 19:15 |
| zyga | ok | 19:15 |
| zyga | that's .4 that you will SRU | 19:16 |
| zyga | or still .3 | 19:16 |
| mvo | zyga: I hope I will be be able to announce it again later tonight but that is about it | 19:16 |
| mvo | zyga: probably .4 | 19:16 |
| mvo | zyga: I want to have at least the fix for the oom detection | 19:16 |
| zyga | .3 is very solid but .4 has a few more fixes and the all new API | 19:16 |
| mvo | well "fix" | 19:16 |
| zyga | I'm somewhat worried about the new store api there | 19:16 |
| mvo | zyga: yeah, then .3+X | 19:16 |
| zyga | but I realise it's important | 19:16 |
| zyga | mvo: oom "fix" will surely show up in adt | 19:16 |
| zyga | so "yay" for working on this bug | 19:17 |
| zyga | it was under my radar, I was surprised by how old that thread was | 19:17 |
| mvo | zyga: "yay" - really a frustrating day, oom bug, threading explosion and refresh-mode: sigterm not working. oh well, tomorrow will be better | 19:17 |
| zyga | is the SIGTERM refresh issue real? | 19:17 |
| zyga | that is, it's not an application level bug? | 19:18 |
| mvo | zyga: it may be applicatoin dependent | 19:18 |
| mvo | zyga: its strange, the strace indidate its real | 19:18 |
| zyga | hrm | 19:19 |
| zyga | let me know if you want me to look tomorrow | 19:19 |
| zyga | it would be a .5 | 19:20 |
| zyga | and 2.33 would be more off if true | 19:20 |
| zyga | but it may mean 2.32 is our first LTS :) | 19:20 |
| zyga | and I would welcome that | 19:20 |
| pedronis | well, if .4 is just oom, we need .5 soon (that would have been .4) | 19:21 |
| pedronis | and then later is .6 | 19:21 |
| zyga | 2.32.19 is the charm | 19:21 |
| zyga | it will also include the YAMA fix ;-) | 19:21 |
| pedronis | mvo: so what was suppored to be .4 will be .5 ? | 19:22 |
| pedronis | will .4 be SRU only? | 19:22 |
| pedronis | I mean no core build? | 19:22 |
| diddledan | ooh. I just spotted that 2.32.3 landed stable | 19:23 |
| diddledan | :-) | 19:23 |
| mvo | pedronis: I think we will do .4 | 19:24 |
| mvo | pedronis: and for the sru I do .3.1 or something | 19:24 |
| mvo | pedronis: or .3ubuntu1 | 19:24 |
| pedronis | ok | 19:24 |
| mvo | pedronis: just the OOM thing | 19:24 |
| pedronis | mostly because I communicated that API would be in .4 | 19:25 |
| pedronis | I can communicate again if needed | 19:25 |
| mvo | pedronis: yeah, I'm still onboard with that | 19:25 |
| mvo | pedronis: I think its fine | 19:25 |
| pedronis | mvo: all the backports are green | 19:26 |
| pedronis | (still marked as blocked tough) | 19:26 |
| zyga | mvo: once .4 is out I will massage a release page | 19:28 |
| zyga | and do suse updates | 19:28 |
| popey | ooh! 2.32 is out? | 19:28 |
| zyga | popey: _again_ :D | 19:29 |
| popey | lulz | 19:29 |
| zyga | popey: snapd is so cool we can release the same version twice | 19:29 |
| popey | Thanks guys! | 19:29 |
| zyga | take that classic packages! | 19:29 |
| popey | only twice? | 19:29 |
| zyga | popey: you only release twice | 19:30 |
| mvo | pedronis: \o/ | 19:33 |
| mvo | pedronis: great that they are green | 19:33 |
| pedronis | mvo: I closed the PR about usign google for 2.32 | 19:33 |
| mvo | pedronis: ok | 19:52 |
| mvo | zyga: heh, the PR is small but the amount of discussion is not ;) I check it in my morning | 20:29 |
| diddledan | is there any way you know of to prevent the /tmp/$temporary_name files from being deleted when something goes wrong? I'm receiving the message I'm about to paste, but running with --debug doesn't reveal anything further, and the files are gone when I try to investigate what's wrong | 21:02 |
| diddledan | https://www.irccloud.com/pastebin/gZMbloyw/ | 21:02 |
| sergiusens | diddledan: mind trying out `edge`? | 21:04 |
| diddledan | ok, gimme a sec | 21:05 |
| diddledan | running.... | 21:05 |
| petan | is there any way to start a script that alters the source code (like patch) before the snap start building it? | 21:06 |
| diddledan | you'd love this snapcraft.yaml, sergiusens, it's now sitting at 1340 lines long :-p | 21:06 |
| petan | now it changes the source somewhere, but seems to build it elsewhere and the patch is not applied :/ | 21:06 |
| nacc | petan: https://docs.snapcraft.io/build-snaps/scriptlets | 21:06 |
| diddledan | petan: the scriptlet you want is `prepare` | 21:07 |
| nacc | petan: prepare ? | 21:07 |
| sergiusens | petan: `prepare` if on stable or https://forum.snapcraft.io/t/proposal-expanding-scriptlets/4673 if on edge | 21:07 |
| petan | nacc: I did try prepare, but as I said, the script is executed but source code which is actually built by snapcraft is not touched by it | 21:07 |
| petan | seems like prepare is touching some different copy of source code | 21:07 |
| diddledan | cmake? | 21:07 |
| petan | if that's question for me, yes the project is using cmake | 21:08 |
| nacc | petan: that seems like it would depend on the plugin (and whether it builds in place, or makes copies, etc) | 21:08 |
| diddledan | bingo! | 21:08 |
| sergiusens | diddledan: I am waiting for you to snap up the new gnucash! | 21:08 |
| petan | how is it related to cmake | 21:08 |
| diddledan | yeah cmake references the source in `src` while the build executes in `build` so you need to adjust your prepare to reference `../src` | 21:08 |
| sergiusens | cmake does out of source builds, unfortunately we carry a bad legacy on that one | 21:09 |
| petan | oh | 21:09 |
| petan | will try | 21:09 |
| sergiusens | I need to leave for now, feel free to create forum posts I can follow up on those later | 21:09 |
| sergiusens | cheers | 21:09 |
| petan | cmake is very popular thingie it should be supported properly | 21:11 |
| nacc | petan: it seems like it is? | 21:17 |
| nacc | petan: cmake just does a build copy | 21:17 |
| kyrofa | petan, the typical way to use cmake is out-of-source. That's what snapcraft does | 21:30 |
| kyrofa | You're not supposed to be messing with source code in prepare | 21:30 |
| kyrofa | That's part of the build step | 21:30 |
| kyrofa | The fact that it works on some plugins and not others is because it's not how you're supposed to use prepare :P | 21:31 |
| petan | but I want to "prepare" the source code for building | 21:31 |
| petan | so what should I use instead of prepare to prepare source? | 21:31 |
| kyrofa | petan, then you need to use edge and use override-pull instead | 21:31 |
| petan | what | 21:31 |
| petan | what is edge and what is override-pull and who says I am pulling anything? | 21:31 |
| kyrofa | petan, https://forum.snapcraft.io/t/scriptlets/4892 | 21:32 |
| kyrofa | petan, where are you getting the snapcraft you're using? | 21:32 |
| petan | I made it myself huh | 21:32 |
| kyrofa | So... a venv? | 21:32 |
| petan | anyway, that forum page is lacking simple example | 21:33 |
| petan | I don't want to "override" something, which is only example there... | 21:33 |
| petan | anywa | 21:33 |
| petan | it works now with prepare | 21:33 |
| kyrofa | petan, overriding the pull step is exactly what you want to do there | 21:33 |
| petan | maybe not "correct way" but it works | 21:33 |
| kyrofa | The example is even patching | 21:33 |
| petan | hmm | 21:33 |
| kyrofa | But yeah, if you're happy with prepare, go for it. Just know that it's not the proper and supported way to patch code. There wasn't a proper and supported way to do that until override-pull | 21:34 |
| kyrofa | (other than implementing a local plugin) | 21:35 |
| mup | PR snapcraft#2063 opened: many: add snapcraftctl set-version <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2063> | 21:45 |
| Caelum | zyga: something just broke snaps on TW, I'll look into it later today | 22:29 |
| mup | PR snapd#5027 opened: client: snapshot sets, snapshots, snapshot actions, oh my! <Created by chipaca> <https://github.com/snapcore/snapd/pull/5027> | 23:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!