Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?
> Even then, AFAIR Qt does not enable Wayland support by default, and it > might need the following environment variables Having installed the packages, I'm able to choose KDE's Wayland session from SDDM and it works out-of-the-box. Applications don't run with Xwayland, and I've stumbled on some Wayland-specific bugs that've been reported already.
Bug#1035318: ITP: golang-github-bemasher-rtltcp -- Go library interface to an rtltcp daemon
Package: wnpp Severity: wishlist Owner: John Scott X-Debbugs-Cc: debian-devel@lists.debian.org Control: block 1025210 by -1 * Package name: golang-github-bemasher-rtltcp * URL : https://github.com/bemasher/rtltcp * License : AGPLv3 Programming Lang: Go Description : Go library interface to an rtltcp daemon This is a Go library that allows programs a high-level means of interacting with rtltcp, a daemon that allows for remote control of an RTL-SDR (if you're familiar with SoapyRemote, it's similar). This is the last remaining dependency for packaging rtlamr, a program from the same author. Note that this library is under the AGPLv3, not the ordinary GPL, so applications that use it need to be AGPL-compatible (generally means AGPL or GPL), and then the final binary is subject to the AGPL. I'm aware of the recent discussions around Berkeley DB and how problematic this can be for programs that aren't traditionally thought of as being network-facing, but since rtlamr is by the same author under the same license and thought to be its only user, my opinion is that this is pretty insignificant. If other programs use this library someday, of course, we'll have to check that they are respectful of the license. I will maintain this in the Debian Go Team's umbrella and in accordance with their practices because it's written in Go, but it will be used mostly by ham radio folks. I'm not a Debian Developer or Maintainer, so I'm grateful to have already identified a possible sponsor who is knowledgeable in both areas. signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Re: [External] Re: Intel SOF audio firmware packaging
> firmware could also be built but dependencies would be hard to > package/maintain - as I understood - those need a forked xtensa > compiler. I'm adopting the firmware-ath9k-htc package at the moment, which also uses a forked xtensa compiler and is built from source. Rather than package the custom toolchain first, I build the toolchain in addition to the firmware at the same time. I don't know that I'll have time before the freeze to help, but after Bullseye is released I think it would be relatively unpainful with my groundwork laid. That said I've not looked at the audio firmware and if it typically needs to be digitally signed, that's a bummer. signature.asc Description: This is a digitally signed message part.
Re: Making Debian available
On Sunday, January 17, 2021 6:06:15 AM EST Bjørn Mork wrote: > All these USB devices work only because they come with firmware on a largish > flash. That's not the complete case. Of the modern libre USB WiFi dongles I know of, carl9170 (firmware for AR9170 chips) is included in firmware-linux-free and should be in the installer. These devices are a little older, but support 802.11n and even dual-band 2.4GHz/5GHz connectivity for some. The newer flagship chips for USB wireless dongles, ath9k_htc (AR7010/AR9271), have libre firmware released by Qualcomm Atheros upon request of ThinkPenguin, their employees, and other interested parties. This firmware isn't included in the installer or installed by default with firmware-linux-free yet, but is provided by the firmware-ath9k-htc package I maintain. A takeaway from Theo de Raadt and the OpenBSD Project's successes on wireless devices is that it doesn't hurt to ask. IMHO, a message in the Debian Installer should be clear to place blame on the device manufacturers, something I don't think the current message about nonfree firmware emphasizes, signature.asc Description: This is a digitally signed message part.
Re: Making Debian available
On Sunday, January 24, 2021 7:19:58 AM EST Bjørn Mork wrote: > What we are left with is users who are offended by the mere existence of > non-free binaries on a Debian image, and who see this as significantly > worse than the non-free firmware in their NIC, SSD, EC, CPU etc. The reason why, say, wireless firmware is more serious from a software freedom standpoint (and I believe the FSF's stance) is: 1. Unlike with SSD firmware, there are wireless cards that use libre firmware and some are still manufactured and quite easy to attain. The goalpost for free software moves with what has been achieved. One used to have to accept using a proprietary BIOS, but not anymore; Coreboot/Libreboot have pushed that boundary, so now it's been realized as something attainable. When the first libre SSD comes out, then we can worry about SSD freedom, because then we'll be able to lend our support. 2. Firmware copied by Debian onto a device's RAM is very easy to change for the manufacturer with an update: they get the liquidity of software at their disposal. The user doesn't get to take advantage of this, so the manufacturer holds a good amount of control over the user, comparable to ordinary software. Changing the firmware on an EEPROM is far less practical for the user or manufacturer (they're on similar footing), and if it's not electronically erasable, it's merely an object that can't be practically changed of which you'd need to make a new one anyway. I hope this explains the viewpoints of those opposed to the proprietary firmware in installation images, and why they distinguish it from other notions of firmware. signature.asc Description: This is a digitally signed message part.
Bug#986778: ITP: gcc-sh-elf -- GNU C compiler for embedded SuperH devices
Package: wnpp Severity: wishlist Owner: John Scott X-Debbugs-Cc: debian-devel@lists.debian.org, pkg-electronics-de...@alioth-lists.debian.net Control: block -1 by 912271 980889 * Package name : gcc-sh-elf Upstream Author : GNU Project * URL : https://gcc.gnu.org * License : GPL Programming Lang: C, C++ Description : GNU C compiler for embedded SuperH devices This native package will provide a build of gcc as a cross-compiler for bare-metal SuperH devices as well as a build of Newlib to serve as the ISO C standard library. My primary motivation is to make possible building carl9170, the libre wireless firmware for Atheros AR9170 USB wireless adapters, but it may be useful for other applications as well. I plan to maintain this within the Electronics Team. signature.asc Description: This is a digitally signed message part
Re: debian 11 Bullseye RC 1
On Sat, 2021-05-29 at 07:27 -0400, Timothy M Butterworth wrote: > Can anyone suggest a WiFi USB adapter that works with debian? (Disclaimer: I'm the maintainer of the firmware-ath9k-htc package, and ThinkPenguin, one of the vendors, has compensated me for my work.) I suggest getting a wireless adapter that is Respects Your Freedom certified by the Free Software Foundation to work with only free software. You can see a list of those here: https://ryf.fsf.org/products?category=7 These are guaranteed to work with fully free software and free firmware. Most (all?) of the USB ones use the ath9k_htc chipset, and although they're not yet working with the installer (#934822) or working out of the box (#900171), they work if you install the firmware-ath9k-htc package. Alternatively, you may reply to me privately if you're looking for advice on how to hunt eBay for bargain ones, although then you're taking a gamble of whether a device really has the chip inside it's supposed to. signature.asc Description: This is a digitally signed message part
Re: debian 11 Bullseye RC 1
On Sat, 2021-05-29 at 23:26 +0500, Andrey Rahmatullin wrote: > > On Sat, 2021-05-29 at 07:27 -0400, Timothy M Butterworth wrote: > > > Can anyone suggest a WiFi USB adapter that works with debian? > > > > (Disclaimer: I'm the maintainer of the firmware-ath9k-htc package, > > and ThinkPenguin, one of the vendors, has compensated me for my work.) > > > > I suggest getting a wireless adapter that is Respects Your Freedom > > certified by the Free Software Foundation to work with only free > > software. You can see a list of those here: > > https://ryf.fsf.org/products?category=7 > No 802.11ac, right? Correct, to the best of my knowledge there don't exist any libre Wi-Fi adapters supporting 802.11ac, USB or otherwise. Even the OpenWifi project seems to have their sights set on 802.11n. In theory this might not be a hardware limitation, but a driver+firmware one. signature.asc Description: This is a digitally signed message part
Bug#994625: ITP: carl9170fw -- libre firmware for AR9170 USB wireless adapters
Package: wnpp Severity: wishlist Owner: John Scott X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ker...@lists.debian.org Control: block -1 by 986778 Control: block 890601 by -1 Control: affects -1 linux-firmware-free * Package name : carl9170fw Version : 1.9.9-399-gcd480b9 Upstream Author : Linux wireless maintainers * URL : https://github.com/chunkeey/carl9170fw * License : mostly GPLv2-only Programming Lang: C Description : libre firmware for AR9170 USB wireless adapters This is carl9170, the libre firmware for Qualcomm Atheros's AR9170 802.11n USB wireless adapters that complements the carl9170 Linux driver. carl9170 is already shipped in firmware-linux-free, but the primary objective of transitioning it into this new source package is to get it building from source. This is possible with the SuperH bare-metal cross toolchain I'm packaging. I will need sponsorship for this package (and am currently seeking sponsors for the cross toolchain too); the Kernel Team may help with the former. Regardless, co-maintainers/uploaders are welcome and I'd be glad to help prospective contributors get adapters, as they can be a little tricky to find. signature.asc Description: This is a digitally signed message part
Re: Bug#980889: RFP: binutils-sh-elf -- cross binary utilities for SuperH bare-metal systems
On Fri, 2021-10-22 at 11:18 +0200, John Paul Adrian Glaubitz wrote: > I had a look at the package and it throws a number of lintian errors. Are you > planning to address these or are they common for all binutils-$ARCH-elf > packages > we currently have in Debian? I believe you're referring to debian-rules-missing-required-target and debian-rules-missing-recommended-target. In this case, Lintian seems to not recognize that I'm using Debhelper via the .DEFAULT target in the Makefile. I've filed a Lintian bug for this (#983539). If it's really bothersome, I could switch debian/rules from .DEFAULT: dh $@ to %: dh $@ but I personally prefer the former as a stylistic choice, and this would cover up an area where Lintian should be smarter. As for debian-rules-sets-DH_COMPAT, which is merely a warning, Lintian has this to say: > As of debhelper version 4, the DH_COMPAT environment variable is only > to be used for temporarily overriding debian/compat. Any line in > debian/rules that sets it globally should be deleted and a separate > debian/compat file created if needed. I don't set DH_COMPAT globally; I use it as a temporary override for dh_auto_configure, and my source comments explain why I do this. I would consider filing a Lintian bug, and still would if you'd like me to, but frankly I'd like to keep the warning around as a reminder that we should drop this hack when we're able. signature.asc Description: This is a digitally signed message part
Bug#1025210: ITP: rtlamr -- RTL-SDR receiver for smart utility meters
Package: wnpp Severity: wishlist Owner: John Scott X-Debbugs-Cc: debian-devel@lists.debian.org, debian-h...@lists.debian.org, debian...@lists.debian.org * Package name : rtlamr Version : 0.9.1 Upstream Author : Douglas Hall * URL : https://github.com/bemasher/rtlamr * License : AGPLv3 only Programming Lang: Go Description : RTL-SDR receiver for smart utility meters rtlamr is a program for using an RTL-SDR (and maybe other SDRs?) to receive readings from smart utility meters. I use this software, an willing to maintain it, and will make sure it stays in good shape. I have confirmed that it works with commonly available meters. This is useful for a variety of creative purposes, such as analyzing one's own energy usage, or even energy usage within a community, or to identify water leaks. As far as I know, no other packages provide similar functionality. The closest package is rtl_433, and it doesn't support these devices. I'm neither DD nor DM and will need a sponsor. I will maintain this either within the Go Team or the Ham Radio Team. I've CC'ed both of them to see if it piques their interest or if they have a preference. I would really like it if a fellow ham would see about getting it to work with an alternate SDR. signature.asc Description: This is a digitally signed message part
Bug#1033888: ITP: usbscale -- read weight data from a USB scale
Package: wnpp Severity: wishlist Owner: John Scott Tags: newcomer X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : usbscale Upstream Contact: Eric Jiang * URL : https://github.com/erjiang/usbscale * License : GPL 3.0 or any later version Programming Lang: C Description : read weight data from a USB scale This package provides a utility one can use to read data from various USB scales, ones which are sold as postage scales in particular. Even though the program is very small, I still think it belongs in Debian. As far as I know, there are no applications in Debian that are capable of reading this sort of data. With usbscale, it's easy for medium-volume mailers to have scripts or utilities that talk to usbscale and, say, do automatic postage price computation. I use this application sometimes. I'm not a Debian Developer and will need a sponsor. I can't think of any pertinent teams to maintain it in, but since it's a small package, I see no problem with maintaining it on my own. I am familiar with Debian Packaging and will probably be able to get this out in the next few days. signature.asc Description: This is a digitally signed message part
Re: What is going on with atomics?
Hello everyone, (TL;DR at the end) I've mostly been lurking on Debian mailing lists for a long time, so if you don't know me, I'm John, a Debian Maintainer working on a couple cross toolchains for building the device firmware that *is* free from source, but I pitch in on many packages here and there and wear different hats. I still have a lot to learn, but I'm working my way down the stack to learn more and to advance free software as well as hardware that can facilitate it. I don't represent Debian in this capacity, but in particular I'm a member of The Austin Group (https://www.opengroup.org/austin/), the body that maintains the POSIX and Single UNIX Specification standards—although I'm mostly an observer there and likewise do not speak for them. I think a few other Debian contributors are members as well; a full list is at https://pubs.opengroup.org/onlinepubs/9799919799/frontmatter/participants.html In mid-2024, The Open Group and the IEEE (and hopefully the ISO/IEC standards bodies soon as well) published POSIX Issue 8 and the Single UNIX Specification 5 (SUSv5). The reason I'm sharing that is because POSIX specifies how a C compiler can be invoked on a conforming system so that essential functionality can work across different UNIX-like systems without needless change. A big part of the 2024 major revision, the first in about fifteen years, was incorporating C11/C17, the version of the ISO C standard that introduced atomics. In this revision of POSIX, the standardized C compiler is installed under the name 'c17'. Neither Debian nor GCC make any claims to adhere to this part of the standard and there have always been minor quirky differences between GCC's command-line syntax parsing and how the standard says it should be done for the standardized compiler (formerly named 'c99'), but in practice I believe GCC and GNU software generally tries to adhere when it makes sense and entertains patches to improve compatibility with other systems and standards when they're wholesome. POSIX says that systems may require specific compiler flags to access particular sets of functions. For example, use of the "-l m" option may be required for the math functions to be available when building an application. At https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358#c16 you can see the bug report to GCC upstream asking for GCC to link with the atomics support library when necessary as required. Atomics require special care mainly from the compiler and its machine code underpinnings (as opposed to the ISO C standard library), so GCC is the main orchestrator of atomics and is best informed to handle this. In my reply to that bug, I shared an insight I had which is that, in my personal opinion in trying to interpret the specification, a compiler conforming to POSIX may *not* require the usage of special compiler flags to get support for atomics, except if those systems pre-define the __STDC_NO_ATOMICS__ macro to indicate the absence of any claim by the OS to support atomics. In particular POSIX does not specify an "-l atomic" option, but it does say that the compiler, by default, will expose all of the symbols needed for functions and objects specified in headers like , except for those special exceptions like "-l m" for math and "-l rt" for realtime functionality. No such exception was added for atomics-related symbols. GNU is not afraid to deviate from specifications if doing so better serves users (https://www.gnu.org/prep/standards/html_node/Non_002dGNU-Standards.html), but they ultimately do whatever is most useful, especially when they coincide. This quirk of how to link with support for atomics mostly shows up on less common architectures and I figured maybe this hasn't been on GCC's radar because of that, and folks building software for such systems are probably more likely to figure out how to appease the compiler on-the-fly. Therefore, in my appeal on the upstream bug, I shared that addressing this issue in practice will have the bonus feature of helping standards conformance and interoperability with other systems as well (this being more of an "issue in principle"). I was delighted when I saw in my inbox some time later an update that a fix had been made upstream. It apparently caused regressions on some systems so it had to be promptly reverted, but this is to say that problem-solving efforts have been making great strides very recently. For Debian's needs, as-needed linking with libatomic could maybe be done without as much fuss downstream in the meantime, but I don't really work on Debian's core GCC packages and can't judge how easy this could be. This silly technicality is not something that upstream applications should have to care about, or even really build systems. GCC is the right place to fix this and they're fortunately doing it right now. Other downstream hacks we might could do is have dpkg or debhelper set build flags appropriately, a
