rollback print/cups for pkgsrc-2014Q2?

[Eric Schnoebelen]

I've just spent the weekend trying to (re)create a working CUPS
print server from the recently updated (to 1.7.3) print/cups package.

After futzing and fighting with it for most of the weekend, I
was unable to create a working print server. With the previous
version, it was working fine. Fundementally, it's *bad* when it
can't even print a test page on a postscript printer.

To that end, I rolled my own CUPS print server back to the
1.5.4nb11 package that was on the -2014Q1 branch.

In the interest of making sure our users have a working print
server once they upgrade to the pkgsrc-2014Q2 branch, I'd
strongly recommend we roll back the print/cups package to
1.5.4nb11.

Other opinions?

Thanks,
Eric

--
Eric Schnoebelen ***@cirr.com/***@netbsd.org http://www.cirr.com
The Internet interprets censorship as damage and routes around it.
-- Old net.parable

[Fredrik Pettai]

Post by Eric Schnoebelen
I've just spent the weekend trying to (re)create a working CUPS
print server from the recently updated (to 1.7.3) print/cups package.
After futzing and fighting with it for most of the weekend, I
was unable to create a working print server. With the previous
version, it was working fine. Fundementally, it's *bad* when it
can't even print a test page on a postscript printer.
To that end, I rolled my own CUPS print server back to the
1.5.4nb11 package that was on the -2014Q1 branch.
In the interest of making sure our users have a working print
server once they upgrade to the pkgsrc-2014Q2 branch, I'd
strongly recommend we roll back the print/cups package to
1.5.4nb11.
Other opinions?

Did you try 1.6.4 ?

(Before I get too frustrated with never getting the latest version to work, I usually back down a major version just to see if it works better. Usually this saves some hair pulling, and also helps in pinpointing the problem(s) introduced in the latest version(s)...)

/P

[Eric Schnoebelen]

Fredrik Pettai writes:
- On Jun 16, 2014, at 05:28 , Eric Schnoebelen <***@NetBSD.org> wrote:
- > To that end, I rolled my own CUPS print server back to the
- > 1.5.4nb11 package that was on the -2014Q1 branch.
- >
- > In the interest of making sure our users have a working print
- > server once they upgrade to the pkgsrc-2014Q2 branch, I'd
- > strongly recommend we roll back the print/cups package to
- > 1.5.4nb11.
- >
- > Other opinions?
-
- Did you try 1.6.4 ?

No, but I doubt it would have provided much joy, since 1.6.x was
the release where Apple decoupled all of the previously built in
filters.

Seriously, I needed a working printing system badly, so I backed
down to what worked.

--
Eric Schnoebelen ***@cirr.com http://www.cirr.com
Those are my principles, and if you don't like them...
well, I have others. -- Groucho Marx

[Hauke Fath]

Post by Eric Schnoebelen
In the interest of making sure our users have a working print
server once they upgrade to the pkgsrc-2014Q2 branch, I'd
strongly recommend we roll back the print/cups package to
1.5.4nb11.
Other opinions?

Maybe re-activate 1.5.4 as print/cups, and make the newer version
print/cups17 for now?

hauke

[Edgar =?utf-8?B?RnXf?=]

Post by Hauke Fath
Maybe re-activate 1.5.4 as print/cups, and make the newer version
print/cups17 for now?

Yes, please.
Isn't it that CUPS 1.6 dropped the standard CUPS browsing protocol?

[Manuel Bouyer]

Post by Edgar =?utf-8?B?RnXf?=

Post by Hauke Fath
Maybe re-activate 1.5.4 as print/cups, and make the newer version
print/cups17 for now?

Yes, please.
Isn't it that CUPS 1.6 dropped the standard CUPS browsing protocol?

This is what I remember too. And I'm still relying on the CUPS browsing
protocol for a few things.

[Eric Schnoebelen]

Manuel Bouyer writes:
- On Mon, Jun 16, 2014 at 11:17:16AM +0200, Edgar Fu? wrote:
- > > Maybe re-activate 1.5.4 as print/cups, and make the newer version
- > > print/cups17 for now?
- >
- > Yes, please.
- > Isn't it that CUPS 1.6 dropped the standard CUPS browsing protocol?
-
- This is what I remember too. And I'm still relying on the CUPS browsing
- protocol for a few things.

print/cups-filters does supply a new daemon that implements the CUPS
browsing protocols. So, not all is lost there. (if only it all
played well out of the box right now.)

--
Eric Schnoebelen ***@cirr.com http://www.cirr.com
Those are my principles, and if you don't like them...
well, I have others. -- Groucho Marx

[Eric Schnoebelen]

Hauke Fath writes:
- On Sun, 15 Jun 2014 22:28:20 -0500, Eric Schnoebelen wrote:
- > In the interest of making sure our users have a working print
- > server once they upgrade to the pkgsrc-2014Q2 branch, I'd
- > strongly recommend we roll back the print/cups package to
- > 1.5.4nb11.
- >
- > Other opinions?
-
- Maybe re-activate 1.5.4 as print/cups, and make the newer version
- print/cups17 for now?

Or simply hold off on re-importing cups 1.7.3 as print/cups
until after the -2014Q2 freeze is complete. That'll give
everyone 3 months to sort out the issues before the next freeze.
Hopefully by then we can get it resolved.

--
Eric Schnoebelen ***@cirr.com http://www.cirr.com
Those are my principles, and if you don't like them...
well, I have others. -- Groucho Marx

[Uwe Klaus]

Hi,

I also spent some time to get cup 1.7.3 running, but I managed to print.
For postscript based printers I used cups-filters. The cups and the
cups-filters package share some files, so you have to resolve PLIST
conflicts.

share/cups/banners/classified
share/cups/banners/confidential
share/cups/banners/secret
share/cups/banners/standard
share/cups/banners/topsecret
share/cups/banners/unclassified
share/cups/data/testprint

For non postscript based printers (in my case HP Photosmart C309a) I
installed hplip together with ghostscript-gpl and option cups enabled
(ghostscript-agpl didn't work).
Again ghostscript-gpl and cups-filters share some files.

libexec/cups/filter/gstopxl
libexec/cups/filter/gstoraster

Post by Eric Schnoebelen
After futzing and fighting with it for most of the weekend, I
was unable to create a working print server. With the previous
version, it was working fine. Fundementally, it's *bad* when it
can't even print a test page on a postscript printer.

This is really annoying. The following page explains the background.
http://www.bsmdevelopment.com/Reference/Tech_20130002.html

Best regards,
Uwe

[Eric Schnoebelen]

Uwe Klaus writes:
- I also spent some time to get cup 1.7.3 running, but I managed to print.
- For postscript based printers I used cups-filters. The cups and the
- cups-filters package share some files, so you have to resolve PLIST
- conflicts.
-
- share/cups/banners/classified
- share/cups/banners/confidential
- share/cups/banners/secret
- share/cups/banners/standard
- share/cups/banners/topsecret
- share/cups/banners/unclassified
- share/cups/data/testprint
-
- For non postscript based printers (in my case HP Photosmart C309a) I
- installed hplip together with ghostscript-gpl and option cups enabled
- (ghostscript-agpl didn't work).
- Again ghostscript-gpl and cups-filters share some files.
-
- libexec/cups/filter/gstopxl
- libexec/cups/filter/gstoraster

I encountered all of those issues as well, and spent a bit of
time trying to resolve them. Another conflict was with
foomatic-filters{,-cups}.

I choose to rebuild ghostscript-gpl without the "cups" flag to
resolve the conflict there.

Even after all of that, I was unable to print a test page, and
trying to print a plain text file generated an error about CUPS
being unable to find a font to print with.

Needless to say, after suppressing my urge to take the relevant
server to the top of a very tall building and throw it over, I
backed down to CUPS 1.5.4nb11 via the pkgsrc-2014Q1 tree.

- > After futzing and fighting with it for most of the weekend, I
- > was unable to create a working print server. With the previous
- > version, it was working fine. Fundementally, it's *bad* when it
- > can't even print a test page on a postscript printer.
-
- This is really annoying. The following page explains the background.
- http://www.bsmdevelopment.com/Reference/Tech_20130002.html

I wish I would have found that page when I was googling
yesterday. Not that it would have changed much, I suspect.

--
Eric Schnoebelen ***@cirr.com http://www.cirr.com
Those are my principles, and if you don't like them...
well, I have others. -- Groucho Marx

[Thomas Klausner]

Post by Eric Schnoebelen
I've just spent the weekend trying to (re)create a working CUPS
print server from the recently updated (to 1.7.3) print/cups package.

I'm sorry that that proved so annoying.

Post by Eric Schnoebelen
To that end, I rolled my own CUPS print server back to the
1.5.4nb11 package that was on the -2014Q1 branch.

I've reimported cups-1.5.x as print/cups15, I hope that's sufficient.

If not, what is missing?
Thomas

[Hauke Fath]

Post by Thomas Klausner
I've reimported cups-1.5.x as print/cups15, I hope that's sufficient.

Thanks!

I guess the following would fix PR pkg/48889 for now?

Index: options.mk
===================================================================
RCS file: /cvsroot/pkgsrc/net/netatalk22/options.mk,v
retrieving revision 1.1
diff -u -p -u -r1.1 options.mk
--- options.mk 11 Jun 2014 11:03:56 -0000 1.1
+++ options.mk 17 Jun 2014 20:28:34 -0000
@@ -6,7 +6,7 @@ PKG_SUPPORTED_OPTIONS= cups debug dnssd
.include "../../mk/bsd.options.mk"

.if !empty(PKG_OPTIONS:Mcups)
-.include "../../print/cups/buildlink3.mk"
+.include "../../print/cups15/buildlink3.mk"
CONFIGURE_ARGS+= --enable-cups
.else
CONFIGURE_ARGS+= --disable-cups

Cheerio,
hauke

[Thomas Klausner]

Post by Hauke Fath

Post by Thomas Klausner
I've reimported cups-1.5.x as print/cups15, I hope that's sufficient.

Thanks!
I guess the following would fix PR pkg/48889 for now?

...

Post by Hauke Fath
.if !empty(PKG_OPTIONS:Mcups)
-.include "../../print/cups/buildlink3.mk"
+.include "../../print/cups15/buildlink3.mk"
CONFIGURE_ARGS+= --enable-cups
.else
CONFIGURE_ARGS+= --disable-cups

For netatalk22 it's definitely correct.

I'd also like to hear opinions if for this branch all cups-packages
should depend on cups15, and we switch back to cups after the branch;
or if we should have a general switch for this (i.e., mk/cups.mk which
chooses one of the two, depending on a user-setting).
Thomas

[Manuel Bouyer]

Post by Thomas Klausner

Post by Hauke Fath

Post by Thomas Klausner
I've reimported cups-1.5.x as print/cups15, I hope that's sufficient.

Thanks!
I guess the following would fix PR pkg/48889 for now?

...

Post by Hauke Fath
.if !empty(PKG_OPTIONS:Mcups)
-.include "../../print/cups/buildlink3.mk"
+.include "../../print/cups15/buildlink3.mk"
CONFIGURE_ARGS+= --enable-cups
.else
CONFIGURE_ARGS+= --disable-cups

For netatalk22 it's definitely correct.
I'd also like to hear opinions if for this branch all cups-packages
should depend on cups15, and we switch back to cups after the branch;
or if we should have a general switch for this (i.e., mk/cups.mk which
chooses one of the two, depending on a user-setting).

At last it should default to cups15 until the problems with the new cups
are fixed.

[Greg Troxel]

Post by Thomas Klausner

Post by Hauke Fath

Post by Thomas Klausner
I've reimported cups-1.5.x as print/cups15, I hope that's sufficient.

Thanks!
I guess the following would fix PR pkg/48889 for now?

...

Post by Hauke Fath
.if !empty(PKG_OPTIONS:Mcups)
-.include "../../print/cups/buildlink3.mk"
+.include "../../print/cups15/buildlink3.mk"
CONFIGURE_ARGS+= --enable-cups
.else
CONFIGURE_ARGS+= --disable-cups

For netatalk22 it's definitely correct.
I'd also like to hear opinions if for this branch all cups-packages
should depend on cups15, and we switch back to cups after the branch;
or if we should have a general switch for this (i.e., mk/cups.mk which
chooses one of the two, depending on a user-setting).

Well, really the problem is that the update to 1.7 happened when it
doesn't work well enough, and now we have cups15 which I see as the
main/normal version and cups which is the new/flaky version. It seems
1.5 is the version that should be handed to a user who doesn't
understand which one they want (or rather, people who are running 1.5
shouldn't get upgraded to 1.7).

So I would say that pring/cups should be downgraded to 1.5, and
print/cups17 could exist or it could not for the branch and it can be
brought back (as cups17) post-branch. But that's not super important,
and I can see the argument against churn.

Given the current names, I would say everything that depends on cups
should depend on print/cups15.

Post branch, I think the thing to do is for people that like cups to get
the 1.7 package and associated cups-filters packages to the point where
they work well enough that they can be recommended for general use.
When that happens, however long it takes, then the dependencies can be
flipped from print/cups15 to print/cups. THen after long enough to
make sure there aren't issues, cups15 can be removed.

I don't see any reason to go to the complexity of cups.mk. We're only
in this situation because the upgrade happened before the package really
worked, and once 1.7 and associated other packages (not clear how many
more are needed) are ok, there will be no good reason to stay with 1.5.

[Thomas Klausner]

Post by Greg Troxel
Given the current names, I would say everything that depends on cups
should depend on print/cups15.

Ok, I've switched all packages that depended on print/cups to use
print/cups15 instead, and also added an upper bound in
cups15/buildlink3.mk (<1.7) so the newer one isn't pulled in by
accident.

Post by Greg Troxel
Post branch, I think the thing to do is for people that like cups to get
the 1.7 package and associated cups-filters packages to the point where
they work well enough that they can be recommended for general use.

Please, someone who actually uses cups for printing, do that.

Thanks,
Thomas

[Eric Schnoebelen]

Thomas Klausner writes:
- On Tue, Jun 17, 2014 at 08:02:22PM -0400, Greg Troxel wrote:
- > Post branch, I think the thing to do is for people that like cups to get
- > the 1.7 package and associated cups-filters packages to the point where
- > they work well enough that they can be recommended for general use.
-
- Please, someone who actually uses cups for printing, do that.

It's on my todo list. (probably post freeze/branch.)

--
Eric Schnoebelen ***@cirr.com http://www.cirr.com

[Thomas Klausner]

Post by Eric Schnoebelen
- > Post branch, I think the thing to do is for people that like cups to get
- > the 1.7 package and associated cups-filters packages to the point where
- > they work well enough that they can be recommended for general use.
-
- Please, someone who actually uses cups for printing, do that.
It's on my todo list. (probably post freeze/branch.)

I've fixed the conflict between cups and cups-filters by stopping the
latter to install the conflicting files.

I had filed a bug report about the conflict a month ago, but didn't
get an answer yet.

https://bugs.linuxfoundation.org/show_bug.cgi?id=1222

Thomas

[Eric Schnoebelen]

Thomas Klausner writes:
- On Wed, Jun 18, 2014 at 11:22:24AM -0500, Eric Schnoebelen wrote:
- >
- > Thomas Klausner writes:
- > - On Tue, Jun 17, 2014 at 08:02:22PM -0400, Greg Troxel wrote:
- > - > Post branch, I think the thing to do is for people that
- > - > like cups to get the 1.7 package and associated cups-filters
- > - > packages to the point where they work well enough that they
- > - > can be recommended for general use.
- > -
- > - Please, someone who actually uses cups for printing, do that.
- >
- > It's on my todo list. (probably post freeze/branch.)
-
- I've fixed the conflict between cups and cups-filters by stopping the
- latter to install the conflicting files.

The fix I have in my tree (still testing) was to have
cups-filters install the conflicting files, rather than cups,
since cups can't do anything with the files with the default
filter set.

The conflicting files are:
share/cups/banners/classified
share/cups/banners/confidential
share/cups/banners/secret
share/cups/banners/standard
share/cups/banners/topsecret
share/cups/banners/unclassified
share/cups/data/testprint

- I had filed a bug report about the conflict a month ago, but didn't
- get an answer yet.
-
- https://bugs.linuxfoundation.org/show_bug.cgi?id=1222

I'm still trying to figure out why other cups systems on my
network doesn't see the printers "exported" by the master cups
print server.

--
Eric Schnoebelen ***@cirr.com http://www.cirr.com
"There's nothing as permanent as a temporary fix." -- Tom Limoncelli

[Thomas Klausner]

Post by Eric Schnoebelen
The fix I have in my tree (still testing) was to have
cups-filters install the conflicting files, rather than cups,
since cups can't do anything with the files with the default
filter set.

Ok, I've made pkgsrc go this way to. cups doesn't install them now,
only cups-filters does.

Post by Eric Schnoebelen
I'm still trying to figure out why other cups systems on my
network doesn't see the printers "exported" by the master cups
print server.

Sounds like something to do with avahi to me?
Thomas

[Eric Schnoebelen]

Thomas Klausner writes:
- On Fri, Aug 22, 2014 at 07:54:31AM -0500, Eric Schnoebelen wrote:
- > I'm still trying to figure out why other cups systems on my
- > network doesn't see the printers "exported" by the master cups
- > print server.
-
- Sounds like something to do with avahi to me?

Maybe a little bit. But I was unable to recreate the
auto-detection/importation of shared CUPS queues without installing
cups-filters. Once cups-filters (with cups-browsed) was installed,
the workstation was able to see the queues provided by the server
without any special configuration, just as it could with cups 1.5.

I'm rapidly reaching the conclusion that cups with-out cups filters
is nearly useless in an environment of networked systems sharing
a common print server.

Should we consider rolling cups-filters into cups so we keep
functionality equivalent to cups 1.5?

--
Eric Schnoebelen ***@cirr.com http://www.cirr.com
Server (n.), 1. Large, extremely expensive machine that goes "Ping!".
Measuring at least 25 cubic feet, heavy, bulky and giving of more heat
than a nuclear power plant. It's big, it's bad, it's beautiful and
makes it pretty clear what happened to this year's IT-budget.

[Thomas Klausner]

Post by Eric Schnoebelen
Maybe a little bit. But I was unable to recreate the
auto-detection/importation of shared CUPS queues without installing
cups-filters. Once cups-filters (with cups-browsed) was installed,
the workstation was able to see the queues provided by the server
without any special configuration, just as it could with cups 1.5.
I'm rapidly reaching the conclusion that cups with-out cups filters
is nearly useless in an environment of networked systems sharing
a common print server.
Should we consider rolling cups-filters into cups so we keep
functionality equivalent to cups 1.5?

I don't like that for maintenance reasons, but a meta package of
appriate name (cups-working? :) that depends on both would be ok in my
eyes.
Thomas

[Eric Schnoebelen]

Thomas Klausner writes:
- On Sat, Aug 23, 2014 at 02:42:20PM -0500, Eric Schnoebelen wrote:
- > I'm rapidly reaching the conclusion that cups with-out cups filters
- > is nearly useless in an environment of networked systems sharing
- > a common print server.
- >
- > Should we consider rolling cups-filters into cups so we keep
- > functionality equivalent to cups 1.5?
-
- I don't like that for maintenance reasons, but a meta package of
- appropriate name (cups-working? :) that depends on both would be ok
- in my eyes.

I can't say I'm fond of the idea either, but pkgsrc does have
the infrastructure to handle a package needing multiple source
tar-balls to build.

In reality, if you install cups-filters, all will work as
desired (or will after I check in the small set of changes and
clean ups in a little bit.) But in it's current naming scheme,
it's extremely non-obvious that you must have cups-filters to
have a working cups printing system.

I'd be inclined to name the meta package "cups", and have what
is currently cups built/installed as cups-server or cups-base.

Just my thoughts, which, when combined with $5, might get you
something good to drink at the neighborhood coffee house or pub.

--
Eric Schnoebelen ***@cirr.com http://www.cirr.com
Server (n.), 1. Large, extremely expensive machine that goes "Ping!".
Measuring at least 25 cubic feet, heavy, bulky and giving of more heat
than a nuclear power plant. It's big, it's bad, it's beautiful and
makes it pretty clear what happened to this year's IT-budget.

[Greg Troxel]

Post by Eric Schnoebelen
- I don't like that for maintenance reasons, but a meta package of
- appropriate name (cups-working? :) that depends on both would be ok
- in my eyes.
I can't say I'm fond of the idea either, but pkgsrc does have
the infrastructure to handle a package needing multiple source
tar-balls to build.

I think it's best to keep separate source tarballs as separate packages,
unless that is really awkward *for packaging*.

Post by Eric Schnoebelen
In reality, if you install cups-filters, all will work as
desired (or will after I check in the small set of changes and
clean ups in a little bit.) But in it's current naming scheme,
it's extremely non-obvious that you must have cups-filters to
have a working cups printing system.

Can cups just depend on cups-filters?

Post by Eric Schnoebelen
I'd be inclined to name the meta package "cups", and have what
is currently cups built/installed as cups-server or cups-base.

cups-base seems ok. I guess cups-server is accurate, but it seems that
if one wants to have a machine without a printer automatically discover
machines with printers, it feels like a client machine, even though to
be a printer client you locally run a server. Hence I don't like
cups-server.

[Richard PALO]

Post by Greg Troxel
cups-base seems ok. I guess cups-server is accurate, but it seems that
if one wants to have a machine without a printer automatically discover
machines with printers, it feels like a client machine, even though to
be a printer client you locally run a server. Hence I don't like
cups-server.

Perhaps the structure by 'ports' isn't all that bad... here's their
directory, the hierarchy is straight-forward.

cups/ cups-bjnp/ cups-cloud-print/
cups-fxlinuxprint/ cups-pdf/ cups-pstoraster/
cups-base/ cups-client/ cups-filters/ cups-image/
cups-pk-helper/ cups-smb-backend/

[Eric Schnoebelen]

Greg Troxel writes:
- ***@cirr.com (Eric Schnoebelen) writes:
- > In reality, if you install cups-filters, all will work as
- > desired (or will after I check in the small set of changes and
- > clean ups in a little bit.) But in it's current naming scheme,
- > it's extremely non-obvious that you must have cups-filters to
- > have a working cups printing system.
-
- Can cups just depend on cups-filters?

Sadly, no. cups-filters depends on the libraries that cups
installs. :( So, cups-filters depends on cups already.
Creating a circular dependency isn't going to work. (I'd hate to
see what bmake would do with that. or pbulk.)

- > I'd be inclined to name the meta package "cups", and have what
- > is currently cups built/installed as cups-server or cups-base.
-
- cups-base seems ok. I guess cups-server is accurate, but it seems that
- if one wants to have a machine without a printer automatically discover
- machines with printers, it feels like a client machine, even though to
- be a printer client you locally run a server. Hence I don't like
- cups-server.

I agree with cups-server being a poor name.

An alternative I haven't mentioned is to document that
print/cups-filter is required in the MESSAGE file. Which I don't
consider a good solution.

Is there a consensous on moving cups into print/cups-base, and
reusing print/cups as a meta package depending on print/cups and
print/cups-filters?


--
Eric Schnoebelen ***@cirr.com http://www.cirr.com
There cannot be a crisis today; my schedule is already full.

[Greg Troxel]

Post by Eric Schnoebelen
- Can cups just depend on cups-filters?
Sadly, no. cups-filters depends on the libraries that cups
installs. :( So, cups-filters depends on cups already.
Creating a circular dependency isn't going to work. (I'd hate to
see what bmake would do with that. or pbulk.)

ok - suggestion withdrawn.

I don't like using MESSAGES, in general.

Post by Eric Schnoebelen
Is there a consensous on moving cups into print/cups-base, and
reusing print/cups as a meta package depending on print/cups and
print/cups-filters?

Sounds good to me, and I haven't heard objections.