[Help] molds: FTBFS with mpich as default MPI provider: /usr/bin/ld: cannot find -lmpi_cxx: No such file or directory

[Andreas Tille]

Control: tags -1 help
Thanks

Hi,

today molds (from Debichem team) came up as candidate for the Bug of the
Day[1].  I considered bug #1075979 easy to fix by simply adding
libopenmpi-dev to Build-Depends since

$ apt-file search libmpi_cxx.so | grep -- -dev
libopenmpi-dev: /usr/lib/x86_64-linux-gnu/libmpi_cxx.so
libopenmpi-dev: /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so

but this is obviously not the case for the 5.x series of libopenmpi-dev
which does not contain this library any more.  Any hints for
replacements or other ways to make the linker happy are welcome since
the problem remains.

Thank you for any help
   Andreas.


[1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks

-- 
https://fam-tille.de

Re: Salsa group role for DDs; bulk update needed

[Andreas Tille]

Hi,

Am Fri, Oct 18, 2024 at 11:21:28AM +0200 schrieb Anton Gladky:
> thanks a lot for raising this! I totally agree with the proposal.
> The only problem is that gitlab API gives the email address which
> we can use to determine, whether the user is DD or not, is available
> only for payed version of gitlab [1]. If there are some other ways
> to get this information, please let me know.

Its actually not really granted that a DD is registered with the
@debian.org e-mail.  So even if we would have that information its not
really helpful.  I guess we could query debian-keyring instead.

> Otherwise, I am also OK to give all members the status maintainer.

Hmmm, I'm absolutely a fan of non-restrictive permissions.  However
we have a lot of people who are actually not contributing and who
I'd rather would degrade to "docwriter" permissions.  What about
querying teammetrics database:

teammetrics=# select * from (select name, count(*) as count from commitstat 
where project = 'debian-science' group by name order by count desc) tmp where 
count > 100;
...
127 rows

This could be done more fine grained for limiting the commits to the
last 5 years or so.  Than we get the real contributors who are active
while we do not give more permissions to people who are inactive and
might not notice if their account might be hijacked.

Kind regards
   Andreas.

> Am Fr., 18. Okt. 2024 um 10:12 Uhr schrieb Michael R. Crusoe
> :
> >
> > TL;DR: request for a script/tool to audit & fix Salsa team roles; request 
> > for one of the Science team owners to run that script/tool.
> >
> > Hello,
> >
> > While helping out[0] a fellow Debian Developer (DD), I noticed that they 
> > had the wrong role in the "science-team" Salsa group.
> >
> > According to the Debian Science Team policy, "all Debian Developers 
> > [should] have at least Maintainer level of access".
> >
> > https://science-team.pages.debian.net/policy/#idm145
> >
> > It would be great if the following script/tool existed:
> >
> > 1. Grab the list of members of the Debian Science team from Salsa.
> > 2. Confirm which of these Salsa users are Debian Developers.
> > 3. For each Salsa user (member of the "science-team" Salsa group) who is a 
> > confirmed Debian Developer, ensure that they have the GitLab group role of 
> > "Maintainer" or higher.
> > 4. All other members of the "science-team" Salsa group (corresponding to 
> > Salsa users who are Debian Maintainers, or who are without formal 
> > membership in Debian) should have the GitLab role of "Developer".
> >
> > If someone can write or assemble that script/tool, they we can ask one of 
> > the Science team "owners" to run the script/tool to do a bulk fix of 
> > permissions
> >
> > List of owners of the "science-team" Salsa group: 
> > https://salsa.debian.org/groups/science-team/-/group_members?max_role=static-50
> >
> > [0] The DD had made a team upload, but they were unable to push their 
> > changes to the corresponding Package Repository as the "debian" branch was 
> > protected and limited to team members in the "Maintainers" role only. 
> > Personally I would be fine with allowing all Debian Maintainers to also 
> > push, but I don't know if that maps well to the GitLab roles. Currently the 
> > Debian Science Team policy is silent on the topic of protected branches 
> > beyond the statement that "[a]ll group members [should] have write access 
> > to all Package Repositories".
> >
> > Cheers
> >
> > --
> > Michael R. Crusoe
> 
> 

-- 
https://fam-tille.de

Fwd: Finding potential speakers for HEPiX

[Andreas Tille]

Hi,

is there anyone near Oklahoma who might represent Debian (see below)?

Kind regards
Andreas.

- Weitergeleitete Nachricht von Dennis van Dok  -

Date: Mon, 7 Oct 2024 15:17:18 +0200
From: Dennis van Dok 
To: Andreas Tille 
Subject: Finding potential speakers for HEPiX

Hi Andreas,

we had a good contribution at HEPiX in Paris from Nicolas Dandrimont, which
was well received and helps to give Debian some traction in the HTC community.

For the upcoming meeting in Oklahoma[1] I would like see if there is anyone
(maybe close to there already) who could make a contribution.

1. https://indico.cern.ch/event/1450798/

Do you have any idea how to go about that?

Thanks,

Dennis


- Ende weitergeleitete Nachricht -

-- 
https://fam-tille.de

Re: Taking over metar into Debian Science team

[Andreas Tille]

Hi Joost,

thank you for the quick response.

Am Sun, Sep 15, 2024 at 08:13:00AM +0200 schrieb Joost van Baal-Ilić:
> Your assumption is correct, you are very welcome to move metar git/maintenance
> to the debian science umbrella.

Thanks for confirming.  I've prepared an upload[3] fixing some bugs and
opened some issues in upstream Git to sort out whether we can close the
other Debian bugs.

Kind regards
Andreas.

[3] https://salsa.debian.org/science-team/metar
 
> On Sun, Sep 15, 2024 at 07:54:02AM +0200, Andreas Tille wrote:
> > Hi,
> > 
> > metar showed up as Bug of the Day[1] and I'd like to work on the bugs of
> > the package.  I think its a nice fit to Debian Science team.  Usually I
> > would file some ITS bug following the Package Salvage procedure[2] but
> > given that you asked for sponsoring (RFS) I assume you would like to
> > join a team where its easy to find sponsors which fits for the Debian
> > Science team.
> > 
> > So I simply assume that this is fine for you.
> > 
> > Kind regards
> > Andreas.
> > 
> > [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
> > [2] 
> > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> > 
> > -- 
> > https://fam-tille.de
> > 
> 

-- 
https://fam-tille.de

Taking over metar into Debian Science team

[Andreas Tille]

Hi,

metar showed up as Bug of the Day[1] and I'd like to work on the bugs of
the package.  I think its a nice fit to Debian Science team.  Usually I
would file some ITS bug following the Package Salvage procedure[2] but
given that you asked for sponsoring (RFS) I assume you would like to
join a team where its easy to find sponsors which fits for the Debian
Science team.

So I simply assume that this is fine for you.

Kind regards
Andreas.

[1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
[2] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging

-- 
https://fam-tille.de

Re: Request for mentorship t to contribute into Debian

[Andreas Tille]

Hi Emmanuel,

Am Tue, Jul 16, 2024 at 09:00:40AM +0200 schrieb Emmanuel FARHI:
> This is a call for Debian mentorship.
> 
> My background is in science and engineering, as well as in scientific
> computing. I'm especially active in scientific programming, contributing to
> a large number of projects on gitlab/github/salsa (I already have a
> farhi-guest account in the latter).
> 
> I've been using Debian-class systems for about 25 years, and I now know
> quite a bit in Debian source packaging e.g. using devscripts tools.
> 
> As part of my current activity (X-ray synchrotron), I've contributed into a
> large ITP/NEW/unstable/testing initiative for new scientific software
> (mostly in Debian Science), and I'm part of the Debian Photon-and-Neutron
> team/pure blend (debian-pan). Up to now we have pushed ~300 new such
> packages (for X-ray and photon science), as well as many related lower level
> libraries.

Thank you for the introduction and welcome in the team and you work in
Debian PAN.  Any contribution is really welcome.

> As of today, I rely on a DD in my team, and a set of DD
> subcontractors for the Debian package uploads.
> 
> I think it's time for me to reach a new level of contribution. I'm eager to
> contribute directly into Debian and its scientific software stack.
> 
> My New Member page is:
> 
>  * https://nm.debian.org/person/farhi/
> 
> and my keysignature fingerprint is:
> 
>  * 74BF724473F079B71ABB867E295EBC8B5A14A5B6

I guess the DD who worked together with you and has sponsored you work
is the best person to support your NM application.
 
> I'd like to join the team of Debian Developpers in order to officially push
> packages, and I'm looking for Mentors to endorse me.
> 
> Would you be so kind to consider my application (and endorse/sign my PGP) ?
> SYNCHROTRON http://www.synchrotron-soleil.fr
 ^

As far as I know there are some DDs around who will do so.

In any case: Welcome in the team
 Andreas.

-- 
https://fam-tille.de

Re: numba

[Andreas Tille]

Hi Diane,

Am Sun, Jul 07, 2024 at 03:50:50PM -0700 schrieb Diane Trout:
> 
> I was wondering how to do this...
> 
> On Salsa the i386 test runner failed with this test case, which seems
> very much like a 32-bit issue.

Since you did not got any answer on this.  If this problem occures on
i386 *only* we might start a discussion whether we want to keep i386
support for numba and its rdepends.  There might be some applications
for arm32 bit in scientific devices but as far as I understood Debian is
droping i386 in the foreseable future.  Starting droping support for
scientific applications now does not seem to do any harm and might save
you some time on maintaining numba.
 
> I'm just uploaded numba_0.59.1+dfsg-2 with Build-Depends: architecture-
> is-64-bit. Hopefully that gets further through the builder.

Ahhh, well, this seems to be a sensible decision even excluding 32bit
arm which is fine for me as well.  It might mean a chain of removal
requests of several rdepends but we need to do this sooner or later
anyway.

Thanks a lot for all your work on numba.  Its really appreciated
Andreas.

-- 
https://fam-tille.de

Re: jupyter-notebook packages

[Andreas Tille]

Am Mon, Jul 01, 2024 at 01:42:06PM -0700 schrieb Diane Trout:
> Is there a way we could coordinate and split up updating packages? I
> think the widgets package has been missing the javascript libraries
> forever.
> 
> Also is there a debian science chat channel?

There is #debian-science (from my extremely limited experience not
extensively used).
 
> There's a #debian-python irc channel, and debian-med has a matrix
> channel.

I'd consider joining a debian-science matrix channel if someone
would create one.

Kind regards
   Andreas. 

-- 
https://fam-tille.de

Re: numba

[Andreas Tille]

Am Wed, Jun 26, 2024 at 01:53:25PM +0200 schrieb PICCA Frederic-Emmanuel:
> I would say if upstream does not support an architecture and we are not able 
> to catch up... we do not have the manpower to solve this...

100% ACK

Maybe it helps to

Build-Depends: architecture-is-64-bit, architecture-is-little-endian,

?

Kind regards
Andreas.

-- 
https://fam-tille.de

Re: Feedback on talk about usage of Debian in HPC: (Was: If someone wants to join)

[Andreas Tille]

Hi Cordell,

Am Fri, Jun 21, 2024 at 04:23:38AM +0200 schrieb Cordell Bloor:
> Thank you for the heads-up. Excellent presentation. I'm sure I will refer 
> back to your list of HPC centres running Debian in the future.

Thanks a lot for your feedback.
 
> I agree that the lack of a go-to company for support causes some difficulty 
> for Debian in the HPC space. It makes things tricky as compared to dealing 
> with Canonical, Red Hat, etc. Perhaps a system integrator like HPE could over 
> take that role, but I assume they would have done so already if they wanted 
> to.

I absolutely agree to both statements (tricky without some system
integrator and if some integrator would be interested this would have
happened).
 
> On a related note, I find the Ubuntu Certified Hardware program quite 
> interesting [1]. A formal certification program for Debian could help both 
> with the user concerns about compatibility and with acquiring hardware for 
> quality assurance. The feasibility of such a program is an open question.

ACK, this might be interesting to have for Debian.  We just need someone
who wants to (realiably) do this.
 
Kind regards
   Andreas.
 
> [1]: https://ubuntu.com/certified

-- 
https://fam-tille.de

If someone wants to join (Was: Any input for some talk about usage of Debian in HPC)

[Andreas Tille]

Hi,

feel free to pick the relevant data from this document

   
https://docs.google.com/document/d/1rcvtsD5QVmmLxSDNxm6FBrWdI0GjXSZtfJ-vkGfKPO4

if you want to join.  Thanks to all who provided input which
was really valuable for me.

Kind regards
Andreas.


Am Sun, May 19, 2024 at 01:12:40PM +0200 schrieb Andreas Tille:
> Hi,
> 
> I have an invitation to have some talk with the title
> 
>Debian GNU/Linux for Scientific Research
> 
> Abstract:
> 
>Over the past decade, Enterprise Linux has dominated large-scale
>research computing infrastructure. However, recent developments have
>sparked increased interest in community-led alternatives. Debian
>GNU/Linux, a long-standing choice among researchers for supporting
>scientific work, is experiencing a renewed interest for High-Throughput
>Computing (HTC) and High-Performance Computing (HPC) applications.  This
>presentation will provide an overview of how Debian is being utilized to
>support scientific research and will include a case study showcasing the
>migration of HTC operations from Enterprise Linux 7 (EL7) to Debian.
> 
> While I could talk about Debian Science and Debian Med in general it
> would be cool to reference to some real life examples where Debian is
> used in Science and what might be the reason to use Debian.
> 
> I personally would like to stress the "we package what we use" aspect
> and the "we mentor upstream to merge competence of the program with
> packaging skills" idea.  Any input would be welcome to cover more ideas.
> 
> Kind regards
> Andreas.
> 
> -- 
> https://fam-tille.de
> 
> 

-- 
https://fam-tille.de

Re: package bcftools dependencies for gff2gff.py and guess-ploidy.py cause bcftools to have 10x as many dependencies

[Andreas Tille]

Hi again,

Am Tue, Jun 18, 2024 at 04:04:21PM -0400 schrieb Giulio Genovese:
> My use case is docker images. I basically cannot use the bcftools debian
> package anymore to build containers as it balloons the size of the final
> image. Appreciate forwarding to the Debian Med team. Thank you. -Giulio

Sounds sensible.  Would you mind summarising all the reasons you gave in
some bug report (`reporbug bcftools`) to make sure it does not get
forgotten?

Thank you
   Andreas.

> On Tue, Jun 18, 2024 at 3:03 PM Andreas Tille  wrote:
> 
> > Hi Giulio,
> >
> > I'm forwarding this to the Debian Med team since as DPL I have basically
> > stalled my packaging work.
> >
> > My gut feeling tells me that 500MB are not really much on a
> > bioinformatitions machine - specifically since python3-matplotlib seems
> > to be nearly a "default installation" on scientists computers.  But well,
> > maybe Recommends are fine and possibly some Test-Depends need to be
> > added (not checked!)
> >
> > Kind regards
> > Andreas.
> >
> > Am Tue, Jun 18, 2024 at 02:37:48PM -0400 schrieb Giulio Genovese:
> > > Hi Andreas,
> > >
> > > To address bug #1069234
> > > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069234> the bcftools
> > > package acquired, through commit a46c2e25
> > > <
> > https://salsa.debian.org/med-team/bcftools/-/commit/a46c2e2567ffcbac0099f102c6bcac2568f100a8
> > >,
> > > two new dependencies:
> > > - python3-gffutils
> > > - python3-matplotlib
> > > This causes the size of the package dependencies to explode from <50MB to
> > > >500MB.
> > >
> > > As bcftools is mostly a C software, I believe the most appropriate
> > approach
> > > is to have those dependencies as recommended dependencies, so that the
> > > package can be installed in a minimalistic fashion with the apt-get
> > > --no-install-recommends command while not affecting other use cases,
> > > similarly to how it was done for the bwa package in commit e3fef43e
> > > <
> > https://salsa.debian.org/med-team/bwa/-/commit/e3fef43e17a26dd0c1c7d7ac81333a0e9c6367b3
> > >
> > > where perl was demoted to a recommended dependency.
> > >
> > > I hope this change can be included for the next release. Thank you!
> > >
> > > Giulio
> >
> > --
> > https://fam-tille.de
> >

-- 
https://fam-tille.de

Re: package bcftools dependencies for gff2gff.py and guess-ploidy.py cause bcftools to have 10x as many dependencies

[Andreas Tille]

Hi Giulio,

I'm forwarding this to the Debian Med team since as DPL I have basically
stalled my packaging work.

My gut feeling tells me that 500MB are not really much on a
bioinformatitions machine - specifically since python3-matplotlib seems
to be nearly a "default installation" on scientists computers.  But well,
maybe Recommends are fine and possibly some Test-Depends need to be
added (not checked!)

Kind regards
Andreas.

Am Tue, Jun 18, 2024 at 02:37:48PM -0400 schrieb Giulio Genovese:
> Hi Andreas,
> 
> To address bug #1069234
>  the bcftools
> package acquired, through commit a46c2e25
> ,
> two new dependencies:
> - python3-gffutils
> - python3-matplotlib
> This causes the size of the package dependencies to explode from <50MB to
> >500MB.
> 
> As bcftools is mostly a C software, I believe the most appropriate approach
> is to have those dependencies as recommended dependencies, so that the
> package can be installed in a minimalistic fashion with the apt-get
> --no-install-recommends command while not affecting other use cases,
> similarly to how it was done for the bwa package in commit e3fef43e
> 
> where perl was demoted to a recommended dependency.
> 
> I hope this change can be included for the next release. Thank you!
> 
> Giulio

-- 
https://fam-tille.de

Any input for some talk about usage of Debian in HPC

[Andreas Tille]

Hi,

I have an invitation to have some talk with the title

   Debian GNU/Linux for Scientific Research

Abstract:

   Over the past decade, Enterprise Linux has dominated large-scale
   research computing infrastructure. However, recent developments have
   sparked increased interest in community-led alternatives. Debian
   GNU/Linux, a long-standing choice among researchers for supporting
   scientific work, is experiencing a renewed interest for High-Throughput
   Computing (HTC) and High-Performance Computing (HPC) applications.  This
   presentation will provide an overview of how Debian is being utilized to
   support scientific research and will include a case study showcasing the
   migration of HTC operations from Enterprise Linux 7 (EL7) to Debian.

While I could talk about Debian Science and Debian Med in general it
would be cool to reference to some real life examples where Debian is
used in Science and what might be the reason to use Debian.

I personally would like to stress the "we package what we use" aspect
and the "we mentor upstream to merge competence of the program with
packaging skills" idea.  Any input would be welcome to cover more ideas.

Kind regards
Andreas.

-- 
https://fam-tille.de

Re: Action needed for R-pkg Uploaders

[Andreas Tille]

Hi again,

I would be *really* happy if those who are in CC could clarify their
intention to maintain the packages that have their names set as
Uploader.  Julian Gilbey and Joost van Baal-Ilić where the only ones who
responed to the initial mail from two months ago.

I just realised that there is a new version of r-cran-amelia which has
Chris Lawrence as Uploader.  Chris, according to UDD did the last
uploads of other packages at 2023-08-19 so you seem to be active in
Debian in some way.  It would help if you could give us some update
about your R packages, if you think these make sense inside Debian or
whether some can be removed and you intend to care for the others or
not.

I also realised that Jonathon Love had his last changelog entry
  r-cran-rprotobuf | 0.4.5-1  | 2016-09-06 16:15:13+00
Jonathon, it would be great if you give some status update about your
interest in the packages where you are listed as Uploader.

I did not checked other uploaders yet, but it would be great to clarify
the status of your involvement.  This would help me a lot to save my
time and concentrate on more important things.

As a general remark: You can add your ID / replace my ID by yours in any
package where I'm listed as Uploader.  I'd be really happy about this.

Kind regards
Andreas.

Am Mon, Mar 11, 2024 at 03:47:42PM +0100 schrieb Andreas Tille:
> Hi R-pkg team members,
> 
> as you might have possibly read I nominated myself for DPL for the next
> term[1].  I will pronounce in my platform clearly that I will stop my
> uploading activity to rather concentrate on my DPL tasks.  I hope I will
> be able to really stop myself from uploading in case I might be elected.
> 
> I will also express that I'm a bit afraid about the effect on the teams
> where I'm very active in.  This is specifically true for the R-pkg team.
> I did lots of team uploads in this team as you might have observed for
> those packages where you are listed as Uploader (see below).  I simply
> worked down the list of packages needing an update[2] if I have some
> spare minutes - no matter whether I'm Uploader or not.  The
> `routine-update` script was of great help here since it basically does
> what it says.
> 
> The fact that the list[2] became a bit longish is simply a sign that I
> was focussing on other things the last weeks - drafting my DPL platform
> etc.  I might upload some packages from list if other things like
> cleaning up after time_t transition in some packages might occupy all my
> time.  However, you need to expect that this list will grow even longer
> if nobody will stand up and fulfill the task I more or less silently
> did the last couple of years.
> 
> I've put all those contributors in CC who had a hit in the UDD query
> 
>SELECT DISTINCT uploaders FROM sources WHERE maintainer_email = 
> 'r-pkg-t...@alioth-lists.debian.net' AND release = 'sid';
> 
> which means the package is maintained by R-pkg team and the package is
> in sid (so no old Uploaders).  Below you see a list of the actual
> package which is listing you as Uploader.  Please note that some people
> are mentioned with different e-mail addresses.  BTW, this list also
> contains Nilesh Patra who declared to leave the team[3].  We need to
> replace him as Uploader (and he is not mentioned in To-Field).
> 
> What I would like you to do is:
> 
>   1. Verify the list of packages whether you want to keep on working
>  on this/these package(s) (and if you have different e-mail
>  addresses please stick to only one)
>   2. If you do not want to serve as Uploader any more please try to
>  find a different Uploader (in the best case) and let this
>  contributor replace your ID or simply remove your ID to not
>  nurish the false hope that someone will care for this package
>  actively
>   3. Make sure you are uploading your packages regularly for new
>  upstream versions and check for potential bugs (listed at the
>  end of[2])
>   4. I'd be happy if you would do me the favour to upload those
>  packages that are listing me as Uploader as long as I might
>  serve as DPL (I do not plan to do so more than one year)
> 
> Thanks a lot for your cooperation inside R-pkg team
>Andreas.
> 
> [1] https://lists.debian.org/debian-vote/2024/03/msg2.html
> [2] 
> https://salsa.debian.org/r-pkg-team/maintenance-utilities/-/blob/master/outdated_r-packages.txt
> [3] https://lists.debian.org/debian-r/2023/11/msg00054.html
> 
> Packages maintained by Uploaders in R-pkg team.
> 
> Alba Crespi :
>  r-cran-data.table
>  r-cran-fastmatch
>  r-cran-metamix
>  r-cran-nmf
>  r-cran-nnls
>  r-cran-phangorn
>  r-cran-pkgmaker
>  r-cran-registry
>  r-cran-rngtools
> 
> Andr

Re: ncl has not set science-team as maintainer

[Andreas Tille]

Hi Alastair,

Am Fri, Apr 19, 2024 at 10:05:35AM +0100 schrieb Alastair McKinstry:
> Yes I will change maintainer on the next upload.

Thanks.
 
> ncl is in "maintenance" mode as of 2019. There is a pivot to python (pyNCL
> and other python modules) but there are still a lot of ncl scripts in use
> out there, so an upstream release is unlikely.

Thank you for the status update.  BTW, I'd recommend running
routine-update on the packaging (I'd volunteer to do so and push
to Git in case you want me to do so.)

Kind regards
   Andreas.

> Kind regards
> 
> Alastair
> 
> On 19/04/2024 09:43, Andreas Tille wrote:
> > Hi Alastair,
> > 
> > I've found ncl in the list of packages with t64 transition issues.
> > Since I know its a Debian Science package I had a look and realised
> > that this package has not set
> > 
> > Maintainer: Debian Science Maintainers 
> > 
> > 
> > as per team policy (and you as well as possibly others as Uploaders).
> > Do you have any specific reason for this?
> > 
> > BTW, when looking into it uscan reports
> > 
> > uscan info: Newest version of ncl on remote site is 6.6.2, local version is 
> > 6.6.2.dfsg.1
> > uscan info:  => Only older package available from:
> > 
> > This is probably due to using .dfsg instead of +dfsg.  I tried to add
> > some dversionmangle option but when featuring a '.' this is refused as
> > "unsafe" by uscan.  I'd recommend to change this with next upstream
> > version.
> > 
> > Kind regards
> >  Andreas.
> > 
> > [1] https://lists.debian.org/debian-devel/2024/04/msg00331.html
> > 
> -- 
> Alastair McKinstry,
> GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
> e: mckins...@debian.org, im: @alastair:mckinstry.ie
> 
> 

-- 
https://fam-tille.de

Does anybody intent to adopt openmx -- nano-scale material simulations

[Andreas Tille]

Hi,

since openmx is listed on the list of blockers for t64 transition and
long time orphaned I wonder whether it is better to remove the package
from Debian.  According popcon its usage has basically zero votes[2]
(which might be caused by the fact that it was not included into the
last two stable releases.

It would be nice if some volunteer would care for this package which had
a new upstream version in 2021 (so is not completely orphaned upstream).

Otherwise it probably makes sense to remove the package from Debian.

Kind regards
 Andreas.

[1] https://lists.debian.org/debian-devel/2024/04/msg00331.html
[2] 
https://qa.debian.org/popcon-graph.php?packages=openmx&show_vote=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

-- 
https://fam-tille.de

ncl has not set science-team as maintainer

[Andreas Tille]

Hi Alastair,

I've found ncl in the list of packages with t64 transition issues.
Since I know its a Debian Science package I had a look and realised
that this package has not set

   Maintainer: Debian Science Maintainers 


as per team policy (and you as well as possibly others as Uploaders).
Do you have any specific reason for this?

BTW, when looking into it uscan reports

uscan info: Newest version of ncl on remote site is 6.6.2, local version is 
6.6.2.dfsg.1
uscan info:  => Only older package available from:

This is probably due to using .dfsg instead of +dfsg.  I tried to add
some dversionmangle option but when featuring a '.' this is refused as
"unsafe" by uscan.  I'd recommend to change this with next upstream
version.

Kind regards
Andreas.

[1] https://lists.debian.org/debian-devel/2024/04/msg00331.html

-- 
https://fam-tille.de

Re: Action needed for R-pkg Uploaders

[Andreas Tille]

Hi Joost,

Am Mon, Mar 18, 2024 at 08:51:27AM +0100 schrieb Joost van Baal-Ilić:
> Andreas: thanks a lot for this heads-up, and thanks HUGELY for maintaining the
> bulk of the r-cran ecosystem in Debian for such a long time.

Thanks to you.  I just want to stress again the fact that it is
extremely questionable that this will continue in case in my DPL term in
case I might become elected.  If you all as team members want to profit
from up to date r-* packages you not only need to care for those
packages you are mentioned as Uploader but care for team wide updates.
In other words:  "Any team member can and *should* upload team
maintained packages no matter who is specified as Uploader."  BTW, its
perfectly welcome to add additional IDs to Uploaders.
 
> Op Mon, Mar 11, 2024 at 03:47:42PM +0100 schreef Andreas Tille:
> > 
> 
> >
> > Joost van Baal-Ilić :
> >  r-cran-bdgraph
> >  r-cran-corpcor
> >  r-cran-d3network
> >  r-cran-farver
> >  r-cran-fdrtool
> >  r-cran-formatr
> >  r-cran-ggforce
> >  r-cran-ggm
> >  r-cran-ggrepel
> >  r-cran-glasso
> >  r-cran-highr
> >  r-cran-httpuv
> >  r-cran-huge
> >  r-cran-hunspell
> >  r-cran-knitr
> >  r-cran-lavaan
> >  r-cran-lisreltor
> >  r-cran-markdown
> >  r-cran-matrixcalc
> >  r-cran-mi
> >  r-cran-mime
> >  r-cran-nfactors
> >  r-cran-qgraph
> >  r-cran-rcppparallel
> >  r-cran-rockchalk
> >  r-cran-sem
> >  r-cran-semplot
> >  r-cran-semtools
> >  r-cran-statcheck
> >  r-cran-tweenr
> >  r-cran-yaml
> 
> I'm afraid I won't have time to take care of those in the near
> future.  However, I _do_ plan to keep maintaining:
> 
>  r-cran-lavaan
>  r-cran-hunspell
>  r-cran-markdown
>  r-cran-httpuv
>  r-cran-statcheck
> 
> (And I've just managed to do upload new upstream of r-cran-statcheck;
> routine-update indeed makes life much easier :)

Good.
 
> So, would it be usefull to do an upload of the 31 - 5 = 26 other packages
> dropping my name from Uploaders: so changing:
> 
>  Maintainer: Debian R Packages Maintainers 
> 
>  Uploaders: Joost van Baal-Ilić 
> 
> into
> 
>  Maintainer: Debian R Packages Maintainers 
> 
> 
> in debian/control?

I'm not really sure what might be the best way to go.  Definitely it is
not good to have somehow false information about Uploaders who do not
intend to Upload the package in question.  Technically its the easiest
way to spot those packages who need an Uploader if there is nobody
mentioned.  We get a linitan warning (error?) about it and UDD will
return the results quickly.
 
It might possibly make sense as well to decide about droping some
packages with no rdepends and low popcon to reduce the workload.  For R
packages there are several ways for users to install (either in plain R
or cran2deb).  If we realise interest in some package was lost and it
just keeps us busy for no visible advantage for users, cleaning up our
package pool might make sense.

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Bug#1065841: Taking over datalad to either Debian Med or Debian Science team

[Andreas Tille]

Hi Yaroslav,

Am Tue, Mar 12, 2024 at 03:50:22PM -0400 schrieb Yaroslav Halchenko:
> Let's keep DataLad under our (NeuroDebian) umbrella for now, since we
> are also upstream there and project is active.  We are also
> working with Vasyl (CCed) to experiment with some semi-automation for
> package updates/backports (for neurodebian) and datalad (and some of its
> ecosystem) packages are the target.  Packaging will be on salsa.  We
> might move them under larger Med or Science teams, but not just yet.

That's perfectly fine and all I would like to see.  No presure.
 
> Re #1065841 specifically -- while trying to build updated package I
> experienced some odd side-effect (pip started to try to install
> tqdm) and didn't see immediate reason.I will see how well it goes on
> debian infra after source only upload (did now).

I perfectly trust you to maintain this package properly.  I simply
was querying this type of bug and thought datalad would nicely fit
into Debian Science scope.

Kind regards
Andreas. 

-- 
http://fam-tille.de

Taking over datalad to either Debian Med or Debian Science team

[Andreas Tille]

Hi Yaroslav,

once we agreed that we should probably move all Neurodebian packages to
Debian Med to make it accessible for a bigger team.  I was not really
active for some time in this attempt.  However, bug #1065841 brought
datalad on my screen.  I would love to see it maintained on Salsa either
in Debian Science team (since it has wider usage) or Debiam Med (since
we moved Neurodebian packages there).

I'd volunteer to do the move if you agree to and by doing so also fix
the two open bugs and run some `routine-update` on the packaging.

What do you think?

Kind regards
   AndreasI'd volunteer to do the move if you agree to and by doing so also fix
the two open bugs and run some `routine-update` on the packaging.

What do you think?

Kind regards
   Andreas.

-- 
http://fam-tille.de

Action needed for R-pkg Uploaders

[Andreas Tille]

Hi R-pkg team members,

as you might have possibly read I nominated myself for DPL for the next
term[1].  I will pronounce in my platform clearly that I will stop my
uploading activity to rather concentrate on my DPL tasks.  I hope I will
be able to really stop myself from uploading in case I might be elected.

I will also express that I'm a bit afraid about the effect on the teams
where I'm very active in.  This is specifically true for the R-pkg team.
I did lots of team uploads in this team as you might have observed for
those packages where you are listed as Uploader (see below).  I simply
worked down the list of packages needing an update[2] if I have some
spare minutes - no matter whether I'm Uploader or not.  The
`routine-update` script was of great help here since it basically does
what it says.

The fact that the list[2] became a bit longish is simply a sign that I
was focussing on other things the last weeks - drafting my DPL platform
etc.  I might upload some packages from list if other things like
cleaning up after time_t transition in some packages might occupy all my
time.  However, you need to expect that this list will grow even longer
if nobody will stand up and fulfill the task I more or less silently
did the last couple of years.

I've put all those contributors in CC who had a hit in the UDD query

   SELECT DISTINCT uploaders FROM sources WHERE maintainer_email = 
'r-pkg-t...@alioth-lists.debian.net' AND release = 'sid';

which means the package is maintained by R-pkg team and the package is
in sid (so no old Uploaders).  Below you see a list of the actual
package which is listing you as Uploader.  Please note that some people
are mentioned with different e-mail addresses.  BTW, this list also
contains Nilesh Patra who declared to leave the team[3].  We need to
replace him as Uploader (and he is not mentioned in To-Field).

What I would like you to do is:

  1. Verify the list of packages whether you want to keep on working
 on this/these package(s) (and if you have different e-mail
 addresses please stick to only one)
  2. If you do not want to serve as Uploader any more please try to
 find a different Uploader (in the best case) and let this
 contributor replace your ID or simply remove your ID to not
 nurish the false hope that someone will care for this package
 actively
  3. Make sure you are uploading your packages regularly for new
 upstream versions and check for potential bugs (listed at the
 end of[2])
  4. I'd be happy if you would do me the favour to upload those
 packages that are listing me as Uploader as long as I might
 serve as DPL (I do not plan to do so more than one year)

Thanks a lot for your cooperation inside R-pkg team
   Andreas.

[1] https://lists.debian.org/debian-vote/2024/03/msg2.html
[2] 
https://salsa.debian.org/r-pkg-team/maintenance-utilities/-/blob/master/outdated_r-packages.txt
[3] https://lists.debian.org/debian-r/2023/11/msg00054.html

Packages maintained by Uploaders in R-pkg team.

Alba Crespi :
 r-cran-data.table
 r-cran-fastmatch
 r-cran-metamix
 r-cran-nmf
 r-cran-nnls
 r-cran-phangorn
 r-cran-pkgmaker
 r-cran-registry
 r-cran-rngtools

Andrius Merkys :
 r-cran-cyclocomp
 r-cran-lintr
 r-cran-rlinsolve
 r-cran-xmlparsedata

Benjamin Eikel :
 r-cran-ggplot2
 r-cran-munsell
 r-cran-scales

Carlos Borroto :
 r-cran-plyr

Charles Plessy :
 r-bioc-genomeinfodb
 r-bioc-genomeinfodbdata
 r-bioc-genomicalignments
 r-bioc-hdf5array
 r-bioc-iranges
 r-bioc-matrixgenerics
 r-bioc-rtracklayer
 r-bioc-s4arrays
 r-bioc-s4vectors
 r-bioc-summarizedexperiment
 r-bioc-xvector
 r-bioc-zlibbioc
 r-cran-biocmanager
 r-cran-epitools
 r-cran-genetics

Chris Lawrence :
 r-cran-aer
 r-cran-amelia
 r-cran-bayesm
 r-cran-coda
 r-cran-eco
 r-cran-gam
 r-cran-geepack
 r-cran-gmaps
 r-cran-jsonlite
 r-cran-mapdata
 r-cran-mapproj
 r-cran-maps
 r-cran-matchit
 r-cran-mcmc
 r-cran-mcmcpack
 r-cran-mnp
 r-cran-pscl
 r-cran-psy
 r-cran-rjags
 r-cran-vgam
 r-cran-zelig

Christopher Hoskin :
 r-bioc-rbgl

Dirk Eddelbuettel :
 r-cran-rocr

Doug Torrance :
 r-cran-m2r
 r-cran-orthopolynom
 r-cran-partitions
 r-cran-r.devices
 r-cran-r.rsp
 r-cran-sets

Doug Torrance :
 r-cran-latte
 r-cran-mpoly

Dylan Aïssi :
 r-cran-fitbitscraper
 r-cran-fitcoach
 r-cran-leaps
 r-cran-prettyr

Dylan Aïssi :
 dh-r
 r-bioc-bioccheck
 r-bioc-biocviews
 r-bioc-impute
 r-bioc-mergeomics
 r-bioc-rhdf5filters
 r-bioc-tcgabiolinksgui.data
 r-bioc-zlibbioc
 r-cran-ape
 r-cran-beeswarm
 r-cran-bigmemory
 r-cran-bigmemory.sri
 r-cran-biocmanager
 r-cran-calibrate
 r-cran-clipr
 r-cran-clisymbols
 r-cran-devtools
 r-cran-factominer
 r-cran-flashclust
 r-cran-gee
 r-cran-ggsci
 r-cran-gh
 r-cran-ini
 r-cran-isoband
 r-cran-isospecr
 r-cran-locfit
 r-cran-lubridate
 r-cran-metamix
 r-cran-modeldata
 r-cran-qqman
 r-cran-ranger
 r-cran-rcmdcheck
 r-cran-rematch2
 r-cran-remotes
 r-cran-reprex
 r-cran-reticulate
 r-cran-rstatix
 r-cran-rvest
 r-cran-selectr
 r-cran-se

Re: Segyio is lagging behind upstream (Was: segyio ftbfs with Python 3.12)

[Andreas Tille]

Hi Tino,

thanks for the hint which reduced the number of test suite failures to
one as you can see in Salsa CI[1].  In case someone might find a
solution for this one we might upload - if not I wonder whether this
package is a candidate for removal.

Please note: I have no interest into this package at all - just hunting
for Python3.12 issues.

Kind regards
Andreas.


[1]https://salsa.debian.org/science-team/segyio/-/jobs/5338110

Am Wed, Feb 21, 2024 at 11:42:58AM +0100 schrieb Tino Didriksen:
> std::uint16_t is in #include 
> 
> stdint.h is the C header, which doesn't import the symbols to the std::
> namespace. In general, the headers Standard C++ imports from Standard C
> snips the .h and prefixes c, so stdint.h -> cstdint, stdio.h -> cstdio, etc.
> 
> -- Tino Didriksen
> 
> 
> On Wed, 21 Feb 2024 at 11:16, Andreas Tille  wrote:
> 
> > Hi,
> >
> > I've found in the set of patches for segyio other cherry-picked patches
> > to adapt to certain Python3.x versions[1].  The patch kindly suggested
> > by s3v to fix this bug[2] would simply be another cherry-pick from upstream
> > who has meanwhile released a couple of new versions incorporating all
> > patches we seem to need for Python3.12 - thus by upgrading to latest
> > upstream the current bug would be fixed.
> >
> > Usually I would do this in case of team maintained packages but I faced
> > some problems with latest upstream and thus I simply created a branch
> > version_1.9.12 with all proposed changes including current packaging
> > standards and fixing a further bug.  Unfortunately the build system is
> > all but smooth compared to other packages and I finally stumbled upon
> > a C++ conversion issue[4] which is not solved by simply adding
> >#include 
> > and my further attempt leads to a test suite issue which seems to
> > indicate that my poor C++ understanding is wrong.
> >
> > So I'm giving up here by leaving two questions:
> >
> >1. Anybody up for fixing this package and bringing it to latest
> >   upstream?
> >2. Alternatively do we want to drop this package from Debian?
> >
> > Kind regards
> > Andreas.
> >
> >
> > [1]
> > https://salsa.debian.org/science-team/segyio/-/tree/master/debian/patches?ref_type=heads
> > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055728#14
> > [3]
> > https://salsa.debian.org/science-team/segyio/-/tree/version_1.9.12?ref_type=heads
> > [4]
> > https://salsa.debian.org/science-team/segyio/-/blob/version_1.9.12/debian/patches/gcc-13.patch?ref_type=heads#L6-9
> >
> > --
> > http://fam-tille.de
> >
> >

-- 
http://fam-tille.de

Segyio is lagging behind upstream (Was: segyio ftbfs with Python 3.12)

[Andreas Tille]

Hi,

I've found in the set of patches for segyio other cherry-picked patches
to adapt to certain Python3.x versions[1].  The patch kindly suggested
by s3v to fix this bug[2] would simply be another cherry-pick from upstream
who has meanwhile released a couple of new versions incorporating all
patches we seem to need for Python3.12 - thus by upgrading to latest
upstream the current bug would be fixed.

Usually I would do this in case of team maintained packages but I faced
some problems with latest upstream and thus I simply created a branch
version_1.9.12 with all proposed changes including current packaging
standards and fixing a further bug.  Unfortunately the build system is
all but smooth compared to other packages and I finally stumbled upon
a C++ conversion issue[4] which is not solved by simply adding
   #include 
and my further attempt leads to a test suite issue which seems to
indicate that my poor C++ understanding is wrong.

So I'm giving up here by leaving two questions:

   1. Anybody up for fixing this package and bringing it to latest
  upstream?
   2. Alternatively do we want to drop this package from Debian?

Kind regards
Andreas.


[1] 
https://salsa.debian.org/science-team/segyio/-/tree/master/debian/patches?ref_type=heads
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055728#14
[3] 
https://salsa.debian.org/science-team/segyio/-/tree/version_1.9.12?ref_type=heads
[4] 
https://salsa.debian.org/science-team/segyio/-/blob/version_1.9.12/debian/patches/gcc-13.patch?ref_type=heads#L6-9

-- 
http://fam-tille.de

Re: Team-maintenance of visidata in Debian Science team (Was: visidata: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13)

[Andreas Tille]

Hi Anja,

Am Thu, Feb 08, 2024 at 02:55:21PM -0800 schrieb Anja:
> We actually already do have a sponsor, and we're going to be upgrading very
> soon! We just wanted to make sure the build was stable.

That's good to hear.
 
> >  While I have no idea for a fix my first attempt would be to update to
> the latest upstream version and see whether the bug might be fixed.
> 
> Yes, it is fixed in upstream!

Vera good.

> Thanks for reaching out,

I admit I insist that joining some team has additional advantages for
instance some contact with other maintainers working in the same field.
For instance it might make your package more visible.  In any case I've
added your package to the Debian Science Blends tasks which will add it
to the packages science-datamanagement (once the next version of  Debian
Science metapackages will be released) and added it to the web sentinel
page right now[1].

> Anja

Kind regards
 Andreas.

[1] https://blends.debian.org/science/tasks/datamanagement#visidata
 
> On Thu, 8 Feb 2024 at 04:45, Andreas Tille  wrote:
> 
> > Hi Anja,
> >
> > when analysing Python3.12 bugs like this I stumbled upon visidata.
> > While I have no idea for a fix my first attempt would be to update to
> > the latest upstream version and see whether the bug might be fixed.
> >
> > I would love to help out (with such an upgrade or sponsoring the
> > package.)  However, my personal policy is to touch team maintained
> > packages only.  In the case of visidata I'd suggest Debian Science team
> > (list in CC).  Just let us know what you think.  If you agree I would
> > volunteer to move the Git archive to science-team and sponsor an upload.
> >
> > Kind regards
> > Andreas.
> >
> > --
> > http://fam-tille.de
> >

-- 
http://fam-tille.de

Team-maintenance of visidata in Debian Science team (Was: visidata: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13)

[Andreas Tille]

Hi Anja,

when analysing Python3.12 bugs like this I stumbled upon visidata.
While I have no idea for a fix my first attempt would be to update to
the latest upstream version and see whether the bug might be fixed.

I would love to help out (with such an upgrade or sponsoring the
package.)  However, my personal policy is to touch team maintained
packages only.  In the case of visidata I'd suggest Debian Science team
(list in CC).  Just let us know what you think.  If you agree I would
volunteer to move the Git archive to science-team and sponsor an upload.

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Bug#1043240: transition: pandas 1.5 -> 2.1 - please upload fixes

[Andreas Tille]

Hi again,

Am Fri, Feb 02, 2024 at 09:56:14PM +0100 schrieb Andreas Tille:
> Hi Rebecca,
> 
> Am Tue, Jan 30, 2024 at 08:05:35AM + schrieb Rebecca N. Palmer:
> > I intend to upload pandas 2.x to unstable soon.  These packages have a patch
> > in their bug - please upload them (I'm a DM, I can't do that), or if you
> > think this patch won't work or isn't a good idea, tell me why:
> > dials
> 
> Was uploaded, all bugs closed.
> 
> > python-altair
> 
> I tried hard to get the latest version which implements what you suggested
> independently in the bug report.  Unfortunately it needs a new dependency
> as I wrote in my comment in the bug report[2] and I was not able to easily
> exclude the test that fails due to the missing module.

Maybe I'd rather revert to the version currently in Debian.  I might check
later if nobody will beat me.
 
> > python-feather-format

I've followed the hint given by Rebecca.  Unfortunately there are new Cython
issues as you can see in Salsa CI[1].  Any hint would be welcome.

> > seaborn

Discussed in other mails

> > tqdm
> 
> I try to check later.

Kind regards
Andreas.


[1] 
https://salsa.debian.org/python-team/packages/python-feather-format/-/jobs/5246082
 

-- 
http://fam-tille.de

Re: Bug#1043240: transition: pandas 1.5 -> 2.1 - please upload fixes

[Andreas Tille]

Hi Rebecca,

Am Tue, Jan 30, 2024 at 08:05:35AM + schrieb Rebecca N. Palmer:
> I intend to upload pandas 2.x to unstable soon.  These packages have a patch
> in their bug - please upload them (I'm a DM, I can't do that), or if you
> think this patch won't work or isn't a good idea, tell me why:
> dials

Was uploaded, all bugs closed.

> influxdb-python

I've answered to the bug[1] that the hints you gave seem to be incomplete.
Unfortunately I have no idea how to fix this.

> python-altair

I tried hard to get the latest version which implements what you suggested
independently in the bug report.  Unfortunately it needs a new dependency
as I wrote in my comment in the bug report[2] and I was not able to easily
exclude the test that fails due to the missing module.

> python-feather-format seaborn tqdm

I try to check later.
 
> In particular, I'd like the seaborn fix uploaded before pandas, so I can set
> Breaks for it.  (The pandas documentation build-depends on seaborn.)

I will check soon as long as noone will beat me in doing so.

Kind regards and thanks for all your work on pandas
   Andreas.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1044076#43
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1044073#23

-- 
http://fam-tille.de

Re: Bug#1061828: r-cran-plotly: Can't create any plots

[Andreas Tille]

Hi again,

Am Tue, Jan 30, 2024 at 08:58:58PM +0100 schrieb Przemysław Kopa:
> 
> $ head -n 6 plotly_cran/lib/plotly-main-2.11.1/plotly-latest.min.js
> /**
> * plotly.js v2.11.1
> * Copyright 2012-2022, Plotly, Inc.
> * All rights reserved.
> * Licensed under the MIT license
> */

I've updated plotly.js from upstream[1] to its latest version (2.28.0)
and hope this is working nicely now (in Debian package 4.10.4+dfsg-2
just uploaded to unstable).

If you want to make sure the plotly Debian package works always as
expected I would love if you could try to convince CRAN plotly authors
to include the uncompressed plotly.js source in their download tarball.
In Debian compressed JS is considered binary without source.  Thus I
have to remove the compressed file and fetch the uncompressed one from
upstream.  Unfortunately I do not do this routinely when upgrading the
plotly package which caused the observed problem.

In any case thanks for your bug report and the accordin investigation
   Andreas.


[1] https://github.com/plotly/plotly.js 

-- 
http://fam-tille.de

Re: Bug#1061828: r-cran-plotly: Can't create any plots

[Andreas Tille]

Hi Przemysław,

Am Tue, Jan 30, 2024 at 08:58:58PM +0100 schrieb Przemysław Kopa:
> I've done some investigation. If you uninstall r-cran-plotly and then
> install plotly directly from CRAN (same version), then the plot from the
> example renders correctly:

Thanks a lot, that's extremely helpful.  I'll try to tackle this problem
tomorrow.

Kind regards
Andreas.
 
> $ sudo apt remove r-cran-plotly
> > install.packages(pkgs =
> "https://cran.r-project.org/package=plotly&version=4.10.1";, repos = NULL)
> > library(plotly)
> > plot_ly(data = iris, x = ~Sepal.Length, y = ~Petal.Length) # works fine!
> 
> I've run the above example firstly with r-cran-plotly installed and then
> with the CRAN version installed to see the differences in resulting
> files. The only files that differ are 'index.html', 'plotly-latest.min.js'
> and 'typedarray.min.js'.
> 
> $ diff -qr plotly_packaged plotly_cran
> Files plotly_packaged/index.html and plotly_cran/index.html differ
> Files plotly_packaged/lib/plotly-main-2.11.1/plotly-latest.min.js and
> plotly_cran/lib/plotly-main-2.11.1/plotly-latest.min.js differ
> Files plotly_packaged/lib/typedarray-0.1/typedarray.min.js and
> plotly_cran/lib/typedarray-0.1/typedarray.min.js differ
> 
> HTML files are essentially identical, the only difference between them
> lays in object id attributes, which are generated randomly. On the other
> hand, plotly and typedarray js files are completely different and CRAN
> versions appear to be newer, for example:
> 
> $ head -n 6 plotly_cran/lib/plotly-main-2.11.1/plotly-latest.min.js
> /**
> * plotly.js v2.11.1
> * Copyright 2012-2022, Plotly, Inc.
> * All rights reserved.
> * Licensed under the MIT license
> */
> 
> $ head -n 6 plotly_packaged/lib/plotly-main-2.11.1/plotly-latest.min.js
> /**
> * plotly.js v1.31.2
> * Copyright 2012-2017, Plotly, Inc.
> * All rights reserved.
> * Licensed under the MIT license
> */
> 
> Therefore, I think there must be a problem with 'plotly-latest.min.js'
> and 'typedarray.min.js' that are packaged in r-cran-plotly. Hope this
> helps!
> 
> Kind regards,
> Przemyslaw
> 

-- 
http://fam-tille.de

Re: Bug#1061828: r-cran-plotly: Can't create any plots

[Andreas Tille]

Control: tags -1 help

Hi Przemyslaw,

thanks a lot for your bug report.  Its a schame that you have issues
with the packaged version of plotly.

Am Mon, Jan 29, 2024 at 09:36:55PM +0100 schrieb Przemyslaw Kopa:
>Tried a simple scatterplot example:
> 
>library(plotly)
>plot_ly(data = iris, x = ~Sepal.Length, y = ~Petal.Length)
> 
>* What was the outcome of this action?
> 
>Web browser opened with an empty page instead of a plot and there 
>were many JS errors in browser's console. Plotly.js version that comes 
>bundled with r-cran-plotly is very old, which is probably the cause of 
>those errors. Tried also 4.10.4 from testing - same result.

I confirm I can reproduce the problem.

When checking the html page source I get

...








...

So its not really sure what actual package is responsible for the
problem which ca also be caused by crosstalk, htmlwidgets, a non-fitting
jquery etc.

I've checked the browser console and can see things like

NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 
(NS_ERROR_NOT_IMPLEMENTED) [nsIAppStartup.secondsSinceLastOSRestart]
_collectStartupConditionsTelemetry 
resource:///modules/BrowserGlue.sys.mjs:1609
BG__onFirstWindowLoaded resource:///modules/BrowserGlue.sys.mjs:1717
BG_observe resource:///modules/BrowserGlue.sys.mjs:962
_delayedStartup chrome://browser/content/browser.js:2076
update.locale  file doesn't exist in either the application or GRE directories 
UpdateUtils.sys.mjs:135:13
getLocale resource://gre/modules/UpdateUtils.sys.mjs:135
Given tab is not restoring. SessionStore.sys.mjs:6035:15
_resetLocalTabRestoringState 
resource:///modules/sessionstore/SessionStore.sys.mjs:6035
_restoreTabContentComplete 
resource:///modules/sessionstore/SessionStore.sys.mjs:6597
_restoreTabContent 
resource:///modules/sessionstore/SessionStore.sys.mjs:6468

I admit for the moment I do not have any idea and no clue what this
might mean.  Any help would be welcome.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: can I help with pyvista packaging?

[Andreas Tille]

Hi Francesco,

Am Mon, Jan 29, 2024 at 03:37:32PM +0100 schrieb Francesco Ballarin:
> Thanks Andreas, I'll reply below

That's very convinient and normal on Debian lists.  Please also be aware
that on Debian lists it policy to not CC people.  While nobody will
blame you here on Debian Science list about not following this (and I do
so intentionally since I do not know whether you are subscribed) I just
tell you so since you are a newcomer and maybe you will run into a
situation on some other mailing list where someone might give you some
not so friendly advise about this. ;-)

> On Mon, Jan 29, 2024 at 9:18 AM Andreas Tille  wrote:
> > Maybe its a good thing to discuss this issue at
> > debian-pyt...@lists.debian.org (keeping the actual uploaders Gorden and
> > Ximin in CC) to check out the blockers for the migration.  Finally we
> > need to make sure that we will not lag too much behind upstream.
> >
> 
> Agreed. I'll wait a couple more days to see if the person I asked
> replies, and after that I'll post to the debian-python list.

Debian-python is also a very well fitting list.
 
> > Alternatively there is debian/README.source
> 
> Yes, sorry, I confused the two REAMDEs. I was thinking about README.source

No problem.  I was just mentioning alteratives since not everybody reads
README.source under every circumstance.  That's why I also drop a note
into d/changelog if its very important knowledge for other team members.
 
> > I admit I do not fully understand what you mean.  Why not adding
> > versioned Build-Depends and let dpkg check the proper versions?
> 
> Will do. It will probably be easier to explain what I was trying to
> say once I've actually done it, so if needed we'll come back to this
> point after I've started working on it.

Perfect.
 
> > No.  Just create another binary package containing just the
> > dependencies.  That's fine.
> 
> Will do, thanks!

You are welcome.
 
> I'll keep you up to date on the progress,

Thanks a lot for your work on this

Andreas. 

-- 
http://fam-tille.de

Re: can I help with pyvista packaging?

[Andreas Tille]

server
> > trame-vtk
> > trame-vuetify
> > =
> >
> > under the science team?
> >
> > If so, can you please manually add me to each one of those with the
> > highest possible gitlab permissions, so that I can tweak salsa CI?
> > (I am in the science group and therefore I can access every science
> > team repo, but only with the lowest gitlab permissions)
> >
> > It's probably going to take me a bit longer with trame, because I
> > don't have as much experience with it as with pyvista, but I'd like to
> > get started in the next few days.
> >
> > Cheers,
> > Francesco
> >
> > On Sat, Jan 27, 2024 at 11:34 PM Andreas Tille  wrote:
> > >
> > > Hi Francesco,
> > >
> > > thanks a lot for the fix - the package is uploaded to new.
> > >
> > > Kind regards
> > >Andreas.
> > >
> > > Am Sat, Jan 27, 2024 at 10:23:20PM +0100 schrieb Francesco Ballarin:
> > > > A first version is available at
> > > > https://salsa.debian.org/science-team/python-pyvista
> > > > in case you want to have a look before I/we change it from UNRELEASED
> > > > to unstable.
> > > >
> > > > autopkgtest passes.
> > > > test-crossbuild-arm64 is failing, but is allowed to do so, not sure if
> > > > it is relevant.
> > > >
> > > > As agreed, interactive plotting within jupyter is not considered for 
> > > > now.
> > > >
> > > > Cheers,
> > > > Francesco
> > > >
> > > >
> > > > On Sat, Jan 27, 2024 at 7:08 PM Andreas Tille  wrote:
> > > > >
> > > > > Am Sat, Jan 27, 2024 at 06:28:14PM +0100 schrieb Francesco Ballarin:
> > > > > > OK Andreas, I'll push to master. Let me take the lead on that, and 
> > > > > > I'll come back to you and Drew with progress and questions.
> > > > >
> > > > > Perfectly fine for me.
> > > > >
> > > > > > I think I have some ideas on how to get started on the basic 
> > > > > > package.
> > > > > >
> > > > > > The full package (i.e., all optional components that one can 
> > > > > > install with "pip install pyvista[all]") will be much more complex, 
> > > > > > because it depends on trame, which comes split in five 
> > > > > > interdependent packages
> > > > > > 
> > > > > > trame3.2.4
> > > > > > trame-client 2.11.2
> > > > > > trame-server 2.11.7
> > > > > > trame-vtk2.5.8
> > > > > > trame-vuetify2.3.1
> > > > > > 
> > > > > > and who knows how many dependencies each one of those have.
> > > > >
> > > > > Sounds complex and I'd love to stay in background given that I need to
> > > > > care for >1000 packages.
> > > > >
> > > > > > Down the line I'd want to have that too, because that's what I 
> > > > > > actually need for plotting within jupyter notebooks in my 
> > > > > > libraries, see for instance
> > > > > > https://viskex.github.io/tutorials/01_introduction/tutorial_plot_subdomains_3d_dolfinx.html
> > > > > > but let's start with a less ambitious goal ;)
> > > > >
> > > > > +1
> > > > >
> > > > > > I think that the error you see is because python3-vtk9 is only 
> > > > > > built for python 3.11, but unit tests are getting run with python 
> > > > > > 3.12.
> > > > > > At the moment, I'd like to disable that part adding an empty 
> > > > > > override_dh_auto_test-indep and run tests with autopkgtest only, so 
> > > > > > that I can have a clearer idea on the difference between 
> > > > > > dependencies required for building the package vs dependencies 
> > > > > > required for testing it, because I know from experience that there 
> > > > > > are a few packages that are only needed for testing pyvista.
> > > > >
> > > > > Perfectly fine for me.  Feel free to turn the RFP in ITP and I can
> > > > > sponsor the upload if needed.
> > > > >
> > > > > Thanks a lot for your help
> > > > > Andreas.
> > > > >
> > > > > --
> > > > > http://fam-tille.de
> > > > [http://static.unicatt.it/ext-portale/5xmille_firma_mail_2023.jpg] 
> > > > <https://www.unicatt.it/uc/5xmille>
> > > >
> > > >
> > >
> > > --
> > > http://fam-tille.de
> [http://static.unicatt.it/ext-portale/5xmille_firma_mail_2023.jpg] 
> <https://www.unicatt.it/uc/5xmille>
> 
> 

-- 
http://fam-tille.de

How can we deal with lots of RC bugs as a team (and do we need critterding as one example)

[Andreas Tille]

Hi,

in the Debian Med team we dedicate the time before Christmas in a so
called "Advent bug squashing party" to bug fixing.  Every team member
simply picks bugs from our list of bugs no matter whether these are
"own" packages (in terms of the bug fixer is Uploader) or not.  Since
I tried to fix some Python3.12 related packages I was also searching
the list of Debian Science bugs[1] and found quite some easy to fix
RC bugs.

When stumbling about the bugs in critterding[2] I realised that the
"latest" beta which was released more than 10 years ago (so upstream
seems to be definitely dead) has two RC bugs while the version in
unstable depends on old toolkits (qt4, SDL 1.2) and thus need to be
ported sooner or later which will be the task of the Debian maintainer
(Gabriele is Uploader of this package and in CC) which I doubt
considering the last upload was in 2016.  This is just one example which
I stumbled upon.  IMHO we should remove this package from Debian since I
do not see any realistic chance to keep it.  This is just a suggestion -
if someone disagrees with it since there are some votes in popcon[3] I'm
fine with it, but there should be someone who actively cares for the
bugs in this package.

As I said this is just an example.  In my investigation I've found lots
of packages with easy to fix RC bugs - some simply by upgrading to the
latest upstream version.  Since I dedicate most of my time to Debian Med
and its preconditions I can't continue my bug hunting effort in Debian
Science in the same manner as I did the last week.  However, I think we
should agree as a team to some means to care for our team packages -
or spot some candidates for removal if we don't have the power to do
proper maintenance.

Kind regards
   Andreas.

[1] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-science-maintain...@lists.alioth.debian.org
[2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=critterding
[3] 
https://qa.debian.org/popcon-graph.php?packages=critterding&show_vote=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

-- 
http://fam-tille.de

Re: Bug#1043240: transition: pandas 1.5 -> 2.1

[Andreas Tille]

Hi Rebecca,

Am Sun, Jan 21, 2024 at 03:29:21PM + schrieb Rebecca N. Palmer:
> 
> Hence, doing this transition now would involve breaking some reverse
> dependencies with no known fix, but given the number of packages involved,
> trying to wait until they're all fixed is rather likely to instead end in
> pandas 1.5 being broken by a new Python/numpy/etc.

Just go for it and lets try to fix issues as soon as possible.

Thanks a lot for all your work on pandas

 Andreas.

-- 
http://fam-tille.de

Re: python-sparse's autopkg tests fail with Python 3.12

[Andreas Tille]

Hi Nilesh,

Am Sat, Jan 13, 2024 at 04:15:07PM +0530 schrieb Nilesh Patra:
> Fixed in Git, please check.

Thanks a lot.  I'll wait for debci whether bug #1055847 persists.

I wonder whether we could close simply #1058485 since the test is passing
with current numba.

Kind regards
 Andreas.

-- 
http://fam-tille.de

Re: python-sparse's autopkg tests fail with Python 3.12

[Andreas Tille]

Hi,

thanks to Rebecca's hint I've updated python-sparse in Git to the latest
upstream version.  I decided to deactivate all patches.  When trying to build
I'm running into several errors:

  ModuleNotFoundError: No module named 'sparse._version'   [1]

This is surely due to the removal of versioneer in upstream commit
6fca42bc1cd0acea2153b074658b834231a4d00f  - but I can't imaginge upstream
simply left the according responsible line

sparse/__init__.py:from ._version import __version__, __version_tuple__  # 
noqa: F401

and did not noticed that tests are failing.  Am I missing something?

Kind regards
Andreass.

[1] ModuleNotFoundError: No module named 'sparse._version'

-- 
http://fam-tille.de

Debian Med sprint February 16.-18. 2024 in Berlin (in person meeting)

[Andreas Tille]

Hi,

the Debian Med team will held its yearly in person meeting from Friday,
February 16 (evening) until Sunday, February 18 (evening) in Berlin.
For more detailed information please visit the Wiki page[1] and if you
like to join our small meeting with bug squashing (may be Python 3.12
bug fixing etc.) you are perfectly welcome to add your name to the list
of attendees.

Looking forward to see you all

 Andreas.

[1] https://wiki.debian.org/Sprints/2023/DebianMed2024

-- 
http://fam-tille.de

Re: build-depends on atlas, which is obsolete and scheduled for removal

[Andreas Tille]

Control: tags -1 help

[Ritika Ramani in CC to inform that Debian tries to get rid of Atlas
 which also affects phast. see https://bugs.debian.org/1056681]

Hi,

I tried to replace clapack by LAPACKE.  Unfortunately this is not a
drop-in replacement.  As you can see in the raw(! normal log is to
long!) build log on Salsa[1] when seeking for the string
  too few arguments to function
you see

...
phast_eigen.c: In function 'mat_diagonalize':
phast_eigen.c:62:3: error: too few arguments to function 'dgeev_'
   62 |   dgeev_(&jobvl, &jobvr, &n, tmp, &n, wr, wi, vl,
  |   ^~
In file included from /usr/include/lapack.h:11,
 from 
/builds/med-team/phast/debian/output/source_dir/src/../include/phast/external_libs.h:43,
 from 
/builds/med-team/phast/debian/output/source_dir/src/../include/phast/vector.h:19,
 from 
/builds/med-team/phast/debian/output/source_dir/src/../include/phast/matrix.h:18,
 from 
/builds/med-team/phast/debian/output/source_dir/src/../include/phast/eigen.h:18,
 from phast_eigen.c:18:
/usr/include/lapack.h:1828:6: note: declared here
 1828 | void LAPACK_dgeev_base(
  |  ^
phast_eigen.c: In function 'mat_eigenvals':
phast_eigen.c:199:3: error: too few arguments to function 'dgeev_'
  199 |   dgeev_(&jobvl, &jobvr, &n, tmp, &n, wr, wi, NULL,
  |   ^~
...


Seems the LAPACKE function is differently defined than the clapack
function.  Any help is really appreciated.

Note: There might be a chance to define SKIP_LAPACK and by doing so do
not build with some performance drain.  However, I'd prefer if we could
provide phast with the speed users might expect.

Kind regards
   Andreas.
[1] https://salsa.debian.org/med-team/phast/-/jobs/4979980/raw

-- 
http://fam-tille.de

Help for emmax needed (Was: Removing ATLAS?)

[Andreas Tille]

Control: tags -1 help

Hi,

Am Fri, Jul 14, 2023 at 01:40:22AM +0200 schrieb Sébastien Villemot:
> Le lundi 10 juillet 2023 à 22:01 +0200, Andreas Tille a écrit :
> > I've checked my responsibility for the dependencies and stumbled about
> > emmax
> > 
> > 
> > emmax.c:10:10: fatal error: clapack.h: No such file or directory
> >10 | #include 
> >   |  ^~~
> > compilation terminated.
> > ...
> 
> clapack.h is apparently an early attempt at providing a C interface to
> some LAPACK functions (which are in Fortran). It indeed looks ATLAS-
> specific.
> 
> The modern solution for that problem is to use LAPACKE (note the final
> “E”), which is provided by liblapacke-dev. It is a standardized and
> maintained C interface to all LAPACK routines.
> 
> I guess it should be feasible to adapt emmax to make it work with
> LAPACKE.

I tried to do so in Salsa.  Unfortunately LAPACKE is not a drop in
replacement and I'm lacking the necessary knowledge about all these
LAPACK implementations.  For instance I have no idea how to fix the
error you can see in Salsa CI[1] which has

...
emmax.c: In function 'dsyevd':
emmax.c:1633:17: error: conflicting types for 'dsyevd_'; have 'void(char *, 
char *, int *, double *, int *, double *, double *, int *, int *, int *, int *)'
 1633 |   extern  void  dsyevd_ (char *JOBZp, char *UPLOp, int *Np,
  | ^~~
In file included from /usr/include/lapack.h:11,
 from emmax.c:10:
/usr/include/lapack.h:17096:6: note: previous declaration of 'dsyevd_' with 
type 'void(const char *, const char *, const int32_t *, double *, const int32_t 
*, double *, double *, const int32_t *, int32_t *, const int32_t *, int32_t *, 
size_t,  size_t)' {aka 'void(const char *, const char *, const int *, double *, 
const int *, double *, double *, const int *, int *, const int *, int *, long 
unsigned int,  long unsigned int)'}
17096 | void LAPACK_dsyevd_base(
  |  ^~
emmax.c: In function 'dsyevr':
emmax.c:1652:17: error: conflicting types for 'dsyevr_'; have 'void(char *, 
char *, char *, int *, double *, int *, double *, double *, int *, int *, 
double *, int *, double *, double *, int *, int *, double *, int *, int *, int 
*, int *)'
 1652 |   extern  void  dsyevr_ (char *JOBZp, char *RANGEp, char *UPLOp, int 
*Np,
  | ^~~

Looking at the last line of this snippet (line 901 in the linked CI
log[1]) the parameter char *RANGEp is not part of the declaration of
LAPACK_dsyevd_base given in line 17096 of /usr/include/lapack.h.

I admit this is hard to solve for me and I would love if someone
with some knowledge of LAPACK could provide some patch.  A similar
issue exists for dgetrf.

Any help would be appreciated.

Kind regards
   Andreas.

[1] https://salsa.debian.org/med-team/emmax/-/jobs/4977705#L901

-- 
http://fam-tille.de

Re: Please push your changes to python-xarray

[Andreas Tille]

Am Mon, Nov 13, 2023 at 09:21:09AM -0500 schrieb Aaron M. Ucko:
> FWIW, it looks like gbp import-dscs --debsnap should lose less
> historical detail than a single mass commit.


$ gbp import-dscs --debsnap --pristine-tar --create-missing-branches 
python-xarray
gbp:info: Downloading snapshots of 'python-xarray' to '/tmp/tmp1juarxv5'...
gbp:info: No git repository found, creating one.
gbp:info: Version '0.9.1+ds1-1' imported under '/tmp/python-xarray'
gbp:info: Version '0.9.2-1' imported under '/tmp/python-xarray'
gbp:info: Version '0.9.6-1' imported under '/tmp/python-xarray'
gbp:info: Creating missing branch 'upstream/latest'
gbp:error: Git command failed: Error running git branch: Schwerwiegend: cannot 
lock ref 'refs/heads/upstream/latest': 'refs/heads/upstream' existiert; kann 
'refs/heads/upstream/latest' nicht erstellen
gbp:error: Failed to import '/tmp/tmp1juarxv5/python-xarray_0.9.1+ds1-1.dsc'



I admit my intention is to fix the bug inside the package not spending
my time on fixing the repository.  Any volunteer to make the commit more
granularly?  (Please no hints what I could do - just fixing the
repository would be really welcome.)

Kind regards
   Andreas.

 
> Alastair McKinstry  writes:
> 
> > Hi
> >
> > Apologies I am swamped on this. Please go ahead and apply.
> >
> > Thanks
> > Alastair
> >
> > On 13/11/2023 12:51, Andreas Tille wrote:
> >> Ping?
> >>
> >> I'd love to apply the patch from the bug report and push everything 
> >> properly.
> >> If I do not hear from you I might consider mass-commiting all the releases
> >> you made without pushing to the repository in one single commit and add 
> >> what
> >> I'd like to commit.
> >>
> >> Kind regards
> >>  Andreas.
> >>
> >> Am Tue, Nov 07, 2023 at 09:26:13AM +0100 schrieb Andreas Tille:
> >>> Hi Alastair,
> >>>
> >>> I realised that the Git repository on salsa[1] is lagging a couple of
> >>> uploads behind the package pool.  Please be so kind to push your changes
> >>> to Salsa.
> >>>
> >>> Thanks a lot for your work on this package
> >>>  Andreas.
> >>>
> >>> [1] https://salsa.debian.org/science-team/python-xarray
> >>>
> >>> -- http://fam-tille.de
> 

-- 
http://fam-tille.de

Re: Please push your changes to python-xarray

[Andreas Tille]

Ping?

I'd love to apply the patch from the bug report and push everything properly.
If I do not hear from you I might consider mass-commiting all the releases
you made without pushing to the repository in one single commit and add what
I'd like to commit.

Kind regards
Andreas.

Am Tue, Nov 07, 2023 at 09:26:13AM +0100 schrieb Andreas Tille:
> Hi Alastair,
> 
> I realised that the Git repository on salsa[1] is lagging a couple of
> uploads behind the package pool.  Please be so kind to push your changes
> to Salsa.
> 
> Thanks a lot for your work on this package
> Andreas.
> 
> [1] https://salsa.debian.org/science-team/python-xarray
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Please push your changes to python-xarray

[Andreas Tille]

Hi Alastair,

I realised that the Git repository on salsa[1] is lagging a couple of
uploads behind the package pool.  Please be so kind to push your changes
to Salsa.

Thanks a lot for your work on this package
Andreas.

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

-- 
http://fam-tille.de

r-cran-stanheaders seems to use old tbb interface instead of onetbb

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/stan-dev/rstan/issues/1101

Hi,

I opened an issue on StanHeaders upstream about an issue with rstan and
rstanarm.  Any help (patch) to port StanHeaders to the new onetbb
interface would be welcome.

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Removing ATLAS?

[Andreas Tille]

Hi Rafael,

Am Wed, Jul 12, 2023 at 03:34:09PM +0200 schrieb Rafael Laboissière:
> When generating the C++ code, the xmds tool tries to link against
> libcblas.so, which, currently, only exists in the libatlas-base-dev package.

I admit this is actually the reason why any of the packages I'm maintaining
depends from libatlas-base-dev:  These are linking against libcblas which is
only provided in this package.  If we might find a way to provide some kind
of "wrapper" so other implementations could provide libcblas as well, this
could be some generic solution.  Unfortunately I'm probably pretty naive
and I'm asking for the impossible.
 
Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Removing ATLAS?

[Andreas Tille]

Hi Steffen,

Am Tue, Jul 11, 2023 at 10:02:53AM +0200 schrieb Steffen Möller:
> EMMAX is (was) important
> https://genome.sph.umich.edu/wiki/EMMAX
> 
> but I admittedly cannot invest into maintaining this or atlas.

Sure we can't maintain this.

> My suggestion would be to talk back to upstream about transitioning to an 
> alternative. I have no idea about how difficult this would be to patch 
> ourselves.

Do you have some contact to upstream?  The version number is
 beta-07Mar2010
 
which is usually a sign that upstream has orphaned this code long
ago.  If you can reach upstream it would be great if you could ping
them somehow.

Kind regards
 Andreas.

> Best,
> Steffen
> 
> > Gesendet: Montag, 10. Juli 2023 um 22:01 Uhr
> > Von: "Andreas Tille" 
> > An: debian-science@lists.debian.org
> > Betreff: Re: Removing ATLAS?
> >
> > Hi Sébastian,
> > 
> > Am Sat, Jul 08, 2023 at 10:01:15AM +0200 schrieb Sébastien Villemot:
> > > 
> > > So, given all that, I’m inclined to (try to) remove atlas during the
> > > trixie development cycle.
> > 
> > Sounds reasonable.
> >  
> > > Any thought on this?
> > 
> > I've checked my responsibility for the dependencies and stumbled about
> > emmax
> > 
> > 
> > emmax.c:10:10: fatal error: clapack.h: No such file or directory
> >10 | #include 
> >   |  ^~~
> > compilation terminated.
> > 
> > 
> > and noticed
> > 
> > $ apt-file search clapack.h
> > libatlas-base-dev: /usr/include/x86_64-linux-gnu/clapack.h
> > ... (other instances are not blas related)
> > 
> > which was probably the reason why I've picked libatlas-base-dev
> > originally.  I would not say that emmax is important and its
> > also a not maintained upstream any more.  However, I vaguely
> > remember that this
> >#include 
> > in some code pieces of Debian Med was the reason to actually
> > pick this blas implementation.  Any hint how to deal with such
> > cases?
> >  
> > Kind regards
> > Andreas.
> >  
> > > Checking reverse dependencies...
> > > # Broken Depends:
> > > ceres-solver: libceres-dev
> > >   libceres3
> > > colmap: colmap [amd64 arm64 i386 mips64el mipsel ppc64el s390x]
> > > dune-common: libdune-common-dev
> > > emmax: emmax
> > > ergo: ergo
> > > iml: libiml0
> > > nipy: python3-nipy-lib [armel mipsel]
> > > psfex: psfex
> > > python-escript: python3-escript [armel mipsel]
> > > python3-escript-mpi [armel mipsel]
> > > qm-dsp: libqm-dsp0
> > > scamp: scamp [amd64 arm64 mips64el ppc64el s390x]
> > > scikit-misc: python3-skmisc
> > > sight: libsight [amd64]
> > > source-extractor: source-extractor
> > > xmds2: xmds2
> > > 
> > > # Broken Build-Depends:
> > > ceres-solver: libatlas-base-dev
> > > dune-common: libatlas-base-dev
> > > emmax: libatlas-base-dev
> > >libatlas3-base
> > > ergo: libatlas-base-dev
> > > ghmm: libatlas-base-dev
> > > halide: libatlas-base-dev
> > > hpcc: libatlas-base-dev
> > > iml: libatlas-base-dev
> > > ncl: libatlas3-base
> > > odin: libatlas-base-dev
> > > opm-material: libatlas-base-dev
> > > phast: libatlas-base-dev
> > > plink1.9: libatlas-base-dev
> > > plink2: libatlas-base-dev
> > > psfex: libatlas-base-dev
> > > qm-dsp: libatlas-base-dev
> > > scamp: libatlas-base-dev
> > > scikit-misc: libatlas-base-dev
> > > source-extractor: libatlas-base-dev
> > > theli: libatlas-base-dev
> > > xmds2: libatlas-base-dev
> > > 
> > > Dependency problem found.
> > > 
> > 
> > 
> > 
> > 
> > -- 
> > http://fam-tille.de
> > 
> >
> 
> 

-- 
http://fam-tille.de

Re: Removing ATLAS?

[Andreas Tille]

Hi Sébastian,

Am Sat, Jul 08, 2023 at 10:01:15AM +0200 schrieb Sébastien Villemot:
> 
> So, given all that, I’m inclined to (try to) remove atlas during the
> trixie development cycle.

Sounds reasonable.
 
> Any thought on this?

I've checked my responsibility for the dependencies and stumbled about
emmax


emmax.c:10:10: fatal error: clapack.h: No such file or directory
   10 | #include 
  |  ^~~
compilation terminated.


and noticed

$ apt-file search clapack.h
libatlas-base-dev: /usr/include/x86_64-linux-gnu/clapack.h
... (other instances are not blas related)

which was probably the reason why I've picked libatlas-base-dev
originally.  I would not say that emmax is important and its
also a not maintained upstream any more.  However, I vaguely
remember that this
   #include 
in some code pieces of Debian Med was the reason to actually
pick this blas implementation.  Any hint how to deal with such
cases?
 
Kind regards
Andreas.
 
> Checking reverse dependencies...
> # Broken Depends:
> ceres-solver: libceres-dev
>   libceres3
> colmap: colmap [amd64 arm64 i386 mips64el mipsel ppc64el s390x]
> dune-common: libdune-common-dev
> emmax: emmax
> ergo: ergo
> iml: libiml0
> nipy: python3-nipy-lib [armel mipsel]
> psfex: psfex
> python-escript: python3-escript [armel mipsel]
> python3-escript-mpi [armel mipsel]
> qm-dsp: libqm-dsp0
> scamp: scamp [amd64 arm64 mips64el ppc64el s390x]
> scikit-misc: python3-skmisc
> sight: libsight [amd64]
> source-extractor: source-extractor
> xmds2: xmds2
> 
> # Broken Build-Depends:
> ceres-solver: libatlas-base-dev
> dune-common: libatlas-base-dev
> emmax: libatlas-base-dev
>libatlas3-base
> ergo: libatlas-base-dev
> ghmm: libatlas-base-dev
> halide: libatlas-base-dev
> hpcc: libatlas-base-dev
> iml: libatlas-base-dev
> ncl: libatlas3-base
> odin: libatlas-base-dev
> opm-material: libatlas-base-dev
> phast: libatlas-base-dev
> plink1.9: libatlas-base-dev
> plink2: libatlas-base-dev
> psfex: libatlas-base-dev
> qm-dsp: libatlas-base-dev
> scamp: libatlas-base-dev
> scikit-misc: libatlas-base-dev
> source-extractor: libatlas-base-dev
> theli: libatlas-base-dev
> xmds2: libatlas-base-dev
> 
> Dependency problem found.
> 




-- 
http://fam-tille.de

Re: Bug#1040500: routine-update: Don't create d/salsa-ci.yml file

[Andreas Tille]

Hi Jochen,

Am Fri, Jul 07, 2023 at 12:04:29PM +0200 schrieb Jochen Sprickerhof:
> 
> echo "SALSA_TOKEN=" >> ~/.devscripts
> echo 'SALSA_CI_CONFIG_PATH="recipes/debian.yml@salsa-ci-team/pipeline"' >> 
> ~/.devscripts
> sudo apt install devscripts
> salsa update_safe --group science-team --all

Thanks for this code.  The only problem is that the salsa command does
not work for everybody - specifically not for me, despite I'm using the
token which works for any other task on salsa (including creating new
repositories, pushing etc.)  I simply get

$ salsa update_safe --group science-team --all
Error GETing 
https://salsa.debian.org/api/v4/groups/science-team?with_custom_attributes=0&with_projects=0
 (HTTP 401): Unauthorized {"error":"invalid_token","error_description":"Toke... 
at /usr/share/perl5/Devscripts/Salsa.pm line 396.

I would love to get this working for me but previous attempts to sort
this out failed.  I know it works for a couple of other DDs.

The other thing is the setting this for all might be slightly dangerous
since we have a couple of configured debian/salsa-ci.yml files in Debian
Med and Pkg R teams.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: Bug#1040500: routine-update: Don't create d/salsa-ci.yml file

[Andreas Tille]

Hi Jochen,

Am Fri, Jul 07, 2023 at 09:48:45AM +0200 schrieb Jochen Sprickerhof:
> > I confirm routine-update is going beyond the recommendation but in those
> > teams where I'm working (in CC) we have this de-facto standard to use
> > this file.  Before I change the behaviour of routine-update I would like
> > to discuss this inside these teams and ask for opinions.
> 
> I don't think we have a de-facto standard on that file in debian-science, at
> least I removed it from my packages a long time ago already and I agree with
> Christopher that routine-update should do the same. There is no benefit in
> having a file with the same content in every repo and every Debian package
> if we can avoid it.

Thanks for your opinion about this.  What I mean with de facto standard:  We
have about 2000 repositories configured to check debian/salsa-ci.yml.  I have
not yet found a way to set the according field via gitlab API to something
else.  If this is scriptable I'd happily remove debian/salsa-ci.yml.  For the
moment I state two votes against salsa-ci.yml. ;-)

Kind regards
  Andreas.

-- 
http://fam-tille.de

Re: Bug#1040500: routine-update: Don't create d/salsa-ci.yml file

[Andreas Tille]

Control: severity -1 wishlist

Hi Christopher,

thanks you for the suggestion to enhance routine-update.

Am Thu, Jul 06, 2023 at 09:03:23PM +0100 schrieb Christopher Obbard:
> routine-update adds a file under the path "debian/salsa-ci.yml".

Yes, this is intended.
 
> According to the salsa-ci-team[1], the default recommendation is to
> set the pipeline URL in the project settings rather than to use a
> standaline debian/salsa-ci.yml file.
> 
> Therefore, please remove the addition of this file and instead
> please print a warning if this file exists for manual intervention to
> change the pipeline to the recommended suggestion by the Salsa CI team.

I confirm routine-update is going beyond the recommendation but in those
teams where I'm working (in CC) we have this de-facto standard to use
this file.  Before I change the behaviour of routine-update I would like
to discuss this inside these teams and ask for opinions.

That's why I also have set the severity of this bug to wishlist (not
because I consider it of minor interest but rather to express that the
behaviour which you want to be changed is perfectly intended but should
be discussed here in this bug report).

Kind regards
Andreas.
 
> [1]: https://salsa.debian.org/salsa-ci-team/pipeline/#basic-use

-- 
http://fam-tille.de

Re: Maintenance of OSPRay and its dependency

[Andreas Tille]

Hi François,

Am Sat, Jul 01, 2023 at 05:47:48PM +0200 schrieb François Mazen:
> I'm working on packaging OSPRay [1], and Steve advised to make it team
> maintained by the Debian Science Team. I definitely agree because
> OSPRay mainly targets scientific applications like VTK or ParaView.

Thanks for your intend to provide more valuable scientific software
to Debian.
 
> I'm wondering if the build dependencies should also be maintained by
> the team:
>  - rkcommon [2]
>  - ispc [3][4]
>  - Open Image Denoise (not mandatory, for later package version) [5]
>  - Open VKL (not mandatory, for later package version) [6]

It used to be good practice to maintain preconditions also inside the
team even if not directly science related.
 
> ISPC is for general purpose, so it would maybe make less sense to be
> maintained by the team.

The advantage of beeing maintained by the team is that these
preconditions are rising signals in our QA tools for the team and
every team member can easily fix it.
 
> It seems that I can create the projects on salsa/debian-science group,
> but I would prefer an approval before going forward.

If you ask me please go forward.

Kind regards
   Andreas.

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039111
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039110
> [3] https://salsa.debian.org/mzf/ispc
> [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956816
> [5] https://www.openimagedenoise.org/
> [6] https://www.openvkl.org/



-- 
http://fam-tille.de

Re: numba: autopkgtest regression: segmentation fault on arm64

[Andreas Tille]

Hi

On Sun, 21 May 2023 11:39:29 -0700 Diane Trout wrote:
> Unfortunately it also wants llvmlite 0.40.0.

Could you please be more verbose about this "unfortunately"?

> It'd probably be easier to get upstream to help with debugging 0.57

I fully agree that we should target at latest upstream instead of
trying to stick to our heavily patched old version.

Kind regards
 Andreas.

-- 
http://fam-tille.de

Bug#1036753: unblock: debian-science/1.14.5

[Andreas Tille]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-scie...@packages.debian.org, 
debian-science@lists.debian.org
Control: affects -1 + src:debian-science

Please unblock package debian-science

[ Reason ]
This is the usual update of the Blends metapackages short before the
release to reflect removals inside the freeze process.  Well, admittedly
its not the "usual" one.  I intended to get version 1.14.4 featuring
lots of changes into testing before the freeze and failed.  Its simply
my fault and I should have done this earlier - I'm very sorry about
this.  The consequence is a diff to the version in testing (1.14.3)
which is *way* larger than usually acceptable and I can perfectly
understand if you might reject this unblock request due to this large
diff which is not readable any more.  The consequence would be some
inconsistencies inside the metapackages which might have a non-optimal
user experience.

[ Impact ]
Some packages recommended inside the metapackages are removed from
bookworm.  Due to my late upload of 1.14.4 which contained a lot of
updates regarding packages created by Debian Science users would
miss quite some packages that are not mentioned in the dependencies
of the metapackages.

[ Tests ]
Unfortunately there are no tests for the metapackages.  However, they
are automatically created and thus checked against the package pool
and thus it is sensible to expect that the packages are fine.

[ Risks ]
There is no real code inside the metapackages so the packages are
extremely trivial and all are leaf packages so no other package is
depending from them and thus they can not break any other package.

[ Checklist ]
  [*] all changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in testing

[ Other info ]
I promise to deliver smaller diffs for the next release cycle.

unblock debian-science/1.14.5


debian-science_1.14.3-1.14.5.debdiff.gz
Description: application/gzip

Re: HDF5 - how about removing gif2h5 subject to several CVE?

[Andreas Tille]

Hi Gilles,

since nobody responded to your question (I did not respond as well since
none of my packages uses this tool) here some opinion from me:  No
contradiction means agreement - thus just go for it.

Thanks a lot for caring for hdf5 libraries
Andreas.

Am Sat, Feb 25, 2023 at 10:37:58PM +0100 schrieb Gilles Filippini:
> Hi debian-science,
> 
> Three CVE were recently reported [1] against gif2h5. When I asked the HDF
> group about these CVE I had this answer:
> 
> > Those appear to be flaws in a small, poorly-written, command-line tool
> (gif2h5) and not the HDF5 library itself. This is only a concern if you have
> built a service that uses the tool. I am very surprised that those CVE
> issues were given high scores given how rarely the tool is used in a
> production environment.
> >
> > I have no fix ETA since my plan is to move the tool to a separate
> repository. Valgrind has always complained about that tool and the code
> doesn't seem worth fixing.
> >
> > You can avoid the issue entirely by not deploying or exposing the gif2h5
> tool. This can be done at configure time via the --disable-hltools configure
> option (in CMake, set HDF5_BUILD_HL_TOOLS to OFF) which will disable
> building the high-level tools.
> 
> What do you think about removing gif2h5 from the hdf5-tools package?
> 
> And would it be OK to fix HDF5 in stable and oldstable this way?
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031726
> 
> Thanks in advance,
> _g.
> 
> 

-- 
http://fam-tille.de

Numba issues for genx for other architectures than amd64 and ppc64el (Was: genx won't start: TypeError: Pen(): arguments did not match any overloaded call)

[Andreas Tille]

Hi,

I've found genx in the "Cleaner view"[1] due to missing builds[2].
It turns out that for instance for arm64[3] the build fails with

   tests/test_numba_equivalency.py Fatal Python error: Segmentation fault

For armel[4] (and armhf) we get

   dh_auto_test -a -O--buildsystem=pybuild
I: pybuild base:240: cd /<>/.pybuild/cpython3_3.11/build; 
python3.11 -m pytest tests
Fatal Python error: Aborted

Current thread 0xf7a30020 (most recent call first):
  File "/usr/lib/python3/dist-packages/llvmlite/binding/ffi.py", line 151 in 
__call__
  File "/usr/lib/python3/dist-packages/llvmlite/binding/executionengine.py", 
line 92 in finalize_object
  File "/usr/lib/python3/dist-packages/numba/core/codegen.py", line 1060 in 
wrapper
  File "/usr/lib/python3/dist-packages/numba/core/codegen.py", line 999 in 
_finalize_specific
  File "/usr/lib/python3/dist-packages/numba/core/codegen.py", line 797 in 
_finalize_final_module
  ...

For i386[5]

I: pybuild base:240: cd /<>/.pybuild/cpython3_3.11/build; 
python3.11 -m pytest tests
= test session starts ==
platform linux -- Python 3.11.2, pytest-7.2.1, pluggy-1.0.0+repack
rootdir: /<>
collected 14 items / 1 error

 ERRORS 
_ ERROR collecting .pybuild/cpython3_3.11/build/tests/test_numba_equivalency.py 
_
tests/test_numba_equivalency.py:11: in 
from genx.models.lib import instrument, instrument_numba, paratt, 
paratt_numba, neutron_refl, neutron_numba, \
genx/models/lib/instrument_numba.py:9: in 
@numba.jit(
/usr/lib/python3/dist-packages/numba/core/decorators.py:219: in wrapper
disp.compile(sig)
/usr/lib/python3/dist-packages/numba/core/dispatcher.py:965: in compile
cres = self._compiler.compile(args, return_type)
   ...


and we have other errors for other architectures which all contain
the string "numba".  IMHO this is a mess we can hardly fix in hard
freeze.  I see only two chances:

   1. Restrict the architectures to amd64 and ppc64el (which are
  the only ones where the build succeeds or
   2. Remove the package from testing for the moment.  The only
  rdepends is currently pan-grazing-incidence which will be
  lowered to suggests once we re-render debian-pan metapackages.

What do you think?

Kind regards
Andreas.

[1] 
https://udd.debian.org/bugs/?release=bookworm_and_sid&merged=ign&done=only&rc=1&flastmod=ign&flastmodval=5&sortby=last_modified&sorto=asc&ctags=1&cdeferred=1&caffected=1&cautormtime=1&cmissingbuilds=1&#results
[2] https://buildd.debian.org/status/package.php?p=genx&suite=sid
[3] 
https://buildd.debian.org/status/fetch.php?pkg=genx&arch=arm64&ver=3.6.21-1&stamp=1681143066&raw=0
[4] 
https://buildd.debian.org/status/fetch.php?pkg=genx&arch=armel&ver=3.6.21-1&stamp=1681142381&raw=0
[5] 
https://buildd.debian.org/status/fetch.php?pkg=genx&arch=i386&ver=3.6.21-1&stamp=1681142358&raw=0

-- 
http://fam-tille.de

Re: Packaging liblsl

[Andreas Tille]

Hi Enrico,

Am Tue, Mar 14, 2023 at 10:55:50AM +0100 schrieb Enrico Zini:
> 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?

We have a couple of packages if the type you describe inside the team.
I consider team maintenance better for such packages since there might
be at least some chance that others might step in to do something even
if I admit that my experience shows that probability for this is not
as high as I would wish.

Kind regards
Andreas.
 
> [1] https://github.com/sccn/liblsl

-- 
http://fam-tille.de

Re: Bug#1027215: Bug#1026539: How much do we lose if we remove theano (+keras, deepnano, invesalius)?

[Andreas Tille]

Hi Rebecca,

Am Thu, Mar 02, 2023 at 09:00:14PM + schrieb Rebecca N. Palmer:
> 
> 1.1.2 isn't the latest version, just the latest that calls the module theano
> rather than aesara.  (I chose it to package because I didn't want to fully
> break compatibility, then abandoned it because I didn't like how much it did
> break.)

Ahh, so aesara is not really a "fork" but a "rename"?
 
> > If it would have build smoothly on all architectures, yes.
> 
> If you wouldn't want to do this work if it can't get into bookworm (possibly
> because you'd prefer to package 2.0 as aesara if you have to wait until
> trixie anyway), you might want to ask them first.

I admit I do not want to take over theano / aesara.  I simply wanted to
see what I can do to lend a helping hand on packages that are not yet
removed from testing.  I naively assumed that just numpy issues should
be solvable.
 
> > But we have
> > the first trouble on arm64[1]
> Sorry - I forgot that theano skips most of its tests on Salsa-CI (because
> there's enough of them to take several hours), which is probably why it
> "passed" that but failed the full build.
> 
> Given how many failures there are (everywhere), I don't consider this worth
> fixing, but you are of course free to disagree.

Considering my practical experience now I agree.

> (If you're planning to xfail tests, note that I consider *wrong-answer* bugs
> (though not crash bugs) in this kind of package to be RC.  I haven't checked
> whether we currently have any.)

I admit I'll give up here on that package where we decided that the
loose we have is acceptable.

Kind regards and thanks a lot for your work on this package as well as
your hints in this mail

 Andreas.

-- 
http://fam-tille.de

Re: Bug#1026539: How much do we lose if we remove theano (+keras, deepnano, invesalius)?

[Andreas Tille]

Hi Rebecca,

Am Wed, Mar 01, 2023 at 10:41:23PM + schrieb Rebecca N. Palmer:
> I agree that switching to Aesara is probably the only reasonable option
> other than removal.  (I'd given up on trying to fix 1.0, and was intending
> to let removal happen.)
> 
> However, it's a much bigger change than is normally allowed in bookworm at
> this point.  (1.1 includes multiple breaking changes, which is why it's in
> experimental, but a quick codesearch suggests these parts *may* not be used
> in keras/deepnano. https://github.com/aesara-devs/aesara/releases?page=8 )

I admit I do not see any good reason to stick to the old version if we
decided before that keras/deepnano are no real blockers to even drop
theano.  Thus I was considering it more promising to spent my time on
the latest version.
 
> Do you want to ask release team for permission to do this?

If it would have build smoothly on all architectures, yes.  But we have
the first trouble on arm64[1]

> Or do you want
> to try the same patches on 1.0?  (I suspect that that won't work, but I
> haven't actually tried it.)
> 
> (Also, you might not want numpy1p24_compat.patch - the v1p0 branch is
> currently in whatever state it was in when I gave up on it, and my vague
> memory is that this was a failed experiment, though I don't know if that
> meant "actively bad" or just "not a (full) solution".)

I've found some patches inside numpy1p24_compat.patch that were also
in Aesara.  Since the package did not fully build with this patch
alone I've added a separate patch with the only goal to build and pass
the test suite.

Kind regards
Andreas.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=theano&arch=amd64&ver=1.1.2%2Bdfsg-4&stamp=1677751828&raw=0

-- 
http://fam-tille.de

Re: How much do we lose if we remove theano (+keras, deepnano, invesalius)?

[Andreas Tille]

Control: tags -1 pending

Hi,

> Andrius Merkys wrote:
> That said, it is OK to omit keras in bookworm if need be, but I would 
> like to see it back for trixie.

I've spent some time into theano and it builds and runs its test suite
in Salsa CI[1].  Since despite some tests are failing in my local
pbuilder environment I'd be happy if someone else could run some test
build before uploading.  I decided for the latest upstream that was
prepared by Rebecca and I also sneaked into the aesara fork[2] to copy
some solutions they found for numpy 1.24 compatibility.

I think we can not really loose much by taking this code from
experimental since if we break something it can be removed which is
the consensus we've somehow found before.  In case it might work we
have saved something for bookworm.  Regarding future releases we
should probably check whether those packages we want to save will
work with aesara.

Kind regards
   Andreas.

[1] https://salsa.debian.org/science-team/theano/-/pipelines/506598
[2] https://github.com/aesara-devs/aesara

-- 
http://fam-tille.de

Re: Bug#1030907: [Help] Possible scikit-learn issue (Was: Bug#1030907: umap-learn: FTBFS (failing tests))

[Andreas Tille]

Hi again,

Am Thu, Feb 09, 2023 at 05:52:13PM +0100 schrieb Andreas Tille:
> > That said, the np.matrix discrepancy was only just fixed recently, in
> > December, by
> > https://github.com/lmcinnes/umap/pull/946

I've updated the packaging, added the PR, fixed some test issues that
were not yet addressed by these patches but there are remaining issues:

   https://salsa.debian.org/med-team/umap-learn/-/jobs/3925631 

Any idea how to fix these?

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: [Help] Possible scikit-learn issue (Was: Bug#1030907: umap-learn: FTBFS (failing tests))

[Andreas Tille]

Am Thu, Feb 09, 2023 at 04:57:03PM +0100 schrieb Drew Parsons:
> tldr;  https://github.com/lmcinnes/umap/pull/946

Thanks for the hint.
 
> There's a couple of strange aspects to this problem.  The np.matrix seems to
> be generated by scipy.sparse.  np.matrix is "not recommended" by numpy, but
> not actually deprecated (at least not removed) yet.  scikit-learn is jumping
> the gun by declaring it's not supported.
> 
> On the other hand, scitkit-learn has been "not supporting" it for two years
> now.  This corner of the debian archive is quite a bit out of date.  The
> current version of umap (i.e. umap-learn) is 0.5.3, released April last
> year.
> 
> That said, the np.matrix discrepancy was only just fixed recently, in
> December, by
> https://github.com/lmcinnes/umap/pull/946

I did not updated umap-learn since it had a new dependency from tensorflow.
However, I can skip those dependency and will upgrade to the latest version.

Kind regards
   Andreas. 

-- 
http://fam-tille.de

[Help] Possible scikit-learn issue (Was: Bug#1030907: umap-learn: FTBFS (failing tests))

[Andreas Tille]

Control: tags -1 help

Am Thu, Feb 09, 2023 at 12:50:45AM +0100 schrieb Santiago Vila:
> Package: src:umap-learn
> Version: 0.4.5+dfsg-3
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer:
> 
> During a rebuild of all packages in bookworm, your package failed to build:

In Salsa CI you can find a more informative log:

   https://salsa.debian.org/med-team/umap-learn/-/jobs/3923570

Looking at line 1307 and following I'm wondering, whether this issue is
rather caused by scikit-learn which is not fully converted to numpy
1.24.

Any ideas how to fix this?

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: scikit-learn Re: Are we still trying to do scipy 1.10, given transition freeze?

[Andreas Tille]

Am Tue, Feb 07, 2023 at 09:05:28AM +0100 schrieb Drew Parsons:
> On 2023-02-07 08:33, Graham Inggs wrote:
> > Hi Drew
> > 
> > I think python3-scipy should declare a Breaks on python3-skbio less
> > than the version in unstable (0.5.8-3).
> > This should sort out the autopkgtest regressions of emperor,
> > python-skbio itself, q2-metadata and q2-quality-control, which are all
> > passing in unstable, and allow scipy and python-skbio to migrate
> > together.
> 
> Ok, I'll add that with the gammapy patch.

Thanks a lot.
 
> > Python-cooler seems to have a different failure, and I don't see a bug
> > filed for it.
> 
> cooler seems to be fixed in experimental, I guess it just needs to be
> uploaded to unstable.

I'll do so

Thanks for the hint

 Andreas. 

-- 
http://fam-tille.de

Re: Numba not in testing due to lots of autopkgtest errors - how to proceed

[Andreas Tille]

Hi Diane,

Am Mon, Feb 06, 2023 at 11:23:47AM -0800 schrieb Diane Trout:
> I pushed numba 0.56.4+dfsg-2 to unstable, and it should be vastly
> better than -1. I quickly counted there's about 13 test failures for
> what functionality we can support, those failing tests are currently
> getting skipped by pythons unittest expectedFailure and skip test
> decorators, so autopkgtest will thinks it's clean.

Kudos for all your work on this complex package!

Kind regards

Andreas. 

-- 
http://fam-tille.de

Re: We are right before the freeze now - please update anything to latest version that needs updating

[Andreas Tille]

Hi Maarten,

Am Fri, Feb 03, 2023 at 10:55:14AM +0100 schrieb Maarten van Gompel:
> I'll give it a try today and see how far I can get. Hopefully that's
> still in time? There will be ABI changes but at least there are no other
> packages in debian that depend on our stack besides our own packages.

I guess for ABI changes it is to late since ftpmaster was asked
to not accept renamed library packages (which you need for an
ABI change)

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: Numba not in testing due to lots of autopkgtest errors - how to proceed

[Andreas Tille]

Hi Graham,

Am Fri, Feb 03, 2023 at 11:36:01AM +0200 schrieb Graham Inggs:
> I will hint numba 0.56.4+dfsg-1 to migrate to testing now, despite the
> autopkgtest regressions, and file an RC bug so we don't lose track of
> this. Please don't upload until this has happened.

Thanks a lot for your always helpful support
Andreas.

-- 
http://fam-tille.de

Re: Numba not in testing due to lots of autopkgtest errors - how to proceed

[Andreas Tille]

Hi Graham,

Am Thu, Feb 02, 2023 at 08:40:23PM +0200 schrieb Graham Inggs:
> On Thu, 2 Feb 2023 at 17:18, Andreas Tille  wrote:
> > It seems to me that build time tests are working and the failure is
> > just in autopkgtest.  I'm drawing this conclusion from your latest
> > push to Salsa where amd64 and i386 were building successfully
> ...
> > I know that's cheating but there is no time for fiddling around here
> > any more. We are running the same test as at build-time where it is
> > passing so we can assume that numba works.
> 
> The build time tests are probably only passing because of a similar
> "cheat" [1] committed in 2017.

Good catch!

I confirm that the log also shows some errors in the dh_auto_test part
of the log I created locally.

I admit I don't know what might be a good solution.  Building to check
for failing tests takes ages on some decent hardware.  Salsa CI has
trouble to build it reliably.

I have no idea whether numba should be considered a case for "if
Python3.11 does not work we should revert and release with Python3.10".
I do not see any real chance to fix all issues in numba right in time
for the freeze.

Kind regards
   Andreas.
 
> [1] 
> https://salsa.debian.org/science-team/numba/-/commit/3d08b6e6fe43400e7640de51d8e5afb5942d79ed

-- 
http://fam-tille.de

Re: Numba not in testing due to lots of autopkgtest errors - how to proceed

[Andreas Tille]

Hi Diane,

Am Wed, Feb 01, 2023 at 02:21:08PM -0800 schrieb Diane Trout:
> > 
> > could you please give an update about the status of numba?  The
> > window
> > of opportunity is closing soon.  Please be as verbose as possible
> > what
> > help you might need.
> > 
> 
> Ok what I've been doing so far was I did manage to backport all of
> upstreams python 3.11 patches.
> 
> Though I did make a mistake in one of them that generated a great deal
> of errors (and more importantly I did find, fix, and pushed the fix for
> that error to salsa)
> 
> Mostly I've been running the tests and watching it fail, and trying to
> add to the list of tests to ignore.
> 
> I've been building on a server with 24 GB of ram but have been getting
> out of memory errors with sbuild & autopkgtest for some reason, and my
> system monitoring seems to suggest it was only getting up to 6-7 GB
> used. (I'm using an old server because no one else is using it...)
> 
> To get around crashing due to the OOM killer I switched from upstreams
> numba.runtests to pytest-xdist. pytest also makes it easier to ignore
> specific tests that are causing trouble and xdist does a better job of
> restarting failed worker processes.
> 
> It might be good for someone else to run the tests and see what
> happens, is it something about my sbuild / autopkgtest that's causing
> it to crash with an out of memory error?

It seems to me that build time tests are working and the failure is
just in autopkgtest.  I'm drawing this conclusion from your latest
push to Salsa where amd64 and i386 were building successfully

   https://salsa.debian.org/science-team/numba/-/pipelines/493712

while the autopkgtest failed[1].
 
> There's also asking upstream if this is expected behavior?
> 
> But run tests for 3-4 hours to see what test failed and then ignore
> that is not a particularly efficient method.
> 
> I'm open for more suggestions.
> 
> Also I may have found a bug in autopkgtestbut haven't investigated
> it yet.
> 
> [gw22] [ 99%] FAILED
> tests/test_array_methods.py::TestArrayMethods::test_np_frombuffer_dtype
> self.testbed.check_exec(['rm', '-rf', 
> self.tb]) 
>   File "/usr/share/autopkgtest/lib/adt_testbed.py", line 559, in
> check_exec
> (code, out, err) = self.execute(argv, 
>   File "/usr/share/autopkgtest/lib/adt_testbed.py", line 531, in
> execute   
> killtree(proc.pid)
> UnboundLocalError: local variable 'proc' referenced before assignment 

As in [1] it failed with

[gw0] [  4%] PASSED 
tests/test_array_reductions.py::TestArrayReductions::test_array_nanmin_complex64_2d
 
tests/test_array_reductions.py::TestArrayReductions::test_array_nanmin_complex64_3d
 
[gw0] [  4%] PASSED 
tests/test_array_reductions.py::TestArrayReductions::test_array_nanmin_complex64_3d
 
tests/test_array_reductions.py::TestArrayReductions::test_array_nanmin_float32_1d
 autopkgtest [21:28:49]: ERROR: timed out on command "su -s /bin/bash debci -c 
set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true;  . 
~/.profile >/dev/null 2>&1 || true; 
buildtree="/tmp/autopkgtest-lxc.bwdnkpny/downtmp/build.4kI/src"; mkdir -p -m 
1777 -- "/tmp/autopkgtest-lxc.bwdnkpny/downtmp/python3-numba-artifacts"; export 
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.bwdnkpny/downtmp/python3-numba-artifacts";
 export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 
"/tmp/autopkgtest-lxc.bwdnkpny/downtmp/autopkgtest_tmp"; export 
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.bwdnkpny/downtmp/autopkgtest_tmp"; export 
ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; export 
LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=2; unset LANGUAGE LC_CTYPE 
LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME 
LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL;cd 
"$buildtree"; chmod +x 
/tmp/autopkgtest-lxc.bwdnkpny/downtmp/build.4kI/src/debian/tests/python3-numba; 
exec /tmp/autopkgtest-lxc.bwdnkpny/downtmp/wrapper.sh 
--script-pid-file=/tmp/autopkgtest_script_pid 
--stderr=/tmp/autopkgtest-lxc.bwdnkpny/downtmp/python3-numba-stderr 
--stdout=/tmp/autopkgtest-lxc.bwdnkpny/downtmp/python3-numba-stdout -- 
/tmp/autopkgtest-lxc.bwdnkpny/downtmp/build.4kI/src/debian/tests/python3-numba 
;" (kind: test)
Session terminated, killing shell...autopkgtest [21:28:50]: test python3-numba: 
---]

I tried to exclude this with a "rude" patch[2] where I first excluded
test_array_nanmin_* to avoid the situation above.  In my local
autobuilder I've got something similar with test_array_var_* and
thus I excluded these tests as well.  Now Salsa CI is crashing twice
when extracting the source which does not bring us forward at all.

So I would suggest to "forcefully" make autopkgtest pass

Re: We are right before the freeze now - please update anything to latest version that needs updating

[Andreas Tille]

Hi Joost,

Am Thu, Feb 02, 2023 at 10:39:17AM +0100 schrieb Joost van Baal-Ilić:
> Hi Andreas e.a.,
> 
> [I guess the same is true for debian-science, re-using your -med post here.]

Re-using is fine. ;-)
 
> On Wed, Feb 01, 2023 at 03:14:30PM +0100, Andreas Tille wrote to debian-med:
> > Hi Maarten and others,
> > 
> > as subject says we are right before the freeze since packages need some time
> > to migrate to testing to reach the next stable release.  We should upload
> > what should be in the next release *right now*.  I've explicitly kept 
> > Maarten
> > in CC since I have no idea how these package interoperate with each other 
> > and
> > will not touch these.
> > 
> > Kind regards and thanks to anybody who works hard to make the next stable
> > release the best ever.
> 
> I feel still responsible for the r-cran stuff @
> https://qa.debian.org/developer.php?login=joostvb ; thanks to Andreas and 
> other
> debian-science people that is pretty much up to date.
> 
> The Debian science-linguistics part I've been working on till about 2016 is
> collected at https://qa.debian.org/developer.php?login=ko.vandersloot%40uvt.nl
> .  There's quite some work to do there.  Upstream also has commit and upload
> access, but I don't expect them to make it in time for the release; the future
> of this software in Debian is a bit unclear now.

May be I should (again) advertise routine-update, which works quite good
to take over the routine part (except refreshing patches) to update a
package.

For the sake of completeness I'd recommend the UDD dashboard:

   
https://udd.debian.org/dmd/?email1=debian-science-maintainers%40lists.alioth.debian.org&email2=tille%40debian.org&email3=r-pkg-team%40alioth-lists.debian.net&packages=&ignpackages=&format=html#todo

(where you probably should add your own ID as email2) to also see issues
with testing migration.  Its *not* sufficient to push a package to
unstable to make it migrate to testing automagically.  I've observed in
several cases that packages I assumed to migrate nicely hanging in
unstable for ages (due to some issues with dependencies, architectures,
autopkgtests).  You can also find uscan errors there which might hide
new upstream versions

> (These days I'm very busy preparing
> https://wiki.debian.org/DebianEvents/be/2023/FOSDEM .)

Have fun there.  Finally I should come to this nice event again ... 

Kind regards
Andreas.

-- 
http://fam-tille.de

Numba not in testing due to lots of autopkgtest errors - how to proceed

[Andreas Tille]

Hi Diane,

could you please give an update about the status of numba?  The window
of opportunity is closing soon.  Please be as verbose as possible what
help you might need.

In any case thanks for all your work on this heavy package

 Andreas.

-- 
http://fam-tille.de

Re: Help needed to finalise the oneTBB migration of flexbar

[Andreas Tille]

Am Sat, Jan 28, 2023 at 09:06:43AM +0100 schrieb Andreas Tille:
> Am Fri, Jan 27, 2023 at 11:12:10PM +0100 schrieb Étienne Mollier:
> > favor of funtion tbb::parallel_pipeline).  I'm a bit dry for the
> > moment and will have the weekend busy, so if someone wants to
> > take over from here, please go ahead.
> 
> I'll see what I can do, thanks in any case
>Andreas.

I need to admit I'm also running out of ideas. :-( 

Anyone with more experience in (one)TBB?

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: scikit-learn Re: Are we still trying to do scipy 1.10, given transition freeze?

[Andreas Tille]

Am Thu, Jan 26, 2023 at 07:51:23PM + schrieb Rebecca N. Palmer:
> Control: tags 1029701 fixed-upstream
> 
> Full log: 
> https://ci.debian.net/data/autopkgtest/unstable/amd64/s/scikit-learn/30693526/log.gz
> 
> There appear to be at least 2 separate failures here, both known and
> probably fixed upstream.  So yes, 'new upstream version' is the first thing
> to try, but we'll need to check what _that_ breaks.

Sure.  Thus I uploaded to experimental first.  I hope we can get
some enlightenment from

   https://qa.debian.org/excuses.php?experimental=1&package=scikit-learn

soon (at the time of writing this is empty since the package was
just uploaded).  At least autopkgtest is passing.  I'll check
Debian Med related packages manually later.

Kind regards
Andreas.
 
> https://github.com/scikit-learn/scikit-learn/issues/23626
> https://github.com/scikit-learn/scikit-learn/issues/24424

-- 
http://fam-tille.de

Re: Are we still trying to do scipy 1.10, given transition freeze?

[Andreas Tille]

Am Thu, Jan 26, 2023 at 05:45:58PM +0100 schrieb Drew Parsons:
> > Any solution for this one?
> 
> Probably just needs updating to the latest release.  They fixed some things.
 
Latest release is building in my local git.  I'll report about issues
if I might meet some.  Otherwise I'll also upload to experimental.

Kind regards
Andreas. 

-- 
http://fam-tille.de

Re: Are we still trying to do scipy 1.10, given transition freeze?

[Andreas Tille]

Am Thu, Jan 26, 2023 at 04:51:25PM +0100 schrieb Drew Parsons:
> On 2023-01-26 16:46, Andreas Tille wrote:
> > I've fixed all those Debian Med related issues in testing where you
> > filed
> > bug reports for.  Seems from my point of view the upload of 1.10 is
> > fine.
> > 
> > I've also pushed d/copyright paragraphs for the included submodules to
> > Git.
> 
> Thanks Andrea.  armel has revealed which tests it needs skipped, so I'll
> push scipy 1.10 to unstable after scipy 1.8.1-22 is done migrating to
> testing

I just notice that bug #1029701 of scikit-learn might be a show stoper.

Any solution for this one?

Kind regards
Andreas. 

-- 
http://fam-tille.de

Re: Are we still trying to do scipy 1.10, given transition freeze?

[Andreas Tille]

Am Thu, Jan 26, 2023 at 04:51:25PM +0100 schrieb Drew Parsons:
> 
> Thanks Andrea.  armel has revealed which tests it needs skipped, so I'll
> push scipy 1.10 to unstable after scipy 1.8.1-22 is done migrating to
> testing

Thanks a lot for all your work on this

  Andreas. 

-- 
http://fam-tille.de

Re: Are we still trying to do scipy 1.10, given transition freeze?

[Andreas Tille]

Hi Drew,

Am Thu, Jan 26, 2023 at 01:46:18PM +0100 schrieb Drew Parsons:
> > for the release architectures with autopkgtests, so expect results for
> > more architectures to appear over the next few hours.
> > [1] https://qa.debian.org/excuses.php?experimental=1&package=scipy
> 
> Ok, if you're happy with those regressions then I'm happy.  In any case,
> I've filed bug reports against them.

I've fixed all those Debian Med related issues in testing where you filed
bug reports for.  Seems from my point of view the upload of 1.10 is fine.

I've also pushed d/copyright paragraphs for the included submodules to
Git.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: Are we still trying to do scipy 1.10, given transition freeze?

[Andreas Tille]

Am Wed, Jan 25, 2023 at 04:29:59PM +0100 schrieb Drew Parsons:
> heh yeah, I was just replying about that :)

So at least I was beating you in writing an e-mail! :-P
 
> Are we confident on bringing scipy 1.10 to the new stable?

In any case we should probably follow Graham's advise to let things
migrate to testing first.

>  1.10.0-1exp6
> should finish building on all release arches soon, we'll start seeing its
> debci results soon.

Meanwhile someone with a proper setup might run ratt on it.  I
personally failed setting up sbuild to get this done but having some
verification that at least this tool does not uncover serious issues
would make sense.

Kind regards and thanks a lot for your work on this
Andreas.

-- 
http://fam-tille.de

Re: Are we still trying to do scipy 1.10, given transition freeze?

[Andreas Tille]

Am Wed, Jan 25, 2023 at 04:23:58PM +0100 schrieb Andreas Tille:
> I'm just building an according package locally and will hopefully upload
> soon. 

... but Drew Parsons seems to have beaten me. ;-)

Thanks also to Drew
Andreas. 

-- 
http://fam-tille.de

Re: Are we still trying to do scipy 1.10, given transition freeze?

[Andreas Tille]

Hi Graham,

Am Wed, Jan 25, 2023 at 03:09:54PM +0200 schrieb Graham Inggs:
> Please do fix #1029550 in 1.8.1 in testing before uploading 1.10.0 to
> unstable.  It is one of the last blockers for NumPy.

I'm just building an according package locally and will hopefully upload
soon. 

Thanks a lot for the pointer

Andreas.

-- 
http://fam-tille.de

Re: Bug#1022571: transition: pandas 1.3 -> 1.5

[Andreas Tille]

Hi Graham,

Am Wed, Jan 25, 2023 at 02:28:37PM +0200 schrieb Graham Inggs:
> On Wed, 25 Jan 2023 at 11:43, Andreas Tille  wrote:
> > I was motivated for this patch by Diane's statement on the Debian Med
> > matrix channel that dask and dask.distributed are interconnected.  If
> > the autopkgtest on Salsa CI[4] would have passed I would have uploaded.
> 
> We will temporarily remove dask.distributed from testing, which should
> unblock dask and pandas.

Thanks a lot!

> No uploads please, until dask and pandas have migrated.

Yep

   Andreas. 

-- 
http://fam-tille.de

Re: Bug#1022571: transition: pandas 1.3 -> 1.5

[Andreas Tille]

Hi Graham

Am Tue, Jan 24, 2023 at 12:50:41PM +0200 schrieb Graham Inggs:
> 
> On Tue, 24 Jan 2023 at 00:16, Rebecca N. Palmer  
> wrote:
> > The remaining autopkgtest failures blocking pandas are:
> > - dipy/amd64 and snakemake/i386 look like random flakiness: please retry
> > them.  (I think DMs can't use the self-service interface.)  Or for dipy,
> > see #1029533 for a possible fix.
> 
> These have cleared up.
> 
> > - python-xarray/i386 looks like xarray not pandas: see #1004869.
> 
> Sometimes britney is too greedy and pins too many packages from
> unstable.  I managed to find the right combination [1] and got the
> test to pass without python-xarray.

Thanks a lot.
 
> > - dask and dask.distributed have to go together, with or before pandas.
> 
> There's nothing in the currently uploaded packages that specifies
> this, although I do see a commit on salsa [2].

I was motivated for this patch by Diane's statement on the Debian Med
matrix channel that dask and dask.distributed are interconnected.  If
the autopkgtest on Salsa CI[4] would have passed I would have uploaded.

Unfortunately I have no idea how to deal with those
PytestUnraisableExceptionWarnings raised in this test and thus I did
not upload.

> I tried running dask.distributed's autopkgtest with dask and itself
> from unstable [3], but no luck.

Diane, could you please comment on this or at least throw some ENOTIME
error to let others know.

Thanks a lot for you contribution in any case
   Andreas. 
 
> [1] https://ci.debian.net/packages/p/python-xarray/testing/i386/
> [2] 
> https://salsa.debian.org/python-team/packages/dask.distributed/-/commit/9df3fe1a0ea7538f742ebb162379e3cd50b388e6
> [3] https://ci.debian.net/packages/d/dask.distributed/testing/amd64/

[4] 
https://salsa.debian.org/python-team/packages/dask.distributed/-/jobs/3834919 

-- 
http://fam-tille.de

Help needed to finalise the oneTBB migration of flexbar

[Andreas Tille]

Control: tags -1 help

Hi,

I made some progress[1] in converting flexbar (which seems to be
orphaned upstream[2] so we are on our own with the migration - but the
program ist interesting anyway) but finally have hit a blocker which
you can see in the build in Salsa CI[3].

It would be great if someone could help me over this blocker.

Kind regards
   Andreas.


[1] 
https://salsa.debian.org/med-team/flexbar/-/blob/master/debian/patches/onetbb.patch
[2] https://github.com/seqan/flexbar/issues/38
[3] https://salsa.debian.org/med-team/flexbar/-/jobs/3820125

-- 
http://fam-tille.de

Please help to reproduce (Was: shiny-server: server-function don't run)

[Andreas Tille]

Hi Sebastian,

thanks for your bug report and your attempt to track this down by replacing
the sockjs files.  Please note that neither Nilesh nor I are shiny-server
users.  Thus it would help if you could provide a possibly small example that
helps us reproducing the problem.

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Are we still trying to do scipy 1.10, given transition freeze?

[Andreas Tille]

Hi,

Am Thu, Jan 19, 2023 at 12:52:13AM +0100 schrieb Drew Parsons:
> On 2023-01-18 22:31, Rebecca N. Palmer wrote:
> > 
> > This "broken by numpy 1.24" bug looks to me like 17033, not 17630.
> > This has what looks like a trivially-backportable patch, though I
> > haven't actually tried that:
> > https://github.com/scipy/scipy/pull/17035
> 
> We can try applying that patch to scipy 1.8 and see if it fixes test
> failures.

+1

> > Given that the transition freeze was on 2023-01-12, it's too late to
> > move to scipy 1.10 if that's likely to cause significant breakage.
> > (Do we have a guess of whether it will, or do we need a package that
> > builds in experimental to test that?)
> 
> It's a good question. I figure it wouldn't be much worse than switching the
> default python to 3.11 two weeks before freeze.

I'm also assuming that Python 3.11 creates more noise in the archive
than scipy 1.10.  I was motivated to look into scipy upgrade since some
Debian Med package needed a more recent scipy than we currently have in
unstable.  The need for this newer scipy was relaxed thanks to a patch
from Nilesh.  However, having a recent scipy inside the next stable
release is nice to have.  If we realise that switching scipy might ease
the 3.11 migration it might be something we could convince the release
team about despite we are in transition freeze.

> A handful of deprecated
> functions got removed, likely some package will break but it is probably
> fixable. But best to upload to experimental first.

We should do so in any case.
 
> > The scipy 1.10 FTBFS in salsa (
> > https://salsa.debian.org/python-team/packages/scipy/-/pipelines/486634
> > ) is it trying to download test data, which isn't allowed for a
> > build-time test.  We could make those tests autopkgtest-only, or if
> > the data is reasonably sized, add it to the package: Pooch can use a
> > local cache.
> > https://sources.debian.org/src/pooch/1.6.0-2/README.rst/
> 
> pooch is used for scipy.datasets, which is a new scipy submodule. As such
> it's fair enough to just skip those new tests if necessary. Skipping at
> build-time is simpler than caching, though the cached dataset tests are
> light (the downloaded datasets are not so large, 3 files 1.9M total) The
> default cache is ${HOME}/.cache/scipy-data, we'd need to learn how to point
> it at, say, debian/scipy-data instead.
> 
> The 3 files in question are defined in datasets/_registry.py,
> 
> registry_urls = {
> "ascent.dat":
> "https://raw.githubusercontent.com/scipy/dataset-ascent/main/ascent.dat";,
> "ecg.dat":
> "https://raw.githubusercontent.com/scipy/dataset-ecg/main/ecg.dat";,
> "face.dat":
> "https://raw.githubusercontent.com/scipy/dataset-face/main/face.dat";
> }
> 
> The test_data tests that break (with no internet or cache) are
>   test_existence_all
>   test_ascent
>   test_face
>   test_electrocardiogram
> 
> If we're in a rush because of the freeze then skipping these tests at
> build-time is reasonable.

+1

Kind regards
 Andreas. 

-- 
http://fam-tille.de

Re: Helping hands needed to upgrade scipy

[Andreas Tille]

Hi Drew,

Am Wed, Jan 18, 2023 at 02:45:31AM +0100 schrieb Drew Parsons:
> On 2023-01-17 18:12, Andreas Tille wrote:
> > Hi,
> > 
> > I upgraded the experimental branch of scipy to contain the submodules
> > upstream includes.  I'm *not* convinced that we need them all -
> > hopefully we can get rid of boost (but upstream has some patches here)
> > and scipy-mathjax.
> > 
> > For the moment I've tried to build the experimental branch and ended
> > up with some issue where cython can't be found (should be cython3 for
> > sure)[1].
> > 
> > Unfortunately my spare time is occupied now by other more urgent tasks.
> > I'd be happy if someone else could review / pick up / continue from
> > here.
> 
> 
> The problem was not meson as such, but that upstream is only half using
> meson.  They must have decided they don't trust the way meson handles
> cython, and set up their own custom build tools for it, see
> https://github.com/scipy/scipy/pull/15407
> 
> That is, they hard-coded the cython executable name in
> scipy/_build_utils/cythoner.py
> 
> They actually did the same already in the old setuptools build
> (tools/cythonize.py), but we didn't notice since they had the breaking
> cython call wrapped in a try block which inspected a Cython class from
> inside python.  I raised an Issue about  whether cythoner.py should do the
> same in https://github.com/scipy/scipy/issues/17808
> We could argue the fault is debian's for not providing a cython executable
> (it does have -2 and -3 options for choosing the python version to work
> with).

Thanks for the clarification.

> I figure also we should use python3-mesonpy, since it's what upstream uses.
> Best not to diverge too far from their build method I think.

I'm perfectly fine with this approach.  That's why I initially pushed
meson-python to new.  I've just dput meson-python_0.12.0-2_source to let
it migrate to testing.  My attempt to use plain meson (as per upstream
readme) was just to shorten the time while meson-python was in new
queue.

> I've pushed commits updating cythoner.py to point cythoner.py at cython3.
> The main build now completes. Have to clean up test handling next:
> "FileNotFoundError: [Errno 2] No such file or directory:
> '/projects/python/build/scipy/.coveragerc'

Nice.  Hope my preparation (of meson-python and the multi-source tarball)
helped to move forward.  Please double check whether we really need the
boost code copy. 

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Do we want to keep up pyfr?

[Andreas Tille]

Hi Drew,

Am Tue, Jan 17, 2023 at 12:43:56PM +0100 schrieb Drew Parsons:
> > [1] https://salsa.debian.org/science-team/pyfr
> > [2] https://salsa.debian.org/science-team/pyfr/-/jobs/3809459
> 
> 
> From the test log, h5py didn't get installed.
> 
> Looking at debian/tests/control, it only has @ (installs packages).  Looks
> like it wants @builddeps@, or else needs python3-h4py added explicitly, or
> as a Depends: in the pyfr binary package.

I've now forced python3-h5py into Depends which did not helped unfortunately.
(Build log in Salsa CI not yet finalised at the time of writing.)

Kind regards
   Andreas.

-- 
http://fam-tille.de

Helping hands needed to upgrade scipy

[Andreas Tille]

Hi,

I upgraded the experimental branch of scipy to contain the submodules
upstream includes.  I'm *not* convinced that we need them all -
hopefully we can get rid of boost (but upstream has some patches here)
and scipy-mathjax.

For the moment I've tried to build the experimental branch and ended
up with some issue where cython can't be found (should be cython3 for
sure)[1].

Unfortunately my spare time is occupied now by other more urgent tasks.
I'd be happy if someone else could review / pick up / continue from
here.

Kind regards
Andreas.


[1] https://salsa.debian.org/python-team/packages/scipy/-/jobs/3809903

-- 
http://fam-tille.de

Do we want to keep up pyfr?

[Andreas Tille]

Hi,

I pushed some changes to pyfr git[1] including the latest upstream
version.  Unfortunately the autopkgtest fails[2] with

   pkg_resources.DistributionNotFound: The 'h5py>=2.10' distribution was not 
found and is required by pyfr

(which is a bit strange since we have h5py 3.7.0.)  If someone might
dedicate some time to this issue we can keep pyfr.

Kind regards
Andreas.


[1] https://salsa.debian.org/science-team/pyfr
[2] https://salsa.debian.org/science-team/pyfr/-/jobs/3809459

-- 
http://fam-tille.de

Re: How much do we lose if we remove theano (+keras, deepnano, invesalius)?

[Andreas Tille]

Hi Thiago,

Am Mon, Jan 16, 2023 at 11:08:35AM -0300 schrieb Thiago Franco Moraes:
> Done! I removed both python3-theano and python3-keras.

Thanks for the quick response.  Autopkgtest currently fails due to

  Bug #1027851  pytorch FTBFS with Python 3.11 as default version

I think, I'll wait a bit until this is clarified.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: skimage: two build-time tests are failing in latest upload

[Andreas Tille]

Hi Ole,

Am Mon, Jan 16, 2023 at 12:09:22PM +0100 schrieb Ole Streicher:
> > === short test summary info 
> > 
> > FAILED
> > skimage/color/tests/test_colorconv.py::test_lab_lch_roundtrip_dtypes[float16]
> > FAILED
> > skimage/color/tests/test_colorconv.py::test_lab_lch_roundtrip_dtypes[float32]
> > = 2 failed, 7199 passed, 113 skipped, 1 xfailed, 8 xpassed, 825
> > warnings in 188.02s (0:03:08) =
> > E: pybuild pybuild:388: test: plugin distutils failed with: exit
> > code=1: cd /<>/.pybuild/cpython3_3.11/build; python3.11
> > -m pytest
> >
> > I admit I'd consider simply ignoring these two tests on s390x.
> 
> I forwarded them upstream [1]. If they don't have an advice, I will just
> disable them.

Thanks.  I admit I'd love to see skimage migrating to testing soon.  I
do not have any experience how quick upstream is with answering but if
you ask me, just excluding these two tests right now and fix the issue
later to win some time in the release process would be an attractive
idea to me.
 
> > BTW, I've just uploaded dask which hopefully might work properly so you
> > might consider reverting its exclusion done in your latest upload.
> 
> I will probably leave dask out here: it does not give additional
> functionality in the build. We *may* re-include it for testing, but even
> then my impression is that the tests are not really worthwile.

Perfectly fine for me - I just wanted to mention this since I was
writing about skimage.

Kind regards
   Andreas.

> [1] https://github.com/scikit-image/scikit-image/issues/6670

-- 
http://fam-tille.de

Re: How much do we lose if we remove theano (+keras, deepnano, invesalius)?

[Andreas Tille]

Hi Thiago,

Am Sat, Jan 14, 2023 at 07:50:27PM -0300 schrieb Thiago Franco Moraes:
> Hi Rebecca,
> 
> InVesalius can work without Theano (and Keras). It will use Pytorch.

Would you mind updating the packaging without Theano?  Currently its in
its Build-Depends.  Would it be sufficient to drop this Build-Depends?
If yes, I would upload a fixed package.

Kind regards
   Andreas.

-- 
http://fam-tille.de

skimage: two build-time tests are failing in latest upload

[Andreas Tille]

Hi Ole,

thanks for caring for skimage.  I realised that s390x fails building[1]
with:

=== short test summary info 
FAILED 
skimage/color/tests/test_colorconv.py::test_lab_lch_roundtrip_dtypes[float16]
FAILED 
skimage/color/tests/test_colorconv.py::test_lab_lch_roundtrip_dtypes[float32]
= 2 failed, 7199 passed, 113 skipped, 1 xfailed, 8 xpassed, 825 warnings in 
188.02s (0:03:08) =
E: pybuild pybuild:388: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.11/build; python3.11 -m pytest 

I admit I'd consider simply ignoring these two tests on s390x.

BTW, I've just uploaded dask which hopefully might work properly so you
might consider reverting its exclusion done in your latest upload.  But
I fully leave this to your decision and would be happy if you could deal
with the s390x issue.

Kind regards
   Andreas.


[1] 
https://buildd.debian.org/status/fetch.php?pkg=skimage&arch=s390x&ver=0.19.3-7&stamp=1673824604&raw=0

-- 
http://fam-tille.de

Re: transition: pandas 1.3 -> 1.5

[Andreas Tille]

Am Mon, Jan 09, 2023 at 01:44:40PM +0200 schrieb Graham Inggs:
> Hi Rebecca
> 
> On Fri, 6 Jan 2023 at 10:30, Rebecca N. Palmer  
> wrote:
> > Should this go ahead before the freeze?  I think yes if the new dask
> > works, but am open to disagreement.
> 
> Please go ahead.  With numpy 1:1.24.1-2 built on all release
> architectures, now is a good time.

Fine for me.

Thanks a lot for working on pandas
   Andreas.

-- 
http://fam-tille.de

Re: keras orphaned

[Andreas Tille]

Hi Stephen,

Am Wed, Jan 04, 2023 at 10:38:44PM +0100 schrieb Stephen Sinclair:
> I have unfortunately decided to orphan keras and related packages, as there
> are errors with the latest numpy that I cannot resolve, and upstream no
> longer maintains this software as an independent package from TensorFlow,
> so it is EOL as far as compatibility with Theano is concerned.

Thanks a lot for maintaining keras so far.
 
> Please feel free to pick up the packages if you think you can resolve the
> current bug reports, but since keras is now part of TensorFlow, it may be
> better to concentrate efforts there.

I would *really*, *really* love if people would concentrate fully on
TensorFlow - specifically the Python3 module which is not packaged yet.
Its so urgently needed by lots of Debian Med packages but I absolutely
fail to free some capacity myself.

Kind regards

 Andreas.

PS: TensorFlow is coordinated on debian-ai list - so you might like
to join there.

-- 
http://fam-tille.de

Debian Med sprint January 21.+22. 2023 (in person meeting)

[Andreas Tille]

Hi again,

I've just learned that the poll link below does not work.  The good
thing is that meanwhile sufficient reasons are given to decide for

21.+22. January 2023

I've added the date to the Wiki page.

Please add your name when you intend to come.  Please remember that it
would be good to arrive may be at Friday 20.1. noon to meet at some
place that needs to be determined and if possible stay until Monday
23.1. to do some after sprint socialising in Berlin.

Looking forward to see you all

 Andreas.

Am Thu, Dec 01, 2022 at 08:50:12AM +0100 schrieb Andreas Tille:
> Hi folks,
> 
> thanks to Sascha Steinbiss we can have our next in person meeting where
> we were in 2020 the last time.  His employer is offering rooms outside
> of their office hours (actually Saturday + Sunday).  All details are
> listed at the sprint wiki page:
> 
>
> https://wiki.debian.org/Sprints/2022/Debian%20Med%20Sprint%202023%2C%20Berlin
> 
> There are two options for the dates: 14.+15.1. or 21.+22.1.  To find out
> what weekend might fit best I've setup a poll.  Please note:  I just
> added the Fridays before and the Mondays after the weekends in question
> where we might be able to find alternative places or just do some
> socialising in Berlin.  The rooms are not available on Monday and
> Friday.  However, I intend to book the accomodation on site which has a
> cute meeting room which would be perfect for Friday afternoon / evening
> (no idea about network bandwith there but meeting is fine.)
> 
> So when filling in the poll please focus just on Saturday + Sunday but
> may be you consider the days around it for staying in Berlin:
> 
>http://whenisgood.net/dqhwatj
> 
> Looking forward to meet you all.  Newcomers are kindly invited (I've
> put "Mentoring" as first item on my agenda.)  We also welcome Debian
> contributors who just come for bug squashing - so feel free to use
> our sprint as bug squashing party for Debian Med related bugs.
> 
> Kind regards
> 
>  Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Re: MRs on salsa and letting janitor automate things

[Andreas Tille]

Hi Jelmer,

Am Thu, Dec 01, 2022 at 04:04:13PM + schrieb Jelmer Vernooij:
> One of the things you don't get when running these scripts manually rather 
> than
> waiting or the janitor is that it verifies the package still builds, passes
> autotests and generates binary diffs before proposing/pushing changes.

Great.  But I'm doing these build as well when dealing with the package.
;-)

> Although
> you do get a lot of those benefits either way, since most of lintian-brush's
> bug fixes are driven by the janitor running it across the entire archive.
> 
> Actually, I'm curious what you prefer about routine-update vs the janitor
> pushing/creating PRs? Is it just that you control the moment you work on a
> package vs having the changes pushed/proposed by an external agent?

I simply prefer triggering any changes myself.  The tools used by
Janitor are really cool and helpful - so thanks for the great work.  I
simply see no advantage if "someone else" does random commits to the
package I'm working on.
 
> > Routine-update is calling lintian-brush which is IMHO what Janitor is
> > doing.  Jelmer in CC in case I should run more scripts.
> 
> The janitor currently has the following "campaigns" that are part of its
> default set:
> 
>  * lintian-fixes (fixes various lintian-reported issues)
>  * apply-multiarch-hints (applies hints from the Multi-Arch hinter)
>  * deb-scrub-obsolete (remove no longer necessary dependencies, maintscripts,
>  migrates away from dependencies on transitional
>packages)
>  * orphan (update maintainer for orphaned packages to QA team)
>  * mia (drop uploaders who have been marked as MIA by the MIA team)

I'm happy about all these things done by lintian-brush.
 
> And several that are enabled for a select set of people only, not ready for
> mainstream (yet?):
> 
>  * fresh-releases (merges new upstream releases, refreshes patches, bumping
>dependency versions, etc)
>  * uncommitted (import archive changes not in VCS, e.g. for NMUs)

Thanks a lot for your cool QA tools

 Andreas. 

-- 
http://fam-tille.de

Re: MRs on salsa and letting janitor automate things

[Andreas Tille]

Hi again,

Am Thu, Dec 01, 2022 at 01:55:43PM +0100 schrieb PICCA Frederic-Emmanuel:
> > As I tried to explain, routine-update does all what Janitor is doing
> > (please let me know if not than I'd include the actual Janitor code)
> > plus other things Janitor can't do.  I'm fine with whatever the team
> > might prefer and I can cope with Janitor changes, but its not my
> > preference.
> 
> It seems to me that a script provided by janitor should be used by 
> routine-update in order to avoid this problem.

This *is* the case and perfectly intendend.

> Is there a sort of generic command in janitor which run all the janitors 
> scripts ?

Routine-update is calling lintian-brush which is IMHO what Janitor is
doing.  Jelmer in CC in case I should run more scripts.

Kind regards
   Andreas. 

-- 
http://fam-tille.de

Re: MRs on salsa and letting janitor automate things

[Andreas Tille]

Hi Stuart,

Am Wed, Nov 30, 2022 at 10:58:06AM +1100 schrieb Stuart Prescott:
> 
> While there is a substantial overlap in the feature sets, one is not a
> subset of the other.
> 
> - routine-update does some great things like normalising packaging. That's
> something Janitor can't do because people would scream about an automated
> tool touching their precious whitespace.
> 
> - Janitor applies multi-arch hints, and looks at obsolete versioned
> dependencies — these are things that routine-update can't do because it
> doesn't have a holistic view of the archive.

That's not true since routine-update calls the same routines as Janitor.

> Janitor is also run
> automatically rather than only when the maintainer is seeking to update the
> package, meaning that improvements can accrue over time.

IMHO that's quite some advantage.  I see no relevance in changes that
are just end up inside the git repository and are possibly bit-rotting
there.

> Janitor updates
> also cause CI to be run, meaning that regressions such as a FTBFS caused by
> other packages changing get spotted earlier.

That's a valid point.
 
> I don't see any reason to say that tools are mutually exclusive — let's let
> Janitor make improvements and when packages need updating, we can have
> routine-update make some more?

As I tried to explain, routine-update does all what Janitor is doing
(please let me know if not than I'd include the actual Janitor code)
plus other things Janitor can't do.  I'm fine with whatever the team
might prefer and I can cope with Janitor changes, but its not my
preference.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: MRs on salsa and letting janitor automate things

[Andreas Tille]

Hi Dima,

Am Tue, Nov 29, 2022 at 06:56:02PM -0800 schrieb Dima Kogan:
> Hi Nilesh and Stuart. That email on debian-devel describes my use case
> well. My packages are vanilla-enough that there's little value in doing
> anything more than Build-Depends: debhelper (>=11) and sticking "11" in
> debian/compat or something like that. Let me know if this has some major
> downsides I'm not seeing.

IMHO its sensible to follow the latest toolset version sooner or later.
There are several sensible features and if your packages are vanilla and
simple there is no good reason to stick to any specific debhelper compat
version.

Kind regards
Andreas.

-- 
http://fam-tille.de

Debian Med sprint January 2023 (in person meeting)

[Andreas Tille]

Hi folks,

thanks to Sascha Steinbiss we can have our next in person meeting where
we were in 2020 the last time.  His employer is offering rooms outside
of their office hours (actually Saturday + Sunday).  All details are
listed at the sprint wiki page:

   https://wiki.debian.org/Sprints/2022/Debian%20Med%20Sprint%202023%2C%20Berlin

There are two options for the dates: 14.+15.1. or 21.+22.1.  To find out
what weekend might fit best I've setup a poll.  Please note:  I just
added the Fridays before and the Mondays after the weekends in question
where we might be able to find alternative places or just do some
socialising in Berlin.  The rooms are not available on Monday and
Friday.  However, I intend to book the accomodation on site which has a
cute meeting room which would be perfect for Friday afternoon / evening
(no idea about network bandwith there but meeting is fine.)

So when filling in the poll please focus just on Saturday + Sunday but
may be you consider the days around it for staying in Berlin:

   http://whenisgood.net/dqhwatj

Looking forward to meet you all.  Newcomers are kindly invited (I've
put "Mentoring" as first item on my agenda.)  We also welcome Debian
contributors who just come for bug squashing - so feel free to use
our sprint as bug squashing party for Debian Med related bugs.

Kind regards

 Andreas.

-- 
http://fam-tille.de