/srv/irclogs.ubuntu.com/2018/12/12/#snappy.txt

brlinAny chance SNAPCRAFT_BUILD_ENVIRONMENT=lxd get re-implemented in snapcraft?03:40
mborzeckimorning06:06
mborzeckimvo: morning07:24
mvomborzecki: hey, good morning07:25
mborzeckimvo: left a comment in your dns retry pr07:28
mborzeckii think it's a bit tricky, especially when there are 2 resolves that could run07:28
mvomborzecki: yeah, its nasty07:37
=== pstolowski|afk is now known as pstolowski
pstolowskimorning08:03
mupPR snapd#6292 opened: spread: record each tests/upgrade job <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6292>08:06
mborzeckisuper simple PR ^^08:08
mborzeckipstolowski: hey08:08
pstolowskimborzecki: question there08:16
jameshmvo: 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 snap08:16
mvojamesh: ok, we can do that - could you add details what is needed into the PR?08:17
mvojamesh: 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:17
mborzeckipstolowski: 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 installed08:21
pstolowskik08:22
mborzeckipstolowski: 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
mupPR #6270: data/selinux, tests: refactor SELinux policy, add minimal tests <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6270>08:23
pstolowskimborzecki: sure, replied08:27
pedroniszyga: hi, I did another pass on #619008:36
mupPR #6190: overlord/configstate,features: expose features to snapd tools <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>08:36
zygaThank you, looking08:37
pedronismvo: morning, we have a meeting overlapping the standup today :/08:38
zygaI’ll add the remaining test and tweak the things you pointed out08:38
mvopedronis: yeah, I noticed as well08:38
mvopedronis: unfortunate08:38
pedroniszyga: thx08:38
mborzeckineed to go out for a bit, back in an hour or so08:39
pedronismvo: can we have a chat (hopefully short) about state of various things in a bit?08:41
pstolowskipedronis: hello, updated #626808:44
mupPR #6268: overlord/ifacestate: helpers for serializing hotplug changes <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6268>08:44
mvopedronis: yes, just wrestling with core18 and cloud-init and ordering right now but I think I'm almost done08:45
pedronisok08:45
pedronispstolowski: I'll look08:46
pedronisthx08:46
mupPR snapd#6209 closed: run-checks: discard test good/bad banner <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6209>08:47
mupPR 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:48
zygamaster is still broken?08:51
pedronisapparently  https://api.travis-ci.org/v3/job/466661285/log.txt08:54
pedronisstill issues with seeded and core1808:54
pedronismvo: ^08:54
mvopedronis: looking08:55
mvopedronis: 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/TERM08:56
mupPR 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
jameshmvo: I think this should fix dbus activation for core18.  I haven't tested it yet though: https://github.com/snapcore/core18/pull/9808:57
mupPR core18#98: hooks: add symlinks for snapd's D-Bus configuration files <Created by jhenstridge> <https://github.com/snapcore/core18/pull/98>08:57
mvojamesh: nice, thank you08:57
pedronismvo: this is the degraded test, not sure I know what it does08:57
pedronismvo: maybe you other fix, makes this one flaky?08:57
mvopedronis: yeah, what I mean is that the error looks different, I will poke at it08:58
mvopedronis: could be fallout from the previous change of course :/08:58
pedronismvo: I'm slightly worried about the hacks and counter hacks that seeded as is and the snapd being a snap are creating in core1808:58
pedronisseeded = the service08:59
mvopedronis: 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?08:59
mvopedronis: i.e. I write down the details and we have a HO once you had a chance to look at it?09:00
zygaIm happy to help as we09:00
zygawell09:00
mvozyga: sounds great09:01
zyganothing brings the mood down as the eternal red cross09:01
pedronismvo: also will not the bug about the snapd socket changing affect also other operations, not just the seeded service?09:12
mvopedronis: maybe, this happens very early, I'm writing down the sequence then hopefully things are clearer09:13
zygamborzecki: updated https://github.com/snapcore/snapd/pull/628809:14
mupPR #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:14
=== seb128_ is now known as seb128
pedronispstolowski: done09:21
pstolowskithx09:21
pedronisthank you09:22
mvopedronis, zyga here is the overview, I will write the problems with snapd.seeding next09:24
mvosnapd.seeded09:24
mvopedronis, zyga https://gist.github.com/mvo5/12632c729f07c3b02fa3d0e7383439d5/edit09:24
zygalooking09:24
zygamvo: point 5, typo, I think you mean "then snapd exits"09:28
mvozyga: indeed, sorry09:29
zygamvo: 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 started09:29
mvozyga: its the "start-after", it does not have any dependency implications09:30
zygamvo: question about core81.start-snapd: when does it become ready in sysytemd terms?09:30
mvozyga: i.e. it will happily run if the after=nonexisting09:30
mvozyga: after seeding is done09:30
zygais it using sd-notify?09:30
mvozyga: snap watch --last=seed :)09:30
mvozyga: should I add it to the gist?09:31
zygais it a type oneshot service?09:31
mvozyga: correct09:31
mvozyga: with remainafter=true09: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 particularly09: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 page09:31
zygaso that seems all is good09:31
zygathank you mvo09:32
mvozyga: yeah, I'm writing the problematic parts down now, the first part is mostly to give a good understanding how things work09:32
zygathank you for that, it is very useful09:33
zygaI would love to have a man page for each unit we have09:33
zygaand what you pasted above could live there09:33
zygain that good old unix tradition09:33
pedronismvo: read it, I was not aware of this, it seems problematic in many ways tbh09:38
pedronisI mean fully aware of this09:39
mvopedronis: ok, writing down some more, lets talk in a HO then09:39
pedronismvo: I have another meeting in 20 but let's see what we can do09:41
popeyWhat's the minimum allowed length of a snap name?09:41
mvopedronis: https://gist.github.com/mvo5/12632c729f07c3b02fa3d0e7383439d509:42
mvopedronis: I can jump in HO now, we can try to make it quick09:42
mvopedronis: I'm in the standup channel now09:42
mvopedronis: ready when you are09:43
niemeyerHeya09:54
niemeyerI've created a team for the base snaps (core18 and 16)09:54
mupPR 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
niemeyerSo all the right people have access to both09:54
mborzeckire10:07
zygathank you niemeyer!10:07
popeyzyga: do you know if there's code somewhere that constrains the length of a snap?10:07
zygalength of what exactly?10:08
zygathe file size?10:08
popeythe snap name10:08
zygaah10:08
zygayes10:08
zygait is limited10:08
popeya, aa, aaa10:08
zygain snapcraft, snapd and the store10:08
popeywhat's the limit?10:08
zygalet me look10:08
zygaAFAIK 4010:08
popeythanks10:08
zygabut looking10:08
popeywhat's the minimum?10:08
zyga210:09
zygamax is 40 as I said10:09
zygahttps://github.com/snapcore/snapd/blob/master/snap/validate.go#L9410:09
zygathis is the logic in snapd10:09
popeyis there a reason why 2 was selected?10:10
zygaI'm sure there was10:10
zygaI think a one character command name is pretty unexpected10:10
zygaand would be filled with spam10:10
popey"filled" - there's not a lot of single characters available ;)10:10
popeyaround 26 or so in English10:10
zygasnapcraft register a10:11
zyga;-)10:11
zygaanyway, that's that10:11
popeyOk. I am not sure what to do as I have found a project which I have snapped, but it's one letter long10:11
popeyAm I expected to tell an upstream to rename their project?10:11
zygawhat's the project name?10:12
popeys10:12
zygawow10:12
zygawhat is it?10:12
popeyhttps://github.com/zquestz/s10:12
popeyopen a web search from the command line10:12
popeyso you'd want it to be short10:12
zygapopey: I suggest that you escalate this to niemeyer10:13
zygapopey: it could be called the-s10:13
zygawith an alias perhaps10:13
niemeyerpopey: There's a long culture in Debian of fixing upstream names when they are unfit for purpose10:14
niemeyerpopey: This seems no different10:14
popeyThis seems very different. Part of the selling point of snaps is there's not someone in the middle between them and users.10:15
niemeyerI suffered from that myself.. my old school "smart" project, as in Smart Package Manager, wasn't accepted as "smart"10:15
niemeyerIt was too general10:15
niemeyerEnded up as "smartpm" in Debian10:15
niemeyerI can't imagine they'd take "s" :)10:15
popeyOk10:15
niemeyerpopey: Our infrastructure is a middle man.. we need to balance the voices of publishers with the voice of users10:16
niemeyerand manufacturers etc10:16
popeyI'll offer a suggestion to them.10:16
niemeyerpopey: Thanks10:17
zyganiemeyer, popey: do you think the alias idea is workable?10:17
niemeyerzyga: I don't know to be honest.. it depends a bit more on the context10:18
mborzeckizyga: can you take a look at https://github.com/snapcore/snapd/pull/6292 it's your favourite topic :)10:23
mupPR #6292: spread: record each tests/upgrade job <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6292>10:23
zygammm10:23
zygagaaah10:24
zygayou want me to look even older10:24
zygathe reason for upgrade not using that10:24
zygais that they setup is quite different10:24
* zyga is sad10:24
zygadone10:25
mborzeckizyga: 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 rest10:25
pedronismvo: could you also follow up on that email to foundation you sent, or should I?10:26
mvopedronis: I will do that, thank you10:26
mvopedronis: just finishing my work on the unit, then I will follow up10:26
pedronismvo: thx, also I'm out of the meeting, so we can HO a bit more when you have time10:27
zygamborzecki: upgrade tests are very much distinct10:27
zygamborzecki: I wonder if it would make sense to run them on a speparate pass10:27
zygamborzecki: until we are sure they are not leaving garbage behind10:27
zygaor vice versa10:27
mborzeckizyga: committed your suggestion10:27
zygathank youu10:27
mborzeckizyga: i hope that the PR confirms my suspicions as to why https://github.com/snapcore/snapd/pull/6265 fails10:28
mupPR #6265: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6265>10:28
mvopedronis: I think I found a good solution, will push in a bit and then we can HO again10:30
pedronispstolowski: any new findings on the slow remove bug? are you blocked on hot plug stuff? missing 2nd reviews?10:35
pedronismvo: https://forum.snapcraft.io/t/auto-import-doesnt-work-with-uc18/896010:37
pstolowskipedronis: no news yet, investigating. i need 2nd reviews from mvo, yes10:37
mvopstolowski: sorry!10:37
pstolowskipedronis: i'll land hotplug seq soon once travis is green, that one got enough reviews10:38
mvopedronis: uh, not more bugs :(10:38
pstolowskimvo: don't be, i know you have lots of more important stuff atm, np10:38
mvopedronis: yeah, the udev auto-import it is, looking at it next10:38
pedronismvo: let's chat first tough10:39
pedronisI mean before you start on something next ...10:39
mupPR core18#99 opened: static: add snapd.seeded.service to core18 <Created by mvo5> <https://github.com/snapcore/core18/pull/99>10:41
mvopedronis: HO?10:43
pedronisyes10:43
mupPR 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:43
mborzeckizyga: added the renames you suggested10:50
mborzeckianyone interested in doing a 2nd review of #6285 ?10:51
mupPR #6285: selinux: package to query SELinux status and verify/restore file contexts <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6285>10:51
zygamborzecki: thank you :)10:58
mborzeckizyga: can you take a look at the release bits in #6286 too?11:00
mupPR #6286: release: support probing SELinux state <SELinux> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6286>11:00
zygaemmm11:01
zygasure11:01
zygamborzecki: question about package layout11:02
zygamborzecki: or tree layout perhaps11:02
zygamborzecki: pkg/selinux, pkg/apparmor, pkg/foo11:02
zygainstead of top-levels11:02
zyga?11:02
mborzeckizyga: hm that discussion would need to involve the whole team probably11:03
zygayes11:03
mborzeckizyga: can you bring it up during the standup maybe?11:03
zygatoday is not the best moment because pedronis will be off11:03
zygaand mvo's last day this year11:04
zygabut next year sure11:04
zyganothing urgent11:04
mborzeckijanuarny then :) new year resolution11:04
zygamborzecki: +1 with the request to make selinux probe lazy11:04
zygahaha, sounds good :)11:04
zygaI'd love to shuffle the apparmor package around11:04
zygahave one pkg/apparmor11:04
zygaand use it from release and interfaces/apparmor11:04
zygabrb11:14
* pstolowski lunch11:25
mupPR 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:26
zygare11:39
ackkhi, 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 works11:42
mupPR core18#99 closed: static: add snapd.seeded.service to core18 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/99>11:50
zygapedronis: updated https://github.com/snapcore/snapd/pull/619011:52
mupPR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>11:52
zygamvo: is this useful for you or can I re-trigger? https://www.irccloud.com/pastebin/WSgr3x1G/12:05
mvozyga: kill it, I think this is understood now, the next core18 should have a fix12:14
zygathank you12:15
zygamborzecki: another small cleanup from my pile https://github.com/snapcore/snapd/pull/629312:34
mupPR #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:34
zygaremoving dead code12:35
zygamborzecki: and if you have a sec, this is green too :-) https://github.com/snapcore/snapd/pull/627812:35
mupPR 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
mupPR #6278: cmd/snap: modularize snap list processing <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6278>12:35
zygaChipaca: ^ if you ack this I'll feel better asking for it to be merged12:35
Chipacazyga: I looked at that yesterday, I wanted to talk with you about it12:42
Chipacaor was it Monday i looked at it12:42
zygasure12:42
Chipacaanyway12:42
Chipacazyga: how is that "modularised"?12:42
zygait's easier to make changes without editing those pesky long lines :)"12:42
Chipacazyga: +1 for doing that to the header12:43
Chipacazyga: the rows, I'm not sure it's a win vs what's there12:43
zygaChipaca: or maybe going full in12:43
zygaand having a struct column {  name string, value func(...) }12:43
pedroniszyga: I +1ed  6190 with a comment, it needs a 2nd review as well12:45
zygapedronis: thank you, I can remove the snap name from that patch set to avoid any controversy and let it move on12:46
zygawho do you think should perform the 2nd review?12:46
pedronisno strong preference on that12:47
Chipacazyga: as it stands, i'm -1 on that pr, fwiw12:47
mborzeckiChipaca: zyga: fwiw i'd prefer to use the template engine there12:47
Chipacazyga: but I'll admit I might be missing the point12:48
Chipacamborzecki: does the template engine handle alignment?12:48
zygaChipaca: if you think that's not the way forward, let's then close it12:48
mborzeckiidk, needs checking12:48
zygait was a small thing I wanted to explore12:48
Chipacamborzecki: I think it doesn't :-)12:48
pedronismborzecki: we had a PR about that12:48
zygaas you know :)12:48
zygabut not essential12:48
pedronisand it went in circles12:48
mborzeckiah12:49
mborzeckihaha12:49
pedronisI have an ongoing discussion with Chipaca about what to do with our output more in general12:49
pedronisbut next year stuff at this point12:49
Chipacapedronis: which reminds me, was that topic post all you hoped for, or did I miss the point?12:49
pedronisChipaca: it touches the right things, I don't agree 100% with the conclusion, as I just said, I plan to get back to it12:50
pedronisis not top priority right now12:50
pedronis(because so many things)12:50
Chipacaagreed about so-many-things12:50
pedronisChipaca: I tought I mentioned this already with you12:50
Chipacabut yeah, not completely happy with it myself12:50
pedronisbut maybe I didn't12:50
Chipacapedronis: maybe you did, i'm dropping packets myself12:50
zygaChipaca, mborzecki: I need a 2nd review on https://github.com/snapcore/snapd/pull/619012:52
mupPR #6190: overlord/configstate,features: expose features to snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>12:52
pedronisI think Chipaca is off today, no?12:54
ChipacaI am12:55
zygaChipaca: oh, sorry then12:55
Chipacano worries12:55
zygaChipaca: what are you doing here dear sir?12:55
Chipacahappy to chat12:55
Chipacazyga: chatting with friends?12:56
Chipacabut maybe also having lunch12:56
zygaChipaca: btw, watching parliament TV is interesting12:56
Chipacahah, today it might be yes12:56
zygaChipaca: fair enough, I do that myself more often than not :)12:56
zygaChipaca: 8PM is it?12:56
Chipacaalthough they behave like badly-mannered school children12:56
zygaI beg to differ, they behave like well taught, kindly speaking, badly mannered school children12:57
Chipacayou forgot pompous, pretentious, and pedantic12:57
Chipacaand probably other things that start with P12:57
zyga"my right and honourable friend the douchebag"12:58
zyga;-)12:58
zygastill12:58
zygathat sentence is far better than typical time-squandering insults I hear from the benches in our own government12:58
pedroniszyga: I closed that PR btw13:01
mupPR 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
pedroniswith comment13:01
zyga+113:02
pedronismborzecki: are you exploding and cleaning up6238 in smaller PRs, is that right?13:09
pedronis#623813:09
mupPR #6238: [WIP] many: add minimal SELinux support, refactor the policy <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6238>13:09
mborzeckipedronis: yes, all the PRs tagged with selinux label are about that13:09
zygasome more test woes13:09
zygahttps://www.irccloud.com/pastebin/z2HoQxdq/13:09
zygahttps://api.travis-ci.org/v3/job/466903966/log.txt is full of that13:09
zyganot sure what to make of this13:09
zygaaway, I was meaning to take a break for coffee / dog13:10
zygacachio: if you are around, could you have a look?13:10
cachiozyga, hey13:12
cachiosure13:12
cachiozyga, nice error13:12
zygaperhaps that's the same issue that mvo is fighting13:13
zygawith seeding13:13
cachiozyga, is it happening on master?13:15
zygaI don't know, I've seen this error today before but perhaps on this branch as well13:20
mborzeckii have a feeling that the spread jobs only succeed by acccident, and the default state of things is to fail13:22
=== ricab is now known as ricab|lunch
pedronispstolowski: I +1ed #6180 with some final comments13:25
mborzeckiever seen a failure like this? https://api.travis-ci.org/v3/job/466929872/log.txt13:25
mupPR #6180: snap/info: bind global plugs/slots to implicit hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6180>13:25
cachiozyga, last error on master for core18 on degraded test is the same than mvo is working I think13:26
zygathank you13:27
cachiozyga, snapd.seeded service failed to start13:27
pstolowskipedronis: thanks13:27
cachiozyga, I'll try to reproduce this one13:27
pedroniszyga: the gpio enable/disable fix we did only for 2.37 in the end, right?13:29
ackkdoes anyone run snapcraft in jenkins?13:40
threshackk, I do for VLC, why13:45
ackkit seems snapcraft doesn't handle well non-interactive shells13:46
ackkI'm running it on a slave via ssh13:46
threshit does show quite a bit of output13:46
ackkI had to snapcraft | cat, otherwise I don't get any output13:46
ackkbut it seems now the yarn plugin fails, I suspect because it doesnt' use --non-interactive when calling yarn13:46
threshoh?13:46
threshI definitely do not do it :)13:47
threshah, "Allocate a pseudo-TTY" is checked for that particular docker container I use to build VLC snap in13:49
threshso probably that's hwy13:49
ackkmhm I wonder if I can do something like that13:50
pedronismborzecki: did a pass on #628513:50
ackkthresh, do you use a custom image to build with snapcraft in docker?13:50
threshackk, yeah13:50
mupPR #6285: selinux: package to query SELinux status and verify/restore file contexts <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6285>13:50
mborzeckipedronis: thanks!13:51
threshackk, 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/Dockerfile13:52
ackkthresh, 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 way13:52
threshsurely you can pass the image13:53
threshbut I doubt vlc's one will be handy13:53
zygaYes pedronis13:53
pedronisthx13:54
pedronismvo: have you seen that core18 is also red?13:56
pedronismvo: I mean,  https://github.com/snapcore/core18/commits/master13:57
pedronissorry13:57
ackkthresh, yeah we currently have a (container) slave dedicated to it, but because of this issue it's failing to build13:57
mvopedronis: yes :(13:58
mvocachio, degville zyga, mborzecki, pstolowski I can't join the standup today, have a conflicting meeting14:00
threshackk, do you have templates defined in your docker jenkins plugin?  or it works some other way?14:00
cachiomvo, np14:00
ackkthresh, no we're not using docker at the moment. but I didn't know you could do that14:01
ackkthresh, where we use docker, we have a pipeline with a Dockerfile in the repo, which is used by the corrsponding Jenkinsfile14:02
threshI wouldnt recommend my way :)14:02
threshI'm slowly migrating all that crap to gitlab ci atm14:02
mupPR core18#101 opened: static: add missing systemd symlinks <Created by mvo5> <https://github.com/snapcore/core18/pull/101>14:18
* cachio afk14:22
mupPR core18#101 closed: static: add missing systemd symlinks <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core18/pull/101>14:23
mupPR 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
mborzeckizyga: pushed a smarter way of relabeling to https://github.com/snapcore/snapd/pull/626514:28
mupPR #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:28
mborzeckizyga: the relevant changes are in cmd/snap/cmd_run*14:29
zygaAck14:29
=== ricab|lunch is now known as ricab
* cachio lunch15:28
mupPR 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
zygamborzecki: hey15:39
zygamborzecki: quick review request for -55,+0 in 629315:39
pstolowskipedronis: do you have a moment for HO? i've some observations & interesting log about task runner15:44
ackksergiusens, 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:15
kyrofanoise][, can I use a brand store in classic Ubuntu?16:18
sergiusensackk there is not16:23
ackksergiusens, I see, thanks16:23
noise][kyrofa, yes that can be done16:28
kyrofanoise][, how?16:29
noise][same as with core basically, you need a model16:30
kyrofaYou can have a model assertion on classic? How is that setup?16:31
pedronispstolowski: was having a break, now back but it's a bit late, we should talk tomorrow morning I suppose16:33
pstolowskipedronis: ok, makes sense16:34
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 know16:37
pedronisyou can but is fixed unless you make your own image (which there is no simple tooling for for that case), until we introduce remodeling16:38
pedronisand decide what is possible16:39
kyrofaInteresting, okay, thanks16:40
pedronispstolowski: I answered your question in 618016:50
pstolowskipedronis: aha!16:51
pstolowskithx16:51
zygapedronis: FYI https://github.com/snapcore/snapd/pull/6294 is super special experiment, let's see if it passes17:00
mupPR #6294: packaging/ubuntu: build with golang 1.10 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/6294>17:00
mupPR snapd#6294 opened: packaging/ubuntu: build with golang 1.10 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/6294>17:00
mupPR 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:01
pedroniszyga: are blocked?17:02
pedronis*are you blocked?17:02
zygapedronis: no, not at the moment :)17:02
zygapedronis: only by master being flaky17:02
pedroniszyga: we just discussed that indeed we want to switch to 1.9 or 1.1017:02
pedronisbut for 2.3817:02
pedronisI mean with mvo17:02
zygapedronis: this is an experiment to see if this could help with core 18 issue that I discussed with mvo17:02
zygato see if there's a long term better way to do something17:03
=== pstolowski is now known as pstolowski|afk
mupPR core18#102 opened: static: run snapd for the first time with systemd-run <Created by mvo5> <https://github.com/snapcore/core18/pull/102>17:25
* cachio afk17:30
* zyga afk17:51
mupPR 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
mupPR 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:43
mupPR snapd#6295 opened: systemd: start snapd.autoimport.service in --no-block mode <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6295>18:45
mupPR 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:49
cachiozyga, I was reviewing upgrade test suite and I think it is important to run in every PR18:50
zygacachio: I didn't want to change that18:50
mupPR core18#103 opened: static: add missing systemd symlinks <Created by mvo5> <https://github.com/snapcore/core18/pull/103>18:50
zygacachio: I wanted it to run on separate VMs18:50
zygaby starting spread with update suite separately18:50
zygamvo: hey18:51
zygaback?18:51
mvozyga: yes18:51
cachiozyga, ahh, ok, so run that suite first in the vm?18:51
zygacachio: no18:51
cachiojust run that suite on the vm?18:51
zygareally, just spread -v foo:tests/upgrade18:51
mvozyga: I think the open PRs things should be good again, but I'm trying now18:51
zygaand spread -v tests:/everything-but-upgrade18:52
zygaseparate invocations of spread18:52
zygawhat are the symlinks for mvo?18:52
zygaah18:52
zygawanted!18:52
zygamvo: so we need new snapd release?18:53
cachiozyga, ok, so first everything-but-upgrade and then upgrade is ok?18:53
zygacachio: you can even run them in parallel18:54
zygaspread foo &18:54
zygaspread bar &18:54
zygawait18:54
mvozyga: yes18:54
cachiozyga, sorry, I don't see how that helps18:54
zygacachio: it makes it faster18:54
zygacachio: separately invoked spread will not reuse any vms18:55
pedronismvo: I'm working on the retry PR btw18:55
zygaand foo and bar above were selectors needed to run the update suite vs other stuff18:55
cachiozyga, adding more workers shouldn't help to make that faster?18:56
zygacachio: not really18:56
zygacachio: starting parallel work in parallel will18:56
mvopedronis: \o/18:57
zygacachio: do you understand what I'm trying to achieve?18:57
cachiobecause 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 tests18:57
cachiozyga, not really18:58
cachiozyga, well you said "run faster"18:58
zygacachio: 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 some18:58
Son_Gokuzyga, what distros do we have left that offer golang < 1.10?18:58
zygacachio: running spread twice will need to wait for the first run to finish before starting the first run18:59
zygacachio: so the suggestion was to run spread foo &; spread bar &; wait;18:59
zygacachio: to start two runs in parallel on two sets of machines18:59
zygacachio: does that make sense?18:59
zygaSon_Goku: nothing, this is just about building with newer golang in ubuntu19:00
cachiozyga, what will happen with the logging?19:00
cachiozyga, it could be very confusing19:00
zygacachio: it will be sent to stdout, you can obviously redirect it and cat both logs in the end19:00
zygacachio: it could also be very sensible :) it depends on how it is done19:00
zygacachio: master being broken because of things we don't understand every day is worse than confusing19:01
mupPR core18#104 opened: static: snapd.seeded.service needs the right After= dependency <Created by mvo5> <https://github.com/snapcore/core18/pull/104>19:02
mvozyga: ^- one more trivial one19:02
zygayeah, makes sense19:03
mvota!19:03
cachiozyga, 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 vm19:03
cachiozyga, perhaps to add a new backend attached to the suite19:04
cachiosomething like19:04
cachiospread google: google-upgrade:19:04
cachioso we have a single spread run19:05
cachioand single spread logs19:06
cachiozyga, does it make sense?19:07
mupPR snapcraft#2425 opened: snap: re-add pyc files for snapcraft <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2425>19:07
pedronismvo: pushed19:08
mupPR 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
mvocachio: we need one more commit, building now19:09
cachiomvo, good19:12
zygacachio: yes it does19:13
pedronis#6287 needs 2nd reviews, now it also code by me19:13
mupPR #6287: httputil: retry on temporary net errors <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6287>19:13
zygamvo: we need one more patch for 2.3619:27
pedroniscore18 CI failures look a bit messy:  https://api.travis-ci.org/v3/job/467148384/log.txt19:28
mupPR snapd#6296 opened: tests: new backend used to run upgrade test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6296>19:29
pedroniszyga: ?19:29
zygapedronis: we broke fedora, one sec19:30
mvozyga: which one?19:30
zygamvo: maciej is making the patch19:30
mborzeckievenin19:31
zygahttps://bugzilla.redhat.com/show_bug.cgi?id=165815219:31
zygahey19:32
zygait seems that we need one ' to fix it19:32
zygaideal for 2.3619:32
cachiozyga, #629619:32
mupPR #6296: tests: new backend used to run upgrade test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6296>19:33
cachiolet's see19:33
zygasuper, thanks19:33
zygalet's see how this behaves19:33
mborzeckizyga: Pharaoh_Atem: https://github.com/snapcore/snapd/pull/629719:33
mupPR #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
cachiomvo, core18 rev 491 is the one I should test?19:33
cachioit is on beta now19:34
mupPR 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:34
mborzeckizyga: ^^19:35
zygamborzecki: are the whitespace changes deliberate?19:36
mborzeckizyga: not necessary, but made it look like the rest of the code there which is using tabs for indentation19:37
zyga+119:37
mvocachio: I think this will be a step forward19:38
mvobut there is one more thing I'm looking at :(19:38
zygamvo:  ^ can we cherry pick that into 2.3619:41
mvozyga: yes, please mark it19:42
zygait's marked19:42
zygathank you19:42
zygahmm, I log into FAS and yet bugzilla thinks I'm not logged in19:45
zygaeh19:45
cachiomvo, last core18 from beta work much better20:01
cachiocould not reproduce the error anymore20:01
mvocachio: that sounds very encouraging20:02
zygadegville: it's almost time20:03
mvofwiw, I updated 6243 while waiting for tests but not urgent20:20
pedroniscachio: mvo: encouraging/good20:20
cachiopedronis, mvo tests are going well so far20:21
mvocachio: cool20:23
degvillethanks for the reminder zyga :) I reckon she'll make it through to the next level.20:24
pedronismvo: 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 tweaking20:31
pedronis(go vet was unhappy here when I tried something like that)20:31
pedroniscachio: another run dying without actually starting tests: https://api.travis-ci.org/v3/job/467159346/log.txt20:32
pedronisthis was the selinux PR20:32
pedronisfor 2.3620:32
cachiopedronis, taking a look20:33
cachiopedronis, this failed on 1 test20:34
cachiogoogle:ubuntu-core-16-64:tests/main/ubuntu-core-upgrade20:34
pedronisit didn't reboot?20:35
cachiopedronis, mmmm, I think it lost connection on reboot20:37
cachiopedronis, ot os weord20:37
cachioweird20:37
mvopedronis: oh, I thought I did pointers, maybe I was dreaming20:39
cachiopedronis, perhaps it is related to the error on spread rebooting machines20:40
cachiopedronis, it is not returning from the reboot20:41
cachioI'll try  to reproduce it20:42
mvopedronis: 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 code20:46
mvopedronis: (maybe I'm just tired :)20:47
pedronismvo: the methods on it are by value, so yes, in principle is copied20:58
pedronisbefore it was an empty struct so didn't matter20:58
pedronismuch either way20:58
cwaynemvo: cachio core18 498/497 looks good from our end21:02
cachiocwayne, nice21:03
pedronismvo: so retry logic is not working on arch21:03
pedroniseven newer go?21:03
mvopedronis: indeed, I was a bit blind, updated it21:03
mvocwayne: thanks, great to hear21:03
mvopedronis: oh, I have no idea, let me look at arch21:03
cachiocwayne, mvo I see 494 on beta21:04
pedronismvo: https://api.travis-ci.org/v3/job/467160635/log.txt  also the setup of the test doesn't work on core21:04
cwaynecachio: armhf/arm6421:04
mvocwayne: \o/21:04
cachioahh, ok21:04
mvopedronis: aha, yes, I think its ok to blacklist core for this test21:04
cwaynecachio: dont have an x86 device for core18 yet21:04
cachiocwayne, nice21:04
cachiomvo, do we need to cover all the architectures for core18?21:05
pedronismvo: mv: cannot move '/etc/resolv.conf' to '/etc/resolv.conf.save': Read-only file system21:05
mvocachio: yes, eventually, not tonight though21:05
mvopedronis: exactly21:05
pedronismvo: we can move the file it points to no?21:06
cachiomvo, ok21:06
mvopedronis: yes21:07
pedronismaybe21:07
pedronisit just feels strange to skip on core if possible21:07
mvopedronis: I think on arch we get "Temporary failure in name resolution" :(21:07
pedronisbut IsTemporary is not set?21:08
mvopedronis: it looks like it is not which is ironic given the error text21:08
pedroniswhat go does it have?21:08
mvopedronis: I try to figure that out now but I don't see it in the output, I may need to run spread with it21:08
* mvo runs in google to find out21:09
pedronismvo: seems it might be a cgo error actually21:13
pedronisso maybe maciej was right, and it's used sometimes21:14
zygare21:14
zygait seems it's not EOD, or EOY yet21:14
mvopedronis: yeah, will you add code to detect it or shall I?21:16
mvozyga: not quite21:16
mvopedronis: 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
pedronismvo: yes, it's a bit late to try to fix this21:18
pedronisI'm also not sure how stable/where that message exactly comes from21:18
pedronisgo runtime code? resolver code?21:18
mvopedronis: arch has go1.11.2 fwiw21:18
mvopedronis: I suspect resolver but we can dig into it tomorrow (grep -r glibc- :)21:19
pedronisI suspect the same21:19
pedronisalso calling it a day21:19
mvopedronis: ttfn!21:19
zygamvo: gai error21:19
zygaI’m on the phone now21:20
cachiomvo, good sleep21:20
cachiomvo, see you tomorrow21:20
mvocachio: see you21:22
mvozyga: gai?21:22
pedronisanyway seems indeed from libc21:25
zygapedronis: yes, the error is from https://linux.die.net/man/3/gai_strerror21:39
=== joedborg_ is now known as joedborg
=== blackboxsw_ is now known as blackboxsw
mupPR 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>23:13

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