[06:09] good morning [06:09] * zyga preps kids for school [06:15] morning [07:14] good morning everyone [07:14] https://forum.snapcraft.io/t/yes-snaps-are-cross-distribution/3906 <- cool stuff :) [07:18] zyga: good morning [07:20] PR snapd#4637 opened: devicestate: fix the TestDoRequestSerialErrorsOnNoHost failing on artful/bionic [07:21] huh? [07:21] mvo can you explain? [07:26] zyga: mvo: morning [07:27] zyga: iirc there's an ongoing story about pickign the right 'unresolvable' domain in the tests, *.test was suppsoed to be the answer, but my guess is some resolvers were trying to resolve it actually [07:30] zyga: /var/lib/snapd/mount is something that was introduced in 2.31 cycle? [07:30] no [07:30] far older [07:31] snap-mgmt --purge does not clean it up [07:32] i'm checking snapd aur package and noticed that /var/lib/snapd/mount was left behind when i removed snapd-git [07:37] mborzecki it's very very old, probably an omission then [07:37] mvo could we use something like http://unresolvable.snapcraft.io [07:37] and arrange with people so that it never resolves [07:38] I'm almost inclined to buy really-nowhere.com ;-) [07:43] zyga: ups, thanks. so the issue appaears to be that for some daemons artful/bionic returns SERVFAIL instead of NXDOMAIN [07:43] zyga: its not fully clear yet why, I'm looking into this. we see this on bionic autopkgtests and also on one of my two artful systems [07:44] mvo can I help somehow, I can setup nothing.zygoon.pl with any config desired [07:44] how are you testing this? [07:44] zyga: I have one machine where i can reproduce it [07:44] is it using systemd-resolved? [07:44] PR snapd#4637 closed: devicestate: fix the TestDoRequestSerialErrorsOnNoHost failing on artful/bionic [07:45] zyga: I think so, I switched to it a while ago there, I would consider it a fluke without the autopkgtest failure that looks similar [07:45] zyga: internally we handle SERVFAIL as a temporary error and retry [07:45] well, my offer stands, let me know if I can help [07:45] zyga: this is why we see a test failure, this test is expecting an error and it gets a "doing" [07:45] ack [07:45] zyga: thanks! I will dig a bit [07:46] * zyga looks for a color scheme appropriate for "gloomy polish morning" [07:46] gloomy, it's fat thursday today [07:47] zyga: did you get your donut yet? [07:56] mvo: hi, don't autopkgtest machines proxy http(s)? that probably gives a different kind of errors [07:57] mborzecki no, not today [07:58] mborzecki I will get one in a few days, today is the worst possible day to buy them (unless you make one at home0 [08:03] pedronis: thats an interessting idea, they do that [08:03] o/ [08:04] pedronis: it might be two issues :/ anyway, I get a SERVFAIL in a fresh bionic kvm (which we consider a temp error) so thats something to look into [08:04] morning [08:33] https://jordaneldredge.com/projects/winamp2-js/ :D [08:34] (drag and drop music to play) [08:34] zyga: i'll sync snapd-git aur PKGBUILD with that of snapd and open a PR to our repo to sync the recipe in packaging too [08:35] mborzecki sounds good, thank you [08:35] PR snapd#4638 opened: devicestate: fix autopkgtest failure in TestDoRequestSerialErrorsOnNoHost [08:38] anyone (sans chipaca who did) wants to look at https://github.com/snapcore/snapd/pull/4636 [08:38] PR #4636: snap: understand directories in layout blacklist [09:16] i'm wondering snap is being used in the scenario of distributing a library itself. i.e. the package would contain a standalone app but a library? [09:18] wiking it's possible using the content interface [09:18] though we have a constraint that snaps can only share among one snap publisher [09:19] goooooooooooooooood mornin [09:19] if someone wants to maintain a snap that is used by others we need to allow that, it's essentially a promise to maintain something correctly [09:19] ikey happy pączki day :-) [09:19] wiking, for example there's a gnome platform snap (AFAIK) that anyone can use even though it's published by a third party [09:20] Chipaca morning :) [09:20] zyga, and thee [09:20] gnome-3-26-1604 [09:20] zyga, yeah i'm trying to avoid keep maintaining a deb/rpm package and possibly just switch to snap [09:20] zyga: moin [09:20] wiking though for libraries we recommend just making a part that anyone can use [09:20] parts can be easily embedded into an snap at build time [09:21] the gnome platform snap is gnome-3-26-1604 right now (the name encodes the abi and base libs to make it easier to pick and choose) [09:21] fwiw [09:22] zyga, ok so i guess i should be looking into 'Sharing a C-level library' [09:22] wiking so, who would consume your library? [09:22] anybody who wants to use it? :) [09:23] snaps, unlike classic packages, typically don't model runtime dependencies as distinct packages for end-users [09:23] I'm almost certain that you want to make a part instead of a snap [09:23] oh i see [09:23] wiking you can ask kalikiana about parts [09:23] wiking you can maintain a part on a shared pool of parts (I forgot the name) [09:23] and anyone can build a snap that references your part by name [09:23] https://docs.snapcraft.io/build-snaps/parts [09:24] i guess [09:24] parts are like -dev or -devel packages in classic systems [09:24] yes [09:24] k [09:24] cool thnx for the quick support :) [09:24] welcome, enjoy snaps :-) [09:25] thnx [09:25] * ikey needs to assault jdstrand's mindbrain today [09:27] * zyga LOLs a little [09:41] ikey: are you trying to break everyone else's brain by using that weird term? :-P [09:41] kinda. xD [09:45] #4615 and #4633 are in need of 2nd review [09:45] PR #4615: overlord/snapstate/backend: perform cleanup if snap setup fails [09:45] PR #4633: snap: introduce timer service data types and validation [09:46] zyga: your blacklist checking code still has bugs i fear [09:46] yeah? [09:47] zyga: at least as I understand it [09:47] I implemented the thing we discussed last night, I'm adjusting tests to match [09:47] what's the bug? [09:47] zyga: should an entry of /foo stop a later entry of /foo/bar ? [09:47] if /foo is a file, no [09:47] if foo is a directory, yes [09:47] yes foo was a file iin this [09:47] why not? [09:48] I see what you are saying [09:48] technically it will just fail but it should be validated [09:48] hmm [09:48] but that's good, actually :) [09:48] it means validation gets easier [09:48] it's good that it'd fail, but my experience is the error is nicer if it's caught in a validation step [09:48] yep [09:48] zyga: does it? [09:48] thank you, I'll adjust [09:48] I think so [09:48] we'll see :) [09:49] you still don't want /foo to block /foolicious [09:49] sure [09:49] so for files it's "is this file a prefix of any complete prefix of this path" [09:49] where complete prefix is up to a / or o$ [09:50] or $* [09:50] * Chipaca is forgetting how to type [09:50] * Chipaca goes to see if coffee is the answer [09:54] * Son_Goku rises from the dead [09:57] hey hey [10:05] pstolowski: what do you mean with "that's what we do in undoMountSnap"? [10:05] pstolowski: backend.UndoSetupSnap _is_ undoMountSnap [10:06] unless that is exactly what you mean [10:06] (thus my original phrasing) [10:06] * Chipaca seems to be in an argument with himself [10:06] no i'm not [10:06] * Chipaca is too [10:08] Chipaca, I mean, undoMountSnap calls backend.UndoSetupSnap, which does backend.RemoveSnapFiles [10:09] pstolowski: yes [10:09] ah [10:09] pstolowski: now i understood [10:09] pstolowski: and feel dumb :-) [10:09] Chipaca, so, it's the same cleanup that mborzecki does on error [10:10] yes [10:10] pstolowski: I got confused there, sorry, all sorted now (for now!) [10:11] no worries, happens all the time here ;) [10:14] but there's a big difference [10:14] i'll comment on the PR [10:16] Chipaca: please do [10:17] Chipaca, good! you get my curiosity [10:19] good morning niemeyer [10:19] you're up early :) [10:20] zyga: can you give 4571 another pass? [10:20] mmm [10:20] reading [10:21] @: :-) [10:21] I know what it does but ... autotools :) [10:22] btw, I meant to ask [10:22] why do we need another configre.ac there? (in data0 [10:22] I never used a tree with more than one [10:22] could those things be rolled into the main one? [10:25] mborzecki ^ [10:27] zyga: with paths going from cmd to ../data? hm don't know if out of source tree builds with work this way [10:27] yeah [10:28] zyga: nvm, i can try that [10:28] I'll read on [10:31] mborzecki: they don't [10:32] mborzecki: I was wrong [10:34] mvo: RemainAfterExit=yes is interesting, ^C when systemctl start is waitig does not make the service exit, it keeps on working in the background, trying to start it again sort of hangs/hooks to the job that already runs [10:35] mborzecki: hm, so its not a solution for us? [10:35] mborzecki: can we please make this so that --libexecdir=/usr/libexec works like it's supposed to? [10:35] the only reason it doesn't currently is because of inconsistent implementations in makefiles/autofoo [10:36] mborzecki done [10:36] Son_Goku: have this in a separate branch now, quite a lot of changes, first i'd like to have autotools in data and then fix the libexec (would make the diff smaller also) [10:37] and please use pkgconfig stuff [10:37] it's already there since you've autotoolized it [10:37] no reason not to [10:39] my typing *and* my language (and probably my diction!) are shot to hell today [10:39] mvo: feels like this setting should be exposed in snap.yaml instead, it will change the behavior of the unit a bit, once started it sort-of remains 'active' until you stop it, meaning when ExecStart exits it's still considered active [10:39] mborzecki: still, +1, and maybe even good news :-) [10:41] Chipaca: btw. i recall there was a lp bug about snap try that failed would leave some stuff behind and remember going through this code once already ;) (although i didn't know that undo is only run if task was successful) [10:42] Chipaca she sells sea shells on the ... [10:44] zyga: she sells sea shells on the sea shore // mollusc moltings mostly make measly money // the lady later lacks lucre and leans on loans // she barters her business to barely bypass bankruptcy // turns out tacky tourist trinkets turn in ten times the take // she shelves t-shirts by the sea shore. [10:45] wow, I didn't know most of them [10:45] zyga: that's a newer take on the old one [10:45] must write down for at-the-pub fun [10:45] zyga: https://www.smbc-comics.com/comic/2014-07-23 [10:47] zyga: the original is making fun of a very early (and mostly ignored) paleontologist, https://en.wikipedia.org/wiki/Mary_Anning [10:48] it'd be so nice if gnome-shell didn't log an exception every 3 seconds :/ [10:48] better not press ctrl-c [10:48] it's like "red... no blue YAAAH" [10:49] heh, use log is full of this BS: https://paste.ubuntu.com/26540491/ [10:49] and it's not even the extensions [10:50] mborzecki: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887082 / [10:50] ? [10:52] Chipaca: yup, that's the one [11:01] PR snapd#4612 closed: snap: exclude `gettimeofday` from `snap run --strace` [11:25] mvo: i think we could run `systemctl start --no-block always`, if the unit files are bad (dependencies are wrong, format is incorrect) systemctl fails right away, and then we proceed to stop all the services in the cleanup phase [11:26] * pedronis lunch [11:29] mborzecki: this does sound good to me [11:30] mborzecki: mvo: is this --no-block + poll? [11:31] mvo: we may consider waiting for a while to see if they do not enter a failed state, but this sounds like a compication and the 'while' may be hard to agree on [11:32] Chipaca: --no-block, with optional poll to see if ActiveState is not 'failed' [11:32] mborzecki: a'ight [11:33] mborzecki, Chipaca: what kinds of "gurantees" do we currently get from systemctl start? my understanding is that its not that much anyway but should not regress here of course [11:34] mvo: it comes back when the exec of the thing succeeded [11:34] mvo: or when the thing notified it was up, if it's a notifier [11:34] mvo: or when it finishes running, if it's a oneshot [11:34] mvo: or or or [11:34] :-) [11:34] mvo: that's part of the problem :-) [11:35] /o\ [11:35] indeed [11:36] no-block + poll lets _us_ decide the vagaries (and makes cancelling cleaner) [12:04] Chipaca: mvo: if i'm reading systemctl source code right, without --no-block, there will be a wait set up, for each of the jobs that failed, if any of those failed systemctl exits with error status === verterok` is now known as verterok [12:45] PR snapd#4619 closed: tests/main/user-data-handling: get rid of ordering bug [12:51] Chipaca can you please have a 2nd look at 4636 [12:51] I implemented the thing we discussed last night [12:51] and you would be the perfect 2nd reviewer [12:57] zyga: i like it [12:57] zyga: i'll go deeper after the standup [12:57] thank you! [13:01] Chipaca: You coming? [13:03] niemeyer: nah [13:08] zyga, any ideas here? https://askubuntu.com/questions/1004203/installing-snapd-on-14-04-fails [13:09] yes [13:09] 3.13 [13:09] install snapd, reboot [13:09] it works [13:09] would now be a good moment to start freaking out because there's an ubuntu on its way to the asteroid belt [13:09] … and it's not going to be getting updates!!! /o\ [13:10] it's going to be _so_ rootkitted by the time it gets back [13:10] pesky space worms will eat it [13:11] zyga: https://i.imgur.com/vCrOo9e.gifv [13:16] ctrl-?meta-j29 [13:17] ups, ignore that [13:22] kyrofa I replied on the forum [13:31] * kalikiana going out for lunch, back later [13:39] mvo, hey [13:40] cachio_: hey [13:40] mvo, I see this error compiling snapd on bionic https://paste.ubuntu.com/26541162/ [13:40] mvo, any guess? [13:41] cachio_: hi, did you manage to start uploading some of those snaps that were missing in staging? [13:41] mvo oh btw, I didn't get that snap to work yesterday [13:41] pedronis, yes, the snaps are in the store [13:41] but it should be ok now [13:41] * pstolowski lunch [13:42] I noticed that the build got done but upload failed because of stale auth [13:42] cachio_: thx, I'll try again with the tests later today [13:42] pedronis, still working on some fixes [13:42] ok [13:43] zyga: what snap was that? [13:43] cachio_: let me know if I can help, also a couple we can just skip as discussed (lxd, canonical-livepatch and core transition) [13:43] cachio_: hm, I have not seen this yet [13:43] mvo the one you poked me about, snapd-hacker-toolbelt [13:43] zyga: #4606 could use your eyes [13:43] PR #4606: snap: use custom unsquashfsStderrWriter for unsquashfs error detection [13:43] zyga: aha, irght [13:43] zyga: right thanks [13:44] Chipaca sure, opened [13:44] cachio_: golang in bionic is on 1.9 now, maybe that is the problem, let me check [13:45] cachio_: hm, no, its like this for some time [13:45] niemeyer btw, I forced myself not to fullscreen any windows now [13:45] and I think I'm getting used to it [13:46] I can fit a few 1080p "big" windows easily and the habit of getting everything maximised is just that, a habit [13:46] cachio_: let me upgrade to bionic to test [13:47] mvo, nice, tx [13:47] pedronis, I uploaded 4 snaps [13:48] for amd64 and i386 [13:50] cachio_: hm, there was a new golang-1.9 upload during the night it seems [13:51] cachio_: so maybe/probably that is the reason [13:51] mvo, mmm [13:51] cachio_: but its a point release, should not break like this [13:51] "should" :) [13:52] anyway, once my upgrade is done I will know [13:52] mvo, btw I am using the cloud image that perhaps has some differences with yours installation [13:55] cachio_: I have a cloud image vm at hand too which I can try. I assume you did something like "sudo apt build-dep snapd" at some point, i.e. its not something like a missing pkgconfig or something like this (the error indicates its not) === chihchun_afk is now known as chihchun [13:57] mvo, I updated the prepare-project script to use the external backend to test bionic [13:58] mvo, I am using the same code we have to build in linode but in the external backend [13:59] cachio_: ok [13:59] ikey: hey, steam-support is not forgotten! I traveled last week to the snapcraft sprint and a couple of other things came up, but as of last night, steam-support is back on top of the list so planned on working on it today [13:59] ikey: sorry for the delay [14:00] yeah no worries bud, just figured id prod [14:00] hey jdstrand [14:00] it wasn't going to make 2.31 anyway, so still no issues with 2.32 [14:00] yeah figures [14:00] hey zyga :) [14:02] I'm working on hardening, I won't push anything major for you to review today though [14:02] zyga: cool (on both counts) [14:03] landing existing stuff is fun enough :) [14:03] it's getting quite close :) [14:05] zyga: let me double check with you. your changes to the content interface recently were a) only about the slot side and b) add a new 'source' attribute that has read and write lists under it, which may not be specified alongside the legacy read and write attributes. read and write legacy attributes are still supported [14:05] zyga: is that a good summary? [14:05] yes [14:05] that's accurate [14:06] (I phrased that slightly weird, source is alone, read/write may continue to be used instead of source) [14:06] ok cool [14:06] PR snapd#4639 opened: store: enable deltas for core devices too [14:06] so, the review-tools now understand this :) (not in prod yet) [14:06] woot, great [14:07] cachio_: I can reproduce the error [14:07] mvo, good [14:07] I looked at the PR and it was clear enough, I just wanted to double check since the updated docs aren't there yet [14:07] mvo, yesterday I was using a prebuilt core [14:07] but then I tried to run all in the bionic and I got that error [14:08] Chipaca replied [14:08] pedronis, I see this errror https://paste.ubuntu.com/26541264/ [14:08] but the weird part is that test-snapd-base-bare snap is uploaded in the staging store [14:09] cachio_: ah [14:09] * zyga returns to snapshots [14:10] cachio_, mwhudson it looks like 1.9.4 #cgo LDFLAGS whitelisting broke snap-seccomp [14:10] pedronis, not sure which could be the reason [14:10] * Chipaca hugs zyga [14:11] cachio_: I dont't see that snap [14:11] not in stable? [14:12] no, sorry, mistyped [14:12] cachio_: wondering if core is too old in that test [14:13] cachio_: test-snapd-base-bare seems to have the wrong type, it says application and not base [14:14] same in prod though [14:14] mmh [14:14] cachio_, mwhudson https://github.com/golang/go/issues/23672 is the issue, our ldflags -Wl,-Bstatic are not longer allowed [14:14] hmm [14:14] mvo are we in trouble? [14:14] zyga: a bit [14:15] a little bit or the grammatical bit where it's really a bucket full of trouible [14:15] mvo: any idea why base snaps would work with the production store, but not staging (I don't know what would be different) [14:15] *trouble [14:15] zyga: our static linking in snap-confine of libseecomp no longer works [14:15] hmmm hmmm [14:15] pedronis: work in the sense that snap install base-18 from staging does not work? [14:15] is that related to golang or to something else? [14:15] mvo: this https://paste.ubuntu.com/26541264/ [14:15] zyga: golang upstream change [14:15] from cachio_ [14:15] zyga: https://github.com/golang/go/issues/23672 [14:16] the base snap is there in staging, with the wrong type fwiw, but it has the wrong type also in production afaict [14:16] cachio_, pedronis is test-snapd-base-bare published in staging into the stable channel? [14:16] mvo hold on but snap-confine is in pure c [14:16] or did you meant snap-seccomp [14:16] zyga: sorry, snap-seccomp [14:16] ahh [14:16] ok [14:17] well [14:17] that sucks [14:17] mvo let me know if you want to discuss options [14:17] we could dlopen libseccomp from core perhaps [14:17] mvo, yes [14:17] (that would be good on a few levels, at least) [14:17] mvo, in staging for all the archs in all the channels [14:18] cachio_: what snapd version is in use there, I suppose master? [14:18] pedronis, yes [14:18] zyga: I need to think a little bit about it, but it sucks [14:19] cachio_: I can try as well in a little bit, not sure what would be different in staging though [14:21] pedronis, it is weird because I can install test-snapd-base-bare [14:22] in the staging store [14:22] but if it used as base snap it cannot be found [14:23] cachio_: quite confusing [14:24] kyrofa: hi! weird: kernel: [1304675.438833] audit: type=1400 audit(1518072222.273:174): apparmor="DENIED" operation="exec" profile="snap.nextcloud.mysql" name="/bin/systemctl" pid=19425 comm="mysql.server" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 [14:25] kyrofa: I think it is falling back though, since I see: nextcloud.mysql[19403]: Shutting down MySQL [14:25] nextcloud.mysql[19403]: .. * [14:25] systemd[1]: Stopped Service for snap application nextcloud.mysql. [14:26] mvo: zyga: moving each -Wl into separate line does not help I guess? [14:26] mborzecki: I can try, I think its a whitelist [14:27] right: there's a review for --as-needed https://go-review.googlesource.com/c/go/+/92795 [14:28] mvo: and thre are environment variables too [14:28] mvo: https://go.googlesource.com/go/+/867fb18b6d5bc73266b68c9a695558a04e060a8a [14:29] this piece in particular: https://go.googlesource.com/go/+/867fb18b6d5bc73266b68c9a695558a04e060a8a%5E%21/#F3 [14:34] zyga: tried this in the autotools branch https://paste.ubuntu.com/26541368/ automake went down with some bs error, clearly confused about the relative paths [14:34] uh [14:35] mborzecki what if we moved those upstairs [14:35] that would work, right? [14:35] that would work, but it will also clutter the toplevel dir [14:35] is there a list of env vars available for use in snippits in snapcraft? (not for snaps themselves) [14:35] sure [14:36] Chipaca I added a review to snapshots (half of review really) [14:37] zyga: otoh, it's 3 files at most that need to be kept in the tree -> configure.ac, Makefile.am, autogen.sh, the rest is just temporary artifacts [14:37] yeah [14:37] maybe that's the solution [14:38] mborzecki so [14:38] mborzecki another idea [14:39] how about if we add .dot-dot symlink [14:39] and make data show up as cmd/.dot-dot/data [14:39] :D [14:40] hmm might work, let me try [14:41] looking at 4606 now [14:46] mvo: by the looks of it, the arch package does not build due to the go changes atm [14:49] right, pkg-config is broken now too [14:52] go build github.com/snapcore/snapd/cmd/snap-seccomp: invalid pkg-config package name: --static [14:53] zyga: can you take a look at https://github.com/bboozzoo/aur-snapd/pull/3 ? [14:53] PR bboozzoo/aur-snapd#3: snapd: updates [14:53] Issue snapcraft#1921 opened: Evaluate contents of manifest.txt, add reasons and surface to the user during staging [14:53] yes [14:53] i'll push another fix with a workaround for go1.9.4 in a minute [14:57] mborzecki done [14:58] zyga: thanks [15:03] Chipaca +1 [15:03] PR snapd#4606 closed: snap: use custom unsquashfsStderrWriter for unsquashfs error detection