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