AUR (en) - pacserve

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.108034
First Submitted:	2011-04-17 00:30 (UTC)
Last Updated:	2022-07-15 22:46 (UTC)

Latest Comments

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

Xyne commented on 2012-06-01 21:01 (UTC)

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.

<deleted-account> commented on 2012-06-01 19:26 (UTC)

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 (UTC)

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

dvzrv commented on 2012-05-05 17:20 (UTC)

@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! :)

Xyne commented on 2011-09-17 16:35 (UTC)

@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 (UTC)

[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