Note that kernel.org signs the raw tar file and not the compressed
file. This way, they avoid issues like that and also allow conversion
into different compression formats while the signature stays valid.
Downside is that you have to decompress it first and then hash quite a
big file for
* FC Stegerman , 2023-02-19 21:08:
(There was a recent LWN article covering this, see
https://lwn.net/Articles/921787/.)
That seems to be subscribers-only :(
Here you go:
https://lwn.net/SubscriberLink/921787/ff1350f40f12fb8e/
--
Jakub Wilk
On 19.02.23 21:08, FC Stegerman wrote:
* Guillem Jover [2023-02-19 20:50]:
My upstream creates a tarball with git-archive, creates a signature and
uploads it (as described in the wiki[3]). This used to work to verify
the github-created tarball, but fails now - while creating my own
tarball
* Guillem Jover [2023-02-19 20:50]:
> > My upstream creates a tarball with git-archive, creates a signature and
> > uploads it (as described in the wiki[3]). This used to work to verify
> > the github-created tarball, but fails now - while creating my own
> > tarball like upstream and verifying
Hi!
On Sun, 2023-02-19 at 18:34:56 +0100, Jens Reyer wrote:
> [This is a followup to the thread "Q: uscan with GitHub" at
> https://lists.debian.org/debian-devel/2022/10/msg00313.html. I manually set
> in-reply-to, but am not sure if it'll work.]
> My upstream creates a ta
[This is a followup to the thread "Q: uscan with GitHub" at
https://lists.debian.org/debian-devel/2022/10/msg00313.html. I manually
set in-reply-to, but am not sure if it'll work.]
> On Tue, Oct 11, 2022 at 10:23 AM Stephan Lachnit
wrote:
>> On Sun, Oct 9, 2022 at 7:
On Tue, Oct 11, 2022 at 10:23 AM Stephan Lachnit
wrote:
> On Sun, Oct 9, 2022 at 7:06 PM Volans wrote:
> >
> > I've encountered the same problem and come out with a version of the
> watch file using the GitHub APIs. In my case I also needed to download the
> PGP signature. I've add some
On Sun, Oct 9, 2022 at 7:06 PM Volans wrote:
>
> I've encountered the same problem and come out with a version of the watch
> file using the GitHub APIs. In my case I also needed to download the PGP
> signature. I've add some comments to the watch file for an easier
> understanding.
>
> The
>
> On Mon, 19 Sep 2022 at 18:12:15 +0200, Samuel Thibault wrote:
> > julien.pu...@gmail.com, le lun. 19 sept. 2022 18:00:37 +0200, a ecrit:
> > > Le lundi 19 septembre 2022 à 20:50 +0900, Hideki Yamane a écrit :
> > > > Recent changes in GitHub releases pages, I cannot check upstream
> > > >
Hi,
Quoting Paul Wise (2022-09-20 02:38:30)
> On Mon, 2022-09-19 at 20:50 +0900, Hideki Yamane wrote:
> > Recent changes in GitHub releases pages, I cannot check upstream
> > version with uscan. How do you deal with it?
>
> If you are using the automatically generated tarballs, then
> just
On Tue, Sep 20, 2022 at 08:36:48AM +0800, Paul Wise wrote:
> On Mon, 2022-09-19 at 18:54 +0200, Andrea Pappacoda wrote:
> > Hi, what I usually do with GitHub is to use its API, since it has the
> > advantage of not breaking uscan when they do changes to the web UI.
> Since the API uses pagination,
On Tue, Sep 20, 2022 at 10:36 AM Samuel Henrique
wrote:
> On Tue 20 Sept 2022, 01:39 Paul Wise, wrote:
>
> On Mon, 2022-09-19 at 18:54 +0200, Andrea Pappacoda wrote:
>
> > Hi, what I usually do with GitHub is to use its API, since it has the
> > advantage of not breaking uscan when they do
On Tue 20 Sept 2022, 01:39 Paul Wise, wrote:
On Mon, 2022-09-19 at 18:54 +0200, Andrea Pappacoda wrote:
> Hi, what I usually do with GitHub is to use its API, since it has the
> advantage of not breaking uscan when they do changes to the web UI.
Since the API uses pagination, this has the
On Mon, 2022-09-19 at 18:12 +0200, Samuel Thibault wrote:
> The problem is that the tags page only contains snapshots of the
> repository, and not an autoconf-ed tarball.
I think that is an advantage, because then you can be sure that you can
rebuild the autotools generated files from source
On Mon, 2022-09-19 at 20:50 +0900, Hideki Yamane wrote:
> Recent changes in GitHub releases pages, I cannot check upstream
> version with uscan. How do you deal with it?
If you are using the automatically generated tarballs, then
just switching to the uscan git mode seems like the way to go.
On Mon, 2022-09-19 at 18:54 +0200, Andrea Pappacoda wrote:
> Hi, what I usually do with GitHub is to use its API, since it has the
> advantage of not breaking uscan when they do changes to the web UI.
Since the API uses pagination, this has the minor downside of making it
harder to use the uscan
Il giorno lun 19 set 2022 alle 18:12:15 +02:00:00, Samuel Thibault
ha scritto:
That works for the tags page, but not for the releases page... The
problem is that the tags page only contains snapshots of the
repository,
and not an autoconf-ed tarball. For instance since recently uscan
cannot
On Mon, 19 Sep 2022 at 18:12:15 +0200, Samuel Thibault wrote:
> julien.pu...@gmail.com, le lun. 19 sept. 2022 18:00:37 +0200, a ecrit:
> > Le lundi 19 septembre 2022 à 20:50 +0900, Hideki Yamane a écrit :
> > > Recent changes in GitHub releases pages, I cannot check upstream
> > > version with
julien.pu...@gmail.com, le lun. 19 sept. 2022 18:00:37 +0200, a ecrit:
> Le lundi 19 septembre 2022 à 20:50 +0900, Hideki Yamane a écrit :
> >
> > Recent changes in GitHub releases pages, I cannot check upstream
> > version with uscan. How do you deal with it?
>
> It's not that recent ; here is
Hi,
Le lundi 19 septembre 2022 à 20:50 +0900, Hideki Yamane a écrit :
>
> Recent changes in GitHub releases pages, I cannot check upstream
> version with uscan. How do you deal with it?
It's not that recent ; here is a working example:
version=4
opts="\
dversionmangle=s/\+dfsg.*$//,\
Hi,
Recent changes in GitHub releases pages, I cannot check upstream version
with uscan. How do you deal with it?
$ cat debian/watch
version=4
https://github.com/KittyKatt/screenFetch/releases
/KittyKatt/screenFetch/archive/refs/tags/v*@ANY_VERSION@@ARCHIVE_EXT@
$ uscan --no-download
21 matches
Mail list logo
