Samuel, your copyright assignment is now on file.
We collect as per usual copyright assignments for the GNU network
utilities. Just as per normal GNU policies.
Alfred M. Szmidt, le mer. 28 sept. 2022 11:21:34 -0400, a ecrit:
>> have you signed copyright assignment papers for InetUtils,
>
>I didn't know there was copyright assignment for InetUtils :/
>
> It has always been the case. The process is a fe
> have you signed copyright assignment papers for InetUtils,
I didn't know there was copyright assignment for InetUtils :/
It has always been the case. The process is a few days in the best of
cases, and even if it is a week or more, it doesn't slow down progress
much, if at all.
I
* gdb/i386gnu-nat.c (CREG_OFFSET): New macro.
(creg_offset): New array.
(CREG_ADDR): Use creg_offset instead of reg_offset.
Did anyone review this? I don't know GNU/Hurd, but the patch looks
very plausible.
Do you have write access to the GDB
This is sadly a very bad idea; it is bad because it was tried and
failed. This is how the ams-branch worked. All the patches in that
branch have been proven stable, still, none of them are applied to the
trunk.
___
Bug-hurd mailing list
Seperate changes should have seperate headers.
This is incorrect. You can say it five times, or fifty times, but
it is not correct.
It is correct, this has been the rule for all patches to date.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
So, if you are volunteering to fix the driver, great.
Please send the network card for the non-working driver to me.
But there is no need to keep it around on the random chance that
someone may someday fix it.
Then we should remove all driver code that one belives is not used
anylonger
Is there some kind of logic to how you split up the ChangeLog
entries?
What exactly don't you understand about it?
I'm asking if there is logic to the split up, if there isn't, each
change should be in a seperate ChangeLog entry. If there is, please
explain such logic.
How did
okay, still somewhat long, but here we go ...
Thanks. Looks nice, it was tested and stuff right? Does swaping
cards work?
currently cards are only detected by the manfid, a real userspace
cardmgr ought to detect by cis content, etc. as well (quite like
linux's implementation does)
Would there be any objections if I'd remove all native device
drivers from the gnumach-1-branch that are not used anymore?
Care to explain what that would achive? Wouldn't it be better to
simply make the native drivers work?
We don't have any need to make drivers
Seperate changes should have seperate headers.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
If a driver is redundant, then we have no need to care about it.
If a driver doesn't work, we should not include it.
If a driver doesn't work, then it should be fixed.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
Is there some kind of logic to how you split up the ChangeLog entries?
How did you check that the files are ok to remove (it is a long list,
so it is hard to check each file)? i386/utils/debug.h looks a
suspicious for example.
I'm not sure what `adopt all users' means. Maybe you mean callees?
Is this the new console? I.e. the one with virtual consoles? You
could try pressing C-A-BACKSPACE and restart it. Not entierly sure
where you ought to look for this bug, I don't even remeber if there is
a `screensaver' blanker thingy in the console which could contain a
bug.
We have already a `ports' like setup for translators which are
not part of the Hurd, i.e. HurdExtras, where people can maintain
their own translators in a central repository so that it is
easier to find them.
I see HurdExtras as a place for translators that haven't found a
If you make a tag before and after the removal then go for it.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
``Adding the proper libraries to HURDLIBS'' is basically the first
sugestion, combined with a reliable mechanism to make sure that
discrepancies will always be noticed (and do not lead to at first
incomprehensible--like in the example I gave--or--maybe even more
dangerous--silent
I admit I'm not sure of all the context here, but is there some
proposal that /usr will not resolve in GNU? That seems impractical
to me. Virtually everything ever written uses /usr, one way or
another.
There aren't many things that need /usr, most things will figure out
such
find / -P -name FOO
What does -P do? I don't see it in the documentation of find
on my machine.
From (find)Symbolic Links:
`-P'
`find' does not dereference symbolic links at all. This is the
default behaviour. This option must be specified before any of the
file
What do you think?
I think your patch is correct.
Could you elaborate on the two solutions and how the differ (are
better) than just adding the proper libraries to HURDLIBS? You have
to take care both the header and library implement the same API/ABI.
And the safest way to do that is simply
Are there any objections that can convince me not to commit those
to the Hurd's trunk?
Other than you not having any permissions as far as I can see?
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
How about a daemon (or service, or translator, or whatever) that
would monitor the /Programs directory where the new programs are
installed. And when that daemon sees a new program it automagicaly
does a ln -s for binaries, includes, libraries, etc.
That is exactly what stowfs does,
StowFS doesn't create links, it uses unionfs.
And unionfs creates virtual symbolic links that don't really exist.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
So you basically want a server -- it's not a translator --
receiving notifies of the /packages directory changes and reacting
to dir_notify by changing the PATH environment variable of ALL
processes. I am not an Hurd expert. How do you exactly plan to do
it?
I cannot either see how
I know that there are A LOT of scripts that will need to be
CORRECTED.
Not as many as you think. Most scripts figure out where the
interpeter is at compile/configure time.
I do not think that keep a loop symlink of USR-/ is a good idea,
since you will never be able to do a find /
I was thinking about why we need to merge all packages on the root
filesystem is this is not a requirement of POSIX. Posix uses PATH
to determine where the executable files are, lib directories are
setted on /etc/ld.so.conf, others directiories of packages are not
important to the
Fixing hard coded filenames is easy. One can always provide a /usr
symbolic link. Infact, any program that depends on a hard coded file
name is seriously broken.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
I do agree that such a behavior could be considered broken, but if
most of the programs do that I believe that the support for them
should be provided.
And this is easy to do, provide /usr as a symbolic link to / if such
support is needed.
Cheers.
And this is easy to do, provide /usr as a symbolic link to / if
such support is needed.
Or you could frob bash's she-bang parsing.
Easier to frob exec. Then all shells that do hash-bangs will follow.
Make exec strip the leading directory, and then you have something
like `#!foo',
And this is easy to do, provide /usr as a symbolic link to / if
such support is needed.
Yes, of course. I just meant to say that those programs (scripts)
shouldn't necessarily be considered broken... even if they truly
are.
Thing is that they are broken, figuring out where the
Testing and feedback, as always, would be gratly appreciated!
Dunno what kind of feeback you want, the patch looks OK.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
This is applied for the first patch too?
It only applies to perfectly OK patches which some people are simply
to lazy to understand properly.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
I got it but I mean the patch released by me (the first mail in
this topic) has the same problems than the patch released by ams? I
think they are differents.
They aren't different, mine is simply a cleaner version of yours.
Look at the #if's and you will see why they are equivalent.
[...] but I have no idea where I must post/show/give/upload these
modifyed files.
For now, just post them here. Anyone who follows MachRevival also
follows the action on GNU Mach. And patches that end up in GNU Mach
will with most certanty end up in MachRevival. MachRevival will
probobly
Note that for fixes that are more advanced than adding some casts
to get rid of compile-time warnings or similar, we'd like you to
assign the copyright of your changes to the FSF.
Papers are not needed (but nice to have) for GNU Mach. They are a
must for the Hurd though. Or that is how
add_bsd_partition() is only used when MACH _and_ CONFIG_BSD_DISKLABEL
are defined.
2006-01-31 Alfred M. Szmidt [EMAIL PROTECTED]
* linux/dev/drivers/block/genhd.c (add_bsd_partition): Silence
compiler warning. Reported by Matheus Morais
[EMAIL PROTECTED]
--- genhd.c
I see why this could cause a possible warning (unused function?), but
I don't see why it does so. Could you show the warning message?
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Are you sure that changing the #ifdef to #if is the right
change?
Quite, if you have specific concerns that I might have missed
then please speak up.
Your patch is potentially a functional change; not simply a bug fix.
You've defended the addition of
2006-01-28 Thomas Schwinge [EMAIL PROTECTED]
* Makefile.in: Various cleanups. Do not include $(sysdep)/Makefrag
anymore. Move shared and system dependent stuff out of this file.
Include Makerules.
This says nothing about what actually changed. `Did
It would be a pitty if users had to recompile their kernel to have
this supported, is there any possibility of including this in Linux?
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
I am subscribed to the list. No need to send the messages to me in
private unless you are in a hurry, since gnu servers seem to be
late these days. :-)
It is normal to CC all people whom you reply to on a mailing list.
However, the modifications are not made properly by GPL2
You removed libexecdir (and maybe some other variables), why?
Doing something like `--prefix=$(libexecdir)/foo' is always OK.
All variables that can be substituted should be listed. The
variables also get partially expanded, so that is one more reason
to list all of them
./configure --prefix='$(libexecdir)/foo' --libexecdir=/foo
Do you really consider that as a valid use case? Putting
libexecdir's files into `/foo/' and everything else into
`/foo/foo/{bin,share,...}/'?
Yes, I have ended up using similar hacks on several occassions.
If this
For people that doesn't like mails coming from savannah bug
tracker (this involves me too) I inline the patch. It's quite
long (1k lines) but well, just to give an idea of what it does,
here it is.
Obviously vm bugs are very painful to debug when they happen. Can
you
I'm going to commit the following patch unless someone vetoes:
Last time I checked, things don't work like that.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
The question might be rephrased into: do we want proc server
interaction to be XSI-compliant, or do we want strict XSI
compliancy only at libc level?
glibc is the proper place, it should be XSI compliant. proc might not
be though.
___
You might try unsharing the IRQ's for those devices, or some such. Or
compile a really utterly bare kernel.
In wichfile do I find the main() function for gnumah?
_start() in i386/i386at/boothdr.S.
You can also use the kernel debugger to help you out. See the manual
for details about it, it
And to make it clear to everyone else, Thomas is not the maintainer,
nor an active developer of the Hurd. And has absolutley no say in
this matter what so ever.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
And you are? And you do? Says who?
I have been taking care of all the patches for the last year or two, I
have also been the one who has asked, re-asked, and re-re-asked to get
thingies applied. You have not done squat. So unless I missed your
divine work somewhere, I'm the one deciding
Which is what I said, without your bitter and hateful tone.
[... snip ...]
So I'm not sure what, other than your hate for me, you wish to
convey.
I have no idea where you got that, I have neither postive feelings for
you, or negative ones. Maybe if you stopped telling yourself that I
I'm simply reminding people of this fact.
And I'm simply reminding you that you have no say on this matter.
But this prompts me to say that, in my judgment, Thomas Schwinge
should be invited if he is willing to be an official approver of
patches.
What the heck does `offical approver
Marco, if you want to throw out accusations, lies, and insults, do it
somewhere else.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Although I never met Thomas, he has the right set of social skills
required for this job.
Social skills isn't what is required for this job, whatever that is.
Technical skills are; which Thomas might or might not have, but his
help to commit things will be nice to have.
[CCing bug-hurd]
I have done a number of attempts to boot Gnu/Hurd, but mostly the
computer interrupts and reboots in the middle of the process.
No idea if you checked this, but check if you have shared IRQ's. cat
/proc/interrupts in GNU/Linux or some such.
Partitions check: (DOS
[Adding CC to bug-hurd, _again_, don't remove it!]
22: 9186 IO-APIC-level libata, NVidia CK804
23: 13705 IO-APIC-level libata, eth0
These two could cause problems, I don't know what libata or nvidia is.
But if GNU Mach has support for your NIC and any of these two, it
Double wonderfull! Nice work, keep it up. Also has my OK.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Okie, I'm fed up with the braindead crap that the Savannah tracker is.
Always send patches directly to bug-hurd first, when they have been
discussed, and OKed, _then_ add it to the brain dead pile of shit that
the Savannah tracker is. Not before, not later. When it has been
added, to not change
When it has been added, to not change it. Consider it as a commit
to the CVS, and it is there forever. Make a new bug report for the
patch, and follow the above rules.
Let me clarify, instead of changing the patch, send a new bug report
that fixes the filed patch, basically the same
Gnumach fails to build due to the new make POSIX compliant
behaviour with tabs and shell commands.
Not tabs, newlines and backslashes.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
If you wish to discuss private things, do it in private.
This is my last mail on this topic, I have better things to do, like
removing the lint between my toes.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Thank you for once again confirming my decision, now I am sure I did
the right thing in not making you a project administrator of
HurdExtras.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
This I assume is related to the `gnumach, task based IO ports'.
Explanation behind the changes, why etc are needed. I haven't looked
at the patch yet.
2006-01-02 Samuel Thibault [EMAIL PROTECTED]
* iopl.c (iopl_emulate): TSS is now task-based. Fix TSS and
locking accordingly.
Has my blessing.
2006-01-02 Samuel Thibault [EMAIL PROTECTED]
* iopl.c (iopl_port_list): Added timer controller port.
diff -urp gnumach-mine-3-device_port_fix/i386/i386at/iopl.c
gnumach-mine-4-more_ports/i386/i386at/iopl.c
--- gnumach-mine-3-device_port_fix/i386/i386at/iopl.c
Has my blessing, though, I think that this patch should be merged with
`gnumach, timer controller'; it touches the same stuff, etc, so having
seperate patches for them doesn't make much sense.
2006-01-02 Samuel Thibault [EMAIL PROTECTED]
* kd.c (vga_port_list): Rename to...
Looks good, fixed ChangeLog (you forgot to mention i386_io_port_add).
2006-01-02 Samuel Thibault [EMAIL PROTECTED]
* iopb.c (iopb_create, i386_io_port_add): Set default IO
permissions to none.
* ktss.c (ktss_init): Likewise.
diff -urp
Could you gives some explanation about this patch? I haven't looked
at it yet, and I don't recall any discussion about it. I only touched
the ChangeLog in a couple of places, since I'm more interested in a
discussion behind why this patch is needed, etc.
2006-01-02 Samuel Thibault [EMAIL
Once again, explanation behind the patch. We are a bit lazy, so such
things help alot. :-)
2006-01-07 Samuel Thibault [EMAIL PROTECTED]
* iopb.c: Include device/io_req.h for io_req_t. New io device.
(ioopen): New function.
(ioclose): Likewise.
(io_bitmap_set):
This should be merged with `gnumach, new device' from the looks. No
need to make lots of small patches that all depend on each other.
Explanation as always is needed (if there was one already, smack us
over the head with it).
2006-01-07 Samuel Thibault [EMAIL PROTECTED]
* conf.c: New
Looks ok. Why the ifdef i386 though?
2006-01-02 Samuel Thibault [EMAIL PROTECTED]
* iopb.c (i386_io_port_add): Get the device parameter properly.
(i386_io_port_remove): Likewise.
diff -urp gnumach-mine-2-default_noio/i386/i386/iopb.c
Has my blessing, I fixed the ChangeLog (we don't mention why a include
is included).
gnumach/ChangeLog:
2005-12-26 Samuel Thibault [EMAIL PROTECTED]
* iopb.c: Include vm_param.h.
(io_tss_init): Fix address and limit of user TSS.
diff -urp
Several things with this patch, generic-speaker.c is from what I know
non-arch dependant, so adding IA-32 seem to be wrong without taking
into account what system one is compiling things on. Also, much code
in the Hurd doesn't care what system one is running on, so adding
IA-32 specific code
Commited the following to ams-branch. Neal promised to commit it, but
he didn't.
pflocal/ChangeLog
2006-01-07 Neal H. Walfield [EMAIL PROTECTED]
* connq.c (struct connq): Changed type of HEAD to `struct
connq_request *'. Changed type of TAIL to `struct connq_request
URL:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=15355
Summary: GNU Mach doesn't support shared IRQ
Project: The GNU Hurd
Submitted by: ams
Submitted on: Tue 01/03/06 at 00:49
Category: GNU Mach
Update of bug #15355 (project hurd):
Depends on: = patch #4398
___
Follow-up Comment #2:
You mean file #5141? No. I don't recall what kind of hardware I used to
reproduce it, but any two
Update of bug #12434 (project hurd):
Status:None = Confirmed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=12434
Update of bug #15073 (project hurd):
Status:None = In Progress
___
Follow-up Comment #4:
It isn't like we are any better... :-) Sergio, Thomas, thanks for tracking
and reporting this.
Update of bug #7118 (project hurd):
Status:None = Confirmed
___
Follow-up Comment #2:
Can also be reproduced in qemu by setting the amount of avaiable memory to =
1GiB.
Update of bug #15301 (project hurd):
Severity: 3 - Normal = 2 - Minor
Status:None = In Progress
Assigned to:None = ams
Originator Name:
Update of patch #4740 (project hurd):
Status:None = In Progress
___
Reply to this item at:
http://savannah.gnu.org/patch/?func=detailitemitem_id=4740
Update of patch #4738 (project hurd):
Status:None = In Progress
___
Reply to this item at:
http://savannah.gnu.org/patch/?func=detailitemitem_id=4738
Update of patch #4737 (project hurd):
Status:None = In Progress
___
Reply to this item at:
http://savannah.gnu.org/patch/?func=detailitemitem_id=4737
Update of patch #4740 (project hurd):
Assigned to:None = ams
___
Reply to this item at:
http://savannah.gnu.org/patch/?func=detailitemitem_id=4740
Update of patch #4738 (project hurd):
Assigned to:None = ams
___
Follow-up Comment #1:
Need ChangeLog, but that is easy to do before commit.
Update of patch #4737 (project hurd):
Assigned to:None = ams
___
Reply to this item at:
http://savannah.gnu.org/patch/?func=detailitemitem_id=4737
Update of bug #15296 (project hurd):
Status:None = Need Info
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=15296
Update of bug #15295 (project hurd):
Status:None = Confirmed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=15295
Update of bug #15323 (project hurd):
Status:None = Confirmed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=15323
- and not for 3: knowing what to mount where.
I think that 3 is actually useful, but for the human and not for the
command. It is nice to have a list of what is being used where.
I'd rather see /etc/fstab just got ridden of, and e2fsck run by
/hurd/ext2fs itself upon startup (if
The action of mounting a fs is intricated with the action of
checking it beforehand, that's what I'd like to express in some
way. Fstab does that on usual unices. The hurdish way of mounting
is rather setting a translator, so I'd rather see checking being
done at translator
Is it possible to compare L4 and Mach side-by-side and have list of
features that are there in L4?
Not easily, the differences are just to big. One can make quite a
crude sketch of what the differences are, but not side-by-side in a
detailed fashion.
Is the design of Mach flawed or is
Do you think this is feasible and sensible?
No, it is a waste of time. More often than not you learn nothing,
since you are simply following steps that someone else has written for
you. Following instructions blindly is not learning, or exploring.
Also, compiling a system from scratch is
Is the GNU project propagating one size fits all here?
You are always free to modify the system to fit your needs, this is
one of the freedoms of free software.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
anyway, there's actually a tool to create a system from scratch on
Bee
This has already existed for the GNU system since about 1 year now.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Update of bug #3939 (project hurd):
Status: Fixed = None
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=3939
Unless someone has problem with me or the points listed I can
volunteer on working and reporting about the first two tasks, that
is:
* Clean up the Code. (Assigned to: We need YOU here!)
* Update the core architecture and drivers. (Assigned to: We need YOU
here!)
Please
please excuse my ignorance, but what's the Status of GNU Mach? I
heard the L4 microkernel is favored for the Hurd. Do you guys try
to catch up?
GNU Mach has always been favoured over L4 since it has always worked.
___
Bug-hurd mailing list
There are some problems with Mach which seem very hard or even
impossible to fix without using a new microkernel.
Impossible it is not, very hard it is or might be, but so is porting
to a new kernel, which is infact even harder.
For that reason, we are looking at other microkernels. We
I'm looking for improve my skills and I would like to help
too. What can I do? ;)
It all depends on what your skills are, but running through the bug
reports in the bug tracker, and double checking what still happens,
and what doesn't is a good start. Making proper bug testcases is also
That depends on your definition of what a new microkernel is. If
the changes you need to make are very fundamental, the result is
arguably a new microkernel.
New in the sense: Drop GNU Mach, use something else. Changing GNU
Mach to suit our needs so that it becomes vastly different is
1 - 100 of 758 matches
Mail list logo
