16:06:54 <itchka> #startmeeting
16:06:54 <chwido> Woof! Let's start the meeting. It's Wed Jun 19 16:06:54 2019 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
16:06:54 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:06:54 <chwido> You should add extra chair(s) just in case, with #chair nick.
16:06:54 <chwido> Have a good meeting, don't bark too much!
16:07:04 <ben79> Thought Xsane does work here so far
16:08:08 <itchka> What is the problem with xsane?
16:10:00 <ben79> bero says it has not been maintained for 8 years
16:10:47 <ben79> but as I said it works here, the original issue was that task-scanning is incorrectly name omv2015 instead of omv4000
16:10:48 <itchka> It's always worked for me maintained or not.
16:11:08 <itchka> Ah ok
16:11:34 <ben79> I'm just trying to get dnf to install omv4000 package not 2015 one we gotta get those 2015 and other incorrectly named package gone, gone
16:13:23 <bero> back again
16:13:40 <itchka> Hi bero
16:13:47 <bero> xsane does work, but skanlite works better and is still maintained
16:13:58 <ben79> It's gotta be the metadata and the fact we have both task-scanning 2015 and 4000 packages
16:14:08 <itchka> Let's start
16:14:08 <HisShadow_> bero: you can remove them in the platform file listing on abf, just be careful
16:14:16 <HisShadow_> err, that was for ben79
16:15:01 <ben79> HisShadow_: I'll  always tell bero or other dev what I'm doing if i do this because if I remove something that should instead be rebuilt...
16:15:25 <itchka> #item 1
16:15:43 <fdrt> ben79 need to create a list of packages with 2015 tag
16:15:45 <fdrt> than rebuild it
16:15:47 <itchka> #topic Report: ABF, cooker
16:15:48 <fdrt> than remove old
16:16:34 <itchka> bero: Over to you
16:16:43 <ben79> fdrt: in the case there are task-scanning 2015 and also task-scanning 4000 packages in 4.0 probably all of the repos
16:17:49 <bero> So ABF is still working well with the usual glitches we'll have to find fixes for at some point (builds aborting because buildroot  creation fails because a package is being updated or something)
16:17:59 <bero> cooker is still essentially 4.0, but starting to diverge
16:18:19 <bero> TPG has bumped the libarchive soname, I'm about to throw in Qt 5.13.0
16:18:31 <bero> after that cooker will diverge from the other trees again
16:18:39 <bero> so no more easy "let's just copy binaries around"
16:18:56 <bero> that's pretty much all from me -- does anyone else have anything to add on the topics?
16:19:14 <bero> Of course once Qt 5.13.0 is built, will build KDE Frameworks 5.59 and Plasma 5.16.1
16:19:30 <HisShadow_> bero: I remember you were saying yesterday about packages needing to go into updates instead of release
16:19:41 <HisShadow_> bero: need to set Released on the platform, that's it
16:20:20 <bero> Also looking into LLVM master, I've found a few patches that should make RISC-V hardfloat work
16:20:28 <bero> HisShadow_: yes, seen it and activated the button, thanks
16:20:35 <itchka> Won't it have to be set on rock as well as rolling.
16:21:40 <bero> No, rolling will never be "released"
16:21:54 <bero> because all builds are supposed to go to rolling/release and not rolling/updates
16:21:55 <HisShadow_> we don't have rock, it's just a symlink I think, and yeah, makes more sense for rolling to never be released
16:21:59 <itchka> Then how will packages be firected to testing?
16:22:02 <bero> rock is a symlink to 4.0 so it's set there
16:22:09 <itchka> firected=directed
16:22:18 <bero> That's a flag to publishing while building
16:22:26 <HisShadow_> there are testing repos
16:22:40 <bero> When using the abf command line client, use abf --auto-publish-status testing
16:22:56 <itchka> bero: That's really dodgy we can't really have that someones bound to forget.
16:24:04 <bero> And in the web builder, select "Into testing" in the Automated publishing dropdown
16:24:18 <bero> I just use scripts that make sure I never forget
16:24:41 <bero> I have a "cooker2rolling" script that merges cooker commits into rolling and then starts a build with --auto-publish-status testing
16:24:50 <bero> but I agree that it would be nice to prevent "default" publishing
16:25:18 <bero> HisShadow_: fdrt: Can we have modify abf to allow only publishing to testing for rolling? (And preferably 4.0 as well)?
16:26:35 <itchka> bero: If we don't 'set it in stone' we will end up in exactly the same position as we were before which made a nonsense of the rolling release.
16:27:58 <AngryPenguin> bero I would suggest to give up publishing for testing in unsupported repo
16:28:24 <AngryPenguin> unsupported is mostly broken so if we fix/update somethings in unsupported then we can publish it without QA
16:28:31 <AngryPenguin> this should save time for QA
16:29:01 <bero> agreed, but we can't set rolling to "released" because that would keep a messy release/ tree and a giant updates/ tree -- so we need a different way to block publishing directly to release/
16:29:18 <bero> AngryPenguin: I'd agree there as well, given unsupported means unsupported -- what do QA people thing?
16:29:21 <bero> think even?
16:31:02 <itchka> When we ram 2014 and to some extent 3 through kahinah we always pushed the packages straight through from contrib. No reaso why that should change.
16:31:18 <itchka> ram=ran
16:32:26 <rugyada> agreed
16:32:34 <rugyada> unsupported=unsupported
16:33:34 <fdrt> bero need to ask hisshadow about it
16:33:55 <fdrt> just regular users (not admins) can publish only in testing for released platforms
16:34:03 <fdrt> you are admin
16:35:16 <itchka> contrib/unsupported is a side issue. We must do something about rolling. When all this was discussed the key point for approval was that no packages could be published into rolling without going through testing.
16:38:43 <itchka> If that can be criteria can be avoided by anyone, admin or not it has the potential to make a nonsense of the rolling release.
16:39:43 <bero> fdrt: rolling isn't a released platform (stuff still needs to go to release/ rather than updates/ after it goes out of testing...), so we need the same block for it while it isn't "released"
16:45:25 <ben79> task-scanning                                        noarch                                 2015.0-5  >>> this is not in repos at abf-downloads.org but dnf is still pulling it
16:45:50 <ben79> I think I removed the mirror list stuff from repo and enabled baseurl but still
16:46:17 <ben79> and yes dnf clean all has been done about 20 times
16:47:17 <ben79> I don't think we want to wait on mirrors to update to test what we do in ABF so I must not have that part correct yet
16:49:15 <ben79> No packages here: /var/cache/dnf/rock-updates-x86_64-425e07d6e464da23/
16:49:36 <ben79> updates is where latest task-scanning is
16:53:29 <bero> I'm checking on the server right now... Can't find it in the obvious places either
16:53:48 <ben79> repo: downloading from remote: rock-updates-x86_64
16:53:59 <ben79> what is remote?
16:54:08 <ben79> mirror?
16:54:57 <bero> ./cooker-obsolete/repository/znver1/main/release/task-scanning-4.0-6-omv4000.noarch.rpm
16:54:59 <bero> ./cooker-obsolete/repository/znver1/main/release/task-scanning-4.0-5-omv4000.noarch.rpm
16:55:01 <bero> ./cooker-obsolete/repository/x86_64/main/release/task-scanning-4.0-6-omv4000.noarch.rpm
16:55:03 <bero> ./cooker-obsolete/repository/i686/main/release/task-scanning-4.0-6-omv4000.noarch.rpm
16:55:05 <bero> ./3.0/repository/i586/main/release/task-scanning-2015.0-5-omv2015.0.noarch.rpm
16:55:07 <bero> ./3.0/repository/x86_64/main/release/task-scanning-2015.0-5-omv2015.0.noarch.rpm
16:55:09 <bero> ./3.0/repository/armv7hl/main/release/task-scanning-2015.0-5-omv2015.0.noarch.rpm
16:55:11 <bero> ./3.0/repository/aarch64/main/release/task-scanning-2015.0-3-omv2015.0.noarch.rpm
16:55:13 <bero> ./openmandriva2014.0/repository/i586/main/release/task-scanning-2014.0-2-omv2014.0.noarch.rpm
16:55:15 <bero> ./openmandriva2014.0/repository/x86_64/main/release/task-scanning-2014.0-2-omv2014.0.noarch.rpm
16:55:17 <bero> ./rolling/repository/znver1/main/release/task-scanning-4.0.1-7-omv4000.noarch.rpm
16:55:19 <bero> ./rolling/repository/armv7hnl/main/release/task-scanning-2015.0-5-omv2015.0.noarch.rpm
16:55:21 <bero> ./rolling/repository/x86_64/main/release/task-scanning-4.0.1-7-omv4000.noarch.rpm
16:55:23 <bero> ./rolling/repository/i686/main/release/task-scanning-4.0.1-7-omv4000.noarch.rpm
16:55:25 <bero> ./rolling/repository/SRPMS/main/release/task-scanning-4.0.1-7.src.rpm
16:55:27 <bero> ./rolling/repository/SRPMS/main/release/task-scanning-4.0-6.src.rpm
16:55:29 <bero> ./rolling/repository/aarch64/main/release/task-scanning-2015.0-5-omv2015.0.noarch.rpm
16:55:31 <bero> ./rolling/repository/aarch64/main/release/task-scanning-4.0-6-omv4000.noarch.rpm
16:55:33 <bero> ./rolling/repository/aarch64/main/release/task-scanning-2015.0-3-omv2015.0.noarch.rpm
16:55:35 <bero> ./rolling/repository/riscv64/main/release/task-scanning-2015.0-5-omv2015.0.noarch.rpm
16:55:37 <bero> ./cooker/repository/znver1/main/release/task-scanning-4.0.1-7-omv4000.noarch.rpm
16:55:39 <bero> ./cooker/repository/armv7hnl/main/release/task-scanning-2015.0-5-omv2015.0.noarch.rpm
16:55:41 <bero> ./cooker/repository/x86_64/main/release/task-scanning-4.0.1-7-omv4000.noarch.rpm
16:55:43 <bero> ./cooker/repository/i686/main/release/task-scanning-4.0.1-7-omv4000.noarch.rpm
16:55:45 <bero> ./cooker/repository/SRPMS/main/release/task-scanning-4.0.1-7.src.rpm
16:55:47 <bero> ./cooker/repository/aarch64/main/release/task-scanning-2015.0-5-omv2015.0.noarch.rpm
16:55:49 <bero> ./cooker/repository/aarch64/main/release/task-scanning-2015.0-3-omv2015.0.noarch.rpm
16:55:51 <bero> ./cooker/repository/aarch64/main/release/task-scanning-4.0-6-omv4000.noarch.rpm
16:55:53 <bero> ./cooker/repository/riscv64/main/release/task-scanning-2015.0-5-omv2015.0.noarch.rpm
16:55:55 <bero> ./openmandriva2013.0/repository/i586/main/release/task-scanning-2011.0-4-omv2013.0.noarch.rpm
16:55:57 <bero> ./openmandriva2013.0/repository/x86_64/main/release/task-scanning-2011.0-4-omv2013.0.noarch.rpm
16:55:59 <bero> ./4.0/container/561261/armv7hnl/main/release-rpm-new/task-scanning-4.0-6-omv4000.noarch.rpm
16:56:01 <bero> ./4.0/container/561261/SRPMS/main/release-rpm-new/task-scanning-4.0-6.src.rpm
16:56:03 <bero> ./4.0/container/561273/i686/main/release-rpm-new/task-scanning-4.0-7-omv4000.noarch.rpm
16:56:05 <bero> ./4.0/container/561273/SRPMS/main/release-rpm-new/task-scanning-4.0-7.src.rpm
16:56:07 <bero> ./4.0/container/561262/znver1/main/release-rpm-new/task-scanning-4.0-6-omv4000.noarch.rpm
16:56:09 <bero> ./4.0/container/561262/SRPMS/main/release-rpm-new/task-scanning-4.0-6.src.rpm
16:56:11 <bero> ./4.0/container/561258/x86_64/main/release-rpm-new/task-scanning-4.0-6-omv4000.noarch.rpm
16:56:13 <bero> ./4.0/container/561258/SRPMS/main/release-rpm-new/task-scanning-4.0-6.src.rpm
16:56:15 <bero> ./4.0/container/561260/i686/main/release-rpm-new/task-scanning-4.0-6-omv4000.noarch.rpm
16:56:17 <bero> ./4.0/container/561260/SRPMS/main/release-rpm-new/task-scanning-4.0-6.src.rpm
16:56:19 <bero> ./4.0/container/561272/x86_64/main/release-rpm-new/task-scanning-4.0-7-omv4000.noarch.rpm
16:56:21 <bero> ./4.0/container/561272/SRPMS/main/release-rpm-new/task-scanning-4.0-7.src.rpm
16:56:23 <bero> ./4.0/container/561259/SRPMS/main/release-rpm-new/task-scanning-4.0-6.src.rpm
16:56:25 <bero> ./4.0/container/561259/aarch64/main/release-rpm-new/task-scanning-4.0-6-omv4000.noarch.rpm
16:56:27 <bero> ./4.0/container/561274/znver1/main/release-rpm-new/task-scanning-4.0-7-omv4000.noarch.rpm
16:56:29 <bero> ./4.0/container/561274/SRPMS/main/release-rpm-new/task-scanning-4.0-7.src.rpm
16:56:31 <bero> ./4.0/repository/znver1/main/release/task-scanning-4.0-6-omv4000.noarch.rpm
16:56:33 <bero> ./4.0/repository/znver1/main/updates/task-scanning-4.0-7-omv4000.noarch.rpm
16:56:35 <bero> ./4.0/repository/armv7hnl/main/release/task-scanning-2015.0-5-omv2015.0.noarch.rpm
16:56:37 <bero> ./4.0/repository/x86_64/main/release/task-scanning-4.0-6-omv4000.noarch.rpm
16:56:39 <bero> ./4.0/repository/x86_64/main/updates-rpm-backup/task-scanning-4.0-6-omv4000.noarch.rpm
16:56:41 <bero> ./4.0/repository/x86_64/main/updates/task-scanning-4.0-7-omv4000.noarch.rpm
16:56:43 <bero> ./4.0/repository/i686/main/release/task-scanning-4.0-6-omv4000.noarch.rpm
16:56:45 <bero> ./4.0/repository/i686/main/updates/task-scanning-4.0-7-omv4000.noarch.rpm
16:56:47 <bero> ./4.0/repository/SRPMS/main/release/task-scanning-4.0-6.src.rpm
16:56:49 <bero> ./4.0/repository/SRPMS/main/updates-rpm-backup/task-scanning-4.0-6.src.rpm
16:56:51 <bero> ./4.0/repository/SRPMS/main/updates/task-scanning-4.0-7.src.rpm
16:56:53 <bero> ./4.0/repository/aarch64/main/release/task-scanning-2015.0-3-omv2015.0.noarch.rpm
16:56:55 <bero> ./4.0/repository/aarch64/main/release/task-scanning-2015.0-5-omv2015.0.noarch.rpm
16:56:57 <bero> ./4.0/repository/aarch64/main/release/task-scanning-4.0-6-omv4000.noarch.rpm
16:57:02 <bero> So 2015.0-5 really shouldn't be visible to anything that isn't either prehistoric or ARM or RISC-V... No idea where it gets that idea from
16:57:16 <bero> I wonder if it somehow sees aarch64 as a subdirectory and tries to grab noarch packages from there
16:57:21 <bero> but it certainly shouldn't
16:58:28 <ben79> Unless it is still  using a mirror and mirror is not updates:
16:58:34 <ben79> rock-x86_64: using metadata from Wed 19 Jun 2019 07:18:46 AM CDT.
16:58:34 <ben79> repo: downloading from remote: rock-updates-x86_64
16:59:08 <ben79> [rock-updates-x86_64]
16:59:08 <ben79> name="OpenMandriva Rock - x86_64 - Updates"
16:59:08 <ben79> # Master repository:
16:59:08 <ben79> baseurl=http://abf-downloads.openmandriva.org/rock/repository/x86_64/main/updates/
16:59:08 <ben79> gpgcheck=1
16:59:09 <ben79> gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-OpenMandriva
16:59:11 <ben79> enabled=1
16:59:39 <ben79> So I wonder If I'm doing something wrong in trying to disable the mirror use
17:00:05 <ben79> To me that should be using: http://abf-downloads.openmandriva.org/rock/repository/x86_64/main/updates/
17:00:53 <bero> ben79: that looks right
17:01:20 <ben79> I'm baffled, I know I don't know as much as you, but I can't see how this is possible
17:02:09 <ben79> I'm also puzzled by what "downloading from remote" would mean unless it is a mirror?
17:03:47 <ben79> Question: In order to be doing my job thourghly I need to go back and attempt to build the 4000 package and remove the 2015 for all arches and platforms cooker, rolling, and 4.0 right?
17:05:58 <ben79> bero: It is still using mirror: [MIRROR] task-scanning-2015.0-5-omv2015.0.noarch.rpm: Status code: 404 for http://abf-downloads.openmandriva.org/rock/repository/x86_64/main/release/task-scanning-2015.0-5-omv2015.0.noarch.rpm
17:05:58 <ben79> [FAILED] task-scanning-2015.0-5-omv2015.0.noarch.rpm: No more mirrors to try - All mirrors were already tried without success
17:06:33 <ben79> but wait, the package is not there but dnf is still trying to install it, I'm a bit lost
17:07:01 <ben79> metadata?
17:07:21 <bero> Hmm... Probably it's a relic from an old metadata build (when the package was still there) and then only incremental metadata builds that don't clean up after themselves
17:07:54 <bero> There are proper task-scanning packages in 4.0
17:08:06 <bero> but of course with version numbers smaller than 2015.0
17:08:21 <bero> probably the easy fix is to add an epoch to task-scanning and rebuild
17:08:57 <bero> fdrt: Do you know if we have some other way to make sure metadata picks up a seemingly "older" package if the "new" one has been removed ages ago?
17:17:00 <ben79> Apologies off topic during meeting, my passion for a kind of major issue now that we have released over road my manners.
17:17:39 * ben79 And my bad grammar
17:18:46 <itchka> It's an important issue ben79.
17:19:28 <AngryPenguin> poor performance in benchmarks is another issue :/
17:19:44 <AngryPenguin> look at this https://www.phoronix.com/vr.php?view=27979
17:20:02 <itchka> It will be worse if we don't have a sane way to update packages
17:21:08 <itchka> So please lets stick to the point there's nothing we can do about those benchmarks right now.
17:21:16 <ben79> The only problem with updating the package I had was that I had to learn a few more things about ABF
17:22:07 <itchka> How are we going to move forward with this issue with rolling?
17:22:42 <ben79> People that will be using 4.0 long term aren't going to be much concerned with the gee whiz stuff anyway they will want stable and things to "just work"
17:23:42 <ben79> Don't know yet I discovered this in the context of upgrading a ROCK system to then convert to Rolling and see how many packages Rolling will be downgrading
17:24:45 <ben79> Which indicates another different problem because unless I misunderstand going from Rock to Rolling should downgrade any packages but currently it does including kernel-firmware packs
17:25:30 <ben79> Correction: going from Rock to Rolling should Not downgrade any packages
17:25:57 <ben79> If it is then we have some issues, and it is
17:27:16 <ben79> Both issues go to this topic: <rugyada> 5. Maintenance of Rolling: Procedure for QA to manage packages. QA
17:27:47 <ben79> the incorrect package names are everywhere Cooker, Rolling and 4.0
17:27:58 <ben79> and they gotta go
17:32:43 <itchka> Are these the 2015 package names?
17:33:06 <itchka> I'm at a loss to where to go with this....
17:36:34 <ben79> Yes mostly 2015 but there may be some 3000 ones or 'nuns' (nones)
17:37:44 <ben79> fdrt I believe said we need to make a list of them but I have no clues how to list anything in a repository, I know how to make a list of installed packages on a computer  but that's my knowledge limit
17:38:10 <ben79> If some one teaches us how or comes up with a script I'm willing to learn/help
17:38:38 * ben79 I gotta be in and out of the meeting for a while now
17:39:01 <itchka> Ok
17:42:17 <itchka> It sounds to me like our repos are broken and that we have to rebuild all the packages that are incorrectly named which, I suspect, going to be a fairly major task. This is before we even attempt to update anything to new versions.
17:43:45 <itchka> bero: I guess there is no quick fix for this?
17:45:09 <bero> Probably not
17:45:14 <bero> need to see a list of packages
17:45:48 <bero> given we did run a few mass builds and fixed stuff that didn't build that is in any way relevant, I'd almost assume anything that still has a tag < 4000 is obsolete crap and a candidate for removal
17:47:02 <bero> by the way, I've just looked at the benchmarks AngryPenguin posted
17:47:11 <bero> They did something wrong there
17:47:35 <bero> but of course we shouldn't scream too loudly unless we know that their mistake is really the only problem
17:47:39 <bero> Look at this:
17:47:53 <bero> Processor Details- OM Lx 4.0 x86-64: Scaling Governor: acpi-cpufreq conservative- OM Lx 4.0 Znver1: Scaling Governor: acpi-cpufreq conservative- Clear Linux: Scaling Governor: acpi-cpufreq performance- openSUSE Tumbleweed: Scaling Governor: acpi-cpufreq ondemand- Ubuntu 19.04: Scaling Governor: acpi-cpufreq ondemand
17:48:39 <bero> So OM Lx was configured to save power (conservative scaling governor) while Clear Linux was configured to essentially run at highest speed (performance) and OpenSUSE was running at ondemand (which also scales up faster than conservative)
17:48:53 <bero> This is different distros' default settings probably
17:49:10 <bero> but we'd win those tests if they were also considering battery use
17:49:48 <bero> Also Clear Linux has performance CFLAGS and friends in its environment
17:50:03 <bero> (see "Environment Details" in the benchmark setup)
17:50:20 <bero> This is rigged, and not exactly in our favor
17:50:42 <bero> I'll post a comment explaining it without using the word rigged ;)
17:51:08 <bero> actually the article calls it out itself later
17:51:37 <bero> but it's probably why the #1 thing that makes us look bad if people look at the results only (as I did initially)
17:56:41 <itchka> We should ask for a retest with all governers set the same.
17:56:57 <AngryPenguin> bero I saw it too
17:57:57 <AngryPenguin> often such tests appear. One system with performance and other with ondenamed.
17:58:28 <itchka> It's a meaninless test as it is.
17:58:46 <bero> It's meaningful because it's the various distributions' default setting
17:58:59 <bero> but it doesn't compare important things like battery drain after running the tests etc.
17:59:57 * ben79 back for bit
18:01:46 <AngryPenguin> bero: https://www.reddit.com/r/firefox/comments/b7sc9n/the_fastest_linux_distributions_for_web_browsing/eju8frz/?context=3
18:02:31 <AngryPenguin> opensuse with powersave vs clear with intel_pstate performanc
18:02:38 <ben79> FWIW: IMO the task-scanning package itself is not that important, scanning works on default install with skanlite, and *may be a candidate for removal
18:02:56 <ben79> FWIW: But the issue demonstrated is IMO very important
18:03:23 <ben79> I meant task-scanning *may* be candidate for removal
18:04:18 <itchka> #chair bero ben79
18:04:18 <chwido> Current chairs: ben79 bero itchka
18:04:37 <itchka> Got hand over now. BBL
18:04:58 <AngryPenguin> btw. bero feature request - easy to use graphical cpufreq switch from powersave - ondenamed - performance
18:05:00 <AngryPenguin> :D
18:05:12 <bero> AngryPenguin: indeed
18:05:17 <ben79> #chair bero ben79 rugyada
18:05:17 <chwido> Current chairs: ben79 bero itchka rugyada
18:05:29 <bero> AngryPenguin: and maybe use ondemand by default, it seems to be a decent tradeoff for most
18:05:41 * ben79 ben79 has already said he has to be "in and out"
18:07:15 <ben79> bero: AngryPenguin: before we build cpufreq tool maybe we should addres this: # systemctl status cpupower
18:07:18 <ben79> Loaded: loaded (/lib/systemd/system/cpupower.service; disabled; vendor preset: disabled)
18:08:29 <AngryPenguin> bero: good idea
18:08:53 <ben79> it is a good idea but
18:08:54 <AngryPenguin> probably it will not hurt and it can increase performance
18:10:12 <ben79> is it meant to work on tuned.service or?
18:10:26 <ben79> since cpupower is disabled
18:10:34 <bero> Posted a reply
18:10:36 <AngryPenguin> ben79: check available: by command cpupower frequency-info
18:10:46 <bero> We should consider dumping tuned for 4.1
18:10:47 <AngryPenguin> and set it by cpupower frequency-set -g ondemand
18:10:58 <AngryPenguin> or performance
18:11:00 <bero> tuned is a fedoraism that often does more bad than good
18:11:17 <ben79> cpupower in OM Lx 4.0 is disabled by tuned.service
18:11:32 <bero> yes, those 2 don't go together too well
18:11:39 <bero> which is one reason to dump the latter and enable the former
18:12:15 <ben79> I'm all in favor of that which is why I wonder what good a gui tool would do unless we actully start using cpupower
18:14:35 <ben79> cpupower frequency-info = current CPU frequency: Unable to call hardware
18:16:04 <ben79> On my intel boxes cpu freq is set by tuned.service unless I over ride it myself
18:16:33 <AngryPenguin> root
18:16:36 <AngryPenguin> try with root
18:16:45 <ben79> that is root
18:16:49 <AngryPenguin> hmm
18:17:00 <AngryPenguin> for me is everyting ok
18:17:20 <ben79> I have like multiple OM lx 4 hw systems and they are all like this.
18:17:37 <bero> works here (on AMD)
18:18:11 <ben79> Look in /lib/systemd/system/tuned.service >>> Conflicts=cpupower.service
18:18:19 <bero> "systemctl stop tuned"
18:18:23 <ben79> Is TPG here?
18:18:41 <ben79> Woops!
18:19:22 <AngryPenguin> recently, as I was test new mesa in one game, I changed cpufreq to performance and indeed FPS was a bit better
18:19:29 <ben79> This is a Rock system updated this moring
18:20:03 <ben79> bero: I can do that but why do I keep having to do that?
18:20:37 <ben79> Since Lx 3 that I know of.
18:22:10 <bero> "rpm -e tuned"
18:22:11 <ben79> FWIW I know how to get cpupower to work and how to mask tuned my concern is all the other people with Intel CPU's because I have seen myself some issues with tuned
18:23:24 <ben79> I would say tuned should be rpm -e tuned from the repos, but...
18:23:38 <bero> I'd agree about the default setup at least
18:23:44 <bero> but let's do that in cooker and rolling
18:23:54 <bero> no need to mess with 4.0 on this one
18:24:47 <bero> tuned mostly works for 4.0, good enough until we've tested a probably better alternative for 4.1
18:24:58 <ben79> Yes, it's to late for 4.0
18:25:59 <AngryPenguin> bero: https://github.com/jsalatas/plasma-pstate
18:26:03 <AngryPenguin> ^^
18:26:37 <ben79> Anyway if we were actually using cpupower then a gui to set cpu freq is a fantastic idea AngryPenguin
18:30:32 <bero> AngryPenguin: thanks, looks useful
18:31:37 <ben79> bero: And so far for me in Cooker or 4.0 tuned has been working OK, I just do not trust it with Intel CPU's and Intel is all I have
18:44:30 <ben79> #topic Report: ABF, cooker
18:44:52 <ben79> Have we covered this adequately?
18:46:47 <AngryPenguin> cooker currently broken on plasma5
18:47:16 <AngryPenguin> cinnamon is my friend today :)
18:48:11 <ben79> What Not Lumina?
18:49:46 <ben79> bubbawarthog tried to tell people about illumos but no one cared
18:50:35 <bero> Problem is as usual, we're in the middle of a qt update and the problem will fix itself when all packages are built
18:50:43 <AngryPenguin> ben79: lumina is very very poor "in options"
18:50:57 <AngryPenguin> also is based on qt and qt is now in updating phase
18:50:59 <ben79> I've never used it
18:51:06 <AngryPenguin> so it may be broken too
18:51:19 <ben79> in Cooker
18:51:31 <bero> lxqt and lumina are less broken because they don't rely as heavily on plugin functionality
18:51:42 <bero> there's a good chance they're mostly working right now
18:51:54 <ben79> Any way we should be ready for next topic? Or not?
18:51:54 <bero> but either way the fix is on its way
18:53:55 <bero> IMO we're ready... Would be nice to get an update on blocking publishing directly to rolling/release, but fdrt and HisShadow_ don't seem to be around, so that's a topic for another time
19:03:23 <ben79> Here is something that I think relates to topics on today's agenda. In fully updated Rock system switch to Rolling repos and there are 41 downgrades including falkon, glibc, and kernel-firmware >>> I'm thinking this tells us something like our work flow is out of whack or something >>> the list: https://pastebin.com/pRLf4mxY
19:05:07 <ben79> Just food for thought at the moment ^^^
19:05:32 <ben79> #Topic Drop 32-bit packages
19:05:43 <bero> That should definitely not happen
19:06:33 <bero> Everything that goes to rolling must go through cooker and everything that goes to rock must go through rolling
19:06:58 <AngryPenguin> bero because build x86_64 for rolling failed
19:07:03 <AngryPenguin> thats why downgrade
19:07:12 <bero> yes, we need to fix that
19:07:26 <bero> and technically the update for 4.0 shouldn't have been pushed before fixing rolling
19:07:38 <ben79> That is what I thought, I'm not meaning to be complaining but I think we need to look at getting our workflow established
19:07:43 <bero> but it's ok for now, this was just a minor release process hickup
19:07:52 <rugyada> bero:  [17:25] <rugyada> workflow must be cooker > rolling > 4.0 (rock) if any.
19:08:24 <ben79> rugyada: Or Else!
19:08:32 <ben79> :D
19:08:37 <bero> usually yes
19:08:40 <bero> with a few exceptions
19:08:56 <bero> e.g. when cooker is at clang 9.0 we can still push a clang 8.0.2 update or so for rolling/rock
19:09:07 <bero> but that doesn't affect anything we have already
19:09:52 <rugyada> and maybe while at it let's make clear Rock definition:
19:09:58 <rugyada> Rock
19:09:59 <rugyada> This is the stable release tree. It gets only important updates, such as security fixes or fixes for system crashes.
19:10:09 <bero> yes...
19:10:22 <bero> unless people scream enough to make us change the idea, no plasma 5.16 for 4.0
19:10:31 <bero> but a fairly quick 4.1 release
19:10:31 <rugyada> otherwise it's just a rolling copy..
19:10:48 <AngryPenguin> bero we should push new kernels to 4.0 and rolling
19:10:54 <AngryPenguin> for fix this cve
19:11:00 <bero> AngryPenguin: agreed
19:11:12 <ben79> release 4.1 in 6 months or 3?
19:11:27 <ben79> or 6 weeks?
19:12:46 <rugyada> release plan: not 'time' but 'milestones approach'
19:12:51 <ben79> I think we need to get the incorrect pack names/2015 sorted then work towards 4.1
19:13:39 <AngryPenguin> idea - can we release ISOs for rolling for example every month or two?
19:13:49 <AngryPenguin> like arch/manjaro and other rolling?
19:13:57 <ben79> milestones is better approach but only if milestones are spelled out
19:14:10 <AngryPenguin> i see every month news "new manjaro iso release" bla bla bla
19:14:59 <ben79> AngryPenguin: for that we should go to every week IMO
19:15:42 <rugyada> btw we are again offtopic, and I may leave any time since now. So in case a vote is needed and I'm AFK I vote yes to drop 32bit.
19:15:42 <ben79> unless we have to test them,
19:16:55 <ben79> 32bit packages or ISO's? I don't see dropping the packages as realistic, Steam for one example
19:17:31 <AngryPenguin> rugyada: in ideal world yes, in real not yet xD
19:17:58 <AngryPenguin> as ben79 said steam depend on it
19:18:27 <AngryPenguin> well, ubuntu force droping 32bit from next release
19:18:41 <AngryPenguin> but i dont know how they deal with all this mess
19:18:56 <ben79> On a personal level I'
19:19:18 <ben79> On a personal level I'm in favor, but I don't think it is practical for our users
19:19:45 <rugyada> AngryPenguin:  no, in *this* world.
19:19:51 <ben79> I do think we should give up on i686 ISO's
19:20:10 <bero> the idea would be to replace them with building only the libraries we need for wine, steam and friends with -m32 inside the 64bit packages
19:20:21 <bero> the downside of that is that making the spec files do that is manual work
19:20:46 <bero> but the upside is that it eliminates the need of maintaining the whole i686 tree and all
19:21:04 <ben79> If we can do that without biting off more than we can chew, that sounds great, but while I'm still seeing a ton of 2015 packages uh,
19:21:19 <bero> crazy already does something similar in FW
19:21:41 <bero> IMO it's something we should do at some point, but not necessarily now
19:22:08 <AngryPenguin> bero: but how should we know what packages will be needed for someone?
19:22:18 <AngryPenguin> for example steam need mesa 32 and few other libs
19:22:34 <AngryPenguin> steam games in mosty cases use steam-runtime so most of problem is fixed
19:22:40 <bero> ldd is usually helpful
19:22:41 <AngryPenguin> but drm-free games on GOG not
19:22:46 <bero> we know what wine needs
19:22:53 <AngryPenguin> most of gog games is 32bit and what now?
19:23:03 <bero> and of course if in doubt, err on the side of building too many packages
19:23:08 <ben79> I do think is good goal
19:23:50 <ben79> But then I think we should get rid of unusable packages in unsupported repo too
19:24:08 <ben79> in every repo
19:25:28 <bero> agreed, fix them or get rid of them
19:29:31 <ben79> but for now what do we decide about 32-bit packages, ?
19:30:13 <ben79> I like the idea of dropping but not until 4.1 or later release
19:31:06 <rugyada> ben79: almost 2 years ago we decided to drop 32 bit stuff
19:31:18 <rugyada> already too much time passed
19:31:36 <rugyada> it has to be done, and to be done now.
19:31:40 <rugyada> imo
19:32:56 <ben79> My point is we have a tendancy to try to do to much, right now getting rid of incorrect package names and getting workflos working for new release plan have to be highest prioity partly because we went ahead and did the 4,0 release so we really have to do these
19:33:22 <itchka> That's as maybe but we haven't done the work to make that possible.
19:33:36 <ben79> make which possible?
19:34:07 <itchka> Dropping 32bit repos
19:34:36 <ben79> As far as work flow for release plan I don't have a clue what I should be doing and I'm one of the people that is supposed to be doing it
19:35:25 <ben79> itchka: yes not ready for that, but I don't know how much work it would be?
19:37:19 <ben79> My observation is that people here are much less likely to use i686 repos than our users, though that is hard to quantify
19:38:45 <itchka> Downloads of wine32 might give a guide.
19:39:34 <Pharaoh_Atem> bero: there's a concept of multilib repos
19:39:49 <Pharaoh_Atem> we could produce a filter list of packages that when built for x86_64, they also get built for i686
19:40:02 <Pharaoh_Atem> and instead of getting dumped in an i686 repo, they're put in x86_64
19:40:25 <itchka> I think we need to keep wine32 in a functional condition I suspect it is even more useful now than in the past wher people want to run legacy windoes apps in a secure environment.
19:40:29 <Pharaoh_Atem> this is how Fedora and RHEL do this, and lets them avoid having a dependency on a full i686 repo
19:41:00 <Pharaoh_Atem> and ABF is capable of this setup, in part because ROSA does this for their RELS product
19:41:11 <ben79> Wine and Steam are probably the main 2 32 bit, and I use neither I suspect most on this channel don't
19:41:51 <itchka> I use wine32 for some electronic cad and spice applications
19:42:17 <bero> I'm not too fond of that idea because that would result in either continuing to build all the tools that go along with the libraries, or adding a lot of %ifarch bits to make sure only the libraries get built (which is as much work as just building the needed bits with -m32)
19:42:42 <bero> I usually use wine32 for a couple of games when my nephew and niece are around
19:44:40 <ben79> Should we decide something like get rid of 32-bit for certain release and do the -m32 thing for Wine and Steam?
19:45:12 <AngryPenguin> I insist for supporting 32-bit for some time
19:45:17 <ben79> If it's possible I think getting rid of all those packages has to make maintaining the rest easier
19:45:18 <AngryPenguin> we will see in the future how the situation will develop. What other distributions do and we will decide in the future.
19:46:01 <ben79> Ah, Ha, controversy, difference of opinion, I love it, provokes action
19:46:29 <AngryPenguin> ben79: do we care at i686 in building process?
19:46:41 <ben79> or provokes endless argument
19:46:43 <AngryPenguin> I think not. We do not fix errors. build errors too etc.
19:47:19 <ben79> AngryPenguin, usually not, but it would be less load on ABF and we just added a lot of load with new release plan
19:48:02 <AngryPenguin> I'm not convinced. Abandoning 32-bit can cause us problems.
19:48:58 <AngryPenguin> Imagine those users who can't play a GOG game because there is no 32-bit library in OM
19:48:59 <ben79> I would say we can't just drop it all of a sudden it has to be planned, should have been planned before now probably, but wasn't
19:49:39 <ben79> I know, gamers tend to be some of your top notch complainers too
19:49:48 <AngryPenguin> btw. look at this topic https://www.reddit.com/r/linux_gaming/comments/c24gpk/i386_architecture_will_be_dropped_starting_with/
19:50:33 <AngryPenguin> some people are happy that thanks to this, users are go away from Ubuntu to debian
19:51:20 <bero> That's because Brokenbuntu -- as always -- does the weird thing and abandons multiarch
19:51:51 <bero> If in doubt about something, look what Ubuntu does and then do the opposite. You'll usually get it right. ;)
19:51:57 <ben79> Yeah, that is just strange to me...
19:53:28 <ben79> To me dropping support for 32-bit operating system and ISO's makes much sense and I've been saying that for some time
19:53:48 <ben79> But dropping 32 bit packages is a whole  'nuther matter,
19:54:13 <ben79> I'd like to see 'em gone, but I question if it is practical
19:55:06 <ben79> In the past I certainly thought we were talking about dropping support for ISO's and OS
19:55:47 <Izaic[m]> how did the meeting go?
19:56:06 <Izaic[m]> QT fixed yet?
19:56:08 <ben79> molasses, like most meetings in most organizations
19:56:29 <Izaic[m]> i saw earlier towards two you guys said it wasn't... so im guessing it isn't yet
19:57:01 <ben79> You do not that every developer here has a day job right?
19:57:01 <Izaic[m]> ben79: Someone was beating his head on his desk? The other was obnoxiously chewing gum? And bero was trying to be the serious boss? Right?
19:57:13 <bero> Izaic[m]: meeting and Qt builds both still going on
19:57:22 <Izaic[m]> oh
19:57:32 <Izaic[m]> ben79: Yes, but i also know you have different timezones
19:57:46 <ben79> well there is that
19:57:57 <Izaic[m]> And it has been prophesized that bero is a openmandriva god who spends 24/7 compiling and building
19:58:25 <bero> I actually don't exist, I'm just the next version of the chwido bot
19:58:40 <Izaic[m]> right. the more useful one.
19:59:07 <ben79> the end of the world has been prophesied  multiple times as well
19:59:48 <AngryPenguin> bero: btw. look what needed gog games
19:59:52 <AngryPenguin> for example https://www.gog.com/game/shadowrun_dragonfall_directors_cut
19:59:57 <AngryPenguin> look at system req
20:00:14 <Izaic[m]> I'm holding off on updating till QT is fixed... That way i dont bork my system again... i had to rescue it from a iso backup i made
20:00:56 <AngryPenguin> Izaic[m] you should swich to stable 4.0 or rolling
20:01:09 <Izaic[m]> It wont have KDE 5.16 :P AngryPenguin
20:01:13 <ben79> AngryPenguin:Works on Ubuntu what else is there?
20:01:16 <Izaic[m]> Plus i'm doing testing for ya on Znver
20:01:39 <AngryPenguin> ben79: requires 32-bit libs
20:01:54 <ben79> I know, lots of games do
20:02:48 <bero> Izaic[m]: rolling will have KDE 5.16, just 4.0 won't
20:03:09 <ben79> lots are 32 bit only ,  game engineers smoking dope haven't caught up to 64 bit
20:03:15 <Izaic[m]> Ah, so as soon as it's working it will be pushed? bero
20:03:35 <bero> that's the idea
20:03:41 <AngryPenguin> ben79: in some cases this is not that simple
20:03:50 <bero> cooker gets it, it gets fixed there, then it's copied to rolling
20:04:16 <Izaic[m]> bero:  Speaking of rolling, wine is missing other libraries... even if i delete the 64 bit version of spirv-tools, it still errors ... https://forum.openmandriva.org/t/unable-to-install-wine32-and-wine64-together-nor-can-i-install-just-wine32/2837
20:04:18 <bero> well, it is that simple -- game devs usually have a "no need to switch to anything newer as long as the old stuff works"
20:04:30 <bero> remember DOS games still coming out when the rest of the world had moved on to other OSes?
20:05:03 <ben79> Izaic[m]: the point is this: If you use Cooker there are times when it will be broken, we guarantee that, Rolling we hope to keep in working state of course.
20:08:03 <Izaic[m]> ben79: Oh nice. Is it ready yet however?
20:08:14 <Izaic[m]> And can i downgrade? By default the LX4 Znver ISO has cooker as the respositories
20:08:18 <ben79> OK, back to the 32-bit packages are we going to dicide something?
20:08:49 <ben79> You used the wrong ISO. latest ISO's use Rock by default
20:09:06 <Izaic[m]> Wrong iso?
20:09:14 <Izaic[m]> It was the one from the 16th
20:09:42 <ben79> https://sourceforge.net/projects/openmandriva/files/release/4.0/
20:09:52 <Izaic[m]> ben79: https://sourceforge.net/projects/openmandriva/files/release/4.0/OpenMandrivaLx.4.0-plasma.znver1.iso/download
20:09:57 <Izaic[m]> This one
20:10:26 <ben79> Or there is a bug in znver1 ISO , Or I don't understand something
20:10:46 <ben79> but x86_64 uses Rock now I'm sure of that
20:11:16 <bero> I haven't reinstalled my znver1 boxes, but I'm sure the iso has been built from the 4.0 tree
20:11:16 <Izaic[m]> Probably bugged. bero Said it might need to be fixed, and so i double checked it, and it is indeed using cooker by default
20:11:42 <ben79> bero: Is this a bug ^^^ ?
20:11:57 <ben79> Oh, did not see your answer
20:12:07 * ben79 Doh!
20:12:28 <Izaic[m]> The release uses 5.1.9-desktop-1omv4000 kernel
20:12:33 <bero> I haven't checked yet and can't download the iso until I'm back home (metered connection right now), will take a look when I get home (probably Monday)
20:12:42 <bero> kernel version looks right
20:12:44 <Izaic[m]> I assume that's what cooker had at the time?
20:13:10 <ben79> it is also what 4.0 had
20:13:37 * Izaic[m] uploaded an image: image.png (390KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/smaNvYKqyuITSJzPbJHMuexj >
20:13:43 <Izaic[m]> I haven't updated or switched repos.
20:13:44 <Izaic[m]> (QT is broken, so i can't update without borking)
20:14:18 <ben79> Oh, I believe and was giving you credit for knowing what you are doing also
20:14:20 * Izaic[m] uploaded an image: image.png (103KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/NzKxbTsIfYozlaxdPREEOUyp >
20:15:25 <ben79> try cat /etc/release
20:15:39 <ben79> cooker I believe is 4.0.1 now?
20:15:46 <bero> That screenshot also shows a lot of repositories enabled that shouldn't be enabled by default
20:15:55 <bero> The default should be only Main enabled
20:16:05 <ben79> and rock or stable will show 4.0
20:16:08 <Izaic[m]> OpenMandriva Lx release 4.0.1 (Nitrogen) for znver1
20:16:21 <Izaic[m]> I enabled the other repositories to try and get wine32 installed bero
20:16:32 <bero> maybe repo-picker messed up parsing the configs and saving the changes also moved to cooker
20:19:02 <Izaic[m]> Speaking of configs... How is Dnfdragora-updater configured to startup on boot? I would like to replace it with discover's update notifier
20:19:31 <Izaic[m]> I expected a entry in the plasma autostart menu, but i guess not
20:20:41 <ben79> Are we going to decide something on 32-bit packages?
20:21:09 <Izaic[m]> ben79: What do you mean?
20:21:22 <Izaic[m]> Dropping them?
20:21:55 <ben79> Topic currently under discussion: 2. Drop 32-bit packages
20:22:14 <Izaic[m]> What about Wine32?
20:22:21 <Izaic[m]> It's essential for alot of software still... wintricks requires it too.
20:22:25 <Izaic[m]> winetricks*
20:22:36 <AngryPenguin> bero ben79 my vote is for keep supporitng 32-bit for some time and then decide about it in future (after 4.1 release or later)
20:22:49 <bero> Izaic[m]: wine32 and libraries needed by it or steam definitely won't be dropped
20:23:00 <Izaic[m]> I'm sure there's other instances of 32 libraries being used still
20:23:07 <ben79> I thouht when I saw that packages was a misprint, I thought we'd been talking about dropping support for 32-bit operating system/ISO's
20:23:08 <Izaic[m]> Ah okay bero
20:23:19 <Izaic[m]> Then i don't see an issue if the essential 32 bit ones aren't dropped.
20:23:53 <bero> ben79: well, in the long run I'd like to stop building stuff like libreoffice on i686 because it keeps breaking and it isn't worth fixing if nobody uses i686 boxes
20:23:53 <ben79> well there are a lot of games that require 32 bit packages aren't there?
20:24:04 <Izaic[m]> bero: Will winetricks be added also? I noticed it's absent in cooker
20:24:05 <bero> nothing to do with compat packages though
20:24:13 <bero> I'm pretty sure it's there or at least was there at some point
20:24:17 <Izaic[m]> Cooker + Znver
20:24:54 <ben79> bero:I'm fine with what you suggest about Wine and Steam and -m32
20:25:32 <ben79> but I think this is to big of a move to not plan it for acertain release and announce before we actully do it
20:25:43 <bero> Given fixing the library packages to build -m32 versions will take some time anyway and we currently have other things to do, I'm ok with holding off on it for now...
20:25:56 <Izaic[m]> I doubt more than 3 people use 32 bit anymore.
20:26:20 <bero> But we should get ready to do it the next time i686 is causing pains again
20:26:41 <bero> and maybe agree that it's not a blocker if e.g. libreoffice isn't available on i686
20:26:42 <AngryPenguin> samba?
20:26:59 <Izaic[m]> Yeah. The mess of libraries especially. Can't install wine properly.
20:27:24 <bero> AngryPenguin: That's one of the pain points right now, but we probably have to fix that anyway given some parts of wine may need samba libraries
20:27:28 <ben79> So is this fair #action We will move towards supporting a few like wine and steam with -m32 and otherwise drop like a hot potato 32-bit packages for a future release perhaps 4.1?
20:27:49 <Izaic[m]> Yes.
20:28:00 <Izaic[m]> Less cruft to deal with. Less maintence.
20:28:17 <ben79> and #action we can of course add some more -m32 stuff if users demand is enough to warrant doing so?
20:28:28 <bero> Maybe we can start phasing it out while still keeping it around a bit longer...
20:28:31 <bero> I'd propose:
20:28:35 <Izaic[m]> Speaking of steam, cooker at least is missing a library... Let me pull it up real quick.. bero
20:28:40 <AngryPenguin> I would postpone the discussion about it after 4.1
20:28:56 <bero> 1. After the 4.0 release, no more STABLE releases of i686 trees
20:29:18 <bero> 2. Keep building i686 for now, but make it cooker and rolling only
20:29:33 <bero> (that should at least save us from having to backport stuff there)
20:29:57 <bero> 3. At some point in the future, but not before 4.1, move towards building library versions with -m32
20:30:00 <Izaic[m]> Sounds good
20:30:04 <bero> is that ok with everyone?
20:30:11 <Pharaoh_Atem> I think we should move that target to 5.0
20:30:22 <ben79> On this issue I'm inclined strongly to go with bero's suggestion
20:30:44 <Pharaoh_Atem> doing it on a 4.x release is confusing and not helpful
20:31:01 <Pharaoh_Atem> especially for users who expect stuff in the same version series to remain compatible
20:31:05 <Izaic[m]> Why not do a forum poll and see how many users are still actively using 32 bit?
20:31:42 <Izaic[m]> Pharaoh_Atem: And to be fair, things break from point releases to point releases all the time. The users should always expect a update to change/break stuff imo.
20:31:42 <ben79> As far as OS we already know almost all 32-bit ISO's are installed on 32-bit hw
20:31:44 <bero> We did that before, turns out everyone who doesn't contribute at all voted to keep 32 bit but nobody actually uses it ;)
20:32:05 <Pharaoh_Atem> Izaic[m]: it *shouldn't* though
20:32:09 <Izaic[m]> Haha
20:32:17 <ben79> CORRECTION: As far as OS we already know almost all 32-bit ISO's are installed on 64-bit hw
20:32:42 <Izaic[m]> I think enough fair warning should be fine
20:33:00 <ben79> We have zero testers commonly using 32-bit hw
20:33:08 <bero> and we'll keep rolling and cooker for i686 for now, so it's not like people have to move to something else
20:33:21 <Izaic[m]> I have 32 bit arm systems... that's it
20:33:38 <ben79> Well that's different
20:34:01 <Izaic[m]> Yeah
20:34:09 <bero> armv7hnl probably has to stay for now
20:34:18 <bero> and we may even add riscv32 at some point
20:34:37 <bero> this is just about 32 bit x86 systems
20:34:48 <ben79> #Action 1. After the 4.0 release, no more STABLE releases of i686 trees
20:34:57 <ben79> Are we OK with this?
20:35:03 <Izaic[m]> I don't see a reason to even support riscv yet... considering a grand total of around 2 people probably have hardware capable of doing anything.
20:35:05 <bero> AFAIK nobody has been building 32bit x86 processors for years
20:35:14 <Izaic[m]> Yes.
20:35:26 <ben79> #Action 2. Keep building i686 for now, but make it cooker and rolling only
20:35:28 <bero> even low-end Atoms have been x86_64 for some years
20:36:17 <ben79> #Action 3. At some point in the future, but not before 4.1 probably not until 5.0, move towards building library versions with -m32
20:36:27 <fdrt> hello
20:36:41 <bero> riscv is interesting because it's a fully open architecture, especially with stuff like the Huawei export bans it may soon be the only viable thing in some parts of the world -- even if only few people have the hardware right now
20:36:53 <Izaic[m]> Even MS is trying to drop 32 bit mostly
20:36:55 <ben79> Note: I added  probably not until 5.0 >>> if any #Actions are not OK please speak up
20:36:59 <fdrt> i made an auto_updater for cooker, it's working in a way like bero's kde-tools but written in python
20:37:35 <bero> fdrt: nice!
20:37:41 <ben79> Note: I want to move this meeting but I don't want to be doing things we don't have agreement on
20:39:00 <ben79> Izaic[m]: There are rumors that Linux will take over the PC Desktop/Laptop market in the next 2-5 years and M$ will be who does it.
20:39:20 <Izaic[m]> bero: Got the error from steam: "error while loading shared libraries: libatomic.so.1: wrong ELF class: ELFCLASS32
20:39:21 <Izaic[m]> Game removed: AppID 231430 "", ProcID 25053 "
20:40:04 <ben79> I did not say reliable rumors, I read in  publication about Economics not computers
20:40:39 <AngryPenguin> Izaic[m] company of heroes2?
20:40:44 <Izaic[m]> I heard of that too. It's possible. Although i also heard microsoft is working on a modern NT kernel without legacy support...
20:40:53 <Izaic[m]> Yes. AngryPenguin
20:40:57 <AngryPenguin> wrong elf mean wrong lib architectures
20:41:14 <AngryPenguin> guess
20:41:20 <ben79> Frankly you hear all kinds of stuff...
20:41:34 <Izaic[m]> Which means something is wrong with the library on Znver1
20:41:51 <ben79> bero: are you OK with #Actions?
20:42:28 <bero> It's quite likely M$ doesn't put all its eggs in one basket. I wouldn't be surprised if they were working on both a modern NT kernel and a Windows UI on top of a Linux kernel
20:42:48 <bero> ben79: sure, if everyone else is -- those #Actions are essentially my proposal...
20:42:53 <Izaic[m]> So Znver1 library issues: libatomic.so.1 .... spirv-tools-2019.1-1.i686 and spirv-tools-2019.1-1.znver1 .... libvkd3d.so.1
20:43:06 <Izaic[m]> But i presume what i report should be taken with a grain of salt atm, because i'm using a outdated OMLX4
20:43:36 <ben79> Anyone not OK with those actions?
20:44:03 <bero> libatomic looks like it's a 32-bit version where a 64-bit version is being looked for... probably a messup somewhere else (the system wouldn't boot if there wasn't a 64-bit libatomic)
20:44:07 <bero> I'm fixing spirv-tools
20:44:26 <ben79> >>> # > Action OpenMandriva to switch to Hurd kernel
20:44:38 <ben79> OK with that?
20:44:49 <Izaic[m]> Yes.
20:44:50 <ben79> It's almost ready
20:44:53 <Izaic[m]> :P
20:45:14 <itchka> Those actions Ben
20:45:28 <ben79> Yes
20:45:32 <Izaic[m]> Lol
20:45:41 <Izaic[m]> Switch it over to Linux Zen
20:46:06 <Izaic[m]> Then just create a virtual machine layer to run hurd on top of...
20:46:23 <Izaic[m]> GNU/Hurd OpenMandriva
20:46:34 <bero> why hurd? Why not FreeDOS?
20:46:59 <Izaic[m]> FreeDOS is overrated, duh
20:47:02 <bero> at least FreeDOS is a proven technology... ;)
20:47:34 <Izaic[m]> We should really go for OS/2
20:47:43 <Izaic[m]> It's been in use for years in the new york subway
20:48:01 <AngryPenguin> openmandriva follows the footsteps of ubuntu xD
20:48:03 <AngryPenguin> lol
20:48:04 <Izaic[m]> I mean, Commondore Basic would work too, no?
20:48:09 <AngryPenguin> i have better idea
20:48:17 <AngryPenguin> for 5.0 release, we should drop rpm package
20:48:18 <Izaic[m]> OpenMandriva becomes ubuntu
20:48:25 <AngryPenguin> and switch to deb
20:48:33 <AngryPenguin> and change name to openUbuntu
20:48:34 <AngryPenguin> xD
20:49:20 <Izaic[m]> Drop RPM, Switch to APT, get rid of zen optimizations... Get rid of a layer of compiler opts... Add a openmandriva security team.... Change the name to debian... and downgrade all software so that it's a year old with security patches.
20:50:10 <Izaic[m]> And then remove plasma, add cinnamon, and rename to Mandriva Mint
20:51:23 <bero> FreeDOS, 10 year old Debian packages, where's the difference? ;)
20:52:48 <ben79> OK so done with that topic? Obviously.
20:53:04 <ben79> I propose we discuss this: 5. Maintenance of Rolling: Procedure for QA to manage packages. QA
20:53:13 <bero> yes, works for me...
20:53:16 <ben79> and table the other topics until next week
20:53:32 <ben79> #Topic 5. Maintenance of Rolling: Procedure for QA to manage packages. QA
20:54:00 <Izaic[m]> QA: Send the ISO to me, let me test, i say it gud, you say it gud, we all say it gud. Done.
20:54:10 <Izaic[m]> Dun*
20:55:02 <Izaic[m]> Just muk sare thot u have plasma 5.16 un rolling release
20:55:16 * Pharaoh_Atem sighs
20:56:10 <ben79> You *may* need to be little more patient about getting the latest packages. I even takes Ubuntu some time to rebuild and test stuff.
20:56:35 <Izaic[m]> Ubuntu is too slow
20:56:58 <ben79> Maintenance of Rolling: Procedure for QA to manage packages.
20:57:13 <Izaic[m]> If it's gonna take 6 months to update rolling, i'll have to just shoot my computer :D
20:57:25 <bero> So, from the developer side, the idea is to build stuff in cooker first, and when it is thought to be sane (e.g. not waiting for another set of rebuilds), copy to rolling/testing
20:57:28 <ben79> I'll start this with I believe I get the concept but specifically I don't know what to do
20:58:05 <bero> I've added a script to do that to the kde-packaging-tools tree (which we should probably rename to packaging-tools at some point, it has been useful for stuff outside of updating kde for ages)
20:58:08 <bero> https://github.com/OpenMandrivaSoftware/kde-packaging-tools/blob/master/cooker2rolling
20:58:16 <Izaic[m]> I really hope this QT rebuild fixes everything i can use 5.16 finally... And then once it's determined sane downgrade to rolling
20:59:11 <bero> as long as developers use that script or something similar, we won't get dumps directly into rolling/release (only to rolling/testing, where they should be going) even before ABF has a way to really block builds in rolling/release
20:59:43 <bero> From there, QA should take it, install the packages, test, and then move the packages from rolling/testing to rolling/release
20:59:50 <Izaic[m]> Testing?
21:00:06 <bero> AFAIK Kahinah is still useful for that, but the idea was to merge the functionality into ABF
21:00:07 <ben79> bero: So, I suspect what I need to learn won't be that much, just how to move packages from testing to rolling and then to 4.0 updates?
21:00:11 <itchka> Bet you as soon as a new systemd comes along we won't find it in testing!!!
21:00:28 <Izaic[m]> Ah, i didn't even notice that testing switch... How does the testing repos differ?
21:00:41 <itchka> It HAS to be enforced
21:01:02 <bero> Xu_R: fdrt: HisShadow_: Do you have any update on the Kahinah merge?
21:01:22 <ben79> Enforce it by giving only certain people privilages at certain steps, that would stop that
21:02:15 <Izaic[m]> Did you guys hear they are adding a debug system to systemd?
21:02:22 <bero> itchka: agreed, nobody should be pushing directly to rolling/release (except to fix up prior messups that cause it to break the build environment or so, of course)
21:02:29 <fdrt> bero there is something complicated
21:02:36 <Izaic[m]> I found that extremely interesting.
21:02:38 <itchka> I don't think permissions in ABF ar ethat fine grained.
21:02:46 <fdrt> i think tht need to implement it in ABF
21:03:06 <bero> ben79: So, I suspect what I need to learn won't be that much, just how to move packages from testing to rolling and then to 4.0 updates? -- Kahinah or its successor for rolling/testing to rolling/release -- and most stuff should simply not go to 4.0 updates
21:03:40 <lcomedeiros[m]> <fdrt "i think tht need to implement it"> Hélio All OMA.
21:03:40 <bero> that's the whole point of creating the rolling tree, we shouldn't throw updates at 4.0 that a lot of people won't want, but at the same time we don't want to force people who want faster updates on cooker
21:04:05 <ben79> Right we need to be clear on QA side about what does not/does go to 4.0
21:04:34 <lcomedeiros[m]> Hello All OMA.
21:04:46 <ben79> basically bug fixes and security updates only
21:05:17 <ben79> Hello, lcomedeiros[m]
21:05:37 <ben79> as I understand
21:05:57 <ben79> In other works what you see today in 4.0 is what you get.
21:06:50 <ben79> As far as package versions, not sure everyone gets that yet
21:07:35 <AngryPenguin> bero: 17:29 Xu_R I'm just going to leave this here because I know there will be questions about it (since bero asked me to look at putting push to testing functionality into abf) and i have meetings today: things I did previously: lots of work/real life/personal issues
21:07:45 <AngryPenguin> things I'm looking at this week: activating old kahinah to 4.0 while I refresh myself on how abf works, alongside $day_job
21:07:52 <AngryPenguin> please ping me if there's something urgently i need to consider or if we suddenly want to change how we serve repos, thanks
21:08:00 <AngryPenguin> * end of transmission
21:08:36 <bero> IMO we need to be flexible there -- if a package version update fixes a bug that has been annoying people on 4.0, we can push an update, but mostly feature updates (like maybe KDE 5.16.1) probably shiouldn't go to 4.0 updates
21:08:54 * ben79 AngryPenguin: Thanks so much for remembering that, I didn't
21:09:49 <ben79> That makes perfect sense but then we'll have to communicate...
21:10:47 <AngryPenguin> bero: we can push to 4.0 some drivers updates, mesa + kernel
21:10:51 <Pharaoh_Atem> bero: ideally, we can actually have update advisories produced now
21:11:04 <Pharaoh_Atem> so that it provides the information people need to know about this
21:11:13 <Pharaoh_Atem> security vs bugfix vs enhancement, etc.
21:11:28 <bero> Pharaoh_Atem: Agreed if we can get people to actually do it
21:12:06 <bero> AngryPenguin: In some cases yes, but I'd rather not risk pushing e.g. a mesa update that improves things for most but unexpectedly breaks things badly for people using some uncommon hardware
21:12:11 <Pharaoh_Atem> if it could be part of the ABF workflow (HisShadow_, fdrt?) for suggesting updates to push out for rock or rolling, then that'd be awesome
21:12:14 <itchka> Can't you just use the commit messages?
21:12:45 <Pharaoh_Atem> I don't know if you've noticed, but people put garbage in the commit messages ever since we stopped generating changelogs
21:12:53 <fdrt> where is kaninah  ?
21:12:59 <Izaic[m]> bero: But feature updates particularly in KDE fix alot of bugs
21:12:59 <bero> Probably people who want serious updates there should use rolling
21:13:04 <Izaic[m]> Plasma 5.16 for example has a ton of bug fixes
21:13:08 <itchka> I try not too.
21:13:22 <Izaic[m]> Particularly in the compositor
21:13:40 <Pharaoh_Atem> itchka: a lot of people do things like "fix" as just the commit message
21:13:43 <AngryPenguin> fdrt: https://kahinah.rxu.tech/
21:13:44 <ben79> fdrt: https://kahinah.rxu.tech/builds/testing
21:13:45 <Pharaoh_Atem> with huge changes
21:14:26 <Pharaoh_Atem> bero: ABF has the ability to generate updateinfo from advisories filled out in ABF itself
21:14:28 <itchka> Pharaoh_Atem: Disappointing
21:14:52 <Pharaoh_Atem> itchka: yeah, I know, the messages got sloppy after autogeneration of rpm changelogs from git was disabled
21:16:06 <bero> IMO autogeneration of rpm changelogs from git should be enabled so people can see what happened... But of course that also means people need to stop using commit messages like "Fix" or "Update blah.spec"
21:17:02 <Pharaoh_Atem> yeah
21:17:07 <Pharaoh_Atem> I agree completely
21:17:23 <ben79> What should be in commit messages? Exactly what you changed or?
21:17:37 <ben79> why you changed?
21:17:53 <Pharaoh_Atem> but one of the reasons why I'd like to see advisories in OMV is that only Linux distributions that provide updateinfo information in their rpm-md metadata are allowed to be used at work
21:17:54 <bero> ben79: short summary of what was done and when it isn't obvious, why it was done...
21:18:07 <Pharaoh_Atem> and my workplace isn't the only one like that
21:18:10 <lcomedeiros[m]> @ben79 Thanks for the explanations.
21:18:10 <ben79> OK, not rocket science
21:18:12 <bero> Can be something short like "5.16.1" when e.g. updating plasma-desktop from 5.15.4 to 5.16.1
21:18:26 <bero> or "Fix https://issues.openmandriva.org/show_bug.cgi?id=123456"
21:19:03 <bero> or in a more complicated case, "Disable LTO optimizations because they caused a crash while doing xyz on abc hardware"
21:19:05 <Pharaoh_Atem> well, you can use "Fix omvbz#123456" instead ;)
21:19:44 <bero> My #1 hated commits are "Disable [insert optimization here]" or "Use different compiler" without giving any reason
21:20:03 <bero> because those are guaranteed to be reverted at some point if the reason isn't documented
21:20:11 <itchka> Pharaoh_Atem: is 'dnf provides Xrandr.h' enough to find out which package provides the file. It doesn't seem to work for me...
21:20:49 <itchka> bero: I will bear  in min No 1#
21:20:57 <itchka> min=mind
21:21:14 <bero> preferably such things should be documented right where the optimization is disabled or the compiler is switched
21:21:15 <Pharaoh_Atem> itchka: "dnf provides '*/Xrandr.h'",
21:21:52 <itchka> Pharaoh_Atem: Ok that explains it :)
21:22:24 <itchka> and it makes sense thinking about it.
21:24:47 <ashledombos[m]> Anyone with twitter account able to help? https://twitter.com/carlosigls/status/1141397775894102016
21:25:27 * bero doesn't have a twitter account
21:25:40 <bero> also no idea what went wrong there
21:25:45 <itchka> nor itchka
21:25:49 <bero> obviously the repositories are working
21:26:04 <bero> need way more details...
21:26:40 <Pharaoh_Atem> bero: I suspect it's related to the omv2015 and omv3001 packages
21:26:49 <Pharaoh_Atem> they cause rpm and dnf to break in bad ways
21:28:11 <bero> Only if they're installed... So far I've only seen junk packages that usually wouldn't be installed anywhere with ancient disttags
21:28:38 <Pharaoh_Atem> the distepoch makes dnf think they're higher than the ones without them
21:28:49 <Pharaoh_Atem> when they have the same EVR otherwise
21:28:55 <Pharaoh_Atem> even though distepoch is invalid
21:37:10 <ben79> bero: So moving packages from rolling/testing to rolling will be done with Kahinah or something similar, but the tool does not exist yet?
21:37:58 <bero> ben79: Kahinah should be usable for this as soon as someone adds the rolling tree into it
21:38:11 <bero> There's nothing special about rolling, so adding it the same way 4.0 was added will work
21:39:39 <ben79> OK, we will then upon occasion move package from rolling to 4.0 with Kahinah for bug and security fixes and special circumstances
21:39:43 <ben79> so that is that
21:40:23 <ben79> so I do know how to do that just the tool isn't ready yet.
21:43:44 <bero> Primarily it's about moving from rolling/testing to rolling/release
21:43:48 <bero> not so much rolling to 4.0
21:43:56 <bero> rolling to 4.0 will require a rebuild at least
21:44:09 <bero> because rolling will sooner or later have newer libraries with different sonames
21:53:21 <ben79> bero: OK, then really not so hard.
21:57:46 <AngryPenguin> itchka: i dont see nv drivers for 4.0
21:57:51 <AngryPenguin> only for cooker
21:58:50 <ben79> bero: no one will be install task-scanning anymore, it's gone, just need to get the meta data to like the task-scanning-4.0-7 omv4000 package
21:58:55 <itchka> How odd let me try again perhaps the target reset itself when I pressed recreate build list.
21:59:21 <AngryPenguin> itchka: ok
21:59:26 <ben79> I meant no one will be install task-scanning 2015, no one will be installing that
21:59:39 <AngryPenguin> when build end I ping redding people about nvidia drivers
21:59:43 <AngryPenguin> they asking about it
21:59:48 <itchka> AngryPenguin: Running should there soon
21:59:55 <AngryPenguin> ok, thanks
22:04:17 <ben79> Still using dkms?
22:05:18 <itchka> Yes
22:05:29 <ben79> itchka: probably ought to build that for rolling too
22:06:29 <itchka> Building
22:06:54 <itchka> I can't test it 'cus my kits too old.
22:07:18 <ben79> Also in 4.0 for me builds don't publish automatically you have to manually publish everything
22:08:13 <itchka> It's non-free it doesn't seem to have that restriction.
22:09:54 <AngryPenguin> we forgot about p"3. 4.1 release plan, workflow, milestones"
22:10:01 <bero> It does seem to have that restriction as well -- e.g. 561398 is "Build complete" and not "Build has been published"
22:10:20 <AngryPenguin> or I miss something?
22:13:55 <ben79> AngryPenguin: <ben79> I propose we discuss this: 5. Maintenance of Rolling: Procedure for QA to manage packages. QA
22:13:55 <ben79> <bero> yes, works for me...
22:13:55 <ben79> <ben79>  and table the other topics until next week
22:14:19 <itchka> bero: That's what you get for going by the colour:) I'll publish it
22:14:58 <itchka> That is assuming we treat non-free like unsupported
22:15:17 <bero> sure
22:15:27 <bero> IMO non-free is even more unsupported than unsupported
22:15:35 <bero> because we typically can't fix it even if we want to
22:15:37 <ben79> For AIB I would say for everyone to continue to be aware of new release and help any users with issues otherwise we should focus on getting rid of misnamed packages 2015/3000 ect
22:15:56 <itchka> bero: I'm not sure there's a word for that :)
22:16:26 <bero> There is, and that word is "Microsoft" ;)
22:16:56 <itchka> or perhaps nVidia:))
22:17:37 <itchka> I do have one thing for AOB
22:17:53 <itchka> It's about the nVidia drivers.
22:18:29 <itchka> and the second on is about vlc
22:18:54 <Izaic[m]> What was the trick to using a .spec file for installing libraries automatically?
22:19:13 <Izaic[m]> I don't remember the parameters for dnf
22:19:30 <itchka> sudo dnf builddep *.spec
22:19:52 <ben79> #Topic 6. AIB
22:19:53 <Izaic[m]> Thank you!
22:20:02 <ben79> Been there done that one.
22:20:15 <itchka> ben79: I have found out why the flatpack vlc works.
22:20:23 <ben79> #Topic 7. AOB
22:20:48 <itchka> Ok nVidia drivers.
22:20:54 <AngryPenguin> itchka?
22:21:00 <AngryPenguin> why
22:21:28 <ben79> itchka: Was not meaning to interrupt if I did
22:22:44 <itchka> AngryPenguin: It appears to use libEGL instead of presumably libGL
22:24:15 <itchka> Our version must have something missing from it because it does not detect it's presence (libEGL) so it doesn't use it
22:26:30 <itchka> There are CFLAGS variables in the configure help which seem to allow you to point configure at the libEGL headers maybe we need to set those. I'll provide some logs a bit later to show you.
22:28:34 <AngryPenguin> ok
22:29:01 <fdrt> https://www.phoronix.com/scan.php?page=article&item=omlx-znver1-linux&num=1
22:29:08 <itchka> With regard to nVidia: There are currently two ways of installing the nVidia drivers. There is the legacy version and there is the GLVND version most of the libraries can be parallel installed with the exception of two libs which are mutually exclusive (they have the same names but different functionality)
22:32:10 <itchka> I am considering a second rpm which contains the glvnd install but I'm wondering what the policy for packaging something like this is. Do I produce two small packages each with the different pairs of libs and one larger package which contains all the support stuff or do I do it some other way?
22:32:17 <fdrt> bero https://www.phoronix.com/scan.php?page=article&item=omlx-znver1-linux&num=1
22:33:40 <fdrt> The Znver1-optimized OpenMandriva Lx 4.0 build can offer some slight performance benefits over the generic x86-64 version, but as shown by these benchmarks, the likes of Ubuntu, Clear Linux, and openSUSE were a great deal faster. OpenMandriva was the only Linux distribution assembled using LLVM Clang rather than GCC, it strangely still defaults to using the conservative CPUFreq configuration, and other differences from the higher profile (and faster)
22:33:42 <fdrt> Linux distributions.
22:48:51 <ben79> Wonder if we should have put nvidia-current in testing repos? Just to get in the habit?
22:49:40 <ben79> But make no mistake I appreciate the heck out of Colin taking the time to do these, a heck of a lot
22:50:14 <ben79> prolly no big deal at this time anyway
22:51:11 <itchka> ben79: I think as we said non-free is even more unsupported than supported :)
22:51:35 <itchka> I'm sorry I'll read that again
22:51:49 <itchka> ben79: I think as we said non-free is even more unsupported than un#supported :)
22:52:21 <bero> fdrt: I've already added a comment on that Phoronix article explaining where they're comparing stuff that shouldn't be compared... It's on the 2nd or 3rd page of comments
22:52:26 <ben79> just that we put packages out without testing maybe they should for rolling and 4.0 go to testing repos
22:52:54 <ben79> After all the times you and I have complained about TPG doing this...
22:53:36 <AngryPenguin> ben79 and do you or other QA people have hardware to test it in testing?
22:53:42 <AngryPenguin> if not then this no make sense
22:53:44 <ben79> but I see the humor
22:53:58 <ben79> No but users can test these
22:54:28 <ben79> I'm just saying if we start making exceptions on the we will be run over by certain developer
22:55:26 <ben79> This has ben a huge, bigger than huge problem in the past
22:56:19 <ben79> So if y'all want to make exceptions go ahead but I think we will regret this base on past behavior
22:57:24 <itchka> By that argument ben79 stuff pushed to unsupported should also be tested.
22:58:42 <bero> Of course ideally it would actually be tested
22:58:54 <bero> but realitically with the current number of contributors I don't see that happening
22:58:56 <itchka> It's a hard one; maybe we should reaname the repo non-free-totally-unsupported!
22:59:04 <bero> better to focus our efforts where they help most -- which is main
22:59:39 <fdrt> yes i see bero
23:02:31 <itchka> AngryPenguin: Take a look here my ramplings were a bit wrong as it looks like it's the code that's testing whether the libs exist that seems to be failing. The flatpak build decides that stuff is not working and tries something different whereas the Om testing code breaks on the first detection attempt. https://pastebin.com/bHM1Fbfg
23:02:31 <ben79> I just think it is a big mistake to start putting untested packages anywhere but testing repo. Just my opinion apparently. But we know very well we have a dev that is challenged about this.
23:03:14 <ben79> Make a 1 cm exception and some people will take that to a km
23:04:02 <ben79> Ofc, I am very red flagged about exactly this issue for long experience with Lx 3
23:05:52 <itchka> Just for your peace of mind Ben I'll put nvidia-long-lived in testing. Hopefully them you'll get some sleep tonight :)
23:07:31 <ben79> I was not so much meaning to dig on this specific instance, these specific but just saying in general we need to get in the habit. Or we will regret it.
23:08:28 <ben79> I will be barking like a chihuahua anytime I see untested packages going directly to rolling/release or 4.0, you can all count on that going forward.
23:09:04 <ben79> testing repos are for testing, this ain't rocket science
23:10:16 <ben79> chwido bark chihuahua
23:10:17 * chwido barks at chihuahua in minor chords.
23:10:44 <ben79> chwido rollover
23:11:44 <ben79> itchka: I'm fine with things as they are if you want to leave it, just saying about going forward
23:12:08 <ben79> itchka: And you know why the issue gets under my skin...
23:12:52 <itchka> I do indeed Ben; I do indeed!
23:14:57 <itchka> This must be the longest meeting on record! It's gone midnight here!
23:15:12 <itchka> Time to call it a day i think.
23:15:29 <ben79> I can close if you want to leave itchka
23:15:43 <ben79> and get some much needed sleep
23:17:10 <itchka> I should I have to prepare for going away again on Friday. I'm competing in a scything event on Sunday.
23:17:34 <Izaic[m]> lol
23:17:41 <Izaic[m]> dedication
23:18:15 <itchka> More like addiction :)
23:18:54 <ben79> So on that unless any one has Any Other Business in next 5 min, I will close this meeting and the topic either not resolved or not discussed  will go to new weeks meeting
23:21:12 <bero> One OB: closing the meeting ;)
23:21:31 <ben79> OK
23:22:03 <bero> Actually one real OB, given most people here are also council members... We need to find a time for the council meeting, so far nobody has said anything
23:22:13 <bero> Looks like we have a lot of stuff piling up there
23:22:40 <bero> So please, those who are on the council, let us know what a good time would be for you
23:23:18 * ben79 I was going to #Action Untested packages go from Cooker to Rolling/testing repo, and if warranted from Rolling/release to 4.0/testing repo (know this, learn this, believe this, use this)
23:23:37 <ben79> +1 to what bero says
23:24:16 <ben79> I'm more time flexible for Council meeting than most especially a one time meeting
23:24:21 <bero> ben79: yes, good idea. Btw, gawk 5.0.1 is waiting in rolling/testing
23:24:40 <ben79> #Action Untested packages go from Cooker to Rolling/testing repo, and if warranted from Rolling/release to 4.0/testing repo (know this, learn this, believe this, use this)
23:24:57 <bero> fdrt: Package lib64Qt5QuickControls2_5-5.13.0-1-omv4000.znver1.rpm is not signed
23:24:57 <bero> Package qt5-qtquickcontrols2-5.13.0-1-omv4000.znver1.rpm is not signed
23:24:57 <bero> The downloaded packages were saved in cache until the next successful transaction.
23:24:58 <bero> You can remove cached packages by executing 'dnf clean packages'.
23:24:59 <bero> Error: GPG check FAILED
23:25:09 <ben79> So I need to get a Rolling system so I can check packages...
23:25:11 <bero> Somehow abf seems to skip signing every now and then
23:25:15 <ben79> was going to do today
23:25:40 <bero> right now it is safe to distro-sync between 4.0 and rolling both ways
23:25:48 <bero> probably not for much longer
23:25:59 <bero> for cooker it's already risky because of libarchive
23:26:59 <ben79> bero: there are package in 4.0 main/testing but they look old like copied form somewhere all at one time
23:27:15 <bero> let's kill them
23:27:28 <bero> probably the result of cp -a cooker 4.0 when 4.0 was created
23:28:12 <bero> the only thing that I'm aware of that should be in 4.0 main/testing right now is kernel-release 5.1.12 with the CVE fixes
23:28:16 <ben79> yeah same for rolling/main/testing except for gawk
23:28:36 <bero> I've thrown some more stuff there already
23:28:38 <bero> but not a lot
23:28:43 <bero> spirv-* bits
23:29:09 <ben79> don't see kernel pack in 4.0/main/testing
23:30:35 <ben79> can we close now?
23:32:00 <AngryPenguin> dont see because it is not published
23:32:20 <bero> Let's close -- time for me to get to bed as well...
23:32:25 <bero> Kood night!
23:32:33 <AngryPenguin> night
23:33:14 <ben79> #End meeting
23:33:22 <ben79> #Endmeeting