Using the website just now, I had to search the internet to find the
subhurd page. Perhaps these link will help others find the right
page.
* documenation.mdwn: add a link to subhurds
* hurd.mdwn: add a link to subhurds
* hurd/documentation: add a link to subhurds
---
documentation.mdwn | 1
I always have a hard time finding this page. Maybe adding this link
to the hurd/documentation and hurd page will help others to find the
existing Hurd translators page.
* hurd/documentation.mdwn: add a link to hurd/translator
* hurd.mdwn: add a link to hurd/translator
* documentation.mdwn: add a
Follow-up Comment #3, bug #49024 (project hurd):
The gsync files were relicensed in commit
c8e687cb8a6ba8f278c58bf78126f843ceb292bb on 2016-10-31, and the ACPI files
were deleted in commit c387012395ec83dbdad5e9a1e31f3a214337d064 on
2016-11-06.
gitlog-to-changelog has not been relicensed nor dele
Follow-up Comment #2, bug #49024 (project hurd):
I think the first step should be to import the GPLv3 license text to the
source tree. Even if the GPLv3-or-later files were eventually deleted from
the source tree, they would probably be left in the Git history. Having the
GPLv3 license text like
Follow-up Comment #1, bug #49024 (project hurd):
I previously listed GPLv2-only files that carry their own license notices.
The GNU Mach tree also contains Linux source files that do not contain a
license notice; then, linux/src/COPYING specifies GPLv2 for them.
linux/dev/drivers/block/genhd.c i
URL:
<http://savannah.gnu.org/bugs/?49024>
Summary: gnumach links with GPLv3+ material but omits GPLv3
text
Project: The GNU Hurd
Submitted by: kon
Submitted on: Wed Sep 7 21:24:34 2016
Category: GN
Hi!
On Mon, 28 Sep 2015 23:54:01 +0300, gk.p...@gmail.com wrote:
> When going to the "recent changes" at the hurd wiki, and clicking to one
> of the pages I am redirected to a "404 - not found" page. This also
> holds true for the hurd wiki at sceen.net.
Thanks for reporting this -- it seems the
Hi!
Maksym: this will give you some idea for tmpfs development/testing.
On Thu, 20 Oct 2011 17:23:23 +, I wrote:
> commit 3aa7bb4849945c7480873567767db3face604260
> Author: Thomas Schwinge
> Date: Thu Oct 20 15:47:00 2011 +0200
>
> Populate a [build]/lib directory wi
Hello,
There are a lot of dead links on
http://www.gnu.org/software/hurd/hurd/running/distrib.html
these are supposed to be existing documents. Something bad probably
happened.
Samuel
Hi,
Thanks for debugging this! Forwarding it to the appropriate list.
-antrik-
- Forwarded message from Kalle Olavi Niemitalo <[EMAIL PROTECTED]> -
Date: Wed, 26 Dec 2007 17:44:37 +0200
From: Kalle Olavi Niemitalo <[EMAIL PROTECTED]>
Subject: Re: [elinks-dev] The Links/L
Hi,
On Sun, Jun 24, 2007 at 11:07:26PM +0200, Jose Luis Alarcon Sanchez wrote:
> ldconfig: /lib/libslapi-2.3.so.0 is not a simbolic link
>
> ldconfig: /lib/libldap_r-2.3.so.0 is not a simbolic link
>
> ldconfig: /lib/libldap-2.3.so.0 is not a simbolic link
>
> ldconfig: /lib/liblber-2.3.so.0 i
Hi folks.
Command apt-get install, when is setting up packages,
many times have an ouput like this:
Setting up liblzo2-2 (2.02-3) ...
ldconfig: /lib/libslapi-2.3.so.0 is not a simbolic link
ldconfig: /lib/libldap_r-2.3.so.0 is not a simbolic link
ldconfig: /lib/libldap-2.3.so.0 is not a simboli
Just to complete the follow menssage about Links bug...
anyone know where is the bug and why the keys not work well at the
main screen? Looks like a simple problem but i cant find where is the
error.
Thanks again! ;D
Matheus Morais
___
Bug
It's already someone work in Links (workable :D) for hurd?
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
On Tue, Mar 01, 2005 at 03:16:14AM +0100, Alfred M. Szmidt wrote:
>$ rpctrace cat /tmp/d/0123/a/f > rpctrace-2 2>&1
>
> When doing a rpctrace, use the -I option to include msgid files. That
> way the numbers get converted to readable function names.
#v+
$ find /include/ -name '*.defs' | whil
$ rpctrace cat /tmp/d/0123/a/f > rpctrace-2 2>&1
When doing a rpctrace, use the -I option to include msgid files. That
way the numbers get converted to readable function names.
Is someone able to reproduce this?
How can I help to debug this?
I haven't been able to reproduce, are you us
Hello again!
#v+
$ uname -osrv
Linux 2.4.29 #1 Sat Jan 22 16:40:17 CET 2005 GNU/Linux
$ ~/tmp/do_it
+ set -e
+ cd /tmp
+ mkdir e
+ ln -s e/d /tmp/
+ mkdir -p e/d/012/b e/d/c/a
+ echo OK.
+ ln -s b/c/a e/d/012/
+ ln -s /tmp/d/c e/d/012/b/
+ cat /tmp/d/012/a/f
OK.
+ mv /tmp/d/012 /tmp/d/0123
+ cat /
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> That's actually not a problem, because each walk through the union
> fs requires a retry. The library is supposed to keep track of how
> many retries it gets, and handle ELOOP itself.
Still, if you imagine many that users create a unionfs based
Moritz Schulte <[EMAIL PROTECTED]> writes:
> After I did the O_NOTRANS lookup in unionfs, I check if the resulting
> node is the same as the one returned by netfs_startup. If it is, I
> return ELOOP to make it impossible to reach the unionfs inside of the
> unionfs again, which would lead to infi
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> What we really want is for the user to do a retry of the name as it
> exists in the "real" location, and then if that results in ENOENT,
> we want the user to return back to the filesystem for another name
> to try.
Well, here you are only consid
Moritz Schulte <[EMAIL PROTECTED]> writes:
> Actually I was not thinking about making ".." go to the unionfs, but
> this surely seems like a good idea.
>
> > If it's a translator (of any kind, including symlink) then it does
> > the translator linkage *itself*, just as diskfs/netfs does it.
>
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Oh, that. Blech blech blech.
Blech is also corking.
> And, of course, this matters in just this case! Because it's a
> union, and so the node is found in *two* directories and it's not at
> all clear which one is right.
I'm not sure wether I
Moritz Schulte <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > What exactly would the problem be there? Maybe I've missed a beat
> > in the conversation.
>
> Maybe I am overlooking something, I am not that familiar with
> libdiskfs.
>
> My question is: give
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> What exactly would the problem be there? Maybe I've missed a beat
> in the conversation.
Maybe I am overlooking something, I am not that familiar with
libdiskfs.
My question is: given the situation that dir_lookup is called to
re-open a node, w
Moritz Schulte <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > I think the right fix is to have lookups for "" do all the normal
> > processing when you open a file.
>
> Well, yes, but the problem of relative symbolic
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> I think the right fix is to have lookups for "" do all the normal
> processing when you open a file.
Well, yes, but the problem of relative symbolic links is not yet
solved, is it?
moritz
--
[EMAIL P
Moritz Schulte <[EMAIL PROTECTED]> writes:
> > It might well be that we have a hole in the interface here. Blech.
>
> So... fs interface change - anyone? =)
I think the right fix is to have lookups for "" do all the normal
processing when you open a file.
That is, it should do the translator s
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> I think that's why I originally stated "." which Roland corrected to
> "".
Well, "." would not work for non-directories, of course.
> It might well be that we have a hole in the interface here. Blech.
So... fs interface change - anyone? =)
node, he doesn't get the target of a symbolic
link, nor does he get the port to a translator running on that node.
In libdiskfs/dir-lookup.c the case where path is "" is handled
specially; the user simply gets the same node again, to which he sent
the dir_lookup RPC. Neither the p
> Look up the node with O_NOTRANS, and then return *that* to the user,
> with FS_RETRY_REAUTH and a retry name of ".".
Empty string, actually.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Moritz Schulte <[EMAIL PROTECTED]> writes:
> I was thinking about what unionfs should do with symbolic links and
> translators on the underlying filesystems; i think if unionfs's
> _S_dir_lookup would return retry names in that case, that would be
> reasonable.
Yes, tha
Hi,
I was thinking about what unionfs should do with symbolic links and
translators on the underlying filesystems; i think if unionfs's
_S_dir_lookup would return retry names in that case, that would be
reasonable.
It would create some problems if unionfs would simply use
file_name_l
www.paradice.coolfreehost.com
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
33 matches
Mail list logo
