Re: NEW review & revision process (or lack thereof) (Re: Growing new FTP-masters (Re: Bits from DPL))

[Jonathan Dowland]

I've recently been trying to help rescue a package that is dropped for 
Trixie, partly for technical reasons (source package split means a round 
trip through NEW) and party for license reasons (some uncertainty about 
copyright of some icons, which have been in the archive for decades, but 
since a NEW round-trip is required, this is a reject-worthy bug now)


On Mon Mar 10, 2025 at 7:57 AM GMT, Luke Faraone wrote:
We discard the source tarballs and changes files on REJECT so there is 
nothing to `debdiff`. This partially happens for legal reasons: if we 
determine a package is not suitable for the archive then we may no 
longer have the legal right to retain it on ftp-master.


That makes sense. In my case, I still don't have access to the source 
package that was rejected, but that could be solved if the (very busy) 
maintainer uploaded it somewhere else (e.g. to Salsa). Since it's never 
been in Debian (technically), there's no historic packages to look at 
(yet).


The rationale given when I joined as ftpassistant (c. 2012) for not 
publicising decisions e.g. in the ITP was to avoid publishing 
potentially harshly-worded and embarassing reviews to maintainers in 
public (like pointing out that you missed a fairly obvious license 
declaration, incompatibility, or packaging step).


I am welcome to feedback from the project as to whether this outweighs 
the benefit to having past decisions available for public consultation.


I had to ask nicely for someone with privileges to send me the ftp team 
reject notes to get some clue as to what needs fixing. So I would 
definitely prefer if they were open by default.



Thanks for your efforts!

--
Please do not CC me for listmail.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

Bug#1100052: ITP: python-enaml -- Declarative DSL for building rich user interfaces in Python

[Alexander Sulfrian]

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

* Package name: python-enaml
  Version : 0.18.0
  Upstream Contact: Matthieu C. Dartiailh 
* URL : https://github.com/nucleic/enaml
* License : BSD-3-clause
  Programming Lang: Python
  Description : Declarative DSL for building rich user interfaces in Python

Enaml is a programming language and framework for creating professional
quality user interfaces with minimal effort. Enaml combines a domain specific
declarative language with a constraints based layout system to allow users to
easily define rich UIs with complex and flexible layouts. Enaml applications
can be run on any platform which supports Python and Qt.

A few highlights of the framework:

 * A declarative language which extends the grammar of Python
 * A set of operators which automatically track runtime dependencies
 * A layout system which uses symbolic constraint declarations
 * A design which encourages model-view separation
 * A well documented and easy to follow code base


This is a dependency for InkCut which I also intend to package.

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

Bug#1100571: ITP: mgmt -- next generation config management

[Thomas Goirand]

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

* Package name: mgmt
  Version : 0.0.26.git.2024.10.25.85e1d6c0e8
  Upstream Contact: James Shubin 
* URL : https://github.com/purpleidea/mgmt
* License : GPL-3
  Programming Lang: Go
  Description : next generation config management

 Mgmt is a real-time automation tool. It is familiar to existing configuration
 management software, but is drastically more powerful as it can allow you to
 build real-time, closed-loop feedback systems, in a very safe way, and with a
 surprisingly small amount of our mcl code. For example, the following code
 will ensure that your file server is set to read-only when it's friday.
 .
 It can run continuously, intermittently, or on-demand, and in the first case,
 it will guarantee that your system is always in the desired state for that
 instant! In this mode it can run as a decentralized cluster of agents across
 your network, each exchanging information with the others in real-time, to
 respond to your changing needs.

Re: Change the expectation that emails should wrap at 80 characters

[Jonathan Dowland]

On Mon Mar 10, 2025 at 1:41 PM GMT, Jeremy Stanley wrote:
My groff/troff reply to your earlier suggestion of this was only 
somewhat tongue-in-cheek. Markdown isn't a singular clearly-specified 
syntax, but a family of them with several popular flavors in 
widespread use (as Timo's parser option challenges indicate).


Personally I think markdown is a bust at the moment due to the lack of 
client support (and MUA behaviour with an unknown text/* type seems 
remarkably poor: falling back to plain presentation would seem the smart 
choice there).


But that aside, I skimmed the RFCs for adding text/markdown and it 
supports a "variant" attribute, with a handful of dialects pre-defined 
by a sister RFC, including CommonMark, GitHub-flavoured and Pandoc.


registration of text/markdown:
https://www.rfc-editor.org/rfc/rfc7763.html

definition of various variants, inc. CommonMark:
https://www.rfc-editor.org/rfc/rfc7764#section-3.5

That would address the ambiguity.

It seems straightforward enough to me that Markdown's code blocks should 
not be reflowed whereas most of the rest of a Markdown document probably 
could be. (Perhaps the specs actually spell this out; I haven't 
checked).


It's a shame that Markdown's blockquote ('> ') doesn't match how people 
do quoted emails in practice. This won't work (requires more empty lines 
between the tiers)


Foo said:

Bar said:

Baz said:

You're wrong

No you're wrong

You're both wrong


…and when it does work, Pandoc's rendering (to 'plain') at least makes 
the tiers hard to distinguish. (assuming most other renderers will be 
the same)


There's also no handling of signatures.


--
Please do not CC me for listmail.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

Re: Bug#1100571: ITP: mgmt -- next generation config management

[Simon Richter]

Hi,

On 3/15/25 22:58, Thomas Goirand wrote:


   Description : next generation config management


[...]

Can you reword the description so that it reads less like an 
advertisement? "next generation", compared to what?


   Simon


OpenPGP_0xEBF67A846AABE354.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion

[Pirate Praveen]

On 3/9/25 9:20 PM, Ansgar 🙀 wrote:

What is the point of this then?


If I understood the argument of FSF correctly, the point is, having the 
same freedom as the hardware manufacturer to modify or not modify. In 
case of hardware without firmware (or fused firmware that cannot be 
modified further), this argument has some merit, I think. But if it 
needs firmware to function, I think argument is hardware manufacturers 
having more power than you to modify firmware.


It is all about where you want to draw the line between the hardware and 
software. Each of these has to be approached in different way since we 
can relatively easily modify/build the software, but not hardware (it 
needs huge investments and scale to be cost effective - may be 3D 
printers will be able to change that equation in the future, but not 
very likely in near future). So for hardware we are willing to give more 
power to manufacturers, but not for software.



Does it help users to replace/rewrite non-free firmware if it is not
supplied by the operating system? Or enable the user to not use non-
free firmware? I don't think so.


In a weird way, if you don't update the firmware, then no one has the 
ability to modify.


Basically hardware manufacturers are withholding code that they could 
give you easily, at least from the point of view of actually making use 
of it. The actual hardware design may not be as useful like firmware as 
modifying that will still require ability to manufacture, but for 
firmware you already have the ability to use modified version.



The only other reason to do this seems to be free/libre-washing by
pretending the non-free firmware is not there... But I don't think that
is something useful to spend resources on (but if people want to do so
for unofficial installer images, they are of course free to do so; as
far as I understand the FSF is in favor of free/libre-washing).

Or is there some other reason to want to do this?


In an academic way, this gives user same freedom as the hardware 
manufacturer - no one is able to modify the hardware (if you never 
update the firmware yourself). So the hardware manufacturer don't have 
control over your hardware, after you received it.


So the value of this is, looking at your ability to easily modify, do we 
have the freedom to modify?


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Change the expectation that emails should wrap at 80 characters

[Soren Stoutner]

On Saturday, March 15, 2025 3:08:01 AM Mountain Standard Time Stephan 
Verbücheln 
wrote:
> Am Montag, dem 03.03.2025 um 14:42 -0700 schrieb Soren Stoutner:
> > Interesting.  I guess that text could be interpreted as “Do not send
> > an HTML part, even if you also send a plain text part.”
> 
> Are you serious? That does not make any sense.
> 
> > Please don't send your messages in HTML; use plain text instead.
> 
> https://www.debian.org/MailingLists/index.html
> 
> How could it be more clear?
> 
> > However, I would appreciate it if this discussion were not hijacked
> > to discuss HTML vs. plain text.
> 
> The whole discussion requires that we know what the rules mean,
> especially if you want to change them.
> 
> Regards

This discussion isn’t about this at all.  If you would like to start a 
discussion about HTML, 
please feel free to do so under a different thread.

-- 
Soren Stoutner
so...@debian.org


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

Re: Change the expectation that emails should wrap at 80 characters

[Soren Stoutner]

On Saturday, March 15, 2025 2:53:28 AM Mountain Standard Time Jonathan Dowland 
wrote:
> On Fri Mar 14, 2025 at 9:49 PM GMT, Soren Stoutner wrote:
> > I am planning on proposing a GR, but I want to take the time to make
> > sure I word it well.  I expect to be able to do so in the next few
> > days.
> 
> Short of a GR, you could determine who "owns" the CoC at the moment:
> it's not clearly a Debian document like the DFSG, policy, etc.; in fact
> it's probably the domain of the listmasters. Have you talked to them at
> all?

I thought about doing that, but those who are against this change feel so 
strongly about 
their position I don’t think they would accept a change made that way as valid. 
 In 
addition, such a change doesn’t just need to apply to the mailing lists, but 
also to other 
interactions with Debian by email, like the BTS.  Because the primary 
interaction that most 
people have with Debian is through email, changing the way that interaction 
works is a 
big enough issue that I don’t see any other appropriate way of making it 
outside of a GR.

-- 
Soren Stoutner
so...@debian.org


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

Re: Change the expectation that emails should wrap at 80 characters

[Andrea Pappacoda]

Hi Soren,

On Sat Mar 15, 2025 at 3:47 PM CET, Soren Stoutner wrote:
On Saturday, March 15, 2025 7:41:02 AM Mountain Standard Time Antonio 
Terceiro wrote:
Please don't. Mobilizing the entire project to discuss and vote on 
the exact format for sending plain text email is ridiculous. That 
silent majority is silent, because, well, this issue is completely 
irrelevant.


It’s important enough to me.


I understand how you feel, but please keep in mind that changing the 
current recommendation would degrade the experience for many people.


New recommendations, to me, should be net improvements. We've already 
discussed about a message format which solves your reflowing concerns, 
while not degrading the experience where hard-wrapped text is fine.


Moreover, as Antonio said, do you really think that this matter is 
important enough to have everyone in Debian care about it?


Rather than trying to force my opinion on everyone, I'd work to improve 
existing software.


Have a nice weekend, bye :)


signature.asc
Description: PGP signature

Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?

[Roberto C . Sánchez]

On Sat, Mar 15, 2025 at 05:23:54PM -0400, Jeremy Bícha wrote:
> On Sat, Mar 15, 2025 at 4:34 PM Roberto C. Sánchez  wrote:
> > Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
> > for a package?
> 
> Why are you opposed to using Salsa as the VCS for cpuset? You use
> Salsa for many other packages and Github for some others.
> 
I am not opposed to using Salsa. As you note, I already use it for other
packages.

The nature of my question (which I took considerable time articulating
in order ensure that it was clear, but which apparently was not) has to
do with the appropriateness of *unilaterally* declaring Salsa as the VCS
in an *NMU*.

> Although there are obviously some DDs who dislike Salsa, I think the
> widespread project consensus is that Salsa should be used for packages
> if they are not hosted in some other VCS. Our current DPL, Andreas,
> ran on an explicit platform of encouraging Salsa and has continued to
> push towards that through his entire DPL term.
> 
Well, yes, I am aware of all of those things. In fact, during the Mini
DebConf in Toulouse a few months ago I gave a presentation on LTS and
Andreas asked a question along the lines of "how can maintainers help to
make LTS work go more smoothly?" To which I responded along the lines
of, "host packages in Salsa and use a consistent branch structure,
preferably DEP-14". You can put me squarely in the "likes Salsa, uses
it, and encourages others to use it."

> I consider the lack of using any VCS to be a bug, perhaps of normal
> severity. And therefore, I do think it is appropriate to import a
> package with its history into the Debian namespace on Salsa as part of
> an NMU. The lack of a VCS makes it harder for people to contribute to
> the package and makes it harder to see full packaging history.
> 

So, having established that I do not oppose using Salsa, I suppose I
ought to articulate at a finer level of detail why I have a problem with
what happened with cpuset (which your message has helpfully prompted to
think through a bit more completely).

As far as "drive by" changes go, they can be anywhere from trivial to
very substantial. Fixing a typo is trivial. Importing a package to Salsa
is substantial (though not overly so in the case of cpuset). Importing
to a VCS requires making a variety of choices (fork from upstream or
not, debian/ directory-only or not, pristine-tar or not, multiple
upstream branches or one, default branch name, etc.). And I'm sure I
left some out.

So, the point is, importing a package to a VCS, particularly one that is
then declared as the canonical VCS for that package (at least as far as
the PTS is concerned) requires making enough choices that it should be
considered off-limits in an NMU, unless the maintainer has been
coordinated with in advance.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?

[Marco d'Itri]

On Mar 15, "Roberto C. Sánchez"  wrote:


This appears, at least to me, to have rather substantially exceeded what
is appropriate for an uncoordinated NMU.

Indeed.

--
ciao,
Marco


signature.asc
Description: PGP signature

Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?

[gregor herrmann]

On Sat, 15 Mar 2025 16:34:09 -0400, Roberto C. Sánchez wrote:


This appears, at least to me, to have rather substantially exceeded what
is appropriate for an uncoordinated NMU. In particular, this seems to be
inconsistent with the following paragraph from the Developer's
Reference, section 5.11.1:
* Does your NMU really fix bugs? ("Bugs" means any kind of bugs, e.g.
 wishlist bugs for packaging a new upstream version, but care should
 be taken to minimize the impact to the maintainer.) Fixing cosmetic
 issues or changing the packaging style in NMUs is discouraged.


Agreed; while there are good points to be made about maintainership 
and streamlining packages etc. -- under the current best practices 
this is overshooting IMO.



I had thought of possibly suggesting an update to the documentation, but
I'm not sure that adding more words would make the matter any more
clear.


I think the docs are okay.


Cheers,
gregor

--
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Re: Should GPU shaders be considered firmware?

[Dirk Lehmann]

Hell Stephan =)

On 3/15/25 12:52 PM, Stephan Verbücheln wrote:

Am Donnerstag, dem 13.03.2025 um 02:37 +0100 schrieb Dirk Lehmann:

GPU shaders should be clearly respected as software (and not
hardware).  Therefore, `intel-media-va-driver-non-free` is rightly in
the Debian archive `non-free`.


First of all, I completely agree that:
1. shaders are computer programs
2. the shaders in that package are unfree


okay, I have looked a bit into the sources of the upstream repository.
And I have good news!

All source files I checked in

  * media_driver/agnostic/*/kernel{,isa}/*/*.c

which you listed at begin of this thread looks like as they are

  * EITHER SHADERS NOR FIRMWARE !

These datasets are looking more like n-dimensional arrays.

Kernels in image- and video processing are mathematical matrices.
I.e. on images they will be scrolled (mathematical operation:
"symmetric convolved") through the images as (real-time)-filter for
anti-aliasing, sharpening, etc.  In this `intel-media-va-driver`-case
they are seeming to be used to interpolate frames.  I would assume,
for example if the video footage has a frame-rate of 60 fps and the
rendering-context (i.e. display) 144 fps then additional frames will
be generated/interpolated.

Here a Wiki link for the case of image processing:

  * https://en.wikipedia.org/wiki/Kernel_(image_processing)#Convolution

Yes, such tasks are usually done by shaders from GPU, but I'm quite
sure that the data above are just the Kernel-Matrices itself.  Would
be nice, if somebody can verify that the exported symbols in the
corresponding header files are really no executable code containing.

Question of licensing
*

I'm not a lawyer, but just want to start a discussion about a possible
sublicensing.  Even in my last post I had data explicitly excluded
from the general case

On 3/13/25 2:37 AM, Dirk Lehmann wrote:
> [...]
>
> As you expect, in detail from technical point of view, firmware is a
> special kind of software.  It is not data -- and it is executable in
> the sense that it changes the state of "physical hardware" in time.
>
> [...]

From technical point of view, I would

  * consider these kernel-matrices as binary images

As like images are painted with tools like Gimp, the kernel-matrices
were generated by the `KernelBinToSource.exe` tool (see source
comments), whose sources are available in the upstream repository,
too.

But I'm not a lawyer and don't know in detail how to deal with it.  I
would try do something like this:

The license of sources itself grants to the kernel-matrices-images
besides copy, modify, merge, publish, distribute also explicity

  * sublicensing

For me as not-lawyer it is a license of the class
attribution-share-alike license.  The question should be if it is
allowed to sublicense the kernel-matrices-images as

  * CC BY-SA
(Creative Commons Attribution-ShareAlike Licenses) ?

as this license should be better for datasets -- and if so, if the CC
BY-SA is compliant to our DFSG.  But I really have to less knowledge
about that topic, and which formalities are needed to be respected for
sublicensing.

Greets,
Dirk =)



OpenPGP_0xE2A3766F21F02BD5.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?

[Andrey Rakhmatullin]

On Sat, Mar 15, 2025 at 04:34:09PM -0400, Roberto C. Sánchez wrote:

Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
for a package?


That doesn't make sense to me, at least without context, not because 
setting Vcs-* doesn't make sense in a NMU but because creating an official 
package repo while not being a maintainer sounds weird.



--
WBR, wRAR


signature.asc
Description: PGP signature

Re: Change the expectation that emails should wrap at 80 characters

[Christoph Berg]

Re: Soren Stoutner
> I thought about doing that, but those who are against this change feel so 
> strongly about 
> their position I don’t think they would accept a change made that way as 
> valid.  In 
> addition, such a change doesn’t just need to apply to the mailing lists, but 
> also to other 
> interactions with Debian by email, like the BTS.  Because the primary 
> interaction that most 
> people have with Debian is through email, changing the way that interaction 
> works is a 
> big enough issue that I don’t see any other appropriate way of making it 
> outside of a GR.

So, you've joined Debian a mere half a year ago, and now instead of
talking to people about changing something, you are starting a GR just
to make sure everyone gets to know an idea that will go nowhere
anyway?

Please get a life.

https://xkcd.com/793/

Christoph

Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?

[Tollef Fog Heen]

]] Roberto C. Sánchez  

How do others suggest to handle this particular situation? 


Last time it happened to me, I rolled back the inappropriate 
changes in the package and let the NMUer clean up the mess left on 
salsa.


--  Tollef Fog Heen UNIX is user friendly, it's just picky about 
who its friends are

Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?

[Jeremy Bícha]

On Sat, Mar 15, 2025 at 4:34 PM Roberto C. Sánchez  wrote:
> Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
> for a package?

Why are you opposed to using Salsa as the VCS for cpuset? You use
Salsa for many other packages and Github for some others.

Although there are obviously some DDs who dislike Salsa, I think the
widespread project consensus is that Salsa should be used for packages
if they are not hosted in some other VCS. Our current DPL, Andreas,
ran on an explicit platform of encouraging Salsa and has continued to
push towards that through his entire DPL term.

I consider the lack of using any VCS to be a bug, perhaps of normal
severity. And therefore, I do think it is appropriate to import a
package with its history into the Debian namespace on Salsa as part of
an NMU. The lack of a VCS makes it harder for people to contribute to
the package and makes it harder to see full packaging history.

Thank you,
Jeremy Bícha

Re: Change the expectation that emails should wrap at 80 characters

[Soren Stoutner]

On Saturday, March 15, 2025 11:19:25 AM Mountain Standard Time Andrea Pappacoda 
wrote:
> Hi Soren,
> 
> On Sat Mar 15, 2025 at 3:47 PM CET, Soren Stoutner wrote:
> > On Saturday, March 15, 2025 7:41:02 AM Mountain Standard Time Antonio
> > 
> > Terceiro wrote:
> >> Please don't. Mobilizing the entire project to discuss and vote on
> >> the exact format for sending plain text email is ridiculous. That
> >> silent majority is silent, because, well, this issue is completely
> >> irrelevant.
> > 
> > It’s important enough to me.
> 
> I understand how you feel, but please keep in mind that changing the
> current recommendation would degrade the experience for many people.

I feel like the current requirement degrades the experience for many people.

> New recommendations, to me, should be net improvements. We've already
> discussed about a message format which solves your reflowing concerns,
> while not degrading the experience where hard-wrapped text is fine.

I feel like my proposal is a vast net improvement, although I do understand 
that it would 
degrade the workflow of a small number of people.  However, on balance, with 
the 
number of people who would have an improved workflow vs. the number of people 
who 
would have a degraded workflow, I think it is the correct decision for Debian 
as a whole.

> Moreover, as Antonio said, do you really think that this matter is
> important enough to have everyone in Debian care about it?

Yes, I do.  I sat on this idea for a while before my first post to make sure I 
really felt it was 
worth the effort it would take and that it really mattered enough to pursue.

Email is the way the majority of people interface with Debian.  Having a good 
email 
experience is therefore worth the attention of the entire Debian community.

> Rather than trying to force my opinion on everyone, I'd work to improve
> existing software.

I agree.  That is why I think, given the current state of affairs, it is 
inappropriate for the 
code of conduct to force a particular column width on anyone.


-- 
Soren Stoutner
so...@debian.org


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

Re: Change the expectation that emails should wrap at 80 characters

[Soren Stoutner]

On Friday, March 14, 2025 2:49:26 PM Mountain Standard Time Soren Stoutner 
wrote:
> On Wednesday, March 12, 2025 5:38:40 PM Mountain Standard Time Mario
> Limonciello
> wrote:
> > 
> > 
> > >Mario Limonciello (hints of format=flowed support)
> > 
> > Thanks for the summary. I am of the camp of f=f.
> > 
> > At least with the MUA I'm using most of the time (Thunderbird) this is
> > the default, and no one has complained to me directly about it for any
> > email sent to the Kernel community or Debian community.
> > 
> > As it seems to be a polarizing discussion I do wonder if maybe it would
> > make most sense to have a "proper" vote to determine which way the
> > "silent majority" of developers actually lean?
> 
> I am planning on proposing a GR, but I want to take the time to make sure I
> word it well.  I expect to be able to do so in the next few days.

The GR can be found at:

https://lists.debian.org/debian-vote/2025/03/msg00011.html

-- 
Soren Stoutner
so...@debian.org


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

Re: Change the expectation that emails should wrap at 80 characters

[Jonathan Dowland]

Thank you for the summation Phil!

To clarify my position: At present I am against the proposal.

Regarding format=flowed: I would not want the CoC complicated with it at 
this time; I'd rather first gather more data on the current state of 
client support, which MUAs are in popular use for Debian lists, and 
suchlike.


--
Please do not CC me for listmail.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

Re: Improvement of headless server upgrades

[Marc Haber]

On Thu, 6 Mar 2025 14:00:46 +0100, Lee Garrett 
wrote:
>P.S.: This failure mode isn't even documented in the release notes.

But they do, don't they, recommend to have console access available
during an upgrade right?

Greetings
Marc
-- 

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

Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)

[Charles Plessy]

On Fri, 2025-03-07 at 09:51 +0900, Charles Plessy wrote:

> > I have prepared a stub for a "Gateway to NEW" on Salsa:
> > 
> > https://salsa.debian.org/newgateway-team

Le Sun, Mar 09, 2025 at 06:00:55PM +0800, Maytham Alsudany a écrit :
 
> Am I correct in assuming that each package to be reviewed will be an
> issue under the "reviews" repo (and possibly also mention the relevant
> package maintainer there)?
> 
> Will packages be reviewed upon request, or will it be fine to pick out
> packages from the NEW queue and review them to assist FTP masters?

The way I envision it, is that people will ask for peer review before uploading
to the NEW queue.  One of the reasons is that we will provide CI pipelines and
checklists that assist the preparation of the `debian/copyright` file, and once
the maintainer has used that system, requesting a review will be only a few
clicks away.  At the moment I have the impression that ussing issues is the
easiest way, but alternatively Merge Requests on the file that tracks packages
and their reviews could work too.

I have made a very simple proof or concept here:

https://salsa.debian.org/newgateway-team/reviews/-/blob/main/README.md?ref_type=heads

I have not finished to collect the contents of the checklists, and I am just at
the beginning of learning how CI pipelines work on GitLab.  People intersted in
making the NEW gateway happen, your contribution is most welcome!  It can not
be the pet project of a single person.  In any case, I will use it for my 
packages
and will do my best to convince my team mates to do so too :)

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Re: Should GPU shaders be considered firmware?

[Stephan Verbücheln]

Am Donnerstag, dem 13.03.2025 um 02:37 +0100 schrieb Dirk Lehmann:
> GPU shaders should be clearly respected as software (and not
> hardware).  Therefore, `intel-media-va-driver-non-free` is rightly in
> the Debian archive `non-free`.

First of all, I completely agree that:
1. shaders are computer programs
2. the shaders in that package are unfree

They are not unfree because of license restrictions but because of
missing sources for some blobs.

Please note that Debian does not only require sources for computer
programs. Generated data should also preferably include all sources
that allow developers to study, modify and generate their own versions
of that data.

There are many edge cases. What about JavaScript executed in the web
browser? What about file formats which are de facto executable programs
in some kind of virtual machine such as PostScript or TrueType fonts?

> for me is a computer machine a stack of three layers:
> 
>     Machine/Computer
>    ,-,
>    | optional non-free/proprietary software  |
>    |-|
>    | Free and open-source software   |
>    |-|
>    | Hardware (maybe non-free/proprietary)   |
>    '-'

I do not agree with that. Shaders do not run “on top” like apps or
JavaScript in the web browser. They are loaded into the GPU just like
the firmware and are executed there.

> The question must be: Is firmware to be considered as hardware or
> software?  I.e. in your case of GPU shaders the question is:
> 
>    * Should be GPU shaders considered as hardware or software?

That is not the question. Firmware is not hardware either.

>    1. Firmware needs to be developed by the chip-vendor itself.
> 
>   (Hardware from companies point of view)
> 
>    1. GPU shaders will not be developed exclusively by the chip
> vendor
>   itself.  In contrast, they providing SDKs for development.

This is also true for these GPU shaders.
   1. They are developed by the hardware vendor and its community.
   2. They are not developed by a software company like shaders for a
  game engine.
   3. The whole purpose is to enable hardware capabilities, in this
  case video encoders and decoders.
   4. The same shaders developed by the GPU vendor can be used by any
  video player or library.
   5. The available libraries in user space are free.

> The answer is: The path is the goal.  The 3-layer machine/computer
> model we agree all, hopefully.  We can map the companies-/logistic-
> point of view very well to that 3-layer model, imho.

That model does not make sense to me. I want firmware and shaders to be
free just as software. But there is a practical difference between
software which we can replace by alternatives and firmware which is
required by the hardware.

The only way to achieve the end goal is by only buying hardware which
works without non-free firmware. This is the long-term goal but not
always possible in the short term.

There are libreboot, coreboot etc., but they all require unfree blobs
from hardware vendors. This might change with more RISC-V options
coming to market, but the situation is as it is.

In the meantime, we have non-free-firmware for people who want/need it.
It will exists regardless of whether it is included in the installation
media or not.

From the information security and privacy perspective, those shaders
are also comparable with firmware.
   1. Your wireless firmware runs on the network device. It does not
  have access to your kernel or any other thing running in main CPU
  and memory. It can only see the network traffic that you route
  through that interface.
   2. Your GPU firmware runs on the graphics card. It does not have
  access to your kernel or any other thing running in main CPU and
  memory. It can only see information that you send to this
  graphics card for display.
   3. The shaders run on the GPU. They do not have access to your
  kernel or any other thing running in main CPU and memory. They
  can only see information that you send to this graphics card for
  decoding and encoding.

My point is that these particular shaders could be argued to belong to
non-free-firmware and not non-free.

Regards
Stephan


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

Re: Salsa CI job 'missing-breaks' to be enabled by default starting March 1st

[Bastian Blank]

On Thu, Mar 06, 2025 at 05:23:00PM +0100, NoisyCoil wrote:
> oss4-dev is fine (unless diversions of files in linux-libc-dev are
> forbidden): oss4-dev is correctly diverting the header, as a consequence it
> needs not Break or Conflict with linux-libc-dev.

linux-libc-dev defines the interface the kernel provides.  Random
packages overriding that makes for nasty surprises.

So there are multiple solutions:
- Rename the header and move out of the linux dir.
- Move the header outside of /usr/include and explicitely use this
  directory in the include path.

> The issue here is that the new missing-breaks pipeline job has no clue that
> packages are correctly diverting files, and it flags as missing Breaks
> packages which, in fact, do not miss Breaks because they aren't supposed to
> have any.

Because diverts are kind of sledgehammers.  Without coordination they
break stuff.

Bastian

-- 
Beam me up, Scotty!  It ate my phaser!

Re: Change the expectation that emails should wrap at 80 characters

[Soren Stoutner]

On Saturday, March 15, 2025 7:41:02 AM Mountain Standard Time Antonio Terceiro 
wrote:
> On Fri, Mar 14, 2025 at 02:49:26PM -0700, Soren Stoutner wrote:
> >On Wednesday, March 12, 2025 5:38:40 PM Mountain Standard Time Mario
> >Limonciello>
> >wrote:
> >> 
> >> 
> >> >Mario Limonciello (hints of format=flowed support)
> >> 
> >> Thanks for the summary. I am of the camp of f=f.
> >> 
> >> At least with the MUA I'm using most of the time (Thunderbird) this is
> >> the default, and no one has complained to me directly about it for any
> >> email sent to the Kernel community or Debian community.
> >> 
> >> As it seems to be a polarizing discussion I do wonder if maybe it would
> >> make most sense to have a "proper" vote to determine which way the
> >> "silent majority" of developers actually lean?
> >
> >I am planning on proposing a GR, but I want to take the time to make sure I
> >word it well.  I expect to be able to do so in the next few days.
> 
> Please don't. Mobilizing the entire project to discuss and vote on the
> exact format for sending plain text email is ridiculous. That silent
> majority is silent, because, well, this issue is completely irrelevant.

It’s important enough to me.

-- 
Soren Stoutner
so...@debian.org


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

Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion

[Ansgar 🙀]

Hi,

On Mon, 2025-03-10 at 10:57 +0100, Simon Josefsson wrote:
> I don't think the above fully resolve my concerns though.  The mere
> presence of official documented hooks to load non-free software is
> problematic from a freedom perspective.

Maybe a "free" version of Debian could be provided with all of
/usr/share/doc/*, /usr/share/man/* and similar removed? And of course
any references to FSF-provided documentation...

But I guess this also answers my other question: removing references to
non-free firmware to make them disappear is clearly freewashing.

"Ignorance is strength^Wfreedom."

Ansgar

Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion

[Bjørn Mork]

Simon Richter  writes:

> their questionable choices in buying hardware that ships with non-free
> firmware

Is there hardware that ships with free firmware?  Seriously.


Bjørn

Re: Change the expectation that emails should wrap at 80 characters

[Jonathan Dowland]

On Fri Mar 14, 2025 at 9:49 PM GMT, Soren Stoutner wrote:
I am planning on proposing a GR, but I want to take the time to make 
sure I word it well.  I expect to be able to do so in the next few 
days.


Short of a GR, you could determine who "owns" the CoC at the moment: 
it's not clearly a Debian document like the DFSG, policy, etc.; in fact 
it's probably the domain of the listmasters. Have you talked to them at 
all?



--
Please do not CC me for listmail.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

Bug#1100491: ITP: blazar-nova -- Nova scheduler filter used for the host reservation feature

[Thomas Goirand]

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

* Package name: blazar-nova
  Version : 7.0.0~rc1
  Upstream Contact: OpenStack Discuss 
* URL : https://github.com/openstack/blazar-nova
* License : Apache-2.0
  Programming Lang: Python
  Description : Nova scheduler filter used for the host reservation feature

 This package provides the Nova-related filters and extensions for the Blazar
 Reservation Service in OpenStack. This package includes the Blazar filter, a
 Nova scheduler filter used for the host reservation feature. It ensures that
 Nova does not schedule regular instances on Blazar-owned hosts unless
 preemption is enabled, and that host lease boundaries are respected.
 .
 Blazar is a resource reservation service for OpenStack. Blazar enables users
 to reserve a specific type/amount of resources for a specific time period and
 it leases these resources to users based on their reservations.
 .
 The following two resource types are currently supported:
  * Compute host: reserve and lease with a unit of a whole host
  * Instance: reserve and lease with a unit of a flavor

I will maintain this package within the OpenStack team.

Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?

[Roberto C . Sánchez]

Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
for a package?

I ask because one of my packages was NMUed earlier today. I have listed
myself in the LowThresholdNmu wiki page (that is, any packages for which
I am the sole maintainer). However, I did not think that placing myself
on that list meant anything other than "if you want to NMU one of my
packages, you can do so without coordination or delay, but still
otherwise observing the accepted practices for NMUS".

In this particular instance, the NMUer decided that in addition to
fixing an RC bug and another normal bug that I had not gotten around to
(which I genuinely appreciate), the NMUer also decided to do a bunch of
housekeeping, including a bunch of hygiene of files under debian/ and
also created a repo for the package in Salsa and unilaterally declared
the VCS of the package to be the new Salsa repo by populating d/control
(where the package did not have a VCS previously declared).

This appears, at least to me, to have rather substantially exceeded what
is appropriate for an uncoordinated NMU. In particular, this seems to be
inconsistent with the following paragraph from the Developer's
Reference, section 5.11.1:

* Does your NMU really fix bugs? ("Bugs" means any kind of bugs, e.g.
  wishlist bugs for packaging a new upstream version, but care should
  be taken to minimize the impact to the maintainer.) Fixing cosmetic
  issues or changing the packaging style in NMUs is discouraged.

I had thought of possibly suggesting an update to the documentation, but
I'm not sure that adding more words would make the matter any more
clear.

How do others suggest to handle this particular situation?

Regards,

-Roberto
-- 
Roberto C. Sánchez

Re: Change the expectation that emails should wrap at 80 characters

[Antonio Terceiro]

On Fri, Mar 14, 2025 at 02:49:26PM -0700, Soren Stoutner wrote:

On Wednesday, March 12, 2025 5:38:40 PM Mountain Standard Time Mario Limonciello
wrote:




>Mario Limonciello (hints of format=flowed support)


Thanks for the summary. I am of the camp of f=f.

At least with the MUA I'm using most of the time (Thunderbird) this is
the default, and no one has complained to me directly about it for any
email sent to the Kernel community or Debian community.

As it seems to be a polarizing discussion I do wonder if maybe it would
make most sense to have a "proper" vote to determine which way the
"silent majority" of developers actually lean?


I am planning on proposing a GR, but I want to take the time to make sure I 
word it well.  I
expect to be able to do so in the next few days.


Please don't. Mobilizing the entire project to discuss and vote on the 
exact format for sending plain text email is ridiculous. That silent 
majority is silent, because, well, this issue is completely irrelevant.


signature.asc
Description: PGP signature

Bug#1100579: general: After latest update problems with super key

[Andrey]

Package: general
Severity: normal
X-Debbugs-Cc: andrey.scherstobi...@gmail.com

Dear Maintainer,

After latest update:
can not unassign super key from overview action
can not assign super key to swith keyboard layout
due to onscreen indicator, swithing layout become very slow.
If you localize something, it slows things down a lot


Andrey

Re: Change the expectation that emails should wrap at 80 characters

[Tollef Fog Heen]

]] Soren Stoutner 

Because the primary interaction that most people have with 
Debian is through email, changing the way that interaction works 
is a big enough issue that I don’t see any other appropriate way 
of making it outside of a GR. 


Given we've never established this by way of a GR, there is 
clearly a way.


A GR is possibly the absolute worst tool in the toolbox for 
changing norms like this.


(Also, if you insist on posting HTML, please use proper HTML and 
not this bullshit HTML where you mark each line as a paragraph, 
with inline styling, and a quote marker instead of using the 
actual semantic HTML for, y'know, quotes.)


--  Tollef Fog Heen UNIX is user friendly, it's just picky about 
who its friends are

Re: Change the expectation that emails should wrap at 80 characters

[Stephan Verbücheln]

Am Samstag, dem 15.03.2025 um 07:47 -0700 schrieb Soren Stoutner:
> It’s important enough to me.

Not important enough to fix your formatting and encoding, it appears.

Regards


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

Re: STFU please (Re: Bits from DPL)

[Holger Levsen]

On Thu, Mar 06, 2025 at 02:54:32PM +0530, Pirate Praveen wrote:
> On 3/6/25 2:09 PM, Holger Levsen wrote:
> > so if the/a team says they cannot handle new members right now and thus
> > there should be no big announcement asking for new members, I very much
> > think this should be respected and not be ignored and spread on our
> > most visible mailing list, where there pain will be consumed with popcorn.
> This has been an long term recurring complaint without any tangible solution
> or a plan from the concerned team, so I think it is important for the whole
> project to address it, and not just leave it to the ftp team to resolve it
> (they ave not been able to address it by themselves for a long time).

yes, maybe, probably.

but the way it's been done here currently is utterly disrespectful und hardly
helpful at all.


-- 
cheers,
Holger

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

There are no jobs on a dead planet.


signature.asc
Description: PGP signature

Re: salsa.debian.org maintenance

[Manuel Choorly]

unsubscribe

сб, 15 мар. 2025 г. в 20:36, Alexander Wirt :

> Am Sat, Mar 15, 2025 at 08:38:03PM +0100 schrieb Alexander Wirt:
> > Hi,
> >
> > I will do a security upgrade for salsa right now, please expect some
> > service outage(s).
> And we are back.
>
> Thanks for your patience
>
> Alex
>
>

Re: Should GPU shaders be considered firmware?

[Bastian Blank]

On Wed, Mar 12, 2025 at 11:10:49AM +, Stephan Verbücheln wrote:
> Arguments for this:
>1. The shaders are loaded into the GPU, very much like firmware.

Shaders are not what makes the device function.  You need the firmware
first.

>2. They are not linked into any libraries or applications.

Actually they are.  They provide a specific interface that the library
expects, so they are linked to this library.

(Okay, so do the firmwares for the proprietary nvidia driver, which are
distinct to the "free" counterparts)

>5. They are required by the operating system or applications to make
>   use of hardware capabilities.

Nope, they are not required to run the hardware.  They implement a
specific capability on top of the existing hardware.  And also you can
run multiple instances of it (pseudo) concurrently on the same hardware.

You can not replace the firmware without resetting the hardware
completely to a known state.

> Arguments against:
4. Shaders are "general purpose" execution on the GPU hardware.

We also had a (in Debian only partially supported) case in the past: the
PS3 contained two distinct and incompatible PowerPC core setups.  Just
like this case of the GPU, you need special support to start code on
those separate CPU cores, called SPE.  With the arguments brought up
here, code run on those SPE could also be firmware, which makes no
sense.

But if you think further: what about FPGA programs.  Would that be
firmware?  FPGA are "general purpose" devices and those programs can do
everything in reason.

What about an alternative "firmware" for a GPU that just outputs
the Mandelbrot set, but does not longer make it a usable GPU?

So firmware is a piece of code that
- runs exclusively on a piece of hardware,
- provides an agreed on interface to a kernel oder user mode driver.

Bastian

-- 
There are certain things men must do to remain men.
-- Kirk, "The Ultimate Computer", stardate 4929.4

Re: Change the expectation that emails should wrap at 80 characters

[Stephan Verbücheln]

Am Montag, dem 03.03.2025 um 14:42 -0700 schrieb Soren Stoutner:
> Interesting.  I guess that text could be interpreted as “Do not send
> an HTML part, even if you also send a plain text part.”

Are you serious? That does not make any sense.

> Please don't send your messages in HTML; use plain text instead.
https://www.debian.org/MailingLists/index.html

How could it be more clear?

> However, I would appreciate it if this discussion were not hijacked
> to discuss HTML vs. plain text. 

The whole discussion requires that we know what the rules mean,
especially if you want to change them.

Regards


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

Re: Should GPU shaders be considered firmware?

[Stephen Kitt]

On Wed, 12 Mar 2025 20:58:50 +0100, Hakan Bayındır  wrote:
> > On 12 Mar 2025, at 18:09, Marco d'Itri  wrote:
> > On Mar 12, Hakan Bayındır  wrote:
> >> If we think that a shader is a firmware, any software running on the
> >> second socket on a system is also a firmware, since the program is
> >> running on a different CPU w.r.t. to Kernel.  
> > This is not how Linux actually works.  
> 
> Of course, this is the point. So the shaders.

I think Marco’s point is that the kernel runs on all CPUs in a system, not
just the first one.

Regards,

Stephen


pgpqG50SBNgrP.pgp
Description: OpenPGP digital signature

Re: Call for participation in tag2upload closed beta

[Simon Josefsson]

Yay!

I'm happy to beta-test this.  Exactly what features are required from
dgit to be able to use tag2upload?  Maybe I can offer myself to vet the
process as a package maintainer that only minimally uses dgit, assuming
that I can manage to install and get dgit to work on my machine.  A
simple 'dpkg -i' of 12.9 worked now, and I was able to run 'dgit build'
in my existing libntlm git clone.  I haven't been using dgit before
this, but maybe this is sufficient to count me as a dgit user.

Packages (for example): libntlm, cppi, git2cl, guile-fibers

/Simon

Sean Whitton  writes:

> Hello everyone,
>
> We are ready to start a closed beta for tag2upload.
>
> For the first stage, these are the kind of participants we want:
>
> - Individual maintainer or small team, where everyone is on board.
>   DDs and DMs are equally welcome.
>
> - (At least some of) the packages are uploaded relatively often.
>
> - Happy to perform an occasional upload that only touches d/changelog,
>   for testing.
>
> - Happy to risk breakage or lossage, including possible broken uploads.
>   We don't expect broken uploads, but one point of the beta is to
>   discover any problems of that kind.
>
> - You already use dgit to upload.
>
>   This is not because using tag2upload requires using dgit.
>   There are two reasons for this limitation at this stage:
>
>   There are some complications that will be avoided in git trees that
>   are already known to work fine with dgit.
>
>   On a social/pedagogical level, users of dgit will already be familiar
>   with some of our terminology etc.
>
> - Happy to tolerate the history of your package on dgit-repos diverging
>   a bit from what's on salsa.
>   (Interleaving dgit pushes and tag2upload will add some merges.)
>
> - Willing to tolerate rough edges!
>
> Just to note, we will not ask you to use tag2upload for every upload of
> the packages for which it is enabled.  Uploads done in the usual way can
> freely be done too.
>
> If you'd like to sign up, write to us at ,
> specifying a list of your packages for which we should enable tag2upload
> processing, and confirming you have your co-maintainers agreement.
>
> Or just reply to dgit-owner@ or on debian-devel if you have some
> questions first.
>
> For more information, see .
>
> For the tag2upload Delegates,


signature.asc
Description: PGP signature

Re: Call for participation in tag2upload closed beta

[Johannes Schauer Marin Rodrigues]

Hi Sean,

Quoting Sean Whitton (2025-03-15 02:49:58)
> - (At least some of) the packages are uploaded relatively often.

with the upcoming freeze, I do not expect too many uploads to be necessary (but
can be done if needed). But is that a problem?

> - You already use dgit to upload.

The wiki page says to use git-debpush from src:dgit. Which version of
git-debpush is new enough? Does the version from Bookworm work?

> If you'd like to sign up, write to us at , specifying
> a list of your packages for which we should enable tag2upload processing, and
> confirming you have your co-maintainers agreement.

No co-maintainers and happy to try out tag2upload for: box64, ldraw-parts-free,
pico-sdk, picotool, vcmi, img2pdf, plakativ

Co-maintainer (Jochen) agrees: sbuild

Thanks!

cheers, josch

signature.asc
Description: signature