Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #13552 > unrolled thread

Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: python-django-js-asset_1.2.2-3_source.changes REJECTED Antonio Terceiro <terceiro@debian.org> - 2021-09-19 21:30 +0200
    Re: python-django-js-asset_1.2.2-3_source.changes REJECTED Carsten Schoenert <c.schoenert@t-online.de> - 2021-09-19 23:10 +0200
      Re: python-django-js-asset_1.2.2-3_source.changes REJECTED Andrey Rahmatullin <wrar@debian.org> - 2021-09-20 09:30 +0200
      Re: python-django-js-asset_1.2.2-3_source.changes REJECTED Antonio Terceiro <terceiro@debian.org> - 2021-09-20 13:30 +0200
        Re: python-django-js-asset_1.2.2-3_source.changes REJECTED Sandro Tosi <morph@debian.org> - 2021-09-20 17:20 +0200
          Re: python-django-js-asset_1.2.2-3_source.changes REJECTED Andrey Rahmatullin <wrar@debian.org> - 2021-09-20 17:30 +0200
            Re: python-django-js-asset_1.2.2-3_source.changes REJECTED Sandro Tosi <morph@debian.org> - 2021-09-21 03:20 +0200
          Re: python-django-js-asset_1.2.2-3_source.changes REJECTED Thomas Goirand <zigo@debian.org> - 2021-09-20 21:50 +0200
          Re: python-django-js-asset_1.2.2-3_source.changes REJECTED Antonio Terceiro <terceiro@debian.org> - 2021-09-21 23:10 +0200
            Re: python-django-js-asset_1.2.2-3_source.changes REJECTED Sandro Tosi <morph@debian.org> - 2021-09-22 00:40 +0200
            Re: writing debian/gbp.conf considered harmful [was:  python-django-js-asset_1.2.2-3_source.changes REJECTED] Thomas Goirand <zigo@debian.org> - 2021-09-22 09:30 +0200

#13552 — Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Sun, Sep 19, 2021 at 10:27:21AM +0200, Carsten Schoenert wrote:
> Hello Antonio,
> 
> as you initially did the first upload for this package I'm now heading
> over to you.
> 
> Am 19.09.21 um 09:48 schrieb Debian FTP Masters:
> > 
> > python-django-js-asset_1.2.2-3.dsc: Invalid size hash for python-django-js-asset_1.2.2.orig.tar.gz:
> > According to the control file the size hash should be 6360,
> > but python-django-js-asset_1.2.2.orig.tar.gz has 6367.
> > 
> > If you did not include python-django-js-asset_1.2.2.orig.tar.gz in your upload, a different version
> > might already be known to the archive software.
> 
> I've no idea where the size of 6360 for the orig.tar.gz file is coming
> from which DAK refers.
> 
> If I look at the source package sites or on snapshot.d.o I always see a
> size of 6367.
> 
> https://packages.debian.org/source/unstable/python-django-js-asset
> http://snapshot.debian.org/package/python-django-js-asset/1.2.2-1/
> 
> And this size was recreated by gbp locally.
> But the question is now how to proceed now. A quick & dirty solution
> would be to simply use the old tar.gz file (if available).
> Another option would be more dramatically and let remove the package
> completely from the archive. Do you have opinions on that?

Looking from my side, the tarball from the archive (apt source
python-django-js-asset) and the one generated by pristine-tar are
identical:

4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  /tmp/python-django-js-asset_1.2.2.orig.tar.gz
4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  /tmp/archive/python-django-js-asset_1.2.2.orig.tar.gz

From reading the REJECT email, I think it implies that the .dsc/.changes
you uploaded refer to an orig tarball with 6360 bytes. Do you still have
the exact artifacts that you uploaded?

[toc] | [next] | [standalone]

#13553

Hi Antonio,

thanks for your quick feedback!

Am 19.09.21 um 21:24 schrieb Antonio Terceiro:

> Looking from my side, the tarball from the archive (apt source
> python-django-js-asset) and the one generated by pristine-tar are
> identical:
> 
> 4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  /tmp/python-django-js-asset_1.2.2.orig.tar.gz
> 4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  /tmp/archive/python-django-js-asset_1.2.2.orig.tar.gz
> 
>  From reading the REJECT email, I think it implies that the .dsc/.changes
> you uploaded refer to an orig tarball with 6360 bytes. Do you still have
> the exact artifacts that you uploaded?

No, not completely.
But I played around a bit with gbp and pristine-tar too and I was able 
to recreate a tarball which has the same size and the same hashes as the 
*.tar.gz in the archive and the one you've posted by using pristine-tar 
manually.

If I clean out all completely and build the package from scratch by gbp 
I get again a wrong size and of course also different hashes.

Currently I've no real clue why gbp is creating here different results, 
will look again at this once Guido is around, I'm sure he can blame me 
that I'm doing something wrong. :P

I was able to upload 1.2.2-3 successful recently so no big problem any more.

-- 
Regards
Carsten

[toc] | [prev] | [next] | [standalone]

#13556

[Multipart message — attachments visible in raw view] — view raw

On Sun, Sep 19, 2021 at 10:56:33PM +0200, Carsten Schoenert wrote:
> Hi Antonio,
> 
> thanks for your quick feedback!
> 
> Am 19.09.21 um 21:24 schrieb Antonio Terceiro:
> 
> > Looking from my side, the tarball from the archive (apt source
> > python-django-js-asset) and the one generated by pristine-tar are
> > identical:
> > 
> > 4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  /tmp/python-django-js-asset_1.2.2.orig.tar.gz
> > 4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  /tmp/archive/python-django-js-asset_1.2.2.orig.tar.gz
> > 
> >  From reading the REJECT email, I think it implies that the .dsc/.changes
> > you uploaded refer to an orig tarball with 6360 bytes. Do you still have
> > the exact artifacts that you uploaded?
> 
> No, not completely.
> But I played around a bit with gbp and pristine-tar too and I was able to
> recreate a tarball which has the same size and the same hashes as the
> *.tar.gz in the archive and the one you've posted by using pristine-tar
> manually.
> 
> If I clean out all completely and build the package from scratch by gbp I
> get again a wrong size and of course also different hashes.
As pristine-tar is not enabled in debian/gbp.conf you need to enable it
explicitly with --git-pristine-tar each time you run a command that uses
it.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#13557

[Multipart message — attachments visible in raw view] — view raw

On Sun, Sep 19, 2021 at 10:56:33PM +0200, Carsten Schoenert wrote:
> Hi Antonio,
> 
> thanks for your quick feedback!
> 
> Am 19.09.21 um 21:24 schrieb Antonio Terceiro:
> 
> > Looking from my side, the tarball from the archive (apt source
> > python-django-js-asset) and the one generated by pristine-tar are
> > identical:
> > 
> > 4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  /tmp/python-django-js-asset_1.2.2.orig.tar.gz
> > 4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  /tmp/archive/python-django-js-asset_1.2.2.orig.tar.gz
> > 
> >  From reading the REJECT email, I think it implies that the .dsc/.changes
> > you uploaded refer to an orig tarball with 6360 bytes. Do you still have
> > the exact artifacts that you uploaded?
> 
> No, not completely.
> But I played around a bit with gbp and pristine-tar too and I was able to
> recreate a tarball which has the same size and the same hashes as the
> *.tar.gz in the archive and the one you've posted by using pristine-tar
> manually.
> 
> If I clean out all completely and build the package from scratch by gbp I
> get again a wrong size and of course also different hashes.
> 
> Currently I've no real clue why gbp is creating here different results, will
> look again at this once Guido is around, I'm sure he can blame me that I'm
> doing something wrong. :P

That's because gbp does not use pristine-tar by default, and
debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
fix that.

[toc] | [prev] | [next] | [standalone]

#13558

> That's because gbp does not use pristine-tar by default, and
> debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
> fix that.

I dont think this is the right approach: the default options to work
on DPT packages should be in gbp default config file (or in another,
global, config file), and not live in each and every package
debian/gbp.conf file; it is already inconsistently maintained with
several packages having uncommon settings that will take precedence
over the default ones.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

[toc] | [prev] | [next] | [standalone]

#13559

[Multipart message — attachments visible in raw view] — view raw

On Mon, Sep 20, 2021 at 11:14:44AM -0400, Sandro Tosi wrote:
> > That's because gbp does not use pristine-tar by default, and
> > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
> > fix that.
> I dont think this is the right approach: the default options to work
> on DPT packages should be in gbp default config file (or in another,
> global, config file), and not live in each and every package
> debian/gbp.conf file;
What's the mechanism to put these options there for everyone who works on
a DPT package? Or do you mean just working with whatever is shipped with
gbp?

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#13562

On Mon, Sep 20, 2021 at 11:21 AM Andrey Rahmatullin <wrar@debian.org> wrote:
> On Mon, Sep 20, 2021 at 11:14:44AM -0400, Sandro Tosi wrote:
> > > That's because gbp does not use pristine-tar by default, and
> > > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
> > > fix that.
> > I dont think this is the right approach: the default options to work
> > on DPT packages should be in gbp default config file (or in another,
> > global, config file), and not live in each and every package
> > debian/gbp.conf file;
> What's the mechanism to put these options there for everyone who works on
> a DPT package?

that's a great question! i dont think a technical solution currently exists.

> Or do you mean just working with whatever is shipped with
> gbp?

that wont work, but there could be a solution if we request a new
feature in gbp.

According to man 5 gbp.conf, there is either a global configuration
file, a per user file or a per repo/branch. In order to support
different workflows (for different teams, f.e.), this is not
sufficient.

But it could work if gbp.conf supported something similar to gitconfig
includeIf: in my ~/.gitconfig i have

```
[includeIf "gitdir:~/deb/"]
   path = ~/.gitconfig-deb
```

(~/deb is where i keep all my Debian work), and that means that if the
CWD is part of the ~/deb/ tree, git will also include ~/.gitconfig-deb
which contains Debian-specific configs, like the @d.o mail address.

Now, we'd also need a single location to store the team-specific
gbp.conf, and we already have a repo thta would fit:
https://salsa.debian.org/python-team/tools/packages , which currently
contains files useful to work on the entire team packages. This is
useful in my specific workflow, which is suspect is rather unusual,
but here how it goes:

* i checked https://salsa.debian.org/python-team/tools/packages in
~/deb/python (this could be anywhere)
* run ./checkout -a to checkout all team packages (or ./checkout
<pkg1>... for only a subset)
* use `mr` (via .mcrconfig) to work on _m_ultiple _r_epositories (mr)

this repo could also contain a team-specific gbp.conf file we could
use. Admittedly, we probably only need a handful of options,
pristine-tar = True is only one that comes to mind (be aware this file
will need to be compatible with *all* repos currently in the team, so
setting the debian branch etc, wont work, until all repos are
uniform).

I'm going to file a feature request for the includeIf-like feature for gbp

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

[toc] | [prev] | [next] | [standalone]

#13561

On 9/20/21 5:14 PM, Sandro Tosi wrote:
>> That's because gbp does not use pristine-tar by default, and
>> debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
>> fix that.
> 
> I dont think this is the right approach: the default options to work
> on DPT packages should be in gbp default config file (or in another,
> global, config file), and not live in each and every package
> debian/gbp.conf file; it is already inconsistently maintained with
> several packages having uncommon settings that will take precedence
> over the default ones.

+1

Plus gbp is just *one* out of *many* tools available. Some people just
prefer to use sbuild only, for example, and that's perfectly fine. IMO
it's up to the person that's using gbp to know what they are doing.

FYI, I've rebuilt regularly packages from the team, I even have
"pristine-tar = False" in my ~/.gbp.conf, and it's all fine...

Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [next] | [standalone]

#13564

[Multipart message — attachments visible in raw view] — view raw

On Mon, Sep 20, 2021 at 11:14:44AM -0400, Sandro Tosi wrote:
> > That's because gbp does not use pristine-tar by default, and
> > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
> > fix that.
> 
> I dont think this is the right approach: the default options to work
> on DPT packages should be in gbp default config file (or in another,
> global, config file), and not live in each and every package
> debian/gbp.conf file; it is already inconsistently maintained with
> several packages having uncommon settings that will take precedence
> over the default ones.

I agree with you in theory; my global gbp.cons enables pristine-tar.

However, having it duplicated in every package means we as a team work
consistently regardless of people's global configuration, and that's one
less detail people need to get just right to be able to contribute
effectively.

Also, one's global configuration might not apply to all the packages
they contribute to; it's easier for everyone if gbp just does the
right thing based on per-package configuration than expecting people to
remember to switch their defaults, or to pass options explicitly.

[toc] | [prev] | [next] | [standalone]

#13565

On Tue, Sep 21, 2021 at 5:00 PM Antonio Terceiro <terceiro@debian.org> wrote:
>
> On Mon, Sep 20, 2021 at 11:14:44AM -0400, Sandro Tosi wrote:
> > > That's because gbp does not use pristine-tar by default, and
> > > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
> > > fix that.
> >
> > I dont think this is the right approach: the default options to work
> > on DPT packages should be in gbp default config file (or in another,
> > global, config file), and not live in each and every package
> > debian/gbp.conf file; it is already inconsistently maintained with
> > several packages having uncommon settings that will take precedence
> > over the default ones.
>
> I agree with you in theory; my global gbp.cons enables pristine-tar.
>
> However, having it duplicated in every package means we as a team work
> consistently regardless of people's global configuration,

not at all, right now we dont have a *consistent* debian/gbp.conf in
each package, everyone writes their own and it's currently a mess.

what when we decide to add a new option, or change the value of an
existing one? DPT currently has ~2500 packages: how do you maintain
consistency in all of them?

> and that's one
> less detail people need to get just right to be able to contribute
> effectively.
>
> Also, one's global configuration might not apply to all the packages
> they contribute to; it's easier for everyone if gbp just does the
> right thing based on per-package configuration than expecting people to
> remember to switch their defaults, or to pass options explicitly.

please refer to
https://lists.debian.org/debian-python/2021/09/msg00065.html for how i
see this being implemented.


--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

[toc] | [prev] | [next] | [standalone]

#13566 — Re: writing debian/gbp.conf considered harmful [was: python-django-js-asset_1.2.2-3_source.changes REJECTED]

On 9/21/21 11:00 PM, Antonio Terceiro wrote:
> However, having it duplicated in every package means we as a team work
> consistently regardless of people's global configuration, and that's one
> less detail people need to get just right to be able to contribute
> effectively.

No. It *ALREADY* works by default, no need to tweak anything on
debian/gbp.conf. Also, as I wrote already, using gbp buildpackage is
*NOT* the only one way of doing things. One can use sbuild without gbp.
What you're proposing is in fact the same as if you were proposing to
add defaults for some text editors in the packaging: that's irrelevant,
and hard to maintain consistently (like Sandro wrote).

> Also, one's global configuration might not apply to all the packages
> they contribute to

It is the case for me: I contribute to both the OpenStack team and the
Python team. Both teams have *very* different workflow (the Python team
is using pristine-tar, I don't like it and that's the main reason why
OpenStack is maintained outside of this team...).

In the OpenStack team, we used to maintain per-package debian/gbp.conf.
I am *very* happy we decided back in Debconf Montreal in 2017 to stop
doing that.

> it's easier for everyone if gbp just does the
> right thing based on per-package configuration than expecting people to
> remember to switch their defaults, or to pass options explicitly.

There's nothing to switch. One just needs to remember to explicitly
generate the tarball with "gbp export-orig", OR (preferred) directly
fetch the orig.tar.{gz,xz} from the Debian archive. If you forget, gbp
complains about it and stops building (that is, as long as you have the
option "no-create-orig = True" in your ~/.gbp.conf).

Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web