=== sitter_ is now known as sitter
[06:12] <mborzecki> morning
[06:25] <mvo> hey mborzecki - good morning
[06:27] <mborzecki> i see that 2.37 is out :) time to update arch packages
[06:28] <mvo> mborzecki: yeah, I need someone approve the SRU uploads still but otherwise most things are in place now
[06:43] <zyga> Hi
[06:51] <mvo> hey zyga
[07:00] <zyga> Hey, all good
[07:00] <zyga> Details later today :-)
[08:06] <mup> PR snapcraft#2441 opened: legacy/meta: make hooks executable instead of complaining they're not <Created by Saviq> <https://github.com/snapcore/snapcraft/pull/2441>
[08:09] <mborzecki> pushed an update to arch, seems to work fine locally
=== pstolowski|afk is now known as pstolowski
[08:23] <pstolowski> hey
[08:30] <mborzecki> pstolowski: hey
[08:33] <mvo> hey pstolowski
[08:45] <zyga>  hey pawel
[08:45] <zyga> mborzecki: thank you :)
[08:45] <zyga> I will push suse updates after returning
[08:45] <zyga> I want to test them locally
[08:58] <mup> PR snapcraft#2442 opened: cli: enable cleaning of parts <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2442>
[09:07] <mborzecki> turns out that plug name sorting spread error was a regression after all
[09:09] <mborzecki> and we're missing a unit test for /v2/interfaces (legacy connections) that checks whether returned data is sorted
[09:10] <mborzecki> snap interfaces makes doesn't do anything about sorting of plugs/slots and conencted endpoint, so i guess it's implied that the data is sorted already
[09:20] <pstolowski> mborzecki: was it a regression after yesterday's PR?
[09:32] <pstolowski> need 2nd review for simple https://github.com/snapcore/snapd/pull/6379
[09:32] <mup> PR #6379: ifacestate/tests: extra test for hotplug-connect handler <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6379>
[09:34] <Chipaca> huh, I don't  understand #6388
[09:34] <mup> PR #6388: tests: fix install-snaps test by changing the snap info regex <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6388>
[09:35] <mborzecki> pstolowski: no, it's a regression in my connections endpoint PR
[09:35] <Chipaca> for two reasons: that install test should fail all the time now because of #6339
[09:35] <mup> PR #6339: cmd/snap: only auto-enable unicode to a tty <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6339>
[09:35] <Chipaca> but at the same time --unicode=never should not make a difference, for the same reason
[09:36] <Chipaca> so somehting's off
[09:36] <pstolowski> mborzecki: ack. the client should be fixed to sort imho
[09:36] <mborzecki> Chipaca: there shuld be a git revision in the build log that cachio linked
[09:36] <mborzecki> s/shuld/should/
[09:38] <mborzecki> Chipaca: heh, can't find one :/
[09:38] <Chipaca> mborzecki: issue is on master as well
[09:39] <Chipaca> mborzecki: I suspect there's a sneaky en dash that isn't coming from an escapes struct
[09:39]  * Chipaca greps
[09:41] <mborzecki> heh, en dash, wreaking havoc since MS started replacing - with it in their office/outlook suites :P
[09:41] <Chipaca> actually, no
[09:41] <Chipaca> that's never an en dash
[09:41] <Chipaca> what
[09:41] <Chipaca> ah
[09:41]  * Chipaca stops, steps back, and hits the coffee
[09:42] <kyrofa> That's always my solution as well
[09:42] <Chipaca> mborzecki: I was so indignant at people using 1252 instead of latin 1
[09:44] <mborzecki> Chipaca: 1250 here :P
[09:47] <Chipaca> mborzecki: I guess you had the same thing going with latin 2?
[09:47] <mborzecki> Chipaca: yup
[09:47] <Chipaca> although probably not as bad, given what html 5 does
[09:58] <mborzecki> Chipaca: haha, https://github.com/snapcore/snapd/pull/6388#discussion_r248595404 so the font rendering i get in FF makes - and en dash virtually indistinguishable
[09:58] <mup> PR #6388: tests: fix install-snaps test by changing the snap info regex <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6388>
[09:59] <Chipaca> mborzecki: https://github.com/snapcore/snapd/blob/master/cmd/snap/main.go#L500
[09:59] <mborzecki> Chipaca: at 250% zoom it's slightly longer and slimmer than -
[10:01] <mup> PR snapd#6392 opened: interfaces: helpers for sorting plug/slot/connection refs <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6392>
[10:02] <mborzecki> trivial one ^^
[10:05] <Chipaca> mborzecki: connRef already has sorting tests?
[10:05] <mborzecki> Chipaca: yes
[10:06] <mborzecki> just above the first hunk in sorting_test.go
[10:08] <mborzecki> i'm suprised how the test suite is mostly non-flaky recently
[10:13] <Chipaca> mborzecki: don't jinx it
[10:55] <mup> PR snapd#6392 closed: interfaces: helpers for sorting plug/slot/connection refs <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6392>
[11:06] <mborzecki> prepare of google:arch-linux-64:tests/{main,regression,completion,smoke}/ suites failed, with an awkward error
[11:33] <kenvandine> pedronis`: https://bugs.launchpad.net/snapd/+bug/1768419
[11:33] <mup> Bug #1768419: Pass through snapd client User-Agent to store requests snapd <snapd:Triaged> <https://launchpad.net/bugs/1768419>
[11:39] <Chipaca> kenvandine: ?
[11:50] <kenvandine> Chipaca: we were just discussing that and i was sending pedronis` the link
[11:50] <Chipaca> fwiw we do now have context in more places, but it'd still be a bunch of work to get it everywhere
[11:51] <Chipaca> (context is needed to do what that says)
[11:51] <kenvandine> Chipaca: could you comment on that bug with any concerns?
[11:51] <kenvandine> we are trying to make sure the store team is on board as well
[11:51] <Chipaca> kenvandine: is "it's work" a concern? :-)
[11:51] <kenvandine> a little
[11:52] <kenvandine> it's something we really want
[11:52] <kenvandine> not just us but advocacy
[11:52] <Wimpress> degville: Do you have any docs (draft or otherwise) that explain the key signing of snaps?
[11:53] <Wimpress> I have an ISV asking after details for a security review.
[11:55] <mborzecki> Chipaca: pushing that user-agent info through all the layers without context sounds nightmarish
[11:55] <Chipaca> mborzecki: "a lot of work"
[11:56] <mborzecki> Chipaca: and when complete, it'd probably be nothing to be proud of :)
[11:56] <Chipaca> mborzecki: eh, dunno about that
[11:57] <Chipaca> mborzecki: it is the kind of thing that would make a refactor of daemon more urgent though
[11:57] <degville> Wimpress: no, sorry - not specifically. The closest is likely the Ubuntu Core image building doc: https://docs.ubuntu.com/core/en/guides/build-device/image-building.
[11:57] <Chipaca> anyway, commented there
[11:58] <Chipaca> degville: Wimpress: wasn't there a whitepaper?
[11:58] <Wimpress> degville: I suspected ;-) Thanks for looking. I'll prepare a reply.
[11:59] <Wimpress> I have the whitepaper, very old now. Orientated toward Ubuntu Core rather than just snaps.
[11:59] <degville> Wimpress: we can create one - happy to prioritise it - especially if there's a Whitepaper.
[12:02] <Wimpress> degville: Please do add creating snap signing/integrity checking to your TODO list :-)
[12:02] <degville> Wimpress: will do - thanks. This seems important.
[12:03] <Wimpress> I'll prepare a reply and let the ISV know this is something we're working on.
[12:16] <mup> PR snapd#6393 opened: packaging: import debian salsa packaging work <Created by mvo5> <https://github.com/snapcore/snapd/pull/6393>
[12:27] <greyback> hey, I'm trying to install Core on my RPi3 - I used the edge image - it has stuck at the account email setup with "x509: certificate expiired or not yet valid". Appears networking set up ok, I can ping and attempt ssh connection. Any idea what's wrong?
[12:28]  * Chipaca ⇝ lunch
[12:31] <popey> greyback: time and date wrong?
[12:31] <greyback> popey: how can I check that?
[12:31] <greyback> this is during Core first setup
[12:32]  * greyback plugs out and in again, in case it helps
[12:35] <greyback> nope
[12:35] <popey> I don't know, but that's where cert errors often come from
[12:35] <popey> also if you're behind a proxy
[12:35] <popey> are you in capetown? Is the IS transparent proxy in the way and doing something silly?
[12:36] <greyback> no, but I'm in a new office
[12:36] <ppisati> ogra: how do i install hcitool in ubuntu core? core16 doesn't have it
=== ricab is now known as ricab|lunch
[12:38] <cwayne> ppisati: bluez snap
[12:38] <popey> greyback: does it have a captive portal?
[12:38] <greyback> popey: no, and no sign of a proxy.
[12:38] <ppisati> cwayne: yeah. i found it
[12:39] <popey> greyback: does it work in a vm? on your laptop?
[12:39] <greyback> popey: worth a shot
[12:39] <popey> Otherwise I'm a bit out of ideas, sorry.
[12:39] <popey> But it all smells of crappy network doing stuff if your certificates are wonky
[12:39] <popey> (also, does a core16 image work?)
[12:40] <greyback> popey: thanks for the help. I've mostly carted around VMs, so this is the first time I've done the core initial setup in a while
[12:40] <greyback> I'll see what I can figure out
[12:42]  * pstolowski lunch
[12:49] <mup> PR snapcraft#2443 opened: schema: allow before and after <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2443>
[12:54] <zyga> mvo: hey
[12:54] <zyga> mwhudson: thank you!
[12:54] <zyga> mvo: I wasn't aware (or I missed because steve told me) that mwhudson is going to be back today
[12:55] <zyga> mwhudson: we're working on the 2.37 debian release
[12:55] <zyga> mwhudson: I think it's safe to say that we will sync with you next week, this week we're okay and it's best that we just take the responsibility of landing this release out there, we can definitely upload more changes later if needed
[12:56] <zyga> mwhudson: we also discussed ideas on how to improve the situation in both snapd upstream (how to test it so that we detect this early) and in debian (improvements to salsa packaging, packaging missing things, updating packages for stale things)
[12:56] <zyga> mvo: mwhudson ran tests on debian kernel and they did not fail so I suspect some interaction between unit tests and ubuntu kernel running in debian userspace chroot
[12:59] <mborzecki> off to pick up the kids from school
[13:32] <ogra> ppisati, it comes with the bluez snap
[13:37] <ppisati> ogra: yep, found it
[13:39] <ogra> ppisati, btw, the forum indicates that more and more people use your sample-kernel trees from GH ... are they still kept up to date ?
[13:39] <ogra> (/me saw three users alone in the last ten days)
[13:40] <ogra> (different ones)
[13:41] <mvo> zyga: aha, cool
[13:42] <mvo> mwhudson: https://github.com/snapcore/snapd/pull/6393 <- might be interessting for you (cc zyga)
[13:42] <mup> PR #6393: packaging: import debian salsa packaging work <Created by mvo5> <https://github.com/snapcore/snapd/pull/6393>
[13:42] <zyga> mvo: I'll gladly look next week unless you believe there is some value to cherry pick as debian/patches
[13:48] <mvo> zyga: if you package works, no need to cherry pick anything
[13:48] <mvo> zyga: if the package does not work there might be fixes worth getting there
[13:49] <ppisati> ogra: they never meant to be updated, they are just there as an example how to make your kernel work with ubuntu core
[13:49] <ogra> hmm, k, people seem to actually use them
[13:59] <Chipaca> getting tea, bbiab
=== ricab|lunch is now known as ricab
[14:30] <ppisati> ogra: what's the best strategy to build a snapdragon ubuntu core image that uses a kernel snap with a custom dtb?
[14:32] <ogra> ppisati, build a normal image, put dtb into system-boot partition next to the default one, stop boot at u-boot prompt and point to the new dtb with the fdt_file var (or however that was called on db)
[14:33] <ogra> if you actually want to build from scratch and your dtb has a special name, you need to build a modified gadget with changed uboot.env.in with the same change as above
[14:34] <ogra> easiest is indeed just building a default image and simply ship your dtb in your kernewl snap as a replacement of the default file ... (same filename) then you dont need to touch anything
[14:35] <ppisati> ogra: ok so, my kernel snap contains the custom dtb and it has the same name, does it replace the one from the gadget snap?
[14:35] <mborzecki> Chipaca: looking at the overlord loop, looks like we could detect when the time jumps by some reasonable amount (eg. some mulitple of ensure intervals?) and skip one call to ensure
[14:35] <ogra> there is none in the gadget snap on db
[14:35] <ppisati> *the same name as the one normally used to boot the board
[14:35] <ogra> it is used from the kernel snap
[14:35] <ppisati> ogra: oh cool
[14:35] <ogra> so as long as you keep the same name it will just be used
[14:36] <ogra> even if you manually install your kernel snap on an image
[14:36] <ppisati> ogra: k, thanks
[14:39] <mborzecki> Chipaca: anyways, we'll know more once we have some feedback from popey
[14:44] <Chipaca> mborzecki: time changed between 1.6 and 1.11 (was it 1.7?) and started including two times per time
[14:44] <Chipaca> mborzecki: we'd have to test both :-)
[14:44] <Chipaca> but, yes
[14:46] <Chipaca> mborzecki: that is, 1.6 didn't have monotonic timers
[14:46] <mborzecki> Chipaca: we're switching to 1.9 though? :P
[14:46] <Chipaca> mborzecki: so if the machine suspends for an hour half an hour before a dst change, ¯\_(ツ)_/¯
[14:46] <Chipaca> mborzecki: aye
[14:47] <mborzecki> Chipaca: i mean we can try and reduce the changes of this happening, but that's probably it
[14:49] <zyga> Chipaca: papercut: search for test that uses "snapname" and revision 42
[14:49] <zyga> it's not mocking and ends up writing to ~/snap/
[14:49] <Chipaca> zyga: ouch
[14:49] <Chipaca> zyga: spread, or unit?
[14:49] <zyga> :)
[14:49] <zyga> unit
[14:50] <zyga> maybe sudo mkdir snap/snapname
[14:50] <zyga> and chmod 000
[14:50] <zyga> to catch it
[14:50] <Croepha> is there still a download for ubuntu core?
[14:51] <zyga> Croepha: https://www.ubuntu.com/download/iot
[14:51] <zyga> mvo: about cmd/snap-seccomp, question about build-deps
[14:51] <zyga> do I recall correctly that needs some i386 headers?
[14:51] <Croepha> zyga: thanks :)
[14:51] <zyga> if so, how is that expressed?
[14:52] <zyga> https://www.irccloud.com/pastebin/lvJKcDgF/
[14:52] <mvo> zyga: I don't remember, maybe thats it
[14:53] <zyga> I wonder how that looks like because nothing in debian/control looks appropriate
[14:54] <Chipaca> zyga: instead of making me hunt, if you already know the test can you tell me? if you don't then i can hunt no problem
[14:54] <Chipaca> there are a lot of tests in snap-exec that use snapname at rev 42
[14:54] <Chipaca> also snapenv
[14:55] <zyga> Chipaca: I don't know the test
[14:55] <zyga> just noticed when I ran go test ./...
[14:55] <zyga> uh
[14:55] <zyga> ok
[14:55] <zyga> not urgent :)
[14:55] <Chipaca> ok
[14:55] <zyga> dreaded 42 :)
[14:56] <Chipaca> mborzecki: https://github.com/davecheney/junk/blob/master/clock/clock_linux.go fwiw
[15:15] <mborzecki> shall we land #6388?
[15:15] <mup> PR #6388: tests: fix install-snaps test by changing the snap info regex <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6388>
[15:25] <Chipaca> mborzecki: +1
[15:26] <mup> PR snapd#6388 closed: tests: fix install-snaps test by changing the snap info regex <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6388>
[15:38] <roadmr> Chipaca hi :) does snapd 2.37 currently in beta have full support for epochs?
[15:38] <Chipaca> roadmr: define "full support"
[15:39] <Chipaca> roadmr: #6356 isn't on master yet, so 2.37 doesn't have it, so I don't consider epochs "done"
[15:39] <roadmr> Chipaca: hm I guess not refreshing to a revision of the snap that isn't epoch-compatible with the one I have
[15:39] <mup> PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356>
[15:39] <roadmr> Chipaca: ah - yes, that was sort of it, I didn't check/track the actual PR. I'll keep an eye on that one then :) thanks!
[15:40] <Chipaca> roadmr: the "don't refresh if not epoch-compatible" work is in 2.37 yes
[15:40] <roadmr> Chipaca: (and indeed it was to mention something about epochs in our weekly report - but I'll just leave it at "RSN!")
[15:40] <roadmr> Chipaca: ah, so #6356 is the "eager refresh" thingy?
[15:40] <mup> PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356>
[15:41] <Chipaca> roadmr: yes
[15:41] <roadmr> great! thanks Chipaca
[16:11]  * cachio lunch
[16:57] <mup> PR snapd#6394 opened: tests: iterate getting journal logs to support delay on boards <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6394>
[17:01] <mup> PR snapd#6395 opened: cmd/snap: use a fake user for 'run' tests <Simple 😃> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6395>
[17:01] <Chipaca> zyga: ^
[17:02] <cachio> mvo, 2.37 is in candidate
[17:02] <mvo> cachio: yay
[17:03] <mvo> cachio: thank you!
[17:04] <cachio> mvo, :)
[17:09] <zyga> Chipaca: thank you!
[17:12] <cachio> mvo, yesterday I saw a mount error again
[17:12] <cachio> forgot to mention :(
[17:16] <cachio> I think it was on 2.37
[17:16] <cachio> on ubuntu-core-18
[17:40]  * zyga EODs
[17:42] <cachio> zyga, is it needed the change I did time ago on upgrade backend?
[17:42] <zyga> cachio: I don't know what you mean, sorry
[17:42] <zyga> I'm too tired today
[17:42] <zyga> long day
[17:42] <zyga> 7:30 -> 19:30
[17:42] <cachio> zyga, ahh, ok
[17:42] <cachio> let's talk tomorrow
[17:42] <zyga> +1
[17:43] <cachio> thanks
[17:59] <mvo> cachio: oh? if you see the mount error again, please give me an url, that is really sad if the bug is not actually fixed
=== pstolowski is now known as pstolowski|afk
[18:07] <mup> PR snapd#6393 closed: packaging: import debian salsa packaging work <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6393>
[18:07] <mup> PR snapd#6396 opened: packaging: import debian salsa packaging work <Created by mvo5> <https://github.com/snapcore/snapd/pull/6396>
[19:01] <zyga> mwhudson: hey, for tomorrow, just to let you know, we are working on the package with mvo
[19:01] <zyga> mwhudson: my fork of salsa is at https://salsa.debian.org/zyga-guest/snapd/commits/debian
[19:36] <diddledan> https://openfaas.bowlhat.net/function/awesomify?q=snap+craft
[19:46] <Pharaoh_Atem> popey: did you poke anyone to add CentOS/RHEL 7 instructions for installing and using snaps?
[19:46] <Pharaoh_Atem> I didn't do all that work to make it available in EPEL for nothing, did I? :P
[19:46] <popey> haha!
[19:46] <popey> I did poke, I need to re-poke
[19:47] <popey> will do so tomorrow morning
[19:47] <popey> Thanks for the nudge
[19:47] <zyga> indeed!
[21:02] <mwhudson> zyga: great
[21:02] <mwhudson> zyga: didn't you get your dd hat yet?
[21:29]  * cachio afk
[23:50] <mup> PR snapd#6397 opened: tests: Use backend: [autopkgtest] for smoke test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6397>