/srv/irclogs.ubuntu.com/2020/11/19/#snappy.txt

mupPR snapd#9556 closed: tests: testing new fedora 33 image <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9556>02:30
zyga-x240good morning mvo07:09
zyga-x240mvo: I had a look at the changes to the export manager but ended up just going to sleep yesterday; I think today may be better as lately we are sleep deprived by Lucy who is going through the 2-yo hyperactivity phase07:10
mupPR snapd#9664 closed: spread: disable unattended-upgrades on ubuntu <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9664>07:11
mvogood morning zyga-x24007:14
mvozyga-x240: no worries! thanks for letting me know07:14
mupPR snapd#9652 closed: o/servicestate: unlock state before calling wrappers in doServiceControl <Bug> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9652>07:22
zyga-x240mvo: I saw that the uboot bug was addressed07:23
zyga-x240mvo: I understand this unblocks gadget updates across the pi lineup07:24
zyga-x240mvo: and that this was an additional blocker for uc2007:24
mvozyga-x240: yeah, it's pretty good07:24
mvozyga-x240: I need to check if we have updated pi/edge already07:24
mvozyga-x240: but the debs got udpated, once that is in we will look into fixing it on a broader scope07:25
zyga-x240mvo: the debs got updated yes07:25
zyga-x240please note that while great, this makes the pi break on the dbt skew07:26
zyga-x240only fresh installs are okay07:26
mvozyga-x240: yes, we are working on this too07:26
zyga-x240but it's inevitable07:26
zyga-x240I know, that's really cool07:26
mvozyga-x240: and there is work to use piboot so that we have proper a/b boot with dtbs, so it's advancing on all fronts07:26
mvo(also not as fast as I wish we would go)07:26
zyga-x240mvo: I heard about that as well, but I was not sure if that has already started to approach snapd side07:27
zyga-x240will it be another bootloader variant in our code or will there be some middleware-like abstraction via hooks07:27
mvozyga-x240: I think it will be bootloader like07:28
mvozyga-x240: maybe a variant of uboot, i.e. if uboot finds config.txt then it will behave slightly differently07:28
mvozyga-x240: but the details are not clear yet, we are still in the prototype phase for this07:28
zyga-x240mvo: I recall that there was some resitence from the pi foundation to help us in any way that would require code changes07:30
zyga-x240mvo: do you know how A/B or try mode boot will work?07:31
mvozyga-x240: dave told me he tested it from pi3 onward07:31
mvozyga-x240: but *maybe* we loose the pi2 :(07:31
mvozyga-x240: not sure yet, also this seems to be super recent firmware changes07:31
zyga-x240ah, that's reassuring then07:31
zyga-x240perhaps it is an improvement to the boot process07:32
zyga-x240any kind of conditionality or writable state accessible from the native bootloader is sufficient07:32
zyga-x240but you know that :)07:32
zyga-x240I hope they changed their minds on it07:32
mborzeckimorning07:33
zyga-x240hey mborzecki07:33
mborzeckifinally got my tires swapped to the winter set07:33
mvozyga-x240: I think they did but we helped them with that AIUI07:33
mvogood morning mborzecki07:34
zyga-x240mborzecki: just in time for global warming ;-)07:34
mborzeckizyga-x240: haha right07:34
mborzeckimvo: hey07:34
zyga-x240mborzecki: I really wish we have a month of -5 to -10 and lots of snow07:34
zyga-x240I miss that from my childhood07:34
mvomborzecki: when you have a few cycles, could you please look at 9497 ? hopefully straightforward07:34
mborzeckizyga-x240: no thanks ;) you're free to enjoy winter in canada though07:34
mborzeckimvo: sure07:35
zyga-x240mborzecki: could as well be a screen saver unless I'm there :)07:35
mvozyga-x240: or move to minessota07:35
mvozyga-x240: the cold there is quite impressive07:35
zyga-x240mvo: my new boss tries to move me to Italy instead ;-)07:35
zyga-x240I wish we had that magic house with a handle that can open in four different ways, to go to four different places07:36
mborzeckizyga-x240: tbh this sounds quite nice07:36
zyga-x240a house by the sea, a house in the mountains, in big city and that big black void IIRC07:36
mborzeckizyga-x240: move to the south and enjoy the all year round cycling season07:36
zyga-x240(I love that movie)07:36
zyga-x240mborzecki: well, now I'd be happy if lucy stopped running around at 1AM every day :)07:37
zyga-x240I guess that will pass07:37
mvozyga-x240: it will pass and in 10y happen again ;)07:38
mvozyga-x240: or maybe 15y07:38
zyga-x240mvo: yeah but when she has her own room that's okay :D07:38
mvozyga-x240: heh … good point!07:39
zyga-x240mvo: I will look at patching spread soon07:39
zyga-x240I'm split between a fork and proper upstream cooperation07:39
zyga-x240I'm going to add new backends to it07:40
zyga-x240mainly to use a muxpi-exposed ad-hoc new API as "cloud"07:40
zyga-x240initially a 1-1 but later 1-n model (one host talking to a number of configured muxpi's over lan, each exposing some real hardware and features)07:40
zyga-x240I guess time will tell, I haven't touched this yet07:40
mvozyga-x240: nice, looking forward to that07:45
mvozyga-x240: more spread development is most welcome07:45
mborzeckifun thing i noticed in the serial log of a failed test: ` Error syncing keystore file /usr/share/secureboot/updates/dbx/dbxupdate_x64.bin`08:03
zyga-x240interesting :)08:04
pstolowskimorning08:07
zyga-x240hey pawel :)08:07
pstolowskiheya08:07
mvohey pstolowski !08:20
pstolowskio/08:21
mborzeckipstolowski: hey08:27
mborzeckisomehow debug logs in #9640 make no sense08:27
mupPR #9640: tests/nested/manual/core20-save: verify handling of ubuntu-save with different system variants  <Run nested> <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9640>08:27
pstolowskimborzecki: hey; merge master, this will fix lxd-services-smoke failure08:31
mborzeckipstolowski: it's the test changed by the PR, the debug output makes no sense, things which should have been there given the environment variables are not present08:33
mborzeckiit's as if the env variables are not set, or something overwrites them08:33
pedronismborzecki: nested.sh might overwrite some stuff?08:36
mborzeckipedronis: it sets some things but it should not overwrite NESTED_{ENABLE_TPM,ENABLE_SECURE_BOOT,BUILD_SNAPD_FROM_CURRENT}08:37
mborzeckipedronis: otoh, the debug output suggest that NESTED_BUILD_SNAPD_FROM_CURRENT was not set, because the gadget snap was most likely not repacked08:38
pedronismborzecki: remember that there is some form of image caching08:39
pedronismaybe it's bugggy in terms of reusing things even if they were built with different params ?08:40
mborzeckipedronis: this is a manual test and supposedly nothing ran before it08:40
mvopedronis: I re-read your comments on 9667 again this morning - is https://github.com/snapcore/snapd/pull/9667/files#diff-3dedbc3a1986cf905aca293ca6d16560d297253859ecaa8bcea2b7dab7143b3cR1360 what you suggested?08:40
mupPR #9667: devicestate: implement boot.HasFDESetupHook <Skip spread> <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9667>08:40
pedronismvo: yes, that looks like what I had in mind08:41
mvopedronis: nice, let me add tests then08:41
pstolowskimborzecki: fwtw we do set NESTED_IMAGE_ID in some manual/ tests08:41
pedronismborzecki: spread bug?  I suppose you should sprinkle "env" calls around08:42
pedronismvo: ask my review again in it when you think it's ready08:51
mvopedronis: I just added tests, so a quick look would be good08:56
mborzeckimvo: what shall we do with #9633?08:56
mupPR #9633: github: run nested suite when commit is pushed to release branch <Run nested> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9633>08:56
pedronismvo: I put it back into my queue08:57
mvopstolowski: could you please have a look at 8943 when you have some spare cycles?09:17
pstolowskimvo: yes09:17
mvo\o/09:17
pstolowskiit has conflict though09:21
pstolowskijamesh: hey, can you merge master ^ if still around?09:22
jameshpstolowski: doing it now.09:23
pstolowskity09:24
jameshpstolowski: I've pushed up a fix for the merge conflict.  Thanks for looking into this.09:34
pstolowskijamesh: thanks, i'll get to it shortly09:45
mupPR snapd#9497 closed: usersession/agent: have session agent connect to the D-Bus session bus <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9497>09:52
mupPR snapd#9641 closed: o/servicestate: preserve order of services on snap restart <Bug> <Services ⚙️> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9641>09:52
mborzeckifunny how that core20-save test works just fine when running on google from local spread :/09:56
pedronismborzecki: I see some issues with #965910:19
mupPR #9659: osutil: add KernelCommandLineKeyValue; boot: refactor ModeAnd...FromKernelCommandLine <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9659>10:19
mborzeckipedronis: hm good catch label != "" and empty mode, looks like it would hit an internal error in cmd_initramfs_mounts in that case, and other call sites ignore the label and just look at the mode10:23
mborzeckiheh, gorename just paniced on me when trying to rename KernelCommandLineKeyValue10:31
mborzeckibacktrace --> https://paste.ubuntu.com/p/zcywxYtfB6/10:34
vidal72[m]jamesh: is this still needed for snap? https://github.com/flatpak/xdg-desktop-portal/pull/44310:45
mupPR flatpak/xdg-desktop-portal#443: Don't use AppArmor to detect snap confined clients <Created by jhenstridge> <https://github.com/flatpak/xdg-desktop-portal/pull/443>10:45
jameshvidal72[m]: yeah.  We'd like to get that in.10:46
jameshvidal72[m]: I can look at rebasing if that'd help10:46
vidal72[m]it may help yes10:47
jameshvidal72[m]: sorry for not being more active on this.  I got swamped with other work, and it wasn't clear what would have been needed to get it landed back then.10:54
mborzeckipedronis: i've updated #965911:05
mupPR #9659: osutil: add KernelCommandLineKeyValue; boot: refactor ModeAnd...FromKernelCommandLine <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9659>11:05
mborzeckimvo: are you updating #9667 or should i push the tweaks there?11:20
mupPR #9667: devicestate: implement boot.HasFDESetupHook <Skip spread> <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9667>11:20
pedronismborzecki: thx, will look in a bit11:37
mupPR snapd#9661 closed: osutil/disks: add DiskFromName to get a disk using a udev name <Simple 😃> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9661>12:08
pedronismborzecki: reviewed12:09
mborzeckipedronis: thanks, added a proposal of a name for that var in a comment12:20
ijohnsonmorning folks12:24
ijohnsonmborzecki: are you working on addressing pedronis' feedback on 965912:24
ijohnson?12:24
mborzeckiijohnson: yeah12:28
ijohnsonk, thank you !12:29
pedronismvo: I reviewed #965612:32
mupPR #9656: devicestate: support "storage-safety" defaults during install <Run nested> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9656>12:32
pedronisdegville: ijohnson: ^ there's a log message there where native speaker input could be valuable12:33
ijohnsonsure I can have a look12:33
ijohnsonresponded12:35
=== msalvatore_ is now known as msalvatore
pedronismborzecki: thx, better but I proposed a slight tweak on the name, sorry. mostly is unclear if "mock" is relevant there or not12:36
pedronisijohnson: thanks, your message sounds good to me12:38
ijohnsonpedronis: mvo: did y'all see my comment in the SU doc about the uc20 regression?12:39
degvillepedronis: ijohnson: me too, although I'm trying to think of something other than 'due', as it could imply prefer-unencrypted was unintentionally set.12:39
* ijohnson has no strong attachment to the word "due"12:39
pedronisah, language is hard12:40
pedronisijohnson: yes, sounds something to discuss in the standup12:40
degvilleturtles all the way down.12:40
ijohnsonpedronis: ok12:40
* pstolowski lunch13:00
mvomborzecki: \o/ for updating 966713:34
mvopedronis: thanks for the review!13:35
pedronispstolowski: is #9409 ready for re-reviews?13:38
mupPR #9409: cmd/snap: implement 'snap validate' command <validation-sets :white_check_mark:> <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9409>13:38
mupPR snapd#9667 closed: devicestate: implement boot.HasFDESetupHook <Skip spread> <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9667>13:38
mupPR snapd#9670 opened: devicestate: make checkEncryption fde-setup hook aware <Created by mvo5> <https://github.com/snapcore/snapd/pull/9670>13:43
pstolowskipedronis: yes13:46
pedronispstolowski: ok, I put it back into my queue13:49
mupPR snapd#9660 closed: gadget/gadget.go: allow system-recovery-{image,select} as roles in gadget.yaml <Needs Samuele review> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9660>13:53
mupPR snapcraft#3381 opened: multipass build provider: check if instance exists before deleting <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3381>14:21
mborzeckipstolowski: pushed a commit with NESTED_IMAGE_ID to #964014:30
mupPR #9640: tests/nested/manual/core20-save: verify handling of ubuntu-save with different system variants  <Run nested> <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9640>14:30
pedronispstolowski: are you blocked right now?14:37
mupPR snapd#9659 closed: osutil: add KernelCommandLineKeyValue; boot: refactor ModeAnd...FromKernelCommandLine <Squash-merge> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9659>14:38
ijohnson\o/14:39
mvothanks ijohnson !14:39
ijohnsonthanks for merging mvo!14:40
pstolowskipedronis: not really; but i think i won't start new validation sets PR until existing ones are ok'ed?14:41
pedronispstolowski: mostly asking if a re-review of the client one can wait tomorrow?14:41
pstolowskipedronis: yes that's fine. when you ack the client api bit then i'll update the second existing PR to match14:42
mvo8929 needs a second review, should be relatively easy I hope14:51
* cachio lunch14:54
pstolowskilooking16:16
pstolowski+116:28
jdstrandamurray: would you ming giving https://github.com/snapcore/snapd/pull/9263 a final review from security? (I commented on the base decl and removal of device-tree only)16:45
mupPR #9263: interfaces/fpga: add fpga interface <Needs Samuele review> <Needs security review> <Squash-merge> <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/9263>16:45
ijohnson.........................................16:54
ijohnsonwhy does uboot.go refer to the u-boot bootloader as "uboot", but gadget.yaml requires "u-boot"16:55
* ijohnson sighes heavily16:55
ijohnsonpedronis: I could use some help here if you have some time16:55
ijohnsonnot sure which we should re-name16:55
pedronisijohnson: none16:55
pedronisI'm not quite sure why it matters16:56
ijohnsonI suppose I could just silently alias "u-boot" as "uboot"16:56
pedronisijohnson: I fear I'm missing something here16:56
ijohnsonwell firstly the names are inconsistent which is just unfortunate as a fact of matter16:56
pedroniskind of yes16:57
ijohnsonsecondly, I am trying to do the ForGadget thing which uses the name of the bootloader from the gadget.yaml to know which bootloader it should try16:57
pedronisthat's the part I don't get16:57
pedroniswhy the gadget.yaml16:57
pedronisthat was not what we discussed16:57
ijohnsonmmm16:57
pedronismaybe is needed for lk16:57
pedronisbut is not what we discussed16:57
* zyga-mbp looks at https://github.com/snapcore/snapd/pull/954616:58
ijohnsonso if we don't use gadget.yaml how do we know what bootloader is in a given extracted gadget tree ?16:58
mupPR #9546: overlord: add inert export manager <Created by zyga> <https://github.com/snapcore/snapd/pull/9546>16:58
pedronisijohnson: we look at the .conf file, as we did before16:58
ijohnsonare we supposed to just grep for all "*.conf" files and see which one matches ?16:58
ijohnsonI guess we could do that, it feels again like we are guessing since folks could put whatever .conf they want there in addition to uboot.conf16:59
pedronisijohnson: the change I had in mind was very simple16:59
ijohnsonfor example16:59
pedronisijohnson: but that's how things worked already16:59
pedroniswe are not trying to change how that works16:59
ijohnsonI guess I was just trying to make that nicer since it feels silly how much guessing we end up doing17:00
pedroniswe are just changing the implementaion details17:00
pedronisijohnson: well it changes the mechanics quite a bit17:00
pedronisprobably not a good thing to do before 2217:00
pedronisat this point17:00
ijohnsonpedronis: did you mean not a good thing to do before 20 ?17:01
pedronisno, I mean, if we want to change the mechaninics of detecting the gadget17:01
pedronisbootloader17:01
pedronisthat would be a core 22 thing17:01
pedronisat this point17:01
ijohnsonok sure I will just go do the silly grep thing17:02
pedronisijohnson: is not a grep thing17:02
pedronisijohnson: maybe we should have a quick chat17:02
ijohnsonsure17:02
ijohnsonI'm in the SU17:03
zyga-mbphey King_InuYasha17:07
=== ijohnson is now known as ijohnson|lunch
mupPR snapd#9671 opened: release: snapd 2.48 <Simple 😃> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9671>17:59
zyga-mbpmvo +118:00
mupPR snapd#9671 closed: release: snapd 2.48 <Simple 😃> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9671>18:19
mvothanks zyga-mbp18:24
zyga-mbp:-)18:24
zyga-mbpI should really thank you instead18:24
mvocachio: snapd snap in beta for everything but arm*18:25
mvocachio: core as well, arm will come in ~1h or so18:26
cachiomvo, nice18:27
cachioperfect, validation already started18:27
mvocachio: \o/18:27
mvothanks!18:27
cachiomvyaw18:27
cachiomvo, yaw18:27
mupPR snapd#9672 opened: vendor: update secboot repo to avoid including secboot.test binary <Created by mvo5> <https://github.com/snapcore/snapd/pull/9672>18:39
mupPR snapcraft#3382 opened: project loader: purge dead code in Config <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3382>18:52
mvocachio: arm is now also ready in beta19:07
cachiomvo, perfect19:09
cachiothanks19:09
cachioI'll write in the docs with the results19:10
mvota!19:11
=== ijohnson|lunch is now known as ijohnson
ijohnsonmvo: approved 967219:13
mvoijohnson: \o/19:13
mvoijohnson: thanks, I closed/reopened because I forgot the "run-nested" label :/19:14
ijohnsonah right19:15
pedronisfor clarity, that brings in also https://github.com/snapcore/secboot/pull/10819:52
mupPR secboot#108: Make AddEFISecureBootPolicyProfile less strict <Created by chrisccoulson> <Merged by chrisccoulson> <https://github.com/snapcore/secboot/pull/108>19:52
ijohnsonyes I looked at the diff in secboot and it looked "safe" to me19:53
mupPR snapd#9662 closed: bootloader/many: return error from ConfigFile and new* functions <UC20> <⛔ Blocked> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/9662>21:35
mupPR snapd#9673 opened: bootloader/many: rm ConfigFile, add Present for indicating presence of bloader <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9673>21:35
amurrayjdstrand: security review done on https://github.com/snapcore/snapd/pull/926323:11
mupPR #9263: interfaces/fpga: add fpga interface <Needs Samuele review> <Needs security review> <Squash-merge> <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/9263>23:11
jdstrandamurray: thanks!23:12
mupPR snapd#9674 opened: bootloader/lkenv: mv v1 to separate file, include/lk/snappy_boot_v1.h: little fixups <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9674>23:51
mupPR snapd#9675 opened: bootloader/lkenv: add v2 struct + support using it <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9675>23:56

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