Results 1 to 10 of 10

Thread: Problem with packaging the Open Grid Scheduler

  1. #1

    Default Problem with packaging the Open Grid Scheduler

    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/...cef622a3a96f6d), logs attached. However, OBS fails (https://build.opensuse.org/package/l...SE_13.2/x86_64) the build and it is unclear to me where the problem lies.

    Any help appreciated.

  2. #2
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    28,516
    Blog Entries
    15

    Default Re: Problem with packaging the Open Grid Scheduler

    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;

    Code:
    %dir %{_datadir}/X11
    %dir %{_datadir}/X11/app-defaults
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  3. #3

    Default Re: Problem with packaging the Open Grid Scheduler

    Dear Malcom,

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

    Code:
    [  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:

    Code:
    [  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.
    Code:
    [  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,
    Code:
    [  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. #4
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    28,516
    Blog Entries
    15

    Default Re: Problem with packaging the Open Grid Scheduler

    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...?

    You can also reset the badness with the rpmlintrc file, eg;
    Code:
    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.
    Last edited by malcolmlewis; 10-Jun-2016 at 07:11.
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  5. #5

    Default Re: Problem with packaging the Open Grid Scheduler

    Quote Originally Posted by malcolmlewis View Post
    Hi
    Just a reference to start with: https://en.opensuse.org/Portalackaging and https://en.opensuse.org/openSUSEackaging_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.

  6. #6
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    28,516
    Blog Entries
    15

    Default Re: Problem with packaging the Open Grid Scheduler

    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/Portalackaging and
    > https://en.opensuse.org/openSUSEackaging_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:Sha...ckaging_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. #7

    Default Re: Problem with packaging the Open Grid Scheduler

    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.

  8. #8
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    28,516
    Blog Entries
    15

    Default Re: Problem with packaging the Open Grid Scheduler

    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;
    Code:
    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;
    Code:
    %defattr(-,root,root)
    If you rem anything out the has a % you need to edit and add an extra%
    so it's ignored eg;

    Code:
    # %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. #9

    Default Re: Problem with packaging the Open Grid Scheduler

    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


    Quote Originally Posted by malcolmlewis View Post
    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;
    Code:
    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;
    Code:
    %defattr(-,root,root)
    If you rem anything out the has a % you need to edit and add an extra%
    so it's ignored eg;

    Code:
    # %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!

  10. #10
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    28,516
    Blog Entries
    15

    Default Re: Problem with packaging the Open Grid Scheduler

    Quote Originally Posted by boehringers View Post
    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
    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.
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •