/srv/irclogs.ubuntu.com/2017/11/23/#snappy.txt

=== gsilva is now known as gsilvapt
mupPR snapd#4276 closed: tests: document and slightly refactor prepare/restore code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4276>00:10
=== gsilvapt is now known as gsilva
=== gsilva is now known as gsilvapt
mborzeckimorning everyone05:55
ikeyweird question, but why does "snap find solus" list clementine and nextcloudclient? :D06:29
* ikey is truly baffled06:30
zyga-solusgood morning06:34
ikeymorning06:36
zyga-solusikey: hey06:37
* zyga-solus needs to take tomorrow off, too many days off, a bit tired06:38
ikey:/06:38
mborzeckizyga-solus: morning06:42
zyga-solushey :-)06:43
mborzeckizyga-solus: found an old patch that i missed whel opening all the arch related PRs06:44
zyga-solusmborzecki: oh, nice, what does it do?06:45
mborzeckiyou remember that we had an assumption that daemon user is uid 1?06:45
zyga-solusyes06:45
mupPR 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
mborzeckiwell the patch fixes the assumption :) or rather gets rid of if06:45
zyga-solusnice, looking06:46
zyga-solusmborzecki: short and simple, thanks!06:47
mborzeckiyw06:47
mborzeckihad nigthmares about the refresh timer parser? :)06:47
mvozyga-solus, mborzecki good morning06:48
zyga-solushaha06:48
mborzeckimvo: hey06:48
zyga-solusno, but I did dream of not working tomorrow ;D06:48
zyga-solusand I think I'll just do it06:48
mvozyga-solus: we had a strange wildcard error in some tests last night, do you know if this is fixed06:48
zyga-solusmvo: no, I read that sergio and gustavo were discussing it06:49
zyga-solusmvo: do you have a reference06:49
zyga-solusmvo: I'm not sure if that is the same thign06:49
zyga-solus*thing06:49
mvozyga-solus: no worries, I have a look, was just wondering if I'm chasing windmills or dragons ;)06:50
zyga-solusmvo: it's always dragons here :D06:50
zyga-solusmvo: (sometimes dragons sit on top of windmills)06:50
mvolol06:50
* mvo hugs zyga-solus 06:51
kyrofazyga-solus, what happened with https://github.com/snapcore/snapd/pull/4258 ?06:51
mupPR #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:51
zyga-soluskyrofa: I discussed it with jdstrand, we need to tweak it slightly in order not to make snap-confine too powerful,06:52
zyga-soluskyrofa: I'll get back to it06:52
zyga-soluskyrofa: I'm looking at why master breaks so often as this clamps our velocity a lot06:52
kyrofaAh okay, very good. Still a path forward, though?06:52
zyga-solusyes, totally06:53
kyrofaAlright, night guys. Note that I'm off tomorrow06:56
zyga-soluskyrofa: lovely, enjoy!06:57
mborzeckisome of the tests in my PR failed with 504 gateway timeout coming from the store, this is some bad luck07:01
zyga-solusmborzecki: store had some issues yesterady07:02
zyga-solusalso, not sure if real or fluke due do damaged tests, I saw a lot of EOF errors on assertions07:02
zyga-solusso, if you are using qemu for testing I will have one simple and sweet improvement07:07
zyga-soluscurrently running 8 workers locally, seeing almost no network traffic07:08
zyga-solusstill some polish to do but the patch is a few lines long and simple to use07:08
zyga-solusI realized that a single run burned about 2GB of data07:08
zyga-solusand my mobile quota is high but not infinite07:09
zyga-solusso this will not only be faster but also more economic ^_^07:09
zyga-solusand there's far less waiting for IO07:09
zyga-solusobligatory pic: https://twitter.com/zygoon/status/93359158120623718407:10
zyga-solus^_^07:10
mborzeckinice07:13
zyga-solusmvo: I ran main, regression and completion suites yesterday in a loop07:15
zyga-solusmvo: none of those failed with one of those weird random errors07:15
zyga-solusmvo: I'll extend that to the full suite to see if I see any pattern07:15
mvozyga-solus: interessting and good to know07:16
paulliuhi. I'm running Debian testing and I cannot run "snap run hello-world". http://paste.ubuntu.com/26025879/07:18
paulliuHow do I debug?07:18
zyga-soluspaulliu: hey, we are aware of the issue, sorry for the bad experience07:18
paulliuzyga-solus: got it. thanks. :)07:19
zyga-soluspaulliu: we made some patches but it seems it's not enough, we are looking into the issue with the help of our kernel developers07:19
zyga-soluspaulliu: it's likely the next release will have a fix or workaround07:19
zyga-soluspaulliu: for now you can try booting with apparmor=007:19
zyga-soluspaulliu: that _might_ fix it07:19
paulliuzyga-solus: thanks for the info. I just thought it was me that makes something wrong on my system. Thanks a lot. :)07:19
* zyga-solus sees some wasted traffic, adds snaps to cache 07:21
mupPR snapcraft#1755 opened: WIP:  tests: collect the autopkgtest results and save them in git  <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1755>07:29
mupPR 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:01
mupPR 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:02
zyga-ubuntuman, what's going on with EOFs on assertions08:03
=== __chip__ is now known as Chipaca
Chipacazyga-ubuntu: where?08:04
zyga-ubuntuChipaca: on random PRs, look at failures, it's a common pattern08:06
mvoChipaca, zyga-ubuntu also randomly failing: http://paste.ubuntu.com/26026114/08:08
zyga-solusmvo: hmmm08:09
Chipacamvo: gustavo was seeing that one yesterday08:09
zyga-solusmvo: do you have dpkg build logs on that debug shell?08:09
mvozyga-solus: maybe - it happend just now08:09
* kalikiana coffee08:09
mvozyga-solus: funny (sort of) - looks like no log at all08:10
Chipacamvo: well the error is because there is nothing matching snapd_*.snap08:12
zyga-solusmvo: hmm08:13
Chipacaso of all funny things, this one at least makes sense08:13
zyga-solusyes08:13
mborzecki4252 fails the same way08:14
mvoChipaca: right, there is nothing there, the interessting question is why and why did it not fail earlier08:14
mvoChipaca: I don't see anything in /home/gopath/ except the subdirs08:14
Chipacamvo: incompatible bit-registration operators08:14
mborzecki+ dnf -q -y install '/home/gopath/snap-confine*.rpm' '/home/gopath/snapd*.rpm'08:15
Chipacamvo: (bofh excuse generator time!)08:15
Chipacazyga-solus: did your changes to prepare etc land?08:15
zyga-solusChipaca: would it be hard for snap download to be a no-op if there's a file in place that's just right?08:15
zyga-solusChipaca: yes, but i have many more to make before we get the benefits08:16
mvoChipaca: lol08:16
Chipacazyga-solus: my question was because i wonder if that's why we no longer have .debs08:16
zyga-solusChipaca: well08:16
mvozyga-solus: it would be trivial, we did this a long time ago in apt08:16
zyga-solusChipaca: I doubt it's that08:16
mborzeckithe build fails https://paste.ubuntu.com/26026137/08:16
mborzeckiman the logs are not the easiest to browse08:17
zyga-solusman that's one looooong line08:17
zyga-solusexit code 2, that's helpful08:17
Chipacazyga-solus: "download be a no-op" <- didn't we already do that08:17
zyga-solusChipaca: nope08:17
zyga-solusChipaca: we pull and pull and pull and overwrite08:17
zyga-solusmborzecki: what's the error there?08:17
mborzeckiha no clue, dh failed, go install returned -208:18
mvozyga-solus: any idea about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734038 ? it looks strange and does not error for me08:21
mupBug #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:21
zyga-solusmvo: yes, you need to be on bionic08:22
zyga-solusmvo: #include is now mandatory, apparmor broke syntax08:22
mvozyga-solus: wuut? you need to be on bionic for #include?08:22
mvozyga-solus: you are saying 2.29.4 in -proposed is broken everywhere?08:22
pedronisfwiw even on xenial   man apparmor.d  doesn't mention include without #08:23
zyga-solusmvo: bionic has new apparmor that stopped supporting bare include and now requires #include08:23
zyga-soluspedronis: it was documented on apparmor documentation website08:23
zyga-solusjdstrand was surprised too :)08:23
mvozyga-solus: the bugreport is about xenial/zesty08:23
zyga-solusmvo: maybe we got a backport/update?08:23
zyga-solusmvo: it was in bionic last week08:23
mvozyga-solus: ok, so its a simple matter of s/include/#include/ ?08:24
zyga-solusyes08:24
mvozyga-solus: and we may need a .5 :(08:24
zyga-solusbut I suspect upstream will be fixed later on08:24
zyga-solusmvo: well, I honestly feel this is not our bug08:24
zyga-solusmvo: we can work around but this is broken apparmor parser08:25
* mvo sits in a corner and sobs08:25
mvozyga-solus: ok08:25
zyga-solusmvo: also, it's a conffile08:25
zyga-solusmvo: people can forever stay on the "broken" version08:26
pedronisme is a bit sceptical that they will "fix" it08:26
mvozyga-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 here08:26
zyga-solusmvo: so we carry on even if build fails, sweet08:27
zyga-solusmvo: do you think that's something I broke?08:27
mborzeckiset -e ?08:27
mvozyga-solus: git log indiciates that you touched it last ;) so there is a chance for this. but no worries08:27
zyga-solusmborzecki: I have a suspicion08:27
zyga-solusspread sets -e08:28
mvomborzecki: yeah, recent refacors probably08:28
zyga-solusand this is not carried into scripts that are not sourced08:28
zyga-solus(I hate this sourcing that is going on, everything is sourced and has side effects apart from functions08:28
zyga-solusanyway, let me fix this08:28
pedronis?08:28
pedronisdo we source things with side effects?08:28
zyga-solussure we do08:29
zyga-solusmost scripts have a bunch of functions and then happy execution down below08:29
mborzeckihm looking at fedora log I see there's snapd package, but there there should be snap-confine as well right?08:29
zyga-solusand we source them to get MATCH and stuff08:29
zyga-solusmborzecki: no, we don't want to have separate snap-confine08:29
zyga-solusmborzecki: it's just historic08:29
pedronismvo:  http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference#Include_statements  otoh it's a wiki08:29
zyga-soluspedronis: thank you for finding that!08:29
zyga-soluspedronis: it's an upstream bug08:30
pedronisit's a bizarre "bug"08:30
mborzeckihm fedora rpm spec is still building 2 packages from what i can see08:30
Chipacasigh08:30
pedronisI mean it should have been conscious08:30
zyga-solusmborzecki: it's something that needs to be fixed, but it takes time08:30
Chipacamvo: zyga-solus: so the bug is right there08:30
pedronisit's kind of hard to randomly change your syntax08:30
pedronisunless your parser is horrible08:30
Chipacamvo: zyga-solus: prepare-restore.sh does not set -e08:30
zyga-solusyes, that's what I just fixed08:31
Chipacamvo: zyga-solus: and it's executed, not sourced08:31
zyga-soluswhile I loath -e, it's the lesser evil08:31
zyga-solusyep, I reached the same conclusion08:31
zyga-solusPR coming up08:31
Chipacazyga-solus: -e -u and pipefail are the only sane way to have these set up imo08:31
mborzeckizyga-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 hint08:32
zyga-solusChipaca: !shell is saner :)08:32
zyga-solusChipaca: remind me why -o pipefail is useful?08:33
zyga-solusChipaca: (I'm writing a comment)08:33
Chipacazyga-solus: the exit status of “foo | bar” is the exit status of bar, without it08:34
mborzeckibtw. do you guys see a number of can interfaces popping up after running seccomp test suite?08:36
zyga-solusmborzecki: nope?08:36
zyga-solusmvo: btw, sergio found a very worrying thing08:36
mborzeckithey are nr0-nr3 and rose0-rose908:36
zyga-solusmvo: on reboot the interfaces are lost08:36
zyga-solusmvo: reliably08:37
zyga-solusmvo: his PR has all the details, I didn't dig into it08:37
zyga-solusChipaca: 427908:37
zyga-solusand sorry about that folks08:37
mupPR snapd#4279 opened: tests: set -e, -o pipefail in prepare-restore.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/4279>08:38
mvozyga-solus: looking09:02
mvozyga-solus: so we have more scripts that need set -eu etc?09:03
zyga-solusmvo: I think just this one as it's a new script09:04
mvozyga-solus: ok09:05
zyga-solusmvo: I'll add -u shortly, just looking at some problem09:05
mvota09:07
zyga-solusChipaca: can you please look at 428009:11
mupPR snapd#4280 opened: tests: remove obsolete workaround <Created by zyga> <https://github.com/snapcore/snapd/pull/4280>09:11
Chipacazyga-solus: why not ln instead of cp?09:11
Chipacazyga-solus: even better, cp -l (so it falls back to a plain cp if it can't ln)09:12
zyga-solusChipaca: interesting, I had some reasons but I'm re-examining now09:12
zyga-solusChipaca: there's some extra stuff coming but I think symlinks could be fine, I just hate the syntax :)09:13
Chipacazyga-solus: reflink doesn't work on the filesystems we're running tests on afaik, fwiw09:13
Chipacazyga-solus: ln, not ln -s09:14
zyga-solusChipaca: yes, only on xfs AFAIK09:14
Chipacazyga-solus: that is, hard links09:14
Chipacazyga-solus: (cp -l does hard links)09:14
zyga-solusdoes cp -l handle xdev?09:14
Chipacazyga-solus: yes09:15
Chipacazyga-solus: it falls back to a regular cp09:15
zyga-solussounds good then, I'll adjust that09:16
zyga-solusChipaca: do you know if the store proxy thing is working now?09:16
Chipacazyga-solus: --link instead of -l if you want it to self-document a little more09:16
zyga-solusChipaca: oh, for sure09:16
=== chihchun is now known as chihchun_afk
mvozyga-solus: I pushed a fix for the debian-sid failure that cachio had into his branch (just fyi)09:20
zyga-solusmvo: what was the problem?09:20
mvozyga-solus: https://github.com/snapcore/snapd/pull/4265/commits/9f534e22dabd022f72e9376bf6f84913461e85a109:21
mupPR #4265: New debian-sid-64 and debian-9-64 images for testing <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4265>09:21
mvozyga-solus: i.e. snap-confine needs a profile09:21
zyga-solusohh09:22
zyga-solusthank you, great find09:22
mvozyga-solus: yw09:23
mupPR 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-solusthanks!09:23
Chipacamy question isn't why user-data-handling failed in #4277; it's how it doesn't fail before it09:33
mupPR #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 digs09:33
mupPR snapd#4281 opened: snapstate: support for pre-refresh hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/4281>09:37
mvozyga-solus: http://paste.ubuntu.com/26026470/ is what you wnated for snap download, rightß09:38
zyga-solusyes!09:39
zyga-solusplease :D09:39
zyga-solusit will help with caching09:39
mvozyga-solus: once I wrote a test I will push a PR09:39
mvozyga-solus: slightly sad, we apparently have no test for DownloadSnap, so a good time to write one :)09:43
zyga-solus:-)09:43
zyga-solusmvo: download is totally client-side, right?09:43
mvozyga-solus: yes09:43
zyga-solusok, now way to reuse the cache but that's not too terrible09:44
Chipacazyga-solus: mvo: download should try to chat with snapd though09:46
pstolowskizyga-solus, tiny suggestion to 428009:46
Chipacazyga-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 stuff09:47
zyga-solusChipaca: yes, that would be perfect09:47
zyga-soluspstolowski: looking09:48
Chipacazyga-solus: mvo: note it could even get a filehandle back from snapd09:48
Chipaca(we don't currently do that but it's possible)09:48
zyga-solusvery good idea pstolowski09:48
zyga-solusChipaca: yeah, I was thinking about that :)09:48
zyga-solusChipaca: streaming doesn't seem too terrible though, no real difference here09:48
ChipacaOTOH as soon as we get into passing filehandles the idea of exposing snapd to the network transparently goes away09:49
ChipacaOTO²H we're already there with crednet09:49
Chipacaso, fun time09:49
zyga-soluspstolowski: updated09:49
Chipacawe have a test that only passes because of how we were looking at homes09:50
Chipaca:-)09:50
Chipacait does: mkdir -p /home/*/snap/test-snapd-tools/$rev/09:50
zyga-solus* ?09:50
Chipacawhich creates a directory in /home/ called "*"09:50
zyga-solusLOL09:50
Chipacahi-fucking-larious09:50
pedronisChipaca: well, that's tests09:50
zyga-solusChipaca: 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 spelling09:50
magicaltrouthello folks, is there any issues with the snap review queue?09:51
Chipacamagicaltrout: there shouldn't be one, why?09:52
Chipacamagicaltrout: 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:52
* Chipaca might be oversimplifying things09:53
magicaltrouthehe09:53
magicaltrouti pushed a snap 30 minutes ago09:53
magicaltroutit says failed09:53
magicaltroutbut the cli is hanging09:53
Chipacamagicaltrout: which cli?09:53
magicaltroutsnapcraft push09:53
Chipacaah09:53
magicaltroutand on the dashboard is says 2 fails09:53
magicaltroutbut there's no content in the + button09:53
Chipacawho was our EU-timeone snapcrafter?09:53
pstolowskizyga-solus, thanks, +109:54
magicaltrouthttps://imagebin.ca/v/3iGoz2K7NShK09:55
zyga-solusthank you :)09:55
magicaltroutsad times09:55
Chipacakalikiana: ^ magicaltrout might benefit from your expertise09:55
magicaltroutthat worked yesterday09:56
magicaltroutdo i kill it and restart the push?09:56
Chipacamagicaltrout: wait for kalikiana please, he'll know better than i do09:56
pedronismvo: do you have password for  snappy-stagingstore in staging ? I suppose not09:58
mvopedronis: no09:58
mvopedronis: sorry09:58
pedronismvo: that's used for the private snaps tests, we probably need to setup something shared and also transfer the snaps09:58
* mvo nods09:58
mupPR snapd#4282 opened: tests: cache snaps to $TESTSLIB/cache <Created by zyga> <https://github.com/snapcore/snapd/pull/4282>09:59
zyga-solusmvo: ^09:59
=== chihchun_afk is now known as chihchun
* zyga-solus looks for ethernet cable10:05
mupPR 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:05
pstolowskimvo, hey, there is question to you from zyga-solus in 4158 comments10:06
mupPR 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
mvopstolowski: thanks, looking10:07
zyga-soluspstolowski: reviewed 428110:10
zyga-soluspstolowski: and a kind request to squash this10:11
zyga-solusmvo: thank you, reviewed10:13
zyga-solusmvo: can you look at 4282, it's related10:13
kalikianamagicaltrout: reading the backlog...10:16
mborzeckisome weird things about running arch on linode10:17
mborzeckithe 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 this10:18
zyga-solusmborzecki: probably typical $cloud ops, they use custom kernels10:18
zyga-solusmborzecki: same was true for ubuntu but then we changed to use grub in our image10:19
magicaltroutkalikiana: 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 plug10:19
zyga-solusmborzecki: you probably need to work with niemeyer and cachio to get a better image in10:19
magicaltroutbut as the dashboard hung I think the automated review process got sad at some point10:19
mborzeckizyga-solus: yeah, probably10:19
kalikianamagicaltrout: so did the dashboard get stuck or the local command?10:19
mborzeckii'm working with the default image anyway, got it to a point that it's about to start building the package10:19
magicaltroutkalikiana: both10:20
kalikianaoh10:20
magicaltroutand then i pressed the stop review button and the cli released10:20
magicaltroutand the dashboard just switched to allow a manual review10:20
pstolowskimvo, zyga-solus thanks10:21
pedronismvo: zyga-solus: prereq are put in their own lane (not the default lane)10:24
pedronisthat's already like that in master10:24
zyga-soluspedronis: I think we were worried that we don't end up with something installed while its prepreq is missing10:25
pedroniszyga-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 itself10:28
zyga-solusah, that should be good then10:29
pedronisyes, there's nothing to do afaik10:31
mvopedronis: thanks for double checking10:31
zyga-solushmm10:44
=== mup_ is now known as mup
zyga-solusmvo: so what's up with quiet10:44
zyga-solusI just added quiet and ... man things break!10:44
mvozyga-solus: a good question, in what way do things break?10:44
zyga-solusmvo: my blazingly fast cache is idle, cpu is idle, network is idle10:45
zyga-solusmvo: but it's running apt install cups10:45
zyga-soluswoah, it's running now10:45
zyga-solusbut it was just sitting there for a long itme10:45
zyga-solushmmm10:45
zyga-solus(as in idle)10:45
zyga-solusI watch htop/dstat all the time10:45
mvozyga-solus: this might be interessting https://travis-ci.org/snapcore/snapd/builds/306221204#L2268 (+ test-snapd-tools.echo Hello10:46
mvocannot bind-mount the mount namespace file /proc/7579/ns/mnt -> test-snapd-tools.mnt: Permission denied10:46
mvosupport process for mount namespace capture exited abnormally)10:46
zyga-solusmvo: debian?10:47
zyga-solusmvo: do you have denials?10:47
mvozyga-solus: yeah, debian-sid10:47
zyga-solusmvo: I think we really want jjohansen to look and say10:47
zyga-solusmvo: it looks like a bug10:47
mvozyga-solus: http://paste.ubuntu.com/26026737/10:47
mvozyga-solus: oh, interessting, that is the rule we aded, no?10:47
zyga-solusmvo: there are rules exactly for that10:47
zyga-solusright?10:48
zyga-solusyes10:48
mvozyga-solus: I guess I need to check if the rule is really on disk10:48
zyga-solusman, 4260 fails for like the 10th time10:49
mvozyga-solus: also interessting, only failing in upgrade-basic, so maybe10:49
mvozyga-solus: yeah, harmless "sanity check install" ;)10:49
mvozyga-solus: of course the previous install won't work on debian-sid10:49
zyga-solusand more of those canot unrmarshal EOF erorrs10:49
zyga-solusmvo: are machine disks recycled?10:50
zyga-solusmvo: when we deploy, say, xenial, do we wipe the disk?10:50
zyga-solusmvo: it looks that that run keeps happening on machine that has some junk assertions10:50
* ikey likes zyga advertising solus for him so he doesn't have to :p10:50
zyga-solusbut this makes little sense10:50
zyga-solusikey: hehe :)10:50
zyga-solushmm, the LXD test could be more cache friendly10:51
zyga-solusI wonder if apt-cacher-ng can cache lxd images if we push the proxy config down10:51
* ikey goes and writes a hashmap10:52
ikeyagain10:52
zyga-solusikey: waat?10:52
zyga-solusikey: in which language and why?10:52
ikeyC10:52
zyga-solusikey: how come there's no libikey10:52
ikeythere is10:52
zyga-solussoo?10:52
ikeyhttps://github.com/intel/libnica10:52
ikeyim replacing it10:53
zyga-solusoh, nice10:53
ikeythe original lost sight and got vendored into a buttload of projects10:53
ikeybut there was no ABI promise and it makes lots of naive decisions10:53
zyga-solusikey: makes sense10:53
ikeyf.e: NcHashmapEntry *row = &(buckets[hash % (unsigned)n_buckets]);10:53
ikeyvs say, &buckets[hash & n_bucket_mask]10:54
ikeywhere n_bucket_mask = n_buckets - 1 and a power of 210:54
zyga-solusikey: I'd love to talk about that topic one day10:54
zyga-solusikey: I'm building a pet project with similar needs10:54
zyga-soluswell10:54
zyga-solusish10:54
ikeyoh?10:54
ikeybtw .s comparison of the two methods: https://hastebin.com/ekomafajoj.pl10:55
ikeyi know which one i want :p10:55
ikeydivq is hella spensive10:55
zyga-solusikey: a small home grown C library for that is designed for correctness and error handling10:55
zyga-solusikey: just I want mine to build on ... heaven forbid, windows10:56
ikeyooo ok10:56
zyga-solus(in addition to normal environment)10:56
ikeyportability is good10:56
ikeymy new design constraint is to not be glibc specific10:56
zyga-solusyeah, I'm impressed by the toolchains there10:56
ikeyfound myself fixing up some projects that explicitly #include <linux/limits.h>10:56
zyga-solusfun 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 work10:56
ikeywow10:57
zyga-solusikey: msdn has some fantastic things there on the console APIs and unix compatibility and VTs and such10:57
zyga-solus(very recent)10:57
mcphailI'm asking in genuine ignorance here - is glib deprecated for these things?10:57
ikeyhuh ok ill need to poke around it10:57
ikeymcphail, which?10:58
ikeyglibc or glib2?10:58
mcphailglib210:58
ikeyif glibc, its unportable antiunix hell10:58
ikeyand glib2 has an enormous arse10:58
ikeyyou can't trust it truly for long running processes10:58
magicaltroutyeah kalikiana the new push worked first time, the automated queue must have got sad on my previous attempt10:58
ikeydue to its internal memory management and want to leak10:58
mcphailaah ok10:58
ikeyfor clearlinux i ported clr-debug-info, a simple FUSE fs daemon that runs all the time, from glib2 to nica10:58
ikeyand switched from pthreads to C11 atomics10:59
ikeyi cut the memory usage in half and removed any leaks10:59
ikeyand it could be trusted to not grow over time10:59
ikeyanother example is when you execv{p,}e a process without forking10:59
ikeyyou're just asking to page fault the child into oblivion10:59
zyga-solusIMO glib has totally broken error handling10:59
zyga-soluswell10:59
ikeyabort()10:59
ikeyg_assert(i dont know what im doing anymore)11:00
zyga-solusish, but not what I want to aim for11:00
zyga-solusyeah11:00
zyga-solusit was NULL but that's fine, let's carry on11:00
ikeyg_critical(but yet im still running)11:00
mcphailhmm. Interesting. I've only ever played with it a bit. I just dabble in coding11:00
zyga-solusI think it's a fair question11:00
ikeyalso the vtable design of glib2 leads to far higher memory usage11:00
zyga-soluspart of my motivation os to re-invent the wheel in a different way (maybe dead end) and to learn in the process11:00
ikeyit relies on embedded structs in the malloc'd struct11:00
ikeyimagine now your vtable is simply a single pointer to a static vtable11:01
ikeyyou greatly reduce the memory usage for these "objects"11:01
zyga-solusmvo: one more step towards nicer prepare world needs one more review in 428411:01
ikeywhich is pretty much how the kernel does it (ops tables)11:01
ikeyalso with op table redirection you can get rid of a whole slew of "if (!self)" checks11:01
mupPR snapd#4284 opened: tests: merge pepare-project.sh into prepare-restore.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/4284>11:01
ikey(though arguably you should use the builtin likely/unlikely functions there)11:02
zyga-solusand we are hit with another case of mysterious failure11:02
pedronispstolowski: zyga-solus questions on #4158 made me think that it probably needs a couple more code comments, added PR comments about this11:02
mupPR #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-soluspstolowski: aww, cannot create hard link in cp --link11:02
zyga-soluser, that's Chipaca perhaps11:02
zyga-solusI guess it's back to good old cp then11:02
pstolowskipedronis, thanks, i'm in the process of adressing that11:04
mcphailikey: 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 etc11:04
zyga-soluspedronis: thank you11:04
ikeyfor standard "do a thing and exit within some predicted timeslot" theres no real reason to avoid it11:04
zyga-solusmcphail: depends on what you want:11:04
zyga-solusmcphail: make hash tables or make stuff on top :)11:04
zyga-solusboth are fun11:04
ikeyif its "im a piece of plumbing" or "i run forever" then its worth considering the options11:04
ikeyand yeah tbh, implementing ADT is a great exercise11:05
zyga-solusikey: +1000 on plubming layer11:05
ikeylearning how this stuff works internally just increases understanding11:05
mcphailcool. Cheers guys. Sorry for straying o/t11:05
zyga-solusalso one more comment11:05
ikeymy fault on that one, sorry :D11:05
zyga-solusthere's plenty of research11:05
ikeyyeah11:05
ikeyincorporate the best and distil into awesome :D11:05
zyga-solusand plenty of "good old hash table that has $magic performance so let's not re-implement"11:05
zyga-soluswhere reality is that it's junk but nobody wants to touch it11:05
ikeychained buckets are typically easiest11:05
zyga-solusand it was optimized on Sun Sparc V or something11:05
* ikey is gonna attempt a robin this time11:06
Chipacazyga-solus: why can't create hard link?11:06
zyga-solusChipaca: fedora has tmpfs on /tmp11:06
zyga-solusChipaca: I dropped --link11:06
zyga-solusChipaca: in retrospective, well, sucks11:06
zyga-solusChipaca: can 4277 be split in any way?11:07
zyga-solusChipaca: perhaps add the new functions in one PR11:07
zyga-solusChipaca: and convert things in another11:07
zyga-solusChipaca: to kill the old ones in last11:08
kalikianamagicaltrout: 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-solusChipaca: it's just too daunting to look IMO11:08
mupPR snapd#4282 closed: tests: cache snaps to $TESTSLIB/cache <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4282>11:17
zyga-solusdoes anyone know of a commad like "time" that says "transferred so-and-so many bytes"11:26
Chipacazyga-solus: why does tmpfs on /tmp break --link? (i tested exactly that and it works here)11:37
Chipacazyga-solus: there are dd-alikes with progress bars11:37
zyga-solusChipaca: because it copies from /tmp to /var and _does not_ handle xdev11:38
Chipaca4277 can be split, probably. i'll give it a go.11:38
zyga-solusChipaca: (well, hardlinks)11:38
Chipacauh11:38
Chipacazyga-solus: my /tmp is no longer tmpfs? what11:39
zyga-solusChipaca: it is tmpfs on fedora11:39
zyga-solusChipaca: note that it didn't fail everywhere :)11:39
Chipacai thought it was tmpfs here11:39
zyga-solusnope11:39
mborzeckihmm go unit tests do not really need a package, but we build it anyway in prepare :/11:40
zyga-solusmborzecki: in the unit suite?11:40
zyga-soluswhee11:41
mborzeckiyes11:41
Chipacazyga-solus: too many laptops; it's a tmpfs on my other one11:41
zyga-solusI'm using measure-each for the 1st time now11:41
Chipacazyga-solus: ln || cp?11:41
zyga-solusChipaca: nah, it's just temporary, next patch will restore --link11:41
zyga-solusChipaca: :-)11:41
Chipacaok11:41
Chipacait's interesting that it doesn't have --link=auto11:42
Chipaca¯\_(ツ)_/¯11:42
mborzeckizyga-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-solusChipaca: TEH BLEADING EDGE ;-)11:42
zyga-solusmborzecki: yeah, that's weird / silly11:42
zyga-solusmborzecki: but, so is much of our preapre code :)11:42
zyga-solusmborzecki: I'll clean it up to be easier to understand what's going on11:42
cachiozyga-solus, the test interfaces-network-control-tuntap still failing in the new debian-sid https://travis-ci.org/snapcore/snapd/builds/306221204#L470711:42
zyga-solusmborzecki: suite prepares are in -f11:42
zyga-solus-e is ready for review now :")11:43
cachiozyga-solus, not sure if it is the same error that we used to see11:43
zyga-soluslooking now11:43
zyga-soluscachio: yes, I think so11:44
zyga-solusmvo: 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-solusmborzecki: can you please look at 428411:44
mborzeckilooking now11:45
mborzeckihmm will need to update arch integration, but that's not a big deal11:47
niemeyerHello world11:55
zyga-soluso/11:55
niemeyerThanks!11:55
niemeyerThank you all!11:55
niemeyerYou are all great to work and interact with.11:55
zyga-soluswoot, you are in a good mood today :)11:57
niemeyerI've heard today we're supposed to give thanks according to some conventions. Sounds like a good idea.11:58
kalikianaAnd no turkeys have to die this way :-P I like it11:59
mupPR 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:00
ikey**ohhh*12:07
ikeyits thanksgiving12:07
* ikey finally gets it12:07
zyga-solusah12:07
ikeythat took me longer than i care to admit12:07
* zyga-solus thanks ikey for making something fresh from distro POV12:07
ikeyoh, ty :D12:07
mborzeckizyga-solus: i'll open an early pr with spread support for arch, so that we can better track the conflicts between this and your refactor12:07
* ikey thanks you lot for caring about users and doing something about it :]12:08
zyga-solusok12:08
zyga-solusmborzecki: thanks, I'll try to help with conflicts12:08
magicaltroutcan you install a local charm to test in jail mode so I can see if the confinement makes it bomb12:10
mupPR snapd#4285 opened: tests, spread: add Arch Linux to CI systems <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4285>12:10
magicaltroutwithout bothering to push files to the store?12:10
zyga-solusmagicaltrout: probably --dangerous --jail12:10
magicaltroutooh bloody dangerous12:10
zyga-solusmagicaltrout: but I don't remember trying that12:10
magicaltrouti always forget that one12:10
zyga-solusmborzecki: general comment, I think we want separate snapd package for eventual inclusion into arch (again)12:13
zyga-solusmborzecki: or perhaps aupdate12:13
zyga-solusmborzecki: and that would resolve some of the complexity and the TODO in build_pkg12:13
zyga-solusmborzecki: reviewed12:14
mborzeckizyga-solus: thanks12:14
zyga-solusmborzecki: and please rebase/merge12:14
zyga-solusmborzecki: (sorr for the conflict there)12:15
mupPR 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
mborzeckinp12:15
zyga-soluspstolowski: approved 4158 though I think mvo wanted to move part out to a different PR12:15
pstolowskizyga-solus, yes, I know and responded (will move to separate PR)12:16
* pstolowski lunch12:16
zyga-soluspstolowski: thanks, perfect12:18
zyga-solusmvo: 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:20
zyga-solusI used ~20GB of bandwidth on tests today12:21
zyga-solus(cached)12:21
zyga-solusI actually get to use CPUs now, not just wait for IO12:21
mvozyga-solus: I was thinking the same, have a pr open but did not press the ok button :)12:26
zyga-solusmvo: thanks! please do12:27
mupPR 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:27
mupPR 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:51
mborzeckiis there a way to poke spread so that it'll kill remote command and clean up?12:54
zyga-solusmborzecki: ctrl-c12:57
zyga-solusmborzecki: other than that kill it and then discard the machines with -discard12:57
mborzeckiyay, -discard does magic12:59
mborzeckithanks12:59
zyga-solusoh12:59
zyga-solusstandup time12:59
zyga-ubuntujamesh: thanks for the spread test~!13:17
jameshzyga-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 VM13:18
zyga-ubuntujamesh: 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 heavy13:19
* jamesh is still waiting for the NBN to roll out in his suburb13:19
zyga-ubuntusorry guys my desktop froze again :/13:20
zyga-ubunturebooted hard way and will be back soon13:20
kalikianazyga-ubuntu: graphics drivers?13:23
mupPR snapd#4280 closed: tests: remove obsolete workaround <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4280>13:23
zyga-ubuntukalikiana: maybe13:23
mupIssue 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:36
mupPR 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:43
zyga-ubuntujdstrand: hey, thank you for your feedback so far; I'm back to working on this so expect some more PRs13:48
zyga-ubuntujdstrand: but I write for another issue actually, do you think you can look at 4100, it's close to landing but has unanswered questions13:48
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
pedronismvo: this is the bug: https://bugs.launchpad.net/snapd/+bug/173391013:56
mupBug #1733910: snapd should track what user installed what, and use the appropriate macaroon in auto-refresh <snapd:Confirmed> <https://launchpad.net/bugs/1733910>13:56
mborzeckiyou actually have to have shellcheck installed to even hit that branch in run-checks13:58
Chipacawe still don't have shellcheck on the spread images? :-(13:59
pedroniswe don't13:59
Chipacaniemeyer: i thought you were going to install it?13:59
niemeyerChipaca: Hm?14:00
mborzeckihmm i've installed it on arch and hit this14:01
mupPR snapd#4287 opened: tests/lib: fix shellcheck errors <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4287>14:03
mborzeckitrivial review ^^14:03
zyga-ubuntudone14:05
mborzeckizyga-ubuntu: thanks14:06
zyga-ubuntuI wonder why 4260 fails consistently14:08
zyga-ubuntuit seems like this is not a fluke14:08
zyga-ubuntubut actual consequence of the changes14:08
cybrNauti think i found a snap pack that will not install on Debian -- which, if I understand corretly, defeats the purpose of snapcraft14:10
sergiusenspopey 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
cybrNautaren't "snap" packages supposed to be something that "just works"?14:10
sergiusenscybrNaut which package? it might be that it doesn't work anywhere14:11
cybrNauti go to https://anbox.io/, and find a snap pack that has an embedded dependancy on PPAs14:11
cybrNautPPAs are Ubuntu-specific14:11
cybrNauti 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/614:12
cybrNauteven though "snapd" is offically available on debian14: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:12
ogra_*the anbox14:13
cybrNautogra_: your phrasing kind of made it clear.. i'm not installing anbox... i'm installing an installer14:13
ogra_right14:13
cybrNautso i suppose there would be no problem using the snap to install an installer.. but then the installer is useless14:13
ogra_and the installed uses PPAs etc ... and in the end installs the anbox snap14:13
mborzeckizyga-ubuntu: hm fails on snap ack <..whatever>14:13
sergiusensyou 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 everywhere14:13
ogra_once it did set up the modules as needed etc14:13
ogra_sergiusens, anbox isnt classic, only the installer IIRC14:14
sergiusensright, or the case of an "installter"14:14
sergiusenswhich essentially makes it classic14:14
ogra_cybrNaut, there should be instructions somewhere to do all the setup in debian i think14:15
ogra_sadly morphis is not around atm14:15
ogra_he is the one who could point you to the instructions (if theer are any)14:15
mborzeckizyga-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 broken14:15
cybrNautogra_: i suspect it'll involve cloning the github project and building that14: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 involved14:16
cybrNautogra_: i see a manual install process here https://github.com/anbox/anbox which looks reasonable14:18
cybrNautthanks for the help.  i'll try the manual process since i'd rather not mess with PPAs14:19
zyga-ubuntupstolowski: commented on 410814:20
zyga-ubuntu4281 is green and needs a 2nd review14:20
zyga-ubuntuniemeyer: perhaps ^14:21
pstolowskizyga-ubuntu, thanks!14:21
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:22
pedronismborzecki: something is definitely off with that branch, but unclear what14:23
Chipacabloodearnest: 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 pstolowski14:30
Chipacabloodearnest: i haven't much to say wrt snapctl14:30
mupPR snapd#4288 opened: Adding "set -e" to test lib scripts <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4288>14:30
mupPR snapd#4288 closed: Adding "set -e" to test lib scripts <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4288>14:32
pedronismborzecki: it would seem something there broke client parsing of server responses14:33
pstolowskiChipaca, yes, I've been invited to this topic today already, just didn't get to respond yet14:34
niemeyerzyga-ubuntu, pstolowski: Looking14:45
niemeyerChipaca, pstolowski: Responded there14:46
cybrNautlooks 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
pstolowskithanks niemeyer14:47
Saviqpopey: this something you guys aware of? https://imgur.com/a/QiDAY14:49
popeySaviq: depends, where'd you get that?14:50
cachioniemeyer, do you know which are the base packages that you installed in the ubuntu images on linode?14:57
cachiothose needed to make spread run the snapd suite14:57
niemeyercachio: Figuring out which packages are necessary for the suite and isolating them in a reusable way was literally the work you did15:04
niemeyercachio: The images weren't changed much other than making sure they would boot15:05
cachioniemeyer, ok15:05
niemeyercachio: and *removing* stuff to make them lighter15:05
zyga-ubuntuthe measurement stuff I did can also detect that and keep it up to date15:06
cachioniemeyer, do you  have the list of images available on linode?15:08
niemeyercachio: Our images or their images?15:11
cachioniemeyer, their15:11
niemeyerpstolowski: Reviewed15:11
mupPR snapd#4287 closed: tests/lib: fix shellcheck errors <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4287>15:12
niemeyercachio: You can use the API for a complete list.. this is the interesting stuff: https://www.linode.com/distributions15:12
cachioniemeyer,  tx15:13
niemeyercachio: np15:13
zyga-ubuntumborzecki: 4285 fails now15:14
mborzeckizyga-ubuntu: i know, it's the -Syu thing15:15
mborzeckizyga-ubuntu: more details here if you're interested: https://forum.snapcraft.io/t/integrate-arch-linux-into-ci-pipeline/2904/315:16
zyga-ubuntuthanks, looking15:16
=== cachio is now known as cachio_lunch
mborzeckii think i'll just make all the installation commands -Syu for now15:17
mborzeckithen we can reiterate and maybe use some custom images that are rebuilt daily or sth15:18
* zyga-solus managed to get to 5/196 without failures now, nice :)15:40
zyga-solus8/196, another run15:45
pstolowskiniemeyer, thanks, updated15:48
=== chihchun is now known as chihchun_afk
mborzeckizyga-solus: pushed 2 more patches, let's see how far it gets this time15:51
pstolowskiniemeyer, btw, can you cast your eye on #4259 again too?15:51
mupPR #4259: snapd: fix handling of undo in the taskrunner <Created by stolowski> <https://github.com/snapcore/snapd/pull/4259>15:51
pedronispstolowski: we need that code for normalizing int and float afaiu15:52
pedronisor we need ot change the rules15:53
niemeyerYeah, the original suggestion was to move it into SetAttr time15:53
niemeyerpedronis: Would that not work?15:53
pstolowskipedronis, because interfaces themselves can set values15:53
elopiodamn, I lost a " in travis. Sooo close.15:53
pedronispstolowski: and because JSON pcakage has slightly different rules15:53
pedronisitself15:53
pstolowskipedronis, okay, i'll make a separate normalize() helper for this15:53
mborzeckiniemeyer, and if you still feel fresh enough for reviews, would you mind taking a look at #4269?15:54
mupPR #4269: timeutil: new refresh timer parser <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4269>15:54
niemeyerSure thing15:54
mborzeckithanks15:54
pedronisniemeyer: well right now pstolowski just removed it (if I read correctly), I don't care too much about the details15:54
pedronisbut we need it and it needs to be recursive afaict15:55
FaultsI have a quick question. Why most Snaps looks ugly... like Windows NT 4.0. I suppose Snaps not support theming from OS?15:55
niemeyerpedronis: My original point is that we don't want that on copying15:55
niemeyerpedronis: Does that make sense?15:55
pedronisniemeyer: yes, but the code will be similar (a kind of copy)15:56
pedronisI suppose we need normalize and copyAttributes15:56
niemeyerFaults: There's on going work to make snaps automatically use a theme that matches the system15:56
=== cachio_lunch is now known as cachio
niemeyerFaults: Some details here https://forum.snapcraft.io/t/use-the-system-gtk-theme/496/27?u=jamesh15:56
niemeyerFaults: They look ugly in some cases because that's not finished yet15:57
FaultsOh lovely! Thanks from quick reply niemeyer :)15:57
niemeyerMy pleasure15:57
FaultsIdea of Snap (and flatpak) is pure gold!15:57
niemeyerpedronis, 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:58
pstolowskiniemeyer, 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 once15:59
pstolowskiniemeyer, and yes, it was copy+normalize in one method15:59
niemeyerpstolowski: Still bogus.. the static values you get from the snap are guaranteed to be correct because the reading logic fixed them16:00
niemeyerpstolowski: It's the modifications thereafter that need to be accounted for16:00
pstolowskiniemeyer, ok, i get this, i'm adding a separate normalize method just for setting dynamic attributes. copy will be made for static ones16:00
niemeyerpstolowski: Brilliant, thanks!16:00
pstolowskiand copy will assume correct types are used already, no normalization16:01
* zyga-solus got up to 9/19616:19
zyga-solus(and had dinner)16:19
* kalikiana configured mypy in syntastic, not super fast but very comfortable to work with16:21
mupPR snapd#4289 opened: snapstate: move autorefresh code into autoRefresh helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4289>16:25
zyga-ubuntumvo: can that not be based on 4161?16:27
zyga-ubuntumvo: it's a bit hard to see what's new16:27
pedronisI would have expected the changes in the reverse order, first refactor, then new feature16:29
pedroniswith this  we need to land #416116:29
mupPR #4161: snapstate: add support for refresh.schedule=managed <Created by mvo5> <https://github.com/snapcore/snapd/pull/4161>16:29
pedronisfirst16:29
zyga-solusyes, I agree16:30
cachioniemeyer, spread 46 ready again16:30
niemeyercachio: There we go16:31
cachioI removed a set of packages16:31
mvopedronis, zyga-ubuntu ups, sorry, happy to revert the order again16:31
mupPR 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:31
mupPR snapd#4289 closed: snapstate: move autorefresh code into autoRefresh helper <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4289>16:33
* kalikiana wrapping up for the day16:36
pedronismvo: thanks, unless you think the refactoring will be very controversial, in which case the other order could also work16:42
niemeyercachio: 1.3G \o/16:43
mupPR snapd#4290 opened: snapstate: move autorefresh code into autoRefresh helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4290>16:43
mvopedronis: 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
pedronismvo: I think it should be fine, it doesn't look super big16:44
cachioniemeyer, :)16:45
cachioniemeyer, let's see if that works properly now16:46
niemeyercachio: Ok, should I bake it?16:46
cachioyes16:46
cachioniemeyer, ~16:47
niemeyercachio: on it16:47
zyga-ubuntumvo: +1 on 429016:50
mvozyga-ubuntu: thanks, just fixed one tiny issue (force push to keep history cleanish)16:54
zyga-solusoh, what was it?16:54
mvozyga-solus: forgot to add the snapManager.LastRefresh() accessors16:54
mvozyga-solus: unit tests failed, so obvious16:55
mvozyga-solus: actually a merge artifact but anyway, tiny and obvious16:55
zyga-solusmvo: can you please have a quick look at 422716:55
zyga-solusmvo: it's green and has one review16:55
mvosure16:57
mupPR snapd#4227 closed: tests: add test for frame buffer interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4227>16:57
zyga-solusgreat, back on 25 :D16:58
zyga-soluscachio: do you have the patch that is missing in 426?17:00
zyga-solus426517:00
cachiozyga-solus, I am working on the tests that fail sporadically related to gpg17:02
cachioI'll try to push today17:02
zyga-soluscachio: is this for that particular PR?17:02
cachiozyga-solus, yes17:06
cachioit is failing on debian-917:06
cachiozyga-solus, in the last execution failed https://travis-ci.org/snapcore/snapd/builds/306221204#L388817:09
om26erHow much time before snapcraft 2.35 moves from xenial-proposed to -updates ?17:09
cachiozyga-solus, debuging I saw that gpg was failing to create/delete keys17:09
cachioit was trying to create some dirs in /root/....17:10
* om26er knows it was accepted to -proposed only an hour ago.17:10
cachiozyga-solus, I am running the full suite17:11
cachiozyga-solus, it can not be reproduced if you just run this test17:11
zyga-soluscachio: what is the error that you saw?17:12
zyga-soluscachio: typically gpg breaks on lack of entropy17:12
cachiozyga-solus, the entropy was ok17:13
cachiolike 250017:13
zyga-soluscachio: debian may use differnt source of randomness from other distros (perhaps)17:13
zyga-soluscachio: aha17:13
cachiozyga-solus, I can share the vm once it failes17:14
cachiofails17:14
zyga-soluscachio: I'd like to see the error message17:14
zyga-soluscachio: I'll probably break soon, my back is giving me signals it's enough for today17:14
cachiozyga-solus, np, I'll leave more info in the PR17:15
niemeyercachio: fedora-26-64 is ready17:20
cachioniemeyer, great, testing it17:20
Son_Gokucachio, is fedora-27-64 and fedora-rawhide-64 synced up to the latest?17:21
zyga-soluspedronis: can you please look at http://paste.ubuntu.com/2602922717:21
Son_Gokuaka "dnf --refresh distro-sync"?17:21
zyga-soluspedronis: is that a sane assertion (syntax wise)17:22
cachioSon_Goku, no yet17:22
Son_Gokuok17:22
zyga-soluspedronis: this is what we fail on that EOF bug17:22
cachioSon_Goku, I'll do that after 2617:22
Son_Gokucool17:22
pedroniszyga-solus: it looks like one, I don't the problem is assertion17:23
pedroniszyga-solus: my guess would be the change in response,  but I'm not sure why it would trigger problems17:23
pedroniszyga-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 happening17:24
zyga-soluspedronis: right, I'm looking at the diff again but nothing stands out17:25
zyga-soluspedronis: the only new thing is Tracks17:25
zyga-soluspedronis: it didn't have any annotation before17:25
pedronisbut that struct is not involved with ack at all17:25
pedronisas I said afaict the only logical candidate17:25
zyga-solushmm17:25
pedronisis the change in response.go17:25
pedronisit would be good to verify that theory17:26
zyga-soluspedronis: sure, that's easy17:26
zyga-solusthank you17:26
zyga-soluspedronis: so, it's not that17:30
zyga-soluspedronis: rebuilt snap, snapd, reinstalled, restarted snapd17:30
pedroniszyga-solus: actually I'm quite sure it is17:31
zyga-soluspedronis: ok, let me re-check17:32
pedronisI mean I see the now the code17:32
pedroniswhy that would matter17:32
pedroniswe do things like this in client:   err := jsonutil.DecodeWithNumber(bytes.NewReader(rsp.Result), v)17:33
pedronisjson.Unmarshal(rsp.Result, &resultErr)17:33
zyga-solusok17:33
mupPR 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-solusI definitely removed that change17:33
pedronisand this is the field in the client:          Result     json.RawMessage `json:"result"`17:33
zyga-solusand rebuilt17:33
* zyga-solus wonders17:33
pedronisso if the field is not there (instead of null), I suspect those to break with EOF17:34
Chipacazyga-solus: 4291 is the syscall bits alone17:34
zyga-solusand restarted17:34
zyga-solusChipaca: woot, thank you!17:34
zyga-soluspedronis: could it be a combination, I'm sure I removed this aspect of the patch17:34
zyga-soluspedronis: and new snapd is runing17:34
zyga-solus*running17:34
zyga-solusah17:35
zyga-solussorry, obviously17:35
zyga-solusreexec17:35
pedronisheh17:35
zyga-solusthank you17:36
zyga-solus:)17:36
pedronisnow we need to decide whether we want to fix client or we consider this an incompatible change17:36
pedronismaybe Chipaca or niemeyer have opinions on that17:37
zyga-solusyes, confirmed17:37
zyga-solusfunny outcome17:37
pedroniswith how client is written we cannot omit result17:38
pedronisatm17:38
niemeyerI'm out of context.. can someone summarize?17:38
pedronisniemeyer:    is this change:  https://github.com/snapcore/snapd/pull/4260/files#diff-e1016939c627280d9f6c53bdab0530bf17:39
mupPR #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-solusniemeyer: 4260 introduced a change that broke tests, it added "omitempty" to daemon response17:39
zyga-solusniemeyer: this broke client that assumes there's something there17:39
pedroniseven if just "null"17:40
niemeyerzyga-solus: What's the field?17:40
zyga-solushttps://github.com/snapcore/snapd/pull/4260#discussion-diff-152852846R8217:40
zyga-solus"result"17:40
pedronisin respJSON17:40
pedronisour response wrapper type17:40
niemeyerI can see the argument both ways..17:41
niemeyerIt's pretty silly for us to be sending null when it's not present17:41
niemeyerIt also seems somewhat silly to change that at this point17:41
zyga-solusshall I undo that aspect?17:41
zyga-solusI have it checked out17:41
zyga-solus(then the rest can presumably land)17:41
niemeyerzyga-solus: Yeah, I don't really see much of a benefit on the change, other than being more aesthetically pleasing17:42
mupPR snapcraft#1756 opened: tests: add the missing quote on autopkgtest run <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1756>17:43
zyga-solusI'll push this with a small test17:43
cachioniemeyer, could you please start the spread-46 again, I need to install a pckg17:46
cachioa dependency seems to be missing, I see this error "fw_printenv: command not found"17:47
niemeyercachio: Done.. up in a few17:47
cachioniemeyer, tx17:47
Chipacapedronis: what's the context?17:49
Chipaca(way too much backlog)17:50
Chipacapedronis: ah! just saw you tell gustavo :-)17:50
Chipacareading17:50
zyga-soluspushed, it should pass now17:51
cachioniemeyer, done17:54
cachioniemeyer, it was failing to prepare the suite17:54
zyga-solusChipaca: much shorter and nice to review17:57
zyga-solusChipaca: just thinking aloud18:04
zyga-solusChipaca: let's introduce uid_t, gid_t18:04
zyga-solusinstead of everyone and their $pet remembering to use uint3218:04
Chipacazyga-solus: well... uid_t is the reason we have this mess in the first place18:05
Chipacait's way too obscure what exact integer type a given _t is18:05
Chipacaso, not a fan here, today18:05
zyga-solusChipaca: but that's in C where nothing checks18:06
zyga-solusChipaca: in go we'd, at least, get checks18: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:06
Chipacazyga-solus: what would you call the type?18:07
zyga-solusChipaca: UserID, GroupID perhaps18:08
zyga-solusmouthful but to the point18:08
Chipacathat's a type name?18:08
Chipacazyga-solus: tempted to say call it ID, as in user.ID18:09
zyga-solusChipaca: and Group.ID18:09
Chipacazyga-solus: yep18:10
zyga-solusChipaca: and have a cho.Own() calls? :D18:10
Chipacazyga-solus: no18:10
Chipacazyga-solus: clearly it'd be ch.Own()18:10
pedronisheh18:10
Chipacazyga-solus: and ch.Sh()! it's perfect18:10
Chipacai mean, seriously user.UserID is nasty18:11
zyga-solusChipaca: unix.UserID ?18:12
zyga-solusChipaca: ^_^18:12
zyga-solus\\o18:12
zyga-soluso//18:12
zyga-solus\o/18:12
Chipacacould be18:12
Chipacaalthough that does clash with the new syscall18:12
Chipacabut not bothered about that tbh18:13
zyga-solussend partial review18:13
zyga-solusso again, to ensure everyone knows, I'm off tomorrow18:14
zyga-solusgotta go and see what's outside the thing called door18:14
pedronisI never noticed that go uses marker methods sometimes18:15
Chipacazyga-solus: chaos and anarchi18:15
zyga-soluspedronis: marker methods?18:15
pedronisos.Signal.Signal18:15
pedronisis what I noticed18:15
zyga-solusinteresting18:17
cachiozyga-solus, https://paste.ubuntu.com/26029507/18:21
Chipacaeep18:21
Chipacajust noticed "Tracks" in the json output18:22
Chipacawhen/how did that happen18:22
cachiozyga-solus, if you need access just ask18:22
zyga-solusChipaca: that's a new thing18:24
zyga-solusChipaca: it's in that PR18:24
zyga-soluscachio: interesting18:25
zyga-soluscachio: perhaps something we can find in the source code of gpg18:26
zyga-solusbut a long shot18:26
zyga-solusnot sure what's wrong18:26
mupPR snapcraft#1757 opened: Saving snap-build assertion as '.build' <Created by cprov> <https://github.com/snapcore/snapcraft/pull/1757>18:31
pedroniszyga-solus: cachio: it might be gpg2 vs gpg1  (in principle we support both but afaik we test mostly gpg1)18:32
cachiozyga-solus, not sure18:37
zyga-solusmvo: hey18:37
cachiopedronis, zyga-solus using gpg I can create keys18:38
zyga-solusmvo: if around 4290 has some comments from pedronis but is good to merge otherwise18:38
zyga-soluscachio: which version is in sid?18:38
mvozyga-solus: checking18:38
zyga-solusthanks!18:38
cachiozyga-solus, 2.1.1818:39
cachiosorry18:39
cachiothis is not sid18:39
cachiothis si debian-918:39
cachioit is working properly on sid18:39
pedronisso unstable works, but current version doesn't ?18:41
cachiopedronis, yes18:41
pedronis(that sounds interesting, I would have expected neither or the reverse)18:41
pedronisI wonder what's different18:42
pedroniscachio: what gpg version to they have each ?18:42
pedroniss/to/do/18:42
cachiochecking on sid18:43
cachiopedronis, it will take few minutes18:43
mupPR snapcraft#1758 opened: tests: move the ppa test trigger to lxd <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1758>18:43
cachioniemeyer, any news about the fedora-26?18:46
niemeyercachio: It's back at 1.6G :)18:46
cachioniemeyer, I just install 450KB18:49
cachioheeeh18:49
niemeyercachio: Clearly there's quite a bit more that is happening on the image every time we boot18:49
niemeyercachio: No matter how terrible the algorithm of resize2fs is, it's probably deterministic18:50
niemeyercachio: If we figure what that thing is, we can learn to disable it, or at least clean it back up18:50
cachioniemeyer, I could disable the timer18:51
cachioservice18:51
cachioniemeyer, I'll take a look and research a bit more18:52
niemeyercachio: Thanks18:52
cachiois it up?18:52
niemeyerYeah18:52
niemeyerNo, sorry18:52
niemeyerBooting it back up now18:52
cachiopedronis, gpg (GnuPG) 2.2.218:53
cachioon sid18:53
cachioit is almost the same18:53
mupPR snapd#4292 opened: snapstate: store userID in snapstate <Created by mvo5> <https://github.com/snapcore/snapd/pull/4292>18:55
mupPR snapd#4170 closed: cmd/snap-update-ns: add planWritableMimic <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4170>19:19
cachioniemeyer, please try again with the 4619:32
cachioI disabled the service which triggers the automatic updates19:33
niemeyercachio: Image is ready20:27
cachiosize?20:30
cachioniemeyer, it was beter?20:30
sergiusenselopio 2.35 is in -proposed20:30
cachiobetter20:30
elopiosergiusens do you want me to test it instead of fixing my 2 bugs tomorrow?20:31
sergiusenselopio I am more interested in you fixing the error stuff first, then the SRU testing and last the bugs20:35
elopioAck20:35
mupPR 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
mupPR 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
niemeyercachio: Yeah, back to 1.320:38
cachioniemeyer, nice20:39
mupPR 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>20:49
sergiusenselopio mind reviewing snapcraft#1759 before you EOD?21:43
mupPR snapcraft#1759: many: ensure classic confined binaries use the correct interpreter <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1759>21:43
mupPR snapcraft#1759 opened: many: ensure classic confined binaries use the correct interpreter <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1759>21:44
cachioniemeyer, sadly I'll need the spred 4621:51
cachioI found the problem in the setup21:52
cachiois it missing a grub pkg21:52
niemeyercachio: I can't fire it right now, but you can reuse the image and fire a new machine22:03
cachiook22:03
mupPR 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
niemeyercachio: 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 first22:05
mupBug #1734213 opened: Python scripts named pip* filtered out of snaps <Snappy:New> <https://launchpad.net/bugs/1734213>22:06
niemeyerresized the root22:06
robert_ancellzyga-ubuntu: thanks!22:06
zyga-ubuntu:-)22:06
zyga-ubuntumy pleasure22:06
cachioniemeyer, Spread-50 is the vm22:18
cachioI fixed the problems and it is ready to run snapd tests22:18
cachioniemeyer, coudl you please remove it from the pool?22:19

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!