[00:10] <mup> PR snapd#4276 closed: tests: document and slightly refactor prepare/restore code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4276>
[05:55] <mborzecki> morning everyone
[06:29] <ikey> weird question, but why does "snap find solus" list clementine and nextcloudclient? :D
[06:30]  * ikey is truly baffled
[06:34] <zyga-solus> good morning
[06:36] <ikey> morning
[06:37] <zyga-solus> ikey: hey
[06:38]  * zyga-solus needs to take tomorrow off, too many days off, a bit tired
[06:38] <ikey> :/
[06:42] <mborzecki> zyga-solus: morning
[06:43] <zyga-solus> hey :-)
[06:44] <mborzecki> zyga-solus: found an old patch that i missed whel opening all the arch related PRs
[06:45] <zyga-solus> mborzecki: oh, nice, what does it do?
[06:45] <mborzecki> you remember that we had an assumption that daemon user is uid 1?
[06:45] <zyga-solus> yes
[06:45] <mup> PR snapd#4278 opened: cmd/snap-seccomp: fix uid/gid restrictions tests on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4278>
[06:45] <mborzecki> well the patch fixes the assumption :) or rather gets rid of if
[06:46] <zyga-solus> nice, looking
[06:47] <zyga-solus> mborzecki: short and simple, thanks!
[06:47] <mborzecki> yw
[06:47] <mborzecki> had nigthmares about the refresh timer parser? :)
[06:48] <mvo> zyga-solus, mborzecki good morning
[06:48] <zyga-solus> haha
[06:48] <mborzecki> mvo: hey
[06:48] <zyga-solus> no, but I did dream of not working tomorrow ;D
[06:48] <zyga-solus> and I think I'll just do it
[06:48] <mvo> zyga-solus: we had a strange wildcard error in some tests last night, do you know if this is fixed
[06:49] <zyga-solus> mvo: no, I read that sergio and gustavo were discussing it
[06:49] <zyga-solus> mvo: do you have a reference
[06:49] <zyga-solus> mvo: I'm not sure if that is the same thign
[06:49] <zyga-solus> *thing
[06:50] <mvo> zyga-solus: no worries, I have a look, was just wondering if I'm chasing windmills or dragons ;)
[06:50] <zyga-solus> mvo: it's always dragons here :D
[06:50] <zyga-solus> mvo: (sometimes dragons sit on top of windmills)
[06:50] <mvo> lol
[06:51]  * mvo hugs zyga-solus
[06:51] <kyrofa> zyga-solus, what happened with https://github.com/snapcore/snapd/pull/4258 ?
[06:51] <mup> PR #4258: cmd/snap-confine,tests: fix unmounting on systems without rshared / <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4258>
[06:52] <zyga-solus> kyrofa: I discussed it with jdstrand, we need to tweak it slightly in order not to make snap-confine too powerful,
[06:52] <zyga-solus> kyrofa: I'll get back to it
[06:52] <zyga-solus> kyrofa: I'm looking at why master breaks so often as this clamps our velocity a lot
[06:52] <kyrofa> Ah okay, very good. Still a path forward, though?
[06:53] <zyga-solus> yes, totally
[06:56] <kyrofa> Alright, night guys. Note that I'm off tomorrow
[06:57] <zyga-solus> kyrofa: lovely, enjoy!
[07:01] <mborzecki> some of the tests in my PR failed with 504 gateway timeout coming from the store, this is some bad luck
[07:02] <zyga-solus> mborzecki: store had some issues yesterady
[07:02] <zyga-solus> also, not sure if real or fluke due do damaged tests, I saw a lot of EOF errors on assertions
[07:07] <zyga-solus> so, if you are using qemu for testing I will have one simple and sweet improvement
[07:08] <zyga-solus> currently running 8 workers locally, seeing almost no network traffic
[07:08] <zyga-solus> still some polish to do but the patch is a few lines long and simple to use
[07:08] <zyga-solus> I realized that a single run burned about 2GB of data
[07:09] <zyga-solus> and my mobile quota is high but not infinite
[07:09] <zyga-solus> so this will not only be faster but also more economic ^_^
[07:09] <zyga-solus> and there's far less waiting for IO
[07:10] <zyga-solus> obligatory pic: https://twitter.com/zygoon/status/933591581206237184
[07:10] <zyga-solus> ^_^
[07:13] <mborzecki> nice
[07:15] <zyga-solus> mvo: I ran main, regression and completion suites yesterday in a loop
[07:15] <zyga-solus> mvo: none of those failed with one of those weird random errors
[07:15] <zyga-solus> mvo: I'll extend that to the full suite to see if I see any pattern
[07:16] <mvo> zyga-solus: interessting and good to know
[07:18] <paulliu> hi. I'm running Debian testing and I cannot run "snap run hello-world". http://paste.ubuntu.com/26025879/
[07:18] <paulliu> How do I debug?
[07:18] <zyga-solus> paulliu: hey, we are aware of the issue, sorry for the bad experience
[07:19] <paulliu> zyga-solus: got it. thanks. :)
[07:19] <zyga-solus> paulliu: we made some patches but it seems it's not enough, we are looking into the issue with the help of our kernel developers
[07:19] <zyga-solus> paulliu: it's likely the next release will have a fix or workaround
[07:19] <zyga-solus> paulliu: for now you can try booting with apparmor=0
[07:19] <zyga-solus> paulliu: that _might_ fix it
[07:19] <paulliu> zyga-solus: thanks for the info. I just thought it was me that makes something wrong on my system. Thanks a lot. :)
[07:21]  * zyga-solus sees some wasted traffic, adds snaps to cache
[07:29] <mup> PR snapcraft#1755 opened: WIP:  tests: collect the autopkgtest results and save them in git  <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1755>
[08:01] <mup> PR snapd#4278 closed: cmd/snap-seccomp: fix uid/gid restrictions tests on Arch <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4278>
[08:02] <mup> PR snapd#4277 closed: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4277>
[08:03] <zyga-ubuntu> man, what's going on with EOFs on assertions
[08:04] <Chipaca> zyga-ubuntu: where?
[08:06] <zyga-ubuntu> Chipaca: on random PRs, look at failures, it's a common pattern
[08:08] <mvo> Chipaca, zyga-ubuntu also randomly failing: http://paste.ubuntu.com/26026114/
[08:09] <zyga-solus> mvo: hmmm
[08:09] <Chipaca> mvo: gustavo was seeing that one yesterday
[08:09] <zyga-solus> mvo: do you have dpkg build logs on that debug shell?
[08:09] <mvo> zyga-solus: maybe - it happend just now
[08:09]  * kalikiana coffee
[08:10] <mvo> zyga-solus: funny (sort of) - looks like no log at all
[08:12] <Chipaca> mvo: well the error is because there is nothing matching snapd_*.snap
[08:13] <zyga-solus> mvo: hmm
[08:13] <Chipaca> so of all funny things, this one at least makes sense
[08:13] <zyga-solus> yes
[08:14] <mborzecki> 4252 fails the same way
[08:14] <mvo> Chipaca: right, there is nothing there, the interessting question is why and why did it not fail earlier
[08:14] <mvo> Chipaca: I don't see anything in /home/gopath/ except the subdirs
[08:14] <Chipaca> mvo: incompatible bit-registration operators
[08:15] <mborzecki> + dnf -q -y install '/home/gopath/snap-confine*.rpm' '/home/gopath/snapd*.rpm'
[08:15] <Chipaca> mvo: (bofh excuse generator time!)
[08:15] <Chipaca> zyga-solus: did your changes to prepare etc land?
[08:15] <zyga-solus> Chipaca: would it be hard for snap download to be a no-op if there's a file in place that's just right?
[08:16] <zyga-solus> Chipaca: yes, but i have many more to make before we get the benefits
[08:16] <mvo> Chipaca: lol
[08:16] <Chipaca> zyga-solus: my question was because i wonder if that's why we no longer have .debs
[08:16] <zyga-solus> Chipaca: well
[08:16] <mvo> zyga-solus: it would be trivial, we did this a long time ago in apt
[08:16] <zyga-solus> Chipaca: I doubt it's that
[08:16] <mborzecki> the build fails https://paste.ubuntu.com/26026137/
[08:17] <mborzecki> man the logs are not the easiest to browse
[08:17] <zyga-solus> man that's one looooong line
[08:17] <zyga-solus> exit code 2, that's helpful
[08:17] <Chipaca> zyga-solus: "download be a no-op" <- didn't we already do that
[08:17] <zyga-solus> Chipaca: nope
[08:17] <zyga-solus> Chipaca: we pull and pull and pull and overwrite
[08:17] <zyga-solus> mborzecki: what's the error there?
[08:18] <mborzecki> ha no clue, dh failed, go install returned -2
[08:21] <mvo> zyga-solus: any idea about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734038 ? it looks strange and does not error for me
[08:21] <mup> Bug #1734038: Potential regression found with apparmor test on Xenial/Zesty <apport-bug> <package-from-proposed> <regression-proposed> <s390x> <xenial> <zesty> <linux (Ubuntu):Incomplete> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1734038>
[08:22] <zyga-solus> mvo: yes, you need to be on bionic
[08:22] <zyga-solus> mvo: #include is now mandatory, apparmor broke syntax
[08:22] <mvo> zyga-solus: wuut? you need to be on bionic for #include?
[08:22] <mvo> zyga-solus: you are saying 2.29.4 in -proposed is broken everywhere?
[08:23] <pedronis> fwiw even on xenial   man apparmor.d  doesn't mention include without #
[08:23] <zyga-solus> mvo: bionic has new apparmor that stopped supporting bare include and now requires #include
[08:23] <zyga-solus> pedronis: it was documented on apparmor documentation website
[08:23] <zyga-solus> jdstrand was surprised too :)
[08:23] <mvo> zyga-solus: the bugreport is about xenial/zesty
[08:23] <zyga-solus> mvo: maybe we got a backport/update?
[08:23] <zyga-solus> mvo: it was in bionic last week
[08:24] <mvo> zyga-solus: ok, so its a simple matter of s/include/#include/ ?
[08:24] <zyga-solus> yes
[08:24] <mvo> zyga-solus: and we may need a .5 :(
[08:24] <zyga-solus> but I suspect upstream will be fixed later on
[08:24] <zyga-solus> mvo: well, I honestly feel this is not our bug
[08:25] <zyga-solus> mvo: we can work around but this is broken apparmor parser
[08:25]  * mvo sits in a corner and sobs
[08:25] <mvo> zyga-solus: ok
[08:25] <zyga-solus> mvo: also, it's a conffile
[08:26] <zyga-solus> mvo: people can forever stay on the "broken" version
[08:26] <pedronis> me is a bit sceptical that they will "fix" it
[08:26] <mvo> zyga-solus, Chipaca so I think mborzecki found the issue, if the tests/build fails for whatever reason the script does not fail and we keep going until the error with the missing debs happens. slightly strange what regressed here
[08:27] <zyga-solus> mvo: so we carry on even if build fails, sweet
[08:27] <zyga-solus> mvo: do you think that's something I broke?
[08:27] <mborzecki> set -e ?
[08:27] <mvo> zyga-solus: git log indiciates that you touched it last ;) so there is a chance for this. but no worries
[08:27] <zyga-solus> mborzecki: I have a suspicion
[08:28] <zyga-solus> spread sets -e
[08:28] <mvo> mborzecki: yeah, recent refacors probably
[08:28] <zyga-solus> and this is not carried into scripts that are not sourced
[08:28] <zyga-solus> (I hate this sourcing that is going on, everything is sourced and has side effects apart from functions
[08:28] <zyga-solus> anyway, let me fix this
[08:28] <pedronis> ?
[08:28] <pedronis> do we source things with side effects?
[08:29] <zyga-solus> sure we do
[08:29] <zyga-solus> most scripts have a bunch of functions and then happy execution down below
[08:29] <mborzecki> hm looking at fedora log I see there's snapd package, but there there should be snap-confine as well right?
[08:29] <zyga-solus> and we source them to get MATCH and stuff
[08:29] <zyga-solus> mborzecki: no, we don't want to have separate snap-confine
[08:29] <zyga-solus> mborzecki: it's just historic
[08:29] <pedronis> mvo:  http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference#Include_statements  otoh it's a wiki
[08:29] <zyga-solus> pedronis: thank you for finding that!
[08:30] <zyga-solus> pedronis: it's an upstream bug
[08:30] <pedronis> it's a bizarre "bug"
[08:30] <mborzecki> hm fedora rpm spec is still building 2 packages from what i can see
[08:30] <Chipaca> sigh
[08:30] <pedronis> I mean it should have been conscious
[08:30] <zyga-solus> mborzecki: it's something that needs to be fixed, but it takes time
[08:30] <Chipaca> mvo: zyga-solus: so the bug is right there
[08:30] <pedronis> it's kind of hard to randomly change your syntax
[08:30] <pedronis> unless your parser is horrible
[08:30] <Chipaca> mvo: zyga-solus: prepare-restore.sh does not set -e
[08:31] <zyga-solus> yes, that's what I just fixed
[08:31] <Chipaca> mvo: zyga-solus: and it's executed, not sourced
[08:31] <zyga-solus> while I loath -e, it's the lesser evil
[08:31] <zyga-solus> yep, I reached the same conclusion
[08:31] <zyga-solus> PR coming up
[08:31] <Chipaca> zyga-solus: -e -u and pipefail are the only sane way to have these set up imo
[08:32] <mborzecki> zyga-solus: the error on fedora is: https://paste.ubuntu.com/26026198/ looks like snapd was built, but snap-confine was not, maybe that's a hint
[08:32] <zyga-solus> Chipaca: !shell is saner :)
[08:33] <zyga-solus> Chipaca: remind me why -o pipefail is useful?
[08:33] <zyga-solus> Chipaca: (I'm writing a comment)
[08:34] <Chipaca> zyga-solus: the exit status of “foo | bar” is the exit status of bar, without it
[08:36] <mborzecki> btw. do you guys see a number of can interfaces popping up after running seccomp test suite?
[08:36] <zyga-solus> mborzecki: nope?
[08:36] <zyga-solus> mvo: btw, sergio found a very worrying thing
[08:36] <mborzecki> they are nr0-nr3 and rose0-rose9
[08:36] <zyga-solus> mvo: on reboot the interfaces are lost
[08:37] <zyga-solus> mvo: reliably
[08:37] <zyga-solus> mvo: his PR has all the details, I didn't dig into it
[08:37] <zyga-solus> Chipaca: 4279
[08:37] <zyga-solus> and sorry about that folks
[08:38] <mup> PR snapd#4279 opened: tests: set -e, -o pipefail in prepare-restore.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/4279>
[09:02] <mvo> zyga-solus: looking
[09:03] <mvo> zyga-solus: so we have more scripts that need set -eu etc?
[09:04] <zyga-solus> mvo: I think just this one as it's a new script
[09:05] <mvo> zyga-solus: ok
[09:05] <zyga-solus> mvo: I'll add -u shortly, just looking at some problem
[09:07] <mvo> ta
[09:11] <zyga-solus> Chipaca: can you please look at 4280
[09:11] <mup> PR snapd#4280 opened: tests: remove obsolete workaround <Created by zyga> <https://github.com/snapcore/snapd/pull/4280>
[09:11] <Chipaca> zyga-solus: why not ln instead of cp?
[09:12] <Chipaca> zyga-solus: even better, cp -l (so it falls back to a plain cp if it can't ln)
[09:12] <zyga-solus> Chipaca: interesting, I had some reasons but I'm re-examining now
[09:13] <zyga-solus> Chipaca: there's some extra stuff coming but I think symlinks could be fine, I just hate the syntax :)
[09:13] <Chipaca> zyga-solus: reflink doesn't work on the filesystems we're running tests on afaik, fwiw
[09:14] <Chipaca> zyga-solus: ln, not ln -s
[09:14] <zyga-solus> Chipaca: yes, only on xfs AFAIK
[09:14] <Chipaca> zyga-solus: that is, hard links
[09:14] <Chipaca> zyga-solus: (cp -l does hard links)
[09:14] <zyga-solus> does cp -l handle xdev?
[09:15] <Chipaca> zyga-solus: yes
[09:15] <Chipaca> zyga-solus: it falls back to a regular cp
[09:16] <zyga-solus> sounds good then, I'll adjust that
[09:16] <zyga-solus> Chipaca: do you know if the store proxy thing is working now?
[09:16] <Chipaca> zyga-solus: --link instead of -l if you want it to self-document a little more
[09:16] <zyga-solus> Chipaca: oh, for sure
[09:20] <mvo> zyga-solus: I pushed a fix for the debian-sid failure that cachio had into his branch (just fyi)
[09:20] <zyga-solus> mvo: what was the problem?
[09:21] <mvo> zyga-solus: https://github.com/snapcore/snapd/pull/4265/commits/9f534e22dabd022f72e9376bf6f84913461e85a1
[09:21] <mup> PR #4265: New debian-sid-64 and debian-9-64 images for testing <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4265>
[09:21] <mvo> zyga-solus: i.e. snap-confine needs a profile
[09:22] <zyga-solus> ohh
[09:22] <zyga-solus> thank you, great find
[09:23] <mvo> zyga-solus: yw
[09:23] <mup> PR snapd#4279 closed: tests: set -e, -o pipefail in prepare-restore.sh <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4279>
[09:23] <zyga-solus> thanks!
[09:33] <Chipaca> my question isn't why user-data-handling failed in #4277; it's how it doesn't fail before it
[09:33] <mup> PR #4277: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4277>
[09:33]  * Chipaca digs
[09:37] <mup> PR snapd#4281 opened: snapstate: support for pre-refresh hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/4281>
[09:38] <mvo> zyga-solus: http://paste.ubuntu.com/26026470/ is what you wnated for snap download, rightß
[09:39] <zyga-solus> yes!
[09:39] <zyga-solus> please :D
[09:39] <zyga-solus> it will help with caching
[09:39] <mvo> zyga-solus: once I wrote a test I will push a PR
[09:43] <mvo> zyga-solus: slightly sad, we apparently have no test for DownloadSnap, so a good time to write one :)
[09:43] <zyga-solus> :-)
[09:43] <zyga-solus> mvo: download is totally client-side, right?
[09:43] <mvo> zyga-solus: yes
[09:44] <zyga-solus> ok, now way to reuse the cache but that's not too terrible
[09:46] <Chipaca> zyga-solus: mvo: download should try to chat with snapd though
[09:46] <pstolowski> zyga-solus, tiny suggestion to 4280
[09:47] <Chipaca> zyga-solus: mvo: ideally it'd try (but gracefully handle failing) to ask snapd for things like what creds to use, and what cache to use if any? maybe more stuff
[09:47] <zyga-solus> Chipaca: yes, that would be perfect
[09:48] <zyga-solus> pstolowski: looking
[09:48] <Chipaca> zyga-solus: mvo: note it could even get a filehandle back from snapd
[09:48] <Chipaca> (we don't currently do that but it's possible)
[09:48] <zyga-solus> very good idea pstolowski
[09:48] <zyga-solus> Chipaca: yeah, I was thinking about that :)
[09:48] <zyga-solus> Chipaca: streaming doesn't seem too terrible though, no real difference here
[09:49] <Chipaca> OTOH as soon as we get into passing filehandles the idea of exposing snapd to the network transparently goes away
[09:49] <Chipaca> OTO²H we're already there with crednet
[09:49] <Chipaca> so, fun time
[09:49] <zyga-solus> pstolowski: updated
[09:50] <Chipaca> we have a test that only passes because of how we were looking at homes
[09:50] <Chipaca> :-)
[09:50] <Chipaca> it does: mkdir -p /home/*/snap/test-snapd-tools/$rev/
[09:50] <zyga-solus> * ?
[09:50] <Chipaca> which creates a directory in /home/ called "*"
[09:50] <zyga-solus> LOL
[09:50] <Chipaca> hi-fucking-larious
[09:50] <pedronis> Chipaca: well, that's tests
[09:50] <zyga-solus> Chipaca: did you see my measurement PR for spread, maybe you can use it sooner for something useful?
[09:50]  * Chipaca wonders how badly he messed up that spelling
[09:51] <magicaltrout> hello folks, is there any issues with the snap review queue?
[09:52] <Chipaca> magicaltrout: there shouldn't be one, why?
[09:52] <Chipaca> magicaltrout: AFAIK there isn't a queue; either review passes, or you need to open a topic in the forum explaining why you're special :-)
[09:53]  * Chipaca might be oversimplifying things
[09:53] <magicaltrout> hehe
[09:53] <magicaltrout> i pushed a snap 30 minutes ago
[09:53] <magicaltrout> it says failed
[09:53] <magicaltrout> but the cli is hanging
[09:53] <Chipaca> magicaltrout: which cli?
[09:53] <magicaltrout> snapcraft push
[09:53] <Chipaca> ah
[09:53] <magicaltrout> and on the dashboard is says 2 fails
[09:53] <magicaltrout> but there's no content in the + button
[09:53] <Chipaca> who was our EU-timeone snapcrafter?
[09:54] <pstolowski> zyga-solus, thanks, +1
[09:55] <magicaltrout> https://imagebin.ca/v/3iGoz2K7NShK
[09:55] <zyga-solus> thank you :)
[09:55] <magicaltrout> sad times
[09:55] <Chipaca> kalikiana: ^ magicaltrout might benefit from your expertise
[09:56] <magicaltrout> that worked yesterday
[09:56] <magicaltrout> do i kill it and restart the push?
[09:56] <Chipaca> magicaltrout: wait for kalikiana please, he'll know better than i do
[09:58] <pedronis> mvo: do you have password for  snappy-stagingstore in staging ? I suppose not
[09:58] <mvo> pedronis: no
[09:58] <mvo> pedronis: sorry
[09:58] <pedronis> mvo: that's used for the private snaps tests, we probably need to setup something shared and also transfer the snaps
[09:58]  * mvo nods
[09:59] <mup> PR snapd#4282 opened: tests: cache snaps to $TESTSLIB/cache <Created by zyga> <https://github.com/snapcore/snapd/pull/4282>
[09:59] <zyga-solus> mvo: ^
[10:05]  * zyga-solus looks for ethernet cable
[10:05] <mup> PR snapd#4277 opened: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <https://github.com/snapcore/snapd/pull/4277>
[10:06] <pstolowski> mvo, hey, there is question to you from zyga-solus in 4158 comments
[10:07] <mup> PR snapd#4283 opened: snap: use existing files in `snap download` if digest/size matches <Created by mvo5> <https://github.com/snapcore/snapd/pull/4283>
[10:07] <mvo> pstolowski: thanks, looking
[10:10] <zyga-solus> pstolowski: reviewed 4281
[10:11] <zyga-solus> pstolowski: and a kind request to squash this
[10:13] <zyga-solus> mvo: thank you, reviewed
[10:13] <zyga-solus> mvo: can you look at 4282, it's related
[10:16] <kalikiana> magicaltrout: reading the backlog...
[10:17] <mborzecki> some weird things about running arch on linode
[10:18] <mborzecki> the vm starts with linode kernel but when you pacman -Syu the kernel can be upgraded to the latest avaialble in the repos, i'd assume that they prepped the images somehow to avoid this
[10:18] <zyga-solus> mborzecki: probably typical $cloud ops, they use custom kernels
[10:19] <zyga-solus> mborzecki: same was true for ubuntu but then we changed to use grub in our image
[10:19] <magicaltrout> kalikiana: i've killed the review and stuff and i'm pushing a new one because the only change i made between working and broken was remove the home plug
[10:19] <zyga-solus> mborzecki: you probably need to work with niemeyer and cachio to get a better image in
[10:19] <magicaltrout> but as the dashboard hung I think the automated review process got sad at some point
[10:19] <mborzecki> zyga-solus: yeah, probably
[10:19] <kalikiana> magicaltrout: so did the dashboard get stuck or the local command?
[10:19] <mborzecki> i'm working with the default image anyway, got it to a point that it's about to start building the package
[10:20] <magicaltrout> kalikiana: both
[10:20] <kalikiana> oh
[10:20] <magicaltrout> and then i pressed the stop review button and the cli released
[10:20] <magicaltrout> and the dashboard just switched to allow a manual review
[10:21] <pstolowski> mvo, zyga-solus thanks
[10:24] <pedronis> mvo: zyga-solus: prereq are put in their own lane (not the default lane)
[10:24] <pedronis> that's already like that in master
[10:25] <zyga-solus> pedronis: I think we were worried that we don't end up with something installed while its prepreq is missing
[10:28] <pedronis> zyga-solus: that's not really related, it's more that if we install core as a prereq we don't remove it , if what fails is the install of snap itself
[10:29] <zyga-solus> ah, that should be good then
[10:31] <pedronis> yes, there's nothing to do afaik
[10:31] <mvo> pedronis: thanks for double checking
[10:44] <zyga-solus> hmm
[10:44] <zyga-solus> mvo: so what's up with quiet
[10:44] <zyga-solus> I just added quiet and ... man things break!
[10:44] <mvo> zyga-solus: a good question, in what way do things break?
[10:45] <zyga-solus> mvo: my blazingly fast cache is idle, cpu is idle, network is idle
[10:45] <zyga-solus> mvo: but it's running apt install cups
[10:45] <zyga-solus> woah, it's running now
[10:45] <zyga-solus> but it was just sitting there for a long itme
[10:45] <zyga-solus> hmmm
[10:45] <zyga-solus> (as in idle)
[10:45] <zyga-solus> I watch htop/dstat all the time
[10:46] <mvo> zyga-solus: this might be interessting https://travis-ci.org/snapcore/snapd/builds/306221204#L2268 (+ test-snapd-tools.echo Hello
[10:46] <mvo> cannot bind-mount the mount namespace file /proc/7579/ns/mnt -> test-snapd-tools.mnt: Permission denied
[10:46] <mvo> support process for mount namespace capture exited abnormally)
[10:47] <zyga-solus> mvo: debian?
[10:47] <zyga-solus> mvo: do you have denials?
[10:47] <mvo> zyga-solus: yeah, debian-sid
[10:47] <zyga-solus> mvo: I think we really want jjohansen to look and say
[10:47] <zyga-solus> mvo: it looks like a bug
[10:47] <mvo> zyga-solus: http://paste.ubuntu.com/26026737/
[10:47] <mvo> zyga-solus: oh, interessting, that is the rule we aded, no?
[10:47] <zyga-solus> mvo: there are rules exactly for that
[10:48] <zyga-solus> right?
[10:48] <zyga-solus> yes
[10:48] <mvo> zyga-solus: I guess I need to check if the rule is really on disk
[10:49] <zyga-solus> man, 4260 fails for like the 10th time
[10:49] <mvo> zyga-solus: also interessting, only failing in upgrade-basic, so maybe
[10:49] <mvo> zyga-solus: yeah, harmless "sanity check install" ;)
[10:49] <mvo> zyga-solus: of course the previous install won't work on debian-sid
[10:49] <zyga-solus> and more of those canot unrmarshal EOF erorrs
[10:50] <zyga-solus> mvo: are machine disks recycled?
[10:50] <zyga-solus> mvo: when we deploy, say, xenial, do we wipe the disk?
[10:50] <zyga-solus> mvo: it looks that that run keeps happening on machine that has some junk assertions
[10:50]  * ikey likes zyga advertising solus for him so he doesn't have to :p
[10:50] <zyga-solus> but this makes little sense
[10:50] <zyga-solus> ikey: hehe :)
[10:51] <zyga-solus> hmm, the LXD test could be more cache friendly
[10:51] <zyga-solus> I wonder if apt-cacher-ng can cache lxd images if we push the proxy config down
[10:52]  * ikey goes and writes a hashmap
[10:52] <ikey> again
[10:52] <zyga-solus> ikey: waat?
[10:52] <zyga-solus> ikey: in which language and why?
[10:52] <ikey> C
[10:52] <zyga-solus> ikey: how come there's no libikey
[10:52] <ikey> there is
[10:52] <zyga-solus> soo?
[10:52] <ikey> https://github.com/intel/libnica
[10:53] <ikey> im replacing it
[10:53] <zyga-solus> oh, nice
[10:53] <ikey> the original lost sight and got vendored into a buttload of projects
[10:53] <ikey> but there was no ABI promise and it makes lots of naive decisions
[10:53] <zyga-solus> ikey: makes sense
[10:53] <ikey> f.e: NcHashmapEntry *row = &(buckets[hash % (unsigned)n_buckets]);
[10:54] <ikey> vs say, &buckets[hash & n_bucket_mask]
[10:54] <ikey> where n_bucket_mask = n_buckets - 1 and a power of 2
[10:54] <zyga-solus> ikey: I'd love to talk about that topic one day
[10:54] <zyga-solus> ikey: I'm building a pet project with similar needs
[10:54] <zyga-solus> well
[10:54] <zyga-solus> ish
[10:54] <ikey> oh?
[10:55] <ikey> btw .s comparison of the two methods: https://hastebin.com/ekomafajoj.pl
[10:55] <ikey> i know which one i want :p
[10:55] <ikey> divq is hella spensive
[10:55] <zyga-solus> ikey: a small home grown C library for that is designed for correctness and error handling
[10:56] <zyga-solus> ikey: just I want mine to build on ... heaven forbid, windows
[10:56] <ikey> ooo ok
[10:56] <zyga-solus> (in addition to normal environment)
[10:56] <ikey> portability is good
[10:56] <ikey> my new design constraint is to not be glibc specific
[10:56] <zyga-solus> yeah, I'm impressed by the toolchains there
[10:56] <ikey> found myself fixing up some projects that explicitly #include <linux/limits.h>
[10:56] <zyga-solus> fun fact: windows implementation of virtual terminals and unix consoles of the olden days is probably the most comprehensive and accessible documentation of how it is specced to work
[10:57] <ikey> wow
[10:57] <zyga-solus> ikey: msdn has some fantastic things there on the console APIs and unix compatibility and VTs and such
[10:57] <zyga-solus> (very recent)
[10:57] <mcphail> I'm asking in genuine ignorance here - is glib deprecated for these things?
[10:57] <ikey> huh ok ill need to poke around it
[10:58] <ikey> mcphail, which?
[10:58] <ikey> glibc or glib2?
[10:58] <mcphail> glib2
[10:58] <ikey> if glibc, its unportable antiunix hell
[10:58] <ikey> and glib2 has an enormous arse
[10:58] <ikey> you can't trust it truly for long running processes
[10:58] <magicaltrout> yeah kalikiana the new push worked first time, the automated queue must have got sad on my previous attempt
[10:58] <ikey> due to its internal memory management and want to leak
[10:58] <mcphail> aah ok
[10:58] <ikey> for clearlinux i ported clr-debug-info, a simple FUSE fs daemon that runs all the time, from glib2 to nica
[10:59] <ikey> and switched from pthreads to C11 atomics
[10:59] <ikey> i cut the memory usage in half and removed any leaks
[10:59] <ikey> and it could be trusted to not grow over time
[10:59] <ikey> another example is when you execv{p,}e a process without forking
[10:59] <ikey> you're just asking to page fault the child into oblivion
[10:59] <zyga-solus> IMO glib has totally broken error handling
[10:59] <zyga-solus> well
[10:59] <ikey> abort()
[11:00] <ikey> g_assert(i dont know what im doing anymore)
[11:00] <zyga-solus> ish, but not what I want to aim for
[11:00] <zyga-solus> yeah
[11:00] <zyga-solus> it was NULL but that's fine, let's carry on
[11:00] <ikey> g_critical(but yet im still running)
[11:00] <mcphail> hmm. Interesting. I've only ever played with it a bit. I just dabble in coding
[11:00] <zyga-solus> I think it's a fair question
[11:00] <ikey> also the vtable design of glib2 leads to far higher memory usage
[11:00] <zyga-solus> part of my motivation os to re-invent the wheel in a different way (maybe dead end) and to learn in the process
[11:00] <ikey> it relies on embedded structs in the malloc'd struct
[11:01] <ikey> imagine now your vtable is simply a single pointer to a static vtable
[11:01] <ikey> you greatly reduce the memory usage for these "objects"
[11:01] <zyga-solus> mvo: one more step towards nicer prepare world needs one more review in 4284
[11:01] <ikey> which is pretty much how the kernel does it (ops tables)
[11:01] <ikey> also with op table redirection you can get rid of a whole slew of "if (!self)" checks
[11:01] <mup> PR snapd#4284 opened: tests: merge pepare-project.sh into prepare-restore.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/4284>
[11:02] <ikey> (though arguably you should use the builtin likely/unlikely functions there)
[11:02] <zyga-solus> and we are hit with another case of mysterious failure
[11:02] <pedronis> pstolowski: zyga-solus questions on #4158 made me think that it probably needs a couple more code comments, added PR comments about this
[11:02] <mup> PR #4158: snapctl: don't error out on start/stop/restart from configure hook during install or refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/4158>
[11:02] <zyga-solus> pstolowski: aww, cannot create hard link in cp --link
[11:02] <zyga-solus> er, that's Chipaca perhaps
[11:02] <zyga-solus> I guess it's back to good old cp then
[11:04] <pstolowski> pedronis, thanks, i'm in the process of adressing that
[11:04] <mcphail> ikey: but, for hobby projects like the stuff I do, you wouldn't warn me off glib2 altogether? I'm a bit lazy to implement my own hash tables etc
[11:04] <zyga-solus> pedronis: thank you
[11:04] <ikey> for standard "do a thing and exit within some predicted timeslot" theres no real reason to avoid it
[11:04] <zyga-solus> mcphail: depends on what you want:
[11:04] <zyga-solus> mcphail: make hash tables or make stuff on top :)
[11:04] <zyga-solus> both are fun
[11:04] <ikey> if its "im a piece of plumbing" or "i run forever" then its worth considering the options
[11:05] <ikey> and yeah tbh, implementing ADT is a great exercise
[11:05] <zyga-solus> ikey: +1000 on plubming layer
[11:05] <ikey> learning how this stuff works internally just increases understanding
[11:05] <mcphail> cool. Cheers guys. Sorry for straying o/t
[11:05] <zyga-solus> also one more comment
[11:05] <ikey> my fault on that one, sorry :D
[11:05] <zyga-solus> there's plenty of research
[11:05] <ikey> yeah
[11:05] <ikey> incorporate the best and distil into awesome :D
[11:05] <zyga-solus> and plenty of "good old hash table that has $magic performance so let's not re-implement"
[11:05] <zyga-solus> where reality is that it's junk but nobody wants to touch it
[11:05] <ikey> chained buckets are typically easiest
[11:05] <zyga-solus> and it was optimized on Sun Sparc V or something
[11:06]  * ikey is gonna attempt a robin this time
[11:06] <Chipaca> zyga-solus: why can't create hard link?
[11:06] <zyga-solus> Chipaca: fedora has tmpfs on /tmp
[11:06] <zyga-solus> Chipaca: I dropped --link
[11:06] <zyga-solus> Chipaca: in retrospective, well, sucks
[11:07] <zyga-solus> Chipaca: can 4277 be split in any way?
[11:07] <zyga-solus> Chipaca: perhaps add the new functions in one PR
[11:07] <zyga-solus> Chipaca: and convert things in another
[11:08] <zyga-solus> Chipaca: to kill the old ones in last
[11:08] <kalikiana> magicaltrout: hmmm so it was a temporary hickup I guess. But something to keep an eye on me thinks, snapcraft should never freeze like that...
[11:08] <zyga-solus> Chipaca: it's just too daunting to look IMO
[11:17] <mup> PR snapd#4282 closed: tests: cache snaps to $TESTSLIB/cache <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4282>
[11:26] <zyga-solus> does anyone know of a commad like "time" that says "transferred so-and-so many bytes"
[11:37] <Chipaca> zyga-solus: why does tmpfs on /tmp break --link? (i tested exactly that and it works here)
[11:37] <Chipaca> zyga-solus: there are dd-alikes with progress bars
[11:38] <zyga-solus> Chipaca: because it copies from /tmp to /var and _does not_ handle xdev
[11:38] <Chipaca> 4277 can be split, probably. i'll give it a go.
[11:38] <zyga-solus> Chipaca: (well, hardlinks)
[11:38] <Chipaca> uh
[11:39] <Chipaca> zyga-solus: my /tmp is no longer tmpfs? what
[11:39] <zyga-solus> Chipaca: it is tmpfs on fedora
[11:39] <zyga-solus> Chipaca: note that it didn't fail everywhere :)
[11:39] <Chipaca> i thought it was tmpfs here
[11:39] <zyga-solus> nope
[11:40] <mborzecki> hmm go unit tests do not really need a package, but we build it anyway in prepare :/
[11:40] <zyga-solus> mborzecki: in the unit suite?
[11:41] <zyga-solus> whee
[11:41] <mborzecki> yes
[11:41] <Chipaca> zyga-solus: too many laptops; it's a tmpfs on my other one
[11:41] <zyga-solus> I'm using measure-each for the 1st time now
[11:41] <Chipaca> zyga-solus: ln || cp?
[11:41] <zyga-solus> Chipaca: nah, it's just temporary, next patch will restore --link
[11:41] <zyga-solus> Chipaca: :-)
[11:41] <Chipaca> ok
[11:42] <Chipaca> it's interesting that it doesn't have --link=auto
[11:42] <Chipaca> ¯\_(ツ)_/¯
[11:42] <mborzecki> zyga-solus: i'm running linode:arch-2017.07.01:tests/unit/go and it goes through prepare-project where the package is built unconditionally (?)
[11:42] <zyga-solus> Chipaca: TEH BLEADING EDGE ;-)
[11:42] <zyga-solus> mborzecki: yeah, that's weird / silly
[11:42] <zyga-solus> mborzecki: but, so is much of our preapre code :)
[11:42] <zyga-solus> mborzecki: I'll clean it up to be easier to understand what's going on
[11:42] <cachio> zyga-solus, the test interfaces-network-control-tuntap still failing in the new debian-sid https://travis-ci.org/snapcore/snapd/builds/306221204#L4707
[11:42] <zyga-solus> mborzecki: suite prepares are in -f
[11:43] <zyga-solus> -e is ready for review now :")
[11:43] <cachio> zyga-solus, not sure if it is the same error that we used to see
[11:43] <zyga-solus> looking now
[11:44] <zyga-solus> cachio: yes, I think so
[11:44] <zyga-solus> mvo: actually, do you remember that tuntap failure? was it errno 13 or errno 1? -- the error from test cachio just linked to is errno 1 and I don't recall seeing _that_
[11:44] <zyga-solus> mborzecki: can you please look at 4284
[11:45] <mborzecki> looking now
[11:47] <mborzecki> hmm will need to update arch integration, but that's not a big deal
[11:55] <niemeyer> Hello world
[11:55] <zyga-solus> o/
[11:55] <niemeyer> Thanks!
[11:55] <niemeyer> Thank you all!
[11:55] <niemeyer> You are all great to work and interact with.
[11:57] <zyga-solus> woot, you are in a good mood today :)
[11:58] <niemeyer> I've heard today we're supposed to give thanks according to some conventions. Sounds like a good idea.
[11:59] <kalikiana> And no turkeys have to die this way :-P I like it
[12:00] <mup> PR snapd#4277 closed: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4277>
[12:07] <ikey> **ohhh*
[12:07] <ikey> its thanksgiving
[12:07]  * ikey finally gets it
[12:07] <zyga-solus> ah
[12:07] <ikey> that took me longer than i care to admit
[12:07]  * zyga-solus thanks ikey for making something fresh from distro POV
[12:07] <ikey> oh, ty :D
[12:07] <mborzecki> zyga-solus: i'll open an early pr with spread support for arch, so that we can better track the conflicts between this and your refactor
[12:08]  * ikey thanks you lot for caring about users and doing something about it :]
[12:08] <zyga-solus> ok
[12:08] <zyga-solus> mborzecki: thanks, I'll try to help with conflicts
[12:10] <magicaltrout> can you install a local charm to test in jail mode so I can see if the confinement makes it bomb
[12:10] <mup> PR snapd#4285 opened: tests, spread: add Arch Linux to CI systems <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4285>
[12:10] <magicaltrout> without bothering to push files to the store?
[12:10] <zyga-solus> magicaltrout: probably --dangerous --jail
[12:10] <magicaltrout> ooh bloody dangerous
[12:10] <zyga-solus> magicaltrout: but I don't remember trying that
[12:10] <magicaltrout> i always forget that one
[12:13] <zyga-solus> mborzecki: general comment, I think we want separate snapd package for eventual inclusion into arch (again)
[12:13] <zyga-solus> mborzecki: or perhaps aupdate
[12:13] <zyga-solus> mborzecki: and that would resolve some of the complexity and the TODO in build_pkg
[12:14] <zyga-solus> mborzecki: reviewed
[12:14] <mborzecki> zyga-solus: thanks
[12:14] <zyga-solus> mborzecki: and please rebase/merge
[12:15] <zyga-solus> mborzecki: (sorr for the conflict there)
[12:15] <mup> PR snapd#4284 closed: tests: merge pepare-project.sh into prepare-restore.sh <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4284>
[12:15] <mborzecki> np
[12:15] <zyga-solus> pstolowski: approved 4158 though I think mvo wanted to move part out to a different PR
[12:16] <pstolowski> zyga-solus, yes, I know and responded (will move to separate PR)
[12:16]  * pstolowski lunch
[12:18] <zyga-solus> pstolowski: thanks, perfect
[12:20] <zyga-solus> mvo: the change to apparmor backend you made in 4265 is important enough to be pulled out and proposed/merged faster, would you mind if I do that?
[12:21] <zyga-solus> I used ~20GB of bandwidth on tests today
[12:21] <zyga-solus> (cached)
[12:21] <zyga-solus> I actually get to use CPUs now, not just wait for IO
[12:26] <mvo> zyga-solus: I was thinking the same, have a pr open but did not press the ok button :)
[12:27] <zyga-solus> mvo: thanks! please do
[12:27] <mup> PR snapd#4286 opened: apparmor: generate the snap-confine re-exec profile for AppArmor{Partial,Full} <Created by mvo5> <https://github.com/snapcore/snapd/pull/4286>
[12:51] <mup> PR snapd#4283 closed: snap: use existing files in `snap download` if digest/size matches <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4283>
[12:54] <mborzecki> is there a way to poke spread so that it'll kill remote command and clean up?
[12:57] <zyga-solus> mborzecki: ctrl-c
[12:57] <zyga-solus> mborzecki: other than that kill it and then discard the machines with -discard
[12:59] <mborzecki> yay, -discard does magic
[12:59] <mborzecki> thanks
[12:59] <zyga-solus> oh
[12:59] <zyga-solus> standup time
[13:17] <zyga-ubuntu> jamesh: thanks for the spread test~!
[13:18] <jamesh> zyga-ubuntu: it's a bit of a pain writing those tests: a successful run of a single test seems to take about 10 minutes, even with it reusing the VM
[13:19] <zyga-ubuntu> jamesh: I've pushed a few useful caching patches, I recommend using SPREAD_HTTP_PROXY=... (your local apt-cacher-ng) and with one more PR you should be able to cache most of the snaps so that tests are not bandwidth heavy
[13:19]  * jamesh is still waiting for the NBN to roll out in his suburb
[13:20] <zyga-ubuntu> sorry guys my desktop froze again :/
[13:20] <zyga-ubuntu> rebooted hard way and will be back soon
[13:23] <kalikiana> zyga-ubuntu: graphics drivers?
[13:23] <mup> PR snapd#4280 closed: tests: remove obsolete workaround <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4280>
[13:23] <zyga-ubuntu> kalikiana: maybe
[13:36] <mup> Issue snapcraft#1661 closed: Walk the prime directory for elf files (in lifecycle) <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1661>
[13:43] <mup> PR snapd#4286 closed: apparmor: generate the snap-confine re-exec profile for AppArmor{Partial,Full} <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4286>
[13:48] <zyga-ubuntu> jdstrand: hey, thank you for your feedback so far; I'm back to working on this so expect some more PRs
[13:48] <zyga-ubuntu> jdstrand: but I write for another issue actually, do you think you can look at 4100, it's close to landing but has unanswered questions
[13:56] <mborzecki> "Using GOPATH as if it were a single entry and not a list:"  <--- does this check in run-checks --static fail for anyone?
[13:56] <pedronis> mvo: this is the bug: https://bugs.launchpad.net/snapd/+bug/1733910
[13:56] <mup> Bug #1733910: snapd should track what user installed what, and use the appropriate macaroon in auto-refresh <snapd:Confirmed> <https://launchpad.net/bugs/1733910>
[13:58] <mborzecki> you actually have to have shellcheck installed to even hit that branch in run-checks
[13:59] <Chipaca> we still don't have shellcheck on the spread images? :-(
[13:59] <pedronis> we don't
[13:59] <Chipaca> niemeyer: i thought you were going to install it?
[14:00] <niemeyer> Chipaca: Hm?
[14:01] <mborzecki> hmm i've installed it on arch and hit this
[14:03] <mup> PR snapd#4287 opened: tests/lib: fix shellcheck errors <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4287>
[14:03] <mborzecki> trivial review ^^
[14:05] <zyga-ubuntu> done
[14:06] <mborzecki> zyga-ubuntu: thanks
[14:08] <zyga-ubuntu> I wonder why 4260 fails consistently
[14:08] <zyga-ubuntu> it seems like this is not a fluke
[14:08] <zyga-ubuntu> but actual consequence of the changes
[14:10] <cybrNaut> i think i found a snap pack that will not install on Debian -- which, if I understand corretly, defeats the purpose of snapcraft
[14:10] <sergiusens> popey elopio from the conversation yesterday, I am already on codein and accepted everything. I just had the impression there was grouping for shared tasks or is it to each their own?
[14:10] <cybrNaut> aren't "snap" packages supposed to be something that "just works"?
[14:11] <sergiusens> cybrNaut which package? it might be that it doesn't work anywhere
[14:11] <cybrNaut> i go to https://anbox.io/, and find a snap pack that has an embedded dependancy on PPAs
[14:11] <cybrNaut> PPAs are Ubuntu-specific
[14:12] <cybrNaut> i also found this thread, which seems to confirm that it won't work on debian https://discourse.anbox.io/t/anbox-modules-dkms-port-for-debian/33/6
[14:12] <cybrNaut> even though "snapd" is offically available on debian
[14:12] <ogra_> cybrNaut, anbox-installer is definitely 100% ubuntu specific (using dkms to build modules etc)
[14:12] <ogra_> cybrNaut, rge anbox snap itself is generic though ...
[14:13] <ogra_> *the anbox
[14:13] <cybrNaut> ogra_: your phrasing kind of made it clear.. i'm not installing anbox... i'm installing an installer
[14:13] <ogra_> right
[14:13] <cybrNaut> so i suppose there would be no problem using the snap to install an installer.. but then the installer is useless
[14:13] <ogra_> and the installed uses PPAs etc ... and in the end installs the anbox snap
[14:13] <mborzecki> zyga-ubuntu: hm fails on snap ack <..whatever>
[14:13] <sergiusens> you can talk to the upstream for anbox, but they went classic, which means the snap part of it is relegated to just a payload and up to the upstream to support it well everywhere
[14:13] <ogra_> once it did set up the modules as needed etc
[14:14] <ogra_> sergiusens, anbox isnt classic, only the installer IIRC
[14:14] <sergiusens> right, or the case of an "installter"
[14:14] <sergiusens> which essentially makes it classic
[14:15] <ogra_> cybrNaut, there should be instructions somewhere to do all the setup in debian i think
[14:15] <ogra_> sadly morphis is not around atm
[14:15] <ogra_> he is the one who could point you to the instructions (if theer are any)
[14:15] <mborzecki> zyga-ubuntu: aiui 'Nov 23 10:16:29 li563-82 snapd[28522]: 2017/11/23 10:16:29.793688 daemon.go:233: DEBUG: pid=28517;uid=0;@ POST /v2/assertions 8.452359ms 200' the post requests end with 200 OK unless marshalling at snapd or unmarshalling at snap is broken
[14:16] <cybrNaut> ogra_: i suspect it'll involve cloning the github project and building that
[14:16] <ogra_> cybrNaut, not sure ... you will need the dkms modules, so i guess using the deb source package from the PPA and such are involved
[14:18] <cybrNaut> ogra_: i see a manual install process here https://github.com/anbox/anbox which looks reasonable
[14:19] <cybrNaut> thanks for the help.  i'll try the manual process since i'd rather not mess with PPAs
[14:20] <zyga-ubuntu> pstolowski: commented on 4108
[14:20] <zyga-ubuntu> 4281 is green and needs a 2nd review
[14:21] <zyga-ubuntu> niemeyer: perhaps ^
[14:21] <pstolowski> zyga-ubuntu, thanks!
[14:22] <ogra_> morphis, meet cybrNaut ... he is trying to get anbox to run on debian ... do wer have any HOWTO (regarding the dkms modules on debian etc) ?
[14:23] <pedronis> mborzecki: something is definitely off with that branch, but unclear what
[14:30] <Chipaca> bloodearnest: regarding https://forum.snapcraft.io/t/should-snapctl-set-in-apps-trigger-the-configure-hook/2032 i think that's a question for gustavo or pstolowski
[14:30] <Chipaca> bloodearnest: i haven't much to say wrt snapctl
[14:30] <mup> PR snapd#4288 opened: Adding "set -e" to test lib scripts <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4288>
[14:32] <mup> PR snapd#4288 closed: Adding "set -e" to test lib scripts <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4288>
[14:33] <pedronis> mborzecki: it would seem something there broke client parsing of server responses
[14:34] <pstolowski> Chipaca, yes, I've been invited to this topic today already, just didn't get to respond yet
[14:45] <niemeyer> zyga-ubuntu, pstolowski: Looking
[14:46] <niemeyer> Chipaca, pstolowski: Responded there
[14:47] <cybrNaut> looks like the manual process would fail, as aptitude on debian says => Couldn't find any package whose name or description matched "libdbus-cpp-dev"
[14:47] <pstolowski> thanks niemeyer
[14:49] <Saviq> popey: this something you guys aware of? https://imgur.com/a/QiDAY
[14:50] <popey> Saviq: depends, where'd you get that?
[14:57] <cachio> niemeyer, do you know which are the base packages that you installed in the ubuntu images on linode?
[14:57] <cachio> those needed to make spread run the snapd suite
[15:04] <niemeyer> cachio: Figuring out which packages are necessary for the suite and isolating them in a reusable way was literally the work you did
[15:05] <niemeyer> cachio: The images weren't changed much other than making sure they would boot
[15:05] <cachio> niemeyer, ok
[15:05] <niemeyer> cachio: and *removing* stuff to make them lighter
[15:06] <zyga-ubuntu> the measurement stuff I did can also detect that and keep it up to date
[15:08] <cachio> niemeyer, do you  have the list of images available on linode?
[15:11] <niemeyer> cachio: Our images or their images?
[15:11] <cachio> niemeyer, their
[15:11] <niemeyer> pstolowski: Reviewed
[15:12] <mup> PR snapd#4287 closed: tests/lib: fix shellcheck errors <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4287>
[15:12] <niemeyer> cachio: You can use the API for a complete list.. this is the interesting stuff: https://www.linode.com/distributions
[15:13] <cachio> niemeyer,  tx
[15:13] <niemeyer> cachio: np
[15:14] <zyga-ubuntu> mborzecki: 4285 fails now
[15:15] <mborzecki> zyga-ubuntu: i know, it's the -Syu thing
[15:16] <mborzecki> zyga-ubuntu: more details here if you're interested: https://forum.snapcraft.io/t/integrate-arch-linux-into-ci-pipeline/2904/3
[15:16] <zyga-ubuntu> thanks, looking
[15:17] <mborzecki> i think i'll just make all the installation commands -Syu for now
[15:18] <mborzecki> then we can reiterate and maybe use some custom images that are rebuilt daily or sth
[15:40]  * zyga-solus managed to get to 5/196 without failures now, nice :)
[15:45] <zyga-solus> 8/196, another run
[15:48] <pstolowski> niemeyer, thanks, updated
[15:51] <mborzecki> zyga-solus: pushed 2 more patches, let's see how far it gets this time
[15:51] <pstolowski> niemeyer, btw, can you cast your eye on #4259 again too?
[15:51] <mup> PR #4259: snapd: fix handling of undo in the taskrunner <Created by stolowski> <https://github.com/snapcore/snapd/pull/4259>
[15:52] <pedronis> pstolowski: we need that code for normalizing int and float afaiu
[15:53] <pedronis> or we need ot change the rules
[15:53] <niemeyer> Yeah, the original suggestion was to move it into SetAttr time
[15:53] <niemeyer> pedronis: Would that not work?
[15:53] <pstolowski> pedronis, because interfaces themselves can set values
[15:53] <elopio> damn, I lost a " in travis. Sooo close.
[15:53] <pedronis> pstolowski: and because JSON pcakage has slightly different rules
[15:53] <pedronis> itself
[15:53] <pstolowski> pedronis, okay, i'll make a separate normalize() helper for this
[15:54] <mborzecki> niemeyer, and if you still feel fresh enough for reviews, would you mind taking a look at #4269?
[15:54] <mup> PR #4269: timeutil: new refresh timer parser <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4269>
[15:54] <niemeyer> Sure thing
[15:54] <mborzecki> thanks
[15:54] <pedronis> niemeyer: well right now pstolowski just removed it (if I read correctly), I don't care too much about the details
[15:55] <pedronis> but we need it and it needs to be recursive afaict
[15:55] <Faults> I have a quick question. Why most Snaps looks ugly... like Windows NT 4.0. I suppose Snaps not support theming from OS?
[15:55] <niemeyer> pedronis: My original point is that we don't want that on copying
[15:55] <niemeyer> pedronis: Does that make sense?
[15:56] <pedronis> niemeyer: yes, but the code will be similar (a kind of copy)
[15:56] <pedronis> I suppose we need normalize and copyAttributes
[15:56] <niemeyer> Faults: There's on going work to make snaps automatically use a theme that matches the system
[15:56] <niemeyer> Faults: Some details here https://forum.snapcraft.io/t/use-the-system-gtk-theme/496/27?u=jamesh
[15:57] <niemeyer> Faults: They look ugly in some cases because that's not finished yet
[15:57] <Faults> Oh lovely! Thanks from quick reply niemeyer :)
[15:57] <niemeyer> My pleasure
[15:57] <Faults> Idea of Snap (and flatpak) is pure gold!
[15:58] <niemeyer> pedronis, pstolowski: Right, we do want the types to be strict. My point is that this was being done incorrectly.. we don't want to be strict when reading values. We want to be strict when changing them.
[15:59] <pstolowski> niemeyer, ok, so i wasn't doing that on reading anymore. the copyRecursive method was left intact, but it was instead used when NewConnectedSlot/Plug was constructed - just once
[15:59] <pstolowski> niemeyer, and yes, it was copy+normalize in one method
[16:00] <niemeyer> pstolowski: Still bogus.. the static values you get from the snap are guaranteed to be correct because the reading logic fixed them
[16:00] <niemeyer> pstolowski: It's the modifications thereafter that need to be accounted for
[16:00] <pstolowski> niemeyer, ok, i get this, i'm adding a separate normalize method just for setting dynamic attributes. copy will be made for static ones
[16:00] <niemeyer> pstolowski: Brilliant, thanks!
[16:01] <pstolowski> and copy will assume correct types are used already, no normalization
[16:19]  * zyga-solus got up to 9/196
[16:19] <zyga-solus> (and had dinner)
[16:21]  * kalikiana configured mypy in syntastic, not super fast but very comfortable to work with
[16:25] <mup> PR snapd#4289 opened: snapstate: move autorefresh code into autoRefresh helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4289>
[16:27] <zyga-ubuntu> mvo: can that not be based on 4161?
[16:27] <zyga-ubuntu> mvo: it's a bit hard to see what's new
[16:29] <pedronis> I would have expected the changes in the reverse order, first refactor, then new feature
[16:29] <pedronis> with this  we need to land #4161
[16:29] <mup> PR #4161: snapstate: add support for refresh.schedule=managed <Created by mvo5> <https://github.com/snapcore/snapd/pull/4161>
[16:29] <pedronis> first
[16:30] <zyga-solus> yes, I agree
[16:30] <cachio> niemeyer, spread 46 ready again
[16:31] <niemeyer> cachio: There we go
[16:31] <cachio> I removed a set of packages
[16:31] <mvo> pedronis, zyga-ubuntu ups, sorry, happy to revert the order again
[16:31] <mup> PR core#58 closed: use `snapctl internal configure-core` to configure core <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core/pull/58>
[16:33] <mup> PR snapd#4289 closed: snapstate: move autorefresh code into autoRefresh helper <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4289>
[16:36]  * kalikiana wrapping up for the day
[16:42] <pedronis> mvo: thanks, unless you think the refactoring will be very controversial, in which case the other order could also work
[16:43] <niemeyer> cachio: 1.3G \o/
[16:43] <mup> PR snapd#4290 opened: snapstate: move autorefresh code into autoRefresh helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4290>
[16:44] <mvo> pedronis: yw, I think your suggestion is the right onw, new PR up, let me know if I should split even further (one PR that just moves stuff, one that adds baby-step feature)
[16:44] <pedronis> mvo: I think it should be fine, it doesn't look super big
[16:45] <cachio> niemeyer, :)
[16:46] <cachio> niemeyer, let's see if that works properly now
[16:46] <niemeyer> cachio: Ok, should I bake it?
[16:46] <cachio> yes
[16:47] <cachio> niemeyer, ~
[16:47] <niemeyer> cachio: on it
[16:50] <zyga-ubuntu> mvo: +1 on 4290
[16:54] <mvo> zyga-ubuntu: thanks, just fixed one tiny issue (force push to keep history cleanish)
[16:54] <zyga-solus> oh, what was it?
[16:54] <mvo> zyga-solus: forgot to add the snapManager.LastRefresh() accessors
[16:55] <mvo> zyga-solus: unit tests failed, so obvious
[16:55] <mvo> zyga-solus: actually a merge artifact but anyway, tiny and obvious
[16:55] <zyga-solus> mvo: can you please have a quick look at 4227
[16:55] <zyga-solus> mvo: it's green and has one review
[16:57] <mvo> sure
[16:57] <mup> PR snapd#4227 closed: tests: add test for frame buffer interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4227>
[16:58] <zyga-solus> great, back on 25 :D
[17:00] <zyga-solus> cachio: do you have the patch that is missing in 426?
[17:00] <zyga-solus> 4265
[17:02] <cachio> zyga-solus, I am working on the tests that fail sporadically related to gpg
[17:02] <cachio> I'll try to push today
[17:02] <zyga-solus> cachio: is this for that particular PR?
[17:06] <cachio> zyga-solus, yes
[17:06] <cachio> it is failing on debian-9
[17:09] <cachio> zyga-solus, in the last execution failed https://travis-ci.org/snapcore/snapd/builds/306221204#L3888
[17:09] <om26er> How much time before snapcraft 2.35 moves from xenial-proposed to -updates ?
[17:09] <cachio> zyga-solus, debuging I saw that gpg was failing to create/delete keys
[17:10] <cachio> it was trying to create some dirs in /root/....
[17:10]  * om26er knows it was accepted to -proposed only an hour ago.
[17:11] <cachio> zyga-solus, I am running the full suite
[17:11] <cachio> zyga-solus, it can not be reproduced if you just run this test
[17:12] <zyga-solus> cachio: what is the error that you saw?
[17:12] <zyga-solus> cachio: typically gpg breaks on lack of entropy
[17:13] <cachio> zyga-solus, the entropy was ok
[17:13] <cachio> like 2500
[17:13] <zyga-solus> cachio: debian may use differnt source of randomness from other distros (perhaps)
[17:13] <zyga-solus> cachio: aha
[17:14] <cachio> zyga-solus, I can share the vm once it failes
[17:14] <cachio> fails
[17:14] <zyga-solus> cachio: I'd like to see the error message
[17:14] <zyga-solus> cachio: I'll probably break soon, my back is giving me signals it's enough for today
[17:15] <cachio> zyga-solus, np, I'll leave more info in the PR
[17:20] <niemeyer> cachio: fedora-26-64 is ready
[17:20] <cachio> niemeyer, great, testing it
[17:21] <Son_Goku> cachio, is fedora-27-64 and fedora-rawhide-64 synced up to the latest?
[17:21] <zyga-solus> pedronis: can you please look at http://paste.ubuntu.com/26029227
[17:21] <Son_Goku> aka "dnf --refresh distro-sync"?
[17:22] <zyga-solus> pedronis: is that a sane assertion (syntax wise)
[17:22] <cachio> Son_Goku, no yet
[17:22] <Son_Goku> ok
[17:22] <zyga-solus> pedronis: this is what we fail on that EOF bug
[17:22] <cachio> Son_Goku, I'll do that after 26
[17:22] <Son_Goku> cool
[17:23] <pedronis> zyga-solus: it looks like one, I don't the problem is assertion
[17:23] <pedronis> zyga-solus: my guess would be the change in response,  but I'm not sure why it would trigger problems
[17:24] <pedronis> zyga-solus: easiest would be to get the branch, try one of the failing tests, try to undo that change, see if it changes something, then figure out what's happening
[17:25] <zyga-solus> pedronis: right, I'm looking at the diff again but nothing stands out
[17:25] <zyga-solus> pedronis: the only new thing is Tracks
[17:25] <zyga-solus> pedronis: it didn't have any annotation before
[17:25] <pedronis> but that struct is not involved with ack at all
[17:25] <pedronis> as I said afaict the only logical candidate
[17:25] <zyga-solus> hmm
[17:25] <pedronis> is the change in response.go
[17:26] <pedronis> it would be good to verify that theory
[17:26] <zyga-solus> pedronis: sure, that's easy
[17:26] <zyga-solus> thank you
[17:30] <zyga-solus> pedronis: so, it's not that
[17:30] <zyga-solus> pedronis: rebuilt snap, snapd, reinstalled, restarted snapd
[17:31] <pedronis> zyga-solus: actually I'm quite sure it is
[17:32] <zyga-solus> pedronis: ok, let me re-check
[17:32] <pedronis> I mean I see the now the code
[17:32] <pedronis> why that would matter
[17:33] <pedronis> we do things like this in client:   err := jsonutil.DecodeWithNumber(bytes.NewReader(rsp.Result), v)
[17:33] <pedronis> json.Unmarshal(rsp.Result, &resultErr)
[17:33] <zyga-solus> ok
[17:33] <mup> PR snapd#4291 opened: osutil/sys: reimplement getuid and chown with the right int type <Created by chipaca> <https://github.com/snapcore/snapd/pull/4291>
[17:33] <zyga-solus> I definitely removed that change
[17:33] <pedronis> and this is the field in the client:          Result     json.RawMessage `json:"result"`
[17:33] <zyga-solus> and rebuilt
[17:33]  * zyga-solus wonders
[17:34] <pedronis> so if the field is not there (instead of null), I suspect those to break with EOF
[17:34] <Chipaca> zyga-solus: 4291 is the syscall bits alone
[17:34] <zyga-solus> and restarted
[17:34] <zyga-solus> Chipaca: woot, thank you!
[17:34] <zyga-solus> pedronis: could it be a combination, I'm sure I removed this aspect of the patch
[17:34] <zyga-solus> pedronis: and new snapd is runing
[17:34] <zyga-solus> *running
[17:35] <zyga-solus> ah
[17:35] <zyga-solus> sorry, obviously
[17:35] <zyga-solus> reexec
[17:35] <pedronis> heh
[17:36] <zyga-solus> thank you
[17:36] <zyga-solus> :)
[17:36] <pedronis> now we need to decide whether we want to fix client or we consider this an incompatible change
[17:37] <pedronis> maybe Chipaca or niemeyer have opinions on that
[17:37] <zyga-solus> yes, confirmed
[17:37] <zyga-solus> funny outcome
[17:38] <pedronis> with how client is written we cannot omit result
[17:38] <pedronis> atm
[17:38] <niemeyer> I'm out of context.. can someone summarize?
[17:39] <pedronis> niemeyer:    is this change:  https://github.com/snapcore/snapd/pull/4260/files#diff-e1016939c627280d9f6c53bdab0530bf
[17:39] <mup> PR #4260: Stop various JSON field from being sent with null values <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/4260>
[17:39] <zyga-solus> niemeyer: 4260 introduced a change that broke tests, it added "omitempty" to daemon response
[17:39] <zyga-solus> niemeyer: this broke client that assumes there's something there
[17:40] <pedronis> even if just "null"
[17:40] <niemeyer> zyga-solus: What's the field?
[17:40] <zyga-solus> https://github.com/snapcore/snapd/pull/4260#discussion-diff-152852846R82
[17:40] <zyga-solus> "result"
[17:40] <pedronis> in respJSON
[17:40] <pedronis> our response wrapper type
[17:41] <niemeyer> I can see the argument both ways..
[17:41] <niemeyer> It's pretty silly for us to be sending null when it's not present
[17:41] <niemeyer> It also seems somewhat silly to change that at this point
[17:41] <zyga-solus> shall I undo that aspect?
[17:41] <zyga-solus> I have it checked out
[17:41] <zyga-solus> (then the rest can presumably land)
[17:42] <niemeyer> zyga-solus: Yeah, I don't really see much of a benefit on the change, other than being more aesthetically pleasing
[17:43] <mup> PR snapcraft#1756 opened: tests: add the missing quote on autopkgtest run <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1756>
[17:43] <zyga-solus> I'll push this with a small test
[17:46] <cachio> niemeyer, could you please start the spread-46 again, I need to install a pckg
[17:47] <cachio> a dependency seems to be missing, I see this error "fw_printenv: command not found"
[17:47] <niemeyer> cachio: Done.. up in a few
[17:47] <cachio> niemeyer, tx
[17:49] <Chipaca> pedronis: what's the context?
[17:50] <Chipaca> (way too much backlog)
[17:50] <Chipaca> pedronis: ah! just saw you tell gustavo :-)
[17:50] <Chipaca> reading
[17:51] <zyga-solus> pushed, it should pass now
[17:54] <cachio> niemeyer, done
[17:54] <cachio> niemeyer, it was failing to prepare the suite
[17:57] <zyga-solus> Chipaca: much shorter and nice to review
[18:04] <zyga-solus> Chipaca: just thinking aloud
[18:04] <zyga-solus> Chipaca: let's introduce uid_t, gid_t
[18:04] <zyga-solus> instead of everyone and their $pet remembering to use uint32
[18:05] <Chipaca> zyga-solus: well... uid_t is the reason we have this mess in the first place
[18:05] <Chipaca> it's way too obscure what exact integer type a given _t is
[18:05] <Chipaca> so, not a fan here, today
[18:06] <zyga-solus> Chipaca: but that's in C where nothing checks
[18:06] <zyga-solus> Chipaca: in go we'd, at least, get checks
[18:06] <Chipaca> (granted all it would've taken is compiling a little C program on all the architectures they were interested in, but still)
[18:06] <Chipaca> (also they get it right in the stat_t struct :-)
[18:07] <Chipaca> zyga-solus: what would you call the type?
[18:08] <zyga-solus> Chipaca: UserID, GroupID perhaps
[18:08] <zyga-solus> mouthful but to the point
[18:08] <Chipaca> that's a type name?
[18:09] <Chipaca> zyga-solus: tempted to say call it ID, as in user.ID
[18:09] <zyga-solus> Chipaca: and Group.ID
[18:10] <Chipaca> zyga-solus: yep
[18:10] <zyga-solus> Chipaca: and have a cho.Own() calls? :D
[18:10] <Chipaca> zyga-solus: no
[18:10] <Chipaca> zyga-solus: clearly it'd be ch.Own()
[18:10] <pedronis> heh
[18:10] <Chipaca> zyga-solus: and ch.Sh()! it's perfect
[18:11] <Chipaca> i mean, seriously user.UserID is nasty
[18:12] <zyga-solus> Chipaca: unix.UserID ?
[18:12] <zyga-solus> Chipaca: ^_^
[18:12] <zyga-solus> \\o
[18:12] <zyga-solus> o//
[18:12] <zyga-solus> \o/
[18:12] <Chipaca> could be
[18:12] <Chipaca> although that does clash with the new syscall
[18:13] <Chipaca> but not bothered about that tbh
[18:13] <zyga-solus> send partial review
[18:14] <zyga-solus> so again, to ensure everyone knows, I'm off tomorrow
[18:14] <zyga-solus> gotta go and see what's outside the thing called door
[18:15] <pedronis> I never noticed that go uses marker methods sometimes
[18:15] <Chipaca> zyga-solus: chaos and anarchi
[18:15] <zyga-solus> pedronis: marker methods?
[18:15] <pedronis> os.Signal.Signal
[18:15] <pedronis> is what I noticed
[18:17] <zyga-solus> interesting
[18:21] <cachio> zyga-solus, https://paste.ubuntu.com/26029507/
[18:21] <Chipaca> eep
[18:22] <Chipaca> just noticed "Tracks" in the json output
[18:22] <Chipaca> when/how did that happen
[18:22] <cachio> zyga-solus, if you need access just ask
[18:24] <zyga-solus> Chipaca: that's a new thing
[18:24] <zyga-solus> Chipaca: it's in that PR
[18:25] <zyga-solus> cachio: interesting
[18:26] <zyga-solus> cachio: perhaps something we can find in the source code of gpg
[18:26] <zyga-solus> but a long shot
[18:26] <zyga-solus> not sure what's wrong
[18:31] <mup> PR snapcraft#1757 opened: Saving snap-build assertion as '.build' <Created by cprov> <https://github.com/snapcore/snapcraft/pull/1757>
[18:32] <pedronis> zyga-solus: cachio: it might be gpg2 vs gpg1  (in principle we support both but afaik we test mostly gpg1)
[18:37] <cachio> zyga-solus, not sure
[18:37] <zyga-solus> mvo: hey
[18:38] <cachio> pedronis, zyga-solus using gpg I can create keys
[18:38] <zyga-solus> mvo: if around 4290 has some comments from pedronis but is good to merge otherwise
[18:38] <zyga-solus> cachio: which version is in sid?
[18:38] <mvo> zyga-solus: checking
[18:38] <zyga-solus> thanks!
[18:39] <cachio> zyga-solus, 2.1.18
[18:39] <cachio> sorry
[18:39] <cachio> this is not sid
[18:39] <cachio> this si debian-9
[18:39] <cachio> it is working properly on sid
[18:41] <pedronis> so unstable works, but current version doesn't ?
[18:41] <cachio> pedronis, yes
[18:41] <pedronis> (that sounds interesting, I would have expected neither or the reverse)
[18:42] <pedronis> I wonder what's different
[18:42] <pedronis> cachio: what gpg version to they have each ?
[18:42] <pedronis> s/to/do/
[18:43] <cachio> checking on sid
[18:43] <cachio> pedronis, it will take few minutes
[18:43] <mup> PR snapcraft#1758 opened: tests: move the ppa test trigger to lxd <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1758>
[18:46] <cachio> niemeyer, any news about the fedora-26?
[18:46] <niemeyer> cachio: It's back at 1.6G :)
[18:49] <cachio> niemeyer, I just install 450KB
[18:49] <cachio> heeeh
[18:49] <niemeyer> cachio: Clearly there's quite a bit more that is happening on the image every time we boot
[18:50] <niemeyer> cachio: No matter how terrible the algorithm of resize2fs is, it's probably deterministic
[18:50] <niemeyer> cachio: If we figure what that thing is, we can learn to disable it, or at least clean it back up
[18:51] <cachio> niemeyer, I could disable the timer
[18:51] <cachio> service
[18:52] <cachio> niemeyer, I'll take a look and research a bit more
[18:52] <niemeyer> cachio: Thanks
[18:52] <cachio> is it up?
[18:52] <niemeyer> Yeah
[18:52] <niemeyer> No, sorry
[18:52] <niemeyer> Booting it back up now
[18:53] <cachio> pedronis, gpg (GnuPG) 2.2.2
[18:53] <cachio> on sid
[18:53] <cachio> it is almost the same
[18:55] <mup> PR snapd#4292 opened: snapstate: store userID in snapstate <Created by mvo5> <https://github.com/snapcore/snapd/pull/4292>
[19:19] <mup> PR snapd#4170 closed: cmd/snap-update-ns: add planWritableMimic <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4170>
[19:32] <cachio> niemeyer, please try again with the 46
[19:33] <cachio> I disabled the service which triggers the automatic updates
[20:27] <niemeyer> cachio: Image is ready
[20:30] <cachio> size?
[20:30] <cachio> niemeyer, it was beter?
[20:30] <sergiusens> elopio 2.35 is in -proposed
[20:30] <cachio> better
[20:31] <elopio> sergiusens do you want me to test it instead of fixing my 2 bugs tomorrow?
[20:35] <sergiusens> elopio I am more interested in you fixing the error stuff first, then the SRU testing and last the bugs
[20:35] <elopio> Ack
[20:38] <mup> PR snapcraft#1754 closed: nodejs plugin: pass proxy configuration to yarn <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1754>
[20:38] <mup> PR snapcraft#1756 closed: tests: add the missing quote on autopkgtest run <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1756>
[20:38] <niemeyer> cachio: Yeah, back to 1.3
[20:39] <cachio> niemeyer, nice
[20:49] <mup> PR snapd#4158 closed: snapctl: don't error out on start/stop/restart from configure hook during install or refresh <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4158>
[21:43] <sergiusens> elopio mind reviewing snapcraft#1759 before you EOD?
[21:43] <mup> PR snapcraft#1759: many: ensure classic confined binaries use the correct interpreter <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1759>
[21:44] <mup> PR snapcraft#1759 opened: many: ensure classic confined binaries use the correct interpreter <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1759>
[21:51] <cachio> niemeyer, sadly I'll need the spred 46
[21:52] <cachio> I found the problem in the setup
[21:52] <cachio> is it missing a grub pkg
[22:03] <niemeyer> cachio: I can't fire it right now, but you can reuse the image and fire a new machine
[22:03] <cachio> ok
[22:05] <mup> PR snapd#4260 closed: Stop various JSON field from being sent with null values <Created by robert-ancell> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4260>
[22:05] <niemeyer> cachio: Alternatively, you can generally also start the machine via the API, but this one time I realized the root by mistake, so it needs to be expanded back to 10G first
[22:06] <mup> Bug #1734213 opened: Python scripts named pip* filtered out of snaps <Snappy:New> <https://launchpad.net/bugs/1734213>
[22:06] <niemeyer> resized the root
[22:06] <robert_ancell> zyga-ubuntu: thanks!
[22:06] <zyga-ubuntu> :-)
[22:06] <zyga-ubuntu> my pleasure
[22:18] <cachio> niemeyer, Spread-50 is the vm
[22:18] <cachio> I fixed the problems and it is ready to run snapd tests
[22:19] <cachio> niemeyer, coudl you please remove it from the pool?


[12:29] <BluesKaj> Hi all
[16:39] <Eickmeyer[m]> RikMills, jbicha : kdeconnect merge request accepted.
[17:21] <Eickmeyer[m]> RikMills: You may want to merge the changes I did to kinetic_staging and kinetic_archive in to the unstable and stable branches of kdeconnect's packaging. I don't want to mess with it since I don't know your workflow there.
[17:23] <RikMills> will do
[21:15] <RikMills> plasma 5.25.4 for jammy is now in ppa:kubuntu-ppa/backports-extra
[21:15] <RikMills> if anyone can do a little testing, that would be grand
[21:18] <arraybolt3[m]> Sounds fun, will do. Kinetic or Jammy? (Sounds like Jammy.)
[21:18] <RikMills> "for jammy" ;)
[21:18] <arraybolt3[m]> 🤦♂ Right, thanks.
[21:19] <RikMills> in theory the PPA should be ok with or without the normal backports being enabled
[21:27] <RikMills> anyway, thanks :)
[21:30] <arraybolt3[m]> 👍