bug#70456: Request for merging core-updates branch

bug#70456: Request for merging core-updates branch

[Steve George]

Let's see where we are with the branch currently.

Thanks,

Steve / Futurile

bug#70456: Request for merging "core-updates" branch

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

Hey,

Thanks for raising this issue Steve, given the branch has been going for
around 9 months (since [1]) now, I think it's well overdue to start
looking at building and merging it.

1: https://lists.gnu.org/archive/html/guix-commits/2023-07/msg00332.html

I pushed a single commit plus a merge from master today, and that was
pretty difficult. There was plenty of conflicts, and I probably have
resolved some wrongly, and there's potentially some things that Git
didn't raise as conflicts but might have broken with merging in master.

I'm also really confused by what commits appear to be on the branch,
take 12b15585a75062f3fba09d82861c6fae9a7743b2 which appears to be one
core-updates, but it's a duplicate of
e2a7c227dea5b361e2ebdbba24b923d1922a79d0 which was pushed to
master. Same with this commit 28d14130953d868d4848540d9de8e1ae4a01a467,
which is different to f29f80c194d0c534a92354b2bc19022a9b70ecf8 on
master.

Putting aside the functional changes on core-updates, it's doesn't seem
good to merge these seemingly duplicate commits on to master. I'm not
sure how this happened though, or how to fix it.

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

bug#70456: Request for merging "core-updates" branch

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]

Christopher Baines <mail@cbaines.net> writes:

> I'm also really confused by what commits appear to be on the branch,
> take 12b15585a75062f3fba09d82861c6fae9a7743b2 which appears to be one
> core-updates, but it's a duplicate of
> e2a7c227dea5b361e2ebdbba24b923d1922a79d0 which was pushed to
> master. Same with this commit 28d14130953d868d4848540d9de8e1ae4a01a467,
> which is different to f29f80c194d0c534a92354b2bc19022a9b70ecf8 on
> master.

I've worked out at least when these two werid commits turned up on
core-updates.

12b15585a7 is mentioned here:
  https://lists.gnu.org/archive/html/guix-commits/2023-09/msg00955.html

and 28d1413095 is mentioned here:
  https://lists.gnu.org/archive/html/guix-commits/2024-03/msg00381.html


With the changes last month in March, I was going to suggest deleting
the branch and then re-creating from f205179ed2 and trying to re-apply
the changes that should be on core-updates, while avoiding any
"duplicate" commits. However, I'm not even sure where to being with the
~5000 commits pushed in September, at least one of them is a duplicate
of a commit on master, but I'm not sure how many of the other ~5000 are.

For comparison, I did a merge of master in to core-updates today, and
this is what it shows up like on guix-commits:

  https://lists.gnu.org/archive/html/guix-commits/2024-04/msg01209.html

There are only two new revisions, the ed update I pushed, and the merge
commit, which is what a merge should look like as far as I'm aware.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

bug#70456: Request for merging "core-updates" branch

[Maxim Cournoyer]

Hi,

Christopher Baines <mail@cbaines.net> writes:

> Christopher Baines <mail@cbaines.net> writes:
>
>> I'm also really confused by what commits appear to be on the branch,
>> take 12b15585a75062f3fba09d82861c6fae9a7743b2 which appears to be one
>> core-updates, but it's a duplicate of
>> e2a7c227dea5b361e2ebdbba24b923d1922a79d0 which was pushed to
>> master. Same with this commit 28d14130953d868d4848540d9de8e1ae4a01a467,
>> which is different to f29f80c194d0c534a92354b2bc19022a9b70ecf8 on
>> master.
>
> I've worked out at least when these two werid commits turned up on
> core-updates.
>
> 12b15585a7 is mentioned here:
>   https://lists.gnu.org/archive/html/guix-commits/2023-09/msg00955.html
>
> and 28d1413095 is mentioned here:
>   https://lists.gnu.org/archive/html/guix-commits/2024-03/msg00381.html
>
>
> With the changes last month in March, I was going to suggest deleting
> the branch and then re-creating from f205179ed2 and trying to re-apply
> the changes that should be on core-updates, while avoiding any
> "duplicate" commits. However, I'm not even sure where to being with the
> ~5000 commits pushed in September, at least one of them is a duplicate
> of a commit on master, but I'm not sure how many of the other ~5000 are.
>
> For comparison, I did a merge of master in to core-updates today, and
> this is what it shows up like on guix-commits:
>
>   https://lists.gnu.org/archive/html/guix-commits/2024-04/msg01209.html
>
> There are only two new revisions, the ed update I pushed, and the merge
> commit, which is what a merge should look like as far as I'm aware.

I think probably what happened is that in the middle of a merge of
master -> core-updates (which entails sometimes painful conflicts
resolution), a new commit pushed to core-updates, and to be able to push
the resulting local branch (including the thousands of commits from the
merge commit) got rebased on the remote core-updates.

Perhaps another merge commit appeared on the remote around the same
time, which would explain the duplicates.

While I agree it's messy to have 5000 of duplicated commits, I'm not
sure attempting to rewrite the branch, which has seen a lot of original
commits, is a good idea (it'd be easy to have some good commits fall
into cracks, leading to lost of work).

I'd rather we take this experience as a strong reminding that rebasing
merge commits should be avoided at all costs (git already issues a
warning, IIRC).  As you suggested, the next time a situation like this
happens (locally prepared merge commit with new commits made to the
remote branch), merging the remote into the local branch is probably a
nicer solution.

-- 
Thanks,
Maxim

bug#70456: Request for merging "core-updates" branch

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 4238 bytes --]

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hi,
>
> Christopher Baines <mail@cbaines.net> writes:
>
>> Christopher Baines <mail@cbaines.net> writes:
>>
>>> I'm also really confused by what commits appear to be on the branch,
>>> take 12b15585a75062f3fba09d82861c6fae9a7743b2 which appears to be one
>>> core-updates, but it's a duplicate of
>>> e2a7c227dea5b361e2ebdbba24b923d1922a79d0 which was pushed to
>>> master. Same with this commit 28d14130953d868d4848540d9de8e1ae4a01a467,
>>> which is different to f29f80c194d0c534a92354b2bc19022a9b70ecf8 on
>>> master.
>>
>> I've worked out at least when these two werid commits turned up on
>> core-updates.
>>
>> 12b15585a7 is mentioned here:
>>   https://lists.gnu.org/archive/html/guix-commits/2023-09/msg00955.html
>>
>> and 28d1413095 is mentioned here:
>>   https://lists.gnu.org/archive/html/guix-commits/2024-03/msg00381.html
>>
>>
>> With the changes last month in March, I was going to suggest deleting
>> the branch and then re-creating from f205179ed2 and trying to re-apply
>> the changes that should be on core-updates, while avoiding any
>> "duplicate" commits. However, I'm not even sure where to being with the
>> ~5000 commits pushed in September, at least one of them is a duplicate
>> of a commit on master, but I'm not sure how many of the other ~5000 are.
>>
>> For comparison, I did a merge of master in to core-updates today, and
>> this is what it shows up like on guix-commits:
>>
>>   https://lists.gnu.org/archive/html/guix-commits/2024-04/msg01209.html
>>
>> There are only two new revisions, the ed update I pushed, and the merge
>> commit, which is what a merge should look like as far as I'm aware.
>
> I think probably what happened is that in the middle of a merge of
> master -> core-updates (which entails sometimes painful conflicts
> resolution), a new commit pushed to core-updates, and to be able to push
> the resulting local branch (including the thousands of commits from the
> merge commit) got rebased on the remote core-updates.
>
> Perhaps another merge commit appeared on the remote around the same
> time, which would explain the duplicates.
>
> While I agree it's messy to have 5000 of duplicated commits, I'm not
> sure attempting to rewrite the branch, which has seen a lot of original
> commits, is a good idea (it'd be easy to have some good commits fall
> into cracks, leading to lost of work).

I think it's important to weigh up the cost and risks associated with
either merging these commits, or somehow avoiding doing so. I think the
potential impact is more than just a bit of messy Git history.

Assuming we merge core-updates without doing anything about these
duplicate commits, and taking the cwltool package as a semi-random
example, if you do:

  git log -p gnu/packages/bioinformatics.scm

You're going to see two commits for the update to 3.1.20240112164112,
that's maybe confusing, but not a big issue I guess since they look the
same, just different hashes.

But say you're looking at the Git history because you want that specific
version of cwltool and you're going to use guix time-machine or an
inferior looking at that revision. Well, it's a lucky dip. If you pick
the original master commit, you're in luck, you'll probably get
substitutes for cwltool. But if you pick the other seemingly identical
commit, you're effectively checking out core-updates as it was last
month and the chance of substitutes is much less likely. I also can't
really think how you'd work out which commit is best to use once
core-updates is merged? The easiest way would probably be to check the
signature, but that will only work most of the time.

This isn't a new issue, it's already problematic for substitute
availability to use intermediate commits (commits that weren't directly
pointed to by master). But there are over 1000 packages who's versions
are being changed on core-updates currently, or at least it looks like
this because of the duplicate commits, and if I'm correct about how
people are using the git history to find commits for specific versions
of packages, then having these duplicates in the Git history for master
forever more is going to catch people out for as long as those versions
remain relevant.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

bug#70456: Request for merging "core-updates" branch

[Maxim Cournoyer]

Hi Christopher,

Christopher Baines <mail@cbaines.net> writes:

[...]

> Assuming we merge core-updates without doing anything about these
> duplicate commits, and taking the cwltool package as a semi-random
> example, if you do:
>
>   git log -p gnu/packages/bioinformatics.scm

I trust the 'newest' (appearing first in 'git log --grep='cwltool:
Update') would yield the commit having substitutes?

If so, the inconvenience is somewhat mitigated, as long as you know to
use the newest of duplicated commits.

-- 
Thanks,
Maxim

bug#70456: Request for merging "core-updates" branch

[tumashu]

[-- Attachment #1: Type: text/plain, Size: 315 bytes --]


emacs has a script gitmerge.el, it can skip some commit when merge with different merge rule (ours), maybe can make life easier:


https://git.savannah.gnu.org/cgit/emacs.git/tree/admin/gitmerge.el


https://git.savannah.gnu.org/cgit/emacs.git/tree/admin/notes/git-workflow











--
发自我的网易邮箱手机智能版

[-- Attachment #2: Type: text/html, Size: 436 bytes --]

Re: bug#70456: Request for merging "core-updates" branch

[Ludovic Courtès]

Hi Chris and all,

Christopher Baines <mail@cbaines.net> skribis:

> I think keeping the Git commit history clean and representative is
> really important, so to me at least this means core-updates can't be
> merged to master in it's current form, even if the changes overall from
> these 6351 commits are reasonable.
>
> I'm really not sure how to move forward though, I had a go at trying to
> rebuild the branch without introducing the thousands of duplicate
> commits and that produced a branch with 765 commits over master, which
> still seems a lot, but a big improvement over 6351:
>
>   https://git.cbaines.net/guix/log/?h=chris-core-updates-no-duplicates-attempt
>
> That was really hard going though, as there's plenty of merge conflicts
> along the way, and I'm pretty sure I solved some of them
> incorrectly. The resulting branch also differs from core-updates.

Woow, impressive.  How did you go about finding which commits were
duplicates/cherry-picked from master?  Which commit did you start from?

Given everything you’ve explained, it seems to me it’s worth trying to
start from a clean branch like this.

I checked it out (commit da77ea23daa0bfa4a73290dff99b22d6825ff80b) to
get an idea of where we are and got this:

--8<---------------cut here---------------start------------->8---
make[2]: *** No rule to make target 'gnu/packages/patches/glib-networking-gnutls-binding.patch', needed by 'all-am'.
make[2]: *** No rule to make target 'gnu/packages/patches/librecad-support-for-boost-1.76.patch', needed by 'all-am'.
--8<---------------cut here---------------end--------------->8---

It stopped at:

--8<---------------cut here---------------start------------->8---
gnu/packages/sdl.scm:72:2: error: (package (name "sdl2") (version "2.30.1") (source (origin (method url-fetch) (uri (string-append "https://libsdl.org/release/SDL2-" version ".tar.gz")) (sha256 (base32 "0fj7gxc7rlzzrafnx9nmf7ws3paxy583fmx7bcbavi6gr3xmy881")))) (arguments (list #:tests? #f #:configure-flags (gexp (append (quote ("--disable-wayland-shared" "--enable-video-kmsdrm" "--disable-kmsdrm-shared")) (quote ("--disable-alsa-shared" "--disable-pulseaudio-shared" "--disable-x11-shared" "LDFLAGS=-lGL")))) #:make-flags (gexp (cons* (string-append "LDFLAGS=-Wl,-rpath," (ungexp (this-package-input "eudev")) "/lib" ",-rpath," (ungexp (this-package-input "vulkan-loader")) "/lib") (quote ("V=1")))))) (propagated-inputs (list libx11 libcap mesa)) (native-inputs (list pkg-config)) (inputs (list libxrandr glu alsa-lib pulseaudio dbus eudev glib ibus-minimal libxkbcommon libxcursor vulkan-loader wayland wayland-protocols)) (outputs (quote ("out" "debug"))) (synopsis "Cross platform game development library") (description "Simple DirectMedia Layer is a cross-platform development library designed to\nprovide low level access to audio, keyboard, mouse, joystick, and graphics\nhardware.") (home-page "https://libsdl.org/") (license license:bsd-3)): missing field initializers (build-system)
--8<---------------cut here---------------end--------------->8---

I guess these are merge conflicts that weren’t correctly resolved.

This branch rewrites the entire ‘core-updates’ history.  What about
rewriting starting from the first series of “duplicate” commits?  That
should solve the immediate issue while keeping the “known good” history?

Thanks,
Ludo’.

bug#70456: Process gnome-team before core-updates

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 309 bytes --]

block 70456 by 70766
thanks

I think being able to merge core-updates is still a few weeks away, so I
think there's time to build and merge gnome-team without delaying
core-updates.

If it does become a problem, we can always switch approach and wait
until after core-updates is merged to look at gnome-team.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

bug#70456: Request for merging core-updates branch

[Lars-Dominik Braun]

Hi,

it seems the core-updates branch is first in the merge-queue. haskell-team
was successfully built by the CI and is ready to be merged. Since there
does not seem to be an ETA for core-updates, can I skip the queue and
go ahead with merging haskell-team?

Lars

bug#70456: Request for merging core-updates branch

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

Lars-Dominik Braun <lars@6xq.net> skribis:

> Hi,
>
> it seems the core-updates branch is first in the merge-queue. haskell-team
> was successfully built by the CI and is ready to be merged. Since there
> does not seem to be an ETA for core-updates, can I skip the queue and
> go ahead with merging haskell-team?
>
> Lars

Hi.
The lisp-team branch is also in a good shape and ready to be merged.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#70456: Request for merging core-updates branch

[Maxim Cournoyer]

Hi,

Guillaume Le Vaillant <glv@posteo.net> writes:

> Lars-Dominik Braun <lars@6xq.net> skribis:
>
>> Hi,
>>
>> it seems the core-updates branch is first in the merge-queue. haskell-team
>> was successfully built by the CI and is ready to be merged. Since there
>> does not seem to be an ETA for core-updates, can I skip the queue and
>> go ahead with merging haskell-team?
>>
>> Lars
>
> Hi.
> The lisp-team branch is also in a good shape and ready to be merged.

I think it's fine to merge these first; perhaps the core-updates merge
request should be removed if it was preposterous (usually we issue the
merge request when we are confident the branch is ready to me merged).

-- 
Thanks,
Maxim

bug#70456: Request for merging core-updates branch

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Hi,
>
> Guillaume Le Vaillant <glv@posteo.net> writes:
>
>> Lars-Dominik Braun <lars@6xq.net> skribis:
>>
>>> Hi,
>>>
>>> it seems the core-updates branch is first in the merge-queue. haskell-team
>>> was successfully built by the CI and is ready to be merged. Since there
>>> does not seem to be an ETA for core-updates, can I skip the queue and
>>> go ahead with merging haskell-team?
>>>
>>> Lars
>>
>> Hi.
>> The lisp-team branch is also in a good shape and ready to be merged.
>
> I think it's fine to merge these first; perhaps the core-updates merge
> request should be removed if it was preposterous (usually we issue the
> merge request when we are confident the branch is ready to me merged).

Hi.

It might be more logical to have two steps. First a "work started on
xyz-team branch" message to indicate to the QA to make the stats for
this branch, and then the "request for merging xyz-team branch" message
to put the branch in the merge queue.

I'll try to merge the lisp-team branch tomorrow (UTC+2 timezone).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#70456: core-updates failed package: time

[宋文武 via Bug reports for GNU Guix]

time-1.9 fail its test on core-updates:
https://ci.guix.gnu.org/build/4587082/log/raw

time(1) failed to detect 5MB allcoation.
  mem-baseline(kb): 768
  mem-5MB(kb):      5720
  delta(kb):        4952
FAIL tests/time-max-rss.sh (exit status: 1)

delta is 4952, but it expect 5000-6000.

No idea what's the reason, maybe skip it?

bug#70456: core-updates failed package: libfaketime for i686-linux

[宋文武 via Bug reports for GNU Guix]

宋文武 <iyzsong@envs.net> writes:

libfaketime (dependency of nss, poppler, cairo) failed for i686-linux

https://ci.guix.gnu.org/build/4555668/log/raw


out=1717606732 (secs since Epoch) expected=1 - bad
out=1717606732 (secs since Epoch) expected=2 - bad
out=1717606732 (secs since Epoch) expected=4 - bad


that mean FAKETIME=1 date doesn't report 1, but 1717606732.
I think that due to libfaketime doesn't work with _TIME_BITS=64 on 32bit
systems.  Maybe this issue
https://github.com/wolfcw/libfaketime/issues/418.

I have no idea how to fix this, help need!

bug#70456: Request for merging core-updates branch

[Maxim Cournoyer]

Hi,

Guillaume Le Vaillant <glv@posteo.net> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Hi,
>>
>> Guillaume Le Vaillant <glv@posteo.net> writes:
>>
>>> Lars-Dominik Braun <lars@6xq.net> skribis:
>>>
>>>> Hi,
>>>>
>>>> it seems the core-updates branch is first in the merge-queue. haskell-team
>>>> was successfully built by the CI and is ready to be merged. Since there
>>>> does not seem to be an ETA for core-updates, can I skip the queue and
>>>> go ahead with merging haskell-team?
>>>>
>>>> Lars
>>>
>>> Hi.
>>> The lisp-team branch is also in a good shape and ready to be merged.
>>
>> I think it's fine to merge these first; perhaps the core-updates merge
>> request should be removed if it was preposterous (usually we issue the
>> merge request when we are confident the branch is ready to me merged).
>
> Hi.
>
> It might be more logical to have two steps. First a "work started on
> xyz-team branch" message to indicate to the QA to make the stats for
> this branch, and then the "request for merging xyz-team branch" message
> to put the branch in the merge queue.

That'd be neat.  Some other flow/UI idea:

From the QA interface, have a "Request to build" button action attached
to a branch.

If the branch could be built successfully (with all checks OK), enable a
"Request to merge" button, that could send an email with the patches to
review to guix-patches.

-- 
Thanks,
Maxim

bug#70456: Request for merging core-updates branch

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Guillaume Le Vaillant <glv@posteo.net> writes:
>
>> Lars-Dominik Braun <lars@6xq.net> skribis:
>>
>>> Hi,
>>>
>>> it seems the core-updates branch is first in the merge-queue. haskell-team
>>> was successfully built by the CI and is ready to be merged. Since there
>>> does not seem to be an ETA for core-updates, can I skip the queue and
>>> go ahead with merging haskell-team?
>>>
>>> Lars
>>
>> Hi.
>> The lisp-team branch is also in a good shape and ready to be merged.
>
> I think it's fine to merge these first; perhaps the core-updates merge
> request should be removed if it was preposterous (usually we issue the
> merge request when we are confident the branch is ready to me merged).

Can you clarify what you mean by preposterous?

While the guidance did previously say to raise an issue when you wanted
to merge the branch, it's now changed to when you create the branch in
an attempt to avoid this of situation of long running stateful branches
in the future.

I fail to see how merging core-updates is going to get easier if we
wait.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

bug#70456: Request for merging "core-updates" branch

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

Hey,

I've spent a bunch of time in the last few days trying to see if I can
get the bordeaux build farm moving on core-updates and I think things
are moving at pace now.

Builds are happening for 6 systems, with the only major omission being
i586-gnu, I think there are existing issues with the guix-daemon in the
childhurds not being able to stop builds which timeout, which leads to
them getting stuck on builds. I'm not sure if there's an open bug about
this.

The other major issue that comes up every time there's a core-updates
round is that the x86_64-linux bootstrap doesn't seem to build on btrfs,
or at least milano-guix-1 which uses btrfs. I have to work around this
by scheduling builds with --tag=filesystem=ext4 to have them run on
other machines. There isn't a good bug for this, but #53416 probably
applies.

data.qa.guix.gnu.org seemed to be timing out more than usual for both
patches and branches, so I've made some changes there and in the
qa-frontpage to mitigate that. The core-updates page should now always
load, although something needs adding so you can see how up to date the
data is.

1: https://qa.guix.gnu.org/branch/core-updates

Andreas has also been getting some additional x86_64-linux/i686-linux
agents up and running which should help to speed up the build
throughput.

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

bug#70456: Request for merging core-updates branch

[Maxim Cournoyer]

Hi Christopher,

Christopher Baines <mail@cbaines.net> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Guillaume Le Vaillant <glv@posteo.net> writes:
>>
>>> Lars-Dominik Braun <lars@6xq.net> skribis:
>>>
>>>> Hi,
>>>>
>>>> it seems the core-updates branch is first in the merge-queue. haskell-team
>>>> was successfully built by the CI and is ready to be merged. Since there
>>>> does not seem to be an ETA for core-updates, can I skip the queue and
>>>> go ahead with merging haskell-team?
>>>>
>>>> Lars
>>>
>>> Hi.
>>> The lisp-team branch is also in a good shape and ready to be merged.
>>
>> I think it's fine to merge these first; perhaps the core-updates merge
>> request should be removed if it was preposterous (usually we issue the
>> merge request when we are confident the branch is ready to me merged).
>
> Can you clarify what you mean by preposterous?
>
> While the guidance did previously say to raise an issue when you wanted
> to merge the branch, it's now changed to when you create the branch in
> an attempt to avoid this of situation of long running stateful branches
> in the future.

OK, sorry, I somehow had forgotten/missed that.  Some branches might
require more work post merge-request than was expected; it's hard to say
without trying it first.

> I fail to see how merging core-updates is going to get easier if we
> wait.

It's not.  But while things are still being worked on, if other branches
are done and ready, they shouldn't be in held in limbo.

-- 
Thanks,
Maxim

bug#70456: Request for merging "core-updates" branch

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]

Christopher Baines <mail@cbaines.net> writes:

> I've spent a bunch of time in the last few days trying to see if I can
> get the bordeaux build farm moving on core-updates and I think things
> are moving at pace now.

Following on from this, builds have mostly paused for the last few days
as many changes have landed on the master branch.

There's a few impactful changes in this range [1] (subversion,
git-minimal, qt-build-system, ...) but also going back just over a week
there were the lisp-team changes pushed to master (ecl and sbcl updates)
which I don't think are in core-updates yet.

1: https://git.savannah.gnu.org/cgit/guix.git/log/?qt=range&q=c5fc11488c..831001c581

It's hard to tell how these changes will interact with those on
core-updates but I think we need to just rebase the branch and find out.

I've now done that and pushed it as core-updates-next. This is mostly to
allow others to make changes to core-updates-next today, before swapping
it out with core-updates tomorrow.

This core-updates-next also includes a few additional patches, plus the
contents of tex-team, since that was next in the queue, and the changes
shouldn't be risky.

Some good progress was made with building core-updates, so I'm hoping
that with this next iteration (and hopefully a quiet period on the
master branch) we can get to the point where we can merge.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

bug#70456: Request for merging "core-updates" branch

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]

Christopher Baines <mail@cbaines.net> writes:

> Christopher Baines <mail@cbaines.net> writes:
>
>> I've spent a bunch of time in the last few days trying to see if I can
>> get the bordeaux build farm moving on core-updates and I think things
>> are moving at pace now.

...

> Some good progress was made with building core-updates, so I'm hoping
> that with this next iteration (and hopefully a quiet period on the
> master branch) we can get to the point where we can merge.

Substitute availability has been progressing well for core-updates, with
the biggest fix being the switch to datefudge for the nss tests on 32bit
systems.

Unfortunately it's been a while since core-updates has been rebased, and
the master branch hasn't been quiet so even though substitute
availability looks good, core-updates is missing ~2500 commits from
master, including some impactful changes and not representative of the
state of master if it was merged.

I did try rebasing around 3 weeks ago, but I got stuck on some rust
related conflicts and gave up. I've had another go now though and I've
managed to rebase, although I did remove some of the rust changes (I've
sent them as patches here [1].

1: https://issues.guix.gnu.org/72553

Hopefully the builds won't take more than a week or two to happen.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]