Bug#1094168: ITP: showtime -- Watch without distraction

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

Bug#1077382: ITP: python-aiodhcpwatcher -- watch for DHCP packets with asyncio

+ 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

Bug#1067390: ITP: watcher -- watch for files or directory changes without using filesystem events

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

Bug#1059905: ITP: rust-if-watch -- asynchronous network watcher

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

Bug#1039943: ITP: linescroll -- simple tool to watch logfile throughput

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

Re: debian/watch: Ignoring pre-release on GittHub

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

Re: debian/watch: Ignoring pre-release on GittHub

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

Re: debian/watch: Ignoring pre-release on GittHub

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

Re: debian/watch: Ignoring pre-release on GittHub

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

debian/watch: Ignoring pre-release on GittHub

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

Re: Help needed for watch file after bitbucket changed download page

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

Bitbucket changed download page - possibly lots of watch files affected (Was: Help needed for watch file after bitbucket changed download page)

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

Re: d/watch for Gitea's new dynamic pages

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

Re: d/watch for Gitea's new dynamic pages

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'

Re: d/watch for Gitea's new dynamic pages

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

Re: d/watch for Gitea's new dynamic pages

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

Re: d/watch for Gitea's new dynamic pages

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/,

d/watch for Gitea's new dynamic pages

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

Re: Have the watch file checks stopped?

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

Re: Have the watch file checks stopped?

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

Re: Have the watch file checks stopped?

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://

Have the watch file checks stopped?

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

Re: Changed Github download URLs are affecting lots of existing watch files

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

Re: Changed Github download URLs are affecting lots of existing watch files

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/

Re: Changed Github download URLs are affecting lots of existing watch files

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

Re: Changed Github download URLs are affecting lots of existing watch files

de 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 are newer than the package. That would be extremely helpful. > Some additional points for the thread in general: > > I wou

Re: Changed Github download URLs are affecting lots of existing watch files

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: https://janitor.debian.net

Re: Changed Github download URLs are affecting lots of existing watch files

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 f

Re: Changed Github download URLs are affecting lots of existing watch files

//qa.debian.org/cgi-bin/fakeupstream.cgi https://salsa.debian.org/qa/qa/-/blob/master/cgi-bin/fakeupstream.cgi > This got me thinking: the version checking mechanism of d/watch files is > useless if the outside world changes, i.e. if upstream's URLs > change. Why do we then ship this

Re: Changed Github download URLs are affecting lots of existing watch files

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 version

Re: Changed Github download URLs are affecting lots of existing watch files

s obtained from > Github right after the release)? > This was reported as #985633 A fixer for this issue was added to lintian-brush already (version 0.101, fixer debian-watch-file-uses-old-github-pattern). That said, I agree that needing to update and re-upload every package isn't a great

Re: Changed Github download URLs are affecting lots of existing watch files

b changes > > > its website, only uscan should be updated. > > > > Yes. Or maintain watch files outside the packages. > > Fine for me - but what is our QA tool chain using. As far as I know > tracker.d.o and other tools are relying on UDD and the information is >

Re: Changed Github download URLs are affecting lots of existing watch files

hub right after the release)? > > > > This breaks also more than thousand package from JS Team. > > > > We could perhaps handle that with uscan then each time GitHub changes > > its website, only uscan should be updated. > > Yes. Or maintain watch files outside the packag

Re: Changed Github download URLs are affecting lots of existing watch files

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 chang

Re: Changed Github download URLs are affecting lots of existing watch files

te. > > Any idea what to do (besides uploading all packages obtained from > > Github right after the release)? You could make a lintian-brush filter to make Janitor prepare the change for you on next upload. In the meantime, I don't think there's a better way of tracking chan

Re: Changed Github download URLs are affecting lots of existing watch files

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 > >https://github.com/#GITHUBUSER#/#PACKAGE#/releases/lat

Re: Changed Github download URLs are affecting lots of existing watch files

ases (which may or > may not be what you want). Well, my point was not to discuss possible enhancements of the watch file string but rather how to sensibly solve the issue that those strings that used to work at least until last month now have stopped working due to the change at Github. Thank you for your comments anyway Andreas. -- http://fam-tille.de

Re: Changed Github download URLs are affecting lots of existing watch files

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

Changed Github download URLs are affecting lots of existing watch files

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) si

Re: uscan/watch regexp and multiple versions

Hi Alastair, Le 16/01/2021 à 08:02, Alastair McKinstry a écrit : Some of the stack(s) i'm watching have versions, eg. "3.4.1" but also bundled version numbers "2020.10.1" that I wish to ignore; Why not use a regex that matches the first one but not the last one, maybe something like .*/v?(\d

uscan/watch regexp and multiple versions

Hi, I'm adding watch files for projects, and have a problem with multiple version number epochs in a github release. Some of the stack(s) i'm watching have versions, eg. "3.4.1" but also bundled version numbers "2020.10.1" that I wish to ignore; Is there any e

Re: Bug#973637: flag debian/watch files that use older versions of the format

On Mon, Nov 02, 2020 at 10:54:11PM +0100, Xavier wrote: > But version 2 is really deprecated and it's > not easy to maintain uscan with 4 versions (It took me a lot of hours to > rewrite old uscan to modern Perl-OO). > That's why I'd like to see a "error" tag for version ≤ 2. Right, but currently

Re: Bug#973637: flag debian/watch files that use older versions of the format

> Hi Jelmer > > On Mon, Nov 2, 2020 at 9:57 AM Jelmer Vernooij > wrote: > > > > It would be great if lintian could flag debian/watch files that > > didn't use a watch file format version or use an older version > > (< 4). > > Can you just use t

Re: watch files and .gitattributes export-ignore

Here's the result of my research: uscan does support git clone. But it won't ignore the .gitattributes file. I opened https://bugs.debian.org/947317 I went for an ugly README.source using "git deborig" for now. Thank you everyone for the help! signature.asc Description: This is a digitally sign

Re: watch files and .gitattributes export-ignore

Hello Jean-Michel, On Thu 12 Dec 2019 at 09:48AM +01, Jean-Michel Vourgère wrote: > Upstream of phppgadmin has nice unit tests in its github.com repository, but > they use a .gitattributes file [1] to strip these tests files from the > distributed tar files: All the unit tests are missing from th

Re: watch files and .gitattributes export-ignore

On 12/12/19 2:48 AM, Jean-Michel Vourgère wrote: > Upstream of phppgadmin has nice unit tests in its github.com repository, but > they use a .gitattributes file [1] to strip these tests files from the > distributed tar files: All the unit tests are missing from the orig.tar. Have you asked upstr

Re: watch files and .gitattributes export-ignore

On 12/12/19 3:48 AM, Jean-Michel Vourgère wrote: > Hello > > Upstream of phppgadmin has nice unit tests in its github.com repository, but > they use a .gitattributes file [1] to strip these tests files from the > distributed tar files: All the unit tests are missing from the orig.tar. > > I won

Re: watch files and .gitattributes export-ignore

Hi Jean-Michel, On 2019-12-12 10:48, Jean-Michel Vourgère wrote: > Ideally, I'd like to generate the orig.tar from a "git clone". But uscan > don't > support that. Do you mean uscan's 'mode=git' does honor .gitattributes? I wasn't aware of that. Best, Andrius signature.asc Description: Ope

watch files and .gitattributes export-ignore

ules. I guess I'll go for a manual build of the orig.tar, with a d/README.source. Or a script. Any better idea? To make things worse, I think I'll keep the d/watch file so I get warning when upstream releases a new version. But that's pretty bad because then one has to be

Re: A problem with a watch file

Hi, On 18-10-17 15:11:00, Tommi Höynälänmaa wrote: > I have installed the key to both debian/upstream/signing-key.pgp and > debian/upstream/signing-key.asc. It still doesn't work. Run uscan with increased verbosity (-v), it might give you a hint what is going wrong. Cheers, Georg signature.asc

Re: A problem with a watch file

On 16.10.2018 15:40, Xavier wrote: Hello, you must install upstream key in debian/upstream/signing-key.asc: uscan should verify key with its own keystore, not yours. Cheers, Xavier I have installed the key to both debian/upstream/signing-key.pgp and debian/upstream/signing-key.asc. It stil

Re: A problem with a watch file

ot;gpg --verify" works fine. Hello, you must install upstream key in debian/upstream/signing-key.asc: uscan should verify key with its own keystore, not yours. Cheers, Xavier > The contents of the watch file are: > ---cut here--- > version=4 > opts="pgpsigurlmangle=s/$/.s

Re: A problem with a watch file

Hi Tommi, > gpgv: Can't check signature: No public key You can find the steps to retrieve and store the key here: https://wiki.debian.org/debian/watch#Cryptographic_signature_verification Regards Fritz signature.asc Description: PGP signature

Re: A problem with a watch file

o public key uscan warn: OpenPGP signature did not verify. ---cut here--- Checking the signature with "gpg --verify" works fine. The contents of the watch file are: ---cut here--- version=4 opts="pgpsigurlmangle=s/$/.sig/" http://localhost/theme-d-gnome.html theme-d-gnome-

Re: A problem with a watch file

Hi, Might be you should rename the signature having .asc suffix instead of .sig Bye, Joël On Sat, Oct 13, 2018 at 2:33 PM Adam D. Barratt wrote: > > On Sat, 2018-10-13 at 15:23 +0300, Tommi Höynälänmaa wrote: > > Hi > > > > > > On 12.10.2018 04:40, Sergio Durigan Junior wrote: > > > 2) Upstream

Re: A problem with a watch file

On Sat, 2018-10-13 at 15:23 +0300, Tommi Höynälänmaa wrote: > Hi > > > On 12.10.2018 04:40, Sergio Durigan Junior wrote: > > 2) Upstream uses "_" as the "NAME_VERSION" separator (instead of > > "NAME-VERSION").  Your regex doesn't match that.  Also, you have to > > be > > careful because upstream

Re: A problem with a watch file

Hi On 12.10.2018 04:40, Sergio Durigan Junior wrote: Complementing what Jonas said, you have a few more errors: 1) The "theme-d-gnome*" packages are not listed in . Instead, they're at . URL www.iki.fi/tohoyn

Re: A problem with a watch file

On Thursday, October 11 2018, Tommi Höynälänmaa wrote: > Hi > > What is wrong with the following watch file: > > ---cut-here--- > > version=4 > pgpsigurlmangle=s/$/.sig/ http://www.iki.fi/tohoyn/theme-d/ > theme-d-gnome-(\d[\d.]*)\.tar\.(?:gz|bz2|xz) > > ---cut-h

Re: A problem with a watch file

Hi Tommi, [cc'ing you discretely - please subscribe to the list if you haven't] Quoting Tommi Höynälänmaa (2018-10-11 14:13:19) > Hi > > What is wrong with the following watch file: > > ---cut-here--- > > > ---cut-here--- > > It gives the following er

A problem with a watch file

Hi What is wrong with the following watch file: ---cut-here--- version=4 pgpsigurlmangle=s/$/.sig/ http://www.iki.fi/tohoyn/theme-d/ theme-d-gnome-(\d[\d.]*)\.tar\.(?:gz|bz2|xz) ---cut-here--- It gives the following error message with uscan: ---cut-here--- uscan warn: Filename pattern

Re: debian/watch for bintray ?

On Wed, May 30, 2018 at 11:17 AM, Dirk Eddelbuettel wrote: > Oh, nice! With one of those sed expressions in the watch file you mean? Yeah, there are some examples in the codesearch link above: opts=downloadurlmangle=s/://,filenamemangle=s/:// https://codesearch.debian.net/search?q=p

Re: debian/watch for bintray ?

you remove the : character from the | download URLs, then you can get tarballs. Oh, nice! With one of those sed expressions in the watch file you mean? | BTW, you might want to let them know that the packages.d.o link there | is obsolete: | | You reached this site over an old URL. Depending on

Re: debian/watch for bintray ?

On Sat, May 26, 2018 at 10:50 AM, Dirk Eddelbuettel wrote: >https://www.quantlib.org/download.shtml The bintray URL there eventually points here: https://dl.bintray.com/quantlib/releases/ That has all the versions and if you remove the : character from the download URLs, then you can get ta

Re: debian/watch for bintray ?

On 26 May 2018 at 10:42, Paul Wise wrote: | On Sat, May 26, 2018 at 10:31 AM, Dirk Eddelbuettel wrote: | | > Quantlib. | > upstream web https://www.quantlib.org/ | > upstream src https://github.com/lballabio/QuantLib | > my srchttps://salsa.debian.org/edd/quantlib | | Can't you u

Re: debian/watch for bintray ?

On Sat, May 26, 2018 at 10:31 AM, Dirk Eddelbuettel wrote: > Quantlib. > upstream web https://www.quantlib.org/ > upstream src https://github.com/lballabio/QuantLib > my srchttps://salsa.debian.org/edd/quantlib Can't you use the github releases? https://github.com/lballabio/Quant

Re: debian/watch for bintray ?

tps://github.com/lballabio/QuantLib my srchttps://salsa.debian.org/edd/quantlib Most recent release (which I hand-downloaded) https://bintray.com/quantlib/releases/QuantLib/1.13 My not-working (and hence renamed) watch file https://salsa.debian.org/edd/quantlib/blob/master/deb

Re: debian/watch for bintray ?

On Sat, May 26, 2018 at 5:23 AM, Dirk Eddelbuettel wrote: > An upstream package I look after switched from sf.net to bintray. Which upstream? Please link to bintray. > Do we have a trick to parse layout via uscan? Looks like only minor tricks are needed: https://codesearch.debian.net/search?q=

debian/watch for bintray ?

An upstream package I look after switched from sf.net to bintray. Do we have a trick to parse layout via uscan? Please CC me as I am no longer subscribed to debian-devel. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Help with watch file

lace[0] function makes no > > assumptions about what the separator is. > > > > [0]: > > https://anonscm.debian.org/cgit/collab-maint/devscripts.git/tree/scripts/uscan.pl?id=bce34b8d7fa410e64c411bd780f8e21603167ae7#n4441 > > Indeed. There was a fair amount of time spe

Re: Help with watch file

maint/devscripts.git/tree/scripts/uscan.pl?id=bce34b8d7fa410e64c411bd780f8e21603167ae7#n4441 Indeed. There was a fair amount of time spent during the development of that code to support as many native Perl features as were reasonable and actually used in watch files at the time (hence the \l etc support). Regards, Adam

Re: Help with watch file

On Thu, Dec 22, 2016 at 05:42:43PM -0500, Bill Blough wrote: > On Thu, Dec 22, 2016 at 12:40:26PM +, Ian Jackson wrote: > > suffers rather from leaning toothpick syndrome. Does the > > `downloadurlmangle' support Perl's ability to handle nonstandard > > delimiters ? Using something other than

Re: Help with watch file

On Thu, Dec 22, 2016 at 12:40:26PM +, Ian Jackson wrote: > suffers rather from leaning toothpick syndrome. Does the > `downloadurlmangle' support Perl's ability to handle nonstandard > delimiters ? Using something other than / means that / does not need > to be \-escaped. { } are often a goo

Re: Help with watch file

Bill Blough writes ("Re: Help with watch file"): > You want the downloadurlmangle option. This > opts=downloadurlmangle=s/github\.com\/arrayfire\/arrayfire\/archive\/v?(\d[\d\.]*)\.tar\.gz/arrayfire.com\/arrayfire_source\/arrayfire-full-$1\.tar\.bz2/ > \ > http://github.c

Re: Help with watch file

On Wed, Dec 21, 2016 at 09:33:29PM +, Ghislain Vaillant wrote: > Dear all, > > I am trying to write a watch file suitable for fetching tarballs from a > *link* published on a GitHub release page [1]. It seems this link > points to a different location on Amazon S3 [2].

Re: Help with watch file

On Thu, Dec 22, 2016 at 5:33 AM, Ghislain Vaillant wrote: > I am trying to write a watch file suitable for fetching tarballs from a > *link* published on a GitHub release page [1]. It seems this link > points to a different location on Amazon S3 [2]. For the arrayfire-full tarballs:

Help with watch file

Dear all, I am trying to write a watch file suitable for fetching tarballs from a *link* published on a GitHub release page [1]. It seems this link points to a different location on Amazon S3 [2]. [1] https://github.com/arrayfire/arrayfire/releases [2] http://arrayfire.s3.amazonaws.com

Re: how PTS tracks new upstream versions using debian/watch ?

On Wed, Sep 16, 2015 at 9:54 PM, Jérémy Lal wrote: > how PTS tracks new upstream versions using debian/watch ? The PTS doesn't do that, it just downloads the data from the QA service: https://anonscm.debian.org/viewvc/qa/trunk/pts/www/bin/update_incoming.sh?view=markup#l1

how PTS tracks new upstream versions using debian/watch ?

? no, that would be crazy Is the optional command in debian/watch line run by the PTS tracker ? no, too dangerous security-wise, but i had to ask Jérémy.

Re: Issue with PTS watch file service

leading to more workarounds needing to be added. I did a bunch of that for the easy stuff on qa.d.o and the PTS already. People who know about watch stuff and could probably fix this are Bart Martens and or UDD and or Mole people. https://wiki.debian.org/ServicesSSL -- bye, pabs https://wiki.debian.org/P

Re: Issue with PTS watch file service

Hi Daniel, On Fri, Jun 05, 2015 at 01:24:14PM +0200, Daniel Leidert wrote: > Hi, > > Is it possible, that the watch file service of our PTS has some issue > atm? The PTS spuriously reports "temporary or permanent problems" for > some projects, although the watch files lo

Issue with PTS watch file service

Hi, Is it possible, that the watch file service of our PTS has some issue atm? The PTS spuriously reports "temporary or permanent problems" for some projects, although the watch files look perfectly ok to me and uscan does work as expected. Some examples: https://packages.qa.de

Bug#770047: ITP: xul-ext-video-without-flash -- extension to watch videos without the flash plugin

-without-flash License: GPL-3+ Description: extension to watch videos without the flash plugin Fetch video source of flash based media and play the video directly with Iceweasel (a.k.a. Firefox), without the use of the flash plug-in. Supported sites/embed video players: * Youtube

Re: debian/watch problem

On Fri, Jun 13, 2014 at 12:50 PM, Eugene Zhukov wrote: > Hello, > > I'm struggling to get debian/watch working for the package jing-trang. > The problem is upstream says Google no longer allows publishing > tarballs under [0]. So they only have tag for the latest release [1].

Re: debian/watch problem

On 13/06/14 11:50, Eugene Zhukov wrote: > I'm struggling to get debian/watch working for the package jing-trang. > The problem is upstream says Google no longer allows publishing > tarballs under [0]. We are having the same problem with the abcde package, our solution has been to

debian/watch problem

Hello, I'm struggling to get debian/watch working for the package jing-trang. The problem is upstream says Google no longer allows publishing tarballs under [0]. So they only have tag for the latest release [1]. My question is, is it possible to write a d/watch file for that? [0]

Bug#672506: ITP: ruby-directory-watcher -- Watch directory/files and Generate events by file change

Package: wnpp Owner: Youhei SASAKI Severity: wishlist * Package name: ruby-directory-watcher Version : 1.4.1 Upstream Author : Tim Pease * URL or Web page : http://gemcutter.org/gems/directory_watcher * License : Expat Description : Watch directory/files and

Re: A DM/DD should know how to watch his mouth (code of conduct).

On 03/05/2012 06:27 AM, Gergely Nagy wrote: > Perhaps a few strongers words were used than neccessary, but > honestly "crap" is not a word one should be afraid to see. > And IMO, it's Fabian's right to say that VLC package from d-m.o is "crappy", because introducing an epoc, which messes with hi

Re: A DM/DD should know how to watch his mouth (code of conduct).

Hi Sergio, On So, 04 Mär 2012, Sergio Cipolla wrote: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660814 the Debian > Multimedia maintainer Fabian Greffrath was very wrong, by being not You call "crappy" a strong word? I propose that you watch a bit of TV or read news pa

Re: A DM/DD should know how to watch his mouth (code of conduct).

Daniel Baumann writes: > On 03/04/2012 11:05 PM, Fernando Lemos wrote: >> Fabian's language in those bug reports isn't uncommon in the free >> software community, deal with it. > apart from the fact that Fabian is factually right.. > just because someone is offended (Fabian, by the initial bug

Re: A DM/DD should know how to watch his mouth (code of conduct).

On 03/04/2012 11:05 PM, Fernando Lemos wrote: > Fabian's language in those bug reports isn't uncommon in > the free software community, deal with it. apart from the fact that Fabian is factually right.. just because someone is offended (Fabian, by the initial bug reporter going mental) doesn't ma

Re: A DM/DD should know how to watch his mouth (code of conduct).

Sergio Cipolla writes: > I'm not sure if you're a Debian Maintainer or not (or worse, Debian > Developer) but this kind of big mouthing shouldn't be accepted from a > DM/DD. I don't see a problem. Someone has a strong opinon, and perhaps the way it came across was a bit harsh, but I don't believ

Re: A DM/DD should know how to watch his mouth (code of conduct).

On 2012-03-04, Sergio Cipolla wrote: > "Fabian, who do you think you are to call d-m-o's packages as 'crappy'? > d-m-o is a traditional and very respected 3rd party repository for > Debian and has been for years. It's not. It's neither traditional nor very respected. At least not in the develop

Re: A DM/DD should know how to watch his mouth (code of conduct).

"Thomas Preud'homme" writes: > Le dimanche 4 mars 2012 22:55:46, Russ Allbery a écrit : >> Er... the first person to use the word "crappy" in that entire bug >> discussion is, um, you. Usually when you put quote marks around things >> that's supposed to indicate that it's a quote. > You probabl

Re: A DM/DD should know how to watch his mouth (code of conduct).

Hi, On Sun, Mar 4, 2012 at 6:28 PM, Sergio Cipolla wrote: > Hello. > I'm just a Debian user for some years and I'm writing to this list > because I found that at > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660814 the Debian > Multimedia maintainer Fabian Greffrath was very wrong, by being

Re: A DM/DD should know how to watch his mouth (code of conduct).

Le dimanche 4 mars 2012 22:55:46, Russ Allbery a écrit : > Sergio Cipolla writes: > > I'm just a Debian user for some years and I'm writing to this list > > because I found that at > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660814 the Debian > > Multimedia maintainer Fabian Greffrath was

Re: A DM/DD should know how to watch his mouth (code of conduct).

Sergio Cipolla writes: > I'm just a Debian user for some years and I'm writing to this list > because I found that at > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660814 the Debian > Multimedia maintainer Fabian Greffrath was very wrong, by being not > only wrong in what he said but also ve

A DM/DD should know how to watch his mouth (code of conduct).

Hello. I'm just a Debian user for some years and I'm writing to this list because I found that at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660814 the Debian Multimedia maintainer Fabian Greffrath was very wrong, by being not only wrong in what he said but also very impolite. I wrote to a fo

Re: uscan, watch files, and gihub tags

Hi Paul, Am Tue, 20 Dec 2011 09:12:13 +0800 schrieb Paul Wise : > On Tue, Dec 20, 2011 at 5:24 AM, Andreas Rütten wrote: > > > I assume the "tags as .tar.gz" feature is something special from > > github. Or could I use also tags from e.g. git.debian.de in a > > watchfile? > > git.debian.de doe

Re: uscan, watch files, and gihub tags

On Tue, Dec 20, 2011 at 5:24 AM, Andreas Rütten wrote: > I assume the "tags as .tar.gz" feature is something special from > github. Or could I use also tags from e.g. git.debian.de in a watchfile? git.debian.de doesn't exist so that would not work. As for non-github sites, gitweb doesn't appear

Re: uscan, watch files, and gihub tags

Am Mon, 19 Dec 2011 20:02:57 +0800 schrieb Thomas Goirand : > On 12/19/2011 03:15 PM, Thomas Goirand wrote: > > I tried to poke with opts="uversionmangle=s/^master\///" to remove > > "master/" from the version of upstream git repo, but no luck... > > > Seems this works for me now: > > version=

  1   2   3   >