Hey,
> I'm not seeing any size difference, but groff is not in the output:
OK, then its normal.
> That fails on master (libpaper) whereas with the patch it works,
> so I guess the patch is useful on that front.
>
> The patch for sudo will be in the following emails.
>
> Is there anything else
> I only build-tested them natively on/for x86_64 (and
> cross built for aarch64 for the sudo one)
This LGTM, I added your copyright on the two first patches and pushed!
Thanks,
Mathieu
Hello,
On Tue, Mar 31, 2020 at 9:45 AM Mathieu Othacehe wrote:
> This LGTM, I added your copyright on the two first patches and pushed!
Thanks for handling that.
Stay tuned for the next batch.
Christopher, looks like your work on data.guix.gnu.org already triggered
something useful ! ;-)
--
V
> Christopher, looks like your work on data.guix.gnu.org
> already triggered something useful ! ;-)
And the view for comparing with previous run is just showing
me what I wanted to see, perfect !
Question: would this view show any `guix size` difference if any ?
Keep up the good work !
--
Vinc
Vincent,
Vincent Legoll 写道：
I'm not seeing any size difference, but groff is not in the
output:
There's some deeper confusion here: why do you expect the size to
change, at all?
Making ‘groff’ native was the right thing to do (and please, keep
fixing bugs like this! :-) but it has nothing
Hello,
On Tue, Mar 31, 2020 at 11:44 AM Tobias Geerinckx-Rice wrote:
> Vincent Legoll 写道：
> > I'm not seeing any size difference, but groff is not in the
> > output:
>
> There's some deeper confusion here: why do you expect the size to
> change, at all?
Because I've been told so...
On Mon, Mar
Hey Ludo!
I have been hanging out in #guix recently, and I have submitted a few
guix bug reports (not many). I just wanted to thank you for the
community that you have built with Guix. I have done some minor
volunteer work with other free software projects, but those other free
software projects
Vincent Legoll writes:
>> Making ‘groff’ native was the right thing to do (and please, keep
>> fixing bugs like this! :-) but it has nothing to do with making
>> packages smaller.
>
> Never will ?
>
> I'm not expecting package size to shrink, but package closure
> (is that the right word) size to
Hello,
bijan ghavami-kia skribis:
> Thank you kindly for the reply! I have one question born out of my ignorance,
> so please be patient with me; I am looking at the various
> packages, which belong to various repos eg CRAN, TeXlive etc;
> for the julia language..., is there a similar thing, o
Hello Guix!
I have finished packaging all the linphone project's packages. \o/
PATCH: https://issues.guix.gnu.org/issue/40264
SOURCE: https://cloud.disroot.org/f/94900047
There will be no new patches and only revision patches. :-)
Regards,
RG.
Hi!
Vagrant Cascadian skribis:
> On 2020-03-29, Danny Milosavljevic wrote:
>> Hi Ludo,
>>
>> On Sun, 29 Mar 2020 16:44:39 +0200
>> Ludovic Courtès wrote:
>>
>>> Oh, really? I’m surprised partitioning causes problems (though I’m
>>> not familiar with embedded dev!).
>>
>> Well, maybe not that b
Hi,
Vincent Legoll skribis:
> On Sun, Mar 29, 2020 at 5:00 PM Ludovic Courtès wrote:
>> So my recommendation would be to fix [4] specifically for ‘guix-daemon’
>> by adding a ‘set-proxy’ action or something.
>
> Trying to understand what that would imply, I stumbled upon my
> ignorance of how t
Vincent Legoll writes:
>> Christopher, looks like your work on data.guix.gnu.org
>> already triggered something useful ! ;-)
>
> And the view for comparing with previous run is just showing
> me what I wanted to see, perfect !
Nice, I'm glad that you're enjoying using the Guix Data Service, and
On Tue, 31 Mar 2020 at 15:06, Leandro Doctors wrote:
> Below, I share the final version I uploaded to the GSoC website.
Another bug: I didn't mention how I plan to publicly report my
progress over the course of my work. Besides the normal interaction
via this list, I will send (at least) three pr
Hello,
On Tue, Mar 31, 2020 at 3:25 PM Marius Bakke wrote:
> Unless you are cross-compiling (i.e. guix build --target=foo),
> native-inputs and inputs behave exactly the same; they are simply
> concatenated.
OK, thanks for the clarification.
Christopher, I'm not a web guy, I may take a shot at
* gnu/packages/games.scm (nethack)[native-inputs]: New field.
[inputs]: Move flex & bison to native-inputs.
---
gnu/packages/games.scm | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
index 3284459021..addadebbba 100644
--- a
* gnu/packages/networking.scm (iwd)[native-inputs]: New field.
[inputs]: Move libtool to native-inputs.
---
gnu/packages/networking.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gnu/packages/networking.scm b/gnu/packages/networking.scm
index ec2f0b64bd..79b07e23f0 100644
* gnu/packages/version-control.scm (cgit)[native-inputs]: New field.
[inputs]: Move groff & python-docutils to native-inputs.
---
gnu/packages/version-control.scm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-contro
* gnu/packages/mail.scm (mailutils)[native-inputs]: New field.
[inputs]: Move dejagnu & texinfo to native-inputs.
---
gnu/packages/mail.scm | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/gnu/packages/mail.scm b/gnu/packages/mail.scm
index 36b94f409f..458d82ecce 100644
* gnu/packages/photo.scm (darktable)[native-inputs]: New field.
[inputs]: Move intltool & pkg-config to native-inputs.
---
gnu/packages/photo.scm | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/photo.scm b/gnu/packages/photo.scm
index 585289daf1..9f6e4a3031 1
* gnu/packages/graphviz.scm (graphviz)[native-inputs]: New field.
[inputs]: Move swig to native-inputs.
---
gnu/packages/graphviz.scm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/graphviz.scm b/gnu/packages/graphviz.scm
index 2d2bb11130..051089881a 100644
---
Hi! I found here in Guix not only the idea that implements
- free software
- reproducible builds,
- better control over system
- and something for the 5th industrial revolution
but also community and relations with the other projects.
Guix uses sources from the different original places (from the
Vincent,
Thank you!
This list is for general Guix discussion. Although that can
sometimes include rough patches (heh), please send any future
contributions to our patch tracker at guix-patc...@gnu.org — after
carefully reading the ‘Submitting Patches’ section of the Guix
manual.
Vincent L
I was on a while back about using IPFS or some other CAS to cache
computation and results. I iterated on this concept with metadata, then
data, then just files as a fundamental concept. It became abundantly clear
that how we use, think, and need from and about files are not what computer
files ar
Spelling and grammar fixes. Automatic tools have become insufficient to
catch everything.
On Tue, Mar 31, 2020 at 9:33 PM Josh Marshall <
joshua.r.marshall.1...@gmail.com> wrote:
> I was on a while back about using IPFS or some other CAS to cache
> computation and results. I iterated on this co
Hi Björn,
thanks for the list of suggestions!
> * First of all, I find this mixture very confusing: Is this about bugs
> or is this about patches? I really don't know, and the start page is
> ambigious about it too:
>
> "Guix /patch/ tracker
> This is a web frontend to the Guix /issue/ trackers
Hello. As of now, building a system requires that the kernel package includes the lib/modules directory, probably with at least some loadable modules, which is not necessary the case for custom packages. This can be fixed trivially with a check in operating-system-directory-base-entries: (packages-
Hi Leandro,
A quick message to let you know that I'm very excited by your project!
I've recently started developing with Clojure and I'd love to see a
Clojars importer become reality!
Good luck!
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
28 matches
Mail list logo
