[15:07:28] Meeting started by ben79 [15:07:50] tpg: we definitely need to sort that out, but not sure if it makes sense without the treasurer being there? [15:08:02] Topics: 1. Releasing the new updated, with an important bug fix, Lx 4.1 ISO's [15:08:02] 2. Wallpaper for Cooker that identifies as Cooker and for Rolling that identifies as Rolling [15:08:02] 3.. Announcing Rolling. [15:08:02] 4. Releasing OM Lx 4.2 Alpha [15:08:34] ben779 add please 5 GitHub sponsor programme [15:08:54] And 6. Future of i686 [15:09:04] (or lack thereof ;) ) [15:09:10] OK, I'm really just making this up as I go. [15:09:29] Like there is any for i685 ;) [15:09:39] Topics: 5. GitHub sponsor program [15:09:49] 6. Future of i686 [15:09:52] Well, there is one for some packages -- but we can build them without i686 repos these days [15:10:17] What do Y'all want to talk about first? [15:10:53] Doesn't matter, maybe just start at 1... [15:11:03] .Topic 1. Releasing the new updated, with an important bug fix, Lx 4.1 ISO's [15:11:16] Yea, I knew that was coming... [15:12:27] .Topic 1. Releasing the new updated, with an important bug fix, Lx 4.1 ISO's [15:12:51] I have tested both znver1 and x86_64 ISO's on hw and vbox and they work [15:13:21] IMO there's no reason to delay it then -- we didn't throw anything really unsafe at the 4.1 tree [15:13:28] Unless there's something else we want to put into it? [15:13:43] No there are less than 100 packages that are different [15:13:52] There's loads of improvements in cooker, but none that I'd call both important and safe enough to throw at 4.1 [15:14:23] especially once rolling is announced, 4.1 is for people who want sta(b)le [15:14:38] The biggest difference is that grub2-editor and grub2-extra do not get removed by Calamares [15:15:04] Which I can assure you is important to some of our users [15:16:24] rugyada are you here? [15:16:33] yes [15:16:56] Are we just going to post these ISO's on SF and announce them or is there to be more to it? [15:17:39] nothing more, I think [15:18:15] Then let's release these [15:18:28] ok [15:18:54] we should change the name to 4.1.1 or 4.1a or whatever to make a visible difference [15:18:58] need to just drop a few lines for announcement [15:19:04] it would be odd of 2 people downloaded "4.1" and got different results [15:19:13] https://abf.openmandriva.org/platforms/4.1/products/195/product_build_lists/3276 and https://abf.openmandriva.org/platforms/4.1/products/194/product_build_lists/3274 [15:19:51] ACTION: Release to SF and Announce ISO's # 3276 and # 3274 [15:19:52] .Action Release to SF and Announce ISO's # 3276 and # 3274 [15:20:26] .Topic 2. Wallpaper for Cooker that identifies as Cooker and for Rolling that identifies as Rolling [15:21:07] Why only wallpaper? [15:21:12] Just as topic title states, can we start identifying Cooker as Cooker and Rolling as Rolling at least with wallpaper? [15:21:41] It would be better is it was more than wallpaper [15:22:02] Why not whole theme? Starting from bootloader, Plymouth, DM and ksplash and finishing on wallpaper? [15:22:10] Why not? [15:22:19] definitely a good idea [15:22:40] Well I can do that, but first we need to finish integration of many packages into distro-release [15:22:45] might be too much work to do all at the same time, but given cooker and rolling will stay forever, we can keep the indicators forever [15:23:23] OK, can we Action this with understanding that it is In_progress and will take some time. [15:23:46] https://github.com/OpenMandrivaAssociation/distro-release/tree/one-to-rule-them-all [15:24:09] I've already prepared some skeleton but lost some motivation on this [15:24:22] Now I have some free time and I may finish it [15:24:51] how do we call the complete 'set' of images (grub, plymouth,ksplash etc.) distro-theme ? [15:25:26] distro-release-theme [15:25:32] ok [15:25:50] can we have different distro-release-theme packages ? [15:25:58] anyways names are secondary [15:26:07] Yes we can [15:26:20] But first let's complete everything in one place [15:26:33] tpg: it's for properly identify the stuff while talking [15:26:49] And we need to update the cooker2rolling script to exclude distro-release-theme [15:26:49] I'll finish it till end of next week [15:27:12] bero: Um, yep, [15:27:50] rugyada when I'll finish it and build to local repo you will have time to test it and give suggestions [15:28:17] ok [15:28:37] let me know also where I shall upload the images [15:29:39] rugyada sure will give you a sign, but first we have to test that upgrade from current situation will work without issues [15:30:03] I'll be happy to help test this [15:30:07] we'll need some new images for testing [15:30:19] Yes [15:30:44] I have them pretty ready, for development releases [15:31:29] I was thinking about to prepare standard images, and dynamically add marks on them with text Rolling or Cooker, based on distro flavour [15:31:50] https://www.flickr.com/photos/rugyada/ [15:32:30] Is this OK with people here? .Action Upgrade distro-release-theme package to identify Cooker as Cooker and Rolling as Rolling, [15:32:38] tpg: ok just tell me what you need [15:33:04] +1 [15:33:14] Sure [15:33:28] tpg: fine-tuning as we'll go [15:37:32] ACTION: Upgrade distro-release-theme package to identify Cooker as Cooker and Rolling as Rolling [15:37:32] .Action Upgrade distro-release-theme package to identify Cooker as Cooker and Rolling as Rolling [15:37:33] +1 [15:38:41] .Topic 3. Announcing Rolling [15:38:43] Gotta go [15:38:57] Allright tpg, thanks [15:40:09] So should we announce Rolling and when, before or after Lx 4.2 Alpha for instance? [15:40:54] imo before alpha [15:41:35] before to announce I'd suggest to build new rolling isos [15:42:04] so ppl can download the latest ones [15:42:18] fresh ISOs [15:43:00] agreed [15:43:08] this reminds me that isobuilder kind of su**s [15:43:21] Ideally we should do another cp cooker rolling before announcing it [15:43:29] https://abf.openmandriva.org/product_build_lists [15:43:36] So we can got ahead and announce as soon as we finalize an announcement and build new ISO's? [15:43:37] bero: +1 [15:43:59] with the whole 32-bit library stuff being complicated to update (dnf doesn't replace i686 libraries with x86_64 libraries), we probably want to finish that so someone installing rolling won't run into trouble right away [15:44:04] so as far as I'm concerned: [15:44:16] 1. Finish getting 32-bit compat libs into the 64bit repo [15:44:26] 2. Make sure the basics still work [15:44:31] Yeah that makes sense and means we need to wait bit to announce this. [15:44:32] 3. copy cooker to rolling [15:44:35] 4. announce rolling [15:44:39] 5. give it a bit more testing [15:44:45] 6. build 4.2-alpha from rolling repos [15:45:23] Uh, that looks like a good plan to me [15:45:25] that's what we want I think [15:45:30] perfect [15:45:55] as long as the problems with cooker not starting up properly are fixed. [15:47:31] Yes we would not want the VBox problems to be in Rolling or Lx 4.2 Alpha [15:48:00] I actually say the same problem on hardware, so I doubt that it is VBox related. [15:48:56] user reported issue with sddm but it was in 4.1 https://forum.openmandriva.org/t/boot-hang/3599/9 [15:49:31] someone else will have to figure out what's going on there, everything is working perfectly here [15:50:04] I am running X86_64. Does that make a difference? [15:50:33] That forum report is completely unrelated, that was a user installing a version of sddm that should not have ever made it to Lx 4.1. [15:51:01] I am running cooker iso 3275 but not upgraded since install [15:51:16] christann: The Issues I'm talking about in VBox have specific VBox errors so that can not be in hardware I don't think, [15:51:49] on hardware there is this bug: https://issues.openmandriva.org/show_bug.cgi?id=2605 [15:51:54] ben79: I know. but christann's issue looks similar [15:52:02] or not ? [15:52:17] I will try cooker on this hardware soon. [15:52:25] That version of sddm works just fine in Cooker or Rolling [15:53:05] Rolling is runnning well on an old PC here (using Wayland). [15:53:22] If that hardware bug is affecting other users besides me there is a workaround, downgrade systemd, [15:55:01] The issue I have with Cooker in VBox is unrelated to sddm, system boots to sddm login screen just fine and screen displays just fine, it is strictly plasma desktop that does not work. [15:55:28] Was trying to wait for cooker mass rebuild before filing a bug report. [15:56:12] And the VBox errors are about DM not being notified or some such crap. [15:56:41] We need to be sure we are really taking about the same issue. [15:57:13] The issue in bug 2605 is entirely different and occurs well before the sddm login starts. [15:57:47] But bug 2605 is known to be specific to certain hardware so far. [16:02:41] ACTION: 1. Finish getting 32-bit compat libs into the 64bit repo 2. Make sure the basics still work 3. copy cooker to rolling [16:02:42] .Action 1. Finish getting 32-bit compat libs into the 64bit repo 2. Make sure the basics still work 3. copy cooker to rolling [16:02:53] ACTION: 4. announce rolling 5. give it a bit more testing 6. build 4.2-alpha from rolling repos [16:02:53] .Action 4. announce rolling 5. give it a bit more testing 6. build 4.2-alpha from rolling repos [16:03:58] So that partly address this Topic: [16:04:14] .Topic 4. Releasing OM Lx 4.2 Alpha [16:07:52] maybe 5 > 4 and 4 > 5 ? [16:15:34] We can modifying things as we go especially on a multi-point project [16:15:55] I just got crashed, I think by sddm-helper [16:17:35] maybe plasma shell [16:18:42] in my cases, cooker is very unstable in last few days... [16:22:33] We can hope mass rebuild fixes that. [16:23:31] But christann and ben79 may need to get some bug reports done to further define the different issues with Cooker starting up. I know I have 2 completely different issues myself [16:24:34] Bug 2605 and the other is in VBox and not bug reported yet. [16:26:06] In VBox I see: libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE [16:26:20] That is in xorg-session.log [16:27:34] that should definitely be fixed by a rebuild [16:28:06] Also: xsettingsd: loaded 0 settings from .../xsettingsd.conf [16:28:17] That is good to know then [16:28:36] That *should* fix the issues of Cooker in VBox [16:30:25] Anyway as far as releasing Alpha 4.2 I believe rugyada is mostly ready for that we just need to get to the point of generating the ISO's? [16:33:46] I think we are ready as soon as we have completed the 5 steps before [16:34:31] OK [16:35:12] Do we have the people we need to discuss 5. GitHub sponsor program? [16:35:55] Guessing if tpg is not here then no. [16:38:14] is there a mass rebuild step at some time between 1 and 5 ? [16:38:47] I'd say after 5, unless we discover errors the mass build will fix [16:39:05] k [16:39:24] btw. anyone know if tpg fix issue with steam? [16:39:47] Nope [16:39:57] I'll try today [16:40:04] ok [16:40:32] btw. steam works for me, but I use mix of x86_64 and i686 [16:40:42] not pure x86_64 [16:43:10] pure 64 is not ready yet [16:43:19] I just got mesa to build today... [16:43:24] so a few more dependencies missing... [16:43:46] we'll have to double-check wine and steam and any other 32-bit junk that may still be out there when it's done [16:45:59] .Topic 5. GitHub sponsor program [16:46:20] .Topic 5. GitHub sponsor program [16:46:29] tpg? [16:46:53] Yes [16:47:05] GitHub sponsor program [16:47:08] ? [16:47:38] Well topic is to raise awareness about GH sponspor programme [16:47:54] We as Association were accepted to join that programmr [16:48:34] I've started to fill the sponsorship page, but we need support from JCL, bero and others [16:49:44] Things to do: [16:50:11] Enable 2FA login, we need one person who will take care of it. [16:50:29] Create Stripe Connect account to collect donations [16:50:56] Fill tax form [16:50:59] That are the hard part. [16:51:42] Next thing is is to add some content, about our org, our goals, and setup tiers for donations [16:52:30] I've made a draft for these, but would be nice to make a review of it [16:58:35] So anyone who have access please check this dashboard https://github.com/sponsors/OpenMandrivaAssociation/dashboard [17:02:17] Need to go away for few minutes [17:12:26] And back again [17:12:33] OK, thanks tpg, [17:12:53] this looks like something we should keep on the list for next few meetings. [17:14:18] yes, looks good to me so far [17:14:35] If there is anything specific to .action on this let me know and we will .action it [17:14:48] .Topic 6. Future of i686 [17:14:57] probably .action get someone who knows how to do it to take care of the tax form [17:15:09] So, i686... [17:15:49] As cooker users will probably have spotted, 32-bit libraries are starting to show up in x86_64 and znver1 repos [17:15:55] Threre's new macros to help creating those packages [17:16:04] %configure32, %cmake32, %meson32 [17:16:44] They generally act like %configure, %cmake and %meson, except they kill -m64, add -m32 and use a build32 subdirectory in place of a build directory [17:17:43] the idea is to build relevant libraries needed by wine, steam and potentially other i686 stuff we still need - inside the regular packages for the relevant libraries to make sure they never go out of sync [17:18:49] The big difference from before is that the 32-bit and 64-bit versions of libraries now live in the same repositories [17:18:57] Would be nice to build all the packages that steam needs, then i686 repo may be removed [17:19:31] The primary advantage is that this allows us to build a version of wine that can run both windoze64 and windoze32 applications, instead of having to package conflicting and separate wine32 and wine64 packages [17:19:45] Second foo32.x86_64.rpm would be nice to get real arch in file name [17:20:03] The second advantage is that, when we decide we're ready to do it, we can kill the i686 repos [17:20:17] tpg: yes, the goal is to build all packages that wine and steam need [17:20:44] I'm not using any "32" naming right now to keep the same names as before, to ease updating [17:20:57] but I think for 5.0 we should rethink package naming... [17:21:38] because, among other things, with qemu-binfmt stuff being where it is now, it now makes sense to package even few libraries that belong to separate architectures [17:22:12] e.g. i686 and x86_64 versions of wine dependencies on ARM so even an ARM box can run stuff like "wine notepad.exe" (through qemu-binfmt) [17:22:54] If and when we start doing that, the difference between "lib" and "lib64" won't be enough anymore because we may well have a situation where a 64-bit ARM, 32-bit ARM, 64-bit x86 and 32-bit x86 version all have to coexist [17:25:24] and of course at some point in the future, we'll likely have lib128 or lib96 versions as well ;) [17:26:32] Current status: A lot of key packages are ready, last night mesa (which of course has a slew of dependencies) finished building [17:26:50] Still a few things missing, e.g. wine uses gstreamer so the entire multimedia stack needs to be built [17:32:21] A lot of work, and I appreciate it, I suspect a lot of folks would like to see i686 retired. [17:46:24] OK, that sounds like very good news regarding i686 and 32 bit libraries. [17:46:37] .Topic Any Other Business [17:47:07] If there is any other business to discuss now is the time. Otherwise I'll end the meeting in about 10 minutes. [17:50:05] Probably the 5.0 naming scheme is a better topic when more people are around [17:50:14] not too urgent given 4.2 isn't even ready yet... [17:50:14] yes: any chance to have back the option to poweroff pc from grub menu ? [17:50:40] it was like: Other > poweroff (or so) [17:50:58] crazy: ^^^ I think you did that, remember how (or why it was removed)? [18:07:31] bbl [18:21:44] https://github.com/OpenMandrivaAssociation/omdv-build-iso/blob/master/grub2-menus/grub-other-menu.cfg [18:22:04] I reckon I'll end it all now. [18:22:12] Meeting ended by ben79. Total meeting length: 194 minutes [18:22:12] .Endmeeting