Hello,
Xinglu Chen writes:
> On Wed, Apr 21 2021, Maxim Cournoyer wrote:
>
>>> One thing that I find a little annoying is that you have to specify a
>>> default value for the fields. This doesn’t make much sense in some
>>> cases, e.g. there is no good default value for ‘user.name = NAME’ in
Ludovic Courtès writes:
> Hi!
>
> (“Sorry for the long delay” is officially my motto at this point.)
>
> Christopher Baines skribis:
>
>> This has been on my mind for a while, as I wonder what effect it has on
>> users fetching substitues.
>>
>> The narinfo caching as I understand it works as
Hi,
Maxim Cournoyer skribis:
>> +(define-syntax-rule (without-field-serialization definition)
>> + (syntax-parameterize ((configuration-field-serialization?
>> + (identifier-syntax #f)))
>> +definition
>> +#t))
>> +
>> +(without-field-serialization
>> +
BTW, one thing that would be interesting too is to return 404 with a
long ‘Cache-Control’ validity when the requested store item is among the
cached failures.
We could also add an extra response header to explicitly communicate
that the store item is known to fail to build.
Ludo’.
Hi!
(“Sorry for the long delay” is officially my motto at this point.)
Christopher Baines skribis:
> This has been on my mind for a while, as I wonder what effect it has on
> users fetching substitues.
>
> The narinfo caching as I understand it works as follows:
>
> Default success TTL => 36
Hi Guix!
Thanks Mark for raising these issues. I definitely share your concerns,
specifically regarding the two commits you mentioned and how they
misleadingly have undesirable consequences:
Hi Leo!
Raghav and Léo, is wip-gnome based on core-updates?
It was based on core-updates, but I recently re-created wip-gnome based
on master.
Regards,
RG.
OpenPGP_signature
Description: OpenPGP digital signature
Hi Mark!
Thank you for these links. From the IRC log cited above, it now appears
that Léo Le Bouter bears primary responsibility
for these mistakes. In particular, according to the IRC
logs, Léo wrote:
raghavgururajan: the main issues on the rebasing were about
security fixes on
Léo Le Bouter writes:
> On Thu, 2021-04-22 at 13:40 -0400, Mark H Weaver wrote:
>> This commit was digitally signed and pushed to the 'wip-gnome' branch
>> by
>> Raghav, but it's also "Signed-off-by: Léo Le Bouter", so I'm not sure
>> who bears primary responsibility for this one.
>
> It seems
Léo,
On Thu, 2021-04-22 at 13:40 -0400, Mark H Weaver wrote:
This commit was digitally signed and pushed to the 'wip-gnome'
branch
by
Raghav, but it's also "Signed-off-by: Léo Le Bouter", so I'm
not sure
who bears primary responsibility for this one.
It seems you are more focused and
Hi Léo,
Léo Le Bouter writes:
> I don't share your analysis, the security fixes werent stripped because
> glib/cairo was also updated to latest version in subsequent commits
> which were pushed all at once.
'glib' was updated, but 'cairo' wasn't, presumably because there's no
newer stable
Luciana Lima Brito writes:
> On Thu, 22 Apr 2021 21:08:08 +0100
> Christopher Baines wrote:
>
>> I'm not quite sure what you mean by empty fields in the JSON here?
>
> I mean now it appears like this in the json
>
> hash-alg: {}
>
> Before, it was entirely omitted.
Right, OK. I'd call
Am Donnerstag, den 22.04.2021, 22:01 +0200 schrieb Léo Le Bouter:
> On Thu, 2021-04-22 at 00:08 -0400, Mark H Weaver wrote:
> > Hi Raghav,
> >
> > Raghav Gururajan writes:
> >
> > > > Those commits on 'core-updates' were digitally signed by Léo Le
> > > > Bouter
> > > > and have the same
Léo Le Bouter writes:
> On Thu, 2021-04-22 at 00:08 -0400, Mark H Weaver wrote:
>> 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,
On Thu, 22 Apr 2021 21:08:08 +0100
Christopher Baines wrote:
> I'm not quite sure what you mean by empty fields in the JSON here?
I mean now it appears like this in the json
hash-alg: {}
Before, it was entirely omitted.
> It sounds like you're roughly on the right track, do share what
Luciana Lima Brito writes:
> Hi,
>
>> Small intentional changes are better, so I'd start just with looking
>> at some of the data coming out of the query. But yes, I think you're
>> in the right place. The hard part here is probably to look at how
>> those values are used in the JSON and HTML
On Thu, 2021-04-22 at 13:40 -0400, Mark H Weaver wrote:
> This commit was digitally signed and pushed to the 'wip-gnome' branch
> by
> Raghav, but it's also "Signed-off-by: Léo Le Bouter", so I'm not sure
> who bears primary responsibility for this one.
It seems you are more focused and spend
Canan Talayhan writes:
> 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
On Thu, 2021-04-22 at 00:08 -0400, Mark H Weaver wrote:
> 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
Hi,
> Small intentional changes are better, so I'd start just with looking
> at some of the data coming out of the query. But yes, I think you're
> in the right place. The hard part here is probably to look at how
> those values are used in the JSON and HTML rendering code, and adjust
> that
Hi Leo,
Leo Famulari writes:
> On Thu, Apr 22, 2021 at 12:05:36AM -0400, Raghav Gururajan wrote:
>> 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
>>
On Thu, Apr 22, 2021 at 12:05:36AM -0400, Raghav Gururajan wrote:
> 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),
On Thu, Apr 22, 2021 at 12:27:52PM -0400, Mark H Weaver wrote:
> I don't understand why it's relevant how many patches are involved. It
> sounds like if I had concatenated all of the CVE-2021-27219 patches into
> a single file, you would have judged that as "simple", and therefore
> ungrafted it,
Here's another commit with a blatantly misleading commit log:
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-gnome=f5fc3c609e2f38ca1c0523deadb9f77d838fbf32
The summary line is "gnu: gdk-pixbuf: Add missing arguments", but in
fact it does all of the following:
(1) Ungrafts
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
Efraim Flashner schreef op do 22-04-2021 om 10:59 [+0300]:
> * gnu/packages/version-control.scm (mercurial)[arguments]: Skip tests on
> powerpc-linux.
> ---
> gnu/packages/version-control.scm | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> Unchanged since last patchset, IMO not
Hi Leo,
Leo Famulari writes:
> 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?
>>
>>
Hi,
we have a couple of issues with a new proposed interesting package:
Weir, written in Common Lisp.
This is the proposed patch:
https://issues.guix.gnu.org/issue/47943
There are a couple of problems:
1. the code from the book "On Lisp" by Paul Graham is not free software
(AFAIU): please any
Hi,
宋文武 writes:
> This patch is for core-updates:
> From 15e28e84eaea8f68b6247ab53052f0dd50a544b2 Mon Sep 17 00:00:00 2001
> From: 宋文武
> Date: Thu, 22 Apr 2021 19:21:51 +0800
> Subject: [PATCH] gnu: cairo: Reintroduce security patches [security fixes].
>
> Two patches were accidentally removed
Mark H Weaver writes:
> 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.
>>
>>
* gnu/packages/glib.scm (glib)[source]: Add patch.
[arguments]: Remove custom 'increase-test-timeout phase.
* gnu/packages/patches/glib-skip-failing-test.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register it.
---
gnu/local.mk | 1 +
gnu/packages/glib.scm
* gnu/packages/compression.scm (zstd)[arguments]: Adjust
'fix-tests-32bit phase to work better on low RAM machines.
---
gnu/packages/compression.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Discussed on IRC, ready to go straight to core-updates.
diff --git
* gnu/packages/nss.scm (nss)[arguments]: Skip tests on powerpc-linux.
---
gnu/packages/nss.scm | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
Unchanged since last patchset, IMO not ready for upstreaming.
diff --git a/gnu/packages/nss.scm b/gnu/packages/nss.scm
index
* gnu/packages/version-control.scm (mercurial)[arguments]: Skip tests on
powerpc-linux.
---
gnu/packages/version-control.scm | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Unchanged since last patchset, IMO not ready for upstreaming.
diff --git a/gnu/packages/version-control.scm
* gnu/build/vm.scm (qemu-command): Add missing case for powerpc.
---
gnu/build/vm.scm | 1 +
1 file changed, 1 insertion(+)
Adjusted at the suggestion of Vincent Legoll to strongly match just
powerpc-linux and not powerpc64le.
diff --git a/gnu/build/vm.scm b/gnu/build/vm.scm
index
* gnu/packages/debug.scm (american-fuzzy-lop): Add case for
powerpc-linux.
(qemu-for-american-fuzzy-lop): Same.
---
gnu/packages/debug.scm | 2 ++
1 file changed, 2 insertions(+)
This patch is already in master and already merged into core-updates.
diff --git a/gnu/packages/debug.scm
* gnu/packages/disk.scm (mac-fdisk): New variable.
* gnu/packages/patches/mac-fdisk-gentoo-patchset.patch,
gnu/packages/patches/mac-fdisk-p18.patch: New files.
* gnu/local.mk (dist_patch_DATA): Register them.
---
gnu/local.mk |2 +
gnu/packages/disk.scm
* gnu/packages/gl.scm (mesa)[inputs]: Add llvm, glslang for powerpc.
[arguments]: Customize the configure flags for powerpc. Add powerpc
specific phase to skip failing tests.
---
gnu/packages/gl.scm | 33 +
1 file changed, 29 insertions(+), 4 deletions(-)
Blanket
* gnu/packages/base.scm (binutils)[source]: Add patch.
* gnu/packages/patches/binutils-libiberty-endianness-bug.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register it.
---
gnu/local.mk | 1 +
gnu/packages/base.scm | 3 +-
* gnu/packages/commencement.scm (gcc-boot0)[arguments]: Adjust
configure-flag to also use '--with-long-double-128' on powerpc-linux.
---
gnu/packages/commencement.scm | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
I ran into build troubles without this patch. It only affects
* gnu/packages/guile.scm (guile-3.0)[arguments]: On powerpc add two
phases to adjust for 32-bit big-endian systems.
---
gnu/packages/guile.scm | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
This patch has the comments updated. I reported my findings to the guile
debbugs
This looks to be about 2 weeks worth of time since the last email, with
about 10 days of continuous building and is based on commit
76fc36d0a7215979bb74c05840f5a4de4ab5ea93 which changes the default gcc
to 8. I'll inline my comments in the top of each of the patches.
Some of the patches are going
On 923bb70a1bff657125c3008f119a477e5cb57c2b
gnu:glibc-for-bootstrap: Fix patch.
Run
./pre-inst-env guix build --target=powerpc-linux-gnu bootstrap-tarballs
Producing
/gnu/store/dyj1wvayyp1ihaknkxniz1xamcf4yrhl-bootstrap-tarballs-0
With guix hash -rx
Luciana Lima Brito writes:
> 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
On Wed, Apr 21 2021, Maxim Cournoyer wrote:
>> One thing that I find a little annoying is that you have to specify a
>> default value for the fields. This doesn’t make much sense in some
>> cases, e.g. there is no good default value for ‘user.name = NAME’ in the
>> Git config, the user should
On Thu, Apr 22 2021, raingloom 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
>
46 matches
Mail list logo
