Package Details: lprng 3.8.C-10

Git Clone URL: (read-only, click to copy)
Package Base: lprng
Description: An Enhanced Printer Spooler
Upstream URL:
Licenses: custom:Artistic
Conflicts: cups
Submitter: axs
Maintainer: djraymondnm
Last Packager: djraymondnm
Votes: 9
Popularity: 0.002380
First Submitted: 2008-12-01 12:01 (UTC)
Last Updated: 2017-10-28 18:49 (UTC)

Latest Comments

lpilz commented on 2022-02-07 13:20 (UTC)

For me, the build breaks with

/usr/bin/ld: vars.o:(.bss+0x7e8): multiple definition of `Mail_fd'; checkpc.o:(.bss+0x0): first defined here

Is this a known issue?

eschwartz commented on 2018-09-30 03:00 (UTC) (edited on 2018-09-30 15:45 (UTC) by eschwartz)

The install script is utterly wrong and results in pacman seeing files as missing, and other files being completely untracked. Do not use install scripts to do the job that rightfully belongs to package().

ron2138, the AUR supports markdown (python-markdown with standard extensions, including some aspects of github-flavored markdown) so you can just use ``` to delimit code blocks.

ron2138 commented on 2018-09-11 13:25 (UTC) (edited on 2018-09-30 22:28 (UTC) by ron2138)

The following patches:

  1. States the URL of the upstream source that is actually used. I think the other URL is a bit misleading, because it supposedly states a source version that is not used by this package.
  2. Install all the sample files by pacman, avoiding moving files by an install script. Avoiding work by the install script looks to me cleaner, though in this case it is negligible. I don't see if there is any reason to prefer the install script method over the more cleaner way of avoiding it in this case. Am I missing something?
    diff --git a/PKGBUILD b/PKGBUILD
    index b500855..69b38d4 100644
    --- a/PKGBUILD
    +++ b/PKGBUILD
    @@ -6,7 +6,7 @@ pkgver=3.8.C
     pkgdesc="An Enhanced Printer Spooler"
     arch=('i686' 'x86_64')
     depends=(openssl bash)
    @@ -70,6 +70,10 @@ package() {
          install -D -m 0644 "${srcdir}/lpd.perms" \
    +     mv "${pkgdir}/etc/lprng/printcap.sample" \
    +        "${pkgdir}/etc/lprng/lpd/lpd.conf.sample" \
    +        "${pkgdir}/etc/lprng/lpd/lpd.perms.sample" \
    +         "${pkgdir}/usr/share/doc/lprng/"

    @@ -82,4 +86,4 @@ md5sums=('5901bed95e61d2bea3ba3056056af432'
    -         '0f21b173ae0f16d225b4519e0f3238ff')
    +         'd3d4423db63a7242c3f68b61e8346fdc')

    diff --git a/lprng.install b/lprng.install
    index 8039b18..5b6a80b 100755
    --- a/lprng.install
    +++ b/lprng.install
    @@ -1,9 +1,3 @@
    -post_install() {
    -  mv /etc/lprng/printcap.sample /etc/lprng/lpd/lpd.conf.sample \
    -    /etc/lprng/lpd/lpd.perms.sample /usr/share/doc/lprng
    -  echo 'See /usr/share/doc/lprng/README to configure'
     pre_remove() {
       /usr/bin/systemctl stop lpd.service
       /usr/bin/systemctl disable lpd.service

djraymondnm commented on 2017-10-28 18:56 (UTC)

I have turned off openssl in version 10 as configuration now fails (why???) and ssl doesn't seem to be needed for common usage. (I tried it on our network, printing remotely from a cups client.) Works out of the box now.

02m commented on 2017-10-26 16:14 (UTC)

Got the same error as killajoe while installing.

killajoe commented on 2017-10-04 08:28 (UTC)

checking if ssl authentication is disabled... enabled checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes checking for RC4_set_key in -lcrypto... yes checking for SSL_load_error_strings in -lssl... no configure: error: Unable to use OpenSSL ... someone have builded this one actually?

asveikau commented on 2017-06-05 18:31 (UTC)

Hi, Wanted to note a few things. 1. PKGBUILD says it supports i686 and x86_64 but for a few years now I am running it on a raspberry pi without issue (armv6h). 2. Recently this package seems to have linker issues with libssl for me (openssl 1.1.0.f-1). I manually removed --enable-ssl as a workaround since I'm not using it on my LAN, didn't care to dig any further than that.

djraymondnm commented on 2016-04-05 23:54 (UTC)

This package was flagged out of date on 1 Jan 2016 because version 3.8.35 has become available on the original lprng website. The version used here is based on 3.8.32 and appears to have been forked by Debian people. I have tried to compile 3.8.35 from the original website with no success. Further examination suggests that Debian has put in a heroic amount of effort to make lprng compile and run. Furthermore, according to the change log in 3.8.35, no changes significant to Linux were made between 32 and 35. I therefore consider the current version 3.8.C up to date and I am removing the out of date flag.

djraymondnm commented on 2015-02-20 20:28 (UTC)

Regarding the comment by Grymer about the installation of lprng failing because /usr/sbin exists, I have solved this problem by forcing the installation of all binary files for lprng directly into /usr/bin. So, lprng installs cleanly now. Also, a filter that uses foomatic-rip has been added, so that the whole .ppd filter system can be used. This requires the installation of foomatic-filters-lprng from the AUR. Finally, a Wiki page now exists for lprng.

djraymondnm commented on 2015-01-18 23:09 (UTC)

Well, I'm stumped! I uninstalled lprng on my laptop and reinstalled it and I had no problem. Quite a few lprng programs get installed in /usr/sbin, but this should work with the link unless /usr/bin has some executables the clash with lprng executables. (This among other reasons is why cups conflicts with lprng.) I also have /usr/sbin as a symbolic link to /usr/bin (as it is supposed to be). Glad you found a way to install.

grymer commented on 2015-01-17 23:46 (UTC)

It's definitely a symbolic link, and I'm using a fresh system installed from the '2015.01.01' ISO. Not sure why pacman complained.

djraymondnm commented on 2015-01-15 16:52 (UTC)

Hmmm... I haven't seen this. Are you sure that your '/usr/sbin' really is a link to '/usr/bin' at this point? If there is stuff in /usr/sbin when the filesystem upgrade is done, this upgrade might fail. If that is true, then you can just move stuff in sbin to bin and manually make /usr/sbin a symbolic link.

grymer commented on 2015-01-15 11:59 (UTC)

Compiled great, but Pacman install failed first time with message 'lprng: /usr/sbin exists in filesystem'. It installed okay by using the '--force' option. I guess this is because the filesystem package provides a symlink '/usr/sbin -> /usr/bin' ('/usr/sbin' now being deprecated).

acampbell commented on 2014-08-23 14:52 (UTC)

Tnanks: this now compiles without problems.

djraymondnm commented on 2014-04-12 23:53 (UTC)

Corrected a problem with gsfilter in version 5.

djraymondnm commented on 2014-02-21 16:20 (UTC)

I just uploaded a much cleaner version of the lprng package (-3), including a link to the reference manual on my website, as the original documentation website has just disappeared.

djraymondnm commented on 2014-02-04 02:24 (UTC)

I just uploaded a new version of lprng which is based on code at sourceforge. It works for me on an up to date Arch system.

acampbell commented on 2013-06-02 17:21 (UTC)

I'm new to Arch and this is my first attempt at compiling on AUR. I've been using lprng for years on Debian and was keen to have it in Arch. Unfortunately I didn't succeed. I made the changes mentioned below by jevv but although the numerous errors went away during the compile the eventual message was "failed to build". I really don't like CUPS but it looks as if there isn't any alternative.

commented on 2011-10-10 02:27 (UTC)

Wow, now lprng build is missing flags (though not sure which). To make the thing compile I had to edit makepkg.conf, and add in the 3 compilation flags (CFLAGS, CXXFLAGS and LDFLAGS) the following: -Wno-error=unused-result With this the errors due to warnings indicating result values are unused, get ignored, and thus, the error is prevented. Finally lprng compiles...

commented on 2011-10-10 01:38 (UTC)

New building failure on x86_64: /bin/sh ../libtool --mode=compile gcc -I.. -I. -I./include -I./common -D_FILE_OFFSET_BITS=64 -I/usr/include -g -W -Wall -Werror -Wno-unused -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -D_FILE_OFFSET_BITS=64 -g -W -Wall -Werror -Wno-unused -DHAVE_CONFIG_H -c ./common/getqueue.c libtool: compile: gcc -I.. -I. -I./include -I./common -D_FILE_OFFSET_BITS=64 -I/usr/include -g -W -Wall -Werror -Wno-unused -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -D_FILE_OFFSET_BITS=64 -g -W -Wall -Werror -Wno-unused -DHAVE_CONFIG_H -c ./common/getqueue.c -o getqueue.o ./common/getqueue.c: In function ‘Trim_status_file’: ./common/getqueue.c:1700:13: error: ignoring return value of ‘ftruncate’, declared with attribute warn_unused_result [-Werror=unused-result] cc1: all warnings being treated as errors make[1]: *** [getqueue.lo] Error 1 make[1]: Leaving directory `/tmp/yaourt-tmp-vasqueja/aur-lprng/src/LPRng-3.8.35/src' make: *** [src] Error 2 Any idea?

commented on 2011-10-10 01:36 (UTC)

The errors go away with: cd /usr/lib sudo ln -s libfakeroot/ As pointed out by: However there's another building problem to solve. I'll talk to it in next comment...

commented on 2011-09-05 11:45 (UTC)

I'm trying to build the LPRng package using makepkg. When makepkg runs, it outputs dozens and dozens of lines which state: ERROR: object '' from LD_PRELOAD cannot be preloaded: ignored. Eventually, makepkg finishes with " ==> ERROR: A failure occurred in build(). Aborting..." My Arch system is fully up-to-date as of last week (2nd September 2011). What do I need to do to build this package successfully?

axs commented on 2011-01-04 23:26 (UTC)

Ugh, never have any problem with, ftp or http, and they list FTP as the main source. The site doesn't have any SF links on download page, and looks like they didn't update their SF page in a while. Changed ftp link to http though, agreed, it should be easier for most people to use http. Arch being rolling release system and all, I guess there is a reason to keep the "current" version in this package, and maybe create another one for (apparently stable) 3.8.A. And hm, it really doesn't require any patches. The package itself is larger because of the docs — and again, looks like they have no source-only package on the main site.

commented on 2010-05-04 03:19 (UTC)

This was an old comment I had... Why is the used as the source for lprng, when the page itself,, points to Problem is that the sources are not able to be downloaded most of the time. This hurts the package, which by the way keeps being my preferred spooler... Only caveat with the sourceforge repositories, is that the version conventin doesn't follow the one... Under debian unstable they're using 8.3.A (, and they're around the 3rd version of this source... If we use the sourceforge source, as debian is doing, the bonus is that there are no patches needed, and I haven't found the source I pointed out, unavailable. Another approach is to use the http source,, but it doens't work all the time, but at least it improves over the ftp source, which is pretty much dow most of the time... One noticeable difference is that the sourceforge source is 958K long, while the http lprng one is 12M, not sure why the increase in size, niether why 3.8.33 was not uploaded into sourceforge, if sourceforge is actually pointed out by the original web page...