Re: GNOME 49’s dependencies on systemd

Rutherther writes: > Hi Noé, > > Noé Lopez writes: > >> >> Hi again, >> >> As I have it working now, there is no dependency on guix-home. Simply, >> on session start an shepherd instance is started for GNOME. Completely >> independently from your home shepherd if you have one. > > Thanks for the

Re: GNOME 49’s dependencies on systemd

Noé Lopez writes: > Rutherther writes: > >> Hi Noé, >> >> Noé Lopez via "Development of GNU Guix and the GNU System distribution." >> writes: >> >>> Secondly, gnome-session (responsible for starting user services) is >>> go

Re: Informal Guix 1.4.0 branch and security fixes?

Liam Hupfer writes: > Denis ’GNUtoo’ Carikli writes: > >> If we look at guix packages in various distributions, we have Guix >> 1.4.0, 1.3.0 and 1.2.0[1]. > > In Nixpkgs we gave up and shipped the last commit on master mentioned in > the recent CVE disclosure. It’s visible as ‘1.4.0-unstable-202

Re: Package shared library Rawspeed for use via CMake

Hi Noé, Thanks for the context and the suggestions. This seems actionable. I hope to find the time in the coming months to improve the packaging. I'll get in touch if I run into issues. Best, Nico

Re: Shepherd: flaky self tests

Ludovic Courtès writes: > Hi Simon, > > Simon Josefsson writes: > >> Below is the log file. > >> + shepherd --version >> ;;; WARNING: loading compiled file >> /usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/fibers.go failed: >> ;;; In procedure load-thunk-from-memory: incompatible bytecode vers

Re: Shepherd: flaky self tests

Ludovic Courtès writes: > Hi Simon, > > Simon Josefsson writes: > >> Ludovic Courtès writes: > > [...] > >>> ++ wc -l >>> + test 22 -le 18 >>> >>> This is the same as . >>> >>> Could you instrument it as I suggested there? >> >> I'm still seeing this with 1.0.

Re: Shepherd: flaky self tests

Ludovic Courtès writes: >> I've often seen failure in the 'log-rotation.sh' self-tests on my own >> system (see attachment for log), > > It fails while checking the number of remaining open file descriptors: > > + herd -s t-socket-3705122 stop three > ++ file_descriptor_count > ++ ls -l /proc/370

Re: xlibre X11 server

I'm not sure I understand the reactions to the Xlibre project. The quote from their website is: This is an independent project, not at all affiliated with BigTech or any of their subsidiaries or tax evasion tools, nor any political activists groups, state actors, etc. It's explicitly free of a

[Non GCD] Changing GCD headers

Hi Guix, As discussed in https://codeberg.org/guix/guix-consensus-documents/pulls/1, I would like to change the headers for current GCDs to add more date information. Currently, GCDs only have a date header, which is sometimes the submission date and sometimes another date. It would be good to ke

Upcoming security disclosures on June 24, 2025

Hi Guixers, This is an advanced notice of upcoming security disclosures and fixes. Vulnerabilities were identified by Snyk Security Labs which affect Guix, Nix, and Lix (their pre-announcement is at

Re: GNOME 49’s dependencies on systemd

Rutherther writes: > Hi Noé, > > Noé Lopez via "Development of GNU Guix and the GNU System distribution." > writes: > >> Secondly, gnome-session (responsible for starting user services) is >> going to use systemd too. So we need to replace it with a Shep

Re: GNOME 49’s dependencies on systemd

Noé Lopez writes: > Hi GNOME team, > > In [1], GNOME recently announced some new dependencies on systemd for > release 49. > > Firstly, GDM now depends on userdb to dynamically allocate user accounts > for showing multiple GDM at once. However, there is an alternate code > path for elogind that m

GNOME 49’s dependencies on systemd

Hi GNOME team, In [1], GNOME recently announced some new dependencies on systemd for release 49. Firstly, GDM now depends on userdb to dynamically allocate user accounts for showing multiple GDM at once. However, there is an alternate code path for elogind that means we can preallocate gdm-greete

Re: CI is broken

Hi Ludo’, On Thu, Jun 05, 2025 at 08:46 AM, Ludovic Courtès wrote: > Ian Eure writes: > >>uncaught throw to %exception: (#<&store-protocol-error message: >>"reading file >>`/gnu/store/9kqd85xgbgdng03nia2q12nl05w5b6yi-sbm-0.9.tar.gz.drv': >>No such file or directory" status: 1

Package shared library Rawspeed for use via CMake

Hi all, I recently contributed the Ansel photo editor in gnu/packages/photo.scm https://codeberg.org/guix/guix/pulls/85 Ansel is a fork of Darktable, and both use the rawspeed library: https://github.com/aurelienpierreeng/ansel/blob/master/.gitmodules https://github.com/darktable-org/darktable/bl

Re: Extra commits pushed on Savannah

Hi folks, On Tuesday, June 3rd, 2025 at 12:37 PM, Noé Lopez via "Development of GNU Guix and the GNU System distribution." wrote: > > > Hi everyone, > > There are four extra commits that were pushed on Savannah and not > Codeberg: > > ad8cb7af8f * sav

Extra commits pushed on Savannah

Hi everyone, There are four extra commits that were pushed on Savannah and not Codeberg: ad8cb7af8f * savannah/master gnu: openscad: Update to 2025.06.01. 1e081d0a48 * gnu: manifold: Update to 3.0.1-0.7c8fbe1. 36a5c856be * gnu: opencsg: Ran guix style. 531c26bba8 * gnu: opencsg: Update to 1.8.2.

Re: Help needed for packaging KeePass

Hi, nomike and guix, Despite my lack of experience with Mono, I tried to look into this problem. I did not find the cause of it, but I've found some stuff that I'd like to share and hope it'll be useful. First I modified your recipe to use the "/verbosity:diagnostic" flag, as shown below, to get

Re: Broken pull requests

Noé Lopez writes: > Hi everyone, > > A few hours ago, all teams were deleted and recreated by a script to add > the users from etc/teams.scm. > > This broke all pull requests that had teams as reviewers, since these > teams got deleted, they now reference nothing and the codeberg site will > give

Broken pull requests

Hi everyone, A few hours ago, all teams were deleted and recreated by a script to add the users from etc/teams.scm. This broke all pull requests that had teams as reviewers, since these teams got deleted, they now reference nothing and the codeberg site will give a 500 error. I have reported thi

Re: Committers: create and share your Codeberg account

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Arg, this is a ProtonMail bridge issue, it drops the signature to use my ProtonMail key. I've been meaning to go back to this issue to see what the problem was with some encrypted emails in the past, but just now found out this detail of rewriting me

Re: Committers: create and share your Codeberg account

Hi all, On Fri, May 09, 2025 at 11:37 AM, Ludovic Courtès wrote: > Hello Guix! > > 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. > Mine is

Re: Delibaration vs. voting

Hi, On Mon, May 12 2025, Vagrant Cascadian wrote: > we could use "deliberation results" or "results of the deliberation" ? Perhaps a clickable thesaurus could help to explore adjacent meanings? According to The Free Dictionary, the shade meaning for "vote" you are all chasing is "poll". [1] If

Re: Substitutes mirror available in Japan! (and questions regarding mirroring)

Ludovic Courtès writes: > Simon Josefsson writes: > >> Ludovic Courtès writes: >> The nar-herder which handles serving substitutes for the bordeaux build farm is meant to enable high performance mirroring, and that's what's used for the mirrors listed on https://bordeaux.guix.gnu

Re: GCD005: Regular and efficient releases

Hi Ian and Rutherther, On Sun, May 11 2025, Rutherther wrote: > If release and master are diverging branches Sorry to double up. >From a technical point of view, I think it would be superior to have package functions that accept a version (i.e. not variables like now) and define releases and th

Re: GCD005: Regular and efficient releases

Hi Ian and Rutherther, On Sun, May 11 2025, Rutherther wrote: > If release and master are diverging branches Could the monorepo be broken up in such a way that release work might take place in one part while regular development continues in the others? The release team would focus on each part

Re: Committers: create and share your Codeberg account

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, 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. Here I am: https://code

Re: Practical consensus building, was: Deliberation period for GCD 003 "Rename the default branch" has technically started

Hi Leo, On Thu, May 08 2025, Leo Famulari wrote: > [if] we had two of these [...] and took their responsibilities as > facilitators very seriously. Based on my reading of the group dynamics, you, futurile, nckx, or ieure would all have favorable personalities for that role (and others, too). So

Re: Substitutes mirror available in Japan! (and questions regarding mirroring)

Ludovic Courtès writes: >> The nar-herder which handles serving substitutes for the bordeaux build >> farm is meant to enable high performance mirroring, and that's what's >> used for the mirrors listed on https://bordeaux.guix.gnu.org/. > > Would be nice to have a section in the Cookbook on sett

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

Hi Steve, On Mon, May 05 2025, Steve George wrote: > Voting result: > - 45% (22 votes) voted to pass the GCD > - 14% voted to disapprove > - 41% abstained by not voting > > This GCD is withdrawn as it didn't achieve full consensus: > > "The GCD is accepted if (1) at least 25% of all team

Re: our git linked with openssl, license is incompatible

Hi Efraim, On Thu, May 01 2025, Efraim Flashner wrote: > gnutls wasn't a drop-in replacement wolfSSL could be such a "drop-in" replacement. [1] Their OpenSSL compatibility layer became popular when OpenSSL lost their FIPS rating for a little while, but I ported software to it long before. wolfS

Re: emacs-team needs you 👉 to properly test your packages

So the full list is the following: export SKIP_PACKAGES=cedille:emacs-emms-print-metadata:emacs-emms:emacs-jedi:emacs-flycheck-haskell:emacs-explain-pause-mode:emacs-realgud:emacs-emms-mode-line-cycle:emacs-helm-emms:emacs-org-emms:emacs-keystore-mode:emacs-prodigy-el:emacs-webfeeder:emacs-magit-

Re: emacs-team needs you 👉 to properly test your packages

I’ve been playing a bit with emacs-team branch after #78095 (and previous emacs-build-system manifest). This is a (preliminary) list of packages still needing some tweaks before we are able to built it all and are ready to merge (and move to emacs 30 !!): export SKIP_PACKAGES=cedille:emacs-gnos

Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.

Maxim Cournoyer writes: > Nicolas Goaziou writes: > > I agree that it has value; wouldn't it only be for testing website > problems (it's still a thing in 2025 to find a website feature that only > works with Chromium, in a nudge to the good old Internet Explorer > days). My hypothetical use-ca

Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.

Hello, Maxim Cournoyer writes: > Danny Milosavljevic writes: > >> * gnu/packages/patches/ungoogled-chromium-fcntl-fix.patch: New file. >> * gnu/packages/chromium.scm (%guix-patches): Add reference to it. >> * gnu/local.mk (dist_patch_DATA): Add reference to it. > > Ouch, the last time ungoogled

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

Hi Ludo' On Mon, Apr 21 2025, Ludovic Courtès wrote: > I’m curious how else this could be handled Vagrant will surely repond better than I can, but just to get the ball rolling: Debian has a mandated "further discussion" (FD) option, which was somehow renamed to "none of the above" (NOTA). [1]

Re: Shepherd: flaky self tests

Hi. Here are more tests that I suspect are flaky tests and not real failures: log-rotation: https://buildd.debian.org/status/fetch.php?pkg=shepherd&arch=arm64&ver=1.0.4-1&stamp=1744885841&raw=0 https://buildd.debian.org/status/fetch.php?pkg=shepherd&arch=armel&ver=1.0.4-1&stamp=1744886174&raw=0

Re: GNU Shepherd 1.0.4 released

Ludovic Courtès writes: >> I tried to simplify things by using 'guix shell' like this (using Guix >> commit a36ff7d51110403295a359e7f40c3eb42ccfd509): > > FWIW, I used ‘guix shell -CPDf guix.scm texlive-scheme-basic’ from this: ... > Could you check if that works better? (You can probably just s

Shepherd: flaky self tests

Hi Running the self-tests have been disabled in the Debian packages, and I only now realized this and re-enabled them. It seems some of them (or the test harness) is flaky. I've often seen failure in the 'log-rotation.sh' self-tests on my own system (see attachment for log), but now the Debian i

Re: GNU Shepherd 1.0.4 released

Ludovic Courtès writes: > It is bit-for-bit reproducible from a checkout of the ‘v1.0.4’ tag of > the Git repository. Yay, thanks for supporting repreproducible tarballs! I cannot reproduce your tarball, and one reason is that I don't know what recipe you used and what tool versions you wer

Re: Please don't leave GNU

Denis 'GNUtoo' Carikli writes: >> Is the syscall available for non-root users? If so isn't that a linux >> kernel bug, surely non-privileged users shouldn't be allowed to load >> firmware that can modify hardware behaviour? > There is no syscall. You can do it by hand with echo and cat. > > It wo

Re: Please don't leave GNU

Maxim Cournoyer writes: >> An example would be to switch from linux-libre to some 100% free linux >> kernel that doesn't block nonfree firmware, so if users reluctantly >> need nonfree firmware they would, on their own, add them. > > I thought I'd mention that technically, making it impossible to

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

Hi Andreas, On Fri, Apr 11 2025, Andreas Enge wrote: > Well, why should r-team go before qt-team or tex-team? > (I have no particular opinion and am fine with any decision on that > matter, but one should search agreement by qt-team and tex-team Some "one" has to do it. Why not you? Kind regar

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

Hi Ricardo, On Fri, Apr 11 2025, Ricardo Wurmus wrote: > There has now been a new R release while the branch has been waiting Upstream will always do as they please. To us, it's more important what's in Guix. Your branch should be merged now (and before you update R) after our new branch merge

[Shepherd] Default value for #:wait-for-termination?

Hi, Should we change the default for the #:wait-for-termination? parameter in the Shepherd's make-timer-constructor to #t? It seems safer. I added to all my timers. Kind regards Felix

Re: How is security managed in Guix? Should there be a team?

John Kehayias via "Development of GNU Guix and the GNU System distribution." writes: >> Yes, most distributions have a special security point of contact that is >> not publicly archived, to discuss ways to resolve responsible disclosure >> vulnerabilities for examp

Re: How is security managed in Guix? Should there be a team?

Hello, (CCing some more security people) On Fri, Apr 04, 2025 at 05:51 PM, Simon Josefsson via \"Development of GNU Guix and the GNU System distribution.\" wrote: > Nicolas Graves writes: > >> Hi Guix! >> >> I think one of the things where Guix could be bet

Re: How is security managed in Guix? Should there be a team?

Nicolas Graves writes: > Hi Guix! > > I think one of the things where Guix could be better is security / > ensuring CVEs are fixed quickly. > > In 76819 I developped some missing functionality in the CVE linter, so > that it will be easier to get proper missing libraries. > > A few ideas/question

Re: Slow guix pull? (was Re: Please don't leave GNU)

Simon Tournier writes: > To my knowledge, the main bottleneck on most machines is the part > “Computing Guix derivation...“ and sadly it’s not substitutable. I'm not sure that is the full story. Is there some way to instrument 'guix pull' to report what it is spending time on? I think there ar

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

Hi Andreas, On Tue, Apr 01 2025, Andreas Enge wrote: > Probably we also need some human scheduler. In the past it has happened > that branches have clogged the queue although for a week or two nobody > was available to work on it. Having a person following the branches and > interacting with the

Re: “Build daemon drops its privileges” 👈 blog post

Not invalidating my questions, but maybe some additional insight: Reading the guix-install.sh make me believe that one part of my issues could be due to: [ FAIL ] Init system could not be detected. Several things from guix-install.sh are not run properly in my GitLab runner instance. I see two w

Re: “Build daemon drops its privileges” 👈 blog post

Ludovic Courtès writes: > Hello Guix! > > New blog post about this newfangled unprivileged guix-daemon: > > https://hpc.guix.info/blog/2025/03/build-daemon-drops-its-privileges/ Yay! I'm trying to adapt this for my GitLab CI/CD container images [1] but I'm having some troubles which are proba

Re: Debbugs changes on #guix

Hi there, On Thu, Mar 20 2025, Ian Eure wrote: > I think the bot messages have value I turned the messages off again, as I did not wish to make enemies. I made my point: Closing bugs takes work, and '/ignore debbugs' is not a good general policy. Kind regards, Felix P.S. Thanks to Ian and Rut

Re: Questions on Managing Patches and Branches

Hello, Andreas Enge writes: > Hello Chris, > > Am Fri, Mar 28, 2025 at 10:31:26PM +0300 schrieb Christopher Baines: >> On tooling, as I say, QA used to attempt to build the first 2 or 3 >> branches. With the data service and build coordination being a bit >> faster now, I think building the firs

Pretty-printing configuration files

Hi, Any chance we can start pretty-printing configuration files? They are easier to read, and M-x debpaste is less likely to reject them as spam because they contain at least two line breaks. [1] Kind regards Felix [1] https://github.com/formorer/paste.pl/blob/32e7f1e4a92a6a71fe16e2dea9b30aefb

Re: Thoughtful updates to TexLive

Hello, Andreas Enge writes: > Actually I am wrong, it is CTAN, not Texlive. And CTAN contains rather > obscure packages, such as the thesis format for this or that university, > which I suppose are not shipped as part of Texlive. I believe TeX Live includes all free parts of CTAN. In particular

Re: Thoughtful updates to TexLive

Hello, Andreas Enge writes: > So maybe once the fix for issue 75893 is pushed and the modular texlive > updated to version 2025, it will finally be time to retire the > monolithic package. Modular TeX Live 2025 is on its way! > Well, I do not know how complicated it will be to update the modul

Re: chez scheme can't load system shared library

Hi Xie Pan, On Tue, Mar 25 2025, Pan Xie wrote: > *this* chez scheme can not load system shared library correctly: I have never used Chez Scheme but suspect you have to set LD_LIBRARY_PATH. In Bash, it might look like something like this: $ LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH chez-sche

Re: Some thoughts about the documentation

"Thomas Ieong" writes: > Hey Guix, > > I was thinking about how we could do better documentation wise and came up > with some ideas. > > - Let people comment via a web interface on issues.guix.gnu.org I think it > would help a lot and lower the barrier to entry. I know we're supposed > to mov

Re: Thoughtful updates to TexLive

Hello, Andreas Enge writes: > For compiling a set of slides of a talk, now time is an issue: > real 0m36,095s > user 0m13,706s > sys 0m22,710s > > With the monolithic texlive: > real 0m9,127s > user 0m9,260s > sys 0m0,613s > (which is already a lot when one has to recompile every time af

[Shepherd] Disappearing timer

Hi, My timer join-irc-channels [1] starts when being 'deployed' but is gone after a reboot, even though the Shepherd configuration includes a reference to it. [2] There is no trace: # herd status join-irc-channels herd: error: service 'join-irc-channels' could not be found The system generation

[Shepherd] Skipping a beat

Hi, Should #:wait-for-termination? be called #:skip-when-running? The name captures that beats are missed when a process has not yet terminated. Due the connection with time, "when" is better than "if". Kind regards Felix

Re: [PATCH 00/48] Extend bag-build to gexps.

Hi Sergio, I worked towards it quite recently ! Latest efforts are from yesterday even ;) The latest working example on my side is (used in guile-emacs repo as guix.scm with command guix build -f guix.scm) :  https://git.sr.ht/~ngraves/guix-stack/tree/master/item/examples/guile-emacs.scm The co

Re: Guix on the MNT/Reform

Christine Lemmer-Webber writes: > This is good news, to myself and I am sure many others who are either > using or hopeful for the future of the Reform. > > I am really happy to see not only the progress but that there may be a > way to have the majority of work in Guix itself (even if there's th

Debbugs changes on #guix

Hi, I enabled an experimental barebones feature that broadcasts Debbugs changes on #guix. It's another technical feature that could improve the speed at which bugs are being closed. Please let me know what you think! Kind regards Felix

Re: How to move forward about Rust? antioxidant, cargo2guix, etc.

> Are you saying that if two dependents of a package A depend on the same > package B, but with different features we need to build B with the > union of those features? > Exactly, except in some cases where features are incompatible with each other, but that's (very) rare.  What's annoying is t

Re: How to move forward about Rust? antioxidant, cargo2guix, etc.

Nicolas Graves writes: > 4) The full Guix way > > Most likely : we don't have the manpower in the short term for > going the full guix way, because, and I second Murilo's point here, we > dive in dependency hell quickly with more required efforts than > reasonable (having implemented it myself, d

Re: mumi CLI now supports tagging

Arun Isaac writes: > Hi Noé, > > The new open/closed indicator badges and separation of open/closed > issues is now online. I'm happy to hear your feedback and tweak it a > bit. > Looks great, thanks! >>> Also, implementing sorting on the list is difficult to do, especially >>> with the new rel

Re: Guix on the MNT/Reform

Vagrant Cascadian writes: > On 2025-03-13, Vagrant Cascadian wrote: >> Just pushed a "wip-linux-libre-arm64-mnt-reform" branch that contains a >> kernel for the MNT/Reform family of systems. >> >> I have successfully built and booted a linux-libre-arm64-mnt-reform@6.12 >> kernel on a "MNT Reform2

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

Hi Ricardo, On Fri, Mar 07 2025, Ricardo Wurmus wrote: > Surely you are not suggesting that my desire to work on Guix [...] > would be sufficient in reducing the backlog of bugs? The remainder of my message made that clear but you were offended and hit reply too fast. My observation was about t

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

Hi Ricardo, On Fri, Mar 07 2025, Ricardo Wurmus wrote: > I'd rather work on Guix. Then why is there a backlog of bugs? I only see a group of software developers unable to close more bugs than are being opened. It's not because of technical limitations, but because the committers are overwhelme

Re: Guix booth at JDLL in Lyon, France?

> >> Note that the event is mostly French-speaking. >> >> Thoughts? Volunteers? >> >> I'll bring stickers ;) > > You got me at "French-speaking", but stickers are nice too! 😉 > What about t-shirts? People asked me about that at Guix Days. Some feel that > we > lack a "visual identity" (my words) w

Re: mumi CLI now supports tagging

Arun Isaac writes: > Hi Noé, > >> Seeing closed issues is very important depending on what I’m looking >> for. How about having a colored « open » indicator next to the tags (or >> as a tag)? > > Yes, we could have an "open/closed" indicator badge similar to the tag > badges. I'll implement that

Re: Possible path to bootstrap GNAT, the Ada compiler

Dear Ludo, sorry for the belated reply. I missed this original message, thankfully Janneke brought it to my attention during a discussion stemming from our FOSDEM encounter. On 10/15/24 17:38, Ludovic Courtès wrote: > Hello there, > > Recently, Alexandre Oliva kindly sent me this message, whic

Re: Feburary update on qa.guix.gnu.org and related things

Hi, On Tue, Mar 04 2025, Andreas Enge wrote: > we could also do a videoconference. We could use Debian's Jitsi instance. [1] It would be nice to put a picture to the words. How about the conference ID "Quality"? [1] https://jitsi.debian.social/ > it might as well be on #guix directly. Okay,

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

Ekaitz Zarraga writes: > On 2025-03-04 18:19, Ricardo Wurmus wrote: >> >> The AGit flow: >> >> - clone the upstream repository >> - checkout a new branch >> - make a commit >> - push the commit as a PR to the forge. > > Yes but no. > It's easy, but if we are going to make any contributor do tha

Re: Guix booth at JDLL in Lyon, France?

Julien Lepiller writes: > Hi Guix! > > There is a regular event in Lyon, called JDLL (journées du logiciel libre): > . It will happen end of may this year. > > We have until march 16 to submit a proposal for a talk or a booth. If we can > gather at least three more people (ot

Looking for a mentor for PackageKit/Appstream integration

Hi, I’m currently working on bug #17152 (GNU Guix backend for PackageKit / Gnome-Software). My goals are being able to search, update, install and remove packages from Gnome Software and Discover (KDE Plasma). Fortunately, they both use a common “protocol” so I only need to implement two things:

Re: Feburary update on qa.guix.gnu.org and related things

Hi Chris & everyone, On Thu, Feb 27 2025, Christopher Baines wrote: > last year I did send out an email about starting a Quality Assurance > Meeting/Team/Sociocracy circle [1] > 1: https://lists.gnu.org/archive/html/guix-devel/2024-06/msg00217.html I'd like to invite anyone who wants to help Ch

Re: mumi CLI now supports tagging

Arun Isaac writes: > Hi Noé, > > Thank you for your feedback! > >> It seems the new design has removed the ability to sort by date in >> searches, which is a very important feature for me. > > We could bring back the sorting. But first, could you help me understand > what you use the sorting for?

Re: Packaging the "next" Python

Hi Leo, 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 cases. In all circumstances, however, later package versions should never inherit from

Re: How to move forward about Rust? antioxidant, cargo2guix, etc.

Hi Murilo, On Mon, Feb 24 2025, Murilo wrote: > generating guix package definitions from Cargo.lock. How else can we avoid packaging errors like this one? [1] Kind regards Felix P.S. I'm not a Rust person & behind on the conversation. [1] https://issues.guix.gnu.org/76444

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

Hi, On Mon, Feb 24 2025, Ricardo Wurmus wrote: > - it's not always just down to Guile's poor backtraces (which on their own > can be puzzling, no question about it) > - on the compilation side of things I think Guix would benefit from > enforcing type contracts to trigger errors earlier. Tho

Re: Users of demlo package.

Hi Oleg & Andreas, On Sat, Feb 22 2025, Andreas Enge wrote: > upstream was also the packager; there is a certain probability that > the package has never been used by anyone else. > So I would suggest to send this patch to the issue tracker, maybe cc-ing > the packager, and see what happens duri

Mumi list interface [Was: mumi CLI now supports tagging]

Hi Arun, On Sat, Feb 22 2025, Arun Isaac wrote: > the mumi web UI now has an improved listing of issues. I find that the list interface [1] made the website [2] less helpful, but my opinion is probably not important. Kind regards Felix [1] https://issues.guix.gnu.org/76297 [2] https://issues.g

Re: mumi CLI now supports tagging

Arun Isaac writes: > In other news, the mumi web UI now has an improved listing of issues. > Dates are now human-friendly relative dates instead of absolute > timestamps. Hi, First of all, thank you for your work on mumi. It seems the new design has removed the ability to sort by date in searc

Re: [GCD] Set search paths without program wrappers

宋文武 via "Development of GNU Guix and the GNU System distribution." writes: > Hartmut Goebel writes: > >> Hi, >> >> I don't understand what solution you propose. >> >> The GCD talks about setting some Env variable, like >> `GUIX_INTERPRETE

Re: [GCD] Set search paths without program wrappers

Hartmut Goebel writes: > Hi, > > I don't understand what solution you propose. > > The GCD talks about setting some Env variable, like `GUIX_INTERPRETER_FILE` > and `GUIX_MAIN_SCRIPT_FILE` (for Python). > What is happening then? Isn't there some code required for reading the files > in search-p

Re: [GCD] Set search paths without program wrappers

Simon Tournier writes: > Hi Tobias, 宋文武, all, > > (Since I do not parse 宋文武 – only copy/paste – so I hope it makes > sense to say “Hi 宋文武” :-)) Hi Simon, that's widely used in Chinese too, we also write "Hi" as "嗨" :) > > On Thu, 20 Feb 2025 at 07:56, Tobias Geerinckx-Rice wrote: > >>> Should

QA is back‽

Hey, Just noticed QA has been going through a lot of issues lately[1], thanks to everyone who worked on it! [1] https://qa.guix.gnu.org/patches

Re: guix build -P not building dependent(s) of django package

On Thursday, February 20th, 2025 at 9:33 AM, jgart wrote: > > > [jgart@unknownee2179f0a061 guix]$ make -j6 && ./pre-inst-env guix refresh -l > python-django-cache-url > > A single dependent package: python-django-configurations@2.4.1 > > Hi, when running guix build python-django-cache-

Re: [GCD] Set search paths without program wrappers

宋文武 via "Development of GNU Guix and the GNU System distribution." writes: > Simon Tournier writes: > >>> title: Set search paths without program wrappers >>> id: 003 >>> status: draft >>> discussion: https://issues.guix.gnu.org/ >&

Re: [GCD] Set search paths without program wrappers

Simon Tournier writes: >> title: Set search paths without program wrappers >> id: 003 >> status: draft >> discussion: https://issues.guix.gnu.org/ >> authors: 宋文武 >> sponsors: Maxim Cournoyer >> date-submitted: >> date: >> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only >

Re: Libravatar avatars on mumi

Arun Isaac writes: >> Sorry, we had some issues (probably kernel related) when reconfiguring >> berlin and had to roll back. The latest version of mumi with Libravatar >> avatars will be back after we have resolved these issues. > > The latest version of mumi is now on berlin. And, we now have Li

Re: Guix Consensus Document: Git repo and workflow

Simon Tournier writes: > Hi all, > > Please consider the Git repository hosting the GCDs: > > https://git.savannah.gnu.org/cgit/guix/guix-consensus-documents.git/ > > And the README file proposes a workflow. It’s up to changes. :-) > > Feel free to drop new GCDs. However, please consider th

Re: [GCD] Rename “main” branch

Hi Vivien, On Mon, Feb 17 2025, Vivien Kraus wrote: > Maybe we could be a bit more explicit instead of “may be perceived as > harmful”, if the case needs to be made stronger. For instance, “the > current default, “master”, evokes a metaphor for a political > organization based on inequality. See

Re: is the certbot service broken?

Hi Attila, On Mon, Feb 17 2025, Attila Lendvai wrote: > the challenge response is saved to the wrong path I did not research your claim but Certbot has been working fine for me ever since I started using Guix. [1] I just added two more certificates last night. Please note that my code requires

Re: [bug#55231] Understanding #:substitutable? and #55231

Hi Maxim, > It's not good to surprise user expectations in such a way, especially if > it can expose them to legal problems (no matter how unlikely). > > I hope that helps put a light on what the remaining issue is, which > should be fixed (in my opinion) before #55231 can be merged. I am inclin

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

Hi Ian, On Sun, Feb 16 2025, Ian Eure wrote: > Your purported authorization is irrelevant, as the name is within the > Guix project, not g-golf; and even if Guix had renamed the project, > such changes are explicitly permitted by g-golf’d LGPLv3 license. > > Since you seem to be more devoted to m

Re: none

Z572 writes: > My main concern is whether it will affect guix time-machine. > Will the master branch be removed after the migration to the main > branch on some time, or will it just stay there? Even if the 'master' branch is removed, which to avoid confusion I think should be done, we still hav

  1   2   3   4   5   6   7   8   >