Python repo for Leap 15.5 has gone away.
This repo seems to have gone away: http://download.opensuse.org/repositories/devel:/languages:/python/15.5 Now there is one for 15.6 instead. I'll guessing that this is a mistake? -- Roger Oberholtzer
Am 01.11.23 um 05:52 schrieb Roger Oberholtzer:
This repo seems to have gone away:
http://download.opensuse.org/repositories/devel:/languages:/python/15.5
Now there is one for 15.6 instead.
I'll guessing that this is a mistake?
Friendly reminder not to use devel:languages:python as repository. Ever. From the project description:
Backporting of packages against older distribution releases should not be happening in this project, only build verification. If a package is needed on any of the older openSUSE products then maintenance update is to be created. Alternatively for SLE products submission by an interested party should be done by openSUSE:Backports project.
If you just need the newest packages, please consider using devel:languages:python:backports instead.
- Ben
On 2023-11-01 17:14, Ben Greiner wrote:
Am 01.11.23 um 05:52 schrieb Roger Oberholtzer:
This repo seems to have gone away:
http://download.opensuse.org/repositories/devel:/languages:/python/15.5
Now there is one for 15.6 instead.
I'll guessing that this is a mistake?
Friendly reminder not to use devel:languages:python as repository. Ever.
From the project description:
Backporting of packages against older distribution releases should not be happening in this project, only build verification. If a package is needed on any of the older openSUSE products then maintenance update is to be created. Alternatively for SLE products submission by an interested party should be done by openSUSE:Backports project.
Where in YaST or zypper can we read those descriptions before we add a repo? Tools to add repos, like the web search, or "opi", don't give any information. We users only have the name of the repos.
If you just need the newest packages, please consider using devel:languages:python:backports instead.
- Ben
-- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 11/2/23 09:19, Carlos E. R. wrote:
On 2023-11-01 17:14, Ben Greiner wrote:
Am 01.11.23 um 05:52 schrieb Roger Oberholtzer:
This repo seems to have gone away:
http://download.opensuse.org/repositories/devel:/languages:/python/15.5
Now there is one for 15.6 instead.
I'll guessing that this is a mistake?
Friendly reminder not to use devel:languages:python as repository. Ever.
From the project description: > Backporting of packages against older distribution releases should not be happening in this project, only build verification. If a package is needed on any of the older openSUSE products then maintenance update is to be created. Alternatively for SLE products submission by an interested party should be done by openSUSE:Backports project.
Where in YaST or zypper can we read those descriptions before we add a repo?
Tools to add repos, like the web search, or "opi", don't give any information. We users only have the name of the repos.
This info doesn't exist because none of these repositories are designed or intended to be used by general end users. They exist in general to be used by developers for development and testing purposes and shouldn't be considered something that is officially offered or supported by the openSUSE project. Although there are times where more experienced users do use some of these repo's at there own risk although this is certainly not something recommended by the project in general. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 2023-11-02 01:31, Simon Lees wrote:
On 11/2/23 09:19, Carlos E. R. wrote:
On 2023-11-01 17:14, Ben Greiner wrote:
Am 01.11.23 um 05:52 schrieb Roger Oberholtzer:
This repo seems to have gone away:
http://download.opensuse.org/repositories/devel:/languages:/python/15.5
Now there is one for 15.6 instead.
I'll guessing that this is a mistake?
Friendly reminder not to use devel:languages:python as repository. Ever.
From the project description: > Backporting of packages against older distribution releases should not be happening in this project, only build verification. If a package is needed on any of the older openSUSE products then maintenance update is to be created. Alternatively for SLE products submission by an interested party should be done by openSUSE:Backports project.
Where in YaST or zypper can we read those descriptions before we add a repo?
Tools to add repos, like the web search, or "opi", don't give any information. We users only have the name of the repos.
This info doesn't exist because none of these repositories are designed or intended to be used by general end users. They exist in general to be used by developers for development and testing purposes and shouldn't be considered something that is officially offered or supported by the openSUSE project. Although there are times where more experienced users do use some of these repo's at there own risk although this is certainly not something recommended by the project in general.
My point is, how are we to know? The fact that openSUSE has extra repos is a selling point in the promotion materials. But we have no way to know which repos we can use and which we can't. We just need some application that is not in the main repos, we use the facilities to find what repo has it, we add the repo, install the package, maybe the package wants some extra library, we search for it, we add that extra repo. No one tells us what repos are good to use and which are not. There is no repository description anywhere that we can read. There is a communication problem here. (I think I needed to add the python repo at some point on some computer because some other program, perhaps some update of SA, wanted it. I don't have access at the moment to that computer to check.) -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 11/2/23 12:42, Carlos E. R. wrote:
On 2023-11-02 01:31, Simon Lees wrote:
On 11/2/23 09:19, Carlos E. R. wrote:
On 2023-11-01 17:14, Ben Greiner wrote:
Am 01.11.23 um 05:52 schrieb Roger Oberholtzer:
This repo seems to have gone away:
http://download.opensuse.org/repositories/devel:/languages:/python/15.5
Now there is one for 15.6 instead.
I'll guessing that this is a mistake?
Friendly reminder not to use devel:languages:python as repository. Ever.
From the project description: > Backporting of packages against older distribution releases should not be happening in this project, only build verification. If a package is needed on any of the older openSUSE products then maintenance update is to be created. Alternatively for SLE products submission by an interested party should be done by openSUSE:Backports project.
Where in YaST or zypper can we read those descriptions before we add a repo?
Tools to add repos, like the web search, or "opi", don't give any information. We users only have the name of the repos.
This info doesn't exist because none of these repositories are designed or intended to be used by general end users. They exist in general to be used by developers for development and testing purposes and shouldn't be considered something that is officially offered or supported by the openSUSE project. Although there are times where more experienced users do use some of these repo's at there own risk although this is certainly not something recommended by the project in general.
My point is, how are we to know?
The fact that openSUSE has extra repos is a selling point in the promotion materials. But we have no way to know which repos we can use and which we can't.
This is something we shouldn't be doing.
We just need some application that is not in the main repos, we use the facilities to find what repo has it, we add the repo, install the package, maybe the package wants some extra library, we search for it, we add that extra repo. No one tells us what repos are good to use and which are not. There is no repository description anywhere that we can read.
You should consider no repo safe to use without risk except for maybe a select few hosted by 3rd parties to resolve issues around non license compliant drivers or other patent encumbered software that openSUSE can't legally ship.
There is a communication problem here.
Indeed
(I think I needed to add the python repo at some point on some computer because some other program, perhaps some update of SA, wanted it. I don't have access at the moment to that computer to check.)
The python repo is especially good for randomly breaking your system, the backports repo on Leap can be manageable if you really know what your doing. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Citeren "Carlos E. R." <robin.listas@telefonica.net>:
On 2023-11-02 01:31, Simon Lees wrote:
On 11/2/23 09:19, Carlos E. R. wrote:
On 2023-11-01 17:14, Ben Greiner wrote:
Am 01.11.23 um 05:52 schrieb Roger Oberholtzer:
This repo seems to have gone away:
http://download.opensuse.org/repositories/devel:/languages:/python/15.5
Now there is one for 15.6 instead.
I'll guessing that this is a mistake?
Friendly reminder not to use devel:languages:python as repository. Ever.
From the project description: > Backporting of packages against older distribution releases should not be happening in this project, only build verification. If a package is needed on any of the older openSUSE products then maintenance update is to be created. Alternatively for SLE products submission by an interested party should be done by openSUSE:Backports project.
Where in YaST or zypper can we read those descriptions before we add a repo?
Tools to add repos, like the web search, or "opi", don't give any information. We users only have the name of the repos.
This info doesn't exist because none of these repositories are designed or intended to be used by general end users. They exist in general to be used by developers for development and testing purposes and shouldn't be considered something that is officially offered or supported by the openSUSE project. Although there are times where more experienced users do use some of these repo's at there own risk although this is certainly not something recommended by the project in general.
My point is, how are we to know?
The fact that openSUSE has extra repos is a selling point in the promotion materials. But we have no way to know which repos we can use and which we can't.
We just need some application that is not in the main repos, we use the facilities to find what repo has it, we add the repo, install the package, maybe the package wants some extra library, we search for it, we add that extra repo. No one tells us what repos are good to use and which are not. There is no repository description anywhere that we can read.
I beg to differ: https://build.opensuse.org/project/show/devel:languages:python Before adding a development project, it makes sense to at least check the project on OBS.
There is a communication problem here.
(I think I needed to add the python repo at some point on some computer because some other program, perhaps some update of SA, wanted it. I don't have access at the moment to that computer to check.)
I think that even the devel:languages: part is unclear to me. I have always interpreted that tree to mean things that developers in that language may need. Things that are not part of the base distribution. Either because they are too specialized, or perhaps experimental in nature. I agree that one uses it at one's own risk. But aside from the core repos that make up the OS release, isn't that the case with all repos? Some things make it in to the core, while others don't. If I could stick with the core repos, I would. But we use/need packages that are only available in other repos. We understand the risks. If there was a 15.5 python repo, but it should not be used, so it was removed, then why is there a 15.6 repo? That seems confusing and unclear. backports is perhaps poorly named? I view a backport as code that has been modified for compatibility reasons. It is no longer the original. If anything, I would stay away from backports and try to use current releases of everything. Backports are a last ditch chance at getting a package to work in some environment. If that is was the backports python repo is, and that is the only place to get packages not in the core distro, then I am confused. As I said, perhaps it is just poorly named? I love the repos that SUSE/openSUSE provide. Big fan. Happy user. But some things that are perhaps obvious to the developers are not clear to those who would like to use what all the hard work is creating. In my case here, if I wanted the most complete availability of Python packages for Leap 15.5, which repos should I use? Following that, if I do not find a specific package, which repos are the 2nd tier repos for this? I am not just looking to install a Python package or two. I am making an OEM installable Leap 15.5 image with kiwi that, for our use, comes fully loaded with all the things we actually use. Building such images is very dependent on the repos that you define. When the Python 15.5 repo went away, I am no longer able to build an OEM Leap 15.5 installer. On Thu, Nov 2, 2023 at 7:56 AM Arjen de Korte <suse+build@de-korte.org> wrote:
Citeren "Carlos E. R." <robin.listas@telefonica.net>:
On 2023-11-02 01:31, Simon Lees wrote:
On 11/2/23 09:19, Carlos E. R. wrote:
On 2023-11-01 17:14, Ben Greiner wrote:
Am 01.11.23 um 05:52 schrieb Roger Oberholtzer:
This repo seems to have gone away:
http://download.opensuse.org/repositories/devel:/languages:/python/15.5
Now there is one for 15.6 instead.
I'll guessing that this is a mistake?
Friendly reminder not to use devel:languages:python as repository. Ever.
Backporting of packages against older distribution releases should not be happening in this project, only build verification. If a package is needed on any of the older openSUSE products then
From the project description: maintenance update is to be created. Alternatively for SLE products submission by an interested party should be done by openSUSE:Backports project.
Where in YaST or zypper can we read those descriptions before we add a repo?
Tools to add repos, like the web search, or "opi", don't give any information. We users only have the name of the repos.
This info doesn't exist because none of these repositories are designed or intended to be used by general end users. They exist in general to be used by developers for development and testing purposes and shouldn't be considered something that is officially offered or supported by the openSUSE project. Although there are times where more experienced users do use some of these repo's at there own risk although this is certainly not something recommended by the project in general.
My point is, how are we to know?
The fact that openSUSE has extra repos is a selling point in the promotion materials. But we have no way to know which repos we can use and which we can't.
We just need some application that is not in the main repos, we use the facilities to find what repo has it, we add the repo, install the package, maybe the package wants some extra library, we search for it, we add that extra repo. No one tells us what repos are good to use and which are not. There is no repository description anywhere that we can read.
I beg to differ:
https://build.opensuse.org/project/show/devel:languages:python
Before adding a development project, it makes sense to at least check the project on OBS.
There is a communication problem here.
(I think I needed to add the python repo at some point on some computer because some other program, perhaps some update of SA, wanted it. I don't have access at the moment to that computer to check.)
-- Roger Oberholtzer
On Thu, Nov 2, 2023 at 11:12 AM Arjen de Korte <suse+build@de-korte.org> wrote:
Citeren "Carlos E. R." <robin.listas@telefonica.net>:
On 2023-11-02 01:31, Simon Lees wrote:
On 11/2/23 09:19, Carlos E. R. wrote:
On 2023-11-01 17:14, Ben Greiner wrote:
Am 01.11.23 um 05:52 schrieb Roger Oberholtzer:
This repo seems to have gone away:
http://download.opensuse.org/repositories/devel:/languages:/python/15.5
Now there is one for 15.6 instead.
I'll guessing that this is a mistake?
Friendly reminder not to use devel:languages:python as repository. Ever.
Backporting of packages against older distribution releases should not be happening in this project, only build verification. If a package is needed on any of the older openSUSE products then
From the project description: maintenance update is to be created. Alternatively for SLE products submission by an interested party should be done by openSUSE:Backports project.
Where in YaST or zypper can we read those descriptions before we add a repo?
Tools to add repos, like the web search, or "opi", don't give any information. We users only have the name of the repos.
This info doesn't exist because none of these repositories are designed or intended to be used by general end users. They exist in general to be used by developers for development and testing purposes and shouldn't be considered something that is officially offered or supported by the openSUSE project. Although there are times where more experienced users do use some of these repo's at there own risk although this is certainly not something recommended by the project in general.
My point is, how are we to know?
The fact that openSUSE has extra repos is a selling point in the promotion materials. But we have no way to know which repos we can use and which we can't.
We just need some application that is not in the main repos, we use the facilities to find what repo has it, we add the repo, install the package, maybe the package wants some extra library, we search for it, we add that extra repo. No one tells us what repos are good to use and which are not. There is no repository description anywhere that we can read.
I beg to differ:
https://build.opensuse.org/project/show/devel:languages:python
Before adding a development project, it makes sense to at least check the project on OBS.
*Users* do not even know that OBS exists, what it is for or how to interpret information there. Users get redirected from software.opensuse.org (most common case) to 1-click install or sometimes just get a direct link to download.opensuse.org. Not much can be done about the latter, but the former boils down to the usual complaints about s.o.o being unsuitable as the end user-facing tool. Although even in the latter case zypper could support a mechanism to display a warning when adding a repository (as part of repository metadata) and such warnings could be generated automatically by OBS.
There is a communication problem here.
(I think I needed to add the python repo at some point on some computer because some other program, perhaps some update of SA, wanted it. I don't have access at the moment to that computer to check.)
On 2023-11-02 09:32, Andrei Borzenkov wrote:
*Users* do not even know that OBS exists, what it is for or how to interpret information there. Users get redirected from software.opensuse.org (most common case) to 1-click install or sometimes just get a direct link to download.opensuse.org. Not much can be done about the latter, but the former boils down to the usual complaints about s.o.o being unsuitable as the end user-facing tool.
Although even in the latter case zypper could support a mechanism to display a warning when adding a repository (as part of repository metadata) and such warnings could be generated automatically by OBS.
I talked about how software.opensuse.org and 1-click installs should either be dramatically reformed or removed over SEVEN years ago https://www.youtube.com/watch?v=lz3whk4E_IA My view has only grown stronger over time. Users should not be using random OBS projects, just as Windows users shouldn't use random .exes from the internet. Software we want our users to use should be in our distributions. Period. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
On 2023-11-02 09:57, Richard Brown wrote:
On 2023-11-02 09:32, Andrei Borzenkov wrote:
*Users* do not even know that OBS exists, what it is for or how to interpret information there. Users get redirected from software.opensuse.org (most common case) to 1-click install or sometimes just get a direct link to download.opensuse.org. Not much can be done about the latter, but the former boils down to the usual complaints about s.o.o being unsuitable as the end user-facing tool.
Although even in the latter case zypper could support a mechanism to display a warning when adding a repository (as part of repository metadata) and such warnings could be generated automatically by OBS.
I talked about how software.opensuse.org and 1-click installs should either be dramatically reformed or removed over SEVEN years ago
https://www.youtube.com/watch?v=lz3whk4E_IA
My view has only grown stronger over time. Users should not be using random OBS projects, just as Windows users shouldn't use random .exes from the internet.
Software we want our users to use should be in our distributions. Period.
If openSUSE does what you suggests, it is death of it. Not everything is in the distribution, we need more. Period. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
Hi Richard, hi Carlos, On 02.11.23 at 12:48 Carlos E. R. wrote:
On 2023-11-02 09:57, Richard Brown wrote:
Software we want our users to use should be in our distributions. Period.
FULL ACK.
Not everything is in the distribution, we need more. Period.
The actual question is: Why is it not in the distribution? Setting aside license/legal issues, my guess would be that too many "casual packagers" are afraid by "maintaining something in the distribution". Which is unfortunate, as it is not much of a hassle (for most packages, YMMV) in my experience. In other words: Someone has to step forward and maintain those packages, then they can be included in the distribution. Using "some package from OBS" IMHO is a bad idea, if it is unclear how "maintained" the package is. (Carlos, I know your reply will be that you are a mere user and not a packager. My answer will be "I was too, but I learned how to use OBS a little so I can maintain packages" :-) ) Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On Thu, Nov 2, 2023 at 3:26 PM Johannes Kastl via openSUSE Factory <factory@lists.opensuse.org> wrote:
Using "some package from OBS" IMHO is a bad idea, if it is unclear how "maintained" the package is.
Exactly as any package in distribution. Either someone maintains them or not. The only difference is that if the package fails to build, it gets removed from Tumbleweed. As long as the package still builds, nobody knows whether it actually works or not until someone tries installing and using it. Packages do not magically become "better maintained" just because they are included in the Factory.
On Thursday 2023-11-02 13:48, Andrei Borzenkov wrote:
On Thu, Nov 2, 2023 at 3:26 PM Johannes Kastl via openSUSE Factory <factory@lists.opensuse.org> wrote:
Using "some package from OBS" IMHO is a bad idea, if it is unclear how "maintained" the package is.
Exactly as any package in distribution.[..] Packages do not magically become "better maintained" just because they are included in the Factory.
Home projects just fail, and the one person that could be mailed has it disabled or ignores it. Failing Factory builds get circulated to a wider audience, and more often (~twice automated, and potentially a third time by a human). It's true, a factory submission does not guarantee collaboration, but a non-submission almost certainly guarantees non-collaboration.
Hi Jan, hi Andrei, On 02.11.23 at 14:13 Jan Engelhardt wrote:
It's true, a factory submission does not guarantee collaboration, but a non-submission almost certainly guarantees non-collaboration.
For Factory submissions (and probably Leap as well) at least once the package is being checked critically, both technically and legally... So yes, a package in Factory can still error out and fail to work, but the hurdle is a little higher at least. Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Am 02.11.23 um 08:26 schrieb Johannes Kastl via openSUSE Factory:
Hi Jan, hi Andrei,
On 02.11.23 at 14:13 Jan Engelhardt wrote:
It's true, a factory submission does not guarantee collaboration, but a non-submission almost certainly guarantees non-collaboration.
For Factory submissions (and probably Leap as well) at least once the package is being checked critically, both technically and legally...
So yes, a package in Factory can still error out and fail to work, but the hurdle is a little higher at least.
Kind Regards, Johannes
Note that the original question in this thread was about devel:language:python packages for 15.5. Almost everything in d:l:p is in Factory anyway. But it is not in vanilla 15.X. Welcome to the 156th discussion about Python being outdated in 15.X. We still do not have a functioning and well documented "Python Module Pythons" providing a reasonably complete stack for Python 3.11 for SLE15. Until that happens, users will keep on trying random selections of obs project repositories to get more recent python packages into 15.X. - Ben
Hi all, Am Do., 2. Nov. 2023 um 18:20 Uhr schrieb Ben Greiner <code@bnavigator.de>:
We still do not have a functioning and well documented "Python Module Pythons" providing a reasonably complete stack for Python 3.11 for SLE15. Until that happens, users will keep on trying random selections of obs project repositories to get more recent python packages into 15.X.
An initial batch of modules has finally been released in leap and the python 3 module. Greetings, Dirk
Am 2. November 2023 13:48:31 MEZ schrieb Andrei Borzenkov <arvidjaar@gmail.com>:
On Thu, Nov 2, 2023 at 3:26 PM Johannes Kastl via openSUSE Factory <factory@lists.opensuse.org> wrote:
Using "some package from OBS" IMHO is a bad idea, if it is unclear how "maintained" the package is.
Exactly as any package in distribution. Either someone maintains them or not. The only difference is that if the package fails to build, it gets removed from Tumbleweed. As long as the package still builds, nobody knows whether it actually works or not until someone tries installing and using it.
Packages do not magically become "better maintained" just because they are included in the Factory.
+1
On Do, Nov 2 2023 at 13:25:46 +01:00:00, Johannes Kastl via openSUSE Factory <factory@lists.opensuse.org> wrote:
Not everything is in the distribution, we need more. Period.
The actual question is: Why is it not in the distribution?
Setting aside license/legal issues, my guess would be that too many "casual packagers" are afraid by "maintaining something in the distribution".
Which is unfortunate, as it is not much of a hassle (for most packages, YMMV) in my experience.
In other words: Someone has to step forward and maintain those packages, then they can be included in the distribution.
Using "some package from OBS" IMHO is a bad idea, if it is unclear how "maintained" the package is.
There are a couple of issues reported on software-o-o GitHub repository about ways to improve this. Ideas like allowing users to show their interest in having packages be a part of the distros, listing download statistics of individual packages so that maintainers can pick up popular packages which are not yet a part of Factory. The biggest problem stopping adoption of those ideas is the fact that software-o-o doesn't currently have a database, everything is cached by rails or fetched directly from OBS, so implementing these things would be difficult if not impossible. Making software-o-o have a database wouldn't be too hard, and it would be great to have a piece of software that helps improve the distros with the packages that users want, but as usual it's a problem of having the time to do all that. LCP [Jake] https://lcp.world/
Am 2. November 2023 12:48:22 MEZ schrieb "Carlos E. R." <carlos.e.r@opensuse.org>:
On 2023-11-02 09:57, Richard Brown wrote:
On 2023-11-02 09:32, Andrei Borzenkov wrote:
*Users* do not even know that OBS exists, what it is for or how to interpret information there. Users get redirected from software.opensuse.org (most common case) to 1-click install or sometimes just get a direct link to download.opensuse.org. Not much can be done about the latter, but the former boils down to the usual complaints about s.o.o being unsuitable as the end user-facing tool.
Although even in the latter case zypper could support a mechanism to display a warning when adding a repository (as part of repository metadata) and such warnings could be generated automatically by OBS.
I talked about how software.opensuse.org and 1-click installs should either be dramatically reformed or removed over SEVEN years ago
https://www.youtube.com/watch?v=lz3whk4E_IA
My view has only grown stronger over time. Users should not be using random OBS projects, just as Windows users shouldn't use random .exes from the internet.
Software we want our users to use should be in our distributions. Period.
If openSUSE does what you suggests, it is death of it.
Not everything is in the distribution, we need more. Period.
+1
2. 11. 2023 v 19:23, Eric Schirra <ecsos@opensuse.org>:
Am 2. November 2023 12:48:22 MEZ schrieb "Carlos E. R." <carlos.e.r@opensuse.org>:
On 2023-11-02 09:57, Richard Brown wrote:
On 2023-11-02 09:32, Andrei Borzenkov wrote:
*Users* do not even know that OBS exists, what it is for or how to interpret information there. Users get redirected from software.opensuse.org (most common case) to 1-click install or sometimes just get a direct link to download.opensuse.org. Not much can be done about the latter, but the former boils down to the usual complaints about s.o.o being unsuitable as the end user-facing tool.
Although even in the latter case zypper could support a mechanism to display a warning when adding a repository (as part of repository metadata) and such warnings could be generated automatically by OBS.
I talked about how software.opensuse.org and 1-click installs should either be dramatically reformed or removed over SEVEN years ago
https://www.youtube.com/watch?v=lz3whk4E_IA
My view has only grown stronger over time. Users should not be using random OBS projects, just as Windows users shouldn't use random .exes from the internet.
Software we want our users to use should be in our distributions. Period.
If openSUSE does what you suggests, it is death of it.
Not everything is in the distribution, we need more. Period.
+1 Simple solution fix package and send it into distro :D
Am 2. November 2023 19:25:06 MEZ schrieb "Ondřej Súkup" <mimi.vx@gmail.com>:
2. 11. 2023 v 19:23, Eric Schirra <ecsos@opensuse.org>:
Am 2. November 2023 12:48:22 MEZ schrieb "Carlos E. R." <carlos.e.r@opensuse.org>:
On 2023-11-02 09:57, Richard Brown wrote:
On 2023-11-02 09:32, Andrei Borzenkov wrote:
*Users* do not even know that OBS exists, what it is for or how to interpret information there. Users get redirected from software.opensuse.org (most common case) to 1-click install or sometimes just get a direct link to download.opensuse.org. Not much can be done about the latter, but the former boils down to the usual complaints about s.o.o being unsuitable as the end user-facing tool.
Although even in the latter case zypper could support a mechanism to display a warning when adding a repository (as part of repository metadata) and such warnings could be generated automatically by OBS.
I talked about how software.opensuse.org and 1-click installs should either be dramatically reformed or removed over SEVEN years ago
https://www.youtube.com/watch?v=lz3whk4E_IA
My view has only grown stronger over time. Users should not be using random OBS projects, just as Windows users shouldn't use random .exes from the internet.
Software we want our users to use should be in our distributions. Period.
If openSUSE does what you suggests, it is death of it.
Not everything is in the distribution, we need more. Period.
+1 Simple solution fix package and send it into distro :D
Unfortunately, it very often doesn't work. Requires unnecessary time and nerves. You encounter ignorance, arrogance, non-response and unwillingness. Far too many packages are clearly too old. It takes months to get through all this, if you manage it at all. Why do you think there are more and more interesting and newer packages in the Home repos? Just reflect on the reactions and behavior of the "management team" in this thread. Think about it.
On 2023-11-02 07:47, Arjen de Korte wrote:
Citeren "Carlos E. R." <robin.listas@telefonica.net>:
On 2023-11-02 01:31, Simon Lees wrote:
On 11/2/23 09:19, Carlos E. R. wrote:
On 2023-11-01 17:14, Ben Greiner wrote:
Am 01.11.23 um 05:52 schrieb Roger Oberholtzer:
...
My point is, how are we to know?
The fact that openSUSE has extra repos is a selling point in the promotion materials. But we have no way to know which repos we can use and which we can't.
We just need some application that is not in the main repos, we use the facilities to find what repo has it, we add the repo, install the package, maybe the package wants some extra library, we search for it, we add that extra repo. No one tells us what repos are good to use and which are not. There is no repository description anywhere that we can read.
I beg to differ:
https://build.opensuse.org/project/show/devel:languages:python
Before adding a development project, it makes sense to at least check the project on OBS.
That's not how we users do things. Andrei B. explains it well. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On Thursday 2023-11-02 12:49, Carlos E. R. wrote:
The fact that openSUSE has extra repos is a selling point in the promotion materials. But we have no way to know which repos we can use and which we can't. [..] No one tells us what repos are good to use and which are not.
But also, no one tells you which toes of your foot are good to shoot at, and which ones aren't. Common sense for the win.
Am 02.11.23 um 04:49 schrieb Carlos E. R.:
On 2023-11-02 07:47, Arjen de Korte wrote:
Citeren "Carlos E. R." <robin.listas@telefonica.net>:
On 2023-11-02 01:31, Simon Lees wrote:
On 11/2/23 09:19, Carlos E. R. wrote:
On 2023-11-01 17:14, Ben Greiner wrote:
Am 01.11.23 um 05:52 schrieb Roger Oberholtzer:
...
My point is, how are we to know?
The fact that openSUSE has extra repos is a selling point in the promotion materials. But we have no way to know which repos we can use and which we can't.
We just need some application that is not in the main repos, we use the facilities to find what repo has it, we add the repo, install the package, maybe the package wants some extra library, we search for it, we add that extra repo. No one tells us what repos are good to use and which are not. There is no repository description anywhere that we can read.
I beg to differ:
https://build.opensuse.org/project/show/devel:languages:python
Before adding a development project, it makes sense to at least check the project on OBS.
That's not how we users do things.
But you should. And why don't you do it? Because users keep telling other newbies on Reddit and the forums to use opi or click on development and home repository links on software.o.o. Stop doing that. - Ben
On Thu 02 Nov 2023 10:11:59 AM CDT, Ben Greiner wrote: <snip>
That's not how we users do things.
But you should. And why don't you do it? Because users keep telling other newbies on Reddit and the forums to use opi or click on development and home repository links on software.o.o. Stop doing that.
- Ben
Hi Ben We frown upon it in the Forums the best we can ;) A recent example: <https://forums.opensuse.org/t/problem-after-tw-dist-upgrade-to-20231023/170189/28> Then in the case of users creating scripts to perform installs outside of the build service... I just shake my head... I've deleted a whole lot of Sub Projects in my Build Service $HOME and disabled publishing.... It has got better, back a few years I've seen users with 100+ repositories added and wonder why they have an issue... -- Cheers Malcolm °¿° (Linux Counter #276890) Tumbleweed 20231031 | GNOME Shell 45.0 | 6.5.9-1-default HP Z440 | Xeon E5-2695 V4 X36 @ 2.10GHz | Quadro T400/Tesla P4 up 19:49, 2 users, load average: 0.03, 0.05, 0.02
On Thu, 2 Nov 2023 10:11:59 -0700, Ben Greiner wrote:
But you should. And why don't you do it? Because users keep telling other newbies on Reddit and the forums to use opi or click on development and home repository links on software.o.o. Stop doing that.
People form bad habits and then share those bad habits. It seems to me that if a devel: repo isn't intended to be added to a users' repo list, it should either be impossible to do so, or there should be a very obvious warning that this is a bad idea - and not just on build.o.o or software.o.o, but in the tools used to add repos to a local system. Don't block it entirely - because maybe there are situations where it makes sense - so let an override be available for those who know what they're doing. Most users don't know what they're doing, and you're not going to get every user to stop giving bad recommendations to other users (sure would be nice if we *could* do that, but people are involved, so it ain't happening). But wait....we *shouldn't* be using opi? Then what does that tool even exist for? (And we wonder why users get confused - provide a tool that makes it easy to install specific things, and then say "don't use that, you'll screw your system up" isn't a great look). -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
On 11/3/23 04:32, Jim Henderson wrote:
On Thu, 2 Nov 2023 10:11:59 -0700, Ben Greiner wrote:
But you should. And why don't you do it? Because users keep telling other newbies on Reddit and the forums to use opi or click on development and home repository links on software.o.o. Stop doing that.
People form bad habits and then share those bad habits. It seems to me that if a devel: repo isn't intended to be added to a users' repo list, it should either be impossible to do so, or there should be a very obvious warning that this is a bad idea - and not just on build.o.o or software.o.o, but in the tools used to add repos to a local system.
Don't block it entirely - because maybe there are situations where it makes sense - so let an override be available for those who know what they're doing.
Most users don't know what they're doing, and you're not going to get every user to stop giving bad recommendations to other users (sure would be nice if we *could* do that, but people are involved, so it ain't happening).
But wait....we *shouldn't* be using opi? Then what does that tool even exist for? (And we wonder why users get confused - provide a tool that makes it easy to install specific things, and then say "don't use that, you'll screw your system up" isn't a great look).
It exists because someone created it and provided it because they thought it would be useful for people and as a project we are very hesitant to say no to someone without a very strong reason be it legal, technical or otherwise. I think where I sit in the compromise on this is opi can sit in the repo because its obviously useful for certain people who know what they are doing but at the same time we shouldn't be including it in official documentation which to date we haven't as far as I know. Secondly we should be discouraging people from using it in official support channels when it comes up due to the reasons mentioned in this thread. I had similar feedback to Lubos' idea of providing a desktop file pointing to software.o.o the other week. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Fri, 3 Nov 2023 10:55:41 +1030, Simon Lees wrote:
But wait....we *shouldn't* be using opi? Then what does that tool even exist for? (And we wonder why users get confused - provide a tool that makes it easy to install specific things, and then say "don't use that, you'll screw your system up" isn't a great look).
It exists because someone created it and provided it because they thought it would be useful for people and as a project we are very hesitant to say no to someone without a very strong reason be it legal, technical or otherwise.
"It could cause serious harm to your system" seems to be a pretty significant reason to not include it, along with "this is an unsupported tool". On my TW system, it looks like it's from the Utilities repo, which looks to me to be an "official" repo. So why are we including unsupported tools in official repos? For that matter, I see that it is *also* in the main OSS repo. So we include stuff in the main repo that people *shouldn't* use? That seems.....odd (to put it mildly). What else do we include in the OSS repo that we should be steering users away from?
I think where I sit in the compromise on this is opi can sit in the repo because its obviously useful for certain people who know what they are doing but at the same time we shouldn't be including it in official documentation which to date we haven't as far as I know. Secondly we should be discouraging people from using it in official support channels when it comes up due to the reasons mentioned in this thread.
This is news to me. I'm sure I'm not alone - and as one of the admins in the forums, I would've expected it to be something that was super clear that we *should not* be promoting the use of. Now I wonder if there are other tools that are commonly suggested that should be discouraged?
I had similar feedback to Lubos' idea of providing a desktop file pointing to software.o.o the other week.
Which I think makes more sense, because software.o.o includes home: repos - which I always recommend against because they're essentially "playground" repos (something that I've had to explain to third parties, like System76, who pointed me at a random home: repo for builds of their utilities that could run on openSUSE). I guess my bottom line question is this: How is *anyone* supposed to know what tools are "safe" and what tools we include that they "should be discouraged from using" - and why on Earth do we include anything that people who don't know any better should be "discouraged from using" in the first place? Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
* Jim Henderson <hendersj@gmail.com> [11-02-23 21:58]:
On Fri, 3 Nov 2023 10:55:41 +1030, Simon Lees wrote:
But wait....we *shouldn't* be using opi? Then what does that tool even exist for? (And we wonder why users get confused - provide a tool that makes it easy to install specific things, and then say "don't use that, you'll screw your system up" isn't a great look).
...
This is news to me. I'm sure I'm not alone - and as one of the admins in the forums, I would've expected it to be something that was super clear that we *should not* be promoting the use of.
Now I wonder if there are other tools that are commonly suggested that should be discouraged?
how does one determing who is capable and who is not. I find opi a *valuable* tool and I understand perfectly well that using packages from *unofficial* repos is problematic. why should I be denied the use of *any* tool? after all, I am the admin of my system(s) and responsible to backup, corrupt, reinstall, or any other action due to my inaptness or lack of knowledge. If a package/application is not available and someone has built it, I may try it or may build it locally myself and/or may completely fail. But it is my judgement and my own failings not to be determined by someone else's decision of my capabilities. one *cannot* protect one from oneself. I am responsible for what I do. please offer advise but do not deny me the ability to make decisions about my administration of my systems. opi is a good tool. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On Thu, 2 Nov 2023 22:18:49 -0400, Patrick Shanahan wrote:
how does one determing who is capable and who is not. I find opi a *valuable* tool and I understand perfectly well that using packages from *unofficial* repos is problematic. why should I be denied the use of *any* tool? after all, I am the admin of my system(s) and responsible to backup, corrupt, reinstall, or any other action due to my inaptness or lack of knowledge. If a package/application is not available and someone has built it, I may try it or may build it locally myself and/or may completely fail. But it is my judgement and my own failings not to be determined by someone else's decision of my capabilities.
I agree.
one *cannot* protect one from oneself.
Someone who is determined to make bad decisions, sure, they're going to do that. But we don't document it appropriately to allow people to make good decisions wrt using the tool. We put it in the official repos and then we're supposed to discourage people from using it, and just to drive the point home, we don't document it? That's madness.
I am responsible for what I do. please offer advise but do not deny me the ability to make decisions about my administration of my systems.
opi is a good tool.
I agree that it is. This is why I'm questioning why we should be actively discouraging people from using it when we include it in the main repos. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
On 03.11.23 02:04, Jim Henderson wrote:
"It could cause serious harm to your system" seems to be a pretty significant reason to not include it,
"rm" can cause serious harm to your system. try "rm -rf /*" as root, but don't complain afterwards. zypper can do serious harm to your system if used wrong. opi is a tool. A tool that can ease some things for the casual user (like codecs installation) but if used unwisely, it will do harm. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Fri, 3 Nov 2023 06:22:49 +0100, Stefan Seyfried via openSUSE Factory wrote:
On 03.11.23 02:04, Jim Henderson wrote:
"It could cause serious harm to your system" seems to be a pretty significant reason to not include it,
"rm" can cause serious harm to your system. try "rm -rf /*" as root, but don't complain afterwards.
zypper can do serious harm to your system if used wrong.
opi is a tool. A tool that can ease some things for the casual user (like codecs installation) but if used unwisely, it will do harm.
A fair point, but still, that's a far cry from "we should actively discourage people from using it, even though we include it in the standard repos". -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
On Fri, 2023-11-03 at 01:04 +0000, Jim Henderson wrote:
For that matter, I see that it is *also* in the main OSS repo. So we include stuff in the main repo that people *shouldn't* use? That seems.....odd (to put it mildly). What else do we include in the OSS repo that we should be steering users away from?
I think where I sit in the compromise on this is opi can sit in the repo because its obviously useful for certain people who know what they are doing but at the same time we shouldn't be including it in official documentation which to date we haven't as far as I know. Secondly we should be discouraging people from using it in official support channels when it comes up due to the reasons mentioned in this thread.
This is news to me. I'm sure I'm not alone - and as one of the admins in the forums, I would've expected it to be something that was super clear that we *should not* be promoting the use of.
Now I wonder if there are other tools that are commonly suggested that should be discouraged?
tumbleweed-cli comes to mind. If uses properly, it can help - the more repos you add, the less likely it will work.
On Fri, 03 Nov 2023 16:08:48 +0100, Dominique Leuenberger wrote:
Now I wonder if there are other tools that are commonly suggested that should be discouraged?
tumbleweed-cli comes to mind.
If uses properly, it can help - the more repos you add, the less likely it will work.
That's also a far cry from "we should discourage people from using it". -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
On Fri 03 Nov 2023 10:55:41 AM CDT, Simon Lees wrote: <snip>
It exists because someone created it and provided it because they thought it would be useful for people and as a project we are very hesitant to say no to someone without a very strong reason be it legal, technical or otherwise.
I think where I sit in the compromise on this is opi can sit in the repo because its obviously useful for certain people who know what they are doing but at the same time we shouldn't be including it in official documentation which to date we haven't as far as I know. Secondly we should be discouraging people from using it in official support channels when it comes up due to the reasons mentioned in this thread.
Seems official to me... ;) <https://en.opensuse.org/SDB:OBS_Package_Installer> <https://github.com/openSUSE/opi> <snip> -- Cheers Malcolm °¿° (Linux Counter #276890) Tumbleweed 20231031 | GNOME Shell 45.0 | 6.5.9-1-default HP Z440 | Xeon E5-2695 V4 X36 @ 2.10GHz | Quadro T400/Tesla P4 up 1 day 4:47, 2 users, load average: 0.48, 0.22, 0.09
On 11/3/23 12:53, Malcolm wrote:
On Fri 03 Nov 2023 10:55:41 AM CDT, Simon Lees wrote: <snip>
It exists because someone created it and provided it because they thought it would be useful for people and as a project we are very hesitant to say no to someone without a very strong reason be it legal, technical or otherwise.
I think where I sit in the compromise on this is opi can sit in the repo because its obviously useful for certain people who know what they are doing but at the same time we shouldn't be including it in official documentation which to date we haven't as far as I know. Secondly we should be discouraging people from using it in official support channels when it comes up due to the reasons mentioned in this thread.
Seems official to me... ;) <https://en.opensuse.org/SDB:OBS_Package_Installer> <https://github.com/openSUSE/opi>
Just because something has a wiki page with documentation doesn't make it official, when people were working on the full official documentation for openSUSE it was intentionally omitted. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 2023-11-03 10:29, Simon Lees wrote:
Just because something has a wiki page with documentation doesn't make it official, when people were working on the full official documentation for openSUSE it was intentionally omitted.
Oh the irony given how much stuff they included that was explicitly in opposition to the wishes of our actual developers… It’s quite simple - from a legal/liability/licensing perspective only the stuff actually in the openSUSE distros can be considered covered under the openSUSE License Anything else can be removed at any time, for any reason as described in https://en.opensuse.org/openSUSE:Build_Service_Terms_of_Service And that’s in addition to any devel or home project being at the whim of the devel or home maintainers - their repos, their rules. So if anyone wants to rely on a package, having it in an openSUSE distro is a whole bunch safer than any alternative -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
* Richard Brown <rbrown@suse.de> [11-03-23 10:46]:
On 2023-11-03 10:29, Simon Lees wrote:
Just because something has a wiki page with documentation doesn't make it official, when people were working on the full official documentation for openSUSE it was intentionally omitted.
Oh the irony given how much stuff they included that was explicitly in opposition to the wishes of our actual developers…
It’s quite simple - from a legal/liability/licensing perspective only the stuff actually in the openSUSE distros can be considered covered under the openSUSE License
Anything else can be removed at any time, for any reason as described in https://en.opensuse.org/openSUSE:Build_Service_Terms_of_Service
And that’s in addition to any devel or home project being at the whim of the devel or home maintainers - their repos, their rules.
So if anyone wants to rely on a package, having it in an openSUSE distro is a whole bunch safer than any alternative
aside from including it within a local repo (createrepo).
-- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On Fri, 3 Nov 2023 19:59:12 +1030, Simon Lees wrote:
Just because something has a wiki page with documentation doesn't make it official, when people were working on the full official documentation for openSUSE it was intentionally omitted.
IMO, that should lead to a discussion about whether or not it should even be in the standard repos. Otherwise, what you're doing is not giving people any information to make an informed decision about something that sure looks to be official, since it's in the OSS repo. How are people supposed to make an informed decision about what is "safe" to use that's included in the distro and what it is *not* "safe" to use that's included in the distro? Especially something that's written to make it *easier* to install things like codecs correctly? To include a tool that makes life easier and then to say "but don't use it" borders on madness. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
participants (20)
-
Andrei Borzenkov -
Arjen de Korte -
Ben Greiner -
Carlos E. R. -
Carlos E. R. -
Dirk Müller -
Dominique Leuenberger -
Eric Schirra -
Jacob Michalskie -
Jan Engelhardt -
Jim Henderson -
Johannes Kastl -
Larry Len Rainey -
Malcolm -
Ondřej Súkup -
Patrick Shanahan -
Richard Brown -
Roger Oberholtzer -
Simon Lees -
Stefan Seyfried