Ran pacman -Rcns, removed ~/.config/Code and ~/.vscode, then did as you said above before re-running makepkg -srci.
I’m guessing pacman -Rcns leaves behind a sym-link from before because I got this when I initially re-ran makepkg -srci on the old code:
:: Processing package changes...
(1/1) installing code [###########################################################################] 100%
ln: failed to create symbolic link '/usr/bin/code': File exists
error: command failed to execute correctly
Tried repeating the procedure, but got the same error. Otherwise, the programme appears to still install and run correctly.
The weird thing is that I’ve looked in /usr/bin/ before and after installing the package and there is no symlink or file called code in there.
EDIT: Ignore that last bit. I misread the terminal output. Didn’t realise I was looking at one of the subdirectories of /usr/bin. Will manually remove the symlinks and repeat the install-uninstall process.
Probably because it was installed by the last package. Did you uninstall it first? I have seen that when the link is obsolete. I can see if I can put a rm in the .install file and see if it will do anything. The last package was linking to a different file and I changed it to what the .deb had in their post install.
Yup… just checked. Uninstalled the package then removed the symlink. Then reinstalled and uninstalled the package again. The symlink gets left behind after uninstalling.
When opening a few scripts to test code I noticed that julia and julia-docs weren’t available in the Arch/Manjaro ARM repos (although they are in the x86_64 repos). This is possibly a bit niche, but I thought I might put it out there and see whether there’s any interest in these. I just tried the build instructions present on the julia GitHub repo and was able to build a working version of julia:
git clone git://github.com/JuliaLang/julia.git
cd julia
git checkout v1.5.0
make
Takes about an hour or so to build on the Pinebook Pro if you don’t set the -j flag.
Binary releases are also available at the Julia website Download page.
I’m currently trying to modify the PKGBUILD from the Arch x86_64 package to see if that will also build, as they have some cblas optimisations and such.
EDIT: There’s a julia-aarch64-git AUR package that seems to have done a better job than I could ever do. However, I get a build failure when trying to install it via yay.
Is there a chance to add micro to Manjaro ? I think I remember it was available for some time but in the moment it is not.
I think it is a very useful and user friendly terminal editor for those who just got used to CTRL-X/C/V/S/…
It can be build from AUR but you always have to install the whole go dev environment.
There is a aarch64 binary on the github page.
Oh, great find. That is new and it works. The package maintainer has a lightly concerning view about alternative architectures in AUR, but on the bright side he did modify the package, so Hurray
A great editor for everyone who looks for an alternative to nano.
Something I use quite often is cryptmount, for mounting encrypted filesystems. I’m not sure why this isn’t in the core repos for Arch/Manjaro, as it is for Debian/Ubuntu. There is an AUR package, but this wouldn’t install on aarch64 architecture. Today, I finally got fed up and had a go at trying to fix it. Managed to get it to build. Tested it and it works on my existing encrypted filesystems. The problem was that the script the package contained wasn’t able to automatically detect aarch64 architecture, so I had to manually set it as a configure parameter. Would it be possible to add this package to the Manjaro ARM repos?
Have you tried just adding aarch64 to the arch=() array before building it?
I can’t see anything in its PKGBUILD that would keep it from building on aarch64.
PS: Just tested this, and you are right. It can’t guess arm architectures. Autotools suck at this.
Yup. I could probably improve the PKGBUILD generally by adding a simple $CARCH detection code chunk, similar to the one present in the code-git AUR PKGUILD. Might be best to entirely sidestep the package’s means to auto-detect hardware.
Something like this:
# Maintainer: Benjamin Feakins <feakster at poster dot eu>
# Contributor: Mike Sampson <mike at sambodata dot com>
# Contributor: Andrea Benazzo <andy at qitty dot net>
# Modified PKGBUILD from https://aur.archlinux.org/packages/cryptmount/
pkgname=cryptmount-arm
pkgver=5.3.2
_pkgver=5.3
pkgrel=1
pkgdesc="Utility which allows an ordinary user to mount an encrypted file system"
arch=('i686' 'x86_64' 'arm' 'armv6h' 'armv7h' 'aarch64')
url="http://cryptmount.sourceforge.net/"
license=('GPL')
provides=(cryptmount)
depends=(cryptsetup device-mapper glibc libgcrypt systemd util-linux)
makedepends=(gcc)
source=($provides-$pkgver.tar.gz::http://downloads.sourceforge.net/project/cryptmount/cryptmount/cryptmount-$_pkgver/cryptmount-$pkgver.tar.gz)
backup=('etc/cryptmount/cmtab')
sha512sums=('972c7fefadb86bb82cdeb96b185f45bec08ac07d39474a4c7e2a473bc2453624ffcc387b6836a02260dcd0d1176a5a743c45bdf3d7e78d2f519f02a48c62a6b8')
prepare() {
cd "$srcdir/$provides-$pkgver"
case "$CARCH" in
"x86_64")
_arch=x86_64-unknown-linux-gnu
;;
"arm")
_arch=arm-unknown-linux-gnu
;;
"armv6h")
_arch=arm-unknown-linux-gnu
;;
"armv7h")
_arch=arm-unknown-linux-gnu
;;
"aarch64")
_arch=arm-unknown-linux-gnu
;;
*)
_arch=$(./config.guess)
;;
esac
echo "Build: $_arch"
}
build() {
cd "$srcdir/$provides-$pkgver"
./configure --build=$_arch --prefix=/usr --sbindir=/usr/bin --sysconfdir=/etc --with-systemd=yes
make
}
package() {
cd "$srcdir/$provides-$pkgver"
make DESTDIR="$pkgdir" install
}
