[04:58] <mup> PR snapcraft#1312 opened: state: fix the name of the source details <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1312>
[06:24] <mup> PR snapd#3290 closed: add support for `snap install foo --channel=3.4` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3290>
[06:51] <mup> PR snapd#3307 opened: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307>
[06:56] <Chipaca> *yawn*
[07:04] <mup> PR core#39 opened: add version-script <Created by mvo5> <https://github.com/snapcore/core/pull/39>
[07:04] <mup> PR snapd#3308 opened: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308>
[07:13] <Chipaca> ohhhhh
[07:13]  * Chipaca figured out why so many tests failed
[07:13] <Chipaca> MATCH *must* take the thing it's matching from via stdin
[07:13] <Chipaca> ah well
[07:14] <Chipaca> school run now, fix later
[07:16] <zyga> re
[07:16] <zyga> good morning
[07:21] <morphis> zyga: morning!
[07:21] <morphis> zyga: pushed two PRs this morning which start introducing things necessary for fedora/suse spread testing
[07:27] <zyga> morphis: I saw, I'm reading one now! :)
[07:29] <morphis> zyga: :-)
[07:32] <zyga> morphis: commented on 3308
[07:36] <pstolowski> morning
[07:37] <zyga> morphis: commented on 3307 now
[07:38] <zyga> o/
[07:39] <zyga> pstolowski: if you remove this part of https://github.com/snapcore/snapd/pull/3282/files#r115504625 we can land that branch right away
[07:39] <mup> PR snapd#3282: hooks: default timeout <Created by stolowski> <https://github.com/snapcore/snapd/pull/3282>
[07:39] <zyga> pstolowski: then the extra change can be made in a separate PR
[07:40] <pstolowski> zyga, the change from 5 to 10?
[07:40] <zyga> pstolowski: yes
[07:40] <pstolowski> zyga, ok, doing
[07:40] <zyga> thank you!
[07:40] <zyga> morphis: can you do a quick review of (tiny) https://github.com/snapcore/snapd/pull/3262
[07:40] <mup> PR snapd#3262: cmd/snap-confine: aggregate operations holding global lock <Created by zyga> <https://github.com/snapcore/snapd/pull/3262>
[07:41] <morphis> zyga: sure
[07:41] <zyga> mvo: does https://github.com/snapcore/snapd/pull/3111 need more work or is that a definite +1?
[07:41] <mup> PR snapd#3111: snapd: initial implementation for systemd software watchdog for snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/3111>
[07:41] <morphis> zyga: replied on both PRs
[07:41] <zyga> thanks
[07:41] <mvo> zyga: it fails in tests currently
[07:41] <mvo> zyga: in myserious ways
[07:42] <mvo> zyga: let me have a look at it now
[07:42] <morphis> zyga: done
[07:43] <mvo> zyga: oh, looks like test-failure are gone
[07:43] <mvo> zyga: strange
[07:45] <zyga> morphis: replied
[07:46] <zyga> mvo: I spent some time last night on gardening PRs, maybe that fixed it
[07:48] <morphis> zyga: my point for the package installation barely is, when I add a new distribution I just have to edit a single file and not have to touch hundreds of test cases. If a test case needs a specific package there it should express that in a common way "netcat" and the layers below will map that correctly. The really becomes a maintenance burden. Also respect variants of distribution with different package names etc.
[07:49] <zyga> morphis: that assumes that it is sufficient. My point is that it is a magic assumption that may not hold. What if you need two packages?
[07:49] <zyga> morphis: I bet you will need to edit all files anyway
[07:49] <morphis> why that?
[07:49] <zyga> morphis: and this introduces extra layer that feels wrong
[07:49] <zyga> morphis: because something may be installed by default on one distro and not in another
[07:50] <morphis> zyga: I take this really like an "interface" which has different implementations
[07:50] <zyga> morphis: I think there is no such thing because those packages can have different content
[07:50] <zyga> morphis: (maybe not snapd but certainly true for others)
[07:50] <zyga> morphis: anyway, I think another review is needed
[07:51] <morphis> zyga: so if you express "netcat" and that is shipped by default the apt-get call will either do nothing or we tweak the install function to detect that an do nothing
[07:51] <morphis> right now it falls back to the supplied name but we can also ignore any errors
[07:51] <morphis> zyga: actually it feels wrong to me to express all these distribution specifics in the test cases we have
[07:52] <morphis> zyga: but yeah, lets have another review :-)
[07:53] <mvo> zyga: re the next cloud update - this only happens inside lxd apparently
[07:53] <mvo> zyga: just fyi
[07:53] <zyga> mvo: thanks for the hint!
[07:54] <mvo> zyga: I could not reproduce on a regulra system and kyrofa also could not reproduce the nextcloud failure on a regular system, but it failed for him inside lxd. I will update the title of the post
[07:55] <zyga> mvo: I honestly don't have a good feeling for lxd; I don't use it daily and we don't test it at all so there may be dragons of any sizes lurking inside
[08:01] <Chipaca> TFW you're looking at a test and wondering how it ever passed before
[08:04] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/3289 needs a 2nd review if you are in review mood
[08:04] <mup> PR snapd#3289: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/3289>
[08:05] <Chipaca> zyga: got a lot of MATCH-related state right now
[08:05] <zyga> Chipaca: stay there then :) that branch would be great to land too :)
[08:19]  * zyga -> breakfast
[08:19] <mup> PR snapd#3262 closed: cmd/snap-confine: aggregate operations holding global lock <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3262>
[08:22] <morphis> zyga: do you have time today to check https://github.com/snapcore/snapd/pull/3222 again?
[08:22] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[08:27] <zyga> morphis: yes, I certainly will; is the discussion there resolved? I recall gustavo had some questions/comments
[08:27] <morphis> zyga: he didn't responded yet, will ping him as well when he comes online
[08:34] <morphis> zyga: when you have a few min: https://build.opensuse.org/request/show/494796
[08:37] <zyga> morphis: done, you may want to disable leap 42.1 on your branch
[08:38] <morphis> zyga: yeah, this branch will be removed anyway once you merge :-)
[08:39] <morphis> zyga: you had any time for the Yocto review?
[08:42] <zyga> morphis: not quite, it's still open it my tab; I'll do my best to review it before the end of week today
[08:42] <morphis> zyga: we're not in a hurry
[08:43] <morphis> zyga: https://github.com/morphis/meta-snappy/pull/10 will only take a minute :-)
[08:43] <mup> PR morphis/meta-snappy#10: snapd: update to 2.25 release <Created by morphis> <https://github.com/morphis/meta-snappy/pull/10>
[08:52] <morphis> zyga: thanks!
[08:56]  * zyga switches to coding mode
[09:40] <Chipaca> zyga: ping
[09:46] <zyga> Chipaca: yes?
[09:47] <Chipaca> zyga: were you aware that in one of the tests, what used to be “! grep expr /sys/some/file” worked because /sys/some/file did not exist?
[09:47] <zyga> nope
[09:47] <zyga> Chipaca: are you uncovering a can of worms just now?
[09:47] <Chipaca> zyga: /sys/fs/cgroup/devices/snap.test-snapd-tools.env/devices.list in particular
[09:48] <Chipaca> zyga: should I change the test to check for nonexistance directly, or is it conceivable that the file could sometimes exist, depending on test ordering?
[09:48] <zyga> Chipaca: I don't know, let me look at the test quickly
[09:49] <Chipaca> zyga: main/security-device-cgroups/
[09:49] <Chipaca> I think the file is removed by the cleanup, but I don't know if that is mandatory or incidental
[09:50] <Chipaca> and “if [ -e /sys/yadda ]; then MATCH -v expr /sys/yadda; fi” DTRT AFAIK
[09:50] <zyga> Chipaca: that's cgroup, not a real file
[09:50] <zyga> Chipaca: and I don't know how it behaves very well honestly
[09:50]  * zyga looks
[09:50] <Chipaca> sure looks like a file to sh :-)
[09:50] <Chipaca> zyga: meh, then i'll leave the if [ -e
[09:50] <zyga> sure, my point is that cleanup that removes it is whereR?
[09:51] <zyga> I actually didn't read the cgroup code much
[09:51]  * zyga looks
[09:51] <Chipaca> zyga: in the same yaml
[09:51] <Chipaca> udevadm --potato
[09:53] <zyga> udev-support nees some refactoring love
[09:53] <zyga> we spawn a shell for each device /o\
[09:54] <zyga> Chipaca: so this looks like a layered can of worms, can you please add a FIXME there and I will get back to it
[09:54] <zyga> this code has not changed at all since ubuntu-app-launcher
[09:54] <zyga> and that particular test was written by jdstrand
[09:54] <Chipaca> zyga:     # FIXME: this is, apparently, a layered can of worms. Zyga says he needs to fix it.
[09:55] <Chipaca> zyga: (or tell me what to put so you remember)
[09:55] <zyga> so I need to look at it for some time before I can make heads or tails
[09:55] <zyga> Chipaca: yes, that's fine :)
[10:08] <morphis> ogra_: what is the state on https://bugs.launchpad.net/snappy/+bug/1650688 ?
[10:08] <mup> Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688>
[10:10] <ogra_> morphis, well, i'm not sure mvo's suggestion will work (symlinking a bind-mount) ...
[10:11] <zyga> ogra_: symlinking a bind mount?
[10:11] <morphis> ogra_: just wondering as it was set to be fixed for 2.25 and we now released 2.26 and it is still not fixed and two customers are already asking for it
[10:11] <ogra_> morphis, i guess what could work is to patch systemd to not handle it as link at all and write the data into it ...
[10:12] <ogra_> zyga, https://bugs.launchpad.net/snappy/+bug/1650688/comments/25
[10:12] <mup> Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688>
[10:12] <morphis> ogra_: so what prevents us from patching systemd?
[10:13] <ogra_> having to carry that patch ...
[10:13] <ogra_> we're just at the point where we can drop systemd from the PPA
[10:13] <morphis> something we could sent upstream?
[10:13] <ogra_> (having it there caused quite some probs regarding libusb (there is a fixed version dependency)
[10:14] <morphis> ogra_: yeah, ran into that problem multiple times
[10:14] <ogra_> morphis, right, it must either be upstreamable or at least suitable for a distro patch we can hand to foundations
[10:15] <morphis> ogra_: argument for distro patch would be already that Ubuntu Core is a first class citizen in our ecosystem, isn't it?
[10:15] <ogra_> yes, but it must still be suitable :)
[10:15] <morphis> sure, so what is the plan, get it fixed for 2.27?
[10:15] <ogra_> we can work towards that, yeah
[10:16] <morphis> just saying, we should fix it by 2.27, this is now delayed for two releases ..
[10:16] <ogra_> right
[10:26] <Chipaca> so, there's an important difference between "grep foo | wc -l" and "grep -c foo"
[10:28] <ogra_> morphis, mvo .... oooh ... http://paste.ubuntu.com/24559979/ we already carry a patch, i guess we just need to adjust it
[10:34] <mup> PR snapd#3309 opened: interfaces/mount: keep track of kept mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3309>
[10:34] <mup> PR snapd#3310 opened: interfaces/mount: spell unmount correctly <Created by zyga> <https://github.com/snapcore/snapd/pull/3310>
[10:39] <Chipaca> ogra_: “Forwarded: OMGno, this is a rather nasty hack until we fix system-image to get a writable /etc”
[10:39]  * Chipaca giggles
[10:39] <ogra_> Chipaca, well :)
[10:39] <ogra_> the point is that we have a patch and it doesnt seem to work ....
[10:39] <mup> PR core#39 closed: add version-script <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/core/pull/39>
[10:40] <zyga> mvo: I just merged the version script, cannot wait to see this in snap list!
[10:40] <ogra_> and i think the reason is:
[10:40] <ogra_> 96         if (r >= 0 && startswith(realfile, "/etc/writable")) {
[10:40] <ogra_> because ...
[10:41] <ogra_> ogra@pi3:~$ ls -l /etc/localtime
[10:41] <ogra_> lrwxrwxrwx 1 root root 18 May 12 04:20 /etc/localtime -> writable/localtime
[10:41] <ogra_> it looks for an absolute name
[10:44] <Chipaca> ogra_: what package is that patch for btw?
[10:44] <ogra_> systemd
[10:45] <Chipaca> ah
[10:48] <Chipaca> ogra_: note that the filename is passed through readlink_and_make_absolute first
[10:48]  * Chipaca looks at how that one works
[10:48] <ogra_> yes, i''m just digging into that ... it calls readlinkat() in the end
[10:50] <Chipaca> ogra_: maybe it should be changed to readlink_and_canonicalize?
[10:51] <ogra_> because that calls chase_symlinks() ?
[10:52] <ogra_> i have the feeling just making the link itself absolute would be sufficient
[10:53] <ogra_> funnily the subsequent link *is* absolute
[10:53] <ogra_> ogra@pi3:~$ ls -l /etc/writable/localtime
[10:53] <ogra_> lrwxrwxrwx 1 root root 27 May 11 06:35 /etc/writable/localtime -> /usr/share/zoneinfo/Etc/UTC
[10:54] <Chipaca> ah, fair enough
[10:55] <ogra_> https://github.com/snapcore/core/blob/master/live-build/hooks/08-etc-writable.chroot#L14
[11:00] <mup> PR core#40 opened: make links to /etc/writable absolute <Created by ogra1> <https://github.com/snapcore/core/pull/40>
[11:00] <ogra_> :)
[11:01]  * zyga requests a review for one-liner https://github.com/snapcore/snapd/pull/3310/files
[11:01] <mup> PR snapd#3310: interfaces/mount: spell unmount correctly <Created by zyga> <https://github.com/snapcore/snapd/pull/3310>
[11:02] <zyga> pstolowski: I think you could review this quickly https://github.com/snapcore/snapd/pull/3309/files
[11:02] <mup> PR snapd#3309: interfaces/mount: keep track of kept mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3309>
[11:02] <mup> PR snapd#3311 opened: difs,interfaces/mount: add support for locking namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3311>
[11:02] <pstolowski> k
[11:02] <zyga> mvo: and this is for you (no C :) https://github.com/snapcore/snapd/pull/3311/files
[11:02] <mup> PR snapd#3311: difs,interfaces/mount: add support for locking namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3311>
[11:06] <pstolowski> i'm not sure what's going on with travis test on my #3282.. seems to be infra issue:
[11:06] <pstolowski> Error preparing linode:ubuntu-core-16-64:tests/regression/ : kill-timeout reached, cannot reconnect to linode:ubuntu-core-16-64 (Spread-15) after reboot: dial tcp 96.126.110.77:22: i/o timeout
[11:06] <mup> PR snapd#3209 closed: interfaces/mount: add partial implementation of Change.Needed <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3209>
[11:06] <zyga> pstolowski: I:m looking too
[11:06] <zyga> just restarted
[11:06] <zyga> ogra_: question about https://github.com/snapcore/core/pull/40 -- why were those relative in the first place?
[11:06] <mup> PR core#40: make links to /etc/writable absolute <Created by ogra1> <https://github.com/snapcore/core/pull/40>
[11:07] <pstolowski> zyga, I restarted it an hour ago.. with smiliar failure again
[11:07] <ogra_> zyga, i have not idea :)
[11:07] <ogra_> zyga, that patch came originally from pitti irc
[11:08] <zyga> ogra_: maybe he remembers, could you ask him?
[11:08] <zyga> ogra_: just in case we're missing something magic
[11:09] <ogra_> zyga,  but i assume because he expectes readlink_and_make_absolute() to read a link and make it absolute :P
[11:09]  * zyga hates expect tests :(
[11:09] <ogra_> *expected
[11:09]  * zyga goes for lunch and small break
[11:10] <ogra_> zyga, i'm just ruling out the potential that it doesnt with this change ...
[11:10] <ogra_> there is no guarantee it fixes anything
[11:10] <ogra_> and it wont do any harm either (nothing else cares if the link is relative or absolute)
[11:30] <zyga> fgimenez:     - linode:ubuntu-16.04-64:tests/main/interfaces-openvswitch failed here: https://travis-ci.org/snapcore/snapd/builds/231504228?utm_source=github_status&utm_medium=notification
[11:30] <zyga> fgimenez: there's no good information there
[11:30] <zyga> fgimenez: do you know if that is a massive package that has lots of IO during installation?
[11:31] <mup> PR core#40 closed: make links to /etc/writable absolute <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core/pull/40>
[11:32] <fgimenez> zyga: i don't think so according to https://travis-ci.org/snapcore/snapd/builds/231504228#L3487 it is just 1820kb
[11:33] <fgimenez> zyga: thanks a lot, i didn't have luck trying to reproduce, will try again
[11:34] <zyga> fgimenez: it's just random, I don't know if the cause is the same
[11:35] <fgimenez> zyga: ok, now with the seed it may be easier to confirm/discard the ordering cause, let's see
[11:35] <zyga> note that it died on timeout so we don't really know what happened :/
[11:50] <zyga> Chipaca: do you know MATCH sometimes works with an argument?
[11:50] <zyga> Chipaca: could it be something as silly as missing -- ?
[11:51] <Chipaca> zyga: stdin handling in that shell might be wonky
[11:51] <Chipaca> zyga: like, if you do a match, the second match finds stdin closed (and so reads the args)
[11:51] <Chipaca> that's an unproven hypothesis right now
[11:51] <Chipaca> but you asked :-)
[11:53] <zyga> thanks
[11:53] <Chipaca> zyga: also, note grep always reads the args
[11:53] <zyga> I think we should grok this, we rely on match too much :)
[11:54] <Chipaca> the problem is that MATCH uses 'cat' to read stdin unconditionally
[11:54] <Chipaca> so if cat is not connected, it hangs
[11:54] <Chipaca> if cat is closed, it doesn't hang
[11:54] <Chipaca> i mean if stdin is closed
[11:54] <Chipaca> because cat returns immediately
[11:55] <Chipaca> zyga: makes sense?
[11:55] <Chipaca> needs testing but makes sense to me :-)
[11:55] <zyga> mhm
[11:55]  * zyga would like to see MATCH in C
[11:55] <Chipaca> wat
[11:55] <Chipaca> no dude
[11:55] <Chipaca> i mean, it can be improved, sure
[11:55] <pstolowski> #3282 failed again, this time on create-key test
[11:56] <Chipaca> and probably should be, but "write it in c" is a whole new class of pain
[11:59] <Chipaca> zyga: my pet peeve with it right now is that sometimes we really need the expressiveness of pcre, but we're stuck with -E
[12:00] <Chipaca> this stdin is just a quirk
[12:00] <Chipaca> (compared to that)
[12:01] <zyga> me nods
[12:01] <Chipaca> heh, somebody kicked off the test suite again
[12:01] <Chipaca> but i'm working through the bugs :-)
[12:02] <Chipaca> (just took me a bit because i didn't have a 32-bit image for local qemu)
[12:02] <zyga> Chipaca: spread.zygoon.pl
[12:02] <zyga> :D
[12:03] <Chipaca> zyga: 1205993472 bytes transferred in 451 seconds (2.55 MiB/s)
[12:04] <Chipaca> my network is lazy today
[12:04] <zyga> lazy as in slow?
[12:04] <zyga> my network is never this fast
[12:05] <Chipaca> yeah, it should be about 4 times that
[12:06] <Chipaca> (on paper i mean; in practice it's usually 2x)
[12:16] <zyga> heh
[12:16] <zyga> so my one character change PR keeps failing
[12:16] <zyga> snap-sign this time
[12:16] <zyga> because expect sucks :/
[12:18] <zyga> what I find surprising is that travis fails way way more often than autopkgtests
[12:18] <zyga> I wonder why that may be
[12:18] <zyga> since the infra is actually dedicated, not shared
[12:19] <zyga> I wonder if I should merge the private-interfaces branch now
[12:19] <zyga> (now == just after release) :)
[12:21] <Chipaca> zyga: which is your one character change PR?
[12:23] <zyga> https://github.com/snapcore/snapd/pull/3310
[12:23] <mup> PR snapd#3310: interfaces/mount: spell unmount correctly <Created by zyga> <https://github.com/snapcore/snapd/pull/3310>
[12:24] <Chipaca> aw, i wanted to see the expect failure
[12:25] <zyga> Chipaca: just killed by timeout
[12:25] <Chipaca> zyga: expect timeout is how expect fails, always
[12:26] <Chipaca> it times out waiting for a match
[12:26] <Chipaca> (well, it can also fail with a syntax error :-) )
[12:27] <Facu> sergiusens_, elopio, reading this https://forum.snapcraft.io/t/in-progress-snapcraft-2-30/347 and wondering if it should mention something about https://bugs.launchpad.net/snapcraft/+bug/1670471 or https://bugs.launchpad.net/snapcraft/+bug/1686162
[12:27] <mup> Bug #1670471: Bad message after failed release <Snapcraft:Fix Committed by facundo> <https://launchpad.net/bugs/1670471>
[12:27] <mup> Bug #1686162: Support "branch"es in Store responses <Snapcraft:Fix Committed by facundo> <https://launchpad.net/bugs/1686162>
[12:27] <jdstrand> zyga, Chipaca: iirc, once a cgroup is setup the dirs and files stay until after a reboot. I recall trying to cleanup but being unable to. aiui, all you can do is reset the cgroup but the files are still there. it's possible there is a way that I didn't find
[12:29] <zyga> jdstrand: interesting, I will look into this after working on namespaces
[12:31] <pedronis> mvo: hi, I updated the forum entry about the repair assertion to match the state of your branch
[12:31] <mvo> pedronis: thank you very much
[12:33] <Chipaca> man, tests/main/interfaces-openvswitch needs to be hacked into shape
[12:33] <Chipaca> it takes _ages_
[12:33] <Chipaca> (to the point that it often times out entirely)
[12:34] <zyga> Chipaca: yep
[12:34] <Chipaca> in _prepare_
[12:34]  * Chipaca looks
[12:36] <mup> PR core#41 opened: limit the version string to 32chars (this is what the store allows) <Created by mvo5> <https://github.com/snapcore/core/pull/41>
[12:38] <zyga> Chipaca: apt-get install
[12:39] <Chipaca> zyga: maybe it's just that the base prepare takes ages
[12:39] <Chipaca> and this will push it over the edge
[12:39] <Chipaca> zyga: because that apt-get got the stuff in 0s
[12:39] <Chipaca> then, sure, it needs to dance the install dance
[12:39] <Chipaca> but, we probably should bump the prepare timeout overall if it's this close
[12:40] <zyga> can we do that for a particular test case?
[12:40] <mvo> pedronis: also thanks a bunch for your review, I will add the missing test now
[12:41] <Chipaca> zyga: yes
[12:41] <Chipaca> niemeyer: is kill-timeout for the whole test, or separately for prepare and execute?
[12:44] <niemeyer> Yo
[12:44] <niemeyer> Chipaca: for each script individually
[12:45] <Chipaca> niemeyer: and prepare and execute are scripts?
[12:45] <Chipaca> niemeyer: hello! good morning :-)
[12:47] <ogra_> mvo, so that rsyslog removal ...
[12:47] <ogra_> mvo, any opinion yet ?
[12:53] <Chipaca> huh, another test that was psasing who-knows-how
[12:53] <zyga> ogra_, mvo: tests broken because of the version script on core snap
[12:53] <zyga> mvo: specifically tests/main/listing
[12:55] <kyleN> hi ara
[12:56] <Chipaca> mvo: fgimenez: question about tests/main/ubuntu-core-create-user
[12:56] <zyga> hmm
[12:56] <zyga> or maybe not?
[12:57] <Chipaca> mvo: fgimenez: the test currently purports to check that the output of create-user on a managed device (without the --force-managed flag) is “error: while creating user: cannot create user "nosuchuser@example.com"”
[12:58] <Chipaca> mvo: fgimenez: but that's not the output from that command (and it hasn't been that for a while)
[12:58] <Chipaca> I don't pretend to understand how this test passed in the past
[12:58] <Chipaca> but i want to know if the current message is what it should be, in which case i will make the test check for that
[12:58] <Chipaca> and if it ins't, i'll fix the message
[12:58] <Chipaca> mvo: fgimenez for the record the message currently is “error: while creating user: cannot create user: device already managed”
[12:59] <MrGeneral> howdy
[13:00] <MrGeneral> Is it possible to run snap @ debian jessie?
[13:00] <zyga> MrGeneral: hello
[13:00] <zyga> ah standup time
[13:00]  * zyga never remembers debian codenames
[13:00] <zyga> testing is OK
[13:00] <MrGeneral> All good.
[13:00] <zyga> before is too old
[13:00] <MrGeneral> hmhm I see
[13:00] <MrGeneral> so I need to enable testing I guess.
[13:00] <MrGeneral> too old?
[13:00] <MrGeneral> hmhm
[13:00] <pedronis> Chipaca: the test is wrong it seems, it should try the wrong user before it sets up a real one
[13:01] <pedronis> Chipaca: I mean it seems to be mixing up failure modes
[13:01] <zyga> MrGeneral: yes, kernel and systemd and perhaps something else
[13:02] <fgimenez> Chipaca: something is indeed wrong there, is a "$" missing https://github.com/snapcore/snapd/blob/master/tests/main/ubuntu-core-create-user/task.yaml#L39 ?
[13:02] <Chipaca> fgimenez: hah!
[13:02] <Chipaca> omg
[13:03] <Chipaca> fgimenez: yes, that is missing a $, but, even that does not fail
[13:03] <Chipaca> fgimenez: it never reaches there
[13:03] <Chipaca> fgimenez: (or if it reaches, it isn't enough to time out)
[13:03] <Chipaca> to error out I mean
[13:05] <mup> PR snapd#3312 opened: DO NOT MERGE YET: add coveralls.io integration <Created by mvo5> <https://github.com/snapcore/snapd/pull/3312>
[13:05] <MrGeneral> Got it, thank you zyga :)
[13:08] <mup> PR snapd#3312 closed: DO NOT MERGE YET: add coveralls.io integration <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3312>
[13:13] <mup> PR snapcraft#1305 closed: Use architectures field which existed in older LXD <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1305>
[13:14] <mup> PR snapd#3313 opened: send things to codecov.io <Created by mvo5> <https://github.com/snapcore/snapd/pull/3313>
[13:16] <mup> PR snapcraft#1249 closed: Add Linux Mint support <Created by nefelim> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1249>
[13:28] <ogra_> morphis, do we have any snap that uses the timedatectl dbus call that i could use to test https://bugs.launchpad.net/snappy/+bug/1650688 ?
[13:28] <mup> Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688>
[13:29] <ogra_> calling it locally will not use dbus but directly call the tool whihc works fine
[13:29] <morphis> ogra_: not really
[13:30] <ogra_> i'm pretty sure the missing line for /etc/localtime in the interface will also have some effect here
[13:31] <mup> PR snapcraft#1306 closed: recording: record global build-packages installed on the host <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1306>
[13:32] <mup> PR snapd#3314 opened: tests: allow 16-X.Y.Z version of core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3314>
[13:33] <mup> PR snapd#3315 opened: rename host's http proxy env vars <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3315>
[13:36] <mup> PR snapd#3316 opened: make /etc/localtime writable in timezone_control <Created by ogra1> <https://github.com/snapcore/snapd/pull/3316>
[13:53] <morphis> ogra_: I got a basic qemu snap going which gives me latest git with raspi2 machine and got the kernel from the pi2-kernel snap booting
[13:53] <morphis> ogra_: however didn't got uboot started yet and because of that the kernel fails to find its rootfs
[13:54] <ogra_> push it to edge .... happy to poke at it
[13:55] <diddledan> what is that error supposed to mean?: [Error 21] Is a directory: '/build_corebird/prime/usr/lib/locale' <-- I told it I wanted 'usr/lib/locale' in the prime section of my yaml
[14:02] <ogra_> jdstrand, i'd appreciate a review of https://github.com/snapcore/snapd/pull/3316
[14:02] <mup> PR snapd#3316: make /etc/localtime writable in timezone_control <Created by ogra1> <https://github.com/snapcore/snapd/pull/3316>
[14:03] <mup> PR core#41 closed: limit the version string to 32chars (this is what the store allows) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/41>
[14:09] <zyga> mvo: can you review https://github.com/snapcore/snapd/pull/3314 to unbreak master
[14:09] <mup> PR snapd#3314: tests: allow 16-X.Y.Z version of core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3314>
[14:24] <pedronis> niemeyer: this is the first issue(s) about auto-connect to address right? https://forum.snapcraft.io/t/what-should-the-auto-connect-logic-be-like/312
[14:26] <zyga> pedronis: one thing that is perhaps related is that I want to add a small tweak to interfaces to give them a way to share more meta-data
[14:27] <zyga> pedronis: we could then share more useful things, like auto-connect 1-no-N flags or anything else we need internally
[14:27] <zyga> pedronis: (and useful things like human readable descriptions we just keep as code comments)
[14:27] <ogra_> niemeyer, in case you feel like reading it https://lists.ubuntu.com/archives/ubuntu-devel/2017-January/039634.html ... (for a boring afternoon or so)
[14:28] <ogra_> niemeyer, thats the discussion about dropping syslog from the distro
[14:28] <niemeyer> ogra_: Can you please mention that in the forum thread? It's good background.
[14:28] <ogra_> yep
[14:28] <niemeyer> pedronis: Yeah
[14:30] <Chipaca> looks like we ran out of travis coin
[14:30] <pedronis> zyga: that's interesting but as niemeyer says on the forum, I think we should start fixing the initial bug before adding stuff
[14:30] <niemeyer> Chipaca?
[14:31] <zyga> pedronis: yes, as I said it's not directly related (my motivation is to get the user visible interface descriptions available in the API) but once we have a hold of the problem and know what to do it may be a handy mechanism
[14:31] <pedronis> at the moment all auto-connecting interfaces are 1-to-N afaik
[14:32] <pedronis> I mean from slot (1) to plugs (N)
[14:33] <mup> PR snapd#3317 opened: many: start implenting "base" snap type on the snapd side <Created by mvo5> <https://github.com/snapcore/snapd/pull/3317>
[14:34] <zyga> pedronis: perhaps
[14:35] <zyga> pedronis: things like gpio and other hardware might not be
[14:35] <zyga> (it may be but might not be)
[14:38] <zyga> we need to land https://github.com/snapcore/snapd/pull/3314 to fix master
[14:38] <mup> PR snapd#3314: tests: allow 16-X.Y.Z version of core snap <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/3314>
[14:38] <zyga> please review
[14:42]  * zyga just lands it
[14:43] <mup> PR snapd#3314 closed: tests: allow 16-X.Y.Z version of core snap <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3314>
[14:48] <ogra_> niemeyer, hmm, is there a way that a non-creator of a topic could set a category in discourse (perhaps via a config option) ...
[14:49] <ogra_> niemeyer, i.e. https://forum.snapcraft.io/t/3g-usb-modems-compatible-with-modem-manager-snap-on-ubuntu-core/582 would fit into "device" but the original creator didnt set it ... would be a cool feature if others could add a category in that case
[14:49] <pedronis> ogra_: let me see
[14:49] <mvo> zyga: nice one, thank you
[14:49] <pedronis> ogra_: done
[14:50] <pedronis> ogra_: I can change categories, it's one of those things discourse grants after some use afaict
[14:50] <ogra_> pedronis, oh
[14:50] <pedronis> part of one of the badges
[14:51]  * ogra_ thought he did earn enough badges yet ... seems not :P
[14:51] <pedronis> ogra_: I got it with "Regular"
[14:51] <pedronis> you should have it too
[14:51] <pedronis> afaict
[14:51] <pedronis> https://forum.snapcraft.io/badges/3/regular
[14:52] <zyga> mvo: OK to land https://github.com/snapcore/snapd/pull/3295 ?
[14:52] <mup> PR snapd#3295: interfaces/builtin: make all interfaces private <Created by zyga> <https://github.com/snapcore/snapd/pull/3295>
[14:52] <pedronis> ogra_:  "You can now recategorize and rename topics..."
[14:52] <niemeyer> ogra_: Yeah, moderators can do it
[14:53] <pedronis> niemeyer: also Regulars
[14:53] <niemeyer> pedronis: Ah, indeed!
[14:53] <niemeyer> discourse++
[14:53] <pedronis> ogra_: click the pencil on the right of topic titles
[14:53] <ogra_> oh man
[14:53] <ogra_> yeah, i can
[14:53] <diddledan> how do I get snapcraft to prime a directory? it's complaining that: [Error 21] Is a directory: 'path I want included'
[14:53] <ogra_> it didnt strike me that i need to edit the headline for it
[14:54] <pedronis> you should click all that is shiny :)
[14:54] <morphis> ogra_: can we change https://bugs.launchpad.net/snappy/+bug/1650688 to be in-progress?
[14:54] <mup> Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688>
[14:54] <ogra_> diddledan, catching the snapcraft guys might be easier on rocket.ubuntu.com
[14:54] <ogra_> morphis, done
[14:55] <morphis> ogra_: thanks
[14:55] <morphis> niemeyer: you have time to have another look on https://github.com/snapcore/snapd/pull/3222 today?
[14:55] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[14:55] <diddledan> really? why have they moved over therE?!
[14:55] <niemeyer> morphis: Yeah
[14:56] <diddledan> I hate this replacing with shiny just because
[14:56] <pedronis> morphis: the icon here seems broken (or a cache issue?):  https://forum.snapcraft.io/badges/101/fedora
[14:56] <morphis> niemeyer: thanks!
[14:56] <diddledan> there wasn't anything wrong with IRC! </rant>
[14:56] <morphis> pedronis: hm, didn't created that badge so not sure where it takes the icon from
[14:56] <morphis> niemeyer: ^^
[14:56] <morphis> pedronis: https://snapforum.s3.amazonaws.com/original/1X/bfb1e013ef4b1f1276a1ca3d38a40a789a056bb8.png -> doesn't exist ..
[14:57] <niemeyer> Wow.. strange
[14:57] <niemeyer> Let me check that
[14:57] <ogra_> diddledan, nobody says there is anything wrong with it (and they are still idling here but probably dont check it as often as rocket)
[15:02] <niemeyer> Apparently I screwed up by removing a reference to the image, and Discourse is smarter than I expected and removed the image that had no references
[15:07] <niemeyer> morphis: Fixed, thanks for the note
[15:08] <niemeyer> pedronis: ^
[15:08] <pedronis> thx
[15:08] <pedronis> I just noticed because I went to the badges page
[15:18]  * niemeyer => lunch
[15:24] <pedronis> niemeyer: we should remember to remove upcoming from stuff that is done (I think you listed that in the process post)
[15:31] <pedronis> mvo: Chipaca: is this resolved  https://forum.snapcraft.io/t/hashsum-failures-during-tests/198 ?
[15:32] <Chipaca> I don't think so
[15:37] <pedronis> niemeyer: mvo: I removed the "upcoming" tag from some stuff that was done
[15:47] <morphis> pedronis: are you planing to solve and implement https://forum.snapcraft.io/t/gadget-snap-config-defaults-dont-work/409/4  for 2.27?
[15:48] <pedronis> morphis: yes (https://forum.snapcraft.io/t/next-snapd-2-27/572 )
[15:48] <pedronis> morphis: have a plan, should have PR(s) on Mon or Tue
[15:48] <morphis> pedronis: awesome!
[16:19] <pstolowski> pedronis, do you know from top of your head where do we create 'update-aliases' task? for some reason I can only find it in tests... but not where it's created
[16:20] <niemeyer> pedronis: +1
[16:20] <niemeyer> pedronis: Thanks for cleaning it up
[16:26] <pstolowski> 2017-05-12 15:40:57 Failed tasks: 1
[16:26] <pstolowski>     - linode:ubuntu-16.04-32:tests/main/create-key
[16:26] <pstolowski> 2017-05-12 15:40:57 Failed task prepare: 1
[16:26] <pstolowski>     - linode:ubuntu-16.04-32:tests/main/completion
[16:26] <pstolowski> #3282 failed again ^ ...
[16:38] <pedronis> pstolowski: there is no such task
[16:38] <pedronis> pstolowski: aliasesv2.go has a comment listing all the aliases tasks
[16:39] <pedronis> pstolowski: why the question?
[16:40] <pedronis> pstolowski: ah, update-aliases, it's a backend operation, not a task
[16:40] <pstolowski> pedronis, cause I unexpectedly get this in of the my failing tests; and grepping master gives a bunch of those..
[16:40] <pedronis> lots of aliases tasks end up creating those
[16:41] <pedronis> pstolowski: I fear I need to see the test to help
[16:42] <pedronis> pstolowski: anyway under normal circucmstances (refresh/install etc) it comes from setup-aliases
[16:42] <pstolowski> pedronis, i see. thanks
[16:43] <pedronis> also I misremembered the comment listing tasks is in handlers.go
[16:46] <mup> PR snapcraft#1313 opened: Meta: Version from deb <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1313>
[16:59] <zyga> 2017-05-12 16:53:57 Cannot allocate linode:ubuntu-16.04-64: cannot create Linode disk with ubuntu-16.04-64: you do not have enough unallocated storage to create this Disk (608 requested, but only 0 available)
[18:28] <niemeyer> Fixed.. that was Spread-06 FWIW
[18:28] <niemeyer> All others are clean
[18:47] <mup> PR snapd#3295 closed: interfaces/builtin: make all interfaces private <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3295>
[18:47] <mup> PR snapd#3310 closed: interfaces/mount: spell unmount correctly <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3310>
[21:43] <mup> PR snapcraft#1314 opened: catkin plugin: add support for rosinstall files <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1314>
[22:44] <nacc> sigh, i think i've found a relatively serious issue with the store, on a friday :)
[22:44] <nacc> oh nm, it's a bug in my snapcraft.yaml in the process of renaming a snap
[22:44] <nacc> it does feel like the store should not try to cross-build/upload snaps: https://launchpad.net/~nacc/+snap/git-ubuntu/+build/37953
[22:45] <nacc> snap is git-ubuntu, but the generated snap is usd-nacc, and yet it tried to upload it :)
[22:53] <nacc> hrm, but it does seem like lp is a bit confused: https://launchpad.net/~nacc/+snap/git-ubuntu/+build/37953
[22:54] <nacc> the 'manage this package in the store' url ends up pointing to the wrong snap (the one built, admittedly)