Hi,
Ricardo Wurmus skribis:
> I’m unpacking to rsync now, but it’s not great to duplicate files on the
> local disk only to send them over the network. The ideal workflow for
> me would treat the store on my local machine as the source and the
> remote machine as the target, without any copying
Hi,
Christopher Baines skribis:
> Ludovic Courtès writes:
>
>> Following discussions on IRC, I’ve created a new ‘ungrafting’ branch
>> that does nothing but ungraft things.
>>
>> The rationale is that grafts incur additional overhead when installing
>> things (the time to create those grafts),
Hi!
Peng Mei Yu skribis:
> Ludovic Courtès writes:
>
>> Ricardo Wurmus skribis:
>>
>>> We need to make sure that *all* the files produced by “guix publish”
>>> have correct permissions; IIRC some of the files are not readable at all
>>> by users other than the owner of the files.
>>
>> Oops, I
Hi,
luhux skribis:
> I am using guix environment --container to containerize my programming
> environment and runtime environment, but I found that the container / created
> by this command uses tmpfs and cannot be resized.
>
> When a file in the container outputs a lot of logs to the tmpfs of
Hi,
Peng Mei Yu skribis:
> Good news. The maintainers of mirrors.sjtug.sjtu.edu.cn (an academic
> free software mirror site) agreed to accept Guix into their support
> list.
Nice!
> Bad news. Their first implementation of a Guix mirror failed. Their
> server architecture is like this: A fro
Hi,
zimoun skribis:
> On Sat, 12 Dec 2020 at 14:24, Magali wrote:
>
>>> Awaiting how to walk the history tree, I am proposing to use the loop as
>>> Mathieu said. However, ’match’ is preferred over ’car’.
>>
>> I got curious as to why it is preferred, hehe. Is there a special
>> reason?
>
> I
Hi Leo,
On Tue, 08 Dec 2020 at 13:20, Leo Famulari wrote:
> On Tue, Dec 08, 2020 at 03:13:40PM +0100, zimoun wrote:
>> I have missed the discussion on IRC and I do not understand the
>> rationale. What's the point of "ungrafting"?
>
> Grafts cause profile operations like `guix install` and `guix
Hi!
Ryan Prior skribis:
> I propose a different approach: the "guix versions" subcommand provides
> direct answers to practical user questions.
> - What package versions are available?
> - How do I use them?
> - Which versions are known to be vulnerable?
> - Which have available substitutes?
>
>
Hi,
Hartmut Goebel skribis:
> how to specify "dependencies of package" in a manifest?
There’s no standard procedure that does that currently (it’s buried in
(guix scripts environment)) but it’d be nice to have.
Ludo’.
Hi!
Marius Bakke skribis:
> Marius Bakke skriver:
>
>> Now the question is: should we restore this patch, and in practice
>> restart the branch almost from scratch? Or drop it, considering
>> upstream has rejected it[0]?
>
> Following a discussion on IRC, we decided to reinstate the patch and
Hi,
Thanks for your inputs.
On Sat, 12 Dec 2020 at 22:08, Ryan Prior wrote:
> I propose a different approach: the "guix versions" subcommand provides
> direct answers to practical user questions.
> - What package versions are available?
> - How do I use them?
> - Which versions are known to be
Hi Ludo,
On Mon, 14 Dec 2020 at 11:38, Ludovic Courtès wrote:
> However, it might give the false idea that users can pick
> package versions independently (as in: I want esbuild X, GCC Y, and Go
> Z), which is not really the case: packages are interrelated.
Someone tried that on help-guix. The
Hi,
On Mon, 14 Dec 2020 at 11:41, Ludovic Courtès wrote:
>> how to specify "dependencies of package" in a manifest?
>
> There’s no standard procedure that does that currently (it’s buried in
> (guix scripts environment)) but it’d be nice to have.
I had a tiny patch that export ’package-environm
On Mon, Dec 14, 2020 at 11:32:05AM +0100, zimoun wrote:
> But if grafts is here, it is because of something. Therefore, I do not
> understand what it does mean “ungraft”. Avoid the grafting mechanism
> when it is possible?
Grafts are used to "hack" the package dependency graph. We try to make
so
Thanks, Tobias. I am now properly populating the store. I have switched to
using 'guix graph --type=derivation' to pull in what seems to be the full
set of dependencies. I am seeing a strange issue when importing a package.
I can typically duplicate and import a file and it is copied to the
origina
Hi Leo,
Leo Famulari writes:
> When we added the recursive grafting feature, we intended to use it to
> deploy urgent security updates quickly, but we also intended to
> "ungraft" quickly, maybe in a week or two. We never planned to keep
> packages grafted for several months as we do now — graft
On Mon, Dec 14, 2020 at 03:03:16PM -0500, Mark H Weaver wrote:
> So, it's still a mathematical function (assuming all packages build
> deterministically), but not necessarily the same function as if normal
> upgrades had been done instead of grafts. That's the main issue with
> grafts that I'm awa
Hi Guix!
Consider these two files:
https://ci.guix.gnu.org/nar/gzip/kfcrrl6p6f6v51jg5rirmq3q067zxih6-ungoogled-chromium-87.0.4280.88-0.b78cb92
https://ci.guix.gnu.org/nar/lzip/kfcrrl6p6f6v51jg5rirmq3q067zxih6-ungoogled-chromium-87.0.4280.88-0.b78cb92
Quick decompression bench:
--8<---
My proposed changes to allow for parallel download assume downloads are
network-bound, so they can be separate from other jobs. If downloads are
actually CPU-bound, then it has indeed no merit at all :)
Le 14 décembre 2020 17:20:17 GMT-05:00, "Ludovic Courtès" a
écrit :
>Hi Guix!
>
>Consider t
Ludovic Courtès writes:
> Hi Guix!
>
Hi Ludo
> Quick decompression bench:
I guess this benchmark follows the distri talk, doesn't it? :)
File size with zstd vs zstd -9 vs current lzip:
- 71M uc.nar.lz
- 87M uc.nar.zst-9
- 97M uc.nar.zst-default
> Where to go from here? Several options:
>
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 Greg,
Greg Hogan writes:
> For the Python-3.5.9 tarball the first version loads in the expected way.
> The second tarball is restored to a new location:
>
>
> $ cp -a /gnu/store/f99fblkzb6ip268sg096shhs7wzjyp55-Python-3.5.9.tar.xz
> Python-3.5.9.tar.xz
Another option is plzip (parallel Lzip, an official part of Lzip).
> decompression of ungoogled-chromium from the LAN completes in 2.4s for
> gzip vs. 7.1s for lzip. On a low-end ARMv7 device, also on the LAN, I
> get 32s (gzip) vs. 53s (lzip).
With four cores, plzip would beat gzip in the first
23 matches
Mail list logo
