[01:48] PR snapd#7364 opened: overlord/snapstate: add migration function to fix invalid channel spec [03:08] PR snapcraft#2662 closed: windows installer [06:07] good morning [06:29] good morning pedronis === pstolowski|afk is now known as pstolowski [07:01] morning [07:06] good morning pawel, mvo [07:07] hey zyga and pstolowski [07:09] mvo: hey, i'm applaying yours & John suggestions to the snap switch PR; interestingly, snap revert op test is explicitily expecting the "..forwarding" message. wrong test? [07:09] mvo: hi, tests/main/install has a weird name, it's really install-fontconfig-cache [07:10] I noticed because it apparently confused Ian [07:11] flock nil pointer failure https://www.irccloud.com/pastebin/W7rNxA82/ [07:11] I'll check that out after breakfast [07:11] mvo: anyway, I'm looking/tweaking Ian PRs [07:12] pedronis: yes, sorry for that [07:12] pedronis: cool, thanks [07:12] pstolowski: interessting, maybe it does make sense for revert? worth checking with john when he is around [07:13] pstolowski: but I think john is right, I was overdoing it a bit in my pastebin suggestion. the unit test might be useful hopefully [07:16] PR snapd#7360 closed: snap: use deterministic paths to find the built deb [07:16] mvo: yep, i'll apply your 'equals' test tweak, ty [07:17] pedronis: 7313 LGTM, do you want to wait for john before merging or is that good? [07:25] mvo: I would wait for John to give a look [07:26] ta [07:41] mvo: #7359 can be reviewed, and hopefully the spread tests are right now [07:41] PR #7359: overlord/snapstate: check channel names on install [07:43] pedronis: great, I have a look now [07:51] pedronis: thank you! [07:53] pedronis: about 7364, whats your feeling, should we do it this way or via a patch? [07:58] mvo: not sure at all, apparently the store is very very liberal [07:58] (which I don't remember it being) [08:00] pedronis: I see, hm, hm [08:00] * mvo scratches head [08:00] mvo: you can send this: ////18/////stable///// [08:01] pedronis: meh, "fun" [08:02] zyga: bad news, "main/mount-ns" failed on master [08:02] oh, can you show me how? [08:02] zyga: in the ubuntu-18.04-64 tests [08:02] zyga: sure, one sec, let me paste the relevant bits [08:03] do you have a log or was it locally? [08:03] zyga: its master [08:03] zyga: https://travis-ci.org/snapcore/snapd/jobs/577710067 [08:03] zyga: https://paste.ubuntu.com/p/wjvW4PrkDk/ [08:04] hmmm [08:04] I see it [08:04] it seems LXD test fixes were not enough somehow [08:04] one moment [08:05] oh [08:05] lxd didn't run in that set!? [08:05] zyga: I don't know, I have not looked deeper yet [08:08] mvo: do you have powers to create a track for test-snapd-tools snap in the store (for the new spread tests i'm preparing)? [08:08] pstolowski: I think only the store can do this [08:08] pstolowski: the formal process is to ask in the forum but given that its a test snap hopefully this is a quick one [08:10] pedronis: I was leaning slightly towards a patch before because it means less things to worry about in snapstate and because its a one-off thing. but no super strong opinion [08:10] mvo: we need to chat I think [08:11] also with John when he's around [08:15] pedronis: ok, I have a meeting in 45min but time until then [08:17] mvo: got it, thanks [08:31] mvo: Chipaca: hi, let me know when we can chat about /stable [08:32] * Chipaca doesn't like stables [08:37] pedronis, Chipaca ready when you are, I'm looking at this firstboot_test.go unit test failure we see sometimes [08:37] mvo: that's fixed one of my PRs [08:37] if it's the MissingBase one [08:38] pedronis: aha, nice. looking [08:38] mvo: Chipaca: going to the standup HO [08:38] i'll be there in a minute [08:39] mvo: i'm gonna request track "2.0" for test-snapd-tools, any objections / suggestions? [08:39] pedronis: I'm there now - did you fix the issue by using better helpers? or was there someting deeper [08:59] PR snapd#7365 opened: tests: spread test for snap refresh/switch channel and risk switching [09:35] Chipaca: we forgot to mention, this is relevant as well: https://github.com/snapcore/snapd/pull/7359 [09:35] PR #7359: overlord/snapstate: check channel names on install [09:39] pedronis: I was just noticing that the path to install lets you get nasty channels into state no problem, only showDone prints the error (once it's too late to abort) [09:39] same for refresh i think [09:40] ugh, 60kB/s download :-( [09:40] Chipaca: with that code it shouldn't be the case [09:41] Chipaca: anyway, sorry I didn't mention it, but it needs a review, be built on top [09:41] to print the warning and continue the check needs to be done way earlier than snapstate [09:49] Chipaca: yes, but snapstate needs to fail if it gets something not normalized [09:49] Chipaca: to print a warning we need to do this ins cmd_snap_op, no? [09:50] yep [09:56] mvo: I have an idea [09:56] checking it onw [09:56] *now [10:03] hmm [10:03] cannot build spread? [10:03] cmd/humbox/main.go:170:39: m.HTTPHandler undefined (type autocert.Manager has no field or method HTTPHandler) [10:05] zyga: spread and snapd have different deps [10:05] should I use separate GOPATH for each thing>? [10:07] probably [10:07] zyga: snapd shouldn't need anything from gopath right now though [10:07] zyga: you might have some old deps in there :) [10:08] thanks, let me look [10:10] pedronis: the SeedMissingBase test failure is understood now, s.makeAssertedSnap() makes a local_1.0.snap and snaptest.MakeTestSnapWithFiles() also makes one. but what is signed/used is inconsistent so sometimes (when the second rolls over) the two get out of sync because the second is stored in the squashfs header [10:11] mvo: ah [10:11] mvo: wow [10:11] nice [10:13] zyga: predronis fixed all of this afaict in his refactor [10:34] pedronis: given that 7341 is mostly shuffling things around, should we be ok with a single review? I would love to move forward with 7345 [10:35] pedronis: 7341 probably needs a master merge to get green [10:36] pedronis: also 7067 seems to be super close, we could do the comments in a followup [10:38] PR snapd#7347 closed: gadget: do not error on gadget refreshes with multiple volumes [10:39] huh, #7345 was quite a beast [10:39] PR #7345: overlord/devicestate,seed: small step, introduce seed.LoadAssertions and use it from firstboot [10:42] PR snapd#7366 opened: interfaces/gpg-keys: Allow access to gpg-agent and creation of lockfiles [10:43] uhgh [10:43] as soon as I'm done with current stuff I'm looking at xdg-portal-filechooser [10:43] I restarted that like 20 times [10:43] today [10:43] is that even possible, not sure :? [10:46] pstolowski: its based on another pr [10:47] mvo: allright, i reviewed the entire thing then [10:50] mvo: I reproduced the bug [10:50] mvo: it's super surprising!!! [10:50] mvo: it's not any other test [10:50] mvo: it's just REBOOT [10:50] mvo: spread somwhow gets different behavior on 2nd boot [10:50] mvo: on 1st boot the mount table is different than later on [10:51] mvo: I think that's because project-prepare doesn't run after reboot [10:51] mvo: I'll check that [10:51] mvo: I think because pstolowski reviewed all of 7345 7341 got two reviews now [10:51] mvo: so I'll merge master into it, try to address your comments and it can land [10:51] +1 [10:56] pedronis: thank you! [11:01] PR snapd#7367 opened: snap, cmd/snap: support (but warn) using deprecated multi-slash channel [11:01] pedronis, mvo, please let me know if this is what you had in mind: ^^^ [11:11] Chipaca: yessish, but is it missing tests? [11:11] I mean I cannot tell it does what is supposed to from the test in cmd_snap_op_test.go [11:12] mvo: fun: E: Failed to fetch http://apt.postgresql.org/pub/repos/apt/dists/xenial-pgdg/main/binary-amd64/Packages.bz2 Hash Sum mismatch [11:15] pedronis: meh, not again [11:33] mvo: question to #7336 [11:33] PR #7336: tests: add debug section to interfaces-contacts-service [11:40] brb [11:49] mvo: and I now understand the origin of the failure as well [11:49] well, that's that :) [11:49] mvo: the origin is that on ubuntu we remove lxd on project prepare [11:49] but since it had executed it left behind its stale state [11:52] mvo: I'll collect some tangible proof for the commit message and have a solution shortly === ricab is now known as ricab|lunch [12:16] PR core18#138 opened: Use snapcraft's now-non-default destructive mode for building on travis [12:17] pedronis: ah, i started writing a unit test but then realised it was almost the same as an existing one so i modded that, but maybe it's not super clear [12:18] Chipaca: it's not clear at all, I expected the reverse [12:18] also a test about this would have /stable in it, no? [12:18] pedronis: the reverse to what? [12:18] Chipaca: turning /stable => latest/stable [12:18] not turning stable into stable [12:21] cachio: re 7361, what about apt-hooks? [12:22] pstolowski, hi, yes, testing this right now [12:23] cachio: ah, ok, no worries, i wasn't sure if you saw the question in the PR [12:23] pstolowski, yes, I am also testing another test which failed [12:23] I'll push that in a momento [12:23] Chipaca: no, I'm not going silly, the warning code in cmd_snap_op is not exercised [12:24] at all [12:24] pedronis: ah! hm. I'll fix that. [12:24] i was talking about the code in snap :-) [12:25] Chipaca: no, I was talking about the code in cmd_snap_op [12:25] anyway travis is not with us today [12:34] zyga: ta [12:57] * ijohnson pours one out for travis [12:57] morning folks [12:57] hey ijohnson [12:57] PR snapcraft#2691 opened: travis: use apt addon to prevent apt update issues [12:57] hey pstolowski [13:01] hey I see this unit test failure on travis but not locally, anybody else seen this? https://pastebin.ubuntu.com/p/SHm3dWhgNP/ [13:01] pedronis: pushed unit test for that [13:02] ijohnson: fixed in one of pedronis prs [13:06] PR snapcraft#2689 closed: schema: build-base support for the snapd type [13:21] snap install http --channel=$(printf "/%.0s" {1..65527})stable$(printf "/%.0s" {1..65527}) [13:23] Chipaca: you are having fun? [13:25] PR core18#138 closed: Use snapcraft's now-non-default destructive mode for building on travis [13:35] mvo: I hit the limit of my shell before I hit any other limit :-) [13:35] also my patience [13:37] pedronis: can I push a shellcheck fix to #7359 ? [13:37] PR #7359: overlord/snapstate: check channel names on install [13:37] ijohnson: yes [13:37] ack, one moment [13:37] Chipaca: that's probably for you to review ^ (I touched it too much to do a review myself at this point) [13:38] mvo: Chipaca: all the PRs in play are now marked 2.41 === ricab|lunch is now known as ricab [13:39] pedronis: thank you [13:44] mvo, are you promoting to beta today right? [13:45] cachio: that was my plan but it seems like we have too much pending in the 2.41, I want to merge them all before I push a new version [13:45] cachio: so more likely tomorrow [13:52] mvo, good [13:52] mvo, thanks for the news [14:11] PR snapd#7368 opened: cmd/snap,image,seed: move image.ValidateSeed to seed.ValidateFromYaml [15:03] zyga, hey, #7256 updated [15:03] PR #7256: tests: adding retry command and use it to delete $XDG directory [15:04] pedronis: can you +1 my request https://forum.snapcraft.io/t/track-request-2-0-for-test-snapd-tools/12965/2 ? [15:05] zyga, tested on py2 and 3 [15:05] * cachio lunch [15:06] thanks pedronis and roadmr ! [15:07] ;) [15:11] cachio: thank you, I'll review it soon [15:20] pstolowski: your track is ready 💯 [15:30] mvo: cachio did you guys have a chance to see if that snapd I built was correct? [15:31] mvo: can you give a nod on my PR if possible to merge and tag a release? [15:34] roadmr: thank you! [15:34] now i need someone to push something there [15:35] mvo: do you have rights to push test-snapd-snap to the new track? [15:40] ijohnson: i think your patch pr would be cleaner if it built on my pr [15:40] ijohnson: but we're targetting different things :-/ [15:40] this'll be fun :-) [15:41] Chipaca: ok, I'll hold off on doing anything more to my patch PR until yours is ready, I am about to leave for the airport in ~20 minutes, so I probably won't be able to do much yet today [15:41] ijohnson: i might merge the two into a pr that targets 2.41 [15:42] Chipaca: that's fine with me [15:42] similarly i can take your snapstate pr about this, stack it on the deprecation one, and add a check for that in there, again targeting 2.41 [15:43] i'll be taking a break before i delve into that though :-) [15:47] Chipaca: sorry, I'm confused, I thought in the end we wante to turn /stable into latest/stable [15:48] becauses stable means just switch risk atm [15:50] pedronis: hmm, if that was what we wanted, then I might need to take steps :-) [15:50] pedronis: before we were using one and printing the other, which was wrong [15:50] that's why I asked [15:51] * ijohnson is quite confused about what /stable is supposed to be turned into and when [15:51] pedronis: the code that does mx.Channel = ch.Name would be wrong though [15:52] yes [15:52] ijohnson: quite [15:52] ijohnson: the issue is that Channel in states are actual channel, the channel on the command line are intentions [15:52] pstolowski: I think so, what snap what track? I can also make you contributor then you can also do it [15:53] so conceptually we might not normalize them the same way [15:53] I think turning /stable into latest/stable is OK, although I don't think saying it's just stable would break anything [15:53] Chipaca: anyhow [15:53] mvo: test-snapd-tools, track 2.0 [15:53] and given that /latest/stable turns into latest/stable, turing /stable to stable might be easier to think of [15:54] pstolowski: sure, let me look at this [15:54] Chipaca: did you get to work on the patch that is really the thing that will break people [15:54] there we want to turn /stable in stable [15:54] pedronis: ijohnson has the patch [15:54] where? [15:54] https://github.com/snapcore/snapd/pull/7364/files [15:54] PR #7364: overlord/snapstate: add migration function to fix invalid channel spec [15:54] that's not a patch [15:55] it's also not the full normalisation either [15:55] I thought I said this [15:55] at some point :) [15:55] pedronis: i mean, that's what the patch needs to do (just for every snap) [15:56] pedronis: so i thought i'd build it on that [15:56] don't think it's doing the right thing [15:56] hmm, ok [15:56] the patch needs to FieldsFunc and join by "/" again [15:56] I think [15:56] eh, ok [15:57] i'll do that instead then [15:57] but after my break [15:57] ok [15:57] sorry, this is confusing [15:58] Chipaca: about your other PR, not sure, maybe we should just keep if we get push back when things go to beta or candidate [15:58] there is no obvious thing for it to do [15:58] still [15:59] pedronis, Chipaca: okay, well feel free to abandon my PR #7364 and go with what Chipaca has or will have, I will check in tomorrow to see what happens but am unable to do anymore work now unfortunately [15:59] PR #7364: overlord/snapstate: add migration function to fix invalid channel spec [16:00] BTW I resolved the merge conflict between PR 7367 and 7359, the branch is here: https://github.com/anonymouse64/snapd/tree/channels-with-extra-slashes-with-7359 [16:00] PR #7367: snap, cmd/snap: support (but warn) using deprecated multi-slash channel [16:00] talk to y'all tomorrow [16:01] jdstrand: hey, is this something you can quickly sort "error: snap "review-tools" is not available on edge for this architecture (s390x) but exists on other architectures amd64, arm64, armhf, i386, ppc64el)." ? [16:03] pstolowski: there are some complications but I'm on it [16:54] noise][1, niemeyer: is this our current doc for brand stores? https://docs.ubuntu.com/core/en/build-store/ [16:55] I was surprised to find that on docs.ubuntu.com instead of snapcraft [17:02] PR core18#136 closed: Remove the 60-unminimize motd, identify system as Ubuntu Core 18 [17:13] pedronis: hey, could you (or one of you snapd masters) suggest what should be done to "clean" snapd's state (without removing the installed snaps or their data)? context: https://discourse.ubuntu.com/t/building-multipass-images-with-packer/12361 [17:13] thanks! :) [17:35] mvo: ack, ty === pstolowski is now known as pstolowski|afk [18:11] sergiusens: I can enable it. I can't test it, but I can enable it [18:12] PR snapd#7363 closed: cmd/snap-confine: fix group and permission of .info files [18:14] sergiusens: done. I'm building it [18:14] * jdstrand crosses fingers [18:25] * zyga still debugs stuff [18:26] jdstrand I will get it tested by clicking on adt-retry [18:26] jdstrand surprised this went away as it used to be working before [18:27] jdstrand: hey do you know about ure and uno-libs3 perpetually causing review-tools to barf about 4063-1 and 4102-1? [18:29] USNs claim the latest packages (6.0.7-0ubuntu0.18.04.9 in our case) have the fix, but still review-tools is unhappy [18:31] poor review-tools 😞 [18:33] sergiusens: I never built for s390x.... /me hmms [18:34] Saviq: let me look. is it possible you have a revision that is in a channel/track that is lingering without the fix? [18:38] Saviq: what package? multipass? mir-kiosk? I get all the emails for outdated packages and don't see what you see. can you paste? [18:40] sergiusens: fyi, says it'll build in 2 hours [18:47] jdstrand: egmde-confined-desktop, I checked the manifest that it has the latest packages [18:48] jdstrand: you've got mail [18:50] Saviq: the package name was enough. /me looking [18:50] that is a big snap [18:59] Saviq: 6.0.7-0ubuntu0.18.04.9 < 1:6.0.7-0ubuntu0.18.04.8 [19:00] Saviq: snapcraft is dropping the epoch in the manifest [19:00] stage-packages: [19:00] - uno-libs3=6.0.7-0ubuntu0.18.04.9 [19:00] jdstrand: wow, that build is sure taking its time to start [19:00] USN has 1:6.0.7-0ubuntu0.18.04.8 [19:02] sergiusens: there seems to be a bug in the way that snapcraft is calculating what was staged. likely because snapcraft is parsing the on disk filename of the deb and that filename omits the epoch [19:03] sergiusens: shall I file a bug? if so, where? LP? [19:12] sergiusens: actually, hold on [19:12] jdstrand: was looking as this code base was not fresh [19:12] jdstrand: we use python-apt for this and use .candidate [19:12] I can look deeper, just not right now [19:14] jdstrand, sergiusens: ack, filing bug [19:15] Saviq: no, don't [19:16] it turns out that libreoffice is one of those weird packages that uses different versions for the binaries [19:16] Source: libreoffice (1:6.0.7-0ubuntu0.18.04.9) [19:16] Package: uno-libs3 [19:16] Version: 6.0.7-0ubuntu0.18.04.9 [19:18] ah, source vs. package [19:18] s/package/binary/ [19:18] so review-tools needs to take that into account? [19:18] there are limitations to what the review-tools can do since they don't have all the information. I'll see if I can come up with some [19:18] something [19:19] kk [19:19] shall I file bug for review-tools then? [19:19] epochs are evil! [19:20] Saviq: no real point, I am working on it [19:20] I had another thing I'm working on, so I'll do both. if I need to, I'll fill it [19:22] "I had another thing I'm working on, so I'll do both" [19:22] hmm, the usn db has the wrong version (it includes the epoch) [19:35] mvo: what does ~ >>> snap run --strace riot-web [19:35] /var/lib/snapd/snap/strace-static/current/bin/strace: Unexpected wait status 0x8b [19:36] error: exit status 1 mean? [19:36] PR snapd#7350 closed: tests: check snap_daemon user and group on system-usernames-illegal test are not created [19:46] jdstrand: hm. Review-tools doesn't know about gpio-control interface apparently :( and I'm being asked to allow-{installation,autoconnection} for it for a couple of snaps. Do you know what the deal is with that interface? [19:47] PR snapd#7359 closed: overlord/snapstate: check channel names on install [19:47] sergiusens: hm, hm, that is an issue with strace usually [19:48] jdstrand: I was able to just plonk some json in plugs referring gpio-control, just concerned that tools will be unhappy with it [19:49] what up with all the review-tools stuff today? [19:49] * jdstrand looks [19:52] hehe sorry jdstrand :( [19:53] roadmr: there are several that were added and not documented in the forum either [19:53] jdstrand: 😢 [19:53] roadmr: let me add those, fix the icon issue and get you a tag. that may be tomorrow [19:53] PR snapd#7357 closed: cmd/snap: fix snap switch message

[19:53] PR snapd#7369 opened: overlord/snapstate: check channel names on install (2.41) [19:53] jdstrand: sure thing, no huge rush - I asked code-insiders to re-request manual review but they haven't so far [19:54] degville: hey, fyi, https://forum.snapcraft.io/t/supported-interfaces/7744 is missing packagekit-control and appstream-metadata. it lists gpio-control but without a link [19:56] roadmr: plonking the json is fine. thanks! did you want me to review? [19:57] jdstrand: not necessarily, it seems like a straightforward allow-installation: true (and same for allow-autoconnection) and the interface is well-scoped, it's also in a snap for a brand store [19:57] no superprivileged shenanigans or anything [19:57] (just that when trying to generate the json, I used review-tools which barfed at the interface name - but I wrangled it manually and it was ok) [19:59] roadmr: cool. fyi, ad1045d [19:59] (not a tag) [19:59] looked more like a year to me :) only the trailing "d" threw me off [20:00] hehe [20:08] jdstrand: thanks for letting me know! I'll fix it. [20:19] degville: thanks! [20:20] Saviq: it is more involved than a quick fix, so I filed a bug: https://bugs.launchpad.net/usn-tool/+bug/1841848 [20:20] Bug #1841848: snap USN notifications reporting binaries with different versions than source as out of date when they are not