Re: Thoughts on setting a minimum requirement for committing changes, and the contribution model in general.

Hilton Chain writes: I appreciate your work and I think it would be valuable if you can share what can be improved in [1] based on your experience. [1]: https://guix.gnu.org/manual/devel/en/html_node/Bulk-Updates.html Running `guix refresh` is only the first step. In almost every upgrade

Re: Thoughts on setting a minimum requirement for committing changes, and the contribution model in general.

Attila Lendvai writes: My work on Guix is dominated by bulk upgrades of hundreds of R packages. There is no point in submitting the upgrades individually. In fact, my work on Guix has become so dominated by this is somewhat tangential, but guix is the first project in my entire programmer c

Re: Thoughts on setting a minimum requirement for committing changes, and the contribution model in general.

Liam Hupfer writes: Ricardo Wurmus writes: My work on Guix is dominated by bulk upgrades of hundreds of R packages. There is no point in submitting the upgrades individually. In fact, my work on Guix has become so dominated by R upgrades that I barely ever get to do much else. This

Re: Revisiting the "ChangeLog" style.

Maxim Cournoyer writes: What about the double spaces convention? Would you favor dropping it as well? We have it because that makes it easy for Emacs to navigate between sentences. (It may have been repurposed from the previously widespread typing convention on typewriters.) -- Ricardo

Re: Thoughts on setting a minimum requirement for committing changes, and the contribution model in general.

Hilton Chain writes: - Require all changes to be submitted first. This is actually enforcing the commit policy[2]. I was critical of that policy back then and dependent on what "submit" exactly means I think there are cases where it's an obstacle. My work on Guix is dominated by

Re: guix refresh error

Paul Garlick writes: Are others seeing this too? Yes, this has been reported as issue #78126. -- Ricardo

Re: Codeberg migration check list

Ludovic Courtès writes: - [ ] Git repository imported *Sunday* - [ ] git.guix.gnu.org redirect changed to codeberg.org/guix *Sunday* I'm a little confused about this. We currently have https://codeberg.org/guix/guix-mirror . Will this remain? Will its size be an obstacle to import

Re: Package inheritance doesn't inherit name

"nomike (they/them)" writes: #+BEGIN_QUOTE All unspecified fields are inherited from the parent package. #+END_QUOTE But obviously this is not the case, as you get a compile error from guile when you omit the name from a derived package. The errors only happen when other fields reference "

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Ludovic Courtès writes: Ricardo Wurmus writes: Noé Lopez writes: I guess its for style points, which I’m all for. I do think it would be better to set the URL to git.guix.gnu.org/guix/guix.git and just a DNS redirect to codeberg to avoid the extra connection. I second this. I think

Re: bug#76296: [PATCH maintenance] hydra: bayfront: Set up ‘git.guix.gnu.org’ as a redirect to Savannah.

Noé Lopez writes: I guess its for style points, which I’m all for. I do think it would be better to set the URL to git.guix.gnu.org/guix/guix.git and just a DNS redirect to codeberg to avoid the extra connection. I second this. I think a DNS level redirect would be sufficient. I'd prefer

Re: Committers: create and share your Codeberg account

Ludovic Courtès writes: If you’re a committer, please consider creating an account on Codeberg. To avoid problems, I suggest you send your account name as a public reply to this message, in a signed message. This is me: https://codeberg.org/rekado -- Ricardo signature.asc Descripti

Re: Why are the git submodules not being cloned?

"nomike (they/them)" writes: I'm trying to package a more recent nightly version of openscad[0] with this package definition[1]. Even though I use =(recursive? #t)= within =(git-reference)=, the submodule directories in the build directory (e.g. =/tmp/guix-build-openscad-nightly--2025.04.2

Re: Deliberation period for GCD 003 "Rename the default branch" has technically started

I accept. -- Ricardo

Re: GCD 004 deliberation

Andreas Enge writes: Am Thu, Apr 10, 2025 at 10:24:13AM +0200 schrieb Ludovic Courtès: It is disappointing that the proposal did not get more attention; we’ll have to assess to what extent this is due to the process itself. Well, to give a bit of feedback, for me this GCD had the opposite

FYI: I'll be away from June to October (inclusive)

Hi Guix, I'll be mostly away from computers from June until the end of October. Concretely, this will have the following effects: - no work on R or bioinformatics packages - no reviews or responses to requests for mentoring - no work on the guix-science project, or the guix-cran / guix-bioc

Re: A silly concern about substitute servers

Pan Xie writes: 1. Does a substitute server keeps all the packages it build? If the answer is yes, won't it consume huge storage resources? If the answer is no, then the user who use time-machine travel back to     years before have to build all the packages from scratch? You are correct o

Jumping the queue: merge r-team before python-team?

Hi Guix, the r-team branch has been ready for weeks. It has only accumulated more changes (like the upgrade of R itself) as it has been sitting in the queue. What do you think about letting this branch jump the queue ahead of python-team? -- Ricardo

Re: chez scheme can't load system shared library

André A. Gomes writes: Pan Xie writes: scheme can't start up with LD_LIBRARY_PATH set: $ LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH scheme Segmentation fault (core dumped) $ LD_LIBRARY_PATH='/usr/lib' scheme Segmentation fault (core dumped) The question by Pan has been answered but I have

Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg

Ludovic Courtès writes: c) A discussion allowing write-access for dedicated branches. Opening a PR gives access to a dedicated branch; I suppose that would be the main approach, available to everyone. Getting a dedicated branch on the guix/guix repo wouldn’t be different from now

Re: emacs-next periodic updates

Gabriel Santos writes: I managed to update emacs-next-minimal to db0bed7a68cd2308eba61247a6a77f73533ffef6 The only package that didn't build properly was emacs-next-pgtk-xwidgets: checking for webkit2gtk-4.1 >= 2.12 webkit2gtk-4.1 < 2.41.92... no checkinbg for webkit2gtk-4.0 >= 2.12 webkit2g

Re: Automatic tagging by team on mumi

Hi Arun, mumi now automatically tags issues by team. You can try queries like "tag:team-games", "tag:team-python date:1m..", etc. This is probably the biggest quality of life improvement I've witnessed since mumi came along. Bravo! (It is with a happy befuddlement that I observe apparentl

Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg

Suhail Singh writes: Ludovic Courtès writes: As for experimenting, I agree and I reiterate my invitation to send trivial patches to (or to Guix-Science, Guix-Past, etc.). I think this GCD’s discussion period is the right time to give it a try as it can

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

Felix, On Fri, Mar 07 2025, Ricardo Wurmus wrote: I'd rather work on Guix. Then why is there a backlog of bugs? This is such an odd thing to ask, I cannot convince myself that it's a serious question asked in good faith. Surely you are not suggesting that my desire to wo

Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

Divya Ranjan writes: We have a *humongous* backlog of patches, [...] [...] we host a backend service that regularly checks the Codeberg repository for any new issues or PRs and then communicates to us through the Codeberg’s Forgejo API [0] the content of said issues and PRs. The data recei

Re: mumi CLI now supports tagging

Hi Arun, I agree that sorting by date on a collection that has already been sorted by relevance would yield unexpected results. But I'd like to offer a low-cost solution for sorting on the client: Also, implementing sorting on the list is difficult to do, especially with the new relative dat

Re: Trying out Codeberg

Maxim Cournoyer writes: Hi Denis, Denis 'GNUtoo' Carikli writes: On Sat, 22 Feb 2025 22:35:21 +0900 Maxim Cournoyer wrote: [0] https://forge.a-lec.org/ (self-hosted in France by a nonprofit! [1]) [1] https://www.a-lec.org/ Personally I have a private repository on forge.a-lec.org that

Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg

Alexis Simon writes: Everyone preferring (or simply only knowing) the classic fork-PR can go this way. Correct. Any person that would prefer not forking and working mostly from the command-line can do so through the Agit flow. But from the commiter/reviewer POV, this will look identical,

Re: bug#76503: [GCD] Migrating repositories, issues, and patches to Codeberg

Ekaitz Zarraga writes: On 2025-03-04 12:22, Maxim Cournoyer wrote: - The flow would be*even* more confusing than now, since it'd look like Github but require committers to use it very differently. This is a very interesting take. I have a similar view when we mention A-Git-Flow

Re: ci.guix.gnu.org stuck for aarch64-linux?

Efraim Flashner writes: If its for the aarch64 build machines for ci.guix.gnu.org, do they depend on rust for their images? If it's not for them then I suggest getting substitutes from bordeaux. It's for my aarch64-linux machine at home. There don't see to be any substitutes from bordeaux

Re: Packaging the "next" Python

Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: On Thu, Feb 27 2025, Leo Famulari wrote: I always recommend against using inheritance Yes, it's like a disease! Please make the use of inheritance illegal in package declarations except in approved case

Re: Packaging the "next" Python

Hi Tanguy, ```scheme (define-public python-3.13 (package (inherit python-3.12) (version "3.13.2") (source (origin (sha256 (base32 "0mpbb6hkzdphyin861ywqnxibh5i4gjl5vvxdyralz6ngk2vr16r")) (patches (search-patches "python-3-deterministic-build-info.

ci.guix.gnu.org stuck for aarch64-linux?

Hi Guix, on aarch64-linux we are missing inkscape, gtk+ v3, python 3, etc. The builds appear to have been stuck for days. Manually building the derivations on ci.guix.gnu.org fails unceremoniously with errors like "too many files open". Last I checked the aarch64 nodes connected to ci.guix.gnu.

Re: example of poor debugging message (follow up Guix Days)

45mg <45mg.wri...@gmail.com> writes: > Jokes aside, it would be nice to find out why the location of the > package definition isn't displayed in the backtrace. But I feel like I'd > need a very thorough understanding of how `guix build` works to figure > it out. One important complication to keep

Re: "guix package -u automake" pulls in gtk

Andreas Enge writes: > Am Sun, Feb 23, 2025 at 06:21:27PM +0100 schrieb Ricardo Wurmus: >> > I also encounter the failure below in python-uvicorn, which is a >> > prerequisite for rest. >> This may be a non-deterministic failure. It built fine on my laptop. > &

Re: "guix package -u automake" pulls in gtk

Andreas Enge writes: > Am Sun, Feb 23, 2025 at 06:21:27PM +0100 schrieb Ricardo Wurmus: >> > I also encounter the failure below in python-uvicorn, which is a >> > prerequisite for rest. >> This may be a non-deterministic failure. It built fine on my laptop. > &

Re: [shepherd] Fails tests on aarch64-linux

Ludovic Courtès writes: >> ;;; (ACTUAL ((service (version 0) (provides (root shepherd)) >> (requires ()) (respawn? #f) (docstring "The root service is used to >> operate on shepherd itself.") (enabled? #t) (running (process >> (version 0) (id 14089) (command >> ("/gnu/store/mwv03cfpqwvnffq76fp4x1

Re: "guix package -u automake" pulls in gtk

Andreas Enge writes: > Am Sun, Feb 23, 2025 at 10:33:00AM +0100 schrieb Ricardo Wurmus: >> On aarch64-linux I still cannot build gtk+ because now libsoup-minimal >> fails to link. At least samba builds now since the fix to python-anyio. > > Thanks a lot for pushing the fix!

Re: example of poor debugging message (follow up Guix Days)

Ludovic Courtès writes: > Seeing this backtrace and error, I would go to pyproject.scm:93 to see > what’s in there, and then look among the packages you’re building for > the one that’s passing #:tests? without a value. I'd be happy if the backtrace showed the location of the package definition

Re: "guix package -u automake" pulls in gtk

On aarch64-linux I still cannot build gtk+ because now libsoup-minimal fails to link. At least samba builds now since the fix to python-anyio. -- Ricardo

Re: "guix package -u automake" pulls in gtk

Andreas Enge writes: > Next I will check whether python-anyio builds on the python-team branch. I'm going to patch python-anyio for aarch64-linux on master. The python-team branch is far from ready. -- Ricardo

[shepherd] Fails tests on aarch64-linux

Hi, I'm trying to use "guix deploy" to my aarch64-linux machine. This does not succeed as /gnu/store/g9jx0a8lfwmg1vyx78nlx55ikr5c7cj0-shepherd-1.0.2.drv aborts with test failures in tests/status-sexp.sh and tests/forking-service.sh. The log is attached. FAIL: tests/status-sexp =

Re: "guix package -u automake" pulls in gtk

Hi Andreas, > So it looks as if the simple act of calling "guix package -u" requires > gtk+@3 and samba; how is this possible? (The following is a guess.) This behavior depends on the contents of your profile due to profile hooks. The module (guix profiles) defines this: --8<---cut

Re: example of poor debugging message (follow up Guix Days)

Attila Lendvai writes: > i don't > see it acknowledged that this is way less than ideal. including that > too much of guile is written in C, [...] This is even acknowledged in the Guile manual. The commit history and the Guile maintainers own words also show that replacing more of Guile's core

Re: G-Golf in Guix - G-Golf pkg(s) name(s)

David Pirotte writes: >> it is not up to every author/committer to name things as they wish. > > Quite the opposite: it should not be up to the distro to rename > upstream projects as they wish. At the very least, the distro should > ask for an authorization. Frankly, this is absurd. The upstre

Re: Numerical problem (compiling python-numba package)

Hi Emmanuel, > I don't know if guix-devel is appropriate to report issue with a > package. It's appropriate. > I have a problem installing the package python-numba version: 0.61.0, I > cannot compile it on my machine (it > compiles on others). While I cannot reproduce this (I upgraded python-n

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

Hi Christopher, Codeberg.org / Forgejo does have an API, and there are Emacs interfaces. They are mentioned in the GCD. -- Ricardo

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

45mg <45mg.wri...@gmail.com> writes: > I strongly feel that the Guix project itself needs to maintain a > permanent (read-only) archive of all its mailing lists, and ensure that > it is searchable and downloadable. The bug-guix and guix-patches mailing lists are special in that they are only used

Re: Contributing to Guix without rDNS

Hi Zacchaeus, > Felix Lechner writes: > >> Hi Zacchaeus, >> >> On Thu, Jan 30 2025, Ricardo Wurmus wrote: >> >>> the Guix project is not operating the GNU list servers >> >> The Guix project could operate an authenticated mail relay for mem

Re: Contributing to Guix without rDNS

Zacchaeus writes: > I just found out that sending a patch to guix-patc...@gnu.org (all > gnu.org emails) requires reverse DNS [...] I don't know who you should contact about this, but the Guix project is not operating the GNU list servers. You may have better luck talking to the people who do.

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

Thanos Apollo writes: > Moreover, the current workflow exemplifies a "hacker" ethos, valuing > custom tools and minimizing third-party dependencies. I'd just like to note that (the GNU instance of) Debbugs is a third party dependency, and it is inflexible enough that mumi cannot effectively work

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

Divya Ranjan writes: > Only 9% of contributors feel like the addition of a PR-based workflow > ála Github/Codeberg/Gitlab would lead to them contributing further but > while 203 respondents (a total of 20%) report that it’s the timely > reviews and actions on contributions that inhibit motivation

Re: [python-team]: Time for Python 3.11.

What do you think about adding libxcrypt to python-3.11? The unmaintained but still influential python-passlib fails to detect support for some crypt() primitives, and I think we can fix this by building python-3.11 with libxcrypt support. We build Python 3.10 (as well as Python 2) with libxcrypt

Re: [python-team]: Time for Python 3.11.

Sharlatan Hellseher writes: > As Ricardo pushed python-3.11 and set it as default on python-team > branch it's triggered world rebuild. I started fixing some packages already by removing instances of the "U" file mode. You may find this document helpful in fixing problems: https://docs.pytho

Re: [PATCH v2 0/1] services: network-manager: Add extra-configuration-files field.

Attila Lendvai writes: >> instead of calling for >> the proliferation of private channels, a different kind of unmanageable >> structurelessness. > > not private channels, simply channels that are not owned/controlled by > the exact same set of committers as guix proper, and not demanding the >

Re: Non-committers can't keep authenticated forks updated

Liliana Marie Prikler writes: >> This has the slight issue that I can no longer easily answer a >> question "is this commit in my fork", since I cannot search by the >> commit hash. I admit it is not a question I need to answer often >> (last time was on 21st of October, CVE-2024-52867). > You co

Re: [PATCH v2 0/1] services: network-manager: Add extra-configuration-files field.

Attila Lendvai writes: >> > this patch failed to get any attention in two weeks >> >> >> Two weeks isn't a long time in free software projects. A more common >> time frame would be between one year and eighteen months. > > > ...and with such a delay most patches bitrot beyond recognition, then >

Last minute python-team fixes: help needed!

Hi, I've spent the last weeks whipping the python-team branch into shape, but I'm running out of steam. There are still a number of failures, and I'm about to lose motivation to continue fixing the remaining build failures. Here are some of the failures that may be of interest: ansible pyth

Re: GNU Manuals in Info/HTML format via Guix?

Björn Bidar writes: > Rostislav Svoboda writes: > >>> Following a discussion on emacs-devel, several people suggested that >>> GNU Guix may be a a good way to contemplate this distribution mechanism, >>> for obvious GNU-related reasons. >> >> As a side note, at the Guix Days Fringe of FOSSDEM al

Re: Value of inkscape/stable

Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > Does the rationale for having a separate inkscape/stable [1] still > hold? Yes. dblatex still depends on inkscape, and thousands of packages directly or indirectly depend on dblatex. We use inkscape/stable

Re: Updating java-commons-io?

Hartmut Goebel writes: > how to update java-commons-io? Consider *adding* a more recent version instead of replacing it. There's a chance we need the older version for the early Java dependency graph. Upgrading packages close to the root is pretty messy. -- Ricardo

Re: python-team: New branch

Ricardo Wurmus writes: > I've just rebased python-team on top of master, because Maxim just > pushed some changes to python-tox etc to the master branch. Perhaps prematurely I rebased python-team on top of rust-team to benefit from upgrades needed for pydantic. When rust-team is reb

Re: python-team: New branch

Maxim Cournoyer writes: > I have a Python mass update branch I've been developing, holding it back > because I kept finding breakage (whether caused by my changes or > already there). There's now 200 commits in it, including an update to > virtualenv and typing extensions, along Python build syst

Re: python-team: New branch

Sharlatan Hellseher writes: > I've pulled and initiated local rebuild for > >guix build -P 2 python-astropy > > I'll push any fixes if it failes. Thank you! I've just rebased python-team on top of master, because Maxim just pushed some changes to python-tox etc to the master branch. -- Ri

Re: python-team: New branch

Ricardo Wurmus writes: > If there is more time we should also consider upgrading these packages: > > python-typing-extensions > python-virtualenv > python-platformdirs > python-colorama > python-chardet > > (I patched out version checks in python-to

python-team: New branch

Hi Guix, I'm CC'ing the python-team. Since the merge of the python-team branch we've seen a bunch of new build failures to popular packages. I've started work to repair some of the damage. I think we should start a new python-team branch where we build out important upgrades and fixes. I'd lik

Re: On the quest for a new release model

"pelzflorian (Florian Pelz)" writes: > Ricardo Wurmus writes: >> Efraim Flashner writes: >>> Lets make releases boring :) >> >> I'm a very boring person, so this deeply resonates with me. >> >> No matter if people agree with this or

Re: On the quest for a new release model

Suhail Singh writes: > Ricardo Wurmus writes: > >> I've only ever signed off on one release (0.13.0?) and I'd be happy to >> help get another one out of the door. > > What does making a release entail? Is this documented somewhere? It is documented: http

Re: Guix (and Guile's) promise, and how to (hopefully) get there

Divya Ranjan writes: > Similarly, I would suggest the thoughts on improving Guix/Guile to > look at aspects of the project where we might not be doing the best > job, or if we can take different steps in terms of reachout. But as an > user and contributor, please don’t take steps to separate Guix

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

Tomas Volf <~@wolfsden.cz> writes: >> Over the years, consensus emerged that ‘core-updates’, as a branch where >> we lump together all sorts of rebuild-the-world changes, is no longer >> sustainable. > > So, uh, how should I sent patches for that? Before, I was able to mark > patches as intended

Re: On the quest for a new release model

Efraim Flashner writes: > Since, IMO, the major uses of the actual guix package is for the daemon > and the installer, I think we could tag a minor release just about every > time we bump the guix package. > > Lets make releases boring :) I'm a very boring person, so this deeply resonates with m

Re: No ibus modules for GTK4 with Sway

Hi Tomas, I had the other variables set, but not GUIX_GTK4_PATH. I tried export GUIX_GTK4_PATH=/run/current-system/profile/lib/gtk-4.0/ This is an improvement, because now dino (my GTK4 test application) accepts characters selected with ibus-libpinyin. It's not really usable, though, becaus

Re: On the quest for a new release model

Suhail Singh writes: >> Also you would need some way to specify what channel commits are able to >> work together version-wise. > > Let's say we have two channels in the future: $guix-slim and > $guix-extras. Wouldn't it be sufficient for $guix-extras to depend on > $guix-slim ? If not, could y

Re: On the quest for a new release model

Simon Josefsson via "Development of GNU Guix and the GNU System distribution." writes: > How much of the guix git repository content can you remove and still > have a working OS? In other words, can we strip away almost all of the > packages and still have a minimal bootable system? If we mini

Re: On the quest for a new release model

Suhail Singh writes: > Assuming my understanding above is correct, wouldn't you agree that > (even) for those individuals what's most important is that there is a > _stable_ and _not-very-outdated_ release available? My (and I believe > Greg's) contention is that following a time-based release p

No ibus modules for GTK4 with Sway

Hi Guix, I've reconfigured my system with Sway and I noticed that GTK4 applications now ignore my input method. GTK3 applications and Emacs still work fine. GTK4 applications used to work with IBus under Gnome, so I'm guessing that some more configuration is required to make this work... Does a

Speed up grafts by storing reference offset in index

Hello Guix, grafts can be a little slow for a number of reasons: - they are not substituted, because the assumption is that it is preferrable to rewrite references locally instead of downloading a big archive with the modified file. Local computations on x86_64 are often acceptable, but on

Re: On the quest for a new release model

Hi, Thanks for moving this discussion forward. I do think we need much more regular releases. > - devel as the branch for developments, master for releases and > security/bug fixes Changing the branching model is very difficult to do. I think it is better to ignore branches for now and focus

Re: Automatically testing package updates

Suhail Singh writes: > If we do decide to keep bots in a separate realm as it were, it would be > desirable (and in my opinion, important) if that still allowed for at > least as much transparency that the issue tracker provides for human > activities. Examples are the guix-cran and guix-bioc ch

Re: Automatically testing package updates

Attila Lendvai writes: > sidenote: as a newcomer i found it rather off-putting that the bug > tracker is full of random two-liner package updates, many long > forgotten and even obsolete. This is exactly my point and why I think the bug tracker must contain only *actionable* work that humans are

Re: Automatically testing package updates

Suhail Singh writes: > Efraim Flashner writes: > >> Also I don't think we should spam the bug tracker with package upgrades, >> so we'd have to think about something for that. > > Could you clarify what you're objecting to? Is it bug issues being > created that are then not (as is currently the

Re: Automatically testing package updates

Hilton Chain writes: > On Thu, 05 Dec 2024 15:20:53 +0800, > Efraim Flashner wrote: >> >> I'm now thinking about the easy-package -> hard-package learning curve >> for new contributors, and I'm not sure how we'd address that. > > I'm thinking about something like a wiki of packaging examples, whe

Re: ‘cargo-build-system’ makes everything slow

Hi, Perhaps this would be a good time to revive the antioxidant-build-system by Maxime Devos. I see on https://issues.guix.gnu.org/64904 that Nicolas Graves had been working on bringing it back to live, but there are no patches. -- Ricardo

Caching calls to download-to-store?

Hi Guix, the CRAN updater downloads every upstream archive three times. The importer memoizes calls to the download procedure, but one download that is out of reach is the very first. It is triggered by package-update/url-fetch in (guix upstream). It uses download-to-store, which will unconditi

Re: Status of python-team 2024-11-21

Andreas Enge writes: > My interest in the python branch is that I would like to install qmk, which > fails to build on master (due to python-uvicorn). I've fixed python-unicorn on master yesterday. -- Ricardo

Re: Bug triage

Rostislav Svoboda writes: > Hi, > >> Isn't this the same as [...] > > I wasn't talking about the meaning of the predicates in my examples. I > wanted to point out that: > - it would be nice to have a few predicate examples under the Hint > and/or in the Help https://issues.guix.gnu.org/help#searc

Re: Unhelpful "--help" output

Christopher Howard writes: > Hi, if planning to make changes to --help output, could you please try > to preserve the output formatting as much as possible? I don't think I can guarantee this. > I'm trying to > fix the bitrot in the emacs-guix "shell commands" code, which actually > parses the

Unhelpful "--help" output

Hi Guix, I found the help output not to be very helpful whenever there are sub-commands. The output contains options that are not relevant to the sub-command. The options also don't appear to be ordered. Here is an example. I want to know more about "guix system docker-image", so I run "guix s

Re: system-sexps?

Christopher Howard writes: > Hi, I am trying to troubleshoot some old code (bug#74272). Did there > used to be a guix function called system-sexps? Can anyone tell me > where it used to be, or what function replaced it? `git log -p --grep system-sexp` says no. -- Ricardo

Re: Using Pipewire for PulseAudio and JACK in Guix

Divya writes: Thanks for pointing it out, indeed its trying to write into /etc/xdg. How does one handle such a case when packaging in Guix? We'd patch the build system files to make it write to $output/etc/xdg instead. -- Ricardo

Re: python-dbus-python changes triggered many rebuilds

Ian Eure writes: Would it make sense to sort package inputs when computing derivations to prevent this sort of unintentional change? The order matters, e.g. when we add a different gcc to shadow the existing gcc. -- Ricardo

[r-team]: My immediate plans for R.

Hi there, after a few months offline I'm now back to work on Guix for a little bit. I see that not much happened to our vast collection of R packages in my absence, so here is my plan: - apply all patches relating to R packages (done) - upgrade to R 4.4.2 (released on Oct 31) - upgrade all CRAN

Re: (unrelated and off-topics) Visiting a future of GNU

Hi Simon, I enjoyed reading your article. Would you consider https://gnu.tools/en/documents/social-contract/ to be a social contract as defined in your blog post? The GNU Assembly ended up being rather immobilized by proximity to GNU, its self-appointed spokes people, and the fact that old GNU c

Re: Using Pipewire for PulseAudio and JACK in Guix

Hi, > Also, I saw that jack_mixer[0] is missing from the main guix package > repository, I’d like to have that added. Since its the most minimal > and straightforward JACK mixer I’ve been using over the last 4-5 > years. Since its a Python + C application mostly, so one shouldn’t > have any major

Re: Including code in a non-Guile language into Guix

Evan Cooney writes: > I know that Guix is mainly written in Guile, but has much thought gone > into optimizing these commands Yes. > by rewriting some of the > code in a more performance-oriented language like C? No. Guile is not the bottleneck. > C is also more widely taught and known than

Re: Including code in a non-Guile language into Guix

Suhail Singh writes: > Daniel Littlewood writes: > >> guix pull ("38k new commits"): 21m45s >> guix pull immediately after: 2m25s >> guix shell emacs (fresh): 1m49s >> ... >> >> nix-channel --update: 0m23s >> nix shell -p emacs (fresh): 0m24s > > Those are some interesting comparisons. Is the r

Re: Guix (and Guile's) promise, and how to (hopefully) get there

"Thompson, David" writes: > On Sun, Oct 27, 2024 at 3:13 PM Ekaitz Zarraga wrote: >> >> Many people on this project have tried to change GNU from the inside and >> are very critical with the FSF (see the https://gnu.tools/). I think >> that's also a good way to do things, changing them from the

Re: Guix (and Guile's) promise, and how to (hopefully) get there

Ekaitz Zarraga writes: > Let's remember the FSF still pays most of our bills. I think clarification is required here: the Guix project receives donations, including a single very large donation. Most of these donations were received because of Guix's participation in an FSF program (an agreemen

Re: Guix (and Guile's) promise, and how to (hopefully) get there

indieterminacy writes: > At our end I think more pressure and greater expectations should be > made wrt GNU. > Its good that there have been statements made in the past, these types > of things should be expanded upon. When we published https://gnu.tools/ it was our conviction that GNU is what w

Re: Discussion on Guix funding // future

Steve George writes: > On 25 Oct, Ricardo Wurmus wrote: >> Steve George writes: >> >> > One concern with supporting developers is whether it demotivates them >> > in the long-term: from intrinsic to extrinisic motivation. Basically, >> > the answe

Re: Discussion on Guix funding // future

Ekaitz Zarraga writes: > Ricardo, I can agree with you but how do you reward just being there > and doing the dirty job? For reviews, for example, one could find an arbitrary set of metrics and hand out an award with a monetary component at an annual event. I'm not speaking of sustainable fundi

  1   2   3   4   5   6   7   8   9   10   >