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.ppdspuriously 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