> Hello Guix Devs,
>
> I've been using Guix for the last few months. As a Haskell programmer,
> I realized the latest stable that's available in the guix package
> repository is 9.2.8 which is _really_ old, considering that the
> current stable releases are at least older than 9.6.x.
>
> I'd like
> I'm currently updating Tryton to version 7.0 and am wondering whether
> it's better to contribute the change to Guix or to set up a channel for
> Tryton.
As a general rule: it is always better to contribute a change instead of
maintaining a separate channel for it if the change could be accept
>>> Now I'm trying to use it on two VPS from two different vendors, booted
>>> in rescue mode, but after the installation (via bootstrap-guix.sh) when
>>> I reboot the VPS I get the usual grub menu but the boot process suddenly
>>> fails with this error (manually copied from web console, sorry for
> in trying to build a Docker image for ARM64 (aarch64-linux), I am
> hitting errors of the kind
>
> "package git-annex@10.20230926 does not support aarch64-linux"
>
> There doesn't seem to be anything specifically in the package
> definitions that precludes building for aarch64-linux, so I sus
On Wed, Jan 17, 2024 at 12:17:26PM -0500, Greg Hogan wrote:
> What is the preferred process for when a patch review is provided
> (often by a committer) but no response is received from the submitter
> (for many weeks or months)?
>
> Is it appropriate to make the recommended changes and submit an
> A better test infrastructure in Guix would probably be good, but is not
> ready yet. Would it make sense, however, to split out those inputs only
> needed for testing?
>
> Such a step would probably make bootstrapping new architectures a lot
> easier. It would also reduce the dependency graph in
> Hi,
>
> Looking at this definition in gnu/system.scm [1] I am trying to figure
> out what 'os' is:
>
> (define* (operating-system-kernel-arguments
> os root-device #:key (version %boot-parameters-version))
> "Return all the kernel arguments, including the ones not specified
>
> Hi Saku,
>
> Am Freitag, dem 08.12.2023 um 10:42 +0200 schrieb Saku Laesvuori:
> > Hi,
> >
> > I'm planning on refreshing Guix's haskell packages as my fix for
> > https://issues.guix.gnu.org/66347Â requires rebuilding all of them
> > anyway.
Hi,
I'm planning on refreshing Guix's haskell packages as my fix for
https://issues.guix.gnu.org/66347 requires rebuilding all of them
anyway. Should I try to keep commits small with only one update per
commit (which is more work but managable if I don't care about the
commits being buildable) or
On Wed, Nov 08, 2023 at 10:18:40AM -0800, Vagrant Cascadian wrote:
> On 2023-11-08, Felix Lechner via wrote:
> > On Wed, Nov 08 2023, Maxim Cournoyer wrote:
> >> A source tree doesn't produce a derivation. A derivation is the
> >> complete build recipe that captures the source and the package
> >>
> I'd like to be part of the solution, so Saku, I'd like to help
> write the putative scripts you talk about. The main difficulty I see is
> that they need to be configured to be able to send and receive email on
> the user's behalf.
That could probably be done via git send-email. I think the hard
> Dear Guix,
>
> I've just blown up Guix's debbugs by opening (and then closing) 33 bugs
> instead of sending a 33-commits patch series.
>
> I've also seen that there is a huge discussion on the cognitive overhead
> of contributing. I will read it as soon as I can spare more time on this.
>
> I
> > > until needed (rarely). the email based model is just a flat list of
> > > messages that includes all the past mistakes, and the by now
> > > irrelevant versions.
> >
> > What the? If anything, emails are like a tree and discussions in most
> > forges are a single long list that's rarely well
> > Although now, just a few hours later, I'm having second thoughts on
> > this. When you really think about it, it's very unlinkely that some
> > user would prefer typing something like
> >
> > guix install
> > %D0%B8%D0%BC%D0%B0%D0%B3%D0%B8%D0%BD%D0%B0%D1%80%D0%B8-%D0%BF%D1%80%D0%BE%D0%B3%D1%8
>> Certainly, Nix enjoys clout, but there's nothing to stop you from
>> committing a guix.scm to your favourite project. Case in point, I
>> recently contributed to one such project on Github (via mail to the
>> devs, of course).
>
>Well, what holds me back is that many dependencies are missing, s
> >You can always check what kind of data the program gives to the
> >neural network as the program is free software. If the data is valid
> >runtime input it is also valid training data.
>
> That's not necessarily true. Like an image generating program will be
> trained on image + caption pairs,
> >If you know how to convert the blob to weights in the neural network
> >(something the program has to do to make any use of the blob) and know
> >the error function, you can continue the training with new data.
>
> Yeah, I get that, but you don't necessarily know what the weights
> mean. Let's
> Is this even practically possible? How do you re-train a blob you know
> nothing about? To me this sounds similar to saying a compiled binary
> is free software if the license allows you to decompile it and
> deobfuscate it.
If you know how to convert the blob to weights in the neural network
(s
> We should ask what is the FSF's opinion about it, if they have one.
> personally see trained data models as data more than code; so when their
> licensing allows them to be redistributed I see no objection to package
> them in Guix.
No idea whether this is FSF's official stand but in a talk[0] R
> > /run/setuid-programs/ should be at the top of your PATH.
>
> Well, the home profile ends up being first here:
I, too, have my home profile as the first one. Having peeked into
/etc/profile and ~/.guix-home/setup-environment it seems like that is
the original order without any interference fr
.
- Saku Laesvuori
signature.asc
Description: PGP signature
21 matches
Mail list logo
