Arch Linux User Repository

The upstream URL has changed to https://alpineapp.email/ - see its repo. The one currently in the PKGBUILD is dead.

Would it be possible to add --with-passfile=.alpine.passfile as in alpine PKGBUILD? Thanks!

could you please add armv7l to arch field? compiles and runs find on raspberry pi. thank you, j

Hi guys & gals!

I resurrected alpine as a separate package. The upstream seems to be making releases again and I see no reason for not having a stable package, in addition to this one.

@yar, I can add you as a comaintainer, if you wish.

Just to let you know:

As I am evaluating Manjaro Arm presently, I tried to build alpine-git for the aarch64 architecture (Raspberry Pi 4 running Manjaro Arm aarch64). Simply adding 'aarch64' to the PKGBUILD line 8 to read: arch=('i686' 'x86_64' 'aarch64') is enough. It compiles fine and runs as expected.

I just downloaded Alpine after having struggled with Mutt to no avail. I am running two headless Arch Linux servers where I had the need to implement command line based Email Clients.

After some confusion (the usual cloud provided desinformation) I got Alpine from here (the sourceforge fork doesn't compile for me) and I got gmail, mail.ru, t-online to behave properly and with all features. To get passfile support I had to change --without-passfile to --with-passfile=<.mypassfile> in the PKGBUILD. As the passfile is encrypted I don't see a major Hazard here.

For gmail go to the setup menu (press M S C) edit

Personal Name = <your full name>;

User Domain = gmail.com;

SMTP Server (for sending) = smtp.gmail.com:587/TLS/user=<user>@gmail.com;

Inbox Path = {pop.gmail.com:995/user=<user>@gmail.com/POP3/SSL}

You will have to adjust your gmail account to allow less secure devices to connect ( after trying to connect gmail will send you a message pointing you to the setting ). If you want to be extremely secure you can subscribe to oauth2 by establishing a development account with google, dropping your anonymity (or what is left of it) completely.

Some Servers don't like the attitude of Alpine to not use the Email credentials for the From: entry, but rather the machine account and domain. This can be avoided by setting the appropriate From: options in the setup menu.

Thanks to all of you providing this nice and powerfull tool to the rest of us. btw reportedly Linus Torvalds is using it as well as Cern and some Universities.

Take care.

P.S. For some servers you need to manually import their cert, just google for ssl certificate import. Alpine has a menu option to import the file once you have it.

I didn't even realize alpine had been merged with this! Nobody told me! https://lists.archlinux.org/pipermail/aur-requests/2019-June/032160.html

"does it really make a lot of sense for someone to maintain a separate copy" <-- Yes, yes it does.

Manually editing PKGBUILDs is fun and all, but it's not reasonable to expect everybody to do that on their own. IMHO if the process is not part of a shared and automated system, it's broken. That is why I made this package in the first place. I don't want weird hacky bullshit installed on my boxes! I want them to come from a clear, well-documented origin!

Maintaining this package is basically a future-proofed, machine-readable version of your comment complaining about the package.

the difference between the latest release and the tip of the master branch is negligible most of the time

@tirsek I haven’t dived deep into the source code, but according to the log there was 61 commits in 2019, and 30 in 2020. This package is not really “tip of the master branch” anyway.

In addition, I believe only stable package can possibly go into community repository.

I know that my comment sounds like a cry baby since every Arch Linux user should learn building their own PKGBUILD, but if I end up going that route I would rather go one step further making it an AUR package.

@FranklinYu: As far as I know, there used to be an alpine package (https://web.archive.org/web/20171019223358/http://aur.archlinux.org/packages/alpine/), but it has since been deleted. I believe I saw some comment somewhere about it being merged with the -git package instead.

My two cents, but forgive me if I'm overstepping here:

For a piece of software like alpine, which is more or less feature complete, and doesn't receive any significant new features, but rather just an occasional bugfixes, the difference between the latest release and the tip of the master branch is negligible most of the time, so does it really make a lot of sense for someone to maintain a separate copy?

If you wish to build a specific release rather than the latest bleeding edge, perhaps you could modify your local PKGBUILD file to point to a specific release version tag? Simply replace source=("git+http://repo.or.cz/${gitname}.git") with source=("git+http://repo.or.cz/${gitname}.git#tag=v2.22") before running makepkg, and you should end up with a build of release 2.22 instead.