> Have you looked at the script though? This is a really weird hack:
>
> exec 9<&0
> 9 isn't referenced anywhere else... it's not surprising that if you redirect a
> non-existant descriptor to 0, your fd 0 will be messed up. I wonder how this
> can possibly work on gnu/linux.
Yes, I looked
On Wed, Mar 15, 2006 at 05:25:41PM +0100, Petr Salinger wrote:
> Hi,
>
> screen does't work due to 64bit AND non-linux.
> With following fix it starts:
>
> --- osdef.h.in~ 2006-03-15 16:53:47.0 +0100
> +++ osdef.h.in 2006-03-15 16:53:47.0 +0100
> @@ -107,6 +107,7 @@
> extern cha
On Wed, Mar 15, 2006 at 05:25:41PM +0100, Petr Salinger wrote:
> --- osdef.h.in~ 2006-03-15 16:53:47.0 +0100
> +++ osdef.h.in 2006-03-15 16:53:47.0 +0100
> @@ -107,6 +107,7 @@
> extern char *tgoto __P((char *, int, int));
>
> #ifdef POSIX
> +#include
> extern int setsid __P
Hi,
screen does't work due to 64bit AND non-linux.
With following fix it starts:
--- osdef.h.in~ 2006-03-15 16:53:47.0 +0100
+++ osdef.h.in 2006-03-15 16:53:47.0 +0100
@@ -107,6 +107,7 @@
extern char *tgoto __P((char *, int, int));
#ifdef POSIX
+#include
extern int setsid
On Wed, Mar 15, 2006 at 02:41:38PM +0100, Petr Salinger wrote:
> Hi.
>
> > I found a bit more breakage in glibc for amd64.
>
> I am not sure which parts are due to
>
> - amd64
> - FreeBSD 6 in general
I didn't find any of these problems when using kfreebsd-6.0 on i386, so I think
we can discar
On Wed, Mar 15, 2006 at 02:14:19PM +0100, Robin Elfrink wrote:
> On a (just yesterday installed) FreeBSD 5.4 server I get (the binary is
> /usr/sbin/amavisd):
I don't think this is relevant, since we use the ps from procps (gnu/linux
utils).
> On my Debian GNU/kFreeBSD box I get (the binary is /u
Hi.
> I found a bit more breakage in glibc for amd64.
I am not sure which parts are due to
- amd64
- FreeBSD 6 in general
- kfreebsd-6 packaging without 900_devfs_perm_fixes.diff
- gdb 6.1.1 for native amd64/FreeBSD 6.0
> screen is accessing broken pointers. Sometimes it segfaults, sometimes
Robert Millan wrote:
>>I wouldn't be surprised if other perl-based daemons have this same problem.
>
>
> AFAIK the kernel is in charge to interpret shebang headers and run the
> corresponding interpreter, so it wouldn't be strange that Linux and kFreeBSD
> differ in some way.
>
> How does this
On Wed, Mar 15, 2006 at 12:14:09PM +0100, Robert Millan wrote:
>
> As a workaround, perhaps it'd be a good idea to remove network drivers from
> the
> kernel image. This shouldn't be a problem assuming kfreebsd-common works
> properly (a pre-requisite for this is Depending on kfreebsd-common, of
On Wed, Mar 15, 2006 at 10:33:29AM +0100, Petr Salinger wrote:
> > I've built CD installer images for kfreebsd-amd64.
>
> Many thanks.
>
> > The boot sequence is not as mature as in kfreebsd-i386 yet (fsck and ifup
> > segfault), but you should have no trouble in setting up network manualy or
> >
Hi,
I found a bit more breakage in glibc for amd64.
screen is accessing broken pointers. Sometimes it segfaults, sometimes it
modifies itself (it's pretty funny when it says /var/run/screen should be mode
777 instead of 775 ;).
ifup -a segfaults. Looking at the gdb backtrace it seems to be ca
Package: kfreebsd-5
Severity: normal
It seems that all modules are provided in the package, not just those that are
not in kernel.
This is not just a waste of space (they can't be loaded), but also disruptive
for tools like kfreebsd-common, which make a list of modules that can be loaded
and pres
> I've built CD installer images for kfreebsd-amd64.
Many thanks.
> The boot sequence is not as mature as in kfreebsd-i386 yet (fsck and ifup
> segfault), but you should have no trouble in setting up network manualy or
> via dhclient.
ifup segfaults can be easily fixed - just rebuild ifupdown 0.
13 matches
Mail list logo
