Re: sponsoring library transitions

[Pierre Gruet]

Hi Jose Luis,

Le 05/03/2024 à 17:47, Jose Luis Rivero a écrit :

Hi again:

On Fri, Feb 9, 2024 at 6:12 PM Pierre Gruet <mailto:p...@debian.org>> wrote:


... dart is currently involved in the 64 bit time_t transition. Have
you
seen that Version 6.12.1+dfsg4-13.1~exp1 has been uploaded to
experimental? It will undergo a library transition so we should wait it
is finished.


I've been following the time64_t transition and I think that all 
packages have landed unstable and some days have passed since that. Is 
it now a good moment to upload the new versions and start the transitions?


Thanks!


THanks for following the situation; I think we have to wait longer, 
packages have been uploaded to unstable but there are some side effects 
and the migration to testing has not happened yet.
For instance, even dart had failed its build on ppc64el, I have just 
triggered a new build, which passed. Let's wait all the packages 
successfully build and are in testing before going on; I can guess the 
release team will appreciate having the time_t transition behind in 
order to process new transitions.


But no worry, we will be able to proceed to all the updates you are 
planning to do!


Best,

--
Pierre


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: sponsoring library transitions

[Pierre Gruet]

Hi Jose Luis,

Le 08/02/2024 à 18:24, Jose Luis Rivero a écrit :

Hi all:

I have a couple of library transitions ready to review and upload and 
would need sponsoring to start the transitioning process:


Thanks for the work on these packages!



  - urdfdom https://salsa.debian.org/science-team/urdfdom 



In my opinion this package is ready to be transitioned. But do you know 
if the current dart can be built against urdfdom/4.0.0-1? because...


  - dart https://salsa.debian.org/science-team/dart 


    (salsa CI is over 3 hours)


... dart is currently involved in the 64 bit time_t transition. Have you 
seen that Version 6.12.1+dfsg4-13.1~exp1 has been uploaded to 
experimental? It will undergo a library transition so we should wait it 
is finished.




Thanks!


To summarize, we have to wait, concerning dart. I suggest we also wait 
before transitioning urdfdom as its transition will also affect dart, 
which is already embarked in a massive transition itself.


Best,

--
Pierre


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: RFS: updated packages libticcutils, libfolia, uctodata, ucto, timbl, timblserver, mbt, mbtserver, frogdata, frog

[Pierre Gruet]

Hi Maarten,

Le 06/02/2024 à 23:30, Maarten van Gompel a écrit :

Hi Pierre,

Thanks for your reply.


You're welcome!



On Tue Feb 6, 2024 at 10:20 PM CET, Pierre Gruet wrote:

I see ticcutils (at least) is affected by the ongoing 64-bit time_t
transition, it has been NMU-ed to experimental.


Yes, it seems this applies to most of the packages. I don't know exactly
why (I don't think we expose time_t in our ABI), but I understand the
transition applies broadly (better safe than sorry).


I am afraid I am not skilled enough to answer :(




Would you mind waiting
for the end of this process (also acknowledging the related uploads and
new binary package names in your packaging at that time) so that we
don't interfere with the transition?


That's okay, though I thought maybe releasing these new packages
might make the transitional packages obsolete and reduce some
complexity.


There is at least one dependency of all these packages that is waiting 
in experimental for its own transition. When it has started, these 
packages can be uploaded to unstable in a somehow organized process. I 
trust it is better to wait in order to be sure we don't interfere with 
anything :)


By the way, I noticed dimbl is a reverse dependency of ticcutils and 
timbl, and it has not been updated for ages. Could you also include it 
in your series of upcoming uploads please?


Please do reach out again after the transition of the packages has 
finished and we will proceed :)




Regards,



Best,

--
Pierre


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: RFS: updated packages libticcutils, libfolia, uctodata, ucto, timbl, timblserver, mbt, mbtserver, frogdata, frog

[Pierre Gruet]

Hi Maarten,

Le 02/02/2024 à 14:47, Maarten van Gompel a écrit :

Hi,

After a hiatus of too many years, I finally updated the debian packages for
our software stack to their latest upstream releases:

* https://salsa.debian.org/science-team/libticcutils
* https://salsa.debian.org/science-team/libfolia
* https://salsa.debian.org/science-team/uctodata
* https://salsa.debian.org/science-team/ucto
* https://salsa.debian.org/science-team/timbl
* https://salsa.debian.org/science-team/timblserver
* https://salsa.debian.org/science-team/mbt
* https://salsa.debian.org/science-team/mbtserver
* https://salsa.debian.org/science-team/frogdata
* https://salsa.debian.org/science-team/frog

The packages should be built in the above order because of intra-dependencies.

As it's been a while, I hope I did everything right. Of course
I verified the packages work, so things look promising.

I did get some minor lintian warnings like:

   W: frog source: superfluous-file-pattern m4/pkg.m4 [debian/copyright:48]

... because of an earlier m4/* pattern. But judging by the documentation
that should be allowed?

One other relevant issue (for Frog) is the time64 transition (
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061954) , which I hope
I handled okay now.

I'm hoping someone is willing to upload these packages? (and add the 
debian/vX.XX git tag)

Kind Regards,



Thanks for all this work!

I see ticcutils (at least) is affected by the ongoing 64-bit time_t 
transition, it has been NMU-ed to experimental. Would you mind waiting 
for the end of this process (also acknowledging the related uploads and 
new binary package names in your packaging at that time) so that we 
don't interfere with the transition?


Best,

--
Pierre


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [RFS] coinutils and coinor-osi

[Pierre Gruet]

Hi Håvard,

Le 19/12/2023 à 09:19, Håvard F. Aasen a écrit :

Hi Pierre,

On 18.12.2023 18:13, Pierre Gruet wrote:

Dear Håvard,

This is a follow-up to your RFS email [0]. I am willing to sponsor your 
packages coinor-data-sample and coinor-data-netlib except that is appears some 
copyright entries are missing, see the output of scan-copyrights for instance.

Are you comfortable with fixing these?


After Julien's initial reply to the RFS [1], I reached out to upstream
asking about the license, it turns out they do not know where the files
originates from, who has the copyright or which license applies [2]. It
seems that the packages can't be included in Debian. Let me know if I'm
wrong in this.



Hmm no, Julien and you are right. I overlooked that in my preliminary 
copyright check.



The files in question is the same files that has been shipped with
coinutils the last 15 years, though, I hoped to replace them with
coinor-data-sample and coinor-data-netlib.


Also you have been doing a great work on coinutils and I would like to upload 
it, is it fine for you? I have tested rdeps with ratt and everything is OK. 
Alternatively I can grant you DM permissions, please tell me.

Either way is fine, but having upload rights would be nice.


Granted, please go ahead when you wish to.



I'm hoping we can continue with the prepared package, and as long as I
haven't misjudged the licensing issues with the extra test files,
remove them with the next upstream release. Going forward, the source
files will be downloaded from GitHub and will not contain the extra test
files.


Sounds reasonable. In the worst scenario, the problematic data files 
won't be shipped by any package and we will cope with this situation.




I hope to prepare the next release relatively fast, I only need to
rebuild the rdeps and see which, if any, packages breaks without the
extra test files.


Also please fetch the current state of the repository, I have acknowledged the 
QA upload by Adrian Bunk.


Will do, thanks for incorporating the changes.

I case you do upload, I just pushed two small changes to the repo.




Ack!


Best,

--
Pierre


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [RFS] coinutils and coinor-osi

[Pierre Gruet]

Dear Håvard,

This is a follow-up to your RFS email [0]. I am willing to sponsor your 
packages coinor-data-sample and coinor-data-netlib except that is 
appears some copyright entries are missing, see the output of 
scan-copyrights for instance.


Are you comfortable with fixing these?

Also you have been doing a great work on coinutils and I would like to 
upload it, is it fine for you? I have tested rdeps with ratt and 
everything is OK. Alternatively I can grant you DM permissions, please 
tell me.
Also please fetch the current state of the repository, I have 
acknowledged the QA upload by Adrian Bunk.


Best regards and thanks for all the work,

--
Pierre


[0] https://lists.debian.org/debian-science/2023/06/msg00012.html


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Using videos in presentations

[Pierre Gruet]

Hello Leopold,

Le 18/09/2023 à 12:35, Leopold Palomo-Avellaneda a écrit :


Hi,

I like to use LaTeX and if I need to make a presentation I use Beamer. 
In the past, if I had to insert a video, I could do it with the 
necessary packages and any Acroread could played it.


It seems that from 2021 it is not possible, although that Okular can 
show it and I'm quite sure that other pdf viewers that are in the 
archive can do it.


I would prefer to not use libreoffice to make a presentation but I have 
not found any useful information to do it in a pdf with the tools that 
we have in Debian.


Do you know how can I insert a video in a presentation using the package 
that we have in Debian?


Putting

\usepackage{movie15}

in the preamble (movie15.sty being provided by texlive-latex-extra), one 
can later include a movie with, for instance,


\begin{frame}
\begin{figure}
		\includemovie[poster, 
controls]{.75\paperwidth}{.75\paperheight}{path/to/video}

\end{figure}
\end{frame}

which is not perfect though, as (with evince, on Debian) it prints some 
funny picture on the slide, then I have to exit full screen during the 
presentation and click the picture to launch the video -- it has been 
far enough for me for many years.
Running the same .pdf with other operating systems could give you a 
better result, amazingly.


Maybe some better rendering can be achieved with the options of 
\includemovie -- see the docs.




Best regards,


Leopold



Best,

--
Pierre


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1027277: ITP: glgrib -- geophysical GRIB2-encoded fields displayer using OpenGL

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Pierre Gruet 
User: debian-science@lists.debian.org
Usertags: field..geography
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-science@lists.debian.org

* Package name: glgrib
  Version : 1.0.0
  Upstream Contact: Philippe Marguinaud
* URL : https://github.com/pmarguinaud/glgrib
* License : GPL-3
  Programming Lang: C++
  Description : geophysical GRIB2-encoded fields displayer using OpenGL

This is an interactive executable, based on GLFW, displaying GRIB2 fields with
OpenGL. It offers a GLFW backend for interactive display or an EGL backend for
batch processing without X11 display. The interface is written in Perl/Tk.

This software is packaged as an useful geographical data visualization tool,
comfortable and eye-appealing. We plan to maintain it under the Debian-science
team umbrella.

Re: New package : glGrib

[Pierre Gruet]

Hello Philippe,

Le 12/12/2022 à 15:29, philippe marguinaud a écrit :

Hello Pierre,

I have managed to create some Debian packages for glgrib. You can grab 
them here :


ftp://86.250.249.136 

l/p = debian/glGrib4Debian%

I have split the installation into 4 packages :

  * bin : binary executable & shared libraries
  * data : data required to run glgrib
  * doc : documentation
  * test : test files

Only bin and data are actually required.

I still have some warnings in the *.build files, but I would need some 
help to get rid of them.


Thanks! I have some questions and remarks, I suggest we move the 
discussion to your issue tracker

https://github.com/pmarguinaud/glgrib/issues/1



Regards,

Philippe


Best regards,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature

Re: Sponsorship needed for SolveSpace

[Pierre Gruet]

Hi Ryan!

Le 07/12/2022 à 23:37, Ryan Pavlik a écrit :

Hello all!

It looks like the previous "fix" for the s390x test failures,
inadvertently excluded other arches as well and thus still didn't
unblock the migration - see https://bugs.debian.org/1025311

I have prepared an updated revision (and pushed it to salsa and
mentors) that fixes this right the way this new bug suggests.

Please review and sponsor so we can get this unblocked.


Thanks for taking care of the package! The changes look good.
While you are it, could you also repair d/watch and at least correct the 
mismatched Lintian overrides?


Then I can sponsor the upload!



Ryan



Best,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature

Re: New package : glGrib

[Pierre Gruet]

Bonjour Philippe,

Le 05/12/2022 à 18:11, philippe marguinaud a écrit :

Hi all,

I would like to propose a new package for Debian; its purpose is to 
display geophysic fields encoded in GRIB format, using OpenGL rendering.


The source code and a demo gallery are available here :

https://github.com/pmarguinaud/glgrib/



I think this is interesting. How does glGrib compare with XyGrib for 
instance? I guess the main difference is the OpenGL rendering?


I have prepared deb archives, and tested their installation in a 
container; it seems to work.


I guess you used makedeb, equivs or something like that do prepare this 
.deb archive?




I would like somebody to help me finalize the deb packages and guide me 
through the steps for acceptance in the Debian distribution.


If you are targeting an inclusion in Debian, you should be able to build 
the .deb from source in the canonical Debian way in order to enforce 
consistency and reproducibility within the Debian archive. To get a 
broad idea of the involved steps, you can see [0] for instance (maybe 
not the most up-to-date resource though).

If you want, you may have a look at this page and tell us what you think.



Regards,

Philippe Marguinaud


Best regards,

--
Pierre


[0] https://wiki.debian.org/Packaging/Intro


OpenPGP_signature
Description: OpenPGP digital signature

Re: MeshLab update, help wanted

[Pierre Gruet]

Hi Ryan,

Le 20/09/2022 à 18:47, Ryan Pavlik a écrit :

Hey all,

I've updated the MeshLab package to their latest release. I have also
updated the copyright file, which was one of the things I didn't get
to last time I poked the package. It's still failing CI, but I think
it's just a missing Lintian override, if I understand right. (It has a
private library it uses internally, so it's installed to a subdir of
the lib directory, per policy. Thus it has an RPATH to find it, so I
think we just have to say "yeah we intentionally have the rpath in
there")


I think it is useful to dig a bit into the Lintian output:
- the error is related to the relative runpath of
/usr/lib//meshlab/libmeshlab-common.so,
not
/usr/bin/meshlab
and this is somewhat important, I trust this is not what we want to 
achieve [0]. Also it would be worth checking the runpaths of all the 
other private libraries;
- mismatched Lintian overrides are probably caused by recent changes in 
Lintian syntax;
- d/copyright should be slightly reworked, for instance there is a 
stanza with "License: BSD" which is not associated to a full text (also 
you have BSD-2-Clause and BSD-3-Clause, maybe "BSD" is one of them?);

- while you are at it, you could raise the Standards version to 4.6.1.



It at least appears to start up correctly here, when built on
bullseye, but I didn't do a lot of testing on it. Just loaded a few
files.

If someone has a few cycles to look it over, fix that issue, and
submit it, that would be great, since it's by far the most popular
package on my "things I've touched" list.


Let us know if you need to discuss anything in the above list!



https://salsa.debian.org/science-team/meshlab/

Thanks,
Ryan



Thanks for the work on meshlab,

Best,

--
Pierre

[0] https://lintian.debian.org/tags/relative-library-search-path


OpenPGP_signature
Description: OpenPGP digital signature

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

[Pierre Gruet]

Hi Andrea,

Le 04/09/2022 à 13:10, Andrea Pappacoda a écrit :
Il giorno sab 3 set 2022 alle 22:43:50 +02:00:00, Pierre Gruet 
 ha scritto:

Wonderful :) Please let us know when you are done.


Done!

I've reorganized the commits and made some more changes and fixes. The 
last thing I would've liked to do was to rename the branches so that 
they follow DEP14, but I cannot do it without write access to the repo 
(and it's not that important anyway).


Thanks for making the changes that quickly. I am fine with all of them, 
but it seems you forgot to include the changelog entry for version 
0.9.9.8+ds-3 in your merge request (whereas it was in the MR I reviewed 
yesterday). Could you please add it?
This problem was spotted by Lintian, which complained about a Standards 
version too recent regarding the date of the last changelog entry.


Also I am fine with letting the branches layout as is.



If you're ok with the changes I'd prefer to first push to Salsa and then 
upload to Mentors, to be sure that the repo doesn't get out of sync.


Hmm, I feel it is unnecessarily complicated given the situation; with 
just the changelog entry that is currently missing, the MR will be ready 
for being accepted and then we can do the upload without going through 
the mentors process. Your packaging is good and we can just go ahead 
with the changes you made.




Thank you all again for your feedback!



Thanks to you for working on glm!

Best regards,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature

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

[Pierre Gruet]

Hello again Andrea,

Le 03/09/2022 à 22:35, Andrea Pappacoda a écrit :

Thanks Pierre and Anton for your feedback!


You are very welcome! Thanks also for responding to the various points.


Il giorno sab 3 set 2022 alle 21:32:09 +02:00:00, Pierre Gruet 
[...]

- The long description of libglm-dev in debian/control is not
gender-neutral.


Gender-neutral language is not my area of expertise (in my native 
language even tables have a gender...), what should I change "when a 
programmer knows GLSL, he knows GLM as well" to? "they know GLM"?


Honestly it is also not something I am very familiar with. I can advise 
you to see Section 6.6.2.6 in the Debian Developers' Reference; yes, 
``they know GLM'' is what one shall use here.




Thanks again for your feedback! I submitted the pull request on the 
Salsa repo a while ago, and I didn't know much about packaging back 
then. I'm going to fix everything you reported (and possibly more) as 
soon as possible :)




Wonderful :) Please let us know when you are done.

Best regards,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature

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

[Pierre Gruet]

Hi Andrea, hi team,

First: I have reviewed the changes and I am globally satisfied with the 
packaging (some comments below), I would happily sponsor the upload with 
a few changes.


Could someone please give access to the repo to Andrea, and/or also 
allow me (pgt) to process such requests by raising my level to Owner?

Thanks a lot in any case.

Le 02/09/2022 à 22:06, Andrea Pappacoda a écrit :

Hi everyone!

I've been wanting to adopt the glm package, maintained by the Science 
Team, since last September.




It is great someone cares about this package, thanks!

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.


As I said above, the overall quality is very good. I have some comments 
and remarks:

- You could raise the Standards version to the current one;
- The glmConfig.cmake and glmConfig-version.cmake should be patched, as 
(given where you now install them) they are setting GLM_INCLUDE_DIRS to 
be ``/usr/share'', while we want ``/usr/include'';
- A follow-up notice in debian/tests/glm-tests: the tests refer to 
``${glm_INCLUDE_DIRS}'' which is empty. ``${GLM_INCLUDE_DIRS}'' is more 
appropriate.

- You could solve the (only!) Lintian note, caught by
lintian -i -I ,
by calling iconv from debian/rules by overriding a relevant dh_ step;
- To stick to the Debian-science policy, you should set the Section of 
the source package to ``science'' or ``math'';
- There is no ``Files: debian/*'' stanza in debian/copyright, adding one 
would be nice;
- The long description of libglm-dev in debian/control is not 
gender-neutral.





Thanks in advance :)



Thanks again for working on this package!

Best,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1015926: ITP: persalys -- GUI for uncertainty treatment and variabilities management

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Pierre Gruet 
User: debian-science@lists.debian.org
Usertags: field..science
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-science@lists.debian.org

* Package name: persalys
  Version : 12.0.1
  Upstream Author : Airbus-EDF-Phimeca
* URL : https://persalys.fr/
* License : LGPL-3+
  Programming Lang: C++
  Description : GUI for uncertainty treatment and variabilities management

Persalys is a graphical user interface for OpenTURNS, dedicated to the
treatment of uncertainty and the management of variabilities. The software is
a tool between the computer simulation, probabilistic analyses and the data
sciences. The interface is available in French or in English.

Persalys allows one to:
- create mathematical models: analytical, coupling with an external model
(finite elements, ...), FMU;
- analyse the variability of one's parameters thanks to many methods and
visualisation tools;
- statistically analyse one's measuring data, infer probability distributions
or create metamodels.

I am an user of Persalys. I plan to maintain in in the Debian-science team.

Bug#1011557: ITP: pagmo -- library for massively parallel optimisation

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Pierre Gruet 
User: debian-science@lists.debian.org
Usertags: field..science
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-science@lists.debian.org

* Package name: pagmo
  Version : 2.18.0
  Upstream Author : Francesco Biscani 
* URL : https://github.com/esa2/pagmo
* License : GPL-3+ or LGPL-3+
  Programming Lang: C++
  Description : library for massively parallel optimisation

pagmo is a C++ scientific library built around the idea of providing an
unified interface to optimization algorithms and to optimization
problems and to make their deployment in massively parallel environments easy.

This package is needed as a dependency of openturns, which is maintained in the
Debian science team -- which I also plan to do with pagmo.

Re: Ceres solver version 2.1.0

[Pierre Gruet]

Dear François,

Le 21/05/2022 à 18:45, François Mazen a écrit :

Dear Science Team,

I've updated the Ceres Solver package to version 2.1.0, but I can't
upload the package. Could someone grant me right to upload (I'm DM),
otherwise review and sponsor the upload?


DM rights granted, thanks for this work on ceres-solver!

While you are at it, you could upgrade the Standards version and apply 
the multiarch hints. Also I feel debian/copyright could be refreshed.




Best,
François


Best,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008572: ITP: xgboost-predictor-java -- Java implementation of XGBoost predictor for online prediction tasks

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Pierre Gruet 
User: debian-science@lists.debian.org
Usertags: field..science
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-science@lists.debian.org

* Package name: xgboost-predictor-java
  Version : 0.3.1
  Upstream Author : KOMIYA Atsushi
* URL : https://github.com/komiya-atsushi/xgboost-predictor-java
* License : Apache-2.0
  Programming Lang: Java
  Description : Java implementation of XGBoost predictor for online 
prediction tasks

XGBoost is an optimized distributed gradient boosting library designed to be
highly efficient, flexible and portable. It implements machine learning
algorithms under the Gradient Boosting framework. XGBoost provides a parallel
tree boosting (also known as GBDT, GBM) that solve many data science problems
in a fast and accurate way. The same code runs on major distributed
environment (Kubernetes, Hadoop, SGE, MPI, Dask) and can solve problems beyond
billions of examples.

This is the Java implementation of XGBoost. Right now it is needed as a
dependency of gatk, but it should be useful more broadly for scientists or
people from machine learning.
It will be team-maintained in Debian Science team.

Re: Spview package upload

[Pierre Gruet]

Hello Cyril,

Le 24/02/2022 à 21:33, Cyril Richard a écrit :

Dear all,

I've updated debian package of spview to its 2.0.0 version.
Please could you upload the package if everything is ok.


I looked at the changes and they seem good, I uploaded.
I just added more details about the Debian-specific changes you made in 
debian/changelog. You might consider doing such changes in separate 
commits so that they can be listed more easily.


Thanks for providing an updated version and packaging it!



Sincerely yours,

Cyril RICHARD - Ingénieur de Recherche CNRS



Best regards,

--
Pierre

Bug#996991: ITP: jgrapht -- Java library of graph theory data structures and algorithms

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Pierre Gruet 
User: debian-science@lists.debian.org
Usertags: field..science
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-science@lists.debian.org

* Package name: jgrapht
  Version : 1.5.1
  Upstream Author : Abdallah Atouani and collaborators
* URL : https://jgrapht.org/
* License : LGPL-2.1 or EPL-2.0
  Programming Lang: Java
  Description : Java library of graph theory data structures and algorithms

JGraphT is a free Java class library that provides mathematical graph-theory
objects and algorithms. In JGraphT, a graph is defined as a set of vertices
connected by a set of edges.

It is possible to define graphs, to modify, compare or generate them, to run
many algorithms through them. One may also import or export graphs.


The library is needed for the packaging of biojava5, which is an aim of the
Debian med team. It is also a nice adddition to Debian to have this Java
library to tackle graph theory problems.
Many years ago, libgrapht0.6-java and libjgrapht0.8-java have been packaged
because new upstream versions of jgrapht generally incorporated ABI changes.
Now this seems not to be the case, hence this unversioned package name.
The packaging will be done in the Debian-science team.

Re: Looking for example package that uses multiple source tarballs

[Pierre Gruet]

Hi Qianqian,

Le 26/06/2020 à 04:20, Qianqian Fang a écrit :
> 
> [...]
> 
> thanks Pierre for the comments and sample project, very helpful!
>

You are welcome!
> 
> [...]
> 
> I am not sure if it is related, but i have to change my debian/changelog
> version to a lower version number (1.9.1) in order to let uscan download
> the new release (1.9.5). however, both .tar.xz files are empty (except
> the debian/ folder)
> 
> |octave-iso2mesh_1.9.1-1.debian.tar.xz
> octave-iso2mesh_1.9.5+dfsg1-0ubuntu1.debian.tar.xz
> |
> 
> but the *octave-iso2mesh_1.9.1.orig.tar.gz* file is correctly repacked
> and contains all needed files.
> 
> I am wondering if anyone notice something wrong in repack or watch
> script? my repack file was slightly modified from
> https://wiki.debian.org/BenFinney/software/repack
>

As you guessed, the fact that you got the old version number 1.9.1 in
the name of the orig tarball is because "debian" is provided as the
third argument concerning the first tarball, as the above link explains:
it forces the use of the version number written in debian/changelog. You
may see, if you put the right number again in debian/changelog, that
running "uscan --force" will download the tarballs and give them the
right version number.

Yet, I guess this should not remain as is but I unfortunately do not
have the repacking skills to do more at that point.

> 
> another minor thing is the "|-0ubuntu1|" suffix. I am testing the
> packaging in a Ubuntu 18.04 box, is there a way to remove that?
> 
> my packaging files are committed at
> https://salsa.debian.org/pkg-octave-team/octave-iso2mesh/
> 
> 
> 
> much appreciated!
> 
> Qianqian
> 

All the best,
Pierre

Re: Looking for example package that uses multiple source tarballs

[Pierre Gruet]

Hi Qianqian,


Le 25/06/2020 à 21:02, Qianqian Fang a écrit :
> hi everyone,
> 
> I am working on packaging a matlab/octave toolbox that involves multiple
> source tarballs
> 
> https://salsa.debian.org/pkg-octave-team/octave-iso2mesh
> 
> [...]
> 
> I notice that debian/watch file supports multiple source components, so
> I wrote the below watch file:
> 
> |
> |
> 
> |version=3||
> ||
> ||opts="dversionmangle=s/\+dfsg\.\d+$//,filenamemangle=s/\S+\/v?(\S+)\.tar\.gz/iso2mesh-$1\.tar\.gz/"
> \||
> ||    https://github.com/fangq/iso2mesh/tags .*/v?(\d\S+)\.tar\.gz \||
> ||    debian debian/repack||
> ||
> ||https://github.com/fangq/cork/releases
> .*/v(\d[\d\.]*)\.(?:tar.gz|tar.bz2|tar.xz)||
> ||https://github.com/fangq/meshfix/releases
> .*/v(\d[\d\.]*)\.(?:tar.gz|tar.bz2|tar.xz)|
> 

I think you should provide some options ("opts=..."): for instance, a
component name should be provided for the two last parts. You can look
at the manpage of uscan, it provides some examples of watch files for
multiple upstream tarballs.
As you are doing some repack, I guess you will add some suffix to the
version number (like "+dfsg"), and to do so you should need to provide
the "oversionmangle=..." option for the first tarball. Examples are
shown in uscan's manpage.

> 
> but when I ran*uscan --verbose*, it only downloaded/repacked the main
> source file, but refused to download the components
> 
> [...]
> 
> 
> I am wondering if you know any sample package that uses repack/uscan to
> combine multiple source packages? The uscan manpage mentioned about MUT,
> but I could not find a working example.
>

I recently packaged libaparapi-java, which is not yet in Debian but
which you can get from its Salsa repository

https://salsa.debian.org/med-team/libaparapi-java

Running "uscan --verbose" will allow you to get three tarballs : a main
one and two components.

> 
> thanks, let me know if you have any suggestions.
> 
> Qianqian
> 
> 

Regards,
Pierre

Re: [RFS] bibutils for an upload in experimental

[Pierre Gruet]

Hi Andrius,

Le 26/04/2020 à 07:10, mer...@debian.org a écrit :
> Hi Pierre,
> 
> On 2020-04-25 15:53, Pierre Gruet wrote:
>> The release team has just asked to go ahead after I submitted a transition
>> bug [1]; I have prepared the upload to unstable in Salsa [2] (with
>> UNRELEASED distribution), would you please mind uploading it, as you kindly
>> offered?
> 
> Done. Thanks for your contribution!
>

Thanks for helping :-)

> 
> I see that the most of the reverse dependencies of bibutils belong to
> Haskell team. As I am not a member of that team, please contact them for
> sponsoring haskell-* packages.
>

Absolutely, the only non-Haskell reverse dependency is the binary bibutils.
I have already filed a blocking bug, which I am going to raise to RC, and I
will write to the list following your advice.

> 
> Best wishes,
> Andrius
> 

All the best,
Pierre

Re: [RFS] bibutils for an upload in experimental

[Pierre Gruet]

Hi Andrius,

Le 14/04/2020 à 20:22, Andrius Merkys a écrit :
> Hi Pierre,
> 
> On Tue, 14 Apr 2020, 18:54 Pierre Gruet,  <mailto:pgtdeb...@free.fr>> wrote:
> 
> Thanks a lot for reviewing my work, correcting this mistake and uploading
> the package to experimental!
> 
> 
> Happy to help!
> 
> I will now wait for it to exit NEW and then launch the transition 
> procedure.
> 
> 
> Sure! Ping me when you need an upload to unstable for this.
>

The release team has just asked to go ahead after I submitted a transition
bug [1]; I have prepared the upload to unstable in Salsa [2] (with
UNRELEASED distribution), would you please mind uploading it, as you kindly
offered?

> 
> Best wishes,
> Andrius

Thanks a lot in advance, have a nice day,
Pierre

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958662
[2] https://salsa.debian.org/science-team/bibutils

Re: [RFS] bibutils for an upload in experimental

[Pierre Gruet]

Hi Andrius,

Le 14/04/2020 à 07:10, mer...@debian.org a écrit :
> Hi Pierre,
> 
> On 2020-04-08 19:59, Pierre Gruet wrote:
>> Some days ago I worked on the packaging of bibutils, which is maintained in
>> the team. I had to bump the SONAME and therefore I ask for sponsorship to
>> put it in *experimental* in order to begin a transition procedure, having
>> identified four reverse-dependencies.
>>
>> If time permits, I would be happy to get feedback on my packaging and to
>> have the package uploaded.
> 
> I have uploaded bibutils to experimental today. I have just changed a
> line in the debian/changelog saying that libraries are placed in
> /usr/share, when indeed they seem to be placed in /usr/lib.
> 
> Thanks a lot for your contribution!
> 

Thanks a lot for reviewing my work, correcting this mistake and uploading
the package to experimental!

I will now wait for it to exit NEW and then launch the transition procedure.

>
> Best,
> Andrius
> 

All the very best,
Pierre

[RFS] bibutils for an upload in experimental

[Pierre Gruet]

Dear all,


Some days ago I worked on the packaging of bibutils, which is maintained in
the team. I had to bump the SONAME and therefore I ask for sponsorship to
put it in *experimental* in order to begin a transition procedure, having
identified four reverse-dependencies.

If time permits, I would be happy to get feedback on my packaging and to
have the package uploaded.

The package is in Salsa [1].

In order to avoid an accidental upload to unstable, I have already put
*experimental* in the changelog.


Thanks a lot,
Pierre


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

[RFS] bibutils [ITA] -- interconvert various bibliographic data formats

[Pierre Gruet]

Dear Debian Science maintainers,

I have taken over maintenance of bibutils, of which previous 
uploader was David Bremner, who submitted a RFA bug last year.


I am looking for a sponsor for the package:

 * Package name: bibutils
 * Version : 6.10-1
 * Upstream Author : Chris Putnam
 * URL : https://sourceforge.net/projects/bibutils/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/science-team/bibutils
 * Section : text


It builds those binary packages:

  bibutils - interconvert various bibliographic data formats
  libbibutils-dev - bibliography file converter, development kit
  libbibutils7 - bibliography file converter, shared library


Is it possible for you to review this package, which can be found
in Salsa, following the above URL?


Changes since the last upload:

  * New upstream version 6.10
  * New uploader (Closes: #896574), thanks to David Bremner!
  * Raising Standards version to 4.5.0
  * Updating copyright information and enabling machine-readable format
  * Bumping SONAME to libbibutils.so.7
  * Correcting tests of slist_add
  * Fixing FTCBFS with a patch of Helmut Grohne (Closes: #853243)
+ Let dh_auto_build pass cross compilers to $(MAKE)
+ Honour DEB_BUILD_OPTIONS=nocheck
  * Supporting Multi-Arch
  * Fixing Lintian issues with severity info


Warm regards,

Pierre Gruet