Bug#945447: RFS: emacs-websocket/1.12+1.g74e4b82-1 [ITP] -- Emacs WebSocket client and server
On 2019-11-27 07:43:59, Nicholas D Steeves wrote:
> Hi Antoine,
>
> Antoine Beaupré <anarcat@debian.org> writes:
>
>> A few comments...
>>
>> Why do you specify a compression level and algorithm in gbp.conf?
>>
>> compression = xz
>> compression-level = 9
>>
>
> This reduces the incidence of encountering an annoying gbp bug, where
> gbp fails, allegedly because "two tarballs were found", even when the
> tarball did not previously exist on disk and is generated on demand from
> upstream tag.
I have not found this to be a problem enough to proactively add this
setting when it's not necessary.
> Other than that it's harmless and redundant, because these settings
> are now gbp defaults.
Really! What do you base this on? The manpages of "gbp-buildpackage(1)"
in both buster and sid currently say:
--git-compression=TYPE
Specifies the upstream tarball compression type. This will be used to locate
and build the upstream tarball if necessary. The default is auto which derives
the compression type from the pristine-tar branch if available and falls back
to gzip otherwise. Other options are gzip, bzip2, lzma and xz.
--git-compression-level=LEVEL
Specifies the upstream tarball compression level if an upstream tarball needs
to be built.
The keyword here is "default is auto". :p I'm especially concerned about
the excessively high compression-level as well - it's usually not
necessary to change the compression level, and makes it diverge
needlessly from upstream.
>> Upstream doesn't seem to use any peculiar tarball format, so that
>> generated tarball won't match the one published on github.
What I should have written here, for the record, is more like "upstream
doesn't use .xz and uses the default github-generated .gz files".
> I'm using release tags directly and not github generated & published
> tarballs ("why" is another discussion).
I would argue it's the core of this discussion here. You haven't
convinced me that using a .xz tarball format is necessary at all, nor
why you need to diverge from the upstream tarballs.
> The reason the Emacsen Team requests a tarball in d/watch is because
> the git mode we previously used was too resource-intensive.
This seems like another reason to stick with .tgz and not diverge.
> The bug mentioned above also has a useful (hack of a) side-effect in
> that it seems to enforce new upstream version imports from git tags
> rather than github-generated tarballs.
I'm confused - how does compression and compression-level enforce
importing from git tags? And how does that differ from github-generated
tarballs which *are* (reproducibly too) generated frmo git-tags as well?
> Whenever the "light" git-mode becomes generally recommended and
> preferred over the tarball one I'll switch my upstream-uses-github
> packages over to it.
I don't understand what this refers to.
>> I also wonder if it's really necessary to ship a git snapshot instead of
>> the 1.12 release... I see it includes a patch to tweak the GPL version,
>> is that why that was done?
>
> For multiple past NEW packages, ftpmasters have asked me to contact
> upstream about licensing problems (eg: we're accepting, but you need to
> do xyz), so I started doing this preRFS. Then lamby asked me not to
> carry licensing-related-changes as a quilt patch--with good rationale
> that I agree with. Thus, packaging a git snapshot. The contradictory
> declared license issue is here:
>
> https://github.com/ahyatt/emacs-websocket/issues/62
Cool, makes sense.
>> Are the tests included in the package build? or autopkgtest? could that
>> be done? Not a blocker.
>>
>
> Sorry, I don't understand what you mean... ERT tests are already run
> during the build, autopkgtest-pkg-elpa has been activated
> (d/control:L12), I've confirmed autopkgtest runs the tests, and I've
> also opened an upstream issue about integrating the functional tests
> into the ERT framework:
>
> https://github.com/ahyatt/emacs-websocket/issues/64
Awesome, that answers my question, thanks!
> Since all NEW packages now require two uploads before they can enter
> testing, I like to add value to the second upload, and the following
> brand new commit seems like a good candidate for this:
>
> https://github.com/ahyatt/emacs-websocket/commit/69ee80a88ba825a925e82a5576a340b3ec03fd51
>
> Depending on how long it takes this package to pass NEW upstream might
> tag a new release including that commit, which would be ideal for the
> second upload!
Cool.
>> Otherwise looks good.
>>
>
> Thanks for reviewing :-) 'hope my reply sufficiently addresses your
> concerns!
Not quite. Your reply about the compression level stuff makes me more
worried than anything, to be honest. :p
I would like us to stick with the actual gbp defaults here, which are
"auto" and can easily pick up upstream tgz defaults.
A.
--
One of the strongest motives that leads men to art and science is
escape from everyday life with its painful crudity and hopeless
dreariness. Such men make this cosmos and its construction the pivot
of their emotional life, in order to find the peace and security which
they cannot find in the narrow whirlpool of personal experience.
- Albert Einstein
Reply to: