dune-grid: Please give back some 32bit builds for migration

[Markus Blatt]

Hi,

Please give-back the i386, armel, and armhf builds [1]. As a maintainer I am 
not in group Debian and cannot do it myself and reuploading seems a waste of 
resources.

dune-grid has troubles migrating to testing due to failing builds with previous 
buggy OpenMPI versions. In the current version of OpenMPI in Sid this should be 
resolved, but this needs a rebuild on i386, armel, and armhf to pick the 
versions up.

Thanks a lot.

Best,

Markus

[1] 

Re: alberta: FTBS on ppc64el fixed but Sponsor for uploading needed

[Markus Blatt]

Hi,

I have uploaded the fixed version and merged the branches.

Thanks a lot.

Best,
Markus

Re: alberta: FTBS on ppc64el fixed but Sponsor for uploading needed

[Markus Blatt]

Hi Nilesh,

Am Mon, Mar 11, 2024 at 08:59:16PM +0530 schrieb Nilesh Patra:

On Mon, Mar 11, 2024 at 11:44:25AM +0100, Markus Blatt wrote:

Just Maintainer of some packages but not alberta.


That should change in a few minutes? :-)


thanks a lot.

Would be cool, if you would confirm that my additions because of 64bit time_t 
are ok, too:
https://salsa.debian.org/science-team/alberta/-/merge_requests/3/diffs

After that I will try the upload.

Best,

Markus

Re: alberta: FTBS on ppc64el fixed but Sponsor for uploading needed

[Markus Blatt]

Hi,

Unfortunately, there was another error due to a problem in tdwz with dwarfv5 
[3] produced
by default when compiling with clang. I got the error:

dh_dwz
dwz: 
debian/libalberta4t64/usr/lib/powerpc64le-linux-gnu/libalberta_1d.so.4.0.0: 
Unknown debugging section .debug_addr

To fix it we now use the -gdwarf-4 compiler option with clang.

Now the package builds in a ppc64el chroot on my system.

Markus

Am Mon, Mar 11, 2024 at 11:44:25AM +0100 schrieb Markus Blatt:

Dear all,

I was able to fix the FTBFS bug 1060076 [1] by backporting two upstream patches.
You can find my changes in  MR [2]. Note that this also adds the 
changes for the 64bit time_t transition made in version 3.0.3-1.1 to 
the repository. Those

were missing before.

I am not Debian Developer. Just Maintainer of some packages but not alberta.
Hence I need a sponsor for the upload. Hopefully somebody from the Science team
is so kind as to do this.

Thanks a lot.

Best,

Markus

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060076
[2] https://salsa.debian.org/science-team/alberta/-/merge_requests/4

[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016936

alberta: FTBS on ppc64el fixed but Sponsor for uploading needed

[Markus Blatt]

Dear all,

I was able to fix the FTBFS bug 1060076 [1] by backporting two upstream patches.
You can find my changes in  MR [2]. Note that this also adds the changes for 
the 64bit time_t transition made in version 3.0.3-1.1 to the repository. Those

were missing before.

I am not Debian Developer. Just Maintainer of some packages but not alberta.
Hence I need a sponsor for the upload. Hopefully somebody from the Science team
is so kind as to do this.

Thanks a lot.

Best,

Markus

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060076
[2] https://salsa.debian.org/science-team/alberta/-/merge_requests/4


signature.asc
Description: PGP signature

alberta: Incorporate changes from 64-bit time_t transition in vcs.

[Markus Blatt]

Hi,

I would like to a the FTBS bug in alberta.
Unfortunately the salsa repository is not up date because the changes done for 
the 64-bit time_t transition
are not in the repo.

I creates an MR [1] based on what I found in alberta_3.0.3-1.1.debian.tar.xz. 
Would be nice if someone would
double check that. Thanks a lot.

Best,
Markus
[1] https://salsa.debian.org/science-team/alberta/-/merge_requests/3

Bug#1055857: transition: opm-common

[Markus Blatt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-science@lists.debian.org

Dear Debian release team,

A new upstream release of OPM is available. To ease migration to testing I am
requesting a mini-transition. Uploading to unstable would probably work even
without a transition, but I would like to play it safe.

This should only affect the OPM source packages opm-common, opm-grid, opm-
models, opm-simulators and opm-upscaling.

I have already uploaded new versions to experimental that seemed to have built
without any issues, see [1].
(please explain about the transition: impacted packages, reason, ...
 for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions)

Ben file:

title = "libopm-common-2023";
is_affected = .depends ~ "libopm-common-2023.04" | .depends ~ "libopm-
common-2023.10";
is_good = .depends ~ "libopm-common-2023.10";
is_bad = .depends ~ "libopm-common-2023.04";

Thanks a lot.

Kind regards,

Markus

[1] https://qa.debian.org/developer.php?login=markus%40dr-blatt.de

Please giveback opm-model/2023.04+ds-2 build on mips64el

[Markus Blatt]

Hi,

For opm-models the build on mips64el was failing due to a missing build of opm-common 
for that architecture, see [1].
I have fixed the build issue on mips64el for opm-common in version 2023.04+ds-5, see [2], 
and the binaries should be installable now.


I would be really cool if a Debian Developer would press giveback at [1] to 
trigger another build.
As a mainainer I am not allowed to do that.

Thanks a lot.

Cheers,

Markus

[1] https://buildd.debian.org/status/package.php?p=opm-models
[2] https://buildd.debian.org/status/package.php?p=opm-common

Re: Please give-back armhf build of opm-common-2022.10+ds-6

[Markus Blatt]

Hi Drew,

Thanks a lot.

I guess I will need to limit the architectures again then and definitely exclude
armhf.

This will also fix the issue that OPM is blocked because of autopkgtest not 
being run
on architectures where no binaries are built.

Best,

Markus

Am Wed, Mar 22, 2023 at 05:15:30PM +0100 schrieb Drew Parsons:
The armhf (and x32) failure seems enduring.  I guess it needs to be 
fixed in code. Or ignored.


Drew

On 2023-03-22 15:07, Drew Parsons wrote:

done

On 2023-03-22 12:48, Markus Blatt wrote:

Hi,

somehow the armhf build of opm-common-2022.10+ds-6 failed. This 
seems to happen

from time to time, see [1]. Not nice, but I am unable to replicate
this. There were
no changes between the versions that would explain the build failure

Would be cool if someone with Debian Developer status could give-back
that build to
buildd at [2] and it will hopefully succeed. Then this migth migrate
once unblocked.
Note that autopkgtests succeed for all architectures where binaries
are actually built.

There are two important fixes that make this worth-while:
- Build time has been drastically reduced (factor > 2), see [3].
(There was a massive
 increase in built time when gcc-12 was introduced)
- Printed version string in programs is correct ("2022.10 (Debian
GNU/Linux 12 (bookworm):
 2022.10+ds-1+b2)" instead of "2022.10 ( lsb_release -r | sed
s/.*:s*([^s]*).*/1/: 2022.10+ds-1+b2)")

Best,

Markus
[1] <https://buildd.debian.org/status/logs.php?pkg=opm-common=armhf>
[2] <https://buildd.debian.org/status/package.php?p=opm-common>
[3] <https://buildd.debian.org/status/logs.php?pkg=opm-common=amd64>





--

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858

Please give-back armhf build of opm-common-2022.10+ds-6

[Markus Blatt]

Hi,

somehow the armhf build of opm-common-2022.10+ds-6 failed. This seems to happen
from time to time, see [1]. Not nice, but I am unable to replicate this. There 
were
no changes between the versions that would explain the build failure

Would be cool if someone with Debian Developer status could give-back that 
build to
buildd at [2] and it will hopefully succeed. Then this migth migrate once 
unblocked.
Note that autopkgtests succeed for all architectures where binaries are 
actually built.

There are two important fixes that make this worth-while:
- Build time has been drastically reduced (factor > 2), see [3]. (There was a 
massive
  increase in built time when gcc-12 was introduced)
- Printed version string in programs is correct ("2022.10 (Debian GNU/Linux 12 
(bookworm):
  2022.10+ds-1+b2)" instead of "2022.10 ( lsb_release -r | sed s/.*:s*([^s]*).*/1/: 2022.10+ds-1+b2)") 


Best,

Markus
[1] 
[2] 
[3] 

Re: Changes for new upstream version (2.9.0) of DUNE (Mini-transition because of OPM)

[Markus Blatt]

Dear Graham,

Am Sun, Jan 15, 2023 at 04:25:04PM +0200 schrieb Graham Inggs:

Hi Markus

On Tue, 3 Jan 2023 at 02:46, Markus Blatt  wrote:

Nevertheless opm-grid, opm-material, opm-models, opm-simulators, and 
opm-upscaling will
need to be rebuild for the mini-transition. Otherwise they won't work correctly


I found out about this transition after an Ubuntu developer asked me
to schedule binNMUs for some opm-* packages.  In future, you can
follow steps described [1] and file a transition bug against
release.debian.org. For now, I have scheduled binNMUs for opm-grid,
opm-material, opm-models, opm-simulators, and opm-upscaling.

I've also set up a transition tracker [2], with the following ben file:

[2] https://release.debian.org/transitions/html/dune-common-2.9.0.html


Thanks a lot Graham. That really worked like a charm and seem to finished. 
Cool.These processes
and the tools in Debian are really great.

Next time I will try to do that myself to avoid confusion.
Is the upload to NEW for dune-common optional as the package name stays the 
same?

Cheers,

Markus
--

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858

Changes for new upstream version (2.9.0) of DUNE (Mini-transition because of OPM)

[Markus Blatt]

Hi,

happy new year to everyone.

There has been a new upstream version of DUNE for some time. As Ansgar is burried 
in work, I have prepared changes and merge requests for the Debian packages tob bring 
DUNE 2.9.0 into Debian. Those changes are based on the upstream tag v2.9.0 of each 
upstream repository (use dune-common/debian/get-orig-source dune-module 2.9.0 v2.9.0" 
to create the tarballs). As I am just a DM with no upload rights for DUNE I cannot do 
more at  the moment. Hope somebody else take over the upload (to experimental?). Maybe 
Ansgar or somebody can find some time?


I have tested these changed in experimental (from Christmas) together with the OPM packages 
that depend on DUNE and that I maintain. This worked. For current experimental there seems 
to be an issue for dune-grid because the dependency on python3 (via python3-vtk9) is not 
resolvable due to an ongoing transition (Make python-3.11 the default).


Note that because OPM depends on DUNE this seems to be a Mini-transition. Unfortunately, I 
have no experience with this.


You can find the merge request for DUNE at:
- dune-common: 
https://salsa.debian.org/science-team/dune-common/-/merge_requests/4
- dune-geometry: 
https://salsa.debian.org/science-team/dune-geometry/-/merge_requests/5
- dune-grid: https://salsa.debian.org/science-team/dune-grid/-/merge_requests/3
- dune-istl: https://salsa.debian.org/science-team/dune-istl/-/merge_requests/3
- dune-tyeptree: 
https://salsa.debian.org/science-team/dune-typetree/-/merge_requests/4
- dune-localfunctions: 
https://salsa.debian.org/science-team/dune-localfunctions/-/merge_requests/4
- dune-functions: 
https://salsa.debian.org/science-team/dune-functions/-/merge_requests/3
- dune-grid-glue: 
https://salsa.debian.org/science-team/dune-grid-glue/-/merge_requests/2

The changes needed for OPM to work with the new version were not to many. Only one package 
needed changes in the packaging:

- opm-common: 
https://salsa.debian.org/science-team/opm-common/-/merge_requests/2

Nevertheless opm-grid, opm-material, opm-models, opm-simulators, and 
opm-upscaling will
need to be rebuild for the mini-transition. Otherwise they won't work correctly

If it is possible to give me upload rights for the DUNE packages, then I could do the 
upload/transition work myself, too. But I would still require some guidance (next steps, etc.) 
and don't want to step on other people's toes.


Thanks a lot for the help.

Cheers,

Markus

Re: Please giveback arm64 build of opm-simulators in experimental

[Markus Blatt]

Am Mon, May 02, 2022 at 10:55:23AM +0200 schrieb Timo Röhling:

The package was BD-Uninstallable because I was faster than Gard and
you, and the giveback reverts to the BD-Uninstallable check while
buildd figures out whether or not all build dependencies are installable.

The package is building now.


thanks a lot guys. That did the job. And sorry for the human deadlock situation 
;)

Markus


signature.asc
Description: PGP signature

Please giveback arm64 build of opm-simulators in experimental

[Markus Blatt]

Hi,

Would be cool if someone with the necessary right would press "giveback" for the arm64 build at [1]. 
Unfortunately, I cannot do that myself (as a Debian Maintainer) as buildd says "You need to be in the "debian" group for now.". 
The issue of the build should be fixed in the recently uploaded opm-common version 2022.04~rc1-2,

which should be picked up by the build.

Thanks a lot.

Markus

[1] 
https://buildd.debian.org/status/package.php?p=opm-simulators=experimental


signature.asc
Description: PGP signature

Re: libscotch-dev/7.0.1-2: Why is there no libscotchmetis.so?

[Markus Blatt]

Am Fri, Mar 18, 2022 at 11:51:38PM +0100 schrieb Drew Parsons:
As for /usr/share/dune/cmake/modules/FindMETIS.cmake, it does handle 
the scotchmetis version via METIS_API_VERSION


If it's then going to look for find_library(METIS_LIBRARY 
scotchmetis), then for scotch 7 that should be updated to

find_library(METIS_LIBRARY scotchmetisv$(METIS_API_VERSION))




Thanks. Already provided a patch 
https://salsa.debian.org/science-team/dune-common/-/merge_requests/3

libscotch-dev/7.0.1-2: Why is there no libscotchmetis.so?

[Markus Blatt]

Hi,

while investigating several bugs [1] [2] [3] caused by the scotch transition,
I started wondering why there is no libscotchmetis.so library but just
libscotchmetisv3.so and libscotchmetisv5.so.

The cause for the bugs seems to be that the CMake scripts only search for 
libscotchmetis.so.
This can be fixed in dune-common by searching for the correct version. An
alternative fix might be that libscotch-dev also ships a libscotchmetis.so that 
points
to one of those.

Markus

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007823
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007830
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007930


signature.asc
Description: PGP signature

Re: RFS: source-only upload of opm-{grid,simulators,upscaling}/2021.10-2

[Markus Blatt]

Hi Nilesh,

Am Sat, Feb 26, 2022 at 12:57:45PM +0530 schrieb Nilesh Patra:

On 2/17/22 8:52 PM, Nilesh Patra wrote:

Optionally it would be nice to also upload the new versions of opm-material
and opm-model, where mainly fix the Architectures in d/control such that
buildd will try to build them on all available architectures. But I can also
do that later, when key is added to the keyring of Debian Maintainers. No
rush here.


Ai'ght, let's wait for your keys to be added :)
Please remind us when that happens.


Looks like this is done, as per[1] - Congrats!
I have granted you DM access for all of your opm-* packages so you should be 
able
to upload them on your own now (you would have gotten a mail about this)



Cool, thanks a lot for that.

Markus



signature.asc
Description: PGP signature

Re: RFS: source-only upload of opm-{grid,simulators,upscaling}/2021.10-2

[Markus Blatt]

Hi,

Am Mon, Feb 21, 2022 at 08:55:55PM +0530 schrieb Nilesh Patra:

[...]
Updated source can be found at
https://salsa.debian.org/science-team/opm-upscaling
https://salsa.debian.org/science-team/opm-simulators

UNRELEASED and untagged as requested, but version incremented.


Great, thanks for working on these, I uploaded both.



Seems like the failing tests on platforms might still prevent migration
to testing:
https://qa.debian.org/excuses.php?package=opm-simulators
https://qa.debian.org/excuses.php?package=opm-upscaling

On those platforms there are no binary packages due to missing dependencies.

If that is a problem for migration of the source packages and the successfully
tested binary packages, then I have prepared new versions of the packages
that use "Restrictions: skip-not-installable" to d/tests/control to skip these.

In that case please review and upload the status of
https://salsa.debian.org/science-team/opm-simulators
https://salsa.debian.org/science-team/opm-upscaling

Thanks a lot. I owe you quite some beverages by now...

Markus

Re: RFS: source-only upload of opm-{grid,simulators,upscaling}/2021.10-2

[Markus Blatt]

Hi Ansgar,

Am Mon, Feb 21, 2022 at 05:16:40PM +0100 schrieb Ansgar:


On Mon, 2022-02-21 at 15:55 +0100, Markus Blatt wrote:


No need to list it again and I removed the offending entry:

Build-Depends: ..., libsuperlu3-dev (>= 3.0) | libsuperlu-dev (>=
4.3), ...

Maybe buildd is different and does not allow packages that do not
exist?


To get reliable build results, the buildd network removes alternative
build dependencies when building for unstable; only the first
alternative is used.  They are only used for the *-backports and
experimental suites (I admit I'm not sure about stable uploads, but
they should *not* be used there).


Thanks for the explanation.

Markus



signature.asc
Description: PGP signature

Re: RFS: source-only upload of opm-{grid,simulators,upscaling}/2021.10-2

[Markus Blatt]

Hi Nilesh,

Am Mon, Feb 21, 2022 at 01:07:02AM +0530 schrieb Nilesh Patra:


On Thu, Feb 17, 2022 at 10:28:58PM +0100, Markus Blatt wrote:

> Done, thanks for your work!

Thanks a lot.


Looks like opm-upscaling and opm-simulators are not building on buildd machines
as seen here[1][2]
It chokes at missing B-D[3]

| opm-upscaling build-depends on missing:
| - libsuperlu3-dev:amd64 (>= 3.0)

Can you check+fix this?



Thanks for the hint. Somehow this was not a problem for salsaci and local 
pbuilder. There
used to be a libsuperlu3-dev package in older Debian releases. Anyway the 
dependency on
libsuperlu-dev and libsuitesparse-dev is already handled as a dependency of 
libdune-istl-dev.
No need to list it again and I removed the offending entry:

Build-Depends: ..., libsuperlu3-dev (>= 3.0) | libsuperlu-dev (>= 4.3), ...

Maybe buildd is different and does not allow packages that do not exist?

I also fixed an autpkgtest problem for python3-opm-simulators (for 2021.10-1
autodep8-python3 did add a test that tried to import opm_simulators, but we use
opm.simulators instead). I simply added a custom python test. Hope that will
prevent the autogeneration. Works on salsaci.

Updated source can be found at
https://salsa.debian.org/science-team/opm-upscaling
https://salsa.debian.org/science-team/opm-simulators

UNRELEASED and untagged as requested, but version incremented.

Thanks a lot for the help.

Cheers,

Markus


signature.asc
Description: PGP signature

Re: RFS: source-only upload of opm-{grid,simulators,upscaling}/2021.10-2

[Markus Blatt]

Hi Nilesh,

Am Thu, Feb 17, 2022 at 08:52:26PM +0530 schrieb Nilesh Patra:

these packages have been accepted by ftp-master into Debian.

You can find the status quo at
https://salsa.debian.org/science-team/opm-grid
https://salsa.debian.org/science-team/opm-simulators
https://salsa.debian.org/science-team/opm-upscaling
To facilitate migration to testing, we need to reupload the
source packages. [...]


Done, thanks for your work!


Thanks a lot.



Minor nitpick: Please do not push the debian/ tag when you are asking 
for sponsorship,
usually the uploader would push that. It is also suggested to leave the 
changelog entry to
UNRELEASED - before RFS, so it does not create any confusion



thanks for the info. That makes sense. Will do the next time.

Cheers,

Markus

RFS: source-only upload of opm-{grid,simulators,upscaling}/2021.10-2

[Markus Blatt]

Hi,

these packages have been accepted by ftp-master into Debian.
Thanks a lot for the work of everybody involved.

You can find the status quo at
https://salsa.debian.org/science-team/opm-grid
https://salsa.debian.org/science-team/opm-simulators
https://salsa.debian.org/science-team/opm-upscaling

To facilitate migration to testing, we need to reupload the
source packages. I have cleaned up dependencies and other issues
in d/control. Added autopkgtests to opm-simulators and opm-upscaling.
Activated autopkgtest in salsaci.

Optionally it would be nice to also upload the new versions of opm-material
and opm-model, where mainly fix the Architectures in d/control such that
buildd will try to build them on all available architectures. But I can also
do that later, when key is added to the keyring of Debian Maintainers. No
rush here.

https://salsa.debian.org/science-team/opm-material
https://salsa.debian.org/science-team/opm-models

Thanks a lot.

Cheers,

Markus

Would be cool 
--


Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858

Re: RFS: opm-common/2021.10-3 [QA] -- Tools for Eclipse reservoir simulation files

[Markus Blatt]

Hi,

Am Fri, Jan 28, 2022 at 07:12:23PM +0100 schrieb Anton Gladky:

Uploaded as well.



Thanks a lot.


I had almost no questions about your technical packaging level. I would
encourage you to apply to a DM-role, if you are interested. I will
definitely advocate your application and then give you permissions
to upload opm-stuff if you apply.



That would be cool. I already applied for DM rights, see 
https://nm.debian.org/process/1008/


Cheers,

Markus

Re: RFS: opm-common/2021.10-3 [QA] -- Tools for Eclipse reservoir simulation files

[Markus Blatt]

Hi Anton,

thanks a lot for the work. Highly appreciated.

Did you also upload opm-upscaling to NEW?

opm-upscaling/2021.10-1  https://salsa.debian.org/science-team/opm-upscaling

Did not receibve any notification and can't see. Maybe it just needs more
time for processing?

Markus

Am Thu, Jan 27, 2022 at 07:14:45PM +0100 schrieb Anton Gladky:

Hi Markus,

done!

Best regards

Anton

Am Mi., 26. Jan. 2022 um 14:44 Uhr schrieb Markus Blatt :


Hi,
Am Wed, Jan 26, 2022 at 07:26:09AM +0100 schrieb Anton Gladky:
>
>I will upload it in the evening. Please prepare all other involved
>packages if any. Thanks. Regards
>

cool. Thanks in advance.

Source uploads needed for migration to testing:
- opm-common/2021.10-3 https://salsa.debian.org/science-team/opm-common
- opm-material/2021.10-2 https://salsa.debian.org/science-team/opm-material
- opm-models/2021.10-2  https://salsa.debian.org/science-team/opm-models


These are the ones that were rejected by ftpmaster and copyright should be 
fixed now.
Please upload to new
- opm-grid/2021.10-1  https://salsa.debian.org/science-team/opm-grid
- opm-simulators/2021.10-1  https://salsa.debian.org/science-team/opm-simulators
- opm-upscaling/2021.10-1  https://salsa.debian.org/science-team/opm-upscaling

Cheers,

Markus


>
>Am Di., 25. Jan. 2022 um 00:00 Uhr schrieb Markus Blatt :
>>
>> Hi,
>>
>> I am looking for a sponsor for my package "opm-common" to do a source upload:
>>
>>   * Package name: opm-common
>> Version : 2021.10-3
>> Upstream Author : o...@opm-project.org
>>   * URL : http://opm-project.org
>>   * License : GPL-2.0+, GPL-3.0+, ODBL-1.0 and DBCL-1.0
>>   * Vcs : https://salsa.debian.org/science-team/opm-common
>> Section : libs
>>
>> The package was still not good enough.
>> We had limited the architectures in d/control to 64bit, but not in 
d/tests/control and
>> that would have prevented the source package from migrating to testing as 
the autopkgtests
>> for 32bit would still be executed and fail due to missing binary packages.
>>
>> After a fruitful discussions on the mentors list, see
>> https://lists.debian.org/debian-mentors/2022/01/msg00185.html, I have now
>>
>> - used "Architecture: any" in d/control to let buildd try to build all 
(32bit builds will fail due to failing ctest)
>> - limited to 64bit architectures in d/tests/control to prevent failing 
autopkgtest
>>
>> I hope that this will allow for migration to testing.
>>
>> Thanks a lot.
>>
>> Cheers,
>>
>> Markus
>>
>

--

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858




--

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858

Re: RFS: opm-common/2021.10-3 [QA] -- Tools for Eclipse reservoir simulation files

[Markus Blatt]

Hi,
Am Wed, Jan 26, 2022 at 07:26:09AM +0100 schrieb Anton Gladky:


I will upload it in the evening. Please prepare all other involved
packages if any. Thanks. Regards



cool. Thanks in advance.

Source uploads needed for migration to testing:
- opm-common/2021.10-3 https://salsa.debian.org/science-team/opm-common
- opm-material/2021.10-2 https://salsa.debian.org/science-team/opm-material
- opm-models/2021.10-2  https://salsa.debian.org/science-team/opm-models


These are the ones that were rejected by ftpmaster and copyright should be 
fixed now.
Please upload to new 
- opm-grid/2021.10-1  https://salsa.debian.org/science-team/opm-grid

- opm-simulators/2021.10-1  https://salsa.debian.org/science-team/opm-simulators
- opm-upscaling/2021.10-1  https://salsa.debian.org/science-team/opm-upscaling

Cheers,

Markus




Am Di., 25. Jan. 2022 um 00:00 Uhr schrieb Markus Blatt :


Hi,

I am looking for a sponsor for my package "opm-common" to do a source upload:

  * Package name: opm-common
Version : 2021.10-3
Upstream Author : o...@opm-project.org
  * URL : http://opm-project.org
  * License : GPL-2.0+, GPL-3.0+, ODBL-1.0 and DBCL-1.0
  * Vcs : https://salsa.debian.org/science-team/opm-common
Section : libs

The package was still not good enough.
We had limited the architectures in d/control to 64bit, but not in 
d/tests/control and
that would have prevented the source package from migrating to testing as the 
autopkgtests
for 32bit would still be executed and fail due to missing binary packages.

After a fruitful discussions on the mentors list, see
https://lists.debian.org/debian-mentors/2022/01/msg00185.html, I have now

- used "Architecture: any" in d/control to let buildd try to build all (32bit 
builds will fail due to failing ctest)
- limited to 64bit architectures in d/tests/control to prevent failing 
autopkgtest

I hope that this will allow for migration to testing.

Thanks a lot.

Cheers,

Markus





--

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858

RFS: opm-common/2021.10-3 [QA] -- Tools for Eclipse reservoir simulation files

[Markus Blatt]

Hi,

I am looking for a sponsor for my package "opm-common" to do a source upload:

 * Package name: opm-common
   Version : 2021.10-3
   Upstream Author : o...@opm-project.org
 * URL : http://opm-project.org
 * License : GPL-2.0+, GPL-3.0+, ODBL-1.0 and DBCL-1.0
 * Vcs : https://salsa.debian.org/science-team/opm-common
   Section : libs

The package was still not good enough.
We had limited the architectures in d/control to 64bit, but not in 
d/tests/control and
that would have prevented the source package from migrating to testing as the 
autopkgtests
for 32bit would still be executed and fail due to missing binary packages.

After a fruitful discussions on the mentors list, see 
https://lists.debian.org/debian-mentors/2022/01/msg00185.html, I have now


- used "Architecture: any" in d/control to let buildd try to build all (32bit 
builds will fail due to failing ctest)
- limited to 64bit architectures in d/tests/control to prevent failing 
autopkgtest

I hope that this will allow for migration to testing.

Thanks a lot.

Cheers,

Markus

Re: RFS: opm-common/2021.10-1 [QA] -- Tools for Eclipse reservoir simulation files

[Markus Blatt]

Hi,

Am Fri, Jan 21, 2022 at 10:11:05PM +0100 schrieb Ansgar:

I uploaded the package.




thanks.


Do I need to do something for opm-material or will that get resolved
automatically?


The build service should automatically note when the dependency gets
installable. However, the package will need a source-only upload (no
changes) to be allowed to migrate to testing.


Will do that ones QA page confirms that opm-commom works,

MArkus

Re: RFS: reupload of opm-common/2021.10-1

[Markus Blatt]

Hi Andreas,

Am Fri, Jan 21, 2022 at 02:02:22PM +0100 schrieb Andreas Tille:

please always remember that we should update Debian Science tasks[1]
to feature all our packages.  Please let me know in what task(s!) opm
should be listed.



thanks for asking. I was wondering how this works.

I would propose to list all modules as

engineering, engineering-dev, simulation, mathematics, mathematics-dev, 
physics, physics-dev

Of course the simulation(-tools) use and provide mathematics (linear,non-linear 
solvers,
pdes, etc.) and use physics (models for subsurface flaw). Hence could/should 
also add
You can see hat I am struggeling a bit here and it is not 100% clear to me what 
a mathematics/physics
package is and what not.

But it is definitely nothing of the rest, for sure ;)

Cheers,

Markus


Am Fri, Jan 21, 2022 at 01:23:20PM +0100 schrieb Markus Blatt:

Hi,

opm-common [0] and opm-material [1] have now been accepted by ftpmaster into 
unstable. Thanks a lot for that.

The upload to ftpmaster was in 11/2021 and as a result the binary-package 
opm-common still has
a dependency on libfmt7. That library is now replaced by libfmt8. Hence the 
package has an unsatisfied
dependency on libfmt7.

Would be cool if somebody would reupload the source package opm-common [2] 
again to resolve this.

Due to opm-common not building opm-material has an unsatisfied dependency on 
libopm-common-dev. I
hope that this gets resolved automatically by just reuploading the opm-common 
source package.

If there is something that I can help with or need to do then please yell.

Thanks a lot.

Regards,

Markus

[0] https://tracker.debian.org/pkg/opm-common
[1] https://tracker.debian.org/pkg/opm-material
[2] https://salsa.debian.org/science-team/opm-common
[3] https://salsa.debian.org/science-team/opm-material
--

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858




--
http://fam-tille.de




--

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858

RFS: opm-common/2021.10-1 [QA] -- Tools for Eclipse reservoir simulation files

[Markus Blatt]

Hi,

Fix the issue with libfmt8 and the package builds find on salsa-ci (except for 
puiparts,
which fails) and my chroot. Furthermore I can successfully build opm-material 
with it on
salsa-ci (only piuparts fails).

piuparts fails in the calls to "apt-cache policy libopm-common-bin" at the end 
as it
picks up the old version in unstable. 
See https://salsa.debian.org/science-team/opm-common/-/jobs/2387003


Do I need to do something for opm-material or will that get resolved 
automatically?

I am looking for a sponsor for my package "opm-common":

 * Package name: opm-common
   Version : 2021.10-2
   Upstream Author : o...@opm-project.org
 * URL : http://opm-project.org
 * License : GPL-2.0+, GPL-3.0+, ODBL-1.0 and DBCL-1.0
 * Vcs : https://salsa.debian.org/science-team/opm-common
   Section : libs

It builds those binary packages:

  libopm-common - Tools for Eclipse reservoir simulation files -- library
  libopm-common-bin - Tools for Eclipse reservoir simulation files -- utility 
programs
  libopm-common-dev - Tools for Eclipse reservoir simulation files -- 
development files
  libopm-common-doc - Tools for Eclipse reservoir simulation files -- 
documentation
  python3-opm-common - Tools for Eclipse reservoir simulation files -- Python 
wrappers

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/opm-common/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opm-common/opm-common_2021.10-2.dsc

Changes since the last upload:

 opm-common (2021.10-2) unstable; urgency=medium
 .
   * d/patches: Support g++-11.2.0 and libfmt >=8.1.0
   * d/control: Move to standard version 4.6.0

Regards,

Markus

Am Fri, Jan 21, 2022 at 01:47:40PM +0100 schrieb Markus Blatt:


Turns out that I was a bit too fast with my request. Seems like there are build 
issues with libfmt now,
that I need to resolve. Will do that and test on my system and report back.

Sorry.

Markus

Am Fri, Jan 21, 2022 at 01:23:20PM +0100 schrieb Markus Blatt:

Hi,

opm-common [0] and opm-material [1] have now been accepted by ftpmaster into 
unstable. Thanks a lot for that.

The upload to ftpmaster was in 11/2021 and as a result the binary-package 
opm-common still has
a dependency on libfmt7. That library is now replaced by libfmt8. Hence the 
package has an unsatisfied
dependency on libfmt7.

Would be cool if somebody would reupload the source package opm-common [2] 
again to resolve this.

Due to opm-common not building opm-material has an unsatisfied dependency on 
libopm-common-dev. I
hope that this gets resolved automatically by just reuploading the opm-common 
source package.

If there is something that I can help with or need to do then please yell.

Thanks a lot.

Regards,

Markus

[0] https://tracker.debian.org/pkg/opm-common
[1] https://tracker.debian.org/pkg/opm-material
[2] https://salsa.debian.org/science-team/opm-common
[3] https://salsa.debian.org/science-team/opm-material
--

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858




--

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858




--

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858

Re: RFS: reupload of opm-common/2021.10-1

[Markus Blatt]

Turns out that I was a bit too fast with my request. Seems like there are build 
issues with libfmt now,
that I need to resolve. Will do that and test on my system and report back.

Sorry.

Markus

Am Fri, Jan 21, 2022 at 01:23:20PM +0100 schrieb Markus Blatt:

Hi,

opm-common [0] and opm-material [1] have now been accepted by ftpmaster into 
unstable. Thanks a lot for that.

The upload to ftpmaster was in 11/2021 and as a result the binary-package 
opm-common still has
a dependency on libfmt7. That library is now replaced by libfmt8. Hence the 
package has an unsatisfied
dependency on libfmt7.

Would be cool if somebody would reupload the source package opm-common [2] 
again to resolve this.

Due to opm-common not building opm-material has an unsatisfied dependency on 
libopm-common-dev. I
hope that this gets resolved automatically by just reuploading the opm-common 
source package.

If there is something that I can help with or need to do then please yell.

Thanks a lot.

Regards,

Markus

[0] https://tracker.debian.org/pkg/opm-common
[1] https://tracker.debian.org/pkg/opm-material
[2] https://salsa.debian.org/science-team/opm-common
[3] https://salsa.debian.org/science-team/opm-material
--

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858




--

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858

RFS: reupload of opm-common/2021.10-1

[Markus Blatt]

Hi,

opm-common [0] and opm-material [1] have now been accepted by ftpmaster into 
unstable. Thanks a lot for that.

The upload to ftpmaster was in 11/2021 and as a result the binary-package 
opm-common still has
a dependency on libfmt7. That library is now replaced by libfmt8. Hence the 
package has an unsatisfied
dependency on libfmt7.

Would be cool if somebody would reupload the source package opm-common [2] 
again to resolve this.

Due to opm-common not building opm-material has an unsatisfied dependency on 
libopm-common-dev. I
hope that this gets resolved automatically by just reuploading the opm-common 
source package.

If there is something that I can help with or need to do then please yell.

Thanks a lot.

Regards,

Markus

[0] https://tracker.debian.org/pkg/opm-common
[1] https://tracker.debian.org/pkg/opm-material
[2] https://salsa.debian.org/science-team/opm-common
[3] https://salsa.debian.org/science-team/opm-material
--

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858

Re: Continuing packaging effort (was: Bug#994272: RFS: opm-{common|material|grid|models|simulators|upscaling}/2021.04-1 [ITP] -- opm -- Open Porous Media Software Suite)

[Markus Blatt]

Hi Anton,

On Tue, Nov 16, 2021 at 11:53:21PM +0100, Anton Gladky wrote:

I have not uploaded simulators yet. So I reverted to the -1 version.



Cool, I will adjust the tags accordingly if you don't mind.

All package are now in NEW of ftpmaster. Thanks Anton and Debian Science. That
was a breeze, prompt, and amazing.

I also like the packaging process. The tools are really great and they helped
discovering quite a few flaws that might not have been noticed otherwise.

Good job and thanks a lot.

Markus

Re: Continuing packaging effort (was: Bug#994272: RFS: opm-{common|material|grid|models|simulators|upscaling}/2021.04-1 [ITP] -- opm -- Open Porous Media Software Suite)

[Markus Blatt]

On Tue, Nov 16, 2021 at 11:22:02PM +0100, Markus Blatt wrote:

Turned out I introduced two typos in the manpage in opm-simulators.
Already fixed and rebuilding. Will upload 2021.10-2 in a few minutes.



Done: https://mentors.debian.net/package/opm-simulators/

Markus

Re: Continuing packaging effort (was: Bug#994272: RFS: opm-{common|material|grid|models|simulators|upscaling}/2021.04-1 [ITP] -- opm -- Open Porous Media Software Suite)

[Markus Blatt]

On Tue, Nov 16, 2021 at 09:41:49PM +0100, Markus Blatt wrote:

I have packaged the new release 2021.10.

You can find the packages on mentors.debian.org:



Turned out I introduced two typos in the manpage in opm-simulators.
Already fixed and rebuilding. Will upload 2021.10-2 in a few minutes.

Markus

Re: Continuing packaging effort (was: Bug#994272: RFS: opm-{common|material|grid|models|simulators|upscaling}/2021.04-1 [ITP] -- opm -- Open Porous Media Software Suite)

[Markus Blatt]

Dear all,

I have packaged the new release 2021.10.

You can find the packages on mentors.debian.org:

https://mentors.debian.net/package/opm-common/
https://mentors.debian.net/package/opm-material/
https://mentors.debian.net/package/opm-grid/
https://mentors.debian.net/package/opm-models/
https://mentors.debian.net/package/opm-simulators/
https://mentors.debian.net/package/opm-upscaling/

or salsa.debian.org:
https://salsa.debian.org/science-team/opm-common
https://salsa.debian.org/science-team/opm-material
https://salsa.debian.org/science-team/opm-grid
https://salsa.debian.org/science-team/opm-models
https://salsa.debian.org/science-team/opm-simulators
https://salsa.debian.org/science-team/opm-upscaling

Looking forward to the reviews and comments.

Cheers,

Markus

On Thu, Nov 04, 2021 at 05:53:45PM +0100, Markus Blatt wrote:

Here is a copy of the message sent to Debian's BTS.

We are still looking for a sponsor for the OPM packages.

[...]

What OPM is and why it should be in Debian:

The Open Porous Media (OPM) software suite provides libraries and
tools for modeling and simulation of porous media processes, especially
for simulating CO2 sequestration and improved and enhanced oil recovery.
Its main part is a blackoil reservoir simulator with file input and output
compatible with a major commercial oil reservoir simulator. On some
cases it clearly outperforms the commercial one. Being open source it lowers
the bar for starting simulations and is used by industry, research institutes
and quite a few small consultancies.

Looking foward to your reviews and sponsoring efforts.

Cheers,

Markus

[0] https://lists.debian.org/debian-mentors/2021/09/msg00055.html
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994272

Re: Continuing packaging effort (was: Bug#994272: RFS: opm-{common|material|grid|models|simulators|upscaling}/2021.04-1 [ITP] -- opm -- Open Porous Media Software Suite)

[Markus Blatt]

Hi Anton,

On Thu, Nov 04, 2021 at 09:30:17PM +0100, Anton Gladky wrote:

thanks for this effort! I am also interested in this software
and will review it within the next few days.



cool. I am looking forward to it.

Markus

Continuing packaging effort (was: Bug#994272: RFS: opm-{common|material|grid|models|simulators|upscaling}/2021.04-1 [ITP] -- opm -- Open Porous Media Software Suite)

[Markus Blatt]

Hi,

just to keep debian-science up to date (I am sorry for not CCing with the
original message to BTS and for multiple messages).

Here is a copy of the message sent to Debian's BTS.

We are still looking for a sponsor for the OPM packages.

FYI: We are about to release the next upstream version 2021.10 and intend to
update the prospective Debian packages (see [0], [1] for all details).
Any comments and recommendations about the current packages are of course
welcome and we will try to incorporate them. It might of course make sense to
wait with uploading to NEW for the new release. I will report when the packages
for the new release are available.

What OPM is and why it should be in Debian:

The Open Porous Media (OPM) software suite provides libraries and
tools for modeling and simulation of porous media processes, especially
for simulating CO2 sequestration and improved and enhanced oil recovery.
Its main part is a blackoil reservoir simulator with file input and output
compatible with a major commercial oil reservoir simulator. On some
cases it clearly outperforms the commercial one. Being open source it lowers
the bar for starting simulations and is used by industry, research institutes
and quite a few small consultancies.

Looking foward to your reviews and sponsoring efforts.

Cheers,

Markus

[0] https://lists.debian.org/debian-mentors/2021/09/msg00055.html
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994272

Re: RFS: opm-{common|material|grid|models|simulators|upscaling}/2021.04-1 [ITP] -- opm -- Open Porous Media Software Suite

[Markus Blatt]

Hi,

thanks a lot for all the help and comments I received during the last
month while working on the packages.

As Ansgar is lacking time, I did the usual drill (mentors.debian.org,
RFS bug, etc.). It would be cool if someone else from the
Debian Science team would sponsor the packages and upload them as
part of Debian Science.

I apologize for the pain of many packages, but each is maintained in its
own repository upstream.

My comments about the CI setup and answers to some of the previous
review comments can be found at 
https://lists.debian.org/debian-science/2021/07/msg0.html


Cheers,

Markus

Bug#994272: RFS: opm-{common|material|grid|models|simulators|upscaling}/2021.04-1 [ITP] -- opm -- Open Porous Media Software Suite

[Markus Blatt]

tors - Python wrappers for the Open porous media /
reservoir simulators
  libopm-simulators-doc - Open porous media / reservoir simulators --
documentation
  libopm-simulators-bin - Parallel porous media / reservoir simulators --
applications
  libopm-simulators - Open porous media / reservoir simulators -- library
  libopm-simulators-dev - Parallel porous media / reservoir simulators --
development files

To access further information about this package, please visit the following
URL:

  https://mentors.debian.net/package/opm-simulators/

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/o/opm-simulators/opm-
simulators_2021.04-1.dsc

Changes for the initial release:

 opm-simulators (2021.04-1) unstable; urgency=medium
 .
   * Initial release (Closes: #987381)

6. opm-upscaling

* Package name: opm-upscaling
   Version : 2021.04-1
   Upstream Author : o...@opm-project.org
 * URL : http://opm-project.org
 * License : GPL-3.0+
 * Vcs : https://salsa.debian.org/science-team/opm-upscaling
   Section : libs

It builds those binary packages:

  libopm-upscaling-doc - Porous media upscaling tools -- documentation
  libopm-upscaling - Porous media upscaling tools -- library
  libopm-upscaling-bin - Porous media upscaling tools -- applications
  libopm-upscaling-dev - Porous media upscaling tools -- development files

To access further information about this package, please visit the following
URL:

  https://mentors.debian.net/package/opm-upscaling/

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/o/opm-upscaling/opm-
upscaling_2021.04-1.dsc

Changes for the initial release:

 opm-upscaling (2021.04-1) unstable; urgency=medium
 .
   * Initial release (Closes: #987381)

Thanks a lot for your help

Regards,
--
  Markus Blatt



-- System Information:
Debian Release: 10.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500,
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-17-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Re: Help needed to sign and upload dune packages (part of debian-science) to experimental

[Markus Blatt]

Hi Patrick,

On Mon, Sep 13, 2021 at 11:29:27AM +0200, Patrick Jaap wrote:
I think I forgot to add the dependency "libdune-grid-doc" in the 
2.8.0~rc1 package which contains the missing msh file. 


I am certainly lacking a lot of experience with packaging, but adding a
dependency on a doc package to *-dev package seems strange as documentation
should be optional.

I would propose to fix this in  another way:
1. Patch upstream dune-grid to install files needed by tests below 
/usr/share/dune-grid.
 Actually on Debian jessie the file was at this location:

 mblatt@smaug:~$ apt-cache policy libdune-grid-dev
libdune-grid-dev:
 Installiert:   2.6.0-3
 Installationskandidat: 2.6.0-3
 Versionstabelle:
*** 2.6.0-3 500
   500 http://deb.debian.org/debian buster/main amd64 Packages
   100 /var/lib/dpkg/status


Not sure when this vanished. Smells like a bug in the upstream release to me.

2. Patch the failing modules to use that location.


Am 07.09.21 um 13:34 schrieb Adam Borowski:

On Tue, Sep 07, 2021 at 10:43:45AM +0200, Lisa Julia Nebel wrote:

Hello debian science team and debian mentors,

thanks for all the help so far with uploading the dune-packages to the
debian archive!!!

We are currently looking into the problems regarding alberta, and apart from
that, then there are only two unreviewed packages left:

 * https://mentors.debian.net/package/dune-functions/
 * https://mentors.debian.net/package/dune-pdelab/

They still fail for me:
 7/23 Test  #7: globalvaluedlfetest ...***Failed0.40 sec
Reading 2d Gmsh grid...
Dune reported error: Dune::IOError 
[read:/usr/include/dune/grid/io/file/gmshreader.hh:372]: Could not open 
/usr/share/doc/dune-grid/grids/gmsh/curved2d.msh




Cheers,

Markus
--

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858

Re: Packaging Open Porous Media (OPM) software suite

[Markus Blatt]

Hi,

I have worked on the packages quite a bit. They are now all added
to the CI on salsa and are green. See the list
https://salsa.debian.org/search?utf8=%E2%9C%93=opm-_id=_id==false_ref=_source=navbar

There have some struggles and I had to work a bit to get it work or deactivate 
some stuff

On Wed, May 26, 2021 at 03:32:54PM +0200, Markus Blatt wrote:

- "build i386" as the upstream tests fail on this platform.
One of the reasons is probably the Y2k38 problem on this 
architecture.

Can I restrict Architecture in debian/control to 64bit only?


It turned out that even with fixes for i386 the packages would be rather
useless. Hence the work was stopped. Instead we now only lit 64bit architectures
in debian/control and intsruct salsa-ci to skip i386 builds via 
variables:

 SALSA_CI_DISABLE_BUILD_PACKAGE_I386: 1

in debian/salsa-ci.yml

-reprotest times out. 


I increased the timeout of the CI to 2 hours. At least for opm-common
some of the reprocibility bugs have been fixed. Unfortunately for the
other modules reprotest had to be deactivated (SALSA_CI_DISABLE_REPROTEST: 1)
as the test runs as root and some of our tests are run using MPI (which refuses
to run as root). See 
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/160

autopkgtests:

I have added autopkgtests to all modules. Unfortunately, I had to deactivate 
running them on all modules
but opm-common. The problem is that they need the packages from other OPM 
modules. That works for the build
(see below) but autopkgtest has a problem with ca-certificates when using external repositories, see 
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/201#note_244674


For opm-simulators the shared CI on gitlab.com ran out of RAM and I had to 
deactivate parallel builds
in the CI (SALSA_CI_DPKG_BUILDPACKAGE_ARGS: --jobs=1)

- Please consider reducing the number of source packages.
Uploading/sponsoring
7 source packages, especially if some of them should go through NEW
queue. It is
pain.



Each of the source packages has its own repository upstream. [...]
I always assumed that Debian source package correspond to official 
upstream tarballs/repositories. 


Indeed and I feel with you. When I added the CI to all packages I already
had to deal with that. As we need the OPM packages we depend on, I used the
following approach

- Activated aptly for salsa-ci:   (SALSA_CI_DISABLE_APTLY: 0)
- Created a gpg keypair for the aptly repostories
- In the Setting->CI/CD->Variables
 - Set variable (type variable) SALSA_CI_APTLY_GPG_KEY to the private key (same 
key for all repos)
 - Set variable (type variable) SALSA_CI_APTLY_GPG_PASSPHRASE to the passphrase 
for the key
 - Set variable (type File) SALSA_CI_EXTRA_REPOSITORY to a recent one of aptly, 
e.g.
   deb 
https://salsa.debian.org/science-team/opm-common/-/jobs/1734127/artifacts/raw/aptly
 unstable main
 - Set variable (type File) SALSA_CI_EXTRA_REPOSITORY_KEY to the public (same 
key for all repos)

I wonder how other multi-repository projects deal with these build 
dependencies. Any hint/insight would
be highly appreciated

Would be cool if somebody would take another look?

Is there anything I need to do because of the freeze? CI is using unstable.

Cheers,

Markus

Re: Packaging Open Porous Media (OPM) software suite

[Markus Blatt]

Hi Andrius,


Thanks  alot for your kind help. Sorry, about late reply but I wanted to 
address the comments of Anton in the opm-common package first. That 
turned out to be quite some work.


On Thu, Apr 29, 2021 at 12:39:31PM +0300, Andrius Merkys wrote:

On 2021-04-28 16:17, Markus Blatt wrote:
- For the library packages the SONAME will change with each release, 
as

 the ABI is quite unstable. The version is not part of the library
 package name, which lintian would warn about. But we are overwriting
 the warning currently.


This lintian warning is quite important. If the ABI is unstable, I would
suggest making these libraries private by putting them under
/usr/lib//opm (for example) and shipping them in the same
binary package as the main executable(s).



Not sure what you mean by private. The libraries are/will/can/be used by 
other packages, e.g.  the binaries in lib-opm-simulators-bin need the 
libraries from all the lib-opm-* packages. Also opm-grid is a DUNE 
modules and a grid along the DUNE interface. Hence the library from 
lib-opm-grid could be used in user code and future Debian packages.


Should I still put them beneath /usr/lib//opm? It seems a bit 
uncommon but I might be missing something.


Thanks and Cheers,

Markus

Packaging Open Porous Media (OPM) software suite

[Markus Blatt]

Hi,

I have recently posted an ITP (bug )for this software
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987381



* Package name: opm-common, opm-material, opm-grid, opm-models, opm-
simulators, opm-upscaling
 Version : 2021.04
 Upstream Author : OPM 
* URL : https://www.opm-project.org/
* License : GPL2+/GPL3+
 Programming Lang: C++, Python
 Description : Open Porous Media (OPM) software suite
.
The Open Porous Media (OPM) software suite provides libraries and  
tools for modeling and simulation of porous media processes, especially 
for simulating CO2 sequestration and improved and enhanced oil 
recovery.




I am part of the OPM development team. We are prepared to maintain the 
packages, but as nobody of us is a Debian developer, we would of course 
need help for uploading. We have not done so, but intend to ask Ansgar 
Burchardt whether he has time for this.


I have an account on salsa and the current version of the packaging 
effort can be found there.  https://salsa.debian.org/blattms/opm-common 
https://salsa.debian.org/blattms/opm-material 
https://salsa.debian.org/blattms/opm-models 
https://salsa.debian.org/blattms/opm-grid 
https://salsa.debian.org/blattms/opm-simulators 
https://salsa.debian.org/blattms/opm-upscaling To us as recreational 
packagers this looks good now, but chances are that we have missed 
stuff.


I also requested being added to the Debian Science team on Salsa, but 
that does not seem to have happened yet (or I missed it). Once that 
happens I will gladly push to https://salsa.debian.org/science-team.


Some notes on the packaging:

- Packaging is based on the branch point (git commit) for the upcoming 
 2021.04 release. Once that is released we will add the new version.
- We use git-buildpackage with the default layout and pristine-tar 
 (there is a debian/dbp.conf file that activate pristine-tar, and tells

 it which files to strip from upstream)
- We have stripped some sources for the Debian packaging (jenkins, 
 travis, embedded source code, upstream packaging for Redhat, Debian, 
 OpenSuse) to satisfy the Debian Policy and prevent unnecessary changes 
 from appearing in the Repositories of the Debian packaging. Note that 
 these are also stripped from the tarballs and listed in 
 debian/copyright (Excluded-Files) and debian/gbp.conf for ease of 
 maintenance.
- Apart from opm-material and opm-models, which are header-only 
 libraries and missing lib.deb because of this, most 
 repositories create Packages lib-dev.deb, lib.deb,
 lib-doc.deb and (for opm-common, opm-grid, opm-simulators) 
 lib-bin.deb. There are also packages with python bindings: 
 python3-opm-common.deb, python3-opm-simulators.deb
- For the library packages the SONAME will change with each release, as 
 the ABI is quite unstable. The version is not part of the library 
 package name, which lintian would warn about. But we are overwriting 
 the warning currently.
- opm-upscaling is missing manpages for the binaries. This will be fixed 
 upstream and backported soon.


Some questions:

- In the future we imight want to  be able to install several versions 
 of libopm-simulators-bin.deb concurrently (which would need to depend 
 on different versions of the library packages lib.deb, and 
 probably install binaries into different versioned directories and use 
 update-alternatives. Is there a proposed policy/approach to do this? I 
 would assume that this needs to be prepared now by putting some kind 
 of versioning into the Debian packages for the libraries (e.g. like 
 Petsc).
- Does the top-level directory in the tarballs need to have a special 
 name (like opm-common-2021.04 for version 2021.04 of opm-common)?
 The reason for asking is that upstream tags final versions as 
 release//final, which will make uuscan us funny looking
 opm-common-release-2021.04-final. If it does upstream needs to use the 
 more common tagging scheme v, or we need to create the 
 tarballs ourselves and use gbp import-orig .


Thanks a lot for your kind help.

Cheers,

Markus


--

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858