[00:01] <scientes> how do i compile "snap" command in order to test it?
[00:01] <scientes> before i submit a patch
[00:01] <scientes> shawn@shawn-desktop:~/git/snapd$ go get github.com/snapcore/snapd
[00:01] <scientes> package github.com/snapcore/snapd: no Go files in /home/shawn/go/src/github.com/snapcore/snapd
[00:10]  * scientes just found HACKING.md
[05:08] <mborzecki> morning
[05:22] <zyga> Hi
[05:24] <mborzecki> zyga: new, intersting developments from flock?
[05:24] <zyga> some hands-on session on AWS CLI snap
[05:25] <zyga> our presentation is today so I'llbe focusing on that
[05:25] <zyga> what is wrong with master? /home/gopath/src/github.com/snapcore/snapd/tests/lib/prepare.sh: line 413: 1: command not found
[05:25] <zyga> + /snap/bin/ubuntu-image -w /home/image /home/image/pc.model --channel edge '' --extra-snaps /home/image/snapd_2.34.3_amd64.snap --output /home/image/core18-amd64.img
[05:25] <zyga> /home/gopath/src/github.com/snapcore/snapd/tests/lib/prepare.sh: line 288: 29999 Segmentation fault      (core dumped) /snap/bin/ubuntu-image -w "$IMAGE_HOME" "$IMAGE_HOME/pc.model" --channel "$IMAGE_CHANNEL" "$EXTRA_FUNDAMENTAL" --extra-snaps "${extra_snap[0]}" --output "$IMAGE_HOME/$IMAGE"
[05:28] <zyga> mborzecki: can you please ask mvo to ack the last two revisions of fedora29 again
[05:29] <zyga> mborzecki: unfortunately the store has no memory so it blocks every upload I do
[05:34] <mborzecki> zyga: https://github.com/snapcore/snapd/pull/5625
[05:36] <mborzecki> zyga: anyways, for all we know that check will be passing now, but the segfault will probably still be there
[05:36] <zyga> thanks
[06:05] <mborzecki> zyga: maciek@corsair:~ ubuntu-image --help
[06:05] <mborzecki> zsh: segmentation fault (core dumped)  ubuntu-image --help
[06:05] <zyga> Must be Friday
[06:07] <mborzecki> zyga: all channels have the same version, it's also a classic snap, maybe it's something else that's causing this
[06:23] <zyga> mborzecki: could be
[06:23] <mborzecki> zyga: can you install ubuntu-image snap locally?
[06:25] <zyga> re
[06:25] <zyga> mborzecki: trying
[06:26] <zyga> it doesn't crash here
[06:26] <zyga> but then python complains about lack of dpkg
[06:27] <zyga> is mvo around today?
[06:31] <zyga> mvo: hello
[06:31] <zyga> mvo: may I ask you to approve fedora29 uploads again
[06:31] <mvo> zyga: goood morning! when is your presentation?
[06:31] <mvo> zyga: sure
[06:31] <zyga> mvo: 11:20
[06:31] <zyga> mvo: I found some more bugs but worked around them
[06:32] <zyga> mvo: and this should also make it work on ubuntu now
[06:32] <mvo> zyga: you can always telegram me when things are urgent
[06:32] <mvo> (just btw)
[06:32] <mvo> zyga: nice!
[06:32] <zyga> mvo: thank you! I didn't want to bother you last night
[06:33] <zyga> mvo: https://gitlab.com/zygoon/fedora29 in case you want to cross ref what you approve
[06:33] <mvo> zyga: thanks looking
[06:33] <zyga> there are tags referencing store uploads
[06:34]  * zyga is pretty happy with the makefile there :)
[06:35] <mborzecki> zyga happy with the makefile :) heh
[06:35] <zyga> it looks nice as a makefile :)
[06:36] <mborzecki> hehe
[06:37] <mborzecki> yay, only 3 builds for snapcraft left, meaning snapd will start soon right?
[06:38] <zyga> mvo: thank you, you should be able to refresh fedora29 now
[06:38] <zyga> and it, _fingers crossed_ should work
[06:38] <mborzecki> zyga: i'm stepping through ubuntu-image with gdb now, take a look at this https://paste.ubuntu.com/p/RQWc2Rcr2f/
[06:39] <mborzecki> that's why snap run --shell also exits with a segfault here
[06:39] <zyga> mborzecki: woah?
[06:39] <zyga> I have no idea why this would crash, do you have any clues?
[06:41] <mborzecki> zyga: heh, LD_LIBRARY_PATH=/snap/ubuntu-image/100/usr/lib:/snap/ubuntu-image/100/lib:/snap/ubuntu-image/100/usr/lib/lib-arch:/snap/ubuntu-image/100/lib/lib-arch /bin/bash -> segfault
[06:42] <zyga> mborzecki: which linker is this using?
[06:44] <zyga> mvo, mborzecki: is hello-fedora working for you guys now?
[06:44] <mborzecki> zyga: the host's, the segfault is actually in the liner #0  0x00007f7c49694b31 in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
[06:44] <zyga> mborzecki: that's the bug
[06:44] <zyga> it should use ld-so from the core snap
[06:46] <mborzecki> zyga: but it's a script, https://paste.ubuntu.com/p/XGsxrdjTWP/
[06:46] <zyga> right
[06:46] <zyga> but _broken_
[06:47] <zyga> it must invoke the linker
[06:47] <zyga> to avoid using the host linker
[06:47] <zyga> but anyway
[06:47] <zyga> why did it break, what changed?
[06:47] <mborzecki> let me check some other classic snaps
[06:47] <mborzecki> zyga: there was a glibc & python update i believe
[06:49] <zyga> mborzecki: try python0
[06:49] <zyga> it should work everywhere
[06:49] <zyga> but it was made by me
[06:49] <zyga> so it's a bit more special
[06:49] <zyga> if that crashes then the world is broken
[06:49] <mborzecki> zyga: heh upgraded glibc (2.27-3 -> 2.28-1)
[06:49] <zyga> it if works then we can look for more clues
[06:50] <mvo> mborzecki: good morning!
[06:50] <mborzecki> mvo: heya
[06:51] <mvo> btw, I see red tests in the most recent PRs, anything going on with CI? or just some bad PRs ;)
[06:51] <mvo> zyga: let me check
[06:51] <zyga> mvo: ubuntu-image segvfaults
[06:51] <zyga> mvo: maciej is looking at that
[06:51] <mvo> boooo
[06:51] <mvo> mborzecki, zyga: thanks
[06:51] <mvo> heh
[06:51] <mvo> there was a new release
[06:52] <mvo> and it went all the way from edge to stable with a single push
[06:52] <mvo> because …
[06:52] <mborzecki> reasons
[06:53] <mvo> mborzecki: where do we pull from? beta/edge? stable?
[06:53] <mborzecki> well slack works, python0 works, so it's ubuntu-image that's borked
[06:53] <mborzecki> mvo: same version in every channel
[06:53] <mvo> mborzecki: yeah, I think I have the privs to "fix" that
[06:53] <mvo> mborzecki: I just need to know where we pull from
[06:53] <mborzecki> mvo: edge
[06:53] <mvo> mborzecki: excellent
[06:54] <mvo> mborzecki: fixed
[06:54] <mborzecki> mvo: refreshing
[06:54] <mvo> mborzecki: and next we need to have a word with the uploader of the snap :)
[06:55] <mborzecki> lukasz? :)
[06:55]  * mvo won't name names
[06:56] <mborzecki> mvo: https://paste.ubuntu.com/p/pXgtFBFVHd/ better, at least no segfault, no clue if it's intended to be used outside of ubuntu though ;)
[06:56] <mvo> mborzecki: heh
[06:56] <mvo> mborzecki: why on earth would it need dpkg?
[06:56] <mvo> mborzecki: well, I guess I should look at the code to answer that
[06:57] <mborzecki> mvo: well, why it's not bundled in the snap? :)
[06:57] <mvo> mborzecki: looks like its using it to detect its own arch
[06:57] <mvo> mborzecki: another great question
[06:59] <mborzecki> wow, snapcraft travis jobs are really ~7h long?
[06:59] <mvo> mborzecki: to be fair it looks like the snapcraft.ymal has not changed
[07:00] <mvo> mborzecki: so maybe a snapcraft change broke u-i
[07:00] <mvo> mborzecki: it was failing inside travis too, right? not just on arch?
[07:00] <mvo> mborzecki: I think thats correct, snapcraft runs a ton of integration tests that build stuff (at least AIUI)
[07:00] <mborzecki> mvo: yes, my guess is some library pulled in through LD_LIBRARY_PATH got updated/changed
[07:01] <mvo> mborzecki: ok
[07:01] <mborzecki> mvo: https://paste.ubuntu.com/p/vFfwvBsHH7/
[07:02] <mvo> mborzecki: nice!
[07:02] <mvo> mborzecki: I also like your hostname in the pastebin :)
[07:02] <mborzecki> mvo: whatever it is it's inside /snap/ubuntu-image/100/lib/lib-arch
[07:03] <mvo> mborzecki: there is probably a lot inside there
[07:04] <pstolowski> mornings!
[07:04] <mborzecki> mvo: i see mostly glibc, readline
[07:04] <mborzecki> pstolowski: hey
[07:06] <mborzecki> mvo: well, maybe libc shouldn't be there after all https://paste.ubuntu.com/p/KhT6SbWYj4/ it's not there in rev 98 which works
[07:07] <zyga> pstolowski: hey
[07:07] <zyga> pstolowski: can you do a quick test for me please
[07:08] <mborzecki> zyga: hello-fedora still works
[07:08] <zyga> mborzecki: thank you!
[07:09] <mvo> mborzecki: worth a shoot
[07:10] <mvo> zyga: I have fedora29 r9 and hello-fedora r5 but still get the error launching it but I don't have the latest snapd maybe
[07:10] <mvo> zyga: same missing file error
[07:10] <zyga> mvo: you should not need the lasted snapd
[07:10] <zyga> drat :/
[07:10] <zyga> ok, thank you
[07:10] <zyga> (perhaps you do, because the fix in dirs.go)
[07:10] <zyga> the hack I did only works on simpler implementation in snap-confine
[07:10] <zyga> that's okay
[07:10] <zyga> thank you for trying
[07:11] <zyga> mvo: I suspect swapping ID=... lines in $SNAP/usr/lib/os-release in fedora29 would fix it
[07:11] <zyga> mvo: if you want to unpack the squashfs and "snap try" it to check
[07:11] <zyga> but don't worry, it's better to fix this through mater
[07:13] <mvo> zyga: once your snapd PR lands it will work, no?
[07:13] <zyga> mvo: I think so, yes
[07:13] <mvo> zyga: if so, lets just make sure it does land
[07:13] <zyga> mvo: it's passing tests
[07:13] <zyga> (except core prepare is broken)
[07:13] <zyga> yeah
[07:17] <pstolowski> mborzecki: hey, do you have any PR you want reviewed?
[07:17] <pstolowski> mborzecki: i mean, you have a few, but what's the 1st in the queue?
[07:17] <mborzecki> pstolowski: https://github.com/snapcore/snapd/pull/5614 if you could
[07:18] <pstolowski> sure
[07:18] <mborzecki> pstolowski: thanks
[07:22] <zyga> mvo, mborzecki: should we disable core if we cannot fix ubuntu-image for a while?
[07:22] <mvo> zyga: it is "fixed"
[07:22] <mborzecki> zyga: it should be possible now
[07:23] <zyga> Son_Goku: I'm happy with the slides, I think
[07:24] <mborzecki> zyga: do you have the slide deck available anywhere?
[07:24] <zyga> https://docs.google.com/presentation/d/1Vf3wfC8O7D4_f_zyPBvvy6U6YBBRQd_3ncR6sWszTQM/edit?usp=sharing
[07:25] <zyga> it's mostly a "talking" presentation so we have a few slides but most of the content will be verbal
[07:28] <zyga> suggestions welcome!
[07:29] <mborzecki> zyga: nice
[07:35]  * sil2100 ordere
[07:35]  * sil2100 ordered a raspi3
[07:35] <sil2100> (cat's tail pressed enter too soon)
[07:37] <mvo> sil2100: yay
[07:42] <luk3yx> Is there any way to rename a snap's internal name without deleting and re-adding it?
[07:44] <zyga> Son_Goku: snap install copr #
[07:44] <zyga> # exercise for the reader
[07:44] <Son_Goku> :D
[07:44] <mvo> mborzecki: https://github.com/CanonicalLtd/ubuntu-image/pull/157 should fix the issue of running ubuntu-image on arch
[07:45] <sil2100> grrr
[07:45] <mborzecki> mvo: ta
[07:46] <sil2100> mvo: oh! Yeah, none of us really thought about u-i on a non-ubuntu system ;)
[07:46] <mvo> sil2100: yeah, I haven't either, just mborzecki did
[07:46] <mvo> :)
[07:46]  * mvo hugs mborzecki 
[07:47] <Chipaca> wait. There are non-ubuntu systems?!?
[07:47] <Chipaca> this changes everything
[07:47]  * Chipaca tries "snap changes everything" just to make sure
[07:47] <sil2100> Chipaca: apparently!
[07:47]  * Chipaca grins like an idiot
[07:54] <mborzecki> mvo: yup, i can run ubuntu-image --help now :)
[07:55] <mborzecki> btw.  took a bit of trial & error to track down all dependencies with a clean venv
[07:55] <mvo> mborzecki: *nod*
[07:55] <mvo> mborzecki: thanks for confirming
[07:59] <Gargoyle> Hi all.
[08:07] <Gargoyle> I'm just setting up a new company laptop with Fedora 28, and I could not run "sudo lxd init". I just came back with "command not found". However, running it without the "sudo" worked fine.
[08:08] <Chipaca> Gargoyle: sudo's path is probably different to your user's path
[08:08] <Gargoyle> Am I likely to run into issues further down the line - if I've done something wrong early on, I'd prefer to catch it now than in a few days time when I have everything setup on the system.
[08:11] <mvo> Chipaca: I noticed that inside cmd/snap ; go test will fail for me. it looks like it will print the new (nice) green checkmarks but the tests do not expect those
[08:11] <mvo> Chipaca: is that just me?
[08:11] <mvo> Chipaca: when i run "go test | more" its fine again
[08:11] <Chipaca> mvo: let me see...
[08:12] <Chipaca> mvo: how do you run it, exactly?
[08:13] <mvo> Chipaca: I "cd cmd/snap ; go test"
[08:13] <mvo> Chipaca: inside a mate terminal
[08:14] <Chipaca> mvo: huh
[08:14] <Chipaca> mvo: and what about 'go test .'?
[08:19] <mvo> Chipaca: that is fine
[08:19] <mvo> Chipaca: interessting
[08:19] <Chipaca> mvo: here it fails with a dbus error
[08:19] <mvo> Chipaca: wuut? what does it try to talk to?
[08:19] <Chipaca> ... value *errors.errorString = &errors.errorString{s:"cannot obtain bus name 'io.snapcraft.Launcher'"} ("cannot obtain bus name 'io.snapcraft.Launcher'")
[08:20] <Chipaca> mvo: test runner is weird
[08:20] <Chipaca> mvo: results change depending on whether I set -v or not
[08:20] <mvo> might be something inside our test not properly mocked
[08:21] <Chipaca> mvo: 'go test -v .' -> colour errors
[08:21] <Chipaca> mvo: 'go test .' -> just the dbus error (also present with -v)
[08:21] <mvo> Chipaca: go test -v gives me also the \x1b bits inside the test output
[08:23] <Chipaca> mvo: so, the colours in the output mean that Stdout is a terminal
[08:23] <mvo> Chipaca: yeah, I wonder why. this is normal bionic
[08:24] <Chipaca> mvo: this here is "normal" xenial
[08:24] <Chipaca> mvo: I'll dig into it and see what i learn
[08:24] <mvo> Chipaca: aha! can you please try with "go1.10" from the snap? I will try with go 1.6
[08:24] <Chipaca> mvo: ah,  about the same with a snapped 1.10
[08:27] <mvo> Chipaca: yeah, no difference for me either
[08:28] <Chipaca> sigh
[08:28] <Chipaca> mvo: the problem probably arises because colour support checks whether stdout is a terminal just once
[08:29] <Chipaca> mvo: so it needs mocking in tests
[08:29] <Chipaca> mvo: I don't know why it only needs mocking in some cases and not in others
[08:31] <Chipaca> mvo: doing this now fwiw
[08:34] <mvo> Chipaca: ta
[08:35] <Chipaca> mvo: could i get a review of #5617?
[08:36] <mvo> Chipaca: yes
[08:46] <Chipaca> mvo: when you run the tests, do you have a "DBUS_SESSION_BUS_ADDRESS" env var?
[08:47] <mvo> Chipaca: I do have that set
[08:47] <Chipaca> mvo: here I need to explicitly unset it for tests to pass when running from the directory (but not otherwise)
[08:48] <Chipaca> mvo: the funny thing is testutil/dbustest.go saves that env var but doesn't unset it nor set it to anything
[08:48] <Chipaca> mvo: so i'm not sure what's supposed to be doing it
[08:48] <mvo> Chipaca: woah
[08:49] <Chipaca> mvo: ikr
[08:49] <Chipaca> in any case, pr coming with these fixes
[08:51] <mvo> Chipaca: \o/
[08:54] <mborzecki> pstolowski: hey, got a question about udev, udev monitor will start before dumping current device db right?
[08:55] <pstolowski> yes, this will be visible in the PR i'm working on which integrates monitor and udevadm parser
[08:56] <mborzecki> ah ok
[08:56] <pstolowski> mborzecki: i'm starting the monitor and queue monitor events until db dump finishes, then i flush accumulated events
[08:57] <mborzecki> pstolowski: then dedup is based on devpath/devname?
[08:58] <Chipaca> mvo: https://github.com/snapcore/snapd/pull/5627 addresses the 'go test' weirdness
[09:01] <pstolowski> mborzecki: not sure yet, probably, i haven't tought much about that aspect yet
[09:28] <Chipaca> boo
[09:28] <Chipaca> Failed project prepare: 4
[09:28] <Chipaca> boooh
[09:34] <mborzecki> Chipaca: hmm something isn't right https://paste.ubuntu.com/p/JmVDynrPCF/
[09:36] <Chipaca> mborzecki: mhmm
[09:45] <Chipaca> mborzecki: ah
[09:45] <Chipaca> mborzecki: i think i know what's happening
[09:45] <mborzecki> Chipaca: takes a while for socket to appear
[09:45] <Chipaca> mborzecki: exactly :-)
[09:45] <Chipaca> we don't wait for it to start
[09:46] <mborzecki> Chipaca: added a loop with 20s wait, but still no socket, maybe it's started wrong?  http://paste.ubuntu.com/p/VnwfFwjn4s/
[09:46] <Chipaca> mborzecki: are you fixing it, or should i?
[09:47] <mborzecki> Chipaca: go ahead :P
[09:48] <Chipaca> k
[09:49] <mborzecki> omg silly me
[09:51] <mborzecki> Chipaca: http://paste.ubuntu.com/p/mwvRRjjqzf/ if you want to use it
[09:58] <Chipaca> mborzecki: want to try https://pastebin.ubuntu.com/p/mX8x6BZDps/ ?
[09:58] <mborzecki> nice
[09:59] <Chipaca> mborzecki: interestingly the printed address looks like unix:path=/tmp/check-6227058902689785204/0/user_bus_socket,guid=c22feadfc799529b07be91f75b6d603a
[10:00] <mborzecki> Chipaca: works all right here
[10:10] <mborzecki> Chipaca: don't know if you got that, your patch works fine
[10:10] <Chipaca> mborzecki: i hadn't, thank you
[10:10] <Chipaca> i'll push it now
[10:11] <Chipaca> mborzecki: did you get the bit about how the printed address has more stuff than just user_bus_socket?
[10:12] <mborzecki> yeah, saw that here too, apparently it's not critical as i was doing setenv without that and it worked too
[10:21] <Chipaca> mborzecki: I could've also done --print-pid and waited for that
[10:21] <Chipaca> eh, it works this way
[10:21] <Chipaca> w/e
[10:47] <ogra> mvo, did the pi3 gadget ever get updated in stable to include all the gpio interfaces (it is in edge since 1.5y, but i dont know if/when you pushed pi3 into stable)
[10:48] <ogra> (i'D have expected it to be updated along with the push of pi2-kernel to stable)
[10:49] <mvo> ogra: it has not bee updated
[10:49] <ogra> damn
[10:49] <mvo> ogra: the kernel is done by the kernel team they can't push the gadgets
[10:50] <mvo> ogra: gadgets are foundations territory nowdays
[10:50] <ogra> it has various firmware fixes for thermal and power management and the stable one seems to miss all gadget based interfaces
[10:50] <mvo> ogra: yeah, I think it should go out, we just need a) QA b) somoeone driving this :/
[10:51] <mvo> ogra: fwiw, the LP page is owned by foundations and steve has the required privs to push the snaps
[10:51] <ogra> i honestly have not run stable gadgets since the above stuff landed ... so for a) i can clearly give you a thumbs up :)
[10:52] <ogra> and *all* interfaces missing is clearly a downer
[10:52] <Chipaca> my network is having a fun day
[10:53] <Chipaca> but on the other hand so is travis
[10:53] <mvo> Chipaca: and so is LP - arm builds are very slow (the builders look a bit overworked)
[10:56] <Chipaca> eight hour workday for workers! rabble rabble rabble
[10:56] <Chipaca> drat, i meant builders
[11:37] <zyga> hello :)
[11:37] <zyga> how are things?
[11:40] <zyga> is travis working now, it was pretty slow when I tried to use it yesterday
[11:47] <Chipaca> zyga: wrt travis, everything is terrible, slow, horrible, raining on the ice cream
[11:48] <Chipaca> zyga: Son_Goku: how's your flocking?
[11:58] <zyga> Chipaca: we're done with our presentation, it went very good
[11:58] <zyga> we had lots of questions and interaction with the audience
[11:58] <Chipaca> zyga: people weren't asleep and hung over?
[11:58] <zyga> and we have a working fedora29 base now :)
[11:58] <zyga> no, today is the first day when it's not 999999C outside
[11:59] <zyga> I still want to catch some infrastructure people to discuss the hand off
[11:59] <zyga> and the fedora project leader to get an ack of the use of the fedora log
[11:59] <zyga> logo
[12:01] <zyga> Chipaca: and people are surprisingly extremely sober
[12:01] <zyga> drink responsibly, said the spiritual ghost of jono
[12:07]  * mvo weeps about the fact that he still has no arm PPA build for snapd 2.35~pre1
[12:08] <mborzecki> need another coffee
[12:09] <mborzecki> mvo: i've updated https://github.com/snapcore/snapd/pull/5584 with your patch, thanks!
[12:09] <mvo> mborzecki: \o/ happy that you liked it
[12:10] <mborzecki> mvo: yeah, i feel like i should rewrite that snap name validation too
[12:11] <mborzecki> mvo: also played around trying to get the bits of validation code shared between update-ns and libsnap-confine-private, so far no other idea than a separate file and a symlink to update-ns, the simplicity of go build is not making it too easy
[12:16] <mvo> mborzecki: I think rewrite of the snap name validation is not a good idea
[12:16] <mvo> mborzecki: but yeah, sharing is probably hard, but I have not put much thought into it yet, its just mildly annoying
[12:19] <cachio> mvo, hey
[12:22] <mvo> cachio: hey he
[12:22] <mvo> cachio: how are you?
[12:22] <cachio> mvo, fine
[12:23] <cachio> you?
[12:23] <mvo> cachio: yeah, doing well. need more tea though
[12:23] <mvo> :)
[12:23] <cachio> hehe, I have 2 issues to fix on core 18
[12:23] <mvo> cachio: tell me more please
[12:23] <cachio> mvo, https://paste.ubuntu.com/p/Z7m38nK6VY/
[12:24] <mvo> cachio: aha, nice find. we need to kill this one I think
[12:24] <mvo> cachio: like remove the service entirely
[12:25] <cachio> mvo, yes, makes sense
[12:25] <mvo> cachio: I need to finish a PR first but once that is done I can look into it or maybe sil2100 has some spare cycles for ensuring update-motd.service is removed from core18
[12:25] <cachio> mvo, sure
[12:39] <sil2100> I can!
[12:40] <mborzecki> wow a thunderstorm
[12:41] <mvo> mborzecki: we had this yesterday - it was wild
[12:43] <mborzecki> hmm snap-update-ns segfaulting now :P
[12:45] <mborzecki> i suppose by internet will be choppy a bit today
[12:48] <ogra> mborzecki, while yoyu duck and cover, just think about the fact that the air is breathable afterwards ;)
[12:48] <ogra> (it definitely helped a lot here)
[13:23] <jdstrand> mvo: ok, responded to 5621 (twice! :)
[13:26] <mvo> jdstrand: thank you!
[13:26]  * mvo reads
[13:28] <jdstrand> mvo: let me know if what I said doesn't make sense
[13:30] <mborzecki> mvo: pre-patch version works
[13:31] <mvo> mborzecki: ok, let me look at the diff again, I wonder what I broke
[13:32] <mborzecki> mvo: well the code looks correct, maybe i broke sth when doing little tweaks
[13:32] <mvo> mborzecki: how can I reproduce? just build and copy in place and run a snap?
[13:33] <mborzecki> mvo: sec, let me see if the same happens with non instance keyed snaps
[13:34] <mborzecki> mvo: snaps without instance key work
[13:36] <mvo> mborzecki: is "go test cmd/snap-update-ns " enough to trigger the crash?
[13:37] <mborzecki> mvo: nope, the tests are passing
[13:37] <mborzecki> mvo: heh, and even the hello-world_foo is used in the test suite :)
[13:37] <mvo> mborzecki: so its crashing only when used for real(tm) ?
[13:38] <mborzecki> mvo: yes
[13:46] <jdstrand> mborzecki: fyi, https://github.com/snapcore/snapd/pull/5584#pullrequestreview-145243262
[13:47] <mborzecki> jdstrand: thanks!
[13:47] <jdstrand> mborzecki: is this the pr that you and mvo are discussing now?
[13:47] <mvo> mborzecki: I played around a bit but did not managed to reproduce
[13:47] <mborzecki> jdstrand: yes
[13:48] <jdstrand> hmm, I verified the new 'i' handling. let me look again
[13:48] <mborzecki> mvo: https://paste.ubuntu.com/p/ZGS8QwfWXt/
[13:49] <jdstrand> mborzecki: there is an off by one, no?
[13:49] <jdstrand> for (i = 0; instance_key[i] != '\0'; i++) {
[13:49] <jdstrand> ...
[13:49] <jdstrand> else if (i > 10) {
[13:50] <jdstrand> 0123456789\0: i will be 11 here
[13:50] <jdstrand> no, that's right
[13:51] <mborzecki> jdstrand: the s is +1 because of this
[13:54] <mvo> mborzecki: if you are still inside gdb, does "print instance_key[i]" yield anything?
[13:54] <mvo> mborzecki: the gdb output looks all legit or am I missing something?
[13:55] <Chipaca> looking for reviews on #5617 plz (not a trivial, unless you look at each commit individually)
[13:55] <mborzecki> mvo: replaced islower/isdigit with own code and it works (?!?)
[13:55] <mvo> mborzecki: heh
[13:55] <mvo> mborzecki: optimization this smells like (in best yoda voice)
[13:55] <mvo> mborzecki: can you build with -O0 ? is this arch/ubuntu?
[13:56] <mborzecki> mvo: i'm building with -O0
[13:56] <mvo> :(
[13:57] <mborzecki> mvo: heh :P
[13:57] <jdstrand> mborzecki: I didn't mean on the buffer, I meant on the length check, but it is fine
[13:58] <jdstrand> one thing about strsep() is that it is going to modify the string
[13:58] <mborzecki> jdstrand: yeah, there's a copy made in validate_instance_name
[13:59] <jdstrand> right, I recall verifying that was ok
[13:59] <jdstrand> mborzecki: what is the failure?
[14:00] <mvo> mborzecki: is that on arch or ubuntu? what go version and gcc --version is in use?
[14:00] <jdstrand> actally, shouldn't char s[52] = {0,}; be char s[53] = {0,};?
[14:00] <jdstrand> 40 char snap_name + 10 char instance_key + 1 NULL + 1 extra to detect overflows
[14:01] <jdstrand> doesn't that not account for the valid '_'?
[14:01] <mborzecki> jdstrand: #0  0x000000000055406e in instance_key_validate (instance_key=0x7ffe6a68b55c "foo") at bootstrap.c:286
[14:01] <mborzecki> 286             if (islower((int)instance_key[i]) || isdigit((int)instance_key[i])) {
[14:01] <mborzecki> segfaulting in this line, instance_key is "foo"
[14:01] <mvo> jdstrand: oh, I think you are correct!
[14:01] <jdstrand> some40charname_instance\0
[14:01] <mvo> mborzecki: hm, hm, that cast
[14:02] <mborzecki> mvo: added it just now to test things, but it's segfaulting without that too
[14:02] <mvo> mborzecki: hm, no, that should be fine
[14:02] <mborzecki> mvo: jdstrand: instance_key address is well within the bounds of validate_instance_name:s
[14:03] <mvo> mborzecki: does it make a difference if you only have "islower" or "isdigit" ?
[14:04] <mvo> mborzecki: of replacing it with if(instance_key[i] != '\0')
[14:04] <Son_Goku> mvo, how are we looking on getting snapd 2.35 out the door?
[14:05] <mvo> Son_Goku: its in beta now
[14:05] <mvo> Son_Goku: beta does not yet include the fedora base fix but the next one will be
[14:05] <mvo> Son_Goku: next beta will be early next week
[14:06] <Son_Goku> mvo, cool
[14:06] <Son_Goku> zyga wants me to update Fedora and my beta CentOS packages to 2.35, which is why I was asking
[14:06] <mvo> Son_Goku: +1
[14:07] <Son_Goku> the talk went really well (aside from the questions about the store), and there was definitely interest in Fedora-based snaps
[14:08] <Son_Goku> well, even the questions about the store weren't that bad, but the talk went over so well that we went ~15 minutes over time
[14:09] <Son_Goku> mainly for Q&A
[14:10] <mborzecki> mvo: omg, i'm stupid after all, it's working all right
[14:10] <mborzecki> mvo: i obviously did not built it as a static binary
[14:10] <mvo> mborzecki: puhhh, ok
[14:10] <jdstrand> mborzecki: there is an off-by-one with the strncpy() that will result in an unterminated string. you need sizeof(s) + 1
[14:11]  * mvo finds it amusing that "close()" is defined in unistd.h but open in sys/types.h
[14:12] <mborzecki> mvo: heh funny that it failed, thought that gcc has builtin primitives for isblahblah by now
[14:12] <jdstrand> mborzecki: it is interesting that because you use a for loop instead of strlen() for the length, it didn't end up being a problen,
[14:12] <mvo> mborzecki: I think there is some magic going on with these, iirc they get replaced at init time with optimized versions or something
[14:13] <mborzecki> jdstrand: thanks for double checking
[14:13] <mborzecki> mvo: and here i thought that the world is coming down :)
[14:14] <mvo> mborzecki: same here, I was really confused
[14:14] <mvo> mborzecki: thanks for getting to the bottom of it
[14:15] <jdstrand> mborzecki: the '+ 1 extra to detect overflows' actually accounts for the '_'. Perhaps it would be better to rephrase that comment to be: '// 40 char snap_name + '_' + 10 char instance_key + 1 NULL
[14:17] <mborzecki> jdstrand: ack
[14:24] <mborzecki> jdstrand: shouldn't that be `char s[53] = {0}; strncpy(s, instance_name, sizeof(s) -1);` actually?
[14:28] <jdstrand> mborzecki: yes
[14:33] <jdstrand> mborzecki: I added a comment to correct myself and adjusted the 'comment' comment
[14:34] <jdstrand> since you do want 53 to detect that overflow character, rather then just stripping it off
[14:34] <jdstrand> hopefully I'm awake now :)
[14:39] <mborzecki> mvo: jdstrand: pushed an update, thanks for your reviews
[14:40] <mborzecki> i'm off to do some shopping now, kids are waiting already :/
[15:07] <jdstrand> mvo: 5621 reviewed
[15:12] <juliank> mvo: apt install petname on cosmic with 2.35 gives me error: json: cannot unmarshal object into Go struct field .packages of type string
[15:13] <juliank> broken types?
[15:17] <mvo> juliank: uh, interessting. let me try this
[15:19] <juliank> JSON-RPC calls: https://paste.ubuntu.com/p/gny3GH5kJQ/
[15:22] <juliank> Maybe I should have used pipes, ugh, this is annoying to test...
[15:24] <juliank> Packages        []string `json:"packages"`
[15:24] <juliank> is Params struct{} is clearly wrong
[15:24] <juliank> as Packages is not a list of strings, but a list of objects describing packages
[15:24] <juliank> mvo: ^
[15:28] <mvo> juliank: aha, nice catch. I'm in a meeting right now but will get back after the meeting, feel free to push a fix if you already have an idea what is going on
[15:34] <cachio> mvo, https://paste.ubuntu.com/p/2ZFG59dc7s/
[15:34] <cachio> I found that after a timeout installing a snap
[15:35] <cachio> mvo, this is the test https://paste.ubuntu.com/p/BB6D2rmjq7/
[15:38] <mvo> cachio: hm, mount failed? protcol error again?
[15:39] <juliank> mvo: basically you need http://paste.ubuntu.com/p/fNpjhSYg9F/ as the type change for jsonRPC, not sure if other changes are needed
[15:43] <juliank> The hook works fine if the packages does not exist in apt
[15:43] <juliank> (as packages is empty then)
[15:43] <mvo> juliank: nice catch, thank you
[15:44] <juliank> probably want to extract the version struct to not repeat it 3 times
[15:45] <juliank> or just keep out the entire packages array if you don't use it yet
[15:48] <zyga> re
[15:48] <zyga> how are you doing mvo?
[15:50] <mvo> juliank: thank you!
[15:51] <mvo> juliank: I added a regression test and will work on this later tonight or monday
[15:52] <Chipaca> mvo: monday monday monday
[15:52] <Chipaca> mvo: your weekend starts in 8 minutes
[15:53] <mvo> zyga: good, thanks
[15:53] <mvo> Chipaca: heh, good point
[15:53] <zyga> mvo: yeah, do listen to Chipaca
[15:53] <zyga> mvo: how far away are you from Dresden?
[15:53] <Chipaca> well, not _always_, but this time would be good
[15:54] <mvo> zyga: the opposite side of the country - why? do you want to come over? or do you want me to come over :) ?
[15:55] <zyga> the event still runs yesterday (odd, right?) and I was thinking you could use a more casual context or you will work all the time
[15:55] <zyga> mvo: but across the country is not close enough to od thatr
[15:55] <zyga> *do thta
[15:55] <zyga> ...
[15:55]  * zyga is not doing a great job at typing
[15:58] <zyga> mvo: I saw the fedora fix was merged, thank you for that (that's a team-wide effort!)
[16:05] <mvo> zyga: yw, enjoy the rest of the event
[16:06]  * mvo takes a break
[16:25] <cachio> mvo, it seems to be
[16:51] <Chipaca> I think it's EOW time here
[16:51]  * Chipaca looks around
[16:51] <Chipaca> yeah, everybody else here is no longer working, might as well stop myself
[16:51] <Chipaca> :-D
[17:09] <sergiusens> Chipaca: speak for yourself!
[17:09] <Chipaca> sergiusens: I do!
[17:09] <sergiusens> please do, so that travis builders get freed up and we can start being productive again :-P
[17:10] <Chipaca> sergiusens: https://www.google.com/maps/@51.2565417,0.3714914,17z <- there's nobody around me working on snapd for *kilometers*
[17:10] <Chipaca> the closest are over the horizon
[17:11] <Chipaca> sergiusens: travis ate pregnant snail soup this week
[17:15] <sergiusens> probably
[17:16] <sergiusens> Chipaca: is core16 being worked on as a proper base?
[17:30] <Chipaca> sergiusens: define "being worked on"
[17:30] <Chipaca> sergiusens: yes
[17:31] <Chipaca> sergiusens: the focus of work is on core18 right now
[17:31] <Chipaca> sergiusens: core16 _will_ become, itself, the focus once everything in core18 is done
[17:31] <Chipaca> sergiusens: whereby core16 + snapd snaps will replace the core snap of old
[17:32] <Chipaca> sergiusens: waarom?
[17:39] <sergiusens> Chipaca: transparent migration? Hope it goes better than ubuntu-core -> core :-)
[17:43] <Chipaca> sergiusens: ubuntu-core -> core was *fine*
[17:46] <sergiusens> Chipaca: yeah, after all the errors were fixed ;-) I had to reinstall all my snaps!
[17:46] <Chipaca> sergiusens: LA LA LA LA IT WENT FANT LA LA LA
[17:46] <Chipaca> FINE*
[17:46] <Chipaca> fant wtf
[17:46]  * Chipaca looks at his nearly-empty beer
[17:46]  * Chipaca identifies the problem
[17:46] <Chipaca> brb, topping up
[18:28] <mvo> jdstrand: I updated 5621 again, thanks for the excellent feedback
[18:30] <jdstrand> mvo: cool, np
[22:00] <kyrofa> If I `snap revert`, and later want to return to the revision from which I reverted, how might I do that?