Arch Linux User Repository

Thanks, fixed. I dropped the config patch, it is against Arch philosophy anyways.

Fails to build after latest update:

==> Starting prepare()...
patching file conf.sample.php
Hunk #1 FAILED at 111.
Hunk #2 FAILED at 125.
Hunk #3 succeeded at 190 (offset 42 lines).
2 out of 3 hunks FAILED -- saving rejects to file conf.sample.php.rej

@fordprefect: well, I'm also short on time ;-) But I could push to this repository with the applied changes. Will test a little further first though.

@dvzrv: thanks for your suggestions. since I am extremely short on time atm, do you mind to send a patch?

@fordprefect: You might want to have a look at man sysusers.d and man tmpfiles.d. I suggest adding the /var/lib/privatebin directory and using systemd-tmpfiles to set permissions on that directory. Then you can easily use the prepare() function to set the data dir accordingly. No need for upstreaming, as other operating systems will have other ways of doing this.

Also: You can add web-servers/uwsgi/etc. as optdepends. Additionaly, it is always a good idea to make sure, that files are really only chmodded 644 in package().

Well… it’s not so simple… There are 2 ways you can handle web applications: — “web-style”: put everything where your HTTP server can run it, and let user http own everything (much like software installed in /opt, actually); or - “native-style”: explode everything into /usr, /var, /etc, /srv, where /usr is not writeable. We Linux packagers rightfully tend to choose the 2nd style, but in fact most web applications are primarily intended to be used with the 1st style. Symlinks allow us to seamlessly switch from web-style to native-style, but in this instance there is no need to make “data/” a symlink since the conf file allows for a custom path.

@YinYeti: this sounds like a sane decision, could you try to communicate this upstream (e.g. open a ticket for the developers)?

Thank you fordprefect, it worked perfectly! To other users of this software, I suggest one more thing (independent of the packaging): when you configure privatebin, in the conf file, change all PATH… lines to replace "data" with "/var/lib/privatebin", where this path will be a directory you create where user http can write. If you don’t do that, it will try to write in the "/usr/…/privatebin/data", where user http can _not_ write (and should not).

dang, you are right. corrected. Lesson learned: dont do this stuff half asleep…

Hey fordprefect, Thanks for this quick update :-) I’m afraid it won’t work, though: <1> mv "$pkgdir/usr/share/webapps/$pkgname/cfg" "$pkgdir/etc/webapps/cfg" <2> ln -s /etc/webapps/$pkgname "$pkgdir/usr/share/webapps/$pkgname/cfg" Here you create /etc/webapps/cfg on line <1>, but create a link from /etc/webapps/privatebin on line <2> ;-) I did not test, but I suppose it should be: mv "$pkgdir/usr/share/webapps/$pkgname/cfg" "$pkgdir/etc/webapps/$pkgname" ln -s /etc/webapps/$pkgname "$pkgdir/usr/share/webapps/$pkgname/cfg" Only the end of the first line changes.