Hello Brice,
I think it would be useful to warn users that when pulling there is
a direct connection to guix git repos, so to route it through Tor,
one needs to use torsocks. It wont make the configuration foolproof,
but it will reduce the leaks to clearnet.
From 6a73b1b1129d3d636d7a0559dffa19e5d
Thank you for the direct reply, zimoun.
> [The problem] is a pragmatic one. As any good Zen says: "Now is better than
> never. Although never is often better than *right* now."
Okay. If that is the case, then I very much empathize with the problem.
> Going from imperative/sequential "install, pu
From ac47ba538dd5cf628b26cce05e3b15b24ca03077 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9=20Batista?=
Date: Tue, 16 Jun 2020 19:20:57 -0300
Subject: [PATCH] gnu: Add tor-client.
To: guix-devel@gnu.org
* gnu/packages/tor.scm (tor-client): New variable.
---
gnu/packages/tor.scm | 31 +
Ludovic Courtès writes:
>> 3: http://theworld.com/~cme/spki.txt
>>
>> Using the above ACL, you'd trust a substitute for a path with a specific
>> hash if you can find 2 narinfos for that path and hash if they're signed
>> with keys in that entry. Multiple entries would still be supported, and
>>
Hi Ricardo,
On Tue, 16 Jun 2020 at 17:34, Ricardo Wurmus wrote:
> That’s correct. Outputs are buckets into which we drop build
> artifacts. We will build everything with all inputs in one derivation
> and then move stuff into output buckets. This means that you can
> download independent outp
On Tue, 16 Jun 2020 at 10:28, Julien Lepiller wrote:
>>If I run "guix install foo:out --no-substitutes" then I potentially
>>build any other "outputs"" of foo, e.g., "doc" i.e., potentially
>>download a lot of TeX stuff, or in the case of Git, all the Subversion
>>stuff. Right?
>
> Yes, becaus
zimoun writes:
> On Sat, 13 Jun 2020 at 12:16, Christopher Baines wrote:
>
>> Looking at different outputs, the references are different. If you're
>> just using the "out" output, then you don't need subversion in your
>> store, but if you're using the "svn" output, then you do, as that output
Hi,
Speaking about Makefile and Guix documentation, I have remarked things
(maybe I am doing wrong) that annoys me time to time.
1. "make info" is not self consistent.
--8<---cut here---start->8---
./doc/guix.texi:11297: @include: could not find os-config-bare
Dear,
On Tue, 16 Jun 2020 at 10:03, George Clemmer wrote:
> "manifest" occurs ~600 times in the ./guix directory. I am guessing its
> use is deeply embedded with developers. If so, renaming it internally
> seems like a bad idea. And if we write our internal manifest into the
> profile and call i
Le 16 juin 2020 08:41:58 GMT-04:00, zimoun a écrit :
>Bonjour Julien,
>
>On Sat, 13 Jun 2020 at 07:38, Julien Lepiller
>wrote:
>
>> Exactly, no. You cannot separate inputs from outputs, because they
>are
>> part of the same derivation. When you build an output, you actually
>> build the complete
Hi zimoun,
zimoun writes:
> In contradiction with what I wrote above, I agree. :-)
>
> /manifest should be renamed /specifications or
> something like that.
>
> And a comment could be inserted in this file saying: internal usage, do
> not modify, etc..
>
> WDYT?
Sure, that would work. But, on
Dear,
On Tue, 16 Jun 2020 at 20:33, elaexuo...@wilsonb.com wrote:
>> 1. We can only approximate that actual profile content; storing
>>an approximate ‘manifest.scm’ along with the profile would IMO be
>>deceptive.
>
> Is this a technical barrier or a pragmatic one?
[...]
> If the problem
Bonjour Julien,
On Sat, 13 Jun 2020 at 07:38, Julien Lepiller wrote:
> Exactly, no. You cannot separate inputs from outputs, because they are
> part of the same derivation. When you build an output, you actually
> build the complete derivation and there's no way to separate that in
> "this part
Hi Chris,
Thank you for explaining. It still miss a point.
On Sat, 13 Jun 2020 at 12:16, Christopher Baines wrote:
> Looking at different outputs, the references are different. If you're
> just using the "out" output, then you don't need subversion in your
> store, but if you're using the "sv
Hello!
This new post introduces the work I did to have a fully reproducible
replication (!) of a 13-year old article, using Guix to express the
whole pipeline:
https://hpc.guix.info/blog/2020/06/reproducible-research-articles-from-source-code-to-pdf/
Feedback welcome!
Ludo’.
> 1. We can only approximate that actual profile content; storing
>an approximate ‘manifest.scm’ along with the profile would IMO be
>deceptive.
Is this a technical barrier or a pragmatic one?
If it is the former, then I don't quite grok why. I explain my reasoning in
great detail in a pr
Efraim Flashner writes:
> I see the include directory is about 20MB, can that be left in "out" or
> is that needed in the "lib" output?
It can be left out, I mentioned it in my first email.
>> Where would we store the different backends? In different outputs?
>> On which backend does Mesa depe
Hi!
Mathieu Othacehe skribis:
> Here's a wip patch for the website. It adds a new "download/latest"
> page allowing to download the latest Guix System images from Cuirass.
>
> I've merged all the required mechanisms in Guix and Cuirass, now most of
> the remaining work is "cosmetic" (and that's
Hi Edouard,
Edouard Klein skribis:
> Ludovic Courtès writes:
[...]
>> However, this is definitely something ‘guix lint’ could check with
>> something along the lines of the patch below.
>
> Thank you for pushing profile-collisions, it certainly is helpful for
> finding such problems, and it pe
Hi,
George Clemmer skribis:
> Yes, only 'manifest.scm' is in the doc, but '.guix-profile/manifest'
> smacks a user in the face pretty quickly which leads to these messy
> questions.
That’s something I had not anticipated. It’s an interesting lesson!
Ludo’.
Hi,
zimoun skribis:
> On Sun, 14 Jun 2020 at 17:24, Ludovic Courtès wrote:
>
>> I think there were several issues we discussed:
>>
>> 1. We can only approximate that actual profile content; storing
>> an approximate ‘manifest.scm’ along with the profile would IMO be
>> deceptive.
>>
On Tue, Jun 16, 2020 at 11:27:45AM +0200, Pierre Neidhardt wrote:
> Ludovic Courtès writes:
>
> >> - either move the libs to a "lib" output,
> >> - or move the "bin" and "include" folder to a new output.
> >>
> >> The second approach has the benefit of being less disruptive for
> >> dependents.
Hi Pierre,
Pierre Neidhardt skribis:
> Ludovic Courtès writes:
>
>> I think there were several issues we discussed:
>
> Allow me to reiterate, at the risk of bikeshedding... :)
>
>> 1. We can only approximate that actual profile content; storing
>> an approximate ‘manifest.scm’ along wit
Hi,
Chris Marusich skribis:
> First, consider this snippet from doc/local.mk:
>
> # We cannot add new dependencies to `%D%/guix.pdf' & co. (info "(automake)
> # Extending"). Using the `-local' rules is imperfect, because they may be
> # triggered after the main rule. Oh, well.
> pdf-local: $(D
Ludovic Courtès writes:
> Pierre Neidhardt skribis:
>
>> Is it worth including in guix/etc?
>
> I think it’d be nice!
I fixed a bug and added etc/committer.scm.in.
--
Ricardo
Dear,
On Mon, 15 Jun 2020 at 22:51, George Clemmer wrote:
> ISTM we set ourselves up for confused users and a lot of explaining by
> labeling two very different things with same name :-0
I think there is a confusion here. The file /manifest is an
internal detail implementation and the user sho
Hi!
Christopher Baines skribis:
> My feeling is that making some initial step forward in this area is
> going to be tricky, care needs to be taken around the security and
> backwards compatibility aspects. I've now got around to actually
> thinking about potential ways to make parts of this happ
Ludovic Courtès writes:
>> - either move the libs to a "lib" output,
>> - or move the "bin" and "include" folder to a new output.
>>
>> The second approach has the benefit of being less disruptive for dependents.
>
> I have a slight preference for a “lib” output since that’s more in line
> with w
Hi,
Pierre Neidhardt skribis:
> For the first 2 links, click on
> "View the file list for ..." link at the bottom to display the file
> list.
>
> "bin" and "include" occupy some 35 MiB. First thing we can do is split
>
> - either move the libs to a "lib" output,
> - or move the "bin" and "inclu
Dear,
On Mon, 15 Jun 2020 at 19:08, elaexuo...@wilsonb.com wrote:
> I went ahead and read through the threads that Pierre shared in a different
> reply. For posterity and to collect my own thoughts, let me see if I can
> distill the discussion so far:
[...]
> If the answer to the final question
Danny Milosavljevic writes:
Hi Danny,
> On Mon, 15 Jun 2020 14:54:39 +0200
> Jan Nieuwenhuizen wrote:
>
>> I’ve published a post about the second big reduction of the Guix
>> bootstrap binaries
>>
>> https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/
>
> "again decide
31 matches
Mail list logo
