Hi,
On Tue, Apr 20 2021, Maxim Cournoyer wrote:
> That's a very good question, which I asked myself recently when
> attempting to write my first non-trivial service for Guix
> (jami-daemon-service-type). I'd say 'define-configuration' is
> technically superior because of the automatic type check
Hi Ludovic,
Ludovic Courtès writes:
> Hi Maxim,
>
> Maxim Cournoyer skribis:
>
>> I've rediscovered the little gem that is (guix services configurations),
>> and attempted to make it more generally useful by adding an option to
>> opt out of serialization (which is not well adapted for producin
I've missed it unintentionally. I've not touched the "@" sign this time. :)
>> + (define page-header "Comparing")
>> +
>> (layout
>> + #:title
>> + (string-append page-header " " (string-take base-commit 8) " and "
>> + (string-take target-commit 8))
>>#:body
>>`(,(header)
Hello again,
Ludovic Courtès writes:
[...]
> diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm
> index 90f12a8d39..20e1647335 100644
> --- a/gnu/services/configuration.scm
> +++ b/gnu/services/configuration.scm
> @@ -109,6 +109,9 @@
> (define (serialize-
Hi Xinglu,
Xinglu Chen writes:
> Hi,
>
> On Tue, Apr 20 2021, Maxim Cournoyer wrote:
>
>> That's a very good question, which I asked myself recently when
>> attempting to write my first non-trivial service for Guix
>> (jami-daemon-service-type). I'd say 'define-configuration' is
>> technically
Hi,
This email is mostly addressed to Christopher Baines, due to the
Outreachy.
In the last email to me, you said this about my next steps on
contributing:
"In terms of what to do next, you could continue on this derivation
comparison path. Some of the code you've got here could be used to make
Sorry for the slow response.
On Wed, Apr 21, 2021 at 12:38:58AM +0200, Ludovic Courtès wrote:
> Hi Florian,
>
> "pelzflorian (Florian Pelz)" skribis:
> > On Tue, Apr 20, 2021 at 03:21:13AM +0200, pelzflorian (Florian Pelz) wrote:
> >> > git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd
> > It
I just noticed that 'glib' is still grafted on the 'wip-ungrafting'
branch. Was that intentional?
https://git.sv.gnu.org/cgit/guix.git/tree/gnu/packages/glib.scm?h=wip-ungrafting&id=e12210dc92098d8581cea3007d57dbb6be16bb41#n171
Mark
Hello Guix,
Raghav Gururajan has pushed another misleading "cosmetic changes"
commit. This one is *far* worse than the examples I gave before.
This one removes the security fixes for CVE-2018-19876 and
cairo-CVE-2020-35492 that I had applied in commit
bc16eacc99e801ac30cbe2aa649a2be3ca5c102a.
Be
... and here's another "cosmetic changes" commit from Raghav that
removes all of the security fixes for 'glib' that I had added:
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-gnome&id=40b58074895ee510cab496655e6bec8d95abe693
Also, both of these commits were marked as:
"Signed-off
Hi Mark,
Am Mittwoch, den 21.04.2021, 17:11 -0400 schrieb Mark H Weaver:
> Hello Guix,
>
> Raghav Gururajan has pushed another misleading "cosmetic changes"
> commit. This one is *far* worse than the examples I gave before.
> This one removes the security fixes for CVE-2018-19876 and
> cairo-CVE
Hi all,
Thanks for keeping a critical eye on WIP branches, Mark.
Raghav, can you explain why you created that commit? What's the
context & the goal? Why is it on current wip-gnome? What do you
expect to happen to it?
Léo, all the same questions for you, plus:
Mark H Weaver writes:
"Sign
On Wed, Apr 21, 2021 at 04:47:06PM -0400, Mark H Weaver wrote:
> I just noticed that 'glib' is still grafted on the 'wip-ungrafting'
> branch. Was that intentional?
>
> https://git.sv.gnu.org/cgit/guix.git/tree/gnu/packages/glib.scm?h=wip-ungrafting&id=e12210dc92098d8581cea3007d57dbb6be16bb41#n17
On Thu, Apr 22, 2021 at 12:16:13AM +0200, Leo Prikler wrote:
> However, in taking more time to let patches sit on the
> mailing list, I fear that I might come off as "unwilling" to those
> contributors, whose work I help review, including Raghav, and also that
> my involvement in some patch discuss
Hi All!
Sorry, I just saw this email and noticed its thread via web. I wasn't
subscribed.
> Raghav, can you explain why you created that commit? What's the
> context & the goal? Why is it on current wip-gnome? What do you
> expect to happen to it?
The commit is not new. I cherry-picked from c
Hi Mark!
Raghav Gururajan has pushed another misleading "cosmetic changes"
commit.
When you brought-up the concern
(https://lists.gnu.org/archive/html/guix-devel/2020-12/msg8.html),
which I am grateful for, I have worked myself to prevent that from
happening. It was so hard for me provi
On Wed, 21 Apr 2021 12:45:21 +0200
Xinglu Chen wrote:
> One thing that I find a little annoying is that you have to specify a
> default value for the fields.
Are you sure? If you don't specify a default, won't the user just be
forced to write
(service whatever
(whatever-configuration
Hi Raghav,
Raghav Gururajan writes:
>> Raghav Gururajan has pushed another misleading "cosmetic changes"
>> commit.
[...]
>> This one is *far* worse than the examples I gave before.
>> This one removes the security fixes for CVE-2018-19876 and
>> cairo-CVE-2020-35492 that I had applied in commit
Hi Mark!
Those commits on 'core-updates' were digitally signed by Léo Le Bouter
and have the same problems: they remove security
fixes, and yet the summary lines indicate that only "cosmetic changes"
were made.
Yeah, the commit title didn't mention the change but the commit message did.
I'm
Hi Mark!
For glib, IIRC, we updated package to latest version and guix lint
didn't show any more CVEs. Also, I think the change was added as part of
the cosmetic change commit, to cleanly apply succeeding patches.
For cairo, let me get back to you.
Okay, I was able to retrace. When Leo and
Hi Raghav,
Raghav Gururajan writes:
>> Those commits on 'core-updates' were digitally signed by Léo Le Bouter
>> and have the same problems: they remove security
>> fixes, and yet the summary lines indicate that only "cosmetic changes"
>> were made.
>
> Yeah, the commit title didn't mention the
Hi Raghav,
Raghav Gururajan writes:
> Okay, I was able to retrace. When Leo and I were working outside
> savannah, there was master --> core-updates merge. Leo made these
> changes when he committed to his repo
> (https://logs.guix.gnu.org/guix/2021-03-26.log#000811), from which I
> pulled t
Hi Mark!
(1) These original summary lines are still misleading, because "ungraft"
means to integrate the fixes from the replacement into the original,
but here, the fixes are simply being deleted.
I see. Now I get the idea. Thanks for explaining this.
(2) These original commit logs
Efraim Flashner writes:
>> If it's a test failure, has the issue been reported upstream?
>
> I'll check to see if I can find something upstream. If not I'll report
> it. FWIW Debian disables the test suite for powerpc.
> https://sources.debian.org/src/binutils/2.36.1-6/debian/rules/#L537
How sig
Hello Mathieu,
> Hello,
>
> Thanks for this patch, it seems to work fine!
>
> > - ;; Extract the substitute URLs of the user configuration.
> >
> >
> > - (os (read-operating-system
> > (%installer-configuration-file)))
> >
> >
> > - (substitute-urls (and
On Fri, 31 Jul 2020, Jack Hill wrote:
Hi Guix,
I'm wondering why we use Lua 5.1 instead of LuaJIT for neovim? It seems that
upstream prefers LuaJIT given the non-default configure flag we use[0] and
their FAQ[1].
I don't have an opinion either way. I'm learning about neovim today, and am
c
26 matches
Mail list logo
