Re: RFS: phcpack 2.4.84 (NEW)
Hi Doug, On Wed, 7 Jul 2021 at 03:42, Torrance, Douglas wrote: > > On Wed 19 May 2021 12:37:22 PM EDT, Doug Torrance > wrote: > > I've finished packaging PHCpack, which is written in Ada and solves > polynomial systems using homotopy continuation, for Debian. It also > includes Python and Octave interfaces. > > > > Would anyone be willing to review/sponsor? Note that I currently have > it set for upload to unstable since it's destined for the NEW queue and I > don't think that would interfere with the freeze, but perhaps it would make > sense to upload to experimental instead? > > > > https://salsa.debian.org/science-team/phcpack > > FYI, I'm still looking for a sponsor for PHCpack. Upstream recently > released a new version (2.4.85), and I've updated the packaging in Salsa > accordingly. > ./src/Ada/Math_Lib/QD/READ_ME states this: The main reference for the QD-2.3.9 library is Y. Hida, X.S. Li, and D.H. Bailey: "Algorithms for quad-double precision floating point arithmetic." In 15th IEEE Symposium on Computer Arithmetic (Arith-15 2001), 11-17 June 2001, Vail, CO, USA, pages 155-162. IEEE Computer Society, 2001. Shortened version of Technical Report LBNL-46996, software at http://crd.lbl.gov/~dhbailey/mpdist/qd-2.3.9.tar.gz. Note that the "BSD-LBNL-License" is GPL compatible, although "If you wish to use the software for commercial purposes please contact the Technology Transfer Department at t...@lbl.gov or call 510-286-6457." I admit, I'm not very sure if I understand the terms there correctly, but should it be mentioned in d/copyright? I also see similar stuff in a lot of READ_ME files, ./src/Ada/Root_Counts/MixedVol/READ_ME for instance. Do they need to be mentioned in d/copyright? If not, IMO adding a "Comment:" and the reasoning for not adding these in copyright would be good. > > I've also opened a merge request in the Debian Science Blend repo to add > it to the mathematics task: > https://salsa.debian.org/blends-team/science/-/merge_requests/7 > > I'm also still looking for sponsors for a few other packages: > > * macaulay2 (new upstream version 1.18, for experimental) > https://salsa.debian.org/science-team/macaulay2 Unfortunately, I've got no resources to build it :-( I hope someone else uploads this. If not, just ping me after your keys are added to the DM keyring, and I'll grant you DM access for this > * macaulay2-jupyter-kernel (NEW) > https://salsa.debian.org/science-team/macaulay2-jupyter-kernel Uploaded! > * qepcad (NEW) > https://salsa.debian.org/science-team/qepcad ./plot2d/ADJ2D_plot is a binary file, and I'm sure FTP masters will not like it. Please repack this and compile the same during the build. > Good news: my DM application was recently approved, so once the keyring is > updated, I won't need to ask for sponsorship for non-NEW packages. :) > I'm very happy about this. Whilst I could not advocate you due to us working on not many packages together, I was definitely cheering on the sidelines all this while. I hope you apply for being a DD someday, and by that time I've sponsored enough packages for you. Cheers, Nilesh
Re: RFS: phcpack 2.4.84 (NEW)
On Wed 19 May 2021 12:37:22 PM EDT, Doug Torrance wrote: I've finished packaging PHCpack, which is written in Ada and solves polynomial systems using homotopy continuation, for Debian. It also includes Python and Octave interfaces. Would anyone be willing to review/sponsor? Note that I currently have it set for upload to unstable since it's destined for the NEW queue and I don't think that would interfere with the freeze, but perhaps it would make sense to upload to experimental instead? https://salsa.debian.org/science-team/phcpack FYI, I'm still looking for a sponsor for PHCpack. Upstream recently released a new version (2.4.85), and I've updated the packaging in Salsa accordingly. I've also opened a merge request in the Debian Science Blend repo to add it to the mathematics task: https://salsa.debian.org/blends-team/science/-/merge_requests/7 I'm also still looking for sponsors for a few other packages: * macaulay2 (new upstream version 1.18, for experimental) https://salsa.debian.org/science-team/macaulay2 * macaulay2-jupyter-kernel (NEW) https://salsa.debian.org/science-team/macaulay2-jupyter-kernel * qepcad (NEW) https://salsa.debian.org/science-team/qepcad Good news: my DM application was recently approved, so once the keyring is updated, I won't need to ask for sponsorship for non-NEW packages. :) Thanks! Doug signature.asc Description: PGP signature
Self-introduction and questions
Dear list, my name is Chiara Marmo. I have previously contributed to debian as packager of the aravis library [1]. Recently I have worked for the scikit-learn Consortium at Inria [2]. I am interested in improving my contributions to debian and I was wondering if I can made myself useful for the team packaging scikit-learn. To put myself at work I have tried to package locally the library using the current content of the repo on salsa [3]: it seems to me that the current master on salsa contains files that are not present in upstream. Is that expected? Do you mind if I synchronize the contents of the two repos and propose a merge request on salsa? Thanks for listening. Best, Chiara [1] https://salsa.debian.org/debian-astro-team/aravis [2] https://scikit-learn.fondation-inria.fr/home/ [3] https://salsa.debian.org/cmarmo-guest/scikit-learn
Re: Packaging Open Porous Media (OPM) software suite
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
