/srv/irclogs.ubuntu.com/2019/09/03/#snappy.txt

mborzeckimorning04:52
zygaGood morning05:04
mborzeckizyga: kids already at school, yay ;)05:05
zygamborzecki: oldest just went to school05:15
zygamborzecki: middle one finished breakfast05:15
zygamborzecki: youngest one plays with her toys :)05:15
zygamborzecki: our son is 170 now05:15
zygahe's not even 1305:15
zygamborzecki: easy landing for the morning https://github.com/snapcore/snapd/pull/7218#pullrequestreview-27271653505:15
zygamborzecki: I added the extra checks you asked for05:16
mupPR #7218: tests: measure behavior of the device cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/7218>05:16
mborzeckiand it's green :)05:16
zygawoot, thankyou05:17
zygaanother easy ish is https://github.com/snapcore/snapd/pull/739205:17
mupPR #7392: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7392>05:17
zyganeeds 2nd +105:17
zygaalso green05:17
mupPR snapd#7218 closed: tests: measure behavior of the device cgroup <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7218>05:17
zygamborzecki: one more kid to walk to school, ttyl05:29
zygaback now06:00
mborzeckimvo: morning06:30
mvohey mborzecki06:32
zygagood morning mvo06:36
zygamvo: one more review if I can grab your attention :)06:36
zygahttps://github.com/snapcore/snapd/pull/739206:36
mupPR #7392: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7392>06:36
zygamborzecki: let's start chopping your classic mount namespace PR as we discussed in private06:37
zygait will help with the review and will help with figuring out what is wrong06:37
mvohey zyga06:37
zyga:-)06:38
zygamvo: do you know who is the upstream of command-not-found nowadays?06:39
mvozyga: foundations, why?06:42
zygamvo: I have some patches06:42
mborzeckimvo: zyga: #7393 really simple06:47
mupPR snapd#7393 opened: cmd/libsnap-confine-private, cmd/s-c: use constants for snap/instance name lengths <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7393>06:47
mupPR #7393: cmd/libsnap-confine-private, cmd/s-c: use constants for snap/instance name lengths <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7393>06:47
zygamborzecki: +106:48
mborzeckithx06:48
mupPR snapd#7394 opened: tests: move debug section after restore <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7394>06:58
=== pstolowski|afk is now known as pstolowski
pstolowskimorning07:05
zygagood morning pawel!07:05
pedronispstolowski: hi, what's the status of #7277 ?07:11
mupPR #7277: [RFC] overlord/snapstate: fix undo on firstboot seeding <Created by stolowski> <https://github.com/snapcore/snapd/pull/7277>07:12
* zyga goes to read https://github.com/snapcore/snapd/pull/738107:12
mupPR #7381: seed,image,o/devicestate: extract seed loading to seed/seed16.go <Created by pedronis> <https://github.com/snapcore/snapd/pull/7381>07:12
zygagreat for rainy morning focus :)07:13
pstolowskipedronis: hi, i've addressed your feedback but not yet happy about some aspects, i need to revisit this PR, i haven't looked at it for a while07:23
mborzeckipstolowski: pedronis: hi07:26
pedronispstolowski: it's the last bit of https://trello.com/c/9Clql0BE/299-first-boot-fixes , considering that the initramfs/grub stuff is more nice to have07:26
pedronisand also not great time given uc20 work07:26
pstolowskipedronis: ack, going to look at it today07:28
zygais it just me or is github not responding very well now?07:32
mupPR snapd#7393 closed: cmd/libsnap-confine-private, cmd/s-c: use constants for snap/instance name lengths <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7393>07:38
* zyga short break07:43
mupPR snapd#7394 closed: tests: move debug section after restore <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7394>07:49
Chipacazyga: ping08:38
zygahey08:38
Chipacazyga: hiya08:39
Chipacazyga: what's the purpose of osutil.MountOptsToFlags ?08:40
Chipacait seems very sensible, but it's not used -- instead, the unchecked MountOptsToCommonFlags is used08:40
zygalet me look08:41
Chipacak08:41
Chipacanot going to change it, but it caught my attention08:41
Chipaca(i'm fixing compilation on darwin)08:41
zygaah,08:42
zygaI see it now08:42
zygait's the layer on top of common flags that understands x-snapd and filters them out but errors on unknown flags08:42
zygalet me look at that08:42
zygathanks!08:42
Chipacazyga: np! tbh it looks like the Common one should be private, if i understand the difference08:43
zygaif you look at how it is used, common is the one being used because we acknowledge there are flags we don't understand that we just pass to mount08:44
mupPR snapd#7395 opened: cmd/snap-confine: apply global mount namespace initialization for confined and classic snaps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7395>08:44
zygaso I think the strict version is just unused and could be removed08:44
pstolowskizyga: any thoughs on https://bugs.launchpad.net/snapd/+bug/1841137 ?08:50
mupBug #1841137: /dev/loopX devices left around for removed snap revisions <snapd:Triaged> <https://launchpad.net/bugs/1841137>08:50
zygapstolowski: oooh08:53
zygainteresting08:53
pstolowskizyga: garbage collection gone wrong?08:54
zygathere's no garbage collection, it's explicitly managed malloc/free style08:54
zygathe deleted aspect is super puzzling!08:54
pstolowskizyga: i mean gc in the sense of removing old revisions automatically08:55
zygapstolowski: nitpick: triaged literally means: we know the severity08:55
zygasetting it to triaged without setting one is weird08:55
zygapstolowski: normally mount does that08:55
zygapstolowski: libmount removes loopback devices08:55
Chipacaagreed about triaged08:56
zygasince I just rebooted08:56
Chipacaif you don't know the severity it's confirmed, not triaged :-)08:56
zygacan everyone with a longer uptime run: sudo losetup | grep deleted08:56
zygaand see if it shows anything08:56
Chipacanothing right now but i have seen them before08:56
Chipacathat's when they appear in unity08:57
Chipacai didn't know it was noteworthy :-)08:57
zygathat's super curious08:57
zygaI wonder if that's another lowlevel bug in kernel/libmount/systemd08:57
zyganormally systemd doesn't handle those so more likely in libmount08:57
pstolowskiChipaca, zyga noted, thanks :)08:57
Chipacawhat snap is it? here it's always been core when i've looked08:57
zygamvo, pedronis, mborzecki ^ perhaps you? (sudo losetup | grep deleted)08:58
pstolowskiChipaca: btw thanks for updating yesterday's bug ;)08:58
zygaChipaca: those that refresh08:58
zygaChipaca: I will look at adding a test for this though08:58
zygaChipaca: refresh tree times08:58
zygaChipaca: maybe that's exactly what I saw in the core 18 leak detector08:58
Chipacapstolowski: :)08:58
zygaI saw deleted revisions08:58
pstolowskiChipaca: there are more snaps than just core there08:58
zygaso maybe it's a real bug that just doesn't get measured because refreshes are not 10 a day08:58
zygapstolowski: thank you!08:58
pedroniszyga: a bunch for core08:59
zygacan you check the changes for those if you still have them08:59
zygapedronis: I assume you have high uptime08:59
zygabut that's great, it's probably easy to reproduce then08:59
pedronisI doubt, they are actuall old revisions08:59
mvozyga: none here it seems09:00
pedronis< 770009:00
zygathanks guys!09:00
mvo(just ran your command)09:00
zygathank you09:00
zygapstolowski: thanks for sharing, I was working on this anyway without realizing it is not limited to our test suite09:00
pedroniszyga: https://pastebin.ubuntu.com/p/wwXft5wyDg/09:01
zygapedronis: 18.04?09:01
pedronisyes09:01
zygaperfect, thank you09:01
mborzeckizyga: isn't this because of preserved mount namespaces?09:03
zygano09:03
zygawell09:03
zygaI don't think so09:03
zygait's more involved09:03
zygathe most surprising part is the deleted element09:03
zygabut let me write a test first09:03
mborzeckizyga: deleted seems fine to me, iirc association of a file with a loopback device is done using a file descriptor09:04
zygamborzecki: it's not fine09:04
zygaIMO09:04
zygabut let's check out little by litte09:04
zygait only happens when the parent dentry is removed AFAIR09:05
pedroniszyga: is this the highest priority thing on your plate?09:05
zygapedronis: in terms of wrapping up, it's what I was doing anyway but I was chasing logs from runs, this gives me an idea for a test to write, maybe it will uncover the bug more directly09:05
pedronismborzecki: they are not mounted anywhere09:07
zygathough there are two separate sides here, losetup deleted vs mountinfo deleted09:08
pstolowskiChipaca: do you know what's the status of https://bugs.launchpad.net/snapd/+bug/1804245 ?09:08
mupBug #1804245: empty response from store when throttled allows switch to nonexistent track <snapd:New> <https://launchpad.net/bugs/1804245>09:08
Chipacapstolowski: I think i fixed that one :-) updated the bug to reflect09:09
pstolowskigood :)09:09
Chipacai just need to confirm09:10
Chipacai was wrong i think09:11
Chipacadigging09:11
pstolowskizyga: this can be closed? https://bugs.launchpad.net/snapd/+bug/180586609:13
mupBug #1805866: On core18 system core18 snap was mounted after snapd had started <snapd:New> <https://launchpad.net/bugs/1805866>09:13
zygapstolowski: no, why?09:14
zygait's a real bug IMO09:14
pstolowskizyga: ok, it's very old, i assumed it was fixed as otherwise we would probably see it more?09:16
zygapstolowski: we don't really boot that often with services, not on classic systems09:16
pstolowskiok, fair enbough09:16
* pstolowski is stepping down from triaging job for now09:18
jameshzyga: is there anything else needed to get https://github.com/snapcore/snapd/pull/6767 merged?09:23
mupPR #6767: wrappers: allow snaps to install icon theme icons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6767>09:23
zygajamesh: no, just need to finish my review09:24
jameshzyga: okay, thanks.09:24
Chipacapstolowski: confirmed, fixed in 6ce906f7df209:27
pstolowskiChipaca: ty!09:27
Chipacaupdating the bug09:27
mupPR snapd#7396 opened: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396>09:40
zygapstolowski: I replied to https://github.com/snapcore/snapd/pull/7392#discussion_r320176487 -- let me know if that's okay in your eyes09:52
mupPR #7392: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7392>09:52
zygapstolowski: I'm happy to have a follow up09:52
pstolowskizyga: ty, replied09:57
zygawoot, thanks.09:57
mupPR snapd#7392 closed: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7392>09:58
zygais there anything we could retry that would help us?10:08
zygasnap install from the store perhaps10:08
zygaany ideas?10:08
zygathough that retries internally so perhaps no10:09
zygapstolowski: I cannot immediately reproduce the error with leaking loopback device10:09
zygaI was wondering if being base is somehow more special10:09
zygabut then the bug report did include telegram-desktop10:10
zygait may also be a more recent-ish environment (a rolling distro)10:10
zygaI'll run my test on 16.04 and look at finishing some of reviews instead10:10
zygapstolowski: ^ quiet in 739710:16
mupPR snapd#7397 opened: tests: add --quiet switch to retry-tool <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7397>10:16
pstolowskizyga: right, i couldn't repro loopback issue either. perhaps we need to observe our systems more close for some time10:17
pstolowskizyga: thanks for 7397!10:17
zygait means we are missing something though :)10:17
zygait's going to be good when we finally understand what it was10:17
zygapstolowski: I updated https://github.com/snapcore/snapd/pull/725610:21
mupPR #7256: tests: adding retry command and use it to delete $XDG directory <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256>10:21
mupPR snapd#7398 opened: boot, etc: simplify BootParticipant (etc) usage <Created by chipaca> <https://github.com/snapcore/snapd/pull/7398>10:23
mupPR snapd#7399 opened: tests: verify retry-tool not retrying missing commands <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7399>10:24
zygapstolowski: replied on https://github.com/snapcore/snapd/pull/7397#discussion_r32020063410:26
mupPR #7397: tests: add --quiet switch to retry-tool <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7397>10:26
=== pedronis_ is now known as pedronis
mborzeckipstolowski: zyga: when that happens, aren't those devices listed in nautilus sidebar too?10:31
zygamborzecki: I have *never* seen that in my sidebar on TW10:31
zygabut I did see some wonkiness in unity a while ago while using a 16.04 vm10:32
mborzeckizyga:  i have, i recall asking someone during last sprint about that :)10:32
zygammmm10:33
zygamore interesting to see what causes it10:33
mupPR snapd#7400 opened: cmd/snap-update-ns: don't propagate detaching changes <Created by zyga> <https://github.com/snapcore/snapd/pull/7400>10:35
zygamborzecki: speaking of mounting https://github.com/snapcore/snapd/pull/740010:36
mupPR #7400: cmd/snap-update-ns: don't propagate detaching changes <Created by zyga> <https://github.com/snapcore/snapd/pull/7400>10:36
zygaI'm reviving that MS_SHARED bugfix but this is something I found in that branch10:36
zygait's a bit unusual in the sense that it is a fix for something that was hidden by lack of sharing10:37
zygabut I proposed it ahead of actual sharing10:37
zygaI explain why in the PR10:37
zygaI should break for coffee and then really return to reviews or I will never get them done10:37
* Chipaca takes a break10:38
zygamborzecki, pstolowski: https://github.com/snapcore/snapd/pull/7397#discussion_r32020628110:42
pstolowskimborzecki: i think the reporter of that bug mean that when he said gnome file manager10:42
mupPR #7397: tests: add --quiet switch to retry-tool <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7397>10:42
mborzeckipstolowski: nautilus?10:43
pstolowskimborzecki: on my 18.04 box i only have cli so can't verify; on full-blown 19.04 i couldn't reproduce in my short tests10:43
pstolowskimborzecki: yes, nautilus10:43
mborzeckiwoo, it's called files now :/10:44
zygafiles :)10:44
zyganice10:44
mborzeckiand i keep on typing nau.. in the search10:44
zygauntil it becomes folders ;)10:44
zygaafter coffee / reviews I'll change my test to refresh bases while running various apps10:44
zygaand see what happens then10:44
zygapstolowski: trivial quickie https://github.com/snapcore/snapd/pull/739910:46
mupPR #7399: tests: verify retry-tool not retrying missing commands <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7399>10:46
zygathis is also pretty obvious but I was unsure if there are any side effects10:46
zygahttps://github.com/snapcore/snapd/pull/739610:46
mupPR #7396: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396>10:46
zygathough it feels like the original code was just buggy anyway10:46
zygamborzecki: is my reasoning correct? https://github.com/snapcore/snapd/pull/7396#discussion_r32020807510:47
mupPR #7396: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396>10:47
zygamvo: can you please finish the review of https://github.com/snapcore/snapd/pull/736210:48
mupPR #7362: cmd: unify die() across C programs <Created by zyga> <https://github.com/snapcore/snapd/pull/7362>10:48
* zyga breaks11:00
pstolowskigood idea11:08
* pstolowski lunch11:08
pstolowskipedronis: #7092 seems to be happy11:39
mupPR #7092: packaging: use snapd type and snapcraft 3.x <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7092>11:39
* Chipaca goes for lunch11:44
mvo6705 needs a second review now11:48
mvozyga: will do after lunch11:49
mborzeckizyga: updated #738711:54
mupPR #7387: packaging/fedora, tests/lib/prepare-restore: helper tool for packing sources for RPM <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7387>11:54
pedronisChipaca: comment on #739811:57
mupPR #7398: boot, etc: simplify BootParticipant (etc) usage <Created by chipaca> <https://github.com/snapcore/snapd/pull/7398>11:57
pedronis*commented11:57
mborzeckizyga: duh, mounts do not look nice when there's more snaps installed https://paste.ubuntu.com/p/BHvpFx7P3X/12:13
mborzeckizyga: ok, updated #7302 too12:23
mupPR #7302: cmd/snap-confine: add support for parallel instances of classic snaps <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7302>12:23
mupPR pc-amd64-gadget#19 closed: UC20 spike changes <Created by cmatsuoka> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/19>12:36
cachiomvo, pedronis  I need to skip the standup, perhaps arriving late but not sure, forgot I had a meeting in the school12:37
zygamborzecki: seeing double :)12:37
zygamborzecki: I have an idea about that12:37
zygamborzecki: but in the evening after round of reviews12:37
zygamborzecki: for tomorrow, ok?12:37
ograjdstrand, i have a problem ... trying to use a DHT11 sensor (temp/humidity) and output to an OLED display on a Pi3 with https://github.com/adafruit/Adafruit_Python_DHT ... i end up with https://paste.ubuntu.com/p/Z7PDBTCjkb/ ... could we add these paths to "hardware-observe" ?12:58
Chipacapedronis: interesting comments12:59
rbasakI'm using Docker to run snapcraft inside Travis. Is there anything I need to do to switch to using core18?13:17
rbasakCurrently I'm doing: docker run -v $(pwd):$(pwd) -t snapcore/snapcraft sh -c "apt-get update -qq && apt-get install -qq git && cd $(pwd) && snapcraft"13:17
rbasakI'm wondering if I need to use a different Docker image based on Bionic?13:17
Chipacarbasak: use core18 for what?13:17
Chipacadoes snapcraft in docker not use multipass?13:17
* Chipaca doesn't know13:18
Chipacai imagine not, in which case yeah you'd need a bionic image13:18
rbasakChipaca: to base my snap on core18 I mean. Ie. "base: core18" in snapcraft.yaml AIUI. Yes - that's what I was thinking.13:19
rbasakIs there a published snapcraft-that-uses-bionic image?13:19
Chipacarbasak: I don't know. Maybe sergiusens does?13:26
zygacmatsuoka: can this land? https://github.com/snapcore/snapd/pull/726613:51
mupPR #7266:  recovery: update run mode variable name <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7266>13:51
cmatsuokazyga: on the uc20 branch, yes13:52
cmatsuokazyga: thanks13:52
zygacachio: hey, I pushed into the XDG branch of yours14:00
zygacachio: I also opened something small for your consideration: https://github.com/snapcore/snapd/pull/739614:00
mupPR #7396: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396>14:00
cachiozyga, nice, thanks14:00
jdstrandogra: it is likely fine. they are binary files. add to the list for the next round. thanks!14:00
jdstrandadded*14:01
zygajdstrand: hello :)14:01
jdstrandzyga: hi :)14:01
ograjdstrand, thanks !14:01
ijohnsonrbasak: there is not, you will need to roll your own docker image14:02
ijohnsonrbasak: if you're building on travis, it is probably much easier for you to just build with lxd and call snapcraft from your job definition directly, travis supports running snapcraft as a snap and lxd as a snp14:03
rbasakijohnson: OK, thanks.14:06
rbasakijohnson: do you know of any examples?14:06
ijohnsonrbasak, sure one minute14:06
ijohnsonrbasak: take a look at one of the snapcrafters snaps at https://github.com/snapcrafters/sdlpop/blob/master/.travis.yml14:07
rbasakijohnson: that's great. Thank you!14:08
cachiozyga, #7256 needs a +114:13
mupPR #7256: tests: adding retry command and use it to delete $XDG directory <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256>14:13
cachiopstolowski, could you please take a quick look to #725614:13
pstolowskicachio: yes14:15
cachiopstolowski, tx14:15
pstolowskicachio: looks good but as i said in earlier comment i think we should wait for it to fail again an see if #7336 shows anything interesting14:16
mupPR #7336: tests: add debug section to interfaces-contacts-service <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7336>14:16
roadmrjdstrand: hi are you around? I have a question :) {"docker": {"allow-auto-connection": "true"} <- this implies allow-installation, right? so a snap with this in the plugs section should automatically pass review, not be held with human review required due to 'allow-installation' constraint (bool) declaration-snap-v2_plugs_installation (docker, docker)14:22
cachiopstolowski, ok, I'll try to force the error14:23
cachiopstolowski, otherwise it will take too much time14:24
pstolowskicachio: force how?14:24
cachiopstolowski, retrying execution14:24
cachiountil it fails14:24
pstolowskicachio: ok14:24
cachioand praying14:25
cachioheheehe14:25
pstolowskiheh14:25
jdstrandroadmr: it does not imply allow-installation14:25
roadmrjdstrand: ah, ok. That makes sense14:26
pedronisit does for snapd14:26
jdstrandroadmr: in snapd, auto-connection, connection and installation are all separate from each other. the review-tools only look at auto-connection and installation for when to manual review14:26
roadmrjdstrand: did this change? did it imply installation?14:26
pedronisit doesn't respect the conventions though14:26
jdstrandroadmr: nothing has changed for months14:27
roadmrjdstrand: (context, someone is saying that a snap for which they have the above used to pass automated review but then started failing14:27
roadmr)14:27
jdstrandroadmr: right, months ago it was discovered that we weren't prompting for manual review for the docker interface when we should have. it changed then14:27
jdstrandroadmr: there were a handful of snaps that were affected. they must not have uploaded anything in a while14:28
roadmrjdstrand: like, 2 months ago? we narrowed the transition down to "2019-06-17 13:55 - 2 months, 2 weeks ago"14:28
roadmrjdstrand: perfect, that explains it :) do you mind if I give them allow-installation? this is a snap in a brand store and they'd been using docker previously14:28
jdstrandroadmr: 693121ef4ad15a0642967d5f7af69e52c1b8969d. Feb 1514:29
roadmroh that's more than 2 months ago :)14:29
jdstrandpedronis: I guess it makes sense that allow-auto-connection implies installation as a practical matter, but that is not how we initially designed the feature. do you recall when that changed?14:31
nessitaroadmr, the date would be relevant for our bump of review tools though, not necessarily when the review tools changed14:32
nessita(hi all!)14:32
pedronisjdstrand: it's always been like this14:32
jdstrandpedronis: oh, you mean because if it has nothing to say about installation, it is allowed14:33
pedronisyes14:33
roadmrnessita: indeed, but the gap is still puzzling - we certainly updated the tools between February and June, so it's weird this only started happening in June if the change was in the tools since Feb14:33
nessitaroadmr, right14:33
nessitaroadmr, have you, by any chance, downloaded the two revisions to compare if they changed anything in their manifest?14:34
roadmrnessita: nope14:35
jdstrandpedronis: right. that is different than auto-connection affecting installation if something does have something to say about it, which is what I meant14:35
jdstrandanyhoo, yes14:35
jdstrandroadmr: can you paste me their snap.yaml?14:38
roadmrjdstrand: sure, incoming14:38
roadmrjdstrand: https://pastebin.canonical.com/p/WJyNTTKQ8X/14:39
ackkhi, testing with the confined maas snap and snapd 2.41, I'm getting https://paste.ubuntu.com/p/cJxN7B4KpP/ all of a sudden, what could it be related to?14:39
zygaackk: woah14:40
zygaackk: is it /root?14:40
ackkzyga, what is?14:40
zygaI think it might be confused by root :)14:40
zygaackk: there's a check that $HOME is not something crazy14:40
zygaackk: but it may not capture /root14:40
ackkzyga, yeah "maas --help" works but "sudo maas --help" doesn't14:40
zygaChipaca: ^ is that us?14:40
zygaChipaca: if so that's a regression14:41
* jdstrand notes that when to manual review is a different question than when to apply at install time14:41
zygamvo: ^14:41
ackkzyga, oddly, I had just run "sudo maas init" a little before, and that must have worked14:41
zygahuh14:41
zygathat's more mysterious14:41
ackklemme try a reproducer14:41
mvozyga: thanks, in a meeting14:41
zygaack14:41
Chipacaackk: what distro?14:41
zygaackk: thank you14:41
ackkChipaca, bionic14:41
mvozyga: but thanks for the heads up, please keep me updated about your finidings14:41
Chipacasudo's path should have /snap/bin on it14:42
mvomight be the new systemd generator?14:42
Chipaca(some distros have it in bash but not in sudo which is weird)14:42
Chipacaugh14:42
zygahttps://github.com/snapcore/snapd/blob/fa465e97df3b159f18c77786cdc540d2cdcd29d5/cmd/snap-confine/user-support.c#L4414:42
mvowhich went in with 2.41 but only in the debs14:42
ackkChipaca, I'm pretty sure cloud images don't14:42
Chipacaackk: don't what?14:42
ackkChipaca, I'm in a lxd14:42
ackkdon't have /snap/bin in path14:43
ackkat least, not for root14:43
ackkoh actually it seems they do now14:43
Chipacaackk: in 'sudo visudo', you should see /snap/bin in 'secure_path'14:43
zygaI just shut down my desktop14:43
zygabut https://github.com/snapcore/snapd/commit/634a17c85718f15babe9fbe3cd85a36225bcfdd314:43
zygait could be a good attempt to add a /root home directory there to see what happenns (in spread test)14:44
Chipacaackk: maybe you installed snapd, and didn't re-login?14:44
ackkChipaca, it's there14:44
ackkChipaca, nope, that's not a fresh container14:44
ackkI'm testing now in a fresh one, see if I can reproduce14:44
jdstrandroadmr: because of that ^ the tools look at the slots side for both *for slots that specifiy an installation constraint in the base decl*. the base decl convention for docker here is that a slot implementation may provide a so-called superprivileged interface but another impl of the same slot might not. again, change was intentional14:46
roadmrjdstrand: ah ok - got it14:47
ackkChipaca, I did relogin just now fwiw, no difference14:47
jdstrandroadmr: oh, and the review-tools error is correct for that snap.yaml14:48
jdstrands/correct/expected/14:48
roadmrawesome :) yes, just looks like behavior changed here and we didn't update the PD - I'll add allow-installation for them14:49
roadmr(behavior changed expectedly as you explained)14:49
jdstrandcool, thanks14:49
roadmrthank you for explaining :)14:49
roadmrI mean, it was pretty clear we needed to add allow-installation, the message says as much and fwiw I usually add both anyway - just wanted to understand why this changed14:50
jdstrandroadmr: speaking of the review-tools, can you pull 20190829-1435UTC? not urgent. only meaningful change for the store is sr_lint.py: improve error message with invalid Icon paths15:06
roadmrjdstrand: sure thing!15:06
jdstrandthanks :)15:07
ppd1990jdstrand: Hi, I'd be glad if you could weigh in on #7366 in the near future :) Am still in the office for a few hours with a little spare time for possible changes15:19
mupPR #7366: interfaces/gpg-keys: Allow access to gpg-agent and creation of lockfiles <Created by ppd1990> <https://github.com/snapcore/snapd/pull/7366>15:19
* cachio lunch15:20
dokomvo: snapcraft autopkg test regressions in eoan15:21
jdstrandppd1990: yes, it is on my list for today. note there is some history that I need to dig up for why it is the way it is15:23
mvodoko: hey, thanks for the heads up - sergiusens will take care of it I'm sure!15:29
dokomvo: well, it would be nice if the snappy team would notice these regressions on their own  by default ...15:32
mvodoko: right, I hear you and we try to be responsive. snapcraft is a different team though,15:34
popey_sergiusens: ^ see comments from doko15:40
mvosecond review for 6705 would be great btw15:43
mvoackk, zyga, Chipaca still in meetings - is there a tl;dr on this potential regression?15:59
zygamvo: no, I took a break but I just stopped and writing a quick regression test16:00
ackkmvo, I don't have a clean reproducer but it seems related to the fact that I was ending up running snapcraft --destructive-mode with the snap mounted from the prime dir, so maybe that ends up confusing snapd?16:00
mvota16:00
mvothanks! please keep me updated, if it turns out to be a regression I want to know as soon as possible16:01
zygamvo: understood, sorry for lagging16:01
mvozyga: no worries! it was not meant as being pushy :)16:03
rbasakWhat's the production status of core18? https://forum.snapcraft.io/t/ubuntu-core-18/5169 suggests it's experimental?16:04
popey_rbasak: that's a very old post16:04
rbasakIt's the second hit for "snap core18" on Google.16:04
rbasakThe first hit goes to the store page which doesn't answer my question.16:05
pedronismvo: I will look at #6705 in my morning, slightly surprised by Chipaca's comments on it16:05
rbasakI can't find any announcement that says that core18 is production now?16:05
mupPR #6705: bootloader: little kernel support <Needs Samuele review> <Created by kubiko> <https://github.com/snapcore/snapd/pull/6705>16:05
ChipacaI will go for a run now and stop surprising people16:06
mvoChipaca: enjoy!16:06
zygaChipaca: +116:06
mvopedronis: I will fix the things that john mentioned, its a good point16:07
mvo(good points)16:07
zygaackk: hey16:07
zygastill around?16:07
zygaackk: what does "sudo env" say in that machine where it happened?16:08
zygaackk: feel free to paste in private if sensitive16:08
cwaynerbasak: https://ubuntu.com/blog/ubuntu-core-18-released-for-secure-reliable-iot-devices16:09
cwaynetop of https://ubuntu.com/core too16:09
rbasakcwayne: great. Thanks!16:09
cwaynenp :)16:09
mupPR snapd#7399 closed: tests: verify retry-tool not retrying missing commands <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7399>16:10
ackkzyga, https://paste.ubuntu.com/p/gDNq93zrPC/16:11
zygaackk: can you walk me through a case16:11
zygaackk: this is inside a container, correct?16:12
ackkzyga, yes16:12
zygaackk: how do you access the host of the container, via ssh?16:12
zygaackk: when you access the container, how do you "jump into" it, via lxc shell?16:12
ackkzyga, via ssh, but I have my home bind-mounted in the container, so I ssh with the same user16:13
zygaackk: bind mounted from the host of the container?16:13
zygaackk: so you ssh into (guest) from (host) or from a different machine?16:13
ackkzyga, https://paste.ubuntu.com/p/XNq6w2sVGQ/16:13
ackkzyga, no, ssh from my laptop to the lxd on it16:14
zygaackk: so (3rd computer) -> (guest) directly, via ssh?16:14
ackkzyga, why 3rd computer? the containres are on my laptop as well16:16
zygaah, I understand now16:16
zygaso you ssh from the laptop, which is the host, directly into the container16:17
ackkzyga, correct16:17
zygaackk: and inside the container, so in (guest), the user ack exists because it was added manually?16:17
ackkzyga, yes16:18
zygaackk: and when you run sudo maas, snap-confine complains and quits16:18
zygaackk: this is on 2.41 from the archive?16:19
ackkzyga, 2.41 snapd snap16:19
ackkfrom beta16:19
zygaaha, the snapd snap16:19
zygaok, thank you16:19
zygalet me check stuff16:19
zygacan you run one simple test16:19
zygasnap install snapd-hacker-toolbelt16:19
zygaand see if that works16:19
zygait's just a busybox snap16:19
ackkzyga, so, also the issue doesn't happen right away as I mentioned before. I have the snap installed via snap try, but was then running a sync target which ended up calling snapcraft again16:20
ackkzyga, sure16:20
ackkzyga, just run it?16:20
zygayeah16:20
zygaso maas is in try mode?16:20
ackkzyga, yes16:21
zygawhat is a sync target?16:21
ackkzyga, (that snap works fwiw)16:21
zygaackk: can you try to unsquashfs snapd-hacker-toolbelt, edit it anyway you like (it's a static binary),16:22
zygaackk: install it in try mode16:22
ackkzyga, so we have a makefile target that updates the prime/ dir based on the tree, so you can change code and have it copied. but that because of a recent change ended up calling "snapcraft --destructive-mode prime" again16:22
zygaand see if you can reproduce the issue somehow16:22
ackkzyga, it seems after that the snap had the issue16:22
zygaso there are two aspects16:23
zygathe message we saw indicates that we failed16:23
zygathe details only change the error message printed16:23
zygaso even if /root was handled in that logic, it would at most affect the failure message16:23
zygathe reason we saw that particular message is that we got EROFS16:24
zygaso we attempted to create a directory but got an EROFS error from the system16:24
zygawe can strace that to see what exactly failed16:24
zygaackk: actually16:24
zygaackk: if you can still reproduce it16:24
zygaplease set SNAP_CONFINE_DEBUG=yes16:24
zygaand run that command again16:24
ackkzyga, where in the calling shell?16:24
zygathat will tell us all the details without the need of strace16:24
zygaackk: after sudo16:24
zygasudo SNAP_CONFINE_DEBUG=yes maas --help16:25
ackkoh ok, I don't have it right now but will try to reproduce tomorrow16:25
zygaackk: so whatever really happened, it seems something has switched your home directory, or /root to read only mode16:25
=== pstolowski is now known as pstolowski|afk
mupPR snapcraft#2695 closed: spread tests: install package marker into ament index <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2695>16:55
jdstrandroadmr: sorry, can you pull 20190903-1746UTC? not terribly urgent, just an update to an override for core2017:47
jdstrandxnox: fyi ^17:48
roadmrjdstrand: sure, her it goes18:13
jdstrandroadmr: thanks!19:31
sergiusensdoko: mvo I did an upload last week and it was all green20:05
mupPR snapcraft#2697 opened: Neon extension <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2697>20:08
mupPR snapd#7401 opened: tests: add unstable stage for travis execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7401>20:18
diddledanyootoobe: https://youtu.be/cWlYe0CE2iU22:10
mupPR snapd#7402 opened: daemon, client, cmd/snap: include architecture in 'snap version' <Created by chipaca> <https://github.com/snapcore/snapd/pull/7402>22:15

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