Bug#701954: new discoveries

[Till Kamppeter]

On 03/13/2013 11:53 PM, David Griffith wrote:
> 
> Regarding the problem of my prints to a Brother printer being offset, I
> found this page:
> http://selig.ws/hejdo/en/computers/linux/brother-printing.html
> 
> It describes my problems exactly.  The solution does not require
> fiddling with potentially proprietary source code, but instead a
> modifies CUPS. Trying to run this replacement cpdftocps with
> /usr/share/cups/mime/local.convs as suggested in the page doesn't work.
> In the "PostScript filters" section I see this:
> 
> application/vnd.cups-pdfapplication/vnd.cups-postscript 22 
> pdftops
> 
> This appears to be the same as what executes cpdftocps in Squeeze. 
> There seems to be some sort of cost penalty involved here that doesn't
> let this line from local.convs from working:
> 
> application/vnd.cups-pdf application/vnd.cups-postscript 11 cpdftocps-mas
> 
> So I commented out the former line and added the latter line right
> underneath.  This fixes the print alignment problem
> 
> I don't know how this can be universalized or exactly why cpdftocps was
> removed.  Does this give you enough to go on to come up with a solution?
> 

Thank you for the hint.

In current Debian (unstable/experimental) and Ubuntu cpdftocps is
replaced by a new pdftops filter (part of the cups-filters package,
maintained upstream by me) which takes over both the role of the old
pdftops filter and of the cpdftocps filter. It is written in C and by
configuration settings or print job options one can make it use either
Ghostscript or Poppler. Currently, Ghostscript is the default and so the
problem described here should not occur.

In the future I intend continuing Ghostscript for desktop and server use
but switching to Poppler for mobile devices. In this case the problem
could reappear and I would need to add the equivalent of "grep -v
'Policies 1 dict dup begin .PageSize 3 def end def'" to the pdftops filter.

Now I have tested with the current Poppler on Ubuntu Raring and found
out that instead of

Policies 1 dict dup begin .PageSize 3 def end def

I get

/Policies 1 dict dup begin /PageSize 6 def end def

and I am in doubt of whether I have to remove this now to get compatible
with Brother printers. So I want to ask you to do some testing:

1. On Ubuntu Raring (you can boot it with a live CD) or Debian
Experimental try

a. Set up your printer and print normally. Does it work?

b. Make sure your print queue uses your Brother printer in PostScript
mode. Correct the queue's configuration if needed and re-test.

c. Print a job with the command line

lp -d  -o pdftops-renderer=pdftops 

Does it still work correctly?

2. In your normal environment do the following:

pdftops 

This produces a PS file containing the line

/Policies 1 dict dup begin .PageSize 3 def end def

Replace the line by

/Policies 1 dict dup begin /PageSize 6 def end def

with a text editor. Replace all occurences of the line.

Then print the file unfiltered:

lp -o raw 

Does it come out correctly?

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5141a14b.9040...@gmail.com

Bug#711169: cups-daemon: ipp printer browsing support removed

[Till Kamppeter]

Thank you very much for the bug report and the patch.

The hard switchover from IPP-only broadcasting to Bonjour-only
broadcasting on the transition from CUPS 1.5.x to 1.6.x is really bad.

cups-browsed is indeed the only solution to get Bonjour browsing to
conserve the configuration-less client feature in CUPS 1.6.x environment
and CUPS broadcasting/browsing to get compatibility between CUPS 1.5.x
and 1.6.x.

Your patch is a first step to inform users about the need of
cups-browsed. Suggestion to improve it: Explicitly mention that the
configuration settings have to be done in /etc/cups/cups-browsed.conf.

I am also thinking about letting cups-browsed at least listen to the old
IPP broadcasts ("BrowseRemoteProtocols cups"), so that new clients work
with old servers out of the box but the network does not get flooded
with broadcasts of an obsolete format by cups-browsed. WDYT?

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51af1c68.6040...@gmail.com

Bug#712237: cups-server-common: The cost factor for pstops

[Till Kamppeter]

The old cost factor (65) I had introduced to overcome an ugliness in the
PDF-based printing workflow.

If the cost factor is 66 and an app sends a PostScript input file and
the printer is PostScript (or some old-fashioned driver insisting on
PostScript input is used), I got

PostScript -> pstopdf -> PDF -> pdftopdf -> PDF -> pdftops -> PostScript

a detour of PostScript being converted to PDF and back to PostScript
which happened sometimes because some apps (like emacs) did not switch
over to the PDF-based printing workflow sending out print data in PDF.

This principally works but causes delays (and even failures) due to
unneeded CPU- and meomory-intensive re-rendering and also sometimes font
problems as in bug #712015.

So I created a bypass for this situation by using the 65 cost factor
resulting in

PostScript -> pstops -> PostScript

This worked well until CUPS 1.6.x came up where this workaround caused
"make test" to fail and so the build of the Debian and Ubuntu packages.
Therefore we reverted to 66.

The best would be getting all apps sending PDF (and cups-pdf accepting
PDF), but as this will probably take years (and there are also apps in
use which are not maintained any more), we should better fix the "make
test" so that the tests pass also with the 65 cost factor or modifying
the filter workflow generally does not break the tests.

   Till


On 06/14/2013 01:12 PM, Brian Potkin wrote:
> Package: cups-server-common
> Version: 1.6.2-8
> Severity: normal
> 
> 
> In /usr/share/cups/mime/mime.convs there is
> 
>application/postscript  application/vnd.cups-postscript 66  
> pstops
> 
> In cups 1.5.x we have
> 
>application/postscript  application/vnd.cups-postscript 65  
> pstops
> 
> Unless it is intended to alter the work flow for all PostScript documents
> I'd consider this is a bug. There is nothing obvious in the changelog
> to account for the change. (But it not unknown for the significance of
> something to pass me by :) ).
> 
> Regards,
> 
> Brian.
> 
> 
> 
> 
> -- System Information:
> Debian Release: 7.0
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51bb23bf.8040...@gmail.com

Bug#712015: cups-filters: cups-pdf produces ugly pdfs through its pixelated font

[Till Kamppeter]

I have written more about the cost factor and its motivations in bug
#712237 now.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51bb23ff.9050...@gmail.com

Re: driver for "Epson AcuLaser C1100" convert this to x64 (amd64) please

[Till Kamppeter]

This is a closed-source driver, the package does not contain any source
code. AFAIK there are no methods to convert 32-bit binary executables to
64-bit.

   Till

On 06/15/2013 11:20 AM, DutchGlory wrote:
> I have printer driver here for "Epson AcuLaser C1100" if someone is able to 
> convert this to x64... (amd64) 
> i'll (and many others) be *MORE* than happy :) 
> 
> Epson AL C1100 (x68) source - filter - filter cups.tar.gz
>   
> 
> Thank you...
> André
> 
> 
> 
> -
> 
> DutchGlory 
> My Opensim/Second Life Blog 
> http://verwijs.wordpress.com 
> (Dutch, basic hardware/software help  windows, Mac, Linux) 
> http://verwijs-pc.nl 
> My Twitter Page: 
> http://twitter.com/OpenSimFan 
> My Facebook page (be my friend, please ) 
> http://www.facebook.com/andre.verwijs 
> --
> View this message in context: 
> http://debian.2.n7.nabble.com/driver-for-Epson-AcuLaser-C1100-convert-this-to-x64-amd64-please-tp2976161.html
> Sent from the debian-printing mailing list archive at Nabble.com.
> 
> 


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51bc3740.8030...@gmail.com

Bug#712045: ghostscript-cups: colord icc profile not applied

[Till Kamppeter]

I have applied the two patches now in Ghostscript's upstream GIT
repository, commit #1b87b820.

Thank you very much for the bug report and the patches.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c1abe7.8070...@gmail.com

Bug#712045: ghostscript-cups: colord icc profile not applied

[Till Kamppeter]

pplied this fix, too. Thank you very much.

Commit: 1149c245e

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c1b1f6.5010...@gmail.com

Bug#682426: cups: filter gs takes several minutes consuming 100 % of CPU

[Till Kamppeter]

The problem is indeed Cairo, which creates a full-page transparency
layer even for small images. This happens also very often when printing
PDFs with evince, as evince re-renders the output with Cairo instead of
passing the input PDF through.

There are already upstream bug reports on Cairo. Perhaps you should
comment there.

This bug report should be moved to Cairo.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c231f5.3020...@gmail.com

Bug#712949: cups-filters’ pdftops filter refuses to output PostScipt LanguageLevel 3

[Till Kamppeter]

Fixed in upstream BZR repo of cups-filters, rev. 7069.

Now generally PS level 3 is sent if the PPD identifies the printer as PS
level 3. There is an exception rule of HP's lasers getting PS level 2 in
such a case.

   Till


On 06/21/2013 08:22 AM, cl...@jhcloos.com wrote:
> Package: cups-filters
> Version: 1.0.34-3
> Severity: important
> Tags: upstream
> 
> [Bastien asked me to report this an an important bug. -JimC]
> 
> Revision 6868 of upstream cups-filters bzr introduced code to prevent pdftops
> from generating level3 postscript.  Ever.
> 
> Ubuntu bug https://bugs.launchpad.net/bugs/277404
> and poppler bug https://bugs.freedesktop.org/show_bug.cgi?id=19640
> 
> are referenced in the commit.
> 
> Certain HP printers were unable to handle the level3 postscript
> generated by poppler’s (and probably xpdf’s) pdftops(1), which can be
> used by the cups-filters pdftops filter.  The problem seems to be
> specific to CID-keyed fonts.
> 
> HP refused to change their PPDs, which advertize level3 support, on
> the grounds that the level3 ps generated by apple’s osx worked fine.
> 
> cups-filters should not limit itself to generating level1 and level2;
> instead the PPD files for the affected HP printers should be edited
> to specify level2.
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> 


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c4ce41.9050...@gmail.com

Bug#712015: cups-filters: cups-pdf produces ugly pdfs through its pixelated font

[Till Kamppeter]

On 06/20/2013 07:16 PM, James Cloos wrote:
> With the cups-filters pacakge, that won't help.
> 
> Ubuntu pushed a change into that package upstream which limits all
> output of the pdftops filter to LanguageLevel2 (or lower) due to a
> bug with one HP printer.  Which breaks the filter for everyone else.
> See the comment in the src.

This is only true if cups-filters is using the Poppler pdftops utility,
if Ghostscript is used (and this is the default in Ubuntu and also
upstream), level 3 PostScript is generated if the PPD requests it.

Bastien, so you can try 'LanguageLevel : "3"' in the PPD, but make sure
that the pdftops filter uses Ghostscrpt.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c5bc80.1000...@gmail.com

Bug#712719: Your workaround worked!

[Till Kamppeter]

On 06/22/2013 11:00 PM, NetCat wrote:
> Hello
> 
> mv /usr/lib/cups/backend/ipp /usr/lib/cups/backend/ipp-orig
> cp /usr/lib/cups/backend/ipp14 /usr/lib/cups/backend/ipp
> 
> It works. I can print from both machines again.
> What means that something went wrong with the ipp in Wheezy.
> 
> Thank you very much for your perfect support,
> Adrian.

The IPP backend "ipp" of CUPS 1.5.x and newer got some changes by
upstream to make it conforming better with the IPP standards, fixing
several other problems.

Unfortunately, some old (incompatible? buggy?) printers and print server
boxes failed with the new IPP backend. So I decided to carry on the old
backend as "ipp14" in the Debian and Ubuntu package of CUPS 1.5.x and
newer. The backend is exactly the one of the last CUPS 1.4.x release.

You do not really need to rename the backends, you should even avoid
renaming them, as with the next update of the CUPS package the renaming
gets undone.

Please undo the renaming or reinstall the cups package and then chgange
the URI of you queue pointing to the NAS from "ipp://..." to "ipp14://...".

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c6162f.7090...@gmail.com

Re: Bug#712237: cups-server-common: The cost factor for pstops

[Till Kamppeter]

I have now changed the cost factors of the filters which come with the
cups-filters package (in the upstream BZR repository, will be part of
cups-filters 1.0.35).

Now the cost factor of pstops in CUPS can stay 66, so the upstream
default does not need to be changed and with the new cost factors in
cups-filters awkward workflows like pstopdf->pdftopdf->pdftops or
pstopdf->pdftopdf->gstoraster are replaced by the simpler workflows
pstops or pstops->gstoraster, avoiding duplicate rendering.

If the input format is PDF nothing changes.

See also

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

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51ca12c9.3060...@gmail.com

Bug#714460: cups-browsed: A man page for cups-browsed

[Till Kamppeter]

On 06/29/2013 05:56 PM, Brian Potkin wrote:
> ... or forward upstream, if they are of use.

I am the upstream maintainer of cups-filters and I am also reading the
printing-related Debian bug reports.

Thank you very much for contributing the man pages.

I have now added them to the upstream BZR repository of cups-filters, so
they get included from release 1.0.36 on. I have also done the needed
additions to Makefile.am so that the pages get installed by "make
install" and get included in the upstream tarballs by "make dist".

> A review and additions/ammendments would be appreciated.

The man pages are correct, I only updated the default for
BrowseRemoteProtocols to "dnssd cups" to reflect the change in
cups-filters 1.0.35.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51d149c8.5000...@gmail.com

Bug#716842: cups-filters: please compile with support for using acroread as pdftops-renderer

[Till Kamppeter]

I have fixed this in cups-filters upstream now. If a renderer
(Ghostscript, Poppler, Adobe Reader) is not installed, its executable
path(s) are set to the executable name. With execv() replaced by
execvp() in pdftops.c, the renderer will also work when only installed
at run time, also when the executable happens to be in /usr/local/bin/.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e94e60.5000...@gmail.com

Bug#711229: leak

[Till Kamppeter]

On 07/24/2013 08:10 PM, Jim Paris wrote:
> Maybe the cups-browsed leak is related to:
>   https://bugzilla.redhat.com/show_bug.cgi?id=959682
> 
> I can't figure out how to see what their fix was, though.
> 
> -jim
> 
> 

See also the upstream bug

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

and Ubuntu bug

https://bugs.launchpad.net/bugs/1203276

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51f02253.50...@gmail.com

Merging of ghostscript-cups into cups-filters

[Till Kamppeter]

Hi,

first, sorry for making a broken commit into the CUPS GIT repository. I
have simply overtaken a patch from a co-worker. I have fixed this patch
now, removing the Ubuntu defaults, adding the missing patch and making
the patch Ubuntu-only, as it is a temporary override of a failing test
which prevents CUPS from building under Ubuntu. The Recommends: on
ghostscript-cups I have now replace by a The Recommends: on cups-filters
1.0.36 OR ghostscript-cups. The ghostscript-cups in Suggests: I have
removed as it is already in Recommends:.


I did the following change upstream:

To make maintaining the CUPS filters easier and due to the fact that
gstoraster depends on libcupsfilters now, I have moved all CUPS filters
which come with Ghostscript (in the cups/ directory of the Ghostscript
source) into the cups-filters package. The cups/ directory contains only
the files for building the "cups" output device of Ghostscript now.

This I have done in the upstream versions 9.08 of Ghostscript and 1.0.36
of cups-filters.

I have also made the needed changes in the packaging in Ubuntu:

ghostscript
 - Removed the ghostscript-cups binary package.

cups-filters
 - cups-filters binary package gets
   "Provides/Conflicts/Replaces: ghostscript-cups"
 - Removed from cups-filters binary package:
   "Recommends/Breaks: ghostscript-cups (versioned)"

printer-driver-..., lsb, ...
 - Replaced "Depends: ghostscript-cups" by
   "Depends: cups-filters (>= 1.0.36) | ghostscript-cups"
 - Same for "Recommends: ...".

These changes should allow a smooth transition:

- The "Depends: cups-filters (>= 1.0.36) | ghostscript-cups" allows to
  update the driver package before cups-filters gets updated to 1.0.36
  or newer.
- cups-filters 1.0.36 or newer removes ghostscript-cups, replacing
  gstoraster by its own upstream-up-to-date and backward-compatible
  version. This works also with older Ghostscript packages which still
  contain ghostscript-cups.
- As ghostscript 9.08 and newer does not ship ghostscript-cups any more,
  this update can only be done when cups-filters 1.0.36 is uploaded.

Can you please do this transition in Debian, preferably by back-merging
the Ubuntu changes? The BZR repo of cups-filters is already
appropriately and the GIT repo of CUPS are already updated. So mainly
the printer driver packages and the lsb package need to get updated. See
also

https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1212012

for a patch for lsb.

Please also do needed changes in README.Debian files if necessary.

Thanks in advance.

   Till



-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/521727ea.5070...@gmail.com

Ghostscript 9.09 released upstream, Debian on 9.05

[Till Kamppeter]

Hi,

is Ghostscript in Debian still maintained? Or is there anything in
Ghostscript 9.06 and newer which does not allow its use in Debian? If so
please tell the problem or report it directly upstream (and please post
the upstream bug links here). If Ghostscript as it is now is not
suitable for Debian any more, should we consider switching over to Poppler?

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52173e04.6090...@gmail.com

Re: Ghostscript 9.09 released upstream, Debian on 9.05

[Till Kamppeter]

Jonas, thank you for the info.

GS 9.09 builds (at least under Ubuntu) with all libraries taken from the
system, no convenience code is used any more. But I do not know whether
all of these libraries are actually available in Debian or whether there
are some being newer in Ubuntu than in Debian or not in Debian at all,
as I did not package these libraries for Ubuntu.

I have packages GS 9.09 for Ubuntu with a ~dfsg source tarball not
containing any of the convenience library code copies. There are also no
source code patches (only some build system patches which most probably
are known to you).

You can find the package and the source tarball for backmerging to Debian on

https://launchpad.net/ubuntu/+source/ghostscript/9.09~dfsg-0ubuntu1

   Till

On 08/23/2013 01:23 PM, Jonas Smedegaard wrote:
> Quoting Till Kamppeter (2013-08-23 12:48:36)
>> is Ghostscript in Debian still maintained?
> 
> Yes.
> 
> 
>> Or is there anything in Ghostscript 9.06 and newer which does not 
>> allow its use in Debian? If so please tell the problem or report it 
>> directly upstream (and please post the upstream bug links here).
> 
> Recent Ghostscript releases depend on patches to liblcms which has not 
> yet entered Debian (see bug#701993).  This is not a bug upstream, as the 
> Ghostscript project choose to include convenience copies of code, 
> something which strongly discouraged in Debian, as it (among other 
> things) hurts security maintenance.
> 
> (sorry - I thought you were already well aware of all these details, 
> Till)
> 
> 
>> If Ghostscript as it is now is not suitable for Debian any more, 
>> should we consider switching over to Poppler?
> 
> Not sure what you mean by that.  Poppler is used by parts of Debian, and 
> Ghostscript is used by other parts of Debian.
> 
> If upstreams would like to consider switching between them, they are 
> free to do so.
> 
> For the (few, I suspect) upstream projects supporting both and therefore 
> leaving Debian with a choice, I guess Poppler is generally preferred 
> already - but I might be wrong, and it would be good to base such 
> choices on concrete analysis, because both projects are alive and well.
> 
> 
>  - Jonas
> 


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52174f3b.20...@gmail.com

Re: Ghostscript 9.09 released upstream, Debian on 9.05

[Till Kamppeter]

On 08/25/2013 08:16 PM, Jonas Smedegaard wrote:
> Quoting Till Kamppeter (2013-08-23 14:02:03)
>> GS 9.09 builds (at least under Ubuntu) with all libraries taken from 
>> the system, no convenience code is used any more. But I do not know 
>> whether all of these libraries are actually available in Debian or 
>> whether there are some being newer in Ubuntu than in Debian or not in 
>> Debian at all, as I did not package these libraries for Ubuntu.
>>
>> I have packages GS 9.09 for Ubuntu with a ~dfsg source tarball not 
>> containing any of the convenience library code copies. There are also 
>> no source code patches (only some build system patches which most 
>> probably are known to you).
>>
>> You can find the package and the source tarball for backmerging to 
>> Debian on
>>
>> https://launchpad.net/ubuntu/+source/ghostscript/9.09~dfsg-0ubuntu1
> 
> You write above that Ghostscript 9.09 builds on Ubuntu.
> 
> I am quite interested in learning which versions of libraries you have 
> succesfully build against, but fail to locate _succesful_ build logs 
> from Ubuntu (but found a few failing ones - missing build-dependency).
> 
> Could you perhaps provide me a URL to a succesful build log?

I have built it on my local machine running a fully up-to-date Saucy.
The build server is not able to build it because the libopenjpeg package
is not in Ubuntu Main, but only in Universe. It is in the process to be
transferred to Main, but this takes longer than expected.

See

https://bugs.launchpad.net/ubuntu/+source/openjpeg/+bug/711061

Currently, this transfer is on the TODO list of a security guy at Canonical.

The previous Ghostscript versions in Ubuntu (9.06 and 9.07) used the
libopenjpeg coming with Ghostscript, as the GS developers have added API
s which did not make it into upstream libopenjpeg that time.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/521a4e8b.1080...@gmail.com

Re: Ghostscript 9.09 released upstream, Debian on 9.05

[Till Kamppeter]

On 08/25/2013 09:10 PM, Jonas Smedegaard wrote:
> Quoting Till Kamppeter (2013-08-25 20:35:55)
>> On 08/25/2013 08:16 PM, Jonas Smedegaard wrote:
>>> Quoting Till Kamppeter (2013-08-23 14:02:03)
>>>> GS 9.09 builds (at least under Ubuntu) with all libraries taken 
>>>> from the system, no convenience code is used any more. But I do not 
>>>> know whether all of these libraries are actually available in 
>>>> Debian or whether there are some being newer in Ubuntu than in 
>>>> Debian or not in Debian at all, as I did not package these 
>>>> libraries for Ubuntu.
>>>>
>>>> I have packages GS 9.09 for Ubuntu with a ~dfsg source tarball not 
>>>> containing any of the convenience library code copies. There are 
>>>> also no source code patches (only some build system patches which 
>>>> most probably are known to you).
>>>>
>>>> You can find the package and the source tarball for backmerging to 
>>>> Debian on
>>>>
>>>> https://launchpad.net/ubuntu/+source/ghostscript/9.09~dfsg-0ubuntu1
>>>
>>> You write above that Ghostscript 9.09 builds on Ubuntu.
>>>
>>> I am quite interested in learning which versions of libraries you 
>>> have succesfully build against, but fail to locate _succesful_ build 
>>> logs from Ubuntu (but found a few failing ones - missing 
>>> build-dependency).
>>>
>>> Could you perhaps provide me a URL to a succesful build log?
>>
>> I have built it on my local machine running a fully up-to-date Saucy. 
>> The build server is not able to build it because the libopenjpeg 
>> package is not in Ubuntu Main, but only in Universe. It is in the 
>> process to be transferred to Main, but this takes longer than 
>> expected.
> 
> Yes, I am aware of the libopenjpeg issue.  Specifically I was curious 
> about the verison of liblcms2-dev, but might have interest also in other 
> dependencies - that's why I generally asked for a build log.
> 
> 
>  - Jonas
> 

liblcm2 is version 2.5.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/521a5958.4070...@gmail.com

pyppd fix

[Till Kamppeter]

Hi,

I have fixed the problem of pyppd that the compressed PPD archive
contains more than one entry per PPD file even if the PPD is not for
several different printer models. See upstream bug report

https://github.com/vitorbaptista/pyppd/issues/1

Please back-sync my current Ubuntu package to Debian and then make
no-change rebuilds of all Debian packages which use pyppd. Get my Ubuntu
package here:

https://launchpad.net/ubuntu/+source/pyppd/1.0.0-3ubuntu1

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5224de1e.9000...@gmail.com

Bug#723719: ghostscript: New Upstream Version 9.10 available

[Till Kamppeter]

I have already packaged GS 9.10 for Ubuntu, so it only needs to get
back-synced to Debian.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/523aa0d8.7060...@gmail.com

Released cups-filters 1.0.42, updated Debian package BZR

[Till Kamppeter]

Hi,

I have released cups-filters 1.0.42, and updated the Debian package BZR
appropriately, but there is still a small problem:

cups-filters 1.0.42 incorporates foomatic-rip and makes the
foomatic-filters package obsolete. Therefore I have added
"Conflicts/Replaces/Provides: foomatic-filters" for the cups-filters
binary package in debian/control, so that apt-get uninstalls
foomatic-filters when installing the new cups-filters package. This does
not work completely, as the packages with versioned dependency on
foomatic-filters are not satisfied by the Provides in cups-filters,
probably due to the much lower upstream version number of cups-filters.

The offending packages are

 printer-driver-m2300w depends on foomatic-filters (>= 4.0.0~bzr156).
 foomatic-db-engine depends on foomatic-filters (>= 4.0).
 printer-driver-pxljr depends on foomatic-filters (>= 4.0.0~bzr156).

How should I proceed?

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/529921b3.8020...@gmail.com

Landscape printing problem is bug in Poppler not cups-filters

[Till Kamppeter]

Hi,

recently, you have applied a patch to Debian's cups-filters package to
solve a problem of printing Landscape-oriented pages. The bug report and
the origin of the patch is

https://bugzilla.redhat.com/show_bug.cgi?id=768811

The patch is only a workaround for a bug in Poppler, in the
implementation of the "-origpagesizes" option of the pdftops utility of
Poppler. THe patch for cups-filters simply drops the broken
"-origpagesizes" option, making printing of documents with varying page
sizes not working any more.

I have fixed Poppler now. See

https://bugs.freedesktop.org/show_bug.cgi?id=72312

and as with this "-origpagesizes" is working correctly now I have
changed the pdftops call in cups-filters to always use "-origpagesizes"
when the CUPS job is not sent with "-o fitplot" or "-o fit-to-page".

So please use my patch from the Poppler bug report in Debian's Poppler
package and use the cups-filters pdftops filter as of BZR rev. 7131 in
Debian.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/529f493d.90...@canonical.com

Re: Released cups-filters 1.0.42, updated Debian package BZR

[Till Kamppeter]

On 12/05/2013 09:11 PM, Didier 'OdyX' Raboud wrote:
> The usual procedure is to file bugs against the affected packages, if 
> possible with a tested patch. In this specific case, as all three 
> packages are under the Debian Printing umbrella, we could just go ahead 
> with fixing and uploading these packages.
>

They should depend on "cups-filters | foomatic-filters (>= 4.0...)".

> That said, as far as I saw, none of the files shipped by foomatic-
> filters are shipped in cups-filters 1.0.42, right? How will packages 
> automagically use cups-filters instead of foomatic-filters?

The relevant file in cups-filters is /usr/lib/cups/filters/foomatic-rip.
If it is missing in the Debian package, debian/cups-filters.install
needs to get corrected.

   Till



-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52a0e744.60...@gmail.com

Bug#729713: libcups2: fails to fetch ppd of ipp:// device

[Till Kamppeter]

On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote:
> Control: tags -1 +moreinfo 
> 
> Hi Lionel and Wolfgang,
> hi Till,
> 
> thanks for your detailed bugreports and proposed patch.
> 
> Le samedi, 16 novembre 2013, 05.34:09 Lionel Elie Mamane a écrit :
>> Let FOO be a printer configured in CUPS with an
>> ipp://foo.localdomain.tld/something device uri.
>> Mine is a Konica Minolto C353.
>>
>> All cups clients fail to show printing options.
>>
>> "lpoptions -d FOO -l" says:
>>  lpoptions: Unable to get PPD file for FOO: Not Found
>>
>> A wireshark shows a request for http://device_ip:631/ipp.ppd,
>> to which the printer replies by a 404.
>>
>> The attached patch disables that undesirable behaviour, which is new
>> in 1.6 (did not happen in 1.5).
> 
> Your proposed patch is functionally equivalent to disabling the get-ppd-
> file-for-statically-configured-ipp-shared-queues.patch , which was 
> introduced in 1.6.1-1 as a backport from upstream's fix for 
> http://cups.org/str.php?L4178
> 
> Till, as you wrote this patch, what do you think about this?
> 
> Apparently, http://cups.org/str.php?L4159 was related to this problem 
> and got solved differently in 1.6.2, and now cups/util.c appears to be 
> redundant around this codeblock.
> 
> Till, can we remove this patch on all versions > 1.6.2 ?
> 

Important is to check whether if you create a raw IPP queue pointing to
a CUPS queue on a remote server that you get access to the options on
the client (means that the client loads the PPD from the server). Please
test this.

You can test by creating an arbitrary print queue with PPD on one
machine (the server) and sharing it. On another machine (the client) you
either create a raw ipp: or ipps: queue pointing to the queue on the
server or you run cups-browsed (which creates such a queue
automatically). If you print out of a GUI app on the client using the
ipp/ipps queue pointing to the CUPS server you should see the PPD
options in the print dialog. You should also run "lpoptions -p 
-l" on the client and should see the options if  is an ipp/ipps
queue pointing to the server and no error message if  is
pointing to a native IPP printer.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52c94c2f.3030...@gmail.com

Bug#729713: libcups2: fails to fetch ppd of ipp:// device

[Till Kamppeter]

On 01/05/2014 01:23 PM, Didier 'OdyX' Raboud wrote:
> Hi Till,
> 
> Le dimanche, 5 janvier 2014, 13.12:31 Till Kamppeter a écrit :
>> On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote:
>>> Your proposed patch is functionally equivalent to disabling the
>>> get-ppd- file-for-statically-configured-ipp-shared-queues.patch ,
>>> which was introduced in 1.6.1-1 as a backport from upstream's fix
>>> for http://cups.org/str.php?L4178
>>>
>>> Till, as you wrote this patch, what do you think about this?
>>>
>>> Apparently, http://cups.org/str.php?L4159 was related to this
>>> problem
>>> and got solved differently in 1.6.2, and now cups/util.c appears to
>>> be redundant around this codeblock.
>>>
>>> Till, can we remove this patch on all versions > 1.6.2 ?
>>  
>> Important is to check whether if you create a raw IPP queue pointing
>> to a CUPS queue on a remote server that you get access to the options
>> on the client (means that the client loads the PPD from the server).
>> Please test this.
> 
> Actually, what I'm saying is that the patch adds a redundant block. See 
> the attached abstract from util.c. In my reading, lines 26 to 41 (added 
> by the patch) is redundant with lines 6 to 25 (upstream code).
> 
> From that, I tend to think the patch can be safely removed, no?
> 
> Cheers,
> 
> OdyX
> 
OK, you are right, patch can be removed.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52c9502b.6060...@gmail.com

Bug#729713: libcups2: fails to fetch ppd of ipp:// device

[Till Kamppeter]

On 01/05/2014 01:36 PM, Wolfgang Walter wrote:
> On Sunday 05 January 2014 13:12:31 Till Kamppeter wrote:
>> On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote:
>>> Control: tags -1 +moreinfo
>>>
>>> Hi Lionel and Wolfgang,
>>> hi Till,
>>>
>>> thanks for your detailed bugreports and proposed patch.
>>>
>>> Le samedi, 16 novembre 2013, 05.34:09 Lionel Elie Mamane a écrit :
>>>> Let FOO be a printer configured in CUPS with an
>>>> ipp://foo.localdomain.tld/something device uri.
>>>> Mine is a Konica Minolto C353.
>>>>
>>>> All cups clients fail to show printing options.
>>>>
>>>> "lpoptions -d FOO -l" says:
>>>>  lpoptions: Unable to get PPD file for FOO: Not Found
>>>>
>>>> A wireshark shows a request for http://device_ip:631/ipp.ppd,
>>>> to which the printer replies by a 404.
>>>>
>>>> The attached patch disables that undesirable behaviour, which is new
>>>> in 1.6 (did not happen in 1.5).
>>>
>>> Your proposed patch is functionally equivalent to disabling the get-ppd-
>>> file-for-statically-configured-ipp-shared-queues.patch , which was
>>> introduced in 1.6.1-1 as a backport from upstream's fix for
>>> http://cups.org/str.php?L4178
>>>
>>> Till, as you wrote this patch, what do you think about this?
>>>
>>> Apparently, http://cups.org/str.php?L4159 was related to this problem
>>> and got solved differently in 1.6.2, and now cups/util.c appears to be
>>> redundant around this codeblock.
>>>
>>> Till, can we remove this patch on all versions > 1.6.2 ?
>>
>> Important is to check whether if you create a raw IPP queue pointing to
>> a CUPS queue on a remote server that you get access to the options on
>> the client (means that the client loads the PPD from the server). Please
>> test this.
>>
>> You can test by creating an arbitrary print queue with PPD on one
>> machine (the server) and sharing it. On another machine (the client) you
>> either create a raw ipp: or ipps: queue pointing to the queue on the
>> server or you run cups-browsed (which creates such a queue
>> automatically). If you print out of a GUI app on the client using the
>> ipp/ipps queue pointing to the CUPS server you should see the PPD
>> options in the print dialog. You should also run "lpoptions -p 
>> -l" on the client and should see the options if  is an ipp/ipps
>> queue pointing to the server and no error message if  is
>> pointing to a native IPP printer.
>>
>>Till
> 
> We do not have a cups-server running on the client. Our configuration is:
> 
> client: only
> /etc/cups/client.conf with
> ServerName cups.localdomain.tld.
> 
> On the print server cups.localdomain.tld. we have a lot of printers in 
> printers.conf like that
> 
> 
> AuthInfoRequired none
> Info Mehltau
> Location Rosenstraße
> MakeModel MyFavoritePostscripPrinterModel
> DeviceURI ipp://mehltau.drucker.localdomain.tld/ipp
> State Idle
> StateTime 1387541234
> Type 8425548
> Filter application/vnd.cups-raw 0 -
> Filter application/vnd.cups-command 0 commandtops
> Filter application/vnd.cups-postscript 0 -
> Accepting Yes
> Shared Yes
> JobSheets none none
> QuotaPeriod 0
> PageLimit 0
> KLimit 0
> OpPolicy default
> ErrorPolicy abort-job
> 
> 
> We do not wan't to mehltau to be a raw-printer as the printer server should 
> e.g. handle pdfs etc.
> 
> This setting breaks with cups 1.6. as now the client contacts 
> cups.localdomain.tld but then tries to get the ppd from 
> mehltau.drucker.localdomain.tld instead from cups.localdomain.tld
> 
> But mehltau.drucker.localdomain.tld is a ipp postscript printer (e.g. from HP 
> or any other vendor) and does not provide ppds (and in our case the client is 
> not even allowed to communicate with Mehltau directly).
> 
> Regards,
> 

My patch did

httpSeparateURI(HTTP_URI_CODING_ALL,
  device_uri,
  scheme, sizeof(scheme), username,sizeof(username),
  host, hostsize, port, resource, resourcesize);

whereas the final fix does

httpSeparateURI(HTTP_URI_CODING_ALL,
  _httpResolveURI(device_uri, uri, sizeof(uri),
  _HTTP_RESOLVE_DEFAULT, NULL,NULL),
  scheme, sizeof(scheme), username,sizeof(username),
  host, hostsize, port, resource, resourcesize);

Can it be that the _httpResolveURI() causes some problem here?

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52c9546d.3060...@gmail.com

Splitting foo2zjs

[Till Kamppeter]

OdyX, you have split foo2zjs into printer-driver-foo2zjs and
printer-driver-foo2zjs-common telling that you want all arch-independent
files being shared across architectures. This saves some disk space in
the build server infrastructure (there should be plenty of disk space)
and on the user side it is probably without any benefit as nowadays no
one shares a system disk partition between several computers (which can
be of different architectures). So for me it looks like that it makes
building and updating more complicated without real benefit. Or what are
the real advantages?

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52cd398c.4000...@gmail.com

Re: Splitting foo2zjs

[Till Kamppeter]

On 01/08/2014 12:59 PM, Jonas Smedegaard wrote:
> Quoting Till Kamppeter (2014-01-08 12:42:04)
>> OdyX, you have split foo2zjs into printer-driver-foo2zjs and 
>> printer-driver-foo2zjs-common telling that you want all 
>> arch-independent files being shared across architectures. This saves 
>> some disk space in the build server infrastructure (there should be 
>> plenty of disk space) and on the user side it is probably without any 
>> benefit as nowadays no one shares a system disk partition between 
>> several computers (which can be of different architectures). So for me 
>> it looks like that it makes building and updating more complicated 
>> without real benefit. Or what are the real advantages?
> 
> Just guessing here, but I believe that if aiming for multiarch 
> compatibility, arch-independent parts need to be shipped as a separate 
> package (or code patched to look in unusual locations for its data 
> files.
> 

Do we need multi-arch for packages which are not a library?

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52cd3eb6.4060...@gmail.com

Re: Splitting foo2zjs

[Till Kamppeter]

Thank you very much for the info, no problem with the split.

   Till

On 01/08/2014 01:33 PM, Didier 'OdyX' Raboud wrote:
> Hi Till,
> 
> Thanks for rising this question.
> 
> Le mercredi, 8 janvier 2014, 12.42:04 Till Kamppeter a écrit :
>> OdyX, you have split foo2zjs into printer-driver-foo2zjs and
>> printer-driver-foo2zjs-common telling that you want all
>> arch-independent files being shared across architectures. This saves
>> some disk space in the build server infrastructure (there should be
>> plenty of disk space)
> 
> This was triggered by the arch-dep-package-has-big-usr-share lintian 
> informational tag:
> 
> http://lintian.debian.org/tags/arch-dep-package-has-big-usr-share.html
> 
> Where it saves the most is on the mirrors, especially on Debian, as we 
> currently have 13 architectures. The saving (although not huge) is of 
> ~400 kB per package, for a new package of ~520 kB, altogether a ~4.6Mb 
> saving.
> 
> I agree it's not immense, but it's a small move in the direction of 
> containing the continuous archive grow.
> 
> (Also, it's probably worth mentioning that this change went through the 
> NEW queue, so the FTP-Masters had to acknowledge that change…)
> 
>> and on the user side it is probably without any benefit as nowadays no
>> one shares a system disk partition between several computers (which
>> can be of different architectures).
> 
> Well, it's without downsides either as far as I can tell, no? The update 
> should be fully transparent for all users, no?
> 
>> So for me it looks like that it makes building and updating more
>> complicated without real benefit. Or what are the real advantages?
> 
> Well, I can agree that src:foo2zjs became a little more complicated to 
> maintain, but it's really not a burden, as far as I'm concerned… (Fixing 
> the manpages or the build-system were way more cumbersome to do fwiw.)
> 
> That said, if you have serious reasons to revert that, I'd happily hear 
> them…
> 
> Cheers,
> 
> OdyX
> 


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52cd4638.8090...@gmail.com

Re: Splitting foo2zjs

[Till Kamppeter]

OdyX, a small correction needs to be done:

You package splitting has replaced

/usr/lib/cups/driver/foo2zjs

by

/usr/lib/cups/driver/foo2zjs-common

leading to "lpinfo -m" listing the foo2zjs PPDs with
"foo2zjs-common:..." instead of "foo2zjs: ...". This makes the PPD
updater not matching the entries any more.

So you either need to rename the PPD generator back to

/usr/lib/cups/driver/foo2zjs

or change the file

debian/printer-driver-foo2zjs.ppd-updater

from

DRIVER_REGEXP='^foo2zjs:'
GENNICKNAME_REGEXP='s/-z\d\b//'

to

DRIVER_REGEXP='^foo2zjs-common:'
GENNICKNAME_REGEXP='s/-z\d\b//'

Otherwise PPDs of existing queues using this driver will not get
auto-updated.

   Till


On 01/08/2014 01:33 PM, Didier 'OdyX' Raboud wrote:
> Hi Till,
> 
> Thanks for rising this question.
> 
> Le mercredi, 8 janvier 2014, 12.42:04 Till Kamppeter a écrit :
>> OdyX, you have split foo2zjs into printer-driver-foo2zjs and
>> printer-driver-foo2zjs-common telling that you want all
>> arch-independent files being shared across architectures. This saves
>> some disk space in the build server infrastructure (there should be
>> plenty of disk space)
> 
> This was triggered by the arch-dep-package-has-big-usr-share lintian 
> informational tag:
> 
> http://lintian.debian.org/tags/arch-dep-package-has-big-usr-share.html
> 
> Where it saves the most is on the mirrors, especially on Debian, as we 
> currently have 13 architectures. The saving (although not huge) is of 
> ~400 kB per package, for a new package of ~520 kB, altogether a ~4.6Mb 
> saving.
> 
> I agree it's not immense, but it's a small move in the direction of 
> containing the continuous archive grow.
> 
> (Also, it's probably worth mentioning that this change went through the 
> NEW queue, so the FTP-Masters had to acknowledge that change…)
> 
>> and on the user side it is probably without any benefit as nowadays no
>> one shares a system disk partition between several computers (which
>> can be of different architectures).
> 
> Well, it's without downsides either as far as I can tell, no? The update 
> should be fully transparent for all users, no?
> 
>> So for me it looks like that it makes building and updating more
>> complicated without real benefit. Or what are the real advantages?
> 
> Well, I can agree that src:foo2zjs became a little more complicated to 
> maintain, but it's really not a burden, as far as I'm concerned… (Fixing 
> the manpages or the build-system were way more cumbersome to do fwiw.)
> 
> That said, if you have serious reasons to revert that, I'd happily hear 
> them…
> 
> Cheers,
> 
> OdyX
> 


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52cf0a5a.2060...@gmail.com

Bug#578079: [Pkg-cups-devel] Bug#578079: I can see this bug too

[Till Kamppeter]

For lpadmin commands it depends where -E is specified. -E before -p
enforces encryption, but -E after -p directly enables the queue.

So you have to take care that the command line arguments of lpadmin are
in the right order in the maintainer scripts.

We do not want to enforce encryption as it is not compatible with all
server configurations, but we want the newly created queue to be enabled
from the beginning on. With all this we want to assure that every user
gets a working queue, regardless of his configuration.

So make sure that the maintainer scripts do

lpadmin -p PDF -E ...

and never

lpadmin -E ...

With this fixed all should work well regardless of whether the ugly
"Upgrade required" error message in CUPS is fixed or not.

   Till


On 01/11/2014 07:21 PM, Didier 'OdyX' Raboud wrote:
> Hi Till,
> 
> Can you give your input here? I seem to remember some discussions about 
> CUPS-PDF…
> 
> Le vendredi, 10 janvier 2014, 17.55:29 Martin-Éric Racine a écrit :
>> 2014/1/10 Didier 'OdyX' Raboud :
>>> While hunting down old src:cups bugs, I stumbled upon #578079, which
>>> I think is not-a-bug, see below.
>>>
>>> Le jeudi, 28 avril 2011, 15.56:06 Martin-Éric Racine a écrit :
 I'm starting to suspect that upstream made some
 backward-incompatible
 changes to the way queues are handled, because we get a similar
 problem with CUPS-PDF, but only whenever the package gets upgraded;
 if it's installed from scratch or purged then re-installed, it
 works as it should.
>>>
>>> From the code:
>>>
>>> $ git grep -B1 'Upgrade Required' cups/
>>> cups/http-support.c-case HTTP_STATUS_UPGRADE_REQUIRED :
>>> cups/http-support.c:s = _("Upgrade Required");
>>> $ git grep 'HTTP_STATUS_UPGRADE_REQUIRED ' cups/http.h
>>> cups/http.h:  HTTP_STATUS_UPGRADE_REQUIRED = 426,
>>>
>>>   /* Upgrade to SSL/TLS required */
>>>
>>> … which means that the 'Upgrade Required' error is not a "Please
>>> upgrade your cups client to a more recent version because we broke
>>> backwards- compatibility"-error, but a "Hey client, please talk to
>>> me over SSL/TLS because I require it"-error. This can be enforced
>>> using the "Encryption"> 
>>> cups.conf statement:
>>> https://localhost:631/help/ref-cupsd-conf.html#Encryption
>>>
>>> I therefore propose to close this bug as it doesn't appear (to me)
>>> to be a bug but mostly a miscomprehension of the error message.
>>
>> Way back when people reported installation errors for CUPS-PDF, the
>> general concensus was that using the -E option to enable encryption
>> with 'lpadmin' was a source of problem, because the SSL certificates
>> needed by CUPS might not have been yet unpacked and configured on a
>> fresh install, so the option was removed from CUPS-PDF's maintainer
>> scripts.
> 
> One possibility would be to hijack a ppd-updater trigger to setup this 
> queue once cups is fully setup, see : 
> http://sources.debian.net/src/cups/1.7.1-1/debian/cups.postinst#L167
> The trigger runs after CUPS is fully configured.
> 
> Another possibility would be to pre-depend on CUPS but I think it's 
> probably overkill. 
> 
>> Yet, according to the above, connections do require it. I'd really
>> appreciate more precise info for when it's required and when it's not.
>> Once I've received this, I can upgrade CUPS-PDF's maintainer scripts
>> to match.
>>
>> Still, TBH, the error message itself is a textbook example of
>> obfuscated code that provides misleading feedback to the user. *sigh*
> 
> Yeah, I agree and therefore reported the upstream 
> https://cups.org/str.php?L4333.
> 
> Cheers,
> OdyX
> 


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d1cef4.2070...@gmail.com

SpliX package

[Till Kamppeter]

Hi,

I have tried to sync your new SpliX package but under Ubuntu it FTBFS as
you are not including the debian/local/apport-hook.py file. See

https://launchpadlibrarian.net/162345035/buildlog_ubuntu-trusty-i386.splix_2.0.0%2Bsvn315-1fakesync1_FAILEDTOBUILD.txt.gz

Can you fix that? Thanks.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d3f1c8.8060...@gmail.com

Bug#712512: Problem remains

[Till Kamppeter]

Please follow the instructions of the section "USB printer does not
print or prints garbage" on
https://wiki.ubuntu.com/DebuggingPrintingProblems. Thanks.


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d4fbb9.1070...@gmail.com

Re: SpliX package

[Till Kamppeter]

On 01/15/2014 07:12 PM, Luca Niccoli wrote:
> Hi Till,
> 
> do you need  a new upload to debian for syncing the Ubuntu package or a
> commit on the alioth git repository would be enough?
> 
> Cheers,
> 
> Luca
> 

I will need a new upload to Debian.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d6d525.6030...@gmail.com

cups-filters 1.0.44 and binary package splitting for mobile

[Till Kamppeter]

Hi,

I have released cups-filters 1.0.44 upstream and updated the Debian GIT
repo appropriately.

In addition, I have split two binary packages to allow a low-footprint
printing stack on mobile devices, the "level 2" on

https://blueprints.launchpad.net/ubuntu/+spec/client-1305-printing-stack-with-mobile-in-mind

Now, by installing avahi-daemon, cups-daemon, cups-ppd-less,
cups-browsed, cups-filters-ppd-less, poppler-utils, and the libraries
pulled in by these one gets a printing stack in the order of two-digit
megabytes, without the bulk of drivers and PPD files.

Setting "CreateIPPPrinterQueues Yes" in /etc/cups/cups-browsed.conf this
printing stack will auto-discover IPP printers with known languages
(PDF, PostScript, PWG Raster, PCL-XL, PCL 5c/e) and shared CUPS printers
in the network and automatically set up queues for them and also
automatically remove these queues again when the printers disappear
(only if there are no jobs left in the queues).

This way one gets basic printing functionality on mobile (or other
low-footprint devices like for example set-top-boxes) devices without
printer setup tool and without driver libraries. Note also that Poppler
one has usually on a mobile device for screen display of PDF files.

OdyX, the changes are in the Debian GIT repos of CUPS and cups-filters
now. Can you upload the packages to Debian so that they sync into
Ubuntu? Can you also check whether I did the splitting correctly? Thanks.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d91fba.40...@gmail.com

Re: cups-filters 1.0.44 and binary package splitting for mobile

[Till Kamppeter]

On 01/17/2014 07:02 PM, Didier 'OdyX' Raboud wrote:
> Hi Till,
> 
> Le vendredi, 17 janvier 2014, 13.19:06 Till Kamppeter a écrit :
>> I have released cups-filters 1.0.44 upstream and updated the Debian
>> GIT repo appropriately.
> 
> Nice, thanks.
> 
>> In addition, I have split two binary packages to allow a low-footprint
>> printing stack on mobile devices, the "level 2" on
>>
>> https://blueprints.launchpad.net/ubuntu/+spec/client-1305-printing-sta
>> ck-with-mobile-in-mind
> 
> I would really have appreciated a public discussion here on debian-
> printing@l.d.o before seeing extensive split patches applied on the 
> packaging repository, which just make me feel like an uploading-monkey 
> for Ubuntu purposes now; mind you, these are also Debian packages. This 
> earlier discussion would have opened options about binary package names, 
> etc.
> 
> That said, I don't disagree with the general goal, or with the split, 
> but really, if you want to maintain cups and cups-filters "in Debian 
> first" (which is great, I absolutely welcome that, it reduces the 
> workload for everyone), then you also need to do it the "Debian way", 
> which implies discussion with or within the concerned package 
> maintainers _before_ doing extensive changes.
> 
>> Now, by installing avahi-daemon, cups-daemon, cups-ppd-less,
>> cups-browsed, cups-filters-ppd-less, poppler-utils, and the libraries
>> pulled in by these one gets a printing stack in the order of two-digit
>> megabytes, without the bulk of drivers and PPD files.
> 
> In particular, I find the -ppd-less postfix absolutely awful; in english 
> it would (as far as my l10n-en skills go) stand as "-ppdless" anyway. 
> Also, it describes what it doesn't do, rather than describing what it 
> does. Something like -coreprotocols, -core, -minimal, -direct or even
> -ppdless would sound way better. My personal preference would go for
> "-direct", but let's discuss!
> 
>> OdyX, the changes are in the Debian GIT repos of CUPS and cups-filters
>> now. Can you upload the packages to Debian so that they sync into
>> Ubuntu? Can you also check whether I did the splitting correctly?
> 
> Besides the naming issue above:
> 
> * Replaces and Breaks need to be "<<" the version that is uploaded, aka
>   1.0.44-1, not "<=" the latest uploaded version. People out there could
>   have rebuilt cups-filters without the split; see Debian Policy §7.6.1.
> * You have created new changelog entries without replicating earlier
>   changes (some of which fix bugs, which come automagically with git-dch
>   --meta).
>   I have certainly already mentionned this to you; I prefer to generate
>   (+ hand-edit) changelog entries using git-dch at release time (this
>   makes backporting, reverting, etc easier). So if you don't stick to
>   this, please at least make sure to replicate my changelog entries)
> 
> I will fix the two above problems and upload as soon as we can find an 
> agreement on a nicer postfix than -ppd-less (and when cups 1.7.1-2 will 
> have migrated to testing).

Sorry for simply committing it this way.

For the debian/changelog I was also wondering why there were changes in
"git log" which are not represented by the debian/changelog. I do not
know how they got lost in my copy of the repo (or how they did not make
it into it).

For the name for the new binary packages I am also a little bit in
doubt, -minimal is also not good as there is the smaller level-1
configuration of no drivers/filters at all. The new packages are for a
configuration with a minimum support for directly talking to printers.

As filters for PDF, PostScript, PWG Raster, and PCL are also certain
printer drivers perhaps we should say something like -basic-drivers?

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d975ea.5060...@gmail.com

Re: cups-filters 1.0.44 and binary package splitting for mobile

[Till Kamppeter]

On 01/18/2014 02:57 PM, Didier 'OdyX' Raboud wrote:
> Le vendredi, 17 janvier 2014, 19.26:50 Till Kamppeter a écrit :
>> For the debian/changelog I was also wondering why there were changes
>> in "git log" which are not represented by the debian/changelog. I do
>> not know how they got lost in my copy of the repo (or how they did
>> not make it into it).
> 
> The point of generating the changelog with git-dch is that nothing gets 
> committed to debian/changelog until release time. Then, just before 
> releasing, one generates the debian/changelog using `git-dch --meta`, 
> then commits the debian/changelog only.
> 

OK.

>> For the name for the new binary packages I am also a little bit in
>> doubt, -minimal is also not good as there is the smaller level-1
>> configuration of no drivers/filters at all. The new packages are for a
>> configuration with a minimum support for directly talking to
>> printers.
>>
>> As filters for PDF, PostScript, PWG Raster, and PCL are also certain
>> printer drivers perhaps we should say something like -basic-drivers?
> 
> -core-drivers ? AFAIK they are not -basic, but rather a selection of the 
> most important ones, hence -core.

OK, let us take -core-drivers.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52dad918.8010...@gmail.com

Re: cups-filters 1.0.44 and binary package splitting for mobile

[Till Kamppeter]

On 01/19/2014 01:58 PM, Didier 'OdyX' Raboud wrote:
> Reviewing the package before uploading made me aware of a new question: 
> shouldn't cups-filters-core-drivers depend (or at the very least 
> recommend) on ghostscript ? At least:
> 
> a) pdftoippprinter tries to use either gstoraster filter (in cups-
> filters) or ghostscript through CUPS_GHOSTSCRIPT, then fallbacks to 
> pdftoraster.
> b) pdftops tries to use gs through CUPS_GHOSTSCRIPT if pdftops-renderer 
> is configured that way (which is default as far as I could see).
> 
> So for b) at least, cups-filters-core-drivers needs to depend on 
> ghostscript, which is apparently conflicting with the goal of having a 
> small-footprint package. The other possibility is to configure cups-
> filters with --with-pdftops=hybrid, no?

This is not needed, pdftoippprinter leads with Poppler-only (and also
Ghostscript-only) systems independent of default configuration. It
always checks presence of Poppler components (/usr/bin/pdftops,
pdftoraster, CUPS_POPPLER_PDFTOPS) and of Ghostscript components (gs,
gstoraster, gstopxl, CUPS_GHOSTSCRIPT) before using them. It also adds
"pdftops-renderer=..." to the filter command line if the absense of a
renderer requires the use of the other, overriding any default settings.

So a Poppler-only system (typical situation for a phone) will work
perfectly, independent of the --with-pdftops=... default choice done at
build time (so we use the most desktop-friendly "hybrid" here).

So do not add Depends/Recommends or use OR ("|") relationships which get
fulfilled also if the system is Poppler-only or Ghostscript-only.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52dbd080.6000...@gmail.com

Bug#655106: [hpijs-ppds] margins for F4280 are wrong - calling make-duplex-page-sizes-default.sh

[Till Kamppeter]

Originally, the simple paper size names "A4", "Letter", ... referred to
paper sizes with smaller margins/a larger printable area, but these
sizes do not allow Duplex printing, jobs simply came out one-sided.
Office applications only used the simple names for paper sizes as part
of the document (not of the print settings). Trying to print these
documents always gave one-sided output. To really get duplex output on
HP inkjets one had to switch to special duplex page sizes (like
A4.duplex), which once required extra user action and second, was not
possible from many applications (like OpenOffice/LibreOffice). So I made
the script to modify the PPD generator so that the default page sizes
are the duplex ones and the former default page sizes get special page
sizes for small margins (A4.SM).

This way more user's requirements are addressed, as more need duplex
printing and not so many printing of graphical elements close to the
borders.

If you need the smaller margins and do not need double-sided for a
certain print job, simple select the small-margin (SM) page size
manually (or even a borderless page size if available).

It would be indeed a bug if this change is applied to printer which
under no circumstances is able to print duplex (no duplex unit built-in
or as accessory).

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52dd3063.3040...@gmail.com

Making the CUPS daemon startable on-demand

[Till Kamppeter]

Hi,

in Ubuntu we also want to have print functionality in the mobile
version, Ubuntu Touch (therefore I also did the binary package
splitting). As mobile devices run on battery and have limited RAM one
should avoid keeping daemons running alll the time, especially if they
are used infrequently, like the CUPS daemon.

Therefore I want to add a functionality to make the CUPS daemon
startable on-demand and, if CUPS go started on-demand, stop when the
print queues empty out.

There exist already implementations for that, in upstream CUPS for the
launchd of Mac OS X, and at Red Hat for systemd. There is a nice article
available about the development of the systemd implementation:

http://0pointer.de/blog/projects/socket-activation2.html

Ubuntu uses Upstart and not systemd, but it looks like that one can
easily "translate" the systemd implementation to Upstart. See especially
the "Bridges" section of the Upstart documentation here:

http://upstart.ubuntu.com/cookbook/#upstart-socket-bridge

Now I do not want to make Ubuntu-only distro patches but find a solution
which works on both Debian and Ubuntu (to avoid package delta, keeping
synced) and ideally which can get submitted upstream.

For this I want to know, how Debian starts services. Upstart? systemd?
System V Init? Something else? Should we create a CUPS patch supporting
all systems and submitting this upstream?

WDYT?

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e038c4.5020...@gmail.com

Re: cups-filters 1.0.44 and binary package splitting for mobile

[Till Kamppeter]

On 01/19/2014 01:58 PM, Didier 'OdyX' Raboud wrote:
>> OK, let us take -core-drivers.
> 
> ACK.
>

I have now changed the GIT repos of cups and cups-filters to use
-core-drivers.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e040d6.60...@gmail.com

Bug#736378: libgs9-common: replace \r with \n in ps2epsi.ps

[Till Kamppeter]

Please report this upstream to Ghostscript's bug tracking system

http://bugs.ghostscript.com/

Preferably attach a patch to the bug report.

Thanks.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e0472a.9020...@gmail.com

Bug#736378: libgs9-common: replace \r with \n in ps2epsi.ps

[Till Kamppeter]

On 01/23/2014 01:22 AM, Ryo Furue wrote:
> It is
> 
> http://bugs.ghostscript.com/show_bug.cgi?id=694968

This is fixed upstream now.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e0efad.7000...@gmail.com

Re: Making the CUPS daemon startable on-demand

[Till Kamppeter]

On 01/23/2014 03:23 PM, Didier 'OdyX' Raboud wrote:
> The answer to this question is currently debated in the following 
> technical committee question: http://bugs.debian.org/727708 which isn't 
> settled yet.
> 
> Also, the question of the systemd support patch has been asked in 
> http://bugs.debian.org/732435 . I think both your question of a multi-
> init's patch and the systemd patch questions should wait before the 
> resolution of #727708 …

How long will it take until the decision is made? I want to have support
for starting CUPS on-demand before the Feature Freeze of Ubuntu 14.04 on
Feb 20, 2014. Or should I create an interim patch then?

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e12f81.9040...@gmail.com

Bug#736942: cups: Printing not working with Konica Minolta C220

[Till Kamppeter]

Should be fixed in cups-filters 1.0.40 and later:

[...]
CHANGES IN V1.0.40

- pdftops: Introduced new "hybrid" renderer: Here usually
  Ghostscript is used, but if the printer is a Brother,
  Minolta, or Konica Minolta Poppler's pdftops gets used. This
  is a quirk rule to work around bugs in the PS interpreters
  of the printers.
[...]

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e96547.9070...@gmail.com

Bug#737306: cups-core-drivers: commandtops missing from cups-core-drivers

[Till Kamppeter]

For actual printing commandtops is not needed, but it seems that CUPS
hardwires the requirement of its presence to unlock printing to a
PostScript printer (PPD without *cupsFilter: line).

We either need to patch CUPS to remove this hard requirement (but still
allow the use of commandtops if it is there) or we need to move
commandtops into cups-core-drivers. Probably moving commandtops is much
easier and it should not to take so much space.

Didier, WDYT we should do here?

   Till


On 02/01/2014 01:06 PM, Yves-Alexis Perez wrote:
> Package: cups-core-drivers
> Version: 1.7.1-3
> Severity: normal
> 
> Hi,
> 
> following the cups split, I removed the cups package and only kept the
> -core ones. I have a fairly common setup, my printer is an ipp Brother
> one, which I think use PS (or PCL) language (Brother HL-5250DN).
> 
> Now, when trying to print or in the printer properies I get an error
> saying /var/lib/cups/commandtops file is missing.
> 
> If PS-based printing is not in the -core package, I have to admit I'm
> not sure what belongs there and who is it useful for.
> 
> Regards,
> 


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52ece9c3.9090...@gmail.com

Bug#661544: cups: fontconfig conf file should be in conf.avail, not conf.d

[Till Kamppeter]

On 05.02.2014 17:12, Didier 'OdyX' Raboud wrote:

Control: tags -1 +moreinfo

Hi Till,

Can you provide more explanations about this file (introduced in
1.0.19)?

Le lundi, 27 février 2012, 16.12:10 Samuel Bronson a écrit :

(…)
File: /etc/fonts/conf.d/99pdftoopvp.conf
(…)
I think the file listed above is should probably be installed as
/etc/fonts/conf.avail/99pdftoopvp.conf, with a symlink to it in
conf.d.

At least, /etc/fonts/conf.d/README says that this how it is normally
done, and all but one of the *other* conf files in my conf.d do this.
(The remaining file is also a symlink, but points elsewhere.)


I don't see a reason to do differently, I'll see if I can prepare a
patch soon.



No problem, please do.

I do not really no for what this file is good. It simply came in with 
the pdftoopvp filter which was hosted separately before the introduction 
of cups-filters.



If it turns out to be vital that this not be done with
99pdftoopvp.conf, it would be a good idea to add a comment explaining
why to the file.

(It would also be nice if there was a comment explaining what the
filename is supposed to mean, as it's really non-obvious even after
looking at the file. Comments explaining the problem(s) it solves
would also be quite welcome.)


Till: ^ that would need your enlightenment…



I do not really know. See above.

Otani-san, do you know what this file is good for?

   Till


--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f26688.9070...@gmail.com

Bug#738440: cups: new version contains Ubuntu Bug #1019662

[Till Kamppeter]

I have fixed the problem upstream (BZR rev. 7159) now. I do not use
PATH+MAX any more for strings which are used to hold a command line.
Command lines have 65535 bytes now.

Please test and tell whether it solves the problem. If so, I will
release a new cups-filters version.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f953ef.6070...@gmail.com

Please upload cups 1.7.1-5

[Till Kamppeter]

Hi,

I have committed changes on CUPS to GIT, adding features for running the
CUPS daemon on-demand, once to trigger cupsd via Upstart's socket bridge
and second, to automatically shut down CUPS when it gets idle (no jobs,
no shared printers).

See also

https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1276713
https://blueprints.launchpad.net/ubuntu/+spec/client-1305-printing-stack-with-mobile-in-mind

Thanks in advance

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52fe44c5.4090...@canonical.com

Re: Please upload cups 1.7.1-5

[Till Kamppeter]

Sorry for doing this massive change which was only worked out inside
Ubuntu. I overvalued being synced between Debian and Ubuntu.

I will simply put it into the Ubuntu package for now and in the future I
will do any bigger changes which are only worked out within Ubuntu into
the Ubuntu package. Simply take them into Debian after some time when it
turns out that they do the right thing and do not cause regressions. If
the patches principally work, but do not fit into Debian's policies I
would consider to make them Ubuntu-only (only applying if the package is
built under Ubuntu).

I will submit the patches upstream after some testing, especially
waiting for the Upstart socket bridge bug getting fixed and we are bale
to test running CUPS on-demand.

By the way, for having Debian using a resource-saving on-demand CUPS,
which init systems (Sys V, Upstart, systemd) must be supported?

   Till


On 02/14/2014 06:10 PM, Didier 'OdyX' Raboud wrote:
> Till,
> 
> Le vendredi, 14 février 2014, 17.31:01 Till Kamppeter a écrit :
>> I have committed changes on CUPS to GIT, adding features for running
>> the CUPS daemon on-demand, once to trigger cupsd via Upstart's socket
>> bridge and second, to automatically shut down CUPS when it gets idle
>> (no jobs, no shared printers).
> 
> First, please make sure to adhere to the source policy [0] which I 
> mentioned to you multiple times already:
> 
> * one commit per change, no changelog entry committed
> * DEP-3 headers in all patches
> * one commit per release with the full polished changelog entry
> 
> In this one single commit, you have added _three_ patches (none of which 
> have been reported upstream) and released a new version; then you just 
> come and request that Debian includes your invasive patches in a new 
> upload to our development release without preliminary discussion at all.
> 
> Doing things "Debian first" shouldn't mean "discuss things on Ubuntu-
> devel without including the Debian maintenance team, then prepare 
> invasive patches, dump them on the packaging repository and file a 
> ticket on their list to have them upload it for you".
> 
> I would have preferred if debian-printing had been informed of the 
> discussion I then found today on ubuntu-devel. I would also have 
> preferred if you had dumped such invasive patches on a master-ubuntu 
> branch and uploaded preliminary packages to Ubuntu's development 
> distribution: there are things that are worthwhile to do "Debian first" 
> (most things that are _not_ Ubuntu specific should be done together and 
> in coordination with Debian), but you can't rely on volunteers to upload 
> your R&D work in a timely manner to Ubuntu through Debian.
> 
> So, for now, I'm quite annoyed and have other things to do in the next 
> days, so don't expect an upload from me right now. Feel free to upload 
> this to Ubuntu first, I will likely backport most of it at a later 
> point.
> 
> OdyX
> 
> [0] Sure, it's unwritten (yet), but if you look at the history you can 
> get it, I'm sure.
> 


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52fe67e6.5070...@gmail.com

Bug#740583: pdftops (ghostscript) issue in debian 7.0 https://answers.launchpad.net/hplip/+question/243753

[Till Kamppeter]

The DSC warnings are caused by a bug in Ghostscript (needs upstream
report on http://bugs.ghostscript.com/), sometimes Ghostscript inserts
"%BeginResource" (only one "%" character) instead of "%%BeginResource".
This problem is still present in Ghostscript 9.10.

One can easily show it running only Ghostscript:

gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOUTPUTFILE=%stdout
-dLanguageLevel=3 -r600 -dCompressFonts=false -dNoT3CCITT
-dNOINTERPOLATE -c 'save pop' -f /tmp/compilers.pdf >
/tmp/printout_gs_9_05.ps

The exact Ghostscript command line can be different for you. See the
output of your "cupsfilter" call.

If a printer errors due to this it is a firmware bug, as
"%%BeginResource" and "%%EndResource" are still comments (also if they
have only one "%" character) and so they should be ignored by the
printer's PostScript interpreter.

Please try the following:

Edit your /tmp/printout_gs_9_05.ps file, correcting the missing "%"
characters, changing all "%BeginResource" to "%%BeginResource", the try
to print it (with "-o raw") again. Does it work now?

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/531443c2.1090...@gmail.com

Bug#740583: pdftops (ghostscript) issue in debian 7.0 https://answers.launchpad.net/hplip/+question/243753

[Till Kamppeter]

Reported bug to Ghostscript upstream:

http://bugs.ghostscript.com/show_bug.cgi?id=695082

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/531467dc.3030...@gmail.com

Bug#740583: pdftops (ghostscript) issue in debian 7.0 https://answers.launchpad.net/hplip/+question/243753

[Till Kamppeter]

Sanjay. can you please go to

http://bugs.ghostscript.com/show_bug.cgi?id=695082

and answer the questions of the Ghostscript developers so that they can
find and fix the bug? Thanks.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5314909a.1090...@gmail.com

Re: Should cups and foomatic-filters conflict with each other?

[Till Kamppeter]

foomatic-filters is indeed obsolete. foomatic-rip in a CUPS-only version
is now in cups-filters which is required by cups. So you should simply
remove foomatic-filters from the tasks, its functionality is included in
cups-filters now.

foomatic-filters is only useful for legacy non-CUPS print environments
(LPRng? Is this still maintained?). foomatic-filters is not developed
upstream any more.

   Till

On 03/08/2014 09:15 AM, Petter Reinholdtsen wrote:
> 
> I discovered a serious problem when testing Debian Edu based on jessie.
> The installation of Debian Edu based on testing fail because the tasks
> are uninstallable.  I investigated, and the cause seem to be that
> foomatic-filters and cups is not installable together.
> 
> Is this intentional, or should they be co-installable?  Is the
> foomatic-filters package obsolete?  I notice from
> http://packages.qa.debian.org/f/foomatic-filters.html > that the
> last upload was in 2012, which made me suspect that the package is no
> longer active maintained.
> 
> Cc to debian-edu@, to let all developers know about the problem.
> 


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/531ad93d.5030...@gmail.com

Fix for CUPS STR #4391

[Till Kamppeter]

Hi,

to fix

https://www.cups.org/str.php?L4391

I have removed
debian/patches/fix-race-condition-in-cupsdoiorequest.patch in Ubuntu's
CUPS package on the GIT (released as 1.7.1-5ubuntu9). Also it is told in

https://www.cups.org/str.php?L4386

that the fix does not actually work.

So I recommend you to do this in Debian as well.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5329c5f0.2030...@gmail.com

Bug#742766: printer-driver-postscript-hp: HP LaserJet PostScript PPD buggy in Wheezy

[Till Kamppeter]

Thank you very much for your bug report and your patch.

I fixed the bug in the hplip package for Debian and Ubuntu now (SVN
repository, rev. 629).

This should also get fixed upstream. Please report this bug with your
patch upstream at http://launchpad.net/hplip/. Thanks in advance.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53346a0d.2010...@gmail.com

Bug#742766: printer-driver-postscript-hp: HP LaserJet PostScript PPD buggy in Wheezy

[Till Kamppeter]

On 03/27/2014 07:16 PM, Jean Tourrilhes wrote:
>   Already done :
> https://bugs.launchpad.net/hplip/+bug/1298194

Great, thanks. This is totally OK.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53346da9.6000...@gmail.com

Re: Parameters to program are not passed over correctly

[Till Kamppeter]

Which printer setu tool are you using? Are you using foomatic-gui? Note
that this program is no maintained any more and does not come from
OpenPrinting. It is based on the printer/driver relationship information
being provided in XML format. As this is very space-consuming and slow,
I have deprecated this format for end users and demoted it to be only a
VCS-friendly source format. End users get the information now as highly
compressed PPD files in
/usr/lib/cups/driver/foomatic-db-compressed-ppds. This takes much less
space and is compatible with all CUPS-conforming printer setup tools,
but not with the deprecated, not standard-conforming foomatic-gui.

So if you are using foomatic-gui, uninstall it and use
system-config-printer, gnome-control-center, or http://localhost:631/
instead. All these tools show you the available drivers.

   Till

On 03/28/2014 04:01 PM, Udo Pütz wrote:
> Hi,
> sorry, I can't really find the bug reporting page login, if I click
> "please report it" here
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=cups;dist=unstable
> that page eats my ear off...
> 
> Problem: No printer driver is listed on a raspberry pi - but also on my
> desktop machine (amd64).
> This script is executed during the setup:
> sh -c /usr/bin/foomatic-combo-xml -C -n -l '/usr/share/foomatic'
> 
> The parameters are not passed correctly, if
> sh -c "/usr/bin/foomatic-combo-xml -C -n -l '/usr/share/foomatic'"
> or
> /usr/bin/foomatic-combo-xml -C -n -l '/usr/share/foomatic'
> is used the script works.
> 
> Best regards,
> Udo Puetz
> 


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53359a7f.4040...@gmail.com

Bug#742666: cups-daemon: No Upstart support

[Till Kamppeter]

Cameron, first, thank you for your patch.

Here my remarks:

1. I have modified the CUPS daemon to have working avahi-daemon support
even if avahi-daemon is started after cupsd or if avahi-daemon is
restarted while cupsd stays running. cupsd simply stops broadcasting
when avahi-daemon disappears and carries on broadcasting when it appears
again. So no interaction with avahi-daemon is needed in the Upstart scripts.

2. Why does CUPS under Debian need other Upstart scripts than CUPS under
Ubuntu. Why should we not simply drop all the "$(derives_from_ubuntu)"
conditionals and let the Upstart script which was developed for Ubuntu
also be installed under Debian?

3. Do not let debian/rules remove a file shipped with the source package
(in this case debian./*.upstart), as the build tree cannot be reset by
"debian/rules clean" any more. This can cause major problems when
building this package.

Can you post a link to the Launchpad bug which you are talking about in
your last comment?

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53394a85@gmail.com

Bug#742666: cups-daemon: No Upstart support

[Till Kamppeter]

Cameron, please also make sure that your Upstart support works with
socket activation, as it does with the current Ubuntu package. Please
integrate the two patches introduced for that in the Ubuntu package
(attached) in the Debian package. Also modify the Upstart jobs so that
the CUPS daemon starts socket-activated (via port 631 and
/var/run/cups/cups.sock) but CUPS also starts when a USB printer is
plugged/unplugged or on boot when printers are shared or jobs in the queues.

This way we can use CUPS on mobile systems (like Ubuntu Touch) or simply
save battery power on laptops.

   Till
--- a/scheduler/main.c
+++ b/scheduler/main.c
@@ -1683,6 +1683,13 @@
   if (_httpAddrPort(&(lis->address)) == 443)
 lis->encryption = HTTP_ENCRYPT_ALWAYS;
 #  endif /* HAVE_SSL */
+
+  /* As we are started on-demand, stop on idle */
+  if (!ExitOnIdleTimeout)
+ExitOnIdleTimeout = 30;
+  cupsdLogMessage(CUPSD_LOG_DEBUG, "As we are starting on-demand (socket-triggered), activate exit-on-idle mode, timeout: %d seconds.",
+  ExitOnIdleTimeout);
+
 }
 
 /*
Description: CUPS Upstart socket activation:
 Important to note:
 - Run by default in foreground (-f), not Foreground (-F). With -F CUPS
 closes all inherited file descriptors, which is not needed under
 upstart since it does that on our behalf, furthermore closing passed
 socket activation descriptors prevents us from using socket
 activation.
 - Force foreground (-f) mode if environment suggests that we are Upstart
 socket activated (similar to "-l" flag for launchd).
 - Initialize addrlen to sizeof(addr) to make getsockname() work.
 - Correct environment variable name used to check event type
 - Get UPSTART_FDS simply with atoi()
 - Perform explicit return code checking from getsockname function call
Author: Till Kamppeter ,
 Dimitri John Ledkov 
Bug: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1276713
--- a/scheduler/main.c
+++ b/scheduler/main.c
@@ -26,6 +26,8 @@
  *   launchd_checkin() - Check-in with launchd and collect the listening
  *   fds.
  *   launchd_checkout()- Update the launchd KeepAlive file as needed.
+ *   upstart_checkin() - Check-in with Upstart and collect the
+ *   listening fds.
  *   parent_handler()  - Catch USR1/CHLD signals...
  *   process_children()- Process all dead children...
  *   select_timeout()  - Calculate the select timeout value.
@@ -83,6 +85,7 @@
 static void		launchd_checkin(void);
 static void		launchd_checkout(void);
 #endif /* HAVE_LAUNCHD */
+static void		upstart_checkin(void);
 static void		parent_handler(int sig);
 static void		process_children(void);
 static void		sigchld_handler(int sig);
@@ -320,6 +323,14 @@
   usage(1);
 }
 
+  /* force non-disconnecting foreground mode upon upstart socket
+   * activation, as otherwise all fd's are closed before we get to use
+   * them */
+  if (getenv("UPSTART_FDS"))
+  {
+fg  = 1;
+  }
+
   if (!ConfigurationFile)
 cupsdSetString(&ConfigurationFile, CUPS_SERVERROOT "/cupsd.conf");
 
@@ -573,6 +584,11 @@
 #endif /* HAVE_LAUNCHD */
 
  /*
+  * If we were started by Upstart get the listen sockets file descriptors...
+  */
+  upstart_checkin();
+
+ /*
   * Startup the server...
   */
 
@@ -761,6 +777,13 @@
 #endif /* HAVE_LAUNCHD */
 
/*
+* If we were started by Upstart get the listen sockets file
+	* descriptors...
+*/
+
+upstart_checkin();
+
+   /*
 * Startup the server...
 */
 
@@ -1509,6 +1532,93 @@
 }
 #endif /* HAVE_LAUNCHD */
 
+static void
+upstart_checkin(void)
+{
+  /*
+   * Example socket event environment:
+   *
+   * UPSTART_INSTANCE=
+   * PORT=34568
+   * PROTO=inet
+   * UPSTART_JOB=foo5
+   * UPSTART_FDS=43
+   * UPSTART_EVENTS=socket
+   * ADDR=127.0.0.1
+   *
+   */
+  int fd = 0;
+  const char *e;
+  http_addr_t addr;
+  socklen_t addrlen = sizeof(addr);
+  cupsd_listener_t *lis;
+  char s[256];
+
+  if (!(e = getenv("UPSTART_EVENTS")))
+return;
+
+  if (strcasecmp(e, "socket"))
+return;
+
+  if (!(e = getenv("UPSTART_FDS")))
+  {
+cupsdLogMessage(CUPSD_LOG_ERROR,
+		"upstart_checkin: We got started via Upstart socket event but no environment variable UPSTART_FDS is not set");
+return;
+  }
+
+  fd = atoi(e);
+
+  if (getsockname(fd, (struct sockaddr*) &addr, &addrlen) < 0)
+  {
+cupsdLogMessage(CUPSD_LOG_ERROR,
+		"upstart_checkin: Unable to get local address - %s",
+		strerror(errno));
+return;
+  }
+
+ /*
+  * Try to match the systemd socket address to one of the listeners...
+  */
+
+  for (lis = (cupsd_listener_t *)cupsArrayFirst(Listeners);
+   lis;
+   lis = (cupsd_listener_t *)cupsArrayNext(Listeners))
+if (httpAddrEqual(&lis->address, &addr))
+  break;
+
+  if (lis)
+  {
+cupsdLogMessage(CUPSD_LOG_DE

CUPS 1.7.2 released - As today is Final Freeze for Ubuntu 14.04 LTS I had to rush it in, how to proceed with GIT?

[Till Kamppeter]

Hi,

I have rushed CUPS 1.7.2 into Ubuntu, so that it made it before today's
Final Freeze for Ubuntu Trusty 14.04 LTS (to be released in one week
from now).

Therefore I did not do anything with the Debian GIT as it had taken me
too much time. Especially I also do not know how the branches master and
master-ubuntu can be based on different source releases.

I recommend you to wait for it to make it into Ubuntu in a few hours,
download it from Launchpad and then use my _orig.tar.bz2 also for
Debian, so that syncing of Debian and Ubuntu versions goes flawlessly
after the Ubuntu 14.04 release. I will update the ubuntu-master branch
as soon as you have switched master over to 1.7.2.

Sorry for the inconvenience, but due to the tons of bug fixes in 1.7.2
we had to get it in.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5346e794.10...@gmail.com

Re: CUPS 1.7.2 released - As today is Final Freeze for Ubuntu 14.04 LTS I had to rush it in, how to proceed with GIT?

[Till Kamppeter]

On 04/10/2014 10:27 PM, Didier 'OdyX' Raboud wrote:
> You guys at Ubuntu should prepare a merge of the Ubuntu patches (mostly 
> Upstart support) on the master-ubuntu for me to review (basically, merge 
> 'master' into 'master-ubuntu', quilt refresh and check the diffs).
>

Will do so after the Ubuntu 14.04 release.

>> Sorry for the inconvenience, but due to the tons of bug fixes in 1.7.2
>> we had to get it in.
> 
> No problem, thanks.
> 

I have updated the master-ubuntu branch now to represent what I have
uploaded to Ubuntu today.

   Till




-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53470ed9.2030...@gmail.com

Updating Debian package of Ghostscript

[Till Kamppeter]

Hi Jonas,

thank you for updating Debian's Ghostscript to 9.10.

Unfortunately, 9.10 is not the newest any more. Current version is 9.14.
I have packaged 9.14 already for Ubuntu Utopic (14.10). Before you
package it for Debian I want to ask you to not name the original source
tarball ghostscript_9.14~dfsg.orig.tar.bz2 but something like
ghostscript_9.14~dfsg+1.orig.tar.bz2 (upstream version 9.14~dfsg+1) so
that I can sync it to Ubuntu without getting a source tarball conflict.

Please also report upstream Ghostscript bugs for things like no support
for using system's libtrio, to avoid carrying too many distro patches
eternally.

Also document well what has to be removed from the original source for
future updates.

Thanks for your great work!

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53688024.3010...@gmail.com

Bug#748028: Conflicting parameter types yielding undefined behaviour

[Till Kamppeter]

I have fixed this now upstream in BZR revision 7203. The fix will be
part of the 1.0.54 release.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53723edd.4070...@gmail.com

Bug#750498: cups: server keeps timing out after 30secs idling with no way to change that

[Till Kamppeter]

It seems that cupsd needs to check whether there is a running web
interface session and consider itself non-idle then.

colord will probably also need some tweaking for laptop/mobile battery
saving environments.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/538e447e.3050...@gmail.com

Bug#756724: cups-browsed: Can't see remote printers in print dialogs

[Till Kamppeter]

I have fixed this regression on the BZR repository, rev. 7241. Thank you
for the bug report.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53de9584.8010...@gmail.com

cups-filters 1.0.57 released

[Till Kamppeter]

I have released cups-filters 1.0.57, to fix an important bug introduced 
by Joe Simon's color management support changes, which made the unit 
tests of the build of the CUPS package fail:


https://bugs.launchpad.net/bugs/1356405

Joe has quickly fixed it (thank you, Joe) and therefore I have released 
1.0.57. I also included the two patches from the Debian package upstream.


   Till


--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ec4f99.5090...@gmail.com

CUPS 1.7.5 is out

[Till Kamppeter]

Hi,

I only want to tell that 1.7.5 is out with several bug fixes. See 
www.cups.org.


   Till


--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53eccf1c.4080...@gmail.com

"Main Switch" to turn off CUPS totally when we use systemd as PID 1

[Till Kamppeter]

Hi all,

all major distros are using systemd or will end up with it very soon. 
under systemd on-demand use of CUPS is supported and for most users it 
is a nice feature, especially to save battery and resources on laptops 
and mobile devices.


But on SUSE there are complaints which have lead to long discussion 
making SUSE use a configuration without on-demand facility:


https://bugzilla.novell.com/show_bug.cgi?id=864894
https://bugzilla.novell.com/show_bug.cgi?id=857372

Especially Johannes Meixner told me that the current systemd 
configuration is missing a "Master Switch"  to not only stop cupsd but 
also to tell that it should not be started on-demand. Currently you have 
only the possibility to stop the daemon butt systemd is still listening 
on the sockets and therefore CUPS gets started as soon as someone 
accesses port 631 or connects a USB printer. This is a security hole as 
a normal user can trigger the start of a program which runs as root.


The master switch has ideally three states:

Off: cupsd does not get started also if a user tries to access printing 
services (port 631, ...).


On-demand: As we have it now, cupsd does not run if it has no jobs or 
shared printers and is triggered by accessing port 631, a domain socket, ...


On: cupsd is permanently running (for servers).

Can such a thing be introduced? This would be great.

   Till


--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ecf672.8030...@gmail.com

cups-filters 1.0.58 and ippusbxd

[Till Kamppeter]

Hi,

today I have released cups-filters 1.0.58 due to the completion of Joe
Simon's GSoC project to add color management support to cups-filters.

Note that cups-filters on Ubuntu is currently not in sync with Debian,
as to get Daniel Dressler's GsoC project, ippusbxd (IPP-over-USB printer
support) into Ubuntu before Utopic's Feature Freeze (tomorrow, Thursday)
without NEW processes in both Debian and Ubuntu, I have added ippusbxd
temporarily to cups-filters.

Please do not back-sync these changes. Please simply go on updating
cups-filters with the newest upstream releases and let ippusbxd be a
separate source package in Debian (name it ippusbxd for both the source
and the binary package) and I sync it into Ubuntu. When this is done I
will remove the temporary ippusbxd addition from cups-filters and return
to syncing cups-filters from Debian.

Thank you in advance.

   Till

https://github.com/daniel-dressler/ippusbxd
http://danieru.com/category/os/printing/


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f51e1f.4050...@gmail.com

cups-filters 1.0.59 released

[Till Kamppeter]

Hi,

I have released cups-filters 1.0.59 with following fixes/changes:

- cupsfilters.drv: Added PPD file for a Generic IPP Everywhere
  Printer, generating PWG Raster output.
- gstoraster, pdftoraster, imagetoraster: Allow PWG Raster
  output with print queues using a PPD file, using the new
  "PWGRaster" PPD attribute.
- pdftoraster: Removed "cm_disabled" flag in selectConvFunc()
- libcupsfilters: Allowed color management to continue while
  invalid input
- rastertopdf: Streamlined PDF conversion code
- rastertopdf: Invert all CUPS_CSPACE_K documents by default
- foomatic-rip: Clean trailing white space from PPD file lines
  to avoid a segfault caused by it (Bug #1227).

I wanted to get it into the Debian GIT repo and used the steps I always
used:

git clone https://alioth.debian.org/anonscm/git/printing/cups-filters.git
cd cups-filters
git checkout --track -b upstream origin/upstream
git checkout --track -b pristine-tar origin/pristine-tar
git checkout master
uscan --verbose
git checkout upstream
git-import-orig --pristine-tar ../cups-filters_1.0.59.orig.tar.xz

The output is the following:

What is the upstream version? [1.0.59]
gbp:info: Importing '../cups-filters_1.0.59.orig.tar.xz' to branch
'upstream'...
gbp:info: Source package is cups-filters
gbp:info: Upstream version is 1.0.59
pristine-tar: committed cups-filters_1.0.59.orig.tar.xz.delta to branch
pristine-tar
gbp:info: Merging to 'master'
gbp:error: Import of ../cups-filters_1.0.59.orig.tar.xz failed: Error
running git checkout: error: Your local changes to the following files
would be overwritten by checkout:
INSTALL
NEWS
README
configure
configure.ac
cupsfilters/colormanager.c
cupsfilters/colormanager.h
filter/gstoraster.c
filter/imagetoraster.c
filter/pdftoraster.cxx
filter/rastertopdf.cpp
Please, commit your changes or stash them before you can switch branches.
Aborting

Looks like that there are local changes in the upstream code in the GIT
repo.

I got this with a fresh clone of the GIT repo, so there cannot be
changes from my side.

Can you have a look to see what is going wrong here? Do I need to change
the procedure of updating the upstream release?

   Till




-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5425d84f.60...@gmail.com

Re: cups-filters 1.0.59 released

[Till Kamppeter]

On 09/27/2014 09:57 PM, Didier 'OdyX' Raboud wrote:
> Hi Till,
> 
> Le vendredi, 26 septembre 2014, 23.19:11 Till Kamppeter a écrit :
>> I have released cups-filters 1.0.59
> 
> Cool, thanks.
> 
>> I wanted to get it into the Debian GIT repo and used the steps I
>> always used:
>>
>> git clone
>> https://alioth.debian.org/anonscm/git/printing/cups-filters.git
>> cd cups-filters
>> git checkout --track -b upstream origin/upstream
>> git checkout --track -b pristine-tar origin/pristine-tar
>> git checkout master
>> uscan --verbose
>> git checkout upstream
> 
> Your mistake is here: you need to be on the 'master' when running 
> import-orig.
> 
>> Can you have a look to see what is going wrong here? Do I need to
>> change the procedure of updating the upstream release?
> 
> It's mostly good. :-), but I'd say the following is actually easier:
> 
> git clone ssh://anonscm.debian.org/git/printing/cups-filters.git
> git import-orig --uscan --pristine-tar
> 
> I've pushed the result of the above to the repository.
>

Thank you very much.

> I have other things on TODO right now, feel free to work on the 
> packaging, I'll be available to upload to Debian.
> 
> (Btw, I've noticed a cups upload in Ubuntu, should we incorporate the 
> fixes in Debian?)
> 

There are no additional fixes or patches on cups-filters in these Ubuntu
uploads. The only difference is that they have ippusbxd added so that it
is shipped in the cups-filters-ippusbxd binary package (as
/usr/sbin/ippusbxd) in Ubuntu Utopic.

This should not get overtaken into Debian. The intention is to create a
proper ippusbxd source package in Debian which then gets overtaken into
Ubuntu (V. V. edition). Then ippsubxd will get dropped from Ubuntu's
cups-filters package so that cups-filters can sync again.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54271f4d.8000...@gmail.com

Re: Syncing cups

[Till Kamppeter]

On 09/30/2014 05:11 PM, Didier 'OdyX' Raboud wrote:
> Le mardi, 30 septembre 2014 17.06:44, vous avez écrit :
>> in the Ubuntu package of CUPS there are fixes for AppArmor problems.
>> Can you check them and see whether you can overtake them to Debian,
>> so that I can sync CUPS again?
> 
> These have been merged and uploaded earlier today.
> 
> Cheers,
> OdyX
> 
> 

We do I not see them on the GIT? Last upload there is

--
commit c9945caa5e08ca95506e970827b709c704b8d02f
Author: Didier Raboud 
Date:   Mon Sep 22 18:01:19 2014 +0200

Add two USB quirk fixes for Canon MX310 and MX320 printers

LP: #1346868
LP: #1369547
--

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/542aca35.5040...@gmail.com

Re: Syncing foo2zjs

[Till Kamppeter]

On 09/30/2014 05:12 PM, Didier 'OdyX' Raboud wrote:
> Le mardi, 30 septembre 2014 16.29:01, vous avez écrit :
>> Can this change get overtaken into Debian? Or do we have to live with
>> the difference of the Debian package recommending tix and the Ubuntu
>> package suggesting it?
> 
> It can; we already have this type of differences for mscompress.
> 
> I've gone ahead and implemented the attached patch, I'll upload 
> soon'ish.
> 
> OdyX
> 

Great. Thank you very much.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/542aca52.1020...@gmail.com

Re: Syncing cups

[Till Kamppeter]

Thank you very much.

Synced.

   Till


On 09/30/2014 06:06 PM, Didier 'OdyX' Raboud wrote:
> Le mardi, 30 septembre 2014, 17.20:21 Till Kamppeter a écrit :
>> On 09/30/2014 05:11 PM, Didier 'OdyX' Raboud wrote:
>>> Le mardi, 30 septembre 2014 17.06:44, vous avez écrit :
>>>> Can you check them and see whether you can overtake them to Debian,
>>>> so that I can sync CUPS again?
>>>
>>> These have been merged and uploaded earlier today.
>>
>> We do I not see them on the GIT?
> 
> … Because I forgot to push, sorry. There you go.
> 
> Cheers,
> 
> OdyX
> 


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/542ad9a3.2090...@gmail.com

Bug#763517: patches breaking color management

[Till Kamppeter]

On 09/30/2014 07:34 PM, Didier Raboud wrote:
> Till: would you have an idea of what is causing #763517 ?
> 

Unfortunately, I have no idea about what is exactly happening here. I
have forwarded this to Joe Simon who created the color management
extension patch. Let's wait for his answer.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/542aebe0.30...@gmail.com

Re: cups-browsed and cups IdleExitTimeout bugs ?

[Till Kamppeter]

On 09/30/2014 06:13 PM, Didier 'OdyX' Raboud wrote:
> Hi Till,
> 
> while I'm integrating the Ubuntu patches in cups and foo2zjs, would you
> mind taking a look at the (excellent) bugs reported by Brian Potkin in
> cups-browsed and cups?
> 
> In cups-browsed:
>   #759348 cups-browsed: May hang for 90 seconds when restart
> 
> This is most certainly upstream-specific, I'd highly welcome your input
> there.
> 

I must look deeper into this.

> In cups:
>   #758284 cups-daemon: IdleExitTimeout appears to be unreliable
>   #758665 cups-daemon: The cups daemon stops and starts continuously when 
> browsing
> 
> These two look like problems brought by your
> cupsd-idleexittimeout.patch, I'd therefore also welcome your input
> there.
> 

I do not know whether an idle exit solution was already accepted
upstream and our patch perhaps forgotten to be removed, or perhaps it
needs to be reduced to only support Upstart (with systemd support
already upstream). So we need to investigate this.

Also under Debian cupsd is started by systemd and probably there are
different modes to choose, either simple permanent, which is like
before, for server/desktop, and on-demand for laptop/mobile. cupsd does
not only need to know whether it was fired up by systemd but also
whether in permanent or on-demand mode, and only time out in the latter
mode.

On Ubuntu there are no complaints yet, but we use Upstart and only the
permanent mode currently. For the on-demand only short tests were done,
no long-term investigations.

   Till



-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/542b1a1b.2000...@gmail.com

Re: Bug#764253: system-config-printer: Creates millions of ppd symlinks

[Till Kamppeter]

I have forwarded this report to Tim Waugh from Red Hat, original author
of system-config-printer and he has answered me the following:

--
> can you check this ppdcache.py problem mentioned here?

I've committed a change which should stop the looping by failing the
call on IOError.
https://git.fedorahosted.org/cgit/system-config-printer.git/commit/?h=1.4.x&id=9a81dd1de3afaf30eec92045429029103823b577

> And why is scp-dbus-service doing something when a job is printed?

You're in a better position to find that out. It doesn't do that for me.

Run "scp-dbus-service --debug" before printing, and see which D-Bus call
it receives. Or watch dbus-monitor --session.

By the way, you know about CUPS STR #4500, right..?
  https://cups.org/str.php?L4500
--

For the two bugs you mentioned there are fixes now:

> Thus I think there are two bugs here:
>  * cups should not create files with wrong permissions in /etc/cups/ppd

CUPS STR #4500: https://cups.org/str.php?L4500

>  * scp-dbus-service should not start an infinite loop creating millions
>of symlinks in /tmp just because the permissions in /etc/cups/ppd
>are wrong

https://git.fedorahosted.org/cgit/system-config-printer.git/commit/?h=1.4.x&id=9a81dd1de3afaf30eec92045429029103823b577

The only strange thing is that scp-dbus-service gets triggered by simply
printing. So can you please try what Tim suggests:

--
Run "scp-dbus-service --debug" before printing, and see which D-Bus call
it receives. Or watch dbus-monitor --session.
--

and post your results here? Thanks.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5447d7c9.5010...@gmail.com

Back to Debian/Ubuntu sync of the CUPS package

[Till Kamppeter]

Hi,

I have now commited a change on the Ubuntu-only AppArmor profile patch
to merge in the changes of Jamie Strandboge's Ubuntu releases of the
CUPS package, 1.7.5-3ubuntu1 and 1.7.5-3ubuntu2 (see
https://launchpad.net/ubuntu/+source/cups/+changelog). This way from the
next Debian release of CUPS on I can sync the CUPS package again.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/544d36eb.1030...@gmail.com

Bug#766334: BrowseAllow all gets into cups-browsed.conf by default resulting in no remote printers

[Till Kamppeter]

On 10/30/2014 08:29 AM, Didier 'OdyX' Raboud wrote:
> Hi Michal, and thanks for your bugreport,
> 
> I think I understand the problem you're having, let's see.
> 
> Le mercredi, 22 octobre 2014, 13.12:51 Michal Hocko a écrit :
>> (..)
>> Of course I had
>> BrowseAllow all
>>
>> present and that caused all remote printers being disallowed by
>> default.
> 
> Are you saying that all "BrowseAllow" stanzas _but_ "BrowseAllow all" 
> should have been taken over by cups-browsed?
> 
>> Maybe postinstall script can ask whether such an option should be
>> added if those options cannot be ignored by default.
> 
> We try to avoid doing explicit prompts unless really _really_ important, 
> we're not in such a case here…
> 
> Till: What would you think of the above proposal? It kinda-makes sense 
> for me: in CUPS < 1.5 meaning, "BrowseAllow all" meant "accept packets 
> from anywhere", but in cups-browsed meaning, this is completely 
> discarded, and the same meaning is achieved without any 'BrowseAllow' 
> stanza. I'd welcome your input there.
> 

The "Browse..." directive implementation was done by Tim Waugh as part
of the legacy CUPS broadcasting/browsing support. I do not know the
exact details, especially not of combinations of various lines. I only
know that all clients are allowed if no line is given.

Tim, can you help here? Thanks,

   Till

P. S.: Tim, please use "Reply all" so that your answer gets tracked with
the Debian bug report.


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54520e88.7060...@gmail.com

Bug#766334: BrowseAllow all gets into cups-browsed.conf by default resulting in no remote printers

[Till Kamppeter]

On 10/30/2014 01:13 PM, Tim Waugh wrote:
> I've added support for 'BrowseAllow All' in revno 7303.
> 

Tim, thank you very much for the quick help.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54522f33.1060...@gmail.com

Bug#758626: cups-browsed: uses a lot of CPU on a busy network

[Till Kamppeter]

I by myself have never tested cups-browsed with that many printers or
otherwise very noisy networks. It is also the first time that someone
reports that cups-browsed takes a lot of CPU.

cups-browsed is running an event loop and if an event (= broadcast
signal from local avahi-daemon or from remote CUPS server) happens, a
callback function to create, update, or remove a print queue is executed.

Important to know is also what kind of broadcasting the remote servers
are doing. Are they running newer CUPS versions and so using Bonjour for
broadcasting (cups-browsed is then triggered by the local avahi-daemon)
or are these older servers using CUPS broadcasting (cups-browsed uses
the legacy CUPS browsing facility then)?

Can you deactivate CUPS browsing via cups-browsed.conf? If some printers
go away on your local system then you indded have servers using the old
method. Does the system load caused by cups-browsed go down now? Perhaps
upgrading old servers to have all broadcasting being Bonjour could help.

Is there a lot of Bonjour broadcasting in your network, also from other
devices, like file servers or so? You can see this running the
"avahi-discover" command.

Is your local machine sharing CUPS printers? Did you turn on the legacy
CUPS broadcasting of your local cups-browsed to share to old clients?
Try to turn this off and in case of success, update the CUPS on these
clients.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54539bc1.5060...@gmail.com

Bug#712512: Ghostscript seems to be working

[Till Kamppeter]

Your problem seems to be a bad interference between your printer and the
USB CUPS backend. Please follow the instructions of the section

USB printer does not print or prints garbage

on

https://wiki.ubuntu.com/DebuggingPrintingProblems

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54540e99.4020...@gmail.com

Bug#712512: Ghostscript seems to be working; usb problem

[Till Kamppeter]

On 11/01/2014 09:17 PM, ael wrote:
> On Fri, Oct 31, 2014 at 11:35:05PM +0100, Till Kamppeter wrote:
>> USB printer does not print or prints garbage
>>
>> on
>>
>> https://wiki.ubuntu.com/DebuggingPrintingProblems
> 
> Somehow my last message repeated -o usb-no-reattach-default=true
> when the first should have been -o usb-unidir-default=true .
> 
> That is either option fixes the bug it seems.
> 
> I am editing /usr/share/cups/usb/org.cups.usb-quirks for now but it is
> not clear to me which option to use: unidir or no-reattach? Which is 
> preferable?
> 
> Meanwhile should I report upstream to http://www.cups.org/str.php?
> 
> ael
> 

I f only unidir (no-reattach removed) works, use unidir.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5457a2ca.2030...@gmail.com

Bug#768163: CUPS and CM option

[Till Kamppeter]

I think we do not really need this patch. What is does is allowing to
set color calibration mode as default setting for a print queue via the
CUPS web interface. But this option should only be set when calibrating
the printer, not permanently, so Mike Sweet is right that this is a
per-job option. It makes much more sense to post feature requests for
the print dialogs (GTK, KDE, ...) or even to let it only get supplied by
color calibration apps when sending the jobs with the calibrartion pages.

The actual execution of the option happens completely in cups-filters,
as the color correction based on the ICC profiles is done there.

   Till

On 11/23/2014 01:50 PM, Didier 'OdyX' Raboud wrote:
> Hi Joe, hi Till,
> 
> As you might have seen from this Debian bug (#768163), the Color 
> management option is missing all non-english translations.
> 
> I must say that I'm quite concerned by this Color management patch for 
> the following reasons:
> - Debian's now in freeze; adding HTML template patches across 9
>   languages (without having resources to translate these…) is slightly
>   invasive for this freeze phase.
> - In https://www.cups.org/str.php?L4462, upstream basically refused to
>   accept your patch on a longer term. I will _not_ adopt the maintenance
>   of this patch as Debian maintainer, so that questions the long-term
>   maintainability of this patch.
> - There's still #763517 about a failure to work correctly (which is
>   arguably in need of more info from the submitter).
> 
> I'm now considering either of these options:
> a) Leave it "as-is" for Jessie; this leaves CUPS in jessie with no non-
> english translations for this feature at the advantage of not needing 
> much work. I'm still questioning the responsibility for that patch over 
> the course of the jessie stable release lifecycle.
> 
> b) Patch 9 translations with english content; this makes CUPS in jessie 
> with english texts in native translations, and I'm not sure that it will 
> be accepted at this point of the release cycle by the release team.
> 
> c) Drop the Color Management patch entirely for the Jessie release 
> cycle: given that upstream has released the 2.0.x series and that, as 
> far as I know, there is no color-management patch available for that 
> codebase yet (and that upstream has declined to include your patch), I 
> tend to think that this is the most future-proof decision for this 
> patch.
> 
> What's your opinion on this?
> 
> TIA, cheers,
> 
> OdyX
> 
> Le mercredi, 5 novembre 2014, 16.33:26 Pascal Obry a écrit :
>> I just found out that on the CUPS page when defining (or modifying) a
>> printer the "Color Calibration Mode" check box only appears only when
>> the language of the desktop is set to  English.


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5474611b.9030...@gmail.com

Plans on updating to CUPS 2.0.x in Debian and on introducing ippusbxd package?

[Till Kamppeter]

Hi,

what are your plans on upgrading CUPS and introducing ippusbxd in
Debian? I know that there is curremtly a freeze for the next release, so
should I do these steps Ubuntu-only for now and Debian picks them up
after the release? Or will Debian do these steps enough time before FF
of Ubuntu Vivid?

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/547ded6a.3010...@gmail.com

Re: Plans on updating to CUPS 2.0.x in Debian and on introducing ippusbxd package?

[Till Kamppeter]

On 12/02/2014 06:23 PM, Didier 'OdyX' Raboud wrote:
> My plans is to work on these two things "soon", but I have quite limited 
> time and availabilities.
> 
> * My ippusbxd package is mostly ready, and only waits on me to take time 
> to upload it (likely to experimental)
> * CUPS 2.0.x will need more involved work, which I expect to be 
> conducting over the next month, possibly over the end-of-year vacations.
>

Thanks for the info.

> I'll keep the list posted. :-) When is the feature freeze of Vivid?
> 

Usually end of February 2015, not earlier the 20th.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/547df790.7060...@gmail.com

CUPS release for Debian

[Till Kamppeter]

Hi,

I have pushed a small bug fix to the Debian GIT repo of CUPS. As we want 
to SRU it into the Trusty and Utopic releases of Ubuntu and for that the 
fix has to go into Vivid first I would be very grateful if you could 
upload the current state to Debian (Experimental if Unstable is frozen) 
so that I can sync. If not, please tell me and I do an Ubuntu-only 
update with the fix.


Thanks in advance

   Till


--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54d21a0c.5000...@gmail.com

Re: CUPS release for Debian

[Till Kamppeter]

On 04.02.2015 13:39, Didier 'OdyX' Raboud wrote:

Hi Till, and thanks for your mail,

Le mercredi, 4 février 2015, 11.09:32 Till Kamppeter a écrit :

I have pushed a small bug fix to the Debian GIT repo of CUPS. As we
want to SRU it into the Trusty and Utopic releases of Ubuntu and for
that the fix has to go into Vivid first I would be very grateful if
you could upload the current state to Debian (Experimental if
Unstable is frozen) so that I can sync. If not, please tell me and I
do an Ubuntu-only update with the fix.


Hmm. The patch for "Fix -h option not honoured when CUPS_SERVER variable
is defined (LP: #1352809)" doesn't seem to match upstream's for STR4528,
no?

Any reason not to backport the complete patch?
Cheers,
OdyX



See the comments of Louis Bouchard, the contributor of this patch, on

https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1352809

   Till


--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54d29f17.4020...@gmail.com

CUPS 2.0.2

[Till Kamppeter]

Hi,

have you already started working on the transition to CUPS 2.0.x for Debian?

I did not see anythin in the GIT and start now to work on it as on Feb 
17 we have Feature Freeze. If you have done already some parts, please 
create a branch on the GIT or send me the stuff you have already done in 
any other form.


Thanks in advance.

   Till


--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54d95151.6080...@gmail.com

Re: CUPS 2.0.2

[Till Kamppeter]

Thank you very much. I will now update the Ubuntu-specific patches and 
remove the remaining USB quirk patches (they are applied upstream, but 
at a different point in the file and therefore the patches still worked, 
leading to harmless duplicate entries).


   Till

On 10.02.2015 15:09, Didier 'OdyX' Raboud wrote:

Hi Till, hi all,

Le lundi, 9 février 2015, 22.31:13 Till Kamppeter a écrit :

have you already started working on the transition to CUPS 2.0.x for
Debian?

I did not see anythin in the GIT and start now to work on it as on Feb
17 we have Feature Freeze. If you have done already some parts,
please create a branch on the GIT or send me the stuff you have
already done in any other form.


So I've taken some time in the last days to work on CUPS 2.0.x and have
now uploaded 2.0.2-1 to Debian experimental few minutes ago :-).

(It FTBFS on non-linux archs apparently, but that's a first start!)

Cheers,
OdyX




--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54da4f97.2090...@gmail.com

Re: CUPS 2.0.2

[Till Kamppeter]

I have pushed these small corrections to the GIT now. With this CUPS 2.x 
is also nicely working on Ubuntu.


   Till

On 10.02.2015 16:36, Till Kamppeter wrote:

Thank you very much. I will now update the Ubuntu-specific patches and
remove the remaining USB quirk patches (they are applied upstream, but
at a different point in the file and therefore the patches still worked,
leading to harmless duplicate entries).

Till

On 10.02.2015 15:09, Didier 'OdyX' Raboud wrote:

Hi Till, hi all,

Le lundi, 9 février 2015, 22.31:13 Till Kamppeter a écrit :

have you already started working on the transition to CUPS 2.0.x for
Debian?

I did not see anythin in the GIT and start now to work on it as on Feb
17 we have Feature Freeze. If you have done already some parts,
please create a branch on the GIT or send me the stuff you have
already done in any other form.


So I've taken some time in the last days to work on CUPS 2.0.x and have
now uploaded 2.0.2-1 to Debian experimental few minutes ago :-).

(It FTBFS on non-linux archs apparently, but that's a first start!)

Cheers,
OdyX






--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54da5a17.3050...@gmail.com

Re: Plans on updating to CUPS 2.0.x in Debian and on introducing ippusbxd package?

[Till Kamppeter]

On 11.02.2015 18:27, Didier 'OdyX' Raboud wrote:

Hi Till,

Le mardi, 2 décembre 2014, 18.23:09 Didier 'OdyX' Raboud a écrit :

My plans is to work on these two things "soon", but I have quite
limited time and availabilities.

* My ippusbxd package is mostly ready, and only waits on me to take
time to upload it (likely to experimental)


So, been there, done that; it's uploaded to unstable, but is stuck in
NEW, in which it will probably stay until the Jessie release.

Packaging is there:

http://anonscm.debian.org/cgit/printing/ippusbxd.git

Note that I named the binary package "ippusbxd" and not cups-filters-
ippusbxd. The Conflicts, Replaces and Provides are in place and
shouldn't be a problem to import straight ahead in Ubuntu.

Cheers,
OdyX



Thank you for packaging ippusbxd. The name is absolutely correct as it 
was also my intention for the naming. The name change from 
cups-filters-ippusbxd to ippusbxd is important, as this allows arbitrary 
version numbering (otherwise the ippusbxd project would need higher 
version numbers than cups-filters).


Unfortunately, it is very close to our Feature Freeze and therefore I 
will not be able to introduce the new package into Vivid, but in 15.10 I 
will for sure use it.


   Till


--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54dbf01c.3080...@gmail.com

cups-filters 1.0.65

[Till Kamppeter]

Hi,

I have released cups-filters 1.0.65 last week and also updated the 
Ubuntu package. The Ubuntu package does not contain any patches or any 
other thing which is not in the Debian package. So you can simply 
back-sync it to Debian unstable or experimental.


   Till


--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e50d9e.8090...@gmail.com

Re: CUPS 2.0.2

[Till Kamppeter]

On 11.02.2015 05:17, Didier 'OdyX' Raboud wrote:

Le mardi, 10 février 2015, 17.20:55 Till Kamppeter a écrit :

I have pushed these small corrections to the GIT now. With this CUPS
2.x is also nicely working on Ubuntu.


I've now uploaded 2.0.2-2 with your changes but the removal of the
IdleExitTimeout upstart patch, that wasn't refreshed correctly and FTBFS
the build on !systemd (aka !linux) builds. Feel free to re-introduce it
in a way that allows cups to build reliably when libsystemd is not
available at build-time.

Cheers,
OdyX



This patch is very simple and should not cause an FTBFS, as you write 
that it did not refreash smoothly, it can have hooked in at any weird 
place and not insode the upstart-checkin() function. As the 
upstart-checkin() function is provided by the 
cupsd-upstart-support.patch I will merge 
cupsd-idleexittimeout-upstart.patch into cupsd-upstart-support.patch. WDYT?


If you think that this is not a good idea or if the patch hooked in at 
the right place when the FTBFS accured, please post the output of the 
compiler. Thanks.


   Till



--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e54002.4020...@gmail.com

Re: CUPS 2.0.2

[Till Kamppeter]

On 19.02.2015 06:21, Didier 'OdyX' Raboud wrote:

Le mercredi, 18 février 2015, 23.44:34 Till Kamppeter a écrit :

I've now uploaded 2.0.2-2 with your changes but the removal of the
IdleExitTimeout upstart patch, that wasn't refreshed correctly and
FTBFS the build on !systemd (aka !linux) builds. Feel free to
re-introduce it in a way that allows cups to build reliably when
libsystemd is not available at build-time.


This patch is very simple and should not cause an FTBFS, as you write
that it did not refreash smoothly, it can have hooked in at any weird
place and not insode the upstart-checkin() function. As the
upstart-checkin() function is provided by the
cupsd-upstart-support.patch I will merge
cupsd-idleexittimeout-upstart.patch into cupsd-upstart-support.patch.
WDYT?


Go ahead. I'll upload to experimental and we'll see if the kFreeBSD's
cope with it in a clean way. :)


If you think that this is not a good idea or if the patch hooked in at
the right place when the FTBFS accured, please post the output of the
compiler. Thanks.


https://buildd.debian.org/status/fetch.php?pkg=cups&arch=kfreebsd-i386&ver=2.0.2-1&stamp=1423587871

^ this was the build log on kFreeBSD, with the patch as uploaded.

Cheers, OdyX



Thanks for the log. I have found a solution now. I have re-introduced 
the patch Ubuntu-only, as under Ubuntu there are no non-Linux builds.


One could do it more sophisticated actually, introducing conditionals 
for Upstart, bbut due to the fact that Ubuntu is currently switching 
from Upstart to systemd and so Upstart is getting obsolete I have opted 
for this simple solution.


   Till


--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e5c216.7070...@gmail.com

Re: CUPS 2.0.2

[Till Kamppeter]

On 19.02.2015 08:59, Till Kamppeter wrote:


Thanks for the log. I have found a solution now. I have re-introduced
the patch Ubuntu-only, as under Ubuntu there are no non-Linux builds.

One could do it more sophisticated actually, introducing conditionals
for Upstart, bbut due to the fact that Ubuntu is currently switching
from Upstart to systemd and so Upstart is getting obsolete I have opted
for this simple solution.

Till



I have also committed my most recent changes on the package in Ubuntu 
Vivid now, so the Debian GIT and the Ubuntu package are equal again so 
that it can be synced again.


   Till


--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e5f832.90...@gmail.com

Bug#778940: hplip: please package latest upstream version (3.15.2)

[Till Kamppeter]

On 02/22/2015 01:25 AM, tony mancill wrote:
> Package: hplip
> Version: 3.14.6-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Please consider packaging the latest upstream version.  The attached
> patch will build a working package for 3.15.2.
> 
> Thank you!
> tony
> 

Thank you for the patch. As I have already packaged HPLIP 3.15.2 for
Ubuntu the new package is already available on the Debian Subversion
repository for HPLIP, ready for being released on Debian.

   Till


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e9a140.1050...@gmail.com