February 2019 - openSUSE Science - openSUSE Mailing Lists

Re: [opensuse-science] New package: DAKOTA
by Egbert Eich 01 Mar '19

01 Mar '19

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(a)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(a)opensuse.org > > To contact the owner, e-mail: opensuse-science+owner(a)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(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

2 1

Re: [opensuse-science] New package: DAKOTA
by Egbert Eich 28 Feb '19

28 Feb '19

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(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

2 1

Re: [opensuse-science] New package: DAKOTA
by Egbert Eich 28 Feb '19

28 Feb '19

Hi Chris, Chris Coutinho writes: > Hello OpenSUSE Science, > > DAKOTA is a package developed at Sandia national labs, and used to > orchestrate numerical simulations for optimization and uncertainty > quantification. I've been using it for a while, always needing to build > it from source, and recently learned that I could actually build it on > OBS. Now that it's up there, I thought I would notify you all and > propose including it in the OpenSUSE:Science project. > > https://build.opensuse.org/package/show/home:cbcoutinho/dakota > > I have a couple questions: > > 1. Is the Science project accepting new packages? Yes. Please do 'osc sr science' from within you checked out project. There will be some review to make sure things are ok - especially, if you would like to have it in openSUSE:Factory it is important to stick the the packaging guidelines. > 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? Errors are an issue as they will contribute to the badness value. Warnings should be fixed, but we sometimes also see false positives I personally ignore them, you can filter them in an rpmlint script, however, this will draw the attention of the Factory reviewers, so you need to justify each filter rule. > 3. I included Python bindings and MPI by default. Does the Science > project require separate packages (e.g for with/without MPI)? This is up to you. If it can be built without MPI and there may be benefit to do this, you may want to do this as well. These days the preferred method would be to use multibuild and cover everything in a single spec file. https://openbuildservice.org/help/manuals/obs-reference-guide/cha.obs.multi… Cheers, Egbert. -- 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(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

1 0

[opensuse-science] New package: DAKOTA
by Chris Coutinho 28 Feb '19

28 Feb '19

Hello OpenSUSE Science, DAKOTA is a package developed at Sandia national labs, and used to orchestrate numerical simulations for optimization and uncertainty quantification. I've been using it for a while, always needing to build it from source, and recently learned that I could actually build it on OBS. Now that it's up there, I thought I would notify you all and propose including it in the OpenSUSE:Science project. https://build.opensuse.org/package/show/home:cbcoutinho/dakota I have a couple questions: 1. Is the Science project accepting new packages? 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? 3. I included Python bindings and MPI by default. Does the Science project require separate packages (e.g for with/without MPI)? Thanks, Chris

1 0

Re: [opensuse-science] leap 15.1
by Egbert Eich 27 Feb '19

27 Feb '19

Alin Marin Elena writes: > Hi All, > > with leap 15.1 repos being rolled shall we have one for this > http://download.opensuse.org/repositories/science:/HPC/ > > for the moment there is only one leap15 that may cause confusion. > Yes, IHMO, we should add leap 15.1 there. Nicolas, what do you think? Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

2 1

[opensuse-science] leap 15.1
by Alin Marin Elena 27 Feb '19

27 Feb '19

Hi All, with leap 15.1 repos being rolled shall we have one for this http://download.opensuse.org/repositories/science:/HPC/ for the moment there is only one leap15 that may cause confusion. Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

1 0

[opensuse-science] openmpi/libfabric
by Alin Marin Elena 18 Feb '19

18 Feb '19

Dear all, we are affected by this bug too https://bugzilla.redhat.com/show_bug.cgi?id=1408316 any chance for an update. Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

2 3