On Sun, 2023-01-15 at 22:47 +0100, Bruno Haible wrote:
> Unfortunately, this magic pixie dust depends on your CPU model,
> UEFI/BIOS settings, Linux host kernel version, and VirtualBox
> version.
I just got a new GNU/Linux laptop for working at home: it has the very
latest Intel i9 CPU, NVMe disk,
Paul Smith wrote:
> > I'll try downloading the 2022-08-24
> > version you reference above and see if that makes a difference.
>
> It did not matter: same hang. There's clearly some magic pixie dust
> that needs to be sprinkled on my system to get this to work, that I do
> not have.
Unfortunately
On Sun, 2023-01-15 at 21:31 +0100, Bruno Haible wrote:
> In my instructions for GNU/Hurd in 2020 I had noted
> Disable 'Nested paging', otherwise it DOES NOT BOOT!
>
> So, maybe it's worth looking at the main parameters of the VirtualBox VM:
> - General: Operating System: Other/Unknown
> - S
On Sun, 2023-01-15 at 15:06 -0500, Paul Smith wrote:
> I did get the "current" version, which was created on 2022-10-30.
> Maybe that one is broken? I'll try downloading the 2022-08-24
> version you reference above and see if that makes a difference.
It did not matter: same hang. There's clearl
Paul Smith wrote:
> I've tried a couple of times, using different instructions (VirtualBox
> and vanilla KVM) and every time when it starts to boot the first time
> (after selecting this install) it prints:
>
> ...
> module 0: initrd $(ramdisk-create)
> rd0: 13279232 bytes @fa491
> mod
On Sun, Jan 15, 2023 at 3:04 PM Paul Smith wrote:
>
> On Sun, 2023-01-15 at 19:24 +0100, Bruno Haible wrote:
> > Pseudo-graphical install.
>
> I've tried a couple of times, using different instructions (VirtualBox
> and vanilla KVM) and every time when it starts to boot the first time
> (after sel
On Sun, 2023-01-15 at 19:24 +0100, Bruno Haible wrote:
> Download
> https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/20220824/debian-sid-hurd-i386-DVD-1.iso
I did get the "current" version, which was created on 2022-10-30.
Maybe that one is broken? I'll try downloading the 2022-08-24 ve
On Sun, 2023-01-15 at 19:24 +0100, Bruno Haible wrote:
> Pseudo-graphical install.
I've tried a couple of times, using different instructions (VirtualBox
and vanilla KVM) and every time when it starts to boot the first time
(after selecting this install) it prints:
...
module 0: initrd $(ramd
Paul Smith wrote:
> I will download a GNU/Hurd KVM image, as suggested here:
>
> https://www.debian.org/ports/hurd/hurd-cd
>
> is that appropriate for testing?
Yes.
The GNU/Hurd installation instructions vary a bit over time, but these are
my notes from 5 months ago. Fill in the ** fields.
On Sun, 2023-01-15 at 15:49 +0100, Bruno Haible wrote:
> - 5 failures in category 'features/jobserver'
> - 2 failures in category 'features/parallelism'
> - 1 failure in category 'features/recursion'
> - 1 failure in category 'functions/shell'
It seems these are the same errors from the pr
On Sun, 2023-01-15 at 09:44 -0500, Paul Smith wrote:
> We'll have to override these settings in that test.
OK I made a change that will hopefully address this.
On Mon, 2023-01-16 at 00:15 +0900, KO Myung-Hun wrote:
> Then, this patch is acceptable? Or MSYS is a special case ?
I don't think this patch is a good idea. I said in my initial email:
> I don't think I like this change. I understand its usefulness but in
> general make never tries to manipula
On Sun, 2023-01-15 at 15:53 +0100, Bruno Haible wrote:
> On macOS 12.5 / arm64 I see two test failures:
> - output-sync
> - temp_stdin
Thanks, I fixed this one.
On Sun, 2023-01-15 at 14:58 +0100, Bruno Haible wrote:
> On Manjaro Linux 17, installed from manjaro-kde-17.1.12-stable-
> x86_64.iso,
> in 32-bit mode, the build failure reported in
> https://lists.gnu.org/archive/html/bug-make/2022-10/msg00212.html
> still occurs. Find the build details attache
Hi/2.
Eli Zaretskii wrote:
>> Date: Sun, 15 Jan 2023 00:57:56 +0900
>> From: KO Myung-Hun
>> CC: bug-make@gnu.org
>>
>>> How do you mean "make of mingw does not require $(EXEEXT)"? AFAICT,
>>> if the Makefile defines a target FOO, and there's a file FOO.exe that
>>> is up to date wrt its depende
On macOS 12.5 / arm64 I see two test failures:
- output-sync
- temp_stdin
Find attached the log files. The machine is gcc104.fsffrance.org.
makeerror-4.4.0.90-aarch64-apple-darwin21.6.0-050w.tar.gz
Description: application/compressed-tar
On GNU/Hurd (from 2022), I get 13 test failures:
New:
- 4 failures in category 'features/archives', due to "cc: not found".
Already reported in
https://lists.gnu.org/archive/html/bug-make/2022-10/msg00218.html :
- 5 failures in category 'features/jobserver'
- 2 failures in category 'featu
On Sun, 2023-01-15 at 09:35 -0500, Paul Smith wrote:
> On Sun, 2023-01-15 at 15:33 +0100, Bruno Haible wrote:
> > In this test you have the lines
> >
> > # Fallback if configure did not find AR
> > my $ar = get_config('AR') || 'ar';
> >
> > Why not do the same for CC?
> >
> > my $cc = get_
On Sun, 2023-01-15 at 15:33 +0100, Bruno Haible wrote:
> In this test you have the lines
>
> # Fallback if configure did not find AR
> my $ar = get_config('AR') || 'ar';
>
> Why not do the same for CC?
>
> my $cc = get_config('CC') || 'cc';
Yes, that's how it's done in other tests. I'll
Paul Smith wrote:
> > But instead I see 4 test failures in the 'features/archives'
> > category.
>
> These are because:
>
> ! /bin/sh: 1: cc: not found
>
> Why is there no C compiler on this system? Or is the problem that it's
> not on the PATH for some reason?
Indeed, there is no 'cc' nor '
On Sun, 2023-01-15 at 14:52 +0100, Bruno Haible wrote:
> - The wilcard.9 failure reported in
> https://lists.gnu.org/archive/html/bug-make/2022-10/msg00123.html
> and discussed in
> https://lists.gnu.org/archive/html/bug-make/2022-10/msg00158.html
> is still present.
This is due to bugs in
On Sun, 2023-01-15 at 14:36 +0100, Bruno Haible wrote:
> But instead I see 4 test failures in the 'features/archives'
> category.
These are because:
! /bin/sh: 1: cc: not found
Why is there no C compiler on this system? Or is the problem that it's
not on the PATH for some reason?
On Manjaro Linux 17, installed from manjaro-kde-17.1.12-stable-x86_64.iso,
in 32-bit mode, the build failure reported in
https://lists.gnu.org/archive/html/bug-make/2022-10/msg00212.html
still occurs. Find the build details attached.
makeerror-manjaro17-32bit.tar.gz
Description: application/co
On OpenSUSE Leap 15.2 / x86_64 (a glibc 2.26 system):
- The wilcard.9 failure reported in
https://lists.gnu.org/archive/html/bug-make/2022-10/msg00128.html
and discussed in
https://lists.gnu.org/archive/html/bug-make/2022-10/msg00158.html
is still present.
- The output-sync and temp_stdin
On Debian 9.1.0 / x86 (a machine with glibc 2.24):
- The wilcard.9 failure reported in
https://lists.gnu.org/archive/html/bug-make/2022-10/msg00123.html
and discussed in
https://lists.gnu.org/archive/html/bug-make/2022-10/msg00158.html
is still present.
- The output-sync and temp_stdin fa
On Debian 11.1 / x86_64 (a glibc 2.31 system) I don't see the
older test failures from
https://lists.gnu.org/archive/html/bug-make/2022-10/msg00124.html
any more. But instead I see 4 test failures in the 'features/archives'
category.
Find the logs attached.
makeerror-4.4.0.90-x86_64-pc-linux
On CentOS stream, 3 tests fail, in the output-sync category.
Find attached the logs:
- with gcc: makeerror-4.4.0.90-x86_64-pc-linux-gnu-itaa.tar.gz
- with clang: makeerror-4.4.0.90-x86_64-pc-linux-gnu-dzg1.tar.gz
It looks similar to what I reported in
https://lists.gnu.org/archive/html/bug-ma
27 matches
Mail list logo
