Re: [PATCH] ifconfig hurd: Notify pfinet of interfaces

Samuel, your copyright assignment is now on file.

Re: [PATCH] ifconfig hurd: Notify pfinet of interfaces

We collect as per usual copyright assignments for the GNU network utilities. Just as per normal GNU policies.

Re: [PATCH] ifconfig hurd: Notify pfinet of interfaces

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

Re: [PATCH] ifconfig hurd: Notify pfinet of interfaces

> 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 now

Re: [PATCH,HURD] Fix reading core

> > > * 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

Re: Maintenance of the Hurd parts in glibc (was: about GNU Hurd)

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 Bug-hurd@gnu.o

Re: Remove GNU Mach's unused device drivers

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

Re: Remove GNU Mach's unused device drivers

> 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

Re: Remove GNU Mach's unused device drivers

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 http://lists.gnu.org/mailman/listin

Re: Remove GNU Mach's unused device drivers

Seperate changes should have seperate headers. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Remove GNU Mach's unused device drivers

>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

Re: pcmcia-support for gnumach-1

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)

Re: Remove GNU Mach's unused device drivers

> 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

Re: Remove GNU Mach's unused device drivers

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?

Re: screen "blackened" after one hour or two in console

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. _

Re: libdiskfs: build system inconsistencies; the Hurd `collecting box'

> 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

Re: libdiskfs: build system inconsistencies; the Hurd `collecting box'

``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 bre

Re: Remove GNU Mach's unused device drivers

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

Re: libdiskfs: build system inconsistencies; the Hurd `collecting box'

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 t

Re: No to StowFS!

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 n

Re: No to StowFS!

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 informa

Re: No to StowFS!

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

Re: No to StowFS!

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

Re: Remove GNU Mach's unused device drivers

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? ___ Bug-hurd mailing

Re: [PATCH] Building the Hurd with gcc-4.0

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

Re: strict aliasing problem in GNU Mach

I corrected this. Thanks, but you did the same thing with the following: * Makerules.in: Set no_deps to true if we don't need the dependency files. * i386/linux/Makefile.in: Do care about linux-flags if no_deps is true; reverting the change from 2006-01-31. __

Re: strict aliasing problem in GNU Mach

2006-02-03 Thomas Schwinge <[EMAIL PROTECTED]> * Makerules.in: Add -fno-strict-aliasing to CFLAGS. * i386/linux/Makefile.in: Likewise for linux-gen-flags. The correct format is: * Makerules.in (CFLAGS): Added -fno-strict-aliasing. * i386/linux/Makefile.in (linux-

Re: No to StowFS!

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 / -

Re: No to StowFS!

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

Re: No to StowFS!

> 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

Re: No to StowFS!

> 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', w

Re: No to StowFS!

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. __

Re: No to StowFS!

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 http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: No to StowFS!

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 sy

Re: About Linux glue sofware interrupts. [PATCH]

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

Re: Warnings removed from linux/dev/drivers/block/genhd.c

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. __

Re: Warnings removed from linux/dev/drivers/block/genhd.c

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

Re: Warnings removed from linux/dev/drivers/block/genhd.c

>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 CONFIG_BS

Re: Warnings removed from linux/dev/drivers/block/genhd.c

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. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Warnings removed from linux/dev/drivers/block/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

Re: Warnings removed from linux/dev/drivers/block/genhd.c

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

Re: Clean gnumach code - MachRevival

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

Re: Clean gnumach code - MachRevival

[...] 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

Re: GNU Mach's build system (partly) reworked

> ./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 real

Re: GNU Mach's build system (partly) reworked

> 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 (

Re: OT: Fixed Roland'd Hurd EA ext2 patch for Linux

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 (includi

Re: OT: Fixed Roland'd Hurd EA ext2 patch for Linux

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

Re: GNU Mach's build system (partly) reworked (was: Compile GNU Mach 1.3 drivers)

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 stuff

Re: [patch #4818] Dynamic memory allocation for Linux Device drivers in glue. [PATCH] [LONG]

> 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 br

Re: [patch #4818] Dynamic memory allocation for Linux Device drivers in glue. [PATCH] [LONG]

Nice patch, overall it looks great. A bit more testing and another eyeball check, and it should go in. PS, I'm assuming that the inclusion of ../rtl8139.c was a mistake. ;) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listin

Re: gnumach and gcc 4.0 (patch 1)

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

Re: [RFC] Fix setsid(0)

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. ___ Bug-hur

Re: [RFC] PS2 mouse fix

Wonderfull. Has my OK. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Patch submission and discussion guidelines

I don't recall giving you any kind of permission to post private messages to a public list. This is what is inapprorpiate behaviour. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Patch submission and discussion guidelines

Do not post further messages like this on the bug-hurd list. I will post anything I deem justified. If you wish to complain about inapproproate messages, complain at Thomas, Michael and Marco who are trying to make this into `accuse Alfred of everything possible'. ___

Re: Patch submission and discussion guidelines

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. _

Re: Patch submission and discussion guidelines

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

Re: Patch submission and discussion guidelines

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

Re: Patch submission and discussion guidelines

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 f

Re: Patch submission and discussion guidelines

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 how

Re: Patch submission and discussion guidelines

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

Re: Boot problems with AMD64

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

Re: [RFC] de4x5 pci card probe fixup

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

Re: Boot problems with AMD64

[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 mig

Re: Boot problems with AMD64

[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 parti

Re: Patch submission and discussion guidelines

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 thi

Patch submission and discussion guidelines

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

Re: [patch] Gnumach 1.3 fails to build with make 3.81 beta

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

Re: spam filtering on the hurdextras lists

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

Re: spam filtering on the hurdextras lists

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

hurd, support new device "io"

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 shoul

gnumach, tss fixes

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 gnumach-20050801/build-dbg/machine/

gnumach, device params

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 gnumach-mine-3-device_port_fix/i386/i386

gnumach, new device 2?

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

gnumach, new device

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 for io_req_t. New "io" device. (ioopen): New function. (ioclose): Likewise. (io_bitmap_set): Treat speci

gnumach, task based IO ports

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 PROTE

gnumach, io perms

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 gnumach-mine-1-user_tss/i386/i386

gnumach, more timer stuff

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... (k

gnumach, more task based stuff

Same here, explanation behind the changes, why etc. 2006-01-02 Samuel Thibault <[EMAIL PROTECTED]> * task.c (task_init): Call new machine_task_module_init() function. (task_create): Call new machine_task_init() function. (task_deallocate): Call new machine_task_terminate

gnumach, timer controller

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 2006

gnumach, task based TSS

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

pflocal patch from neal

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

[bug #15355] GNU Mach doesn't support shared IRQ

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

[bug #15355] GNU Mach doesn't support shared IRQ

URL: 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

[bug #7118] GNU Mach can't handle 1G memory

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. __

[bug #15073] kernel panic with sis900 NIC and gnumach(-dbg) 20050801-1

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.

[bug #12434] Unix-domain (local) sockets do not support getsockname() or getpeername()

Update of bug #12434 (project hurd): Status:None => Confirmed ___ Reply to this item at: ___

Re: fs translators and fsck [Was: init scripts don't fsck extra partitions]

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 setting

Re: init scripts don't fsck extra partitions

- 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 necessa

[bug #15323] Screen insert only the first part of a copied text

Update of bug #15323 (project hurd): Status:None => Confirmed ___ Reply to this item at: ___

[bug #15295] Mach lets processes write to I/O ports

Update of bug #15295 (project hurd): Status:None => Confirmed ___ Reply to this item at: ___

[bug #15296] gnumach hangs because of Linux 2.0.36 adaptec drivers

Update of bug #15296 (project hurd): Status:None => Need Info ___ Reply to this item at: ___

[bug #15298] gnumach detects VMware's ethernet card twice

Update of bug #15298 (project hurd): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #2: I closed this since w

[patch #4737] User TSS fixup

Update of patch #4737 (project hurd): Assigned to:None => ams ___ Reply to this item at: __

[patch #4738] Patch consider_lmm_collect: Test always true

Update of patch #4738 (project hurd): Assigned to:None => ams ___ Follow-up Comment #1: Need ChangeLog, but that is easy to do before commit. __

[patch #4740] i386_io_port_remove lacks unlocking

Update of patch #4740 (project hurd): Assigned to:None => ams ___ Reply to this item at: __

[patch #4737] User TSS fixup

Update of patch #4737 (project hurd): Status:None => In Progress ___ Reply to this item at: __

[patch #4738] Patch consider_lmm_collect: Test always true

Update of patch #4738 (project hurd): Status:None => In Progress ___ Reply to this item at: __

[patch #4740] i386_io_port_remove lacks unlocking

Update of patch #4740 (project hurd): Status:None => In Progress ___ Reply to this item at: __

[bug #15323] Screen insert only the first part of a copied text

Follow-up Comment #2, bug #15323 (project hurd): Marco wrote the followin: Marcus has looked into this problem, see `term/ChangeLog' why this limit changed. IIRC there is not a clean way to fix this properly and the same problem exists on GNU/Linux. Perhaps I could lookup some IRC logs in whic

  1   2   3   4   5   6   7   8   9   >