On 2024-04-26, Christina O'Donnell wrote:
> gnu/packages/patches/nss-Disable-library-signing.patch: Disable library
> signing to make the build reproducible.
> gnu/packages/nss.scm (nss): Apply this new patch.
Nice!
> diff --git a/gnu/packages/patches/nss-Disable-library-signing.patch
>
On 2024-03-13, Vagrant Cascadian wrote:
> It would be really nice, especially for downstream distributors, if
> there was a test for CVE-2024-27297.
>
> There is working code to test this in the excellent blog post on the
> subject, which is a likely good starting point!
It would be really nice, especially for downstream distributors, if
there was a test for CVE-2024-27297.
There is working code to test this in the excellent blog post on the
subject, which is a likely good starting point!
On 2023-07-20, Vagrant Cascadian wrote:
> On 2022-04-29, Ludovic Courtès wrote:
>> Vagrant Cascadian skribis:
>>
>>> Both guix-daemon.service and guix-publish.service make use of
>>> StandardError=syslog and StandardOutput=syslog.
>>
>> [...]
>>
retitle 40316 nss not reproducible
thanks
Still an issue on master as of d29e5a83e887cd2f4f459a12cbbfc40c77e55ce2:
guix challenge --verbose --diff=simple nss
guix challenge: warning: could not determine current substitute URLs; using
defaults
On 2020-12-03, Ludovic Courtès wrote:
> Mathieu Othacehe skribis:
>
>>> … but I don’t think we can assume that the checkout is in the
>>> ‘%load-path’ when this code is executed. WDYT, Mathieu?
>>
>> Cuirass happens to add checkouts to the %load-path just before loading
>> this file.
>
> Is that
Well, with a fairly recent guix:
Generation 78 Mar 07 2024 12:51:33(current)
guix d29e5a8
repository URL: /home/vagrant/src/guix
branch: master
commit: d29e5a83e887cd2f4f459a12cbbfc40c77e55ce2
gnucash 5.5 is now still not reproducible, but apparently for a possibly
different
On 2024-03-07, Vagrant Cascadian wrote:
> On 2024-02-20, Andrew Tropin wrote:
>> guix pull -C channels-lock.scm produces different profiles on different
>> machines.
>>
>> I executed the same command on a few different machines.
>> channels-lock.scm contain
On 2024-01-26, Maxim Cournoyer wrote:
> Maxim Cournoyer writes:
>> Building cuirass with 'guix build --no-grafts --check -K cuirass' shows
>> it has differences. Then running
>
> I think this is not particular to cuirass but more to any Guile package.
> I've found similar issues with guile-git
On 2024-02-20, Andrew Tropin wrote:
> guix pull -C channels-lock.scm produces different profiles on different
> machines.
>
> I executed the same command on a few different machines.
> channels-lock.scm contains channels list with exact commit specified.
>
> --8<---cut
On 2023-11-21, Christopher Howard wrote:
> Hi, recently I tried to use diffoscope to compare to PDFs. I got these errors:
>
> │┄ xxd not available in path. Falling back to Python hexlify.
> │┄ 'pdftotext' not available in path. Falling back to binary comparison.
>
> I found that if I installed
Several tests have started failing with builds of Guix in Debian:
https://bugs.debian.org/1064748
My suspicion is I need to rebuild one of guix's build dependencies, but
I am not sure which one. Maybe all of them... Debian doesn't quite have
the same nice feature of always rebuilding
On 2024-02-08, Leo Famulari wrote:
> On Thu, Feb 08, 2024 at 07:57:38AM +0100, Wilko Meyer wrote:
>> Vagrant Cascadian writes:
>> > The linux-libre 6.7.x package contains ... as far as I can tell, no
>> > supported arm64/aarch64 platforms! This is a pretty signi
On 2024-02-07, Vagrant Cascadian wrote:
> On 2023-06-24, Alan & Kim Zimmerman wrote:
>> I took a look at this, and the problem seems to be that the cwd ends up
>> different from before, so all the file operations fail.
>>
>> It needs (chdir "../nn
On 2023-06-24, Alan & Kim Zimmerman wrote:
> I took a look at this, and the problem seems to be that the cwd ends up
> different from before, so all the file operations fail.
>
> It needs (chdir "../nncp-7.5.0") in the 'go-unpack section.
>
> Attached is a patch that does this, if it works via
The linux-libre 6.7.x package contains ... as far as I can tell, no
supported arm64/aarch64 platforms! This is a pretty significant
regression from the linux-libre 6.6.x packaging!
This appears to have been introduced in
95a3aaf7ad37bb0717f2c9e3faf6f636b586d133
Unfortunately it is all too easy
On 2023-12-01, Vagrant Cascadian wrote:
> All 12 of the tests for python-sphinx-prompt fail:
>
> https://ci.guix.gnu.org/build/2678884/log/raw
>
> I tried updating python-sphinx-prompt to the newer 1.8.x version, which
> switched to pyproject and poetry, but may requi
X-Debbugs-Cc: Lars-Dominik Braun , jg...@dismail.de, Marius Bakke
, Munyoki Kilyungi
All 12 of the tests for python-sphinx-prompt fail:
https://ci.guix.gnu.org/build/2678884/log/raw
I tried updating python-sphinx-prompt to the newer 1.8.x version, which
switched to pyproject and poetry, but
On 2023-08-08, Ludovic Courtès wrote:
> Vagrant Cascadian skribis:
>> Oh, I noticed on reconfiguring back to a system without the patches to
>> support /run/privileged configurations ... the /run/privileged directory
>> is still present, with all those files sitting th
On 2023-08-06, Hilton Chain wrote:
> On Sat, 22 Jul 2023 04:24:17 +0800,
> Saku Laesvuori via Bug reports for GNU Guix wrote:
>>
>> [1 ]
>> > > I vote for TMPFS, since that would also reduce flash wear.
>> > > Honestly I don't get why it's not already using TMPFS.
>> >
>> > One argument could be
On 2023-07-21, Csepp wrote:
> Vagrant Cascadian writes:
>> While I know that Guix does not really follow the FHS in most respects,
>> maybe the intention of /run defined there should still be respected?
>>
>> https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.ht
So, if there are files sitting around in /run, they do not get cleaned
up unless it is something guix is already aware of
(e.g. /run/setuid-programs).
I noticed this when experimenting with:
https://issues.guix.gnu.org/61462
Add support for file capabilities(7)
Even after a reboot, the
On 2023-07-21, Ludovic Courtès wrote:
> Maxim Cournoyer skribis:
>
>> It appears that the Guix-Past channel now fails to build like so:
>>
>> substitute: ^Msubstitute: ESC[Kupdating substitutes from
>> 'https://ci.guix.gnu.org'... 0.0%^Msubstitute: ESC[Kupdating substitutes
>> from
On 2021-01-22, Vagrant Cascadian wrote:
> On 2021-01-18, Vagrant Cascadian wrote:
>> I don't have the system handy at the moment, but there is a recent build
>> log failure from staging:
>>
>> https://ci.guix.gnu.org/build/187255/log/raw
>>
>> It appe
On 2021-02-05, Leo Famulari wrote:
> On Fri, Feb 05, 2021 at 01:19:39PM -0800, Vagrant Cascadian wrote:
>> I get the following error when building mbedtls-apache on aarch64:
>>
>> /tmp/guix-build-mbedtls-apache-2.23.0.drv-0/source/programs/ssl/ssl_context_i
On 2022-04-29, Ludovic Courtès wrote:
> Vagrant Cascadian skribis:
>
>> Both guix-daemon.service and guix-publish.service make use of
>> StandardError=syslog and StandardOutput=syslog.
>
> [...]
>
>> So apparently need to switch the .service files to use
On 2023-03-06, Ludovic Courtès wrote:
> Vagrant Cascadian skribis:
>
>> On 2023-03-01, Josselin Poiret wrote:
>>> Vagrant Cascadian writes:
>
> [...]
>
>>> I can't find the installer dump on dump.guix.gnu.org unfortunately
>>> :(.
>>
>&g
On 2023-03-01, Josselin Poiret wrote:
> Vagrant Cascadian writes:
>> Tried the guix installer 1.4.0, and it seemed to be going smoothly,
>> downloading substitutes... but eventually timed out waiting for
>> substitutes...
>>
>> The "Resume" option f
Tried the guix installer 1.4.0, and it seemed to be going smoothly,
downloading substitutes... but eventually timed out waiting for
substitutes...
The "Resume" option for the install dropped me back to selecting locale,
keyboard, substitutes, root password, user, etc. without actually
seeming to
On 2022-05-27, Vagrant Cascadian wrote:
> On 2022-05-27, Vagrant Cascadian wrote:
>> I've been working on a package called lcsync:
>>
>> https://issues.guix.gnu.org/55682
>>
>> But lcsync needs CAP_NET_RAW... Normally, this is accomplished by
>> runnin
On 2022-11-03, zimoun wrote:
> On Wed, 02 Nov 2022 at 11:40, Vagrant Cascadian wrote:
>>> I do not know if “git clean -dfx” would help because here the error is
>>> probably between the repositories src/guix and src/guix-master and Guix
>>> manages them under 2
On 2022-11-02, zimoun wrote:
> On ven., 28 oct. 2022 at 13:23, Vagrant Cascadian wrote:
>
>>> Oh yeah, that reminds me to add to the confusion, "guix time-machine
>>> --commit=SOMECOMMIT" worked fine, even where "SOMECOMMIT" didn't
>>> successf
On 2022-10-26, Vagrant Cascadian wrote:
> On 2022-10-26, zimoun wrote:
>> On Wed, 26 Oct 2022 at 09:57, Vagrant Cascadian wrote:
>>
>>> It is consistently the same errors in the log, though on further looking
>>> i discovered a branch in ~/.cache/guix/checkout
On 2022-10-26, zimoun wrote:
> On Wed, 26 Oct 2022 at 09:57, Vagrant Cascadian wrote:
>
>> It is consistently the same errors in the log, though on further looking
>> i discovered a branch in ~/.cache/guix/checkouts/ that had old removed
>> files in it (including wicd
On 2022-10-26, zimoun wrote:
> On Tue, 25 Oct 2022 at 12:50, Vagrant Cascadian wrote:
>
>> originally stared for
>> me with guix successfully pulled to
>> bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f, and then trying to guix pull
>> to anything newer would trigge
On 2021-04-29, Ludovic Courtès wrote:
> Roel Janssen skribis:
>> On Wed, 2021-04-28 at 23:38 +0200, Ludovic Courtès wrote:
>>> Roel Janssen skribis:
>>>
>>> > /builder for
>>> > `/gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-
>>> > cache.drv'
>>> > failed to produce output path
>>> >
When I do:
guix build --rounds=2 PACKAGE
And the results differ, the process of actually running diffoscope on
the results is very manual and a bit hard to automate. I might get
output like:
guix build: error: derivation
`/gnu/store/dn50zya4d1zh21q6s3nh7f394s7ksknv-autogen-5.18.16.drv'
When I run a command such as:
guix challenge --verbose --diff=diffoscope gavl 2>&1 | tee gavl
It works for the most part, producing the diffoscope output, but ends
with a bunch of warnings regarding removing the temporary directory it
created to compare the files:
warning: failed to delete
On 2022-05-27, Vagrant Cascadian wrote:
> I've been working on a package called lcsync:
>
> https://issues.guix.gnu.org/55682
>
> But lcsync needs CAP_NET_RAW... Normally, this is accomplished by
> running:
>
> setcap cap_net_raw=eip /path/to/bin/lcsync
Similar iss
I've been working on a package called lcsync:
https://issues.guix.gnu.org/55682
But lcsync needs CAP_NET_RAW... Normally, this is accomplished by
running:
setcap cap_net_raw=eip /path/to/bin/lcsync
You could add lcsync to setuid-programs, but this would be a terrible
idea, as it's a file
On 2022-05-06, Vagrant Cascadian wrote:
> On 2022-05-06, Vagrant Cascadian wrote:
>> On 2022-05-06, Maxime Devos wrote:
>>> raingloom schreef op vr 06-05-2022 om 02:28 [+0200]:
>>>> > …)) In guix/cpu.scm:
>>>> > 94:2 0 (cpu->gcc-archit
On 2022-05-06, Vagrant Cascadian wrote:
> On 2022-05-06, Maxime Devos wrote:
>> raingloom schreef op vr 06-05-2022 om 02:28 [+0200]:
>>> > …)) In guix/cpu.scm:
>>> > 94:2 0 (cpu->gcc-architecture #f)
>>>
>>> This indicates the same to
On 2022-05-06, Maxime Devos wrote:
> raingloom schreef op vr 06-05-2022 om 02:28 [+0200]:
>> > …)) In guix/cpu.scm:
>> > 94:2 0 (cpu->gcc-architecture #f)
>>
>> This indicates the same to me.
>> But I don't know the internals of --tune well enough, so it's just a
>> hunch.
>
> Could anyone
On 2022-05-06, raingl...@riseup.net wrote:
> On Fri, 06 May 2022 00:50:21 +0200
> Ludovic Courtès wrote:
>
>> The log goes like this:
>> ...
>> + guix shell --export-manifest gsl openblas gcc-toolchain --tune
>
> This seems to be the important part, it looks like the CPU arch isn't
> being
On 2022-04-09, Vagrant Cascadian wrote:
> Ever since switching to a system generation using the new shepherd
> 0.9.0, whenever I'm reconfiguring my system over an ssh connection, the
> ssh connection drops out during the switch...
>
> I hadn't noticed this happening before using t
The fix for https://issues.guix.gnu.org/54812 seems to have caused some fallout:
eeb8ac43c8c0b0cc69422766070dbefc55f5c5c1 services: shepherd: Do not unload
transient services.
a2c759c8304c461d096ab763568e7f71546ff4e8 services: herd: Report whether a
service is transient.
These allow guix
Ever since switching to a system generation using the new shepherd
0.9.0, whenever I'm reconfiguring my system over an ssh connection, the
ssh connection drops out during the switch...
I hadn't noticed this happening before using the new shepherd.
Thankfully I always use tmux or screen and can
On 2022-03-17, Maxim Cournoyer wrote:
> Ludovic Courtès writes:
>> Vagrant Cascadian skribis:
>>> On 2021-05-02, Vagrant Cascadian wrote:
>>>> On 2021-05-02, Ludovic Courtès wrote:
>>>>> Guile 3.0’s compiler with ‘-O1’ (which is what we use for packag
In the CODE-OF-CONDUCT, I see the phrase:
Note: In the sequel, "project" refers to GNU Guix, and "project
maintainer(s)" refers to maintainer(s) of GNU Guix.
What does "the sequel" refer to?
Maybe something more like "Note: In this document, ..." ?
Maybe the intended meaning is lost in
On 2022-01-29, Leo Famulari wrote:
> The build farm is having trouble building Guix for i686-linux. In fact,
> it hasn't successfully completed the 'guix' job in weeks:
>
> https://issues.guix.gnu.org/53463
>
> And building the guix package does not work on aarch64, also for weeks:
>
>
On 2022-01-17, Vagrant Cascadian wrote:
> On 2022-01-17, Pierre Langlois wrote:
>> Chris Marusich writes:
>>> Chris Marusich writes:
>
>>>> If nobody has further comments, I will commit the attached version to
>>>> mas
On 2022-01-17, Pierre Langlois wrote:
> Chris Marusich writes:
>> Chris Marusich writes:
>>> If nobody has further comments, I will commit the attached version to
>>> master in about 24 hours.
>>
>> I've committed this in 24c3485bb3ffc05e687ef6513ac287b8d3048bab. We
>> still need to update the
On 2021-10-29, Ludovic Courtès wrote:
> Vagrant Cascadian skribis:
>
>> Most things seem to work fine, but noticed an oddity with guix shell:
>>
>> vagrant@vagranttdgxbookworm:~$ guix shell --pure --check --development guix
>> guix git less
>>
>> guix
This is a recently installed Debian bookworm system, initially using the
package from debian experimental (guix 1.3.0-3, built with guile 3.0),
and "guix pull" up to a recent guix master:
vagrant@vagranttdgxbookworm:~$ guix describe
Generation 7Oct 28 2021 11:04:25(current)
guix 0e6470b
On 2021-10-24, Vagrant Cascadian wrote:
> On 2021-10-24, zimoun wrote:
>> On Sun, 24 Oct 2021 at 04:22, Vagrant Cascadian wrote:
>>> "This packages", "This modules", "allows to" and "permits to" in package
>>> descriptio
On 2021-10-24, zimoun wrote:
> On Sun, 24 Oct 2021 at 04:22, Vagrant Cascadian wrote:
>> From a171769da0f737468e06866164eadf1e720764ba Mon Sep 17 00:00:00 2001
>> From: Vagrant Cascadian
>> Date: Sun, 24 Oct 2021 04:00:15 -0700
>> Subject: [PATCH] lint: Add descrip
On 2021-10-22, zimoun wrote:
> On Thu, 21 Oct 2021 at 16:18, Vagrant Cascadian wrote:
>
>> It has been rewritten to easily add new typo checks, but this one so far
>> only addresses pluralized "This packages". Would be easy enough to add
>> "allows to"
On 2021-10-21, Vagrant Cascadian wrote:
> For the last couple years guix has been applying simple workarounds in
> u-boot packages to disable the features that required openssl due to
> GPL/openssl license incompatibilities.
>
> I made an attempt at updating guix to u-boot 2021.
On 2021-10-22, Leo Famulari wrote:
> On Thu, Oct 21, 2021 at 11:17:03PM -0700, Vagrant Cascadian wrote:
>> While openssl 3.0 is licensed compatibly with GPLv3, u-boot has portions
>> which are GPLv2-only, so that's not as attractive of a way forward as
>> one might hope for.
On 2019-03-08, Ludovic Courtès wrote:
> Vagrant Cascadian skribis:
>> I'm not sure where it would be appropriate to add more comments
>> regarding the GPL/Openssl incompatibilities; e.g. if someone were to
>> propose adding one of the u-boot targets that requires it, they m
On 2021-06-09, Vagrant Cascadian wrote:
> There have been at least three newly added "This packages" since I
> submitted this patch, so wondering if we can at least get the simple
> case merged before getting too caught up in all the potential
> improvements?
And up until
On 2021-08-01, Vagrant Cascadian wrote:
> Turning this conversation into a bug, original thread around here:
>
> https://lists.gnu.org/archive/html/guix-devel/2021-05/threads.html#00427
For reference:
bug#49810: source tarballs potentially built for each derivation
live well,
Turning this conversation into a bug, original thread around here:
https://lists.gnu.org/archive/html/guix-devel/2021-05/threads.html#00427
On 2021-05-29, Vagrant Cascadian wrote:
> On 2021-05-01, Leo Famulari wrote:
>> On Sat, May 01, 2021 at 06:45:32PM -0700, Vagrant Cascad
packages/bootloaders.scm
> +++ b/gnu/packages/bootloaders.scm
> @@ -12,7 +12,7 @@
> ;;; Copyright © 2019 Mathieu Othacehe
> ;;; Copyright © 2020 Björn Höfling
> ;;; Copyright © 2018, 2019, 2020 Vagrant Cascadian
> -;;; Copyright © 2020 Pierre Langlois
> +;;; Copyright
On 2021-05-04, Ludovic Courtès wrote:
> Vagrant Cascadian skribis:
>
>> From 4e724fbe9815e1c27967b835f08d2259164538ba Mon Sep 17 00:00:00 2001
>> From: Vagrant Cascadian
>> Date: Wed, 21 Apr 2021 09:26:45 -0700
>> Subject: [PATCH] lint: Add description chec
On 2021-05-02, Vagrant Cascadian wrote:
> Unfortunately, guix doesn't currently support booting off of a separate
> /boot partition, since the kernel and initrd are in /gnu/store; your
> bootloader needs to be able to mount the partition that /gnu/store is
> located on.
>
> Th
When building guix on Debian's buildd infrastructure, some of the test
suites fail when building on machines that only have IPv6:
https://buildd.debian.org/status/logs.php?pkg=guix=amd64
In this case, the machine "x86-conova-01" is the only one that
fails to build, and one of the main
On 2021-05-11, Ludovic Courtès wrote:
> Vagrant Cascadian skribis:
>
>> Initially, I tried adding just the obviously mmc related modules, but
>> this gave me guile prompt from the initramfs as it failed to find the
>> rootfs. Notably, even with the above list,
I tried building a pinebook-pro image on an aarch64-linux Guix System...
$ uname -a
Linux myhostname 5.12.2-gnu #1 SMP 1 aarch64 GNU/Linux
$ guix system image ./gnu/system/images/pinebook-pro.scm
substitute: updating substitutes from
'http://mycachingproxy/ci'... 100.0%
The following derivations
Both guix-daemon.service and guix-publish.service make use of
StandardError=syslog and StandardOutput=syslog.
When building a guix 1.2.0 or 1.3.0rc* on Debian, I get the following
warnings when checking with lintian:
W: guix: systemd-service-file-uses-deprecated-syslog-facility
There should be an option to support dynamic loading of modules from the
initrd.
I recently pushed some changes to use the "linux-libre" kernel with
pinebook pro:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=d330d63a29f35ebcbebce19b13d49c69d38a5815
But in order to even boot, I need
On 2021-05-04, Ludovic Courtès wrote:
> Vagrant Cascadian skribis:
>
>> On 2021-01-22, Vagrant Cascadian wrote:
>>> I've uploaded guix 1.2.0 built against guile-2.2 to Debian, and while it
>>> builds fine on the official buildd.debian.org infrastructure, on amd64
&
On 2021-05-02, Vagrant Cascadian wrote:
> On 2021-05-02, Ludovic Courtès wrote:
>> Vagrant Cascadian skribis:
>>> On 2021-04-30, Vagrant Cascadian wrote:
>>>> I've been unable to build version 1.3.0rc1 for i386 on Debian:
>>>>
>>>> [ 70
On 2021-05-02, Ludovic Courtès wrote:
> Vagrant Cascadian skribis:
>
>> On 2021-04-30, Vagrant Cascadian wrote:
>>> I've been unable to build version 1.3.0rc1 for i386 on Debian:
>>>
>>> [ 70%] GUILEC gnu/packages/direct-connect.go
>>> [ 70%
On 2021-01-22, Vagrant Cascadian wrote:
> I've uploaded guix 1.2.0 built against guile-2.2 to Debian, and while it
> builds fine on the official buildd.debian.org infrastructure, on amd64
> and arm64 the "channel-news, one entry" test from tests/channels.scm
> fails
On 2021-04-30, Vagrant Cascadian wrote:
> I've been unable to build version 1.3.0rc1 for i386 on Debian:
>
> [ 70%] GUILEC gnu/packages/direct-connect.go
> [ 70%] GUILEC gnu/packages/disk.go
> GC Warning: Failed to expand heap by 8388608 bytes
> GC Warning: Fai
I've been unable to build version 1.3.0rc1 for i386 on Debian:
[ 70%] GUILEC gnu/packages/direct-connect.go
[ 70%] GUILEC gnu/packages/disk.go
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 8388608 bytes
...
GC Warning: Failed to expand
On 2021-04-26, Vagrant Cascadian wrote:
> On 2021-04-26, Vagrant Cascadian wrote:
>> The attached patch enables support for LCD display and limited audio
>> support for pinebook-pro-rk3399.
>
> Updated patch which adds battery support too.
Fixed in linux-libre@5.11 and lin
On 2021-04-28, Ludovic Courtès wrote:
> Vagrant Cascadian skribis:
>
>> When building guix (with commit cb3f9696f6251ad382febad33290fed929c176b4
>> from branch version-1.3.0) on Debian, it fails with the following error
>> with guile-library (a.k.a. guile-lib) version
On 2021-04-26, Vagrant Cascadian wrote:
> The attached patch enables support for LCD display and limited audio
> support for pinebook-pro-rk3399.
Updated patch which adds battery support too.
live well,
vagrant
From 4c2a728e1186367a4bdc5c4416d6d58eee13b0e7 Mon Sep 17 00:00:00 200
Control: reassign 48050 guix-patches
Reassigning to guix-patches.
Unless this debbugs is all old-school and I have to send to instead
cont...@debbugs.gnu.org ... will know shortly!
live well,
vagrant
signature.asc
Description: PGP signature
478b620eb4f52e76bde691262ebc793e4e3fd384 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Mon, 26 Apr 2021 09:27:50 -0700
Subject: [PATCH] gnu: linux-libre: Add LCD and sound support for Pinebook Pro.
* gnu/packages/linux.scm (linux-libre-5.11-source): Add Pinebook Pro
lcd patch.
(linux-libre-arm64-generic): Enable
On 2021-04-25, Efraim Flashner wrote:
> On Wed, Apr 21, 2021 at 04:10:40PM -0700, Vagrant Cascadian wrote:
>> Control: tags 44675 +patch
>>
>> On 2020-11-15, Vagrant Cascadian wrote:
>> > Please consider a guix lint description/synopsis check for basic
>> >
When building guix (with commit cb3f9696f6251ad382febad33290fed929c176b4
from branch version-1.3.0) on Debian, it fails with the following error
with guile-library (a.k.a. guile-lib) version 0.2.6.1-2:
ice-9/eval.scm:293:34: error: %strict-tokenizer?: unbound variable
hint: Did you forget a
or: This Packages --> This packages
> Also, quotes: "description contains ‘This packages’ but should just be ‘This
> package’".
Again, nice catch!
Updated the commit message and incorporated the above suggestions into
the updated attached patch.
live well,
vagrant
From 4e724fb
Control: tags 44675 +patch
On 2020-11-15, Vagrant Cascadian wrote:
> Please consider a guix lint description/synopsis check for basic
> spelling, typo and rudimentary grammar issues.
...
> Many of these are likely to be caught by most spell checking routines;
> I'm not sure if there
I get the following error when building mbedtls-apache on aarch64:
/tmp/guix-build-mbedtls-apache-2.23.0.drv-0/source/programs/ssl/ssl_context_info.c:
In function ‘read_next_b64_code’:
/tmp/guix-build-mbedtls-apache-2.23.0.drv-0/source/programs/ssl/ssl_context_info.c:384:16:
error: comparison is
ugh I haven't managed to find
which tests failed in the build output at a cursory glance...
Will try to get a failed build log locally when I get a chance to more
easily debug and review...
live well,
vagrant
> Le 17 janvier 2021 15:56:34 GMT-05:00, Vagrant Cascadian
> a écrit :
>
php 7.4.14 fails to build on aarch64 due to test suite failures.
Reverting back to php 7.4.13 by reverting commit
d033540e6c113323089403a26e39f9a288c9c857 works fine for me, though
obviously it would be better to track down the exact test suite failure
and figure out a proper fix.
This blocks
On 2020-12-07, zimoun wrote:
> On Mon, 07 Dec 2020 at 18:13, Pierre Neidhardt wrote:
>
>>> Can you try, as root on Guix System:
>>>
>>> $ echo 1 > /proc/sys/kernel/unprivileged_userns_clone
>>
>> # echo 1 > /proc/sys/kernel/unprivileged_userns_clone
>> -bash:
On 2020-12-03, Ludovic Courtès wrote:
> Should we close this issue now that you found the RES_OPTIONS=attempts:0
> trick, or do you think we should still keep the refactoring bits?
Well, it's three cases of copy-paste code, and one nearly identical but
inverted. Someone once suggested to me to
On 2020-11-27, Ludovic Courtès wrote:
> Vagrant Cascadian skribis:
>> On 2020-11-26, Ludovic Courtès wrote:
>>> In particular, Guile-Git 0.4.0 has this thing compile-time check to make
>>> sure it matches the ABI of the underlying libgit2 version (0.28 or 1.0):
>&g
On 2020-11-26, Ludovic Courtès wrote:
> Vagrant Cascadian skribis:
>
>> Updating the build dependency to libgit2-dev >= 1.0.1 (which pulls in a
>> similar version to what guix is using) fixes test suite failures ... but
>> only on the amd64 architecture. The sam
Fun With More Debian packaging test suite failures...
Updating the build dependency to libgit2-dev >= 1.0.1 (which pulls in a
similar version to what guix is using) fixes test suite failures ... but
only on the amd64 architecture. The same tests pass Using an older
version of libgit2-dev (0.28).
I'm exploring building with guile 2.2 because guile-gnutls built with
guile 3.0 is only available in experimental, and even there, missing for
arm64.
FAIL: tests/swh.scm - lookup-origin
And then hangs indefinitely. I've seen it run for hours at a time. Works
fine with guile 3.0.
In
I'm exploring building with guile 2.2 because guile-gnutls built with
guile 3.0 is only available in experimental, and even there, missing for
arm64.
From tests/lint.log:
test-name: archival: missing content
location: /build/guix-EdK9LP/guix-1.2.0~rc2/tests/lint.scm:921
source:
+ (test-assert
+
On 2020-11-16, Ludovic Courtès wrote:
> Vagrant Cascadian skribis:
>
>> When building from a build path containing a "~", such as:
>>
>> /build/guix-1WL3Dl/guix-1.2.0~rc1/
>>
>> tests/build-utils.scm and tests/guix-system.sh bot
Please consider a guix lint description/synopsis check for basic
spelling, typo and rudimentary grammar issues.
Most of the ones I've found were caught by debian's "lintian" tool:
https://tracker.debian.org/lintian
Common issues appear to be:
"This packages" -> "This package"
"allows to
When building from a build path containing a "~", such as:
/build/guix-1WL3Dl/guix-1.2.0~rc1/
tests/build-utils.scm and tests/guix-system.sh both fail.
I've observed this with v1.2.0rc1, as well as
c6e8f40f2ce6082171c18b4aad9877b0ad022563.
Building in such a directory revealed two failing
On 2020-11-10, Vagrant Cascadian wrote:
> On 2020-11-10, Ludovic Courtès wrote:
>> Vagrant Cascadian skribis:
>>> On 2020-11-08, Ludovic Courtès wrote:
>>>> Vagrant Cascadian skribis:
>>>>
>>>>> If this could be considered for the upcomi
1 - 100 of 160 matches
Mail list logo
