debtransform considers files ending with .tar as source files.

[hurricanehrndz]

files ending in .tar should not be considered source otherwise you get:

 Too many files looking like a usable source tarball (would not know which to pick): termite-v10.32.tar.gz termite-v10.32.tar

[dkgroot]

I notice the same thing. Further investigation on my part shows that the service:recompress progress does not remove the original tar file after it has compressed it to one of: gz, xz, bz2. That causes debtransform to see two files which in turn then failes with the error mentioned above.

Looking at the https://github.com/openSUSE/obs-service-recompress/blob/master/recompress script showed me that it tried to do perform 'rm -f "$FILE"' in line 118. And in a simulation on my own machine it managed to do so. Calling the recompress script from _service however failes to remove the original file (maybe because they are named differently, ie: _service:tar_scm:[filename].tar and _service:recompress:tar_scm:[filename].tar.gz).

Hope the extra bit of research helps in fixing the right script. Of course fixing debtransform to prefer .tar.gz / .tar.bz2 / .tar.xz over .tar would also fix the issue. Then again removing the source file after recompression, will save the buildservice a lot of space.

[hurricanehrndz]

@dkgroot

I have created an issue with the service:recompress. Unfortunately after analyzing the code I could not find fault with the bash script. Line 118 of recompress is suppose to remove the original tar file. I'm not sure why that does not occur when obs-build calls the service. Maybe core.py from obs-build needs to get analyzed as to why the file is prevented from being removed. Either which way Debian source package format does not support tar compression alone and thus should be ignored. Hopefully this pull request gets accepted.

[dkgroot]

Skipping .tar as a possible source file makes sense in any case. Agreed. Investigating what changed in recompress can be handled as a seperate issue. I do remember the original tar file being removed after recompress before. Maybe even as early as two days ago.

Thanks for your quick repsonse btw. I was beating my head against the wall, trying to figure out what i did wrong :-)

[hurricanehrndz]

@dkgroot

Me too, 3 hours.

[dkgroot]

;-). Keeping fingers crossed !

[dg0yt]

For those relying on tar_scm+recompress+set_version, and looking for a workaround:

Use an additional download_url service to fetch a tarball with a fixed name before tar_scm. The tarball's name can be used in the DSC for the tag DEBTRANSFORM-TAR. tar_scm is still used for set_version if it comes after download_url. This adds another tarball to fix the problem from having two...

[dkgroot]

@dg0yt : Thanks i already figured that one out, problem is our repository (on sourceforge) does not provide regular tarball download from trunk without some kind of user intervention. But thanks for mentioning it anyway, might be helpfull for someone else :-)

[dg0yt]

I would prefer if tar_scm would create compressed tarballs. Submitted untested attempt at https://github.com/openSUSE/obs-service-tar_scm/pull/93.

[dkgroot]

Second That !

[noscript]

+1 for debtransform to ignore .tar.

Until then I came up with another workaround. To hide the tarball from debtransform I had to set some bogus extension and explicitly list all the files for extraction.

<service name="tar_scm">
  ...
  <param name="extension">tar_</param>
  <param name="extract">file1</param>
  <param name="extract">file2</param>
</service>