size while the latter refers to the target type.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 2023-06-16 09:26, Sergey Bugaev wrote:
Hello,
So how about this?
"Cause operations on the new file descriptor to act as if the named
file is not the process's controlling terminal, even if it is.
@xref{Job Control}.
When @code{O_IGNORE_CTTY} is not set, @code{open} has to perform a
runtim
On 6/13/23 03:54, Sergey Bugaev wrote:
"Do not recognize the named file as the controlling terminal, even if
it refers to the process’s existing controlling terminal device.
Operations on the new file descriptor will never induce job control
signals."
This is an opportunity to improve the docs!
On 6/10/23 12:13, Sergey Bugaev wrote:
O_IGNORE_CTTY is not about
acquiring a ctty if you don't yet have one (that never happens
implicitly on the Hurd), but about (re)opening your current ctty.
OK, I'm starting to see the distinction now.
I don't know whether any programs actually care ab
On 6/9/23 14:13, Sergey Bugaev wrote:
Perhaps... but there's another reason I don't particularly like the
idea of doing it on that level.
Yes, your points make sense. No big deal either way,
Do you perhaps mean that POSIX does not require a
newly opened terminal to become your ctty even if y
On 2023-06-06 02:21, Sergey Bugaev wrote:
_hurd_port2fd and
_hurd_intern_fd are both public APIs, documented with
"FLAGS are as for `open'; only O_IGNORE_CTTY and O_CLOEXEC are meaningful"
You could change the documentation so that it now says that flags that
imply O_IGNORE_CTTY are also me
On 2023-06-04 13:42, Sergey Bugaev via Libc-alpha wrote:
- int flags = O_RDONLY | O_NONBLOCK | O_DIRECTORY | O_CLOEXEC;
+ int flags = O_RDONLY | O_NONBLOCK | O_DIRECTORY | O_CLOEXEC | O_IGNORE_CTTY;
Why is O_IGNORE_CTTY useful here? O_DIRECTORY means that the file cannot
be a tty. (If GNU/Hu
On 2023-04-20 05:06, Cristian Rodríguez via Libc-alpha wrote:
Exactly, my understanding is that it is a futile exercise ..if one
sufficient privilege at that stage one can do whatever is desired.. why
even bother messing with the standard fds..
Making stdin unreadable is not meant to thwart a
Rebuild vim again... this time the error was double free or prec != ...
something.
Also the error is in vim-gtk3.
I have use ps, to find pid of the test.
run gdb
attach pid_of_the_test
file vim (in gtk3)
bt
note that 0 is the last thing happened.
So in a vim_free (#30), it aborted, much
Ok, the right way to call this is:
paul@binou:~/malloc/glibc-2.31$ dose-builddebcheck --deb-native-arch=hurd-i386
/var/lib/apt/lists/deb.debian.org_debian-ports_dists_unreleased_main_binary-hurd-i386_Packages
/var/lib/apt/lists/deb.debian.org_debian-ports_dists_sid_main_binary-hurd
lib/gcc/i686-gnu/10/include/varargs.h:5:2: error: #error "Revise your code
to use ."
5 | #error "Revise your code to use ."
| ^
Traceback (most recent call last):
File "/home/paul/malloc/glibc-2.31/conform/linknamespace.py", line 217, in
main()
File &
Was searching what are the missing package needed for sbcl to be built (sbcl is
a Common Lisp compiler).
~/.config/dpkg/buildflags.conf
paul@binou:~$ dose-builddebcheck -v --deb-native-arch=i386
/var/lib/apt/lists/deb.debian.org_debian-ports_dists_sid_main_binary-all_Packages
/var/lib/apt
Le sam., 27 févr. 2021 10:30:27 -0500 Samuel Thibault
écrit
> Paul Dufresne, le sam. 27 févr. 2021 09:58:50 -0500, a ecrit:
> > I am trying to rebuild glibc with -DMALLOC_DEBUG=1
> >
> > $ DEB_CFLAGS_APPEND="-DMALLOC_DEBUG=1" dpkg-buildpacka
n:
i686-gnu-gcc-10
/home/paul/malloc/glibc-2.31/build-tree/hurd-i386-libc/hurd/RPC_termctty_open_terminal.c
-c -std=gnu11 -fgnu89-inline -pipe -O2 -g
-fdebug-prefix-map=/home/paul/malloc/glibc-2.31=. -Wall -Wwrite-strings -Wundef
-fmerge-all-constants -frounding-math -fstack-protector-strong -
Le ven., 26 févr. 2021 23:29:01 -0500 Jessica Clarke
écrit
>
> I'd advise you to not delve too deeply into malloc. This is likely a
> buffer overflow that then corrupts the (inline) state maintained by
> malloc, so you really need to be looking at vim.
>
> Jess
I have an i
Le ven., 26 févr. 2021 23:13:56 -0500 Jessica Clarke
écrit
>
> The low 3 bits of the actual size are known to always be 0, so they
> aren't stored and instead replaced with the 3 flags. The diagram
> doesn't make that overly clear, but if you re-read all the text it
> should.
Here is the relevant part in malloc.c:
/*
Search for a chunk by scanning bins, starting with next largest
bin. This search is strictly by best-fit; i.e., the smallest
(with ties going to approximately the least recently used) chunk
that fits is selected.
This looks like one of these moments I think I am brighter than I am... but
here my reasoning of the problem so far:
I am using https://github.com/bminor/glibc/blob/master/malloc/malloc.c
In it we see:
> chunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |
> > vim: malloc.c:4034: _int_malloc: Assertion `(unsigned long) (size) >=
> > (unsigned long) (nb)' failed.
Strangely, the error seems to be seen by many people, in different projects:
This one have found a fix, in a small C program (in 2010):
https://www.linuxquestions.org/questions/programm
Le ven., 26 févr. 2021 16:48:57 -0500 Samuel Thibault
écrit
> Paul Dufresne, le ven. 26 févr. 2021 16:42:16 -0500, a ecrit:
> > Got this on daily image (was a few days I did not tried):
> > vim depends on vim-common (= 2:8.2.2434-1); however:
> > Version of
Got this on daily image (was a few days I did not tried):
vim depends on vim-common (= 2:8.2.2434-1); however:
Version of vim-common on system is 2:8.2.2434-2.
Vim depends on vim-runtime (= 2:8.2.2434-1); however:
Version of vim -runtime on system is 2:8.2.2434-2.
vim-tiny depends on vim-c
This thread have made me look more about Common Lisp.
And I just discovered Mezzano, an OS written in Common Lisp:
https://github.com/froggey/Mezzano/releases/tag/demo5
Do you think it would be possible to use your lisp bindings to use Mezzano's
device drivers... like AHCI, USB, etc?
I do not see a 32 bit version of libfl-devel in my distribution (64 bit version
was installed):
paul@jacko:~/mymach/mig/build$ apt-cache madison libfl-dev
libfl-dev | 2.6.4-8 | http://ca.archive.ubuntu.com/ubuntu groovy/main amd64
Packages
paul@jacko:~/mymach/mig$ dpkg-query --status
I have shown:
fatal error: ac_nonexistent.h: No such file or directory
This is correct, configure is making sure an non-existing include does
correctly stop the compilation.
Taken from:
https://unix.stackexchange.com/questions/360506/what-is-ac-nonexistent-h
https://stackoverflow.com/questions/1811125/undefined-reference-to-yywrap
suggests %option noyywrap
in the scanner specification
Adding it to ../lexxer.l: It worked!
Even the QEMU machine started correctly with the generated gnumach.gz !
Le mar., 09 févr. 2021 12:47:49 -0500 Samuel Thibault
écrit
> Paul Dufresne, le mar. 09 févr. 2021 12:29:11 -0500, a ecrit:
> It's not looking for bash. It's bash which is looking for "no". See the
> configure log, it told you that it didn't find
ix="$GNU"
--host=i686-unknown-linux-gnu
then I believee:
$ make DESTDIR=~/gnu install-data
will install the 32 bit headers files.
I am a bit ignoring your "new" README file in git for now... to test if that
will fix the problem.
But I have new one:
paul@j
Hi, look at the patch in the bug report I mentioned:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=970659;filename=nspr_pr_src_pthreads_ptsynch.c.diff;msg=5
The error lies at the parentheses and (__GLIBC__ == 2 &&
__GLIBC_MINOR__ >= 2) is true for the HURD.
Paul
> Riccardo
>
>
signature.asc
Description: This is a digitally signed message part
RD should be relatively easy, the hard part would be porting
the complete standard library and allowing the Rust compiler to run on
the Hurd, I am a bit unsure whether porting liblibc is still necessary
for porting libstd, if it still is, that would be an additional,
significant amount of wor
About not seeing the GNU Mach console because the BIOS is started in graphical
mode...
if I understood the problem.
Reading Grub doc...
[This paragraph probably don't work because it says it inform Linux to use text
mode]
Maybe before grub-mkconfig: GRUB_GFXPAYLOAD_LINUX
or using e to e
Le mar., 09 févr. 2021 03:54:54 -0500 Samuel Thibault
écrit
> Paul Dufresne, le lun. 08 févr. 2021 21:08:10 -0500, a ecrit:
> > Last time, after compiling my new gnumach.gz on Ubuntu, I did not tried
> > it.
> >
> > I tested it on my QEMU envi
Le mar., 09 févr. 2021 03:54:27 -0500 Samuel Thibault
écrit
> Paul Dufresne, le mar. 09 févr. 2021 00:06:37 -0500, a ecrit:
> > But
> > # apt-get build-dep gnumach
> > did not install mig package.
>
> Didn't it install mig-for-host and mig
But
# apt-get build-dep gnumach
did not install mig package.
I have done pretty much the same under Gnu HURD, and got master (today)
compiled and run without problems.
I have tried to compile older versions like with:
make clean
git checkout `git rev-list -1 --before="August 01 2018" master`
make gnumach.gz
but I get the same result: hanging on start ext2fs:
If I get much before like Jan 1 2018, I get an error about applying a configure
patch... sorry for
Last time, after compiling my new gnumach.gz on Ubuntu, I did not tried it.
I tested it on my QEMU environment (Gnu Hurd from this morning)...
and it stop on:
start ext2fs:
with cursor flashsing after.
I have tried to reverse the printk line I had added to ahci driver (that was
printed)
> Le dim., 07 févr. 2021 13:02:58 -0500 Paul Dufresne
> écrit
>
> > I suspect CAP.SAM was 0 in previous versions... did not check.
> > But that most computers now have CAP.SAM to 1, so that GHC.AE should be
> written, even if already to 1, to "
Thanks! Will try it.
But for now, I'd like to attract your attention on two things about the build:
xorriso : NOTE : Copying to System Area: 26764 bytes from file
'/home/sthibault/tmp/sid/boot1/boot/grub/grub_embed'libisofs:
WARNING : Can't add /debian to Joliet tree. Symlinks can only be added
Le dim., 07 févr. 2021 13:02:58 -0500 Paul Dufresne
écrit
> I suspect CAP.SAM was 0 in previous versions... did not check.
> But that most computers now have CAP.SAM to 1, so that GHC.AE should be
> written, even if already to 1, to "wake up" the device.
I am interested by the fact that when booting Mach on most real hardware I see
an error:
from:
printk("ahci: %02x:%02x.%x: Port %u phy offline?!\n", bus, dev, fun, i);
line 919 of
https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/linux/dev/drivers/block/ahci.c
line 35 of
https://git.savan
Le dim., 07 févr. 2021 10:41:25 -0500 Samuel Thibault
écrit
> Also, make sure to run
>
> make clean
>
> to clean up any leftover from previous bogus attempts.
>
> Samuel
>
hum...hum... Applied that tip and now I have a gnumach.gz file.
nu
configure: error: in `/home/paul/mymach/gnumach/build':
configure: error: C compiler cannot create executables
See `config.log' for more details
I fixed it with: sudo apt install gcc-multilib
Also, after building mig: I was adding ~/bin to my PATH where ~/bin/mig was a
symlink to ~
Did read: https://lists.gnu.org/archive/html/grub-devel/2021-02/msg00023.html
Line 20 of
http://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/i386/i386at/boothdr.S
#define MULTIBOOT_FLAGS 0x0003
Since bit 2, to request from the bootloader video information is not set, it
seems rea
according to man xorriso, that would looks like:
-boot_image "grub" efi_path=bootefi.fat32 platform_id="0xef"
where bootefi.fat32 would be a file in FAT32 containing both:
/EFI/BOOT/BOOTIA32.EFI
/EFI/BOOT/BOOTX64.EFI
... I think.
Will now look atAndrea G. Monaco's post on grub-devel
It seems possible (to boot from a CDROM in UEFI) with SysLinux:
https://wiki.syslinux.org/wiki/index.php?title=Isohybrid#UEFI
unclear if it is with GRUB too... Someone seems to say that System Resue CD do
that
https://askubuntu.com/questions/1025656/how-do-i-boot-an-iso-file-from-my-drive-u
so, with
/media/paul/Debian sid h-i386 1/EFI/boot/BOOTX64.EFI
(for info, I used isomaster to add it, after having copied it from my own
/boot/efi directory (using root access) to my $HOME directory,
chown $USER ~/BOOTX64.EFI )
My previous DVD show the DVD in UEFI boot mode in the Boot men
Well, I was to say that I took a quick look to GNU Mach code, and that it seems
to just ignore the Multiboot2 information data structure,
but it is probably normal, as it use Multiboot "1" Magic:
line 18 of
http://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/i386/i386at/boothdr.S
#define MULT
I just wrote:
> The question is... how to we get the EFI_SYSTEM_TABLE, that was read by
> BOOTX64.EFI (which I believe is part of Grub binary package)...
> or is there an other way to get it again?
That is much easier than I thought!
This manual explains it:
https://www.gnu.org/software/gru
https://help.ubuntu.com/community/UEFIBooting
is a good introduction to booting on UEFI with Grub.
They say:
"If you have a non-Mac UEFI system, then you have a x86_64 (aka 64-bit) UEFI
2.x firmware. "
But I did saw non-MAC UEFI which was 32 bit on relatively old laptops.
Type the following com
I can't boot current in UEFI on "recent: Prime H310M-C CR2.0 motherboard.
Here on Ubuntu, I see the CD have:
/media/paul/Debian sid h-i386 1/EFI/boot/bootia32.efi
nothing else in that /EFI/boot directory.
I am really unsure, but I feel this file is for people having to boot 32 bits
(U
Le ven., 05 févr. 2021 14:27:15 -0500 Samuel Thibault
écrit
> Paul Dufresne, le ven. 05 févr. 2021 12:22:33 -0500, a ecrit:
> > Well, realizing that I would need to make a local mirror of Debian (to be
> > edited by debian-cd, what a strange idea!)
>
>
Well, realizing that I would need to make a local mirror of Debian (to be
edited by debian-cd, what a strange idea!) to build
my own iso... I came to think how I expect Hurd (Debian Hurd I suppose) to
boot. How would I do it?
The way most people expect to try an OS today, is by writing it (th
Well... a bit long... hope it helps Samuel! ;-)
paul@kibar:~/own3/debian-cd$ patch -p1 < patch-debian-cd
patching file CONF.sh
patching file Makefile
patching file data/bullseye/README.html.in
patching file data/bullseye/exclude-udebs
patching file debian/changelog
Hunk #1 succeeded at
Le jeu., 04 févr. 2021 20:11:06 -0500 Samuel Thibault
écrit
> Paul Dufresne, le jeu. 04 févr. 2021 20:06:06 -0500, a ecrit:
> > Le jeu., 04 févr. 2021 19:48:55 -0500 Samuel Thibault
> > écrit
> >
> > > debcheckout debian-cd
>
Le jeu., 04 févr. 2021 19:48:55 -0500 Samuel Thibault
écrit
> debcheckout debian-cd
paul@kibar:~/own3$ debcheckout debian-cd
declared git repository at https://salsa.debian.org/images-team/debian-cd.git
git clone https://salsa.debian.org/images-team/debian-cd.git debian
>That's what debian-cd wants to build iso files.
hey... hey... it is not debian-cd. It is debian-installer.
You see, when I try(tried) to:
mailto:g...@salsa.debian.org:images-team/debian-cd.git
It ask "my" password, and I have none.
Was taken from the Clone (upper-right) in
https://salsa.
Did: $"make build_cdrom_grub"
Got:
paul@kibar:~/owncd3/debian-installer/build$ cat dest/MANIFEST
cdrom/debian-cd_info.tar.gz -- mkisofs config files for CD
cdrom/exec.static -- kernel for use with mkisofs to build a CD
cdrom/ext2fs.static -- kernel fo
Le jeu., 04 févr. 2021 15:05:20 -0500 Samuel Thibault
écrit
> Paul Dufresne, le jeu. 04 févr. 2021 14:39:41 -0500, a ecrit:
> > debootstrap: gpgv: Can't check signature: No public key
>
> It seems I hadn't pushed the fix for the debian-ports keyr
And my resulting mini.iso failed near the beginning of the base installation
with:
debootstrap: gpgv: using RSA key 058165A2348E022{...}
debootstrap: gpgv: Can't check signature: No public key
{hum...}
Ok... got mini.iso on the host now.
Did on the guest:
$cp dest/monolithic/mini.iso ~
Then on the host (not in ssh shell!):
$ scp -P paul@localhost:mini.iso .
Sent using Zoho Mail
Le jeu., 04 févr. 2021 13:40:25 -0500 Samuel Thibault
écrit
> Paul Dufresne, le jeu. 04 févr. 2021 13:38:17 -0500, a ecrit:
> > except it was generated in QEMU (with ssh)... and I don't know yet how to
> > copy the file from QEMU vi
Yeah... by commenting out:
deb http://incoming.ports.debian.org/buildd unstable main/debian-installer
which was not yet available, I have been able to build mini.iso easily from
your new instructions...
except it was generated in QEMU (with ssh)... and I don't know yet how to copy
the file from
ll one hunk rejected:
paul@kibar:~/debian-installer$ cat build/Makefile.rej
--- build/Makefile
+++ build/Makefile
@@ -523,12 +523,18 @@ ifndef ONLY_KLIBC
mkdir -p $(TREE)/lib
# HACK ALERT: X.Org modules are excluded from the scan as mklibs
# is unable to find symbols pr
Because emacs-gtk still seems to be missing from daily image, I toght that if I
could build the CD myself, maybe I could spot why emacs-gtk is not included.
I did found:
https://people.debian.org/~sthibault/hurd-i386/installer/README-d-i but it
seems outdated.
So I have began to make an update
daily image of february 3, base installation:
emacs depends on emacs-gtk >= 1:27.1 | emacs-lucid >= 1:27.1 | emacs-nox >=
1:27.1 but none of them is installed
So the interesting patch(
https://gitlab.com/procps-ng/procps/-/commit/bb96fc42956c9ed926a1b958ab715f8b4a663dec
) was done:
Jan 4 2020
In my opinion that patch should fix the problem.
Current stable version of procps (3.3.16) was released Dec, 7 2019 (about 1
month before the patch).
There is
Upstream was changed:
https://gitlab.com/procps-ng/procps/-/blob/master/pgrep.c
long cmdlen = get_arg_max() * sizeof(char);
where get_arg_max is defined as:
/*
* SC_ARG_MAX used to return the maximum size a command line can be
* however changes to the kernel mean this can be bigger than we
Grrhh! Sorry! Had diff arguments in reverse orders.
root@kibar:~/procps-3.3.16# diff -u ../orig/procps-3.3.16/pgrep.c pgrep.c
--- ../orig/procps-3.3.16/pgrep.c 2020-02-06 06:04:02.0 -0500
+++ pgrep.c 2021-02-02 11:39:44.0 -0500
@@ -498,6 +498,8 @@
pid_t myse
root@kibar:~/procps-3.3.16# diff -u pgrep.c ../orig/procps-3.3.16/pgrep.c
--- pgrep.c 2021-02-02 11:39:44.0 -0500
+++ ../orig/procps-3.3.16/pgrep.c 2020-02-06 06:04:02.0 -0500
@@ -498,8 +498,6 @@
pid_t myself = getpid();
struct el *list = NULL;
Sorry, because in previous posts, it seems code was not exactly the same as
source code.
I now came to the following conclusion:
main (argc=2, argv=0x1032e24) at pgrep.c:935
935 procs = select_procs (&num);
(gdb) s
select_procs (num=0x1032d60) at pgrep.c:489
489 {
(gdb) s
Oops forgot to mention one command in previous post:
In previous post:
#DEB_BUILD_OPTIONS="nostrip noopt" apt -b source procps
root@kibar:~/procps-3.3.16# file /usr/bin/pgrep
Corrected info:
#DEB_BUILD_OPTIONS="nostrip noopt" apt -b source procps
#apt install ./*.deb
root@kibar:~/pro
(gdb) l
429 {
430 PROCTAB *ptp;
431 int flags = 0;
432
433 if (opt_pattern || opt_full || opt_longlong)
434 flags |= PROC_FILLCOM;
435 if (opt_ruid || opt_rgid)
436 flags |= PROC_FILLSTATUS;
43
Code seems to make an abnormal call... I think:
I include the first part to show that you need to cd to the source code
directory for gdb to show you source lines.
root@kibar:~# gdb pgrep
GNU gdb (Debian 10.1-1.7+hurd.1) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc
Using daily image of February 1, with updates for Perl. (I have no reason to
think Perl have something to do with the problem)
I normally don't use pgrep and pkill, but have decided to try them.
I get something like:
root@kibar:~# pgrep Xorg
pgrep: cannot allocate 4294967295 bytes
root@kiba
[Oops, missed one line in my previous message]
gdb _build/src/app/vte-2.91
break 1394
run -v
p message->error
---
[added run -v ]
vte2.91/src/app support -v for verbose info
root, ... not too sure how
much abnormal it is for Hurd.]
root@patsy:/home/paul/xfce4-terminal-0.8.10# ./configure --enable-debug=full
[...]
Build Configuration:
* Debug support: full
root@patsy:/home/paul/xfce4-terminal-0.8.10# make
make all-recursive
make[1]: Ente
I was investigating a bit, under Ubuntu, but I suspect this is quite similar in
Debian... will verify a bit more tomorrow.
paul@jacko:/etc/menu$ dpkg -L twm
/.
[...]
/etc/X11/twm/system.twmrc-menu
/etc/menu-methods
/etc/menu-methods/twm
/usr
/usr/bin
/usr/bin/twm
[...]
/usr/lib/X11
Oh, I should probably mention the following warning from QEMU:
qemu-system-x86_64: warning: host doesn't support requested feature:
CPUID.8001H:ECX.svm [bit 2]
I did not investigate much... don't know what kind of problem it can cause me.
Trying to summarize what I have found.
Default X resolution with QEMU is too big, I set it to the minimum size:
1024x768 with:
root@debian:/home/paul# cat /etc/X11/xorg.conf.d/paul.conf
Section "Device"
Identifier "mydev"
EndSection
Section "Moni
, but not having the rights to do
so... sorry I will try recopy exact message when I see it... if useful.
I also remember that during installation, I think package zlib1g, complains
about /dev/random file not existing...
wait: now reading:
paul@debian:~$ cat /hurd/random-hurd.sh
#!/bin/sh
First, thanks for informing about "su -" needed for /sbin commands to be used
rather than just "su", indeed it fixed my problem.
So after installing the daily image,tasksel, selected "Debian Desktop
environment", "dpkg-reconfigure x11-common xserver-xorg-legacy" as described in
https://www.de
For me,
https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/daily/debian-sid-hurd-i386-NETINST-1.iso
(Jan 26, 2021) have the following problem:
libsource-highlight4v5 depends on libboost-regex1.71.0-icu67 which ... is not
installed -> leaving unconfigured
gdb depends on libsourc
Today I tried to install
https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/daily/debian-sid-hurd-i386-NETINST-1.iso
in QEMU.
I got:
gdb depends on libboost-regex1.74.0-icu67 which is not installed
Seems to be the only problem that stop bootstrap-base to succeed.
I now realized that I was confused by the existence of both:
https://cdimage.debian.org/cdimage/ports/current-hurd-i386/
where current is 20190705, and
http://cdimage.debian.org/cdimage/ports/latest/hurd-i386/current/
where current is 20200731.
I have tried to refrain to respond fastly, trying to find what you are talking
about.
But frankly I think it will not change much my answer.
I did found:
https://buildd.debian.org/status/package.php?p=vim&suite=sid#problem-4
which seems related to what you said about vim segfaulting during bui
I have seen problems with daily images from:
https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/
Was problems with vim, emacs, gdb... in previous days... I think but unsure I
don't seems to see them now.
Had tried previous monthly image, was also having vim and emacs installatio
On real hardware I have seen a kind of error on loading AHCI: from my memory:
phys 0 offline!?
So I tried to emulate a SATA connected cdrom in QEMU with:
qemu-system-i386 -m 700M --device ich9-ahci,id=sata -drive media=cd
rom,if=none,id=sata-cd0,file=debian-sid-hurd-i386-DVD-1.iso -device
ide
by the pci/ directory:
00:00.0
00:02.0
00:14.0
00:16.0
00:17.0
00:1C.0
00:1C.6
02:00.0
04:00.0
And now the great moment, the devices as given by Linux lspci:
paul@Bagotteville:~$ lspci -b
00:00.0 Host bridge: Intel Corporation 8th Gen Core 4-core Desktop Processor
Host Bridge/DRAM Re
I am unfamiliar with emacs, but following your message I decided to give a try.
I first found the latest released version is 27.1.
At first, I was not using --enable-kvm with qemu-system-i386, but because emacs
is relatively big, it helps a lot.
So, as root, I "wget http://ftp.gnu.org/gnu
s, if I remember well. But Hurd doesn't
support USB, and these are usually listed with lsusb which, obviously, doesn't
exists on the Hurd
El lun., 26 oct. 2020 a las 15:58, Paul Dufresne (<mailto:dufres...@zoho.com>)
escribió:
Le lun., 26 oct. 2020 01:42:37 -0400 Damie
Le lun., 26 oct. 2020 01:42:37 -0400 Damien Zammit
écrit
On 26/10/20 10:56 am, Almudena Garcia wrote:
> This is my lspci -nn
I think it's a bug with the pci-arbiter listing some of your hardware four
times using lspci.
Why would the pci-arbiter do such a weird thing?
I know
Your lspci output has:
00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port
1 [8086:27d0] (rev 02)
00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port
1 [8086:27d0] (rev 02)
00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI E
Sorry I misread what you said!
Ok, it is Intel chipset, no ATI card.
It is a bit strange to me it is shown as 2 cards...
But repeating it 4 times seems really a bug in PCI scan.
But I will let Samuel take a look, I think he knows much more than me!
Intel i945G is the chipset, and you can hardly not have a chipset.
And I have been having this chipset for many years and know it has graphical
capabilities.
lspci -nn
would help clarify the issue.
Your T60 Xorg log shows:
[1638054.575] (!!) More than one possible primary device found
[1638054.575] (!!) More than one possible primary device found
[1638054.575] (!!) More than one possible primary device found
[1638054.575] (--) PCI: (0@0:2:0) 8086:27a2:17aa:201a rev 3, Mem @
0xee10/52428
!
Some errors I thought was the cause of the error seems not that important after
all:
>From working Xorg.0.log:
root@debian:/home/paul# cat /var/log/Xorg.0.log|egrep "\(WW\)|\(EE\)"
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[1613931.874] (WW) The director
Le sam., 24 oct. 2020 05:03:56 -0400 Samuel Thibault
<mailto:samuel.thiba...@gnu.org> écrit ----
Paul Dufresne, le sam. 24 oct. 2020 04:10:19 -0400, a ecrit:
> libpciaccess0/unreleased,now 0.16-1+hurd.5 hurd-i386 [installed]
Ah, this is not actually the latest, it seems t
I now see in xorg-server 1.20.9's announce:
https://www.mail-archive.com/xorg@lists.x.org/msg06493.html
Adam Jackson (2):
linux: Make platform device probe less fragile
linux: Fix platform device PCI detection for complex bus topologies
Maybe this break something with hurd?
Option "AutoAddGPU" "true"
Option "AutoAddDevices" "true"
Option "AutoEnableDevices" "true"
EndSection
paul@debian:~$
But I still get:
X.Org X Server 1.20.9
X Protocol Version 11, Revision 0
Build Operating System: GNU 0.
]
Running under qemu:
kvm -m 1G -drive cache=writeback,file=net.img --accel kvm -net nic -net
user,hostfwd=tcp:127.0.0.1:-:22
(but tried startx both in the ssh and in qemu as root and as paul)
paul@debian:~$ cat /var/log/Xorg.0.log
[1503568.161]
X.Org X Server 1.20.9
X Protocol Version
1 - 100 of 144 matches
Mail list logo
