16:25:58 <itchka> #startmeeting
16:25:58 <chwido> Woof! Let's start the meeting. It's Wed Nov  6 16:25:58 2019 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
16:25:58 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:25:58 <chwido> You should add extra chair(s) just in case, with #chair nick.
16:25:58 <chwido> Have a good meeting, don't bark too much!
16:26:12 <itchka> Here's the agenda:-
16:26:13 <itchka> 1. OMLx 4.1 alpha release
16:26:15 <itchka> 2. Quick report on Short News
16:26:16 <itchka> 3. Maintenance of Rolling release
16:26:18 <itchka> 4. Alternative Desktop spins
16:26:19 <itchka> 5. AIB
16:26:20 <itchka> 6. AOB
16:26:47 <itchka> Lets start on item 5
16:26:54 * bero is here, just got back from the bathroom
16:27:30 <itchka> Oke dokey then we will start on item 1
16:27:36 <itchka> #item 1
16:27:49 <itchka> #topic OMLx 4.1 alpha release
16:28:29 <itchka> bero: Can you give us the low down on this one.
16:29:14 <itchka> I gathered from ben79 that cooker has been copied acros again.
16:29:38 <bero> So, as we've decided after the 4.0 release, we want to do a relatively speedy 4.1 release, and all the interesting pieces are now falling in place (frameworks 5.64, plasma 5.17.2, qt 5.14, ...), so it's time to make an alpha release and start getting serious about 4.1
16:30:16 <bero> We had a few more problems with the rolling tree initially caused by incorrect build order, that should now be fixed by blacklisting the qt/kde packages and just building them with cooker2rolling when ready
16:30:29 <bero> we've done that for the current 5.64 update, and it looks good so far
16:30:55 <bero> (that's already after copying cooker over again to fix the earlier mess)
16:31:19 <itchka> That's good. How will we manage building in the right order in future?
16:31:41 <bero> same way we've done now -- qt/kde will remain blacklisted and then be built in the right order with cooker2rolling
16:32:00 <bero> ben79 is seeing some problems with systemsettings crashing that I currently can't reproduce
16:32:06 <bero> other than that the current isos seem to be good
16:32:29 * ben79 Here: https://forum.openmandriva.org/t/call-for-testing-candidate-isos-for-om-lx-4-1-alpha-release/3186/6
16:32:29 <itchka> So cooker2rolling works with your buildlists?
16:32:35 <bero> I'll rebuild systemsettings, maybe that'll fix it
16:32:36 <bero> itchka: yes
16:33:10 <bero> ideally, we'll release the alpha on Saturday -- that's when KF 5.64 is officially released, releasing something that already has it might get us some attention in the kde community
16:33:50 <itchka> bero: So will this apply to all the buildlists that exist for just Qt and KF5
16:34:01 <itchka> or just
16:34:16 <bero> just for qt and kf5 for now because that's where the build order is really important
16:34:24 <bero> but we can expand it to other things if we notice similar issues
16:34:59 <ben79> lxqt for instance
16:35:07 <itchka> Ok that seems good to me.
16:35:23 <bero> I get the same
16:35:24 <bero> org.kde.kcoreaddons: Error loading plugin "kcm_workspace" "The shared library was not found."
16:35:25 <bero> Plugin search paths are ("/usr/lib64/qt5/plugins", "/usr/bin")
16:35:25 <bero> The environment variable QT_PLUGIN_PATH might be not correctly set
16:35:34 <bero> error messages from systemsettings, but it doesn't crash for me
16:35:52 <bero> and the errors seem to be harmless because right after spewing the error, exactly the plugin it was complaining about not finding does show up
16:36:01 <bero> something weird going on there, but that seems to be harmless
16:36:05 <itchka> It sounds like we are heading in the right direction now.
16:36:24 <bero> I'm not seeing "kf5.ki18n: "1 instead of 2 arguments to message {The translation file...} supplied before conversion.""
16:36:26 <ben79> It crashes when you go from one kcm module to another
16:36:27 <bero> but not sure why
16:36:38 <bero> ben79: I just went through all the kcm modules and it didn't crash
16:36:41 <ben79> And it does it every time
16:37:29 <itchka> ben79: Ar you running znver1?
16:38:01 <itchka> You both may be on differenct arches
16:38:19 <ben79> this is in x86_64 system installed from ISO ABF # 2850
16:38:23 * bero is on znver1, but I don't see how there could be a difference between the arches in that
16:38:33 <bero> and of course I didn't do a fresh install
16:38:39 <ben79> And I have this on multiple systems not just one
16:38:44 <bero> so it might be some implicit dependency on a package that isn't there
16:38:48 <ben79> mine are fresh installs
16:39:42 <ben79> My concern specifically is about the ISO and if we are trying to release on a certain date to get attention of KDE peoples and they see SystemSettings crash as consistently as I am...
16:40:30 <ben79> And I did run distro-sync after installing the ISO, at that time there were no packages to upgrade or reinstall.
16:41:20 * ben79 Also wish we had more testers but we don't seem to have that
16:41:32 <bero> I'll take a look at the next iso in vbox
16:41:42 <itchka> ben79: I'll try it here
16:42:11 <ben79> I'm going to check znver1 ISO's and if there is no problem with that then we may just need to build a new x86_64 ISO.
16:51:49 <itchka> Ok well that's the fist bug that needs checking and fixing if necessary
16:52:27 <itchka> Shall we move on
16:52:57 <itchka> We can come back to this is necessary.
16:53:07 <itchka> #item 2
16:53:30 <itchka> #topic Quick report on Short News
16:53:46 <itchka> rugyada: I guess this is you?
16:53:56 <ruru[m]> the quick report is we started to publish short news
16:54:20 <ruru[m]> yep
16:54:28 <ruru[m]> thanks to Raphael who took care of it and got a nice web template
16:54:41 <ruru[m]> you can read Short News published here https://www.openmandriva.org/en/news/
16:54:57 <ruru[m]> if anyone has anything they believe is important or they like to share please ping the usual known (Ben, Raph or ruru)
16:55:28 <ruru[m]> :)
16:56:10 <itchka> I'll have something on the iso-builder when I have finished testing which should be tonight.
16:56:38 <ruru[m]> that's all, end of report.
16:56:55 <itchka> Ok Thanks rugyada :)
16:57:04 <itchka> #item 3
16:57:33 <itchka> #topic  Maintenance of Rolling release
16:57:57 <itchka> This is ben79 and me I guess.
16:58:39 <itchka> Do you want to kick this off ben79 or shall I?
16:58:52 <ben79> Go ahead.
16:59:02 <itchka> Ok
17:00:25 <itchka> In dicussion with ben79 we have tried to work out a way of controlling the rate of flow of packages into rolling in order to keep the repository functional.
17:05:49 <itchka> There is a bit of an issue with cooker to rolling. The automated nature of this script can cause all sorts new packages to appear in the testing repos which may or may not break things. Of particular issue is still the fact that all Qt  and KF5  packages must be present before they are released. There doesn't seem to be any easy way of properly regulating the flow of these packages because they take time to build and there will always will be
17:05:51 <itchka> failures for whatever reason.
17:07:48 <itchka> In discussion recently we floated the possibility that the testing repository could be hidden from the outside world temporarily while such builds were taking place therefore minimising breakage for tester.
17:08:03 <itchka> testers
17:10:51 <itchka> We do not know whether this can be done and still allow ABF to function as normal but if it can it would be a great aid to management of the repo since QA could shut it down at times of serious instability.
17:11:06 <itchka> Thoughts pleas...
17:12:56 <ben79> Well the automated script builds every package introduced in Cooker for Rolling/testing unless the packages are blacklisted.
17:14:16 <ben79> I thought and still think this should not happen immediately as there are to many unknowns about building every package introduced in Cooker.
17:14:47 <ben79> One thought is that there be a 3 or more day delay before auto building packages for rolling.
17:15:37 <ben79> And or a list published to QA *before* the packages are built so we can select some to not build. Whether QA can keep up with such a list would be a concern though.
17:17:11 <itchka> I think that's pretty much the same as releasing or blocking packages in Kahinah.
17:18:14 <ben79> Then there wouldn't be anything different from current status would there?
17:19:01 <ben79> Packages go to testing repo/Kahinah, QA either accepts or rejects packages, just like we have been doing with OM Lx 3.
17:20:04 <ben79> If there are any groups of packages that have to built in a certain order they get added to blacklist and we hope someone can write a script to build them correctly.
17:21:13 <ben79> In the past the problem is QA can't keep up with this because we never have had enough people doing this.
17:21:27 <bero> I don't think we should lock access to anything, it doesn't make sense... But of course regular users who don't want any breakage should never enable testing
17:21:31 <bero> we just need to make that clear...
17:21:40 <bero> but if we lock it down, how do we get people to become testers?
17:22:12 <bero> I'd say we have to keep everything open, but give people a strong warning about enabling testing
17:23:01 <bero> I'd agree that it would be better to have a bit of a delay between cooker and rolling/testing so we can prevent stuff from even going to rolling/testing if cooker users see something is wrong
17:23:21 <bero> but OTOH it's testing and the point of testing is that QA can reject anything that goes there...
17:23:35 <itchka> The point of locking it down is so that testers machines don't get hopelessy broken until stuff has finished building or dependency issues have been addressed. Tester are not necessarily experts.
17:24:15 <itchka> They will soon lose interest if their boxes are contantly breaking.
17:26:20 <itchka> If they want that kind of system then they may just as well use cooker.
17:26:29 <ben79> bero: itchka: I do like the idea of a delay before moving packages to rolling/testing. And we can hope for heads up communication from devs on things.
17:26:53 <ben79> So why are testing repos different now than they were in the past?
17:28:08 <itchka> Well for a start there is no update repo so you can't revert a broken package.  It's staright from testing into main.
17:28:36 <itchka> Once it's there if it's broken there ain't no way back.
17:28:47 <ben79> OK, that is one valid point
17:29:30 <ben79> but you can downgrade package if you download them from ABF and if someone does not know how to do that they should not have been using testing repos IMO.
17:30:04 <ben79> No the situation is not perfect, it never has been.
17:30:39 <ben79> But I'm not sure we have identified anything we can actually fix.
17:30:39 <itchka> yeah one package maybe but it starts to get pretty tedious if it's half of Qt and you don't know what all the packages are called.
17:31:48 <ben79> My point is that we really need to focus on releasing OM Lx 4.1 not trying to fix problems we've been living with for literally years.
17:32:10 <ben79> If there is a way to fix something we should explore doing that after OM Lx 4.1 is released.
17:32:53 <itchka> But ben79 the problems introduce by rolling are far worse that those we had before for the reason I have just explained.
17:33:39 <ben79> So what do we do about releasing OM Lx 4.1? Let's answer that first.
17:35:07 <itchka> Close off the testing repo and work with what we have.
17:35:21 <bero> There is a way back, we can always republish a previous build from abf
17:35:32 <bero> it's just not visible outside of abf
17:37:47 <itchka> I guess the user could then downgrade but it's not really practical. The kind of breakage I'm thinking about should be linited to cooker.
17:40:03 <itchka> Can we just hide the testing repo and test what we have. If it has breakage then we can reopen and push packages to fix through. At least then rolling is insualted from any automated builds that might be inherited from cooker.
17:40:48 <ben79> Then what you really are objecting to is automatic builds from Cooker is it not?
17:41:38 <bero> we've tried without having those automatic builds and it didn't work because nobody bothered to do anything about the tens of minor packages that get updated every day...
17:41:55 <bero> we need to find a reasonable way between not having automatic builds and having them right away
17:43:05 <ruru[m]> keep in mind that testing repository are disabled by default
17:44:59 <itchka> ruru[m]: I know that but testers have to enable it to test stuff so they run dnf upgrade  and hey presto everythings broken because a kf5 build is half way through.
17:46:01 <ruru[m]> testers have to be advanced users, not newbies
17:46:22 <ruru[m]> newbies just use system without testing repos enabled
17:46:31 <itchka> Why would you want to be a tester in those circumstances. As far as I can see the ability to close off the repo until the builds are over.
17:46:34 <ruru[m]> and we are ok.
17:46:39 <ben79> itchka: There is no way for this to work without testers accepting responsibility for knowing what they are doing. We don't have resources to make a process so fool proof ordinary users can use testing repos. I don't see that as practical at all.
17:47:08 <christann> Hi
17:47:11 <ben79> Why would you want to be tester unless you know what you are doing?
17:47:34 <ruru[m]> advanced users are supposed to know how to manage system breaks
17:48:15 <ben79> Testing implies problems, that is why you are testing, to find problems, people that look for problems need to be able to deal with problems I think,
17:49:49 <itchka> Well if you don't do something about it you are going to struggle getting releases out.  I don't have any other solutions except ditching the rolling idea as without some modicum of stability testing is pointless.
17:50:35 <itchka> #chair ben79 bero
17:50:35 <chwido> Current chairs: ben79 bero itchka
17:51:46 <ruru[m]> itchka:  what means "ditching the rolling idea"
17:52:12 <itchka> Don't have a rolling release.
17:52:26 <itchka> Go bsck to what we were doing before.
17:52:46 <itchka> bsck=back
17:52:49 <ruru[m]> itchka: this is not an option :)
17:55:45 <bero> The 4.0 release process was a huge mess...
17:55:56 <bero> What we were doing before wasn't really working
17:56:07 <itchka> I have to feed the family. Hopefully ben79 or bero can take over the chair.
17:56:16 <bero> In the end everyone was running cooker, which is not exactly what we want to have
17:56:39 <bero> I still think we need something that's (mostly) safe for day to day use (so not cooker) but more up to date than the sta(b)le release
17:56:46 <bero> We just have to figure out how to do it right
17:57:11 <bero> I think we're on the right track now, but we'll have to sort out some more bits...
17:57:59 <ben79> In line wiht bero's comments: In the middle of the week I was more skeptical about maintaining rolling, but I asked question and learned more and I think the problem is not that it is not workable but that we have to make it work. I now believe this is do-able.
17:58:13 <itchka> You have to regulate the flow of packages from cooker to rolling it's the only way as far as I can see.
17:58:18 <itchka> bbl
18:00:46 <ben79> As far as maintaining Rolling:
18:01:20 <ben79> 1. I don't understand what is different about testing repos today compared to a year ago or 5 years ago >>> Except that we don't have the urpmi recover package. That is a shout coming.
18:01:46 <ben79> 2. The fact there is no updates repo does not seem important. You can downgrade to package in release repo which by the way in rolling functions exactly as updates repo
18:02:42 <ben79> 3. So I believe, and I believe this fits what both bero and itchka have said, the issue is how do we regulate flow of packages from Cooker to Rolling.
18:03:11 <ben79> 4. Let's let this be a WIP and not let it delay releasing OM Lx 4.1 Alpha because
18:03:55 <bero> agreed with all of that
18:04:08 <bero> and of course there is an updates repo for people staying on rock
18:04:54 <ben79> 1. a. The urpmi recover package was unknown to almost all testers even then.
18:05:38 <ben79> (Don't remember the exact name of that package, urpm-recover or something)
18:07:10 <ben79> bero: Yes another point lost in the above conversation is that still to this day nothing has changed as far as our stable release except that we have made it even more stable. Certainly a massive improvement in stability compared to OM Lx 3.
18:08:30 <ben79> I've had Rock systems on multiple computers since day it was released and I don't remember any breakage what so ever, or even any significant stability issue.
18:09:05 <ben79> Someone should get a pat on the back or pat on the head for that.
18:10:19 <bero> And IMO that's partly because we now have rolling
18:10:40 <bero> with rolling available people don't backport stuff to sta(b)le before it's ready
18:11:25 <ben79> Yes, absolutely agree with that
18:11:48 <bero> that's one of the points of rolling -- no more need to compromise, rock can remain sta(b)le and people who want a newer KDE or whatever can use rolling while we'd never tell them to use cooker
18:13:13 <ben79> So currently for Rolling it seems we need to: 1. agree on some form of delay in auto building non-blacklisted packages
18:13:47 <ben79> 2. Realize if there are problems around certain package groups that they can be blacklisted and built a different way or not at all
18:14:48 <AngryPenguin> when it comes to delay, I'm not convinced if it's a good idea
18:14:51 <ben79> 3. Emphasize with developers that when they build packages in Cooker that may adversely affect stability of Rolling they need to give QA a heads up, mention it to itchka for instance.
18:16:24 <ben79> 4. Developers and everyone needs to realize that a part of making this all work lies in not overwhelming QA with more than they can do or tasks we don't know how to do
18:18:37 <bero> AngryPenguin: why not?
18:19:41 <AngryPenguin> bero Look. A few days ago I was building Cinnamon for Cooker and I immediately made sure that each package built correctly also for Rolling.
18:19:51 <AngryPenguin> when the script was disabled and turned on today suddenly there were building errors in Cinnamon in Rolling.
18:20:35 <AngryPenguin> so it will be difficult to check a few days laters if something we built was correctly built in Rolling
18:24:57 <ben79> Interesting point and throws a monkey wrench in things.
18:27:25 <ben79> So that leave me thinking based on AngryPenguin point that we leave Rolling as it is for time being and realize that we have a blacklist and use it when needed.
18:27:41 <ben79> That we do the OM Lx 4.1 Alpha release.
18:28:17 <ben79> That we learn as we go how we are going to maintain Rolling. Discuss issues as they arise.
18:28:20 <bero> true, if we have a delay, we certainly need abf to become more active about screaming at people if a (auto)build failed
18:29:02 <bero> probably the current blacklist catches most of the stuff that could go really really wrong
18:29:35 <bero> we might possibly want to add the X server and mesa, given how easily they can break UIs
18:29:57 <bero> but then we have to make sure people actually do take care of building them in rolling manually after they've worked in cooker for a bit
18:30:22 <bero> would be nice if abf could start nagging people about stuff in rolling that is older than cooker after a while
18:30:46 <ben79> yep
18:34:19 <ben79> mesa and x11-server are in the blacklist already
18:35:43 <ben79> llvm gcc binutils glibc boost mesa icu poppler x11-server kernel-release + Qt5 and some KDE stuff
18:37:52 <ben79> So whether there is or should be a delay or not seems to be under discussion?
18:38:41 <ben79> Which means we stay with status quo and release Lx 4.1 Alpha and see how things go.
18:39:05 <ben79> I expect problems and I expect that we will deal with them as we go forward and as we learn more.
18:40:06 <ben79> When I say I expect problems,I expect we will encounter some problems with Rolling maintenance until we get it sorted out.
18:47:57 <ben79> #topic 3. Alternative desktop ISO spins
18:48:42 <ben79> So what's all this I hear about Alternative desktop ISO spins?
18:50:51 <bero> and do we want to release any of those with alpha1?
18:53:10 <ben79> I think for alpha 1 we should stick to Plasma desktop only and if we decide to do so add other things over time.
18:55:51 <AngryPenguin> well, spins we can release in any time
18:56:41 <AngryPenguin> we can add in announcement that we have functional desktops like gnome, xfce etc and how to install it
18:56:52 <AngryPenguin> and we release isos later with stable release
18:57:02 <AngryPenguin> or sometings like that
18:58:38 <ben79> would not hurt to have a wiki page about available desktops and how to install them
19:00:21 <AngryPenguin> gnome, cinnamon, mate, i3, ice-wm, lxqt, lumina - works
19:00:47 <AngryPenguin> not works budgie and Enlightenment
19:01:31 <ruru[m]> AngryPenguin:  did you fix cinnamon-settings ?
19:01:48 <AngryPenguin> ruru[m] yes,
19:01:52 <AngryPenguin> should work fine now
19:02:07 <ruru[m]> great
19:02:10 <ruru[m]> ty
19:09:10 <ruru[m]> AngryPenguin:  and how is the situation in rolling? you mentioned there were building errors
19:09:55 <AngryPenguin> yes
19:09:58 <AngryPenguin> but fixed it
19:10:18 <ruru[m]> good then
19:11:35 <ruru[m]> imo: alpha1 Plasma only, short mention about functional alternative desktops
19:12:06 <ruru[m]> then if possible build alternative destops iso spins
19:12:33 <ruru[m]> and publish news on them
19:13:25 <ruru[m]> so you can get feedback from each one spin
19:15:07 <ruru[m]> (and don't flood Alpha release with distracting comments too)
19:18:10 <bero> we may also want to check out liri
19:19:12 <AngryPenguin> ahh
19:19:14 <AngryPenguin> qt desktop
19:19:32 <AngryPenguin> now I know why bero is interested xD
19:19:49 <AngryPenguin> * check also deepin desktop
19:28:30 <AngryPenguin> anyway anyone noticed the strange appearance of some things in firefox? I mean for example, buttons etc
19:29:21 <AngryPenguin> like here https://imgur.com/iuAFZeD
19:51:31 <ben79> #topic 4. AIB
19:51:45 <ben79> Package Scribus missing platform independent libraries >>> The only open Rolling bug. Issues occurs in Rock as well. We all know there is more than one bug in Rolling don't we?
19:51:45 <ben79> https://issues.openmandriva.org/show_bug.cgi?id=2554
19:51:45 <ben79> 
19:52:03 <ben79> TV Monitor not correctly recognized.  >>> This bug we need to see if it still persists in OM Lx 4.1 Alpha. Occurs primarily on Intel and nVidia hardware as far as I know.
19:52:03 <ben79> https://issues.openmandriva.org/show_bug.cgi?id=2510
19:52:21 <ben79> Currently 39 Open bugs against Cooker, mostly package/feature request and some bc bug reports, The aforementioned 1 bug report against Rolling, and 12 against Rock.
19:56:42 <bero> I can't reproduce 2554 and never could
19:56:48 <bero> so my hardware doesn't seem to be affected
20:05:38 <ben79> 2554 does not happen on my Ryzen5 computer, I need to test this with current Lx 4.1 Alpha on an Intel box when I get some time.
20:06:21 <ben79> The Ryzen5 computer had Radeon R7-240 GPU that is probably more relevant
20:07:37 <ben79> I'm building a new x86_64 Lx 4.1 Alpha ISO with rebuilt systemsettings package: https://abf.openmandriva.org/platforms/rolling/products/81/product_build_lists/2853
20:07:52 <ben79> will see if that clears up any issue with systemsettings
20:08:23 <ben79> I tried the znver1 ISO in VBox and the problem is less but it does crash on a few modules in systemsettings
20:17:06 <bero> Let's rebuild all of plasma, some of the kcms come from other packages
20:17:40 <ben79> bero: OK
20:17:47 <ben79> sound like good idea
20:18:35 <ben79> I canceled that ISO build. Will wait for plasma rebuild.
20:19:36 <bero> I just wonder why it doesn't crash here
20:19:47 <bero> but maybe there's some remains of my local builds left despite distro-sync
20:25:41 <ben79> back in a min. or so
20:27:49 <ben79> bero: Have you started rebuild of pd.buildlist or shall I?
20:28:59 <ben79> And in this case is that ./cooker2rolling or ./rebuild pd.buildlist?
20:32:42 <bero> I've started it in cooker
20:32:52 <bero> cooker2rolling is only needed if there's changes
20:33:36 <ben79> OK
20:33:37 <bero> The right thing to run is probabyl
20:33:49 <bero> abf chain_build --testing --auto-publish-status testing --no-extra-tests -a znver1 -a x86_64 -a i686 -b rolling --update-type enhancement --no-extra-tests -i pd.buildlist
20:34:41 <bero> (the rebuild script bumps the release number, that can be harmful if run on rolling but not cooker -- it could result in rolling>cooker on some packages)
20:36:07 <ben79> Oh, that is good to know for rebuild, that would be a problem
20:38:13 <ben79> Anyway I'm just gonna wait until it is time to build ISO
20:43:17 <ben79> or just wat
20:43:21 <ben79> or just wait
20:43:53 <ben79> #topic AOB
20:44:05 <ben79> Anyone have Any Other Business?
20:50:34 <AngryPenguin> we plan to release installation images aarch64 and armv7hnl with lx 4.1?
21:03:55 <ben79> We haven't been building packages for those arches very consistently.
21:14:54 <AngryPenguin> bero are you still around?
21:15:13 <berolinux[m]> I've disabled them for the kf/pd rebuild so we don't have additional delays for the alpha, but will definitely put them back
21:15:43 <berolinux[m]> I'm definitely planning to make a 4.1 release there at least for a few boards
21:16:20 <AngryPenguin> berolinux[m] can you look what wrong is with patch? https://github.com/OpenMandrivaAssociation/kernel-release/commit/09c183e74a8ec86809c701be336e3de7e86c154a
21:16:40 <AngryPenguin> trying rebase it for current release but still can;t apply
21:24:37 <ben79> Apologies for being a distracted chair.
21:24:41 <ben79> #endmeeting