The default value for “magit-git-executable” (when magit is installed
via Guix) appears to be a store path, such as
“/gnu/store/l7g5r1c2i0bf3cd71g53ajy8khdcyidz-git-2.16.1/bin/git”. This
means that when magit is used over TRAMP it will try to find the exact
same git executable on the remote.
Inst
On Mon, Feb 12, 2018 at 01:16:41AM +0100, Danny Milosavljevic wrote:
> git-fetch doesn't allow specifying "--depth 1".
>
> That means the repo clones are needlessly large.
>
> Since in packages we only need one specific commit anyhow why do we fetch
> all the other commits?
I think it's worth ad
On Sun, Feb 11, 2018 at 03:34:42PM +, Marius Bakke wrote:
> Never mind, it was actually completed by the time I packed up.
> I pushed it (and fixed the merge conflict in xml.scm, sorry about that!).
Awesome, thanks!
signature.asc
Description: PGP signature
This is fixed now that we ship an SELinux policy for the daemon in
etc/guix-daemon.cil
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
n...@crash.cx writes:
> Turns out so far that it works when you make /usr/bin/perl as a
> special file type link available on the system, as the problem is
> some unchanged hook lines pointing to this instead of the store.
The error messages you posted seem unrelated to whether /usr/bin/perl is
Package: guix
After installing and running libreoffice with
$ guix package -i libreoffice@5.3.7.2
$ soffice
no fonts show up (see attached screenshot).
Following the instructions provided by
https://www.gnu.org/software/guix/manual/html_node/Application-Setup.html#Application-Setup
I did
$ guix
Trying to install bigloo@4.3b leads to a hash mismatch.
This was reproduced by several people.
On Mon, Feb 12, 2018 at 05:43:35PM +0100, Amirouche Boubekki wrote:
> Trying to install bigloo@4.3b leads to a hash mismatch.
>
> This was reproduced by several people.
Can you copy and paste the error message here?
signature.asc
Description: PGP signature
Hello,
I think it would work better if when installing python@3, a ‘python’
executable would be available in the PATH. Maybe there is a technical
reason for not doing so, but I find its absence rather confusing.
Thanks for considering it.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0
Hi Mathieu,
On Mon, 12 Feb 2018 17:52:41 +0100
Mathieu Lirzin wrote:
> I think it would work better if when installing python@3, a ‘python’
> executable would be available in the PATH. Maybe there is a technical
> reason for not doing so, but I find its absence rather confusing.
For backward c
On 2018-02-12 17:59, Leo Famulari wrote:
On Mon, Feb 12, 2018 at 05:43:35PM +0100, Amirouche Boubekki wrote:
Trying to install bigloo@4.3b leads to a hash mismatch.
This was reproduced by several people.
Can you copy and paste the error message here?
$ guix package -i bigloo@4.3b
substitute:
Ricardo Wurmus (2018-02-12 13:53 +0100) wrote:
> The default value for “magit-git-executable” (when magit is installed
> via Guix) appears to be a store path, such as
> “/gnu/store/l7g5r1c2i0bf3cd71g53ajy8khdcyidz-git-2.16.1/bin/git”. This
> means that when magit is used over TRAMP it will try to
On Mon, Feb 12, 2018 at 06:23:07PM +0100, Danny Milosavljevic wrote:
> Hi Mathieu,
>
> On Mon, 12 Feb 2018 17:52:41 +0100
> Mathieu Lirzin wrote:
>
> > I think it would work better if when installing python@3, a ‘python’
> > executable would be available in the PATH. Maybe there is a technical
On Sun, Feb 11, 2018 at 10:35:48AM -0500, Leo Famulari wrote:
> And CVE-2018-135 may be mitigated by the compiler. I'll investigate
> more.
The researcher's advisory recommends building UnZip with FORTIFY_SOURCE
to reduce the impact of the bug. The attached patch does that.
AFAICT, the proof-
Efraim Flashner writes:
> On Mon, Feb 12, 2018 at 06:23:07PM +0100, Danny Milosavljevic wrote:
>> Hi Mathieu,
>>
>> On Mon, 12 Feb 2018 17:52:41 +0100
>> Mathieu Lirzin wrote:
>>
>> > I think it would work better if when installing python@3, a ‘python’
>> > executable would be available in th
Hi,
Danny Milosavljevic writes:
> On Mon, 12 Feb 2018 17:52:41 +0100
> Mathieu Lirzin wrote:
>
>> I think it would work better if when installing python@3, a ‘python’
>> executable would be available in the PATH. Maybe there is a technical
>> reason for not doing so, but I find its absence rat
Alex Kost writes:
> Ricardo Wurmus (2018-02-12 13:53 +0100) wrote:
>
>> The default value for “magit-git-executable” (when magit is installed
>> via Guix) appears to be a store path, such as
>> “/gnu/store/l7g5r1c2i0bf3cd71g53ajy8khdcyidz-git-2.16.1/bin/git”. This
>> means that when magit is use
help-debb...@gnu.org (GNU bug Tracking System) writes:
> From: Ricardo Wurmus
> Subject: Re: bug#30437: No “.guix-profile/bin/python” after ‘guix package -i
> python’
> To: 30437-d...@debbugs.gnu.org
> Date: Mon, 12 Feb 2018 20:00:57 +0100 (38 minutes, 1 second ago)
> User-agent: mu4e 0.9.18; em
Hi Leo,
On Mon, 12 Feb 2018 10:09:39 -0500
Leo Famulari wrote:
> I think it's worth adding, but as an option, because there are Git
> server implementations, like JGit, that don't support shallow cloning.
Thanks for that! I didn't consider that before...
Possible patch (do you know such serve
Mathieu Lirzin writes:
> Hi,
>
> Danny Milosavljevic writes:
>
>> On Mon, 12 Feb 2018 17:52:41 +0100
>> Mathieu Lirzin wrote:
>>
>>> I think it would work better if when installing python@3, a ‘python’
>>> executable would be available in the PATH. Maybe there is a technical
>>> reason for no
Ricardo Wurmus writes:
> Mathieu Lirzin writes:
>
>> Danny Milosavljevic writes:
>>
>>> On Mon, 12 Feb 2018 17:52:41 +0100
>>> Mathieu Lirzin wrote:
>>>
I think it would work better if when installing python@3, a ‘python’
executable would be available in the PATH. Maybe there is a t
I think Google uses JGit for their public facing Git servers, but I'm not sure.
On February 12, 2018 5:59:50 PM EST, Danny Milosavljevic
wrote:
>Hi Leo,
>
>On Mon, 12 Feb 2018 10:09:39 -0500
>Leo Famulari wrote:
>
>> I think it's worth adding, but as an option, because there are Git
>> server i
22 matches
Mail list logo
