On Wed, Mar 31, 2021 at 3:50 PM Andreas Tille wrote:
> My favourite solution would be to rather use the idea to base this
> on the VCSwatch result and automatically change VCS.
VCSwatch only looks at repositories linked from Debian Vcs-* headers,
not the upstream VCS repositories.
--
bye,
pabs
On Wed, Mar 31, 2021 at 3:46 PM Andreas Tille wrote:
> But I do not want an uscan warning for every single commit. Is git mode
> able to distinguish random commits from official releases (tags)?
The manual page lists an option for that so it seems likely.
--
bye,
pabs
Hi Wookey,
On Sat, Mar 27, 2021 at 10:45:42PM +, Wookey wrote:
>
> Has anyone tried asking github if they are willing to specify and
> support a stable interface (maybe even revert this change for the time
> being). It's quite a big deal when they change these things,
> especially just
On Sun, Mar 28, 2021 at 06:41:52AM +, Paul Wise wrote:
> The problem with it was that it was entirely separate to the
> maintainer's files so it was often different to their preferred way of
> doing things. One option for doing this more optimally would be to add
> some code to vcswatch to
On Mon, Mar 29, 2021 at 6:33 PM Olek Wojnar wrote:
> Thanks for sharing that, the automated test build is a great feature! It
> would be useful if maintainers could opt-in to using something like that for
> specific packages.
The Janitor is doing something like that:
On Sun, Mar 28, 2021 at 2:42 AM Paul Wise wrote:
>
> doing things. One option for doing this more optimally would be to add
> some code to vcswatch to extract debian/watch files from the Vcs-*
> repos and pass those to UDD, which could then run uscan with the VCS
> debian/watch files where they
On Sat, Mar 27, 2021 at 10:18 AM Gard Spreemann wrote:
> Phil Morrell writes:
>
> > Sounds like you're asking for a new github redirector on qa.debian.org
> > as there is for sf.net, which could use the official api for stability.
FTR there is one of those here:
Has anyone tried asking github if they are willing to specify and
support a stable interface (maybe even revert this change for the time
being). It's quite a big deal when they change these things,
especially just before a stable release.
Having a reliable way to check the current release
On Fri, Mar 26, 2021 at 10:38:57PM +0100, Andreas Tille wrote:
> This breaks at least all Debian Med packages refereing to Github and
> probably way more. This means our toolset will fail to detect new
> upstream versions.
>
> Any idea what to do (besides uploading all packages obtained from
>
On Sat, Mar 27, 2021 at 12:26:29PM +0100, Andreas Tille wrote:
> Hi Bart,
>
> On Sat, Mar 27, 2021 at 07:38:17AM +0100, Bart Martens wrote:
> > On Fri, Mar 26, 2021 at 11:43:27PM +0100, Yadd wrote:
> > > Le 26/03/2021 à 22:38, Andreas Tille a écrit :
> > > > Any idea what to do (besides uploading
Hi Bart,
On Sat, Mar 27, 2021 at 07:38:17AM +0100, Bart Martens wrote:
> On Fri, Mar 26, 2021 at 11:43:27PM +0100, Yadd wrote:
> > Le 26/03/2021 à 22:38, Andreas Tille a écrit :
> > > Any idea what to do (besides uploading all packages obtained from
> > > Github right after the release)?
> >
> >
Phil Morrell writes:
> Sounds like you're asking for a new github redirector on qa.debian.org
> as there is for sf.net, which could use the official api for stability.
This got me thinking: the version checking mechanism of d/watch files is
useless if the outside world changes, i.e. if
On Fri, Mar 26, 2021 at 11:43:27PM +0100, Yadd wrote:
> Le 26/03/2021 à 22:38, Andreas Tille a écrit :
> > I just learned that what was formerly something like
> >
> > .*/archive/
> >
> > became now
> >
> > .*/archive/refs/tags/
> >
> > This breaks at least all Debian Med packages
Le 26/03/2021 à 22:38, Andreas Tille a écrit :
> Hi,
>
> I just learned that what was formerly something like
>
>https://github.com/#GITHUBUSER#/#PACKAGE#/releases/latest
> .*/archive/#PREFIX#@ANY_VERSION@\.tar\.gz
>
> has to be
>
>
Hi Timo,
On Fri, Mar 26, 2021 at 10:55:14PM +0100, Timo Röhling wrote:
> Hi Andreas,
>
> * Andreas Tille [2021-03-26 22:38]:
> > https://github.com/#GITHUBUSER#/#PACKAGE#/releases/latest
> > .*/archive.*/#PREFIX#@ANY_VERSION@\.tar\.gz
>
> As .* also matches forward slashes, I use
>
>
Hi Andreas,
* Andreas Tille [2021-03-26 22:38]:
https://github.com/#GITHUBUSER#/#PACKAGE#/releases/latest
.*/archive.*/#PREFIX#@ANY_VERSION@\.tar\.gz
As .* also matches forward slashes, I use
https://github.com/#GITHUBUSER#/#PACKAGE#/releases/latest
.*/#PREFIX#@ANY_VERSION@\.tar\.gz
Hi,
I just learned that what was formerly something like
https://github.com/#GITHUBUSER#/#PACKAGE#/releases/latest
.*/archive/#PREFIX#@ANY_VERSION@\.tar\.gz
has to be
https://github.com/#GITHUBUSER#/#PACKAGE#/releases/latest
.*/archive.*/#PREFIX#@ANY_VERSION@\.tar\.gz
now (at least)
17 matches
Mail list logo
