Christina O'Donnell writes:
> On 08/05/2024 14:01, Christopher Baines wrote:
>> I think it would be nice to have a new release, and indeed release more
>> often, I think the way to get there is for less things to be broken
>> between releases, such that releasing takes
Ricardo Wurmus writes:
>> These changes from r-updates have effectively jumped the queue past
>> those on the core-updates and gnome-team branches, and since there was
>> never a "Request for merging" issue opened [1], the bordeaux build farm
>> is going to be delayed in building gnome-team as
guix-comm...@gnu.org writes:
> rekado pushed a change to branch master
> in repository guix.
>
> from 2bea3f2562 gnu: kubo: Unbundle go-cidutil, go-log and go-ipfs-util.
> new 79c2b32337 gnu: r-with-tests: Update to 4.4.0.
...
> new 5ad635ec49 gnu: r-job: Update to 0.3.1.
>
Simon Tournier writes:
> Here or there, we have bugs as:
>
> https://issues.guix.gnu.org/70659
> https://issues.guix.gnu.org/70726
>
> And our answer looks like:
>
> > Additionally, I strongly advise upgrading guix-daemon, as noted in
> the
> > bug report above.
>
>
Efraim Flashner writes:
> On Mon, Apr 29, 2024 at 04:52:29PM +0200, Ricardo Wurmus wrote:
>> Hi Guix,
>>
>> for the past weeks the "master" branch has been in pretty poor state
>> according to ci.guix.gnu.org. It keeps hovering at around 56% progress,
>> which is a far cry from the 80+% we
Andreas Enge writes:
> Hello,
>
> Am Wed, Apr 24, 2024 at 02:21:56PM +0100 schrieb Christopher Baines:
>> Let me know if you have any thoughts or questions!
>
> in this part:
> +@item
> +Minimise the changes on master that are missing on the branch prior to
> +m
Steve George writes:
> I think we should strongly recommend against long-running unmerged branches.
>
> Perhaps there could be a recommendation to merge every 3 months.
My hope is that with these process changes, we won't end up with
long-running branches.
Maybe we could add a recommendation,
Hey!
Almost a year ago, the branching strategy was changed [1][2].
1: https://issues.guix.gnu.org/63459
2: https://lists.gnu.org/archive/html/guix-devel/2023-06/msg00024.html
I think these changes have gone OK, we've had ~27 [3] branches merged in
this manor and I think looking back these
Ludovic Courtès writes:
> What’s the status of ‘core-updates’? What are the areas where help is
> needed?
>
> I know a lot has happened since the last update¹, which is roughly when
> I dropped the ball due to other commitments, but I’m not sure where we
> are now.
I haven't really been
Ludovic Courtès writes:
> Hi,
>
> Philip McGrath skribis:
>
>> I don't know if the root cause is related, but this reminded me of
>> some networking errors I sometimes get accessing substitutes. I had
>> the luck (good or bad?) to get an example while building
>>
Liliana Marie Prikler writes:
> I've now pushed the merge commits for both emacs-team and gnome-team.
Thank you to everyone involved in getting these changes through :D
> If you have a weak machine, PLEASE DO NOT PULL IMMEDIATELY AND WAIT FOR
> CI TO CATCH UP! Despite efforts to prebuild
Ludovic Courtès writes:
> Hi!
>
> Christopher Baines skribis:
>
>> Related to this, I've added options to the nar-herder to help change the
>> TTL being used, and reduced the TTL for bordeaux.guix.gnu.org to 10
>> minutes (from 180 days) [4]. This will at
Hey!
I'm think the last update I sent out was back in April 2023 [1], but
it's coming up to 3 years since bordeaux was added as a default
substitute server [2]. It's scary how much time has passed!
1: https://lists.gnu.org/archive/html/guix-devel/2023-04/msg00319.html
2:
"Artyom V. Poptsov" writes:
> Hello,
>
> I just found out that Guix QA returns a plain Guile error message when I
> try to open an issue that was merged:
> https://qa.guix.gnu.org/issue/69654
>
> The error looks like this:
>
> An error occurred
>
> Sorry about that!
> wrong-type-arg
>
>
MSavoritias writes:
> On 3/16/24 19:50, Christopher Baines wrote:
>> Ian Eure writes:
>>
>>> Hi Guixy people,
>>>
>>> I’d never heard of SWH before I started hacking on Guix last fall, and
>>> it struck me as rather a good idea. However, I’
Ian Eure writes:
> Hi Guixy people,
>
> I’d never heard of SWH before I started hacking on Guix last fall, and
> it struck me as rather a good idea. However, I’ve seen some things
> lately which have soured me on them.
>
> They appear to be using the archive to build LLMs:
>
Ludovic Courtès writes:
> Christopher Baines skribis:
>
>> - Then there's the big areas to work on next:
>>
>>- I think I'm going to need to use thread pools for SQLite operations
>> in the daemon, as the build coordinator does.
>
> I think we sho
Hey!
Here's an overdue update on rewriting the Guix daemon in Guile,
following on from the earlier thread on guix-devel [1] and the blog post
[2].
1: https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00328.html
2: https://guix.gnu.org/en/blog/2023/a-build-daemon-in-guile/
Unfortunately I
Clément Lassieur writes:
> On Fri, Feb 16 2024, Andreas Enge wrote:
>
>> Am Fri, Feb 16, 2024 at 11:56:50AM +0100 schrieb Clément Lassieur:
>>> Would it makes sense to have a "does-not-apply" tag too?
>>
>> Should this not appear in the QA page, assuming that once all the new
>> issues are
Vivien Kraus writes:
> Hello Chris,
>
> Le vendredi 09 février 2024 à 10:44 +, Christopher Baines a écrit :
>> Let me know if you have any comments or questions!
>
> Thank you for all your work on QA.
>
> I can’t help but notice QA is missing
Vivien Kraus writes:
> Dear QA wizards,
>
> Le vendredi 09 février 2024 à 10:44 +, Christopher Baines a écrit :
>> You just need to not be involved (so you can't review your
>> own patches)
>
> I interpret this as it’s OK to review patches if you asked for a c
Andreas Enge writes:
> I see a few "Failed to process revision", for instance here:
>https://qa.guix.gnu.org/issue/68778
> While I am not sure why, these look like transient (?) build failures,
> at least failures not related to the patch in question. What is there to do?
Long term it
Tanguy LE CARROUR writes:
> Hi Chris,
>
> First of, thanks (again) for everything that you’ve done with QA!
> It looks great!
>
>
> Quoting Christopher Baines (2024-02-09 11:44:11)
>> Let me know if you have any comments or questions!
>
> Unfortunately, I ha
Hey!
After substitute availability taking a bit of a dive recently, the
bordeaux build farm has finally caught back up and QA is back submitting
builds for packages changed by patches.
QA also has a feature to allow easily tagging patches (issues) as having
been reviewed and ready to merge
Steve George writes:
> Hi,
>
> Did anyone take a photo of the discussion whiteboard?
>
> And/or anyone get a photo of the room generally that could be used in
> the blog post? Be nice to have a visual ...
I took a picture of the infrastructure discussion whiteboard:
Ludovic Courtès writes:
> To those traveling to Brussels tomorrow: who’s in to meet in our lair,
> namely Au Bon Vieux Temps, on Wednesday evening/night? :-)
>
>
> https://www.openstreetmap.org/?mlat=50.84832=4.35237#map=20/50.84832/4.35237=Y
>
> I should be able to be there around
Andreas Enge writes:
> Am Sat, Dec 09, 2023 at 11:54:59AM +0100 schrieb Ludovic Courtès:
>> I think this underlines a collective failure to get our act together.
>
> indeed, and besides what Simon mentioned about the bank situation I think
> there was a certain lack of consistency between
Hey,
I sent out the last update [1] back near the start of December.
1: https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00021.html
In summary, QA has been not really working since mid December as
data.qa.guix.gnu.org wasn't keeping up with processing revisions for
patches and branches.
Ludovic Courtès writes:
> Christopher Baines skribis:
>
>> I think you're right, while I send some other changes in #68266, I think
>> it's this change around make-rust-sysroot that has pretty much all the
>> effects on performance.
>>
>> I think the tens
Efraim Flashner writes:
> [[PGP Signed Part:Signature made by expired key 41AAE7DCCA3D8351 Efraim
> Flashner ]]
> On Fri, Jan 05, 2024 at 04:41:14PM +, Christopher Baines wrote:
>>
>> Ludovic Courtès writes:
>>
>> > Hi,
>> >
>> &
Ludovic Courtès writes:
> Hi,
>
> Christopher Baines skribis:
>
>> When asked by the data service, it seems to take Guix around 3 minutes
>> to compute cross derivations for all packages (to a single
>> target). Here's a simple script that replicates this:
Maxim Cournoyer writes:
> Hi,
>
> Christopher Baines writes:
>
>> Tobias Geerinckx-Rice writes:
>>
>>> Christopher Baines 写道：
>>>> it's not the most cost effective setup
>>>
>>> Has this been explained in more detail before?
>
Tobias Geerinckx-Rice writes:
> Christopher Baines 写道：
>> it's not the most cost effective setup
>
> Has this been explained in more detail before?
Probably not, beid is currently a CPX51 Hetzner cloud server costing
€65.33 a month. This has been useful as it's enabled scalin
Ludovic Courtès writes:
> Hello,
>
> Christopher Baines skribis:
>
>> I am still planning to shutdown data.qa.guix.gnu.org and
>> QA which depends on it within the next couple of weeks. I do hope it can
>> return some point though, and hopefully sooner rather
Ludovic Courtès writes:
> Hello!
>
> Christopher Baines skribis:
>
>> As previously set out, I'm planning to stop hosting the data service
>> instances this year. While I would like to stop hosting the server for
>> data.guix.gnu.org,
>
> I forgot
Hey!
Not much has changed since the last update. There's a new "waiting for
builds" status, I tweaked some code around build cancelation, I put in
place a mitigation for #67194 affecting the build coordinator, and did
some investigation of the hurd locale issue (#67507).
As previously set out,
Hey,
I have a RISC-V board that is hooked up to the bordeaux build farm, and
there is another board connected, although there's some issues with the
connection/agent.
1 to 2 boards though isn't enough to get good substitute availability
and build packages for patches and branches though.
Reza Housseini writes:
> Hi Christopher
>
> I submitted a new revision to the issue, but the QA link shows
>
> Issue not found
> This could mean the issue does not exist, it has no patches or has
> been closed.
>
> do you know what the problem is here?
There's two issues, one is the machine
John Kehayias writes:
> Hi everyone,
>
> Update below:
>
> On Sun, Nov 05, 2023 at 11:47 PM, John Kehayias wrote:
> [snippy snip snip]
>>>
>>> Happy to! Substitutes will eventually become available, but there's
>>> quite a few builds to be done. This takes care of some ungrafts and
>>> updates
"jgart" writes:
> Does anyone follow this workflow for reviewing patches?
>
> git clone https://git.guix-patches.cbaines.net/guix-patches/
> git checkout issue-x
> git format-patch ...
> # then in the development checkout of Guix:
> git am ...; make; ./pre-inst-env guix build
>
> Should we
Christopher Baines writes:
> Hey!
>
> This event is now finished! Efraim and Julien and I had a discussion
> about Guix things relating to Reproducible Builds and there are some
> notes available here [1].
>
> 1: https://reproducible-builds.org/events/hamburg2023/guix-todo/
Hey!
This event is now finished! Efraim and Julien and I had a discussion
about Guix things relating to Reproducible Builds and there are some
notes available here [1].
1: https://reproducible-builds.org/events/hamburg2023/guix-todo/
Maybe the others can mention what things they've been looking
Suhail writes:
> "Christopher Baines" writes:
>
>> There isn't much documentation for QA
>
> Understood.
>
> Is the preferred place to ask questions regd the QA service this mailing
> list?
Yep.
>> I think it's fair to say that these shouldn't be s
Suhail writes:
> Christopher Baines writes:
>
>> - The README is published at https://qa.guix.gnu.org/README
>
> The README seems more focused on task planning and TODO items than
> explaining how to use the qa.guix.gnu.org website. Could you please
> provide a
Hey,
The last update I sent out was back in July [1].
1: https://lists.gnu.org/archive/html/guix-devel/2023-07/msg00144.html
There have been quite a few changes over the last few months, here's a
summary of the changes:
- QA now stores when it's submitted builds for a issue/branch and
Hey!
When asked by the data service, it seems to take Guix around 3 minutes
to compute cross derivations for all packages (to a single
target). Here's a simple script that replicates this:
(use-modules (srfi srfi-34)
(gnu packages)
(guix grafts)
guix-comm...@gnu.org writes:
> This is an automated email from the git hooks/post-receive script.
>
> snape pushed a commit to branch master
> in repository guix.
>
> The following commit(s) were added to refs/heads/master by this push:
> new 6c894b7a1a gnu: Add passff.
> 6c894b7a1a is
Christopher Baines writes:
> Vivien Kraus writes:
>
>> It seems that the only available information of the feature branch is
>> in the patch name.
>> ---
>>
>> Hello guix!
>>
>> Thank you for making the QA tool. It seems to me that feature branc
Andy Tai writes:
> Hi, per Chris's recent comments, Guix QA only looks at (a window of)
> recently created issues due to storage space limitations, which is
> understandable.
>
> However, if I have update (package definition) patches to not very
> recent issues, such as some stale issues
Arun Isaac writes:
>> Sorry, I missed this patch. I will apply it tonight.
>
> Done!
>
> https://git.savannah.gnu.org/cgit/guix/mumi.git/commit/?id=a89c5109963de0b5fd1f500ed2e2ede47728fdb4
> https://git.savannah.gnu.org/cgit/guix/mumi.git/commit/?id=025fc600f1cb4c73042bf920aee3e07d5fb9c53a
>
>
Maxim Cournoyer writes:
> Hi Christopher,
>
> Christopher Baines writes:
>
>> Hey,
>>
>> As has happened before in the past, at the moment we're not getting
>> emails to guix-commits for the main guix.git repository. This impacts
>> the data service
Simon Tournier writes:
> Hi,
>
> Out of my curiosity, is this patch
>
> On Tue, 26 Sep 2023 at 09:59, Christopher Baines wrote:
>> * mumi/web/graphql.scm (): Include merged_with.
>> ---
>> mumi/web/graphql.scm | 12 +++-
>> 1 file changed, 11
Reza Housseini writes:
>> This is probably down to a top level circular dependency. In particular,
>> trying to paraview to compute the version to form part of the
>> native-search-path at the top level causes problems.
>
> I'm wondering why it builds fine locally but causes problems in QA
>
Andy Tai writes:
> Hi, for one of my package patches, Guix QA shows
>
> "Unable to apply patches"
>
> in https://qa.guix.gnu.org/issue/63095
>
> even though I double checked the patch applies cleanly on the current
> head of the master branch.
>
> Guix QA shows no hint as what the failure is
Hey,
As has happened before in the past, at the moment we're not getting
emails to guix-commits for the main guix.git repository. This impacts
the data service instances as they use these emails to know when there
are new revisions to process.
I've now added the ability to configure the data
"reza.housse...@gmail.com" writes:
> On October 5, 2023 10:49:06 AM GMT+02:00, Christopher Baines
> wrote:
>>
>>"reza.housse...@gmail.com" writes:
>>
>>> I submitted an issue to guix. But QA refuses to build it [1]. I have
>>> no
"reza.housse...@gmail.com" writes:
> I submitted an issue to guix. But QA refuses to build it [1]. I have
> no clue what the problem is, can anyone shed light on a possible
> resolution?
You pretty much found the problem, the relevant line on the page you
linked to is:
[ 6/ 50] loading...
Efraim Flashner writes:
> [[PGP Signed Part:Signature made by expired key 41AAE7DCCA3D8351 Efraim
> Flashner ]]
> On Thu, Sep 28, 2023 at 11:58:10PM +0200, Ricardo Wurmus wrote:
>>
>> Christopher Baines writes:
>>
>> > PackagingCon [1] is happeni
Giovanni Biscuolo writes:
> [[PGP Signed Part:Signature made by expired key D37D0EA7CECC3912 Giovanni
> Biscuolo (Xelera) ]]
> Hi,
>
> Giovanni Biscuolo writes:
>
> [...]
>
The first thing we need is a server side git post-receive hook on
Savannah, I've opened the sr#110928 support
Christopher Baines writes:
> I've been reviewing the list of ideas on and around QA ([1]) recently,
> and got thinking again about how to support people without commit access
> reviewing patches. Obviously you don't need commit access to review
> patches, but where I think we need
* mumi/web/graphql.scm (): Include merged_with.
---
mumi/web/graphql.scm | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/mumi/web/graphql.scm b/mumi/web/graphql.scm
index 6dcb8ce..2c7c676 100644
--- a/mumi/web/graphql.scm
+++ b/mumi/web/graphql.scm
@@ -69,7 +69,17
Vivien Kraus writes:
> Hi!
>
> Here is a small library that exports 3 types:
> − is the collection of metadata that is present
> in the square brackets in the patch names;
> − is an individual item of the patch series;
> − is a whole series of patches;
>
> And a set of functions to parse
Simon Tournier writes:
> On Wed, 26 Jul 2023 at 09:44, Christopher Baines wrote:
>
>> The queue is very large at [3].
>
> Some patches trigger a lot of rebuilds. And the threshold is about 300
> or something, I guess. Would it be possible to mark these items?
>
&
Andy Tai writes:
> For a submitted patch, if Guix QA "fails to process revision" as in this log
> https://data.qa.guix.gnu.org/job/49399
>
> [ 32/ 40] compiling... 60.0% of 20 filesmadvise failed: Cannot allocate memory
> builder for `/gnu/store/j3hy5gymlfrdrhm8aj2brnsa2pix16n2-guix-home.drv'
>
Vivien Kraus writes:
> It seems that the only available information of the feature branch is
> in the patch name.
> ---
>
> Hello guix!
>
> Thank you for making the QA tool. It seems to me that feature branches
> are ignored for patches. The patches seem to always be applied on top
> of master.
Mathieu Othacehe writes:
>> I imagine the daemon could be structured as a set of actors (it’s really
>> my thing these days ;-)), with an eye on facilitating code sharing and
>> interaction with the Coordinator, Cuirass, and all that.
>
> I think this point is really important here. If the
Mekeor Melire writes:
> 2023-09-13 16:36 m...@cbaines.net:
>
>> I think this has been talked about for a while [1], but I want to
>> make it happen. Currently the guix-daemon is still similar to the
>> nix-daemon that it was forked from, and is implemented in C++. I
>> think that a Guile
Caleb Ristvedt writes:
>> Still though, I'd like to hear what people think about which direction
>> the implementation should go, and what features they'd like to see. Even
>> if those are not essential to make the Guile implementation viable, it
>> still might inform the direction to take.
>
Josselin Poiret writes:
>> 2: https://nlnet.nl/project/GuixDaemon-Guile/
>>
>> Rewrites are risky because you only get the value right at the end,
>> therefore the priority is to get a minimal but viable implementation in
>> Guile that can be switched to, and not to get distracted on adding or
Christopher Baines writes:
> [[PGP Signed Part:Good signature from 5E28A33B0B84F577 Christopher Baines
> (trust ultimate) created at 2023-09-15T12:40:53+0100 using
> RSA]]
>
> guix-comm...@gnu.org writes:
>
>> commit 076b3384dfa29ae118d0375d516376a7fe98a197
&g
guix-comm...@gnu.org writes:
> commit 076b3384dfa29ae118d0375d516376a7fe98a197
> Author: Maxim Cournoyer
> AuthorDate: Tue Sep 12 09:29:22 2023 -0400
>
> gnu: qemu: Reinstate the iothreads-commit-active test.
>
> * gnu/packages/virtualization.scm (qemu) [arguments]: Add set-SOCK_DIR
>
Ludovic Courtès writes:
>> Rewrites are risky because you only get the value right at the end,
>> therefore the priority is to get a minimal but viable implementation in
>> Guile that can be switched to, and not to get distracted on adding or
>> improving functionality unnecessarily. That is
Vagrant Cascadian writes:
> On 2023-09-13, Christopher Baines wrote:
>> I think this has been talked about for a while [1], but I want to make it
>> happen. Currently the guix-daemon is still similar to the nix-daemon
>> that it was forked from, and is implemented in C++.
Maxim Cournoyer writes:
>> The transformation toward a Guile daemon is a point of consistency and
>> pride for the project and therefore unlikely to be second-guessed or
>> reverted. My recommendation is to replace the daemon gradually—working
>> from (apply system* (command-line) downward—and
Hey!
I think this has been talked about for a while [1], but I want to make it
happen. Currently the guix-daemon is still similar to the nix-daemon
that it was forked from, and is implemented in C++. I think that a Guile
implementation of the guix-daemon will simplify Guix and better support
Maxim Cournoyer writes:
> Hi Vagrant,
>
> Vagrant Cascadian writes:
>
>> On 2023-09-06, Liliana Marie Prikler wrote:
>>> Am Dienstag, dem 05.09.2023 um 19:41 -0400 schrieb brian
‘* foo/bar.scm new-package (inputs): add input’
stuff. I literally can never remember this format,
Felix Lechner writes:
> On Wed, Sep 6, 2023 at 9:47 AM Christopher Baines wrote:
>>
>> Maybe we can use debbugs tags for this?
>
> Instead of pushing people into reviews and then again making the same
> committers a bottleneck, I would offer some entry-level cont
Hey!
I've been reviewing the list of ideas on and around QA ([1]) recently,
and got thinking again about how to support people without commit access
reviewing patches. Obviously you don't need commit access to review
patches, but where I think we need some process is how to expedite
someone with
Giovanni Biscuolo writes:
> Hello,
>
> often bug reports related to patches are left open even after the
> patch/patchset have been applied, the last example is a batch of Debbugs
> manual gardening from Vagrant last Fri and Sat when he closed more than
> 20 bugs with messages similar to this
Hey,
PackagingCon [1] is happening in Berlin on the 26th to the 28th of
October, and the Reproducible Builds summit is happening in Hamburg on
the 31st of October to the 2nd of November.
1: https://packaging-con.org/
2: https://reproducible-builds.org/events/hamburg2023/
I've had a talk
"jgart" writes:
> Hi Guixers,
>
> Andreas' detailed a nice workflow for reviewing patches in a previous thread*:
>
> ```
> git clone https://git.guix-patches.cbaines.net/guix-patches/
> git checkout issue-x
> git format-patch ...
> then in the development checkout of Guix:
> git am ...;
Hey,
It's been a while since I sent out the last update on QA things that
I've been working on, there was a small update back in May [1] and one
before that in March [2].
1: https://lists.gnu.org/archive/html/guix-devel/2023-05/msg00142.html
2:
Andy Tai writes:
> This is a bug report on Guix QA:
> I submitted a patch updating Openshot to the latest version. As
> Openshot is an app, it should have few, if any, packages depending on
> it. but Guix QA seems confused and was rebuilding 14000 packages:
>
>
guix-comm...@gnu.org writes:
> jpoiret pushed a commit to branch master
> in repository guix.
>
> commit 999a6ac0cfd9339e138007ed9e4e544a55e92e3e
> Author: Josselin Poiret
> AuthorDate: Mon May 22 11:04:17 2023 +0200
>
> gnu: mig: Update to 1.8+git20230520.
>
> * gnu/packages/hurd.scm
John Kehayias writes:
>>> Or does the section about branch building for once patches are pushed
>>> to a branch on Savannah?
>>
>> I'm not sure what you're asking here.
>
> I'm confused myself over my wording, but I remember what I was trying
> to get at:
>
> Currently QA doesn't build patches
John Kehayias writes:
>> I've now merged these changes as
>> 0ea096ae23fa81f05ce97e5e61c15647c0a475ec.
>>
>> You can now see the updated Commit Policy on the website [1] (you might
>> need to force a refresh), as well as the new section on managing patches
>> and branches [2].
>>
>> 1:
>>
Christopher Baines writes:
> The changes in #63459 have strayed now in to touching the commit policy
> [1]. My intent was to simplify the guidance by grouping it better, but I
> think the significant change here is that the commit policy now
> references the entire branching stra
Andreas Enge writes:
> thanks for taking up this issue! I agreed with Ludovic's comments, so
> things look good now for me. A very minor point: In the section on
> "trivial" changes, I would drop this sentence (which was already there
> before):
> "This is subject to being adjusted, allowing
Maxim Cournoyer writes:
> Hi Christopher,
>
> Christopher Baines writes:
>
>> guix-comm...@gnu.org writes:
>>
>>> apteryx pushed a commit to branch master
>>> in repository guix.
>>>
>>> commit ec9f15b158300da3a77ce02cd2267222f435e8
Hey!
The changes in #63459 have strayed now in to touching the commit policy
[1]. My intent was to simplify the guidance by grouping it better, but I
think the significant change here is that the commit policy now
references the entire branching strategy, rather than just talking about
sending
Christopher Baines writes:
> guix-comm...@gnu.org writes:
>
>> glv pushed a commit to branch master
>> in repository guix.
>>
>> commit b019b49c74e51e42230da471f39bff9f642fbc24
>> Author: Guillaume Le Vaillant
>> AuthorDate: Fri Jun 2 13:32:55 2023
Efraim Flashner writes:
> On Sat, Jun 03, 2023 at 08:12:48PM +0100, Christopher Baines wrote:
>>
>> Efraim Flashner writes:
>>
>> > On Fri, Jun 02, 2023 at 11:03:42PM +0100, Christopher Baines wrote:
>> >>
>> >> guix-comm...@gnu.org w
Guillaume Le Vaillant writes:
> Christopher Baines skribis:
>
>> guix-comm...@gnu.org writes:
>>
>>> glv pushed a commit to branch master
>>> in repository guix.
>>>
>>> commit b019b49c74e51e42230da471f39bff9f642fbc24
>>> Author:
guix-comm...@gnu.org writes:
> glv pushed a commit to branch master
> in repository guix.
>
> commit b019b49c74e51e42230da471f39bff9f642fbc24
> Author: Guillaume Le Vaillant
> AuthorDate: Fri Jun 2 13:32:55 2023 +0200
>
> gnu: sbcl: Update to 2.3.5.
>
> * gnu/packages/lisp.scm (sbcl):
guix-comm...@gnu.org writes:
> This is an automated email from the git hooks/post-receive script.
>
> efraim pushed a commit to branch master
> in repository guix.
>
> The following commit(s) were added to refs/heads/master by this push:
> new 2a6d2fc1d8 gnu: sbcl: fix build on
guix-comm...@gnu.org writes:
> apteryx pushed a commit to branch master
> in repository guix.
>
> commit ec9f15b158300da3a77ce02cd2267222f435e80f
> Author: Maxim Cournoyer
> AuthorDate: Tue Jun 6 12:12:40 2023 -0400
>
> gnu: wxwidgets: Add libxtst to inputs.
>
> WxWidgets was already
Hey!
Since the core-updates merge, substitute availability has been quite
changeable. This has been more due to the large changes merged since the
core-updates merge than the changes in core-updates itself.
Substitute availability was quite high for a brief period around a
couple of weeks ago,
Efraim Flashner writes:
> On Fri, Jun 02, 2023 at 11:03:42PM +0100, Christopher Baines wrote:
>>
>> guix-comm...@gnu.org writes:
>>
>> > efraim pushed a commit to branch master
>> > in repository guix.
>> >
>> > commit 076688fa1e41
guix-comm...@gnu.org writes:
> efraim pushed a commit to branch master
> in repository guix.
>
> commit 076688fa1e41a09f034a80e1a593bac43f1f1482
> Author: Efraim Flashner
> AuthorDate: Thu Jun 1 11:06:00 2023 +0300
>
> gnu: openblas: Update architectures we provide substitutes for.
>
>
Luis Felipe writes:
> Hi Chris,
>
> El 31/05/23 a las 10:48, Christopher Baines escribió:
>> Luis Felipe writes:
>>
>>> Another (faster) test from a different machine with Guix System 020184f,
>>> same place and network (60 Mbps):
>> Thanks for t
1 - 100 of 766 matches
Mail list logo
