Possible issue with different encodes

[spinscale]

Hey,

I have the following in my pom.xml

...
                                <data>
                                    <src>${project.basedir}/src/deb/default/</src>
                                    <type>directory</type>
                                    <excludes>.DS_Store</excludes>
                                    <mapper>
                                        <type>perm</type>
                                        <prefix>/etc/default</prefix>
                                        <user>root</user>
                                        <group>root</group>
                                    </mapper>
                                </data>
...

There is only one file inside which is in unix encoding. However, when the packaging is done under windows, this file suddenly gets converted to windows line.separators, which then makes it uninstallable under debian linux, as the it cannot be sourced anymore and bash returns and error code which in turn stops the installation. Also this does not seem to happen with every windows installation (works on two other machines).

I have only taken a quick peek at the source, but I thought the specified files are simply copied and not changed in any way (or is this possible with the template functionality)? Anything else which could cause this behaviour?

Any hints are greatly appreciated.

[tcurdt]

Odd - I thought we have the line ending under control.
Hm - might be that was just about the control files.

Can you try if you can reproduce it with the jdeb examples?

Thanks for reporting.

[costin]

Hi, the test run with the latest jdeb on Win 8.1 x64 is available at
https://gist.github.com/costin/cb1398be897f445e0f49

cheers,

[tcurdt]

@ebourg @tmortagne any of you guys have a windows machine at hand?

[tmortagne]

I can restart on Windows and try that later today I think. Just need to build jdeb with Maven, right ?

(will have to setup Window for all that, it's basically just a video game player OS for me right now)

At least I have Win 8.1 x64 too.

[tcurdt]

From the gist it seems like it. Building the examples deb could also be a good idea. Thanks!

[tmortagne]

Will test several versions of Maven, could be related to that too.

[tmortagne]

I can confirm that I get https://gist.github.com/costin/cb1398be897f445e0f49 too (both with Maven 3.0.5 and 3.2.1). I don't have much time right but I can try to debug it on Windows this weekend.

[tcurdt]

@tmortagne that would be fantastic. if you could just pinpoint the problem that would be a start.

[tmortagne]

As soon as I get some time to setup Eclipse on Windows I'm sure a step by step debug should give a lot of informations.

[tmortagne]

Hmm https://gist.github.com/costin/cb1398be897f445e0f49 is not related to encoding or line ending, it expect "C:\Users\THOMA_~1\AppData\Local\Temp\DataProducerFilesTestCase.16835971457892943192txt" and end up with "/Users/THOMA_~1/AppData/Local/Temp/DataProducerFilesTestCase.16835971457892943192txt" as filename parameter in DataConsumer#onEachFile call.

Looks more like test bug to me as this parameter is supposed to be the path in the tar archive and not the File#getAbsolutePath() used by the test which cannot work in Windows.

[tcurdt]

True. @tmortagne, could you fix the test as a first step?

[tcurdt]

Hm. I don't see how where we could possibly be converting the line endings. @spinscale is using a DirectoryDataProducer which calls produceFile and produceDir. Following produceFile one can see the Producers.produceInputStreamWithEntry passes the inputstream to the consumer. The anonymous consumer in DataBuilder is then just copying the stream.

So the possibly unrelated failing testcase aside I think we will need a way to reproduce this.

[tcurdt]

The example project has a similar data producer.
We should check to build the example on windows and see if it exhibits the same problems.