changes on git submodule
Maybe consult man debian-watch and note that afaik the newline after
Version: 5 is mandatory.
By chance I forgot this hint and it works even without the newline.
Thanks a lot for your hints
Cheers,
Yadd
> Maybe consult man debian-watch and note that afaik the newline after
> Version: 5 is mandatory.
By chance I forgot this hint and it works even without the newline.
Thanks a lot for your hints
Andreas.
--
https://fam-tille.de
Pattern: HEAD
Mode: git
Git-Pretty: 0.0~git%cd
Maybe consult man debian-watch and note that afaik the newline after
Version: 5 is mandatory.
Best,
--
Carl
signature.asc
Description: PGP signature
Hi again,
the Gitlab template is checking the tags of the project - great.
Unfortunately some projects do not use tags - specifically in golang
packages this is more or less the normal state. For instance there
are watch files like in golang-github-jacobsa-timeutil[1]:
version=4
opts="
Hi again,
Am Wed, Aug 20, 2025 at 10:19:06AM +0200 schrieb Andreas Tille:
> Am Wed, Aug 20, 2025 at 08:35:32AM +0200 schrieb Xavier:
> > BTW, I found a way to build a template for Gitlab
>
> I love to repeat: You rock!
Maybe there is another challenge with this watch
Hi,
> Il giorno 1 set 2025, alle ore 22:59, Peter B ha
> scritto:
>
> Had a quick look at some of these.
> Is a blank line needed after the first line with "Version: 5" in it?
>
Yes, the version has to live in its own paragraph. See the manpage
debian-watc
On 01/09/2025 21:09, Lucas Nussbaum wrote:
..snip..
And according to UDD there are a few other that are failing:
..snip
Had a quick look at some of these.
Is a blank line needed after the first line with "Version: 5" in it?
Cheers,
Peter
On Tue Sep 2, 2025 at 9:14 AM CEST, Marc Haber wrote:
It would be nice if uscan would recognize both version= and Version:.
It currently gets confused and falls back to more ancient versions,
giving misleading error messages, when one accidentally starts a v5
file with "version=5", which is an
h. See the manpage
debian-watch, “Format of the Watch file, version 5”.
It would be nice if uscan would recognize both version= and Version:. It
currently gets confused and falls back to more ancient versions, giving
misleading error messages, when one accidentally starts a v5 file with
"ve
Andrea Pappacoda:
Hi,
Il giorno 1 set 2025, alle ore 22:59, Peter B ha
scritto:
Had a quick look at some of these.
Is a blank line needed after the first line with "Version: 5" in it?
Yes, the version has to live in its own paragraph. See the manpage
debian-watch, “Format of
lable
> > node-redis | 4.6.14+~1.1.2-2 || | only
> > older package available
> > (10 rows)
>
> I filed https://bugs.debian.org/1113722 because the qa.debian.org
> watch service isn't working with Version: 5 watch files.
Quoting the bug repo
| | newer
> package available
> gloo-cuda | 0.0~git20231202.5354032-5 || | newer
> package available
> node-redis | 4.6.14+~1.1.2-2 || | only older
> package available
> (10 rows)
I filed https://bugs.debian.org/1113
On Sat, 2025-08-23 at 17:49 +0200, Joachim Zobel wrote:
> Hi.
>
> The watch file mosquitto has stopped working [1] while uscan still
> reports the version. Is there a way reproduce what the watch cgi is
> doing so I can reserch this.
[...]
This is bug #1112065. You can avoid th
Russ Allbery writes ("Gerrit and different merge UIs (was: debian/watch version
5)"):
> One feature I do still miss from Gerrit that I don't think GitHub has is
> the ability to merge a single commit from a merge request composed of
> multiple commits. With GitHub, so
On 22/08/25 at 13:15 -0700, Otto Kekäläinen wrote:
> Maybe we can have more of this, but note that we already have at least
> 7 avenues for the information about an open MR can reach the
> maintainer: https://wiki2025.debian.org/wiki/Salsa. I think this
> ultimately boils down to people who dislike
Hi.
Thanks for the replies. I have learned by now:
1. uscan -v tests what I can see on my DDPO page.
2. uscan should do this without warnings.
3. I should use the latest version of devscripts.
Sincerly,
Joachim
On Saturday, August 23, 2025 8:49:50 AM Mountain Standard Time Joachim Zobel
wrote:
> Hi.
>
> The watch file mosquitto has stopped working [1] while uscan still
> reports the version. Is there a way reproduce what the watch cgi is
> doing so I can reserch this.
>
> Than
Hi,
On Fri, 22 Aug 2025 at 14:33, Theodore Tso wrote:
> On Fri, Aug 22, 2025 at 01:15:54PM -0700, Otto Kekäläinen wrote:
> > Maybe we can have more of this, but note that we already have at least
> > 7 avenues for the information about an open MR can reach the
> > maintainer: https://wiki2025.deb
Hi,
On Sat, Aug 23, 2025 at 05:49:50PM +0200, Joachim Zobel wrote:
> Hi.
>
> The watch file mosquitto has stopped working [1] while uscan still
> reports the version. Is there a way reproduce what the watch cgi is
> doing so I can reserch this.
>
> Thanks,
>
Hi.
The watch file mosquitto has stopped working [1] while uscan still
reports the version. Is there a way reproduce what the watch cgi is
doing so I can reserch this.
Thanks,
Joachim
[1] https://qa.debian.org/cgi-bin/watch?pkg=mosquitto
On Fri, Aug 22, 2025 at 01:15:54PM -0700, Otto Kekäläinen wrote:
> Maybe we can have more of this, but note that we already have at least
> 7 avenues for the information about an open MR can reach the
> maintainer: https://wiki2025.debian.org/wiki/Salsa. I think this
> ultimately boils down to peop
Hi!
On Sun, 17 Aug 2025 at 05:57, Theodore Ts'o wrote:
> On Sun, Aug 17, 2025 at 12:54:14AM -0700, Otto Kekäläinen wrote:
> > I am in fact mentoring two out of the nine GSoC students we have, plus
> > a dozen other new contributors as part of regular mentoring under the
> > Debian mentoring umbre
Am Wed, Aug 20, 2025 at 08:35:32AM +0200 schrieb Xavier:
> BTW, I found a way to build a template for Gitlab
I love to repeat: You rock!
Thanks a lot
Andreas.
--
https://fam-tille.de
r a écrit :
>>>>>
>>>>> What do you think ?
>>
>> Great work! I love it!
>>
>>>> Thank you for this work! It makes watch files much more readable.
>>>>
>>>> Later a further improvement could be to generate a d
Hi Russ,
Thanks for writing a long reply! I just wanted to acknowledge I fully
read it and look forward to hearing more learnings from your career
over a pint of beer at the next event we attend, and I am glad to also
share my learnings from various CI and CR systems and what I think
works best fo
On 8/19/25 08:09, Alexandre Detiste wrote:
Thank you very much for this.
One personal request: can the Filename-Mangle be preset in the GitHub
template ?
It s horribly annoying to roll back 3 branches because some random other
project' s v2.0.1.tar.gz was imported on top of an existing repo.
Thank you very much for this.
One personal request: can the Filename-Mangle be preset in the GitHub
template ?
It s horribly annoying to roll back 3 branches because some random other
project' s v2.0.1.tar.gz was imported on top of an existing repo.
Greetings
Le mar. 19 août 2025, 07:59, Yadd
On 8/18/25 22:25, Lucas Nussbaum wrote:
[...]
Hi,
I updated the vendorized copy of devscripts in UDD to version 2.25.18,
and then forced a refresh of version:5 packages.
Everything works fine.
udd=> select source, version, errors, warnings, status from upstream where
watch_file ~* 'version:
> https://salsa.debian.org/qa/udd/-/blob/master/rimporters/upstream.rb?ref_type=heads
> >
> > Is there a package already in the archive that uses version 5, so I can
> > test that updating devcripts in UDD works?
> >
> > Lucas
>
> Hi,
>
> yes, udd's
On 2025-08-16 22:43:53 -0400 (-0400), Theodore Ts'o wrote:
On Sat, Aug 16, 2025 at 05:53:46PM +, Jeremy Stanley wrote:
I just want to chime in and say that a significant portion of my
workday too is spent doing code review. I do find it relevant
and useful, however I expect if you asked my
On Sun, Aug 17, 2025 at 12:54:14AM -0700, Otto Kekäläinen wrote:
>
> I am in fact mentoring two out of the nine GSoC students we have, plus
> a dozen other new contributors as part of regular mentoring under the
> Debian mentoring umbrella. One of my GSoC students posted a MR to
> update a package
Quoting Otto Kekäläinen (2025-08-17 09:54:14)
> Now I am afraid that if half a dozen senior people in Debian write in
> a negative tone about Merge Requests, new contributors will feel
> unwelcomed, and also people doing Outreachy, GSoC and regular
> mentoring will feel that their volunteer time is
als.
We all know that "Code reivew at a company is very different from code
review for some open source project on a forge." - I don't know if
your intent is to be patronizing, but to me what you write above feels
like that.
In this "debian/watch" thread I aske
On Sat, Aug 16, 2025 at 05:53:46PM +, Jeremy Stanley wrote:
>
> I just want to chime in and say that a significant portion of my workday too
> is spent doing code review. I do find it relevant and useful, however I
> expect if you asked my employer they would not refer to my time as
> inexpens
d problems while searching for a new upstream version:
debian/watch is an obsolete version 1 watch file;
please upgrade to a higher version
(see uscan(1) for details).
So it will be needed to update uscan to manage version-5 packages.
Best regards,
Xavier
NB: old uscan wants "versi
On 2025-08-16 12:42:53 -0700 (-0700), Russ Allbery wrote:
[...]
That said, GitHub at least has gotten a lot better over the years. In
particular, they added incremental reviews (only showing you the bits that
have changed since your previous review), commit-by-commit review (or
maybe that's alway
Hi,
..
> fantastic for fire and forget changes to a bunch of packages. You can just
> make an MR and enable automerge, and not only will you be told if the
Yes, this feature is nice and is enabled by default. If you review a
MR and click "merge" before the CI passed, it will hold merging until
the
This is entirely an aside, so folks following the rest of the thread can
ignore it. I decided to go ahead and send it to debian-devel since it's
the sort of general technical discussion that I personally enjoy reading
here, although apologies if folks consider it noise since it's not really
somethi
Hello,
On Sat 16 Aug 2025 at 09:14am -07, Otto Kekäläinen wrote:
> I earlier also sent you an email with the list of commits missing from
> the changelog, which you then chose not to incorporate into your final
> changelog update
I'm sorry about this mistake. I did not intend to ignore the addi
On 2025-08-15 18:53:38 -0700 (-0700), Russ Allbery wrote:
Otto Kekäläinen writes:
[...]
It is not expensive to do reviews.
[...]
It is *sometimes* not expensive to do reviews. Sometimes it is quite
expensive.
[...]
I just want to chime in and say that a significant portion of my
workday t
Hi,
For the record, devscripts is green again thanks to Yadd's fix about
1h after I my email noting it:
https://salsa.debian.org/debian/devscripts/-/commits/main
> I did in fact look at CI (and also ran autopkgtest and saw a failure).
>
> But I judged that I should upload anyway, given the incons
Am Sat, Aug 16, 2025 at 08:23:29AM +0200 schrieb Yadd:
> Hi Andreas,
>
> done: https://salsa.debian.org/debian/devscripts/-/merge_requests/544
Cool. As I said there: I'm fine with any solution that makes clear we
can't watch anything.
> BTW, the main goal of templates
>Hi!
>
>I would also like to remind people who do not yet have a habit of
>doing it to start checking the Salsa CI status of your package before
>uploading it. It can be seen in Salsa itself, via command-line tools
>and from the UDD and QA dashboards.
>
>***
>debian/wat
On Sat, Aug 16, 2025 at 12:21:10AM -0700, Otto Kekäläinen wrote:
> I would also like to remind people who do not yet have a habit of
> doing it to start checking the Salsa CI status of your package before
> uploading it.
and please also everybody, wash your hands!
SCNR. what a waste of time.
-
Hello,
On Sat 16 Aug 2025 at 12:21am -07, Otto Kekäläinen wrote:
> I would also like to remind people who do not yet have a habit of
> doing it to start checking the Salsa CI status of your package before
> uploading it. It can be seen in Salsa itself, via command-line tools
> and from the UDD an
Hi!
I would also like to remind people who do not yet have a habit of
doing it to start checking the Salsa CI status of your package before
uploading it. It can be seen in Salsa itself, via command-line tools
and from the UDD and QA dashboards.
***
debian/watch thread:
> > Could you pleas
On 8/15/25 23:43, Andreas Tille wrote:
Hi,
Am Thu, Aug 14, 2025 at 01:45:16PM +0200 schrieb Yadd:
On 8/14/25 13:40, Julien Plissonneau Duquène wrote:
Le 2025-08-14 10:25, Xavier a écrit :
What do you think ?
Great work! I love it!
Thank you for this work! It makes watch files much more
On 8/16/25 06:41, Lucas Nussbaum wrote:
On 15/08/25 at 23:53 +0200, gregor herrmann wrote:
On Thu, 14 Aug 2025 10:25:32 +0200, Xavier wrote:
I propose to release it to unstable, then backports. And then we
will be able to push it into debci machines (else tracker will
report errors for all ver
On 15/08/25 at 23:53 +0200, gregor herrmann wrote:
> On Thu, 14 Aug 2025 10:25:32 +0200, Xavier wrote:
>
> > I propose to release it to unstable, then backports. And then we
> > will be able to push it into debci machines (else tracker will
> > report errors for all version-5 files).
> > What do y
Otto Kekäläinen writes:
> It is not expensive to do reviews.
I realize that it's a little difficult to keep all of the various people
straight in these threads, and there are a lot of people weighing in with
a wide variety of backgrounds. Some of them have said that they haven't
used a merge req
Hi,
My original email to this thread said:
> Could you please stop pushing directly on 'main' in
> https://salsa.debian.org/debian/devscripts and instead publish Merge
> Requests?
Your follow-up later was:
> Again, this is the kind of thing that is tedious and annoying and very
> much not fun, an
On Fri, 2025-08-15 at 16:59 +0200, Raphael Hertzog wrote:
> And in GitLab it's called a "namespace" or a "group".
>
> I am also quite skeptic about the choice of "Author" which I find
> confusing. I'm not sure that "Owner" is any better. In the end,
> "Namespace" might be a good term that could be
On Thu, 14 Aug 2025 10:25:32 +0200, Xavier wrote:
I propose to release it to unstable, then backports. And then we
will be able to push it into debci machines (else tracker will
report errors for all version-5 files).
What do you think ?
I think this is great!
Please go ahead and thanks for
Hi,
Am Thu, Aug 14, 2025 at 01:45:16PM +0200 schrieb Yadd:
> On 8/14/25 13:40, Julien Plissonneau Duquène wrote:
> > Le 2025-08-14 10:25, Xavier a écrit :
> > >
> > > What do you think ?
Great work! I love it!
> > Thank you for this work! It mak
On 8/15/25 16:59, Raphael Hertzog wrote:
On Fri, 15 Aug 2025, NoisyCoil wrote:
On 14/08/25 16:56, Ananthu C V wrote:
I haven't checked it in detail either, but I guess having an "Owner" field
would just suit both Author and Organization.
+1 for Owner, Author and Organization don't apply to on
Otto Kekäläinen writes:
> First of all you don't need a MR to trigger CI. You can just push your
> branch and you will get an email if CI failed.
Yes, I know. I was being sloppy by not distinguishing between an MR and a
branch. My point is that I push simple changes directly to main and more
com
Hi,
(I didn't get Russ original email, so mostly replying to it via this)
> Am Thu, Aug 14, 2025 at 12:02:19PM -0700 schrieb Russ Allbery:
> > For the record, I will not use MRs routinely for my own packages. I do not
> > like this workflow for my own changes, and I am going to continue to push
>
On Fri, 15 Aug 2025, NoisyCoil wrote:
> On 14/08/25 16:56, Ananthu C V wrote:
> > I haven't checked it in detail either, but I guess having an "Owner" field
> > would just suit both Author and Organization.
>
> +1 for Owner, Author and Organization don't apply to one another.
And in GitLab it's c
On Fri, Aug 15, 2025 at 12:14:39PM +0200, Andreas Tille wrote:
> While I generally agree it might make sense to suggest a MR based
> workflow for devscripts since it contains quite different things where
> different people are working on. I for myself (as a very rare
> contributor to devscripts) w
Am Thu, Aug 14, 2025 at 12:02:19PM -0700 schrieb Russ Allbery:
>
> For the record, I will not use MRs routinely for my own packages. I do not
> like this workflow for my own changes, and I am going to continue to push
> directly to the primary branch unless I need an MR for some reason (such
> as
Hi,
> > Later a further improvement could be to generate a default configuration
> > from d/upstream/metadata which would probably allow many packages to not
> > need a d/watch anymore.
>
> While I like the idea, isn't d/watch used by Debian tooling to check if
&g
On 14/08/25 13:40, Julien Plissonneau Duquène wrote:
Later a further improvement could be to generate a default configuration
from d/upstream/metadata which would probably allow many packages to not
need a d/watch anymore.
While I like the idea, isn't d/watch used by Debian tooling to
On 14/08/25 16:56, Ananthu C V wrote:
I haven't checked it in detail either, but I guess having an "Owner" field
would just suit both Author and Organization.
+1 for Owner, Author and Organization don't apply to one another.
Cheers!
Hello Otto,
On Thu 14 Aug 2025 at 11:37am -07, Otto Kekäläinen wrote:
> Hi Yadd, Sean and Bas!
>
> Could you please stop pushing directly on 'main' in
> https://salsa.debian.org/debian/devscripts and instead publish Merge
> Requests?
>
> It would help avoid unnecessary mistakes from getting into
On 8/14/25 8:37 PM, Otto Kekäläinen wrote:
Could you please stop pushing directly on 'main' in
https://salsa.debian.org/debian/devscripts and instead publish Merge
Requests?
You'll need to enforce that with Protected branches.
I've committed the trixie changes directly because that's much fast
Otto Kekäläinen writes:
> Could you please stop pushing directly on 'main' in
> https://salsa.debian.org/debian/devscripts and instead publish Merge
> Requests?
I really hope debian-devel is not going to turn into an ongoing discussion
of how the workflows of other maintainers are wrong.
For th
here was 4 commits on the same file within an hour. This
typically don't happen when people prepare their work in a MR and it
gets reviewed & merged only once you are actually done:
± git log --oneline main
* afee2861 Update d/ch 6 hours ago (HEAD -> main, origin/main, origin/HEAD)
* 430
Hi,
On Thu, Aug 14, 2025 at 03:10:49PM +0200, Michael Banck wrote:
> Isn't that usually called an organisation in Github? Sure, for personal
> repos, org == author, but not in general. Or are both supported (I did
> not check, sorry).
I haven't checked it in detail either, but I guess having an "
Hi,
On Thu, Aug 14, 2025 at 10:25:32AM +0200, Xavier wrote:
> uscan with new debian/watch format version 5 is ready (available in
> experimental).
> Of course this version of uscan is still able to read current formats. The
> main changes in version 5 are:
> - rfc822 style (li
Hello,
On Thu 14 Aug 2025 at 01:43pm +02, Yadd wrote:
> Hi Sean,
>
> sure you can, thank you! I kept all version=4 tests to verify that there is no
> regression, so I think everything is OK
>
> Best regards,
> Xavier
Cool, thank you for the feedback.
--
Sean Whitton
signature.asc
Description
On 8/14/25 13:40, Julien Plissonneau Duquène wrote:
Le 2025-08-14 10:25, Xavier a écrit :
What do you think ?
Thank you for this work! It makes watch files much more readable.
Later a further improvement could be to generate a default configuration
from d/upstream/metadata which would
On 8/14/25 12:15, Sean Whitton wrote:
Hello,
On Thu 14 Aug 2025 at 10:25am +02, Xavier wrote:
Hi,
uscan with new debian/watch format version 5 is ready (available in
experimental).
Of course this version of uscan is still able to read current formats. The main
changes in version 5 are
Le 2025-08-14 10:25, Xavier a écrit :
What do you think ?
Thank you for this work! It makes watch files much more readable.
Later a further improvement could be to generate a default configuration
from d/upstream/metadata which would probably allow many packages to not
need a d/watch
Hello,
On Thu 14 Aug 2025 at 10:25am +02, Xavier wrote:
> Hi,
>
> uscan with new debian/watch format version 5 is ready (available in
> experimental).
> Of course this version of uscan is still able to read current formats. The
> main
> changes in version 5 are:
> -
Hi,
uscan with new debian/watch format version 5 is ready (available in
experimental).
Of course this version of uscan is still able to read current formats. The main
changes in version 5 are:
- rfc822 style (like other debian files)
- "templates" that permit to calculate automatical
Description : Watch without distraction
Play your favorite movies and video files without hassle. Showtime features
simple playback controls that fade out of your way when you're watching,
fullscreen, adjustable playback speed, multiple language and subtitle tracks,
and screen
+
Programming Lang: Python
Description : watch for DHCP packets with asyncio
This Python library makes it possible to watch for DHCP packets with asyncio.
Users of this library will simply provide a callback function that this
library will call whenever a DHCP packet is detected.
I intend to
Package: wnpp
Severity: wishlist
Owner: Arthur Diniz
* Package name: watcher
Version : 1.0.7-1
Upstream Author : Benjamin Radovsky
* URL : https://github.com/radovskyb/watcher
* License : BSD-3-clause
Programming Lang: Go
Description : watch for files
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard
X-Debbugs-Cc: debian-devel@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: rust-if-watch
Version : 3.2.0
Upstream Contact: David Craven
* URL : https://github.com/mxinden/if
Programming Lang: Rust
Description : simple tool to watch logfile throughput
Monitor log files for activity and display results via graph or
statistics.
Useful for live comparisson of server access. E.g. cached vs uncached
web access. Results can easily be displayed in a format suitable
ort such an API, and it is appropriate if I only need to detect
whether it is
pre-release or not.
Even though it is not enough to hide API specific internal
such as auto-generated archive or attached assets in d/watch,
it is practically enough because we accept writing site-specific
d/watch as of now [1]
[1] https://wiki.debian.org/debian/watch
Thanks,
--
Kentaro Hayashi
On 2022-12-08 12:59, Kentaro Hayashi wrote:
2022年12月5日(月) 16:41 Stephan Lachnit :
You can try to take a look at the GitHub API, e.g. [1].
Inside is an `prerelease` entry. Not sure how easy this is to
implement in uscan though.
Cheers,
Stephan
[1]: https://api.github.com/repos/lutris/lutris/r
2022年12月5日(月) 16:41 Stephan Lachnit :
>
> You can try to take a look at the GitHub API, e.g. [1].
>
> Inside is an `prerelease` entry. Not sure how easy this is to
> implement in uscan though.
>
> Cheers,
> Stephan
>
> [1]: https://api.github.com/repos/lutris/lutris/releases?per_page=100
Thanks,
I
You can try to take a look at the GitHub API, e.g. [1].
Inside is an `prerelease` entry. Not sure how easy this is to
implement in uscan though.
Cheers,
Stephan
[1]: https://api.github.com/repos/lutris/lutris/releases?per_page=100
Hi,
Recently, I've faced an issue with debian/watch with pre-released version.
Here is the scenario:
1. upstream releases x.y.z with pre-release label. (tagged with x.y.z)
2. new release x.y.z was detected on developer dashboard
(https://qa.debian.org/developer.php)
3. upstream releases
Hello Andreas,
On 2022-09-29 14:54 4, Andreas Tille wrote:
I confirm this works. However, uscan does not do the usual link to
orig.tar.gz. Any idea why this is the case?
I have found this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896705
But did you have signing key from Rob Egan
sidered debian-mentors@l.d.o usually the proper list to find
a solution for problems in watch files I agree that this should be made
public also on debian-devel. It seems quite some packages are affected:
https://codesearch.debian.net/search?q=path%3Adebian%2Fwatch+bitbucket&literal=1
My gue
rnatively, would it be better to set USCAN_SYMLINK in d/watch
(instead of ~/.devscripts)? Thank you!
Kind regards
Felix Lechner
[1]
https://salsa.debian.org/lintian/lintian/-/commit/d336b6f732fb0059a522f19dbd1e322864c821a9
Le 07/11/2021 à 21:37, Felix Lechner a écrit :
> Hi
>
> On Thu, Nov 4, 2021 at 12:48 PM Johannes Schauer Marin Rodrigues
> wrote:
>>
>>> filenamemangle=s/.+\/tag\/(\d\S+)$/foot-$1\.tar\.gz/ \
>> filenamemangle=s{.*/(.*)}{@PACKAGE@-$1.tar.gz} \
>
> mapreri pointed out that 'USCAN_SYMLINK=rename'
On Thu, Nov 4, 2021 at 12:48 PM Johannes Schauer Marin Rodrigues
wrote:
>
>> filenamemangle=s/.+\/tag\/(\d\S+)$/foot-$1\.tar\.gz/ \
> filenamemangle=s{.*/(.*)}{@PACKAGE@-$1.tar.gz} \
I think this is more generic:
filenamemangle=s/.*?(@ANY_VERSION@@ARCHIVE_EXT@)/@PACKAGE@-$1/
(not dependent t
Hi
On Thu, Nov 4, 2021 at 12:48 PM Johannes Schauer Marin Rodrigues
wrote:
>
> > filenamemangle=s/.+\/tag\/(\d\S+)$/foot-$1\.tar\.gz/ \
> filenamemangle=s{.*/(.*)}{@PACKAGE@-$1.tar.gz} \
mapreri pointed out that 'USCAN_SYMLINK=rename' is superior to
'filenamemangle' in both of our cases.
Linti
Quoting Felix Lechner (2021-11-04 20:17:49)
> For anyone having issues with Gitea's new dynamic download links [1] here is
> a debian/watch file that works.
>
> * * *
>
> version=4
> opts=\
> downloadurlmangle=s/\/releases\/tag\/(\d\S+)$/\/archive\/$1\.tar\.gz/,
Hi,
For anyone having issues with Gitea's new dynamic download links [1]
here is a debian/watch file that works.
Kind regards
Felix Lechner
[1] https://github.com/go-gitea/gitea/issues/16354
* * *
version=4
opts=\
downloadurlmangle=s/\/releases\/tag\/(\d\S+)$/\/archive\/$1\.ta
On 23/08/21 at 13:45 +0200, Gard Spreemann wrote:
>
> Mattia Rizzolo writes:
>
> > On Mon, Aug 23, 2021 at 12:59:39PM +0200, Gard Spreemann wrote:
> >> Have the uscan watch file checks that feed qa.debian.org stopped? Is it
> >> on purpose? Perhaps a
Mattia Rizzolo writes:
> On Mon, Aug 23, 2021 at 12:59:39PM +0200, Gard Spreemann wrote:
>> Have the uscan watch file checks that feed qa.debian.org stopped? Is it
>> on purpose? Perhaps a consequence of the recent release?
>
> That's one part that's included in
On Mon, Aug 23, 2021 at 12:59:39PM +0200, Gard Spreemann wrote:
> Have the uscan watch file checks that feed qa.debian.org stopped? Is it
> on purpose? Perhaps a consequence of the recent release?
That's one part that's included in the UDD downtime reported here:
https://
Hi list,
Have the uscan watch file checks that feed qa.debian.org stopped? Is it
on purpose? Perhaps a consequence of the recent release?
Best,
Gard
signature.asc
Description: PGP signature
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
https://wiki.debian.org/
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 before
1 - 100 of 350 matches
Mail list logo
