[06:16] <mborzecki> morning
[06:49] <mup> PR snapd#6450 closed: release: 2.37.1 <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6450>
[07:21] <mborzecki> arch packages update
[07:21] <mborzecki> d
[07:37] <ackk> hi, is it expected that $SNAP_DATA and $SNAP_COMMON on parallel installs point at the same dirs on all installs?
[07:41] <zyga> Hello
[07:42] <zyga> ackk: yes, check out the data though
[07:42] <zyga> It is all good :-)
[07:42] <zyga> mborzecki: thank you
[07:43] <mborzecki> ackk: yes, inside the mount namespace those appear as the same paths, but outside each instance has its own dir
[07:43] <mborzecki> zyga: hey
[07:44] <ackk> oh, I see
[07:44] <mborzecki> ackk: however, this is not the case for $SNAP_USER_DATA, $SNAP_USER_COMMON and $XDG_RUNTIME_DIR
[07:45] <mborzecki> ackk: https://forum.snapcraft.io/t/parallel-installs/7679 has some info about the paths and lists some limitations of the current implementation
[07:47] <ackk> mborzecki, but why are SNAP_DATA and SNAP_COMMON paths not instance-based as for the USER ones?
[07:47] <zyga> ackk: just technical limitation
[07:48] <zyga> We should be able to handle that eventually
[07:48] <zyga> 2.39
[07:48] <zyga> Perhaps
[07:48] <mborzecki> ackk: they are, each instance has a separate directory, but insdie a snap we bind mount the instance specific dir on top of the non instance one to make it easier to use
[07:50] <mborzecki> ackk: for instance, snap foo_123 has /var/snap/foo_123/common and /var/snap/foo_123/current, inside the filesystem view of the snap, /var/snap/foo_123/common is also avaialble as /var/snap/foo/comon, but that's stil the same directory
[07:51] <mborzecki> ackk: not sure i explained that well enough :)
[07:52] <ackk> mborzecki, yeah thanks I understand
[07:56] <ackk> mborzecki, ok, the issue I was trying to track down seems to be this: if you have a "foo" snap with a config hook and you snap install foo_2, the hook is not found
[08:06] <mborzecki> ackk: ok, let me look into this, maybe there's a bug after all
[08:06] <ackk> mborzecki, thanks
[08:09] <pstolowski> morning
[08:09] <mborzecki> pstolowski: hey
[08:10] <mvo> mborzecki: thanks for the arch update
[08:10] <mvo> zyga: fwiw, the failure in the last from last night was a fluke
[08:10] <mvo> zyga: I re-run the entire suite
[08:10] <mvo> zyga: and no errors, so yay
[08:11] <zyga> Good morning pawel, michael
[08:11] <zyga> Good news
[08:11] <mvo> zyga: and good morning
[08:14] <zyga> I will be around soon. Feeling a little under the weather today
[08:43] <zyga> at my keyboard
[08:47] <mup> PR snapd#6451 opened: tests: update smoke/sandbox test for armhf <Created by mvo5> <https://github.com/snapcore/snapd/pull/6451>
[08:48] <mborzecki> ackk: i tried my demo snap and it seems the hooks are called as expected
[08:48] <mborzecki> ackk: in your case, do you need foo to be installed before foo_2 is installed?
[08:49] <ackk> mborzecki, that's the case that doesn't work, when you just snap install foo_2 and don't have foo installed
[08:49] <mvo> pstolowski: hey, good morning! if you have some cycles and a dragonboard or a pi3 running some of the beta validation would be great, then we can parallelize  as much as possible
[08:49] <mvo> zyga: or do you happen do have a dragonboard?
[08:49] <zyga> mvo: I do :)
[08:49] <mborzecki> ackk: can you use this demo snap https://github.com/bboozzoo/parallel-installs-demo ? snap pack and install --dangerous .. --name parallel-installs-demo_foo
[08:50] <mborzecki> ackk: the configure hooks drops a log in $SNAP_COMMON, so there should be /var/snap/parallel-installs-demo_foo/common/run.log file once it's installed
[08:51] <pstolowski> mvo: sure, happy to help, i've pi3, shall i run specific tests on it?
[08:51] <ackk> mborzecki, yeah that works but IDK why my snap doesn't then
[08:51] <ackk> mborzecki, "snap install --edge h2static_2"
[08:52] <ackk> mborzecki, then set listen=:8080
[08:52] <ackk> (or any port)
[08:52] <mborzecki> ackk: ok, trying
[08:52] <zyga> pstolowski, mvo: for the benefit of everyone let's discuss the testing process here
[08:52] <zyga> my memory of how it goes is rusty
[08:53] <pstolowski> zyga: yeah, i've never done this before, not familiar with the process at all
[08:53] <mvo> zyga: its all in the mail from sergio
[08:53] <zyga> https://github.com/snapcore/snapd/blob/master/tests/external-backend.md
[08:53] <mvo> zyga: his examples are really good
[08:53] <zyga> oh, let me look
[08:54] <mvo> zyga, pstolowski https://github.com/sergiocazzolato/snappy-qa-jobs
[08:54] <zyga> https://github.com/sergiocazzolato/snappy-qa-jobs
[08:54] <zyga> right :)
[08:54] <mvo> zyga: heh
[08:54] <zyga> mvo: I think we really want to help sergio merge the code to master
[08:54] <mvo> pstolowski: yeah, sorry for this. special circumstances because sergio is on vac and we need to deal with this regrssion :/
[08:54] <zyga> or at least link to it from master
[08:55] <mvo> zyga: yeah, I think we need to look into brining this into our tree
[08:57] <pstolowski> mvo: don't mention it, happy to help, we really need to spread knowledge and workloads more
[08:57] <mvo> pstolowski: yeah, it also makes me appreciate sergios work more (I always did of course) but its nice to see how much this is automated
[08:58] <mvo> pstolowski, zyga I added you to the card and there is a list of things to do, if you take one, just add *name* in the checlist and once its done a pastebin link (those are generated automatically)
[08:59] <mborzecki> ackk: can you add https://github.com/bboozzoo/parallel-installs-demo/blob/master/meta/snap.yaml#L10-L11 to your snap.yaml?
[08:59] <mborzecki> pstolowski: do you know if configure hooks are automatically discovered?
[09:00] <ackk> mborzecki, oh wait, I thought I had that, lemme try
[09:02] <pstolowski> mborzecki: yes they are
[09:04] <ackk> mborzecki, ah, that works
[09:04] <ackk> mborzecki, thanks
[09:13] <sparkiegeek> ackk: did you figure out your 'hooks aren't running on parallel installs' issue?
[09:14] <ackk> sparkiegeek, yeah, see above. I was missing the hook: section in the snapcraft.yaml
[09:14] <sparkiegeek> ackk: ah, so PEBKAC
[09:14] <ackk> sparkiegeek, well, afaiu it's only mandatory if you need to set plugs. the hook is called on the "normal" install
[09:15] <pedronis> pstolowski: mborzecki: hook should be outdiscovered,  does autodiscovery gets confused if there's a instance name?
[09:15] <mborzecki> sparkiegeek: might be a bug too looking into it, for now declaring it explicitly works
[09:15] <Chipaca> mo'in
[09:15] <pedronis> Chipaca: hello
[09:15] <sparkiegeek> Chipaca: moin moin
[09:15] <mborzecki> pedronis: trying to find that out
[09:19] <Chipaca> pedronis: question about lanes: why do tasks have a list of lanes? when would a task be on more than 1?
[09:21] <pstolowski> mvo: clarification needed - if i'm going to test fresh core18 install on pi3, after flashing the image i do the initial consoleconf setup manually right? the test scripts doesn't automate this?
[09:21] <mvo> pstolowski: correct
[09:21] <pstolowski> mvo: good, thanks
[09:24] <mvo> pstolowski: if you notice anything where the docs should be clearer feel free to make notes and pass to sergio
[09:25] <pedronis> Chipaca: afaik we haven't used that feature so far (putting a task in more than one lane)
[09:25] <pstolowski> mborzecki: fwtw we rely on auto-discovered configure in many of our test snaps in spread
[09:25] <Chipaca> popey: Wimpress: where was that "how to make your snap more shiny" tutorial with stats and such?
[09:26] <Chipaca> pedronis: what would it do if we did? :-)
[09:26] <pedronis> Chipaca: something complicate if you abort
[09:26] <pedronis> we have logic for it (complicated)
[09:27] <pedronis> Chipaca: tbh, at this point I would be ok for us to error if we try to do that (add a task to more than one lane)
[09:28] <Chipaca> ok, I'll not worry about it for now then
[09:28] <popey> Chipaca: https://snapcraft.io/blog/make-your-snap-store-page-pop
[09:28] <Chipaca> pedronis: can we talk in malta about using a database for state?
[09:28] <Chipaca> popey: thanks!
[09:29] <mborzecki> pstolowski: pedronis: looks like there is a bug
[09:29] <pedronis> Chipaca: we can talk about it
[09:29] <mup> PR core18#116 opened: Support arm64 with efi bootloader <Created by woodrow-shen> <https://github.com/snapcore/core18/pull/116>
[09:29] <pedronis> Chipaca: do we have an obvious candidate for it tough?
[09:30] <mborzecki> pstolowski: pedronis: https://github.com/snapcore/snapd/blob/master/snap/info.go#L1011-L1019
[09:31] <pedronis> mborzecki: I suppose the bug is inside those functions
[09:31] <pedronis> ah we set instance key
[09:31] <pedronis> late
[09:31] <pedronis> funny us
[09:31] <mborzecki> yeah
[09:31] <pedronis> mborzecki: anyway need a test
[09:31] <mborzecki> mhm
[09:32] <pedronis> mborzecki: ?
[09:32] <mborzecki> pedronis: just confirming that's the bug, and we do need a test
[09:36] <pstolowski> grr github acting up on me, can't see that diff
[09:37] <pstolowski> mborzecki: do we have any tests for hooks and instances?
[09:43] <mborzecki> pstolowski: no, i don't think there's a spread test specifically targeting hooks with parallel instances
[09:44] <mborzecki> so declaring the hooks explicit works, but autodiscovery does not
[09:45] <zyga> mborzecki, pedronis: patch for 2.37.2 :) ?
[09:45] <mborzecki> zyga: likely
[09:45] <mborzecki> are we doing .2 already? :P
[09:45] <Chipaca> the tests run so much faster with 1.10
[09:47] <zyga> mborzecki: inevitably
[09:49] <mborzecki> Chipaca: especially the ones are cache and don't run
[09:49] <mup> PR snapd#6452 opened: overlord/snapstate: format the refresh time for the log <Simple 😃> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6452>
[09:50] <Chipaca> mborzecki: travis's "short" unit run went from ~9m to ~5m
[09:50] <Chipaca> locally it seems to be even faster
[09:50] <mborzecki> Chipaca: oh, those aren't cached for sure
[09:50] <Chipaca> ^^^ a very very trivial PR (honest)
[09:54] <mborzecki> ehh merge conflict in #6415
[09:54] <mup> PR #6415: snapstate, snap: allow update/switch requests with risk only channel to DTRT <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6415>
[09:55] <Chipaca> mborzecki: yeah
[10:03] <ogra> pedronis, mvo, is there any coordination between the cloud-init people and the core team going on ... the cloud-init documentation regarding core seems to be quite a mess (see: https://forum.snapcraft.io/t/ubuntu-core-18-rpi-3-not-seeded/9728/9 )
[10:04] <pedronis> ogra: not really so far
[10:05] <ogra> yeahm thats what i thought
[10:08] <sparkiegeek> blackboxsw: ^
[10:11] <Chipaca> pedronis: wrt re-refresh, it's to be done on all snaps that were requested in the original update, not on all snaps that were updated, right?
[10:12] <Chipaca> ie if the user said "snap refresh a b c d", re-refresh checks those 4 even if just c had an update?
[10:12] <pedronis> Chipaca: should we write it down somehwere
[10:12] <Chipaca> pedronis: I'll add a comment :-)
[10:12] <pedronis> we are reshaing the same thing again and again
[10:12] <Chipaca> pedronis: last time it was just-those-that-had-epoch-bump vs "all"
[10:12] <Chipaca> now i'm clarifying what "all" meant
[10:12] <pedronis> Chipaca: we need to ask about snaps that have had a successful refresh, of these we should refresh the ones that have a new epoch change lined up
[10:13] <pedronis> *ask the store
[10:13] <Chipaca> pedronis: yes, and for that I check the lanes
[10:13] <Chipaca> pedronis: but in the task description, I wanted to say what the re-refresh was _for_
[10:14] <Chipaca> I guess just the ones that get updated is the better superset
[10:15] <pedronis> Chipaca: yes, but that's also the set we put in the original summary, no?
[10:16] <pedronis> I don't think the summary has a b c d
[10:16] <pedronis> if only c got an update
[10:16] <pedronis> (but maybe I'm misremembering)
[10:17] <Chipaca> pedronis: the change summary yes, we set that in daemon
[10:17] <Chipaca> the task summary no
[10:17] <Chipaca> (there's no other task that's whole-update like rerefresh is)
[10:18] <Chipaca> (afaik)
[10:18] <pedronis> but we have the info
[10:18] <zyga> mvo: should we upload 2.37.1-1 to disco?
[10:18] <pedronis> Chipaca: we are problably discussing a detail that doesn't merit discussing here, it should be clear enough in the code, np?
[10:19] <Chipaca> pedronis: i think so
[10:21] <pstolowski> mvo: my validation tests seem to be stuck on failover:emptysystemd
[10:22] <mvo> pstolowski: hm, ok might be worthwhile to investigate
[10:23] <mvo> pstolowski: I saw some fluke failures in different tests, especially in core18 I think we need to look at those too, looks like the suite is not quite as robust on core18 yet
[10:26] <pstolowski> nooo... /usr/bin/pastebinit
[10:26] <pstolowski> Uploding execution log to paste.ubuntu.com
[10:26] <pstolowski> Failed to contact the server: [Errno socket error] The write operation timed out
[10:27] <pstolowski> mvo: is it ok to re-run the tests over same image, or should i reflash?
[10:28] <mvo> pstolowski: worth a try to re-run but my experience is that it might be broken from some invalid restore etc
[10:29] <mvo> pstolowski: via the docs in tests/external-devices.md you can also re-run individual tests
[10:30] <pstolowski> mvo: ack, thanks
[10:41] <Chipaca> hmm
[10:41] <Chipaca> 2019/01/30 10:40:32.282838 taskrunner.go:420: DEBUG: Running task 293320 on Do: Make snap "core" (6259) available to the system
[10:41] <Chipaca> 2019/01/30 10:40:32.321291 link.go:75: cannot update fontconfig cache: cannot get fc-cache-v6 from core: open /snap/core/current/bin/fc-cache-v6: no such file or directory
[10:41] <Chipaca> suspect something there is not waiting for the mount
[10:46] <pedronis> Chipaca: we had a fix for that I tought
[10:47] <Chipaca> ah, maybe we do (i'm switching channels a lot)
[10:48] <pedronis> Chipaca: https://github.com/snapcore/snapd/pull/6317
[10:48] <mup> PR #6317: overlord/snapstate/backend: call fontconfig helpers from the new 'current' <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6317>
[10:57] <pstolowski> pedronis: i've cleaned up https://github.com/snapcore/snapd/pull/5962 and unblocked it. diff is ~1100 lines, but 700 lines are new tests.
[10:57] <mup> PR #5962: ifacestate/hotplug: hotplug handlers <Complex> <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5962>
[10:58] <pstolowski> mvo: pastebin step of the validation tests always fails for me :/
[11:00] <mvo> pstolowski: even if you have pastebinit installed? strange it works pretty reliable for me (18.04 and 18.10)
[11:01] <mvo> the Pi test just takes forever :/
[11:01] <pedronis> pstolowski: ok, thanks, will try to get to it this week still
[11:02] <pedronis> pstolowski: does it include the bits about avoiding to recreate slots already in the gadget, or is that separate?
[11:03] <pstolowski> pedronis: yes it does
[11:05] <pstolowski> mvo: yes, i can use pastebinit manually just fine
[11:10] <pedronis> pstolowski: did you find out if we have problem with the implicit slots logic as it relates to hotplug?
[11:10] <pedronis> or it will just work
[11:11] <pstolowski> pedronis: should just work; it remains a bit messy and brittle though
[11:12] <pedronis> ok, thanks
[11:19]  * Chipaca takes a break
[11:58] <mborzecki> heh, hookstate tests are missing some cleanup, added new test there and the previous ones get stuck :/
[12:51] <mup> PR snapd#6453 opened: snap: fix hook autodiscovery for parallel installed snaps <Parallel installs ⛓> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6453>
[12:51] <mborzecki> pedronis: pstolowski: fix for autodiscovery of hooks ^^
[13:00] <pstolowski> ty
[13:02] <zyga> mvo: hey
[13:02] <zyga> sorry for the slow update
[13:03] <zyga> I'm having issues setting up the dragon board
[13:03] <zyga> it gets the ip address but console-conf is unhappy
[13:07] <jdstrand> mvo: hey, fyi, test-snapd-dbus-consumer and test-snapd-dbus-provider have a bunch of 'Store upload failed for...' messages that for some reason the security team is getting emails for, but I don't see where we own those. did the macaroon expire?
[13:07] <pedronis> jdstrand: yes, macaroon expiry is the likely cause
[13:32] <mvo> jdstrand: oh, stange - sould you forward me one of those?
[13:32] <mvo> jdstrand: why the security team of all people :)
[13:36] <zyga> mvo: I think the dragonboard image doesn't work
[13:36] <mvo> zyga: uh
[13:36] <zyga> mvo: it boots, I can associate with ap's
[13:36] <zyga> mvo: but I cannot leave console conf
[13:36] <zyga> mvo: some kernel error flies on the screen briefly during setup
[13:36] <mvo> zyga: uc16 or uc18 or both?
[13:36] <zyga> mvo: and then the message from console-conf is "Network configuration timed out; please verify your settings"
[13:37] <zyga> uc16
[13:37] <zyga> I've been trying to use different AP's move the device around etc
[13:37] <zyga> mvo: note that it does connect, it gets an IP address
[13:37] <zyga> but that's that
[13:37] <zyga> the error that flashes is "] wcn36xx: ERROR hal_remove_b6"
[13:38] <mvo> zyga: hm, hm, bad. I can't comment, I don't know enough about the DB, I think sergio mentioned we can run some tests via testflinger, I have a look at this now
[13:38] <zyga> mvo: I can make a uc18 image next
[13:39] <zyga> I may also have a usb-ethernet adapter at home somewhere
[13:39] <zyga> but I think that's not sufficient to say "this is good"
[13:39] <zyga> I doubt it's our fault (3.37 -> 3.37.1)
[13:39] <zyga> so I would not block on that
[13:40] <mvo> zyga: yeah, lets see if testflinger is more happy
[13:43] <cwayne> plars: ^ fyi
[13:46] <zyga> booting uc18 now
[13:46] <zyga> random thing from logs: FAT: Misaligned buffer address (00000000bd0f48f0)
[13:46] <zyga> ubuntu-image issue?
[13:47] <zyga> mvo: uc18 feels less happy
[13:48] <zyga> ah
[13:48] <zyga> no, just veeeery slow :)
[13:49] <zyga> mvo: uc18 works
[13:53] <jdstrand_> mvo: ok, I bounced them to you
[13:53] <mvo> zyga: probably slow because of entropy
[13:53] <mvo> jdstrand_: ta
[13:53] <mvo> zyga: running testflinger now, fingers crossed
[13:54] <cwayne> mvo: is this with a fresh image created with the core in beta?
[13:54] <mvo> cwayne: I hope so, this is done via a script from sergio, I have not looked at the inner workings yet
[13:55] <mvo> cwayne: it says "2019-01-30 13:52:47,210 dragonboard_002 INFO: DEVICE AGENT: Flashing Test Image
[13:55] <mvo> "
[13:55] <cwayne> ok, just checking as we've done the core beta snap tests and dragonboard was a-ok
[13:55] <mvo> cwayne: aha, so my test is redundant?
[13:55] <cwayne> mvo: not if its a new image
[13:55] <cwayne> we just snap refresh
[13:55] <mvo> cwayne: its the beta 2.37.1
[13:55] <mvo> cwayne: aha, I see
[13:55] <mvo> cwayne: I will check, I am not sure which method is used
[13:55] <cwayne> IIRC this test is creating an image with ubuntu-image, which i guess is technically different
[13:55] <mvo> cwayne: indeed, I double check
[13:55] <zyga> mvo: question about sergio's scripts, <BRACH> is the snapd branch?release/2.37?
[13:56] <mvo> zyga: he has examples
[13:56] <zyga> I'm jumping through the maze of includes
[13:56] <mvo> zyga: but its more like a TAG
[13:56] <mvo> zyga: yeah, the layout is a bit unconventional :)
[13:56] <zyga> k
[13:56] <zyga> thanks
[13:56] <mvo> zyga: I had very good results just following the examples
[13:57] <zyga> it's running now ... let's see
[14:04] <zyga> core doesn't like motd: /etc/update-motd.d/50-motd-news: 59: /etc/update-motd.d/50-motd-news: cannot create /var/cache/motd-news: Read-only file system
[14:08] <mvo> zyga: hm, we killed motd on core I thought
[14:08] <zyga> not that hard apparently
[14:08] <zyga> where should the bugs go?
[14:09] <zyga> we still have /etc/update-motd.d/50-motd-news
[14:09] <zyga> we actually have more
[14:09] <zyga> -rwxr-xr-x 1 root root 1220 Apr  9  2018 00-header
[14:09] <zyga> -rwxr-xr-x 1 root root 4264 Aug 19 23:44 50-motd-news
[14:09] <zyga> -rwxr-xr-x 1 root root  348 Jan 30 05:01 60-unminimize
[14:09] <mvo> zyga: meh, I think we need to kill that
[14:09] <zyga> it's in /etc, I hope that's not another writable-dirs hell
[14:20] <zyga> 2019-01-30 15:19:34 WARNING: external:ubuntu-core-16-arm-64 (external:ubuntu-core-16-arm-64:tests/main/failover:rclocalcrash) running late. Current output: ... <- feels this guy got stuck
[14:20] <mvo> zyga: uh, apparently that happend to pstolowski as well - sounds like we need to look into this why its fragile
[14:24] <zyga> mvo: another random error observation, pam complains about Jan 30 14:08:45 localhost login[2870]: pam_env(login:session): Unable to open env file: /etc/default/locale: No such file or directory
[14:25] <zyga> mvo: tests failed
[14:25] <zyga> http://paste.ubuntu.com/p/D699fhS5BK/
[14:25] <zyga> it looks like
[14:25] <zyga>  real issue /home/gopath/src/github.com/snapcore/snapd/tests/lib/boot.sh: line 33: fw_setenv: command not found
[14:26] <pstolowski> zyga: i saw that a lot
[14:26] <zyga> https://www.irccloud.com/pastebin/uSQ850Vs/
[14:27] <mvo> zyga: woah
[14:27] <mvo> zyga: is thre /etc/default/locale?
[14:27] <zyga> no
[14:27] <zyga> mvo: where should I report those
[14:27] <zyga> irc doesn't work well
[14:28] <zyga> core18 github?
[14:40] <pedronis> pstolowski: btw what did we conclude about spread tests for hotplug?
[14:44] <pstolowski> pedronis: i've something based on groundwork set by Sergio (nested vm tests), a simple scenario with virtual serial port worked, but it will require some effort still
[14:56] <pedronis> pstolowski: ok
[14:58] <pstolowski> mvo: doh, you won't believe what prevented ssh-agent from working for me
[14:58] <mvo> pstolowski: I'm curious now :)
[14:59] <mvo> zyga: yeah, core18 github
[14:59] <zyga> mvo: thank you, on it
[15:03] <pstolowski> mvo: i had two rsa keys, one very old and unused (i don't even remember what it was); it was also very weak; turns out just having it around caused an issue; got rid of it and ssh agent is now happy about the other key and doesn't prompt for password anymore
[15:05] <mup> Issue core18#117 opened: update-motd is installed but cannot operate on read-only / <bug> <Created by zyga> <https://github.com/snapcore/core18/issue/117>
[15:20]  * zyga -> tea and lunch
[15:43] <mborzecki> #6252 is green now, yay
[15:44] <mup> PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
[16:08] <pedronis> mvo #6453 needs a 2nd review
[16:08] <mup> PR #6453: snap: fix hook autodiscovery for parallel installed snaps <Parallel installs ⛓> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6453>
[16:08] <pedronis> Chipaca: 6452 is green
[16:08] <mvo> pedronis: in a wee bit
[16:09] <pedronis> mvo: np, pointing to it because it would go in 2.37.2
[16:09] <Chipaca> pedronis: whee
[16:09] <mup> PR snapd#6452 closed: overlord/snapstate: format the refresh time for the log <Simple 😃> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6452>
[16:09] <mvo> pedronis: sounds good
[16:10] <zyga> re
[16:12] <Chipaca> brb, walking the dog for a bit
[16:13] <zyga> mvo: it's not a regression but core18 has a real bug
[16:14] <mvo> zyga: which bug? the motd?
[16:14] <zyga> no, the fw_printenv, hold on
[16:15] <zyga> https://github.com/snapcore/core18/issues/118
[16:15] <mup> Issue core18#118 opened: fw_printenv is not present in core18 <bug> <Created by zyga> <https://github.com/snapcore/core18/issue/118>
[16:16] <mvo> zyga: aha, right
[16:16] <mvo> zyga: yeah, I wonder why we did nto notice - oh well. we need to fix it so that we can run the tests. we could even bring it in as a snap or provide an internal command (we have support to write uboot)
[16:16] <zyga> it feels like a core18 or a gadget binary
[16:16] <zyga> it's not great that we didn't notice before release
[16:17] <mvo> zyga: well, I think its only needed for tests
[16:17] <zyga> I'm not familiar with how we use that binary to say where it belongs
[16:17] <mvo> zyga: I'm 99% sure
[16:17] <zyga> mvo: if it is just for tests that's not bad then
[16:17] <mvo> zyga: yeah, we would be in trouble otherwise
[16:17] <zyga> but also means nobody noticed?
[16:17] <zyga> that is, we released ignoring or not testing that
[16:17] <mvo> zyga: yeah, thats the part that is concerning
[16:17] <mvo> zyga: correct
[16:17] <zyga> I will file more bugs
[16:17] <zyga> took a break, got some cold/flu meds
[16:17] <zyga> feeling better now
[16:17] <mvo> zyga: well, what test was this?
[16:18] <mvo> zyga: I am running tests here right now on a dragonboard
[16:18] <mvo> zyga: and they are passing so I wonder *why*
[16:18] <zyga> as core18 or core16?
[16:18] <mvo> zyga: maybe we exclude some tests somewhere for the wrong reasons (systems: [-...])
[16:18] <mvo> zyga: aha, sorry - this one runs on core16
[16:18] <zyga> right
[16:18] <mvo> zyga: I will restart on core18 once this is done
[16:18] <zyga> it's not broken on core18
[16:18] <mvo> zyga: sorry !
[16:18] <zyga> we should generate a diff between file list of core and core18
[16:19] <zyga> mvo: it is likely pawel saw the same issue on pi
[16:19] <zyga> pstolowski: which raspberry pi model did you use and which snapcraft model did you use?
[16:21] <zyga> I amended the bug report with more details
[16:21] <pstolowski> zyga: pi3 model b v1.2, 2015
[16:21] <zyga> mvo: there's no snapcore/dragonboard-kernel
[16:21] <zyga> where should those bug reports go?
[16:21] <pstolowski> zyga: what do you mean by snapcraft model? i just built beta images following the guide, with a script
[16:22] <zyga> pstolowski: snap known model
[16:22] <zyga> what does that say on your device?
[16:22] <pstolowski> ah, let me check
[16:26] <zyga> mvo: we only use fw_setenv for testing, that's okay then
[16:27] <mvo> zyga: yeah, we still need to make sure how to get that in the tests and figure out why we didn't notice this before
[16:29] <cwayne> This sounds like a reason for us to do this full beta image testing in our lab as well
[16:29] <mvo> cwayne: indeed
[16:30] <mvo> cwayne: having nightly runs against edge for pi3/db for core and core18 would be awesome
[16:30] <oSoMoN> hey jdstrand, https://forum.snapcraft.io/t/the-u2f-devices-interface/9722 mentions 2.37+, yet the interface is not in 2.37.1, is that an oversight?
[16:31] <pstolowski> zyga: my pi3 system is borked, snapd daemon doesn't respond to client anymore :(
[16:31] <zyga> that's ok
[16:31] <zyga> which image did you flash?
[16:32] <pstolowski> zyga: pi3-18-beta
[16:32] <zyga> pstolowski: thank yo
[16:32] <zyga> you*
[16:32] <zyga> so that's that, the same bug is present across core18 devices
[16:32] <zyga> mvo: this is double worrying now, it means core18 was not really tested?
[16:32] <zyga> it would not have passed anywhere
[16:35] <mvo> zyga: indeed it is, looking now
[16:35] <zyga> mvo: I will restart core16 testing now
[16:36] <mvo> zyga: core is the critical one
[16:37] <mvo> zyga: but core18 (snapd) also needs to be promoted of course (but it has less users at this point)
[16:37] <mvo> zyga: anyway, I am building a core18 beta now to see if what we can do
[16:37] <zyga> flashing in progress
[16:40] <mvo> I run fresh-install-pi3-core18 now
[16:41] <zyga> mvo: dragonboard doesn't power off, it reboots
[16:41] <zyga> where should I report that?
[16:42] <zyga> booting core16
[16:44] <mvo> zyga: hm, foundations or kernel I would say
[16:44] <zyga> mvo: URL? :-)
[16:44] <zyga> I wish we had one for each part of ubuntu core
[16:44] <mvo> zyga: if kernel ppisati might know why a dragonboard would reboot instead of powerdown
[16:44] <zyga> github.com/snapcraft/dragonboard-kernel
[16:45] <mvo> zyga: +1
[16:45] <pedronis> mvo: we really need to review what we run with core18
[16:46] <mvo> pedronis: indeed - this is still puzzling, I'm running pi3 core18 now here to see what I get
[16:46] <mvo> but of course arm is not run as part of the normal spread
[16:47] <zyga> mvo: I feel weird because I have a feeling _we_ ran the validation tests for core18
[16:47] <mvo> so its plausible that the full suite was not run yet on arm for core18 - if so we really need to make sure to fix that
[16:47] <mvo> zyga: we do - the question is if we ever did that for arm
[16:48] <mvo> zyga: anyway, hopefully I hvae some data points and an image to poke around soon
[16:48] <zyga> mvo: I mean, that you and me were running core18 tests
[16:48] <zyga> mvo: and that we did include pi
[16:49] <zyga> Press enter to configure.
[16:49] <zyga> /usr/share/subiquity/console-conf-wrapper: line 62: read: read error: 0: Resource temporarily unavailable
[16:51] <mvo> zyga: that is something that mwhudson might be interessted in
[16:51] <zyga> mvo: this time I managed to connect, I'll start tests now
[16:55] <mup> PR snapd#6453 closed: snap: fix hook autodiscovery for parallel installed snaps <Parallel installs ⛓> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6453>
[17:22] <diddledan> https://snapstats.org/
[17:22] <diddledan> ^^^ I made a thing!
[17:28] <zyga> diddledan: https://snapstats.org/bases seems inaccurate
[17:28] <zyga> diddledan: look at hello-fedora
[17:29] <diddledan> that's purposely stripped because it's a hello-world snap
[17:29] <zyga> something that should be mentioned
[17:29] <zyga> is the logo use official?
[17:29] <diddledan> no it isn't
[17:30] <diddledan> I am just putting a disclaimer about that
[17:30] <popey> https://www.irccloud.com/pastebin/SOj5dhP7/
[17:30] <popey> ^ zyga
[17:30] <zyga> fedora29 was not pushed to stable
[17:30] <zyga> that's why,
[17:30] <popey> so maybe unpublish hello-fedora from stable?
[17:31] <zyga> I'll publish the base snap
[18:02] <jdstrand> oSoMoN: oh, I thought it made it. I suspect it will be in 2.37.2 then. mvo, fyi u2f-devices is not in 2.37.1
[18:02] <pedronis> mvo: 6453 needs a backport, right?
[18:03] <oSoMoN> jdstrand, ack
[18:03] <pedronis> jdstrand: correct
[18:03] <pedronis> backport is still up for merging together with other bug fixes
[18:28] <mvo> pedronis: correct, I added a card for 6453
[18:29] <mvo> jdstrand: sorry for that, iirc there is a question/issue in the PR
[18:29] <mvo> jdstrand: yes, will be in .2
[18:31] <jdstrand> mvo: I thought all questions were resolved which was why it made it to master. let me know if I should do anything else
[18:32] <mvo> jdstrand: its just that it looks like this PR squashed all the commits in to a single one but it landed in master as 5 individual commits iirc
[18:32] <mvo> jdstrand: so if we merge it this way into 2.37 next time there will be unneeded conflicts when merging 2.37 -> master again
[18:32] <mvo> jdstrand: https://github.com/snapcore/snapd/pull/6434#pullrequestreview-196909893 - but please do let me know if I misremember/misread
[18:32] <mup> PR #6434: interfaces: add u2f-devices interface (2.37) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6434>
[18:37] <jdstrand> mvo: oh! I did that together for a nicer git log for 2.37. is it better if I cherry-pick?
[18:42] <zyga> Error executing external:ubuntu-core-16-arm-64:tests/main/interfaces-daemon-notify https://www.irccloud.com/pastebin/M7vCiVNk/
[18:48] <mvo> jdstrand: yeah, with the cherry picks git should be able to work out that this patch was already applied before - squashing it will result in conflicts if its merged back. I can double check, maybe git got smarter over the years though
[18:48] <mvo> zyga: yeah, I think sergio has a PR for this, once sec, let me try to find it
[18:48] <mvo> zyga: I think we need to cherry pick https://github.com/snapcore/snapd/pull/6394
[18:48] <mup> PR #6394: tests: iterate getting journal logs to support delay on boards on daemon-notify test <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6394>
[18:49] <zyga> mvo: ah, nice
[18:49] <mvo> zyga: the good news is its a test-only thing, no real issue
[18:49] <zyga> yes
[19:01] <jdstrand> mvo: let me just make your life easier and create a new PR
[19:02] <zyga> mvo: daughter interrupt (not that daugther)
[19:03] <zyga> mvo: I will promote after this test finishes and it feels like an hour away
[19:24] <mup> PR snapcraft#2454 opened: baseplugin: add a proper exception for cross-compilation support <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2454>
[19:27] <mvo> zyga: thank you
[19:27] <mvo> zyga: my 2019-01-30 20:18:32 Executing external:ubuntu-core-18-arm-32:tests/core18/snapd-refresh (232/232)...
[19:27] <mvo> zyga: is almost done but that is only relevant for the snapd snap candidate promotion
[19:33] <mup> PR snapcraft#2453 closed: ant, maven and gradle plugins: use correct defaults for jre <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2453>
[19:33] <mvo> zyga: strange things - I ran the ubuntu-core-18-arm-32 suite from a fresh image and did not see the fw_setenv error - in what test did you had this error? fwiw, my full log is at http://paste.ubuntu.com/p/vdmNJDPzBf/
[19:33] <mvo>  
[19:37] <zyga> I added that to the log
[19:37] <zyga> Can you see fw_setenv on PATH?
[19:38] <zyga> (I meant I added that detail to the bug report)
[19:38] <mvo> zyga: I have not logged into the machine, just observed tehat the test did not fail, looking now
[19:43] <mvo> zyga: hm, no fw_printenv on uc18
[19:45] <mvo> zyga: ok, so this is curious - when I grep the tree for "fw_printenv" I see it used in the "bootenv" shell function - this is only used in main/core-snap-refresh-on-core/task.yaml  main/core-snap-refresh/task.yaml  main/failover/task.yaml  main/kernel-snap-refresh-on-core/task.yaml  main/ubuntu-core-upgrade/task.yaml and those are all only running on ubuntu-core-16-*
[19:46] <mvo> zyga: maybe accidently the uc16 tests were run on a uc18 system?
[19:48] <pstolowski> mvo: it's possible in my case, i accidently run tests earlier with dev_snapd_pi argument instead of dev_snapd_pi_18
[19:48] <mvo> pstolowski: sounds plausible
[19:49] <mvo> pstolowski: no worries
[19:50] <pstolowski> mvo: nb, i reflashed and have been running the tests for last 2hrs (225/232 atm) and for the first time it looks it's going somewhere. not sure what changed
[19:50] <mvo> pstolowski: \o/
[19:50] <mvo> pstolowski: sounds encouraging - which test case is that?
[19:51] <pstolowski> mvo: core18/snapd-refresh
[19:51] <mvo> pstolowski: nice
[19:51] <pstolowski> fingers crossed for pastebin at the end..
[19:55] <mvo> yeah
[19:58] <zyga> I’m still with my daughter
[19:58] <zyga> I ran the script from the tree, using “db” name
[20:06] <pstolowski> mvo__ my tests just finished - 4 failures - http://paste.ubuntu.com/p/JjP9dcMfQt/
[20:07] <pstolowski> mvo__: but i see you run fresh install for pi3 as well
[20:53] <zyga> I will be back in 45 minutes :/
[21:13] <mup> PR snapcraft#2455 opened: cli: retrieve error data from provider <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2455>
[21:33] <zyga> Let’s see ...
[21:40] <zyga> dragonboard core16 tests are good
[21:42]  * zyga EOds
[21:55] <diddledan> zyga: I swapped out the snapcraft logo for one of my own creation on snapstats.org
[21:58] <roadmr> diddledan: then your footer doesn't need to say "The Snapcraft logo is copyright Canonical Limited." anymore, does it? :)
[21:58] <diddledan> true
[22:09] <Chipaca> sergiusens: o/
[22:09] <sergiusens> Chipaca: hey!
[22:09] <Chipaca> sergiusens: is that test failing on master as well, or only on that pr?
[22:10] <sergiusens> Chipaca: only on that PR, the thing diddledan did was just convert our schema.yaml to json
[22:11] <Chipaca> sergiusens: right
[22:11] <Chipaca> sergiusens: those error messages are only different in whitespace (one of them is wrapped)
[22:11] <Chipaca> sergiusens: on master, that test uses Equals
[22:12] <Chipaca> sergiusens: and I don't see anything in that PR that changes it to use a different checker
[22:12] <Chipaca> so it's using Equals
[22:12] <Chipaca> and... they aren't equal :-)
[22:13] <sergiusens> Chipaca: I see this now, in the yaml, it is a continous string and in the json diddledan added \n in the message, we should remove the \n from there
[22:14] <Chipaca> yeah, that's the wrong place to \n
[22:14] <Chipaca> :-)
[22:14] <mup> PR snapd#6454 opened: interfaces/apparmor: deny inet/inet6 in snap-update-ns profile <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6454>
[22:16] <mup> PR snapd#6455 opened: interfaces/apparmor: deny inet/inet6 in snap-update-ns profile <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6455>
[22:19] <mup> PR snapcraft#1905 closed: Remove dangling symlink from JDK plugin (LP Bug #1617296) <Created by ARostovsky> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1905>
[22:19] <mup> PR snapcraft#2446 closed: Update schema/snapcraft.yaml <Created by diddledan> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2446>
[22:22] <mup> PR snapcraft#2389 closed: repo: run `apt update` before `apt install` <Created by abitrolly> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2389>
[23:21] <mup> PR snapd#6456 opened: interfaces: add network-manager-observe interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6456>
[23:24] <mup> PR snapd#6457 opened: interfaces: add network-manager-observe interface (2.37) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6457>