Indeed, few of the patches at
http://patch-tracker.debian.org/package/hurd/1:0.5.git20140326-1 look
Debian-specific.
For features that are not “fully baked” yet, like DDE, wouldn’t it make
sense to have a branch in the Hurd repo, instead of a set of patches in
Debian?
As for patches for which
Ludovic Courtès, le Sun 06 Apr 2014 22:44:12 +0200, a écrit :
Indeed, few of the patches at
http://patch-tracker.debian.org/package/hurd/1:0.5.git20140326-1 look
Debian-specific.
For features that are not “fully baked” yet, like DDE, wouldn’t it make
sense to have a branch in the Hurd repo,
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 this
On Mon, Apr 7, 2014 at 4:52 PM, Samuel Thibault samuel.thiba...@gnu.orgwrote:
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
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
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 fine,
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 taken the
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
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 people
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 things
* 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.
*
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
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.
*
On Mon, Apr 7, 2014 at 5:57 PM, Samuel Thibault samuel.thiba...@gnu.orgwrote:
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.
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
On Mon, Apr 7, 2014 at 5:31 PM, Samuel Thibault samuel.thiba...@gnu.orgwrote:
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
On Mon, Apr 7, 2014 at 5:32 PM, Samuel Thibault samuel.thiba...@gnu.orgwrote:
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.
Zhang Cong, le Mon 07 Apr 2014 19:36:02 +0800, a écrit :
On Mon, Apr 7, 2014 at 5:32 PM, Samuel Thibault samuel.thiba...@gnu.org
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
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 keeping
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 with
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, if this
On Mon, Apr 7, 2014 at 7:58 PM, Richard Braun rbr...@sceen.net 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
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
From: Emilio Pozuelo Monfort poch...@gmail.com
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.
*
From: Emilio Pozuelo Monfort poch...@gmail.com
* 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 j...@jk.fr.eu.org
On Mon, Apr 7, 2014 at 7:43 PM, Samuel Thibault samuel.thiba...@gnu.orgwrote:
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,
Zhang Cong, le Mon 07 Apr 2014 20:42:04 +0800, a écrit :
On Mon, Apr 7, 2014 at 7:43 PM, Samuel Thibault samuel.thiba...@gnu.org
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
On Fri, Mar 21, 2014 at 12:50 AM, Thomas Schwinge
tho...@codesourcery.comwrote:
Hi!
Welcome back! ;-)
On Thu, 20 Mar 2014 22:40:13 +0800, Yue Lu hacklu.newb...@gmail.com
wrote:
On Tue, Feb 25, 2014 at 4:53 PM, Thomas Schwinge
tho...@codesourcery.comwrote:
GDB: »catch syscall«;
On Mon, Apr 7, 2014 at 8:55 PM, Samuel Thibault samuel.thiba...@gnu.orgwrote:
Zhang Cong, le Mon 07 Apr 2014 20:42:04 +0800, a écrit :
On Mon, Apr 7, 2014 at 7:43 PM, Samuel Thibault samuel.thiba...@gnu.org
wrote:
Again, no. Drivers can work the way they prefer. The driver
Hi!
On Tue, 8 Apr 2014 00:20:57 +0800, Zhang Cong congzh...@mathphoenix.com 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
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 seem
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 version of
2014-04-07 21:05 GMT+00:00 Samuel Thibault samuel.thiba...@gnu.org:
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
Manolis Ragkousis, le Mon 07 Apr 2014 21:11:40 +, a écrit :
2014-04-07 21:05 GMT+00:00 Samuel Thibault samuel.thiba...@gnu.org:
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
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
35 matches
Mail list logo
