bug#55326: libgit2 1.3.0 includes a time-dependent test
I opened a pull request upstream that just removes the specific test for
“HEAD@{10 years ago}". Since that functionality is well-covered by subsequent
tests.
See here for the PR: https://github.com/libgit2/libgit2/pull/6299
<https://github.com/libgit2/libgit2/pull/6299>
> Though maybe by that time, we have complete time namespaces …
One would hope!
Cheers,
Carl Dong
> On May 9, 2022, at 3:25 AM, Maxime Devos wrote:
>
> Ludovic Courtès schreef op ma 09-05-2022 om 00:11 [+0200]:
>> Fixed:
>>
>> e48b5484afde93294c4ed7215e88ed450842b2e5 (master)
>> f5fe0082abe4547f3fb9f29d8351473cfb3a387b (staging)
>
> It's still time-dependent though:
>
>> + (substitute* "tests/refs/revparse.c"
>> +(("10 years ago")
>> + "100 years ago"))
>
> wouldn't it now fail after ~100 or ~1000 years?
> Though maybe by that time, we have complete time namespaces ...
>
> Greetings,
> Maxime.
signature.asc
Description: Message signed with OpenPGP
bug#53426: mingw-w64-{x86_64, i686}-winpthreads broken after absorption of binutils-next
I did some more exploration, and found that not only are the mingw-w64-{x86_64,
i686}-winpthreads packages broken, but any --target=x86_64-w64-mingw32 package:
$ guix build --target=x86_64-w64-mingw32 hello
I have this patch which resolves the problem by simply disabling compressed
debug sections, but perhaps it’d also be worthwhile to investigate the root
cause...
--8<---cut here---start->8---
diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index 78cbf871ac..397e4d4c1c 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -101,7 +101,8 @@ (define* (cross-binutils target #:optional (binutils
binutils))
"ath9k-htc-firmware-binutils.patch")))
((target-mingw? target)
(package-with-extra-patches
- binutils
+ (package-with-extra-configure-variable
+binutils "--enable-compressed-debug-sections" "no")
(search-patches "binutils-mingw-w64-timestamp.patch"
"binutils-mingw-w64-deterministic.patch")))
(else binutils))
--8<---cut here---end--->8---
Cheers,
Carl Dong
> On Jan 21, 2022, at 5:10 PM, Maxime Devos wrote:
>
> Carl Dong schreef op vr 21-01-2022 om 16:30 [-0500]:
>> I’m wondering what the best course of action is to fix the mingw-w64-
>> {x86_64,i686}-winpthreads packages (e.g. just remove the configure
>> flag for mingw-w64? Add that flag only for linux? Or something else?)
>> and would love some help.
>
> I would assume that it works for Linux, it also works for the Hurd,
> so I would prefer something like
>
> #$@(if (target-mingw?) '() '("--some-configuration..."))
>
> above
>
> #$@(if (target-linux?) '("--some-configuration...") '())
>
> Greetings,
> Maxime.
>
signature.asc
Description: Message signed with OpenPGP
bug#53426: mingw-w64-{x86_64, i686}-winpthreads broken after absorption of binutils-next
Hi all,
The mingw-w64-{x86_64,i686}-winpthreads have been broken since the absorption
of binutils-next in ce362bc1f35102e7d79ad7e0d638d20cef304f01. My very crude
debugging (adding and removing configure flags from the binutils in
gnu/packages/base.scm until the packages compiled) led me to the culprit:
"--enable-compressed-debug-sections=all”.
I’m wondering what the best course of action is to fix the
mingw-w64-{x86_64,i686}-winpthreads packages (e.g. just remove the configure
flag for mingw-w64? Add that flag only for linux? Or something else?) and would
love some help.
Cheers,
Carl Dong
bug#34170: bitcoin-core bundles leveldb
> If desired, it would also be possible to do something in-between > unbundling and using bitcoin's leveldb: define a 'leveldb/bitcoin' > variant of the 'leveldb' package (using package/inherit or (package > (inherit ...) ...)), add it as input to the 'bitcoin' package and tell > and/or patch bitcoin's buid scripts to use that leveldb. Yes I think that would be a splendid idea! With regards to patching bitcoin’s builds scripts, Bitcoin Knots follows Bitcoin Core closely, but has a bunch of patches which allow for using system libs, so that might be good to reference: https://github.com/bitcoin/bitcoin/compare/master...bitcoinknots:21.x-syslibs <https://github.com/bitcoin/bitcoin/compare/master...bitcoinknots:21.x-syslibs> > As source code, use an appropriate commit from > <https://github.com/bitcoin-core/leveldb-subtree> (and add a comment > to the definition of bitcoin-core to keep leveldb/bitcoin in-sync). FYI, according to https://github.com/bitcoin/bitcoin/pull/17398 <https://github.com/bitcoin/bitcoin/pull/17398>, we are currently using the upstream LevelDB commit 0c40829872a9f00f38e11dc370ff8adb3e19f25b Cheers, Carl Dong > On Jan 5, 2022, at 2:13 PM, Maxime Devos wrote: > > Hi, > > Carl Dong schreef op wo 05-01-2022 om 12:40 [-0500]: >> Simon, Maxime, Danny, >> >> Thanks for CCing me on this message! The rationale for bundling >> leveldb in Bitcoin Core goes a bit beyond convenience, it is several >> things: >> >> 1. The original reason for sub-treeing is that Bitcoin Core used to >> maintain its own version of leveldb with its own fixes >> here: https://github.com/bitcoin-core/leveldb-subtree, since then >> most of these fixes have been upstreamed as >> of: https://github.com/bitcoin/bitcoin/pull/17398 > > Seems reasonable to me, but the bitcoin project is upstreaming the > changes it made and most are already upstream, so I would prefer > to use upstream's leveldb. > >> 2. We also used to support using an external leveldb, however, it >> seems that it was fragile to rely on external projects to maintain >> ABI compatibility, see the quoted IRC bug report >> here: https://github.com/bitcoin/bitcoin/pull/23282. Reasonable minds >> may disagree on this point, especially coming from Guix where >> patching is convenient. > > The quoted ABI incompatibility > > bitcoind fails to start with undefined symbol: > _ZTIN7leveldb6LoggerE in Debian Sid after leveldb upgraded from 1.22 to > 1.23: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996486 > > doesn't apply in Guix, because guix uses RUNPATH and multiple library > versions can exist in the same store (in different directories in the > store). > >> In addition to the above, Bitcoin Core experienced a hard fork in >> 2013 due to database incompatibilities, which has predisposed >> maintainers towards a more stringent approach with pinning >> dependencies and their configure/build-time flags. >> See: https://blog.bitmex.com/bitcoins-consensus-forks/#was-the-2013- >> incident-a-hardfork > > I doubt that Guix has sufficient Bitcoin Core users to cause > a hard fork, but yes, this is an understandable reason to bundle > things. But any such problem seems easy to resolve (at the guix side): > we could simply temporarily switch to an older version of leveldb. > > If desired, it would also be possible to do something in-between > unbundling and using bitcoin's leveldb: define a 'leveldb/bitcoin' > variant of the 'leveldb' package (using package/inherit or (package > (inherit ...) ...)), add it as input to the 'bitcoin' package and tell > and/or patch bitcoin's buid scripts to use that leveldb. > > As source code, use an appropriate commit from > <https://github.com/bitcoin-core/leveldb-subtree> (and add a comment > to the definition of bitcoin-core to keep leveldb/bitcoin in-sync). > > A benefit of this approach (if done properly, with (origin (inherit > ...) ...) such that patches of 'leveldb' are inherited) above the > status quo, is that is that if for some reason 'leveldb' is patched in > Guix, then 'leveldb/bitcoin' receives the patch as well. Another > benefit is that the dependency 'googletest' and 'benchmark' of leveldb > would remain unbundled. > > Greetings, > Maxime. > signature.asc Description: Message signed with OpenPGP
bug#34170: bitcoin-core bundles leveldb
Simon, Maxime, Danny, Thanks for CCing me on this message! The rationale for bundling leveldb in Bitcoin Core goes a bit beyond convenience, it is several things: 1. The original reason for sub-treeing is that Bitcoin Core used to maintain its own version of leveldb with its own fixes here: https://github.com/bitcoin-core/leveldb-subtree <https://github.com/bitcoin-core/leveldb-subtree>, since then most of these fixes have been upstreamed as of: https://github.com/bitcoin/bitcoin/pull/17398 <https://github.com/bitcoin/bitcoin/pull/17398> 2. We also used to support using an external leveldb, however, it seems that it was fragile to rely on external projects to maintain ABI compatibility, see the quoted IRC bug report here: https://github.com/bitcoin/bitcoin/pull/23282 <https://github.com/bitcoin/bitcoin/pull/23282>. Reasonable minds may disagree on this point, especially coming from Guix where patching is convenient. In addition to the above, Bitcoin Core experienced a hard fork in 2013 due to database incompatibilities, which has predisposed maintainers towards a more stringent approach with pinning dependencies and their configure/build-time flags. See: https://blog.bitmex.com/bitcoins-consensus-forks/#was-the-2013-incident-a-hardfork <https://blog.bitmex.com/bitcoins-consensus-forks/#was-the-2013-incident-a-hardfork> Let me know if I can provide more context! Cheers, Carl Dong > On Jan 5, 2022, at 4:45 AM, zimoun wrote: > > Hi Maxime, > > On Wed, 05 Jan 2022 at 10:39, Maxime Devos wrote: > >>> The package bitcore-core still provides ’leveldb’: >>> >>> [...] >>> >>> and I am not sure to get what is the issue. Some explanations? >> >> The issue is that bitcoin-core bundles leveldb (which you have shown >> is still the case), even though leveldb is packaged in Guix. > > Thanks, I missed that ’leveldb’ is packaged in Guix. Indeed, it should > preferably be used. > > So reopen. :-) > > > Cheers, > simon
bug#52694: time-machine error when leaping from version-1.2.0 to version-1.4.0
Hi all,
A fellow Bitcoin developer has submitted a patch bumping our time-machine to a
commit on the version-1.4.0 branch for testing. While testing that change, a
few developers encountered a bug in the time-machine script.
I’ve been able to distill it down to a reproducible form:
$ guix time-machine --branch=version-1.2.0 -- time-machine
--commit=6dffced09ecda024e0884e352778c221ad066fd6 -- describe
The specific error that you get:
--8<---cut here---start->8---
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Backtrace:
In guix/store.scm:
2042:24 19 (run-with-store # ?)
In guix/inferior.scm:
734:8 18 (_ _)
In guix/channels.scm:
876:2 17 (_ _)
836:2 16 (_ _)
In ./guix/monads.scm:
482:9 15 (_ _)
In guix/store.scm:
1876:8 14 (_ _)
In guix/channels.scm:
604:36 13 (_ #)
657:11 12 (_)
In ice-9/eval.scm:
196:35 11 (_ #(#(#) "/gnu?" ?))
173:47 10 (_ #(#(#(#) # ?) ?))
213:37 9 (_ #(#(#(#) # ?) ?))
159:9 8 (_ #(#(#(#) # ?) ?))
159:9 7 (_ #(#(#(#) # ?) ?))
159:9 6 (_ #(#(#(#) # ?) ?))
In guix/modules.scm:
157:28 5 (module-closure _ #:select? _ #:dependencies _)
In guix/memoization.scm:
100:0 4 (_ # "/gnu/store/i88h59?" ?)
In ice-9/ports.scm:
445:17 3 (call-with-input-file _ _ #:binary _ #:encoding _ # _)
In guix/modules.scm:
69:4 2 (_ _)
In ice-9/boot-9.scm:
1669:16 1 (raise-exception _ #:continuable? _)
1669:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1669:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern"
(#:re-export-and-replace (delete) #:replace ((define-public* . define-public))
#:export (content-hash content-hash? content-hash-algorithm content-hash-value
origin origin? this-origin origin-uri origin-method origin-hash origin-sha256
origin-file-name origin-actual-file-name origin-patches origin-patch-flags
origin-patch-inputs origin-patch-guile origin-snippet origin-modules base32
base64 package package? this-package package-name package-upstream-name
package-version package-full-name package-source package-build-system
package-arguments package-inputs package-native-inputs
package-propagated-inputs package-outputs package-native-search-paths
package-search-paths package-replacement package-synopsis package-description
package-license package-home-page package-supported-systems package-properties
package-location package-definition-location hidden-package hidden-package?
package-superseded deprecated-package package-field-location this-package-input
this-package-native-input lookup-package-input lookup-package-native-input
lookup-package-propagated-input lookup-package-direct-input prepend replace
modify-inputs package-direct-sources package-transitive-sources
package-direct-inputs package-transitive-inputs
package-transitive-target-inputs package-transitive-native-inputs
package-transitive-propagated-inputs package-transitive-native-search-paths
package-transitive-supported-systems package-mapping package-input-rewriting
package-input-rewriting/spec package-source-derivation package-derivation
package-cross-derivation package-output package-grafts
package-patched-vulnerabilities package-with-patches package-with-extra-patches
package-with-c-toolchain package/inherit transitive-input-references
%supported-systems %hurd-systems %cuirass-supported-systems supported-package?
package-error? package-error-package
package-input-error? package-error-invalid-input
package-cross-build-system-error?
package->bag bag->derivation bag-direct-inputs bag-transitive-inputs
bag-transitive-host-inputs bag-transitive-build-inputs
bag-transitive-target-inputs package-development-inputs package-closure
default-guile default-guile-derivation set-guile-for-build package-file
package->derivation package->cross-derivation origin->derivation)))'.
--8<---cut here---end--->8---
Let me know if there’s any other information I can provide or if this is a dupe!
Cheers,
Carl Dong
bug#50203: binutils-mesboot0: configure: sed: command not found
Hi all, After resolving bug#49985, a new build failure has stumped a community member of mine. When building /gnu/store/8kap9kj0ayhaqd4ay7n9lgpbcwankxrq-binutils-mesboot0-2.14.drv, the build fails and the logs are as follows: https://paste.sr.ht/~dongcarl/7fe559b338dfa9aa3cf3464dbdab8109487c9783#8kap9kj0ayhaqd4ay7n9lgpbcwankxrq-binutils-mesboot0-2.14.log-L5504 We’ve tried the normal suspects: --cores=1, reboots, mounting tmpfs at /tmp, etc. What’s also fascinating is that, when I inspect his keep-failed directory: https://nextcloud.carl.homeserver.net/s/ZHmAbz3LwyPwcfL We found that: 1. The $PATH in the environment-variables file contained /gnu/store/2z4y0n547x7d566281isklk9ls2d8c9q-sed-mesboot0-1.18/bin, which in turn contained a working sed: --8<---cut here---start->8--- Usage: /gnu/store/2z4y0n547x7d566281isklk9ls2d8c9q-sed-mesboot0-1.18/bin/sed [-nV] [--quiet] [--silent] [--version] [-e script] [-f script-file] [--expression=script] [--file=script-file] [file…] --8<---cut here---end--->8--- 2. The configure’s shebang (/gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b/bin/sh) exists on his system and works This problem has also been encountered in the past: https://logs.guix.gnu.org/guix/2021-04-03.log#210314 As always, I’m happy to spend energy investigating, but would love any pointers on what the most promising place to look is! Cheers, Carl Dong cont...@carldong.me "I fight for the users"
bug#49985: bash-mesboot0: Inscrutable error in build phase
Mathieu, I think this was exactly the problem, because mounting a tmpfs at /tmp solved it. Thanks for your help! Cheers, Carl Dong > On Aug 19, 2021, at 12:20 PM, Mathieu Othacehe wrote: > > > Hello Carl, > >> The error line is L1299: "make: stat:Makefile: sterror: unknown error” > > This reminds me of: > https://lists.gnu.org/archive/html/bug-guix/2020-05/msg00335.html. > > I never took the time to fix this issue. Bottom line is that building > the bootstrap toolchain fails on NVME disks because some syscalls > (stat64, lstat64 and fstat64) need to be implemented in GNU Mes. > > There's a small demonstration program that you can use to demonstrate > this theory :). > > Thanks, > > Mathieu
bug#49985: bash-mesboot0: Inscrutable error in build phase
No worries! We’re all learning :-)
I ended up asking my colleague to use:
strace --env=MES_DEBUG=1
We’ll see what happens!
> On Aug 11, 2021, at 8:53 AM, Bengt Richter wrote:
>
> Just this disclaimer:
> I am just a lurker interested in mes, not a mes developer or team member.
> (I am trying to do some minimal stuff too, so I cloned the mes repo and pull
> once
> in a while to see what's going on :)
>
> Sorry for any implication that I really know anything about mes ;/
>
> On +2021-08-11 03:21:18 +0200, Bengt Richter wrote:
>> On +2021-08-11 02:38:54 +0200, Bengt Richter wrote:
>>> On +2021-08-10 15:41:25 -0400, Carl Dong wrote:
>>>> Hi all,
>>>>
>>>> While setting up Guix for a community member of mine, we encountered this
>>>> somewhat inscrutable problem (I later learned this is not the first time
>>>> Guix users have run into this problem!). When building
>>>> /gnu/store/2nvaxgs0rdxfkrwklh622ggaxg0wap6n-bash-mesboot0-2.05b.drv, we
>>>> encountered the following build failure:
>>>> https://paste.sr.ht/~dongcarl/376b19b8349c329ed5329508c7fb43a7c3aec64b#2nvaxgs0rdxfkrwklh622ggaxg0wap6n-bash-mesboot0-2.05b.log-L1299
>>>>
>>>> The error line is L1299: "make: stat:Makefile: sterror: unknown error”
>>>> --
>>>
>>> To me, sterror looks like a typo for strerror
>>> so grepping for sterror might find the typo, if that's what it is?
>>>
>> Looking at ./lib/mes/__mes_debug.c, it looks like you could set/export
>> environment
>> MES_DEBUG=1 and run it again to see the error number ./lib/string/strerror.c
>> (in git repo) doesn't like.
>>
>> Then run something like my error-printing kludge that will work on your
>> system:
>>
>> I called it errno-grep
>> --8<---cut here---start->8---
>> #!/usr/bin/bash
>> if [ -z "$1" ];then
>>echo "Usage: errno-grep [ grep switches for grepping the following files
>> in order ]"
>>echo "/usr/include/asm-generic/errno-base.h"
>>echo "/usr/include/asm-generic/errno.h"
>>exit 0
>> fi
>>
>> if [ "${1:0:1}" == "-" ]; then
>>exec grep "$@" /usr/include/asm-generic/errno-base.h
>> /usr/include/asm-generic/errno.h
>> else
>>exec egrep -wh "$@" /usr/include/asm-generic/errno-base.h
>> /usr/include/asm-generic/errno.h
>> fi
>> --8<---cut here---end--->8---
>>
>> HTH.
>>
>>
>>
>
> --
> Regards,
> Bengt Richter
bug#49985: bash-mesboot0: Inscrutable error in build phase
Hi all, While setting up Guix for a community member of mine, we encountered this somewhat inscrutable problem (I later learned this is not the first time Guix users have run into this problem!). When building /gnu/store/2nvaxgs0rdxfkrwklh622ggaxg0wap6n-bash-mesboot0-2.05b.drv, we encountered the following build failure: https://paste.sr.ht/~dongcarl/376b19b8349c329ed5329508c7fb43a7c3aec64b#2nvaxgs0rdxfkrwklh622ggaxg0wap6n-bash-mesboot0-2.05b.log-L1299 The error line is L1299: "make: stat:Makefile: sterror: unknown error” This failure persists even when ran with --cores=1, across reboots. I’ve even tried building that derivation with --check on my own machine (which successfully built that derivation), and every log line matched (plus or minus some timing log lines) up until L1299. We’ve also tried rebuilding bash-mesboot0-2.05b.drv’s dependency /gnu/store/2nvaxgs0rdxfkrwklh622ggaxg0wap6n-bash-mesboot0-2.05b.drv with: --8<---cut here---start->8--- guix gc --delete /gnu/store/prkqai3zwh3shlqpll6xyncmmqpj49dd-gash-boot-0.2.0 guix build --cores=1 /gnu/store/2nvaxgs0rdxfkrwklh622ggaxg0wap6n-bash-mesboot0-2.05b.drv --8<---cut here---end--->8--- Which did not make a difference. What is interesting is that this is not the first time this problem has cropped up for people. I see 2 past mentions of this exact error: - Mentioned by kagevf on Dec 16th, 2020: https://logs.guix.gnu.org/guix/2020-12-16.log#043712 - Mentioned by genr8_ (with help from rekado_) on Mar 22nd, 2021: https://logs.guix.gnu.org/guix/2021-03-22.log#182406 I’m happy to spend energy investigating, but would love any pointers on what the most promising place to look is! My friend's system is an Intel i5 system, running Guix 1.3.0 on Ubuntu. His /tmp is on the same partition as / and is ext4. Cheers, Carl Dong cont...@carldong.me "I fight for the users"
bug#48389: Guile 3.0.7 test suite fails non-deterministically
Hi all, I’m also encountering this exact error when time-machining from 0961807915d7955e70a081272d857b6cbf92c0c8 to 83d9e2ee56cb0ca2a644074ad232503e25ac7116 I’m able to reproduce this (I’ve tried building the derivation 5 times now with different --cores, and this error happens every time) Build logs here: https://nextcloud.carl.homeserver.net/s/yas2SwmST8Z3jRG Keep-failed directory here: https://nextcloud.carl.homeserver.net/s/sSrjPZn5NqikeoJ My system: - AMD Ryzen Threadripper 2970WX 24-Core Processor - Guix on Arch Linux - tmpfs mounted on /tmp Cheers, Carl Dong cont...@carldong.me "I fight for the users"
bug#47935: coreutils: tests/tail-2/inotify-dir-recreate.sh fails on overlayfs
Upstream bug filed: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47940
bug#47935: coreutils: tests/tail-2/inotify-dir-recreate.sh fails on overlayfs
Hi all, I’m continuing my testing of the 1.3.0 branch, and I’ve found that coreutil's tests/tail-2/inotify-dir-recreate.sh fails on filesystems where tail detects that it cannot use inotify safely (probably arising out of this check: https://github.com/coreutils/coreutils/blob/34a48bf0f0552aaed21a7dba4a5488946a978317/src/tail.c#L2486-L2491). Example for this: overlayfs used by docker/podman/etc. The author of tail’s inotify support explains it here: https://github.com/containers/podman/issues/5493#issuecomment-598851397 A quick and easy fix for v1.3.0 may be to just disable tests/tail-2/inotify-dir-recreate.sh :-) Cheers, Carl Dong cont...@carldong.me "I fight for the users"
bug#47924: v1.3.0: Missing configure check for guile-lib >= 0.27
Hi all, Testing out the version-1.3.0 branch right now, and I think perhaps it’s missing a configure-time check for guile-lib >= 0.27 for %strict-tokenizer? Cheers, Carl Dong cont...@carldong.me "I fight for the users"
bug#44559:
Hi Guix! Thanks to all of you for your thoughtful replies! On Feb 19, 2021, at 10:33 AM, Ludovic Courtès wrote: > I agree it’s a problem, and yes, it would probably be a good idea to > release 1.2.1 with the upgraded GnuTLS we now have in ‘master’. I’m very heartened by your affirmation of the project’s support of bootstrappability and building from source. :-) In addition, I think it would be good to make sure that the package transformation options are powerful enough to allow users to sidestep these problems in their own workflow and decrease the pressure on maintainers. On Feb 19, 2021, at 10:33 AM, Ludovic Courtès wrote: > ‘--without-tests’ should work, but you need to pass the right version > number I guess? Oh! That may be the case. I am using `guix time-machine` however, and that does not yet have the `--without-tests` flag, I have opened bug#46650 so that we can discuss that issue there. On Feb 19, 2021, at 1:32 PM, Maxime Devos wrote: > Alternatively, could the build container be adjusted to always begin at > 1970-01-01, using ‘time namespaces’? Unfortunately, as Ludovic mentioned earlier in this thread, time_namespaces(7) is only for CLOCK_MONOTONIC and. CLOCK_BOOTTIME. :-( Carl Dong cont...@carldong.me "I fight for the users" > On Feb 19, 2021, at 10:33 AM, Ludovic Courtès wrote: > > Hi Carl, > > Carl Dong skribis: > >> As bitcoin core begins the planning to officially transition to Guix-based >> releases, I've had many community members build guix v1.2.0 from source and >> afterward attempt `--bootstrap --no-substitutes` builds. As you may imagine, >> they are getting stuck on this gnutls problem and cannot proceed further. > > Yeah. :-/ > >> I'm wondering: >> >> 1. Is there a workaround that does not involve changing the system time? We >> have attempted several flags: >> 1. --with-graft=gnutls=gnutls@3.6.14 >> 2. --without-tests=gnutls >> 3. --with-input=gnutls=gnutls@3.6.14 >> These attempts all failed to work around this bug, and I’m curious as >> to why that would be. My guess would be that when we do `--bootstrap`, Guix >> bootstraps itself first without taking into account these flags? > > ‘--without-tests’ should work, but you need to pass the right version > number I guess? > >> 2. Since bootstrappability is one of the core tenets of Guix, might it be >> appropriate to cut a v1.2.1 release with this problem (and any other >> potential bootstrap problems) fixed? (Happy to discuss in separate thread if >> more appropriate) > > I agree it’s a problem, and yes, it would probably be a good idea to > release 1.2.1 with the upgraded GnuTLS we now have in ‘master’. > > Longer-term, we need to find a way to address or avoid this issue. A > brute-force approach would be to have the build machines at ci.guix run > with a clock ten years ahead. That should generally be fine since the > only place where timestamps matter are unmodified upstream tarballs. In > all other cases, mtime is set to 1. > > Perhaps we could start by testing this hypothesis on a separate build > farm. Chris, Mathieu, WDYT? > > Thanks, > Ludo’.
bug#46650: Extending package transformation options
Hi Guix! TL;DR Shall we add a `--without-tests` option (or something similar) for `guix time-machine`? Our release workflow in Bitcoin is planned to shift over to Guix for the next release, and as such we have a lot more testers who are running Guix as we speak on their machines! Exciting! Our build workflow basically boils down to something like: --8<---cut here---start->8--- $ guix time-machine --commit= … \ -- environment --manifest=manifest.scm … \ -- --8<---cut here---end--->8--- The fact that this is even possible (and allows reproducibility across time) speaks to the awesomeness of Guix! :-) One of the main reasons for switching over to Guix is for its bootstrappbility and the ability to perform `--bootstrap --no-substitutes` builds. As mentioned in the gnutls ticket, performing these source-based builds can sometimes reveal problems with tests suites: 1. Spurious tests 2. “Expiring” tests (like the gnutls one) 3. Foreign distro problems (0zmcam9sdiag9s1qx3xvlf8a3jnm53x2-sed-4.8.drv fails to build on SELinux-based distros because of a test failure in testsuite/inplace-selinux) I think that the package transformation options are the perfect “hack-around” solution for this, namely `--without-tests`. In fact, since those who experience these problems are building from source, it makes no difference that the store item would be change: they would need to build everything anyway! However, in the case of our workflow above, there is no way to specify `--without-tests=` to `guix time-machine`, which insists on building the broken `gnutls` package and running its tests. I’ve tried isolating the command to just: --8<---cut here---start->8--- $ guix time-machine --commit= … \ -- --help --8<---cut here---end--->8— To make sure that it’s `guix time-machine` which is trying to build gnutls and not the time-machine’d `guix environment`. I’m not too familiar with how package transformation options work internally, but I’m guessing all we need here is a `--without-tests` option (or something similar) for `guix time-machine`? Is there anything else that’s necessary to successfully skip tests for my workflow? Cheers, Carl Dong cont...@carldong.me "I fight for the users"
bug#44559:
Hi all, As bitcoin core begins the planning to officially transition to Guix-based releases, I've had many community members build guix v1.2.0 from source and afterward attempt `--bootstrap --no-substitutes` builds. As you may imagine, they are getting stuck on this gnutls problem and cannot proceed further. I'm wondering: 1. Is there a workaround that does not involve changing the system time? We have attempted several flags: 1. --with-graft=gnutls=gnutls@3.6.14 2. --without-tests=gnutls 3. --with-input=gnutls=gnutls@3.6.14 These attempts all failed to work around this bug, and I’m curious as to why that would be. My guess would be that when we do `--bootstrap`, Guix bootstraps itself first without taking into account these flags? 2. Since bootstrappability is one of the core tenets of Guix, might it be appropriate to cut a v1.2.1 release with this problem (and any other potential bootstrap problems) fixed? (Happy to discuss in separate thread if more appropriate) Cheers, Carl Dong cont...@carldong.me "I fight for the users"
bug#45165: binutils-mesboot0 fails at configure, cannot find lex
New observation! On my Arch machine which has
5.10.11-arch1-1
And
# CONFIG_EXPERT is not set
CONFIG_UID16=y
(So according to my previous email it not trigger the bug)
I’m getting the following strace:
$ strace -v -e trace=file ~/sh -c "test -w /home/dongcarl/.bash_profile”
execve() = 0
[ Process PID=404360 runs in 32 bit mode. ]
open("/dev/tty", O_RDWR)= 3
stat("/home/dongcarl", 0xffdcd738) = -1 EOVERFLOW (Value too large for
defined data type)
getcwd("/home/dongcarl", 1024) = 15
stat("/home/dongcarl/.bash_profile", 0xffdcd6bc) = -1 EOVERFLOW (Value too
large for defined data type)
+++ exited with 1 +++
Not sure hot to interpret this...
bug#45165: binutils-mesboot0 fails at configure, cannot find lex
Regardless of how Kconfig options interact with each other, it seems that this bug is only triggered when the effective kernel config (/proc/config.gz) contains the following: CONFIG_EXPERT=y # CONFIG_UID16 is not set Cheers, Carl Dong
bug#45165: binutils-mesboot0 fails at configure, cannot find lex
Hi all, I was able to bisect this down to a few kernel configuration options, so perhaps those with more kernel experience can help me track down what’s going on. The two Kconfig options which seem to influence the behavior are: 1. CONFIG_EXPERT 2. CONFIG_UID16 CONFIG_EXPERT=y, CONFIG_UID16=y -> status code = 0 CONFIG_EXPERT=y, CONFIG_UID16=n -> status code = 1 CONFIG_EXPERT=y, CONFIG_UID16 not set -> status code = 1 CONFIG_EXPERT=n, any CONFIG_UID16 -> status code = 0 This is somewhat perplexing to me, as looking at the entry for CONFIG_UID16, I see that the default value is “y”, so I would expect there not to be a difference between CONFIG_UID16=y and CONFIG_UID16 not being set when CONFIG_EXPERT=y. This configuration option investigation originated from when I bisected across Arch Linux’s kernel configuration and found that this recent commit fixed our problem: https://github.com/archlinux/svntogit-packages/commit/1b26b3445354ccdb92b4361e772fb9f246143d0b#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a Note that this above config has CONFIG_HAVE_UID16=y and CONFIG_MULTIUSER=y Let me know how best to approach this! Cheers, Carl Dong
bug#45165: binutils-mesboot0 fails at configure, cannot find lex
More clues:
I ran the following one-liner:
for i in $(seq 0 65535); do sudo chown $i:$i
/tmp/guix-build-binutils-mesboot0-2.14.drv-0/binutils-2.14/config.cache &&
/gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b/bin/sh -c "test
-w /tmp/guix-build-binutils-mesboot0-2.14.drv-0/binutils-2.14/config.cache" &&
echo "Winner: $i" && break; done
This is designed to iterate through all possible uid values, chown the
config.cache file, and test if that uid makes the “test” builtin think that it
is writable. If there is one, it’ll print “Winner: ” and exit
The result: Nothing was printed and the exit status was 1
Not sure where to go from here.
Cheers,
Carl Dong
> On Dec 15, 2020, at 7:46 PM, Carl Dong wrote:
>
> Hi all,
>
> I think I have a new lead!
>
> Here’s what I did:
> 1. cd /tmp/guix-build-binutils-mesboot0-2.14.drv-0/binutils-2.14
> 2. env -i bash --rcfile environment-variables
> 3. Ran the configure command from the log, just to check:
> ./configure --disable-nls --disable-shared --disable-werror
> --build=i386-unknown-linux --host=i386-unknown-linux
> --target=i386-unknown-linux --with-sysroot=/
> --prefix=/gnu/store/jfa9b78rdniyw7qilsmw3bh02x8x68ly-binutils-mesboot0-2.14
>
> Indeed it did still output "not updating unwritable cache ./config.cache”
>
> However, when I tried `test -w config.cache`, there was no status code…
>
> This led me to look at ./configure’s shebang, which is:
> /gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b/bin/sh
>
> Then I did:
> /gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b/bin/sh
> -c "test -w config.cache”
>
> Which _did_ exit with status=1 !
>
> So I believe that this is a problem with the “test” builtin in
> /gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b
>
> So I ran:
> env -i bash --rcfile environment-variables -c 'strace -v -e trace=file
> /gnu/store/m89p469fxwn4hj7an9givd1ry 9vk7j2l-bash-mesboot0-2.05b/bin/sh -c
> "test -w config.cache”'
>
> And the output:
> execve("/gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b/bin/sh",
> ["/gnu/store/m89p469fxwn4hj7an9giv"..., "-c", "test -w config.cache"],
> ["PWD=/tmp/guix-build-binutils-mes"..., "SHLVL=0", "_=/usr/bin/strace"]) = 0
> [ Process PID=2049037 runs in 32 bit mode. ]
> open("/dev/tty", O_RDWR)= 3
> stat("/tmp/guix-build-binutils-mesboot0-2.14.drv-0", {st_dev=makedev(0,
> 0x2f), st_ino=2546749, st_mode=S_IFDIR|0755, st_nlink=3, st_uid=1000,
> st_gid=1000, st_blksize=4096, st_blocks=0, st_size=80, st_atime=1608079054 /*
> 2020-12-15T19:37:34.095396729-0500 */, st_atime_nsec=95396729,
> st_mtime=1607635957 /* 2020-12-10T16:32:37.842047431-0500 */,
> st_mtime_nsec=842047431, st_ctime=1607636165 /*
> 2020-12-10T16:36:05.793930344-0500 */, st_ctime_nsec=793930344}) = 0
> stat(".", {st_dev=makedev(0, 0x2f), st_ino=2546749, st_mode=S_IFDIR|0755,
> st_nlink=3, st_uid=1000, st_gid=1000, st_blksize=4096, st_blocks=0,
> st_size=80, st_atime=1608079054 /* 2020-12-15T19:37:34.095396729-0500 */,
> st_atime_nsec=95396729, st_mtime=1607635957 /*
> 2020-12-10T16:32:37.842047431-0500 */, st_mtime_nsec=842047431,
> st_ctime=1607636165 /* 2020-12-10T16:36:05.793930344-0500 */,
> st_ctime_nsec=793930344}) = 0
> stat("config.cache", 0xfff9affc)= -1 ENOENT (No such file or
> directory)
> +++ exited with 1 +++
>
> I had a hunch that the mode is most likely the problem. So I tried the
> following:
>
> chmod 664 config.cache -> status is still 1
> chmod 646 config.cache -> status is now 0!!
>
> So somehow the “test” builtin for my bash-mesboot0 doesn’t think that it has
> owner or group permissions to write to a file that itself created?
>
> Let me know what you guys think could be the case!
>
> Cheers,
> Carl Dong
>
>
bug#45165: binutils-mesboot0 fails at configure, cannot find lex
Hi all,
I think I have a new lead!
Here’s what I did:
1. cd /tmp/guix-build-binutils-mesboot0-2.14.drv-0/binutils-2.14
2. env -i bash --rcfile environment-variables
3. Ran the configure command from the log, just to check:
./configure --disable-nls --disable-shared --disable-werror
--build=i386-unknown-linux --host=i386-unknown-linux
--target=i386-unknown-linux --with-sysroot=/
--prefix=/gnu/store/jfa9b78rdniyw7qilsmw3bh02x8x68ly-binutils-mesboot0-2.14
Indeed it did still output "not updating unwritable cache ./config.cache”
However, when I tried `test -w config.cache`, there was no status code…
This led me to look at ./configure’s shebang, which is:
/gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b/bin/sh
Then I did:
/gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b/bin/sh
-c "test -w config.cache”
Which _did_ exit with status=1 !
So I believe that this is a problem with the “test” builtin in
/gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b
So I ran:
env -i bash --rcfile environment-variables -c 'strace -v -e trace=file
/gnu/store/m89p469fxwn4hj7an9givd1ry 9vk7j2l-bash-mesboot0-2.05b/bin/sh -c
"test -w config.cache”'
And the output:
execve("/gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b/bin/sh",
["/gnu/store/m89p469fxwn4hj7an9giv"..., "-c", "test -w config.cache"],
["PWD=/tmp/guix-build-binutils-mes"..., "SHLVL=0", "_=/usr/bin/strace"]) = 0
[ Process PID=2049037 runs in 32 bit mode. ]
open("/dev/tty", O_RDWR)= 3
stat("/tmp/guix-build-binutils-mesboot0-2.14.drv-0", {st_dev=makedev(0, 0x2f),
st_ino=2546749, st_mode=S_IFDIR|0755, st_nlink=3, st_uid=1000, st_gid=1000,
st_blksize=4096, st_blocks=0, st_size=80, st_atime=1608079054 /*
2020-12-15T19:37:34.095396729-0500 */, st_atime_nsec=95396729,
st_mtime=1607635957 /* 2020-12-10T16:32:37.842047431-0500 */,
st_mtime_nsec=842047431, st_ctime=1607636165 /*
2020-12-10T16:36:05.793930344-0500 */, st_ctime_nsec=793930344}) = 0
stat(".", {st_dev=makedev(0, 0x2f), st_ino=2546749, st_mode=S_IFDIR|0755,
st_nlink=3, st_uid=1000, st_gid=1000, st_blksize=4096, st_blocks=0, st_size=80,
st_atime=1608079054 /* 2020-12-15T19:37:34.095396729-0500 */,
st_atime_nsec=95396729, st_mtime=1607635957 /*
2020-12-10T16:32:37.842047431-0500 */, st_mtime_nsec=842047431,
st_ctime=1607636165 /* 2020-12-10T16:36:05.793930344-0500 */,
st_ctime_nsec=793930344}) = 0
stat("config.cache", 0xfff9affc)= -1 ENOENT (No such file or directory)
+++ exited with 1 +++
I had a hunch that the mode is most likely the problem. So I tried the
following:
chmod 664 config.cache -> status is still 1
chmod 646 config.cache -> status is now 0!!
So somehow the “test” builtin for my bash-mesboot0 doesn’t think that it has
owner or group permissions to write to a file that itself created?
Let me know what you guys think could be the case!
Cheers,
Carl Dong
bug#45165: binutils-mesboot0 fails at configure, cannot find lex
Hi all, Let me know if there’s anything at all I can do here to help debug :-) Cheers, Carl Dong
bug#45165: binutils-mesboot0 fails at configure, cannot find lex
Hi Janneke! Oh, that’s a very good find! I have no idea why config.cache is not writable… This is most strange! I checked that my mountpoints have enough free space… Not sure what else to check? Looking at `guix describe`, I’m on bf8dfe3df025e4ac80cccb87497b4f072ba10e2a Cheers, Carl Dong > On Dec 11, 2020, at 1:33 AM, Jan Nieuwenhuizen wrote: > > Carl Dong writes: > > Hello! > >> Some more information from my debugging: >> >> 1. This error is reproducible even when I specify --cores=1, which is very >> strange >> 2. I have attached the full log to this email > > Diffing this with the build log from > > --8<---cut here---start->8--- > guix build -e '(@@ (gnu packages commencement) binutils-mesboot0)' --log-file > wget > https://ci.guix.gnu.org/log/jfa9b78rdniyw7qilsmw3bh02x8x68ly-binutils-mesboot0-2.14 > -O jfa9b78rdniyw7qilsmw3bh02x8x68ly-binutils-mesboot0-2.14.gz > gunzip jfa9b78rdniyw7qilsmw3bh02x8x68ly-binutils-mesboot0-2.14.gz > diff -u jfa9b78rdniyw7qilsmw3bh02x8x68ly-binutils-mesboot0-2.14 > 2020-10-10-binutils-mesboot0.log > [..] > > @@ -5538,16 +5537,16 @@ > checking for i386-unknown-linux-windres... no > checking for windres... windres > checking whether to enable maintainer-specific portions of Makefiles... no > -updating cache ./config.cache > +not updating unwritable cache ./config.cache > creating ./config.status > creating Makefile > [..] > @@ -5558,7 +5557,7 @@ > checking whether the C compiler (tcc -D __GLIBC_MINOR__=6 -g ) works... yes > checking whether the C compiler (tcc -D __GLIBC_MINOR__=6 -g ) is a > cross-compiler... no > checking whether we are using GNU C... no > -checking for ranlib... (cached) true > +checking for ranlib... true > checking for POSIXized ISC... no > checking for ANSI C header files... yes > checking for working const... yes > --8<---cut here---end--->8--- > > config values do not get cached (why is config.cache > unwritable?)...which seems to lead to a misdectected presence of lex: > > --8<---cut here---start->8--- > -@ build-succeeded > /gnu/store/bz6xjpzlwf57m4bg3w5ihlq638sscx54-binutils-mesboot0-2.14.drv - > -checking for flex... (cached) > /tmp/guix-build-binutils-mesboot0-2.14.drv-0/binutils-2.14/missing flex > -checking for flex... (cached) > /tmp/guix-build-binutils-mesboot0-2.14.drv-0/binutils-2.14/missing flex > -checking for yywrap in -ll... (cached) no > -checking lex output file root... (cached) lex.yy > [..] > +checking for flex... no > +checking for lex... no > +./configure: line 4417: flex: command not found > +checking for flex... lex > +checking for yywrap in -ll... no > +checking lex output file root... ./configure: line 4505: lex: command not > found > +configure: error: cannot find output from lex; giving up > +make: *** [configure-ld] Error 1 > --8<---cut here---end--->8--- > > What is your build environment/version of guix you're using? It looks > like some unreproducible bit is leaking in somewhere?? > > Greetings, > Janneke > > -- > Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org > Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#45165: binutils-mesboot0 fails at configure, cannot find lex
derivation `/gnu/store/9mf1r6xzp10gcxks4dbr2iiqn2imm1bi-glibc-utf8-locales-2.31.drv': 1 dependencies couldn't be built Backtrace: 11 (primitive-load "/gnu/store/1q0np6cpqjj6180qwxglxm2xf7dsvqlx-compute-guix-derivation") In ice-9/eval.scm: 155:9 10 (_ _) 159:9 9 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?)) In ./guix/store.scm: 2049:24 8 (run-with-store # _ #:guile-for-build _ #:system _ #:target _) 1883:8 7 (_ _) In ./guix/gexp.scm: 258:18 6 (_ _) 1123:2 5 (_ _) 982:2 4 (_ _) 843:4 3 (_ _) In ./guix/store.scm: 1931:12 2 (_ #) 1358:5 1 (map/accumulate-builds # _ _) 1369:15 0 (_ # _ _) ./guix/store.scm:1369:15: Throw to key `srfi-34' with args `(#)'. guix pull: error: You found a bug: the program '/gnu/store/1q0np6cpqjj6180qwxglxm2xf7dsvqlx-compute-guix-derivation' failed to compute the derivation for Guix (version: "64098437081d8752d95ca9d065bf8367bd5ffb08"; system: "x86_64-linux"; host version: "bf8dfe3df025e4ac80cccb87497b4f072ba10e2a"; pull-version: 1). Please report it by email to . - Cheers, Carl Dong
bug#40459: Non-reproducible behaviour in libtool < 2.2.7b bootstrapped ltmain.sh
Hi Guix! While investigating a libstdc++.a reproducibility issue, I found that libtool prior to 74c8993c (first included in version 2.2.7b, link: https://git.savannah.gnu.org/cgit/libtool.git/commit/?id=74c8993c178a1386ea5e2363a01d919738402f30) did not sort find output. It seems that many packages (including all released gcc versions so far) are bootstrapped with a libtool < 2.2.7b. There are probably many ways to approach this, and I propose that we could simply use a somewhat strict regex find and replace on ltmain.sh. Would love feedback and better ideas! Cheers, Carl Dong
bug#32773: [PATCH] Fix clang libstdc++ header location search
Hi David!
This patch is most welcome, I’m wondering if you think it’d be possible to add
more details in the comments for future readers of the code. See below.
> On Nov 13, 2019, at 11:56 AM, David Truby wrote:
>
> +;; Make clang look for libstdc++ in the right
> location
> +(("LibStdCXXIncludePathCandidates\\[\\] = \\{")
> + (string-append
> "LibStdCXXIncludePathCandidates[] = { \"" gcc "/include/c++\","))
I believe the reason why clang’s “auto detection” fails here is because it
expects the /include dir containing c++ to be under the same directory as
LibDir, correct? Perhaps we can note that since in Guix, we put the libs in a
separate output, we invalidate the aforementioned expectation, and this is why
we need to manually add this path.
Another point: Perhaps we can add the path on a separate line instead of it
being on the same line?
Otherwise, looks great!
Cheers,
Carl Dong
bug#37999: clang fails to pickup/supply startfiles to ld
Thank you so much Mathieu for the patch! Marius: I believe this will only cause a rebuild for clang and not llvm, which means that it only affects ~30 packages. Perhaps this can go in master? Would love to know your thoughts. Cheers, Carl Dong cont...@carldong.me "I fight for the users" ‐‐‐ Original Message ‐‐‐ On Thursday, October 31, 2019 10:57 PM, Marius Bakke wrote: > Mathieu Othacehe m.othac...@gmail.com writes: > > > From f126146880e3904f39728313dfc10288b51fc23a Mon Sep 17 00:00:00 2001 > > From: Mathieu Othacehe m.othac...@gmail.com > > Date: Thu, 31 Oct 2019 15:05:54 +0100 > > Subject: [PATCH] gnu: clang-from-llvm: Fix set-glibc-file-names phase. > > > > - gnu/packages/llvm.scm (clang-from-llvm)[arguments]: Turn case on major > > version into a cond, so that newer versions of clang have the same > > behaviour as > > version 6 and 7. > > > > LGTM. It will have to wait for the next 'staging' window, though.
bug#38061: [minimal reproducer included] libstdc++ mutex references cause clang builds to fail
Hi all,
I'm having another issue with the clang toolchain right now and I've come up
with a minimal reproducer:
Given the following manifest.scm:
--8<---cut here---start->8---
(use-modules (gnu packages gcc)
(gnu packages linux)
(gnu packages llvm))
(packages->manifest
(list clang
(make-libstdc++ gcc)
linux-libre-headers))
--8<---cut here---end--->8---
And test.cpp:
--8<---cut here---start->8---
#include
#include
typedef std::once_flag once_flag;
int
main()
{
std::cout << "Hello, World\n";
}
--8<---cut here---end--->8---
If you invoke:
--8<---cut here---start->8---
guix environment --manifest=manifest.scm --container --pure -- clang++ test.cpp
--8<---cut here---end--->8---
The output looks like:
--8<---cut here---start->8---
test.cpp:4:14: error: no type named 'once_flag' in namespace 'std'
typedef std::once_flag once_flag;
~^
1 error generated.
--8<---cut here---end--->8---
In my original non-minimal build, other things in also cause compilation
errors, which seem odd to me.
Any help would be very much appreciated!
Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"
bug#37876: Regression in MAKE-GCC-TOOLCHAIN after core-updates merge
Hi all, Looking closer at the code, the regression seems to be in MAKE-GCC-LIBC in (gnu packages base), rather than in MAKE-GCC-TOOLCHAIN. New minimal reproducer: --8<---cut here---start->8--- (use-modules (gnu packages commencement) (gnu packages gcc) (gnu packages base)) (make-gcc-libc gcc glibc-2.28) --8<---cut here---end--->8--- Cheers, Carl Dong cont...@carldong.me "I fight for the users"
bug#37876: Regression in MAKE-GCC-TOOLCHAIN after core-updates merge
Hi Ludo’, > Does it work with ‘glibc-2.28’? Curiously... glibc-2.28 also doesn't work: https://www.dropbox.com/s/ly7u4sf0umgz509/gcc-glibc-2.28-7.4.0.drv.log?dl=1 > We’re not building any such toolchain in CI but we probably should… I think so too, happy to contribute a patch for the CI after we figure this out. Cheers, Carl Dong cont...@carldong.me "I fight for the users"
bug#37876: Regression in MAKE-GCC-TOOLCHAIN after core-updates merge
Hi all, I believe there's been a recent regression w/re MAKE-GCC-TOOLCHAIN. I'm unable to guix build the following minimal reproducer: --8<---cut here---start->8--- (use-modules (gnu packages commencement) (gnu packages gcc) (gnu packages base)) (make-gcc-toolchain gcc glibc-2.27) --8<---cut here---end--->8--- My guix describe output: Generation 33 Oct 22 2019 15:07:03(current) guix f5d6c88 repository URL: https://git.savannah.gnu.org/git/guix.git commit: f5d6c88d0f5e1556295c1a19c46ddfcb7a23107f The build failure logs can be found here: https://www.dropbox.com/s/y7sg3m786ziiwvb/gcc-glibc-2.27-7.4.0.drv.log?dl=0 Cheers, Carl Dong cont...@carldong.me "I fight for the users"
bug#30756: GCC >= 6 '-isystem' and C_INCLUDE_PATH behavior changed, breaking #include_next
Hi all, I ran into a similar problem in 37870, whereby the mingw-w64 search path was placed at the top of the search paths, making include_next very grumpy. Mark: I'm curious as to why -idirafter was not a viable solution to the problem, as it seems like the perfect way to add a path to the bottom of the list of search paths. Perhaps there's something more fundamental that I'm missing? Cheers, Carl Dong cont...@carldong.me "I fight for the users"
bug#37801: Possible insight into issue #30756 #include_next bug
Hi Danny, Thank you so much for the links and quotes, I'm definitely going to refer back to them in the future and you probably saved me dozens of hours :-) > I think so. I can't figure out why Guix is not just setting up CROSS_CPATH > on its own in the first place. > gnu/packages/cross-base.scm DOES have a search-path specification for > CROSS_CPATH. Perhaps Ludovic can confirm this, but I believe the reason why Guix is not setting up CROSS_CPATH is because it doesn't _know_ it's cross-compiling. Guix only sets up CROSS_CPATH when we invoke on the command line with --target=x86_64-w64-mingw32 or something like that. I'm not exactly sure what a clean solution to this is, but I'd hope we can find one in the future. I'm thinking that the reason why my final solution involved explicitly setting the exact ordering in my CROSS_CPLUS_INCLUDE_PATH was because mingw-w64 is considered to be libc and that makes it special somehow. Not 100% sure though. Cheers, Carl Dong cont...@carldong.me "I fight for the users"
bug#36777: Guix Inferiors: Curious incorrect derivation output bug
All,
Yes! The patch actually fixed the problem when applied on top of
5cf4b26d52bcea382d98fb4becce89be9ee37b55! I was also able to come up with a
minimal reproducing manifest:
```
(use-modules (guix inferior) (guix channels)
(srfi srfi-1)) ;for 'first'
(define channels
(list (channel
(name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git;)
(commit
"6869b6635afd93872b8f0d9f2db0db4c0d765a86"
(define inferior
;; An inferior representing the above revision.
(inferior-for-channels channels))
(packages->manifest
(map (lambda (x)
(first (lookup-inferior-packages inferior x)))
'("gzip")))
```
It seems that the `gzip` package is what's causing this.
Not sure what the next steps are for this, but I'd very much like to understand
where this went wrong. Perhaps we could write tests for this so it doesn't
happen in the future for releases.
Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"
bug#36777: Guix Inferiors: Curious incorrect derivation output bug
Hi all, I did some more digging, and have included a git-bisect log, the -info-dir.drv, and -info-dir-builder here: https://gist.github.com/dongcarl/0a305badf20c9b5cfae738147ca416af Please let me know if I can provide more information. Cheers, Carl Dong cont...@carldong.me "I fight for the users" ‐‐‐ Original Message ‐‐‐ On Friday, July 26, 2019 7:50 AM, Ludovic Courtès wrote: > Hello Carl, > > Carl Dong cont...@carldong.me skribis: > > > I have my manifest.scm here: > > https://github.com/dongcarl/bitcoin/blob/2019-06-guix-channels-and-inferiors/contrib/guix/manifest.scm, > > and it references the aforementioned Guix channel. > > This one appears to work for me (I interrupted it before it was done > compiling all the toolchains, though.) > > > What I expect to happen is that now when I change my default profile's Guix > > version by 'guix pull'ing, it won't affect the environment that's generated > > by > > the manifest.scm. I've tested this with differing versions of Guix as my > > default > > profile, and this seems to work with > > 7304d5623ab5cc35289cb1535cbd0d8a37691fac > > and 7f1c69f5d32bee6b8b6b902a9ce445e04aa9d07d being my default profile. > > However, > > I tried an older version b6dc08393e6a8313b88ce422fc3c1e4e9c0efc6f, and got > > the > > following error: > > When I put b6dc08393e6a8313b88ce422fc3c1e4e9c0efc6f in .guix-channel and > use that as my channel, it also works fine (well, I commented out the > toolchains as well.) > > > guix environment: error: derivation > > `/gnu/store/r641vpqc9rfjhljf7rzfzwmkmpa642ls-info-dir.drv' has incorrect > > output `/gnu/store/q9hkdidycz3wq28xxgjq47bzx5s39k52-info-dir', should be > > `/gnu/store/z5hh2nl0h58b9f6hdxfwm00gjyxfcc3n-info-dir' > > > > That definitely looks like a bug. > > Could you send the faulty info-dir.drv file? > > Thanks, > Ludo’.
bug#36777: Guix Inferiors: Curious incorrect derivation output bug
Hi all, I've been working on improving the Guix build support on Bitcoin Core so that it'll be ready to use for official releases. One of the things that I wanted to do was to use a combination of channels and inferiors to have reproducible builds across time. I have most of it set up, but am running into some trouble. Here are the details: I have a Guix channel set up at https://github.com/dongcarl/bitcoin-guix, where I pin the Guix version to 6869b6635afd93872b8f0d9f2db0db4c0d765a86 in the .guix-channel, and declare all my packages in packages.scm. I have my manifest.scm here: https://github.com/dongcarl/bitcoin/blob/2019-06-guix-channels-and-inferiors/contrib/guix/manifest.scm, and it references the aforementioned Guix channel. What I expect to happen is that now when I change my default profile's Guix version by 'guix pull'ing, it won't affect the environment that's generated by the manifest.scm. I've tested this with differing versions of Guix as my default profile, and this seems to work with 7304d5623ab5cc35289cb1535cbd0d8a37691fac and 7f1c69f5d32bee6b8b6b902a9ce445e04aa9d07d being my default profile. However, I tried an older version b6dc08393e6a8313b88ce422fc3c1e4e9c0efc6f, and got the following error: ``` guix environment: error: derivation `/gnu/store/r641vpqc9rfjhljf7rzfzwmkmpa642ls-info-dir.drv' has incorrect output `/gnu/store/q9hkdidycz3wq28xxgjq47bzx5s39k52-info-dir', should be `/gnu/store/z5hh2nl0h58b9f6hdxfwm00gjyxfcc3n-info-dir' ``` I remember my previous attempts at integrating channels and inferiors into our workflow yielded a similar result, so I would like to know if this is a bug, and how I might go about fixing this so that I can feel comfortable using inferiors for our builds. Nevertheless, thank you all for your hard work. The fact that we have inferiors at all is marvelous! Cheers, Carl Dong cont...@carldong.me "I fight for the users"
bug#36238: Problems cross-compiling on core-updates
Unfortunately b1593c1c4fd8f4fc6df4c43cab51334426e3aa76 still doesn't work, I've attached the log. Cheers, Carl Dong cont...@carldong.me "I fight for the users" r7dqzwhva6pgi4g3hasvbj3yf9wgq4-bison-3.4.1.drv.bz2 Description: BZip2 compressed data
bug#36238: Problems cross-compiling on core-updates
Hi all, I noticed that cross-compiling isn't working on the core-updates branch. I'm on commit cfd4e4d06e3cda0f3eed8d6b9277ce53e55404b8 and all you need to reproduce is to invoke: ./pre-inst-env guix build --target=aarch64-linux-gnu coreutils Attached is the build log. Cheers, Carl Dong cont...@carldong.me "I fight for the users" riwrnisxp5skbmi8alq3m611g46lid-bison-3.4.1.drv.bz2 Description: BZip2 compressed data
