Package Details: pacserve 2021-1

Git Clone URL: https://aur.archlinux.org/pacserve.git (read-only, click to copy)
Package Base: pacserve
Description: Easily share Pacman packages between computers. A replacement for PkgD.
Upstream URL: https://xyne.archlinux.ca/projects/pacserve
Keywords: arch_linux pacman server
Licenses: GPL
Conflicts: pacredir
Submitter: Xyne
Maintainer: Xyne
Last Packager: Xyne
Votes: 103
Popularity: 0.39
First Submitted: 2011-04-17 00:30
Last Updated: 2021-02-11 12:51

Latest Comments

« First ‹ Previous ... 4 5 6 7 8 9 10 11 12 13 Next › Last »

nplatis commented on 2013-05-10 22:33

I updated and pacserve seems to start OK now.

Unfortunately, I receive an error message "Empty reply from server" for every file pacman tries to receive (either the *.db files when updating the databases or the package files when downloading them).

My error log is the following:

Μάι 11 01:30:48 dynamo pacserve[427]: Traceback (most recent call last):
Μάι 11 01:30:48 dynamo pacserve[427]: File "/usr/lib/python3.3/socketserver.py", line 610, in process_request_thread
Μάι 11 01:30:48 dynamo pacserve[427]: self.finish_request(request, client_address)
Μάι 11 01:30:48 dynamo pacserve[427]: File "/usr/lib/python3.3/site-packages/ThreadedHTTPSServer.py", line 206, in finish_request
Μάι 11 01:30:48 dynamo pacserve[427]: http.server.HTTPServer.finish_request(self, request, client_address)
Μάι 11 01:30:48 dynamo pacserve[427]: File "/usr/lib/python3.3/socketserver.py", line 345, in finish_request
Μάι 11 01:30:48 dynamo pacserve[427]: self.RequestHandlerClass(request, client_address, self)
Μάι 11 01:30:48 dynamo pacserve[427]: File "/usr/lib/python3.3/site-packages/ThreadedHTTPSServer.py", line 267, in __init__
Μάι 11 01:30:48 dynamo pacserve[427]: http.server.BaseHTTPRequestHandler.__init__(self, *args, **kwargs)
Μάι 11 01:30:48 dynamo pacserve[427]: File "/usr/lib/python3.3/socketserver.py", line 666, in __init__
Μάι 11 01:30:48 dynamo pacserve[427]: self.handle()
Μάι 11 01:30:48 dynamo pacserve[427]: File "/usr/lib/python3.3/http/server.py", line 400, in handle
Μάι 11 01:30:48 dynamo pacserve[427]: self.handle_one_request()
Μάι 11 01:30:48 dynamo pacserve[427]: File "/usr/lib/python3.3/http/server.py", line 388, in handle_one_request
Μάι 11 01:30:48 dynamo pacserve[427]: method()
Μάι 11 01:30:48 dynamo pacserve[427]: File "/usr/lib/python3.3/site-packages/ThreadedHTTPSServer.py", line 557, in do_GET
Μάι 11 01:30:48 dynamo pacserve[427]: self.do_authenticated_GET()
Μάι 11 01:30:48 dynamo pacserve[427]: File "/usr/lib/python3.3/site-packages/Quickserve.py", line 448, in do_authenticated_GET
Μάι 11 01:30:48 dynamo pacserve[427]: self.do_authenticated_GET_or_HEAD(True)
Μάι 11 01:30:48 dynamo pacserve[427]: File "/usr/lib/python3.3/site-packages/Pacserve.py", line 419, in do_authenticated_GET_or_HEAD
Μάι 11 01:30:48 dynamo pacserve[427]: resolved = self.server.resolve_path(self.url_path)
Μάι 11 01:30:48 dynamo pacserve[427]: File "/usr/lib/python3.3/site-packages/Quickserve.py", line 304, in resolve_path
Μάι 11 01:30:48 dynamo pacserve[427]: if self.options.root:
Μάι 11 01:30:48 dynamo pacserve[427]: AttributeError: 'Namespace' object has no attribute 'root'

Xyne commented on 2013-05-10 21:57

The only error I see is due to the missing dependency. I'm updating the package now so that should be fixed in a few minutes.

I think you see $PACSERVE_ARGS in the output because it is displaying the exact line from the service file in the error. When the service is run, the variable is substituted as intended.

Please update pacserve and python3-threaded_servers and try again.

nplatis commented on 2013-05-10 21:39

Sorry, I am still unable to run pacserve successfully. status gives:

pacserve.service - Pacserve
Loaded: loaded (/usr/lib/systemd/system/pacserve.service; disabled)
Active: activating (auto-restart) (Result: exit-code) since Σαβ 2013-05-11 00:28:59 EEST; 13s ago
Process: 2191 ExecStart=/usr/bin/pacserve $PACSERVE_ARGS (code=exited, status=1/FAILURE)

Μάι 11 00:28:59 dynamo systemd[1]: pacserve.service: main process exited, code=exited, status=1/FAILURE
Μάι 11 00:28:59 dynamo systemd[1]: Unit pacserve.service entered failed state.
Μάι 11 00:29:14 dynamo systemd[1]: pacserve.service holdoff time over, scheduling restart.
Μάι 11 00:29:14 dynamo systemd[1]: Stopping Pacserve...
Μάι 11 00:29:14 dynamo systemd[1]: Starting Pacserve...
Μάι 11 00:29:14 dynamo systemd[1]: Started Pacserve.
Μάι 11 00:29:14 dynamo pacserve[2196]: Traceback (most recent call last):
Μάι 11 00:29:14 dynamo pacserve[2196]: File "/usr/lib/python3.3/runpy.py", line 160, in _run_module_as_main
Μάι 11 00:29:14 dynamo pacserve[2196]: "__main__", fname, loader, pkg_name)
Μάι 11 00:29:14 dynamo pacserve[2196]: File "/usr/lib/python3.3/runpy.py", line 73, in _run_code
Μάι 11 00:29:14 dynamo pacserve[2196]: exec(code, run_globals)
Μάι 11 00:29:14 dynamo pacserve[2196]: File "/usr/lib/python3.3/site-packages/Pacserve.py", line 48, in <module>
Μάι 11 00:29:14 dynamo pacserve[2196]: import pycman
Μάι 11 00:29:14 dynamo pacserve[2196]: ImportError: No module named 'pycman'
Μάι 11 00:29:14 dynamo systemd[1]: pacserve.service: main process exited, code=exited, status=1/FAILURE
Μάι 11 00:29:14 dynamo systemd[1]: Unit pacserve.service entered failed state.

I see two problems, I think:
a) The problem with parsing /etc/pacserve/pacserve.service.conf since $PACSERVE_ARGS does not seem to get substituted by its value
b) The "ImportError: No module named 'pycman'"

Xyne commented on 2013-05-10 20:13

completely rewritten in Python 3
see the project page and help message for changes

(incidentally, the multicast functionality seems to be working very well now)

Xyne commented on 2013-04-27 19:31

@solarwind
Feel free to post actual errors, submit patches or use something else. I wrote pacserve for myself and have only shared it in case others find it useful. I try to fix bugs that others report, but if I do not experience them myself and cannot reproduce them then there is not much that I can do.

What you are suggesting is that I spend my own free time, of which I currently have very little, to learn a new library and use it in pacserve just for you, while the current implementation appears to work for everyone else.

Incidentally, a comment with a rude tone is not a contribution.

solarwind commented on 2013-04-23 06:06

You misunderstand, that is a bug report, contribution, and advice.

rafaelff commented on 2013-04-23 00:49

Well, that escalated quickly... Normally, people provide feedback with with bug reports or feature requests, or even ask for help, with mostly the intent to contribute. You should try that too instead of ranting around, @solarwind.

solarwind commented on 2013-04-22 23:49

Xyne, there's a reason that tested code and libraries like avahi are used. They work. Your multicast implementation fails. It is unable to resolve the own machine's hostname and exits. "The current code" does NOT work.

nplatis commented on 2013-04-05 15:29

[I mentioned the following problem, but the thread is possibly too old.]

pacserve does not start correctly at boot. The last three lines of its status are:

File "/usr/lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
error: [Errno 19] No such device

If I restart pacserve, everything is fine.

Xyne commented on 2013-03-25 18:18

@KerrickStaley
Run "systemctl status pacserve.service" on both systems and check for errors. If there are no errors then look for the messaging "adding: ... to server pool". If you don't see that then try restarting pacserve on each system, one at a time, and recheck the status each time on both systems to see if either detects the other. Each time pacserve starts it should send out a multicast query. After that it should send out multicast queries ever 5 minutes by default (or maybe 10, I don't remember right now).

If it still doesn't work, try manually querying each pacserve server locally and from the other system:

curl http://localhost:15678/search/core/x86_64/foo-1-1.pkg.tar.xz
curl http://10.42.0.1:15678/search/core/x86_64/foo-1-1.pkg.tar.xz
curl http://10.42.0.46:15678/search/core/x86_64/foo-1-1.pkg.tar.xz

It will print a list of the host aliases that it has queried. You should see both servers in the output.

I have had problems with ad-hoc wifi networks before. It may be a forwarding or firewall issue depending on your setup, but I'm grasping at straws here.