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.075861
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 .. 3 4 5 6 7 8 9 10 11 12 13 14 Next › Last »

<deleted-account> commented on 2014-04-04 21:04 (UTC)

It probably isn't a good fix but copying /usr/lib/python3.3/site-packages/ThreadedServers to /usr/lib/python3.4/site-packages/ThreadedServers fixes the problem for the time being

schmoken commented on 2014-04-04 03:14 (UTC)

Python 3.4 update breaks pacserve. ● pacserve.service - Pacserve Loaded: loaded (/usr/lib/systemd/system/pacserve.service; enabled) Active: activating (auto-restart) (Result: exit-code) since Thu 2014-04-03 20:47:28 MDT; 4s ago Process: 7526 ExecStart=/usr/bin/pacserve $PACSERVE_ARGS (code=exited, status=1/FAILURE) Main PID: 7526 (code=exited, status=1/FAILURE)

Xyne commented on 2013-11-21 00:39 (UTC)

Hi altrus, I see how that may be useful, but at the same time anyone who has configured their firewall with rules specific enough to drop the target packets before they reach the end of the chain is likely someone who will want to manage their own rules entirely on their own. More importantly, inserting the rule would usurp other rules. If the user has decided to filter those packets for some reason, I think it's best to let the user determine the best configuration. Besides, I don't feel like getting stabbed by fukawi2 [1] :P [1] https://bbs.archlinux.org/viewtopic.php?pid=1210848#p1210848

altrus commented on 2013-11-17 19:19 (UTC)

Hi, The default behaviour of pacserve-ports is to append the allow rules to the end of the INPUT chain. Depending on how iptables is configured, this may result in otherwise legitimate packets being dropped by earlier rules. To avoid this from happening, consider replacing the 'append' rule with an 'insert' rule. This requires changing the invocation of the iptables binary in the /usr/bin/pacserve-ports file. This requires first substituting the -A (append) flag to -I (insert) on line 12, so it reads: "$iptables_bin" -I $@ || exit 1 Next, we have to specify what rule number we want to insert at in the /etc/pacserve/pacserve-ports.conf file. This requires us to specify the rule number we want to insert the rule at. I've (somewhat arbitrarily) decided to insert the rule at line 3. This means the new conf file reads: PACSERVE_RULES=( 'INPUT 3 -p tcp --dport 15678 -j ACCEPT' 'INPUT 3 -p udp -m pkttype --pkt-type multicast --dport 15679 -j ACCEPT' ) You may wish to consider making this the default behaviour, as it ensures the pacserve rules will accept the packages, even if later rules try to drop the packets.

Xyne commented on 2013-09-17 08:30 (UTC)

@apoulos I had completely forgotten about that. I has been fixed in pacserve 2013.9. Thanks!

apoulos commented on 2013-09-16 20:59 (UTC)

Found python2 reference in /usr/bin/pacman.conf-insert_pacserve It says: #!/usr/bin/env python2 # Compatible with Python 3, so just change the hashbang later. So I changed it to python3 and now I don't need python2 anymore.

Xyne commented on 2013-07-27 06:59 (UTC)

p.s. Please update to the latest version and let me know if pacsrv works as expected for e.g. lirc and lirc-utils.

Xyne commented on 2013-07-27 06:57 (UTC)

@apoulos Pacserve only works with Python 3. There seems to be something wrong with your setup. The executables use the hashbang #!/usr/bin/env python3 I have never needed to change my Python environment settings so I do not know what you need to do to fix it. The errors for packages with colons in the file name is due to a (long-standing) bug in Pacman. I have added code to specifically detect Pacman clients but this is really something that the Pacman devs should fix. Please let them know that you have also encountered the error. Specifically, tell them that HTTP redirects should be URL-decoded (a.k.a. percent-decoded).

apoulos commented on 2013-07-26 00:58 (UTC)

On a fresh i686 install, I noticed that I get a 0 sized /tmp/pacsrv-root.conf file on executing "pacsrv -Sy". The output is: /usr/bin/env: python2: No such file or directory error: no usable package repositories configured. I installed python2, removed the pacsrv-root.conf and then it worked fine. Should python2 be a dependency? Also, I noticed while running a pacsrv -Syu, it works great, except on package names which include a colon ":". Here are the two errors I found: error: failed retrieving file 'lirc-utils-1:0.9.0-52-i686.pkg.tar.xz' from localhost:15678 : The requested URL returned error: 400 Bad Request error: failed retrieving file 'lirc-1:0.9.0-52-i686.pkg.tar.xz' from localhost:15678 : The requested URL returned error: 400 Bad Request

Xyne commented on 2013-05-25 16:58 (UTC)

@untitaker The problem is that the default XferCommand example in pacman.conf lacks proper quotes. If you use -O '%o' '%u' instead, it works as expected. I'll send an email to the pacman dev mailing list about this.

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