Re: Dropping big-endian (s390x) support for some r-bioc-* packages

[Andreas Tille]

Am Wed, Oct 02, 2024 at 08:34:24PM +0900 schrieb Charles Plessy:
> Le Wed, Oct 02, 2024 at 12:53:56PM +0200, Michael R. Crusoe a écrit :
> > 
> > So I propose to add a "architecture-is-little-endian" build-dep to the 
> > following packages and request the removal of their s390x builds from the 
> > archive:

+1

> I am all for it but I would like to propose something bigger.
> 
> Let r-bioc-biocgenerics (or r-bioc-biocbase) provide a virtual package
> called r-bioc-supported-architectures available for amd64 and arm64
> only, and make all r-boc-* depend on it at the next BioC release (which
> takes place this month).

It might possibly a good idea to fix the architure depencency inside
r-bioc-biocgenerics (or r-bioc-biocbase).  However, there are new
interesting architectures coming up (like riscv64) and excluding those
without good reason is IMHO not rectified by the problems we've seen in
the past.
 
> People who want r-bioc-* packages on other architectures can first work
> on portability issues outside the Debian main archive, and can create 
> a local version of r-bioc-supported-architectures to enable building
> BiocC on what they want.  If the mass-build looks sustainable we can
> consider add, maybe after consulting BioC upstream about future
> prospects.
> 
> I think that bioinformaticians can aim for other architectures if they
> have appetite for the work it represents, and portrers can aim for
> bioinformatics if they have the workforce for it, but by default we
> should not build these packages everywhere because it puts the whole
> burden on mostly just us.

I think architecture-is-little-endian on r-bioc-biocgenerics will solve
our current problems without creating extra work for future
architectures.  I'm also scared by the extra work we have to remove
all those architectures that are currently building and testing fine.

Kind regards
   Andreas.

-- 
https://fam-tille.de

Re: GNUmed (-client/-server): new upstream available

[Andreas Tille]

Am Wed, Sep 25, 2024 at 08:41:43PM +0200 schrieb Karsten Hilbert:
> 
> It should be. Andreas had been packaging GNUmed for the last
> ten years or so. Off the top of my head I don't recall
> changes that would ask for a change in packaging
> infrastructure, this being a maintenance release.

It was a `routine-update`-ish change the last couple of
years.
 
Kind regards
Andreas. 

-- 
https://fam-tille.de

Re: Developer statistics

[Andreas Tille]

Am Wed, Sep 18, 2024 at 01:24:47PM + schrieb Nilesh Patra:
> Offtopic, but do you see a possibility of adding a SSL cert to
> blends.debian.net?
> 
> The “http://” URL doesn’t work for me when I’m using a machine I don’t
> own, as the network administrator’s settings block it.

Its on my long term todo list but never made it on top. :-(

Kind regards
 Andreas. 

-- 
https://fam-tille.de

Re: Developer statistics

[Andreas Tille]

Am Wed, Sep 18, 2024 at 12:48:07PM +0200 schrieb Joost van Baal-Ilić:
> FYI: And the output of 'teammetrics' is collected and published at
> http://blends.debian.net/liststats/ (took me some clicks to find that one).

Ahhh, sorry, I assumed that's known here.  The reason why I did not
pointed there is, that these graphs do not provide the answer to some
general data about some developers activities.  Its just split over
teams.

Kind regards
Andreas.

-- 
https://fam-tille.de

Re: Developer statistics

[Andreas Tille]

Am Wed, Sep 18, 2024 at 12:56:46PM +0300 schrieb Andrius Merkys:
> > I would have a look at https://wiki.debian.org/UltimateDebianDatabase .
> 
> Thanks - I gave UDD a look and managed to get what I wanted quite quickly.

Nice you got what you need.  I'd like to add that you can find a couple
of useful queries inside the teammetrics Git repository[1].

For those who are interested:  I'm updating my Debian Maintainer
homepage daily by using queries like this:

   
https://salsa.debian.org/tille/public_html/-/blob/main/update_my_stats?ref_type=heads

(The update script is actually a python script but uses the same
queries.)

Hope this helps
Andreas.

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

-- 
https://fam-tille.de

Re: About removing libsis-jhdf5-java from unstable

[Andreas Tille]

Hi Pierre,

Am Mon, Sep 16, 2024 at 07:24:04AM +0200 schrieb Pierre Gruet:
> I would like to remove libsis-jhdf5-java from unstable. To be accurate, it
> is rather a proposal by pini in the bug log
>   https://bugs.debian.org/1078968
> which is about libsis-jhdf5-java blocking the upcoming auto-hdf5 transition.
> pini and I looked at it and it seems difficult to see what changes would be
> needed in libsis-jhdf5-java to make it build against hdf5 1.14.x .
> Meanwhile, upstream does not seem to be active anymore, the orig repo is
> unreachable...
> 
> I have reworked the two rdeps of the package, fastqc and megan-ce, so that
> they don't need sis-jhdf5.

The only reason why sis-jhdf5 was packaged was fastqc (possibly later
megan-ce was profitting from it).

> This was done by removing some classes from the
> build. This does not affect their rdeps. fastqc and megan-ce have reached
> testing, so that libsis-jhdf5-java now has no rdep in unstable nor testing.
> 
> If no voice is raised, I will proceed with the removal of libsis-jhdf5-java
> from unstable within a week.

Sounds perfectly fine as long as fastqc and megan-ce are fine and are
passing their tests.
 
> Cc-ing the current other uploaders so that no one misses it.

Thanks for the ping and caring for Debian Med Java packages.

Kind regards
Andreas.

-- 
https://fam-tille.de

Re: Bug#1079958: Should epigrass be removed from unstable?

[Andreas Tille]

Hi,

probably we should remove epigrass.  It seems way harder to get dash and
panel trough NEW than getting epigrass accepted again once these might
be in Debian.

Sad to see it go since it could help in the next pandemic but if its not
working there is no point to leave it.

CCing Debian Med list to find motivated persons for dash ... which might
be great for lots of scientific tools.

Kind regards
 Andreas.

-- 
https://fam-tille.de

Re: PyMol 3.0 is out - salsa upload works for me

[Andreas Tille]

Hi Étienne,

Am Sat, Jul 20, 2024 at 12:16:19AM +0200 schrieb Étienne Mollier:
> Thanks, I was going to proceed to the upload, but it occurred to
> me that pymol is a debichem team package, team which I am not
> part of.  I requested salsa access to at least be able to push a
> tag and pinged the alioth list.  I thought it would be more
> appropriate that I join before begining to sponsor uploads and
> push tags.

It makes sense to join DebiChem team in any case since in its repository
are some packages which are shared with Debian Med tasks.  I'm very
positive that mbanck will give permission very easily.

Kind regards
Andreas, preparing for the trip to Busan.

-- 
https://fam-tille.de

python-questplus FTBFS on i386

[Andreas Tille]

Hi,

in my attempt to fix #1074664 I upgraded to latest upstream and missed
the fact that it does not build on i386[1].  I have no capacity to work
on this - hopefully someone might be able to catch up.

Thanks a lot
   Andreas.

[1] https://salsa.debian.org/med-team/python-questplus/-/jobs/5980179
https://buildd.debian.org/status/package.php?p=python-questplus

-- 
https://fam-tille.de

Re: Bug#1076129: tao-json: FTBFS: add support for loongarch64

[Andreas Tille]

Control: tags -1 help

Hi,

Am Thu, Jul 11, 2024 at 03:46:30PM +0800 schrieb zhangdandan:
> Source: tao-json
> Version: 0.0+git20200604.f357d72-2
> Severity: normal
> Tags: patch
> User: debian-loonga...@lists.debian.org
> Usertags: loong64

Thanks a lot for your patch.  While I currently stalled my packaging
work drastically, patches have high priority.  I've applied it in Git
and updated it to the new upstream version.

Unfortunately this version does not build for other reasons as you
can see in Salsa CI[1].

Thus tagging the bug help and CC the great Debian Med team who took
over lots of my packaging duties.  I guess its a low hanging fruit
to fix this but I currently do not have the capacity to track this
down.

Kind regards
Andreas.

PS: It would be great if the patch would be forwarded upstream once
it has proven to work.
When doing so asking upstr

[1] https://salsa.debian.org/med-team/tao-json/-/jobs/5964128

-- 
https://fam-tille.de

Re: Bug#1074291: RFS: ghmm/0.9~rc3-7 [RC] [Team] -- General Hidden-Markov-Model library - tools

[Andreas Tille]

Hi Bo,

thanks a lot for your fix.  I've sponsored your commits.

See you in Busan (if I'm not misleaded and if so please approach me)
Andreas.

Am Thu, Jun 27, 2024 at 02:26:45PM +0800 schrieb Bo YU:
> Hi team,
> 
> https://salsa.debian.org/med-team/ghmm/-/tree/master?ref_type=heads
> 
> Please help me to review the upload for ghmm in your free time. We can
> ignore the piuparts test failed due to old binary built with
> python3.11 on Debian archives.
> 
> TIA.
> 
> 
> BR,
> Bo
> 
> 
> On Thu, Jun 27, 2024 at 3:42 AM Bastian Germann  wrote:
> >
> > On Wed, 26 Jun 2024 13:12:46 +0800 Bo YU  wrote:
> > >  ghmm (0.9~rc3-7) unstable; urgency=medium
> > >  .
> > >* Team upload.
> > >* Add fix_imp_func_issue.patch to fix ftbfs issue.(Closes: #1073355)
> >
> > For team uploads please push your changes to git to show that you are part 
> > of the team.
> > I guess the Med Team has some different channel to ask for sponsorship. 
> > Please use that in the future.
> 
> 

-- 
https://fam-tille.de

Re: python-cogent [Was: Bug#950598: Chain of Dependencies prevents closing RC bugs]

[Andreas Tille]

Good work, thanks a lot!  Andreas.

Am Wed, Jun 26, 2024 at 10:50:05PM -0300 schrieb Emmanuel Arias:
> Hi!
> 
> I've just upload python-cogent.
> 
> After try build doc package I realized that we need kaleido package in
> Debian (see #1074333). I tried create a patch to avoid that but make sense
> package kaleido instead to create a big patch to avoid it.
> 
> Also I removed the privacy leak due require.js lib.
> 
> Thanks!
> 
> Cheers,
> Emmanuel
> 
> On Wed, Jun 26, 2024 at 09:11:55AM +0200, Andreas Tille wrote:
> > Thanks a lot to you both,  I commited
> > 
> >   Build-Depends: architecture-is-64-bit, architecture-is-little-endian
> > 
> > as suggested by Ananthu and leave you the lead / upload of further
> > changes.
> > 
> > Thanks again,
> > Andreas.
> > 
> > Am Wed, Jun 26, 2024 at 01:28:10AM -0300 schrieb Emmanuel Arias:
> > > Hi,
> > > 
> > > The packages looks good to me. I'm trying a second shoot with
> > > jupyter-sphinx, but it's too late for me, tomorrow I will continue and
> > > uploaded.
> > > 
> > > Ananthu, thanks for updated it!
> > > 
> > > Cheers,
> > > Emmanuel
> > > 
> > > On Wed, Jun 26, 2024 at 03:14:26AM +0530, Ananthu C V wrote:
> > > > Hi Andreas,
> > > > 
> > > > I had a look at python-cogent and updated it to the latest version.
> > > > It builds fine, so I have pushed the changes to the team repo.
> > > > 
> > > > I tried re-enabling python3-jupyter-sphinx as a build dependency,
> > > > but while I was able to stop sphinx-autodoc from actually trying
> > > > to import 'cogent3' which is the root package and failing, using
> > > > 'autodoc_mock_imports = ["cogent3"]', the jupyter-execute extension
> > > > (jypyter_sphinx.execute) still tries to invoke the import later inside
> > > > the jupyter notebook cells and fails saying 'unable to import cogent3'.
> > > > As such build fails and I was forced to disable it again.
> > > > 
> > > > Yet another thing is that, the package could probably use the
> > > > 'architecture-is-little-endian' virtual package now maybe from the state
> > > > of its arch definition, but I did not touch that since I am not awfully
> > > > familiar with how that works.
> > > > 
> > > > I do not have enough bandwidth to spend anymore time on this for now,
> > > > that means the lintian warnings also stay. Anyone can pick up from here
> > > > and/or upload (all assuming salsa ci is happy with it).
> > > > 
> > > > On Tue, Jun 25, 2024 at 04:19:43PM +0200, Andreas Tille wrote:
> > > > > Hi,
> > > > >
> > > > > I wonder whether someone could have a look at python-cogent.  It 
> > > > > might make
> > > > > sense to upgrade to the latest stable release.
> > > > 
> > > > Best,
> > > > Ananthu
> > > > 
> > 
> > 
> > 
> > -- 
> > https://fam-tille.de



-- 
https://fam-tille.de

Re: python-cogent [Was: Bug#950598: Chain of Dependencies prevents closing RC bugs]

[Andreas Tille]

Thanks a lot to you both,  I commited

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

as suggested by Ananthu and leave you the lead / upload of further
changes.

Thanks again,
Andreas.

Am Wed, Jun 26, 2024 at 01:28:10AM -0300 schrieb Emmanuel Arias:
> Hi,
> 
> The packages looks good to me. I'm trying a second shoot with
> jupyter-sphinx, but it's too late for me, tomorrow I will continue and
> uploaded.
> 
> Ananthu, thanks for updated it!
> 
> Cheers,
> Emmanuel
> 
> On Wed, Jun 26, 2024 at 03:14:26AM +0530, Ananthu C V wrote:
> > Hi Andreas,
> > 
> > I had a look at python-cogent and updated it to the latest version.
> > It builds fine, so I have pushed the changes to the team repo.
> > 
> > I tried re-enabling python3-jupyter-sphinx as a build dependency,
> > but while I was able to stop sphinx-autodoc from actually trying
> > to import 'cogent3' which is the root package and failing, using
> > 'autodoc_mock_imports = ["cogent3"]', the jupyter-execute extension
> > (jypyter_sphinx.execute) still tries to invoke the import later inside
> > the jupyter notebook cells and fails saying 'unable to import cogent3'.
> > As such build fails and I was forced to disable it again.
> > 
> > Yet another thing is that, the package could probably use the
> > 'architecture-is-little-endian' virtual package now maybe from the state
> > of its arch definition, but I did not touch that since I am not awfully
> > familiar with how that works.
> > 
> > I do not have enough bandwidth to spend anymore time on this for now,
> > that means the lintian warnings also stay. Anyone can pick up from here
> > and/or upload (all assuming salsa ci is happy with it).
> > 
> > On Tue, Jun 25, 2024 at 04:19:43PM +0200, Andreas Tille wrote:
> > > Hi,
> > >
> > > I wonder whether someone could have a look at python-cogent.  It might 
> > > make
> > > sense to upgrade to the latest stable release.
> > 
> > Best,
> > Ananthu
> > 



-- 
https://fam-tille.de

python-cogent [Was: Bug#950598: Chain of Dependencies prevents closing RC bugs]

[Andreas Tille]

Hi,

I wonder whether someone could have a look at python-cogent.  It might make
sense to upgrade to the latest stable release.

Thanks a lot for all who helped me managing my DPL duty and ignore things
I usually would have grabbed up.

Kind regards
  Andreas.

- Weitergeleitete Nachricht von Colin Watson  -

Date: Tue, 25 Jun 2024 14:38:59 +0100
From: Colin Watson 
To: Andreas Tille , 950598-cl...@bugs.debian.org
Cc: debian-rele...@an3as.eu, Debian Med Project List 
, 1010...@bugs.debian.org
Subject: Re: Bug#950598: Chain of Dependencies prevents closing RC bugs

On Fri, Feb 10, 2023 at 11:16:49AM +0100, Andreas Tille wrote:
> to fix
> 
>   #1030884 python-cogent: FTBFS (ImportError: cannot import name 'float' from 
> 'numpy')
> 
> and let it migrate to testing it needs to wait for
> 
>   #950598 python3-jupyter-sphinx: package relies on unavailable 
> `ipywidgets.embed` module
> 
> which in turn needs
> 
>   #896460 Please package ipywidgets 7
> 
> which needs another not yet packaged precondition.

#896460 has been fixed now for a while, testing has ipywidgets 8.1.1-2,
and jupyter_sphinx.execute can be imported.  As a result I'm closing
this bug, and I think you can revert whatever workarounds you added to
python-cogent.

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]


- Ende weitergeleitete Nachricht -

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

Re: Upgrading fis-gtm and closing CVE-2021-44496 CVE-2021-44504

[Andreas Tille]

Hi Bhaskar,

it seems Amul is not actively working on fis-gtm package any more.
Could you name any new contact person for the Debian package?

Kind regards
   Andreas.

Am Mon, Apr 01, 2024 at 02:51:26PM +0200 schrieb Andreas Tille:
> Ping?
> 
> Am Sat, Dec 09, 2023 at 06:13:24PM +0100 schrieb Andreas Tille:
> > Hi Amul,
> > 
> > I realised that fis-gtm is lagging behind upstream some versions and the
> > Debian packaged fis-gtm is featuring CVE-2021-44496 and CVE-2021-44504.
> > It would be great if you could upgrade the Debian package to the latest
> > upstream version.
> > 
> > Kind regards,
> > Andreas.
> > 
> > -- 
> > http://fam-tille.de
> > 
> > 
> 
> -- 
> https://fam-tille.de
> 
> 

-- 
https://fam-tille.de

Fwd: SPAdes 4.0 is released!

[Andreas Tille]

Hi,

if someone might have time to upgrade SPAdes to its latest version this
would be great.  Major upgrades of the spades Debian package are
unfortunately not straightforward due to several code copies shipped with
upstream.  Some of them are not identical with the original code.

Kind regards
   Andreas.

- Weitergeleitete Nachricht von SPAdes no reply  -

From: SPAdes no reply 
Subject: SPAdes 4.0 is released!

Dear SPAdes user

We have finally released new SPAdes 4.0!

Since its birth in 2012 SPAdes has always been a free and open-source software,
mainly supported by various academic and non-profit organization grants.
However, since 2022 SPAdes is not developed within a certain academic
institution anymore. SPAdes is currently maintained and supported by an
international group of volunteering contributors, namely, a SPAdes team.

Our old website is not active anymore. We also do not have a dedicated support
email. From now on we are relying only on our GitHub repo. Please, download
releases and report issues there. We also reworked and improved SPAdes
documentation.

SPAdes 4.0 will most likely be the last major release introducing new features
and significant changes. No further development is currently planned.
Nonetheless, we strongly intend to continue making bug-fix releases and
supporting our users. And as always - patches are welcome!

With love and happy assembling,
SPAdes team

unsubscribe

*

- Ende weitergeleitete Nachricht -

-- 
https://fam-tille.de

Re: Migration to htslib ecosystem 1.20.

[Andreas Tille]

Hi,

thank you for all your work
Andreas.

Am Thu, May 30, 2024 at 09:06:11PM +0200 schrieb Étienne Mollier:
> Étienne Mollier, on 2024-05-30:
> > Some of the htslib packages were already available in their 1.20
> > version counterpart, so I tried to finish the migration
> > yesterday as I had some time.  I seem to have fumbled a bit the
> > samtools upload by forgetting to declare it requires libhts-dev
> > 1.20 specifically, as otherwise tests are not passing.  Giveback
> > attempts are still capturing htslib 1.19, so I prepared a
> > samtols upload with bumped build dependency version.  In the
> > meantime, there may be stray uninstallable samtools-test
> > packages in sid, as the arch-all package build went through, but
> > not the arch-anys.  Otherwise not too much to worry about.
> > 
> > If everything goes according to the plan, the htslib 1.20
> > ecosystem should be consistent in testing in a couple of days.
> 
> Erm, things didn't go according to the plan.  Thankfully Salsa
> caught properly my failure to handle properly arch-any &
> no-arch-all builds (which went hidden behind the version
> discrepancy issue).  Anyway this should be fixed in samtools
> 1.20-3 upload (I failed to dcut rm 1.20-2 in time).  Hopefully
> it is good for real now.
> 
> That's some entropy thrown at the archive in little time.
> Perhaps I should favor resting now and see how things evolved
> tomorrow.
> 
> Have a good night,
> -- 
>   .''`.  Étienne Mollier 
>  : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
>  `. `'   sent from /dev/pts/1, please excuse my verbosity
>`-on air: England - The Imperial Hotel



-- 
https://fam-tille.de

Re: [Help] Re: [bredelings/BAli-Phy] Test suite error in 4.0-beta7 (Issue #17)]

[Andreas Tille]

Am Wed, May 29, 2024 at 09:39:01AM +0200 schrieb Étienne Mollier:
> I'm having a look at BAli-Phy 4.0 beta 13 and after a few
> adjustments, I see the test suite is passing alright.  I pushed
> my changes on salsa and am preparing an experimental upload.

Thanks a lot
Andreas.

-- 
https://fam-tille.de

[Help] Re: [bredelings/BAli-Phy] Test suite error in 4.0-beta7 (Issue #17)]

[Andreas Tille]

Hi,

can anybody check bali-phy?

Kind regards
   Andreas.

- Weitergeleitete Nachricht von Benjamin Redelings 
 -

Date: Tue, 28 May 2024 05:42:45 -0700
From: Benjamin Redelings 
To: bredelings/BAli-Phy 
Cc: Andreas Tille , Author 
Subject: Re: [bredelings/BAli-Phy] Test suite error in 4.0-beta7 (Issue #17)

Hi Andreas,
Would you be able to build beta13 for experimental?
-BenRI

-- 
Reply to this email directly or view it on GitHub:
https://github.com/bredelings/BAli-Phy/issues/17#issuecomment-2135124799
You are receiving this because you authored the thread.

Message ID: 

- Ende weitergeleitete Nachricht -

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

Could someone have a look into bali-phy [notificati...@github.com: Re: [bredelings/BAli-Phy] Test suite error in 4.0-beta7 (Issue #17)]

[Andreas Tille]

Hi folks,

this is residing since some time in my inbox but I will not be able to
deal with this.  It would be great if someone might subscribe the issue
below and update the bali-phy package accordingly.

Kind regards
   Andreas.

- Weitergeleitete Nachricht von Benjamin Redelings 
 -

Date: Mon, 01 Apr 2024 07:32:34 -0700
From: Benjamin Redelings 
To: bredelings/BAli-Phy 
Cc: Andreas Tille , Author 
Subject: Re: [bredelings/BAli-Phy] Test suite error in 4.0-beta7 (Issue #17)

Hi Andreas,
I finally did a beta9 release, so the issue should be fixed.  Would you be able 
to build beta9 for experimental?
-BenRI

-- 
Reply to this email directly or view it on GitHub:
https://github.com/bredelings/BAli-Phy/issues/17#issuecomment-2029850883
You are receiving this because you authored the thread.

Message ID: 

- Ende weitergeleitete Nachricht -

-- 
https://fam-tille.de

Re: Binary conflict between Midnight Commander and MinIO Client

[Andreas Tille]

Hi,

Am Mon, Apr 22, 2024 at 09:28:29AM +0200 schrieb Philip Hands:
> >> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli
> 
> Might I suggest that the link goes the other way, so that the symlink
> lives in /usr/bin?  That way the existence of the lib directory is
> somewhat self-documenting.

That's an interesting hint.  In Debian Med we are using a common
directories

/usr/lib/debian-med/bin/
/usr/lib/debian-med/man/

where those binaries will be moved to and have some kind of a
README.Debian template[1].  Changing this to have the real executable /
manpage to /usr/lib/debian-med/* makes sense.
 
We simply advise Debian Med users to set PATH to that dir and have
all the name-clashed binaries inside Debian Med without additional
interaction.

Kind regards
Andreas.

[1] 
https://salsa.debian.org/med-team/ea-utils/-/blob/master/debian/README.Debian?ref_type=heads

-- 
https://fam-tille.de

If someone might care for raxml-ng this would be great (Was: [amkozlov/raxml-ng] What libpll code is really needed (Issue #164))

[Andreas Tille]

Hi,

I never managed to finish raxml-ng packaging which would be a great
thing to have.  Some hints about its preconditions can be found
inn the issue linked below.

Kind regards
   Andreas.

- Weitergeleitete Nachricht von Alexey Kozlov  
-

Date: Fri, 18 Aug 2023 14:17:07 -0700
From: Alexey Kozlov 
To: amkozlov/raxml-ng 
Cc: Andreas Tille , Author 
Subject: Re: [amkozlov/raxml-ng] What libpll code is really needed (Issue #164)

> If I simply would package libpll-2 in the very place where libpll was 
> packaged and I keep *that* name (without the -2) this would be pretty 
> convenient since its not a new Debian package and does not need any new 
> processing. Do you think this is the correct way to go?

Yes, I think this is the way to go.

In fact, in the next major raxml-ng release, both `libpll-2` and `pll-modules` 
will be superseded by the new lib `coraxlib`:

https://codeberg.org/Exelixis-Lab/coraxlib

This should hopefully solve the long-lasting historical name confusion.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/amkozlov/raxml-ng/issues/164#issuecomment-1684443628
You are receiving this because you authored the thread.

Message ID: 

- Ende weitergeleitete Nachricht -

-- 
https://fam-tille.de

Re: Status of the t64 transition

[Andreas Tille]

Hi Sebastian,

thank you for your work on t64 transition.

Am Thu, Apr 18, 2024 at 09:22:02PM +0200 schrieb Sebastian Ramacher:

I've spotted these Debian Med packages.

> gentle
> jellyfish
> quorum
> sbmltoolbox

No idea how we can help here.  Please let us know if we can do
something.

> anfo

We like to fix gcc-12 issues (#1012893) in anfo but so far nobody
managed to do so since it seems to be quite complex.  If we are
blocking progress with this package its probably a sign that it
should be removed from Debian.

> blasr

We try to work on #1067374.

> freebayes

Upstream is working on bug #1067271.

> vg

This package is in a bad state in any case and we are aware of this.
However, could you explain in how far is this affecting t64 transition
since 32bit architectures are excluded?

> If you maintain any of the packages above, please check their status and
> help get them fixed. Any help in filing bugs, fixing packages,
> requesting removals, etc. is appreciated so that we can look into
> unblocking the whole stack and migrate it to testing.

I fixed two packages of Debian Python Team and pinged about some
packages in Debian Science Team.

Kind regards
Andreas. 

-- 
https://fam-tille.de

Re: Emboss not migrating due to autopkgtest error on s390x

[Andreas Tille]

Am Wed, Apr 17, 2024 at 03:20:27PM +0300 schrieb Andrius Merkys:
> I have added the build-time test and filed the needed RM bugs + removed
> python-biopython test-dependency on emboss on s390x.

Thanks a lot
   Andreas. 

-- 
https://fam-tille.de

Re: Emboss not migrating due to autopkgtest error on s390x

[Andreas Tille]

Am Tue, Apr 16, 2024 at 07:33:15PM +0530 schrieb Nilesh Patra:
> > I would suggest the following course of action for emboss:
> > 
> > 1. Add a build-time test calling emboss executable(s). This way builds will
> > fail on s390x (and possibly other architectures) until #1069098 is fixed.
> > 
> > 2. RM emboss for s390x without excluding s390x from build architectures.
> > 
> > This way emboss will be able to migrate and there will be no action needed
> > if/when #1069098 is fixed.
> 
> Makes sense to me.

+1

Kind regards
Andreas.

-- 
https://fam-tille.de

We are currently maintaining exactly 1000 packages in main

[Andreas Tille]

Hi folks,

by chance I looked at

   
https://qa.debian.org/developer.php?email=debian-med-packaging%40lists.alioth.debian.org

and realised:

   main (1000)

;-)

Kind regards
Andreas.

-- 
https://fam-tille.de

Emboss not migrating due to autopkgtest error on s390x

[Andreas Tille]

Hi,

according to tracker[1] emboss is not migrating due to a test suite
error on s390x[2].  IMHO the appropriate thing to do is to also remove
s390x architecture - but we also need to care for all rdepends (again
after removing these for 32bit).  Any volunteer to file the according
bugs?

I guess adding architecture-is-little-endian to Build-Depends will
to the trick to prevent building on s390x.

Kind regards
   Andreas.


[1] https://tracker.debian.org/pkg/emboss
[2] https://ci.debian.net/packages/e/emboss/testing/s390x/43624748/

-- 
https://fam-tille.de

Re: Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf

[Andreas Tille]

Hi,

Am Wed, Apr 10, 2024 at 03:33:53PM -0700 schrieb Steven Eker:
> I like that solution since I believe there are 64-bit platforms where long
> is 32-bits. I've updated my development version thus:
> 
>   //
>   //    timeValue.tv_sec is 64-bit since Linux kernel 5.6 but GMP doesn't
> yet have support
>   //    for long long which is a problem on platforms where long is less
> than 8 bytes.
>   //
> #if SIZEOF_LONG < 8
>   double seconds = timeValue.tv_sec;
> #else
>   long seconds = timeValue.tv_sec;
> #endif
>   mpz_class nanoSeconds(seconds);

Sounds like some working solution.  It would help if you could tag a new
released to enable us fetching a fresh tarball incorporatinig this
change.
 
> Of course I expect to drop support for 32-bit before 2038 - certainly when
> one our dependencies drops support. But I've gotten a bug report for
> building Maude on a Raspberry Pi.

Raspian is based on Debian and if the 32bit ARM architectures fail here
Raspian people have a problem.

Kind regards
   Andreas. 

-- 
https://fam-tille.de

Re: Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf

[Andreas Tille]

Hi,

I'd suggest to set

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

and remove 32bit architectures of maude.

Kind regards
   Andreas.

-- 
https://fam-tille.de

Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages

[Andreas Tille]

Hi,

Am Mon, Apr 01, 2024 at 09:12:49PM +0200 schrieb Sascha Steinbiss:
> 
> > If there is agreement with this, then I would like an amend the
> > Debain-Med team policy to make it clear that we, as a community of
> > package maintainers and users, are okay with removing support for 32-bit
> > and/or big-endian systems without discussion.
> 
> I'd probably not go as far as to eagerly _remove_ all support for 32-bit
> as in RM'ing existing packages that still build and work fine.

ACK.  Finally also removing packages creates some work we finally want
to save.  I think we should simply apply this policy to new packages and
those who start failing for whatever reason with no obvious fix / patch
provided.

> I know that many others in Debian care about their specific niche
> architecture and would be offended at some random maintainer just
> dismissing their subjectively reasonable request to fix things. Making
> it known beforehand where Debian Med puts its focus would help in making
> such situations feel less personal.

Fully ACK.
 
> > New packages that aren't "Architecture: all": 1. Add
> > "architecture-is-64-bit" and "architecture-is-little-endian" to the
> > "Build-Depends" list in "debian/control".
> 
> Nice, didn't know about these virtual packages before. Makes sense for
> new packages -- would this result in an equivalent effect as restricting
> the "Architecture" list in all binary packages?

If we agree about the policy to restrict new packages to the said
architectures I'd recommend adding this to our package template[1].
 
> > Removing architectures in existing packages:
> [...]
> 
> This approach looks good. As I said, I'd rather only go this way if the
> maintainer in question notices that there is a need to do so.
> 
> I agree that if it turns out that for a package to be removed there are
> reverse dependencies outside of Debian Med's maintainership which would
> be affected, we would need to coordinate with the maintainers of these
> reverse dependencies. My gut feeling says these cases will be
> exceptional though.

Sure.
 
> I think it could also make sense to think of what to do for other
> architectures that are not yet covered in Michael's proposal, such as
> (subjectively) obscure archs that still are considered official release
> architectures (riscv64, mips64el, ...) or

As long as these do not create any trouble its perfectly fine to support
these.

> all the non-official architectures
> (alpha, hurd-*, m68k, ...)?

Hurd will be available next year. ;-P

Kind regards
Andreas.

[1] 
https://salsa.debian.org/med-team/community/package_template/-/blob/master/debian/control?ref_type=heads

-- 
https://fam-tille.de

Re: Upgrading fis-gtm and closing CVE-2021-44496 CVE-2021-44504

[Andreas Tille]

Ping?

Am Sat, Dec 09, 2023 at 06:13:24PM +0100 schrieb Andreas Tille:
> Hi Amul,
> 
> I realised that fis-gtm is lagging behind upstream some versions and the
> Debian packaged fis-gtm is featuring CVE-2021-44496 and CVE-2021-44504.
> It would be great if you could upgrade the Debian package to the latest
> upstream version.
> 
> Kind regards,
> Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
https://fam-tille.de

Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages

[Andreas Tille]

Hi Charles,

Am Fri, Mar 29, 2024 at 03:48:07PM +0900 schrieb Charles Plessy:
> > For the moment it would be easy to make sure at least new r-bioc-*
> > packages are restricted to the said architectures by adding this to
> > dh-r.
> 
> I fully agree.

I've pushed an (only weakly tested) patch to dh-r[1] implementing this.
If you think this is fine, feel free to upload a new version of dh-r
which enables wider testing.
 
> By the way the next Bioconductor is scheduled for May 1st, shortly after
> the R 4.4 release.

Thanks for the information.  I'd be super happy if this would be managed
without my help in case I might become elected as DPL.  I'm willing to
take part but I have no idea how much my Debian time will be occupied.

Kind regards
Andreas.

[1] 
https://salsa.debian.org/r-pkg-team/dh-r/-/commit/72571478f4bc889675a60a9a05d7ef31e8bbba15

-- 
https://fam-tille.de

Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages

[Andreas Tille]

Hi,

I'm personally fine with Michaels suggestion in general.

Am Fri, Mar 29, 2024 at 10:13:40AM +0530 schrieb Nilesh Patra:
> 
> 
> On 28 March 2024 7:21:01 pm IST, "Michael R. Crusoe"  
> wrote:
> 
> There are also packages inside debian med umbrella which are not necessarily 
> related to medicine or bioinformatics. These include some general purpose 
> python packages, some C/C++ libraries et. al. There are packages that 
> reverse-depend on the same. I don't think it's a good idea to remove 32 bit 
> support in *all* the packages that are under our umbrella, but probably only 
> the ones that are end-user applications.

When reading Michaels proposal I also was thinking about generic
libraries we are packaging as pre-dependencies for our end-user
applications.  I'd be fine with mentioning those as exceptions from what
I consider perfectly sensible for the packages that are really targeting
at our user base.
 
> It may be good to move packages not related to medicine to different teams 
> over time but some of them actually don't fit into any availability team as 
> per my understanding and may have to be moved to debian/ namespace.
> 
> What do you think?

I'm not convinced that moving package out of our focus is a good idea.
When we did so in the past these packages somehow went out of our focus
and we hear back from them only by testing removal warnings.  I have no
problem with moving packages if there is some request from somewhere
else and thus there is some convincing interest that the package is
maintained properly.  But I would not browse the packages maintained by
our team, check which might be of general interest, seek in what other
team it might be appropriate, become a member of that team and maybe
learn that this team has quite a different policy than we have (as I
learned in DPT recently).

In short:  Keep on maintaining what we have and apply common sense
where to restrict the architectures sensibly.

BTW. actively restricting the architectures for existing packages just
creates work for no use.  I think we should simply focus on new packages
and those that create some troublesome bug reports that we can deal
with by removing unused architectures.

One other hint: I consider it a good idea to forward our proposed change
of policy to debian-devel@l.d.o (once we agreed upon the change - maybe
in some MR) for two reasons:

  1. There might be a chance we have overlooked something.
  2. There might be other teams that are interested in a similar
 change of policy.

> >and on the Debian-Med Matrix channel for instant discussions: 
> >https://app.element.io/#/room/#debian-med:matrix.org
> 
> I'll be happy to open another thread about it, but while we are at it, do you 
> think it makes sense to make this as our official communication media?
> 
> Most of us don't hang out on #debian-med IRC and it would be a little 
> misleading for someone wanting to contact us.

>From my perspective the main drawpack of IRC is that you can't search in
history.  What about setting the title of #debian-med IRC pointing to
our matrix channel?  This would make easily clear what we prefered as
communication channel.
 
> Should we just close the IRC channel and endorse the matrix channel as the 
> official one?

I do not use it but it makes sense to ask on IRC whether people
like this channel for whatever reason.
 
BTW, the Debian Med team is maintaining lots of packages in R pkg team -
most prominently r-bioc-* packages but there are more packages dedicated
to our user base.  We should probably also write a R pkg policy (which
is long overdue).  For the moment it would be easy to make sure at least
new r-bioc-* packages are restricted to the said architectures by adding
this to dh-r.

Kind regards
Andreas.

-- 
https://fam-tille.de

Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)

[Andreas Tille]

Hi Emanuele.

Am Tue, Mar 19, 2024 at 12:16:16PM +0100 schrieb Emanuele Rocca:
> I've uploaded a NMU to DELAYED/2: https://bugs.debian.org/1067147

Thanks a lot for your attempt to help.  In principle we have a team wide
low threshold NMU - so undelayed NMUs are fine.  The kind of race
condition in uploads might imply that some ping in advance might be
helpful to avoid duplicated work.
 
> With those changes dcmtk builds fine on both armel and armhf. I've
> dropped the graphviz build-depend on those arches too, it can of course
> be reintroduced once graphviz become installable again.

Meanwhile your patch is imported and was uploaded by Michael - thanks to
all who helped solving this.

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)

[Andreas Tille]

Hi again,

sorry, I did not checked the situation.

Am Tue, Mar 19, 2024 at 10:34:13AM +0100 schrieb Andreas Tille:
> Testing removals are happening automatically if some RC bug exists
> for a certain time without pinging.  Just writing some additional
> information to the bug in question would have prevented this but
> nobody of us had sufficient capacity.  That's a shame but will be
> healed over time (which is hopefully not that long).

Since you all pinged that bug we now have another 4 weeks of time before
anything gets removed from testing.  So we just need to bear the noise
from testing removal warnings of quite some packages (which I'd love to
get rid of thus uploading a fix would be great). 

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)

[Andreas Tille]

Am Tue, Mar 19, 2024 at 09:52:49AM +0100 schrieb Jörg Riesmeier:
> Dear all,
> 
> > Indeed, and there is a simple fix too, which has been uploaded to
> > experimental only so far:
> 
> yes, there is a simple fix (that disables the error), but there is also a 
> more fundamental fix that (hopefully) solves the issue at its core:
> 
> 
> https://git.dcmtk.org/?p=dcmtk.git;a=commit;h=bdc18c85b7fca130464dd745ea3efef3c9b8b94e

Thanks for the additional pointer.
 
> Furthermore, it feels kind of strange that the DCMTK package was about to be 
> removed because a rather insignificant test tool causes problems on a single 
> platform, and this test tool is even not part of any Debian package (see 
> "debian/rules" file):

Testing removals are happening automatically if some RC bug exists
for a certain time without pinging.  Just writing some additional
information to the bug in question would have prevented this but
nobody of us had sufficient capacity.  That's a shame but will be
healed over time (which is hopefully not that long).

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)

[Andreas Tille]

Hi Sébastien,

Am Tue, Mar 19, 2024 at 09:44:04AM +0100 schrieb Sébastien Jodogne:
> > > 
> > > On 2024-03-19 06:24, Sébastien Jodogne wrote:
> > > > Because of bug #1060104, a large majority of the packages related to
> > > > medical imaging have just disappeared from Debian Unstable.

To be precise s/Unstable/Testing/ (but its a shame anyway).

> > > > But, if I correctly understand #1060104, it is specific to one single
> > > > platform (armel).
> > > 
> > > Indeed, and there is a simple fix too, which has been uploaded to
> > > experimental only so far:
> > > https://salsa.debian.org/med-team/dcmtk/-/commit/42583dfe9fd344a63cdbc278268d4176d4a22ec4
> > > 
> > > Mathieu (or someone else from debian-med), could you please apply that
> > > to unstable as well? It seems that with the current state of unstable
> > > the transition will take a while anyways.
> > 
> > I will be away from any Debian tasks for at least another month
> > unfortunately. The patch was suggested by an armel porter so I believe
> > this is the right thing to do.

Thanks for confirming.

> > > Worth pointing out that right now dcmtk cannot be built in sid/armel due
> > > to a missing build depend, namely graphviz. It seems worth applying the
> > > fix to unstable anyways so that it does not fall through the cracks, and
> > > we can schedule a binNMU later when graphviz is available again.
> 
> I could try to upload this patch by myself to unstable. Unfortunately, I'm
> not an uploader of the dcmtk package, so an intervention from a Debian
> Developer is required to give me the proper access rights:
> https://tracker.debian.org/pkg/dcmtk

Upload permission granted.  Feel free to keep on asking if something
might not work as expected.

Kind regards
   Andreas.

-- 
http://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

Re: How is autopkgtest working in Perl packages

[Andreas Tille]

Am Mon, Mar 11, 2024 at 10:29:30PM +0100 schrieb Étienne Mollier:
> The change turns out to be much more involved than I initially
> thought: we need to account for the build dependencies as well
> as the recommends, and tests don't go skipped that easily,
> because the control on skippable entries occurs after the
> testbed is installed, which cannot occur since recommended
> packages are uninstallable.  I'll probably continue having a
> look at bioperl-run during the week.

Cool. It would be great if we could get rid of 32bit emboss related
packages to get back all those packages in testing which were removed
now.

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

How is autopkgtest working in Perl packages

[Andreas Tille]

Hi,

when trying to exclude clustalw and emboss from bioperl-run I learned
that its autopkgtest is failing for all architectures but amd64.  The
reason is that the test wants to install pftools which is only available
on amd646.  Thus all autopkgtests for other architectures are failing
with

   Broken autopkgtest-satdep:ppc64el Depends on pftools:ppc64el < none @un mH >

(and other not installable dependencies.)  Unfortunately I do not see
any debian/tests/control file which is hidden by some Perl test magic
I do not know.  Any hint how to relax the depencency from non-existent
packages?

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

clustalw lost in debian/dists/sid/main/binary-i386/Packages.{gx}z ?

[Andreas Tille]

Hi,

I'm working on some time_t side effects on the emboss package and by
doing so stumbled I upon the fact that i386 builds of packages with a
Build-Dependency on clustalw are failing.  You can see an example in
Salsa CI for libbio-tools-run-alignment-clustalw-perl[1] which contains

   The following packages have unmet dependencies:
builddeps:. : Depends: clustalw but it is not installable
   E: Unable to correct problems, you have held broken packages.

When checking the package pool[2] I can find
   clustalw_2.1+lgpl-7_i386.deb
which is easily installable in some chroot I created using

   sudo debootstrap --arch=i386 sid i386-chroot http://deb.debian.org/debian

Debci seems to be fine in testing clustalw on all architectures[3] and
according to build logs[4] all should be fine.  Unfortunately

   wget -q  -O - 
http://ftp.debian.org/debian/dists/sid/main/binary-i386/Packages.xz | xzgrep 
"Package: *clustalw" Packages.xz

is empty and I wonder why.  Is the Packages file for i386 just broken
or is it me?

Kind regards
Andreas.

[1] 
https://salsa.debian.org/perl-team/modules/packages/libbio-tools-run-alignment-clustalw-perl/-/jobs/5431253
[2] http://ftp.debian.org/debian/pool/main/c/clustalw/
[3] https://ci.debian.net/packages/c/clustalw/unstable/i386/
[4] https://buildd.debian.org/status/package.php?p=clustalw

-- 
http://fam-tille.de

Build-Dependencies from emboss-lib for bioperl-run and python-biopython (Was: reverse dependencie)

[Andreas Tille]

Control: block -1 by 1065782

Hi Thorsten,

Am Mon, Mar 04, 2024 at 06:41:28PM + schrieb Thorsten Alteholz:
> there are still reverse dependencies that need to be taken care of:
> 
> Checking reverse dependencies...
> # Broken Depends:
> emboss: jemboss

I think this is a false positive since jemboss is built from the emboss
source.

> emboss-explorer: emboss-explorer

Bug filed.
 
> # Broken Build-Depends:
> bioperl-run: emboss

This needs further investigation.

> embassy-domainatrix: emboss-lib (6.6.1~ <)

Fixed Build-Depends.

> embassy-domalign: emboss-lib (6.6.1~ <)

Fixed Build-Depends.

> embassy-domsearch: emboss-lib (6.6.0-1~ >=)
>emboss-lib (6.6.1~ <)

Fixed Build-Depends.

> python-biopython: emboss

This needs further investigation.
 
> In case they matter, this needs to be addressed first. Please remove the
> moreinfo tag once that is done.

Thanks for checking.  Once bioperl-run and python-biopython is fixed we
reset moreinfo.

Kind regards
Andreas. 

-- 
http://fam-tille.de

Re: regarding filtering architectures

[Andreas Tille]

Hi Michael,

Am Thu, Mar 07, 2024 at 12:23:15PM +0100 schrieb Michael R. Crusoe:
> This is a great tip, thanks!
> 
> I've pushed commits that use the provisions from the
> architecture-properties package to clean up d/control for the following
> packages:
> 
> abyss
> bazel-bootstrap
> bowtie
> bowtie2
> canu
> diamond-aligner
> gmap
> jellyfish
> kallisto
> mmseqs2
> pbcopper
> python-skbio
> subread

Very nice!  That way we will not forget this in the next upgrade.  I
guess there are more candidates - my strategy would be to seek for loong
in the list of architectures.

Thanks for this effort
Andreas.

-- 
http://fam-tille.de

Re: regarding filtering architectures

[Andreas Tille]

Hi,

Paul has sent me a valuable hint.  I totally missed this information
but will try to fix all our packages that are only available for 64 bit
architectures according to this.  I'm just bouncing this information
to the list in case I'm not the only one who missed this simple option
to exclude 32bit.

Kind regards
Andreas.

Am Sun, Mar 03, 2024 at 07:28:57AM +0100 schrieb Paul Gevers:
> Hi Andreas,
> 
> I just spotted two of you packages [1] where you stopped supporting 32 bits.
> I'm not going to judge on that (I don't even look at the reason), but
> instead of hard-coding the list of architectures, could you use a
> Build-Dependens on architecture-is-64-bit (from
> https://packages.debian.org/unstable/architecture-properties).
> 
> Rationale: https://lists.debian.org/debian-devel/2022/09/msg00105.html
> 
> Paul
> 
> [1] https://tracker.debian.org/media/packages/e/emboss/control-6.6.0dfsg-13
> [2] 
> https://tracker.debian.org/media/packages/r/r-bioc-rhtslib/control-2.4.1dfsg-2
> 
> Paul




-- 
http://fam-tille.de

Re: Bug#1064291: marked as done (ITP: python-awkward -- manipulate JSON-like data with NumPy-like idioms)

[Andreas Tille]

Hi Sascha,

Am Sun, Feb 25, 2024 at 08:32:52PM +0100 schrieb Sascha Steinbiss:
> > nox > Creating virtual environment (virtualenv) using python3 in 
> > .nox/prepare
> > nox > python -m pip install build numpy packaging PyYAML requests tomli
> > nox > Command python -m pip install build numpy packaging PyYAML requests 
> > tomli failed with exit code 1:
> > WARNING: The directory '/nonexistent/.cache/pip' or its parent directory is 
> > not owned or is not writable by the current user. The cache has been 
> > disabled. Check the permissions and owner of that directory. If executing 
> > pip with sudo, you should use sudo's -H flag.
> > ...
 
> Hmm, I never had that.

Sounds good.  Maybe something is broken on my side?

> The buildd builds also seem to pass this step with no
> errors.

Even better.

> I am wondering if nox wants to pull anything from PyPI using pip and
> either your DNS configuration is weird or your build container cannot access
> the Internet (which than again it shouldn't)... but if buildds are not
> supposed to access the Internet why don't the builds fail there? On the
> buildds the issue there seems to be related to a script using an old(?)
> Python YAML library syntax:
> https://buildd.debian.org/status/package.php?p=python-awkward

I admit I'm fine with the situation that the build works everywhere
except for me as long as I have no reason to build it. ;-)
 
> > Even worse:  It requires pyarrow
> 
> It does? The project metadata, where all other dependencies are listed, does
> not mention it, and the dependencies that are listed there are all from
> Debian:
> 
> ...
> dependencies = [
> "awkward_cpp==29",
> "importlib_metadata>=4.13.0;python_version < \"3.12\"",
> "numpy>=1.18.0",
> "packaging",
> "typing_extensions>=4.1.0; python_version < \"3.11\"",
> "fsspec>=2022.11.0"
> ]
> ...
> 
> Grepping through the test requirements though seems to indicate that the
> tests in the awkward package need pyarrow:

Its not only the tests:

$ grep -Rl pyarrow src/* | wc -l
76

> ❯ grep pyarrow *requi* pyproject.toml
> requirements-test-full.txt:pyarrow>=7.0.0;sys_platform != "win32" and
> python_version < "3.12"
> requirements-test-minimal.txt:pyarrow==7.0.0
> 
> But I disabled the Python unit tests (mostly because I couldn't get them to
> work with the combined C++ and Python package built here) so I didn't catch
> it.
> I was also under the impression that awkward working with data from pyarrow
> would just be one use case, but not a hard requirement for awkward to work.
> Probably too optimistic given your observations :/

Seems so.  Maybe we finally need to tackle pyarrow.
 
> >  ERROR collecting tests/test_awkward.py 
> > 
> > ImportError while importing test module 
> > '/tmp/autopkgtest.sD3d5G/autopkgtest_tmp/tests/test_awkward.py'.
> > Hint: make sure your test modules/packages have valid Python names.
> > Traceback:
> > /usr/lib/python3.12/importlib/__init__.py:90: in import_module
> >  return _bootstrap._gcd_import(name[level:], package, level)
> > tests/test_awkward.py:205: in 
> >  ak.str.to_categorical(ak.Array([["a", "b", "c"], ["a", "b"]])),
> > /usr/lib/python3/dist-packages/awkward/_dispatch.py:62: in dispatch
> >  next(gen_or_result)
> > /usr/lib/python3/dist-packages/awkward/operations/str/akstr_to_categorical.py:53:
> >  in to_categorical
> >  return _impl(array, highlevel, behavior, attrs)
> > /usr/lib/python3/dist-packages/awkward/operations/str/akstr_to_categorical.py:60:
> >  in _impl
> >  pc = import_pyarrow_compute("ak.str.to_categorical")
> > /usr/lib/python3/dist-packages/awkward/_connect/pyarrow.py:60: in 
> > import_pyarrow_compute
> >  raise ImportError(error_message.format(name))
> > E   ImportError: to use ak.str.to_categorical, you must install pyarrow:
> 
> In that case it looks like anndata needs a feature of awkward that also
> needs pyarrow. Which is, yeah, a problem, given that we don't have anything
> form Arrow in Debian (yet). Since pyarrow is just bindings that need the
> rest of the library (https://arrow.apache.org/docs/python/index.html) then
> this pulls in another large dependency.

That's correct.
 
> > Since python-anndata is the last package with Python3.12 issues there is 
> > some work
> > left on this front.
> 
> True. I am afraid that Arrow would be too much for me to take care of at the
> moment, sorry. I started it a while ago but quickly found that that I bit
> off more than I can chew without it becoming a full-time task.
> (See my ITP and the thread on it)

I'm aware of this.  Thank you for your work on this anyway.

Kind regards
Andreas.


-- 
http://fam-tille.de

Re: Bug#1064291: marked as done (ITP: python-awkward -- manipulate JSON-like data with NumPy-like idioms)

[Andreas Tille]

Awkward Array is a library for nested, variable-sized data, including
> arbitrary-length lists, records, mixed types, and missing data, using
> NumPy-like idioms. Arrays are dynamically typed, but operations on them
> are compiled and fast. Their behavior coincides with NumPy when array
> dimensions are regular and generalizes when they're not.
> 
> This is packaged as a dependency for another package under the umbrella
> of the Debian Med packaging team.

> Date: Sat, 24 Feb 2024 13:06:34 +
> From: Debian FTP Masters 
> To: 1064291-cl...@bugs.debian.org
> Subject: Bug#1064291: fixed in python-awkward 2.6.1-1
> 
> Source: python-awkward
> Source-Version: 2.6.1-1
> Done: Sascha Steinbiss 
> 
> We believe that the bug you reported is fixed in the latest version of
> python-awkward, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 1064...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Sascha Steinbiss  (supplier of updated python-awkward 
> package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Format: 1.8
> Date: Mon, 19 Feb 2024 18:28:57 +0100
> Source: python-awkward
> Binary: python3-awkward python3-awkward-dbgsym
> Architecture: source amd64
> Version: 2.6.1-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Med Packaging Team 
> 
> Changed-By: Sascha Steinbiss 
> Description:
>  python3-awkward - manipulate JSON-like data with NumPy-like idioms
> Closes: 1064291
> Changes:
>  python-awkward (2.6.1-1) unstable; urgency=medium
>  .
>[ Andreas Tille ]
>* Initial release (Closes: #1064291)
> Checksums-Sha1:
>  e835fc60616da3330a380ca105e75bbec149cfa5 2366 python-awkward_2.6.1-1.dsc
>  a4ef295e085c7c58ec1f2a28290f13da42132bdc 6040868 
> python-awkward_2.6.1.orig.tar.gz
>  91af6573bfdd76139113e93f54143f79b7c3b654 3292 
> python-awkward_2.6.1-1.debian.tar.xz
>  277224034e7f5452fb4fc00191f8553dcc25ac75 9409 
> python-awkward_2.6.1-1_amd64.buildinfo
>  7f35255f4e0e28de704b43ef7020b035cac46c59 5174496 
> python3-awkward-dbgsym_2.6.1-1_amd64.deb
>  2b24ffdfc4f6030fcfaf86d4edc780cf4731fc5a 882204 
> python3-awkward_2.6.1-1_amd64.deb
> Checksums-Sha256:
>  d3ea8befdebc2a6e24965ee1fbd235669c7c558c97c1f359f342cb889729ef69 2366 
> python-awkward_2.6.1-1.dsc
>  4c17354edae1bf4a5701e2a5b949043b8f358895718712e0720ba1be9dabbce6 6040868 
> python-awkward_2.6.1.orig.tar.gz
>  5befc650dc06b79040802fd8da693894918a5162076ebad46fcc45f978a016dd 3292 
> python-awkward_2.6.1-1.debian.tar.xz
>  23f92d9578aa35ae164bc4cd72d81a9bb3e3f68ab27d792a7002772c8501f313 9409 
> python-awkward_2.6.1-1_amd64.buildinfo
>  557768ad12a871641aeef664829d6b476c2e6620ec51b1608cf553e7676d2db5 5174496 
> python3-awkward-dbgsym_2.6.1-1_amd64.deb
>  fea0101f0d78ff16ddb3a00d03f11ff493bbac5a24d70b98a87f6fd814fdeee8 882204 
> python3-awkward_2.6.1-1_amd64.deb
> Files:
>  a1714dda9f9e9fa20d0584e12e54107a 2366 python optional 
> python-awkward_2.6.1-1.dsc
>  4985e5efc79105640d5718931eebab33 6040868 python optional 
> python-awkward_2.6.1.orig.tar.gz
>  a1e6d04386e251fe0328470de85897b6 3292 python optional 
> python-awkward_2.6.1-1.debian.tar.xz
>  d205149ace149bf2de2a3b844811d476 9409 python optional 
> python-awkward_2.6.1-1_amd64.buildinfo
>  378ae2d1514d3afada7cd93760dafe1d 5174496 debug optional 
> python3-awkward-dbgsym_2.6.1-1_amd64.deb
>  ad082dfeacaee9dd9b04bfa6683096dd 882204 python optional 
> python3-awkward_2.6.1-1_amd64.deb
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCAAdFiEEWzS6WqtVB+kDQm6F6NN64vCfSHIFAmXTt0MACgkQ6NN64vCf
> SHLdbxAAnX9oiBgUwB0NCbh6JPSo+JQr/shB6OLdwEp5rqpjkKJyJUzim4secHZ2
> 5dr2sIqIoUvVdayW6QyNcOt53ncL0CD1qt88A6Hl/bpabDaHLHBdk+ltr+Axqcek
> G2V9mrOoOddt+obakrdrM6g4Ts3TwuDvshqJs9EA351SZeEVCP3+Glq8pc0Cfmsl
> r7qX+vHI9su/k6PFpmH66qqZbzi9sIUnkxSLmsxFyVX+ZTaP85T2rxp4HdqrDagh
> dqSMA8lptt9uWbXua+2PLifmmh9wMRvJUsiMByCRNhRu5T/4h2WYMfEtrTGpVs0d
> JRvTMpe9bsdm2/+ffV2fXK6E6/9Wl6dbg8aoLmqIVFkdfyMlpsowSCgE+KlAKrxG
> rHmOkFYeaFtWDeASwa15vPut33KZlkf5HFtRV+jeCUgWa4IQJJq6NznmS7K3e1p9
> YZbIfCpMjO3qAaKaFcVtRuvA2CM9/HxROmO3BLsRVvkS5mZMOi8g+xOjX8xZttIC
> EOrslMcfQ3djAIebQ20ZeqJHohvKSRKRygYXDW9UR8jv390KvGfi/S9eTKyrlBQb
> lZFvnf8QoDKrFHsyefLiojsZgG948/fN7RsM4i32SxLWtGwIZ+qbfMaG6IQPIP2Q
> Rn5y2fjJ0G+VAbrCeypJ4zJVARXfhYQOKGMeUqUex/OsgXkX9Ig=
> =CdJG
> -END PGP SIGNATURE-
> 




-- 
http://fam-tille.de

Re: New CamiTK 5.2.0 release

[Andreas Tille]

Dear Emmanuel,

Am Thu, Feb 22, 2024 at 04:07:25PM +0100 schrieb Emmanuel Promayon:
> Thank for your time, patience and explanations!

You are welcome.

> Thank you very much for the explanation, the wiki update and the link to
> routine-update, that will probably my saviour in the future!

Routine-update is saving me a lot of time and I hope it will do so
for others. ;-)

> > The repository has the line with "lib/x86_64-linux-gnu" while the
> > downloaded tarball has only "lib".  If you really need to adapt the
> > original tarball to some Debian specific things this needs to be done in
> > a quilt patch.  Please also note:  This change only works for amd64
> > architecture which currently is the only architecture where the Debian
> > package is built.  However, this restriction is only due to the fact
> > that libinsighttoolkit5-dev is only available for this architecture.  In
> > case it might be available for other architectures as well your patch
> > above will fail on those.
> Understood. Now that the correct libDir variable is set back to just "lib",
> the multiarch support should be taken into account directly in the
> debian/rules.
> The first instruction of the target override_dh_auto_configure target is:
> sed -i 's+libDir = "lib";+libDir = "lib/$(DEB_HOST_MULTIARCH)";+g'
> sdk/libraries/core/CamiTKVersion.h

Just a general think I do not understand:  Why is it necessary that a
header file knows about the location of the (shared/static?) library?
 
> Which, from what I understand, should replace the libDir variable with the
> specific architecture version, hopefully making it ready for when/if
> libinsighttoolkit5-dev supports other architectures.
> Let me know if that sounds correct for you.

Using the correct lib dir on different architectures is probably the
right way to support these architectures.  But its the first time I see
that a header file needs to know the location of the lib.
 
> I pushed the fix to salsa, let me know if that solved the problem.

I've uploaded yesterday.

> Best
> regards, Emmanuel PS : I added Manik Bhattacharjee in cc who joined me in
> the CamiTK project team.

Welcome Manik.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: New CamiTK 5.2.0 release

[Andreas Tille]

Hi Emmanuel,

Am Thu, Feb 22, 2024 at 07:48:53AM +0100 schrieb Emmanuel Promayon:
> I hope you had a great sprint (seems a lot was done, congrats!).

All was fine, thank you.
 
> I was wondering if any of you had any time to check the new CamiTK version
> package in between all of the bug fixing and python transition?

I admit I was avoiding doing larger builds on my laptop and wanted
to do this at home.  Thanks for pinging in any case.

> On 16/02/2024 11:01, Emmanuel Promayon wrote:
> > Dear all,
> > 
> > First of all, I'd like to wish the whole team a great sprint in Berlin.
> > 
> > As far as CamiTK is concerned, version 5.2.0 has been released upstream
> > and I have updated the package on salsa.
> > I did not tag the master branch with the debian/5.2.0 tag, as I am not
> > 100% sure that everything is valid.
> > The pristine-tar branches were updated this time (hopefully the right
> > way!).

Hmmm, sorry, no.  If you check that branch[1] you see the names for the
two last releases are the original download names with camel case letters,
a '-' instead of '_' separating the name and the version and lacking the
'.orig' string inside the tarball name.  I would have fixed this by doing

uscan --verboe --force-download
pristine-tar commit ../camitk_5.2.0.orig.tar.gz

but after doing so I got:

dpkg-source: info: local changes detected, the modified files are:
 camitk-5.2.0/sdk/libraries/core/CamiTKVersion.h
dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/camitk_5.2.0-1.diff.LLSDXq

So it seems there are some differences inside the tarball.  I try to
repeat what you need to do when there is a new upstream version:

uscan --verbose
gbp import-orig --pristine-tar --no-interactive camitk_VERSION.orig.tar.gz
dch -i "New upstream version"

I also tried to write the according paragraph in Debian Med policy[2]
more verbosely.  Maybe even the hint to `routine-update` is helpful.
It simply does all you want to do (including the steps above).

If there would not have been the conflict between the repository and
the original tarball I would have went on after fixing pristine-tar
branch.  But I don't know what to do with this diff:

--- camitk-5.2.0.orig/sdk/libraries/core/CamiTKVersion.h
+++ camitk-5.2.0/sdk/libraries/core/CamiTKVersion.h
@@ -32,5 +32,5 @@ const char * Core::version = "CamiTK 5.2
 const char * Core::shortVersion = "camitk-5.2";
 const char * Core::soVersion = "5";
 const char * Core::debugPostfix = "-debug";
-const char * Core::libDir = "lib";
+const char * Core::libDir = "lib/x86_64-linux-gnu";
 }

The repository has the line with "lib/x86_64-linux-gnu" while the
downloaded tarball has only "lib".  If you really need to adapt the
original tarball to some Debian specific things this needs to be done in
a quilt patch.  Please also note:  This change only works for amd64
architecture which currently is the only architecture where the Debian
package is built.  However, this restriction is only due to the fact
that libinsighttoolkit5-dev is only available for this architecture.  In
case it might be available for other architectures as well your patch
above will fail on those.

Please let me know if you need further hints.

Thanks a lot for working on camitk package
Andreas.

[1] https://salsa.debian.org/med-team/camitk/-/tree/pristine-tar?ref_type=heads
[2] 
https://med-team.pages.debian.net/policy/#updating-a-source-package-managed-with-git


-- 
http://fam-tille.de

Help needed to port qiime to Python3.12

[Andreas Tille]

Hi,

as reported in a qiime2 issue[1] there is some problem with Python3.12
in the tests of the q2-* packages which are all using the qiime package.
This problem is currently hidden from the tests made by Python3.12
porters but it became obvious now on Salsa CI[2].  I tried to fiddle
around a bit with the qiime code but with no success at all.  Any help
would be welcome.

Kind regards
Andreas.

[1] https://github.com/qiime2/qiime2/issues/751
[2] https://salsa.debian.org/med-team/q2-types/-/jobs/5313640#L900

-- 
http://fam-tille.de

For the sprint attendees: Dinner tomorrow evening

[Andreas Tille]

Hi folks,

I'd suggest to have dinner tomorrow evening 18:00 at Viet Kitchen
(as last year):

   
https://www.openstreetmap.org/?mlat=52.47994&mlon=13.35216#map=19/52.47994/13.35216

(I've added this also to the Wiki)

See you either tomorrow or on Saturday
 Andreas.

PS: For those who need to join from remote: Should we keep some
kind of live connection open all the time or do we want to
agree to somme common sessions at certain times?

-- 
http://fam-tille.de

Re: Should we restrict libtread-pool to 64bit only

[Andreas Tille]

Am Mon, Feb 12, 2024 at 10:09:43PM -0500 schrieb Aaron M. Ucko:
> Andreas Tille  writes:
> 
> >Build-Depends libthread-pool 4.0.0 which does not build
> >for 32bit architectures[1]
> 
> I see a fix in experimental:
> 
> https://buildd.debian.org/status/package.php?p=libthread-pool&suite=experimental
> 
> Why not just reupload it to unstable?

Done.  Thanks a lot for the reminder
Andreas. 

-- 
http://fam-tille.de

Should we restrict libtread-pool to 64bit only (Was: Bug#1063800: src:pinfish: fails to migrate to testing for too long: not installable on armel, armhf and i386)

[Andreas Tille]

Hi,

the chain of dependencies for pinfish which creates the problem is

   pinfish depends racon which in turn can't install its
   Build-Depends libthread-pool 4.0.0 which does not build
   for 32bit architectures[1]

My suggestion to solve the issue is to explicitly set

   Architecture: any-amd64 arm64 mips64el ppc64el riscv64 s390x alpha ia64 
loong64 ppc64 sparc64 x32

and ask ftpmaster for removing 32bit architectures for libthread-pool,
racon and pinfish.  Does anybody think we should ask libthread-pool
upstream to support 32bit or do we just want to go on to remove 32bit
(which also solves time_t bug easily).

Kind regards
Andreas.

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

Am Mon, Feb 12, 2024 at 09:35:34PM +0100 schrieb Paul Gevers:
> Source: pinfish
> Version: 0.1.0+ds-3
> Severity: serious
> Control: close -1 0.1.0+ds-4
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 30 days as having a Release Critical bug in testing
> [1]. Your package src:pinfish has been trying to migrate for 31 days [2].
> Hence, I am filing this bug. It seem the version in unstable isn't
> installable on our 32 bit architectures. It seems like the version in
> testing doesn't have binaries on these architectures, while the buildd
> history shows they were built for the previous version, so you probably had
> them removed. You probably need to do this again, but I suggest to add a
> Build-Depends on racon to prevent accidental builds on architectures where
> racon isn't available (and thus the package becomes not installable).
> 
> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot be
> fixed via unstable. Additionally, blocked packages can have impact on other
> packages, which makes preparing for the release more difficult. Finally, it
> often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that hamper
> the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new bugs,
> there will be at least 30 days before the package is auto-removed.
> 
> I have immediately closed this bug with the version in unstable, so if that
> version or a later version migrates, this bug will no longer affect testing.
> I have also tagged this bug to only affect sid and trixie, so it doesn't
> affect (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to issues
> beyond your control, don't hesitate to contact the Release Team.
> 
> Paul
> 
> [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
> [2] https://qa.debian.org/excuses.php?package=pinfish
> 




> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de

Lets do the video conference next week

[Andreas Tille]

Hi folks,

today we should schedule our video conference but I will not make it
today and I think its better to meet next week at the sprint and invite
those who are not at site via Jitsi.

See you next week
Andreas.

-- 
http://fam-tille.de

Re: Do we need the Python interface of ghmm

[Andreas Tille]

Hi Steffen,

Am Wed, Feb 07, 2024 at 02:23:22PM +0100 schrieb Steffen Möller:
> Hi Andreas,
> it will be best to remove it, I suggest.

I just had the idea whe can do something inbetween:  Add some
README.Debian that Python3 interface is "probably broken since the test
we added fails."  Users who might *really* use this interface might
possibly provide a solution we have no capacity to seek for.  I simply
move the Python part of the autopkgtest to this README.Debian.

> I do not have any personal contact to upstream, somehwat unfortunate since 
> this looks very nice and educational, but ... unless someone enjoys such a 
> transition, I suggest to just wait for a version 0.10.

Well, waiting for some version 0.10 sounds not very realistic,  The
package is on SourceForge which somehow smells very agy.  Given that
0.9-rc3 is from 2013-08-09 we can safely assume that the world will not
see any version 0.10, IMHO.

Kind regards
Andreas.
 
> > Gesendet: Mittwoch, 07. Februar 2024 um 14:02 Uhr
> > Von: "Andreas Tille" 
> > An: "Debian Med Project List" 
> > Cc: "Steffen Möller" 
> > Betreff: Re: Do we need the Python interface of ghmm
> >
> > Hi again,
> > 
> > if there is no response of kind "Yes, please try to keep the Python
> > interface of ghmm" it will be removed soon.
> > 
> > Kind regards
> >Andreas.
> > 
> > Am Tue, Jan 30, 2024 at 07:58:34AM +0100 schrieb Andreas Tille:
> > > Hi Steffen (and two whom it might concern),
> > > 
> > > when Israel has written the autopkgtest for ghmm it turned
> > > out that there are several issues with the Python3 interface.
> > > In Matrix Nilesh raised the perfectly valid question:
> > > 
> > >The py interface is living off a patch from py2to3 and is (very)
> > >broken. It needs quite a lot of patching. Maybe it's a sensible thing 
> > > to
> > >evaluate if we even need it?
> > > 
> > > Could you please state your opinion about this?
> > > 
> > > We should respond in a timely manner to the atlas removal
> > > effort (patch in Git) and currently it is blocked by the
> > > test suite issue of the Python3 interface.
> > > 
> > > Kind regards
> > >Andreas.
> > > 
> > > -- 
> > > http://fam-tille.de
> > > 
> > > 
> > 
> > -- 
> > http://fam-tille.de
> >
> 
> 

-- 
http://fam-tille.de

Re: Do we need the Python interface of ghmm

[Andreas Tille]

Hi again,

if there is no response of kind "Yes, please try to keep the Python
interface of ghmm" it will be removed soon.

Kind regards
   Andreas.

Am Tue, Jan 30, 2024 at 07:58:34AM +0100 schrieb Andreas Tille:
> Hi Steffen (and two whom it might concern),
> 
> when Israel has written the autopkgtest for ghmm it turned
> out that there are several issues with the Python3 interface.
> In Matrix Nilesh raised the perfectly valid question:
> 
>The py interface is living off a patch from py2to3 and is (very)
>broken. It needs quite a lot of patching. Maybe it's a sensible thing to
>evaluate if we even need it?
> 
> Could you please state your opinion about this?
> 
> We should respond in a timely manner to the atlas removal
> effort (patch in Git) and currently it is blocked by the
> test suite issue of the Python3 interface.
> 
> Kind regards
>Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Re: User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)

[Andreas Tille]

Hi again,

I've filed bug #1062371

RM: emboss [armel armhf i386 hppa m68k powerpc sh4] -- ROM; No support of 
32 bit architectures any more

Kind regards
Andreas.

Am Wed, Jan 31, 2024 at 07:53:26AM +0100 schrieb Andreas Tille:
> Hi again,
> 
> besides my suggested solution to split up emboss-lib again (and when
> doing so make the package emboss-lib a metapackage depending from single
> packages to match all its rdepends) I wonder whether we should provide
> EMBOSS for 64 bit architectures only.  While we probably need to file a
> lot of removal requests to 32 bit packages of its rdepends it somehow
> fits the reality that these days nobody seriously runs emboss on 32bit
> architectures.  As explained in the according wiki page[1] other binary
> distros are dropping 32-bit at all and Debian rather cares for
> automotive, IOT, TVs, routers, plant control, building
> monitoring/control, cheap Android phones - nothing that is using EMBOSS.
> 
> I would really like to get some input from *our users* here on the
> Debian Med list since I need your response to draw a sensible decision.
> 
> Kind regards
> Andreas.
> 
> [1] https://wiki.debian.org/ReleaseGoals/64bit-time
> 
> Am Fri, Jan 26, 2024 at 10:44:09AM +0100 schrieb Andreas Tille:
> > Hi Charles,
> > 
> > I wonder how we can properly solve this bug.  In the early stage of
> > Emboss packaging obviously the packages
> > 
> >libajax6,
> >libajax6-dev,
> >libnucleus6,
> >libnucleus6-dev
> > 
> > existed (thus the remaining Conflicts/Replaces on emboss-lib which can
> > probably be removed right now).  I wonder whether we should restore those
> > single library package per shared library + devel package, merge
> > static+shared library in one package or even merge
> > 
> >libacd 6 emboss-lib (>= 6.6.0+dfsg)
> >libajax 6 emboss-lib (>= 6.6.0+dfsg)
> >libajaxdb 6 emboss-lib (>= 6.6.0+dfsg)
> >libajaxg 6 emboss-lib (>= 6.6.0+dfsg)
> >libensembl 6 emboss-lib (>= 6.6.0+dfsg)
> >libnucleus 6 emboss-lib (>= 6.6.0+dfsg)
> > 
> > in libemboss6
> > 
> >libepcre 7 emboss-lib (>= 6.6.0+dfsg)
> > 
> > in libemboss-pcre7 (ugly since its a code copy of pcre3 but well,
> > that's another battle field) and
> > 
> >libeplplot 3 emboss-lib (>= 6.6.0+dfsg)
> > 
> > in libemboss-plplot3 to express the proper sonames inside the library
> > package names.  Any more sensible suggestion is pretty welcome.
> > 
> > Kind regards
> > Andreas.
> > 
> > -- 
> > http://fam-tille.de
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Re: User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)

[Andreas Tille]

Hi Tony,

Am Wed, Jan 31, 2024 at 09:57:32AM + schrieb Tony Travis:
> The only people I know still using 32-bit software are doing BLAST etc on
> older Raspberry Pi's. However, AFAIK, the default Raspberry Pi OS (based on
> Debian Bullseye) is 32-bit even though the newer Raspberry Pi have 64-bit
> processors. Personally, I don't think it's worth the effort to support
> 32-bit software these days. I don't use EMBOSS any longer.

Thanks a lot to your insight.  Do you have any contact to those people
running 32bit systems?  Can you forward this question to them?  Or more
generally:  Wouldn't it make sense if people doing Debian based
bioinformatics would subscribe this list and speak here?

Kind regards
   Andreas.

-- 
http://fam-tille.de

User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)

[Andreas Tille]

Hi again,

besides my suggested solution to split up emboss-lib again (and when
doing so make the package emboss-lib a metapackage depending from single
packages to match all its rdepends) I wonder whether we should provide
EMBOSS for 64 bit architectures only.  While we probably need to file a
lot of removal requests to 32 bit packages of its rdepends it somehow
fits the reality that these days nobody seriously runs emboss on 32bit
architectures.  As explained in the according wiki page[1] other binary
distros are dropping 32-bit at all and Debian rather cares for
automotive, IOT, TVs, routers, plant control, building
monitoring/control, cheap Android phones - nothing that is using EMBOSS.

I would really like to get some input from *our users* here on the
Debian Med list since I need your response to draw a sensible decision.

Kind regards
Andreas.

[1] https://wiki.debian.org/ReleaseGoals/64bit-time

Am Fri, Jan 26, 2024 at 10:44:09AM +0100 schrieb Andreas Tille:
> Hi Charles,
> 
> I wonder how we can properly solve this bug.  In the early stage of
> Emboss packaging obviously the packages
> 
>libajax6,
>libajax6-dev,
>libnucleus6,
>libnucleus6-dev
> 
> existed (thus the remaining Conflicts/Replaces on emboss-lib which can
> probably be removed right now).  I wonder whether we should restore those
> single library package per shared library + devel package, merge
> static+shared library in one package or even merge
> 
>libacd 6 emboss-lib (>= 6.6.0+dfsg)
>libajax 6 emboss-lib (>= 6.6.0+dfsg)
>libajaxdb 6 emboss-lib (>= 6.6.0+dfsg)
>libajaxg 6 emboss-lib (>= 6.6.0+dfsg)
>libensembl 6 emboss-lib (>= 6.6.0+dfsg)
>libnucleus 6 emboss-lib (>= 6.6.0+dfsg)
> 
> in libemboss6
> 
>libepcre 7 emboss-lib (>= 6.6.0+dfsg)
> 
> in libemboss-pcre7 (ugly since its a code copy of pcre3 but well,
> that's another battle field) and
> 
>libeplplot 3 emboss-lib (>= 6.6.0+dfsg)
> 
> in libemboss-plplot3 to express the proper sonames inside the library
> package names.  Any more sensible suggestion is pretty welcome.
> 
> Kind regards
> Andreas.
> 
> -- 
> http://fam-tille.de

-- 
http://fam-tille.de

Do we need the Python interface of ghmm

[Andreas Tille]

Hi Steffen (and two whom it might concern),

when Israel has written the autopkgtest for ghmm it turned
out that there are several issues with the Python3 interface.
In Matrix Nilesh raised the perfectly valid question:

   The py interface is living off a patch from py2to3 and is (very)
   broken. It needs quite a lot of patching. Maybe it's a sensible thing to
   evaluate if we even need it?

Could you please state your opinion about this?

We should respond in a timely manner to the atlas removal
effort (patch in Git) and currently it is blocked by the
test suite issue of the Python3 interface.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: ClonalFrameML: Dataset with less computational resourses

[Andreas Tille]

Hi Xavier,

Am Mon, Jan 29, 2024 at 06:34:54PM +0100 schrieb Komolehin Israel:
> > Would it be useful for you if I added these files to the github
> > repository?
> 
> Yes. That would be great.

I consider this specifically helpful since you could add a test
in the upstream archive which is helpful not only for Debian but
in general.  We could simply call this test.

Kind regards
Andreas.

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

Debian Med video meeting today Saturday 2024-01-13 19:00 UTC

[Andreas Tille]

Hi,

this is the call for the next video meeting of the Debian Med team
that are an established means to organise the tasks inside our team.

Meetings usually take us only 15-20min depending what we are talking
about and how many people are joining.  The next meeting is tomorrow
   
 https://www.timeanddate.com/worldclock/fixedtime.html?iso=20240113T19

The meeting will happen at the Debian Social channel

 https://jitsi.debian.social/DebianMedCovid19

The topic is what contributors have done in the past period and to
coordinate the work until the next meeting.

For those who are interested in hot topics we want to tackle, here
are some items:

  - Python 3.12 transition
  - Evaluation of advent bug squashing
  - Status outreachy project

Newcomers are always welcome.

See you today
 
   Andreas.

-- 
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: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)

[Andreas Tille]

Hi,

Am Wed, Jan 03, 2024 at 12:41:23PM +0100 schrieb Sascha Steinbiss:
> > This would be very convenient.  I'd take over to ask DPL for budget
> > confirmation once the list of attendees needing travel support is
> > fixed.
> 
> Done: https://wiki.debian.org/Sprints/2023/DebianMed2024

Thanks a lot.  I've added myself.  Please let me know how many people
might join the evening session on top of the water tower.  If we might
be maximum three people we can simply use the accomodation room I've
booked with my wife and can save the extra Debian money for the bigger
and fancier room.

See you all
Andreas.


-- 
http://fam-tille.de

Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)

[Andreas Tille]

Am Wed, Jan 03, 2024 at 10:44:03AM +0100 schrieb Sascha Steinbiss:
> 
> I can see in our internal calendar that the room has been booked for
> 17./18.2.
> 
> > We should setup an according Wiki page quickly (but I will not be
> > possible to do this today).
> 
> Should I just clone the previous page, just updating the year and
> resetting the registration list?

This would be very convenient.  I'd take over to ask DPL for budget
confirmation once the list of attendees needing travel support is
fixed.

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)

[Andreas Tille]

Hi,

Am Sat, Dec 30, 2023 at 11:39:35PM +0100 schrieb Étienne Mollier:
> > > I'd love to fix 17-18. February (or lets meet at 16.2. February evening
> > > inside the water tower like last year.)

Just lets fix it on this 16.2. water tower whoever will make it and
17-18 inside the kacher space provided by Saschas company.  We should
setup an according Wiki page quickly (but I will not be possible to
do this today).

> I don't really have constraints on these dates.  It may depend
> on how well it plays with my dayjob calendar, but it is not the
> best moment of the year to look it up.  I will come back on this
> topic next week if I happen to have blockers.
> 
> > I will probably not be able to join in the water tower on the 16th, but no
> > worry about this.

That's fine.  I did not even checked whether the water tower is
available but I hope we will find either this or some other
space for a hand full of people.

See you
   Andreas.

-- 
http://fam-tille.de

Re: Please help fixing meson/cmake code of btllib to use Debian packaged libargparse

[Andreas Tille]

Am Sat, Dec 30, 2023 at 04:28:39PM +0100 schrieb Étienne Mollier:
> 
> autopkgtest-pkg-python can be requested to use only one python3
> version by specifying the X-Python3-Version field in d/control,
> first paragraph.  It is a consequence of autopkgtest-pkg-python
> using `py3versions --requested`.

Uhmm, I was not aware of this.
 
> That being said, routine-update looks to drop this field without
> checking the python3 version selected.  I assume there was a
> good reason to drop this field extension in the past, but
> py3versions(1) manual does not really hint that this field is
> obsolete.  Perhaps switching the build dependency to enforce
> python3.11 (or python3.12) over generic python3 would be a
> working alternative.  In any case, both methods will require
> manual work on python3 version upgrades.

I've fixed routine-update to not remove that field.  I do not
have more time now - so if you feel like fixing libsbml that
would be great.

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Please help fixing meson/cmake code of btllib to use Debian packaged libargparse

[Andreas Tille]

Am Sat, Dec 30, 2023 at 04:27:31PM +0530 schrieb Nilesh Patra:
> > I can try to do so but I'm afraid we will run into the same issue as
> > for libsbml[1].
> 
> No, we won't. There are no autopkgtests for the python wrapper. If 
> autopkgtests for this
> are added, we should just run the same for default python3 and not all 
> supported versions.
> 
> libsbml tests fail due to us running it for supporter pyvers[1]. I don't 
> think it should be an issue.

But this is due to

   Testsuite: autopkgtest-pkg-python

by simply loading the module with any pyvers.  Loading libsbml would be
a sensible test as well but I have no idea how to tell
autopkgtest-pkg-python to use simply default Python3 version.

Kind regards
Andreas.
 
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059650#20

-- 
http://fam-tille.de

Re: Please help fixing meson/cmake code of btllib to use Debian packaged libargparse

[Andreas Tille]

Am Sat, Dec 30, 2023 at 01:19:32PM +0530 schrieb Nilesh Patra:
> > Sure.  Feel free to implement this - I'm just not available for the next
> > couple of days.
> 
> This is the currently existing solution itself. Only additional change needed 
> is to
> replace python3-all-dev with python3-dev in d/control.

I can try to do so but I'm afraid we will run into the same issue as
for libsbml[1].

Kind regards
Andreas.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059650#20

-- 
http://fam-tille.de

Re: [Advent bug squashing] Bugs from the past couple weeks

[Andreas Tille]

Hi Lance,

Am Fri, Dec 29, 2023 at 10:36:54PM +0700 schrieb Lin Qigang:
> While I do not plan to close any more before the new year, I enjoyed joining
> this year's bug squashing advent. Thank you again to all of my sponsors and
> those who offered help.

It was a pleasure to work with you.  In future I'd prefer to grant you
DM upload permissions for the packages you worked on.

> I hope everyone is enjoying their holidays. I wish
> you all a Happy New Year!

Same to you
Andreas

-- 
http://fam-tille.de

Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)

[Andreas Tille]

Am Wed, Dec 27, 2023 at 09:43:19PM +0100 schrieb Steffen Möller:
> > for teaching and meeting reasons.
> > 
> > But as I just wrote, 17-18 also works.
> 
> I'd opt for the earlier date, so we have a bit of a break before some of us I 
> expect to bump into each other again in Hamburg if Holger's event 
> materialises a month later.

Well, but there is FOSDEM 3+4. February - so this is even more dense. 

I'd love to fix 17-18. February (or lets meet at 16.2. February evening
inside the water tower like last year.)

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Please help fixing meson/cmake code of btllib to use Debian packaged libargparse

[Andreas Tille]

Am Fri, Dec 29, 2023 at 11:35:41AM +0530 schrieb Nilesh Patra:
> On a brief look, it does not seem easy and would mean maintaining a debian 
> specific
> patch for ever which maybe non-trivial for future versions.
> 
> Can we not support just the default python3-dev?

Sure.  Feel free to implement this - I'm just not available for the next
couple of days.

Kind regards
 Andreas.

-- 
http://fam-tille.de

Re: Please help fixing meson/cmake code of btllib to use Debian packaged libargparse

[Andreas Tille]

Hi,

Am Thu, Dec 28, 2023 at 03:28:54PM +0530 schrieb Nilesh Patra:
> 
> Fixed the build. Now it fails at dh_missing due to python stuff not being 
> installed.
> I am not sure if you want to create a new bin pkg with python wrapper or not 
> - so I
> leave the onus of finalizing it onto you.

I've added python3-btllib but its not that easy since we obviously need
to add different modules for Python3.11 and Python3.12.  I have no spare
cycles to implement this and leave it to someone who might be faster
than I (probably not before 9. January).

Kind regards
   Andreas.

-- 
http://fam-tille.de

Please help fixing meson/cmake code of btllib to use Debian packaged libargparse

[Andreas Tille]

Hi,

libargparse was accepted by ftpmaster.  Now meson code needs to be
adjusted to create a proper cmake input file to use the Debian packaged
version of libargparse (may be even that needs some cmake helper to be
detected properly).  Currently I do not have time to care for this[1]:

../meson.build:57:35: ERROR: Unknown variable "argparse_subproject".

Any help would be welcome
Andreas.

[1] https://salsa.debian.org/med-team/btllib/-/jobs/5088102

-- 
http://fam-tille.de

[Advent bug squashing] Thanks to all who joined the fun

[Andreas Tille]

Hi,

I think bug #1059214 was my last one in this years Advent bug squashing.
Thanks to all who joined.  For those who missed the fun for whatever
reason there are some "add build support for loongarch64" and some
"Fails to build source after successful build" low hanging fruits left.
;-)

For those who live in those parts of the world where Christmas matters
I wish a merry Christmas.  I'm looking forward work together with all
of you next year
   Andreas.

-- 
http://fam-tille.de

Re: Python-iow Autopkgtest Review (Bug #1035258)

[Andreas Tille]

Hi Israel,

Am Sat, Dec 23, 2023 at 08:07:22PM +0100 schrieb Komolehin Israel:
> I worked on Python-iow package by providing autopkgtest and providing a
> patch to fix some issues with the upstream test. CI was successful.

Nice.
 
> I would like this package to be reviewed as the test fails with Python3.12.
> I have provided a readme in debian/tests to document the source of the test
> failure which is pandas, however test passes with python3.11 and CI was
> successful.

For the next time please add a DEP3 header to your patches.
 
> I look forward to review and upload if all looks good. I will submit a bug
> report for test failure with Python3.12.

Uploaded.  Thanks a lot for your preparation
   Andreas.

-- 
http://fam-tille.de

Re: Do we need pynwb - if yes please care for its new dependency

[Andreas Tille]

Hi Yaroslav,

Am Thu, Dec 21, 2023 at 03:52:26PM -0500 schrieb Yaroslav Halchenko:
> So a solution would be to revert going to monitor github and then reimport
> source.  I do not think it is worthwhile packaging nwb-schema at this point
> since small and unlikely we would bother packaging any other package which
> would use it directly.
> 
> Do you agree to such changes -- then I could do the needed dance with git repo
> , just let me know.

I was more or less blindly following DPT advise to prefer Github over
PiPY.  Just feel free to do whatever seems the most efficient solution
for you.

Thanks a lot for your quick response
   Andreas. 

-- 
http://fam-tille.de

Do we need pynwb - if yes please care for its new dependency

[Andreas Tille]

Hi Yaroslav,

I bumped pynwb to its latest upstream version a couple of times.  It was
not release in any stable release since o-o-stable since the package was
always in a bad state.  Popcon is pretty low[1] - but we do not see any
Ubuntu users here so may be that's a weak metric.

My recent update in Git to latest upstream has uncovered that it needs
a new predepends[2].  If you consider this package a good citizen inside
Debian it would be great if you would care for this new package.  Other
bugs should be fixed in Salsa, thought.

Kind regards
Andreas.

[1] https://qa.debian.org/popcon.php?package=pynwb
[2] https://github.com/NeurodataWithoutBorders/nwb-schema

-- 
http://fam-tille.de

Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)

[Andreas Tille]

Hi Sascha,

Am Thu, Dec 21, 2023 at 03:13:04PM +0100 schrieb Sascha Steinbiss:
> 
> Absolutely! See [1] -- for February or early March we could have the room on
> weekends without a problem. I am now waiting for you guys to come up with a
> suggestion for possible specific dates so I can finalize the booking.
> 
> How about Feb 10-11, for example? My weekends are still free for now so it's
> your choice.

I admit I'd prefer Feb. 17-18 over 10-11.  Other opinions?
We could setup some poll if needed, but may be we can find a date the
easy way. ;-)

Kind regards
Andreas.


-- 
http://fam-tille.de

Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)

[Andreas Tille]

Hi Sasccha,

did you managed to reserve a room for our sprint?  It would be nice if
we know in advance to arrange travel for those who do not come from
close by.

Kind regards and have a nice CHristmas
   Andreas.

Am Mon, Nov 20, 2023 at 06:12:47PM +0100 schrieb Andreas Tille:
> Hi Sascha,
> 
> thanks a lot for checking the know venue.
> 
> Am Mon, Nov 20, 2023 at 03:27:35PM +0100 schrieb Sascha Steinbiss:
> > > I wouldn't mind going somewhere else for a change... but i can
> > > surely ask if we can have another weekend in February.
> 
> Same for me - I would like to meet at any location but we need some
> volunteer who will care for the venue.  So far nobody volunteered to do
> the work.  Lets wait until the upcoming weekend for someone to volunteer
> to do the actual work (not suggesting where it could be nice - we all
> know the world has some nice places ;-) )  If this is not the case I
> think Berlin is fixed and we should decide for a date.
>  
> > I have made some inquiries and as long we're only there on the weekend,
> > there are no blockers for at least February, likely also March.
> > I'd be happy to take care of the preparations once we come up with a
> > date, should we choose to meet in Berlin again.
> 
> We might do the same as last year:  Booking the room on top of the water
> tower for a Friday evening meeting and use the office of Saschas company
> for Saturday and Sunday.
> 
> See you in February
> Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Re: [Advent bug squashing] newer bmtk version, and other niceties

[Andreas Tille]

Hi Étienne,

Am Wed, Dec 20, 2023 at 08:51:34PM +0100 schrieb Étienne Mollier:
> And with this, I will probably wind down my activity for the
> remaining of the year

Thanks a lot for all your work and have a nice Christmas
Andreas.

-- 
http://fam-tille.de

needs-internet restriction (Was: Bug#1010653: closed ...) (Bug#1010653: fixed in busco 5.5.0-2)

[Andreas Tille]

Hi Andrius,

Am Wed, Dec 20, 2023 at 08:27:31AM +0200 schrieb Andrius Merkys:
> On 2023-12-19 18:51, Debian Bug Tracking System wrote:
> > [ Komolehin Israel Timilehin ]
> > * Added autopkgtest to check hmmer and prodigal integration (Closes: 
> > #1010653)
> 
> Thanks for working on this. I see that the added autopkgtest uses network to
> download the dataset. It is done properly, with 'needs-internet'
> restriction, which is good. However, does Debian CI enable internet access
> for such autopkgtests?

Isn't it exactly what needs-internet restriction was invented for?

May be I'm to naive here but I used it exactly for those cases and
it worked.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: Thanks a lot [ftpmas...@ftp-master.debian.org: ugene_49.1+dfsg-1_amd64.changes ACCEPTED into unstable]

[Andreas Tille]

Hi Pierre,

Am Tue, Dec 12, 2023 at 09:09:46PM +0100 schrieb Pierre Gruet:
> You're welcome! I am astonished to see it cleared NEW in one hour anf a half,

Yes, I had to double check when I've seen this.  Very nice

> I had not even the time to prepare my Advent Calendar email related to it.

:-

> That said, I am always very happy when we move software out of non-free!

That's definitely the best we can do!  I've adde Ugene to our
SoftwareLiberation Wiki page[1]

> Bug #1032688 was solved by you, and bug #1010358 by Michael :)

Well, I'm perfectly fine if these go on your account in team metrics
(which works per changelog owner). ;-)

Kind regards
   Andreas.

[1] https://wiki.debian.org/DebianMed/SoftwareLiberation

-- 
http://fam-tille.de

Thanks a lot [ftpmas...@ftp-master.debian.org: ugene_49.1+dfsg-1_amd64.changes ACCEPTED into unstable]

[Andreas Tille]

Hi Pierre,

this is really good and important work.  Thanks a lot for it

Andreas.

- Weitergeleitete Nachricht von Debian FTP Masters 
 -

Date: Tue, 12 Dec 2023 19:00:13 +
From: Debian FTP Masters 
To: Debian Med Packaging Team , 
Pierre Gruet 
Subject: ugene_49.1+dfsg-1_amd64.changes ACCEPTED into unstable

Thank you for your contribution to Debian.



Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 12 Dec 2023 14:49:53 +0100
Source: ugene
Binary: ugene ugene-data ugene-dbgsym
Architecture: source all amd64
Version: 49.1+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team 

Changed-By: Pierre Gruet 
Description:
 ugene  - integrated bioinformatics toolkit
 ugene-data - required data for UGENE - integrated bioinformatics toolkit
Closes: 1010358 1018252 1032688
Changes:
 ugene (49.1+dfsg-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version 49.1+dfsg
   * Refreshing patches
   * Shipping to main instead of non-free (Closes: #1018252):
 - Excluding files with non-free license (*.so and psipred)
 - Rewriting d/copyright
   * Updating install paths
   * Setting the runpaths so that private shared libraries can be found
   * Fixing spelling mistakes
   * Using python3 instead of python in shebangs
   * Fixing Lintian override syntax
   * Overriding Lintian warnings about spelling errors due to false positives
 .
   [ Andreas Tille ]
   * Fix watch file
   * Standards-Version: 4.6.2 (routine-update)
   * Build-Depends: s/libprocps-dev/libproc2-dev/ (Closes: #1032688)
 .
   [ Michael R. Crusoe ]
   * debian/patches/Fix-for-non-constant-SIGSTKSZ.patch: from Ubuntu,
 Closes: #1010358
Checksums-Sha1:
 94b7823fb1fc97799fbfe4df06950b8651d6ae7c 2290 ugene_49.1+dfsg-1.dsc
 5a8f61ab1ef8a884ffd57cd5ee8f8c2cb4a8c594 16227828 ugene_49.1+dfsg.orig.tar.xz
 f7c9a78fda51e047a8c1630d98c5b9deb9d4e39b 40636 ugene_49.1+dfsg-1.debian.tar.xz
 024ec6144aecdde337e85fd01371704ab0bdd4b0 7612600 ugene-data_49.1+dfsg-1_all.deb
 3581df8eda69842e4d996c76428bf4384c85bd6d 608828980 
ugene-dbgsym_49.1+dfsg-1_amd64.deb
 8513bc897a1929f09f843b28f9460adf1f99ad67 13359 
ugene_49.1+dfsg-1_amd64.buildinfo
 c5361fc2e28811066b4f6d687437d66b0b8ed183 22210740 ugene_49.1+dfsg-1_amd64.deb
Checksums-Sha256:
 d6b50935c791298da631f297312be1a56f97684acefb2f462152d4f9cb544feb 2290 
ugene_49.1+dfsg-1.dsc
 0e84cb5ebc26bacddd0d538b9ccf0906c49ac867a39cc81c033f8d3adf796b6d 16227828 
ugene_49.1+dfsg.orig.tar.xz
 8dfa17a74603f24075957774dd602d7bf1e27c5c3494aca5fbb690f7fd5ac793 40636 
ugene_49.1+dfsg-1.debian.tar.xz
 73a0e7773901fc7bf59488ace2ef35c5d04dba0db5af8fbb9912da4cbe1560b2 7612600 
ugene-data_49.1+dfsg-1_all.deb
 f627e3ca06edc61b7fff9ff33af4f5b0da70e7b1ae9e45d6e4220351c3fa5030 608828980 
ugene-dbgsym_49.1+dfsg-1_amd64.deb
 954a1daca20405613f306cdbba456a469ebab70b3a94711e33d56dbd4515582b 13359 
ugene_49.1+dfsg-1_amd64.buildinfo
 18b07770fb8abd57a756f2454386e1df0c0290b239923b21ac14b40832b204c3 22210740 
ugene_49.1+dfsg-1_amd64.deb
Files:
 4741a35a40dff8d6a425ea8d2772e62f 2290 science optional ugene_49.1+dfsg-1.dsc
 c2423d8701dc5fb5a007684882d3d167 16227828 science optional 
ugene_49.1+dfsg.orig.tar.xz
 8a36134d6fed4abd7e1424770ec7 40636 science optional 
ugene_49.1+dfsg-1.debian.tar.xz
 5be3f6a848d90b76512e81251b53cd83 7612600 science optional 
ugene-data_49.1+dfsg-1_all.deb
 c31a479dfc5ba8d9b8982ac92662e1ea 608828980 debug optional 
ugene-dbgsym_49.1+dfsg-1_amd64.deb
 f336fa8fdc484f38d594f6d1784fdab2 13359 science optional 
ugene_49.1+dfsg-1_amd64.buildinfo
 180f6b1502a223163062a95437b1bd96 22210740 science optional 
ugene_49.1+dfsg-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEM8soQxPpC9J9y0UjYAMWptwndHYFAmV4kFcACgkQYAMWptwn
dHYEhRAAlbfyripVaCFyMh1w3S1E+LtpMnXAuH97NfaX6aQ0rOxLlKIj8rXifFzv
308w8/EXks+EbenRPqXcCwXgtasntaOfJZ2r2ENzl/avGmTg3DQ/TD6YDYb5zeSC
5RoQcZ7SF+UmMi5/jS6fphROzjbsTvg+7tH4N4W0bxF1Y3ARRnz+20ytbuORhgHz
F+5zA9VVvsYr/enVb62FZBcn0ATAM9b8B3TAhlwShWRQXVDx3ylpca9vi+u2DwWz
4xoA0HayspzoEXiOh7Rx7dq1GeKWjkp69OL/Vs5u6gzY21Iw7VFDFifww2JwfNJS
jDW3EqZiGnBu4t4Zz4xYodgCkAbCtTJbhxRL+LCeaD8OtbSglg9bsCfQOC8geyBd
LExivKjCyroFe3Pd6K6vbI2o5XdWTkQM07r2Qwpg/Fh3FikEhfvi0AhFJJJIbunj
M18QRYtidz7mBgkKi4p8rVKVuS665Eag1+hjVvzcU3Qij6qe3TD9MzJON+OEnMUP
2kUKZ+J+U1sRo09PwEYtBkj6845PSRbFxeLpv51hnxqcWbiOR52j+9imhqBVL2gn
UB0bb5bF297FmCmKxxmRczkeUlZy6A49el+iD8UG1hSrBzrWGRI0qsmhqaO3fu3s
qIiOTa/2/34aj4QJ1WcNyqB/uv8x36kCJsZ07PB0oSrirQL4GK8=
=1Bbg
-END PGP SIGNATURE-


___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


- Ende weitergeleitete Nachricht -

-- 
http://fam-tille.de

Re: Attempt to upgrade sra-sdk

[Andreas Tille]

Hi Aaron,

Am Sun, Dec 10, 2023 at 06:30:01PM -0500 schrieb Aaron M. Ucko:
> 
> Because env/common.cmake doesn't actually try to use a system
> installation:
> 
>   #check_include_file_cxx(mbedtls/md.h HAVE_MBEDTLS_H)
>   set(HAVE_MBEDTLS_H 0) # TODO: disabling system mbedtls since it may be 
> outdated
> 
> Patching that logic to enable and honor the check reveals that its
> concerns are legitimate, with upstream bundling and evidently relying on
> a 3.x version whereas Debian still ships 2.28.5; arranging to use the
> Debian version yields several compilation errors in libs/cloud/gcp.c's
> Sign_RSA_SHA256, and quite possibly more errors elsewhere.
> 
> Per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036231, Debian
> packaging of mbed TLS 3.x is waiting on a long-term-support release
> series thereof, so our options are either backporting ncbi-vdb to build
> against 2.28. (perhaps with the help of reverse cherry-picks) or
> reinstating the bundled 3.x copy.

Thanks a lot for your analysis.  I admit I stumbled for no important
reason over sra-sdk and friends.  I'm perfectly fine with delaying the
upgrade until Debian packaged mbed is catching up.
 
Kind regards
   Andreas. 

-- 
http://fam-tille.de

Re: Attempt to upgrade sra-sdk

[Andreas Tille]

Hi Aaron,

Am Sat, Dec 09, 2023 at 08:23:26PM -0500 schrieb Aaron M. Ucko:
> 
> AFAICT, the immediate problem is that label_online_tests.patch refers to
> at least one removed or renamed test:
> 
>   CMake Error at test/internal/vdb-diff/CMakeLists.txt:42 
> (set_tests_properties):
> set_tests_properties Can not find test to add properties to:
>   Test_VDB_Diff_Check_success
> 
> Temporarily disabling this patch will let you focus on compilation
> issues for the time being.

We'll probably leave this for later
 
> Please also bear in mind that upstream maintains this code in
> conjunction with ncbi-vdb (lower-level) and ngs-sdk (higher-level), so
> it may help to update ncbi-vdb first and you may want to update ngs-sdk
> afterwards.

I should have known this but unfortunately I forgot.  I've pushed the
latest version of ncbi-vdb with patches adapted but get:

No mbedtls libs found installed in the system, using local copy...
-- Configuring done (1.1s)
CMake Error at libs/ncbi-vdb/CMakeLists.posix.txt:56 (add_library):
  Error evaluating generator expression:
  
$
  
  Objects of target "mbedx509" referenced but no such target exists.
Call Stack (most recent call first):
  libs/ncbi-vdb/CMakeLists.txt:84 (include)

  
CMake Error at build/common.cmake:185 (add_library):
  Error evaluating generator expression:

$

  Objects of target "mbedx509" referenced but no such target exists.


which is strange since libmbedtls-dev is in Build-Depends.  I'll leave
this to someone who is more educated with cmake than I.

 
> I'll take a closer look when I get a chance.

Hope my preparation is some welcome kick-start.  I wonder whether some
of our patches could be forwarded upstream to reduce the number of edits
for any new version. 

Kind regards
Andreas.

-- 
http://fam-tille.de

Attempt to upgrade sra-sdk

[Andreas Tille]

Hi Aaron,

I've spent some time into the new version of sra-sdk and tried to adapt
the patches to the new upstream version.  Salsa CI was not working at
the time of pushing so there is no build log but if you might like to
try on your side you will notice that my attempt failed.  I'd be super
happy if you might find some time to get the build working again.

Kind regards
Andreas.

-- 
http://fam-tille.de

Upgrading fis-gtm and closing CVE-2021-44496 CVE-2021-44504

[Andreas Tille]

Hi Amul,

I realised that fis-gtm is lagging behind upstream some versions and the
Debian packaged fis-gtm is featuring CVE-2021-44496 and CVE-2021-44504.
It would be great if you could upgrade the Debian package to the latest
upstream version.

Kind regards,
Andreas.

-- 
http://fam-tille.de

Debian Med video meeting tomorrow Saturday 2023-12-09 19:00 UTC

[Andreas Tille]

Hi,

this is the call for the next video meeting of the Debian Med team
that are an established means to organise the tasks inside our team.

Meetings usually take us only 15-20min depending what we are talking
about and how many people are joining.  The next meeting is tomorrow
   
 https://www.timeanddate.com/worldclock/fixedtime.html?iso=20231209T19

Despite technical issues of the last meeting I think we stick to the
known Debian Social channel

 https://jitsi.debian.social/DebianMedCovid19

The topic is what contributors have done in the past period and to
coordinate the work until the next meeting.

For those who are interested in hot topics we want to tackle, here
are some items:

  - Status of BioConductor transition
  - Python 3.12 transition
  - Advent bug squashing

Newcomers are always welcome.

See you tomorrow
 
   Andreas.

-- 
http://fam-tille.de

Wrong calls of snpEff in snippy (Was: Could some SnpEff user from the community please ping authors)

[Andreas Tille]

Control: reassign -1 snippy
Control: retitle -1 Wrong calls of snpEff
Control: tags -1 upsteam
Control: forwarded -1 https://github.com/pcingola/SnpEff/issues/510

Thanks to snpEff upstream I've found a solution[1] for the problem
reported above.  I've also added a conscise test case[2] which was
exposing the problem above (which is solved) but in a later call to
snpEff with a different command a new problem occures.

I have reported this to snpEff[3] since I hope to get quick help there
for another patch to snippy to simply get rid of some single line in
some output file.  If all fails we can remove this manuall inside the
snippy Perl code but I'm striving for a clean solution here.

Kind regards
Andreas.

[1] 
https://salsa.debian.org/med-team/snippy/-/blob/master/debian/patches/snpeff_v5.1%2B.patch
 
[2] 
https://salsa.debian.org/med-team/snippy/-/blob/master/debian/tests/test_for_working_snpeff_v5.1%2B
[3] https://github.com/pcingola/SnpEff/issues/510

-- 
http://fam-tille.de

Re: Could some SnpEff user from the community please ping authors

[Andreas Tille]

Hi Nilesh,

Am Wed, Dec 06, 2023 at 02:00:52AM +0530 schrieb Nilesh Patra:
> Sometimes just tagging upstream author does wonders :)

I hope I'll keep that trick in mind! ;-)

> They have replied and the (upstream) bug has been closed.
> BTW, are you able to still reproduce (without any fixes for snpeff/snippy) 
> #1031465?

Confirming snippy builds nicely and bug can be closed.
 
> For me, it is working fine in an unstable chroot (including autopkgtests)
> and maybe could be closed.

I've just pushed a patch for snippy that works with the options
suggested by snpEff upstream.  I need to do some further tests but I
think the problem is solved.

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: [Advent bug squashing] 9 bugs + 1 bug = 10 bugs

[Andreas Tille]

Hi Étienne,

Am Sun, Dec 03, 2023 at 03:54:57PM +0100 schrieb Étienne Mollier:
> > Please leave some low hanging fruits for me! ;-P
> 
> I see at least four screenful worth of low hanging fruits in the
> bug tracking system affecting Debian Med packages, if not more.
> That should be plenty for everyone.  ;)

Pt, don't tell here on a public list.  You are uncovering the reason
why I was able to close so many bugs in the past.  Newcommers might step
in and start closing bugs ...   Or even people claiming to have to less
time find out it just takes less than 5min to close a bug.

> > Honestly, if you both as well as Nilesh would not have joined the team
> > we would not manage to do all the work.  Its a great pleasure for me to
> > work together with you all.
> 
> You're welcome!

Thanks again
Andreas.

-- 
http://fam-tille.de