[05:17] <mborzecki> morning
[05:39] <mborzecki> bisecting go in the morning
[05:48] <zyga> mborzecki: hey
[05:48] <zyga> I found a bag of bugs around that flaky test
[05:48] <mborzecki> zyga: hey
[05:56] <zyga> One core18 seeding bug
[05:57] <zyga> One raciness bug in the test
[05:57] <zyga> And a bug around my use of MATCH
[05:57] <zyga> it is a miracle it passed at all
[06:12] <mvo> mborzecki: anything interessting from the bisect so far?
[06:12] <mvo> zyga: uh, bugs, bugs, bugs
[06:12] <mborzecki> mvo: not yet
[06:12] <mvo> mborzecki: thank you
[06:17] <zyga> mvo: hello
[06:17] <zyga> Just making coffe
[06:17] <zyga> Yes, bugs in test code
[06:17] <zyga> The one about core18 is generic
[06:18] <zyga> The rest are just test specific
[06:18] <zyga> I will be preparing patches. Just making coffee
[06:18] <mvo> zyga: thanks!
[06:18] <zyga> I spent all evening iterating on those, such a time sink to understand a trivial bug
[06:26] <zyga> re
[06:31] <mvo> mborzecki: quick question - you mentioned that using qemu -m 256 (or even 128) and buildmode=pie does not trigger the bug? i.e. its only observable on a low-mem arm system?
[06:32] <mup> PR snapd#6700 opened: packaging: disable -buildmode=pie to fix memory issue on armhf <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6700>
[06:32] <mborzecki> mvo: 256 worked with qemu
[06:33] <mborzecki> and pie ofc
[06:33] <mvo> mborzecki: and strace showed now abnormal allocations and the auxv no anomal start address?
[06:33] <mborzecki> mvo: oh, and couldn't get pi to run with mem=256M, even when tweaking gpu_mem
[06:33] <mvo> mborzecki: thanks!
[06:34] <mvo> mborzecki: this is slightly sad as we will not be able to test if we can ever re-enable buildmode=pie :/
[06:34] <mborzecki> mvo: didn't look at auxv, but brk was in the lower range
[06:34] <mvo> mborzecki: yeah, thats fine then
[06:34] <mvo> mborzecki: brk I think is the key
[06:35] <mvo> mborzecki: thanks again, I wonder if we should ask the guys if they can loan one of these boards to us or what we can do
[06:35] <mborzecki> mvo:  do you know if it's a regular chip board?
[06:35] <mvo> mborzecki: I don't know much, I think its a cheap/special one and the manufactor is no longer in business
[06:36] <mvo> mborzecki: I can try to find the datasheet and mail it to you
[06:36] <mborzecki> mvo: i have 2 chip boards, though regular ones, not -pro, at least one of those works
[06:37] <mvo> mborzecki: oh, nice. so you say we could use those for testing?
[06:37] <mborzecki> mvo: yes, iff it's the same board and i get the image
[06:38] <mvo> mborzecki: nice!
[06:38] <zyga> mvo: I added a comment to the PR
[06:38] <zyga> please check that if you have the setup
[06:38] <zyga> I'm trying to wrap up findings from last night
[06:39] <mvo> mborzecki: there is a datasheet in the "Subject: Re: core 2.38 memory issue
[06:39] <mvo> " mail
[06:39] <mvo> mborzecki: you are on CC :) thats all the data I have
[06:39] <mvo> zyga: is it? I build snap/snapd without buildmode=pie and "file" showed me a buildid that looks valid
[06:41] <zyga> without buildmode= what is the default mode
[06:41] <zyga> I think it differs  across go distributions
[06:41] <zyga> I certainly noticed this on suse
[06:41] <mvo> zyga: what go version is suse using?
[06:41] <zyga> I think it's the patches/config more than the version
[06:42] <zyga> suse is fully up to date, as usual
[06:42] <zyga> but please  just check what you get
[06:42] <zyga> and perhaps add a spread test for build-id
[06:42] <mvo> zyga: yeah, adding a spread test seems to be the right thing to move forward here with confidence
[06:42] <pedronis> mvo: mborzecki: do we know if the bug exist on 1.11 ? (I was looking at the relevant code and it's quite different in 1.11)
[06:42] <zyga> mvo: +1
[06:42] <mborzecki> pedronis: no 1.11 seems ok
[06:42] <mvo> pedronis: I think mborzecki tested on 1.11 - I let him speak
[06:43] <mborzecki> mvo: pedronis: i'm bisecting between 1.10beta2 (bad) and 1.11beta3 (good)
[06:44] <mvo> mborzecki: nice
[06:49] <pedronis> ok, as I said, my impression is that they rewrote the relevant code in between
[06:49] <pedronis> arena_used doesn't exist at some point in 1.11
[06:54] <mborzecki> pedronis: yeah, it might be that they rewrote chunks of code and fixed it (or made it not be triggered) by accident
[06:59] <mborzecki> mvo: they use chip PRO, slightly different than my board, idk maybe their image would work with some tweaks to dt
[07:03] <mvo> mborzecki: nice
[07:04] <mborzecki> mvo: heh, this reminds me of the -buildmode=shared that was triggerd by someone with yocto on i386
[07:06] <mup> PR snapd#6687 closed: snap-confine: set rootfs_dir in sc_invocation struct <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6687>
[07:12] <mup> PR snapcraft#2527 opened: Add -h short option for help <Created by techtonik> <https://github.com/snapcore/snapcraft/pull/2527>
[07:13] <pstolowski> morning
[07:17] <mborzecki> mvo: first commit that fixes our issue
[07:17] <mborzecki> mvo: https://github.com/golang/go/commit/c0392d2e7fbdcd38aafb959e94daf6bbafe2e4e9
[07:19] <mvo> mborzecki: aha! thank you
[07:19] <zyga> re after breakfast
[07:19] <mvo> mborzecki: that makes sense
[07:20] <mborzecki> mvo: we've looked at a commit just 3-4 revisions later
[07:20] <zyga> mvo: could we build with go 1.11?
[07:20] <mvo> zyga: we don't have that unfortunately
[07:21] <mborzecki> mvo: we've looked at this one https://github.com/golang/go/commit/2b415549b813ba36caafa34fc34d72e47ee8335c and it was mentioned in the issues that seemed related
[07:21] <zyga> mvo: don't have it where? in the repo?
[07:21] <mvo> zyga: correct, rmadison golang tells me we are on 1.10
[07:21] <mvo> zyga: even in disco
[07:21] <zyga> understood
[07:22] <mvo> zyga: aha, sorry - we have 1.11 in disco
[07:22] <mvo> zyga: as non-default but only disco, I doubt we will get a lot of support when we try to get this backported into xenial,bionic and trusty :/
[07:24] <mborzecki> mvo: iirc the official policy is use the latest and n-1 releases, otherwise you're on your own
[07:24] <pedronis> yes
[07:24] <pedronis> so we need to discuss
[07:25]  * mvo nods
[07:25] <mborzecki> we'd probably need to start with having 1.11/12 packaged
[07:30]  * pstolowski test 123
[07:31] <pstolowski> guess it works now.. morning everyone
[07:35] <mvo> pstolowski: welcome back!
[08:01] <pstolowski> zyga: the failure on #6643 is unrelated to the PR right`?
[08:01] <mup> PR #6643: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <https://github.com/snapcore/snapd/pull/6643>
[08:02] <zyga> pstolowski: yes
[08:02] <zyga> I debugged it and the fixes are coming up soon
[08:02] <pstolowski> k
[08:02] <zyga> whhee
[08:02] <zyga> it passed :)
[08:02]  * zyga runs it a few more times
[08:06] <mup> PR snapd#6701 opened: [ONLY FOR TESTS] Refresh awareness test debug <⛔ Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6701>
[08:07] <mborzecki> zyga: do you have beaglebone black by any chance?
[08:07] <zyga> yes
[08:07] <zyga> two in  fact
[08:08] <mborzecki> ha!
[08:08] <mborzecki> zyga: any chance you could load 16.04 armhf image on it and hook it up to the network?
[08:08] <zyga> sure, give me the URL and 15 minutes please
[08:09] <mborzecki> so now we just need to find a suitable image
[08:11] <zyga> do you want core  or classic?
[08:11] <zyga> classic is more convenient for this test, I suppose
[08:13] <mborzecki> zyga: classic
[08:13] <mborzecki> hm elinux used to have the images, but i see none now
[08:19] <zyga> mborzecki: let me look
[08:20] <zyga> https://elinux.org/BeagleBoardUbuntu
[08:20] <zyga> let me try one  of those
[08:20] <zyga> I'll report back soon
[08:23] <mborzecki> zyga: hm can't even locate 16.04 armhf rootfs :/
[08:24] <mborzecki> zyga: is there a core 16 image maybe? i don't see one either
[08:25] <zyga> h
[08:25] <zyga> back in the office
[08:25] <zyga> let me look at what 's on my board now
[08:27] <zyga> mvo: https://paste.ubuntu.com/p/SsqgjbFqfy/ how does this look like?
[08:35] <zyga> mborzecki: powering up
[08:35] <zyga> and nothing yet, obviously
[08:35] <zyga> I will look at flashing an image then
[08:39] <zyga> mborzecki: wait
[08:39] <zyga> it booted :D
[08:39] <zyga> woot
[08:39] <zyga> core16
[08:40] <mborzecki> well, that's good enough i think
[08:41] <zyga> let me try to log into it
[08:44] <pstolowski> Chipaca: hey, wdyt about Samuele's remark re warnings in https://github.com/snapcore/snapd/pull/6662 ? sounds reasonable to me
[08:44] <mup> PR #6662: overlord/snapstate,snapshotstate: create snapshot on snap removal (3/4) <Created by stolowski> <https://github.com/snapcore/snapd/pull/6662>
[08:44] <Chipaca> pstolowski: sounds like a separate pr to me
[08:44] <zyga> mborzecki: I have the IP address but I cannot get access yet,
[08:44] <zyga> maybe it refreshed to 2.38 :D
[08:44] <Chipaca> pstolowski: because it's not the only instance of 'this failed but nothing to do except alert the user' in snapshotstate
[08:44] <pstolowski> Chipaca: that's fine; isn't it as simple as one API call?
[08:45] <pstolowski> Chipaca: ah i see your point
[08:45] <zyga> mborzecki: when I ssh in I get logged out instantly
[08:45] <zyga> hmmm
[08:46] <Chipaca> pstolowski: but yes, it's st.Warnf(), probably
[08:46] <zyga> I've attachec a keyboard
[08:46] <zyga> and ... no luck?
[08:47] <zyga> connection closed again
[08:47] <zyga> I rebooted
[08:47] <zyga> odd
[08:49] <mborzecki> zyga: maybe it's updating?
[08:49] <zyga> maybe
[08:49] <mborzecki> zyga: do you have console attached?
[08:49] <zyga> I will leave it for 15 minutes
[08:49] <zyga> mborzecki: console?
[08:49] <zyga> serial?
[08:49] <zyga> no
[08:49] <mborzecki> zyga: yeah
[08:49] <zyga> I have a display
[08:49] <zyga> but keyboard doesn't interact with it
[08:50] <mborzecki> zyga: not once have i used display with bbb :D
[08:50] <mborzecki> zyga: if it's an old core iamge, it might be getting updated now
[08:51] <mborzecki> btw. figured out why the addresses are so high for the the PIE binaries on that kernel
[08:51] <zyga> mborzecki: woot
[08:51]  * zyga is really impressed by the debugging on this issue
[08:51] <zyga> fantastic work guys!
[08:52] <mborzecki> https://paste.ubuntu.com/p/c8MQWPy7fn/
[08:52] <mborzecki> it's actually kernel config, need to check what's used elsewhere
[08:53] <mborzecki> oh, and the address changed over kernel versions, 5.x seems to use 0x40000000
[08:53] <mborzecki> as in fixed
[08:57] <mvo> mborzecki: nice job! so if CONFIG_PAGE_OFFSET = 0xc0000000 was lower things must also work?
[08:58] <mborzecki> mvo: 'may' :P
[08:58] <mvo> mborzecki: yeah, not asking for this, just curious
[08:58] <mvo> mborzecki: is ELF_ET_DYN_BASE = 0x7f555555 derived from this config somehow?
[08:58] <mborzecki> mvo: yes, see the paste
[08:59] <mvo> mborzecki: aha, nice, yeah, now I see it
[08:59] <mvo> mborzecki: great job
[08:59] <mvo> mborzecki: that was pretty hard to debug, thanks for all the effort here
[09:10] <Chipaca> on core, what's the easiest way of knowing if i'm core18 or core16?
[09:10] <Chipaca> also, on core18, can i remove core?
[09:10]  * Chipaca is about to try it but thought he'd ask first
[09:11] <mvo> zyga: it looks like build-id is available everywhere (or the system-key spread test is broken)
[09:11] <zyga> mvo: +1
[09:11] <mvo> zyga: would you mind double checking ? just "go build github.com/snapcore/snapd/cmd/snap -o /tmp/lala" file /tmp/lala
[09:11] <mvo> zyga: to see if there is a build-id?
[09:11] <mvo> zyga: on suse
[09:11] <zyga> checking now
[09:11] <mvo> zyga: again, just as an extra pre-caution
[09:12] <mvo> zyga: thank you!
[09:12] <zyga> zyga@yantra:/tmp> go build -o lala github.com/snapcore/snapd/cmd/snap; file lala
[09:12] <zyga> lala: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=43261688d0e2e49bede15de8619def1bbea5e0fa, for GNU/Linux 3.2.0, not stripped
[09:12] <zyga> looks ok
[09:13] <zyga> perhaps that aspect of go has changed in suse since
[09:13] <zyga> +1 from me
[09:19] <mvo> zyga: \o/
[09:19] <mvo> zyga: yeah, I think it did
[09:19] <mvo> zyga: (but a quick google search did not bring up anything interessting :/
[09:20] <zyga> mborzecki: one more try, if it fails I will reflash
[09:42] <zyga> mborzecki: fixed auth
[09:42] <zyga> mborzecki: I can now log in
[09:44] <zyga> mborzecki: I'm refreshing core to stable
[09:44] <zyga> it was running a local build
[09:45] <zyga> mborzecki: I will install some more tools
[09:46] <zyga> mborzecki: do you still need access?
[09:47] <mborzecki> zyga: yes, that'd be great
[09:47] <zyga> k
[09:47] <zyga> mborzecki: how do we add an user to an existing system?
[09:47] <mborzecki> oh
[09:47] <mborzecki> haha
[09:48] <mborzecki> snapd api?
[09:49] <zyga> perhaps
[09:49] <zyga> it's still installing a few things
[09:49] <zyga> mborzecki: what kind of username do you prefer on my gateway?
[09:50] <mborzecki> zyga: mborzecki?
[09:50] <zyga> k
[10:03] <zyga> mborzecki: ping
[11:09] <zyga> https://github.com/snapcore/snapd/pull/6702 <- refresh-app-awareness fixes
[11:09] <mup> PR #6702: tests: fixes discovered debugging refresh-app-awareness <Created by zyga> <https://github.com/snapcore/snapd/pull/6702>
[11:09] <mup> PR snapd#6702 opened: tests: fixes discovered debugging refresh-app-awareness <Created by zyga> <https://github.com/snapcore/snapd/pull/6702>
[11:10] <zyga> mborzecki, mvo : ^
[11:10] <zyga> please look, it's affecting master
[11:11] <mvo> zyga: thanks
[11:11] <zyga> if you feel like it I will gladly split this into core vs test fixes
[11:12] <mborzecki> ogra: hi, any clue where i can find the source code of linux-generic-bbb 4.4.0-93-1 rev 21 kernel?
[11:12] <ogra> mborzecki, apt-get source linux (in xenial)
[11:13] <ogra> mborzecki, it is only re-packing the binary deb
[11:13] <mborzecki> ogra: ah, excellent then
[11:13] <ogra> (might be a bit behind in versions though)
[11:14] <ogra> mborzecki, for core18 images, you can use the pc-kernel snap, in core18 we have an officially supported armhf build from the kernel team, so there is no need anymore for my hackish bbb kernel
[11:15] <ogra> http://people.canonical.com/~ogra/snappy/pocketbeagle/ uses it ...
[11:20] <mup> PR snapd#6701 closed: [ONLY FOR TESTS] Refresh awareness test debug <⛔ Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6701>
[11:24] <zyga> Chipaca: hey
[11:24] <zyga> Chipaca: shall I merge https://github.com/snapcore/snapd/pull/6621 now?
[11:24] <mup> PR #6621: overlord/snapstate: track time of postponed refreshes <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6621>
[11:25] <Chipaca> zyga: sure
[11:25] <zyga> cool, thank you
[11:26] <mup> PR snapd#6621 closed: overlord/snapstate: track time of postponed refreshes <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6621>
[11:26] <zyga> pedronis: hey, I noticed you were looking at https://github.com/snapcore/snapd/pull/6690
[11:26] <zyga> do you have any idea about time.Time comparison?
[11:26] <mup> PR #6690: overlord/snapstate: inhibit refresh for up to a week <Created by zyga> <https://github.com/snapcore/snapd/pull/6690>
[11:26] <pedronis> yes, I'll comment there in a bit
[11:27] <pedronis> (not the most important thing overall but I got curious)
[11:27] <zyga> cool, I'm eager to see what you found out
[11:27] <zyga> it depends on TZ that is different in tests and on local machines, I didn't dig deeper though
[11:37] <ogra> just add a snap that sets the timezone (iz trivial) :)
[11:44] <pedronis> zyga: commented there
[11:44] <zyga> checking
[11:50] <pstolowski> re
[12:03] <cmatsuoka> do we run binaries using an explicit elf interpreter at some point?
[12:04] <cmatsuoka> I'm having a problem with binaries with patched interpreters, but only when running with an explicit interpreter, and only on s390x :\
[12:26] <cachio> mvo, pedronis zyga pstolowski mborzecki Chipaca cmatsuoka hey, I am having troubles with freenode, please if you need to contact me today please find me in the internal snappy channel
[12:27] <zyga> ack
[12:32] <Chipaca> pedronis: all the tests pass \o/
[12:32] <Chipaca> pedronis: they really shouldn't /o\
[12:32]  * Chipaca is having fun
[12:48] <dot-tobias> jdstrand / ogra: I'm using the timezone-control interface on Core 16 (Raspi 3). No denials and the timezone shows up in timedatectl briefly, but afterwards timedatectl as well as date revert back to UTC. If I set the TZ with sudo timedatectl via SSH, it sticks. Am I doing something wrong, or is https://bugs.launchpad.net/snappy/+bug/1733881 affecting this?
[12:48] <mup> Bug #1733881: timezone set to n/a on ubuntu core <Snappy:Confirmed> <https://launchpad.net/bugs/1733881>
[12:49] <dot-tobias> ^ addendum: My app calls systemd-timezoned via DBus (tried with Ruby gem ruby-dbus as well as a test shell script which invokes dbus-send)
[12:53]  * jdstrand_ defers to ogra (I would expect the dbus interface to work)
[13:10] <ogra> dot-tobias, it only gets reset on reboot right ?
[13:19] <dot-tobias> ogra: Just rebooted to confirm, I think I'm hitting two issues here: 1) timedatectl does not retain timezone information across reboots, but date +"%Z %z" still has proper output 2) when I set the timezone via DBus from a snap (as opposed to sudo timedatectl via SSH), /etc/writable/localtime is not written and not symlinked to /etc/localtime, thus both date and timedatectl report UTC
[13:20] <ogra> dot-tobias, i have a hack to work around this ... gimme a bit
[13:21] <dot-tobias> ogra: Great, thanks!
[13:30] <ogra> dot-tobias, this should work (untested) https://github.com/ogra1/timezone-snap
[13:30] <ogra> just install it in your image and make sure timezone-control is connected for it
[13:33] <dot-tobias> ogra: Thank you! Will try out and let you know. FWIW: Is this also required on Core 18? Otherwise I could migrate my snap to core18
[13:34] <ogra> i think core18 will have the same issue ... there was another bug in core18 (cant set any of hostname, timezone or locale) that i'm not sure is completely fixed yet
[13:44] <mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[13:44] <mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[13:44] <mup> PR core#104 closed: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
[13:45] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[13:45] <mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[13:45] <mup> PR core#104 opened: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
[13:52] <zyga> https://github.com/snapcore/snapd/pull/6702 <= please review to fix master
[13:52] <mup> PR #6702: tests: fixes discovered debugging refresh-app-awareness <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6702>
[14:13]  * zyga breaks for lunch
[15:04] <mup> PR snapcraft#2528 opened: packaging: use our patchelf branch <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2528>
[15:20] <pedronis> Chipaca: have you seen this:  https://bugs.launchpad.net/snapd/+bug/1823768 ?
[15:21] <mup> Bug #1823768: snap refresh failure during task: Consider re-refresh of snap: snap has "refresh-snap" change in progress <snapd:New> <https://launchpad.net/bugs/1823768>
[15:21] <Chipaca> pedronis: i had not
[15:22] <pedronis> Chipaca: it seems we are detecting a self-conflict with the change, or we are missing something
[15:23] <Chipaca> yep
[15:23] <pedronis> Chipaca: can I assing to you, to look at it when you have some time?
[15:27] <Chipaca> pedronis: yep
[15:27] <pedronis> thx
[15:51] <zyga> Chipaca: could you do a 2nd review on https://github.com/snapcore/snapd/pull/6702 please
[15:51] <mup> PR #6702: tests: fixes discovered debugging refresh-app-awareness <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6702>
[15:51] <mup> Bug #1823988 opened: CAP_NET_ADMIN not being provided with the recommended plugs <Snappy:New> <https://launchpad.net/bugs/1823988>
[15:52] <Chipaca> zyga: +1
[15:53] <zyga> Chipaca: thank you!
[15:53] <mup> PR snapd#6702 closed: tests: fixes discovered debugging refresh-app-awareness <⚠ Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6702>
[15:56] <mup> PR snapcraft#2529 opened: build providers: idempotent destroy for LXD <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2529>
[15:57] <mup> PR snapd#6703 opened: tests: add deferred actions <Created by zyga> <https://github.com/snapcore/snapd/pull/6703>
[16:06] <oSoMoN> jdstrand, there's a couple of chromium snap revisions awaiting manual approval, if you don't mind approving those
[16:06] <jdstrand> oSoMoN: yep, I saw earlier. I'll get to them in a bit
[16:07] <oSoMoN> thanks
[16:09] <zyga> Chipaca: updated https://github.com/snapcore/snapd/pull/6690 based on pedronis review, could you have one last look before merging
[16:09] <mup> PR #6690: overlord/snapstate: inhibit refresh for up to a week <Created by zyga> <https://github.com/snapcore/snapd/pull/6690>
[16:09] <zyga> jdstrand: hey, how are you doing :)
[16:09] <Chipaca> no
[16:09]  * Chipaca closes his eyes and goes LA LA LA LA
[16:10] <Chipaca> zyga: it's a-ok
[16:11] <jdstrand> zyga: I'm good. you? lots of meetings today. plan on picking up more PR reviews toady
[16:11] <zyga> jdstrand: good, feel happy about making progress lately :)
[16:11] <zyga> jdstrand: also endless debugging of shell :)
[16:11] <zyga> jdstrand: also some improvement towards better shell tests
[16:11] <zyga> jdstrand: good luck with the meetings, don't get lost in them
[16:11] <jdstrand> nice :)
[16:12] <jdstrand> they're done now. got some takeaways to get to right away, but hopefully can finish the PR reviews then pickup daemon user tomorrow
[16:14] <zyga> jdstrand: question, do you want to review https://github.com/snapcore/snapd/pull/6643
[16:14] <mup> PR #6643: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <https://github.com/snapcore/snapd/pull/6643>
[16:14] <zyga> it's the regression test and helper program for the ioctl bug
[16:18] <jdstrand> zyga: nah. I looked at it before. I only care about the result cause it is just build code and we have spread tests that will detect if we generate it wrong
[16:21] <zyga> jdstrand: +1
[16:22] <mup> PR snapd#6704 opened: overlord/devicestate,snapstate: measurements around ensure and related tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6704>
[16:25] <zyga> I think I should break now
[16:25] <zyga> jdstrand: one last word today: I noticed your branch and I will get to it soon, some of the changes there collide with upcoming changes to group handling but I will deconflict those as conflicts arise in, either branch
[16:26] <jdstrand> zyga: ack
[16:26] <jdstrand> I can deconflict too, but if you're keen to do it, that works
[17:05] <mup> PR snapcraft#2528 closed: packaging: use our patchelf branch <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2528>
[17:05] <Chipaca> zyga: getopt, not getopts
[17:05] <Chipaca> zyga: util-linux, not bash
[17:06] <Chipaca> oh wait your comment was about local
[17:06] <Chipaca> hm
[17:06] <zyga> Chipaca: thank you for the review!
[17:07] <Chipaca> zyga: /bin/sh also has 'local'
[17:07] <zyga> Chipaca: I replied, happy to iterate on the points raised
[17:07] <zyga> Chipaca: /bin/sh may have it but it is not POSIX and shellcheck complains
[17:07] <zyga> Chipaca: but I will adjust the shebang and use local happily
[17:07] <Chipaca> ah ok
[17:08] <zyga> Chipaca: I'm very curious about the RETURN idea, can you tell me more please
[17:08] <zyga> Chipaca: ideally scope would be gone
[17:08] <zyga> Chipaca: and defer would do the right thing by sourcing the file
[17:08] <zyga> Chipaca: if it wasn't for prepare/restore it would be totally useless
[17:16] <Chipaca> zyga: well, the execute thing is run inside a function, right?
[17:17] <zyga> Chipaca: perhaps... I don't know
[17:17] <zyga> I think they are all concatenated internally
[17:17] <zyga> we could look at spread source code or at spread -vv output
[17:17] <Chipaca> hm
[17:18] <Chipaca> something for tomorrow, if it's me doing it
[17:18] <Chipaca> I'm gonna EOD
[17:18] <Chipaca> zyga: you should too :-)
[17:18] <zyga> Chipaca: gladly
[17:18] <zyga> Chipaca: thank you for the review!
[17:18] <Chipaca> np! looks good
[17:18] <zyga> Chipaca: defer review :)
[17:26] <mup> PR snapcraft#2525 closed: catkin plugin: check stage-snaps for ROS dependencies <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2525>
[19:02] <mup> PR snapcraft#2529 closed: build providers: idempotent destroy for LXD <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2529>
[22:51] <mup> PR snapd#6705 opened: bootloader: little kernel support <Created by kubiko> <https://github.com/snapcore/snapd/pull/6705>