libtool. (Could
someone confirm they have this problem as well?)
Thanks for any advice/suggestion you might have,
--
Jérémie Koenig
http://jk.fr.eu.org/
2010/3/11 Jérémie Koenig :
> By the way, some other problems I have (I will investigate those further):
> * Using the VESA driver, the X server crashes with SIGILL. The
> backtrace shown suggests this happens in the int10 code.
The culprit is xf86EnableIO() in hw/xfree86/os-sup
On Fri, Mar 12, 2010 at 4:22 PM, Samuel Thibault
wrote:
> Jérémie Koenig, le Fri 12 Mar 2010 10:44:13 +0100, a écrit :
>> Apparently the code in my card's BIOS needs access to both 0x40-0x43
>> and 0x60-0x63: if I reenable them manually from within gdb the vesa
>> driv
On Fri, Mar 12, 2010 at 8:29 PM, Samuel Thibault
wrote:
> Jérémie Koenig, le Fri 12 Mar 2010 19:54:31 +0100, a écrit :
>> The vesa driver works on Linux, but gains access to the io ports
>> through iopl(3),
>
> Ah, right, it does both... At first read I thought it was d
On Sat, Mar 13, 2010 at 12:15 PM, Samuel Thibault
wrote:
> Jérémie Koenig, le Sat 13 Mar 2010 02:37:36 +0100, a écrit :
>> (the manual page seems to indicate it can only be used for the
>> first 0x400 ports on Linux).
>
> Yes, but that's precisely what Xorg uses :)
Ah,
On Fri, Mar 19, 2010 at 3:39 AM, Samuel Thibault
wrote:
> Jérémie Koenig, le Thu 11 Mar 2010 12:37:06 +0100, a écrit :
>> with DEB_BUILD_OPTIONS=debug,nostrip, I get a segfault from libtool.
>> (Could someone confirm they have this problem as well?)
>
> There are a coupl
bian-installer tomorrow as expected.
I will be hanging around on #hurd and #debian-hurd in general and be
there on wednesdays, 10:30 UTC in particular. I'll be sure to catch up
on the logs of the previous meetings.
Sorry for the silence again, see you all on wednesday.
--
Jérémie Koenig
http://jk.fr.eu.org/
move on to the other parts of my project for now unless
some critical problem with the attached patch shows up. However I
intend to return to this as soon as possible and I would appreciate if
we could discuss it in the meantime.
Thanks,
--
Jérémie Koenig
http://jk.fr.eu.org/
[1]
2010/6/11 Jérémie Koenig :
> I'm going to move on to the other parts of my project for now unless
> some critical problem with the attached patch shows up.
Such as its author forgetting about enabling ramdisk_write() in
RAMDISK_DEV_OPS, and hence testing it :-/
I attach the corr
s). However I've tested the patch with the
remains of a failed build and it seems it works as exepected. BTW, a
modified gnumach with ramdisk is there as well (deb
http://jk.fr.eu.org/debian unstable/).
--
Jérémie Koenig
http://jk.fr.eu.org/
Only in eglibc-2.11.1: build-tree
diff -ru eglibc-2.11.
ndled on a case-by-case basis in the individual POSIX
calls (mkdir, rmdir, link, unlink, ...) ?
--
Jérémie Koenig
http://jk.fr.eu.org/
ion between links
and nodes is important. Considering this I'm not sure we should
require them to handle the empty string case.
--
Jérémie Koenig
http://jk.fr.eu.org/
n mkdir("/") returning EEXIST.
I'm not sure many such use cases exist.
> For link, we're talking about the target, i.e. "ln something /", so the
> question is the same.
I guess EEXIST should also be returned in this case.
Anyway thanks for taking the time to consider this,
--
Jérémie Koenig
http://jk.fr.eu.org/
nce to our
particular problem, so I used it anyway.
I'll test the patch tomorrow and post the results,
--
Jérémie Koenig
http://jk.fr.eu.org/
From cc3b65cdb6fd96af6fb591f05f8cba206123d79c Mon Sep 17 00:00:00 2001
From: Jeremie Koenig
Date: Sun, 13 Jun 2010 17:20:48 +0200
Subject:
options mean, and a given
store can be specified in many different ways.
What do you think?
--
Jérémie Koenig
http://jk.fr.eu.org/
if (opt == SO_TYPE)
> + {
Maybe switch statements would be more future-friendly?
(just my 2 nitpicking cents)
--
Jérémie Koenig
http://jk.fr.eu.org/
On Wed, Jul 14, 2010 at 7:51 PM, Carl Fredrik Hammar
wrote:
> On Tue, Jul 13, 2010 at 08:00:24PM +0200, Jérémie Koenig wrote:
>> The second one, which I favor and am working on so far, would be to
>> enumerate the _grub_ devices, and use get_storage_info() on them too.
> (...)
b drive (usb
>> stick) will work.
>
> dd < mini.iso > /dev/sda
If your USB drive _is_ in fact /dev/sda, it should be added.
(Otherwise you'll just wipe out some hard drive)
Check out the 'dmesg' output to find out which device corresponds to
your USB drive.
--
Jérémie Koenig
http://jk.fr.eu.org/
port for process 1701: (ipc/send)
>> invalid destination port
>>
>> And this console message disappears:
>> task 520b4efc deallocating an invalid port 27260952, most probably a bug
For what it's worth, I see the same behavior with "gdb /bin/ps-hurd".
Package
ainst trying my patched hurd right now.
Alternatively, keep a copy of /lib/libpthread.so.0.3 somewhere and
have busybox ready.
--
Jérémie Koenig
http://jk.fr.eu.org/
on. Is
there really anything using it? (I was able to rebuild Hurd with the
new version.)
--
Jérémie Koenig
http://jk.fr.eu.org/
with corrected commit messages is available
here: https://github.com/jeremie-koenig/glibc
Please ignore f78f23d "use GLIBC_2.13_DEBIAN_8 for now".
--
Jérémie Koenig
http://jk.fr.eu.org/
On Wed, Jun 29, 2011 at 10:59 PM, Samuel Thibault
wrote:
> Jérémie Koenig, le Wed 29 Jun 2011 22:55:48 +, a écrit :
>> The old !SA_SIGINFO case was a non-standard (BSD-based?) extension. Is
>> there really anything using it?
>
> You can never know. And thus probably ha
;t support it. (Now whether there actually is such a
system which uses this file, I don't know.)
--
Jérémie Koenig
http://jk.fr.eu.org/
nding signals,
> but GNU/Hurd currently does not clear them. According to POSIX,
> exec() is supposed to not clear pending signals. So at least, spawn()
> inheriting pending signals is coherent in GNU/Hurd. Making fork() and
> spwan() clear pending signals would be a separate fix.
FL))
>>
>> This is not done any more. Actually I believe it is more correct.
>
> Note that this example still does not terminate after the patch, because
> ignored signals are never actually marked pending:
>
> (hurd/hurdsig.c)
> | if (act != ignore &&
onclusion or patch to fix them all.
Discussion:
http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00054.html
Patch to fix some of them:
http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00063.html
--
Jérémie Koenig
http://jk.fr.eu.org/
> What do people think about it?
It looks good to me, should not be too hard to implement as far as I
can tell, and the d-i boot image scripts would be trivial to update.
--
Jérémie Koenig
http://jk.fr.eu.org/
> sleeps (no, there aren't many threads in that test, just two dozen).
Could thread migration [1] maybe help with this?
[1] http://www.brynosaurus.com/pub/os/thread-migrate.pdf
--
Jérémie Koenig
http://jk.fr.eu.org/
ions/
Also, there is a "contributing" page on the Hurd wiki:
http://www.bddebian.com/~hurd-web/contributing/
--
Jérémie Koenig
http://jk.fr.eu.org/
le to upgrade
their system until they make the above modifications.
If you think this is too disruptive and the mirror should stay up for
the time being, please object now and I'll deploy my scripts[1] on the
new server.
[1] https://github.com/jeremie-koenig/hurd-installer-mirror
--
Jérémie Ko
t been as fast as I would have liked.
However I have started some of the work required to provide safe Java
bindings for Mach system calls.
See https://github.com/jeremie-koenig/hurd-java.
--
Jérémie Koenig
http://jk.fr.eu.org/
Hi,
As per [1], the weekly IRC meeting is tomorrow Wednesday at 19:00 UTC,
in the #hurd channel at irc.freenode.net. Everyone is invited to join
us and/or suggest topics for discussion.
[1] http://www.gnu.org/software/hurd/irc.html
See you tomorrow,
--
Jérémie Koenig
http://jk.fr.eu.org/
t things to do you might like.
--
Jérémie Koenig
http://jk.fr.eu.org/
2].
[1] http://www.gnu.org/software/hurd/hurd/running.html
[2] http://www.gnu.org/software/hurd/hurd/running/qemu.html
--
Jérémie Koenig
http://jk.fr.eu.org/
own to work; the
situation with the other repositories is a little bit messy.
(By the way if you or someone else would like to help sorting this
out, that would another possibility for a highly valuable and
appreciated contribution :-)
--
Jérémie Koenig
http://jk.fr.eu.org/
On Thu, Feb 16, 2012 at 11:19 PM, Ludovic Courtès wrote:
> Hi Jérémie,
Hi!
> Jérémie Koenig skribis:
>> [glibc source]
>> (By the way if you or someone else would like to help sorting this
>> out, that would another possibility for a highly valuable and
>
would be a great way to learn your way around the
codebase. (But of course it's just a suggestion and if you find
something you think is more appropriate feel free to ask us about it.)
--
Jérémie Koenig
http://jk.fr.eu.org/
2012/3/15 Ludovic Courtès :
> What about sending Hydra’s messages sent to commit-h...@gnu.org?
Good idea.
Also I've added commit-hurd to http://www.bddebian.com/~hurd-web/mailing_lists.
--
Jérémie Koenig
http://jk.fr.eu.org/
39 matches
Mail list logo
