[00:47] PR snapcraft#2162 closed: tests: new codespell, narrowed checks and better execution order [02:27] Is it possible to remove old revisions from the store? [02:49] zyga: https://flocktofedora.org/#cfp [05:03] morning [05:24] PR snapd#5346 opened: cmd/snap: add a backup handler for snap:// URIs that prompts the user to install the gnome-software snap [06:09] hey [06:09] irccloud is down, hmm [06:13] zyga: heh, looks like it [06:13] ok, let me push those suse PRs [06:20] oh, drat [06:20] master has even better integration [06:20] let me take some of that too [06:21] I wish the snapd.apparmor.service was in 2.33 :/ [06:26] zyga: can't you backport it? [06:26] yeah, that's what I'm looking at now [06:26] it's not a large change [06:27] I'm building 2.33 as is to see what it lacks from the packaging in master [06:37] I don't love cherry picking our patches when they are not squashed [06:38] I guess I can branch off 2.33 and cherry pick the lot [06:38] then squash and export [06:38] right? [06:39] tumbleweed is on 4.17, [06:39] that's ... fast :) [06:50] zyga: 4.17.2-1-ARCH [06:50] probably fedora too [06:53] ok, patches prepared, one more build [06:55] Pharaoh_Atem I need to thank you for the fantastic rework of the opensuse package! [06:55] it makes things much easier [06:58] zyga: did you get a chance to look at #5341 ? [06:58] the C changes? [06:58] PR #5341: cmd/libsnap-confine-private: intoduce helpers for validating snap instance name and instance key [06:58] zyga: yup [06:59] not in detail, [06:59] probably good if jdstrand could take a look too when he comes back [07:00] btw. if nobody minds i'll be landing #5314 soon [07:00] PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs === pstolowski|afk is now known as pstolowski [07:04] mornings [07:04] pstolowski hey [07:04] mborzecki I asked one question on the validate PR [07:05] https://pastebin.ubuntu.com/p/y3kjK4zXGS/ <- rpmlint report so far [07:06] hey pstolowski ! good morning [07:06] zyga: not sure i follow, the pr splits instance name to snap name and instance key and validates both already [07:06] mvo, mborzecki any new developments re snapd.seeded service issue? you haven't forwarded me those emails, have you? [07:06] yes but you _already_ have a function for splitting it [07:10] zyga: right but that code is supposed to work with validated input and dies instead of returning nice errors, i could probably rework it to use sc_error [07:10] ah [07:10] zyga: it will die if sc_error is unset right? [07:11] this makes sense [07:11] yes [07:11] sc_error was designed so that errors are either propagated or the program dies [07:11] zyga: i can look into it [07:12] mvo: do yu have any high priority pending PRs that use info.Name() that would conflict if i merge #5314? [07:12] PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs [07:13] mborzecki btw, I want to simplify sc_error [07:13] mborzecki: nothing with priority, feel free to land this [07:13] I wrote some personal code and I evolved (simplfied) error handling a bit [07:14] mvo: ack [07:14] we could talk about this on Friday [07:15] PR snapd#5314 closed: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs [07:15] [ 43s] FAIL: booted_test.go:218: bootedSuite.TestUpdateBootRevisionsOSErrorsLate [07:15] [ 43s] [07:15] [ 43s] booted_test.go:253: [07:15] [ 43s] c.Assert(chg.IsReady(), Equals, true) [07:15] [ 43s] ... obtained bool = false [07:15] [ 43s] ... expected bool = true [07:15] random test failures are best [07:16] zyga: does it fail when ran isolated? [07:16] it didn't fail for the last N runs I did [07:16] I'm only tweaking linter errors so it's just random [07:16] I didn't try isolated yet [07:16] zyga: trid go test -c -o foo.test && while true; ./foo.test -check.f || break; done ? [07:17] mvo: do you have the log from snapd.seeded failure? (or is pstolowski already looking into it) [07:21] mborzecki: https://pastebin.canonical.com/p/thJBrCX4wr/ ; i haven't looked at it yet but about to, mvo has some more info in emails, looking forward to them [07:21] mborzecki: pstolowski said he will look into it last night, I can mail the logs to both of you [07:22] pstolowski: I sent the mail a bit earlier is it not there yet? [07:22] mvo: nope, no emails [07:23] most lint errors are gone now [07:23] just a few more.. [07:26] mvo: pstolowski: looks like snapd.seeded could use Requires=snapd.socket at least [07:27] indeed [07:29] mborzecki, pstolowski sent it to both of you again [07:32] PR snapd#5347 opened: data: remove /bin/sh from snapd.sh [07:36] mborzecki: did you get the mail? [07:36] mvo: yup, got it [07:36] mvo: thanks! [07:37] mborzecki: thank you, interessting, pstolowski did not get it, we were wondering if my fastmail provider has a problem but apparently its more complicated :/ [07:37] interesting :) [07:37] mvo: yeah, got a nice fat warning from gmail about possible spoof [07:38] mvo: similar to a name in your organization but the email address does not belong to your domain or the email is not authenticated. Avoid clicking links or replying with sensitive information unless you reach out to the sender by another means to ensure that this email is legitimate [07:42] mvo: so yes looks like Requires=.. will do it, but i'd test it; how do i play with seeding? [07:43] hm i'm wondering if there could some unwanted side effect [07:43] pstolowski: mvo: maybe we should have Restart=on-failure too? [07:44] mborzecki: yeah, that sounds reasonable [07:44] mborzecki: restart on failure [07:52] allright i see some spread tests for seeding [07:52] hmm got 14% of battery left, need to find a power outlet [07:57] mvo, mborzecki okay, i'll try to amend existing spread tests to reproduce and then will apply the above plan [07:58] pstolowski: sounds good [07:58] pstolowski: \o/ [08:01] PR snapd#5348 opened: packaging/opensuse: snap-confine should be 06755 [08:11] mvo: ok, the problem reproduces nicely with just examining systemctl snapd.seeded service status in existing spread test, onto fix now [08:12] pstolowski: yay, thank you [08:12] pstolowski: I will pull that into 2.33.1 [08:12] ok [08:12] ok, i'm moving back home, bbiab [08:14] PR snapd#5349 opened: packaging/opensuse: add missing bits for snapd.seeded.service [08:15] mvo: pstolowski: which problem? [08:16] Chipaca: https://pastebin.canonical.com/p/thJBrCX4wr/ [08:16] Chipaca: snapd.seeded service not waiting for snapd.socket [08:17] pstolowski: it should wait for snapd.service I'd think [08:17] unless that creates a loop [08:22] PR snapd#5350 opened: packaging/opensuse: don't use %-macros in comments [08:23] Chipaca hey sir [08:23] quick question [08:23] $(reverse complete.sh) needs to be executable, correct? [08:23] PR snapd#5351 opened: packaging/opensuse: build position-independent binaries [08:25] zyga: hmm... let me remember [08:26] zyga: it doesn't need to afaik [08:26] it is on ubuntu [08:26] it isn't on opensuse [08:26] shall I unify some way? [08:27] zyga: we run essentially 'bash etelpmoc.sh' [08:27] and it is in the tree [08:30] zyga: if you have the 'http' snap installed, and you run: snap run --command=complete http 9 9 6 1 ' ' "http -" http - [08:30] zyga: if that prints a bunch of stuff, it works :) [08:30] (by a bunch of stuff i mean a list of options) [08:31] yes, it works [08:31] ok, I'll remove the +x bit then [08:31] zyga: er [08:31] hm? [08:31] zyga: note it's the one in the core you want to tweak [08:31] oh [08:31] bummer [08:31] :) [08:32] that's more work ;) [08:33] Chipaca ok, that works too [08:34] zyga: also it's rev << $(rev << clearly [08:35] PR snapd#5270 closed: snap,client: show "publisher" in `snap list` and expose in client API [08:35] PR snapd#5352 opened: many: expose full publisher info of the snapd api [08:37] hah! in github the way you tell it utf is ok is with 'utf8=✓' [08:38] Chipaca: hi, 5352 follows your suggestion about expanding publisher in the snapd API to the same object as the v2 store API [08:38] pedronis: reviewing it already [08:38] (toggled whitespace to see the struct diffs properly which is when i noticed the utf8=✓ thing) [08:39] PR snapd#5353 opened: data/completion: remove shebang and +x from etelpmoc.sh [08:41] pedronis: had we agreed on changing the column name in list? [08:41] pedronis: (that's a bigger 'we' than you and me) [08:43] Chipaca: for publisher instead of developer? I think we did [08:43] mvo: schweet [08:53] PR snapd#5354 opened: packaging/opensuse: ship apparmor integration if enabled === chihchun_afk is now known as chihchun [08:57] https://code.facebook.com/posts/605721433136474/accelerate-large-scale-applications-with-bolt/ is interesting === zyga_ is now known as zyga [09:05] Chipaca: I pushed the opposite approach, we should also perhaps look at those shellcheck warnings I posed [09:05] nothing there screams critical though [09:05] I will address those separately [09:06] zyga: sure. be careful though :) [09:09] Chipaca: answered some of your comments [09:10] Chipaca: also do you really meant adding output related code to the client pkg? that feels strange [09:12] PR snapd#5355 opened: data/complete: fix three out of four shellcheck warnings in data/complete [09:12] Chipaca: I decided not to touch that last one [09:12] feel free to do so [09:12] my bash is not that fantastic to do it comfortably [09:14] Chipaca: also I notice that client/packages.go imports snap nowadays, do you know what's the expected boundary? I could move to shared snap.StoreAccount under you unflatten request [09:14] *your [09:15] re [09:15] 2018-06-20 09:13:55 Cannot allocate google:arch-linux-64: cannot allocate new Google server for arch-linux-64: quota 'IN_USE_ADDRESSES' exceeded. Limit: 575.0 in region us-east1. [09:15] google hates us todaty [09:16] or just me [09:16] ayy [09:16] mmh [09:16] ETOOMANYIPV4ADDRESSESWHATWEREYOUTHINKING [09:16] do we have machines left over [09:16] something not cleaning up the machines? [09:17] zyga: to be fair you created a tons of small PRs it seems [09:17] or perhaps the many small PRs consumed too much [09:17] yeah, I think that's it [09:17] let's wait for this to settle in ~20 mintues [09:18] like another round and we are in review sprint territory [09:20] mborzecki: https://github.com/snapcore/snapd/pull/5342 can be merged now [09:20] PR #5342: tests: shellchecks part 4 [09:20] pedronis: I'm +1 for shared, but gustavo has sometimes objected to it [09:20] I hope my small packaging fixes can mostly land very fast [09:21] pedronis: but I think we're moving towards mostly-shared, see snapshots for example [09:21] PR snapd#5342 closed: tests: shellchecks part 4 [09:21] mborzecki: when is the cutover for your shellchecks work? [09:22] mborzecki: by this i mean, when would an 'exceptions' list be shorter than a 'must' list :) [09:22] Chipaca: i think we're at ~40% [09:23] i'll open another batch today [09:23] Chipaca: ok, I kept it flat because is flat atm, and also there would be more churn but I can do that if you feel it's better [09:23] Chipaca: did you see my questions/comment on ForTerminal ? [09:24] pedronis: I did not [09:24] got the gas inspector in, got a little sidetracked [09:29] Chipaca: also if it's snap.StoreAccount it seems even a worse place for ForTerminal, I think we'll have a function with flags or functions in cmd/snap itself instead [09:29] mborzecki: if you want you can review your/our go-check PR, I tweaked it a little bit to address the concerns that gustavo had and I think its quite nice now [09:30] pedronis: ok [09:33] mvo: i see you've pushed the fix for basic types [09:33] nice [09:34] mborzecki: we need a 'basic types starter pack' meme now [09:34] mborzecki: yeah, I think/hope its good now [09:35] mborzecki: it still has the properties we want, i.e. big structs/long strings are nicely diffed [09:35] https://github.com/snapcore/snapd/pull/5350 is green and trivial, please review [09:35] PR #5350: packaging/opensuse: don't use %-macros in comments [09:35] mborzecki: if it looks good to you I will ask gustavo (either here or in the standup) for a quick look [09:36] https://github.com/snapcore/snapd/pull/5347 is in the same spot [09:36] PR #5347: data: remove /bin/sh from snapd.sh [09:37] mvo: trivial action on https://github.com/snapcore/snapd/pull/5331 [09:37] PR #5331: snapstate: sort "snapd" first [09:40] zyga: thanks, will do [09:42] PR snapd#5356 opened: packaging: require snapd.socket in snapd.seeded.service; make sure snapd.seeded.… [09:42] mvo, mborzecki ^ [09:43] btw, systemd didn't like Restart=on-failure, perhaps because it can't be combined with oneshot? [09:45] pstolowski: silly question, why is the after=snapd.socket not enough? [09:49] mvo: that's a little bit vague, see https://serverfault.com/questions/812584/in-systemd-whats-the-difference-between-after-and-requires [09:49] mvo: after is just ordering, if both seeded.service and snapd.socker are started together, seeded will be ordered after [09:49] "After= configures service order (do X only after Y), while Requires= state dependencies. If you don't specify an order, a service depending on another would be started at the same time as the one it is depending on" [09:49] but if you start seeded.service and socket is not active then it will not be started [09:50] "After= is a "loose coupling" [09:53] zyga: should your rpm stuff go into 2.33.1 as well? [09:53] pstolowski: right, it may nee to be one of the 'daemon' modes [09:54] well, the packaging/ directory can be master only [09:54] there are a few things we could cherry pick once everything lands [09:54] but I have patches in the tree so not a hard requirement [09:54] I'm happy if they land in master only [09:55] mborzecki, pstolowski thanks, I guess I'm missing something. if snapd.seeded is ordered after snapd.socket (which it currently is afaiui) then when snapd.seeded runs it should simply socket activate on snap system-info snapd. or are sockets and services started by systemd in different "runs" ? [09:55] mvo: thank you for the reviews! [09:55] https://github.com/snapcore/snapd/pull/5349 needs a 2nd review now [09:55] PR #5349: packaging/opensuse: add missing bits for snapd.seeded.service [09:55] (green and ready) [09:55] mborzecki, pedronis I guess my question is "why are snapd.seeded, snapd.socket" not started togehter :) [09:56] PR snapd#5350 closed: packaging/opensuse: don't use %-macros in comments [09:56] mborzecki, pstolowski is it because of the different "WantedBy"? [09:57] mborzecki, pstolowski sorry for the questions, just trying to understand the why behind it [09:57] mvo: my guess is that the seeded target is ordered independenly of the sockets target [09:58] mborzecki: yeah, I think that makes sense. I would have assumed socket targets run before the normal multi-user though. but its the best theory so far :) [09:58] as an experiment we could make snapd.seeded wantedby socket.target to see if that also solves the issue [09:58] mvo: or make snapd.socket wanted by seeded target [10:00] i can experiment with that [10:00] why wanted by and not before/after? [10:01] also note wantedby and requires do not imply before/after [10:01] fwtw the spread tests are happy after requires= fix [10:01] so i guess you need both [10:01] requires= and after= [10:01] or wantedby= and before= [10:01] Chipaca: atm (with my PR) we have after= and requires=, yes [10:01] (probably the former) [10:02] good === chihchun is now known as chihchun_afk [10:06] pstolowski: hi, btw can your disconnect hooks PR be re-reviewed? [10:06] pedronis: not really, there is a spread test failure that may be related to conflict-checks change [10:08] ok, ping me when you think I should look again [10:09] pedronis: but if you could take a look at https://github.com/snapcore/snapd/pull/5323 that would be great [10:09] PR #5323: ifacestate: prevent running interface hooks twice when self-connecting on autoconnect [10:13] mvo: updated https://github.com/snapcore/snapd/pull/5353 -- I also re-worded the branch description to match the final state [10:13] PR #5353: data/completion: fix inconsistency in +x and shebang [10:18] mborzecki: can you have a quick look at https://github.com/snapcore/snapd/pull/5349 [10:18] PR #5349: packaging/opensuse: add missing bits for snapd.seeded.service [10:18] I noticed we hit a GCE quota limit for IN_USE_ADDRESSES [10:21] likely due to the number of PRs in flight [10:21] PR snapd#5349 closed: packaging/opensuse: add missing bits for snapd.seeded.service [10:21] we discussed that above with pedronis a moment ago [10:22] oh wow that's a massive failure https://api.travis-ci.org/v3/job/394476948/log.txt [10:23] cannot allocate new Google server for ubuntu-16.04-32: quota 'IN_USE_ADDRESSES' exceeded. Limit: 575.0 in region us-east1 [10:23] etc. [10:25] ah that's what you discussed above [10:25] mborzecki: thank you for the idea, https://github.com/snapcore/snapd/pull/5347 is now a one-liner [10:25] PR #5347: data: remove /bin/sh from snapd.sh [10:29] pstolowski: will look at that after lunch [10:29] thx [10:32] mborzecki: https://github.com/snapcore/snapd/pull/5341#pullrequestreview-130331441 is reviewed :) [10:32] PR #5341: cmd/libsnap-confine-private: intoduce helpers for validating snap instance name and instance key [10:33] zyga: thanks! [10:35] mborzecki: for your shellcheck work, what do you think of listing the spread tests that are allowed to fail rather than the ones that are required to pass? [10:36] mborzecki: I ask, because I've added new spread tests in some of my branches that failed shellcheck and didn't error out because they weren't listed in the "must" file [10:37] what's the default terminal on kubuntu, xubuntu, lubuntu, mate? <- popey? [10:37] jamesh: hm something to consider, looks like an easy change [10:37] uh [10:37] konsole, dunno about the others [10:37] mborzecki: it seems like a check that new tests should be required to pass [10:38] popey: do you have a konsole handy? (as in already installed, at your fingertips) [10:38] yes [10:38] popey: could you run http://paste.ubuntu.com/p/WkK7GSvhfC/ ? [10:38] jamesh: yes, that would be helpful, i could stop reminding people to add their files to must-pass list [10:39] mborzecki: it would also make it easier to tell when the job was finished: you'd have an empty file listing the tests allowed to fail. [10:41] PR snapd#5357 opened: firstboot: mark essential snaps as "Required" in the state [10:42] https://usercontent.irccloud-cdn.com/file/DtIIptAt/Screenshot_20180620_114053.png [10:42] @Chipaca ^ [10:42] zyga: what's the easiest way for a machead to run a core image? [10:42] machead? [10:42] zyga: person with a mac and no ubuntu [10:42] aaah [10:42] popey: what [10:42] Mac head [10:43] :D [10:43] lol, sorry, I didn't parse that at first [10:43] Chipaca: screenshot above [10:43] well, those raspberry pi's, Mac-heads love to buy stuff I suspect ;) [10:43] popey: no i mean what happened to the utf8 [10:43] no clue [10:44] Chipaca: more seriously, if you need a VM there are several popular choices [10:44] VMware fusion, maybe parallels (but I didn't use it and it's a subscription now so bleh) [10:44] popey: all those should be «[…] Green ☑✅✓✔🗸🗹» [10:45] my bad [10:45] kinkpad ;) [10:45] kde thinkpad -> kinkpad :) [10:45] kinky [10:46] https://usercontent.irccloud-cdn.com/file/hCiOpnNQ/Screenshot_20180620_114603.png [10:46] better [10:46] thank you [10:46] popey: 18.04? [10:46] sorry, i used the raw text from the pastebin, which was my error [10:46] 16.04 [10:46] kde neon [10:46] popey: ok [10:47] popey: and those strings are now the right utf8 thing, in that order? [10:48] i copypasted from the pastebin, so should be as you wrote them [10:48] IOW konsole in 16.04 renders ☑ and ✅ the same? [10:48] emoji support is much later [10:48] so that's expected [10:48] yeah, i dont think I've fiddled much with the fonts or anything [10:49] is cachio around today [10:49]