/srv/irclogs.ubuntu.com/2020/12/02/#snappy.txt

=== ijohnson|lunch is now known as ijohnson
mupPR snapd#9720 closed: many: rename disks.FindMatching... to FindMatching...WithFsLabel and err type <Squash-merge> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9720>02:02
mupPR snapd#9719 closed: boot: set kernel command line in modeenv during install  <Run nested> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9719>06:09
mupPR snapd#9727 closed: seed: cleanup/drop some no longer valid TODOS, clarify some other points <Run nested> <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9727>06:14
mborzeckimorning06:53
mupPR snapd#9725 closed: bootloader: remove installableBootloader interface and methods <Cleanup :broom:> <Simple 😃> <Skip spread> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9725>07:59
mborzeckipstolowski: hey08:05
pstolowskiheya08:06
mupPR snapd#9713 closed: tests: sign new nested-18|20* models to allow for generic serials <Run nested> <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9713>08:09
zygahey guys08:16
mborzeckizyga: hey08:26
mborzeckiupdated the spread test in #9724 and current_kernel_command_lines is not populated after reboot, hmm hmm08:27
mupPR #9724: boot: observe successful command line update, provide a default  <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9724>08:27
mvogood morning pstolowski and mborzecki08:34
mborzeckimvo: hey08:35
pedronishello08:45
pedronispstolowski's #9409 needs 2nd reviews08:45
mupPR #9409: cmd/snap: implement 'snap validate' command <validation-sets :white_check_mark:> <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9409>08:45
mvopedronis: good morning, let me have a look08:46
pedronismvo: are you blocked on it for something atm?  #9709 seems to need a couple of typo fixes but then could land08:46
pstolowskity08:46
mupPR #9709: snapshotstate: improve handling of multiple errors <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9709>08:46
mvopstolowski: 9409 is still marked as blocked, is that still accurate08:47
mvopedronis: review for 9705 would be great08:47
mvopedronis: otherwise not really blocked08:47
pedronismvo: was it updated? I missed that08:47
pstolowskimvo: kind of, i think we may want to land it close to the followups otherwise it won't do anything08:47
mvopedronis: yeah, last evening08:48
mborzeckihmmmm so spread test failed, but it works in local testing in a vm08:48
mvopstolowski: ok, I have a look08:48
pedronismvo: ah, I looked at it but never did anything active so I'm not getting emails about it, sorry08:48
mvoI need a second review for 971808:48
mvopedronis: no worries08:48
pedronismborzecki: you have a bunch of small comments on #9724, but you likely saw that08:50
mupPR #9724: boot: observe successful command line update, provide a default  <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9724>08:50
mborzeckipedronis: yup, trying to figure out the mystery of spread test first08:50
pedronismvo: at some point last nigh GH actions were failing internally? is that fixed now08:51
pedronis*night08:51
mvopedronis: I noticed this too, I restarted some PRs early in my morning, need to double check08:51
mvopedronis: hm, I'm pretty sure I restarted the macos test in 9731 but it appears to be still failing for unknown/internal reasons08:52
* mvo tries again08:52
pedronisit has one passing and one failed08:53
mvoyes, same here08:53
pedronisit's even stranger08:53
mvoindeed08:53
mvonow it's running and looking okay but still strange that we have two08:53
pedronismvo: do you want me to pick up the small fixes to #9709 ?08:54
mupPR #9709: snapshotstate: improve handling of multiple errors <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9709>08:54
mvopedronis: sure, if you have time/want to I would be happy08:54
mvopedronis: but only if it's no burden08:54
mupPR snapd#9732 opened: asserts: snapasserts method to validate installed snaps against validation sets <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9732>08:59
pstolowskipedronis: ^09:15
pedronispstolowski: I saw it thx09:15
mborzeckiheh, so a race between the test checking mdoeenv and snapd updating it09:16
=== pedronis_ is now known as pedronis
pedronismborzecki: this is mark successful?09:23
mborzeckipedronis: yes09:23
pedronismborzecki: I don't think we have a nice way to know ran Ensure at least once09:29
mborzeckipedronis: yeah, for now i'm using nested_retry_until_successful, which should be good enough09:30
pedronismvo: tweaks ended up slightly larger than I expected, please double check quickly: https://github.com/snapcore/snapd/pull/9709/commits/6d07df7ce8a261b032b0a963cd40881bd0134bdc09:33
mupPR #9709: snapshotstate: improve handling of multiple errors <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9709>09:33
mvopedronis: sure thing, let me look09:35
mvopedronis: nice! yeah, I like that09:36
mvopedronis: thank you!09:36
zygamvo hey09:54
zygaone job running on my infra, I'll shut down half when it finishes09:54
mvopstolowski: I reviewed 9409 (probably also worth for pedronis to quickly look as I had one output question)09:56
mvozyga: great, thanks09:56
pedronismvo: I looked at #9705, some meta questions there09:58
mupPR #9705: devicestate: add runFDESetupHook() helper <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9705>09:58
pstolowskimvo: thank you!09:58
pedronismvo: most of the output comes from the spec09:58
pedronisbut I will double check09:58
pedronismvo: let me know if we need to chat about 970509:59
mvopedronis: cool, let me look at 9705, I will let you know10:00
pedronispstolowski: having a short break and then I will look at the validate PRs, command one, and the new one10:05
pstolowskipedronis: thanks10:07
mupPR snapd#9709 closed: snapshotstate: improve handling of multiple errors <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9709>10:40
pedronis#9513 needs a master merge now10:48
mupPR #9513: snapshotstate: detect duplicated snapshot imports <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9513>10:48
mvopedronis: thanks, will do (just looking to tweak some things in 9705)10:58
ograhmm ... i'm getting popup notifications about snapd not being able to update the snap-store app ...11:44
mvoogra: that's because it is in use right now11:45
ograthe snap-store keeps its backend permanently running even if you close the app11:45
ograand there is no way for users to stop it11:45
ograit isnt in use ... thats the point 🙂11:45
mvoogra: yeah that's a problem, I guess we need help from the desktop team to make this possible11:45
ograthe only wy to stop it is to fish the process out of the process list and kill it manually ... even if the UI is closed11:46
pstolowskipedronis, mvo i've pushed tweaks to #9409,  most notably added helpers and reused regexps that already existed in asserts, and made 'snap validate' hidden so we can land it11:46
mupPR #9409: cmd/snap: implement 'snap validate' command <validation-sets :white_check_mark:> <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9409>11:46
ogramvo, but gerat to see the notification work !11:46
ogra*great even11:46
mvopstolowski: nice, thanks so much!11:54
pstolowskithere is just one remaining comment re "invalid ..."11:56
pstolowskilet me know if my suggestion makes sense11:56
mupPR snapd#9731 closed: daemon: split out snapctl support and snap configuration support to their own api_*.go files <Cleanup :broom:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9731>12:00
pedronispstolowski: using %w is what we want but it makes 1.9 unhappy, you need to use fmt := on a separate line, maybe const works also12:04
pedronispstolowski: there are examples already12:04
pstolowskipedronis: ah, ok12:04
pstolowskiright, i can see it, thanks12:05
cachiopstolowski, hi12:05
cachiowhen you have time, could you please take a look to #947912:05
mupPR #9479: tests: replace pkgdb.sh (library) with tests.pkgs (program) <Created by zyga> <https://github.com/snapcore/snapd/pull/9479>12:05
pstolowskihi cachio, sure12:07
* pstolowski lunch12:10
mvopstolowski: thanks for the update to the PR!12:12
pedronispstolowski: did another pass, sorry a bit of nitpicking about names, https://github.com/snapcore/snapd/pull/9409#pullrequestreview-54276918012:20
mupPR #9409: cmd/snap: implement 'snap validate' command <validation-sets :white_check_mark:> <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9409>12:20
* cachio afk12:24
pedronispstolowski: also I wonder if we really use name as you say here: https://github.com/snapcore/snapd/pull/9409/files#r534061494, but I commented asking about that12:25
mupPR #9409: cmd/snap: implement 'snap validate' command <validation-sets :white_check_mark:> <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9409>12:25
mvopedronis: I did the master merge for 9513 now and also updated 9705, let me know if that makes sense, if not we should proably have a quick chat before the standup ho12:31
mvopstolowski: do you think you could have a look at 9718? should be pretty straightforward hopefully12:32
pedronismvo: 9705 looks good, but 9718 should probably land first because fdesetup gets moved12:41
pedronisand it will be a bit messy12:41
pedronismvo: commented on #970512:44
mupPR #9705: devicestate: add runFDESetupHook() helper <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9705>12:44
pstolowskimvo: yes, i can take a look (after standup most likely)13:05
pedronispstolowski: left some initial high-level comments in #9732 , let me know if you have questions13:12
mupPR #9732: asserts: snapasserts method to validate installed snaps against validation sets <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9732>13:12
pstolowskipedronis: thanks, will check shortly13:13
ijohnsonmorning folks13:38
mupPR snapd#9733 opened: tests: New queries for the os tools <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9733>13:51
ijohnson#9721 is pretty simple and could use some reviews :-D14:42
mupPR #9721: osutil/disks: add FindMatchingPartitionUUIDWithPartLabel to Disk iface <Simple 😃> <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9721>14:42
mvoijohnson: looking14:47
ijohnsonthanks!14:49
mupPR snapd#9734 opened: Add support additional camera/capture devices <Created by flexiondotorg> <https://github.com/snapcore/snapd/pull/9734>14:51
pedronismborzecki: #9721 maybe is something you could look at as you reviewed the other code there?15:15
mupPR #9721: osutil/disks: add FindMatchingPartitionUUIDWithPartLabel to Disk iface <Simple 😃> <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9721>15:15
=== King_InuYasha is now known as Conan_Kudo
=== Conan_Kudo is now known as King_InuYasha
ijohnsonmborzecki: do you have a link to that forum post where you investigated why systems with many snaps are slow to boot because the mounting of the squashfs files conflicts with each other and they end up trying to get mounted in many different places? I think it would be good to at least explain to this person why snaps make their boot slow:15:24
ijohnsonhttps://forum.snapcraft.io/t/how-do-i-stop-snaps-mounting-during-boot-on-ubuntu-18-04/2143415:24
mborzeckiijohnson:  i looked at some things here: https://forum.snapcraft.io/t/snapd-causing-lengthy-boot-time/10466/6?u=mborzecki15:26
ijohnsonmborzecki: ah yes that was exactly what I was thinking about15:28
ijohnsonthanks!15:28
=== King_InuYasha is now known as Conan_Kudo
dot-tobiasdegville: Controlling service startup order with before/after keywords is documented for “the snap format”, but it's missing both from “apps and services metadata” and “Snapcraft.yaml format” pages. Is this intentional? If not, I'll suggest a change on the respective forum threads.15:31
=== Conan_Kudo is now known as King_InuYasha
degvilledot-tobias: no, it's not intentional. It's definitely something we should add - thanks for flagging it.15:33
ijohnsonmvo: pedronis: could one of you sudo merge 9721, it has 2 +1s, but it failed due to 429s from the store15:37
mvoijohnson: sure, let me do that15:37
ijohnsonmvo: thanks!15:37
ijohnsonbtw should we be retrying 429's ?15:37
ijohnsonseems like yes ?15:37
ijohnsonbut on a exponential backoff or something since 429 is too many requests15:37
mvoa second review for 9718 would be great15:38
ijohnsonlike this seems wrong:15:38
ijohnsonretry.go:184: DEBUG: Not retrying: &errors.errorString{s:"too many requests"}15:38
ijohnsonmvo: sure I will add it to my queue15:38
mvota15:38
mupPR snapd#9721 closed: osutil/disks: add FindMatchingPartitionUUIDWithPartLabel to Disk iface <Simple 😃> <Squash-merge> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9721>15:41
pedronisijohnson: we already have logic that try to spread out catalog refresh requests but it might be a bit too naive on restarts15:44
ijohnsonpedronis: well I didn't read the code, just that reading the debug log messages is what confused me. are you saying that we do catalog refreshes at a higher level than the http retry itself?15:44
pedronisijohnson: yes, retrying with backoff on 429 is probably not useful15:45
pedronisbecause the backoff needed would be larger than anything practical15:45
ijohnsonmmm fair enough15:45
pedronisfor most operations15:45
ijohnsonyeah that makes sense15:46
pedronisor at least for the sitatuons were it matters atm15:46
pedronisthis might just be hopeless to be clear atm15:46
=== King_InuYasha is now known as Conan_Kudo
=== Conan_Kudo is now known as King_InuYasha
dot-tobiasdegville: re before/after docs https://forum.snapcraft.io/t/snapcraft-app-and-service-metadata/8335/8?u=tobias and https://forum.snapcraft.io/t/snapcraft-yaml-reference/4276/43?u=tobias15:51
degvilledot-tobias: thank you! I'll merge those in asap.15:52
dot-tobiaswelcome, glad to contribute to docs as a way to say thanks 😊15:52
ijohnsonmvo: pedronis: could you also sudo merge #9729, it is very red on 429's though there is one interesting lxd failure that I have saved the logs for and is not at all related the lkenv changes there15:57
mupPR #9729: bootloader/lkenv: specify backup file as arg to NewEnv(), use "" as path+"bak" <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9729>15:57
mvoijohnson: sure15:58
pedronisijohnson: done15:58
ijohnsonthen I can update the full pr with everything15:58
pedronismvo: done already15:58
ijohnson\o/15:58
ijohnsonthanks!15:58
pstolowskimvo: 2 questions under 5918, +115:59
mupPR snapd#9729 closed: bootloader/lkenv: specify backup file as arg to NewEnv(), use "" as path+"bak" <Simple 😃> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9729>16:01
mvopstolowski: thank you!16:02
pstolowskiof course it was 9718, not sure how I came up with that other number ;16:05
pstolowski;)16:05
pedronispstolowski: I wondered :)16:13
pstolowskiheh16:13
blackboxswhi folks, question out of left field. In early boot on azure vms.  I run into the following error trying to install a snap: Failed running command '/usr/bin/snap install canonical-livepatch' [exit(1)]. Message: error: cannot perform the following tasks:  Run configure hook of "canonical-livepatch" snap if present (run hook "configure": cannot perform operation: mount --bind /snap/core/current/etc/apparmor17:50
blackboxsw/tmp/snap.rootfs_F0mewd/etc/apparmor: Permission denied)17:50
blackboxswmight this be related to a condition installing additional snaps too soon after waiting on snapd.seeded? We run ' /usr/bin/snap wait system seed.loaded' before trying to install any snaps.    But I'm getting failures like this: https://bugs.launchpad.net/snapd/+bug/167419317:52
mupBug #1674193: core snap's configuration hangs on debian | openSUSE | mainline kernel <snapd:Fix Released by morphis> <snapd (Debian):Fix Committed> <snapd (Fedora):Fix Committed by morphis> <snapd (openSUSE):Fix Released by morphis> <https://launchpad.net/bugs/1674193>17:52
blackboxswI am able to snap install canonical-livepatch shortly after initial boot, so this is a racy/early-boot problem17:53
blackboxswcore  16-2.48  10444  latest/stable  canonical✓  core  (bionic, kernel:5.4.0-1031-azure)  for reference18:02
blackboxswwill dig to get more details now. was just wondering about known apparmor type concerns in early boot18:03
=== ijohnson is now known as ijohnson|lunch
ijohnson|lunchblackboxsw: tbh that looks like a bug in the snap itself, but I would need to look more when I get back from lunch in the meantime have you asked the livepatch folks about the snap?18:11
* cachio afk18:53
mupPR snapd#9735 opened: gadget: disable ubuntu-boot role validation check <Created by mvo5> <https://github.com/snapcore/snapd/pull/9735>19:57
mupPR snapd#9733 closed: tests: New queries for the os tools <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9733>20:02
=== ijohnson|lunch is now known as ijohnson
mupPR snapd#9736 opened: o/devicestate: save model with serial in the device save db <Run nested> <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9736>20:47
blackboxswijohnson: thanks. I pinging in livepatch and they hadn't seen that issue previously either. It could be a case of slow platform response for snap installs and setup. I'll try adding retries on the command to see if that avoids a racy21:02
blackboxswcondition21:02
blackboxswas it is we retry snap install canonical-livepatch 3 times anyway21:03
blackboxswwith a backoff 0.5 1 and 5 seconds21:03
ijohnsonblackboxsw: ok, do you have more logs in that bug? or better yet do you have a shell on such an affected machine?21:06
blackboxswijohnson: I'll try reproducing on an azure PRO vm and see if I can cause it repeatedly.  If I can, I'll present an IP here of the affected vm for inspection21:07
blackboxswthanks BTw21:07
mupPR snapd#9737 opened: tests: use os.query tool instead of comparing the system var <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9737>21:08
ijohnsongreat, thank you21:08
jaceknaxino: /names21:23
mupPR snapd#9735 closed: gadget: disable ubuntu-boot role validation check <Run nested> <UC20> <⚠ Critical> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9735>22:03
blackboxswijohnson: couldn't reproduce snap install canonical-livepatch failures on multiple launches. Will bring it up again if I can trigger the failure mode23:24
ijohnsonblackboxsw: ok, if you are able to reproduce please get a system journal with `journalctl --no-pager`?23:54
ijohnsonAnd file a bug with that journal23:55
blackboxswijohnson: will do. I note that I may have interrupted the system's initial boot on this machine in my integration test that exhibited the issue, so I could have possibly disrupted initial snap core setup.23:56
blackboxswwill grab logs if it happens again23:56
ijohnsonGreat thank you23:57

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