| Caelum | zyga: looks like we'll need to update the opensuse package again, stopped working | 02:34 |
|---|---|---|
| Caelum | zyga: "cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied" | 02:35 |
| mborzecki | morning | 05:04 |
| mup | PR snapd#5691 closed: spdx: allow Other-Open-Source <Simple> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5691> | 05:49 |
| mup | PR snapd#5728 opened: spdx: remove "Other Open Source" from the support licenses <Created by mvo5> <https://github.com/snapcore/snapd/pull/5728> | 05:50 |
| mvo | zyga: hey, what do you think, when can we remove the experimental flag from layouts? | 05:55 |
| mup | PR snapd#5729 opened: many: rename ClientOpts to ClientOptions <Created by mvo5> <https://github.com/snapcore/snapd/pull/5729> | 06:00 |
| mborzecki | mvo: hi, is /etc/hostname not writable in core 18 devices? https://github.com/snapcore/snapd/pull/5722 hostnamectl appears to be failing with 'read only filesystem' | 06:06 |
| mup | PR #5722: tests: test for the hostname interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5722> | 06:06 |
| mborzecki | mvo: iirc layouts still have that problem with trespassing to the host's filesystem | 06:07 |
| mvo | mborzecki: hm, etc/hostname should be a symlink on core18 to etc/writable/hostname, let me double check that | 06:09 |
| mvo | mborzecki: yeah, its a symlink | 06:11 |
| mvo | mborzecki: so maybe thats the problem? that the apparmor policy does not have the symlink? | 06:12 |
| mvo | (target) | 06:12 |
| mborzecki | mvo: hmm, but it failed with 'read only fs', i'd guess EROFS appeared somewhere there, with apparmort that'd be more like permission denied | 06:13 |
| mborzecki | mvo: wonder if hostnamectl truncates /etc/hostname or writes a new file and does a rename | 06:13 |
| zyga | Good morning | 06:15 |
| mborzecki | zyga: hey | 06:16 |
| zyga | I’ll start soon | 06:17 |
| mvo | mborzecki: oh that rings a bell | 06:17 |
| zyga | Kids had blood test today | 06:17 |
| mvo | mborzecki: let me quickly check | 06:17 |
| zyga | And needed my “moral support” | 06:17 |
| mvo | pedronis: is 5699 something you want to review ? or do you think its fine? | 06:17 |
| mvo | mborzecki: this sounds a lot like https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936 | 06:18 |
| zyga | mvo: after trespassing bug is fixed | 06:18 |
| mvo | zyga: aha, ok | 06:18 |
| zyga | Then they are ready | 06:18 |
| mup | Bug #1778936: please re-add Support-system-image-read-only-etc.patch <patch> <systemd (Ubuntu):New> <systemd (Ubuntu Bionic):New> <systemd (Ubuntu Cosmic):New> <https://launchpad.net/bugs/1778936> | 06:18 |
| mborzecki | mup: heh, yes | 06:19 |
| mup | mborzecki: I apologize, but I'm pretty strict about only responding to known commands. | 06:19 |
| mborzecki | mvo: heh, yes :) | 06:19 |
| zyga | I’ll work with Maciej on this as it was harder to come up with precise logic than I wished last time | 06:19 |
| mvo | mborzecki: I get the feeling I will have to do this SRU myself :/ | 06:21 |
| mvo | mborzecki: anyway | 06:21 |
| mvo | mborzecki: I will put it on my list | 06:21 |
| mup | PR snapd#5730 opened: devicestate: support getting (http) proxy from core config <Created by mvo5> <https://github.com/snapcore/snapd/pull/5730> | 06:22 |
| mup | PR snapd#5704 closed: snap: add new type "TypeSnapd" and attach to the snapd snap <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5704> | 06:23 |
| mup | PR snapd#5728 closed: spdx: remove "Other Open Source" from the support licenses <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5728> | 06:24 |
| mvo | mborzecki: want to have a quick look at 5719 again? I had to change it slightly after gustavos review but should be fine (all tests still happy and errors better) | 06:25 |
| mborzecki | mvo: already +1'ed it | 06:25 |
| mborzecki | oh, w8, that's the other one :) | 06:25 |
| mup | PR snapd#5710 closed: cmd: support re-exec into the "snapd" snap <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5710> | 06:32 |
| mup | PR snapd#5709 closed: configcore,snapstate: add new core.experimental.snapd-snap option <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5709> | 06:41 |
| mup | PR core#93 closed: hooks: unwind /etc/alternatives <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/93> | 06:44 |
| zyga | Back | 06:44 |
| zyga | mvo: re | 06:58 |
| zyga | mvo: I have that dragon on my desk if you need any support | 06:58 |
| zyga | mvo: it's not powered on but I can bring all the misc bits and set it up if you need me to | 06:58 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 07:16 |
| mborzecki | pstolowski: hey | 07:20 |
| Caelum | zyga: hi, opensuse package is broken again, something to do with apparmor, would an update fix it? If so I'll send you a PR. | 07:21 |
| zyga | Caelum: yes, I have the build ready, just need to pull the trigger | 07:21 |
| zyga | Caelum: can you review & test? | 07:21 |
| Caelum | zyga: yeah totally | 07:21 |
| zyga | ok | 07:22 |
| zyga | hold on, let me commit | 07:22 |
| mvo | zyga: I just send an update to the etc/alternatives stuff in snapcore/core18. not urgent but you may be interessted | 07:22 |
| mup | PR core18#64 opened: hooks: improve /etc/alternatives unwinding <Created by mvo5> <https://github.com/snapcore/core18/pull/64> | 07:22 |
| zyga | ack | 07:22 |
| Caelum | zyga: also at some point I want to talk about reviving the gentoo overlay | 07:23 |
| zyga | sure | 07:24 |
| zyga | I have nothing for that so please go ahead | 07:24 |
| mup | PR core#94 opened: hooks: improve /etc/alternatives unwinding <Created by mvo5> <https://github.com/snapcore/core/pull/94> | 07:25 |
| zyga | btrfs rebalance ... | 07:26 |
| zyga | ha | 07:33 |
| zyga | mvo: I found a bug in our systemd unit | 07:33 |
| zyga | system key refresh takes long eough | 07:33 |
| zyga | long enough | 07:33 |
| zyga | that systemd restarts us | 07:33 |
| zyga | we need to poke systemd using sd-notify during the security setup as it can take a lot of time | 07:34 |
| zyga | I guess this will continue while balancing is in progress as the system is much slower than usual | 07:36 |
| Caelum | it's good to cron that shit | 07:44 |
| Caelum | mine is @daily | 07:44 |
| Caelum | zyga: well highlight me if you want me to do anything | 07:44 |
| zyga | Caelum: sure, I'll send my build as soon as btrfs stops my system from crawling | 07:45 |
| zyga | Caelum: I want to branch it so that it can be reviewed | 07:45 |
| Caelum | awesome | 07:46 |
| zyga | ok I/O aside I managed to branch it | 07:56 |
| mborzecki | mvo: left you a coment in https://github.com/snapcore/snapd/pull/5729 btw. the title says it's only messing with ClientOptions, but it's adding proxy too | 08:02 |
| mup | PR #5729: many: rename ClientOpts to ClientOptions <Created by mvo5> <https://github.com/snapcore/snapd/pull/5729> | 08:03 |
| zyga | https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd | 08:03 |
| niemeyer | Good mornings! | 08:06 |
| Chipaca | moin moin | 08:12 |
| zyga | hey guys | 08:12 |
| zyga | good morning | 08:12 |
| zyga | :) | 08:12 |
| pstolowski | o/ | 08:12 |
| zyga | summer is supposedly back this week (just not yet) | 08:12 |
| Chipaca | mvo: did you see the last failure on #5722? is /etc/hostname writable on core 18? | 08:17 |
| mup | PR #5722: tests: test for the hostname interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5722> | 08:18 |
| mvo | Chipaca: I did not, but i suspect its https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936 | 08:26 |
| mup | Bug #1778936: please re-add Support-system-image-read-only-etc.patch <patch> <systemd (Ubuntu):New> <systemd (Ubuntu Bionic):New> <systemd (Ubuntu Cosmic):New> <https://launchpad.net/bugs/1778936> | 08:26 |
| Chipaca | mvo: ah | 08:26 |
| mvo | zyga: nice catch | 08:26 |
| mvo | mborzecki: 5729 is build on top of the other one, I hope I added it to the description | 08:27 |
| mvo | mborzecki: I think I could split them maybe thats clearer | 08:27 |
| mborzecki | mvo: it's ok with me | 08:27 |
| mvo | mborzecki: otoh the proxy one can land, I was just waiting to double check with pedronis if he wants to have a look at the proxy thing because it does some potentially dangerous state interactions (it needs to lock state to get the proxy) | 08:28 |
| mvo | mborzecki: ok | 08:28 |
| mvo | Chipaca: and WELCOME BACK | 08:28 |
| Chipaca | mvo: :-) | 08:29 |
| Chipaca | mvo: looking forward to all the review feedback that'll be waiting for me | 08:29 |
| Chipaca | zyga: were you able to get your lab back up? I could use a darwin shell about now | 08:32 |
| zyga | Chipaca: almost, I can set you up in 10 min | 08:32 |
| Chipaca | zyga: no rush; just let me know | 08:32 |
| zyga | almost done | 08:35 |
| pedronis | mvo: hi | 08:36 |
| mvo | pedronis: good morning! just wanted to double check if 5699 is something you want to have a look at :) | 08:37 |
| pedronis | mvo: I'm a bit worried that we are not super consistent about releasing the lock when doing store things | 08:38 |
| mvo | pedronis: just to clarify you don't have to, but it might be interessting because of the proxy helper and state lock interplay | 08:38 |
| pedronis | we do for some main things | 08:38 |
| mvo | pedronis: yeah, this PR would enforce that we are | 08:38 |
| pedronis | mvo: enforce ? | 08:38 |
| mvo | pedronis: well, it will crash or hang if we don't | 08:38 |
| pedronis | wouldn't call that enforce | 08:38 |
| zyga | Chipaca: check check? | 08:39 |
| mvo | pedronis: ok, bad wording then :/ I mean we will need it | 08:39 |
| Chipaca | zyga: check what? | 08:40 |
| Chipaca | ah | 08:40 |
| zyga | Chipaca: did you see my private msg? | 08:40 |
| pedronis | mvo: yea, re-double checking | 08:40 |
| Chipaca | zyga: now yes | 08:40 |
| zyga | Chipaca: there's golang and gcc | 08:41 |
| zyga | Chipaca: there should be git and other things but let me know if you need more | 08:41 |
| zyga | Chipaca: you are on bare metal | 08:41 |
| Chipaca | zyga: woo, thanks | 08:42 |
| Chipaca | mbuahaha | 08:42 |
| zyga | enjoy :) | 08:42 |
| === chihchun is now known as chihchun_afk | ||
| pedronis | mvo: so rechecking most of the relevant packages have tests with a fakeStore that uses a pokeStateLock helper to check for that, daemon doesn't do that though because usually it doesn't hold the lock for long and also there's no clear state in many tests, but bit delicate, maybe you want to look there what we can do | 08:53 |
| mvo | pedronis: so it sounds like I should add tests in daemon that poleStateLock? | 08:56 |
| pedronis | mvo: add pokeStateLock in daemon test fake store bits, yes, it seems by definition there is always a state if we use those, because we had to use ReplaceStore anyway | 08:57 |
| mvo | pedronis: great, I will do that, thank you | 08:59 |
| * zyga wonders what the error is in https://build.opensuse.org/build/home:zyga:branches:system:snappy/openSUSE_Tumbleweed/i586/snapd/_log | 09:12 | |
| zyga | log files from suse are horrible :/ | 09:13 |
| mborzecki | hm i guess locking the state for the whole duration of doMountSnap() is a bad idea? | 09:13 |
| Chipaca | zyga: can you install squashfs-tools? | 09:13 |
| zyga | Chipaca: not sure, let me try | 09:13 |
| Chipaca | zyga: (assuming you're using something like brew) | 09:14 |
| zyga | no, I try to stay clear of brew | 09:14 |
| Chipaca | (or whatever the package mangler on osx is) | 09:14 |
| Chipaca | zyga: I'll run it from git (or try to!) | 09:15 |
| zyga | Chipaca: it doesn't build, hold on | 09:15 |
| zyga | mksquashfs.c:4404:29: error: use of undeclared identifier 'FNM_EXTMATCH' | 09:15 |
| zyga | FNM_PATHNAME|FNM_PERIOD|FNM_EXTMATCH) == 0; | 09:15 |
| zyga | I have a firm deja-vu now | 09:16 |
| zyga | Chipaca: if you can find me a copy that builds :) | 09:16 |
| zyga | Chipaca: I suspect someone patched the glibc-specific flag | 09:16 |
| zyga | I remember now, I was building this on my MacBook | 09:17 |
| zyga | (remember, the one I had in Netherlands) | 09:17 |
| zyga | and I had to patch some things for it to build | 09:18 |
| === chihchun_afk is now known as chihchun | ||
| Chipaca | zyga: looks like there's a nixos patch for darwin | 09:18 |
| zyga | Chipaca: do you have a link or a tree ? | 09:20 |
| zyga | ideally something we would later on incorporate into our build | 09:20 |
| Chipaca | zyga: could you sudo chmod u+s /usr/bin/dtrace | 09:36 |
| zyga | dtrace? :) | 09:37 |
| zyga | sure, what do you need it for | 09:37 |
| Chipaca | zyga: this is the patch: https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/filesystems/squashfs/darwin.patch | 09:37 |
| Chipaca | zyga: 'snap pack' failing with 'exit error 1', wondering what all is failing | 09:37 |
| Chipaca | shortest path to answer that is to trace it :-) | 09:37 |
| Chipaca | then i need to improve the error output | 09:37 |
| Chipaca | then, fix it | 09:37 |
| zyga | Chipaca: are you set now? | 09:44 |
| Chipaca | zyga: it works | 09:45 |
| zyga | ok, good luck | 09:45 |
| zyga | I should reboot the ssh host as it runs an older kernel | 09:45 |
| zyga | so let me know when would be a good time for that | 09:45 |
| zyga | Caelum: hey | 09:47 |
| zyga | I pushed https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd | 09:47 |
| zyga | can you please have a look at that | 09:47 |
| zyga | I cannot understand why the i386 build fails | 09:47 |
| zyga | (the error log is just ... not saying anything) | 09:47 |
| zyga | in any case, that is the latest and greatest | 09:47 |
| zyga | so any feedback you can get on that is appreciated | 09:48 |
| zyga | Caelum: you need to build the package locally as I didn't publish the build | 09:49 |
| zyga | I'll grab a coffee and be back soon | 09:49 |
| Caelum | zyga: looking now | 09:51 |
| Caelum | zyga: one reason the build can fail I told you about a couple months ago, there is one time-sensitive test running in parallel | 09:52 |
| Caelum | don't remember which one it was | 09:55 |
| zyga | Caelum: maybe but I'm not convinced | 09:58 |
| zyga | this is failing on i386 consistently | 09:59 |
| zyga | while not failing on amd64 | 09:59 |
| Caelum | oh ok | 10:02 |
| Caelum | I've had a similar thing initially, it would build on i386 but fail on amd64 | 10:02 |
| Caelum | because it needs 32bit support stuff | 10:03 |
| zyga | but on 32bit system every library is this | 10:03 |
| zyga | I mean, 32bit | 10:03 |
| Caelum | yup | 10:04 |
| Caelum | there are no logs? | 10:04 |
| zyga | sure there are | 10:05 |
| zyga | have a look | 10:05 |
| zyga | I could not find what failed | 10:05 |
| zyga | the go build / check wrappers are extremely verbose | 10:05 |
| zyga | it seems a page full of text flies for every single file | 10:05 |
| Caelum | it thinks the tests failed because of bad exit status but there is no error, that would probably mean a segfault | 10:06 |
| Caelum | is it always failing on i386? | 10:07 |
| Caelum | err i686 I guess | 10:07 |
| Caelum | in the same exact place? | 10:08 |
| Caelum | build is randomly freezing on me downloading packages | 10:09 |
| Caelum | weird | 10:09 |
| zyga | Caelum: I don't know, what I managed to get is the log file it references | 10:10 |
| zyga | https://www.irccloud.com/pastebin/SC8Lnihd/ | 10:10 |
| Caelum | zyga: yeah that just runs the tests | 10:11 |
| Caelum | zyga: and then one of them segfaults | 10:11 |
| zyga | aha, | 10:11 |
| zyga | I can run tests with "go test ./..." just fine | 10:11 |
| Caelum | on 32 bit? | 10:11 |
| zyga | but on x86_64 :) | 10:11 |
| zyga | probably some of the hardening things are breaking | 10:11 |
| mvo | pedronis: adding pokestate is a bit of a rathole, a lot of tests do not setup the fake store and just rely on that some other test did that. anyway, working on it. good intuition there | 10:16 |
| Caelum | zyga: if you want to do a test on a 32 bit docker image, there are apparently some tricks involved: https://github.com/moby/moby/issues/611 | 10:22 |
| zyga | I'm using a 32bit chroot | 10:22 |
| Caelum | ah cool | 10:23 |
| zyga | abuild@tumbleweed:~/go/src/github.com/snapcore/snapd/vendor/github.com/mvo5/libseccomp-golang> go test | 10:26 |
| zyga | can't load package: package github.com/snapcore/snapd/vendor/github.com/mvo5/libseccomp-golang: build constraints exclude all Go files in /home/abuild/go/src/github.com/snapcore/snapd/vendor/github.com/mvo5/libseccomp-golang | 10:26 |
| zyga | mvo: ^ that's interesting, I'm trying to understand why this happens | 10:26 |
| zyga | nothing immediately obvious would cause this | 10:26 |
| mvo | zyga: that it the upstream libseccomp-golang with a mintor tweak | 10:27 |
| mvo | zyga: what arch is this? | 10:27 |
| zyga | mvo: i586 chroot | 10:27 |
| mvo | zyga: maybe its just missing from libseccomp-golang? | 10:27 |
| zyga | mvo: the constraints just say +linux | 10:27 |
| zyga | I'm exploring | 10:28 |
| Caelum | zyga: well, for some reason my build kept freezing on downloading packages, so I was not able to test anything, sorry. Going to be driving for the next 8 hours. If you aren't sure this always happens, you can make a dummy commit to force a rebuild or there is an osc command to force a rebuild too. | 10:28 |
| popey | Why does "snap info chromium" say license: unknown, but https://snapcraft.io/chromium shows lots of licenses? | 10:28 |
| zyga | Caelum: I tried that | 10:28 |
| Caelum | zyga: ah great | 10:28 |
| zyga | popey: because meta/snap.yaml doesn't say license: | 10:28 |
| popey | ah | 10:29 |
| popey | ok, thanks! :D | 10:29 |
| popey | It's a bit odd that it behaves differently if installed or not | 10:30 |
| zyga | yes | 10:31 |
| zyga | because once set of meta-data is from the store and the other is from the package | 10:31 |
| popey | yes, that's bizarro | 10:31 |
| zyga | # runtime/cgo | 10:33 |
| zyga | cc1: sorry, unimplemented: 64-bit mode not compiled in | 10:33 |
| zyga | mvo: tadam | 10:33 |
| zyga | that's golang 1.10 i386 | 10:33 |
| zyga | being confused about something apparently | 10:33 |
| zyga | this is a i386 chroot | 10:33 |
| zyga | (well i586) | 10:33 |
| zyga | this is after unsetting CGO_ENABLED=0 | 10:33 |
| mvo | zyga: yeah, I was suspecting that it can't identify its architcture | 10:33 |
| mup | PR snapd#5731 opened: daemon: remove TestSnapsInfoUnknownSource <Created by mvo5> <https://github.com/snapcore/snapd/pull/5731> | 10:34 |
| mvo | Chipaca: ^-- might be interessting for you, would love your feedback | 10:34 |
| niemeyer | cjwatson: ping | 10:38 |
| Caelum | zyga: and there is some kind of problem with 'osc build' that I saw in another one of my projects that I'm getting now: file /usr/lib/rpm/fileattrs/kernel.attr from install of rpm-config-SUSE-0-1.1.noarch conflicts with file from package rpm-4.14.1-3.1.x86_64 | 10:38 |
| Caelum | zyga: not related to snapd | 10:39 |
| zyga | I can build / test it in a chroot after setting GOARCH=386 | 10:39 |
| Chipaca | popey: license should be per snap revision (and not editable via web), but the store hasn't been able to implement it yet | 10:39 |
| Caelum | zyga: it also runs: file /usr/lib/rpm/fileattrs/kernel.attr from install of rpm-config-SUSE-0-1.1.noarch conflicts with file from package rpm-4.14.1-3.1.x86_64 | 10:40 |
| Caelum | err | 10:40 |
| Chipaca | mvo: what does 'go env' print? | 10:40 |
| Caelum | /usr/bin/make -O -j2 -C cmd check | 10:40 |
| mvo | Chipaca: you mean zyga right? | 10:40 |
| Chipaca | probably, yes | 10:41 |
| zyga | go env https://www.irccloud.com/pastebin/YsN4UGgW/ | 10:41 |
| zyga | though this is tweaked in an interactive shell | 10:41 |
| zyga | vanilla build doesn't show me anything useful | 10:41 |
| Chipaca | zyga: not sure what you're trying to do, but why are you trying to do it with gccgo? | 10:41 |
| Caelum | zyga: I mean, did you do only "go test" or "make check" too | 10:42 |
| zyga | this is for snap-seccomp | 10:42 |
| zyga | lots of red | 10:43 |
| zyga | https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd | 10:43 |
| mup | PR snapd#5732 opened: daemon: add pokeTest helper to the daemon tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/5732> | 10:43 |
| zyga | I'm just going to say this, whoever came up with the wrappers for golang in opensuse needs to do a reality check, it's the least useful wrapper I saw | 10:43 |
| zyga | and this includes the previous ruby wrapper | 10:43 |
| mvo | pedronis: I added the tests to a new PR and also updated the 5699 - should I add more before merging 5699? | 10:43 |
| zyga | I'm giving up on this | 10:44 |
| Caelum | zyga: so this happens on all architectures now | 10:46 |
| cjwatson | niemeyer: hi | 10:46 |
| Caelum | zyga: ok well, I'll take a look over the next few days | 10:47 |
| zyga | ok | 10:47 |
| Caelum | zyga: driving home from LA to san francisco now, take care | 10:51 |
| zyga | safe ride home | 10:51 |
| niemeyer | cjwatson: Heya | 10:57 |
| niemeyer | cjwatson: How do we kick spammers and their comments out of Launchpad? | 10:57 |
| niemeyer | cjwatson: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053/comments/100 | 10:57 |
| mup | Bug #1575053: Please move the "$HOME/snap" directory to a less obtrusive location <julyshakedown> <snapd:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1575053> | 10:57 |
| cjwatson | niemeyer: done | 11:01 |
| cjwatson | (https://answers.launchpad.net/launchpad/+addquestion is our preferred way to report spam) | 11:01 |
| niemeyer | cjwatson: Thanks! | 11:03 |
| niemeyer | cjwatson: Will use that next time | 11:03 |
| cjwatson | thanks for the report, we obviously try to boot spammers out ASAP to minimise damage | 11:03 |
| abeato | Wimpress, hey, do you know how can make snapcraft generate a manifest? | 11:05 |
| zyga | ok | 11:30 |
| zyga | small progress | 11:30 |
| zyga | finally feels better than packaging | 11:30 |
| baimafeima | hi does anyone know what's the difference in terms of security and user privacy when comparing snaps, flatpaks and appimages? | 11:42 |
| zyga | baimafeima: it's complicated | 11:42 |
| zyga | baimafeima: except maybe appimages that by default have no sandbox at all | 11:42 |
| baimafeima | zyga, mhm so appimages could theoretically gather a lot of data as they are not sandboxed ... | 11:43 |
| baimafeima | if I were to install a malicious snap or flatpak or appimage, through which could my system most easily be exploited? | 11:43 |
| zyga | baimafeima: as appimage is not sandboxed in any way the answer is obvious | 11:44 |
| baimafeima | zyga, what about snaps vs flatpaks? pros and cons? | 11:45 |
| zyga | it's complicated | 11:45 |
| baimafeima | zyga, let's say I have wayland and on the operating system side all the latest versions | 11:46 |
| zyga | it's still very complicated | 11:46 |
| zyga | it's not something that can be accurately described in a few moments | 11:46 |
| baimafeima | zyga, does having reproducible builds apply to both? | 11:48 |
| zyga | no, to neither | 11:48 |
| baimafeima | zyga, I know snaps have a broader use case, IoT and such and distribution is centralized, whereas everyone can host their own flatpaks and it's more desktop-focused... | 11:50 |
| zyga | baimafeima: perhaps it's not common knowledge but both systems cannot care less about how the package is built | 11:50 |
| zyga | so any package can be built in any way really | 11:50 |
| zyga | so some packages can be built with all the hardening and reproducible build tweaks | 11:51 |
| zyga | while others can just contain a debug build from someone's lap | 11:51 |
| baimafeima | zyga, so you basically suggest a snap is not a snap or a flatpak isn't a flatpak and I would still have to trust the developer on the quality of the packaging? So there are going to be hardened snaps and those that are not? | 11:52 |
| zyga | baimafeima: with both systems you trust on whoever is making the package, yes | 11:53 |
| baimafeima | is the reason to keep the entry barrier into snap or flatpak development low? or is there a way to enforce higher minimum standards below which a snap simply won't run? | 11:53 |
| zyga | while many packages can be of good quality there is nothing that prevents anyone from making a bad quality package | 11:53 |
| baimafeima | zyga, I see, then I would say a centralized distribution system like with snaps could have an eye on quality control whereas that wouldn't be easily possible with flatpaks? | 11:54 |
| zyga | well | 11:54 |
| zyga | what's the goal? | 11:54 |
| zyga | linux packaging is hard | 11:54 |
| zyga | linux market share is pretty much close to zero | 11:55 |
| zyga | using the right helpers people will get (over time) better and better builds | 11:55 |
| zyga | but you have to recognise that packaging is very hard as it is already | 11:55 |
| zyga | with each distribution having complex policy | 11:55 |
| zyga | and widely different levels of quality | 11:55 |
| zyga | the point of snaps and flatpak is to make it better for developers and users | 11:55 |
| zyga | that includes making it easier | 11:56 |
| baimafeima | zyga, mhm I see, which distribution do you use to build and develop? | 11:56 |
| zyga | we have plenty of bad outdated, buggy apps already | 11:56 |
| zyga | and the existing policy system does not change that | 11:56 |
| zyga | you can link the buggy and broken and old package with hardening options and use reproducible builds while you are at it | 11:57 |
| zyga | but because it's hard and complex the upstreams cannot care less about that (I'm generalising obviously) and if they ever test something it is whatever they are running (probably not linux because of statistics) | 11:57 |
| zyga | so in the end, we are hoping to make the process less complex so that more people have a better time at making apps | 11:57 |
| zyga | and at using apps | 11:57 |
| zyga | baimafeima: I use multiple operating systems | 11:58 |
| baimafeima | zyga, interesting | 11:58 |
| baimafeima | zyga, I remember (but cannot find the github issue) that there was a discussion regarding on-the-fly updates and whether there is a possibility for end-users to prevent a snap from updating itself and how this can be integrated into software centers with fine-grained control | 12:00 |
| zyga | baimafeima: I wonder if statistically upstream developers still use compiled languages as a majority so reproducible builds and hardening probably apply a level below where people generally tend to code now | 12:00 |
| zyga | baimafeima: there's a thread about that on the snapcraft forum I believe | 12:02 |
| baimafeima | zyga, ah yeah I think it was on the forum, not sure whether it's been resolved by now | 12:03 |
| zyga | baimafeima: it depends by what you mean, there's no universal agreement on what should happen | 12:03 |
| baimafeima | zyga, it's a pity that there's not more commitment to reproducible builds | 12:03 |
| === pstolowski is now known as pstolowski|lunch | ||
| zyga | baimafeima: it's a pity there's no more commitment to {useful APIs,documentation,stability,artwork,localisation,business friendliness} | 12:04 |
| baimafeima | zyga, I think most end-users won't care but some care about the degree of control through the auto-update mechanism | 12:04 |
| zyga | there are many dragons to fight | 12:04 |
| abeato | sergiusens, , hey, do you know how can make snapcraft generate a manifest? | 12:07 |
| baimafeima | zyga, thanks for the infos, I'll slowly read my way into this | 12:09 |
| zyga | baimafeima: if you have specific questions I will be happy to answer them | 12:11 |
| baimafeima | zyga, thanks | 12:14 |
| zyga | brb | 12:17 |
| zyga | re | 12:33 |
| === pstolowski|lunch is now known as pstolowski | ||
| Son_Goku | baimafeima, reproducible builds aren't particularly valuable to most people | 12:50 |
| Son_Goku | they've made that choice when they decided in their ecosystems that they attempt fetching from a VCS (nodejs, php, golang, etc.) rather than having releases upload a tarball (python, rust, c/c++, etc.) | 12:51 |
| jdstrand | mborzecki, mvo: /etc/writable/hostname is *not* writable in interfaces/builtin/hostname_control.go | 13:10 |
| zyga | 3085 1000000 20 0 70896 65316 38896 R 100.0 8.1 2:34.73 unattended+ | 13:11 |
| zyga | that's weird | 13:11 |
| zyga | that's on a dragon board running core | 13:11 |
| zyga | ah, that's inside a container | 13:12 |
| mup | PR snapcraft#2227 closed: lxd: wait for cloud-init <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2227> | 13:39 |
| mup | PR snapcraft#2228 opened: storeapi: handle releasing to curly braced branch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2228> | 13:42 |
| ogra | hmm ... when i "snap stop" a service from a snap and the snap gets refreshed, the service gets automatically started again | 13:54 |
| ogra | is that expected (not by me for sure, but is it expected y the implementation ?) | 13:54 |
| ogra | *by the | 13:55 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | ogra: yes | 14:14 |
| Chipaca | ogra: or, no | 14:14 |
| Chipaca | ogra: … maybe? | 14:14 |
| Chipaca | ogra: 'snap stop' does not imply 'snap disable' | 14:14 |
| Chipaca | ogra: i mean, snap stop --disable | 14:14 |
| Chipaca | which is different from snap disable, of course | 14:14 |
| pedronis | mvo: btw assertions not only have revisions, but also format (an increasing version of the format), in theory we could also play with that (so far we have incremented it only for snap-declaration) | 14:22 |
| mvo | pedronis: oh, interessting idea | 14:22 |
| pedronis | mvo: snapd always sends the max-format it supports when asking for assertions | 14:24 |
| pedronis | anyway another thing | 14:25 |
| * mvo nods | 14:26 | |
| ogra | Chipaca, well, can i disable single services and not the whole snap ? i thought disable completely turns off the whole set | 14:30 |
| pedronis | mvo: to be clear it's per assertion type, is not global | 14:32 |
| Chipaca | ogra: 'snap disable' is snap-level; 'snap stop --disable' is service-level | 14:37 |
| mvo | pedronis: ta | 14:41 |
| ogra | Chipaca, aaah !! thanks | 14:43 |
| zyga | re, hasty day, quick lunch done | 14:47 |
| sergiusens | abeato: hey, sorry, I saw your question pop-up but was super focused on code reviews. So you want SNAPCRAFT_BUILD_INFO (also reminded under recording here https://github.com/snapcore/snapcraft/releases/tag/2.43) | 15:17 |
| abeato | sergiusens, ok, so that is just an env var, right? is it considered experimental still? | 15:18 |
| sergiusens | abeato: no, not experimental, it is being used by USN already | 15:19 |
| abeato | sergiusens, got it, thanks | 15:19 |
| mup | PR snapd#5733 opened: snap/squashfs: improve error message from Build on mksquashfs failure <Created by chipaca> <https://github.com/snapcore/snapd/pull/5733> | 15:31 |
| mup | PR core#94 closed: hooks: improve /etc/alternatives unwinding <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/94> | 15:36 |
| mvo | fwiw, I'm looking at the core16 degraded boot failure right now | 15:36 |
| zyga | mvo: flashing dragon now | 15:43 |
| zyga | mvo: I'm done with meetings today | 15:43 |
| abeato | sergiusens, can you force creation of the manifest in snapcraft.yaml file? | 15:49 |
| sergiusens | abeato: we have no language for that. Maybe create a forum post requesting it. | 15:54 |
| abeato | sergiusens, ok | 15:55 |
| sergiusens | abeato: fwiw, I do agree we need a way to opt-in/opt-out | 15:55 |
| sergiusens | but it is one of those where agreeing on the syntax for it is the larger discussion:-) | 15:55 |
| abeato | haha | 15:55 |
| abeato | ok | 15:55 |
| abeato | sergiusens, https://forum.snapcraft.io/t/no-way-to-create-manifest-from-snapcraft-yaml/7076 | 16:02 |
| cachio | zyga, hey | 16:09 |
| cachio | https://paste.ubuntu.com/p/y2p6byKthP/ | 16:09 |
| cachio | I saw this error | 16:09 |
| zyga | right | 16:09 |
| zyga | I don't know why it happens | 16:10 |
| zyga | I saw the pastebin before | 16:10 |
| cachio | zyga, ok :( | 16:10 |
| zyga | there's clearly a bug but we don't have a firm understanding if this is a bug in systemd or in the kernel | 16:10 |
| zyga | or in some intermediate libraries | 16:11 |
| cachio | zyga, nice, I'll continue researching | 16:12 |
| zyga | there's a thread that has some information about this | 16:12 |
| zyga | if you find out anything please add it there | 16:13 |
| xnox | mvo, so you went and fixed something for which you already had a universal pam script for without fixing the issue we hit with cloud-sdks shipped as snaps =) | 16:18 |
| xnox | mvo, can we talk about https://github.com/snapcore/snapd/pull/5226 again? i posted the comment there. | 16:18 |
| mup | PR #5226: data: add systemd user environment generator <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5226> | 16:18 |
| xnox | mvo, is the test case still not clear which environment is still wrong and still does not contain /snap/bin | 16:18 |
| zyga | mvo: booting your image now | 16:23 |
| zyga | I had some SD card woes | 16:23 |
| zyga | (apparently that silly lock switch does something) | 16:23 |
| zyga | it errors with: /usr/share/subiquity/console-conf-wrapper: line 13: snap: command not found | 16:24 |
| zyga | I'm in interactive uboot prompt | 16:24 |
| zyga | mvo: just let me know what you need when you're back | 16:24 |
| zyga | mvo: I applied: env set snappy_cmdline net.ifnames=0 init=/lib/systemd/systemd ro panic=-1 fixrtc systemd.debug-shell=1 | 16:25 |
| pstolowski | zyga: hey, got a moment for quick HO? | 16:37 |
| * cachio lunch & doctor | 16:40 | |
| blackboxsw | nice sergiusens: on cloud-init status --wait. :) per the above lxd: wait branch. | 16:57 |
| blackboxsw | glad to see consumers of that blocking wait | 16:58 |
| mvo | xnox: I'm checking your comment and will reply | 16:59 |
| xnox | mvo, thanks | 16:59 |
| mvo | zyga: yeah, that might not be sufficient to get a shell | 16:59 |
| mvo | xnox: aha, so we need a *system* env generator. is there such a thing? pardon my ignorance on this | 17:01 |
| mvo | xnox: anyway, I will investigate | 17:03 |
| xnox | mvo, well the generator is that. | 17:04 |
| xnox | mvo, we already had user thing already anyway | 17:04 |
| === pstolowski is now known as pstolowski|afk | ||
| xnox | mvo, via the legacy script that we did | 17:04 |
| mvo | xnox: ok | 17:04 |
| mvo | xnox: so we ship a systemd system env generator but its not picked up, that is the issue, correct? | 17:04 |
| xnox | mvo, no you never shipped it | 17:04 |
| xnox | mvo, you proposed it and then did not merge.... | 17:05 |
| xnox | mvo, and decided that you need environment.d snippet and that's it.... but you didn't need that one at all | 17:05 |
| xnox | cause you already had the pam.d thing already (the shell script thing) | 17:05 |
| xnox | mvo, maybe we need a hangout? | 17:05 |
| sergiusens | blackboxsw: heh, I wish I'd known about that sooner, I had implemented my own poller looking at the cloud init status file | 17:05 |
| xnox | mvo, so the /etc/profile.d/apps-bin-path.sh & /usr/lib/environment.d/990-snapd.conf are redundand. | 17:06 |
| mvo | xnox: oh, now I remember, sorry, it was a while. ok - I think I know what is going on, I missed the difference between the two | 17:06 |
| mvo | xnox: the difference between environment.d and a generator | 17:06 |
| xnox | mvo, well profile.d is used by pammy / more traditional things; and the latter one is used by recentish systemd things for /logged in users/ | 17:07 |
| blackboxsw | sergiusens: mea cupla. /me needs to figure out how to better advertise nice CLI features... I dump updates in here https://cloudinit.readthedocs.io/en/latest/topics/capabilities.html#cli-subcommand-details, but I'll make sure to rope someone snappy in on next round of changes that could affect folks. | 17:07 |
| xnox | mvo, the /usr/lib/environment.d/ is read by /usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator for the logged in users. | 17:07 |
| mvo | xnox: thanks, I know now what to do - sorry for this | 17:08 |
| mvo | xnox: I will resurrect the system env generator | 17:08 |
| xnox | mvo, that's ok. it is confusing, and most things are named identical. | 17:08 |
| xnox | or very similar | 17:08 |
| xnox | mvo, dammit can't find the docs now. | 17:09 |
| sergiusens | blackboxsw: no worries, I only found out about that status file by a google/ddg search that led to a bug report from 5 years ago iirc where scott mentioned he'd implement it; look at the code a bit, saw it was there for the series we needed it and just went ahead and did what needed doing | 17:09 |
| sergiusens | documentation is hard :-) | 17:10 |
| mvo | xnox: no worries, I will resurrect the PR tomorrow | 17:10 |
| mvo | xnox: thanks for the heads up! | 17:10 |
| xnox | mvo, cool thanks! | 17:10 |
| xnox | mvo, it would be nice to have a direction.d thing for system envrionemnt too, but there doesn't appear to be one, hence the need of a executable generator for the system one. | 17:10 |
| xnox | (systemd doesn't pre-ship one, the way it does a user generator) | 17:11 |
| blackboxsw | sergiusens: as a heads up, I know snappy also looks at instance-data.json we'll shortly have a 'cloud-init query' subcommand which allows one to query the struct without having to parse the data file directly. Some of those query changes will also surface improved 'region' detection on a couple of clouds. I'll add you as a reviewer when that branch is up, just for a glance to see if it's of interest. | 17:13 |
| sergiusens | blackboxsw: heh, well the person you want to reach out to is mvo; I personally work on only snapcraft these days | 17:15 |
| blackboxsw | +1 thx | 17:15 |
| sergiusens | my snapd days ended almost 3 years ago :-) | 17:15 |
| zyga | pstolowski|afk: now yes | 18:01 |
| zyga | mvo: I can tinker perhaps enough to get a Getty | 18:01 |
| mvo | zyga: good luck | 18:09 |
| * zyga just states for the record that we have some idea why the dragon image is not working | 18:54 | |
| mup | PR snapd#5734 opened: tests: remove /etc/alternatives from dirs-not-shared-with-host <Created by mvo5> <https://github.com/snapcore/snapd/pull/5734> | 19:22 |
| * zyga EODs | 19:56 | |
| === gurmble is now known as grumble | ||
| * zyga likes https://commit.style/ | 20:09 | |
| mup | PR snapcraft#2226 closed: templates: reimplement templates as python classes <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2226> | 21:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!