dave_uyHow do you add a license for a publish snap?00:23
=== ackk is now known as Guest76534
=== StoneTable is now known as aisrael
* Son_Goku hates his life right now03:20
Son_Gokumy air conditioning died, so now it's nearly 35C in my house03:21
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
zygaGood morning05:58
mborzeckizyga: hey06:03
mborzeckimup is quiet again?06:09
mborzeckisimple one ^^06:10
mborzeckimvo: hey06:10
mvohey mborzecki06:11
zygamvo: good morning06:11
mvogood morning zyga06:12
zygamvo: that issue from last evening, the journal included sigsegv06:12
zyganot sure if you noticed that06:12
mvozyga: thanks for the log from last night  I think I know now what is going on06:12
mvozyga: yeah, console-conf06:12
mvozyga: but the key was the error from snap-repair \o/06:12
zygacan you explain?06:13
mvozyga: part of the "bootstrap" of snapd itself is to start its services06:16
mvozyga: if one of them fails the bootstrap fails06:17
mvozyga: and snap-repair is failing apparently because it has no network06:17
mvozyga: so the fix is probably as simple as making this non-fatal (which it is - I mean, it should be :)06:17
zygaah, I see06:18
=== chihchun_afk is now known as chihchun
=== pstolowski|afk is now known as pstolowski
mborzeckipstolowski: o/07:10
mvohey pstolowski ! good morning07:15
mvozyga: if I could get a review for 5734 master should be good again07:32
mvozyga: right now tests are failing there because of the latest core snap changes07:32
zygadoing now07:35
zygamvo: question07:36
mvozyga: ta07:36
zygamvo: what shall we do with snapd code that groks alternatives, in a world with core18 and core16 and snapd there is no way to "depend" on the right build of core in snapd snap (or vice versa)07:37
zygaif I kill the small bit of code that handles alternatives in snap-confine and people upgrade the wrong way they will see old core with alternatives symlinks and nothing to handle that in s-c07:37
zygashall I remove that code or just wait until nobody reasonably will be on the old snapd07:37
mvozyga: if we find /etc/alternatives we keep doing what we are doing today07:37
mvozyga: and once we have epochs we drop it07:37
zygamvo: ah, so only after epochs07:38
zygathat was the answer I was looking for, thanks!07:38
=== Guest76534 is now known as ackk
mvozyga: we can add a note in the code though07:38
mvozyga: we *could* keep the test alive using ubuntu-core07:38
mvozyga: which never changes07:38
mvozyga: I mean, the spread that we just removed07:38
mvozyga: but I think its fine07:38
zygaI think it's fine07:38
mvo:) agreement!07:39
t1mpis there a recommended way to get python 3.6 or 3.7 in a snap? Xenial comes with 3.5...08:07
zygaYou can use base: core18 to use ubuntu 18.04 as a base08:07
zygaor you can build python from source as a part08:07
zygabut I think using the base is easier08:07
t1mpyes, I prefer not to spend the time to build python from source08:08
t1mpright, I'll try core18. I thought that xenial was basically always the base image08:08
=== chihchun is now known as chihchun_afk
t1mpmaybe then it is also time to upgrade my laptop, so that I have the same environment everywhere :)08:09
t1mpwell, I use docker anyway08:09
t1mpzyga: thanks08:09
zygat1mp: you can now choose out of two stable bases08:09
zygat1mp: with more coming08:09
zygat1mp: obviously anyone can run all the snaps regardless of the base they use :)08:10
t1mpzyga: True. But for testing my python lib, and building the snap (I'm not using cleanbuild) locally it is nice to have the same environment08:12
zygayeah, I agree08:12
zygawell, good luck :-)08:12
t1mpwell, for testing the python code locally I use miniconda anyway.08:12
=== chihchun_afk is now known as chihchun
Chipacapedronis: thank you for the review! :-D08:54
Chipacapedronis: I'll look at writing that test asap08:55
pedronisChipaca: thx, I think that's how abort should work without lanes but I might be misremembering anyway my point was also about the comment08:55
Chipacapedronis: yep, i'll add a comment also08:56
zygaChipaca: question for you sir08:56
Chipacazyga: the answer is that it was working that way when I found it, all I did was pick it up and put it somehwere dry, honest ociffer08:56
zygawhat's the factor that chooses * over ✓ https://www.irccloud.com/pastebin/EYj3TrPi/08:56
Chipacazyga: canUnicode is true, assuming --unicode=auto, if the first one of LC_MESSAGES, LC_ALL, or LANG that is set has "UTF-8" or "UTF8" in it (case-insensitively)08:58
Chipacazyga: I say "set" but I mean "set and non-empty", fwiw08:58
zygaChipaca: this test works/fails depending on suse version08:59
zygamissing mocking?08:59
Chipacazyga: I don't think so, but, maybe?08:59
zygaor maybe broken mocking, I'll re-trigger09:00
Chipacazyga: maybe you're on to somehting with the mocking09:02
zygaChipaca: the log comes from obs09:02
Chipacazyga: I think we set LANG=UTF-8 in our run09:03
Chipacaer, C.UTF-809:03
Chipacait's a regexp, we could change it to accept either :-)09:03
zygayes, something for .109:03
zygaI'll fix that09:03
Chipacathe smile is because it'll be a fun regexp09:03
Chipacazyga: but, there should be a bunch of other tests failing in the same way09:04
Chipacaor similar09:04
Chipacazyga: 'snap info' output for ex09:04
Chipacazyga: (not just publisher but the channel map will be different on non-utf8)09:05
ChipacaI _nearly_ succumbed to the temptation of working on widths this last vacation09:07
Chipacabut i resisted! i can do it in my 20% time if i ever do09:07
zyga3 tests left09:08
zyga2945 tests passed with my patch :)09:09
pstolowskizyga: hey, got a moment for HO?09:09
zygaI saw your ping last evening09:09
zygabut I was on a walk then09:09
zygalet's HO09:09
zygacan you send me the link pelase09:09
pedronispstolowski:  I reviewed the sublevel PR with some comments09:20
pstolowskipedronis: thank you!09:28
mborzeckiE: Failed to fetch http://us-east1.gce.archive.ubuntu.com/ubuntu/dists/xenial-updates/universe/binary-amd64/Packages.xz  Hash Sum mismatch09:40
ograzyga, mvo is it true that you want to hide base snaps from "snap list" output ? if so, will there be an exception from this on Ubuntu Core (how would i find out the version of my rootfs otherwise ?)09:42
zygaogra: snap list --all or something will show more things09:47
zygabut I see your point09:47
=== tomwardill_ is now known as tomwardill
zygamaybe on core we should show the boot snap09:47
ograwe often have customers digging through CVEs for example ... for that they need to know what rootfs revision they run etc09:48
ograor perhaps add a --show-base option that lists them again09:48
ogra(i dont really care about the impleentation but the info is valuable on core)09:49
zygaogra: I don't know what the exact argument to show / hide this would be but I think we agreed to have some09:51
ograah, cool, as long as seeing them somehow is still possible all is fine ...09:52
mvoxnox: so about the systemd env generator - i have put a PR up but it does not work and I am a bit lost about the why. setting env vars works just fine. as long as the env is not PATH. now the sad part is that even the man-page talks about reording path so I would assume systemd itself is fine but something we customize is probably not fine. any ideas? I am poking at the code and it looks like it applies DEFAULT_PATH for un09:54
mvoknown reasons and nothing in the (manager) code stands out as strange09:54
pachuloafternoon everyone! Is there any roadmap for core18 snap somewhere? Right now is 0.1 but the beta & edge channels revisions weight as twice as the one in the stable & candidate channels...10:10
popeypachulo: https://forum.snapcraft.io/t/the-road-to-core18/5547  this do?10:13
pachulook, yes, forgot about it, thanks popey !10:18
cachiomvo, hey, I got +1 to go to stable with 2.3510:20
mvocachio: did you had a chance to check with sergiusens  if there will be any issues from his side if we go to stable with 2.35?10:21
cachiomvo, no, I'll do it today10:21
mvocachio: thank you!10:22
cachiomvo, yaw10:24
cachiosergiusens, please tell me which test we should do to validate snapcraft with the core 2.3510:25
cachiomvo, I am leaving in 10 minutes, I'll ping you once I am back10:25
mvocachio: sure, no worries10:26
mvoxnox: fwiw, just tested the same behavior on fedora28 with systemd 238 so might be an upstream bug10:27
Chipacaniemeyer: how do I 'fork' a comment into its own topic? For https://forum.snapcraft.io/t/where-is-a-snap-stored-and-how-can-i-change-that/3194/10?u=chipaca10:41
niemeyerChipaca: Click on the wrench or gear (whatever it is) for the topic, and there should be an option there which will allow you to select the topics to split10:42
Chipacaniemeyer: https://imgur.com/xt0xCgS10:42
niemeyerChipaca: This is the post menu10:43
niemeyerChipaca: At the bottom of the post there should be a topic-general one10:44
Chipacaah, for the _topic_10:44
Chipacaniemeyer: yup! found it, thanks!10:44
ChipacaI plague of radioactive locusts on all randomly-failing tests10:48
zygare :)11:11
zygauseful call with mborzecki11:12
mborzeckizyga: yeah, nice stuff11:12
zygamborzecki: wrote that comment now11:31
mborzeckizyga: thanks11:33
=== pstolowski is now known as pstolowski|lunch
sergiusenscachio, mvo: "snap install snapcraft --classic && snap install lxd && cd $(mktemp -d) && snapcraft init && snapcraft cleanbuild"11:41
ograsergiusens, lxd init ? not needed anymore ?11:44
* Chipaca ~> lunch11:45
=== chihchun is now known as chihchun_afk
* Chipaca ~> hopefully lunch cor real this time11:57
sergiusensogra: yes you do, "lxd init --auto" should cover that12:00
mborzeckizyga: mvo: shall we land https://github.com/snapcore/snapd/pull/5720 ?12:13
sborovkovHi, what does this mean? automated review rejected the snap12:26
sborovkovFailed to run click-review properly. click-review12:26
=== pstolowski|lunch is now known as pstolowski
=== chihchun_afk is now known as chihchun
sborovkovI can't even reupload it because automated review rejects with that dumb error that makes zero sense to user12:33
mvodebugging why systemd env generators do not work for PATH12:34
pedronissborovkov: there's been a regression on how review tools results are being handled, it should be getting fixed12:35
sborovkovpedronis: is there any workaround12:35
pedronissborovkov: I think once the fix is out it should be possible to re-run things and get the proper result and go from there12:36
zygamborzecki: yes, I see it was merged now12:36
pedronisout in the store12:36
zygamvo: hey12:37
zygamvo: about that :)12:37
pedronissborovkov: roadmr can probably say more when he is around12:37
zygamvo: I have a question related to PATH12:37
zygamvo: (also systemd env generators were made for PATH so if they don't work it's a bit unexpected)12:37
sborovkovpedronis: ok, thanks.12:37
zygamvo: on my quest to kill --with-snap-mount-dir I reached 990-snapd.conf.in12:37
mvozyga: yeah, its super annoying12:37
mvozyga: what is your question?12:37
zygamvo: maybe we can ask Zbyszek about it (he implemented them)12:37
zygamvo: can we simply add both /snap/bin:/var/lib/snapd/snap to PATH12:38
mvozyga: do you know him?12:38
zygamvo: so that we have one set of files12:38
zygamvo: yes12:38
zygamvo: I met him at flock and he lives nearby12:38
mvozyga: I was trying to build a test case first before I bother upstream12:38
zygamvo: he invited me to co-work with him on snapd topics in fedora yesterday but $meeting_frenzy12:38
mvozyga: but even that is hard :/12:38
mvozyga: woah12:38
mvozyga: ok, that sounds great12:38
zygamvo: yes :) he's super nice12:38
zygasince he wrote this feature we may just ask12:39
zygabut ideally we'd have a reproducer that we can show him12:39
zyga(something trivial like a shell script that ECHOs one path)12:39
zygamvo: so since we are looking at the same file now, how can I reproduce the problem?12:39
sborovkovpedronis: or is there anyone who i can ask to set it to the accepted state? since it's a branded store it should not be an issue12:39
mvozyga: reproducer is really just "#!/bin/sh -ex; echo "PATH=$PATH:/snap/bin" ; echo "OTHER_ENV=foo"12:39
* zyga adds that and reboots12:40
zygado I need to reboot?12:40
mvozyga: and when I daemon-reload and run "systemd-run --unit testenv; journalctl -u testenv"12:40
mvozyga: no12:40
mvozyga: just daemon reload12:40
zygaok, one sec12:40
mvozyga: let me write a shell script12:40
mvozyga: so that its bullet-proof12:40
mvozyga: and then we can share it12:40
zyga-rw-rw-r--  1 zyga zyga   32 Aug 24 14:00 990-snapd.conf.in12:40
zygawe drop the .in file !?!12:40
zyganot the .conf file12:41
mvozyga: wuuut?12:41
zygamvo, could that be it :D12:41
zygalook at your disk12:41
mvozyga: no, thats not it12:41
mvozyga: I mean that is a problem but that is not related to the systemd env stuff I was poking at this morning12:41
zygahm, something dropped .in on my disk12:41
mvozyga: anyway, I make a reproducer script12:41
mvozyga: and ping you12:41
zygathe in file is not from dpkg12:41
zygahow. I got it now12:42
zygait's from august 2412:42
pedronissborovkov: if it's a branded the store somebody on your team should have permissions to do that , but if the review-tools failed there might something off for real with the snap12:47
sborovkovpedronis, hmm, so we can override automatic review? my previous snap version was uploaded and review went fine. diff shows that there is no difference in snapcraft.yaml besides snap version12:49
mvozyga: please try http://paste.ubuntu.com/p/pjMyGZ7RsR/12:49
pedronissborovkov: there are checks on version too?  what does version look like ?12:50
mvozyga: hm?12:50
zyganothing, just "mmm, trying" (ack)12:50
zygaI heard you :)12:50
mvozyga: ta12:50
mvozyga: sorry, misread :)12:50
pedronissborovkov:  the first is not a question,  there are checks on version too since a while12:50
mborzeckimvo: it doesn't work?12:51
mvomborzecki: it does12:51
mvomborzecki: *but*12:51
mvomborzecki: not for PATH12:51
mvomborzecki: it looks like something overrides that later again12:51
mborzeckimvo: can you rename it to 99-test.sh ?12:51
mvomborzecki: when I set PATHxxx=$PATH:/snap/bin I see a (very) different path12:51
mvomborzecki: sure, let me try that12:51
sborovkovpedronis, I mean in the snapcraft.yaml I just bumped the version from 1.0.19 to 1.0.20. Error from the tools is very weird Failed to run click-review properly. click-review12:51
pedronissomething seems strange12:52
Chipacaniemeyer: I was actually considering runing delete on loading the warnings12:52
Chipacaniemeyer: I'll look into prune though, that might be better (or maybe both)12:52
pedronissborovkov: do you have  a dot at the end of the version by chance or something else odd with the version line12:52
Chipacaniemeyer: note the current impl doesn't delete anywhere12:53
mvozyga: hold on12:53
pedronissborovkov: is this a large snap?12:53
mvozyga: the script has at least one bug, let me fix this first12:53
zygamvo: I have some interesting findings from tinkering12:53
mborzeckimvo: for eg. here on arch i have 10-arch which overrides PATH12:54
sborovkovpedronis, no. it is a large snap yes12:54
sborovkovversion is set to 1.0.2012:54
pedronissborovkov: ok, either way we need somebody that can look around in the store (which I can't)12:54
zygamvo: what's testenv?12:55
niemeyerChipaca: Yeah, Prune seems perfect for that.. it's already multi-purpose, and has the goal of GCing12:55
mvozyga: http://paste.ubuntu.com/p/JnmTrjpWsP/12:55
zygaah, 'EOF' is key12:55
mvozyga: its just a systemd unit that runs the "env" command12:55
mvozyga: yeah, sorry12:55
zygamvo: where is testenv defined?12:55
zygasystemctl cat doesn't know about12:56
zygaabout it12:56
mvozyga: systemd-run --unit testenv env12:56
mvozyga: thats what creates it12:56
zygaI see12:56
mvozyga: I can add -k12:56
mvozyga: to keep it running12:56
zygamvo: does systemd-environment-d-generator matter?12:57
zygamvo: I have an idea!12:57
zygaone sec12:57
pedronissborovkov: I saw you opened a topic,  I will ping somebody that can look when they are around12:58
mvozyga: tell me more please12:58
sborovkovpedronis, thanks12:59
zygathere's a built-in generator that reads /etc/environment.d12:59
zygaand it is stated that generators can mutate the environment for future generators12:59
zygaso perhaps what happens is that we do something but then the default generator just overwrites PATH12:59
zyga       The environment.d directories contain a list of "global" environment variable assignments for the user environment.  systemd-environment-d-generator(8) parses them13:01
zyga       and updates the environment exported by the systemd user instance to the services it starts.13:01
mvozyga: standup :)13:01
mvozyga: /etc/environment.d is empty for me13:01
zygaI have 999-snapd.conf there because I'm running dpkg -i'd master13:02
mvozyga: but even that is ok, no?13:03
mvozyga: i.e. nothing in it overrides PATH13:04
zygaAug 29 15:03:52 fyke env[45277]: MAGIC=canary13:04
zygaAug 29 15:03:52 fyke env[45277]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin13:04
zygaAug 29 15:03:52 fyke env[45277]: ALT_PATH=/sbin:/usr/sbin:/bin:/usr/bin:/it-worked13:04
mvozyga: anyway I was also able to reproduce this in fedora13:04
zygaecho "ALT_PATH=$PATH:/it-worked"13:04
zygaecho "PATH=$PATH:/it-worked"13:04
zygaecho "MAGIC=canary"13:04
mvozyga: but that was on our fedora (google image)13:04
mvozyga: so same issue, right?13:04
zygaI'm testing on bionic locally13:04
zygabut look that ALT_PATH is ok13:04
zygabut still contains _different_ value13:04
zygaso this smells like something else (pam?) changing everything13:05
zyga: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin vs /sbin:/usr/sbin:/bin:/usr/bin13:05
mvozyga: yeah13:05
mvozyga: the latest reproducer also uses PATH in the OTHER_ENV to show that13:06
zygathe first is PATH , the other is ALT_PATH sans the it-worked directory13:06
mvozyga: so yeah, something is fishy13:06
zygagrep for /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin13:06
zygathat's the one we get13:06
mvozyga: well, grep for that in the systemd source ;)13:06
mvozyga: it is also the #define DEFAULT_PATH there13:06
mvozyga: its slightly more complicated there because it has it split up for combined /usr,/ and not but afaict its the same as we have in /etc/environment13:07
zygait's all broken13:07
zygalook at this13:07
mvozyga: I also moved /etc/environment away and tried with that13:07
mvozyga: no difference, but maybe I need to reboot13:07
zygathe value in /etc/environment is _different_, it has /usr/games as well that we don't see13:07
zygathe one in login.defs matches13:08
mvozyga: aha, I actually moved it away /etc/enviornment and still the same issue13:08
zygalet me grep elsewhere13:08
mvozyga: yeah, I commted that out13:08
mvozyga: same issue13:08
mvozyga: I think its internal somehow but maybe I'm wrong13:08
zygaI did a grep in /usr13:10
zygaand ... nothing sensible13:10
zyganothing in systemd13:10
zygaor libraries13:10
zygamvo: /bin/slogin or /bin/rlogin13:11
zygaare those used?13:11
zygaah, I didn't grep in /lib13:12
mvozyga: https://github.com/systemd/systemd/blob/54fe2ce1b943b55162cc35b28e976c4fbf490dae/src/basic/path-util.h#L2613:12
zygait's internal https://www.irccloud.com/pastebin/NI6HRX6J/13:12
mborzeckimvo: your test script has the same issue here on systemd 23913:24
mvomborzecki: something also overrides path for you? yeah, I think we need zyga  to talk to upstream13:34
zygasome more fun with PATH13:38
zygaI'll share my script13:38
mvozyga: anything interessting?13:48
zygamvo: yes13:48
zygaso, some more context needed13:48
mvozyga: does it work?13:48
zygawanna HO?13:48
=== chihchun is now known as chihchun_afk
xnoxmvo, yo! re the testing.14:27
xnoxmvo, you do need to reboot...14:27
xnoxcause manager.c doesn't really rerun system generators on reload/re-exec, or at least I do not see it do that.14:27
cachiosergiusens, hey, I got this https://paste.ubuntu.com/p/BCyssdQKTZ/14:28
mvoxnox: I think reboot does not help and afaicts it does re-run the generators, I did "strace -f -p 1 -e trace=execve -s256 -v" and I can see daemon-reload running my generator14:28
mvoxnox: but let me try to reboot just to be one the safe side14:28
sergiusenscachio: try again, but "snap refresh snapcraft --edge" first.14:29
mvoxnox: http://paste.ubuntu.com/p/JnmTrjpWsP/ <- fwiw - my reproducer14:30
sergiusensthat should come out as soon as this ends https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-43/702414:30
mvoxnox: but *maybe* it runs the generator just does not pick it up14:30
sergiusensfor which I was hoping more interaction with, but oh well.14:30
mvoxnox: anyway, trying to reboot now14:30
* zyga had lunch and needs a small break14:34
mvoxnox: ohhh, it looks like the reboot helped, let me try this again on a clean system (cc zyga)14:36
zygamvo: hold on, I rebooted _doen_ times14:36
zygamvo: what did you get?14:36
mvozyga: oh14:36
zygamvo: did you get PATH changed?14:37
xnoxmvo, i think daemon-reexec may be sufficient, deamon-reload would not be.14:37
=== chihchun_afk is now known as chihchun
xnoxmvo, note that system-environment-generators are not available in xenial14:37
xnoxmvo, i need this in bionic and up, .deb package...14:38
xnoxmvo, such that on classic systems things are right.14:38
zygathat's what I ran14:38
xnoxand on core1814:38
mvoxnox: yeah, I'm testing this on bionic14:38
mvozyga: yes http://paste.ubuntu.com/p/Sr2BMvh8fq/14:38
mborzeckizyga: spread test for parallel instances and the content interface https://paste.ubuntu.com/p/qh33dy9j3W/ basically install some instances, poke data here and there, verify that it's written and visible everywhere14:38
mvozyga: I'm trying inside spread now14:38
xnoxmvo, zyga $ systemclt daemon-reexec14:39
zygamvo: can you add /foo or something like that and check if that is pickedu p14:39
mvozyga: I messed around quite a bit with my system14:39
xnoxnot just daemon-reload....14:39
mvoxnox: cool, will try that14:39
zygaI'll check14:39
zygamborzecki: ack14:39
mvozyga: yeah, its strange14:39
mvoxnox: also the documentation is a bit misleading: "After installing new generators or updating the configuration, systemctl daemon-reload may be executed. This will re-run all generators, updating environment configuration. It will be used for any services that are started subsequently." (from the systemd.environment-generator man page)14:42
mvoxnox: but yeah, running inside spread now, hopefully that was it :)14:42
cachiosergiusens, https://paste.ubuntu.com/p/sqb3YRpZSH/14:44
cachiosergiusens, am I doing somthing wrong?14:45
sergiusenscachio: is the store down? that is basically "snap install core" failing on lxd14:45
xnoxmvo, yeah that's lies.14:45
mvoxnox: :( thanks for confirming14:46
xnoxmvo, * but will not affect running units, units that are starting or stopping, failed units, or things that have been loaded already, or manager instance env will not be updated and so on and so forth14:46
xnoxis closer to truth14:46
zygamvo: because of the fact that the test cleans up after itself my rebooting was not a factor14:47
cachiosergiusens, it is not14:47
mvozyga: ohhhhh14:47
mvozyga: ok14:47
cachioI though it was a problem on my network config14:47
mvozyga: I updated the spread test14:47
sergiusenscachio: try installing core on a "lxc launch ubuntu:xenial" lxd instance14:47
sergiusensit might be your network, did you "sudo lxd init"?14:48
xnoxmvo, zyga - basically we need to affect the internal structure of manager object, which does load /etc/systemd/system.conf and stuff from the generators, but from then on it keeps on serializing state and keeping it persistent even across re-execs. Thus to be sure, we need a reboot, such that manager object loads things correctly upon initial exec.14:48
xnoxi mean, i can fix manager.c to be better, but that will not help with upgrades =) and by the time we rebooted once we should be tip top =)14:49
cachiosergiusens, let me try it14:50
mvoxnox: does https://github.com/mvo5/systemd/commit/9040e581561d920d3ba4ee0e01661392985c4bf6 look sensible?14:54
mvoxnox: just so that the next guy does not have this misleading experience14:54
=== chihchun is now known as chihchun_afk
mvoxnox: actually that did not work in my clean test env - trying the full reboot now14:56
xnoxmvo, i think they will want an issue that adding system generator, things do not change, after daemon-reload/rexec.14:57
xnoxmvo, reading the code i see that it does re-run generators; but then does deserialize; thus wiping the results of generators.14:58
xnoxmvo, imho it should run generators; deserialize; re-run generators again14:58
mvoxnox: +1 for that14:58
mvoxnox: I can file a bug, its easy enough to reproduce14:59
xnoxmvo, yeah, and look at manager_reload function in manager.c14:59
mvoxnox: in a meeting now15:00
xnoxand point out that probably manager_deserialize wipes out the result of manager_run_environment_generators earlier15:00
mvoxnox: thanks, will do15:00
mvoxnox: (in a meeting now)15:10
eraserpencilHi guys, I'm following the official docs and guide https://blog.ubuntu.com/2017/06/28/build-test-and-publish-snap-packages-using-snapcraft, but I cant seem to get it to work.15:15
eraserpencili'm having trouble creating the docker instance15:15
cachiosergiusens, I had to reinstall lxd15:17
cachiosergiusens, it worked las executino15:17
cachioso, do I need to do something else?15:18
sergiusenscachio: on edge? ok that should be released tomorrow15:18
cachiosergiusens, yes, https://paste.ubuntu.com/p/H8ghgN6Pmw/15:18
cachiothis is the log15:18
cachiojdstrand, could you please take a look to the error in #572215:22
sergiusenscachio: 👍15:22
cachiosergiusens, nice15:22
jdstrandcachio: ok15:23
cachiojdstrand, tx15:26
mvoChipaca: review for 5731 would be great, should be trivial15:27
cachiomvo, checked with snapcraft15:28
cachioso I'll make the promotion if its ok for you15:28
cachioI need to check with the store guys for sure15:28
mvocachio: yay15:28
Chipacamvo: hmm. That's a query old gnome-software would do IIRC15:28
mvoChipaca: do we support that query?15:29
mvoChipaca: I looked at the source and could not see we handle unknown15:29
Chipacamvo: we should not fail on it15:29
mvoChipaca: or am I not looking hard enough15:29
ChipacaI think all the test is checking is that we don't fall over15:29
Chipacasource is supposed to be A or B, but if it's C, don't panic15:30
Chipacasomething like that15:30
mvoChipaca: well, I think the test is wrong in any case, if you run it in isolation it fails15:31
Chipacamvo: I'll take a look later, if that's ok15:31
mvoChipaca: totally15:31
Chipacamvo: where does the test come from? i don't have it on master15:31
mvoChipaca: wuut? not in master. its from 201615:31
Chipacagrep -r TestSnapsInfoUnknownSource -> nothing15:32
Chipacaon master here15:32
mvogit grep TestSnapsInfoUnknownSource15:32
mvodaemon/api_test.go:func (s *apiSuite) TestSnapsInfoUnknownSource(15:32
ChipacaI get nothing for the same query :-(15:33
Chipacawhat's going on15:33
Chipacamvo: where is it in this: https://github.com/snapcore/snapd/blob/master/daemon/api_test.go15:34
zygamvo: so what's the bottom line, daemon reexec or bug in manager?15:34
ChipacaAuthor: Michael Vogt <mvo@ubuntu.com>15:34
ChipacaDate:   Tue Aug 28 12:31:46 2018 +020015:34
Chipaca    daemon: remove TestSnapsInfoUnknownSource15:34
Chipaca    15:34
Chipacamvo: you removed that one yesterday15:35
Chipacamvo: in 22cbc462724b9ee7ef42fe0b768981773e6b95bb15:35
mvoChipaca: uhhh, ok15:35
* Chipaca hugs mvo 15:35
mvoChipaca: sounds like the pr needs to change then15:35
mvoChipaca: and I need to re-add it so that we can inspect it15:36
Chipacamvo: leave it as is for now15:36
Chipacamvo: I'll think about it and we can talk tomorrow15:36
mvoChipaca: +115:36
Chipacamvo: it worries me that you're forgetting what you did yesterday :-/ you ok?15:36
mvoChipaca: i am - but maybe a bit too spread out recently :(15:38
Chipacamvo: take care15:38
* Chipaca afk for a bit for same15:39
* mvo hugs Chipaca 15:39
* Chipaca hugs back15:39
pedronisChipaca: what happened I think is that https://github.com/snapcore/snapd/pull/5732 was merged that included the removal PR16:12
cachiomvo, 2.35 is stable16:17
mvocachio: thank you!16:19
cachiomvo, yaw16:19
* zyga ->walk16:26
=== pstolowski is now known as pstolowski|afk
Chipacapedronis: what surprised me was that the new pr didn't conflcit17:16
pedronisChipaca: it was older than one that merged17:20
pedronis*than the17:20
pedronisChipaca: out-of-order merging17:21
Chipacapedronis: All I hear is 'github r dumb'17:21
pedronisChipaca: github doesn't care afaik,  if you create a chain of 10 PR and merge the last one, you get everything in17:21
pedronisnothing stopping you17:21
Chipacapedronis: right, but at that point why doesn't it mark the merged ones somehow17:22
pedronisas implicitly merged?17:22
pedronisit doesn't know, it tracks the to be merged branch, not the target17:23
Chipacapedronis: well it does something to detect conflicts17:23
Chipacapedronis: i'm sure the same something can detect nops17:23
Chipacapedronis: OTOH, ¯\_(ツ)_/¯17:24
pedronisit doesn't seem they care supporting chain of PRs17:24
pedronisit's not a thing it seems for their pov17:24
ograzyga, what ever happened to the non-apparmor side of https://forum.snapcraft.io/t/apparmor-profile-caching/1268 ? did you ever fix the updating of the rootfs mount time ?17:48
zygaogra: checking17:56
zygaogra: ah that17:57
zyganon apparmor side is not affected17:57
zygait was really a combination of apparmor caching, devices without battery-powered RTC _and_ the bug in the time restore from mount time17:57
zygaapparmor caching was reliant upon mtime17:57
zygawith the fix to the last part of the chain the bug is gone17:58
ograzyga, well, the not-updating of the last mount time causes other issues for customer snaps17:59
zygaand that was fixed18:00
ograwe have customers with x509 certs in use that fail when the tie isnt correct18:00
ogra(using them inside their app snaps)18:00
ogrado you know who worked on it so i can point to a PR in a bug ?18:01
zygalet me think18:01
ogra(this can also wait til tomorrow ... no hurry ... i was just pinged about it ...)18:02
zygaI'm wrong18:03
zygaI fixed one aspect of apparmor usage that made us immune to time skew18:03
zygabut I believe someone else (not sure who) worked on the root bug18:03
ograyeh,, that one i know18:03
zygaI will show you what I did18:03
ograi had hoped Chipaca has probably looked into the shutdown issue to fix the root cause18:03
zygaand woot for the commit message18:04
Chipacaogra: ?18:04
ograzyga, right, that doesnt really help with the clock :)18:04
ograChipaca, fixrtc reads the last mount time stamp from dumpe2fs on systems without rtc ... due to the fact that snapd-shutdown-helper never really unmounts, that timestamp permananetly stays at image creation time18:05
Chipacaogra: why does snapd-shutdown-helper never really unmount?18:05
zygaogra: AFAIK it was slightly different18:05
zygaogra: kernel chooses not to update that timestamp if the filesystem is remounted ro before unmounting18:06
ograChipaca, i think thats actually an ext4 bug that zyga discovered18:06
zygaand that's what happens18:06
Chipacaogra: so, no, i haven't fixed it -- first i'm hearing of it :-)18:06
ograheh, yeah, obviously18:06
Chipacain my defence i've been on holidays for a week18:06
ogralets talk tomorrow :)18:07
Chipaca… I could easily go away for another week though18:07
Chipacathis 'working' thing sucks18:07
ograits late and i dont want to keep anyone busy after hours18:07
Chipacayeah, i've got to walk the dog, and see about dinner18:07
ograenjoy ... i'll ping tomorrow18:07
jdstrandkjackal_bot: fyi, https://github.com/snapcore/snapd/pull/573919:39
jdstrandkjackal_bot: fyi, having trouble getting to the docker-support side, so I just sent up the classic change19:42
MattJHowdy. I searched the docs and the forum, but couldn't find an answer... is there a way for a snap to access /etc/ssl? It seems like it would be a common requirement, but I don't know how people handle it20:38
Doctor_NickMattJ: Sounds like you'd need a plug to access the root file system, or just use classic containment21:12
Doctor_Nickalso, if someone could help me out with this issue here, I would be greatly appreciative: https://forum.snapcraft.io/t/getting-a-part-build-artifact-into-another-parts-build-before-pull/708221:14

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