Re: [aarch64] sbcl build failure

On Wed, Mar 31, 2021 at 12:15:01AM +0200, Vincent Legoll wrote: > I'm looking at the following cl-zstd build failure: > https://ci.guix.gnu.org/build/133326/details > which is caused by sbcl build failure that I > reproduced locally. During the recent staging cycle, I noticed a huge number of

Re: hikari build failure

On Tue, Mar 30, 2021 at 11:58:57PM +0200, Vincent Legoll wrote: > > I've restarted . > > I'm seeing overdrive1 as idle (as a lot of hydra workers) yet the > restart is still in scheduled state. > > What am I missing ? I don't know exactly what

Re: GNOME 40 work should be done on Savannah

On Tue, 2021-03-30 at 21:55 -0400, Mark H Weaver wrote: > I'm sorry if that happened. It was not my intent. Can you show me > what > I wrote that misrepresents your position? I don't have the energy now I feel already bad enough this discussion even happened, in a way that even Ludo, the

Re: GNOME 40 work should be done on Savannah

Hi Léo, Léo Le Bouter writes: > I think Mark misrepresents my sayings in their messages. I'm sorry if that happened. It was not my intent. Can you show me what I wrote that misrepresents your position? > We are ONLY using git to exchange work and collaborate on the patchset > with Raghav,

Re: Question about compile packages

On Tue, 30 Mar 2021 07:12:27 -0400 Julien Lepiller wrote: > Not sure about your first question. Maybe create your own fork and > regularly rebase it? Guix will not be very happy with that I think, > but it should work. > > To pass --no-substitutes, you can pass it to guix-daemon, or remove >

meson-build-system cross compilation

Hi Raghav, since you have been using meson build system a lot, could you add support for cross-compilation to guix/build-system/meson.scm please? I would do it myself if I knew how. See https://issues.guix.gnu.org/44244 See also https://mesonbuild.com/Cross-compilation.html As it is now, a

Re: Question about compile packages

Hi, Charles Direg asked: > How can I modify the flags that any program is compiled with within guix? That > is, I can allow in the gnu-build-system to modify it globally so that I can > add the build flags to any package, for example, add the flags -O2 > -march=native -mtune=native so global as

Re: GNOME 40 work should be done on Savannah

On Tue, 2021-03-30 at 14:12 +0200, Ludovic Courtès wrote: > > I don't feel like people should be barred to contribute to that > > GNOME > > 40 upgrade because they arent an approved committer. That doesnt > > feel > > inclusive to me. > > I respectfully think you misunderstand the review process.

Re: GNOME 40 work should be done on Savannah

On Tue, 2021-03-30 at 14:12 +0200, Ludovic Courtès wrote: > I respectfully think you misunderstand the review process. Review is > about sharing responsibilities and reducing the likelihood of > mistakes. > > It’s crucial from many different perspectives: security-wise, > socially > (the process

Re: Security patching and the branching workflow: a new security-updates branch

On Tue, 2021-03-30 at 13:48 +0200, zimoun wrote: > Ahah, I am happy to know it. I hope it is because a > “miscommunication» > and not because you do not carefully read or because maybe you only > see > through the tiny lens of known security vulnerabilities. From my > opinion, your point of view

Re: GNOME 40 work should be done on Savannah (was: Re: GNOME 40)

On Tue, 2021-03-30 at 02:41 -0400, Mark H Weaver wrote: > Sorry, but that's simply false. You _do_ have a choice. You can do > what we've been doing in the Guix community for years: as a > committer, > _you_ can commit the work of non-committers on their behalf. If not > you, then any of the

Re: Will 2021 be the year of build systems on gexps?

Hi Ludo, Ludovic Courtès writes: > So this is it, 2021 *is* the year of build systems on gexps! Wow! Congratulations! I am very happy to see this finally come together. > It’s crazy that it took 6 years (six!) to get past the finish line. I think I’ve only known what a gexp is for three

Re: [PATCHES] ImageMagick security updates without grafting

Mark H Weaver writes: > Maxime Devos writes: > >> guix build $PACKAGES >> # maybe guix build $PACKAGES --no-grafts? >> guix graph --type=references $PACKAGES >> # ^ look in output for "imagemagick". > > For the record, it seems that this command gives false positives. Sorry, I was mistaken

Re: Let's include powerpc64le-linux in the next release

Hello, On Tue, Mar 30, 2021 at 10:24 AM Ludovic Courtès wrote: > Plus, I’m really grateful to OSUOSL for giving > us access to this machine! Yes, it's really nice to have access to those, and in the future, if we want to really support the ppc64le with substitutes, we may ask for a CI-class VM

[aarch64] sbcl build failure

Hello, I'm looking at the following cl-zstd build failure: https://ci.guix.gnu.org/build/133326/details which is caused by sbcl build failure that I reproduced locally. I diffed the CI build log output with my local attempt and got the same thing modulo timings [1] and other harmless stuff. [1]

Re: hikari build failure

> I've restarted . I'm seeing overdrive1 as idle (as a lot of hydra workers) yet the restart is still in scheduled state. What am I missing ? -- Vincent Legoll

Re: Will 2021 be the year of build systems on gexps?

Hi Maxim and all, So this is it, 2021 *is* the year of build systems on gexps! I’ve rebased it and pushed on ‘core-updates’ with 2eafeb2f3d661061bc412c3f27c90202e4532532 as the tip. The build farm has a bit of work to do now it seems. Hmm actually the evaluation at

Re: hikari build failure

Vincent Legoll writes: What should we do ? just wait for next build ? I've restarted . Kind regards, T G-R

hikari build failure

Hello, I saw the aarch64 build failure for hikari on cuirass https://ci.guix.gnu.org/build/133895/details it looked like the failure was because bmake (a dep) failed, I tried to build it locally which succeded, then also retried hikari with success. I'm on a binary install above armbian on

Re: Deep vs Shallow trace: Removing the tradeoff?

Hi ilmu, On +2021-03-28 23:16:23 +, ilmu wrote: > First of all, thanks for engaging with me, sorry for not putting more work > into the initial email. Note that I have attached inline images from the > paper, the paper is also attached to this email. > An interesting paper.. I have long

rust-tempfile-3 update to 3.2.0 breaks sequoia build

Hi Nicolas, building sequoia is currently broken in master with "syn::export::ToTokens" not found. I tracked this down to 6513650d40f74 "gnu: rust-tempfile-3: Update to 3.2.0." (2021-02-16). The updated package also updates some dependency-requirements: cfg-if 0.1 -> 1, rand 0.7 -> 0.8 and

Re: [PATCH] display grafted package

Hi, zimoun skribis: > The attached patch does that only for ’package->recutils’ (show and > search). For instance, note the ’replaced’ field for the grafted > package. (Obviously, it could be any other word than ’replaced’ > compatible with the recutils record.) [...] > name: zstd >

Re: GNOME 40 work should be done on Savannah

Hi Léo, Léo Le Bouter skribis: > I don't feel like people should be barred to contribute to that GNOME > 40 upgrade because they arent an approved committer. That doesnt feel > inclusive to me. I respectfully think you misunderstand the review process. Review is about sharing responsibilities

Re: Security patching and the branching workflow: a new security-updates branch

On Sat, 27 Mar 2021 at 15:14, Léo Le Bouter wrote: > but you > cannot put forward the arguments you've made, they do not work. Ahah, I am happy to know it. I hope it is because a “miscommunication» and not because you do not

Re: GNOME 40 work should be done on Savannah (was: Re: GNOME 40)

Hi, > The thing is, the work of non-committers *must* be reviewed at some > point, anyway. Moreover, a committer must take responsibility by > digitally signing it. To eliminate either of these steps would put us > at risk. > > There's no guarantee that the work of Guix committers will be

Re: Question about compile packages

Not sure about your first question. Maybe create your own fork and regularly rebase it? Guix will not be very happy with that I think, but it should work. To pass --no-substitutes, you can pass it to guix-daemon, or remove the authorized keys from /etc/guix/acl. The second option lets you

Re: Deep vs Shallow trace: Removing the tradeoff?

Hi, ilmu skribis: > Early cutoff is a very desirable property that nix does not have (and I > assume therefore that neither does guix). The “intensional model” that Julien mentioned, or what the Nix folks now refer to as “content-addressed derivations”, have this early cutoff property. It’s

Re: Needed: tooling to detect references to buggy */stable packages

Hi, Mark H Weaver skribis: > It occurs to me that we will need some tooling to ensure that no > references to these buggy "*/stable" packages end up in package outputs > that users actually use. Otherwise, it is likely that sooner or later, > a runtime reference to one of these buggy packages

Re: Document our WIP

Hi! Vincent Legoll skribis: > I'd like to reiterate my proposal to document our > ongoing projects, maybe with a "WIP" page on the > web site (even if I'm not a web guy, I volunteer > the maintenance of it). To me, a good way to make sure work remains “in progress” is to post regular updates

Re: I have merged wip-ppc64le-for-master to master

Hi! Chris Marusich skribis: > FYI, I have merged wip-ppc64le-for-master to master and closed bug > 47182. I have also deleted the wip-ppc64le-for-master branch. Yay, congrats! \o/ I now have access to the OSUOSL POWER9 machine. I’ve set up offloading and it seems to work well. Thanks to

Buying AArch64 hardware?

Hi Leo, Leo Famulari skribis: > I volunteer to host one or two workstation-type 64-bit ARM machines. > > Concretely, this would mean a Honeycomb LX2 or Ampere ALTRA workstation, > since I don't believe there are any other aarch64 workstations available > for sale. > >

Re: A proposal for better quality in maintenance of packages by reducing scope

Hi Léo, Léo Le Bouter skribis: > I would like to propose that we reduce the scope of the maintenance we > do in GNU Guix and establish a list of packages that we more or less > commit to maintaining because this is something that we can do and is > attainable, for example, we could remove

Re: Secure GNU Guix offloading

Hi! Léo Le Bouter skribis: > I don't want to give more access than what SSH non-root access would > give, and I think it would be possible to do something helpful in GNU > Guix offloading so it can work even without the offload machine > trusting the client's store public signing key. One

Re: Let's include powerpc64le-linux in the next release

Hi Tobias, Tobias Geerinckx-Rice skribis: > Ludovic Courtès 写道： >> Like Efraim wrote, the person who makes the release (I’m afraid >> it’ll be >> me) needs to be able to offload to a “trustworthy” machine for that >> platform. > > Define trustworthy? I put quotes because it’s informally

Re: GNOME 40 work should be done on Savannah (was: Re: GNOME 40)

Mark H Weaver writes: > Christopher Baines writes: > >> Mark H Weaver writes: >>> How is it more flexible than a "wip-*" branch on Savannah? >> >> I wouldn't use quite the same words as Léo, but from my perspective, >> controlling access to particular branches (master, staging, >>

Re: GNOME 40 work should be done on Savannah (was: Re: GNOME 40)

Hi Léo, Léo Le Bouter writes: > The people that work on it now are Raghav and me, and Raghav does not > have commit access yet, so that's the only way we can work and > cooperate now. We don't have a choice. Sorry, but that's simply false. You _do_ have a choice. You can do what we've been