| === harrisj_ is now known as harrisj | ||
| mvo | hey Chipaca, good morning! | 08:23 |
|---|---|---|
| mvo | 7096 needs a second review, should be an easy one | 08:24 |
| Chipaca | mvo: looking | 08:24 |
| mvo | ta | 08:24 |
| pedronis | mmh | 08:36 |
| mvo | pedronis: mmh? (and good morning :) | 08:44 |
| pedronis | I have vague memories that the ! would go in front , but I'm probably misremembering, the notes says after | 08:44 |
| pedronis | also the shell would scream if in front | 08:45 |
| pedronis | so I'm misremembering for sure | 08:45 |
| mvo | pedronis: oh, indeed | 08:46 |
| pedronis | also in the context of the unset work, we shouldn't forget we decided to fix snap set a.x=... a=... by sorting | 09:18 |
| mvo | pedronis: good point, I wonder if we captured this in one of the trello cards | 09:19 |
| Chipaca | pedronis: what kind of sorting? | 09:20 |
| Chipaca | ogra: mvo: do you know, offhand, how to pause the live cdimage before it boots into the actual live system? wanting to set SNAPD_DEBUG :) | 09:25 |
| ogra | not sure you can ... but there should be a console on tty4 | 09:26 |
| ogra | (so you can do your edits and restart all involved bits) | 09:27 |
| Chipaca | ogra: the thing i'm wanting to see is the seeding, and i'm not fast enough | 09:28 |
| mvo | Chipaca: uh, thats a tricky one. I wonder if you could break into initramfs | 09:28 |
| ogra | yeah, thats a possibility but also a lot of time consuming work | 09:29 |
| ogra | (manually assmbling the rootfs, chrooting and editing etc) | 09:29 |
| Chipaca | eugh | 09:29 |
| Chipaca | I've asked laney, maybe they have a trick for it | 09:29 |
| ogra | try break=bottom | 09:29 |
| ogra | on the kernel commandline | 09:29 |
| mvo | yeah, break=bottom was what I was thinking, then tweak and exit the shell and hope for the best | 09:30 |
| Chipaca | trying that | 09:30 |
| ogra | (there should be a way to enter this at the very start) | 09:30 |
| Chipaca | break=bottom and then echo SNAPD_DEBUG=1 >> /root/etc/environment worked | 09:33 |
| mvo | Chipaca: \o/ | 09:37 |
| Chipaca | need to step out for a bit, will bbiab | 09:38 |
| pedronis | Chipaca: by depth | 09:40 |
| mvo | 6878 (health status in info/list has two +1, I will merge it, I left one bikesheed comment though, but its fine to ignore that) | 09:49 |
| pedronis | mvo: it's in the card https://trello.com/c/yxC3omC9/245-snap-unset-support | 09:53 |
| pedronis | but not sure it was done yet (haven't looked at the PRs) | 09:53 |
| mvo | pedronis: excellent, thank you! | 09:53 |
| mvo | pedronis: not done yet in any of the PRs I have seen so far | 09:54 |
| mvo | fwiw 7098 and 7102 should be easy wins | 09:54 |
| pedronis | we are also missing snapctl unset | 09:56 |
| mvo | pedronis: good catch | 09:57 |
| pedronis | anyway I added actual todos to the card | 09:58 |
| mvo | pedronis: thanks for adding it to the card! | 09:58 |
| mvo | fwiw - I closed 5915 now (netplan apply) now that we have #7107 | 10:03 |
| * mvo really misses mup btw | 10:03 | |
| pedronis | mvo: thank you | 10:04 |
| mvo | 7100 is now also green - its "funny" one, it requires that we update gorilla too | 10:05 |
| pedronis | it needs Chipaca to look at it, then I will look at it as well | 10:06 |
| ackk | sergiusens, hi, would you consider merging https://github.com/sergiusens/snapcraft-preload/pull/32? we'd need it for postgres, which tries to create /dev/shm/PostgreSQL.XXXXX files | 10:10 |
| Chipaca | mvo: wrt 7100, why not have the prereq helpers also take context? | 10:20 |
| Chipaca | mvo: they're called from a do* handler so you've got a tomb so you've got a natural context already | 10:21 |
| mvo | Chipaca: aha, let me check that | 10:22 |
| Chipaca | mvo: i mean, if they break all the tests in the world, maybe it's worth leaving them for later :-) | 10:22 |
| Chipaca | but otherwise, ...? | 10:22 |
| mvo | Chipaca: let me explore that | 10:23 |
| mvo | Chipaca: I'm a bit slow (sry!) do you have an example helper name that could take the context for me? not sure I know what you have in mind | 10:25 |
| Chipaca | mvo: installOneBaseOrRequired | 10:25 |
| Chipaca | mvo: via installPrereqs | 10:25 |
| mvo | Chipaca: aha, yes | 10:25 |
| mvo | Chipaca: I can do that, however I think the reason its not done (now) is that the client-user-agent will only be set (in this PR) in the SnapAction store API call. once the change is created the client-user-agent is no longer available in the change. we could fix that but its more work and the win seems to be small. or am I missing something? | 10:27 |
| mvo | Chipaca: we would have to persist the client-user-agent somewhere in the change if we want to keep it and use it in the handlers | 10:28 |
| Chipaca | mvo: hm... | 10:30 |
| Chipaca | ah so it's not in the tomb at all | 10:30 |
| Chipaca | sary, missed that disconnect again | 10:30 |
| Chipaca | mvo: in any case +1 | 10:31 |
| Chipaca | pedronis: does request-serial in classic hit the actual store? | 10:44 |
| mvo | Chipaca: \o/ thank you! | 10:46 |
| mvo | 7098 is green and has one +1 already and is small… | 10:46 |
| Chipaca | mvo: it's got two +1's though | 10:50 |
| pedronis | Chipaca: yes | 10:50 |
| Chipaca | pedronis: that's taking ~30s | 10:50 |
| Chipaca | pedronis: which is the same as seeding takes | 10:51 |
| Chipaca | on this machine | 10:51 |
| Chipaca | pedronis: seems slow for a single request | 10:51 |
| Chipaca | ¯\_(ツ)_/¯ | 10:51 |
| pedronis | that is interesting | 10:51 |
| Chipaca | pedronis: https://snapforum.s3.amazonaws.com/original/2X/5/55ca16db9b44fe934424c27999c3386948b4fb4e.png | 10:52 |
| mvo | Chipaca: heh :) | 10:53 |
| mvo | Chipaca: we are down to 51! | 10:53 |
| Chipaca | pedronis: it's prepare-serial-request, not submit-serial-request, that takes that long though | 10:53 |
| pedronis | Chipaca: ah, but we don't split retries | 10:53 |
| pedronis | so a bit unclear | 10:53 |
| pedronis | if that's one request or many retries | 10:53 |
| Chipaca | pedronis: you can ask | 10:53 |
| Chipaca | pedronis: you can ask me, even | 10:53 |
| Chipaca | or you can get the iso and look for yerself :-p | 10:54 |
| pedronis | prepare-serial-request | 10:54 |
| pedronis | that is even weirder | 10:54 |
| Chipaca | anyway i need to go comb my hair (just one of them) and get ready for the show | 10:55 |
| pedronis | are we doing or changed something silly | 10:55 |
| pedronis | we ask only a nonce from the store there | 10:55 |
| pedronis | I need to dig/look around a bit | 10:55 |
| Chipaca | pedronis: you ok to repro this on your own, or should i get the logs somewhere | 10:56 |
| Chipaca | pedronis: instructions here: https://forum.snapcraft.io/t/snap-seeding-is-slow-racy/12310 | 10:56 |
| pedronis | Chipaca: well, I'm not promising to repro it | 10:56 |
| pedronis | I'm promosing to understand what we need to look | 10:56 |
| pedronis | more precisely | 10:56 |
| Chipaca | pedronis: fair enough | 10:56 |
| Chipaca | i look forward to learning more :-D | 10:56 |
| Chipaca | but now i need to run | 10:56 |
| mvo | Chipaca: I added a comment to 7083 that might be worth doing (not sure though, depends on the plans with 7092) | 10:58 |
| Chipaca | mvo: ok, i'll take a look in a bit | 11:06 |
| Chipaca | afk from irc but github will work :-) | 11:06 |
| pedronis | I left some comments there | 11:15 |
| pedronis | Chipaca: it takes ~200ms to get a nonce from the store, so something else is going on | 11:17 |
| === ricab is now known as ricab|lunch | ||
| mvo | 7102 is another easy win | 12:41 |
| mvo | xnox: snapd PR#7031 (re-enable the system PATH generator) is fixed now, right? or do we need some initramfs fix too (I have some vague memories that this was discussed but don't know the conclusion) | 13:33 |
| mvo | xnox: once you +1 it I will merge it | 13:34 |
| ogra | sil2100, could we get this into all gadgets (core16 and 18) soon ? https://github.com/snapcore/pi3-gadget/pull/28 | 13:56 |
| === ricab|lunch is now known as ricab | ||
| ogra | (i asked ondra for a signoff too, to get more eyes on it, but in general someone should really monitor the pi firmware and push regular updates to the gadgets, they often fix over/under vlotage issues, overheating etc) | 13:57 |
| cwayne | ogra: sil2100 i thought we just landed the same thing | 14:00 |
| ogra | cwayne, well, i couldnt make any of our official images boot on the CM3 on my desk ... neither core16 nor core18 (though i dont look much at 18 anyway given the quality) | 14:01 |
| ogra | CM3+ | 14:01 |
| ogra | sorry | 14:01 |
| ogra | using my universal pi-kiosk snap with the latest firmware (also for pi4 support) boots it fine though | 14:02 |
| ogra | otherwise it always hangs on the rainbow splashscreen (meaning the rpi bootloader itself dies before it can load anything) | 14:02 |
| cwayne | ogra: did you try with a very recent image? think the updated gadget landed in stable ~5hrs ago | 14:07 |
| cwayne | worked for 18 for us | 14:07 |
| ogra | i tried both, 16 and 18 from the current dir on cdimage | 14:09 |
| om26er | Hi! one of my snap failed to publish because I added a new hook, is that normal will have to go through a review or is that something that needs changing in my yaml ? | 14:11 |
| om26er | the warning was "unknown hooks in meta/hooks: 'disconnect-plug-services-content' lint-snap-v2_unknown_hook" | 14:12 |
| ogra | i also dont get why we still have separate images for pi2/3/cm3 and dont use the universal gadget, i thought we moved to that | 14:12 |
| ackk | jdstrand, hi, wrt /run/uuidd/request, do you think it makes sense to file a bug for an interface request? I see it's currently available in openvswitch-support | 14:19 |
| om26er | roadmr ^ | 14:20 |
| xnox | mvo: you are correct. Needs https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1814355 tasks for initramfs-tools done. | 14:20 |
| xnox | let me comment on the PR | 14:20 |
| mvo | xnox: thank you | 14:31 |
| jdstrand | ackk: last we talked in Lyons, blake, et al all felt that the snap should be adjusted to use /proc/sys/kernel/random/uuid, which is standard and in the default template). there is nothing that will guarantee that /run/uuidd/request will be there on all distros. that said, it seems systemd is providing it and snapd requires systemd (and 14.04 is no longer supported by snapd) | 14:45 |
| ackk | jdstrand maybe we can use snap layouts for that | 14:48 |
| ackk | jdstrand, we don't explicitly use that socket, libuuid does that | 14:48 |
| jdstrand | ackk: well, sure, but why use libuuid? :) | 14:49 |
| ackk | jdstrand, actually we can't use templates as the kernel one is just a file you cat | 14:49 |
| ackk | jdstrand, because it's somewhat standard? IDK we don't use it explicitly :) | 14:50 |
| ackk | I mean it's not a direct dependency | 14:50 |
| ackk | a lot of stuff use that | 14:50 |
| * jdstrand wonders why it doesn't use the kernel interface rather than uuidd | 14:51 | |
| * cachio afk | 14:51 | |
| jdstrand | (when the kernel supports it) | 14:51 |
| ackk | jdstrand, dunno, portability? | 14:51 |
| ackk | I mean, sure libuuid could use that file if it's there | 14:51 |
| jdstrand | right | 14:51 |
| jdstrand | anyway, I've taken a todo to investigate this for the default template | 14:51 |
| jdstrand | I suspect systemd will be looking at that file | 14:52 |
| ackk | jdstrand, the python uuid uses os.urandom() afaics | 14:52 |
| sil2100 | ogra: that should be released already | 15:01 |
| sil2100 | ogra: the 'master' branch is out-of-date and not used | 15:01 |
| sil2100 | ogra: I actually need to just remove it | 15:01 |
| mvo | ijohnson: just fyi, I'm poking at the tests in your netplan-apply pr right now | 15:01 |
| sil2100 | ogra: there are 16 and 18 branches, and both have the latest uboot bumps for the pi3 | 15:01 |
| ogra | sil2100, well, none of the images i tried on the CM3+ booted | 15:01 |
| ogra | sil2100, this is not u-boot ... this is the raspberry pi firmware | 15:02 |
| ogra | sil2100, it doesnt even get to a point where it would load u-boot, hangs in teh step before | 15:02 |
| ogra | (on the ranbow colored splash screen (which shoudl really be disabled, not sure why thats on in the official gadgets) | 15:03 |
| sil2100 | ogra: ok, I see what's the problem - you are right, the core16 gadgets didn't get the firmware bump | 15:03 |
| sil2100 | ogra: since we only bumped the uboot version there | 15:04 |
| ogra | right | 15:04 |
| sil2100 | ogra: let me do that then | 15:04 |
| ogra | thanks !! | 15:04 |
| sil2100 | ogra: but the 18 ones are bumped if anything | 15:04 |
| sil2100 | ETOOMANYGADGETREPOS | 15:04 |
| ogra | wried | 15:04 |
| sil2100 | Sorry about that! | 15:04 |
| ogra | *weird even | 15:04 |
| ogra | sil2100, i definitely tried the rpi3 UC18 images from /current | 15:04 |
| ogra | (as well as the (totally pointless) cm3 ones ... why do we build them ?) | 15:05 |
| ogra | sil2100, could it be that the fix hasnt made it to /current yet ? (i can surely try /pending too if needed) | 15:06 |
| sil2100 | hm hm hm, it looks correct, manifest shows having the latest pi gadget, and from what I see in the gadget's build log the right boot-firmware tag has been cloned | 15:10 |
| sil2100 | And I thought waveform checked if it's the right firmware version before submitting the PR | 15:10 |
| ijohnson | mvo: thanks | 15:10 |
| mvo | ijohnson: I pushed some bits, if you mind I can also push to a separate PR | 15:14 |
| ijohnson | no, it's fine you can push to the same PR, thanks! | 15:14 |
| mvo | ijohnson: mostly suggestions, probably need a critical eye from samuele as well but should make things a bit easier | 15:14 |
| ijohnson | mvo: ack, thanks for that | 15:14 |
| mvo | ijohnson: its mostly there now, something in the TestYesNetplanApply test is unhappy still, it hangs here | 15:14 |
| mvo | ijohnson: not sure why, probably some mocking missing for something | 15:15 |
| ijohnson | yeah I've seen it hang a few times I think it has something to do with locks | 15:15 |
| ijohnson | err I've seen it hang in a few iterations I've done | 15:15 |
| mvo | ijohnson: yeah, its probably not my changes :) | 15:15 |
| mvo | ijohnson: aha, locks! good catch, let me check those | 15:15 |
| ijohnson | the version I pushed up shouldn't hang, but maybe your changes are moving back to what I tried originally that was hanging | 15:15 |
| * mvo nods | 15:16 | |
| ogra | sil2100, looking at https://github.com/snapcore/pi-gadget/blob/18-armhf/snapcraft.yaml i see a tag from feb 2019 ... perhaps thats still not new enough | 15:20 |
| sil2100 | ogra: maybe, but waveform selected that tag exactly because of cm3+ support | 15:22 |
| sil2100 | Let me poke him | 15:22 |
| sil2100 | ogra: anyway I'd expect it to work as we use the exact same firmware tag for disco and eoan classic raspi3 images, and I'm sure those work on the cm3+ | 15:25 |
| sil2100 | (also, per Dave's original commit message: https://github.com/snapcore/pi-gadget/commit/b8a16cb1e1d9a2c0419da8fef0bffc12e3c914fb ) | 15:25 |
| ogra | very weird ... | 15:25 |
| sil2100 | I asked him to test again | 15:25 |
| sil2100 | Maybe there's something weird going on somewhere | 15:25 |
| sil2100 | I'll wait for this to be resolved before I update the 16 gadgets, since I'd like it all to use the same firmware | 15:26 |
| om26er | When a new hook is added to a snap package (e.g. interface connection/disconnection hook), does that need to be approved by the store guys ? | 15:26 |
| ijohnson | om26er: I'm not sure that the store review tools have been updated to take into account interface connection/disconnection plugs | 15:27 |
| ijohnson | jdstrand and roadmr should be able to help you with that when they get time | 15:27 |
| ogra | sil2100, well https://github.com/snapcore/pi-gadget/commits/18-armhf shows that all travis checks have failed ... not sure if that tree is gated by travis though | 15:27 |
| ogra | (for both last commits) | 15:27 |
| sil2100 | ogra: well, it passed on the PRs | 15:28 |
| sil2100 | ogra: (when you check the failed travis checks, those are issues with git clone and I also experienced that during the snap builds) | 15:30 |
| sil2100 | And even locally | 15:30 |
| sil2100 | There was a period of time where the default git repo url of uboot that we use was not usable | 15:31 |
| sil2100 | Anyway, basically the travis checks are build-checks, so if LP was able to build the end snap, that means it passed all the tests | 15:31 |
| om26er | ijohnson thanks, I'll wait | 15:32 |
| ogra | ok ... as long as the sync to LP isnt blocked by these travis checks i guess it is fine | 15:32 |
| ogra | just looked like a potential reason for not having the change in these images | 15:33 |
| sil2100 | ogra: I checked the snap build logs, and I saw that the git clone of the firmware branch printed "Note: checking out '98997f363e3683ead4f50c37902169248628303a'.", which is a commit from feb 2019 | 15:34 |
| ogra | ok | 15:34 |
| ogra | very strange then | 15:34 |
| sil2100 | cwayne: hey! Do you guys have cm3+'s in the lab? | 15:35 |
| ogra | they do | 15:35 |
| roadmr | om26er: can you show me (snapcraft.yaml) what you added? | 15:35 |
| cwayne | They're on the way sil2100 | 15:35 |
| cwayne | plars has one at home | 15:35 |
| sil2100 | cwayne: awesome \o/ | 15:35 |
| plars | sil2100: have a new image I need to try? | 15:36 |
| om26er | roadmr https://github.com/deskconn/deskconn-server/blob/master/snap/snapcraft.yaml | 15:38 |
| roadmr | om26er: hm this looks reasonable; I think the best way would be for you to change what you need, upload the snap, and the review tools will tell you if it needs manual approval | 15:41 |
| sil2100 | plars: could you check the current one? Since Dave seems to be AFK - just so that someone else also tries booting it http://cdimage.ubuntu.com/ubuntu-core/18/current/ <- | 15:41 |
| roadmr | om26er: typically what we do is approve that in general, and subsequent uploads won't need the same thing | 15:41 |
| plars | sil2100: will do | 15:41 |
| sil2100 | plars: thank you! | 15:41 |
| ogra | plars, i couldnt get that one to boot on my CM3+ ... | 15:41 |
| om26er | roadmr https://dashboard.snapcraft.io/snaps/deskconn/revisions/84/ | 15:42 |
| ogra | would be good to have another datapoint | 15:42 |
| om26er | I think revision 82 is the one that needs approval | 15:42 |
| sil2100 | This will be some good input, since I at least hope he did test that gadget change before submitting the PR | 15:43 |
| sil2100 | (Dave that is) | 15:43 |
| cwayne | sil2100: we had tried an image with a gadget using Dave's pr and were able to boot core18 but not core16 | 15:47 |
| sil2100 | cwayne: yeah, the core16 is expected, because of uh, my mistake | 15:47 |
| sil2100 | Too many repos of those gadgets | 15:47 |
| sil2100 | cwayne: but the 18 gadget booted fine on the cm3+? | 15:48 |
| cwayne | plars: ^ | 15:48 |
| cwayne | Yeah that was my understanding | 15:48 |
| plars | yes, still setting up to try this one though - I'm also trying to boot it with a regular cm3 in the lab | 15:48 |
| sil2100 | The regular ones should be good, since I saw those being tested in the automated testing | 15:49 |
| ogra | yeah, very unlikely that they could have regressed | 15:52 |
| plars | ogra: did that rpiboot from edge work for you at least? seems to be working on my cm3+ | 15:52 |
| plars | it's writing the image now | 15:53 |
| ogra | sil2100, oh ... note that i tested http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/ is that different from http://cdimage.ubuntu.com/ubuntu-core/18/current/ ? | 15:54 |
| sil2100 | ogra: yes! | 15:54 |
| ogra | oh man | 15:54 |
| ogra | can we clean up that directory mess ? | 15:54 |
| sil2100 | ogra: we don't daily-build stable images, only during point releases | 15:54 |
| sil2100 | ogra: you need to check the timestamps, we only daily build edge and beta images right now | 15:54 |
| ogra | oh my ... ok | 15:55 |
| sil2100 | ogra: stable is like the stable ones we want to brand and 'release', which only happens on every point release | 15:55 |
| sil2100 | ;) | 15:55 |
| ogra | then sorry for the noise ... i followed some download link (that i have lost now :( ... ) | 15:55 |
| ogra | from our main website somewhere | 15:55 |
| sil2100 | http://cdimage.ubuntu.com/ubuntu-core/18/current/ are for edge and http://cdimage.ubuntu.com/ubuntu-core/18/beta/current/ are for beta - and I guess for a daily stable image you'd have to build one locally with ubuntu-image --channel=stable | 15:56 |
| sil2100 | It might be a decent idea to build some stable images before point releases | 15:56 |
| sil2100 | But doing it daily wouldn't make much sense, there's not enough velocity there | 15:56 |
| ogra | well, yeah, dail stable (or daily in general) is nonsense anyway ... the images shoudl simply be built change-triggered | 15:56 |
| sil2100 | So we'd probably switch some stable images built on every stable snap change, but that's still not there | 15:57 |
| sil2100 | Yeah, that's the plan | 15:57 |
| sil2100 | But we still don't have that | 15:57 |
| sil2100 | plars, cwayne: issue has been resolved, sorry for the commotion o/ | 15:58 |
| ogra | http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/ doesnt really suggest it is anything thats daily though ... if i navigate from the toplevel of cdimage i indeed want the "stable " release ... and then go to the most current image of that by using the "current" link | 15:58 |
| ogra | so even if i had not follwed a download link originally,m i would have ended up in the exact same place to get the latest stable image | 15:59 |
| sil2100 | Well, the header of the stable images mentions 'Ubuntu Core 18', where others explicitly say 'Daily Builds' - but indeed, we might want to make this a bit more intuitive | 15:59 |
| sil2100 | ogra: well, this is the 'latest stable image' ;) | 16:00 |
| ogra | right ... but there are no headers at http://cdimage.ubuntu.com/ubuntu-core/18/ :) | 16:00 |
| sil2100 | ogra: as mentioned, we will only promote to 'current stable' on point releases, so people following download links will always get only the image we blessed during point release preparation | 16:00 |
| sil2100 | True | 16:00 |
| sil2100 | cdimage is a confusing place | 16:01 |
| sil2100 | ;p | 16:01 |
| ogra | and when i finally enter the site i have to search for the right image between the gazillio pi images on that page (is there any reason why we do not have one pi image per arch /armhf/amd64 ?) | 16:01 |
| plars | sil2100: this boots on both my cm3 and cm3+, but it has edge snaps for everything. Is that expected? | 16:01 |
| plars | ah, just saw the backlog | 16:02 |
| * ogra hands plars some https://www.youtube.com/watch?v=7nqcL0mjMjw | 16:02 | |
| ogra | :) | 16:02 |
| plars | hah | 16:03 |
| plars | sil2100: so we are waiting on a different image to test now I guess? | 16:03 |
| sil2100 | plars: no no, it's all good - I mean, I'll be pushing new cm3 16 gadgets out soon, but other than that we're good | 16:04 |
| plars | ack | 16:05 |
| ogra | sil2100, but in all seriousness, why do we have pi2, pi3 and cm3 images there ? supposedly all using the universal pi gadget and the same kernel, so in the end they are all the same image | 16:07 |
| ogra | this smells like a massive waste of built/test time and server space | 16:08 |
| ogra | (i originally developed the universal pi gadget to exactly not have three images anymore :) ) | 16:09 |
| sil2100 | ogra: well, it is a waste, yes, that was some leftover of the 16 times, no reason for it - guess when the first 18 models have been created and signed we simply cloned what we had for 16 | 16:10 |
| sil2100 | So we got pi2, pi3 and cm3 models, thus a separate image for each model | 16:10 |
| sil2100 | oh well | 16:10 |
| ogra | sil2100, yeah, for 16 we couldnt change ... i had hoped for 18 it would though | 16:10 |
| ogra | i guess i'll send some expensive tea to bribe xnox to make sure core20 gets better here ;) | 16:11 |
| sil2100 | ogra: a missed opportunity I guess! There was a bit too much going on so I also didn't notice it's unneeded until it was already all released ;) | 16:11 |
| ogra | yeah | 16:11 |
| mvo | ijohnson: please check netplan-apply - should be mostly good now, feel free to fix anything I missed and there is also a spread test missing iirc | 16:12 |
| ijohnson | mvo: thanks I just saw your push I was waiting to push up my spread test until you were done | 16:12 |
| ogra | well, who knows ... i'm not sure we can actually support the pi4 with the same kernel snaps in the end ... perhaps it was a clever thing to keep them separate | 16:12 |
| ogra | until we can go to a new enough kernel that supports all of them in core20 | 16:13 |
| mvo | ijohnson: yeah, I think I'm finished with what I wanted to do :) feel free to tweak/adjust as needed, its your PR afterall, I feel slightly bad for being so pushy in it :/ | 16:13 |
| mvo | ijohnson: but it was also fun so I couldn't stop myself | 16:14 |
| ijohnson | mvo: no problem, I appreciate the help in the tests that was what I was blocked on so you have unblocked me :-) | 16:14 |
| mvo | ijohnson: great! happy to help and to be fair the testing was a bit delicate (but hopefulyl we can make things better/easier :) | 16:15 |
| ijohnson | +1 | 16:15 |
| pedronis | 7083 needs a bit more work, there or in a follow up | 16:18 |
| pedronis | it has 2 +1 but I should probably look at it as well | 16:18 |
| pedronis | I commented about the work | 16:18 |
| jdstrand | hmm, om26er is gone. ijohnson> fyi, so long as the hook is known to the review-tools at all, then there is no problem. if a new hook is added to snapd, then the review-tools need to learn it | 16:21 |
| pedronis | ijohnson: I was discussing with mvo, a smallish thing that we might need sooner rather than later, related to remodeling is this: https://forum.snapcraft.io/t/remodeling-to-a-new-model/10477/2 | 16:22 |
| ijohnson | jdstrand: does the store tools know how to handle interface hooks? IIUC, those hooks could be named anything in the patterns shown on https://docs.snapcraft.io/interface-hooks | 16:23 |
| ijohnson | pedronis: looking | 16:23 |
| jdstrand | pedronis: I'm not up on remodeling and I don't see anything in that forum that references hooks (am I blind?) | 16:25 |
| pedronis | jdstrand: not related to the discussion, but ijohnson has progress quite a bit on his current task, so I was discussing with mvo what he can pick up next | 16:26 |
| pedronis | *progressed | 16:26 |
| pedronis | *can or could | 16:26 |
| jdstrand | oh, heh, I copied the wrong link. durr | 16:26 |
| ijohnson | pedronis: okay this seems straight forward, but actually like jdstrand I'm not familiar with the current plan on remodeling :-) | 16:27 |
| ijohnson | pedronis: is that forum post all we have for the plan for remodeling ? I see you also have quite a few PR's open with remodelling label | 16:27 |
| pedronis | ijohnson: we progressed quite a bit | 16:28 |
| pedronis | that forum topic is mostly concerened with reregistration, switching model | 16:28 |
| pedronis | ijohnson: I'm close to eod but we can chat more tomorrow | 16:28 |
| jdstrand | ijohnson: the tools already handle those, yes | 16:28 |
| jdstrand | ijohnson: (https://docs.snapcraft.io/interface-hooks) | 16:29 |
| ijohnson | pedronis: okay sure I will try to schedule a meeting tomorrow to discuss more | 16:29 |
| ijohnson | jdstrand: hmm okay well it looked like using an interface hook was the problem that om26er was running into | 16:30 |
| jdstrand | ijohnson: ah, the tools know about connect-*, prepare-* but not disconnect-* | 16:32 |
| jdstrand | I see that r82 uses disconnect-plug-... | 16:33 |
| * jdstrand adjusts tools | 16:33 | |
| jdstrand | roadmr: hi! can you pull 20190716-1700UTC? not urgent. fixes om2er's issue (cc ijohnson) | 17:01 |
| roadmr | jdstrand: sure thing, I'll queue it up | 18:52 |
| === kyrofa_ is now known as kyrofa | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
