Chris Coutinho writes:

Hi Egbert,

I've fixed all the errors that were mentioned in the log file and cleaned up some of the rpmlnt output. Now I've submitted the package for review.

Yup. Thanks! I've seen your submission. Will wait until the build is done and take a look. One thing that we may want to address is the inclusion of the libboost. It's a bit ugly to have to define a version. This is bound to break eventually.

Thanks again for your feedback.

Sure. Cheers, Egbert.

Chris.

On Thu, 28 Feb 2019 at 15:35, Egbert Eich <eich@suse.com> wrote:

...

Hi Chris,

Chris Coutinho writes:

...

Hi Egbert,

Thanks for you reply and feedback. I made some adjustments to the spec file and removed all the spec files - now I'm stuck at one rpmlint problem keeping me above a badness value of 1000, namely the 'arch-dependent-file-in-usr-share' error.

See my project build log for the error I'm talking about.

I'm seeing this: [ 1436s] dakota-examples.x86_64: E: arch-dependent-file-in-usr-share (Badness: 590) /usr/share/dakota/examples/hopspack/1-var-bnds-only/var_bnds_only [ 1436s] dakota-examples.x86_64: E: arch-dependent-file-in-usr-share (Badness: 590) /usr/share/dakota/examples/hopspack/2-linear-constraints/linear_constraints [ 1436s] dakota-examples.x86_64: E: arch-dependent-file-in-usr-share (Badness: 590) /usr/share/dakota/examples/hopspack/3-degen-linear-constraints/degen_linear_constraints [...]

I'd assume these files are binaries (ie have the execution flag set). These should not be installed in /usr/share. Instead you may want to consider to either move the entire structure /usr/share/dakota(/examples) to /usr/lib/dakota or at least do this with a subset of the files - like the example binaries. If there is no option to tell cmake to do this, you can move them 'manually' in the spec file afterwards.

[ 1436s] dakota.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib/librol.so [ 1436s] dakota.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib/libteuchoscomm.so [ 1436s] dakota.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib/libteuchoscore.so [ 1436s] dakota.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib/libteuchosnumerics.so [...]

are there also versioned so files of the same name? ie. some /usr/lib/librol.so.x.y.z? If so, the unversioned .so is just a link and should go to the devel package. Another issue might be that shared libraries on x86_64 should go to /usr/lib64/ not /usr/lib/. This is happening despite the %cmake macro adding these config parameters: -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib64 I guess you could either fix how the project uses cmake (and submit the patch upstream) or move things manually.

[ 1436s] dakota-examples.x86_64: E: env-script-interpreter (Badness: 9) /usr/share/dakota/examples/parallelism/Case3-EvaluationTiling/OpenMPI/text_book_di_dynamic.py /usr/bin/env python [ 1436s] dakota-examples.x86_64: E: env-script-interpreter (Badness: 9) /usr/share/dakota/examples/script_interfaces/Python/rosenbrock_bb.py /usr/bin/env python [...]

These things should be easy to fix. For HPC-style packages we have an RPM macro for it.

...

The binaries rpmlint is complaining about are related to the examples.

Ok.

...

In principle, the binaries are specific to the directories they're in - I don't think moving them to /usr/lib/ is really applicable. Any tips?

Why not? The LSB considers /usr/share as shareable among machines - even ones with different archiectures. /usr/lib on the other hand is considered arch-specific, thus it may contain arch-specific binaries as well. I haven't looked at the content of these directories, but if they contain data etc. that needs to live next to the binaries, you would have to put this into /usr/lib as well: there is nothing that would prevent you to put arch-independent stuff in there as well.

Cheers, Egbert.

...

Regards, Chris

On Thu, 28 Feb 2019 at 08:34, Egbert Eich <eich@suse.com> wrote:

...

Hi Chris,

Chris Coutinho writes:

...

2. Currently it builds using a simple patch (known by the developers) and ignoring all rpmlint warnings/errors. I'm assuming included packages shouldn't just ignore all errors. What's the policy for dealing with that?

I've just looked at your package and the rpmlitrc file you've added. This file will definitely not go past the beam counters and quite a few things that ought to be fixed.

These are Nonos and most are easy to fix: addFilter("dakota.* files-duplicate") addFilter("dakota.* library-without-ldconfig-postin") addFilter("dakota.* library-without-ldconfig-postun") addFilter("dakota.* no-changelogname-tag") addFilter("dakota.* non-executable-in-bin") addFilter("dakota.* non-executable-script") addFilter("dakota.* script-without-shebang") addFilter("dakota.* zero-length") addFilter("dakota.* arch-dependent-file-in-usr-share") addFilter("dakota.* devel-file-in-non-devel-package") addFilter("dakota.* env-script-interpreter") addFilter("dakota.* files-duplicated-waste")

These depend, some might be false positives: addFilter("dakota.* position-independent-executable-suggested") addFilter("dakota.* shared-lib-without-dependency-information") addFilter("dakota.* shlib-policy-missing-suffix")

I don't remember a single HPC/scientiffic library which doesn't trigger this - this I just ignore it: addFilter("dakota.* shared-lib-calls-exit")

You may want to run: osc service run format_spec_file to sanitize your spec file.

It looks like you've used the spec file from the upstream project. Unfortunately, spec files from upstream projects are not always up to the standards required by distributions.

Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-science+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-science+owner@opensuse.org

-- Egbert Eich (Res. & Dev.) SUSE LINUX GmbH SUSE Labs - Project Manager HPC Tel: +49 911-740 53 0 http://www.suse.com ----------------------------------------------------------------- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, D90409 Nürnberg, Germany-- To unsubscribe, e-mail: opensuse-science+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-science+owner@opensuse.org

-- Egbert Eich (Res. & Dev.) SUSE LINUX GmbH SUSE Labs - Project Manager HPC Tel: +49 911-740 53 0 http://www.suse.com ----------------------------------------------------------------- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, D90409 Nürnberg, Germany-- To unsubscribe, e-mail: opensuse-science+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-science+owner@opensuse.org