how to handle upstream orig tarball with git-lfs reference files?

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

how to handle upstream orig tarball with git-lfs reference files?

Drew Parsons
Upstreams are starting to use git lfs in their git repos.  In some cases
the git-lfs references files are retained in the source tarball, not
replacing the reference with the actual files.  This happens for
instance with github repos (I gather it happens because the tarball is
generated with 'git archive' [1]).  An example is the mesh files [2] in
pygalmesh 0.4.0 [3].

This means gbp import-orig, used in the normal way (or "old" way) with
orig tarballs, will import lfs references, and dpkg-buildpackage will
proceed to attempt the build with those references files, not with the
actual files.  So the build fails.

Actually 'gbp import-orig --pristine-tar' also fails, e.g.,

   pygalmesh$ gbp import-orig --uscan --pristine-tar
   gbp:info: Launching uscan...
   uupdate: debian/source/format is "3.0 (quilt)".
   uupdate: Auto-generating pygalmesh_0.3.6-2.debian.tar.xz
   uupdate: -> Copy to      pygalmesh_0.4.0-1.debian.tar.xz
   gbp:info: Using uscan downloaded tarball
../pygalmesh_0.4.0.orig.tar.gz
   What is the upstream version? [0.4.0]
   gbp:info: Importing '../pygalmesh_0.4.0.orig.tar.gz' to branch
'upstream'...
   gbp:info: Source package is pygalmesh
   gbp:info: Upstream version is 0.4.0
   gbp:error: Import of ../pygalmesh_0.4.0.orig.tar.gz failed: Couldn't
commit to 'pristine-tar' with upstream
'536d07340054dd9bd56202ea58f4619650b3d05c': Downloading
test/meshes/elephant.vtu (136 KB)
   Error downloading object: test/meshes/elephant.vtu (a11aa57): Smudge
error: Error downloading test/meshes/elephant.vtu
(a11aa572d612abfacace9a31c0e20c8a628bf4ffd50b1661e14790ae02c93b7b):
     [a11aa572d612abfacace9a31c0e20c8a628bf4ffd50b1661e14790ae02c93b7b]
Object does not exist on the server or you don't have permissions to
access it: [404] Object does not exist on the server or you don't have
permissions to access it

   Errors logged to
/home/projects/pygalmesh/.git/lfs/logs/20190810T231824.577519072.log
   Use `git lfs logs last` to view the log.
   error: external filter 'git-lfs filter-process' failed
   fatal: test/meshes/elephant.vtu: smudge filter lfs failed
   tar: Unexpected EOF in archive
   tar: Unexpected EOF in archive
   tar: Error is not recoverable: exiting now
   pristine-tar: command failed: git archive --format=tar
536d07340054dd9bd56202ea58f4619650b3d05c | (cd
'/tmp/pristine-tar.B3MfD_oDaJ' && tar x)
   gbp:error: Error detected, Will roll back changes.
   gbp:info: Rolling back branch upstream by resetting it to
72d0bcfaba44dea918042ba323c546b0d88b4905
   gbp:info: Rolling back branch pristine-tar by resetting it to
d832fde1c79f59611d31e4188a0388491914bde6
   gbp:error: Rolled back changes after import error.


So what is currently the best way to handle lfs files in upstream
tarballs?  Is gbp-buildpackage the only automated solution and those not
using it just need to learn how?  Or can debian/watch be written to
include a git-lfs pull when repacking a source tarball?  Any other
solutions apart from manual repacking?

A related question, is it possible to configure a github repo so that
the source tarball links are generated with actual files?  If so then we
could request upstream to configure their repo that way.

Drew

[1] https://github.com/git-lfs/git-lfs/issues/1322
[2] https://github.com/nschloe/pygalmesh/tree/master/test/meshes
[3] https://github.com/nschloe/pygalmesh/releases

Reply | Threaded
Open this post in threaded view
|

Re: how to handle upstream orig tarball with git-lfs reference files?

Drew Parsons
On 2019-08-11 01:55, Drew Parsons wrote:

> Upstreams are starting to use git lfs in their git repos.  In some
> cases the git-lfs references files are retained in the source tarball,
> not replacing the reference with the actual files.  This happens for
> instance with github repos (I gather it happens because the tarball is
> generated with 'git archive' [1]).  An example is the mesh files [2]
> in pygalmesh 0.4.0 [3].
>
> This means gbp import-orig, used in the normal way (or "old" way) with
> orig tarballs, will import lfs references, and dpkg-buildpackage will
> proceed to attempt the build with those references files, not with the
> actual files.  So the build fails.
>
> Actually 'gbp import-orig --pristine-tar' also fails, e.g.,
>
>   pygalmesh$ gbp import-orig --uscan --pristine-tar
...
>   Error downloading object: test/meshes/elephant.vtu (a11aa57): Smudge
> error: Error downloading test/meshes/elephant.vtu
> (a11aa572d612abfacace9a31c0e20c8a628bf4ffd50b1661e14790ae02c93b7b):
>     [a11aa572d612abfacace9a31c0e20c8a628bf4ffd50b1661e14790ae02c93b7b]
> Object does not exist on the server or you don't have permissions to
> access it
...
> So what is currently the best way to handle lfs files in upstream
> tarballs?  Is gbp-buildpackage the only automated solution and those
> not using it just need to learn how?  Or can debian/watch be written
> to include a git-lfs pull when repacking a source tarball?  Any other
> solutions apart from manual repacking?


I can answer part of my own question now, but it reinforces the other
part: how should we handle LFS files?

As far as the source tarball and pristine-tar goes, that can be fixed by
changing debian/watch to track upstream git tags rather than upstream
release tarballs, e.g.

version=4
      opts="mode=git, gitmode=full, pgpmode=none" \
      https://github.com/nschloe/pygalmesh.git \
      refs/tags/v([\d\.]+) debian uupdate

The tarball pulled this way by 'gbp import-orig --uscan --pristine-tar'
pulls in the actual LFS files instead of their references.


But this brings us back to the reason why upstream started using LFS in
the first place.  With this import-orig, the Debian git repos on salsa
will be carrying the large data files that upstream is trying to manage
with git-lfs.  In the case of pygalmesh, for instance, the mesh file
test/meshes/liver.inr is 49MB in size.

Do we really want to be carrying large upstream data files in salsa,
when upstream has judged they should be handled using git-lfs
infrastructure?

We have the policy of not pulling files from the internet at build time,
which is probably a good policy to maintain.  Does it mean we want to
configure salsa or some other part of debian infrastructure to provide a
git-lfs service?  Maybe salsa can already do it, in which case a HOWTO
on wiki.debian.org would be useful.

Drew

Reply | Threaded
Open this post in threaded view
|

Re: how to handle upstream orig tarball with git-lfs reference files?

Andrej Shadura-2
Hi,

On Sun, 11 Aug 2019, 04:18 Drew Parsons, <[hidden email]> wrote:
We have the policy of not pulling files from the internet at build time,
which is probably a good policy to maintain.  Does it mean we want to
configure salsa or some other part of debian infrastructure to provide a
git-lfs service?  Maybe salsa can already do it, in which case a HOWTO
on wiki.debian.org would be useful.

Salsa already supports git-lfs, it's just not enabled by default. Moreover, my pristine-tar replacement, pristine-lfs, takes advantage of this support.

I'm on a phone, I'll write a longer reply later.

-- 
Cheers,
  Andrej
Reply | Threaded
Open this post in threaded view
|

Re: how to handle upstream orig tarball with git-lfs reference files?

Drew Parsons
On 2019-08-11 13:26, Andrej Shadura wrote:

> Hi,
>
> On Sun, 11 Aug 2019, 04:18 Drew Parsons, <[hidden email]> wrote:
>
>> We have the policy of not pulling files from the internet at build
>> time,
>> which is probably a good policy to maintain.  Does it mean we want
>> to
>> configure salsa or some other part of debian infrastructure to
>> provide a
>> git-lfs service?  Maybe salsa can already do it, in which case a
>> HOWTO
>> on wiki.debian.org [1] would be useful.
>
> Salsa already supports git-lfs, it's just not enabled by default.
> Moreover, my pristine-tar replacement, pristine-lfs, takes advantage
> of this support.
>
> I'm on a phone, I'll write a longer reply later.


Nice timing with pristine-lfs, I look forward to hearing more.

Drew

Reply | Threaded
Open this post in threaded view
|

Re: how to handle upstream orig tarball with git-lfs reference files?

Daniel Leidert-2
In reply to this post by Andrej Shadura-2
Am Sonntag, den 11.08.2019, 07:26 +0200 schrieb Andrej Shadura:
> On Sun, 11 Aug 2019, 04:18 Drew Parsons, <[hidden email]> wrote:
> > We have the policy of not pulling files from the internet at build time,
> > which is probably a good policy to maintain.  Does it mean we want to
> > configure salsa or some other part of debian infrastructure to provide a
> > git-lfs service?  Maybe salsa can already do it, in which case a HOWTO
> > on wiki.debian.org would be useful.
>
> Salsa already supports git-lfs, it's just not enabled by default.

Git LFS is actually enabled on all our projects without user interaction. IMHO
you are wrong.

Regardsm Daniel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Why keep upstream sources in Git at salsa.d.o? (was: how to handle upstream orig tarball with git-lfs reference files?)

Daniel Leidert-2
In reply to this post by Drew Parsons
Am Sonntag, den 11.08.2019, 01:55 +0800 schrieb Drew Parsons:
> Upstreams are starting to use git lfs in their git repos.  In some cases
> the git-lfs references files are retained in the source tarball, not
> replacing the reference with the actual files.  This happens for
> instance with github repos (I gather it happens because the tarball is
> generated with 'git archive' [1]).  An example is the mesh files [2] in
> pygalmesh 0.4.0 [3].

What I really don't understand is, why we duplicate upstream files (now even
really large files) on salsa.d.o. The debian/-only approach (or "overlay"
layout in git-buildpackage) works fine. Salsa CI also works just fine.

I cannot find anyhting useful in storing the upstream files in our Git. Also
all other distributions I know, which store their packaging files in a VCS,
only store *their* files, not the upstream sources. Do we really have to waste
our resources?

Regards, Daniel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why keep upstream sources in Git at salsa.d.o? (was: how to handle upstream orig tarball with git-lfs reference files?)

Simon McVittie-7
On Sun, 11 Aug 2019 at 15:03:51 +0200, Daniel Leidert wrote:
> What I really don't understand is, why we duplicate upstream files (now even
> really large files) on salsa.d.o.

I can't tell you every maintainer's reasons to do this, but here's why
*I* prefer having upstream source code in our packaging git repository:

* When I'm investigating a bug, I don't need a separate repository and a
  separate checkout to look back through the history of the code that is
  under suspicion and find out why it is the way it is.

* When I'm rebasing our patch series on updated upstream source code,
  I don't need a separate repository and a separate checkout to do so.
  (I use gbp-pq for this; other workflows are available.)

* When I'm trying to fix a bug, I can switch to the patches-applied view
  (in my case this means gbp pq import) and try repeated rebuilds until
  it works. I don't need to have a separate repository and a separate
  checkout of the upstream source code, apply the Debian patch series,
  work out how to build that in a way that is compatible with the
  expectations of the Debian package, iterate on the new patch, and finally
  export it (git format-patch) in a form that I can add to the Debian
  packaging.

* If upstream's VCS repository disappears or goes offline, either
  temporarily or forever, we still have the history up to this point
  (and if necessary we can fork).

When GNOME's Debian packaging was still in svn, all of those except the
last were practical problems. I find it much easier to work with GNOME
packaging now that we're using git with full upstream source.

The one family of packages for which I still don't use a
full-upstream-source git repository is openarena-data, because game
data/assets have limited history (they get added and occasionally
deleted, but rarely modified) and limited scope for patching, and are
inconveniently large.

    smcv

Reply | Threaded
Open this post in threaded view
|

Re: how to handle upstream orig tarball with git-lfs reference files?

Andrej Shadura-2
In reply to this post by Daniel Leidert-2
Hi,

On Sun, 11 Aug 2019 at 14:57, Daniel Leidert <[hidden email]> wrote:
>
> Am Sonntag, den 11.08.2019, 07:26 +0200 schrieb Andrej Shadura:
> > On Sun, 11 Aug 2019, 04:18 Drew Parsons, <[hidden email]> wrote:
> > > We have the policy of not pulling files from the internet at build time,
> > > which is probably a good policy to maintain.  Does it mean we want to
> > > configure salsa or some other part of debian infrastructure to provide a
> > > git-lfs service?  Maybe salsa can already do it, in which case a HOWTO
> > > on wiki.debian.org would be useful.

> > Salsa already supports git-lfs, it's just not enabled by default.

> Git LFS is actually enabled on all our projects without user interaction. IMHO
> you are wrong.

I had to enable it just last week on one of the projects of mine.

--
Cheers,
  Andrej

Reply | Threaded
Open this post in threaded view
|

Re: Why keep upstream sources in Git at salsa.d.o? (was: how to handle upstream orig tarball with git-lfs reference files?)

Marc Haber-3
In reply to this post by Daniel Leidert-2
On Sun, 11 Aug 2019 15:03:51 +0200, Daniel Leidert
<[hidden email]> wrote:

>Am Sonntag, den 11.08.2019, 01:55 +0800 schrieb Drew Parsons:
>> Upstreams are starting to use git lfs in their git repos.  In some cases
>> the git-lfs references files are retained in the source tarball, not
>> replacing the reference with the actual files.  This happens for
>> instance with github repos (I gather it happens because the tarball is
>> generated with 'git archive' [1]).  An example is the mesh files [2] in
>> pygalmesh 0.4.0 [3].
>
>What I really don't understand is, why we duplicate upstream files (now even
>really large files) on salsa.d.o. The debian/-only approach (or "overlay"
>layout in git-buildpackage) works fine. Salsa CI also works just fine.

When I started with mantaining my packages in git, that layout way not
yet available. Actually, this was my major beef against git since I
had been using this approach happily with svn und svn-buildpackage for
years.

I haven't heard that a debian/ only repository layout is possible with
git-buildpackage before today.

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Reply | Threaded
Open this post in threaded view
|

Re: how to handle upstream orig tarball with git-lfs reference files?

Alexander Wirt-2
In reply to this post by Andrej Shadura-2
On Mon, 12 Aug 2019, Andrej Shadura wrote:

> Hi,
>
> On Sun, 11 Aug 2019 at 14:57, Daniel Leidert <[hidden email]> wrote:
> >
> > Am Sonntag, den 11.08.2019, 07:26 +0200 schrieb Andrej Shadura:
> > > On Sun, 11 Aug 2019, 04:18 Drew Parsons, <[hidden email]> wrote:
> > > > We have the policy of not pulling files from the internet at build time,
> > > > which is probably a good policy to maintain.  Does it mean we want to
> > > > configure salsa or some other part of debian infrastructure to provide a
> > > > git-lfs service?  Maybe salsa can already do it, in which case a HOWTO
> > > > on wiki.debian.org would be useful.
>
> > > Salsa already supports git-lfs, it's just not enabled by default.
>
> > Git LFS is actually enabled on all our projects without user interaction. IMHO
> > you are wrong.
>
> I had to enable it just last week on one of the projects of mine.
It is available for every project, but it doesn't make sense to enable it
unconditionally on every project. We - the salsa admins - recommend using
git-lfs for big files.

Alex
 

Reply | Threaded
Open this post in threaded view
|

Re: Why keep upstream sources in Git at salsa.d.o?

Daniel Leidert-2
In reply to this post by Marc Haber-3
Am Montag, den 12.08.2019, 19:53 +0200 schrieb Marc Haber:

> On Sun, 11 Aug 2019 15:03:51 +0200, Daniel Leidert
> <[hidden email]> wrote:
> > Am Sonntag, den 11.08.2019, 01:55 +0800 schrieb Drew Parsons:
> > > Upstreams are starting to use git lfs in their git repos.  In some cases
> > > the git-lfs references files are retained in the source tarball, not
> > > replacing the reference with the actual files.  This happens for
> > > instance with github repos (I gather it happens because the tarball is
> > > generated with 'git archive' [1]).  An example is the mesh files [2] in
> > > pygalmesh 0.4.0 [3].
> >
> > What I really don't understand is, why we duplicate upstream files (now
> > even
> > really large files) on salsa.d.o. The debian/-only approach (or "overlay"
> > layout in git-buildpackage) works fine. Salsa CI also works just fine.
>
> When I started with mantaining my packages in git, that layout way not
> yet available. Actually, this was my major beef against git since I
> had been using this approach happily with svn und svn-buildpackage for
> years.
>
> I haven't heard that a debian/ only repository layout is possible with
> git-buildpackage before today.
Works nicely. I keep a file debian/gbp.conf usually with the content

> [DEFAULT]
> pristine-tar = false
> debian-branch = master # or debian/sid
> verbose = true
>
> [buildpackage]
> overlay = true

in Git for others; and I use debian/.gitattributes with this content:

> .gitattributes export-ignore
> salsa-ci.yml export-ignore
> gbp.conf export-ignore

to keep the Debian package clean.

The default salsa-ci.yml works very well with this too. We use this layout for
most of our packages in the debichem team. As far as I heard, the KDE team uses
it too.

`gbp pq` doesn't work with this layout.

Regards, Daniel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why keep upstream sources in Git at salsa.d.o?

Alexis Murzeau-3
Le 13/08/2019 à 01:17, Daniel Leidert a écrit :

> Am Montag, den 12.08.2019, 19:53 +0200 schrieb Marc Haber:
>> On Sun, 11 Aug 2019 15:03:51 +0200, Daniel Leidert
>> <[hidden email]> wrote:
>>> Am Sonntag, den 11.08.2019, 01:55 +0800 schrieb Drew Parsons:
>>>> Upstreams are starting to use git lfs in their git repos.  In some cases
>>>> the git-lfs references files are retained in the source tarball, not
>>>> replacing the reference with the actual files.  This happens for
>>>> instance with github repos (I gather it happens because the tarball is
>>>> generated with 'git archive' [1]).  An example is the mesh files [2] in
>>>> pygalmesh 0.4.0 [3].
>>>
>>> What I really don't understand is, why we duplicate upstream files (now
>>> even
>>> really large files) on salsa.d.o. The debian/-only approach (or "overlay"
>>> layout in git-buildpackage) works fine. Salsa CI also works just fine.
>>
>> When I started with mantaining my packages in git, that layout way not
>> yet available. Actually, this was my major beef against git since I
>> had been using this approach happily with svn und svn-buildpackage for
>> years.
>>
>> I haven't heard that a debian/ only repository layout is possible with
>> git-buildpackage before today.
>
> Works nicely. I keep a file debian/gbp.conf usually with the content
>
>> [DEFAULT]
>> pristine-tar = false
>> debian-branch = master # or debian/sid
>> verbose = true
>>
>> [buildpackage]
>> overlay = true
>
> in Git for others; and I use debian/.gitattributes with this content:
>
>> .gitattributes export-ignore
>> salsa-ci.yml export-ignore
>> gbp.conf export-ignore
>
> to keep the Debian package clean.
>
> The default salsa-ci.yml works very well with this too. We use this layout for
> most of our packages in the debichem team. As far as I heard, the KDE team uses
> it too.
>
> `gbp pq` doesn't work with this layout.
>
> Regards, Daniel
>
Hi,

I'm curious about keeping only debian/ in git.
How to build such git repository ?

I've tried one of yours but failed like this:
```
$ gbp clone https://salsa.debian.org/ruby-team/ruby-html-proofer
gbp:info: Cloning from
'https://salsa.debian.org/ruby-team/ruby-html-proofer'
$ cd ruby-html-proofer/
$ gbp buildpackage "--git-builder=sbuild -v -As -d unstable" \
> --git-export-dir=../build-area
gbp:error: upstream/3.11.1 is not a valid treeish
```

I guess I'm missing either a part of git history or just the orig
tarball, but what's the normal way to get it ?

(maybe there is a doc or wiki somewhere about this ?)

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why keep upstream sources in Git at salsa.d.o?

Andreas Metzler-2
Alexis Murzeau <[hidden email]> wrote:
> Le 13/08/2019 à 01:17, Daniel Leidert a écrit :
>> Am Montag, den 12.08.2019, 19:53 +0200 schrieb Marc Haber:
[...]
>>> I haven't heard that a debian/ only repository layout is possible with
>>> git-buildpackage before today.

>> Works nicely. I keep a file debian/gbp.conf usually with the content
[...]
> I'm curious about keeping only debian/ in git.
> How to build such git repository ?

> I've tried one of yours but failed like this:
[...]
> I guess I'm missing either a part of git history or just the orig
> tarball, but what's the normal way to get it ?

> (maybe there is a doc or wiki somewhere about this ?)

Looking at the manpage I think you'll need to give gbp a pointer to
where the upstream tarball is available.

--git-tarball-dir=DIRECTORY

cu Andreas

--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Reply | Threaded
Open this post in threaded view
|

Re: Why keep upstream sources in Git at salsa.d.o?

Daniel Leidert-2
In reply to this post by Alexis Murzeau-3
Am Dienstag, den 13.08.2019, 22:10 +0200 schrieb Alexis Murzeau:

[..]

> I'm curious about keeping only debian/ in git.
> How to build such git repository ?
>
> I've tried one of yours but failed like this:
> ```
> $ gbp clone https://salsa.debian.org/ruby-team/ruby-html-proofer
> gbp:info: Cloning from
> 'https://salsa.debian.org/ruby-team/ruby-html-proofer'
> $ cd ruby-html-proofer/
> $ gbp buildpackage "--git-builder=sbuild -v -As -d unstable" \
> > --git-export-dir=../build-area
> gbp:error: upstream/3.11.1 is not a valid treeish
> ```
>
> I guess I'm missing either a part of git history or just the orig
> tarball, but what's the normal way to get it ?
You need the tarball of course, which you can obtain via origtargz. The tarball
is expected to be found at the location specified in tarball_dir in /etc/git-
buildpackage/gbp.conf, ~/.gbp.conf or given via command line paramter. You can
also use the command line to run origtargz:

gbp clone https://salsa.debian.org/ruby-team/ruby-html-proofer
cd ruby-html-proofer
gbp buildpackage --git-preexport="origtargz -dt" --git-tarball-dir=../ \
                 --git-builder="sbuild -v -As -d unstable" \
                 --git-export-dir=../build-area/

> (maybe there is a doc or wiki somewhere about this ?)

It is not yet very well documented.

HTH and regards, Daniel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why keep upstream sources in Git at salsa.d.o?

Maximiliano Curia-2
In reply to this post by Daniel Leidert-2
¡Hola Daniel!

El 2019-08-13 a las 01:17 +0200, Daniel Leidert escribió:
> `gbp pq` doesn't work with this layout.

Actually, it does, you just have to add the option --pq-from=TAG.

Happy hacking,
--
"The most important thing in the programming language is the name. A language
will not succeed without a good name. I have recently invented a very good
name and now I am looking for a suitable language."
-- Donald Knuth
Saludos /\/\ /\ >< `/

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why keep upstream sources in Git at salsa.d.o?

Daniel Leidert-2
Am Mittwoch, den 14.08.2019, 09:48 -0300 schrieb Maximiliano Curia:
> El 2019-08-13 a las 01:17 +0200, Daniel Leidert escribió:
> > `gbp pq` doesn't work with this layout.
>
> Actually, it does, you just have to add the option --pq-from=TAG.

How so? There is no upstream branch. So independent of the setting in --pq-from
the command fails here. Are you referring to a layout, where an upstream branch
exists, but is not merged with the debian branch?

Regards, Daniel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why keep upstream sources in Git at salsa.d.o?

Maximiliano Curia-2
¡Hola Daniel!

El 2019-08-14 a las 15:16 +0200, Daniel Leidert escribió:
> Am Mittwoch, den 14.08.2019, 09:48 -0300 schrieb Maximiliano Curia:
>> El 2019-08-13 a las 01:17 +0200, Daniel Leidert escribió:
>>> `gbp pq` doesn't work with this layout.

>> Actually, it does, you just have to add the option --pq-from=TAG.

> How so? There is no upstream branch. So independent of the setting in --pq-from
> the command fails here. Are you referring to a layout, where an upstream branch
> exists, but is not merged with the debian branch?

I tend to work with a debian remote and an upstream remote. And reuse
upstream's release tag, that only works if the tag contents match the tarball
contents, of course, where they don't, I keep a local only set of
upstream/$version tags.

Happy hacking,
--
"Politicians and diapers have one thing in common. They should both be changed
regularly, and for the same reason."
-- José Maria de Eça de Queiroz
Saludos /\/\ /\ >< `/


signature.asc (849 bytes) Download Attachment