Need ROME users for package testing

ROME is the rolling release published by the OpenMandriva Association. ROME is designed for individual users and will have more up to date software. Codename ROME.

We need people that use ROME for package testing and for voting to move packages from rolling/testing repos to rolling/release repos.

This is described in more detail here.

1 Like

Note: While ROME has not been officially announced yet it is in great shape and in extensive testing has proved to be as stable as our Rock release. Internally we are treating ROME as product ready for users. At this time we are doing a testing or “shaking out” period for our system of maintaining ROME as a rolling release.

Here I’m. Tomorrow i will enable them.


Uhm… I’ll try it tomorrow on my pc test (Acer Aspire 5755). I’m having trouble with video card on it…

1 Like

Hi, update of 27/9/22:

 Package             Arch     Version            Repository                Size
 kernel-desktop      x86_64   5.19.11-2          rolling-testing-x86_64   147 M
 cpupower            x86_64   6.0.0-0.rc7.1      rolling-testing-x86_64    69 k
 cups-filters        x86_64   1.28.16-8          rolling-testing-x86_64   598 k
 dbus-common         noarch   1.14.2-1           rolling-testing-x86_64    12 k
 dbus-tools          x86_64   1.14.2-1           rolling-testing-x86_64    44 k
 dbus-x11            x86_64   1.14.2-1           rolling-testing-x86_64    23 k
 fontconfig          x86_64   2.14.0-1           rolling-testing-x86_64   136 k
 kernel-rc-headers   x86_64   1:6.0.0-0.rc7.1    rolling-testing-x86_64   1.4 M
 lib64bpf1           x86_64   6.0.0-0.rc7.1      rolling-testing-x86_64   160 k
 lib64cupsfilters1   x86_64   1.28.16-8          rolling-testing-x86_64    95 k
 lib64dbus-1_3       x86_64   1.14.2-1           rolling-testing-x86_64   137 k
 lib64expat1         x86_64   2.4.9-1            rolling-testing-x86_64    84 k
 lib64fontconfig1    x86_64   2.14.0-1           rolling-testing-x86_64   163 k
 lib64fontembed1     x86_64   1.28.16-8          rolling-testing-x86_64    29 k
 lib64xft2           x86_64   2.3.6-1            rolling-testing-x86_64    45 k
 xfsprogs            x86_64   5.19.0-1           rolling-testing-x86_64   940 k
Installazione dipendenze:
 lib64qpdf           x86_64   11.1.0-1           rolling-testing-x86_64   684 k
Rimozione in corso:
 kernel-desktop      x86_64   5.18.13-1          @cooker-x86_64           154 M

After this update the image from plymouth has disappeared.
When turned off, the image is displayed.

The system starts and works correctly.


I re-launched:

sudo update-grub2

and everything came back ok

1 Like

kernel-rc-headers ??

1 Like

There was a recent issue with gawk that caused the Plymouth bootsplash not to appear at bootup, this originally required a downgrade of gawk. Once downgraded, we had to run the command to set the Plymouth bootsplash theme again with -R at the end, then it came back. No issues here since.

1 Like

Update to 09/29/2022 for me everything is ok

 Package                   Arch   Version          Repository              Size
 curl                      x86_64 7.85.0-1         rolling-testing-x86_64 181 k
 google-chrome-stable      x86_64 106.0.5249.61-1  google-chrome           88 M
 lib64Quotient0            x86_64 0.7.0-0.20220928.1
                                                   rolling-testing-x86_64 527 k
 lib64freebl3              x86_64 1:3.83-1         rolling-testing-x86_64 484 k
 lib64netfilter_conntrack3 x86_64 1.0.9-1          rolling-testing-x86_64  43 k
 lib64nss3                 x86_64 1:3.83-1         rolling-testing-x86_64 786 k
 lib64nss_myhostname2      x86_64 251.20220811-4   rolling-testing-x86_64  51 k
 lib64nss_resolve2         x86_64 251.20220811-4   rolling-testing-x86_64  69 k
 lib64nss_systemd2         x86_64 251.20220811-4   rolling-testing-x86_64 146 k
 lib64systemd0             x86_64 251.20220811-4   rolling-testing-x86_64 327 k
 lib64udev1                x86_64 251.20220811-4   rolling-testing-x86_64  78 k
 lib64xxf86vm1             x86_64 1.1.5-1          rolling-testing-x86_64  14 k
 neochat                   x86_64 22.09-1          rolling-testing-x86_64 583 k
 nss                       x86_64 1:3.83-1         rolling-testing-x86_64 583 k
 nss-shlibsign             x86_64 1:3.83-1         rolling-testing-x86_64  18 k
 plasma-wayland-protocols  noarch 1.9.0-1          rolling-testing-x86_64  40 k
 systemd                   x86_64 251.20220811-4   rolling-testing-x86_64 3.2 M
 systemd-analyze           x86_64 251.20220811-4   rolling-testing-x86_64  83 k
 systemd-bash-completion   x86_64 251.20220811-4   rolling-testing-x86_64  25 k
 systemd-console           x86_64 251.20220811-4   rolling-testing-x86_64  18 k
 systemd-coredump          x86_64 251.20220811-4   rolling-testing-x86_64  44 k
 systemd-cryptsetup        x86_64 251.20220811-4   rolling-testing-x86_64  68 k
 systemd-homed             x86_64 251.20220811-4   rolling-testing-x86_64 349 k
 systemd-hwdb              x86_64 251.20220811-4   rolling-testing-x86_64 2.4 M
 systemd-locale            x86_64 251.20220811-4   rolling-testing-x86_64 135 k
 systemd-oom               x86_64 251.20220811-4   rolling-testing-x86_64  34 k
 systemd-polkit            x86_64 251.20220811-4   rolling-testing-x86_64  10 k
 systemd-rpm-macros        x86_64 251.20220811-4   rolling-testing-x86_64 9.6 k
Installazione dipendenze:
 lib64curl                 x86_64 7.85.0-1         rolling-testing-x86_64 255 k
     sostituisce  lib64curl4.x86_64 7.84.0-3

A post was split to a new topic: ROME upgrade to Plasma 5.25.90 unusable

A post was merged into an existing topic: ROME upgrade to Plasma 5.25.90 wayland becomes unusable

Thanks for the reports folks. But that was not the purpose of me starting this thread.

What is needed and what the first post in this thread was about was getting people testing and voting on packages in Kahinah. This is described in more detail here

Posting about technical problems in this forum is probably the slowest and least efficient way to get such problems addressed by someone that can actually help. Bug reports or contacting contributor group at OpenMandriva Cooker matrix channel are the way to get results.

Apologies if it sounds like I am lectureing but getting people to vote on packages in Kahinah has been a very frustrating situation. What keeps happening is moving or not moving packages out of testing repos keeps getting left to one or two people. Most packages are moved simply because they have been in testing repo and Kahinah for 7 days. Even thought I am the person who usually does this I really, really, do not like it.

OpenMandriva Linux is a Community distribution of Linux. It requires people in the community to actually do things for the distro to function at it’s best.

1 Like

Could someone kindly explain why Kahinah (once connecting to it via GitHub) requests full access to the user’s GitHub account? Thank you.

1 Like

I am not very knowledgeable about the authentication of login on websites. I just do it when I have to.

All I know is that Kahinah used your GH account to login. In other words it uses GH to authenticate users for login. I do not know if GH has different levels of such things. Not something I would ever have thought of. I would think you either are using GH or you are not. But that may not be correct.

The person to ask would be Robert Xu or Xu_R on the OpenMandriva Cooker channel. He is not there all the time though. He wrote that software. It is currently maintained by @Colin aka itchka in Cooker channel. He also has been an infrequent visitor lately. Usually if you ping one of both of them they do answer when they are next around.

The screen that came up for me, included Robert’s name as creator, but it wanted full-access to the account, which I am not willing to provide.

I am however, willing to continue using rolling-testing in a VirtualBox, but will not vote on packages.

Kahinah uses your GH account to login. You are the only person I have ever heard complain about this.

Again asking about this in this forum is a waste of your time. You need to ask Robert. (Maybe a PM to @robxu9?)

From my perspective I do not understand your concern. How could GH log you in to Kahinah without access to your GH account? It seems you don’t trust Kahinah or the people using it.

I think am starting to understand a bit better what you mean. Does GH need write and execute permissions for user in Kahinah? It would seem that it should not need that. But I don’t know enough about how this works to say. As I understand it an ordinary user in Kahinah is strictly using Kahinah and doing things with in that context.

However someone with admin privileges in Kahinah, like me, is issuing commands from Kahinah to ABF an entirely separate entity. It probably does need such access for someone with admin privileges in Kahinah to be able to issue commands to ABF. But I am speculating, don’t know this for sure at all.

One might guess this was set up the way it is for convenience and simplicity. Remembering this was done in early days of creation of OpenMandriva and that as a group we have all been learning as we go.

I would post the screenshot, except that it contains personal information, but it implies that I would be giving the site owner full access to personal user data, if authorized - which I will not do.

I’ve been mentioned! I do still see emails come through, I just have limited time :frowning:

I’m happy to explain what we do here. When you login to Github, we request that we see the email address associated with your Github account. These are for two reasons. One, so that we know your email. The user database was built off a previous authentication system and hasn’t been updated since when we moved it to using Github auth. Two, so that package maintainers can override the systems after 7 days if nobody has voted, if their email was associated with the package update.

All the code is open source. We particularly request the Github user scope, because when I tried to request a narrowed down scope, I had difficulty getting the email address for some reason. But this was 3 years ago at least now.

I would like to find time to narrow the scope down again to just either read:user and/or user:email, but I’d also like to find time to rewrite Kahinah into something that wasn’t written way long ago, and I don’t particularly have time at the moment. I’ll take an action item to look into reducing the scope of permissions again, but please at least be reassured that we are only using your email and nothing else. Since I request the user scope, Github considers that full access to personal user data.

Also, contributions welcome.

Edit: I’ve updated the Github app description to let you know that the application only wants your email address. I’ve also attempted to lower the scope - doesn’t seem to have totally exploded this time. Ping me if that doesn’t work.

1 Like

Thank you for the clarification.

2 posts were split to a new topic: Problem with something regarding rolling-testing