Can't install hw-probe on OpenSuSE 15.4
I want to install an run hw-probe on my OpenSuSE 15.4 system and ran into troubles. So I am in need of a guru to help me. Here is what I dod and the responses I got - quasar:/etc/X11 # zypper addrepo https://download.opensuse.org/repositories/hardware/openSUSE_Leap_15.4/ hardware Adding repository 'hardware' ....................................................................[done] Repository 'hardware' successfully added URI : https://download.opensuse.org/repositories/hardware/openSUSE_Leap_15.4/ Enabled : Yes GPG Check : Yes Autorefresh : No Priority : 99 (default priority) Repository priorities are without effect. All enabled repositories share the same priority. quasar:/etc/X11 # zypper install hw-probe Error building the cache: [hardware|https://download.opensuse.org/repositories/hardware/openSUSE_Leap_15.4/] Valid metadata not found at specified URL History: - [hardware|https://download.opensuse.org/repositories/hardware/openSUSE_Leap_15.4/] Repository type can't be determined. Warning: Skipping repository 'hardware' because of the above error. Retrieving repository 'snappy' metadata ........................................................[error] Repository 'snappy' is invalid. [snappy|https://download.opensuse.org/repositories/system:/snappy/openSUSE_Leap_15.4] Valid metadata not found at specified URL History: - [snappy|https://download.opensuse.org/repositories/system:/snappy/openSUSE_Leap_15.4] Repository type can't be determined. Please check if the URIs defined for this repository are pointing to a valid repository. Warning: Skipping repository 'snappy' because of the above error. Some of the repositories have not been refreshed because of an error. Loading repository data... Warning: Repository 'Update repository of openSUSE Backports' metadata expired since 2024-02-05 05:25:26 PST. Warning: Repository 'Update Repository (Non-Oss)' metadata expired since 2024-04-30 04:05:04 PDT. Warning: Repository metadata expired: Check if 'autorefresh' is turned on (zypper lr), otherwise manually refresh the repository (zypper ref). If this does not solve the issue, it could be that you are using a broken mirror or the server has actually discontinued to support the repository. Reading installed packages... 'hw-probe' not found in package names. Trying capabilities. No provider of 'hw-probe' found. Resolving package dependencies... Nothing to do. quasar:/etc/X11 # zypper lr Repository priorities are without effect. All enabled repositories share the same priority. # | Alias | Name | Enabled | GPG Check | Refresh ---+---------------------------------------+------------------------------------------------------------+---------+-----------+-------- 1 | download.nvidia.com-$releasever | nVidia Graphics Drivers | Yes | (r ) Yes | Yes 2 | ftp.gwdg.de-openSUSE_Leap_$releasever | Packman Repository | Yes | (r ) Yes | Yes 3 | hardware | hardware | Yes | ( p) Yes | No 4 | openSUSE-Leap-15.4-1 | openSUSE-Leap-15.4-1 | No | ---- | ---- 5 | repo-backports-debug-update | Update repository of openSUSE Backports (Debug) | No | ---- | ---- 6 | repo-backports-update | Update repository of openSUSE Backports | Yes | (r ) Yes | Yes 7 | repo-debug | Debug Repository | No | ---- | ---- 8 | repo-debug-non-oss | Debug Repository (Non-OSS) | No | ---- | ---- 9 | repo-debug-update | Update Repository (Debug) | No | ---- | ---- 10 | repo-debug-update-non-oss | Update Repository (Debug, Non-OSS) | No | ---- | ---- 11 | repo-non-oss | Non-OSS Repository | Yes | (r ) Yes | Yes 12 | repo-oss | Main Repository | Yes | (r ) Yes | Yes 13 | repo-sle-debug-update | Update repository with updates from SUSE Linux Enterpris-> | No | ---- | ---- 14 | repo-sle-update | Update repository with updates from SUSE Linux Enterpris-> | Yes | (r ) Yes | Yes 15 | repo-source | Source Repository | No | ---- | ---- 16 | repo-update | Main Update Repository | Yes | (r ) Yes | Yes 17 | repo-update-non-oss | Update Repository (Non-Oss) | Yes | (r ) Yes | Yes 18 | snappy | snappy | Yes | (r ) Yes | Yes quasar:/etc/X11 # zypper ref Repository 'nVidia Graphics Drivers' is up to date. Repository 'Packman Repository' is up to date. Retrieving repository 'hardware' metadata ......................................................................................[error] Repository 'hardware' is invalid. [hardware|https://download.opensuse.org/repositories/hardware/openSUSE_Leap_15.4/] Valid metadata not found at specified URL History: - [hardware|https://download.opensuse.org/repositories/hardware/openSUSE_Leap_15.4/] Repository type can't be determined. Please check if the URIs defined for this repository are pointing to a valid repository. Skipping repository 'hardware' because of the above error. Repository 'Update repository of openSUSE Backports' is up to date. Repository 'Non-OSS Repository' is up to date. Repository 'Main Repository' is up to date. Repository 'Update repository with updates from SUSE Linux Enterprise 15' is up to date. Repository 'Main Update Repository' is up to date. Repository 'Update Repository (Non-Oss)' is up to date. Retrieving repository 'snappy' metadata ........................................................................................[error] Repository 'snappy' is invalid. [snappy|https://download.opensuse.org/repositories/system:/snappy/openSUSE_Leap_15.4] Valid metadata not found at specified URL History: - [snappy|https://download.opensuse.org/repositories/system:/snappy/openSUSE_Leap_15.4] Repository type can't be determined. Please check if the URIs defined for this repository are pointing to a valid repository. Skipping repository 'snappy' because of the above error. Some of the repositories have not been refreshed because of an error. Marc.... --
Hello, On 2024-08-08 21:00, Marc Chamberlin via openSUSE Users wrote:
I want to install an run hw-probe on my OpenSuSE 15.4 system and ran into troubles
openSUSE Leap 15.4 is EOL, and consequently the hardware project remove it as a build target. openSUSE Leap 15.4 shipped without hw-probe, so if you need it you would have to upgrade. The current release is openSUSE Leap 15.6. Andreas
On 8/8/24 12:10, Andreas Stieger via openSUSE Users wrote:
Hello,
On 2024-08-08 21:00, Marc Chamberlin via openSUSE Users wrote:
I want to install an run hw-probe on my OpenSuSE 15.4 system and ran into troubles
openSUSE Leap 15.4 is EOL, and consequently the hardware project remove it as a build target.
openSUSE Leap 15.4 shipped without hw-probe, so if you need it you would have to upgrade. The current release is openSUSE Leap 15.6.
Andreas
Hmm Why couldn't the hardware project just leave the hardware repository "as is" at EOL so that us slow to upgrade folks could continue to use and retrieve software from it? According to github hw-probe was in the OpenSuSE 15.4 hardware repository - https://github.com/linuxhw/hw-probe/blob/master/INSTALL.md#install-on-opensu... It seems harsh to actually dump the ability to use a repository just because the associated version of OpenSuSE went to EOL. In this day and age, I can't believe disk storage space is a problem! So what gives? Why break something that was working? Seems like this is a poor policy decision. The repository should just be frozen, no further updates or fixes added, but let it continue to work and be available. Marc... -- "The Truth is out there" - Spooky _ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (This email is digitally signed and the OpenPGP electronic signature is added as an attachment. If you know how, you can use my public key to prove this email indeed came from me and has not been modified in transit. My public key, which can be used for sending encrypted email to me also, can be found at - https://keys.openpgp.org/search?q=marc@marcchamberlin.com or just ask me for it and I will send it to you as an attachment. If you don't understand all this geek speak, no worries, just ignore this explanation and ignore the OpenPGP signature key attached to this email (it will look like gibberish if you open it) and/or ask me to explain it further if you like.)
Marc Chamberlin composed on 2024-08-08 13:04 (UTC-0700):
Hmm Why couldn't the hardware project just leave the hardware repository "as is" at EOL so that us slow to upgrade folks could continue to use and retrieve software from it?
Mirror space consumption? Not all packages can only be installed in releases for which they were built. Were you to fetch the rpm for 15.5, you might find it to be installable. Some rpms I have installed in various Leap installations were built several years ago, and not necessarily for openSUSE. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2024-08-08 22:04, Marc Chamberlin via openSUSE Users wrote:
Hmm Why couldn't the hardware project just leave the hardware repository "as is" at EOL so that us slow to upgrade folks could continue to use and retrieve software from it? According to github hw-probe was in the OpenSuSE 15.4 hardware repository -
https://github.com/linuxhw/hw-probe/blob/master/INSTALL.md#install-on-opensu...
It seems harsh to actually dump the ability to use a repository just because the associated version of OpenSuSE went to EOL. In this day and age, I can't believe disk storage space is a problem! So what gives? Why break something that was working? Seems like this is a poor policy decision. The repository should just be frozen, no further updates or fixes added, but let it continue to work and be available.
Ah actually found it: https://build.opensuse.org/request/show/1176822 So looks like I pushed for it to be deleted, as it should be. Obviously not speaking for the hardware project but: Using EOL software is irresponsible and a general security concern: CWE-1104, CWE-1395, OWASP A06:2012. A lack of forwarded-looking upgrade planning for long predictable dates does not mean that it will be there forever. Nothing broke because it never worked: The risk was taken when a dependency outside of the user's control was taken. Additionally maintaining old things would cause significant load on the finite OBS resource. Your idea of archiving is acknowledged, if it is needed it may exist. It does not right now, indicating that this is a fringe request for which there is a better option: Plan to upgrade in time and execute. For myself I am happy with the archived distro itself, which is why I put things I need into the distro. From https://en.opensuse.org/Lifetime, which I believe I wrote when I was involved in the openSUSE Maintenance team: Discontinued distributions<https://en.opensuse.org/Lifetime#Discontinued_distributions> Users running a (soon-to-be) discontinued version of openSUSE should upgrade <https://en.opensuse.org/SDB:System_upgrade> their systems to a supported release to receive security updates <https://en.opensuse.org/Portal:Maintenance> and community support <https://en.opensuse.org/openSUSE:Communication_channels>. Since eventually package repositories <https://en.opensuse.org/Package_repositories> for discontinued releases are removed from download servers <https://en.opensuse.org/openSUSE:Mirrors> as well as the build target list of the Build Service <https://en.opensuse.org/Portal:Build_Service>, it will be increasingly difficult to install new software on such distributions. cya, Andreas
On 2024-08-08 23:11, Andreas Stieger via openSUSE Users wrote:
On 2024-08-08 22:04, Marc Chamberlin via openSUSE Users wrote:
Hmm Why couldn't the hardware project just leave the hardware repository "as is" at EOL so that us slow to upgrade folks could continue to use and retrieve software from it? According to github hw-probe was in the OpenSuSE 15.4 hardware repository -
https://github.com/linuxhw/hw-probe/blob/master/INSTALL.md#install-on-opensu...
It seems harsh to actually dump the ability to use a repository just because the associated version of OpenSuSE went to EOL. In this day and age, I can't believe disk storage space is a problem! So what gives? Why break something that was working? Seems like this is a poor policy decision. The repository should just be frozen, no further updates or fixes added, but let it continue to work and be available.
Ah actually found it: https://build.opensuse.org/request/show/1176822 So looks like I pushed for it to be deleted, as it should be.
Obviously not speaking for the hardware project but: Using EOL software is irresponsible and a general security concern: CWE-1104, CWE-1395, OWASP A06:2012. A lack of forwarded-looking upgrade planning for long predictable dates does not mean that it will be there forever. Nothing broke because it never worked: The risk was taken when a dependency outside of the user's control was taken.
Additionally maintaining old things would cause significant load on the finite OBS resource. Your idea of archiving is acknowledged, if it is needed it may exist. It does not right now, indicating that this is a fringe request for which there is a better option: Plan to upgrade in time and execute. For myself I am happy with the archived distro itself, which is why I put things I need into the distro.
There is no request to maintain old things, but to not delete them, to just freeze and leave an archive, out of the mirror structure perhaps. No resources from the OBS. And about irresponsibility, me for instance have old distros in "decommissioned" computers, like the old laptop that I only use to see movies in front of the static exercise bike. It serves no purpose to update it. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 2024-08-09 13:32, Carlos E. R. wrote:
There is no request to maintain old things, but to not delete them, to just freeze and leave an archive, out of the mirror structure perhaps. No resources from the OBS.
That is work. If you need it, do it.
And about irresponsibility, me for instance have old distros in "decommissioned" computers, like the old laptop that I only use to see movies in front of the static exercise bike. It serves no purpose to update it.
And this example invalidates my point.. how exactly? Andreas
On 8/9/24 04:48, Andreas Stieger via openSUSE Users wrote:
On 2024-08-09 13:32, Carlos E. R. wrote:
There is no request to maintain old things, but to not delete them, to just freeze and leave an archive, out of the mirror structure perhaps. No resources from the OBS.
That is work. If you need it, do it.
Do tell? What ongoing work is needed to maintain an archive? How much work is involved to make a snapshot and archive a repository? Doesn't seem like it should involve a lot of work by someone who groks SuSE's repositories. Your suggestion "If you need it, do it" is crass and impracticable for us simple users. I imagine it would be a steep learning curve to understand the whole repository architecture, design, software, and testing procedures, let alone get qualified to make changes to the repository structures! What would take an expert a few minutes to accomplish would take me days/weeks to do.
And about irresponsibility, me for instance have old distros in "decommissioned" computers, like the old laptop that I only use to see movies in front of the static exercise bike. It serves no purpose to update it.
And this example invalidates my point.. how exactly?
I have systems, like Carlos, that are in a working state, but also are remote and difficult to access. These systems are basically robots, doing the same thing and supporting services that don't really need to be changed. They work, as is, and simply don't need to be changed very much! Upgrading them involves a high risk of breakage, trying to adapt software, configurations, etc to new/changed interfaces, deprecated and removed software, etc. I could write a book about all the "breakages" and the time it takes to grok and integrate new software interfaces and configurations, after doing an upgrade to a new release. Keeping backwards compatibility doesn't seem to be a requirement of OpenSuSE releases anymore. You are also implying that keeping downtime to a minimum, while doing an upgrade, is no longer a priority of the OpenSuSE development and maintenance teams either. So your "point" is invalidated by the necessity of keeping a system in a running state, often referred to as the "If it ain't broke, don't fix it" mantra. Yes there may be security fixes and other flaws in an older version of OpenSuSE, but these facts may be outweighed by other concerns/issues. IMHO your argument, to force users to upgrade, whenever a new release of OpenSuSE comes out, does a big disservice to users who simply can't keep up. Now I got to worry about even older OpenSuSE systems I support, will I be even able to upgrade them when intermediate repositories are being abandon, or not archived? Also, I have a system, my laptop, that I simply can't upgrade. Attempting to upgrade breaks and the newer version of OpenSuSE will not install properly or in a runable state. I don't have the knowledge to try an fix the problem myself, and others can't help because they do not experience the failure I am having. So what am I suppose to do when I can't upgrade? BTW, I do understand the risks of not being able to ask for support on older versions of OpenSuSE, that's fair and I accept it. But to handicap users, by removal of older repositories, and access to stuff in them, IMHO is NOT a fair way to treat users. Especially if it doesn't/shouldn't involve a lot of extra work just to archive a repository, as is, when the release is deprecated. I think it is fair to ask, if a tool was available for an older version of OpenSuSE, it should remain available for that older version, in some kind of archive/repo until perhaps storage space is overwhelmed. Marc...
Andreas
On 8/9/24 10:48, Marc Chamberlin via openSUSE Users wrote:
On 8/9/24 04:48, Andreas Stieger via openSUSE Users wrote:
On 2024-08-09 13:32, Carlos E. R. wrote:
There is no request to maintain old things, but to not delete them, to just freeze and leave an archive, out of the mirror structure perhaps. No resources from the OBS.
That is work. If you need it, do it.
Do tell? What ongoing work is needed to maintain an archive? How much work is involved to make a snapshot and archive a repository? Doesn't seem like it should involve a lot of work by someone who groks SuSE's repositories. Your suggestion "If you need it, do it" is crass and impracticable for us simple users. I imagine it would be a steep learning curve to understand the whole repository architecture, design, software, and testing procedures, let alone get qualified to make changes to the repository structures! What would take an expert a few minutes to accomplish would take me days/weeks to do.
This was a topic a few months ago. I've got to maintain a local image of many of the openSUSE repos for servicing an insular network. I've got a fairly easy way to do it using Redhat's yum program. I'll collect my notes and processes and post them here in a bit. But this would be for local use with distribution via NFS, making your repo available to the public would be another matter. Regards, Lew
On 8/9/24 11:08, Lew Wolfgang wrote:
That is work. If you need it, do it. Do tell? What ongoing work is needed to maintain an archive? How much work is involved to make a snapshot and archive a repository? Doesn't seem like it should involve a lot of work by someone who groks SuSE's repositories. Your suggestion "If you need it, do it" is crass and impracticable for us simple users. I imagine it would be a steep learning curve to understand the whole repository architecture, design, software, and testing procedures, let alone get qualified to make changes to the repository structures! What would take an expert a few minutes to accomplish would take me days/weeks to do.
This was a topic a few months ago. I've got to maintain a local image of many of the openSUSE repos for servicing an insular network. I've got a fairly easy way to do it using Redhat's yum program. I'll collect my notes and processes and post them here in a bit.
Here's how I downloaded openSUSE repositories. I'm sure this isn't the only way to do this, but I had a restriction in that I couldn't use rsync to download deltas. Once the repos were on a local machine I sneaker-netted the deltas into an isolated network where they were distributed on an insular subnet by NFS. First, download the dnf utilities: zypper in dnf-utils Then, create the root directory for your local repos: mkdir /data/repos (for example) Now, make the local repo using the URI that "zypper lr -U" reports: (using backports as an example) yum-config-manager --add-repo=http://download.opensuse.org/update/leap/15.5/backports/ (for example) cd to your local repo root: cd /data/repos Now list your local repo. It will be different than the one you downloaded, spaces replaced with underlines. dnf repolist Finally, the outside repository can be downloaded to the local. Plug in the repository you listed in the dnf repolist command reposync --repoid=download.opensuse.org_update_leap_15.5_backports_ --download-metadata --download-path=./ The first time reposync is run it will download the entire indicated repository. Subsequent runs will download only the changes from the last time it was run. This allows one to have a complete up-to-date local repo that can be kept around permanently if desired. Repeat for the rest of the repositories you want to keep. The series of reposyncs could be put into a shell script and run regularly if the remote repos are still being maintained. Note that rsync is probably better at doing this, but my system is behind a firewall that doesn't allow outgoing rsync connections. Go figure. They allow outgoing ports 80 and 443, but not port 873. Regards, Lew
It's not like the fundamentals of your request haven't been discussed for as long as software had a lifetime. Occasionally this results in enterprise products. You are free to run your machines openSUSE machines in any way you like. But I am also free to point out that it is a bad decision to depend on an OBS devel project repositories that are known to not have an archive, where did remove them repeatedly, and said so usually long in advance.
IMHO your argument, to force users to upgrade, whenever a new release of OpenSuSE comes out, does a big disservice to users who simply can't keep up.
Nobody is forcing you to upgrade or do anything. But that does not imply that anyone else has to do anything for you. Your system is still working fine. Just hw-info is not available for a new installation, a change you attempted to do. As for keeping up, may I point out to the comfortable release cadence, and the 8 months that have passed since 15.4 is EOL and the one year that has passed since the successor release 15.5 is available.
Now I got to worry about even older OpenSuSE systems I support, will I be even able to upgrade them when intermediate repositories are being abandon, or not archived?
You, should not rely on development repository builds to remain available in perpetuity. hw-probe is part of openSUSE Leap 15.5 and 15.6 and is maintained there. You should report any bugs that prevent you from upgrading.
So what am I suppose to do when I can't upgrade?
You could engage a local expert, possibly in a LUG. And of course our fabulous community that will get you to a maintained release. Andreas
On 2024-08-09 20:32, Andreas Stieger via openSUSE Users wrote:
It's not like the fundamentals of your request haven't been discussed for as long as software had a lifetime. Occasionally this results in enterprise products.
You are free to run your machines openSUSE machines in any way you like. But I am also free to point out that it is a bad decision to depend on an OBS devel project repositories that are known to not have an archive, where did remove them repeatedly, and said so usually long in advance.
Nobody is suggesting to keep old files in OBS.
You, should not rely on development repository builds to remain available in perpetuity. hw-probe is part of openSUSE Leap 15.5 and 15.6 and is maintained there. You should report any bugs that prevent you from upgrading.
I seem to recall having reported a bug on hw-probe years ago, it crashed.
So what am I suppose to do when I can't upgrade?
You could engage a local expert, possibly in a LUG. And of course our fabulous community that will get you to a maintained release.
Andreas
Recently someone posted about a machine that can not be upgraded to 15.6 because the media will not boot. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 2024-08-10 19:06, Carlos E. R. wrote:
Nobody is suggesting to keep old files in OBS.
And I did not say it was. Just that the status quo is deletion some time after the EOL date. In this case, 8 months. The request to have an archive for OBS published repositories is understandable, but a waste of time.
I seem to recall having reported a bug on hw-probe years ago, it crashed.
Link?
Recently someone posted about a machine that can not be upgraded to 15.6 because the media will not boot.
Link? Andreas
On 8/10/24 10:17, Andreas Stieger via openSUSE Users wrote:
Recently someone posted about a machine that can not be upgraded to 15.6 because the media will not boot.
Link?
That was posted by Franz Polster on July 31. Message body follows: I am still working with Leap 15.4 and tried to install Leap 15.6. Following the standard procedure (on July 29) I burnt the Offline-image with k3b and started the installation with option "Installation". The installation process stopped at the message "[ end Kernal Panic - not syncing: Attempted to kill init! exit code=0x00000004 ]", with the CAPS-lock LED flashing! The same happened today (July 31), with a second (different) download of the Offline-image but using a USB-stick instead of a DVD. Also, I tried the network-image, with the same negative result What is wrong, what should I do get Leap 15.6 installed? Thanks in advance! Franz
On 2024-08-10 19:17, Andreas Stieger via openSUSE Users wrote:
On 2024-08-10 19:06, Carlos E. R. wrote:
Nobody is suggesting to keep old files in OBS.
And I did not say it was. Just that the status quo is deletion some time after the EOL date. In this case, 8 months. The request to have an archive for OBS published repositories is understandable, but a waste of time.
It is not a waste of time for the people needing it.
I seem to recall having reported a bug on hw-probe years ago, it crashed.
Link?
[Bug 1210427] hw-probe segfaults https://bugzilla.suse.com/show_bug.cgi?id=1210427
Recently someone posted about a machine that can not be upgraded to 15.6 because the media will not boot.
Link?
Really? It has been a long thread. Lew has posted it. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 2024-08-11 14:33, Carlos E. R. wrote:
It is not a waste of time for the people needing it.
Well then I think it would be a splendid idea for /these /people to waste their time on it.
I seem to recall having reported a bug on hw-probe years ago, it crashed.
Link?
[Bug 1210427] hw-probe segfaults https://bugzilla.suse.com/show_bug.cgi?id=1210427
This has been resolved as a duplicate of boo#1214189, where additional input requested from you in May, and closed to a lack of response.
On 11.08.2024 15:40, Andreas Stieger via openSUSE Users wrote:
[Bug 1210427] hw-probe segfaults https://bugzilla.suse.com/show_bug.cgi?id=1210427
This has been resolved as a duplicate of boo#1214189, where additional input requested from you in May,
In May 2024, the first comment since the bug was opened in August 2023.
On 2024-08-11 14:40, Andreas Stieger via openSUSE Users wrote:
On 2024-08-11 14:33, Carlos E. R. wrote:
It is not a waste of time for the people needing it.
Well then I think it would be a splendid idea for /these /people to waste their time on it.
If they have the skills and the resources to do it.
I seem to recall having reported a bug on hw-probe years ago, it crashed.
Link?
[Bug 1210427] hw-probe segfaults https://bugzilla.suse.com/show_bug.cgi?id=1210427
This has been resolved as a duplicate of boo#1214189, where additional input requested from you in May, and closed to a lack of response.
No, it was closed as there being a problem with vdpauinfo. It then was changed to a bug on vdpauinfo. It was me who asked about information, I got no reply and the bug was eventually closed. In the end, I could not run hw-probe. I still can't. Another bug was opened on vdpauinfo, Bug 1214189, which according to my emails, is still open. Looking on the web, there was movement in May, a year later. For your information, hw-probe still segfaults. I don't understand the instructions in comment 2. gdb /usr/bin/vdpauinfo <core-file> (gdb) bt What is "<core-file>"? What do I write there EXACTLY? -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On Sun, 11 Aug 2024 20:27:49 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2024-08-11 14:40, Andreas Stieger via openSUSE Users wrote:
On 2024-08-11 14:33, Carlos E. R. wrote:
It is not a waste of time for the people needing it.
Well then I think it would be a splendid idea for /these /people to waste their time on it.
If they have the skills and the resources to do it.
I seem to recall having reported a bug on hw-probe years ago, it crashed.
Link?
[Bug 1210427] hw-probe segfaults https://bugzilla.suse.com/show_bug.cgi?id=1210427
This has been resolved as a duplicate of boo#1214189, where additional input requested from you in May, and closed to a lack of response.
No, it was closed as there being a problem with vdpauinfo. It then was changed to a bug on vdpauinfo. It was me who asked about information, I got no reply and the bug was eventually closed.
In the end, I could not run hw-probe. I still can't.
Another bug was opened on vdpauinfo, Bug 1214189, which according to my emails, is still open. Looking on the web, there was movement in May, a year later.
For your information, hw-probe still segfaults.
I don't understand the instructions in comment 2.
gdb /usr/bin/vdpauinfo <core-file> (gdb) bt
What is "<core-file>"? What do I write there EXACTLY?
It is the core file produced when vdpauinfo crashes. You put the full address of the file. (You may need to check your configuration to make sure it creates core files and to find where it puts them. I have no idea how to do that in opensuse. RTFM?)
On 2024-08-11 22:20, Dave Howorth wrote:
On Sun, 11 Aug 2024 20:27:49 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2024-08-11 14:40, Andreas Stieger via openSUSE Users wrote:
On 2024-08-11 14:33, Carlos E. R. wrote:
I don't understand the instructions in comment 2.
gdb /usr/bin/vdpauinfo <core-file> (gdb) bt
What is "<core-file>"? What do I write there EXACTLY?
It is the core file produced when vdpauinfo crashes. You put the full address of the file. (You may need to check your configuration to make sure it creates core files and to find where it puts them. I have no idea how to do that in opensuse. RTFM?)
How can I put the name of the core file produced after the crash, into the gdb command line which is written before it crashes? It is nonsensical. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 8/11/24 05:40, Andreas Stieger via openSUSE Users wrote:
On 2024-08-11 14:33, Carlos E. R. wrote:
It is not a waste of time for the people needing it.
Well then I think it would be a splendid idea for /these /people to waste their time on it.
Kind of a harsh response! I would have to divert weeks (probably) of my time, which should be devoted to supporting users of remote telescopes, to grok, gain the skills, acquire permissions, and figure out how to maintain and support the repositories. I simply don't have the time to step up to your request to handle this myself just because I need it. That is why I rely on others to be the gurus and experts in maintaining things like repositories and software packages in general. As a user I SIMPLY CAN'T BE AN EXPERT IN EVERY TOOL I NEED, AND HAVE TO SUPPORT THAT TOOL BY HAVING IT DUMPED ON ME! IMHO your response is rather callous, I asked for help and your response is to say "Do it yourself"??? Yes, I understand you are a volunteer your time is precious, and you want to focus on things of interest to you, but if you are going to respond to requests for help, how about focusing on finding WIN WIN solutions instead. Are you here to help users, or are you here to denigrate users? Your responses have been, how not to help users, which doesn't make users feel very welcomed here. Marc... -- *"The Truth is out there" - Spooky* -- *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/This email is digitally signed. My public key for sending encrypted email to me can be found at - https://keys.openpgp.org/search?q=marc@domesweetdome.us.com or just ask me for it and I will send it to you as an attachment. If you don't understand, no worries, just ignore it and/or ask me to explain it further./)
On 2024-08-11 21:17, Marc Chamberlin via openSUSE Users wrote:
On 8/11/24 05:40, Andreas Stieger via openSUSE Users wrote:
On 2024-08-11 14:33, Carlos E. R. wrote:
It is not a waste of time for the people needing it.
Well then I think it would be a splendid idea for /these /people to waste their time on it.
Kind of a harsh response! I would have to divert weeks (probably) of my time, which should be devoted to supporting users of remote telescopes, to grok, gain the skills, acquire permissions, and figure out how to maintain and support the repositories. I simply don't have the time to step up to your request to handle this myself just because I need it. That is why I rely on others to be the gurus and experts in maintaining things like repositories and software packages in general. As a user I SIMPLY CAN'T BE AN EXPERT IN EVERY TOOL I NEED, AND HAVE TO SUPPORT THAT TOOL BY HAVING IT DUMPED ON ME! IMHO your response is rather callous, I asked for help and your response is to say "Do it yourself"??? Yes, I understand you are a volunteer your time is precious, and you want to focus on things of interest to you, but if you are going to respond to requests for help, how about focusing on finding WIN WIN solutions instead. Are you here to help users, or are you here to denigrate users? Your responses have been, how not to help users, which doesn't make users feel very welcomed here.
Within 10 minutes of your query you got an explanation of the issue and why it happened, with the rather reasonable recommendation to upgrade to a maintained version. What you did /not/ get was the resolution you preferred, and you have been arguing along the lines of "oh just do archive it, it's not that hard", and lack of knowledge to self-service. Not liking the consequence of that does not make someone else unwelcoming. My original recommendation remains: upgrade to one of the maintained distribution version to receive support and bug fixes. Alternatives exists, including those that should have low barriers to self-service. Andreas
On 8/11/24 2:17 PM, Marc Chamberlin via openSUSE Users wrote:
As a user I SIMPLY CAN'T BE AN EXPERT IN EVERY TOOL I NEED, AND HAVE TO SUPPORT THAT TOOL BY HAVING IT DUMPED ON ME! IMHO your response is rather callous,
<it's Friday> Oh how true. There are a few corollaries that apply: - jack of all trades, master of none - if you play golf, your tennis game will suffer and on and on. One of the most appreciated efforts from SUSE/openSUSE during my two decades of involvement was the "Evergreen" project. This kept certain releases updated and repositories available long after EOL. The benefit was it prevented users from being whipsawed out of a working release at EOL and allowed them the benefit and courtesy of choosing when to update to the next version. Many factors come into play, but by far the most pressing is work-stoppage experienced jumping from one release to the next. This is more acute for users with highly tweaked and tailored installs which can literally take days if not weeks to re-perfect on a new release -- running down versions changes, package changes and most importantly "the crap that breaks that nobody can explain (see fn1)". While evergreen was user-supported there was also support for it from opensuse in resources, buildservice, repos, etc.. Here, much of that same benefit could be provided by SUSE simply by not taking repos down. That takes no effort. What is confusing to users is when they look and see repos back to 12.3 still there, but repos for 15.4 have been taken down. I'm sure I don't understand it, but that, to a great extent, is where a bulk of the frustration comes from. Thankfully, buildservice still builds 15.4-TW by default. This isn't a criticism or a request to do A or B, merely a few points I feel are important to consider from the community's perspective. In the boxed-set days, there was no issue, you got your new boxed-set, installed and never looked back because each new release brought so much new functionality. That really hasn't been the case from 10.x forward. (yes, hardware support expands with each kernel -- to the point support for old hardware is now being dropped as well, and vulnerabilities are patched) but from a "I can do now do X on the new desktop" point of view -- there hasn't been new great "gotta have" killer feature in 20 years. It is easily understandable that someone with weeks of config tweaks in a working setup would try to avoid upsetting the apple-cart until there is a convenient time to upgrade. Leaving repos up really helps provide flexibility and options for that period of time. "duping" to the next release carries risk and many uncertainties, especially for highly tweaked installs. (and thank God for Linux - it's the choice it provides that allows you to tweak your install to perfectly meet you needs (fn2)) Food for thought. Maybe there is a happy medium somewhere that can help users like Marc, and myself on occasion, enjoy a little evergreen until time can be found to update. Footnotes :) fn1 - there is still a complete mystery why the USB MS-Mouse attached to my laptop no longer scrolls in TW with non-toplevel Gtk apps with focus-follows-mouse using libinput, but two-finger-scroll on the touchpad using synaptics continues to work just fine as it did in 15.4. So there is a subtle Gtk/libinput issue that detracts from the current experience that will likely take weeks or more to ultimately diagnose and resolve. Also, there is no native cinelera for TW (video editing is the last thing you want a containerized app to do). fn2 - chuckling as I check how my .bashrc has grown and the number of scripts I've written has proliferated: $ wc -l < .bashrc 870 $ find scr -type f | wc -l 991 </it's Friday> -- David C. Rankin, J.D.,P.E.
On 8/9/24 12:48 PM, Marc Chamberlin via openSUSE Users wrote:
I think it is fair to ask, if a tool was available for an older version of OpenSuSE, it should remain available for that older version, in some kind of archive/repo until perhaps storage space is overwhelmed.
Marc...
Marc has a point, Many times it is simply a conscious decision on the part of the repo maintainer to uncheck the "publish" flag in buildservice. There really isn't a need for that. The packages are still built, just not published and the repo is hidden. The frustrating point is for the same repo, version for 13.x and 42.x are still be present, it's just the last most recent versions that have reached eol that are hidden. The mozilla repo is a good example where 15.4 just recently "disappeared" after the post regarding the 115->128 ver. profile changes were discussed on this list. -- David C. Rankin, J.D.,P.E.
On 8/9/24 16:04, David C. Rankin wrote:
On 8/9/24 12:48 PM, Marc Chamberlin via openSUSE Users wrote:
I think it is fair to ask, if a tool was available for an older version of OpenSuSE, it should remain available for that older version, in some kind of archive/repo until perhaps storage space is overwhelmed.
Marc...
Marc has a point,
Many times it is simply a conscious decision on the part of the repo maintainer to uncheck the "publish" flag in buildservice. There really isn't a need for that. The packages are still built, just not published and the repo is hidden.
The frustrating point is for the same repo, version for 13.x and 42.x are still be present, it's just the last most recent versions that have reached eol that are hidden.
The mozilla repo is a good example where 15.4 just recently "disappeared" after the post regarding the 115->128 ver. profile changes were discussed on this list.
So, how best to resolve this issue? Bug report? Let this topic play out on this news group longer? Just curious! Marc...
On 8/10/24 10:35 PM, Marc Chamberlin via openSUSE Users wrote:
So, how best to resolve this issue? Bug report? Let this topic play out on this news group longer? Just curious! Marc...
Old issue and it is solely up to the powers that be. It is the not so subtle push to upgrade that we've seen when releases hit end of life for two decades. My 15.4 install was perfect, still is, but with the mozilla repo disappearing, it was either time to uninstall FF and pull the linux version from mozilla.org, or try the next versions. There are packages that do not exist in TW that cause issues with with kde3 like botan/libbotan versions preventing install of the kde-gtk package (the one that works). I have a suspicion that may be the root of the issue I see with libinput and kwin and Gtk apps, but it may not be as well. It's not just kwin that is having cursor issues with Gtk apps. In a perfect world, the repos would just be left up, just like the distribution and many of the mainstream repositories for each release are. So long as the packages still work, it's no skin off of anyone's teeth just to let the repo sit there. The issues creep in when CVE's would impact packages just sitting there. Like the recent xz/ssh issue or the curl issue. Then somebody would have to determine if the versions were vulnerable and rebuild. SUSE does have a vested interest in not having broken vulnerable packages laying around -- I get that. So I see the concerns on both sides, but granted, there are very few xz/ssh or curl CVE's that come along (and 15.4 wasn't vulnerable to begin with in the version of xz it had). It is just up to the distro. Though turning off mozilla did seem a bit spiteful... :) -- David C. Rankin, J.D.,P.E.
Good morning everyone, sitting with a coffee in the garden so we'll have a bit more time today. On 2024-08-11 05:53, David C. Rankin wrote:
Old issue and it is solely up to the powers that be.
Contrary to that I believe we have a project structure that allows for things to happen if people step up to do this. It may be apparent that I think that the request very bad idea, but if someone steps up why not. That has not happened, maybe that is a data point.
There are packages that do not exist in TW
This is why it is essential for all packages to be brought into the distribution if they have an upstream. Not the case for kde3, but for all others this allows the following...
that cause issues with with kde3 like botan/libbotan versions preventing install of the kde-gtk package (the one that works)
Angel and I spent time to bring the whole distribution to Botan 3. This was needed because Botan 2 will be end-of-life at the end of 2024 and is will be implicitly insecure after. We needed to touch keepassxc, rehex, rnp, ueberzugpp either at spec level or upstream. The whole Tumbleweed distribution now runs on Botan 3 and we could retire the legacy version. It's not really a big deal with the limited set. We completed this for Tumbleweed because we feel strong ownership for it, to keep it secure next year. Also this was something interesting to do on one or two slow weekends / evenings. With the same notion I take liberty to not care as much for legacy things - because it is not as much fun or fulfilling. In practice a kde3 hold-out represents the ask for someone to fix a problem now, possibly to do more than zero to maintain Botan 2 next year too - not something I would want to do in the context of community work. (Except of someone bakes me a cake, or similar goodwill guestures) I even made a transitional package for Botan 2 that would have keep old library consumers running, but in the context of the distribution it is no longer needed. Grab it from devel:libraries:c_c++/Botan2 and do what you need with it. Don't expect this to be there for long, and certainly not next year. The sources are there forever. This example may show the types of bugs that the project is most likely to work on, and why continued availability for development project repositories for openSUSE Leap 15.4 are not on the top of that list.
The issues creep in when CVE's would impact packages just sitting there. Like the recent xz/ssh issue or the curl issue. Then somebody would have to determine if the versions were vulnerable and rebuild. SUSE does have a vested interest in not having broken vulnerable packages laying around -- I get that.
For the packages: There is no security tracking coverage at all by anyone for packages not in a currently maintained distribution. And never for project repositories. For the CVE creep: Yes I believe that people should recognize a responsibility for the IT infrastructure they operate. At home you can run anything you want, but don't expect other people to do any work supporting that over the previous lifetime commitments. The points made were "it's not that hard", "disk space does not cost much", and "don't break my running system", "I can't upgrade because of this bug" - I will fix a Tumbleweed bug if I can, but please let's do it there and on maintained Leap releases trailing it. I also have a larger concern about habit forming that translates into engineering or business decisions.
So I see the concerns on both sides,
Insightful, yes, both sides are valid. But one is more right than the other in the grand scheme of things.
but granted, there are very few xz/ssh or curl CVE's that come along (and 15.4 wasn't vulnerable to begin with in the version of xz it had). openSUSE Leap 15.5 and 15.6 were never affected by the xz issue.
The larger concern is what once a release is EOL there will be neither tracking nor fixes. The lack of tracking alone is why upgrades should be done in due time. cya, Andreas
participants (8)
-
Andreas Stieger -
Andrei Borzenkov -
Carlos E. R. -
Dave Howorth -
David C. Rankin -
Felix Miata -
Lew Wolfgang -
Marc Chamberlin