[02:34] zyga: looks like we'll need to update the opensuse package again, stopped working [02:35] zyga: "cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied" [05:04] morning [05:49] PR snapd#5691 closed: spdx: allow Other-Open-Source [05:50] PR snapd#5728 opened: spdx: remove "Other Open Source" from the support licenses [05:55] zyga: hey, what do you think, when can we remove the experimental flag from layouts? [06:00] PR snapd#5729 opened: many: rename ClientOpts to ClientOptions [06:06] 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] PR #5722: tests: test for the hostname interface [06:07] mvo: iirc layouts still have that problem with trespassing to the host's filesystem [06:09] mborzecki: hm, etc/hostname should be a symlink on core18 to etc/writable/hostname, let me double check that [06:11] mborzecki: yeah, its a symlink [06:12] mborzecki: so maybe thats the problem? that the apparmor policy does not have the symlink? [06:12] (target) [06:13] 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] mvo: wonder if hostnamectl truncates /etc/hostname or writes a new file and does a rename [06:15] Good morning [06:16] zyga: hey [06:17] I’ll start soon [06:17] mborzecki: oh that rings a bell [06:17] Kids had blood test today [06:17] mborzecki: let me quickly check [06:17] And needed my “moral support” [06:17] pedronis: is 5699 something you want to review ? or do you think its fine? [06:18] mborzecki: this sounds a lot like https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936 [06:18] mvo: after trespassing bug is fixed [06:18] zyga: aha, ok [06:18] Then they are ready [06:18] Bug #1778936: please re-add Support-system-image-read-only-etc.patch [06:19] mup: heh, yes [06:19] mborzecki: I apologize, but I'm pretty strict about only responding to known commands. [06:19] mvo: heh, yes :) [06:19] I’ll work with Maciej on this as it was harder to come up with precise logic than I wished last time [06:21] mborzecki: I get the feeling I will have to do this SRU myself :/ [06:21] mborzecki: anyway [06:21] mborzecki: I will put it on my list [06:22] PR snapd#5730 opened: devicestate: support getting (http) proxy from core config [06:23] PR snapd#5704 closed: snap: add new type "TypeSnapd" and attach to the snapd snap [06:24] PR snapd#5728 closed: spdx: remove "Other Open Source" from the support licenses [06:25] 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] mvo: already +1'ed it [06:25] oh, w8, that's the other one :) [06:32] PR snapd#5710 closed: cmd: support re-exec into the "snapd" snap [06:41] PR snapd#5709 closed: configcore,snapstate: add new core.experimental.snapd-snap option [06:44] PR core#93 closed: hooks: unwind /etc/alternatives [06:44] Back [06:58] mvo: re [06:58] mvo: I have that dragon on my desk if you need any support [06:58] mvo: it's not powered on but I can bring all the misc bits and set it up if you need me to === pstolowski|afk is now known as pstolowski [07:16] mornings [07:20] pstolowski: hey [07:21] 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] Caelum: yes, I have the build ready, just need to pull the trigger [07:21] Caelum: can you review & test? [07:21] zyga: yeah totally [07:22] ok [07:22] hold on, let me commit [07:22] zyga: I just send an update to the etc/alternatives stuff in snapcore/core18. not urgent but you may be interessted [07:22] PR core18#64 opened: hooks: improve /etc/alternatives unwinding [07:22] ack [07:23] zyga: also at some point I want to talk about reviving the gentoo overlay [07:24] sure [07:24] I have nothing for that so please go ahead [07:25] PR core#94 opened: hooks: improve /etc/alternatives unwinding [07:26] btrfs rebalance ... [07:33] ha [07:33] mvo: I found a bug in our systemd unit [07:33] system key refresh takes long eough [07:33] long enough [07:33] that systemd restarts us [07:34] we need to poke systemd using sd-notify during the security setup as it can take a lot of time [07:36] I guess this will continue while balancing is in progress as the system is much slower than usual [07:44] it's good to cron that shit [07:44] mine is @daily [07:44] zyga: well highlight me if you want me to do anything [07:45] Caelum: sure, I'll send my build as soon as btrfs stops my system from crawling [07:45] Caelum: I want to branch it so that it can be reviewed [07:46] awesome [07:56] ok I/O aside I managed to branch it [08:02] 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:03] PR #5729: many: rename ClientOpts to ClientOptions [08:03] https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd [08:06] Good mornings! [08:12] moin moin [08:12] hey guys [08:12] good morning [08:12] :) [08:12] o/ [08:12] summer is supposedly back this week (just not yet) [08:17] mvo: did you see the last failure on #5722? is /etc/hostname writable on core 18? [08:18] PR #5722: tests: test for the hostname interface [08:26] Chipaca: I did not, but i suspect its https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936 [08:26] Bug #1778936: please re-add Support-system-image-read-only-etc.patch [08:26] mvo: ah [08:26] zyga: nice catch [08:27] mborzecki: 5729 is build on top of the other one, I hope I added it to the description [08:27] mborzecki: I think I could split them maybe thats clearer [08:27] mvo: it's ok with me [08:28] 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] mborzecki: ok [08:28] Chipaca: and WELCOME BACK [08:29] mvo: :-) [08:29] mvo: looking forward to all the review feedback that'll be waiting for me [08:32] zyga: were you able to get your lab back up? I could use a darwin shell about now [08:32] Chipaca: almost, I can set you up in 10 min [08:32] zyga: no rush; just let me know [08:35] almost done [08:36] mvo: hi [08:37] pedronis: good morning! just wanted to double check if 5699 is something you want to have a look at :) [08:38] mvo: I'm a bit worried that we are not super consistent about releasing the lock when doing store things [08:38] 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] we do for some main things [08:38] pedronis: yeah, this PR would enforce that we are [08:38] mvo: enforce ? [08:38] pedronis: well, it will crash or hang if we don't [08:38] wouldn't call that enforce [08:39] Chipaca: check check? [08:39] pedronis: ok, bad wording then :/ I mean we will need it [08:40] zyga: check what? [08:40] ah [08:40] Chipaca: did you see my private msg? [08:40] mvo: yea, re-double checking [08:40] zyga: now yes [08:41] Chipaca: there's golang and gcc [08:41] Chipaca: there should be git and other things but let me know if you need more [08:41] Chipaca: you are on bare metal [08:42] zyga: woo, thanks [08:42] mbuahaha [08:42] enjoy :) === chihchun is now known as chihchun_afk [08:53] 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:56] pedronis: so it sounds like I should add tests in daemon that poleStateLock? [08:57] 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:59] pedronis: great, I will do that, thank you [09:12] * zyga wonders what the error is in https://build.opensuse.org/build/home:zyga:branches:system:snappy/openSUSE_Tumbleweed/i586/snapd/_log [09:13] log files from suse are horrible :/ [09:13] hm i guess locking the state for the whole duration of doMountSnap() is a bad idea? [09:13] zyga: can you install squashfs-tools? [09:13] Chipaca: not sure, let me try [09:14] zyga: (assuming you're using something like brew) [09:14] no, I try to stay clear of brew [09:14] (or whatever the package mangler on osx is) [09:15] zyga: I'll run it from git (or try to!) [09:15] Chipaca: it doesn't build, hold on [09:15] mksquashfs.c:4404:29: error: use of undeclared identifier 'FNM_EXTMATCH' [09:15] FNM_PATHNAME|FNM_PERIOD|FNM_EXTMATCH) == 0; [09:16] I have a firm deja-vu now [09:16] Chipaca: if you can find me a copy that builds :) [09:16] Chipaca: I suspect someone patched the glibc-specific flag [09:17] I remember now, I was building this on my MacBook [09:17] (remember, the one I had in Netherlands) [09:18] and I had to patch some things for it to build === chihchun_afk is now known as chihchun [09:18] zyga: looks like there's a nixos patch for darwin [09:20] Chipaca: do you have a link or a tree ? [09:20] ideally something we would later on incorporate into our build [09:36] zyga: could you sudo chmod u+s /usr/bin/dtrace [09:37] dtrace? :) [09:37] sure, what do you need it for [09:37] zyga: this is the patch: https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/filesystems/squashfs/darwin.patch [09:37] zyga: 'snap pack' failing with 'exit error 1', wondering what all is failing [09:37] shortest path to answer that is to trace it :-) [09:37] then i need to improve the error output [09:37] then, fix it [09:44] Chipaca: are you set now? [09:45] zyga: it works [09:45] ok, good luck [09:45] I should reboot the ssh host as it runs an older kernel [09:45] so let me know when would be a good time for that [09:47] Caelum: hey [09:47] I pushed https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd [09:47] can you please have a look at that [09:47] I cannot understand why the i386 build fails [09:47] (the error log is just ... not saying anything) [09:47] in any case, that is the latest and greatest [09:48] so any feedback you can get on that is appreciated [09:49] Caelum: you need to build the package locally as I didn't publish the build [09:49] I'll grab a coffee and be back soon [09:51] zyga: looking now [09:52] 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:55] don't remember which one it was [09:58] Caelum: maybe but I'm not convinced [09:59] this is failing on i386 consistently [09:59] while not failing on amd64 [10:02] oh ok [10:02] I've had a similar thing initially, it would build on i386 but fail on amd64 [10:03] because it needs 32bit support stuff [10:03] but on 32bit system every library is this [10:03] I mean, 32bit [10:04] yup [10:04] there are no logs? [10:05] sure there are [10:05] have a look [10:05] I could not find what failed [10:05] the go build / check wrappers are extremely verbose [10:05] it seems a page full of text flies for every single file [10:06] it thinks the tests failed because of bad exit status but there is no error, that would probably mean a segfault [10:07] is it always failing on i386? [10:07] err i686 I guess [10:08] in the same exact place? [10:09] build is randomly freezing on me downloading packages [10:09] weird [10:10] Caelum: I don't know, what I managed to get is the log file it references [10:10] https://www.irccloud.com/pastebin/SC8Lnihd/ [10:11] zyga: yeah that just runs the tests [10:11] zyga: and then one of them segfaults [10:11] aha, [10:11] I can run tests with "go test ./..." just fine [10:11] on 32 bit? [10:11] but on x86_64 :) [10:11] probably some of the hardening things are breaking [10:16] 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:22] 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] I'm using a 32bit chroot [10:23] ah cool [10:26] abuild@tumbleweed:~/go/src/github.com/snapcore/snapd/vendor/github.com/mvo5/libseccomp-golang> go test [10:26] 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] mvo: ^ that's interesting, I'm trying to understand why this happens [10:26] nothing immediately obvious would cause this [10:27] zyga: that it the upstream libseccomp-golang with a mintor tweak [10:27] zyga: what arch is this? [10:27] mvo: i586 chroot [10:27] zyga: maybe its just missing from libseccomp-golang? [10:27] mvo: the constraints just say +linux [10:28] I'm exploring [10:28] 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] Why does "snap info chromium" say license: unknown, but https://snapcraft.io/chromium shows lots of licenses? [10:28] Caelum: I tried that [10:28] zyga: ah great [10:28] popey: because meta/snap.yaml doesn't say license: [10:29] ah [10:29] ok, thanks! :D [10:30] It's a bit odd that it behaves differently if installed or not [10:31] yes [10:31] because once set of meta-data is from the store and the other is from the package [10:31] yes, that's bizarro [10:33] # runtime/cgo [10:33] cc1: sorry, unimplemented: 64-bit mode not compiled in [10:33] mvo: tadam [10:33] that's golang 1.10 i386 [10:33] being confused about something apparently [10:33] this is a i386 chroot [10:33] (well i586) [10:33] this is after unsetting CGO_ENABLED=0 [10:33] zyga: yeah, I was suspecting that it can't identify its architcture [10:34] PR snapd#5731 opened: daemon: remove TestSnapsInfoUnknownSource [10:34] Chipaca: ^-- might be interessting for you, would love your feedback [10:38] cjwatson: ping [10:38] 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:39] zyga: not related to snapd [10:39] I can build / test it in a chroot after setting GOARCH=386 [10:39] popey: license should be per snap revision (and not editable via web), but the store hasn't been able to implement it yet [10:40] 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] err [10:40] mvo: what does 'go env' print? [10:40] /usr/bin/make -O -j2 -C cmd check [10:40] Chipaca: you mean zyga right? [10:41] probably, yes [10:41] go env https://www.irccloud.com/pastebin/YsN4UGgW/ [10:41] though this is tweaked in an interactive shell [10:41] vanilla build doesn't show me anything useful [10:41] zyga: not sure what you're trying to do, but why are you trying to do it with gccgo? [10:42] zyga: I mean, did you do only "go test" or "make check" too [10:42] this is for snap-seccomp [10:43] lots of red [10:43] https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd [10:43] PR snapd#5732 opened: daemon: add pokeTest helper to the daemon tests [10:43] 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] and this includes the previous ruby wrapper [10:43] pedronis: I added the tests to a new PR and also updated the 5699 - should I add more before merging 5699? [10:44] I'm giving up on this [10:46] zyga: so this happens on all architectures now [10:46] niemeyer: hi [10:47] zyga: ok well, I'll take a look over the next few days [10:47] ok [10:51] zyga: driving home from LA to san francisco now, take care [10:51] safe ride home [10:57] cjwatson: Heya [10:57] cjwatson: How do we kick spammers and their comments out of Launchpad? [10:57] cjwatson: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053/comments/100 [10:57] Bug #1575053: Please move the "$HOME/snap" directory to a less obtrusive location [11:01] niemeyer: done [11:01] (https://answers.launchpad.net/launchpad/+addquestion is our preferred way to report spam) [11:03] cjwatson: Thanks! [11:03] cjwatson: Will use that next time [11:03] thanks for the report, we obviously try to boot spammers out ASAP to minimise damage [11:05] Wimpress, hey, do you know how can make snapcraft generate a manifest? [11:30] ok [11:30] small progress [11:30] finally feels better than packaging [11:42] hi does anyone know what's the difference in terms of security and user privacy when comparing snaps, flatpaks and appimages? [11:42] baimafeima: it's complicated [11:42] baimafeima: except maybe appimages that by default have no sandbox at all [11:43] zyga, mhm so appimages could theoretically gather a lot of data as they are not sandboxed ... [11:43] if I were to install a malicious snap or flatpak or appimage, through which could my system most easily be exploited? [11:44] baimafeima: as appimage is not sandboxed in any way the answer is obvious [11:45] zyga, what about snaps vs flatpaks? pros and cons? [11:45] it's complicated [11:46] zyga, let's say I have wayland and on the operating system side all the latest versions [11:46] it's still very complicated [11:46] it's not something that can be accurately described in a few moments [11:48] zyga, does having reproducible builds apply to both? [11:48] no, to neither [11:50] 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] baimafeima: perhaps it's not common knowledge but both systems cannot care less about how the package is built [11:50] so any package can be built in any way really [11:51] so some packages can be built with all the hardening and reproducible build tweaks [11:51] while others can just contain a debug build from someone's lap [11:52] 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:53] baimafeima: with both systems you trust on whoever is making the package, yes [11:53] 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] while many packages can be of good quality there is nothing that prevents anyone from making a bad quality package [11:54] 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] well [11:54] what's the goal? [11:54] linux packaging is hard [11:55] linux market share is pretty much close to zero [11:55] using the right helpers people will get (over time) better and better builds [11:55] but you have to recognise that packaging is very hard as it is already [11:55] with each distribution having complex policy [11:55] and widely different levels of quality [11:55] the point of snaps and flatpak is to make it better for developers and users [11:56] that includes making it easier [11:56] zyga, mhm I see, which distribution do you use to build and develop? [11:56] we have plenty of bad outdated, buggy apps already [11:56] and the existing policy system does not change that [11:57] you can link the buggy and broken and old package with hardening options and use reproducible builds while you are at it [11:57] 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] 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] and at using apps [11:58] baimafeima: I use multiple operating systems [11:58] zyga, interesting [12:00] 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] 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:02] baimafeima: there's a thread about that on the snapcraft forum I believe [12:03] zyga, ah yeah I think it was on the forum, not sure whether it's been resolved by now [12:03] baimafeima: it depends by what you mean, there's no universal agreement on what should happen [12:03] zyga, it's a pity that there's not more commitment to reproducible builds === pstolowski is now known as pstolowski|lunch [12:04] baimafeima: it's a pity there's no more commitment to {useful APIs,documentation,stability,artwork,localisation,business friendliness} [12:04] zyga, I think most end-users won't care but some care about the degree of control through the auto-update mechanism [12:04] there are many dragons to fight [12:07] sergiusens, , hey, do you know how can make snapcraft generate a manifest? [12:09] zyga, thanks for the infos, I'll slowly read my way into this [12:11] baimafeima: if you have specific questions I will be happy to answer them [12:14] zyga, thanks [12:17] brb [12:33] re === pstolowski|lunch is now known as pstolowski [12:50] baimafeima, reproducible builds aren't particularly valuable to most people [12:51] 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.) [13:10]