Dear maintainer,

I included Debian Science team and Debian HPC team into this question
since here should be the experts whether this package might have some
remaining use inside Debian.

I suggest removing lcas-lcmaps-gt4-interface from Debian for the
following reasons:

 * relies on the Globus Toolkit (GT4), which has reached "End of Life"
   and is no longer maintained.
 * orphaned upstream so does not receive security patches, posing
   a risk to authentication workflows.
 * uses old X.509 GSI standards that are often incompatible with modern
   OpenSSL versions and have been replaced by OAuth2/OIDC tokens.
 * no function outside of legacy scientific grid computing. For standard
   servers or desktops, it is useless
 * removal would reduces technical debt and prevents potential
   dependency conflicts during future Debian upgrades.
 * there are no (build-)dependencies to other packages
 * There are no votes in popcon
https://qa.debian.org/popcon-graph.php?packages=lcas-lcmaps-gt4-interface&show_installed=on&show_vote=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
 * There seems to be no active maintainer

This bug serves as a pre-removal warning. After one month, the bug will be
reassigned to ftp.debian.org to actually request removal of the package.

In case the package should be removed from unstable, you may reassign this
bug report:

    Control: severity -1 normal
    Control: retitle -1 RM: lcas-lcmaps-gt4-interface -- RoM; rc-buggy
    Control: reassign -1 ftp.debian.org
    Control: affects -1 + src:lcas-lcmaps-gt4-interface

Alternatively, you may wait a month and have it reassigned.

In case you disagree with the above, please add a wontfix tag to this bug.

    Control: tags -1 + wontfix

Doing so will also prevent automatic reassignment.

This package was highlighted in the Bug of the Day[1] initiative, which
aims to introduce newcomers to manageable tasks and guide them through
the workflow to solve them. The focus of this initiative is on migrating
packages to Salsa, as it's a great way to help newcomers become familiar
with a consistent Git-based workflow.

Kind regards
   Andreas.


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

Hi Dennis,

thanks a lot for your prompt response.  That's very helpful.

Am Mon, Jan 26, 2026 at 09:43:07AM +0100 schrieb Dennis van Dok:

Cool.  Happy that I was wrong with my suspicion.

Very good to know!

Sorry about my false statement in this aspect.

If its relevant for Debian 14 just lets keep it.

Surely this is not a requirement.  It was my (broken way) to say "well,
it seems it is outdated in the scientific context and has no other use
(at least to me knowledge).

Thank you for your insight.

That's surely the weak part of popcon.  In case you have some contact
and the local policy might permit running popcon it would be great if
you could advertise this.

I'm happy to realise this.  I'm very sorry about the wrong assumtion -
I'm probably way to used to the situation that I get no answer at all.

Since I have some experience in doing this I could offer to do this as
"punishment" for my wrong assumptions.  If you tell me whether you have
some prefered team (maybe Debian Science or plain Debian team) I could
create a repository with the content of past releases.

Kind regards
    Andreas.

Hi Mischa,

Am Mon, Jan 26, 2026 at 11:09:58AM +0100 schrieb Mischa Salle:

Thank you for the additional information.

Very nice!

Good to know.

I checked

https://tracker.debian.org/pkg/lcas-lcmaps-gt4-interface

saying

    The VCS repository is not up to date, push the missing commits.

Its maintained in some SVN

https://ndpfsvn.nikhef.nl/viewvc/mwsec/packaging/debian/trunk/lcas-lcmaps-gt4-interface/

which has no commits since 12 years and seems to be at least temporarily
not available (see #1124782),  Last Upload was >8 years ago - these are
typical features I have observed in packages that are not maintained.

As I suggested in my other mail I'd volunteer to help migrating the
packaging to Salsa.

Kind regards and sorry for my wrong assumption
    Andreas.

Op 25-01-2026 om 10:33 schreef Andreas Tille:

While that may be true, there are still people who monitor the software
for security reasons.

How was this conclusion reached? I know upstream maintainer and I know
that security patches *will* be provided if issues come up.

This is indeed legacy software, but for the moment still used in some
scientific communities while a transition to tokens is underway.
Removing it from Debian is fine, but then we will still have to provide
those communities with Debian compatible packages through other channels.

I was not aware that this was a requirement for inclusion ;-)

That is highly unlikely, unless the entirity of the Globus Toolkit is
also on the block. I think the fate of this package is tied to the GT.

Which I can understand as most site admins do not enable this for their
servers.

Not true ;-)

I'll check it out, thanks.

hi all,

*Only* the *original* Globus Toolkit is EOL, however it has been forked
and is maintained and frequently updated, now under the name the Grid
Community Toolkit, see
https://github.com/gridcf/gct?tab=readme-ov-file#grid-community-toolkit
The packages currently in Debian have for many years already been based
on the GCT and are packaged for Debian by Mattias Ellert. See for
example
https://packages.debian.org/trixie/libglobus-gridmap-callout-error-dev
which has all the information.

see above, upstream is not at all orphaned, neither the libglobus*
dependencies nor the lcas-lcmaps-gt4-interface itself.

All the software packaged for Debian is kept up to date for the latest
OpenSSL versions and is built and tested for a variety of distributions
including Debian stable, testing etc. and the latest Fedora.

+1 to Dennis' answer.

+1 to Dennis' answer. Plus I am one of the developers of both the
lcas-lcmaps-gt4-interface and the Grid Community Toolkit. So in a sense
there aren't even external dependencies.

Indeed, where does this conclusion come from?! The debian package pages
has clearly all the information, both about the maintainer, about the
move to the Grid Community Toolkit etc.

Kind regards,
Mischa Sallé

Op 26-01-2026 om 20:14 schreef Andreas Tille:

No worries--we are glad the situation has been made clear.

I shouldn't worry about it. I've migrated to github for now, but the
release cycle is so long I don't think there is a benefit to moving to
Salsa?

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124782

and
https://github.com/NDPF/mwsec-packaging-debian/tree/main/lcas-lcmaps-gt4-interface

If there *is* a benefit (maybe due to running build pipelines by the
time Debian 14 comes around) I am happy to move it to Salsa as well.

Best,

Dennis

Hi Dennis,

Am Tue, Jan 27, 2026 at 01:20:22PM +0100 schrieb Dennis van Dok:

Thank you for taking it this way.  I'm really happy about this.

This are the benefits I see on hosting the packaging on Salsa:

  1. This is Debian packaging, and Salsa is where Debian packaging
     expertise lives.
  2. You can benefit easily from automated maintenance (e.g. janitor MR
     proposals).
  3. Salsa CI can verify the packaging and provide full logs when
     other Debian developers need to help debug issues.
  4. Salsa is the canonical place other Debian contributors will look first.
  5. Merge requests from drive-by contributors are more likely on Salsa.
  6. Consistent access control via Debian accounts (no extra GitHub setup).

Even with long release cycles, hosting on Salsa mainly reduces future
friction — migration later is usually more work than starting there.

Kind regards
    Andreas.

Op 27-01-2026 om 14:13 schreef Andreas Tille:

OK, you have convinced me. I will move the packaging to Salsa.