On 06/02/2022 17:20, Frederik Schwan via arch-dev-public wrote:
On Mon, Jan 31, 2022 at 09:25:41PM +0100, Jelle van der Waa via arch-dev-public
wrote:
We’ve wanted automatic flagging packages out of date for a while and
currently every packager has to come up with it’s own solution. Let’s solve
On 2/6/22 14:25, David Runge via arch-dev-public wrote:
On 2022-01-31 21:25:41 (+0100), Jelle van der Waa via arch-dev-public wrote:
We’ve wanted automatic flagging packages out of date for a while and
currently every packager has to come up with it’s own solution. Let’s
solve this centralized b
On Mon, Jan 31, 2022 at 09:25:41PM +0100, Jelle van der Waa via arch-dev-public
wrote:
> We’ve wanted automatic flagging packages out of date for a while and
> currently every packager has to come up with it’s own solution. Let’s solve
> this centralized by integrating nvchecker into archweb.
>
>
On 2022-01-31 21:25:41 (+0100), Jelle van der Waa via arch-dev-public wrote:
> We’ve wanted automatic flagging packages out of date for a while and
> currently every packager has to come up with it’s own solution. Let’s
> solve this centralized by integrating nvchecker into archweb.
One thing that
On 31.01.22 21:25, Jelle van der Waa via arch-dev-public wrote:
We’ve wanted automatic flagging packages out of date for a while and
currently every packager has to come up with it’s own solution. Let’s
solve this centralized by integrating nvchecker into archweb.
nvchecker is a program whic
On 22-02-02 21:03, Felix Yan via arch-dev-public wrote:
> There is a regex plugin and a htmlparser plugin for this.
>
> The htmlparser plugin accepts XPath, but if you want to process it further
> the regex plugin may just work better.
>
> Examples for your packages:
>
> [html-xml-utils]
> source =
On 3/2/22 03:42, Leonidas Spyropoulos via arch-dev-public wrote:
On 02/02/2022 17:32, Evangelos Foutras via arch-dev-public wrote:
I'm not fond of the hidden all-caps filename for editable sources
(whereas it's fine for .BUILDINFO and friends). More importantly
though, has integration with [1] b
On 2/1/22 22:54, George Rawlinson via arch-dev-public wrote:
On 22-02-01 08:21, Morten Linderud via arch-dev-public wrote:
At this stage, the following [community] packages that I maintain
require massaging of HTML sources:
* html-xml-utils
* oil
* parallel
* libmilter (bundled with sendmail sou
On 2/2/22 19:59, Anatol Pomozov via arch-dev-public wrote:
And here is one more tool to check if package version is of out-of-date
https://github.com/anatol/pkgoutofdate
It is a pretty simple tool that does not require any modification to Arch
repo. It simply tries to guess what is the next poss
Hi
On Wed, Feb 2, 2022 at 9:32 AM Evangelos Foutras via arch-dev-public <
arch-dev-public@lists.archlinux.org> wrote:
> On Mon, 31 Jan 2022 at 22:27, Jelle van der Waa via arch-dev-public
> wrote:
> >
> > The question is if anyone object to checking these small .NVCHECKER
> > files into our svn
On 02/02/2022 17:32, Evangelos Foutras via arch-dev-public wrote:
I'm not fond of the hidden all-caps filename for editable sources
(whereas it's fine for .BUILDINFO and friends). More importantly
though, has integration with [1] been considered? The best way to
implement automatic version checki
On 2/2/22 18:32, Evangelos Foutras via arch-dev-public wrote:
On Mon, 31 Jan 2022 at 22:27, Jelle van der Waa via arch-dev-public
wrote:
The question is if anyone object to checking these small .NVCHECKER
files into our svn repository. If there are no real objections, I'll
start implementing t
On Mon, 31 Jan 2022 at 22:27, Jelle van der Waa via arch-dev-public
wrote:
>
> The question is if anyone object to checking these small .NVCHECKER
> files into our svn repository. If there are no real objections, I'll
> start implementing this functionality into archweb in two weeks.
I'm not fond
On 01/02/2022 21:54, George Rawlinson via arch-dev-public wrote:
On 22-02-01 08:21, Morten Linderud via arch-dev-public wrote:
These require running arbitrary scripts on archweb so they should probably
remain
unsupported. Is there no better options?
At this stage, the following [community] pa
On 22-02-01 08:21, Morten Linderud via arch-dev-public wrote:
> These require running arbitrary scripts on archweb so they should probably
> remain
> unsupported. Is there no better options?
At this stage, the following [community] packages that I maintain
require massaging of HTML sources:
* ht
On Tue, Feb 01, 2022 at 03:55:44AM +, George Rawlinson via arch-dev-public
wrote:
>
> I have no objections to this, and happily support this endeavour.
>
> However, I currently track 8 packages via shell scripts (available via
> nvchecker's "cmd" source), all found here[0].
>
> Some of them
On 22-01-31 21:25, Jelle van der Waa via arch-dev-public wrote:
> We’ve wanted automatic flagging packages out of date for a while and
> currently every packager has to come up with it’s own solution. Let’s solve
> this centralized by integrating nvchecker into archweb.
>
> nvchecker is a program w
17 matches
Mail list logo