Re: R packages are not recognized.

Divya writes: > I installed R packages using `guix install`, `guix shell` or by adding them > to my home configuration, but in none of those ways can I get > my R system (which is also installed through guix using system configuration) > can recognize those packages. > > What is going wrong? R

Re: "guix pack -f docker" does too much work

Maxim Cournoyer writes: >>> I think it would be great if "guix pack -f docker" could avoid building >>> all these identical layers again and again. Perhaps it would be >>> possible to have a single derivation for each layer? This way we >>> wouldn't have to recreate the same layer archives ever

Re: Does anyone use i686-linux? [was Re: bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux]

André Batista writes: >> > Keeping this to i686-linux specifically, what generation of hardware >> > supports i686 but not x86_64? Some (very) quick checking on wikipedia >> > suggests that the x60 from 2006 was either 32-bit or 64-bit, and I >> > believe there was an atom chip from 2015 that was

Re: ‘core-updates’ is gone; long live ‘core-packages-team’!

Marek Paśnikowski writes: >> Summary 1: not enough computing time >> > > Compute less. This can be achieved by selecting a subset of packages to > be built, leaving the rest to be compiled by users. I don't think we should do that. We have some useful information, though, to reduce the number

Re: Merging ‘core-updates’ real soon

I noticed a regression for x86_64 since the rebasing of core-updates onto master. epiphany no longer builds due to a build failure in webkitgtk. I hadn't reported it yet, because there's a chance it's due to limited resources on my laptop; ci.guix.gnu.org is still a large number of builds behind.

Re: [core-updates] aarch64: Cannot build glibc-2.39

I successfully deployed to my aarch64-linux machine (Rockpro64) on Guix commit 1a30e510464f5d3232f80007328b9af4dd90c6d4. Works without problems. -- Ricardo

Re: [core-updates] aarch64: Cannot build glibc-2.39

Ludovic Courtès writes: > Ludovic Courtès skribis: > ./pre-inst-env guix build -K --system=aarch64-linux -e \ '((@@ (gnu packages make-bootstrap) glibc-for-bootstrap) (@ (gnu packages base) glibc))' >>> >>> I was able to build that glibc with this diff: >> >> I’m testing

Re: Guix publish stopped working

Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > A few months ago, 'guix publish' stopped accepting connections on a > bunch of my machines. Do the logs say anything of interest? Does a restart "fix" it? -- Ricardo

Re: Status of python-team branch

Lars-Dominik Braun writes: > Hi, > >> I'd like to check who is working on python-team branch to prepare it for >> the merge? > > I don’t think anyone is actively working on it right now. #71408 is > the place where any updates should be if there were any. CC’ing a few > people who have contribute

Re: Indication of build failure from substitute servers?

"Jonathan Frederickson" writes: > Would it make sense to have some mechanism for substitute servers to be able > to provide a sort of "non-existence proof" for a given > package? Something that the CI system could publish to indicate that its > build attempt for that package failed, and that cl

Re: Indication of build failure from substitute servers?

Marek Paśnikowski writes: > The proof of availability is in workflow itself. The project committers > NEVER commit anything to the master branch. Only the CI system > does. Instead, the committers push to a "pre-main" branch, and the CI > system picks the commits up one by one and attempts to bui

Re: Does anyone use i686-linux? [was Re: bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux]

Efraim Flashner writes: > On Fri, Jul 26, 2024 at 02:51:49PM -0400, Leo Famulari wrote: >> For a long time we've not been able to build linux-libre on i686-linux >> because the source unpacking process runs out of memory. > > I believe if we limit the unpacking process to not more than 8 cores we

[core-updates] aarch64: Cannot build glibc-2.39

Hi Guix, I tried to deploy to my aarch64 system with Guix on core-updates. This fails with a configure failure in the build of glibc 2.39. This is the output of the configure phase: --8<---cut here---start->8--- starting phase `configure' source directory: "/

Re: [core-updates] Setting SSL_CERT_FILE in the build environment

Zheng Junjie writes: > Ricardo Wurmus writes: > >> Zheng Junjie writes: >> >>> This patch should fix it. >> >> Thank you for the patch! >> >>> From f41bf905cfb1395a53cfc0d79315148ac9ba0a79 Mon Sep 17 00:00:00 2001 >>> Message-ID:

Re: [core-updates] Setting SSL_CERT_FILE in the build environment

Zheng Junjie writes: > Zheng Junjie writes: > >> Ricardo Wurmus writes: >> >>> Zheng Junjie writes: >>> >>>> This patch should fix it. >>> >>> Thank you for the patch! >>> >>>> From f41bf905cfb1395a53c

Re: [core-updates] Setting SSL_CERT_FILE in the build environment

Zheng Junjie writes: > This patch should fix it. Thank you for the patch! > From f41bf905cfb1395a53cfc0d79315148ac9ba0a79 Mon Sep 17 00:00:00 2001 > Message-ID: > > From: Zheng Junjie > Date: Tue, 16 Jul 2024 00:06:39 +0800 > Subject: [PATCH] gnu: python-requests-next: Fix build. > > * gnu/p

Re: [core-updates] Setting SSL_CERT_FILE in the build environment

Ricardo Wurmus writes: > Ricardo Wurmus writes: > >> How can we generate a certificate bundle in the build environment? >> Apparently it is not enough to just add the nss-certs package. > > Apparently it is totally enough to just add the nss-certs package, and >

Re: [core-updates] Setting SSL_CERT_FILE in the build environment

Ricardo Wurmus writes: > How can we generate a certificate bundle in the build environment? > Apparently it is not enough to just add the nss-certs package. Apparently it is totally enough to just add the nss-certs package, and that's what I di

[core-updates] Setting SSL_CERT_FILE in the build environment

Hi Guix, in issue #70179 we remove the bundled certificate file from python-certifi, which fixes real issues with Python tools on foreign distros. The fix is not without side-effects, though. On core-updates we see a failure in python-requests, which attempts to open a certificate bundle when lo

Re: ci.guix.gnu.org is getting back to life

Ludovic Courtès writes: > Last month, we discussed¹ slow progress with builds (and ‘core-updates’ > in particular) on ci.guix, especially on AArch64 and POWER9. Those > turned out to be mostly due to scalability issues in Cuirass. Likewise, > the front page at https://ci.guix.gnu.org was timing

Re: ‘core-updates’ rebased: testing needed!

Hi, Ludovic Courtès writes: > I have just rebased ‘core-updates’ on ‘master’ (commit > bd5c61781c13611ed16686513980907c6ee34ae6): > > 6e5ecfd0fb7 gnu: libarea: Fix build. > 41e2cd0dd0e gnu: txr: Add missing input. > 1c27fa835d9 gnu: grass: Fix build. > 399a4e8afd3 gnu: python-magic: Adju

Re: anonymized nginx logs (was Re: Guix user statistics and upstream/downstream dependencies)

Simon Tournier writes: > On Tue, 14 May 2024 at 07:57, Maxim Cournoyer > wrote: > >> We have detailed anonymized nginx logs of all downloaded substitutes >> from Berlin, at least. If you are interested to use this data as a >> source we could probably make it available to you since it's anonym

Re: Sustainable funding and maintenance for our infrastructure

Hi Simon, > On Tue, 02 Jul 2024 at 16:24, Ludovic Courtès wrote: > >> The reason for this discussion is that we were >> thinking that we should not take our existing build farms for granted >> and be prepared for the future. > > Could you explain the rationale? I unders

Re: packaging: what to do about these requiring systemd?

Andy Tai writes: > Some packages require systemd; Some of these packages are perfectly happy with elogind. Others only check to decide what files to install (systemd unit files or those for another init system). -- Ricardo

merging r-team branch

Hi Guix, the r-team branch has been built successfully. It contains updates to R and both CRAN and Bioconductor packages. It is the last in the queue of branches to be merged: core-updates #70456 tex-team #70915 python-team #71408 kde-team #71614 rust-team#71703

Re: About SWH, let avoid the wrong discussion

MSavoritias writes: >> > - Guix respects the consent of the person using guix lint and their >> > expectations. (that lint actually lints) >> > - Respects their privacy >> > - Respects their autonomy. >> >> User autonomy is not curtailed by informing an aligned service's crawler >> that an up

Re: About SWH, let avoid the wrong discussion

MSavoritias writes: >> To clarify. I am specifically opposed to a change in official Guix >> packages that allows for this statement: >> >> "Do not upload automatically to software heritage, and no one else can >> either." > > Let me put this more clear Richard, the statement above that archivin

Re: Reducing "You found a bug" reports

Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > On Mon, Jun 17 2024, Ludovic Courtès wrote: > >> I’m fine removing the “report a bug” message [...] WDYT? > > Just a quick side note that some members in our community (not I) are > offended by the word "bug"

Re: I'm retiring (for a while); help needed

Ludovic Courtès writes: >> The channel updaters are running on the berlin server, and the channel >> packages are built by the build farm guix.bordeaux.inria.fr. > > Is there a document summarizing the setup: the repos involved, the > services/periodic jobs running, etc.? There is no such docume

Re: pico.css in Cuirass

Ludovic Courtès writes: >> The last thing I started working on was to use the HTML5 "progress" >> element instead of using custom div + bootstrap JS. With pico.css we >> can drop most classes and a lot of nested divs. Currently, though, it >> all looks very messy. > > Do I get it right that thi

Re: I'm retiring (for a while); help needed

Ludovic Courtès writes: > jbra...@dismail.de skribis: > >> I've done some web work in the past. I could probably help with the >> bootstrap -> pico move. > > I’m also interested in helping land it. Did you have a preliminary > branch for this, Ricardo? I've just pushed my progress to the "wip-

Re: I'm retiring (for a while); help needed

Lars-Dominik Braun writes: >> * maintenance of R, as well as CRAN and Bioconductor packages. > > is there anyone who will look after the automated channels > guix-cran/guix-bioc (and possibly guix-science)? Nobody has volunteered to do that. The channel updaters are running on the berlin server

Re: I'm retiring (for a while); help needed

Simon Tournier writes: > how often do you run “./pre-inst-env guix refresh”? I aimed to do this once a week, every Monday, but I never quite managed to keep it up. It is necessary to keep the packages in Guix up-to-date to prevent problems with the automated updates of the guix-cran and guix-bi

Re: "guix pack -f docker" does too much work

Ludovic Courtès writes: >> I think it would be great if "guix pack -f docker" could avoid building >> all these identical layers again and again. Perhaps it would be >> possible to have a single derivation for each layer? This way we >> wouldn't have to recreate the same layer archives every ti

I'm retiring (for a while); help needed

Hi Guix, in the next few months (from June to the end of October 2024) I won't have much time for computers. Unfortunately, this means that my projects will stall unless some of you continue them. There are only three important projects, and one unimportant project: * maintenance of R, as well

"guix pack -f docker" does too much work

Hi Guix, a few months ago "guix pack -f docker" was modified to produce layers. This is great! Unfortunately, "guix pack" itself still produces one big tarball containing all these layers. There is no sharing of previously built layers, because they are all hidden inside the pack. I think it wo

Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems

Jean-Pierre De Jesus Diaz writes: > I haven't contributed it yet because it has been a bit hard adapting axoloti-* > packages to use a modern toolchain because I'm also intending to remove > the old toolchains in `gnu/packages/embedded.scm' eventually and > instead use the ones in `cross-gcc-tool

Re: (almost) deterministic patchsets

Richard Sent writes: > On a related note I recently discovered that issues.guix.gnu.org does > have a patch-set endpoint that optionally takes a revision e.g. > issues.guix.gnu.org/issue/70XXX/patch-set/3. It's not advertised because it was not well tested at the time. I'm using this script to

Re: (almost) deterministic patchsets

Richard Sent writes: > On a related note I recently discovered that issues.guix.gnu.org does > have a patch-set endpoint that optionally takes a revision e.g. > issues.guix.gnu.org/issue/70XXX/patch-set/3. It's not advertised because it was not well tested at the time. I'm using this script to

Re: branch master updated (2bea3f2562 -> 6745d692d4)

kiasoc5 writes: >>> Also, there appears to be a couple of FIXUP commits that were pushed. >> Yeah, it's very annoying that I missed these two FIXUP commits :-/ >> > > Seeing that these are the only 2 FIXUP commits on the master branch > history so far, would it make sense to force push and edit

Re: branch master updated (2bea3f2562 -> 6745d692d4)

Christopher Baines writes: > Ricardo Wurmus writes: > >>> These changes from r-updates have effectively jumped the queue past >>> those on the core-updates and gnome-team branches, and since there was >>> never a "Request for merging" issue opened [1],

Re: branch master updated (2bea3f2562 -> 6745d692d4)

Hi, > guix-comm...@gnu.org writes: > >> rekado pushed a change to branch master >> in repository guix. >> >> from 2bea3f2562 gnu: kubo: Unbundle go-cidutil, go-log and go-ipfs-util. >> new 79c2b32337 gnu: r-with-tests: Update to 4.4.0. > > ... > >> new 5ad635ec49 gnu: r-job: Update t

Re: Changing the defaults for --localstatedir and --sysconfdir?

Ludovic Courtès writes: > At this point I think defaulting > to /var and /etc would do more good than harm. Are those the only defaults that should change? These are the only ones we are actively using, but perhaps it would be confusing to have --prefix still point to /usr/local whereas --local

Hackathon: fix build errors on the "master" branch.

Hi Guix, for the past weeks the "master" branch has been in pretty poor state according to ci.guix.gnu.org. It keeps hovering at around 56% progress, which is a far cry from the 80+% we used to have in the old days. A lot of packages are in fact broken. Many more are marked as broken due to a b

Re: API for rewriting package fields ?

Nicolas Graves via "Development of GNU Guix and the GNU System distribution." writes: > Is there an interface to rewrite / update a field from a series of > packages easily? We have "update-package-inputs" in (guix upstream), which defines a local procedure "update-field". Perhaps you can use

Re: Is git the best tool for pulling packages?

Adam writes: > As I see, first guix pull running too long for a lot of people. Note that this is not due to download speeds but often due to compilation. When updating Guix you are not just fetching new data, but a new version of Guix itself (which happens to come with a library encoding packag

Re: Python's native-inputs

> TL;DR : > - patch series in big progress, not done yet because I don't really > know where to stop and massive rebuilds. Please take a look at the python-team branch, which contains changes to the build system. -- Ricardo

Re: Distributed GNU Shepherd NLNet Grant

Hi Juli, > I am happy to announce that this grant application was approved! [2] Congratulations! > Materially, it would allow Shepherd dæmons running on > different machines to securely communicate and interact with each > other, going so far as to control one machine's dæmons from another > mac

Re: Adding plumbing subcommand 'derivation'?

Hi Simon, > So I propose to add the plumbing command ’derivation’. Any objection? I think it's useful to have. To avoid proliferation of sub-commands, do you think we could put this under "inspect", a generic sub-command for all sorts of as yet to be invented introspection tools? -- Ricardo

Re: [python-team] Weird python-notebook test failures

[resending as a wide reply, sorry] Felix Lechner writes: > Hi Ricardo, > > On Sat, Apr 06 2024, Ricardo Wurmus wrote: > >> Any ideas what might be going on here? > > Could it be "ModuleNotFoundError: No module named 'jupyter_server'"? I don't th

[python-team] Weird python-notebook test failures

Hi Guix, on the python-team branch I'm slowly fixing build errors, but I can't figure out what's wrong with python-notebook: https://ci.guix.gnu.org/build/3872654/details Nothing big changed that would explain the build failure. It looks like the notebook server doesn't start and all the er

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

[mu4e must have changed the key bindings for replies, so here is my mail again, this time as a wide reply.] Giovanni Biscuolo writes: > So AFAIU using a fixed "autoreconf -fi" should mitigate the risks of > tampered .m4 macros (and other possibly tampered build configuration > script)? > > IMHO

Re: Backdoor in upstream xz-utils

Tomas Volf <~@wolfsden.cz> writes: > On 2024-03-29 13:39:59 -0700, Felix Lechner via Development of GNU Guix and > the GNU System distribution. wrote: >> > Is there a way we can blacklist known bad versions? >> >> Having said all that, I am not sure Guix is affected. >> >> On my systems, the 'd

Re: guix --container is RAM hungry

raingl...@riseup.net writes: > On 2024-03-21 22:44, Edouard Klein wrote: >> Dear Guixers, >> >> I'm a huge fan of guix --container, and I created a system to use those >> by default for network services. But the VPS these services run on has >> only 2GB of RAM, and I just realized that a contai

Re: PyTorch with ROCm

Hi David, > after seeing that ROCm packages [1] are available in the Guix-HPC > channel, I decided to try and package PyTorch 2.2.1 with ROCm 6.0.2. Excellent initiative! > For this, I first unbundled the (many) remaining dependencies of the > python-pytorch package and updated it to 2.2.1, th

Re: How would you feel about this derivative logo for Nonguix?

Luis Felipe writes: > https://gitlab.com/nonguix/nonguix/-/issues/317 > > That page also mentions the reasoning behind the derivative logo. > > I don't see any issue if Nonguix uses such a logo (specially variant > D2), but what do you think about it? They don't want to upset the GNU > Guix com

Re: Contribute or create a channel?

Hartmut Goebel writes: > In both cases I need some tooling to fetch the current bug-fix version > of the series in question. This can not be done using "guix refresh" > only AFAIU, as this would use the next release-series if this is > already released while our packages are not yet updated. "

Re: GSoC 2024

Gábor Boskovits writes: > Continue rewrite build daemon in Guile Scheme > Ludovic Courtès (civodul) Since this is an ongoing NLnet project I think we should not offer it as a GSoC project this time. -- Ricardo

Re: Contribute or create a channel?

Hi Hartmut, > I'm currently updating Tryton to version 7.0 and am wondering whether it's > better to contribute the change to Guix or to set up a > channel for Tryton. > > WDYT? I'm eager to learn about your thoughts. > > Here is why I'm wondering: > > * Tryton consists of a client, a server an

Re: Contribute or create a channel?

Attila Lendvai writes: >> WDYT? I'm eager to learn about your thoughts. > > the patch inflow to the guix repo is currently overwhelming the > available capacity for review and pushing. With an email like the one sent by Hartmut we can better arrange for shepherding this large submission. (Not

Re: Building container images with nix2container

Antoine Eiche writes: > Ricardo Wurmus writes: > >> We have "guix pack" as part of Guix. It builds Docker or squashfs >> images as well as various other formats. What does nix2container offer >> beyond what we have? > > I acutally don't know

Re: Building container images with nix2container

Antoine Eiche writes: > In case you would like to try nix2container with Guix, in theory, you > would need to add the support of another input reference graph format > [6] and a write simple Guix derivations [7] calling the nix2container > binary. We have "guix pack" as part of Guix. It build

Re: Simple design question for schemers

Hartmut Goebel writes: > Using a custom function "extend": > > (native-inputs > (extend %standard-trytond-native-inputs > trytond-account-invoice > trytond-purchase > trytond-sale)) We have a macro called MODIFY-INPUTS, which you could use, but C

Re: [Cuirass] JavaScript work

Janneke Nieuwenhuizen writes: > I'm wondering though what the net gain of minification is > with current bandwiths. On the few sites that I use javascript on I just > ship the preferred readable code. JavaScript libraries can weigh several megabytes unminified. With minification applied to t

Re: Supporting sssd, preparing for nscd sunset

Hi Ludo, thanks for getting the discussion started. This problem has been weighing on me for the past months and I don't see a good way forward. Ludovic Courtès writes: > For the record, glibc maintainer Carlos O’Donell brought up our use case > a while back on the glibc mailing list but it wa

“guix package -d” on empty profile downloads stuff

Hi Guix, I have a little i686-linux laptop to which I deployed the Sugar desktop. The only user account on that laptop (other than root) has no Guix profile. I switched to that user account and ran “guix package -d”. Here is what happened: --8<---cut here---start

[Cuirass] JavaScript work

Hi, I noticed that Cuirass bundles minified JavaScript. I’ve started a new branch that replaces the minified JavaScript with readable source code and minifies the files as part of the build. I also tried to remove the need for jQuery, at least in our own JavaScript code. (Datatables.js still us

Re: Debugging missing architecture support

Efraim Flashner writes: > As far as tracking back from git-annex to ghc to see that it's not > supported on aarch64, I'm not sure how you would find that information. You can try this in guix repl: --8<---cut here---start->8--- (import (srfi srfi-1)

Re: guix refresh --update Removes Needed Dependencies

"jgart" writes: > Hi Guixers, > > `guix refresh --update` removes Tex Dependencies that are needed. This makes > it more tedious to update packages :( “guix refresh” considers the importers’ output to be authoritative. Can the Python importer be improved to discover the need for TeX things?

Re: Guix Days: Patch flow discussion

Hi Josselin, >>> b4/lei is a nice example (we already have yhetil.org as a back-end, >>> but maybe a more blessed one would be better) of a tool that lets you >>> completely automate applying a patchset to a branch. >>> >>> patchwork is a nice tool to gather up and track patchsets, with status >

Re: Debbugs update (Was: Guix Days: Patch flow discussion)

Hi Felix, > I also packaged and deployed on GNU Guix > > (A) the fifteen-year old Debbugs version deployed at gnu.org [2][3][4] > (B) the modern Debbugs version deployed at debian.org [5][6][7] > (C) and a custom version of Mumi for my own bug fixes [8][9] > > Together with the official de

Re: Introducing Guix "Features"! (Was: Syntactic Diabetes)

> for an average unix user a service is a process that is running in the > backgroud, doing stuff mostly without any user interaction. you can > try to argue this away, but i'm afraid that this is the state of > things. I don’t think it’s a good idea to aim to satisfy some presumed “average unix

Re: 07/07: gnu: Add python-docspec.

Hi Maxim, > I'm not in the Python team, but I thought I'd give some feedback on > recent Python packages added. > > guix-comm...@gnu.org writes: > >> gnu: Add python-docspec. >> >> * gnu/packages/python-xyz.scm (python-docspec): New variable. >> >> Change-Id: I3103bde348327

Re: python importers as an alternative to propagated-inputs

Justin Veilleux writes: > Hi everyone. I was thinking about the propagated-inputs field in package > definitions. As I understand it, it is useful as a way to replace RPATHs > in packages that aren't compiled or don't support them. > > I was reading the documentation on > https://docs.python.or

Re: Separating test inputs?

Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > In Debian, test prerequisites are annotated awkwardly with in > the build prerequisites. (I think Guix calls them native-inputs.) You > can see some of Debian's funny notations here [1] and here. [2] Nativ

Re: Question on python-pydantic update, rust and maturin build tool

Sharlatan Hellseher writes: > It might be addressed to rust/python teams. > https://github.com/pydantic/pydantic-core > > During update of some packages from (gnu packages astronomy) I've faced with > requirement for the fresh version of pydantic which > depends on pydantic-core built with rus

Re: Are declarative app configs worth it?

Nguyễn Gia Phong writes: > [[PGP Signed Part:Undecided]] > [1. text/plain] > On 2023-12-26 at 15:56+01:00, Ricardo Wurmus wrote: >> On 2023-12-26 at 14:53+01:00, Sergey Trofimov wrote: >> > - adding it to guix increases maintenance burden: new versions >> > c

Re: Are declarative app configs worth it?

Attila Lendvai writes: > if you demand that e.g. all services accepted into guix have a > configuration entry for every possible config field, and that the > documentation of these fields are duplicated into the guix > codebase... then whatever is included into guix will have a 100% > coverage.

Re: Are declarative app configs worth it?

Sergey Trofimov writes: > - adding it to guix increases maintenance burden: new versions could > add or remove config options This is why there should be automated tests. There are too few of them. > - it requires documentation/translation, another hidden cost We should only accept confi

Re: arm-none-eabi toolchain and compiling C++ stuff

Attila Lendvai writes: > is that a bug in (gnu packages embedded)? shall i look into fixing it? > > or am i the one who has invalid expectations? FWIW I have successfully been using make-arm-none-eabi-nano-toolchain-4.9 with the Axoloti DSP board (via the axoloti-patcher package). The 2018 to

Re: Request-For-Comment process: concrete implementation

Hi Simon, > Well, more than 7 weeks later… Hum, does it mean that the Guix project > is not interested in formalizing some RFC? > > WDYT about the proposal? I just got back from travels and finally caught up with important email. I read the proposal and it looks good to me. Thank you for worki

Re: Computing a derivation for a profile

Ricardo Wurmus writes: > I would like to compute a derivation for a profile specified by a > manifest. I do not (yet) want to actually build that derivation. “guix build -d -m manifest.scm” also doesn’t quite do what I want. It returns the derivations for all the listed packages,

Computing a derivation for a profile

Hi Guix, I would like to compute a derivation for a profile specified by a manifest. I do not (yet) want to actually build that derivation. This seems like a simple thing to do, but I haven’t been able to accomplish this. Here is one of the things I’ve tried in “guix repl”: --8<---

Re: RFI: Guix XMPP service. paid service?

jbra...@dismail.de writes: > I would like to pay $5 a month to have an xmpp account > coolawesomeusern...@guix.gnu.org > > Are there other interested parties? It might be a possible way to generate > $$ to continue developing guix. I’d rather not commercialize stuff like this, especially not

Re: Should commits rather be buildable or small

Attila Lendvai writes: > i myself also had headaches multiple times when i fixed something that > needed to touch several different packages, and they would only work > when applied in one transaction: > > how many debbugs issues? multiple issues and record the dependencies? > little gain for m

Re: Heisenbug

Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > While executing meta-command: > error: label: unbound variable > >> ,reload > > While this gives > > While executing meta-command: > unknown file name for module # > > Also, what is a meta-command, please?

Re: Should commits rather be buildable or small

Attila Lendvai writes: >> I guess "required" here means that in some cases Guix's policy is to >> prefer small commits over buildable commits (with the previous >> definition). I at least don't see any technical reasons why it would be >> required. The question then becomes whether that policy

Re: Better support remote deployment

Ludovic Courtès writes: > That said, I wonder if this would really be more convenient than SSH’ing > into the target machine and running the commands right there. Perhaps > I’m missing something about the use case? The use case is to have a development host where packages are built and then p

Building and caching old Guix derivations for a faster time machine

Hi Guix, to me the biggest downside of using “guix time-machine” is that it has to do a lot of boring work before the interesting work begins. The boring work includes building Guix derivations for the given channels, most of which have long been collected as garbage on ci.guix.gnu.org. It would

Re: Meet Guix at Capitole du Libre in Toulouse, nov. 18-19

Luis Felipe writes: > El 26/10/23 a las 14:03, Luis Felipe escribió: >> El 25/10/23 a las 21:17, Julien Lepiller escribió: >>> The print service I usually use has a lot of options for flyers, >>> {10,15,20,30}*{10,15,20,30}, 12*12, 21*29.7 and 30*40 cm. I think >>> 15*20 would be best. >>> >>>

Re: Better support remote deployment

Hi Felix, > On Wed, Nov 01 2023, Ricardo Wurmus wrote: > >> What do you think about changing “guix package” and/or “guix copy” to >> better support deployment of remote profiles? > > As someone who uses 'guix deploy' all the time. I believe remote > admini

Better support remote deployment

Hi Guix, I build software locally and deploy the result to a remote system with “guix copy”. This works pretty well but has a few rough edges: 1. “guix build -m manifest.scm” does not generate a profile. It only builds the list of packages. To build a profile from a manifest file we need to re

[cuirass] Typo?

Hi, In (cuirass base) there is this definition: --8<---cut here---start->8--- (define (exception-reporter . results) "Return an exception handler that reports the exception on the error port and returns the values RESULTS." (lambda (key . args) (false-i

Re: doc: Mention the responsibilities that blocking comes with.

Simon Tournier writes: > +concerns are actively resolved with proposals that work for everyone. A > +contributor (which may or may not have commit access) wishing to Should be “who” instead of “which”. > +understand its finer details, you are encouraged to read > +

Re: Re-evaluating the practice of automating user configuration

Maxim Cournoyer writes: > All in all, I guess my position is unchanged: despite the potential for > surprises, automating and enforcing these configs provide benefits that > outweigh the cons, in my experience/opinion. I concur. In light of efforts to reduce cognitive overhead, I think it is

Re: Proposal: Differentiate products more clearly (Cycle 01)

Hi, > 2018-01-17 · website: say what Guix is at the very top > https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00232.html Hey, that’s me! Naturally, I do agree that we need clearer product differentiation and your drafts are pretty and clear as always. On the other hand I’ve always f

Re: performance issue with TeX Live

Emmanuel Beffara writes: > De Nicolas Goaziou le 09/10/2023 à 16:03: >> Emmanuel Beffara writes: >> > I do want to contribute to a solution, because right now texlive is >> > practically unusable in Guix. >> >> FWIW, I use modular TeX Live regularly, so "unusable" is probably a bit >> strong.

Re: Is this a bug in guix refresh with respect to Common Lisp packages?

"jgart" writes: >> These are the 7 packages: > > I didn't get that output from `./pre-inst-env guix refresh -l > sbcl-enhanced-eval-when` > > I get the following: > > [jgart@fedora guix]$ guix refresh -l sbcl-enhanced-eval-when > Building the following 1 package would ensure 7 dependent packag

Re: Is this a bug in guix refresh with respect to Common Lisp packages?

"jgart" writes: > make -j6 && ./pre-inst-env guix refresh -l sbcl-enhanced-eval-when > > I don't see 7 dependent packages that would be rebuilt... Just three. > > Building the following 1 package would ensure 7 dependent packages are > rebuilt: cl-definitions-systems@2.0.1 These are the 7 pac

Re: guix refresh -u weird behaviour

"jgart" writes: > I've experienced this same issue with quite a number of Python > packages that I've tried to import though... Yes, this indicates a defect in the importer. -- Ricardo

  1   2   3   4   5   6   7   8   9   10   >