.
I: Unpacking dpkg...
I: Unpacking e2fsprogs...
I: Unpacking findutils...
I: Unpacking gnumach-common...
I: Unpacking gnumach-image-1.8-486...
I: Unpacking grep...
I: Unpacking gzip...
I: Unpacking hostname...
I: Unpacking hurd...
I: Unpacking hurd-libs0.3:hurd-amd64...
I: Unpacking init-system-helpe
an_inlined_ports) and the MiG patch, which required a 3 line change
> > to add appropriate casts from mach_port_name_inlined_t* to mach_port_t*
> > in server.c.
>
> Thanks for the update!
>
> I confirm it now builds fine with -Werror, I have pushed the whole
> series.
I have put some note on the wiki
https://darnassus.sceen.net/~hurd-web/open_issues/64-bit_port/
to build a proper debian hurd-amd64 chroot:
sudo debootstrap --foreign --verbose --arch hurd-amd64
--keyring=/usr/share/keyrings/debian-keyring.gpg sid chroot-hurd-amd64
https://people.debian.org
On 2/12/24 8:31 PM, Flavio Cruz wrote:
This port extends the existing i686 port to support x86_64 by trying to
reuse existing code whenever it makes sense.
* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
position of amd64 registers in the different Hurd structs, including
Samuel Thibault, le dim. 25 août 2024 17:50:51 +0200, a ecrit:
> An amd64 installer cd image is available on
>
> https://people.debian.org/~sthibault/hurd-amd64/installer/cdimage/daily/
I have also put it on
http://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/current/
where it
Samuel Thibault, le dim. 22 juin 2025 17:14:41 +0200, a ecrit:
> Almudena Garcia, le dim. 22 juin 2025 17:10:22 +0200, a ecrit:
> > Do you will publish amd64 version?
>
> There are already quite recent versions for amd64.
But I had forgotten about the mig transition... I have re
May 12, 2023 5:58 PM, "Samuel Thibault" wrote:
> I have put some note on the wiki
>
> https://darnassus.sceen.net/~hurd-web/open_issues/64-bit_port
>
> to build a proper debian hurd-amd64 chroot:
>
> sudo debootstrap --foreign --verbose --arch hurd-amd64
Diego Nieto Cid wrote:
> I tried on qemu and also had some issues, I'm not sure why :(
>
> - IRC -
> hmm it seems I also have some trouble running the latest image
> too.
> > qemu-system-x86_64 -drive
> file=debian-hurd-amd64-2025080
g/cdimage/ports/latest/hurd-amd64/debian-hurd-20241115.img.tar.xz
> boots fine in VirtualBox (7.0.x on Ubuntu).
>
> The image from August 2025
> https://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/debian-hurd-amd64-20250807.img.tar.xz
> does not boot in VirtualBox (7.0.x on Ubun
On August 25, 2024 6:02:02 PM GMT+02:00, Samuel Thibault
wrote:
>Samuel Thibault, le dim. 25 août 2024 17:50:51 +0200, a ecrit:
>> An amd64 installer cd image is available on
>>
>> https://people.debian.org/~sthibault/hurd-amd64/installer/cdimage/daily/
>
>
Hi,
Did anyone have any success in booting GNU/Hurd (GNUMach) on AMD64 computer? I
was playing with GNU/Hurd using Qemu, and it worked fine. Two days ago I have
found a forgotten 2.5G drive and I have installed hurd on that drive. But,
whenever I try to boot it, Grub just loads the kernel and
On Wed, Apr 26, 2006 at 08:42:09PM +0200, Filip Brcic wrote:
> Did anyone have any success in booting GNU/Hurd (GNUMach) on AMD64 computer?
I don't think so. I heard quite a number of people reporting the same
incident you just reported. Since I don't have such hardware, I ca
alize
> (which
> can be seen here[1]).
> [1]
> https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gunixcredentialsmessage.c?ref_type=heads#L115
>
> It seems to be some structure size issue on amd64 (i386 tests don't fail)
> regarding
> SCM_CREDS imp
17:50:51 +0200, a ecrit:
> > An amd64 installer cd image is available on
> >
> > https://people.debian.org/~sthibault/hurd-amd64/installer/cdimage/daily/
>
> I have also put it on
> http://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/current/
>
> where it won't be overwritten by newer daily images.
>
> Samuel
>
>
Sergey Bugaev, le mer. 03 mai 2023 01:16:29 +0300, a ecrit:
> I see [0] -- is that it? Cool!
>
> [0]: https://salsa.debian.org/glibc-team/glibc/-/commits/hurd-amd64
It's part of it yes.
> How does this work -- how does the Debian tooling know what
> 'hurd-amd64&#x
On 2/23/24 9:28 PM, Flavio Cruz wrote:
This port extends the existing i686 port to support x86_64 by trying to
reuse existing code whenever it makes sense.
* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
position of amd64 registers in the different Hurd structs.
The
What are the memory limits in AMD64 GNU Mach? Is it 1TB or 64TB?
Yuhong Bao
: src
status: broken
reasons:
-
missing:
pkg:
package: firefox-esr
version: 78.8.0esr-1
architecture: any,all
type: src
unsat-dependency: libnspr4-dev:hurd-i386 (>= 2:4.25~)
-
package: openjdk-11
version: 11.0.4+11-1
architec
Hello,
An amd64 installer cd image is available on
https://people.debian.org/~sthibault/hurd-amd64/installer/cdimage/daily/
It seems to be working, provided that one has enough memory (2G seems
enough)
Samuel
Almudena Garcia, le dim. 22 juin 2025 17:10:22 +0200, a ecrit:
> Do you will publish amd64 version?
There are already quite recent versions for amd64.
Samuel
es but got 88 bytes of data
> >
> > which I traced to the GIO function g_unix_credentials_message_deserialize
> > (which
> > can be seen here[1]).
> > [1]
> > https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gunixcredentialsmessage.c?ref_type=heads#L115
> >
&g
Samuel Thibault, le ven. 05 mai 2023 17:30:11 +0200, a ecrit:
> Sergey Bugaev, le ven. 05 mai 2023 18:15:00 +0300, a ecrit:
> > On Fri, May 5, 2023 at 4:30 PM Samuel Thibault
> > wrote:
> > > FI, I'm having debian hurd-amd64 packages cross-built, I'm getting e.
On Tue, Feb 27, 2024 at 11:15 PM John Baldwin wrote:
> On 2/23/24 9:28 PM, Flavio Cruz wrote:
> > This port extends the existing i686 port to support x86_64 by trying to
> > reuse existing code whenever it makes sense.
> >
> > * gdb/amd64-gnu-tdep.c: Adds logic for
Hi,
Il 05/09/23 20:27, Guy-Fleury Iteriteka ha scritto:
https://people.debian.org/~sthibault/hurd-i386/initrd-amd64.img.gz
»
And how you launch this one. I get: no bootable module
It can be used as a ramdisk; one way to use it (maybe not the simplest,
but more or less the one I used) is to
On 4/27/06, Filip Brcic <
[EMAIL PROTECTED]> wrote:Hi,Did anyone have any success in booting GNU/Hurd (GNUMach) on AMD64 computer? I
was playing with GNU/Hurd using Qemu, and it worked fine. Two days ago I havefound a forgotten 2.5G drive and I have installed hurd on that drive. But,whenever
-
hmm it seems I also have some trouble running the latest image
too.
> qemu-system-x86_64 -drive
file=debian-hurd-amd64-20250807.img,cache=writeback
this leads to: panic: ../vm/vm_page.c:1607: vm_page_alloc_pa:
vm_page:: privileged thread unable to allocate page
and bumping a bit the a
Samuel Thibault, le ven. 05 mai 2023 19:23:57 +0200, a ecrit:
> Samuel Thibault, le ven. 05 mai 2023 17:30:11 +0200, a ecrit:
> > Sergey Bugaev, le ven. 05 mai 2023 18:15:00 +0300, a ecrit:
> > > On Fri, May 5, 2023 at 4:30 PM Samuel Thibault
> > > wrote:
> > >
ction g_unix_credentials_message_deserialize (which
can be seen here[1]).
It seems to be some structure size issue on amd64 (i386 tests don't fail)
regarding
SCM_CREDS implementation. But I couldn't debug the test because they are run
from
complicated shell scripts :(
Two patches to the test runner needs to be a
Hi!
I've started porting gnumach to amd64, slowly, and I don't promise I'll
get anything ready soon, or ever.
I'm first going to fix compilation warnings on ia32 so that it's easier
to spot the 64-bit problems on amd64, and any regressions in ia32
introduced when fixi
On 06 May 2023 16:17, Samuel Thibault wrote:
> This adds support for passing -m elf32_x86_64 vs -m elf_x86_64 to the
> linker on hurd-amd64
this was difficult to merge because you aren't using git.
please switch to that in the futrue when sending patches.
-mike
signature.asc
Descr
Po Lu, le lun. 04 sept. 2023 08:53:21 +0800, a ecrit:
> Incidentally, where are the Debian hurd-amd64 images that are always in
> earshot but never in sight?
?
«
If people want to play with it, I have updated the image on
https://people.debian.org/~sthibault/hurd-i386/initrd-amd64.
Constantine Kousoulos, le Thu 08 Mar 2007 20:16:10 +0200, a écrit :
> Since my notebook has a turion processor, shouldn't 'uname -m'
> produce something like 'x86_64'?
No, because GNU Mach only supports AMD64 pro
True. I've just noticed it
Thanks for your work
El dom, 22 jun 2025 a las 17:14, Samuel Thibault ()
escribió:
> Almudena Garcia, le dim. 22 juin 2025 17:10:22 +0200, a ecrit:
> > Do you will publish amd64 version?
>
> There are already quite recent versions for amd64.
>
> Samuel
>
This port extends the existing i686 port to support x86_64 by trying to
reuse existing code whenever it makes sense.
* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
position of amd64 registers in the different Hurd structs.
The signal code is very similar to i686, except the
This port extends the existing i686 port to support x86_64 by reusing
existing code whenever it makes sense.
* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
position of amd64 registers in the different Hurd structs.
The signal code is very similar to i686, except the
On Fri, May 5, 2023 at 4:30 PM Samuel Thibault
> > > > wrote:
> > > > > FI, I'm having debian hurd-amd64 packages cross-built, I'm getting
> > > > > e.g.
> > > > > dash built, I'll probably have rumpkernel built
Arne Babenhauserheide, le Fri 23 Jul 2010 17:57:46 +0200, a écrit :
> 128MiB might be a bit too little… :)
Yes. At least 256MiB is a must.
> (I don’t use kvm – I don’t know if my CPU supports it: no svm flag (amd64))
no svm on amd64 -> no kvm (vmx on intel).
Samuel
Damien Zammit, le mer. 13 août 2025 03:39:39 +, a ecrit:
> We need a timer to delay short amounts during SMP init and to calibrate lapic
> timer. That is why we introduced hpet. It is present in every amd64 board
> since 2005.
> I don't think its too much to expect the t
Il 05/05/23 19:23, Samuel Thibault ha scritto:
Samuel Thibault, le ven. 05 mai 2023 17:30:11 +0200, a ecrit:
Sergey Bugaev, le ven. 05 mai 2023 18:15:00 +0300, a ecrit:
On Fri, May 5, 2023 at 4:30 PM Samuel Thibault wrote:
FI, I'm having debian hurd-amd64 packages cross-built, I'
Thank you for the great QotH!
I enjoyed reading it a lot and only found a single part to comment:
jbra...@dismail.de writes:
> Several packages that build on hurd-i386 are failing to
> build on hurd-amd64, so those certainly need to be fixed. Currently
> swapping does not work well with
On Tue, Dec 31, 2024 at 02:02:53AM +, Diego Nieto Cid wrote:
>
> Here are the results for `hurd-amd64`:
>
> $ cc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-gnu/glib-2.0/include \
> -pthread cred_size.c -lgio-2.0 -lgobject-2.0 -lglib-2.0 \
>
Hello,
Yuqian Yang, le jeu. 19 juin 2025 11:59:04 +, a ecrit:
> I found that Debian lacks `hurd-i386` and `hurd-amd64` variants of
> `crossbuild-essential-*`[1]. I wonder whether this is intentional, or we can
> just add these two.
I'm not aware of any fundamental reason again
Hello,
So it seems I cannot run `sudo apt update` after booting the amd64
image[1]. I followed the instructions to 1) grow the partition and
filesystem, 2) convert the image to a VDI file for Virtual Box and 3) set
the timezone [2].
However I've got the following answer from apt update:
-
otableISO#Determine_those_options_which_need_to_be_adapted_on_amd64_or_i386
> ... and GNU Mach is not a Linux...
It seems that the Debian GNU/Hurd ISOs already use GRUB for booting via
legacy BIOS. So using GRUB for EFI would not be as inconvenient as for
Debian amd64, which needs configuration for both SYSLINUX and GRUB.
But a
entially no "laptop" support then (albeit a little bit vintage, amd64
> uses newer expansion slots, but we don't support 64 bit...)
Amd64 cpus can boot 32bit systems fine. That works on my laptop for
instance.
Samuel
On September 4, 2023 9:50:34 AM GMT+02:00, Samuel Thibault
wrote:
>Po Lu, le lun. 04 sept. 2023 08:53:21 +0800, a ecrit:
>> Incidentally, where are the Debian hurd-amd64 images that are always in
>> earshot but never in sight?
>
>?
>
>«
>If people want to play wit
mage/ports/latest/hurd-amd64/debian-hurd-20241115.img.tar.xz
> boots fine in VirtualBox (7.0.x on Ubuntu).
>
> The image from August 2025
>
> https://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/debian-hurd-amd64-20250807.img.tar.xz
> does not boot in VirtualBox (7.0.x on U
e for now,
but saving/restoring sse registers needs to be implemented.
With that fixed/worked around, I was not seeing erroneous configure
executions etc. any more, so I was able to unleash the hurd-amd64 build
daemon, which has been busy building packages for a couple of weeks now,
we have
Hello again,
Nevermind, I had to also set the date with `date -s ""`. It seems
only changing the timezone is not enough as the time is not fixed.
Thanks
El lun, 2 dic 2024 a las 23:23, Diego Nieto Cid ()
escribió:
> Hello,
>
> So it seems I cannot run `sudo apt update` afte
Diego Nieto Cid, le mar. 31 déc. 2024 02:47:35 +, a ecrit:
> On Tue, Dec 31, 2024 at 02:02:53AM +, Diego Nieto Cid wrote:
> >
> > Here are the results for `hurd-amd64`:
> >
> > $ cc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-gnu/glib-2.0/include \
> &
This adds SIGSEGV_FAULT_STACKPOINTER for the hurd-amd64 case
--- ./lib/sigsegv.c.original2023-05-05 10:45:54.673751100 +
+++ ./lib/sigsegv.c 2023-05-05 10:48:47.903577554 +
@@ -351,6 +351,17 @@
"old esp, if trapped from user". */
# define SIGSEGV_FAULT_STACKPO
e.
> I've tried debootstrapping from
> https://people.debian.org/~sthibault/tmp/hurd-amd64 as the wiki page
> says; but that doesn't proceed beyond the rumpdisk. Rumpdisk just sits
> there, slowly spitting out logs;
Does it detect disks? What qemu parameters are you using?
I&#x
Constantine Kousoulos, le Mon 05 Mar 2007 20:37:25 +0200, a écrit :
> I know that the amd64 arch is a big problem. Maybe with a little
> help i could pinpoint some bugs and, maybe, fix them.
I wouldn't say so big a problem, since Mach got to boot fine :)
> ./native-install: l
Hi!
The pciutils package is failing to build in Debian on hurd-amd64:
https://buildd.debian.org/status/fetch.php?pkg=pciutils&arch=hurd-amd64&ver=1%3A3.13.0-1%2Bb1&stamp=1732538417&raw=0
The error is the following:
,---
315 | int err = pci_get_dev_rom(device_p
7;m still getting the Killed message when running
programs,
even when I do "make check" for running the test suite. :(
Is master supposed to work or should I check some more stable branch?
[1]
http://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/debian-hurd-amd64-20250316.img.tar.
.
[0]: https://people.debian.org/~sthibault/tmp/hurd-amd64/README.txt
I can't just install packages by reconfiguring apt and installing them
directly as you suggest, because that assumes a working Debian
installation -- naturally, one for a different architecture, and one
that these new packages would break.
Damien Zammit wrote:
> It is present in every amd64 board since 2005.
> I don't think its too much to expect the timer to exist for amd64.
I see. It seems it is part of ICH 6 and newer [1][2].
VirtualBox has a setting to emulate ICH 9 instead of PIIX3 [3]. When I try
booting Hur
it and then compress it. They put a lot of
stress on ext2fs and rumpdisk and make them take a lot of CPU time,
running at almost 100%. Especially the md5sum step.
There is a merge request on Debian's packaging repo [1] that proposes
to apply the hurd-i386 patches to hurd-amd64 (disabling some
This port extends the existing i686 port to support x86_64 by trying to
reuse existing code whenever it makes sense.
* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
position of amd64 registers in the different Hurd structs, including
i386_thread_state. The signal code is
isting code whenever it makes sense.
>
> * gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
> position of amd64 registers in the different Hurd structs, including
> i386_thread_state. The signal code is very similar to i686, except the
> trampoline code is adapt
loaded fixed
packages to debian-ports, to be available within a few hours. Samuel Flavio
Cruz, le jeu. 15 févr. 2024 01:56:14 -0500, a ecrit: > This port extends the
existing i686 port to support x86_64 by trying to > reuse existing code
whenever it makes sense. > > * gdb/amd64-gnu-
This port extends the existing i686 port to support x86_64 by trying to
reuse existing code whenever it makes sense.
* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
position of amd64 registers in the different Hurd structs, including
i386_thread_state. The signal code is
ing i686 port to support x86_64 by trying to
> reuse existing code whenever it makes sense.
>
> * gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
> position of amd64 registers in the different Hurd structs, including
> i386_thread_state. The signal code is ve
Sergey Bugaev, le ven. 05 mai 2023 18:15:00 +0300, a ecrit:
> Hello,
>
> On Fri, May 5, 2023 at 4:30 PM Samuel Thibault
> wrote:
> > FI, I'm having debian hurd-amd64 packages cross-built, I'm getting e.g.
> > dash built, I'll probably have rumpkernel b
gt; Cheers,
> Diego
>
> El lun, 11 ago 2025 a las 11:01, Bruno Haible via Bug reports for the GNU
> Hurd () escribió:
>
>> The image from November 2024
>>
>> https://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/debian-hurd-20241115.img.tar.xz
>> boots fin
t how virtualbox considers the RTC time should be set.
Samuel
> El lun, 2 dic 2024 a las 23:23, Diego Nieto Cid (<[1]dnie...@gmail.com>)
> escribió:
>
> Hello,
>
> So it seems I cannot run `sudo apt update` after booting the amd64 image
> [1]. I followed th
On Sat, May 6, 2023 at 8:34 PM Samuel Thibault
wrote:
> This adds SIGSEGV_FAULT_STACKPOINTER for the hurd-amd64 case
>
> --- ./lib/sigsegv.c.original2023-05-05 10:45:54.673751100 +
> +++ ./lib/sigsegv.c 2023-05-05 10:48:47.903577554 +
> @@ -351,6 +351,17 @@
>
3, the
old openssh will break. I have put a Breaks so people don't accidentally
end up there. But installing the rebuilt openssh will not currently
upgrade libc0.3, so be sure to upgrade both packages on your hurd-amd64
system.
So basically, after next "unreleased" mirror pulse (~7:30 U
Guillem Jover, le sam. 22 févr. 2025 14:09:59 +0100, a ecrit:
> The pciutils package is failing to build in Debian on hurd-amd64:
>
>
> https://buildd.debian.org/status/fetch.php?pkg=pciutils&arch=hurd-amd64&ver=1%3A3.13.0-1%2Bb1&stamp=1732538417&raw=0
>
We need a timer to delay short amounts during SMP init and to calibrate lapic
timer. That is why we introduced hpet. It is present in every amd64 board
since 2005.
I don't think its too much to expect the timer to exist for amd64.
Damien
Sent from Proton Mail Android
Ori
no idea about vm/*) implies.
>> ¹ Please note that while int is 32 bits on both i386 and amd64, the
>> size of ptrdiff_t varies between the two.
> It’s unsigned long.
Usually, ‘long’ requires %lX, not %X (‘int’.) These are both
32-bit on i386, but %lX is 64-
in readme [0] is helpful (thank you!),
Note that it is just the boilerplate that I have in all my tmp/ repos.
> but I still have questions.
>
> [0]: https://people.debian.org/~sthibault/tmp/hurd-amd64/README.txt
>
> I can't just install packages by reconfiguring apt and inst
This adds support for passing -m elf32_x86_64 vs -m elf_x86_64 to the
linker on hurd-amd64
Changelog:
* m4/libtool.m4: dd x86_64-gnu* case to pass -m elf32_x86_64 vs
-m elf_x86_64 to linker.
--- m4/libtool.m4.orig 2023-05-03 18:33:23.949698403 +0200
+++ m4/libtool.m4 2023
lt openssh will not currently
> upgrade libc0.3, so be sure to upgrade both packages on your hurd-amd64
> system.
>
> So basically, after next "unreleased" mirror pulse (~7:30 UTC),
> make sure to install libc0.3 (>= 2.40-6~1) and openssh-server (>=
> 9.9p1-3+hurd.1) at
Samuel Thibault, le sam. 22 févr. 2025 15:33:27 +0100, a ecrit:
> Guillem Jover, le sam. 22 févr. 2025 14:09:59 +0100, a ecrit:
> > The pciutils package is failing to build in Debian on hurd-amd64:
> >
> >
> > https://buildd.debian.org/status/fetch.php?pkg=pci
ardware (it didn't in the November 2024 images). But for the moment,
it should be sufficient to document the issue in
https://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/YES_REALLY_README.txt
.
Bruno
[1] https://wiki.osdev.org/HPET
[2] https://www.virtualbox.org/manual/ch08.html
This port extends the existing i686 port to support x86_64 by trying to
reuse existing code whenever it makes sense.
* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
position of amd64 registers in the different Hurd structs, including
i386_thread_state. The signal code is
ing to
> reuse existing code whenever it makes sense.
>
> * gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
> position of amd64 registers in the different Hurd structs, including
> i386_thread_state. The signal code is very similar to i686, except the
> tramp
mp/gnumach
and I'm loading the ext2fs.static module, as obtained from
https://people.debian.org/~sthibault/tmp/hurd-amd64/pool-hurd-amd64/h/hurd/hurd_0.9.git20230520-1_hurd-amd64.deb
which I have put on
https://dept-info.labri.fr/~thibault/tmp/ext2fs.static
and what I obtain is:
GNU Mach
good idea.
The bottom of this Qoth has a section about running the Hurd on a T400. Since
I own a T400, I will try to install the Hurd on it this week, that way, when we
reccomend hardware...I can confidently say that it works.
Draft Qoth Q3 2024:
Samuel Thibault added rust support for hurd-amd
Looks all fine, please push to master!
Samuel
Hi!
On Sat, 2025-02-22 at 15:33:47 +0100, Samuel Thibault wrote:
> Samuel Thibault, le sam. 22 févr. 2025 15:33:27 +0100, a ecrit:
> > Guillem Jover, le sam. 22 févr. 2025 14:09:59 +0100, a ecrit:
> > > The pciutils package is failing to build in Debian on hurd-amd64:
> >
report:
-
package: 0ad
version: 0.0.23.1-5
architecture: amd64,arm64,armhf,i386,kfreebsd-amd64,kfreebsd-i386
type: src
status: broken
reasons:
-
missing:
pkg:
package: init-system-helpers
version: 1.60
architecture: all
essential: true
unsat
> ((struct i386_exception_link *)STACK_IKS(stack) - 1)
> >
> > +#ifdef __x86_64__
> > +#ifdef USER32
> > +#define STACK_ALIGN 4
> > +#else
> > +/* Follow System V AMD64 ABI guidelines. */
> > +#define STACK_ALIGN 16
> > +#en
Samuel Thibault wrote:
Constantine Kousoulos, le Mon 05 Mar 2007 20:37:25 +0200, a ιcrit :
I know that the amd64 arch is a big problem. Maybe with a little
help i could pinpoint some bugs and, maybe, fix them.
I wouldn't say so big a problem, since Mach got to boot fine :)
:)
./n
1]
> > > https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gunixcredentialsmessage.c?ref_type=heads#L115
> > >
> > > It seems to be some structure size issue on amd64 (i386 tests don't fail)
> > > regarding
> > > SCM_CREDS implementation.
&
building
+on the x86_64 userland port in Feb 2023. As of September 2024, the
+Debian hurd-amd64 port works just like the hurd-i386, except for
+missing packages and more
+[[bugs|https://lists.gnu.org/archive/html/bug-hurd/2024-07/msg00058.html]],
+namely swapping issues with rumpdisk and deadlocking
Hi!
> This supports the x86_64-pc-gnu triplet
Applied. Thanks.
Salam-Shalom,
Werner
--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
openpgp-digital-signature.asc
Description: PGP signature
lready ;) ) ).
Ah, I've meant bootstrap as in servers bootstrap, bootstrapfs, all
that. Getting Hurd proper to run on x86_64 *is* the most interesting
thing right now, which is why I'm doing it :)
I see [0] -- is that it? Cool!
[0]: https://salsa.debian.org/glibc-team/glibc/-/commits/hur
ket.h
>
I wrote a little test-case (attached) that compares several sizes of the objects
involved in the GBus authentication.
Here are the results for `hurd-amd64`:
$ cc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-gnu/glib-2.0/include \
-pthread cred_size.c -lgio-2.0 -lgobjec
This port extends the existing i686 port to support x86_64 by trying to
reuse existing code whenever it makes sense.
* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
position of amd64 registers in the different Hurd structs.
The signal code is very similar to i686, except the
Hi,
El lun, 11 ago 2025 a las 15:10, Bruno Haible () escribió:
>
> So, most likely your problem is that you haven't specified "-M q35".
>
>
Thanks so much, that was my problem indeed!!!
Cheers
Diego
o
> # apt-cache rdepends libcap2|wc -l
> 103
>
> Interesting packages: zsh, bind9, syslog-ng, wodim, smbclient,
> pulseaudio*, gnome-keyring, ntpdate, etc.
A lot of which *already* have [linux-any] or [!hurd-i386 !kfreebsd-i386
!kfreebsd-amd64] or | not+linux-gnu in the depend
Sergey Bugaev, le lun. 15 mai 2023 20:51:54 +0300, a ecrit:
> store (= rumpdisk, not ramdisk) and nano? :)
FI nano is now available as debian-amd64 package since a few days :)
Samuel
Samuel Thibault, le jeu. 01 août 2024 00:14:35 +0200, a ecrit:
> - packages that don't fail on hurd-i386, probably worth investigating as
> that'll probably reveal some bugs in the hurd-amd64 port.
(sometimes it's just that the package has 64bit-specific code that was
nev
> source-packages: 32570
> broken-packages: 32570
> paul@binou:~$
>
> The reason:
> output-version: 1.2
> native-architecture: i386
> host-architecture: i386
> report:
> -
> package: 0ad
> version: 0.0.23.1-5
> architecture: amd64,arm64,armhf,i386,kfree
Luca writes:
> Hi Sergey,
>
> Il 03/01/24 09:17, Sergey Bugaev ha scritto:
>> How are you running it? Should I still be using a ramdisk image and
>> not rumpdisk?
>
> Recently I've been installing hurd-amd64 on another disk of my
> hurd-i386 vm and booting from
* i386/i386/thread.h: Define STACK_ALIGN which is 16-byte for 64 bit
programs as recommended by the System V AMD64 guidelines.
* i386/i386/pcb.c: Use STACK_ALIGN to align the bootstrap arguments and
ultimately the stack where the program starts on.
* kern/bootstrap.c: Do not align arg_len here
On Fri, Apr 21, 2023 at 12:24 PM Samuel Thibault
wrote:
> No, they don't :) otherwise they wouldn't respect the ABI. The AMD64
> ABI indeed defaults to /lib/ld64.so.1, and says that Linux uses
> /lib64/ld-linux-x86-64.so.2, and that is cast in stone, we cannot change
> it
m
configuration files, relegating their task to Autoconf instead.
Incidentally, where are the Debian hurd-amd64 images that are always in
earshot but never in sight?
Thanks.
1 - 100 of 303 matches
Mail list logo
