On Wednesday, April 3rd, 2024 at 1:06 PM, Maxim Cournoyer
wrote:
> Is anyone opposed to having nss-certs in %base-packages?
I applaud that plan. Not only that, I think that Guix should warn if you don't
have nss-certs in your profile on a foreign distro (with a mechanism to
suppress that,
On Tuesday, April 2nd, 2024 at 3:23 AM, Attila Lendvai
wrote:
> https://github.com/Tudmotu/gnome-shell-extension-clipboard-indicator/issues/138#issuecomment-904689439
>
> ...and its author actively defends this situation.
Yikes. This sounds like a great reason to fork. The author can prefer
I'm reading today that a backdoor is present in xz's upstream tarball (but not
in git), starting at version 5.6.0. Source:
https://www.openwall.com/lists/oss-security/2024/03/29/4
Guix currently packages xz-utils 5.2.8 as "xz" using the upstream tarball. Is
there a way we can blacklist known
On Sunday, March 17th, 2024 at 12:24 PM, Ludovic Courtès wrote:
> ‘guix home import’ does exactly that: generate a first configuration
> that you may find necessary to tweak. Perhaps the manual should clarify
> that?
Maybe we should call it "guix home init" then? Describing it as "import"
On Sunday, March 17th, 2024 at 12:24 PM, Ludovic Courtès wrote:
> I personally try to lower the barrier for Home services, but I think few
> people (if any) beyond me review Home services.
>
> We should expand the ‘home’ team; who’s in?
I would like to contribute to Guix home, but haven't been
[I intended to CC the following to guix-devel but forgot:]
--- Forwarded Message ---
From: Ryan Prior
Date: On Saturday, March 16th, 2024 at 6:36 PM
Subject: Re: Concerns/questions around Software Heritage Archive
To: Vivien Kraus
>
>
> On Saturday, March 16th, 2024 a
On Saturday, March 16th, 2024 at 10:52 AM, Ian Eure wrote:
>
>
> Hi Guixy people,
> [...]
> I was also distressed to see how poorly they treated a developer
> who wished to update their name:
> https://cohost.org/arborelia/post/4968198-the-software-heritag
>
On Wednesday, March 6th, 2024 at 11:37 AM, Luis Felipe
wrote:
>
>
> Hi,
>
> Nonguix would like to have a logo [...] I couldn't help it and suggested to
> reuse the GNU Guix logo
I like this. There's a clear visual continuity, but with warnings and (in
options B-D) part of the Guix horns
--- Original Message ---
On Wednesday, June 7th, 2023 at 10:09 PM, Ludovic Courtès wrote:
>
>
> Hello!
>
> Here is the “camera-ready” version of the new ‘guix locate’ command
> (formerly ‘guix index’) that Antoine and myself have worked on.
> I think it’s ready to go.
It would be
I don't like the unpredictability of jgart's original proposal, but maybe
something explicit could still look similar.
Suppose you could build emacs-ement these three ways:
# no transform- this is a version packaged in Guix
guix build emacs-ement@0.5.2
# transform using `with-git-commit`
guix
Hi there FSF Licensing! (CC: Guix devel, Nicholas Graves) This morning I read
through the FSDG to see if it gives any guidance on when machine learning model
weights are appropriate for inclusion in a free system. It does not seem to
offer much.
Many ML models are advertising themselves as
--- Original Message ---
On Monday, March 13th, 2023 at 10:21 PM, Josselin Poiret
wrote:
> But I would really like for tests to move out of build phases
I've mentioned this previously in IRC as well. Fundamentally, it strikes me as
wrong that a change which only affects tests, leaving
Migrating application settings to guix-home is something we want to make really
approachable. Right now it's a relatively new and little-known feature but it
could quickly become one of the top use cases for Guix, as a lot of people are
interested in declarative application configuration.
A
Hi Octavio! We had a discussion about this last month, and we might make some
changes to make it clearer what "advanced" means (or perhaps change the
wording.)
Here's a link to that discussion in the list archive:
https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00298.html
Cheers,
On Saturday, November 26th, 2022 at 9:47 PM, Simon Josefsson via "Development
of GNU Guix and the GNU System distribution." wrote:
> I find use of the term 'advanced' wrt Guix confusing and even mildly
> excluding, even though it is wide-spread. [...] Can I use it even if I'm not
> an
On Monday, September 12th, 2022 at 1:29 AM, Olivier Dion
wrote:
> It already can.
>
> I use this in my Makefiles: [snip]
That's a solid approach with your makefile! I tried it yesterday with just the
tar.gz and it didn't seem to work, but probably I misspelled something and then
gave up
Hi there! Lately I've been testing distribution tarballs with a workflow like
this:
- update some software in my source directory
- create a distribution tarball
- untar to a directory like /tmp/mypkg-src
- run: guix build --with-source=mypkg=/tmp/mypkg-src
It would be nice to skip step 3
ple and for trying out a Guix developer js
> workflow for me. Do you happen to know if the same approach works
> for erlang?
>
> I think we should have language developer documentation for
> general orientation of new Guix users. Ryan Prior, another Guix
> contributor/develope
On Saturday, June 4th, 2022 at 12:07 PM, Ricardo Wurmus
wrote:
> let’s add a page to the website that lists teams
> and a mail alias for each of the teams
That sounds great. What do you think about encouraging each team to write a
dedicated intro to Guix from the perspective of that team as
--- Original Message ---
On Saturday, May 28th, 2022 at 8:45 AM, Arun Isaac
wrote:
> There's still the complexity of backing up a PostgreSQL
> database
How much easier is sqlite3?
I host a Postgres server on DigitalOcean with automatic db backup. I've had to
restore, it's easy and it
--- Original Message ---
On Sunday, May 22nd, 2022 at 8:00 AM, Foo Chuan Wei
wrote:
> The shell in the environment where packages are built ignores SIGINT and
> SIGQUIT. If I add `(invoke "sh" "-c" "trap")` to a custom build phase
That executes a shell which traps and then immediately
On Wednesday, April 27th, 2022 at 2:01 PM, John Soo wrote:
> Hi Gio!
>
> I am very sorry I have let it slip.
No worries! I am planning this weekend to try out the fixes in 55013 (and try
building from upstream savannah; I didn't realize that was different from what
we have in guix) and this
Zimoun wrote:
> Today, Guix provides a script that allows to install on any foreign Linux
> distribution. [...] Guix provides a “nightly“ VM. And, IIRC, Guix is also
> available via upstream Gnome boxes. Somehow, it is already “Guix for
> Desktop”, no? ;-)
An important bit of context here is
One side-thread in "Building a software toolchain that works" notes that Guix
faces challenges for adoption because it's not readily available to users of
proprietary operating systems like macOS and Windows.
I've witnessed over the past decade that GNU/Linux development on other
platforms has
One of the side-threads in "Building a software toolchain that works" was
essentially this:
If I fetch sources for a package using Guix, with the intention to make changes
and then build and test the software myself, what should we do with any patches
& snippets that are part of the Guix
On Wednesday, March 16th, 2022 at 2:02 PM, Josselin Poiret
wrote:
> Let me chime in on a specific point.
>[...]
> I don't think I would've written these patches without Guix's help.
This is CRUCIAL to Guix's value proposition: by abstracting away so much of the
incidental complexity of
I read a Twitter thread just now, which I'll link and reproduce below, that
reminds me of something we're trying to build with Guix. Perhaps it'll resonate
with other folks here like it did with me.
Jonathan Feinberg wrote at
https://twitter.com/pheinberg/status/1503116750203797516
>I
On Friday, January 21st, 2022 at 9:03 AM, Ludovic Courtès wrote:
> The database for 18K packages is quite big:
>
> --8<---cut here---start->8---
>
> $ du -h /tmp/db*
>
> 389M /tmp/db
>
> 82M /tmp/db.gz
>
> 61M /tmp/db.zst
>
> --8<---cut
‐‐‐ Original Message ‐‐‐
On Sunday, January 16th, 2022 at 4:21 AM, Jacob Hrbek
wrote:
> Currently it's taking me 1~4 hours (depending on the system without
>
> outsourcing the load on high performance system) to build the guix
>
> repository in order to be able to test the contribution
Hey André, glad you're working on this!
I have an Emacs package with native-compilation, pgtk, sqlite3, xinput2, and
xwidgets that I call "emacs-edge" and have been using daily with Spacemacs. [1]
Hope you're able to get yours working, I'd love to move back to an upstream
Guix package instead
‐‐‐ Original Message ‐‐‐
On Friday, December 10th, 2021 at 10:40 PM, Blake Shaw
wrote:
> tldr: is there also room to discuss contributing -- and possibly doing a
> sizeable makeover to -- the Guile documentation?
Absolutely. The Guile docs are unusable and make Guile a pain to work
On Monday, October 18th, 2021 at 7:40 AM, Ludovic Courtès
wrote:
> Hi Ryan,
> How would we define “bad” though?
A definition isn't necessary, this can be an "I know it when I see it" thing.
If we have an oops or discover an issue, and say oh darn that lives in the repo
forever now, we'd be
‐‐‐ Original Message ‐‐‐
> A "bad" commit might still be perfectly fine to fetch certain things from if
> they're unaffected by it
The database could store a comment with each "bad" commit hash to help people
decide if they're affected. It could even go further and include a list of
On Friday, October 15th, 2021 at 10:03 PM, Liliana Marie Prikler
wrote:
> > On the plus side, such an attack would be recorded forever in Git
> >
> > history.
>
> On the minus side, time-machine makes said record a landmine to step
>
> into.
I've suggested this before and this seems like a
On Wednesday, September 15th, 2021 at 8:47 AM, Andrew Tropin
> People will be trying to use home services inside operating systems, and
> configuration record for system services inside home services.
I think it will be a dismal design failure if we cannot make this just work the
way people
Hey Guix.
I've been thinking lately it would be convenient to create certain uniquely
named execution environments on my machine. For example, I might have one set
up with dependencies for my Python webapp & environment variables set to
autoconnect to a Postgres server. I might have another
> [I want to bootstrap] all binaries related to creating a GNU/Linux
> distribution, such that I can reproduce an exact OS, Racket installation, and
> Xiden instance. I want a trusted initial state on GNU/Linux.
Seems like the easy path for you is to package Xiden for Guix, and then
construct
I learned today that Guix will chug happily along applying a transform to a
nonexistent package.
For example, I can run:
guix environment --with-latest=not-exist --ad-hoc which
This shows no warning or errors. I think it would be beneficial to show an
error & bail if the target of a
On Tuesday, June 22nd, 2021 at 6:53 AM, Hartmut Goebel
wrote:
> Am 06.06.21 um 21:44 schrieb Lars-Dominik Braun:
>
> > 3. Determine the fate of Python 2, which is probably broken through this
> >
> > patch set. Shall we remove it entirely? Is it worth to keep support?
>
> Python 2 is dead,
On Sunday, June 13th, 2021 at 7:04 PM, Leo Famulari wrote:
> Yeah, I agree that telemetry is a problem in addition to being valuable
>
> for developers.
I've been encouraged by the recent progress in differential privacy that
opt-out freedom respecting telemetry may be possible. I think this
On Wednesday, May 26th, 2021 at 2:02 PM, Ludovic Courtès wrote:
> > Could the new syntax accept both variables and specifications, e.g.,
> >
> > (list "glib:bin" foo "bar@2.3")
> >
> > ?
>
> No! I mean, yes it could, but no, I don’t think that’s a good idea.
>
> :-)
>
> In terms of API, I prefer
Hey Guix. There's a specific thing I'm motivated to address after the recent
security incident with the "cosmetic" patches & all the fallout of that.
In one of the comments that lead off that thread, Mark asked "does anyone else
find it worrisome that Raghav has commit access?" I speculate this
On Thursday, April 29th, 2021 at 11:43 PM, Leo Le Bouter
wrote:
> I feel like what has happened is really a disaster, I don't feel like
> contributing to GNU Guix anymore in the future.
Hey Léo, thank you for writing & for all your contributions. As a security
professional I feel you deeply
On April 23, 2021, Leo Famulari wrote:
> On Fri, Apr 23, 2021 at 10:00:14PM +0200, Leo Prikler wrote:
> > Spreadsheets sounds fine to me, but I think the most important ones
> > (libreoffice and org-mode) are already excluded from that module for
> > obvious reasons ;)
> > Perhaps an even more
On April 14, 2021, obaseki osakpolor wrote:
> Hello everyone, [snip]Â
Hi Osakpolor, I'm glad you found Guix delightful so far! I've also been
working on learning Guile, the folks in #guile on Freenode IRC chat have
been helpful. Welcome!
Ryan
On April 11, 2021, jgart wrote:
> package fosspay for guix and write a service for it
Nice idea, that looks like a really useful little service.
If any Guix maintainers are supported by community donations, send your
links so we can pitch in!
On March 14, 2021, Joshua Branson wrote:
> Andrew Tropin writes:
>
> > There is an implementation of `guix home` subcommand, which behaves
> > similar to `guix system`
Thanks for sharing this Andrew, it looks awesome & I'm going to give it
a try!
What do you think about changing the command?
On February 13, 2021, Hartmut Goebel
wrote:
> Am 09.02.21 um 17:16 schrieb Léo Le Bouter:
> > Commonly awesome lists are used to share links to all things related
> to
> > some topic or some software
>
> I wonder why not just calling it "Link list" then? [This] would be
> much
> easier to
Hi Guix! I've been digesting this piece, published hours ago, describing
dependency confusion attacks that revealed severe vulnerabilities at
many major organizations: https://medium.com/@alex.birsan/dependency-
confusion-4a5d60fec610
Guix users already have a few mitigations against this sort of
On February 2, 2021, "Nicolò Balzarotti" wrote:
> This post seems just M$ propaganda, more than a "Is anybody working on
> the
> inclusion of Powershell?"
For what it's worth I didn't read it that way.
I use PowerShell and have spent some time looking into what it would
take to build .NET Core
On January 30, 2021, "Ludovic Courtès" wrote:
> Actually, part of the code would be shared anyway, so we could always
> go
> with ‘--export-manifest’ first and think about adding the extra files
> later. (Though I’m still unsure about these extra files, TBH.)
I do like the extra files. It feels
On January 25, 2021, Lars-Dominik Braun wrote:
> Being able to demote setuptools and pip
> to ordinary packages is merely a side-effect, because they’re not
> essential any more.
I didn't read all of PEP 517, does it deprecate bundling pip with
Python? My understanding was that it just gives
On January 24, 2021, Pjotr Prins wrote:
> I was just thinking that it should be possible to login with ssh into
> a GNU Guix shell running in a container that gets fired up by the
> sshd. I am thinking about a safe shell for fetching files. If this
> works no chroot setup is required.
>
> Or is
On January 23, 2021, Lars-Dominik Braun wrote:
> [...] Remove pip and
> setuptools from python (saves almost 20MiB from the closure and avoids
> weird conflicts between python’s setuptools and python-setuptools) and
> turn them into (almost) ordinary packages.
I think if we do that then Python
On January 11, 2021, John Soo wrote:
> Hi Guix!
>
> Emacs-Guix has a new home! I just pushed
> a42f66cb40a9e60611f429a403b08dbed29bae02 to Emacs-Guix on Savannah.
Thanks and congrats!
> If you have a command you want fixed, please let me know and I will
> priortize it.
How do you feel about
‐‐‐ Original Message ‐‐‐
> By the way, your patches show that they are authored by "Ryan Prior via
> Guix-patches via guix-patc...@gnu.org". Is that the correct email address?
No, the correct email address is rpr...@protonmail.com
There's maybe 15 commits i
I don't know in depth how Proton works internally, but I think it
includes non free DLLs, including DRM support, to improve compatibility
with Windows games. If my understanding is correct, shipping Proton and
games that depend on it as part of Guix would be a tacit endorsement of
proprietary
On December 14, 2020, "Ludovic Courtès" wrote:
> Here’s another idea: allowing ‘guix copy’ to talk to a “raw” remote
> store—i.e., just /gnu/store + /var/guix/db accessed over SSH.
> Hmm that amounts to implementing a subset of the daemon.
This reminds me of the much-loved "agentless" model of
Hi there! I've been following the "guix git" discourse with interest
because I know a lot of people who care about pinning packages to
specific versions and selecting specific versions of software to
install. This constituency currently relies heavily on systems like rvm,
nvm, and conda to manage
On December 6, 2020, Ricardo Wurmus wrote:
> What do you think about adding an output format that is no format at
> all
> but a file enumeration printed to stdout? That way I could use “guix
> pack” to produce a list of files to transfer and use that to transfer
> only the unchanged files.
On December 6, 2020, Leo Famulari wrote:
> Are there any other changes we should make on [staging]?
It would be great if we can update the default Ruby to 2.7.2. Is there a
process for updating Ruby I can follow to help out?
On December 5, 2020, "Ludovic Courtès" wrote:
> many actions should be done lazily, in particular populating caches.
Absolutely.
> I’m thinking we could get rid of the mandb hook.
Please.
> 1. Provide a ‘man’ wrapper or modify the ‘man-db’ package such that
> the database gets built on the
On December 4, 2020, Raghav Gururajan
wrote:
> I can tell you that those cosmetic changes I made were 100%
> irrational, useless and noisy.
That's certainly a way to frame it, but I'd like to hold some space for
the idea that the things we neuroatypical people do to manage and
satisfy our own
Hi Mark!
On December 2, 2020, Mark H Weaver wrote:
> We all have our own personal preferences of how best to indent scheme
> code, but if more of us adopted the habit of needlessly reordering
> fields and reindenting code of every package we touch, as one of us
> seems to have done, it could get
On November 26, 2020, Jelle Licht wrote:
> On other distros it defaults to a location that is not writable by
> normal users either;
Indeed I can confirm that Ubuntu node also has this problem.
> Node doesn't do this on other distros either, correct?
> [snip]
> Another way folks solved this
Hi folks! I stumbled across an issue with the node package today and
wanted to send a report before I forget.
npm assumes that the global prefix is a writeable folder. Operations
like `npm link` will fail if it isn't. Right now our node package
doesn't set a prefix, so it defaults to the
On November 22, 2020, Danny Milosavljevic
wrote:
> Because the question is what to do if you invoke
>
> guix pack -f docker guix postgresql
> [snip]
> So I would suggest that
>
> guix system docker-image ...
>
> create /etc/passwd by merging the required user accounts like
> described
> above,
On November 20, 2020, "Ludovic Courtès" wrote:
> … what you’re doing here suggest that ‘guix pack’ should indeed create
> those files.
Oh I think it should be an option. Many Docker containers do not need
those things, but it would be great to have the option to include them.
Another option
On November 19, 2020, Pierre Neidhardt wrote:
> [--without-tests] would encourage untested builds if I
> recall correctly
That may have been a concern (I wasn't part of the conversation) but I
don't see how the current implementation could do that. If a normal
"guix build foo" fails, then it's a
On November 18, 2020, Pierre Neidhardt wrote:
> aviva writes:
>
> > nobody i know uses it. without a community of users, it has no
> purpose
>
> There must always be a first user ;)
I use Jami regularly with a few adventurous friends who like peer-to-
peer things. We often have to fall back to
On November 18, 2020, Bengt Richter wrote:
> E.g., (quoted from [1]), does the following mean that the guix daemon
> potentially could run "projects"
> instead of guixbuilder* to create "Multiple isolated environments on a
> single host" ?
> The features of Compose that make it effective are:
>
>
On November 17, 2020, Danny Milosavljevic
wrote:
> Hmm, maybe I'm misunderstanding what Docker compose does entirely.
What docker-compose does is it creates a set of Docker containers for
you based on a configuration file. In that file you define services,
filesystem volumes and their mount
On November 15, 2020, raingloom wrote:
> Alpine already achieves an incredibly tiny install size by splitting
> packages into many outputs. We could and should do the same.
> As far as I know, they do not have parameterized packages.
I definitely support more package-splitting and dependency
On November 12, 2020, "Ludovic Courtès" wrote:
> Looks nice and useful!
Thank you! If you end up using it, I'd be interested to hear feedback
about what works well and what could go in a different direction.
> Did you consider making it part of Emacs-Guix? That’d give us a single
> go-to place
On November 11, 2020, Jan Wielkiewicz
wrote:
> [web browsers are] a really poorly designed copy of
> operating systems and its utilities.
>
> [...]
>
> I just don't understand why in the web browser.
> I'll try it.
The web browser is the primary operating environment for a lot of
people. Just as
Hi folks! I use Emacs to write and maintain Guix packages, and I've
created some tools and snippets to automate repetitive tasks and remove
guesswork. If you also use Emacs, you might be interested to try them or
contribute your own.
My repository is here:
76 matches
Mail list logo
