Re: Core-updates merge

Hi Pierre, On Fri, Jul 14, 2023 at 11:18 AM Pierre Langlois wrote: > > Attribution is always nice of course, but mistakes happen Thank you for your kind and generous reaction to the innocent oversight. Please have a good weekend! Kind regards Felix

Re: Core-updates merge

Hi Pierre! On Fri, Jul 14, 2023 at 07:12 PM, Pierre Langlois wrote: > Hi John! > > John Kehayias writes: > >> Bringing back up an old thread, but >> >> On Fri, Apr 28, 2023 at 05:55 AM, John Kehayias wrote: >> >>> Dear Andreas and fellow Guix-ers, >>> >>> On Tue, Apr 25, 2023 at 04:09 PM,

Re: Core-updates merge

Hi Felix, On Fri, Jul 14, 2023 at 09:52 AM, Felix Lechner wrote: > Hi John, > > On Fri, Jul 14, 2023 at 9:37 AM John Kehayias > wrote: >> >> Unfortunately >> I managed to clobber the author line in the git log after editing and >> testing locally, sorry about that! (Anything that can be done to

Re: Core-updates merge

Hi John! John Kehayias writes: > Bringing back up an old thread, but > > On Fri, Apr 28, 2023 at 05:55 AM, John Kehayias wrote: > >> Dear Andreas and fellow Guix-ers, >> >> On Tue, Apr 25, 2023 at 04:09 PM, Andreas Enge wrote: >> > [...] >>> Each and every package is not yet in shape; please

Re: Core-updates merge

Hi John, On Fri, Jul 14, 2023 at 9:37 AM John Kehayias wrote: > > Unfortunately > I managed to clobber the author line in the git log after editing and > testing locally, sorry about that! (Anything that can be done to fix > that?) Giving proper attribution can be essential in group projects.

Re: Core-updates merge

Bringing back up an old thread, but On Fri, Apr 28, 2023 at 05:55 AM, John Kehayias wrote: > Dear Andreas and fellow Guix-ers, > > On Tue, Apr 25, 2023 at 04:09 PM, Andreas Enge wrote: > [...] >> Each and every package is not yet in shape; please feel free to submit >> patches for your favourite

Re: Core-updates merge

Hello! "Leo Famulari" skribis: > Thank you for leading this effort! > > The value of leadership and project management is sometimes underappreciated > in software projects, but they are essential for our success. Agreed! You did a great job Andreas at coordinating all the work *and* actually

ocaml bootstrap (was Re: Core-updates merge)

On Fri, Apr 28, 2023 at 04:17:40PM +0200, Simon Tournier wrote: > Hi Andreas, > > On mar., 25 avril 2023 at 16:09, Andreas Enge wrote: > > > - OCaml could be simplified by dropping version 4.07 (Julien Lepiller). > > Well, 4.07 is the version that is de-bootstrapped, i.e. bootstrapped > using

Re: Build dependency inflation (was: Re: Core-updates merge)

Simon Josefsson via "Development of GNU Guix and the GNU System distribution." writes: > [[PGP Signed Part:Undecided]] > Andreas Enge writes: > >> - Too much in Guix depends on too much else, which makes building things >> needlessly entangled; in particular time zone data should not be

Re: Build dependency inflation (was: Re: Core-updates merge)

Hi, On jeu., 27 avril 2023 at 19:56, Simon Josefsson via "Development of GNU Guix and the GNU System distribution." wrote: > Andreas Enge writes: > >> - Too much in Guix depends on too much else, which makes building things >> needlessly entangled; in particular time zone data should not be

Re: Core-updates merge

Hi Andreas, On mar., 25 avril 2023 at 16:09, Andreas Enge wrote: > I have just merged core-updates into master and deleted the branch! Awesome! Thank you for your patient leadership over the past months. :-) > - R on powerpc64le needs to be built by changes to valgrind and lz4 > (Simon

Re: [Rust Team] Status post core-updates merge

Hi Efraim, Efraim Flashner writes: [...] >> I'm also curious, since you're "early adopters": how are you managing >> with the team workflow? Any tips, remarks or impressions that you could >> share with other teams? > > Speak in the plural and no one will realize it's a team of one ;) > > I'm

Re: Core-updates merge

Dear Andreas and fellow Guix-ers, On Tue, Apr 25, 2023 at 04:09 PM, Andreas Enge wrote: > Hello all, > > I have just merged core-updates into master and deleted the branch! > This has been a long adventure, which became particularly intensive > after the last Guix Days in February. First and

Re: Build dependency inflation (was: Re: Core-updates merge)

Hi, TL;DR: If we have 22k sources, how about expressing dependency as a 22k x 22k matrix of weights Wij and dependency by multiplication of 22k x 1 matrix os sources variables ordered Sj by immediate dependency first. I guess the Sj column matrix is transposed to do the multiplication, so the Wij

Build dependency inflation (was: Re: Core-updates merge)

Andreas Enge writes: > - Too much in Guix depends on too much else, which makes building things > needlessly entangled; in particular time zone data should not be referred > to by packages, but be loaded at runtime (Leo Famulari). This is an important open problem -- is there any way to

Re: [Rust Team] Status post core-updates merge

On Thu, Apr 27, 2023 at 07:06:29PM +0200, Josselin Poiret wrote: > Hi Efraim (and the rest of the Rust team), > > Efraim Flashner writes: > > > Now that core-updates has been merged into master it's time for a status > > update from the rust team. > > > > Currently rust supports (in the order

Re: [Rust Team] Status post core-updates merge

Hi Efraim (and the rest of the Rust team), Efraim Flashner writes: > Now that core-updates has been merged into master it's time for a status > update from the rust team. > > Currently rust supports (in the order of gaining support) x86_64, > aarch64 and riscv64. GDB-11 doesn't currently build

[Rust Team] Status post core-updates merge

Now that core-updates has been merged into master it's time for a status update from the rust team. Currently rust supports (in the order of gaining support) x86_64, aarch64 and riscv64. GDB-11 doesn't currently build on aarch64 or riscv64, so we're removing gdb-11 entirely and using a new gdb-12

Re: Core-updates merge

Hello, My gratitude for your patience and perseverance on merging the core-updates branch :-). Congratulations everyone! -- Thanks, Maxim

Re: Core-updates merge

Thank you for leading this effort! The value of leadership and project management is sometimes underappreciated in software projects, but they are essential for our success. On Tue, Apr 25, 2023, at 10:09, Andreas Enge wrote: > Hello all, > > I have just merged core-updates into master and

Re: Core-updates merge

Hi Andreas, Andreas Enge writes: > Hello all, > > I have just merged core-updates into master and deleted the branch! > This has been a long adventure, which became particularly intensive > after the last Guix Days in February. First and foremost many thanks to > everyone who contributed to the

Re: Core-updates merge

On 4/25/23 8:40 AM, Felix Lechner via Development of GNU Guix and the GNU System distribution. wrote: Hi Andreas, On Tue, Apr 25, 2023 at 7:09 AM Andreas Enge wrote: many thanks to everyone who contributed to the branch, be it by commits, discussions or by working on the infrastructure.

Re: Core-updates merge

Hi Andreas, On Tue, Apr 25, 2023 at 7:09 AM Andreas Enge wrote: > > many thanks to > everyone who contributed to the branch, be it by commits, discussions or > by working on the infrastructure. I'd like to please also acknowledge your pivotal role in shepherding that monumental merge. With

Core-updates merge

Hello all, I have just merged core-updates into master and deleted the branch! This has been a long adventure, which became particularly intensive after the last Guix Days in February. First and foremost many thanks to everyone who contributed to the branch, be it by commits, discussions or by

Core-updates merge, d-1

Hello, people have been working on packages close to the leaves which did not build any more in core-updates; but as far as I can see, nothing major has popped up that would prevent a merge. So unless there is firm opposition, I intend to merge core-updates to master tomorrow as announced, in

Re: package systems, before and after the core-updates merge

Hi, On Sat, 19 Oct 2019 at 23:03, Ludovic Courtès wrote: > > I think this is down to the use of package-transitive-supported-systems > > within the Guix Data Service, but the output of this function for a > > package can also be seen by running guix package --show. > > The patch below fixes

Re: package systems, before and after the core-updates merge

Hi, Christopher Baines skribis: > One thing that I was aware of before the recent core-updates merge was > that the Guix Data Service [1] didn't generate derivations for systems > other than x86_64-linux and i686-linux, at least to the same extent as > the master branch before the

package systems, before and after the core-updates merge

Hey, One thing that I was aware of before the recent core-updates merge was that the Guix Data Service [1] didn't generate derivations for systems other than x86_64-linux and i686-linux, at least to the same extent as the master branch before the recent core-updates merge. 1: http

Re: packages which are broken after core-updates merge

Ludovic Courtès writes: > ng0 skribis: > >> icecat is failing, with new profiles, with old profiles. This can be >> reproduced in a new profile by selecting 'Preferences > Applications'. >> It should immediately crash. > > I have

Re: packages which are broken after core-updates merge

Ricardo Wurmus writes: > Clément Lassieur writes: > >>> Clément Lassieur transcribed 0.2K bytes: > icecat is failing, with new profiles, with old profiles. This can be > reproduced in a new profile by selecting 'Preferences > Applications'.

Re: packages which are broken after core-updates merge

> Clément Lassieur writes: > >>> Clément Lassieur transcribed 0.2K bytes: > icecat is failing, with new profiles, with old profiles. This can be > reproduced in a new profile by selecting 'Preferences > Applications'. > It should immediately crash.

Re: packages which are broken after core-updates merge

> ng0 skribis: > >> icecat is failing, with new profiles, with old profiles. This can be >> reproduced in a new profile by selecting 'Preferences > Applications'. >> It should immediately crash. > > I have /gnu/store/pk4sbzk3xh7yjj9ls7hkhzgaj0xha7xp-icecat-45.7.0-gnu1 >

Re: packages which are broken after core-updates merge

ng0 skribis: > icecat is failing, with new profiles, with old profiles. This can be > reproduced in a new profile by selecting 'Preferences > Applications'. > It should immediately crash. I have /gnu/store/pk4sbzk3xh7yjj9ls7hkhzgaj0xha7xp-icecat-45.7.0-gnu1 (x86_64)

Re: packages which are broken after core-updates merge

Clément Lassieur writes: >> Clément Lassieur transcribed 0.2K bytes: >>> > icecat is failing, with new profiles, with old profiles. This can be >>> > reproduced in a new profile by selecting 'Preferences > Applications'. >>> > It should immediately crash. >>> >>> It

Re: packages which are broken after core-updates merge

> Clément Lassieur transcribed 0.2K bytes: >> > icecat is failing, with new profiles, with old profiles. This can be >> > reproduced in a new profile by selecting 'Preferences > Applications'. >> > It should immediately crash. >> >> It doesn't crash when "--with-system-icu" is removed. > > Can

Re: packages which are broken after core-updates merge

Clément Lassieur transcribed 0.2K bytes: > > icecat is failing, with new profiles, with old profiles. This can be > > reproduced in a new profile by selecting 'Preferences > Applications'. > > It should immediately crash. > > It doesn't crash when "--with-system-icu" is removed. Can you send a

Re: packages which are broken after core-updates merge

> icecat is failing, with new profiles, with old profiles. This can be > reproduced in a new profile by selecting 'Preferences > Applications'. > It should immediately crash. It doesn't crash when "--with-system-icu" is removed.

packages which are broken after core-updates merge

neomutt no longer works with kyotocabinet correctly: Apr 3 13:52:29 localhost vmunix: [ 426.159873] traps: mutt[937] trap invalid opcode ip:7f15d1356008 sp:7fffe89d9070 error:0 Apr 3 13:52:29 localhost vmunix: [ 426.159876] in libkyotocabinet.so.16.13.0[7f15d12e9000+ee000] icecat is failing,

Re: ‘core-updates’ merge is a squashed commit

On Sat 06 Aug 2016 09:52, Andreas Enge writes: > I am not very happy about such a policy; if I sign a commit, I am only > signing my commit, and not all of its history For what it's worth, this is not quite true. The SHA1 hashes of parent commits are part of the commit object

Re: ‘core-updates’ merge is a squashed commit

On Sat 06 Aug 2016 04:07, Leo Famulari writes: > But, I also think the primary point of signing the commits is to record > the identity of the person responsible for the commit, and so I think > the policy should be to sign each commit. [0] To me this is not the value that

Re: ‘core-updates’ merge is a squashed commit

On Thu, Aug 04, 2016 at 17:06:15 +0200, Andy Wingo wrote: > What's the rationale for requiring non-HEAD commits to be signed when > pushing? For me a signed HEAD implicitly signs all parent comments, in > my mental trust model anyway :) That could be a potentially daunting/impossible task for

Re: ‘core-updates’ merge is a squashed commit

On Fri, Aug 05, 2016 at 08:59:32PM -0400, Mark H Weaver wrote: > I haven't thought deeply on this, but it seems to me that Andy's > suggestion has a lot of merit. We could choose to decide, as a matter > of policy, that if you sign a commit with unsigned ancestor commit(s), > you are effectively

Re: ‘core-updates’ merge is a squashed commit

On Fri, Aug 05, 2016 at 08:59:32PM -0400, Mark H Weaver wrote: > Leo Famulari writes: > > If I push A-B-C with a signed HEAD immediately after somebody pushes a > > forged D, won't it look like I vouch for D? > > This can't happen unless D is already in your local repo before

Re: ‘core-updates’ merge is a squashed commit

Leo Famulari writes: > On Fri, Aug 05, 2016 at 06:50:30PM +0200, Andy Wingo wrote: >> Why would you sign a commit if you don't attest to intermediate unsigned >> commits? > > If I push A-B-C with a signed HEAD immediately after somebody pushes a > forged D, won't it look like

Re: ‘core-updates’ merge is a squashed commit

On Fri, Aug 05, 2016 at 06:50:30PM +0200, Andy Wingo wrote: > Why would you sign a commit if you don't attest to intermediate unsigned > commits? If I push A-B-C with a signed HEAD immediately after somebody pushes a forged D, won't it look like I vouch for D? How could a 3rd party tell whether D

Re: ‘core-updates’ merge is a squashed commit

On Fri 05 Aug 2016 16:59, Leo Famulari writes: > On Fri, Aug 05, 2016 at 09:35:59AM +0200, Andy Wingo wrote: >> Yeah. I guess I don't see see "author misattribution on unsigned >> commits" as part of the threat model. >> >> My mental model is that if you have a signed

Re: ‘core-updates’ merge is a squashed commit

On Fri, Aug 05, 2016 at 09:35:59AM +0200, Andy Wingo wrote: > Yeah. I guess I don't see see "author misattribution on unsigned > commits" as part of the threat model. > > My mental model is that if you have a signed commit A with unsigned > parents B, C, ..., that it's the person who signed

Re: ‘core-updates’ merge is a squashed commit

On Thu 04 Aug 2016 22:05, Leo Famulari writes: > On Thu, Aug 04, 2016 at 06:55:34PM +0200, Andy Wingo wrote: >> On Thu 04 Aug 2016 18:44, Leo Famulari writes: >> >> > How would the rest of us distinguish between >> > >> > 1) a range of your commits with

Re: ‘core-updates’ merge is a squashed commit

On Thu, Aug 04, 2016 at 06:55:34PM +0200, Andy Wingo wrote: > On Thu 04 Aug 2016 18:44, Leo Famulari writes: > > > How would the rest of us distinguish between > > > > 1) a range of your commits with a signed HEAD > > 2) a range of your commits with a signed HEAD that you

Re: ‘core-updates’ merge is a squashed commit

On Thu, Aug 04, 2016 at 08:32:42PM +0200, Andreas Enge wrote: > On Thu, Aug 04, 2016 at 12:37:07PM -0400, Leo Famulari wrote: > > git rebase "$range" --exec "git commit --amend --no-edit --gpg-sign" || > > git rebase --abort > > So it is not enough to just do a >git rebase -S > ? I

Re: ‘core-updates’ merge is a squashed commit

On Thu, Aug 04, 2016 at 04:45:56PM +0200, Mathieu Lirzin wrote: > With gpg-agent and git properly setup, signing every local commit is not > that inconvenient IME. > I recommend you to give a try. ;) Ever so often I try gpg@2 (I do not remember whether 2.0 or 2.1), it works for a while, it stops

Re: ‘core-updates’ merge is a squashed commit

On Thu 04 Aug 2016 18:44, Leo Famulari writes: > How would the rest of us distinguish between > > 1) a range of your commits with a signed HEAD > 2) a range of your commits with a signed HEAD that you pushed after I > pushed a commit created with `git commit --author="Andy

Re: ‘core-updates’ merge is a squashed commit

On Thu, Aug 04, 2016 at 05:06:15PM +0200, Andy Wingo wrote: > On Thu 04 Aug 2016 14:36, Mark H Weaver writes: > > > Unfortunately, when I tried to push it to 'master', it was rejected > > because of 56 unsigned commits on the 'core-updates' branch. > > What's the rationale for

Re: ‘core-updates’ merge is a squashed commit

On Thu 04 Aug 2016 14:36, Mark H Weaver writes: > Unfortunately, when I tried to push it to 'master', it was rejected > because of 56 unsigned commits on the 'core-updates' branch. What's the rationale for requiring non-HEAD commits to be signed when pushing? For me a signed

Re: ‘core-updates’ merge is a squashed commit

Hi, Andreas Enge writes: > On Thu, Aug 04, 2016 at 09:23:50AM -0400, Mark H Weaver wrote: >> I just did this. Huge thanks to Lisa Marie Maginnis, GNU sysadmin >> extraordinaire, for promptly responding to my plea for help :) > > Thanks to both of you! > >> However, we should

Re: ‘core-updates’ merge is a squashed commit

Mark H Weaver skribis: > Leo Famulari writes: > >> On Thu, Aug 04, 2016 at 02:40:32PM +0200, Andreas Enge wrote: >>> On Thu, Aug 04, 2016 at 08:36:28AM -0400, Mark H Weaver wrote: >>> Good news, thanks for all this work! >> >> Indeed! >> >>> > Unfortunately,

Re: ‘core-updates’ merge is a squashed commit

Leo Famulari writes: > On Thu, Aug 04, 2016 at 02:40:32PM +0200, Andreas Enge wrote: >> On Thu, Aug 04, 2016 at 08:36:28AM -0400, Mark H Weaver wrote: >> Good news, thanks for all this work! > > Indeed! > >> > Unfortunately, when I tried to push it to 'master', it was

Re: ‘core-updates’ merge is a squashed commit

On Thu, Aug 04, 2016 at 02:40:32PM +0200, Andreas Enge wrote: > On Thu, Aug 04, 2016 at 08:36:28AM -0400, Mark H Weaver wrote: > Good news, thanks for all this work! Indeed! > > Unfortunately, when I tried to push it to 'master', it was rejected > > because of 56 unsigned commits on the

Re: ‘core-updates’ merge is a squashed commit

Andreas Enge writes: > On Thu, Aug 04, 2016 at 03:50:51AM -0400, Mark H Weaver wrote: >> How about reverting the squashed commit and then re-doing a proper merge >> from 'core-updates-2016-08-01' into 'master'? > > If this is possible without too many complications, that sounds

Re: ‘core-updates’ merge is a squashed commit

On Thu, Aug 04, 2016 at 03:50:51AM -0400, Mark H Weaver wrote: > How about reverting the squashed commit and then re-doing a proper merge > from 'core-updates-2016-08-01' into 'master'? I think we should do this. It's worth a little blemish in the commit history in order to retain the history of

Re: ‘core-updates’ merge is a squashed commit

On Thu, Aug 04, 2016 at 03:50:51AM -0400, Mark H Weaver wrote: > How about reverting the squashed commit and then re-doing a proper merge > from 'core-updates-2016-08-01' into 'master'? If this is possible without too many complications, that sounds like a good option; the earlier the better,

Re: ‘core-updates’ merge is a squashed commit

Leo Famulari <l...@famulari.name> writes: > On Wed, Aug 03, 2016 at 10:29:21PM +0200, Ludovic Courtès wrote: >> In fact, commit 455859a50f88f625d13fc2f304111f02369b366b, which is the >> core-updates merge, is *not* a merge commit. Instead it seems to be a >> squ

Re: ‘core-updates’ merge is a squashed commit

On Wed, Aug 03, 2016 at 10:29:21PM +0200, Ludovic Courtès wrote: > In fact, commit 455859a50f88f625d13fc2f304111f02369b366b, which is the > core-updates merge, is *not* a merge commit. Instead it seems to be a > squashed commit of all of core-updates. Consequently, part of the

‘core-updates’ merge is a squashed commit

Hello! Someone reported that the commit stats for the new release were suspicious and found that the recent core-updates merge was fishy. In fact, commit 455859a50f88f625d13fc2f304111f02369b366b, which is the core-updates merge, is *not* a merge commit. Instead it seems to be a squashed commit

Re: Preparing for core-updates merge

Mark merged ‘core-updates’ yesterday (thanks!). Please report any issues. Ludo’.

Re: Preparing for core-updates merge

It’s building now! It may be that some of your favorite packages will fail to build with 4.9, so keep an eye on it. Ludo’.

Preparing for core-updates merge

Hello! I think we can soon get core-updates built entirely so we can merge it afterwards. Any objections? Can someone confirm that everything is OK on armhf? (Mark tested a few days ago, so I guess this should be OK.) Thanks, Ludo’.

core-updates merge really imminent

l...@gnu.org (Ludovic Courtès) skribis: If there are no objections, we’ll let Hydra build all of ‘core-updates’ and merge it afterwards–i.e., within 2-3 days. Ahem, sometimes, days last real long. But we’re getting there! http://hydra.gnu.org/jobset/gnu/core-updates shows that most things

core-updates merge imminent

If there are no objections, we’ll let Hydra build all of ‘core-updates’ and merge it afterwards–i.e., within 2-3 days. OK? Ludo’.

Re: core-updates merge imminent

Done! At the moment most packages are built for x86_64; i686 is a bit behind and mips64el is a lot behind. Ludo’.

core-updates merge imminent

Hi Guix! Hydra is now building all the packages from ‘core-updates’, so unless something goes wrong, expect it to be merged within 24-48 hours. We’ll reopen a ‘core-updates’ branch shortly after that. Ludo’.

Re: core-updates merge imminent

l...@gnu.org (Ludovic Courtès) skribis: It seems we can soon merge ‘core-updates’. So far Hydra has been building the core packages of that branch, and the only problem left is the cross-compilation of the bootstrap GCC (‘%gcc-static’ in make-bootstrap.scm), which is annoying but not