gimp-print-devel

Re: [Gimp-print-devel] CUPS backend -- move to its own directory?

[Robert K. <rl...@al...>]

On Fri, 24 May 2019 10:53:52 -0400, Solomon Peachy wrote:
> On Sun, May 19, 2019 at 10:16:04PM -0400, Robert Krawitz wrote:
>> So one question, is there something useful that can be done with a
>> smaller test space (e. g. not the full N-dimensional space, just
>> varying one parameter at a time)?
>
> Yeah, there's no need to exhaustively test the N-dimensional space.  I 
> rarely bother test anything beyond resolution, print size, and 
> (sometimes) lamination.  Once I add support for "expected failures" that 
> will expand a little bit.

Sounds good.

>> That would help a lot.
>
> I changed it to only test 1/1, 1/3, 3/1, and 3/3, and even with recent 
> printer additions the test time is down to about 7.5 minutes.

That's a lot better.  Can your test use the rotor setup (see the CUPS
and run-testpattern-2 tests to see how that works), so jobs can be
farmed off to different machines?  Currently it's split 5 ways.

>> Is there any way you could have your test capture the output from the
>> backend and compute a SHA on it, so you could use it as a regression
>> test?  I understand it might not only be a byte stream that matters,
>> but if you can find a way of encoding anything other than bytes into
>> that stream, that would serve as well.  Basically the same kind of
>> thing run-testpattern-2 does for checksum generation.  I could move
>> compress-checksums and compress-checksums to some place more generic
>> than src/testpattern.
>
> The backend doesn't emit any printer data streams in these debug/test 
> modes, and I don't consider the backend's informative logging output 
> (other than CUPS attribute messages) to be a stable interface.  I have 
> plans to change that (and also do things like emit JSON to make UI 
> wrappers around the status inquires easier to work with) but that's 
> pretty far down the to-do list..

Would it be useful to have an option emit printer data streams, or are
those simply the unprocessed data from the driver with some out of
band protocol that can't be captured as a data stream?  That would
allow saving checksums from these tests like we do from the
run-testpattern-2 tests.
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] CUPS backend -- move to its own directory?

[Solomon P. <pi...@sh...>]

On Sun, May 19, 2019 at 10:16:04PM -0400, Robert Krawitz wrote:
> So one question, is there something useful that can be done with a
> smaller test space (e. g. not the full N-dimensional space, just
> varying one parameter at a time)?

Yeah, there's no need to exhaustively test the N-dimensional space.  I 
rarely bother test anything beyond resolution, print size, and 
(sometimes) lamination.  Once I add support for "expected failures" that 
will expand a little bit.

> That would help a lot.

I changed it to only test 1/1, 1/3, 3/1, and 3/3, and even with recent 
printer additions the test time is down to about 7.5 minutes.

> Is there any way you could have your test capture the output from the
> backend and compute a SHA on it, so you could use it as a regression
> test?  I understand it might not only be a byte stream that matters,
> but if you can find a way of encoding anything other than bytes into
> that stream, that would serve as well.  Basically the same kind of
> thing run-testpattern-2 does for checksum generation.  I could move
> compress-checksums and compress-checksums to some place more generic
> than src/testpattern.

The backend doesn't emit any printer data streams in these debug/test 
modes, and I don't consider the backend's informative logging output 
(other than CUPS attribute messages) to be a stable interface.  I have 
plans to change that (and also do things like emit JSON to make UI 
wrappers around the status inquires easier to work with) but that's 
pretty far down the to-do list..

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
Coconut Creek, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

Re: [Gimp-print-devel] Missing dependency check in 'make distcheck-minimal'

[Robert K. <rl...@al...>]

On Thu, 23 May 2019 09:14:25 -0400, Solomon Peachy wrote:
> Here's the output out of my automated build system:
>
> $ make distcheck-minimal
> STP_TEST_PROFILE=`echo distcheck-minimal |sed -e s/distcheck-// -e 
> s/-/_/g -e s/parallel//` STP_PARALLEL=`scripts/count-cpus` 
> STP_TEST_SUITE=1 STP_TEST_DIST=1 /usr/bin/time make -k -s 
> -j`scripts/count-cpus` DISTCHECK_CONFIGURE_FLAGS=NO_PKGCONFIG_PATHS=1 distcheck
>  (cd include && make  top_distdir=../gutenprint-5.3.2-pre1 
> distdir=../gutenprint-5.3.2-pre1/include \
>      am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
>  (cd gutenprint && make  top_distdir=../../gutenprint-5.3.2-pre1 
> distdir=../../gutenprint-5.3.2-pre1/include/gutenprint \
>      am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
>  (cd gutenprintui2 && make  top_distdir=../../gutenprint-5.3.2-pre1 
> distdir=../../gutenprint-5.3.2-pre1/include/gutenprintui2 \
>      am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
> /bin/sh: line 1: --fhead: command not found
> make[7]: *** [Makefile:712: typebuiltins.h] Error 127
> make[7]: Target 'distdir-am' not remade because of errors.
> make[6]: *** [Makefile:544: distdir] Error 2
> make[5]: *** [Makefile:571: distdir-am] Error 1
> make[4]: *** [Makefile:567: distdir] Error 2
> make[3]: *** [Makefile:721: distdir-am] Error 1
> make[2]: *** [Makefile:715: distdir] Error 2
> make[2]: Target 'dist-xz' not remade because of errors.
> make[2]: Target 'dist-bzip2' not remade because of errors.
> make[1]: *** [Makefile:818: dist] Error 2
> make[1]: Target 'distcheck' not remade because of errors.
> Command exited with non-zero status 2
>
> It's relying on 'glib-mkenums' (part of the 'glib2-devel' in 
> RedHat-land) but there's no check in the bootstrap or configure script 
> for this.  Just a confusing error message.  :)

Where exactly is this happening?  That looks like you've elided
something, so I don't have the full context.

This should only be getting run during a maintainer build; the tarball
should have the file.  In that case, this should be the fix:

diff --git a/scripts/autogen.sh b/scripts/autogen.sh
index c91f1c37..bb8e89c5 100644
--- a/scripts/autogen.sh
+++ b/scripts/autogen.sh
@@ -50,6 +50,13 @@ else
   libtool_err=1
 fi
 
+if [ -z "`type -p glib-mkenums`" ] ; then
+  echo
+  echo "**Error**: You must have \`glib2-mkenums' installed to create a"
+  echo "Gutenprint distribution.  This is usually distributed in the"
+  echo "glib2-devel, glib2-dev, or similar package."
+  DIE=1
+fi
 
 if [ -n "$libtool_err" ] ; then
   echo

-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] 5.3

[Solomon P. <pi...@sh...>]

On Wed, May 22, 2019 at 08:32:51PM -0400, Robert Krawitz wrote:
> This will need to be noted in the announcement (which I'll hold
> pending at least documentation of the workaround here), along with the
> workaround; could it be fixed in 5.2.15 final?

FWIW I don't know if the blacklist ever worked on OSX.

> "Prevented printing from working" could be anything from a single
> printer to everything; what is this?

Single printer (Sony UP-CR10L) but possibly affecting a couple of others 
too (UP-DR150 and UP-DR200).

> 5.3.2-pre1 has been all over the place.  Maybe we should go right to
> 5.3.3, and as soon as that's stable on the Mac go to 5.4 and call that
> the new stable series?  I'd really like to tie off 5.2.  The release
> process for 5.2 is a lot more manual than for 5.3, so more chances for
> things to go wrong (e. g. 5.2.13 was never tagged!), and I think the
> tests for 5.3 are a lot better than for 5.2.

I'd like to see 5.2 wrapped up too.  

I wonder if it might make more sense, for 5.3, to stop bothering with 
-pre builds, and more rapidly iterate the version number?

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
Coconut Creek, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

[Gimp-print-devel] Missing dependency check in 'make distcheck-minimal'

[Solomon P. <pi...@sh...>]

Here's the output out of my automated build system:

$ make distcheck-minimal
STP_TEST_PROFILE=`echo distcheck-minimal |sed -e s/distcheck-// -e 
s/-/_/g -e s/parallel//` STP_PARALLEL=`scripts/count-cpus` 
STP_TEST_SUITE=1 STP_TEST_DIST=1 /usr/bin/time make -k -s 
-j`scripts/count-cpus` DISTCHECK_CONFIGURE_FLAGS=NO_PKGCONFIG_PATHS=1 distcheck
 (cd include && make  top_distdir=../gutenprint-5.3.2-pre1 
distdir=../gutenprint-5.3.2-pre1/include \
     am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
 (cd gutenprint && make  top_distdir=../../gutenprint-5.3.2-pre1 
distdir=../../gutenprint-5.3.2-pre1/include/gutenprint \
     am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
 (cd gutenprintui2 && make  top_distdir=../../gutenprint-5.3.2-pre1 
distdir=../../gutenprint-5.3.2-pre1/include/gutenprintui2 \
     am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
/bin/sh: line 1: --fhead: command not found
make[7]: *** [Makefile:712: typebuiltins.h] Error 127
make[7]: Target 'distdir-am' not remade because of errors.
make[6]: *** [Makefile:544: distdir] Error 2
make[5]: *** [Makefile:571: distdir-am] Error 1
make[4]: *** [Makefile:567: distdir] Error 2
make[3]: *** [Makefile:721: distdir-am] Error 1
make[2]: *** [Makefile:715: distdir] Error 2
make[2]: Target 'dist-xz' not remade because of errors.
make[2]: Target 'dist-bzip2' not remade because of errors.
make[1]: *** [Makefile:818: dist] Error 2
make[1]: Target 'distcheck' not remade because of errors.
Command exited with non-zero status 2

It's relying on 'glib-mkenums' (part of the 'glib2-devel' in 
RedHat-land) but there's no check in the bootstrap or configure script 
for this.  Just a confusing error message.  :)

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
Coconut Creek, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

Re: [Gimp-print-devel] 5.3

[Robert K. <rl...@al...>]

On Tue, 21 May 2019 15:19:33 -0400, Solomon Peachy wrote:
> On Mon, May 13, 2019 at 12:15:12PM -0400, Solomon Peachy wrote:
>> I'll pass this image along to the two folks I'm talking to right now, to 
>> try and see if the baseline functionality is there, at least.
>
> Just FYI, the 5.2 build "worked" insofar as the backend was recognized 
> and communicated with the printer.  Two problems:
>
>  * The blacklist didn't work, and OSX defaulted to using the standard 
>    'usb' backend.  User was able to switch backends via the CUPS web UI.

This will need to be noted in the announcement (which I'll hold
pending at least documentation of the workaround here), along with the
workaround; could it be fixed in 5.2.15 final?

>  * A (known) job parsing bug in the backend prevented printing from 
>    working.

"Prevented printing from working" could be anything from a single
printer to everything; what is this?

> I just passed on the 5.3.2-pre1 image that Steve built and we'll see if 
> that behaves any better.

5.3.2-pre1 has been all over the place.  Maybe we should go right to
5.3.3, and as soon as that's stable on the Mac go to 5.4 and call that
the new stable series?  I'd really like to tie off 5.2.  The release
process for 5.2 is a lot more manual than for 5.3, so more chances for
things to go wrong (e. g. 5.2.13 was never tagged!), and I think the
tests for 5.3 are a lot better than for 5.2.
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Gimp-print-devel] Canon printer does not work on mac

[Dmitry R. <dmi...@gm...>]

Hallo,
I have tried to use a Canon Selphy ES20 printer on mac (High Sierra
10.13.6).
My version of gutenprint is 5.2.14
I have added a printer with gutenprint driver and it looks like the system
sees it

Dmitrys-MacBook-Pro:~ indim$ lpstat -v

device for Canon_ES20:
usb://Canon/ES20?serial=0356D845A90F4122BCE476321072C521

device for EPSON_Stylus_Pro_3800:
usb://EPSON/Stylus%20Pro%203800?serial=0JY600803010046540

device for stkPrinter: stk:

However if i try to print a picture (from a Lightroom or other programs) it
sends the task to the printer queue and nothing happens.
It just says "Printing the page 1, 100%" in the queue

Do you know if it is supported or if i did something wrong?
Thanks,
Regards,
Dmitry

Re: [Gimp-print-devel] 5.3

[Solomon P. <pi...@sh...>]

On Mon, May 13, 2019 at 12:15:12PM -0400, Solomon Peachy wrote:
> I'll pass this image along to the two folks I'm talking to right now, to 
> try and see if the baseline functionality is there, at least.

Just FYI, the 5.2 build "worked" insofar as the backend was recognized 
and communicated with the printer.  Two problems:

 * The blacklist didn't work, and OSX defaulted to using the standard 
   'usb' backend.  User was able to switch backends via the CUPS web UI.
 * A (known) job parsing bug in the backend prevented printing from 
   working.

I just passed on the 5.3.2-pre1 image that Steve built and we'll see if 
that behaves any better.

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
Coconut Creek, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

Re: [Gimp-print-devel] CUPS backend -- move to its own directory?

[Robert K. <rl...@al...>]

On Sun, 19 May 2019 21:22:31 -0400, Solomon Peachy wrote:
> On Sat, May 18, 2019 at 10:58:18AM -0400, Robert Krawitz wrote:
>> Is there benefit to valgrinding all of these combinations?  It's
>> possible that there is; I've found a few obscure bugs only due to
>> checking corner cases.
>
> The 1-2 page transtion is most important, but some backends can now do 
> job/copy combining so the 2-3 page transition matters for those too.  So 
> rather than trying to encode all of that complexity into the test 
> definitions, it was just simpler to run it for everything.

Understood.

>> Is this run parallel (which presumably wouldn't be that hard to
>> arrange)?  Test vectors like this are normally embarrassingly
>> parallel, so with 8 core/16 threads I typically get in the range of
>> 12x over single thread.  And if the Ryzen 3000 really is as good as
>> the rumors have it and if I upgrade off-cycle.  Well.
>
> Both phases are set up to max out the core/thread count in the 
> system, so on my box, those jobs run with 8 threads in parallel.

So one question, is there something useful that can be done with a
smaller test space (e. g. not the full N-dimensional space, just
varying one parameter at a time)?

>> That's a reasonable mockup environment.  This is part of the CUPS tree
>> (even if we put it in a subtree), so we could set up the dependencies
>> such that the CUPS driver is built in-tree for it.
>
> All the test script really cares about is where to find genpppd and 
> rastertogutenprint.  I now have those settable via an environment 
> variable.

You can do that referenced to the build root.  Look at the code in
src/cups/test-rastertogutenprint.in.

>> You probably don't need to run all 9 combinations; 1/1, 1/3, and 3/3
>> would seem likely to be what you'd need unless there's some specific
>> reason to do more (maybe even 1/1, 1/2, and 2/2 or 2/3).  That would
>> cut the space down by a factor of 3.
>
> Yeah, I don't envision a 3/3 job passing if 2/2 does not.

That would help a lot.

>> As for the VID and PID, we could either add those to printers.xml or
>> you could have a separate .xml file that contains them (VID and PID
>> are standard USB attributes, which are generic attributes and might at
>> some point matter for other printers).  Then you could have a program
>> similar to src/testpattern/printer_options that extracts them and
>> passes the data off to a run-testpattern-2 type program that generates
>> the combinations.
>
> Probably makes the most sense to put VID/PIDs into printers.xml.  The 
> rest, probably not.

That's hardware information that's relevant to all USB-connected
printers, which are the large majority of printers we support.  It's
certainly something that could be useful for printer detection.

>> Right now we don't have any actual printer emulation in our test suite.
>
> There's still no substitute for actual hardrware.  I now have all of the 
> low-hanging stuff covered, but now it gets trickier..

Is there any way you could have your test capture the output from the
backend and compute a SHA on it, so you could use it as a regression
test?  I understand it might not only be a byte stream that matters,
but if you can find a way of encoding anything other than bytes into
that stream, that would serve as well.  Basically the same kind of
thing run-testpattern-2 does for checksum generation.  I could move
compress-checksums and compress-checksums to some place more generic
than src/testpattern.
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] CUPS backend -- move to its own directory?

[Solomon P. <pi...@sh...>]

On Sat, May 18, 2019 at 10:58:18AM -0400, Robert Krawitz wrote:
> Is there benefit to valgrinding all of these combinations?  It's
> possible that there is; I've found a few obscure bugs only due to
> checking corner cases.

The 1-2 page transtion is most important, but some backends can now do 
job/copy combining so the 2-3 page transition matters for those too.  So 
rather than trying to encode all of that complexity into the test 
definitions, it was just simpler to run it for everything.

> Not unless we had a separate repository for it, that's for certain!
> And obviously we wouldn't want that in the default pipeline.  But
> hardware people have test data that make that look insignificant by
> comparison.

I want to greatly expand that test suite, but now that the 
gutenprint-generated stuff is automated, a lot of the problem space gets 
encompassed by that.

> Is this run parallel (which presumably wouldn't be that hard to
> arrange)?  Test vectors like this are normally embarrassingly
> parallel, so with 8 core/16 threads I typically get in the range of
> 12x over single thread.  And if the Ryzen 3000 really is as good as
> the rumors have it and if I upgrade off-cycle.  Well.

Both phases are set up to max out the core/thread count in the 
system, so on my box, those jobs run with 8 threads in parallel.

> That's a reasonable mockup environment.  This is part of the CUPS tree
> (even if we put it in a subtree), so we could set up the dependencies
> such that the CUPS driver is built in-tree for it.

All the test script really cares about is where to find genpppd and 
rastertogutenprint.  I now have those settable via an environment 
variable.

> You probably don't need to run all 9 combinations; 1/1, 1/3, and 3/3
> would seem likely to be what you'd need unless there's some specific
> reason to do more (maybe even 1/1, 1/2, and 2/2 or 2/3).  That would
> cut the space down by a factor of 3.

Yeah, I don't envision a 3/3 job passing if 2/2 does not.

> As for the VID and PID, we could either add those to printers.xml or
> you could have a separate .xml file that contains them (VID and PID
> are standard USB attributes, which are generic attributes and might at
> some point matter for other printers).  Then you could have a program
> similar to src/testpattern/printer_options that extracts them and
> passes the data off to a run-testpattern-2 type program that generates
> the combinations.

Probably makes the most sense to put VID/PIDs into printers.xml.  The 
rest, probably not.

> Right now we don't have any actual printer emulation in our test suite.

There's still no substitute for actual hardrware.  I now have all of the 
low-hanging stuff covered, but now it gets trickier..

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
Coconut Creek, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

Re: [Gimp-print-devel] CUPS backend -- move to its own directory?

[Robert K. <rl...@al...>]

On Sat, 18 May 2019 08:40:59 -0400, Solomon Peachy wrote:
> On Fri, May 17, 2019 at 09:21:42PM -0400, Robert Krawitz wrote:
>> BTW, IIRC you were working on a test suite for the backend; is that
>> something you could add in?
>
> What I have works well, but integrates poorly. It has two components:
>
>  * The first works against a library of pre-generated test jobs of 
>    various sources (Windows, misc gutenprint releases) that exhibit 
>    quirks that might not be in the current gutenprint codebase. Here's
>    a typical entry:
>
>      #backend,vid,pid,filename,mediatype
>      shinko-s1245,0x10ce,0x0007,shinko_s1245_8x10.raw,0x0
>
>    Each entry is run with valgrind, and 1-3 copies, 3 times total.
>    (Takes 12 minutes on my E3-1230 V2 server)

Is there benefit to valgrinding all of these combinations?  It's
possible that there is; I've found a few obscure bugs only due to
checking corner cases.

>    As this phase depends on a .5GB library of job files, there's 
>    probably little point in attempting to integrate it.

Not unless we had a separate repository for it, that's for certain!
And obviously we wouldn't want that in the default pipeline.  But
hardware people have test data that make that look insignificant by
comparison.

>  * The second is more comprehensive, and relies on the *installed* 
>    gutenprint cups filter to generate test jobs.  Here's the set of 
>    entries for the same model:
>
>     #gp_printername,vid,pid,mediatype,gp_options
>     shinko-chcs1245,0x10ce,0x0007,0,PageSize=w288h576
>     shinko-chcs1245,0x10ce,0x0007,0,PageSize=w360h576
>     shinko-chcs1245,0x10ce,0x0007,0,PageSize=w432h576
>     shinko-chcs1245,0x10ce,0x0007,0,PageSize=w576h576
>     shinko-chcs1245,0x10ce,0x0007,0,PageSize=w576h576-div2
>     shinko-chcs1245,0x10ce,0x0007,0,PageSize=c8x10
>     shinko-chcs1245,0x10ce,0x0007,0,PageSize=c8x10-div2
>     shinko-chcs1245,0x10ce,0x0007,0,PageSize=c8x10-w576h432_w576h288
>     shinko-chcs1245,0x10ce,0x0007,1,PageSize=w576h864
>     shinko-chcs1245,0x10ce,0x0007,1,PageSize=w576h864-div2
>     shinko-chcs1245,0x10ce,0x0007,1,PageSize=w576h864-div3
>     shinko-chcs1245,0x10ce,0x0007,0,PageSize=c8x10;StpLamination=Glossy
>     shinko-chcs1245,0x10ce,0x0007,0,PageSize=c8x10;StpLamination=GlossyFine
>     shinko-chcs1245,0x10ce,0x0007,0,PageSize=c8x10;StpLamination=Matte
>     shinko-chcs1245,0x10ce,0x0007,0,PageSize=c8x10;StpLamination=MatteFine
>
>    Jobs are generated with 1-3 pages, and with 1-3 copies, for a total 
>    of 9 jobs per entry.  Current suite takes 51 minutes on the same 
>    Xeon box, without valgrind.  I only bother with options that the job 
>    parsing/sanity checking code checks or otherwise affects the 
>    command stream sent to the printer.  (stuff that's just blindly 
>    passed on is assumed to be okay)

Is this run parallel (which presumably wouldn't be that hard to
arrange)?  Test vectors like this are normally embarrassingly
parallel, so with 8 core/16 threads I typically get in the range of
12x over single thread.  And if the Ryzen 3000 really is as good as
the rumors have it and if I upgrade off-cycle.  Well.

> In both cases, I need the vid/pid to spoof the backend's printer 
> scan/attach code, and the media code is used in lieu of a real printer 
> reporting its loaded media type.

That's a reasonable mockup environment.  This is part of the CUPS tree
(even if we put it in a subtree), so we could set up the dependencies
such that the CUPS driver is built in-tree for it.

> Notable weaknesses:
>
>   * Test metadata & option combos must be manually constructed.

You probably don't need to run all 9 combinations; 1/1, 1/3, and 3/3
would seem likely to be what you'd need unless there's some specific
reason to do more (maybe even 1/1, 1/2, and 2/2 or 2/3).  That would
cut the space down by a factor of 3.

As for the VID and PID, we could either add those to printers.xml or
you could have a separate .xml file that contains them (VID and PID
are standard USB attributes, which are generic attributes and might at
some point matter for other printers).  Then you could have a program
similar to src/testpattern/printer_options that extracts them and
passes the data off to a run-testpattern-2 type program that generates
the combinations.

>   * Backend-centric; uses installed gutenprint filter.  This is 
>     a reflection of how the backend code is developed, and is easily fixed.
>   * No ability to handle an "expected failure" (eg print 5x7" with 6x4" 
>     media loaded)

Again, that could be changed.

>   * Only tests through the parsing stage, as anything further requires 
>     emulating printer comms/behaviors.

Right now we don't have any actual printer emulation in our test suite.
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] CUPS backend -- move to its own directory?

[Solomon P. <pi...@sh...>]

On Fri, May 17, 2019 at 09:21:42PM -0400, Robert Krawitz wrote:
> BTW, IIRC you were working on a test suite for the backend; is that
> something you could add in?

What I have works well, but integrates poorly. It has two components:

 * The first works against a library of pre-generated test jobs of 
   various sources (Windows, misc gutenprint releases) that exhibit 
   quirks that might not be in the current gutenprint codebase. Here's
   a typical entry:

     #backend,vid,pid,filename,mediatype
     shinko-s1245,0x10ce,0x0007,shinko_s1245_8x10.raw,0x0

   Each entry is run with valgrind, and 1-3 copies, 3 times total.
   (Takes 12 minutes on my E3-1230 V2 server)

   As this phase depends on a .5GB library of job files, there's 
   probably little point in attempting to integrate it.

 * The second is more comprehensive, and relies on the *installed* 
   gutenprint cups filter to generate test jobs.  Here's the set of 
   entries for the same model:

    #gp_printername,vid,pid,mediatype,gp_options
    shinko-chcs1245,0x10ce,0x0007,0,PageSize=w288h576
    shinko-chcs1245,0x10ce,0x0007,0,PageSize=w360h576
    shinko-chcs1245,0x10ce,0x0007,0,PageSize=w432h576
    shinko-chcs1245,0x10ce,0x0007,0,PageSize=w576h576
    shinko-chcs1245,0x10ce,0x0007,0,PageSize=w576h576-div2
    shinko-chcs1245,0x10ce,0x0007,0,PageSize=c8x10
    shinko-chcs1245,0x10ce,0x0007,0,PageSize=c8x10-div2
    shinko-chcs1245,0x10ce,0x0007,0,PageSize=c8x10-w576h432_w576h288
    shinko-chcs1245,0x10ce,0x0007,1,PageSize=w576h864
    shinko-chcs1245,0x10ce,0x0007,1,PageSize=w576h864-div2
    shinko-chcs1245,0x10ce,0x0007,1,PageSize=w576h864-div3
    shinko-chcs1245,0x10ce,0x0007,0,PageSize=c8x10;StpLamination=Glossy
    shinko-chcs1245,0x10ce,0x0007,0,PageSize=c8x10;StpLamination=GlossyFine
    shinko-chcs1245,0x10ce,0x0007,0,PageSize=c8x10;StpLamination=Matte
    shinko-chcs1245,0x10ce,0x0007,0,PageSize=c8x10;StpLamination=MatteFine

   Jobs are generated with 1-3 pages, and with 1-3 copies, for a total 
   of 9 jobs per entry.  Current suite takes 51 minutes on the same 
   Xeon box, without valgrind.  I only bother with options that the job 
   parsing/sanity checking code checks or otherwise affects the 
   command stream sent to the printer.  (stuff that's just blindly 
   passed on is assumed to be okay)

In both cases, I need the vid/pid to spoof the backend's printer 
scan/attach code, and the media code is used in lieu of a real printer 
reporting its loaded media type.

Notable weaknesses:

  * Test metadata & option combos must be manually constructed.
  * Backend-centric; uses installed gutenprint filter.  This is 
    a reflection of how the backend code is developed, and is easily fixed.
  * No ability to handle an "expected failure" (eg print 5x7" with 6x4" 
    media loaded)
  * Only tests through the parsing stage, as anything further requires 
    emulating printer comms/behaviors.

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
Coconut Creek, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

Re: [Gimp-print-devel] CUPS backend -- move to its own directory?

[Robert K. <rl...@al...>]

On Fri, 17 May 2019 19:53:52 -0400, Solomon Peachy wrote:
> On Fri, May 17, 2019 at 01:17:26PM -0400, Robert Krawitz wrote:
>> Solomon, do you think it would make sense to move the backend to its
>> own directory under src/cups?
>
> No objections from me.

BTW, IIRC you were working on a test suite for the backend; is that
something you could add in?
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] CUPS backend -- move to its own directory?

[Robert K. <rl...@al...>]

On Fri, 17 May 2019 19:53:52 -0400, Solomon Peachy wrote:
> On Fri, May 17, 2019 at 01:17:26PM -0400, Robert Krawitz wrote:
>> Solomon, do you think it would make sense to move the backend to its
>> own directory under src/cups?
>
> No objections from me.

It's a a pretty big chunk of code just by its lonesome.

>> Only thing is, as long as we're doing 5.2 releases, doing backports
>> might be a bit more of a pain for you.
>
> Right now I'm only backporting what I consider to be critical bugfixes.  
> Due to signifcant internal differences, it's already a mostly manual 
> affair.
>
> To ease my maintainence burden, I've debated just syncing up the 5.2 
> branch with the master backend code; it's fully backwards compatible.
>
> But I have no plans to backport any of the dyesub printer additions.
>
> Most of the dyesub users that contact me are using LTS-type distros with 
> relatively ancient gutenprint builds.  Since they generally need to 
> recompile gutenprint from source anyway, I've been handing them 5.3 
> snapshots.  (And then only if recompiling the backend isn't sufficient)
>
> Granted, that still leaves out OSX users...

Hopefully not for long, now.

Maybe it's time to just declare that 5.2.15 will be the last 5.2
release barring disaster (like security hole) and as of 5.3.3 (or
maybe 5.4.0?) that should be declared stable.  I have more confidence
now in 5.3 than 5.2; for one, we actually have a repeatable build/test
pipeline.  I usually manage to goof something doing a 5.2 build, and
the backend_sinfonia.h thing likely would have slipped through unless
I thought to do a make distcheck.  The build-release script in 5.3
pretty well puts paid to all that.
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Backend isn't building

[Solomon P. <pi...@sh...>]

On Fri, May 17, 2019 at 08:51:11PM -0400, Robert Krawitz wrote:
> The problem was that it wasn't getting into the tarball.  It needed to
> be added to backend_gutenprint_SOURCES.
> 
> make distcheck-minimal is a good test for that.

Aaaah.  Okay, I just added that to my regression set.

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
Coconut Creek, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

Re: [Gimp-print-devel] Backend isn't building

[Robert K. <rl...@al...>]

On Fri, 17 May 2019 19:25:41 -0400, Solomon Peachy wrote:
> On Fri, May 17, 2019 at 03:27:02PM -0400, Robert Krawitz wrote:
>> 2019-05-17T17:35:16+0000 compilation terminated.
>> 2019-05-17T17:35:16+0000 make[5]: *** [backend_gutenprint-backend_kodak6800.o] Error 1
>> 2019-05-17T17:35:16+0000   CC       backend_gutenprint-backend_kodak605.o
>> 2019-05-17T17:35:16+0000 ../../../src/cups/backend_kodak605.c:42:10: fatal error: backend_sinfonia.h: No such file or directory
>> 2019-05-17T17:35:16+0000  #include "backend_sinfonia.h"
>
> It landed as part of commit 9094945, and also passed my jenkins 
> instance's regression run, so I don't know why it would be failing for 
> you.

The problem was that it wasn't getting into the tarball.  It needed to
be added to backend_gutenprint_SOURCES.

make distcheck-minimal is a good test for that.
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] CUPS backend -- move to its own directory?

[Solomon P. <pi...@sh...>]

On Fri, May 17, 2019 at 01:17:26PM -0400, Robert Krawitz wrote:
> Solomon, do you think it would make sense to move the backend to its
> own directory under src/cups?

No objections from me.

> Only thing is, as long as we're doing 5.2 releases, doing backports
> might be a bit more of a pain for you.

Right now I'm only backporting what I consider to be critical bugfixes.  
Due to signifcant internal differences, it's already a mostly manual 
affair.

To ease my maintainence burden, I've debated just syncing up the 5.2 
branch with the master backend code; it's fully backwards compatible.

But I have no plans to backport any of the dyesub printer additions.

Most of the dyesub users that contact me are using LTS-type distros with 
relatively ancient gutenprint builds.  Since they generally need to 
recompile gutenprint from source anyway, I've been handing them 5.3 
snapshots.  (And then only if recompiling the backend isn't sufficient)

Granted, that still leaves out OSX users...

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
Coconut Creek, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

Re: [Gimp-print-devel] Backend isn't building

[Solomon P. <pi...@sh...>]

On Fri, May 17, 2019 at 03:27:02PM -0400, Robert Krawitz wrote:
> 2019-05-17T17:35:16+0000 compilation terminated.
> 2019-05-17T17:35:16+0000 make[5]: *** [backend_gutenprint-backend_kodak6800.o] Error 1
> 2019-05-17T17:35:16+0000   CC       backend_gutenprint-backend_kodak605.o
> 2019-05-17T17:35:16+0000 ../../../src/cups/backend_kodak605.c:42:10: fatal error: backend_sinfonia.h: No such file or directory
> 2019-05-17T17:35:16+0000  #include "backend_sinfonia.h"

It landed as part of commit 9094945, and also passed my jenkins 
instance's regression run, so I don't know why it would be failing for 
you.

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
Coconut Creek, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

Re: [Gimp-print-devel] Trailing whitespace

[Solomon P. <pi...@sh...>]

On Fri, May 17, 2019 at 01:09:59PM -0400, Robert Krawitz wrote:
> On Fri, 17 May 2019 12:50:47 -0400, Steve Letter via Gimp-print-devel wrote:
> > This isn't directed at me, is it?
> 
> It's generic -- anyone who merges anything into master should do
> this.  I can fix it up easily enough, but I'd like to get people in
> the habit of doing it.

Set it up as a pre-commit hook.  :)

(I have my editors configured to automatically strip all trailing 
spaces, FWIW)

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
Coconut Creek, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

[Gimp-print-devel] Backend isn't building

[Robert K. <rl...@al...>]

2019-05-17T17:35:16+0000 compilation terminated.
2019-05-17T17:35:16+0000 make[5]: *** [backend_gutenprint-backend_kodak6800.o] Error 1
2019-05-17T17:35:16+0000   CC       backend_gutenprint-backend_kodak605.o
2019-05-17T17:35:16+0000 ../../../src/cups/backend_kodak605.c:42:10: fatal error: backend_sinfonia.h: No such file or directory
2019-05-17T17:35:16+0000  #include "backend_sinfonia.h"

-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Gimp-print-devel] CUPS backend -- move to its own directory?

[Robert K. <rl...@al...>]

Solomon, do you think it would make sense to move the backend to its
own directory under src/cups?

Only thing is, as long as we're doing 5.2 releases, doing backports
might be a bit more of a pain for you.
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Trailing whitespace

[Robert K. <rl...@al...>]

On Fri, 17 May 2019 12:50:47 -0400, Steve Letter via Gimp-print-devel wrote:
> This isn't directed at me, is it?

It's generic -- anyone who merges anything into master should do
this.  I can fix it up easily enough, but I'd like to get people in
the habit of doing it.

>> On May 17, 2019, at 9:43 AM, Robert Krawitz <rl...@al...> wrote:
>> 
>> I fixed the trailing whitespace in this file, but please be careful
>> going forward.
>> 
>> You can also run
>> 
>> scripts/build-release preflight
>> 
>> which *should* work on any POSIX system (if it doesn't, I'll fix it).
>> 
>> https://travis-ci.org/RobertKrawitz/gutenprint-mirror/jobs/533759241#L1334

-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Trailing whitespace

[Steve L. <sle...@ya...>]

This isn’t directed at me, is it?

Steve Letter
System Software Engineer, Embedded

> On May 17, 2019, at 9:43 AM, Robert Krawitz <rl...@al...> wrote:
> 
> I fixed the trailing whitespace in this file, but please be careful
> going forward.
> 
> You can also run
> 
> scripts/build-release preflight
> 
> which *should* work on any POSIX system (if it doesn't, I'll fix it).
> 
> https://travis-ci.org/RobertKrawitz/gutenprint-mirror/jobs/533759241#L1334
> -- 
> Robert Krawitz                                     <rl...@al...>
> 
> ***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
> Member of the League for Programming Freedom  --  http://ProgFree.org
> Project lead for Gutenprint   --    http://gimp-print.sourceforge.net
> 
> "Linux doesn't dictate how I work, I dictate how Linux works."
> --Eric Crampton
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[Gimp-print-devel] Trailing whitespace

[Robert K. <rl...@al...>]

I fixed the trailing whitespace in this file, but please be careful
going forward.

You can also run

scripts/build-release preflight

which *should* work on any POSIX system (if it doesn't, I'll fix it).

https://travis-ci.org/RobertKrawitz/gutenprint-mirror/jobs/533759241#L1334
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] 5.3

[Solomon P. <pi...@sh...>]

On Mon, May 13, 2019 at 06:01:30PM -0400, Steve Letter via Gimp-print-devel wrote:
> I haven’t been able to get it working on my Sinfonia yet, model S1245 
> but I am sure I’m doing something wrong.

I _think_ the 5.2 branch has all of the S1245 backend fixes in it from 
our collaboration.  The first thing you should do is confirm that CUPS 
is using the gutenprint backend vs CUPS's built-in usb backend, and we 
can take it from there should it still not work for you.

I'm towards the tail end of an internal reworking of the various 
Sinfonia backends -- My goal is to unify as much of the Sinfonia-related 
code as possible, so it will be easier to add some of their newer 
models.  As I write this, I'm up to just over 1KLOC code reduction.

Once that's done and I fix any regressions on the two models I have 
here, I'll commit the result to master...

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
Coconut Creek, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.