Request for merging "core-updates" branch

  • Open
  • quality assurance status badge
Details
9 participants
  • Efraim Flashner
  • Guillaume Le Vaillant
  • ???
  • Lars-Dominik Braun
  • Ludovic Courtès
  • Christopher Baines
  • Maxim Cournoyer
  • Steve George
  • tumashu
Owner
unassigned
Submitted by
Steve George
Severity
normal
Blocked by
S
S
Steve George wrote on 18 Apr 16:56 +0200
Request for merging core-updates branch
(address . bug-guix@gnu.org)
ZiE0qcjXe5H_3XLT@dragon2
Let's see where we are with the branch currently.

Thanks,

Steve / Futurile
C
C
Christopher Baines wrote on 18 Apr 20:51 +0200
(no subject)
(address . control@debbugs.gnu.org)
87ttjy4i8l.fsf@cbaines.net
retitle 70456 Request for merging "core-updates" branch
thanks
C
C
Christopher Baines wrote on 19 Apr 16:42 +0200
Re: Request for merging "core-updates" branch
87il0d4dn0.fsf@cbaines.net
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.


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
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmYigvNfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XfdZxAArvvJgyEIeZjJZDMlwXDoK9XGfXP0++rV
NCjtbfa7hOFWA+hexPDIJFQEdYAw/uHeRMTja1pPHAB7sroTMhLtNbAMhW+FdPpi
bl9iB3jMdvXXnbOFo3+wPBBls4Utaoklckj/gqEgSjNyAKdYfKO+IkdG0ytvlPrD
9eGgUAOQ+Av+EqVeq8l8qS5G+lt231zuvwHOaXshqKCKfDgLNH9HRo6+XwANuwaG
TstFRDEDxosDlfU8jNpxKa2maOFmCI+A57XoFeR1w+nnCabf7bhUxADxnsbY2rEU
ByOHdqZ7F4tpbRRteuns2yZIS1T+tFpOmidbbIhBkh+cz6kmJwT+rg279OS2uRPp
wFSc+b4u3fvnYK29mdsJoMTaNWpqsZVDMN6WJeMN+kymG0wXJVVUr4QcAdde1E5T
XiEhiiFDzP6D9edSo+lk9sZBFYI2hY8w7JdUyU0AYb6f6jc8dQ/wyBrBe2H13lgp
L2qYoHj9E73OciJgJQQXfapPzHTIuGh5PdPYeJpsKx3mjFsLdHrSggJZS4cp439d
cM0gd+K+qQt+8xq7ZqERRPVopHb3341y7+2oFV6gyblY4gp0HAq8i2yA3TLeIfOm
sGAqpsnYXE/jq8hI+b7UX1QhzIcO+LcJ43CC9aycILComYHR9QB6y4ImLTAELQ8J
Nw5uq9GF8xw=
=o2zU
-----END PGP SIGNATURE-----

C
C
Christopher Baines wrote on 19 Apr 19:00 +0200
Re: bug#70456: Request for merging "core-updates" branch
(address . 70456@debbugs.gnu.org)
877cgt47a1.fsf@cbaines.net
Christopher Baines <mail@cbaines.net> writes:

Toggle quote (8 lines)
> 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:

and 28d1413095 is mentioned here:


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:


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.
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmYioyZfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XeddA/+MtC2Q79KS79HxTbG3yuL+VVDdEO4AT3Z
3RcIcBzw3k+fc4GAgMcxWqIujCrpQ+SP1BEY+Y+VkRD4DJW03F2zY2KxJO2jGfJd
B7Wt1SNe99wWFSILVJXerckEw2MO9Ef/W9iZyFqt7ScwbLBAPEQm/n9onMR1o9e+
O6FAeMXNpwQ2t/jZLpD+Ip4gxlHsy08H+Ep7QkBLWbGb4r/mZxGBzBjTGGt5VY5e
96HDrb0iHdMPuQf8sE9tclIzlTY8enso8kqvsrDVq7fD3F0CmwEdBjNA3hP/Dt/g
90EsaeIXXH+ntzz9n7PboKs1Y8BAkiNtdCNhj8ZlcUDDDj5ZFU9qdDzljWJ7m3U8
9PZFy7QlNMSlMGMiVYEnjvhn7fCWG7ESLHSmacFCPKV43OVV/h645ZjchqK5Oet7
mFfVQqfRu/RY37m5pUkFKnCZhecDwLQP7XS1haQMIo7GLbDBXvNbUwlygp7VX2uj
Chq9jLl6ci9Z6389aK1G4kUrtFoJZaPOWz8zhvKNkryWAq/faTuqY4DQHPB5LOcR
dH62r0sdFSjmfEmD2JL3JVanspSi7xhWBr2hqGbkfTstA7ouTWnNOHfR2FieWefW
iT2kU3grmcy1yUgNZQIbb85+7Ryfy+1TBEksHgb932sUgoaK1wD5lJ3pSPXwUHTs
mOT8Ejci9V8=
=40DP
-----END PGP SIGNATURE-----

C
C
Christopher Baines wrote on 20 Apr 13:14 +0200
Re: Status of ‘core-updates’
(name . Ludovic Courtès)(address . ludo@gnu.org)
87mspo2sme.fsf@cbaines.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (7 lines)
> 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 following core-updates, but I have had a look
since there's a request to merge it now [1].

I'm really concerned by the commits on the branch though, assuming I'm
using Git right, there are 6351 commits on the branch:

git log --pretty=oneline core-updates ^master | wc -l

Somehow, I think there's been a couple of pushes of commits to
core-updates that have partially duplicated lots of commits from master,
I put some more details in:


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:


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.

Maybe someone with more time, care and attention could do a better job,
but it might be more worthwhile just starting fresh and rather than
trying to produce a like for like branch just without the thousands of
duplicate commits, effectively manually rebase the branch (without the
duplicate commits) on master and try to get the commits in to a usable
state.

Any ideas?

Thanks,

Chris
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmYjo5lfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XekIQ/+KuLYQirShTHCf9rGDm8wZHHZWlF7zSuK
nMpV9021Xddb9uHY6LD8Zy3N8D/91GtfgiWuYujhxhGeylfr7nVk8J05K4nXlWeX
NfMTcAENmAOkxuSc2W9lERY851wJ4wrQ0WUN72UcbPB/Mxwrq4ZX7PxvYAqbP3fI
khWwcImneoGgVxOr0w7pxE+9bONQ22pbPpgeh+7Cbqi7aPiKxMTg/A8ByNdea8RM
WJ3hPdaeTlJq9+d9gR4mn9H7aerPJVqsWxu4LC6L/7Bdho+KCId1hZJ71JV6jDAc
Qty4xSwr7aQ65mhqmiGN8u4MFAm6Q1vWfkQKA3r/9YvdzZPj65g1+s4wMCLdh0wN
w9/XmR/MiLai+4xWqKXvTjCxjWLN5DpaOcuTrM9bpfu7dCVtVPIQ8b8g0n2uHSxa
8np0reYM+v4K9eQUwSDvtt5kpbe8ntF9Ds9RNahQ1lelt+14r1hz0DjQDO31tcdf
tCLYnuuO7mm2AOy9Pl0PjkfBxtktRfQs0Q2xU4Ff/UBIzw2r8FkKQaaBrrZKklrr
Hs8ru/lDjZe7E0hzquMduPajRDyJIGMTLjjJ7jhWOiTzrw7Cwy7NsJLDyAHB7H4T
L3u9EhOjVnQYHF445vl0Rvnu+AkAIeXqvlzp/m/4Xc5fcgKmDkB48l6jWrCKeqDv
HOk2q5j/CAs=
=imOn
-----END PGP SIGNATURE-----

M
M
Maxim Cournoyer wrote on 20 Apr 18:16 +0200
Re: bug#70456: Request for merging "core-updates" branch
(name . Christopher Baines)(address . mail@cbaines.net)
87bk64j9h8.fsf@gmail.com
Hi,

Christopher Baines <mail@cbaines.net> writes:

Toggle quote (35 lines)
> 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
C
C
Christopher Baines wrote on 20 Apr 20:08 +0200
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87h6fv3o0t.fsf@cbaines.net
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (53 lines)
> 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.
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmYkBKJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XeyBBAAtzoraZGiN1S8oA+s7mUFZBlnAmOG6P73
D+jiHOwibqAzMQM8+gFe/1K+Aqfk/Dv7tRRRiDS7AKaqNwBwh9ZcYrRZcy6z2Pdk
7oxB4X7nVQleFr+ljwvuNp0YsvJh31OSUTPoVgo1HfOwnBnvugcwImx9gzjPdJ+R
JFT5RHJJyHrtcFOYG45yk6K0NxqDu5ZTukwH8cYQTHFdctYMqBTq249BaME6tozT
FIWQH6BGuNEVHNsW+8ReOLRyf394YsqBxy4VDGc3TuiGlNTAkWiIX6QdNaPBd0kM
gN5gwNnI6ngukAXwgo/Mhf9iCqCyPnMNblpbSRic+IwsLXbQP6djU5enAo2s0xHs
y3pyND8TkUB1XakgHtPWhNFFGoHzuklzV8RPIO1RAL0u6lvqyG2qZT11rsKOElD4
Jx9etuGnz+xM6IQivcwpxHwRJoKUf+z91sYbIP/8OOtF0MuW2jBL48ysRTrHxALn
wBE+74wuolENicS6LfvFS7qvK96340Y9pVIUKqof1IGJPbIvRQNikx9uTZ+tDf6I
QXn+S3HYQhxcgviyEbtDYkWSpbfMQ594trlhPmczGgaYUVlSniuBWxPAf41twF4G
bX/JpUxjMR/qy0zY8fPoPg3eu+v4piMBUoIfsWDW1ryIDzGLVIqln6I42A3d5no8
bss9DuR15pM=
=AnWa
-----END PGP SIGNATURE-----

M
M
Maxim Cournoyer wrote on 20 Apr 23:15 +0200
Re: Status of ‘core-updates’
(name . Christopher Baines)(address . mail@cbaines.net)
87mspnivms.fsf@gmail.com
Hi Christopher,

Christopher Baines <mail@cbaines.net> writes:

Toggle quote (39 lines)
> Ludovic Courtès <ludo@gnu.org> 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 following core-updates, but I have had a look
> since there's a request to merge it now [1].
>
> I'm really concerned by the commits on the branch though, assuming I'm
> using Git right, there are 6351 commits on the branch:
>
> git log --pretty=oneline core-updates ^master | wc -l
>
> Somehow, I think there's been a couple of pushes of commits to
> core-updates that have partially duplicated lots of commits from master,
> I put some more details in:
>
> https://issues.guix.gnu.org/70456#3
>
> 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.

I also think Git commit history is important, but in this case I weigh
the value of removing ~5000 duplicated rust commits against the risks of
resolving merge conflicts wrong or forgetting commits upon attempting to
recreate the branch from scratch lower than the benefit.

Toggle quote (7 lines)
> Maybe someone with more time, care and attention could do a better job,
> but it might be more worthwhile just starting fresh and rather than
> trying to produce a like for like branch just without the thousands of
> duplicate commits, effectively manually rebase the branch (without the
> duplicate commits) on master and try to get the commits in to a usable
> state.

Given the little attention core-updates is currently receiving, I doubt
someone is willing to put the effort to recreate the branch from scratch
to clean its git history; at least speaking for myself I'd rather spend
the little hack time I have to work on it toward getting it finalized.

I believe how these duplicates came to exist was probably two separate
master -> core-updates merge commits, with one of them ending up being
rebased on top of the other, probably so that it could be pushed.
Perhaps we could capture in our contribution guidelines that rebasing a
merge commit should never be done to keep the history clean, and that in
a situation where:

1. a merge has been prepared locally (with conflicts resolved and all)
2. a new commit has appeared on the remote branch

the solution should be to merge the remote branch into the local one
instead of rebasing the local one on the remote one (as is usually
done). Disclaimer: I haven't actually tried this suggested approach,
which should be done before documenting it, if there's a consensus to do
so.

In other words, I suggest we document what *not* to do to avoid
repeating the same mistake in the future, and move on.

--
Thanks,
Maxim
S
S
Steve George wrote on 22 Apr 11:39 +0200
block 70456 with 67973
(address . control@debbugs.gnu.org)
1713778748-3175-bts-steve@futurile.net
block 70456 with 67973
thanks
S
S
Steve George wrote on 22 Apr 11:41 +0200
block 70456 with 45885
(address . control@debbugs.gnu.org)
1713778908-2675-bts-steve@futurile.net
block 70456 with 45885
thanks
S
S
Steve George wrote on 22 Apr 11:48 +0200
block 70456 with 40316
(address . control@debbugs.gnu.org)
1713779317-2200-bts-steve@futurile.net
block 70456 with 40316
thanks
S
S
Steve George wrote on 22 Apr 11:51 +0200
block 70456 with 68270
(address . control@debbugs.gnu.org)
1713779459-1387-bts-steve@futurile.net
block 70456 with 68270
thanks
M
M
Maxim Cournoyer wrote on 22 Apr 19:31 +0200
Re: bug#70456: Request for merging "core-updates" branch
(name . Christopher Baines)(address . mail@cbaines.net)
87sezdgv8a.fsf@gmail.com
Hi Christopher,

Christopher Baines <mail@cbaines.net> writes:

[...]

Toggle quote (6 lines)
> 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
S
S
Steve George wrote on 23 Apr 15:07 +0200
block 70456 with 46442
(address . control@debbugs.gnu.org)
1713877622-2297-bts-steve@futurile.net
block 70456 with 46442
thanks
S
S
Steve George wrote on 23 Apr 17:23 +0200
block 70456 with 70537
(address . control@debbugs.gnu.org)
1713885799-1346-bts-steve@futurile.net
block 70456 with 70537
thanks
S
S
Steve George wrote on 23 Apr 18:32 +0200
block 70456 with 39415
(address . control@debbugs.gnu.org)
1713889973-3525-bts-steve@futurile.net
block 70456 with 39415
thanks
T
L
L
Ludovic Courtès wrote on 2 May 09:53 +0200
(name . Christopher Baines)(address . mail@cbaines.net)
8734r03b11.fsf@inria.fr
Hi Chris and all,

Christopher Baines <mail@cbaines.net> skribis:

Toggle quote (16 lines)
> 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:

Toggle snippet (4 lines)
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'.

It stopped at:

Toggle snippet (3 lines)
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)

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’.
C
C
Christopher Baines wrote on 8 May 14:03 +0200
Process gnome-team before core-updates
(address . control@debbugs.gnu.org)
87pltwfr3i.fsf@cbaines.net
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.
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmY7ahFfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9Xc7hxAAjl4tflCbDrQvwjrFgZajJlTLzQeQmnrf
daUNdE2lrSKcQigosYWH8NtUpNBvD+Cw/mev20E70sxa33avWomL2/jJ/gkMPAqY
o58lj1VIlxVXPMx+1DDxq8MZsPtGsFuUyLO1hmvS8xxZu48IGy3ye1V/cAPc3Hkb
/LCSkr+u4JZV7BePSrzS0pGYxQ6ELcAZlvpb4kANoUTwNP3fnXIZI0LabwyUxCga
qgPLX8COe6gEbk0JIQFGq1maBIYSCU+Ws9wBCwUe4GDm+emdeU1rFfxKYXCFDFwh
akmE7UInARxk0gXI3+aUcpeCU5MA1eozXvIiLK2Vv9NFKF1VieQrpk3t2utZIpOh
OmYhNiVJrTWKhzHJ9U22Uj3hF+C0F13tZuDMVzwuc9Ssy/FGVQGCjmcDEGoeVxG1
XLB/wCiqGd1CPJ2kEIqDuro5VIiTNAt7R8PKa6X7l9tqH4LreigLu4Y5FvTSVCWC
dZsPSuUhPSLPROGU5bZMwq654tFosAlGfB5X1LJpvKwfLjmK2qwFy5ZdXgQwyA2p
utpk4zxEc6/bPkCzt51lFOnh3p8p9J08Keq3UT3nr+FSamr3ZsZLs0v5NeZ0VJVV
SnfPZsMCvO8Y+LdVcAqdkJTjFbvCSBeE0OWAukb6M14X0/OinhUV0V2Az65NWnnx
3O4vDn6EKR4=
=XciC
-----END PGP SIGNATURE-----

E
E
Efraim Flashner wrote on 9 Jun 11:54 +0200
Re: branch core-updates updated (c8c6883398 -> 0e06c9697a)
(name . Christopher Baines)(address . mail@cbaines.net)
ZmV706i6uTb69V1Q@3900XT
On Sun, Jun 09, 2024 at 10:46:10AM +0100, Christopher Baines wrote:
Toggle quote (29 lines)
> guix-commits@gnu.org writes:
>
> > efraim pushed a change to branch core-updates
> > in repository guix.
> >
> > from c8c6883398 gnu: dico: Add libxcrypt dependency.
> > new 9804f8c149 gnu: coeurl: Update to 0.3.1.
> > new 51c7b6d76f gnu: font-gnu-freefont: Build with newer fontforge.
> > new 0e06c9697a gnu: Remove fontforge-20190801.
> >
> > The 3 revisions listed above as "new" are entirely new to this
> > repository and will be described in separate emails. The revisions
> > listed as "add" were already present in the repository and have only
> > been added to this reference.
>
> These changes confused me as I was looking at the trying to work out why
> they needed to be pushed to core-updates. Eventually I figured out that
> Git is right, these commits are entirely new, but they duplicate
> existing commits already pushed to master (e.g. 0e06c9697a is a
> duplicate of 3d5f4b2d7dda).
>
> I know the new guidance says to "Avoid merging master in to the branch",
> but one of the reasons for that is to avoid situations just like this
> where merges are done incorrectly and commits are duplicated between
> branches.
>
> To fix this, I think we should rebase core-updates on master and drop
> these commits.

I wasn't aware I was "doing it wrong" with this, I saw that coeurl 0.3.0
failed on core-updates but a bump to 0.3.1 fixed the build, and it could
go to master also. Similar story with working to remove
fontforge-20190801 which no longer built on core-updates. I figured that
applying the patch to both branches would make it easier to merge master
into core-updates since there would be less drift between the two.

What is the correct way to apply a patch to multiple branches?

--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmZle88ACgkQQarn3Mo9
g1EPRhAAirfUI+i4zzMiooZD76weJ0GWsmBcVpvXIe4r3mMgtJ7+kKtqCBNRx9aC
D8YqyQ7hYxL1x1oEa0eg153twa+dX/hEIBYKuNGbr/Y5rwmqb4Q5Ie3aJAwkM27C
VVMzVGz1S5E1LXzV6ptX2KqLJPxISTD65OZ36m+QcGISpu1BhBpORuoD3v/PsDYF
fQ55U5N1aE+PBzZJvuYLble6Ghz7BG6xYJs+1NJPMBz0xlwWPEloOa0LhUzCpYEm
Ix3rSFm0EFK1bYWPpNRi83TvLHqbJPjWBY01njW5FnDEWFDla3KJnzzjHoagGwcV
WZ3HD6l5bOsbsf6R0Ce9qXBb/5w9jzsBer3O820a/95eMZaNenrkENWH4XcCOOXo
KjaVsm3at0bS1iZ3xzodhepE6XQ6kFpiwnpet08pusMEK7+kQfAJ7JNlN0zfm51a
J2y0Qj5JmAUdYo9A6xhKVQBKkFQlBIijpKgQ32FjFDQfJM8LjcFz4O5a+kR9T6RM
mg3AuJJsD/K8DZQqVe0ysXJqNUsY1uwKetEUuIQOBNw8EbeFXIuapWt4zfARRUAw
iYdCmGnHLnrgs9J49ZvsTQYIbCkgPUULlx9BfgXgqz6DrkW2vR20TGe8UoqI5qge
4rkuJhSoc+Oy0CtCHblbtkO8b8DmNT0wjPCQ9zONAK6nU2BBTx4=
=Ysf2
-----END PGP SIGNATURE-----


C
C
Christopher Baines wrote on 9 Jun 11:46 +0200
87jziy1mal.fsf@cbaines.net
guix-commits@gnu.org writes:

Toggle quote (13 lines)
> efraim pushed a change to branch core-updates
> in repository guix.
>
> from c8c6883398 gnu: dico: Add libxcrypt dependency.
> new 9804f8c149 gnu: coeurl: Update to 0.3.1.
> new 51c7b6d76f gnu: font-gnu-freefont: Build with newer fontforge.
> new 0e06c9697a gnu: Remove fontforge-20190801.
>
> The 3 revisions listed above as "new" are entirely new to this
> repository and will be described in separate emails. The revisions
> listed as "add" were already present in the repository and have only
> been added to this reference.

These changes confused me as I was looking at the trying to work out why
they needed to be pushed to core-updates. Eventually I figured out that
Git is right, these commits are entirely new, but they duplicate
existing commits already pushed to master (e.g. 0e06c9697a is a
duplicate of 3d5f4b2d7dda).

I know the new guidance says to "Avoid merging master in to the branch",
but one of the reasons for that is to avoid situations just like this
where merges are done incorrectly and commits are duplicated between
branches.

To fix this, I think we should rebase core-updates on master and drop
these commits.
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmZleeJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XcjMxAArwbYGwBczYAsqb1OsRC58fC9vJd+lBLV
eopXKjghcwEai0gm6J10s7KnIneIm9M6ety1TX6ELvUl4qHrj+FFi5hZTaneqcxs
+axs3SYCcZ+HWqL1lH03hGVFLJosZ273944JJxAUiCi5iRR5CbffKcukyqCt7dHG
p90M/60aDr2hsVBWj4EN3kzR5EyO9Pg3zBLJEilJ6pbokbnrxy3gGjXUtIN89fTE
9ZVkWAn52GUFYNPzNnBUEz89DgNqlcavL3oGSwuG6x6ge8q9LrHHC/5zlyhif1iO
8blg5RxO2tZfta6OEP2HfOz3ewJCyjoi7OWjKJ6Z38RGECTaLq5ZU+FNkLp/H0Lr
J4MUGvC66XzQzCdH60SBdUtnCpgv3PqnodUBP8QXdzRJhvd24jCxVS2/76RML1Od
HUih7PDwGqFa6DvSCkbekIGN+w910MtCTHhgdmVBr8/t9cBzhmYuqJ2TcC7yJfgI
d+Ag8jOScFfweIX2yLYbQpsrKsJ50cjJz1d0cHkvBU5V11xt7sVKiBWSSHQYR9P+
pSd6gnscxbGq1HTEeIcZRzak5+8AH32CLC2pohuwwKU8ACaKSWhZwPQbuqb8Tp+3
GaYkjLb7208Thm5uMJt+1CxOy6bxTjquwxFjkl5i/1PnY5yMQj5QDWvH0MupM3GX
wa8CFnqFbN8=
=Cecn
-----END PGP SIGNATURE-----

C
C
Christopher Baines wrote on 9 Jun 12:20 +0200
(address . 70456@debbugs.gnu.org)
87frtm1koq.fsf@cbaines.net
Efraim Flashner <efraim@flashner.co.il> writes:

Toggle quote (37 lines)
> On Sun, Jun 09, 2024 at 10:46:10AM +0100, Christopher Baines wrote:
>> guix-commits@gnu.org writes:
>>
>> > efraim pushed a change to branch core-updates
>> > in repository guix.
>> >
>> > from c8c6883398 gnu: dico: Add libxcrypt dependency.
>> > new 9804f8c149 gnu: coeurl: Update to 0.3.1.
>> > new 51c7b6d76f gnu: font-gnu-freefont: Build with newer fontforge.
>> > new 0e06c9697a gnu: Remove fontforge-20190801.
>> >
>> > The 3 revisions listed above as "new" are entirely new to this
>> > repository and will be described in separate emails. The revisions
>> > listed as "add" were already present in the repository and have only
>> > been added to this reference.
>>
>> These changes confused me as I was looking at the trying to work out why
>> they needed to be pushed to core-updates. Eventually I figured out that
>> Git is right, these commits are entirely new, but they duplicate
>> existing commits already pushed to master (e.g. 0e06c9697a is a
>> duplicate of 3d5f4b2d7dda).
>>
>> I know the new guidance says to "Avoid merging master in to the branch",
>> but one of the reasons for that is to avoid situations just like this
>> where merges are done incorrectly and commits are duplicated between
>> branches.
>>
>> To fix this, I think we should rebase core-updates on master and drop
>> these commits.
>
> I wasn't aware I was "doing it wrong" with this, I saw that coeurl 0.3.0
> failed on core-updates but a bump to 0.3.1 fixed the build, and it could
> go to master also. Similar story with working to remove
> fontforge-20190801 which no longer built on core-updates. I figured that
> applying the patch to both branches would make it easier to merge master
> into core-updates since there would be less drift between the two.

You're right regarding drift, but unfortunately I think this duplication
of commits creates merge conflicts, or at least makes them much more
likely.

Toggle quote (2 lines)
> What is the correct way to apply a patch to multiple branches?

I'd frame the problem differently, we don't want multiple branches, we
want everything on master. Unfortunately for some changes that is hard
to test and creates too much churn, so for those changes they go to a
branch where they can be built and tested prior to pushing/merging them
to master.

To avoid changes happening on a topic branch and master, I think it's
important that any change that can be made on master, is made on
master. That should avoid the problem where someone else comes along and
doesn't realise a change has been made on core-updates, and duplicates
that on master. In this instance, you pushed the changes to master,
which is great.

I realise it does require more up front effort, but if you see a failing
build on a topic branch that's fixed by some change on master, the topic
branch should be rebased to include those changes. Providing it's done
correctly, merging should be fine as well, but the docs now say to avoid
that and prefer rebasing (mostly because of how merging has introduced
duplicate commits in to core-updates)

This rebasing or merging will minimise the drift between the two
branches as well, while avoiding Git conflicts and commit duplication.

So I don't think we want to be applying patches to multiple branches. If
it can be applied to master, it should be applied there, then all the
branches should be rebased to include it.

Does that make sense? This isn't really a "doing it wrong" thing, more
that we need to try and optimise the process for managing branches. I
haven't got a concise definition of what we're trying to optimise for,
but in this instance we want to avoid Git issues like merge conflicts
and avoid duplication and complexity by making changes that can be made
on master, just on master.
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmZlggVfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XfRJQ/7B6KRFV4aTJhTsvzsx3XFBp2aMS1VWIOX
hVOuEC89bMqixerzfBe7dPqyt/8SYPetD3dV2EHR5MqPrpQO1r0e5T9yJlab3ehc
Wy+JIQySy3KbtiSH4dDILyld/sJ7TVbC/YS/zBFPghFT+/egV0DzOvasvFUNKLzS
ggzMDJxT5SssgQMAV2SnNOV9FDEkw4Ubmk0nqeladGTzAm4n1ajMomMNAlw8dV9y
/TOnwevnuIKY6lx0aY52Y6qpiLGh510Nc8xaPQqXkBtulGq1Tes8s4nmft7zkNg3
vKRYThfPJ2ymMXtPZmpmNqB/Iy0pdO/g1TX6e5lYq+eXqoq9qLFPURAKrAt1w9B8
2ri8dpRO7WinKVr/g9k6XNf4r2HaUCtqxYpTxrUQnyFR0VJL+tli22CAJ39eLNfJ
gKS3dCnhJyfCSAL43wWdcShIzNjIiHLfPOEvQor7P6lkYi7n5/8EUaPGm8yH2wWY
bSvRefUanIx9Edv8mjVgMMmfUnyQ/9iRiapOkKxmf80y39aNlJSWk2MOTvdwP3v3
5P8Q7IdVg+Wt/xerUdnPrLcZfUuQn0sPSvZRW4zRIGF7xA6ufn4spj0ptnyCqLZN
utYJUQIre3WKMJPsicYY6DSFOl0QxmQFttX52/H2quG/9/b2LfR0J+dsgVX7pfoO
R53lYSeUIQ4=
=vWmK
-----END PGP SIGNATURE-----

C
C
Christopher Baines wrote on 9 Jun 13:34 +0200
(address . 70456@debbugs.gnu.org)
87bk4a1hav.fsf@cbaines.net
Christopher Baines <mail@cbaines.net> writes:

Toggle quote (32 lines)
> Efraim Flashner <efraim@flashner.co.il> writes:
>
>> On Sun, Jun 09, 2024 at 10:46:10AM +0100, Christopher Baines wrote:
>>> guix-commits@gnu.org writes:
>>>
>>> > efraim pushed a change to branch core-updates
>>> > in repository guix.
>>> >
>>> > from c8c6883398 gnu: dico: Add libxcrypt dependency.
>>> > new 9804f8c149 gnu: coeurl: Update to 0.3.1.
>>> > new 51c7b6d76f gnu: font-gnu-freefont: Build with newer fontforge.
>>> > new 0e06c9697a gnu: Remove fontforge-20190801.
>>> >
>>> > The 3 revisions listed above as "new" are entirely new to this
>>> > repository and will be described in separate emails. The revisions
>>> > listed as "add" were already present in the repository and have only
>>> > been added to this reference.
>>>
>>> These changes confused me as I was looking at the trying to work out why
>>> they needed to be pushed to core-updates. Eventually I figured out that
>>> Git is right, these commits are entirely new, but they duplicate
>>> existing commits already pushed to master (e.g. 0e06c9697a is a
>>> duplicate of 3d5f4b2d7dda).
>>>
>>> I know the new guidance says to "Avoid merging master in to the branch",
>>> but one of the reasons for that is to avoid situations just like this
>>> where merges are done incorrectly and commits are duplicated between
>>> branches.
>>>
>>> To fix this, I think we should rebase core-updates on master and drop
>>> these commits.

I've gone ahead and done this now.
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmZlkyhfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9Xd3ZA//QUoZ/+12ZmuM6NyKrlnUYfIBCadz4gss
Grz+rZPmjuj/huq7S45CADUD1opz425CIOqq0MSA88myPJGqyCl1uqakTyJ9ipS1
O8OT5lp73xqPWhqQnkNzD9huOOyT9LVvDZ7Lpz0ggI81DtfYoEC2eC0fGbJ7wIpy
Bq+pk5C86YoiYW1F5jurJHClFLp8rARBb8+dKE/Xvirj74AwjLY0i9ISWVAb3kZR
MRPPyZhgoMqS2K9E9Z7Ox7zMHuyxh29geEsJWEURmYEmgqndbcy0TYBUMEiGL0RZ
R8vnYYJPOADnFme5CLxSVhp/1ebc8Yb9O6HZoTGHYeZFD5p+y308qPgzejB366fR
QvsOqtrzM9VIpTbdnCwiRZFGJ/fzwPRFpor7QP6K+UtkGOLn/GgKZ2us6Q768AZV
xQ4KvPkZj88AFCvC2sPbQmiFyLD4ggvL74eEUlkRPw0LKXz2NSxv0K85FsZg1SFp
VphDmj8le1FZZUEVItyhTzHaeIYNGIictYzLUorw7SGvxl1qZexLd5m+GpDmxGFR
4Gz1OPSiAXJJfar77uyhHCBnG0Zm4ZF78/mVlvD1aiBdcpXuwBjD+rUCWuTEI+M+
0ZwuUM7NslFeknc4jbHJiL//s0vyjSOXtfx3N4L3/HUAIBa4KkqGulwVRloEkp3m
gxyZoN4g410=
=jAYw
-----END PGP SIGNATURE-----

L
L
Lars-Dominik Braun wrote on 14 Jun 08:30 +0200
Re: Request for merging core-updates branch
(name . Steve George)(address . steve@futurile.net)
ZmvjnvQ9K37K938Q@noor.fritz.box
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
G
G
Guillaume Le Vaillant wrote on 14 Jun 09:55 +0200
Re: bug#70456: Request for merging core-updates branch
(name . Lars-Dominik Braun)(address . lars@6xq.net)
87cyokt0v1.fsf@kitej
Lars-Dominik Braun <lars@6xq.net> skribis:

Toggle quote (9 lines)
> 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.
-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCZmv3Yg8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j+6xAD/X6AXpCySJa55Cn848tSt3i01ZqEbyfwEFTka
VQ9NlA4A/2UyU10yXlMr95Ybrn+JHOLcNalAvS5hGk84BlAUXX94
=zc2X
-----END PGP SIGNATURE-----

M
M
Maxim Cournoyer wrote 6 days ago
(name . Guillaume Le Vaillant)(address . glv@posteo.net)
87jzinwdl5.fsf@gmail.com
Hi,

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

Toggle quote (14 lines)
> 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
G
G
Guillaume Le Vaillant wrote 6 days ago
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
874j9rgw4e.fsf@kitej
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

Toggle quote (22 lines)
> 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).
-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCZnCaYQ8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j849AD+PKnovStS23LN8FMbYiKcBMT5kRopWgbmI636
YqPoEHQA/2S+0bkCsm14khKIcoTLNosuJxqzo2EXWx9pMJrtSq6Q
=ERdq
-----END PGP SIGNATURE-----

?
?
??? wrote 6 days ago
core-updates failed package: time
(address . 70456@debbugs.gnu.org)
87bk3zgfpm.fsf@envs.net
time-1.9 fail its test on core-updates:

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?
?
?
??? wrote 6 days ago
core-updates failed package: libfaketime for i686-linux
(address . 70456@debbugs.gnu.org)
875xu63d2a.fsf_-_@envs.net
??? <iyzsong@envs.net> writes:

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



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

I have no idea how to fix this, help need!
M
M
Maxim Cournoyer wrote 5 days ago
Re: bug#70456: Request for merging core-updates branch
(name . Guillaume Le Vaillant)(address . glv@posteo.net)
87cyoee9am.fsf@gmail.com
Hi,

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

Toggle quote (31 lines)
> 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
C
C
Christopher Baines wrote 2 days ago
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87msne2ury.fsf@cbaines.net
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (20 lines)
> 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.
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmZ1mLJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9Xf8Aw//fluiB4w8wFG5Y+Ny1gt1AkCR49R4C82q
Y7rtmUuAVkgHssdjoa/pZFwcsi6fqK35LsnbsIXbjN9p8u4hQwBnbOKxUCvGRmjj
fmuRIsmIK+U5QdmftSanI2orWDBHfyxddACBcL5klsuoKmcw8xRBAURFGRkVwZDw
sEP5EupzkMI5FpTIPJBAZvjJLuX6viFsw3rNztupduL2uwoIsYvIdChWEyRPh5+j
JraskfUa1ueMeWEtTNF1kwFgkB25J9x0nOLlr4d2X2WaIOtgrOGrGZNJtm42Tsy9
3kk99Fkpq/fo1hPXm9gAAF21f3JdWdS/I443fvW7ur5KzEbQDBgS09jeTjBlemUO
It05ckT/axsM16HuHuF92atkhVmxCqgy6QWGCu1JdHE4G8U4zjjikNXHcl1ad5+o
/j3KHIipsronvaBgqBjofeGaB8wJH/FzHIOqQiOFUDThoS5TAn1X9ZyrTKqWakIJ
75RP7Brq0b+Bcq0SXOCXyaJphKFczKRMheVMI2oqVYlT4ucwU1LjRpRKy8aefSPW
er0GPq4MSCRc+dpiQGZIEvEzQTBKGJ8mHEcwqyEEKmagTsSs5bbGjV8qWj9NNtFM
inUcDBuBfd68gnF1pAZYyDn7xSlrG+pJM8tpvjdLXsLe0mAdsD3zZcsidbZXXTHc
uSQJn6VQ3pg=
=Aw5N
-----END PGP SIGNATURE-----

C
C
Christopher Baines wrote 25 hours ago
Re: Request for merging "core-updates" branch
(address . 70456@debbugs.gnu.org)
87msnc6ac8.fsf@cbaines.net
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.


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
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmZ3JydfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9Xc5lQ/5Ae3JbQsxWHBBkpWszk+EBbKkjgixtfKj
59TSRPyFP/4q0QzD4sX8p0pZpJUh6NTtHGJDc9nbvteyotdXiZEg9Q6GpRQ0jCQN
/5HRkFj2ILh0+j1+akK1x5iA92gZoUvtgzJE1Mv3DwHxNVyP5cKHCh1XRyZ5x4vA
Q67UdCaBWJB6yztEkYJuJiEpwX5pjCFlT06P4pC7iHD4FvrVAcgkxxTZnxTs4kR9
SDO9yIfJrSN4pQPNk5sQYMQ4fRXHRez5T28/2RpbgPi1c8njpVtid3+kQuW0huMH
eVYkHUnnl83JIId4hw+JcbxT+aHunC1CEuIjf7JoqO8aQ6ZR/XKIeigA4iHb2nQ0
+Gt/juN6K46uuGtxjC+9BjPM+A/RzHKNojeP24F5El9bWbastqqpoW1u1Bae45W5
UT1s7cNrZ5TeTrD6YOj8u/R15CHJvndV2jtIoDhvat0aMIaygJr/SFpPnKUXg1Rt
jg0l/Mf63v5hIeBA0wg+StH0Ld/XiN6v8RPXjpqE4EETW8mpFIcAmfLS53G4azn0
Wn0WaMtXrFqBhwEm3CaQ8nBTYN1iFTj4sJhc5VW701qG7ViQNxwXdEdKw47SUTcu
W2wCrfrtlx3yiU+bxGjaAeKZ9zxSE3lvoiUZ+URz2iHjKcYY3ID+T52vhf1tLYJO
aIhAvccrt8g=
=pezN
-----END PGP SIGNATURE-----

?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 70456@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 70456
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch