* Status of ‘core-updates’ @ 2024-03-24 11:21 Ludovic Courtès 2024-03-30 10:55 ` Josselin Poiret 2024-04-20 11:14 ` Christopher Baines 0 siblings, 2 replies; 24+ messages in thread From: Ludovic Courtès @ 2024-03-24 11:21 UTC (permalink / raw) To: Josselin Poiret; +Cc: Guix Devel Hello! 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. Thanks, Ludo’. ¹ https://lists.gnu.org/archive/html/guix-devel/2024-01/msg00096.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Status of ‘core-updates’ 2024-03-24 11:21 Status of ‘core-updates’ Ludovic Courtès @ 2024-03-30 10:55 ` Josselin Poiret 2024-04-10 14:39 ` Ludovic Courtès 2024-04-20 11:14 ` Christopher Baines 1 sibling, 1 reply; 24+ messages in thread From: Josselin Poiret @ 2024-03-30 10:55 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Guix Devel [-- Attachment #1: Type: text/plain, Size: 1142 bytes --] Hi Ludo, Ludovic Courtès <ludo@gnu.org> writes: > What’s the status of ‘core-updates’? What are the areas where help is > needed? Disclaimer: I've been quite busy with work recently and haven't been able to work on core-updates that much (having to build the world locally doesn't help). Currently, the desktop system image doesn't build anymore because we've also integrated patches to use pkgconf instead of pkg-config. I think the effort to actually make that work with all of our packages is going to be a bit too much to handle right now. IMO, we should probably revert/branch out before then so that we can push core-updates past the finish line. A feature branch to integrate pkgconf properly could then be worked on later. Other than that, I was able to get a working desktop before the aforementioned patches but with some locale errors that I fixed with ae07bc2dd0124b625acf70e594ccc90d6d128562, so I'm not expecting too much trouble. We'll probably have to add libxcrypt as an input to some other packages that I haven't tested yet, but that's quite trivial. Best, -- Josselin Poiret [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 682 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Status of ‘core-updates’ 2024-03-30 10:55 ` Josselin Poiret @ 2024-04-10 14:39 ` Ludovic Courtès 2024-04-11 10:18 ` Steve George 0 siblings, 1 reply; 24+ messages in thread From: Ludovic Courtès @ 2024-04-10 14:39 UTC (permalink / raw) To: Josselin Poiret; +Cc: Guix Devel Hello! Josselin Poiret <dev@jpoiret.xyz> skribis: > Disclaimer: I've been quite busy with work recently and haven't been > able to work on core-updates that much (having to build the world > locally doesn't help). No problem. We should find someone willing to pick up the coordination work for the coming month or so. Any volunteer? :-) To be clear (but I guess it’s crystal clear to anyone who’s been around long enough :-)), what we need most is someone to keep track of changes, coordinate efforts, decide what goes in the branch and what’s postponed or moved to a separate branch, and send periodic (weekly) status updates over the course of a couple of months. This can (and probably should) be done without doing any actual hacking on the branch. > Currently, the desktop system image doesn't build anymore because we've > also integrated patches to use pkgconf instead of pkg-config. I think > the effort to actually make that work with all of our packages is going > to be a bit too much to handle right now. IMO, we should probably > revert/branch out before then so that we can push core-updates past the > finish line. A feature branch to integrate pkgconf properly could then > be worked on later. Last time we discussed it on IRC, you were in the process of putting up a branch without those pkgconf changes, IIRC. Were you able to complete that work? If not, I guess that’ll be the first thing to do, unless someone has a better idea. > Other than that, I was able to get a working desktop before the > aforementioned patches but with some locale errors that I fixed with > ae07bc2dd0124b625acf70e594ccc90d6d128562, so I'm not expecting too much > trouble. We'll probably have to add libxcrypt as an input to some other > packages that I haven't tested yet, but that's quite trivial. Alright. Thanks for all the work so far! Ludo’. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Status of ‘core-updates’ 2024-04-10 14:39 ` Ludovic Courtès @ 2024-04-11 10:18 ` Steve George 2024-04-12 20:21 ` Ludovic Courtès 0 siblings, 1 reply; 24+ messages in thread From: Steve George @ 2024-04-11 10:18 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Josselin Poiret, Guix Devel On 10 Apr, Ludovic Courtès wrote: > Hello! > > Josselin Poiret <dev@jpoiret.xyz> skribis: > > > Disclaimer: I've been quite busy with work recently and haven't been > > able to work on core-updates that much (having to build the world > > locally doesn't help). > > No problem. We should find someone willing to pick up the coordination > work for the coming month or so. Any volunteer? :-) > > To be clear (but I guess it’s crystal clear to anyone who’s been around > long enough :-)), what we need most is someone to keep track of changes, > coordinate efforts, decide what goes in the branch and what’s postponed > or moved to a separate branch, and send periodic (weekly) status updates > over the course of a couple of months. This can (and probably should) > be done without doing any actual hacking on the branch. (...) This sounds like something I can do: - track changes (in branch) - co-ordinate blocking issues (in bug system) - co-ordinate with people doing the actual work :-P - send (periodic) weekly emails - encourage shipping by minimising scope creep ;-) Sounds like there's already agreement to revert the 'pkgconf' change and push a new branch without them which becomes 'core-updates'. Josselin on IRC I had the impression you were working on that? Thanks, ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Status of ‘core-updates’ 2024-04-11 10:18 ` Steve George @ 2024-04-12 20:21 ` Ludovic Courtès 2024-04-17 17:47 ` Maxim Cournoyer 0 siblings, 1 reply; 24+ messages in thread From: Ludovic Courtès @ 2024-04-12 20:21 UTC (permalink / raw) To: Steve George; +Cc: Josselin Poiret, Guix Devel, maxim.cournoyer Hi Steve, Steve George <steve@futurile.net> skribis: > On 10 Apr, Ludovic Courtès wrote: [...] >> To be clear (but I guess it’s crystal clear to anyone who’s been around >> long enough :-)), what we need most is someone to keep track of changes, >> coordinate efforts, decide what goes in the branch and what’s postponed >> or moved to a separate branch, and send periodic (weekly) status updates >> over the course of a couple of months. This can (and probably should) >> be done without doing any actual hacking on the branch. > (...) > > This sounds like something I can do: > > - track changes (in branch) > - co-ordinate blocking issues (in bug system) > - co-ordinate with people doing the actual work :-P > - send (periodic) weekly emails > - encourage shipping by minimising scope creep ;-) Awesome, thanks for volunteering! > Sounds like there's already agreement to revert the 'pkgconf' change and push a new branch without them which becomes 'core-updates'. Josselin on IRC I had the impression you were working on that? I’m not sure what the situation is (I see Maxim just pushed changes on top of current ‘core-updates’, so maybe it’s OK?). Josselin, Maxim: could you explain what problems there are around pkgconf and what you would recommend? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Status of ‘core-updates’ 2024-04-12 20:21 ` Ludovic Courtès @ 2024-04-17 17:47 ` Maxim Cournoyer 2024-04-17 22:52 ` Felix Lechner via Development of GNU Guix and the GNU System distribution. ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Maxim Cournoyer @ 2024-04-17 17:47 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Steve George, Josselin Poiret, Guix Devel Hello, Ludovic Courtès <ludo@gnu.org> writes: > Hi Steve, > > Steve George <steve@futurile.net> skribis: > >> On 10 Apr, Ludovic Courtès wrote: > > [...] > >>> To be clear (but I guess it’s crystal clear to anyone who’s been around >>> long enough :-)), what we need most is someone to keep track of changes, >>> coordinate efforts, decide what goes in the branch and what’s postponed >>> or moved to a separate branch, and send periodic (weekly) status updates >>> over the course of a couple of months. This can (and probably should) >>> be done without doing any actual hacking on the branch. >> (...) >> >> This sounds like something I can do: >> >> - track changes (in branch) >> - co-ordinate blocking issues (in bug system) >> - co-ordinate with people doing the actual work :-P >> - send (periodic) weekly emails >> - encourage shipping by minimising scope creep ;-) > > Awesome, thanks for volunteering! > >> Sounds like there's already agreement to revert the 'pkgconf' change >> and push a new branch without them which becomes >> 'core-updates'. Josselin on IRC I had the impression you were >> working on that? > > I’m not sure what the situation is (I see Maxim just pushed changes on > top of current ‘core-updates’, so maybe it’s OK?). Since branches were merged in, I believe the problem we are facing at the moment is librsvg failing its test suite with a segfault (!). Could be the glibc upgrade, or rust itself, I'm not sure. I was trying to upgrade librsvg, which needs an update anyway, but it pulls many rust crates updates. I'll get there eventually, if nobody beats me to it. > Josselin, Maxim: could you explain what problems there are around > pkgconf and what you would recommend? Nothing in particular to point at the moment, but remaining problems would manifest in the form of missing inputs, due to transitive libtool dependencies causing overlinking and the new pkgconf being smart enough to optimize away some previously captured link directives that would be baked in the RUNPATH and sastify libtool overlinking needs. The solution is to hunt the libtool .la files from the transitive dependencies causing the problem and removing them. See commit b6540bd285cbe5920ad379ddfc6256359ee7204c for an example. -- Thanks, Maxim ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Status of ‘core-updates’ 2024-04-17 17:47 ` Maxim Cournoyer @ 2024-04-17 22:52 ` Felix Lechner via Development of GNU Guix and the GNU System distribution. 2024-04-19 14:13 ` Ludovic Courtès 2024-04-22 16:20 ` Efraim Flashner 2 siblings, 0 replies; 24+ messages in thread From: Felix Lechner via Development of GNU Guix and the GNU System distribution. @ 2024-04-17 22:52 UTC (permalink / raw) To: Maxim Cournoyer, Ludovic Courtès Cc: Steve George, Josselin Poiret, Guix Devel Hi Maxim, On Wed, Apr 17 2024, Maxim Cournoyer wrote: > The solution is to hunt the libtool .la files Would my old web-based file finder, which I could resurrect, help with locating such files? Kind regards Felix ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Status of ‘core-updates’ 2024-04-17 17:47 ` Maxim Cournoyer 2024-04-17 22:52 ` Felix Lechner via Development of GNU Guix and the GNU System distribution. @ 2024-04-19 14:13 ` Ludovic Courtès 2024-04-19 15:22 ` Maxim Cournoyer 2024-04-22 16:20 ` Efraim Flashner 2 siblings, 1 reply; 24+ messages in thread From: Ludovic Courtès @ 2024-04-19 14:13 UTC (permalink / raw) To: Maxim Cournoyer; +Cc: Steve George, Josselin Poiret, Guix Devel Hi Maxim, Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > Since branches were merged in, I believe the problem we are facing at > the moment is librsvg failing its test suite with a segfault (!). Could > be the glibc upgrade, or rust itself, I'm not sure. I was trying to > upgrade librsvg, which needs an update anyway, but it pulls many rust > crates updates. I'll get there eventually, if nobody beats me to it. Ouch, OK. I guess it doesn’t hurt if several of us take a look and we share our findings here. >> Josselin, Maxim: could you explain what problems there are around >> pkgconf and what you would recommend? > > Nothing in particular to point at the moment, but remaining problems > would manifest in the form of missing inputs, due to transitive libtool > dependencies causing overlinking and the new pkgconf being smart enough > to optimize away some previously captured link directives that would be > baked in the RUNPATH and sastify libtool overlinking needs. > > The solution is to hunt the libtool .la files from the transitive > dependencies causing the problem and removing them. See commit > b6540bd285cbe5920ad379ddfc6256359ee7204c for an example. Good. So it seems like we can move forward after all and just do the “normal” job and finding and fixing build failures along these lines. Do we need ci.guix to build more packages to facilitate testing and debugging? That’s something I can help with (though I’ll be away for a week). Thank you for explaining, Ludo’. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Status of ‘core-updates’ 2024-04-19 14:13 ` Ludovic Courtès @ 2024-04-19 15:22 ` Maxim Cournoyer 0 siblings, 0 replies; 24+ messages in thread From: Maxim Cournoyer @ 2024-04-19 15:22 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Steve George, Josselin Poiret, Guix Devel Hi Ludo, Ludovic Courtès <ludo@gnu.org> writes: > Hi Maxim, > > Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > >> Since branches were merged in, I believe the problem we are facing at >> the moment is librsvg failing its test suite with a segfault (!). Could >> be the glibc upgrade, or rust itself, I'm not sure. I was trying to >> upgrade librsvg, which needs an update anyway, but it pulls many rust >> crates updates. I'll get there eventually, if nobody beats me to it. > > Ouch, OK. I guess it doesn’t hurt if several of us take a look and we > share our findings here. > >>> Josselin, Maxim: could you explain what problems there are around >>> pkgconf and what you would recommend? >> >> Nothing in particular to point at the moment, but remaining problems >> would manifest in the form of missing inputs, due to transitive libtool >> dependencies causing overlinking and the new pkgconf being smart enough >> to optimize away some previously captured link directives that would be >> baked in the RUNPATH and sastify libtool overlinking needs. >> >> The solution is to hunt the libtool .la files from the transitive >> dependencies causing the problem and removing them. See commit >> b6540bd285cbe5920ad379ddfc6256359ee7204c for an example. > > Good. So it seems like we can move forward after all and just do the > “normal” job and finding and fixing build failures along these lines. > > Do we need ci.guix to build more packages to facilitate testing and > debugging? That’s something I can help with (though I’ll be away for a > week). If we do this, and I believe it'd be useful, I think it'd help to fork a 'core-updates-frozen' and have the CI rebuild this one fully, leaving 'core-updates' open to business as usual. -- Thanks, Maxim ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Status of ‘core-updates’ 2024-04-17 17:47 ` Maxim Cournoyer 2024-04-17 22:52 ` Felix Lechner via Development of GNU Guix and the GNU System distribution. 2024-04-19 14:13 ` Ludovic Courtès @ 2024-04-22 16:20 ` Efraim Flashner 2 siblings, 0 replies; 24+ messages in thread From: Efraim Flashner @ 2024-04-22 16:20 UTC (permalink / raw) To: Maxim Cournoyer Cc: Ludovic Courtès, Steve George, Josselin Poiret, Guix Devel [-- Attachment #1: Type: text/plain, Size: 3194 bytes --] On Wed, Apr 17, 2024 at 01:47:49PM -0400, Maxim Cournoyer wrote: > Hello, > > Ludovic Courtès <ludo@gnu.org> writes: > > > Hi Steve, > > > > Steve George <steve@futurile.net> skribis: > > > >> On 10 Apr, Ludovic Courtès wrote: > > > > [...] > > > >>> To be clear (but I guess it’s crystal clear to anyone who’s been around > >>> long enough :-)), what we need most is someone to keep track of changes, > >>> coordinate efforts, decide what goes in the branch and what’s postponed > >>> or moved to a separate branch, and send periodic (weekly) status updates > >>> over the course of a couple of months. This can (and probably should) > >>> be done without doing any actual hacking on the branch. > >> (...) > >> > >> This sounds like something I can do: > >> > >> - track changes (in branch) > >> - co-ordinate blocking issues (in bug system) > >> - co-ordinate with people doing the actual work :-P > >> - send (periodic) weekly emails > >> - encourage shipping by minimising scope creep ;-) > > > > Awesome, thanks for volunteering! > > > >> Sounds like there's already agreement to revert the 'pkgconf' change > >> and push a new branch without them which becomes > >> 'core-updates'. Josselin on IRC I had the impression you were > >> working on that? > > > > I’m not sure what the situation is (I see Maxim just pushed changes on > > top of current ‘core-updates’, so maybe it’s OK?). > > Since branches were merged in, I believe the problem we are facing at > the moment is librsvg failing its test suite with a segfault (!). Could > be the glibc upgrade, or rust itself, I'm not sure. I was trying to > upgrade librsvg, which needs an update anyway, but it pulls many rust > crates updates. I'll get there eventually, if nobody beats me to it. I personally think getting librsvg updated will be easier on the rust-team branch than on the core-updates branch, since there have been many commits to the rust-team branch that haven't yet been merged into master. Assuming that now that the cairo upgrade to 1.18 was what was holding back the librsvg upgrade, I can get librsvg up to a newer version and then submit it for a merge. Overall the branch should be in fairly good shape. > > Josselin, Maxim: could you explain what problems there are around > > pkgconf and what you would recommend? > > Nothing in particular to point at the moment, but remaining problems > would manifest in the form of missing inputs, due to transitive libtool > dependencies causing overlinking and the new pkgconf being smart enough > to optimize away some previously captured link directives that would be > baked in the RUNPATH and sastify libtool overlinking needs. > > The solution is to hunt the libtool .la files from the transitive > dependencies causing the problem and removing them. See commit > b6540bd285cbe5920ad379ddfc6256359ee7204c for an example. > > -- > Thanks, > Maxim > -- 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Status of ‘core-updates’ 2024-03-24 11:21 Status of ‘core-updates’ Ludovic Courtès 2024-03-30 10:55 ` Josselin Poiret @ 2024-04-20 11:14 ` Christopher Baines 2024-04-20 21:15 ` Maxim Cournoyer 2024-05-02 7:53 ` bug#70456: Request for merging "core-updates" branch Ludovic Courtès 1 sibling, 2 replies; 24+ messages in thread From: Christopher Baines @ 2024-04-20 11:14 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Maxim Cournoyer, Josselin Poiret, Guix Devel, 70456 [-- Attachment #1: Type: text/plain, Size: 2017 bytes --] 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. 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 987 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Status of ‘core-updates’ 2024-04-20 11:14 ` Christopher Baines @ 2024-04-20 21:15 ` Maxim Cournoyer 2024-05-02 7:53 ` bug#70456: Request for merging "core-updates" branch Ludovic Courtès 1 sibling, 0 replies; 24+ messages in thread From: Maxim Cournoyer @ 2024-04-20 21:15 UTC (permalink / raw) To: Christopher Baines Cc: Ludovic Courtès, Josselin Poiret, Guix Devel, 70456 Hi Christopher, Christopher Baines <mail@cbaines.net> writes: > 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. > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: bug#70456: Request for merging "core-updates" branch 2024-04-20 11:14 ` Christopher Baines 2024-04-20 21:15 ` Maxim Cournoyer @ 2024-05-02 7:53 ` Ludovic Courtès 1 sibling, 0 replies; 24+ messages in thread From: Ludovic Courtès @ 2024-05-02 7:53 UTC (permalink / raw) To: Christopher Baines; +Cc: Guix Devel, Josselin Poiret, 70456, Maxim Cournoyer 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’. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#70456: Request for merging core-updates branch @ 2024-04-18 14:56 Steve George 2024-04-19 14:42 ` bug#70456: Request for merging "core-updates" branch Christopher Baines ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Steve George @ 2024-04-18 14:56 UTC (permalink / raw) To: 70456 Let's see where we are with the branch currently. Thanks, Steve / Futurile ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#70456: Request for merging "core-updates" branch 2024-04-18 14:56 bug#70456: Request for merging core-updates branch Steve George @ 2024-04-19 14:42 ` Christopher Baines 2024-04-19 17:00 ` Christopher Baines 2024-04-26 14:44 ` tumashu 2024-06-14 6:30 ` bug#70456: Request for merging core-updates branch Lars-Dominik Braun 2 siblings, 1 reply; 24+ messages in thread From: Christopher Baines @ 2024-04-19 14:42 UTC (permalink / raw) To: 70456, steve [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#70456: Request for merging "core-updates" branch 2024-04-19 14:42 ` bug#70456: Request for merging "core-updates" branch Christopher Baines @ 2024-04-19 17:00 ` Christopher Baines 2024-04-20 16:16 ` Maxim Cournoyer 0 siblings, 1 reply; 24+ messages in thread From: Christopher Baines @ 2024-04-19 17:00 UTC (permalink / raw) To: 70456; +Cc: Maxim Cournoyer, steve [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#70456: Request for merging "core-updates" branch 2024-04-19 17:00 ` Christopher Baines @ 2024-04-20 16:16 ` Maxim Cournoyer 2024-04-20 18:08 ` Christopher Baines 0 siblings, 1 reply; 24+ messages in thread From: Maxim Cournoyer @ 2024-04-20 16:16 UTC (permalink / raw) To: Christopher Baines; +Cc: 70456, steve 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#70456: Request for merging "core-updates" branch 2024-04-20 16:16 ` Maxim Cournoyer @ 2024-04-20 18:08 ` Christopher Baines 2024-04-22 17:31 ` Maxim Cournoyer 0 siblings, 1 reply; 24+ messages in thread From: Christopher Baines @ 2024-04-20 18:08 UTC (permalink / raw) To: Maxim Cournoyer; +Cc: 70456, steve [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#70456: Request for merging "core-updates" branch 2024-04-20 18:08 ` Christopher Baines @ 2024-04-22 17:31 ` Maxim Cournoyer 0 siblings, 0 replies; 24+ messages in thread From: Maxim Cournoyer @ 2024-04-22 17:31 UTC (permalink / raw) To: Christopher Baines; +Cc: 70456, steve 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#70456: Request for merging "core-updates" branch 2024-04-18 14:56 bug#70456: Request for merging core-updates branch Steve George 2024-04-19 14:42 ` bug#70456: Request for merging "core-updates" branch Christopher Baines @ 2024-04-26 14:44 ` tumashu 2024-06-14 6:30 ` bug#70456: Request for merging core-updates branch Lars-Dominik Braun 2 siblings, 0 replies; 24+ messages in thread From: tumashu @ 2024-04-26 14:44 UTC (permalink / raw) To: 70456 [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#70456: Request for merging core-updates branch 2024-04-18 14:56 bug#70456: Request for merging core-updates branch Steve George 2024-04-19 14:42 ` bug#70456: Request for merging "core-updates" branch Christopher Baines 2024-04-26 14:44 ` tumashu @ 2024-06-14 6:30 ` Lars-Dominik Braun 2024-06-14 7:55 ` Guillaume Le Vaillant 2 siblings, 1 reply; 24+ messages in thread From: Lars-Dominik Braun @ 2024-06-14 6:30 UTC (permalink / raw) To: Steve George; +Cc: ludo, mail, 70456, maxim.cournoyer, efraim 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#70456: Request for merging core-updates branch 2024-06-14 6:30 ` bug#70456: Request for merging core-updates branch Lars-Dominik Braun @ 2024-06-14 7:55 ` Guillaume Le Vaillant 2024-06-17 19:53 ` Maxim Cournoyer 0 siblings, 1 reply; 24+ messages in thread From: Guillaume Le Vaillant @ 2024-06-14 7:55 UTC (permalink / raw) To: Lars-Dominik Braun Cc: Steve George, maxim.cournoyer, ludo, mail, efraim, 70456 [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#70456: Request for merging core-updates branch 2024-06-14 7:55 ` Guillaume Le Vaillant @ 2024-06-17 19:53 ` Maxim Cournoyer 2024-06-17 20:19 ` Guillaume Le Vaillant 0 siblings, 1 reply; 24+ messages in thread From: Maxim Cournoyer @ 2024-06-17 19:53 UTC (permalink / raw) To: Guillaume Le Vaillant Cc: Steve George, ludo, mail, Lars-Dominik Braun, efraim, 70456 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#70456: Request for merging core-updates branch 2024-06-17 19:53 ` Maxim Cournoyer @ 2024-06-17 20:19 ` Guillaume Le Vaillant 0 siblings, 0 replies; 24+ messages in thread From: Guillaume Le Vaillant @ 2024-06-17 20:19 UTC (permalink / raw) To: Maxim Cournoyer Cc: Steve George, ludo, mail, Lars-Dominik Braun, efraim, 70456 [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2024-06-17 20:20 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-03-24 11:21 Status of ‘core-updates’ Ludovic Courtès 2024-03-30 10:55 ` Josselin Poiret 2024-04-10 14:39 ` Ludovic Courtès 2024-04-11 10:18 ` Steve George 2024-04-12 20:21 ` Ludovic Courtès 2024-04-17 17:47 ` Maxim Cournoyer 2024-04-17 22:52 ` Felix Lechner via Development of GNU Guix and the GNU System distribution. 2024-04-19 14:13 ` Ludovic Courtès 2024-04-19 15:22 ` Maxim Cournoyer 2024-04-22 16:20 ` Efraim Flashner 2024-04-20 11:14 ` Christopher Baines 2024-04-20 21:15 ` Maxim Cournoyer 2024-05-02 7:53 ` bug#70456: Request for merging "core-updates" branch Ludovic Courtès -- strict thread matches above, loose matches on Subject: below -- 2024-04-18 14:56 bug#70456: Request for merging core-updates branch Steve George 2024-04-19 14:42 ` bug#70456: Request for merging "core-updates" branch Christopher Baines 2024-04-19 17:00 ` Christopher Baines 2024-04-20 16:16 ` Maxim Cournoyer 2024-04-20 18:08 ` Christopher Baines 2024-04-22 17:31 ` Maxim Cournoyer 2024-04-26 14:44 ` tumashu 2024-06-14 6:30 ` bug#70456: Request for merging core-updates branch Lars-Dominik Braun 2024-06-14 7:55 ` Guillaume Le Vaillant 2024-06-17 19:53 ` Maxim Cournoyer 2024-06-17 20:19 ` Guillaume Le Vaillant
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.