[03:40] Any chance SNAPCRAFT_BUILD_ENVIRONMENT=lxd get re-implemented in snapcraft? [06:06] morning [07:24] mvo: morning [07:25] mborzecki: hey, good morning [07:28] mvo: left a comment in your dns retry pr [07:28] i think it's a bit tricky, especially when there are 2 resolves that could run [07:37] mborzecki: yeah, its nasty === pstolowski|afk is now known as pstolowski [08:03] morning [08:06] PR snapd#6292 opened: spread: record each tests/upgrade job [08:08] super simple PR ^^ [08:08] pstolowski: hey [08:16] mborzecki: question there [08:16] 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] jamesh: ok, we can do that - could you add details what is needed into the PR? [08:17] 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] 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] k [08:23] 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] PR #6270: data/selinux, tests: refactor SELinux policy, add minimal tests [08:27] mborzecki: sure, replied [08:36] zyga: hi, I did another pass on #6190 [08:36] PR #6190: overlord/configstate,features: expose features to snapd tools <⛔ Blocked> [08:37] Thank you, looking [08:38] mvo: morning, we have a meeting overlapping the standup today :/ [08:38] I’ll add the remaining test and tweak the things you pointed out [08:38] pedronis: yeah, I noticed as well [08:38] pedronis: unfortunate [08:38] zyga: thx [08:39] need to go out for a bit, back in an hour or so [08:41] mvo: can we have a chat (hopefully short) about state of various things in a bit? [08:44] pedronis: hello, updated #6268 [08:44] PR #6268: overlord/ifacestate: helpers for serializing hotplug changes [08:45] pedronis: yes, just wrestling with core18 and cloud-init and ordering right now but I think I'm almost done [08:45] ok [08:46] pstolowski: I'll look [08:46] thx [08:47] PR snapd#6209 closed: run-checks: discard test good/bad banner [08:48] PR core18#97 opened: hooks: add hook to ensure cloud-config runs in the right order [08:51] master is still broken? [08:54] apparently https://api.travis-ci.org/v3/job/466661285/log.txt [08:54] still issues with seeded and core18 [08:54] mvo: ^ [08:55] pedronis: looking [08:56] 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] PR core18#98 opened: hooks: add symlinks for snapd's D-Bus configuration files [08:57] 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] PR core18#98: hooks: add symlinks for snapd's D-Bus configuration files [08:57] jamesh: nice, thank you [08:57] mvo: this is the degraded test, not sure I know what it does [08:57] mvo: maybe you other fix, makes this one flaky? [08:58] pedronis: yeah, what I mean is that the error looks different, I will poke at it [08:58] pedronis: could be fallout from the previous change of course :/ [08:58] 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] seeded = the service [08:59] 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] pedronis: i.e. I write down the details and we have a HO once you had a chance to look at it? [09:00] Im happy to help as we [09:00] well [09:01] zyga: sounds great [09:01] nothing brings the mood down as the eternal red cross [09:12] mvo: also will not the bug about the snapd socket changing affect also other operations, not just the seeded service? [09:13] pedronis: maybe, this happens very early, I'm writing down the sequence then hopefully things are clearer [09:14] mborzecki: updated https://github.com/snapcore/snapd/pull/6288 [09:14] PR #6288: cmd/snap-confine: refactor call to snap-update-ns --user-mounts === seb128_ is now known as seb128 [09:21] pstolowski: done [09:21] thx [09:22] thank you [09:24] pedronis, zyga here is the overview, I will write the problems with snapd.seeding next [09:24] snapd.seeded [09:24] pedronis, zyga https://gist.github.com/mvo5/12632c729f07c3b02fa3d0e7383439d5/edit [09:24] looking [09:28] mvo: point 5, typo, I think you mean "then snapd exits" [09:29] zyga: indeed, sorry [09:29] 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] zyga: its the "start-after", it does not have any dependency implications [09:30] mvo: question about core81.start-snapd: when does it become ready in sysytemd terms? [09:30] zyga: i.e. it will happily run if the after=nonexisting [09:30] zyga: after seeding is done [09:30] is it using sd-notify? [09:30] zyga: snap watch --last=seed :) [09:31] zyga: should I add it to the gist? [09:31] is it a type oneshot service? [09:31] zyga: correct [09:31] zyga: with remainafter=true [09:31] 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] useful for this type of service. This is the implied default if neither Type= nor ExecStart= are specified. [09:31] ^ from the man page [09:31] so that seems all is good [09:32] thank you mvo [09:32] 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] thank you for that, it is very useful [09:33] I would love to have a man page for each unit we have [09:33] and what you pasted above could live there [09:33] in that good old unix tradition [09:38] mvo: read it, I was not aware of this, it seems problematic in many ways tbh [09:39] I mean fully aware of this [09:39] pedronis: ok, writing down some more, lets talk in a HO then [09:41] mvo: I have another meeting in 20 but let's see what we can do [09:41] What's the minimum allowed length of a snap name? [09:42] pedronis: https://gist.github.com/mvo5/12632c729f07c3b02fa3d0e7383439d5 [09:42] pedronis: I can jump in HO now, we can try to make it quick [09:42] pedronis: I'm in the standup channel now [09:43] pedronis: ready when you are [09:54] Heya [09:54] I've created a team for the base snaps (core18 and 16) [09:54] PR core18#97 closed: hooks: add hook to ensure cloud-config runs in the right order [09:54] So all the right people have access to both [10:07] re [10:07] thank you niemeyer! [10:07] zyga: do you know if there's code somewhere that constrains the length of a snap? [10:08] length of what exactly? [10:08] the file size? [10:08] the snap name [10:08] ah [10:08] yes [10:08] it is limited [10:08] a, aa, aaa [10:08] in snapcraft, snapd and the store [10:08] what's the limit? [10:08] let me look [10:08] AFAIK 40 [10:08] thanks [10:08] but looking [10:08] what's the minimum? [10:09] 2 [10:09] max is 40 as I said [10:09] https://github.com/snapcore/snapd/blob/master/snap/validate.go#L94 [10:09] this is the logic in snapd [10:10] is there a reason why 2 was selected? [10:10] I'm sure there was [10:10] I think a one character command name is pretty unexpected [10:10] and would be filled with spam [10:10] "filled" - there's not a lot of single characters available ;) [10:10] around 26 or so in English [10:11] snapcraft register a [10:11] ;-) [10:11] anyway, that's that [10:11] 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] Am I expected to tell an upstream to rename their project? [10:12] what's the project name? [10:12] s [10:12] wow [10:12] what is it? [10:12] https://github.com/zquestz/s [10:12] open a web search from the command line [10:12] so you'd want it to be short [10:13] popey: I suggest that you escalate this to niemeyer [10:13] popey: it could be called the-s [10:13] with an alias perhaps [10:14] popey: There's a long culture in Debian of fixing upstream names when they are unfit for purpose [10:14] popey: This seems no different [10:15] 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] I suffered from that myself.. my old school "smart" project, as in Smart Package Manager, wasn't accepted as "smart" [10:15] It was too general [10:15] Ended up as "smartpm" in Debian [10:15] I can't imagine they'd take "s" :) [10:15] Ok [10:16] popey: Our infrastructure is a middle man.. we need to balance the voices of publishers with the voice of users [10:16] and manufacturers etc [10:16] I'll offer a suggestion to them. [10:17] popey: Thanks [10:17] niemeyer, popey: do you think the alias idea is workable? [10:18] zyga: I don't know to be honest.. it depends a bit more on the context [10:23] zyga: can you take a look at https://github.com/snapcore/snapd/pull/6292 it's your favourite topic :) [10:23] PR #6292: spread: record each tests/upgrade job [10:23] mmm [10:24] gaaah [10:24] you want me to look even older [10:24] the reason for upgrade not using that [10:24] is that they setup is quite different [10:24] * zyga is sad [10:25] done [10:25] 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] mvo: could you also follow up on that email to foundation you sent, or should I? [10:26] pedronis: I will do that, thank you [10:26] pedronis: just finishing my work on the unit, then I will follow up [10:27] mvo: thx, also I'm out of the meeting, so we can HO a bit more when you have time [10:27] mborzecki: upgrade tests are very much distinct [10:27] mborzecki: I wonder if it would make sense to run them on a speparate pass [10:27] mborzecki: until we are sure they are not leaving garbage behind [10:27] or vice versa [10:27] zyga: committed your suggestion [10:27] thank youu [10:28] zyga: i hope that the PR confirms my suspicions as to why https://github.com/snapcore/snapd/pull/6265 fails [10:28] PR #6265: cmd/snap: attempt to restore SELinux context of snap user directories [10:30] pedronis: I think I found a good solution, will push in a bit and then we can HO again [10:35] pstolowski: any new findings on the slow remove bug? are you blocked on hot plug stuff? missing 2nd reviews? [10:37] mvo: https://forum.snapcraft.io/t/auto-import-doesnt-work-with-uc18/8960 [10:37] pedronis: no news yet, investigating. i need 2nd reviews from mvo, yes [10:37] pstolowski: sorry! [10:38] pedronis: i'll land hotplug seq soon once travis is green, that one got enough reviews [10:38] pedronis: uh, not more bugs :( [10:38] mvo: don't be, i know you have lots of more important stuff atm, np [10:38] pedronis: yeah, the udev auto-import it is, looking at it next [10:39] mvo: let's chat first tough [10:39] I mean before you start on something next ... [10:41] PR core18#99 opened: static: add snapd.seeded.service to core18 [10:43] pedronis: HO? [10:43] yes [10:43] PR core18#100 opened: static: add missing /lib/udev/rules.d/66-snapd-autoimport.rules [10:50] zyga: added the renames you suggested [10:51] anyone interested in doing a 2nd review of #6285 ? [10:51] PR #6285: selinux: package to query SELinux status and verify/restore file contexts [10:58] mborzecki: thank you :) [11:00] zyga: can you take a look at the release bits in #6286 too? [11:00] PR #6286: release: support probing SELinux state <⛔ Blocked> [11:01] emmm [11:01] sure [11:02] mborzecki: question about package layout [11:02] mborzecki: or tree layout perhaps [11:02] mborzecki: pkg/selinux, pkg/apparmor, pkg/foo [11:02] instead of top-levels [11:02] ? [11:03] zyga: hm that discussion would need to involve the whole team probably [11:03] yes [11:03] zyga: can you bring it up during the standup maybe? [11:03] today is not the best moment because pedronis will be off [11:04] and mvo's last day this year [11:04] but next year sure [11:04] nothing urgent [11:04] januarny then :) new year resolution [11:04] mborzecki: +1 with the request to make selinux probe lazy [11:04] haha, sounds good :) [11:04] I'd love to shuffle the apparmor package around [11:04] have one pkg/apparmor [11:04] and use it from release and interfaces/apparmor [11:14] brb [11:25] * pstolowski lunch [11:26] PR core18#100 closed: static: add missing /lib/udev/rules.d/66-snapd-autoimport.rules [11:39] re [11:42] 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] PR core18#99 closed: static: add snapd.seeded.service to core18 [11:52] pedronis: updated https://github.com/snapcore/snapd/pull/6190 [11:52] PR #6190: overlord/configstate,features: expose features to snapd tools [12:05] mvo: is this useful for you or can I re-trigger? https://www.irccloud.com/pastebin/WSgr3x1G/ [12:14] zyga: kill it, I think this is understood now, the next core18 should have a fix [12:15] thank you [12:34] mborzecki: another small cleanup from my pile https://github.com/snapcore/snapd/pull/6293 [12:34] PR #6293: cmd/snap-confine: remove unused sc_discard_preserved_mount_ns [12:35] removing dead code [12:35] mborzecki: and if you have a sec, this is green too :-) https://github.com/snapcore/snapd/pull/6278 [12:35] PR snapd#6293 opened: cmd/snap-confine: remove unused sc_discard_preserved_mount_ns [12:35] PR #6278: cmd/snap: modularize snap list processing [12:35] Chipaca: ^ if you ack this I'll feel better asking for it to be merged [12:42] zyga: I looked at that yesterday, I wanted to talk with you about it [12:42] or was it Monday i looked at it [12:42] sure [12:42] anyway [12:42] zyga: how is that "modularised"? [12:42] it's easier to make changes without editing those pesky long lines :)" [12:43] zyga: +1 for doing that to the header [12:43] zyga: the rows, I'm not sure it's a win vs what's there [12:43] Chipaca: or maybe going full in [12:43] and having a struct column { name string, value func(...) } [12:45] zyga: I +1ed 6190 with a comment, it needs a 2nd review as well [12:46] pedronis: thank you, I can remove the snap name from that patch set to avoid any controversy and let it move on [12:46] who do you think should perform the 2nd review? [12:47] no strong preference on that [12:47] zyga: as it stands, i'm -1 on that pr, fwiw [12:47] Chipaca: zyga: fwiw i'd prefer to use the template engine there [12:48] zyga: but I'll admit I might be missing the point [12:48] mborzecki: does the template engine handle alignment? [12:48] Chipaca: if you think that's not the way forward, let's then close it [12:48] idk, needs checking [12:48] it was a small thing I wanted to explore [12:48] mborzecki: I think it doesn't :-) [12:48] mborzecki: we had a PR about that [12:48] as you know :) [12:48] but not essential [12:48] and it went in circles [12:49] ah [12:49] haha [12:49] I have an ongoing discussion with Chipaca about what to do with our output more in general [12:49] but next year stuff at this point [12:49] pedronis: which reminds me, was that topic post all you hoped for, or did I miss the point? [12:50] 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] is not top priority right now [12:50] (because so many things) [12:50] agreed about so-many-things [12:50] Chipaca: I tought I mentioned this already with you [12:50] but yeah, not completely happy with it myself [12:50] but maybe I didn't [12:50] pedronis: maybe you did, i'm dropping packets myself [12:52] Chipaca, mborzecki: I need a 2nd review on https://github.com/snapcore/snapd/pull/6190 [12:52] PR #6190: overlord/configstate,features: expose features to snapd tools [12:54] I think Chipaca is off today, no? [12:55] I am [12:55] Chipaca: oh, sorry then [12:55] no worries [12:55] Chipaca: what are you doing here dear sir? [12:55] happy to chat [12:56] zyga: chatting with friends? [12:56] but maybe also having lunch [12:56] Chipaca: btw, watching parliament TV is interesting [12:56] hah, today it might be yes [12:56] Chipaca: fair enough, I do that myself more often than not :) [12:56] Chipaca: 8PM is it? [12:56] although they behave like badly-mannered school children [12:57] I beg to differ, they behave like well taught, kindly speaking, badly mannered school children [12:57] you forgot pompous, pretentious, and pedantic [12:57] and probably other things that start with P [12:58] "my right and honourable friend the douchebag" [12:58] ;-) [12:58] still [12:58] that sentence is far better than typical time-squandering insults I hear from the benches in our own government [13:01] zyga: I closed that PR btw [13:01] PR snapd#6278 closed: cmd/snap: modularize snap list processing [13:01] with comment [13:02] +1 [13:09] mborzecki: are you exploding and cleaning up6238 in smaller PRs, is that right? [13:09] #6238 [13:09] PR #6238: [WIP] many: add minimal SELinux support, refactor the policy [13:09] pedronis: yes, all the PRs tagged with selinux label are about that [13:09] some more test woes [13:09] https://www.irccloud.com/pastebin/z2HoQxdq/ [13:09] https://api.travis-ci.org/v3/job/466903966/log.txt is full of that [13:09] not sure what to make of this [13:10] away, I was meaning to take a break for coffee / dog [13:10] cachio: if you are around, could you have a look? [13:12] zyga, hey [13:12] sure [13:12] zyga, nice error [13:13] perhaps that's the same issue that mvo is fighting [13:13] with seeding [13:15] zyga, is it happening on master? [13:20] I don't know, I've seen this error today before but perhaps on this branch as well [13:22] i have a feeling that the spread jobs only succeed by acccident, and the default state of things is to fail === ricab is now known as ricab|lunch [13:25] pstolowski: I +1ed #6180 with some final comments [13:25] ever seen a failure like this? https://api.travis-ci.org/v3/job/466929872/log.txt [13:25] PR #6180: snap/info: bind global plugs/slots to implicit hooks [13:26] zyga, last error on master for core18 on degraded test is the same than mvo is working I think [13:27] thank you [13:27]