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

Machine readable contributor information (was: Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages)

[Niels Thykier]

Fabio Fantoni:

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

[...]

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)




If we go down this route, could we consider making it machine readable 
(in parallel with human readable)[0]. For people doing drive-by 
nmu/patches across many packages, having to manual open link and read 
policies can often take considerable time. It is the small things really 
like:


 * 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. (I get this is the DEP-18
   thread and the answer should be "MR via salsa", but then DEP-18 is
   opt-in, which means it might not be "MR via salsa" after all)

 * Does the maintainer prefer dgit and if so, which of its 5+ different
   documented workflows should I follow?
   (Like how does it manage patches git-wise)

 * Etc.

And yet we do not have good answers for these kind of questions in an 
automated fashion.


I am happy to work on the client side of this problem. I already took a 
stab at something similar (see [1], currently stuck on getting a single 
source of truth data source), so it would fit into the work I am doing 
anyway.


Best regards,
Niels

[0]: I mean a dedicated `JSON` or `YAML` file in parallel to the human 
policy. Shenanigans like parsing special statements from formats aimed 
at humans do not really cut it in my book.


[1]: https://salsa.debian.org/debian/debputy/-/merge_requests/37

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

[Simon Richter]

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

Bug#1077964: ITP: adwaita-icon-theme-legacy -- A fullcolor icon theme providing fallback for legacy apps.

[Alessandro Astone]

Package: wnpp
Severity: wishlist
Owner: Alessandro Astone 
X-Debbugs-Cc: debian-devel@lists.debian.org, 
debian-gtk-gn...@lists.debian.org


* Package name : adwaita-icon-theme-legacy
Version : 46.2
Upstream Contact: Jakub Steiner 
* URL : https://gitlab.gnome.org/GNOME/adwaita-icon-theme-legacy
* License : LGPL-3.0-only or CC-BY-SA-3.0
Programming Lang: N/A
Description : A fullcolor icon theme providing fallback for legacy apps.
 GNOME does not use adwaita-icon-theme as an FDO-compliant icon theme
 but third party applications might. By making adwaita-icon-theme
 inherit from adwaita-icon-theme-legacy, it becomes once again an
 FDO-compliant icon theme that third party applications can use.

--

adwaita-icon-theme-legacy is a new upstream GNOME component, and it is a 
new mandatory dependency of adwaita-icon-theme.


The purpose of the package is to provide /legacy/ icons, now dropped 
from adwaita-icon-theme, for applications that use the FDO 
icon-theme-spec 



GNOME does not intend for adwaita-icon-theme to provide icons for all 
the names in the spec, but the theme might be the system’s default icon 
theme, and thus used by third-party (typically non-GNOME) applications. 
Thus, adwaita-icon-theme was set to inherit from 
adwaita-icon-theme-legacy to remain compliant with the spec.


Read more about it:

 *

   https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/issues/288

 *

   
https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/commit/9cb8144b387251eef9c0a221b2febe18802e2435


 *

   https://gitlab.freedesktop.org/xdg/default-icon-theme/-/issues/21

--

This package will be maintained by the Debian GNOME team. Packaging will 
be at

https://salsa.debian.org/gnome-team/adwaita-icon-theme-legacy

Re: Machine readable contributor information

[Simon Richter]

Hi,

On 8/5/24 17:26, Niels Thykier wrote:


  * Does this package use `gbp dch` [...]
  * Does this package use some form of automatic formatting [...]
  * Does the maintainer prefer MR via salsa or BTS [...]
  * Does the maintainer prefer dgit and if so, which of its 5+ different
    documented workflows should I follow?


The thing is: all of these things are really interfaces, but they have 
not been designed as interfaces, they are just exposed parts of the 
implementation.


What we want is a single machine readable interface that allows updating 
packages. What we get in this way is a selector for an open set of 
possible interfaces, all with their individual drawbacks.


To really use that in an automated fashion, someone will have to develop 
a software package that has a single interface and several plugins that 
implement this interface, and that abstract away the differences between 
the exposed-implementation-details-as-interface.


So this does not save us from designing a proper interface, so we might 
as well get this done and then add the abstraction layer for the tools 
directly into the tools themselves.


Such an interface would assume a backend data model that can accurately 
represent the timeline of Debian packaging, including


 - taking upstream source
   - from tarball
   - from git
   - leave option to support other VCS, but do not waste effort
 - removing DFSG non-compliant files
 - demarcating the separation between "upstream" and "Debian"
 - producing a reproducible .orig archive (with no limit on format)
 - adding and updating packaging metadata
 - adding, updating and removing patches to the upstream source 
(ideally tracking patch author information and patch metadata 
information separately

 - producing a reproducible .debian archive (with no limit on format)
 - listing package history, with events classed accordingly

There needs to be some allowance for backends to be unable to retrieve 
some information, simply because the Debian archive does not track 
contributions line-by-line, and several of the git backends have also 
lost information along the way, like the original commit message for a 
patch that got copied into debian/patches.


A successful abstraction, in my view, hides the existence of the 
debian/patches directory, and represents it as metadata, with the 
metadata fields from the patch files themselves, and includes an 
interface for "add this patch to the upstream sources at this point in 
the patch stack and rebase everything." Whether that uses git rebase or 
quilt refresh in the background is of no concern to the interface user.


Of course that will lose most of the "usefulness" of salsa, which does 
not expose this high-level view, and cannot easily be made to do so. The 
point I was trying to make all along was that this was always a red 
herring, and if we want to have good tools, then we cannot tie packaging 
workflows to the back of a software development workflow just so we 
could reuse some of their shiny tools.


   Simon

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

Bug#1077974: ITP: gr-framework -- Universal framework for cross-platform visualization applications

[Kentaro HAYASHI]

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

* Package name: gr-framework
  Version : 0.73.7
  Upstream Contact: Josef Heinen 
* URL : https://github.com/sciapp/gr
* License : MIT
  Programming Lang: C++
  Description : Universal framework for cross-platform
  visualization applications

GR is a universal framework for cross-platform visualization
applications. It offers developers a compact, portable and consistent
graphics library for their programs. Applications range from
publication quality 2D graphs to the representation of complex 3D
scenes.

My collegue keen to use packaged version of gr-framework
in Debian.

Re: Bug#1077974: ITP: gr-framework -- Universal framework for cross-platform visualization applications

[Simon Richter]

Hi,

On 8/5/24 20:26, Kentaro HAYASHI wrote:


* Package name: gr-framework


GNURadio are already squatting the "gr-*" namespace, so discoverability 
will be bad and confused GNURadio users will install it.


Ideally, they would move to "gnuradio-*", but that would be fairly involved.

   Simon