Re: PyTables no longer buildable on s390x

[Anton Gladky]

Hi Antonio,

sure, please go ahead!

Best regards

Anton


Am Mo., 12. Feb. 2024 um 20:12 Uhr schrieb Antonio Valentino <
antonio.valent...@tiscali.it>:

> Dear Anton,
> PyTables > 3.9 depends on c-blosc2 that in not available on s390x.
> As a consequence PyTables itself is no longer buildable on that platform.
>
> Please note that this will have a consequence on the sfepy package,
> maintained by you, that currently depends on pytables.
>
> In #1061661 I have already requested the removal of python3-tables-lib
> from unstable [s390x].
> Are you fine with removing sfepy form unstable [s390x] as well?
>
>
> [#1061661] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061661
>
> kind regards
> --
> Antonio Valentino
>
>

Re: Updating ortools

[Anton Gladky]

Hi,

sure, welcome to team! it would be also good to fix RC bugs also there. Thanks!

Regards,

Anton

Am Di., 2. Jan. 2024 um 20:15 Uhr schrieb Kari Pahula :
>
> Hi.
>
> As the maintainer of minizinc, I have an interest in ortools.  I added
> ortools-flatzinc as rdep for it with a recent update but noticed that
> it's kind of unmaintained at the moment.
>
> I can prepare an update with the newest upstream version and add
> myself as an uploader.
>

Re: How to build compatible packages that use Eigen?

[Anton Gladky]

Hi Dima,

I have been maintaining the Eigen library in Debian for over 12 years,
and I cannot recall the specific bug ticket related to this topic. However,
it seems that the question you have raised is indeed valid. If patching
Eigen in those two places would help resolve the issue, please prepare
a patch, and I believe we can proceed with pushing it.

Does it make sense to discuss this with the Eigen developers? Or is the
question very specific to Debian (or packaging) and might not be of interest
to them?

Best regards,


Anton


Am Mi., 12. Juli 2023 um 01:24 Uhr schrieb Dima Kogan :

> Hi.
>
> Apologies for taking so long to look at this again; I've been busy.
>
> I just looked into it, and my conclusion is that there's no way to
> ensure that Eigen won't crash without us patching our package. So we
> should patch our package.
>
> I'm attaching a tiny demo program. Extract it and
>
>   make && ./main
>
> You'll see that it crashes. We have lib.cc:
>
>   #include 
>
>   __attribute__((visibility("default")))
>   Eigen::MatrixXd* make_array()
>   {
>   return new Eigen::MatrixXd(10,20);
>   }
>
> This is an analogue of some library we would be packaging for Debian.
> This would be built with no cpu-specific options, which is what the
> Makefile in this demo does.
>
> We also have a main.cc:
>
>   #include 
>
>   Eigen::MatrixXd* make_array();
>   int main(void)
>   {
>   Eigen::MatrixXd* matrix = make_array();
>   delete matrix;
>   return 0;
>   }
>
> This is an analogue of some user program that uses this library. This
> isn't going into Debian, and the user wants to use their CPU fully, so
> they build with -mavx. This causes Eigen to crash. Because the
> allocation and deallocation paths don't work the same.
>
> In this demo no Eigen symbols are exported from lib.so, so it's not a
> case of the linker picking the wrong weak symbol, and this cannot be
> fixed by symbol versioning or visibility settings or anything.
>
> This isn't a contrived example. I hit this in the real-world with a
> package I'm going to upload soon (g2o).
>
> Can anybody see ways to make Eigen work reliably here without patching
> away the different paths in aligned_malloc() and aligned_free() ?
>
>
> https://sources.debian.org/src/eigen3/3.4.0-4/Eigen/src/Core/util/Memory.h/#L179
>
> https://sources.debian.org/src/eigen3/3.4.0-4/Eigen/src/Core/util/Memory.h/#L200
>
> I don't see any way to do it currently, and probably we should patch
> these out.
>
> There was also a second similar problem I saw earlier, that resulted in
> crashes due to inconsistent alignment. I'm going to revisit that
> shortly.
>
> Thanks.
>
>

Re: Packaging liblsl

[Anton Gladky]

Hi Enrico,

from my point of view it is totally fine to upload the
package under the Debian Science
umbrella.

Regards


Anton


Am Di., 14. März 2023 um 10:56 Uhr schrieb Enrico Zini <
enr...@enricozini.org>:

> Hello,
>
> I've been needing to use liblsl[1] for a personal project, I noticed
> that it's easily packaged, and it would be straightforward to upload it
> to Debian.
>
> However, the package seems to have a much vaster reach and field of
> application than a hobby project, and I fear I can't take responsibility
> for supporting people on the issue tracker besides FTBFS kind of issues.
>
> With these premises, would it be ok if I uploaded it under the hat of
> the Debian Science Team and let it become a sort of shared good?
>
> [1] https://github.com/sccn/liblsl
>
>
> Enrico
>
> --
> GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <
> enr...@enricozini.org>
>
>

Re: MRs on salsa and letting janitor automate things

[Anton Gladky]

Hello Stuart,

thanks for the information! I am personally OK with the idea of committing
directly to the Science packages, not sure about the opinions of other
team members.

But if it improves the overall package quality - I am totally for this.

Otherwise, I did not find an opportunity to blacklist some packages
for the janitor, not being touched by this tool. There are some difficult
ones, so I would prefer to have this option. Do you know, whether
it is possible?

Thanks!

Anton

Am So., 27. Nov. 2022 um 06:02 Uhr schrieb Stuart Prescott :
>
> Hi folks
>
> tl;dr: there lots of untriaged MRs on salsa; let's permit Janitor to
> automatically commit its updates
>
>
> There are lots of MRs on salsa for science-team packages that are open.
> Many of these have been open for months and many have no comments,
> triage or feedback visible on salsa. Many of these have been made by
> first time contributors who, by virtue of their MRs sitting
> unacknowledged and unmerged for months, think we don't care. That's not
> our intended message!
>
> Attached are:
>
> * a list of MRs that are currently open on salsa (sorted by package)
>
> * associated dd-list of maintainers/uploaders for these packages
>
> If you don't currently get notified about MRs being opened for packages
> you are interested in, I encourage you to tweak your salsa notification
> preferences. My approach to this is to "star" packages for which I am
> maintainer, uploader, or otherwise interested enough in that I'd like to
> see notifications for MRs.
>
>
> In amongst the human-generated MRs, there was also a huge number of
> automated MRs from the Janitor bot. Over the last couple of days I've
> been through Janitor's MRs (about 200 of them). These are all really
> simple changes, each of which I checked and almost all of them I have
> merged.
>
> For those not familiar with Janitor, it looks for easy to fix issues in
> the packaging that are flagged by lintian (or other similar tools) and
> fixes them. Unlike lintian, it has internet access and knowledge of the
> Debian archive, so it can do extra things like update upstream homepages
> or remove obsolete version constraints on packages. Janitor's fixes
> range from pedantic to very useful; even the more pedantic ones steadily
> improve the signal:noise of lintian and so lintian becomes more useful
> on those packages.
>
> https://janitor.debian.net/
>
> I propose that we let Janitor make these commits directly rather than
> opening MRs; quite a few other teams in Debian have done this and it is
> working well. Janitor has proven itself to be reliable and useful. Since
> we've now been able to see that Janitor's changes are OK for a few
> years, we can safely cut out the manual work and just let the bot get on
> with its work. Comments?
>
> regards
> Stuart
>
> --
> Stuart Prescott   http://www.nanonanonano.net/   stu...@nanonanonano.net
> Debian Developer  http://www.debian.org/ stu...@debian.org
> GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Re: Veusz update to 3.5.3

[Anton Gladky]

Hi Jeremy!

Looks good. Some notes:

- overriding lintian "veusz source: source-is-missing
[Documents/manual/html/searchindex.js]"
  please drop it from the source and use dh --sphinxtools to symlink it.
- d/rules:
override_dh_auto_build: export http_proxy=127.0.0.1:9
override_dh_auto_build: export https_proxy=127.0.0.1:9
override_dh_auto_build: delete_generated
dh_auto_build...

Looks weird. Is it really necessary to override auto_build several times?

Otherwise, please read "man dh" the section about "execute_after" and
"execute_before".
It can make your d/rules shorter.

When you are ready and the package needs to be sponsored - please let us know.

Best regards

Anton

Am Sa., 5. Nov. 2022 um 13:09 Uhr schrieb Jeremy Sanders
:
>
> Dear Science Team
>
> It would be great if someone could have a look at the current version of
> the Veusz packaging (for version 3.5.3) and review if it is ready to upload:
>
> https://salsa.debian.org/science-team/veusz
>
> The existing package currently fails to build under unstable and does
> not run (see closed bug #1023185).
>
> Thanks again
>
> Jeremy
>
>
>

Re: RFS: solvespace/3.1+ds1-2 [RC] [Team] -- Parametric 2d/3d CAD

[Anton Gladky]

Ok, uploaded! Thanks!


Anton


Am Di., 20. Sept. 2022 um 18:35 Uhr schrieb Ryan Pavlik <
ryan.pav...@gmail.com>:

> Ah, thanks for the reminder. I have submitted that request.
>
> On Tue, Sep 20, 2022 at 12:11 AM Anton Gladky 
> wrote:
> >
> > Hi Ryan,
> >
> > thanks for update. I will sponsor the package.
> >
> > But please note, just dropping the arch from the list of supported
> > one is not enough to get the package into the archive.
> > You have to request the binary removal from the archive on a specific
> > arch, filling the bug against ftp.debian.org.
> >
> > Best regards
> >
> > Anton
> >
> >
> > Am Mo., 19. Sept. 2022 um 21:00 Uhr schrieb Ryan Pavlik <
> ryan.pav...@gmail.com>:
> >>
> >> Hello science packagers,
> >>
> >> I've updated the SolveSpace package to fix the RC bug - unfortunately
> >> by excluding the architecture with the problem, since I couldn't
> >> reproduce it or debug it further here. Please review and submit. The
> >> source package has been uploaded to Mentors, and the salsa repo is
> >> updated.
> >>
> >> To access further information about this package, please visit the
> >> following URL:
> >>
> >>   https://mentors.debian.net/package/solvespace/
> >>
> >> Alternatively, you can download the package with 'dget' using this
> command:
> >>
> >>   dget -x
> https://mentors.debian.net/debian/pool/main/s/solvespace/solvespace_3.1+ds1-2.dsc
> >>
> >> Changes since the last upload:
> >>
> >>  solvespace (3.1+ds1-2) unstable; urgency=medium
> >>  .
> >>* Team upload.
> >>* Drop s390x architecture due to test failures. Closes: #1013163
> >>* Bump Standards-Version to 4.6.1. No changes required.
> >>* d/copyright: Update
> >>* Update lintian overrides.
> >>
> >>
> >> Ryan Pavlik
> >>
>

Re: RFS: solvespace/3.1+ds1-2 [RC] [Team] -- Parametric 2d/3d CAD

[Anton Gladky]

Hi Ryan,

thanks for update. I will sponsor the package.

But please note, just dropping the arch from the list of supported
one is not enough to get the package into the archive.
You have to request the binary removal from the archive on a specific
arch, filling the bug against ftp.debian.org.

Best regards

Anton


Am Mo., 19. Sept. 2022 um 21:00 Uhr schrieb Ryan Pavlik <
ryan.pav...@gmail.com>:

> Hello science packagers,
>
> I've updated the SolveSpace package to fix the RC bug - unfortunately
> by excluding the architecture with the problem, since I couldn't
> reproduce it or debug it further here. Please review and submit. The
> source package has been uploaded to Mentors, and the salsa repo is
> updated.
>
> To access further information about this package, please visit the
> following URL:
>
>   https://mentors.debian.net/package/solvespace/
>
> Alternatively, you can download the package with 'dget' using this command:
>
>   dget -x
> https://mentors.debian.net/debian/pool/main/s/solvespace/solvespace_3.1+ds1-2.dsc
>
> Changes since the last upload:
>
>  solvespace (3.1+ds1-2) unstable; urgency=medium
>  .
>* Team upload.
>* Drop s390x architecture due to test failures. Closes: #1013163
>* Bump Standards-Version to 4.6.1. No changes required.
>* d/copyright: Update
>* Update lintian overrides.
>
>
> Ryan Pavlik
>
>

Re: ITA: glm -- C++ library for OpenGL GLSL type-based mathematics

[Anton Gladky]

Hi Andrea,

thanks for taking care of this package! Really appreciate it.

Please, follow an advices given by Pierre and we will upload
the package, giving you permissions to upload it in the future.

It could also be good if you add salsa-CI to be sure that the package
is building aod passing all tests. It is also an additional tests for you,

Best regards

Anton


Am Fr., 2. Sept. 2022 um 22:13 Uhr schrieb Andrea Pappacoda <
and...@pappacoda.it>:

> Hi everyone!
>
> I've been wanting to adopt the glm package, maintained by the Science
> Team, since last September.
>
> I'm a DM, so I can't directly take ownership of the package nor push to
> Salsa. Could somebody please look at my changes, give me write access
> to the repo and possibly sponsor the first upload? You can find my
> changes here:
> 
>
> I've already asked this on IRC, and joostvb, while approving my changes
> in general, said that it would've been better to ask this on the
> mailing list.
>
> Thanks in advance :)
>
> --
> OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49
>
>
>

Re: coinor packages

[Anton Gladky]

Hi Håvard,

thanks for your contribution efforts! I have just added you
into the salsa group of the debian science team. Feel free
to move your repos into it. I will review your packages ASAP.

Best regards


Anton


Am Fr., 22. Juli 2022 um 09:10 Uhr schrieb Håvard F. Aasen <
havard.f.aa...@pfft.no>:

> Hi,
>
> I was looking at coinutils [1], and noticed it was lagging a few "bug-fix"
> releases behind.
>
> Would it be ok if I reintroduced the packages coinutils and coinor-osi
> into the team, and add myself as uploader?
>
> If we are to keep the coinor packages up to date, we also need to ship a
> new
> package, I have already prepared, coinor-data-sample [2], this is test
> files
> that has been split out from the coinutils package. I was hoping to
> maintain
> this under the Science Team umbrella. There is also a second package I
> would
> like to package, coinor-data-netlib [3], these are optional test files,
> and as far as i know isn't shipped in any package in Debian. I haven't
> filed
> any ITP's yet.
>
> If we go through with this, packages that depends on files split out from
> coinutils, would need to add coinor-data-sample as a build-dependency, if
> they use the test files of course, coinor packages normally do.
>
>
> I'm not sure if I am an official team member, I know I already has
> developer
> access, if not, I would also request to join the Debian Science Team.
>
>
> Regards,
> Håvard
>
> [1] https://tracker.debian.org/pkg/coinutils
> [2] https://salsa.debian.org/haava/coinor-data-sample
> [3] https://salsa.debian.org/haava/coinor-data-netlib
>
>

Re: Request for sponsorship - SolveSpace 3.1

[Anton Gladky]

Uploaded, thanks for contributing!


Anton


Am Mo., 11. Juli 2022 um 16:08 Uhr schrieb Ryan Pavlik :

> Hello all,
>
> I've updated the team-maintained SolveSpace package following the
> recent upstream release, and have pushed it to mentors as well as
> updated on salsa.
>
> The previous RC1 upload's migration to testing is stuck behind an
> autopkgtest s390x regression I can't reproduce, and that isn't seen in
> Ubuntu either, but that debci can reliably trigger. I have not done
> anything particularly different in this package, but perhaps some
> small detail of the build will make it pass; otherwise help there
> would be appreciated as well.
>
> The RFS template follows below.
>
> I am looking for a sponsor for my package "solvespace":
>
>  * Package name: solvespace
>Version : 3.1+ds1-1
>Upstream Author : [fill in name and email of upstream]
>  * URL : https://solvespace.com
>  * License : OFL-1.1-RFN, GPL-3.0+, Expat, GPL-2.0+, other
>  * Vcs : https://salsa.debian.org/science-team/solvespace
>Section : graphics
>
> The source builds the following binary packages:
>
>   solvespace - Parametric 2d/3d CAD
>   libslvs1 - SolveSpace geometric kernel
>   libslvs1-dev - SolveSpace geometric kernel (development files)
>
> To access further information about this package, please visit the
> following URL:
>
>   https://mentors.debian.net/package/solvespace/
>
> Alternatively, you can download the package with 'dget' using this command:
>
>   dget -x
> https://mentors.debian.net/debian/pool/main/s/solvespace/solvespace_3.1+ds1-1.dsc
>
> Changes since the last upload:
>
>  solvespace (3.1+ds1-1) unstable; urgency=medium
>  .
>* Team upload.
>* New upstream version 3.1+ds1
>* Rediff patches.
>  Drop 05_eigen_dependency_fix.patch: Applied upstream.
>  Drop 06_desktop_file_exec.patch: Applied upstream.
>
> Regards,
>   Ryan A. Pavlik
>
>

DebConf22, Debian Science BoF

[Anton Gladky]

Dear all,

this year we are organizing Debian Science BoF during
Debconf22. It is scheduled [0]:

Type: BoF (45 minutes)

Room: Ereniku

Time: Jul 22 (Fri): 15:00


Please use this link to add some topics to discuss [1].
It is planned to have an informal talk about Debian Science
Team activities and plans for the future.

[0] https://debconf22.debconf.org/talks/16-debian-science-bof/
[1] https://pad.dc22.debconf.org/p/16-debian-science-bof

See you there!

Anton

Re: [RFS] resampy

[Anton Gladky]

Hi Antonio,

I do not have enough permissions to move the package away
from python team. I would just propose to let the package be
there. The only thing which should be fixed is the binaries
in the code.

Regards

Anton

Am Di., 28. Juni 2022 um 07:49 Uhr schrieb Antonio Valentino
:
>
> Dear David and Anton,
>
> Il 28/06/22 00:56, David Bremner ha scritto:
> > Antonio Valentino  writes:
> >>
> >> David (in cc), how performed the initial packaging, recommends to
> >> maintain the package in debian-python.
> >> I have not a strong preference but my sponsoring request posted on
> >> debian-python have been ignored for long time, so I fear that there is
> >> not too much interest there for this package.
> >>
> >> I no one have objections I would be more comfortable to maintain the
> >> package in debian-science.
> >> If it is OK for you I can quickly update the package control file
> >> accordingly.
> >>
> >
> > It only seemed natural to package it in the python team, because people
> > there are experts in python modules. But I really don't have strong
> > opinions, I'm happy if someone will take care of it somewhere in Debian.
>
> thanks for the feedback David.
> In this case I would move the package into debian science.
>
> Anton, IMHO the first step is to move the repository.
> Is it something that I can do myself as a DM?
>
>
> regards
> --
> Antonio Valentino
>

Re: [RFS] resampy

[Anton Gladky]

Hi Antonio,

the package looks good. I would only propose to drop "resampy/data/"
because they are binaries. Is there any opportunity to replace it with the
text version maybe?

And you are going to put it into the python-team (which I think is totally OK),
but you are asking in the debian-science list :)

But I will sponsor it for python team too.

Regards

Anton

Am Mi., 22. Juni 2022 um 08:37 Uhr schrieb Antonio Valentino
:
>
> Dear Debian Science Maintainers,
> I have prepared a debian package for resampy [1], an "Efficient signal
> resampling. Implements band-limited sinc interpolation method for
> sampling rate conversion."
>
> The initial packaging has been started by David (in cc) and the ITP is
> at [2].
> The David's original idea was to maintain the package in debian-python
> [3] but it seems that there is not too much interest there, and I was
> not able to find a sponsor for the initial upload.
>
> I think that the package fits very well in debian-science and I'm
> wondering if there is interest in maintaining resampy under debian-science.
>
> Of course I will take care of the package maintenance and updates but I
> would need help to move the repository form debian-python [3], and also
> I need someone to review the package and sponsor the initial upload.
>
> In there anyone interested in sponsoring resampy?
>
>
> [1] https://github.com/bmcfee/resampy
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968469
> [3] https://salsa.debian.org/python-team/packages/resampy
>
> kind regards
> --
> Antonio Valentino
>

Re: Migration from vtk7 to vtk9

[Anton Gladky]

Hi François,

thanks for working on this!

Yes, those bugs are filed against packages, depending on vtk6 and vtk7.
I would firstly recommend finding out, whether the package has a newer
version and maybe vtk9 support is provided. If not - it makes sense to contact
upstream about migration to vtk9, and only if upstream is dead or not
quite active, does it make sense to dive into the code and fix it.

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


Anton

Am Di., 21. Juni 2022 um 22:15 Uhr schrieb François Mazen :
>
> 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
>
>

Re: gmp: machine-readable d/copyright and new repack

[Anton Gladky]

Hi Bastian,

thanks for the contribution!

I have just uploaded a new version with your changes
and repacked upstream tarball.

Best regards

Anton

Am So., 12. Juni 2022 um 02:09 Uhr schrieb Bastian Germann :
>
> Hi,
>
> I have just pushed some git commits that convert gmp's d/copyright file to 
> the machine-readable
> format and replace the repack logic to make use of Files-Excluded. Would some 
> team member who is
> more involved in gmp review the changes to make sure I have not missed 
> something?
>
> Thanks,
> Bastian
>

Re: SolveSpace update ready for review and sponsor

[Anton Gladky]

I have reviewed and uploaded the package! Thanks!

Anton

Am Mo., 16. Mai 2022 um 19:32 Uhr schrieb Ryan Pavlik :
>
> Hello Debian Science!
>
> I have prepared an updated package for SolveSpace, which I help
> develop/maintain, which recently put out its 3.1~rc1 release with
> substantial improvements. I have updated the package's git repo on
> salsa: https://salsa.debian.org/science-team/solvespace  and also
> pushed to Mentors: https://mentors.debian.net/package/solvespace/
>
> Since we now have upstream tarballs with the submodules included, we
> can now easily use debian/watch aka uscan to do the whole "getting new
> versions" thing, and we now use files-excluded in d/copyright to
> exclude mainly submodule files we don't want in our source package
> (Windows binaries, software already packaged in debian, generated
> doxygen files, etc.). Most of the patches I made for the last package
> release have now been integrated upstream, and only a few small new
> ones were needed, which are already submitted upstream. I also added
> lintian overrides for the false-positive checks, which does leave a
> few info/warning messages active, so I have a few things to improve in
> the future. However, it would be good to get this in. I did mostly
> test on Bullseye so it actually should be backportable easily too.
>
> Thank you!
>
> Ryan Pavlik
>

Re: SolveSpace update ready for review and sponsor

[Anton Gladky]

Hi Ryan,

thanks for the update and contribution! I will review and upload a package
within the next few days.

Best regards

Anton

Am Mo., 16. Mai 2022 um 19:32 Uhr schrieb Ryan Pavlik :
>
> Hello Debian Science!
>
> I have prepared an updated package for SolveSpace, which I help
> develop/maintain, which recently put out its 3.1~rc1 release with
> substantial improvements. I have updated the package's git repo on
> salsa: https://salsa.debian.org/science-team/solvespace  and also
> pushed to Mentors: https://mentors.debian.net/package/solvespace/
>
> Since we now have upstream tarballs with the submodules included, we
> can now easily use debian/watch aka uscan to do the whole "getting new
> versions" thing, and we now use files-excluded in d/copyright to
> exclude mainly submodule files we don't want in our source package
> (Windows binaries, software already packaged in debian, generated
> doxygen files, etc.). Most of the patches I made for the last package
> release have now been integrated upstream, and only a few small new
> ones were needed, which are already submitted upstream. I also added
> lintian overrides for the false-positive checks, which does leave a
> few info/warning messages active, so I have a few things to improve in
> the future. However, it would be good to get this in. I did mostly
> test on Bullseye so it actually should be backportable easily too.
>
> Thank you!
>
> Ryan Pavlik
>

Re: Google Summer of Code, Debian Science

[Anton Gladky]

Dear Debian Science team,

as discussed, I have submitted a proposal to GSoC 2022 [1].
I have a feedback that a second ("backup") person is needed as
a mentor.

If somebody wants to join this initiative, please drop me an email.

[1]
https://wiki.debian.org/SummerOfCode2022/PendingProjects/QualityAssuranceDebianScience

Thanks

Anton


Am Mo., 21. Feb. 2022 um 17:42 Uhr schrieb Anton Gladky :

> Dear all,
>
> Google Summer of Code call for Debian is announced [1].
> I am going to apply Debian Science Team as one of the projects.
>
> Main topic is QA-Work: Autopkgtests for high-popcon packages,
> gitlab-CI for most of packages, bringing not-in-testing packages
> into the proper shape to let them migrate to testing.
>
> If somebody wants to be a co-mentor or if you have better ideas
> for the project, please let me know.
>
> [1] https://lists.debian.org/debian-devel-announce/2022/02/msg2.html
>
> Best regards
>
> Anton
>

Re: Google Summer of Code, Debian Science

[Anton Gladky]

Hi Nilesh,

yes, thanks for the reminder. I will do it today.
News from the last few days beated me personally. So,
it is difficult to concentrate on the work.

Regards

Anton

Am Di., 1. März 2022 um 14:51 Uhr schrieb Nilesh Patra :
>
> On 2/22/22 5:36 PM, Anton Gladky wrote:
> > Hello Drew,
> >
> > It is a very good idea!
> >
> > Though I would separate this task from QA-work on Debian Science
> > packages. [...]
>
> Anton, Google is reviewing our projects (as I saw one of the admins saying 
> that on IRC)
> So you might want to add atleast one project to the wiki rather quickly,
> so we don't run out of time to do so.
>
> Regards,
> Nilesh

Re: Google Summer of Code, Debian Science

[Anton Gladky]

Hello Andreas,

thank you very much for offering a help! Yes, it would be fine
if you run the script.

Best regards

Anton

Am Di., 22. Feb. 2022 um 11:28 Uhr schrieb Andreas Tille :
>
> Hi,
>
> Am Mon, Feb 21, 2022 at 05:42:56PM +0100 schrieb Anton Gladky:
> > Google Summer of Code call for Debian is announced [1].
> > I am going to apply Debian Science Team as one of the projects.
> >
> > Main topic is QA-Work: Autopkgtests for high-popcon packages,
> > gitlab-CI for most of packages, bringing not-in-testing packages
> > into the proper shape to let them migrate to testing.
> >
> > If somebody wants to be a co-mentor or if you have better ideas
> > for the project, please let me know.
>
> I'm basically running the same GSoC project in Debian Med (as in
> previous years) and to my experience this is an extremely valuable
> project.  Students have a low entry barrier and its quite granted that
> you get sensible output since it is split into tiny tasks which are all
> helpful once solved.
>
> If you want me to run this script[1] also for Debian Science as I do it
> in a cron job for Debian Med I can very easily do it.  The text file[2]
> (result of the cron job) has turned out to be very helpful for the
> intern (and others!) to pick sensible packages.
>
> Kind regards
>
>   Andreas.
>
> [1] 
> https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/missing-autopkgtest
> [2] 
> https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/debian-med-tests.txt
>
> --
> http://fam-tille.de
>

Re: Google Summer of Code, Debian Science

[Anton Gladky]

Hello Drew,

It is a very good idea!

Though I would separate this task from QA-work on Debian Science
packages. If you want, we could apply one-more project (something
like HPC-testing of MPI-based science packages) and point special
requirements for possible applicants. Feel free to propose a text
for that. Thanks again!

Regards

Anton

Am Di., 22. Feb. 2022 um 12:52 Uhr schrieb Drew Parsons :
>
> On 2022-02-21 17:42, Anton Gladky wrote:
> > Dear all,
> >
> > Google Summer of Code call for Debian is announced [1].
> > I am going to apply Debian Science Team as one of the projects.
> >
> > Main topic is QA-Work: Autopkgtests for high-popcon packages,
> > gitlab-CI for most of packages, bringing not-in-testing packages
> > into the proper shape to let them migrate to testing.
> >
> > If somebody wants to be a co-mentor or if you have better ideas
> > for the project, please let me know.
> >
> > [1]
> > https://lists.debian.org/debian-devel-announce/2022/02/msg2.html
>
>
> It would be helpful to run parallel/HPC performance testing for our MPI
> numerical packages.
>
> This would be a type of CI testing that we would set up to run regularly
> and report.
> Lucas Nussbaum is in charge of an academic supercomputing cluster that
> we can access to run such tests.
>
> Some packages have benchmarks already at hand.  The FEniCS project for
> instance offers fenicsx-performance-tests (both prebuilt and source).
>
> The project would determined how to set up MPI CI testing (how to
> activate it on Lucas' system), and what parameters (test size etc) to
> use to get meaningful numbers.
> A suggested tools for managing test parameters and results might be
> https://reframe-hpc.readthedocs.io/en/stable/
>
> The report format could be similar to
> https://fenics.github.io/performance-test-results/
> or perhaps the GSoC worker could come up with a better way of presenting
> results.
>
> It would be useful to be able to quantify how well our HPC packages
> actually scale (in cloud computing environments) and monitor if there's
> any drop in performance (e.g. with version updates)
>
> Also useful to report their performance with the various BLAS
> alternatives.
>
> This would be valuable GSoC project I think.
>
> Drew

Google Summer of Code, Debian Science

[Anton Gladky]

Dear all,

Google Summer of Code call for Debian is announced [1].
I am going to apply Debian Science Team as one of the projects.

Main topic is QA-Work: Autopkgtests for high-popcon packages,
gitlab-CI for most of packages, bringing not-in-testing packages
into the proper shape to let them migrate to testing.

If somebody wants to be a co-mentor or if you have better ideas
for the project, please let me know.

[1] https://lists.debian.org/debian-devel-announce/2022/02/msg2.html

Best regards

Anton

Re: RFS faber - build dependency for boost-python

[Anton Gladky]

Hi Steffen,

thanks for your work and packaging effort. I will take a deeper
look into the package within the next few days.

On behalf of the Debian Boost Team.

Best regards

Anton

Am Di., 8. Feb. 2022 um 18:07 Uhr schrieb Steffen Möller
:

>
> Hello,
>
> This is about
>
> https://salsa.debian.org/python-team/packages/faber
>
> I had asked the Debian boost folks already to comment on that package
> but have not heard back. Faber is a build tool that the upstream boost
> community has elevated as the next thing for their Python interface. But
> it can also be used as a substitute for make.
>
> Anyway. Could someone please have a look that I have not borked to
> smoothen the transition through NEW? Please feel free to upload.
>
> Many thanks!
>
> Best,
> Steffen
>

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

[Anton Gladky]

Uploaded as well.

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.

Cheers

Anton

Am Fr., 28. Jan. 2022 um 09:17 Uhr schrieb 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

[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

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

[Anton Gladky]

Hi Markus,

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

Anton

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
>

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)

[Anton Gladky]

Hi Markus, thanks for contribution!

I briefly reviewed your packages and did not find any
serious issues there! Also employing Salsa-CI is really
cool stuff, which is helping to be sure that the package
is OK.

Please consider to become DM/DD.

Best regards

Anton

Am Mi., 17. Nov. 2021 um 09:50 Uhr schrieb 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)

[Anton Gladky]

Hi Markus,

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

Regards


Anton

Am Di., 16. Nov. 2021 um 23:47 Uhr schrieb 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)

[Anton Gladky]

Hi Markus,

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

Best regards

Anton

Am Do., 4. Nov. 2021 um 18:17 Uhr schrieb 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: Request to join

[Anton Gladky]

Hi,

Welcome on board! Added to the salsa-group.

Regards

Anton

Am Mi., 3. Nov. 2021 um 20:39 Uhr schrieb Jose Manuel Abuin Mosquera
:
>
> Hello.
>
> My name is Jose Manuel Abuin, I am a scientific software developer and a
> Debian user since a long time ago. I would like to join the group and
> help in anything I can. My login in salsa is jmabuin-guest
>
> For more information you can take a look at my web
> http://jmabuin.github.io/ or my GitHub https://github.com/jmabuin
>
> Cheers!
>
> Jose M. Abuin
>

Re: Debian Math Team

[Anton Gladky]

I think we all have a very limited free time to work on Debian.
At least it is my situation.

Newcomers are looking for reviewers/uploaders, trying to reach
a relatively large audience in d/science, sometimes for a very long
time without success. How will it work in a smaller team?

Doing some large transitions (vtk, boost, etc.) I am always very glad
seeing package maintained in a d/science because it is very easy
to make a tiny uploads, reaching the result very fast without filing
bugs, NMUs etc. All these official bureaucratic procedures  take a lot
of time and at the end slow down the process. Why do we want to
get a one-more team with own policy, necessity to be a member of it
doing such uploads etc. It makes things harder!

I have unsubscribed myself from most of the mailing lists (even from
debian-devel, sorry), leaving only important ones for me to save some
more time for QA-work, reviewing/sponsoring/uploading packages, fixing
bugs, setting CI-pipelines for salsa-repos etc.  Why do we want to spread
an energy/time writing new policy, moving packages etc?

My strong opinion is that new barriers (blends/teams/salsa-groups whatever)
will unlikely improve the total quality and amount of Debian packages.
For me it just means that I will probably need to file more NMUs, asking
other people for reviews etc... It is a pain and a waste of time. Sorry.

I will probably need to request membership in other teams due to
some QA or release-transition work, but

Regards

Anton

Re: Debian Math Team

[Anton Gladky]

I do not see any benefits from creating a one-more team. It decreases
definitely bus-factor of the package, will unlikely increase their quality
and for end-users it is mostly not visible, in what team it is maintained.

Sure, feel free to create it, if you want, but please do not move any existing
packages from any team to a new one without prior confirmation of all
uploaders.

>From my point of view, we have enough really useful work in Debian which
needs to be done (fixing bugs, adding autopkgtests, setting-up
CI-pipelines etc.)
instead of moving packages between teams.

Cheers

Anton

Re: Debian Math Team

[Anton Gladky]

Hi Doug,

well, I think that it just increases a fragmentation. But it is up to you.

Best regards

Anton

Am Fr., 29. Okt. 2021 um 22:04 Uhr schrieb Torrance, Douglas
:
>
> During the Debian Science BoF at this year's DebConf, there was some
> discussion of creating a team devoted to packaging mathematical software.
>
> This seemed like a pretty good idea, so I figured that I'd go ahead and
> start working on getting it set up.  I've already created a Salsa group [1]
> and a team on the Debian Package Tracker [2].  If you're interested in
> joining, then you should be able to sign up at these links.
>
> I figured next would be applying for a mailing list, putting together a team 
> policy, etc.  Any thoughts?
>
> Doug
>
> [1] https://salsa.debian.org/math-team
> [2] https://tracker.debian.org/teams/math/

Re: Joining the team

[Anton Gladky]

Hi Roland,

Welcome on board! I have added you into the team.

Regards


Anton


Am So., 10. Okt. 2021 um 16:36 Uhr schrieb Roland Mas :

> Hi all,
>
> I've been contracted by Synchrotron SOLEIL to work on packaging
> scientific applications and libraries and other software used in
> scientific contexts. Some of them can belong under the Python team,
> others under the Javascript team, but some are not really relevant to
> those two teams, so I'd rather package them under the Debian Science
> Team umbrella.
>
> So this email is my introduction to the team, and a request to be added
> to the Salsa group (my login is "lolando") so as to be able to keep the
> relevant packages in the right place.
>
> See you :-)
>
> Roland.
>
>

Re: Update Ceres Solver to 2.0.0

[Anton Gladky]

Hi François,

thanks for the update! I will definitely check it
within the next few days.

Best regards

Anton


Andrius Merkys  schrieb am Mo., 4. Okt. 2021, 08:29:

> Hi François,
>
> On 2021-10-03 12:50, François Mazen wrote:
> > 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?
>
> Transitions for libs packages in Debian indeed have to proceed a certain
> workflow [3]. To start with, you should target experimental instead of
> unstable in debian/changelog.
>
> > In addition, could you please grant me right to upload the package as
> > I'm DM?
>
> It would be best if Anton could help you with upload and rights.
>
> > [1] https://salsa.debian.org/science-team/ceres-solver
> > [2] https://mentors.debian.net/package/ceres-solver/
>
> [3] https://wiki.debian.org/Teams/ReleaseTeam/Transitions
>
> Best,
> Andrius
>
>

Re: upgrading numerical libraries and sundials

[Anton Gladky]

Hello Drew,

yes, I will prepare a newer sundials update within the next few days.

Regards


Anton


Am Fr., 1. Okt. 2021 um 02:23 Uhr schrieb Drew Parsons :

> I'm preparing the numerical library upgrade to push to unstable.
> That's superlu-dist hypre mumps petsc slepc.
>
> I discovered that sundials 2.7.0 is incompatible with hypre 2.22.
> But right in the middle of testing they released 2.8.0, so it's already
> ready to go.
>
> Anton, do you prefer to prepare sundials 2.8.0 yourself, or would you
> like me to push it to experimental?
> It contains a few ABI bumps (arkode4, cvode5, ida5, kinsol5,
> nvecserial5) so it'll have to pass NEW.
>
> We'll also need to coordinate upgrade of xtl with xtensor, though that
> could be done separately from the other numerical libraries.
> (Vincent, would it be interesting for the Quantstack team to take over
> xtensor and xtensor-blas?  Or to join and transfer xtl to the Debian
> Science team?)
>
> Drew
>
>

Re: [Fwd: Bug#988474: RFS: freefem++/3.61.1+dfsg1-5.2 [NMU] [RC] -- Provides the binaries of the FreeFem++ FE suite]

[Anton Gladky]

You are right. piparts was trying to install the current version
in unstable to test the migration. But it failed, because version
in unstalbe is uninstallable.

I have uploaded the package, but pay attention, i have changed
the version number to freefem++_3.61.1+dfsg1-6.

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.

Anyway, we will have also an opportunity to put freefem++ insto
bullseye-backports,
but you can start to work on a newer version at least on salsa.

Regards

Anton


Am Do., 13. Mai 2021 um 23:16 Uhr schrieb François Mazen :

> 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: [Fwd: Bug#988474: RFS: freefem++/3.61.1+dfsg1-5.2 [NMU] [RC] -- Provides the binaries of the FreeFem++ FE suite]

[Anton Gladky]

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 :

> 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: [Fwd: Bug#988474: RFS: freefem++/3.61.1+dfsg1-5.2 [NMU] [RC] -- Provides the binaries of the FreeFem++ FE suite]

[Anton Gladky]

Control: tags -1 +pending

Hi François,

thanks for fixing this issue. I am testing it and if it works, I will
upload it.
I am not sure, whether it will be possible to reintroduce this package
in testing on this stage of the freeze. Please contact the release team
about that.

Welcome to join Debian Science Team as a co-maintainer of this
(and maybe other) packages. I have added you to the corresponding
salsa group.

Anton


Am Do., 13. Mai 2021 um 19:27 Uhr schrieb François Mazen :

> 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: [RFS] Re: Bug#987921: linbox FTBFS on 32bit with gcc 10

[Anton Gladky]

Your changes look good. Let's wait for approval by
release team not to pollute unstable by unapproved uploads.

Regards

Anton


Am Mo., 10. Mai 2021 um 11:40 Uhr schrieb Torrance, Douglas <
dtorra...@piedmont.edu>:

> On Sun 09 May 2021 05:16:38 PM EDT, Anton Gladky wrote:
> > I will review/upload the package tomorrow,
> > Please file a pre-approval request against release.debian.org. Thanks
>
> Thanks!  Pre-approval request: https://bugs.debian.org/988296
>
> Doug

Re: [RFS] Re: Bug#987921: linbox FTBFS on 32bit with gcc 10

[Anton Gladky]

Hi Doug,

I will review/upload the package tomorrow,
Please file a pre-approval request against release.debian.org. Thanks

Regards

Anton


Am So., 9. Mai 2021 um 22:48 Uhr schrieb Torrance, Douglas <
dtorra...@piedmont.edu>:

> Control: tags -1 pending
>
> On Sun 02 May 2021 12:46:50 AM EDT, Adrian Bunk wrote:
> > Source: linbox
> > Version: 1.6.3-2
> > Severity: serious
> > Tags: ftbfs
> >
> >
> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/i386/linbox.html
>
> I've fixed this RC bug in git:
> https://salsa.debian.org/science-team/linbox
>
> Would anyone be willing to review/sponsor?  I'm hoping that linbox won't
> get removed before the bullseye release.
>
> Thanks!
> Doug
>

Re: Packaging Open Porous Media (OPM) software suite

[Anton Gladky]

Hi Markus,

Welcome on board! I have added you to the salsa group of the
Debian Science Team. Feel free to push your projects there.

I did not have a deep look into the packaging, but have some notes:

- Try to use the newer compat-version. 11 is a little bit outdated.
- Please add autopkgtests for packages.
- Try to add Gitlab-CI for every package. It definitely improves the
package quality
  and makes the package maintenance easier.
- 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.

> - In the future we imight want to  be able to install several versions

I would recommend not to do it. At least in the official version of the
Debian package.
That just means that every new upload should have another binary name, NEW
queue,
sponsoring from DD etc. It can only have sense for very big and very
popular packages
like boost for example. But for small scientific packages it is just
overhead.

> Does the top-level directory in the tarballs need to have a special

No. If you do "dpkg-source -x AAA.dsc" the top level directory will be
overwritten.

Just a general note. Make the simple things not too complicated. Otherwise
the package will not work and is very difficult in maintenance.

Best regards

Anton


Am Mi., 28. Apr. 2021 um 15:40 Uhr schrieb 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 

Re: VTK and ParaView parallelization

[Anton Gladky]

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 :

> 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
>
>
>

Re: ortools package

[Anton Gladky]

Hi Romain,

thanks for interest to work inside of the Debian science team.
I have added you to salsa, please push your changes there and
let us know when the package is being ready to be reviewed.

Best regards


Anton


Am Fr., 19. März 2021 um 17:36 Uhr schrieb Romain Porte :

> Hello Debian Science team,
>
> Please keep me in Cc, not part of the list.
>
> I recently filled an ITP [1] for Google's OR-Tools [2].
>
> I would like this package to be introduced in the Debian Science team. I
> have requested access to the team on Salsa, but did not get any answer
> so far.
>
> The current implementation depends on some source packages to be
> reviewed by the Debian Python team. Nevertheless I would like to create
> the repository on Salsa, put my initial work on it and ask for feedback
> as it contructs a good number of binary packages:
>
> libortools-dev_8.2+ds-1_amd64.deb libdevel optional
> libortools-doc_8.2+ds-1_all.deb doc optional
> libortools8-dbgsym_8.2+ds-1_amd64.deb debug optional automatic=yes
> libortools8_8.2+ds-1_amd64.deb libs optional
> ortools-examples_8.2+ds-1_all.deb science optional
> ortools-flatzinc-dbgsym_8.2+ds-1_amd64.deb debug optional automatic=yes
> ortools-flatzinc_8.2+ds-1_amd64.deb science optional
> ortools-samples-dbgsym_8.2+ds-1_amd64.deb debug optional automatic=yes
> ortools-samples_8.2+ds-1_amd64.deb science optional
> ortools_8.2+ds-1_amd64.buildinfo science optional
> python3-ortools-dbgsym_8.2+ds-1_amd64.deb debug optional automatic=yes
> python3-ortools_8.2+ds-1_amd64.deb python optional
>
> Thanks in advance for showing me the way to proceed.
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985094
>
> [2] https://github.com/google/or-tools
>
> Romain.
>
>

Re: freefem-sources upload

[Anton Gladky]

Hi Dimitrios,

I have enabled the CI-pipeline for freefem. It builds, but it looks like
there
are some problems with piuparts, blhc and lintian [1]. Some of errors seems
to be relevant (missing breaks+replaces?).

Also I have shortly looked in the package and it seems d/copyright should
definitely be updated and improved. Many third party sources are missing
there.
Please check EVERY file in the source and update d/copyright. Also maybe
the source should be repacked and some libs could be dropped prior the
packaged variants?

Feel free to contact me if you have any questions or the package is ready to
be reviewed and uploaded.

[1] https://salsa.debian.org/science-team/freefempp/-/pipelines/228521

Best regards

Anton



Am So., 7. Feb. 2021 um 06:01 Uhr schrieb Dimitrios Eftaxiopoulos <
eftax...@otenet.gr>:

> Hi,
>
> An upload of the src:freefem-sources package (continuation of the
> src:freefem+
> +  package), has been prepared in
>
> https://salsa.debian.org/science-team/freefempp/-/tree/experimental
>
> The upload should fix the serious #957233 bug (ftbfs with gcc-10) and
> should go
> to the NEW queue (change of source package name by upstream and removal
> and
> addition of binary packages).
>
> Could someone have a look and possibly upload?
>
> Regards
> Dimitris
>
>
>

Re: Sponsoring of packages for the next stable release

[Anton Gladky]

You are welcome!

There is a build problem on arm64 "96 - ContactTest (Timeout)". Please
fix or disable this
only test. I have restarted the build but it did not succeed.

Regards

Anton

Am So., 24. Jan. 2021 um 17:54 Uhr schrieb Stephen Sinclair
:
>
> Great, thank you Anton, I don't think I would have figured that out!  This 
> should be extremely helpful for future maintenance.
>
> regards,
> Steve

Re: Sponsoring of packages for the next stable release

[Anton Gladky]

Hi Stephen,

I have disabled i386 build [1] and reduced the size of salsa-build binaries [2].
Now it builds fine in pipeline and I have uploaded the package.

[1] 
https://salsa.debian.org/science-team/siconos/-/commit/8aca640c2743655e87aa181ddfd153f51e6f58e7
[2] 
https://salsa.debian.org/science-team/siconos/-/commit/9a836cee37a46e20721ab33871f55b54e6e953dc

Best regards

Anton

Am Sa., 23. Jan. 2021 um 14:48 Uhr schrieb Stephen Sinclair
:
>
> Hi Anton,
>
> Thanks, last time I tried to use the salsa pipeline for this package,
> it was not possible because the build produced too much log output and
> failed for that reason.
> It seems that in your attempt, it actually makes it all the way to the
> end; I'm actually not clear on what "fails", it actually succeeds
> building and testing the package, but ends with,
>
> > Uploading artifacts as "archive" to coordinator... failed
> > context=artifacts-uploader error=invalid argument
>
> I have no idea what arguments to what program are invalid here, but it
> seems to have to do with the pipeline process and not the package
> itself.
>
> https://salsa.debian.org/science-team/siconos/-/jobs/1367137
>
> For the i386 build, it fails unfortunately simply because the machine
> runs out of memory.  (The build annoyingly requires upwards of 7 GB of
> memory while compiling the SWIG bindings; part of the motivation for
> wanting to distribute a pre-compiled package!)  However to be honest I
> am not sure siconos works properly on 32-bit architectures anyway.
> https://salsa.debian.org/science-team/siconos/-/jobs/1367138
>
> As for other architectures, there is a bug on arm64 that I have been
> trying to fix but it is not an easy one.  In the meantime the package
> is very useful for x86_64 users, who are in the majority.
>
> regards,
> Steve
>
> On Fri, Jan 22, 2021 at 10:36 PM Anton Gladky  wrote:
> >
> > Hi Stephen,
> >
> > I have enabled the salsa-pipeline on siconos package and it seems
> > fails to build currently [1]. Could you please take a look and let me know,
> > whether it is ready to be uploaded.
> >
> > Thanks
> >
> > [1] https://salsa.debian.org/science-team/siconos/-/pipelines
> >
> > Anton
> >
> > Am Mi., 20. Jan. 2021 um 22:46 Uhr schrieb Stephen Sinclair
> > :
> > >
> > > Hello,
> > >
> > > If there still is time, there is a minor version upstream update to
> > > the siconos package looking for a sponsor:
> > > https://mentors.debian.net/package/siconos/
> > >
> > >  siconos (4.3.1+dfsg-1) unstable; urgency=medium
> > >  .
> > >* New upstream release.
> > >* Rebase patches:
> > >  + Remove upstreamed patch to FindLAPACK.cmake.
> > >* Update policy version 4.5.1.
> > >    * Update debhelper version 13.
> > >* Add missing symbols for numerics.
> > >* Change architecture for siconos and siconos-mechanics-tools to all.
> > >* Add debian/upstream/metadata.
> > >* Replace debian/compat with debhelper-compat package.
> > >
> > >
> > > regards,
> > > Steve
> > >
> > > On Sat, Jan 9, 2021 at 9:27 PM Anton Gladky  wrote:
> > > >
> > > > Dear members of Debian Science Team,
> > > >
> > > > we are approaching to a new stable release freeze. If youhave some
> > > > packages to be sponsored, please let us know.
> > > >
> > > > I have a very limited time, but I will try to review/sponsor someof
> > > > packages.
> > > >
> > > >
> > > > Best regards
> > > >
> > > > Anton
> > > >

Re: Sponsoring of packages for the next stable release

[Anton Gladky]

Hi Stephen,

I have enabled the salsa-pipeline on siconos package and it seems
fails to build currently [1]. Could you please take a look and let me know,
whether it is ready to be uploaded.

Thanks

[1] https://salsa.debian.org/science-team/siconos/-/pipelines

Anton

Am Mi., 20. Jan. 2021 um 22:46 Uhr schrieb Stephen Sinclair
:
>
> Hello,
>
> If there still is time, there is a minor version upstream update to
> the siconos package looking for a sponsor:
> https://mentors.debian.net/package/siconos/
>
>  siconos (4.3.1+dfsg-1) unstable; urgency=medium
>  .
>* New upstream release.
>* Rebase patches:
>  + Remove upstreamed patch to FindLAPACK.cmake.
>* Update policy version 4.5.1.
>* Update debhelper version 13.
>* Add missing symbols for numerics.
>* Change architecture for siconos and siconos-mechanics-tools to all.
>* Add debian/upstream/metadata.
>* Replace debian/compat with debhelper-compat package.
>
>
> regards,
> Steve
>
> On Sat, Jan 9, 2021 at 9:27 PM Anton Gladky  wrote:
> >
> > Dear members of Debian Science Team,
> >
> > we are approaching to a new stable release freeze. If youhave some
> > packages to be sponsored, please let us know.
> >
> > I have a very limited time, but I will try to review/sponsor someof
> > packages.
> >
> >
> > Best regards
> >
> > Anton
> >

Re: Sponsoring before freeze

[Anton Gladky]

Hi Thomas,

there is one of examples [1].  But as far as I see, this package is
not a library.
It is not necessary to build it in autopkgtest.

The sense of autopkgtest is to test the package functionality. So you can
for example run some tests to check, whether they are working. Cmake builds
are relevant for libs to be sure that they are providing proper headers and
shared objects.

Regards

[1] https://salsa.debian.org/science-team/vtk9/-/tree/master/debian/tests

Anton

Am Di., 19. Jan. 2021 um 23:02 Uhr schrieb Thomas Schiex
:
>
> Dear Anton,
>
> I pushed the new upstream version of toulbar2.
>
> I'm now wondering what autopkgtest would be useful for. When you build
> the package, the dh_auto_test target does launch our ctest target. So
> the tests are run anyway for all builds. What does autopkgtest would
> bring then?
>
> Also, if someone has an example of a package that uses autopkgtest in a
> cmake with ctest context in mind,  this could help.
>
> Kind regards
>
> Thomas
>
> Le 18/01/2021 à 22:24, Anton Gladky a écrit :
> > Hi Thomas,
> >
> > uploaded! Thanks for your contribution.
> >
> > Please consider adding autopkgtest for the next upload. If you
> > prepare them before freeze, please let me know and I will upload it.
> >
> > Regards
> >
> > Anton

Re: Sponsoring of packages for the next stable release

[Anton Gladky]

Thanks a lot for update. Please prepare a merge request, let's check
the pipelines and I will upload
it into the experimental.

Best regards

Anton

Am Do., 21. Jan. 2021 um 18:10 Uhr schrieb Ryan Pavlik :
>
> Update: I re-did it calling it 3.0.rc2+repack1 since the ~ ended up
> breaking piuparts on CI. It's just a minor detail in the scheme of
> things, I assume. I have pushed to the team repo.
>
> It should be "safe" to release now. There is new support for OpenMP and
> LTO, but without direct access to experimental and buildd's of the
> various architectures, I wouldn't want to upload a package to unstable
> at this point with those enabled and risk breaking it. It works fine, if
> a smidge slower than possible, without openmp and LTO enabled, so I
> think probably leave it well enough alone.
>
> I've added some autopkgtests using the CLI interface as completely as
> possible without modifying the source tree, which should help too.
> Probably the most fragile part of the package is the use of three-js
> (libjs-three) for the HTML trimesh viewer export: if that gets updated
> and breaks something being used, the export will appear to work fine but
> will hit a javascript error on usage. I'd be interested to learn how to
> write up the test to catch this, if anybody has ideas.
>
> Thanks!
>
> Ryan
>
> On 1/19/2021 5:57 PM, Ryan Pavlik wrote:
> > Anton,
> >
> > Thanks for taking the time to update that package! Upstream has released
> > another RC (which should be identical to 3.0 with the exception of
> > translation updates). Additionally, we've found a patch from upstream
> > mimalloc that should fix the armel build (I hope), and which I have
> > included in the debian package. I have updated to that upstream release,
> > and updated the package substantially (removed some bundled fonts and
> > js, etc) and pushed to my salsa repo: I wasn't sure if you wanted me to
> > push to the main team repo, especially since the existing version is
> > "3.0.rc1+repack1" which Lintian warns me is not less than 3.0 - I did my
> > import as "3.0~rc2+repack1" accordingly.
> >
> > https://salsa.debian.org/rpavlik/solvespace
> >
> > When you have a chance, I'd appreciate a review and sponsoring. I've
> > done basic testing of the package myself, especially the parts that are
> > affected by patches/repack, and it seems to work well to me.
> >
> > Thanks!
> >
> > Ryan
> >
> > On 1/16/2021 12:09 PM, Anton Gladky wrote:
> >> Hi Ryan,
> >>
> >> the newer version of solvespace is in sid already. There is a problem
> >> with armel compilation
> >>
> >> selected processor does not support `yield' in ARM mode
> >>
> >> So I requested the removal of the package on this platform.
> >> If somebody has an advice how to fix this special assembler-problem,
> >> please let me know.
> >>
> >> Best regards
> >>
> >> Anton
> >>
> >>
> >> Anton
> >>
> >>
> >> Am Do., 14. Jan. 2021 um 00:33 Uhr schrieb Ryan Pavlik 
> >> :
> >>> On 1/9/2021 2:27 PM, Anton Gladky wrote:
> >>>> Dear members of Debian Science Team,
> >>>>
> >>>> we are approaching to a new stable release freeze. If youhave some
> >>>> packages to be sponsored, please let us know.
> >>>>
> >>>> I have a very limited time, but I will try to review/sponsor someof
> >>>> packages.
> >>>>
> >>>>
> >>>> Best regards
> >>>>
> >>>> Anton
> >>> I see you were the last to touch the SolveSpace package. Do you expect
> >>> to have time to look at that soon to update to the new RC? (They/we have
> >>> very high stability standards, 3.0 could have been released 2 years ago)
> >>> If not, I'll go ahead and update to the latest tagged upstream this week
> >>> and request sponsorship.
> >>>
> >>>
> >>> Thanks,
> >>>
> >>>
> >>> Ryan
> >>>
> >>>
>

Re: Sponsoring before freeze

[Anton Gladky]

Hi Thomas,

uploaded! Thanks for your contribution.

Please consider adding autopkgtest for the next upload. If you
prepare them before freeze, please let me know and I will upload it.

Regards

Anton

Am Do., 14. Jan. 2021 um 00:39 Uhr schrieb Thomas Schiex
:
>
> Dear Anton,
>
> I have tried to prepare toulbar2 with a new upstream version. If something is 
> missing I'm happy to inject extra effort in it.
>
> Thomas

Re: python-rioxarray

[Anton Gladky]

Hi Magnus,

there are only recommendation, how do I usually deal with
such kind of problems:

> * the upstream tar ball comes with the egg-info directory. Presumably
> I should remove that since it gets generated?

Yes, remove. Put the wildcard in d/copyright under Files-Excluded section
and do "uscan --download --repack".

>  * the upstream project helpfully credits parts of the code that they
> have adapted from other projects. However, they folded their changes
> into other files. How is that reflected in the copyrights file?

All copyrights-holders should definitely be mentioned in d/copytight.
Otherwise the package will be rejected. The best way to drop all embedded
copies of third-party code and replace them by packaged versions, if they are
available in archive and if it is technically possible.

>  * I do get a bunch of warnings about privacy issues in the sphinx
> generated docs. I attempted to use the same rules as xarray but that
> didn't quite work. Also there are references to other images. How are
> these dealt with?

I am using "sed" to drop those places [1], [2]. But it can sometimes break
images, links etc.

[1] https://salsa.debian.org/science-team/yade/-/blob/master/debian/rules#L66
[2] https://salsa.debian.org/science-team/sumo/-/blob/master/debian/rules#L29

Regards

Anton

Am Do., 14. Jan. 2021 um 19:39 Uhr schrieb Magnus HAGDORN
:
>
> Hi all,
> I have just uploaded the first of my python packages that is probably
> closest to being finished to mentors. I am still in the process of
> figuring out how debian packaging in general and python packaging in
> particular works. I did copy a lot of the debian build machinery from
> the xarray package which was very helpful.
>
> So, I have a few issues still:
>  * the upstream tar ball comes with the egg-info directory. Presumably
> I should remove that since it gets generated?
>
>  * the upstream project helpfully credits parts of the code that they
> have adapted from other projects. However, they folded their changes
> into other files. How is that reflected in the copyrights file?
>
>  * I do get a bunch of warnings about privacy issues in the sphinx
> generated docs. I attempted to use the same rules as xarray but that
> didn't quite work. Also there are references to other images. How are
> these dealt with?
>
>  * I need to sort out the tests
>
> I have added the repo to salsa, it can be found here:
> https://salsa.debian.org/science-team/python-rioxarray
>
> Cheers
> magnus
> The University of Edinburgh is a charitable body, registered in Scotland, 
> with registration number SC005336.

Re: RFS: macaulay 1.17.1

[Anton Gladky]

Hi, I will take care of it.

Anton

Am So., 17. Jan. 2021 um 13:13 Uhr schrieb Torrance, Douglas
:
>
> On 1/11/21 7:54 PM, Doug Torrance wrote:
> > A new release of Macaulay2 was just announced.  I've packaged it for
> > Debian, and I think it's ready for upload to unstable:
> >
> > https://salsa.debian.org/science-team/macaulay2
> >
> > Would anyone be able to review/sponsor?
>
> My test builds of this package started failing due to some recent
> changes made in node-jquery.  I've pushed some new commits fixing the
> issue.  Still looking for a sponsor.  I'd love to get Macaulay2 into
> testing before the freeze!
>
> Thanks!
> Doug

Re: Sponsoring of packages for the next stable release

[Anton Gladky]

Hi Ryan,

the newer version of solvespace is in sid already. There is a problem
with armel compilation

selected processor does not support `yield' in ARM mode

So I requested the removal of the package on this platform.
If somebody has an advice how to fix this special assembler-problem,
please let me know.

Best regards

Anton


Anton


Am Do., 14. Jan. 2021 um 00:33 Uhr schrieb Ryan Pavlik :
>
>
> On 1/9/2021 2:27 PM, Anton Gladky wrote:
> > Dear members of Debian Science Team,
> >
> > we are approaching to a new stable release freeze. If youhave some
> > packages to be sponsored, please let us know.
> >
> > I have a very limited time, but I will try to review/sponsor someof
> > packages.
> >
> >
> > Best regards
> >
> > Anton
>
>
> I see you were the last to touch the SolveSpace package. Do you expect
> to have time to look at that soon to update to the new RC? (They/we have
> very high stability standards, 3.0 could have been released 2 years ago)
> If not, I'll go ahead and update to the latest tagged upstream this week
> and request sponsorship.
>
>
> Thanks,
>
>
> Ryan
>
>

Re: RFS: robot-testing-framework/2.0.1-1 [ITP] -- Robot Testing Framework

[Anton Gladky]

OK, uploaded! Please add manual page for the binary for the next upload.

Regards


Anton


Am Di., 12. Jan. 2021 um 22:46 Uhr schrieb Daniele E. Domenichelli <
ddomeniche...@drdanz.it>:

> On 12/01/2021 19:19, Daniele E. Domenichelli wrote:
> > Should I remove it from the source tarball as well?
>
> I removed tinyxml source from the tarball (thanks @Leopold for the
> suggestion) and uploaded version 2.0.1+ds1-1 to mentors.
>
> Cheers,
>  Daniele
>
>

Sponsoring of packages for the next stable release

[Anton Gladky]

Dear members of Debian Science Team,

we are approaching to a new stable release freeze. If youhave some
packages to be sponsored, please let us know.

I have a very limited time, but I will try to review/sponsor someof
packages.


Best regards

Anton



OpenPGP_signature
Description: OpenPGP digital signature

Re: RFS: robot-testing-framework/2.0.1-1 [ITP] -- Robot Testing Framework

[Anton Gladky]

Hi Daniele,

thanks for your contribution!

Your package looks fine to me. I have just a couple of minor notes.
Please fix them and I will upload the package.

- please go through ALL files and put license information, if the
  copyright is different from default one (check files in cmake-folder
and others)
- tinyxml is packaged for Debian. Please try to use the packaged
  version and drop an embedded  one, if it is possible. There
  should be a good reason not to use a packaged version of the
  software.
- push pristine-tar branch

Best regards

Anton

Am Di., 15. Dez. 2020 um 09:44 Uhr schrieb Daniele E. Domenichelli
:

>
> Any other comment on this package?
> Will anyone sponsor the upload?
>
> Thanks in advance.
>
> Daniele
>
>
> On 15/11/2020 14:33, Daniele E. Domenichelli wrote:
> > Package: sponsorship-requests
> > Severity: wishlist
> >
> > Dear mentors,
> >
> > I am looking for a sponsor for my package "robot-testing-framework":
> >
> >   * Package name: robot-testing-framework
> > Version : 2.0.1-1
> > Upstream Author : Istituto Italiano di Tecnologia (IIT)
> >   * URL : https://robotology.github.io/robot-testing-framework/
> >   * License : GPL-2, LGPL-2.1+
> >   * Vcs :
> > https://salsa.debian.org/science-team/robot-testing-framework
> > Section : libs
> >
> > It builds those binary packages:
> >
> >robot-testing-framework - Robot Testing Framework (metapackage)
> >librobottestingframework-doc - Robot Testing Framework - documentation
> >robottestingframework-testrunner - Robot Testing Framework -
> > robottestingframework-testrunner
> >librobottestingframework-python2 - Robot Testing Framework -
> > RTF_python library
> >librobottestingframework-ruby2 - Robot Testing Framework - RTF_ruby
> > library
> >librobottestingframework-lua2 - Robot Testing Framework - RTF_lua library
> >librobottestingframework-dll2 - Robot Testing Framework - RTF_dll library
> >librobottestingframework2 - Robot Testing Framework - RTF library
> >librobottestingframework-dev - Robot Testing Framework - development
> > files
> >
> > To access further information about this package, please visit the
> > following URL:
> >
> >https://mentors.debian.net/package/robot-testing-framework/
> >
> > Alternatively, one can download the package with dget using this command:
> >
> >dget -x
> > https://mentors.debian.net/debian/pool/main/r/robot-testing-framework/robot-testing-framework_2.0.1-1.dsc
> >
> > Changes for the initial release:
> >
> >   robot-testing-framework (2.0.1-1) unstable; urgency=medium
> >   .
> > * Initial release. (Closes: #969037)
> >
> > Regards,
> >   Daniele
> >
>

Re: HELP needed for uploading a new debianisation 7.1-3 of the Rheolef package

[Anton Gladky]

Hi Pierre,

sure, I will! Please push your changes in master-branch. It looks
only the tags were pushed.

Regards

Anton

Am Sa., 2. Jan. 2021 um 19:41 Uhr schrieb Pierre Saramito
:
>
> Hi Anton, hi all,
>
> I just commit with git a new release 7.1-3 of the debianisation
> of the rheolef package: it fixes bug #978088 (see d/changelog)
> thanks to a patch by Vagrant Cascadian 
>
> The upstream version is unchanged (7.1).
>
> Could you please upload it in debian ?
>
> Many thanks for your help.
>
> Best regards,
>
> Pierre
> --
> pierre.saram...@imag.fr
> Directeur de Recherche CNRS
> Laboratoire Jean Kuntzmann, Grenoble, France
> http://ljk.imag.fr/membres/Pierre.Saramito

Re: RFS: macaulay2 1.16.99 (experimental)

[Anton Gladky]

Hi Doug,

I have uploaded the package into experimental.

However CI-pipelines are failing for the package [1].
Could you please have a look, whether the package really fails
to build or it is a CI-issue?

[1] https://salsa.debian.org/science-team/macaulay2/-/pipelines/211610

Regards



Anton

Am Di., 15. Dez. 2020 um 13:31 Uhr schrieb Torrance, Douglas
:
>
> The Macaulay2 developers just announced a new beta release (1.16.99).
> I've packaged it, targeting "experimental", in the "debian/experimental"
> branch at:
>
> https://salsa.debian.org/science-team/macaulay2
>
> The previous upload of version 1.16 earlier this year failed to build on
> every architecture except for amd64 (!).  I believe we've fixed the main
> underlying issue (there was a segfault on architectures that default to
> unsigned char due to how the compiler was optimizing the string hashing
> function), but I'd like to see if it builds on all of the official
> architectures so we can iron any additional issues before the main 1.17
> release in a few weeks.  Ideally, we can get that into bullseye before
> the freeze.
>
> Would anyone be able to review and sponsor?
>
> Thanks!
> Doug
>
>

Re: Veusz updated to 3.3.1: please review and upload

[Anton Gladky]

Uploaded! Thanks for contribution!

Regards

Anton

Am Mi., 16. Dez. 2020 um 17:37 Uhr schrieb Jeremy Sanders
:
>
> Dear all
>
> Would it be possible to review and upload the update to veusz (3.3.1)
> from the repository? Not much has changed since the last update except
> for the upstream changes:
>
> veusz (3.3.1-1) unstable; urgency=low
>
>* Update to Veusz 3.3.1
>* Bump Standards-Version to 4.5.1
>* Include upstream GPG signing key
>* Drop upstreamed sip5 compatibility patches
>* Increase debhelper-compat level to 13
>
> I think it's in reasonable shape. It all builds fine using pbuilder for
> sid for me and in Salsa's CI:
>
> https://salsa.debian.org/science-team/veusz/-/pipelines
>
> Thanks again for your time and help
>
> Jeremy
>

Re: Veusz updated to 3.3.1: please review and upload

[Anton Gladky]

Hi,

please push pristine-tar branch for .3.3.1. Thanks



Anton

Am Mi., 16. Dez. 2020 um 17:37 Uhr schrieb Jeremy Sanders
:
>
> Dear all
>
> Would it be possible to review and upload the update to veusz (3.3.1)
> from the repository? Not much has changed since the last update except
> for the upstream changes:
>
> veusz (3.3.1-1) unstable; urgency=low
>
>* Update to Veusz 3.3.1
>* Bump Standards-Version to 4.5.1
>* Include upstream GPG signing key
>* Drop upstreamed sip5 compatibility patches
>* Increase debhelper-compat level to 13
>
> I think it's in reasonable shape. It all builds fine using pbuilder for
> sid for me and in Salsa's CI:
>
> https://salsa.debian.org/science-team/veusz/-/pipelines
>
> Thanks again for your time and help
>
> Jeremy
>

Re: HELP needed for uploading a new debianisation of the Rheolef package

[Anton Gladky]

Hi,

I will take care of it.

Regards

Anton

Am Mi., 16. Dez. 2020 um 21:57 Uhr schrieb Pierre Saramito
:
>
> Hi all,
>
> This is a kind reminder.
> I just commit with git a new release 7.1-2 of the debianisation of the 
> rheolef package.
>
> It fixes a FTBFS bug #971933 (see d/changelog):
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971933
>
> The upstream version is unchanged (7.1).
>
> Could you please upload it in debian ?
>
> Many thanks for your help.
>
> Best regards,
>
> Pierre
> --
> pierre.saram...@imag.fr
> Directeur de Recherche CNRS
> Laboratoire Jean Kuntzmann, Grenoble, France
> http://ljk.imag.fr/membres/Pierre.Saramito

Re: thank you for VTK9 and paraview

[Anton Gladky]

Hi,

Ben, Matthieu thanks for your advices! It seems we have managed to
compile vtk9 builds for most of platforms [1] (thanks to Adrian for that!).

For GLES-compilation 4 patches were backported [2]-[5]. And for
armel, armhf and mips issues this commit [6] did a trick.

If you plan to release the next minor vtk9 version with those fixes inside,
it would be reasonable for us to upload this version, dropping patches.

Thanks again for assistance!

[1] https://buildd.debian.org/status/package.php?p=vtk9
[2] 
https://salsa.debian.org/science-team/vtk9/-/blob/master/debian/patches/80_allow_gles_platforms.patch
[3] 
https://salsa.debian.org/science-team/vtk9/-/blob/master/debian/patches/81_allow_gles_platforms.patch
[4] 
https://salsa.debian.org/science-team/vtk9/-/blob/master/debian/patches/82_allow_gles_platforms.patch
[5] 
https://salsa.debian.org/science-team/vtk9/-/blob/master/debian/patches/83_allow_gles_platforms.patch
[6] 
https://salsa.debian.org/science-team/vtk9/-/commit/381ea980c87793d04005908d2ac08609ded68982

Best regards

Anton

Am Mo., 7. Dez. 2020 um 16:18 Uhr schrieb Ben Boeckel :
>
> On Mon, Dec 07, 2020 at 10:42:33 +0100, Mathieu Westphal wrote:
> > I've included Ben in the discussion, he may be of more help.
> > @Ben Boeckel  : These fine folks from Debian are
> > having some issues with VTK on specific architectures.
>
> Thanks!
>
> > That being said, we are not specifically testing nor supporting these
> > architectures, so fixes may be necessary.
> > A more public discussion about it, either on our gitlab [1] or on our
> > discourse [2] may be needed.
>
> I'll echo that. Could you please file issues? I suspect other distros
> will be hitting these problems too and I'd like to get their input on
> any problems as well.

Re: MeshLab update ready to review/sponsor

[Anton Gladky]

Hi Ryan,

I have uploaded the package. Please try to add some autopkgtest for the
future uploads.

Thanks for contribution!

Anton

On 12/2/20 12:24 AM, Ryan Pavlik wrote:
> Hello Debian scientists!
> 
> I have completed the update of the MeshLab package to 2020.09, which was
> the latest upstream release before this morning. It is presently in
> Salsa, ready for review and sponsorship:
> 
> https://salsa.debian.org/science-team/meshlab
> 
> As is common with this project, upstream shuffled/added some bundled
> deps, so the files-excluded list got updated as did the rest of the
> copyright file, which was the bulk of the work. On the plus side, the
> file now mostly is the same as the output of `cme update
> dpkg-copyright`, which should reduce maintenance burden.
> 
> I don't have time this week to look at 2020.12, released today, but it
> does make our Files-Excluded work much harder through some build system
> modification/re-org. I've opened some discussions with upstream about
> these changes, and hopefully they'll revise them so we can have an
> easier-to-package 2021.01, and maybe just skip 2020.12 entirely.
> 
> This will fix https://bugs.debian.org/975157 - the lone bug, a FTBFS and
> thus serious.
> 
> I'd also like to acknowledge the help of Anton Gladky in getting the
> previous 2020.06 release out.
> 
> Thanks for your reviews and sponsorship!
> 
> Ryan Pavlik
> 
> (Apologies for my previous unreadable encrypted email: looks like I
> accidentally encrypted the email to myself instead of signing it. I have
> reverted my Thunderbird settings.)
> 



OpenPGP_signature
Description: OpenPGP digital signature

Re: thank you for VTK9 and paraview

[Anton Gladky]

I also have problems with vtk9 on armel, armhf and mipsel [1].
On armel and mipsel it fails with:

==
/usr/bin/ld: ../../lib/arm-linux-gnueabi/libvtkCommonDataModel-9.0.so.9.0.1:
undefined reference to `__atomic_fetch_add_8'
collect2: error: ld returned 1 exit status
==

and on armhf:

==
/<>/GUISupport/Qt/QVTKOpenGLNativeWidget.cxx:240:5:
error: ‘QOpenGLFunctions_3_2_Core’ was not declared in this scope; did
you mean ‘QOpenGLFunctionsPrivate’?
==

Adding "-latomic" in the first case did not resolve the problem.
armhf-failure was not investigate deeply.

@Mathieu, could you please help us from the upstream side to analyze
those issues with VTK/Paraview?
We are approaching a new stable release soon, it would not be good to
drop VTK and Paraview on
some architectures.

[1] https://buildd.debian.org/status/package.php?p=vtk9

Best  regards

Anton

Am Fr., 4. Dez. 2020 um 13:04 Uhr schrieb Alastair McKinstry
:
>
> Hi
>
> The latest Paraview breaks on 32 bit architectures. Its breaking both on 
> 32/64 bit code issues
> (multiple definitions of int/long prototypes in templates) and memory 
> exhaustion in compilation.
>
> Is there much merit in building Paraview for 32-bit platforms or should they 
> be dropped?
>
> Alastair
>
> On 30/11/2020, 02:05, "Drew Parsons"  wrote:
>
> Hi Anton and Alastair, just a big thank you for getting VTK-9 and
> paraview updated and packaged.  They've been hard to manage so it's a
> good work you've done.
>
> Drew
>
>

Re: RFS: gfan

[Anton Gladky]

No problem, please fix it and let me know.

Regards

Anton

On 12/3/20 10:24 PM, Torrance, Douglas wrote:
> Thanks, Anton!
> 
> Some of the builds are failing after one of my changes, so I'll likely
> be making another sponsorship request again soon.  :)
> 
> Doug
> 



OpenPGP_signature
Description: OpenPGP digital signature

Re: RFS: gfan

[Anton Gladky]

OK, uploaded!

Thanks for contribution!

Best regards

Anton

On 11/22/20 4:57 AM, Torrance, Douglas wrote:
> Hello!
> 
> Would anyone be able to review and sponsor a new upload of gfan?  Among
> other things, it fixes a failing autopkgtest on 32-bit architectures [1].
> https://salsa.debian.org/science-team/gfan
> 
> Thanks!
> Doug
> 
> [1] https://bugs.debian.org/974558

Re: RFS: saclib and mpsolve

[Anton Gladky]

Uploaded!

Best regards

Anton

Am Di., 27. Okt. 2020 um 11:06 Uhr schrieb Torrance, Douglas
:
>
> Hi everyone,
>
> I worked on two math packages, saclib and mpsolve, that recently have
> gone through the NEW queue and have been accepted into unstable.
>
> Both of them need source-only uploads to migrate to testing. I've
> prepared new versions of each package in git to accomplish this.  Would
> anyone be able to sponsor?
>
> https://salsa.debian.org/science-team/saclib
> https://salsa.debian.org/science-team/mpsolve
>
> Thanks!
> Doug

Re: RFS: siconos 4.3.0+dfsg-1

[Anton Gladky]

Uploaded. Thanks for your contribution!

Anton

Am Sa., 26. Sept. 2020 um 18:11 Uhr schrieb Stephen Sinclair

:
>
> Hi Anton,
>
> Sorry to nudge, but have you had a chance to look at the package?
> I just did a rebuild after upgrading my unstable schroot today and it
> still seems to build and passes autopkgtest, so I feel confident.
>
> kind regards,
> Steve
>
>
> On Wed, Sep 9, 2020 at 12:33 PM Stephen Sinclair  wrote:
> >
> > Thank you Anton, much appreciated.  Open to any comments.
> >
> > kind regards,
> > Steve
> >
> > On Tue, Sep 8, 2020 at 8:20 PM Anton Gladky  wrote:
> > >
> > > Hello,
> > >
> > > I will take care of it.
> > >
> > >
> > > Anton
> > >
> > >
> > > Am Di., 8. Sept. 2020 um 08:55 Uhr schrieb Stephen Sinclair 
> > > :
> > >>
> > >> Dear Debian Science members,
> > >>
> > >> I am looking for a sponsor for this update to the Siconos package.  I
> > >> was unfortunately unable to find a sponsor (on mentors) when I made
> > >> the initial update for the 4.3.0 upstream release, but after finding
> > >> and fixing some recent problems due to updates in dependencies in
> > >> unstable, I have now uploaded an updated version-1 package to mentors,
> > >> and I try again directly here.
> > >>
> > >> This update is for a new upstream release, but also fixes bugs filed
> > >> against siconos for gcc-10 and boost.
> > >>
> > >> The package may be found on salsa here:
> > >> https://salsa.debian.org/science-team/siconos
> > >>
> > >> And on mentors here, where the full changelog can be seen:
> > >> https://mentors.debian.net/package/siconos/
> > >>
> > >> Here follows the RFS template:
> > >>
> > >>  * Package name: siconos
> > >>Version : 4.3.0+dfsg-1
> > >>Upstream Author : siconos-t...@lists.gforge.inria.fr
> > >>  * URL :
> > >> https://nonsmooth.gricad-pages.univ-grenoble-alpes.fr/siconos/index.html
> > >>  * License : Expat, ODEPACK-Public-Domain, expm, LGPL-2.1+,
> > >> BSD-3-clause, BOOST-1.0, Apache-2.0
> > >>  * Vcs : https://salsa.debian.org/science-team/siconos
> > >>Section : science
> > >>
> > >> It builds those binary packages:
> > >>
> > >>   python3-siconos - modeling and simulation of nonsmooth dynamical
> > >> systems (python3)
> > >>   libsiconos-io-dev - modeling and simulation of nonsmooth dynamical
> > >> systems (io dev)
> > >>   libsiconos-io6 - modeling and simulation of nonsmooth dynamical
> > >> systems (io lib)
> > >>   libsiconos-mechanics-dev - modeling and simulation of nonsmooth
> > >> dynamical systems (mechanics dev)
> > >>   libsiconos-mechanics6 - modeling and simulation of nonsmooth
> > >> dynamical systems (mechanics lib)
> > >>   libsiconos-control-dev - modeling and simulation of nonsmooth
> > >> dynamical systems (control dev)
> > >>   libsiconos-control6 - modeling and simulation of nonsmooth dynamical
> > >> systems (control lib)
> > >>   libsiconos-kernel-dev - modeling and simulation of nonsmooth
> > >> dynamical systems (kernel dev)
> > >>   libsiconos-kernel6 - modeling and simulation of nonsmooth dynamical
> > >> systems (kernel lib)
> > >>   libsiconos-numerics-dev - modeling and simulation of nonsmooth
> > >> dynamical systems (numerics dev)
> > >>   libsiconos-numerics6 - modeling and simulation of nonsmooth
> > >> dynamical systems (numerics lib)
> > >>   siconos-mechanics-tools - modeling and simulation of nonsmooth
> > >> dynamical systems (mechanics tools)
> > >>   siconos - modeling and simulation of nonsmooth dynamical systems
> > >> (simulation runner tool)
> > >>
> > >> To access further information about this package, please visit the
> > >> following URL:
> > >>
> > >>   https://mentors.debian.net/package/siconos/
> > >>
> > >> Alternatively, one can download the package with dget using this command:
> > >>
> > >>   dget -x 
> > >> https://mentors.debian.net/debian/pool/main/s/siconos/siconos_4.3.0+dfsg-1.dsc
> > >>
> > >>
> > >> Changes since the last 

Re: RFS: siconos 4.3.0+dfsg-1

[Anton Gladky]

Hello,

I will take care of it.


Anton


Am Di., 8. Sept. 2020 um 08:55 Uhr schrieb Stephen Sinclair <
radars...@gmail.com>:

> Dear Debian Science members,
>
> I am looking for a sponsor for this update to the Siconos package.  I
> was unfortunately unable to find a sponsor (on mentors) when I made
> the initial update for the 4.3.0 upstream release, but after finding
> and fixing some recent problems due to updates in dependencies in
> unstable, I have now uploaded an updated version-1 package to mentors,
> and I try again directly here.
>
> This update is for a new upstream release, but also fixes bugs filed
> against siconos for gcc-10 and boost.
>
> The package may be found on salsa here:
> https://salsa.debian.org/science-team/siconos
>
> And on mentors here, where the full changelog can be seen:
> https://mentors.debian.net/package/siconos/
>
> Here follows the RFS template:
>
>  * Package name: siconos
>Version : 4.3.0+dfsg-1
>Upstream Author : siconos-t...@lists.gforge.inria.fr
>  * URL :
> https://nonsmooth.gricad-pages.univ-grenoble-alpes.fr/siconos/index.html
>  * License : Expat, ODEPACK-Public-Domain, expm, LGPL-2.1+,
> BSD-3-clause, BOOST-1.0, Apache-2.0
>  * Vcs : https://salsa.debian.org/science-team/siconos
>Section : science
>
> It builds those binary packages:
>
>   python3-siconos - modeling and simulation of nonsmooth dynamical
> systems (python3)
>   libsiconos-io-dev - modeling and simulation of nonsmooth dynamical
> systems (io dev)
>   libsiconos-io6 - modeling and simulation of nonsmooth dynamical
> systems (io lib)
>   libsiconos-mechanics-dev - modeling and simulation of nonsmooth
> dynamical systems (mechanics dev)
>   libsiconos-mechanics6 - modeling and simulation of nonsmooth
> dynamical systems (mechanics lib)
>   libsiconos-control-dev - modeling and simulation of nonsmooth
> dynamical systems (control dev)
>   libsiconos-control6 - modeling and simulation of nonsmooth dynamical
> systems (control lib)
>   libsiconos-kernel-dev - modeling and simulation of nonsmooth
> dynamical systems (kernel dev)
>   libsiconos-kernel6 - modeling and simulation of nonsmooth dynamical
> systems (kernel lib)
>   libsiconos-numerics-dev - modeling and simulation of nonsmooth
> dynamical systems (numerics dev)
>   libsiconos-numerics6 - modeling and simulation of nonsmooth
> dynamical systems (numerics lib)
>   siconos-mechanics-tools - modeling and simulation of nonsmooth
> dynamical systems (mechanics tools)
>   siconos - modeling and simulation of nonsmooth dynamical systems
> (simulation runner tool)
>
> To access further information about this package, please visit the
> following URL:
>
>   https://mentors.debian.net/package/siconos/
>
> Alternatively, one can download the package with dget using this command:
>
>   dget -x
> https://mentors.debian.net/debian/pool/main/s/siconos/siconos_4.3.0+dfsg-1.dsc
>
>
> Changes since the last upload:
>
>  siconos (4.3.0+dfsg-1) unstable; urgency=medium
>  .
>* New upstream version. (Closes: #962219) (Closes: #961735)
>* Add dependencies libboost-timer-dev, libboost-chrono-dev.
>* Depend on openblas and lapacke instead of atlas.
>* Require fclib 3.1.0
>* Update location of install paths.
>* Enable WITH_GENERATION, now required for serialization.
>* Install new siconos_export_raw_data tool.
>* Fix cmake import targets to allow independent packages.
>* Update patches for new upstream version.
>* Add a flag for gfortran to avoid a regression in GCC-10.
>  (Closes: #957794)
>* Remove unused build rule for swig3.0 symlink.
>* Remove non-existent files from debian/copyright.
>* Rewrite patch descriptions using gbp pq.
>* Fix a Python warning about using 'is' with a literal.
>* Patch for setup.py to import Command from distutils.core.
>* Patch to fix broken lapacke linkage.
>* Remove empty override_dh_auto_clean.
>* Patch to update use of node factory in breathe.
>
> kind regards,
> Steve
>
>

Re: Introduction to causal dynamics

[Anton Gladky]

 I have just added you into the Debian Science Group on salsa.

Usually salsa is used to maintain the packaging stuff, but the upstream is
hosted mostly
on github/gitlab and similar.

Best regards

Anton


Am Mi., 2. Sept. 2020 um 10:20 Uhr schrieb Ralph Alexander Bariz <
ralph.ba...@pm.me>:

> Hi Anton,
>
> Since I'm using Debian(in truth Parrot OS, a Debian Testing based
> derivative) its just natural, that I want to take care to get it into
> Debian repositories. Also I want to get it away from my quite insecure own
> gitlab instance, having it on Debian Salsa Git would be perfect. Also I'd
> like to pass ownership, or at least get some push from somewhere else
> making it impossible to (get forced to) re-license it. Who knows where
> home-office rules of theese times lead to, just want to be sure it stays
> AGPL. Also for sure I'd like to join the team.
>
> BR Ralph
>
>
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, September 1, 2020 9:35 PM, Anton Gladky 
> wrote:
>
> Hi Ralph,
>
> thanks for the introduction. Could you please shortly formulate how the
> Debian Science Team can be useful for you?
>
> Best regards
>
>
> Anton
>
>
> Am So., 30. Aug. 2020 um 14:13 Uhr schrieb Ralph Alexander Bariz <
> ralph.ba...@pm.me>:
>
>> Hi all,
>>
>> My name is Ralph Alexander Bariz. I've written a, I think quite usable,
>> proof of concept for a runtime which should introduce a new kind of
>> algorithmic dedicated to the graph oriented modeling and execution of
>> complex non-linear systems.
>> Please see
>> https://gitlab.ralph.or.at/causal-rt/wiki/-/blob/ralph/debconf/debconf.odp
>> Please see the C++ POC Implementation
>> https://gitlab.ralph.or.at/causal-rt/causal-cpp
>> I request to move over the whole project group to salsa
>> https://gitlab.ralph.or.at/causal-rt
>> My salsa username is "udet".
>>
>> Below I've written, for people interested in the why and probably a way
>> to some kind of new discrete and, error-resistant discretely, executable
>> physics, the thesis. I would also like this post to be seen as an official
>> pre-publication of this thesis.
>>
>> Thanks.
>>
>> *Preface*:
>> I'm system analytics and architect, no mathematician. So this wont
>> contain a lot of numerical math what probably also is not necessary but
>> instead the results of a structural analysis of what Germans call
>> "Wirklichkeit".
>>
>> While this journey begun with working out a methodology to model and
>> execute symmetric interaction simulations on GPU's utilizing definite
>> integrals I was not convinced it could allow to model and execute the aimed
>> complex systems observed to be real.
>> It continued passing by actor model systems which were more what I seek
>> for but still very data oriented while lacking for a definition of "the
>> how".
>>
>> At that time I came into contact with Werner Heisenberg's and Hans-Peter
>> Dürr's "last assumption" defining a virtual entity they called "Wirks".
>> This, for me, was the key to understand what we seem to have missed all the
>> time. Here a discrepancy between the German and the English language got
>> very obvious. While a certain understanding of "the how" seems to be deeply
>> integrated into German language, the English language seems to completely
>> lack it. This discrepancy gets most obvious when thinking about the classic
>> definition of causality in both languages. While the English language
>> defines causality as the implication cause -> effect, while cause and
>> effect are both about the "what", the German definition is "Ursache"(cause)
>> -> "Wirkung" while "Wirkung" is not about the "what" but about the "how".
>> Also one might note, the English "reality" covers the German "Realität" but
>> not the German "Wirklichkeit" while the reality is about the set of all
>> being and the "Wirklichkeit" is the set of all happening.
>> When trying to model this thought of a "Wirks" there came up a few
>> implications which made such a model very attractive not only in context of
>> Max Planck's assumption of a discrete energy and spacetime but also seems
>> to connect the strings in context of thermodynamics and the simple
>> question, why there is entropy but also allows to neatly and exactly define
>> a model of time and why density(mass and extent) of a system influences the
>> flow of time within this system in relation to another system of anoth

Re: Introduction to causal dynamics

[Anton Gladky]

Hi Ralph,

thanks for the introduction. Could you please shortly formulate how the
Debian Science Team can be useful for you?

Best regards


Anton


Am So., 30. Aug. 2020 um 14:13 Uhr schrieb Ralph Alexander Bariz <
ralph.ba...@pm.me>:

> Hi all,
>
> My name is Ralph Alexander Bariz. I've written a, I think quite usable,
> proof of concept for a runtime which should introduce a new kind of
> algorithmic dedicated to the graph oriented modeling and execution of
> complex non-linear systems.
> Please see
> https://gitlab.ralph.or.at/causal-rt/wiki/-/blob/ralph/debconf/debconf.odp
> Please see the C++ POC Implementation
> https://gitlab.ralph.or.at/causal-rt/causal-cpp
> I request to move over the whole project group to salsa
> https://gitlab.ralph.or.at/causal-rt
> My salsa username is "udet".
>
> Below I've written, for people interested in the why and probably a way to
> some kind of new discrete and, error-resistant discretely, executable
> physics, the thesis. I would also like this post to be seen as an official
> pre-publication of this thesis.
>
> Thanks.
>
> *Preface*:
> I'm system analytics and architect, no mathematician. So this wont contain
> a lot of numerical math what probably also is not necessary but instead the
> results of a structural analysis of what Germans call "Wirklichkeit".
>
> While this journey begun with working out a methodology to model and
> execute symmetric interaction simulations on GPU's utilizing definite
> integrals I was not convinced it could allow to model and execute the aimed
> complex systems observed to be real.
> It continued passing by actor model systems which were more what I seek
> for but still very data oriented while lacking for a definition of "the
> how".
>
> At that time I came into contact with Werner Heisenberg's and Hans-Peter
> Dürr's "last assumption" defining a virtual entity they called "Wirks".
> This, for me, was the key to understand what we seem to have missed all the
> time. Here a discrepancy between the German and the English language got
> very obvious. While a certain understanding of "the how" seems to be deeply
> integrated into German language, the English language seems to completely
> lack it. This discrepancy gets most obvious when thinking about the classic
> definition of causality in both languages. While the English language
> defines causality as the implication cause -> effect, while cause and
> effect are both about the "what", the German definition is "Ursache"(cause)
> -> "Wirkung" while "Wirkung" is not about the "what" but about the "how".
> Also one might note, the English "reality" covers the German "Realität" but
> not the German "Wirklichkeit" while the reality is about the set of all
> being and the "Wirklichkeit" is the set of all happening.
> When trying to model this thought of a "Wirks" there came up a few
> implications which made such a model very attractive not only in context of
> Max Planck's assumption of a discrete energy and spacetime but also seems
> to connect the strings in context of thermodynamics and the simple
> question, why there is entropy but also allows to neatly and exactly define
> a model of time and why density(mass and extent) of a system influences the
> flow of time within this system in relation to another system of another
> density. Also it seems, that such a model allows to understand certain
> effects observed in quantum-mechanics and why space is not a that certain
> thing as we use to treat it as. Causal dynamics has implications to the
> concept of "calculus" and neatly defines the symmetric corner-cases where
> it is useful but clearly points out why in "real" asymmetric/complex and
> not dominated(like domination of suns mass where error can but cut as
> negligible) cases it cannot be applied.
>
> In the following lines I will not handle the concrete "proof of concept"
> implementation for classic computing I have done but use one of its
> example's to support some of previously broached claims. Still it has to be
> clear, this POC implementation is NOT complete neither correct. Also please
> mind, here I define causal dynamics as the thesis observed and deduced but
> not as the thesis making philosophical sense. There is an extended thesis
> assuming that all systems are continuous in their nature and its aspects
> are discretising on interaction but since there, for me, is no hint
> available yet, that this could be the case, but even seemingly one that
> this might not be the case(entropy) I will not touch this thought at this
> point.
>
> *Definitions*:
>
>- A "Processor" is an environment allowing the execution of a causal
>systems
>- An "Aspect" is a piece of Information in context of a system
>- A "Wirks" is the necessity of information to change
>- A "Tick" is a pattern allowing a processor to process a certain
>"Wirks" within a causal system
>- A "Wirkung" is a branch of "Wirks" implying each other
>- A "Wirklichkeit" is an integral 

Re: [COVID-19 Hackathon] Bazel build system pending NEW

[Anton Gladky]

Hi,

> eigen: sometimes TF relies on new features that debian's libeigen3-dev
>does not provide. In that case we have to use an embedded
>tarball again.

The new 3.3.8 release seems to be scheduled on 7th of september [1].
If it has features that you need, please just wait a couple of days and it
will be
uploaded into the archive.

[1]
https://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2020/08/msg1.html

Best regards

Anton



Am Di., 1. Sept. 2020 um 04:37 Uhr schrieb Mo Zhou :

> Hi Michael,
>
> I went through the list of missing dependencies.
>
>  aws-*: I'm not interested in them. In the past I just (manually)
> filtered out all the code associated with aws functionalities.
> Most of them are possibly not packaged yet.
>
>  abseil-cpp: this is a tricky one. Similar to facebook/folly. It does
>  not guarantee a stable ABI. Once the system-provided abseil
>  breaks the tensorflow, we have to embed one.
>
>  Anyway it's present in our archive: libabsl-dev but I don't
>  know whether tensorflow builds against it.
>
>  re2: already present in archive. I guess there is no reason to embed it.
>
>  boringssl: maybe a simple string replacement s/boring/open/g will just
> work?
>
>  farmhash: in archive, and I'm the uploader. Ping me if it needs to be
> updated.
>
>  eigen: sometimes TF relies on new features that debian's libeigen3-dev
> does not provide. In that case we have to use an embedded
> tarball again.
>
>  highwayhash: in archive, and I'm the uploader.
>
>  fft2d: TF uses merely 1 source file from this project for merely
> one OP/Kernel. Just keep it embedded.
> The last upstream update was ~10 yrs ago (IIRC).
>
> On Mon, Aug 31, 2020 at 05:32:56PM +0200, Michael R. Crusoe wrote:
> > Hey Mo, we have some unpackaged dependencies. Currently TensorFlow can
> be built
> > using code copies, but obviously that isn't a great plan. Here are the
> current
> > code copies:
> https://github.com/meteorcloudy/tensorflow/tree/r2.2-debian/debian
> > /dist
> >
> > If you want to help out you can use the bazel-bootstrap and
> > libcheck-framework-java binary packages from
> https://people.debian.org/~olek/
> > packages/
>
> Great! Thanks for the hint.
>
>

Re: Introduction and joining the debian-science/robotics team

[Anton Gladky]

Hello Daniele,

welcome to the team!

Feel free to create an account on salsa, request an access to the Science
team and you can safely work on your packages there.

When you are ready or have a question, you can always ask in a team. You
will definitely find someone to communicate. Almost all robotics packages
are successfully maintained in the science team.

Please add your packages on salsa and ask for sponsoring, when you think,
they are ready to be reviewed or/and uploaded.

Best regards

Anton


Daniele E. Domenichelli  schrieb am Mi., 26. Aug.
2020, 17:53:

> Hello everyone,
>
> I'm a technician/developer at Istituto Italiano di Tecnologia (IIT)[1],
> and I'm working mostly on YARP (an open source middleware for
> robotics)[2,3] and in general on the on the software developed in the
> "robotology" GitHub organization[4] and running on the iCub[5] and R1[6]
> robots.
>
> I've been around Debian for a very long time, mostly as a user,
> reporting random bugs and in a few cases helping with a couple of
> packages. I'm also the maintainer of nifti2dicom[7] (which I haven't
> really updated in the last few years, since I'm no longer working in the
> neuroimaging field, but it is still working), and the former maintainer
> of gtkdataboxmm[8] which is no longer in Debian repositories.
>
> I was at the debian-science and debian-med BoFs at DebConf (drdanz),
> since I'm interested in packaging and maintaining a few packages from
> the "robotology" github organization (mostly developed here at IIT), and
> perhaps helping with some other robotics-related packages.
>
> I started working on a few of them but the YARP package turned out to be
> a lot more complicated than what I was expecting (I actually opened the
> original ITP in 2012, and I worked upstream little by little on fixing
> the issues that I found while trying to create the package).
> I now have a few working packages on an Ubuntu PPA[9], but I'm a bit
> stuck because I could not find any sponsor, I have lots of questions,
> and I'm still a bit confused by the Debian workflow.
>
> Therefore I was wondering if there is someone that would be available
> to mentor me through the process.
>
> These are the related bugs that I opened so far:
>
> * #682756: ITP: yarp -- middleware for humanoid robots
> * #934757: ITP: ycm-cmake-modules -- Extra CMake Modules for YARP and
>   friends
> * #966342: RFS: ycm-cmake-modules/0.11.3-1 [ITP] -- Extra CMake Modules
>   for YARP and friends
> * #969037: ITP: robot-testing-framework -- Robot Testing Framework
>
>
>
> I'm also looking for someone that would like to make a talk here at IIT
> (unfortunately online, due to the coronavirus, but we can eventually try
> to organize a visit later, when the pandemic is over), about
> Debian Science, Debian in general, and eventually make a
> small tutorial for beginners about how to start packaging.
> We produce a lot of software and libraries, but unfortunately we tend to
> build everything from sources on all our computers, therefore my goal is
> to persuade the people working here that proper packaging could help a
> lot our workflow.
>
>
> By the way, in case you have never heard about them, iCub is an open
> source (both hardware and software) humanoid robotic platform that we
> produce mostly for research and R1 is a recent effort to produce a "low
> cost" humanoid robot (unfortunately for this robot the hardware is not
> open).
> All the computers onboard and of the cluster connected to the robots run
> either Debian or in same cases ubuntu, with a few exceptions for
> computers running some specific software that runs only on windows,
> and researcher laptops that run whatever operating system the researcher
> chooses.
>
>
> Thanks in advance to anyone who will reply and will help me with the
> packaging.
>
>
> Cheers,
>  Daniele
>
>
> [1]https://www.iit.it/
> [2]http://yarp.it/
> [3]https://github.com/robotology/yarp/
> [4]https://github.com/robotology
> [5]https://icub.iit.it/
> [6]https://icub.iit.it/products/r1-robot
> [7]https://tracker.debian.org/pkg/nifti2dicom
> [8]https://tracker.debian.org/pkg/gtkdataboxmm
> [9]https://launchpad.net/~robotology/+archive/ubuntu/test/+packages
>
>

Re: joining the science team to package spaCy & gensim

[Anton Gladky]

Hello Paul!

I have approved your request. Welcome on board! Please contact the team if
you need an assistance or help.

Best regards,

Anton


Paul Wise  schrieb am Do., 27. Aug. 2020, 13:55:

> Hi all,
>
> My employer is interested in having spaCy and gensim in Debian.
>
> https://spacy.io/
> https://radimrehurek.com/gensim/
>
> I noticed that there is a spaCy package in the team's repository
> although it is not yet in Debian and gensim is also a natural language
> processing tool so the team seems like the right place for it too.
>
> https://salsa.debian.org/science-team/spacy
>
> I have used stdeb to create internal packages of spacy, gensim and
> their missing dependencies. The packages all build, some tests fail and
> the packaging needs cleanup and fixes. I would like to import the
> packages into the team and work on completing them. Some of the
> dependencies are probably more suitable for the general Python team or
> possibly the machine learning team, so I'll import those elsewhere.
>
> I've submitted my request to join the salsa project.
>
> [Please CC me in reply, I'm not subscribed to the list]
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>

Re: RFS: python-jdata and python-bjdata - JData/BJData encoders and decoders for python

[Anton Gladky]

Hi,

uploaded yesterday. Now it is waiting for review in NEW queue.

Best regards

Anton


Am Mo., 27. Juli 2020 um 22:15 Uhr schrieb Qianqian Fang :

> On 7/22/20 4:33 PM, Anton Gladky wrote:
>
> > I currently have "Testsuite: autopkgtest-pkg-python" in control and "export
> PYBUILD_TEST_ARGS=test/" in rules, the CI pipeline seems to be ok with
> autopkgtest for pybj
> Ah, OK. I missed it.
>
> Please fix the binary inclusion (do not forget to rename the tarball then).
>
>
> hi Anton
>
> I noticed that although the auto-test did run for the pyjdata package, it
> reported 0 test. I migrated my test unit to use unittest, and now it runs
> properly.
>
> to make this update, I created a new upstream release (v0.3.6), and
> imported it to salsa, see new commits here
>
> https://salsa.debian.org/science-team/pyjdata/-/commits/master
>
> let em know if you see anything else worth fixing.
>
> Qianqian
>
>
>
> Best regards
>
> Anton
>
>
> Am Mi., 22. Juli 2020 um 01:41 Uhr schrieb Qianqian Fang  >:
>
>> On 7/21/20 4:39 PM, Anton Gladky wrote:
>>
>> Hi Qianqian,
>>
>> some general notes to both packages:
>>
>>
>> thanks, see my below updates
>>
>>
>> - Please go through ALL files and put licenses/copyrights into the
>> d/copyright.
>>
>> done
>>
>>
>> - Remove python2-binaries. This python version is not supported any more.
>>
>>
>> done
>>
>>
>> - Remove all binaries from the code (ods-files)
>>
>>
>> forgive me, what are ods-files?
>>
>>
>> - pysdate - empty clean file is not needed
>>
>>
>> removed.
>>
>>
>> - Add DEP-8 autopkgstests
>>
>>
>> can you point me to an example project how this is done?
>>
>> I currently have "Testsuite: autopkgtest-pkg-python" in control and "export
>> PYBUILD_TEST_ARGS=test/" in rules, the CI pipeline seems to be ok with
>> autopkgtest for pybj
>>
>> https://salsa.debian.org/science-team/pybj/-/pipelines/158112
>>
>>
>> for pyjdata, two tests were failed due to the dependency to
>> python3-bjdata (which I believe can be fixed once both packages are
>> uploaded)
>>
>> https://salsa.debian.org/science-team/pyjdata/-/pipelines/158115
>>
>>
>> Please pay attention, I did not compile and test your packages. Please
>> fix all lintian
>> errors and warnings, if they exist.
>>
>>
>> most of those should have been fixed, let me know if you see something
>> that worth fixing.
>>
>> thanks
>>
>>
>> Qianqian
>>
>>
>>
>> Best regards
>>
>> Anton
>>
>>
>> Am Fr., 17. Juli 2020 um 17:34 Uhr schrieb Qianqian Fang <
>> fan...@gmail.com>:
>>
>>> hi Anton
>>>
>>> just to let you know that I've fixed the numpy-abi error for pybj
>>>
>>>
>>> https://salsa.debian.org/science-team/pybj/-/commit/818484c1eb462fa1abd80951132a95dcd048641d
>>>
>>> https://mentors.debian.net/package/pybj
>>>
>>> I also updated pyjdata dependency list:
>>>
>>> https://mentors.debian.net/package/pyjdata
>>>
>>> let me know if you have any additional questions regarding these two
>>> packages.
>>>
>>> Qianqian
>>>
>>> On 7/14/20 6:07 PM, Qianqian Fang wrote:
>>>
>>> On 7/14/20 5:11 PM, Anton Gladky wrote:
>>>
>>> Hi.
>>>
>>> Thanks for your contribution to Debian. I have just some doubts about
>>> usefulness for Debian and possible popularity of those two projects.
>>>
>>>
>>> hi Anton
>>>
>>> thanks for your comment. happy to explain. Changed message title from
>>> "JSON/..." to "JData/BJData encoders and decoders" to avoid further
>>> confusions.
>>>
>>> see my self-introduction in a previous thread
>>>
>>> https://lists.debian.org/debian-science/2020/06/msg6.html
>>>
>>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=fangqq%40gmail.com
>>>
>>> I am working on packaging a number research software produced from my
>>> lab and research projects. I have already submitted 5 octave-related
>>> projects, mentored by Rafael Laboissière (CCed) via the Debian Octave
>>> Group. I intend to maintain these packages in the future (already doing so
>>> for Fedora).
>>>
>>> These two python m

Re: RFS: python-jdata and python-bjdata - JData/BJData encoders and decoders for python

[Anton Gladky]

Up to you.

Qianqian Fang  schrieb am Do., 23. Juli 2020, 17:57:

> On 7/23/20 11:39 AM, Anton Gladky wrote:
>
> Qianqian Fang  schrieb am Do., 23. Juli 2020, 01:17:
>
>> https://github.com/Iotic-Labs/py-ubjson/tree/dev-contrib/test
>>
>> I can make a new release to get rid of this file, is that ok? or I need
>> to do a repack?
>>
> Yes, please.
>
>
> just to clarify - do you mean do a new release? or do a repack to this
> current release?
>
> thanks
>
>
>
>
> Anton
>
>

Re: RFS: python-jdata and python-bjdata - JData/BJData encoders and decoders for python

[Anton Gladky]

Qianqian Fang  schrieb am Do., 23. Juli 2020, 01:17:

> https://github.com/Iotic-Labs/py-ubjson/tree/dev-contrib/test
>
> I can make a new release to get rid of this file, is that ok? or I need to
> do a repack?
>
Yes, please.


Anton

Re: RFS: python-jdata and python-bjdata - JData/BJData encoders and decoders for python

[Anton Gladky]

Hi,

> forgive me, what are ods-files?

https://salsa.debian.org/science-team/pybj/-/blob/master/test/perf_results.ods

> can you point me to an example project how this is done?

> I currently have "Testsuite: autopkgtest-pkg-python" in control and "export
PYBUILD_TEST_ARGS=test/" in rules, the CI pipeline seems to be ok with
autopkgtest for pybj
Ah, OK. I missed it.

Please fix the binary inclusion (do not forget to rename the tarball then).

Best regards

Anton


Am Mi., 22. Juli 2020 um 01:41 Uhr schrieb Qianqian Fang :

> On 7/21/20 4:39 PM, Anton Gladky wrote:
>
> Hi Qianqian,
>
> some general notes to both packages:
>
>
> thanks, see my below updates
>
>
> - Please go through ALL files and put licenses/copyrights into the
> d/copyright.
>
> done
>
>
> - Remove python2-binaries. This python version is not supported any more.
>
>
> done
>
>
> - Remove all binaries from the code (ods-files)
>
>
> forgive me, what are ods-files?
>
>
> - pysdate - empty clean file is not needed
>
>
> removed.
>
>
> - Add DEP-8 autopkgstests
>
>
> can you point me to an example project how this is done?
>
> I currently have "Testsuite: autopkgtest-pkg-python" in control and "export
> PYBUILD_TEST_ARGS=test/" in rules, the CI pipeline seems to be ok with
> autopkgtest for pybj
>
> https://salsa.debian.org/science-team/pybj/-/pipelines/158112
>
>
> for pyjdata, two tests were failed due to the dependency to python3-bjdata
> (which I believe can be fixed once both packages are uploaded)
>
> https://salsa.debian.org/science-team/pyjdata/-/pipelines/158115
>
>
> Please pay attention, I did not compile and test your packages. Please fix
> all lintian
> errors and warnings, if they exist.
>
>
> most of those should have been fixed, let me know if you see something
> that worth fixing.
>
> thanks
>
>
> Qianqian
>
>
>
> Best regards
>
> Anton
>
>
> Am Fr., 17. Juli 2020 um 17:34 Uhr schrieb Qianqian Fang  >:
>
>> hi Anton
>>
>> just to let you know that I've fixed the numpy-abi error for pybj
>>
>>
>> https://salsa.debian.org/science-team/pybj/-/commit/818484c1eb462fa1abd80951132a95dcd048641d
>>
>> https://mentors.debian.net/package/pybj
>>
>> I also updated pyjdata dependency list:
>>
>> https://mentors.debian.net/package/pyjdata
>>
>> let me know if you have any additional questions regarding these two
>> packages.
>>
>> Qianqian
>>
>> On 7/14/20 6:07 PM, Qianqian Fang wrote:
>>
>> On 7/14/20 5:11 PM, Anton Gladky wrote:
>>
>> Hi.
>>
>> Thanks for your contribution to Debian. I have just some doubts about
>> usefulness for Debian and possible popularity of those two projects.
>>
>>
>> hi Anton
>>
>> thanks for your comment. happy to explain. Changed message title from
>> "JSON/..." to "JData/BJData encoders and decoders" to avoid further
>> confusions.
>>
>> see my self-introduction in a previous thread
>>
>> https://lists.debian.org/debian-science/2020/06/msg6.html
>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=fangqq%40gmail.com
>>
>> I am working on packaging a number research software produced from my lab
>> and research projects. I have already submitted 5 octave-related projects,
>> mentored by Rafael Laboissière (CCed) via the Debian Octave Group. I intend
>> to maintain these packages in the future (already doing so for Fedora).
>>
>> These two python modules are part of a bigger project that I initiated
>> last year (http://openjdata.org). They allow python users to read/write
>> JData-annotated data files produced by my MATLAB toolbox JSONLab (
>> https://github.com/fangq/jsonlab , about 46000 downloads on Matlab file
>> exchange and ~1000 clones/week on github). This work is partly funded by my
>> NIH (National Institute of Health) grants and broader dissemination is part
>> of the project goals.
>>
>>
>> Do you know how many people can be interested in these two libraries?
>> It looks like at least one of them duplicates the functionality of the
>> built-in
>> JSON module. Could you please shortly describe the benefits of both
>> of them before we start to evaluate it technically?
>>
>>
>> The *python-bjdata* project was extended from *python-ubjson* - an
>> existing Debian package. Unfortunately, the UBJSON spec (
>> http://ubjson.org), despite being broadly used, is no longer actively
>> maintained. I started a fork earlier this y

Re: RFS: python-jdata and python-bjdata - JData/BJData encoders and decoders for python

[Anton Gladky]

Hi Qianqian,

some general notes to both packages:
- Please go through ALL files and put licenses/copyrights into the
d/copyright.
- Remove python2-binaries. This python version is not supported any more.
- Remove all binaries from the code (ods-files)
- pysdate - empty clean file is not needed
- Add DEP-8 autopkgstests

Please pay attention, I did not compile and test your packages. Please fix
all lintian
errors and warnings, if they exist.

Best regards

Anton


Am Fr., 17. Juli 2020 um 17:34 Uhr schrieb Qianqian Fang :

> hi Anton
>
> just to let you know that I've fixed the numpy-abi error for pybj
>
>
> https://salsa.debian.org/science-team/pybj/-/commit/818484c1eb462fa1abd80951132a95dcd048641d
>
> https://mentors.debian.net/package/pybj
>
> I also updated pyjdata dependency list:
>
> https://mentors.debian.net/package/pyjdata
>
> let me know if you have any additional questions regarding these two
> packages.
>
> Qianqian
>
> On 7/14/20 6:07 PM, Qianqian Fang wrote:
>
> On 7/14/20 5:11 PM, Anton Gladky wrote:
>
> Hi.
>
> Thanks for your contribution to Debian. I have just some doubts about
> usefulness for Debian and possible popularity of those two projects.
>
>
> hi Anton
>
> thanks for your comment. happy to explain. Changed message title from
> "JSON/..." to "JData/BJData encoders and decoders" to avoid further
> confusions.
>
> see my self-introduction in a previous thread
>
> https://lists.debian.org/debian-science/2020/06/msg6.html
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=fangqq%40gmail.com
>
> I am working on packaging a number research software produced from my lab
> and research projects. I have already submitted 5 octave-related projects,
> mentored by Rafael Laboissière (CCed) via the Debian Octave Group. I intend
> to maintain these packages in the future (already doing so for Fedora).
>
> These two python modules are part of a bigger project that I initiated
> last year (http://openjdata.org). They allow python users to read/write
> JData-annotated data files produced by my MATLAB toolbox JSONLab (
> https://github.com/fangq/jsonlab , about 46000 downloads on Matlab file
> exchange and ~1000 clones/week on github). This work is partly funded by my
> NIH (National Institute of Health) grants and broader dissemination is part
> of the project goals.
>
>
> Do you know how many people can be interested in these two libraries?
> It looks like at least one of them duplicates the functionality of the
> built-in
> JSON module. Could you please shortly describe the benefits of both
> of them before we start to evaluate it technically?
>
>
> The *python-bjdata* project was extended from *python-ubjson* - an
> existing Debian package. Unfortunately, the UBJSON spec (http://ubjson.org),
> despite being broadly used, is no longer actively maintained. I started a
> fork earlier this year to continue the development of this specification,
> and python-bjdata is a parser that is compliant to the BJData spec.
>
> The jdata/bjdata framework is not a duplication to JSON - instead, it
> defines a systematic way to encode basic data structures into
> JSON/UBJSON/BJData serializable forms.
>
> The detailed specifications, examples and rationales can be found at
>
> http://openjdata.org/wiki/
>
> in a way, the jdata module is similar to *json-tricks* but aimed at a
> more systematic/standardized way to annotate complex data (such as graphs,
> maps, ND arrays ...) for sharing, exchange and reuse.
>
> https://packages.debian.org/buster/python/python3-json-tricks
>
> the bjdata module is a binary JSON format (similar to UBJSON, and msgpack)
> to store binary and strongly typed hierarchical data. The differences are
> highlighted in this github tracker
>
> https://github.com/ubjson/universal-binary-json/issues/109
>
> Although these two modules were recently developed, we are beginning to
> integrate those in my other tools including *iso2mesh*
> <http://iso2mesh.sf.net/>, *jsonlab* <http://openjdata.org/jsonlab> and
> *mcx* <http://mcx.space/> (~10,000 registered users combined). So
> packaging and maintaining these tools will greatly facilitate the data
> exchange among the user communities.
>
> let me know if I can provide any additional explanations.
>
> thanks
>
> Qianqian
>
>
>
> Best regards
>
>
> Anton
>
>
> Am Di., 14. Juli 2020 um 06:35 Uhr schrieb Qianqian Fang  >:
>
>> Dear Science team,
>>
>> I just submitted two python module packages and wonder if anyone is
>> willing to take a look and sponsor these packages
>>
>> The python-jdata and python-bjdata packages aim to enabl

Re: RFS: python-jdata and python-bjdata - JSON/BJData encoders and decoders for python

[Anton Gladky]

Hi.

Thanks for your contribution to Debian. I have just some doubts about
usefulness for Debian and possible popularity of those two projects.

Do you know how many people can be interested in these two libraries?
It looks like at least one of them duplicates the functionality of the
built-in
JSON module. Could you please shortly describe the benefits of both
of them before we start to evaluate it technically?

Best regards


Anton


Am Di., 14. Juli 2020 um 06:35 Uhr schrieb Qianqian Fang :

> Dear Science team,
>
> I just submitted two python module packages and wonder if anyone is
> willing to take a look and sponsor these packages
>
> The python-jdata and python-bjdata packages aim to enable sharing python
> data with other programming environments (like MATLAB, C/C++) via
> JSON/binary JSON encoded data files (i.e. the JData/Binary JData
> specifications).
>
> The RFS and mentors links can be found in the below two links
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964993
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964994
>
> both packaging files can be found at
>
> https://salsa.debian.org/science-team/pybj
> https://salsa.debian.org/science-team/pyjdata
>
> Also need some input on removing the missing-dependency-on-numpy-abi error.
>
> thanks
>
> Qianqian
>
>

Debian Science BoF, Debconf20

[Anton Gladky]

Dear members of Debian Science Team,

I am going to submit a proposal for a BoF (birds of feather) for a
DebConf20, where Debian Science Team members and other people can meet
and discuss topics, connected to the Debian Science and similar.

If somebody wants to join as a co-author, feel free to drop me an email.
Deadline is 5th of July.

Also I have prepared here a page [1], where everybody can add a topic to
discuss (please do not forget to add your name/nick).

[1] https://pad.systemli.org/p/mvSA33-2dCXhpZz9DChG

Best regards

Anton




signature.asc
Description: OpenPGP digital signature

Re: MeshLab package ready for review and sponsorship

[Anton Gladky]

Hi Ryan,

I have uploaded the package. But it would be good if you have a look
at some small notes:

* I have enable gitlab-ci on this repo. And it looks like CXXFLAGS are ignored
  by the build system [1]. Please try to find the reason for this and
enable vlhc
  test again [2].

* Please consider adding autopkgstest, if it is possible for this package.

[1] https://salsa.debian.org/science-team/meshlab/-/jobs/827736
[2] 
https://salsa.debian.org/science-team/meshlab/-/commit/c6307efbc883d58680474f4216d4244ce7f22627

Best regards and thanks for contribution!

Anton

Am Mo., 22. Juni 2020 um 21:50 Uhr schrieb Ryan Pavlik :
>
> Hello all!
>
> I've finished up the most recent MeshLab release (2020.06) and it's now
> on Mentors ready to upload.
>
> https://mentors.debian.net/package/meshlab
>
> It's also on salsa: https://salsa.debian.org/science-team/meshlab
>
> Thank you!
>
> Ryan Pavlik
>
>

Re: RFS: keras/2.3.1+dfsg-2 [RC] -- deep learning framework running on Theano or TensorFlow

[Anton Gladky]

Hi Stephen,

I will take a look within the next few days. After meshlab.

Best regards

Anton

Am Mi., 24. Juni 2020 um 18:48 Uhr schrieb Stephen Sinclair
:
>
> Package: sponsorship-requests
> Severity: important
>
> Dear mentors,
>
> I am looking for a sponsor for my package "keras"
>
>  * Package name: keras
>Version : 2.3.1+dfsg-2
>Upstream Author : François Chollet 
>  * URL : https://keras.io/
>  * License : Expat
>  * Vcs : https://salsa.debian.org/science-team/keras
>Section : science
>
> It builds those binary packages:
>
>   python3-keras - deep learning framework running on Theano or TensorFlow
>
> To access further information about this package, please visit the
> following URL:
>
>   https://mentors.debian.net/package/keras
>
> Alternatively, one can download the package with dget using this command:
>
>   dget -x 
> https://mentors.debian.net/debian/pool/main/k/keras/keras_2.3.1+dfsg-2.dsc
>
> Changes since the last upload:
>
>* debian/patches:
>  + fix test regression for python3-h5py 2.10.0-8.
>(Closes: #963426)
>
> The package will not be updated to Keras release 2.4.0 due to
> end-of-life.  In the future Keras will be included in TensorFlow,
> which is not yet available in Debian; when it is, this package will be
> removed, but until then this package remains the principle way to
> include Keras in Debian.
>
> Please read:
>
> https://github.com/keras-team/keras/releases/tag/2.4.0
>
> This update fixes a small problem with a test due to updates to python3-h5py.
>
> Regards,
>
> --
>   Stephen Sinclair
>

Re: MeshLab package ready for review and sponsorship

[Anton Gladky]

Hi Ryan

I will take a look within the next few days.

Regards

Anton

Ryan Pavlik  schrieb am Mo., 22. Juni 2020, 21:50:

> Hello all!
>
> I've finished up the most recent MeshLab release (2020.06) and it's now
> on Mentors ready to upload.
>
> https://mentors.debian.net/package/meshlab
>
> It's also on salsa: https://salsa.debian.org/science-team/meshlab
>
> Thank you!
>
> Ryan Pavlik
>
>
>

Re: [RFS] python-pweave

[Anton Gladky]

Hi,

uploaded!

Regards

Anton

Am So., 21. Juni 2020 um 19:56 Uhr schrieb Nilesh Patra :
>
> Hi,
> python-pweave has a RC bug: #962104 filed against it. I've fixed this
> My changes are pushed here[1].
> Needs review and sponsorship.
>
> [1]: https://salsa.debian.org/science-team/python-pweave
>
> Thanks and regards
> Nilesh

Re: RFS: topcom

[Anton Gladky]

Any way - uploaded! Thanks for your contribution.


Anton

Am Do., 18. Juni 2020 um 20:01 Uhr schrieb Anton Gladky :
>
> Could you please check, what is wrong with pristine-tar file?
>
> gbp:error: Pristine-tar couldn't verify
> "topcom_0.17.8+ds.orig.tar.xz": pristine-tar:
> ...topcom_0.17.8+ds.orig.tar.xz does not match stored hash (expected
> a8f7f02
>
> Thanks
>
> Anton
>
> Am Do., 18. Juni 2020 um 10:30 Uhr schrieb Doug Torrance
> :
> >
>
> > On Wed, Jun 17, 2020 at 4:53 PM Anton Gladky  wrote:
> > > I will take care of it within the next few days.
> >
> > Wonderful, thank you!
> >

Re: RFS: topcom

[Anton Gladky]

Could you please check, what is wrong with pristine-tar file?

gbp:error: Pristine-tar couldn't verify
"topcom_0.17.8+ds.orig.tar.xz": pristine-tar:
...topcom_0.17.8+ds.orig.tar.xz does not match stored hash (expected
a8f7f02

Thanks

Anton

Am Do., 18. Juni 2020 um 10:30 Uhr schrieb Doug Torrance
:
>

> On Wed, Jun 17, 2020 at 4:53 PM Anton Gladky  wrote:
> > I will take care of it within the next few days.
>
> Wonderful, thank you!
>

Re: RFS: topcom

[Anton Gladky]

Hi Doug,

I will take care of it within the next few days.

Best regards

Anton

Am Di., 16. Juni 2020 um 00:45 Uhr schrieb Doug Torrance
:
>
> Hi everyone,
>
> I've been looking for a sponsor for topcom for a few weeks now.  I've
> asked on the Sponsoring of Blends page and the Sage list, but I don't
> think I've asked on the main Science list yet!
>
> If anyone would be willing to take a look, the git repository is at:
> https://salsa.debian.org/science-team/topcom
>
> It's a dependency for the algebraic geometry/commutative algebra
> software Macaulay2, which I hope to get into Debian after version 1.16
> is released at the end of the month.
>
> Thanks!
> Doug
>

Re: [RFS] Compyle v0.6

[Anton Gladky]

Hi,

uploaded!

Anton

Am Mi., 17. Juni 2020 um 07:35 Uhr schrieb Antonio Valentino
<

antonio.valent...@tiscali.it>:

>
> Hi list,
> I'm looking for a sponsor to upload the new version (v0.6) of compyle [1].
> The source code package is on salsa [2] but I an quickly upload it on
> mentors.d.n if you prefer.
>
>
> [1] https://github.com/pypr/compyle
> [2] https://salsa.debian.org/science-team/compyle
>
>
> kind regards
>
> --
> Antonio Valentino
>

Re: [RFS] setzer/0.2.5-1 [ITP] -- simple yet full-featured LaTeX editor

[Anton Gladky]

Hi Stephan,

thanks for your work on a new package.
I have shortly reviewed it and there are have some very minor notes::

- Please use the git-packaging schema, described in Debian Science Policy
[1].
  Usually we do not pull upstreams commits, but import tarball with
pristine-tar.
[1] https://science-team.pages.debian.net/policy/#idm297

- please double check all files and put all licenses in the d/copyright.
  It is very important!

Please fix the first issue and double-check the second note and I will
upload this package.

Best regards

Anton



Am Di., 28. Apr. 2020 um 13:33 Uhr schrieb Stephan Lachnit <
stephanlach...@protonmail.com>:

> Dear Debian Science Team,
>
> I'm currently looking for a sponsor for Setzer, an amazing LaTeX editor.
> More information on Setzer can be found on my RFS:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958991
>
> I think it fits this team after looking at the DebianScience/Typesetting
> wiki page, that's why I want to maintain it in the Debian Science team, if
> someone here is interested to sponsor it.
>
> Cheers,
> Stephan
>
>

Re: RFS: lasagne update

[Anton Gladky]

Hi Stephen,

I have reviewed this package, made some more minor changes and
uploaded it.

Thanks for contribution!

Anton


Am Do., 30. Apr. 2020 um 17:13 Uhr schrieb Stephen Sinclair <
radars...@gmail.com>:

> Hello science team,
>
> I am looking for a sponsor for the deep learning package lasagne.  The
> package has been updated on salsa and is passing build and test:
>
> https://salsa.debian.org/science-team/lasagne/pipelines/131520
>
> Currently it is blocking numpy migration so I sped up my work on this
> update to close that bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959137
>
> If anyone could take a look please feel free to upload if there are no
> outstanding concerns.
>
> kind regards,
> Steve
>
>

Re: PyZoltan (Was: RE: [RFS] zarr, numcodecs and asctree)

[Anton Gladky]

Hi Antonio,

uploaded!

You are maintaining a relatively large number of packages and
all, which I sponsored, are in the high quality.

I would propose you to think about a getting a DM status
or even applying to become DD.

Best regards

Anton

Am Mi., 22. Apr. 2020 um 17:08 Uhr schrieb

Antonio Valentino

:
>
> Dear Anton,
> thank you again for sponsoring the upload of pyzoltan.
> I would like yo kindly ask you to make a source-only upload to allow the
> migration of the package into testing.
>
>
> kind regards
> antonio
>
> Il 02/03/20 22:16, Anton Gladky ha scritto:
> > Uploaded!
> >
> > Anton
> >
> > Am So., 1. März 2020 um 22:19 Uhr schrieb Anton Gladky :
> >>
> >> Hi Antonio,
> >>
> >> I will take care of it.
> >>
> >> Regards
> >>
> >> Anton
> >>
> >> Am So., 1. März 2020 um 09:04 Uhr schrieb Antonio Valentino
> >> :
> >>>
> >>> Dear Anton,
> >>> the pyzoltan package code has been uploaded into a the salsa repo (some
> >>> time ago actually).
> >>> Are you still willing to sponsor it?
> >>>
> >>>
> >>> kind regatds
> >>> antonio
> >>>
> >
>
> --
> Antonio Valentino
>

Re: RFS: keras, keras-applications, keras-preprocessing

[Anton Gladky]

Hi Steve,

I have uploaded all packages. If they will be broken in the
future and no upstream support available, they just need to
be removed. You have done work, why to loose it at least right
now

Thanks for contribution!

Anton

Am Di., 14. Apr. 2020 um 15:51 Uhr schrieb Stephen Sinclair
:
>
> Hi Anton,
>
> Thanks for checking the package.
>
> On Tue, Apr 14, 2020 at 7:48 AM Anton Gladky  wrote:
> >
> > Hello Stephen,
> >
> > I started from keras yesterday, made some minor changes.
> > But it seems some tests are failing:
> >
> > = 14 failed, 812 passed, 252 skipped, 87
> > warnings in 3054.59 seconds =
> >
> > Please check, whether they can be skipped or the tolerance
> > should be increased.
>
> This is similar to the result I get if I run the tests without
> including the updated keras-preprocessing and keras-applications
> packages in my schroot, so I wonder if that's what happened.
> However, I realized I forgot to *require* these updated packages by
> increasing the versions in debian/control, so now I have done so.
> Now on a fresh schroot without the updates the package fails to build,
> with the updates it builds and passes tests for me.
> I supplied the updated .debs using --extra-package options to sbuild,
> as well as to autopkgtest.
>
> I have pushed a few commits on salsa master.
>
> That said, as of this month keras outside of Tensorflow is now
> end-of-life, so I am not sure if it is worth keeping these packages in
> debian:
>
> https://github.com/keras-team/keras/blob/master/README.md
>
> > Bugs present in multi-backend Keras will only be fixed until April 2020 (as 
> > part of minor releases).
>
> Perhaps a last update while things are still working, but removal on
> breakage?  Or better to just remove it entirely?
> With theano also being end of life things are looking shaky.
>
> regards,
> Steve
>
>
> > Am Sa., 21. März 2020 um 15:40 Uhr schrieb Stephen Sinclair
> > :
> > >
> > > Dear Science team,
> > >
> > > I decided to check up on my packages and found that there are errors
> > > that have cropped up due to recent updates to Python and GCC.  I
> > > noticed that they will be autoremoved from testing soon, so I am
> > > looking for a sponsor to upload some updates.
> > >
> > > In particular keras and siconos, but keras is more urgent as it will
> > > be autoremoved on Monday.  And, I am still working on fixing a problem
> > > with swig4.0 in the siconos package.
> > >
> > > So, the following packages have been updated in salsa repositories:
> > >
> > > science-team/keras
> > > science-team/keras-applications
> > > science-team/keras-preprocessing
> > >
> > > Unfortunately my sponsor is no longer available, so I am looking for a
> > > new sponsor to check and upload these packages.
> > >
> > > Note: the salsa CI fails for keras because it does not use the updated
> > > keras-applications and keras-preprocessing, I am not sure how to make
> > > that work.
> > >
> > > But, it is building and testing successfully on my machine.
> > >
> > > Would someone be willing to sponsor an upload of these packages?
> > >
> > > kind regards,
> > > Steve
> > >

Re: RFS: keras, keras-applications, keras-preprocessing

[Anton Gladky]

Hello Stephen,

I started from keras yesterday, made some minor changes.
But it seems some tests are failing:

= 14 failed, 812 passed, 252 skipped, 87
warnings in 3054.59 seconds =

Please check, whether they can be skipped or the tolerance
should be increased.

Best regards

Anton

Am Sa., 21. März 2020 um 15:40 Uhr schrieb Stephen Sinclair
:
>
> Dear Science team,
>
> I decided to check up on my packages and found that there are errors
> that have cropped up due to recent updates to Python and GCC.  I
> noticed that they will be autoremoved from testing soon, so I am
> looking for a sponsor to upload some updates.
>
> In particular keras and siconos, but keras is more urgent as it will
> be autoremoved on Monday.  And, I am still working on fixing a problem
> with swig4.0 in the siconos package.
>
> So, the following packages have been updated in salsa repositories:
>
> science-team/keras
> science-team/keras-applications
> science-team/keras-preprocessing
>
> Unfortunately my sponsor is no longer available, so I am looking for a
> new sponsor to check and upload these packages.
>
> Note: the salsa CI fails for keras because it does not use the updated
> keras-applications and keras-preprocessing, I am not sure how to make
> that work.
>
> But, it is building and testing successfully on my machine.
>
> Would someone be willing to sponsor an upload of these packages?
>
> kind regards,
> Steve
>

Re: RFS: keras, keras-applications, keras-preprocessing

[Anton Gladky]

Hi Stephen,

I am reviewing packages and preparing uploads.

Best regards

Anton

Am Sa., 21. März 2020 um 15:40 Uhr schrieb Stephen Sinclair
:
>
> Dear Science team,
>
> I decided to check up on my packages and found that there are errors
> that have cropped up due to recent updates to Python and GCC.  I
> noticed that they will be autoremoved from testing soon, so I am
> looking for a sponsor to upload some updates.
>
> In particular keras and siconos, but keras is more urgent as it will
> be autoremoved on Monday.  And, I am still working on fixing a problem
> with swig4.0 in the siconos package.
>
> So, the following packages have been updated in salsa repositories:
>
> science-team/keras
> science-team/keras-applications
> science-team/keras-preprocessing
>
> Unfortunately my sponsor is no longer available, so I am looking for a
> new sponsor to check and upload these packages.
>
> Note: the salsa CI fails for keras because it does not use the updated
> keras-applications and keras-preprocessing, I am not sure how to make
> that work.
>
> But, it is building and testing successfully on my machine.
>
> Would someone be willing to sponsor an upload of these packages?
>
> kind regards,
> Steve
>

Re: HELP needed for uploading a new upstream version of the Rheolef package

[Anton Gladky]

Hi Pierre,

I have sponsored your package.

Please consider the migration to compat-level 12. 10 is outdated.

Best regards

Anton

Am Mo., 23. März 2020 um 18:43 Uhr schrieb Anton Gladky :
>
> I think I sponsored this package some time ago and I will try to have
> a look again.
>
> Anton
>
> Am Mo., 23. März 2020 um 18:33 Uhr schrieb Pierre Saramito
> :
> >
> > Hi Andreas Tille,
> >
> > > From Andreas:
> > > Currently I can only support Covid-19 related
> > > packages (which we try to assemble in Debian Med team currently)
> >
> > Let me known if I could help the Debian Med team ?
> > I remain "confined" at home, but I could help (test pkg, ect) ?
> >
> >
> > > please find some other sponsor from Debian Science project.
> >
> > Is there somebody from the Debian science project
> > to just help me for uploading the Rheolef-7.1-1 pkg ?
> > The debianization is ready and well-tested at
> >https://salsa.debian.org/science-team/rheolef
> > It closes the two FTBFS bugs: #944197 and #946116
> >
> >
> > Best wishes,
> >
> > Pierre
> >
> > --
> > pierre.saram...@imag.fr
> > Directeur de Recherche CNRS
> > Laboratoire Jean Kuntzmann, Grenoble, France
> > http://ljk.imag.fr/membres/Pierre.Saramito
> >

Re: HELP needed for uploading a new upstream version of the Rheolef package

[Anton Gladky]

I think I sponsored this package some time ago and I will try to have
a look again.

Anton

Am Mo., 23. März 2020 um 18:33 Uhr schrieb Pierre Saramito
:
>
> Hi Andreas Tille,
>
> > From Andreas:
> > Currently I can only support Covid-19 related
> > packages (which we try to assemble in Debian Med team currently)
>
> Let me known if I could help the Debian Med team ?
> I remain "confined" at home, but I could help (test pkg, ect) ?
>
>
> > please find some other sponsor from Debian Science project.
>
> Is there somebody from the Debian science project
> to just help me for uploading the Rheolef-7.1-1 pkg ?
> The debianization is ready and well-tested at
>https://salsa.debian.org/science-team/rheolef
> It closes the two FTBFS bugs: #944197 and #946116
>
>
> Best wishes,
>
> Pierre
>
> --
> pierre.saram...@imag.fr
> Directeur de Recherche CNRS
> Laboratoire Jean Kuntzmann, Grenoble, France
> http://ljk.imag.fr/membres/Pierre.Saramito
>

Re: [RFS] Meshlab

[Anton Gladky]

Hi Ryan,

thanks for the contribution! I will have a look at your changes within
the next few days.

Regards


Anton

Am Mo., 16. März 2020 um 17:14 Uhr schrieb Ryan Pavlik :
>
> The current version has some FTBFS, some DFSG issues, as well as an
> issue with installing but not actually running. I've prepared an updated
> version, which has a newer upstream (release instead of snapshot) that
> has been repacked to exclude the DFSG-problematic files, and that is
> also overall fixed up a bit (copyright file more accurate and up to
> date, repeatable generation of "upstream" tarball, patch to fix a plugin
> broken by removal of DFSG-violation, etc.) It is the package whose
> upload would fix all the issues in the BTS marked as pending.
>
> It's ready for review and sponsorship:
>
> https://mentors.debian.net/package/meshlab
> https://salsa.debian.org/rpavlik-guest/meshlab
>
> (I was accepted into the team gitlab group, but out of courtesy I didn't
> push my changes to the team repo yet because they hadn't been reviewed.)
>
> Thanks!
>
> Ryan
>