Re: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff

2014-04-06 Thread Emilio Pozuelo Monfort
On 07/04/14 00:26, Justus Winter wrote: > Hi, > > Quoting Samuel Thibault (2014-04-06 21:25:42) >> Justus Winter, le Sun 06 Apr 2014 19:58:45 +0200, a écrit : >>> I'd like to see more of the debian/patches merged, especially the >>> exec_filename_* series. >> >> The discussion about it with Roland

Re: GNU/Hurd DDE talk at FOSDEM

2014-02-01 Thread Emilio Pozuelo Monfort
On 01/02/14 10:34, Samuel Thibault wrote: > Samuel Thibault, le Fri 31 Jan 2014 18:35:44 +0100, a écrit : >>> I look forward to watching the recorded video :-) >> >> I'm afraid there is usually no video of the microkernel room. > > Actually all rooms will be recorded :D (except the Java room) Coo

Re: [PATCH] libports: implement lockless management of threads

2013-11-13 Thread Emilio Pozuelo Monfort
On 12/11/13 20:13, Samuel Thibault wrote: > Hello, > > OK, I believe that'll work indeed. What really makes it work is this: > > Justus Winter, le Mon 11 Nov 2013 21:12:34 +0100, a écrit : >> + /* Decrement nreqthreads. */ >> + unsigned int tc = __atomic_sub_fetch (&thread_counts, 1, >

Re: Further Hurd releases

2013-10-25 Thread Emilio Pozuelo Monfort
Hey, On 25/10/13 17:34, Thomas Schwinge wrote: > Hi! > > On Fri, 25 Oct 2013 15:54:43 +0200, Justus Winter > <4win...@informatik.uni-hamburg.de> wrote: >> what you're suggesting is not >> possible. Labels can only be placed in front of a statement and a >> declaration is not a statement. Well, t

Re: [PATCH 5/5] libtrivfs: fix an use-after-free error

2013-10-25 Thread Emilio Pozuelo Monfort
Minor nitpick: On 25/10/13 10:30, Justus Winter wrote: > Found using the Clang Static Analyzer. > > * libtrivfs/protid-clean.c (trivfs_clean_protid): Fix use-after-free error. > --- > libtrivfs/protid-clean.c |5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/libtri

Re: [PATCH 1/6] procfs: fix the error handling in argp_parser

2013-06-27 Thread Emilio Pozuelo Monfort
Hi, On 27/06/13 14:31, Justus Winter wrote: > Do not exit using error (1, ..) but gracefully handle the error using > argp_error. > > * procfs/main.c (argp_parser): Proper error handling. > --- > procfs/main.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git

Re: trouble building hurd debian package, alioth confusion

2013-06-10 Thread Emilio Pozuelo Monfort
On 10/06/13 16:10, Justus Winter wrote: > Awesome, didn't know this one. Still I was hoping to get a git repo > since that way I could plug it into my package building solution. The debian packaging with the upstream sources + patches are in a git repo: emilio@titan:~$ apt-cache showsrc hurd | gr

Re: __executable_start

2013-05-26 Thread Emilio Pozuelo Monfort
Hi, On 26/05/13 16:38, Thomas Schwinge wrote: Hi! Re-submitting an oldie of Samuel's: On Sun, 24 Jun 2007 17:45:35 +0200, Samuel Thibault wrote: - _start points on the first instruction, not on the elf header. __executable_start does point on the elf header. --- sysdeps/mach/hurd/i386

Re: libcap2?

2011-08-16 Thread Emilio Pozuelo Monfort
On 16/08/11 14:55, Svante Signell wrote: > On Tue, 2011-08-16 at 14:24 +0200, Samuel Thibault wrote: >> grep-aptavail -FBuild-Depends -sPackage,Build-Depends -n "libcap" >> mySources | paste -sd " \n" | sed -e 's/^\([^ ]*\) .*, \(libcap[^,]* >> \).*$/\1: \2/' | grep -v hurd-i386 | grep -v linux-a

Re: getproc() and zsh

2011-06-30 Thread Emilio Pozuelo Monfort
On 30/06/11 13:52, Samuel Thibault wrote: > Emilio Pozuelo Monfort, le Thu 30 Jun 2011 11:45:31 +0200, a écrit : >> I don't, but where do we use getauth() ? I can't see that in >> http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd

Re: getproc() and zsh

2011-06-30 Thread Emilio Pozuelo Monfort
On 27/06/11 21:37, Samuel Thibault wrote: > Hello, > > zsh started failing to build it static variant on hurd-i386 since we > added the sendmsg(SCM_RIGHTS) patch. This is because it uses getauth(), > which thus pulls hurdports.o from libcrt.a, and thus getproc(), for > which zsh already provides a

Re: Writing the MotH: Questions

2011-06-20 Thread Emilio Pozuelo Monfort
On 19/06/11 13:51, Samuel Thibault wrote: > Arne Babenhauserheide, le Sun 19 Jun 2011 13:45:26 +0200, a écrit : >> An important question I have is what the plan for Debian is exactly: How many >> packages must be ported (XX%) and when do we have to be ready (-MM)? > > There's no plan. Ideally

Re: exec server, /dev/fd/N, RPATH and $ORIGIN

2011-06-15 Thread Emilio Pozuelo Monfort
On 09/06/11 09:46, Jeremie Koenig wrote: > 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 >> (...) >> So this patch adds two new RPCs: exec_exec_file_name RPC and >> fi

Fwd: Interface for SCSI transactions ?

2011-04-11 Thread Emilio Pozuelo Monfort
Forwarding to bug-hurd where I think this is more appropriate and the right people will see your mail. Emilio Original Message Subject: Interface for SCSI transactions ? Date: Thu, 07 Apr 2011 16:17:13 +0200 From: Thomas Schmitt To: help-h...@gnu.org Hi, i would like to explo

Re: GSoC: PATH_MAX

2011-04-07 Thread Emilio Pozuelo Monfort
On 07/04/11 21:42, olafbuddenha...@gmx.net wrote: > I don't know how g_free() behaves -- but if it's the same as normal > free(), you don't need the conditional: free(NULL) is a no-op by > definition. g_free is null-safe too. I thought free(NULL) wasn't safe and led to crashes, but you're right ac

Re: [Fwd: Questions on isc-dhcp]

2011-03-11 Thread Emilio Pozuelo Monfort
On 27/02/11 18:50, Svante Signell wrote: > On Sun, 2011-02-27 at 17:48 +0100, Samuel Thibault wrote: >> Samuel Thibault, le Sun 27 Feb 2011 17:43:12 +0100, a écrit : >>> that glibc opens /servers/sockets/2, which thus triggers the pfinet >>> translator configured there. >> >> The trigger happening

Re: [Fwd: Questions on isc-dhcp]

2011-02-27 Thread Emilio Pozuelo Monfort
On 27/02/11 13:17, Samuel Thibault wrote: > Svante Signell, le Sun 27 Feb 2011 14:07:17 +0100, a écrit : >> I was referring to the git,hg or whatever archive where the latest >> sources are checked in. > > apt-get source would tell you that URL, which happens to be > svn://svn.debian.org/svn/pkg-g

Re: [PATCH] Add support to send file descriptors over Unix sockets

2010-10-05 Thread Emilio Pozuelo Monfort
Hi, On 05/10/10 01:00, Samuel Thibault wrote: > Emilio, any update on this patch according to Fredrik's comments? > I could easily add it as a patch in Debian's libc. I already updated it, see 4c62d794@gmail.com I've tried it again with Manuel Menal's fix and my testcase works, although the

Re: Bug#591386: since: Does not work as expected on GNU/Hurd

2010-09-20 Thread Emilio Pozuelo Monfort
Hi, On 02/08/10 14:10, Axel Beckert wrote: > "since" does not work as expected on GNU/Hurd (e.g. strauss): > > !57 Z47 ?127 L1 a...@strauss:ttyp0 (-zsh) 11:06:02 [~/debian/since-1.1] > > ./since /tmp/since-test > foo > !58 Z48 ?0 L1 a...@strauss:ttyp0 (-zsh) 11:06:25 [~/debian/since-1.1] > echo

Re: GSoC meetings

2010-08-29 Thread Emilio Pozuelo Monfort
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 new time constraints after vacations end... > Please give some feedback. On

Re: [PATCH] Add support to send file descriptors over Unix sockets

2010-08-11 Thread Emilio Pozuelo Monfort
Hi, On 01/08/10 21:02, Carl Fredrik Hammar wrote: > 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, >>

[PATCH 2/3] Add a file_exec_file_name RPC

2010-08-04 Thread Emilio Pozuelo Monfort
>From ba528e4a9db131112aa09edfdbb3449b55618578 Mon Sep 17 00:00:00 2001 From: Emilio Pozuelo Monfort Date: Wed, 26 May 2010 01:27:40 +0200 Subject: [PATCH 2/3] Add a file_exec_file_name RPC * hurd/fs.defs (file_exec): Deprecate in favor of... (file_exec_file_name): ...this new RPC. Change

[PATCH 3/3] Use the new _hurd_exec_file_name function

2010-08-04 Thread Emilio Pozuelo Monfort
>From bbce8439190738efc9260490fa52f9dfe9600306 Mon Sep 17 00:00:00 2001 From: Emilio Pozuelo Monfort Date: Wed, 26 May 2010 23:32:16 +0200 Subject: [PATCH 3/3] Use the new _hurd_exec_file_name function * configure.in: Check for _hurd_exec_file_name. * utils/fakeauth.c: Call _hurd_exec_file_n

[PATCH 1/3] Add a new exec_exec_file_name RPC

2010-08-04 Thread Emilio Pozuelo Monfort
And these are the Hurd patches. Regards, Emilio >From 011df9d35eb68132cdb14a0f55e2435375e2cfce Mon Sep 17 00:00:00 2001 From: Emilio Pozuelo Monfort Date: Wed, 26 May 2010 00:15:37 +0200 Subject: [PATCH 1/3] Add a new exec_exec_file_name RPC * hurd/exec.defs (exec_exec_file_name): New

[PATCH] Use the new file_exec_file_name RPC

2010-08-04 Thread Emilio Pozuelo Monfort
Hi, This is the glibc patch. If we need to check for file_exec_file_name, I'll integrate something along the lines of the attached patch (after addressing some issues mentioned on IRC with the macro). Regards, Emilio 2010-08-04 Emilio Pozuelo Monfort * hurd/hurdexec.c (_hurd

Re: exec server and /dev/fd/N

2010-08-04 Thread Emilio Pozuelo Monfort
Hi, Regarding glibc checking for the presence of file_exec_file_name in configure, Thomas said he's happy if we just let the build fail if the RPC is not present. Should we check for it or is that fine? If it's fine, I believe these patches are ready to be pushed. If we need to check for it, I hav

Re: socket_send & socket_recv fail when sending non-socket ports

2010-07-28 Thread Emilio Pozuelo Monfort
On 28/07/10 00:53, Roland McGrath wrote: > I don't know off hand why you're getting that failure mode. But in general > you can't use MACH_MSG_TYPE_MOVE_SEND in Hurd RPC arguments (only for > replies) because of the interrupt retry issue. That could be related > to this failure though I can't rea

O_NOTRANS & O_NOFOLLOW

2010-07-28 Thread Emilio Pozuelo Monfort
Hi, cp has some issues with O_NOFOLLOW meaning O_NOTRANS (per __hurd_file_name_lookup). One of them is when opening pipes with O_NOFOLLOW (or when opening them with O_NOTRANS, which is the problem here). Then the permissions are checked in libdiskfs (if the pipe is in an ext2fs partition for examp

[PATCH] Add support to send file descriptors over Unix sockets

2010-07-27 Thread Emilio Pozuelo Monfort
#if set to 1 (i.e. sending socket fds). Regards, Emilio >From bd70862e18ba6c2a404917bffef72de367a3b132 Mon Sep 17 00:00:00 2001 From: Emilio Pozuelo Monfort Date: Sat, 17 Jul 2010 22:09:13 +0200 Subject: [PATCH] Add support to send file descriptors over Unix sockets --- sysdeps/mach/hurd/rec

socket_send & socket_recv fail when sending non-socket ports

2010-07-27 Thread Emilio Pozuelo Monfort
Hi, While adding support for SCM_RIGHTS to glibc, I've created a testcase that sends and receives some ports on the result of a socketpair() call. The ports sent were initially the two ports result of another socketpair() call, and it was working fine, but then I tried with the result of a couple

[PATCH] Use the new file_exec_file_name RPC

2010-07-26 Thread Emilio Pozuelo Monfort
ge (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 worked fine. No idea why. Regards, Emilio 2010-07-26 Emilio Pozuelo Monfort * hurd/hurdexec.c (_hurd_exec

Re: [PATCH] Bump HURD_INTERFACE_VERSION

2010-07-26 Thread Emilio Pozuelo Monfort
Hi, On 23/07/10 11:24, olafbuddenha...@gmx.net wrote: > On Mon, Jul 19, 2010 at 10:57:48AM +0200, Thomas Schwinge wrote: >> On Fri, Jul 16, 2010 at 12:19:21PM +0200, Emilio Pozuelo Monfort wrote: > >>> * hurd/version.h (HURD_INTERFACE_VERSION): Bumped for the >&g

[PATCH 2/3] Add a file_exec_file_name RPC

2010-07-26 Thread Emilio Pozuelo Monfort
>From 459924a5bcd33464c732befb81a2c89397d4e13d Mon Sep 17 00:00:00 2001 From: Emilio Pozuelo Monfort Date: Wed, 26 May 2010 01:27:40 +0200 Subject: [PATCH 2/3] Add a file_exec_file_name RPC * hurd/fs.defs (file_exec): Deprecate in favor of... (file_exec_file_name): ...this new RPC. Change

Re: exec server and /dev/fd/N

2010-07-26 Thread Emilio Pozuelo Monfort
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 left the HURD_INTERFACE_VERSION patch out. We should decide whether to remove it or

[PATCH 1/3] Add a new exec_exec_file_name RPC

2010-07-26 Thread Emilio Pozuelo Monfort
>From 234eb51c6b8184c6785512852eb0b3be6244c783 Mon Sep 17 00:00:00 2001 From: Emilio Pozuelo Monfort Date: Wed, 26 May 2010 00:15:37 +0200 Subject: [PATCH 1/3] Add a new exec_exec_file_name RPC * hurd/exec.defs (exec_exec_file_name): New RPC. (exec_exec): Label as deprecated. * doc/hurd.t

[PATCH 3/3] Use the new _hurd_exec_file_name function

2010-07-26 Thread Emilio Pozuelo Monfort
>From c6276e2df1d370dbbdd7f4e6fb388f241f84fee7 Mon Sep 17 00:00:00 2001 From: Emilio Pozuelo Monfort Date: Wed, 26 May 2010 23:32:16 +0200 Subject: [PATCH 3/3] Use the new _hurd_exec_file_name function * configure.in: Check for _hurd_exec_file_name. * utils/fakeauth.c: Call _hurd_exec_file_n

Re: RPC user stub libraries

2010-07-20 Thread Emilio Pozuelo Monfort
On 19/07/10 23:06, Thomas Bushnell, BSG wrote: >> * What's the reason for having a libmachuser / libhurduser be part of >>glibc? >> >>Is it for Roland's convenience, or is there a technical reason? Can >>we move it out of the glibc build process? >> > > Given the need for the librar

Re: [PATCH] Implement getsockopt (fd, SOL_SOCKET, SO_TYPE, ...)

2010-07-17 Thread Emilio Pozuelo Monfort
This fixed Carl and Samuel's comments. I haven't retested since the changes are trivial. Cheers, Emilio >From 6892a23b4387eab9cde63fa86a04b3e7efd615cf Mon Sep 17 00:00:00 2001 From: Emilio Pozuelo Monfort Date: Wed, 14 Jul 2010 18:40:36 +0200 Subject: [PATCH] Implement g

Re: [PATCH] Implement getsockopt (fd, SOL_SOCKET, SO_TYPE, ...)

2010-07-17 Thread Emilio Pozuelo Monfort
Hi, On 15/07/10 20:46, Carl Fredrik Hammar wrote: > On Thu, Jul 15, 2010 at 05:15:25PM +0200, Emilio Pozuelo Monfort wrote: > The first thing you should do in any RPC that is not a stub is: > if (!user) > return EOPNOTSUPP; Done. I'm not sure when user would be NUL

Re: What do you need from the Hurd for your day-to-day tasks?

2010-07-17 Thread Emilio Pozuelo Monfort
On 15/07/10 17:54, Samuel Thibault wrote: > Emilio Pozuelo Monfort, le Wed 14 Jul 2010 21:13:11 +0200, a écrit : >> - Support for modern processors (Intel Core 2 Duo, I've heard anything newer >> than Pentium III may not work) > > I'd actually say that anything

[PATCH] Use the new __hurd_exec_file_name RPC

2010-07-16 Thread Emilio Pozuelo Monfort
And here goes the glibc one. Regards, Emilio 2010-07-16 Emilio Pozuelo Monfort * hurd/hurdexec.c (_hurd_exec): Deprecate it. (_hurd_exec_file_name): New function. * hurd/hurd.h: Declare it. * hurd/Versions: Export it. * sysdeps/mach/hurd/execve.c: Use

[PATCH 3/3] Use the new _hurd_exec_file_name function

2010-07-16 Thread Emilio Pozuelo Monfort
Hi, 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?). Cheers, Emilio >From 968f68ba6747ed11b8eb44b09e81323d40e6324b Mon Sep 17 00:00:00 2001 From: Emilio Pozuelo Monfort Date: Wed, 26 May 2

[PATCH] Bump HURD_INTERFACE_VERSION

2010-07-16 Thread Emilio Pozuelo Monfort
>From 03b291be17be4beb67d7397526c1ae7c292649df Mon Sep 17 00:00:00 2001 From: Emilio Pozuelo Monfort Date: Thu, 15 Jul 2010 20:37:20 +0200 Subject: [PATCH] Bump HURD_INTERFACE_VERSION * hurd/version.h (HURD_INTERFACE_VERSION): Bumped for the recently added RPCs. --- h

[PATCH 2/3] Add a file_exec_file_name RPC

2010-07-16 Thread Emilio Pozuelo Monfort
>From 3804a36fcf95a3fd588ce67a08a36346134b8d1f Mon Sep 17 00:00:00 2001 From: Emilio Pozuelo Monfort Date: Wed, 26 May 2010 01:27:40 +0200 Subject: [PATCH 2/3] Add a file_exec_file_name RPC * hurd/fs.defs (file_exec_file_name): New RPC. (file_exec): Label as depreca

[PATCH 1/3] Add a new exec_exec_file_name RPC

2010-07-16 Thread Emilio Pozuelo Monfort
On 31/05/10 18:27, Carl Fredrik Hammar wrote: > I have reviewed the patches and apart from formatting there were only > a couple of issues. Next iteration is hopefully the last. I hope so! > On Thu, May 27, 2010 at 06:22:26PM +0200, Emilio Pozuelo Monfort wrote: >> On 25/05

Re: [PATCH] Implement getsockopt (fd, SOL_SOCKET, SO_TYPE, ...)

2010-07-15 Thread Emilio Pozuelo Monfort
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 buffer is big enough. >From 4adb3ab202d945139555a325460fc4a39f77

Re: [PATCH] Implement getsockopt (fd, SOL_SOCKET, SO_TYPE, ...)

2010-07-15 Thread Emilio Pozuelo Monfort
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 :( >From 1d24cce79fd6cc0b7618a716cc6c489585497445 Mon Sep 17 00:00:00 2001 From: Emilio Pozuelo Monfort Date: Wed, 14 Jul 2010 18:40:36 +0200 Subject:

Re: [PATCH] Implement getsockopt (fd, SOL_SOCKET, SO_TYPE, ...)

2010-07-15 Thread Emilio Pozuelo Monfort
On 15/07/10 16:36, Jérémie Koenig wrote: > On Thu, Jul 15, 2010 at 4:07 PM, Emilio Pozuelo Monfort > wrote: >> error_t >> S_socket_getopt (struct sock_user *user, >> int level, int opt, >> char **value, size_t *value_len) >&

[PATCH] Implement getsockopt (fd, SOL_SOCKET, SO_TYPE, ...)

2010-07-15 Thread Emilio Pozuelo Monfort
Hi, SSIA. I've tested it with SOCK_STREAM, SOCK_DGRAM and SOCK_SEQPACKET and it works fine. Cheers, Emilio --- pflocal/socket.c | 16 +--- 1 files changed, 13 insertions(+), 3 deletions(-) diff --git a/pflocal/socket.c b/pflocal/socket.c index 06777ca..464bbc1 100644 --- a/pfloca

Re: What do you need from the Hurd for your day-to-day tasks?

2010-07-14 Thread Emilio Pozuelo Monfort
On 12/07/10 08:41, Arne Babenhauserheide wrote: > What is currently missing in the Hurd distibutions to make it fullfill your > basic needs for your day-to-day work or hobby? Ideally on real hardware, > alternatively in qemu/virtualbox/XEN/… I'd first need to (try to) install it on my desktop (r

Re: News 2010-06

2010-07-14 Thread Emilio Pozuelo Monfort
On 04/07/10 14:43, Carl Fredrik Hammar wrote: > 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

[bug #29655] linkat() fails because __file_name_lookup_at() problems

2010-06-02 Thread Emilio Pozuelo Monfort
Update of bug #29655 (project hurd): Item Group:None => Standard Compliance Assigned to:None => pochu Reproducibility:None => Every Time

Re: [PATCH 1/3] Add a new exec_exec_file_name RPC

2010-06-01 Thread Emilio Pozuelo Monfort
On 02/06/10 01:22, Roland McGrath wrote: > I am not convinced that this is worth doing. Any name from anywhere is > always just a guess at what might be the right file name. There will > always be cases where you can't manage to guess it. It is only a guess for > convenience when not secure, aft

Re: [PATCH 1/3] Add a new exec_exec_file_name RPC

2010-06-01 Thread Emilio Pozuelo Monfort
Hi Roland, On 02/06/10 00:29, Roland McGrath wrote: > wrt new RPC: sorry, I skipped the earlier discussion. > What is this for? No problem. Let me quote myself: > 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 scr

[PATCH 3/3] Use the new _hurd_exec_file_name function

2010-05-27 Thread Emilio Pozuelo Monfort
--- utils/fakeauth.c |6 +++--- utils/rpctrace.c |4 ++-- utils/shd.c |6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) 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 @@ /* fakea

[PATCH 2/3] Add a file_exec_file_name RPC

2010-05-27 Thread Emilio Pozuelo Monfort
--- TODO |2 +- doc/hurd.texi | 16 exec/hashexec.c | 31 +++ hurd/fs.defs | 27 +++-- hurd/hurd_types.h |8 ++-- init/init.c |

[PATCH] Use the new __hurd_exec_file_name RPC

2010-05-27 Thread Emilio Pozuelo Monfort
This fixes problems when an script could end with /dev/fd/N in argv[0] because the exec server didn't know the file name. --- hurd/Versions |1 + hurd/hurd.h | 12 +- hurd/hurdexec.c | 48 ++- sysdeps

[PATCH 1/3] Add a new exec_exec_file_name RPC

2010-05-27 Thread Emilio Pozuelo Monfort
--- doc/hurd.texi |8 exec/exec.c | 44 exec/hashexec.c | 10 +++--- exec/priv.h |3 ++- hurd/exec.defs | 18 -- hurd/version.h |2 +- 6 files changed, 70 insertions(+), 15 deletions(-) diff --

Re: exec server and /dev/fd/N

2010-05-27 Thread Emilio Pozuelo Monfort
fine IMHO, you need a new glibc to build the new Hurd anyway) unless we get into weird tricks OR we move the client side RPCs from libhurduser.so to a library built from Hurd. Regarding version.h, I've bumped HURD_INTERFACE_VERSION in 0001 for exec_exec_file_name, but should

Re: exec server and /dev/fd/N

2010-05-26 Thread Emilio Pozuelo Monfort
Hi, 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 file being executed (when it's a scrip

Re: exec server and /dev/fd/N

2010-05-25 Thread Emilio Pozuelo Monfort
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) >> +error = lookup (name = filename, 0, &name_file); >>

Re: exec server and /dev/fd/N

2010-05-25 Thread Emilio Pozuelo Monfort
Hi Carl, Thanks for the thorough review! On 25/05/10 21:10, Carl Fredrik Hammar wrote: > Some of the changes that need to be made have already been discussed on > IRC: you should use string_t instead of data_t, empty string instead of > NULL for RPCs, and update copyright years, OK > The first

[bug #29206] /proc/meminfo says swap is full when it's not

2010-05-25 Thread Emilio Pozuelo Monfort
Follow-up Comment #2, bug #29206 (project hurd): I successfully tested this patch: diff -u -r1.1.2.5 procfs_nonpid_files.c --- procfs_nonpid_files.c 12 Dec 2008 00:48:54 - 1.1.2.5 +++ procfs_nonpid_files.c 25 May 2010 11:57:14 - @@ -412,8 +414,8 @@ "HighFree:t%l

[bug #29655] linkat() fails because __file_name_lookup_at() problems

2010-05-25 Thread Emilio Pozuelo Monfort
Update of bug #29655 (project hurd): Wiki-like text discussion box: As we have just discussed on #hurd, the patch looks good and should be submitted to libc-alpha after I have the copyright assignment for glibc on file (and after updating the changelog). => __

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

2010-05-24 Thread Emilio Pozuelo Monfort
Update of bug #28934 (project hurd): Wiki-like text discussion box: I've posted my last patches on http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00108.html => ___ Follow-up Comment #14: I've posted my last

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

2010-05-24 Thread Emilio Pozuelo Monfort
Update of bug #28934 (project hurd): Wiki-like text discussion box: => I've posted my last patches on http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00108.html ___ Reply to this item at:

exec server and /dev/fd/N

2010-05-24 Thread Emilio Pozuelo Monfort
of libhurduser.so should maybe be moved to Hurd. Cheers, Emilio >From 1ab4b589efdd9ba9a809ba6d0dd88fd0d3645b0d Mon Sep 17 00:00:00 2001 From: Emilio Pozuelo Monfort Date: Wed, 19 May 2010 23:06:13 +0200 Subject: [PATCH 1/4] Extend check_hashbang with a filename argument If the new filename argument is no

Re: GSoC IRC meetings, dammit!

2010-05-17 Thread Emilio Pozuelo Monfort
On 18/05/10 00:17, olafbuddenha...@gmx.net wrote: > Hi, > > So, we had three GSoC IRC meetings so far. At the first two, one student > was absent; and at the third one, another was missing... Neither doing > as much as giving notice of the absence. > > The community bonding period is almost over,

[bug #29655] linkat() fails because __file_name_lookup_at() problems

2010-05-12 Thread Emilio Pozuelo Monfort
Update of bug #29655 (project hurd): Wiki-like text discussion box: => As we have just discussed on #hurd, the patch looks good and should be submitted to libc-alpha after I have the copyright assignment for glibc on file (and after updating the changelog). _

[bug #29655] linkat() fails because __file_name_lookup_at() problems

2010-05-08 Thread Emilio Pozuelo Monfort
Follow-up Comment #3, bug #29655 (project hurd): Thanks for the review. This patch (hopefully) clarifies the comment. I don't understand your second point though. How can "linkat(..., AT_SYMLINK_FOLLOW)" be wrong? Do you mean that in that case with my patch, file_name_lookup_at() will have O_NO

Re: Initial GSoC meeting

2010-04-27 Thread Emilio Pozuelo Monfort
On 27/04/10 11:59, Emilio Pozuelo Monfort wrote: > I have class at that time, though I can probably make it some days (but not > others). OTOH I'll finish them on June 9th, so maybe it's not worth changing > the > schedule if it fits everyone else. Actually my class f

Re: Initial GSoC meeting

2010-04-27 Thread Emilio Pozuelo Monfort
Heya, On 26/04/10 23:39, olafbuddenha...@gmx.net wrote: > So, GSoC is on -- and we have several new participants. All the > candidates have written to the list before, so I hope I can skip formal > introductions -- though of course the students can introduce themselfs > if they wish :-) I don't t

Re: $CRASHSERVER not honored?

2010-04-26 Thread Emilio Pozuelo Monfort
On 26/04/10 16:52, Thomas Schwinge wrote: > I'm not up-to-date about upstream and Debian GNU/Hurd > GDB's status, when GDB itself is starting the inferior (`run' command). > There has been a bug which I reported some moons ago, together with a > preliminary patch, but I'm not sure if it was committ

[bug #29655] linkat() fails because __file_name_lookup_at() problems

2010-04-24 Thread Emilio Pozuelo Monfort
Follow-up Comment #1, bug #29655 (project hurd): Return value submitted at http://sources.redhat.com/ml/libc-alpha/2010-04/msg00046.html ___ Reply to this item at: _

[bug #29655] linkat() fails because __file_name_lookup_at() problems

2010-04-24 Thread Emilio Pozuelo Monfort
URL: Summary: linkat() fails because __file_name_lookup_at() problems Project: The GNU Hurd Submitted by: pochu Submitted on: Sat 24 Apr 2010 12:50:52 PM CEST Category: glibc

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

2010-04-15 Thread Emilio Pozuelo Monfort
Follow-up Comment #11, bug #28934 (project hurd): It looks like I somehow fucked the previous glibc build, since I've built it from scratch this time, and it works great. No regressions and gcc works. The patch was the same. I've modified the patch a little bit after testing that it works follow

Re: Building software for the Hurd

2010-04-13 Thread Emilio Pozuelo Monfort
On 13/04/10 10:47, Samuel Thibault wrote: > Emilio Pozuelo Monfort, le Tue 13 Apr 2010 10:36:37 +0200, a écrit : >> On 13/04/10 12:32, Jose Luis Alarcon Sanchez wrote: >>> Mmm, the debian-hurd-k16-qemu.img qemu image is enough pretty old right now. >>> I have the idea

Re: Building software for the Hurd

2010-04-13 Thread Emilio Pozuelo Monfort
On 13/04/10 12:32, Jose Luis Alarcon Sanchez wrote: > Mmm, the debian-hurd-k16-qemu.img qemu image is enough pretty old right now. > I have the idea on my head since some days ago. Can i send a new qemu image > with a dist-upgraded system to any place?. > > Ever is more easy begin with a updated

Re: Building software for the Hurd

2010-04-12 Thread Emilio Pozuelo Monfort
On 12/04/10 22:31, Patrik Olsson wrote: > Hello, > > I wonder how to build software for the Hurd, and then run it. I think I > need some cross compiler environment, but I'm not sure how to build it. > > Is this (link below) the recommended procedure for setting up a > cross-compilation environmen

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

2010-04-12 Thread Emilio Pozuelo Monfort
Follow-up Comment #10, bug #28934 (project hurd): Err the glibc patch was not the one I finally used (I attached the wrong one). Here's the one I've used. I've tested in another VM and I see the same regression. Furthermore I've found that gcc stops working fine in a machine with a new glibc.so

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

2010-03-22 Thread Emilio Pozuelo Monfort
Follow-up Comment #8, bug #28934 (project hurd): Actually there seems to be a regression: a program like main (int argc, char **argv) { printf ("%s", argv[0]); } put into /bin/foobar, will make $ foobar print ./foobar instead of "foobar", which would be expected and works fine without my pat

[bug #29292] ext2 filesystem doesn't sync properly on shutdown

2010-03-21 Thread Emilio Pozuelo Monfort
URL: Summary: ext2 filesystem doesn't sync properly on shutdown Project: The GNU Hurd Submitted by: pochu Submitted on: Sun 21 Mar 2010 10:09:40 PM GMT Category: None

[bug #29287] halt seems to hang when running on the hurd console

2010-03-21 Thread Emilio Pozuelo Monfort
URL: Summary: halt seems to hang when running on the hurd console Project: The GNU Hurd Submitted by: pochu Submitted on: Sun 21 Mar 2010 08:13:38 PM GMT Category: None

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

2010-03-21 Thread Emilio Pozuelo Monfort
Follow-up Comment #7, bug #28934 (project hurd): The attached two patches fix this by adding a new exec flag in Hurd, EXEC_FILE_NAME, that will make the exec server to not look at PATH, but just exec the name it's been passed, even if it doesn't contain slashes. Then we add a new _hurd_exec_file

Re: Xorg, libpciaccess and /dev/mem

2010-03-19 Thread Emilio Pozuelo Monfort
On 11/03/10 12:37, Jérémie Koenig wrote: > * I'm able to use gdb on the X server through the network but when I > try to rebuild the xorg-server source package with > DEB_BUILD_OPTIONS=debug,nostrip, I get a segfault from libtool. (Could > someone confirm they have this problem as well?) debug w

[bug #29206] /proc/meminfo says swap is full when it's not

2010-03-12 Thread Emilio Pozuelo Monfort
URL: Summary: /proc/meminfo says swap is full when it's not Project: The GNU Hurd Submitted by: pochu Submitted on: Fri 12 Mar 2010 01:03:05 PM GMT Category: None Seve

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

2010-02-26 Thread Emilio Pozuelo Monfort
Follow-up Comment #5, 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. > Also, ``./foo bar'' gets me `bar' in Linux not `./bar'. Are you sur

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

2010-02-26 Thread Emilio Pozuelo Monfort
Follow-up Comment #3, bug #28934 (project hurd): Hi Carl, Actually I don't think the exec server needs to know what exec*() variant has been called, since the call itself will have called execve() with the full path by looking at PATH if needed (see glibc's posix/execvpe.c, the beginning of the

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

2010-02-19 Thread Emilio Pozuelo Monfort
Follow-up Comment #1, bug #28934 (project hurd): btw the POSIX standard that makes me think path in execve() should always be taken as a path (note the difference between path and file), from http://www.opengroup.org/onlinepubs/95399/functions/exec.html """ int execve(const char *path, char

[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

2010-02-19 Thread Emilio Pozuelo Monfort
URL: Summary: execve(path, args) should take path as a a relative path if it doesn't contain slashes Project: The GNU Hurd Submitted by: pochu Submitted on: Fri 19 Feb 2010 03:43:23 PM GMT

Re: Porting highlights for the Month of the Hurd 2009-12

2009-12-28 Thread Emilio Pozuelo Monfort
Hi, Arne Babenhauserheide wrote: > Is there a port among the highlights you'd like to showcase? Many GNOME packages have been ported, resulting in the gnome-core metapackage being installable again. I haven't tested them yet though as I can't start X :) Cheers, Emilio

Re: news 2009-11-30

2009-12-02 Thread Emilio Pozuelo Monfort
Heya Arne Babenhauserheide wrote: >> Also thanks to Samuel Thibault, the latest grub2 package (1.97+20091125-1) Note that this version has a segfault that is triggered when running grub-install or grub-mkconfig. The 1.97+20091130-1 package fixes this issue though, so I suggest to use that version