Re: Add a new exec_exec_file_name RPC

Well, I'm not the one to be convinced: it's only Roland which can ack the glibc part, and thus the whole idea of the RPC addition. One "just" needs to explain him why we really need it. Samuel

Re: Glibc building procedure error report.

Manolis Ragkousis, le Mon 07 Apr 2014 21:11:40 +, a écrit : > 2014-04-07 21:05 GMT+00:00 Samuel Thibault : > > Which version of libpthread is this? I don't have this in my copy of the > > tree. We got rid of these a long time ago. > > I am using the master branch, commit 3b391db91f70b21669514

Re: Glibc building procedure error report.

2014-04-07 21:05 GMT+00:00 Samuel Thibault : > Which version of libpthread is this? I don't have this in my copy of the > tree. We got rid of these a long time ago. I am using the master branch, commit 3b391db91f70b2166951413ee1eccc78cd398a44

Re: Glibc building procedure error report.

Manolis Ragkousis, le Mon 07 Apr 2014 19:49:02 +, a écrit : > I am having some problems with building the libpthread addon. I get the error > > > ../libpthread/sysdeps/mach/hurd/pt-sysdep.h:38:32: error: > > '_HURD_THREADVAR_DYNAMIC_USER' undeclared (first use in this function) Which versio

Re: Glibc building procedure error report.

I am having some problems with building the libpthread addon. I get the error > ../libpthread/sysdeps/mach/hurd/pt-sysdep.h:38:32: error: > '_HURD_THREADVAR_DYNAMIC_USER' undeclared (first use in this function) > #define _HURD_THREADVAR_THREAD _HURD_THREADVAR_DYNAMIC_USER <-- but I > can't s

GDB: "warning: Can't wait for pid ???: No child processes" (was: GNU accepted as a mentoring organization in GSOC 2014)

Hi! On Tue, 8 Apr 2014 00:20:57 +0800, Zhang Cong wrote: > I am very interesting in that will the gdb server be a workaround for hurd > gdb's > "warning: Can't wait for pid ???: No child processes" problem? > > Can anyone has workable gdb server to do a test? Can't continue really > make me cr

Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]

On Mon, Apr 7, 2014 at 8:55 PM, Samuel Thibault wrote: > Zhang Cong, le Mon 07 Apr 2014 20:42:04 +0800, a écrit : > > On Mon, Apr 7, 2014 at 7:43 PM, Samuel Thibault > > > wrote: > > > > Again, no. Drivers can work the way they prefer. The driver > > infrastructure itself doesn't need a

Re: GNU accepted as a mentoring organization in GSOC 2014

On Fri, Mar 21, 2014 at 12:50 AM, Thomas Schwinge wrote: > Hi! > > "Welcome back!" ;-) > > > On Thu, 20 Mar 2014 22:40:13 +0800, Yue Lu > wrote: > > On Tue, Feb 25, 2014 at 4:53 PM, Thomas Schwinge < > tho...@codesourcery.com>wrote: > > > > > GDB: »catch syscall«; pretty-printing of mach_msg. >

Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]

Zhang Cong, le Mon 07 Apr 2014 20:42:04 +0800, a écrit : > On Mon, Apr 7, 2014 at 7:43 PM, Samuel Thibault > wrote: > > Again, no.  Drivers can work the way they prefer.  The driver > infrastructure itself doesn't need a "bigplan", it is parts of it which > need their own.  For instan

Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]

On Mon, Apr 7, 2014 at 7:43 PM, Samuel Thibault wrote: > > Again, no. Drivers can work the way they prefer. The driver > infrastructure itself doesn't need a "bigplan", it is parts of it which > need their own. For instance, the IRQ issue I mentioned has its plan > by itself, and it doesn't need

[PATCH 2/3] Add a file_exec_file_name RPC

From: Emilio Pozuelo Monfort * hurd/fs.defs (file_exec): Deprecate in favor of... (file_exec_file_name): ...this new RPC. Change all implementations and forward old implementations to the new version. Change all callers but fallback to old version. Change comments and documentation. Signed-off-

[PATCH 3/3] Use the new _hurd_exec_file_name function

From: Emilio Pozuelo Monfort * configure.in: Check for _hurd_exec_file_name. * utils/fakeauth.c: Call _hurd_exec_file_name instead of _hurd_exec if it's available. * utils/rpctrace.c: Likewise. * utils/shd.c: Likewise. Signed-off-by: Jeremie Koenig Signed-off-by: Justus Winter <4win...@informat

[PATCH 1/3] Add a new exec_exec_file_name RPC

From: Emilio Pozuelo Monfort This is Emilios patch, slightly amended so that the code in hashexec.c actually uses the provided name. This makes it work in a fakerooted environment. * hurd/exec.defs (exec_exec_file_name): New RPC. (exec_exec): Label as deprecated. * doc/hurd.texi: Updated. * exe

Add a new exec_exec_file_name RPC

Hi :) this is a rebased patch series created by Emilio Pozuelo Monfort. I've slightly amended the first patch. This patch series makes the fakeroot translator usable, more precisely the execution of interpreted scripts within the fakeroot environment. Both the patch series and my amendment have r

Re: Please merge the random translator into the Hurd repository

On Mon, Apr 7, 2014 at 7:58 PM, Richard Braun wrote: > > Grouping translators together along with the Hurd libraries and build > system makes the life of developers a lot easier. It reduces the > overhead related to build system settings, and it also reduces the > likeliness of mistakes. It reall

Re: Please merge the random translator into the Hurd repository

Richard Braun, le Mon 07 Apr 2014 13:58:08 +0200, a écrit : > On Mon, Apr 07, 2014 at 01:49:52PM +0200, Thomas Schwinge wrote: > > If there is agreement, despite my comment b), that it'd be beneficial to > > merge the current "external" translators into the Hurd core repository's > > master branch,

Re: Please merge the random translator into the Hurd repository

On Mon, Apr 07, 2014 at 01:49:52PM +0200, Thomas Schwinge wrote: > If there is agreement, despite my comment b), that it'd be beneficial to > merge the current "external" translators into the Hurd core repository's > master branch, if this substantially makes any workflows easier, then I'm > fine w

Re: Please merge the random translator into the Hurd repository

Hi! On Mon, 07 Apr 2014 13:05:43 +0200, Justus Winter <4win...@informatik.uni-hamburg.de> wrote: > please merge the random translator (found in [0]) into the main Hurd > repository. > > 0: git://git.sv.gnu.org/hurd/incubator.git, branch random I have previously (years ago) spoken in favor of ke

Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]

Zhang Cong, le Mon 07 Apr 2014 19:36:02 +0800, a écrit : > On Mon, Apr 7, 2014 at 5:32 PM, Samuel Thibault > wrote: > > Samuel Thibault, le Mon 07 Apr 2014 11:31:33 +0200, a écrit : > > Zhang Cong, le Mon 07 Apr 2014 17:25:34 +0800, a écrit : > > > The one who do this  need have the f

Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]

On Mon, Apr 7, 2014 at 5:32 PM, Samuel Thibault wrote: > Samuel Thibault, le Mon 07 Apr 2014 11:31:33 +0200, a écrit : > > Zhang Cong, le Mon 07 Apr 2014 17:25:34 +0800, a écrit : > > > The one who do this need have the full plan, > > > > I don't see why one would need a full plan. > > Putting it

Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]

On Mon, Apr 7, 2014 at 5:31 PM, Samuel Thibault wrote: > Zhang Cong, le Mon 07 Apr 2014 17:25:34 +0800, a écrit : > > The one who do this need have the full plan, > > I don't see why one would need a full plan. A patch deals with just > part of the code, you don't need to know *all* the code to

Please merge the random translator into the Hurd repository

Dear maintainer :) please merge the random translator (found in [0]) into the main Hurd repository. 0: git://git.sv.gnu.org/hurd/incubator.git, branch random Rationale: The random translator provides /dev/{,u}random that provide cryptographically secure random numbers. A lot of software depend

Re: Upstreaming patches

On Mon, Apr 7, 2014 at 5:57 PM, Samuel Thibault wrote: > And what is the solution? I *DONT* have the time to fix it all myself. > It's as simple as that. What can I do more about it? I believe Samuel has already squeeze his time to make the current bright hurd, thanks. Samuel, If we don't

[PATCH] libports: fix notify_port_t receiver lookups

This is a patch that in conjunction with e9687ec4ff525ae4a88314ba4ae97da770bd012f fixes the receiver lookups for the notify_port_t type. * devnode/Makefile (MIGSFLAGS): Use mig-mutate.h. * eth-filter/Makefile: Likewise. * eth-multiplexer/Makefile: Likewise. * libmachdev/Makefile: Likewise. * devno

Please merge procfs into the Hurd repository

Dear maintainer :) please merge procfs (found in [0]) into the main Hurd repository. 0: git://git.sv.gnu.org/hurd/procfs.git Rationale: The procfs translator provides a Linux-compatible /proc filesystem. While there is no standard that defines the /proc filesystem, a lot of software depends on

[PATCH] libports: fix notify_port_t receiver lookups

* libports/Makefile (MIGSFLAGS): Include mig-mutate.h. * libports/mig-decls.h: New file. * libports/mig-mutate.h: Likewise. * libports/notify-dead-name.c: Fix receiver lookups. * libports/notify-no-senders.c: Likewise. * libports/notify-msg-accepted.c: Adjust function declaration. * libports/notify

Re: Upstreaming patches

Justus Winter, le Mon 07 Apr 2014 11:41:47 +0200, a écrit : > > I end up spending my time mostly fixing & pushing more-or-less-baked > > patches to Debian packages, so people at least get to try them, but the > > polishing+submitting work is much more work, and if nobody gives help > > there, well

Re: Upstreaming patches

Justus Winter, le Mon 07 Apr 2014 11:41:47 +0200, a écrit : > Quoting Samuel Thibault (2014-04-07 01:02:56) > > As for the two other stuff in the Debian hurd package (random, > > procfs), yes it is a ugly hack, and I'd rather avoid it. It was > > just a way to get working /dev/random and /proc so

Re: Upstreaming patches

Justus Winter, le Mon 07 Apr 2014 11:41:47 +0200, a écrit : > I believe that it is essential to reduce every bit of overhead > possible from the development process. Again, I fully understand that. It just happens that I spend mostly all of my available time doing: - fix the few bits without whi

Re: Upstreaming patches

Quoting Samuel Thibault (2014-04-07 01:02:56) > > This has caused me so much pain. And I imagine it is even worse for > > new developers. > > I fully understand all that, it's not fun for me either, and I'd really > love to find the time to fix all that. But for now apparently only I > have take

Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]

Samuel Thibault, le Mon 07 Apr 2014 11:31:33 +0200, a écrit : > Zhang Cong, le Mon 07 Apr 2014 17:25:34 +0800, a écrit : > > The one who do this  need have the full plan, > > I don't see why one would need a full plan. Putting it another way, I don't think anybody has the full plan. Which is fin

Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]

Zhang Cong, le Mon 07 Apr 2014 17:25:34 +0800, a écrit : > The one who do this  need have the full plan, I don't see why one would need a full plan. A patch deals with just part of the code, you don't need to know *all* the code to review the patch, ping people about what is wrong with it, clean

Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]

On Mon, Apr 7, 2014 at 4:52 PM, Samuel Thibault wrote: > Put yet another way, if you ask me "why isn't foo done?" I'll most > probably just answer "because I haven't had time to do it, and nobody > else took the time to do it. If you ask me "could foo be done > then?", I'll answer "sure, patch we

Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]

Put yet another way, if you ask me "why isn't foo done?" I'll most probably just answer "because I haven't had time to do it, and nobody else took the time to do it. If you ask me "could foo be done then?", I'll answer "sure, patch welcome". If you ask me "I've had a look, we could just apply thi

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

Ludovic Courtès, le Sun 06 Apr 2014 22:44:12 +0200, a écrit : > Indeed, few of the patches at > look > Debian-specific. > > For features that are not “fully baked” yet, like DDE, wouldn’t it make > sense to have a branch in the Hur