Arch Linux User Repository

Hi Invarianz,
Thanks for taking care of the package and the information about how to rename the package (delete and add).
For now I am not planning to rename it. The package has only 3 votes and 1 of those is mine, it is not like lots of people are using this package or looking at it! Also I don't use it much.
Another option would be to change it to track git.
Cheers

Hey @archdub. Thanks for taking over! I changed the name to -git (see the pinned comment) because when looking over the naming scheme in the AUR, it seems to be common to add the -git suffix for packages closely tracking the master branch.

In addition, git is actually used here as the version control system (as far as I know repo.or.cz historically is one of the first git remotes that was ever available). However, I also see your point in changing the name: I had to do the same thing: Create a new package and delete or point to the old one to this.

Feel free to do as you fit, thanks again!

Just checked in a new version of the package, with the first upstream changes since 4 years ago.
There is still an outstanding packaging issue: the name of this package does not comply with the guidelines. Its name ends in "-git" and it is not really a git package as it does not track the upstream git repo. However it seems that to fix this I would need to delete this package and upload another with a different name and that seems at the moment to be too much trouble for too little benefit.

Thanks, Invarianz. I took ownership of it.

I have never pushed a pkgbuild, so I will have to figure out how to do that. In the meantime those wanting to build this package can use what I pasted below.

I checked the upstream repo. There were 20 commits this year, all small. The majority of them are to fix build issues, there is one for documentation, and a small number that fixes things such as variable size. In a nutshell, those that have already a working nvi would benefit little from building the new version. The big advantage of the new version is that it builds on Arch unlike the 2020 version.

Thanks for the comments and all the activity @archdub. I'm not using Archlinux or nvi for some time now and don't plan to come back. I disowned the package. If you actively use it I suggest to adopt the package.

Thanks again for the input!

I spent a bit more time on this package, and found that upstream unexpectedly came back to life after being dead for four years. There was a bunch of commits in August and September of this year. Among them there were fixes for the automake tools, so I managed to successfully build the package.
I am pasting below the modified package.
The name of this package should be changed, it is not really a git package as it does not track git, so unless the package is modified to track git, it is better to remove the "-git" suffix from the package name.

cat PKGBUILD.mine
# Maintainer: Invarianz <invarianztheorem [at] web [dot] de>
# Contributor: cmichi <mich [at] elmueller [dot] net>
#
# This package provides the latest offical, upstream nvi
# with multibyte support enabled.

pkgname=nvi-multibyte-git
pkgdesc="Upstream nvi with enabled multibyte support"
arch=('x86_64')
url="git://repo.or.cz/nvi.git"
license=("BSD")
conflicts=("nvi")

_COMMIT="ec6c4a2d8889319a21893cbaf2cc63d11598fba2"
source=("http://repo.or.cz/nvi.git/snapshot/$_COMMIT.tar.gz")
md5sums=('ab5a87935e8ed970c4c562b624948361')

# the last official release was 1.81.6, but there have been
# commits since then. Timestamp (yyyymmdd) of latest commit is appended.
pkgver=1.81.6_20240912
pkgrel=1
_COMMIT_HASH="${_COMMIT:0:7}"

build(){
cd "$srcdir"/nvi-$_COMMIT_HASH/dist/
./distrib
cd ../build.unix

../dist/configure \
    --prefix="$pkgdir"/usr \
    --program-prefix=n \
    --enable-widechar # for multibyte support

make
}

package(){
cd "$srcdir"/nvi-$_COMMIT_HASH/build.unix

make install

# license
install -Dm644 "$srcdir"/nvi-$_COMMIT_HASH/LICENSE \
        "$pkgdir"/usr/share/licenses/$pkgname/LICENSE
}

This package still does not build. I spent a bit more time on it. The errors actually start with automake, they cascade until there is a fatal error. So to fix this would require looking at the autotools at a minimum, maybe also fix C compatibility issues.

I looked at the nvi package in Debian, which exists in stable, testing and unstable, meaning apparently they have no current plan to retire it. They are building it with 35 patches. So one possibility would be to base this AUR package on the Debian version with its patches.
https://packages.debian.org/sid/nvi

I also tried to build nvi2 following the instructions of randiprit in the comment below:
https://aur.archlinux.org/packages/nvi-multibyte-git#comment-965089

However building also fails:
nvi2/common/key.c: In function ‘v_key_name’:
nvi2/common/key.h:25:29: error: implicit declaration of function ‘wcwidth’ [-Wimplicit-function-declaration]
25 | #define XCHAR_WIDTH(sp, ch) wcwidth(ch)

There is another nvi version in AUR, based on the OpenBSD version without Unicode, but it too does not build:
https://aur.archlinux.org/packages/nvi

To conclude, I don't use any flavour of vi often, so I currently don't feel motivated enough to fix this package. For now my nvi package that I built a while back still works.

This is not building for me, probably due to incompatibility between the old code and the new compiler. I still have the old version that works so it is not an immediate problem for me.

One sample of the errors: ../dist/../cl/extern.h:21:6: error: conflicting types for ‘setupterm’; have ‘void(char , int, int )’ 21 | void setupterm __P((char , int, int )); | ^

@randiprit Yes, that is the email thread I was referring too. I had forgotten about the other reason (besides bugs) for not going to nvi2, namely, licensing issues, BSDs are usually very fussy about licenses. I don't know why Debian is not on nvi2 though.

Anyway, I don't have a strong opinion on this, whatever the maintainer does will be fine with me! :-)

@archdub maybe this is the email you refer to (6 years old): https://misc.openbsd.narkive.com/9NHoQv8L/nvi-and-unicode#post4

I use daily nvi2 without any stability problem, never crashed. The lack of 'expandtab' option in (Open)(n)vi(1) is a no-go for me.

@Invarianz: thank you for the tip.

Be sure that in no case I am trying to denigrate the (Open)(n)vi(1) version or trying discouraging it's use. I was just mentioning the existence of version 2. From now I will stop to pollute comments of this AUR Package.