Problem with packaging the Open Grid Scheduler

English Open Build Service (OBS)
#1

I am trying to build the Open Grid Scheduler using the build service. A local build seems to work o.k. (on OpenSuse 13.2, https://gist.github.com/sboehringer/6181165edaa4f093afcef622a3a96f6d), logs attached. However, OBS fails (https://build.opensuse.org/package/live_build_log/home:boehringers/ogs/openSUSE_13.2/x86_64) the build and it is unclear to me where the problem lies.

Any help appreciated.

#2

Hi
In your spec file, either add a build requires for the package that provides /usr/share/X11/app-defaults directory, else in the %files section you need to add the %dir directive eg;


[FONT=courier new]%dir %{_datadir}/X11
%dir %{_datadir}/X11/app-defaults

[/FONT]

#3

Dear Malcom,

thanks for the help, I have advanced one step. Please allow some more newbie questions.

  326s] gridengine.x86_64: E: suse-filelist-forbidden-sysconfig (Badness: 10000) /etc/sysconfig/gridengine is not allowed in SUSE

I am at a loss as to how to handle this error. Then:

  326s] gridengine.x86_64: E: permissions-file-setuid-bit (Badness: 10000) /usr/lib/gridengine/utilbin/testsuidroot is packaged with setuid/setgid bits (04755)

OGS is to be considered legacy code. I agree that with some tweaking setuid/setgidding can be avoided. However, that would involve some considerable work. Is there some acceptable way to deal with such legacy packages?

Next, I get.


  326s] gridengine.x86_64: E: non-position-independent-executable (Badness: 10000) /usr/lib/gridengine/utilbin/testsuidroot

I have no idea as to why osc thinks that.

Finally,


  326s] gridengine.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib64/libdrmaa.so

Again, I do not understand why osc thinks of the lib file as a development file.

Thank you very much in adnance, best, Stefan

#4

Hi
Just a reference to start with: https://en.opensuse.org/Portal:Packaging and https://en.opensuse.org/openSUSE:Packaging_checks

You can create a rpmlintrc (Source99: %{name}-rpmlintrc) file containing eg;


addFilter("libdrmaa.* devel-file-in-non-devel-package")

However, normally *.so file are placed in the devel package, so should fix…?

You can also reset the badness with the rpmlintrc file, eg;


setBadness('permissions-file-setuid-bit', 0)

Is the file gridengine a proper openSUSE sysconfig file, if so there are macros etc to install these properly, else consider fixing it to conform, plus then can use with YaST /etc/sysconfig editor.

Also look at removing the changelog entries out of the spec file into it’s own gridengine.changes file.

#5

Thanks, that brought me one step further again. Now, I get the related


Your package contains a single shared library but is not named after its SONAME

error, which relates to the above. Can this be solved with a badness reset again?

Thanks a lot.

#6

On Thu 16 Jun 2016 12:16:01 PM CDT, boehringers wrote:

malcolmlewis;2781601 Wrote:
> Hi
> Just a reference to start with:
> https://en.opensuse.org/Portal:Packaging and
> https://en.opensuse.org/openSUSE:Packaging_checks
>
> You can create a rpmlintrc (Source99: %{name}-rpmlintrc) file
> containing eg;
> >
Code:

> >
> addFilter(“libdrmaa.* devel-file-in-non-devel-package”)
>

> >
>
> However, normally *.so file are placed in the devel package, so should
> fix…?
>
>

Thanks, that brought me one step further again. Now, I get the related

Code:

Your package contains a single shared library but is not named after
its SONAME

error, which relates to the above. Can this be solved with a badness
reset again?

Thanks a lot.

Hi
Fix it so it’s correct?
https://en.opensuse.org/openSUSE:Shared_library_packaging_policy

Just need to add a lib…{soname} package.

–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.1|GNOME 3.16.2|4.1.21-14-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

#7

Thanks a lot for your help, the package is now building. One last question though. I added a library package for the library that was admonished. This package contains two library files: libdrmaa.so.1.0 and the symbolic link libdrmaa.so pointing to the same file. Again I get the error:


Your package contains a single shared library but is not named after its SONAME

This time, the error can be circumvented with:


addFilter("libdrmaa.* devel-file-in-non-devel-package")

However, there should be a better way.

Thanks in advance.

#8

On Fri 17 Jun 2016 08:26:01 PM CDT, boehringers wrote:

Thanks a lot for your help, the package is now building. One last
question though. I added a library package for the library that was
admonished. This package contains two library files: libdrmaa.so.1.0 and
the symbolic link libdrmaa.so pointing to the same file. Again I get the
error:

Code:

Your package contains a single shared library but is not named after
its SONAME

This time, the error can be circumvented with:

Code:

addFilter(“libdrmaa.* devel-file-in-non-devel-package”)

However, there should be a better way.

Thanks in advance.

Hi
There are still lots of warnings in the build results… can these be
cleaned up so can see the real warnings…?

You should be able to fix the no-soname by tweaking the configure.ac
file to add…

Add a changes file, use /usr/lib/build/spec2changelog to create the
changes file and then remove everything below %changelog;


Usage: cat foo.spec | spec2changes.pl > foo.changes

License format is detailed here http://spdx.org/licenses/

In your %files sections the first line under %files should be;


%defattr(-,root,root)

If you rem anything out the has a % you need to edit and add an extra%
so it’s ignored eg;


# %posttrans

would be

# %%posttrans

–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.1|GNOME 3.16.2|4.1.21-14-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

#9

Dear Malcom,

thank you very much for these suggestions. I had to get into production quickly and thanks to your help the package installs and runs fine under 13.2, x86_64. I am willing to clean up the warnings, both as a matter of making the package better and as a learning experience. However, I would like to see whether there is interest in the package as I intend to package some more projects for OpenSuse. Can package install counts be monitored somewhere?

One more remark: I find it highly irritating that the spec file parser does not ignore %-characters in comments. Also non-substituted %-characters should not result in obscure shell-errors but should stop the build process in the parsing stage. Is there any reason for this behavior?

Thanks, best,

Stefan

#10

Hi
There use to be an ability to see download counts, but not anymore, seems was fine when OBS started, but now too much changing data…

The % is a precursor to a macro, definition etc with rpm… hence the need to use %% to ignore that specific item else it will act on it and/or comment in the log.