Package Details: monero

Git Clone URL: (read-only)
Package Base: monero
Description: Monero: the secure, private, untraceable currency - release version (includes daemon, wallet and miner)
Upstream URL:
Licenses: custom:Cryptonote
Conflicts: bitmonero-git, libmonero-wallet-git
Provides: libmonero-wallet, monero
Submitter: anonimal
Maintainer: anonimal
Last Packager: anonimal
Votes: 84
Popularity: 1.34
First Submitted: 2016-09-21 06:24
Last Updated: 2019-11-21 03:41

Latest Comments

1 2 3 4 5 6 ... Next › Last »

IncredibleLaser commented on 2019-11-22 15:34

It was, but it was "only" the binary for the CLI wallet, this package builds the CLI wallet from source and was unaffected, the source code is hosted on and retrieved from GitHub.

Perdu commented on 2019-11-20 16:21

Official website has been compromised (distributing modified binary) 2 days ago, according to hackernews.

limaxray commented on 2019-11-06 20:24

No worries, it happens, thanks for fixing it so quickly!

anonimal commented on 2019-11-06 06:37

Yeah, that was dumb. I had gotten busy with post-release so hacked that out without thinking twice. Thanks for the reminder.

limaxray commented on 2019-11-06 03:39

monero.sysusers and monero.tmpfiles should be added to the source array so they're copied to srcdir where they should be installed from directly. The relative "${srcdir}/../" references are invalid if the package is built outside of the PKGBUILD directory so shouldn't be used.

anonimal commented on 2019-11-05 01:45

Bumped + removed install file and replaced with sysusers and tmpfiles

rpodgorny commented on 2019-11-03 21:01

just fyi - be sure to use systemd sysusers for that (man sysusers.d)

fl4co commented on 2019-11-03 19:05

Hi, the systemd service installed tries to start the daemon with monero:monero ownership, but there is not a .install file that creates user and group.

EDIT: I confused this package with monero-bin. Ignore this comment.

anonimal commented on 2019-10-14 21:16

Yes, thank you James. I'm not enforcing pkgrel for dependency upgrades because rolling-release boost doesn't always play nice with other projects in development. For example, I've had to downgrade to 1.69 locally for sekreta/kovri because of cmake/boost_filesystem build issues that need to be fixed upstream. This isn't the only case, and, most of the time, it's better to simply rebuild against whatever version a developer is using (remember, sylphio, Arch is developer-friendly).

@sylphio, like he said, give rebuilding of the monero package a try. IIRC, some package managers have the option to do this automatically. For example, yaourt had an option (I say had only because yaourt has been dropped).

jamespharvey20 commented on 2019-10-13 07:20

sylphio, monerod only looks for the boost-libs .so version you originally compiled it against. As with all AUR packages, sometimes when system packages are upgraded, you need to recompile. Recompile this package with the newer boost-libs installed, and it will look for that version. AUR maintainers can bump the pkgrel to indicate this is needed, but often that doesn't happen.