Hello mentors,

I want to import a new svn snapshot to update a Debian package,
the salsa git repo is already configured for gbp, so I did

$ gbp import-orig -u1.5+svn38408 ../upstreamsvn/mplayer

upstream/mplayer is a directory with the unpacked svn checkout.
Gbp creates a ../upstreamsvn/mplayer_1.5+svn38408.orig.tar.gz
archieve (not a tar.xz); it also uses tar.gz in the pristine-tar branch.

One problem with the tar.gz is that debian/gbp.conf has
compression = xz
so when I push to salsa the salsa-ci fails because it searches for a
tar.xz archieve

gbp:info: All Orig tarballs 'mplayer_1.5+svn38408.orig.tar.xz' found at '/builds/Lorenzo.ru.g-guest/mplayer/debian/output'
gbp:info: Creating /builds/Lorenzo.ru.g-guest/mplayer/debian/output/mplayer_1.5+svn38408.orig.tar.xz
gbp:error: Error creating mplayer_1.5+svn38408.orig.tar.xz: Pristine-tar couldn't checkout "mplayer_1.5+svn38408.orig.tar.xz": fatal: path 'mplayer_1.5+svn38408.orig.tar.xz.delta' does not exist in 'refs/heads/pristine-tar'
pristine-tar: git show refs/heads/pristine-tar:mplayer_1.5+svn38408.orig.tar.xz.delta failed
pristine-tar: successfully generated ../mplayer_1.5+svn38408.orig.tar.gz gbp:info: Disabling 'cleaner' hook
gbp:info: Extracting 'mplayer_1.5+svn38408.orig.tar.xz' to '/builds/Lorenzo.ru.g-guest/mplayer/debian/output/mplayer-tmp'
tar: /builds/Lorenzo.ru.g-guest/mplayer/debian/output/mplayer_1.5+svn38408.orig.tar.xz: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
gbp:error: Couldn't unpack '/builds/Lorenzo.ru.g-guest/mplayer/debian/output/mplayer_1.5+svn38408.orig.tar.xz':
it exited with 2

Is there a way to tell gbp import-orig to use xz compression?

Lorenzo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

SGVsbG8gTG9yZW56bywNCg0KcGxlYXNlIHVzZSBhIHNwZWNpYWwgZ2JwLmNvbmYuDQoNCk1v cmUgaW5mb3JtYXRpb24geW91IGNhbiBnZXQgaW4gdGhlIG1hbnBhZ2Ugb2YgZ2JwLmNvbmYN Cg0KUmVnYXJkcw0KDQpNRWNodGlsZGUNCg0KQW0gMjcuMDEuMjMgdW0gMTg6MDIgc2Nocmll YiBMb3JlbnpvOg0KPiBIZWxsbyBtZW50b3JzLA0KPiANCj4gSSB3YW50IHRvIGltcG9ydCBh IG5ldyBzdm4gc25hcHNob3QgdG8gdXBkYXRlIGEgRGViaWFuIHBhY2thZ2UsDQo+IHRoZSBz YWxzYSBnaXQgcmVwbyBpcyBhbHJlYWR5IGNvbmZpZ3VyZWQgZm9yIGdicCwgc28gSSBkaWQN Cj4gDQo+ICQgZ2JwIGltcG9ydC1vcmlnIC11MS41K3N2bjM4NDA4IC4uL3Vwc3RyZWFtc3Zu L21wbGF5ZXINCj4gDQo+IHVwc3RyZWFtL21wbGF5ZXIgaXMgYSBkaXJlY3Rvcnkgd2l0aCB0 aGUgdW5wYWNrZWQgc3ZuIGNoZWNrb3V0Lg0KPiBHYnAgY3JlYXRlcyBhIC4uL3Vwc3RyZWFt c3ZuL21wbGF5ZXJfMS41K3N2bjM4NDA4Lm9yaWcudGFyLmd6DQo+IGFyY2hpZXZlIChub3Qg YSB0YXIueHopOyBpdCBhbHNvIHVzZXMgdGFyLmd6IGluIHRoZSBwcmlzdGluZS10YXIgYnJh bmNoLg0KPiANCj4gT25lIHByb2JsZW0gd2l0aCB0aGUgdGFyLmd6IGlzIHRoYXQgZGViaWFu L2dicC5jb25mIGhhcw0KPiBjb21wcmVzc2lvbiA9IHh6DQo+IHNvIHdoZW4gSSBwdXNoIHRv IHNhbHNhIHRoZSBzYWxzYS1jaSBmYWlscyBiZWNhdXNlIGl0IHNlYXJjaGVzIGZvciBhDQo+ IHRhci54eiBhcmNoaWV2ZQ0KPiANCj4gZ2JwOmluZm86IEFsbCBPcmlnIHRhcmJhbGxzICdt cGxheWVyXzEuNStzdm4zODQwOC5vcmlnLnRhci54eicgZm91bmQgYXQgJy9idWlsZHMvTG9y ZW56by5ydS5nLWd1ZXN0L21wbGF5ZXIvZGViaWFuL291dHB1dCcNCj4gZ2JwOmluZm86IENy ZWF0aW5nIC9idWlsZHMvTG9yZW56by5ydS5nLWd1ZXN0L21wbGF5ZXIvZGViaWFuL291dHB1 dC9tcGxheWVyXzEuNStzdm4zODQwOC5vcmlnLnRhci54eg0KPiBnYnA6ZXJyb3I6IEVycm9y IGNyZWF0aW5nIG1wbGF5ZXJfMS41K3N2bjM4NDA4Lm9yaWcudGFyLnh6OiBQcmlzdGluZS10 YXIgY291bGRuJ3QgY2hlY2tvdXQgIm1wbGF5ZXJfMS41K3N2bjM4NDA4Lm9yaWcudGFyLnh6 IjogZmF0YWw6IHBhdGggJ21wbGF5ZXJfMS41K3N2bjM4NDA4Lm9yaWcudGFyLnh6LmRlbHRh JyBkb2VzIG5vdCBleGlzdCBpbiAncmVmcy9oZWFkcy9wcmlzdGluZS10YXInDQo+IHByaXN0 aW5lLXRhcjogZ2l0IHNob3cgcmVmcy9oZWFkcy9wcmlzdGluZS10YXI6bXBsYXllcl8xLjUr c3ZuMzg0MDgub3JpZy50YXIueHouZGVsdGEgZmFpbGVkDQo+IHByaXN0aW5lLXRhcjogc3Vj Y2Vzc2Z1bGx5IGdlbmVyYXRlZCAuLi9tcGxheWVyXzEuNStzdm4zODQwOC5vcmlnLnRhci5n eg0KPiBnYnA6aW5mbzogRGlzYWJsaW5nICdjbGVhbmVyJyBob29rDQo+IGdicDppbmZvOiBF eHRyYWN0aW5nICdtcGxheWVyXzEuNStzdm4zODQwOC5vcmlnLnRhci54eicgdG8gJy9idWls ZHMvTG9yZW56by5ydS5nLWd1ZXN0L21wbGF5ZXIvZGViaWFuL291dHB1dC9tcGxheWVyLXRt cCcNCj4gdGFyOiAvYnVpbGRzL0xvcmVuem8ucnUuZy1ndWVzdC9tcGxheWVyL2RlYmlhbi9v dXRwdXQvbXBsYXllcl8xLjUrc3ZuMzg0MDgub3JpZy50YXIueHo6IENhbm5vdCBvcGVuOiBO byBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5DQo+IHRhcjogRXJyb3IgaXMgbm90IHJlY292ZXJh YmxlOiBleGl0aW5nIG5vdw0KPiBnYnA6ZXJyb3I6IENvdWxkbid0IHVucGFjaw0KPiAnL2J1 aWxkcy9Mb3JlbnpvLnJ1LmctZ3Vlc3QvbXBsYXllci9kZWJpYW4vb3V0cHV0L21wbGF5ZXJf MS41K3N2bjM4NDA4Lm9yaWcudGFyLnh6JzoNCj4gaXQgZXhpdGVkIHdpdGggMg0KPiANCj4g SXMgdGhlcmUgYSB3YXkgdG8gdGVsbCBnYnAgaW1wb3J0LW9yaWcgdG8gdXNlIHh6IGNvbXBy ZXNzaW9uPw0KPiANCj4gTG9yZW56bw0KPiANCg0KLS0gDQpNZWNodGlsZGUgU3RlaG1hbm4N CiMjIERlYmlhbiBEZXZlbG9wZXINCiMjIFBHUCBlbmNyeXB0aW9uIHdlbGNvbWUNCiMjIEYw RTMgN0YzRCBDODdBIDQ5OTggMjg5OSAgMzlFNyBGMjg3IDdCQkEgMTQxQSBBRDdGDQo=

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Jan 27, 2023 at 06:02:34PM +0100, Lorenzo wrote:

Hello mentors,

I want to import a new svn snapshot to update a Debian package,
the salsa git repo is already configured for gbp, so I did

$ gbp import-orig -u1.5+svn38408 ../upstreamsvn/mplayer

upstream/mplayer is a directory with the unpacked svn checkout.
Gbp creates a ../upstreamsvn/mplayer_1.5+svn38408.orig.tar.gz
archieve (not a tar.xz); it also uses tar.gz in the pristine-tar branch.

As far as I can see this is not configurable, all locally-repacked
tarballs are repacked as .tar.gz.

One problem with the tar.gz is that debian/gbp.conf has
compression = xz

So this configuration is wrong ad you need to change it.

so when I push to salsa the salsa-ci fails because it searches for a
tar.xz archieve

(I'm still surprised that people apparently don't build locally, only on salsa-ci)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Jan 27, 2023 at 07:49:21PM +0100, Mechtilde Stehmann wrote:

Hello Lorenzo,

please use a special gbp.conf.

It would be much more useful if you provided the actual option for this.
(as far as I know it doesn't exist)
Unless you mean something else by "special".

More information you can get in the manpage of gbp.conf

(that manpage doesn't even list actual options)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 28 Jan 2023 19:24:37 +0100
Andrey Rakhmatullin <[email protected]> wrote:

On Fri, Jan 27, 2023 at 06:02:34PM +0100, Lorenzo wrote:

Hello mentors,

I want to import a new svn snapshot to update a Debian package,
the salsa git repo is already configured for gbp, so I did

$ gbp import-orig -u1.5+svn38408 ../upstreamsvn/mplayer

upstream/mplayer is a directory with the unpacked svn checkout.
Gbp creates a ../upstreamsvn/mplayer_1.5+svn38408.orig.tar.gz
archieve (not a tar.xz); it also uses tar.gz in the pristine-tar
branch.

As far as I can see this is not configurable, all locally-repacked
tarballs are repacked as .tar.gz.

Yes, by looking at gbp.conf(5) and manpages of other gbp-* I couldn't
find an option to control the compression type when importing a new
upstream snapshot.
As a workaround it seems that if I compress manually as tar.xz and then
feed the archive to gbp import-orig the xz format is kept. However I
prefer to let gbp handle all steps.

One problem with the tar.gz is that debian/gbp.conf has
compression = xz

So this configuration is wrong ad you need to change it.

I didn't write in my previous message, but the watch file of this
project looks for a tar.xz when downloading a new upstream release.
I'm going to try
compression = auto
in the hope that it works both for tar.xz releases and
tar.gz snapshots.

so when I push to salsa the salsa-ci fails because it searches for a
tar.xz archieve

(I'm still surprised that people apparently don't build locally, only
on salsa-ci)

(I build locally with sbuild and use salsa-ci for piuparts and other
tests)

Lorenzo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Jan 29, 2023 at 03:45:26PM +0100, Lorenzo wrote:

One problem with the tar.gz is that debian/gbp.conf has
compression = xz

So this configuration is wrong ad you need to change it.

I didn't write in my previous message, but the watch file of this
project looks for a tar.xz when downloading a new upstream release.

Are you mixing released tarballs and contents of some SVN repo in the same package repo then? Or what is your workflow?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 29 Jan 2023 20:09:09 +0100
Andrey Rakhmatullin <[email protected]> wrote:

On Sun, Jan 29, 2023 at 03:45:26PM +0100, Lorenzo wrote:

One problem with the tar.gz is that debian/gbp.conf has
compression = xz

So this configuration is wrong ad you need to change it.

I didn't write in my previous message, but the watch file of this
project looks for a tar.xz when downloading a new upstream release.

Are you mixing released tarballs and contents of some SVN repo in the
same package repo then? Or what is your workflow?

Yes, the latest upstream release (mplayer 1.5) has CVEs and fails to
build, so I jumped from 1.4 to 1.5+svn

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jan 30, 2023 at 12:53:24PM +0100, Lorenzo wrote:

One problem with the tar.gz is that debian/gbp.conf has
compression = xz

So this configuration is wrong ad you need to change it.

I didn't write in my previous message, but the watch file of this
project looks for a tar.xz when downloading a new upstream release.

Are you mixing released tarballs and contents of some SVN repo in the
same package repo then? Or what is your workflow?

Yes, the latest upstream release (mplayer 1.5) has CVEs and fails to
build, so I jumped from 1.4 to 1.5+svn

Is this a one-time thing? If so, I would just create a tarball manually.
But overall you need to make sure the SVN repo contains the same files as
the published tarball, otherwise the compression difference is not the
largest problem you could have.
Also, the best way is probably submitting a patch for gbp to make the
repacked tarball compression configurable.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 30 Jan 2023 14:00:48 +0100
Andrey Rakhmatullin <[email protected]> wrote:

Yes, the latest upstream release (mplayer 1.5) has CVEs and fails to
build, so I jumped from 1.4 to 1.5+svn

Is this a one-time thing? If so, I would just create a tarball
manually.

I suspect this package may need to alternate unreleased version and
official releases in future

But overall you need to make sure the SVN repo contains the
same files as the published tarball, otherwise the compression
difference is not the largest problem you could have.

right, I should have excluded the .svn directory from the source..
apart from that I don't think there are other relevant difference.
Is there a document that describes the right steps to follow when
importing a git or svn snapshot in Debian? I couldn't find one.

Also, the best way is probably submitting a patch for gbp to make the repacked tarball compression configurable.

I doubt that I'll have the extra time for that, but it's now in my TODO
list, just in case

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jan 30, 2023 at 08:30:26PM +0100, Lorenzo wrote:

But overall you need to make sure the SVN repo contains the
same files as the published tarball, otherwise the compression
difference is not the largest problem you could have.

right, I should have excluded the .svn directory from the source..
apart from that I don't think there are other relevant difference.
Is there a document that describes the right steps to follow when
importing a git or svn snapshot in Debian? I couldn't find one.

You normally don't need to do anything special when doing that as opposed
to when importing tarballs, though you may need to run some additional
commands (e.g. autoreconf) that are normally done when the source tarball
is created in the software release process (this obviously depends on the project specifics and may not be needed at all). This is assuming the repo contains everything needed and the source tarball isn't e.g. created from
the repo and some external files.
And the need to run these additional commands is exactly because the
contents of a repo and a tarball are different, in which case interleaved imports of both of them will have weird effects on the file history and
may also require changing d/rules back and forth.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)