Re: Teams

Hi Ricardo, Ricardo Wurmus writes: [...] > * Rust team [...] > Maxim Cournoyer [...] I don't think I'm specially fit for Rust packaging (I have little experience/interest in packaging *apps/libraries* with it -- I've only looked into shortening the Rust bootstrap out of

Re: Release v1.4?

Hello, vi...@riseup.net writes: > On 2022-06-06 01:57, zimoun wrote: >> Hi, >> >> On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès wrote: >> >>> guix time-machine --branch=staging -- … >>> >>> Remaining things to check: >>> >>> - [ ] system tests >>> - [ ] status on non-x86_64 architectures

Re: proposal: guix-ment...@gnu.org list/alias

Hello, Ricardo Wurmus writes: > Maxim Cournoyer writes: > >> We'd have to define what are 'new contributors' clearly so that it >> doesn't get flooded/abused though, since the "review" happens behind >> closed doors (in private). > >

Re: On commit access, patch review, and remaining healthy

Hello, zimoun writes: > Hi, > > On Sat, 11 Jun 2022 at 01:13, Thiago Jung Bauermann > wrote: > >> But I do think it's one more source of “friction” for new contributors, >> and one more thing for us to require that they get right. > > [...] > >> There's one in the GNU Coding Standards¹: > > [.

Re: RISCV porting effort

Hello Pjotr, Pjotr Prins writes: > Most of you are probably aware that a RISC-V effort is going on in GNU > Guix. > > Ekaitz is working on the GNU Mes bootstrap and Efraim is porting > packages (gcc and clang are ported), both NLNet projects. Also with > our NSF project we are using GNU Guix for

Re: Set FORCE_SOURCE_DATE=1 by default

Hi Vagrant, Vagrant Cascadian writes: > So, guix sets SOURCE_DATE_EPOCH=1 by default in > guix/build/gnu-build-system.scm, which is great! > > This allows guix packages in many cases to build packages reproducibly, > with a curious side-effect that takes us all back to the early 70s in > some co

Re: Set FORCE_SOURCE_DATE=1 by default

Hi, Vagrant Cascadian writes: > On 2022-06-21, Maxim Cournoyer wrote: >> Vagrant Cascadian writes: >>> So, guix sets SOURCE_DATE_EPOCH=1 by default in >>> guix/build/gnu-build-system.scm, which is great! >>> >>> This allows guix packages in many cas

Re: emacs-jedi package bug missing crucial python server file

Hi, jgart writes: > Hi Guixers, > > Just wanted to report a bug with emacs-jedi: > > This is all that is currently copied into gnu/store: > > jedi-autoloads.el jedi-autoloads.elc jedi-core.el jedi-core.elc > jedi-pkg.el jedi.el jedi.elc test-jedi.el test-jedi.elc tryout-jedi.el > tryout-jedi.elc

Re: Set FORCE_SOURCE_DATE=1 by default

Hi Vagrant, Vagrant Cascadian writes: > On 2022-06-22, Ludovic Courtès wrote: >> Vagrant Cascadian skribis: >> >>> On 2022-06-21, Maxim Cournoyer wrote: >> >> [...] >> >>>> I'd much prefer challenging that stance than "endorsing&q

Re: Set FORCE_SOURCE_DATE=1 by default

Hi Vagrant, [...] >> Perhaps to show our stand here we could patch our copy of pdftex with >> 's/FORCE_SOURCE_DATE/SOURCE_DATE_EPOCH/', lest we end up with a grocery >> list of *SOURCE_DATE* variable variants. > > Sure, with some technical details fixed up, as I think they are > functionally diff

Re: emacs-jedi package bug missing crucial python server file

Hi, Luis Felipe writes: > Hi jgart > > > On Wednesday, June 22nd, 2022 at 03:59, jgart wrote: > >> Hi Guixers, >> > >> Just wanted to report a bug with emacs-jedi: [...] >> I'll try to work on it when I get a chance but feel free to fix it if you >> have the time. >> > >> all best, > > Oh,

Re: Experimental nar-herder support for serving fixed output files by hash

Hi, [...] > What I was getting at here though, ignoring the implementation, was > whether this is worthwhile to do? As in, is there benefit to having this > and being able to extend the content addressed mirrors that Guix uses? It's an effort/reward analysis that you are in the best position to

Re: Why do Emacs packages still pull emacs-transient?

Hi Jorge, "Jorge P. de Morais Neto" writes: > Hi. To begin, thank you for your work on GNU! > > I use Guix package manager (manually installed) atop Debian bullseye. > My Emacs is from Guix package emacs-next with a package transformation > option to pull from current Git master. When I tried

Broken lisp-fill-paragraph post Emacs 28 update

Hi, If you too have been wondering why hitting M-q on package descriptions doesn't produce the intended effect anymore (the first line of text protrudes beyond the fill-column value), this may be of interest. The problem was introduced in commit 9bf367e1848, which aimed to improve the handling of

Re: Broken lisp-fill-paragraph post Emacs 28 update

Hi, Ricardo Wurmus writes: > Hi Maxim, > >> The problem was introduced in commit 9bf367e1848, which aimed to improve >> the handling of Elisp docstrings. To revert to the old version (the one >> that shipped with Emacs 27), you can put this in your .emacs: >> >> (require 'lisp-mode) >> (defun l

Re: [WIP Patch] Adding an FHS container to guix shell

Hi John, John Kehayias writes: > Hi Guixers, > > Apologies for the long email, so let me start with the punchline: > attached is a diff which adds an '--fhs-container' (or -F) option to > guix shell/environment to set up an FHS-like container. This includes > the usual /lib directory and a glibc

Re: [WIP Patch] Adding an FHS container to guix shell

Hi, I forgot to add, this would of course need to be documented in our 'Invoking guix shell' section of the manual. Thanks, Maxim

Enabling tracing on a phase to debug?

Hello Guix, I was toying with the idea to programatically enable tracing the execution of a single build phase to aid with debugging, and came up with this with the help of robin on #guix (thanks!) --8<---cut here---start->8--- @@ -4349,7 +4349,19 @@ (define-pu

Re: bug#55026: potential prebuilt binaries in the Mono package

Hi, zamfofex writes: > It seems the package for Mono in Guix uses a tarball that contains a > lot of prebuilt DLLs. This doesn’t seem to have been mentioned when > the package was introduced. Could it have been a mistake? Some related > discussion: and

Re: Repology and outdated packages

Hi, Vagrant Cascadian writes: > On 2022-06-07, Nicolas Goaziou wrote: >> kias...@disroot.org writes: >> >>> I've been watching the Repology page for Guix and I've noticed that >>> we've dropped to 51% outdated packages >>> [https://repology.org/repository/gnuguix]. We used to be at 40% >>> outda

Re: network maintenance affecting ci.guix.gnu.org

Hi Ricardo, Ricardo Wurmus writes: > Hi, > > on Wednesday, August 17th between 05:00am and 09:00am UTC+2 there will > be network maintenance in data centre hosting the build farm > ci.guix.gnu.org. The build farm may not be available intermittently > during the maintenance window. Thanks for t

Re: [RFC] Use LLVM_BUILD_LLVM_DYLIB instead of BUILD_SHARED_LIBS

Hi, Zhu Zihao writes: > # Background > > Now in Guix. LLVM is built with configure flag > "-DBUILD_SHARED_LIBS:BOOL=TRUE". According to > https://llvm.org/docs/CMake.html. Build LLVM with `BUILD_SHARED_LIBS` is > not recommended for non LLVM developing usage. LLVM says that packager > should use

Re: 04/04: gnu: Add fwupd.

Hi, guix-comm...@gnu.org writes: > civodul pushed a commit to branch master > in repository guix. > > commit 23152ff70f0ed4966d8207846f54c793d7cb4f86 > Author: Petr Hodina > AuthorDate: Tue Jan 4 06:58:51 2022 +0100 > > gnu: Add fwupd. > > * gnu/packages/firmware.scm (fwupd): New va

Re: Clarify the license field of the package

Hi, Maxime Devos writes: [...] > However, keep in mind that sometimes a file is part licensed as, say, > BSD(*), part as Expat, with modifications under the GPL -- to me it > appears that for practical purposes you could consider such a thing to > be 'effectively GPL', but that's not 100% accur

Re: 04/04: gnu: Add fwupd.

Hello Denis, Denis 'GNUtoo' Carikli writes: > Hi, > > On Wed, 31 Aug 2022 09:26:21 -0400 > Maxim Cournoyer wrote: >> > commit 23152ff70f0ed4966d8207846f54c793d7cb4f86 >> > Author: Petr Hodina >> > AuthorDate: Tue Jan 4 06:58:51 2022 +0100 >&

Re: bug#55026: potential prebuilt binaries in the Mono package

inaries (see > https://github.com/dotnet/source-build/issues/1930) > > > > > > > At 2022-08-13 04:03:43, "Maxim Cournoyer" wrote: >>Hi, >> >>zamfofex writes: >> >>> It seems the package for Mono in Guix uses a tarball that conta

Re: [RFC] Use LLVM_BUILD_LLVM_DYLIB instead of BUILD_SHARED_LIBS

Hi Maxime, Maxime Devos writes: > On 20-04-2022 12:56, Zhu Zihao wrote: >> We may introduce following problems if we apply this solution. >> >> 1. Increase the closure size of LLVM. >> >> By default, if LLVM_BUILD_LLVM_DYLIB is set true, LLVM still tries to >> build the static archive. This may

Re: Follow Ten Years of Guix remotely

Hello! Ludovic Courtès writes: > Hello Guix! > > The Ten Years of Guix event will start in just a couple of days: > > https://10years.guix.gnu.org > > If you’re not coming to Paris, we have some good news: talks will be > recorded and the event will be live-streamed! > > https://10years.guix

Re: Emacs integration for 'guix shell'

Hi, Olivier Dion via "Development of GNU Guix and the GNU System distribution." writes: [...] > I have the following in my .dir-locals.el for my library libpatch. The > idea is the same, but without direnv: > > ((nil > . ((eval . > (let ((root (locate-dominating-file >

Re: Some concerns on the current situation on Go packaging

Hi Gabriel, Gabriel Arazas writes: > Hello! I'm a bit concerned about the current situation of packaging of > Go applications in Guix. > > Go modules also use semantic versioning [1] similarly to Rust > packages. In Guix, some of the Rust packages are packaged with > different versions [2]. This

Re: Emacs integration for 'guix shell'

Hi, "Thompson, David" writes: > On Mon, Sep 26, 2022 at 10:44 PM Maxim Cournoyer > wrote: >> >> Hi, >> >> Olivier Dion via "Development of GNU Guix and the GNU System >> distribution." writes: >> >> [...] >> &g

Re: Hostile takeover of the matrix room

Hi, Jacob Hrbek writes: > I've been informed that during transfer of #guix:matrix.org on > #guix:tchncs.de Tobias Geerinckx-Rice (nckx) was able to stage a > hostile takeover over the room and banned me from the new one. This would have been better addressed to guix-maintain...@gnu.org alias, w

Re: git guix checkout automation for contributors

Hi, Ludovic Courtès writes: > Hi! > > Danny Milosavljevic skribis: > >> (1) Install the guix system >> (2) Log in as regular user >> (3) guix edit nano >> (4) It opens a file from /gnu/store that you cannot edit. > > At one point, I thought we could have, say: > > guix edit --clone PKG > > It

Re: bug#58417: Installer script no longer works with `yes` utility

Hi, Tobias Geerinckx-Rice writes: > [Shunted to guix-devel@] > > Jonas Freimuth 写道： >> bash -c 'yes | bash guix-install.sh' > > While this happens to work (again) now, that doesn't mean it always > will or should be considered supported. > > We should reserve the right to ask future questions to

Re: bug#58417: Installer script no longer works with `yes` utility

Hi again, Tobias Geerinckx-Rice writes: > [Shunted to guix-devel@] > > Jonas Freimuth 写道： >> bash -c 'yes | bash guix-install.sh' > > While this happens to work (again) now, that doesn't mean it always > will or should be considered supported. > > We should reserve the right to ask future questi

Re: bug#58417: Installer script no longer works with `yes` utility

Hi Simon, zimoun writes: [...] >> Conversely, I'd like to add a comment that does commit to always >> keeping ‘yes '' | bash guix-install.sh’ working, assuming there >> was no other input or detected issues. Also nice for humans in a >> hurry. >> >> Does that seem unreasonable to anyone? >

Re: bug#58417: Installer script no longer works with `yes` utility

Hi, zimoun writes: > Hi Maxim, > > On dim., 16 oct. 2022 at 21:22, Maxim Cournoyer > wrote: > >> If I understood Tobias, they were not suggesting to make the >> non-interactive installation use case harder/impossible, just to change >> it from 'yes | .

Re: Add earlyoom service to %desktop-services?

Hi, jbra...@dismail.de writes: > October 17, 2022 7:24 AM, "Pkill9" wrote: > >> I think that the earlyoom service is a necessity for a Guix system >> desktop. >> >> For those who don't know what it does, EarlyOOM (early out-of-memory) >> is a daemon that kills applications when the amount of me

Re: Packages depending on (guix build syscalls)

Hi Ludo, Ludovic Courtès writes: > Hello Guix! > > (Resending to the right mailing list, oops!) > > Quite a few packages depend on (guix build syscalls), starting from > ‘ant-bootstrap’ (since commit cded3a759356ff66b7df668bcdbdfa0daf96f4c5 > in 2018) up to GNOME-related packages such as ‘mutter

Re: Could the Go importer use the Go toolchain? (was Re: Go importer and packages with version flags)

Hi François, Good to see interest being picked up on the Go front. François writes: > Hello, > > After a hiatus I am trying to package several softwares written on Golang > (I would like to have terraform and go-jsonnet for example) and I have > some problems with the current implementation so

Re: Types and builds for mypy

Hi, Philip Beadling writes: > Hi all > > Users of mypy and python will have noticed since the promotion of mypy to v0. > 971 it is now neccesary to provide separate python packages containing types > of non core libraries. > > The way we've been collecting these, outside of Guix proper, is in

Re: Packages depending on (guix build syscalls)

Hello, Ludovic Courtès writes: > Hello Guix! > > (Resending to the right mailing list, oops!) > > Quite a few packages depend on (guix build syscalls), starting from > ‘ant-bootstrap’ (since commit cded3a759356ff66b7df668bcdbdfa0daf96f4c5 > in 2018) up to GNOME-related packages such as ‘mutter’

Re: How long does it take to run the full rustc bootstrap chain?

Hi, Félix Baylac Jacqué writes: > Hey Guix, > > I'd be curious to know how long it takes to run the full rustc bootstrap > chain on the Guix build farm. I'm sadly not sure how to approach this > problem. > > Is there a way to extract this information from Cuirass or the Guix data > service? > >

Re: Types and builds for mypy

Hi Phil, Phil writes: > Thanks for your reply Maxim, > > Maxim Cournoyer writes: > > >> Is MyPy the only consumer of Python type annotations? I think so, but >> I'm not sure. If it's the only one, it'd make sense to move mypy and >> all the an

Re: Packages depending on (guix build syscalls)

Hello, Efraim Flashner writes: [...] >> It is great to have ‘font-abattis-cantarell’ built from source (since >> commit 97766323bc6e2b4dcfba4d6b46749a4280bca709), but it’s costly. >> >> There’s probably not much we can do, unless the python-afdko -> icedtea >> dependency is optional. >> >> Id

Re: How long does it take to run the full rustc bootstrap chain?

Hi, b...@bokr.com writes: [...] > I'm curious what > > $ lsblk -o size,model,type,tran,vendor,name|grep -Ei 'ssd|model';echo;lspci > |grep -i nvme > > on your relevant machines would show. > > I opted for the best SSD available for my purism librem13v4 at the time, > and was really happy with s

Re: How long does it take to run the full rustc bootstrap chain?

Hi Bengt, Bengt Richter writes: [...] >> Building Rust is mostly CPU dependent; I think fast single thread >> performance is key as not that much happen in parallel, IIRC. The 3900X >> is a 12 cores (24 logical) beast. >> > > Hm, just TRAN sata, no nvme, so it's going to be slow, but > what is

Monthly maintainers' meeting notes

Hello Guix! I've uploaded the latest maintainers meeting notes, that are mostly focused on the current release. You'll find them at [0]. [0] https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc /maintainers/meetings/2022-11-02.org You can help us getting the release out by looking at

ci.guix.gnu.org and associated services downtime

Hi, There is currently an outage with Berlin, which hosts the build farm, the web site, the issue tracker and a host of other Guix services. Simply rebooting the machine doesn't fix it and it seems it may has to do with the disk controller or the disk itself, so sadly it seem it'll take some befo

Re: Release progress, week 3

Hi, Andreas Enge writes: > Hello, > > mpfr-4.1.1 is expected to be released tomorrow: >https://sympa.inria.fr/sympa/arc/mpfr/2022-11/msg0.html > > I do not expect there to be any breakage (this is a bugfix release), > but adding it would require to recompile everything. > > Is this feasi

Re: Proposing commit access for 'unmatched-paren'

Hi Felix, Felix Lechner writes: > Hi, > > As a new user, I needed lots of help. I also use software that is not > packaged in Guix. > > In preparing my patches for submission I relied extensively on the > guidance so generously offered by the IRC user 'unmatched-paren'. I > thoroughly appreciate

Re: guix import pypi fails if one of the transitive deps has no source on PyPi

Hi jgart, jgart writes: > I realize this may be a feature some may want but then we get no template > to work from because `guix import pypi` is to heavy handed: > > $ guix import pypi neoscore -r > > Starting download of /tmp/guix-file.HrGkox > From > https://files.pythonhosted.org/packages/f8

Re: help wanted: upgrade llvm to 15

Hi, dan writes: > hello guix, > > i'm totally new to guix and free software development, so bear me if > i'm doing something wrong. > > the 0.10 version of zig just got released[1], with the new self-hosted > compiler. during the period of development, i've also submitted a > pull request[2] fo

Re: Should wsl-boot-program create XDG_RUNTIME_DIR?

Hi Dan, dan writes: > Hello guix, > > Even since the WSL image was pushed to master branch, I've been > spending time experimenting with it. It almost runs smoothly, unless > two points: > > 1. when logged in, there is a warning says: >> warning: XDG_RUNTIME_DIR doesn't exists, on-first-login s

Re: Layout of ‘define-configuration’ records

Hi Ludo, Ludovic Courtès writes: > Hi, > > Maxim Cournoyer skribis: > >> This is so that the first field of the generated record matches the first one >> declared, which makes 'define-configuration' record API compatible with >> define-record-type* ones

Re: 01/03: gnu: lld-as-ld-wrapper: Add version 15.

Hi, Marius Bakke writes: > Christopher Baines skriver: [...] >> I spotted this change when looking at [1] as the Guix Data Service is >> failing at extracting a consistent derivation for lld-as-ld-wrapper@0. >> >> 1: https://qa.guix.gnu.org/issue/59367 >> >> Maybe that could be viewed as a bu

Re: Layout of ‘define-configuration’ records

Hi Katherine, Katherine Cox-Buday writes: > Maxim Cournoyer writes: > >>> Moving the field last is problematic as we’ve seen for any user that >>> uses ‘match’ on records—something that’s not recommended but still >>> used a lot. > > Some feedback I hope

Re: Layout of ‘define-configuration’ records

Hi, Ludovic Courtès writes: > Maxim Cournoyer skribis: > >> A side-note, it seems that Ludovic has been >> working toward eliminating the use of match patterns matching the fields >> directly, instead encouraging the use of 'match-record', see >> https

Re: ci.guix.gnu.org and associated services downtime

Hi, zimoun writes: > Hi Maxim, > > I am replying a bit late… > > On Thu, 10 Nov 2022 at 16:42, Maxim Cournoyer > wrote: > >> There is currently an outage with Berlin, which hosts the build farm, >> the web site, the issue tracker and a host of other Guix

Re: Layout of ‘define-configuration’ records

Hi Katherine, Katherine Cox-Buday writes: > Maxim Cournoyer writes: > >> Apologies for causing grief! > > No worries at all, Maxim! The good you do far outweighs any grief, and > even if that weren't the case, we're only human :) > >> I'm taking

Re: Layout of ‘define-configuration’ records

Hi, Ludovic Courtès writes: > Hi Maxim, > > Maxim Cournoyer skribis: > >> Ludovic Courtès writes: > > [...] > >>>> + (%location #,(id #'stem #'stem #'-location) >>>> +

RFC: libgit2 is slow/inefficient; switch to git command?

Hi, While attempting to bisect against the Linux kernel tree, the performance of libgit2 quickly became problematic, to the point where simply cloning the repo became a multiple hours affair, using upward to 3 GiB of RAM for the clone and indexing of the objects (!) Given that: * the git CLI doe

Re: Layout of ‘define-configuration’ records

Hi Ludovic, Ludovic Courtès writes: > Hi, > > Maxim Cournoyer skribis: > >> Ludovic Courtès writes: [...] >> Ah! Thanks for pointing my silly mistake. Then the argument would >> become... if it's good for define-configuration, it should have been >&

Re: Layout of ‘define-configuration’ records

Hi Simon, zimoun writes: > Hi Maxim, > > On Mon, 21 Nov 2022 at 16:00, Maxim Cournoyer > wrote: > >> That sounds very appropriate indeed. I guess we could send >> announcements on API breaking changes to both places. I suppose not >> many people are re

Guile debugger workgroup? (was: Coding style: similarly-named variables)

Hi Simon, zimoun writes: > Hi Maxim, > > On Mon, 21 Nov 2022 at 15:55, Maxim Cournoyer > wrote: > >> In practice since using breakpoints/a debugger to debug Guile code >> rarely works as intended (in my experience hacking on Guix!), we >> typically sprink

Re: Guile debugger workgroup?

Hi Ludovic, Ludovic Courtès writes: > Hi, > > Maxim Cournoyer skribis: > >> I also agree! It's hard to convince people to pick Guile for their >> project when there is: >> >> 1. Lack of a debugger that can break and step anywhere in your source >>

Re: Guile debugger workgroup?

Hi Simon, zimoun writes: [...] > Racket is an example of functional programming and live coding. Haskell > is another; it is functional programming and if I might, I would > recommend to give a look at the interactive GHCi debugger [1]. > > Back to the initial example [2]. Racket is able to s

Re: Guile debugger workgroup?

Hi Attila, Attila Lendvai writes: > coming from common lisp (and SBCL in particular), i think the lowest > hanging fruit in the guile debugging experience is making sure that > backtraces are not cut short when printed. > > i tried multiple ways to configure the printer to acquire more info, > b

Re: Guile debugger workgroup?

Hi, Attila Lendvai writes: >> The scenario you describe above should be possible above (there is a >> debugger that supports breakpoints and single stepping). Now, it may >> be, as you wrote, that inlining can lead breakpoints to never be hit, or >> that there are bugs in this area. These things

Re: Licence of the Guix blog posts

Hi, Ludovic Courtès writes: > Hello Guix! > > You might remember that I started long ago asking people who had > contributed to the blog whether they would agree to licensing their work > under CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant > Sections, no Front-Cover Texts, and no

Potential minor API change notice

Hello, This is a heads up to let you know that the %BASE-PACKAGES-DISK-UTILITIES public variable exported from (gnu system) may be removed in the near future. For the rationale and more details, see the proposed change [0]. [0] https://issues.guix.gnu.org/59661#1 Thanks, Maxim

Re: Remove lash

Hi, Ludovic Courtès writes: > Hi, > > Ricardo Wurmus skribis: > >> on a modern Guix System with Gnome we’re pulling in Python 2. That’s >> because gtk uses lash, and lash (last commit was 14 years ago) comes >> with Python bindings — for Python 2. >> >> I’d like to propose one of the following

Re: Potential minor API change notice

Hi Ludo, Ludovic Courtès writes: > Hi, > > Maxim Cournoyer skribis: > >> This is a heads up to let you know that the >> %BASE-PACKAGES-DISK-UTILITIES public variable exported from (gnu system) >> may be removed in the near future. > > If the patch eventu

Circular dependency woes with gcc variables

Hi, After struggling for a couple hours (!) with top level cycles when attempting to use the procedures from (gnu packages cross-base), I've decided to try to have top level pre-defined variables for these in a new module. The idea was that a new module could minimize the inter-dependencies at th

Re: Potential minor API change notice

Hi Ludovic, Ludovic Courtès writes: > Maxim Cournoyer skribis: > >> Ludovic Courtès writes: >> >>> Hi, >>> >>> Maxim Cournoyer skribis: >>> >>>> This is a heads up to let you know that the >>>> %BASE-PACKAGES-DI

Re: branch master updated: doc: Recommend avoiding execl, execle or execlp in mcron job specifications.

Hi Ludovic, Ludovic Courtès writes: > Hello, > > guix-comm...@gnu.org skribis: > >> diff --git a/doc/guix.texi b/doc/guix.texi >> index e547d469f4..caa6976a82 100644 >> --- a/doc/guix.texi >> +++ b/doc/guix.texi >> @@ -18940,9 +18940,8 @@ gexps to introduce job definitions that are passed >> to

Re: Release progress, week 8

Hi Simon, zimoun writes: > Hi Ludo, > > On Fri, 02 Dec 2022 at 23:45, Ludovic Courtès wrote: > >> I started writing super long release notes (a book!), comments welcome: >> >> >> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/gnu-guix-1.4.0-released.md >> >> Comm

Re: Potential minor API change notice

Hi Katherine, Katherine Cox-Buday writes: > Maxim Cournoyer writes: > >> This is a heads up to let you know that the >> %BASE-PACKAGES-DISK-UTILITIES public variable exported from (gnu >> system) may be removed in the near future. >> >> For the rational

Re: GNU Guix 1.4.0rc2 available for testing!

Hello, Roman Scherer writes: > Hi Ludo, > > I tested the foreign distro installation of > guix-binary-1.4.0rc2.aarch64-linux.tar.xz > on Asahi Linux. I went through the installation without any problems. And I tested the installation of 'guix-binary-1.4.0rc2.armhf-linux.tar.xz' on top of a ver

Re: shepherd: prefix output with service names?

Hi Ricardo, Ricardo Wurmus writes: [...] > What do you think of prefixing every line with the name of the service > that is responsible for it? This way we could probably also > prettify/post-process the output somewhat. I think that's a great idea; I'm not sure if you've noticed, but mcron i

Re: u-boot-am335x-boneblack -> u-boot-am335x-evm-boneblack

Hi Vagrant, Vagrant Cascadian writes: > Wondering what necessitated this change from the old variable name to a > new name... > > commit c04528d2a2597d79278833f3607c806278253446 > Author: Maxim Cournoyer > Date: Tue Dec 20 21:25:27 2022 -0500 > > gnu: u-boot-a

Re: u-boot-am335x-boneblack -> u-boot-am335x-evm-boneblack

Hi Vagrant, Vagrant Cascadian writes: > On 2022-12-22, Maxim Cournoyer wrote: >> Vagrant Cascadian writes: >> >>> Wondering what necessitated this change from the old variable name to a >>> new name... >>> >>> commit c04528d2a2597d792

Re: GNU Guix 1.4.0 released

Hi Ludovic, Ludovic Courtès writes: [...] > • Changes in 1.4.0 (since 1.3.0) > > ** Package management > *** New ‘guix home’ command, for home environment management > *** New ‘guix shell’ command, the successor to ‘guix environment’ > *** New ‘guix system edit’ command, to edit service

[PATCH] gnu: u-boot-am335x-boneblack: Revert to old name.

This reverts to the name this package had previous to commit c2c1dfdf5760873f1db86d14873f725a105f7feb ("gnu: bootloader: Add U-Boot packages for Raspberry Pi models."), which caused the package name to be derived from the board name. * gnu/packages/bootloaders.scm (u-boot-am335x-evm-boneblack): Re

Re: [PATCH] gnu: u-boot-am335x-boneblack: Revert to old name.

Hello, Vagrant Cascadian writes: > On 2022-12-28, Maxim Cournoyer wrote: >> This reverts to the name this package had previous to commit >> c2c1dfdf5760873f1db86d14873f725a105f7feb ("gnu: bootloader: Add U-Boot >> packages for Raspberry Pi models."), whic

Re: GNU Guix 1.4.0 released

Hi Ludo, Ludovic Courtès writes: > Hi! > > Maxim Cournoyer skribis: > >> Congrats, and yay! It's a hell of a release! :-) Let's try to make more >> punctual ones from now on, and also try to lower the amount of manual >> labor producing one incurs (b

Re: Bogus ‘etc/teams.scm’ usage recommendations?

+CC 58...@debbugs.gnu.org Hi, Simon Tournier writes: > Hi Ludo, > > On Tue, 03 Jan 2023 at 23:29, Ludovic Courtès wrote: > >> The manual recommends this (info "(guix) Teams"): >> >> git send-email --to issue_num...@debbugs.gnu.org $(./etc/teams.scm cc >> mentors) *.patch >> >> where: >> >>

Re: Bogus ‘etc/teams.scm’ usage recommendations?

+CC 58...@debbugs.gnu.org Hi, Simon Tournier writes: > Hi Ludo, > > On Tue, 03 Jan 2023 at 23:29, Ludovic Courtès wrote: > >> The manual recommends this (info "(guix) Teams"): >> >> git send-email --to issue_num...@debbugs.gnu.org $(./etc/teams.scm cc >> mentors) *.patch >> >> where: >> >>

Re: Updating Guix's packaged GNU/Hurd

Hi, Joshua Branson writes: > Hey Guix, > > I follow bug-h...@gnu.org pretty religiously (it's super entertaining), > and there has been work on a new cross-hurd branch, which are some > scripts for cross-compiling and creating an up-to-date Hurd system: > > https://github.com/flavioc/cross-hurd

Re: bug#58813: can't substitute etc/teams.scm command as doc suggests

Hi Ludovic, Ludovic Courtès writes: > Hi, > > Maxim Cournoyer skribis: > >> Simon Tournier writes: >> >>> Hi Ludo, >>> >>> On Tue, 03 Jan 2023 at 23:29, Ludovic Courtès wrote: >>> >>>> The manual recommen

Re: bug#58813: can't substitute etc/teams.scm command as doc suggests

Hi Simon, Simon Tournier writes: > Hi, > > On Mon, 09 Jan 2023 at 15:52, Maxim Cournoyer > wrote: > >> It wouldn't change; patman would be hinted at briefly with a reference >> to its documentation (info '(u-boot) Patman patch manager' from the >

Proposed (guix platforms) lookup procedures API change

Hello, There is currently a proposed change [0] to modify the behavior of the LOOKUP-PLATFORM-BY-SYSTEM, LOOKUP-PLATFORM-BY-TARGET and LOOKUP-PLATFORM-BY-TARGET-OR-SYSTEM public procedures from (guix platforms) that would have them return an exception instead of #f when no platform could be found.

Re: Packages grow, no longer fit on a 💾

Hi, Liliana Marie Prikler writes: [...] >> We should do better.  I mean, it’s just a text editor, isn’t it? > Well, gedit is also "just an editor" which weighs 1GB (compared to > 880MB for Emacs) in v1.3.0 and 1.3GB in v1.4.0 (mozjs?). I think we > ought to look into duplicate references being

Re: Packages grow, no longer fit on a 💾

Hi Liliana, Liliana Marie Prikler writes: > Am Sonntag, dem 15.01.2023 um 21:09 -0500 schrieb Maxim Cournoyer: >> Hi, >> >> Liliana Marie Prikler writes: >> >> [...] >> >> > > We should do better.  I mean, it’s just a text editor, isn’t

Re: Exception: srfi-35 vs (ice-9 exceptions (was Re: [bug#60802] [PATCH v2 1/2] platforms: Raise an exception when no suitable platform is found.)

Hi Simon, zimoun writes: > Hi Maxim, > > On Mon, 16 Jan 2023 at 12:46, Maxim Cournoyer > wrote: > >>> So far the we use (srfi srfi-35) exclusively to define condition types; >>> I think we should do the same here, for consistency. >> >> Could we

Re: Packages grow, no longer fit on a 💾

Hi, Simon Tournier writes: [...] > Yeah for sure. :-) Although, from my point of view, the main issue is > about a policy for package inclusion; I mean there is no secret: light > images means images with less features. :-) > > My personal and biased opinion is that Guix should follow minimalis

Uniformly treating native-inputs in native or cross build contexts

Hello Guix, In #60857, I've unified the cross/standard builders for the pyproject-build-system; even their bags representation are now shared. It enables fixing things such as #25235. Going forward, I think it'd be beneficial to apply the same strategy to other build systems, for consistency and

configurable guile backtrace in builder (was: services: base: Add extra-env support to guix-configuration)

+CC guix-devel Hello! Ludovic Courtès writes: > Hi! > > Maxim Cournoyer skribis: > >> Side topic: I wonder if (with some changes to the daemon -- perhaps in >> DerivationGoal::startBuilder) in nix/libstore/build.cc we could leak the >> COLUMNS variable to be abl

Re: Resurrecting top-notch continuous integration for Guile

Hi! Ludovic Courtès writes: > Hi! > > Ludovic Courtès skribis: > >> There’s still much tweaking we can do, but the basics are in place, and >> I find it pretty cool. :-) If there are no objections, I’ll merge this >> branch into “main”. It’s going to be nice to have a dashboard to look >> at

Re: configurable guile backtrace in builder

Hello, Ludovic Courtès writes: > Hi Maxim, > > Maxim Cournoyer skribis: > >> Ludovic Courtès writes: > > [...] > >>> Maxim Cournoyer skribis: >>> >>>> Side topic: I wonder if (with some changes to the daemon -- perhaps in >>>

  1   2   3   4   5   6   7   8   9   10   >