Re: Change the expectation that emails should wrap at 80 characters
Hi Soren, On Wed Feb 26, 2025 at 7:21 PM CET, Soren Stoutner wrote: The purpose of this email is to propose that the expectation that emails should be wrapped at 80 characters when they are sent should be dropped. Most GUI clients handle long lines just fine. Some others, like the aerc TUI client (which I use), don't (by default). It is worth noting that some people in the past tried to solve this wrapping issue with a proposed standard, [RFC 3676], which defines "Format=Flowed" emails. Such messages requires client capable of composing them, and many do, but some popular ones don't. In format=flowed messages, lines are hard-wrapped "transparently". Long lines are wrapped with line breaks, but with a trailing space. Receiving clients then consider lines with a trailing space a single logical line, and are free to re-wrap as they prefer. If you receiving client does not support format=flowed, though, you'll just see a message wrapped at 72 cols. Choosing between sending long lines and flowed text is, to me, a trade-off. Format=flowed requires sender support, but looks good on "dumb" clients. Long lines do not require any special sender support, but looks odd "dumb" clients. In any case, I feel discussing about RFC 3676 might be a bit off-topic on -devel, so I'll end it here. I started thinking about this a few weeks ago when I received an email from a Debian Developer complaining that replies from my email client (KMail) looked odd because they truncated quoted lines in a way that did not lay out pleasingly. This was because I had set KMail to wrap lines at 80 characters. (sorry, I didn't mean to haunt your thoughts) Bye! [RFC 3676]: https://datatracker.ietf.org/doc/html/rfc3676 signature.asc Description: PGP signature
Re: Change the expectation that emails should wrap at 80 characters
On Feb 26, Soren Stoutner wrote: > The purpose of this email is to propose that the expectation that > emails should be wrapped at 80 characters when they are sent should be > dropped. I am opposed. -- ciao, Marco signature.asc Description: PGP signature
Re: Gnome 48 dependency on Xwayland
On Wed, 2025-02-26 at 10:27 -0500, Jeremy Bícha wrote: > No. We are not going to build GNOME for Trixie without support for > Xorg. My question was neither of that. 1. Gnome can already be installed without Xorg in Bookworm and works fine. 2. I was talking about removing specifically Xwayland (not Xorg!) as a required dependency on the package level. > That may be useful for kiosks but is not useful in a general > purpose OS like Debian at this time. It should be installed by task-desktop, but it should not be mandatory if Gnome can be run without it and Xwayland is rarely running nowadays when using GTK3 and GTK4 apps. > Also, please report a bug for this kind of packaging suggested change > instead of emailing this list. Looks like this needs a more general discussion to clear up the misunderstandings. Regards signature.asc Description: This is a digitally signed message part
Re: Change the expectation that emails should wrap at 80 characters
On Wed, Feb 26, 2025 at 11:21:42AM -0700, Soren Stoutner wrote: > The purpose of this email is to propose that the expectation that emails > should be wrapped at 80 characters when they are sent should be dropped. You MUA lacks support for RFC 2646, which is 25 years old. Also it creates Message-Id without a proper FQDN. Please just leave us alone. Bastian -- Violence in reality is quite different from theory. -- Spock, "The Cloud Minders", stardate 5818.4
Bug#1098954: ITP: liborson-charts-java -- A 3D chart library for Java applications (JavaFX, Swing or server-side).
Package: wnpp Severity: wishlist Owner: Christian Bayle X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: liborson-charts-java Version : 2.1.0 Upstream Contact: David Gilbert * URL : https://github.com/jfree/orson-charts * License : GPL-3 Programming Lang: Java Description : A 3D chart library for Java applications (JavaFX, Swing or server-side). Orson Charts is a 3D chart library for the Java™ platform that can generate a wide variety of 3D charts for use in client-side applications (JavaFX and Swing) and server-side applications (with export to PDF, SVG, PNG and JPEG).
Bug#1098955: ITP: libjfreesvg-java -- A fast, lightweight Java library for creating Scalable Vector Graphics (SVG) output.
Package: wnpp Severity: wishlist Owner: Christian Bayle X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libjfreesvg-java Version : 5.0.6 Upstream Contact: David Gilbert * URL : https://github.com/jfree/jfreesvg * License : GPL-3 Programming Lang: Java Description : A fast, lightweight Java library for creating Scalable Vector Graphics (SVG) output. JFreeSVG is a graphics library for the Java(tm) platform that allows you to generate content in SVG format using the standard Java2D drawing API (Graphics2D). JFreeSVG is light-weight, fast, and has no dependencies other than the Java runtime (11 or later).
Gnome 48 dependency on Xwayland
According to reports and changelogs, Gnome 48 should be working without Xwayland. https://gitlab.gnome.org/GNOME/gdm/-/blob/main/NEWS Can you remove the package dependency in Debian? Regards signature.asc Description: This is a digitally signed message part
Re: Gnome 48 dependency on Xwayland
On Wed, Feb 26, 2025 at 10:10 AM Stephan Verbücheln wrote: > According to reports and changelogs, Gnome 48 should be working without > Xwayland. > > https://gitlab.gnome.org/GNOME/gdm/-/blob/main/NEWS > > Can you remove the package dependency in Debian? No. We are not going to build GNOME for Trixie without support for Xorg. That may be useful for kiosks but is not useful in a general purpose OS like Debian at this time. Also, please report a bug for this kind of packaging suggested change instead of emailing this list. https://www.debian.org/Bugs/Reporting Thank you, Jeremy Bícha
Bug#1098952: ITP: libjfreepdf-java -- JFreePDF is a modular library for the Java platform that provides an implementation of the Graphics2D API that emits PDF.
Package: wnpp Severity: wishlist Owner: Christian Bayle X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libjfreepdf-java Version : 2.0.1 Upstream Contact: David Gilbert * URL : https://github.com/jfree/jfreepdf * License : GPL-3 Programming Lang: Java Description : JFreePDF is a modular library for the Java platform that provides an implementation of the Graphics2D API that emits PDF. JFreePDF is a library module for the Java(tm) platform that allows you to create content in Adobe's Portable Document Format (PDF) using the standard Java2D drawing API (Graphics2D). JFreePDF is light-weight, fast, and has no dependencies other than the Java runtime (11 or later). The home page for the project is:
Re: Gnome 48 dependency on Xwayland
Am 26.02.25 um 16:27 schrieb Jeremy Bícha: On Wed, Feb 26, 2025 at 10:10 AM Stephan Verbücheln wrote: According to reports and changelogs, Gnome 48 should be working without Xwayland. https://gitlab.gnome.org/GNOME/gdm/-/blob/main/NEWS Can you remove the package dependency in Debian? No. We are not going to build GNOME for Trixie without support for Xorg. That may be useful for kiosks but is not useful in a general purpose OS like Debian at this time. Is this a hard build-time only option for gnome-shell? Or can gnome-shell/mutter detect this at runtime (making Xwayland as Recommends an option)? OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Change the expectation that emails should wrap at 80 characters
On 2025-02-26, at 11:21:42 -0700, Soren Stoutner wrote: > The purpose of this email is to propose that the expectation that > emails should be wrapped at 80 characters when they are sent should be > dropped. No, thanks. J. signature.asc Description: PGP signature
Re: Gnome 48 dependency on Xwayland
On Wed, Feb 26, 2025 at 2:19 PM Stephan Verbücheln wrote: > Looks like this needs a more general discussion to clear up the > misunderstandings. Please, please file a bug instead. I don't want to discuss package change requests like this on debian-devel especially when you haven't tried filing a bug first. Thank you, Jeremy Bícha
Re: Salsa CI job 'missing-breaks' to be enabled by default starting March 1st
Thanks for the feedback! Ideally the script https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/images/scripts/check_for_missing_breaks_replaces.py would live in the devscripts package and be extended to have the features suggested in this thread. However, even in its current form it has worked well for many years, and I having it enabled by default in Salsa CI now will catch some regressions from entering the archive (and Trixie), and is a better choice than postponing the change with expectations that would have more features in near future.
Change the expectation that emails should wrap at 80 characters
The purpose of this email is to propose that the expectation that emails should be wrapped at 80 characters when they are sent should be dropped. Currently, the code of conduct for the mailing lists says: "Wrap your lines at 80 characters or less for ordinary discussion. Lines longer than 80 characters are acceptable for computer-generated output (e.g., ls -l).” https://www.debian.org/MailingLists/ I started thinking about this a few weeks ago when I received an email from a Debian Developer complaining that replies from my email client (KMail) looked odd because they truncated quoted lines in a way that did not lay out pleasingly. This was because I had set KMail to wrap lines at 80 characters. The purpose of that email was to explain that KMail should be more intelligent in the way it wrapped the quoted lines, which is a fair point, although KMail handles things better than some of the emails I receive on the lists from time to time. However, from a technical perspective, having the *sending* program decide where line breaks should be in an email doesn’t seem like the correct approach to me because, 1) the sending program does not know the screen width of the receiving program, and 2) there is large variability in the screen width of receiving devices, including cell phones who are often less than 80 characters wide. I understand that there are historical reasons for the 80 character limit, but I believe that it is time to reassess best practices. My recommendation is that sending email programs should not wrap text at an arbitrary column, and that all wrapping of text should be handled by the receiving program, which is, of course, the only program that has insight into the width of the screen where the email is currently being displayed. I have composed this email without an arbitrary column wrap, so that those receiving it can see how it is handled by their various clients and devices. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Change the expectation that emails should wrap at 80 characters
On 2025-02-26 11:21:42 -0700 (-0700), Soren Stoutner wrote: [...] > I have composed this email without an arbitrary column wrap, so > that those receiving it can see how it is handled by their various > clients and devices. I'll note that I'm somewhat of a traditionalist, reading list mail (all E-mail really) with the current version of mutt from sid in an emulated 80x24 character terminal, because I spent years in front of serial terminals designed for that geometry (80x25 really but the bottom row is occupied by the terminal's status bar) and got overly accustomed to it. Mutt's default configuration handles non-wrapped long lines fairly gracefully, wrapping them at the last identifiable space character before the terminal's margin, or at the last character if it's an unbroken "word" longer than the terminal width, but then prefixing subsequent wrapped lines with a "+" to indicate they were all actually part of the same line originally. The only real hassle is if I want to copy a very long URL out of a message, I either need to piecemeal reassemble it from the lines that URL is spread across or pipe the body into another tool that doesn't wrap anything. It's likely there are config options for Mutt to alleviate this, I just haven't bothered to go digging. For the record, the editor I compose my messages in is set to wrap at 68 columns in order to avoid my lines being too long when quoted several indent levels deep, but I do sometimes manually re-flow any quoted material I haven't trimmed from others' messages if I see they're near to or exceeding my 80-character terminal margin. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Change the expectation that emails should wrap at 80 characters
* Jeremy Stanley [250226 13:39]: > The only real hassle is > if I want to copy a very long URL out of a message, I either need to > piecemeal reassemble it from the lines that URL is spread across or > pipe the body into another tool that doesn't wrap anything. It's > likely there are config options for Mutt to alleviate this, I just > haven't bothered to go digging. Try urlscan. ...Marvin
Re: Change the expectation that emails should wrap at 80 characters
On 2025-02-26 15:30:48 -0500 (-0500), Marvin Renich wrote: > * Jeremy Stanley [250226 13:39]: > > The only real hassle is > > if I want to copy a very long URL out of a message, I either need to > > piecemeal reassemble it from the lines that URL is spread across or > > pipe the body into another tool that doesn't wrap anything. It's > > likely there are config options for Mutt to alleviate this, I just > > haven't bothered to go digging. > > Try urlscan. Thanks, yes that's what I mean by piping the body into another tool. Both urlscan and the older urlview are probably fine if mutt is running on your local system, in my case it's running on a remote system and I just want to be able to copy the URLs from my terminal without anything fancy trying to interpret or truncate/abbreviate them, react to my pointer, et cetera. Setting a macro to pipe the body through less or vi(ew) has been working well enough for my needs, but some quick testing indicates that if I override markers to no in my muttrc to get rid of the "+" at the start of wrapped lines, that basically solves the long URL copying problem, albeit at the expense of no longer knowing whether mutt wrapped a line for me (not a huge loss, in my opinion). -- Jeremy Stanley signature.asc Description: PGP signature
Bug#1098975: ITP: python-slip10 -- Reference implementation of the SLIP-0010 specification
Package: wnpp Severity: wishlist Owner: Soren Stoutner X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-slip10 Version : 1.0.1 * URL : https://pypi.org/project/slip10/ * License : Expat Programming Lang: Python Description : Reference implementation of the SLIP-0010 specification A reference implementation of the SLIP-0010 specification, which generalizes the BIP-0032 derivation scheme for private and public key pairs in hierarchical deterministic wallets for the curves secp256k1, NIST P-256, ed25519 and curve25519. python-slip10 is a dependence of the latest version of python-trezor. I plan to maintain it under the Debian Python team umbrella.
Re: Flames, flames on the side of my face (Was: Bug#88588: libpam-modules: pam-limits.so is broken)
Thanks
