criteria for acceptable languages for central QA tools in Debian (was: Re: coordination between lintian/piuparts/adequate)

[Serafeim (Serafi) Zanikolas]

[forking to -devel]

Probably adequate is the logical place for this test, but adequate
doesn't build/run on ports architectures since it moved to golang,
so piuparts should probably keep its tests on those arches until
adequate moves to a more portable language or golang gets ported.

that's because unsupported ports architectures have not caught up to go 1.21,
which was released ~1.5 year ago. I'd claim that that says more about the
viability of those ports, than the suitability of go for Debian tooling. if you
feel strongly otherwise, I'd be happy to continue this discussion with a wider

I dont feel strongly about this, but I'd like to point out that I
disagree. IMO it was wrong to rewrite adequate (as any central QA tool
for Debian) in a language which is not available *everywhere*.

I'd like to discuss this with a focus on general principles, and only discuss
specifics (adequate, golang) to the extent that it helps reason about general
principles.

so we have a qa testing package that was written 11y ago in perl, and has been
orphaned for almost all of that time (10y!). it's not critical but it does serve
a purpose, and it's therefore nonideal that it's been orphaned for so long.
someone takes it over and rewrites it in a language that runs in all supported
arches, and likely in many ports too as long as they keep up with a relatively
recent version of the language (in this case, a version released 1.5y ago).

IMO it was wrong to rewrite adequate (as any central QA tool for Debian) in a
language which is not available *everywhere*.

first, I find this concern of little practical relevance: most adequate checks
are not arch-specific.

second, I'd not have adopted adequate if I had to maintain it in perl. given
this clarification, would you prefer the status quo (poor ports coverage but
active adequate maintenance) or would you rather still prefer an unmaintained
adequate with 100% ports coverage?

on a meta level: I find it incredible that this conversation needs to be had at
all, given the increasing median age of Debian contributors, and the limited
popularity of perl among younger people

thanks,
serafi

[Otto Kekäläinen]

Hi,

Post by Serafeim (Serafi) Zanikolas
[forking to -devel]

Probably adequate is the logical place for this test, but adequate
doesn't build/run on ports architectures since it moved to golang,
so piuparts should probably keep its tests on those arches until
adequate moves to a more portable language or golang gets ported.

that's because unsupported ports architectures have not caught up to go 1.21,
which was released ~1.5 year ago. I'd claim that that says more about the
viability of those ports, than the suitability of go for Debian tooling. if you
feel strongly otherwise, I'd be happy to continue this discussion with a wider

I dont feel strongly about this, but I'd like to point out that I
disagree. IMO it was wrong to rewrite adequate (as any central QA tool
for Debian) in a language which is not available *everywhere*.

I'd like to discuss this with a focus on general principles, and only discuss
specifics (adequate, golang) to the extent that it helps reason about general
principles.

I don't have the full context here, but to me it seems fine to use
various programming languages for the tools. The language landscape is
not like version control, where one solution (git) is by far more
popular than anything else, and using an obscure alternative would be
bound to cause friction to everybody else.

If acceptable languages is reduced to a list of top-10 or top-5 on
basis of general popularity, the specific language here (Go) would be
on it. If the list had certain criteria, such as support for (almost)
all Debian architectures, Go would still be on the list.

I am not young anymore, but I and young enough to not have learnt Perl
in the 90s, and if I see a Perl tool in Debian, I tend to not
contribute to it. My own preference is Python, but I see a lot of good
tools being written in Go and in Debian we have multiple recent new
and very capable contributors doing stuff in Go (Thanks Serafi for
adquate! Another is Nicolas who wrote lintian-ssg in Go). I am happy
to touch occasional Go stuff to help grow the Debian community, or any
other language that is reasonably mainstream and has the full
toolchain packaged and maintainer team in Debian.

[Jonathan Dowland]

Post by Serafeim (Serafi) Zanikolas
I'd like to discuss this with a focus on general principles, and only
discuss specifics (adequate, golang) to the extent that it helps
reason about general principles.

That's going to be pretty hard, because the scenario you present is
still pretty specific.

Post by Serafeim (Serafi) Zanikolas
so we have a qa testing package that was written 11y ago in perl, and
has been orphaned for almost all of that time (10y!). it's not
critical but it does serve a purpose, and it's therefore nonideal that
it's been orphaned for so long.

Certainly non-ideal. "Orphaned" does not give the full picture about the
state of the package, however: It could describe a package with critical
bugs that aren't getting fixed, or nobody doing any QA or NMU uploads of
it ever. Neither looks true for adequate.

Post by Serafeim (Serafi) Zanikolas
someone takes it over and rewrites it in a language that runs in all
supported arches, and likely in many ports too as long as they keep up
with a relatively recent version of the language (in this case, a
version released 1.5y ago).

"likely in many ports too" is dancing around the fact that it *doesn't*
run on at least one port, hence Holger's complaint.

An orphaned/unmaintained-but-functional package was still serving some
purpose and was available, and by uploading a rewrite in Go, it became
unavailable. That is a shame (how significant this is, is up for debate)

If you'd chosen to upload "adequate-ng" instead, this wouldn't have
happened, although, there would be plenty of drawbacks to that too.

We're discussing the drawbacks of what you did, but I must acknowledge
the benefits too: you've adopted a package, following the correct
procedures, and (in many other respects) improved it. Thanks!

You also made an effort to reach out to users and stakeholders before
you took the action, which was a good idea.

Post by Serafeim (Serafi) Zanikolas
on a meta level: I find it incredible that this conversation needs to
be had at all, given the increasing median age of Debian contributors,
and the limited popularity of perl among younger people

The "Perl Problem" is a wider issue we should explore in much more
depth. I'm personally a little surprised if it's true that younger
people are unprepared to take a stab at hacking Perl. But since that's
the case, we have deeply embedded, critical stuff written in Perl
everywhere. "adequate" is but the tip of the iceberg.

[Jeremy Stanley]

On 2024-12-12 14:36:51 +0000 (+0000), Jonathan Dowland wrote:
[...]

The "Perl Problem" is a wider issue we should explore in much more depth.
I'm personally a little surprised if it's true that younger people are
unprepared to take a stab at hacking Perl. But since that's the case, we
have deeply embedded, critical stuff written in Perl everywhere. "adequate"
is but the tip of the iceberg.

I think ageists like to assume all young people are lazy. Yes lazy
people of any age are disinclined to participate in projects written
in any language they're not already familiar with, or using any
tools or platforms they're not already familiar with. Also they're
going to disappear on you after a few months even if your project
does use languages and tools they're well-versed in, so there's not
a lot of point in putting in tons of effort to cater to them anyway.

Industrious young people are quite capable of working with any
available tools on projects in any language, I've met plenty of
them, they do exist. I was young once too, if I hadn't been willing
to learn to use tools and languages older than I am, I'd found other
hobbies and/or gone into a different field of work.

[Marc Haber]

Post by Jeremy Stanley
Industrious young people are quite capable of working with any
available tools on projects in any language, I've met plenty of
them, they do exist. I was young once too, if I hadn't been willing
to learn to use tools and languages older than I am, I'd found other
hobbies and/or gone into a different field of work.

I am not a young person any more (sad smiley), and my inclination to
work in uncomfortable or weird environments is significantly higher
when I am getting paid. Since Debian doesn't pay, it needs to have
comfortable or cool tools.

That being said, I frequently consider other tools comfortable than
young people do.

Greetings
Marc

[Marco d'Itri]

The "Perl Problem" is a wider issue we should explore in much more depth.

We would first need to determine that there is an actual problem.
Perl is quite healthy as a language and has aged much better than many
other younger languages: e.g. there is no need to update all code every
few years because backward compatibility is preserved basically forever
at this point.

Perl is still a fundamental tool for system administrators.

[Thomas Dineen]

Have you considered mobonics?

https://en.wikipedia.org/wiki/Moesha

Post by Marco d'Itri

The "Perl Problem" is a wider issue we should explore in much more depth.

We would first need to determine that there is an actual problem.
Perl is quite healthy as a language and has aged much better than many
other younger languages: e.g. there is no need to update all code every
few years because backward compatibility is preserved basically forever
at this point.

+1, advantages of Perl should not be ignored.
Andrius

[Marc Haber]

Post by Marco d'Itri

The "Perl Problem" is a wider issue we should explore in much more depth.

We would first need to determine that there is an actual problem.
Perl is quite healthy as a language and has aged much better than many
other younger languages: e.g. there is no need to update all code every
few years because backward compatibility is preserved basically forever
at this point.

+1, advantages of Perl should not be ignored.

I disagree violently with all efforts that would waste Debian people's
time to rewrite existing and well-working times just for the sake of
having them in a more "modern" programming language.

That time is much better spent with improving existing tools.

Greetings
Marc

[Matthias Urlichs]

Post by Marc Haber
I disagree violently with all efforts that would waste Debian people's
time to rewrite existing and well-working times just for the sake of
having them in a more "modern" programming language.

ITYM "well-working tools".

Post by Marc Haber
That time is much better spent with improving existing tools.

The point of rewriting *is* to improve an existing tool. Or, more
accurately, pave the way towards doing that.

Seriously. *If* the choice is (a) nobody touches the code with a
ten-foot-pole and its debbugs page accrues cruft nobody's going to fix,
or (b) somebody rewrites the tool to Python because, well, I'll leave
enumerating the reasons why one might want to do that (and/or why I
personally did exactly that, and continue to do that) for another time 



 anyway, *if* these are our choices then I'm all for (b).

The question is whether these really *are* our only choices.

--
-- regards
--
-- Matthias Urlichs

[Marc Haber]

On Sat, 14 Dec 2024 22:38:49 +0100, Matthias Urlichs

Post by Matthias Urlichs

Post by Marc Haber
I disagree violently with all efforts that would waste Debian people's
time to rewrite existing and well-working times just for the sake of
having them in a more "modern" programming language.

ITYM "well-working tools".

Post by Marc Haber
That time is much better spent with improving existing tools.

The point of rewriting *is* to improve an existing tool. Or, more
accurately, pave the way towards doing that.

Yes, go ahead with that, but don't force people to do that, and don't
take the old version away until the new one is feature par and bug
free.

Greetings
Marc

[Philipp Kern]

Hi,

On 12/15/24 2:11 PM, Marc Haber wrote:
[ Rewriting existing tools in another language ]

Post by Marc Haber
Yes, go ahead with that, but don't force people to do that, and don't
take the old version away until the new one is feature par and bug
free.

I find the latter a bit offensive and unrealistic. Rewrites after a
decade usually reduce complexity and excise features that turned out to
be a bad idea. Or introduce some subtle bugs that get ironed out only
when it sees usage.

In today's world the alternative is to remove the package - given the
rather aggressive removals we see in testing, if not unstable. That
would also not give you a version that has either feature parity nor bug
freeness - unless you count keeping it installed locally on your
machines and never getting updates again.

Kind regards
Philipp Kern

[Sean Whitton]

Hello,

Rewrites after a decade usually reduce complexity and excise features
that turned out to be a bad idea.

Indeed.

Or introduce some subtle bugs that get ironed out only when it sees
usage.

Indeed, but this work can end up being very costly. A lot of knowledge
might be built into the old code. Even if everything is well documented
and there are comments in the right places, it's still easy to lose
something in the rewrite.

Then you have to balance the reductions in complexity and excision of
features that weren't a great idea, against this risk of costly
regressions. Keeping the old program will often win.

In today's world the alternative is to remove the package - given the
rather aggressive removals we see in testing, if not unstable.

This seems like an overgeneralisation. For Perl, given their strict
stance to backwards compatibility, we can just keep it.

[Philipp Kern]

Post by Sean Whitton

Or introduce some subtle bugs that get ironed out only when it sees
usage.

Indeed, but this work can end up being very costly. A lot of knowledge
might be built into the old code. Even if everything is well
documented
and there are comments in the right places, it's still easy to lose
something in the rewrite.
Then you have to balance the reductions in complexity and excision of
features that weren't a great idea, against this risk of costly
regressions. Keeping the old program will often win.

In today's world the alternative is to remove the package - given the
rather aggressive removals we see in testing, if not unstable.

This seems like an overgeneralisation. For Perl, given their strict
stance to backwards compatibility, we can just keep it.

Assuming there aren't any other mandates that need to be applied to make
the package fit for release or someone can be found to implement them.
It's possible that there are fewer of them, but you still need someone
to patch them when they arise. (The context of my take was the lack of
maintainer (or maintenance).)

I guess I agree very much with the point raised by Richard: "the people
who wrote these scripts are no longer responding" (for one reason or
another).

As a mental exercise, substitute Perl with COBOL. It is very costly to
maintain these days because the knowledge went away - and because the
things are very load-bearing so that there is a lot of hesitance to
touch things. And younger people (ironically, like me) did not grow up
with it and thus have aversions. Keeping the old program will indeed
win, because even incremental changes are frowned upon.

I am fully aware that there is readable and well designed Perl that is
easier to maintain than some of the more freestyle Perl cobbled together
(e.g. without "use strict"). The better the environment around it
(tests, test instances etc.), the more comfortable people will feel to
make changes. Which I guess is a lesson for new software we write[1].

Kind regards
Philipp Kern

[1] I was amazed to see that snapshot has integration tests, for instance.

[Josh Triplett]

don't take the old version away until the new one is feature par and
bug free.

Leaving aside the points Philipp Kern made (some features are
intentionally removed, and code is rarely if ever "bug free")...

Another way of phrasing "don't take the old version away" is "someone
should keep maintaining the old version", and that has the standard
problems of where to find a willing "someone", *and* to what degree the
maintainer of the old version can convince the community to incur the
costs of continuing to support the old version.

Software exists in a community ecosystem, and one person willing to
maintain an alternate version of something doesn't always justify the
costs the rest of the community would incur to support that alternative.
That argument applies in both directions: people who do a rewrite have
to convince others that their version is worth supporting, and people
who want to stick with the old version have to convince others that
their version is worth supporting. And the community may not be willing
to support both concurrently, even if both have a non-zero number of
offers of maintenance. That isn't a bug.

[Sean Whitton]

Hello,

Post by Jonathan Dowland
The "Perl Problem" is a wider issue we should explore in much more
depth. I'm personally a little surprised if it's true that younger
people are unprepared to take a stab at hacking Perl. But since that's
the case, we have deeply embedded, critical stuff written in Perl
everywhere. "adequate" is but the tip of the iceberg.

People keep saying it, but is it true?

If you don't dig too deep, Perl and Python are really very similar in
what it is easier and more difficult to use them for.
The deeper philosophical differences aren't too relevant to maintaining
Debian stuff.

Even if people tend to have a strong preference for one over the other,
they can develop curiosity for learning a bit more about the other in
order to fix something
(happened to me recently in the direction Perl->Python).

[Matthias Urlichs]

Post by Sean Whitton
If you don't dig too deep, Perl and Python are really very similar in
what it is easier and more difficult to use them for.

That may well be, but that just means that there must be a different
reason why Perl has fallen by the wayside, more or less, while Python
has anything but.

Case in point I have written a veritable ton of Perl code, 30 to
15-or-so years ago, building the first version of our company's CMDB tool.

Nowadays? Python. Sorry. Version 3 of that CMDB system is Python from
top to bottom.

I'm not getting into the reasons here, that'd make for a way-too-long
text, but suffice to say that Python data structures are far more
*discoverable* than Perl, which translates to much easier bug fixing.
The same thing applies to typing. Did you try to statically-type-check a
Perl program lately?

--
-- mit freundlichen GrÌßen
--
-- Matthias Urlichs

[Sean Whitton]

Hello,

That may well be, but that just means that there must be a different reason
why Perl has fallen by the wayside, more or less, while Python has anything
but.

What gets and remains popular only sometimes does so because of its
quality. We think Debian is very high quality, but at various times it
has gained and lost popularity.

I think Perl is a really good example of this.

I'm not getting into the reasons here, that'd make for a way-too-long text,
but suffice to say that Python data structures are far more *discoverable*
than Perl, which translates to much easier bug fixing. The same thing applies
to typing. Did you try to statically-type-check a Perl program lately?

Yes, type checking is one advantage of Python over Perl.

[Bill Allombert]

The "Perl Problem" is a wider issue we should explore in much more depth.
I'm personally a little surprised if it's true that younger people are
unprepared to take a stab at hacking Perl. But since that's the case, we
have deeply embedded, critical stuff written in Perl everywhere. "adequate"
is but the tip of the iceberg.

The actual perl problem is that, since perl is very strict about
backward compatibility, perl scripts written 10 or 20 years ago still
work without requiring maintainance, hence they may appear to be
abandonned.
Rewriting such software in a language that require yearly maintainance
does not simplify maintainance in the long run, quite the opposite.

Cheers,

[Jonathan Dowland]

Post by Bill Allombert
The actual perl problem is that, since perl is very strict about
backward compatibility, perl scripts written 10 or 20 years ago still
work without requiring maintainance, hence they may appear to be
abandonned.
Rewriting such software in a language that require yearly maintainance
does not simplify maintainance in the long run, quite the opposite.

FWIW, a Ruby script I wrote to help me triage DSAs¹ is approaching its
20th birthday, I'm happy to report Ruby appears to have avoided any
disasters like Python's 2→3 transition.

[1] https://jmtd.net/dsafilter/

[Richard Lewis]

Post by Bill Allombert

The "Perl Problem" is a wider issue we should explore in much more depth.
I'm personally a little surprised if it's true that younger people are
unprepared to take a stab at hacking Perl. But since that's the case, we
have deeply embedded, critical stuff written in Perl everywhere. "adequate"
is but the tip of the iceberg.

The actual perl problem is that, since perl is very strict about
backward compatibility, perl scripts written 10 or 20 years ago still
work without requiring maintainance, hence they may appear to be
abandonned.

Doesnt this assume that development is "finished"?

I think the problem with perl is not the language (although it is harder
to read than python, ruby, even shell) but that a lot* of the people who
wrote those 10 or 20 year-old scripts are no longer responding to bugs
or making changes.

*not all, but it's only going one way

[Serafeim (Serafi) Zanikolas]

hi Jonathan,

Post by Jonathan Dowland

Post by Serafeim (Serafi) Zanikolas
I'd like to discuss this with a focus on general principles, and only
discuss specifics (adequate, golang) to the extent that it helps
reason about general principles.

That's going to be pretty hard, because the scenario you present is
still pretty specific.

Post by Serafeim (Serafi) Zanikolas
so we have a qa testing package that was written 11y ago in perl, and
has been orphaned for almost all of that time (10y!). it's not
critical but it does serve a purpose, and it's therefore nonideal that
it's been orphaned for so long.

Certainly non-ideal. "Orphaned" does not give the full picture about the
state of the package, however: It could describe a package with critical
bugs that aren't getting fixed, or nobody doing any QA or NMU uploads of
it ever. Neither looks true for adequate.

Post by Serafeim (Serafi) Zanikolas
someone takes it over and rewrites it in a language that runs in all
supported arches, and likely in many ports too as long as they keep up
with a relatively recent version of the language (in this case, a
version released 1.5y ago).

"likely in many ports too" is dancing around the fact that it *doesn't*
run on at least one port, hence Holger's complaint.

which one? https://buildd.debian.org/status/package.php?p=golang-defaults
suggests that go is available in all ports and the issue is that many are on a
several years' old version. I chose to use a couple of stdlib packages that are
"only" 1.5y old. the use of those packages could be trivially eliminated but I'm
rather skeptical that having adequate run on those ports is the most pressing
matter for those ports (as I wrote earlier: most adequate checks are arch-indep
and those that are not, are unlikely to manifest only in ports). patches welcome
to eliminate the use of those packages by anyone feeling otherwise

Post by Jonathan Dowland

Post by Serafeim (Serafi) Zanikolas
on a meta level: I find it incredible that this conversation needs to
be had at all, given the increasing median age of Debian contributors,
and the limited popularity of perl among younger people

The "Perl Problem" is a wider issue we should explore in much more
depth. I'm personally a little surprised if it's true that younger
people are unprepared to take a stab at hacking Perl. But since that's
the case, we have deeply embedded, critical stuff written in Perl
everywhere. "adequate" is but the tip of the iceberg.

"unprepared" is the wrong diagnosis imho. I fully agree with the responses of
Richard Lewis (perl's okay, but old perl contributors gradually fade away
without replenishment), Matthias Urlichs (life's too short to put up with weak
type checking) and Marc Haber ("Since Debian doesn't pay, it needs to have
comfortable or cool tools").

thanks,
serafi

[Serafeim (Serafi) Zanikolas]

Post by Serafeim (Serafi) Zanikolas
hi Jonathan,

[..]

Post by Serafeim (Serafi) Zanikolas

Post by Jonathan Dowland
"likely in many ports too" is dancing around the fact that it *doesn't*
run on at least one port, hence Holger's complaint.

which one? https://buildd.debian.org/status/package.php?p=golang-defaults
suggests that go is available in all ports and the issue is that many are on a
several years' old version. I chose to use a couple of stdlib packages that are
"only" 1.5y old. the use of those packages could be trivially eliminated

I was wrong: gccgo-14 is not available for hppa, m68k and sh4 (and neither is,
of course, golang-go).

fwiw, adequate as of 0.17.5 targets the latest go version that is implemented by
gccgo (which severely lags behind golang-go), so that it builds for all of the
other ports

Post by Serafeim (Serafi) Zanikolas
but I'm
rather skeptical that having adequate run on those ports is the most pressing
matter for those ports (as I wrote earlier: most adequate checks are arch-indep
and those that are not, are unlikely to manifest only in ports).

Post by Jonathan Dowland

Post by Serafeim (Serafi) Zanikolas
on a meta level: I find it incredible that this conversation needs to
be had at all, given the increasing median age of Debian contributors,
and the limited popularity of perl among younger people

[Wouter Verhelst]

Hi,

Post by Serafeim (Serafi) Zanikolas
[forking to -devel]

Probably adequate is the logical place for this test, but adequate
doesn't build/run on ports architectures since it moved to golang,
so piuparts should probably keep its tests on those arches until
adequate moves to a more portable language or golang gets ported.

that's because unsupported ports architectures have not caught up to go 1.21,
which was released ~1.5 year ago. I'd claim that that says more about the
viability of those ports, than the suitability of go for Debian tooling.. if you
feel strongly otherwise, I'd be happy to continue this discussion with a wider

I dont feel strongly about this, but I'd like to point out that I
disagree. IMO it was wrong to rewrite adequate (as any central QA tool
for Debian) in a language which is not available *everywhere*.

I'd like to discuss this with a focus on general principles, and only discuss
specifics (adequate, golang) to the extent that it helps reason about general
principles.
so we have a qa testing package that was written 11y ago in perl, and has been
orphaned for almost all of that time (10y!). it's not critical but it does serve
a purpose, and it's therefore nonideal that it's been orphaned for so long.
someone takes it over and rewrites it in a language that runs in all supported
arches, and likely in many ports too as long as they keep up with a relatively
recent version of the language (in this case, a version released 1.5y ago).

My 2 cents, as an ex m68k porter:

There is always work to be done to support an architecture. In Debian,
most of that work goes to

- Making sure the kernel works
- Making sure gcc works
- Making sure binutils work
- Making sure libc works

This doesn't cover everything, but it covers pretty much 75% of the
work of keeping an architecture alive.

Any language that builds on that work makes it more likely that it will
be supported by all Debian architectures, including less popular ones as
well as future ones that still need to be bootstrapped.

Porting a language such as golang to a new architecture is a fairly
significant undertaking, as it requires that you redo much of the work
that had already been done while porting libc, as golang chose to have
their own syscall interface and ABI rather than reusing the libc one
(presumably for good reasons, I have no idea; regardless it's orthogonal
to the point I'm trying to make). This is true not only for golang, but
also for all compilation and/or runtime environments that require
architecture-specific work.

Yes, some architecture maintainer can work on the required patches, but
there are only so many of them and they don't have infinite time for all
the compilation and runtime environments out there that require
architecture support, and they also may not have the required skill set
to do this work for each of them. So sometimes the work gets postponed
until the architecture has more users and then someone gets annoyed
sufficiently to do the work, or the maintainers of the language
environment see the architecture no longer as fringe and do it
themselves.

Sometimes patches for your architecture are difficult to submit; e.g.,
at some point the LLVM project was notoriously bad at accepting porter
patches for architectures they considered fringe or otherwise
uninteresting, making use of LLVM-based runtimes and languages only
implemented in LLVM (e.g., rust for much of its lifetime) problematic on
those architectures. I have not followed along with LLVM in recent
years, perhaps this situation has been resolved, but again this is not
core to the point I'm trying to make.

With that background,

If you write something for the project, I think you should totally
choose the language that you're most familiar and comfortable with.
Sometimes that means disappointing people using architectures on which
your language of choice is not available. That's fine, provided you're
not trying to replace or implement a core component of Debian.

If you're trying to write something that eventually should be running on
*every* Debian system out there, then please, for the love of all that
is important to you, don't use something that requires specific porter
work. But outside that constraint? Do whatever makes you most
productive.

I did that when I chose perl as the language to write extrepo; knowing
full well it's not as popular as it once was, I still decided that I
could work with that most easily and that it would be much more
efficient, *for me*, if I chose that language to write extrepo in.

And you should absolutely do the same.

[Serafeim (Serafi) Zanikolas]

Wouter, thank you so much for this response. your message has motivated me to
change adequate to target gccgo (rather than golang-go, which is a couple of
years ahead), to extend the availability of adequate to more ports

Post by Wouter Verhelst
Hi,

[..]

Post by Wouter Verhelst
If you write something for the project, I think you should totally
choose the language that you're most familiar and comfortable with.
Sometimes that means disappointing people using architectures on which
your language of choice is not available. That's fine, provided you're
not trying to replace or implement a core component of Debian.
If you're trying to write something that eventually should be running on
*every* Debian system out there, then please, for the love of all that
is important to you, don't use something that requires specific porter
work. But outside that constraint? Do whatever makes you most
productive.

two things: first, what is a "core component of Debian" is very much up to
debate, but I'd be quite surprised if anybody made the case that adequate is.
second, any porter work to make gccgo available would be valuable in its own
sake, given how many other programs are written in go these days

[Holger Levsen]

Post by Serafeim (Serafi) Zanikolas
two things: first, what is a "core component of Debian" is very much up to
debate, but I'd be quite surprised if anybody made the case that adequate is.

adequate is run on all 70000 binary packages on piuparts.debian.org. I'm really
curious whether this will blow up when piuparts.d.o will be upgraded to trixie
running the new adequate...

(actually adequate is run on many more binary packages on piuparts.d.o, because
p.d.o is not only testing unstable...)

I would have loved if a test run with the new adequate on all those packages would
have been made before the old adequate got kicked out. I guess technically it's
not too late to do such a test run on the archive.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

its crazy that civilization is ending in like 20-30 years and were just here
working jobs. (@RobDenBleyker)

[Serafeim (Serafi) Zanikolas]

hi Holger,

Post by Holger Levsen

Post by Serafeim (Serafi) Zanikolas
two things: first, what is a "core component of Debian" is very much up to
debate, but I'd be quite surprised if anybody made the case that adequate is.

adequate is run on all 70000 binary packages on piuparts.debian.org. I'm really
curious whether this will blow up when piuparts.d.o will be upgraded to trixie
running the new adequate...
(actually adequate is run on many more binary packages on piuparts.d.o, because
p.d.o is not only testing unstable...)
I would have loved if a test run with the new adequate on all those packages would
have been made before the old adequate got kicked out. I guess technically it's
not too late to do such a test run on the archive.

sure, let's find out! wouldn't this be simply a matter of pinning adequate to
testing/unstable? or even easier, you could just copy the adequate executable
from unstable to a bookworm instance (since adequate's only versioned dependency
is libc6 (>= 2.34) and latest stable ships 2.36

Paul Wise runs a test instance that has made adequate hit a limit at some point
(not specific to the rewrite, see #1077704), but I've no idea of how many
packages he had installed

slightly tangential: I'm somewhat surprised that piuparts.d.o would run
adequate/stable. that might have made sense with an unmaintained adequate, but
I've added three new checks since the rewrite and it'd make no sense to have to
wait for a stable releases to use them (yes, I also owe you a patch to update
the hardwired list of adequate tags in piuparts; I've been holding back because
every single message from you on adequate comes across as bitter)

thanks,
serafi

ps. happy to also have a phone/video call if that would help us work better
together

[Holger Levsen]

Post by Serafeim (Serafi) Zanikolas
hi Holger,

as you have addressed me here and...

Post by Serafeim (Serafi) Zanikolas

Post by Holger Levsen
(actually adequate is run on many more binary packages on piuparts.d.o, because
p.d.o is not only testing unstable...)
I would have loved if a test run with the new adequate on all those packages would
have been made before the old adequate got kicked out. I guess technically it's
not too late to do such a test run on the archive.

sure, let's find out! wouldn't this be simply a matter of pinning adequate to
testing/unstable? or even easier, you could just copy the adequate executable
from unstable to a bookworm instance (since adequate's only versioned dependency
is libc6 (>= 2.34) and latest stable ships 2.36

... and here ^, I have to tell you that's *your* duty when rewriting adequate
in another langugage.

Post by Serafeim (Serafi) Zanikolas
slightly tangential: I'm somewhat surprised that piuparts.d.o would run
adequate/stable.

I told you in 2024 already that piuparts.d.o runs adequate and that piuparts.d.o
runs stable.

Post by Serafeim (Serafi) Zanikolas
that might have made sense with an unmaintained adequate, but
I've added three new checks since the rewrite and it'd make no sense to have to
wait for a stable releases to use them (yes, I also owe you a patch to update
the hardwired list of adequate tags in piuparts; I've been holding back because
every single message from you on adequate comes across as bitter)

I'm sorry if I come accross as bitter but I've been trying to tell
you since the rewrite about this (and other problems) and that the new
adequate needed more testing before uploading to unstable, but you just didnt
listen...

Post by Serafeim (Serafi) Zanikolas
ps. happy to also have a phone/video call if that would help us work better
together

no, thanks. I'm not even involved in piuparts anymore.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Any business accepting Bitcoin is participating in the human race’s suicide.

[Serafeim (Serafi) Zanikolas]

Post by Holger Levsen

Post by Serafeim (Serafi) Zanikolas
hi Holger,

as you have addressed me here and...

Post by Serafeim (Serafi) Zanikolas

Post by Holger Levsen
(actually adequate is run on many more binary packages on piuparts.d.o, because
p.d.o is not only testing unstable...)
I would have loved if a test run with the new adequate on all those packages would
have been made before the old adequate got kicked out. I guess technically it's
not too late to do such a test run on the archive.

sure, let's find out! wouldn't this be simply a matter of pinning adequate to
testing/unstable? or even easier, you could just copy the adequate executable
from unstable to a bookworm instance (since adequate's only versioned dependency
is libc6 (>= 2.34) and latest stable ships 2.36

... and here ^, I have to tell you that's *your* duty when rewriting adequate
in another langugage.

happy to do so, it's just that I thought that I was talking to somebody from the
piuparts team :)

your "I'm really curious whether this will blow up" is completely devoid of
technical specifics, and frankly comes across as condensending. your "70k
packages" made me think that you're worried about scalability, but skimming
through piuparts.d.o logs suggests that piuparts invokes adequate for one
package at a time, so that's not it.

Post by Holger Levsen

Post by Serafeim (Serafi) Zanikolas
that might have made sense with an unmaintained adequate, but
I've added three new checks since the rewrite and it'd make no sense to have to
wait for a stable releases to use them (yes, I also owe you a patch to update
the hardwired list of adequate tags in piuparts; I've been holding back because
every single message from you on adequate comes across as bitter)

I'm sorry if I come accross as bitter but I've been trying to tell
you since the rewrite about this (and other problems) and that the new
adequate needed more testing before uploading to unstable, but you just didnt
listen...

I have written to the piuparts team *prior* to uploading the rewrite to
unstable, and the only response I received was positive
(https://alioth-lists.debian.net/pipermail/piuparts-devel/2024-July/009870.html).
did you respond to that email and it got lost on the way, or was it in another
context? (I'm discounting your initial, private response to my ITA, which was
before the actual rewrite)

as for "other problems", I note that you have filed exactly zero bugs against
adequate since the rewrite

if you care about adequate, *please* tone down the negativity and file actual
bugs with specifics

thanks,
serafi

[Soren Stoutner]

Post by Serafeim (Serafi) Zanikolas
if you care about adequate, *please* tone down the negativity and file actual
bugs with specifics

+1

[Otto Kekäläinen]

Post by Holger Levsen

Post by Serafeim (Serafi) Zanikolas
two things: first, what is a "core component of Debian" is very much up to
debate, but I'd be quite surprised if anybody made the case that adequate is.

adequate is run on all 70000 binary packages on piuparts.debian.org. I'm really
curious whether this will blow up when piuparts.d.o will be upgraded to trixie
running the new adequate...
(actually adequate is run on many more binary packages on piuparts.d.o, because
p.d.o is not only testing unstable...)
I would have loved if a test run with the new adequate on all those packages would
have been made before the old adequate got kicked out. I guess technically it's
not too late to do such a test run on the archive.

There have been discussions about adding adequate to Salsa CI and run
it by default as part of the piuparts job. If you are now preparing to
have adequate by default in piuparts, then it would make sense to have
it by default in Salsa CI as well, right?

If we do it quickly now there would be time to start seeing some
packages fail on Salsa CI adequate runs before it happens en masse on
actual piuparts. Would that be helpful and appropriate at this time?

[Holger Levsen]

Post by Otto Kekäläinen
There have been discussions about adding adequate to Salsa CI and run
it by default as part of the piuparts job. If you are now preparing to
have adequate by default in piuparts, then it would make sense to have
it by default in Salsa CI as well, right?

adequate has been run by piuparts.d.o since 2013. that was the whole point
of my mail.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

If you want to learn to live with Covid, as in catch it repeatedly, then you're
going to have to learn to live with Long Covid. (1goodtern)