Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Andrey Rakhmatullin]

On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote:
> > My concern about Gitlab is not its *additions* to existing services, but
> > its *duplications* of core services already in Debian.
> 
> I agree, that's the key problem.
> 
> The Debian archive itself is a VCS, so git-maintained packaging is also a
> duplication, and keeping the official VCS and git synchronized is causing
> additional work for developers, which is why people are opposed to having it
> mandated.
The Debian archive itself is a *bad* and *poor* VCS. It should be obvious
in which areas it's poor, and it's bad e.g. because force pushes are
enabled, the history is periodically truncated (though there is no easy
way to get it anyway) etc.
It makes sense that some people want to replace it with a good VCS, but I
agree that adding a good VCS only gives us two VCSes because replacing
will never happen.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

On Tue, May 21, 2024 at 12:32:52AM +0200, Bernd Zeimetz wrote:
> > > All these things should make it much more easy for other people or
> > > automated tools to send merge requests or keep maintaining a
> > > package in
> > > case the original maintainer becomes MIA.
> > 
> > 
> > Mandating a specific git layout is a big jump from not requiring a
> > VCS at all. 
> 
> yes, its a big jump, but we are in 2024 and a modern workflow should be
> expected from a modern distribution.
People will resign.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: About i386 support

[Andrey Rakhmatullin]

On Mon, May 20, 2024 at 07:16:54PM -0300, Leandro Cunha wrote:
> > > > which is good news. The end of support for 32 bits will not
> > > > affect the lives of almost anyone who has machines purchased after
> > > > 2011 and who bought them after that
> > >
> > > Does this also mean he support for armhf will be dropped ?
> > There is no "end of support for 32 bits" yet so no.
> When you refer to 32 bits you are referring to i386 (see the subject),
No, please don't, this confuses people.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Russ Allbery]

Simon Richter  writes:

> A better approach would not treat Debian metadata as git data. Even the
> most vocal advocate of switching everything to Salsa writes in his MR
> that the changelog should not be touched in a commit, because it creates
> conflicts, and instead a manual step will need to be performed later.

This is not a Debian-specific problem and has nothing to do with any
special properties of our workflows or differences between packaging and
other software maintenance tasks.  It's a common issue faced by everyone
who has ever maintained a software package in Git and wanted to publish a
change log.

There are oodles of tools and workflows to handle this problem, ranging
from writing the change log based on the Git commits when you're making
the release to accumulating fragments of release notes in separate files
and using a tool to merge them.  dch's approach of using the Git commit
messages is one of the standard solutions, one that will be familiar to
many people who have faced this same problem in other contexts.

The hard part with these sorts of problems is agreeing on the tool and
workflow to use to solve it, something Debian struggles with more than
most software projects because we lack a decision-making body that can say
things like "we're going to use scriv" and make it stick.  But that isn't
because packaging is a special problem unsuited to Git.  Git has a rich
ecosystem with many effective solutions to problems of this sort.  It's
because we've chosen a governance model that intentionally makes central
decision-making and therefore consistency and coordination difficult, in
exchange for other perceived benefits.

-- 
Russ Allbery (r...@debian.org)  

Re: finally end single-person maintainership

[Simon Richter]

Hi,

On 5/21/24 10:43, Luca Boccassi wrote:


The ecosystem, however, does not support our workflows, and adapting it
to do that is even more effort than maintaining our own tools. [...]



That's a problem of our workflows, which are horrible. The solution is
not to double down on them.


Our workflows are largely influenced by what we do here: we maintain 
packages. This is different from "developing software", or "operating 
infrastructure."


If we can improve the workflows, then I'm all for it. What does not 
work, however, is to replace them with workflows from a different task.


All we are doing here is providing a mapping of the packaging workflow 
onto a git software development workflow. It still remains a packaging 
workflow, because the *goal* of the workflow is the completion of 
packaging tasks.


Providing an implementation layer does not change the goal layer, and 
GitLab does not provide any tools on the goal layer.


If we had buttons in GitLab "import new upstream release" or "show 
issues affecting the stable release branch", I would consider that as 
support for a packaging workflow. As it is now, GitLab only supports the 
workflows that the implementation layer below the goal layer typically 
uses, including workflows that break the upper layer.



At the very least, GitLab integration would allow me to automate such a
simple thing as changelog handling in a more comfortable way than
displaying instructions how to download the conflicting branch into
local git, resolve the conflicts manually, and force-push the branch to
solve the problem.



gbp dch --commit --release


Where is that button in GitLab?

That's my point: GitLab is a step *back* from the commandline tools for 
git integration.


   Simon

Re: finally end single-person maintainership

[Otto Kekäläinen]

Hi Simon!

> > A better approach would not treat Debian metadata as git data. Even the
> > most vocal advocate of switching everything to Salsa writes in his MR
> > that the changelog should not be touched in a commit, because it creates
> > conflicts, and instead a manual step will need to be performed later.

Not exactly, I said it is unnecessary work and doing it will just
cause more work.

Exact quote: "These commits have intentionally no debian/changelog
updates as it causes every single rebase or cherry-pick of a commit to
always have a merge conflict. It is much better to have all commits
as-is, and then right before upload just run gbp-dch --auto to
automatically generate the changelog."

Thus better not to inject debian/changelog changes in every single
patch and instead..

> > At the very least, GitLab integration would allow me to automate such a
> > simple thing as changelog handling in a more comfortable way than
> > displaying instructions how to download the conflicting branch into
> > local git, resolve the conflicts manually, and force-push the branch to
> > solve the problem.
>
> gbp dch --commit --release

..just let automation handle it, like Luca and many others already
know. Personally I prefer the variant `gbp dch --verbose --auto
--release` but essentially it does the same thing.

Anyway, thanks Simon for doing a review on
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19, at
least I know you have tried using Salsa and are speaking from a point
of some experience when criticising it (unlike apparently many
others).

Back on-topic of single-person maintainership - has anyone made a list
of which packages have only *one* maintainer/git committer and are in
the set of top-1000 or top-5000 Debian packages? We should perhaps ask
those people why they don't have co-maintainership, and why they
resist sharing the development work. Debbugs is one example - it has
multiple open MRs and patches in the bug tracker but somehow the sole
active maintainer does not see value in granting more people commit
permissions. If we learn how these maintainers think, perhaps we can
come up with a model to facilitate having more co-maintenance that can
apply to the exact cases where co-maintenance is missing.

- Otto

Re: Bug#1071528: ITP: hardinfo2 -- Hardinfo2 offers System Information and Benchmark for Linux Systems

[Lucas Castro]

Em 20/05/2024 22:53, xiao sheng wen(肖盛文) escreveu:

Hi,

  I had report bug #1070830[1], hardinfo package change upstream repo 
to hardinfo2

also is a better way.

IMHO, hardinfo2 only is the new version of hardinfo, it's not 
necessary to ITP a new
hardinfo2 src package in Debian. The new version has a new binary 
package named hardinfo2

is no problem.


I had mentioned that with upstream, but no response from Debian actual 
maintainer.



There's some ways to solve that.




Regard,
atzlinux

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

在 2024/5/20 23:01, Lucas Castro 写道:

Package: wnpp
Severity: wishlist
Owner: Lucas Castro 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name    : hardinfo2
   Version : 2.1.2
   Upstream Contact: Name 
* URL : https://hardinfo2.org/
* License : GPL-2
   Programming Lang: C
   Description : Hardinfo2 offers System Information and 
Benchmark for Linux Systems


Hardinfo2 is based on hardinfo, which have not been released >10 
years. Hardinfo2 is the reboot that was needed.


Hardinfo2 offers System Information and Benchmark for Linux Systems. 
It is able to
obtain information from both hardware and basic software. It can 
benchmark your system and compare

to other machines online.

Features include:
- Report generation (in either HTML or plain text)
- Online Benchmarking - compare your machine against other machines

Status
--
- Capabilities: Hardinfo2 currently detects most software and 
hardware detected by the OS.

- Features: Online database for exchanging benchmark results.
- Development: Currently done by contributors, hwspeedy maintains

Hardinfo2 is based on hardinfo, which have not been released >10 
years. Hardinfo2 is the reboot that was needed.







OpenPGP_0x42F79A5E0A4D5598.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug#1071528: ITP: hardinfo2 -- Hardinfo2 offers System Information and Benchmark for Linux Systems

[肖盛文]

Hi,

  I had report bug #1070830[1], hardinfo package change upstream repo 
to hardinfo2

also is a better way.

IMHO, hardinfo2 only is the new version of hardinfo, it's not necessary 
to ITP a new
hardinfo2 src package in Debian. The new version has a new binary 
package named hardinfo2

is no problem.


Regard,
atzlinux

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

在 2024/5/20 23:01, Lucas Castro 写道:

Package: wnpp
Severity: wishlist
Owner: Lucas Castro 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: hardinfo2
   Version : 2.1.2
   Upstream Contact: Name 
* URL : https://hardinfo2.org/
* License : GPL-2
   Programming Lang: C
   Description : Hardinfo2 offers System Information and Benchmark for 
Linux Systems

Hardinfo2 is based on hardinfo, which have not been released >10 years. 
Hardinfo2 is the reboot that was needed.

Hardinfo2 offers System Information and Benchmark for Linux Systems. It is able 
to
obtain information from both hardware and basic software. It can benchmark your 
system and compare
to other machines online.

Features include:
- Report generation (in either HTML or plain text)
- Online Benchmarking - compare your machine against other machines

Status
--
- Capabilities: Hardinfo2 currently detects most software and hardware detected 
by the OS.
- Features: Online database for exchanging benchmark results.
- Development: Currently done by contributors, hwspeedy maintains

Hardinfo2 is based on hardinfo, which have not been released >10 years. 
Hardinfo2 is the reboot that was needed.




--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: finally end single-person maintainership

[Luca Boccassi]

On Tue, 21 May 2024 at 02:08, Simon Richter  wrote:
>
> Hi,
>
> On 5/21/24 07:43, Bernd Zeimetz wrote:
>
> > Also its a gitlab instance. There are all kinds of documentation,
> > tutorials, videos and software for/about gitlab, including lots of
> > beginner friendly options. There is a whole ecosystem around gitlab, it
> > does not depend on a few (two?) developers.
>
> The ecosystem, however, does not support our workflows, and adapting it
> to do that is even more effort than maintaining our own tools. We would
> not even save effort in onboarding, because we'd still need to explain
> the Debian specific aspects, only we would now also need to explain
> which parts of the git workflow we can keep and which parts don't work
> for us.

That's a problem of our workflows, which are horrible. The solution is
not to double down on them. Simply due to demographics, the number of
people who can actually stomach them, let alone maintain them, is only
ever going to shrink.

> The workflows of GitHub (more deployment focused) and GitLab (more
> development focused) are already different enough that I have seen
> organizations struggle after making the wrong choice.

Most large organizations and most distributions have additional
tooling on top of git to perform certain tasks, that's really not a
problem nor surprising, because it's still git and everyone
understands it. Going from git push to gbp push when importing new
releases is really not that disruptive.

> git-buildpackage is not a good mapping of packages to git, but the best
> you can do without modifying git itself. Actually using it requires more
> than beginner-level knowledge of git and suspension of any previously
> held convictions that every single commit should be buildable (because
> gbp likes to generate ones that aren't).

Only when importing new releases, so not really an issue. "Every
commit builds" is a good aspiration but it is incredibly rare that it
is 100% the case with no exception ever at any point in the history of
a repo.

> A better approach would not treat Debian metadata as git data. Even the
> most vocal advocate of switching everything to Salsa writes in his MR
> that the changelog should not be touched in a commit, because it creates
> conflicts, and instead a manual step will need to be performed later.
>
> At the very least, GitLab integration would allow me to automate such a
> simple thing as changelog handling in a more comfortable way than
> displaying instructions how to download the conflicting branch into
> local git, resolve the conflicts manually, and force-push the branch to
> solve the problem.

gbp dch --commit --release

Re: finally end single-person maintainership

[Simon Richter]

Hi,

On 5/21/24 07:43, Bernd Zeimetz wrote:


Also its a gitlab instance. There are all kinds of documentation,
tutorials, videos and software for/about gitlab, including lots of
beginner friendly options. There is a whole ecosystem around gitlab, it
does not depend on a few (two?) developers.


The ecosystem, however, does not support our workflows, and adapting it 
to do that is even more effort than maintaining our own tools. We would 
not even save effort in onboarding, because we'd still need to explain 
the Debian specific aspects, only we would now also need to explain 
which parts of the git workflow we can keep and which parts don't work 
for us.


The workflows of GitHub (more deployment focused) and GitLab (more 
development focused) are already different enough that I have seen 
organizations struggle after making the wrong choice.


git-buildpackage is not a good mapping of packages to git, but the best 
you can do without modifying git itself. Actually using it requires more 
than beginner-level knowledge of git and suspension of any previously 
held convictions that every single commit should be buildable (because 
gbp likes to generate ones that aren't).


A better approach would not treat Debian metadata as git data. Even the 
most vocal advocate of switching everything to Salsa writes in his MR 
that the changelog should not be touched in a commit, because it creates 
conflicts, and instead a manual step will need to be performed later.


At the very least, GitLab integration would allow me to automate such a 
simple thing as changelog handling in a more comfortable way than 
displaying instructions how to download the conflicting branch into 
local git, resolve the conflicts manually, and force-push the branch to 
solve the problem.


   Simon

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Thu, 2024-04-11 at 22:52 +, Bill Allombert wrote:
> 
> When a change leads to a RC bug a month or three after having be
> part of a package, fixing the problem falls on the maintainer and not
> on the change author. Even correct changes can trigger latent bugs
> in software.


Yet another reason why using Salsa and its CI *and having autopkg-
tests* is so important - contributors can test their changes before
even asking to merge them. And yes, its up to the 'expert' maintainer
of the package to ensure there are proper tests in place. Because even
that expert is a human only and we all make mistakes.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Wed, 2024-04-10 at 23:16 +0200, Johannes Schauer Marin Rodrigues
wrote:
> Quoting Andreas Tille (2024-04-10 22:44:25)
> > > I do understand the argument that lots of different workflows
> > > adds
> > > friction. But I'm just still using what used to be _the_ standard
> > > one
> > > (insofar as we ever had such a thing). Putting everything in
> > > salsa/git
> > > doesn't standardise workflows in itself. I think Ian/Sean
> > > identified 12
> > > different git-based methods in their dgit review.
> > 
> > I agree that different workflows are not helpful.  We have DEP14[1]
> > ... but we have no efficient processes to
> >   a) accept DEPs
> >   b) dedicate to accepted DEPs
> 
> or teach gbp about DEP14. See this git-buildpackage bug from *six*
> years ago:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829444


DEP14 is a candidate, I can't see that there was any consensus to
accept it. Just because there is a DEP there is no need to implement it
without having any consensus on it.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Tue, 2024-04-09 at 20:51 +0200, Gioele Barabucci wrote:
> 
> Salsa is a forge, i.e. a combination of a Web interface, a git
> server, 
> and a set of integrated features. In comparison to dgit, salsa has,
> like 
> most forges:
> 
> []

Also its a gitlab instance. There are all kinds of documentation,
tutorials, videos and software for/about gitlab, including lots of
beginner friendly options. There is a whole ecosystem around gitlab, it
does not depend on a few (two?) developers.

dgit is an overly complex niche software that should never ever become
a default. We should make it easier for new contributors, not harder.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Mon, 2024-05-20 at 20:47 +, Scott Kitterman wrote:
> > 
> > All these things should make it much more easy for other people or
> > automated tools to send merge requests or keep maintaining a
> > package in
> > case the original maintainer becomes MIA.
> 
> 
> Mandating a specific git layout is a big jump from not requiring a
> VCS at all. 

yes, its a big jump, but we are in 2024 and a modern workflow should be
expected from a modern distribution.

> Do you really think we should remove packages from Debian which don't
> conform to a specific layout (in my mind, that's the implication of
> mandating it)?

no, a grace period is absolutely needed of course. I would start with
rejecting NEW uploads and at some point move to automatic upload by git
tag only.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: About i386 support

[Leandro Cunha]

On Mon, May 20, 2024 at 6:11 PM Andrey Rakhmatullin  wrote:
>
> On Mon, May 20, 2024 at 10:57:58PM +0200, William Bonnet wrote:
> > > which is good news. The end of support for 32 bits will not
> > > affect the lives of almost anyone who has machines purchased after
> > > 2011 and who bought them after that
> >
> > Does this also mean he support for armhf will be dropped ?
> There is no "end of support for 32 bits" yet so no.
>
>
> --
> WBR, wRAR

When you refer to 32 bits you are referring to i386 (see the subject),
they are different architectures.

[1] https://en.wikipedia.org/wiki/I386

-- 
Cheers,
Leandro Cunha

Re: About i386 support

[Andrey Rakhmatullin]

On Mon, May 20, 2024 at 10:57:58PM +0200, William Bonnet wrote:
> > which is good news. The end of support for 32 bits will not
> > affect the lives of almost anyone who has machines purchased after
> > 2011 and who bought them after that
> 
> Does this also mean he support for armhf will be dropped ?
There is no "end of support for 32 bits" yet so no.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: About i386 support

[William Bonnet]

Hi all


On 20/05/2024 22:27, Leandro Cunha wrote:


which is good news. The end of support for 32 bits will not
affect the lives of almost anyone who has machines purchased after
2011 and who bought them after that


Does this also mean he support for armhf will be dropped ?

Cheers
William


OpenPGP_0x8436246AE2D3D15F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: finally end single-person maintainership

[Scott Kitterman]

On May 20, 2024 7:54:46 PM UTC, Bernd Zeimetz  wrote:
>Hi,
>
>On Sun, 2024-04-07 at 16:44 +0200, Andreas Tille wrote:
>> 
>> Do you think that mandating Salsa is a sensible step in this
>> direction?
>
>
>Absolutely.
>
>Also I think requiring a common git layout and the usage of recent
>versions of dh should be required. Using merge requests instead of
>sending patches should be recommended, or at least we could have a
>service that creates and maintains merge requests based on patches
>found in bug reports.
>
>All these things should make it much more easy for other people or
>automated tools to send merge requests or keep maintaining a package in
>case the original maintainer becomes MIA.


Mandating a specific git layout is a big jump from not requiring a VCS at all.  
Do you really think we should remove packages from Debian which don't conform 
to a specific layout (in my mind, that's the implication of mandating it)?

Scott K

Re: About i386 support

[Leandro Cunha]

Hello,

On Mon, May 20, 2024 at 5:15 PM Paul Gevers  wrote:
>
> Hi,
>
> On 20-05-2024 4:50 p.m., Ben Hutchings wrote:
> > There is a tension here between the interests of (a) users that want to
> > run proprietary i386 binaries on 64-bit CPUs, and (b) those who want to
> > keep using 32-bit CPUs.  If i386 is meant for group (a) then the
> > baseline should be raised to include the features that 64-bit CPUs
> > provide, but if it's also for group (b) then this mustn't happen.
>
> The Release Team expects the Debian i386 official port to go to (a).
>
> Paul, wearing his Release Team hat.

LOL, I hope so too...
However, the future stable version will feature RISC-V (at least it's
expected), which is good news. The end of support for 32 bits will not
affect the lives of almost anyone who has machines purchased after
2011 and who bought them after that, which I know was the year I
bought a machine starting to use Debian 1 year later. Another
interesting development that is underway and is inherent to the topic
would be the time_t transition (the 2038 problem).

-- 
Cheers,
Leandro Cunha

Bug#1071540: ITP: lua-vips -- A fast image processing library with low memory needs for Lua

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: Jérémy Lal 
X-Debbugs-Cc: debian-devel@lists.debian.org, The Debian Lua Team 


* Package name: lua-vips
  Version : 1.1.11
  Upstream Contact: John Cupitt 
* URL : https://github.com/libvips/lua-vips
* License : Expat
  Programming Lang: Lua
  Description : A fast image processing library with low memory needs for 
Lua

 This Lua module implements bindings for VIPS using LuaJIT's FFI module.
 .
 VIPS is a fast and efficient image processing system.

Upstream is the same as vips, so it makes sense to package it too.
This software can easily be used in nginx/lua to provide a full-featured
image transformation HTTP service, among other things.
I will maintain it within the Lua Team, and am already planning on using it too.

Re: About i386 support

[Paul Gevers]

Hi,

On 20-05-2024 4:50 p.m., Ben Hutchings wrote:

There is a tension here between the interests of (a) users that want to
run proprietary i386 binaries on 64-bit CPUs, and (b) those who want to
keep using 32-bit CPUs.  If i386 is meant for group (a) then the
baseline should be raised to include the features that 64-bit CPUs
provide, but if it's also for group (b) then this mustn't happen.


The Release Team expects the Debian i386 official port to go to (a).

Paul, wearing his Release Team hat.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Any volunteers for lintian co-maintenance?

[Otto Kekäläinen]

Hi!

> > If I am successful, then lintian can specialize its efforts into issues only
> > visible in packaged artifacts and thereby reduce it scope a bit.
>
> Perfect.  I'd love to have some policy checking at "the right point in
> time".  I'd love to support this but as far as I understand even your
> suggestion does not spare the work of fixing lintian itself.  The problem
> that motivated me to my initial mail to ask for help on lintian was about
> packaged artifacts and we need to keep an eye on this - no matter how nifty
> things we do before.

As somebody who has contributed to a bunch of Debian packaging tooling
(Lintian, Deputy, git-buildpackage, Salsa-CI) I think Niels' approach
makes a lot of sense. Deputy is great for static analysis of Debian
packaging (i.e. are the files in debian/* syntactically and
semantically correct). Lintian could over time remove those checks and
focus only on analysing the build artifacts (as anyway Lintian can be
run only _after_ the build was done). Yes, Lintian needs to continue
to be maintained, but the maintenance work could be slightly less if
Lintian adopts the strategy/architecture of focusing only on
post-build artifact analysis.

Regarding this discussion in general, I get the sense that
participants haven't actually tried Debputy and are not aware of its
capabilities. If you have Podman/Docker you can effortlessly run this
little check to get some experience:

cd my-package
podman run --interactive --tty --rm --volume=$PWD:/tmp/my-package
--workdir=/tmp/my-package debian:sid bash
apt update && apt install -y dh-debputy python3-lsprotocol
debputy lint

Examples of output:

pedantic: File: ./debian/changelog:944:82:944:89: Line exceeds 82 characters
  944:   -
runtime-test-file-uses-supported-python-versions-without-python-all-build-depends
informational: File: ./debian/control:64:19:64:24: Latest
Standards-Version is 4.7.0
 64: Standards-Version: 4.6.2

Re: finally end single-person maintainership

[Bernd Zeimetz]

Hi,

On Sun, 2024-04-07 at 16:44 +0200, Andreas Tille wrote:
> 
> Do you think that mandating Salsa is a sensible step in this
> direction?


Absolutely.

Also I think requiring a common git layout and the usage of recent
versions of dh should be required. Using merge requests instead of
sending patches should be recommended, or at least we could have a
service that creates and maintains merge requests based on patches
found in bug reports.

All these things should make it much more easy for other people or
automated tools to send merge requests or keep maintaining a package in
case the original maintainer becomes MIA.



Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#1071529: ITP: vim-link-vim -- move links out of the way

[Matthias Geiger]

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-devel@lists.debian.org, team+...@tracker.debian.org, 
werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: vim-link-vim
  Version : 1.0.3+git20240514
  Upstream Contact: qadzek
* URL : https://github.com/qadzek/link.vim
* License : MIT
  Programming Lang: vimscript
  Description : move links out of the way

link.vim is a neat vim plugin that allows moving links in markdown,
plaintext files and email to a separate "Links: " section at the end of the
document, thus greatly improving readability.
.
The package will be maintained with the vim team.

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmZLawUVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR11a4QAJH4TSUBGTFgDy5YVXIGDB8ktsTf
nSw50ZOeGRTp+DXt07MMPvl26QypNk0jcJTaw5kT5BigAp5Zz3HfVH7hwdmD6BjG
Xzjm/VnYkfod0VVMpLdAzhDe6oPVVy392oTfsq5Yf5cE/3HDgs++EO+iGqPXniqu
UBuMGwv9xzG4zbqdE6avPkw6S1UwfDo+lc8vxdbR+3psTpCBlwHhVftJMxlCH6FD
uxxB3N3pZCZMES86LcwV1K4IdMaK3eDTtsEYKBRsjWkz1ZUpGAtwRiAAtSM/ejwG
Jc6+Ok3KJglCZxdSGPJZhYqfrSJsC+zIj8GicwbEHn6876JmGwTU3WYMwACTVzaZ
PXOqeOl1mGddPN7onOGpVHEnxFHT3mR6MTfBlIoBOYXBvuDupvkzr95L8GaxLvkl
kcqsJ1LlGzubleKtvn6D7fI/5VnFqYVcuwTMP1DqHFqi5St5CqwPotG/qId1Jp4s
UFpyI/TvdUAF6Nni6so0tNY9qPZva8j6MD3BtTH/n4p+ZbKawR4/u5XfZnpaQ7aZ
KgQh2f4McHflQNuKFxS/pNlslSYMUk1jw+4YZZcENw0g0mMBEL7G+HIYy9Tarob7
o8nFUiLRDQfaYc4bbecs6uKgz84nO2jrUFY8t/YWrhEZLsEn/lewO8yWBCvmaA/M
GkxjHgYyXxzeRAi3
=4kev
-END PGP SIGNATURE-

Re: About i386 support

[defrag mentation]

On Mon, 20 May 2024 00:30:13 +0200, Thomas Goirand  wrote:
> For example, *I* don't care at all about 32 bits arch, and would prefer if 
> these were to be sent to ports.debian.org. I really mean *all* 32 bits arch, 
> including armhf for example.

I agree with you.

No one really needs armel(armv5te) now. Linux kernel has just dropped Marvell's 
armv5te device support. RPI0/1 users want armv6hf instead of armel(armv5te). 
armhf in Debian is armv7hf, and does not support RPI0/1. It supports RPI2.

For armhf, Fedora has dropped it in 37 due to lack of community interest, and 
worse and worse upstream support. armhf is 3GB user process address space, 1GB 
shared kernel address space, and users will find armhf is a bad platform for 
any heavier jobs, such as compiling or emulating things or running heavy server 
or computing programs. Chrome and Chromium-based apps and some other things do 
not support armhf now as well.

armel, armv6hf and armv7hf can be done by embedded distros like Armbian. Debian 
can just move them into Debian ports, not release them as official arches.

For i386, I only use wine32, and do not have any pure 32-bit x86 devices. Pure 
32-bit x86 devices are aging and less energy-saving, and 64-bit first-handed or 
second-handed devices are cheap enough to buy one rather than wasting time to 
maintain i386 support. Old native i386 Linux apps can be supported by an old 
Debian release chroot or container, not by a new release (native boot or 
multiarch or chroot or container or whatever).

I would like to suggest Debian to drop all i386 things excluding wine32, and 
recompile wine32 to 64-bit time_t. And if WineHQ announced 'new wow64' becomes 
default, Debian could drop i386 completely, only leaving multilib and cross 
compiling things in amd64 is enough.

Bug#1071528: ITP: hardinfo2 -- Hardinfo2 offers System Information and Benchmark for Linux Systems

[Lucas Castro]

Package: wnpp
Severity: wishlist
Owner: Lucas Castro 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: hardinfo2
  Version : 2.1.2
  Upstream Contact: Name 
* URL : https://hardinfo2.org/
* License : GPL-2
  Programming Lang: C
  Description : Hardinfo2 offers System Information and Benchmark for Linux 
Systems

Hardinfo2 is based on hardinfo, which have not been released >10 years. 
Hardinfo2 is the reboot that was needed.

Hardinfo2 offers System Information and Benchmark for Linux Systems. It is able 
to
obtain information from both hardware and basic software. It can benchmark your 
system and compare
to other machines online.

Features include:
- Report generation (in either HTML or plain text)
- Online Benchmarking - compare your machine against other machines

Status
--
- Capabilities: Hardinfo2 currently detects most software and hardware detected 
by the OS.
- Features: Online database for exchanging benchmark results.
- Development: Currently done by contributors, hwspeedy maintains

Hardinfo2 is based on hardinfo, which have not been released >10 years. 
Hardinfo2 is the reboot that was needed.

Re: About i386 support

[Ben Hutchings]

On Mon, 2024-05-20 at 13:39 +0200, Ansgar 🙀 wrote:
> Hi,
> 
> On Sun, 2024-05-19 at 10:30 -0500, r...@neoquasar.org wrote:
> > I have an N270 system I can use to contribute, if someone is willing
> > to explain what I need to do to make it useful. 
> > 
> > From: Victor Gamper 
> > Sent: Sunday, May 19, 2024 08:03
> > To: debian-devel@lists.debian.org
> > Subject: Re: About i386 support
> > 
> > I believe I could swap out the processor on my T60,
> > however, I'd both need to have that processor and
> > make sure that it is actually possible. It still would
> > not really make sense on a platform that only supports
> > 3G of physical RAM.
> > 
> > Anyways, if the only reason why i386 cd images are not
> > supported anymore is the lack of contributors,
> > I'd be willing to contribute in that area, if it's possible.
> 
> If you look at https://release.debian.org/testing/arch_qualify.html
> there is at least several things that can be done:
> 
> 1. Add CPU security mitigations to Linux kernel.

With few exceptions, the CPU security issues that have been discovered
in tha past few years are not thought to affect 32-bit-only CPUs. 
(Meltdown did affect some of them but was eventually mitigated on
i386.)  I have raised the possibility of making i386 kernel builds warn
very loudly or refuse to boot on 64-bit-capable hardware, but didn't
try implementing it yet.

[...]
> 3. Look at other arch-specific issues (porter); this can also include
> baseline violations and other issues for real i386 hardware.
[...]

There is a tension here between the interests of (a) users that want to
run proprietary i386 binaries on 64-bit CPUs, and (b) those who want to
keep using 32-bit CPUs.  If i386 is meant for group (a) then the
baseline should be raised to include the features that 64-bit CPUs
provide, but if it's also for group (b) then this mustn't happen.

This also showed up in the 64-bit time_t transition, where the
transition would be desirable for group (b) but would make i386 useless
for group (a).  There was some talk then about creating a new port like
"i386t64" for use by group (b), while i386 would serve group (a) only.
Did anything come of this?

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.



signature.asc
Description: This is a digitally signed message part

Bug#1071522: ITP: paping -- Test network connection between two hosts

[Rony Joao de Sousa]

Package: wnpp
Severity: wishlist
Owner: Rony Joao de Sousa 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: paping
  Version : 1.6.0
  Upstream Contact: Mike Lovell 
* URL : https://github.com/ronyjdesousa/paping
* License : MIT
  Programming Lang: C++
  Description : Test network connection between two hosts

 Paping is an tool designed to monitor the availability of a TCP/IP network
 connection between two points using TCP protocol.
 .
 It offers a straightforward approach to checking if a server is
 reachable and responsive on a specific port. Paping enables real-time
 monitoring of server status, aiding in the prompt detection of
 connectivity issues.
 .
 Paping alike to Ping, but in TCP level, targeting specific ports TCP.
 Both network diagnostic tools used to test the reachability of a host.
 Here are their key similarities:
 .
 Purpose: Both tools are used to check the availability and responsiveness
 of network connections.
 Functionality: They send packets to a specified address and wait for
 a response, measuring the round-trip time.
 Output: Both provide feedback on the success or failure of the packets sent,
 including response times.
 Usage: Both can be used to diagnose network issues and ensure that a host
 is reachable over the network.
 .
 Paping is also an excellent tool for learning TCP/IP. However, this
 program does not support UDP connections and IPv6.

Re: About i386 support

[Ansgar 🙀]

Hi,

On Sun, 2024-05-19 at 10:30 -0500, r...@neoquasar.org wrote:
> I have an N270 system I can use to contribute, if someone is willing
> to explain what I need to do to make it useful. 
> 
> From: Victor Gamper 
> Sent: Sunday, May 19, 2024 08:03
> To: debian-devel@lists.debian.org
> Subject: Re: About i386 support
> 
> I believe I could swap out the processor on my T60,
> however, I'd both need to have that processor and
> make sure that it is actually possible. It still would
> not really make sense on a platform that only supports
> 3G of physical RAM.
> 
> Anyways, if the only reason why i386 cd images are not
> supported anymore is the lack of contributors,
> I'd be willing to contribute in that area, if it's possible.

If you look at https://release.debian.org/testing/arch_qualify.html
there is at least several things that can be done:

1. Add CPU security mitigations to Linux kernel.
2. Address builds reaching address limit. There were ideas to use
foreign-arch (amd64) compilers to do so.
3. Look at other arch-specific issues (porter); this can also include
baseline violations and other issues for real i386 hardware.

It is also possible to work on finding funding and asking someone else
to do this. I've no idea how much that would cost, but let's say a few
10k USD.

Which leads to the problem: most people who want this, seem to want to
continue to use old hardware (T60, N270). However, continuing to
support i386 has likely costs much higher than the replacement cost of
said hardware... Which is probably why nobody really seems sufficiently
motivated to actually invest resources. (Or do you?)

Ansgar

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Bill Allombert]

On Sun, May 19, 2024 at 08:38:58PM -0700, Don Armstrong wrote:
> On Sun, 19 May 2024, Bill Allombert wrote:
> > Also debbugs is a special case:
> > The debbugs Debian package (as opposed to the debbugs software) have never 
> > been
> > really maintained. I am actually one of the very few users of this package
> > and I tried several times to get the maintainers to do a new upload but they
> > were clearly not interested.
> 
> It's more that I'm prioritizing spending my (very) limited Debian time
> on keeping bugs.debian.org and debbugs itself working (and [very slowly]
> developing a new version of Debbugs with a more modern design in the
> hopes that others will contribute.)
> 
> > Ideally debbugs should be made non-native so that some else could
> > maintain the Debian package.
> 
> I'm happy to review patches that get the 2.6 branch of debbugs in shape
> where it can be released into Debian again if someone wants to take that
> effort. 

But precisely, one should not need to wait for a new 'upstream release' to
fix RC bugs that prevent the package to be part of a stable release.
Making it non native would allow that without requiring more of your time.

> I've just assumed that anyone using that package was running
> unstable or running debbugs out of git.

Perforce, since the package has not been in stable or testing for years.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1071507: ITP: sensor-state-data -- Models for storing and converting Sensor Data state

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: sensor-state-data
  Version : 2.18.0
  Upstream Author : J. Nick Koston 
* URL : https://github.com/bluetooth-devices/sensor-state-data
* License : Apache-2.0
  Programming Lang: Python
  Description : Models for storing and converting Sensor Data state

  Provides models for storing and converting sensor data state in Python
  applications. This package facilitates handling sensor data, including
  storage, conversion, and manipulation, making it easier to work with
  sensor data in a structured and consistent manner.
  .
  The package includes various models and utilities to manage sensor data
  efficiently, ensuring compatibility and ease of use across different
  projects and applications. It supports integration with other tools and
  libraries for a seamless experience.

I plan to maintain this package as part of the Python team.

Bug#1071503: ITP: python-srptools -- Tools to implement Secure Remote Password (SRP) authentication

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-srptools
  Version : 1.0.1
  Upstream Author : Igor `idle sign` Starikov 
* URL : https://github.com/idlesign/srptools
* License : BSD-3-clause
  Programming Lang: Python
  Description : Tools to implement Secure Remote Password (SRP) 
authentication

  Provides tools to implement the Secure Remote Password (SRP) protocol for
  secure password-based authentication and key exchange in Python. SRP is a
  password-authenticated key agreement protocol (PAKE) that enhances security
  by allowing for secure password-based authentication and key exchange.
  .
  This package includes both a command-line interface (CLI) and an API for
  incorporating SRP into your Python applications.

I plan to maintain this package as part of the Python team.

Bug#1071500: ITP: unicode-rbnf -- Rule-based number formatting using Unicode CLDR data

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: unicode-rbnf
  Version : 1.1.0
  Upstream Author : Michael Hansen 
* URL : https://github.com/rhasspy/unicode-rbnf
* License : MIT
  Programming Lang: Python
  Description : Rule-based number formatting using Unicode CLDR data

  Provides a pure Python implementation of rule-based number formatting (RBNF)
  using the Unicode Common Locale Data Repository (CLDR). This library allows
  for the spelling out of numbers for a wide range of locales, supporting
  various rulesets depending on the locale.
  .
  The library supports literal text, quotient and remainder substitution,
  optional substitution, rule substitution, and special rules for negative
  numbers, improper fractions, NaN, and infinity.
  .
  Example usage:
  .
   >>> from unicode_rbnf import RbnfEngine
   >>> engine = RbnfEngine.for_language("en")
   >>> engine.format_number(1234)
   'one thousand two hundred thirty-four'
  .
   >>> from unicode_rbnf import RbnfEngine, RulesetName
   >>> engine = RbnfEngine.for_language("en")
   >>> engine.format_number(1999, RulesetName.YEAR)
   'nineteen ninety-nine'
   >>> engine.format_number(11, RulesetName.ORDINAL)
   'eleventh'
  .
  This package is particularly useful for applications requiring accurate and
  locale-aware number spelling, such as text-to-speech systems, financial
  applications, and other linguistic tools.

I plan to maintain this package as part of the Python team.

gzip --rsyncable (was: Re: De-vendoring gnulib in Debian packages)

[Simon Josefsson]

"Theodore Ts'o"  writes:

> On Sun, May 12, 2024 at 04:27:06PM +0200, Simon Josefsson wrote:
>> Going into detail, you use 'gzip -9n' but I use git-archive defaults
>> which is the same as -n aka --no-name.  I agree adding -9 aka --best is
>> an improvement.  Gnulib's maint.mk also add --rsyncable, would you agree
>> that this is also an improvement?
>
> I'm not convinced --rsyncable is an improvement.  It makes the
> compressed object slightly larger, and in exchange, if the compressed
> object changes slightly, it's possible that when you rsync the changed
> file, it might be more efficient.  But in the case of PGP signed
> release tarballs, the file is constant; it's never going to change,
> and even if there are slight changes between say, e2fsprogs v1.47.0
> and e2fsprogs v1.47.1, in practice, this is not something --rsyncable
> can take advantage of, unless you manually copy
> e2fsprogs-v1.47.0.tar.gz to e2fsprogs-v1.47.1.tar.bz, and then rsync
> e2fsprogs-v1.471.tar.g and I don't think anyone is doing this,
> either automatically or manually.
>
> That being said, --rsyncable is mostly harmless, so I don't have
> strong feelings about changing it to add or remove in someone's
> release workflow.

Your example had me convinced, and I thought some more about why we
really should keep using it as it consumes a small percentage more CPU
and disk space.  I have realized that another common operation is
storing and transfering _several_ different releases of e2fsprogs.  I
would suspect that most releases of software is fairly similar to the
previous release when uncompressed.  With gzip --rsyncable, the tarballs
should then be mostly similar.  Without --rsyncable, they will largely
be different if I understand correctly.  This affects dedup-able storage
and transfer methods, and some anecdotical evidence suggests this
improvement is significant - going from 215GB to 176GB vs 13GB:

https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/429

Maybe someone could do some experiment to see if there is substance to
this argument, its not clear to me that the example is comparable.
Storing/transferring several releases for the same software could add
significant savings for larger set of archives.

As the downside seems fairly small, and the potential upside may be
significant, I will use and recommend --rsyncable for git-archive
release tarballs:

   git archive --format=tar --prefix=$PACKAGE-$VERSION/ HEAD | \
  env GZIP= gzip --no-name --best --rsyncable \
  > $PACKAGE-$VERSION-src.tar.gz

/Simon


signature.asc
Description: PGP signature

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Otto Kekäläinen]

> > Ideally debbugs should be made non-native so that some else could
> > maintain the Debian package.
>
> I'm happy to review patches that get the 2.6 branch of debbugs in shape
> where it can be released into Debian again if someone wants to take that
> effort. I've just assumed that anyone using that package was running
> unstable or running debbugs out of git.

I did not notice the release_2.6 branch before. What is the intent
with that branch? Do you want people to submit patches targeting
'master' or 'release_2.6'? How often do you plan to merge it to or
from 'master'?

The 'master' branch is still the default branch. The
https://salsa.debian.org/debbugs-team/debbugs/-/blob/master/README.md
does not mention anything about release_2.6. Should it?

I am a big fan of READMEs and recommend using them to convey guidance
to contributors (assuming you want to have contributors).

Re: Suggestions about i386 support

[Marc Haber]

On Sun, 19 May 2024 20:19:12 +0200, Ben Hutchings
 wrote:
>The plan is to keep i386 as a partial architecture that can be used as
>a "foreign architecture" on systems where amd64 is the main
>architecture.

Many people using ancient hardware such as a T60 thinkpad say that's
not enough for them. I can partly understand both sides though.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402