[00:25] PR snapd#9673 closed: bootloader/many: rm ConfigFile, add Present for indicating presence of bloader [06:12] PR snapd#9685 closed: tests: run tests against 2.48 for the SRU <⛔ Blocked> [06:37] PR snapd#9686 opened: tests: remove workarounds that add "ubuntu-save" if missing [07:01] morning [07:02] good morning [07:24] good morning zyga and mborzecki [07:25] hey :) [07:48] mvo: hey [07:49] 18.04 on my in-laws computer went crazy and was showing year 2037, ofc all https traffic was dead, systemd-timedated was not able to set the date from ntp either [07:50] probably the cmos battery is dying slowly [07:56] mborzecki: woah [08:01] morning [08:06] pstolowski: hey hey [08:10] pstolowski: good morning [08:17] hey mvo, I will need sponsorship in debian [08:17] mvo I'd like to maintain spread there [08:18] zyga-mbp: sure, happy to do that [08:18] I'll make a few more changes so that there's a sid-happy and focal happy version [08:18] and will ping you [08:28] mvo: i've added blocked label to #9686, it appears the gadget in 20/edge does not have ubuntu-save yet [08:28] PR #9686: tests: remove workarounds that add "ubuntu-save" if missing <⛔ Blocked> [08:38] woot, we don't run nested/manual on 20.10 [09:08] PR snapd#8943 closed: wrappers: generate D-Bus service activation files [09:08] PR snapd#9687 opened: osutil: add helper for getting the kernel command line [09:13] PR snapd#9688 opened: boot: add kernel command lines to the modeenv file [09:28] PR snapd#9689 opened: boot: add helper for generating candidate kernel lines for recovery system [09:48] PR snapd#9690 opened: tests: enable nested on 20.10 [09:49] mvo there will be a pair of new deps [10:14] * pstolowski pstolowski not feeling well (stomach bug), calling it a sick day o/ [10:45] zyga: a pair of new deps for what exactly (sorry for the slow reply, was in a meeting) [11:21] mvo: spread package is in https://launchpad.net/~zyga/+archive/ubuntu/oh-tools/+packages [11:22] mvo: when you have time, I'd love some early review [11:22] mvo: it depends on golang-github-niemeyer-pretty and golang-gopkg-niemeyer-ynext.v3 - also present in the same archive [11:22] I tried to follow the right policy but it's aimed at focal for now [11:28] eh, this constant irc disconnect [11:30] For the record, ynext is actually gopkg.in/yaml.v3 by now [11:31] niemeyer oh, that's cool, we should upgrade spread then [11:31] Yeah [11:31] niemeyer hi :) [11:31] niemeyer I can send a PR if you have time to land it [11:32] It's okay, I'll just pack it with whatever next update takes place.. I need to check if the API changed since then as well [11:33] niemeyer do you plan to release a v3.0.0 as well? [11:33] https://github.com/go-yaml/yaml/releases [11:33] would be good for go modules and versions [11:34] Yeah, I've left it settle for a while so the issues would show up before tagging [11:34] Now there are a few (simple, luckily) open issues that I need to look into before tagging [11:41] niemeyer if you ping me when you release the new yaml and the new spread I will make adjustments [11:43] I've packaged the snapshot of yaml.v3 and should be ready to update both spread and yaml.v3 when the time comes [11:52] cachio hey [11:52] zyga, hey [11:53] zyga, how are you doing? [11:53] PR snapd#9691 opened: spread: bump delta ref, tweak repacking to make smaller delta archives [11:54] cachio: good, making progress :) [11:54] cachio I've packaged spread as a debian package [11:54] cachio if you need it it's at https://launchpad.net/~zyga/+archive/ubuntu/oh-tools/+packages [11:54] I'll work with mvo to push it to debian [11:54] zyga, nice, this is really good [11:55] zyga, too much time downloading that binary [11:58] PR snapd#6258 closed: interfaces: support D-Bus activation <:birthday:> [12:03] PR snapd#9692 opened: client,snapctl: add primite support for "stdin" [12:11] cachio the package has built now, it should be published in a few minutes [12:14] and it's there now [12:18] cachio I can install this build on the spread runner box [12:19] will make updates easier [12:20] cc mvo ^ [12:20] feel free to nack, I will do that this evening otherwise [12:22] zyga, it is ok for me [12:22] I have more runners using the binary in the local environment [12:23] which I need to update in that case [12:23] cachio do you use focal or a mixture of focal/bionic? [12:24] PR snapd#9684 closed: devicestate: support "storage-safety" defaults during install (2.48) [12:24] zyga, bionic [12:24] ok [12:24] zyga, got some issues using focal with lxc [12:24] lxd [12:24] oh? [12:24] I am going to migreate that to a new environment soon [12:24] my workers run on focal IIRC [12:25] zyga, in the new environment I'll try using focal [12:26] still trying to fix some networking permissions there [12:26] I've copied spread to bionic as well [12:26] but it's untested [12:26] I can test it today [12:28] cachio I'll import the sources to salsa later so that we can file bugs like normal people [12:28] salsa.debian.org [12:30] zyga, nice, thanks [13:24] PR snapd#9693 opened: data/selinux: update the policy to allow operations on non-tmpfs /tmp [15:11] mborzecki: I reviewed #9688 [15:11] PR #9688: boot: add kernel command lines to the modeenv file [15:11] pedronis: thanks [15:13] pedronis: i take that the field should also be named CurrentKernelComamndLines then? [15:13] yes [15:14] ack [15:14] * cachio lunch [15:18] mborzecki: I reviewed 9688 too [15:45] pedronis: I updated 9692, hope I got all the things you suggested [15:46] ijohnson: thanks! [15:52] 9670 needs a second review please :) [15:57] mvo, hey [15:57] mvo, do you have a moment to talk about spread [15:58] I wanted to discuss ITP and related paperwork [15:58] zyga: yes [15:59] mvo, so I see that we have two options [15:59] mvo, do ITP dance, rebuild the packages I prepared for sid and have you sponsor [16:00] mvo, or wait for the yaml.v3 changes and release and use that instead of ynext [16:00] zyga: what is needed for yaml.v3? [16:00] mvo, the former can start now, the latter is unclear [16:00] zyga: I slightly prefer (2) because without we will need to do a package for 3next? [16:00] mvo, I think gustavo needs to review some patches for yaml, release it, then spread needs to be updated to use it [16:00] zyga: is there a yaml.v3 pacakge yet? [16:01] I made one today [16:01] all the packages are read and need review and sponsorship [16:01] zyga: with the in-progress v3? that should be fine [16:01] I made both [16:01] ynext and yaml.v3 [16:01] zyga: hm, what is the relation of ynext to yaml.v3? I mean, ideally we would not dput ynext because it's extra burden for us and ftp-master [16:02] ynext is precursor to yaml.v3 [16:02] I agree [16:02] zyga: could we make spread work with the current yaml.v3 ? is that easy? [16:02] yaml.v3 is not released yet officially from what I understand [16:02] it should be a drop in replacement though [16:03] zyga: then we could push a yaml.v3 pacakge and spread build against this. and once v3 is fully released we push the two packages again but that does not require any work from ftp-master [16:03] there's a similar question for kr-pretty [16:03] there's a fork in gustavo's github that spread is using [16:03] I also packaged that [16:03] zyga: what the difference of that vs gustavos version? [16:03] mvo, in that case, could you review yaml.v3 that I uploaded there [16:03] mvo, some more patches [16:03] it's go, a bit of a wild west perhaps [16:04] zyga: do we need those? mostly asking because any new binary/source pacakge requires that a human with limited time/patience (ftp-master) looks at it. so the least amount of extra work we create the faster it will go :) [16:04] mvo: re-reviewed [16:04] pedronis: \o/ [16:04] pedronis: hey I wrote a quick doc for the recovery systems rest api, could you take a look? [16:04] I just shared it with you and graham [16:05] mvo, I understand that but I wanted to be true to the source [16:05] I suspect gustavo can answer that in detail [16:05] it ocurred to me that actually it's rather complicated to explain what the difference between "do" and "reboot" action are [16:05] I wanted to make sure I got it right [16:05] hey zyga [16:05] hey ijohnson :) [16:05] having fun with spread I see :-) [16:06] wanted to help a little :) [16:06] zyga: sure, sure, jsut asking if for the debian version we could use spread with upstream -pretty and not with the fork [16:06] always appreciated :-) [16:07] mvo, I don't know, the answer is "maybe" [16:07] it probably only matters in -vv mode [16:07] packaging is rather simple so if you could do a pass and let me know we can iterate [16:08] mvo, I'd be comfortable with non-forked versions iff those land in spread upstream [16:08] PR snapcraft#3386 opened: meta: don't overwrite preconfigured hooks with stubs [16:11] mvo, let me know please [16:11] I'll run away now [16:11] zyga: we can start with the yaml.v3 I guess, that should be pretty simple [16:11] mvo, yeah [16:11] zyga: haha, run! [16:11] we can also rev it [16:11] zyga: let's talk when you are back [16:11] when more patches land upstream I'm happy to release it [16:11] ideally if gustavo tags v3.x.y [16:11] zyga: more patches for what? [16:11] mvo, for yaml.v3, I understand there are PRs for him to review [16:12] zyga: it's totally fine to have yaml.v3 3.0~pre1.gitXXYYYZZZ [16:12] but unless those add deps it's super easy to update [16:12] yeah, this is what I packaged now [16:12] zyga: exactly [16:12] zyga: yeah, that should be fine [16:12] v3-0~20221124... [16:12] zyga: +1 [16:12] so it's good to go IMO [16:13] mvo, I packaged both spread and humbox in the other package [16:13] go packaging is fairly painless now [16:14] so if you have a moment to look and provide feedback, that would rock [16:14] ijohnson: I got the share, I'll look at it tomorrow in my morning if that's ok? [16:14] I did the painful copyright file in all cases [16:14] pedronis: yes that's ok [16:14] pedronis: also I'm working on adding support for i.e. `snap reboot --recover` without the label specified [16:14] zyga: what's the url again? sorry, misplaced [16:14] ijohnson: I thought we supported some of that already [16:14] because that doesn't work, I was just going to make a POST to `/v2/systems` DTRT and figure out the right system to act on [16:15] pedronis: no, you have to specify the system [16:15] mmh [16:15] anonymouse67@ubuntu:~$ snap reboot --recover [16:15] error: cannot request system reboot: method "POST" not allowed [16:15] I'm probably misremembering something [16:15] I think it was just missed in code review [16:15] mvo, https://launchpad.net/~zyga/+archive/ubuntu/oh-tools/+packages [16:15] the client just uses "" as the recovery system when performing the POST [16:15] sorry for not using a more neutral location but it's just practical for me [16:16] pedronis: which I think is totally fair to provide "" as the recovery system in the request and let the daemon figure out the right current system [16:16] ijohnson: sounds we miss a spread tests ? [16:16] well we found it in spread tests when trying to use `snap reboot --recover` and I think there's even a TODO about it not working and need to grep `snap recovery` [16:17] but yes we should add such a spread test [16:17] and/or adapt the current ones to not find the label using `snap recovery` [16:22] ijohnson: to be clear the intention was to make this work, seems we didn't dot the i, I'm bit surprised/worried that we are missing bits also in devicestate [16:22] pedronis: no I don't think we are missing the bits in devicestate [16:23] I just made it work by adding the path for POST to /v2/systems to api_systems.go [16:23] zyga: packaging looks fine, homepage is not quite right, see https://paste.ubuntu.com/p/3TQtMMvRRw/ (ignore the changelog diff, just added that for debdiff benefits) [16:23] I think it's just that little bit of daemon that 's missing [16:23] ah, then I misunderstood your comments [16:23] sorry yes we are _just_ missing the daemon bit [16:23] I will have a PR shortly that uses this after I finish some tests [16:24] would be "nice" to have for release since it's a much more clear CLI user story to just do `snap reboot --recover` and have to find the label from `snap recovery` first, etc. [16:24] but I don't think it's a blocker [16:34] pedronis: thanks! I updated 9692 to use embedding now [16:36] also 9692 needs a second review now :) [16:38] oh hmmm actually maybe devicemgr is doing the wrong thing :-( [16:59] ok I think I have it sorted finally, we are missing bits in both devicemgr and in daemon [17:02] mvo, ah, good catch [17:02] mvo, thanks, I'll open an ITP and complete the package [17:09] mvo let me weak packaging now [17:10] why are the gnome platform snaps missing from `snap find`? [17:10] https://www.irccloud.com/pastebin/YN3ycIMs/ [17:11] i think thats on purpose [17:11] (forgot the reason though ... but theer probably is one even 🙂 ) [17:13] oic. that means I need to guess which ones are available? ;-p [17:15] diddledan, snapcraft list-extensions [17:16] that only works for extensions that have stabilised :-) [17:16] and there's no guarantee that an extension is named exactly the same as their platform snap [17:17] also. kenvandine pretty please get a desktop extension for core20 out the door 🙏🏻 [17:18] diddledan: indeed, it's in the works but waiting on some changes in snapcraft from sergio [17:18] bah :-p [17:19] i have a WIP branch for gnome-3-38-2004{,-sdk} but tons of build failures for things using autotools [17:19] dang [17:19] i was working around them but sergio said he would restore some of the stuff that was dropped from the autotools plugin [17:20] aah. yeah the new v2 plugins are much simpler than their v1 equivalents IIRC [17:20] that probably means they're doing less fixup [17:21] * diddledan makes a note to bother segio ;-p [17:21] sergio* [17:24] yup [17:24] I'm working on improving snapcraft.io/fakecam by adding hardware acceleration, but cuda is complaining about GCC being too new - I'm hoping when I can make the jump to core20 the newer cuda libraries will be better behaved [17:35] PR snapd#9694 opened: o/devicestate,daemon: fix reboot system action to not require a system label [17:36] pedronis: ^ is the pr, you were right there was a small bit in devicestate that needed to be fixed in addition to the daemon bits being weird [17:38] PR snapcraft#3372 closed: tests: make each static test available as a make target [17:38] PR snapcraft#3376 closed: tests: add missing mock for rust unit tests === ijohnson is now known as ijohnson|lunch [19:55] * cachio afk [20:38] PR snapcraft#3373 closed: ci: migrate static & unit tests from travis to github actions [20:53] PR snapcraft#3387 opened: ci: migrate snap publishing to github actions === ijohnson|lunch is now known as ijohnson [21:01] PR snapd#9689 closed: boot: add helper for generating candidate kernel lines for recovery system [21:13] PR snapcraft#3388 opened: ci: migrate snap publishing to github actions [21:44] PR snapcraft#3368 closed: ci: use github actions for cla check [23:26] PR snapd#9695 opened: bootloader/lk: add support for UC20 lk bootloader with V2 lkenv structs [23:52] PR snapd#9696 opened: osutil/disks: allow building on mac os