Jan writes:
> On Sat, 28 Dec 2019 10:40:09 +0100
> Pierre Neidhardt wrote:
>
>> This is indeed your problem, I suspect that something broke the
>> wrapper somehow.
>> Can you share your patch set again? I can have a look.
> I didn't really break anything - it works when launching Jami normall
Jan writes:
> Bad news:
> I still haven't got any response that would solve the bug present only
> in our package:
> https://git.jami.net/savoirfairelinux/ring-client-gnome/issues/1123
> I have not much experience with debugging and reading backtraces, but
> could it be there's something wrong
Yes, I just checked and it actually does work. I must have misremembered
something.
I also should have looked into how the bootloaders are defined. Since it is
just a public record type, I guess there is no problem whatsoever in reality.
Thanks.
03.01.2020, 01:28, "Ludovic Courtès" :
> Hi,
>
>
Hi,
On Thu, 2 Jan 2020 at 18:12, Pierre Neidhardt wrote:
> Last but not least: previously we suggested adding a subcommand like
> "guix which" or "guix filesearch". In another thread, Simon suggested
> that this would be a bad idea and factoring the file search into "guix
> search" is probably
Hi,
"kanic...@yandex.ru" skribis:
> Yes, AFAIR it only works with ‘init’ and has no effect at all with
> ‘reconfigure’.
‘--no-bootloader’ should definitely work for ‘reconfigure’; could you
double-check and report a bug if it doesn’t work?
Now, if that’s useful, we could easily define a “noo
Hi,
Mathieu Othacehe skribis:
> Well, it's not really a bug, but quite suprising at first. If you look
> at the definition of in (guix packages), you'll see that some
> fields are (thunked). %current-system and %current-target-system will
> only return valid results in (thunked) fields.
>
> As
Hello!
(Cc: maintainers.)
Brett Gilio skribis:
> Dec 30, 2019 3:34:22 PM Ludovic Courtès :
>
>> Guix-HPC is “institutional”, that’s part of the reason behind this.
>> Regarding gitlab.inria.fr, that’s because it used to be hosted at Inria.
>> Also, is a channel developed
>> by colleagues at Inr
Hi,
> It’s more than I thought but I think it’s OK. (Also, how come
> bare-bones takes 1.5 GiB?!)
That's one of my next subject of investigation :)
>> (define %default-locale-libcs
>>;; The libcs for which we build locales by default.
>> - (list (canonical-package glibc)))
>> + (list g
Je 2 jan 20:52 skribis Efraim:
> On Thu, Jan 02, 2020 at 12:29:47PM -0500, Julien Lepiller wrote:
> > Le 2 janvier 2020 12:14:50 GMT-05:00, Marco van Hulten a
> > écrit :
> > >Hello—
> > >
> > >I get an error compiling Claws Mail (claws-mail):
> > >
> > >checking for libetpan-config... no
> >
On 02.01.20 20:21, Danny Milosavljevic wrote:
> There were also changes to the DVD bootloader (grub-mkrescue) which would be
> important to release.
Adding the requirement on guile-json 3.x.x which is on master for 7
months or so now. Makes it easier to use guix-master on foreign distros,
which yo
Hartmut Goebel writes:
> Am 01.01.20 um 23:30 schrieb mike.ros...@gmail.com:
>> I think the package is looking pretty good now. I sent some changes
>> requested by Hartmut today so we might need to wait on any more changes
>> he might have.
>
> I tried applying the patches to see the complete/com
Le 2 janvier 2020 14:21:33 GMT-05:00, Danny Milosavljevic
a écrit :
>Hi Julien,
>
>On Thu, 02 Jan 2020 11:07:47 -0500
>Julien Lepiller wrote:
>
>> Instead of a release from the master branch, maybe we can apply the
>fix on top of the version-1.0.1 branch and release that? That way we
>won't need
Hi!
Bringing this topic back to life now that I'm starting working on this.
1. Everyone seems to agree that we need a dedicated field in the package
declaration.
For now, 3 names were proposed:
- parameters
- options
- argument-overrides
I find "argument-overrides" a bit too v
Hi Julien,
On Thu, 02 Jan 2020 11:07:47 -0500
Julien Lepiller wrote:
> Instead of a release from the master branch, maybe we can apply the fix on
> top of the version-1.0.1 branch and release that? That way we won't need the
> build farms to rebuild anything, while fixing the issue. We could a
Pierre Neidhardt writes:
> Hello again!
>
> I'm resurrecting this since I've just started working on this as part of
> the NGI application! :)
>
Internally it’d call ‘guix substitute’ to fetch the file index from
the substitute server, check its signature, cache it locally, and then
>>
On Thu, Jan 02, 2020 at 12:29:47PM -0500, Julien Lepiller wrote:
> Le 2 janvier 2020 12:14:50 GMT-05:00, Marco van Hulten a
> écrit :
> >Hello—
> >
> >I get an error compiling Claws Mail (claws-mail):
> >
> >checking for libetpan-config... no
> >*** Claws Mail requires libetpan 0.57 or newer. See
Hola!
Mathieu Othacehe skribis:
>> Two simple solutions here, I think:
>>
>> 1. Make ‘packages’ a thunked field.
>>
>> 2. Stop using ‘canonical-package’ altogether in ‘%base-packages’.
>>
>> I actually have a preference for #2. We’d need to check what impact it
>> has on the system closure
Le 2 janvier 2020 12:14:50 GMT-05:00, Marco van Hulten a
écrit :
>Hello—
>
>I get an error compiling Claws Mail (claws-mail):
>
>checking for libetpan-config... no
>*** Claws Mail requires libetpan 0.57 or newer. See
>http://www.etpan.org/
>*** You can use --disable-libetpan if you don't need IM
Hello—
I get an error compiling Claws Mail (claws-mail):
checking for libetpan-config... no
*** Claws Mail requires libetpan 0.57 or newer. See http://www.etpan.org/
*** You can use --disable-libetpan if you don't need IMAP4 and/or NNTP support.
configure: error: libetpan 0.57 not found
command
Le 2 janvier 2020 04:28:28 GMT-05:00, Calvin Heim a écrit
:
>Hi Guix developers,
>
>I would like to encourage interest in a new (micro?) release
>for the website.
>
>Every new systemd user who installs Guix v1.0.1
>from the binary release on a foreign distribution
>encounters the solved bug 360
Hi Guix developers,
I would like to encourage interest in a new (micro?) release
for the website.
Every new systemd user who installs Guix v1.0.1
from the binary release on a foreign distribution
encounters the solved bug 36074 [1]. It is solved,
but `guix pull` can't administer the solution b
Am 01.01.20 um 23:30 schrieb mike.ros...@gmail.com:
> I think the package is looking pretty good now. I sent some changes
> requested by Hartmut today so we might need to wait on any more changes
> he might have.
I tried applying the patches to see the complete/compiled diff, but `git
am` failed.
Thank you Efraim, this is exactly what I needed. I've applied the trick
used by GHC (simpler in my opinion), it works perfectly.
As Mathieu pointed out, this is a bit unsettling at first. Is this
(thunked) behaviour documented anywhere? If not, shall we documented
it? Where?
Cheers!
--
Pier
Hello.
Currently Guix attempts to ‘merge’ font packages which install themselves into
the same file path by generating ‘…-fonts-dir’ directories with symbolic links
and combined fonts.dir files.
Needless to say, it is completely broken. The X.org server has not been
following symbolic links to
On Fri 20 Dec 2019 22:08, Ricardo Wurmus writes:
> zimoun writes:
>
>> - I propose the name "guix shell"
>
> This is not a bad idea, especially considering that “guix environment”
> was meant to get shebang support, so that you could use it as the
> interpreter in a script that handles the envi
25 matches
Mail list logo
