On Thu, 2021-03-25 at 21:23 -0400, Mark H Weaver wrote:
>
> Just a reminder that, just as with 'mysql/fixed', 'sqlite/fixed'
> should
> *not* use 'package/inherit', since the package you're defining is the
> replacement for the package you're inheriting from.
>
> Otherwise, it looks good to me!
>
Léo Le Bouter via Bug reports for GNU Guix writes:
> From b0f9566e9ff9a5f409a3fd4293c048ec58bc770d Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?L=C3=A9o=20Le=20Bouter?=
> Date: Thu, 18 Mar 2021 07:09:10 +0100
> Subject: [PATCH] gnu: sqlite: Update to 3.32.3 [security fixes].
>
> * gnu/packages/sql
On Thu, 2021-03-25 at 21:16 -0400, Mark H Weaver wrote:
>
> Looks good to me. Please push. Thank you!
>
> Mark
Thank you for the review, pushed as
52c8d07a4f7033534a71ac7efeec21a65d35c125.
signature.asc
Description: This is a digitally signed message part
Léo Le Bouter via Bug reports for GNU Guix writes:
> v3 tested and builds fine:
>
> $ ./pre-inst-env guix build mariadb
> /gnu/store/f70jymwyfcnsghy4jg8caibci59p8rgq-mariadb-10.5.8-dev
> /gnu/store/cj3qym1x1jjh02m2g23cqpbhchrbmn6c-mariadb-10.5.8-lib
> /gnu/store/mpb5bdf1vkwazqfmmwcvskdm50g191bg-m
$ ./pre-inst-env guix refresh exiv2
gnu/packages/image.scm:1343:2: warning: 'generic-html' updater failed
to determine available releases for exiv2
It seems applying this patch does not help either:
diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm
index d04a247976..8ede48eea5 100644
-
pdfarranger builds without trouble, but is unable to start due to an
API problem:
christopher@theoden ~$ pdfarranger
Traceback (most recent call last):
File "/gnu/store/ppvjh7rfqfql9lpw8pnrqfzdqcs62cf0-pdfarranger-
1.7.1/bin/.pdfarranger-real", line 11, in
load_entry_point('pdfarranger==1.
On Thu, Mar 25, 2021 at 04:16:20PM -0800, Christopher Howard wrote:
> I think it would be fine to close this old bug-report now that the hurd
> image configuration is part of master. I just built a qcow2 today from
> gnu/systems/images/hurd and didn't have any trouble.
Great!
Anyone can close it
I think it would be fine to close this old bug-report now that the hurd
image configuration is part of master. I just built a qcow2 today from
gnu/systems/images/hurd and didn't have any trouble.
Christopher
This persists. System commit from about 1-2 weeks ago. (built from
private branch, so commit name wouldn't mean much)
Not sure how to investigate, because last time I tried looking into
GVFS issues it turned out to be a huge mess.
On Fri, 2021-03-26 at 00:24 +0100, Ludovic Courtès wrote:
> Léo Le Bouter skribis:
>
> > Full log: https://ci.guix.gnu.org/build/117996/log/raw
>
> Speaking of which: please always build packages before pushing. :-)
>
> Thanks,
> Ludo’.
I ran 'guix pull' but turns out that wasnt sufficient.
Hi,
Luis Felipe skribis:
> $ guix lint -c archival icecat
> Backtrace:cecat@78.8.0-guix0-preview1 [archival]...
> 12 (primitive-load "/home/yo/.config/guix/current/bin/guix")
> In guix/ui.scm:
> 2164:12 11 (run-guix-command _ . _)
> In ice-9/boot-9.scm:
> 1736:10 10 (with-exception
Léo Le Bouter skribis:
> Full log: https://ci.guix.gnu.org/build/117996/log/raw
Speaking of which: please always build packages before pushing. :-)
Thanks,
Ludo’.
Hi!
Instead of renaming ‘url-fetch*’, I changed the thing that guesses the
procedure name so that it preferable uses the procedure’s public name,
rather than the name it has within its module. Done in
96aa98b6ca78ffb798e309acac3c3e5068422f30.
Thanks, and apologies for the breakage!
Ludo’.
Ludo experienced the same issue. I fixed it with
ac29d37e2ffd7a85adfcac9be4d5bce018289bec and updated the Cuirass
package
accordingly.
Mathieu
Awesome, thank you!
// David
On Thu, Mar 25, 2021 at 05:21:40PM +0100, Niels Möller wrote:
> Changes to gostdsa and ed448 will not apply, since those curves didn't
> exist in nettle-3.5. Changes to ed25519 might not apply cleanly, due to
> refactoring when adding ed448.
Okay.
> > I’m asking because in Guix, the easiest way f
Hello David,
> Thanks. I forked ur test-channel and updated my specs accordingly and it only
> works the first evaluation, until I push a new commit to the config channel,
> then Im getting this:
Ludo experienced the same issue. I fixed it with
ac29d37e2ffd7a85adfcac9be4d5bce018289bec and updat
Looking through my old bug reports: I think this is probably just
upstream code issues, not a distro-specific issue, and this bug could
be closed as WONTFIX.
Christopher
Ludovic Courtès writes:
> Are there plans to make a new 3.5 release including these fixes?
No, I don't plan any 3.5.x release.
> Alternatively, could you provide guidance as to which commits should be
> cherry-picked in 3.5 for downstream distros?
Look at the branch release-3.7-fixes
(https://
On 2021-03-25 14:47, Mathieu Othacehe wrote:
Hello David,
(build '(manifests . ((my-config . "manifests/user1.scm"
I have changed the manifest argument format recently. This should now
be:
--8<---cut here---start->8---
(build '(manifests "manif
Tobias Geerinckx-Rice via Bug reports for GNU Guix writes:
I'm currently rebuilding IceCat with this change as an extra
precaution, but that shouldn't take long. If that doesn't cause
problems this LGTM for master.
OK, it worked, old IceCat writes new SQlite files.
Kind regards,
T G-R
Also note that you can now use this specification:
--8<---cut here---start->8---
(list
(specification
(namee "my-pkgs")
(build '(channels my-guix-packages))
(channels
(list %default-guix-channel
(channel
(name 'my-guix-packages)
Hello Clément,
It is possible to search for the last build of a given job using the Web
interface search form.
For example,
http://ci.guix.gnu.org/search?query=spec%3Aguix-master+gajim
which corresponds to the search "spec:guix-master gajim", will show the
last build job for gajim on master. A
Hello,
Invalid specifications are now reported, see for example:
--8<---cut here---start->8---
(list (specification
(namee "guix-master")
(build 'hello)))
--8<---cut here---end--->8---
gives,
--8<---
Hello,
> Invalid specifications produce an unhelpful error message, they should
> be validated.
>
> See https://lists.gnu.org/archive/html/help-guix/2018-08/msg00063.html.
The specifications are now Guix records, which means that the syntax
error are now reported:
--8<---cut here--
Hello,
As the specification format is completely new and the evaluation process
has been rewritten, I think we can close this one.
Thanks,
Mathieu
Hello David,
> (build '(manifests . ((my-config . "manifests/user1.scm"
I have changed the manifest argument format recently. This should now
be:
--8<---cut here---start->8---
(build '(manifests "manifests/user"))
--8<---cut here-
Hello,
The Builds table now has as "system" field on Cuirass master. The job
system is displayed on http://ci.guix.gnu.org/eval/xxx page. With
1ed93601089e774df849bc4ffab718bb1f142d34 it is also possible to sort by
table columns, including the "System" column.
Closing this one,
Thanks,
Mathie
Hello,
This should no longer be an issue with the new remote building mechanism
in Cuirass.
Thanks,
Mathieu
Hello,
> The 'core-updates' and 'staging' branches shouldn't trigger evaluations
> at each commit, because they produce too many derivations. Instead, the
> admins should have a 'trigger evaluation' button that they use once in a
> while. That button should be part of an 'admin interface', whi
Hello,
The tests are now evaluated periodically (every 24 hours) which largely
mitigates this issue. Closing this one.
Mathieu
Hello,
This is no longer an issue on Cuirass master.
Thanks,
Mathieu
Hello,
Cuirass now honors those properties, closing this one.
Thanks,
Mathieu
Hello,
> Previously, we've noticed that this problem happens quite frequently
> with armhf builds offloaded to hydra-slave{1,2,3}, which are hosted far
> from Berlin. The examples above show that this problem also happens
> with build slaves that are local to Berlin.
The Cuirass log mechanism
Hello,
Closing as this is fixed on Cuirass master.
Thanks,
Mathieu
Hello,
Closing this one as the specification/evaluation model in Cuirass has
been rewritten.
Thanks,
Mathieu
Hello,
Closing as Cuirass evaluation process now uses less memory.
Thanks,
Mathieu
Hello,
> Some times it's correct, 11 seconds:
> http://ci.guix.gnu.org/build/1024003/details
This is now fixed with 158dd2bd42c8b2ffbde07d5878d24ec26a7dadd4.
Thanks,
Mathieu
v3 tested and builds fine:
$ ./pre-inst-env guix build mariadb
/gnu/store/f70jymwyfcnsghy4jg8caibci59p8rgq-mariadb-10.5.8-dev
/gnu/store/cj3qym1x1jjh02m2g23cqpbhchrbmn6c-mariadb-10.5.8-lib
/gnu/store/mpb5bdf1vkwazqfmmwcvskdm50g191bg-mariadb-10.5.8
Since we don't have PoC, I can't verify the rebas
Closing as this is not any issue anymore since the switch to PostgreSQL.
Mathieu
Hello Jonathan,
This is fixed with 0be2474d42990871170578e3a14a2e6b548157bd.
Thanks,
Mathieu
* gnu/packages/patches/mariadb-CVE-2021-27928.patch: New patch.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/databases.scm (mariadb/fixed): New variable. Apply patch.
(mariadb)[replacement]: Graft.
---
gnu/local.mk | 1 +
gnu/packages/databases.s
On Fri, 2021-03-19 at 12:35 +0100, zimoun wrote:
> Instead of grafting, I would fix first check the compatibility
> between
> mariadb and zstd. Because mariadb@10.5.8 does not build with
> zstd@1.4.9, at least on my machine.
Can you post build logs and repro scenario? mariadb@10.5.8 built fine
f
Thanks!
I'm currently rebuilding IceCat with this change as an extra
precaution, but that shouldn't take long. If that doesn't cause
problems this LGTM for master.
Ludo', do you think the Guix test described here is a good one?
Kind regards,
T G-R
I think you can simplify the patch a bit by inheriting the source too:
(source
(origin
(inherit (package-source mariadb))
(patches …)))
Otherwise, untested but looks good.
* gnu/packages/patches/mariadb-CVE-2021-27928.patch: New patch.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/databases.scm (mariadb/fixed): New variable. Apply patch.
(mariadb)[replacement]: Graft.
---
gnu/local.mk | 1 +
gnu/packages/databases.s
On Thu, Mar 25, 2021 at 11:16:25AM +0100, Maxime Devos wrote:
> On Thu, 2021-03-25 at 12:04 +0200, Efraim Flashner wrote:
> > [...]
> > I'm also running on btrfs
> > (ins)scheme@(guile-user)> (statfs "/")
> > [...]
> >
> > (ins)efraim@3900XT ~$ btrfs filesystem df /
> > Data, single: total=289.00G
On Thu, 2021-03-25 at 12:04 +0200, Efraim Flashner wrote:
> [...]
> I'm also running on btrfs
> (ins)scheme@(guile-user)> (statfs "/")
> [...]
>
> (ins)efraim@3900XT ~$ btrfs filesystem df /
> Data, single: total=289.00GiB, used=287.83GiB
> System, single: total=32.00MiB, used=48.00KiB
> Metadata,
On Thu, Mar 25, 2021 at 09:49:08AM +0100, Maxime Devos wrote:
> Hi Guix,
>
> Version:
> guix (GNU Guix) 1155a88308df7649fe74bd5bb8279a4d103ce386
>
> The following test fails:
>
> (start snip)
> test-name: statfs
> location: $HOME/guix/git/guix/tests/syscalls.scm:123
> source:
> + (test-assert
>
Hi Niels,
> I've prepared a new bug-fix release of Nettle, a low-level
> cryptographics library, to fix a serious bug in the function to verify
> ECDSA signatures. Implications include an assertion failure, which could
> be used for denial-of-service, when verifying signatures on the
> secp_224r1
Hi Guix,
Version:
guix (GNU Guix) 1155a88308df7649fe74bd5bb8279a4d103ce386
The following test fails:
(start snip)
test-name: statfs
location: $HOME/guix/git/guix/tests/syscalls.scm:123
source:
+ (test-assert
+ "statfs"
+ (let ((fs (statfs "/")))
+ (and (file-system? fs)
+ (> (fi
Oops I messed up the commit message in the patch.
Revised patch is attached.
From 2c6c28334173fff9112c36726d31d6adcebfbf2d Mon Sep 17 00:00:00 2001
From: Maxime Devos
Date: Thu, 25 Mar 2021 08:48:24 +0100
Subject: [PATCH] guix: Let the procedure name of "url-fetch*" be what "guix
import" expects.
On Wed, 2021-03-24 at 20:59 -0700, Chris Marusich wrote:
> [..]
>
> In guix/import/print.scm, package->code generates the code by invoking
> (origin-method source) to get the origin's "method", and then invoking
> (procedure-name method) on the method thus obtained. It seems that
> procedure-name
52 matches
Mail list logo
