Package Details: pacserve 2015.11-1

Git Clone URL: https://aur.archlinux.org/pacserve.git (read-only)
Package Base: pacserve
Description: Easily share Pacman packages between computers. A replacement for PkgD.
Upstream URL: http://xyne.archlinux.ca/projects/pacserve
Keywords: arch_linux pacman server
Licenses: GPL
Submitter: Xyne
Maintainer: Xyne
Last Packager: Xyne
Votes: 66
Popularity: 0.321466
First Submitted: 2011-04-17 00:30
Last Updated: 2015-11-30 16:18

Latest Comments

lahwaacz commented on 2015-10-01 18:56

@dangersalad: If it happens with python-3.5, this is to be expected since python3-threaded_servers still has its files under /usr/lib/python-3.4/
As python-3.5 has left testing only today, give Xyne some time to update his packages...

dangersalad commented on 2015-10-01 18:12

I am getting this error when trying to start pacserve

pacserve[10930]: /usr/sbin/python3: Error while finding spec for 'ThreadedServers.Pacserve' (<class 'ImportError'>: No module named 'ThreadedServers')

% pacman -Qi pacserve
Name : pacserve
Version : 2015-1

% pacman -Qi python3-threaded_servers
Name : python3-threaded_servers
Version : 2014.11-1

Xyne commented on 2015-03-06 01:29

@Tempel
This is not a Pacserve error. The filename needs to be percent-encoded to produce a valid URL. Try "http://localhost:15678/pkg/?repo=extra&arch=x86_64&file=libsigc%2B%2B-2.4.1-1-x86_64.pkg.tar.xz" for example, with "+" replaced by "%2B".

Pacman does not properly encode the name before inserting it into the URL and so it fails because "+" represents a space in URL query strings.

This is not the first time that Pacman's lack of proper URL formatting has created a problem. Please create a ticket on the (Pacman) bugtracker.

Regards,
Xyne

Tempel commented on 2015-03-05 04:02

Pacserve seems to have an issue with any file containing a + in the filename. During updates of libsigc++ and freerdp (version 1.2.0_beta1+20150302-1), "The requested URL returned error: 404".

asdil12 commented on 2015-01-31 14:20

or you can put this line in your ~/.gnupg/gpg.conf:
keyserver-options auto-key-retrieve

This will allow gpg to auto-import keys on demand.

hamelg commented on 2015-01-31 14:18

You must import the Xyne public key in your GPG keyring.
https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

lcartercondon commented on 2015-01-30 00:08

==> Retrieving sources...
-> Found pacserve-2015.tar.xz
-> Found pacserve-2015.tar.xz.sig
==> Validating source files with md5sums...
pacserve-2015.tar.xz ... Passed
pacserve-2015.tar.xz.sig ... Passed
==> Validating source files with sha512sums...
pacserve-2015.tar.xz ... Passed
pacserve-2015.tar.xz.sig ... Passed
==> Verifying source file signatures with gpg...
pacserve-2015.tar.xz ... FAILED (unknown public key 1D1F0DC78F173680)
==> ERROR: One or more PGP signatures could not be verified!

I see the previous comment about updating the upstream signature but I am still getting this error.

olebowle commented on 2015-01-20 23:31

Could you please remove ExecRestart from the pacserve-ports.service file, as it's long gone.

The error message is:
[/usr/lib/systemd/system/pacserve-ports.service:15] Unknown lvalue 'ExecRestart' in section 'Service'

Xyne commented on 2015-01-15 05:31

I have updated the upstream signature.

asdil12 commented on 2015-01-10 00:01

gpg reports that the files are not signed with
EC3CBE7F607D11E663149E811D1F0DC78F173680
but with
4A8B17E20B88ACA61860009B5CED81B7C2E5C0D2

$ gpg --verify pacserve-2013.9.tar.xz.sig
gpg: assuming signed data in 'pacserve-2013.9.tar.xz'
gpg: Signature made Tue Sep 17 10:26:20 2013 CEST using RSA key ID C2E5C0D2
gpg: Good signature from "Xyne. <xyne@archlinux.ca>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 4A8B 17E2 0B88 ACA6 1860 009B 5CED 81B7 C2E5 C0D2

Xyne commented on 2015-01-07 00:44

@asdil12
The signature is already in the validpgpkeys array. You should have checked before flagging the package. Check the discussion in the comments on the pkg_scripts page for instructions to eliminate the error.

asdil12 commented on 2015-01-03 19:41

==> Validating source files with sha512sums...
pacserve-2013.9.tar.xz ... Passed
pacserve-2013.9.tar.xz.sig ... Passed
==> Verifying source file signatures with gpg...
pacserve-2013.9.tar.xz ... FAILED (unknown public key 5CED81B7C2E5C0D2)
==> ERROR: One or more PGP signatures could not be verified!


I think you need to define the GPG key fingerprint in the validpgpkeys array:
https://wiki.archlinux.org/index.php/PKGBUILD#validpgpkeys

Xyne commented on 2014-11-01 16:37

@untitaker
It seems that you have deleted the "ACCEPT" target on that machine. I recommend that you restore it.

untitaker commented on 2014-10-30 21:24

Since a while i had a mysterious failure of "pacserve-ports open":

running "iptables -A INPUT -p tcp --dport 15678 -j ACCEPT"
running "iptables -A INPUT -p udp -m pkttype --pkt-type multicast --dport 15679 -j ACCEPT"
iptables: No chain/target/match by that name.

Funnily this happens on only one system.

Xyne commented on 2014-04-05 13:17

> Just _rebuild_ the necessary packages. You need to do this manually for all python packages from the AUR.

This. It is the user's responsibility to rebuild AUR packages against new packages in the official repos.

You could also enable the repo on my site to install all of my packages directly with pacman without worrying about manual rebuilds.

lahwaacz commented on 2014-04-04 21:25

Just _rebuild_ the necessary packages. You need to do this manually for all python packages from the AUR.

paddington1961 commented on 2014-04-04 21:04

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

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

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

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

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

apoulos commented on 2013-09-16 20:59

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

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

@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

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

@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.

untitaker commented on 2013-05-25 15:31

@Xyne:

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

Xyne commented on 2013-05-25 02:44

@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

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

@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

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

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

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

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

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

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.

hamelg commented on 2013-05-12 19:33

After upgrading, pacserve fails to start with the error :

systemd[1]: Unit pacserve.service entered failed state.
systemd[1]: pacserve.service: main process exited, code=exited, status=1/FAILURE
pacserve[8175]: /usr/bin/python3: No module named Pacserve

to solve that, I just fix the library path in /usr/bin/pacserve :
python3 -mThreadedServers.Pacserve "$@"

Xyne commented on 2013-05-11 00:30

The log indicates that it's correctly redirecting so I'm not sure what's going on. Try disabling pacserve in pacman.conf, then run "pacman -Syyu" to force a database refresh, restart the service and try again.

Keep an eye on python3-threaded_servers for updates too.

nplatis commented on 2013-05-10 23:55

Still no luck. This time nothing works at all.

The output of pacman -Syu is the following:

error: GPGME error: No data
error: GPGME error: No data
error: GPGME error: No data
error: GPGME error: No data
error: GPGME error: No data
error: xyne-x86_64: missing required signature
:: Synchronizing package databases...
error: GPGME error: No data
error: failed to update core (invalid or corrupted database (PGP signature))
error: GPGME error: No data
error: failed to update extra (invalid or corrupted database (PGP signature))
error: GPGME error: No data
error: failed to update community (invalid or corrupted database (PGP signature))
error: GPGME error: No data
error: failed to update multilib (invalid or corrupted database (PGP signature))
error: GPGME error: No data
error: xyne-x86_64: missing required signature
error: failed to update xyne-x86_64 (invalid or corrupted database (PGP signature))
error: database 'core' is not valid (invalid or corrupted database (PGP signature))
error: database 'extra' is not valid (invalid or corrupted database (PGP signature))
error: database 'community' is not valid (invalid or corrupted database (PGP signature))
error: database 'multilib' is not valid (invalid or corrupted database (PGP signature))
error: database 'xyne-x86_64' is not valid (invalid or corrupted database (PGP signature)

and the journal (error log) contains entries such as:

May 11 02:50:12 dynamo pacserve[763]: [2013-05-11 02:50:12] INFO: 127.0.0.1 redirecting to http://ftp.cc.uoc.gr/mirrors/linux/archlinux/core/os/x86_64/core.db
May 11 02:50:12 dynamo pacserve[763]: [2013-05-11 02:50:12] INFO: 127.0.0.1 "GET /pkg/?repo=core&arch=x86_64&file=/core.db HTTP/1.1" 303 -

Xyne commented on 2013-05-10 23:26

please try python3-threaded_servers-2013.5.10.2

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.

Xyne commented on 2013-03-25 18:17

@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).

That 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.

KerrickStaley commented on 2013-03-25 07:49

pacsrv doesn't seem to detect the pacserve instance running on my other computer. The two computers are directly connected via an ad-hoc WiFi network; the computer with the up-to-date pacman cache is acting as the "router" (its IP is 10.42.0.1) and the computer running pacsrv is acting as a "client" (IP 10.42.0.46). Both computers have the pacserve Systemd service running.

Xyne commented on 2012-12-04 20:04

I originally wrote the multicast code mostly as a learning experience. The current code works as intended and it is not complicated. I see no reason to add avahi and all of its dependencies just to remove about 30 lines of existing code.

eworm commented on 2012-12-04 06:46

Ok, just another idea. I have not taken a look at it yet, so I can not tell what complicated it is.

If I understand this correctly pacserve has its own multicast implementation. How about using avahi for that? You would not have to care about the open udp port, multicast interval and the like.

Xyne commented on 2012-11-27 23:06

@eworm
The service wasn't using /etc/conf.d/pacserved because I thought it would be easier to create a custom service file (in both cases the user would just be editing a text file in /etc).

I liked your suggestions and have implemented them with some modifications. The global configuration file is now /etc/conf.d/pacserve. It manages runtime options, netfilter rules and the PID file for all services and scripts.

I have also included /etc/pacman.d/pacserve and updated the pacsrv wrapper script to use that instead.

Thanks for making me aware of the systemd.exec options. ;)

eworm commented on 2012-11-26 08:27

The systemd unit file does not read the config file. You should replace

ExecStart=/usr/bin/pacserve --multicast

with

EnvironmentFile=/etc/conf.d/pacserved
ExecStart=/usr/bin/pacserve $PACSERVED_ARGS

eworm commented on 2012-11-26 08:27

The systemd unit file does not read the config file. You should replace

ExecStart=/usr/bin/pacserve --multicast

with

EnvironmentFile=/etc/conf.d/pacserved
ExecStart=/usr/bin/pacserve --multicast $PACSERVED_ARGS

eworm commented on 2012-11-25 14:57

You could install a file /etc/pacman.d/pacserve containing the "Server = ..." line and include that in every repository with "Include = ...".

Xyne commented on 2012-11-25 09:25

The package now contains a service named "pacserve-ports". When enabled, it should open and close the standard pacserve ports when the pacserve service is started or stopped, respectively.

Let me know if there are any issues.

olebowle commented on 2012-10-24 08:53

The .sig file is missing.

Xyne commented on 2012-07-31 17:22

Just run "chown nobody:nobody /var/log/pacserve/pacserve.log" then. It should work. Otherwise, change the location of the log file using /etc/conf.d/pacserved.

sasy360 commented on 2012-07-31 01:56

Thanks for your effort Xyne. I now get this when running the daemon:
error: failed to open log file /var/log/pacserve/pacserve.log as 99:99 ([Errno 13] Permission denied: '/var/log/pacserve/pacserve.log')
there is already a --su option in /etc/rc.d/pacserved options array.

Xyne commented on 2012-07-29 01:42

@sasy360
It should be fixed now.

sasy360 commented on 2012-07-27 02:51

I get this error running the daemon:
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 504, in run
self.__target(*self.__args, **self.__kwargs)
File "/usr/bin/pacserve", line 935, in log_messages
e))
TypeError: %d format: a number is required, not builtin_function_or_method

Anonymous comment on 2012-06-20 19:18

You're right about the gpg issue, Xyne.

Here's a quick fix for anyone else:

pacman-key -e C2E5C0D2 | gpg --import - && gpg --lsign-key Xyne

ImNtReal commented on 2012-06-11 13:58

I just noticed an error in pacserve.service. The After line should have network.target instead of network.service in case NetworkManager or something else is being used instead of network.service. Thanks.

Xyne commented on 2012-06-01 21:01

Nope, the key is fine:
$ pacman-key --verify pacserve-2012.5.tar.xz.sig
gpg: Signature made 2012-05-05 14:45:56 Sat 18 UTC using RSA key ID C2E5C0D2
gpg: NOTE: trustdb not writable
gpg: Good signature from "Xyne. <xyne@archlinux.ca>"

I vaguely recall running into this problem myself. I think it's because makepkg uses (used?) the user's GPG keychain to validate signatures instead of the Pacman keychain. I thought I had posted a bug report but I can't find it (maybe I got sidetracked). Nevertheless, I am able to build the package without errors even on an account without my key in the user keychain.

This is related:
https://bugs.archlinux.org/task/28825

Check which keychains have my key:
* pacman-key --list-keys
* gpg --list-keys

Try adding it to pacman-key first if it's not there.

Anonymous comment on 2012-06-01 19:26

xyne, did something happen with your GPG keys?
http://pastebin.com/1njerKaY

The same problem is seen with your http server AUR entry.

Xyne commented on 2012-05-06 13:51

@david.runge
Thanks. I've updated the PKGBUILD.

dvzrv commented on 2012-05-05 17:20

@Xyne: You need to move the systemd service file to /usr/lib/systemd/system. Otherwise systemd is not able to find it and users will have to copy it to that folder or to /etc/systemd/system/ to make it work. It would also be wise to change the permission to match that of the other unit files:
install -D -m644 "$srcdir/$pkgname-$pkgver/$pkgname.service" "$pkgdir/usr/lib/systemd/system/$pkgname.service"
Great package btw! :)

dvzrv commented on 2012-05-05 16:44

@Xyne: You need to move the systemd service file to /usr/lib/systemd/system. Otherwise systemd is not able to find it and users will have to copy it to that folder or to /etc/systemd/system/ to make it work.
Otherwise great package!! :)

Xyne commented on 2011-09-17 16:35

@mar77i
That's a Pacman issue. You can do one of the following:
* Change your XferCommand to use curl
* ask the Pacman devs when it will be fixed and wait for that
* patch this package

The first option only requires you to uncomment a single line in pacman.conf.

I'm sorry but I am not going to break a web standard just because the pacman devs haven't fixed this yet. There are users who use standards-compliant clients in their XferCommands and changing this to 301 or 302 would create issues for them. If I have to choose between an accepted standard and an ugly kludge to fix one case and break most others, I'm sticking to the standard.

I could code a workaround to try to detect direct requests from pacman, but that would just add unnecessary complexity to the code. The XferCommand is the simplest and most elegant solution until this is fixed in pacman.

mar77i commented on 2011-09-14 12:35

[1] still is an issue here. line 248 can simply set to use 302, which makes things work.

pacman-3.5.4 is unhappy with 307:
# pacman -Syu
:: Synchronizing package databases...
error: failed retrieving file 'core.db' from 192.168.42.129 : Temporary Redirect
core is up to date
error: failed retrieving file 'extra.db' from 192.168.42.129 : Temporary Redirect
extra is up to date
error: failed retrieving file 'community.db' from 192.168.42.129 : Temporary Redirect
community is up to date
:: Starting full system upgrade...
there is nothing to do

[1] https://bugs.archlinux.org/task/23800

rafaelff commented on 2011-07-12 23:49

@Xyne
No problem. Thanks for your contributions to Arch! :)

Xyne commented on 2011-07-12 22:50

@josephgbr
I forgot. :P

rafaelff commented on 2011-07-11 23:37

My problem was solved by updating to pacserve-2011.06.24.1... Any reason for not updating PKGBUILD?

rafaelff commented on 2011-07-10 19:20

In a new archlinux installation, having pacman database updated and mirrorlist set as documented, I started pacserve. When I try to update I get message "error: failed retrieving file 'DBNAME.db' from localhost : Not Found", where 'DBNAME' is the repository name (ex: core). I looked in '/var/lib/pacman/' folder (which is the default pacman DBPATH) and I can't find any "DBNAME.db.tar.gz" (which I have in other old installation here), but I can see "DBNAME.db" files in '/var/lib/pacman/sync' folder.

Where did I go wrong in my settings?

p.s.: pacman is actually working fine with other repos, but it's ignoring pacserve's - which I don't want

Xyne commented on 2011-04-19 20:58

sorry, forgot to update python-xynehttpserver

Anonymous comment on 2011-04-19 19:59

I can't start pacserve, all I get is:

Traceback (most recent call last):
File "/usr/bin/pacserve", line 762, in <module>
main()
File "/usr/bin/pacserve", line 662, in main
parser = add_common_options(parser, default_port=DEFAULT_PORT)
TypeError: add_common_options() got an unexpected keyword argument 'default_port'

Xyne commented on 2011-04-19 18:27

@Ravenman
I've added more info to the project page, including a setup example.

Ravenman commented on 2011-04-18 21:15

Can you create the wiki page about pacserve, please?.