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.38
First Submitted: 2011-04-17 00:30
Last Updated: 2021-02-11 12:51

Latest Comments

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

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.