| mborzecki | morning | 04:52 |
|---|---|---|
| zyga | Good morning | 05:04 |
| mborzecki | zyga: kids already at school, yay ;) | 05:05 |
| zyga | mborzecki: oldest just went to school | 05:15 |
| zyga | mborzecki: middle one finished breakfast | 05:15 |
| zyga | mborzecki: youngest one plays with her toys :) | 05:15 |
| zyga | mborzecki: our son is 170 now | 05:15 |
| zyga | he's not even 13 | 05:15 |
| zyga | mborzecki: easy landing for the morning https://github.com/snapcore/snapd/pull/7218#pullrequestreview-272716535 | 05:15 |
| zyga | mborzecki: I added the extra checks you asked for | 05:16 |
| mup | PR #7218: tests: measure behavior of the device cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/7218> | 05:16 |
| mborzecki | and it's green :) | 05:16 |
| zyga | woot, thankyou | 05:17 |
| zyga | another easy ish is https://github.com/snapcore/snapd/pull/7392 | 05:17 |
| mup | PR #7392: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7392> | 05:17 |
| zyga | needs 2nd +1 | 05:17 |
| zyga | also green | 05:17 |
| mup | PR 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 |
| zyga | mborzecki: one more kid to walk to school, ttyl | 05:29 |
| zyga | back now | 06:00 |
| mborzecki | mvo: morning | 06:30 |
| mvo | hey mborzecki | 06:32 |
| zyga | good morning mvo | 06:36 |
| zyga | mvo: one more review if I can grab your attention :) | 06:36 |
| zyga | https://github.com/snapcore/snapd/pull/7392 | 06:36 |
| mup | PR #7392: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7392> | 06:36 |
| zyga | mborzecki: let's start chopping your classic mount namespace PR as we discussed in private | 06:37 |
| zyga | it will help with the review and will help with figuring out what is wrong | 06:37 |
| mvo | hey zyga | 06:37 |
| zyga | :-) | 06:38 |
| zyga | mvo: do you know who is the upstream of command-not-found nowadays? | 06:39 |
| mvo | zyga: foundations, why? | 06:42 |
| zyga | mvo: I have some patches | 06:42 |
| mborzecki | mvo: zyga: #7393 really simple | 06:47 |
| mup | PR 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 |
| mup | PR #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 |
| zyga | mborzecki: +1 | 06:48 |
| mborzecki | thx | 06:48 |
| mup | PR 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 | ||
| pstolowski | morning | 07:05 |
| zyga | good morning pawel! | 07:05 |
| pedronis | pstolowski: hi, what's the status of #7277 ? | 07:11 |
| mup | PR #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/7381 | 07:12 | |
| mup | PR #7381: seed,image,o/devicestate: extract seed loading to seed/seed16.go <Created by pedronis> <https://github.com/snapcore/snapd/pull/7381> | 07:12 |
| zyga | great for rainy morning focus :) | 07:13 |
| pstolowski | pedronis: 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 while | 07:23 |
| mborzecki | pstolowski: pedronis: hi | 07:26 |
| pedronis | pstolowski: 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 have | 07:26 |
| pedronis | and also not great time given uc20 work | 07:26 |
| pstolowski | pedronis: ack, going to look at it today | 07:28 |
| zyga | is it just me or is github not responding very well now? | 07:32 |
| mup | PR 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 break | 07:43 | |
| mup | PR 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 |
| Chipaca | zyga: ping | 08:38 |
| zyga | hey | 08:38 |
| Chipaca | zyga: hiya | 08:39 |
| Chipaca | zyga: what's the purpose of osutil.MountOptsToFlags ? | 08:40 |
| Chipaca | it seems very sensible, but it's not used -- instead, the unchecked MountOptsToCommonFlags is used | 08:40 |
| zyga | let me look | 08:41 |
| Chipaca | k | 08:41 |
| Chipaca | not going to change it, but it caught my attention | 08:41 |
| Chipaca | (i'm fixing compilation on darwin) | 08:41 |
| zyga | ah, | 08:42 |
| zyga | I see it now | 08:42 |
| zyga | it's the layer on top of common flags that understands x-snapd and filters them out but errors on unknown flags | 08:42 |
| zyga | let me look at that | 08:42 |
| zyga | thanks! | 08:42 |
| Chipaca | zyga: np! tbh it looks like the Common one should be private, if i understand the difference | 08:43 |
| zyga | if 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 mount | 08:44 |
| mup | PR 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 |
| zyga | so I think the strict version is just unused and could be removed | 08:44 |
| pstolowski | zyga: any thoughs on https://bugs.launchpad.net/snapd/+bug/1841137 ? | 08:50 |
| mup | Bug #1841137: /dev/loopX devices left around for removed snap revisions <snapd:Triaged> <https://launchpad.net/bugs/1841137> | 08:50 |
| zyga | pstolowski: oooh | 08:53 |
| zyga | interesting | 08:53 |
| pstolowski | zyga: garbage collection gone wrong? | 08:54 |
| zyga | there's no garbage collection, it's explicitly managed malloc/free style | 08:54 |
| zyga | the deleted aspect is super puzzling! | 08:54 |
| pstolowski | zyga: i mean gc in the sense of removing old revisions automatically | 08:55 |
| zyga | pstolowski: nitpick: triaged literally means: we know the severity | 08:55 |
| zyga | setting it to triaged without setting one is weird | 08:55 |
| zyga | pstolowski: normally mount does that | 08:55 |
| zyga | pstolowski: libmount removes loopback devices | 08:55 |
| Chipaca | agreed about triaged | 08:56 |
| zyga | since I just rebooted | 08:56 |
| Chipaca | if you don't know the severity it's confirmed, not triaged :-) | 08:56 |
| zyga | can everyone with a longer uptime run: sudo losetup | grep deleted | 08:56 |
| zyga | and see if it shows anything | 08:56 |
| Chipaca | nothing right now but i have seen them before | 08:56 |
| Chipaca | that's when they appear in unity | 08:57 |
| Chipaca | i didn't know it was noteworthy :-) | 08:57 |
| zyga | that's super curious | 08:57 |
| zyga | I wonder if that's another lowlevel bug in kernel/libmount/systemd | 08:57 |
| zyga | normally systemd doesn't handle those so more likely in libmount | 08:57 |
| pstolowski | Chipaca, zyga noted, thanks :) | 08:57 |
| Chipaca | what snap is it? here it's always been core when i've looked | 08:57 |
| zyga | mvo, pedronis, mborzecki ^ perhaps you? (sudo losetup | grep deleted) | 08:58 |
| pstolowski | Chipaca: btw thanks for updating yesterday's bug ;) | 08:58 |
| zyga | Chipaca: those that refresh | 08:58 |
| zyga | Chipaca: I will look at adding a test for this though | 08:58 |
| zyga | Chipaca: refresh tree times | 08:58 |
| zyga | Chipaca: maybe that's exactly what I saw in the core 18 leak detector | 08:58 |
| Chipaca | pstolowski: :) | 08:58 |
| zyga | I saw deleted revisions | 08:58 |
| pstolowski | Chipaca: there are more snaps than just core there | 08:58 |
| zyga | so maybe it's a real bug that just doesn't get measured because refreshes are not 10 a day | 08:58 |
| zyga | pstolowski: thank you! | 08:58 |
| pedronis | zyga: a bunch for core | 08:59 |
| zyga | can you check the changes for those if you still have them | 08:59 |
| zyga | pedronis: I assume you have high uptime | 08:59 |
| zyga | but that's great, it's probably easy to reproduce then | 08:59 |
| pedronis | I doubt, they are actuall old revisions | 08:59 |
| mvo | zyga: none here it seems | 09:00 |
| pedronis | < 7700 | 09:00 |
| zyga | thanks guys! | 09:00 |
| mvo | (just ran your command) | 09:00 |
| zyga | thank you | 09:00 |
| zyga | pstolowski: thanks for sharing, I was working on this anyway without realizing it is not limited to our test suite | 09:00 |
| pedronis | zyga: https://pastebin.ubuntu.com/p/wwXft5wyDg/ | 09:01 |
| zyga | pedronis: 18.04? | 09:01 |
| pedronis | yes | 09:01 |
| zyga | perfect, thank you | 09:01 |
| mborzecki | zyga: isn't this because of preserved mount namespaces? | 09:03 |
| zyga | no | 09:03 |
| zyga | well | 09:03 |
| zyga | I don't think so | 09:03 |
| zyga | it's more involved | 09:03 |
| zyga | the most surprising part is the deleted element | 09:03 |
| zyga | but let me write a test first | 09:03 |
| mborzecki | zyga: deleted seems fine to me, iirc association of a file with a loopback device is done using a file descriptor | 09:04 |
| zyga | mborzecki: it's not fine | 09:04 |
| zyga | IMO | 09:04 |
| zyga | but let's check out little by litte | 09:04 |
| zyga | it only happens when the parent dentry is removed AFAIR | 09:05 |
| pedronis | zyga: is this the highest priority thing on your plate? | 09:05 |
| zyga | pedronis: 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 directly | 09:05 |
| pedronis | mborzecki: they are not mounted anywhere | 09:07 |
| zyga | though there are two separate sides here, losetup deleted vs mountinfo deleted | 09:08 |
| pstolowski | Chipaca: do you know what's the status of https://bugs.launchpad.net/snapd/+bug/1804245 ? | 09:08 |
| mup | Bug #1804245: empty response from store when throttled allows switch to nonexistent track <snapd:New> <https://launchpad.net/bugs/1804245> | 09:08 |
| Chipaca | pstolowski: I think i fixed that one :-) updated the bug to reflect | 09:09 |
| pstolowski | good :) | 09:09 |
| Chipaca | i just need to confirm | 09:10 |
| Chipaca | i was wrong i think | 09:11 |
| Chipaca | digging | 09:11 |
| pstolowski | zyga: this can be closed? https://bugs.launchpad.net/snapd/+bug/1805866 | 09:13 |
| mup | Bug #1805866: On core18 system core18 snap was mounted after snapd had started <snapd:New> <https://launchpad.net/bugs/1805866> | 09:13 |
| zyga | pstolowski: no, why? | 09:14 |
| zyga | it's a real bug IMO | 09:14 |
| pstolowski | zyga: ok, it's very old, i assumed it was fixed as otherwise we would probably see it more? | 09:16 |
| zyga | pstolowski: we don't really boot that often with services, not on classic systems | 09:16 |
| pstolowski | ok, fair enbough | 09:16 |
| * pstolowski is stepping down from triaging job for now | 09:18 | |
| jamesh | zyga: is there anything else needed to get https://github.com/snapcore/snapd/pull/6767 merged? | 09:23 |
| mup | PR #6767: wrappers: allow snaps to install icon theme icons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6767> | 09:23 |
| zyga | jamesh: no, just need to finish my review | 09:24 |
| jamesh | zyga: okay, thanks. | 09:24 |
| Chipaca | pstolowski: confirmed, fixed in 6ce906f7df2 | 09:27 |
| pstolowski | Chipaca: ty! | 09:27 |
| Chipaca | updating the bug | 09:27 |
| mup | PR snapd#7396 opened: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396> | 09:40 |
| zyga | pstolowski: I replied to https://github.com/snapcore/snapd/pull/7392#discussion_r320176487 -- let me know if that's okay in your eyes | 09:52 |
| mup | PR #7392: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7392> | 09:52 |
| zyga | pstolowski: I'm happy to have a follow up | 09:52 |
| pstolowski | zyga: ty, replied | 09:57 |
| zyga | woot, thanks. | 09:57 |
| mup | PR 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 |
| zyga | is there anything we could retry that would help us? | 10:08 |
| zyga | snap install from the store perhaps | 10:08 |
| zyga | any ideas? | 10:08 |
| zyga | though that retries internally so perhaps no | 10:09 |
| zyga | pstolowski: I cannot immediately reproduce the error with leaking loopback device | 10:09 |
| zyga | I was wondering if being base is somehow more special | 10:09 |
| zyga | but then the bug report did include telegram-desktop | 10:10 |
| zyga | it may also be a more recent-ish environment (a rolling distro) | 10:10 |
| zyga | I'll run my test on 16.04 and look at finishing some of reviews instead | 10:10 |
| zyga | pstolowski: ^ quiet in 7397 | 10:16 |
| mup | PR snapd#7397 opened: tests: add --quiet switch to retry-tool <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7397> | 10:16 |
| pstolowski | zyga: right, i couldn't repro loopback issue either. perhaps we need to observe our systems more close for some time | 10:17 |
| pstolowski | zyga: thanks for 7397! | 10:17 |
| zyga | it means we are missing something though :) | 10:17 |
| zyga | it's going to be good when we finally understand what it was | 10:17 |
| zyga | pstolowski: I updated https://github.com/snapcore/snapd/pull/7256 | 10:21 |
| mup | PR #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 |
| mup | PR snapd#7398 opened: boot, etc: simplify BootParticipant (etc) usage <Created by chipaca> <https://github.com/snapcore/snapd/pull/7398> | 10:23 |
| mup | PR snapd#7399 opened: tests: verify retry-tool not retrying missing commands <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7399> | 10:24 |
| zyga | pstolowski: replied on https://github.com/snapcore/snapd/pull/7397#discussion_r320200634 | 10:26 |
| mup | PR #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 | ||
| mborzecki | pstolowski: zyga: when that happens, aren't those devices listed in nautilus sidebar too? | 10:31 |
| zyga | mborzecki: I have *never* seen that in my sidebar on TW | 10:31 |
| zyga | but I did see some wonkiness in unity a while ago while using a 16.04 vm | 10:32 |
| mborzecki | zyga: i have, i recall asking someone during last sprint about that :) | 10:32 |
| zyga | mmmm | 10:33 |
| zyga | more interesting to see what causes it | 10:33 |
| mup | PR snapd#7400 opened: cmd/snap-update-ns: don't propagate detaching changes <Created by zyga> <https://github.com/snapcore/snapd/pull/7400> | 10:35 |
| zyga | mborzecki: speaking of mounting https://github.com/snapcore/snapd/pull/7400 | 10:36 |
| mup | PR #7400: cmd/snap-update-ns: don't propagate detaching changes <Created by zyga> <https://github.com/snapcore/snapd/pull/7400> | 10:36 |
| zyga | I'm reviving that MS_SHARED bugfix but this is something I found in that branch | 10:36 |
| zyga | it's a bit unusual in the sense that it is a fix for something that was hidden by lack of sharing | 10:37 |
| zyga | but I proposed it ahead of actual sharing | 10:37 |
| zyga | I explain why in the PR | 10:37 |
| zyga | I should break for coffee and then really return to reviews or I will never get them done | 10:37 |
| * Chipaca takes a break | 10:38 | |
| zyga | mborzecki, pstolowski: https://github.com/snapcore/snapd/pull/7397#discussion_r320206281 | 10:42 |
| pstolowski | mborzecki: i think the reporter of that bug mean that when he said gnome file manager | 10:42 |
| mup | PR #7397: tests: add --quiet switch to retry-tool <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7397> | 10:42 |
| mborzecki | pstolowski: nautilus? | 10:43 |
| pstolowski | mborzecki: 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 tests | 10:43 |
| pstolowski | mborzecki: yes, nautilus | 10:43 |
| mborzecki | woo, it's called files now :/ | 10:44 |
| zyga | files :) | 10:44 |
| zyga | nice | 10:44 |
| mborzecki | and i keep on typing nau.. in the search | 10:44 |
| zyga | until it becomes folders ;) | 10:44 |
| zyga | after coffee / reviews I'll change my test to refresh bases while running various apps | 10:44 |
| zyga | and see what happens then | 10:44 |
| zyga | pstolowski: trivial quickie https://github.com/snapcore/snapd/pull/7399 | 10:46 |
| mup | PR #7399: tests: verify retry-tool not retrying missing commands <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7399> | 10:46 |
| zyga | this is also pretty obvious but I was unsure if there are any side effects | 10:46 |
| zyga | https://github.com/snapcore/snapd/pull/7396 | 10:46 |
| mup | PR #7396: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396> | 10:46 |
| zyga | though it feels like the original code was just buggy anyway | 10:46 |
| zyga | mborzecki: is my reasoning correct? https://github.com/snapcore/snapd/pull/7396#discussion_r320208075 | 10:47 |
| mup | PR #7396: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396> | 10:47 |
| zyga | mvo: can you please finish the review of https://github.com/snapcore/snapd/pull/7362 | 10:48 |
| mup | PR #7362: cmd: unify die() across C programs <Created by zyga> <https://github.com/snapcore/snapd/pull/7362> | 10:48 |
| * zyga breaks | 11:00 | |
| pstolowski | good idea | 11:08 |
| * pstolowski lunch | 11:08 | |
| pstolowski | pedronis: #7092 seems to be happy | 11:39 |
| mup | PR #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 lunch | 11:44 | |
| mvo | 6705 needs a second review now | 11:48 |
| mvo | zyga: will do after lunch | 11:49 |
| mborzecki | zyga: updated #7387 | 11:54 |
| mup | PR #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 |
| pedronis | Chipaca: comment on #7398 | 11:57 |
| mup | PR #7398: boot, etc: simplify BootParticipant (etc) usage <Created by chipaca> <https://github.com/snapcore/snapd/pull/7398> | 11:57 |
| pedronis | *commented | 11:57 |
| mborzecki | zyga: duh, mounts do not look nice when there's more snaps installed https://paste.ubuntu.com/p/BHvpFx7P3X/ | 12:13 |
| mborzecki | zyga: ok, updated #7302 too | 12:23 |
| mup | PR #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 |
| mup | PR 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 |
| cachio | mvo, pedronis I need to skip the standup, perhaps arriving late but not sure, forgot I had a meeting in the school | 12:37 |
| zyga | mborzecki: seeing double :) | 12:37 |
| zyga | mborzecki: I have an idea about that | 12:37 |
| zyga | mborzecki: but in the evening after round of reviews | 12:37 |
| zyga | mborzecki: for tomorrow, ok? | 12:37 |
| ogra | jdstrand, 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 |
| Chipaca | pedronis: interesting comments | 12:59 |
| rbasak | I'm using Docker to run snapcraft inside Travis. Is there anything I need to do to switch to using core18? | 13:17 |
| rbasak | Currently 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 |
| rbasak | I'm wondering if I need to use a different Docker image based on Bionic? | 13:17 |
| Chipaca | rbasak: use core18 for what? | 13:17 |
| Chipaca | does snapcraft in docker not use multipass? | 13:17 |
| * Chipaca doesn't know | 13:18 | |
| Chipaca | i imagine not, in which case yeah you'd need a bionic image | 13:18 |
| rbasak | Chipaca: to base my snap on core18 I mean. Ie. "base: core18" in snapcraft.yaml AIUI. Yes - that's what I was thinking. | 13:19 |
| rbasak | Is there a published snapcraft-that-uses-bionic image? | 13:19 |
| Chipaca | rbasak: I don't know. Maybe sergiusens does? | 13:26 |
| zyga | cmatsuoka: can this land? https://github.com/snapcore/snapd/pull/7266 | 13:51 |
| mup | PR #7266: recovery: update run mode variable name <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7266> | 13:51 |
| cmatsuoka | zyga: on the uc20 branch, yes | 13:52 |
| cmatsuoka | zyga: thanks | 13:52 |
| zyga | cachio: hey, I pushed into the XDG branch of yours | 14:00 |
| zyga | cachio: I also opened something small for your consideration: https://github.com/snapcore/snapd/pull/7396 | 14:00 |
| mup | PR #7396: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396> | 14:00 |
| cachio | zyga, nice, thanks | 14:00 |
| jdstrand | ogra: it is likely fine. they are binary files. add to the list for the next round. thanks! | 14:00 |
| jdstrand | added* | 14:01 |
| zyga | jdstrand: hello :) | 14:01 |
| jdstrand | zyga: hi :) | 14:01 |
| ogra | jdstrand, thanks ! | 14:01 |
| ijohnson | rbasak: there is not, you will need to roll your own docker image | 14:02 |
| ijohnson | rbasak: 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 snp | 14:03 |
| rbasak | ijohnson: OK, thanks. | 14:06 |
| rbasak | ijohnson: do you know of any examples? | 14:06 |
| ijohnson | rbasak, sure one minute | 14:06 |
| ijohnson | rbasak: take a look at one of the snapcrafters snaps at https://github.com/snapcrafters/sdlpop/blob/master/.travis.yml | 14:07 |
| rbasak | ijohnson: that's great. Thank you! | 14:08 |
| cachio | zyga, #7256 needs a +1 | 14:13 |
| mup | PR #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 |
| cachio | pstolowski, could you please take a quick look to #7256 | 14:13 |
| pstolowski | cachio: yes | 14:15 |
| cachio | pstolowski, tx | 14:15 |
| pstolowski | cachio: 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 interesting | 14:16 |
| mup | PR #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 |
| roadmr | jdstrand: 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 |
| cachio | pstolowski, ok, I'll try to force the error | 14:23 |
| cachio | pstolowski, otherwise it will take too much time | 14:24 |
| pstolowski | cachio: force how? | 14:24 |
| cachio | pstolowski, retrying execution | 14:24 |
| cachio | until it fails | 14:24 |
| pstolowski | cachio: ok | 14:24 |
| cachio | and praying | 14:25 |
| cachio | heheehe | 14:25 |
| pstolowski | heh | 14:25 |
| jdstrand | roadmr: it does not imply allow-installation | 14:25 |
| roadmr | jdstrand: ah, ok. That makes sense | 14:26 |
| pedronis | it does for snapd | 14:26 |
| jdstrand | roadmr: 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 review | 14:26 |
| roadmr | jdstrand: did this change? did it imply installation? | 14:26 |
| pedronis | it doesn't respect the conventions though | 14:26 |
| jdstrand | roadmr: nothing has changed for months | 14:27 |
| roadmr | jdstrand: (context, someone is saying that a snap for which they have the above used to pass automated review but then started failing | 14:27 |
| roadmr | ) | 14:27 |
| jdstrand | roadmr: right, months ago it was discovered that we weren't prompting for manual review for the docker interface when we should have. it changed then | 14:27 |
| jdstrand | roadmr: there were a handful of snaps that were affected. they must not have uploaded anything in a while | 14:28 |
| roadmr | jdstrand: like, 2 months ago? we narrowed the transition down to "2019-06-17 13:55 - 2 months, 2 weeks ago" | 14:28 |
| roadmr | jdstrand: 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 previously | 14:28 |
| jdstrand | roadmr: 693121ef4ad15a0642967d5f7af69e52c1b8969d. Feb 15 | 14:29 |
| roadmr | oh that's more than 2 months ago :) | 14:29 |
| jdstrand | pedronis: 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 |
| nessita | roadmr, the date would be relevant for our bump of review tools though, not necessarily when the review tools changed | 14:32 |
| nessita | (hi all!) | 14:32 |
| pedronis | jdstrand: it's always been like this | 14:32 |
| jdstrand | pedronis: oh, you mean because if it has nothing to say about installation, it is allowed | 14:33 |
| pedronis | yes | 14:33 |
| roadmr | nessita: 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 Feb | 14:33 |
| nessita | roadmr, right | 14:33 |
| nessita | roadmr, have you, by any chance, downloaded the two revisions to compare if they changed anything in their manifest? | 14:34 |
| roadmr | nessita: nope | 14:35 |
| jdstrand | pedronis: right. that is different than auto-connection affecting installation if something does have something to say about it, which is what I meant | 14:35 |
| jdstrand | anyhoo, yes | 14:35 |
| jdstrand | roadmr: can you paste me their snap.yaml? | 14:38 |
| roadmr | jdstrand: sure, incoming | 14:38 |
| roadmr | jdstrand: https://pastebin.canonical.com/p/WJyNTTKQ8X/ | 14:39 |
| ackk | hi, 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 |
| zyga | ackk: woah | 14:40 |
| zyga | ackk: is it /root? | 14:40 |
| ackk | zyga, what is? | 14:40 |
| zyga | I think it might be confused by root :) | 14:40 |
| zyga | ackk: there's a check that $HOME is not something crazy | 14:40 |
| zyga | ackk: but it may not capture /root | 14:40 |
| ackk | zyga, yeah "maas --help" works but "sudo maas --help" doesn't | 14:40 |
| zyga | Chipaca: ^ is that us? | 14:40 |
| zyga | Chipaca: if so that's a regression | 14:41 |
| * jdstrand notes that when to manual review is a different question than when to apply at install time | 14:41 | |
| zyga | mvo: ^ | 14:41 |
| ackk | zyga, oddly, I had just run "sudo maas init" a little before, and that must have worked | 14:41 |
| zyga | huh | 14:41 |
| zyga | that's more mysterious | 14:41 |
| ackk | lemme try a reproducer | 14:41 |
| mvo | zyga: thanks, in a meeting | 14:41 |
| zyga | ack | 14:41 |
| Chipaca | ackk: what distro? | 14:41 |
| zyga | ackk: thank you | 14:41 |
| ackk | Chipaca, bionic | 14:41 |
| mvo | zyga: but thanks for the heads up, please keep me updated about your finidings | 14:41 |
| Chipaca | sudo's path should have /snap/bin on it | 14:42 |
| mvo | might be the new systemd generator? | 14:42 |
| Chipaca | (some distros have it in bash but not in sudo which is weird) | 14:42 |
| Chipaca | ugh | 14:42 |
| zyga | https://github.com/snapcore/snapd/blob/fa465e97df3b159f18c77786cdc540d2cdcd29d5/cmd/snap-confine/user-support.c#L44 | 14:42 |
| mvo | which went in with 2.41 but only in the debs | 14:42 |
| ackk | Chipaca, I'm pretty sure cloud images don't | 14:42 |
| Chipaca | ackk: don't what? | 14:42 |
| ackk | Chipaca, I'm in a lxd | 14:42 |
| ackk | don't have /snap/bin in path | 14:43 |
| ackk | at least, not for root | 14:43 |
| ackk | oh actually it seems they do now | 14:43 |
| Chipaca | ackk: in 'sudo visudo', you should see /snap/bin in 'secure_path' | 14:43 |
| zyga | I just shut down my desktop | 14:43 |
| zyga | but https://github.com/snapcore/snapd/commit/634a17c85718f15babe9fbe3cd85a36225bcfdd3 | 14:43 |
| zyga | it could be a good attempt to add a /root home directory there to see what happenns (in spread test) | 14:44 |
| Chipaca | ackk: maybe you installed snapd, and didn't re-login? | 14:44 |
| ackk | Chipaca, it's there | 14:44 |
| ackk | Chipaca, nope, that's not a fresh container | 14:44 |
| ackk | I'm testing now in a fresh one, see if I can reproduce | 14:44 |
| jdstrand | roadmr: 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 intentional | 14:46 |
| roadmr | jdstrand: ah ok - got it | 14:47 |
| ackk | Chipaca, I did relogin just now fwiw, no difference | 14:47 |
| jdstrand | roadmr: oh, and the review-tools error is correct for that snap.yaml | 14:48 |
| jdstrand | s/correct/expected/ | 14:48 |
| roadmr | awesome :) yes, just looks like behavior changed here and we didn't update the PD - I'll add allow-installation for them | 14:49 |
| roadmr | (behavior changed expectedly as you explained) | 14:49 |
| jdstrand | cool, thanks | 14:49 |
| roadmr | thank you for explaining :) | 14:49 |
| roadmr | I 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 changed | 14:50 |
| jdstrand | roadmr: 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 paths | 15:06 |
| roadmr | jdstrand: sure thing! | 15:06 |
| jdstrand | thanks :) | 15:07 |
| ppd1990 | jdstrand: 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 changes | 15:19 |
| mup | PR #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 lunch | 15:20 | |
| doko | mvo: snapcraft autopkg test regressions in eoan | 15:21 |
| jdstrand | ppd1990: 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 is | 15:23 |
| mvo | doko: hey, thanks for the heads up - sergiusens will take care of it I'm sure! | 15:29 |
| doko | mvo: well, it would be nice if the snappy team would notice these regressions on their own by default ... | 15:32 |
| mvo | doko: right, I hear you and we try to be responsive. snapcraft is a different team though, | 15:34 |
| popey_ | sergiusens: ^ see comments from doko | 15:40 |
| mvo | second review for 6705 would be great btw | 15:43 |
| mvo | ackk, zyga, Chipaca still in meetings - is there a tl;dr on this potential regression? | 15:59 |
| zyga | mvo: no, I took a break but I just stopped and writing a quick regression test | 16:00 |
| ackk | mvo, 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 |
| mvo | ta | 16:00 |
| mvo | thanks! please keep me updated, if it turns out to be a regression I want to know as soon as possible | 16:01 |
| zyga | mvo: understood, sorry for lagging | 16:01 |
| mvo | zyga: no worries! it was not meant as being pushy :) | 16:03 |
| rbasak | What'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 post | 16:04 |
| rbasak | It's the second hit for "snap core18" on Google. | 16:04 |
| rbasak | The first hit goes to the store page which doesn't answer my question. | 16:05 |
| pedronis | mvo: I will look at #6705 in my morning, slightly surprised by Chipaca's comments on it | 16:05 |
| rbasak | I can't find any announcement that says that core18 is production now? | 16:05 |
| mup | PR #6705: bootloader: little kernel support <Needs Samuele review> <Created by kubiko> <https://github.com/snapcore/snapd/pull/6705> | 16:05 |
| Chipaca | I will go for a run now and stop surprising people | 16:06 |
| mvo | Chipaca: enjoy! | 16:06 |
| zyga | Chipaca: +1 | 16:06 |
| mvo | pedronis: I will fix the things that john mentioned, its a good point | 16:07 |
| mvo | (good points) | 16:07 |
| zyga | ackk: hey | 16:07 |
| zyga | still around? | 16:07 |
| zyga | ackk: what does "sudo env" say in that machine where it happened? | 16:08 |
| zyga | ackk: feel free to paste in private if sensitive | 16:08 |
| cwayne | rbasak: https://ubuntu.com/blog/ubuntu-core-18-released-for-secure-reliable-iot-devices | 16:09 |
| cwayne | top of https://ubuntu.com/core too | 16:09 |
| rbasak | cwayne: great. Thanks! | 16:09 |
| cwayne | np :) | 16:09 |
| mup | PR 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 |
| ackk | zyga, https://paste.ubuntu.com/p/gDNq93zrPC/ | 16:11 |
| zyga | ackk: can you walk me through a case | 16:11 |
| zyga | ackk: this is inside a container, correct? | 16:12 |
| ackk | zyga, yes | 16:12 |
| zyga | ackk: how do you access the host of the container, via ssh? | 16:12 |
| zyga | ackk: when you access the container, how do you "jump into" it, via lxc shell? | 16:12 |
| ackk | zyga, via ssh, but I have my home bind-mounted in the container, so I ssh with the same user | 16:13 |
| zyga | ackk: bind mounted from the host of the container? | 16:13 |
| zyga | ackk: so you ssh into (guest) from (host) or from a different machine? | 16:13 |
| ackk | zyga, https://paste.ubuntu.com/p/XNq6w2sVGQ/ | 16:13 |
| ackk | zyga, no, ssh from my laptop to the lxd on it | 16:14 |
| zyga | ackk: so (3rd computer) -> (guest) directly, via ssh? | 16:14 |
| ackk | zyga, why 3rd computer? the containres are on my laptop as well | 16:16 |
| zyga | ah, I understand now | 16:16 |
| zyga | so you ssh from the laptop, which is the host, directly into the container | 16:17 |
| ackk | zyga, correct | 16:17 |
| zyga | ackk: and inside the container, so in (guest), the user ack exists because it was added manually? | 16:17 |
| ackk | zyga, yes | 16:18 |
| zyga | ackk: and when you run sudo maas, snap-confine complains and quits | 16:18 |
| zyga | ackk: this is on 2.41 from the archive? | 16:19 |
| ackk | zyga, 2.41 snapd snap | 16:19 |
| ackk | from beta | 16:19 |
| zyga | aha, the snapd snap | 16:19 |
| zyga | ok, thank you | 16:19 |
| zyga | let me check stuff | 16:19 |
| zyga | can you run one simple test | 16:19 |
| zyga | snap install snapd-hacker-toolbelt | 16:19 |
| zyga | and see if that works | 16:19 |
| zyga | it's just a busybox snap | 16:19 |
| ackk | zyga, 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 again | 16:20 |
| ackk | zyga, sure | 16:20 |
| ackk | zyga, just run it? | 16:20 |
| zyga | yeah | 16:20 |
| zyga | so maas is in try mode? | 16:20 |
| ackk | zyga, yes | 16:21 |
| zyga | what is a sync target? | 16:21 |
| ackk | zyga, (that snap works fwiw) | 16:21 |
| zyga | ackk: can you try to unsquashfs snapd-hacker-toolbelt, edit it anyway you like (it's a static binary), | 16:22 |
| zyga | ackk: install it in try mode | 16:22 |
| ackk | zyga, 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" again | 16:22 |
| zyga | and see if you can reproduce the issue somehow | 16:22 |
| ackk | zyga, it seems after that the snap had the issue | 16:22 |
| zyga | so there are two aspects | 16:23 |
| zyga | the message we saw indicates that we failed | 16:23 |
| zyga | the details only change the error message printed | 16:23 |
| zyga | so even if /root was handled in that logic, it would at most affect the failure message | 16:23 |
| zyga | the reason we saw that particular message is that we got EROFS | 16:24 |
| zyga | so we attempted to create a directory but got an EROFS error from the system | 16:24 |
| zyga | we can strace that to see what exactly failed | 16:24 |
| zyga | ackk: actually | 16:24 |
| zyga | ackk: if you can still reproduce it | 16:24 |
| zyga | please set SNAP_CONFINE_DEBUG=yes | 16:24 |
| zyga | and run that command again | 16:24 |
| ackk | zyga, where in the calling shell? | 16:24 |
| zyga | that will tell us all the details without the need of strace | 16:24 |
| zyga | ackk: after sudo | 16:24 |
| zyga | sudo SNAP_CONFINE_DEBUG=yes maas --help | 16:25 |
| ackk | oh ok, I don't have it right now but will try to reproduce tomorrow | 16:25 |
| zyga | ackk: so whatever really happened, it seems something has switched your home directory, or /root to read only mode | 16:25 |
| === pstolowski is now known as pstolowski|afk | ||
| mup | PR 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 |
| jdstrand | roadmr: sorry, can you pull 20190903-1746UTC? not terribly urgent, just an update to an override for core20 | 17:47 |
| jdstrand | xnox: fyi ^ | 17:48 |
| roadmr | jdstrand: sure, her it goes | 18:13 |
| jdstrand | roadmr: thanks! | 19:31 |
| sergiusens | doko: mvo I did an upload last week and it was all green | 20:05 |
| mup | PR snapcraft#2697 opened: Neon extension <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2697> | 20:08 |
| mup | PR snapd#7401 opened: tests: add unstable stage for travis execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7401> | 20:18 |
| diddledan | yootoobe: https://youtu.be/cWlYe0CE2iU | 22:10 |
| mup | PR 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!