Re: Documenting packaging workflows

[Russ Allbery]

Johannes Schauer Marin Rodrigues  writes:

> I would be *very* interested in more in-depth write-ups of the workflows
> other DDs prefer to use, how they use them and what they think makes
> them better than the alternatives.

> Personally, I start packaging something without git, once I'm satisfied
> I use "gbp import-dsc" to create a packaging git with pristine-tar (and
> that will *not* have DEP14 branches and it will use "master" instead of
> "main") and then I push that to salsa and do more fixes until the
> pipeline succeeds and lintian is happy. My patches are managed using
> quilt in d/patches and upstream git is not part of my packaging git. I
> upload using "dgit --quilt=gbp push-source".

> Would another workflow make me more happy? Probably! But how would I get
> to know them or get convinced that they are better? Maybe I'm missing
> out on existing write-ups or video recordings which explain how others
> do their packaging and why it is superior?

One of the lesser-known things found in the dgit package is a set of man
pages describing several packaging workflows.  These certainly aren't
exhaustive of the packaging workflows that people use (for one thing, they
are designed to explain how to use dgit in each workflow, and thus of
course assume that you want to do that), but they're both succinct and
fairly thorough and I found reading them very helpful.  dgit(1) has a list
at the start.

dgit-maint-debrebase(7) is the workflow that I now use, pretty much
exactly as described.  The primary thing that I like about it is that I
never have to deal with the externalized patches or with quilt (I used
quilt for years, and I have developed a real dislike for it and its odd
quirks -- I would rather only deal with Git's odd quirks), and I can use a
git-rebase-like command in much the same way that I use it routinely for
feature branches when doing upstream development.  Then some Git magic
happens behind the scenes to make this safe, and while I don't understand
the details, it has always worked fine, so I don't really care how it
works.  :)

I like having a Git history from as early in the process as possible and I
want the upstream Git history to refer to while I work on packaging (and
want to be able to cherry-pick upstream commits), so I generally start
with a tagged release from the upstream Git repository, create a branch
based on it, and start writing and committing debian/* files.

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

Re: Documenting packaging workflows (was: finally end single-person maintainership)

[PICCA Frederic-Emmanuel]

My standard workflow

I use gbp and dgit

gbp import-orig --pristine-tar --uscan
gbp dch
lintian-brush
dgit --gbp sbuild  (build and autopkgtest)
...work until it is ok on my computer
gbp dch
... hand edit the changelog
gbp push
git push (to push the UNRELEASE master branch)
... wait for salsa result if everythings is ok
... if not work and push commits to salsa
... then relase with
dch -r
dgit --gbp build-source
dgit --gbp push-source
gbp push


I like the way dgit help for the upload.

Cheers

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

On Wed, May 22, 2024 at 12:32:32AM +0200, Salvo Tomaselli wrote:
> And what's the advantage? When an nmu happens the person doing it normally 
> doesn't bother to push to salsa anyway. 
Yes, because it's unfortunately too expensive to:
- make sure the repo exists and is uptodate
- somehow find out what workflow does the repo imply
- if it's an unfamiliar one then somehow learn it
- check if there are no commits on top of the previous upload and if there
  are any then how to merge them with the NMU changes
- check that your commit builds correctly
at least when doing more than one NMU per week or whatever.
The nmudiff(1) interface is standardized, one command does everything, you
are still required to use it, and you need to remember that MRs don't give
notifications so you have an additional reason to use it, and importing a
nmudiff should be easy for the maintainer.

> At most I get a patch in the 
> bugreport, or I have to diff the packages and import the diff.
Sending the nmudiff to the bugreport is mandatory per the devref NMU
procedure (though of course that procedure itself is not a policy and not
everyone follows it).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andreas Tille]

Hi Stefano,

Am Tue, May 21, 2024 at 02:36:47PM + schrieb Stefano Rivera:
> Hi Philip (2024.05.21_10:05:59_+)
> > Attempts at top-down imposition of new methods on Debian strike me as
> > being unlikely to induce joy in anyone involved.
> 
> Yeah, that doesn't fly in community projects like Debian at all.

ACK.
 
> However, there is a gap between getting a DEP approved and getting the
> rest of the project to fully embrace it. That's something that takes
> some leadership in the project. DPLs are in a great position to help
> drive these changes forward.

I confirm I see myself in the "help to get something happening"
position.  I'm fully aware that we can't push anything top-down.  I see
a big step forward in permitting some progress in the first place since
I assume we have quite some volunteers who would implement this progress
which is just not permitted by some rules we have.
 
(My current challenge is to even find out what is broken first as
I'm currently learning in the lintian case.)

Kind regards
   Andreas. 

-- 
https://fam-tille.de

Re: finally end single-person maintainership

[Andreas Tille]

Am Wed, May 22, 2024 at 12:32:32AM +0200 schrieb Salvo Tomaselli:
> 
> And what's the advantage? When an nmu happens the person doing it normally 
> doesn't bother to push to salsa anyway. At most I get a patch in the 
> bugreport, or I have to diff the packages and import the diff.

IMHO this is a hen-egg-problem: If NMUer could expect packages beeing on
Salsa we could require the NMUer to add at least a MR.  I personally
would prefer permissions to push even to the default branch and tag
accordingly.  The current situation of not having some default VCS at
some default place makes injecting NMUs into the VCS impossible and it
does not help to blame NMUers about this.

Kind regards
Andreas.

-- 
https://fam-tille.de

Documenting packaging workflows (was: finally end single-person maintainership)

[Johannes Schauer Marin Rodrigues]

Quoting Luca Boccassi (2024-05-22 01:45:54)
> On Wed, 22 May 2024 at 00:40, Russ Allbery  wrote:
> > For what it's worth, what I do for the packages for which I'm also
> > upstream is that I just add Salsa as another remote and, after I upload
> > a new version of the Debian package, I push to Salsa as well (yes,
> > including all the upstream branches; why not, the Debian branches are
> > based on that anyway, so it's not much more space).  One of these days
> > I'll get CI set up properly, and then it will be worthwhile to push to
> > Salsa *before* I upload the package and let it do some additional
> > checking.
> >
> > It's still an additional step, and I still sometimes forget to do it, but
> > after some one-time setup, it's a fairly trivial amount of work.
> >
> > It's more work to accept a merge request on Salsa and update the
> > repositories appropriately, since there are two repositories in play, but
> > in that case I'm getting a contribution out of it that I might not have
> > gotten otherwise, so to me that seems worth it.
> >
> > I used to try to keep the debian directory in a separate repository or try
> > to keep the Debian Git branches in a separate repository, and all of that
> > was just annoying and tedious and didn't feel like it accomplished much.
> > Just pushing the same branches everywhere is easy and seems to accomplish
> > the same thing.
> 
> Yeah I am doing the same, and gradually switching all my packages that
> used to have a separate upstream/downstream history to a single merged
> tree. This can be done post-facto with some one-time git rocket
> surgery, doesn't have to be the case from day one. It's a huge
> improvement, and with gpp patch-queue I can just cherry-pick upstream
> commits directly, with no hassle whatsoever. It works really nicely,
> and gbp supports it just fine as a workflow, even while still checking
> in upstream release tarballs in pristine-tar.

I would be *very* interested in more in-depth write-ups of the workflows other
DDs prefer to use, how they use them and what they think makes them better than
the alternatives.

Personally, I start packaging something without git, once I'm satisfied I use
"gbp import-dsc" to create a packaging git with pristine-tar (and that will
*not* have DEP14 branches and it will use "master" instead of "main") and then
I push that to salsa and do more fixes until the pipeline succeeds and lintian
is happy. My patches are managed using quilt in d/patches and upstream git is
not part of my packaging git. I upload using "dgit --quilt=gbp push-source".

Would another workflow make me more happy? Probably! But how would I get to
know them or get convinced that they are better? Maybe I'm missing out on
existing write-ups or video recordings which explain how others do their
packaging and why it is superior?

Any hints or future debconf workshop invitations welcome. :)

Thanks!

cheers, josch

signature.asc
Description: signature

Re: finally end single-person maintainership

[Johannes Schauer Marin Rodrigues]

Quoting Bernd Zeimetz (2024-05-21 00:54:07)
> 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.

the current gbp defaults were also implemented without any consensus on them,
so in that regard, embracing DEP14 would not make the situation worse.

What is improved by DEP14 is that in contrast to the current gbp defaults, it
is backed up by a write-up of advice, best-practices and recommendations. We
should have more of these write-ups for the things we do. This would also make
it easier for new contributors to get into Debian.

Thanks!

cheers, josch

signature.asc
Description: signature

Re: finally end single-person maintainership

[Luca Boccassi]

On Wed, 22 May 2024 at 00:40, Russ Allbery  wrote:
>
> Salvo Tomaselli  writes:
>
> > If the debian/ directory is on salsa, but the rest of the project is
> > somewhere else, then this no longer works, I have to tag in 2 different
> > places, I have 2 different repositories to push to and so on.
>
> For what it's worth, what I do for the packages for which I'm also
> upstream is that I just add Salsa as another remote and, after I upload
> a new version of the Debian package, I push to Salsa as well (yes,
> including all the upstream branches; why not, the Debian branches are
> based on that anyway, so it's not much more space).  One of these days
> I'll get CI set up properly, and then it will be worthwhile to push to
> Salsa *before* I upload the package and let it do some additional
> checking.
>
> It's still an additional step, and I still sometimes forget to do it, but
> after some one-time setup, it's a fairly trivial amount of work.
>
> It's more work to accept a merge request on Salsa and update the
> repositories appropriately, since there are two repositories in play, but
> in that case I'm getting a contribution out of it that I might not have
> gotten otherwise, so to me that seems worth it.
>
> I used to try to keep the debian directory in a separate repository or try
> to keep the Debian Git branches in a separate repository, and all of that
> was just annoying and tedious and didn't feel like it accomplished much.
> Just pushing the same branches everywhere is easy and seems to accomplish
> the same thing.

Yeah I am doing the same, and gradually switching all my packages that
used to have a separate upstream/downstream history to a single merged
tree. This can be done post-facto with some one-time git rocket
surgery, doesn't have to be the case from day one. It's a huge
improvement, and with gpp patch-queue I can just cherry-pick upstream
commits directly, with no hassle whatsoever. It works really nicely,
and gbp supports it just fine as a workflow, even while still checking
in upstream release tarballs in pristine-tar.

Re: finally end single-person maintainership

[Russ Allbery]

Salvo Tomaselli  writes:

> If the debian/ directory is on salsa, but the rest of the project is
> somewhere else, then this no longer works, I have to tag in 2 different
> places, I have 2 different repositories to push to and so on.

For what it's worth, what I do for the packages for which I'm also
upstream is that I just add Salsa as another remote and, after I upload
a new version of the Debian package, I push to Salsa as well (yes,
including all the upstream branches; why not, the Debian branches are
based on that anyway, so it's not much more space).  One of these days
I'll get CI set up properly, and then it will be worthwhile to push to
Salsa *before* I upload the package and let it do some additional
checking.

It's still an additional step, and I still sometimes forget to do it, but
after some one-time setup, it's a fairly trivial amount of work.

It's more work to accept a merge request on Salsa and update the
repositories appropriately, since there are two repositories in play, but
in that case I'm getting a contribution out of it that I might not have
gotten otherwise, so to me that seems worth it.

I used to try to keep the debian directory in a separate repository or try
to keep the Debian Git branches in a separate repository, and all of that
was just annoying and tedious and didn't feel like it accomplished much.
Just pushing the same branches everywhere is easy and seems to accomplish
the same thing.

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

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

[Bernd Zeimetz]

On Tue, 2024-05-21 at 09:11 -0600, Sam Hartman wrote:
> > > > > > "Otto" == Otto Kekäläinen  writes:
>     Otto> Would you be kind and try to understand the opposing
> viewpoint
>     Otto> by trying it for one day?
> 
>     Otto> You could go to
>     Otto>
> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19
>     Otto> and conduct a code review?
> 
> I have not done a code review  of that particular patch on salsa.
> I have done code reviews on salsa, many other gitlabs, and github.
> I find doing a code review in a web page far more frustrating than in
> email.

There are external paid integrations for gitlab which provide the
feature to send emails with full diffs for projects, so there should be
a way to add this feature to the Debian gitlab. I would guess by using
the API.
You can comment on merge requests by email already and you should even
be able to create a new one by mail (that feature exists in gitlab, no
idea if its enabled on salsa and I've never tried it anywhere else).

So I think if this is a feature more people are missing, find them and
spend some time together on creating an external service for salsa that
provides it would be well spent time.



-- 
 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-05-21 at 12:05 +0200, Philip Hands wrote:
> 
> For anyone with an opinion, I'd suggest that you should try to make
> sure
> that DEP-14 reflects your opinion, and then work on getting people to
> adopt the use of DEP-14 and/or get DEP-14 accepted.
> 

To be honest: in my opinion the whole DEP process is flawed. I doubt
that even the first DEP that created DEPs was had enough consent to be
accepted in general. It did just not bother enough people to be against
it and it made some others happy, so it was accepted to exist.



With the future more and more being container and cloud driven, I would
indeed rather see a Debian that is completely maintained in one
location, with as much CI and testing as possible. Keeping everything
reproducible and maybe - in the future - having a rolling release,
which requires these things.
Even if that means that we loose packages and developers. Which would
be sad, but I think healthy for a long term future of Debian.

I would rather see a small but very stable base distribution, with the
option to add features on top. Which do not necessarily need to be
maintained at the same place as Debian, but could use Debian's
infrastructure as its done now. Each "feature" could have its own
release cycle as it fits. Sury's PHP packaging would be a prime example
for that. We run thousands of PHP driven websites and rarely anyone
wants to use what Debian ships as stable (or even from a still
supported oldstable).


The radical way would be to GR this into place with a *long* grace
period. Risky, but better than having a big slow distribution nobody
needs anymore at some point.


-- 
 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-05-21 at 15:50 +0200, Salvo Tomaselli wrote:
> > Do you think that mandating Salsa is a sensible step in this
> > direction?
> 
> No. It would increase my workload for all the stuff where I am also
> upstream.

Could you explain that? I do similar things (just that not everything
of it is published for $reasons), and I can't see how its increasing my
workload as git and CIs are doing these things for me.

So I'm always curious on why workloads increase just by maintining a
package on salsa.


Thanks,

Bernd

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

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

[Otto Kekäläinen]

Hi!

On Sun, 19 May 2024 at 20:48, 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.)

Everyone else has very limited time to contribute to Debian as well.
Therefore we all need to think about what is the most efficient
workflow.

Perhaps you could consider how you can be a force multiplier and scale
your work? You could for example add some of the recent contributors as
developers or maintainers at
https://salsa.debian.org/groups/debbugs-team/-/group_members so they
can review/merge/push code, and you could review all submissions at
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests and
grow those contributors into co-maintainers instead of just ignoring
them?

Perhaps you can also consider optimizing your git workflows? For
example in the case of
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 you
could have simply pressed "Merge" and everything would be good. Now
you decided to not use any of the support Salsa/Salsa-CI provides, you
did extra work to cherry-pick some commits (but not all), added your
extra commit to break the build and now there is new follow-up work to
be done for lapses that could have been easily avoided if Salsa-CI was
enabled.. (I did submit MR!20 though, you can just merge it)

I started this thread "Salsa - best thing in Debian in recent years?"
by asking people who resist Salsa to at least try using it for a while
before criticizing it so much.

What happened in this episode is a case in point. You sit in a "local
optima" of your current workflow and are not willing to invest a bit
extra effort to get to a place where Salsa+Salsa-CI can benefit and
decrease your extra work burden. Now both you and me ended up having
to do extra work that could easily have been avoided..

Personally I like Salsa a lot, and collaboration with maintainers who
embrace Salsa is a breeze, and I feel that my limited Debian time is
relatively productive. That is all thanks to Salsa. I wish those who
are not yet using it would give it a sincere try.

Re: Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Guilherme Puida Moreira]

On Tue, May 21, 2024 at 06:13:21PM +0200, Andrej Shadura wrote:
> In fact, having checked the source code, it’s one way only, and after
> all it’s also someone else’s quick hack. Maybe someone should write
> a robust tool to support all formats and directions and package *that*
> for Debian? :)

I think dasel might be what you want :^)

Select, put and delete data from JSON, TOML, YAML, XML and CSV files
with a single tool. Supports conversion between formats and can be used
as a Go package.

https://github.com/tomwright/dasel
https://tracker.debian.org/pkg/dasel

--puida

Re: finally end single-person maintainership

[Russ Allbery]

Stefano Rivera  writes:

> On the other hand, dgit is only useful if you have a certain view of the
> world, that hasn't aligned with how I've done Debian packaging. I mean,
> an entirely git-centric view where you let go of trying to maintain your
> patch stack.

dgit has no problems with you maintaining your patch stack, at least as I
understand that statement.  I personally use the dgit-maint-debrebase(7)
workflow, which is a fancy way of maintaining your patch stack using an
equivalent of git rebase, since I love git rebase and use it all the time.
But I used the dgit-maint-gbp(7) workflow, which is basically just the
normal git-buildpackage workflow, for years and still use it for some of
my packages and it works fine.

Maybe you mean something different by this than I think you meant.

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

Re: Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Andrej Shadura]

Hi again,

On Tue, 21 May 2024, at 17:59, Andrej Shadura wrote:
> On Tue, 21 May 2024, at 17:17, Facundo Gaich wrote:
>> Well I ended packaging this, it's waiting in debcargo-conf at
>> https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/653
> 
> If the Rust impl of toml2json works better than one written in Python 
> (reserialize), I’m more than happy that you take over the binary package. I’m 
> almost certain it does, given that the Python package is basically someone’s 
> script I packaged and patched over and over again.

In fact, having checked the source code, it’s one way only, and after all it’s 
also someone else’s quick hack. Maybe someone should write a robust tool to 
support all formats and directions and package *that* for Debian? :)

-- 
Cheers,
  Andrej

Re: About i386 support

[Samuel Thibault]

Hello,

Tomas Pospisek, le mar. 21 mai 2024 17:22:47 +0200, a ecrit:
> > > Quoting Victor Gamper (2024-05-17 21:58:58)
> > > For i386 there is a severe lack of person-power. Do you want to start
> > > contributing your free-time for several years to come to d-i and
> > > other areas
> > > which are needed to keep i386 more alive for longer?
> 
> > On 18.05.24 03:15, r...@neoquasar.org wrote:
> >> That depends. What would be required of such a person? I also have
> >> several i386-class machines that run Debian (though only one that can
> >> run Debian 12).
> 
> On 18.05.24 15:16, Maite Gamper wrote:
> 
> > Whilst I can't for sure say how much free time I'll have, I'd like
> > to try and contribute. How would you get started with that?
> 
> There's somewhere a page that is showing how much of the archive is built by
> architecture. A search engine should help you finding that page. Pick the
> package that is furthest down the stack of package dependencies that is not
> building on i386.

It's probably not that easy to find.

The page I know about that would suit best would be the Build-Attempted
and Failed sections of:

https://buildd.debian.org/status/architecture.php?a=i386&suite=sid

> Find out why. Fix the bug. Check if there's a bug report
> about the problem. Send a patch. If the maintainer doesn't have time then
> become a Debian Maintainer [or] Developer yourself, consult with the
> package's maintainers and upload fixed packages.

Yup

Samuel

Re: Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Andrej Shadura]

Hi,

On Tue, 21 May 2024, at 17:17, Facundo Gaich wrote:
> On Thu, Feb 22, 2024 at 1:39 PM Jonas Smedegaard  wrote:
>> Quoting Facundo Gaich (2024-02-22 17:12:22)
>> > I can work on packaging this if you're still interested, I'd need a 
>> > sponsor.
>> > 
>> > I've already done some preliminary work on this, in particular I renamed
>> > the bin to "rust-toml2json" but maybe you've got a better idea?
>> 
>> If the command-line tool does somewhat the same as the existing one, I
>> suggest to rename it with the deviating part as the end instead, so that
>> users TAB-completing would easier notice the alternative:
>> toml2json-rust. 
> 
> Well I ended packaging this, it's waiting in debcargo-conf at
> https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/653

If the Rust impl of toml2json works better than one written in Python 
(reserialize), I’m more than happy that you take over the binary package. I’m 
almost certain it does, given that the Python package is basically someone’s 
script I packaged and patched over and over again.

-- 
Cheers,
  Andrej

Re: About i386 support

[Tomas Pospisek]

Hi Maite, hi Rhys,


don't top-post. That breaks the flow of the arguments being argued about.


*From:* Johannes Schauer Marin Rodrigues 
*Sent:* Friday, May 17, 2024 15:48
*To:* Victor Gamper; debian-devel@lists.debian.org
*Subject:* Re: About i386 support

Quoting Victor Gamper (2024-05-17 21:58:58)
> Is there a reason to do this? If so, what would be required to keep 
the i386

> version, seeing as it still is important and used?

anything can be done if there are enough contributors who care.

For i386 there is a severe lack of person-power. Do you want to start
contributing your free-time for several years to come to d-i and other 
areas

which are needed to keep i386 more alive for longer?


> On 18.05.24 03:15, r...@neoquasar.org wrote:
>> That depends. What would be required of such a person? I also have
>> several i386-class machines that run Debian (though only one that can
>> run Debian 12).

On 18.05.24 15:16, Maite Gamper wrote:

> Whilst I can't for sure say how much free time I'll have, I'd like
> to try and contribute. How would you get started with that?

There's somewhere a page that is showing how much of the archive is 
built by architecture. A search engine should help you finding that 
page. Pick the package that is furthest down the stack of package 
dependencies that is not building on i386. Find out why. Fix the bug. 
Check if there's a bug report about the problem. Send a patch. If the 
maintainer doesn't have time then become a Debian Maintainer oder 
Developer yourself consult with the package's maintainers and upload 
fixed packages.

*t

Bug#1071583: ITP: bluetooth-sensor-state-data -- Models for storing and converting Bluetooth Sensor State 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: bluetooth-sensor-state-data
  Version : 1.6.2
  Upstream Author : J. Nick Koston 
* URL : 
https://github.com/bluetooth-devices/bluetooth-sensor-state-data
* License : Apache-2.0
  Programming Lang: Python
  Description : Models for storing and converting Bluetooth Sensor State 
Data

  This library is designed to facilitate the handling of Bluetooth sensor data
  by offering standardized models that can be easily integrated into various
  applications.
  .
  Key features include:
   * Storage models for Bluetooth sensor state data.
   * Conversion tools to interpret and transform sensor data.
   * Support for various Bluetooth sensor types.
  .
  This package is particularly useful for developers working on applications
  that need to process and manage data from Bluetooth sensors efficiently. It is
  built with ease of use and integration in mind, making it a valuable tool for
  handling Bluetooth sensor data in Python projects.

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

Re: Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Facundo Gaich]

Control: retitle -1 ITP: rust-toml2json -- A very small CLI for converting
TOML to JSON
Control: owner -1 !

Well I ended packaging this, it's waiting in debcargo-conf at
https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/653

Best,
Facundo

On Thu, Feb 22, 2024 at 1:39 PM Jonas Smedegaard  wrote:

> Quoting Facundo Gaich (2024-02-22 17:12:22)
> > I can work on packaging this if you're still interested, I'd need a
> sponsor.
> >
> > I've already done some preliminary work on this, in particular I renamed
> > the bin to "rust-toml2json" but maybe you've got a better idea?
>
> If the command-line tool does somewhat the same as the existing one, I
> suggest to rename it with the deviating part as the end instead, so that
> users TAB-completing would easier notice the alternative:
> toml2json-rust.
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>  * Sponsorship: https://ko-fi.com/drjones
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

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

[Sam Hartman]

> "Otto" == Otto Kekäläinen  writes:
Otto> Would you be kind and try to understand the opposing viewpoint
Otto> by trying it for one day?

Otto> You could go to
Otto> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19
Otto> and conduct a code review?

I have not done a code review  of that particular patch on salsa.
I have done code reviews on salsa, many other gitlabs, and github.
I find doing a code review in a web page far more frustrating than in
email.
I appreciate other people have different experience.
Some of my experience but not all is  accessibility related.

I do find that   trying to put everyone into one user interface--whether
it is github or gitlab or whatever--means some people are going to be
left out.
Interfaces like email mean that people can develop their own tooling.
And for those who do and find tooling they really like that's superior
to a common UI like gitlab for *those people*.
But it's going to be inferior for people who do not spend significant
time on tooling; for those people a common web ui is going to be
superior.

And you can say that I can use my own tooling with gitlab.
That's sort of true.  But then you or people like you will get
frustrated  that I don't interact with your per-commit-line comments
entered in the website, or go to the website to resolve comments or
whatever.
And you'll say that if I just tried the website I'd like it.
And that won't be true, because I have, I do use it in my day job, and I
don't really like it that much.

Even so, I think it is enough better that Debian should move in that
direction.

But Otto, I would encourage you to have more compassion for people who
work with the world differently than you.
In this thread, and in the krb5 merge request we are discussing, you
really do seem to be jumping to an assumption that everyone approaches
code the same way.
And you don't appear to be taking the time to understand or value how
the people you are interacting with may deal with the world differently.

Rather than simply asking people  to try out your way, I'd encourage you
to ask me and others how they deal with code and what they like about
their work flow.
I'm not going to ask you to try it out, because it probably won't work
for you.
You've found something you  think is great.
But I am going to ask you to ask and listen.

I do think we should fall in on the salsa way.  I think it will
generally be better overall.
I do think some of us will suffer as a result.

But there appears to be an assumption here that if we just all tried
this new thing it would be great.
I would appreciate compassion for our differences and for how that's
just not true.
There will be trade offs.

--Sam

Re: finally end single-person maintainership

[Stefano Rivera]

Hi Philip (2024.05.21_10:05:59_+)
> Attempts at top-down imposition of new methods on Debian strike me as
> being unlikely to induce joy in anyone involved.

Yeah, that doesn't fly in community projects like Debian at all.

However, there is a gap between getting a DEP approved and getting the
rest of the project to fully embrace it. That's something that takes
some leadership in the project. DPLs are in a great position to help
drive these changes forward.

> I suspect that there's a decent chunk of developers who generally just
> follow the status quo of every package they work on, without fuss.

Yeah, probably most.

> I rather like dgit for reducing the extent I have to think about this
> sort of thing, but I note that at least one person in this thread seems
> vexed by it, so we cannot even agree on the merits of that, apparently.

On the other hand, dgit is only useful if you have a certain view of the
world, that hasn't aligned with how I've done Debian packaging. I mean,
an entirely git-centric view where you let go of trying to maintain your
patch stack. So, I've only very briefly played with it. I imagine many
in the project have similarly little experience using it.

The tricky thing with tools like this is that you need to invest a lot
of time using the tool to really get a feel for what it's good / bad at.
You probably need to use it to maintain a complex package, for a while.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: Any volunteers for lintian co-maintenance?

[Niels Thykier]

PICCA Frederic-Emmanuel:

I tried it on one of my package silx

warning: File: ./debian/tests/control:22:14:22:19: It is possible that the value is a 
typo of "i386". [Correctable via --auto-fix]
 22: Architecture: !i386

It seems wrong to me, the test control file allow !i386

Cheers

Frederic



Thanks for reporting this issue.

I have pushed a fixed for this to main.

I hope you will report any other issues you might discover. Though 
please consider using the BTS or salsa for future findings. :)


Best regards,
Niels

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

[Luca Boccassi]

On Tue, 21 May 2024 at 14:13, Andrey Rakhmatullin  wrote:
>
> On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote:
> > Hi,
> >
> > On 5/21/24 15:54, Andrey Rakhmatullin wrote:
> >
> > > > 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.
> >
> > All of these things are *also* explicit features. We need a way to unpublish
> > things, and mirrors only want to keep a shallow subset.
> We don't have a way to unpublish things, and force pushes I meant are
> uploading things without including all previous changes, like all those
> NMUs silently not included in the next maintainer uploads.
> But, sure, some of the problems we have are explicitly features.
>
> > Representing the Debian archive in git would probably look like a massive
> > amount of submodules, because that's the only way to represent state across
> > multiple projects without extending it
> Sorry? I don't understand what you would use submodules for. Unless you
> meant literally mapping archive-as-VCS to a single literal VCS repo?

Yeah, I don't understand that either. It seems there is some
misunderstanding, the suggestion to use Salsa doesn't mean that the
current ftp servers are retired. It just means that Salsa is used for
sources, like it is already used in ~90% of the packages today as per
trends.debian.net. Now, whether someone wants to make tarballs and ftp
uploads happen transparently behind the curtain in a salsa-ci job or
something like that is really orthogonal to the idea that sources need
to be stored in git.

Re: Any volunteers for lintian co-maintenance?

[Niels Thykier]

Andreas Tille:

Hi Niels,

at first sorry for my late answer.

At Thu, May 09, 2024 Niels Thykier wrote:
[...]  >> For me, lintian fails in all roles it has. It is not a good tool for 

newbies

to get help, since it can only test build artifacts. As an example, your
feedback look is a full package build followed by unpacking the package just
so lintian can tell you have a typo on line 4. That is a massive waste of
resources - notably developer time and mental bandwidth.


I understand your point about having a tool that checks the debian/ dir for
issues like spelling errors, binary files in the upstream source, and other
concerns right within the packaging tree before the build starts. However, I
don't understand why you mention newbies in this context.



My core argument is the feedback cycle is excruciatingly complicated and 
slow compared to what it needs to be for validation of "debian/*" files. 
In my view, the problem is amplified for newcomers in multiple areas.



[...]
As a consequence,
people now get auto-rejects when uploading because lintian on the FTP master
server does not produce the same output as current lintian in stable or
newer.


I think its a bit unfair to blame lintian about the fact that its old
versions do not do a proper job when it comes to checking newer packages.



Is it now? When I maintained lintian, I was of the understanding that 
the dak usage was an explicit use-case we, as lintian maintainers, were 
expected to support. In my time, I would have considered this situation 
as an RC bug against lintian if I had this change and the FTP masters 
were unable or unwilling to install the -backports version of lintian.


On the other side of the "unfairness" coin, I feel it is unfair to have 
people spend volunteer time being stuck in a painful cycle of "It works 
on my machine, but dak rejects it because lintian is not updated on the 
FTP masters machine" for which they are expected to ignore lintian 
warnings locally to get out of (you need overrides in the old format, 
which the new lintian then complains about - damned if you, damned if 
you don't). Those are volunteers that wasted their Debian time being 
cauhgt between lintian and dak and, in my book, that was much more 
unfair than having lintian (or dak) and its maintainers own up to it.


I feel we, as a distribution, should ensure such problems do not happen. 
As stated, in my time as a lintian maintainer, I felt the responsibility 
was with lintian and that is why I blame lintian.


Maybe times have changed here and we, as a distribution, no longer hold 
lintian accountable here. Not sure who is then, but maybe that is part 
of why this problem has existed for so long.


(For the record, I think the ship sailed on this one. I am not expecting 
Alex to go retroactively fix this problem on the lintian side. I expect 
us not to repeat this mistake again)



[...]
Especially for the editor support
related parts, where people get instant feedback both on issues and the fix,
automatic reformatting on save and completion suggestions. None of which
lintian or wrap-and-sort are capable of.


If you ask me personally I'm absolutely happy about a policy checker that
simply reports issues.  I'm fine with firing up an editor in some other
terminal and be done.  Maybe I'm missing your point but for me that's a
non-issue.  Or is your comparison with wrap-and-sort rather targeting at
some tool that automatically fixes the issues it has found and I can check
the changes afterwards with `git diff`?  Or something like the janitor tools
that even commit changes?
  


I feel my point is not coming across at all and that is frustrating me a 
bit.


Imagine you need to change `debian/control` for some reason regardless 
of the situation that triggered this. You open up your editor and do the 
change. In the process, you make a mistake.


The current workflow is:

 1) Edit file (introducing mistake)
 2) No feedback in the editor, so:
a) You save the file
b) Build an artifact that lintian can check
c) Run lintian to get the feedback
 3) You correct the mistake.
 4) Rinse and repeat all the sub-steps of 2) to validate there are no
mistakes.

This is the workflow you have today with lintian. And it applies equally 
to all kinds of mistakes from policy violations, to textual or semantic 
typos.


Now, I would like you to step away from the status quo. What this 
workflow *should* have been in my view is:


 1) Edit file (introducing mistake)
 2) Editor shows a "Here is a mistake"-marker.
 3) You correct the mistake (either manually or via a quick fix)
 4) Editor removes a "Here is a mistake"-marker.
 5) Save the file

Notice here that I do not need to leave my editor to get feedback. I get 
it automatically, so I cannot forget it nor am I inclined to skip the 
check in a hurry. This is the crux of my problem with status-quo 
feedback loop. I have *actively* ask for feedback. I have to wait for it 
too which becomes paper cut.

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

[Holger Levsen]

On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote:
> 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.

I don't follow this conclusion because the premise "the Debian archive itself is
a VCS" is as right or wrong as the statements "earth is clock" or an "ocean is a
washing machine".

Or, to put it differently, "vi $file ; cp $file $file.bak ; vi $file" is also 
a VCS, but an even poorer one than the Debian archive.

Just because something has some VCS like properties it doesn't make it a VCS
as in the sense as people understand it in 2024.

IMO (very few) people object using a(n official) VCS is because it would change
their workflows and/or because they believe their needs are more important than
our needs. And saying "the Debian archive is a VCS and that causes conflicts
with another VCS" is a red herring at best, because as dak+git or dak+vim+copy
shows (or gosh, using different git repos) that using several VCS is possible 
and
done by millions daily.


-- 
cheers,
Holger

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

It's not climate change nor climate crisis, it's climate disaster.


signature.asc
Description: PGP signature

Bug#1071570: ITP: nemo-qml-plugin-contacts -- QML module providing access to QtPIM QtContacts

[Mike Gabriel]

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

* Package name: nemo-qml-plugin-contacts
  Version : 0.3.28
  Upstream Contact: https://sailfishos.org/contact/
* URL : https://github.com/sailfishos/nemo-qml-plugin-contacts.git
* License : BSD-3-clause
  Programming Lang: C++
  Description : QML module providing access to QtPIM QtContacts

 This QML module provides a high-level abstraction layer on top of the QtPIM
 QtContacts API with some improvements such as a data cache, localisation and
 internationalization enablers, and other utility capabilities.
 .
 This package is part of Lomiri's addressbook app stack and will be
 maintained by the Debian UBports Packaging Team.

Re: Any volunteers for lintian co-maintenance?

[PICCA Frederic-Emmanuel]

I tried it on one of my package silx

warning: File: ./debian/tests/control:22:14:22:19: It is possible that the 
value is a typo of "i386". [Correctable via --auto-fix]
22: Architecture: !i386

It seems wrong to me, the test control file allow !i386

Cheers

Frederic

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

[Andrey Rakhmatullin]

On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote:
> Hi,
> 
> On 5/21/24 15:54, Andrey Rakhmatullin wrote:
> 
> > > 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.
> 
> All of these things are *also* explicit features. We need a way to unpublish
> things, and mirrors only want to keep a shallow subset.
We don't have a way to unpublish things, and force pushes I meant are
uploading things without including all previous changes, like all those
NMUs silently not included in the next maintainer uploads.
But, sure, some of the problems we have are explicitly features.

> Representing the Debian archive in git would probably look like a massive
> amount of submodules, because that's the only way to represent state across
> multiple projects without extending it 
Sorry? I don't understand what you would use submodules for. Unless you
meant literally mapping archive-as-VCS to a single literal VCS repo?


-- 
WBR, wRAR


signature.asc
Description: PGP signature

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

[Simon Richter]

Hi,

On 5/21/24 15:54, Andrey Rakhmatullin wrote:


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.


All of these things are *also* explicit features. We need a way to 
unpublish things, and mirrors only want to keep a shallow subset.


Representing the Debian archive in git would probably look like a 
massive amount of submodules, because that's the only way to represent 
state across multiple projects without extending it -- and extending is 
a big no-no, because then we'd lose all the forge support. Submodules 
cannot represent the pristine-tar branch though.



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.


There are two axes here -- "good" and "fits the use case."

What I'm arguing is that git does not fit our use case, despite being 
good, because it is designed for something else. We can make it fit our 
use case by wrapping it, but then we have a choice between a thin veneer 
that breaks easily as people use git commands inside a source tree, when 
they should only be using gbp commands, or a completely opaque wrapper 
that loses us all the git integration from third-party tools like forges.


Because git treats packaging metadata as data, no correctness of 
metadata is enforced at this level. We could add this in the form of 
upload hooks, but then people would start complaining that they want to 
use the tools like they want. They would be wrong, but that is what 
happens with leaky abstractions.


This is the exact opposite of the mandatory-debhelper debate: requiring 
declarative packaging (and therefore calcifying all custom sequences 
into debhelper plugins) is precisely the opposite of "using git because 
it is familiar" -- the benefit of using the abstraction comes from 
denying access to the layer below and therefore hiding its complexity.


   Simon

Re: Any volunteers for lintian co-maintenance?

[Holger Levsen]

On Mon, May 20, 2024 at 01:00:00PM -0700, Otto Kekäläinen wrote:
> 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
 
and if you don't have docker but "just" trixie or sid, just run

sudo apt install dh-debputy python3-lsprotocol
debputy lint

:)


-- 
cheers,
Holger

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

"I know what you're thinking" used to be an idiom but now it's a business model.


signature.asc
Description: PGP signature

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

[Sean Whitton]

Hello,

On Sun 19 May 2024 at 10:05am +02, Paul Gevers wrote:

>
> PS: I've always wondered if the dgit server shouldn't track history, even if
> uploads don't happen via it. A dgit clone could (should?) already provide
> available history, even if no upload happened via it yet.

Well, 'dgit clone' adds a vcs-git remote pointing at the maintainer's
history.  So it sort of does this.  We could make it do more.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Sean Whitton]

Hello,

On Sun 19 May 2024 at 12:32pm -07, Otto Kekäläinen wrote:

> You could go to
> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and
> conduct a code review?
>
> You might discover that GitLab is useful and is not duplicating
> Debbugs or anything else in Debian - it is currently the only platform
> to conduct code reviews on in a way that has automatic testing and
> comment-response-resolved -tracking. Doing code reviews patches
> attached in email does not have that.
>
> If you try it out, and still think Salsa is bad for Debian, then I am
> more willing to accept your stanze.

I have tried it out, and am happy for those maintainers that like it to
use it, but I do not want to maintain most of my packages that way.
I want people to send me patches to the BTS / project ML.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

On Tue, May 21, 2024 at 12:05:59PM +0200, Philip Hands 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.
> 
> Attempts at top-down imposition of new methods on Debian strike me as
> being unlikely to induce joy in anyone involved.
> 
> After all, We're a self-selecting group of people who are prone to
> repeatedly walking the road less travelled.
> 
> Do we even have a consensus on which layout is "best"?
Definitely no.
Also all of them are bad in some way, which is expected when you wrap
incompatible workflows.

> For anyone with an opinion, I'd suggest that you should try to make sure
> that DEP-14 reflects your opinion, and then work on getting people to
> adopt the use of DEP-14 and/or get DEP-14 accepted.
How do you envision this for people who are against storing upstream
sources in the repo? Having two mutually exclusive options in DEP-14?


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Simon McVittie]

On Mon, 20 May 2024 at 19:10:00 -0700, Otto Kekäläinen wrote:
> 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."

This is not unique to Debian packaging: upstream projects that maintain
a GNU-style ChangeLog and/or NEWS file have the same problem, for the
same reasons.

In the projects where I'm an upstream maintainer, we've generally solved
this by having the detailed ChangeLog either auto-generated from `git log`
at release time or not existing at all, and writing a more user-facing
summary of changes into the NEWS file periodically during development
(generally pushed directly by a maintainer rather than going via a merge
request, because adding text to NEWS hopefully can't cause regressions),
and in particular ensuring NEWS is up-to-date as part of the release
procedure (a maintainer/release manager responsibility).

Using `gbp dch` to maintain debian/changelog is analogous to that
technique - the version auto-generated from `git log` acts as a first
draft, and if a contributor wants to adjust the wording used in
debian/changelog to be less about fine-grained technical details and
more user-facing, they can use `gbp dch` to summarize all changes up
to now, make the desired adjustments, `git commit -m 'Update changelog'`
and push. Next time the changelog needs to be updated, `gbp dch` will
start from just after the most recent change that touched
debian/changelog.

smcv

Re: finally end single-person maintainership

[Luca Boccassi]

On Tue, 21 May 2024 at 03:16, Simon Richter  wrote:
>
> 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."

Not really, our workflows are mainly influenced by whatever was
available in the late 90s and has just kept chugging along on life
support - hence FTP uploads, GPG signing tarballs, sending commands
via emails. There are plenty of ways to maintain packages that do not
involve any of that - see SUSE's OBS, etc.

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

There's factually no need for any of that. As per
https://trends.debian.net/ most packages today are on Salsa despite
the lack of these buttons. The goal is to have an actual source code
management system that allows forking, branching, rebasing, merging,
navigating history, running integration tests. The fact that at some
point one has to interact with crufty old ftp servers and dusty
tarballs is not really relevant. Having a pipeline stage at the end of
salsa-ci that does an upload for you would be a nice improvement, but
it's by no means necessary to use Salsa effectively and productively,
as the vast majority of cases are already showing in reality.

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

If that is needed, why isn't there a button on the ftp server instead of dput?

Re: finally end single-person maintainership

[Philip Hands]

Bernd Zeimetz  writes:

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

Attempts at top-down imposition of new methods on Debian strike me as
being unlikely to induce joy in anyone involved.

After all, We're a self-selecting group of people who are prone to
repeatedly walking the road less travelled.

Do we even have a consensus on which layout is "best"?

DEP-14 exists, but that is still candidate status, and even if it were
accepted, it has a section "When to not follow the above recommendations"

I suspect that there's a decent chunk of developers who generally just
follow the status quo of every package they work on, without fuss.

I rather like dgit for reducing the extent I have to think about this
sort of thing, but I note that at least one person in this thread seems
vexed by it, so we cannot even agree on the merits of that, apparently.

Could it be that we mostly hear from the people at the extremities of
opinion on issues like this?  If so, I don't see how we're going to
establish a consensus, and without that it's not going to be easy (or
worthwhile) to pick a layout, nor to try and impose that on others.

For anyone with an opinion, I'd suggest that you should try to make sure
that DEP-14 reflects your opinion, and then work on getting people to
adopt the use of DEP-14 and/or get DEP-14 accepted.

That way, you'll be able to work towards consistency without having a
massive and pointless fight, that will be sure to harden some people's
opinion against you, making your wished-for outcome that much less
likely.

Cheers, Phil.

P.S. I don't really give a damn about this issue, and am happy to use
DEP-14 in general, or follow the current state of a particular package.
If DEP-14 were to change radically, I'd be willing to switch to new
recommendations, so if you care, please make it better if you can.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Re: About i386 support

[Leandro Cunha]

Andrey,

On Tue, May 21, 2024 at 3:31 AM Andrey Rakhmatullin  wrote:
>
> 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

I agree that it can be confusing, but I mentioned that we are
specifically talking about this architecture (i386) that is in the
subject of the email and to avoid confusion.

--
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-