[02:55] <mup> PR snapcraft#2462 closed: Release changelog for 3.1.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2462>
[06:23] <mborzecki> morning
[07:03] <mborzecki> mvo: hey
[07:03] <mborzecki> mvo: #6480 can land, right?
[07:03] <mup> PR #6480: release: 2.37.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6480>
[07:08] <mvo> mborzecki: good morning! yes, the changelog can land
[07:10] <mup> PR snapd#6480 closed: release: 2.37.2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6480>
=== pstolowski|afk is now known as pstolowski
[08:10] <pstolowski> mornings
[08:20] <pedronis> hello
[08:20] <mvo> hey pstolowski and predronis
[08:22] <mwhudson> mvo: should i (or someone) upload 2.37.2 to debian?
[08:22] <mvo> mwhudson: that would be great, yes
[08:22] <mvo> mwhudson: it fixes some small regressions around classic snaps and special users
[08:22] <mwhudson> mvo: have you managed to import the debian packaging into snapd upstream?
[08:23] <mvo> mwhudson: there is a PR for this https://github.com/snapcore/snapd/pull/6413 but it needs one more review
[08:23] <mup> PR #6413: packaging: import debian salsa packaging work, add sbuild test and use in spead <Created by mvo5> <https://github.com/snapcore/snapd/pull/6413>
[08:24] <mvo> mwhudson: with this the packaging updates would be super trivial because we can just keep in sync this way and we (upstream) detects any dependency issues very early, we even could have a real "debian" branch so that the release is literally just "gbp"
[08:24] <mwhudson> mvo: would my uploading 2.37.2 the old way make your life harder?
[08:24] <mvo> mwhudson: I initially imported with all history from salsa but there is a bad commit in there that breaks something, iirc gbp because of an invalid email address
[08:24] <mwhudson> is it worth waiting for that to merge?
[08:25] <mvo> mwhudson: just go ahead
[08:25] <mwhudson> ok
[08:25] <mvo> mwhudson: I will just merge your changes
[08:25] <mvo> mwhudson: and then once its in our master I plan to take the salsa one, merge our master, fix the conflicts and then things should be super smooth
[08:30] <pstolowski> mvo: i've re-run smoke/install test on pi3 and it failed with same symptoms as yesterday
[08:31] <pstolowski> mvo: this is probably relevant: snapmgr.go:247: cannot read snap info of snap "core" at revision 6351: cannot find installed snap "core" at revision 6351: missing file /snap/core/6351/meta/snap.yaml
[08:32] <pstolowski> mvo: and then https://pastebin.ubuntu.com/p/SFjvTQgghK/
[08:35] <mvo> pstolowski: did you use a fresh image before the re-run?
[08:35] <pstolowski> mvo: no
[08:35] <mvo> pstolowski: I think thats the issue, the test scrweed things up
[08:35]  * mvo needs to be afk for ~10min
[08:35] <pstolowski> mvo: ah
[08:35] <pstolowski> mvo: ok, reflashing
[08:37] <mwhudson> mvo: uploaded
=== phoenix_firebrd is now known as murthy
[08:54] <mvo> mwhudson: thank you!
=== murthy is now known as phoenix_firebrd_
[08:54] <mvo> pstolowski: I think the issue is (I saw that in another test) that the restore is doing something wrong sometimes, I saw that there was a "core" snap in the state but not on disk so things got confused
[08:56] <pstolowski> mvo: sounds plausible
[08:58] <mvo> pstolowski: don't get me wrong, we need to get to the bottom of it but its not an OMGnow priority :)
[08:58] <pstolowski> mvo: yes, of course, it's just a test helpers issue
[08:58] <mvo> exactly
[09:00] <pstolowski> mvo: hmm, i though i could request individual tests with SPREAD_TESTS=... env when running run_external_device.sh, but it doesn't seem to be the case. is there a way to run the script and have device prepared and only run specific tests?
[09:00] <pstolowski> *thought
=== phoenix_firebrd_ is now known as murthy
[09:03] <pstolowski> ah i made a typo, retrying..
[09:12] <mvo> pstolowski: aha, nice, I was not aware of this option! when I retried so far I was doing it by hand (which is a bit cumbersome). thanks for this
[09:21] <pstolowski> mvo: nah, ignore it, doesn't work, it's probably an internal variable in the scripts
[09:21] <pstolowski> mvo: anyway, i re-run the two tests manually and they passed
[09:28] <mvo> pstolowski: thank you!
[09:29] <mvo> pstolowski: I had the same the other day (not the same test but same error and symtoms and re-run on a clean image made it pass)
[09:30] <pstolowski> pedronis: re your comment about renaming/simplyfing RequestedSlotSpec, that could be a separate followup PR i think
[09:30] <pedronis> pstolowski: yes, but we should probably agree a bit on what, anyway this PRs all need 2nd reviews
[09:31] <pstolowski> pedronis: indeed
[09:32] <mvo> I should have time for reviews today
[09:32] <pstolowski> mvo: do you think you could the 2 hotplug PRs?
[09:32] <pstolowski> *could review*
[09:33] <mvo> yeah, I looked at the rename one a bit this morning but need to look at the first one first
[09:33] <pstolowski> mvo: yeah, #6465 should land first, will make the rest smaller
[09:34] <mup> PR #6465: overlord/ifacestate: hotplug-add-slot handler <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6465>
[09:58] <pedronis> pstolowski: can we have a short HO about in 30 mins about the Spec stuff?
[09:58] <pstolowski> pedronis: yes
[09:59] <pedronis> cool
[10:12] <mborzecki> Chipaca: pushed some tweaks to snap connections
[10:13] <mborzecki> Chipaca: the help message is likely worse than it was in the beginning :) i'd love some input from you and degville on this
[10:13] <degville> mborzecki: I'll take a look :)
[10:13] <mborzecki> drat, i probably need to update the spread test now
[10:30] <pstolowski> pedronis: standup HO?
[10:31] <pedronis> yes
[10:35] <mwhudson> "failed mips build of snapd 2.37.2-1" oh noes
[10:35]  * mwhudson goes to bed
[10:36] <mvo> mwhudson: meh, do you have a link to the build log?
[10:36] <mwhudson> mvo: it's really no concern, it has always failed on mips
[10:36] <mvo> pedronis: do you think 6413 could land with only a single review? given that its mostly packaging and a little bit of tests?
[10:37] <mvo> mwhudson: aha, ok
[10:37] <mwhudson> although if you really want a look https://buildd.debian.org/status/package.php?p=snapd
[10:37] <mwhudson> -buildmode=pie not supported on linux/mips
[10:37] <mvo> I see
[10:37] <mvo> thanks!
[10:48] <mborzecki> degville: what do you think about this https://paste.ubuntu.com/p/5Znd8JZ7f2/ ?
[10:52] <Chipaca> mborzecki: problem with that is that you don't clearly say that without a snap it lists all
[10:53] <Chipaca> mborzecki: maybe the first sentence, ... between plugs and slots >for all snaps< in the system
[10:54] <Chipaca> mborzecki: and to emphasize it, in the first example, Lists connected and unconnected plugs and slots ~for~ >limited to< the specified snap.
[10:54] <Chipaca> or something like taht
[11:03] <mborzecki> Chipaca: degville: how about this one https://paste.ubuntu.com/p/CfcwX7J2Qv/ ?
[11:03] <Chipaca> mborzecki: winner
[11:03] <degville> yep!
[11:05] <mborzecki> Chipaca: degville: ok, updating the code, thanks for the help!
[11:06] <degville> mborzecki: np!
[11:22] <pedronis> Chipaca: degville: thanks for the review/inputs on that PR. I will try to my own pass over it later today
[11:41] <Chipaca> pedronis: pstolowski: would it make sense to have (pre-)refresh hooks know the revision on both sides of the refresh?
[11:43] <Chipaca> multipass snapshots live VMs on refresh, and the snapshot format isn't compatible between 16 and 18, so they need to block a refresh if a vm is alive and it's trying to go between those two
[11:43] <pstolowski> Chipaca: imho - yes, that was brought a couple of times but never reached conclusion
[11:44] <pstolowski> Chipaca: could be snapctl enhancement, or in env
[11:58] <pedronis> Chipaca: maybe, revisions are not a useful concept to code around tough
[12:04] <Chipaca> pedronis: yeah, epochs would be better there :-)
[12:07] <pedronis> Chipaca: well, but if they use epochs and express they can't go from here to ther
[12:07] <pedronis> they can't never update
[12:07] <pedronis> unless we had a --foce
[12:07] <pedronis> s/had/add/
[12:07] <pedronis> heh, --force
[12:11] <Chipaca> pedronis: issue for them is that you could, all you need to do is stop your vms (or know they'll be stopped for you?)
[12:12] <pedronis> Chipaca: yea, epochs don't quite fit that
[12:13] <Chipaca> pedronis: https://forum.snapcraft.io/t/how-to-cause-a-snap-rollback/9848/8?u=chipaca
[12:13] <pedronis> yes, I'm aware of that forum post
[12:13] <pedronis> I haven't had brain cycle to more than skim it so far tough
[12:13] <Chipaca> :-) no worries
[12:20] <sparkiegeek> popey: just watching your Snapcraft live - are you familiar with being able to run 'less /path/to/foo.snap' to see what's in there? easy way of peeking to see what's there (maybe don't need to unsquashfs at ~29:00)
[12:20] <sil2100> mvo: hey! Is the snapd 2.37.1 for cosmic good? I mean, you mentioned that the bionic-visible regression did not affect cosmic, right?
[12:20] <sil2100> mvo: is it safe to release?
=== phoenix_firebrd is now known as murthy
[12:25] <mvo> sil2100: it is ok, there is a new 2.37.2 available thought that fixes a rare corner case
[12:26] <mvo> sil2100: I think I would slightly prefer 2.37.2 unless you need the update now
[12:26] <mvo> sil2100: 2.37.2 is already in *-proposed
[12:34] <sil2100> mvo: it's fine, I'll wait for 2.37.2 then
[12:34] <sil2100> btw. it's not yet in -proposed, it's waiting for review o/
[13:34] <mvo> sil2100: ups, thats what I meant, its waiting for -proposed
[13:34] <mvo> sil2100: *nudge* *nudge* *wink* *wink* :P
[13:34] <mvo> sil2100: (no worries, I will wait for the archive-admin of the day)
[13:36] <sil2100> I'll review it today in a bit hopefully (since it's my shift today ;p)
[13:39] <mvo> sil2100: thank you
[13:45] <mup> PR snapd#6483 opened: image,cmd/snap:  simplify --classic-arch to --arch, expose prepare-image <Created by pedronis> <https://github.com/snapcore/snapd/pull/6483>
[14:01] <pedronis> Chipaca: standup?
[14:02] <Chipaca> pedronis: nah
=== ricab is now known as ricab|lunch
[14:29] <mup> PR core18#116 closed: Support arm64 with efi bootloader <Created by woodrow-shen> <Merged by sil2100> <https://github.com/snapcore/core18/pull/116>
[14:30] <mup> PR core18#113 closed: hook-tests: add more hook tests <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/113>
[14:32] <mup> Bug #1576775 changed: Docs: missing command to check a service status and logs <snap-docs> <Snapcraft:Confirmed> <snapd:Fix Released> <https://launchpad.net/bugs/1576775>
[14:36] <popey> https://forum.snapcraft.io/t/retroarch-help-with-issue-on-first-launch/9869
[14:36] <popey> that's a bit worrying. Something perhaps broke in 3.27?
[14:36] <popey> sorry, 2.37 :)
[14:37] <pedronis> Chipaca: the prepare-image PR is https://github.com/snapcore/snapd/pull/6483
[14:37] <mup> PR #6483: image,cmd/snap:  simplify --classic-arch to --arch, expose prepare-image <Created by pedronis> <https://github.com/snapcore/snapd/pull/6483>
[14:47] <ijohnson> hey sil2100, do you have a rough idea of when the arm64 ubuntu server image for raspi will be officially released? Thanks!
[14:49] <sil2100> ijohnson: hey! It'll be out with the 18.04.2 point-release
[14:50] <ijohnson> awesome, that's great news
[14:50] <sil2100> ijohnson: just have in mind that we'll still be improving the experience, with an aim to have a really solid product (hopefully) with disco (19.04)
[14:50] <sil2100> It's all a bit fresh here right now
[14:51] <ijohnson> sil2100: ack, thanks for the explanation
[14:57] <mborzecki> off to pick up the kids
[15:25] <mup> PR snapd#6476 closed: cmd/snap: tweak man output to have no doubled up .TP lines <Simple 😃> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6476>
=== ricab|lunch is now known as ricab
[15:27] <mup> PR snapcraft#2448 closed: Swap yaml schema document with json equivalent <Created by diddledan> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2448>
[15:27] <diddledan> YEY
[15:31] <pstolowski> mvo: doh.. https://pastebin.ubuntu.com/p/5bM7W4DQ96/
[15:36] <mvo> pstolowski: oh, anything interessting on the serial console? I wonder why the read/connect failures
[15:37] <pstolowski> mvo: nothing there, just login prompt
[15:38] <mvo> pstolowski: if you ssh to the machine, does that still work?
[15:39] <pstolowski> mvo: dammit.. my eth cable got loose :(
[15:40] <pstolowski> that's why it had i/o errors
[15:40] <mvo> pstolowski: heh - no worries, better that than something deeper
[15:41] <pstolowski> indeed
[16:49] <mvo> 6483 needs a second review (easy win)
[16:49] <mvo> also 6481 (another easy win)
[16:57] <pedronis> 6483 really needs Chipaca I think
[16:57] <Chipaca> on it
[16:57] <Chipaca> got sidetracked by some things in there
[16:57] <Chipaca> but on it
[16:57] <pedronis> it's fine
[16:57] <pedronis> my point was more than I wouldn't land it before your input
[16:58] <pedronis> I don't think is super urgent either
=== pstolowski is now known as pstolowski|afk
[17:03] <Chipaca> pedronis: there
[17:30] <pedronis> Chipaca: thanks,  you meant vertical space, when you wrote horizontal right?
[17:30] <Chipaca> pedronis: maybe I had my laptop on its side
[17:30] <pedronis> :)
[17:30] <Chipaca> pedronis: yeah
[17:34] <oneguynick> is there any reason after a snapcraft key creation that it would periodically work? snapcraft list-keys shows it and i can see its active, but executing the snap sign states no key
[17:36] <Chipaca> pedronis: fwiw image already pulls in i18n ( image -> store  -> i18n, as well as via strutil and timeutil)
[17:37] <Chipaca> oneguynick: snapcraft key, or snap key?
[17:37] <oneguynick> snapcraft list-keys
[17:37] <pedronis> Chipaca: I'm sure it does, it used from cmd/snap anyway, my point is that package itself doesn't import/use it yet
[17:37] <pedronis> for anything
[17:37] <oneguynick> snap key doesnt appear to be a valid command
[17:38] <Chipaca> pedronis: k
[17:38] <pedronis> Chipaca: pushed btw if you want to look again
[17:38] <Chipaca> oneguynick: but then you use 'snap sign'?
[17:38] <oneguynick> cat box-model.json | sed s/%TIMESTAMP%/$TIMESTAMP/ | snap sign -k itbox > box.model
[17:38] <oneguynick> this is the actual command being executed and failing
[17:39] <Chipaca> pedronis: thank you
[17:39] <oneguynick> output is this on the return
[17:39] <oneguynick> error: cannot sign assertion: cannot sign using GPG: /usr/bin/gpg --personal-digest-preferences SHA512 --default-key INSERTFAKEKEYINFOHERESINCEITSCUT_N_PASTE --detach-sign failed: exit status 2 ("gpg: signing failed: No such file or directory\ngpg: signing failed: No such file or directory\n")
[17:40] <Chipaca> oneguynick: but this only fails sometimes, you say?
[17:40] <oneguynick> yeah i just ran it to build an imagine and it randomly functioned
[17:40] <oneguynick> *image
[17:42] <Chipaca> oneguynick: do you do the list-keys and the sign with the same user in the same vm / container / machine?
[17:43] <oneguynick> yes both running as my user
[17:43] <oneguynick> i only sudo for the ubuntu-image build
[17:44] <Chipaca> oneguynick: snapcraft list-keys calls 'snap keys --json' (and then does some processing on it)
[17:45] <oneguynick> snap keys --json shows the key
[17:45] <oneguynick> snapcraft list-keys lists the same one (as expected it seems)
[17:46] <Chipaca> oneguynick: 'snap sign' and 'snap keys' use the same logic to find keys
[17:46] <Chipaca> oneguynick: the same codepath mostly (except one is listing, the other is searching by name)
[17:46] <oneguynick> any idea why `snap keys` and `snapcraft list-keys` see the key, but not sign?
[17:47] <Chipaca> oneguynick: so far my only hypothesis is that you're inadvertently using it in different contexts, somehow
[17:48] <Chipaca> oneguynick: does it fail reliably?
[17:48] <Chipaca> oneguynick: if so, check that user's ~/.snap/gnupg
[17:49] <oneguynick> failed at least 10-15 runs recently
[17:49] <oneguynick> `S.gpg-agent          S.gpg-agent.extra  openpgp-revocs.d   pubring.kbx   trustdb.gpg
[17:49] <oneguynick> S.gpg-agent.browser  S.gpg-agent.ssh    private-keys-v1.d  pubring.kbx~
[17:49] <oneguynick> contents are there and ownership correct
[17:50] <mup> PR snapd#6481 closed: tests: run test snap as user in the smoke test <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6481>
[17:51] <Chipaca> oneguynick: that's ~/.snap/gnupg ?
[17:51] <oneguynick> yes
[17:53] <Chipaca> oneguynick: can you prepend the snap sign with «strace -e '!select,pselect6,_newselect,clock_gettime' -f -D -vv -o /tmp/sign.trace» and try again until it fails?
[17:56] <oneguynick> looks like the gpg is failing on no such key
[17:57] <ogra> is there any reason you sign your assertion that often ? (you typically only do that once)
[18:02] <oneguynick> i am in the process of prototyping and rebuilding images
[18:30] <mup> PR snapd#6483 closed: image,cmd/snap:  simplify --classic-arch to --arch, expose prepare-image <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6483>
[19:08] <oneguynick> I went ahead and wiped out my keys and started again. Seems to be working better. No idea why
[19:08] <oneguynick> thanks @Chipaca for your help
[19:09] <Chipaca> oneguynick: I blame … evil hackers from Serbia.
[19:09] <mup> PR snapcraft#2464 opened: project_loader: use hardened flags by default <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2464>
[19:09] <Chipaca> fallback blame in case that one is unacceptable: Our POP server was kidnapped by a weasel.
[19:10]  * Chipaca stops playing with 'bofh'
[19:10] <oneguynick> Хвала вам