On 06/10/2015 03:25 AM, Didier 'OdyX' Raboud wrote:
Hi again Till,
Le lundi, 8 juin 2015, 15.51:43 Till Kamppeter a écrit :
On 06/08/2015 01:14 PM, Didier 'OdyX' Raboud wrote:
Hmm. I'm not convinced by all your changes, let's see:
- 4de7ecc adds unncessary noise to the ipp-everywhere patch: (…)
- 1b3ad91 introduces a patch lacking DEP-3 headers.
I have now pushed a massive change on the repository through adopting
the [DEP-14] proposal for the git branch names. I took this opportunity
to rewrite the debian/experimental branch with a selection and rewrite
of your patches. I have integrated the new upstream 2.0.3 into that
branch, rebased the Ipp-Everywhere patch (but had to disable it, as it
breaks tests) and uploaded 2.0.3-1 to experimental.
Probably I will drop the IPP-Everywhere patch altogether, principally,
it does not break anything, but I completely do not understand how it
breaks the testing. On a
lpadmin -p Test3 -v file:/dev/null -E -m drv:///sample.drv/deskjet1000.ppd
spuriously no PPD file gets generated without lpadmin erroring. Looks
much like some kind of race condition.
So seems to be better to wait for Mike officially releasing the IPP
Everywhere support with appropriately calibrated test suite. It will
probably also take some more years for the first IPP Everywhere printer
hit the market and geting marketed as such.
I suggest that you push any new changes on a new ubuntu/wily branch
(based on current debian/experimental), to enable my review before
integrating to the debian/* branches. This should avoid future history
rewrites. How does this sound to you?
I will do so from now on, and then I will first release them into Ubuntu
and observe whether there are no regressions. Then we will loosely sync
between Debian and Ubuntu, whenever the last changes seem to be stable.
Perhaps some patches stay Ubuntu-only with stuff which better fits in a
bleeding-edge distro like Ubuntu but not in a more conservative distro
like Debian. We only need to make sure to not independently introduce
new versions of upstream CUPS with different upstream tarballs for the
same version.
ippserver is an emulator of an IPP Everywhere server, it is for
development. I added it to cups-client as the other, similar
developent tools like ippfind and ipptool are there. I have nothing
against putting it into a separate package. It seems to not have a
man page.
ippserver does have a manpage in test/ippserver.man. What about creating
a new "cups-client-dev" package to put the ipptool tests, ipptool,
ippserver and ippfind binaries ?
I think this is a good idea, but instead of cups-client-dev I would use
the name ipp-utils or cups-ipp-utils and put all ipp* utilities with
their respective man pages into the package. As ippserver is not
intended as a production service but only used for development purposes
and started with different command lines for emulating different
situations I would not put any SystemV/Upstart/systemd startup scripts
for it into the package.
OK, so we must wait for the MIPS folks to come up for introducing CUPS
2.0.x into unstable, or perhaps skip straight to 2.1.x.
Well, I have pushed bugs to upstream once already, but that didn't work
out. I'll keep trying.
If the MIPS fix takes too long, I will perhaps advance CUPS versions in
Ubuntu (Ubuntu does not support MIPS) and we return to sync when MIPS is
solved (can be 2.1.x).
Till
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: https://lists.debian.org/[email protected]
