Quoting Svante Signell (2013-09-17 21:10:17)
On Tue, 2013-09-17 at 19:59 +0200, Samuel Thibault wrote:
Hello,
I have uploaded another snapshot of the hurd package. It notably
includes Justus' mtab translator, so that the df bug is no more!
Great! For me df misses the home directory:
On Wed, Sep 18, 2013 at 12:55:53PM +0200, Justus Winter wrote:
That's weird. Care to share cat /proc/mounts?
Same issue on darnassus :
$ cat /proc/mounts
/dev/hd0s1 / ext2fs writable,no-inherit-dir-group,store-type=typed 0 0
none /servers/socket/26 /hurd/pfinet
On Wed, 2013-09-18 at 12:55 +0200, Justus Winter wrote:
Quoting Svante Signell (2013-09-17 21:10:17)
On Tue, 2013-09-17 at 19:59 +0200, Samuel Thibault wrote:
Hello,
I have uploaded another snapshot of the hurd package. It notably
includes Justus' mtab translator, so that the df
Hey,
I really like to get owncloud-client running in hurd. Two build-deps are not
build in hurd.
till now building ocsync fails with [1]:
src/csync_misc.c: In function 'csync_get_user_home_dir':
src/csync_misc.c:91:15: error: 'PATH_MAX' undeclared (first use in this
function)
char
Hi,
I've had some time to experiment on Debian GNU/Hurd and I tried to set up a
murmurd (Mumble Server).
Since the required zeroc-ice libraries can't be built at the moment, I tried to
build murmurd from the current Mumble Git and these options to qmake:
qmake -recursive main.pro
Jens Mühlenhoff, le Thu 19 Sep 2013 01:55:24 +0200, a écrit :
is returning errno = 1073741865 which is ESPIPE?!
Err, no, it's 0x4029, i.e. _HURD_ERRNO(41), i.e. EPROTOTYPE.
I think that translates to socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0)
Yes. SOCK_CLOEXEC is not currently
Hello,
/proc is not mounted any more after Debian GNU/Hurd installation. This
happens because grub-installer does
if ! umount $ROOT/proc; then
right after having set up itself in the MBR. Justus, I guess the
sysvinit bootup would mount it at boot? If so we can as well mount it
from
Am 19.09.2013 02:06, schrieb Samuel Thibault:
Jens Mühlenhoff, le Thu 19 Sep 2013 01:55:24 +0200, a écrit :
is returning errno = 1073741865 which is ESPIPE?!
Err, no, it's 0x4029, i.e. _HURD_ERRNO(41), i.e. EPROTOTYPE.
Yes of course, I mixed up hexadecimal and decimal, it's getting late
Jens Mühlenhoff, le Thu 19 Sep 2013 02:18:28 +0200, a écrit :
Yes. SOCK_CLOEXEC is not currently supported, the TCP/IP stack thinks
the caller is inventing a new proto type numbered 4194305. You would
get the same behavior on Linux when building the application against a
recent libc, but
On Thu, 2013-09-19 at 02:33 +0200, Samuel Thibault wrote:
Jens Mühlenhoff, le Thu 19 Sep 2013 02:18:28 +0200, a écrit :
Yes. SOCK_CLOEXEC is not currently supported, the TCP/IP stack thinks
the caller is inventing a new proto type numbered 4194305. You would
get the same behavior on Linux
On Thu, 2013-09-19 at 05:38 +0200, Svante Signell wrote:
I was wondering why the Qt code is using (fd != -1 || errno != EINVAL) to
determine success?
Because Linux probably returns EINVAL instead of EPROTOTYPE in such an
error case.
You can solve this problem with a code
11 matches
Mail list logo