; 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:
>>
>> e48b548
"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
heers,
Carl Dong
t; 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
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:
if there’s any other information I can provide or if this is a dupe!
Cheers,
Carl Dong
sboot0-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,
Ca
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:Makefi
-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
n 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"
)
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
Upstream bug filed: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47940
/tail-2/inotify-dir-recreate.sh :-)
Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"
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"
or 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
amiliar 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"
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"
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
[
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
blem:
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
int “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-
h 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
Hi all,
Let me know if there’s anything at all I can do here to help debug :-)
Cheers,
Carl Dong
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
: "x86_64-linux";
host version: "bf8dfe3df025e4ac80cccb87497b4f072ba10e2a"; pull-version: 1).
Please report it by email to .
-
Cheers,
Carl Dong
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
ly 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
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
d::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"
(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"
after we figure this out.
Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"
t
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"
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"
s
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"
ould 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"
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
. The fact that we have inferiors
at all is marvelous!
Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"
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
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
39 matches
Mail list logo
