[Help] Someone’s requested that two of my AUR packages be deleted as they’re ARM-specific

I’ve just received email notifications that say that an AUR user has requested that 2 of my packages by deleted for the following reason:

“ARM specific. Can’t be used on Arch Linux.”

A further email notification I have says that’s he’s already deleted zotero-arm-bin, so he may even be a trusted user.

Is this a legitimate reason for deletion? Is there anything I can do?

Edit: they are in fact a trusted user.

Isn’t arm unofficially available on Arm devices?

Sounds strange to me - there are packages in the main repos (community for example) that are ARm specific (arm bare metal…).

Were they not clearly noted as ARM only? Is there an ARM-AUR setup somewhere?

I just emailed the guy who filed the deletion request & received this response:

Apologies, I can’t type much. I’m on a camping holiday.

Are these PKGBUILDs that duplicate packages already in the Arch repos? If so then they shouldn’t be in the AUR.

If there’s a build problem in Arch Linux ARM and that’s why they’re not available in the ALARM repos then that’s where the effort should be spent.

I’ve found borg-bin and borg-arm-bin and I don’t understand why those are in the AUR given they are in the repos, https://archlinux.org/packages/community/x86_64/borg/ and https://archlinuxarm.org/packages/aarch64/borg

Are you sure those are arm packages? Aren’t they X86_64 packages used in ARM development?

Not having read the code, so no - not sure. Do you know if they have an alternate AUR for ARM? Or does one search for a repo that covers it? (booming echoes of PPA)…

My packages are:

  • simplenote-electron-arm-bin
  • vivaldi-arm-bin

Simplenote isn’t in the Arch repos. Vivaldi kind of is & kind of isn’t. It is in the x86_64 repo, but not in the ARM repos. The same was true for zotero-arm-bin (not mine, but one I use), which was also deleted by the same trusted user.

1 Like

To my knowledge, no there is not an alternate AUR for ARM.

Some of the AUR submiters are very accommodating, such as jguer with his yay package.
He already has entries in his PKGBUILD to accommodate ARM use, namely

arch=('i686' 'pentium4' 'x86_64' 'arm' 'armv7h' 'armv6h' 'aarch64')

That pretty much covers everything.

In the case of polybar, the submitter only lists the following as architectures

arch=("i686" "x86_64")

So I have to download his PKGBUILD and edit it to include aarch64 and armv7h and since this is architecture specific, I have to do a makepkg on two separate machines to get aarch64 AND armv7h versions to put in the EndeavourOS arm repos.

So I then emailed the maintainer and very politely told him I had already tested the PKGBUILDS for both aarch64 and armv7h and would it be possible to include these architectures in his AUR PKGBUILD. The maintainer never even bothered to reply to my E-mail much less make the inclusion.

So the submiters and maintainers for the AUR all have different attitudes about their PKBUILDS. Some are very accommodating and some are the extreme opposite.

What I generally do if I am interested in a package for ARM that exists in the AUR is to check if they support ARM architectures in the PKGBUILD. If not, I download the PKGBUILD and edit it to include ARM, then simply try to do a makepkg. So far, this has worked on everything I have tried except “brscan4”, but this involved a binary provided by Brother which was of course in x86_64. I didn’t find where Brother offered the source code, so I just forgot about it.



It looks like all the arm packages in the AUR have deletion requests or have been deleted already.

Mine have deletion requests, but have not yet been deleted. Do you know if there’s anything I can do?

The vivaldi package clearly violates the rules so I can’t imagine you can do anything about that.

As for the other one, I am not sure.

I believe deletion requests are discussed on the mailing list for aur-requests but I am not an expert.

Does it have an x86_64 version? If so, the PKGBUILD can be made applicable for Arch proper as simplenote-electron-bin (with the additional architectures added as already mentioned).

Actually, there’s already a simplenote-electron-bin package, it needs to have aarch64 adding to its arch() array. Did you try asking the maintainer to make this minor change before packaging up your own version? Also, why are they using the deb rather than the .tar.gz? :face_with_raised_eyebrow:

If there’s an advantage to using the AppImage as a source rather than the Deb then (again) you might discuss that with the current maintainer?

It might be nice to try and fix the build failures in ALARM here. Not sure what is broken, or how much effort it would be, but that would be the better approach.

:point_up: This. You can discuss the deletions on the mailing list prior to someone taking action. You might have some luck on the #archlinux-aur IRC channel too, depending on which TUs/devs are around.

It’s in the AUR. I use it.

This is slightly complicated. There is an x86_64 version of Simplenote on the AUR (here). Looks like you’ve already made a comment :wink:. If you look at the PKGBUILD there are three things of note:

  • The first is that this is a *-bin package, so it makes use of pre-built binaries.
  • The second is that this is a multi-arch package.
  • The third is that aarch64 is not one of the supported architectures.

A while back, I asked Automattic on GitHub whether they would be able to provide aarch64 *.deb packages. Someone kindly provided a patch, and they started to make them. I then asked the AUR maintainer if he wouldn’t mind adapting his AUR PKGBUILD to support ARM, and he kindly agreed. A few Simplenote releases down the line someone at Automattic notified me that they would have to drop the aarch64 *.deb package as they were getting build failures. As a result, the AUR package maintainer dropped support for aarch64, but left in the other architectures. I noticed that Automattic were still releasing aarch64 AppImages, so I decided to make a new PKGBUILD on the AUR that used these as a starting point to build Simplenote for ARM devices. I didn’t add support for non-ARM architectures, as I didn’t want to tread on the other AUR maintainer’s toes too much.

I believe there are. I tend to prefer them to *.deb’s for PKGBUILDs where everything just gets dumped in /opt/$pkgname.

I tried, but got stonewalled:

Strit kindly added the PKGBUILD to the Manjaro ARM repos, but as the above shows, I had no success with Arch Linux ARM. All that resulted from my Arch Linux ARM forum comments was that someone removed Vivaldi from the Arch Linux ARM repos.

1 Like

We should make EOSUR (EndeavourOS User Repository). Just like the AUR, but our rules for package submission.

1 Like

Yes. The upstream release tag has a number of pre-built binaries in different archive formats (deb, AppImage, tar.gz).


Within the current PKGBUILD, correct. However, there is no reason for this as an aarch64 binary is available within the upstream releases.

Technically, you suggested repackaging the upstream binary rather than actually fixing any build failures. :wink:

I agree. Only the current AUR maintainer of the multi-arch Simplenote package seem to like using the *.deb binaries as a starting point.

In the case of Vivaldi, I told them why the current PKGBUILD wouldn’t/didn’t work (it was using an x86_64 *.rpm binary as the source), mentioned that there was a working PKGBUILD for ARM architectures on the AUR, and gave them a link for it. There wouldn’t have been a simple one line fix for their broken PKGBUILD as (I think) the only ARM binaries Vivaldi release(d) are *.deb’s.

1 Like

Interesting - the current Arch PKGBUILD uses the upstream RPM instead of building from source. That’s unusual.

In which case, the correct approach would be to PR against https://github.com/archlinuxarm/PKGBUILDs and commit a PKGBUILD that “fixes” the Arch PKGBUILD to use the Arm debs instead (as in your AUR package).

1 Like

Will have a go at this when I get a few spare moments. I’ve started to make a new PKGBUILD for Vivaldi.

I’ve made a new PKGBUILD for Simplenote, which is just on my GitLab repo for now:

Do EndeavourOS have a community ARM repo? if so, is it possible to contribute to it?

1 Like