Re: Change the expectation that emails should wrap at 80 characters
Soren Stoutner writes: > At this point in the discussion I would like to progress toward a decision. > > One way to do so would be a GR. On one hand, using a GR to modify one line > of the code of conduct for the mailing list seems like a rather large hammer > for a rather small problem. But on the other hand, many people feel strongly > enough about this that a GR might be the only mechanism where people will > feel like the outcome is fair. > > My question is, is there any other decision making process that would be > preferable to a GR to decide this issue? You seem to be under the impression that there's an emerging consensus in favour of your idea. From my reading of this thread, the only real consensus seems to be that format=flowed is a good idea (as a result of which I intend to persuade my mail setup to generate that when I've got a moment). I doubt that a GR is justified, especially if all it's going to end up doing is adding a recommendation for format=flowed to the CoC that isn't actually required for people to adopt the use of format=flowed. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Processing times for the NEW queue (was Re: Bits from DPL)
Hi Simon, * Simon Josefsson [2025-03-07 18:17]: Is it possible from your data sources to filter these two cases apart? It is not explicitly recorded, but I can deduce it from the data, as I have the name of the .changes file and can take everything before the first underscore (_) as source package name. For the sake of simplicity, I did not split the dataset into monthly chunks. Instead, I binned the processing times by four mutually exclusive outcomes. So, without further ado, these are the percentiles for all uploads to NEW from September 2012 [1] until January 2025: 33743 ACCEPTs 50% - 4 days, 18:10:30 90% - 42 days, 3:26:44 98% - 106 days, 12:47:56 24443 ACCEPTs (binNEW) 50% - 2 days, 1:25:25 90% - 13 days, 23:44:49 98% - 67 days, 23:07:27 6318 REJECTs 50% - 8 days, 4:03:34 90% - 98 days, 16:03:15 98% - 267 days, 4:23:37 1712 REJECTs (binNEW) 50% - 21:28:34 90% - 43 days, 0:35:03 98% - 173 days, 1:30:30 I'm pretty sure that you can fit exponential probability distributions on these, but that is work for another day. Cheers Timo [1] In case you are wondering what the significance of that date is, it is when the dak log files changed to the current format, and I was too lazy to implement parsing support for the older ones. It also means there are a few false negatives for my detection of binNEW uploads, but I doubt it changes the results by much. -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1099857: ITP: qtpyvcp -- Framework for LinuxCNC virtual control panels
Package: wnpp Severity: wishlist Owner: Steffen Moeller X-Debbugs-Cc: debian-devel@lists.debian.org, moel...@debian.org * Package name: qtpyvcp Version : 5.0.2 * URL : https://www.qtpyvcp.com/ * License : GPL-2 Programming Lang: Python Description : Framework for LinuxCNC virtual control panels QtPyVCP is a Qt and Python based framework for building virtual control panels (VCPs) for the LinuxCNC machine controller. A set of readily usable VCPs for lathes and mills up to 5 axes are available and in routine use through the globe. . The QtPyVCP projects strives towards a no-code, drag-and-drop system for making simple VCPs, as well as a straightforward, flexible and extensible framework to aid in building complex VCPs. QtPyVCP provides graphical infrastructures for lathes and mills. It is optically very appealing. The package LinuxCNC, which is used underneath, is already shipping with Debian and would miss out without this addition. The package will be uploaded to the electronics-team. Had though about the science-team, but the direct contact for QtPyVCP is the electronics which drives and controls the motors, so it seems like the better fit. No sponsoring required.
Re: The Project Gutenberg license, packages using its books as testdata
On Saturday, March 8, 2025 7:46:58 PM MST Maytham Alsudany wrote: > Hi debian-legal, > > Today I was reviewing a package[1] that contains a file[2] from Project > Gutenberg. d/copyright had listed it under Public-Domain, and it would > seem that way from the website[3] where it says "Public domain in the > USA", but the header in the file indicated that it was licensed "under > the terms of the Project Gutenberg License". > > This package has been accepted into Debian through NEW in the past with > the d/copyright in this state, indicating that the FTP Masters are fine > with it (I'm just guessing). The package was since removed and is now > being reintroduced. My guess is that the FTP Masters took the statement in debian/copyright that the file was in the public domain at face value and didn’t catch the complications with the Project Gutenberg License. > This is not the only package to contain stuff from Project Gutenberg, > codesearch.d.n[4] says 98 results when searching for "Project Gutenberg > License". That is concerning. I am taking the liberties to copy my response to debian-devel to raise greater awareness of the problem as it affects a large number of packages. The full text of the original email with the lengthy analysis is at: https://lists.debian.org/debian-legal/2025/03/msg4.html > Is this really a public domain license? It doesn't seem to be that way > after I initially read it, hence why I'm sending this mail. I've > included the license (sourced from [5]) below with some comments. > [snip excellent analysis] I agree with your analysis, the Project Gutenberg license is not DFSG-free, most particularly because of the restrictions on commercial use. However, as the license points out, some of the books they host are in the public domain (although it appears that they only verify they are in the public domain in the United States, so it would be up to the package maintainer to verify they are in the public domain worldwide). Also, as you pointed out in your analysis, to exercise the public domain option the package maintainer would need to verify that “all references to Project Gutenberg are removed”, which you have stated is not currently the case with this package and doesn’t appear to be the case with other packages that codesearch identified. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1099859: ITP: python-local-agent-rs -- Proton VPN local agent for managing connections
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com * Package name: python-local-agent-rs Version : 1.4.3 Upstream Contact: Proton Technologies * URL : https://github.com/ProtonVPN/local-agent-rs * License : GPL-3+ Programming Lang: Python and Rust Description : Proton VPN local agent for managing connections Local-agent-rs is a ProtonVPN project that provides a Rust library for communicating with ProtonVPN's LocalAgent. Its purpose is to promote efficiency and security in the integration of ProtonVPN features across different clients. . It is responsible for: - Communication with ProtonVPN: - Manages the connection between the ProtonVPN client and ProtonVPN servers. - Handles authentication, key and certificate exchange, and other operations required to establish a secure connection. - Python Bindings: - Includes Python bindings for the Rust library, allowing Rust code to be used in Python applications. - Integrate LocalAgent functionality into ProtonVPN clients written in Python.
Re: The Project Gutenberg license, packages using its books as testdata
On Sat, 2025-03-08 at 20:24 -0700, Soren Stoutner wrote: [...] > > I agree with your analysis, the Project Gutenberg license is not DFSG- > free, most particularly because of the restrictions on commercial use. It appears this has been discussed before: https://lists.debian.org/debian-legal/2017/08/msg1.html -- Maytham signature.asc Description: This is a digitally signed message part
Re: TC decision on ownership of top-level filesystem aliases - #1091995
Hello, On Thu 06 Mar 2025 at 11:25am +01, Helmut Grohne wrote: > Can you clarify how you understand policy here? > > I read it as systemd is not performing an installation here and > therefore does not violate the present policy. If your reading is > different, we should likely clarify policy on this aspect. I read it that way too. -- Sean Whitton signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Le Fri, Mar 07, 2025 at 11:42:10AM -0700, Soren Stoutner a écrit : > In the original GR, one of the options that lost was for Debian to host two > sets of installer > images, one with non-free firmware and one without, and for users to be able > to make an > informed decision before downloading the installer. > > https://www.debian.org/vote/2022/vote_003#textc > > This option did not prevail in the vote, but it would have been my preferred > choice (I was > not a Debian Developer at the time and so did not vote, but I did follow the > discussion). True, but the GR does not prevent Debian of providing a second set of installer images. What is required is someone to do the work, as usual. Cheers, -- Bill. Imagine a large red swirl here.
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Sat, Mar 08, 2025 at 11:16:40PM +0100, Simon Josefsson wrote: > Aurélien COUDERC writes: > > > Le 8 mars 2025 21:09:00 GMT+01:00, Simon Josefsson a > > écrit : > > > >>I read this outcome as fairly clear message that, no, Debian does not > >>want to provide a second set of installer images, and is not interested > >>in contributions to make them. > > Hi Simon, The voting round this issue had nuance, as you can see. In many ways, this reflected the relative difficulty of continuing to do things as we had been doing. Nobody was keen to continue duplicating effort for the sake of duplicate effort and the wording reflected this. There had been a *lot* of discussion over approximately two years, a couple of Debconfs about the fact that some things could not be achieved without non-free firmware potentially even at early stage in the installer. > > > > What the GR says is that you cannot dump that work on the shoulders of > > the people currently maintaining the installer, coordinating the > > releases… > > Absolutely. > I would be happy if my perception of the situation is wrong, and that > fully free official debian installer images was a welcome contribution. > Is that really the case? > We had a "fully free" installer and a large non-free archive from which many people pulled firmware to make their hardware work fully. Non-free-firmware being pulled out of the rest of non-free was a recognition of that fact and a distancing of firmware from the rest of non-free. > > Andy Cater's post is hard to parse for me. Andy, did you intend it as a > sarcastic comment about something that has been beating to death too > many times already and has no chance of becoming reality? Or was it a > real invitation for discussion and accept contributions? My earlier > interactions about this issue were stuck on a deal-breaker: > It is slighttly sarcastic, yes, but it also outlines exactly what is involved if you want to pursue a fully free installer (again). Having been involved in explaining the difference between the installer and the unofficial installer containing firmware far too many times, it was difficult to justify an idealogical separation that made it hard for people to install Debian (or impossible if you were visually impaired, potentially). Maintaining two sets of images would be hard. Testing two sets of images at point release time was also hard. > Andy Cater: > > Please feel free to pick up the code and generate the second set of > > installer images, maintaining the code to exclude non-free-firmware. > > If I understand what you imply here correctly, this is still a problem. > Proper fully free images cannot be generated by going through an > intermediate step that involve non-free software. > You can build an image that contains no firmware. You can build an image that contains only free firmware. You can build an image that contains non-free firmware. Each of these can be built from the code in the Debian archive. The scripts to produce each of these are slightly different: you would need to satisfy yourself that every time you regenerate images you have not inadvertently included inappropriate firmware somewhere along the line. I'd suggest a long read through the mailing list archives and watching a couple of the videos from Sledge. It is harder than it looks and relies on a *lot* of effort to do this. With every good wish, as ever, Andy Cater (amaca...@debian.org) > /Simon
Re: Change the expectation that emails should wrap at 80 characters
On Saturday, March 8, 2025 4:23:56 PM MST Philip Hands wrote: > Soren Stoutner writes: > > At this point in the discussion I would like to progress toward a decision. > > > > One way to do so would be a GR. On one hand, using a GR to modify one line > > of the code of conduct for the mailing list seems like a rather large hammer > > for a rather small problem. But on the other hand, many people feel > > strongly > > enough about this that a GR might be the only mechanism where people will > > feel like the outcome is fair. > > > > My question is, is there any other decision making process that would be > > preferable to a GR to decide this issue? > > You seem to be under the impression that there's an emerging consensus > in favour of your idea. Yes, I feel like there are a majority of Debian Developers who are in favor of making the change that I propose, partially based on the number of people who have commented only once in the conversation with a short message in favor of the change. I also see a small number of Debian Developers who are strongly opposed to the change. I think those who are against the change feel much more strongly about their position than those who are for the change, but my sense is that if it goes to a GR vote the change will pass. -- 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
Aurélien COUDERC writes: > Le 8 mars 2025 21:09:00 GMT+01:00, Simon Josefsson a > écrit : > >>I read this outcome as fairly clear message that, no, Debian does not >>want to provide a second set of installer images, and is not interested >>in contributions to make them. > > Your positions in this thread try to make it sound much more black and > white than it needs to be, than the GR text is written and than my > reading of the current consensus in Debian. > > Like others have said you can start working on alternate fully free > images. We've seen in the thread that there's interest in it. (I would > use them. I did like the fully free images although I would knowingly > install firmware on top of them.) > > What the GR says is that you cannot dump that work on the shoulders of > the people currently maintaining the installer, coordinating the > releases… > > That you're trying to impose so many preconditions before even > starting the work is OTOH an indication to me that you're not really > interested in doing it in the context of Debian. I would be happy if my perception of the situation is wrong, and that fully free official debian installer images was a welcome contribution. Is that really the case? My reading of the vote outcome is that Debian Project made a "statement on an issue of the day" that there would be no more fully free images: The Debian Project also makes the following statement on an issue of the day: ... We will publish these images as official Debian media, replacing the current media sets that do not include non-free firmware packages. This won over the alternative that permit both as official media: We will publish these images as official Debian media, alongside the current media sets that do not include non-free firmware packages. What is the mechanism to issue a new statement on an issue of the day? Does it require a new vote? What I'm looking for is to confirm a shift of sentiments towards a position like this: We will publish images with non-free firmware as official Debian media, and encourage contributors who are interested in fully free installer images to offer them separately and that these are also considered official Debian media. Andy Cater's post is hard to parse for me. Andy, did you intend it as a sarcastic comment about something that has been beating to death too many times already and has no chance of becoming reality? Or was it a real invitation for discussion and accept contributions? My earlier interactions about this issue were stuck on a deal-breaker: Andy Cater: > Please feel free to pick up the code and generate the second set of > installer images, maintaining the code to exclude non-free-firmware. If I understand what you imply here correctly, this is still a problem. Proper fully free images cannot be generated by going through an intermediate step that involve non-free software. /Simon signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Am Samstag, dem 08.03.2025 um 14:51 +0100 schrieb Johannes Schauer Marin Rodrigues: > If you don't trust the vendor, then it makes no difference whether or > not new official firmware/microcode can be uploaded/flashed or not. > If you don't trust the vendor, then the initial microcode that came > with your device might already be doing things that go against your > interests. The trust relationships are more complex than you put it. You have to trust the chip vendors, the OEMs, the merchants, the delivery company, the hotel room service etc. etc. Since Snowden, we know that custom hardware bugs installed by anyone in the supply chain are a real thing. The recommendation for risk groups like journalists and lawyers nowadays is to buy random hardware from the store and pay with cash. However, I agree with you that we do not have a lot of options when it comes to affordable consumer hardware. Even the various projects which try to create openness still depend on proprietary firmware. The situation is improving compared to what it used to be, but we still have a long way to go. Regards Stephan signature.asc Description: This is a digitally signed message part
Re: Processing times for the NEW queue (was Re: Bits from DPL)
Hello, On Fri 07 Mar 2025 at 06:17pm +01, Simon Josefsson wrote: > Your graph and statistics on this is great, thank you! > > Timo Röhling writes: > >> 2. Source packages going through NEW merely because they introduce new >> binary packages are typically processed faster than completely new >> ones. > > Good point. Therefore, I think your graph gives a biased view for > anyone who thinks of NEW processing time to be the same as processing > time to add a new source package to the archive. Just to note that per the FTP team docs[1] we perform a full copyright and license review even if it's just a SONAME bump. I do not think we should be doing this, but it's the team policy. [1] https://salsa.debian.org/ftp-team/manpages -- Sean Whitton signature.asc Description: PGP signature
Re: Processing times for the NEW queue (was Re: Bits from DPL)
Hello, Thank you, Timo, for all the info. I think you're quite right about the psychological impacts and the comparison with the level crossing is apt. -- Sean Whitton signature.asc Description: PGP signature
Bug#1099862: ITP: passim -- A local caching server
Package: wnpp Severity: wishlist Owner: Mario Limonciello X-Debbugs-Cc: debian-devel@lists.debian.org, supe...@gmail.com * Package name: passim Version : 0.1.9 * URL : https://github.com/hughsie/passim * License : LGPL2.1 Programming Lang: C Description : A local caching server Passim is used to cache small files (such as those from a CDN) to be able to share with other clients on the local network that would otherwise be downloading the same files. I'm planning to maintain it in the debian-efi team as it is an optional dependency for fwupd. Fwupd can use it to fetch files from the CDN and then share them with other clients on the same local network.
Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)
Hello,
On Fri 07 Mar 2025 at 10:11am GMT, Simon McVittie wrote:
> If the public NEW-queue viewer at https://ftp-master.debian.org/new.html
> is an accurate reflection of the files that the ftp team would look at
> first in their internal processes, then the top changelog entry (but only
> the top changelog entry, and not later ones), debian/README.source, or
> the copyright file itself would be the places to put evidence supporting
> the copyright file being correct.
Just to note that this order is not the order in which they get
presented to us. Instead, there's some logic in 'dak process-new' to
try to sort them helpfully.
It's got some issues, like if a package has a note attached to it then
it gets sorted last, the idea being that the person who left the note
hopefully will get prompted to look at it again in response to an e-mail
from the uploader. That causes things to get stuck at the bottom for
ages, though.
There's command line options to change the order a bit; I think
basically we can choose whether or not binNEW packages get sorted first.
I have that turned off in my shell aliases; I don't know about other
team members.
> A change history of problems that were reported and fixed doesn't seem
> like something that would speed up the ftp team's work: if they feel that
> they have to review a change history *in addition* to reviewing the uploaded
> artifacts, I don't see how that would take a shorter time than only
> reviewing the uploaded artifacts. The only way this could help is if the
> ftp team were willing to trust the information from peer review and do
> a less in-depth review of packages that have had a positive peer review,
> but I have not seen any indication from the ftp team that they would be
> prepared to do that.
Yes.
> So I think it could be better to frame this in terms of finding a good
> place to put supporting evidence ("I know the licensing situation
> in contrib/foo/ looks strange at first glance, but in fact it's OK
> because..."), rather than somewhere to put a change history of previous
> negative feedback being addressed. The ftp team don't need to know about
> the existence of previous, wrong packages, they are only approving or
> rejecting the hopefully-correct final package that has been submitted
> for their review.
Comments in d/copyright or d/changelog help.
--
Sean Whitton
signature.asc
Description: PGP signature
Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)
Hello Charles, Thanks. Please put prominent links to these three places: - Policy 2.3 -- this covers 90% of my NEW rejects Based on my experience processing NEW, a lot of DDs don't seem to really have an understanding of the requirements explained here. Including me, before I joined the ftp team. I updated this section to try to capture what I learned. - Policy 12.5 -- covers some of the othe REJECTs - the REJECT-FAQ. -- Sean Whitton signature.asc Description: PGP signature
Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)
Charles Plessy writes: >>I suggest to use 'lrc' in the pipeline. I already do this for many >>packages, and I just add >> >>- >>https://salsa.debian.org/debian/licenserecon/raw/main/debian/licenserecon.yml > > Looks good! > >>Yes, false positives happens, and it doesn't always handle Autotools >>projects with a lot of generated files with complex licenses well. > > Here we are in the context of entirely new packages, so we can explore > the idea that packages need either to be licenserecon-clean, or to > include a note why they can't, in order to get a review. For instance, > the form to request a review (issue, MR, or service counter, I am not > sure yet), could contain a checklist item about this. You can add exceptions, similar to lintian overrides, for known false positives: https://salsa.debian.org/debian/gssproxy/-/blob/master/debian/lrc.excludes?ref_type=heads https://salsa.debian.org/go-team/packages/golang-github-sigstore-protobuf-specs/-/blob/debian/sid/debian/lrc.config?ref_type=heads I use it for a bunch of packages, although I have to admit that on complex false positives I tend to disable it rather than trying to figure out how to write the exception file and/or file bug reports (bugs which tends to more often tend to be in licensecheck rather than licenserecon). It would be nice to add this to the standard Salsa CI pipeline: https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/395 The difference of having a 'include' statement in debian/salsa-ci.yml is not that different from adding some 'variables:' to enable a lrc-job, so it is not critical to add it to the standard pipeline. Maybe if more people start to use it we gain more confidence in it as a useful tool, and later on add it to the standard pipeline. /Simon signature.asc Description: PGP signature
Bug#1099808: ITP: golang-github-jesseduffield-gocui -- minimalist console user interfaces Go library
Package: wnpp Severity: wishlist Owner: Jongmin Kim X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-jesseduffield-gocui Version : 0.4+git20250220.b376cb0 Upstream Contact: Jesse Duffield * URL : https://github.com/jesseduffield/gocui * License : BSD-3-clause Programming Lang: Go Description : minimalist console user interfaces Go library This package provides the minimalist Go package aimed at creating the Console User Interfaces. . Following features are available: * Minimalist API * Views (the "windows" in the GUI) implement the interface io.ReadWriter * Support for overlapping views * The GUI can be modified at runtime (concurrent-safe) * Global and view-level keybindings. * Mouse support * Colored text * Customizable edition mode * Easy to build reusable widgets, complex layouts This package was REMOVED[1], but it need to be packaged again for lazygit/0.48.0[2,3]. [1] https://bugs.debian.org/1081322 [2] https://bugs.debian.org/908894 [3] https://lists.debian.org/debian-go/2025/03/msg00041.html This package is a fork of golang-github-jroimartin-gocui. However, due to significant differences[4], the original can no longer be used for lazygit. This fork is actively maintained[5], so I will reintroduce it into Debian. [4] https://github.com/jroimartin/gocui/compare/master...jesseduffield:gocui:master [5] https://github.com/jesseduffield/gocui/commits/master
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Bill Allombert writes: > Le Fri, Mar 07, 2025 at 07:33:53PM +0100, Simon Josefsson a écrit : >> pan...@disroot.org writes: >> >> > I urge Debian to rethink its decision to officially include non-free >> > firmware and correct the social contract. Instead of making non-free >> > firmware the default, Debian should ensure that users consciously >> > choose to install it while being made aware of the implications. >> >> I agree and would personally come back to use Debian on some of my >> laptops if there was a supported way to install Debian from official >> installer images that did not promote non-free software by including >> firmware on them. >> >> The recent AMD Microcode vulnerability is a good case-study on the >> dangers of permitting non-free code to run on your CPU: >> >> https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking > > Do not fall for the marketing. What was broken was the DRM which > forbid you to fix the firmware on your own CPU. This is no more a > vulnerability than letting you boot your own OS. My point was that there is no reasonable way to gain confidence about security properties of any piece of non-free microcode. Everyone can now produce AMD microcode that corrupts your machine in advanced ways that evade detection, but we don't know if such malicious corruption is included in the official microcode. Having source code for the microcode would help gain confidence in it, and is the reasonable request. If the request is denied, I would consider the vendor not trustworthy and look into options. This is a similar vulnerability as installing a non-free operating system like Windows. You essentially have to trust the vendor to provide you with software, which you have no good way of auditing and ultimately end up in their control. It wouldn't be a big problem if software were free of vulnerabilities and never needed updates, but just like Windows has had bugs, microcode have bugs. https://www.gnu.org/philosophy/free-software-even-more-important.html /Simon signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Le 8 mars 2025 13:43:26 GMT+01:00, Simon Josefsson a écrit : > Having source code for the >microcode would help gain confidence in it, and is the reasonable >request. If the request is denied, I would consider the vendor not >trustworthy and look into options. How about you try asking the vendors for that instead of speculating ? Unless you come back with very unexpected good news you definitely need to look for alternatives. As for Debian as a project we've voted on the topic not so long ago and decided we want to ship available firmware with the default installer. I don't see which new bits of information would make us vote differently now. Happy hacking, -- Aurélien
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Sat, Mar 08, 2025 at 02:51:29PM +0100, Johannes Schauer Marin Rodrigues wrote: If you don't trust the vendor, then it makes no difference whether or not new official firmware/microcode can be uploaded/flashed or not. If you don't trust the vendor, then the initial microcode that came with your device might already be doing things that go against your interests. Of course we cannot have much confidence in a piece of microcode of which we do not have the source code. But we also cannot have much confidence in a piece of hardware with non-flashable firmware of which we don't have the vhdl/verilog sources. So what is the difference? This is an old argument that didn't work for people holding this opinion before and do I wouldn't expect it to work now. I don't expect that people's opinions on this matter can be changed. -- WBR, wRAR signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Johannes Schauer Marin Rodrigues writes: > Hi, > > Quoting Simon Josefsson (2025-03-08 13:43:26) >> My point was that there is no reasonable way to gain confidence about >> security properties of any piece of non-free microcode. Everyone can now >> produce AMD microcode that corrupts your machine in advanced ways that evade >> detection, but we don't know if such malicious corruption is included in the >> official microcode. Having source code for the microcode would help gain >> confidence in it, and is the reasonable request. If the request is denied, I >> would consider the vendor not trustworthy and look into options. > > I do not understand something about this argument. > > If you don't trust the vendor, then it makes no difference whether or not new > official firmware/microcode can be uploaded/flashed or not. If you don't trust > the vendor, then the initial microcode that came with your device might > already > be doing things that go against your interests. > > Of course we cannot have much confidence in a piece of microcode of which we > do > not have the source code. But we also cannot have much confidence in a piece > of > hardware with non-flashable firmware of which we don't have the vhdl/verilog > sources. So what is the difference? These are good questions and I believe that if you can see that there is a difference between the two positions, it is easier to appreciate the need for fully free operating systems, and that not offering fully free Debian installer images (even as an option) is problematic. Many years ago I also reacted the same way you and many others do -- "there is no difference between the act of loading non-free firmware into my hardware and then using it compared to the act of using my hardware that contains non-free software in it". However I have come to realize that, yes, there is a significant and fundamental difference between these two cases. I'm not good at explaining this difference, and I believe the reason so many still believe there is no differeence between these positions suggests that we need better ways to articulate the difference. I'm sure most people here are familiar with RMS' argument on this: https://www.gnu.org/distros/free-system-distribution-guidelines.html The way that I came to understand and appreciate the difference between the act of loading non-free firmware into hardware, and the act of using non-free firmware in hardware, is to first acknowledge that hardware is different from software. Software people often think that their ideals on how to design things should apply equally to hardware. Hardware people often think the reverse. I've seen these patterns collide many times, notably when I was involved with Yubico. The escape mechanism is to acknowledge that there has to be different ideals. You don't have to design hardware the way you design software, and vice versa. If you are stuck applying the same ideals for both concepts, it is harder to work out what is right for software and what is right for hardware separately. And harder for experts to work efficiently within their own area. So what are good ideals for software? There are many patterns to subscribe to, but I believe https://www.gnu.org/philosophy/free-sw.html and https://www.gnu.org/distros/free-system-distribution-guidelines.html are worthy to aspire to. Non-free firmware doesn't belong here. I'm not a hardware person, so I'm less confident what good designs for hardware should be, and it seems there is less consensus what the desirable properties really are. One fundamental property that I would like is that I want to be able to examine and modify all steps that ultimately lead to production of the hardware. I'm sure there are more properties that are desirable. It is easy to see that this is a required but not sufficient condition: otherwise you can end up producing a closed device ecosystem like an iPhone. > If I don't trust vendor X, then I cannot buy hardware from them independent of > whether or not the vendor allows me to flash proprietary binary blobs from > them. If I do trust vendor X, then why would I not trust their proprietary > binary blobs? One difference is that you could chose to trust their hardware (CPUs) but don't trust their software (non-free firmware). Consumer level protection in society is generally different when I buy a hardware product compared to if I'm granted a license to use some software. If I buy a bike or helmet it has to meet certain criteria for it to be allowed to be sold (at least where I live) but different laws apply if I use a piece of software under some legal terms of services. Just because I place trust in entity X for the purpose of A doesn't mean that I necessarily must trust entity X for the purpose of B. That is the slippery slope that vendors want you to walk into so they can excercise more control. > I do not think you will find many on this list who will disagree with the > sentiment that it w
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Sat, Mar 08, 2025 at 02:51:29PM +0100, Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting Simon Josefsson (2025-03-08 13:43:26) > > My point was that there is no reasonable way to gain confidence about > > security properties of any piece of non-free microcode. Everyone can now > > produce AMD microcode that corrupts your machine in advanced ways that evade > > detection, but we don't know if such malicious corruption is included in the > > official microcode. Having source code for the microcode would help gain > > confidence in it, and is the reasonable request. If the request is denied, > > I > > would consider the vendor not trustworthy and look into options. > > I do not understand something about this argument. > > If you don't trust the vendor, then it makes no difference whether or not new > official firmware/microcode can be uploaded/flashed or not. If you don't trust > the vendor, then the initial microcode that came with your device might > already > be doing things that go against your interests. Trust in wendors (actually also their trustworthiness) is a function of time. Remember when Github was bought by Microsoft? Remember when Twitter was bought by -- uh -- whatever? Cheers -- t signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Bill Allombert writes: > True, but the GR does not prevent Debian of providing a second set of > installer images. What is required is someone to do the work, as usual. We already had those images before. The winning choice said: We will publish these images as official Debian media, replacing the current media sets that do not include non-free firmware packages. There was another almost identical choice on the vote that instead said: We will publish these images as official Debian media, alongside the current media sets that do not include non-free firmware packages. I read this outcome as fairly clear message that, no, Debian does not want to provide a second set of installer images, and is not interested in contributions to make them. This triggered me to reduce Debian usage and contribute more to the Guix and Trisquel projects (the latter build udebs from Ubuntu packages and maintain a debian-installer fork). /Simon signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Sat, Mar 08, 2025 at 06:59:45PM +, Bill Allombert wrote: > Le Fri, Mar 07, 2025 at 11:42:10AM -0700, Soren Stoutner a écrit : > > In the original GR, one of the options that lost was for Debian to host two > > sets of installer > > images, one with non-free firmware and one without, and for users to be > > able to make an > > informed decision before downloading the installer. > > > > https://www.debian.org/vote/2022/vote_003#textc > > > > This option did not prevail in the vote, but it would have been my > > preferred choice (I was > > not a Debian Developer at the time and so did not vote, but I did follow > > the discussion). > > True, but the GR does not prevent Debian of providing a second set of > installer images. What is required is someone to do the work, as usual. > For anyone interested - others will happily provide instructions as needed but may not wish to carry out the work involved themselves, having already done this for some years: Please feel free to pick up the code and generate the second set of installer images, maintaining the code to exclude non-free-firmware. Don't forget to also do this for debian live media images and coordinate this for all architectures,while ensuring that these are reproducible. Please also be prepared to deal with the number of users who complain that the installer doesn't work for them because they no longer have sound, WiFi or whatever. Please be prepared to help them install tarballs of non-free firmware as appropriate to solve each issue raised. Don't forget to coordinate wiki and Debian web site edits accordingly. Please also be prepared to carry out release testing for each image that is not including firmware per point release every couple of months - I'm assuming you'll be more than happy to check twenty or thirty tests of images yourself. [This last should only take about four hours if you can persuade others to help but may take longer if you are working on your own]. Thank you for volunteering to carry out these tasks. With every good wish, as ever, Andy Cater (amaca...@debian.org) > Cheers, > -- > Bill. > > Imagine a large red swirl here. >
Bug#1099848: ITP: greaseweazle -- Host tools for Greaseweazle
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: greaseweazle Version : 1.21 Upstream Author : Keir Fraser * URL : https://github.com/keirf/greaseweazle * License : Unlicense Programming Lang: Python Description : Host tools for Greaseweazle This package provides tools to access a floppy drive at the raw flux level, using a Greaseweazle interface device. . It can also convert between supported image formats (Acorn, Akai, Amiga, Apple II, Atari 8-bit and ST, Coco, Commodore C64, DEC RX-01 and RX-02, Dragon, Ensoniq, Epson QX-10, GEM, HP, PC, Macintosh, MSX, Northstar, Olivetti M20, PC-98, Sega, Thomson, and various others. This package will be maintained in the Python team.
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Le 8 mars 2025 21:09:00 GMT+01:00, Simon Josefsson a écrit : >I read this outcome as fairly clear message that, no, Debian does not >want to provide a second set of installer images, and is not interested >in contributions to make them. Your positions in this thread try to make it sound much more black and white than it needs to be, than the GR text is written and than my reading of the current consensus in Debian. Like others have said you can start working on alternate fully free images. We've seen in the thread that there's interest in it. (I would use them. I did like the fully free images although I would knowingly install firmware on top of them.) What the GR says is that you cannot dump that work on the shoulders of the people currently maintaining the installer, coordinating the releases… That you're trying to impose so many preconditions before even starting the work is OTOH an indication to me that you're not really interested in doing it in the context of Debian. -- Aurélien
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Hi, Quoting Simon Josefsson (2025-03-08 13:43:26) > My point was that there is no reasonable way to gain confidence about > security properties of any piece of non-free microcode. Everyone can now > produce AMD microcode that corrupts your machine in advanced ways that evade > detection, but we don't know if such malicious corruption is included in the > official microcode. Having source code for the microcode would help gain > confidence in it, and is the reasonable request. If the request is denied, I > would consider the vendor not trustworthy and look into options. I do not understand something about this argument. If you don't trust the vendor, then it makes no difference whether or not new official firmware/microcode can be uploaded/flashed or not. If you don't trust the vendor, then the initial microcode that came with your device might already be doing things that go against your interests. Of course we cannot have much confidence in a piece of microcode of which we do not have the source code. But we also cannot have much confidence in a piece of hardware with non-flashable firmware of which we don't have the vhdl/verilog sources. So what is the difference? If I don't trust vendor X, then I cannot buy hardware from them independent of whether or not the vendor allows me to flash proprietary binary blobs from them. If I do trust vendor X, then why would I not trust their proprietary binary blobs? I do not think you will find many on this list who will disagree with the sentiment that it would be great if we had sources, schematics etc for many more things. On the other hand, I don't think you can currently buy a device that is capable to run, for example, a modern web browser and is fully open. This is why I voted in the last GR as I did. I'm typing this on an MNT Reform which is probably among the most open computers you can buy today but the chips in it are *not* open silicon. Yes, it would be great if they were and it would be great if the firmware blobs I need would not be proprietary. But I already chose to trust the manufacturers of the chips in my laptop or otherwise I would not be typing these lines. Why would I trust the silicone from vendor X and distrust the firmware/microcode from vendor X? Having non-free-firmware enabled by default in the Debian installer just continues pursuing a trust relationship you already decided on entering when you bought the hardware, no? Thanks! cheers, josch signature.asc Description: signature
Re: Debian Policy 4.7.2.0 released
Hello, On Thu 27 Feb 2025 at 06:11pm +09, Charles Plessy wrote: > Le Thu, Feb 27, 2025 at 03:02:08PM +0800, Sean Whitton a écrit : >> >> Packages that already install programs to /usr/games, where another >> package installs a program of the same with different functionality >> to a different directory on the default PATH, may continue to do so. > > Hi Sean, > > I would like to know why this exemption is only given to games? We have > scientific software that have been installing conflicting binaries for > more than one decade without any of their users complaining about it, > and I do not understand why it becomes a priority to change them now. I didn't know about this. Please share some examples on debian-policy@lists.d.o. -- Sean Whitton signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Le Fri, Mar 07, 2025 at 07:33:53PM +0100, Simon Josefsson a écrit : > pan...@disroot.org writes: > > > I urge Debian to rethink its decision to officially include non-free > > firmware and correct the social contract. Instead of making non-free > > firmware the default, Debian should ensure that users consciously > > choose to install it while being made aware of the implications. > > I agree and would personally come back to use Debian on some of my > laptops if there was a supported way to install Debian from official > installer images that did not promote non-free software by including > firmware on them. > > The recent AMD Microcode vulnerability is a good case-study on the > dangers of permitting non-free code to run on your CPU: > > https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking Do not fall for the marketing. What was broken was the DRM which forbid you to fix the firmware on your own CPU. This is no more a vulnerability than letting you boot your own OS. Cheers, -- Bill. Imagine a large red swirl here.
Re: Binary conflict between Midnight Commander and MinIO Client
On Thu, 2025-03-06 at 06:58 +0100, Helmut Grohne wrote: > On Sun, Apr 21, 2024 at 05:32:37PM +, Mathias Gibbens wrote: > > I like that idea, thanks! It would be easy enough to add that to > > Incus' $PATH while making it simple for an end user to modify their > > local environment to directly use `mc` if they wish. > > Let me express a concern regarding this route. If we modify $PATH (in > packages or as an end user), that may subtly break other packages > expecting a particular behavior. Let me sketch a few examples. Ultimately I ended up packaging the MinIO client binary as `/usr/bin/minio-client` and wrote a brief readme for the package describing the naming conflict with mc. Then on the Incus side I simply adjusted the binary name it looks for when searching for the MinIO client. Mathias signature.asc Description: This is a digitally signed message part
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
The ideal laptop in my dreams is running pure Debian on a RISC-V CPU, and all firmware from BIOS/EFI to peripheral devices has the source code available with a license which allows the free-software community to maintain it and remove undesired features. Unfortunately, even though we are getting closer every year, we do not have such hardware yet for the greater market for a reasonable price. If you want to run an Intel- or AMD-based laptop, you have no choice but to run their firmware, BIOS, EFI, microcode etc. More firmware is required for video and network devices. Unfortunately, you cannot run much of it without proprietary firmware, no matter if that firmware is on the Debian CD or not. Please note that firmware is something different than drivers. The best option that I see at the moment with commodity hardware is to buy hardware which does not require proprietary drivers. So at least the main CPU and memory is free from undesired code. This is much easier today then it used to be. I run my primary workstations without any proprietary driver, application or library for years. I really feel with you. I really wish there were more options without proprietary firmware. But I not see any options. The POWER9-based Raptor systems are advertised with free firmware, but they use AMD video cards and Broadcom Ethernet. So I think that what they mean by free firmware only applies to the BIOS/EFI. The coreboot and libreboot projects also need some blobs for Intel and AMD based systems. Microcode is fortunately a thing of the past. It is an idea from the 1960's CISC design which is uncommon and unnecessary for RISC processors. So the most important goal is to get develop laptop with free EFI and free video firmware. Regards Stephan signature.asc Description: This is a digitally signed message part
