15:38:21 <ben79> #startmeeting 15:38:21 <chwido> Woof! Let's start the meeting. It's Wed Oct 23 15:38:21 2019 UTC. The chair is ben79. Information about me at https://wiki.openmandriva.org/en/Chwido. 15:38:21 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:38:21 <chwido> You should add extra chair(s) just in case, with #chair nick. 15:38:21 <chwido> Have a good meeting, don't bark too much! 15:39:31 <ben79> #topic OM Lx 4.1 Alpha Release 15:40:44 <ben79> As far as I know the plan for this that bero is upgrading Plasma desktop to version 5.17.1 and then 15:41:33 <ben79> he will again wipe rolling repositories and copy cooker to rolling and we make ISO's from Rolling branch and that will be OM Lx 4.1 Alpha release. 15:43:01 <ben79> So the best current pre-pre-pre-alpha-preview is the ISO's: 15:43:07 <ben79> https://abf.openmandriva.org/platforms/cooker/products/4/product_build_lists/2788 15:43:26 <ben79> https://abf.openmandriva.org/platforms/cooker/products/53/product_build_lists/2789 15:47:23 <ben79> Meeting agenda: 1. OM Lx 4.1 Alpha Release 15:47:39 <ben79> 2. OMLx 4.1 Alpha wiki pages 15:47:51 <ben79> 3. Rolling maintenance 15:48:08 <ben79> 4. AIB 15:48:17 <ben79> 5. AOB 15:49:20 <ben79> Any discussion about OM Lx 4.1 Alpha Release 15:49:24 <ben79> ? 15:51:17 <rugyada> as the cooker snapshot is a preview of what will be alpha release we need early testing 15:51:44 <rugyada> 2788 and 2789 15:52:30 <rugyada> 2788 is 64bit and 2789 is znver1 15:53:09 <rugyada> the above is for the record 15:53:14 <rugyada> :) 16:00:36 <ben79> So if there is not mere about that. 16:00:38 <ben79> #topic 2. OMLx 4.1 Alpha wiki pages 16:00:51 <rugyada> item 2 is pretty quick 16:01:13 <rugyada> devs to check accurancy of releases: https://wiki.openmandriva.org/en/4.1/New 16:01:33 <rugyada> release notes page should be completed: https://wiki.openmandriva.org/en/4.1/Alpha/Release_Notes 16:01:48 <rugyada> errata also needs to be filled with content https://wiki.openmandriva.org/en/4.1/Alpha/Errata 16:02:14 <rugyada> Q may be what notes to write in errata 16:02:42 <rugyada> so far we see the graphical glitches 16:02:54 <rugyada> but no workaround afaik 16:03:27 <rugyada> anyone knows of anything else? 16:04:12 <rugyada> we did test all latest ISOs 16:04:31 <rugyada> no big issues that I have noticed 16:04:41 <rugyada> also considering it's alpha 16:05:22 <rugyada> overall quality looks pretty good. 16:06:05 * rugyada is done with wiki page item 16:06:45 <ben79> Basically most of the wiki pages is modifying content from 4.0 wiki pages and adding to errata about graphic glitches 16:08:03 <ben79> The graphic glitches are thought to be related to Qt packages which are version 5.14.0beta and it is thought that they will go away as Qt-5.14 is developed for it's Nov. release. 16:08:51 <ben79> That information came from bero 16:11:08 <ben79> I'll also at some point add to Lx 4.1 errata something about the TV as monitor issue: https://issues.openmandriva.org/show_bug.cgi?id=2510 16:11:38 <ben79> but I need to check and update what I know about that first. 16:13:57 <rugyada> wondering if we should mention the clang kernel in release notes, as it's not in default iso but can be installed lately (IIRC) 16:14:30 <rugyada> later* 16:19:14 <ben79> I would thing we should mention 16:20:48 <ben79> Except not yet because the clang kernel version is not yet in Rolling repositories and that is the Repos Lx 4.1 will be using until repos are split. 16:21:46 <rugyada> ok 16:22:15 <ben79> I have another point that goes to Topic 1. OM Lx 4.1 Alpha Release 16:23:09 <ben79> Based on results we see in our Forum we really need to give strong consideration to not have repositories for every branch in our Lx 4.1 release. 16:24:09 <ben79> If users want to upgrade to Rolling or Cooker it would be simple to instruct them to install the correct distro-release packages and have that add the correct repository or something like that. 16:26:51 <AngryPenguin> ruru[m] in https://wiki.openmandriva.org/en/4.1/New we should change digikam from 6.2 to 6.3 :) 16:27:07 <ben79> Or just to simply to add the correct repos as a openmandriva-repo package. 16:28:29 <rugyada> AngryPenguin: thanks 16:32:51 <rugyada> ben79: I tend to agree 16:33:08 <ben79> #chairs rugyada itchka_ 16:33:21 <ben79> #chair rugyada itchka_ 16:33:21 <chwido> Current chairs: ben79 itchka_ rugyada 16:34:14 <ben79> rugyada: Yes we have seen the results, granted though it applies more to the "shot oneself in the foot" type of user, the issue came up a lot 16:37:41 <rugyada> I believe the kde developer preventing to run dolphin as root must have dealt with the same kind of users :P 16:37:52 <rugyada> now I start to understand him 16:38:30 <ben79> there's a thought 16:38:43 <ben79> there's a thought to ponder 16:45:22 <ben79> So if nothing else about wiki pages 16:45:41 <ben79> #topic 3. Rolling maintenance 16:46:49 <ben79> So we are getting ready once again to "fix" some problems that occur in Rolling repos by wiping the repos and copying cooker to rolling 16:47:33 <ben79> So I asked why this keeps happening and bero suggested that perhaps because the packages in rolling are not being built in the correct order. 16:48:08 <ben79> We all know that the Qt and KDE package lists have to be built in a very specific order or there will be problems. 16:48:59 <ben79> So what may be happening is that when they are correctly built in Cooker then the Automated mechanism in ABF then builds them for Rolling but not in correct order. 16:49:41 <ben79> So the thought is to correct this we add the Qt, KF, Plasma desktop, and KApps package lists to the Rolling blacklist. 16:50:13 <ben79> Then this becomes incumbent on the Cooker dev that builds the packages to inform when they are ready for Rolling build 16:50:30 <rugyada> ben79: sounds wise 16:50:56 <ben79> Then QA minion will build these with the cooker2rolling script combined with the package lists. 16:51:28 <ben79> Thus we hope this will correct the recurring problems we have been seeing 16:51:59 <ben79> and we can then get Rolling in proper order to announce for public/users. 16:58:23 <ben79> So if there is nothing else regarding rolling maint. 16:58:44 <ben79> #topic 4. AIB 16:59:31 <ben79> There are some bugs it would be good to get fixed in time for Lx 4.1 release: 16:59:37 <ben79> LXQt desktop fails to start. http://issues.openmandriva.org/show_bug.cgi?id=2541 16:59:47 <ben79> Login to Icewm does not work correctly. http://issues.openmandriva.org/show_bug.cgi?id=2552 16:59:53 <ben79> TV Monitor not correctly recognized. https://issues.openmandriva.org/show_bug.cgi?id=2510 17:02:07 <ben79> The TV Monitor bug needs to be checked in Cooker to be sure it has not been fixed by osmosis. 17:02:34 <ben79> The other two I have checked and they are still present in Cooker as well as other branches. 17:05:53 <itchka_> Back 17:06:23 <ben79> Just in time to rescue this meeting... 17:06:27 <itchka_> Ben79: I think you are right about the build order issue. 17:07:09 <ben79> I suppose someone should spend some time looking in ABF to confirm this, 17:07:16 <itchka_> We had no lights in our kitchen so it was a must fix. 17:07:34 <ben79> Yes that would be a must fix. 17:08:02 <itchka_> I shouldn't be too hard as the build date and time are recorded alongside the buildlist 17:09:35 <itchka_> It was Qt that was the problem but I'm not sure it's that simple. It could happen on cooker if there was a build failure of one package so we would end up with an incomplete set. 17:10:28 <itchka_> Depending on how they were rebuilt in cooker it may be that we would only get the rebuilds 17:11:10 <itchka_> and not the whole lot. 17:13:25 <itchka_> I agree though that currently maintenance on rolling is impossible. I'm of the opinion that the automated build of cooker packages into rolling is not a safe bet. We could end up with sorts of crap while people are tring to sort out problems. 17:14:34 <itchka_> Currently I haven't had time to think about a possible solution. 17:17:31 <ben79> Well there are other things like tool-chain package stacks that need to be built in a correct order aren't there? 17:17:49 <itchka_> Yes but they are on the blacklist 17:18:46 <ben79> My understanding is that they were blacklisted for stable but that not all are blacklisted for Rolling 17:18:56 <ben79> but we don' 17:19:09 <ben79> but we don't know what is blacklisted do we? 17:19:33 <itchka_> I don't know where the blacklists are. 17:19:34 <ben79> That blacklist needs to be accessible for devs and QA it seems 17:20:34 <ben79> fdrt: HisShadow: We are wondering where the blacklists are for Rolling and stable repos? 17:22:08 <ben79> Just want to know what is in those lists for QA purposes 17:22:14 <itchka_> Another thing we need to do is to have a handle on what might be affected by the updates. 17:22:37 <ben79> which updates? 17:23:39 <itchka_> Packages that are automatically dumped into testing. 17:26:00 <ben79> As far as I know that would be whatever package groups have to be built in a specific order, except that 17:26:42 <ben79> for instance even in cooker I don't think we know what other packages besides Qt and KDE are affected when those are rebuilt but we know there are some 17:27:34 <ben79> quite a few in fact, how often do we hear "Well to fix that you just need to rebuild that because of the <foo> update: 17:28:07 <itchka_> It's not that simple Ben some packages have wide ranging effects. poppler is a good example it affects loads of packages and they all have to be rebuilt if poppler changes. 17:28:09 <ben79> From a QA standpoint for trying top maintain something as a stable release that is a bad answer. 17:29:09 <itchka_> I think we have to approach the problem in a different way. 17:29:20 <ben79> I thought that was why some tool-chain packages would be blacklisted even for Rolling, all of them should be blacklisted for stable. 17:31:03 <ben79> At present the only way OM can maintain something as "stable" is to not change the tool-chain because none of us have a handle on what is affected by things like poppler other than "a lot" 17:31:57 <ben79> Again form a QA perspective that is a lousy answer to a problem a user has. 17:33:17 <itchka_> Well there are tools in dnf which may help us perhaps something like sudo dnf repoquery --whatrequires poppler would give some aid. 17:34:25 <ben79> rpm would likely have more tools than dnf 17:34:55 * ben79 Maybe we should ask Ubuntu how they handle this? 17:35:07 <itchka_> :) 17:35:20 * ben79 Gasp, horrors. cough, cough 17:36:09 <ben79> But I do think things like this are an area where it may be wise to ask or otherwise found out how other distros deal with this type of problem. 17:36:10 <itchka_> That query only returned 3 packages and I know that's not true. 17:37:07 <AngryPenguin> itchka check in abf 17:37:09 <AngryPenguin> https://abf.openmandriva.org/build_lists/611462/dependent_projects 17:39:00 <itchka_> I just get a 404 as soon as I select an entry 17:40:22 <AngryPenguin> ok, open abf search for poppler 17:40:39 <AngryPenguin> the open any previous build 17:41:14 <AngryPenguin> and on right is create build list of depentend project 17:41:58 <itchka_> Yes 17:42:36 <ben79> It seems like it should be automatic for any package or package group that has other packages that have to be rebuilt, 17:43:12 <itchka_> AngryPenguin: But I can't see any list 17:45:12 <AngryPenguin> itchka_ https://imgur.com/PHzxgtN 17:45:27 <itchka_> poppler has a QT5 lib yet no KDE packages are showing up in the generated list 17:45:51 <ben79> I don't see a dependent packages button 17:46:12 <itchka_> ben79: Open a build list 17:47:04 <ben79> Ah now I see it \ 17:47:18 <ben79> and I can't believe that list is complete 17:47:57 <itchka_> ben79: Nor I 17:48:55 <ben79> Actually if I were going to pick a distro to ask about this I would go to perhaps openSUSE 17:50:37 <ben79> I used openSUSE for a long time, part of the time, and one reason was the their updates very rarely cause "other" problems. You just updated and kept on using whatever. 17:50:38 <itchka_> AngryPenguin: I can't get to that list. 17:51:04 <itchka_> Did you generate it? 17:51:21 <AngryPenguin> itchka_ you have been deprived of your rights :) 17:51:27 <itchka_> Maybe it is unique to you. 17:51:39 <itchka_> I don't think so 17:52:26 <AngryPenguin> no, just click on existing build and then I see this button create build list of dependent project 17:52:33 <ben79> itchka_: https://imgur.com/a/wsrDkyU 17:52:33 <AngryPenguin> noting more for me 17:52:56 <itchka_> AngryPenguin: So you press the button? 17:53:00 <AngryPenguin> yes 17:53:01 <ben79> yes 17:53:06 <itchka_> Ah ok 17:54:20 <ben79> So right now the summary of this conversation is that there is going to be more, quite a bit more, to maintaining rolling repos than just building the qt and kde package in the right order 17:54:49 <ben79> one problem is that there are other packages that we don't know what else needs to be rebuilt when they are built 17:55:21 <ben79> this seems like a fundamental short coming for QA the QA won't be able to resolve by itself 17:55:37 <itchka_> I'd like to know how those lists are generated. 17:56:02 <ben79> I don't know if those lists were generated or if bero created them 17:56:09 <itchka_> I think you have seen my point Ben 17:56:32 <itchka_> Maybe they are generated by abf 17:58:04 <ben79> So for the time being I think we should table any idea of a public announcement regarding rolling other than that it exists, we are working on it, and there are unresolved issues at this time. 17:58:46 <itchka_> I believe it would be extremely unwise to announce rolling. 18:01:09 <itchka_> I need to think about it some more and see if we can work out a low labour method of dealing with the issue. I have a half a plan but I have so much on my plate at the moment that I really can't do anything about it at the moment. 18:01:57 <ben79> Yes, it would be. And now I realize that all those people since Lx 3 yammering for "Why don't we go to rolling release" clearly were not considering all that is involved in doing that in a way that is usable for Linux users 18:02:22 <itchka_> One of the issues with this whole thing is that "packages" on ABF contain multiple rpms. 18:03:02 <ben79> But the main issue to making a rolling release workable seems to be: 18:03:36 <ben79> Getting a handle on *All* the packages that require other packages to be rebuilt when they are built 18:03:37 <itchka_> So it's no good just saying --whatrequires poppler you have to do --whatrequires on all the files that constitute a poppler build on abf. 18:04:17 <itchka_> Do you see where I am coming from? 18:05:15 <ben79> Yes, but I already knew that there were packages beyond qt and kde that have this requirement at least in the tool-chain 18:05:50 <ben79> and I still think there are more package that need to be rebuilt for qt especially that we don't have listed. 18:05:50 <itchka_> I just can't think of an easy way around this at the moment. 18:07:36 <ben79> I've been wondering for weeks if rolling should not go to a "back burner" and we go back to former plan. 18:08:16 <ben79> Right now it seems rolling is creating extra work without producing results we want. 18:08:44 <itchka_> To be honest Ben I always thought it was a bad idea and I did say so but the majority wanted it. 18:09:23 <ben79> Well now everyone else has more clear evidence. 18:10:23 <itchka_> However to be constructive I am still trying to come up with a way around the difficulties it presents. 18:11:48 <ben79> I'm also not saying (yet) that we put rolling on the "back burner" but I am suggesting we need to be aware that this may be an idea we don't have the tools to make work. 18:11:49 <itchka_> I think for it to work we need acces to the ABF database. I'm pretty sure all the information we need is in there it just needs putting together ina helpful way. 18:12:49 <itchka_> If we can pull off rolling we will be ahead of the other distros 18:13:20 <itchka_> Technically it's feasable. 18:16:58 <itchka_> As an example of what could be done. With the correct information Kahinah could list packages in testing by the number of rebuild dependencies each package has. This would give a league table of what it would be sane to test and release. 18:17:42 <itchka_> Suddenly we would be in control and not floundering around legless. 18:19:04 <itchka_> Anyways lets look quickly at your bugs 18:19:59 <itchka_> The icewm bug looks fixable 18:21:01 <ben79> This is a different computer than the one used to file bug 2510 18:21:07 <itchka_> I suspect the second is icewm wayland which almost certainly not going to work! 18:22:18 <itchka_> Did you just install task-icewm or similar? 18:22:21 <ben79> but on this computer with radeon graphics using tv as monitor just works, however we have already thought that was an intel graphics issue anyway 18:22:30 <ben79> so I'll tesl that later. 18:23:18 <ben79> for icewm: dnf install icewm 18:23:24 <itchka_> Ok 18:23:34 <ben79> for lxqt: dnf install task-lxqt 18:23:54 <itchka_> I know what is causing the LxQt one 18:24:02 <ben79> icewm works it is the entries on the sddm login page that need to be fixed which should be simple 18:24:26 <itchka_> It's a missing symbol in a qt library 18:24:46 <ben79> Just change the "icewm-session" to "icewm" and remove the other one and declare victory 18:24:46 <itchka_> The whole of lxqt needs rebuilding. 18:25:05 <ben79> see that is another list we don't have yet 18:25:35 <ben79> that should be automatic if we are going to be able to maintain a rolling release or semi-automatic 18:26:48 <itchka_> It's probably broken on cooker too. 18:27:12 <ben79> actually I think there is a lxqt list in KDE-packaging-tools 18:27:24 <itchka_> I guess I could risk running bero's tool 18:27:29 <itchka_> Thereis 18:27:37 <ben79> it is broken on cooker and rolling for sure 18:28:02 <ben79> we're supposed to use bero's tool I do 18:29:29 <itchka_> I haven't used it myself I only know of it. 18:30:01 <itchka_> Best set it going on cooker then. 18:30:04 <ben79> but I have not used it with lists, or if that works 18:30:45 <itchka_> Ok don't worry i'll do it later. I have to go now I have a skype call. 18:34:35 <AngryPenguin> btw. for icewm, we can update it to latest version 18:34:46 <AngryPenguin> maybe it comes with some fixes 18:35:15 <ben79> Good idea 18:35:35 <AngryPenguin> ben79 in last time i fix this issue with otter https://issues.openmandriva.org/show_bug.cgi?id=2550 18:40:41 <ben79> Thanks for that one. 18:41:14 <bero> temporarily back (at the airport waiting for departure) 18:41:20 <bero> the *.buildlist files are written manually 18:41:31 <bero> but if we had to do that more frequently it could be automated 18:41:57 <bero> but since we already have them, automating it would be a lot more work than just updating them manually once in a while 18:47:42 <ben79> good, then that probably means there would be a way to automate build lists for other packages that require more package to be rebuilt? (hope this makes sense) 18:47:57 <ben79> like poppler for example 18:58:50 <ben79> So if no more on those bug reports for now 18:59:00 <ben79> #topic 5. AOB 18:59:17 <ben79> Any Other Business? 19:02:23 <bero> the basic idea to see what needs to be rebuilt is 19:02:41 <bero> dnf repoquery --whatrequires [whatever is being checked for] 19:03:45 <bero> it's important to do the same for subpackages 19:03:57 <bero> e.g. to get a list of anything that uses poppler (and therefore needs to be rebuilt) 19:04:23 <bero> dnf repoquery --whatrequires lib64poppler91 19:04:36 <bero> dnf repoquery --whatrequires lib64poppler-qt5_1 19:04:45 <bero> dnf repoquery --whatrequires lib64poppler-glib8 19:05:07 <bero> dnf repoquery --whatrequires lib64poppler-cpp0 19:05:35 <ben79> yes, that makes more sense, when you run the subpackages you get the complete picture it looks like. 19:07:27 <AngryPenguin> I have small question 19:07:57 <ben79> So this is do-able 19:08:04 <AngryPenguin> what with personal repositories? When last time I checked it still didn't use DNF. So If I build package "A" in personal repo and then want to build package "B" that depend on "A" from this repo, then ABF cant find this repository. 19:09:57 <AngryPenguin> fdrt ^^ 19:10:34 <bero> got to go, plane about to leave 19:10:54 <ben79> Have a great trip with much success bero. 19:16:20 <AngryPenguin> bero and dont drink too much vodka xD 19:23:11 <ben79> OK, I think that's enough meeting. 19:23:17 <ben79> #endmeeting