How do I request a package be built?

**broadstairs** · 25-Feb-2021, 03:48

I have a situation where a current package has a bug and has been fixed by the appropriate devs and an update released but as yet this has not been made available in openSUSE. The package is libgd3 and the update I believe was made some months ago. The issue is that the bug which exists in the current package prevents JPGraphs php scripts from working and this is an issue not just for me but for anyone who uses JPGraphs, so compiling it fixes it for me but not for potentially many ( perhaps 100's) of other users out there.

So how do I ask for this package to be updated to add this fix?

Stuart

**malcolmlewis** · 25-Feb-2021, 06:18

Originally Posted by broadstairs

I have a situation where a current package has a bug and has been fixed by the appropriate devs and an update released but as yet this has not been made available in openSUSE. The package is libgd3 and the update I believe was made some months ago. The issue is that the bug which exists in the current package prevents JPGraphs php scripts from working and this is an issue not just for me but for anyone who uses JPGraphs, so compiling it fixes it for me but not for potentially many ( perhaps 100's) of other users out there.

So how do I ask for this package to be updated to add this fix?

Stuart

Hi
Normally via braching and updating for Tumbleweed, for Leap backporting the fix into the current release as a maintenance update...

Else raise a bug report for the Maintainers... openSUSE:Submitting bug reports - openSUSE

**Kieltux** · 25-Feb-2021, 12:53

Hello,

I don't know libgd3 or jpgraph, but newest upstream release of libgd3 is version 2.31.
You can find libgd3 2.31 here: https://build.opensuse.org/package/show/graphics/gd

Have a lot of fun,
Carsten

**tsu2** · 27-Feb-2021, 17:24

Originally Posted by Kieltux

Hello,

I don't know libgd3 or jpgraph, but newest upstream release of libgd3 is version 2.31.
You can find libgd3 2.31 here: https://build.opensuse.org/package/show/graphics/gd

Have a lot of fun,
Carsten

Instead of pointing ordinary Users to an openSUSE build project,
It's probably more useful to point them to where they can get the package using common User tools...

From the software search site, you can install the package from the graphics repository (recommended over the private repos)

https://software.opensuse.org/package/libgd3

TSU

**malcolmlewis** · 27-Feb-2021, 17:58

Originally Posted by tsu2

Instead of pointing ordinary Users to an openSUSE build project,
It's probably more useful to point them to where they can get the package using common User tools...

From the software search site, you can install the package from the graphics repository (recommended over the private repos)

https://software.opensuse.org/package/libgd3

TSU

Hi
That is just a stop gap measure, like I indicated, branch and fix/update/maintenance release etc, else if unable to do this a bug report is the correct route to take.

**tsu2** · 01-Mar-2021, 07:15

Originally Posted by malcolmlewis

Hi
That is just a stop gap measure, like I indicated, branch and fix/update/maintenance release etc, else if unable to do this a bug report is the correct route to take.

Are you suggesting that adding the graphics repository is not a permanent User solution?

TSU

**malcolmlewis** · 01-Mar-2021, 07:18

Originally Posted by tsu2

Are you suggesting that adding the graphics repository is not a permanent User solution?

TSU

Hi
Yes, because any fix will not get propagated to the Leap releases... That can only be done via a maintenance release (backporting fixes).

**tsu2** · 15-Mar-2021, 20:47

Originally Posted by malcolmlewis

Hi
Yes, because any fix will not get propagated to the Leap releases... That can only be done via a maintenance release (backporting fixes).

My understanding is that packages from repositories supported by communities (which SUSE/openSUSE confusingly choose to call "Experimental" instead of Community) are well supported by established developers and maintainers, we are not talking about private repos.

I don't know that this is an issue of whether LEAP maintainers choose to make a package part of the core distribution, I don't know how LEAP decides what is accepted into the OSS but I consider those decisions completely separate and according to separate and different criteria typically not related to a User's immediate need.
This is whether packages from established communities can be considered reliable with a fairly high assurance they will work.
Is this any different than using the Packman repository, any of the various coding language repositories or server application repositories?
I consider all of those acceptable and permanent sources for essential apps, and none should be avoided as less trustworthy or less recommended than OSS for Users.

IMO but open for clarification and willing to change my mind,
TSU

**malcolmlewis** · 16-Mar-2021, 05:37

Originally Posted by tsu2

My understanding is that packages from repositories supported by communities (which SUSE/openSUSE confusingly choose to call "Experimental" instead of Community) are well supported by established developers and maintainers, we are not talking about private repos.

I don't know that this is an issue of whether LEAP maintainers choose to make a package part of the core distribution, I don't know how LEAP decides what is accepted into the OSS but I consider those decisions completely separate and according to separate and different criteria typically not related to a User's immediate need.
This is whether packages from established communities can be considered reliable with a fairly high assurance they will work.
Is this any different than using the Packman repository, any of the various coding language repositories or server application repositories?
I consider all of those acceptable and permanent sources for essential apps, and none should be avoided as less trustworthy or less recommended than OSS for Users.

IMO but open for clarification and willing to change my mind,
TSU

Hi
Because some changes that wind up in development repositories are not backwards compatible.... or you have to hunt around for dependencies (and add more repos). Take for example gscan2pdf I'm still waiting for a dependency to arrive in Tumbleweed (since it's a leaf perl package) to push the update into Tumbleweed, missed the cut for Leap 15.3, so it will remain at the old release for ever and a day for <=leap 15.3.... So a user adds devel:languages

erl to their repos to add the later gscan2pdf and starts pulling in later updates/releases of perl packages if they are not careful, which may/may not work with their system packages.....

I don't use the Packman repository, far too invasive, have my own multimedia solution that has all the good bits to get things working.

Unless maintainers are made aware via a bug report, nothing will happen, users will continue to struggle and potentially break there system with having non-standard repositories present.

**roko772** · 16-Mar-2021, 09:33

Hi!

I don't know I am writing in right place, but I need newest version of spacenav, numbered as 0.8. It was rewritten and supports Magellan serial 6DOF joystick natively.
Newest version found in repos is only 0.7.1, which is unfortunately useless for me. Also, I can't make it work in Tumbleweed, when compiled from source - looks like I can't start this in proper way - maybe since there is not a standard /etc/init.d directory (source packages of spacenav contains some scripts to make installation easier).

Are here any people, that are responsible for building packages and can help me?

Spacenav homepage ---> http://spacenav.sourceforge.net/

Thank you very much!