On Fri, Aug 27, 2010 at 01:51:09AM +0200, Emilio Pozuelo Monfort wrote:
On 22/08/10 11:18, olafbuddenha...@gmx.net wrote:
I guess we will soon need to come up with a new meeting schedule, now
that the summer session is almost over: go back to meeting once a week;
and probably account for
Hi,
On Sun, Aug 22, 2010 at 11:18:41AM +0200, olafbuddenha...@gmx.net wrote:
First of all, I'm not sure I will be able to make it to the meeting
tomorrow. (Am at FrOSCon right now :-) ) But as usual, that shouldn't
stop the others from meeting.
Sure, have a good time. :-)
I guess we will
Hi,
On Wed, Aug 11, 2010 at 07:04:17PM -0300, Diego Nieto Cid wrote:
Hi,
2010/8/9 olafbuddenha...@gmx.net:
Hm, why tmp[5]? The way I read the code, only 4 entries are used...
Well it's the null that terminates the string. But as this isn't used
as a string it probably does not make
Hi,
On Tue, Jul 27, 2010 at 08:22:14PM +0200, olafbuddenha...@gmx.net wrote:
On Wed, Jul 14, 2010 at 07:51:07PM +0200, Carl Fredrik Hammar wrote:
On Tue, Jul 13, 2010 at 08:00:24PM +0200, Jérémie Koenig wrote:
The first one would be to make part.c embed extra information in its
stores
Hi,
On Tue, Jul 27, 2010 at 08:08:36PM +0200, Emilio Pozuelo Monfort wrote:
This patch adds support for SCM_RIGHTS to glibc. It works fine
when sending file descriptors from a socket() or a socketpair() call,
but not from e.g. an open() call, as I've mentioned in another mail.
That's not
Hi,
On Mon, Jul 26, 2010 at 07:32:04PM +0200, Emilio Pozuelo Monfort wrote:
@@ -159,14 +193,28 @@ diskfs_S_file_exec (struct protid *cred,
do
{
right = ports_get_send_right (newpi);
- err = exec_exec (execserver,
-right,
Hi,
On Mon, Jul 26, 2010 at 07:42:25PM +0200, Emilio Pozuelo Monfort wrote:
Also I've tested with the Debian package (which is at 2.11.2) so I
needed to change the Versions file. I changed it to 2.11.2, but I
got quite some warnings that GLIBC_2_11_2 was undefined. I changed
it to 2_11 and it
Hi,
On Mon, Jul 26, 2010 at 07:28:42PM +0200, Emilio Pozuelo Monfort wrote:
New iteration. All mentioned issues have been fixed, except for the glibc
check
for the file_exec_file_name RPC, which I don't know how to do if not using
HURD_INTERFACE_VERSION. Any suggestions are welcome.
I have
Hi,
On Mon, Jul 26, 2010 at 07:33:58PM +0200, Emilio Pozuelo Monfort wrote:
From c6276e2df1d370dbbdd7f4e6fb388f241f84fee7 Mon Sep 17 00:00:00 2001
From: Emilio Pozuelo Monfort poch...@gmail.com
Date: Wed, 26 May 2010 23:32:16 +0200
Subject: [PATCH 3/3] Use the new _hurd_exec_file_name
Hi,
On Thu, Jul 22, 2010 at 12:16:08PM +0200, olafbuddenha...@gmx.net wrote:
I realized that my problems with pfinet crashing after apt-get fetching
~90 MB of packages, are due to a gaping virtual memory leak in pfinet.
(Probably the same one Samuel fixed recently; but I haven't tested his
On Fri, Jul 16, 2010 at 12:15:06PM +0200, Emilio Pozuelo Monfort wrote:
From 3804a36fcf95a3fd588ce67a08a36346134b8d1f Mon Sep 17 00:00:00 2001
From: Emilio Pozuelo Monfort poch...@gmail.com
Date: Wed, 26 May 2010 01:27:40 +0200
Subject: [PATCH 2/3] Add a file_exec_file_name RPC
*
On Fri, Jul 16, 2010 at 12:17:38PM +0200, Emilio Pozuelo Monfort wrote:
Note that this patch should only be applied after the glibc patch is applied,
and maybe some time later (perhaps after a stable release shipping it?).
I think the commit order will need to be brought up at today's meeting.
On Fri, Jul 16, 2010 at 12:21:16PM +0200, Emilio Pozuelo Monfort wrote:
And here goes the glibc one.
Regards,
Emilio
2010-07-16 Emilio Pozuelo Monfort poch...@gmail.com
* hurd/hurdexec.c (_hurd_exec): Deprecate it.
(_hurd_exec_file_name): New function.
* hurd/hurd.h:
On Fri, Jul 16, 2010 at 12:19:21PM +0200, Emilio Pozuelo Monfort wrote:
From 03b291be17be4beb67d7397526c1ae7c292649df Mon Sep 17 00:00:00 2001
From: Emilio Pozuelo Monfort poch...@gmail.com
Date: Thu, 15 Jul 2010 20:37:20 +0200
Subject: [PATCH] Bump HURD_INTERFACE_VERSION
*
Hi,
On Sat, Jul 17, 2010 at 02:07:19PM +0200, Guillem Jover wrote:
On Fri, 2010-07-16 at 12:21:16 +0200, Emilio Pozuelo Monfort wrote:
And here goes the glibc one.
diff --git a/hurd/hurd.h b/hurd/hurd.h
index 642ea43..a83c3fa 100644
--- a/hurd/hurd.h
+++ b/hurd/hurd.h
@@ -243,13
On Sat, Jul 17, 2010 at 12:25:48PM +0200, Carl Fredrik Hammar wrote:
Hi,
On Sat, Jul 17, 2010 at 11:37:34AM +0200, Emilio Pozuelo Monfort wrote:
+ *(int*)*value = user-sock-pipe_class-sock_type;
+ *value_len = sizeof (int);
+ break;
+ default:
+ ret = ENOPROTOOPT
On Sat, Jul 17, 2010 at 03:36:43PM +0200, Ludovic Courtès wrote:
Emilio Pozuelo Monfort poch...@gmail.com writes:
error_t
S_socket_getopt (struct sock_user *user,
int level, int opt,
char **value, size_t *value_len)
{
- return EOPNOTSUPP;
+ int ret =
Hi,
On Thu, Jul 15, 2010 at 05:15:25PM +0200, Emilio Pozuelo Monfort wrote:
On 15/07/10 17:05, Emilio Pozuelo Monfort wrote:
On 15/07/10 16:49, Emilio Pozuelo Monfort wrote:
Here it goes, with a good commit message:
Forgot to add the file before committing :(
Also check that the
Hi,
On Tue, Jul 13, 2010 at 08:00:24PM +0200, Jérémie Koenig wrote:
The first one would be to make part.c embed extra information in its
stores and their encoded form (possibly in the misc fiels of a remap
store). This would force it to create a new layer instead of reusing
the underlying
Hi,
On Tue, Jul 13, 2010 at 03:23:51AM +0200, Arne Babenhauserheide wrote:
They have some very interesting translators, and these should be easily
available.
And easily doesn’t mean cvs :)
Yeah, definitaly.
Should all be in one repository with different subfolders or should each
On Mon, Jul 12, 2010 at 08:41:49AM +0200, Arne Babenhauserheide wrote:
What is missing for you?
Sound support, wireless, and PPPoE. I could probably factor out these
to a seperate router/sound box but at that point I might as well just
run Hurd in in kvm and use the host as the support box,
Hi,
On Mon, Jul 12, 2010 at 03:24:53PM +0200, Arne Babenhauserheide wrote:
Are the hurdextras already in git?
No, only unionfs: http://git.savannah.gnu.org/cgit/hurd/unionfs.git/.
They have some very interesting translators, and these should be easily
available.
And easily doesn’t mean
On Mon, Jul 05, 2010 at 01:23:15PM -0700, Roland McGrath wrote:
This would be ideal, but my current understanding is that
interrupt_operation() is mostly advisory and that the operation will
restart or return EINTR regardless of what the server does, and if this
is true then it is
Hi,
On Sun, Jul 04, 2010 at 12:34:19PM -0700, Roland McGrath wrote:
The auth server, like any server handling interrupt_operation, is
responsible for making sure that the operation either is entirely
interrupted cleanly, or completes normally. For the auth handshake,
interrupting cleanly
Hi,
On Sat, Jul 03, 2010 at 04:11:37PM +0200, Thomas Schwinge wrote:
What's the status of the other GSoC projects?
Well, progress on the test cases have ground to a halt the last couple of
weeks due to exams. However, progress up to the exam period was good,
and Emilio will be back late next
Hello,
I have been investigating the EINTR bug for a while now, and I'm finally
confident about what the problem is. As a reminder, the bug causes sudo
to sometimes fail with EPERM, usually when it tries to open /etc/sudoers
because a reauthentication has failed silently.
While we originally
Hi,
On Mon, Jun 14, 2010 at 09:00:05AM +0200, olafbuddenha...@gmx.net wrote:
or that modifying Mach for this purpose is misguided and should be
avoided (for instance by embedding the initrd in a dedicated section
of an elf module).
Hm... I don't remember this variont actually being
On Mon, Jun 14, 2010 at 10:33:49AM +0200, Samuel Thibault wrote:
Carl Fredrik Hammar, le Mon 14 Jun 2010 10:22:26 +0200, a écrit :
(For instance, it might be possible to make Mach create a task without
thread if it can't execute the image, then you could just read this task
with the task
On Mon, Jun 14, 2010 at 10:49:42AM +0200, Samuel Thibault wrote:
Carl Fredrik Hammar, le Mon 14 Jun 2010 10:47:15 +0200, a écrit :
Is there such a thing as a task ID though? I thought tasks can only
referenced by ports?
Replace task id with port ID in my sentence then. Whatever
Follow-up Comment #1, bug #30096 (project hurd):
As suggested by antrik, the number of threads also explodes when you kill
the execing process. Perhaps the increase in memory usage is because
of this.
Also, I did a quick check to see if Sergio's sync patches magically
fixes this, but they did
Follow-up Comment #2, bug #30096 (project hurd):
Ports are leaked on execve(), most likely in the exec server. If any
of these ports goes to ext2fs, this would explain this bug. I have
attached a program which prints the number of leaks (7).
(file #20726)
URL:
http://savannah.gnu.org/bugs/?30096
Summary: ext2fs leaks memory on multiple execs from same
process
Project: The GNU Hurd
Submitted by: hammy
Submitted on: Wed 09 Jun 2010 04:15:13 PM CEST
Category: Hurd
Hi,
On Thu, Jun 03, 2010 at 06:55:12AM +0200, olafbuddenha...@gmx.net wrote:
On Wed, Jun 02, 2010 at 06:35:02PM +0200, Carl Fredrik Hammar wrote:
On Wed, Jun 02, 2010 at 12:17:12AM +0200, olafbuddenha...@gmx.net
wrote:
I'm a bit ambivalent about this... On one hand, returning the right
* auth/auth.c (S_auth_user_authenticate, S_auth_server_authenticate):
Fail with EINVAL if RENDEZVOUS is MACH_PORT_NULL.
---
Hi,
This patch makes the auth server fail with EINVAL if the rendezvous port
is null.
I don't really think this needs much motivation but then again I
also didn't think
* tmpfs/dir.c (diskfs_direnter_hard): Fix malloc size.
---
Hello,
Found this little doozy while examining Sergio's patches. ENTSIZE was
changed back in 2f7f90ce to reflect the size of a struct dirent instead
of a tmpfs_dirent, but NEW is still a tmpfs_dirent... I just snatched
the old code
On Thu, May 20, 2010 at 12:18:44AM +0200, Sergio Lopez wrote:
El Wed, 19 May 2010 23:32:37 +0200
Samuel Thibault samuel.thiba...@gnu.org escribió:
Sergio Lopez, le Wed 19 May 2010 17:33:39 +0200, a écrit :
El Wed, 19 May 2010 16:05:27 +0200
Carl Fredrik Hammar hammy.l...@gmail.com
Hi,
On Wed, Jun 02, 2010 at 12:00:13AM +0200, olafbuddenha...@web.de wrote:
Keep in mind that this convention stems from a time where people
actually used to *print* code, on a 80 column line printer... So it was
important to strictly observe the limit back then. Nowadays, screens are
large
Hi,
On Wed, Jun 02, 2010 at 12:17:12AM +0200, olafbuddenha...@gmx.net wrote:
I'm a bit ambivalent about this... On one hand, returning the right
error code right away is probably less confusing; but on the other hand,
it adds extra code paths (with all the associated disadvantages) for
Hi,
On Tue, Jun 01, 2010 at 03:52:59AM +0200, olafbuddenha...@gmx.net wrote:
On Mon, May 31, 2010 at 05:59:09PM +0200, Carl Fredrik Hammar wrote:
On Wed, May 26, 2010 at 12:15:37AM +0200, Emilio Pozuelo Monfort wrote:
+kern_return_t
+S_exec_exec_file_name (struct trivfs_protid *protid
Hi,
On Tue, Jun 01, 2010 at 03:50:26AM +0200, olafbuddenha...@gmx.net wrote:
On Mon, May 31, 2010 at 06:16:06PM +0200, Carl Fredrik Hammar wrote:
On Sat, May 22, 2010 at 06:26:29PM +0200, Emilio Pozuelo Monfort wrote:
+ err = __file_exec_file_name (file, task, flags
* auth/auth.c (S_auth_user_authenticate,S_auth_server_authenticate):
Return EINVAL if rendezvous port dies during transaction.
---
Hello,
This is a patch for the auth server to make it also return EINVAL when
the rendezvous port has died during a transaction and not only if it is
dead on
Hi,
On Wed, May 26, 2010 at 01:27:40AM +0200, Emilio Pozuelo Monfort wrote:
diff --git a/exec/hashexec.c b/exec/hashexec.c
index 6be8dfe..c2d0f7d 100644
--- a/exec/hashexec.c
+++ b/exec/hashexec.c
@@ -420,15 +420,28 @@ check_hashbang (struct execdata *e,
return;
/* Execute the
Hi,
On Wed, May 26, 2010 at 11:32:16PM +0200, Emilio Pozuelo Monfort wrote:
diff --git a/utils/fakeauth.c b/utils/fakeauth.c
index 49fa7f1..ccc0855 100644
--- a/utils/fakeauth.c
+++ b/utils/fakeauth.c
@@ -1,5 +1,5 @@
/* fakeauth -- proxy auth server to lie to users about what their IDs are
Hi,
On Sat, May 22, 2010 at 06:26:29PM +0200, Emilio Pozuelo Monfort wrote:
diff --git a/hurd/Versions b/hurd/Versions
index 83c8ab1..81cd904 100644
--- a/hurd/Versions
+++ b/hurd/Versions
@@ -73,6 +73,7 @@ libc {
_hurd_critical_section_unlock;
_hurd_exception2signal;
Hi,
I have reviewed the patches and apart from formatting there were only
a couple of issues. Next iteration is hopefully the last.
On Thu, May 27, 2010 at 06:22:26PM +0200, Emilio Pozuelo Monfort wrote:
On 25/05/10 21:10, Carl Fredrik Hammar wrote:
It would also be good if you always
On Wed, May 26, 2010 at 12:15:37AM +0200, Emilio Pozuelo Monfort wrote:
diff --git a/exec/exec.c b/exec/exec.c
index 272b789..6b0f721 100644
--- a/exec/exec.c
+++ b/exec/exec.c
@@ -1,5 +1,5 @@
/* GNU Hurd standard exec server.
- Copyright (C) 1992,93,94,95,96,98,99,2000,01,02,04
+
Hi,
On Mon, May 31, 2010 at 06:27:29PM +0200, Carl Fredrik Hammar wrote:
Regarding version.h, I've bumped HURD_INTERFACE_VERSION in 0001 for
exec_exec_file_name, but should it be bumped in 0002 too?
This sounds good to me but if someone else objects you should change it.
antrik
On Tue, May 25, 2010 at 11:30:07PM +0200, Samuel Thibault wrote:
Emilio Pozuelo Monfort, le Tue 25 May 2010 23:03:43 +0200, a écrit :
Oh, I haven't noticed this file before. :-)
It's the list of symbols libc.so should export. Since _hurd_exec is a public
API, I guessed _file_name
On Wed, May 26, 2010 at 01:39:24AM +0200, Emilio Pozuelo Monfort wrote:
On 25/05/10 21:10, Carl Fredrik Hammar wrote:
@@ -278,7 +280,9 @@ check_hashbang (struct execdata *e,
else
name = argv;
-if (strchr (name, '/') != NULL)
+if (filename
Hi,
On Tue, May 25, 2010 at 11:03:43PM +0200, Emilio Pozuelo Monfort wrote:
The first three patches are pretty useless on their own, they all affect
the same program, and most changes are pretty mechanical, so I think
you might as well merge them.
OK. I thought about going step by step
On Wed, May 26, 2010 at 12:29:06PM +0200, Emilio Pozuelo Monfort wrote:
On 26/05/10 09:32, olafbuddenha...@gmx.net wrote:
On Mon, May 24, 2010 at 12:08:10PM +0200, Emilio Pozuelo Monfort wrote:
Basically the problem is that in some cases the exec server can't find
the file name of the
On Wed, May 26, 2010 at 09:42:05AM +0200, olafbuddenha...@gmx.net wrote:
I've commented on every hunk to make sure I looked through it all,
which makes it a bit long but hopefully easy to follow (complain if it
isn't).
Well, it certainly does make it pretty redundant...
I prioritized
Hi,
On Wed, May 26, 2010 at 10:25:49AM +0200, olafbuddenha...@gmx.net wrote:
On Tue, May 25, 2010 at 10:49:16AM +0200, Carl Fredrik Hammar wrote:
Emilio reported that `fakeroot --version' (fakeroot-hurd in Debian)
prints out `STANDARD_HURD_VERSION_uptime_' instead of its version. The
bug
Hi,
On Tue, May 25, 2010 at 09:10:57PM +0200, Carl Fredrik Hammar wrote:
On Mon, May 24, 2010 at 12:08:10PM +0200, Emilio Pozuelo Monfort wrote:
diff --git a/exec/hashexec.c b/exec/hashexec.c
index 2aa3844..7a7b329 100644
--- a/exec/hashexec.c
+++ b/exec/hashexec.c
@@ -35,6 +35,7
Hi!
On Wed, May 26, 2010 at 07:07:54PM +0200, Thomas Schwinge wrote:
I'm totally fine with patches being checked in after there's some
consensus that they are what we want. This applies to this easy one, but
likewise applies to those that Sergio has posted, for example.
Sounds good!
Hi,
Emilio reported that `fakeroot --version' (fakeroot-hurd in Debian)
prints out `STANDARD_HURD_VERSION_uptime_' instead of its version.
The bug is due to a faulty make rule which depends on the original
sed script which inserted the correct version but was later inlined
into Makeconf itself
Hi,
On Mon, May 24, 2010 at 12:08:10PM +0200, Emilio Pozuelo Monfort wrote:
These are a series of patches to fix https://savannah.gnu.org/bugs/?28934
Basically the problem is that in some cases the exec server can't find the
file
name of the file being executed (when it's a script), and
On Tue, May 18, 2010 at 05:36:19PM +0200, Sergio Lopez wrote:
El Tue, 18 May 2010 16:33:59 +0200
Carl Fredrik Hammar hammy.l...@gmail.com escribió:
along with another one that fixes symlinks. Perhaps you could adopt
that patch as well and try to get it checked in since you're already
URL:
http://savannah.gnu.org/bugs/?29914
Summary: *_reply.defs can't handle error replies due to type
checks
Project: The GNU Hurd
Submitted by: hammy
Submitted on: Wed 19 May 2010 02:05:14 PM CEST
Category: GNU MIG
On Tue, May 18, 2010 at 04:19:34PM +0200, Sergio Lopez wrote:
This patch adds some padding to tmpfs_dirent structure as it's
suggested in the wiki
(http://www.gnu.org/software/hurd/hurd/translator/tmpfs.html).
It seems Samuel beat you to it back in January: see commit 97c569.
Regards,
Hi,
On Tue, May 18, 2010 at 04:19:34PM +0200, Sergio Lopez wrote:
This patch adds some padding to tmpfs_dirent structure as it's
suggested in the wiki
(http://www.gnu.org/software/hurd/hurd/translator/tmpfs.html).
diff -du hurd-deb.orig/tmpfs/tmpfs.h hurd/tmpfs/tmpfs.h
---
Follow-up Comment #2, bug #29809 (project hurd):
Here is what happens with a settrans -ac foo; ls foo:
0 Client does a dir_lookup(foo) on CWD, presumably on ext2fs
0 ext2fs does a fsys_getroot() on firmlink
0 firmlink does a dir_lookup(foo) on (same) CWD
0 Back to (2)
The important bit is that
Follow-up Comment #4, bug #29655 (project hurd):
This has already been said on IRC but I might as well repeat it here:
POSIX.1-2008 says that only `AT_SYMLINK_FOLLOW` is applicable to linkat()
(see http://www.opengroup.org/onlinepubs/9699919799/functions/linkat.html).
I would recommend testing
Follow-up Comment #2, bug #29655 (project hurd):
The patch looks good, but I do have two minor suggestions.
First, I found the comment a bit confusing. The default behavior is
determined by the O_NOLINK flag, and isn't something that is constant.
So perhaps you could change it to mention this,
Follow-up Comment #2, bug #29642 (project hurd):
Yes, it is reproducible with cthreads.
In fact, I encountered the bug while debugging a cthreads program.
(I knew I forgot to mention something...)
I just now also confirmed that it is reproducible with a minimal example
to make sure it wasn't
URL:
http://savannah.gnu.org/bugs/?29642
Summary: gdb: breakpoints in triggered in other threads
result in SIGTRAP
Project: The GNU Hurd
Submitted by: hammy
Submitted on: Thu 22 Apr 2010 04:38:30 PM CEST
Category: None
Hello,
On Tue, Apr 20, 2010 at 08:49:16AM +0200, olafbuddenha...@gmx.net wrote:
I'm still not convinced that this is a good idea in general. Private
namespaces always make things somewhat intransparent IMHO.
I agree, unless perhaps it is obviously private, e.g. /proc/self.
Well,
Hi,
On Sat, Apr 17, 2010 at 10:54:37AM +0200, Patrik Olsson wrote:
On Fri, 2010-04-16 at 11:52 +0200, Carl Fredrik Hammar wrote:
On Thu, Apr 15, 2010 at 10:47:49PM +0200, Patrik Olsson wrote:
3. Is it possible to have one translator working on two nodes at
the same time
Hello,
On Sun, Apr 18, 2010 at 04:27:28AM +0200, olafbuddenha...@gmx.net wrote:
Nah, I think you are right. Systems that provide private namespaces
(beyond chroot) -- which most notably includes Plan9, but also Linux
nowadays -- do so per-process rather than per-user. So a user gets a
Hello,
On Thu, Apr 15, 2010 at 10:47:49PM +0200, Patrik Olsson wrote:
To design HPM (Hurd Package Manager) I need answers to the following
questions (at least to begin with):
1. Is it possible for an unprivileged user to override the
translator of a node with another translator
Follow-up Comment #12, bug #28934 (project hurd):
The patch looks good, but I have a couple of suggestions.
In __execve you cannot just call _hurd_exec_file_name unconditionally
since all exec() variants end up as a __execve(). For instance,
if there is both `/bin/foo' and `./foo', execpv(foo,
On Fri, Apr 16, 2010 at 01:59:16PM +0200, Samuel Thibault wrote:
Carl Fredrik Hammar, le Fri 16 Apr 2010 11:52:04 +0200, a écrit :
2. If yes on question 1, would this be insecure? For example, if
the user overrides a library used by a setuid program? (Then
again
Hello,
On Mon, Apr 12, 2010 at 01:45:50PM +0200, olafbuddenha...@gmx.net wrote:
(I guess it *might* make sense to special-case a 0 size, if the caller
simply
is not interested in any additional data -- though I'm not sure that's ever
useful. But other cases are definitely bogus.)
It's not
Hello,
On Sun, Apr 11, 2010 at 11:01:20PM +0200, Arne Babenhauserheide wrote:
Am Samstag, 10. April 2010 09:49:02 schrieb olafbuddenha...@gmx.net:
Now we need to find mentors. So far only Samuel and me have signed up
for some of the projects; but in case we get more than one slot, it is
Hi,
On Sat, Apr 10, 2010 at 09:49:02AM +0200, olafbuddenha...@gmx.net wrote:
So please sign up as a mentor for the GNU organisation at
http://socghop.appspot.com/gsoc/mentor/request/google/gsoc2010/gnuproject
and sign up for those projects you would feel comfortable mentoring :-)
OK,
On Sat, Apr 10, 2010 at 12:35:32PM +0200, Carl Fredrik Hammar wrote:
On Sat, Apr 10, 2010 at 09:49:02AM +0200, olafbuddenha...@gmx.net wrote:
So please sign up as a mentor for the GNU organisation at
http://socghop.appspot.com/gsoc/mentor/request/google/gsoc2010/gnuproject
Hello,
I'm going to post 2 patches that implements a new useful feature to
settrans. The first one exposes needed functionallity in libfshelp
and the second one implements the feature. More info in the patch
mails themselves.
(This is the first time I'm trying `tg mail' so please bear with me
Hello,
This patch prepares libfshelp's function service_fsys_startup for use
elsewhere. It just moves the function to its own file and prefixes
its name with fshelp_. I also took the liberty of moving its one out
parameter to the end of the parameter list, and pruning out headers
which are no
Hello,
this patch adds a new option to settrans: --interactive. The main use
case is to be able to start a translator under gdb like so:
settrans -i /tmp/foo gdb /hurd/hello
This is extremely useful if the translator crashes before the startup
handshake, but also just plain more convenient
URL:
http://savannah.gnu.org/bugs/?29463
Summary: Translators output garbage when started with
settrans -P and stopped by gdb
Project: The GNU Hurd
Submitted by: hammy
Submitted on: Wed 07 Apr 2010 08:54:08 PM CEST
Follow-up Comment #9, bug #28934 (project hurd):
I don't see how the regression is possible given that the changes
to the exec server should only affect shell scripts not C programs.
Also your patch to glibc doesn't actually make use of _hurd_exec_file_name,
which makes the above even more
Hi,
On Thu, Mar 11, 2010 at 03:33:56PM +0100, olafbuddenha...@gmx.net wrote:
On Thu, Mar 11, 2010 at 01:18:05PM +0100, Carl Fredrik Hammar wrote:
On Thu, Mar 11, 2010 at 05:12:47AM +0100, olafbuddenha...@gmx.net
wrote:
Thanks for both the content enhancements, and for catching all
Hi,
On Thu, Mar 11, 2010 at 05:12:47AM +0100, olafbuddenha...@gmx.net wrote:
On Wed, Mar 10, 2010 at 02:43:35PM +0100, Thomas Schwinge wrote:
On Wed, Mar 10, 2010 at 08:02:30AM +0100, olafbuddenha...@gmx.net
wrote:
The results of my labour are available from
.
Carl Fredrik Hammar invalid.nore...@gnu.org writes:
[...]
The reason argv[0] is expanded is because it is passed as an argument
to the interpreter, otherwise the interpreter can't find it.
Because the exec server is passed an already opened port to the
executable, it doesn't
On Sat, Feb 27, 2010 at 09:40:55PM +0600, Ivan Shmakov wrote:
Giving them new names, e.g. _hurd_exec_path, might be a good idea to
avoid incompatibilities,
FWIW, this seems to be the most reasonable solution to me.
But note that there's a slight terminology issue here:
--cut:
Follow-up Comment #4, bug #28934 (project hurd):
I researched further how argv[0] is supposed to be handled and have a
much firmer grasp on the situation now.
argv[0] is only expanded to path to the executed file when the executed
file is a #!-script. This means that touching argv[0] in
Follow-up Comment #6, bug #28934 (project hurd):
The reason argv[0] is expanded is because it is passed as an argument
to the interpreter, otherwise the interpreter can't find it.
Unless it is a relative path, of course.
I did mean any path, relative or not. What's important is that
Follow-up Comment #2, bug #28934 (project hurd):
Hi Emilio,
I'm pretty sure you are correct in that execve() should not look in $PATH,
because glibc's sysdeps/mach/hurd/execve.c does a regular file lookup.
As you say the exec server gets confused since it does not find bar in
$PATH, and tries
Hi,
On Sun, Aug 30, 2009 at 02:50:05PM +0200, olafbuddenha...@gmx.net wrote:
On Wed, Aug 26, 2009 at 02:19:28PM +0200, Carl Fredrik Hammar wrote:
diff --git a/hurd/lookup-retry.c b/hurd/lookup-retry.c
index 96968f8..ce9eaf0 100644
--- a/hurd/lookup-retry.c
+++ b/hurd/lookup-retry.c
Hi,
On Mon, Aug 31, 2009 at 09:46:03PM +0200, olafbuddenha...@gmx.net wrote:
On Wed, Aug 26, 2009 at 02:17:21PM +0200, Carl Fredrik Hammar wrote:
This is an obvious fix to glibc that makes it easier to change
`ioctl_handler_t'.
Note that while we can help reviewing glibc patches
Hi
On Wed, Feb 10, 2010 at 12:34:21PM +0100, Thomas Schwinge wrote:
As for the thesis itself: I read it (while waiting for the train home
from FOSDEM -- I had some hours to spend there), and I liked it! :-)
And I'm glad you liked it! :-)
And, as far as I know, it's the first real
Hi,
On Tue, Feb 09, 2010 at 11:41:25AM +0100, Jakub Daniel wrote:
It's been some time since I last attempted to run Hurd.. Now I installed
hurd under kvm and found out that the networking actually worked in it.. so
I happily installed grub2 from repositories but unfortunately unlike last
time
On Tue, Feb 09, 2010 at 05:36:31PM +0100, Samuel Thibault wrote:
Jakub Daniel, le Tue 09 Feb 2010 17:21:39 +0100, a écrit :
It didnt work for me :(, it still complains about not having the list of
partitions...
IIRC there's such warning but it's just a warning, the command still
completed
Follow-up Comment #2, bug #28779 (project hurd):
So it is clear that ext2fs (or possibly libstore)
has messed up encoding the blocks of the file, but I
can't really tell what's wrong ATM. Possibly this
could be a general bug in how ext2fs manages holes
in files, so it should be further
On Sat, Feb 06, 2010 at 04:59:56PM +0100, Michael Banck wrote:
On Fri, Jan 29, 2010 at 02:53:04PM +0100, Carl Fredrik Hammar wrote:
For now it is available from my personal web page provided by my uni:
http://users.student.lth.se/cs07fh9/2009-hammar-hurd-mobility.pdf
but I don't know how
Follow-up Comment #3, bug #28779 (project hurd):
I have attached a patch that makes diskfs_S_file_get_storage_info in
ext2fs return EOPNOTSUPP if the file is sparse. It also removes any
code used for hole mapping, which is now dead.
It works for me (TM).
(file #19634)
Hi,
On Sat, Jan 09, 2010 at 07:10:30PM +0100, olafbuddenha...@gmx.net wrote:
On Thu, Jan 07, 2010 at 04:45:57PM +0100, Carl Fredrik Hammar wrote:
On Mon, Jan 04, 2010 at 03:34:07PM +0100, olafbuddenha...@gmx.net
wrote:
On a technical side, you have to decide what error code MiG should
Follow-up Comment #1, bug #28779 (project hurd):
The situation here is that the ext2fs instance
that contains blip returns a store to the new
ext2fs instance that is a copy of its own store
but with the blocks that contain blip mapped out.
The problem is that ext2fs maps them out wrongly.
First
On Fri, Feb 05, 2010 at 11:30:17PM +0100, Samuel Thibault wrote:
Carl Fredrik Hammar, le Fri 05 Feb 2010 22:28:00 +, a écrit :
In fact, it is impossible to map out the blocks of
a file hole without actually allocating the blocks,
which defeats the purpose of the hole. Instead, I
URL:
http://savannah.gnu.org/bugs/?28794
Summary: ps segfaults when given empty format string
Project: The GNU Hurd
Submitted by: hammy
Submitted on: Tue 02 Feb 2010 06:33:41 PM CET
Category: Hurd
1 - 100 of 260 matches
Mail list logo
