Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages

[Fabio Fantoni]

Il 02/08/2024 11:20, Andrea Pappacoda ha scritto:

Hi Otto, and all the others participating in this thread :)

Il giorno sab 27 lug 2024 alle 15:38:40 -07:00:00, Otto Kekäläinen 
 ha scritto:
I have drafted a new DEP at 
https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled 
"DEP-18: Enable true open collaboration on all Debian packages".


Thanks for your work on this. Trying to unify aspects of Debian 
development is one of the things I think we need to do to not only 
"enable true open collaboration", but also to attract more new 
contributors.


While the proposal has good intentions and goals I agree with, it 
tries to achieve it with tools which, to my eyes, don't really enable 
"true" open collaboration, which Jonas has expressed really well already.


The issue to me is when you add the word "Salsa", or more precisely 
"GitLab" to the mix. Don't get me wrong: these days development *has* 
to be done with Git and with CI workflows, but having to use GitLab 
just to have these two things is overkill.



Having the packaging on git i think is very useful, whether it is on 
salsa or another system it would bring benefits to some packages not 
currently on git. Not to force to use it but at least recommend it (and 
then later reconsider whether to force it)


One particular thing noticed in some cases (and I hope they are not 
many) is the lack of use or especially updates of the Vcs-* fields in 
d/control. I think is important point to packaging repository from the 
tracker if present and to update it if moved, this can help 
collaboration and reduce possible waste of time doing things that are 
perhaps already done by others (or WIP) but which have not yet been 
uploaded.





Before a certain way of doing things can be mandated or "warmly 
recommended", the technology has to be as flawless as possible - and 
today I wouldn't call Salsa "flawless", would you? Issues with 
Salsa/GitLab:


1. It is so slow that it makes me want to close by browser and do 
something else instead

2. It doesn't support email-based workflows
3. It has a lot of features we don't need. Or rather, it has more 
features we *don't* need than we do.
4. Its user interface is confusing, it's often hard to find what I'm 
looking for

5. Did I mention how slow it is?
6. It is developed by a company who's philosophy and interests are 
misaligned with Debian's
7. The product it tries to mimic, GitHub, is also misaligned with 
Debian's philosophy and interests


While performance is something we could reasonably do something about, 
all the other points are part of GitLab by design, and we're stuck 
with them.


It has also been mentioned that email-based workflows are for 
"dinosaurs". Well, I'm 21, so I'm a living example that that's not 
necessarily true :)


I think that both email and systems like salsa/github/gitlab etc. are 
useful, both with pros and cons. Forcing people to use only one or the 
other could be counterproductive at the moment. One thing that I think 
would be useful is to have certain, fast and simple information for each 
package about which actual collaboration methods it uses and prefers.


For example seeing a package it would be very useful to know immediately 
if it wants a collaboration only through bugtracker and patch, only 
through vcs or both are accepted. If managed in a team point more easily 
to information about the team and any pages with details (for example on 
wiki).


I mainly use salsa, it has many advantages and could bring improvements 
in many cases but as mentioned there are also disadvantages (partly 
subjective) and therefore forcing it I don't think is a good thing, 
rather recommending it instead.


But first of all I think it is essential to improve salsa performance 
and reduce downtime and problems. Over the last few years I have found 
myself too many times in cases where I could work on packages but salsa 
was not working or very slow, and many cases where I needed salsa-ci for 
quick checks but it had problems. This is discouraging for contributors 
and counterproductive (especially for those with little time available). 
Recently I think there has been some improvement compared to past 
periods when it was worse both with salsa speed/reachability and 
salsa-ci problems (which lasted longer), big thanks to all those who 
work on it to improve it and I hope it will improve further in the future.


Another thing that seems underestimated and I think it is good to 
emphasize is the excessive slowness of the wiki.debian.org, it seems 
much worse than salsa to me, and I think it's important to solve. There 
is a lot of useful (or in some cases essential) information on the wiki 
for developers (and also for users), and finding yourself too often when 
you need to read something there (or contribute to some page) that 
doesn't load or takes a very long time is counterproductive.


Trying to help new contributors by pointing them in many cases to 
information on the wiki a

Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages

[Fabio Fantoni]

Il 02/08/2024 15:49, Jonas Smedegaard ha scritto:

Hi Fabio,

Quoting Fabio Fantoni (2024-08-02 14:31:04)

One particular thing noticed in some cases (and I hope they are not
many) is the lack of use or especially updates of the Vcs-* fields in
d/control. I think is important point to packaging repository from the
tracker if present and to update it if moved, this can help
collaboration and reduce possible waste of time doing things that are
perhaps already done by others (or WIP) but which have not yet been
uploaded.

That's tracked as OLD key at https://qa.debian.org/cgi-bin/vcswatch -
also included in the Maintainer Dashboard for each package at
https://udd.debian.org/dmd.cgi

Whenever you stumble upon a package misaligned with its declared Vcs
metadata, please file a bugreport, and while doing so consider
encouraging the maintainer to use the Maintainer Dashboard.


Thanks for your reply, I know about there and is useful for found vcs 
not working but vcs working/reachable but no longer used, in favor of 
something else they are not identifiable.


The system is only able to notify partially for those not updated but it 
is not possible to identify if you are working on another repository it 
is not identifiable but it will be only if the vcs field will be 
manually changed, so it is up to the maintainer to change it, in 
addition there is a slight problem that it changes only with a new 
upload, if a lot of time were to pass and a lot of work was done during 
it would not be possible to notice immediately. In some cases you could 
move the repository or notify the move inside but unfortunately in the 
case of repositories on which you do not have permissions (for example 
in abandoned packages and someone is about to adopt or recover them). 
They seem quite rare but unfortunately they happen. Even if it was 
recommended to keep them updated and if it changed update them 
immediately doing a new upload just for that doesn't seem like the best 
to me, could it be useful to have another way, or is there already one? 
anyway this is just a minor thing and even if it were to improve it 
would have little influence compared to what I suppose is what has the 
most influence






I think that both email and systems like salsa/github/gitlab etc. are
useful, both with pros and cons. Forcing people to use only one or the
other could be counterproductive at the moment. One thing that I think
would be useful is to have certain, fast and simple information for each
package about which actual collaboration methods it uses and prefers.

For example seeing a package it would be very useful to know immediately
if it wants a collaboration only through bugtracker and patch, only
through vcs or both are accepted. If managed in a team point more easily
to information about the team and any pages with details (for example on
wiki).

I guess that you mean something like this:
```patch
--- a/debian/control
+++ b/debian/control
@@ -60,6 +60,7 @@ Standards-Version: 4.7.0
  Homepage: https://github.com/oxigraph/oxigraph
  Vcs-Git: https://salsa.debian.org/debian/oxigraph.git
  Vcs-Browser: https://salsa.debian.org/debian/oxigraph
+Contact: https://bugs.debian.org/oxigraph
  Rules-Requires-Root: no

  Package: oxigraph
```

In principle I find that an interesting suggestion, as I can imagine
such information being helpful in understanding if debbugs is used only
by "dinosaurs".

I see two problems, however:

a) Maintainers will be bothered to add that new field to every package
(or at least a substantial subset) for it to be of practical use.

b) Which other answers exist for that field?  I mean, is it ok in Debian
for a maintainer to not use Debbugs?  Is it ok in Debian for a
maintainer to also use another issue tracker and not replicate whatever
is collected elsewhere in Debbugs?

Or perhaps I am missing the point of your suggestion, and you do not
mean where *bug* chatter goes, but instead where *non-bug* conversations
go.  If that is the case, then I believe we have a field already for
that, called "Maintainer:".  If you mean neither issue tracking nor the
main contact information for a package, then please elaborate what you
had in mind, because that's pretty essential to get clarified before
discussing any further...



contact field don't exist now right? even if the contact field maybe 
doesn't give you an idea, maybe something like "contributing" that links 
to the bugtracker, to the repository MR/PR or a wiki page or site with 
any details (especially in case of a group)


how to do it on a technical level, inside debian/control or in another 
way if it was better I don't think it would be a problem, to not disturb 
the maintainers too much if you add something you can only put it 
recommended and not mandatory.


maybe I'm not good at explaining myself, I think the problem is that if 
a contributor, maybe even new or who wants to make even occasi

Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages

[Fabio Fantoni]

Il 03/08/2024 01:28, Jonas Smedegaard ha scritto:

Quoting Fabio Fantoni (2024-08-02 23:51:26)

Il 02/08/2024 15:49, Jonas Smedegaard ha scritto:

I think that both email and systems like salsa/github/gitlab etc. are
useful, both with pros and cons. Forcing people to use only one or the
other could be counterproductive at the moment. One thing that I think
would be useful is to have certain, fast and simple information for each
package about which actual collaboration methods it uses and prefers.

For example seeing a package it would be very useful to know immediately
if it wants a collaboration only through bugtracker and patch, only
through vcs or both are accepted. If managed in a team point more easily
to information about the team and any pages with details (for example on
wiki).

I guess that you mean something like this:
```patch
--- a/debian/control
+++ b/debian/control
@@ -60,6 +60,7 @@ Standards-Version: 4.7.0
   Homepage: https://github.com/oxigraph/oxigraph
   Vcs-Git: https://salsa.debian.org/debian/oxigraph.git
   Vcs-Browser: https://salsa.debian.org/debian/oxigraph
+Contact: https://bugs.debian.org/oxigraph
   Rules-Requires-Root: no

   Package: oxigraph
```

In principle I find that an interesting suggestion, as I can imagine
such information being helpful in understanding if debbugs is used only
by "dinosaurs".

I see two problems, however:

a) Maintainers will be bothered to add that new field to every package
(or at least a substantial subset) for it to be of practical use.

b) Which other answers exist for that field?  I mean, is it ok in Debian
for a maintainer to not use Debbugs?  Is it ok in Debian for a
maintainer to also use another issue tracker and not replicate whatever
is collected elsewhere in Debbugs?

Or perhaps I am missing the point of your suggestion, and you do not
mean where *bug* chatter goes, but instead where *non-bug* conversations
go.  If that is the case, then I believe we have a field already for
that, called "Maintainer:".  If you mean neither issue tracking nor the
main contact information for a package, then please elaborate what you
had in mind, because that's pretty essential to get clarified before
discussing any further...


contact field don't exist now right? even if the contact field maybe
doesn't give you an idea, maybe something like "contributing" that links
to the bugtracker, to the repository MR/PR or a wiki page or site with
any details (especially in case of a group)

Yes, the contact field exists:
https://www.debian.org/doc/debian-policy/ch-controlfields.html#maintainer


I spent a lot of time writing but it seems I didn't manage to convey 
most of what I mean :(


DEP-18 doesn't seem to me to want to change existing contact methods but 
to standardize/improve the collaboration part regarding contributing to 
the development of packages, or am I perhaps missing something?


and I was just thinking about that part and thinking about how to 
contribute in a package then I did a more extensive and practical 
reasoning and it seems that in most of what I said I was unable to 
explain myself


in theory DEP-18 would be great and could produce great results but in 
practice I suppose there are not enough contributors and enough 
participation to make it possible (or at most it will be possible on a 
small part of packages) and so I was thinking about what would be a 
prerequisite to have more possibilities of contributors and 
contributions and also possible small improvements on the situation from 
which we start






maybe I'm not good at explaining myself, I think the problem is that if
a contributor, maybe even new or who wants to make even occasional
contributions on specific packages is not able to find in a simple and
fast way about the package on which he wants to contribute as he should
(or is better to do), in some cases you can understand in short time by
looking a bit at the bugtracker and the vcs while, looking for any wiki
pages if he is part of a team but in many cases it is not simple/fast to
understand how he should contribute for that package in order to get the
best result. using patches on bugtracker or vcs (like salsa) is just one
part, then there could be more

you could say to force everyone to use the same system, in theory it
would solve the problem, but in practice I find it difficult and perhaps
more harmful. I try to summarize: the contributors are people and not
machines, moreover many do it as a passion in a little free time and not
as if it were a job.

We all do it as a passion in little free time and not if it were a job.
Also Maintainers.  What is the point of introducing additional ways to
interact with maintainers than the ones that already exist and (as I
understand it) is mandatory: A general contact *email* address, and tied
to that a connection to the *Debbugs* issue tracker.

If a new contributor is unable to contact a package maintainer throug

Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages

[Fabio Fantoni]

Il 03/08/2024 14:40, Kentaro Hayashi ha scritto:

Hi,

Even though +1 for DEP-18 basically, I think that it might be better
to add an option
to formalize package owner's (single person maintainer) collaboration policy
especially about non-team maintained packages under
https://salsa.debian.org/debian/.

If such a package repository enables merge request feature, then I
will send merge request and
send E-mail to bugs.d.o about url of the MR to notify it.
But it is not true that such MR is merged in timely manner.
(Surely collaboration takes longer time, I know.)

If the package owner expresses a collaboration policy in advance, it
can improve such a situation
in a particular case and we can respect it.

NOTE: The following idea might be out-of-scope in DEP-18, but specific
use-case to improve
collaboration in Debian, IMHO.

Here is just an idea: put collaboration policy metadata in debian/control.
(The following idea assumes that non-maintainer DD tend to hesitate to
commit/merge it)

* Collaboration-Policy: debian/CONTRIBUTION.md
   Yes, we have README.source already, but it might be better to note
in a separate file about collaboration.
* Collaboration-Policy-Commit: yes
   It declares that the package owner encourages non-maintainer DD to
commit directly without merge request.
* Collaboration-Policy-Merge: yes
   It declares that the package owner encourages non-maintainer DD to
allow merge requests.
   (DD has maintainer right in salsa.d.o by default as you know, but
you can merge without worry if there is it.)
* Collaboration-Policy-LowThresholdNmu: yes
   It declares that LowThresholdNmu rule [1] is applied.
* Collabollation-Policy-NMU-Delay: 15
   It declares that NMU delay the package owner wants.

[1] https://wiki.debian.org/LowThresholdNmu

Pros:
* DD/DM and contributors can respect the package owner's intent about
the package collaboration.
* Reduce a chance to cause inconsistency between the content of each
package repository on salsa.d.o and NMU'ed package source.
   * Because other DD (non package owner) can commit/merge, then ship
NMU package.
Cons:
* Maintainers will be bothered to add that new field to every package
   (If there is no Collaboration-Policy, it is safe that sending merge
request and let it the package manager, thus nothing changed)
* No mechanism to enforce Collaboration-Policy-Commit: no or
Collaboration-Policy-Merge: no policy
   because DD has maintainer rights on salsa.d.o and can commit/merge
it in reality.

It might worry too much, but it might be able to block an unfortunate
accident, a so-called package hijack
with incomplete communication in some cases.


Hi, this I think is can be useful (beyond the example use of 
salsa/debian packages which is not necessary as replied by Tobias 
Frost), I think will be better with only one additional (and optional) 
field in d/control, like Collaboration-Policy that point a file or url, 
this I think that can decrease the possible annoyance and in the case of 
teams or even single maintainers having a single policy file to point to 
and update in a simpler and faster way (especially if there were the 
same policies for dozens of packages or more, there could be also 
hundreds or thousands)


Also the local file or via url to which it points I think should have 
both predefined and machine readable fields and the possibility of 
having other text or other links for further details


as an additional field I think it is useful to add one regarding the 
preferred method for contributing, patches on bugtracker (if there were 
those who would prefer to continue on those even if DEP-18 recommended 
salsa), or via vcs (be it MR on salsa, PR on github etc.) depending on 
what you use, or both (if both are welcome)


alternatively to not have an extra field in d/control simply use 
debian/CONTRIBUTION.md, if it exists and if you want to do it in a 
simple/fast way with a single one on many packages pointing to the url 
insert there a single machine readable case that points to the url that 
would have been put in d/control instead




Regards,

2024年7月28日(日) 7:39 Otto Kekäläinen :

Hi all,

I have drafted a new DEP at https://salsa.debian.org/dep-team/deps/-/merge_requests/8 
titled "DEP-18: Enable true open collaboration on all Debian packages".

Direct link to raw text: 
https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn

This would have been a great topic to discuss in person at DebConf, but 
unfortunately I can't attend this year, so I'll just kick this off on the 
mailing list.

This is continuation to the 'single maintainership' discussions earlier this 
year. I also think that more unified and open collaboration processes could 
help decrease maintainer burnout, lower barrier for existing and new 
maintainers to help with multiple packages, and overall perhaps also improve 
quality of uploads by having more attention on the source code prior to upload.

If you think this propos

Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages

[Fabio Fantoni]

Il 03/08/2024 15:16, Jonas Smedegaard ha scritto:

Quoting Kentaro Hayashi (2024-08-03 14:40:51)

Hi,

Even though +1 for DEP-18 basically, I think that it might be better
to add an option
to formalize package owner's (single person maintainer) collaboration policy
especially about non-team maintained packages under
https://salsa.debian.org/debian/.

If such a package repository enables merge request feature, then I
will send merge request and
send E-mail to bugs.d.o about url of the MR to notify it.
But it is not true that such MR is merged in timely manner.
(Surely collaboration takes longer time, I know.)

If the package owner expresses a collaboration policy in advance, it
can improve such a situation
in a particular case and we can respect it.

NOTE: The following idea might be out-of-scope in DEP-18, but specific
use-case to improve
collaboration in Debian, IMHO.

Here is just an idea: put collaboration policy metadata in debian/control.
(The following idea assumes that non-maintainer DD tend to hesitate to
commit/merge it)

* Collaboration-Policy: debian/CONTRIBUTION.md
   Yes, we have README.source already, but it might be better to note
in a separate file about collaboration.
* Collaboration-Policy-Commit: yes
   It declares that the package owner encourages non-maintainer DD to
commit directly without merge request.
* Collaboration-Policy-Merge: yes
   It declares that the package owner encourages non-maintainer DD to
allow merge requests.
   (DD has maintainer right in salsa.d.o by default as you know, but
you can merge without worry if there is it.)
* Collaboration-Policy-LowThresholdNmu: yes
   It declares that LowThresholdNmu rule [1] is applied.
* Collabollation-Policy-NMU-Delay: 15
   It declares that NMU delay the package owner wants.

[1] https://wiki.debian.org/LowThresholdNmu

Pros:
* DD/DM and contributors can respect the package owner's intent about
the package collaboration.
* Reduce a chance to cause inconsistency between the content of each
package repository on salsa.d.o and NMU'ed package source.
   * Because other DD (non package owner) can commit/merge, then ship
NMU package.
Cons:
* Maintainers will be bothered to add that new field to every package
   (If there is no Collaboration-Policy, it is safe that sending merge
request and let it the package manager, thus nothing changed)
* No mechanism to enforce Collaboration-Policy-Commit: no or
Collaboration-Policy-Merge: no policy
   because DD has maintainer rights on salsa.d.o and can commit/merge
it in reality.

It might worry too much, but it might be able to block an unfortunate
accident, a so-called package hijack
with incomplete communication in some cases.

What is the core purpose of adding these suggested new metadata fields?

An NMU is non-collaborative - it is a non-maintainer that not only
offers a contribution but bypasses maintainers and issues a release with
the contribution integrated.

It makes sense for me that we have ways for maintainers to communicate
ahead of time, how NMUs are acceptable, because NMUs lack collaboration.

I was under the impression that collaboration was, well, collaborative.
That it was about collaboration between contributors and maintainers.
Am I mistaken, and it is instead about collaboration between
contributors and non-maintainer mentors, which potentially ends in an
NMU?

If not - if it is collaboration with maintainers - then I don't
understand the need for signalling ahead of time how maintainers prefer
to work, as contributors can simply ask the maintainer.


there is a purpose and that is what I was trying to explain in a part of 
one of my emails: to have certain information on how to contribute in a 
simple and fast way, without having to write emails to which you might 
never receive a reply, or after days or even weeks


so you can instead immediately proceed to contribute in the preferred 
methods indicated and even if there is no response


less emails to answer from maintainers and instead spend that time 
analyzing the contributions received (maybe more likely as he or his 
team prefers)


more chance of contributions, rather than maybe sending an email to the 
maintainer, waiting and since he doesn't respond you think it's useless 
to contribute there and you avoid it (in some packages where I wanted to 
contribute occasionally I ended up doing that). once there are 
contributions there is a greater chance that they will be made NMU by DD 
(especially if RC), if already mostly ready, more chance that they will 
be used by other DD in case of team packages, or possibly by 
contributors trying to save an abandoned package, and these are some 
examples that come to mind





  - Jonas





OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages

[Fabio Fantoni]

Il 03/08/2024 15:59, Jonas Smedegaard ha scritto:

Quoting Fabio Fantoni (2024-08-03 15:39:00)

Il 03/08/2024 14:40, Kentaro Hayashi ha scritto:

Hi,

Even though +1 for DEP-18 basically, I think that it might be better
to add an option
to formalize package owner's (single person maintainer) collaboration policy
especially about non-team maintained packages under
https://salsa.debian.org/debian/.

If such a package repository enables merge request feature, then I
will send merge request and
send E-mail to bugs.d.o about url of the MR to notify it.
But it is not true that such MR is merged in timely manner.
(Surely collaboration takes longer time, I know.)

If the package owner expresses a collaboration policy in advance, it
can improve such a situation
in a particular case and we can respect it.

NOTE: The following idea might be out-of-scope in DEP-18, but specific
use-case to improve
collaboration in Debian, IMHO.

Here is just an idea: put collaboration policy metadata in debian/control.
(The following idea assumes that non-maintainer DD tend to hesitate to
commit/merge it)

* Collaboration-Policy: debian/CONTRIBUTION.md
Yes, we have README.source already, but it might be better to note
in a separate file about collaboration.
* Collaboration-Policy-Commit: yes
It declares that the package owner encourages non-maintainer DD to
commit directly without merge request.
* Collaboration-Policy-Merge: yes
It declares that the package owner encourages non-maintainer DD to
allow merge requests.
(DD has maintainer right in salsa.d.o by default as you know, but
you can merge without worry if there is it.)
* Collaboration-Policy-LowThresholdNmu: yes
It declares that LowThresholdNmu rule [1] is applied.
* Collabollation-Policy-NMU-Delay: 15
It declares that NMU delay the package owner wants.

[1] https://wiki.debian.org/LowThresholdNmu

Pros:
* DD/DM and contributors can respect the package owner's intent about
the package collaboration.
* Reduce a chance to cause inconsistency between the content of each
package repository on salsa.d.o and NMU'ed package source.
* Because other DD (non package owner) can commit/merge, then ship
NMU package.
Cons:
* Maintainers will be bothered to add that new field to every package
(If there is no Collaboration-Policy, it is safe that sending merge
request and let it the package manager, thus nothing changed)
* No mechanism to enforce Collaboration-Policy-Commit: no or
Collaboration-Policy-Merge: no policy
because DD has maintainer rights on salsa.d.o and can commit/merge
it in reality.

It might worry too much, but it might be able to block an unfortunate
accident, a so-called package hijack
with incomplete communication in some cases.

Hi, this I think is can be useful (beyond the example use of
salsa/debian packages which is not necessary as replied by Tobias
Frost), I think will be better with only one additional (and optional)
field in d/control, like Collaboration-Policy that point a file or url,
this I think that can decrease the possible annoyance and in the case of
teams or even single maintainers having a single policy file to point to
and update in a simpler and faster way (especially if there were the
same policies for dozens of packages or more, there could be also
hundreds or thousands)

What annoyance are you referring to?
annoyance maintainers for update it on many package, with a url that 
point to an external file can be update once for even on tens, hundreds 
or more packages it could be set on


Are some new contributors annoyed by the lack of formalized rules for
collaboration?
not only new but also any contributors that want to contribute on other 
package, also about that I tried to explain something in one of my 
previous mail


Are some maintainers annoyed by how some new contributors initiate
collaborative contributions?

I don't know how likely it is, I hope it's very rare


As a maintainer, I can imagine getting annoyed by *non-collaborative*
contributions done in ways that I feel leaves an extra burden on me.
One description for that is "drive-by contributions", meaning that
someone contributes without having the time to *collaborate* on it,
to align the contribution with how the package is maintained.
But since this whole thread is about "true open collaboration", I
assume that you are talking about *collaborative* work, and then I
cannot recognize what is the kind of annoyance you are referring to.


There is a lot of other information that may vary on how to contribute 
in certain packages or teams beyond what is already listed, here only 
some example:


Debian Python Team - 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst


Java team - https://www.debian.org/doc/packaging-manuals/java-policy/

Rust team - https://wiki.debian.org/Teams/RustPackaging

go team - https://go-team.pages.debian.net/packaging.html




Kind regards,

  -

Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages

[Fabio Fantoni]

Il 04/08/2024 15:36, Andrey Rakhmatullin ha scritto:

On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote:

one problem I have with NMUs in team-maintained package is that they
often bypass Salsa…  Would it make sense to add to the DEP a request
that NMUs are started from and pushed to the default branch?

Only if DEP-18 also includes an easy way to find the workflow used by the
repo, which I'm not seeing there (which may be my fault).


something like wrote here can help for you?

https://lists.debian.org/debian-devel/2024/08/msg00058.html

https://lists.debian.org/debian-devel/2024/08/msg00062.html

I think something like this could be useful, even in a possible future 
where all packages would use git and salsa; but from the answers 
received so far it seems to be considered a useless thing. I would be 
curious to know the opinion of more people.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages

[Fabio Fantoni]

Il 05/08/2024 03:14, Andrey Rakhmatullin ha scritto:

On Sun, Aug 04, 2024 at 04:15:13PM +0200, Fabio Fantoni wrote:

Il 04/08/2024 15:36, Andrey Rakhmatullin ha scritto:

On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote:

one problem I have with NMUs in team-maintained package is that they
often bypass Salsa…  Would it make sense to add to the DEP a request
that NMUs are started from and pushed to the default branch?

Only if DEP-18 also includes an easy way to find the workflow used by the
repo, which I'm not seeing there (which may be my fault).


something like wrote here can help for you?

https://lists.debian.org/debian-devel/2024/08/msg00058.html

https://lists.debian.org/debian-devel/2024/08/msg00062.html

I think something like this could be useful, even in a possible future where
all packages would use git and salsa; but from the answers received so far
it seems to be considered a useless thing. I would be curious to know the
opinion of more people.

It's similar but different: I'm talking about workflows to build a package
from the repo (e.g. "gbp with gbp-pq and importing upstream tarballs").
And yeah it could be a metadata field.


Thanks for reply, what I mean is precisely a standard field that points 
to a file, inside the package or even an url as already explained can be 
very useful in most cases) that contains all the useful information for 
contributing to that package, including the one you mention. even if 
everyone applied DEP-14 and DEP-18 there would be some differences that 
could be useful to know in a simple and immediate way. and I think this 
is even more useful with the current situation and also very useful in 
case of any future migrations to more standardized systems.


currently you find such information from a simple search and/or looking 
a bit in the source, in the possible git in a few minutes only in part 
of cases, in many other cases instead it requires more time, the 
possible contact of the maintainer, attempts (and then eventually feel 
that it would be better to "improve" your contributions using other 
methods).


a single standard field (to be added optionally) and adding links to 
that file or url in the tracker (if present) I think would bring 
advantages and save time for both contributors and maintainers in many 
cases (when used)




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages

[Fabio Fantoni]

Il 05/08/2024 10:40, Simon Richter ha scritto:

Hi,

On 8/5/24 17:10, Fabio Fantoni wrote:

currently you find such information from a simple search and/or 
looking a bit in the source, in the possible git in a few minutes 
only in part of cases, in many other cases instead it requires more 
time, the possible contact of the maintainer, attempts (and then 
eventually feel that it would be better to "improve" your 
contributions using other methods).


This information should be in debian/README.source.

   Simon

debian/README.source can be used for that, this according to the current 
documentation does partially that, make it standard also for other parts 
mentioned, more known thing and change/improve the documentation, for 
example in 
https://www.debian.org/doc/debian-policy/ch-source.html#source-package-handling-debian-readme-source 
as at the moment reading at the beginning it leaves to understand to a 
restricted use of it, can be an improvement with minimal effort.


for example also in the end of it description have:

|debian/README.source| may also include any other information that 
would be helpful to someone modifying the source package. Even if the 
package doesn’t fit the above description, maintainers are encouraged 
to document in a |debian/README.source| file any source package with a 
particularly complex or unintuitive source layout or build system (for 
example, a package that builds the same source multiple times to 
generate different binary packages).
that it may suggest a greater use than what I saw and remembered but at 
least something like this should be put at the beginning of the 
description: "debian/README.source may include any information that 
would be helpful to someone modifying the source package and how to 
contribute to it"


could suggest to optionally add other parts on how to contribute that 
have been discussed, to insert any external links where to find the 
information (in order to update a single page/file even for a big amount 
of packages, but leaving README.source unchanged, so I guess it would be 
much more used thanks to less effort from the maintainers)




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Accepting DEP14?

[Fabio Fantoni]

Il 17/08/2024 10:47, Jonas Smedegaard ha scritto:

Hi Chris,

Quoting Chris Hofstaedtler (2024-08-17 10:17:19)

On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote:

IMO, and from discussions in the Debian Perl Group, the blocker is
the conversion of existing repos, both on salsa (which should be
doable via the API as suggested in the sketches mentioned above) and
also locally for hundreds of developer machines [git fails horribly
on the upstream/ → upstream/latest change].

I want to echo this pain. When changing the layout it seems almost
better to start from scratch.

I have in the past found it confusing how to handle it, but now I find
it tolerable (and don't recognize the "better to start from scratch"
judgement), after I figured out (as also hinted at in one of the links
by gregor) that you need to do the following, in that order:

  1. unlock branch "upstream" on salsa
  2. rename branch "upstream" → "upstream/latest" on salsa (or delete it)


rename branch in salsa would be very handy, i searched for it when i 
converted some repositories but i didn't find it, can you tell me how to 
do it please?


converting "upstream" branch to "upstream/latest" has always given me 
problems and wasted more time, that would take away one problem.


another problem seems to be if I had an "upstream" origin (which I use 
to cherry-pick upstream patches when needed), since then I put the 
upstream origin in the local repositories as "upstream_repo" to avoid 
problems.


I think for DEP-14 it would be very useful to have a howto for the 
conversion and a list of useful tips to avoid possible problems



  3. rename branch "upstream" → "upstream/latest" locally
  4. push local changes to salsa

(strictly speaking you can do step 3 before 1-2)



Additionally, in my opinion debian/latest is a mistake we should not
recommend.

Please elaborate why you consider it a mistake.  That's not obvious to
me.





  - Jonas





OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Accepting DEP14?

[Fabio Fantoni]

Il 17/08/2024 12:00, Jonas Smedegaard ha scritto:

Quoting Fabio Fantoni (2024-08-17 11:20:01)

Il 17/08/2024 10:47, Jonas Smedegaard ha scritto:

Hi Chris,

Quoting Chris Hofstaedtler (2024-08-17 10:17:19)

On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote:

IMO, and from discussions in the Debian Perl Group, the blocker is
the conversion of existing repos, both on salsa (which should be
doable via the API as suggested in the sketches mentioned above) and
also locally for hundreds of developer machines [git fails horribly
on the upstream/ → upstream/latest change].

I want to echo this pain. When changing the layout it seems almost
better to start from scratch.

I have in the past found it confusing how to handle it, but now I find
it tolerable (and don't recognize the "better to start from scratch"
judgement), after I figured out (as also hinted at in one of the links
by gregor) that you need to do the following, in that order:

   1. unlock branch "upstream" on salsa
   2. rename branch "upstream" → "upstream/latest" on salsa (or delete it)

rename branch in salsa would be very handy, i searched for it when i
converted some repositories but i didn't find it, can you tell me how to
do it please?

I cannot (I sloppily drop the branch and the republish a moment later),
but please see the links mentioned by Gregor.

  - Jonas

I tried using salsa cli tool from Gregor link but rename of upstream 
branch failed.


I did this trying on one project:

salsa --group cinnamon-team protect_branch xapp master no
salsa --verbose --group cinnamon-team rename_branch xapp 
--source-branch=master --dest-branch=debian/latest
# this failed to delete master, changed default branch from salsa 
website (in Settings->Repository) and deleted master branch (from website)

salsa --group cinnamon-team protect_branch xapp debian/latest m d

# after these the conversion from master to debian/latest seems correct, 
rename of upstream branch instead fails


salsa --verbose --no-fail --group cinnamon-team rename_branch xapp 
--source-branch=upstream --dest-branch=upstream/latest

salsa info: cinnamon-team id is 2992
salsa info: Project xapp => cinnamon-team/xapp
salsa info: cinnamon-team/xapp id is 17710
salsa info: Configuring xapp
salsa warn: Branch rename has failed for xapp
salsa info: Error POSTing 
https://salsa.debian.org/api/v4/projects/17710/repository/branches (HTTP 
400): Bad Request {"message":"Failed to create branch 'upstream/late... 
at /usr/share/perl5/Devscripts/Salsa/rename_branch.pm line 26.


Error above on Sid with devscripts 2.23.7 but I tried also on older system

Someone had rename of upstream branch working?



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Accepting DEP14?

[Fabio Fantoni]

Il 18/08/2024 15:51, Fabio Fantoni ha scritto:

Il 17/08/2024 12:00, Jonas Smedegaard ha scritto:

Quoting Fabio Fantoni (2024-08-17 11:20:01)

Il 17/08/2024 10:47, Jonas Smedegaard ha scritto:

Hi Chris,

Quoting Chris Hofstaedtler (2024-08-17 10:17:19)

On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote:

IMO, and from discussions in the Debian Perl Group, the blocker is
the conversion of existing repos, both on salsa (which should be
doable via the API as suggested in the sketches mentioned above) and
also locally for hundreds of developer machines [git fails horribly
on the upstream/ → upstream/latest change].

I want to echo this pain. When changing the layout it seems almost
better to start from scratch.

I have in the past found it confusing how to handle it, but now I find
it tolerable (and don't recognize the "better to start from scratch"
judgement), after I figured out (as also hinted at in one of the links
by gregor) that you need to do the following, in that order:

   1. unlock branch "upstream" on salsa
   2. rename branch "upstream" → "upstream/latest" on salsa (or 
delete it)

rename branch in salsa would be very handy, i searched for it when i
converted some repositories but i didn't find it, can you tell me 
how to

do it please?

I cannot (I sloppily drop the branch and the republish a moment later),
but please see the links mentioned by Gregor.

  - Jonas

I tried using salsa cli tool from Gregor link but rename of upstream 
branch failed.


I did this trying on one project:

salsa --group cinnamon-team protect_branch xapp master no
salsa --verbose --group cinnamon-team rename_branch xapp 
--source-branch=master --dest-branch=debian/latest
# this failed to delete master, changed default branch from salsa 
website (in Settings->Repository) and deleted master branch (from 
website)

salsa --group cinnamon-team protect_branch xapp debian/latest m d

# after these the conversion from master to debian/latest seems 
correct, rename of upstream branch instead fails


salsa --verbose --no-fail --group cinnamon-team rename_branch xapp 
--source-branch=upstream --dest-branch=upstream/latest

salsa info: cinnamon-team id is 2992
salsa info: Project xapp => cinnamon-team/xapp
salsa info: cinnamon-team/xapp id is 17710
salsa info: Configuring xapp
salsa warn: Branch rename has failed for xapp
salsa info: Error POSTing 
https://salsa.debian.org/api/v4/projects/17710/repository/branches 
(HTTP 400): Bad Request {"message":"Failed to create branch 
'upstream/late... at 
/usr/share/perl5/Devscripts/Salsa/rename_branch.pm line 26.


Error above on Sid with devscripts 2.23.7 but I tried also on older 
system


Someone had rename of upstream branch working?


fixed doing this workaround:

salsa --verbose --no-fail --group cinnamon-team rename_branch xapp 
--source-branch=upstream --dest-branch=upstream-tmp


salsa --verbose --no-fail --group cinnamon-team rename_branch xapp 
--source-branch=upstream-tmp --dest-branch=upstream/latest


after saw this 
(https://gobby.debian.org/export/Teams/Perl/new-branch-layout) probably 
with --rename-head can avoid error on master delete and make the 
procedure faster (not tested now)




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?

[Fabio Fantoni]

Il 25/08/2024 08:27, Gioele Barabucci ha scritto:

On 25/08/24 01:46, gregor herrmann wrote:

Many of the packages are trivial, so updating them (including
autopkgtests and blhc and lintian and whatnot) doesn't take longer
than 5 minutes.

So I can decide to wait for salsa CI for 10 minutes or update 2 more
packages in the same time. (Or try to context switch and keep a stack
of where I was etc.)


This is why "tag2upload once pipeline passes" is needed. (And more 
runners.)


Actually I push keeping "UNRELEASED" even in cases where is near sure to 
be ready because I want see salsa CI result and do fixes/improvements if 
needed before release, shortly after in major of case I did a release 
commit with only finalize the d/changelog and I skip salsa CI on that 
(with "-o ci.skip" on git push) to avoid waste salsa CI resource for 
same result of the previous.


Will tag2upload be usable in that case (with CI skipped on latest commit 
with only finalize of d/changelog, and successfull of the previous) or 
will there be a need for salsa CI successfully completedon the specific 
release commit?




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: DEP-18 discussion summary (Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages)

[Fabio Fantoni]

Il 28/08/2024 04:13, Otto Kekäläinen ha scritto:

Hi!

While I intend to continue on iterating DEP-18, here is a summary to
those who did not wade through the 140+ messages on the topic.
Unfortunately, the summary itself is also a bit long :)
Big thanks for your work and of other people that are trying to improve 
contribution and collaboration in Debian.

## Maintainer Workflows

There were concerns that requiring specific Git and Gitlab practices
could create burdens for existing maintainers, especially
single-person maintainers. Sean Whitton described his own preferences
as a maintainer:


I am happy to use salsa for git hosting and access management. I love that I can easily 
grant push access to my non-DD team members. But, I turn off salsa MRs for the repos of 
all packages I regularly upload. I would hope that this DEP can be written such as to 
account for these sorts of choices. Fabio Fantoni suggested allowing maintainers to 
specify their preferred collaboration methods in a machine-readable way, for example 
through a "Collaboration-Policy" field in debian/control.


As pointed by other people there is debian/README.source that can be 
used for that.


So if don't want to add a new field/s to d/control, and/or a new file we 
could simply use that one making this thing more known. and in the case 
of teams or people who manage many packages (even hundreds or thousands) 
with the same methods could put a link in d/README.source so as to point 
to a single page/site/repository to keep updated in a simpler and faster 
way with all the information



## Performance and Reliability

Multiple participants, including Salvo Tomaselli, Johannes Schauer
Marin Rodrigues, Andrea Pappacoda, and Gioele Barabucci, complained
about Salsa/GitLab being slow or unreliable at times, which deterred
contribution. Improvements to performance and uptime were seen as
important. In response, Otto Kekäläinen noted that the Salsa admins
had posted about upcoming hardware upgrades and other improvements to
address these issues at
https://salsa.debian.org/salsa/support/-/issues.


Thanks for working to improving Salsa.

However, there have also been numerous performance problems and 
unavailability of other parts useful to both contributors and users, in 
particular packages.debian.org and wiki.debian.org which don't seems has 
been considered, or am I wrong?




## Machine-Readable Metadata

Fabio Fantoni and Niels Thykier proposed including more
machine-readable metadata about packaging workflows (e.g. in
debian/control) to help automate contributor onboarding. Niels Thykier
outlined some specific examples of information that could be captured:


Does this package use `gbp dch` (or some other mechanisms) to generate the 
changelog OR should I include a changelog entry with my patch. Does this 
package use some form of automatic formatting that I should apply when I do my 
changes (if `wrap-and-sort`, then which options)? Does the maintainer prefer MR 
via salsa or BTS with patches for when I want to submit my changes for review.


Even if don't want to add them as Machine-Readable Metadata, I think can 
put them at least in debian/README.source (more details above), I think 
the important thing would be to advise maintainers more to make such 
information easily available.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Major of piuparts failed or blocked for long-standing errors of other packages

[Fabio Fantoni]

I've noticed for a long time (maybe years) that most of the packages in 
DDPO have Piuparts tests failing because of long-standing errors of 
other packages and then consequently also block many more dependent on 
them making difficult to find real problems related to the selected package.


Here's an example:

0m52.0s INFO: Warning: Package purging left files on system:
  /etc/X11/Xsession.d/     owned by: dbus-user-session
  /etc/default/locale -> ../locale.conf     not owned
  /etc/vconsole.conf -> default/keyboard     not owned
  /root/.ssh/     not owned
  /var/cache/private/     not owned
  /var/lib/private/     not owned
  /var/lib/systemd/coredump/     not owned
  /var/lib/systemd/ephemeral-trees/     not owned
  /var/lib/systemd/network/     not owned
  /var/lib/systemd/pstore/     not owned
  /var/log/private/     not owned

0m52.0s ERROR: FAIL: After purging files have disappeared:
  /etc/systemd/system/multi-user.target.wants/     not owned
  /etc/systemd/system/multi-user.target.wants/e2scrub_reap.service -> 
/lib/systemd/system/e2scrub_reap.service     not owned


0m52.0s ERROR: FAIL: After purging files have been modified:
  /etc/systemd/system/timers.target.wants/dpkg-db-backup.timer -> 
/lib/systemd/system/dpkg-db-backup.timer     not owned


(taken from 
https://piuparts.debian.org/stable2sid/fail/xapps-common_2.8.5-1.log)



Has anyone else noticed this?

Is there a way to avoid this and finally be able to use 
piuparts.debian.org to find any rare issues that escape Salsa CI and 
manual tests?




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Major of piuparts failed or blocked for long-standing errors of other packages

[Fabio Fantoni]

Il 31/08/2024 22:27, Serafeim (Serafi) Zanikolas ha scritto:

hi FAbio,

On Sat Aug 31, 2024 at 11:54 AM CEST, Fabio Fantoni wrote:

I've noticed for a long time (maybe years) that most of the packages in
DDPO have Piuparts tests failing because of long-standing errors of
other packages and then consequently also block many more dependent on
them making difficult to find real problems related to the selected package.

Here's an example:

0m52.0s INFO: Warning: Package purging left files on system:
    /etc/X11/Xsession.d/     owned by: dbus-user-session
    /etc/default/locale -> ../locale.conf     not owned
    /etc/vconsole.conf -> default/keyboard     not owned
    /root/.ssh/     not owned
    /var/cache/private/     not owned
    /var/lib/private/     not owned
    /var/lib/systemd/coredump/     not owned
    /var/lib/systemd/ephemeral-trees/     not owned
    /var/lib/systemd/network/     not owned
    /var/lib/systemd/pstore/     not owned
    /var/log/private/     not owned

0m52.0s ERROR: FAIL: After purging files have disappeared:
    /etc/systemd/system/multi-user.target.wants/     not owned
    /etc/systemd/system/multi-user.target.wants/e2scrub_reap.service ->
/lib/systemd/system/e2scrub_reap.service     not owned

0m52.0s ERROR: FAIL: After purging files have been modified:
    /etc/systemd/system/timers.target.wants/dpkg-db-backup.timer ->
/lib/systemd/system/dpkg-db-backup.timer     not owned

(taken from
https://piuparts.debian.org/stable2sid/fail/xapps-common_2.8.5-1.log)


Has anyone else noticed this?

Is there a way to avoid this and finally be able to use
piuparts.debian.org to find any rare issues that escape Salsa CI and
manual tests?

manually, yes, at least as far as obsolete conffiles is concerned, by looking at
adequate(1)'s output (which piuparts runs):

% wget https://piuparts.debian.org/stable2sid/fail/xapps-common_2.8.5-1.log -q 
-O - | grep ': obsolete-conffile' | sort -u
   xapps-common: obsolete-conffile /etc/X11/Xsession.d/80xapp-gtk3-module

of course, ideally, piuparts whould be modified to drop all of the "Package
purging left files on system" warnings, given that that's covered by adequate.

(fwiw, one can also run adequate as part of autopkgtest -- see
/usr/share/doc/adequate/README -- but that wouldn't detect obsolete conffiles,
as that requires an install/upgrade sequence, which is what piuparts does among
other things)


Thanks for your reply, I already know about this obsolete-conffile but 
is not possible solve it FWIK, is not removed but moved to another package:


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

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




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: lintian.debian.org off ?

[Fabio Fantoni]

Il 03/09/2024 20:05, Lucas Nussbaum ha scritto:

On 03/09/24 at 12:31 -0400, Louis-Philippe Véronneau wrote:

FYI, I opened an RT ticket asking DSA for a VM to host all of this.

Hi,

I still don't understand the long term strategy here.

UDD provides the same information. I recently did the work so that it is
properly indexed by search engines, see for example
https://www.google.com/search?q=archive-liberty-mismatch
(it will probably take some time to get indexed by other search engines)

What is the point in duplicating efforts?

Lucas

I don't see UDD in the result of the link above but 
https://lintian.club1.fr/tags/archive-liberty-mismatch.html as first result.


I saw lintian.club1.fr result also in other tags I searched recently but 
I never saw UDD if I remember good


I suppose it is common search on google (or other search engine), for 
example to see in some cases among the results also examples of packages 
that had this problem and solved it


be able to get as the first result, or at most among the first, a site 
that explains the Lintian tags, I think is of little importance what is


I think what is perhaps more of a problem are the old links that no 
longer work and it would be good to have them working again by pointing 
them to a new working site, it could also be UDD




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: lintian.debian.org off ?

[Fabio Fantoni]

Il 03/09/2024 21:17, Lucas Nussbaum ha scritto:

On 03/09/24 at 20:49 +0200, Fabio Fantoni wrote:

Il 03/09/2024 20:05, Lucas Nussbaum ha scritto:

On 03/09/24 at 12:31 -0400, Louis-Philippe Véronneau wrote:

FYI, I opened an RT ticket asking DSA for a VM to host all of this.

Hi,

I still don't understand the long term strategy here.

UDD provides the same information. I recently did the work so that it is
properly indexed by search engines, see for example
https://www.google.com/search?q=archive-liberty-mismatch
(it will probably take some time to get indexed by other search engines)

What is the point in duplicating efforts?

Lucas


I don't see UDD in the result of the link above but
https://lintian.club1.fr/tags/archive-liberty-mismatch.html as first result.

It's probably a matter of cache/propagation.


I saw lintian.club1.fr result also in other tags I searched recently but I
never saw UDD if I remember good

As I said I fixed indexation recently (previously it was disallowed in 
robots.txt).

Lucas


And about make old domain working again, even if just a redirect to UDD 
but pointing also to the selected tag?




OpenPGP_signature.asc
Description: OpenPGP digital signature

DEP5 and spdx shortname of license

[Fabio Fantoni]

Hi, spdx has an ever-increasing usage. Today trying reuse tool I tried 
to convert DEP5 d/copyright to REUSE.toml thinking a possible help to 
some project upstream, when license and copyright "management" is not 
good, converting from d/copyright (DEP5) which is better, for example 
with additional parts resulting from research done on files that were 
taken from other projects but did not contain headers with license and 
copyright.


I noticed that even though reuse supports DEP5 the short license names 
used by Debian (and partly by spdx but deprecated) were not supported.


So I wonder, is it possible to put in d/copyright DEP5 the short license 
names using the spdx ones?


I supposeeven using them by default in the future could help the 
contributors (especially the new ones)who already know and use spdx and 
maybe it could help them to reduce the time of creation and management 
of d/copyright files (unfortunately often long even using very useful 
tools like decopy, licensecheck and lrc). What do you think?




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: DEP5 and spdx shortname of license

[Fabio Fantoni]

Il 07/09/2024 22:56, Aurélien COUDERC ha scritto:

Hi Fabio,

Le samedi 7 septembre 2024, 21:43:35 CEST Fabio Fantoni a écrit :


So I wonder, is it possible to put in d/copyright DEP5 the short license
names using the spdx ones?

we’ve been doing that for KDE packages since upstream started tagging all 
source files with SPDX-License / SPDX-Copyright headers and so using SPDX 
license identifiers some years ago. See [1] for example.

While not strictly adhering to DEP-5 I consider it useful to have a 
machine-readable-with-SPDX-identifiers and I’m not sure how useful it is to try 
and translate upstream-provided SPDX identifiers into something else.

Our spec [2] already defines an equivalence rule between License-X and 
License-X.0 declarations for SPDX compatibility.
For what I’ve seen on the quite vast and diverse KDE source corpus we’d only 
need 2 additional equivalence rules to be added to matches what that upstream 
ships :
- equivalence between the + and -or-later suffixes (GPL-2+ / GPL-2.0-or-later)
- equivalence between MIT and Expat.


[1] 
https://salsa.debian.org/qt-kde-team/kde/plasma-workspace/-/blob/debian/experimental/debian/copyright
[2] 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name


Thanks for the information, about tools that help to create and check 
d/copyright are you experiencing problems?


I use a lot decopyand I found that there is this MR of 1 year ago not 
merged: https://salsa.debian.org/debian/decopy/-/merge_requests/4


it would be useful even if it didn't have spdx generation by default but 
at least as an option, I was wondering if there was something preventing 
the use of the spdx name but from the current responses it does not appear.


one more question, is there any tool/script to convert current 
d/copyright to spdx names?




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: DEP5 and spdx shortname of license

[Fabio Fantoni]

Il 08/09/2024 12:25, Aurélien COUDERC ha scritto:


Le 8 septembre 2024 09:38:00 GMT+02:00, Andrea Pappacoda  
a écrit :

Hi Aurélien,

On Sat Sep 7, 2024 at 10:56 PM CEST, Aurélien COUDERC wrote:

Our spec [2] already defines an equivalence rule between License-X and 
License-X.0 declarations for SPDX compatibility.
For what I’ve seen on the quite vast and diverse KDE source corpus we’d only 
need 2 additional equivalence rules to be added to matches what that upstream 
ships :
- equivalence between the + and -or-later suffixes (GPL-2+ / GPL-2.0-or-later)

There's already an equivalence in the SPDX spec, as described in "Annex D: SPDX license expressions"[1] (kind 
of. using the plus sign operator "+" is SPDX's general way of saying "this version or later", while 
"-or-later" is a special case only valid for GPL licenses, as described in [2] and [3]).

This means that you can use "GPL-3.0+" in debian/copyright and have it being 
valid both when interpreted as our format or as an SPDX expression.
GPL-3.0+ and GPL-3.0 are deprecated in spdx and from what I saw a tool 
using spdx consider them not valid

Thanks, interesting.

What I'd like to see is us updating *our* spec to have the equivalence the 
other way around and I can extract upstream provided SPDX licence identifiers 
while staying debian-machine-readable-copyright compliant.


spdx license list it's big and it keeps growing, I think this can help 
in some cases where searching among the Debian ones it is difficult to find


there are some cases where even the spdx list is not enough but I found 
a match in scancode-licensedb.aboutcode.org (now with 2197 licenses)


seems that someone tried to add scancode or integrate its detection in 
decopy (https://wiki.debian.org/JelmerVernooij/scancode) and that would 
be great if we could succeed





--
Aurélien





OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: DEP5 and spdx shortname of license

[Fabio Fantoni]

Il 08/09/2024 07:38, Jonas Smedegaard ha scritto:

[CC'ing Fabio as they seemingly missed my earlier list-only reply]

Quoting Fabio Fantoni (2024-09-07 23:57:35)

Il 07/09/2024 22:56, Aurélien COUDERC ha scritto:

Le samedi 7 septembre 2024, 21:43:35 CEST Fabio Fantoni a écrit :

So I wonder, is it possible to put in d/copyright DEP5 the short license
names using the spdx ones?

we’ve been doing that for KDE packages since upstream started tagging all 
source files with SPDX-License / SPDX-Copyright headers and so using SPDX 
license identifiers some years ago. See [1] for example.

While not strictly adhering to DEP-5 I consider it useful to have a 
machine-readable-with-SPDX-identifiers and I’m not sure how useful it is to try 
and translate upstream-provided SPDX identifiers into something else.

Our spec [2] already defines an equivalence rule between License-X and 
License-X.0 declarations for SPDX compatibility.
For what I’ve seen on the quite vast and diverse KDE source corpus we’d only 
need 2 additional equivalence rules to be added to matches what that upstream 
ships :
- equivalence between the + and -or-later suffixes (GPL-2+ / GPL-2.0-or-later)
- equivalence between MIT and Expat.


[1] 
https://salsa.debian.org/qt-kde-team/kde/plasma-workspace/-/blob/debian/experimental/debian/copyright
[2] 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name

Thanks for the information, about tools that help to create and check
d/copyright are you experiencing problems?

You might already be aware, but (also for others following along) an
overview of tools is maintained here:
https://wiki.debian.org/CopyrightReviewTools



I use a lot decopyand I found that there is this MR of 1 year ago not
merged: https://salsa.debian.org/debian/decopy/-/merge_requests/4

it would be useful even if it didn't have spdx generation by default but
at least as an option, I was wondering if there was something preventing
the use of the spdx name but from the current responses it does not appear.

Licensecheck can use strictly SPDX shortnames like this:

licensecheck --shortname-scheme spdx --check '.*' --recursive --deb-machine 
--lines 0 -- *

...or more relaxed use fallbacks for patterns without SPDX shortname:

licensecheck --shortname-scheme spdx,debian,internal --check '.*' --recursive 
--deb-machine --lines 0 -- *

If you want another output than the DEP5 file format implied by the
option --deb-machine (e.g. one that includes hashes for each file, never
shortening file lists with wildcards) then please file a bugreport
against licensecheck and let's discuss that in detail there:
https://www.debian.org/Bugs/Reporting


one more question, is there any tool/script to convert current
d/copyright to spdx names?

See to tools at https://wiki.debian.org/CopyrightReviewTools and please
update that list if you find additional tools helpful.


Thanks for interest in copyright and licensing tracking,

  - Jonas


Thanks for your reply and information, I already saw that wiki page.

Overall the tool I used the most as a base from which to start creating 
or updating d/copyright is decopy, then manual changes are always required.


Initially if I remember correctly I didn't use any tools but I made rare 
manual changes to the d/copyright, later I used decopy suggested by Maxy 
and Marga who taught me a lot about packaging in the early years.


A few years ago (to try to reduce the times) I had tried several other 
tools, I don't remember exactly all which ones, but mainly looking at 
the list from the wiki page, I didn't find anything better and the only 
decent one that could be useful in some cases was licensecheck.


Recently I retried to look about the tool and I found lrc (licenserecon) 
that seems useful in identifying some missing or incorrect entries.



I did some tests using spdx short name, but seems that currently the 
tools are not good enough to be able to manage them well (in total) and 
it would take more time than the debian names.


If they were well supported instead it could save some time in some 
cases to identify the licenses and I suppose it would be easier and 
faster also for new maintainers who already know/use the spdx names, 
rather than learning the debian ones and the various differences.


licensecheck even if with "--shortname-scheme spdx,debian" seems show 
some debian name where can show spdx instead, with only spdx is probably 
good but i haven't tested it enough


licenserecon don't support spdx name so show entries with correct 
license but spdx name as difference


decopy don't support spdx name in DEP5 output produced but there is a MR 
of 1 year ago


I'll see if Aurélien COUDERC or someone else from the KDE team who uses 
spdx names will answer me to know what tools they use



I tried also scancode-toolkit after saw that it have a very big license 
list (more that spdx), support

Bug#1038946: ITP: xdg-desktop-portal-xapp -- Xapp's Cinnamon, MATE and Xfce backends for xdg-desktop-portal

[Fabio Fantoni]

Package: wnpp
Severity: wishlist
Owner: Fabio Fantoni 
X-Debbugs-Cc: debian-devel@lists.debian.org, fantonifa...@tiscali.it

* Package name    : xdg-desktop-portal-xapp
  Version : 1.0.1
  Upstream Contact: Linux Mint Project 
* URL : https://github.com/linuxmint/xdg-desktop-portal-xapp
* License : GPL-2+ and LGPL-2+ and LGPL-2.1+
  Description : Xapp's Cinnamon, MATE and Xfce backends for 
xdg-desktop-portal



I'll package it under the debian cinnamon team:
https://salsa.debian.org/cinnamon-team/xdg-desktop-portal-xapp

Re: Debian 13 release schedule and Debian 15 codename announcement

[Fabio Fantoni]

Il 05/07/2023 22:50, Joaquín Rufo Gutierrez ha scritto:
|Hello Debian users, We are happy to announce that Debian 13, 
codenamed "Trixie", is expected to be released sometime in 2024, 
following the usual 2-year release cycle.|


|
|

|Hi, sorry but if it were |||2-year release cycle | shouldn't it be 
released in 2025 instead?|


|
|

||

|The exact release date will depend on the progress of testing and bug 
fixing, but we will keep you updated on the development status. As 
part of the release process, we have planned the following freeze 
dates: - Toolchain freeze: January 19, 2024 - Soft freeze: February 
19, 2024 - Hard freeze: March 18, 2024 - Full freeze: To be announced 
Please refer to https://release.debian.org/trixie/freeze_policy.html 
for more details on what each freeze means and how to prepare your 
packages for the release. We would also like to reveal the codename of 
Debian 15, which will be "Buttercup". This name follows the tradition 
of naming Debian releases after characters from the Toy Story movies. 
We hope you like it and look forward to your contributions to make 
Debian 15 another great release. Thank you for your support and 
enthusiasm for Debian. Sincerely, Joaquín Rufo Gutierrez Debian 
Release Team|





OpenPGP_signature
Description: OpenPGP digital signature

Re: Signature strength of .dsc

[Fabio Fantoni]

Il 01/12/2023 01:20, Dimitri John Ledkov ha scritto:

Hi,

Currently dak requires signatures on .changes & .dsc uploads. .changes 
with signatures are publicly announced and then .dsc are published in 
the archive with signatures. .changes references .dsc.


All .dsc have Checksums-Sha256 for the files they reference, .dsc 
itself can be verified through strong checksum in Sources metadata, 
chained via InRelease to the strong debian archive key signature.


The same is not true for signatures on .dsc themselves. Majority of 
.dsc use at least sha256 and can be successfully verified.


But some use weak hash:
5 dsc signed using Hash: RIPEMD160
152 dsc signed using Hash: SHA1

And many of them cannot be verified using debian-keyring:
2,455 no public key


hi, on "no public key" list there are my uploads, I'm debian maintainer 
(https://nm.debian.org/person/fantu/), I signed with my key and I have 
DM upload right for them 
(https://qa.debian.org/developer.php?login=fantonifabio%40tiscali.it)


I did something wrong that I don't know?


3 wrong key usage

Lists of affected .dsc are published at 
https://people.canonical.com/~xnox/dsc-analysis/ due to size.


This makes me wonder if signatures on uploaded or published .dsc have 
any value at all.
Ultimately one should use apt secure to retrieve both .deb and .dsc; 
and verify .changes signature if one wants to figure out authorship.


Should we upload sourceful NMU to eliminate SHA1, RIPEMD160, 
wrong-key-usage signatures in .dsc?


Should we stop requiring signed .dsc on uploads?

--
Regards,

Dimitri.





OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: 64-bit time_t transition in progress

[Fabio Fantoni]

Il 02/02/2024 17:43, Steve Langasek ha scritto:

Hello,

debian-devel-announce wouldn't let me attach the file, but for those on
debian-devel at least, you can find the dd-list of to-be-NMUed source
packages attached.

Thanks,


Sorry to bother you (or anyone else who wants to answer) with a question 
that might be stupid, maybe I didn't understand something.


From what I understand, for most of the packages involved a rebuild is 
enough but this rebuild must be done after that of all their 
dependencies (dependencies of dependencies etc...) involved to avoid 
unexpected events that could cause crashes on some architectures (in 
cases ABI changes occurred in the underlying dependencies but the 
rebuild was done before one of those).


Having a package that depends on many and that part of those are 
themselves involved in various other chains, how do NMU (when needed) to 
unstable and rebuilds of other packages happen?


A single NMU on unstable or rebuild (for each package involved) but with 
such an order so that when it is done all dependencies are already 
rebuild, or with multiple rebuilds between the various migration chains 
involved?


Thanks for any reply and sorry for my bad english.



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: lazarus is marked for autoremoval from testing

[Fabio Fantoni]

Il 13/02/2024 08:06, Abou Al Montacir ha scritto:

Hi All,

On Tue, 2024-02-13 at 04:39 +, Debian testing autoremoval watch wrote:

lazarus 3.0+dfsg1-6 is marked for autoremoval from testing on 2024-03-13

It is affected by these RC bugs:
1061034: lcl-utils-3.0: lcl-utils-3.0 Missing dependencies for lazbuild
https://bugs.debian.org/1061034

I really don't understand this message.
the bug was fixed and is marked as so in the BTS.
I also have 3 other bugs already fixed, but preventing migration to 
testing for more than 8 days.


What' wrong with BTS since a few days? Is there a bug, or the 
procedure to fix bugs changed?


Other bugs preventing migration according to 
https://tracker.debian.org/pkg/lazarus:
 Updating lazarus would introduce bugs in testing: #1060932 
, #1060995 
, #1061009 



--
Cheers,
Abou Al Montacir


I see a your request to remove completely from Debian: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063475


If you want migrate to testing I suppose the RM request is wrong and 
must be closed.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: finally end single-person maintainership

[Fabio Fantoni]

Il 08/04/2024 15:45, Julien Puydt ha scritto:

Hi

Le lun. 8 avr. 2024, 14:45, Simon Richter  a écrit :

The web interface presented by salsa also does not have the necessary
data<->metadata filters to provide an actual insight into what is
really
happening in the repository.


It's been several times already some people complain about salsa 
because of its web interface.


I only use salsa's git. That begs two questions:
- What do I miss by not using the web interface?
- What does that web interface have that people don't like?
Hi, I use salsa git for all packages I mantain and is good, 
unfortunately, however, many times it is slow or temporarily fails (I 
suppose because it is overloaded) and this I suppose could discourage 
its use a bit.


Cheers,

J.Puydt





OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: How to contribute ?

[Fabio Fantoni]

Il 01/01/2022 03:31, Leandro Cunha ha scritto:

Hi,

On Tue, Dec 21, 2021 at 4:06 PM Maxime Lombard  wrote:

Hello,

I'm an user of Debian since 10 years ago and it's only now that i decide to 
help to packaging.
I send this email about wine and wine-development package which are not updated 
since a very long time.

The last wine stable version on Sid is the 5.0 and development version is 
6.0+repack. Currently, the wine source code is frozen and the new stable 
version 7.0 will release next month.
--> I sent email to Michael Gilbert (without answer from him) and open a bug 
report recently to update package.

Same thing with vkd3d package 1.2 which is still in "experimental" since a long 
time too.
I think it's not in Unstable because the test fail with mesa-vulkan-driver >= 
21 (see changelog)
--> I open a bug report upstream about this failure (see 
https://bugs.winehq.org/show_bug.cgi?id=52248). Is it possible to build the 
package without to do test (set --disable-tests to configure) ?

Nowadays, the last package of wine-development was uploaded ~6 months ago. More 
bugs report opened the last months have no answer from Maintainer (999753, 
995580), same thing with vkd3d bug (994186, 993570)

I packaged myself vkd3d 1.2-7  and wine-development 7.0~rc2 and all works 
correctly.
I updated debian folder for wine to prepare the next Stable version.

My question is, how to contribute and hope to have updated version of this 
package in Debian since I am a novice ?

Thanks for your answer,
Maxime

Yes, there are some packages that haven't been updated for a while.
One of them is the retroarch that next year completes its second without
updates and the chromium.
And I believe it is open to anyone who wants to contribute.
There are some processes such as ITS, NMU, QA (orphan packages) and team
upload (for packages kept in teams where it is necessary to work with
someone on the team or be part of the team).

I usually help with QA work and team uploads. But I did deal with ITS once.

Full reference on this.
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#managing-packages
https://www.debian.org/devel/wnpp
https://wiki.debian.org/WNPP
https://wnpp.debian.net

I remember thinking that it was necessary to be a DM or DD to
contribute to Debian
and over time I realized I was wrong.


I also contributing for 7 years only via git (alioth and salsa) without 
being DM but in some cases as I have seen recently with debian-cinnamon 
packages where when this year in the team there was some months with no 
DD/DM (with upload permission) active it was difficult to find someone 
who sponsored the uploads (with the major versions there are up to 15-16 
components to be uploaded at the same time) the work prepared took up to 
a month to be uploaded (now the problem has just been solved)


@Maxime: So probably if you start contributing regularly I think it is 
better that you start creating an account on https://nm.debian.org/ and 
create a gpg key with which to sign the work done to speed up a possible 
transition to DM in the future if situations such as mine will happen 
(moreover in a period with particular other unforeseen events, including 
above all the coronavirus that complicate things)


about disabling tests try to add an override to debian/rules:


override_dh_auto_test:
: # disable it
In any case big thanks for your help improving/updating packages, wine I 
had already seen that it would need help and it would be useful to also 
have the latest stable versions in the backports (only if there is 
really enough time after updating / improving the packages) but 
unfortunately I don't have enough time to contribute to those too




Happy 2022! ;)





OpenPGP_signature
Description: OpenPGP digital signature

on debomatic-*.debian.net unable to build bullseye and bullseye-backports

[Fabio Fantoni]

Hi, I use debomatic-*.debian.net for some years and is very useful for 
testing packages quickly (including installing for testing on many 
devices easy and fast), it also helped me to solve build problems on 
architectures that I don't have devices for (for example ppc64el and s390x).


Actually is not possible build for bullseye and bullseye-backports, I 
wrote a mail to Luca Falavigna (dktrkranz) but in latest months didn't 
replied me.


Is there someone else who has access to those servers and can please fix?

I suppose that conf files used in these servers are stored here: 
https://github.com/debomatic/instances and from a fast look the 
distributions one should be updated (like what was done in latest 
debomatic 
https://github.com/debomatic/debomatic/blob/master/etc/debomatic/distributions) 
and also "mapper" field updated on debomatic conf file (in the instances 
repository is under architectures)


Thanks for any reply and sorry for my bad english



OpenPGP_signature
Description: OpenPGP digital signature

Re: on debomatic-*.debian.net unable to build bullseye and bullseye-backports

[Fabio Fantoni]

Il 23/03/2022 11:35, Paul Wise ha scritto:

On Wed, 2022-03-23 at 11:13 +0100, Fabio Fantoni wrote:


Is there someone else who has access to those servers and can please fix?

AFAIK Luca Falavigna is the only one with access.

There are alternatives to the debomatic hardware listed here:

https://wiki.debian.org/Hardware/Wanted#Available_hardware


thanks for reply

I did a local debomatic server, did and tested the changes to fix 
bullseye/stable build and add bullseye-backports and prepared a PR to 
make faster update them: https://github.com/debomatic/instances/pull/10




OpenPGP_signature
Description: OpenPGP digital signature

Re: on debomatic-*.debian.net unable to build bullseye and bullseye-backports

[Fabio Fantoni]

Il 24/03/2022 13:19, Fabio Fantoni ha scritto:

Il 23/03/2022 11:35, Paul Wise ha scritto:

On Wed, 2022-03-23 at 11:13 +0100, Fabio Fantoni wrote:

Is there someone else who has access to those servers and can please 
fix?

AFAIK Luca Falavigna is the only one with access.

There are alternatives to the debomatic hardware listed here:

https://wiki.debian.org/Hardware/Wanted#Available_hardware


thanks for reply

I did a local debomatic server, did and tested the changes to fix 
bullseye/stable build and add bullseye-backports and prepared a PR to 
make faster update them: https://github.com/debomatic/instances/pull/10


Luca Falavigna merged the commit and updated the debomatic-*.debian.net 
servers (big thanks to him), now also bullseye and bullseye-backports 
are working (info for other people that use them)




OpenPGP_signature
Description: OpenPGP digital signature

Re: Project Improvements

[Fabio Fantoni]

Il 23/05/2022 01:42, Glauber Baldez ha scritto:

Some considerations for project improvement:

1. Debian should already offer users a minimal installation mode 
similar to Ubuntu, without media players, games and office applications.


2. Debian should follow Doug Gwyn's words in stating that Unix was not 
designed to stop its users from doing stupid things, as that would 
also stop them from doing smart things; the operating system must 
trust the user. Writing this, a big problem is not knowing how to 
differentiate the desktop environment from desktop applications, 
treating these factors as if they were the same thing. For example, 
the user cannot be prevented from removing the default web browser 
(desktop application) to replace it with another one of their choice 
as this breaks the desktop environment. Where's the freedom? I repeat 
again: desktop environment and desktop applications are not the same 
thing, so they shouldn't be treated as such either.


Hi, thanks for your mail with suggestion to improve the project.

I'm one maintainer of the cinnamon team, in the years I did some changes 
to make possible to have minimal installation of cinnamon. cinnamon (the 
package) without recommends is the very minimal. In some cases users had 
reported changes that had added unnecessary packages to the dependencies 
that I had then modified or removed and made some tests both on debian 
and ubuntu but unfortunately I can not do them often because they take a 
long time (both installation and quick functional tests) so report or 
advice from users are always useful.


cinnamon-core and cinnamon-desktop-environment are 2 metapackage, the 
first for minimal desktop environment and second full. In the full one 
there are browser, media player and mail client are depends (libreoffice 
instead is already in recommends), one users recently required to remove 
browser and media player from depends but I added some alternative 
instead (in 5.2.2) thinking that are "essential software" for a full DE 
metapackage without recommends.


I was wrong and I should move them to the recommends? Any 
reply/suggestion from other maintainers or users is appreciated. Sorry 
for my bad english.




I hope these proposals will be taken into account and discussed by the 
developer team.


Good luck to the project and everyone.





OpenPGP_signature
Description: OpenPGP digital signature

Re: Project Improvements

[Fabio Fantoni]

Il 25/05/2022 10:33, Paul van der Vlis ha scritto:

Op 23-05-2022 om 13:00 schreef Fabio Fantoni:

Il 23/05/2022 01:42, Glauber Baldez ha scritto:

Some considerations for project improvement:

1. Debian should already offer users a minimal installation mode 
similar to Ubuntu, without media players, games and office 
applications.


2. Debian should follow Doug Gwyn's words in stating that Unix was 
not designed to stop its users from doing stupid things, as that 
would also stop them from doing smart things; the operating system 
must trust the user. Writing this, a big problem is not knowing how 
to differentiate the desktop environment from desktop applications, 
treating these factors as if they were the same thing. For example, 
the user cannot be prevented from removing the default web browser 
(desktop application) to replace it with another one of their choice 
as this breaks the desktop environment. Where's the freedom? I 
repeat again: desktop environment and desktop applications are not 
the same thing, so they shouldn't be treated as such either.


Hi, thanks for your mail with suggestion to improve the project.

I'm one maintainer of the cinnamon team, in the years I did some 
changes to make possible to have minimal installation of cinnamon. 
cinnamon (the package) without recommends is the very minimal. In 
some cases users had reported changes that had added unnecessary 
packages to the dependencies that I had then modified or removed and 
made some tests both on debian and ubuntu but unfortunately I can not 
do them often because they take a long time (both installation and 
quick functional tests) so report or advice from users are always 
useful.


cinnamon-core and cinnamon-desktop-environment are 2 metapackage, the 
first for minimal desktop environment and second full. In the full 
one there are browser, media player and mail client are depends 
(libreoffice instead is already in recommends), one users recently 
required to remove browser and media player from depends but I added 
some alternative instead (in 5.2.2) thinking that are "essential 
software" for a full DE metapackage without recommends.


I was wrong and I should move them to the recommends? Any 
reply/suggestion from other maintainers or users is appreciated. 
Sorry for my bad english.


In my opinion it would be better to use recommends.

I like to use a mail client myself, but many people want to use 
webmail these days for example. And many people don't use an IM client.
you are right, I also have many customers who only use webmail (and I 
had underestimated them) and IM client installed also seem much less 
used recently


Some people like to install a browser from outside Debian, like "Brave 
Browser" or a flatpack with the latest Firefox.
in fact more and more users are using other browsers or browsers from 
flatpack (or others like snap)


Such a meta-package is good to install many packages at once, but it 
would be nice to have the possibility to remove them individually.
also this is right but it seems to me better that some packages still 
remain as dependencies by calculating other cases, for example as those 
who do a "lighter installation" without recommends, but that does not 
become "too small" to make the meta package not useful for that part of 
users


I support many people with Debian, what I often see is that they 
remove a package, and then also the meta-package is removed. 
And later all dependencies of the meta-package are removed by accident.

this is not in all cases, David Kalnischkies explained in his reply


Just my 2 cents...


thanks for your mail

about cinnamon-desktop-environment for next version I moved browsers, 
mail clients, media players and instant messaging clients from depends 
to recomends, I also thought about the pdf viewer a bit but for now I 
think it's better that it stays in the dependencies. while the rest of 
the dependencies seem to me to be quite used, generally relevant and/or 
with too few users that I suppose they would like to remove to move them 
to recommends. any other advice, data or considerations are appreciated




With regards,
Paul






OpenPGP_signature
Description: OpenPGP digital signature

Re: GSConnect GNOME Shell extension package

[Fabio Fantoni]

Il 28/06/2022 07:04, Bruno Kleinert ha scritto:

Hi,

I had begun packaging GSConnect 
https://extensions.gnome.org/extension/1319/gsconnect/ some months 
ago. It's the GNOME equivalent of KDE Connect and integrates some 
functions of Android devices into the GNOME desktop environment.


I used the package for a week, then lost interest in it. If somebody 
wants to maintain it, feel free to pick it up!


The packaging is here: 
https://salsa.debian.org/fuddl/gnome-shell-extension-gsconnect


As of today, no WNPP bug exists. If you pick it up, please create an 
ITP bug.


Cheers,
Bruno


Thanks for your works, gsconnect seems interesting, I suppose you should 
ask to gnome team if they want add it starting from your works.




OpenPGP_signature
Description: OpenPGP digital signature

Re: Bug#1013992: ITP: session-migration -- tool to migrate in user session settings

[Fabio Fantoni]

Il 29/06/2022 03:51, Jeremy Bicha ha scritto:

On Tue, Jun 28, 2022 at 8:07 PM Guillem Jover  wrote:

Package: session-migration
Description: Tool to migrate in user session settings
  This tool is used to migrate in session user data when a program is evolving
  its configuration, or needing to have files moved and so on.
  .
  This program is generally autostarted at the very beginning of the session
  and integrates caching capability.

This looks like an extremely generic name for such tool and package,
when it appears to be restricted to gsettings session data only?

It is not restricted to gsettings although gsettings is a good use case for it.

Here's an example where it's used for something else:
https://salsa.debian.org/gnome-team/gnome-boxes/-/commit/b536a968eb192

It would be nice if the upstream developers would handle user session
migrations tasks themselves, but they often don't.


Hi, this seems really interesting, can be useful in some rare cases, I 
don't remember I've ever seen it before.


However, I have a doubt, but it allow you to do any operation on user 
profiles? in this case, even if it is useful, its wrong use (intentional 
or by mistake) would be worrying





Package: dh-migrations
Provides: dh-sequence-migrations
Description: debhelper extension for session-migration support
  This package provides a debhelper extension to perform session migration
  operations on the installed packages.

This also seems extremely generic. Migrations could refer to anything,
from databases, to any other data source. Something like
dh-gsettings-migrations seems like would be way better?

Despite being around for a decade, it looks like it's only used by
about 6 current Ubuntu source packages so a rename is doable if
needed. I think I wouldn't even need a transitional package since we'd
rebuild all those Ubuntu packages which would get them the properly
named dependency.

Here's a suggestion:
user-session-migration
dh-migrate-user-session Providing dh-sequence-migrate-user-session

Thank you,
Jeremy Bicha





OpenPGP_signature
Description: OpenPGP digital signature

Re: Automatic trimming of changelogs in binary packages

[Fabio Fantoni]

Il 19/08/2022 03:01, Paul Wise ha scritto:

On Thu, 2022-08-18 at 21:18 +0200, Gioele Barabucci wrote:


Does anybody have objective objections against activating automatic
changelog trimming in binary packages?

Before we consider enabling this by default, first we need a way for
`apt changelog` to download the full changelog rather than loading the
changelog from /usr/share/doc in the currently installed package.

Otherwise people who want to look at the full changelog for the
currently installed version of the package will have no easy way to do
so. They will have to manually find it instead, which isn't exactly an
easy process if you do not know where the changelogs are stored online.

Hi, I also used the changelog many times both in the packages I maintain 
and in the one I only use, in some cases a very old changelog entries 
was needed.


I also think a simply, fast and know way to look that full changelog is 
needed.


I also use many times the changelog view on packages.debian.org, it show 
the full changelog from source and will still show the full changelog?




OpenPGP_signature
Description: OpenPGP digital signature

Re: Automatic trimming of changelogs in binary packages

[Fabio Fantoni]

Il 19/08/2022 09:43, julien.pu...@gmail.com ha scritto:

Le vendredi 19 août 2022 à 09:04 +0200, Fabio Fantoni a écrit :

Il 19/08/2022 03:01, Paul Wise ha scritto:

On Thu, 2022-08-18 at 21:18 +0200, Gioele Barabucci wrote:


Does anybody have objective objections against activating
automatic
changelog trimming in binary packages?

Before we consider enabling this by default, first we need a way
for
`apt changelog` to download the full changelog rather than loading
the
changelog from /usr/share/doc in the currently installed package.

Otherwise people who want to look at the full changelog for the
currently installed version of the package will have no easy way to
do
so. They will have to manually find it instead, which isn't exactly
an
easy process if you do not know where the changelogs are stored
online.


Hi, I also used the changelog many times both in the packages I
maintain
and in the one I only use, in some cases a very old changelog entries
was needed.

As long as "apt-get source" gives the whole d/changelog as well as
d/rules, d/control and everything, I think this objection is out.

Why put rarely-used information in each and every installation of our
_users_?


Thanks for reply, I also think that trimming changelog in binaries is 
useful to save disk space and a little bit of bandwidth/time (when 
downloading thanks to smaller packages)


What I mean was only have a fast/easy/know to view the full changelog 
before make trimming the default.


About "apt-get source" need add of deb-src in source.list, download the 
full source of the package and some operations so is not optimal, "apt 
changelog" that download and view the full changelog by default as I saw 
in previous replies seems a good solution




Cheers,

J.Puydt





OpenPGP_signature
Description: OpenPGP digital signature

Bug#842335: ITP: mint-themes -- A collection of Mint themes

[Fabio Fantoni]

Followup-For: Bug #842335
Package: wnpp
X-Debbugs-Cc: debian-devel@lists.debian.org
Owner: Fabio Fantoni 
Control: block -1 by 842338
Control: retitle -1 ITP: mint-themes -- A collection of Mint themes

* Package name    : mint-themes
  Version : 2.0.5
* URL : https://github.com/linuxmint/mint-themes
* License : GPL-3+
  Description : A collection of Mint themes

I'll package it under the debian cinnamon team:
https://salsa.debian.org/cinnamon-team/mint-themes



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022236: ITP: mint-x-icons -- Mint-X icon theme

[Fabio Fantoni]

Package: wnpp
Severity: wishlist
Owner: Fabio Fantoni 
X-Debbugs-Cc: debian-devel@lists.debian.org, fantonifa...@tiscali.it

* Package name    : mint-x-icons
  Version : 1.6.4
* URL : https://github.com/linuxmint/mint-x-icons
* License : GPL-3+
  Description : Mint-X icon theme
A mint/metal theme based on mintified versions of
Clearlooks Revamp, Elementary and Faenza.


Together with mint-y-icons (recently added in debian) is required by 
mint-themes.


Requested by some users over the years.
Some users already use them installing the packages from mint repository 
or from sources.
I therefore thought it would be better to add them in the debian repo as 
well to make them installable in a simpler and faster way to those who 
want them.


I'll package it under the debian cinnamon team:
https://salsa.debian.org/cinnamon-team/mint-x-icons



OpenPGP_signature
Description: OpenPGP digital signature

Re: ITP: misk -- Miscellaneous useful bits for python 3

[Fabio Fantoni]

Il 08/11/2022 15:20, Lance Lin ha scritto:

Package: wnpp
Severity: wishlist
Owner: Lance Lin 
X-Debbugs-Cc: debian-devel@lists.debian.org, lqi...@protonmail.com

* Package name: python3-misk
   Version : 0.7.1
   Upstream Author : Mark Gillard 
* URL : https://github.com/marzer/misk
* License : MIT
   Programming Lang: Python
   Description : Miscellaneous useful bits for python 3

This is a prerequisite package for 'poxy' which is in the RFP list.


I plan to join the Python team and maintain misk there.

Lance Lin 
GPG Fingerprint:  4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7


Hi, an ITP of misk was already opened: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023657


I suggest to look it and wrote to other people to avoid a waste of time 
in "double" work




OpenPGP_signature
Description: OpenPGP digital signature

Re: [DEVEL] Enable support for Renesas platform

[Fabio Fantoni]

Il 18/11/2022 09:20, Huỳnh Thành Hưng ha scritto:

Dear Debian-developer,

I’m from Renesas Electronics Corporation,

My group is developing to support running Debian OS on our devices, 
also for getting ARM System Ready IR certificate.


I recognize that the latest Debian 11 (Bullseye) has the kernel which 
do not enable support for Renesas platform.


  * *linux-image-5.10.0-18-arm64_5.10.140-1_arm64.deb*

Can you help me to enable those configs, also support the official 
release version of Debian Live Installer ISO which support Renesas 
platform?


Hi, thanks for your work, having "out of the box" support on other ARM 
devices I think would be a great thing.
I unfortunately saw years ago when I tried several ARM devices for work, 
before choosing what to use for thin clients that the support was 
lacking and it took me a long time to prepare a system to use
In recent years I've seen more interest in integrating upstream (mainly 
the kernel) and having more support in distributions to make it easier 
and faster for users to use them


A first step is enable it in the kernel as you saw, add in stable 
version is not possible FWIK but should be added in unstable before 
(later, once added and migrated to testing, it will instead be possible 
to have it in the backports), if it will be added before the approaching 
freeze there is a chance it will be added in debian 12


looking at latest version of kernel packaging for experimental in arm64 
config about renesas boards seems not present and I don't see an MR for 
add it: https://salsa.debian.org/kernel-team/linux


probably can be useful see other contacts related to ARM port (mailing 
list, irc, debian developers working on arm on debian) here: 
https://www.debian.org/ports/arm/


I'm not a maintainer of the ARM part, kernel, bootloader and installer 
but I hope you will be able to find someone who can help you and that we 
can have a further improvement in the ARM devices support


I classify the defconfig, also classify the new kernel module to 
support our devices.


  * For new kernel defconfig:

CONFIG_ARCH_RENESAS=y

CONFIG_SOC_RENESAS=y

CONFIG_ARCH_RCAR_GEN3=y

CONFIG_ARCH_R8A774A1=y

CONFIG_RST_RCAR=y

CONFIG_SYSC_RCAR=y

CONFIG_SYSC_R8A774A1=y

CONFIG_RENESAS_IRQC=y

CONFIG_RAVB=y

CONFIG_SERIAL_SH_SCI=y

CONFIG_CLK_RCAR_GEN3_CPG=y

CONFIG_CLK_RENESAS_CPG_MSSR=y

CONFIG_CLK_RENESAS_DIV6=y

CONFIG_CLK_RCAR_USB2_CLOCK_SEL=y

CONFIG_PINCTRL_RENESAS=y

CONFIG_PINCTRL_SH_PFC=y

CONFIG_PINCTRL_PFC_R8A774A1=y

CONFIG_RCAR_THERMAL=y

CONFIG_RCAR_GEN3_THERMAL=y

CONFIG_RENESAS_DMA=y

CONFIG_RCAR_DMAC=y

CONFIG_PCIE_RCAR=y

CONFIG_PCIE_RCAR_HOST=y

CONFIG_SYS_SUPPORTS_SH_CMT=y

CONFIG_SYS_SUPPORTS_SH_TMU=y

CONFIG_SH_TIMER_CMT=y

CONFIG_SH_TIMER_TMU=y

CONFIG_RENESAS_OSTM=y

CONFIG_IPMMU_VMSA=y

CONFIG_COMMON_CLK_VC5=y

CONFIG_MMC_TMIO_CORE=m

CONFIG_MMC_SDHI=m

CONFIG_MMC_SDHI_INTERNAL_DMAC=m

CONFIG_MMC_SDHI_SYS_DMAC=m

CONFIG_RENESAS_USB_DMAC=m

CONFIG_I2C_RCAR=m

CONFIG_GPIO_RCAR=m

CONFIG_VIDEO_RENESAS_FCP=m

CONFIG_VIDEO_RENESAS_VSP1=m

CONFIG_VIDEO_RCAR_CSI2=m

CONFIG_VIDEO_RCAR_VIN=m

CONFIG_DRM_RCAR_DU=m

CONFIG_DRM_RCAR_CMM=m

CONFIG_DRM_RCAR_DW_HDMI=m

CONFIG_DRM_RCAR_LVDS=m

CONFIG_PHY_RCAR_GEN3_USB2=m

CONFIG_PHY_RCAR_GEN3_USB3=m

CONFIG_USB_XHCI_RCAR=m

CONFIG_USB_RENESAS_USBHS=m

CONFIG_USB_RENESAS_USBHS_HCD=m

CONFIG_USB_RENESAS_USBHS_UDC=m

CONFIG_USB_RENESAS_USB3=m

CONFIG_PWM_RCAR=m

CONFIG_SPI_SH_MSIOF=m

CONFIG_SND_SOC_RCAR=m

CONFIG_CAN_RCAR=m

CONFIG_CAN_RCAR_CANFD=m

CONFIG_RENESAS_WDT=y

  * For new kernel modules to be installed in
*linux-image-5.10.0-18-arm64_5.10.140-1_arm64.deb*
  o *I2C Common:*
  + drivers/i2c/*.ko
  o *Renesas I2C: depend on I2C Common*
  + drivers/i2c/busses/i2c-rcar.ko
  o *Renesas GPIO:*
  + drivers/gpio/gpio-rcar.ko
  o *Renesas SDHI:*
  + drivers/mmc/host/tmio_mmc_core.ko
  + drivers/mmc/host/renesas_sdhi_core.ko
  + drivers/mmc/host/renesas_sdhi_internal_dmac.ko
  + drivers/mmc/host/renesas_sdhi_sys_dmac.ko
  o *V4L2 Common driver:*
  + drivers/media/common/videobuf2/*.ko
  + drivers/media/v4l2-core/*.ko
  + drivers/media/mc/mc.ko
  o *Renesas video device: depend on "V4L2 Common driver"*
  + drivers/media/platform/rcar-fcp.ko
  + drivers/media/platform/vsp1/vsp1.ko
  o *Renesas display: depend on "Renesas video device"*
  + drivers/gpu/drm/rcar-du/*.ko
  o *Renesas USB:*
  + drivers/phy/renesas/phy-rcar-gen3-usb2.ko
  + drivers/phy/renesas/phy-rcar-gen3-usb3.ko
  + drivers/usb/renesas_usbhs/renesas_usbhs.ko
  + drivers/usb/gadget/udc/renesas_usb3.ko
  o *Realtek driver:*
  + drivers/net/phy/realtek.ko
  + drivers/net/mdio/mdio-mux.ko
  o *Renesas CAN/CANFD*
  + drviers/net/can/rcar/rcar_can.ko
  + drviers/net/can/rcar/rcar_canfd.ko
  o *Renesas SPI/MSIOF*
  + drivers/spi/spi-sh

Re: GnuPG 2.4 before Trixie freeze

[Fabio Fantoni]

Il 24/09/2024 14:43, Stephan Verbücheln ha scritto:

Hello everyone

Debian Trixie and Sid still have GnuPG 2.2.x. GnuPG 2.4.5 is available
in Experimental.
GnuPG 2.4.0 was released on December 20, 2022. The 2.4.x series has
various useful new features such as TPM support.


Is it realistic to get GnuPG 2.4 into Trixie before the freeze?

What is missing for acceptance into unstable/testing?

Regards
Stephan


You can search bugs related to 2.4 and looking into them for possible 
information, for example from a very fast look this seems one:


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: DEP-18 v2: request for comments

[Fabio Fantoni]

Il 18/11/2024 01:04, Otto Kekäläinen ha scritto:

Hi all,

I published a complete rewrite of the earlier draft as:

 https://salsa.debian.org/dep-team/deps/-/merge_requests/12
 DEP-18: Encourage Continuous Integration and Merge Request
 based Collaboration for Debian packages

If you are in favor of having this as a DRAFT in the DEP directory,
please give it a thumbs up.

Summary of previous discussion below, but an even better summary was
written by LWN in https://lwn.net/Articles/986480/

Related to Salsa in general, I heard we have now new and faster
hardware (thanks Salsa Admins!), and related to Salsa CI there is also
an overhauled README
(https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/README.md)
and lots of fixes by 7 different authors. I think a lot of people have
also practiced more code reviews and tested the Merge Request feature
on Salsa than before. Overall, I think we are on a good path to
evolving this way of working, and hopefully doing it in a way that it
does not stifle work for maintainers who prefer to continue their
single-maintainer habits, so nobody feels at loss.


Thanks to Salsa Admins, recently when I used salsa it went much better.

While unfortunately I still had many cases where packages.debian.org did 
not load the pages or took a long time, several cases still for 
wiki.debian.org too (even if maybe less), am I the only one who notices 
or maybe the other DD/DMs do not use them or use them very little?


Thanks for including to recommend the use of README.source(.md), so if 
it will be used more I think it will be easier and faster to understand 
how to contribute to a given package whatever method or tool is used.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Why are cinnamon-core and cinnamon-desktop-environment still in version 6.2?

[Fabio Fantoni]

Il 05/02/2025 12:19, kindusmith ha scritto:
In Debian 13, all components of cinnamon have been upgraded to 6.4 or 
above, but cinnamon-core and cinnamon-desktop-environment are still 
lower versions of 6.2


Hi, I haven't made the new version of those metapackages yet because at 
the moment it would only be a version bump of the cinnamon components, I 
should first do some tests of clean installations to check if it is 
necessary to modify other parts.


For now I know that I should remove vino from the recommended ones but I 
don't know exactly which remote access system would be best to replace 
it with.


gnome-remote-desktop would be good, but unfortunately it has parts tied 
to gnome, x2goserver which is now an alternative to vino seems to me to 
be poorly supported (from a quick look, I could be wrong) and if I 
remember correctly it is active by default at installation so it might 
not be a great choice, regarding xrdp and others I had tried something 
many years ago, but I am not up to date.


Does anyone have any advice on this?



OpenPGP_signature.asc
Description: OpenPGP digital signature

Recommended remote access software for cinnamon-desktop-environment - was (Why are cinnamon-core and cinnamon-desktop-environment still in version 6.2?)

[Fabio Fantoni]

Il 05/02/2025 12:58, kindusmith ha scritto:


在 2025/2/5 19:44, Fabio Fantoni 写道:

Il 05/02/2025 12:19, kindusmith ha scritto:
In Debian 13, all components of cinnamon have been upgraded to 6.4 
or above, but cinnamon-core and cinnamon-desktop-environment are 
still lower versions of 6.2


Hi, I haven't made the new version of those metapackages yet because 
at the moment it would only be a version bump of the cinnamon 
components, I should first do some tests of clean installations to 
check if it is necessary to modify other parts.


For now I know that I should remove vino from the recommended ones 
but I don't know exactly which remote access system would be best to 
replace it with.


gnome-remote-desktop would be good, but unfortunately it has parts 
tied to gnome, x2goserver which is now an alternative to vino seems 
to me to be poorly supported (from a quick look, I could be wrong) 
and if I remember correctly it is active by default at installation 
so it might not be a great choice, regarding xrdp and others I had 
tried something many years ago, but I am not up to date.


Does anyone have any advice on this?



from chatgpt:

On the Cinnamon desktop, x11vnc is more recommended because it is Xorg 
compatible and more stable:


sudo apt install x11vnc

You can then connect to your Debian 13 machine using a VNC client 
(such as Remmina).


 Conclusion
Vino is a VNC server for GNOME but is not available by default on 
Cinnamon.


On Debian 13 + Cinnamon, x11vnc is recommended instead of Vino.

If you still want to use Vino, you can install it manually, but 
Cinnamon may not be able to call it directly.
Do you want remote access to your Debian 13 + Cinnamon desktop? If so, 
I can help you configure a more appropriate method!


Thanks for reply, I would prefer some answers from human experts rather 
than one from an automated system limited by its own algorithm, acquired 
data and other factors.


As I wrote in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094885#17 for the 
replacement I was aiming for an optimal choice given by various factors:



In fact, on the remote access part things are not well done, I had
searched a time ago, but I had not found optimal solutions,
well-supported, simple (also for inexperienced users) and that support
both xorg and wayland, there would be gnome-remote-desktop, but
unfortunately it is tied to mutter and some parts specific to gnome.


I haven't had time to do any in-depth research and testing recently (and 
I don't know if I'll have enough), so any advice would be appreciated.


Since wayland support of cinnamon is experimental and incomplete, I 
could also replace it with a specific software for xorg for now (and for 
Debian 13). But it would be useful to find something also supported by 
wayland as part of the wayland support that is slowly progressing also 
in cinnamon.


As Jeremy Bícha also wrote "VNC protocol it is not very secure by 
default" in #1094885and so I tried to keep it as a "secondary choice" 
but if there were no good enough alternatives I could still evaluate 
vnc, for example with x11vnc (although just seeing that the last 
upstream version dates back to 6 years ago leaves me a bit doubtful, I 
haven't looked into more detail though, I'll see deep if someone don't 
recommend better choices).





OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Complete and unified documentation for new maintainers

[Fabio Fantoni]

Il 11/01/2025 16:38, Ahmad Khalifa ha scritto:

On 11/01/2025 12:49, Fabio Fantoni wrote:
Write on Google "Debian create new package" and first result: 
https:// wiki.debian.org/HowToPackageForDebian


It points to various parts but mainly the more probable start point 
seems https://wiki.debian.org/Packaging/Intro


To point to git and gbp seems more useful https://wiki.debian.org/ 
PackagingWithGit Here wrote also about DEP14, tell writing first 
package out of git and after import, in fact it is not simple and 
fast to create the initial package starting immediately from git and 
neither to use immediately gbp and also DEP14, to create immediately 
on salsa etc... I remember that the last packages created new some 
time ago I had to do many steps, workarounds and only after convert 
the branches to the DEP14 names.



I just went through this learning process, and IMO, first thing to 
learn is how to "package" (debuild, debhelper, lintian, sbuild, 
devscripts), then you learn how to "publish" it (dput, gbp, DEP-14).


Packaging/Intro wiki is still an excellent first read if only to get 
the terminology in use (upstream tarball, source package, dsc, ...).


To quote from PackagingWithGit wiki:
It is easiest to first create the first version of a package, outside 
of Git.

It's an advanced wiki, not a starting step for newcomers.

At a basic level I think almost everyone starts by trying some basic 
packaging outside the packages for the official repositories, so it can 
be good to aim first at creating the package, but maybe with something 
that is both the most complete and up-to-date, and also the simplest and 
fastest for very basic cases.


The problem is that it seems to me that there is not enough 
predisposition towards git, gbp, salsa and salsa-ci for those who want 
to package for Debian.


There are also cases of people who just want to package their software 
quickly and fairly well for Debian as well as for other distros, for 
Debian they find themselves having to invest days learning and wait 
maybe months to MAYBE have the package included while in a few hours 
maximum they manage to prepare it for other distros and manage to 
include it in a shorter time.


There are those who want to start contributing with small things or 
start trying and find themselves in difficulty and "wasting" time 
without seeing results and often giving up.


Doing it in git from the beginning can be very useful for reviews, 
seeing changes etc... when I looked at some packages in mentors there 
was a significant difference between seeing the differences between 
uploading to download from mentors and packages on git(even if not 
salsa). It is faster to review, comment specifically, and possibly help 
fix/improve directly.


Another difference for maintainers can be managing Debian patches, in 
many cases they are not needed but where they are needed there can be 
also a good difference in the time that can be saved with gbp-pq rather 
than manually with quilt in some cases. I too, despite having used gbp 
for years, out of habit, continued to manage patches with quilt manually 
and only recently with gbp-pq, noticing that I could have saved a lot of 
time in some cases.


And also regarding testing the changes you make there is a big 
difference in time (and I suppose also much less difficulty or 
discouragement in many cases) than preparing ideal environments and/or 
doing it manually locally and use salsa-ci. Having local environments 
and tools is useful for most cases but they are quite a few things and 
can take a long time, while starting to see something concrete in a very 
simple and fast way I suppose can reduce premature abandonment. Then 
maybe I could be wrong and most of the cases of abandonment are for 
others, like some cases seen years ago that seemed to me to be due to 
lack of reviewers and sponsors on mentors.



Starting to use certain things from the beginning can favor them (unless 
you need something different specific to the team and/or packages), but 
if you start by spending a lot of time with certain tools and 
procedures, changing later is more averse or discouraged, perhaps 
without imagining the advantages it can have.



So in general it's ok when you start to see mainly the packaging files 
themselves (both a quick and simple thing, and all the advanced things 
in detail, in an optimal documentation) but shortly after if you want to 
start contributing and/or packaging something new it's useful to have 
something more targeted (again both a quick and simple thing and the 
advanced and detailed things).


An example, a person has some basic knowledge of packaging but now wants 
to contribute to package a new package for the official repo, he should 
find information that helps him understand if the package would fit into 
a team and be able to get there, otherwise some information to be able 
to start in a simple, fast but 

Complete and unified documentation for new maintainers

[Fabio Fantoni]

There has been a lot of talk about attracting and helping new 
maintainers, some improvements have been made "here and there", the 
documentation of gbp (the most used tool) has been improved, salsa, 
salsa-ci have been improved, there is discussion about DEP18, accepting 
DEP14 etc...


Having mostly the packages in the same place (salsa), with the same 
methods/tool (with gbp) would be useful, obviously not preventing you 
from using or continuing with something else, but if you want to aim for 
this thing you should firstly have a complete, simple and fast 
documentation that mainly aims at this goal.


Today trying to see how a new person who wants to start maintaining new 
packages would do and trying to do research thinking from his point of 
view and from simple searches on the internet I found unfortunately that 
these parts are fragmented and do not help at all to aim for something 
unified but not even simple and fast enough.


Write on Google "Debian create new package" and first result: 
https://wiki.debian.org/HowToPackageForDebian


It points to various parts but mainly the more probable start point 
seems https://wiki.debian.org/Packaging/Intro


To point to git and gbp seems more useful 
https://wiki.debian.org/PackagingWithGit Here wrote also about DEP14, 
tell writing first package out of git and after import, in fact it is 
not simple and fast to create the initial package starting immediately 
from git and neither to use immediately gbp and also DEP14, to create 
immediately on salsa etc... I remember that the last packages created 
new some time ago I had to do many steps, workarounds and only after 
convert the branches to the DEP14 names.


What would be the best, easiest and fastest procedure (especially for 
newcomers) to create a new package from scratch, aiming to use git, 
salsa, salsa-ci, gbp and DEP14 from the beginning?


Once found I think it would be useful to have it well documented, in a 
unified part and to which new arrivals can point (and also mentors use 
and point to it).



There are people with enough experience with git, good intuition and who 
learn easily and fast, but as I have noticed there are also people who 
have no or almost no experience with git and have difficulty learning 
new things.


An example is a new maintainer that I helped a lot to packaging his 
software for Debian, at the beginning he tried alone, he arrived on 
mentors but despite some attempts for a long time he continued only with 
unofficial packages that he created in a simple and fast way.


I explained to him about the packaging itself and then given the many 
difficulties in making him learn the necessary things for git and 
package management I thought it was better to avoid complicating further 
with external packaging on salsa but to do it on a branch of the 
upstream repository on github (with gbp import-ref) and now he has 
managed to prepare the latest versions by himself or almost.


In some cases like that it might be better to host the packages outside 
of salsa but for the major cases having a detailed, simple, fast and 
unique documentation to aim to use git, salsa and salsa-ci from the 
beginning I think would be useful. Using salsa-ci from the beginning can 
help to have some first tests also in a simpler and faster way rather 
than making local environments for clean builds on Sid and also all the 
various necessary checks, those can be done shortly later, so as not to 
overload the new people with too many tools, too many procedures etc... 
they will already be loaded by the packaging itself in a complete way 
and following the policies and then there are parts like for example the 
complete and correct creation of debian/copyright that could even take 
more time than all the rest of the packaging in some cases (but this is 
another thing).



I don't know if I've managed to explain well what I mean, but from what 
I've seen over the years, most of the people I've seen trying to 
approach packaging have had difficulty finding documentation and help 
(even on mentors, although it seems to have improved recently), but I 
haven't had time to follow people, I've mostly made some occasional 
messages and tried to follow a few people specifically (unfortunately I 
haven't had enough time either). What I seem to have noticed (I could 
also be wrong) is that most people "run away" at the beginning or after 
a while due to the difficulty in finding all the necessary information 
and/or too much time spent on basic packaging following the policies and 
complete and correct d/copyright. Others, on the other hand, seem to 
have left due to too much time spent waiting for someone that revision 
the package or finding sponsors that can upload it (but this would also 
be another thing outside the point of this topic).




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Let's make 2025 a year when code reviews became common in Debian

[Fabio Fantoni]

Il 24/01/2025 15:26, Christoph J. Scherr ha scritto:

On Fri, 2025-01-24 at 13:05 +0100, Jonas Smedegaard wrote:

Hi Christoph,

Quoting Christoph J. Scherr (2025-01-24 12:13:16)

Hello,

As someone just starting out with Debian, I'd like to share my perspective
on
this discussion.

I only recently contacted the welcome team and have been following the
mailing
lists while waiting for my salsa account approval. From what I've seen so
far,
Debian's development process can be quite challenging to understand as a
newcomer.

In my opinion, having a more intuitive web interface through a code forge
like
GitLab would lower the barrier to entry for potential contributors. I
believe
that normalizing merge requests would particularly benefit contributors from
younger generations, who are more familiar with these modern development
workflows. Exploring the BTS is, for me at least, more confusing for me than
exploring a git repository with issues and merge requests on salsa.

This is my first email to the lists. I hope these thoughts are relevant and
helpful to the discussion.

Welcome!

You certainly make a relevant point, and I believe that I understand how
that point is central for this discussion.

What troubles me, however, is if that is the only point deemed central
to this discussion.

Yes, it is easier to use tooling that we are used to.  Yes, it helps
collaboration around our preferred tooling if user interfaces are as
user friendly as possible.  I think we can all agree on that, in
isolation.

I think we can also all agree, that the BTS is not as globally familiar
as Github issue tracking facilities, nor as pleasing and welcoming and
intuitive to use especially for people oriented towards web interfaces.

I don't challenge any of those observations - I agree with them.

What I have a problem with is collaboration optimized *only* towards the
needs of newcomers.

I find the BTS highly valuable *despite* it being unwelcoming, not
because I come from a different time where its design is somehow a bliss
to work with.

I find non-webby git interactions highly valuable *despite* it being
less intuitive than web-based user interfaces and workflows.

We each have a comfort zone, and an understanding of benefits and
qualities of the tooling we are familiar with, and when we engage in
collaboration we may get challenged about that.  But finding the ideal
ways to collaborate is a complex assessment, not one that benefits from
reducing the options to a binary "does it raise the bar for newcomers?"
question, in my opinion.

I would love to collaborate with you, but when our ways of working are
different, I would like to look at how our different toolings are
helping each of us (the comfort zones of you and me), our product (the
packages etc. that we are working on concretely) and our project (how
our ways of working may affect others in Debian).  It feels to me that
this conversation reduces that conversation to "what is best for
newcomers is best for Debian" and I am not convinced that that is a
sensible reduction.

Hope that makes sense.

  - Jonas


Hello Jonas,

I did not mean that the BTS has no value. Quite the opposite in fact: Without a
method to trace bugs globally, there would be chaos. This is a complex topic, I
just wanted to add my stance on this particular point.

Writing a Pro/Con list might be a good idea, but I am not proficient enough in
both the BTS and GitLab to do so.

Greetings

Christoph

If we want to continue to use mainly BTS I think you should have an 
integration with something that allows you to do more things from the 
web interface, in a simple and fast way.


I recently saw this project that seems good to slightly improve some 
things, for example: https://fabre.debian.net/


Talking about salsa it comes to mind that it could be used for 
authentication if the possibility of doing operations from the web on 
BTS (if will be added), therefore keeping the opening of bugs via the 
usual tool or via email, renewed navigation in bugs and the possibility 
of responses and operations both in the old method via email and from 
the web. Among the functions that can be added, perhaps it could be to 
connect more easily to any MR in the repository. Add more default links, 
to make it easier and faster to reach the packaging repository (if 
present), the upstream repository (from upstream metadata, if present) 
and possible others. It has been useful to me in many cases (and it will 
be useful again), it may seems not be very useful but having some things 
more at hand and also being able to reach some parts by making a few 
less clicks and changing tabs when perhaps you end up doing such 
operations a few hundred or thousand times a year no longer seems like a 
useless or insignificant advantage.


What do you think?



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: DEP-14: Default branch name 'debian/latest' objections?

[Fabio Fantoni]

Il 24/01/2025 22:24, Xiyue Deng ha scritto:

Fabio Fantoni  writes:

...

There is also another thing to consider, if you keep a generic one as
default it always points to the latest version, while a specific one
might not be the latest version and if the contributors do not check
well the branches they could risk wasting time (and maybe also the
reviewers) doing work that does not include work in progress on more
recent branch or that conflicts with it


I would like to echo on this point.  I had worked on a repository that
has the "master" branch marked as the default branch on Salsa, which
lacks many changes compared to the released version.  I tried to
manually incorporate those changes, and only later found out that the
actual latest branch is "debian/sid" and it did have everything
up-to-date.  (Note that this has since been fixed[1]).  I think for new
repository, standardizing on a name (either "debian/latest" or people's
liking) helps identify where the latest work goes to.  And as Salvo
pointed out, it's the tag names that indicate where the releases go to,
not the branch names.

[1] https://salsa.debian.org/debian/mozc


I wrote this because I also saw this issue over the years.

Check the tags is useful if there are new upstream or debian version (so 
new tags) but not unreleased work excluding new upstream version, this 
require to look on branches those with the most recent activity, 
excluding those of fixes released for stable and backports.


It might seem obvious but unfortunately it is not, I fear that someone 
does not check by looking only at the default branch or maybe quickly 
not noticing something, for example in cases with particular and 
different names that are not common, linked to versions of the distro or 
software (at least not numbers).


For this reason, trying to standardize with a single name the branches 
where the most current work is carried out (with some exceptions), if 
not recommended by DEP-14 (because in some cases it is 
counterproductive) but at least suggested being able to have in the 
future the majority of uniform gits I think can be useful.


Then there were cases where the problem was that the default branch was 
no longer actually used but was not updated, so in addition to the name 
it would be good to make sure to keep the default branch updated. I have 
seen for example cases of those who created the repository with master 
but then immediately used another working branch (like "debian"), or who 
had switched from master to main but kept the default on master and 
these are just 2 examples of what I had seen.


While I was finishing I saw @zigo's answer regarding this last part, 
"default branch being set correctly should be what we mandate" would 
help even if is not for all cases (excluding any separate branches for 
"test" work, that is ok more updated but not default)


2 other particular cases that hinder could also be when someone work on 
another git without updating the fields in d/control and that do not 
work on the default branch because maybe only someone with lower 
permission remained active in the repository and who cannot push to the 
default branch by setting (rare but it happened), it would be necessary 
to better define how to act (and also have the means in some cases) to 
reduce the problematic cases to which I add a last example, "abandoned" 
package in which those who continue cannot modify in the repository and 
proceed in another repository but unfortunately until a new upload is 
made with the updated vcs fields others don't know and there is a risk 
of doing duplicate work elsewhere (it happened also to me)




   

There were cases when git wont let me use debian/foo "branch subdir" since it
clashed with other objects in the git repository, but I don't remember what it
was.

(Maybe that you cannot have <$branch> and <$branch>/something)


Thanks,

/mjt





OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: DEP-14: Default branch name 'debian/latest' objections?

[Fabio Fantoni]

Il 24/01/2025 23:12, Soren Stoutner ha scritto:


On Friday, January 24, 2025 9:50:10 AM MST Otto Kekäläinen wrote:

> Thanks everyone for sharing your viewpoints, it is interesting to read!

>

> I feel I need to clarify that I am not a native English speaker and my

> intent was to write a polite and honest email. It does not say

> anywhere that "you must use debian/latest". I am happy with whatever

> the convention is, as long as it works, and is universal at least for

> new packages.

>

> I am fine if single-maintainer packages, or closed-team packages do

> whatever they want, as it won't affect others (at least immediately),

> but not having "best practice" agreed on basic things like git

> branches does cause unnecessary friction and time waste for those who

> participate in the maintenance of packages in multiple different

> teams, at least from my perspective.

>

> As somebody who is mentoring multiple new maintainers, I see them in

> particular having unnecessary hardship from lack of properly agreed

> conventions. For the long-term success of Debian, I think that

> discussing the best practices and having some things agreed is

> valuable, even though running the discussions does take energy.


I agree that we need one standard naming scheme.  Based on the email 
responses, it seems like debian/latest doesn’t convey the appropriate 
meaning, with something like debian/unstable being more appropriate.




debian/unstable is not good in case in default branch want to keep the 
latest work regardless of uploads to unstable or experimental, and use 
debian/unstable only if the latest versions are uploaded to experimental 
(could also be just for the freeze period) but urgent fixes are needed 
for unstable



Perhaps you should create a vote with MR options (similar to the one 
you did for DEP-0 naming).  Once there is a strong consensus on what 
the name should be, I would recommend that gbp be reprogrammed to 
default to that name (I know it is a lot of work), and after that it 
will probably be fairly easy to to get DEP-14 accepted.



--

Soren Stoutner

so...@debian.org





OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: DEP-14: Default branch name 'debian/latest' objections?

[Fabio Fantoni]

Il 24/01/2025 14:25, Tobias Frost ha scritto:

Am Fri, Jan 24, 2025 at 09:16:50AM +0300 schrieb Michael Tokarev:

24.01.2025 04:06, Otto Kekäläinen wrote:

3. "latest" is a misnomer (unlike "main" or "master").  For example, I often use
   "experimental" branch which is more recent than "master", yet the main
   development is happening in "master".

Same here. I think "latest" is a bad choice, as it is ambigious in some
situations: For example, is my experiment(al) package* latest or is the one
target for the next stable latest?  For me, it is much clearer to say e.g
"debian/sid" or "debian/experimental" to express what I want.

* (noting that experiments might not end up in sid, those changes might not
* even have a business
in the latest branch.)
Hi, for years on some packages every new major version I did the uploads 
on experimental first, in addition to the cases of feature freeze, 
master was the default branch and I did it on experimental branch 
changing d/gbp.conf, d/salsa-ci.yml and d/control, recently I switched 
to debian/latest and I'm keeping it there whether you upload to 
experimental or sid and I think that doing debian/unstable (or 
debian/sid) less frequently only if you have the latest in experimental 
but need some urgent fixes in unstable greatly reduces the need to 
change branches (with a few more operations only for where you upload).


So even if it may seem vague it depends on how you choose to do things 
and in many cases you could save time if you keep a generic branch as 
default rather than one tied to unstable or experimental (which requires 
more operations even when not necessary to maintain consistency)


There is also another thing to consider, if you keep a generic one as 
default it always points to the latest version, while a specific one 
might not be the latest version and if the contributors do not check 
well the branches they could risk wasting time (and maybe also the 
reviewers) doing work that does not include work in progress on more 
recent branch or that conflicts with it




  

There were cases when git wont let me use debian/foo "branch subdir" since it
clashed with other objects in the git repository, but I don't remember what it
was.

(Maybe that you cannot have <$branch> and <$branch>/something)


Thanks,

/mjt





OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: DEP-14: Default branch name 'debian/latest' objections?

[Fabio Fantoni]

Il 24/01/2025 02:06, Otto Kekäläinen ha scritto:

Hi!

Current https://dep-team.pages.debian.net/deps/dep14/ states that the
default Debian branch name is 'debian/latest':


In Debian this means that uploads to unstable and experimental should be 
prepared either in
the debian/latest branch or respectively in the debian/unstable and 
debian/experimental
branches.

...

The helper tools that do create those repositories should use a command like 
git symbolic-ref
HEAD refs/heads/debian/latest to update HEAD to point to the desired branch.

I would be curious to hear why people are *not* adopting 'debian/latest'?

Why does the majority of Debian packages still use 'master' or
'debian/master' branch as the main development branch?

Is it simply because git-buildpackage does not to default to 'debian/latest'?


The DEP-14 has been around since November 2014 and one would think
that DDs would have adopted 'debian/latest' as the default branch and
git head now. Since 2020/2021 the whole 'master' was deprecated in
favor of 'main' by most git services and tools, yet 'master' is still
the most popular one in Debian.

Git is a great tool for collaboration. It is sad to see that in Debian
usage of git is stifled by simple things like people not agreeing to
use a common branch naming scheme despite there being a proposal for
10+ years now.


I think:

- because is not the default in tools

- because it is not addressed in the documentation or as an example I 
have seen documentation that used it but due to the lack of details of 
additional operations there was the risk of not really using it 
(https://wiki.debian.org/PackagingWithGit?action=diff&rev2=53&rev1=52)


- because it has changed (it was debian/master) and maybe they don't 
want to change again, or they fear it will change again


- because it is not easy and fast to migrate and if you do it you have 
to redo the local repository, if you are alone working on the repository 
it is not a big problem while if you are many it can create inconveniences



for example, about migration, I changed major repositories on cinnamon 
team recently where I near only me to work with:


- push any works if not already done

- change d/gbp.conf for new branches name and push skipping salsa-ci (if 
used)


- convert with salsa cli that is faster but one thing fails and require 
manual operation:


salsa --group cinnamon-team protect_branch cinnamon master no
salsa --verbose --group cinnamon-team --rename-head rename_branch 
cinnamon --source-branch=master --dest-branch=debian/latest
# this will fails to delete master, change default branch from salsa 
website (in Settings->Repository) and delete master branch (from website)

salsa --group cinnamon-team protect_branch cinnamon debian/latest m d
salsa --verbose --no-fail --group cinnamon-team rename_branch cinnamon 
--source-branch=upstream --dest-branch=upstream-tmp
salsa --verbose --no-fail --group cinnamon-team rename_branch cinnamon 
--source-branch=upstream-tmp --dest-branch=upstream/latest


note: in case of multiple debian/upstream branches more operations will 
be needed


- for local repository instead multiple operation to convert is simpler 
and fast do new with a gbp clone


In case of multiple people active working on repository is good to 
advise all to push any work not pushed, not to do anything else at the 
scheduled time of conversion and then make a new copy with gbp clone.





OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Is Salsa CI easy to use for anyone learning Debian packaging?

[Fabio Fantoni]

Il 23/12/2024 18:09, Otto Kekäläinen ha scritto:

Hi!

Salsa CI is a great system for all aspiring Debian packagers to test
their packages before requesting review from mentors, and also for
experienced packagers to ensure there are no easily testable lapses
before uploading to Debian.

Anyone with a Salsa account can use it. Simply follow the README at
https://salsa.debian.org/salsa-ci-team/pipeline to get started and to
find the optimal settings for your specific package.

However, as there are still packages not using Salsa CI, I wonder is
it straightforward enough for everyone?

I am in the process of doing a round of updates to the README. All
feedback on how to improve the documentation so it is easy to digest
in particular for newcomers is welcome as replies to this email or as
comments at 
https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/563.

- Otto


Thanks for your works, basically it seems quite simple to me.

From my experience the problems encountered are occasional regressions, 
often not of a salsa-ci itself, that cause all builds to fail for 1 or 
more days.


I also had difficult to use extra repo,the documentation could perhaps 
be improved in this regard, for cinnamon packages I had it working using 
debomatic repository but on recently tests for next major version using 
extra repo was not working, and I'm not sure of the cause from a fast 
look: 
https://salsa.debian.org/cinnamon-team/cinnamon-settings-daemon/-/jobs/6815175


in the documentation it could be added for example which tests do not 
support the extra repos to be disabled or which require additional 
changes, for example when was working I had to add a piuparts pre script 
(to have piuparts working) and disabled reprotest and BUILD_PACKAGE_I386.


A minor thing useful can be to disable cross build by default as you 
already did an MR: 
https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/570




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Why are cinnamon-core and cinnamon-desktop-environment still in version 6.2?

[Fabio Fantoni]

Il 08/02/2025 15:18, Andrew M.A. Cater ha scritto:

On Wed, Feb 05, 2025 at 12:44:31PM +0100, Fabio Fantoni wrote:

Il 05/02/2025 12:19, kindusmith ha scritto:

In Debian 13, all components of cinnamon have been upgraded to 6.4 or
above, but cinnamon-core and cinnamon-desktop-environment are still
lower versions of 6.2


Hi, I haven't made the new version of those metapackages yet because at the
moment it would only be a version bump of the cinnamon components, I should
first do some tests of clean installations to check if it is necessary to
modify other parts.


Cinnamon comes originally from Linux Mate and Clement Lefebrvre -
maybe follow what they package as their desktop as a basis for the
full desktop metapackage if you haven't before??
Hi, Mint created more fork or other software not packages for Debian, 
not enough time for maintain also them and some unfortunately they don't 
have enough people and time to maintain them well upstream so I don't 
think it's good to add them.



For now I know that I should remove vino from the recommended ones but I
don't know exactly which remote access system would be best to replace it
with.

gnome-remote-desktop would be good, but unfortunately it has parts tied to
gnome, x2goserver which is now an alternative to vino seems to me to be
poorly supported (from a quick look, I could be wrong) and if I remember
correctly it is active by default at installation so it might not be a great
choice, regarding xrdp and others I had tried something many years ago, but
I am not up to date.


Ideally, yes, don't pull in masses of GNOME. It does seem that a lot of
people rely on Cinnamon at least partly because it's lighter weight and
needs fewer resources. if you can make cinnamon more self contained, that
might be a lot better. [Several of the Debian desktop metapackages need
cleaning up IMHO - don't feel bad that this is being asked of you.]


Sporadically I take a look and see if there are any improvements to the 
metapackages, unfortunately it happens quite rarely, especially the 
tests on multiple combinations (only core or complete with or without 
recommended etc...) but unfortunately it can take a long time for 
example the ubuntu ones of which some packages are different so much 
that before 24.04 I didn't have time for good tests (which I did before 
the lts versions of ubuntu) and unfortunately the default installation 
from the cinnamon metapackages doesn't seem good to me (then there is 
also the increase in the use of snaps which "worsens" some things or 
even just makes them heavier, but that's another thing)


If there are any suggestions for improvement they are welcome.




Does anyone have any advice on this?


I'd suggest RDP in some form: Microsoft seem to be going this way
for suggested interaction with WSL and Red Hat have dropped VNC
because it doesn't work well with Wayland.

If people really want VNC, then TigerVNC is there in Debian for
all architectures.

Hope this helps,

All the very best, as ever,


I would also prefer rdp (instead vnc) and gnome-remote-desktop it seems 
good but unfortunately in some parts it is strictly tied to gnome 
components and there is currently no one working on a fork tied to 
cinnamon components.


There is xrdp although not very good from a quick test and put only as a 
further alternative.


There is rustdesk that seems interesting but is not in the repository 
(there is only an RFP).


For now I replaced vino with x11vnc, not very good from a fast test but 
better the vino.Then when something better is found (and preferably also 
with wayland support) I will replace it.


Tigervnc if I remember correctly, when I tried it years ago it wasn't 
bad, but I don't think it has a simple enough configuration for 
beginners (something was changed or added?), so I haven't tried it 
again, since for the metapackage I'm looking for something simple and 
fast that's also good for beginners.


Anyway I didn't have time to do a thorough research and testing of all 
the software, I just did a quick search and a quick test of some 
software before doing cinnamon-desktop-environment 6.4.0, so if you have 
more experience with remote access programs (present in the repository) 
feel free to recommend them and I will consider them for further 
improvements.




Andrew Cater
(amaca...@debian.org)





OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Improvement of headless server upgrades

[Fabio Fantoni]

Il 06/03/2025 09:43, Holger Levsen ha scritto:

On Tue, Mar 04, 2025 at 08:39:43PM -0500, Helmut K. C. Tessarek wrote:

Both network "outages" could have been prevented by adding a note at the end
of the dist-upgrade output.

they could also have been prevented by reading the release notes and following
their advice.

that would also have prevented this wonderful bikeshedding thread.

sorry to state the obvious.


I think the things to do can be summed up as follows: read release note 
of new major version and NEWS entries


If you are upgrading important or critical systems try also:

- test before in a testing system, or vm. or even just start from a less 
critical one


- try to have additional access in case of unforeseen events (there are 
not only the network ones mentioned in this discussion that can prevent 
the boot but also other undocumented and/or specific ones to the system 
or to a part of it). I mean for example an access from the host in case 
of vm or an ipmi system in case of physical server.


- if you don't have much time to read the whole release note read at 
least the "Upgrade specific items" part, for example for buster there is 
"5.1.6. Migrating from legacy network interface names".


- if you don't have time to read NEWS every update do it at least for 
the first time so you can see all the common ones on the basic packages, 
for example however it can be useful to have a quick look at each update 
and read those of specific programs to be aware of important or 
essential changes and save time rather than having problems later, 
perhaps not noticing the problems immediately or not being able to find 
the cause immediately



Regarding possible improvements I think the only thing that can be added 
is a check to the upgrade operations and if it is detected that you are 
upgrading to packages of the next major version add a simple initial 
warning (but not a big "image" as suggested in topic start) in which it 
is recommended to read the release notes, especially the "Upgrade 
specific items" part, and the NEWS of the packages.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Improvement of headless server upgrades

[Fabio Fantoni]

Il 05/03/2025 02:39, Helmut K. C. Tessarek ha scritto:
This is my first mail in a Debian mailing list and I hope I've chosen 
the correct one. There are way too many lists thus please direct me to 
the correct one, in case I messed up.


I would like to make a suggestion for release upgrades. It should not 
be a huge effort to implement and I can work with someone to make this 
happen.


In the last few days I ran into a serious issue when upgrading to 
newer releases on 3 headless servers: the network connection went dead.
In the first situation the interface name changed from eth0 to end0 
and after the reboot my adapter got a link-local address.
In the second situation dhcpcd was replaced by Network Manager and 
once again the network was dead.


Hi, when you do upgrade to a new major version you should before read 
release note for important changes, also read NEWS on packages upgrade 
(that contain important changes, including the one that can require 
manual changes). It is also good to test upgrade on a test server or on 
a minor one for the first time on any major version upgrade, so you can 
spot other possible unforeseen events.


These network changes are documented and well known, I have done many 
Debian server upgrades over the years and for example those network 
changes I had seen before by documenting myself and I had made sure to 
modify correctly before the upgrade and reboot to avoid unexpected 
events. Alternatively you can also modify to force the old names.




Please don't get me wrong, I am not against keeping up with the times 
and use new technology. Far from it.
But in both cases I had to connect my headless machines to a monitor 
and keyboard and fix the network issues. Usually this is not a 
problem, but sometimes it might be impossible.
In both cases I did not even know that these things would happen. The 
dist-upgrade made the changes without my input and I was left in the 
dark. Iamgine my surprise when I couldn't connect to my boxes anymore.


Both network "outages" could have been prevented by adding a note at 
the end of the dist-upgrade output.


e.g. something like the following (monospace font required for the 
"Attention" text):


    _  _ _ _ _   _ _ ___ ___  _   _
   / \|_   _|_   _| | \ | |_   _|_ _/ _ \| \ | |
  / _ \ | |   | | |  _| |  \| | | |  | | | | |  \| |
 / ___ \| |   | | | |___| |\  | | |  | | |_| | |\  |
/_/   \_\_|   |_| |_|_| \_| |_| |___\___/|_| \_|

Network interface name changed: please update config files before reboot.

    _  _ _ _ _   _ _ ___ ___  _   _
   / \|_   _|_   _| | \ | |_   _|_ _/ _ \| \ | |
  / _ \ | |   | | |  _| |  \| | | |  | | | | |  \| |
 / ___ \| |   | | | |___| |\  | | |  | | |_| | |\  |
/_/   \_\_|   |_| |_|_| \_| |_| |___\___/|_| \_|

Network subsystem changed: please add a system connection before reboot.

Is this something that makes sense? Often you have a remote console 
like an iLO or whatever cloud systems provide. But in some cases there 
is nothing. No console, no monitor, no keyboard. Only a power and a 
network cable.


Cheers,
  K. C.

P.S.: I go by KC, trying to avoid the Spaceballs Dark Helmet mixup.






OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: New contributor experience

[Fabio Fantoni]

Il 31/05/2025 07:34, Marc Haber ha scritto:

On Fri, 30 May 2025 13:28:26 -0700, Soren Stoutner 
wrote:

You can also edit your general notification settings, but if you are a Debian
Developer (and thus a member of the Salsa Debian team) that would mean you
would receive notifications for every package under the Debian namespace (as
well as all the teams you belong to).

That Debian namespace in Salsa which was invented as a replacement for
the collab-maint project on Alioth is a really weird construct. It
clutters up (makes unuseable) search results, makes me "maintainer" of
packages that I don't remotely care about and makes it hard to watch
my merge requests. It's just too big.

Can I have salsa somehow show me all repositories that I have ever
committed to?

Greetings
Marc


I also had issue to check activity on all repositories of packages I 
maintain and other that I want to keep an eye on in case there is a need 
(time permitting).


"your projects" in activity shows you everyone in the groups you are in 
but if you are in large groups it becomes unusable.


The workaround I found is to star all the repositories that I want to 
follow (just a few dozen), so in activity->starred projects I can see 
all the new/recent events in those projects quickly.


Regarding the notifications I have not set it to not receive too many 
emails for all events but only for things I participate in (for example 
new comments in MRs that I want to keep an eye on) but it is possible to 
make notification settings for each repository, even custom (for type of 
events).


The notification management is actually a bit limited and it seems 
problematic to me to modify the custom settings if for example I had 
made them on dozens or more repositories and I wanted to add or remove 
events on all of them, it doesn't seem possible to me, it would be good 
if they added the possibility of optionally setting notifications also 
at the starred projects level.




OpenPGP_signature.asc
Description: OpenPGP digital signature