| === NickZ3 is now known as NickZ | ||
| mup | PR snapcraft#2950 opened: meta: Snap to_dict() cleanup <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2950> | 01:52 |
|---|---|---|
| mup | PR snapd#8148 closed: overlord/configstate/configcore: add support for backlight service <⛔ Blocked> <Created by EthanHsieh> <Closed by EthanHsieh> <https://github.com/snapcore/snapd/pull/8148> | 05:14 |
| mborzecki | morning | 06:08 |
| mborzecki | school run | 06:35 |
| mup | PR snapd#8160 opened: overlord/configstate: add backlight option <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8160> | 06:38 |
| mborzecki | re | 07:12 |
| mborzecki | mvo: hey | 07:33 |
| mvo | mborzecki: good morning | 07:38 |
| zyga | good morning | 07:50 |
| mborzecki | hmm looks like my git filter-branch incantations on #8156 were not good enough | 07:50 |
| mborzecki | zyga: hey | 07:50 |
| mup | PR #8156: [RFC] cmd/snap-bootstrap: subcommand to detect if we want a chooser to run <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8156> | 07:50 |
| zyga | hmm | 07:51 |
| zyga | didn't I review https://github.com/snapcore/snapd/pull/8160 already? | 07:51 |
| mup | PR #8160: overlord/configstate: add backlight option <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8160> | 07:51 |
| zyga | or something just like it? | 07:51 |
| mvo | zyga: I think the config var got tweaks | 07:53 |
| zyga | meanwhile master is still red | 07:54 |
| zyga | Ian sent a fix but it seems to be insufficient or also broken somehow | 07:54 |
| zyga | hmm, what is curious is that the failure is only present on core18 | 07:55 |
| zyga | I wonder if that's because of the extra logic on how snapd is started there | 07:56 |
| mvo | zyga: I run a debug session now | 08:03 |
| mvo | good morning pstolowski | 08:03 |
| pstolowski | morning | 08:03 |
| zyga | hey Pawel, good morning | 08:03 |
| mvo | zyga: it's a bit annoying, also it's super unclear why it's starting now | 08:03 |
| mborzecki | pstolowski: morning! | 08:03 |
| mvo | zyga: actually - new systemd in bionic since 2020-02-17 | 08:04 |
| zyga | ohhh | 08:04 |
| mvo | zyga: I think this is roughtly when the trouble started? | 08:04 |
| zyga | that's a good trail | 08:04 |
| zyga | yeah, let's see the changelog | 08:04 |
| mvo | zyga: we could run core18 tests with stable core18, that still has the old version | 08:05 |
| zyga | wow, that's true, that's brilliant | 08:05 |
| zyga | if that passes we know for sure it's the base OS that changed | 08:05 |
| mvo | zyga: the changelog has a smoking gun | 08:05 |
| zyga | reading it now | 08:06 |
| zyga | og | 08:06 |
| zyga | OnFailure job something | 08:06 |
| zyga | don't trigger ONFailure | 08:06 |
| mvo | - Only trigger OnFailure= if Restart= is not in effect (LP: #1849261) | 08:06 |
| mup | Bug #1849261: Update systemd for ubuntu 18.04 with fix for interaction between OnFailure= and Restart= <architecture-s39064> <bionic> <bugnameltc-182011> <ddstreet> <id-5de127a738dabd05006e38e8> <severity-high> <systemd> <targetmilestone-inin1804> <verification-done> <verification-done-bionic> | 08:06 |
| mup | <Ubuntu on IBM z Systems:Fix Released by canonical-foundations> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Xenial):Won't Fix> <systemd (Ubuntu Bionic):Fix Released by ddstreet> <systemd (Ubuntu Disco):Fix Released> <systemd (Ubuntu Eoan):Fix Released> <https://launchpad.net/bugs/1849261> | 08:06 |
| mvo | zyga: exactly, this looks super suspicious | 08:06 |
| mvo | zyga: also wrong, I mean, if it fails to restart for n times we need to go into failure | 08:06 |
| mvo | anyway | 08:06 |
| zyga | hmm hmm hmm | 08:07 |
| zyga | mvo: but it passes in 20.04 | 08:07 |
| zyga | so something changed there | 08:07 |
| zyga | the patch is https://github.com/systemd/systemd/pull/9158/files | 08:08 |
| mup | PR systemd/systemd#9158: trigger OnFailure= only if Restart= is not in effect <pid1> <Created by poettering> <Merged by keszybz> <https://github.com/systemd/systemd/pull/9158> | 08:08 |
| zyga | I'll check if that got changed further down the line | 08:08 |
| mvo | zyga: cool, thank you | 08:08 |
| mvo | zyga: I think this is it, kind of annoying | 08:08 |
| mvo | zyga: but at least we know now what to do | 08:08 |
| zyga | mvo: the test does run on 20.04, right? | 08:08 |
| mvo | zyga: lol - no | 08:09 |
| mvo | zyga: it has a TODO:UC20: "does not work for unknown reasons" | 08:09 |
| zyga | pfff | 08:09 |
| zyga | hahahaha | 08:09 |
| zyga | so it's broken | 08:09 |
| zyga | and now we need to live with it | 08:09 |
| zyga | ok | 08:10 |
| mvo | zyga: well | 08:10 |
| mvo | zyga: let me try something | 08:10 |
| zyga | the code didn't change since that patch, systemd master still behaves the same way it does in 18.04 | 08:10 |
| zyga | ok | 08:10 |
| zyga | so | 08:10 |
| zyga | I think we need to change how snapd restarts | 08:11 |
| zyga | if we limit that to a fixed number | 08:11 |
| mvo | zyga: I hope we just need to change the startlimitinterval | 08:11 |
| zyga | then on failure will trigger again | 08:11 |
| zyga | no, not the interval | 08:11 |
| mvo | zyga: then the failure will be triggered again | 08:11 |
| mvo | zyga: no? | 08:11 |
| zyga | we need to allow snapd to really fail | 08:11 |
| zyga | that's how I understand this fragment: | 08:11 |
| zyga | https://www.irccloud.com/pastebin/phqUSrfE/ | 08:11 |
| zyga | let me read the diff again | 08:11 |
| mvo | zyga: right, my understanding is that once we hit the restart interval it will actually go into failed state and then the OnFailure is run | 08:12 |
| mvo | zyga: but I just infered this, did not read the patch | 08:12 |
| zyga | we need to check | 08:12 |
| zyga | I mean | 08:13 |
| zyga | just do | 08:13 |
| ijohnson | zyga: mvo: what I think is the best fix to fix this with the new systemd is 2 things, 1 nfs-support test needs to also reset-failed on snapd.socket and 2 snap-failure needs to reset-failed before trying to start the socket unit | 08:13 |
| zyga | https://github.com/systemd/systemd/pull/9158/files#diff-a89a9b6f80aada989d298b4c2c3a9d64R2435 | 08:13 |
| mup | PR systemd/systemd#9158: trigger OnFailure= only if Restart= is not in effect <pid1> <Created by poettering> <Merged by keszybz> <https://github.com/systemd/systemd/pull/9158> | 08:14 |
| zyga | so, as long as the service will auto restart | 08:14 |
| zyga | we don't get failed state | 08:14 |
| zyga | ijohnson: good mornign! | 08:14 |
| zyga | (it's kind of early, wow :) | 08:14 |
| ijohnson | Yeah couldn't sleep but probably will try to go back to bed shortly | 08:14 |
| mvo | ijohnson: woha, hey | 08:15 |
| mvo | ijohnson: good evening :) | 08:15 |
| * mvo hugs ijohnson | 08:15 | |
| ijohnson | mvo: indeed :-) | 08:15 |
| mborzecki | ijohnson: hey! already adjusting to CET timezone? | 08:15 |
| zyga | mvo: I need to handle an errand at home, I'll be back in 20 | 08:16 |
| mvo | zyga: no worries | 08:16 |
| mvo | zyga: testing a patch now | 08:16 |
| ijohnson | Anyways snap-failure needs to be a bit more robust about starting the snapd.socket service anyways | 08:16 |
| mvo | ijohnson: thanks, that's good to know | 08:16 |
| ijohnson | Because cachio ran into another problem with this test that happens because the socket is still lying around | 08:17 |
| mvo | ijohnson: I'm poking at it now, a bit annoying since it takes forever to run each test | 08:17 |
| ijohnson | Haha yes that was most of my day yesterday waiting for spread and fixing other random things in the meantime | 08:17 |
| ijohnson | mvo: but also see my comment about the nfs-support test, it calls reset-failed on _only_ snapd, it should also call that on snapd.socket too | 08:18 |
| mborzecki | stepping out for a bit to get the papers to my accountant, and then will probably work from some place in the city | 08:22 |
| mup | PR snapd#8161 opened: tests: set StartLimitInterval in snapd failover test <Created by mvo5> <https://github.com/snapcore/snapd/pull/8161> | 08:34 |
| mvo | ijohnson: thanks, I check these area too but it seems the current issue is about the StartLimitInterval | 08:36 |
| zyga | re | 08:36 |
| zyga | there's some chaos at home today | 08:41 |
| zyga | I'm heading out | 08:41 |
| ijohnson | mvo: what I was trying to say is that the nfs-support test will start failing too when you make adjustments to the StartLimitInterval that are favorable to snapd-failover because that test is flaky due to not resetting the failed count of the snapd.socket service | 08:41 |
| zyga | don't want to be a part of this | 08:41 |
| zyga | (family life and living with parent-in-law) | 08:41 |
| * mvo hugs zyga | 08:43 | |
| mvo | ijohnson: aha, thanks. my current approach was to adjust the StartLimitInterval only in this one test | 08:44 |
| mvo | ijohnson: i.e. just enough to get us on our feed again, not at all against fixing more | 08:44 |
| ijohnson | Ah okay nvm me then | 08:45 |
| mvo | ijohnson: let's talk some more later, I really don't want to keep you from sleep :) | 08:47 |
| ijohnson | It's fine no worries | 08:47 |
| zyga | mvo: re | 09:08 |
| zyga | mvo: small observation | 09:08 |
| zyga | mvo: perhaps we want to consider a spread suite that does run in autopkgtest and gates classic systemd | 09:08 |
| zyga | mvo: we would catch this if that test was a part of that set | 09:09 |
| zyga | mvo: something to consider after this is resolved | 09:09 |
| zyga | mvo: I'll work on my tasks from Jamie's review - please pull me into a review once you have the fix | 09:10 |
| zyga | mvo: and it's also a good good catch about this test, if we had disabled that test and released a new core we could really have a bad day | 09:10 |
| mvo | zyga: it's an interessting idea, we did have autopkgtest for snapd but it was terrile unreliable | 09:11 |
| mvo | zyga: we would have caught this thought | 09:11 |
| zyga | yeah, perhaps we can turn some knobs to make it better though | 09:11 |
| zyga | dunno | 09:11 |
| * mvo nods | 09:11 | |
| zyga | totally offtopic, I noticed that systemd --user runs for gdm | 09:13 |
| zyga | we should probably not run snap services for gdm | 09:13 |
| pedronis | mvo: hi, is it expected there's no standup in the calendar today? | 09:15 |
| mvo | pedronis: not expected, uh, let me fix this | 09:16 |
| mvo | pedronis: thanks for catching that | 09:16 |
| pedronis | #8130 needs a 2nd review | 09:23 |
| mup | PR #8130: overlord, state: don't abort changes if spawn time before StartOfOperationTime (2/2) <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8130> | 09:24 |
| mup | PR snapd#8162 opened: features: enable "parallel-installs" by default <Created by mvo5> <https://github.com/snapcore/snapd/pull/8162> | 09:27 |
| mborzecki | yay | 09:29 |
| mborzecki | mvo: that's for 2.44? | 09:29 |
| zyga | mvo: that's great to see, thank you! | 09:30 |
| mvo | mborzecki: that's something to discuss | 09:32 |
| mvo | mborzecki: 2.44 means it's ready for 20.04 and most likely on the CD | 09:32 |
| mvo | mborzecki: which is great | 09:32 |
| mvo | mborzecki: but also risky | 09:33 |
| mborzecki | ayy ;) | 09:34 |
| mvo | mborzecki: let's talk at the standup | 09:34 |
| mborzecki | mvo: ok | 09:34 |
| mvo | also - amazon linux is failing to install packages right now :( | 09:34 |
| mborzecki | mvo: duh, got logs? | 09:35 |
| mvo | mborzecki: yes, on sec | 09:36 |
| mvo | mborzecki: I move it to unstable for now, look like some repo issue | 09:36 |
| mvo | mborzecki: probably transient | 09:36 |
| mvo | mborzecki: https://travis-ci.org/snapcore/snapd/jobs/652883253?utm_medium=notification&utm_source=github_status | 09:37 |
| mvo | yay, 8161 unbreaks the snapd-failover test | 09:39 |
| pedronis | mvo: we really need to do something about aliases before turning on parallel installs by default | 09:39 |
| mborzecki | mvo: yeah, looks like inconsistency in amazon's repos | 09:39 |
| mborzecki | mvo: and kinda basic, iproute, iptables :/ | 09:40 |
| mup | PR snapd#8162 closed: features: enable "parallel-installs" by default <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8162> | 09:40 |
| mvo | pedronis: ok, closing this again then until we have time for this | 09:40 |
| mvo | mborzecki: yeah, that was my impression as well, hopefully transient | 09:41 |
| mborzecki | pedronis: thanks for the review | 09:41 |
| pedronis | mvo: yea, sadly it needs more work, but I think the current experience is suboptimal | 09:41 |
| pedronis | and we turn it on we are stuck with the behavior forever | 09:41 |
| mvo | reviews for 8161 would be appreicated | 09:45 |
| mvo | (should be super simple) | 09:45 |
| mvo | and fixed the snapd-failover test - at least in the one run that happened there :) | 09:45 |
| zyga | mvo: what's the context of amazon linux and unstable | 10:09 |
| zyga | the commit message has no other information | 10:09 |
| pedronis | <mvo> also - amazon linux is failing to install packages right now :( | 10:12 |
| mup | PR snapd#8163 opened: tests: enable snapd-failover on uc20 <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8163> | 10:13 |
| * pedronis reboots | 10:37 | |
| mup | PR snapd#8164 opened: snap: use the actual staging snap-id for snapd <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8164> | 11:26 |
| mborzecki | pedronis: got a question about https://github.com/snapcore/snapd/pull/8156#discussion_r381881462 you'd see the WaitTriggerKey() be moved to some other file right and just keep the interfaces and related structs in triggerwatch.go? | 11:26 |
| mup | PR #8156: [RFC] cmd/snap-bootstrap: subcommand to detect if we want a chooser to run <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8156> | 11:26 |
| pedronis | mborzecki: not quite, I think the structs should go where they are used as input or output to functions | 11:27 |
| pedronis | mborzecki: this is go so the interfaces can be defined on the consuming side | 11:27 |
| pedronis | mborzecki: I mean keyEvent etc should be in evdev.go | 11:29 |
| mborzecki | pedronis: hmm right, the only concern i have is that keyEvent is a concrete type, so it's kind of shared between the consumer and producer, not sure if i'm explaining this right :) | 11:35 |
| pedronis | mborzecki: you are, but is not a concern in go | 11:35 |
| pedronis | the interfaces exist mostly for testing, no? | 11:36 |
| pedronis | mborzecki: it's very unsual for a consumer to define structs it wants | 11:36 |
| mborzecki | pedronis: yeah, well, maybe i'm trying to complicated it too har :) | 11:36 |
| pedronis | mborzecki: let's put it this, way if you tried to stick evdev.go in its own package as is, it wouldn't work | 11:37 |
| pedronis | mborzecki: does this ^ remark makes sense? I'm also happy to HO if I'm still confusing you | 11:42 |
| mborzecki | pedronis: it's ok, i'm overcomplicating this, thought about a scenario when evdev went to a separate pacakge and KeyEvent would either need to be an iface, or one package would need to import the other to get the definition, but it makes no sense to restructure it this way | 11:47 |
| pstolowski | cachio: hey! i've asked 2 questions under #8157 | 11:49 |
| mup | PR #8157: tests: using google storage when downloading ubuntu cloud images from gce <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8157> | 11:49 |
| cachio | pstolowski, hi, I'll take a look | 11:49 |
| cmatsuoka | mborzecki: just out of curiosity, what's the time difference between running the chooser trigger check from initramfs or early in the normal system? | 11:54 |
| mborzecki | cmatsuoka: we can start the detection early, in my VMs it's like <1s earlier than early boot, but i guess it may be different on the actual devices | 11:56 |
| mborzecki | cmatsuoka: and there's also a question, whether we'd be able to execute the gadget-provided trigger hook in initramfs, which i suspect we won't | 11:56 |
| mborzecki | cmatsuoka: as i said during the standup, it's probably only to the benefit of a device that supports the trivial input method like keyboard or somesuch | 11:57 |
| cmatsuoka | mborzecki: I had this feeling that initramfs should execute really fast | 11:57 |
| cmatsuoka | mborzecki: but yeah I don't know how slow real devices could be | 11:58 |
| jdstrand | zyga: hey, fyi, https://github.com/snapcore/snapd/pull/7980 is -><- close | 12:07 |
| mup | PR #7980: packaging,snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7980> | 12:07 |
| zyga | jdstrand: cool | 12:15 |
| zyga | jdstrand: I'll check soon | 12:16 |
| zyga | jdstrand: going through coverity, last one to fix | 12:16 |
| * pstolowski lunch | 12:20 | |
| mborzecki | moving back home | 12:20 |
| mborzecki | bbiab | 12:20 |
| cmatsuoka | mvo: the enable failover tests failed for some reason | 12:25 |
| zyga | jdstrand: https://github.com/snapcore/snapd/pull/8165 | 12:26 |
| mup | PR #8165: cmd/snap-confine: fix everything flagged by coverity <Created by zyga> <https://github.com/snapcore/snapd/pull/8165> | 12:27 |
| mup | PR snapd#8165 opened: cmd/snap-confine: fix everything flagged by coverity <Created by zyga> <https://github.com/snapcore/snapd/pull/8165> | 12:27 |
| zyga | jdstrand: replied to setgid, I'll jump there immediately now as it's so low hanging and it could be done shortly | 12:30 |
| zyga | jdstrand: the bigger branch is still in progress, I'm working on improving the testing setup and resolving the issue you highlighted in remote access to 18.04 system | 12:30 |
| zyga | jdstrand: it is real but for reasons I need to dig deeper to understand | 12:30 |
| zyga | mvo, jdstrand: FYI - I will make coverity scan automatic, this is just the first step | 12:31 |
| zyga | jdstrand: btw, I think we got remarkably little things flagged by coeveity | 12:32 |
| zyga | Coverity | 12:32 |
| zyga | I was bracing for a huge list | 12:33 |
| zyga | It is a really cool tool | 12:33 |
| zyga | mvo: it seems core 20 needs more love for failover | 12:37 |
| zyga | mvo: /bin/bash: line 89: /usr/bin/snap: No such file or directory | 12:37 |
| * zyga small coffee & pączek break | 12:39 | |
| cmatsuoka | Pączki look delicious! | 12:41 |
| zyga | cmatsuoka: it's fat Thursday here | 12:44 |
| zyga | cmatsuoka: so pączki are everywhere | 12:44 |
| pedronis | mvo: is it known that snapd snap ships the code in /snap ? | 12:52 |
| cmatsuoka | pedronis: you mean the go source code? yes, but it's to be solved with ijohnson's patch to use base: core in snapcraft.yaml | 12:56 |
| zyga | we back up like real men | 12:59 |
| zyga | by shipping all code to each user in production | 12:59 |
| zyga | Dear $NAME; This is not a scam. Can you send us your core snap back please? We lost all disks in a thunderstorm. kthxbye | 13:00 |
| mborzecki | re | 13:05 |
| zyga | I just jumped through initrd break=premount | 13:07 |
| zyga | fun | 13:07 |
| zyga | I think I will head back | 13:15 |
| zyga | better to have the standup in a private setting | 13:15 |
| zyga | I'll finish my coffee and walk home | 13:15 |
| ijohnson | Speaking of my branch it should be ready to land when the Snapcraft in candidate goes to stable | 13:19 |
| mvo | cmatsuoka, zyga re core20 failover> it is strange, I ran this locally and it worked, oh well. needs investigation | 13:19 |
| pstolowski | mvo: your fix for master failed on preseed test during image download. Perhaps it would make sense to land cachio's 8157 first (and flag it with 'skip spread') | 13:21 |
| sdhd-sascha | zyga: Can you explain what syntax/grammer of the mount command here has? And where receive the command then? | 13:29 |
| sdhd-sascha | ``` | 13:29 |
| sdhd-sascha | emit(" mount options=(bind, rw) %s -> %s,\n", bindFile, path) | 13:29 |
| sdhd-sascha | emit(" mount options=(rprivate) -> %s,\n", path) | 13:29 |
| sdhd-sascha | emit(" umount %s,\n", path) | 13:29 |
| sdhd-sascha | ``` | 13:29 |
| sdhd-sascha | I mean: who receives the message? | 13:29 |
| sdhd-sascha | zyga: wait. it's in the comments. Thank you | 13:31 |
| mvo | pstolowski: hm, I can cherry pick his fix into my PR | 13:34 |
| pstolowski | mvo: that works too | 13:36 |
| zyga | re | 13:44 |
| zyga | sdhd-sascha: that's apparmor mount specification | 13:44 |
| zyga | sdhd-sascha: I'm glad you asked about grammar | 13:45 |
| zyga | sdhd-sascha: that's about the only thing that is very thoroughly documented :) | 13:45 |
| zyga | sdhd-sascha: go to http://manpages.ubuntu.com/manpages/bionic/man5/apparmor.d.5.html | 13:45 |
| zyga | sdhd-sascha: and check the MOUNT RULE = part | 13:46 |
| cmatsuoka | mvo: Thursdays SUs are in a different room now? | 13:55 |
| sdhd-sascha | zyga: :-) thank you, again. | 13:56 |
| sdhd-sascha | i'm looking for a way to mount when a classic snap service restarts. Think the install hook is not enough. | 13:56 |
| zyga | sdhd-sascha: can you summarize as to what you want to detect and what you want to do in response please | 13:56 |
| mvo | cmatsuoka: not really, sorry, silly calendar | 13:57 |
| zyga | hmm | 13:59 |
| zyga | should I join what meet proposes | 13:59 |
| zyga | I'm in the standp | 13:59 |
| zyga | nobody there | 13:59 |
| cmatsuoka | zyga: use the regular one I guess | 13:59 |
| zyga | can you spare the link | 14:00 |
| sdhd-sascha | zyga: the github-runner, needs write access in the same directory. so i create /var/lib/runner/$SNAP_NAME/_work directory on install-hook. Then i want to be sure, that this is mounted to $SNAP/usr/lib/runner/_work | 14:00 |
| zyga | I just go to meet.google.com | 14:00 |
| zyga | mvo: can you share the correct link | 14:00 |
| sdhd-sascha | zyga: it's classic, because i don't know what the github-action-runner-scripts can do | 14:01 |
| sdhd-sascha | zyga: on classic, the layout in snapcraft.yaml is not executed... | 14:02 |
| zyga | sdhd-sascha: layouts don't do anything during classic confinement | 14:02 |
| * sdhd-sascha nod | 14:03 | |
| sdhd-sascha | Would be nice if layouts in classic mode would also work. | 14:04 |
| zyga | sdhd-sascha: what would you expect them to do? | 14:04 |
| zyga | sdhd-sascha: change the host? | 14:04 |
| zyga | sdhd-sascha: what if two snaps want to have $SNAP/foo in /usr/lib? | 14:05 |
| zyga | sdhd-sascha: who wins? | 14:05 |
| sdhd-sascha | maybe, limit the mounts to `/var/lib/runner/$SNAP_NAME/$SNAP_REVISION/_work` like above | 14:05 |
| zyga | sdhd-sascha: what is /var/lib/runner? | 14:06 |
| sdhd-sascha | i mean, without runner | 14:06 |
| mup | PR snapd#8166 opened: cmd/snap-bootstrap: create a new parser instance <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8166> | 14:06 |
| zyga | sdhd-sascha: I think this is weird, a classic snap can just mount stuff there | 14:06 |
| zyga | sdhd-sascha: perhaps I'm missing something but I think layouts are not meant for this | 14:06 |
| sdhd-sascha | ok | 14:07 |
| sdhd-sascha | thank you | 14:07 |
| zyga | sdhd-sascha: layouts take something from the snap and put it somewhere in the view of the snap | 14:07 |
| zyga | sdhd-sascha: but none of that changes the host for real | 14:07 |
| mborzecki | cmatsuoka: btw. could we just mkfs rather than delete/remove partitions? | 14:24 |
| cmatsuoka | mborzecki: right, I think we could just redeploy them instead of messing with the partition table | 14:27 |
| mborzecki | cmatsuoka: just look at the attributes to know which ones we can wipe | 14:27 |
| cmatsuoka | mborzecki: let's try that | 14:29 |
| ackk | mvo, hi, sorry to ping again wrt #1817276, is there anything I can capture when this happens to help debugging? I see it quite frequently locally. it might be made worse by the fact that my laptop is a bit old | 14:36 |
| mup | Bug #1817276: snapfuse use a lot of CPU inside containers <maas> <snapd:Fix Released by mvo> <https://launchpad.net/bugs/1817276> | 14:36 |
| mvo | ackk: I need to appologize for this one, we still have not invstigated how this can happen | 14:39 |
| cmatsuoka | mborzecki: I blocked the PR while I try those changes, but I'll work on the TPM cmdline measuring first | 14:40 |
| mborzecki | cmatsuoka: cool, added a note there too | 14:40 |
| ackk | mvo, np. I can't change the status of that bug. does it make sense to reopen or should I file a new one ? | 14:41 |
| pedronis | mborzecki: ping me when the chooser PR is ready for re-review | 14:42 |
| mvo | ackk: let me reopen it | 14:42 |
| ackk | mvo, thanks | 14:42 |
| mvo | ackk: reopened and updated the description. let me try to investigate again | 14:43 |
| mvo | ijohnson: do you think you could have a look at 8161 ? it's green and seems to fix the snapd failover, if it's not wrong I'm in favor of merging and then we can merge your improvements next? | 14:48 |
| mvo | ijohnson: it should unblock all the other PRs we have open | 14:48 |
| ijohnson | mvo: sure | 14:50 |
| ackk | mvo, thanks | 14:50 |
| ijohnson | mvo: approved | 14:53 |
| mvo | pedronis: thanks for letting me know about the /snaps subdir in the snapd snap - I (strongly) suspect that snapcraft is acting silly here, will investigate | 14:54 |
| ijohnson | mvo: it's fixed in modern snapcraft | 14:55 |
| mvo | ijohnson: aha! so we just need to land your PR :) ? | 14:55 |
| ijohnson | mvo: my PR open right now fixes that, but we just need to wait until snapcraft 3.10 on candidate channel is promoted to stable | 14:55 |
| ijohnson | yes | 14:55 |
| mvo | ijohnson: I guess I could change our build recipe to use snapcraft from candidate? | 14:55 |
| mvo | ijohnson: let me try this | 14:56 |
| ijohnson | mvo: yes that would let us land sooner, not sure if that's okay to build snapd that gets released with candidate? depends on how much you trust sergiusens I guess :-) | 14:56 |
| ijohnson | mvo: the spread test we have is already using candidate | 14:56 |
| ijohnson | (but that doesn't release anywhere, just makes sure it builds) | 14:56 |
| mvo | ijohnson: I trust sergiusens a lot - plus the extra testing snapcraft would get this way is probably good | 14:57 |
| ijohnson | sure sounds good then :-) | 14:57 |
| mup | PR snapd#8161 closed: tests: set StartLimitInterval in snapd failover test <Test Robustness> <⚠ Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8161> | 14:57 |
| sergiusens | ijohnson: I am mostly waiting on feedback from field, but I probably won't be releasing this week | 14:57 |
| mvo | sergiusens: I switched our default snapd builds to use the snapcraft from candidate now, I think this makes sense anyway for testing your stuff earlier | 14:58 |
| mvo | ijohnson: so just to double check 7904 will work with snapcraft 3.10 in candidate? so I can remove the blocked label? | 14:59 |
| ijohnson | mvo: yes | 14:59 |
| mvo | ijohnson: awsome | 15:00 |
| sergiusens | thanks mvo, that will help! | 15:02 |
| mborzecki | zyga: https://github.com/snapcore/snapd/pull/8165/files#r382057305 | 15:06 |
| mup | PR #8165: cmd/snap-confine: fix everything flagged by coverity <Created by zyga> <https://github.com/snapcore/snapd/pull/8165> | 15:06 |
| mborzecki | zyga: found an example of use in qemu: https://github.com/qemu/qemu/blob/master/scripts/coverity-model.c | 15:07 |
| zyga | mborzecki: looking | 15:08 |
| mborzecki | cmatsuoka: can you take a quick look at https://github.com/snapcore/snapd/pull/8166 ? | 15:21 |
| mup | PR #8166: cmd/snap-bootstrap: create a new parser instance <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8166> | 15:21 |
| mvo | ackk: in the bugreport you write this happens inside a bionic container, this is puzzling. however it seems like I can explain why it's happening inside a disco container. but it's a bionic container? | 15:22 |
| mvo | ackk: anyway, I will dig a bit deeper, if you have access to the container the output of "apt list squashfsfuse" would be nice | 15:22 |
| mvo | ackk: to the problematic container | 15:23 |
| ackk | mvo, well yeah I've seen it in bionic, but also on focal while testing maas upgrade from deb to snap | 15:27 |
| mvo | ackk: ok, I keep diging | 15:28 |
| ackk | mvo, in this scenario I launch a bionic container, install maas from deb, do-release-upgrade to focal which updates to the transitional deb (which installs the snap). once services in the snap start, snapfuse eats all cpu (along with python for the services) | 15:28 |
| mvo | ackk: in a meeting right now, will get back to you (and try this out) | 15:43 |
| sdhd-sascha | Is it possible to backup a snap installation and restore them on a new installation as blob ? | 15:52 |
| sdhd-sascha | It could be faster on github-actions if the installation of "snap", "lxd", "snapcraft" could be shortend with a tar-package | 15:53 |
| zyga | sdhd-sascha: ish, it's not trivial | 15:54 |
| * zyga is busy and won't respond now, sorry | 15:54 | |
| cmatsuoka | mborzecki: thanks, that's very useful! | 15:56 |
| * mborzecki figures it's better to rebuild initramfs before repacking the kernel snap /o\ | 15:58 | |
| mvo | ackk: just one more question - what is your "host" os that you run lxd on ? | 16:03 |
| mvo | ackk: just to make sure I get a realistic reproducer | 16:03 |
| ackk | mvo, currently eoan | 16:03 |
| ackk | mvo, lxd backend is btrfs (if that matters) | 16:03 |
| ackk | (lxd 3.20) | 16:04 |
| mvo | ackk: thank you | 16:05 |
| ackk | mvo, np, let me know if you need any more info | 16:05 |
| * cachio lunch | 16:08 | |
| mvo | ijohnson: 7904 is green :) | 16:09 |
| mvo | can someone do a second review on 7904 please? | 16:09 |
| zyga | y | 16:10 |
| ijohnson | mvo: pstolowski reviewed and approved it a while ago | 16:10 |
| ijohnson | but sure more reviews is never a bad idea | 16:10 |
| ijohnson | :-) | 16:10 |
| zyga | mvo: what does adopt-info snapd do? | 16:11 |
| zyga | I remember the concept | 16:11 |
| mup | PR snapd#8163 closed: tests: enable snapd-failover on uc20 <Simple 😃> <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8163> | 16:11 |
| zyga | but what's the data source for "snapd"? | 16:11 |
| mvo | zyga: it means to get info like version from the snapd part | 16:12 |
| zyga | aha, I see | 16:12 |
| zyga | but where is the part defining anything that is adopted? | 16:12 |
| zyga | is that set-version snapcraftctl? | 16:12 |
| ijohnson | zyga: the data source for snapd when not specified defaults to "." | 16:15 |
| ijohnson | err for any snapcraft part rather | 16:16 |
| ijohnson | zyga: `adopt-info: snapd` means get metadata for the snap from the part named "snapd", which is a bit counter-intuitive since the whole snap is named snapd and we also have the magic `type: snapd` so it's not clear if it's a special value or just a part | 16:18 |
| zyga | yeah | 16:18 |
| ijohnson | zyga: if you like I could rename the part from snapd to `snapd-deb` as that's really what the part is building | 16:18 |
| zyga | a comment would be nice | 16:18 |
| zyga | followup material | 16:18 |
| ijohnson | cool, yes I would prefer a followup if that's okay | 16:18 |
| * ijohnson is not feeling lucky | 16:19 | |
| * ijohnson about tests today | 16:19 | |
| zyga | hahaha | 16:19 |
| mup | PR snapd#8167 opened: o/standby: add SNAPD_STANDBY_WAIT to control standby in development <Created by pedronis> <https://github.com/snapcore/snapd/pull/8167> | 16:19 |
| mup | PR snapd#7904 closed: snapcraft.yaml: use build-base and adopt-info, rm builddeb plugin <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7904> | 16:22 |
| mvo | ackk: one more question - in the bugrpeort you say that you see squashfuse generating a lot of cpu, it's squashfuse (and not snapfuse), right? | 16:22 |
| ackk | mvo, let me confirm | 16:23 |
| ackk | mvo, it seems it's actually snapfuse | 16:26 |
| mvo | ackk: that's interessting | 16:26 |
| mvo | ackk: the bugreport says "after installing core and rebooting". this is installing core in the container, I suppose but then rebooting the host? | 16:27 |
| ackk | mvo, no, rebooting the container, but that might be a red herring, I tried reproducing it that way and didn't manage to. so it might have been something else | 16:27 |
| ackk | mvo, what I did right now, though is just to install the maas snap, and initialize it | 16:27 |
| ackk | not a clean container, just my dev onne | 16:27 |
| ijohnson | pedronis: mvo: xnox mentioned to me a while back that we should consider upgrading the build-base of the snapd snap to build a newer libc/other tools, thoughts on this? I don't think we need to do this now, but I could add a TODO:UC20: to the snapcraft.yaml for the snapd snap so we don't lose this suggestion | 16:28 |
| ackk | mvo, I take the more I/O the application does, the more snapfuse has to work as well? | 16:28 |
| mvo | ackk: yes | 16:28 |
| xnox | ijohnson: if you do, you do need to check minumum kernel requirements from newer libc, and how it matches the platforms you support. | 16:29 |
| mvo | ackk: I mean, snapfuse taking quite a bit of cpu is normal but we fixed using the wrong snapfuse binary a while ago and it puzzling that apparently this is not fully working for you | 16:29 |
| ijohnson | also xnox in other news, you should now be able to cleanly build snapd snap from git master with candidate snapcraft :-) | 16:29 |
| ijohnson | xnox: hmm good point | 16:29 |
| xnox | but do note that trusty is no longer a support target for snapd | 16:30 |
| ackk | mvo, I haven't seen issues with other snaps in containers, but maas does quite a lot of IO even just when starting up / setting up, so maybe the issue shows there more prominently | 16:30 |
| ackk | mvo, plus, my laptop is old and non-nvme | 16:30 |
| ackk | mvo, btw, the original issue reported by BjornT was on zfs, mine is on btrfs, so I was wondering if COW filesystems might play a role | 16:31 |
| mup | PR snapcraft#2939 closed: pluginhandler: user directories scoped to partdir for snapcraftctl <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2939> | 16:31 |
| ackk | mvo, I have a focal machine, I can try spawning a container there and see if it it's different | 16:32 |
| mvo | ackk: interessting, could be. I'm trying in a clean 19.10 VM, all freshly created in qemu and see snapfuse hoover around 40% cpu which seems not that unexpected | 16:32 |
| ackk | mvo, is that with maas? | 16:33 |
| mvo | ackk: yes, with maas init | 16:33 |
| mvo | ackk: I now see two snapfuse, one 65 the other 20% | 16:33 |
| ijohnson | zyga: see ^ or v depending on how quick mup is | 16:33 |
| mvo | ackk: I think you mentioned multiple ones with 100% ? | 16:33 |
| mvo | ackk: but this is ext4, I need to try zfs/btrfs :/ | 16:33 |
| mup | PR snapd#8168 opened: snapcraft.yaml: add comments, rename snapd part to snapd-deb <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8168> | 16:33 |
| ijohnson | there it is ^ | 16:34 |
| ackk | mvo, no just one, plus multiple python processes also using quite a lot of cpu, but that's expected during init | 16:34 |
| mvo | ackk: yeah, I see python too but was assuming that is maas :) | 16:34 |
| mvo | ackk: just one> but 100% cpu? | 16:34 |
| mup | PR snapcraft#2947 closed: remote-build: pass through 'source-subdir' property <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2947> | 16:34 |
| ackk | mvo, correct | 16:34 |
| mvo | ackk: ok, I think I need to re-do this with a different fs, ext4 seems to not show it (or I'm doing something wrong) | 16:35 |
| pstolowski | cachio: can you merge master into 8157? | 16:35 |
| mvo | ackk: it runs for a long time, that is normal? | 16:37 |
| ackk | mvo, yeah, although snapfuse stealing cpu makes it worse | 16:37 |
| mvo | ackk: yeah :( | 16:37 |
| ackk | mvo, fwiw in my container here maas init has finished but snapfuse is still running at 100%cpu | 16:39 |
| mvo | ackk: will redo this now with a different fs | 16:39 |
| mvo | ackk: uh, that's interessting | 16:39 |
| ackk | mvo, that's what always happens | 16:39 |
| mvo | ackk: can you check where snapfuse comes from? it should be /usr/bin/snapfuse from inside the container | 16:39 |
| ackk | mvo, /usr/bin/snapfuse | 16:40 |
| ackk | (from /proc/pid/exec) | 16:40 |
| mvo | ackk: yeah, that should be fine (well, "should") | 16:40 |
| ackk | err, exe | 16:40 |
| mup | PR snapcraft#2943 closed: spread: capture developer debug information <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2943> | 16:40 |
| * mvo add zfs or something to see if it makes a difference | 16:40 | |
| * ackk stops maas before laptop catches fire | 16:41 | |
| BjornT | ackk: let it burn and buy a new one already :) | 16:42 |
| pedronis | mborzecki: 8136 needs a 2nd review | 16:42 |
| ackk | BjornT, because of free mentining it I'm now kinda waiting for gen8 | 16:43 |
| mup | PR snapd#8166 closed: cmd/snap-bootstrap: create a new parser instance <Simple 😃> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8166> | 16:45 |
| mup | PR snapcraft#2923 closed: requirements: Update PyYAML requirement to 5.3 <Created by NickZ> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2923> | 16:46 |
| mup | PR snapd#8155 closed: tests: mv ubuntu-core-snapd{,-failover} to core/ suite <Test Robustness> <⚠ Critical> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8155> | 16:47 |
| pedronis | mvo: #8153 needs more work | 16:51 |
| mup | PR #8153: [RFC] "snap run --explain" with different formating <Created by mvo5> <https://github.com/snapcore/snapd/pull/8153> | 16:51 |
| mborzecki | pedronis: cmatsuoka: i've updated #8156 | 16:52 |
| mup | PR #8156: cmd/snap-bootstrap: subcommand to detect UC chooser trigger <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8156> | 16:52 |
| mborzecki | pedronis: as for naming, snap-boostrap core-chooser-trigger and snapd.core-chooser-trigger.service ? | 16:54 |
| ackk | mvo, I started a bionic container and installed maas there on my other machine which is running focal, snapfuse is not using cpu there | 16:55 |
| cachio | pstolowski, done | 16:55 |
| cachio | pstolowski, thanks for the heads up | 16:55 |
| pedronis | mborzecki: s/core/recovery/ | 16:56 |
| mborzecki | pedronis: recovery-chooser-trigger? | 16:56 |
| mvo | ackk: oh? so on focal things are working for you? | 16:56 |
| ackk | mvo, it seems so, I wonder what happens if I update my laptop | 16:56 |
| pedronis | mborzecki: yes | 16:57 |
| pstolowski | cachio: yw | 16:59 |
| mvo | ackk: but I can reproduce the "keeps hogging cpu" issue in bionic | 17:02 |
| ackk | mvo, oh, "good" | 17:02 |
| pstolowski | cachio: i think only 19.10 and 20.04 images need to be re-downloaded often | 17:04 |
| mvo | ackk: but I see a ton of run-supervisorctl restart <lots-of-services> in my ps output, so the snapfuse might be legit traffice because of all this activity in the container? | 17:05 |
| mvo | ackk: like literally >200 supervisorctl restart | 17:06 |
| mvo | ackk: is that expected? also it seems like its not actually restarting :( | 17:06 |
| mvo | ackk: and the number fluctuates | 17:06 |
| mvo | ackk: like I had 206 some moments ago, now 211, then 214, 215 | 17:06 |
| mvo | ackk: now 217 | 17:07 |
| pedronis | #8130 and #8136 could use a 2nd review | 17:07 |
| ackk | mvo, you mean there are that many processes in parallel running? | 17:08 |
| mup | PR #8130: overlord, state: don't abort changes if spawn time before StartOfOperationTime (2/2) <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8130> | 17:08 |
| mup | PR #8136: boot: write current_kernels in bootstate20, makebootable <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8136> | 17:08 |
| mvo | ackk: correct | 17:09 |
| mvo | ackk: I added that to the bugreport too | 17:09 |
| ackk | mvo, can you check /var/snap/maas/common/log/supervisor-run.log ? | 17:10 |
| mvo | ackk: I see a lot of waiting/stopped/spawned | 17:11 |
| mvo | ackk: I can try to scp but i'm at >1600 process right now and I think this will soon OOM | 17:11 |
| mvo | ackk: I am using 2.7/edge maybe edge was not a good idea :) | 17:11 |
| ackk | mvo, you might wanna snap stop maas | 17:11 |
| zyga | master is fixed, right? | 17:11 |
| ackk | o | 17:11 |
| pedronis | zyga: I have seen green things | 17:12 |
| ijohnson | zyga: snapd-failover should be good now with mvo's PR | 17:12 |
| ackk | mvo, oh, yeah although I don't think there's much difference with stable | 17:12 |
| zyga | superb news | 17:12 |
| ijohnson | can't speak to other things | 17:12 |
| zyga | thank you everyone who pushed towards fixing that bug :) | 17:12 |
| mvo | ackk: http://paste.ubuntu.com/p/MkgJwgfhnf/ | 17:12 |
| mvo | zyga: yeah, master should be green | 17:13 |
| mvo | zyga: thank ijohnson mostly | 17:13 |
| zyga | Thank you ijohnson :) | 17:13 |
| mup | PR snapd#8164 closed: snap: use the actual staging snap-id for snapd <Simple 😃> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8164> | 17:13 |
| mvo | ackk: should I attach the log to the bugreport too? | 17:13 |
| mvo | ackk: I wonder if maybe this is causing this heat/cpu issue | 17:13 |
| ackk | mvo, if you could grab a tarball of the whole log/ dir it would be great | 17:14 |
| ackk | mvo, I can take a look at that | 17:14 |
| mborzecki | pedronis: cool, pushed the naming update to #8156, it'd be great if mvo, cmatsuoka or ijohnson could take a look | 17:15 |
| mup | PR #8156: cmd/snap-bootstrap: subcommand to detect UC chooser trigger <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8156> | 17:15 |
| ijohnson | mborzecki: I'll try to take a look today, it was on my queue of things to look at | 17:15 |
| cmatsuoka | mborzecki: will check asap, will finish a debug run here first | 17:16 |
| mvo | ackk: sure, I will do and attach to the bug(?). it looks huge though | 17:16 |
| mborzecki | ijohnson: cmatsuoka: if there's anything super silly feel free to push a patch, i'll pick it up in the morning | 17:16 |
| ackk | mvo, yeah if you don't want to attach it just put it somewhere and I can download it | 17:17 |
| ijohnson | mborzecki: sounds good | 17:17 |
| mvo | ackk: the gzip version of this dir is ~1.2Gb | 17:19 |
| ackk | oh boy | 17:19 |
| mvo | ackk: yeah, I will upload to some gdrive, not sure if LP will like it if I attach to the bugreport | 17:20 |
| ackk | heh | 17:22 |
| mup | PR snapd#8169 opened: [wip] tests/many: don't use StartLimitInterval, StartLimitBurst anymore <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8169> | 17:23 |
| ackk | mvo, thanks, I think you're probably now hitting some bug | 17:25 |
| ackk | mvo, how did you reproduce the issue btw? just installing in a bionic container? | 17:25 |
| mvo | ackk: correct. it's outlined in the original bug. I did use a clean 19.10 eon VM with 8g ram | 17:25 |
| mvo | ackk: then installed snapd and lxd | 17:25 |
| mvo | ackk: then lxd init with btfs as backend | 17:26 |
| ackk | mvo, weird, on this focal machine I don't even see snapfuse using CPU while maas init is running | 17:26 |
| mvo | ackk: then created an "lxc launch images:ubuntu/18.04 container" and "lxc exec <image> bash" and installed maas in there and ran "maas init" | 17:26 |
| mvo | ackk: that's pretty cool, at least it means this problem will go away :) | 17:27 |
| zyga | mvo: snap-confine bug? | 17:27 |
| mvo | ackk: but yeah, frustrating | 17:27 |
| mvo | zyga: do you have more details? | 17:27 |
| ackk | mvo, yeah I hope so. I'll try upgrading my laptop to focal, the installer was crashing on me before, have to try a more recent daily | 17:27 |
| zyga | mvo: no, I'm asking what this is about but now I see this is the snapfuse perf bug | 17:27 |
| mvo | zyga: aha, yes, that's correct | 17:27 |
| mvo | zyga: trying to reproduce their issue but no luck and apparently hitting a different bug | 17:28 |
| zyga | mvo: what did you hit? | 17:28 |
| ackk | mvo, it might be related, because I also usually see supervisord-managed process restarting a lot, but never seen so many running supervsiorctl calls | 17:29 |
| mvo | zyga: I don't know but it's some sort of (slow) fork bomb | 17:29 |
| mvo | ackk: interessting! | 17:29 |
| ackk | mvo, I thought the restarts would be beacuse of timeouts caused by processes being slowed down by snapfuse | 17:30 |
| mvo | ackk: could be but my VM is pretty fast, it's an ssd and has enough ram and the cpu load is not that high. still a possiblity of course | 17:32 |
| mvo | ackk: shared my dir with you, please let me know if you need anything else before I stop this vm again | 17:37 |
| mup | PR snapd#8170 opened: snap-preseed: support for preseeding of snapd and core18 <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8170> | 17:39 |
| ackk | mvo, can you try starting the maas snap again? just to confirm if it starts happening again | 17:48 |
| ackk | mvo, (downloading logs as we speak) | 17:50 |
| mup | PR snapd#8167 closed: o/standby: add SNAPD_STANDBY_WAIT to control standby in development <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8167> | 17:50 |
| ijohnson | pstolowski: reviewed 8003 | 17:52 |
| pstolowski | ijohnson: thank you! if it's green then i'd like to land it and address your suggestions in a followup; if it fails then i'll push to this PR | 17:57 |
| ijohnson | pstolowski: sounds good | 17:57 |
| ijohnson | seems travis is clogged up with jobs :-/ | 18:07 |
| === ijohnson is now known as ijohnson|lunch | ||
| pedronis | we opened too many new PRs especially considering that master was red | 18:09 |
| ijohnson|lunch | yeah but this actually happens pretty regularly in the afternoon my TZ, not sure why, but my thinking is that everyone in EU submits things before they log off | 18:10 |
| === ijohnson|lunch is now known as ijohnson | ||
| * ijohnson -> dentist | 18:44 | |
| NickZ | check yo teef | 18:50 |
| kenvandine | jdstrand: it looks like firefox isn't auto-connecting the pulseaudio plug anymore https://twitter.com/thecalmsprings/status/1230542924489875457 | 18:56 |
| kenvandine | love getting bug reports via twitter :) | 18:56 |
| jdstrand | kenvandine: that's weird. I grandfathered that | 18:58 |
| * jdstrand fixes and investigates | 18:58 | |
| kenvandine | jdstrand: thanks | 18:58 |
| mvo | ackk: sure, let me retry this | 18:59 |
| mvo | ackk: seems to be happening again, I see proxy, ntp, syslog | 19:00 |
| mvo | ackk: then proxy again, it's now at 15 | 19:00 |
| mvo | ackk: now at 46 | 19:04 |
| mup | PR snapd#8149 closed: snapmgr, backends: maybe restart & security backend options <Preseeding 🍞> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8149> | 19:08 |
| * ijohnson -> back | 19:50 | |
| ijohnson | cachio: do you have a reliable way to reproduce that issue with snapd-failover you had the other morning, i.e. where in the logs snap-failure couldn't start snapd.socket because the socket file already exists? I have a fix for that I'd like to confirm if it works but I have never been able to reliably reproduce that error condition | 20:24 |
| mup | PR snapd#8165 closed: cmd/snap-confine: fix everything flagged by coverity <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8165> | 20:25 |
| zyga | this PR title is a lie, there are three left that weren't "new" | 20:38 |
| zyga | oh well | 20:38 |
| cachio | ijohnson, yes I have | 20:44 |
| cachio | but I am leaving in 2 mins | 20:44 |
| cachio | I ll be back in 2 hours | 20:44 |
| cachio | or just telegram me | 20:45 |
| ijohnson | cachio: no problem, it can wait til tomorrow | 20:45 |
| ijohnson | I will mention you on the PR I open I think, so if you could comment there tomorrow that would be great | 20:45 |
| cachio | ijohnson, sure | 20:46 |
| cachio | when I am back I'll comment | 20:46 |
| cachio | sorry but I was working with the new arch image | 20:47 |
| * cachio afk | 20:48 | |
| ijohnson | cachio: no problem, ttyl | 20:48 |
| cmatsuoka | debug tpm unlocking inside the initrd is painful | 21:01 |
| ijohnson | sounds quite painful | 21:07 |
| raer | Hope this works now: Hey snap people. A question regarding an issue (https://github.com/keepassxreboot/keepassxc-browser/issues/439) with the KeepassXC browser plugin (Firefox, Chromium) talking to KeepassXC through NativeMessaging. Afaik this won't work with snap-packaged apps, because of sandboxing / security. | 21:07 |
| raer | Ah. That looks better... | 21:07 |
| mup | PR snapd#8171 opened: cmd/snap-failure/snapd: also rm snapd.socket if it still exists <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8171> | 21:08 |
| raer | What would be the "correct" solution to connect e.g. a browser plugin to an application ouside of the sandbox? | 21:09 |
| ijohnson | raer: it depends, I suggest starting a post on forum.snapcraft.io where more folks will be available to look at your issue | 21:10 |
| raer | I'm reluctant to open that box... | 21:11 |
| ijohnson | raer: AFAIK it's a known problem and oSoMoN has a bug filed somewhere about this issue with the chromium snap specifically | 21:11 |
| raer | https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1741074 ? | 21:12 |
| ijohnson | (and notable oSoMoN is offline right now) | 21:12 |
| mup | Bug #1741074: [snap] chrome-gnome-shell extension fails to detect native host connector <snap> <chromium-browser (Ubuntu):Triaged> <https://launchpad.net/bugs/1741074> | 21:12 |
| raer | dat :) | 21:12 |
| ijohnson | it seems so | 21:12 |
| ijohnson | I'm not familiar enough with the chromium snap to answer myself without more details about how plugins work with chromium and you're sure to find the right folks on the forum so that would be my recommendation | 21:13 |
| ijohnson | you could also try asking in EU tz morning time | 21:13 |
| raer | It is broken for 2 years now | 21:13 |
| raer | A workaround is to install from repo, which is kind of ridiculous. | 21:14 |
| raer | Might ask oSoMoN in the morning. Not keen on signing up for yet another forum... | 21:15 |
| ijohnson | if you have a LP account I believe that the ubuntu forums at discourse.ubuntu.com are tied to your LP account so you don't have to create another account | 21:16 |
| ijohnson | and oSoMoN is around there as well | 21:16 |
| raer | ok. thanks. | 21:17 |
| NickZ | ijohnson: did you ever get multipass working on the raspberry pi 4? | 21:20 |
| ijohnson | NickZ: no I haven't tried for some time, but I think the required kvm options were added to the kernel now | 21:21 |
| ijohnson | NickZ: IIRC there was some other problem with multipass not qemu/kvm related | 21:21 |
| NickZ | yeah, I was lookinga t your issue | 21:21 |
| NickZ | that issue seems resolved now, but im having another one | 21:21 |
| NickZ | I was just wondering if anyone else had gotten this working | 21:22 |
| ijohnson | what's the new issue ? | 21:22 |
| Saviq | NickZ: do you know if Pi3 kernel also got those? | 21:23 |
| NickZ | can't say, haven't tried, although I heard that hardware virtualization is only supported on arm64 hosts | 21:24 |
| NickZ | ijohnson: https://github.com/canonical/multipass/issues/1376 | 21:24 |
| Saviq | NickZ: thanks, we'll have a look - it's weird that -machine would be required, maybe the default can be set somewhere | 21:26 |
| ijohnson | hmm yeah I can't say I know anything about that but I bet Saviq can be of more help :-) | 21:26 |
| NickZ | yeah, it seems unique for raspi hosts, dunno why | 21:27 |
| mup | PR snapd#8157 closed: tests: using google storage when downloading ubuntu cloud images from gce <Simple 😃> <Created by sergiocazzolato> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8157> | 21:39 |
| mup | PR snapd#8172 opened: snapcraft.yaml: add python3-apt, tzdata as build-deps for the snapd snap <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8172> | 22:06 |
| cmatsuoka | ijohnson: found the problem | 23:19 |
| ijohnson | cmatsuoka: what was the problem? | 23:27 |
| cachio | ijohnson, hey | 23:41 |
| cachio | ijohnson, I'll run the test in a loop | 23:42 |
| cachio | the fix is in the code? or in the tests? | 23:43 |
| ijohnson | cachio the fix in the PR I mentioned was in the code for snap-failure | 23:44 |
| ijohnson | At least what I think is a fix | 23:44 |
| ijohnson | I don't entirely understand the root cause but this should at least let snap-failure get past the issue and still recover | 23:45 |
| cachio | ijohnson, mmmm, in that case it is not so simple to test | 23:45 |
| cachio | because I need to create an image with the fix | 23:45 |
| cachio | is this PR still open? | 23:46 |
| ijohnson | Yes one sec let me get you the link | 23:46 |
| ijohnson | cachio: https://github.com/snapcore/snapd/pull/8171 | 23:46 |
| mup | PR #8171: cmd/snap-failure/snapd: also rm snapd.socket if it still exists <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8171> | 23:46 |
| cachio | ijohnson, I'll run it in google | 23:48 |
| cachio | ijohnson, the other way I can reproduce it is difficul because I need an image | 23:48 |
| ijohnson | Great, the tests all passed for that PR in Travis which is a good sign | 23:48 |
| ijohnson | cachio it can certainly wait til tomorrow to | 23:48 |
| ijohnson | *too | 23:49 |
| cachio | ijohnson, yes, I'll test it tonight and add a note in the PR | 23:49 |
| ijohnson | Awesome thanks | 23:51 |
| cachio | yaw | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!