Package Details: libmonero-wallet 0.11.1.0-3

Git Clone URL: https://aur.archlinux.org/monero.git (read-only)
Package Base: monero
Description: Monero: the secure, private, untraceable currency - release version (includes daemon, wallet and miner)
Upstream URL: https://getmonero.org/
Licenses: custom:Cryptonote
Conflicts: bitmonero-git, libmonero-wallet-git
Provides: libmonero-wallet, monero
Submitter: anonimal
Maintainer: anonimal
Last Packager: anonimal
Votes: 43
Popularity: 11.834843
First Submitted: 2016-09-21 06:24
Last Updated: 2017-11-08 00:53

Latest Comments

anonimal commented on 2017-11-08 00:00

Update: @nofxx monero-wallet-qt is pulling from this package so I will have to go with option 1 instead.

anonimal commented on 2017-11-07 23:23

@nofxx https://github.com/monero-project/monero/blob/master/src/wallet/CMakeLists.txt#L92-L127

The disabling of RPC with building GUI deps was apparently an old hack when LTO broke linking. The if-clause in the wallet's CMake recipe for disabling RPC is deprecated now and should be removed in future releases.

Our usage of BUILD_GUI_DEPS is a remanent from when the AUR's monero-core package pulled from this package. Now that the monero-core AUR package has been replaced with monero-gui-bin, I don't personally see a reason to keep the BUILD_GUI_DEPS build option since archers are most likely using cli only and, if they want the GUI, they'll use monero-gui-bin or clone/build the GUI themselves.

Two options:

1) provide a .patch for the wallet's CMake recipe until the next release (which will implement the patch)
2) disable the build option since it's no longer needed

I'm leaning toward option 2 and will proceed with removing BUILD_GUI_DEPS. If there are tons of complaints, we can revert and go with option 1. With either option, the bottom-line will be that monero-wallet-rpc will be available in this package.

nofxx commented on 2017-11-07 05:20

`monero-wallet-rpc` isn't being built, any idea?
On 0.11.x> rpc was split from `monero-wallet-cli`
Thanks!

anonimal commented on 2017-10-30 13:32

spirtbrat: ec2b529b237b5823ff7443ad43ef510196004d2f has been pushed and reintroduces the working service file used in v0.11.0.0. See git-log for details.

anonimal commented on 2017-10-30 13:15

Hi spirtbrat,

Monero had always used one branch (master) for v0.10.0 series. Only in v0.11.0 are we now seeing more than one branch again. The commit you referenced should've been merged into the v0.11.0 series before release - and I had been almost certain they made the merge in v0.11.1.0 (also see the TODO in git log).

I'll make the appropriate changes, thank you.

spirtbrat commented on 2017-10-28 08:17

Hello,

The systemd unit file in v.0.11.1.0 does not work, as it tells the
daemon to create its PID file in /var/run, which is owned by root.

This commit:

https://github.com/monero-project/monero/commit/4c58b7edb862a96623651d0387f150417ada92ad

tells systemd to create a directory in /run for monerod.service with the
correct ownership and that fixes the problem.
But it isn't in a release yet.

Another solution is to run monerod in foreground mode (not daemon) with
--non-interactive and drop the whole PID file business. Systemd already
tracks whether the service is running and additional side mechanism for
the same thing (the PID file) is not necessary.

Like this:


[Unit]
Description=Monero Full Node
After=network.target

[Service]
User=monero
Group=monero
WorkingDirectory=~

ExecStart=/usr/bin/monerod --config-file /etc/monerod.conf --non-interactive

[Install]
WantedBy=multi-user.target

anonimal commented on 2017-09-26 06:21

@redfish

1. You really should lay of the name calling; it only makes you look childish. Accusing me of being "emotional" and "snarky" is both a baseless accusation and unwarranted opinion. I had merely asked a question.

2. More importantly, the "point" was obviously made but upstream was only merged 15 hours ago - so there was no possibility of using an upstream service file that had not yet been approved. And even without this very *minor* service-file patch, nothing is broken, so ultimately there is no real reason to justify your attack.

3. The conf is still identical. Updating the install source directory is not unwarranted though but doing so *now* is - because we are not pulling from master but from a tagged release. In the next release, the PKGBUILD should install from source directory.

redfish commented on 2017-09-24 15:38

@majewsky: running fine in foreground mode *via* systemd? IIRC, that did not work for me, because without --detach, monerod tried to open console and failed. The current way (forking with PIDfile) does work, and is the right way, although I think there is a race between grandchild process creating the pid file and systemd reading it (child needs to wait for child before exiting).

redfish commented on 2017-09-24 15:35

@anonimal: The point is that the package should not maintain a forked .service and .conf, not that the package is not in sync with upstream. The package should use as much of upstream as possible, so please remove the .conf and .service from here and in package() install those files from upstream.

No need to get emotional. Read what RuntimeDirectory= does, before getting snarky. https://github.com/radfish/monero/blob/df322ddde5b4550194317c1ea2837f70c8c2f034/utils/systemd/monerod.service#L9
Yes, I did test (on Arch).

majewsky commented on 2017-09-16 17:06

Why does the service file use Type=forking? monerod is running fine on my box without the --pidfile and --detach switches, without PIDFile= and with Type=simple.

All comments