Re: [PATCH] Large store support for ext2fs

one by one) changes stability. In summary, for really stable ext2fs there are 2 subsystems that should be fixed: 1. GNU Mach page handling. libpager in itself didn't have problems. 2. libdiskfs, having problems like those in https://savannah.gnu.org/patch/?1839 Regards, Ognyan Kulev

Re: Ognyan Kulev added to Savannah hurd group

На 15.02.2013 12:36, Thomas Schwinge написа: > Hi! > > I have just added Ognyan Kulev (ogi) to the Hurd Savannah group. Amongst > other contributions, he's well known for his ext2fs work done nearly ten > years ago. > > Ogi: Regarding Git access, for any core H

Re: Intel's EPT effect on virtualized Hurd

information may lead people to try virtualized Hurd on processor with EPT and their impression will be much better. Regards, Ognyan Kulev

Re: Patch for settrans --help

" was added for "-p". I think it'd be good if clarification is added that -a and -p are not mutually exclusive. Something like ""Set NODE's active translator. Can be combined with --passive." (I'm not native speaker.) Regards, Ognyan Kulev

Re: Drop i860 and PS2 support ?

Constantine Kousoulos wrote: > From my very brief experience with GNU Mach, i came to realise that it > is filled with oldies that are not needed anymore. So, whoever > vollunteers to clean up some of them, is more than welcome. And such clean-ups would make GNU Mach a bit more pleasant for hackin

Re: it wanted to work with the EXT3 file system

Thomas Schwinge wrote: [Cced to bug-hurd.] On Thu, May 04, 2006 at 12:21:22AM +, miguel angel maldonado wrote: it wanted to continue with the work Ognyan Kulev on the EXT3 file system When this Savannah task was entered, I wanted to comment in it but for some reason Savannah denied me

Re: Google's Summer of Code 2006

Thomas Schwinge wrote: > The following is a list of items you might want to work on. [...] :-O Is there particular reason for dropping Xen port for GNU Mach? Regards, ogi ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/list

Re: Google's Summer of Code 2006

I would like to participate in mentoring Xen port development. (After all, if noone takes this task I'll have to do it myself ;-) ) Although I'm sure that our nice Hurd community will be of great help for any of the tasks :-) Michael Banck wrote: If we could find some other (Debian) develope

Re: Google's Summer of Code 2006

Thomas Schwinge wrote: > Possible projects I thought about submitting include `libchannel', > `pfinet rewrite', `nfs / nfsd rewrite / enhancement', `GNU Mach on Xen'. It will not be surprise to anyone that I consider Xen port for the most important one :-) I would just like to mention the 2 major

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

Thomas Schwinge wrote: > The system stayed usable after installing the files, running > /hurd/ext2fs by hand didn't raise a segmentation fault. OK, thanks. I didn't invest much time in gcc 4.0 then but just switched to 3.3 :-) And the only change I've made was something about argp - I was only i

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

Thomas Schwinge wrote: The attached `hurd_v.s._gcc-4.0.patch' makes the Hurd buildable with gcc-4.0. Have you tried to boot with such compiled Hurd? I've compiled ext2fs with gcc 4.0 some weeks ago and ext2fs always raised something like SEGV even when just run from command line. Regards,

Re: mach console and auto-margin

Samuel Thibault wrote: Hum, actually I misread the documentation for the "sam" capability: no new line is added, the cursor is just put at the first column. This is only used on printers, not on terminals. So the gnumach console needs corrected. I think you are talking about http://savannah.gn

Re: Unattended issues

Alfred M. Szmidt wrote: Yes... Most communication about the Hurd nowadays is through ##hurd or #hug @ irc.freenode.net. No discussions of importance take place on IRC. All decision making is done here, on the mailing lists. Anyway, the difference in amount of communication about technic

Re: Unattended issues

Sergio Lopez wrote: Anyway, the features of Savannah doesn't make sense if there's not a maintainer looking at there regularly (and if they are not looking at here, bug-hurd, I doubt they will be looking at there). It definately makes more sense than unresponsed mails because anyone may easily

Re: Unattended issues

Jun Inoue wrote: Allow me to butt in here. Is there an archive of some sort of the discussions that take (took) place in those hurd channels? Yes: http://walfield.org/~deride/ My network's firewalled and I can't connect to IRC. (It seems freenode provides no service that would let me work a

Re: Unattended issues

Sergio Lopez wrote: El mar, 23-08-2005 a las 08:49 +0300, Ognyan Kulev escribió: IMHO In our case, it's best bugs and patches to be submitted to Savannah <http://savannah.gnu.org/projects/hurd>. Savannah may be good or bad but it's important to have easily accessible record of

Re: Unattended issues

Sergio Lopez wrote: This issues (there're many more, but I only took the most recent ones) are still waiting for attention: IMHO In our case, it's best bugs and patches to be submitted to Savannah . Savannah may be good or bad but it's important to have

Re: Build oskit-mach, immediate page fault

Joachim Nilsson wrote: > Actually, being the stubborn hard-ass that I am I managed to build and > successfully boot oskit-mach today. It's weird, but I've put up the > resulting kernel, build scripts and modules file, free for testing at Amazing :-) > It just won't die! :-) If we ignore oskit h

Re: heads up

Alfred M. Szmidt wrote: Just try solving the "where do I popup a dialog?" problem first, you'd have to write some kind of a windowing system and then force all programs to use it. Translators need "just" to support several user-interaction systems. As fallback, all translators must support consol

Re: heads up

Alfred M. Szmidt wrote: The reason that filesystems do not have user context is because I was not sufficiently far-sighted at the time to realize the full flexibility of the translator concept I had created. No, it is because they can't have "user context", but feel free to disprove me wit

plans about the ext2fs patch

Hi, I would like to share my plans about inclusion of the ext2fs patch for supporting large stores. As you all know, the patch is in Debian's hurd package since December 2004 and it's still not dropped from there :-P Unfortunately, it's reported that it adds small amount of instability. I bla

Re: GNU Mach panic

Alfred M. Szmidt wrote: It is already documented in the --help output for configure, and in the GNU Mach documentation, so there is no need to mention this on the wiki. Yes, kdb is documented in GNU Mach Reference. But I'm not aware of documented precise instructions how to make good report for G

Re: GNU Mach panic

Thomas Schwinge wrote: Another GNU Mach panic: #v+ panic: zalloc: zonethreads exhausted Kernel Breakpoint trap, eip 0x11a07e Stopped at 0x11a07d: int $3 db> continue panic: zalloc: zone kalloc.256 exhausted Kernel Breakpoint trap, eip 0x11a07e Stopped at 0x11a07d: int $3 db> reset #v- How have you

Re: Gnufans Wiki. (Was: Re: qemu booting of hurd/l4 how-to)

Joachim Nilsson wrote: This week we will upgrade the server that runs hurd.gnufans.org, from the old PII 266MHz 384MiB to a new Sempron based with 1GiB. So the site will become a little bit easier to work with as well. Can we expect upgrade of the TWiki software too? :-P Regards, ogi _

Re: hangs with (hd0,2)/hurd/ext2fs.static

Shakthi Kannan wrote: GNU Mach 1.3 AT386 boot: physical memory from 0x0 to 0x7ff ...pci probe Partition check (DOS partitions): hd0: hd0: status timeout: status=0xff { Busy } hd1: disabled DMA hd0: drive not ready for command ide0: reset timed-out, status=0xff h

Re: spam

Dmitriy Tochansky wrote: Why are there so much spam?! Because anyone can post to GNU mailing lists without being subscribed (to ease asking questions), and there are no spam filters on the GNU servers. It's expected that subscribers will do filtering on their side (Junk Control in Mozilla *, et

Re: A Hurd release

Marcus Brinkmann wrote: It is true that the email notifications are mostly useless, and I usually only use them as an indication that something changed. If everyone agrees they are useless, we can disable them. It's simple enough to do. Or we could go and help the savannah people make them useful

Re: Screensaver support for the Hurd console

Alfred M. Szmidt wrote: (set! driver-path '("~/console-drivers" "/lib/hurd/console-client")) (set! drivers '(vga pc_kbd pc_speaker)) (set! vga/font "10x20") (set! vga/max-colors 256) (set! dpms/standby 'vga-standby (set! dpms/off 'vga-off (set! dpms/standby-timeout 400) Isn't it enough something li

[bugs #11509] fakeroot is not reliable

This mail is an automated notification from the bugs tracker of the project: The GNU Hurd. /**/ [bugs #11509] Latest Modifications: Changes by: Ognyan Kulev <[EMAIL PROTECTED]> 'Date:

Re: A Hurd release

Daniel Godás wrote: Ok, after the presentation. I have taken a look at the archives and the dev-hurd list archives are very outdated, why? why is this topic beeing discussed in this list and not there? You probably mean hurd-devel. It's only for core developers. The two active core developers (Ma

[bugs #11509] fakeroot is not reliable

e GNU Hurd Submitted by: Ognyan Kulev On: Thu 01/06/2005 at 20:01 Category: None Severity: 5 - Average Priority: 5 - Normal Item Group: None Resolution: None Privacy: Public Assigned to: None Originator Name: Originator Email: Status: Open Reproducibility: Intermittent Size (loc): N

Re: A Hurd release

Alfred M. Szmidt wrote: Buggy software gives bad impression and I think we should at least mark the bad things. All software is buggy, and we aren't talking about a 1.0 release, just 0.3 anyway. So I don't think this is a problem. It's mostly psychological problem. If someone is Hurd newbie

Re: A Hurd release

Marco Gerards wrote: Anyway, I hope to start a discussion with this email. It would be nice if the Hurd maintainers would make it clear what needs to be done before the Hurd 0.3 can be released or if they just release it. Yes, I think the most important thing now is to clearly set what are the re

Re: Changes to the filesystem while find is running - comments?

/* Removing Cc:bugtraq (moderated), Adding Cc:bug-hurd I'm sorry if you are in Cc: and you're not interested */ James Youngman wrote: On Wed, Nov 24, 2004 at 07:50:59AM +0200, Ognyan Kulev wrote: James Youngman wrote: On Mon, Nov 22, 2004 at 06:05:43PM -0800, Martin Buchholz wro

bug-hurd@gnu.org

e GNU Hurd Submitted by: Ognyan Kulev On: Mon 11/08/2004 at 07:33 Category: None Priority: 3 - Low Resolution: None Privacy: Public Assigned to: None Originator Email: Status: Open Summary: [libports] Unnecessary condition_broadcast (&_ports_block) Original Submission: The attach

bug-hurd@gnu.org

Hi, The attached patch fixes same type of typos in resume code of libports. This way the optimization to broadcast _ports_block only when needed is fixed. Regards, ogi 2004-11-03 Ognyan Kulev <[EMAIL PROTECTED]> * resume-all-rpcs.c (ports_resume_all_rpcs): Broadcast block conditio

Re: rollover translator

Ognyan Kulev wrote: POSIX read/write can't work as expected when filesystem changes file pointer at fs's own will. Perhaps it's not explicitly stated in POSIX, but it's expected that noone except file descriptor's owner can change file pointer. After thinking more about

Re: rollover translator

Alfred M. Szmidt wrote: I'm not sure if POSIX allows filesystem (by its own will) to change file offset of user file descriptor. We don't have to care about POSIX here. If program uses POSIX API, then there should be POSIX behaviour. In POSIX, each file descriptor has file pointer/offset/wh

Re: rollover translator

Ognyan Kulev wrote: Another possible implementation is to use sparse blocks: keeping everything before the last X bytes to be sparse blocks. So file will be huge, but only the part we are interested in is saved physically. But I think we don't have RPC that make sparse blocks inside file

Re: rollover translator

Alfred M. Szmidt wrote: I got this funky idea today, but I'm not sure what would be the best way to implement it. What it would essentially do is provide a "circular file", so when you get to the end of the file you start from position 0. With the nice option that if you do roll over, you can cle

Re: rollover translator

Alfred M. Szmidt wrote: If program uses POSIX API, then there should be POSIX behaviour. Meh, I was unclear. What I meant was that the translator can do whatever it wants to the file offset. Aslong as read/write/whatever work as expected. One way to circumvent this is by declaring that this

[EXT2FS] New snapshot ext2fs_20040930

Hi, I've released new development snapshot 20040930 in http://debian.fmi.uni-sofia.bg/~ogi/hurd/ext3fs/ . I've published pre-compiled ext2fs.static.big binary too. For paranoids, the patch and ext2fs are signed by my GPG, which is signed by Debian Developer (zinoviev@). The snapshot seems ver

Re: [PATCH] libpager/data-request.c: missing call to _pager_allow_termination

agemap_resize succeeds. I think the other callers are, however, okay.) Yes, there are some other problems too, like in pager_offer_page and its use of semantics of PM_INCORE. 2004-09-28 Neal H. Walfield <[EMAIL PROTECTED]> Ognyan Kulev <[EMAIL PROTECTED]> I&#x

[PATCH] libpager/data-request.c: missing call to _pager_allow_termination

2004-09-28 Ognyan Kulev <[EMAIL PROTECTED]> * data-request.c (_pager_seqnos_memory_object_data_request): When pager state is not NORMAL, shorten exit path. When _pager_pagemap_resize fails, add call to _pager_allow_termination. diff -urpN --exclude='*~

Bug#273507: Final solution for SUID programs

Package: hurd Version: 20040508-4 UNRELEASED Severity: important Tags: sid patch SVN hurd package doesn't really set SUID bit for /bin/login because chmod u+s is not executed on the correct file. The attached patch sets SUID of /bin/login and other SUID programs. Regards, ogi Index: rules =

Bug#273508: Fix for invocation of e2fsprogs's fsck

Package: hurd Version: 20040508-4 UNRELEASED Tags: sid patch The fsck is called with options -C -R -A. But -R option is for not fsck:ing the root filesystem. The attached patch fixes this, and also correctly remounts the root filesystem. Regards, ogi --- rc 2004-09-26 19:58:38.0 +0300

Re: Build oskit-mach, immediate page fault

Michael Banck wrote: I get this error on two different machines, a P2-400 and a P-M-1500. Marco told me that this error is also experienced by several other people. Yes, I've often experienced this on some machines too. There were some clues in the mailing lists, but I couldn't find them with Goo

Bug#272655: complete fix?

Огнян Кулев wrote: I, as ogi-guest, can't read pkg-hurd repository, so I can't check. OK. It can be viewed from http://svn.debian.org/ :-) And the options to e2fsck in /libexec/rc are not fixed. Regards, ogi ___ Bug-hurd mailing list [EMAIL PROTECTED] h

[bugs #10440] ls -l /dev gives huge total size of directory

e GNU Hurd Submitted by: Ognyan Kulev On: Sun 09/19/2004 at 05:59 Category: None Severity: 5 - Average Priority: 5 - Normal Item Group: None Resolution: None Privacy: Public Assigned to: None Originator Name: Originator Email: Status: Open Reproducibility: None Size (loc): None Eff

Re: console translator set without encoding

Patrick Strasser wrote: I'm not shure if this is a Debian issue. Why should Debian have a different default encoding? Yes, such change should affect upstream behaviour too. I hope this to go in the next hurd upload, which is eagerly expected by many of us. Regards, ogi _

[PATCH][SNAPSHOT 20040819] ext2fs and large stores (> 2G)

Hi, I've applied Neal's changes in libpager and did minimal testing. The resulting snapshot patch is in http://debian.fmi.uni-sofia.bg/~ogi/hurd/ext3fs/ BUILDING Unfortunately, the following hack has to be applied before build: In libdiskfs/diskfs-pager.h, replace this line: #include

[patch #3330] HURD_IHASH_ITERATE_KEYS

This mail is an automated notification from the patch tracker of the project: The GNU Hurd. /**/ [patch #3330] Latest Modifications: Changes by: Ognyan Kulev <[EMAIL PROTECTED]> 'Date:

[patch #3330] HURD_IHASH_ITERATE_KEYS

e GNU Hurd Submitted by: Ognyan Kulev On: Wed 09/01/2004 at 07:18 Category: libihash Priority: 3 - Low Resolution: None Privacy: Public Assigned to: None Originator Email: Status: Open Summary: HURD_IHASH_ITERATE_KEYS Original Submission: New for loop that loops only once is used. Its

[patch #3329] -1 is cast to uint32_t instead of store_offset_t

e GNU Hurd Submitted by: Ognyan Kulev On: Wed 09/01/2004 at 06:50 Category: None Priority: 5 - Normal Resolution: None Privacy: Public Assigned to: None Originator Email: Status: Open Summary: -1 is cast to uint32_t instead of store_offset_t Original Submission: Conditional operator ?:

Re: the watchdog of login program

Roland McGrath wrote: auth_makeauth will fail when the caller is authenticated as nonroot. You mean auth_makeauth inside ugids_verify_make_auth, right? Without being root, login makes ids of new user. Isn't it right that password_check_{user,group}, used as default verify_fn function in ugids_v

Re: the watchdog of login program

Roland McGrath wrote: There probably should be a runtime check in login that would catch this. For example, checking for errors from proc_setowner would be good. It also shouldn't manage to make the auth handles it asks for, and should be complaining about that. I don't understand the last sentence

Re: the watchdog of login program

/* Cc: Jeff */ Roland McGrath wrote: Both 251863 and the failure to set owner could be the same problem. They would both happen if the login process were not properly authenticated as root (to the proc server for setowner and to the tty filesystem for chown). I've finally found what's going on: lo

the watchdog of login program

Hi, When login is run as ordinary user, and, more importantly, from inetutils-telnetd, the following process appears (this is the ps name): (watchdog for login 2107: 5 minutes remaining) When time expires, the session is killed, login:ed or not. telnetd runs login as root, but this doesn't prev

Re: libparted gnu.c patch.

Harley D. Eades III wrote: I was unaware you can open device paths with store_typed_open. I thought you had to use store_open? Reference Manual and store.h are incomplete about store_typed_open. Here is what is in libstore/typed.c, and what the code does: /* Open the store indicated by NAME, w

Re: libparted gnu.c patch.

Ognyan Kulev wrote: (This patch is a hack and if it's applied, it should be reverted when the real bug (in libc and hurd) is fixed.) Just to clarify: hack is the switch if store_typed_open or store_open to be used. Regards, ogi ___ Bug-hurd ma

Re: libparted gnu.c patch.

Harley D. Eades III wrote: I am working on an fdisk interface to libparted for GNU/Hurd. Also, I have been working on fixing problems related to libparted in GNU/Hurd. With, some help from Alfred M. Szmidt. Here is a patch for libparted/gnu.c which adds a test to determine if the us

Re: Error with Ogi's ext2fs patch

Michael Banck wrote: ext2fs.static: hurdmalloc.c: 246: more_memory: Unexpected error: (os/kern) invalid argument I've never experienced such error. Google doesn't find anything too. Hmm, tough bug. The file system seemed to be totally corrupted afterwards, this is a snippet from the e2fs

Re: Review of Thomas's >2GB ext2fs proposal

Thomas Bushnell BSG wrote: Ognyan Kulev <[EMAIL PROTECTED]> writes: Just a small techical correction: we remove mapping only when we are remapping page to contain another block. So when page is evicted, it continues to map the same disk block until ext2fs decides that we want this page t

Re: Review of Thomas's >2GB ext2fs proposal

Thomas Bushnell BSG wrote: I'm confused. It sounded like Ognyan was saying that the page is still assigned to the same area. But it is necessary to vm_free when the kernel tells you to page out. It is unfriendly (and very bad for performance) to hold on to the page. vm_free is something that lib

Re: Review of Thomas's >2GB ext2fs proposal

Neal H. Walfield wrote: If that is the case, then I think we should drop the whole reference counting system and have the accessor functions just do a vm_map and vm_unmap as required. Surely you don't want ext2_getblk to vm_map/vm_unmap 1024 times the same single indirect block for a 4M file when

Re: Review of Thomas's >2GB ext2fs proposal

Thomas Bushnell BSG wrote: I only cache mappings, so it doesn't really matter. Creating mappings is very very cheap (especially if you allow Mach to pick the addresses by using the anywhere flag). Creating mappings is just vm_map, which is speedy and quick--it's the same as vm_allocate. But I wo

Re: Review of Thomas's >2GB ext2fs proposal

Hi, I'm back online :-) Neal H. Walfield wrote: Yes, we remove the data from memory any time we remove a mapping but we only remove mappings when Mach evicts the data. Just a small techical correction: we remove mapping only when we are remapping page to contain another block. So when page is evi

No ext2fs patch today

Hi, Yesterday I've said that today I'll post updated ext2fs. Unfortunately, time was not enough, so I'm leaving it for next Wednesday. Regards, ogi ___ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: please re-activate notifications on commit

Marco Gerards wrote: Jeff did this already (friday IIRC). It should be fixed. Does it include all modules: fabrica, gnumach, hurd, hurd-l4 and mig? I think it's good if commit-hurd catches commits to all these modules. Regards, ogi ___ Bug-hurd mailin

[bugs #9960] High 16 bits of st_nlink are sometimes corrupted

e GNU Hurd Submitted by: Ognyan Kulev On: Tue 08/10/2004 at 18:14 Category: None Severity: 5 - Average Priority: 5 - Normal Item Group: None Resolution: None Assigned to: None Originator Name: Originator Email: Status: Open Reproducibility: Intermittent Size (loc): None Effort: 0.00

please re-activate notifications on commit

Hi, I've just noticed that automatic notifications of commits can be enabled again[1] :-) Please someone with permissions to do so. [1] http://savannah.gnu.org/forum/forum.php?forum_id=3197 Regards, ogi ___ Bug-hurd mailing list [EMAIL PROTECTED] http:

[bugs #9963] gdb attach to settrans -aP ext2fs triggers assertion

e GNU Hurd Submitted by: Ognyan Kulev On: Tue 08/10/2004 at 19:35 Category: None Severity: 5 - Average Priority: 5 - Normal Item Group: None Resolution: None Assigned to: None Originator Name: Originator Email: Status: Open Reproducibility: Every Time Size (loc): None Effort: 0.00 Sum

[bugs #9961] In Mach console, writing character when in last column scrolls

e GNU Hurd Submitted by: Ognyan Kulev On: Tue 08/10/2004 at 18:22 Category: GNU Mach Severity: 5 - Average Priority: 5 - Normal Item Group: Standard Compliance Resolution: None Assigned to: None Originator Name: Originator Email: Status: Open Reproducibility: Every Time Size (loc): N

Close patch #2997 too

As I said in a comment, this patch fixes nothing. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd

Bug#264858: hurd-dbg and hurd-doc packages

Package: hurd Version: 20040508-2 Severity: wishlist It's good if source package generates hurd-dbg and hurd-doc too. hurd-doc should be Architecture: all. Regards, ogi ___ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/b

Please close patch #1606

Hi, Patch #1606 is totally useless, given that now CDBS is used for hurd package. Please, someone to close it. Altough I'm submitter, I can't close it. Regards, ogi ___ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug

ext3fs 0.1 for the Hurd

/* Cc: ext2-devel, to let them know about this effort. */ I'm very pleased to announce the first publicly available version of the ext3fs translator for the Hurd. Download location: http://debian.fmi.uni-sofia.bg/~ogi/hurd/ext3fs/ This is pre-alpha quality software and it's unusable for any seri

Bug#263748: Split fakeroot into a separate package.

Robert Millan wrote: We're eventualy going to port fakeroot. So if we want it installable on GNU, the [/usr]/bin/fakeroot the Hurd package provides should be split in a separate package (e.g. hurd-fakeroot) that conflicts and provides fakeroot. dpkg-divert? Or it's not suited for this kind of stu

Re: is anyone working on PCMCIA

Yaakov wrote: is hurd ever going to adopt OSKit, and should i focus on making my code work within OSKit, or would i just be better off working on my own flavor borrowing code from the aformentioned example along with what ever else i do? Officially oskit-mach will become GNU Mach 2.x, but AFAIK noo

Re: [PATCH] eepro100.c on Thinkpad T30

Andre Caldas wrote: It was not mine the thread owner is: [EMAIL PROTECTED] :-) One more sorry. I've replied too fast to see that mail was not from the author ;-) Regards, ogi ___ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman

Re: [PATCH] eepro100.c on Thinkpad T30

On Thu, Aug 05, 2004 at 02:18:48PM +0900, Andre Caldas wrote: > I think those are the lines you had to _ignore_... I misunderstood your second mail. Sorry. Of course, just adding PCI IDs is OK and welcomed. Regards, ogi ___ Bug-hurd mailing list [E

Re: [PATCH] eepro100.c on Thinkpad T30

/* help-hurd and debian-hurd are stripped. */ arief# wrote: @@ -681,8 +775,8 @@ #endif pcibios_read_config_byte(pci_bus, pci_device_fn, PCI_INTERRUPT_LINE, &pci_irq_line); -

Re: Ognyan's libpager changes

Marco Gerards wrote: Does that include journaling as the name suggests? Yes :-) But 0.1 will be alpha-quality or worse. Regards, ogi ___ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Ognyan's libpager changes

Neal H. Walfield wrote: As a start to getting back into Hurd hacking mode, I have begun to review your ext2fs patch for large file system support. At this point, I have only reviewed the libpager changes in any detail. I want to work with you to develop a well thought out interface and implementa

Re: console-client signal handling

Ognyan Kulev wrote: Marco Gerards wrote: Many people complain on IRC about the console client and that it does not catch the signals. So when you send a SIGTERM signal to the console it does not correctly clean up its state. The same is true for the SIGINT signal. Why not add SIGQUIT too? Or

Re: console-client signal handling

Marco Gerards wrote: Many people complain on IRC about the console client and that it does not catch the signals. So when you send a SIGTERM signal to the console it does not correctly clean up its state. The same is true for the SIGINT signal. Why not add SIGQUIT too? Regards, ogi __

Bug#196913: please redo the patch

Robert Millan wrote: This patch does no longer apply to the debian hurd package, since the rules file has been rewritten. Ogi, please have a look. The patch had the following features: * Documentation is split into hurd-doc * New package hurd-dbg * hurd.msgids is part of the hurd package. Jeff, wha

character devices appear in reused filesystem

Hi, After a crash that made the filesystem useless, I've reinstalled my hurd without initializing the partition with mke2fs, just e2fsck under Linux and rm -fr. Unfortunately, when working with the newly-installed system sometimes some files become character devices. rm them gives something l

Re: libps/libihash

Michael Banck wrote: On Tue, Jun 15, 2004 at 08:04:02PM +0200, Marcus Brinkmann wrote: As the code is inherently non-portable, it would be simple and feasible to add -std=gnu99 to the Makefiles of dpkg for this single file only, or only if the target architecture is the Hurd. That's what Ogi did, b

Re: X and other visions

Marco Gerards wrote: There was quite a lot of testing done by people in #hurd. Some people use a >2GB partition as root partition, IIRC. That's nice to hear :-) Can you tell us how people can help you? Testing? Bug reports? etc... Yes, the easiest is just to use it. When there is a problem, I

Re: Journalling filesystems

Bas Wijnen wrote: On Mon, Jun 14, 2004 at 07:24:25PM +0200, Alfred M. Szmidt wrote: I think they should be implemented in the Hurd. Would you like todo this? Yes, I would. But as Ognyan says: But we are far away from all that, and IMHO we should first finish porting to L4 before dealing with suc

Re: Journalling filesystems

Bas Wijnen wrote: While we're talking about "what really should be supported", I have an other idea. I went to a lecture about smartcard filesystems some time ago and it was partly about journalling filesystems. I think they should be implemented in the Hurd. I'm implementing ext3 server for the

Re: X and other visions

Alfred M. Szmidt wrote: As long as work on ext3fs is progressing I'm personally quite happy, since you can always use ext3fs to mount a ext2 partition. Heck, I don't particulary see the need for the ext2fs patch if ext3fs will exist; but thats me. ext2fs patch is much more important, because it ne

Re: X and other visions

Alfred M. Szmidt wrote: How is the work with ext2fs comming along anyway? Stalled. I'm distracted with many things and my main Hurd fight is ext3fs now, not the ext2fs patch. The last problem with ext2fs patch was with building Debian's glibc (freeze when first patch 00cvs is applied) but it wa

Re: X and other visions

[EMAIL PROTECTED] wrote: Please do not ignore or flame down me because I'm not so used to hacking that stuff. I think I'm experienced enough to GNU/Linux to know how a realization should not look like, and I'd like GNU/Hurd to be better. It's good you are concerned with Hurd's future, but I think w

Bug#254147: hurd: /libexec/rc is not executable

Package: hurd Version: 20040508-2 Severity: normal Tags: sid /libexec/rc is not executable, and it's run by /libexec/runsystem.gnu when system boots. This interrupts boot process, and "single-user mode" (if this can be applied to the Hurd) is entered. The file just has to be made executable. -- Sy

libc0.3-dev 2.3.2.ds1-12.0.1 causes bad build of ext2fs.static

Hi, When libc0.3-dev 2.3.2.ds1-12.0.1 by Michael Banck is installed, compilation of the Hurd leads to bad ext2fs.static that always signals SEGV. (ext2fs and other executables seem fine.) When older 2.3.1-5 is installed, ext2fs.static is fine. Unfortunately, it's too difficult for me to track

[BUG][LIBC] getcwd gives up too easily

Hi, getcwd constructs pathname by dir_lookup(".."). When root of translated file system is found, dir_readdir is run for the directory that contains the translator. For each directory entry, dir_lookup is called in order to find the translated node. The problem is that if dir_lookup fails fo

Re: [Fwd: [bug #6047] rm -f "" prints diagnostic message under the Hurd]

Roland McGrath wrote: Try this and if it's good I'll check it in. All tests passed as wanted (with ENOENT instead of EINVAL). --- hurdlookup.c.~1.52.~ 2003-02-25 16:21:43.0 -0800 +++ hurdlookup.c 2004-04-30 13:25:07.0 -0700 BTW Here is a changelog entry in

Re: [Fwd: [bug #6047] rm -f "" prints diagnostic message under the Hurd]

Marcus Brinkmann wrote: I'd like Roland's opinion on this. Roland, for many functions using dir_lookup we get EINVAL rathern than the ENOENT required by POSIX when a pathname is the empty string "". Where should this be fixed? Just a small correction: dir_lookup will treat "" like ".". The probl

  1   2   3   >