Hello,
I need to be able to read and safe webp graphics in gimp. I am on Opensuse 15.1 and that comes with gimp 2.8 which doesn't support this format, it is (as I read) included from Gimp 2.9.
I found oneclick install for Gimp 2.10 for OS 15.1. Tried it. It failed because libmypaint-1.4 cant be found.
I installed without, but then Gimp doesn't start.
I searched for libmypaint - found oneclick 1.5.1 - tried, but it didn't install because of an rpm error. 1.4.0 is only available for OS 15.2 (haven't tried to install it, should I - on 15.1?)
my questions:
- How can I install Gimp 2.10 on 15.1 and resolve the missing libmypaint-1.4? - or alternatively: how can I make Gimp 2.8 to handle webp graphics?
Thanks for your help!
Daniel
On 28/04/2020 12.37, Daniel Bauer wrote:
Hello,
I need to be able to read and safe webp graphics in gimp. I am on Opensuse 15.1 and that comes with gimp 2.8 which doesn't support this format, it is (as I read) included from Gimp 2.9.
I found oneclick install for Gimp 2.10 for OS 15.1. Tried it. It failed because libmypaint-1.4 cant be found.
First thing: *never* use oneclick install.
Instead, go to the search page, and find the package:
https://software.opensuse.org/package/gimp
Locate the appropriate repo. Avoid the community repos, which leaves the experimental repos. There is only one: "graphics". Click on "expert" download, openSUSE, then click "Add repository and install manually".
Which for 15.1 means:
zypper addrepo https://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/graph... zypper refresh zypper install gimp
Instead of the last two, fire up YaST.
I installed without, but then Gimp doesn't start.
I searched for libmypaint - found oneclick 1.5.1 - tried, but it didn't install because of an rpm error. 1.4.0 is only available for OS 15.2 (haven't tried to install it, should I - on 15.1?)
Well, the graphics repo from above has it. You do not say what repo you tried. If it gives an error, what error?
Am 28.04.20 um 13:37 schrieb Carlos E. R.:
On 28/04/2020 12.37, Daniel Bauer wrote:
Hello,
I need to be able to read and safe webp graphics in gimp. I am on Opensuse 15.1 and that comes with gimp 2.8 which doesn't support this format, it is (as I read) included from Gimp 2.9.
I found oneclick install for Gimp 2.10 for OS 15.1. Tried it. It failed because libmypaint-1.4 cant be found.
First thing: *never* use oneclick install.
Instead, go to the search page, and find the package:
https://software.opensuse.org/package/gimp
Locate the appropriate repo. Avoid the community repos, which leaves the experimental repos. There is only one: "graphics". Click on "expert" download, openSUSE, then click "Add repository and install manually".
Which for 15.1 means:
zypper addrepo https://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/graph... zypper refresh zypper install gimp
Instead of the last two, fire up YaST.
I installed without, but then Gimp doesn't start.
I searched for libmypaint - found oneclick 1.5.1 - tried, but it didn't install because of an rpm error. 1.4.0 is only available for OS 15.2 (haven't tried to install it, should I - on 15.1?)
Well, the graphics repo from above has it. You do not say what repo you tried. If it gives an error, what error?
Thank you Carlos, but still the same error:
All repositories have been refreshed. venus:~ # zypper install gimp Loading repository data... Reading installed packages... 'gimp' is already installed. There is an update candidate for 'gimp' from vendor 'obs://build.opensuse.org/graphics', while the current vendor is 'openSUSE'. Use 'zypper install gimp-2.10.12-lp151.1.5.x86_64' to install this candidate. Resolving package dependencies...
Nothing to do.
venus:~ # zypper install gimp-2.10.12-lp151.1.5.x86_64 Loading repository data... Reading installed packages... Resolving package dependencies...
Problem: nothing provides libmypaint-1.4.so.0()(64bit) needed by gimp-2.10.12-lp151.1.5.x86_64 Solution 1: do not install gimp-2.10.12-lp151.1.5.x86_64 Solution 2: break gimp-2.10.12-lp151.1.5.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/c/d/?] (c):
* Daniel Bauer linux@daniel-bauer.com [04-28-20 08:03]:
Am 28.04.20 um 13:37 schrieb Carlos E. R.:
On 28/04/2020 12.37, Daniel Bauer wrote:
Hello,
I need to be able to read and safe webp graphics in gimp. I am on Opensuse 15.1 and that comes with gimp 2.8 which doesn't support this format, it is (as I read) included from Gimp 2.9.
I found oneclick install for Gimp 2.10 for OS 15.1. Tried it. It failed because libmypaint-1.4 cant be found.
First thing: *never* use oneclick install.
Instead, go to the search page, and find the package:
https://software.opensuse.org/package/gimp
Locate the appropriate repo. Avoid the community repos, which leaves the experimental repos. There is only one: "graphics". Click on "expert" download, openSUSE, then click "Add repository and install manually".
Which for 15.1 means:
zypper addrepo https://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/graph... zypper refresh zypper install gimp
Instead of the last two, fire up YaST.
I installed without, but then Gimp doesn't start.
I searched for libmypaint - found oneclick 1.5.1 - tried, but it didn't install because of an rpm error. 1.4.0 is only available for OS 15.2 (haven't tried to install it, should I - on 15.1?)
Well, the graphics repo from above has it. You do not say what repo you tried. If it gives an error, what error?
Thank you Carlos, but still the same error:
All repositories have been refreshed. venus:~ # zypper install gimp Loading repository data... Reading installed packages... 'gimp' is already installed. There is an update candidate for 'gimp' from vendor 'obs://build.opensuse.org/graphics', while the current vendor is 'openSUSE'. Use 'zypper install gimp-2.10.12-lp151.1.5.x86_64' to install this candidate. Resolving package dependencies...
Nothing to do.
venus:~ # zypper install gimp-2.10.12-lp151.1.5.x86_64 Loading repository data... Reading installed packages... Resolving package dependencies...
Problem: nothing provides libmypaint-1.4.so.0()(64bit) needed by gimp-2.10.12-lp151.1.5.x86_64 Solution 1: do not install gimp-2.10.12-lp151.1.5.x86_64 Solution 2: break gimp-2.10.12-lp151.1.5.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/c/d/?] (c):
You need to add the repo which contains the needed libmypaint as Carlos wrote or you will continue to get the missing package error. Zypper cannot find packages when it does know know the repo's containing the package, ie: add the necessary repo
re-read Carlos' post.
Am 28.04.20 um 14:14 schrieb Patrick Shanahan:
- Daniel Bauer linux@daniel-bauer.com [04-28-20 08:03]:
Am 28.04.20 um 13:37 schrieb Carlos E. R.:
On 28/04/2020 12.37, Daniel Bauer wrote:
Hello,
I need to be able to read and safe webp graphics in gimp. I am on Opensuse 15.1 and that comes with gimp 2.8 which doesn't support this format, it is (as I read) included from Gimp 2.9.
I found oneclick install for Gimp 2.10 for OS 15.1. Tried it. It failed because libmypaint-1.4 cant be found.
First thing: *never* use oneclick install.
Instead, go to the search page, and find the package:
https://software.opensuse.org/package/gimp
Locate the appropriate repo. Avoid the community repos, which leaves the experimental repos. There is only one: "graphics". Click on "expert" download, openSUSE, then click "Add repository and install manually".
Which for 15.1 means:
zypper addrepo https://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/graph... zypper refresh zypper install gimp
Instead of the last two, fire up YaST.
I installed without, but then Gimp doesn't start.
I searched for libmypaint - found oneclick 1.5.1 - tried, but it didn't install because of an rpm error. 1.4.0 is only available for OS 15.2 (haven't tried to install it, should I - on 15.1?)
Well, the graphics repo from above has it. You do not say what repo you tried. If it gives an error, what error?
Thank you Carlos, but still the same error:
All repositories have been refreshed. venus:~ # zypper install gimp Loading repository data... Reading installed packages... 'gimp' is already installed. There is an update candidate for 'gimp' from vendor 'obs://build.opensuse.org/graphics', while the current vendor is 'openSUSE'. Use 'zypper install gimp-2.10.12-lp151.1.5.x86_64' to install this candidate. Resolving package dependencies...
Nothing to do.
venus:~ # zypper install gimp-2.10.12-lp151.1.5.x86_64 Loading repository data... Reading installed packages... Resolving package dependencies...
Problem: nothing provides libmypaint-1.4.so.0()(64bit) needed by gimp-2.10.12-lp151.1.5.x86_64 Solution 1: do not install gimp-2.10.12-lp151.1.5.x86_64 Solution 2: break gimp-2.10.12-lp151.1.5.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/c/d/?] (c):
You need to add the repo which contains the needed libmypaint as Carlos wrote or you will continue to get the missing package error. Zypper cannot find packages when it does know know the repo's containing the package, ie: add the necessary repo
re-read Carlos' post.
I added that repo Carlos mentioned. This repo contains version 1.5 of libmypaint, but not 1.4 as required by gimp of the same repo
On 28/04/2020 14.32, Daniel Bauer wrote:
I added that repo Carlos mentioned. This repo contains version 1.5 of libmypaint, but not 1.4 as required by gimp of the same repo
Bugzilla.
Or install 1.5 breaking that particular dep and see what happens.
Am 28.04.20 um 14:47 schrieb Carlos E. R.:
On 28/04/2020 14.32, Daniel Bauer wrote:
I added that repo Carlos mentioned. This repo contains version 1.5 of libmypaint, but not 1.4 as required by gimp of the same repo
Bugzilla.
https://bugzilla.opensuse.org/show_bug.cgi?id=1170692
Or install 1.5 breaking that particular dep and see what happens.
doesn't work :-(
On 28/04/2020 15.13, Daniel Bauer wrote:
Am 28.04.20 um 14:47 schrieb Carlos E. R.:
On 28/04/2020 14.32, Daniel Bauer wrote:
I added that repo Carlos mentioned. This repo contains version 1.5 of libmypaint, but not 1.4 as required by gimp of the same repo
Bugzilla.
https://bugzilla.opensuse.org/show_bug.cgi?id=1170692
Or install 1.5 breaking that particular dep and see what happens.
doesn't work :-(
You might try with libmypaint from 15.2. It is version 1.4
Warning: do not add the 15.2 repo, just download the packages to a local directory and add that instead. Download gimp and the deps.
Am 28.04.20 um 15:19 schrieb Carlos E. R.:
On 28/04/2020 15.13, Daniel Bauer wrote:
Am 28.04.20 um 14:47 schrieb Carlos E. R.:
On 28/04/2020 14.32, Daniel Bauer wrote:
I added that repo Carlos mentioned. This repo contains version 1.5 of libmypaint, but not 1.4 as required by gimp of the same repo
Bugzilla.
https://bugzilla.opensuse.org/show_bug.cgi?id=1170692
Or install 1.5 breaking that particular dep and see what happens.
doesn't work :-(
You might try with libmypaint from 15.2. It is version 1.4
Warning: do not add the 15.2 repo, just download the packages to a local directory and add that instead. Download gimp and the deps.
I can't find a non-source rpm. I searched https://software.opensuse.org/download/package?package=libmypaint&projec...
Only a source rpm is available. The last "three million times" I tried to compile something I failed. So this is no alternative for me...
Hello,
In the Message;
Subject : Re: [opensuse] installing Gimp 2.10 on OS 15.1 failed (or: how to get webp for gimp?) Message-ID : fe23e972-1903-7e5e-bafa-4184a41d5f08@daniel-bauer.com Date & Time: Tue, 28 Apr 2020 15:36:20 +0200
[DB] == Daniel Bauer linux@daniel-bauer.com has written:
[...] DB> > Warning: do not add the 15.2 repo, just download the packages to a local DB> > directory and add that instead. Download gimp and the deps.
DB> I can't find a non-source rpm. DB> I searched DB> https://software.opensuse.org/download/package?package=libmypaint&projec...
DB> Only a source rpm is available. The last "three million times" I tried to DB> compile something I failed. So this is no alternative for me...
Yes, the compilation of libmypaint 1.4.0 is difficult. I didn't investigate the reason, that is, I searched the easier solution.
Please compile gimp 2.10.12-lp151.1.5.src.rpm with libmypaint 1.5.1. It's easier than compiling the libmypaint 1.4.1.
Regards,
--- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "Three young men died for Rationalization. Yet, Margaret Bloody Thatcher LIVES!" 'Brassed Off'
Op 28-04-2020 om 15:19 schreef Carlos E. R.:
On 28/04/2020 15.13, Daniel Bauer wrote:
Am 28.04.20 um 14:47 schrieb Carlos E. R.:
On 28/04/2020 14.32, Daniel Bauer wrote:
I added that repo Carlos mentioned. This repo contains version 1.5 of libmypaint, but not 1.4 as required by gimp of the same repo
Bugzilla.
https://bugzilla.opensuse.org/show_bug.cgi?id=1170692
Or install 1.5 breaking that particular dep and see what happens.
doesn't work :-(
You might try with libmypaint from 15.2. It is version 1.4
Warning: do not add the 15.2 repo, just download the packages to a local directory and add that instead. Download gimp and the deps.
I found libmypaint 1.4 here: https://opensuse.pkgs.org/15.2/opensuse-oss-x86_64/libmypaint-1_4-0-1.4.0-lp...
Installed it, gimp 2.10 too. Exporting 'as webp' works!
Am 28.04.20 um 15:37 schrieb Harrie Baken:
Op 28-04-2020 om 15:19 schreef Carlos E. R.:
On 28/04/2020 15.13, Daniel Bauer wrote:
Am 28.04.20 um 14:47 schrieb Carlos E. R.:
On 28/04/2020 14.32, Daniel Bauer wrote:
I added that repo Carlos mentioned. This repo contains version 1.5 of libmypaint, but not 1.4 as required by gimp of the same repo
Bugzilla.
https://bugzilla.opensuse.org/show_bug.cgi?id=1170692
Or install 1.5 breaking that particular dep and see what happens.
doesn't work :-(
You might try with libmypaint from 15.2. It is version 1.4
Warning: do not add the 15.2 repo, just download the packages to a local directory and add that instead. Download gimp and the deps.
I found libmypaint 1.4 here: https://opensuse.pkgs.org/15.2/opensuse-oss-x86_64/libmypaint-1_4-0-1.4.0-lp...
Installed it, gimp 2.10 too. Exporting 'as webp' works!
Thank you. I did the same and it works :-)
I have seen that rpm before but I was afraid to install it as it is not "official". After you pointed on it I simply risked it, I hope I did not due something bad...
However I can now work with the new version.
On 28/04/2020 08:32, Daniel Bauer wrote:
I added that repo Carlos mentioned. This repo contains version 1.5 of libmypaint, but not 1.4 as required by gimp of the same repo
I recall going through this self same idiocy myself. I had to resolve it by first deleting old versions of gimp and mypaint then by hand downloading and installing libmypaint_1_4-0 from the graphics repository, and then zyppering in gimp
Information for package libmypaint-1_4-0: ----------------------------------------- Repository : @System Name : libmypaint-1_4-0 Version : 1.4.0-lp151.15.2 Arch : x86_64 Vendor : obs://build.opensuse.org/graphics Installed Size : 81.9 KiB Installed : Yes Status : up-to-date Source package : libmypaint-1.4.0-lp151.15.2.src Summary : A brushstroke creation library
it seems that version is no longer in the repository :-( I can't account for why.
Am 11.05.20 um 13:45 schrieb Anton Aylward:
On 28/04/2020 08:32, Daniel Bauer wrote:
I added that repo Carlos mentioned. This repo contains version 1.5 of libmypaint, but not 1.4 as required by gimp of the same repo
I recall going through this self same idiocy myself. I had to resolve it by first deleting old versions of gimp and mypaint then by hand downloading and installing libmypaint_1_4-0 from the graphics repository, and then zyppering in gimp
Information for package libmypaint-1_4-0:
Repository : @System Name : libmypaint-1_4-0 Version : 1.4.0-lp151.15.2 Arch : x86_64 Vendor : obs://build.opensuse.org/graphics Installed Size : 81.9 KiB Installed : Yes Status : up-to-date Source package : libmypaint-1.4.0-lp151.15.2.src Summary : A brushstroke creation library
it seems that version is no longer in the repository :-( I can't account for why.
Anyway, gimp-2.10 isn't worth install. It is /extremely/ slow, in fact not usable.
It has some new features that I'd love to have, but is so slow that I had to deinstall it and reinstall gimp-2.8. A simple adjust of a curve, for example, takes like a minute, you can see how it generates the effect line by line.
You can search for "gimp 2.10 slow" and find countless reports.
On 05/11/2020 07:29 AM, Daniel Bauer wrote:
Anyway, gimp-2.10 isn't worth install. It is /extremely/ slow, in fact not usable.
It has some new features that I'd love to have, but is so slow that I had to deinstall it and reinstall gimp-2.8. A simple adjust of a curve, for example, takes like a minute, you can see how it generates the effect line by line.
You can search for "gimp 2.10 slow" and find countless reports.
This is fixable -- somehow Arch has it running on par with 2.8, but... there is another huge pain in the ass that some kid with his box of crayons couldn't leave alone....
The Layers/Gradients dialog on the right is completely flipped upside down. For a decade+ plus it was layers, masks, etc.. up top and brushes, gradients on the bottom. I filed a bug against this when 2.10 came out:
https://gitlab.gnome.org/GNOME/gimp/issues/3411
Despite being very surprised that the change had even happened and the lead expressing there had better be a darn good reason for the change -- no reason was forthcoming and nothing was fixed. If you have used gimp before you will notice the change immediately. You can spend a few minutes and move the "features" from the bottom back to the top and vice-versa -- but there is no other easy way to fix it....
Hi Anton, others
On Mon, 2020-05-11 at 07:45 -0400, Anton Aylward wrote:
On 28/04/2020 08:32, Daniel Bauer wrote:
I added that repo Carlos mentioned. This repo contains version 1.5 of libmypaint, but not 1.4 as required by gimp of the same repo
I recall going through this self same idiocy myself.
May be if I explain how this problem originates, I'll hopefully convince you that this isn't some "idiocy" on part of obs://graphics maintainers or anyone else, but rather an example of why installing packages from the devel repositories is not a recommended way of getting an "updated" application while continuing to use Leap:X as the base OS.
The complaint about libmypaint is but a red herring. Rather, since obs://graphics serves as a devel project for openSUSE:Factory -- __not__ as a backport for Leap:15.X, libraries therein continue to be upgraded to their latest versions and pushed to openSUSE:Factory. One of these -- babl -- as part of its upgrade to version 0.1.70, switched to using meson >= 0.50 as its only build system (by upstream). As soon as this was checked into graphics, it stopped building for Leap:15.1 and became unresolvable. Why? Because Leap:15.1 only has meson 0.46 in its official repo and obs://graphics doesn't have meson >= 0.50.0 for Leap either (rightly so, it's not a graphics library/application but a core build system tool).
Gimp also has a dependency on babl (in addition to libmypaint), so when babl became unresolvable in the graphics project for Leap:15.1, so did gimp, and it has been thus since. The last successful build of gimp for Leap:15.1 happened with babl version 0.1.66 (last pre-0.1.70 version), when the graphics project still had libmypaint version 1.4 which gimp linked against. In the meanwhile, libmypaint, which still builds just fine even on Leap 15.1 has continued being updated (now at v1.5.1, soon to-be v1.6.0) in the project (and sent to Factory), so version 1.4 is no longer available for any oS version from obs://graphics.
Fwiw, gimp 2.10.x is in Leap:15.2 and, of course, has been in Tumbleweed for a while.
it seems that version is no longer in the repository :-( I can't account for why.
I hope this helps you understand why.
Cheers,
Hello together, I have been building a version of gimp 2.10 for openSUSE leap 15.1 from scratch, resolving all dependencies by creating/compiling the required packages. It's been a certain effort, but I have 2.10 now and I cannot state that it is very slow - but maybe I have a different usecase than others do. In contrast I really like several features of the new version. If anyone would be interested in a leap 15.1 gimp 2.10 with _all_ packages that need an update - just let me know. I can package my archive of rpm's and upload it so whoever is interested in could download & install the rpms. Best
Dieter
Am Montag, 11. Mai 2020, 19:00:55 CEST schrieb Atri Bhattacharya:
Hi Anton, others
On Mon, 2020-05-11 at 07:45 -0400, Anton Aylward wrote:
On 28/04/2020 08:32, Daniel Bauer wrote:
I added that repo Carlos mentioned. This repo contains version 1.5 of libmypaint, but not 1.4 as required by gimp of the same repo
I recall going through this self same idiocy myself.
May be if I explain how this problem originates, I'll hopefully convince you that this isn't some "idiocy" on part of obs://graphics maintainers or anyone else, but rather an example of why installing
******
On 11/05/2020 19.00, Atri Bhattacharya wrote:
Hi Anton, others
On Mon, 2020-05-11 at 07:45 -0400, Anton Aylward wrote:
On 28/04/2020 08:32, Daniel Bauer wrote:
I added that repo Carlos mentioned. This repo contains version 1.5 of libmypaint, but not 1.4 as required by gimp of the same repo
I recall going through this self same idiocy myself.
May be if I explain how this problem originates, I'll hopefully convince you that this isn't some "idiocy" on part of obs://graphics maintainers or anyone else, but rather an example of why installing packages from the devel repositories is not a recommended way of getting an "updated" application while continuing to use Leap:X as the base OS.
There is a problem here. Repositories lack a description or comment that explains what is the use case of each repository. We only know that they are either "home" or "experimental". We do not know if it is a "devel" repo or that we should not use it - because the view as user is that if its published, we can use it.
On Mon, 2020-05-11 at 20:10 +0200, Carlos E. R. wrote:
On 11/05/2020 19.00, Atri Bhattacharya wrote:
May be if I explain how this problem originates, I'll hopefully convince you that this isn't some "idiocy" on part of obs://graphics maintainers or anyone else, but rather an example of why installing packages from the devel repositories is not a recommended way of getting an "updated" application while continuing to use Leap:X as the base OS.
There is a problem here. Repositories lack a description or comment that explains what is the use case of each repository.
That is literally what the project's description says on the front page [1]: "It is a devel project for openSUSE:Factory."
We only know that they are either "home" or "experimental". We do not know if it is a "devel" repo or that we should not use it - because the view as user is that if its published, we can use it.
I don't know how this view has proliferated, but it needs reiterating that installing packages from random repositories is not recommended in any way. Indeed, the package search [2] tries to reinforce this by burying packages from non-standard repositories as deeply as possible, and even then marking them as experimental.
[1] https://build.opensuse.org/project/show/graphics [2] https://software.opensuse.org/package/gimp
On 11/05/2020 20.31, Atri Bhattacharya wrote:
On Mon, 2020-05-11 at 20:10 +0200, Carlos E. R. wrote:
On 11/05/2020 19.00, Atri Bhattacharya wrote:
May be if I explain how this problem originates, I'll hopefully convince you that this isn't some "idiocy" on part of obs://graphics maintainers or anyone else, but rather an example of why installing packages from the devel repositories is not a recommended way of getting an "updated" application while continuing to use Leap:X as the base OS.
There is a problem here. Repositories lack a description or comment that explains what is the use case of each repository.
That is literally what the project's description says on the front page [1]: "It is a devel project for openSUSE:Factory."
Not valid for users. It has to say it inside YaST, zypper, and here, search page:
https://software.opensuse.org/package/gimp
and inside the files in "/etc/zypp/repos.d/" so that YaST displays the info. Hidden in the OBS is only seen by developers, not users.
Sorry.
We only know that they are either "home" or "experimental". We do not know if it is a "devel" repo or that we should not use it - because the view as user is that if its published, we can use it.
I don't know how this view has proliferated, but it needs reiterating that installing packages from random repositories is not recommended in any way. Indeed, the package search [2] tries to reinforce this by burying packages from non-standard repositories as deeply as possible, and even then marking them as experimental.
[1] https://build.opensuse.org/project/show/graphics [2] https://software.opensuse.org/package/gimp
So, where do we get them from? From Debian, Ubuntu perhaps?
If users should not use packages from repositories, just do not publish them. Problem solved.
* Carlos E. R. robin.listas@telefonica.net [05-11-20 17:06]: [...]
So, where do we get them from? From Debian, Ubuntu perhaps?
If users should not use packages from repositories, just do not publish them. Problem solved.
so you would restrict everyone from all repositories except those which you deem "official".
terrible idea.
If one is not capable of admin'ing their system, they should not be playing around with things they do not understand, or should ask first.
There also would be no trials of development projects and/or new apps.
one cannot protect one from himself short of disconnecting the power source and maiming the connector.
On 11/05/2020 17:48, Patrick Shanahan wrote:
- Carlos E. R. robin.listas@telefonica.net [05-11-20 17:06]:
[...]
So, where do we get them from? From Debian, Ubuntu perhaps?
If users should not use packages from repositories, just do not publish them. Problem solved.
so you would restrict everyone from all repositories except those which you deem "official".
I think he was being sarcastic.
* Anton Aylward opensuse@antonaylward.com [05-11-20 17:58]:
On 11/05/2020 17:48, Patrick Shanahan wrote:
- Carlos E. R. robin.listas@telefonica.net [05-11-20 17:06]:
[...]
So, where do we get them from? From Debian, Ubuntu perhaps?
If users should not use packages from repositories, just do not publish them. Problem solved.
so you would restrict everyone from all repositories except those which you deem "official".
I think he was being sarcastic.
remember to bet your small change first :)
I really do not think so.
On 11/05/2020 23.52, Anton Aylward wrote:
On 11/05/2020 17:48, Patrick Shanahan wrote:
- Carlos E. R. robin.listas@telefonica.net [05-11-20 17:06]: [...]
So, where do we get them from? From Debian, Ubuntu perhaps?
If users should not use packages from repositories, just do not publish them. Problem solved.
so you would restrict everyone from all repositories except those which you deem "official".
I think he was being sarcastic.
I was. ;-)
On 12/05/2020 05:24, Carlos E. R. wrote:
On 11/05/2020 23.52, Anton Aylward wrote:
On 11/05/2020 17:48, Patrick Shanahan wrote:
- Carlos E. R. robin.listas@telefonica.net [05-11-20 17:06]:
[...]
So, where do we get them from? From Debian, Ubuntu perhaps?
If users should not use packages from repositories, just do not publish them. Problem solved.
so you would restrict everyone from all repositories except those which you deem "official".
I think he was being sarcastic.
I was. ;-)
Patrick: I don't think there was a cultural/linguistic problem here.
I'm not sure that i would recognise <irony> on his part but the <sarcasm> came though quite clearly since it involved being outrageously ridiculous.
<sidebar> I get to wonder if any post here that mentions ubuntu is outrageously ridiculous, even the ones that aren't sarcastic. Some, though, might will be ironic. </sidebar>
On Mon, 2020-05-11 at 23:04 +0200, Carlos E. R. wrote:
On 11/05/2020 20.31, Atri Bhattacharya wrote:
On Mon, 2020-05-11 at 20:10 +0200, Carlos E. R. wrote:
On 11/05/2020 19.00, Atri Bhattacharya wrote:
May be if I explain how this problem originates, I'll hopefully convince you that this isn't some "idiocy" on part of obs://graphics maintainers or anyone else, but rather an example of why installing packages from the devel repositories is not a recommended way of getting an "updated" application while continuing to use Leap:X as the base OS.
There is a problem here. Repositories lack a description or comment that explains what is the use case of each repository.
That is literally what the project's description says on the front page [1]: "It is a devel project for openSUSE:Factory."
Not valid for users. It has to say it inside YaST, zypper, and here, search page:
https://software.opensuse.org/package/gimp
and inside the files in "/etc/zypp/repos.d/" so that YaST displays the info. Hidden in the OBS is only seen by developers, not users.
YaST, zypper, or any other package interface do not come with additional repositories pre-configured. You __choose__ to add them, either manually using `zypper addrepo` or via the package search website, which, to be fair, makes it as difficult as possible for you to do so. If that or the "experimental" sign on these packages in the search result does not deter a user, nothing will. One assumes they know what they are doing and on their own if this possibly breaks their system.
Sorry.
We only know that they are either "home" or "experimental". We do not know if it is a "devel" repo or that we should not use it - because the view as user is that if its published, we can use it.
I don't know how this view has proliferated, but it needs reiterating that installing packages from random repositories is not recommended in any way. Indeed, the package search [2] tries to reinforce this by burying packages from non-standard repositories as deeply as possible, and even then marking them as experimental.
[1] https://build.opensuse.org/project/show/graphics [2] https://software.opensuse.org/package/gimp
So, where do we get them from?
I think gimp.org offers flatpack packages [1]. If you absolutely need version 2.10.x, that may be one way to get it.
From Debian, Ubuntu perhaps?
I'm going to ignore this unnecessarily provocative line...
If users should not use packages from repositories, just do not publish them. Problem solved.
They are published with a view that advanced users may be able to make use of them, as long as they know what they are doing. That is, they understand how these devel projects work, are not shy to look at the build status of a package in a devel project and understand why if something isn't working, and perhaps to try and fix them. Often it works out with nary a worry. I am trying to explain why sometimes it does not and why in certain cases it can be rather difficult to fix.
That said, it would probably be nice to have a mechanism to wipe binaries from a repo if they are no longer installable for whatever reason. But I suppose this would be rather difficult to implement considering the vast number of repositories and packages in those repositories that the OBS currently hosts.
[1] https://www.gimp.org/downloads/
On 12/05/2020 00.06, Atri Bhattacharya wrote:
On Mon, 2020-05-11 at 23:04 +0200, Carlos E. R. wrote:
On 11/05/2020 20.31, Atri Bhattacharya wrote:
On Mon, 2020-05-11 at 20:10 +0200, Carlos E. R. wrote:
On 11/05/2020 19.00, Atri Bhattacharya wrote:
May be if I explain how this problem originates, I'll hopefully convince you that this isn't some "idiocy" on part of obs://graphics maintainers or anyone else, but rather an example of why installing packages from the devel repositories is not a recommended way of getting an "updated" application while continuing to use Leap:X as the base OS.
There is a problem here. Repositories lack a description or comment that explains what is the use case of each repository.
That is literally what the project's description says on the front page [1]: "It is a devel project for openSUSE:Factory."
Not valid for users. It has to say it inside YaST, zypper, and here, search page:
https://software.opensuse.org/package/gimp
and inside the files in "/etc/zypp/repos.d/" so that YaST displays the info. Hidden in the OBS is only seen by developers, not users.
YaST, zypper, or any other package interface do not come with additional repositories pre-configured. You __choose__ to add them, either manually using `zypper addrepo` or via the package search website, which, to be fair, makes it as difficult as possible for you to do so. If that or the "experimental" sign on these packages in the search result does not deter a user, nothing will. One assumes they know what they are doing and on their own if this possibly breaks their system.
Sorry.
We only know that they are either "home" or "experimental". We do not know if it is a "devel" repo or that we should not use it - because the view as user is that if its published, we can use it.
I don't know how this view has proliferated, but it needs reiterating that installing packages from random repositories is not recommended in any way. Indeed, the package search [2] tries to reinforce this by burying packages from non-standard repositories as deeply as possible, and even then marking them as experimental.
[1] https://build.opensuse.org/project/show/graphics [2] https://software.opensuse.org/package/gimp
So, where do we get them from?
I think gimp.org offers flatpack packages [1]. If you absolutely need version 2.10.x, that may be one way to get it.
From Debian, Ubuntu perhaps?
I'm going to ignore this unnecessarily provocative line...
If users should not use packages from repositories, just do not publish them. Problem solved.
They are published with a view that advanced users may be able to make use of them, as long as they know what they are doing. That is, they understand how these devel projects work, are not shy to look at the build status of a package in a devel project and understand why if something isn't working, and perhaps to try and fix them. Often it works out with nary a worry. I am trying to explain why sometimes it does not and why in certain cases it can be rather difficult to fix.
That said, it would probably be nice to have a mechanism to wipe binaries from a repo if they are no longer installable for whatever reason. But I suppose this would be rather difficult to implement considering the vast number of repositories and packages in those repositories that the OBS currently hosts.
You are not listening, sorry, so I'm going to ignore most of this. Sorry, but you seem to be ignorant of how users use openSUSE. Not talking of devs, but plain users.
On Tue, 2020-05-12 at 11:48 +0200, Carlos E. R. wrote:
On 12/05/2020 00.06, Atri Bhattacharya wrote:
I think gimp.org offers flatpack packages [1]. If you absolutely need version 2.10.x, that may be one way to get it.
From Debian, Ubuntu perhaps?
I'm going to ignore this unnecessarily provocative line...
If users should not use packages from repositories, just do not publish them. Problem solved.
They are published with a view that advanced users may be able to make use of them, as long as they know what they are doing. That is, they understand how these devel projects work, are not shy to look at the build status of a package in a devel project and understand why if something isn't working, and perhaps to try and fix them. Often it works out with nary a worry. I am trying to explain why sometimes it does not and why in certain cases it can be rather difficult to fix.
That said, it would probably be nice to have a mechanism to wipe binaries from a repo if they are no longer installable for whatever reason. But I suppose this would be rather difficult to implement considering the vast number of repositories and packages in those repositories that the OBS currently hosts.
You are not listening, sorry, so I'm going to ignore most of this.
Go figure!
Sorry, but you seem to be ignorant of how users use openSUSE. Not talking of devs, but plain users.
With due respect, you are not an authority on how openSUSE users use the distro either.
Anyway, last comment from my side on this:
* "Plain user" wants to install gimp on Leap: do nothing if it's pre- installed, if not open YaST or gnome-software or KDE Discover, search for gimp, and install it. * Advanced user: go to https://software.opensuse.org/package/gimp and try "Show gimp for other distributions ==> Show experimental packages" and proceed from there, with the knowledge that you may end up with a broken package that may or may not work or, worse, a broken system. But you are an advanced user, and you can fix it or rollback your system.
You are not going to end up with GIMP from the graphics repository unless you go fishing for it.
On 12/05/2020 07:40, Atri Bhattacharya wrote:
You are not going to end up with GIMP from the graphics repository unless you go fishing for it.
!FALSE!
I'm using the graphics repository because I want the latest version of Darktable, which I've mentioned here a number of times and discussed with other photographically-inclined subscribers to this list. it install from there without problems. I never went fishing for gimp. Gimp is not my first choice as a photo editor, it is the third arrow in my photo-editing quiver after Darktable and RawThreapee and neck-and-neck with (yes it is slow but its written in Java) Lightzone.
I don't naturally think in 'layers'. I grew up with a real - physical, chemical, blacked out - darkroom, using exposure, filters dodging and masking and more the way Darktable works.
But Gimp is there. I think you are being ridiculous about 'expert' and 'devel' when the people who want this stuff want it for making use of the application.
Daniel, misquoting Dr McCoy, might say "I'm a photographer, not <strike> an engineer</strike> a computer geek.
Anton Aylward wrote:
On 12/05/2020 07:40, Atri Bhattacharya wrote:
You are not going to end up with GIMP from the graphics repository unless you go fishing for it.
!FALSE!
I'm using the graphics repository because I want the latest version of Darktable,
Anton -
You are not going to end up with GIMP from the graphics repository unless you go fishing for it ["it" being the graphics repository] .
On Tue, 2020-05-12 at 08:10 -0400, Anton Aylward wrote:
On 12/05/2020 07:40, Atri Bhattacharya wrote:
You are not going to end up with GIMP from the graphics repository unless you go fishing for it.
!FALSE!
I'm using the graphics repository because I want the latest version of Darktable, which I've mentioned here a number of times and discussed with other photographically-inclined subscribers to this list. it install from there without problems. I never went fishing for gimp. Gimp is not my first choice as a photo editor, it is the third arrow in my photo-editing quiver after Darktable and RawThreapee and neck-and-neck with (yes it is slow but its written in Java) Lightzone.
What does gimp have to do with darktable? If you install darktable from graphics repo (which, again, **not recommended**) you will get darktable from the graphics repo. You still won't get gimp from there, unless you ask zypper to explicitly allow vendor-changes and try to upgrade gimp again.
The best way to get latest versions of applications on openSUSE is to use Tumbleweed.
On 12/05/2020 08:24, Atri Bhattacharya wrote:
The best way to get latest versions of applications on openSUSE is to use Tumbleweed.
Not so. Use Tumbleweed and you get experimental versions of everything that makes up openSUSE rather than the latest and determined stable versions of specifics.
If I wanted latest/unstable version of Darktable there is a repository for that; I can pull HEAD from git or similar. I can compile that myself, manually apply patches, only I don't/cant (since I don't have the compiler suite or use build) git://github.com/darktable-org/darktable.git.
But as I say, I'm not a developer, not interested in being a developer, not interested in the 'experimental'.
Darktable 3..0.2 (from last year) is quite stable, thank you and is from the graphics repository.
* Anton Aylward opensuse@antonaylward.com [05-12-20 09:27]:
On 12/05/2020 08:24, Atri Bhattacharya wrote:
The best way to get latest versions of applications on openSUSE is to use Tumbleweed.
Not so. Use Tumbleweed and you get experimental versions of everything that makes up openSUSE rather than the latest and determined stable versions of specifics.
If I wanted latest/unstable version of Darktable there is a repository for that; I can pull HEAD from git or similar. I can compile that myself, manually apply patches, only I don't/cant (since I don't have the compiler suite or use build) git://github.com/darktable-org/darktable.git.
yes Dorothy, there is more than one way to skin a cat!
but compiling yourself is much more involved than utilizing a repo with the package already built.
zypper -v si -d darktable
will provide you with the build environment necessary for darktable, or it did for me.
But as I say, I'm not a developer, not interested in being a developer, not interested in the 'experimental'.
Darktable 3..0.2 (from last year) is quite stable, thank you and is from the graphics repository.
but darktable (note lower-case) "master" is also availabe in from the "graphics" repo. https://download.opensuse.org/repositories/graphics:/darktable:/master/openS... https://download.opensuse.org/repositories/graphics:/darktable:/master/openS...
Op dinsdag 12 mei 2020 15:25:34 CEST schreef Anton Aylward:
Not so. Use Tumbleweed and you get experimental versions of everything that makes up openSUSE rather than the latest and determined stable versions of specifics.
Completely wrong. You get latest reviewed and openQA tested versions, where the entire distro is tested and released over and over again. No KDE beta or GNOME Unstable will land in TW f.e.
On Tue, 2020-05-12 at 09:25 -0400, Anton Aylward wrote:
On 12/05/2020 08:24, Atri Bhattacharya wrote:
The best way to get latest versions of applications on openSUSE is to use Tumbleweed.
Not so. Use Tumbleweed and you get experimental versions of everything that makes up openSUSE rather than the latest and determined stable versions of specifics.
If I may, that seems to be your assumption, and a rather interesting one. I would love to know how you came to believe that. If from some official channel, it would be worth correcting this misinformation.
Except in a very few cases, packages in TW are only updated when the upstream for that application tags and releases a stable version. In very rare cases, when upstream hasn't released a tagged version in a long while, a packager might bundle up all the latest commits from upstream git master and push it as version A.B+gitxxxxxxx, especially if that happens to fix a lot of bugs or solve building problems with updated dependencies.
Yes, TW does have bugs sometimes -- which distro doesn't? -- but these are more often than not due to two or more updated packages not living very happily together, rather than the instability of any one package, and, even so, usually fixed soon.
If I wanted latest/unstable version of Darktable there is a repository for that; I can pull HEAD from git or similar. I can compile that myself, manually apply patches, only I don't/cant (since I don't have the compiler suite or use build) git://github.com/darktable-org/darktable.git.
Guess what version of darktable is on TW right now (from official repositories)? Version 3.0.2; not some arbitrary git master commit. GIMP? 2.10.18, not its git master. GNOME? 3.36.2, not the 3.37.x unstable branch in development upstream. Linux kernel? 5.6.x, not the 5.7-RCx in upstream development.
But as I say, I'm not a developer, not interested in being a developer, not interested in the 'experimental'.
One isn't asking you to become a 'developer'! Just try to be educated about where the package you are using comes from and the level at which you need to be able to administer your system should you choose to use outside-of-preconfigured repositories. And warn any user with whom you share this info of the same.
If I wanted every user to be advanced enough to compile their own packages, I wouldn't go make RPM packages for anyone, would I? That's not the level of 'advanced' I am talking about.
Cheers,
On 12/05/2020 05:48, Carlos E. R. wrote:
You are not listening, sorry, so I'm going to ignore most of this. Sorry, but you seem to be ignorant of how users use openSUSE. Not talking of devs, but plain users.
+1
On 11/05/2020 14:31, Atri Bhattacharya wrote:
There is a problem here. Repositories lack a description or comment that explains what is the use case of each repository.
That is literally what the project's description says on the front page [1]: "It is a devel project for openSUSE:Factory."
I'm sorry. How do you get from
http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/
to
https://build.opensuse.org/project/show/graphics
I'm sure many of us who use the various repositories were unaware of the later. What's the algorithm ? How was this publicised, even to us longer term users of the facilities?
* Anton Aylward opensuse@antonaylward.com [05-11-20 17:39]:
On 11/05/2020 14:31, Atri Bhattacharya wrote:
There is a problem here. Repositories lack a description or comment that explains what is the use case of each repository.
That is literally what the project's description says on the front page [1]: "It is a devel project for openSUSE:Factory."
I'm sorry. How do you get from
http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/
to
https://build.opensuse.org/project/show/graphics
I'm sure many of us who use the various repositories were unaware of the later. What's the algorithm ? How was this publicised, even to us longer term users of the facilities?
ever hear about openSUSE build service
Am Montag, 11. Mai 2020, 23:50:30 CEST schrieb Patrick Shanahan:
I'm sorry. How do you get from
http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/
to
https://build.opensuse.org/project/show/graphics
I'm sure many of us who use the various repositories were unaware of the later. What's the algorithm ? How was this publicised, even to us longer term users of the facilities?
ever hear about openSUSE build service
as a regular user? most likely not.
I mean, would you, if you were to drive a Volkswagen, know the adresses of their production plants by heart? No, because what for.
Cheers MH
Op dinsdag 12 mei 2020 07:13:16 CEST schreef Mathias Homann:
Am Montag, 11. Mai 2020, 23:50:30 CEST schrieb Patrick Shanahan:
I'm sorry. How do you get from
http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/
to
https://build.opensuse.org/project/show/graphics
I'm sure many of us who use the various repositories were unaware of the later. What's the algorithm ? How was this publicised, even to us longer term users of the facilities?
ever hear about openSUSE build service
as a regular user? most likely not.
I mean, would you, if you were to drive a Volkswagen, know the adresses of their production plants by heart? No, because what for.
Cheers MH
Come on, we all know about OBS. The messages on searching are clear. If you don't care, that's OK, but don't criticize then.
On 12/05/2020 07.22, Knurpht-openSUSE wrote:
Op dinsdag 12 mei 2020 07:13:16 CEST schreef Mathias Homann:
Am Montag, 11. Mai 2020, 23:50:30 CEST schrieb Patrick Shanahan:
I'm sorry. How do you get from
http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/
to
https://build.opensuse.org/project/show/graphics
I'm sure many of us who use the various repositories were unaware of the later. What's the algorithm ? How was this publicised, even to us longer term users of the facilities?
ever hear about openSUSE build service
as a regular user? most likely not.
I mean, would you, if you were to drive a Volkswagen, know the adresses of their production plants by heart? No, because what for.
Cheers MH
Come on, we all know about OBS. The messages on searching are clear. If you don't care, that's OK, but don't criticize then.
No, we don't. Why should we, if we are not developers?
It is not that we don't care, it is that we simply do not use them. We get the car at the dealer, not at the factory. All the information come to us from the dealer and the books included with the car, and the tools that come with the car.
Op dinsdag 12 mei 2020 11:48:20 CEST schreef Carlos E. R.:
On 12/05/2020 07.22, Knurpht-openSUSE wrote:
Op dinsdag 12 mei 2020 07:13:16 CEST schreef Mathias Homann:
Am Montag, 11. Mai 2020, 23:50:30 CEST schrieb Patrick Shanahan:
I'm sorry. How do you get from
http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/
to
https://build.opensuse.org/project/show/graphics
I'm sure many of us who use the various repositories were unaware of the later. What's the algorithm ? How was this publicised, even to us longer term users of the facilities?
ever hear about openSUSE build service
as a regular user? most likely not.
I mean, would you, if you were to drive a Volkswagen, know the adresses of their production plants by heart? No, because what for.
MH
Come on, we all know about OBS. The messages on searching are clear. If you don't care, that's OK, but don't criticize then.
No, we don't. Why should we, if we are not developers?
It is not that we don't care, it is that we simply do not use them. We get the car at the dealer, not at the factory. All the information come to us from the dealer and the books included with the car, and the tools that come with the car.
To stick to that comparison: you ignore the book that came with the car. And you ignore the factory calling out in the news to all owners of your car's model to immediately have the breaks replaced.
OBS is on the frontpage of our website, software.o.o clearly shows links to build.opensuse.org ( OBS ) for every package in every project that has the 'publish' flag on. Packages from devel: repos will only land in TW / Leap after reviewing, passing openQA etc. If they haven't ( either in TW distribution repos or as Leap updates ), they haven't passed those. This info has been all over the place for years. Atri's posts on this list are definitely not the first elaborating on this. But you and others seem to simply refuse to accept those facts given.
On 12/05/2020 07.13, Mathias Homann wrote:
Am Montag, 11. Mai 2020, 23:50:30 CEST schrieb Patrick Shanahan:
I'm sorry. How do you get from
http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/
to
https://build.opensuse.org/project/show/graphics
I'm sure many of us who use the various repositories were unaware of the later. What's the algorithm ? How was this publicised, even to us longer term users of the facilities?
ever hear about openSUSE build service
as a regular user? most likely not.
I mean, would you, if you were to drive a Volkswagen, know the adresses of their production plants by heart? No, because what for.
Correct.
On Tue, 2020-05-12 at 07:13 +0200, Mathias Homann wrote:
Am Montag, 11. Mai 2020, 23:50:30 CEST schrieb Patrick Shanahan:
I'm sorry. How do you get from
http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/
to
https://build.opensuse.org/project/show/graphics
I'm sure many of us who use the various repositories were unaware of the later. What's the algorithm ? How was this publicised, even to us longer term users of the facilities?
ever hear about openSUSE build service
as a regular user? most likely not.
I mean, would you, if you were to drive a Volkswagen, know the adresses of their production plants by heart? No, because what for.
Wrong analogy. More like you are trying to customise your car with highly selective, experimental parts not meant to be used by regular Joe/Jane (and clearly marked as such). In that case you better know as much details about those parts as possible, including where those parts come from.
Indeed if these repositories were meant to be widely used, they would have come preconfigured with openSUSE releases or at least been made easy to add, for example, without making users click on "experimental packages" or "expert download" on the package search interface.
Cheers.
On 12/05/2020 06:36, Atri Bhattacharya wrote:
I mean, would you, if you were to drive a Volkswagen, know the adresses of their production plants by heart? No, because what for.
Wrong analogy. More like you are trying to customise your car with highly selective, experimental parts not meant to be used by regular Joe/Jane (and clearly marked as such). In that case you better know as much details about those parts as possible, including where those parts come from.
And you've got the wrong analogy. This isn't like I have all that car maintenance equipment, I haven't had to go searching..
This is like back in the late '60s: - I could run on higher octane fuel from the next pump along - I could replace my headlight bulbs with high-intensity xenon bulbs - I could replace my spark-plugs with high performance 'copper core' ones - I can replace my hub caps with something flashier
Even back then I knew women who doing this level of 'maintenance and improvement'. I now one who changed the oil in the car herself and did 'tune=up' to save money.
Actually I've done all of the above and I've also don a 'top end overhaul', replaced a rusted kicker panel and door. I'm not an auto engineer. All this with just 'home tools' and no particular knowledge of automotive engineering.
I'm not a developer; I don't use a compiler. To cross reference another thread, I use kernel_stable for recompiled kernels that DO include the Ham Radio extensions.
Now if I want to change the clutch, the transmission, that's another matter.
Indeed if these repositories were meant to be widely used, they would have come preconfigured with openSUSE releases or at least been made easy to add, for example, without making users click on "experimental packages" or "expert download" on the package search interface.
What are you going on about? Oh, I'm sure that's one way to get there, but just as Daniel went searching for the latest Gimp, I went searching for the latest Darktable. That this is 'experimental' is as much a surprise to me as it seems to be to him.
As a sidebar, I'd also mention Dave Plater's excellent work to restore the functionality of Konqueror. You'd probably class that as "experimental packages" or "expert download" or "build service" but again I never went searching for it. Dave told me about it and I did, as he suggested, simply a 'zypper addrepo ...'. That this works better than the version on the distribution DVD ... says a lot to me.
On Tue, 2020-05-12 at 08:41 -0400, Anton Aylward wrote:
Indeed if these repositories were meant to be widely used, they would have come preconfigured with openSUSE releases or at least been made easy to add, for example, without making users click on "experimental packages" or "expert download" on the package search interface.
What are you going on about? Oh, I'm sure that's one way to get there, but just as Daniel went searching for the latest Gimp, I went searching for the latest Darktable. That this is 'experimental' is as much a surprise to me as it seems to be to him.
It is, and, if you didn't already, you know now. Please pass on this 'statutory warning' when you share these repositories with others.
As a sidebar, I'd also mention Dave Plater's excellent work to restore the functionality of Konqueror. You'd probably class that as "experimental packages" or "expert download" or "build service" but again I never went searching for it. Dave told me about it and I did, as he suggested, simply a 'zypper addrepo ...'. That this works better than the version on the distribution DVD ... says a lot to me.
I am not classifying anything, the distro is. If you have to click on 'experimental packages' in the package search to get to a package, it is, quite clearly classified thus. As a rule, it bears keeping in mind that you are on your own when using these repositories, no matter how great and/or latest the packages coming from there may be.
If you just 'heard' it from someone, they have done you a disservice if they didn't warn you about it first. I am not talking about this Konqueror package particularly; the packager in this case may well have gone the extra mile to ensure Leap 15.1 users are well supported (for example, the packman repos do this too). But don't simply go and 'zypper addrepo' because someone told you so.
Cheers,
On 12/05/2020 09:09, Atri Bhattacharya wrote:
I am not classifying anything, the distro is. If you have to click on 'experimental packages' in the package search to get to a package, it is, quite clearly classified thus.
That may be so but that's not how I got the Graphics repository, the Packman repository, Dave Plater's KDE repository, Kernel_Stable or others.
As a rule, it bears keeping in mind that you are on your own when using these repositories, no matter how great and/or latest the packages coming from there may be.
Again, that is not so. To give just one example, Dave Plater had been very responsive about my suggestions about packaging and enabling features. In fact the 'build" with individually identifiable authors is more responsive than the mainstream openSUSE! (which is why so many of us use this list!)
And when those individuals stop responding I drop their their repositories.
If you just 'heard' it from someone, they have done you a disservice if they didn't warn you about it first. I am not talking about this Konqueror package particularly; the packager in this case may well have gone the extra mile to ensure Leap 15.1 users are well supported (for example, the packman repos do this too). But don't simply go and 'zypper addrepo' because someone told you so.
Correct, I don't.
Op dinsdag 12 mei 2020 15:35:40 CEST schreef Anton Aylward:
That may be so but that's not how I got the Graphics repository, the Packman repository, Dave Plater's KDE repository, Kernel_Stable or others.
That's what I call creating your own untested and unreviewed TW version. Your perception of how things work is plain wrong.
Op maandag 11 mei 2020 23:37:58 CEST schreef Anton Aylward:
On 11/05/2020 14:31, Atri Bhattacharya wrote:
There is a problem here. Repositories lack a description or comment that explains what is the use case of each repository.
That is literally what the project's description says on the front page [1]: "It is a devel project for openSUSE:Factory."
I'm sorry. How do you get from
http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/
to
https://build.opensuse.org/project/show/graphics
I'm sure many of us who use the various repositories were unaware of the later. What's the algorithm ? How was this publicised, even to us longer term users of the facilities?
Most likely from the Search in OBS. Search for 'graphics' and see for yourself
> Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. >> >>> Q: Why is top posting frowned upon?
On 11/05/2020 23.51, Knurpht-openSUSE wrote:
Op maandag 11 mei 2020 23:37:58 CEST schreef Anton Aylward:
On 11/05/2020 14:31, Atri Bhattacharya wrote:
There is a problem here. Repositories lack a description or comment that explains what is the use case of each repository.
That is literally what the project's description says on the front page [1]: "It is a devel project for openSUSE:Factory."
I'm sorry. How do you get from
http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/
to
https://build.opensuse.org/project/show/graphics
I'm sure many of us who use the various repositories were unaware of the later. What's the algorithm ? How was this publicised, even to us longer term users of the facilities?
Most likely from the Search in OBS. Search for 'graphics' and see for yourself
But we do not search on the OBS.
We search on the search page of opensuse web page.
to:
https://search.opensuse.org/packages/
which has a quick install button, named "direct install", with which you can install things not in the official distribution, without knowing the name of the repository it comes from.
Then I can click "... for other distributions", select "show experimental packages" and then "1 click install" on the one with the higher version. No warnings at all. As easy as can be.
To see the OBS page, one has to hit "expert download" and ... No, it is not there. It was, but the page was reformed and now it is not there. The OBS is hidden, as it should be.
Carlos E. R. wrote:
On 11/05/2020 23.51, Knurpht-openSUSE wrote:
Op maandag 11 mei 2020 23:37:58 CEST schreef Anton Aylward:
On 11/05/2020 14:31, Atri Bhattacharya wrote:
There is a problem here. Repositories lack a description or comment that explains what is the use case of each repository.
That is literally what the project's description says on the front page [1]: "It is a devel project for openSUSE:Factory."
I'm sorry. How do you get from
http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/
to
https://build.opensuse.org/project/show/graphics
I'm sure many of us who use the various repositories were unaware of the later. What's the algorithm ? How was this publicised, even to us longer term users of the facilities?
Most likely from the Search in OBS. Search for 'graphics' and see for yourself
But we do not search on the OBS.
Yes, that is what search.o.o provides - after all, you don't need an extra search engine for the official repos, YaST and zypper will help you search those.
* Per Jessen per@computer.org [05-12-20 06:13]:
Carlos E. R. wrote:
[...]
But we do not search on the OBS.
Yes, that is what search.o.o provides - after all, you don't need an extra search engine for the official repos, YaST and zypper will help you search those.
but YaST and zypper will only show packages for configured repos and opi or search.o.o will include non-configured repos.
wouldn't one want to know a package was available?
and needing to configure a new repo would at lease provide a modicum of caution due to the detail needed to make the configuration.
maybe just Irish luck but I run many experimental packages from added repos utilizing caution for possible system problems related to the (Carlos's words) non-Official repos, and experience few problems. Isn't that one method of "giving back" to the community?
Patrick Shanahan wrote:
- Per Jessen per@computer.org [05-12-20 06:13]:
Carlos E. R. wrote:
[...]
But we do not search on the OBS.
Yes, that is what search.o.o provides - after all, you don't need an extra search engine for the official repos, YaST and zypper will help you search those.
but YaST and zypper will only show packages for configured repos and opi or search.o.o will include non-configured repos.
Right. The latter includes all kinds of stuff.
wouldn't one want to know a package was available?
I tend to start with a 'zypper se', then I go check softare.o.o
and needing to configure a new repo would at lease provide a modicum of caution due to the detail needed to make the configuration.
Maybe it is _too_ easy? dunno.
Hi Anton,
On Mon, 2020-05-11 at 17:37 -0400, Anton Aylward wrote:
On 11/05/2020 14:31, Atri Bhattacharya wrote:
There is a problem here. Repositories lack a description or comment that explains what is the use case of each repository.
That is literally what the project's description says on the front page [1]: "It is a devel project for openSUSE:Factory."
I'm sorry. How do you get from
http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/
Calling this URL <A>
to
and this <B>, my question to you would be: how do you get to <A> in the first place? To be sure, there are several ways to get there. For example, 1. You may search for a package foo on https://software.opensuse.org/ , click on "Show foo for other distributions", scroll down to openSUSE 15.1, click on "Show experimental packages", then click on "Expert download", click on the openSUSE logo, then click "Grab binary packages directly" or "Add repository and install manually". This will have therefore warned you already that a) the packages are experimental and b) that you are doing something requiring "expertise". 2. You picked up URL <A> from a forum post or some other place which did not clarify that it is recommended to avoid this repository and packages therefore may break at any time. This word-of-mouth spreading, so to say, is, in my opinion, the hardest to guard a possibly not-so-advanced user from ending up using these experimental repos. 3. You are a long term user of openSUSE and just "know" where to look. If this is the case, I would guess it is more likely than not that you will have heard about build.o.o and its connection to download.o.o/repositories, and that, indeed, <A> is the published end-product of the work going on in <B>.
There may possibly be other ways. It would be nice to know the route users take to end up at <A>, so that it may be possible to set up proper warning lights along the way.
Cheers,
On Tue, 12 May 2020 01:10:11 +0200 Atri Bhattacharya badshah400@opensuse.org wrote:
Hi Anton,
On Mon, 2020-05-11 at 17:37 -0400, Anton Aylward wrote:
On 11/05/2020 14:31, Atri Bhattacharya wrote:
There is a problem here. Repositories lack a description or comment that explains what is the use case of each repository.
That is literally what the project's description says on the front page [1]: "It is a devel project for openSUSE:Factory."
I'm sorry. How do you get from
http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/
Calling this URL <A>
to
and this <B>, my question to you would be: how do you get to <A> in the first place? To be sure, there are several ways to get there. For example,
- You may search for a package foo on
https://software.opensuse.org/ , click on "Show foo for other distributions", scroll down to openSUSE 15.1, click on "Show experimental packages", then click on "Expert download", click on the openSUSE logo, then click "Grab binary packages directly" or "Add repository and install manually". This will have therefore warned you already that a) the packages are experimental and b) that you are doing something requiring "expertise".
I just went to https://software.opensuse.org/, selected openSUSE Leap 15.1 in the pulldown, typed 'gimp' in the serch box and was presented with 41 results - none of which was the (a) 'gimp' package??????
The results were at this URL: https://software.opensuse.org/search?utf8=%E2%9C%93&baseproject=openSUSE%3ALeap%3A15.1&q=gimp
Oh and the word Show does not appear on the page, so I can't click on a link containing it.
This suggested method of finding the package appears somewhat fragile, at best.
- You picked up URL <A> from a forum post or some other place
which did not clarify that it is recommended to avoid this repository and packages therefore may break at any time. This word-of-mouth spreading, so to say, is, in my opinion, the hardest to guard a possibly not-so-advanced user from ending up using these experimental repos.
This seems to be the only possible way that might be useful to me.
- You are a long term user of openSUSE and just "know" where to
look. If this is the case, I would guess it is more likely than not that you will have heard about build.o.o and its connection to download.o.o/repositories, and that, indeed, <A> is the published end-product of the work going on in <B>.
I'm a long-term user but I certainly don't 'know' where to look, other than in YaST.
There may possibly be other ways. It would be nice to know the route users take to end up at <A>, so that it may be possible to set up proper warning lights along the way.
Cheers,
On Tue, 2020-05-12 at 10:45 +0100, Dave Howorth wrote:
On Tue, 12 May 2020 01:10:11 +0200 Atri Bhattacharya badshah400@opensuse.org wrote:
Hi Anton,
On Mon, 2020-05-11 at 17:37 -0400, Anton Aylward wrote:
On 11/05/2020 14:31, Atri Bhattacharya wrote:
There is a problem here. Repositories lack a description or comment that explains what is the use case of each repository.
That is literally what the project's description says on the front page [1]: "It is a devel project for openSUSE:Factory."
I'm sorry. How do you get from
http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/
Calling this URL <A>
to
and this <B>, my question to you would be: how do you get to <A> in the first place? To be sure, there are several ways to get there. For example,
- You may search for a package foo on
https://software.opensuse.org/ , click on "Show foo for other distributions", scroll down to openSUSE 15.1, click on "Show experimental packages", then click on "Expert download", click on the openSUSE logo, then click "Grab binary packages directly" or "Add repository and install manually". This will have therefore warned you already that a) the packages are experimental and b) that you are doing something requiring "expertise".
I just went to https://software.opensuse.org/;, selected openSUSE Leap 15.1 in the pulldown, typed 'gimp' in the serch box and was presented with 41 results - none of which was the (a) 'gimp' package??????
The results were at this URL: https://software.opensuse.org/search ?utf8=%E2%9C%93&baseproject=openSUSE%3ALeap%3A15.1&q=gimp
Yeah, it's weird, but you have to click on the "Extra files for GIMP"...
Oh and the word Show does not appear on the page, so I can't click on a link containing it.
... and then you can click on "Show gimp for other distributions".
- You picked up URL <A> from a forum post or some other place
which did not clarify that it is recommended to avoid this repository and packages therefore may break at any time. This word-of-mouth spreading, so to say, is, in my opinion, the hardest to guard a possibly not-so-advanced user from ending up using these experimental repos.
This seems to be the only possible way that might be useful to me.
Nothing to do to protect against this, so I'll just tell you for the umpteenth time: Use non-standard, experimental repos **only** if you are an advanced user and know how to fix your system if you break it. Otherwise stick to the repositories openSUSE provides by default. Pass on this message to anyone with whom you share/discuss a non-std repository the next time.
- You are a long term user of openSUSE and just "know" where to
look. If this is the case, I would guess it is more likely than not that you will have heard about build.o.o and its connection to download.o.o/repositories, and that, indeed, <A> is the published end-product of the work going on in <B>.
I'm a long-term user but I certainly don't 'know' where to look, other than in YaST.
And where does YaST come with the graphics repository already configured and added in?
On 12/05/2020 01.10, Atri Bhattacharya wrote:
...
There may possibly be other ways. It would be nice to know the route users take to end up at <A>, so that it may be possible to set up proper warning lights along the way.
See my answer to Knurpht.
You really have to add the repo description in the opensuse search page results, and display it in YaST and in Zypper - if you really want us to know that it is a devel repo for factory and that we are not expected to use it.
Not hidden in the OBS, which is a developer tool, not a user tool.
Carlos E. R. wrote:
On 12/05/2020 01.10, Atri Bhattacharya wrote:
...
There may possibly be other ways. It would be nice to know the route users take to end up at <A>, so that it may be possible to set up proper warning lights along the way.
See my answer to Knurpht.
You really have to add the repo description in the opensuse search page results, and display it in YaST and in Zypper - if you really want us to know that it is a devel repo for factory and that we are not expected to use it.
Essentially, users are not expected to use anything but the official repos -
download.o.o/distribution download.o.o/tumbleweed download.o.o/update
download.o.o/repositories should be considered experimental.
That is hardly major news to anyone?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2020-05-12 at 12:04 +0200, Per Jessen wrote:
Carlos E. R. wrote:
On 12/05/2020 01.10, Atri Bhattacharya wrote:
...
There may possibly be other ways. It would be nice to know the route users take to end up at <A>, so that it may be possible to set up proper warning lights along the way.
See my answer to Knurpht.
You really have to add the repo description in the opensuse search page results, and display it in YaST and in Zypper - if you really want us to know that it is a devel repo for factory and that we are not expected to use it.
Essentially, users are not expected to use anything but the official repos -
download.o.o/distribution download.o.o/tumbleweed download.o.o/update
download.o.o/repositories should be considered experimental.
That is hardly major news to anyone?
We do understand that extra repos are extra, not official. Experimental. Ok, fine. But Atri is basically telling us to not install them at all! As Andrei says, why publish gimp for Leap if we are not supposed to install and use it? If a repo is published for Leap, it should at least be installable on Leap and "work", for some value of work. And if it doesn't work, there must be a channel for users to inform devs that it doesn't.
And another selling point for Leap, is that when people say that it is obsolete technology, we can counter that it is basically stable, but that they can get that package they want in a much newer version from the repositories.
One of the big selling points of openSUSE is that there are many extra repositories to obtain /anything else/. In fact, I have been told often by users (outside of here) that other distributions have more packages than openSUSE, and I had to tell them that there are many more in extra repositories. And show them how to search for what they missed.
For example, I asked google how many packages debian or opensuse got - in Spanish, but I'll translate it. The answer for OS is specially relevant:
https://www.google.com/search?client=firefox-b-e&q=cuantos+paquetes+tiene+debian%3F
Debian viene con más de 59000 paquetes (software precompilado y empaquetado en un formato amigable para una instalación sencilla en su máquina), un gestor de paquetes (APT), y otras utilidades que hacen posible gestionar miles de paquetes en miles de ordenadores de manera tan fácil como instalar una sola aplicación.Mar 9, 2020
Debian -- Acerca de Debian
Debian comes with over 59000 packages (software precompiled and packaged in a user-friendly format for easy installation on your machine), a package manager (APT), and other utilities that make it possible to manage thousands of packages on thousands of computers as easily as installing a single application.Mar 9, 2020
Debian -- About Debian
https://www.debian.org/intro/about.es.html
https://www.google.com/search?client=firefox-b-e&q=cuantos+paquetes+tiene+opensuse%3F
software.opensuse.org ofrece más de 200.000 paquetes de software creados por cientos de usuarios que contribuyen mediante build.opensuse.org una herramienta pública de Open Build Service (OBS). La instalación de paquetes es muy fácil gracias a la tecnología de instalación de openSUSE llamada 1-click.Mar 22, 2013
openSUSE explicado para aquellos que lo quieran probar ...
software.opensuse.org offers more than 200,000 software packages created by hundreds of users who contribute through build.opensuse.org a public Open Build Service (OBS) tool. The installation of packages is very easy thanks to the openSUSE installation technology called 1-click.Mar 22, 2013
openSUSE explained for those who want to try it out ...
(Automated Translation done by DeepL)
Notice that the answer that google selects as main one doesn't come from official sources, but the Debian one is official. Maybe openSUSE Public Relations Office can do something about that ;-)
- -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar)
Carlos E. R. wrote:
On Tuesday, 2020-05-12 at 12:04 +0200, Per Jessen wrote:
Essentially, users are not expected to use anything but the official repos -
download.o.o/distribution download.o.o/tumbleweed download.o.o/update
download.o.o/repositories should be considered experimental.
That is hardly major news to anyone?
We do understand that extra repos are extra, not official. Experimental. Ok, fine. But Atri is basically telling us to not install them at all!
I thought he explained in a very polite and understanding way that we all have the option, but that things may break.
* Per Jessen per@computer.org [05-12-20 06:50]:
Carlos E. R. wrote:
On Tuesday, 2020-05-12 at 12:04 +0200, Per Jessen wrote:
Essentially, users are not expected to use anything but the official repos -
download.o.o/distribution download.o.o/tumbleweed download.o.o/update
download.o.o/repositories should be considered experimental.
That is hardly major news to anyone?
We do understand that extra repos are extra, not official. Experimental. Ok, fine. But Atri is basically telling us to not install them at all!I thought he explained in a very polite and understanding way that we all have the option, but that things may break.
that is how I understood his post.
On 12/05/2020 06:48, Per Jessen wrote:
Carlos E. R. wrote:
On Tuesday, 2020-05-12 at 12:04 +0200, Per Jessen wrote:
Essentially, users are not expected to use anything but the official repos -
download.o.o/distribution download.o.o/tumbleweed download.o.o/update
download.o.o/repositories should be considered experimental.
That is hardly major news to anyone?
We do understand that extra repos are extra, not official. Experimental. Ok, fine. But Atri is basically telling us to not install them at all!I thought he explained in a very polite and understanding way that we all have the option, but that things may break.
Why presume that "extra" = "experimental" ???
Does that hold for Packman? Does that hold for the people who want to continue to run KDE3?
There seem to be two ways of dealing with kernel updates: a) apply the patches to the old kernel and don't change it's numbering b) apply patches and generate a new kernel and change the numbering to reflect that.
That I choose the latter and have 'old' kernels stacked so I can roll-back (until they get purged) seems to me better than having just the one kernel. If a patch is unstable then I have an option that the single-kernel people don't, which is why they need to use BtrFS and keep a whole pile of other stuff, stuff I don't want' in a rollback.
I guess I'm a 'single issue' guy :-)
I don't think that "extra" = "experimental" for all cases.
* Anton Aylward opensuse@antonaylward.com [05-12-20 09:51]:
On 12/05/2020 06:48, Per Jessen wrote:
Carlos E. R. wrote:
On Tuesday, 2020-05-12 at 12:04 +0200, Per Jessen wrote:
Essentially, users are not expected to use anything but the official repos -
download.o.o/distribution download.o.o/tumbleweed download.o.o/update
download.o.o/repositories should be considered experimental.
That is hardly major news to anyone?
We do understand that extra repos are extra, not official. Experimental. Ok, fine. But Atri is basically telling us to not install them at all!I thought he explained in a very polite and understanding way that we all have the option, but that things may break.
Why presume that "extra" = "experimental" ???
Does that hold for Packman?
yes
Does that hold for the people who want to continue to run KDE3?
definitely
[...]
I don't think that "extra" = "experimental" for all cases.
but the difference is only a matter of degree and for one not proficient enough to recover his system, that degree or two is very large.
Anton Aylward wrote:
On 12/05/2020 06:48, Per Jessen wrote:
Carlos E. R. wrote:
On Tuesday, 2020-05-12 at 12:04 +0200, Per Jessen wrote:
Essentially, users are not expected to use anything but the official repos -
download.o.o/distribution download.o.o/tumbleweed download.o.o/update
download.o.o/repositories should be considered experimental.
That is hardly major news to anyone?
We do understand that extra repos are extra, not official. Experimental. Ok, fine. But Atri is basically telling us to not install them at all!I thought he explained in a very polite and understanding way that we all have the option, but that things may break.
Why presume that "extra" = "experimental" ???
I don't, but in the case of what we provide in repositories/, we say it is experimental because it has not gone through the same process as the distribution repos.
Does that hold for Packman? Does that hold for the people who want to continue to run KDE3?
In principle, yes in both cases.
I don't think that "extra" = "experimental" for all cases.
Which repos do you consider to be "extra"?
* Carlos E. R. robin.listas@telefonica.net [05-12-20 06:40]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[...]
We do understand that extra repos are extra, not official. Experimental. Ok, fine. But Atri is basically telling us to not install them at all! As Andrei says, why publish gimp for Leap if we are not supposed to install and use it? If a repo is published for Leap, it should at least be installable on Leap and "work", for some value of work. And if it doesn't work, there must be a channel for users to inform devs that it doesn't.
are you not able to report to the builder (information in the repo) that there is problems with the build.
And another selling point for Leap, is that when people say that it is obsolete technology, we can counter that it is basically stable, but that they can get that package they want in a much newer version from the repositories.
it is *unless* one becomes adventurous or careless and adds repos and builds, and is not knowledgable enough to recover his system when problems arise. It is very difficult to protect one from himself, ie: remove power cord and mangle connector.
On 12/05/2020 05:47, Carlos E. R. wrote:
On 12/05/2020 01.10, Atri Bhattacharya wrote:
...
There may possibly be other ways. It would be nice to know the route users take to end up at <A>, so that it may be possible to set up proper warning lights along the way.
See my answer to Knurpht.
You really have to add the repo description in the opensuse search page results, and display it in YaST and in Zypper - if you really want us to know that it is a devel repo for factory and that we are not expected to use it.
Not hidden in the OBS, which is a developer tool, not a user tool.
+1
11.05.2020 20:00, Atri Bhattacharya пишет:
The complaint about libmypaint is but a red herring. Rather, since obs://graphics serves as a devel project for openSUSE:Factory -- __not__ as a backport for Leap:15.X, libraries therein continue to be upgraded to their latest versions and pushed to openSUSE:Factory. One of these -- babl -- as part of its upgrade to version 0.1.70, switched to using meson >= 0.50 as its only build system (by upstream). As soon as this was checked into graphics, it stopped building for Leap:15.1 and became unresolvable. Why? Because Leap:15.1 only has meson 0.46 in its official repo and obs://graphics doesn't have meson >= 0.50.0 for Leap either (rightly so, it's not a graphics library/application but a core build system tool).
If repository publish Leap 15.1 repo, it is expected that this repo is maintained and working (with suitable definition of "working"). If repository has no intention of maintaining compatibility with Leap 15.1, then why do you publish it in the first place?
On 12/05/2020 07.32, Andrei Borzenkov wrote:
11.05.2020 20:00, Atri Bhattacharya пишет:
The complaint about libmypaint is but a red herring. Rather, since obs://graphics serves as a devel project for openSUSE:Factory -- __not__ as a backport for Leap:15.X, libraries therein continue to be upgraded to their latest versions and pushed to openSUSE:Factory. One of these -- babl -- as part of its upgrade to version 0.1.70, switched to using meson >= 0.50 as its only build system (by upstream). As soon as this was checked into graphics, it stopped building for Leap:15.1 and became unresolvable. Why? Because Leap:15.1 only has meson 0.46 in its official repo and obs://graphics doesn't have meson >= 0.50.0 for Leap either (rightly so, it's not a graphics library/application but a core build system tool).
If repository publish Leap 15.1 repo, it is expected that this repo is maintained and working (with suitable definition of "working"). If repository has no intention of maintaining compatibility with Leap 15.1, then why do you publish it in the first place?
Absolutely! Thanks :-)
You hit the very nail on the head.
Hello,
In the Message;
Subject : Re: [opensuse] installing Gimp 2.10 on OS 15.1 failed (or: how to get webp for gimp?) Message-ID : 20200428121417.GJ24352@wahoo.no-ip.org Date & Time: Tue, 28 Apr 2020 08:14:17 -0400
[PS] == Patrick Shanahan paka@opensuse.org has written:
[...] PS> > Problem: nothing provides libmypaint-1.4.so.0()(64bit) needed by PS> > gimp-2.10.12-lp151.1.5.x86_64 PS> > Solution 1: do not install gimp-2.10.12-lp151.1.5.x86_64 PS> > Solution 2: break gimp-2.10.12-lp151.1.5.x86_64 by ignoring some of its PS> > dependencies PS> > PS> > Choose from above solutions by number or cancel [1/2/c/d/?] (c):
PS> You need to add the repo which contains the needed libmypaint as Carlos PS> wrote or you will continue to get the missing package error. Zypper PS> cannot find packages when it does know know the repo's containing the PS> package, ie: add the necessary repo
There doesn't exist such a repo.
The compilation of gimp 2.10.12-lp151.1.5.src.rpm is the solution for him, I think.
Regards,
--- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ Think. -- The IBM slogan --
Hello,
In the Message;
Subject : Re: [opensuse] installing Gimp 2.10 on OS 15.1 failed (or: how to get webp for gimp?) Message-ID : 871ro7bxal.wl-nomiya@galaxy.dti.ne.jp Date & Time: Tue, 28 Apr 2020 21:38:10 +0900
[MN] == Masaru Nomiya nomiya@galaxy.dti.ne.jp has written:
[...] PS> You need to add the repo which contains the needed libmypaint as Carlos PS> wrote or you will continue to get the missing package error. Zypper PS> cannot find packages when it does know know the repo's containing the PS> package, ie: add the necessary repo
MN> There doesn't exist such a repo.
MN> The compilation of gimp 2.10.12-lp151.1.5.src.rpm is the solution for MN> him, I think.
I built gimp 2.10.12-lp151.1.5.src.rpm with libmypaint 1.5.1 (installed from the graphics repo), and installed. Not so difficult.
It's a nice-looking for me.
Regards,
--- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "No Windows, no gains!" ..... "Why, I am wrong?"
-- Bill --
On 28/04/2020 08:02, Daniel Bauer wrote:
Am 28.04.20 um 13:37 schrieb Carlos E. R.:
On 28/04/2020 12.37, Daniel Bauer wrote:
Hello,
I need to be able to read and safe webp graphics in gimp. I am on Opensuse 15.1 and that comes with gimp 2.8 which doesn't support this format, it is (as I read) included from Gimp 2.9.
I found oneclick install for Gimp 2.10 for OS 15.1. Tried it. It failed because libmypaint-1.4 cant be found.
First thing: *never* use oneclick install.
Instead, go to the search page, and find the package:
https://software.opensuse.org/package/gimp
Locate the appropriate repo. Avoid the community repos, which leaves the experimental repos. There is only one: "graphics". Click on "expert" download, openSUSE, then click "Add repository and install manually".
Which for 15.1 means:
zypper addrepo https://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/graph...
zypper refresh zypper install gimp
Instead of the last two, fire up YaST.
I installed without, but then Gimp doesn't start.
I searched for libmypaint - found oneclick 1.5.1 - tried, but it didn't install because of an rpm error. 1.4.0 is only available for OS 15.2 (haven't tried to install it, should I - on 15.1?)
Well, the graphics repo from above has it. You do not say what repo you tried. If it gives an error, what error?
Thank you Carlos, but still the same error:
All repositories have been refreshed. venus:~ # zypper install gimp Loading repository data... Reading installed packages... 'gimp' is already installed. There is an update candidate for 'gimp' from vendor 'obs://build.opensuse.org/graphics', while the current vendor is 'openSUSE'. Use 'zypper install gimp-2.10.12-lp151.1.5.x86_64' to install this candidate. Resolving package dependencies...
Nothing to do.
venus:~ # zypper install gimp-2.10.12-lp151.1.5.x86_64 Loading repository data... Reading installed packages... Resolving package dependencies...
Problem: nothing provides libmypaint-1.4.so.0()(64bit) needed by gimp-2.10.12-lp151.1.5.x86_64 Solution 1: do not install gimp-2.10.12-lp151.1.5.x86_64 Solution 2: break gimp-2.10.12-lp151.1.5.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/c/d/?] (c):
Information for package libmypaint-1_4-0: ----------------------------------------- Repository : @System Name : libmypaint-1_4-0 Version : 1.4.0-lp151.15.2 Arch : x86_64 Vendor : obs://build.opensuse.org/graphics Installed Size : 81.9 KiB Installed : Yes (automatically) Status : up-to-date
I think you have failed to install and enable the 'graphics' distribution properly.
What does the relevant record in /etc/zypp/repos.d read?
Am 28.04.20 um 16:26 schrieb Anton Aylward:
On 28/04/2020 08:02, Daniel Bauer wrote:
Am 28.04.20 um 13:37 schrieb Carlos E. R.:
On 28/04/2020 12.37, Daniel Bauer wrote:
Hello,
I need to be able to read and safe webp graphics in gimp. I am on Opensuse 15.1 and that comes with gimp 2.8 which doesn't support this format, it is (as I read) included from Gimp 2.9.
I found oneclick install for Gimp 2.10 for OS 15.1. Tried it. It failed because libmypaint-1.4 cant be found.
First thing: *never* use oneclick install.
Instead, go to the search page, and find the package:
https://software.opensuse.org/package/gimp
Locate the appropriate repo. Avoid the community repos, which leaves the experimental repos. There is only one: "graphics". Click on "expert" download, openSUSE, then click "Add repository and install manually".
Which for 15.1 means:
zypper addrepo https://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/graph...
zypper refresh zypper install gimp
Instead of the last two, fire up YaST.
I installed without, but then Gimp doesn't start.
I searched for libmypaint - found oneclick 1.5.1 - tried, but it didn't install because of an rpm error. 1.4.0 is only available for OS 15.2 (haven't tried to install it, should I - on 15.1?)
Well, the graphics repo from above has it. You do not say what repo you tried. If it gives an error, what error?
Thank you Carlos, but still the same error:
All repositories have been refreshed. venus:~ # zypper install gimp Loading repository data... Reading installed packages... 'gimp' is already installed. There is an update candidate for 'gimp' from vendor 'obs://build.opensuse.org/graphics', while the current vendor is 'openSUSE'. Use 'zypper install gimp-2.10.12-lp151.1.5.x86_64' to install this candidate. Resolving package dependencies...
Nothing to do.
venus:~ # zypper install gimp-2.10.12-lp151.1.5.x86_64 Loading repository data... Reading installed packages... Resolving package dependencies...
Problem: nothing provides libmypaint-1.4.so.0()(64bit) needed by gimp-2.10.12-lp151.1.5.x86_64 Solution 1: do not install gimp-2.10.12-lp151.1.5.x86_64 Solution 2: break gimp-2.10.12-lp151.1.5.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/c/d/?] (c):
Information for package libmypaint-1_4-0:
Repository : @System Name : libmypaint-1_4-0 Version : 1.4.0-lp151.15.2 Arch : x86_64 Vendor : obs://build.opensuse.org/graphics Installed Size : 81.9 KiB Installed : Yes (automatically) Status : up-to-date
I think you have failed to install and enable the 'graphics' distribution properly.
What does the relevant record in /etc/zypp/repos.d read?
hope I give the right details :-)
[graphics] name=Graphics Project (openSUSE_Leap_15.1) enabled=1 autorefresh=0 baseurl=http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/ type=rpm-md gpgcheck=1 gpgkey=http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/repoda...
In Yast, checking the versions of libmypaint I only see 1.5
On 28/04/2020 10:39, Daniel Bauer wrote:
What does the relevant record in /etc/zypp/repos.d read?
hope I give the right details :-)
[graphics] name=Graphics Project (openSUSE_Leap_15.1) enabled=1 autorefresh=0
Change that '0' to '1'
and then run zypper refresh
baseurl=http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/ type=rpm-md gpgcheck=1 gpgkey=http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/repoda...
In Yast, checking the versions of libmypaint I only see 1.5
Forget YAST when hunting a problem, it donesn't show what's really going on.
try zypper search libmypaint and zypper info libmypaint
On 28/04/2020 16.53, Anton Aylward wrote:
On 28/04/2020 10:39, Daniel Bauer wrote:
What does the relevant record in /etc/zypp/repos.d read?
hope I give the right details :-)
[graphics] name=Graphics Project (openSUSE_Leap_15.1) enabled=1 autorefresh=0
Change that '0' to '1'
and then run zypper refresh
baseurl=http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/ type=rpm-md gpgcheck=1 gpgkey=http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/repoda...
In Yast, checking the versions of libmypaint I only see 1.5
Forget YAST when hunting a problem, it donesn't show what's really going on.
try zypper search libmypaint
S | Name | Summary | Type --+----------------------------+--------------------------------------------------------------+----------- | libmypaint | A brushstroke creation library | srcpackage | libmypaint-1_5-1 | A brushstroke creation library | package | libmypaint-1_5-1-debuginfo | Debug information for package libmypaint-1_5-1 | package | libmypaint-debuginfo | Debug information for package libmypaint | package | libmypaint-debugsource | Debug sources for package libmypaint | package | libmypaint-devel | Header files for libmypaint, a brushstroke creation library | package | libmypaint-gegl-devel | Header files for libmypaint, a brushstroke creation library | package | libmypaint-gegl0 | GEGL bindings for libmypaint, a brushstroke creation library | package | libmypaint-gegl0-debuginfo | Debug information for package libmypaint-gegl0 | package | libmypaint-lang | Translations for package libmypaint | package cer@Telcontar:~>
zypper search --details libmypaint
S | Name | Type | Version | Arch | Repository --+----------------------------+------------+------------------+--------+-------------- | libmypaint | srcpackage | 1.5.1-lp151.19.1 | noarch | OBS: graphics | libmypaint-1_5-1 | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-1_5-1-debuginfo | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-debuginfo | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-debugsource | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-devel | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-gegl-devel | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-gegl0 | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-gegl0-debuginfo | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-lang | package | 1.5.1-lp151.19.1 | noarch | OBS: graphics cer@Telcontar:~>
As you can see, there is no version 1.4 there. I happen to have the graphics repo enabled.
and zypper info libmypaint
package 'libmypaint' not found.
Information for srcpackage libmypaint: -------------------------------------- Repository : OBS: graphics Name : libmypaint Version : 1.5.1-lp151.19.1 Arch : noarch Vendor : obs://build.opensuse.org/graphics Summary : A brushstroke creation library Description : libmypaint, a.k.a. "brushlib", is a library for making brushstrokes which is used by MyPaint and other projects. Builds binary package : S | Name | Version --+-----------------------------+----------------- | libmypaint-1_5-1 | 1.5.1-lp151.19.1 | libmypaint-1_5-1-debuginfo | 1.5.1-lp151.19.1 | libmypaint-debuginfo | 1.5.1-lp151.19.1 | libmypaint-debugsource | 1.5.1-lp151.19.1 | libmypaint-devel | 1.5.1-lp151.19.1 | libmypaint-gegl-devel | 1.5.1-lp151.19.1 | libmypaint-gegl0 | 1.5.1-lp151.19.1 | libmypaint-gegl0-debuginfo | 1.5.1-lp151.19.1 | libmypaint-lang | 1.5.1-lp151.19.1 | typelib-1_0-MyPaint-1_5 | 1.5.1-lp151.19.1 | typelib-1_0-MyPaintGegl-1_5 | 1.5.1-lp151.19.1
On 28/04/2020 11:01, Carlos E. R. wrote:
zypper search --details libmypaint
S | Name | Type | Version | Arch | Repository --+----------------------------+------------+------------------+--------+-------------- | libmypaint | srcpackage | 1.5.1-lp151.19.1 | noarch | OBS: graphics | libmypaint-1_5-1 | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-1_5-1-debuginfo | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-debuginfo | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-debugsource | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-devel | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-gegl-devel | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-gegl0 | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-gegl0-debuginfo | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-lang | package | 1.5.1-lp151.19.1 | noarch | OBS: graphics cer@Telcontar:~>
As you can see, there is no version 1.4 there. I happen to have the graphics repo enabled.
It makes me wonder if we have the same 'graphics' installed:
[151_graphics] name=151_graphics enabled=1 autorefresh=1 priority=98 baseurl=http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/ path=/ type=rpm-md keeppackages=0
On 28/04/2020 20.39, Anton Aylward wrote:
On 28/04/2020 11:01, Carlos E. R. wrote:
zypper search --details libmypaint
S | Name | Type | Version | Arch | Repository --+----------------------------+------------+------------------+--------+-------------- | libmypaint | srcpackage | 1.5.1-lp151.19.1 | noarch | OBS: graphics | libmypaint-1_5-1 | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-1_5-1-debuginfo | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-debuginfo | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-debugsource | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-devel | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-gegl-devel | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-gegl0 | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-gegl0-debuginfo | package | 1.5.1-lp151.19.1 | x86_64 | OBS: graphics | libmypaint-lang | package | 1.5.1-lp151.19.1 | noarch | OBS: graphics cer@Telcontar:~>
As you can see, there is no version 1.4 there. I happen to have the graphics repo enabled.
It makes me wonder if we have the same 'graphics' installed:
[151_graphics] name=151_graphics enabled=1 autorefresh=1 priority=98 baseurl=http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/ path=/ type=rpm-md keeppackages=0
cer@Telcontar:/etc/zypp/repos.d> ls | grep graph OBS_graphics.repo cer@Telcontar:/etc/zypp/repos.d> cat OBS_graphics.repo [OBS_graphics] name=OBS: graphics enabled=1 autorefresh=1 baseurl=http://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/ path=/ type=rpm-md priority=100 keeppackages=1 cer@Telcontar:/etc/zypp/repos.d>
On 28/04/2020 07:37, Carlos E. R. wrote:
On 28/04/2020 12.37, Daniel Bauer wrote:
Hello,
I need to be able to read and safe webp graphics in gimp. I am on Opensuse 15.1 and that comes with gimp 2.8 which doesn't support this format, it is (as I read) included from Gimp 2.9.
I found oneclick install for Gimp 2.10 for OS 15.1. Tried it. It failed because libmypaint-1.4 cant be found.
First thing: *never* use oneclick install.
Instead, go to the search page, and find the package:
https://software.opensuse.org/package/gimp
Locate the appropriate repo. Avoid the community repos, which leaves the experimental repos. There is only one: "graphics". Click on "expert" download, openSUSE, then click "Add repository and install manually".
Which for 15.1 means:
zypper addrepo https://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.1/graph... zypper refresh zypper install gimp
Instead of the last two, fire up YaST.
just to make sure i have it
priority=98
Well, the graphics repo from above has it. You do not say what repo you tried. If it gives an error, what error?
Information for package gimp: ----------------------------- Repository : 151_graphics Name : gimp Version : 2.10.12-lp151.1.5 Arch : x86_64 Vendor : obs://build.opensuse.org/graphics Installed Size : 64.5 MiB Installed : Yes Status : up-to-date Source package : gimp-2.10.12-lp151.1.5.src
W dniu 28.04.2020 o 12:37, Daniel Bauer pisze:
Hello,
I need to be able to read and safe webp graphics in gimp. I am on Opensuse 15.1 and that comes with gimp 2.8 which doesn't support this format, it is (as I read) included from Gimp 2.9.
I found oneclick install for Gimp 2.10 for OS 15.1. Tried it. It failed because libmypaint-1.4 cant be found.
I installed without, but then Gimp doesn't start.
I searched for libmypaint - found oneclick 1.5.1 - tried, but it didn't install because of an rpm error. 1.4.0 is only available for OS 15.2 (haven't tried to install it, should I - on 15.1?)
my questions:
- How can I install Gimp 2.10 on 15.1 and resolve the missing
libmypaint-1.4?
- or alternatively: how can I make Gimp 2.8 to handle webp graphics?
Thanks for your help!
Daniel
I recently had the same problem. I gave up on installing gimp from any repo. Flatpak to the rescue:
https://flathub.org/apps/details/org.gimp.GIMP
how to install: flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo flatpak install flathub org.gimp.GIMP
how to run: a) it should appear in your applications menu b) flatpak run org.gimp.GIMP
-
Adam Mizerski -
Andrei Borzenkov -
Anton Aylward -
Atri Bhattacharya -
Carlos E. R. -
Daniel Bauer -
Dave Howorth -
David C. Rankin -
Dr.-Ing. Dieter Jurzitza -
Harrie Baken -
Knurpht-openSUSE -
Masaru Nomiya -
Mathias Homann -
Patrick Shanahan -
Per Jessen