On 2022-06-06 01:57, zimoun wrote:
> Hi,
>
> On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès wrote:
>
>> guix time-machine --branch=staging -- …
>>
>> Remaining things to check:
>>
>> - [ ] system tests
>> - [ ] status on non-x86_64 architectures
>
> I agree. To me, it is part of the same
Hello Ricardo,
I would suggest to extend a bit the scope of this idea. What about
creating an etc/tutors.scm file as the one attached.
This way people would run something like:
--8<---cut here---start->8---
git send-email $(get-tutors.scm HEAD^^) *.patches
--
Hi,
On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès wrote:
> guix time-machine --branch=staging -- …
>
> Remaining things to check:
>
> - [ ] system tests
> - [ ] status on non-x86_64 architectures
I agree. To me, it is part of the same effort. From my point of view,
we missed the window
Per https://ci.guix.gnu.org/eval/364633?status=pending , there are ~5k
scheduled jobs, all aarch64-linux.
Per https://ci.guix.gnu.org/workers, all workers report being idle.
Thus, it looks like the aarch64 builders have stalled.
Hi Simon and developers,
what about a flag - e.g. --backup - and a related funcion for "guix
package -d generations" and "guix gc -d generations" (other?) that saves
"channels-generation-.scm" and "manifest-generation- for each
deleted generation?
This way we can keep the current deletion of gene
FWIW,
I just want to commend whoever is packaging TexLive.
My last update covered March of this year - no mean feat given that it
is a 3.4GB package aggregate.
(sorry I cant do more direct contributions for Guix atm, looking forward
to such an honour eventually)
On 04-06-2022 14:07, Ricard
Hi Ricardo,
On Sat, 04 Jun 2022 at 13:00, Ricardo Wurmus wrote:
> This is now implemented in mumi.
Really cool! Thank you!
The bridge between tools becomes easier. For instance, I use the Emacs
frontend of Notmuch where ’cI’ allow to stash the Message-ID, then I can
directly paste it for ref
If we make a team per build system, I'd be in ant, maven, ocaml and dune :)
I think there was also interest in formal methods, it could be a team.
On June 5, 2022 11:51:20 AM GMT+02:00, zimoun wrote:
>Hi Ricardo,
>
>On Sat, 04 Jun 2022 at 14:07, Ricardo Wurmus wrote:
>
>> As a first step I’d su
Hi Ricardo,
On Sat, 04 Jun 2022 at 14:07, Ricardo Wurmus wrote:
> As a first step I’d suggest collecting teams, setting up the email
> aliases, and updating the website to show the existing teams. Here’s
> a draft of three teams:
Well, a team per build system would fit more or less the needs,
Hi,
On Sat, 04 Jun 2022 at 09:39, Giovanni Biscuolo wrote:
> IMHO all users must understand that for
> their projects (profiles) to be reproducible and versioned the /only/
> way is to keep channels.scm and manifests.scm in a VCS (i.e. git)
I agree. This pract
Hello,
Am Sat, Jun 04, 2022 at 02:07:15PM +0200 schrieb Ricardo Wurmus:
> As a first step I’d suggest collecting teams, setting up the email
> aliases, and updating the website to show the existing teams. Here’s
> a draft of three teams:
if something like this makes sense, I would be interested
Hi Ricardo,
> As a first step I’d suggest collecting teams, setting up the email
> aliases, and updating the website to show the existing teams. Here’s
> a draft of three teams:
* Python Team
Lars-Dominik Braun
* Haskell Team
Lars-Dominik Braun
Anyone interested to join these with me?
Cheers,
On Sat, Jun 04, 2022 at 02:50:49PM +, Tobias Geerinckx-Rice wrote:
> I think we should also have (natural) language 'teams' who can be
> pinged when, e.g., a news item lands, through a single
> guix-translators@ meta-alias, and who can co-ordinate before
> releases.
If we do so, please add me
Hello everyone,
Ricardo Wurmus writes:
> As a first step I’d suggest collecting teams, setting up the email
> aliases, and updating the website to show the existing teams.
I think an installer team would be good too (which I would gladly join).
WDYT of the following teams:
* Installer (which I'
14 matches
Mail list logo
