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
ldb-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 0c40829872a9f00f38e11d
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:
erivation 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
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:Makefile: sterror
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 thi
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"
)
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
tests/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"
LOCK_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"
.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"
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
[ Pr
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-
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
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
358: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
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
d 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
ace '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"
.o")), which really calls
Driver::GetFilePath in lib/Driver/Driver.cpp under the hood. Meaning that we
just need to make Driver::GetFilePath aware of our glibc path and return the
correct full path to crt1.o and crti.o.
If anyone can help out here it would be much appreciated.
Cheers,
Carl Dong
(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"
he CI after we figure this out.
Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"
it/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"
o 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"
_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"
include"
+
"/lib/gcc/x86_64-w64-mingw32/7.4.0/include-fixed"))
+ ":")
+ ":"
+ (getenv "CROSS_CPATH")
(add-before 'build 'fix-target-detection
(lambda _
;; NSIS target detection is screwed up, manually
I'd like some feedback on
1. Whether this hack is sane or not
2. Does this apply to other packages suffering from the long-standing
"important" issue #30756
3. Does this reveal something more fundamentally wrong with how we build our
search paths in the first place that should be addressed
4. How I might improve the readability of my final patch
Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"
'guix channel. A detail here is that it only triggers, but triggers reliably,
for certain packages in our manifests, with is quite odd.
I've attached the IRC conversation below for convenience.
Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"
```
question about g
re 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"
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 fo
s.
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"
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
42 matches
Mail list logo
