Bug#698988: 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 >
Bug#698988: 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-de...@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
Bug#1055206: ITP: asahi-fwextract -- Asahi Linux firmware extractor
Package: wnpp Severity: wishlist Owner: Tobias Heider X-Debbugs-Cc: debian-de...@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-de...@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-de...@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-de...@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
Hi Andreas, On Fri, Aug 04, 2023 at 01:07:32PM +0200, Andreas Henriksson wrote: > Hello Tobias Heider, > > While I'm as entusiastic as anyone else here, I have to ask a few > questions that might be a bit skeptical below... > > On Fri, Jul 28, 2023 at 10:00:35PM +0200, Tobias Heider wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Tobias Heider > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: u-boot-asahi > > Version : 2023.04-2 > > Upstream Authors: Mark Kettenis > > URL : https://github.com/AsahiLinux/u-boot > > This is a development repository and things are sent upstream > to u-boot (mainline). The upstreaming effort is driven by the person you > listed as author (while actual authors is usually someone else AFAIK). I don't quite agree with calling it just a development repository. It is the main repository for the Asahi Linux fork where releases are tagged which are then packaged in their official ALARM (and soon Fedora) distributions and also used by the unofficial ports listed here: https://github.com/AsahiLinux/docs/wiki/SW%3AAlternative-Distros You are right that there is work to upstream those changes, but the diff is not small and I don't think the upstream support is at a point where it is actually usable. I wouldn't mind updating the Upstream Authors field if you think there is a better name to put there. > > Is there any other u-boot development forks being packaged in Debian and > how viable do you think this is? Is the plan to eventually provide a > migration to u-boot-asahi binary package provided by src:u-boot or how > do you see the future path of this? I am not aware of other forks being packaged at the moment. I think it is useful because there are many users such as everyone currently using Glanzmann's repo, but also those running Ubuntu or Deepin. Ideally we'll be able to migrate to mainline u-boot at some point but I don't see that happening too soon. > > Is this targeting Trixie or Experimental? Trixie, because that way it will be available for users of the Debian based Asahi ports at some point. Installing the packaged binaries in the boot path requires manual intervention at the moment so the danger of breakage pretty low. > > Is there any particular reason you're targeting u-boot? Are you planning > on working on any installer? Also planning on packaging linux-asahi > development repo? > Repeating what I said above, I think there are plenty of users for m1n1 and u-boot even if not everything needed to install a fully working Debian system is available from the official archive yet. Both of them are relatively straightforward to package, have tagged releases and are useful even without having a working kernel. Also: we need to start somewhere. I don't currenly have a good answer for the linux-asahi kernel. Ultimately I would of course like to have a working kernel available. > > Do you have contact with upstream about this? They have been very vocal > about distros shipping things that causes additional problems for (users > and then in turn for) the Asahi project in the past. > (Also atleast some Asahi team members are already not publishing their > development git branches because of fear of people dumping them into > distros.) I am a maintainer one of one of the community ports where we already ship a packaged version of the asahi u-boot and so far that has not been a problem. The problems you mention were caused by distributions packaging and publishing versions of the upstream software that was neither tagged nor released for the official Asahi distribution and had known bugs. I don't think there is a problem here if we stick to upstream releases and act responsibly, but I wouldn't mind asking for an official blessing from the upstream maintainers if you prefer that. > > How does this effort compare against Thomas Glanzmann effort[1]? > Do you plan to provide a migration path (and why would users migrate > over to debian-bananas effort instead of Glansmanns effort)? > > (IMHO while Glanzmanns effort is not my preferable packaging style, it > provides a very good stop gap solution until everything has been > mainlined into u-boot, linux, mesa which in turn then and only then > makes it ready for proper Debian packaging. Apart from mainlining work > which hopefully will happen without any assintance from Debian, the > biggest challange is probably to provide a sane installer solution > acceptable for Debian. Is this a task the bananas team intends to take > on?) I have discussed my plan to package m1n1 and u-boot with Thomas Glanzmann before I sent this mail to make sure it doesn't interfere with his work or break existing installations. The idea
Bug#1042471: ITP: u-boot-asahi -- u-boot bootloader for Apple silicon systems
Package: wnpp Severity: wishlist Owner: Tobias Heider X-Debbugs-Cc: debian-de...@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
Hi, Just joined the IRC channel if that is on oftc. On Thu, Jul 27, 2023 at 10:32:58PM +0200, Gürkan Myczko wrote: > Hi Tobias > > I'm interested in joining, had a look at it some time ago: > http://sid.ethz.ch/debian/m1n1/ my current WIP lives here: https://salsa.debian.org/tobhe/m1n1/ > > Are you on IRC? #debian-apple ? Nope, I wasn't aware of that. > What will you call the team? Debian-Think-Different or Debian-Apple? > > Best,
Bug#1042410: ITP: m1n1 -- Bootloader for Apple Silicon
Package: wnpp Severity: wishlist Owner: Tobias Heider X-Debbugs-Cc: debian-de...@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-de...@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.
Bug#1016918: ITP: tcpbench -- TCP/UDP benchmarking and measurement tool
Package: wnpp Severity: wishlist Owner: Tobias Heider X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: tcpbench Version : 1.02 Upstream Author : Alexander Bluhm * URL : https://github.com/bluhm/tcpbench-portable * License : ISC Programming Lang: C Description : TCP/UDP benchmarking and measurement tool tcpbench is a small tool that performs throughput benchmarking for TCP or UDP. It runs as a client/server pair. Once connected, the client will send TCP or UDP traffic as fast as possible to the server. Both the client and server will periodically compute and display throughput statistics I plan to maintain the package myself and would appreciate a sponsor.
Bug#1008683: ITP: opencu -- Serial terminal emulator
Package: wnpp Severity: wishlist Owner: Tobias Heider X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: opencu Version : 3 Upstream Author : OpenBSD project * URL : https://github.com/tobhe/opencu * License : ISC Programming Lang: C Description : Serial terminal emulator ported from OpenBSD cu(1) cu is used to connect to another system over a serial link. In the era before modern networks, it was typically used to connect to a modem in order to dial in to a remote host. It is now frequently used for tasks such as attaching to the serial console of another machine for administrative or debugging purposes. I am planning to do the maintenance myself and would appreciate a sponsorship.
