[03:40] <brlin> Any chance SNAPCRAFT_BUILD_ENVIRONMENT=lxd get re-implemented in snapcraft?
[06:06] <mborzecki> morning
[07:24] <mborzecki> mvo: morning
[07:25] <mvo> mborzecki: hey, good morning
[07:28] <mborzecki> mvo: left a comment in your dns retry pr
[07:28] <mborzecki> i think it's a bit tricky, especially when there are 2 resolves that could run
[07:37] <mvo> mborzecki: yeah, its nasty
[08:03] <pstolowski> morning
[08:06] <mup> PR snapd#6292 opened: spread: record each tests/upgrade job <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6292>
[08:08] <mborzecki> super simple PR ^^
[08:08] <mborzecki> pstolowski: hey
[08:16] <pstolowski> mborzecki: question there
[08:16] <jamesh> mvo: I got my dbus activation tests working on everything except ubuntu-14.04-64 and ubuntu-core-18-64 now -- I think the ubuntu-core-18-64 failure would be best solved by adding some extra symlinks to the core18 snap
[08:17] <mvo> jamesh: ok, we can do that - could you add details what is needed into the PR?
[08:17] <mvo> jamesh: then I can prepare a PR for core18 :) you are welcome of course to do the pr too if you don't mind digging into the (not very complicated) core18 build (github.com/snapcore/core18)
[08:21] <mborzecki> pstolowski: left a note, we're not running prepare-restore.sh --prepare-suite-each there, idk why, maybe because it'd need some changes internally as it seems to assume snapd is installed
[08:22] <pstolowski> k
[08:23] <mborzecki> pstolowski: and i don't want to go into the process of debugging the whole suite now, just need this little piece to figure out why #6270 fails, i belive it's because the upgrade test runs and since it had the old policy /run/snapd is incorrectly labeled, but the test it's not logged  :/
[08:23] <mup> PR #6270: data/selinux, tests: refactor SELinux policy, add minimal tests <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6270>
[08:27] <pstolowski> mborzecki: sure, replied
[08:36] <pedronis> zyga: hi, I did another pass on #6190
[08:36] <mup> PR #6190: overlord/configstate,features: expose features to snapd tools <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
[08:37] <zyga> Thank you, looking
[08:38] <pedronis> mvo: morning, we have a meeting overlapping the standup today :/
[08:38] <zyga> I’ll add the remaining test and tweak the things you pointed out
[08:38] <mvo> pedronis: yeah, I noticed as well
[08:38] <mvo> pedronis: unfortunate
[08:38] <pedronis> zyga: thx
[08:39] <mborzecki> need to go out for a bit, back in an hour or so
[08:41] <pedronis> mvo: can we have a chat (hopefully short) about state of various things in a bit?
[08:44] <pstolowski> pedronis: hello, updated #6268
[08:44] <mup> PR #6268: overlord/ifacestate: helpers for serializing hotplug changes <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6268>
[08:45] <mvo> pedronis: yes, just wrestling with core18 and cloud-init and ordering right now but I think I'm almost done
[08:45] <pedronis> ok
[08:46] <pedronis> pstolowski: I'll look
[08:46] <pedronis> thx
[08:47] <mup> PR snapd#6209 closed: run-checks: discard test good/bad banner <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6209>
[08:48] <mup> PR core18#97 opened: hooks: add hook to ensure cloud-config runs in the right order <Created by mvo5> <https://github.com/snapcore/core18/pull/97>
[08:51] <zyga> master is still broken?
[08:54] <pedronis> apparently  https://api.travis-ci.org/v3/job/466661285/log.txt
[08:54] <pedronis> still issues with seeded and core18
[08:54] <pedronis> mvo: ^
[08:55] <mvo> pedronis: looking
[08:56] <mvo> pedronis: this is different from what sergio reported: Dec 11 19:49:27 dec111939-540068 systemd[1]: snapd.seeded.service: Main process exited, code=killed, status=15/TERM
[08:57] <mup> PR core18#98 opened: hooks: add symlinks for snapd's D-Bus configuration files <Created by jhenstridge> <https://github.com/snapcore/core18/pull/98>
[08:57] <jamesh> mvo: I think this should fix dbus activation for core18.  I haven't tested it yet though: https://github.com/snapcore/core18/pull/98
[08:57] <mup> PR core18#98: hooks: add symlinks for snapd's D-Bus configuration files <Created by jhenstridge> <https://github.com/snapcore/core18/pull/98>
[08:57] <mvo> jamesh: nice, thank you
[08:57] <pedronis> mvo: this is the degraded test, not sure I know what it does
[08:57] <pedronis> mvo: maybe you other fix, makes this one flaky?
[08:58] <mvo> pedronis: yeah, what I mean is that the error looks different, I will poke at it
[08:58] <mvo> pedronis: could be fallout from the previous change of course :/
[08:58] <pedronis> mvo: I'm slightly worried about the hacks and counter hacks that seeded as is and the snapd being a snap are creating in core18
[08:59] <pedronis> seeded = the service
[08:59] <mvo> pedronis: yeah, I'm unhappy too, what shall we do? I can write up what is happening and we can discuss what the best option is?
[09:00] <mvo> pedronis: i.e. I write down the details and we have a HO once you had a chance to look at it?
[09:00] <zyga> Im happy to help as we
[09:00] <zyga> well
[09:01] <mvo> zyga: sounds great
[09:01] <zyga> nothing brings the mood down as the eternal red cross
[09:12] <pedronis> mvo: also will not the bug about the snapd socket changing affect also other operations, not just the seeded service?
[09:13] <mvo> pedronis: maybe, this happens very early, I'm writing down the sequence then hopefully things are clearer
[09:14] <zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/6288
[09:14] <mup> PR #6288: cmd/snap-confine: refactor call to snap-update-ns --user-mounts <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6288>
[09:21] <pedronis> pstolowski: done
[09:21] <pstolowski> thx
[09:22] <pedronis> thank you
[09:24] <mvo> pedronis, zyga here is the overview, I will write the problems with snapd.seeding next
[09:24] <mvo> snapd.seeded
[09:24] <mvo> pedronis, zyga https://gist.github.com/mvo5/12632c729f07c3b02fa3d0e7383439d5/edit
[09:24] <zyga> looking
[09:28] <zyga> mvo: point 5, typo, I think you mean "then snapd exits"
[09:29] <mvo> zyga: indeed, sorry
[09:29] <zyga> mvo: point 8, I'm always confused by various systemd features, specifically those that relate to ordering and dependencies, is After the one that says something when starting together, runs after, or is it the one that says that it has a hard dependency on something (here core18.start-snapd) and it will not run unless that other unit is started
[09:30] <mvo> zyga: its the "start-after", it does not have any dependency implications
[09:30] <zyga> mvo: question about core81.start-snapd: when does it become ready in sysytemd terms?
[09:30] <mvo> zyga: i.e. it will happily run if the after=nonexisting
[09:30] <mvo> zyga: after seeding is done
[09:30] <zyga> is it using sd-notify?
[09:30] <mvo> zyga: snap watch --last=seed :)
[09:31] <mvo> zyga: should I add it to the gist?
[09:31] <zyga> is it a type oneshot service?
[09:31] <mvo> zyga: correct
[09:31] <mvo> zyga: with remainafter=true
[09:31] <zyga>            Behavior of oneshot is similar to simple; however, it is expected that the process has to exit before systemd starts follow-up units.  RemainAfterExit= is particularly
[09:31] <zyga>            useful for this type of service. This is the implied default if neither Type= nor ExecStart= are specified.
[09:31] <zyga> ^ from the man page
[09:31] <zyga> so that seems all is good
[09:32] <zyga> thank you mvo
[09:32] <mvo> zyga: yeah, I'm writing the problematic parts down now, the first part is mostly to give a good understanding how things work
[09:33] <zyga> thank you for that, it is very useful
[09:33] <zyga> I would love to have a man page for each unit we have
[09:33] <zyga> and what you pasted above could live there
[09:33] <zyga> in that good old unix tradition
[09:38] <pedronis> mvo: read it, I was not aware of this, it seems problematic in many ways tbh
[09:39] <pedronis> I mean fully aware of this
[09:39] <mvo> pedronis: ok, writing down some more, lets talk in a HO then
[09:41] <pedronis> mvo: I have another meeting in 20 but let's see what we can do
[09:41] <popey> What's the minimum allowed length of a snap name?
[09:42] <mvo> pedronis: https://gist.github.com/mvo5/12632c729f07c3b02fa3d0e7383439d5
[09:42] <mvo> pedronis: I can jump in HO now, we can try to make it quick
[09:42] <mvo> pedronis: I'm in the standup channel now
[09:43] <mvo> pedronis: ready when you are
[09:54] <niemeyer> Heya
[09:54] <niemeyer> I've created a team for the base snaps (core18 and 16)
[09:54] <mup> PR core18#97 closed: hooks: add hook to ensure cloud-config runs in the right order <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core18/pull/97>
[09:54] <niemeyer> So all the right people have access to both
[10:07] <mborzecki> re
[10:07] <zyga> thank you niemeyer!
[10:07] <popey> zyga: do you know if there's code somewhere that constrains the length of a snap?
[10:08] <zyga> length of what exactly?
[10:08] <zyga> the file size?
[10:08] <popey> the snap name
[10:08] <zyga> ah
[10:08] <zyga> yes
[10:08] <zyga> it is limited
[10:08] <popey> a, aa, aaa
[10:08] <zyga> in snapcraft, snapd and the store
[10:08] <popey> what's the limit?
[10:08] <zyga> let me look
[10:08] <zyga> AFAIK 40
[10:08] <popey> thanks
[10:08] <zyga> but looking
[10:08] <popey> what's the minimum?
[10:09] <zyga> 2
[10:09] <zyga> max is 40 as I said
[10:09] <zyga> https://github.com/snapcore/snapd/blob/master/snap/validate.go#L94
[10:09] <zyga> this is the logic in snapd
[10:10] <popey> is there a reason why 2 was selected?
[10:10] <zyga> I'm sure there was
[10:10] <zyga> I think a one character command name is pretty unexpected
[10:10] <zyga> and would be filled with spam
[10:10] <popey> "filled" - there's not a lot of single characters available ;)
[10:10] <popey> around 26 or so in English
[10:11] <zyga> snapcraft register a
[10:11] <zyga> ;-)
[10:11] <zyga> anyway, that's that
[10:11] <popey> Ok. I am not sure what to do as I have found a project which I have snapped, but it's one letter long
[10:11] <popey> Am I expected to tell an upstream to rename their project?
[10:12] <zyga> what's the project name?
[10:12] <popey> s
[10:12] <zyga> wow
[10:12] <zyga> what is it?
[10:12] <popey> https://github.com/zquestz/s
[10:12] <popey> open a web search from the command line
[10:12] <popey> so you'd want it to be short
[10:13] <zyga> popey: I suggest that you escalate this to niemeyer
[10:13] <zyga> popey: it could be called the-s
[10:13] <zyga> with an alias perhaps
[10:14] <niemeyer> popey: There's a long culture in Debian of fixing upstream names when they are unfit for purpose
[10:14] <niemeyer> popey: This seems no different
[10:15] <popey> This seems very different. Part of the selling point of snaps is there's not someone in the middle between them and users.
[10:15] <niemeyer> I suffered from that myself.. my old school "smart" project, as in Smart Package Manager, wasn't accepted as "smart"
[10:15] <niemeyer> It was too general
[10:15] <niemeyer> Ended up as "smartpm" in Debian
[10:15] <niemeyer> I can't imagine they'd take "s" :)
[10:15] <popey> Ok
[10:16] <niemeyer> popey: Our infrastructure is a middle man.. we need to balance the voices of publishers with the voice of users
[10:16] <niemeyer> and manufacturers etc
[10:16] <popey> I'll offer a suggestion to them.
[10:17] <niemeyer> popey: Thanks
[10:17] <zyga> niemeyer, popey: do you think the alias idea is workable?
[10:18] <niemeyer> zyga: I don't know to be honest.. it depends a bit more on the context
[10:23] <mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/6292 it's your favourite topic :)
[10:23] <mup> PR #6292: spread: record each tests/upgrade job <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6292>
[10:23] <zyga> mmm
[10:24] <zyga> gaaah
[10:24] <zyga> you want me to look even older
[10:24] <zyga> the reason for upgrade not using that
[10:24] <zyga> is that they setup is quite different
[10:24]  * zyga is sad
[10:25] <zyga> done
[10:25] <mborzecki> zyga: heh, i was tracking a problem in one of the selinux prs, and the only explanation was that the upgrade test ran, turn out those weren't logged like the rest
[10:26] <pedronis> mvo: could you also follow up on that email to foundation you sent, or should I?
[10:26] <mvo> pedronis: I will do that, thank you
[10:26] <mvo> pedronis: just finishing my work on the unit, then I will follow up
[10:27] <pedronis> mvo: thx, also I'm out of the meeting, so we can HO a bit more when you have time
[10:27] <zyga> mborzecki: upgrade tests are very much distinct
[10:27] <zyga> mborzecki: I wonder if it would make sense to run them on a speparate pass
[10:27] <zyga> mborzecki: until we are sure they are not leaving garbage behind
[10:27] <zyga> or vice versa
[10:27] <mborzecki> zyga: committed your suggestion
[10:27] <zyga> thank youu
[10:28] <mborzecki> zyga: i hope that the PR confirms my suspicions as to why https://github.com/snapcore/snapd/pull/6265 fails
[10:28] <mup> PR #6265: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6265>
[10:30] <mvo> pedronis: I think I found a good solution, will push in a bit and then we can HO again
[10:35] <pedronis> pstolowski: any new findings on the slow remove bug? are you blocked on hot plug stuff? missing 2nd reviews?
[10:37] <pedronis> mvo: https://forum.snapcraft.io/t/auto-import-doesnt-work-with-uc18/8960
[10:37] <pstolowski> pedronis: no news yet, investigating. i need 2nd reviews from mvo, yes
[10:37] <mvo> pstolowski: sorry!
[10:38] <pstolowski> pedronis: i'll land hotplug seq soon once travis is green, that one got enough reviews
[10:38] <mvo> pedronis: uh, not more bugs :(
[10:38] <pstolowski> mvo: don't be, i know you have lots of more important stuff atm, np
[10:38] <mvo> pedronis: yeah, the udev auto-import it is, looking at it next
[10:39] <pedronis> mvo: let's chat first tough
[10:39] <pedronis> I mean before you start on something next ...
[10:41] <mup> PR core18#99 opened: static: add snapd.seeded.service to core18 <Created by mvo5> <https://github.com/snapcore/core18/pull/99>
[10:43] <mvo> pedronis: HO?
[10:43] <pedronis> yes
[10:43] <mup> PR core18#100 opened: static: add missing /lib/udev/rules.d/66-snapd-autoimport.rules <Created by mvo5> <https://github.com/snapcore/core18/pull/100>
[10:50] <mborzecki> zyga: added the renames you suggested
[10:51] <mborzecki> anyone interested in doing a 2nd review of #6285 ?
[10:51] <mup> PR #6285: selinux: package to query SELinux status and verify/restore file contexts <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6285>
[10:58] <zyga> mborzecki: thank you :)
[11:00] <mborzecki> zyga: can you take a look at the release bits in #6286 too?
[11:00] <mup> PR #6286: release: support probing SELinux state <SELinux> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6286>
[11:01] <zyga> emmm
[11:01] <zyga> sure
[11:02] <zyga> mborzecki: question about package layout
[11:02] <zyga> mborzecki: or tree layout perhaps
[11:02] <zyga> mborzecki: pkg/selinux, pkg/apparmor, pkg/foo
[11:02] <zyga> instead of top-levels
[11:02] <zyga> ?
[11:03] <mborzecki> zyga: hm that discussion would need to involve the whole team probably
[11:03] <zyga> yes
[11:03] <mborzecki> zyga: can you bring it up during the standup maybe?
[11:03] <zyga> today is not the best moment because pedronis will be off
[11:04] <zyga> and mvo's last day this year
[11:04] <zyga> but next year sure
[11:04] <zyga> nothing urgent
[11:04] <mborzecki> januarny then :) new year resolution
[11:04] <zyga> mborzecki: +1 with the request to make selinux probe lazy
[11:04] <zyga> haha, sounds good :)
[11:04] <zyga> I'd love to shuffle the apparmor package around
[11:04] <zyga> have one pkg/apparmor
[11:04] <zyga> and use it from release and interfaces/apparmor
[11:14] <zyga> brb
[11:25]  * pstolowski lunch
[11:26] <mup> PR core18#100 closed: static: add missing /lib/udev/rules.d/66-snapd-autoimport.rules <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/100>
[11:39] <zyga> re
[11:42] <ackk> hi, I'm trying to build a snap in jenkins, when I run "snapcraft --destructive-mode" it fails with no output at all. tried --debug as well, still no output. how can I debug further? if I access the jenkins slave and run the comand as the same user it works
[11:50] <mup> PR core18#99 closed: static: add snapd.seeded.service to core18 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/99>
[11:52] <zyga> pedronis: updated https://github.com/snapcore/snapd/pull/6190
[11:52] <mup> PR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
[12:05] <zyga> mvo: is this useful for you or can I re-trigger? https://www.irccloud.com/pastebin/WSgr3x1G/
[12:14] <mvo> zyga: kill it, I think this is understood now, the next core18 should have a fix
[12:15] <zyga> thank you
[12:34] <zyga> mborzecki: another small cleanup from my pile https://github.com/snapcore/snapd/pull/6293
[12:34] <mup> PR #6293: cmd/snap-confine: remove unused sc_discard_preserved_mount_ns <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6293>
[12:35] <zyga> removing dead code
[12:35] <zyga> mborzecki: and if you have a sec, this is green too :-) https://github.com/snapcore/snapd/pull/6278
[12:35] <mup> PR snapd#6293 opened: cmd/snap-confine: remove unused sc_discard_preserved_mount_ns <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6293>
[12:35] <mup> PR #6278: cmd/snap: modularize snap list processing <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6278>
[12:35] <zyga> Chipaca: ^ if you ack this I'll feel better asking for it to be merged
[12:42] <Chipaca> zyga: I looked at that yesterday, I wanted to talk with you about it
[12:42] <Chipaca> or was it Monday i looked at it
[12:42] <zyga> sure
[12:42] <Chipaca> anyway
[12:42] <Chipaca> zyga: how is that "modularised"?
[12:42] <zyga> it's easier to make changes without editing those pesky long lines :)"
[12:43] <Chipaca> zyga: +1 for doing that to the header
[12:43] <Chipaca> zyga: the rows, I'm not sure it's a win vs what's there
[12:43] <zyga> Chipaca: or maybe going full in
[12:43] <zyga> and having a struct column {  name string, value func(...) }
[12:45] <pedronis> zyga: I +1ed  6190 with a comment, it needs a 2nd review as well
[12:46] <zyga> pedronis: thank you, I can remove the snap name from that patch set to avoid any controversy and let it move on
[12:46] <zyga> who do you think should perform the 2nd review?
[12:47] <pedronis> no strong preference on that
[12:47] <Chipaca> zyga: as it stands, i'm -1 on that pr, fwiw
[12:47] <mborzecki> Chipaca: zyga: fwiw i'd prefer to use the template engine there
[12:48] <Chipaca> zyga: but I'll admit I might be missing the point
[12:48] <Chipaca> mborzecki: does the template engine handle alignment?
[12:48] <zyga> Chipaca: if you think that's not the way forward, let's then close it
[12:48] <mborzecki> idk, needs checking
[12:48] <zyga> it was a small thing I wanted to explore
[12:48] <Chipaca> mborzecki: I think it doesn't :-)
[12:48] <pedronis> mborzecki: we had a PR about that
[12:48] <zyga> as you know :)
[12:48] <zyga> but not essential
[12:48] <pedronis> and it went in circles
[12:49] <mborzecki> ah
[12:49] <mborzecki> haha
[12:49] <pedronis> I have an ongoing discussion with Chipaca about what to do with our output more in general
[12:49] <pedronis> but next year stuff at this point
[12:49] <Chipaca> pedronis: which reminds me, was that topic post all you hoped for, or did I miss the point?
[12:50] <pedronis> Chipaca: it touches the right things, I don't agree 100% with the conclusion, as I just said, I plan to get back to it
[12:50] <pedronis> is not top priority right now
[12:50] <pedronis> (because so many things)
[12:50] <Chipaca> agreed about so-many-things
[12:50] <pedronis> Chipaca: I tought I mentioned this already with you
[12:50] <Chipaca> but yeah, not completely happy with it myself
[12:50] <pedronis> but maybe I didn't
[12:50] <Chipaca> pedronis: maybe you did, i'm dropping packets myself
[12:52] <zyga> Chipaca, mborzecki: I need a 2nd review on https://github.com/snapcore/snapd/pull/6190
[12:52] <mup> PR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
[12:54] <pedronis> I think Chipaca is off today, no?
[12:55] <Chipaca> I am
[12:55] <zyga> Chipaca: oh, sorry then
[12:55] <Chipaca> no worries
[12:55] <zyga> Chipaca: what are you doing here dear sir?
[12:55] <Chipaca> happy to chat
[12:56] <Chipaca> zyga: chatting with friends?
[12:56] <Chipaca> but maybe also having lunch
[12:56] <zyga> Chipaca: btw, watching parliament TV is interesting
[12:56] <Chipaca> hah, today it might be yes
[12:56] <zyga> Chipaca: fair enough, I do that myself more often than not :)
[12:56] <zyga> Chipaca: 8PM is it?
[12:56] <Chipaca> although they behave like badly-mannered school children
[12:57] <zyga> I beg to differ, they behave like well taught, kindly speaking, badly mannered school children
[12:57] <Chipaca> you forgot pompous, pretentious, and pedantic
[12:57] <Chipaca> and probably other things that start with P
[12:58] <zyga> "my right and honourable friend the douchebag"
[12:58] <zyga> ;-)
[12:58] <zyga> still
[12:58] <zyga> that sentence is far better than typical time-squandering insults I hear from the benches in our own government
[13:01] <pedronis> zyga: I closed that PR btw
[13:01] <mup> PR snapd#6278 closed: cmd/snap: modularize snap list processing <Simple 😃> <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6278>
[13:01] <pedronis> with comment
[13:02] <zyga> +1
[13:09] <pedronis> mborzecki: are you exploding and cleaning up6238 in smaller PRs, is that right?
[13:09] <pedronis> #6238
[13:09] <mup> PR #6238: [WIP] many: add minimal SELinux support, refactor the policy <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6238>
[13:09] <mborzecki> pedronis: yes, all the PRs tagged with selinux label are about that
[13:09] <zyga> some more test woes
[13:09] <zyga> https://www.irccloud.com/pastebin/z2HoQxdq/
[13:09] <zyga> https://api.travis-ci.org/v3/job/466903966/log.txt is full of that
[13:09] <zyga> not sure what to make of this
[13:10] <zyga> away, I was meaning to take a break for coffee / dog
[13:10] <zyga> cachio: if you are around, could you have a look?
[13:12] <cachio> zyga, hey
[13:12] <cachio> sure
[13:12] <cachio> zyga, nice error
[13:13] <zyga> perhaps that's the same issue that mvo is fighting
[13:13] <zyga> with seeding
[13:15] <cachio> zyga, is it happening on master?
[13:20] <zyga> I don't know, I've seen this error today before but perhaps on this branch as well
[13:22] <mborzecki> i have a feeling that the spread jobs only succeed by acccident, and the default state of things is to fail
[13:25] <pedronis> pstolowski: I +1ed #6180 with some final comments
[13:25] <mborzecki> ever seen a failure like this? https://api.travis-ci.org/v3/job/466929872/log.txt
[13:25] <mup> PR #6180: snap/info: bind global plugs/slots to implicit hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6180>
[13:26] <cachio> zyga, last error on master for core18 on degraded test is the same than mvo is working I think
[13:27] <zyga> thank you
[13:27] <cachio> zyga, snapd.seeded service failed to start
[13:27] <pstolowski> pedronis: thanks
[13:27] <cachio> zyga, I'll try to reproduce this one
[13:29] <pedronis> zyga: the gpio enable/disable fix we did only for 2.37 in the end, right?
[13:40] <ackk> does anyone run snapcraft in jenkins?
[13:45] <thresh> ackk, I do for VLC, why
[13:46] <ackk> it seems snapcraft doesn't handle well non-interactive shells
[13:46] <ackk> I'm running it on a slave via ssh
[13:46] <thresh> it does show quite a bit of output
[13:46] <ackk> I had to snapcraft | cat, otherwise I don't get any output
[13:46] <ackk> but it seems now the yarn plugin fails, I suspect because it doesnt' use --non-interactive when calling yarn
[13:46] <thresh> oh?
[13:47] <thresh> I definitely do not do it :)
[13:49] <thresh> ah, "Allocate a pseudo-TTY" is checked for that particular docker container I use to build VLC snap in
[13:49] <thresh> so probably that's hwy
[13:50] <ackk> mhm I wonder if I can do something like that
[13:50] <pedronis> mborzecki: did a pass on #6285
[13:50] <ackk> thresh, do you use a custom image to build with snapcraft in docker?
[13:50] <thresh> ackk, yeah
[13:50] <mup> PR #6285: selinux: package to query SELinux status and verify/restore file contexts <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6285>
[13:51] <mborzecki> pedronis: thanks!
[13:52] <thresh> ackk, https://code.videolan.org/videolan/docker-images/blob/master/vlc-ubuntu-xenial/Dockerfile and https://code.videolan.org/videolan/docker-images/blob/master/videolan-base-xenial/Dockerfile
[13:52] <ackk> thresh, ah yeah we can't use docker like that since we're using jenkins-job-builder and you can't really pass a dockerfile that way
[13:53] <thresh> surely you can pass the image
[13:53] <thresh> but I doubt vlc's one will be handy
[13:53] <zyga> Yes pedronis
[13:54] <pedronis> thx
[13:56] <pedronis> mvo: have you seen that core18 is also red?
[13:57] <pedronis> mvo: I mean,  https://github.com/snapcore/core18/commits/master
[13:57] <pedronis> sorry
[13:57] <ackk> thresh, yeah we currently have a (container) slave dedicated to it, but because of this issue it's failing to build
[13:58] <mvo> pedronis: yes :(
[14:00] <mvo> cachio, degville zyga, mborzecki, pstolowski I can't join the standup today, have a conflicting meeting
[14:00] <thresh> ackk, do you have templates defined in your docker jenkins plugin?  or it works some other way?
[14:00] <cachio> mvo, np
[14:01] <ackk> thresh, no we're not using docker at the moment. but I didn't know you could do that
[14:02] <ackk> thresh, where we use docker, we have a pipeline with a Dockerfile in the repo, which is used by the corrsponding Jenkinsfile
[14:02] <thresh> I wouldnt recommend my way :)
[14:02] <thresh> I'm slowly migrating all that crap to gitlab ci atm
[14:18] <mup> PR core18#101 opened: static: add missing systemd symlinks <Created by mvo5> <https://github.com/snapcore/core18/pull/101>
[14:22]  * cachio afk
[14:23] <mup> PR core18#101 closed: static: add missing systemd symlinks <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core18/pull/101>
[14:28] <mup> PR snapd#6292 closed: spread: record each tests/upgrade job <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6292>
[14:28] <mborzecki> zyga: pushed a smarter way of relabeling to https://github.com/snapcore/snapd/pull/6265
[14:28] <mup> PR #6265: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6265>
[14:29] <mborzecki> zyga: the relevant changes are in cmd/snap/cmd_run*
[14:29] <zyga> Ack
[15:28]  * cachio lunch
[15:39] <mup> PR snapd#6289 closed: cmd/snap-confine: remove SC_NS_MNT_FILE <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6289>
[15:39] <zyga> mborzecki: hey
[15:39] <zyga> mborzecki: quick review request for -55,+0 in 6293
[15:44] <pstolowski> pedronis: do you have a moment for HO? i've some observations & interesting log about task runner
[16:15] <ackk> sergiusens, I see that the multipass provider passes user-data.yaml to multipass when building, is there a way to inject cloud-init configs in there?
[16:18] <kyrofa> noise][, can I use a brand store in classic Ubuntu?
[16:23] <sergiusens> ackk there is not
[16:23] <ackk> sergiusens, I see, thanks
[16:28] <noise][> kyrofa, yes that can be done
[16:29] <kyrofa> noise][, how?
[16:30] <noise][> same as with core basically, you need a model
[16:31] <kyrofa> You can have a model assertion on classic? How is that setup?
[16:33] <pedronis> pstolowski: was having a break, now back but it's a bit late, we should talk tomorrow morning I suppose
[16:34] <pstolowski> pedronis: ok, makes sense
[16:37] <noise][> kyrofa, yes - e.g. do `snap known model` on your classic system. Not sure if we have good docs for setting that up, maybe pedronis would know
[16:38] <pedronis> you can but is fixed unless you make your own image (which there is no simple tooling for for that case), until we introduce remodeling
[16:39] <pedronis> and decide what is possible
[16:40] <kyrofa> Interesting, okay, thanks
[16:50] <pedronis> pstolowski: I answered your question in 6180
[16:51] <pstolowski> pedronis: aha!
[16:51] <pstolowski> thx
[17:00] <zyga> pedronis: FYI https://github.com/snapcore/snapd/pull/6294 is super special experiment, let's see if it passes
[17:00] <mup> PR #6294: packaging/ubuntu: build with golang 1.10 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/6294>
[17:00] <mup> PR snapd#6294 opened: packaging/ubuntu: build with golang 1.10 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/6294>
[17:01] <mup> PR snapcraft#2424 closed: nodejs plugin: fail gracefully when a package.json is missing <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2424>
[17:02] <pedronis> zyga: are blocked?
[17:02] <pedronis> *are you blocked?
[17:02] <zyga> pedronis: no, not at the moment :)
[17:02] <zyga> pedronis: only by master being flaky
[17:02] <pedronis> zyga: we just discussed that indeed we want to switch to 1.9 or 1.10
[17:02] <pedronis> but for 2.38
[17:02] <pedronis> I mean with mvo
[17:02] <zyga> pedronis: this is an experiment to see if this could help with core 18 issue that I discussed with mvo
[17:03] <zyga> to see if there's a long term better way to do something
[17:25] <mup> PR core18#102 opened: static: run snapd for the first time with systemd-run <Created by mvo5> <https://github.com/snapcore/core18/pull/102>
[17:30]  * cachio afk
[17:51]  * zyga afk
[18:43] <mup> PR core18#102 closed: static: run snapd for the first time with systemd-run <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/102>
[18:43] <mup> PR snapd#6103 closed: tests: split nested vm suite on core and classic and new snapshots test <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6103>
[18:45] <mup> PR snapd#6295 opened: systemd: start snapd.autoimport.service in --no-block mode <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6295>
[18:49] <mup> PR snapd#5714 closed: tests: new test for cifs-mount interface <⛔ Blocked> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5714>
[18:50] <cachio> zyga, I was reviewing upgrade test suite and I think it is important to run in every PR
[18:50] <zyga> cachio: I didn't want to change that
[18:50] <mup> PR core18#103 opened: static: add missing systemd symlinks <Created by mvo5> <https://github.com/snapcore/core18/pull/103>
[18:50] <zyga> cachio: I wanted it to run on separate VMs
[18:50] <zyga> by starting spread with update suite separately
[18:51] <zyga> mvo: hey
[18:51] <zyga> back?
[18:51] <mvo> zyga: yes
[18:51] <cachio> zyga, ahh, ok, so run that suite first in the vm?
[18:51] <zyga> cachio: no
[18:51] <cachio> just run that suite on the vm?
[18:51] <zyga> really, just spread -v foo:tests/upgrade
[18:51] <mvo> zyga: I think the open PRs things should be good again, but I'm trying now
[18:52] <zyga> and spread -v tests:/everything-but-upgrade
[18:52] <zyga> separate invocations of spread
[18:52] <zyga> what are the symlinks for mvo?
[18:52] <zyga> ah
[18:52] <zyga> wanted!
[18:53] <zyga> mvo: so we need new snapd release?
[18:53] <cachio> zyga, ok, so first everything-but-upgrade and then upgrade is ok?
[18:54] <zyga> cachio: you can even run them in parallel
[18:54] <zyga> spread foo &
[18:54] <zyga> spread bar &
[18:54] <zyga> wait
[18:54] <mvo> zyga: yes
[18:54] <cachio> zyga, sorry, I don't see how that helps
[18:54] <zyga> cachio: it makes it faster
[18:55] <zyga> cachio: separately invoked spread will not reuse any vms
[18:55] <pedronis> mvo: I'm working on the retry PR btw
[18:55] <zyga> and foo and bar above were selectors needed to run the update suite vs other stuff
[18:56] <cachio> zyga, adding more workers shouldn't help to make that faster?
[18:56] <zyga> cachio: not really
[18:56] <zyga> cachio: starting parallel work in parallel will
[18:57] <mvo> pedronis: \o/
[18:57] <zyga> cachio: do you understand what I'm trying to achieve?
[18:57] <cachio> because if we have 1 maniche which has to prepare the suite, build snapd and then run just 2 tests, then the instance spending to much time preparing compare with running tests
[18:58] <cachio> zyga, not really
[18:58] <cachio> zyga, well you said "run faster"
[18:58] <zyga> cachio: running update suite separately will prevent intermixing it with other suites, we have plenty of issues as is so this is a simple low cost solution to avoiding some
[18:58] <Son_Goku> zyga, what distros do we have left that offer golang < 1.10?
[18:59] <zyga> cachio: running spread twice will need to wait for the first run to finish before starting the first run
[18:59] <zyga> cachio: so the suggestion was to run spread foo &; spread bar &; wait;
[18:59] <zyga> cachio: to start two runs in parallel on two sets of machines
[18:59] <zyga> cachio: does that make sense?
[19:00] <zyga> Son_Goku: nothing, this is just about building with newer golang in ubuntu
[19:00] <cachio> zyga, what will happen with the logging?
[19:00] <cachio> zyga, it could be very confusing
[19:00] <zyga> cachio: it will be sent to stdout, you can obviously redirect it and cat both logs in the end
[19:00] <zyga> cachio: it could also be very sensible :) it depends on how it is done
[19:01] <zyga> cachio: master being broken because of things we don't understand every day is worse than confusing
[19:02] <mup> PR core18#104 opened: static: snapd.seeded.service needs the right After= dependency <Created by mvo5> <https://github.com/snapcore/core18/pull/104>
[19:02] <mvo> zyga: ^- one more trivial one
[19:03] <zyga> yeah, makes sense
[19:03] <mvo> ta!
[19:03] <cachio> zyga, ok, I get the idea but I am not sure running in parallel is the best solution, I'll see if there is another way to force the upgrade suite to run in a separeta vm
[19:04] <cachio> zyga, perhaps to add a new backend attached to the suite
[19:04] <cachio> something like
[19:04] <cachio> spread google: google-upgrade:
[19:05] <cachio> so we have a single spread run
[19:06] <cachio> and single spread logs
[19:07] <cachio> zyga, does it make sense?
[19:07] <mup> PR snapcraft#2425 opened: snap: re-add pyc files for snapcraft <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2425>
[19:08] <pedronis> mvo: pushed
[19:09] <mup> PR core18#104 closed: static: snapd.seeded.service needs the right After= dependency <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/104>
[19:09] <mvo> cachio: we need one more commit, building now
[19:12] <cachio> mvo, good
[19:13] <zyga> cachio: yes it does
[19:13] <pedronis> #6287 needs 2nd reviews, now it also code by me
[19:13] <mup> PR #6287: httputil: retry on temporary net errors <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6287>
[19:27] <zyga> mvo: we need one more patch for 2.36
[19:28] <pedronis> core18 CI failures look a bit messy:  https://api.travis-ci.org/v3/job/467148384/log.txt
[19:29] <mup> PR snapd#6296 opened: tests: new backend used to run upgrade test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6296>
[19:29] <pedronis> zyga: ?
[19:30] <zyga> pedronis: we broke fedora, one sec
[19:30] <mvo> zyga: which one?
[19:30] <zyga> mvo: maciej is making the patch
[19:31] <mborzecki> evenin
[19:31] <zyga> https://bugzilla.redhat.com/show_bug.cgi?id=1658152
[19:32] <zyga> hey
[19:32] <zyga> it seems that we need one ' to fix it
[19:32] <zyga> ideal for 2.36
[19:32] <cachio> zyga, #6296
[19:33] <mup> PR #6296: tests: new backend used to run upgrade test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6296>
[19:33] <cachio> let's see
[19:33] <zyga> super, thanks
[19:33] <zyga> let's see how this behaves
[19:33] <mborzecki> zyga: Pharaoh_Atem: https://github.com/snapcore/snapd/pull/6297
[19:33] <mup> PR #6297: data/selinux: fix syntax error in definition of snappy_admin interface <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6297>
[19:33] <cachio> mvo, core18 rev 491 is the one I should test?
[19:34] <cachio> it is on beta now
[19:34] <mup> PR snapd#6297 opened: data/selinux: fix syntax error in definition of snappy_admin interface <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6297>
[19:35] <mborzecki> zyga: ^^
[19:36] <zyga> mborzecki: are the whitespace changes deliberate?
[19:37] <mborzecki> zyga: not necessary, but made it look like the rest of the code there which is using tabs for indentation
[19:37] <zyga> +1
[19:38] <mvo> cachio: I think this will be a step forward
[19:38] <mvo> but there is one more thing I'm looking at :(
[19:41] <zyga> mvo:  ^ can we cherry pick that into 2.36
[19:42] <mvo> zyga: yes, please mark it
[19:42] <zyga> it's marked
[19:42] <zyga> thank you
[19:45] <zyga> hmm, I log into FAS and yet bugzilla thinks I'm not logged in
[19:45] <zyga> eh
[20:01] <cachio> mvo, last core18 from beta work much better
[20:01] <cachio> could not reproduce the error anymore
[20:02] <mvo> cachio: that sounds very encouraging
[20:03] <zyga> degville: it's almost time
[20:20] <mvo> fwiw, I updated 6243 while waiting for tests but not urgent
[20:20] <pedronis> cachio: mvo: encouraging/good
[20:21] <cachio> pedronis, mvo tests are going well so far
[20:23] <mvo> cachio: cool
[20:24] <degville> thanks for the reminder zyga :) I reckon she'll make it through to the next level.
[20:31] <pedronis> mvo: that change in 6243 seems in the right direction, but copying mutexes by value is not supported afaik and go vet should be unhappy, it will need tweaking
[20:31] <pedronis> (go vet was unhappy here when I tried something like that)
[20:32] <pedronis> cachio: another run dying without actually starting tests: https://api.travis-ci.org/v3/job/467159346/log.txt
[20:32] <pedronis> this was the selinux PR
[20:32] <pedronis> for 2.36
[20:33] <cachio> pedronis, taking a look
[20:34] <cachio> pedronis, this failed on 1 test
[20:34] <cachio> google:ubuntu-core-16-64:tests/main/ubuntu-core-upgrade
[20:35] <pedronis> it didn't reboot?
[20:37] <cachio> pedronis, mmmm, I think it lost connection on reboot
[20:37] <cachio> pedronis, ot os weord
[20:37] <cachio> weird
[20:39] <mvo> pedronis: oh, I thought I did pointers, maybe I was dreaming
[20:40] <cachio> pedronis, perhaps it is related to the error on spread rebooting machines
[20:41] <cachio> pedronis, it is not returning from the reboot
[20:42] <cachio> I'll try  to reproduce it
[20:46] <mvo> pedronis: aha, I see what you mean now. do we actually copy this backend around? I thought we only had a single one, let me look at the code
[20:47] <mvo> pedronis: (maybe I'm just tired :)
[20:58] <pedronis> mvo: the methods on it are by value, so yes, in principle is copied
[20:58] <pedronis> before it was an empty struct so didn't matter
[20:58] <pedronis> much either way
[21:02] <cwayne> mvo: cachio core18 498/497 looks good from our end
[21:03] <cachio> cwayne, nice
[21:03] <pedronis> mvo: so retry logic is not working on arch
[21:03] <pedronis> even newer go?
[21:03] <mvo> pedronis: indeed, I was a bit blind, updated it
[21:03] <mvo> cwayne: thanks, great to hear
[21:03] <mvo> pedronis: oh, I have no idea, let me look at arch
[21:04] <cachio> cwayne, mvo I see 494 on beta
[21:04] <pedronis> mvo: https://api.travis-ci.org/v3/job/467160635/log.txt  also the setup of the test doesn't work on core
[21:04] <cwayne> cachio: armhf/arm64
[21:04] <mvo> cwayne: \o/
[21:04] <cachio> ahh, ok
[21:04] <mvo> pedronis: aha, yes, I think its ok to blacklist core for this test
[21:04] <cwayne> cachio: dont have an x86 device for core18 yet
[21:04] <cachio> cwayne, nice
[21:05] <cachio> mvo, do we need to cover all the architectures for core18?
[21:05] <pedronis> mvo: mv: cannot move '/etc/resolv.conf' to '/etc/resolv.conf.save': Read-only file system
[21:05] <mvo> cachio: yes, eventually, not tonight though
[21:05] <mvo> pedronis: exactly
[21:06] <pedronis> mvo: we can move the file it points to no?
[21:06] <cachio> mvo, ok
[21:07] <mvo> pedronis: yes
[21:07] <pedronis> maybe
[21:07] <pedronis> it just feels strange to skip on core if possible
[21:07] <mvo> pedronis: I think on arch we get "Temporary failure in name resolution" :(
[21:08] <pedronis> but IsTemporary is not set?
[21:08] <mvo> pedronis: it looks like it is not which is ironic given the error text
[21:08] <pedronis> what go does it have?
[21:08] <mvo> pedronis: I try to figure that out now but I don't see it in the output, I may need to run spread with it
[21:09]  * mvo runs in google to find out
[21:13] <pedronis> mvo: seems it might be a cgo error actually
[21:14] <pedronis> so maybe maciej was right, and it's used sometimes
[21:14] <zyga> re
[21:14] <zyga> it seems it's not EOD, or EOY yet
[21:16] <mvo> pedronis: yeah, will you add code to detect it or shall I?
[21:16] <mvo> zyga: not quite
[21:18] <mvo> pedronis: anyway,I can check tomorrow in my morning, I think I need some sleep :) thanks for all your help (and to you zyga,cachio and cwayne as well!)
[21:18] <pedronis> mvo: yes, it's a bit late to try to fix this
[21:18] <pedronis> I'm also not sure how stable/where that message exactly comes from
[21:18] <pedronis> go runtime code? resolver code?
[21:18] <mvo> pedronis: arch has go1.11.2 fwiw
[21:19] <mvo> pedronis: I suspect resolver but we can dig into it tomorrow (grep -r glibc- :)
[21:19] <pedronis> I suspect the same
[21:19] <pedronis> also calling it a day
[21:19] <mvo> pedronis: ttfn!
[21:19] <zyga> mvo: gai error
[21:20] <zyga> I’m on the phone now
[21:20] <cachio> mvo, good sleep
[21:20] <cachio> mvo, see you tomorrow
[21:22] <mvo> cachio: see you
[21:22] <mvo> zyga: gai?
[21:25] <pedronis> anyway seems indeed from libc
[21:39] <zyga> pedronis: yes, the error is from https://linux.die.net/man/3/gai_strerror
[23:13] <mup> PR snapd#6180 closed: snap/info: bind global plugs/slots to implicit hooks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6180>