Re: New appointment for the Debian Technical Committee: Paul Tagliamonte
Hello, On Mon 10 Mar 2025 at 06:54pm +01, Andreas Tille wrote: > Dear fellow developers, > > As defined by our constitution (§6.2.2), the Debian Technical Committee > has recommended the appointment to the committee of: > > * Paul Tagliamonte > > I agree with their recommendation, and hereby appoint Paul as member of > the Technical Committee, effective immediately. Simon McVittie's term > ended at the end of 2024, thanks to Simon for his work on the Debian > Technical Committee. It was my term that ended, Simon's finished a while back. -- Sean Whitton signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Mon, Mar 10, 2025 at 11:56:28AM +0100, Simon Josefsson wrote: I still haven't heard arguments why people refuse to use an installer that comes with non-free firmware, asks whether this firmware should be used, and if answered "no", none of this non-free firmware ends up in the installed system. The resulting system is free regardless whether there was non-free firmware on the installation images. https://www.gnu.org/distros/optionally-free-not-enough.html https://www.gnu.org/philosophy/install-fest-devil.html I've missed the second link initially, so I'll quote it for people who missed it too or decided not to click: """ My new idea is that the install fest could allow the devil to hang around, off in a corner of the hall, or the next room. (Actually, a human being wearing sign saying “The Devil,” and maybe a toy mask or horns.) The devil would offer to install nonfree drivers in the user's machine to make more parts of the computer function, explaining to the user that the cost of this is using a nonfree (unjust) program. The install fest would tolerate the devil's presence but not officially sponsor the devil, or publicize the devil's availability. Therefore, the users who accept the devil's deal would clearly see that the devil installed the nonfree drivers, not the install fest. The install fest would not be morally compromised by the devil's actions, so it could retain full moral authority when it talks about the imperative for freedom. Those users that get nonfree drivers would see what their moral cost is, and that there are people in the community who refuse to pay that cost. They would have the chance to reflect afterwards on the situation that their flawed computers have put them in, and about how to change that situation, in the small and in the large. """ -- WBR, wRAR signature.asc Description: PGP signature
Re: Need advice on coordinating libkdumpfile update and introducing pykdumpfile
On 10.03.25 00:39, Michel Lind wrote: It should not fail in sbuilder or pbuilder, but just in case I can explicitly disable Python bindings from being built so it’s easier to do a test build Please do. Packages shouldn't build differently (or not at all) depending on whether some random not-mentioned-in-d-control package is installed. Policy doesn't seem to explicitly state that (I just took an admittedly-cursory look), but maybe it should. -- -- regards -- -- Matthias Urlichs OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian on /usr (Re: TC decision on ownership of top-level filesystem aliases - #1091995)
On 09.03.25 17:45, Marco d'Itri wrote: On Mar 09, Matthias Urlichs wrote: My "build me a Debian image" script has been doing that for two years now, simply by moving /var/lib/dpkg to /usr/state/dpkg and bind-mounting it back onto /var/lib/dpkg (symlinking won't work). How so? My /var/lib/dpkg has been a symlink for a very long time. Huh. It's been sufficiently long ago that I first did this; IIRC I simply used a bind mount instead of investigating what replaced the symlink. If this has since been fixed (by chance?), so much the better. Granted that some pieces are missing, most notably /boot (which really should be populated from /usr (and /etc) instead of being directly installed to), but that's irrelevant when your usecase is booting containers, and fixable by reinstalling the kernel packages. Seehttps://www.linux.it/~md/text/factoryreset-asg2024.pdf . Ah. Thanks. -- -- regards -- -- Matthias Urlichs OpenPGP_signature.asc Description: OpenPGP digital signature
NEW review & revision process (or lack thereof) (Re: Growing new FTP-masters (Re: Bits from DPL))
On 06/03/2025 04:54, Matthias Urlichs wrote: Finally, a question -- as you don't seem to document the issues you have with long term packages in their ITP bug, where *do* you document them? There is no built-in issue tracking in `dak`. The "notes" function is only available while the package is in NEW. They must be removed before a package is ACCEPTed or REJECTed. The sole documentation is in the FTP team members' and maintainer's email inboxes. There is no functionality to notify a processing FTP team member when a package is reuploaded. There is no indication in `dak process-new` that a package has been previously uploaded or a systematic way to check to make sure such feedback is addressed. 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. Unless one reads all FTP team mail, unless a maintainer CCes you on a "thanks, reuploaded" mail you are liable to miss such a fact. 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. As Bradley Kuhn mentioned in his DebConf16 talk "The Supreme Court of DFSG-Free?"[1], with rare exception ftpteam does not publish "advisory opinions" nor is there a way to reason about whether a package meets the DFSG other than to observe whether it is present in the archive. To me the status quo seems sub-optimal for a variety of reasons. For a further peak behind the ftpmaster curtain I recommend my DebConf24 talk "Meet the ftpteam" which has a walkthrough of the (quite old-school, "two SSH sessions and tmux") process of NEW package review. (video[2], etherpad[3]) There's certainly space for better tooling. Cheers, Luke Faraone [1]: https://debconf16.debconf.org/talks/38/ [2]: https://debconf24.debconf.org/talks/154-meet-the-ftpteam/ [3]: https://salsa.debian.org/debconf-team/public/data/dc24/-/blob/main/etherpad/txt/154-meet-the-ftpteam.txt
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Sun, Mar 09, 2025 at 05:31:02PM +0100, Simon Josefsson wrote: My hope is that the sentiments towards fully free installer images will change in the Debian project and that they eventually may be official again. I don't see sentiments towards fully free isntaller images. There is just nobody who wants to build them. I THINK that they might become official some day if somebody steps up, does the work and shows that they are willing to do that for at least one release cycle. Until nobody is there who is willing to do the work, it is moot to discuss whether those images could be official or not. If they don't exist, they won't be official. Easy. I still haven't heard arguments why people refuse to use an installer that comes with non-free firmware, asks whether this firmware should be used, and if answered "no", none of this non-free firmware ends up in the installed system. The resulting system is free regardless whether there was non-free firmware on the installation images. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Sun, 09 Mar 2025 17:17:52 +0100, Simon Josefsson wrote: >Right, in the sense that they embed non-free software in the hardware. > >None of those machines require them to be loaded by me as a user for >them to be useful to me. > >This distinction is important to me. I find the version where I can choose whether to use the firmare or not superior to not having the choice. >For me there are several reasons for wanting this, which ought to be >understandable for anyone reading this thread. It isn't. I am too stupid to understand that from the explanaition given. >The supply-chain >security trust concern of non-free firmware is a hot topic right now. I would place less trust on the firmware that is on the device while it rides the supply chain from the factory to my place. >It is fine to disagree that these are concerns worthy spending time on >within the Debian project, which is my perception of the vote outcome. There are not concerns about spending time. There are no people willing to do so. 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: Change the expectation that emails should wrap at 80 characters
Am Sonntag, dem 09.03.2025 um 22:13 +0100 schrieb Philip Hands: > Stephan Verbücheln (against? at least against mixed HTML) - against mixed HTML - against unwrapped lines without a defined method/encoding - okay with format=flowed Disclaimer: Not a Debian developer. Regards signature.asc Description: This is a digitally signed message part
Re: Change the expectation that emails should wrap at 80 characters
On 09/03/2025 21:13, Philip Hands wrote: (... some "vote" counting) Thanks for the counting effort, Philip. Though if you must put people into sides/camps, put me in both/either A. camp "one sentence/comma per line" B. camp "why can't we just make the software able enough, that they can reformat/reflow whatever wrapping the sending side chose, to whatever wrapping the receiving side prefers, so this bikeshedding that never has meaningful outcome is obsoleted" You are free to consider camp A friend or foe with camp wrap. Or just an individual camp. I'd also like to voice my concern about the silent majority. Thank you. -- Sdrager, Blair Noctis OpenPGP_signature.asc Description: OpenPGP digital signature
Re: please do not use text/markdown
Hi Jonas, * Jonas Smedegaard [2025-03-10 12:20]: It should work, but perhaps what you are experiencing is that by default pandoc expects a blank line between changes of blockquote level: https://pandoc.org/MANUAL.html#extension-blank_before_blockquote Maybe this works: pandoc -f markdown-blank_before_blockquote -t plain Yes, that solved the issue. Thank you very much! Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Change the expectation that emails should wrap at 80 characters
Hi Charles, Le 2025-03-10 01:32, Charles Plessy a écrit : [text/markdown instead of text/plain] That's IMO something much more interesting than text/html that should be implemented in MUAs (falling back to displaying it as text/plain eventually) but for now it doesn't display at all in some e.g. in Roundcube 1.6.10 that my service provider is using. An old version of Thunderbird displays it at text/plain. Cheers, -- Julien Plissonneau Duquène
Re: NEW review & revision process (or lack thereof) (Re: Growing new FTP-masters (Re: Bits from DPL))
Luke Faraone writes: > 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. If the price for the ability to learn from the mistakes of others is an occasional dose of public humiliation, then that's a price I'm happy to pay (and I speak as someone that has a talent for making trivial errors). Also, we claim in the Debian Social Contract that we don't hide problems. How about if the (possibly harsh) reasoning were published in a form that only directly tied it to the package name, such that search engines would not instantly and permanently place that comment on one's CV? I'd imagine that the stigma of a rejection would pretty quickly become an understanding that everyone makes mistakes occasionally, which may be a good way of avoiding new contributors becoming intimidated by the assumption that everyone else is doing a perfect job. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Hi, On Mon, 2025-03-10 at 13:27 +0530, Pirate Praveen wrote: > 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. No, the hardware manufacturer has more power with preinstalled firmware as well: they can more easily provide updates for on-board ROMs as well. (You can ship ROMs just like a USB media for OS-provided firmware images; it is just a different media.) > It is all about where you want to draw the line between the hardware and > software. [...] So for hardware we are willing to give more > power to manufacturers, but not for software. So we just declare software as hardware and suddenly it is "free"? Cool, then the preinstalled Windows is free (in the FSF "respects your freedom" sense) too if I don't install updates. :-) > > 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. Who is "you"? The user can choose what firmware version they want to install with OS-supplied firmware. If they don't like a newer version, they can just provide an older one to the hardware. Pretty much all firmware in non-free has no provisions that you have to use the newest version as that would be a problem for Debian to organize... So how does this change depending on where the firmware is stored? > 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. They can also give you the hardware schematics easily so you can install it in a FPGA instead of their provided chips. (And what when the firmware is programming for a FPGA?) That would make modifying the hard- and firmware easier ;-) > 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. Debian doesn't decide what is free or not free based on what the user is capable of doing. For some experienced hardware developer, modifying the hardware schematics can be easier than modifying software code. Otherwise we should factor in the programming language used in free vs non-free which would make most shell code non-free as it is too hard to modify in a safe way. ;-) > > 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. If you give root to the hardware manufacturer to manage firmware files on your computer, then they have control. Firmware updates don't magically arrive on your hard disk unless you either install them or someone sneakily breaks into your computer. >From a purely academic way, we might also discuss hidden wireless backdoors in hardware with pre-installed firmware. There pre-installed firmware is even worse as it is harder to find backdoors if you can't even look at the proprietary binary code. > So the value of this is, looking at your ability to easily modify, do we > have the freedom to modify? So not providing firmware via the operating system gives users the freedom to modify firmware? I don't follow. Ansgar
please do not use text/markdown
Hi Charles,
* Charles Plessy [2025-03-10 09:32]:
Le Sun, Mar 09, 2025 at 10:13:51PM +0100, Philip Hands a écrit : > >
Having skimmed through the 106 mails I currently see in this thread, >
this is the way I’d summarise people’s preferences (if anyone sees
that > I’ve mis-characterised their view, I promise it was not
intentional, so > please forgive me and correct my mistake)
Hi Philip and everybody,
to be clear: I am supporting the proposition to remove the requrement to
wrap lines. I would like to add that I think that we should not organise
GRs on that kind of questions.
I am also exploring the use of text/markdown as the default content type
for my emails.
Have a nice day,
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 -
I cannot read your email at all with K-9 Mail on Android, because
text/markdown is not treated like text at all, and the file cannot be
opened with any app I have installed at the moment. Frankly, I initially
thought you sent some garbage by accident and ignored the mail.
Mutt at least tells me now that I'm dealing with text/markdown, so I
manually added a mailcap entry:
text/markdown; iconv -f %{charset} -t utf-8 | pandoc -f markdown -t
plain; copiousoutput
It works somewhat, but it mangles quotes quite badly since pandoc does
not know about '>' quote markers (I quoted your mail in full and this is
pretty much how it is rendered in mutt).
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄ ╰╯
signature.asc
Description: PGP signature
Re: please do not use text/markdown
Quoting Timo Röhling (2025-03-10 11:19:01)
> Hi Charles,
>
> * Charles Plessy [2025-03-10 09:32]:
> >Le Sun, Mar 09, 2025 at 10:13:51PM +0100, Philip Hands a écrit : > >
> >Having skimmed through the 106 mails I currently see in this thread, >
> >this is the way I’d summarise people’s preferences (if anyone sees
> >that > I’ve mis-characterised their view, I promise it was not
> >intentional, so > please forgive me and correct my mistake)
> >
> >Hi Philip and everybody,
> >
> >to be clear: I am supporting the proposition to remove the requrement to
> >wrap lines. I would like to add that I think that we should not organise
> >GRs on that kind of questions.
> >
> >I am also exploring the use of text/markdown as the default content type
> >for my emails.
> >
> >Have a nice day,
> >
> >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 -
>
> I cannot read your email at all with K-9 Mail on Android, because
> text/markdown is not treated like text at all, and the file cannot be
> opened with any app I have installed at the moment. Frankly, I initially
> thought you sent some garbage by accident and ignored the mail.
>
> Mutt at least tells me now that I'm dealing with text/markdown, so I
> manually added a mailcap entry:
>
> text/markdown; iconv -f %{charset} -t utf-8 | pandoc -f markdown -t
> plain; copiousoutput
>
> It works somewhat, but it mangles quotes quite badly since pandoc does
> not know about '>' quote markers (I quoted your mail in full and this is
> pretty much how it is rendered in mutt).
It should work, but perhaps what you are experiencing is that by default
pandoc expects a blank line between changes of blockquote level:
https://pandoc.org/MANUAL.html#extension-blank_before_blockquote
Maybe this works: pandoc -f markdown-blank_before_blockquote -t plain
(if not, then try replace "-" with "+")
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Le 10 mars 2025 11:56:28 GMT+01:00, Simon Josefsson a écrit : >https://www.gnu.org/distros/optionally-free-not-enough.html > >https://www.gnu.org/philosophy/install-fest-devil.html … of course … that's where the core of the disagreement lies ! We're not a religion, we're just building a distro. I think you're looking for something else than Debian. -- Aurélien
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Mon, 10 Mar 2025 11:56:28 +0100, Simon Josefsson wrote: >Marc Haber writes: >> I still haven't heard arguments why people refuse to use an installer >> that comes with non-free firmware, asks whether this firmware should >> be used, and if answered "no", none of this non-free firmware ends up >> in the installed system. The resulting system is free regardless >> whether there was non-free firmware on the installation images. > >https://www.gnu.org/distros/optionally-free-not-enough.html >https://www.gnu.org/philosophy/install-fest-devil.html No thank you. 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: NEW review & revision process (or lack thereof) (Re: Growing new FTP-masters (Re: Bits from DPL))
Luke Faraone writes: > 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. If that is really the only rationale, I think the reviews ought to be public. As an offender of fairly obvious and embarrasing license mistakes, and other NEW packaging problems, I believe the only sustainable way to improve is to have more eyes looking at things and contributing and doing things in public allows people to learn how the process works, and participate. Charles Plessy's effort to have a pre-NEW review team to do such work seems like a good start (although I never figured out how I would submit a package to that effort). I can see the need for doing private reviews with private feedback though. Maybe what is needed is not so much to change ftp-master's private review process but to have this public pre-review process to smoothen the process a bit. /Simon signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Hi, On 3/10/25 20:41, Andrey Rakhmatullin wrote: We're not obligated to validate their questionable choices in buying hardware that ships with non-free firmware, or apologize for the bad experience they have when upstream changes something they don't like. It is not our duty as volunteers to compensate for the shortcomings of companies, especially companies that use our volunteer time without compensation -- we're the *free* software community, not the *gratis* software community. This is also an old argument. Some rebuttals included "this didn't work so far", "good luck getting fully open firmware in sectors where it's literally impossible" and "please don't call things users have no choice over "questionable choices"". That's my point though: the exact same rebuttals were presented in the 1990ies about getting drivers under a free license, and yet here we are, with excellent driver support for all but a few holdouts that users understand to be problematic due to the politics of the vendors. We've reached the point where people are shitting on nV for the quality of their drivers, and a kernel that has closed-source drivers loaded is "tainted", and the last release in which we shipped ndiswrapper was buster. This happened precisely because of free software zealotry. Free firmware will happen the same way: by users understanding that non-free offerings are inferior because you need to live with all the flaws they have -- and a large part of that is that the free software community is not apologizing for the experiences users have with closed-source drivers. Simon
Re: Bug reports for Uploaders
Hi Raphael, On 10/03/2025 10:36, Raphael Hertzog wrote: (tracker.debian.org maintainer here) Thanks for maintaining the service ;) Hi, On Thu, 06 Mar 2025, Blair Noctis wrote: So if the "staff" agrees, we can make @p.d.o addresses forward also to Uploaders, thus with @p.d.o address as Maintainer, also forwarding bug reports to Uploaders, achieving the goal. I don't really agree. "f...@packages.debian.org" is not the canonical way to reach a package maintainer. As per devref 7.3, it's a way for *maintainers* to contact other maintainers. Not really the same as BTS, which all users are free to use. So I agree it's not the same as BTS forwarding to Uploaders. It's really just a sudden thought. At this point, we have many services mailing maintainers directly and sending a copy to the package tracker. I'm the one who tweaked the above script to make it possible to use f...@packages.debian.org or team+...@tracker.debian.org as the Maintainer of a package. The goal is clearly to receive all the maintainer emails on tracker.debian.org and to let anyone receive them from there. From your initial list, my preferred outcome is to modify tracker.debian.org so that all Uploaders are automatically subscribed, that's what has been requested for a long time in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756954 That would be nice. Thanks for considering it. But there are quite a few safeguards (opt-in/opt-out) to put in place to make this realistic and not generate too many complaints. For instance, you should not generate a package-subscription if the person is already part of a package tracker team monitoring the same package, and each person should be able to opt-out globally or for a specific package. New/removed subscriptions should be notified by emails to the affected persons. Agreed. If we are to make the tracker "smart", these should of course be considered. Need some hands? Cheers, -- Sdrager, Blair Noctis OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Mon, Mar 10, 2025 at 09:33:55PM +0900, Simon Richter wrote: We've reached the point where people are shitting on nV for the quality of their drivers, and a kernel that has closed-source drivers loaded is "tainted", and the last release in which we shipped ndiswrapper was buster. That happened because those solutions were all incredibly painful, depending on the kernel version in use, losing compatibly during every second kernel upgrade, and didn't work cross-architecture. Users hated that. non-free firmware is silent and painless. Users don't care. tl;dr: The situation is totally different, we should not compare apples and peaches here. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Change the expectation that emails should wrap at 80 characters
On 2025-03-10 09:32:59 +0900 (+0900), Charles Plessy wrote: [...] I am also exploring the use of `text/markdown` as the default content type for my emails. 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). If anything, text/x-rst is probably a more suitable choice for such purposes, but Markdown vs reStructuredText religious wars are almost like modern reflections of the vi vs emacs skirmishes of yore. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Change the expectation that emails should wrap at 80 characters
Hi Phil, * Philip Hands [2025-03-09 22:13]: Of the 13 F=F folk, several also lean against the proposal to some extent. Just for the record, you may count me amongst them, too. I'm sympathetic to the soft line wrap cause, but one line paragraphs in text/plain is not a good solution IMHO. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)
Sean Whitton writes: > 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. Might it be worth linking to those policy sections, here perhaps: https://ftp-master.debian.org/#rejections and then linking to that from the NEW summary page. People looking at the NEW summary page are quite likely to be wondering if they may have done something wrong, so will be motivated to follow the links, and might even manage to notice a reason for a rejection by themselves, and fix it unprompted. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Bug reports for Uploaders
(tracker.debian.org maintainer here) Hi, On Thu, 06 Mar 2025, Blair Noctis wrote: > So if the "staff" agrees, > we can make @p.d.o addresses forward also to Uploaders, > thus with @p.d.o address as Maintainer, > also forwarding bug reports to Uploaders, > achieving the goal. I don't really agree. "f...@packages.debian.org" is not the canonical way to reach a package maintainer. At this point, we have many services mailing maintainers directly and sending a copy to the package tracker. I'm the one who tweaked the above script to make it possible to use f...@packages.debian.org or team+...@tracker.debian.org as the Maintainer of a package. The goal is clearly to receive all the maintainer emails on tracker.debian.org and to let anyone receive them from there. From your initial list, my preferred outcome is to modify tracker.debian.org so that all Uploaders are automatically subscribed, that's what has been requested for a long time in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756954 But there are quite a few safeguards (opt-in/opt-out) to put in place to make this realistic and not generate too many complaints. For instance, you should not generate a package-subscription if the person is already part of a package tracker team monitoring the same package, and each person should be able to opt-out globally or for a specific package. New/removed subscriptions should be notified by emails to the affected persons. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Marc Haber writes: > I still haven't heard arguments why people refuse to use an installer > that comes with non-free firmware, asks whether this firmware should > be used, and if answered "no", none of this non-free firmware ends up > in the installed system. The resulting system is free regardless > whether there was non-free firmware on the installation images. https://www.gnu.org/distros/optionally-free-not-enough.html https://www.gnu.org/philosophy/install-fest-devil.html The arguments are available but not everyone is convinced by them. Similar to that the arguments for free software exists but not everyone is convinced by those arguments and instead prefer proprietary software. /Simon signature.asc Description: PGP signature
