Package Details: privatebin 1.5.1-1

Git Clone URL: (read-only, click to copy)
Package Base: privatebin
Description: a minimalist, open source online pastebin where the server has zero knowledge of pasted data
Upstream URL:
Keywords: pastebin privacy
Licenses: zlib
Submitter: fordprefect
Maintainer: fordprefect
Last Packager: fordprefect
Votes: 7
Popularity: 0.000001
First Submitted: 2017-09-29 12:41 (UTC)
Last Updated: 2023-03-02 21:21 (UTC)

Latest Comments

1 2 Next › Last »

fordprefect commented on 2022-04-28 13:21 (UTC)

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

C0rn3j commented on 2022-04-28 13:07 (UTC)

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

dvzrv commented on 2018-03-20 19:07 (UTC)

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

fordprefect commented on 2018-02-24 16:12 (UTC)

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

dvzrv commented on 2018-02-15 14:32 (UTC)

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

theYinYeti commented on 2017-11-17 11:56 (UTC)

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.

fordprefect commented on 2017-11-17 10:02 (UTC)

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

theYinYeti commented on 2017-11-16 08:16 (UTC)

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

fordprefect commented on 2017-11-14 08:38 (UTC)

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

theYinYeti commented on 2017-11-14 07:15 (UTC)

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.