Bug#1100090: ITP: didder -- An extensive, fast, and accurate command-line image dithering tool.
Package: wnpp Severity: wishlist Owner: Nicolas Peugnet * Package name: didder Version : 1.3.0-1 Upstream Author : makeworld * URL : https://github.com/makeworld-the-better-one/didder * License : GPL-3.0 Programming Lang: Go Description : An extensive, fast, and accurate command-line image dithering tool. didder is an extensive, fast, and accurate command-line image dithering tool. It is designed to work well for both power users as well as pipeline scripting. It is backed by the author's dithering library (https://github.com/makeworld-the-better-one/dither), and is unique in its correctness and variety of dithering algorithms. It provides many options, while being correct (linearizing the image, weighting channels by luminance). . Types of dithering supported . * Random noise (in grayscale and RGB) * Ordered Dithering * Bayer matrix of any size (as long as dimensions are powers of two) * Clustered-dot - many different preprogrammed matrices * Some unusual horizontal or vertical line matrices * Yours? You can provide your own ordered dithering matrix in JSON format * Error diffusion dithering * Simple 2D * Floyd-Steinberg, False Floyd-Steinberg * Jarvis-Judice-Ninke * Atkinson * Stucki * Burkes * Sierra/Sierra3, Sierra2, Sierra2-4A/Sierra-Lite * Steven Pigeon (https://hbfs.wordpress.com/2013/12/31/dithering/) * Yours? You can provide your own error diffusion matrix in JSON format . Features . * Set palette using RGB tuples, hex codes, number 0-255 (grayscale), or SVG color names (https://www.w3.org/TR/SVG11/types.html#ColorKeywords) * Optionally recolor image with a different palette after dithering * Set dithering strength * Image is automatically converted to grayscale if palette is grayscale * Force image to grayscale with --grayscale * Change image saturation, brightness, or contrast before dithering * Read EXIF rotation tags by default (disabled with --no-exif-rotation) * Downscale image before dithering, keeping aspect ratio * Upscale image after dithering, without producing artifacts * Supports input image of types JPEG, GIF (static), PNG, BMP, TIFF * Output to PNG or GIF * Process multiple images with one command * Combine multiple images into an animated GIF * Uses all CPU cores when possible * Support images with transparency (alpha channel is kept the same) This is a fine little CLI tool that is easy to use, and all of its dependencies are already packaged in Debian.
Bug#1100112: ITP: golang-github-ashcrow-osrelease -- Go library/binary for parsing osrelease
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-ashcrow-osrelease Version : 0.0.1 Upstream Contact: Steve Milner * URL : https://github.com/ashcrow/osrelease * License : Apache-2.0 Programming Lang: Go Description : Go library/binary for parsing osrelease The osrelease package is a Go library designed to simplify the process of reading and parsing /etc/os-release files. These files contain operating system identification data, which can be useful for various system administration and automation tasks. . This package provides an easy-to-use API for accessing the contents of os-release files, making it straightforward to retrieve information such as the operating system's name, version, and other relevant details. It supports both automatic detection of the os-release file and explicit file loading. I'll maintain this package in the Go team.
General Questions about Translations and what a package maintainer has to do
Hi, I'm on mobile, so only a quick reply: merging should be done with msgmerge as well — you need to call it twice, once with the po files from both branches, and once again with the pot file to fix all the location comments and fuzzy flags. Alternatively, you can define a filter in git to remove(!) locations on checkout and restore them from the pot file on commit, that solves the majority of conflicts. Simon
Bug#1100127: ITP: python-enamlx -- Additional Qt Widgets for Enaml
Package: wnpp Severity: wishlist Owner: Alexander Sulfrian X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-enamlx Version : 0.6.4 Upstream Contact: Jairus Martin * URL : https://github.com/frmdstryr/enamlx/ * License : Expat Programming Lang: Python Description : Additional Qt Widgets for Enaml Enamlx provides the following additional widgets for Enaml: * TableView * TreeView * DoubleSpinBox * GraphicsView * PyQtGraph Plot * KeyEvent 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#1100131: ITP: golang-github-eggsampler-acme -- Go client library implementation for ACME v2 (RFC8555)
Package: wnpp Severity: wishlist Owner: Luca Soler X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-eggsampler-acme Version : 3.6.1-1 Upstream Author : Isaac Truscott * URL : https://github.com/eggsampler/acme * License : Expat Programming Lang: Go Description : Go client library implementation for ACME v2 (RFC8555) Indirect dependency of apptainer. This package will be maintained within the Debian Go Packaging Team. -- Luca signature.asc Description: OpenPGP digital signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Tue, Mar 11, 2025 at 04:29:24PM +0100, Simon Josefsson wrote: However if Debian dismiss those ideas, the argument that the fully free installer doesn't exist because "nobody is working on this, go create them and it will happen" does not seem valid to me. My reading is that these images doesn't exist because Debian had a vote saying they should not exist. I hope this will change in the future. Creating them won't change the decision, but it may be input to renewed discussion. Debian had a vote where we made it clear that we were ok with making use of limited project + developer resources and only testing + shipping an installer which also includes the non-free-firmware component. It wasn't "this should not exist" it was "we're not trying to double your workload, images team". I've not seen _anyone_ suggest that the project would try and stop someone from going off any building CD images that didn't include non-free-firmware, just that we don't expect the existing images team to have to expend more effort to make that happen. J. - Bored of this argument going round in circles. -- ] https://www.earth.li/~noodles/ [] I'm out of bed and dressed. What [ ] PGP/GPG Key @ the.earth.li[] more do you want? [ ] via keyserver, web or email. [][ ] RSA: 4096/0x94FA372B2DA8B985 [][
Bug#1100128: ITP: golang-github-letsencrypt-borp -- Boulder's version of go-gorp/gorp
Package: wnpp Severity: wishlist Owner: Luca Soler X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-letsencrypt-borp Version : 0.0~git20240620.a78493c-1 Upstream Author : Let's Encrypt (ISRG) * URL : https://github.com/letsencrypt/borp * License : Expat Programming Lang: Go Description : Boulder's version of go-gorp/gorp Indirect dependency of apptainer. This package will be maintained within the Debian Go Packaging Team. -- Luca signature.asc Description: OpenPGP digital signature
Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)
Charles Plessy writes: > 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. Could you explain how I would ask for review of a package? I re-read this thread, and the newgateway-team homepages, but I still don't understand how you think the process should work. Could we test the process by reviewing 'litetlog'? https://salsa.debian.org/go-team/packages/litetlog/ It is already in NEW queue, but maybe more eyes on it will catch mistakes before ftp-master review. It will help me understand what you think the process should be here. /Simon signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Fri, Mar 07, 2025 at 08:33:50PM +0100, Michael Biebl wrote: I wonder if we get a reply from the OP or if this was just an attempt to trigger a flame war. We will see... Yup. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1100099: ITP: python-elastcsearch8 -- Python client for Elasticsearch8
Package: wnpp Severity: wishlist Owner: Karsten Schöke X-Debbugs-Cc: debian-devel@lists.debian.org Package name: python-elastcsearch8 Version : 8.17.2 Upstream Contact: Elastic Client Library Maintainers URL : https://github.com/elastic/elasticsearch-py License : Apache-2.0 Programming Lang: Python Description : Python client for Elasticsearch8 Official low-level client for Elasticsearch version 8. Its goal is to provide common ground for all Elasticsearch-related code in Python; because of this it tries to be opinion-free and very extendable. The client's features include: * translating basic Python data types to and from json (datetimes are not decoded for performance reasons) * configurable automatic discovery of cluster nodes * persistent connections * load balancing (with pluggable selection strategy) across all available nodes * failed connection penalization (time based - failed connections won't be retried until a timeout is reached) * thread safety * pluggable architecture * Helper functions for idiomatically using APIs together This is a new dependency of python-elasticsearch-curator an will be maintained by DPT.
Bug#1100121: ITP: golang-github-poy-onpar -- Parallel testing framework for Go
Package: wnpp Severity: wishlist Owner: Luca Soler X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-poy-onpar Version : 0.3.3-1 Upstream Author : Andrew Poydence * URL : https://github.com/poy/onpar * License : Expat Programming Lang: Go Description : Parallel testing framework for Go (library) Onpar provides a BDD style of testing, similar to what you might find with something like ginkgo or goconvey. The biggest difference between onpar and its peers is that a BeforeEach function in onpar may return a value, and that value will become the parameter required in child calls to Spec, AfterEach, and BeforeEach. This allows you to write tests that share memory between BeforeEach, Spec, and AfterEach functions without sharing memory with other tests. When used properly, this makes test pollution nearly impossible and makes it harder to write flaky tests. Indirect dependency of apptainer. This package will be maintained within the Debian Go Packaging Team. -- Luca signature.asc Description: OpenPGP digital signature
Bug#1100095: ITP: golang-github-tredoe-osutil -- access to operating system functionality
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-tredoe-osutil Version : 1.5.0 Upstream Contact: 2021-2024, Nathan Otterness * URL : https://github.com/tredoe/osutil * License : MPL-2.0 Programming Lang: Go Description : access to operating system functionality The tredoe/osutil package provides access to operating system functionality that is dependent on the platform. It includes utilities for executing commands with standard input, output, and error handling, as well as cryptographic functions for hashing passwords using various algorithms such as SHA-512 and SHA-256. . This module is useful for developers who need to interact with the operating system in a platform-agnostic way, ensuring compatibility across different environments. . Features: * Execute commands with full control over standard input, output, and error streams. * Cryptographic utilities for hashing passwords using SHA-512, SHA-256, and other algorithms. * Platform-dependent functionality abstracted for ease of use. I'll maintain this package in the Go team, as a reverse-depends for mgmt-config.
Re: Processing times for the NEW queue (was Re: Bits from DPL)
On 2025-03-06 15:45 +0200, Faidon Liambotis wrote: Your question perhaps incorporates an underlying assumption that "two days", or "[less] than three or four weeks" is not slow. I'd like to challenge this assumption. I can ship code from a VCS host, for free, in a few seconds. Heck, I can even ship code from a debian.org domain, from a shared "debian" namespace, in the same amount of time. Salsa admins are not approving every new repository by hand, and it would be preposterous for anyone to even suggest doing that. But, many of us desire more _fundamental_ changes in this space and have been raising this point for years. I personally have felt like stuck between a rock (status quo) and a hard place (sounding thankless to an overworked team of volunteers) for more than a decade So I'd like to ask the ftp-master team in particular: what would you suggest is the best way to approach your team in collaboratively evolving and improving the way NEW works? How can the project, either through its DPL, or as individual members desiring such larger systemic changes, convince you for the necessity of making said changes, and ultimately help you in implementing them? This bit of the thread hasn't got any reaction/traction yet, which surprises me slightly. Do we still even _need_ to pre-review the archive the same way we have been for 30 years? Could not post-review when actual problems are noted be sufficient (given that much of the rest of the ecosystem seems to manage this, although a lot of that is source rather than binaries). I know this has been discussed before, but it seems to me that this is something worth reviewing, because NEW reviewing is a big pile of work and additional friction, and if we _could_ just do less of it, that would be good. Wookey -- Principal hats: Debian, Wookware http://wookware.org/ signature.asc Description: PGP signature
Bug#1100106: ITP: golang-go4-netipx -- extra stuff from inet.af/netaddr that didn't make it into Go's net/netip
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-go4-netipx Version : 0.0~git20231129.fdeea32 Upstream Contact: Brad Fitzpatrick * URL : https://github.com/go4org/netipx * License : BSD-3-clause Programming Lang: Go Description : extra stuff from inet.af/netaddr that didn't make it into Go's net/netip This is a package containing the bits of the old inet.af/netaddr package that didn't make it into Go 1.18's net/netip standard library package. . As background, see: . * https://github.com/inetaf/netaddr/ (now deprecated) * https://tailscale.com/blog/netaddr-new-ip-type-for-go/ - blog post about why the package came to be originally * https://go.dev/doc/go1.18#netip - Go 1.18 release notes . This package requires Go 1.18+ to use and complements the net/netip. I'll maintain this in the Go team.
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Geert Stappers writes: >> > We're not obligated to validate their questionable choices in buying >> > hardware that ships with non-free firmware >> >> There are a lot of competing priorities here, and it's the height of >> arrogance to be so certain that one's own opinion is best as to try to >> prevent other people from making their own decisions by hiding even the >> existence of a mechanism to install debian on their machine. >> > > Simon, > > > Do know that is OK that there are differences in view, opinion, > standpoint, approaches, ideas and whatever. FWIW, I didn't write what you quoted above, so please check your attributions. /Simon signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Philip Hands writes: > Hi Simon, > > Simon Josefsson writes: > >> While this may be fine to you it is not fine to me, and it is fine to >> disagree on that. > > If there were a method of building images that did not touch the > non-free components, I presume that would satisfy you. That sounds good! > Let's say that we could make that image bit-for-bit reproducible with an > image that was produced by taking the normal with-nonfree-firmware > image, and filtering it somehow (e.g. overwriting the non-free bits with > zeros, say). > > Would you object if the normal way of generating the image was to apply > the filter, rather than build it in parallel? > > If that would be OK, then one could have something that applied the > filter to our normal images to provide people with the images you want, > while not require duplication of building and storage. > > People could always confirm that they were getting the same result as > building without the nonfree firmware by doing it themselves, and > checking things matched. > > Is that something that would work for you? This is better, assuming the "doing it themselves" property is actually confirmed. Your idea is really clever! My assumption all along has been that the presence of the non-free firmware in the build process "taint" the resulting image in a way that makes it impossible be able to 1) zero out the non-free firmware bits from the resulting image, and at the same time 2) be able to separately build a bit-by-bit identical image using only free software and that this image would become identical to the zeroed out image. But you made me realize this is not impossible at all, it is just a Small Matter Of Programming. You could turn this around: how about building the images without non-free software, and replace the zerod out bits with the non-free firmware on final preparation of the non-free images? Then your normal build process is not tainted by the presence of non-free software. 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. They are the enabler of the slippery slope that leads to including non-free software by default. Meanwhile I looked into the debian-cd project to experiment with building images myself. Why aren't the images built in a Salsa pipeline? Yes I understand that 20 years ago the resources required to build the images were large. But today people build large projects in GitHub Actions. What artifact size are we talking about? Looking at the summary of official images at https://www.debian.org/CD/http-ftp/ it seems like around 50GB? What is the build time on a powerful machine? I would start to worry about the design feasability of running this in a pipeline when the total size of artifacts from a single build is larger than 4TB or if a single serialized job would have to run for more than a couple of days. I'm probably missing some combinatorical explosion of varaints that increase the total size, but there is also no requirement that all images are built like this. I would be satisfied if the "netinst" variant for all architectures could be reproduced from purely free software, in a Salsa pipeline, and that seems to be a 5-10GB artifact unless my math is off. I worry that the builds require other non-reproducible/free steps though. A signed boot shim where the private key is not replaceable by a user-controlled key is equally problematic as non-free firmware. Trisquel and Guix avoids these, and I recall seeing stuff like that in Debian -- https://tracker.debian.org/pkg/shim-signed -- but it is good to know that we have more things to work. /Simon signature.asc Description: PGP signature
General Questions about Translations and what a package maintainer has to do
tl;dr: We need more docs about best practices to handle translations as
a package maintainer
My fellow developers,
there are two things in being a DD that I truly despise. The one is
keeping the machine readable debian/copyright up to date, the other is
handling of translations, regardless of whether it's po-debconf, manpage
translations or program translations (when I am also the upstream).
I might rant about debian/copyright when I blow my fuse next time, but
today it's going to be translations. For me, it seems impossible to
support translator's work without putting a significant burden of
additional work to put on oneself. Especially when one uses version
control and does not do all development in Mast^wdebian/latest, dealing
with translations is a nightmare when it comes to merge. As the Newbie¹
DD I am, I keep running into either nightmare merges, or unnecessarily
fuzzed or even destroyed translations, in all cases feeling even more
stupid and incompetent when some translator points out my mistakes. I
have felt being sent back and forth between different workflows (all of
them wrong) by following random advice without being able to find
authoritative explanation.
I might have a fundamantal misunderstandig of procedures, but all
documentation one finds, including Chapter 8 in the Developer's
Reference (which links to a document by Tomohiro KUBOTA which is no
longer there), elaborate on how one would do actual translations, but
doesn't go as far as giving best practice documentation about what a
package maintainer is supposed to do to make translation blend into a
normal packaging workflow without being a nuisance ("put them into the
po directory and build the package" doesn't fit a modern packaging
workflow using version control).
My example package is adduser, but I think that my questions might apply
to other packages as well. adduser has both its program messages and the
manual pages translatable, the latter being done with po4a. I am aware
that there are also translations for debconf templates, but adduser
doesn't have those (any more). I think the problems that show with
debconf template translations are similar to the pain one feels with
documentation and program translations. I actively avoid using debconf
in my packages because I don't want to go through the pain that handling
translations causes, and many parts of Debian consider it bad practice
to use debconf. But that's an entirely different rant.
Handling translations does hurt when the sources are stored in version
control because I constantly end up having changes to pot and po files
in commits where they don't belong, or uncommitted changes that prevent
me, for example, from doing rebases. I have tried to build a workflow
that doesn't hurt me as package maintainer as much, but it has turned
out that this doesn't work because many translators don't care.
Please don't take me wrong, I know this is a rant, and I know that
you'll notice that I am typing this with my fists clenched. But my time
and my nerves and my mental health as as important as it is to be nice
to my translators. I do care, but sometimes it's really hard to maintain
a straight and friendly face while cursing our tools and docs inside.
Whenever I am angry about something in Debian, I start writing docs. So
I try this here, but here I don't know enough to be really helpful. I
hope that this rant will start a positive discussion with actual results
that I could pour into a Wiki page that might actually help with the
pain I am feeling, assuming that many other maintainers feel as well.
Let me try to summarize what I have understood regarding translations
and what my problems are with that.
(1)
When writing software, docs or debconf templates, the respective author
marks certain strings as translateable. There is a number of conventions
to do so which are language dependent. Let's assume that has been done
the right way, there are docs about this.
(2)
There is some point in the development process when it is time to ask
for translations. Translators need a POT file which contains all the
translatable strings, and they make a PO file from that which contains
the actual translation.
(3)
Some program (xgettext for program translations, po4a for manual pages
and some podebconf tool for debconf templates) is used to pull the
translatable strings from the source code and to create a POT file.
xgettext doesn't even try to create a meaningful header and overwrites
whatever one has written into the previous version of the POT file, so a
wrapper is already needed to have a header that translators can fill
(which they usually don't do).
For Adduser's program translations, my call to xgettext is:
xgettext --keyword=mtx --keyword=gtx --omit-header -o "$TEMP_FILE"
--from-code=UTF-8 -L perl adduser deluser $(find . -name "*.pm")².
TEMP_FILE then gets the generated header prepended to result in
adduser.pot.
I have seen
Bug#1100098: ITP: golang-github-yalue-merged-fs -- compose Multiple Go Filesystems
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-yalue-merged-fs Version : 1.3.0 Upstream Contact: Nathan Otterness * URL : https://github.com/yalue/merged_fs * License : Expat Programming Lang: Go Description : compose Multiple Go Filesystems The [release of version 1.16](https://golang.org/doc/go1.16) of the Go programming language included a standard interface for read-only filesystems, defined in Go's `io/fs` standard library package. With this change came some other standard-library changes, including the fact that `archive/zip` now provides a "filesystem" interface for zip files, or the ability of `net/http` to serve files from any filesystem providing the `io/fs` interface. In conjunction, this means utilities like the HTTP server can now directly serve content from zip files, without the data needing to be extracted manually. . While that's already pretty cool, wouldn't it be nice if you could, for example, transparently serve data from multiple zip files as if they were a single directory? This library provides the means to do so: it implements the `io/fs.FS` interface using two underlying filesystems. The underlying filesystems can even include additional `MergedFS` instances, enabling combining an arbitrary number of filesystems into a single `io/fs.FS`. . This repository provides a roughly similar function to [laher/mergefs](https://github.com/laher/mergefs), but it offers one key distinction: correctly listing contents of merged directories present in both FS's. This adds quite a bit of complexity. However, laher/mergefs will be more performant for filesystems not requiring directory- listing capabilities.
Re: Processing times for the NEW queue (was Re: Bits from DPL)
On 3/11/25 6:18 PM, Wookey wrote: Do we still even _need_ to pre-review the archive the same way we have been for 30 years? Could not post-review when actual problems are noted be sufficient (given that much of the rest of the ecosystem seems to manage this, although a lot of that is source rather than binaries). I know this has been discussed before, but it seems to me that this is something worth reviewing, because NEW reviewing is a big pile of work and additional friction, and if we _could_ just do less of it, that would be good. I think in previous discussions, it was suggested to pay for a proper legal opinion, may be from SFC or SFLC. I think this would be a good use of Debian's money. With a proper legal opinion, we will be in a much better position to evaluate changes to these processes. Wookey 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
On Mon, Mar 10, 2025 at 11:03:49AM +0100, Julien Plissonneau Duquène wrote: [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. My Mutt also displays it as it would display text/plain. I wouldn't have known the unusual Content-Type if I hadn't looked. 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
Bug#1100042: ITP: python-casttube -- Interact with the YouTube Chromecast API
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-casttube Version : 0.2.1 Upstream Author : Uri Katz <4urik...@gmail.com> * URL : https://github.com/ur1katz/casttube * License : MIT Programming Lang: Python Description : Interact with the YouTube Chromecast API This library allows users to engage with the YouTube Chromecast API, enabling control over video playback on devices with Chromecast capabilities. It can initiate the playing of videos or playlists, manage queue operations such as adding and removing videos, and handle playback controls including play next and clearing the queue. This library communicates with a YouTube app running on a Chromecast device, requiring a screen ID for interactions. Leveraging this API, casttube provides functionality for controlling media displayed through Chromecast, making it possible to manage streaming directly from a programmatic interface. I plan to maintain this package as part of the Python team.
Bug#1100047: ITP: flashmq -- A high-performance, light-weight MQTT broker/server
Package: wnpp Severity: wishlist Owner: Matthias Urlichs X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: flashmq Version : 1.20.0 Upstream Contact: Wiebe Cazemier * URL : https://flashmq.org * License : OSL v3.0 Programming Lang: C++ Description : A high-performance, light-weight MQTT broker/server FlashMQ is a high-performance, light-weight MQTT broker/server, designed to take good advantage of multi-CPU environments. I want to package it for Debian because (for a given workload) FlashMQ requires a lot less CPU than mosqitto; also, it supports running with multiple threads. Also, FlashMQ supports a plug-in interface for custom authentication and other behavior.
Re: Bits from DPL
Hello, Sean Whitton wrote on 06/03/2025 at 02:01:13+0100: > Hello, > > On Wed 05 Mar 2025 at 11:35pm +0530, Nilesh Patra wrote: > >> Do you mind clarifying why that's the case, unless the reason is truly >> personal or undisclosable? > > It's pretty simple -- there is no-one with the free time to train them > right now, in which case trainees will simply burn out, because they > won't get enough feedback on their NEW reviews. > > We try to recruit only when there is someone who is able to dedicate > some time to training. That depends on what the other team members are > busy with, in and outside of Debian, at a given time. > > This was made very clear to Andreas. There is a risk for such a situation to become auto-feeded. I acknowledge the position of the ftpmasters team, but do you have a plan to avoid it becoming a vicious circle? Bests, -- PEB signature.asc Description: PGP signature
Bug#1100019: ITP: graphite-editor -- Graphite-Editor a modern, vector graphics tool
Package: wnpp Severity: wishlist Owner: Carl Keinath X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: graphite-editor Version : Alpha Upstream Contact: Graphite Labs * URL : https://github.com/GraphiteEditor/Graphite * License : Apache-2.0 Programming Lang: Rust Description : Graphite-Editor is a modern, vector graphics and design tool featuring a hybrid layer and node-based workflow Graphite-Editor is a vector graphics tool with a hybrid layer and node-based workflow for procedural, nondestructive editing. Built with Rust and powered by its dedicated engine, it delivers optimized rendering for modern hardware. I plan to maintain this package myself, but co-maintainers are welcome. The native desktop app is currently in alpha, which I am going to package. Regards, Carl Keinath
Re: New appointment for the Debian Technical Committee: Paul Tagliamonte
Hi Sean, Am Tue, Mar 11, 2025 at 10:01:06AM +0800 schrieb Sean Whitton: > > 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. Apologies for the mistake. I had asked for a review of my text, but it seems to have slipped through. That said, I truly appreciate your work in the Debian Technical Committee as well. Kind regards Andreas. -- https://fam-tille.de signature.asc Description: PGP signature
Re: Salsa CI job 'missing-breaks' to be enabled by default starting March 1st
On Thu, Mar 06, 2025 at 06:21:10PM +0100, Matthias Urlichs wrote: > However, I'm reasonably certain that there are other cases where diversions > are intentional and perfectly valid. Unless 'missing-breaks' learns to > handle them it will report CI failures for *all* of them, at which point we > might as well change Policy to state that diversions are a legacy feature > that cannot be used in new uploads. Do you have an example? > I kindof doubt that we'd get a majority to sign off on that. You don't need to use it, so don't? All of that is opt-in. Bastian -- Youth doesn't excuse everything. -- Dr. Janice Lester (in Kirk's body), "Turnabout Intruder", stardate 5928.5.
Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)
> On Thu 06 Mar 2025 at 01:21pm +09, Charles Plessy wrote: > > > Around 12 years ago, I proposed a peer-review system to increase the > > quality of > > the packages in the NEW queue. https://wiki.debian.org/CopyrightReview Le Thu, Mar 06, 2025 at 05:41:14PM +0800, Sean Whitton a écrit : > > If someone wants to set this up in a way that doesn't increase ftp team > workload but means packages have to be reject'd less often -- by all > means. Thanks Sean, Thorsten and everybody else for the positive feedback. I have prepared a stub for a "Gateway to NEW" on Salsa: https://salsa.debian.org/newgateway-team I added `Debian` as a team member. I am under the impression that forking repositories will not be necessary: if we provide CI pipeline packages like the salsa-ci project, and smart ways to turn them on and off, then people can run their tests in their own repositories. I have some new r-cran-* packages to prepare next week; I will use them as a proof of principle. Everybody is welcome to be faster than me to test the idea. I am not entirely sure on where to continue the discussion, but maybe we can try to leverage Salsa as much as possible for that as well? 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: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Sat, Mar 08, 2025 at 06:58:08PM +0500, Andrey Rakhmatullin 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. See? -- WBR, wRAR signature.asc Description: PGP signature
Re: Improvement of headless server upgrades
On Wed, 5 Mar 2025 14:36:20 -0500, "Helmut K. C. Tessarek" wrote: >On the other >hand, it's not always possible to have a test bed for every single setup. It is way easier to have a test bed or to arrange for console access than even trying to cater for every situation that might happen. Rest assured that package maintainers already try to avoid situations like that to the best of their knowledge. 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: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
> > We're not obligated to validate their questionable choices in buying > > hardware that ships with non-free firmware > > There are a lot of competing priorities here, and it's the height of > arrogance to be so certain that one's own opinion is best as to try to > prevent other people from making their own decisions by hiding even the > existence of a mechanism to install debian on their machine. > Simon, Do know that is OK that there are differences in view, opinion, standpoint, approaches, ideas and whatever. And do know that the best thing to get the holy installer, is to (start to) building it. Groeten Geert Stappers Debian Developer, Voted for 'Lets stop with telling "With the non-free-firmware ISO would have your install through WIFI succesed"' -- Silence is hard to parse
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On 2025-03-09 17:17:52 +0100 (+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. [...] For me there are several reasons for wanting this, which ought to be understandable for anyone reading this thread. The supply-chain security trust concern of non-free firmware is a hot topic right now. [...] Isn't there also a similar concern for keeping security vulnerabilities patched, even if they occur in the embedded non-free firmware that shipped on your hardware? Do you patch such vulnerable firmware manually when you happen to spot a news article about it, or just try to ignore vulnerabilities in firmware along with ignoring the presence of firmware? If you patch your firmware, do you find the process of doing so manually simple enough not to warrant assistance from your operating system? Note that if you don't trust your operating system to not install compromised firmware, then perhaps consider looking a different operating system you do trust. Your operating system has the capacity to install new firmware behind your back regardless of whether or you're personally okay with it doing so. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Simon Josefsson wrote: >Philip Hands writes: > >> Let's say that we could make that image bit-for-bit reproducible with an >> image that was produced by taking the normal with-nonfree-firmware >> image, and filtering it somehow (e.g. overwriting the non-free bits with >> zeros, say). >> >> Would you object if the normal way of generating the image was to apply >> the filter, rather than build it in parallel? >> >> If that would be OK, then one could have something that applied the >> filter to our normal images to provide people with the images you want, >> while not require duplication of building and storage. >> >> People could always confirm that they were getting the same result as >> building without the nonfree firmware by doing it themselves, and >> checking things matched. >> >> Is that something that would work for you? Yeesh. That gets messy - live images include firmware in the squashfs, for example. Simply replacing things with zeroes is not *quite* enough here. ... >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. They are the enabler of the >slippery slope that leads to including non-free software by default. Sigh. That's the same argument for removing the option to even load firmware. We must be *so* sure of purity that we can't even acknowledge that users might need to use/run anythinh that we don't consider pure enough. Let's stop them! >Meanwhile I looked into the debian-cd project to experiment with >building images myself. Why aren't the images built in a Salsa >pipeline? Yes I understand that 20 years ago the resources required to >build the images were large. But today people build large projects in >GitHub Actions. What artifact size are we talking about? Looking at >the summary of official images at https://www.debian.org/CD/http-ftp/ it >seems like around 50GB? Haha, no. Using the last bookworm release as a guide, we created a grand total of 284 images (mix of d-i and live) totalling ~1.7T. >What is the build time on a powerful machine? That build took ~4h end-to-end on casulana,d.o, which I believe is the project's biggest server box. The build process needs a complete local mirror and a *lot* of I/O and CPU. >I would start to worry about the design feasability of running this in a >pipeline when the total size of artifacts from a single build is larger >than 4TB or if a single serialized job would have to run for more than a >couple of days. I'm probably missing some combinatorical explosion of >varaints that increase the total size, but there is also no requirement >that all images are built like this. I would be satisfied if the >"netinst" variant for all architectures could be reproduced from purely >free software, in a Salsa pipeline, and that seems to be a 5-10GB >artifact unless my math is off. > >I worry that the builds require other non-reproducible/free steps >though. A signed boot shim where the private key is not replaceable by >a user-controlled key is equally problematic as non-free firmware. >Trisquel and Guix avoids these, and I recall seeing stuff like that in >Debian -- https://tracker.debian.org/pkg/shim-signed -- but it is good >to know that we have more things to work. Sigh. -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Mon, Mar 10, 2025 at 08:36:45PM +0900, Simon Richter wrote: The current state where we have free software drivers for a lot of hardware is the result of a lot of people investing a lot of time into creating them. In the same way, we need to do both: support our current users by allowing them to use non-free firmware with their current hardware, *and* push for new devices to have free firmware. Part of that push is informing users that what we do wrt firmware is best-effort, support for their hardware can be dropped at any point and the free software community cannot put them in control of their computing experience. 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"". -- WBR, wRAR signature.asc Description: PGP signature
Re: Processing times for the NEW queue (was Re: Bits from DPL)
On 2025-03-11 18:52:07 +0530 (+0530), Pirate Praveen wrote: [...] I think in previous discussions, it was suggested to pay for a proper legal opinion, may be from SFC or SFLC. I think this would be a good use of Debian's money. With a proper legal opinion, we will be in a much better position to evaluate changes to these processes. SPI has relationships with some great IP lawyers specializing in F/LOSS licenses and community-run projects, and they charge us very reasonable rates. All it takes is a clear list of questions and authorization from Debian leadership for us to engage with counsel to get answers. Turn-around time is typically somewhere between a week and a month depending on their availability, and whether the specific questions necessitate a referral to other colleagues with slightly different specializations. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Aurélien COUDERC writes: > 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 ! Right, I think agreement (or disagreement) with those essays explains a lot of what practical choices you make. > We're not a religion, we're just building a distro. I'm not sure what to make of that. Are you saying that Guix, Trisquel etc who strive towards these concepts are not distro's? One person's religion is another person's reasonable beliefs. I'm not sure who has the authority to judge. I'm sure some would dismiss the DFSG as religion, even if we happen to like it here. It is fine for the Debian community to dismiss the arguments described in the links above. This appears to be the case, although I hear some voices that are open to change. However if Debian dismiss those ideas, the argument that the fully free installer doesn't exist because "nobody is working on this, go create them and it will happen" does not seem valid to me. My reading is that these images doesn't exist because Debian had a vote saying they should not exist. I hope this will change in the future. Creating them won't change the decision, but it may be input to renewed discussion. /Simon signature.asc Description: PGP signature
Re: Processing times for the NEW queue (was Re: Bits from DPL)
Hi, * Pirate Praveen [2025-03-11 18:52]: I think in previous discussions, it was suggested to pay for a proper legal opinion, may be from SFC or SFLC. I think this would be a good use of Debian's money. With a proper legal opinion, we will be in a much better position to evaluate changes to these processes. That depends on your expectations. Making any process legally bullet proof is like fixing all the security vulnerabilities in a software package. It would be interesting to know if we are currently overspending or underspending on risk mitigation (in terms of time and money). A legal opinion will be helpful to inform our discussion, but it will not be a substitute for consensus on our collective risk appetite, i.e., how much legal exposure we deem acceptable for Getting Things Done. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Bug reports for Uploaders
Hi, On Mon, 10 Mar 2025, Blair Noctis wrote: > > 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. Heh. It's not really something new, I have been thinking this problem for a long while already: https://dep-team.pages.debian.net/deps/dep2/ Some of the thoughts there turned into some of the changes I pushed forward... but many are still just ideas waiting for people to refresh and pick them up. :-) > > 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? Yes, definitely! I try to be reactive for reviews but I'm mostly a SPOF and would love to get some co-maintainers on board over time. Don't hesitate to ping me on IRC too (I'm buxy there). https://qa.pages.debian.net/distro-tracker/contributing.html 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
Bug#1100046: ITP: python3-asyncclick -- Python package for creating beautiful command line interfaces, async version
Package: wnpp Severity: wishlist Owner: Matthias Urlichs X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python3-asyncclick Version : 8.1.8 Upstream Contact: Matthias Urlichs * URL : h...@github.com:smurfix/asyncclick.git * License : BSD Programming Lang: Python Description : Python package for creating beautiful command line interfaces, async version Asyncclick is an async-ized soft fork of the "click" Python package (already in Debian). It uses anyio, thus works with asyncio and/or trio. The fork is necessary because "standard" click does not support async context managers and exit stacks; without these, writing more complex command line handling gets somewhat unwiedly.
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Mon, Mar 10, 2025 at 03:41:50PM +0100, Bjørn Mork wrote: Simon Richter writes: their questionable choices in buying hardware that ships with non-free firmware Is there hardware that ships with free firmware? Seriously. Yeah, I think that should read "requires", not "ships with". Shipping with is, as explained in other emails, is good. -- WBR, wRAR signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Mon, Mar 10, 2025 at 08:36:45PM +0900, Simon Richter wrote: We're not obligated to validate their questionable choices in buying hardware that ships with non-free firmware There are a lot of competing priorities here, and it's the height of arrogance to be so certain that one's own opinion is best as to try to prevent other people from making their own decisions by hiding even the existence of a mechanism to install debian on their machine.
Re: Salsa pipeline limit
On 10/03/2025 09:57, Simon Josefsson wrote: in a Salsa pipeline, and that seems to be a 5-10GB artifact unless my math is off. Hi Simon, sadly, Salsa pipelines will only handle up to 250MB, a long way short of even 5GB ! https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/389 Cheers, Peter
Bug#1100034: ITP: golang-github-astromechza-etcpwdparse -- Golang library for parsing /etc/passwd entries
Package: wnpp Severity: wishlist Owner: Roland Mas * Package name: golang-github-astromechza-etcpwdparse Version : 0.0~git20170319.f0e5f07-1 Upstream Author : Ben Meier * URL : https://github.com/astromechza/etcpwdparse * License : Expat Programming Lang: Go Description : Golang library for parsing /etc/passwd entries Golang library etcpwdparse . This library provides simple access to the entries in the /etc/passwd file. . It was made for programs that need to be able to pull home directories, user id's and the like but do not want the cgo-dependence of the core os/user package. . The only real caveat is that it doesn't pull user entries from other sources like PAM or LDAP since it only operates by reading the file on disk.
Re: Processing times for the NEW queue (was Re: Bits from DPL)
On Thu, Mar 06, 2025 at 11:19:52AM +0100, Timo Röhling wrote: > I'm not an FTP Team member, but I happen to have analyzed exactly this > question in detail [1]. The FTP team is very transparent in this regard and > provides all processing logs, so any DD can verify this for themselves. Thank you for this analysis and for providing both data as well as the code to produce it, that's super helpful! > In summary, the median wait time in NEW is currently less than 48 hours, and > in the last 10 years it was seldomly longer than a week. 90 percent of all > packages going through NEW are processed within a few weeks. Only 2 percent > of all packages going through NEW are held up for several months or longer. This analysis does not/cannot account for the distinction of the truly "new to the archive" packages, vs. package renames/SONAME bumps etc. It is also my hypothesis, as you also identified with your later point (2), that there are significant differences between the time it takes to complete the two different types of reviews. While it's totally understandable why the data is presented this way, it's worth perhaps keeping this limitation in mind and applying some caution when trying to interpret the data, as median/90p/98p may not tell the right story in what what may well be a bimodal distribution. > That means that in an average month, more than 200 packages pass through NEW > within two days, and only about 20 packages get stuck for more than three or > four weeks. > > So why do people feel NEW processing is generally slow? I have a few ideas: While I agree with basically all your hypotheses (and thank you for so eloquently making them), I think there is an additional reason, that challenges the framing of the question itself. Your question perhaps incorporates an underlying assumption that "two days", or "[less] than three or four weeks" is not slow. I'd like to challenge this assumption. I can ship code from a VCS host, for free, in a few seconds. Heck, I can even ship code from a debian.org domain, from a shared "debian" namespace, in the same amount of time. Salsa admins are not approving every new repository by hand, and it would be preposterous for anyone to even suggest doing that. So why is this different? One could of course say that we, as a project, offer our main archive as a more trustworthy and curated set of software than say, e.g.a random personal GitHub repository, or even the Salsa "debian" namespace. But, in turn, this makes the assumption that the only way to legally distribute software of a certain quality and trustworthiness is by having a team of 5-10 people review it all by hand. This is, IMHO, a flawed and outdated view. I believe this practice has not historically scaled alongside the growth of the project, but also _cannot fundamentally scale_ at the pace of modern software development and the expectations that many of us have. The way I see it, gatekeeping in the way the NEW system works was very common in the 90s and early 2000s, with software development patterns where development teams authored software, and another set of "more privileged" teams (whether these were "operations", "release engineering", "delivery", a "CAB" or "change control board" etc.), would manually review, approve and ship said software. A certain amount of lag was expected, and often built into the system. When the next release was going to be shipped in CDs three years from the time the code was written, waiting a couple of weeks was kind of OK? In my experience, these methodologies have fallen out of practice, through various movements (code review culture, DevOps, "lean" and "agile" software development, "shift left"), associated tooling (the rise of VCS & DVCS like git, code review & CI/CD platforms like GitHub and GitLab, ...) or... even the availability of internet itself. Basically, collaborative software development has come a long way in the past ten or twenty years. That's not to say that these practices do not still exist in certain sectors/industries, nor that there isn't a lot of grey in between these two worlds. But I hope we can all agree that the expectations a modern software developer has for how quickly it will take for their code to reach its intended audience, has *radically* changed over the past two decades. "A few weeks" simply does not cut it anymore -- the average DD would likely revolt if they had to wait for a manual review of a few days or weeks for every Debian upload of theirs, or for every testing migration. We only tolerate it for NEW because most of us have to rarely go through it. With all that said, I'd like to say that I am immensely thankful to these 5-10 people for their work and what is legitimately a lot of work we all benefit from. I also understand that it's hard to contemplate *any* change when you are overworked to the point of burning out, and especially when you feel your work is thankless and unappreciated. But, many of us desire more _fu
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Hi Simon, Simon Josefsson writes: > While this may be fine to you it is not fine to me, and it is fine to > disagree on that. If there were a method of building images that did not touch the non-free components, I presume that would satisfy you. Let's say that we could make that image bit-for-bit reproducible with an image that was produced by taking the normal with-nonfree-firmware image, and filtering it somehow (e.g. overwriting the non-free bits with zeros, say). Would you object if the normal way of generating the image was to apply the filter, rather than build it in parallel? If that would be OK, then one could have something that applied the filter to our normal images to provide people with the images you want, while not require duplication of building and storage. People could always confirm that they were getting the same result as building without the nonfree firmware by doing it themselves, and checking things matched. Is that something that would work for you? Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Bug reports for Uploaders
On 05/03/2025 02:45, Adam D. Barratt wrote: On Wed, 2025-03-05 at 01:32 +0800, Blair Noctis wrote: On 04/03/2025 21:43, Marc Haber wrote: On Tue, 4 Mar 2025 19:15:16 +0800, Blair Noctis wrote: [...] Honestly I never understood how exactly @p.d.o addresses work. Devref says it's "a simple email alias" that "provides a way to email the maintainer", "whatever their individual email address (or addresses) may be", but doesn't tell which kind of email addresses it forwards to. [...] though it seems further clarification can only come from p.d.o staff. "Staff" is a weird term to use in free software contexts. :-) p.d.o is a service, after all ;) In any case you're looking for https://salsa.debian.org/webmaster-team/packages/-/blob/debian-master/bin/build-maintainerdb Thanks, this seems to be the canonical source of an answer. Though with my limited Perl knowledge, I can only see that it 0. reads an override file, 1. searches through the indices/Maintainers file in an archive, whose naming presumably means the Maintainer field of packages, 2. records found email, but ignores when it ends with @p.d.o or @tracker.d.o, 3. writes remaining email, along with tracker dispatch address, for each package. So IIUC, @p.d.o address forwards to 1. the Maintainer if it's not again a @p.d.o, nor @tracker.d.o, 2. tracker subscribers. 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. Aside: I'm amused, and horrified at the same time, that such a maintainer "database" is a plain text file. -- Sdrager, Blair Noctis OpenPGP_signature.asc Description: OpenPGP digital signature
Re: MiniDebConf Hamburg 2025
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 10 Mar 2025 20:03, Matthias Geiger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, We're pleased to announce registration and call for proposals for MiniDebconfHamburg 25 is now open. It will be held from 30th April 2025 to 5th of May 2025 at dock europe in Hamburg, Germany. More details are on the wiki at [0] . [..] [0]: https://wiki.debian.org/DebianEvents/de/2025/MiniDebconfHamburg Hi all, as a fellow DD pointed out the correct link is https://wiki.debian.org/DebianEvents/de/2025/MiniDebConfHamburg Apologies for the mixup. best, werdahias -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQQUWTv/Sl6/b+DpcW7svtu2B7myvgUCZ89ObwAKCRDsvtu2B7my vmROAQCaJ3LgDuex51aFjpyleIkYcxkZeebdcBy1pAxI0/LRbQD8D6Vn+JlWFosN KTHdHE5LaIZFvTPsW5VY69bMm6QN/wQ= =HZTK -END PGP SIGNATURE-
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Quoting Marc Haber (2025-03-10 13:38:05) > 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. Back then some users didn't care to fix things and some found it worthy of pouring hard work into. Similar today. - 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: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)
Le Tue, Mar 11, 2025 at 04:39:00PM +0100, Simon Josefsson a écrit : > > Could you explain how I would ask for review of a package? I re-read > this thread, and the newgateway-team homepages, but I still don't > understand how you think the process should work. > > Could we test the process by reviewing 'litetlog'? Hi Simon, I have just drafted a workflow in https://salsa.debian.org/newgateway-team/reviews#how-to-request-or-make-a-review which I quote here: 0. (We are in pilot phases. Improvements of this workflow are welcome) 1. The package maintainer adds the [pipelines](https://salsa.debian.org/newgateway-team/pipelines) to its Salsa CI file. (It would be cool to have a _devscripts_ script for that.) 2. The package maintainer opens an issue with _Review_ template (shall we just make it default?). Salsa ID pings in the issue can be useful for exchanging reviews. 3. Once the checklist is clear, the maintainer uses the create merge request button in the issue page, to add the package in the table below. (Or just editing the file directly is fine?) 4. Somebody merges the request after verifying quickly that the checklist was properly addressed. 5. Reviewers open issues with the _Review_ template. If problems are found, they ping the maintainer with their salsa ID in the issue discussion. Reviews end by adding the issue ID in the table below via a MR to be accepted and merged by the package maintainer. 6. Once all reviewers thumbs are up, update the table below (with or without MR), and upload to NEW. 7. Once the package leaves the NEW queue, record the outcome in the table below. Surely, please join the tests with litelog! 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: Binary conflict between Midnight Commander and MinIO Client
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. 1. A user adds the minio path to their default shell. When the, mc.desktop launcher may now launch the minio thing instead of mc. 2. If Incus' $PATH is augmented, any tools run from Incus will also be affected by that change and may end up with an incompatible binary. I don't think the approach of augmenting the $PATH is a silver bullet here. Rather, it defers the problems to the end user where none of Debian's QA may have any effect. Stuff looks as if it were working, but the composed $PATH produces subtle breakage that is hard to diagnose. In the functional package manager world, this is less of a problem, because there executables tend to be hard coded using their full path. In principle, Debian could do the same, but then we loose the ability to add our own custom wrappers around existing tools to our $PATH. There is no silver bullet. Helmut
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Sun, Mar 09, 2025 at 03:58:59PM +0100, Simon Josefsson wrote: > > Agreed. However none of that hardware require me to load non-free > firmware from my operating system, which is my point. That situation is > sufficient for me to accept to use the hardware and install an operating > system built without non-free software on it. > Simon, Installing using the Debian installer doesn't *require* you to carry on with the firmware. You can readily remove it - especially if you use the expert install - you are not required to enable the repository in your /etc/apt/sources.list and so on. The installer does list the firmware suggested for install to enable all devices - you don't have to take that suggestion. So - if you don't *see* the need for firmware expressed and firmware is already in the machine you install on, that's fine? We've *had* this argument and the Project as a whole decided by a slim margin that the effort to maintain an installer relatively free of firmware (but including free firmware) AND an installer containing non-free firmware to aid installation of Debian was too much effort. To everyone wishing for this: If you want to make a Trisquel-ised Debian installer with a linux-libre kernel and no firmware, fine - happy for you and relatively happy to see you succeed. At that point there will no longer be a need for the Trisquel fork of Debian to continue on that basis and that will represent a consolidation of effort where Trisquel developers can then concentrate on Debian and stop being downstream of a downstream. . In the interim: That makes *lots* more effort for the Debian Project, lots more space needed for media and so on, as outlined earlier in the thread. Please feel free to step up and contribute significant effort yourself to see all of this come to pass. Andy Cater (amaca...@debian.org) > /Simon
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Tuesday, March 11, 2025 8:29:24 AM MST Simon Josefsson wrote: > Aurélien COUDERC writes: > > 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 ! > > Right, I think agreement (or disagreement) with those essays explains a > lot of what practical choices you make. > > > We're not a religion, we're just building a distro. > > I'm not sure what to make of that. Are you saying that Guix, Trisquel > etc who strive towards these concepts are not distro's? > > One person's religion is another person's reasonable beliefs. I'm not > sure who has the authority to judge. I'm sure some would dismiss the > DFSG as religion, even if we happen to like it here. > > It is fine for the Debian community to dismiss the arguments described > in the links above. This appears to be the case, although I hear some > voices that are open to change. > > However if Debian dismiss those ideas, the argument that the fully free > installer doesn't exist because "nobody is working on this, go create > them and it will happen" does not seem valid to me. My reading is that > these images doesn't exist because Debian had a vote saying they should > not exist. I hope this will change in the future. Creating them won't > change the decision, but it may be input to renewed discussion. I want to say that I agree with Simon on this. What we really need is the open hardware movement to catch up with the open software movement. That will take 20 to 30 years as the open hardware movement is just getting started. As many people have already pointed out, in most cases it isn’t practical to operate the hardware that is generally available without the use of non-free firmware. My sense is the majority of these people, perhaps all of them, are not saying they prefer hardware with non-free firmware or that they don’t support the ideals of the open hardware movement. Rather, they are making a pragmatic statement of the current state of affairs. To a certain degree, promoting official installer images without non-free firmware next to installer images with non-free firmware can raise awareness of the problem. To another degree, it probably wouldn’t do anything right now except confuse some subset of users and require extra effort from those generating the images. Debian is simply too small of an organization to make a very big splash by such a move. As has already been mentioned, nothing of substance has changed since Debian held a GR on this issue. However, if down the road open hardware with free firmware became more widely available (I’m looking at you, RISC-V, although I understand that the most likely short-term outcome is that companies will produce non-free firmware for their RISC-V processors), then it might be worth reopening the issue for consideration. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: General Questions about Translations and what a package maintainer has to do
Hello Marc,
I am currently new as Debian Maintainer, but I have more experience
from upstream-side.
As I understand your question about a general workflow of translations
in all your email-cases correct, I think the short answer maybe to use
`quilt` to patch the .PO files instead of committing them directly via
Git. Also consider `gbp-pq`, could be useful, but not sure.
The reason is, that you can merge (aka. apply) your patch-series
(patch-series: something like a branch in Git) at any time during
source-package building. As I'm new to Debian packaging I'm not sure
if it is possible to use "debian/patches"; but I think no, because the
step is hard-coded during `dpkg-buildpackage` -- and that is not what
we want.
I would recommend to use another quilt directory, like
`debian/patches-intl`. I don't know if there exist some other
recommended directory in any Debian Policy or Debian Guide. Then you
can call in `debian/rules` at the time you wish to apply your patch
series
```
$> QUILT_PATCHES=debian/patches-intl quilt push -a
```
The manual call in `debian/rules` ensures that you can decide yourself
at which step to apply your patches -- and decide if the
`dpkg-buildpackage` should break with an error on fail-patching, or
not. If the package maintainer changes, it should be easy to comment
out the one `quilt` command in `debian/rules` and remove the
patch-series `debian/patches-intl` from the package-repository.
To commit your changes to upstream you just need to apply (or ask to
apply) the patch-series into theres repository. Make sure to have
many small patches, then the chance is greater that some patches are
going to upstream, and maybe others not.
If these patches coming down from upstream `quilt push -a` stops with
a message like:
```
Applying patch debian/patches-intl/.patch
patching file
Hunk #1 FAILED at .
1 out of 1 hunk FAILED -- rejects in file
Patch debian/patches-intl/.patch can be reverse-applied
```
Quilt detects with the message 'can be reverse-applied' that it was
already applied by third-party. Then you can delete the patch in the
patch series with:
```
$> QUILT_PATCHES=debian/patches-intl quilt delete -nr
```
followed by completing to apply the patch series with a second `quilt
push -a` -- and repeatly so on, if more than one patches where
accepted by upstream.
Quilt also allows adapting your patches, in contrast to Git, at which
commits are forever or are needed to be reverted with a revert-commit
(see backport work-flows). That was also an issue you reported.
This workflow should also work if upstream already have translations
committed -- and/or you begin a fresh one. Maybe, not sure, that it
also solve the issue of the multiple calls of `msgmerge`; as I
understand, `msgmerge` was used as a kind of `patch`.
Hopefully this helps you for progression,
Dirk =)
On 3/11/25 12:03 PM, Marc Haber wrote:
tl;dr: We need more docs about best practices to handle translations as
a package maintainer
My fellow developers,
there are two things in being a DD that I truly despise. The one is
keeping the machine readable debian/copyright up to date, the other is
handling of translations, regardless of whether it's po-debconf, manpage
translations or program translations (when I am also the upstream).
I might rant about debian/copyright when I blow my fuse next time, but
today it's going to be translations. For me, it seems impossible to
support translator's work without putting a significant burden of
additional work to put on oneself. Especially when one uses version
control and does not do all development in Mast^wdebian/latest, dealing
with translations is a nightmare when it comes to merge. As the Newbie¹
DD I am, I keep running into either nightmare merges, or unnecessarily
fuzzed or even destroyed translations, in all cases feeling even more
stupid and incompetent when some translator points out my mistakes. I
have felt being sent back and forth between different workflows (all of
them wrong) by following random advice without being able to find
authoritative explanation.
I might have a fundamantal misunderstandig of procedures, but all
documentation one finds, including Chapter 8 in the Developer's
Reference (which links to a document by Tomohiro KUBOTA which is no
longer there), elaborate on how one would do actual translations, but
doesn't go as far as giving best practice documentation about what a
package maintainer is supposed to do to make translation blend into a
normal packaging workflow without being a nuisance ("put them into the
po directory and build the package" doesn't fit a modern packaging
workflow using version control).
My example package is adduser, but I think that my questions might apply
to other packages as well. adduser has both its program messages and the
manual pages translatable, the latter being done with po4a. I am aware
that there are also translations for debconf templates, but adduser
doesn't have those (
Bug#1100155: ITP: magnum-capi-helm -- Helm driven Cluster API driver for Magnum
Package: wnpp Severity: wishlist Owner: Guillaume Boutry X-Debbugs-Cc: debian-devel@lists.debian.org, boutryguillau...@gmail.com * Package name: magnum-capi-helm Version : 1.2.0 Upstream Contact: Dale Smith * URL : https://opendev.org/openstack/magnum-capi-helm * License : Apache2 Programming Lang: Python Description : Helm driven Cluster API driver for Magnum OpenStack Magnum driver using Helm to create k8s clusters with Cluster API. The driver uses capi-helm-charts to create the k8s resources needed to provision a k8s cluster using Cluster API, including various useful add-ons like a CNI and a monitoring stack. Note, the above Helm charts are intended to be a way to share a reference method to create K8s on OpenStack. The charts are not expected or intended to be specific to Magnum. The hope is they can also be used by ArgoCD, Flux or Azimuth to create k8s clusters on OpenStack. Similar package: https://packages.debian.org/sid/magnum-cluster-api The project magnum-capi-helm has been accepted upstream and is now under the governance of the Magnum project. It is a driver, meaning a specialized unit to deploy Kubernets clusters in an OpenStack cluster. The main reason I would like to see this project packaged is the possibility to override the source of helm charts to define the deployed clusters, thus bringing a greater flexibility in the flavor of deployments for kubernetes. This package would be an optional dependency for Magnum. I would like to package and maintain this driver. As this would be my first Debian package, I would be in need of a sponsor once this is ready. I am not sure as to whether this should be maintained under the OpenStack team as they might not want to maintain 2 similar drivers for Magnum? Relevant Team: https://wiki.debian.org/OpenStack
Bug#1100156: ITP: inkcut -- GUI for controlling vinyl cutters
Package: wnpp Severity: wishlist Owner: Alexander Sulfrian X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: inkcut Version : 2.1.5 Upstream Contact: Jairus Martin * URL : https://codelv.com/projects/inkcut/ * License : GPL-3 Programming Lang: Python Description : GUI for controlling vinyl cutters Features: * Graphic manipulation (Rotation, scaling, mirroring) * Copy generation and layout * Weedlines * Inkscape integration * Device control panel * Job history list * Live plot status * Pause, resume, and abort jobs mid way A plugin for inkscape is provided, too. I plan to maintain this package as part of the Debian Python team.
Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)
On Wed, 2025-03-12 at 09:52 +0900, Charles Plessy wrote: > I have just drafted a workflow in > > https://salsa.debian.org/newgateway-team/reviews#how-to-request-or-make-a-review > > which I quote here: > > 0. (We are in pilot phases. Improvements of this workflow are welcome) > > 1. The package maintainer adds the > [pipelines](https://salsa.debian.org/newgateway-team/pipelines) to its > Salsa CI > file. (It would be cool to have a _devscripts_ script for that.) I like the idea of pipelines that only create artifacts, without creating a pass/fail result that affects the package's overall CI. > 2. The package maintainer opens an issue with _Review_ template (shall we > just make it default?). Salsa ID pings in the issue can be useful for > exchanging reviews. > > 3. Once the checklist is clear, the maintainer uses the create merge request > button in the issue page, to add the package in the table below. (Or > just > editing the file directly is fine?) Wouldn't using an issue's open/closed status and tags be sufficient rather than MRs for each issue? For instance: - open = not in the archive yet - closed = in the archive / abandoned - tag "passed-review" - tag "accepted" when the package enters the archive I also suggest using a standard naming scheme like "package/version" (e.g. "r-cran-multitaper/1.0-17-1") for easy lookup of packages as well as different versions (for binNEW). Then, if ftp-masters want to check for a peer-review, they can just look for the name of the package in the list of open issues, named with a standard "package-name/package-version". And if the table in README is still necessary, then (I think) a CI pipeline can update it from the issue data. > 4. Somebody merges the request after verifying quickly that the checklist > was > properly addressed. > > 5. Reviewers open issues with the _Review_ template. If problems are found, > they ping the maintainer with their salsa ID in the issue discussion. > Reviews > end by adding the issue ID in the table below via a MR to be accepted and > merged by the package maintainer. > > 6. Once all reviewers thumbs are up, update the table below (with or without > MR), and upload to NEW. > > 7. Once the package leaves the NEW queue, record the outcome in the table > below. Some definition of scope would be useful (e.g. "we don't check if the program runs or if the package builds (that's the responsibility of the uploader), we just do the same checks as those that happen in the NEW queue"). Let me know how I can help! I enjoy reviewing copyright files, so if any arise, please send them my way :) -- Maytham signature.asc Description: This is a digitally signed message part
Re: General Questions about Translations and what a package maintainer has to do
Hi Marc,
Here are some of my thoughts based on my (relatively little) experience
with both translating to Arabic and receiving translations.
It might also be worthwhile to forward your message to
debian-i18n@l.d.o, since translators and i18n people are more likely to
be subscribed there and less likely to be subscribed here.
On Tue, 2025-03-11 at 12:03 +0100, Marc Haber wrote:
> (3)
> Some program (xgettext for program translations, po4a for manual pages
> and some podebconf tool for debconf templates) is used to pull the
> translatable strings from the source code and to create a POT file.
>
> xgettext doesn't even try to create a meaningful header and overwrites
> whatever one has written into the previous version of the POT file, so a
> wrapper is already needed to have a header that translators can fill
> (which they usually don't do).
>
> For Adduser's program translations, my call to xgettext is:
> xgettext --keyword=mtx --keyword=gtx --omit-header -o "$TEMP_FILE"
> --from-code=UTF-8 -L perl adduser deluser $(find . -name "*.pm")².
> TEMP_FILE then gets the generated header prepended to result in
> adduser.pot.
xgettext comes with a ton of options to help you. Have a look at the
diff I've attached for what I've been able to do.
Note that you shouldn't define the plural stuff in the POT file, that's
something that's set on a per-language basis. There should also be a
newline between the header and first message block.
> I have seen this being done in debian/rules' clean target which, in
> in-tree builds, causes the POT file to be changed as well and I don't
> understand at which step of the packaging process it would be a good
> idea to commit that POT file. If I build my package out of tree (like I
> do out of tradition of svn-buildpackage, I have gbp configured to use
> ../build-area), the POT file ends up newly generated in the source
> package but never gets updated in git. Adduser had POT files from 2022
> in git until just recently because I just never noticed. There is no
> lintian check and no check inside tracker.d.o for this.
>
> In other packages, there is a dedicated m4 macro to call xgettext which
> doesn't make things easier to understand.
Usually, all this stuff with generating and updating POT & PO files is
upstream's responsibility to deal with, hence why you'll find little
documentation for translating anything other than debconf templates. Since this
is a native package, it's up to you to do what you want. My suggestion is to
run this script before release; the most important thing is that it is run
after the program's messages are updated and _finalised_, and before sending it
to translators.
> (4)
> Then,
> msgmerge --update --backup=none --no-fuzzy-matching "${PO_FILE}" "${POT_FILE}"
> is called for every existing PO file. This doesn't move the header from
> the POT file to the existing PO file so stupidities like "# COPYRIGHT
> THE PACKAGE CREATOR" just never get fixed because the translators don't
> seem to care.
The header is only touched when the translation is initially created.
> If a po file for a language already exists during this step, the already
> existing translation gets merged into the new po file. In some
> circumstances that I have not understood yet, the translation gets
> "fuzzied",
A "fuzzy" translation is when the source string has been altered but not
entirely removed, meaning that the translated string needs to be
rechecked. This often occurs when there's a grammatical change or some
rewording in the source string.
> which I have been told causes a lot of unnecessary and
> repeated work for the translators which I am supposed to avoid by doing
> manual work myself which I don't understand. Not doing this work is
> condemned as "not being nice to translators".
Nothing is wrong with making translations fuzzy, sometimes it's
necessary.
I've rarely seen anyone being condemned for fuzzy translations (but then
again, I work in a language team that has virtually no members). The
only reason this would happen is if a maintainer kept making pointless
changes to the source strings to the point that translators are fed up
of reviewing the same strings over and over again, when they could be
creating new translations.
> Basically the same applies for this step than for the POT generation
> step, with the additional hardship that the PO files are generated,
> being written to by a program AND STILL contain a significant part of
> human work. I never know how much work of other people I am destroying
> by calling msgmerge out of line.
Just make sure that you're happy with the state of messages in the
program, since removing any source strings deletes them from the
translations as well. Since Git is being used, this is theoretically
reversible, but really should be avoided in the first place.
> In which stage of package build do I do
> msgmerge? Do I commit the merged po files, when do I commit them, what
> do I do with
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Am Montag, dem 10.03.2025 um 13:27 +0530 schrieb Pirate Praveen: > Basically hardware manufacturers are withholding code that they could > give you easily It is often not that easy because of stupid laws, for example laws that require vendors of radio devices to restrict the frequency range. That is often used as an excuse to not publish sources. But I totally agree that this is a deficiency. Non-free firmware should not exist. Regards signature.asc Description: This is a digitally signed message part
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Hi, On 3/10/25 17:52, Marc Haber wrote: 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. This is, however, a long term problem. The current state where we have free software drivers for a lot of hardware is the result of a lot of people investing a lot of time into creating them. In the same way, we need to do both: support our current users by allowing them to use non-free firmware with their current hardware, *and* push for new devices to have free firmware. Part of that push is informing users that what we do wrt firmware is best-effort, support for their hardware can be dropped at any point and the free software community cannot put them in control of their computing experience. 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. Simon
Re: Change the expectation that emails should wrap at 80 characters
The Wanderer writes: > To be fair, while I *am* against the proposal, I'm also not a Debian > Developer - just an interested observer of, and occasional participant > in, discussions on Debian mailing lists (including this one). +1 and to clarify my view on format=flowed: This should not be made part of any policy document at this time. An informal recommendation of this feature is more likely to confuse than help users. Application support is limited. My impression is that the config setting often is hard to find, if available at all. And some format=flowed implementations are too buggy to be usable. Those who know they can send properly formatted format=flowed emails should of course be allowed to do so. It is harmless and might improve readability for a few recepients. But I'm not a DD, so my views are completely irrelevant wrt discussions of a possible GR. Bjørn
Re: Change the expectation that emails should wrap at 80 characters
Before I did anything else, attempting to view your email in aerc
resulted in:
No filter configured for this mimetype ('text/markdown')
What would you like to do?
O Open using the system handler :open
S Save to file :save
| Pipe to shell command :pipe
I defined a filter (following some advice downthread):
text/markdown=pandoc -f markdown-blank_before_blockquote -t plain
And I can now read your mail. Without the blank_before_blockquote
variant the quoting would be broken. I think using the code block for
your signature is an interesting work-around.
--
Please do not CC me for listmail.
👱🏻 Jonathan Dowland
✎j...@debian.org
🔗 https://jmtd.net
