Re: O: nvi - 4.4BSD re-implementation of vi
On Tue, Feb 06, 2024 at 06:38:18PM +0100, Paride Legovini wrote: > Hi Tobias! > > On 2024-02-05 10:43, Tobias Heider wrote: > > On Sat, Jan 26, 2013 at 12:38:07AM +, Stuart Prescott wrote: > >> > >> The maintainer for the "nvi" package has indicated that he is unable to > >> maintain this package for the time being. I'm marking this package as > >> orphaned > >> now. > > > > Looks like this is still orphaned over ten years later. > > > > As an active nvi user I would love to step up and help, but the biggest > > problem I see is that the choice of upstream project. Since the original > > is gone there isn't a clear successor. > > > > The BSDs all have their own forks which diverged over time (and those don't > > build on Linux). > > The other two options there are today are https://repo.or.cz/nvi.git which > > d/control currently points to and more recently > > https://github.com/lichray/nvi2. > > > > The first has a very low commit frequency (last commit was 2020, before > > that 2016) and sticks very closely to the original source. nvi2 has added > > new features such as multibyte support and is starting to receive bug fixes > > and features from the different *BSD forks. > > > > I have been thinking of proposing a new package for nvi2 but maybe it would > > make more sense to move this one to the more active upstream. It looks like > > some of the issues we are carrying patches for in Debian might be fixed > > there > > already and if not they seem active enough to merge our fixes. > > > > What would be the best way forward here? ITA and eventually switch the > > upstream > > or start a new package and let this one continue its slow death? > > I think making the O bug and ITA and switching upstream is right thing to > do here, maybe explaining the history of the package in README.source. > > I can't think think of a reasonable use case where nvi2 would not be > a suitable drop-in replacement for nvi; if neither can you (knowing > the editor way better than me!), then I'd say go for the switch. > > I'll be happy reviewing/sponsoring if needed. Thanks! Yours and Andreas' feedback give me enough confidence that it might be worth it, so I'll start hacking and see if it's doable. I think I'll ITA and check if I can fix some smaller things first before making the big move, since that will require more time and lots of testing to make sure everything still works. I'll let you know if I have something that needs sponsoring! > > Cheers, > > Paride >
Re: O: nvi - 4.4BSD re-implementation of vi
On Sat, Jan 26, 2013 at 12:38:07AM +, Stuart Prescott wrote: > Package: wnpp > Severity: normal > > The maintainer for the "nvi" package has indicated that he is unable to > maintain this package for the time being. I'm marking this package as orphaned > now. If you want to be the new maintainer, please take it -- see > http://www.debian.org/devel/wnpp/index.html#howto-o for detailed instructions > how to adopt a package properly. > > Description-en: 4.4BSD re-implementation of vi > Vi is the original screen based text editor for Unix systems. > It is considered the standard text editor, and is available on > almost all Unix systems. > . > Nvi is intended as a "bug-for-bug compatible" clone of the original > BSD vi editor. As such, it doesn't have a lot of snazzy features as do > some of the other vi clones such as elvis and vim. However, if all > you want is vi, this is the one to get. > Looks like this is still orphaned over ten years later. As an active nvi user I would love to step up and help, but the biggest problem I see is that the choice of upstream project. Since the original is gone there isn't a clear successor. The BSDs all have their own forks which diverged over time (and those don't build on Linux). The other two options there are today are https://repo.or.cz/nvi.git which d/control currently points to and more recently https://github.com/lichray/nvi2. The first has a very low commit frequency (last commit was 2020, before that 2016) and sticks very closely to the original source. nvi2 has added new features such as multibyte support and is starting to receive bug fixes and features from the different *BSD forks. I have been thinking of proposing a new package for nvi2 but maybe it would make more sense to move this one to the more active upstream. It looks like some of the issues we are carrying patches for in Debian might be fixed there already and if not they seem active enough to merge our fixes. What would be the best way forward here? ITA and eventually switch the upstream or start a new package and let this one continue its slow death? Tobias
Bug#1055943: ITP: asahi-audio -- PipeWire DSP profiles for Apple Silicon machines
Package: wnpp Severity: wishlist Owner: Tobias Heider X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: asahi-audio Version : 0.5 Upstream Authors: The Asahi Linux Contributors URL : https://github.com/AsahiLinux/asahi-audio * License : MIT Description : PipeWire DSP profiles for Apple Silicon machines PipeWire and WirePlumber DSP profiles and configurations to drive the speaker arrays in Apple Silicon laptops and desktops. I hope to maintain this package as part in the bananas-team. See also: https://wiki.debian.org/Teams/Bananas - Tobias
Re: Linking coreutils against OpenSSL
On Thu, Nov 09, 2023 at 11:13:51PM +, Luca Boccassi wrote: > On Thu, 9 Nov 2023 at 22:54, Benjamin Barenblat wrote: > > > > Dear Debian folks, > > > > coreutils can link against OpenSSL, yielding a substantial speed boost > > in sha256sum etc. For many years, this was inadvisable due to license > > conflicts. However, as of bookworm, coreutils requires GPL-3+ and > > OpenSSL is Apache-2.0, so I believe all license compatibility questions > > have been resolved. > > > > What would you think about having coreutils Depend on libssl3? This > > would make the libssl3 package essential, which is potentially > > undesirable, but it also has the potential for serious user time savings > > (on recent Intel CPUs, OpenSSL’s SHA-256 is over five times faster than > > coreutils’ internal implementation). > > This sounds great. systemd also uses OpenSSL for various things, so > libssl3 is pretty much a given on any bootable installation anyway > already. Strongly agree. In addition to possible performance gains I think there are other benefits. Fewer better reviewed crypto implementations and a single upgrade path would be two, especially since like you say libcrypto is pretty much always there anyway. > > > Alternatively, what would you think about making sha256sum etc. > > divertible and providing implementations both with and without the > > OpenSSL dependency? > > Please, no, no more diversion/alternatives/shenanigans, it's just huge > and convoluted complications for no real gain. > +1
Bug#1055206: ITP: asahi-fwextract -- Asahi Linux firmware extractor
Package: wnpp Severity: wishlist Owner: Tobias Heider X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: asahi-fwextract Version : 0.6.12 Upstream Authors: URL : * License : MIT Description : Asahi Linux firmware extractor Scripts to extract firmware blobs from an EFI partition set up by the Asahi Linux installer. I am planning to maintain this as part of the bananas team.
Bug#1055198: ITP: lzfse -- LZFSE Compression library
Package: wnpp Severity: wishlist Owner: Tobias Heider X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: lzfse Version : 1.0 Upstream Authors: URL : https://github.com/lzfse/lzfse * License : BSD-3-Clause Description : LZFSE Compression library LZFSE is a Lempel-Ziv style data compression algorithm using Finite State Entropy coding. It targets similar compression rates at higher compression and decompression speed compared to deflate using zlib. I plan to maintain this as part of the bananas team.
Bug#1050810: ITP: asahi-scripts -- Asahi Linux maintenance scripts
Package: wnpp Severity: wishlist Owner: Tobias Heider X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: asahi-scripts Version : 20230821 Upstream Authors: The Asahi Linux project URL : https://github.com/AsahiLinux/asahi-scripts * License : MIT Description : Asahi Linux maintenance scripts This package contains miscellaneous admin scripts from the Asahi Linux reference distro. Package will be maintained within the Debian Bananas Apple M1 team.
Bug#1043433: ITP: alsa-ucm-conf-asahi -- ALSA Use Case Manager configuration (and topologies) for Apple silicon devices
Package: wnpp Severity: wishlist Owner: Tobias Heider X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: alsa-ucm-conf-asahi Version : 1 URL : https://github.com/AsahiLinux/alsa-ucm-conf-asahi * License : BSD-3-Clause Description : ALSA Use Case Manager configuration (and topologies) for Apple silicon devices This package contains so-called ALSA UCM configuration describing internal sound peripherals on Apple hardware. This is to overlay the parent alsa-ucm-conf package at /usr/share/alsa. . ALSA is the Advanced Linux Sound Architecture. This makes alsa work properly on apple silicon. I intend to maintain this as part of the debian-banans team.
Bug#1042471: ITP: u-boot-asahi -- u-boot bootloader for Apple silicon systems
Package: wnpp Severity: wishlist Owner: Tobias Heider X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: u-boot-asahi Version : 2023.04-2 Upstream Authors: Mark Kettenis URL : https://github.com/AsahiLinux/u-boot * License : GPL-2 Description : A u-boot bootloader for Apple silicon systems Das U-Boot is a cross platform bootloader for embedded systems, used as the default boot loader by several board vendors. It is intended to be easy to port and to debug, and runs on many supported architectures, including PPC, ARM, MIPS, x86, m68k, NIOS, and Microblaze. u-boot is used as a second stage bootloader for Linux on M1/M2 Apple macs. This will be maintained by the Debian Bananas team.
Bug#1042410: ITP: m1n1 -- Bootloader for Apple Silicon
Package: wnpp Severity: wishlist Owner: Tobias Heider X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: m1n1 Version : 1.3.0 Upstream Contact: Hector Martin * URL : https://github.com/AsahiLinux/m1n1 * License : MIT Programming Lang: C Description : Bootloader for Apple Silicon m1n1 is the bootloader developed by the Asahi Linux project to bridge the Apple (XNU) boot ecosystem to the Linux boot ecosystem. There are multiple Debian based community images for Linux on Apple Silicon based on the work of the Asahi Linux project, each currently shipping their own version of this package in a private archive: https://github.com/AsahiLinux/docs/wiki/SW%3AAlternative-Distros I am hoping to start getting some of the shared infrastructure and dependencies into the official Debian archive to have a central point for collaboration. In the long term we hopefully get to a point where regular Debian ships everything needed to run. For now this will be maintained by myself but I am always looking for collaborators.
Bug#1031029: ITP: got -- a version control system which prioritizes ease of use and simplicity
Package: wnpp Severity: wishlist Owner: Tobias Heider X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: got Version : 0.83 Upstream Author : gameoftr...@openbsd.org * URL : https://gameoftrees.org/ * License : ISC Programming Lang: C Description : A VCS which prioritizes ease of use and simplicity over flexibility Game of Trees (Got) is a version control system which prioritizes ease of use and simplicity over flexibility. Got uses Git repositories to store versioned data. Git can be used for any functionality which has not yet been implemented in Got. It will always remain possible to work with both Got and Git on the same repository.
