Re: Maintenance of OSPRay and its dependency
Hi Frederic-Emmanuel, > Now you are Maintainer in the science teams. > Perfect, thanks! Best, François signature.asc Description: This is a digitally signed message part
Re: Maintenance of OSPRay and its dependency
Hi Team, I've managed to create the first repositories to introduce OSPRay to the Debian archive, under the salsa/science-team group for ispc [1], rkcommon [2] and ospray [3]. Unfortunately, I don't have access to the repositories settings, especially to setup the CI pipeline. Could someone grant me Maintainer right on those repositories? Thanks, François [1] https://salsa.debian.org/science-team/ispc [2] https://salsa.debian.org/science-team/rkcommon [3] https://salsa.debian.org/science-team/ospray signature.asc Description: This is a digitally signed message part
Re: Maintenance of OSPRay and its dependency
Hi Andreas, > It used to be good practice to maintain preconditions also inside the > team even if not directly science related. Makes sense, so I'll create the corresponding repos under the Debian- Science umbrella. > If you ask me please go forward. Thanks! Best Regards, François signature.asc Description: This is a digitally signed message part
Maintenance of OSPRay and its dependency
Dear Debian Science Team, I'm working on packaging OSPRay [1], and Steve advised to make it team maintained by the Debian Science Team. I definitely agree because OSPRay mainly targets scientific applications like VTK or ParaView. I'm wondering if the build dependencies should also be maintained by the team: - rkcommon [2] - ispc [3][4] - Open Image Denoise (not mandatory, for later package version) [5] - Open VKL (not mandatory, for later package version) [6] ISPC is for general purpose, so it would maybe make less sense to be maintained by the team. It seems that I can create the projects on salsa/debian-science group, but I would prefer an approval before going forward. Best Regards, François [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039111 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039110 [3] https://salsa.debian.org/mzf/ispc [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956816 [5] https://www.openimagedenoise.org/ [6] https://www.openvkl.org/ signature.asc Description: This is a digitally signed message part
itksnap Java build issue
Hi neuro and science team, while fixing the build of itksnap with VTK 9.1 [1], it seems that the package fails due to java libraries not found at runtime, beside it build-depends on "default-jre" package. The salsa CI fails [2] with: "warning: cannot resolve item 'libjawt.so'" and "warning: cannot resolve item 'libjvm.so'" I'm not familiar with Java development. Could you please advise to fix this build failure? Best Regards, François [1] https://salsa.debian.org/med-team/itksnap/-/merge_requests/2 [2] https://salsa.debian.org/mzf/itksnap/-/jobs/3943621 signature.asc Description: This is a digitally signed message part
Re: Migration from vtk7 to vtk9
Hi Anton, > Progress on fixing those bugs can be monitored here [1]/ > > [1] > https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=gladk%40debian.org=vtk6_vtk7_removal Looks perfect! I'll use it to coordinate our effort. Thanks, François signature.asc Description: This is a digitally signed message part
Migration from vtk7 to vtk9
Hello science team! After discussion with Jochen and Andreas, I'm working on removing the old vtk7 package from the archive, or at least do not build-depends on it. The rationale is that vtk7 is old and not maintained upstream anymore. The current version is vtk9. Unfortunately, many packages are not ready for the migration because the way VTK works changed between version 8 and 9, especially on the CMake side. So I've started to update reverse build-depends of libvtk7-dev: cgal- demo [1], mia [2], nifti2dicom [3], openems [4]... I've discovered that similar initiatives are ongoing [5]. I think that synchronization is needed to avoid duplicate work. There is still a lot to do, like camitk, gdcm, vtk-dicom, facet- analyser, so any contribution is welcome! Best Regards, François [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012280 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012689 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012691 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013190 [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013158 signature.asc Description: This is a digitally signed message part
Re: Ceres solver version 2.1.0
Hello Pierre, > While you are at it, you could upgrade the Standards version and > apply > the multiarch hints. Also I feel debian/copyright could be refreshed. Sure, I'll do it. Best, François signature.asc Description: This is a digitally signed message part
Ceres solver version 2.1.0
Dear Science Team, I've updated the Ceres Solver package to version 2.1.0, but I can't upload the package. Could someone grant me right to upload (I'm DM), otherwise review and sponsor the upload? Best, François signature.asc Description: This is a digitally signed message part
Update Ceres Solver to 2.0.0
Hello science team, I've just packaged the last version of ceres package and I've pushed it to the salsa repo [1], and to mentors [2]. Could someone review the package? The tricky part may be the transition of the lib package from libceres1 to libceres2. For now, I've just renamed the binary package but maybe some additional actions are required? In addition, could you please grant me right to upload the package as I'm DM? Thanks, François [1] https://salsa.debian.org/science-team/ceres-solver [2] https://mentors.debian.net/package/ceres-solver/ signature.asc Description: This is a digitally signed message part
Fwd: Bug#986108: RFS: f3d/1.1.0-1 [ITP] -- fast and minimalist 3D viewer
Dear Debian Science Team, I'm looking for a sponsor for my package "f3d". This is a 3D model viewer based on VTK following the KISS principle. VTK library is maintained by your team, so someone may be interested in reviewing and sponsoring the package. When accepted, I volunteer to maintain the package or make it team- maintained with upload right. Below the initial RFS message with all package data. Do not hesitate to ask more information. Thanks! François Message transféré ---- De: François Mazen Répondre à: François Mazen , 986...@bugs.debian.org À: sub...@bugs.debian.org Objet: Bug#986108: RFS: f3d/1.1.0-1 [ITP] -- fast and minimalist 3D viewer Date: Mon, 29 Mar 2021 18:53:15 +0200 Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "f3d": * Package name : f3d Version : 1.1.0-1 Upstream Author : Kitware SAS * URL : https://kitware.github.io/F3D/ * License : BSD-3-clause * Vcs : https://salsa.debian.org/mzf/f3d Section : graphics It builds those binary packages: f3d - fast and minimalist 3D viewer To access further information about this package, please visit the following URL: https://mentors.debian.net/package/f3d/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/f3d/f3d_1.1.0-1.dsc Changes for the initial release: f3d (1.1.0-1) unstable; urgency=medium . * Initial release (Closes: #985993) Regards,
Re: FreeFEM++ version 4.9 ready for review and upload
Hello Nilesh, thanks for the upload right! > Had a quick look, it looks nice. However would you consider fixing > blhc which seems to fail salsa CI? > IMO it'd be straightforward to do a patch here > > https://salsa.debian.org/science-team/freefempp/-/jobs/1809852 I think CI blhc detection is wrong because freefem++ use a script called "ff-c++" to build the source instead of calling directly g++, which triggers false positive. The ff-c++ script actually calls g++ with the correct flags. For example, blhc detects this line as wrong: eval ./ff-c++ NewSolver.cpp -lumfpack -lamd -lcholmod -lklu - I/usr/include/suitesparse -lumfpack -lamd -lcholmod -lklu - I/usr/include/suitesparse -llapack -lblas but in the build-log we can check that ff-c++ calls g++ with these options, which are fine: g++ -c -fPIC -g -ffile-prefix- map=/home/francois/dev/freefem++/freefempp=. -fstack-protector-strong - Wformat -Werror=format-security -DNDEBUG -O3 -mmmx -mavx -std=c++14 - DBAMG_LONG_LONG -DNCHECKPTR -fPIC '-I./include' '- I/usr/include/suitesparse' '-I/usr/include/suitesparse' -g -ffile- prefix-map=/home/francois/dev/freefem++/freefempp=. -fstack-protector- strong -Wformat -Werror=format-security -DNDEBUG -O3 -mmmx -mavx - std=c++14 -DBAMG_LONG_LONG -DNCHECKPTR -fPIC -Wdate-time - D_FORTIFY_SOURCE=2 -I/usr/include/suitesparse - I/usr/include/hdf5/serial -I/usr/include 'NewSolver.cpp' -Wl,-z,relro - Wl,-z,now -rdynamic Do you have a patch in mind to discard these false positive cases? Thanks, François signature.asc Description: This is a digitally signed message part
FreeFEM++ version 4.9 ready for review and upload
Hello, I've just finished to package the new version 4.9 of FreeFEM++. You may read the changelog to get all the modifications: https://salsa.debian.org/science-team/freefempp/-/blob/master/debian/changelog Could you please review the package and eventually upload it as Team Upload? (or grant me right to upload it as I'm DM) I've also uploaded the package to mentor, in case of you want a quick status of the package: https://mentors.debian.net/package/freefem++/ Thanks! François
Re: Quick Poll: Debian to better support hardware acceleration?
Hello, I'm not confortable in fostering proprietary solution like CUDA against libre alternative in Debian project. CUDA libraries are de-facto outdated when new Debian release comes out due to new hardware release and vendor lock-in business model. As a consequence, the user will always download the last libraries version from the vendor web-site. So, spending time pushing these libraries in the archive is pointless in my opinion. I would better spend time promoting free alternative or high level abstractions like OpenCL or SYSCL even if they are less performant. One day they will be better and Debian would be part of the success. Reminds me some Direct3D/OpenGL war some times ago. With this in mind, I also think that Debian should not prevent CUDA integration in scientific softwares, maybe by providing a simple way to rebuild or configure software to use CUDA libraries from the nVidia website. Sorry for being more purist than pragmatic when dealing with Debian. As a reminder: https://www.debian.org/intro/why_debian.en.html Best, François Le vendredi 21 mai 2021 à 04:40 +, M. Zhou a écrit : > Hi folks, > > --- > > Q: How far should Debian go along the way for supporting hardware > acceleration solutions like CUDA? > > Choice 1: this game belongs to the big companies. we should offload > such burden to third-party providers such as Anaconda. > Choice 2: we may try to provide what the users need. > Choice 3: > > --- > > As we know, hardware acceleration means a lot to scientific > computing, > and I believe a number of debian users use solutions like CUDA, ROCm, > or even SYCL. And the most prevalent solution seems to be CUDA. > Recall that anaconda might be one of the simplest ways to get the > cuda > version of tensorflow and pytorch, etc. So I just want to hear your > opinions on how far we should go along this direction. > > If we really want to go further, then a GPU server should be > available > in our infrastructure to facilitate development. Although license is > another considerable blocker, this can be discussed later. > > Thanks! > signature.asc Description: This is a digitally signed message part
Re: [Fwd: Bug#988474: RFS: freefem++/3.61.1+dfsg1-5.2 [NMU] [RC] -- Provides the binaries of the FreeFem++ FE suite]
Hi Nilesh, thanks for the pointer to the freeze policy. I understand that it's too late and I'm closing the unblock request. Best Regards, François Le lundi 17 mai 2021 à 00:30 +0530, Nilesh Patra a écrit : > Hi, > > On Mon, 17 May 2021 at 00:10, François Mazen wrote: > > Hello Anton, > > > > > When the package is successfully built on all relevant platforms, > > > you can ask the release team to unblock it. But it will unlikely > > > happen > > > due to release policy. > > > > I've requested the unblock, see [1]. Let me know if I've missed > > something. > > As you might see freefem++ is not in testing, and as per the release > policy[1] the packages not in testing cannot re-enter testing at this > stage. > The deadline for such packages to enter testing was Feb 12 and we are > months away from that date. > > Nevertheless, it can definitely be a part of bookworm and bullseye- > backports. Thanks a lot for your work on > freefem++ :-) > > [1]: https://release.debian.org/bullseye/freeze_policy.html#soft > > Nilesh
Re: [Fwd: Bug#988474: RFS: freefem++/3.61.1+dfsg1-5.2 [NMU] [RC] -- Provides the binaries of the FreeFem++ FE suite]
Hello Anton, > When the package is successfully built on all relevant platforms, > you can ask the release team to unblock it. But it will unlikely > happen > due to release policy. I've requested the unblock, see [1]. Let me know if I've missed something. Thanks again for the sponsoring! Have a nice day, François [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988552 signature.asc Description: This is a digitally signed message part
Re: [Fwd: Bug#988474: RFS: freefem++/3.61.1+dfsg1-5.2 [NMU] [RC] -- Provides the binaries of the FreeFem++ FE suite]
Hello Anton, thanks for your time testing my upload! Apparently, piuparts tries to install the package 3.61.1+dfsg1-5.1 instead of 3.61.1+dfsg1-5.2, why? In the old package 3.61.1+dfsg1-5.1, the control file contains libmumps-seq-5.3.1 as libfreefem++ dependency which does not exist anymore in sid. The control file of the build package (3.61.1+dfsg1- 5.2) indicates libmumps-seq-5.3, which exists in sid. The problem is not new [1] and it appears since the version 5.3.4 of mumps. In the mumps changelog [2], we can read: > MUMPS is now ABI-compatible in the minor version. > Provide new packages as libmumps-5.3, etc instead of libmumps-5.3.4 I think that rebuilding the package and using puipart with the 3.61.1+dfsg1-5.2 should be fine. Let me know if I'm missing something. Best, François [1] https://piuparts.debian.org/sid/source/f/freefem++.html [2] https://tracker.debian.org/media/packages/m/mumps/changelog-5.3.5-2 Le jeudi 13 mai 2021 à 22:31 +0200, Anton Gladky a écrit : > Your upload is fine. It fixes the FTBFS. But piuparts > identified some problems with the installation of libfreefem++-dev > [1]. > > Could you please verify whether the problem really exists or not? > > [1] https://salsa.debian.org/science-team/freefempp/-/jobs/1640984 > > Thanks > > Anton > > > Am Do., 13. Mai 2021 um 19:27 Uhr schrieb François Mazen < > franc...@mzf.fr>: > > Dear Science Team, > > > > In case of a DD in this list is interested: I'm forwarding my > > Request > > For Sponsor about RC bug that I've just fixed in the freefem++ > > package. > > It should prevent the removal of the package in the next release. > > > > Then, I volunteer to maintain this package as it need to be updated > > with the new upstream version. > > > > Best Regards, > > François > >
Re: VTK and ParaView parallelization
Anton, thanks for your trust! I've created a merge request for VTK in order to use TBB instead of sequential behavior when dealing with parallel code: https://salsa.debian.org/science-team/vtk9/-/merge_requests/4 I would like to do the same for ParaView but the salsa repo is not sync with the current package in unstable. Version 5.9.0-1 and 5.9.0-2 are missing. Should I push them myself to the salsa repo? Thanks, François Le jeudi 22 avril 2021 à 21:59 +0200, Anton Gladky a écrit : > Hi François, > > thanks for a suggestion! I have added you to Debian Science Team on > salsa. > Feel free to contribute! > > Best regards > > > Anton > > > Am Do., 22. Apr. 2021 um 21:46 Uhr schrieb François Mazen < > franc...@mzf.fr>: > > Hello, > > > > I'm wondering why VTK and ParaView are build with the "Sequential" > > default backend for parallelization (vtkSMPTools backend)? > > This makes ParaView run slower compared to official binary releases > > from Kitware, which are built with Threaded Building Blocks (TBB). > > > > Hence, any serious user of ParaView and VTK will have to use a > > custom > > build, losing all the advantages of Debian packaging. > > > > It seems that TBB is available as Debian packages. Do you think > > that > > the Debian package may be built with TBB? > > The modification is simple: add -DVTK_SMP_IMPLEMENTATION_TYPE="TBB" > > to > > the debian/rules file, and add tbb as dependency in debian/control > > file. > > > > (By the way, I'm DM and I'll be happy to be part of the Debian > > Science > > Team to contribute to the tools that I use everyday, mostly linked > > to > > scientific computation. My salsa login is mzf.) > > > > Best Regards, > > François > > > > signature.asc Description: This is a digitally signed message part
VTK and ParaView parallelization
Hello, I'm wondering why VTK and ParaView are build with the "Sequential" default backend for parallelization (vtkSMPTools backend)? This makes ParaView run slower compared to official binary releases from Kitware, which are built with Threaded Building Blocks (TBB). Hence, any serious user of ParaView and VTK will have to use a custom build, losing all the advantages of Debian packaging. It seems that TBB is available as Debian packages. Do you think that the Debian package may be built with TBB? The modification is simple: add -DVTK_SMP_IMPLEMENTATION_TYPE="TBB" to the debian/rules file, and add tbb as dependency in debian/control file. (By the way, I'm DM and I'll be happy to be part of the Debian Science Team to contribute to the tools that I use everyday, mostly linked to scientific computation. My salsa login is mzf.) Best Regards, François signature.asc Description: This is a digitally signed message part
