Re: Regarding copyright assignment to FSF

[Michael Banck]

Hi,

On Thu, Aug 12, 2021 at 12:18:20PM +1000, Damien Zammit wrote:
> On 11/8/21 11:01 pm, Ludovic Courtès wrote:
> > It would be interesting to consider dropping the copyright assignment
> > requirement for Hurd/Mach/MiG.  For what remains primarily a hobby
> > project, this looks to me like a hindrance more than anything else.
> 
> I imagine it is slightly inconvenient for new contributors, but not a
> hindrance in my opinion.

The fact that this process potentially or apparently took (or rather,
has been taking) months for Sergey (I don't know when it was initiated),
is a pretty good indicator that it is more than a nuisance.

> It ensures that FSF has complete control of the licensing.

I don't mind that, but I also think the Hurd is not a tactical FSF asset
anymore that needs to be kept under tight control. The FSF has enough
copyright in the Hurd that it can enforce it whenever it likes, even if
other people's copyrighted code (as is already the case with the pfinet
stack) is added. Finally, the GPLv2+ code can always be licensed to
GPLv3+ once all the GPLv2only code has been removed, no copyright
assignments are required there, either.

So if the Hurd maintainers would like to drop the requirement (as has
been done with GCC and glibc in recent months), I would support that.


Michael

Re: Regarding copyright assignment to FSF

[Michael Banck]

Hi,

On Sat, Aug 14, 2021 at 02:19:12PM +0200, Dr. Arne Babenhauserheide wrote:
> Michael Banck  writes:
> 
> > I don't mind that, but I also think the Hurd is not a tactical FSF asset
> > anymore that needs to be kept under tight control. The FSF has enough
> > copyright in the Hurd that it can enforce it whenever it likes, even if
> > other people's copyrighted code (as is already the case with the pfinet
> 
> I wouldn’t be so sure about that.
> 
> 1. Without copyright assignment of all code involved, enforcement
>becomes much harder.

I don't think "much harder" can be quantified in a meaningful way,
seeing how parts of the Hurd aren't under the FSF copyright at this
point, anyway.

> 2. The Hurt still provides capabilities other OS’es don’t — while
>maintaining POSIX compatibility. We’ve seen audacity basically
>being taken over by a company in the past months, so the danger of
>losing Hurd to proprietarization rather got bigger than smaller.

Nobody proposes that the FSF relicenses the Hurd to a non-copyleft
license before relinquishing the copyright assignment mandate, so I
don't see how the Hurd continueing to be under a GPLv2+ license will
ever be able to be taken proprietary.

I'm not going to respond further on this thread, this is starting to get
off-topic really quick and if there are further things to be discussed,
gnu-system-discuss or whatever other mailing list is likely the better
place.


Michael

Re: It runs!

[Michael Banck]

On Fri, May 12, 2023 at 09:30:34PM +0300, Sergey Bugaev wrote:
> Hello everyone, I've got some exciting news :)
> 
> /bin/sh runs!!!
> 
> Things start up all the way -- exec, proc, auth, all that. Then
> /hurd/startup exec's /libexec/console-run; I placed a little shell
> script there. The shell (dash) starts up, loads the script, and starts
> executing it! And (this required another tweak to TLS) it manages to
> fork and exec a command!
> 
> The command being "settrans -ac /dev/mach-console /hurd/streamio
> console" -- and that seems to (mostly?) succeed too, streamio starts
> up and settrans does call file-set-trans on the ext2fs. But I haven't
> yet been able to receive any actual output from the shell or
> subsequent commands on the console.
> 
> But -- we now have enough of Unix working to fork and to run /bin/sh!
> How cool is that?!

Woot!


Michael

Re: kvm with hurd-k16.img

[Michael Banck]

On Mon, Nov 03, 2008 at 09:42:01AM +0530, Vikram Vincent wrote:
> 2008/11/2 Shakthi Kannan <[EMAIL PROTECTED]>
> 
> > Hi,
> >
> > --- On Sun, Nov 2, 2008 at 7:37 PM, Shakthi Kannan <[EMAIL PROTECTED]>
> > wrote:
> > |  kvm -boot a -hda hurd-k16.img -fda grub-0.97-i386-pc.ext2fs -m 512
> > \--
> >
> > It was reported here:
> > http://paste.lisp.org/display/67296
> >
> > Had to use it with -no-kvm-irqchip or -no-kvm-pit.
> >
> > For setting up kvm on debian, this documentation is useful:
> > http://kvm.qumranet.com/kvmwiki/Debian
> >
> >
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498940

Is it trivial to apply the fix which went into 2.6.27 to 2.6.26?  If
that's the case, maybe a bug against linux-2.6 should be reported,
requesting it be fixed for the 2.6.26 lenny kernel.


Michael

Re: kvm with hurd-k16.img

[Michael Banck]

reassign 498940 linux-2.6
retitle 498940 [patch] linux-2.6.26 KVM fails to boot Mach
severity 498940 important
tags 498940 +patch
tags 498940 +fixed-upstream
thanks

On Mon, Nov 03, 2008 at 11:28:53AM +0100, Samuel Thibault wrote:
> Michael Banck, le Mon 03 Nov 2008 11:09:08 +0100, a écrit :
> > Is it trivial to apply the fix which went into 2.6.27 to 2.6.26?
> 
> Yes:
> 
> commit f697554515b06e8d7264f316b25e6da943407142
> Author: Aurelien Jarno <[EMAIL PROTECTED]>
> Date:   Fri May 2 17:02:23 2008 +0200
> 
> KVM: PIT: support mode 3
> 
> The in-kernel PIT emulation ignores pending timers if operating
> under mode 3, which for example Hurd uses.
> 
> This mode should output a square wave, high for (N+1)/2 counts and low
> for (N-1)/2 counts. As we only care about the resulting interrupts, the
> period is N, and mode 3 is the same as mode 2 with regard to
> interrupts.
> 
> Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
> 
> diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
> index 735ec9a..60074dc 100644
> --- a/arch/x86/kvm/i8254.c
> +++ b/arch/x86/kvm/i8254.c
> @@ -308,6 +308,7 @@ static void pit_load_count(struct kvm *kvm, int channel, 
> u32
> create_pit_timer(&ps->pit_timer, val, 0);
> break;
> case 2:
> +   case 3:
> create_pit_timer(&ps->pit_timer, val, 1);
> break;
> default:
> 

OK, so reassigning to linux-2.6.  Linux kernel maintainers, please apply
this patch for lenny if another upload is done.


thanks,

Michael

Re: Hurd does not want to build

[Michael Banck]

On Wed, Nov 05, 2008 at 10:33:30PM +0200, Sergiu Ivanov wrote:
>   cd hurd/; make
> 
> which dies with the following error message:
> 
>   ar: creating libshouldbeinlibc.a
>   libshouldbeinlibc.a
>   make[1]: libshouldbeinlibc.a: Command not found
>   make[1]: *** [libshouldbeinlibc.a] Error 127
>   make[1]: Leaving directory `/tmp/hurd/libshouldbeinlibc'
>   make: *** [libshouldbeinlibc] Error 2

Sounds like the ranlib executable is missing, do you have binutils
installed?

"grep RANLIB config.make" probably returns an empty "RANLIB="?


Michael

Re: Fwd: Gentoo GNU/Hurd thread in Gentoo Forums

[Michael Banck]

On Sat, Nov 08, 2008 at 08:23:41AM +0200, Sergiu Ivanov wrote:
> I see... Well, I hope I'll have some time to port emacs to Hurd,
> because, frankly speaking, it's uncomfortable for me to realize that
> *GNU* Emacs does not run on *GNU* Hurd...

Maybe you're doing something wrong then, because GNU Emacs has been
running on GNU Hurd ever since I can remember.

Of course, oweing to the nature of Debian unstable, the emacs22 Debian
package might be uninstallable at times due to missing or outdated
dependencies.  Right now, it seems to be installable without problems,
though.


Michael

Re: Fwd: Gentoo GNU/Hurd thread in Gentoo Forums

[Michael Banck]

On Sun, Nov 09, 2008 at 07:08:30AM +0200, Sergiu Ivanov wrote:
> However, do you mean that I can download the sources of emacs22 and
> they will build successfully on Hurd?

Two weeks ago, that was the case:
http://buildd.debian-ports.org/fetch.php?&pkg=emacs22&ver=22.2%2B2-4&arch=hurd-i386&stamp=1224933865&file=log&as=raw


Michael

Re: status

[Michael Banck]

Arne,

On Sun, Nov 09, 2008 at 11:26:24AM +0100, Arne Babenhauserheide wrote:
> If Viengoos fullfills the hopes I have in it since I read the paper from 
> Neal, 
> then it's likely that the GNU/Hurd will be ported to it. 

You can have your hopes however you want, but it is not very productive
to hype up Viengoos as the next microkernel at this point.  Neal has
made it clear that he considers it a research project and currently not
suitable for the Hurd to use, nor does he currently have the intention
to do the porting and/or necessary work to have Viengoos suitable for a
mainstream operating system.

The Hurd project said it would move to L4, this project has failed and
people are still confused about this several years later.  We should
learn from this and not make any announcements or predictions on how or
when the Hurd will move to a new microkernel until such a project is a
reality.  


Michael

Re: Niche for Hurd - discussion - the power of translators

[Michael Banck]

On Tue, Nov 11, 2008 at 03:58:39AM +0100, [EMAIL PROTECTED] wrote:
> I wonder what it would take to get this into Debian as default...

Uhm, how about starting with a whishlist bug first?


Michael

Re: Niche for the Hurd - summary 2 - niches sorted according to necessary work

[Michael Banck]

On Thu, Nov 13, 2008 at 05:42:49PM +0100, Arne Babenhauserheide wrote:
> I think to make it *the* GNU system we'd need it in a state where I can just 
> start any desktop on it and work with it just like in a GNU/Linux, because 
> else people would just shrug and say "This is GNU then, I think I'll stick 
> with GNU/Linux". 

That's not the definition of *the* GNU system.  *The* GNU system is the
system made/distributed by the GNU project.


Michael

Re: Report in Swedish, English or both?

[Michael Banck]

Hi,

On Wed, Jan 07, 2009 at 10:38:48PM +0100, Carl Fredrik Hammar wrote:
> I'm slightly torn however, partly because I'm more proficient in Swedish.
> And partly because Swedish is in such a poor state when it comes to
> computer science.  Often terminology is borrowed form English even though
> there is viable Swedish words that could replace them.  It would be nice
> to make a contribution in this area.

I think it has to be accepted that while it is possible to write in and
improve your own language, the only viable way when it comes to
contributing to the scientific community is in english.  This may be
less important for this work (but much more so in terms of practical
usefulness to the technical Hurd community, as Olaf pointed out), but
the more you write, the more important it will be that it can be peer
reviewed by non-swedish readers as well.

Thus, I would advise you to write this in english even if your english
is not perfect and it will take longer; it will certainly be fruitful
for the inevitable further publications from you in english, and the
sooner you become familiar with writing scientific publications in
english, the better for your scientific output, I think.


regards,

Michael

Re: Does the cross toolchain really work?

[Michael Banck]

On Thu, Jan 22, 2009 at 10:58:56AM +0800, newper wrote:
> But when I restart the computer it still hang at Hurd sever
> bhootstrap: ext2fs.static[device:hd0s2]exec
> You tell me to enable-kdb when compiling gnumach,but I don't know how
> to use it.

When you --enable-kdb, Mach will drop you into the kernel debugger
instead of rebooting.  However, as you're now having a Hurd issue (exec
hanging) that won't help you here. 


Michael

Re: A GNU/Hurd Roadmap dream

[Michael Banck]

On Tue, Jun 02, 2009 at 10:22:45PM +0200, Arne Babenhauserheide wrote:
> This is the Roadmap I dreamt of: 

Sorry, but this is a wishlist, not a roadmap.


Michael

Re: Hurd build fails on my box

[Michael Banck]

On Sat, Jun 13, 2009 at 09:32:25PM +0300, Sergiu Ivanov wrote:
> I'd like to remark, though, that (on my box) the set of patches I get
> from apt-get and from svn is different... More exactly, the apt-get
> version misses (at least) the ``series'' file and a number of patches
> (like the in6_addr.patch you mentioned). Is this okay or am I doing
> something wrong again?

It's the difference between the last upload of the package, and the
current svn-state of the packaging.

In other words: We should upload the package again some day...


Michael

Re: News 2009-10-31

[Michael Banck]

On Mon, Nov 02, 2009 at 03:58:57PM +0100, Arne Babenhauserheide wrote:
> Am Montag, 2. November 2009 15:29:47 schrieb Thomas Schwinge:
> > > -> http://www.bddebian.com/~hurd-web/news/2009-10-31/

A lot of people will just ignore this monster thread; so if you plan to
actually have people read those, wouldn't it be better to make up a new
thread?  Or move it to another list?


Michael

PS: Is there an RSS feed of the news?

Re: blubber and grubber down

[Michael Banck]

On Tue, Nov 10, 2009 at 05:47:24PM +0100, Thomas Schwinge wrote:
> Hello!
> 
> On Sun, Nov 08, 2009 at 11:45:39AM +0100, I wrote:
> > I think I'll reinstall them later today (preserving /home/, of course).
> 
> Sergiu rightfully so reminded me that I had forgotten to do that.
> blubber is again up running, and grubber will be in some days --
> realistically.  ;-) (I did some changes to my install scripts, and want
> to test and use these improvements for re-installing grubber.)
>  now
> documents the installation process, so that someday another person can do
> this, too.
> 
> 
> > Should be pretty easy now that crosshurd is functional again.
> 
> Michael, FYI: This indeed the case.  The only strange thing I noticed is
> this:
> 
> I: Extracting /var/cache/apt/archives/coreutils_7.5-6_hurd-i386.deb...
> I: Extracting /var/cache/apt/archives/dash_0.5.5.1-3_hurd-i386.deb...
> tar: ./bin/sh: Cannot create symlink to `dash': File exists
> tar: ./usr/share/man/man1/sh.1.gz: Cannot create symlink to `dash.1.gz': 
> File exists
> tar: Exiting with failure status due to previous errors
> I: Extracting /var/cache/apt/archives/debianutils_3.2.1_hurd-i386.deb...
> I: Extracting 
> /var/cache/apt/archives/diffutils_1%3a2.8.1-18_hurd-i386.deb...
> 
> But this didn't have any negative effects (dash finally is running as
> /bin/sh), so I ignored it.

Yeah, it's because both the bash and dash .debs ship the /bin/sh symlink
now; not much we can do about it right now, as both packages are
uptodate with respect to unstable.


Michael

Re: Mercurial vs. git

[Michael Banck]

Hi,

On Wed, Nov 11, 2009 at 03:38:57PM +0100, Arne Babenhauserheide wrote:
> Well, there's Photoshop - and it doesn't yet have a real competitor in free 
> software. Though Gimp is almost as powerful, it is much harder to use for 
> newcomers. Give Photoshop to a newbie, and you'll see him/her working at 
> once. 
> Try that with Gimp, and after a few minutes you'll have a confused user. 

I am getting increasingly annoyed by this - can you explain how this
relates to Hurd development?


Michael

Re: GNU/Hurd in german news

[Michael Banck]

On Thu, Nov 12, 2009 at 12:57:22PM +0100, Arne Babenhauserheide wrote:
> @Samuel: Do you have contact with the fvwm people? If yes: Could you send 
> them 
> a link with the status page? 

I don't think fvwm working is news.


Michael

Re: GNU/Hurd in german news

[Michael Banck]

On Thu, Nov 12, 2009 at 01:20:37PM +0100, Arne Babenhauserheide wrote:
> Am Donnerstag, 12. November 2009 13:02:39 schrieb Michael Banck:
> > On Thu, Nov 12, 2009 at 12:57:22PM +0100, Arne Babenhauserheide wrote:
> > > @Samuel: Do you have contact with the fvwm people? If yes: Could you send
> > > them a link with the status page?
> > 
> > I don't think fvwm working is news.
> 
> Nor interesting to the fvwm people that it runs on GNU/Hurd? 

Why would it be?  AFAIK fvwm has no platform-specific code, so there is
no reason why it should not work.

If it had to be ported, it got ported 10 years ago, so notifying them
now looks totally pointless to me.


Michael

Re: learning curve

[Michael Banck]

This is ridiculous. I am going to unsubscribe from bug-hurd the next
time I see such an off-topic thread again.


Michael

On Thu, Nov 19, 2009 at 08:24:21AM +0100, Arne Babenhauserheide wrote:
> Am Dienstag, 17. November 2009 22:38:39 schrieb olafbuddenha...@gmx.net:
> > The problem with learning bit by bit is that you only look up things if
> > you want to do something new. You never get a complete picture; you
> > never learn how you could do things more efficiently, and/or with better
> > result; and you often pick up really bad practices.
> 
> I tend to disagree here, too. 
> 
> You do pick up back practise if you only check what is absolutely necessary 
> to 
> get the task at hand done (as I often do for shell scripting). 
> 
> If you check deeper issues when you need them, you understand something new 
> and you learn to work more efficiently. 
> 
> Look for example at the Mercurial guide I wrote. At first you only learn to 
> commit and read your log. At that point you already understand that Mercurial 
> tracks your changes - and after using it a bit, you also get a feeling for 
> what commit does. 
> 
> Then you learn how to do nonlinear development, branching and merging at 
> will. 
> Committing is already natural at that point, so you only enhance what you 
> already know by heart. 
> 
> And after that you learn that working together with others is simply 
> nonlinear 
> development by exchanging "commits" between repositories. 
> 
> 
> In really complex areas that becomes even more evident. 
> 
> One example: I'm studying physics, and I learned this summer with the Feynman 
> lectures, which hammer home the point that statistics tell us that the 
> distribution of particles with certain energies is exp(-E/kT) - that's "e" to 
> the potential of minus the energy divided by the temperature (and the 
> Boltzmann constant). He explains that for gases at first (energy distribution 
> in different heights - only from gravity and random movement energy). The 
> distribution says "this many particles with Energy E are there". 
> 
> At that point he never talks about the difference between bose particles and 
> fermi particles. He also doesn't try to give the whole mechanism, but rather 
> gives a central part of the whole picture. 
> 
> Now when I got to learning suprafluids and stuff, it was quite easy to 
> understand what their slightly different distribution does: 
> 
> 1 / (exp(E/kT) - 1)
> 
> That's almost exp( - E/kT), but for low energies it goes to infinity - 
> because 
> the lowest state of a suprafluid can be shared by an arbitrary high number of 
> particles - if you only manage to take away enough energy from them. That's 
> why it can crawl over walls, ignores rotations of the container and such. 
> 
> To really see the implications of that, you already need to know about , 
> Heisenbergs uncertainty relation for the gaussian distribution of energies, 
> quantum mechanics, energy barriers and stuff. But you don't need to 
> understand 
> that to grasp the basic law exp(-E/kt). 
> 
> And really understanding the basic law makes it much easier to understand 
> more 
> complex stuff later on - understanding everything at once is just not 
> feasible 
> for the vast majority of physics students. 
> When you already know exp(-E/kT), many later things are "wow, it's really 
> easy 
> to see how that works - just a small alteration to the basic distribution". 
> 
> (there are more basic principles in physics than this, but that's one which 
> currently fascinates me; it is so easy - once you udnerstand it :) 
> And Feynman really manages to make physics sound as fascinating as it is, 
> while keeping it easy to understand). 
> 
> To organize learning that way makes for a very efficient learning curve. 
> 
> (actually he starts with "all matter is made of atoms (as long as we don't 
> look to deep)" and "we begin with small lies which make it easier to 
> understand the basics - but we tell you which laws are final (to our current 
> knowledge) and which are simplifications we'll have to revise" and goes 
> onward 
> from that). 
> 
> > In either case, you can't seriously argue that it's demanding too much,
> > that everyone learning how to set the text color, should also learn how
> > to set the background color at the same time, and vice versa...
> 
> And the button color, and the text field color (almost no site changes that), 
> ... 
> 
> What's missing there is a way to adapt to user settings. What you describe is 
> binary again: Either set all or nothing. But that means that it doesn't 
> integrate at all or integrates completely - without middle ground. 
> 
> But we already had that part of the discussion... 
> 
> Best wishes, 
> Arne
> 
> PS: I think that this can be relevant to the Hurd, because the learning curve 
> is something which also affects every program, translator usage, etc. - and 
> so 
> it affects how easy it is for people to switch to the Hurd. 

Re: learning curve

[Michael Banck]

On Thu, Nov 19, 2009 at 06:16:07PM +0100, Arne Babenhauserheide wrote:
> I spent some time thinking whether to send this reply to the list or only to 
> Olaf, but I decided to send it to the list, because the learning curve also 
> applies to documentation of the Hurd - the Hurd also offers concepts which 
> are 
> new to many people. 

I said it before, and I'll say it again now: the Hurd does not need
more users, it does not even need a lot more developers, it just need a
few *really smart* developers.

You don't get really smart developers by trashing up your development
list with 200-mail threads about mercurial vs. git vs. cvs or the merits
of light or dark backgrounds in CSS.


I rest my case now.

Michael

Re: Months of the Hurd 2009-12

[Michael Banck]

On Mon, Dec 28, 2009 at 10:25:44AM +0100, Arne Babenhauserheide wrote:
> I prepared the news about this months. If something is missing (or wrong), 
> please tell me! 

There was lots of porting activity as well, mostly by Pino Toscano and
Emilio Pozuelo Monfort.  Maybe asking them for some highlights of newly
fixed or ported packages would be worthwhile.


Michael

Re: cannot boot subhurd

[Michael Banck]

On Sat, Jan 02, 2010 at 10:46:20PM +0800, Da Zheng wrote:
> I tried crosshurd. It doesn't work. Anyone maintains crosshurd?

Yes.

Michael

Re: FOSDEM 2010

[Michael Banck]

On Thu, Dec 31, 2009 at 04:37:12AM +0100, olafbuddenha...@gmx.net wrote:
> Hi,
> 
> On Tue, Dec 22, 2009 at 10:01:41AM +0100, Thomas Schwinge wrote:
> 
> > FOSDEM 2010 is slowly approaching.
> > 
> > A few Hurd types have shown interest in meeting there, so I created
> > 
> > for coordination.  Beware that web-editing (and the whole of bddebian
> > HTTP) is still down due to this Perl crash I (or someone else, of
> > course) needs to have a look at.  But you can either use the Git
> > interface, cf.
> > , for
> > doing any changes, or tell me by email or on IRC (tschwinge on
> > freenode.net).
> 
> As the wiki is kinda-working again now, I think it's right to use
> http://www.bddebian.com/~hurd-web/community/meetings/fosdem_2010/ ?
> 
> Also, I think it would be good to mention that there will be an alt-os
> devroom, where we will surely hang out -- and hopefully could give a
> talk or two as well...

The submission deadline for the alt-os devroom has been extended till
the end of January 4th:

http://groups.google.com/group/rosetta-os/browse_thread/thread/16964e21bef27116

Francois Revol (the chairmain of the devroom) turned up in #hurd today
and requested submissions:

 I'd really like to see a Hurd demo :)

His email address is re...@free.fr.


Michael

Re: Generalizing mobility for the Hurd

[Michael Banck]

On Fri, Jan 29, 2010 at 02:53:04PM +0100, Carl Fredrik Hammar wrote:
> For now it is available from my personal web page provided by my uni:
>   
> but I don't know how long that will last since I'm no longer enrolled.
> I guess I'll have to get a web page of my own eventually.

That file is not very big, I think it could be mirrord (at least) at
hurd.gnu.org as well, under the software/hurd/hurd/documentation
section.


Michael

PS: btw, software/hurd/documentation does not look very welcoming, and
it is a 1st class link from the homepage.

Re: news 2010-03: *bug squashing* and *Hurd in GSoC 2010 with GNU*

[Michael Banck]

On Sat, Mar 27, 2010 at 04:16:11PM +0100, Arne Babenhauserheide wrote:
> Am Samstag, 27. März 2010 16:00:37 schrieb olafbuddenha...@gmx.net:
> > Hi,
> > 
> > On Sat, Mar 27, 2010 at 03:03:36PM +0100, Arne Babenhauserheide wrote:
> > > > This month saw bugs dieing as they met hackers like
> > > > [Jérémie, Antrik, Samuel](http://lists.gnu.org/archive/html/bug-
> 
> > I don't take any credit for that...
> > 
> > Also, I never capitalize my nick :-)
> 
> OK, cleaned up - your nick in the second paragraph. Thanks! 

Maybe I mentioned this before (and I won't mention it again), but if the
news are directed to people not already in the community (which I
assume, otherwise people should know about most of it anyway), then I
would suggest not using first names only or nicknames, but spelling out
full names.


Michael

Re: Article - GNU HURD: Altered visions and lost promise

[Michael Banck]

Hi,

On Wed, Jun 30, 2010 at 05:44:37PM +0200, Jure Repinc wrote:
> I've just seen a new article about GNU Hurd:
> http://www.h-online.com/open/features/GNU-HURD-Altered-visions-and-lost-
> promise-1030942.html

http://news.ycombinator.com/item?id=1474941 is an interesting (from a
historical/FSF POV) comment on that article.


Michael

Re: Debian GNU/Hurd installation wizard and live cd

[Michael Banck]

Hi,

On Thu, Jul 22, 2010 at 08:43:13AM +0200, Arne Babenhauserheide wrote:
> Hi Justus, 
> 
> On Monday 12 July 2010 15:40:07 Arne Babenhauserheide wrote:
> > Do you have an idea why it breaks here?
> 
> Are you still there? 

Maybe try assigning more RAM to KVM if you assigned much less than
512MB.  Just a wild guess.


Michael

Re: [PATCH 0/8] Bring console-driver-xkb up to date

[Michael Banck]

On Wed, Aug 18, 2010 at 03:03:19AM +0200, Samuel Thibault wrote:
> Hello,
> 
> Diego Nieto Cid, le Wed 04 Aug 2010 04:19:58 -0300, a écrit :
> >The past couple of weeks I've been packaging Marco's input driver
> > for Arch Hurd and I've found that some changes were necesary to make
> > it work again.
> 
> Does anybody know whether / where we have an upstream repository where
> to commit such patches?

They should go into the Hurd codebase, methinks.

The original xkb driver was just a tared up dump of Marco's code tree on
his homepage I believe, so there is no real upstream location AFAIK.


Michael

Re: [tschwinge+n...@gnu.org: Duke Nukem Forever Returns, Will Really Be Released in 2011]

[Michael Banck]

Hi,

On Sat, Sep 04, 2010 at 04:33:22PM +0200, Thomas Schwinge wrote:
> So, there's no escape anymore: we'll have to release next year, 2011.
> Finally.  As far as I know, *everyone* is expecting Duke Nukem Forever
> and the GNU Hurd to appear at the same time, yet to be bundeled (see
> ).

Let's contact them for a coordinated release on 4/1/11.


Michael

Re: ED error code

[Michael Banck]

On Tue, Nov 02, 2010 at 11:30:28AM +0100, Manuel Menal wrote:
> On 02/11/2010 11:29, Samuel Thibault wrote:
> > Manuel Menal, le Tue 02 Nov 2010 11:20:27 +0100, a écrit :
> >>> “Macros that begin with E and a digit or E and an uppercase letter may
> >>> be added to the declarations in the  header.”
> 
> >> I'm not a native speaker, but I don't think that means E[A-Z0-9]+ are
> >> reserved for error code macros. Only that error code macros should match
> >> E[A-A0-9]+.
> 
> > I should have quoted the start of the 7.26§ itself:
> 
> > “7.26 Future library directions
> > The following names are grouped under individual headers for
> > convenience. All external names described below are reserved no matter
> > what headers are included by the program.”
> 
> OK, I had missed that part. I'll report bugs against those packages, then.

I think it still makes sense to remove that ED macro if it serves no
purpose


Michael

Re: XKB's keymaps for the Hurd console

[Michael Banck]

On Tue, Mar 22, 2011 at 05:06:40PM -0500, Oz wrote:
> awsome sounds like i'll be playing some quake 3 mods in the near
> future on the hurd.

I suggest you wait for Duke Nukem Forever.


Michael

Re: Porting uptimed: Usage of daemon and replacement of NOFILE

[Michael Banck]

Hi,

On Tue, Nov 01, 2011 at 11:49:48AM +0100, Svante Signell wrote:
> In package uptimed-0.3.16 the following function is defined:

BTW, I had a look at uptimed before, and the main problem I faced
(IIRC), was making it crash safe.  uptimed is writing the current uptime
into a file, and even on GNU/Linux with ext3 or so I had some issuse
with corrupted uptime files after reboot.

Parsing those files is the main point, so writing them safely is
important.  I don't remember whether the code for that is
platform-dependent though.


Michael

Re: A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*.

[Michael Banck]

Hi,

On Sun, May 05, 2013 at 12:33:27AM +0200, Arne Babenhauserheide wrote:
> A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*.
> 
> At the end of the last 2 quarters, Samuel Thibault pushed the [pthread
> patches](http://lists.gnu.org/archive/html/bug-hurd/2012-11/msg00088.html)
> from Vincente, Barry, Thomas, Richard and Samuel and others to the
> different upstream packages, 

As QotH is supposed to be read by a wider audience, I really think you 
should expand the last names of people at least for the first mention.


Michael

Re: Imminent Debian GNU/Hurd release

[Michael Banck]

Hi,

On Fri, May 10, 2013 at 09:30:12PM +0100, Miguel Figueiredo wrote:
> It is with huge pleasure that the Hurd project 

The Debian GNU/Hurd port and the GNU Hurd project are not exactly the
same, even though the member overlap is significant.

Just pointing this out here as I am not sure the (GNU) Hurd project has
acked this and I assume this is a Debian GNU/Hurd effort? (Either would
be fine with me).


Michael

Re: A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*.

[Michael Banck]

Hi,

On Fri, May 10, 2013 at 09:58:28PM +0200, Arne Babenhauserheide wrote:
> At the end of the last 2 quarters, Samuel Thibault pushed the [pthread
> patches](http://lists.gnu.org/archive/html/bug-hurd/2012-11/msg00088.html)
> from Vicente Hernando Ara, Barry de Frese, Thomas Schwinge, Richard

It's Barry de Freese, two e.


Michael

Re: GNU/Hurd DDE talk at FOSDEM

[Michael Banck]

On January 31, 2014 6:35:44 PM CET, Samuel Thibault  
wrote:
>Emilio Pozuelo Monfort, le Fri 31 Jan 2014 12:31:39 +0100, a écrit :
>> What's the status quo of driver support in the Hurd without DDE (very
>few linux
>> old 2.0 drivers...)
>
>You mean other than network boards?  That's a usual part of my talks,
>yes :)
>
>> I look forward to watching the recorded video :-)
>
>I'm afraid there is usually no video of the microkernel room.
>
>Someone would have to bring a microphone and record it.
>
>Samuel

Hi,

I just got told that all Devrooms are being video taped this year, and there 
might even be streaming available.


Michael

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: chroot in its own ext2fs?

[Michael Banck]

Hi,

On Fri, May 02, 2014 at 02:22:01AM +0200, Samuel Thibault wrote:
> Does anybody remember precisely why chroots should have their own
> ext2fs?  I can build packages fine from inside a chroot which doesn't
> have its own ext2fs, for instance.

I don't recall why we did that, maybe it was purely for operational
reasons (offline filesystem checking of just the chroot when still had
lots of corruption) and is no longer applicable today.


Michael

Re: Problem with reinstallation, bootloader

[Michael Banck]

On Tue, Nov 11, 2014 at 10:37:21AM +0100, Riccardo Mottola wrote:
> How can I get from HURD something similar to DMESG or lspci? Right
> now I don't have any other OSs, thus I can easily list all hardware
> Richard B. asked for! Otherwise I'll burn some kind of LiveCD.

IMO, it's generally a good idea to have a grml live-cd (or bootable
usb-stick) handy: http://grml.org/


Michael

Re: HURD and a Laptop

[Michael Banck]

On Thu, Jan 22, 2015 at 06:34:44PM +0100, Samuel Thibault wrote:
> There are wireless tools on debian-ports.  I don't know the details.

I guess they are about 10 years old by now.

Even back then, they did not work very well, as I recall.


Michael

Re: fosdem talk?

[Michael Banck]

On Fri, Jan 29, 2016 at 01:57:10AM +0100, Samuel Thibault wrote:
> Hello,
> 
> That's when I miss the nice quarterly reports we used to have: what's
> new since last FOSDEM?
> 
> For now I have only noted:
> 
> Fixed native fakeroot
> Various optimizations
> - Node cache
> - Lockless reference counting
> - IPC table→radix tree
> - Kernel memory management
> New rpcscan tool

On a more top-level view, we had the following releases:

GNU Hurd 0.6, GNU Hurd 0.7, GNU Mach 1.5, GNU Mach 1.6, GNU MIG 1.5, GNU
MIG 1.6 (not sure it makes sense to highlight the 0.6/1.5 changes, as I
guess those were talked about last year?)

Debian GNU/Hurd 2015

Also, there was the Guix on Hurd GSoC project

I guess there are no real ideas for the next GSoC, but if there are, it
might interest/motivate some in the audience to hear about it.


Michael

Re: real hardware and ethernet cards

[Michael Banck]

Hi,

On Thu, Feb 20, 2020 at 11:34:48PM +0100, Samuel Thibault wrote:
> Riccardo Mottola, le jeu. 20 févr. 2020 23:32:05 +0100, a ecrit:
> > One question: is the issue because the cards are behind PCMCIA/CardBus
> > and we don't support that?
> 
> We have some support for this in the cardmgr-gnumach package. I don't
> know how that works, though.

I'm not sure anybody looked at that in the last 15 years; IIRC it was
put together with a hot needle back then and I'd be very surprised if it
still worked at least somewhat today.


Michael

Re: non-blocking connect fails with no pending acceptors

[Michael Banck]

On Tue, May 17, 2005 at 10:31:09AM +0100, Neal H. Walfield wrote:
> 2005-05-17  Neal H. Walfield  <[EMAIL PROTECTED]>

I am happy to say that this patch fixes the hang when GNOME is compiled
against the gamin file alteration monitor.  GNOME starts up fine now
(though the updating doesn't seem to work well anyway, but gamin is
known to have issues), while it freezes the system on GNOME startup
without.


Michael

-- 
"To be honest, the only game you really need is Tetris, but you know,
there are a couple of freaks out there."
-- Miguel de Icaza


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

Re: ext2fs (was: floppy and mouse)

[Michael Banck]

On Fri, Jul 22, 2005 at 02:02:58PM +0200, Thomas Schwinge wrote:
> On Fri, Jul 22, 2005 at 02:04:32PM +0400, [EMAIL PROTECTED] wrote:
> > [ ext2fs ]
> > block size is not equal memory page size as I understand.
> 
> Yes, that's a limitation of the ext2fs translator that is currently
> included in the Debian GNU/Hurd distribution: it can only cope with
> block sizes of 4096 bytes.

The solution here is to create ext2 file systems with this block size,
i.e. passing -b 4096 to mke2fs.


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Re: [PATCH] building/installing iso9660fs.static by default

[Michael Banck]

On Fri, Jul 22, 2005 at 09:08:37PM -0400, Ben Asselstine wrote:
> Does it make sense to build iso9660fs statically and install that in
> /hurd?  Why not eh?  Patch follows.

The Debian package does this by passing
--enable-static-progs='ext2fs,ufs,iso9660fs' to ../configure, btw, but I
think it makes sense to do include iso9660fs by default.


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Re: floppy and mouse

[Michael Banck]

On Mon, Jul 25, 2005 at 02:11:29PM +0400, [EMAIL PROTECTED] wrote:
> I have done it but my computer showed black screen and no reaction to
> keyboard. I connected a mouse to Com1 port. It works under other
> operation systems on my computer. Then under HURD when I type this
> command(console -d vga -d pc_kbd -d pc_mouse /dev/vcs) without
> -d pc_mouse it was appeared a new console with an ability to swich to
> other consoles by typing a combination of keys Alt-Shift F2, or F3 etc.

This is a known bug in either the console or the pc_mouse driver.

> Before that this feature was unabled. In Cook-book file there is a text
> which tell that I must make devices /dev/mouse and /dev/kbd. As far as I
> understood in full debian distributive these files are present. 

To get /dev/mouse and /dev/kbd, you need to run the repeaters, like
--repeat=kbd and --repeat=mouse, this is undocumented in the manual so
far I think.  The device nodes will appear in /dev/cons/, you can
symlink them to /dev/mouse and /dev/kbd.

See http://hurd.gnufans.org/bin/view/Hurd/Xfree86 for further
information on how to setup the Hurd console to work with X11.


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Re: [PATCH] Trivial fix on an argument in ftpfs

[Michael Banck]

On Fri, Jul 29, 2005 at 05:39:30PM +, Anders Juel Jensen wrote:
>  Just a small fix in ftpfs, it was probably just a typo in the first
> place.

Thanks, I put this into the Debian package.
 
>/* Remove this entry from the set of known inodes.  */
>spin_lock (&nn->fs->inode_mappings_lock);
> -  hurd_ihash_locp_remove (&nn->fs->inode_mappings, nn->dir_entry-
> >inode_locp);
> +  hurd_ihash_locp_remove (&nn->fs->inode_mappings, &nn->dir_entry-
> >inode_locp); spin_unlock (&nn->fs->inode_mappings_lock);

Your mail client seems to have line wrapped those lines, try to avoid
this next time in order to make applying your patches easier.


cheers,

Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Re: Wrappers for the Hurd.

[Michael Banck]

On Sat, Aug 06, 2005 at 11:10:25AM +0200, Alfred M. Szmidt wrote:
> How do people feel about adding wrappers for different languages
> (scheme, ruby, python, ...) to the Hurd repository (they can live in a
> different module)?

How about adding them to the hurdextras repository on savannah?  That
way, they could be maintained by their respective authors without
need to have CVS commit rights to the main Hurd CVS repository.

Copyright assignments would still be worthwhile to have.


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Re: network adapter

[Michael Banck]

On Sun, Aug 21, 2005 at 04:08:56PM +0400, [EMAIL PROTECTED] wrote:
> I have standart network adapter Realtec. I installed it on Debian
> GNU/Linux. But for HURD it does not work.
> settrans -fgap /servers/socket/2 /hurd/pfinet -i eth0 -a 192.168.83.39
> -g 192.168.83.38 -m 255.255.252.0 The computer print something similar
> "Translator died wrong address read help for pfinet" I don't
> understand. How it is realized? 

Run 'devprobe eth0', if it returns no output, your network adapter is
not supported by GNU Mach.  GNU Mach's driver support is less good than
Linux's.

What kind of network adapter do you have?


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Unattended issues

[Michael Banck]

On Wed, Aug 24, 2005 at 09:16:05AM +0300, Ognyan Kulev wrote:
> Yes... Most communication about the Hurd nowadays is through ##hurd or 
> #hug @ irc.freenode.net.

This is bug, not a feature, of course.  

IRC should be used for end-user support, specific hacking or bug
tracking and socialising, IMHO.  Development itself should (at least as
well) mostly be done through the mailing lists and/or Savannah, so all
members of the community can participate and accountability is
guaranteed.


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Re: Unattended issues

[Michael Banck]

On Sat, Aug 27, 2005 at 02:09:52PM -0700, Thomas Bushnell BSG wrote:
> Sergio Lopez <[EMAIL PROTECTED]> writes:
> 
> > The problem isn't the patches itself. Don't belive to Alfred, I'm not
> > claiming to put any patch into the CVS. I'm just asking some design
> > issues, to know what's the proper direction to take so this work can
> > someday become part of the Hurd.
> 
> Welp, ask away.

I think the bottom line is:

Are the Hurd developers interested in any new Mach design
changes/feature additions?  Neal and Marcus don't seem to (concentrating
on Hurd/L4 instead), so this leaves Thomas and Roland apparently.

Sergio proposed/asked some of those:

"Multipage requests for GNU Mach 1,3"
http://lists.gnu.org/archive/html/bug-hurd/2004-12/msg00242.html

"New behaviour for reading from a memory object."
http://lists.gnu.org/archive/html/bug-hurd/2005-07/msg00278.html

and did not get feedback from either of you.

This is not a bad thing per se if you guys don't feel like working on
Mach anymore, but it would probably be good to communicate this clearly
to people either way, as some still seem to be interested in hacking on
it.

What should happen to patches pertaining to other parts than Mach itself
(the Hurd, glibc) due to these design changes is another matter.


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Updating libgc port

[Michael Banck]

Hi,

Boehm's garbage collector (libgc) has been ported to GNU/Hurd a while
ago.  However, the port suffered some bitrot and now builds no more:

checking for thread model used by GCC... posix
configure: error: "Pthreads not supported by the GC on this platform."

The following patch updates the threading stuff by following what gets
defined for Linux and doing some wild guesses, could somebody with more
experience in this field than me look over it before I submit it
upstream?

diff -Naur libgc-6.5/configure.in libgc-6.5.new/configure.in
--- libgc-6.5/configure.in  2005-02-09 20:35:23.0 +0100
+++ libgc-6.5.new/configure.in  2005-10-18 21:04:29.238312160 +0200
@@ -90,6 +90,10 @@
AC_DEFINE(GC_LINUX_THREADS)
AC_DEFINE(_REENTRANT)
;;
+ *-*-gnu*)
+   AC_DEFINE(GC_GNU_THREADS)
+   AC_DEFINE(_REENTRANT)
+   ;;
  *-*-aix*)
AC_DEFINE(GC_AIX_THREADS)
AC_DEFINE(_REENTRANT)
diff -Naur libgc-6.5/include/gc_config_macros.h 
libgc-6.5.new/include/gc_config_macros.h
--- libgc-6.5/include/gc_config_macros.h2005-04-22 02:57:34.0 
+0200
+++ libgc-6.5.new/include/gc_config_macros.h2005-10-18 18:42:58.0 
+0200
@@ -42,7 +42,8 @@
 || defined(GC_SOLARIS_PTHREADS) \
 || defined(GC_HPUX_THREADS) \
 || defined(GC_AIX_THREADS) \
-|| defined(GC_LINUX_THREADS))
+|| defined(GC_LINUX_THREADS)) \
+|| defined(GC_GNU_THREADS)
 # define _REENTRANT
/* Better late than never.  This fails if system headers that   */
/* depend on this were previously included. */
@@ -56,7 +57,7 @@
defined(GC_IRIX_THREADS) || defined(GC_LINUX_THREADS) || \
defined(GC_HPUX_THREADS) || defined(GC_OSF1_THREADS) || \
defined(GC_DGUX386_THREADS) || defined(GC_DARWIN_THREADS) || \
-   defined(GC_AIX_THREADS) || \
+   defined(GC_AIX_THREADS) || defined (GC_GNU_THREADS) || \
 (defined(GC_WIN32_THREADS) && defined(__CYGWIN32__))
 #   define GC_PTHREADS
 # endif
diff -Naur libgc-6.5/pthread_support.c libgc-6.5.new/pthread_support.c
--- libgc-6.5/pthread_support.c 2005-05-21 02:02:07.0 +0200
+++ libgc-6.5.new/pthread_support.c 2005-10-18 18:33:32.0 +0200
@@ -877,7 +877,8 @@
  GC_nprocs = sysconf(_SC_NPROCESSORS_ONLN);
  if (GC_nprocs <= 0) GC_nprocs = 1;
 #  endif
-#   if defined(GC_FREEBSD_THREADS) || defined(GC_IRIX_THREADS)
+#   if defined(GC_FREEBSD_THREADS) || defined(GC_IRIX_THREADS) \
+   || defined(GC_GNU_THREADS)
  /* FIXME: For Irix, that's a ridiculous assumption.   */
   GC_nprocs = 1;
 #   endif
diff -Naur libgc-6.5/threadlibs.c libgc-6.5.new/threadlibs.c
--- libgc-6.5/threadlibs.c  2004-12-17 02:47:42.0 +0100
+++ libgc-6.5.new/threadlibs.c  2005-10-18 18:22:25.0 +0200
@@ -12,7 +12,8 @@
 #   endif
 #   if defined(GC_LINUX_THREADS) || defined(GC_IRIX_THREADS) \
|| defined(GC_SOLARIS_PTHREADS) \
-   || defined(GC_DARWIN_THREADS) || defined(GC_AIX_THREADS)
+   || defined(GC_DARWIN_THREADS) || defined(GC_AIX_THREADS) \
+   || defined(GC_GNU_THREADS)
 printf("-lpthread\n");
 #   endif
 #   if defined(GC_FREEBSD_THREADS)


thanks,

Michael

-- 
 bash: ls: Computer bought the farm
 THAT frightens ppl! :P
 id rather see: "bash: ls: Initialization of googol(AWAX)
disengaged in HYPER32/64 mode due to faulty page request at
AX:12A34F84B"
 at least that would give me the feeling that the
*programmers* knows what is going on :P


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

Re: spam filtering on the hurdextras lists

[Michael Banck]

On Wed, Jan 11, 2006 at 01:01:27AM +0100, Alfred M. Szmidt wrote:
> If you wish to discuss private things, do it in private.

http://web.walfield.org/~deride/%23%23hurd-20060109 says:
<[EMAIL PROTECTED]:43> tschwinge is a complete and utter dickhead.

Insulting people on a public IRC channel hardly can be considered
private.


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Re: Xorg 7.0

[Michael Banck]

On Mon, Jan 16, 2006 at 01:29:08AM +0100, Samuel Thibault wrote:
> Works fine, provided they put back support:
> https://bugs.freedesktop.org/show_bug.cgi?id=5613

Wonderful, thanks a lot for investigating this.


Michael

-- 
 Casper_: what are you doing mostly with your Hurd box?
 azeem: it runs a web server, has frequent ssh and ftp connections
to it, new one about every second, and also runs a a toy box for warwick hug
to ssh into and play. also it runs X with crossfire client... a few xterms


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

Re: Wireless support

[Michael Banck]

On Mon, Jan 16, 2006 at 11:52:43AM -0200, Matheus Morais wrote:
> There exist support to run wireless cards in Hurd? If no, its possible (with
> the currently workable system) design that kind of device driver to Hurd?
> Its already exists a lot of workable drivers in GNU/Linux and FreeBSD, its
> possible port them to work on Hurd?

Device drivers are handled by the underlying microkernel, i.e. GNU Mach.
The currently widely-in-use GNU Mach-1.x has no support for wireless
network drivers nor PCMCIA.  I guess it might be possible in theory to
add this support, but without quite some knowledge in both GNU Mach and
Linux (as Mach uses Linux drivers via some glue code), one will not be
able to get this going.

It seems right now nobody has both the motivation and the skills to get
this running, sorry.


Michael


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

[patch #332] POSIX record file locking

[Michael Banck]

Additional Item Attachment, patch #332 (project hurd):

File name: posix_file_locking.patch   Size:71 KB
ChangeLog entries seperated, rediffed and Copyright year changes taken out


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

[patch #1839] Many small fixes in dir-rename.c and dir-renamed.c

[Michael Banck]

Follow-up Comment #1, patch #1839 (project hurd):

This patch needs breakup into individual parts, and explanations for them
(and test cases for errors it fixes, if possible).

Discussion is here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190732;msg=147

Alfred M. Szmidt:
What bug did this patch fix exactly?  Do you have any test cases for this?

Ognyan Kulev:
Many small bugs are fixed.  Most of the sentences in the changelog entry are
separate fixes that are not related to the other changelog entries. If it's
needed, I can make more detailed explanation about each sentence.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

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

[Michael Banck]

On Sun, Jan 29, 2006 at 12:42:22PM +0100, Alfred M. Szmidt wrote:
> 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?

I hope Roland will submit this upstream once this has been tested a bit
more.  I will roll Debian/Ubuntu kernels next week and announce them
here.

For what's it worth, this is the code change compared to Roland's last
version:

diff -u linux-2.6/fs/ext2/xattr.c linux-2.6/fs/ext2/xattr.c
--- linux-2.6/fs/ext2/xattr.c
+++ linux-2.6/fs/ext2/xattr.c
@@ -337,9 +337,9 @@
} else {
memcpy(buffer, name, size);
buffer += size;
-   rest -= size;
}
}
+   rest -= size;
}
if (ei->i_hurd_translator != 0) {
name = "gnu.translator";
@@ -350,9 +350,9 @@
} else {
memcpy(buffer, name, size);
buffer += size;
-   rest -= size;
}
}
+   rest -= size;
}
if (error >= 0)
error = buffer_size - rest;  /* total size */


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

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

[Michael Banck]

On Sun, Jan 29, 2006 at 06:46:35PM +0100, Alfred M. Szmidt wrote:
>Yes, as long as we don't let the build system create Makefiles in
>subdirectories, which we don't at the moment.  Changed.
> 
> Would be better to simply stop using manually maintained .in's, and
> use automake, then one won't have to care about such changes.  Jeff
> Bailey had such a patch.

Only for the Hurd though, to the best of my knowledge.


Michael

-- 
 the whole gnumach is probably a big easter egg.
 we just have too bad sense of humor to get it.


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

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

[Michael Banck]

On Sun, Jan 29, 2006 at 12:29:02AM -0200, [EMAIL PROTECTED] wrote:
> A fixed patch for supporting passive translators in Linux follows.

I have now built Ubuntu breezy and Debian unstable kernel package (686
flavour only) with that patch.

I only tested the Ubuntu breezy one, but getfattr/setfattr and star
tar creation/extraction worked fine again.

the Ubuntu packages are at

deb http://people.debian.org/~mbanck/ubuntu-breezy/ ./

The unstable package is at

deb http://people.debian.org/~mbanck/xattr-hurd/ ./


enjoy,

Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Re: No to StowFS!

[Michael Banck]

On Fri, Feb 03, 2006 at 01:58:54AM +0100, Alfred M. Szmidt wrote:
>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.

Or you could frob bash's she-bang parsing.


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Re: No to StowFS!

[Michael Banck]

On Fri, Feb 03, 2006 at 02:29:41AM +0100, Alfred M. Szmidt wrote:
> Thing is that they are broken, figuring out where the interpeter is
> should always be done at compile/configure time.  Having perl in
> /usr/local/bin is very common for example, and simply hardcoding it to
> /usr/bin will make things break.

A big point of hardcoding the path in system-critical scripts is that
admins installing random versions of perl and pythong in /local will not
be able to break them as they force the system installed version.


Michael


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

Re: pcmcia-support for gnumach-1

[Michael Banck]

On Wed, Feb 08, 2006 at 07:47:52AM -0500, Thomas Schwinge wrote:
> > For the moment only the pcnet_cs driver works well; getting other
> > ethernet cards (non-wireless) to work actually shouldn't be too hard.
> 
> I hope that everyone will bring their PCMCIA cards along when we meet at
> the upcoming FOSDEM in Bruxelles, so that we can test them.

People can try their luck already, just take the pcmcia-cs source
package, and copy over the driver you need from clients/ to
[gnumach]/linux/dev/drivers/pcmcia/clients, adding the appropriate info
to [gnumach]/linux/dev/drivers/pcmcia/{cards,drivers}.h and to the
Makefiles.

I probably forgot something, but that should get you started.


Michael

PS: I had success with another ne2000 card today, I don't have a media
coupler for it though, so I just got eth0 detected and couldn't test
actual networking.


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

Re: new version of glibc xattr patch

[Michael Banck]

Hi,

On Sun, Mar 06, 2005 at 03:58:38PM -0800, Roland McGrath wrote:
> Not tested in the slightest.

Ben Asselstine and I tested and debugged this now.  With a couple of
small changes, attr's getfattr/setfattr commands and star work fine for
gnu.translator and gnu.author.

> +error_t
> +_hurd_xattr_get (io_t port, const char *name, void *value, size_t *size)
[...]
> +  if (!strcmp (name, "translator"))
> +{
> +  char *buf = value;
> +  size_t bufsz = value ? *size : 0;
> +  error_t err = __file_get_translator (port, &buf, &bufsz);
> +  if (err)
> + return err;

> +  if (*size > bufsz)
> + *size = bufsz;

When getxattr gets called with VALUE as NULL and *SIZE as 0 (to
determine the length of the xattr value), SIZE will be smaller than
BUFSZ and subsequently the callee gets 0 returned and believes no xattrs
are present.

We propose this instead:

  if (value != NULL && bufsz > *size)
return ERANGE;
  *size = bufsz;

> Index: sysdeps/mach/hurd/fremovexattr.c
[...]
> +  return err ? __hurd_dfail (fd, err) : size;
[...]
> Index: sysdeps/mach/hurd/removexattr.c
[...]
> +  return err ? __hurd_fail (err) : size;

As was pointed out before, those should return 0 on success, and not
SIZE.

> Index: sysdeps/mach/hurd/setxattr.c
[...]
> +  return err ? __hurd_fail (err) : size;

This (and fsetxattr) should return 0 on success as well.

> +error_t
> +_hurd_xattr_list (io_t port, void *buffer, size_t *size)
[...]
> +  struct stat64 st;
> +  error_t err = __io_stat (port, &st);
[...]
> +  if (st.st_mode & S_IPTRANS)
> +add ("gnu.translator");

Our tests seemed to have shown that most (all?) passive translators do
not have the S_IPTRANS stat bit set, thus not reporting the
gnu.translator xattr through listxattr.  Are we missing something here?

Note that nodes which have their passive translator set by setfattr
report S_IPTRANS back fine.


cheers,

Michael and Ben

-- 
"Thank God nobody's looking at this comment, or my reputation would be
ruined."
-- Gordon Matzigkeit


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

Re: new version of glibc xattr patch

[Michael Banck]

On Mon, Feb 20, 2006 at 02:15:48PM -0800, Roland McGrath wrote:
> >   if (value != NULL && bufsz > *size)
> > return ERANGE;
> >   *size = bufsz;
> 
> That fix leaks in the ERANGE case.  I did a different fix.
> Please verify it.

It works just as fine.
 
> > Our tests seemed to have shown that most (all?) passive translators do
> > not have the S_IPTRANS stat bit set, thus not reporting the
> > gnu.translator xattr through listxattr.  Are we missing something here?
> 
> I doubt this is true.  If it is, it's a server-side bug.  Note that
> S_IPTRANS and the gnu.translator xattr are found on nodes opened with
> O_NOTRANS.  They will more or less never be seen by the file name-based
> calls, only by f*xattr on an fd opened using O_NOTRANS.  

I see.  This means existing code will need to get changed or rewritten I
guess.  Star and {get,set}fattr always use the file name-based calls,
which is why they do not report passive translators.  We could write a
{set,show}trans replacement for GNU/Linux perhaps, and add an option to
GNU tar to not follow translators (along with the other xattr support).
Star would be a bit more difficult to change, I couldn't get it to use
O_NOTRANS and f*xattr when I quickly tried, the build system breaks down
when _GNU_SOURCE is defined.


Michael


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

automake patches for the Hurd

[Michael Banck]

Hi,

some years ago, Jeff Bailey worked on moving the Hurd build system to
automake.  Some people lately got interested in this again, so I got the
patches from him and am posting them here for people to work on with
Jeff's consent.  They still applied fine (or I resolved some conflicts,
don't remember) but I did not try a full build yet.  


happy hacking,

Michael


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-hurd

Re: Google's Summer of Code 2006

[Michael Banck]

On Thu, Apr 20, 2006 at 10:25:38PM -0400, Barry deFreese wrote:
> >Actually a samba translator is present in the hurd-extras project. 
> >Probably
> >it is a bit broken at the moment as I haven't used/tested it from about 2
> >years.
 
> Yes it's broken.  It depends on Samba and Samba won't build for us at the 
> moment.  Full of PATH_MAX stuff IIRC.

IIRC, there is a patch for samba in the sambafs CVS repo, somebody
should see whether it still applies and is good, maybe some regressions
have happened since.


Michael


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

Re: Google's Summer of Code 2006

[Michael Banck]

On Thu, Apr 20, 2006 at 01:26:48PM -0400, Thomas Schwinge wrote:
> Possible projects I thought about submitting include `libchannel',
> `pfinet rewrite', `nfs / nfsd rewrite / enhancement', `GNU Mach on Xen'.

Other projects I could think about:

* test-suite framework
* update GNU Mach's device glue to linux-2.6
* ext3fs
* overhaul (parts) of the Hurd-specific code in glibc
* a basic firewall
* lvmfs
* KGI/GGI
* GNOME integration


Michael


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

Re: Google's Summer of Code 2006

[Michael Banck]

Hi,

On Mon, Apr 24, 2006 at 01:36:52PM -0300, Matheus Morais wrote:
> On 4/24/06, Barry deFreese <[EMAIL PROTECTED]> wrote:
> > Matheus,
> >
> > If I recall correctly, Colin Watson had gotten pretty far on porting
> > D-I to Hurd but was still having an issue with booting I think.
> 
> Right, azeem already tryed to make contact with Colin in respect to
> mentoring this task, but his awnser was negative because he will be
> very busy in this summer.

Well, he said he would be available for questions and would provide his
current working tree.  As one of the main debian-installer guys, he
could also be very valuable in actually getting the code in.

He seems to be too busy to do the adminstrative legwork though.

If we could find some other (Debian) developer, who is somewhat familiar
with d-i and a good coder, as well as happy to be a mentor, this could
still work out I think.


Michael


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

_POSIX_THREADS in

[Michael Banck]

Hi Roland,

I included your recent patch overhauling bits/posix_opt.h to Debian's
glibc package as _POSIX_THREAD_SAFE_FUNCTIONS is needed to be defiend in
order to build libX11 properly.

While reading the patch I noticed that you #defined _POSIX_THREADS to -1
in it.  I thought we have a posix thread implementation provided by
libpthread, so I am a bit confused.  Is this about something else?


thanks,

Michael

-- 
"I'm great at starting projects...but finishing?  That's harder."
-- Thomas Bushnell, BSG


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

Re: on Google's Summer of Code 2006

[Michael Banck]

On Sat, Apr 29, 2006 at 03:45:23PM +0300, Constantine Kousoulos wrote:
> In order to be more clear, what i meant was that i would like to get 
> involved with one of the ideas presented in 
> http://www.gnu.org/software/soc-projects/ideas.html regarding the GNU Hurd. 
> Would a "mentor" be willing to cooperate with a newbie or experience on the 
> project is required?

As I understand it, you would write up an initial spec or proposal on
your own which the mentor would then comment on.  During the
implementation, the mentor would be available for specific questions and
will finally evaluate your work.

So I think this year's Summer of Code is probably not the best way to
introduce complete newcomers to the Hurd, as the time of the mentors is
probably quite limited.  On the other hand, you still got a few weeks to
become a Hurd insider before Summer of Code starts :)


Michael


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

Re: Google's Summer of Code 2006

[Michael Banck]

On Wed, Apr 26, 2006 at 03:15:03PM +0300, Ognyan Kulev wrote:
> Michael Banck wrote:
> >If we could find some other (Debian) developer, who is somewhat familiar
> >with d-i and a good coder, as well as happy to be a mentor, this could
> >still work out I think.
> 
> I may participate in mentorign that but personally it's definately lower 
> priority than Xen port ;-) I translate debian-installer to Bulgarian and 
> I follow debian-boot@ since year and half.

If you are still interested in mentoring this, can you sign up as mentor
for Debian if you haven't already? 

It would be great if this task (porting d-i to GNU/Hurd) could be
tackled!


Michael

-- 
"Fox News gives you both sides of every story, the President's side and
the Vice President's side."
-- Stephen Colbert


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

Re: upgrade hurd package

[Michael Banck]

On Thu, Jul 13, 2006 at 11:19:51PM +0530, Ritesh Raj Sarraf wrote:
> Is there anything I can do ?

Well, debug why -7 stalls on most apt-get operations.  Any information
there is probably valueable.  Also, building the -7 source package with
different versions of the toolchain (glibc, gcc, binutils, gnumach) and
finding one that works would be valuable.  I tried the latter a while
ago, but failed.


Michael


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

Re: Announcing the slow burial of the Hurd Wiki

[Michael Banck]

On Thu, Aug 10, 2006 at 11:02:53PM +0200, Ernst Rohlicek jun. wrote:
> From my perspective, I wanted to register for an account over a week 
> ago and didn't get an activation reply so far ... besides, some info 
> is outdated (2G limit?!) and the TWiki is from 2002 if I'm correct.

Thomas Schwinge has been working on finding a replacement for the wiki,
but he is on vacation currently and will be back in September.

> I would also be willing to offer hosting and maintenance for it (if 
> the Gnufans domain is taken care of).

Duck has also offered hosting, that should not be a problem.

What might help is getting a dump/backup of the current gnufans wiki so
we can restore/integrate it with whatever wiki we are going to use.

Plus, does anybody know of plans for Savannah to supply wikis to its
projects?


Michael


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

Re: [patch] ISA-support in GNU Mach PCMCIA core

[Michael Banck]

On Mon, Sep 18, 2006 at 09:37:05PM +0200, Thomas Schwinge wrote:
>   * i386/linux/configure: Regenerate.
>   * i386/linux/device-drivers.h.in: Likewise.
> 
>   * i386/linux/configure.ac (AC_PCMCIA_OPTION): New function.

I thought one mentiones the configure: Regenerate after what prompted
the regeneration in the first place.  Don't know whether the GCS have
anything to say on this, though.


Michael


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

Re: GNU Mach: enabling all (working) device drivers by default?

[Michael Banck]

On Tue, Sep 19, 2006 at 02:37:50PM +0200, Thomas Schwinge wrote:
> What are people's feelings about having all (working) device drivers
> enabled by default when configuring GNU Mach?

What would happen if a user configures with --enable-ide?  Would that
mean it only enables ide, or would it be a no-op (or be removed?)

The problem I see is with potential IRQ sharing issues we still have.
AIUI, recompiling gnumach with minimal drivers might resolve those
issues in specific cases.


Michael


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

Re: GNU Mach: enabling all (working) device drivers by default?

[Michael Banck]

On Tue, Sep 19, 2006 at 09:43:55AM -0400, Barry deFreese wrote:
> How about we move all the drive into userspace? ;-)

Send patches.


Michael


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

Re: GNU Mach: enabling all (working) device drivers by default?

[Michael Banck]

On Wed, Sep 20, 2006 at 10:55:12AM +0200, Alfred M. Szmidt wrote:
>> and b) should now re-visit the file [GNU
>> Mach]/i386/README-Drivers and the output of `[GNU Mach]/configure
>> --help=recursive'.
> 
>And here I should add that you will notice that I also removed all
>the aliases for the device drivers but in turn improved the output
>of configure's help screens.
> 
> Please revert this, it makes it hard to do `./configure --help|grep
> alias'. 

I do not see how having these aliases as configuration options are
useful, why do you need them?


Michael


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

Re: transition to automake'fied GNU Mach

[Michael Banck]

On Thu, Oct 26, 2006 at 03:17:18PM +0300, Constantine Kousoulos wrote:
> Guillem Jover wrote:
> >If running unstable, the package automake was just uploaded, which
> >contains version 1.10.
> >
> 
> I don't see it here
> http://packages.debian.org/cgi-bin/search_packages.pl?keywords=automake&searchon=names&subword=1&version=unstable&release=all
 
Those web pages are usually outdated by a day or two, use
http://packages.qa.debian.org/ for more uptodate
information.


Michael


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

Hurd and FAUMachine

[Michael Banck]

Hi,

at Systems expo, there was a booth by the CS department of the
university of Erlangen showcasing their FAUMachine virtual machine.
They advertised it as VMWare-like, but it seems to be closer to qemu
(and indeed, after I asked them for a comparison to qemu, the guy
conceded they were using their code, though I don't know how much of
it).  FAUMachine has a nice GTK GUI and is licensed under the GPL.

I made them download Ben's LiveCD and try it out, but Mach stopped at
the SCSI detection and hang there.  I believe the LiveCD is supposed to
work with qemu, so it would be cool to have the Hurd working on this as
well.  Maybe it is just a matter of configuration (there didn't seem to
be much options for configuring the virtual machine's hardware though,
at least not presented by the GUI)

More information is available at http://www.faumachine.org


cheers,

Michael


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

Re: on HURD

[Michael Banck]

Hi,

On Wed, Nov 08, 2006 at 10:59:05PM +0530, arnuld wrote:
> it seems like HURD development is stalled.  also Debian HURD K10 CDs
> carry the date  Nov 26, 2005. we are developing HURD since 1983,
> almost 23 years now. i think we need to change our aproach. what does
> RMS say about this?

This is a technical list, please move meta-discussions about GNU
elsewhere.


thanks,

Michael

-- 
 BWAHAHAHAHAHAHHA
 MOAHAHAHAHAHA
--- Overfiend is now known as PUREFUCKINGEVIL
 BWAHAHAHAHA


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

Re: openexr: FTBFS on hurd-i386: duplicated case in switch

[Michael Banck]

reassign 396135 libc0.3-dev
retitle 396135 libc0.3-dev: Hurd errno 118 assigned twice (ECANCELED and 
ENOTSUP)
thanks

Hi,

Cyril wrote:
> since ECANCELED and ENOTSUP have the same value on hurd-i386, the
> build fails with:
> > IexThrowErrnoExc.cpp: In function 'void Iex::throwErrnoExc(const
> > std::string&, int)':
> > IexThrowErrnoExc.cpp:720: error: duplicate case value
> > IexThrowErrnoExc.cpp:679: error: previously used here

This is a bug in the Hurd-specific parts of glibc and should get fixed
upstream, rather.

See http://lists.gnu.org/archive/html/help-hurd/2003-06/msg00088.html
for further discussion:

|From: Roland McGrath
|Subject: Re: Why is ENOTSUP == ECANCELED?
|Date: Mon, 23 Jun 2003 19:44:19 -0400 (EDT)
|
|> On Mon, Jun 23, 2003 at 10:35:56PM +0200, Andreas Voegele wrote:
|> > In /include/bits/errno.h both ENOTSUP and ECANCELED get the value
|> > _HURD_ERRNO(118).  Is this intended?
|> 
|> I don't think so.  Roland can you fix this if it is wrong?
|
|They certainly should not have the same number.  The Hurd numbers are
|determined by magic comments in libc/manual/errno.texi; it appears that
|someone added some codes to errno.texi with magic comments and picked
|some random numbers for them (probably Linux numbers) instead of 
|omitting them.  That needs to be fixed.  Can you compare all the 
|numbers in errno.texi with those that existing Hurd binaries were 
|really using, and assign unused numbers to any excess errno codes the 
|Hurd didn't previously have?

(Note that AFAICT Linux doesn't use 118 for ENOTSUP or ECANCELED either)


Michael


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

Re: Bug#407079: libtool: All GNU targets support -Wl, --version-script

[Michael Banck]

(ccing bug-hurd rather than the bug as this starts getting more general)

On Sun, Jan 21, 2007 at 03:59:27PM +0100, Ralf Wildenhues wrote:
> Also I would like to see a complete port of Libtool to Hurd once
> we start down this road; i.e., one that passes as much of the CVS
> HEAD Libtool testsuite as possible.  The CVS testsuite can be run
> in the cross compilation case, see README; if you (or somebody else)
> is interested in doing the port, I'd be happy to assist; please
> send verbose test failure output to the bug-libtool list.

The 1.5.22 testsuite passed fine except for SKIP: deplibs.test, see:
http://experimental.ftbfs.de/fetch.php?&pkg=libtool&ver=1.5.22-4&arch=hurd-i386&stamp=1142952731&file=log&as=raw

Hopefully somebody can check that on CVS HEAD, do you expect big problems?


cheers,

Michael


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

Re: python 2.4: os.urandom() hangs if /dev/random, /dev/urandom are not reconnected to a translator

[Michael Banck]

On Sat, Jan 27, 2007 at 06:16:22PM +, massimo s. wrote:
> I thought that for os.urandom():
> - a timeout could be useful on any platform without a reliable random
> device (I don't think Hurd is alone in this). I'll ask to the python
> mailing list.

/dev/urandom does not provide reliable random data anyway; it's just a
problem if no data can be provided at all I guess.  An appropriate error
message should be raised in that case after some timeout maybe.

For /dev/random, things are different, it should block until reliable
random data is again available from the entropy pool, I think.

> - hurd-specifically, the module could maybe also check if a translator
> is attached to /dev/urandom and at least spit a warning if there is none.

A work-around on the Hurd is to copy a random binary (like /bin/bash) to
/dev/urandom.  

I don't think python should worry about Hurd implementation details
here.


Michael


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

Re: Google Summer of Code 2007

[Michael Banck]

Hi,

On Sun, Mar 11, 2007 at 08:44:00PM -0400, Barry deFreese wrote:
> Are we talking Debian specific stuff or no?  

This is about the FSF's GSoC project, so I don't think Debian-specific
stuff would be appropriate.

> There still the Debian installer afair.

Yes, but after last year's fiasco, I'm weary to waste another Debian
GSoC slot on Debian GNU/Hurd again, the port has enough PR problems in
Debian as is.

> Also, how about implementing PPP?

Some solution for DSL etc. wouldn't be bad, but today most people have
Ethernet of a dedicated DSL router I guess, so it's less urgent than a
couple of years ago I think.

> I think there was something about being able to boot from a stow'd
> filesystem?

That might be an important task for the GNU system, but AFAIK it's only
a matter of debugging/finding the culprit, not sure whether it merits a
GSoC project really.


Michael


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

Re: GRUB on GNU/Hurd (was: GNU/Hurd Rescue CD)

[Michael Banck]

On Wed, Mar 21, 2007 at 08:15:53PM +0100, [EMAIL PROTECTED] wrote:
> So, why doesn't it install a boot loader?

I think this probably because it uses an obsolete code base which never
did install Grub when installing GNU/Linux, either.

Adding this feature would still be welcome, but probably not too much
time should be taken by this, I don't know how hard it would be to dive
into the code etc. The old boot-floppies code we currently use is known
to be quite hard to maintain and extent, which is one of the major
reasons the debian-installer project got started to address these
issues.


Michael


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

[bug #19426] GNU Mach: panic: zalloc: zone kalloc.8192 exhausted

[Michael Banck]

URL:
  

 Summary: GNU Mach: panic: zalloc: zone kalloc.8192 exhausted
 Project: The GNU Hurd
Submitted by: mbanck
Submitted on: Tuesday 03/27/07 at 14:44
Category: GNU Mach
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Discussion Lock: Any
 Reproducibility: Intermittent
  Size (loc): None
 Planned Release: None
  Effort: 0.00
Wiki-like text discussion box: 

___

Details:

I got this panic twice now:

panic: zalloc: zone kalloc.8192 exhausted
eip:0x119127

from the Mach kdb trace:

[EMAIL PROTECTED]:/mnt/boot # addr2line -f -e gnumach-dbg 0x119127
Debugger
../kern/debug.c:104
[EMAIL PROTECTED]:/mnt/boot # addr2line -f -e gnumach-dbg 0x1190fe
panic
../kern/debug.c:143
[EMAIL PROTECTED]:/mnt/boot # addr2line -f -e gnumach-dbg 0x123ee0
zalloc
../kern/zalloc.c:505
[EMAIL PROTECTED]:/mnt/boot # addr2line -f -e gnumach-dbg 0x11b66a
kalloc
../kern/kalloc.c:185
[EMAIL PROTECTED]:/mnt/boot # addr2line -f -e gnumach-dbg 0x11a548
ipc_kobject_server
../kern/ipc_kobject.c:74
[EMAIL PROTECTED]:/mnt/boot # addr2line -f -e gnumach-dbg 0x14aed5
mach_msg_trap
../ipc/mach_msg.c:1367
[EMAIL PROTECTED]:/mnt/boot #

This time, a mysql build aborted with the following error message:

libtool: link: `libtaocrypt_la-aestables.lo' is not a valid libtool object
make[5]: *** [libtaocrypt.la] Error 1

After killing off the build processes and restarting another build, the
machine was becoming quite sluggish and Mach paniced quite soon thereafter
with the above zalloc exhausted message.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

Re: autoreconf -i breaks

[Michael Banck]

On Thu, Mar 29, 2007 at 06:05:20PM +0100, Ashish Gokhale wrote:
> I have Debian Linux Kernel 3.1, autoconf-2.59,
> automake-1.6.3.

As Thomas said, user automake1.9.


Michael


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

Re: [EMAIL PROTECTED]: gnumach ChangeLog config.status.dep.patch [gnumach-1-branch]]

[Michael Banck]

On Wed, Apr 11, 2007 at 12:50:55PM +0200, Thomas Schwinge wrote:
>  12:22:41 up 6 days,  6:00, 20 users,  load average: 145.63, 71.19, 28.72

> Does somebody want to try that on a GNU/Hurd system?  ;-)

I "tried" that when I built the Debian gcc-4.1 package from experimental
it had something like "$(MAKE) -j$(NUM_CPUS)" or so, and NUM_CPUS got
populated via /proc...


Michael


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

Re: ``No symbol table info available.'' (was: glibc 2.5 on GNU/Hurd with GCC 4.1: `EXC_BAD_ACCESS' in glibc nss code)

[Michael Banck]

On Fri, Apr 27, 2007 at 01:06:57PM +0200, Thomas Schwinge wrote:
> $ sudo gdb /hurd/password 328
> GNU gdb 6.5-debian
> [...]
> (gdb) bt full
> #0  0x011408f0 in _nss_files_parse_grent () from /lib/libc.so.0.3
> No symbol table info available.
> [...]
> #v-
> 
> Why is ``no symbol table info available'' for the glibc parts?  How to
> get that working?  I have the `-dbg' package installed.

Try to add LD_LIBRARY_PATH=/usr/lib/debug to the gdb environment via the
"set env" command.

AIUI, the libc0.3 at /usr/lib/debug/lib/libc-*.so (where gdb looks by
default) only has limited information for stack unwinding(?), as
you'd normally wouldn't need it for debugging.

If you want to debug glibc itself, use /usr/lib/debug/libc.so.0.3.

If LD_LIBRARY_PATH doesn't work, maybe
LD_PRELOAD=/usr/lib/debug/libc.so.0.3 does instead.


Michael


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

[bug #17646] glibc: ``-z relro''

[Michael Banck]

Follow-up Comment #3, bug #17646 (project hurd):

If I'm not wrong 2.5 got released a couple of days before this change, my
glibc-2.5 tarball doesn't seem to have the change Thomas referenced in
comment #1.

Did you try with glibc-2.6 from experimental instead (though more work is
probably needed there to get it built)?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

Re: develop hurd on virtual machine

[Michael Banck]

Hi,

On Sat, Jun 09, 2007 at 02:58:51PM +0200, christian nastasi wrote:
> Ok, some new questions.
> For the previous I understand on my own what can I do (or this is what I
> believe).
> - For the emulator I will use the bochs, because I see that there's an hurd
> image working with such emulator.

Qemu is also known to work, and much faster than bochs.

See http://hurd.gnufans.org/bin/view/Distrib/HurdOnQEMU

> - For the cross compiler I found the Thomas scripts at
> http://nic-nac-project.de/~schwinge/tmp/cross-gnu-env and
> http://nic-nac-project.de/~schwinge/tmp/cross-gnu
> 
> For these I have a problem. I follow the instruction reported in the file
> cross-gnu. First of all the gnumach-1-branch doesn't  work because in this
> tree "configure" and others were missing. 

You need to run `autoreconf -f -i' or something similar to generate
those, the automatically generated files have been removed from CVS
recently.

> So I decided to use the gnumach tree instead and it seems to be good.

The gnumach tree is unmaintained and known to be defunct.

> But same problem I found with the MIG.  Here follow the script output.
> "./cross-gnu: line 243:
> /home/chris/own/develop/gnu/hurd-cross-compilation/src/mig/configure: No
> such file or director"
> 
> What can I do?

See above.
 
> - My last question: does anybody used before the bochs and created some hurd
> image for it?

I haven't heard of people using Bochs for quite a while.


Michael


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

Re: Putting a random translator into the Hurd directly?

[Michael Banck]

On Mon, Jun 11, 2007 at 04:23:05PM -0400, Michael Casadevall wrote:
> I've recently started hacking on Hurd again, and I'm curious why a  
> random translator isn't included by default in the Hurd. Looking at  
> the wiki, there are at least two different translators; we should  
> have one of these included out of the box because without /dev/(u) 
> random, its impossible to have SSH and a bunch of other programs.

the GNU maintainers (well, Marcus mostly I think) have made it clear
that a good solution to entropy needs to be found for the Hurd, no
half-baked low-security solution will be acceptable (you could argue
that the current state is much worse, but this is intentional I think -
people should *immediately realize* that there is no cryptographically
secure /dev/random provided by the Hurd and act accordingly.  Having a
/dev/random device would make them think everything is fine)

On the other hand, I think the Debian GNU/Hurd would benefit from a
halfway secure solution and it would be a good test-bed for inclusion
upstream.

So if you have something working, the [EMAIL PROTECTED]
mailing list would be very interested.


Michael


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

Re: Putting a random translator into the Hurd directly?

[Michael Banck]

On Tue, Jun 12, 2007 at 10:51:48AM -0400, Michael Casadevall wrote:
> That makes sense, but why don't we still include a random module in  
> the source itself so people who are working on one at least can work  
> >from a common starting point, but make it so it isn't compiled in by  
> default. I mean, looking at the source, we have trivfs in the main  
> source, and that useless to everyone expect developers

As far as I am aware, nobody proposed a random translator for inclusion
yet anyway.

If you want to start on something now, maybe you could work in the
hurdextras repository which is meant for these things, and later on it
could be transferred to the main hurd source branch.

You should be ready to assign copyright to the FSF (and get people you
base your code on to assign their copyright as well) and follow the GNU
Coding Standards if you plan to propose it for inclusion.


Michael


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

Re: fatfs: slot_status COMPRESS

[Michael Banck]

Hi,

On Wed, Jun 13, 2007 at 10:31:33AM +0200, christian nastasi wrote:
> Just an other one? Could somebody help me with the problem I had had to
> compile the translator on the gnubber.bddebian.com machine as reported in
> http://lists.gnu.org/archive/html/bug-hurd/2007-06/msg00029.html ?

Did you read Samuel's reply at
http://lists.gnu.org/archive/html/bug-hurd/2007-06/msg00030.html ?

If you have further question about this, you should follow-up to his
answer detailing what is unclear.


Michael


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

poll() return value problems according to POSIX(?)

[Michael Banck]

(sorry if that is a FAQ, but google didn't find prior discussion)

Hi,

python2.5 introduced a configure check for a broken poll(), which is
positive on GNU/Hurd (thus HAVE_BROKEN_POLL is defined), but not Linux.

The code of the check is as follows:

#include 

int main (void)
{
struct pollfd poll_struct = { 42, POLLIN|POLLPRI|POLLOUT, 0 };

close (42);

int poll_test = poll (&poll_struct, 1, 0);

if (poll_test < 0)
{
exit(0);
}
[...]

on Linux, poll_test is 1 and errno is set to EBADF.  On GNU/Hurd,
poll_test is -1 and errno is set to EBADF.  This makes the test return
`0' and python define HAVE_BROKEN_POLL, which later on leads to build
errors in [python]/Modules/selectmodule.c.

According to POSIX[1] as I (and some people who pointed me to it) read
it, only EAGAIN, EINTR and EINVAL are valid errors, poll() should not
fail on others (like EBADF), but POLLNVAL should be set
accordingly in revents instead. 

Are we at fail here, is this python test bogus or am I just confused?


thanks,

Michael

-- 
[1] http://www.opengroup.org/onlinepubs/009695399/functions/poll.html


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

bind() broken for AF_UNIX in chroots

[Michael Banck]

Hi,

(The "use-case" here being that for some funky reason dbus needs to get
started in order to build core parts of Gnome in Debian, thus Gnome
is broken in Debian GNU/Hurd until this is fixed, or we decide to build
Gnome completely manually from now on)

The following program works fine in a real installation, but fails with
EADDRNOTAVAIL if run in a chroot:

#include 
#include 
#include 
#include 
#include 

#define SOCKET_ADDR "/tmp/foo"

int main(int argc, char** argv)
{
int fd;
struct sockaddr_un addr;
size_t path_len;

addr.sun_family = AF_UNIX;
path_len = strlen(SOCKET_ADDR);
strncpy(addr.sun_path, SOCKET_ADDR, path_len+1);

fd = socket(PF_UNIX, SOCK_STREAM, 0);
if (bind(fd, (struct sockaddr*) &addr, SUN_LEN(&addr)) < 0)
printf("Error: %s\n", strerror(errno));
}

(This code is a minimal reduction of the dbus-daemon startup code, which
fails in the same way)

The problem is apparently that /hurd/ifsock is set as a passive
translator in [glibc]/sysdeps/mach/hurd/bind.c via
__file_set_translator() and is not aware that it is started in a chroot:

 azeem: it seems that ifsock talks to a different pflocal than
the application
 azeem: could it be that it escapes the chroot somehow?
 what is "it"? ifsocks? the application?
 yes
 ifsocks
 one or the other ;)
 the starting of the translator ?  (that possibly doesn't even
know that there is chroot at stake)
 ah, hm
 youpi: yeah
 how should it know that anyway ?
 well
 youpi: oh
 you mean libc sets a passive translator?
 right

Otherwise, maybe this is a problem with the chroot setup, marcus
suggested setting a firmlink to the main pflocal as a work around, but I
was not successful in doing that (ordinary pipes work in the chroot,
by the way)

Is this an error in glibc or by myself?  Can anybody suggest a
work-around maybe, so that Gnome can be built again?


Michael


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

Re: bind() broken for AF_UNIX in chroots

[Michael Banck]

Hi,

On Fri, Jun 29, 2007 at 01:30:37PM +0200, [EMAIL PROTECTED] wrote:
> On Fri, Jun 29, 2007 at 03:00:54AM +0200, Michael Banck wrote:
> 
> > The following program works fine in a real installation, but fails with
> > EADDRNOTAVAIL if run in a chroot:
> 
> I think I get the same effect: Running it the first time (non-chrooted
> Linux or Hurd) works; second run always gets "address already in use".
> Same for "chroot /". chroot to another partition gives "address not
> available" on first run, and again "address already in use" on later
> runs.

That is EADDRINUSE and is expected if the socket already exists (so
you'd need to rm /tmp/foo in my example, or modify it to unlink the file
first).

The human readable error you get when running in a chroot is 'Cannot
assign requested address' when /tmp/foo does not exists (otherwise
you'll get EADDRINUSE as well), having /tmp/foo in the main root or not
does not matter in this case.


Sorry for being unclear,

Michael


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

Analysis of build failures in Debian GNU/Hurd

[Michael Banck]

Hello,

this mail is a summary of the different kinds of build failures the
Debian GNU/Hurd autobuilder has encountered while building through the
Debian archive.  I've CC'd it to bug-hurd as this should be of general
interest to the GNU Hurd as well.  I also skipped over most of the non
C/C++ failures and general build machine trouble.

Overall, slightly more than 50% of the Debian packages build fine on
Debian GNU/Hurd, around 28% have missing build dependencies, and around
18% fail.

Out of the 1281 packages failing, there are about a dozen main types of
failures:

 (1) Some constant like PATH_MAX being undeclared
 (2) Some header file like  not present
 (3) GNU/Hurd unknown to the build system
 (4) hurd-i386 not in architecture list (Debian specific)
 (5) Linking errors
 (6) Errors involving structs
 (7) Syntax errors possibly due to wrong cpp directives
 (8) Failures in Debian's debhelper scripts, usually uncovering previous
 build failures which got glossed over
 (9) Failed configure checks, usually for some header we do not have
 (10) Failures in test suites
 (11) Hangs/segfaults etc. in the build daemon while executing something

Note that I only counted the first build error here; i.e. it is entirely
possible that a program still uses PATH_MAX unconditionally even after a
missing header got implemented, for example.

 (1) 397 Undeclared constants:

- PATH_MAX: 155
- MAXPATHLEN: 76
- MAXHOSTNAMELEN: 34
- _IOT*: 14
- SA_SIGINFO: 11
- sys_errlist: 7
- MSG_NOSIGNAL: 9
- NOFILE: 7
- IPV6_PKTINFO: 5
- PTHREAD_MUTEX_RECURSIVE_NP: 4
- SOL_IP: 5
- PIPE_BUF: 4
- SOUND_MIXER_*: 4
- HZ: 3
- SIOCDEVPRIVATE: 3
- sys_nerr: 2
- MAP_NORESERVE: 2
- O_DIRECT: 2
- ONLCR: 2
- TABDLY: 2
- TCGETS: 2 
- SA_NOCLDWAIT: 2
- ETHER_ADDR_LEN: 2
- RLIMIT_AS: 2

The following declarations were missing once: AFMT_U8, AF_BLUETOOTH,
ARG_MAX, B9600, CDIOCEJECT, CDROM_SELECT_SPEED, CLONE_VM, CODESET,
CTL_BANK_SELECT, DEV_SERIAL_PREFIX, ETHERTYPE_IP, ETH_ALEN,
FAM_DEBUG_OFF, FIONREAD, F_SETSIG, IOV_MAX, IPV6_V6ONLY, IUCLC, LOCK_EX,
MCAST_JOIN_SOURCE_GROUP, MREMAP_MAYMOVE, OCRNL, OFILL, OPEN_MAX,
O_NOFOLLOW, PING_PROGRAM_FORMAT_6, POLLRDNORM, PPWDATA,
PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP, PTHREAD_STACK_MIN, QMAGIC,
SIGPWR, SIOCSIFHWADDR, SNDCTL_DSP_SETFRAGMENT, SOL_RAW, S_IFMT, TAB3,
TCSBRKP, TCSETS, TIOCGSERIAL, TIOCM_RI, _MAX_PATH

 (2) 329 Missing headers:

- sys/mount.h: 19
- net/if_arp.h: 17
- net/ethernet.h: 15
- termio.h: 12
- net/ppp_defs.h: 8
- net/route.h: 6
- sys/kd.h: 6
- sys/vt.h: 6
- netpacket/packet.h: 4

- linux/types.h: 20
- asm/types.h: 17
- linux/cdrom.h: 15
- linux/kd.h: 10
- linux/videodev.h: 9
- linux/fb.h: 6
- linux/hdreg.h: 6
- linux/joystick.h: 6
- linux/input.h: 6
- linux/fs.h: 4
- linux/if.h: 4
- linux/ioctl.h: 4
- linux/limits.h: 4

The following headers were mising three times or fewer: AppleEvents.h,
X11/forms.h, asm/byteorder.h, asm/ioctl.h, asm/ioctls.h, asm/page.h,
asm/param.h, asm/timex.h, asm/types.h, asm/unistd.h, ast.h, awe_voice.h,
caml/callback.h, caml/custom.h, caml/memory.h, caml/mlvalues.h,
cfortran.h, compiler-info.h, drm.h, fcntl.h, forms.h, initreq.h,
linux/apm_bios.h, linux/awe_voice.h, linux/capability.h, linux/cdrom.h,
linux/config.h, linux/cramfs_fs.h, linux/dvb/dmx.h,
linux/dvb/frontend.h, linux/errno.h, linux/fb.h, linux/fd.h, linux/fs.h,
linux/hdreg.h, linux/if.h, linux/if_ether.h, linux/if_tun.h,
linux/if_vlan.h, linux/in.h, linux/inotify.h, linux/input.h,
linux/ioctl.h, linux/isdn.h, linux/iso_fs.h, linux/joystick.h,
linux/kd.h, linux/kdev_t.h, linux/limits.h, linux/major.h,
linux/netdevice.h, linux/netfilter_ipv4.h, linux/nfs.h, linux/parport.h,
linux/posix_types.h, linux/reboot.h, linux/rtc.h, linux/rtnetlink.h,
linux/scc.h, linux/serial.h, linux/socket.h, linux/sockios.h,
linux/soundcard.h, linux/stat.h, linux/sys.h, linux/tty.h,
linux/types.h, linux/usbdevice_fs.h, linux/version.h, linux/videodev.h,
linux/vt.h, linux/wireless.h, machine/joystick.h, mem.h, net/ethernet.h,
net/if_arp.h, net/if_tun.h, net/ppp_defs.h, net/route.h,
netinet/ip_var.h, netipx/ipx.h, netpacket/packet.h, nlist.h, pcap.h,
scsi/scsi.h, scsi/sg.h, selinux/selinux.h, sun/audioio.h,
sundev/srreg.h, sys/endian.h, sys/epoll.h, sys/filio.h, sys/kd.h,
sys/mount.h, sys/prctl.h, sys/protosw.h, sys/soundcard.h, sys/sysctl.h,
sys/timex.h, sys/vm86.h, sys/vt.h, sysinfo.h, tcl8.3/tcl.h, termio.h,
tk.h, ufs/ufs/dinode.h, util.h, vis.h, windows.h

 (3) 70 build system issues
- 33 #error "unknown/unsupported architecture/platform/kernel"
  (compile time)
- 24 '*gnu*' "not supported yet", "your OS is NOT supported" etc.