Package Details: pacserve 2021-4

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.dev/projects/pacserve
Keywords: arch_linux pacman server
Licenses: GPL
Conflicts: pacredir
Submitter: Xyne
Maintainer: Xyne
Last Packager: Xyne
Votes: 110
Popularity: 0.127086
First Submitted: 2011-04-17 00:30 (UTC)
Last Updated: 2022-07-15 22:46 (UTC)

Dependencies (5)

Required by (0)

Sources (2)

Latest Comments

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

untitaker commented on 2013-05-25 15:31 (UTC)

@Xyne: XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u

Xyne commented on 2013-05-25 02:44 (UTC)

@untitaker Can you post the exact XferCommand? I want to understand exactly why it didn't work. Thanks.

untitaker commented on 2013-05-22 11:07 (UTC)

Nevermind, the cause was a custom XferCommand (wget with verbose settings), which used to work with the Python 2 pacserve. Removing it fixed the problem.

Xyne commented on 2013-05-21 23:12 (UTC)

@untitaker Are you running the latest version of pacserve and python3-threaded_servers? Make sure that you are before proceeding. The only time HTML is returned is if there is an HTTP error, but pacman detects that and should not save it in the database. The entry in /etc/pacman.d/pacserve is correct. Note that "$repo" and "$arch" are replaced by Pacman automatically so if you are testing this with e.g. curl or wget then you need to replace those values yourself. Run the following command (after replacing the architecture if necessary) then post the pacserve.service output from journalctl if the problem persists: curl -Lv 'http://127.0.0.1:15678/pkg/?repo=core&arch=x86_64&file=/core.db' >core.db Also post the HTML that is saved as the database. If you encounter the problem with a different database then update the command above as necessary with the repo name.

untitaker commented on 2013-05-19 17:18 (UTC)

When pacman tries to fetch a db, it gets the directory listing back, not a redirect to a mirror. This seems like a missing change in /etc/pacman.d/pacserve, which contains currently Server = http://localhost:15678/pkg/?repo=$repo&arch=$arch&file=

Xyne commented on 2013-05-14 01:10 (UTC)

p.s @nplatis Please use a service such as pastebin.com to post large excerpts of code or output in the future.

Xyne commented on 2013-05-14 01:08 (UTC)

All reported errors should be fixed now (redirection bugs, sync database corruption, systemd service errors). To get everything working again, do the following (skip unneeded steps, obviously): 1) systemctl stop pacserve.service 2) systemctl status pacserve.service (note the PID) 3) ps -e python3 (check for matching PIDs ) 4) kill -9 <pid> ... 5) remove pacserve from pacman.conf 6) pacman -Syyu 7) update pacserve and python3-threaded servers 8) systemd start pacserve.service 9) add pacserve back to pacman.conf After that everything should work as before (or even better). Sorry for the inconvenience.

nplatis commented on 2013-05-13 19:51 (UTC)

I try to use pacserve via pacman, by inserting appropriate lines in pacman.conf. Now pacman -Sy gives: :: Synchronizing package databases... core 137.9 KiB 0.00B/s 00:00 [######################] 100% extra 137.9 KiB 0.00B/s 00:00 [######################] 100% community 137.9 KiB 0.00B/s 00:00 [######################] 100% multilib 137.9 KiB 0.00B/s 00:00 [######################] 100% archlinuxfr 137.9 KiB 0.00B/s 00:00 [######################] 100% xyne-x86_64 137.9 KiB 0.00B/s 00:00 [######################] 100% error: failed retrieving file 'xyne-x86_64.db.sig' from localhost:15678 : Maximum file size exceeded xyne-x86_64 is up to date error: database 'xyne-x86_64' is not valid (invalid or corrupted database (PGP signature)) The output is exactly the same even if the databases are up-to-date, or if I run pacman -Syy, which is unexpected since pacserve is not supposed to mess with the .db files but only with the package files. journalctl -xb has the following lines: May 13 22:36:00 dynamo pacserve[1811]: [2013-05-13 22:36:00 EEST] INFO: 127.0.0.1 "GET /pkg/?repo=core&arch=x86_64&file=/core.db HTTP/1.1" 200 - May 13 22:36:00 dynamo pacserve[1811]: [2013-05-13 22:36:00 EEST] INFO: 127.0.0.1 "GET /pkg/?repo=core&arch=x86_64&file=/core.db.sig HTTP/1.1" 200 - May 13 22:36:00 dynamo pacserve[1811]: [2013-05-13 22:36:00 EEST] INFO: 127.0.0.1 "GET /pkg/?repo=extra&arch=x86_64&file=/extra.db HTTP/1.1" 200 - May 13 22:36:00 dynamo pacserve[1811]: [2013-05-13 22:36:00 EEST] INFO: 127.0.0.1 "GET /pkg/?repo=extra&arch=x86_64&file=/extra.db.sig HTTP/1.1" 200 - May 13 22:36:01 dynamo pacserve[1811]: [2013-05-13 22:36:01 EEST] INFO: 127.0.0.1 "GET /pkg/?repo=community&arch=x86_64&file=/community.db HTTP/1.1" 200 - May 13 22:36:01 dynamo pacserve[1811]: [2013-05-13 22:36:01 EEST] INFO: 127.0.0.1 "GET /pkg/?repo=community&arch=x86_64&file=/community.db.sig HTTP/1.1" 200 - May 13 22:36:01 dynamo pacserve[1811]: [2013-05-13 22:36:01 EEST] INFO: 127.0.0.1 "GET /pkg/?repo=multilib&arch=x86_64&file=/multilib.db HTTP/1.1" 200 - May 13 22:36:01 dynamo pacserve[1811]: [2013-05-13 22:36:01 EEST] INFO: 127.0.0.1 "GET /pkg/?repo=multilib&arch=x86_64&file=/multilib.db.sig HTTP/1.1" 200 - May 13 22:36:01 dynamo pacserve[1811]: [2013-05-13 22:36:01 EEST] INFO: 127.0.0.1 "GET /pkg/?repo=archlinuxfr&arch=x86_64&file=/archlinuxfr.db HTTP/1.1" 200 - May 13 22:36:01 dynamo pacserve[1811]: [2013-05-13 22:36:01 EEST] INFO: 127.0.0.1 "GET /pkg/?repo=xyne-x86_64&arch=x86_64&file=/xyne-x86_64.db HTTP/1.1" 200 - May 13 22:36:02 dynamo pacserve[1811]: [2013-05-13 22:36:02 EEST] INFO: 127.0.0.1 "GET /pkg/?repo=xyne-x86_64&arch=x86_64&file=/xyne-x86_64.db.sig HTTP/1.1" 200 - Let me note that by removing the respective lines from pacman.conf and using pacsrv, everything runs fine.

Xyne commented on 2013-05-13 18:41 (UTC)

Sorry, I had updated the path in the pacserve executable but only noticed this morning that I had not uploaded it. It should be fixed now. Expect another update tonight as I'm working on improving the thread management. Until then, if you encounter an error when restarting the systemd service, use "ps -e" to locate the python3 thread and kill it with "kill -9 <pid>". @nplatis I don't really understand the error. Can you post some log output or something to make it clearer? Try with the latest version first to see if I have solved them already.

nplatis commented on 2013-05-13 07:14 (UTC)

The latest update to python3-threaded_servers seems to corrupt the files. The indication is that I receive an error message such as: "failed to receive file 'xyne-x86_64.db.sig' from localhost:15678 : Maximum file size exceeded." Also the fix suggested in the previous message is still required.