doesn't build against CUPS 1.6

Bug #1026666 reported by Jiri Popelka
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
HPLIP
New
Undecided
Unassigned
Gentoo Linux
Fix Released
Medium

Bug Description

Hi,

CUPS 1.6 has been planned to be out this summer.
There's however one feature [1] that prevents HPLIP from building against it.

CUPS 1.6 makes various structures private and
introduces several ippGet and ippSet functions
for all of the fields in these structures.

I'm attaching a patch that fixes it for me (tested with CUPS-1.6rc1).
With this patch we use these accessors for IPP API.
We also define our own accessors when CUPS < 1.6.

[1] http://www.cups.org/str.php?L3928

Revision history for this message
Jiri Popelka (jpopelka) wrote :
Revision history for this message
In , kdevgent (karel-de-vriendt) wrote :

Compile error during emerge. When I mask version 3.12.6, I get the same error with version 3.12.4. I assume it is something in my environment but I have no idea what.

Reproducible: Always

Steps to Reproduce:
1. emerge =net-print/hplip-3.12.4
2.
3.
Actual Results:
Compile error (see attached files)

Expected Results:
Emerging hplip without errors

Revision history for this message
In , kdevgent (karel-de-vriendt) wrote :
Download full text (4.8 KiB)

littleboy ~ # emerge --info '=net-print/hplip-3.12.6'
Portage 2.1.11.9 (default/linux/amd64/10.0/desktop, gcc-4.6.3, glibc-2.15-r2, 3.5.0-gentoo x86_64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-3.5.0-gentoo-x86_64-Intel-R-_Atom-TM-_CPU_N570_@_1.66GHz-with-gentoo-2.1
Timestamp of tree: Sun, 29 Jul 2012 13:15:01 +0000
app-shells/bash: 4.2_p37
dev-lang/python: 2.7.3-r2, 3.2.3-r1
dev-util/cmake: 2.8.8-r3
dev-util/pkgconfig: 0.27
sys-apps/baselayout: 2.1-r1
sys-apps/openrc: 0.10.5
sys-apps/sandbox: 2.6
sys-devel/autoconf: 2.13, 2.69
sys-devel/automake: 1.11.6, 1.12.2
sys-devel/binutils: 2.22.90
sys-devel/gcc: 4.6.3
sys-devel/gcc-config: 1.7.3
sys-devel/libtool: 2.4.2
sys-devel/make: 3.82-r3
sys-kernel/linux-headers: 3.5 (virtual/os-headers)
sys-libs/glibc: 2.15-r2
Repositories: gentoo
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="${EPREFIX}/etc/gconf /etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=native -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles news parallel-fetch parse-eapi-ebuild-head protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://mirrors.linuxant.fr/distfiles.gentoo.org/ http://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/ http://mirror.ovh.net/gentoo-distfiles/ http://gentoo.tiscali.nl/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="X a52 aac acl acpi alsa amd64 berkdb bluetooth branding bzip2 cairo cdda cdr cli consolekit cracklib crypt cups cxx dbus dri dts dvd dvdr emboss encode exif fam firefox flac fortran gdbm gif gpm gstreamer gtk iconv jpeg lcms libnotify lock mad mmx mng modules mp3 mp4 mpeg mudflap multilib ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pppd qt3support readline sdl session spell sse sse2 ssl startup-notification svg tcpd thunar tiff truetype udev udisks unicode upower usb vorbis wxwidgets x264 xcb xml xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw as...

Read more...

Revision history for this message
In , kdevgent (karel-de-vriendt) wrote :

littleboy ~ # emerge -pqv '=net-print/hplip-3.12.6'
[ebuild N ] net-print/hplip-3.12.6 USE="X acl fax hpcups libnotify policykit scanner snmp -doc -hpijs -kde -minimal -parport -qt4 -static-ppds"

Revision history for this message
In , kdevgent (karel-de-vriendt) wrote :

Created attachment 319730
Build log

Revision history for this message
In , kdevgent (karel-de-vriendt) wrote :

Created attachment 319732
Environment file

Revision history for this message
In , Polynomial-c (polynomial-c) wrote :

Seems to be a problem with >=net-print/cups-1.6.0. See URL for upstream bug.

Revision history for this message
In , kdevgent (karel-de-vriendt) wrote :

I can confirm that masking cups-1.6.0 solves the problem

Revision history for this message
In , Billie-gentoo (billie-gentoo) wrote :

(In reply to comment #6)
> I can confirm that masking cups-1.6.0 solves the problem

To help fixing this bug it would be great if anybody could test hplip-3.12.6 with the patch included upstream and test if it works with stable cups-1.5 and testing cups-1.6.

Revision history for this message
In , Polynomial-c (polynomial-c) wrote :

(In reply to comment #7)
> (In reply to comment #6)
> > I can confirm that masking cups-1.6.0 solves the problem
>
> To help fixing this bug it would be great if anybody could test hplip-3.12.6
> with the patch included upstream and test if it works with stable cups-1.5
> and testing cups-1.6.

I can confirm that the upstream patch works with cups-1.6.
But I had quite some trouble applying the patch because it seems like the hplip sources have DOS line breaks and portage's epatch doesn't like that even though the patch itself has DOS line breaks as well. So I ended up using edos2unix on the two files the patch is modifying and converted the patch itself to Unix line breaks, too.

I just finished testing the patch with cups-1.5.3 and it compiles fine with that version. Printing seems to be okay as well. So I'd say give it a try.

Revision history for this message
In , Christoph Mende (cmende) wrote :

(In reply to comment #8)
> I can confirm that the upstream patch works with cups-1.6.
> But I had quite some trouble applying the patch because it seems like the
> hplip sources have DOS line breaks and portage's epatch doesn't like that
> even though the patch itself has DOS line breaks as well. So I ended up
> using edos2unix on the two files the patch is modifying and converted the
> patch itself to Unix line breaks, too.

Note that you only need this on the first file (prnt/cupsext/cupsext.c). The problem is that this file has CRLF line endings while the other file in the patch has LF line endings. So if you just use epatch (converts CRLF to LF) it'll fail on the first file, if you use epatch --binary (won't convert) it'll fail on the second file.

Revision history for this message
In , Sylvain Alain (d2-racing) wrote :

I have the same problem on my box.

Here's my hplip :

[ebuild R ] net-print/hplip-3.12.6 USE="X hpcups qt4 -acl* -doc -fax -hpijs -kde -libnotify -minimal -parport -policykit -scanner -snmp -static-ppds" 0 kB

My cups :

[ebuild R ] net-print/cups-1.6.1 USE="X acl dbus filters pam python ssl threads usb -avahi -debug -gnutls -java -kerberos (-selinux) -static-libs -systemd -xinetd -zeroconf" LINGUAS="-ca -es -ja" 0 kB

prnt/cupsext/cupsext.c: In function 'getPrinters':
prnt/cupsext/cupsext.c:336:12: error: dereferencing pointer to incomplete type
prnt/cupsext/cupsext.c:337:12: error: dereferencing pointer to incomplete type
prnt/cupsext/cupsext.c:381:30: error: dereferencing pointer to incomplete type
prnt/cupsext/cupsext.c:381:64: error: dereferencing pointer to incomplete type
prnt/cupsext/cupsext.c:383:41: error: dereferencing pointer to incomplete type
prnt/cupsext/cupsext.c:384:28: error: dereferencing pointer to incomplete type
prnt/cupsext/cupsext.c:393:41: error: dereferencing pointer to incomplete type
prnt/cupsext/cupsext.c:395:22: error: dereferencing pointer to incomplete type
prnt/cupsext/cupsext.c:395:22: error: dereferencing pointer to incomplete type
.....

Revision history for this message
In , Havin_it (robin-bankhead) wrote :

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > I can confirm that masking cups-1.6.0 solves the problem
> >
> > To help fixing this bug it would be great if anybody could test hplip-3.12.6
> > with the patch included upstream and test if it works with stable cups-1.5
> > and testing cups-1.6.
>
> I can confirm that the upstream patch works with cups-1.6.
> But I had quite some trouble applying the patch because it seems like the
> hplip sources have DOS line breaks and portage's epatch doesn't like that
> even though the patch itself has DOS line breaks as well. So I ended up
> using edos2unix on the two files the patch is modifying and converted the
> patch itself to Unix line breaks, too.
>
> I just finished testing the patch with cups-1.5.3 and it compiles fine with
> that version. Printing seems to be okay as well. So I'd say give it a try.

Could someone describe (for us numpties) how to apply this patch, or post an ebuild that does the job? I have:

- Copied the net-print/hplip dir to local overlay;
- Added the patch to the /files dir
- Done ebuild hplip-3.12.6.ebuild digest

I don't see the patch listed with other patches being applied at the start of the build though - presumably this means it fails silently?

If I understand the above, I could (as a temp. hack) call dos2unix in the ebuild, but not sure the syntax to do this. I'm keen to join the testing of this so would be very appreciative if someone can advise (others tuning in might be too).

Revision history for this message
In , Cslycord (cslycord) wrote :

(In reply to comment #11)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > (In reply to comment #6)
> > > > I can confirm that masking cups-1.6.0 solves the problem
> > >
> > > To help fixing this bug it would be great if anybody could test hplip-3.12.6
> > > with the patch included upstream and test if it works with stable cups-1.5
> > > and testing cups-1.6.
> >
> > I can confirm that the upstream patch works with cups-1.6.
> > But I had quite some trouble applying the patch because it seems like the
> > hplip sources have DOS line breaks and portage's epatch doesn't like that
> > even though the patch itself has DOS line breaks as well. So I ended up
> > using edos2unix on the two files the patch is modifying and converted the
> > patch itself to Unix line breaks, too.
> >
> > I just finished testing the patch with cups-1.5.3 and it compiles fine with
> > that version. Printing seems to be okay as well. So I'd say give it a try.
>
> Could someone describe (for us numpties) how to apply this patch, or post an
> ebuild that does the job? I have:
>
> - Copied the net-print/hplip dir to local overlay;
> - Added the patch to the /files dir
> - Done ebuild hplip-3.12.6.ebuild digest
>
> I don't see the patch listed with other patches being applied at the start
> of the build though - presumably this means it fails silently?
You need to edit the ebuild to include the patch. Otherwise, the ebuild behaves as it did before (since you made no changes to it).

Revision history for this message
In , Cslycord (cslycord) wrote :

The easy way to fix this is to cut all the stuff after the first diff out of the patch and put it into a second one.

Revision history for this message
In , Cslycord (cslycord) wrote :

Created attachment 320218
hplip-3.12.6-ipp_accessors.patch

This is just the first part of the upstream patch (the part that has the DOS line endings)

Revision history for this message
In , Cslycord (cslycord) wrote :

Created attachment 320220
hplip-3.12.6-ipp_accessors2.patch

This is the rest of the upstream patch (the parts that have unix line endings)

Revision history for this message
In , Cslycord (cslycord) wrote :

Created attachment 320222
hplip-3.12.6.ebuild

Ebuild that uses the two separated patches. The first one is done using "epatch --binary"

I imagine the gentoo dev will choose better names for having these separated, but atm this is good enough for me. :)

Revision history for this message
In , Lorenzen-robert (lorenzen-robert) wrote :

Hey I am trying to use the patches provided to get 3.12.6 to build but for some reason cant get the patches to apply. I am using the split patches provided by the members below but i get this error:

PATCH COMMAND: patch -p4 -g0 -E --no-backup-if-mismatch --binary < '/usr/local/portage/net-print/hplip/files/hplip-3.12.6-first.patch'

====================================
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -up hplip-3.12.6/prnt/cupsext/cupsext.c.ipp_accessors hplip-3.12.6/prnt/cupsext/cupsext.c
|--- hplip-3.12.6/prnt/cupsext/cupsext.c.ipp_accessors 2012-06-18 12:41:19.000000000 +0200
|+++ hplip-3.12.6/prnt/cupsext/cupsext.c 2012-07-19 17:11:47.606524137 +0200
--------------------------
No file to patch. Skipping patch.
15 out of 15 hunks ignored

patch program exited with status 1

for patch #1, notice I have changed the name of the patch but I rewrote my own ebuild to reflect the changes shown below but using my naming scheme. Does this matter? It never has before... I have done this before so I don't know what the problem is...

I made sure to use --binary for the first one and not the second, but it fails one the first one anyway without looking at the second. So... yeah can someone help me?

Revision history for this message
In , Billie-gentoo (billie-gentoo) wrote :

Created attachment 320244
Reworked patch

I have reworked the patch so it should now work without splitting and binary option from patch. Please test!

@Chris Slycord: Thank you for your work, this made it a bit easier for me.

Revision history for this message
In , Billie-gentoo (billie-gentoo) wrote :

Created attachment 320246
Needed ebuild changes

@Chris Slycord: Next time please attach a diff for ebuilds as well. This makes things more readable.

Revision history for this message
Daniel Pielmeier (daniel-pielmeier) wrote :

This is a reworked patch cause there were issues with the patched files using different EOL markers.

Revision history for this message
In , Mattia Rossi (matrossi) wrote :

Created attachment 320262
patch failure output

I'm also not able to build hplip-3.12.6 (or samba-3.6.6 with use flag cups) since the update to cups-1.6.1 (I've skipped 1.6.0).

I've tried to apply the latest patch, but it failed as per attachment..
Of course no .rej file thanks to the --no-backup-if-mismatch flag..

Revision history for this message
In , Billie-gentoo (billie-gentoo) wrote :

(In reply to comment #20)
> Created attachment 320262 [details]
> patch failure output
>
> I'm also not able to build hplip-3.12.6 (or samba-3.6.6 with use flag cups)
> since the update to cups-1.6.1 (I've skipped 1.6.0).
>
> I've tried to apply the latest patch, but it failed as per attachment..
> Of course no .rej file thanks to the --no-backup-if-mismatch flag..

Hm, the patch works fine here. Using different line endings is really annoying and hplip used to change them back and forth. I have opened a bug upstream requesting the use of a consistent EOL marker.

Revision history for this message
In , Havin_it (robin-bankhead) wrote :

(In reply to comment #12)

> You need to edit the ebuild to include the patch. Otherwise, the ebuild
> behaves as it did before (since you made no changes to it).

I did look at the ebuild but patches weren't named individually there ... It looked as though all .patch files for that version in the /files dir would be applied automatically, but that's probably just my poor understanding of ebuilds :(

Anyway, got there in the end with the new patch. Just had to freeze the build with Ctrl+Z at the right moment and apply the patch manually.

Having done this, I can report that hplip builds successfully with the patch on x86 and amd64. (Whether it will now work, that's another matter...)

Revision history for this message
In , Mattia Rossi (matrossi) wrote :

Seems something happened when downloading the patch. Re-downloaded it, and it worked.

Changed in gentoo:
importance: Unknown → Medium
Revision history for this message
In , Polynomial-c (polynomial-c) wrote :

So what's keeping this bug from getting fixed?

Revision history for this message
In , Billie-gentoo (billie-gentoo) wrote :

(In reply to comment #24)
> So what's keeping this bug from getting fixed?

Limited time!
Will try to get the patched version into the tree this evening.

Revision history for this message
In , Billie-gentoo (billie-gentoo) wrote :

+ 08 Aug 2012; Daniel Pielmeier <email address hidden> hplip-3.12.6.ebuild:
+ Fix building with cups-1.6. Thanks to all involved in bug #428672.

Done.

Changed in gentoo:
status: Unknown → Fix Released
Revision history for this message
In , J-greenbaum (j-greenbaum) wrote :

Wouldn't it make sense to updated the ebuild for the latest unmasked net-print/hplip to require cups <1.6 so that more people don't hit this, or if they do hit this because they have newer cups installed be notified of this known dependency by portage?

Revision history for this message
In , Billie-gentoo (billie-gentoo) wrote :

(In reply to comment #27)
> Wouldn't it make sense to updated the ebuild for the latest unmasked
> net-print/hplip to require cups <1.6 so that more people don't hit this, or
> if they do hit this because they have newer cups installed be notified of
> this known dependency by portage?

Mixing stable and unstable has never been supported. If cups-1.6 becomes stable then a hplip version supporting it should become stable as well.

Feel free to back-port the fix to a stable version of hplip and I will apply it.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.