Hi Andreas,
On Tue, Feb 27 2024, Andreas Enge wrote:
> a time-based approach sounds like a good idea
How about the second Monday and Tuesday of every month? That is a slow
time for contributors who have more time on weekends.
> It might still be good to do it in a separate branch instead of
>
On 2024-02-27, Andreas Enge wrote:
> Am Mon, Feb 26, 2024 at 07:26:57AM -0800 schrieb Felix Lechner:
>> How about a 48-hour period every month in which commits are permitted
>> even if they cause "world rebuilds"?
>> We could pause the substitute builders during that period. It would get
>> rid of
Hello Felix,
Am Mon, Feb 26, 2024 at 07:26:57AM -0800 schrieb Felix Lechner:
> How about a 48-hour period every month in which commits are permitted
> even if they cause "world rebuilds"?
> We could pause the substitute builders during that period. It would get
> rid of core-updates forever.
a ti
Hi Andreas,
On Wed, Jan 31 2024, Andreas Enge wrote:
> We should be able to do a world-rebuild not once or twice a year, but
> at least every month
How about a 48-hour period every month in which commits are permitted
even if they cause "world rebuilds"?
We could pause the substitute builders d
Hello!
Josselin Poiret skribis:
> Thanks for the feedback! So in the meantime I chose to go ahead and try
> with 2.39 (how hard could it be?).
I’m glad you did that; at the same time, I feel like it’s delayed the
merge. Maybe in the future we need a calendar-based schedule for
‘core-updates’
Hi again everyone,
Thanks for the feedback! So in the meantime I chose to go ahead and try
with 2.39 (how hard could it be?).
The main visible change for us in 2.39 is the removal of the crypt
library, with a replacement being the external libxcrypt. This wasn't
too bad to fix in most places, y
Hello,
Le mercredi 31 janvier 2024 à 17:44 +0100, Josselin Poiret a écrit :
> Also, I see that most of the patches that were requested to be merged
> into c-u (like the big pages for jemalloc) actually got pushed, are
> there any other (well-tested) ones we can go for at the same time as
> the
> g
Hi Vivien,
> The eudev package has been touched on gnome-team
I reviewed the patches but do not believe they solve Bug#63508 or
Bug#63787.
That issue, stated succinctly, arises because configure.ac sets the
Makefile variable $(udevrulesdir) to the store output [1] while custom
rules like mine [2
On 2024-01-31, Josselin Poiret wrote:
> One conundrum we have for now: glibc 2.38 has a couple of new CVEs, and
> we have three options:
> 1) change glibc to track the 2.38 release branch → world rebuild.
> 2) graft glibc → bad user experience (and we're not supposed to graft
> outside of master).
Dear guix,
Le mercredi 31 janvier 2024 à 10:19 -0800, Felix Lechner via
Development of GNU Guix and the GNU System distribution. a écrit :
> Either way, I'd appreciate if Eudev could please be fixed in this
> core-updates cycle. The fix has been available for more than half a
> year.
The eudev pa
Hello,
Am Wed, Jan 31, 2024 at 05:44:21PM +0100 schrieb Josselin Poiret:
> One conundrum we have for now: glibc 2.38 has a couple of new CVEs, and
> we have three options:
> 1) change glibc to track the 2.38 release branch → world rebuild.
> 2) graft glibc → bad user experience (and we're not supp
Hi Josselin,
On Wed, Jan 31 2024, Josselin Poiret wrote:
> One conundrum we have for now: glibc 2.38 has a couple of new CVEs
The authors describe CVE-2023-6246, which is probably the most serious
of the four vulnerabilities, as "significant" [1] and Red Bat ranks it
as "8.4 (HIGH)" under the ne
Hi everyone,
Since we're a couple people working on core-updates at the same time, it
might be a good idea to coordinate a bit (of course, other volunteers
welcome :) ).
One conundrum we have for now: glibc 2.38 has a couple of new CVEs, and
we have three options:
1) change glibc to track the 2.3
13 matches
Mail list logo
