Re: Automatically testing package updates

Hi, Sharlatan Hellseher skribis: > I try to keep cadence with update in astronomy module monthly and having > ongoing refresh work for golang collection. Maybe we may have some API > output on that type available at , > showing the impact ration of the given packa

Re: Automatically testing package updates

Vagrant Cascadian skribis: > This can be fixed by updating to guile-ssh 0.18.0: > > https://issues.guix.gnu.org/74659 > > Which also works with libssh 0.10.x in guix master. > > Running "guix build --dependents guile-ssh" on it now. Yay, well done! :-) > First thing I notice is it is trying t

Re: Automatically testing package updates

Ricardo Wurmus skribis: > Attila Lendvai writes: > >> sidenote: as a newcomer i found it rather off-putting that the bug >> tracker is full of random two-liner package updates, many long >> forgotten and even obsolete. > > This is exactly my point and why I think the bug tracker must contain > o

Re: Automatically testing package updates

Attila Lendvai writes: > what other data would you miss that is not available in the git log? No data that is currently being automatically generated. Then again, none of the patches at present are. One can argue (and perhaps that's what you are) that, even in the future, whatever automated-co

Re: Automatically testing package updates

Suhail Singh writes: > If we do decide to keep bots in a separate realm as it were, it would be > desirable (and in my opinion, important) if that still allowed for at > least as much transparency that the issue tracker provides for human > activities. Examples are the guix-cran and guix-bioc ch

Re: Automatically testing package updates

Attila Lendvai writes: > sidenote: as a newcomer i found it rather off-putting that the bug > tracker is full of random two-liner package updates, many long > forgotten and even obsolete. This is exactly my point and why I think the bug tracker must contain only *actionable* work that humans are

Re: Automatically testing package updates

> If we do decide to keep bots in a separate realm as it were, it would be > desirable (and in my opinion, important) if that still allowed for at > least as much transparency that the issue tracker provides for human > activities. what other data would you miss that is not available in the git l

Re: Automatically testing package updates

Suhail Singh writes: > Efraim Flashner writes: > >> Also I don't think we should spam the bug tracker with package upgrades, >> so we'd have to think about something for that. > > Could you clarify what you're objecting to? Is it bug issues being > created that are then not (as is currently the

Re: Automatically testing package updates

Efraim Flashner writes: > Also I don't think we should spam the bug tracker with package upgrades, > so we'd have to think about something for that. Could you clarify what you're objecting to? Is it bug issues being created that are then not (as is currently the case) automatically closed? Or

Re: Automatically testing package updates

Hilton Chain writes: > On Thu, 05 Dec 2024 15:20:53 +0800, > Efraim Flashner wrote: >> >> I'm now thinking about the easy-package -> hard-package learning curve >> for new contributors, and I'm not sure how we'd address that. > > I'm thinking about something like a wiki of packaging examples, whe

Re: Automatically testing package updates

Hi, On Thu, 05 Dec 2024 15:20:53 +0800, Efraim Flashner wrote: > > I'm now thinking about the easy-package -> hard-package learning curve > for new contributors, and I'm not sure how we'd address that. I'm thinking about something like a wiki of packaging examples, where it starts from a 'hello'

Re: Automatically testing package updates

On Mon, Dec 02, 2024 at 08:14:04PM +0100, Simon Tournier wrote: > Hi, > > On Mon, 02 Dec 2024 at 14:44, Ludovic Courtès wrote: > > > This manifest is just an example. We could come up with manifests > > targeting package collections like CRAN packages, astronomy packages, > > and so on. > > Le

Re: Re: Automatically testing package updates

Hi, That option I've been dreaming about for a long time! I try to keep cadence with update in astronomy module monthly and having ongoing refresh work for golang collection. Maybe we may have some API output on that type available at , showing the impact ration o

Re: Automatically testing package updates

On 2024-12-02, Ludovic Courtès wrote: > A new patch series that has just landed¹ adds a ‘--dependents’ flag (and > also ‘--development’) to ‘guix build’, which makes it easier to build > dependents when modifying a package. Yay! > Some examples: > > • guile-ssh fails to build with the latest li

Re: Automatically testing package updates

Manifest attached. :-) (use-modules (gnu packages) (guix build-system gnu) (guix build-system cmake) (guix packages) (guix sets) (ice-9 match) (ice-9 vlist) (srfi srfi-1)) (define all (all-packages)) (defi

Re: Automatically testing package updates

Hi, On Mon, 02 Dec 2024 at 14:44, Ludovic Courtès wrote: > This manifest is just an example. We could come up with manifests > targeting package collections like CRAN packages, astronomy packages, > and so on. Let consider that a “leaf” package is a package that does not appear elsewhere in an

Re: Automatically testing package updates

Hi, That’s cool! Here, I share a “random thought”. :-) > This manifest is just an example. We could come up with manifests > targeting package collections like CRAN packages, astronomy packages, > and so on. Discussing on Mastodon, Konrad emitted this idea [1]: Just an idea from someo