Move u2f-devd into base?

[Christian Weisgerber]

We have FIDO/U2F support for SSH in base.

We also have a group "u2f", 116, in the default /etc/group file.

Why do we keep the devd configuration (to chgrp the device nodes)
in a port, security/u2f-devd?  Can't we just add this to base, too?
It's just another devd configuration file.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: Did clang 14 lose some intrinsics support?

[Christian Weisgerber]

Dimitry Andric:

> > See https://github.com/llvm/llvm-project/commit/e5147f82e1cb
> > 
> > - Instead of __builtin_ia32_pabsd128 maybe use _mm_abs_epi32
> > - Instead of __builtin_ia32_pabsd256 maybe use _mm256_abs_epi32
> 
> I'm wondering why this rather fragile method is chosen? If you want to
> know whether SSE is supported, you check for __SSE__, and similarly
> __SSE2__, __AVX__ and a bunch of others. That is also portable to gcc.

__AVX__, for instance, is not defined unless you compile with -mavx,
which also allows the compiler to issue AVX instructions during
normal code generation.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: [HEADSUP] making /bin/sh the default shell for root

[Christian Weisgerber]

Dirk Meyer:

> Migration of aliase will be painful as ">&" and "|&" is not supoported.

csh sh
>& foo  >foo 2>&1
|& foo  2>&1 | foo

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: Git and complementary web interfaces (some fast but basic, others fuller-featured)

[Christian Weisgerber]

On 2021-01-07, Graham Perrin  wrote:

> cgit describes itself as "hyperfast" with 
> "basic repository browsing" 
> as a feature.
>
> Beyond those basics, I guess that it will be appropriate to ensure 
> awareness of complementary web-based repository browsers including 
> GitHub and  GitLab;

Use of Git implies cloning the repository, so you have a local copy
of the repository and can run _local_ browsing tools to your heart's
desire.  E.g., you could set up your very own cgit web interface.

Personally, I'm fond of Got's curses-based repository browser tog(1).
I think that one is vaguely modeled on another tool called tig(1).
Undoubtedly, there are plenty of others.

The main value of Git web interfaces is easy browsing of foreign
repositories that you have not cloned.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Christian Weisgerber]

On 2021-01-01, Shawn Webb  wrote:

> This is why I asked FreeBSD to provide anonymous read-only ssh://
> support for git. I'm very grateful they support it.
>
> One thing that I need to do with the HardenedBSD infrastructure is
> publish on our site the ssh pubkeys of the server (both RSA and
> ed25519). I plan to do that sometime this coming week. I wonder if it
> would be a good idea for FreeBSD to do the same

The draft FreeBSD Git docs have the SSH fingerprints of the Git
servers.
https://github.com/bsdimp/freebsd-git-docs/blob/main/URLs.md

Here's one from my own ~/.ssh/known_hosts:
SHA256:y1ljKrKMD3lDObRUG3xJ9gXwEIuqnh306tSyFd1tuZE git.freebsd.org (ED25519)

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git and the loss of revision numbers

[Christian Weisgerber]

monochrome:

> the g is also in the uname output:
>
> main-c421-gf20c0e331-dirty

It's the brand new format: -c-g[-dirty]

https://cgit.freebsd.org/src/commit/sys/conf/newvers.sh?id=8d405efd73d3991fe1647f91a2b7c9989dd5f18f

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git and the loss of revision numbers

[Christian Weisgerber]

Michael Grimm:

> If I do understand it correctly, the switch from svn to git comes with a loss 
> of continuously increasing revision numbers.

Correct.

> Correct? If so I wonder how future security advisories and errata notices 
> will be composed. Will there be a date of the commit besides its hash being 
> reported? 

For over TWENTY YEARS, FreeBSD advisories have already contained
the date when the problem was corrected, e.g.:

  Topic:  Several vulnerabilities in procfs [REVISED]
  Category:   core
  Module: procfs
  Announced:  2000-12-18
  Reissued:   2000-12-29
  Affects:FreeBSD 4.x and 3.x prior to the correction date.
  Corrected:  2000-12-16 (FreeBSD 4.2-STABLE)
  2000-12-18 (FreeBSD 3.5.1-STABLE)

I think it is safe to assume that this practice will continue after
the switch to Git.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git tools for building in base?

[Christian Weisgerber]

On 2020-11-25, Warner Losh  wrote:

>> Shouldn't it be in base before the move to git?
>
> We will have got (from OpenBSD: Game Of Trees) in the future. It isn't
> quite there yet, however, so it's not in base.

Since got can't fetch from http(s) yet, there was talk of setting
up anon-ssh access.  What became of that?

devel/got, for those who want to play.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Plans for git

[Christian Weisgerber]

On 2020-09-21, Pete Wright  wrote:

> I believe the most detailed report on this was in the 2020-04 quarterly 
> status report:
> https://www.freebsd.org/news/status/report-2020-04-2020-06.html#Git-Migration-Working-Group

I saw that at the time.  It basically says that the conversion of
the repository is feasible.

> there is also the freebsd-git@ mailing list here:
> https://lists.freebsd.org/pipermail/freebsd-git/

Well, I was asking for a summary.

For instance, I don't know if the Git migration is merely a switch
of the version control system or what other changes will be layered
on top of it as a matter of course, e.g. will the development
infrastructure move to GitHub?  Don't answer that, just point me
to the information.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Plans for git

[Christian Weisgerber]

On 2020-09-21, Alexander Leidinger  wrote:

> In my opinion the people which drive this didn't keep it behind
> closed curtains, and they went step by step more public, as they
> made progress.  To me it looks like now, that they have something
> which is presentable to the world (and not only to committers),
> they presented it to the world.

Since I am one of the sad people who managed to miss all this public
information, where can we find a summary of what's planned for the
switch?

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Plans for git

[Christian Weisgerber]

On 2020-09-19, Zaphod Beeblebrox  wrote:

> Hrm.  Maybe what I hear others saying, tho, and not entirely being replied
> to is just a nice concise document of the why.  What I hear you saying is
> that GIT has momentum and that it's popular... (and I accept that --- it is
> evidently true), but then I hear handwaving about features, but no list of
> features that are a clear win/loose.

How about the very basics (that Warner appears to have lost sight
of)?

Git is a distributed version control system.  You clone a repository
and apart from pulling and pushing changes to another repository,
all your work happens with the local repository.  Subversion has a
central repository and needs to talk to the server all the time.
Laptop on a plane?  No change of workflow with Git.

And since it's your repository, you can cheaply create your own
branches, where you can commit your work and have a versioned history
of it instead of just a flat diff.  I can't overstate the value of
that.  Whether you work on something that will be pushed back
upstream or just your private changes, it has a full commit history.
You can easily revert commits, you can upstream it one by one, you
can upstream it with history.

When FreeBSD switched from CVS to SVN, there was hope or promise
of lightweight branches, but that never materialized.  Developers
still can't have private branches in the FreeBSD repository.  For
a while, a lot of development happened in a Perforce repository--a
commerical version control system, whose company had donated a
license--which offered this feature.  Nowadays, everybody who does
any but the most trivial development does so in a private Git
repository anyway.  It only makes sense to interface this directly
with the FreeBSD repository instead of going through a SVN<>Git
media break.

> Certainly the only clear things a quick search turns up that seem relevant
> is that GIT is GPL2.0 and SVN is Apache2.0.  This was enough for LLVM vs
> GCC and the repository is a core function, but I suppose not a necessary
> function for forked projects that can't abide, so...

There is a bit of historical precedent: The original BSD work at
Berkeley was kept in a SCCS repository, a proprietary version control
system at the time.

And of course the fact that significant FreeBSD development has
effectively happened in Perforce, then in Git for a long time and
is just merged back into the Subversion repository.  To put it
bluntly, the people doing the work have voted with their feet years
ago.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Plans for git

[Christian Weisgerber]

Kyle Evans:

> > > This is probably better for a separate thread, but any idea if there
> >
> > I'm going to regret asking, but what would you need this feature
> > for?
> 
> It's not necessarily that bad -- I used to use it for a poor
> substitute for git-worktree before I learned about that, for local
> projects that I had no intention of pushing back to the remote so I
> saved myself the overhead of hitting the network.

Got uses "bare" repositories from which you check out as many
worktrees as you want.  And you can just keep local changes on a
local branch.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Plans for git

[Christian Weisgerber]

Kyle Evans:

> > FWIW, I just committed a Got port (devel/got).
> 
> This is probably better for a separate thread, but any idea if there
> are plans to eventually support local filesystem cloning in got?

I wouldn't know.

I'm going to regret asking, but what would you need this feature
for?

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Plans for git

[Christian Weisgerber]

On 2020-09-02, Mason Loring Bliss  wrote:

> Just to throw it out there, https://gameoftrees.org/ would be interesting
> to explore for this.

FWIW, I just committed a Got port (devel/got).

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Sound lag over HDMI

[Christian Weisgerber]

Alexander Motin m...@freebsd.org wrote:

 I don't know what to say. I am now using HDMI audio from NVIDIA card to 
 quite old external 5.1 receiver with XBMC every day, and I haven't 
 noticed lags.
 
 The only potentially related effect I have noticed is that my receiver 
 eats first second or about that of playback stream.

That's from the receiver examining the incoming data to see if it
is AC-3, DTS, or plain PCM.

-- 
Christian naddy Weisgerber  na...@mips.inka.de

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: CVS removal from the base

[Christian Weisgerber]

Max Khon f...@samodelkin.net wrote:

 As soon as ports/ (and doc/) are moved to SVN I do not see any
 compelling reasons for keeping CVS in the base system.
 Those who still use it for development can install ports/devel/opencvs

Rather ports/devel/cvs-devel.  Maybe we still need a regular cvs
port.

-- 
Christian naddy Weisgerber  na...@mips.inka.de

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: groff -ms -Tascii (nroff?) strange output

[Christian Weisgerber]

Anton Shterenlikht me...@bristol.ac.uk wrote:

 BUZI groff -ms -Tascii try.1 | more
 
  ESC[1mSome titleESC[0m
 
 How can I get a plain text rendering
 from a troff document with ms macros?

With nroff, use the -c flag:

  nroff -ms -c -Tascii

The groff frontend has a more convoluted syntax for it:

  groff -ms -P -c -Tascii

-- 
Christian naddy Weisgerber  na...@mips.inka.de

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: nroff -mandoc | more no longer works

[Christian Weisgerber]

Robert Watson rwat...@freebsd.org wrote:

 I'm guessing this relates to nroff/groff tweaks, but I was a bit unhappy to 
 learn that the command I've used for the last decade to render man pages 
 while 
 editing them (nroff -mandoc foo.1 | more) no longer works (output below).

nroff -c -mandoc foo.1  should work as expected.

-- 
Christian naddy Weisgerber  na...@mips.inka.de

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Forward: HEADS UP! Default value of ip6_v6only changed

[Christian Weisgerber]

Hajimu UMEMOTO [EMAIL PROTECTED] wrote:

 Our default of net.inet6.ip6.v6only was off in 4.X, and was changed to
 on on 5.X to follow NetBSD's practice.  This behavior on 5.X breaks
 RFC2553/3493, and the change was intentional from security
 consideration.  But, NetBSD changed it off by default.

They have changed back.
http://mail-index.netbsd.org/tech-net/2003/11/03/.html

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Forward: HEADS UP! Default value of ip6_v6only changed

[Christian Weisgerber]

Hajimu UMEMOTO [EMAIL PROTECTED] wrote:

 Our default of net.inet6.ip6.v6only was off in 4.X, and was changed to
 on on 5.X to follow NetBSD's practice.  This behavior on 5.X breaks
 RFC2553/3493, and the change was intentional from security
 consideration.  But, NetBSD changed it off by default.

OpenBSD's behavior is equivalent to v6only on, and OpenBSD doesn't
even provide a knob.

Note that the default choice has a major impact on 3rd party software
(ports).  If we ship with a default of v6only off, then people will
not fix software to open two sockets.  This in turn means that
turning v6only on will break this software.  I predict that a good
many people will then consider the v6only option to be useless.

I understand that itojun would like to see this aspect of RFC2553
amended.  I don't know what the prospects of this happening are on
the IETF level.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Darwin/OSX Bluetooth code

[Christian Weisgerber]

Peter Pentchev [EMAIL PROTECTED] wrote:

 You've done some great work on BlueTooth.  IMHO, it would be a mistake
 to try to un-NetGraph it; there have been lots of rumours about people
 porting the NetGraph framework to other OS's, and if BlueTooth support
 will provide yet one more reason for the need to do this, so be it :)

FWIW, I'm not aware of any such work for OpenBSD, and I estimate
the chances of such work being integrated into OpenBSD as approximately
nil.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

idprio safe?

[Christian Weisgerber]

Is it safe nowadays to run a process at idle priority?  Or is there
still the danger of priority inversion / a deadlock?

On FreeBSD 4.x you can run a process, such as setiathome, at nice
level 19 and it will (almost) only ever get CPU time when no process
of normal priority competes with it.  FreeBSD 5.x is much fairer
in this respect, which has the unpleasant result that such a
background process will noticeably compete for CPU now.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Improvements to fsck performance in -current ...?

[Christian Weisgerber]

Lukas Ertl [EMAIL PROTECTED] wrote:

 It's not just the fsck application itself, background fsck basically needs
 file system snapshots, which are only available on UFS2, and I'm not sure
 if they can be backported to UFS1 at all.

Huh?  Snapshots are available for both UFS1 and UFS2, but only on 5.x.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Initial list of ports that fail due to -pthread

[Christian Weisgerber]

Kris Kennaway [EMAIL PROTECTED] wrote:

 mp3blaster-3.1.3

I have a patch, will talk to maintainer.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: NANO core dump on Current

[Christian Weisgerber]

Tim Aslat [EMAIL PROTECTED] wrote:

 I don't know if I'm the only one with this problem, but here goes.  
 I use Nano (/usr/ports/editors/nano) as my primary text editor, however
 Iv'e noticed that any time I use -CURRENT (on my notebook) it core dumps
 when saving a file.

This is due to a bug in nano and -CURRENT running by default with
malloc option R, which triggers the bug.

When I looked, I didn't understand the code well enough to provide
a fix, and I have been unable to reach the upstream maintainer by
e-mail.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: make -U

[Christian Weisgerber]

Juli Mallett [EMAIL PROTECTED] wrote:

 Why go thru those contortions?  I sometimes use make FOO= to define
 things.  -U obviously has a place, if it not existing means I have to
 have all these contortions to do a fairly obvious thing, yeah?

What are the exact semantics of -U supposed to be?

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Annoucning DragonFly BSD!

[Christian Weisgerber]

Julian Stacey [EMAIL PROTECTED] wrote:

 Periodicaly someone masquerades as Matt Dilllon. [...]
 Maybe this time the poster is the real Matthew Dillon, but I doubt it.

Well, I fetched the DragonFly repository, and if this is a hoax,
somebody went through an awful lot of work to make it look real.

http://grappa.unix-ag.uni-kl.de/cgi-bin/cvsweb/?cvsroot=dragonfly

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

restore(8) triggers panic

[Christian Weisgerber]

I decided to dump, newfs -O2, and restore -r some filesystems on
my -CURRENT/alpha box.  restore reliably triggered a panic such as
this:

  free inode /var/64 has 27384711479296 blocks
  bad block 1043841974, ino 64
  pid 51 (restore), uid 0 inumber 64 on /var: bad block
  free inode /var/64 had -100 blocks
  mode = 0177, inum = 78, fs = /var
  panic: ffs_valloc: dup alloc

UFS1 or UFS2, softupdates on or off, doesn't matter.

I eventually managed to restore the filesystem by populating it
with some dummy files and running the restore afterwards.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: sym disabling controller LED?

[Christian Weisgerber]

Michael Nottebrock [EMAIL PROTECTED] wrote:

 I have a Dawicontrol 2975U SCSI controller, which is handled by the sym 
 driver:
 
 sym0: 875 port 0xac00-0xacff mem 
 0xe3201000-0xe3201fff,0xe3203000-0xe32030ff irq 10 at device 8.0 on pci0
 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking
 
 I have connected the controller's LED-connector to the case hdd-LED and 
 it works fine (for example during loading the kernel) until sym takes 
 over the controller, then it remains dark.

Actually, that's a case of sym(4) failing to actuate the LED rather
than shutting it off.  Later sym chips control the LED in hardware,
but the '875 doesn't and the driver has to blink the LED.  The BIOS
supplied driver does, sym(4) apparently fails to do so for you.  I
seem to recall that there are several GPIO pins that can be used
to drive a LED; possibly this Dawicontrol adapter has the LED wired
to a non-standard port.

In case he doesn't pipe up here, contact sym(4)'s author, Gérard
Roudier [EMAIL PROTECTED].

sym(4) blinks the LED just fine on my equally '875-based Tekram
DC-390F.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

groff and X11 broken (before gcc3.2)

[Christian Weisgerber]

I just finished updating my alpha box to shortly before the gcc3.2
import and now I'm seeing some weird breakage:

$ man ls
out of memory

It's actually nroff (groff) that aborts.
Also:

$ startx
[...]
xinit:  No such file or directory (errno 2):  unable to connect to X server
xinit:  No such process (errno 3):  Server error.

(Hmm, actually that may be due to the XFree86-Server-4.2.0_5 to _6
update.  I think I haven't restarted the X11 server since.)

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: groff and X11 broken (before gcc3.2)

[Christian Weisgerber]

Eric Anholt [EMAIL PROTECTED] wrote:

  $ startx
  [...]
  xinit:  No such file or directory (errno 2):  unable to connect to X server
  xinit:  No such process (errno 3):  Server error.

Of course those xinit errors are useless; I should have looked at
XFree86.0.log.

 You need to either reinstall Xwrapper port, or setuid root your XFree86
 and accept the possible security holes.

*Smacks forehead*
I know that.  I really do.  I guess I wasn't quite awake yet this
morning.

 I wish we could accept having some sort of suid Xwrapper installed with
 XFree86-4-Server, but that would probably be shot down for security
 concerns by those who don't use startx.

I only use startx because xdm is chronically broken on alpha (at
least the way I use it).

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: 'gmake' port broken after (due to ?) GCC 3.2 import

[Christian Weisgerber]

Alexander Kabaev [EMAIL PROTECTED] wrote:

 Not a GCC fault. The bug is in internal gettext library gmake is linked
 with. I looked into read_alias_file function and I simply cannot believe
 what I am seeing there.

PR ports/41075.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: groff and X11 broken (before gcc3.2)

[Christian Weisgerber]

Christian Weisgerber [EMAIL PROTECTED] wrote:

 It's actually nroff (groff) that aborts.

Even a simple groff --version or groff --help will produce the
out of memory error.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: current buildworld failure on Alpha?

[Christian Weisgerber]

Wilko Bulte [EMAIL PROTECTED] wrote:

 ds10#make
 Segmentation fault (core dumped)
 /usr/src/Makefile.inc1, line 140: warning: make -f /dev/null -m
 /usr/src/share/mk  CPUTYPE=ev56 -V CPUTYPE returned non-zero status

There was a time window when make -V ... was broken on 64-bit
archs, i.e. it would segfault after printing the result.  This has
been fixed in revision 1.69 of make/main.c.

 FreeBSD ds10.wbnet 5.0-CURRENT FreeBSD 5.0-CURRENT #7: Sat Aug 10 19:51:27

make was fixed on August 11.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: port upgrade problem

[Christian Weisgerber]

Maxim M. Kazachek [EMAIL PROTECTED] wrote:

 /usr/ports/Mk/bsd.port.mk, line 2580: warning: duplicate script for
 target patch-message ignored

One of the recent changes in make (revision 1.38 of parse.c) causes
it to emit this type of warning.  This causes heaps of apparently
harmless warnings in some places and breakage in a few others.
Presumably the offending Makefiles should be fixed.  I haven't been
sufficiently annoyed yet to really look at the issue.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

What happened to sound?

[Christian Weisgerber]

-CURRENT/alpha as of 1..2 days ago.  I can load my sound modules
just fine

# kldstat
...
223 0xfe00031aa000 3snd_pcm.ko
232 0xfe00031da000 16000snd_sbc.ko
241 0xfe00031f 16000snd_sb16.ko

but they don't show up in the kernel messages, and the corresponding
devices under /dev don't exist.

This still used to work a week ago.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: What happened to sound?

[Christian Weisgerber]

Christian Weisgerber [EMAIL PROTECTED] wrote:

 -CURRENT/alpha as of 1..2 days ago.  I can load my sound modules
 just fine but they don't show up in the kernel messages, and the
 corresponding devices under /dev don't exist.

Must have been a fluke.  Everything is back after a reboot.
(The reason for the reboot, swap_pager_getswapspace: failed, is
another story...)

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Xmms

[Christian Weisgerber]

Andrzej Kwiatkowski [EMAIL PROTECTED] wrote:

 I've upgrade my FreeBSD 5.0 two days ago.
  
 Yesterday when i have compile XMMS from ports,

Threads were broken.  Update and try again.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

LP64: (int)signal()

[Christian Weisgerber]

I would like to clean up the last instances of (int)signal(...) in
the tree.  Any objection to the changes below?

Other occurrences not worth touching:
- contrib/opie/opieftpd.c:  contrib, not used
- libexec/bootpd/bootpd.c:  #ifdef'ed out in favor of sigaction().

Index: atmarpd/atmarpd.c
===
RCS file: /home/ncvs/src/usr.sbin/atm/atmarpd/atmarpd.c,v
retrieving revision 1.4
diff -u -r1.4 atmarpd.c
--- atmarpd/atmarpd.c   9 Dec 2000 09:35:42 -   1.4
+++ atmarpd/atmarpd.c   1 Jul 2002 11:38:07 -
@@ -294,8 +294,7 @@
/*
 * Set up signal handlers
 */
-   rc = (int)signal(SIGINT, atmarp_sigint);
-   if (rc == -1) {
+   if (signal(SIGINT, atmarp_sigint) == SIG_ERR) {
atmarp_log(LOG_ERR, SIGINT signal setup failed);
exit(1);
}
Index: scspd/scspd.c
===
RCS file: /home/ncvs/src/usr.sbin/atm/scspd/scspd.c,v
retrieving revision 1.4
diff -u -r1.4 scspd.c
--- scspd/scspd.c   9 Dec 2000 09:35:42 -   1.4
+++ scspd/scspd.c   1 Jul 2002 11:38:08 -
@@ -319,14 +319,12 @@
/*
 * Set up signal handlers
 */
-   rc = (int)signal(SIGHUP, scsp_sighup);
-   if (rc == -1) {
+   if (signal(SIGHUP, scsp_sighup) == SIG_ERR) {
scsp_log(LOG_ERR, SIGHUP signal setup failed);
exit(1);
}
 
-   rc = (int)signal(SIGINT, scsp_sigint);
-   if (rc == -1) {
+   if (signal(SIGINT, scsp_sigint) == SIG_ERR) {
scsp_log(LOG_ERR, SIGINT signal setup failed);
exit(1);
}
-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: LP64: (int)signal()

[Christian Weisgerber]

Mike Barcroft [EMAIL PROTECTED] wrote:

 You might want to get rid of the other misuse of `rc' above this and
 just remove the variable.

The use of an gratuitous int variable rc to capture return values
is rampant throughout this code.  In fact, not using it is something
of a violation of the local style, but in the case of signal() I
think it's justifiable because SIG_ERR is so much neater than
changing rc to long and messing around with explicit casts.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: State of the ports collection

[Christian Weisgerber]

Kris Kennaway [EMAIL PROTECTED] wrote:

 It seems like ports committers are not able to keep up with the
 rate at which ports are being broken by -current changes:

Since I originally stated that I would work on fixing ports on alpha
and I have clearly failed to do so, I would like to point out that
I have a hard time simply keeping up with the rate of disruptive
changes and breakage in the -CURRENT base system.

Also, either there aren't enough HEAD UPs or I keep missing them.
(E.g., do we have a working C++ compiler again?)

I suspect that by far most port maintainers only run -STABLE and
are simply unaware of the the changes happening in -CURRENT.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

ppc(4) vs. ppbus(4) module?

[Christian Weisgerber]

So far, I've had

device ppc
device ppbus
device lpt

in my KERNEL file to provide parallel printer support.  Now I've
noticed that ppbus and lpt are also available as modules.  However,
when I try to build a kernel with just

device ppc

(intending to load ppbus.ko and lpt.ko later), the build aborts
because sys/isa/ppc.c tries to include ppbus_if.h, which isn't
available without device ppbus.

Okay, so I'll just include device ppbus again, I guess.  But then,
what's the point of having a ppbus.ko at all?

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Serial break into debugger broken from 'cu' on -CURRENT?

[Christian Weisgerber]

Robert Watson [EMAIL PROTECTED] wrote:

 (1) Is serial break currently broken in -CURRENT

I can drop just fine into ddb with a serial break on my -CURRENT
AlphaPC164.  My kernel configuration has option BREAK_TO_DEBUGGER.

 (2) Is serial break currently broken in 'cu'?

Works just fine from abovementioned alpha to my sparc.
I don't have a pair of FreeBSD boxes tied together like that.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Serial break into debugger broken from 'cu' on -CURRENT?

[Christian Weisgerber]

Wilko Bulte [EMAIL PROTECTED] wrote:

 It could be that the DS10 was sufficiently catatonic to not react to
 a break (how likely is that in the first place? I was looking at a hard
 lockup).

If you experience one of the lockups that currently plague
-CURRENT/alpha, the machine won't react to break, ctrl-alt-esc, or
anything else except HALT and RESET.

 Now that I followed Drew's suggestion to
 
 quote
 I suggest reverting rev 1.61 of alpha/alpha/interrupt.c (eg, disable
 interrupt thread preemption).
 /quote
 
 I have not seen a lockup anymore.

Neither have I, but I have only been running with it for a day, and
it has previously managed to survive for up to two days without
locking up.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Non 386 testers REALLY NEEDED

[Christian Weisgerber]

Wilko Bulte [EMAIL PROTECTED] wrote:

 C'mon guys: it is not so long ago (days..) that the Alpha started
 buildworlding -current again.

I tried, and the new kernel blew up at start-up with an unaligned
access.  GENERIC went farther, but died when /etc/rc redundandly
tried to load the osf1 module.  I didn't report it because I haven't
had time to look at any details.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: buildworld fails in pam on Alpha

[Christian Weisgerber]

Wilko Bulte [EMAIL PROTECTED] wrote:

 Now that current on Alpha builds a lot better than a
 few days back it fails in:

 /usr/src/lib/libpam/libpam/pam_get_pass.c:60: warning: type mismatch in
 implicit declaration for built-in function `memset'
 /usr/src/lib/libpam/libpam/pam_get_pass.c:60: warning: type mismatch in
 implicit declaration for built-in function `strlen'

That's the characteristic signature of a missing #include string.h.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Anonymous FreeBSD CVS Servers

[Christian Weisgerber]

Glenn Gombert [EMAIL PROTECTED] wrote:

 Are there any FreeBSD 'Anonymous' FreeBSD Servers avaiable besides:
  :pserver:[EMAIL PROTECTED]:/home/ncvs ,

anoncvs.de.openbsd.org

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: cp in INSTALLTMP?

[Christian Weisgerber]

John Baldwin [EMAIL PROTECTED] wrote:

 Yes, I've seen this.  I'm betting it is timing related, and that dfr's fix to
 pmap.c will fix this.

Indeed it is gone now.  make installworld works fine without cp.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

cp in INSTALLTMP?

[Christian Weisgerber]

I don't know why nobody else seems to be seeing this, but cp is
used several times during installworld, which consequently fails
for me unless cp is added to INSTALLTMP.

...
=== gnu/lib/libreadline/history
install -c -o root -g wheel -m 444   libhistory.a /usr/lib
install -c -o root -g wheel -m 444   libhistory_p.a /usr/lib
install -c -s -o root -g wheel -m 444 libhistory.so.4 /usr/lib
ln -sf libhistory.so.4 /usr/lib/libhistory.so
cp /usr/src/gnu/lib/libreadline/history/../../../../contrib/libreadline/doc/history.3 
rlhistory.3
install -c -o root -g wheel -m 444 rlhistory.3.gz  /usr/share/man/man3
...
=== gnu/usr.bin/cvs/contrib
...
cp /usr/src/gnu/usr.bin/cvs/contrib/../../../../contrib/cvs/contrib/rcs2log.sh rcs2log
install -c -o root  -g wheel -m 555   rcs2log /usr/share/examples/cvs/contrib/rcs2log
...
=== gnu/usr.bin/perl/library/re
rm -f re_exec.c
cp ../../regexec.c re_exec.c
cc -c  -fno-strict-aliasing -DAPPLLIB_EXP=/usr/libdata/perl/BSDPAN 
-DVERSION=\0.02\  -DXS_VERSION=\0.02\ -DPIC -fpic 
-I/home/obj/usr/src/gnu/usr.bin/perl/library/re -I/usr/obj/usr/src/alpha/usr/include 
re_exec.c
rm -f re_comp.c
cp ../../regcomp.c re_comp.c
cc -c  -fno-strict-aliasing -DAPPLLIB_EXP=/usr/libdata/perl/BSDPAN 
-DVERSION=\0.02\  -DXS_VERSION=\0.02\ -DPIC -fpic -I/home/obj/usr/src/gnu/usr.bin 
/perl/library/re -I/usr/obj/usr/src/alpha/usr/include re_comp.c
...
=== gnu/usr.bin/perl/pod/pod2man
install -c  -o root -g wheel -m 555   pod2man /usr/bin
cp -p 
/usr/src/gnu/usr.bin/perl/pod/pod2man/../../../../../contrib/perl5/pod/pod2man.PL 
pod2man.PL
...

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: cp in INSTALLTMP?

[Christian Weisgerber]

Bruce Evans [EMAIL PROTECTED] wrote:

  I don't know why nobody else seems to be seeing this, but cp is
 
 This might be caused by having the sources and objects on different
 machines with inconsistent clocks.

No, it's all local on a single machine.
FWIW, I'm on alpha.

  === gnu/usr.bin/perl/library/re
 [...]
 Does all this happen at install time?

Yes.  make installworld from yesterday.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: more anoncvs servers Re: none

[Christian Weisgerber]

David O'Brien [EMAIL PROTECTED] wrote:

 What is the right mailing list to plead for more anoncvs mirrors?

grappa.unix-ag.uni-kl.de provides anoncvs, among other services.
(See http://.../ for a list.)

However,
- the box runs on OpenBSD, and since all three BSDs appear to use
  incompatible extensions for additional keyword expansion, $FreeBSD$
  will not be properly expanded;
- it's slow and loaded.  (I'm working on a replacement machine.)

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: more anoncvs servers Re: none

[Christian Weisgerber]

David O'Brien [EMAIL PROTECTED] wrote:

  - You need a pretty powerful machine to handle even, say, 4-6 clients
at a time.  Anonymous CVS is a hog like you wouldn't believe.
 
 I have to wonder if there are tricks one can use.

No.  Get a gig of memory, and put ~anoncvs/tmp on a memory disk.
A monster of a fast disk system, RAID with lots of disks, also
helps.

 The GCC and OpenBSD people depend on anoncvs as their main repo transport
 mechanism.

(You can't transport a repo with cvs.  OpenBSD infrastructure
currently uses a grown mix of sup, cvsup, cvs, and rsync.)

 I would imagine there are more than 4-6 people using their
 anoncvs services at times.

Speaking for OpenBSD, these are either big machines, or anoncvs is
real slow.  There were times when src or ports tree updates took
all night.

John may have exaggerated a bit, but anoncvs is indeed a hog.
grappa.unix-ag.uni-kl.de is a pentium-100, 64M box.  We used to
experimentally run with MFS, because OpenBSD prior to 2.9 didn't
have reliable soft updates, and the box basically ran from swap.
Nowdays, ~anoncvs/tmp is back on disk.  Single spindle.  The disk
hasn't exploded yet, but with, say, three anoncvs clients in parallel,
it sure is maxed out.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

buildworld fails in src/lib/libc/posix1e

[Christian Weisgerber]

...
cc -nostdinc -O -pipe -mcpu=ev56 -mcpu=ev56 -DLIBC_RCS -DSYSLIBC_RCS 
-I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -DLIBC_MAJOR=5 
-D__DBINTERFACE_PRIVATE -DINET6 -I/home/obj/usr/src/lib/libc -DPOSIX_MISTAKE 
-I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -DYP -DHESIOD 
-I/usr/obj/usr/src/alpha/usr/include  -c /usr/src/lib/libc/../libc/posix1e/cap_copy.c 
-o cap_copy.o
/usr/src/lib/libc/../libc/posix1e/cap_copy.c:46: conflicting types for `cap_copy_ext'
/usr/obj/usr/src/alpha/usr/include/sys/capability.h:219: previous declaration of 
`cap_copy_ext'
...

cap_copy.c: int cap_copy_ext(void *ext_p, cap_t cap, ssize_t size)
capability.h:   ssize_t cap_copy_ext(void *, cap_t, ssize_t)

On alpha, ssize_t comes down to long (_BSD_SSIZE_T_ in
src/sys/alpha/include/ansi.h).

The same problem applies to cap_size().

Index: lib/libc/posix1e/cap_copy.c
===
RCS file: /cvs/src/lib/libc/posix1e/cap_copy.c,v
retrieving revision 1.1
diff -u -r1.1 cap_copy.c
--- lib/libc/posix1e/cap_copy.c 31 Aug 2001 02:07:48 -  1.1
+++ lib/libc/posix1e/cap_copy.c 2 Sep 2001 20:38:45 -
@@ -41,7 +41,7 @@
 #include errno.h
 #include stdlib.h
 
-int
+ssize_t
 cap_copy_ext(void *ext_p, cap_t cap, ssize_t size)
 {
if (size  0) {
@@ -72,8 +72,8 @@
}
return (c);
 }
-   
-int
+
+ssize_t
 cap_size(cap_t cap)
 {
(void)cap; /* silence warning */
-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: What's touching my executables?

[Christian Weisgerber]

I wrote:

 An increasing number of executables on that box are sporting ever
 newer mtimes.  This appears to have been going on ever since the
 Jul 25 update.  There is no clear pattern which executables are
 touched.  md5 comparisons with previous backup levels (using a Jul 13
 copy of md5) suggest that the executables have not been changed.

I have updated the box (HEAD from Friday, alpha).  The phenomenon
still persists.

I haven't observed any mtime changes on non-executable files.

I'm running a small program that uses a kqueue(2) EVFILT_VNODE/NOTE_ATTRIB
filter to watch for changes to /bin/*.  During the last few hours
some files there have changed their mtime without a kernel event
being triggered.  (An explicit touch(1) does trigger an event.)

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

What's touching my executables?

[Christian Weisgerber]

-CURRENT (Jul 25), alpha.

An increasing number of executables on that box are sporting ever
newer mtimes.  This appears to have been going on ever since the
Jul 25 update.  There is no clear pattern which executables are
touched.  md5 comparisons with previous backup levels (using a Jul 13
copy of md5) suggest that the executables have not been changed.

For various reasons I consider it unlikely that I'm dealing with a
security issue here, although I'm looking into that as well.

Can anybody think of a technical explanation?

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: What's touching my executables?

[Christian Weisgerber]

Will Andrews [EMAIL PROTECTED] wrote:

 Probably the recent change (IIRC) that someone turned running an
 executable into a mtime change.

That was about _atime_ and the discussion was still going on after
I last updated the box.  Besides, I verified that simply running
an executable does not lead to an mtime change.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Anoncvs support

[Christian Weisgerber]

Will Andrews [EMAIL PROTECTED] wrote:

 A service which, IMO, is still not very well supported.  That's probably
 one reason why it's hard to get new developers (not everyone feels like
 syncing the entire repo).  But then again, I wonder how much load there
 is on anoncvs.freebsd.org.  Still, would be nice to have more than one
 anoncvs server, since not everyone's in the U.S.A.

http://grappa.unix-ag.uni-kl.de/

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: new breakage in mounting root? a devfs issue?

[Christian Weisgerber]

Andrea Campi [EMAIL PROTECTED] wrote:

 Seriously, if it's a new breakage, it's not breaking for everybody.

As I already reported to -alpha, it's breaking for me (sources as
of ~March 10) with a custom kernel.  Doesn't happen with GENERIC.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: tape device names and devfs

[Christian Weisgerber]

Steve Kargl [EMAIL PROTECTED] wrote:

 dump.8 and dump(8) both refer explicitly to nsa0 and nrsa0 whereas
 sa0 and nsa0 are the actual device names in -current.

Then this should be fixed.
The non-'r' device names have been standard in -CURRENT for quite
some time.  MAKEDEV only creates 'r'-names for backwards compatibility.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: tape device names and devfs

[Christian Weisgerber]

Steve Kargl [EMAIL PROTECTED] wrote:

   dump.8 and dump(8) both refer explicitly to rsa0 and nrsa0 whereas
   sa0 and nsa0 are the actual device names in -current.
  
  Then this should be fixed.
 
 But, what is the correct fix?  Add symlink magic to rc.devfs?
 Change dump(8)?

Yes, dump(8) and restore(8) need to be updated.  I'll submit a PR.

 MAKEDEV's behavior satisfies POLA by creating the symlinks.  If
 symlinks aren't created in rc.devfs, then how many (custom)
 scripts will this break?

I haven't heard any screaming yet.  Besides, this is -CURRENT.
devfs has also abandoned symlinks for 'r' disk devices.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: tape device names and devfs

[Christian Weisgerber]

Steve Kargl [EMAIL PROTECTED] wrote:

 The "r" in tape device names has traditionally meant "r"ewind.

No.
We've been over this before.  If you check the old 4.xBSD releases,
the 'r' clearly means "raw device".  Once upon a time there were
tape block devices.

 The rewind and non-rewind tape device names were changed under
 devfs from rsa0 and nrsa0 to sa0 and nsa0, (which IMHO
 violates POLA).

They were changed in MAKEDEV long before that.  MAKEDEV also provides
'r' names for compatibility.  devfs simply did away with those
compat links.  For all kinds of devices, not only the tape drives.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

dump(8) segfaults

[Christian Weisgerber]

This is on alpha--does anybody see this on i386 as well?

naddy@kemoauc[~] dump 0af /dev/null /dev/da0a
  DUMP: Date of this level 0 dump: Sun Feb 25 15:33:49 2001
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/da0a (/) to /dev/null
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 67655 tape blocks.
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: SIGSEGV: ABORTING!
  DUMP: SIGSEGV: ABORTING!
  DUMP: SIGSEGV: ABORTING!
  DUMP: SIGSEGV: ABORTING!
  DUMP: SIGSEGV: ABORTING!
Segmentation fault

-current as of Feb 20.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: weird cvs update problem

[Christian Weisgerber]

Brian Somers [EMAIL PROTECTED] wrote:

 ISTR Christian Weisgerber [EMAIL PROTECTED] was having this problem 
 too.

Sorry, you're misremembering.  I've never seen anything like this.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: mergemaster and $FreeBSD$

[Christian Weisgerber]

Archie Cobbs [EMAIL PROTECTED] wrote:

 even worse, mergemaster in some cases seems to be comparing only
 the $FreeBSD$ strings and incorrectly concluding that certain
 files don't need upgrading, when in fact they do.

If the -s switch isn't specified, mergemaster compares id strings
first, and if these match it will consider the files equal.  This
is *very* handy, as it saves you from dealing with your local
changes again and again, even though nothing has changed in the
corresponding release files.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: tar : needs some attention?

[Christian Weisgerber]

John W. De Boskey [EMAIL PROTECTED] wrote:

 tar: cdrom/disc2/dev/acd0t39: minor number too large; not dumped
 
Is this the expected behaviour,

Expected behavior; you can't store 32-bit minor numbers in tar's
archive format.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: -Current + X 4.0.1 = mouse problems

[Christian Weisgerber]

Doug Barton [EMAIL PROTECTED] wrote:

   Previously I had X + moused working just fine, so I had the best
 of both worlds. With X 4.0.1 if I use moused I get no response from the
 mouse in X at all.

Make sure you use

Option  "Protocol" "MouseSystems"

Protocol "Auto" is not reliable.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: fetch | sh panics system

[Christian Weisgerber]

Christian Weisgerber [EMAIL PROTECTED] wrote:

 The following, completely innocuous command line
 $ fetch -o - http://sites.inka.de/mips/unix/freebsd/xterm.shar | sh
 executed as a non-priviledged user, reproducibly panics the machine.

It's caused by fdesc mounted on /dev/fd.
I sent in a PR, kern/18952.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: fetch | sh panics system

[Christian Weisgerber]

Christian Weisgerber [EMAIL PROTECTED] wrote:

 The following, completely innocuous command line
 $ fetch -o - http://sites.inka.de/mips/unix/freebsd/xterm.shar | sh
 executed as a non-priviledged user, reproducibly panics the machine.

Some people have mailed that this particular command line just
works on their machines. I'm not surprised.

Still there must be some sort of problem, which happens to be
triggered accidentally on my box for this unlikely case. I updated
to yesterday's -CURRENT, and the problem persists. This is perfectly
reproducible.

I'll happily provide more details on my configuration, if anybody
can give me a clue what might sensibly affect this.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

fetch | sh panics system

[Christian Weisgerber]

5.0-CURRENT from ~May 17, dual ppro.

The following, completely innocuous command line

$ fetch -o - http://sites.inka.de/mips/unix/freebsd/xterm.shar | sh

executed as a non-priviledged user, reproducibly panics the machine.

-
#0  boot (howto=256) at ../../kern/kern_shutdown.c:303
#1  0xc0163879 in panic (fmt=0xc028dc4f "page fault")
at ../../kern/kern_shutdown.c:553
#2  0xc025760c in trap_fatal (frame=0xc8830d74, eva=52)
at ../../i386/i386/trap.c:927
#3  0xc025727d in trap_pfault (frame=0xc8830d74, usermode=0, eva=52)
at ../../i386/i386/trap.c:820
#4  0xc0256de3 in trap (frame={tf_fs = -930938856, tf_es = -1072103408, 
  tf_ds = -1062797296, tf_edi = -930935184, tf_esi = -930935300, 
  tf_ebp = -930935340, tf_isp = -930935392, tf_ebx = -931419456, 
  tf_edx = 0, tf_ecx = 13, tf_eax = -930935360, tf_trapno = 12, 
  tf_err = 0, tf_eip = -1062106920, tf_cs = 8, tf_eflags = 66195, 
  tf_esp = -930935360, tf_ss = -930935300}) at ../../i386/i386/trap.c:426
#5  0xc0b188d8 in ?? ()
#6  0xc0198fae in vn_open (ndp=0xc8830ec8, fmode=1026, cmode=420)
at vnode_if.h:305
#7  0xc0195005 in open (p=0xc7df7a00, uap=0xc8830f80)
at ../../kern/vfs_syscalls.c:995
#8  0xc025793d in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
  tf_edi = 8, tf_esi = 672168216, tf_ebp = -1077938468, 
  tf_isp = -930934828, tf_ebx = 672102756, tf_edx = 672168216, 
  tf_ecx = 15, tf_eax = 5, tf_trapno = 12, tf_err = 2, tf_eip = 672019108, 
  tf_cs = 31, tf_eflags = 663, tf_esp = -1077938512, tf_ss = 47})
at ../../i386/i386/trap.c:1126
#9  0xc024579e in Xint0x80_syscall ()

-- 
Christian "naddy" Weisgerber [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Internal USR I-modem current?

[Christian Weisgerber]

Timo Geusch [EMAIL PROTECTED] wrote:

 I recently got my hands on an internal Courier I-Modem. [...]
 Any ideas where I need to look to get this card configured by the PnP
 mechanism?

Have you jumpered the card correctly?

I don't know whether those details were changed over the lifetime
of the product, but the old card I have here has a set of jumpers
allowing for COM1..COM4, and PnP as a fifth setting.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Anyone else seeing jumpy mice?

[Christian Weisgerber]

Stijn Hoop [EMAIL PROTECTED] wrote:

 I do have /dev/psm0 in my XF86Config. You're saying it is better to
 use /dev/sysmouse, Protocol moused?

If you have moused running, set XF86Config to /dev/sysmouse, protocol
"MouseSystems".

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Wide-char support and libc

[Christian Weisgerber]

(This should move to freebsd-i18n.)

Donn Miller [EMAIL PROTECTED] wrote:

 Anyone like the idea of adding wide char support to our libc?

I'd like the idea of somebody explaining where/how I can get an
overview of what's missing in the first place.

 Maybe we could port it over from {Net,Open}BSD or BSDi.

Assuming any of those have it, in the first place. I'm fairly sure,
NetBSD and OpenBSD don't.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

cvsup on recent -CURRENT

[Christian Weisgerber]

On this machine which runs -CURRENT from two days ago or so, I'm
seeing frequent cvsup client failures of this type:

TreeList failed: Network write failure: Connection closed

I don't recall ever running into this before.

-- 
Christian "naddy" Weisgerber [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cvsup on recent -CURRENT

[Christian Weisgerber]

(My original question should have gone out last Thursday but had
been stuck in a mail queue since.)

Nick Hibma [EMAIL PROTECTED] wrote:

  TreeList failed: Network write failure: Connection closed
 
 Which host are you pilling from? I am slurping things out of
 cvsup.uk.freebsd.org and see the same messages.

The problem was most apparent with cvsup.uk.openbsd.org, which is
probably the same machine. It was less severe with cvsup.pasta.cs.uit.no,
and didn't occur at all with cvsup3.de.freebsd.org and for localhost
connections.

Disabling newreno

  sysctl -w net.inet.tcp.newreno=0

immediately fixed the problem, so I guess we have the culprit there.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

unknown: PNP...

[Christian Weisgerber]

I just updated an i386 machine after a month to the latest 5.0-CURRENT,
and I now get some strange boot messages:

isa0: too many memory ranges
...
unknown0: PNP at port 0x20-0x21,0xa0-0xa1 irq 2 on isa0
unknown1: PNP0200 at port 0-0xf,0x81-0x83,0x87,0x89-0x8b,0x8f-0x91,0xc0-0xdf drq 4 
on isa0
unknown2: PNP0100 at port 0x40-0x43 irq 0 on isa0
unknown3: PNP0b00 at port 0x70-0x71 irq 8 on isa0
unknown: PNP0303 can't assign resources
unknown4: PNP0800 at port 0x61 on isa0
npxisa0: Legacy ISA coprocessor support at port 0xf0-0xff irq 13 on isa0
unknown5: PNP0c01 at iomem 
0xf-0xf3fff,0xf4000-0xf7fff,0xf8000-0xf,0xcc800-0xc,0-0x9,0xfffe-0x,0xfec0-0xfec0,0xfee0-0xfee0
 on isa0
unknown6: PNP0a03 at port 0x4d0-0x4d1,0xcf8-0xcff,0x480-0x48f on isa0
unknown7: PNP0c02 at port 0x208-0x20f on isa0
unknown: PNP0501 can't assign resources
unknown: PNP0700 can't assign resources
unknown8: PNP0401 at port 0x378-0x37b,0x778-0x77a irq 7 on isa0
unknown: PNP0501 can't assign resources

Any comments?

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Undocumented tape devices in pax(1)

[Christian Weisgerber]

Kris Kennaway [EMAIL PROTECTED] wrote:

 Can someone explain to me why pax(1) has (undocumented) switches which
 select some tape devices, but apparently randomly numbered ones:

Note that these switches appear only in pax' tar compatibility
personality, which isn't used in FreeBSD. And the reason they're
there is because old versions of tar had them.

I'm looking at 4.3BSD's usr/src/bin/tar.c right now, and it supports
-[014578] to select the respective "/dev/rmt#" device.

 These are selectable through -0, -1, -4, etc. Nevermind the fact that they
 point to devices which have never existed in FreeBSD, but why on earth
 wouldn't you want -2, -3, or -6?

Historical reasons.

Back in 4.3BSD, bits 0 and 1 of the minor number seem to have
specified the device, bit 2 marked non-rewinding, bit 3 6250bpi
(high density?). That explains rmt[0145] well enough, although
rmt[78] remain unclear.

 Anyway, does anyone see the point in leaving these in (changing the
 devices to /dev/rsa# and documenting their existence), or should I rip
 them out?

OpenBSD only changed "rmt" to "rst" ("rsa" for us), which isn't
particularly useful. Solaris uses 0..7 to select an entry from
/etc/default/tar, which specifies device name, block size, and tape
size.

I guess mapping -[01] to rsa[01], and -[45] to nrsa[01] still makes
about the most sense.

Unless you intend to revive pax' tar personality under FreeBSD
(which would suggest merging in OpenBSD's changes), I'd say just
leave it.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Undocumented tape devices in pax(1)

[Christian Weisgerber]

Mike Smith [EMAIL PROTECTED] wrote:

 The 'r' prefix for tape devices is entirely unrelated to the 'r' prefix 
 for disk devices.

I'd like to see some backup for this assertion. Historically, BSD
(up to 4.4) used to have

mt  block device, rewinding
   nmt  block device, non-rewinding
   rmt  character device, rewinding
  nrmt  character device, non-rewinding

which leaves little room to doubt.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Undocumented tape devices in pax(1)

[Christian Weisgerber]

Greg Lehey [EMAIL PROTECTED] wrote:

 I suspect that's an assumption on your part.  I think we've come up
 with enough man pages to support naddy's statement.

Which, btw, was drawn from inspection of MAKEDEV in the various
4.xBSD releases in the CSRG archives (Kirk's CD set). Personally,
I take that as an authoritative source.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gcc -Os optimisation broken (RELENG_4)

[Christian Weisgerber]

Doug Barton [EMAIL PROTECTED] wrote:

   Hmm... If I have a PII (Actually celeron 300A) or a PIII, which is
 better, 'pentium' or 'pentiumpro'? I would think the latter, but I've

I have to admit that I kind of lost track of Intel's Pentium du
jour offerings after the PPro, but I think PII and PIII use i686
cores or at least something closest to i686, so I'd use -mpentiumpro
there. I don't pretend to have any idea what's appropriate for the
various AMD/Cyrix/IDT/etc processors.

The machines where I use -mpentium and -mpentiumpro, respectively,
are an actual Intel Pentium and a (dual) Intel Pentium Pro. Yes,
there are people out there who don't buy a new machine each quarter.

   Also, I have heard conflicting reports as to whether compiling the
 kernel/world with optimisations is a good thing. Anyone care to (re)open
 that can of worms?

No new worms in there, I suspect.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gcc -Os optimisation broken (RELENG_4)

[Christian Weisgerber]

David O'Brien [EMAIL PROTECTED] wrote:

 What???  'pentiumpro' code isn't going to be very optimized for a Pentium
 (if it even runs at all).

According to the gcc(1) man page, -mpentiumpro is synonymous to
-mcpu=pentiumpro, which only affects instruction scheduling but
not the actual instruction set used (for that, use -march=...).
So it certainly should run.

If you are aware that the man page is wrong in this respect, please
tell us!

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gcc -Os optimisation broken (RELENG_4)

[Christian Weisgerber]

Maxim Sobolev [EMAIL PROTECTED] wrote:

 I've just upgraded my production server to the 4.0-RELEASE and found that
 squid23 when compiled with -Os option dying with signal 11 on each attempt to
 load page. When I recompiled it with -O fault disappeared.

Which brings us back to the popular topic of which optimization
levels are reliable.

Building 5.0-CURRENT with "-Os -mpentium" failed for me with gas
complaining (unknown opcode I think, but don't hold me to it). I
went back to "-O -mpentium" and that worked fine. On another machine,
"-O2 -mpentiumpro" worked, too.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ssh strangeness in -current...

[Christian Weisgerber]

Sheldon Hearn [EMAIL PROTECTED] wrote:

 What about the off-by-one hostkey length problem?

The client gives a warning when you connect to an old server with
this problem.

 Is it supposed to be possible to drop a "1024-bit" host key from
 the old ssh1 port into /etc/ssh ?

I have switched several hosts from Ylonen-SSH to OpenSSH and have
retained all host keys.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: openssl in -current

[Christian Weisgerber]

David O'Brien [EMAIL PROTECTED] wrote:

 How does OpenBSD deal with it?  Why is it so easy for them?

0. RSA situation

In the USA, the RSA algorithm(!) is patented by RSA Inc. It doesn't
matter where the actual code is from, any use of RSA needs permission
by the patent holder. RSA Inc. provides a reference implentation
(RSAREF), which is free for private/educational/whatever use. Other
implementations are not covered by this license, i.e. their use
infringes on the patent. Commercial users need to get an explicit
license from RSA Inc., which from what I hear you can't get in
practice.

The American RSA patent does not affect the rest of the world, which
can freely use the algorithm in whatever implementation.

In short again:
- USA, non-commercial: must use RSAREF
- USA, commercial: no RSA
- international: free RSA


1. Installation

As distributed on CD/FTP, OpenBSD ships with a shared libcrypto in
/usr/lib that doesn't contain RSA. It has some stubs that will
abort the program with an error message, if it tries to call the
RSA routines. In order to provide RSA, the user needs to install
an additional package from the net. This exists in two versions,
the international one containing OpenSSL's own RSA implementation,
and the USA one with RSAREF. This package installs a new libcrypto
in /usr/local/lib. The RSA-enabled shared library has a higher
version number, so on program start-up it will be picked up in
preference to the non-RSA one. (This whole setup collapses for
those architectures that don't support shared libraries, but I
don't think I need to get into this now as it doesn't concern
FreeBSD.)

In short again:
- no RSA out of the box
- must add international or USA package with RSA after installation


2. Source

OpenSSL is integrated into the OpenBSD source tree. However, the
RSA routines are missing and are not in the CVS repository. A
separate source package--again in international and USA versions--is
available by FTP. This can simply be dropped at the appropriate
place into the OpenBSD source tree and will be automatically picked
up by a world build to produce an RSA-enabled libcrypto. Otherwise
a non-RSA library will be built.

In short again:
- no RSA in OpenBSD repository
- source available as drop-in external package


3. Commentary

The OpenBSD solution is not all that easy. However, it is not that
difficult from a user's perspective either. The install script
(OpenBSD uses a comprehensive shell script in place of sysinstall)
asks the user whether to install the RSA-enabled libraries and as
an alternative points to ssl(8) for information on how to do this
later.

If we want to have OpenSSL in the base system, we necessarily will
need to use an approach similar to the OpenBSD one.

I would like to point out that OpenBSD has made it a major advocacy
point that they ship with OpenSSL and OpenSSH out of the box, nicely
omitting the fact that you need to install a separate package off
the net to actually make it work. However, the favorable user
comments/reviews I see seem to suggest that people very much like
the OpenBSD approach. Again and again it is mentioned that contrary
to other operating systems OpenBSD ships with encryption out of
the box, that you don't need to install additional ports or packages,
and the additional install step either isn't even mentioned or only
in passing, with a remark how easy this is.

There's also the argument that OpenBSD is optimally prepared for
the running out of the RSA patent at the end of the year.

Now, I'm the first to agree that OpenBSD's OpenSSL integration
doesn't buy all that much. Users seem to disagree though. It's a
perception thing, I guess.

Of course, if you want to actually integrate OpenSSL-using software
into the base system (OpenBSD has OpenSSH and Apache), then you
obviously also need to have OpenSSL or at least a stub for it in
the base system.


FWIW, I support Kris' push to put OpenSSL in the base system.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: openssl in -current

[Christian Weisgerber]

David O'Brien [EMAIL PROTECTED] wrote:

 While I don't know is how OpenBSD builds the two sets of bits,  I do know
 how easy it was for me as a user to install 2.6 and get a RSA enabled
 crypto lib.

Alas, if I understand Jordan correctly, he objects exactly to this
additional installation step (adding a ssl package) as being too
difficult.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: openssl in -current

[Christian Weisgerber]

Jeffrey J. Mountin [EMAIL PROTECTED] wrote:

 My big question is - Do we really want to force a 'make world' on the those
 that want RSA support in openssl?

We don't want to and WE DON'T DO.

 That would be ugly, when before it was simply the matter of building only
 two ports.

binary installation:
- before: user needs to install openssl port
- now:user needs to install openssl package

make world:
- before: user needs to install openssl port
- now:openssl is built as part of the world

This thread suffers from people yelling objection without even
understanding the situation.

There are a few teething problems which are blown up way out of
proportion:

- Some people outside the US get their crypto source from a US
  mirror. They shouldn't do this in the first place. In the presence
  of USA_RESIDENT=NO, OpenSSL than proceeds to build without RSA.

- Apparently, there currently is a bug where bsd.port.mk fails to
  recognize that the RSA-enabled package hasn't been installed.
  I'm sure this can easily be fixed, but tying up Kris in endless
  discussions here won't accelerate the process.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

/usr/src/Makefile.inc1: make update

[Christian Weisgerber]

Why does "make update" in /usr/src also include a cvsup of /usr/ports?

Since /usr/ports and /usr/docs have Makefiles and "update" targets
of their own, and the alternative update by cvs doesn't cover
/usr/ports either, I suggest to remove the /usr/ports cvsup from
Makefile.inc1's "update" target.

--- /usr/src/Makefile.inc1  Sun Feb  6 14:24:17 2000
+++ Makefile.inc1   Mon Feb  7 22:15:20 2000
@@ -416,9 +416,6 @@
 .if defined(SUPFILE2)
@${SUP} ${SUPFLAGS} ${SUPFILE2}
 .endif
-.if defined(PORTSSUPFILE)
-   @${SUP} ${SUPFLAGS} ${PORTSSUPFILE}
-.endif
 .endif
 .if defined(CVS_UPDATE)
@echo "--"
-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: /usr/src/Makefile.inc1: make update

[Christian Weisgerber]

Bill Fumerola [EMAIL PROTECTED] wrote:

 As the person who implemented PORTSSUPFILE, I'd object. Originally
 SUPFILE2 was set to the ports-supfile, so to preserve original
 behavior (that is, updating ports along with src/) that stayed in.

Very well.

 To some of us, updating both at the same time is rather convinient as well.

And to some of us it isn't. If you want to be consequential, add
/usr/doc as well, and extend this to updates by CVS, too.

The current behavior is this:

"make update" in

|   /usr/src|   /usr/ports  |   /usr/doc
updates:|   |   |   
|  CVS  : CVSup |  CVS  : CVSup |  CVS  : CVSup
+---+---+---
/usr/src|   X   :   X   |   :   |   :
/usr/ports  |   :   X   |   X   :   X   |   :
/usr/doc|   :   |   :   |   X   :   X

One 'X' sticks out like a sore thumb.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: So, tell me again why we can't read audio CDs in SCSI drives?

[Christian Weisgerber]

Jordan K. Hubbard [EMAIL PROTECTED] wrote:

 Any other SCSI CD owners here currently using tosha?  I'd be
 quite interested to know if this is drive-specific.

Works for me.
4.0-CURRENT from December 19,
Toshiba CD-ROM XM-3601TA 0175,
tosha-0.6.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: OpenSSL update

[Christian Weisgerber]

Kris Kennaway [EMAIL PROTECTED] wrote:

 I have it building fine, although compiling without RSA seems
 broken in openssl 0.9.4.

Well, it works fine in the OpenBSD tree. You might want to take a
look at what's been done there.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Netscape core dump, happily :-)

[Christian Weisgerber]

Gianmarco Giovannelli [EMAIL PROTECTED] wrote:

 Is there anyone who is experienced Netscape crashes with 4.0-CURRENT when 
 the close button is pressed (not always, but very often) ?

Same here. Navigator 4.61. Previous versions didn't show this behavior.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Netscape core dump, happily :-)

[Christian Weisgerber]

Chris Piazza [EMAIL PROTECTED] wrote:

 Disable Javascript and the problem will go away (ugh).

I have JavaScript disabled by default. Still, navigator frequently
crashes on close or (I couldn't care less) exit.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ES1370 Sound problems

[Christian Weisgerber]

Joe Clarke jcla...@cisco.com wrote:

 I currently re-added my es1370-based Ensoniq soundcard to my FreeBSD 3.2
 system with the hope of getting Luigi's sound driver working with it.
 
 es1: AudioPCI ES1370 rev 0x00 int a irq 10 on pci0.15.0
  ^^^
 pcm1: using I/O space register mapping at 0x1800

At least with 4.0-CURRENT that's a problem. You need to patch
sys/pci/es1370.c, ca. line 150, in struct es_pci_driver. Replace es
by pcm. I then get

pcm0: AudioPCI ES1370 irq 15 at device 9.0 on pci0
pcm0: using I/O space register mapping at 0xe400

on boot-up, and the card is made available correctly.

 Trying to play an mp3 with mpg123, I get the following:
 
 Can't reset audio!
 Can't reset audio!

I get these too, but they don't seem to have any effect. mpg123 works
fine.

-- 
Christian naddy Weisgerber  na...@mips.rhein-neckar.de
carpe librum: books 'n' reviews URL:http://www.carpe.com/buch/



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: buildworld failure as of 1999-03-08

[Christian Weisgerber]

Hmm, must have been a gremlin. cvsup'ed again yesterday (didn't look
like anything related to the problem had changed), did another
buildworld, and this time it worked.

Oh, well.

-- 
Christian naddy Weisgerber  na...@mips.rhein-neckar.de
  H Deutsche Transhumanismus-Mailingliste
echo 'subscribe trans-de' | mail majord...@lists.rhein-neckar.de



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

buildworld failure as of 1999-03-08

[Christian Weisgerber]

I cvsup'ed the latest source yesterday evening/this morning and started
a make buildworld.

=== gnu/usr.bin/perl/perl
...
Writing Makefile for Fcntl
mkdir /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/Fcntl
mkdir /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/Fcntl/auto
mkdir /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/Fcntl/auto/Fcntl
cd ext/Fcntl; make -B all
PERL_SRC=/usr/obj/usr/src/gnu/usr.bin/perl/perl
cp Fcntl.pm /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/Fcntl/Fcntl.pm
/usr/obj/usr/src/gnu/usr.bin/perl/perl/perl
-I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib
-I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib
/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/ExtUtils/xsubpp -noprototypes
-typemap /usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/ExtUtils/typemap
Fcntl.xs Fcntl.tc  mv Fcntl.tc Fcntl.c
cc -c -DVERSION=\1.03\ -DXS_VERSION=\1.03\ -DPIC -fpic
-I/usr/obj/usr/src/gnu/usr.bin/perl/perl  Fcntl.c
In file included from
/usr/obj/usr/src/gnu/usr.bin/perl/perl/perl.h:1268,
 from Fcntl.xs:2:
/usr/obj/usr/src/gnu/usr.bin/perl/perl/scope.h:165: unterminated string
or character constant
/usr/obj/usr/src/gnu/usr.bin/perl/perl/scope.h:49: possible real start
of unterminated constant
/usr/obj/usr/src/gnu/usr.bin/perl/perl/scope.h:45: unterminated `#if'
conditional
*** Error code 1

I guess the immediate culprit is this:

/usr/obj/usr/src/gnu/usr.bin/perl/perl/scope.h:
| #ifdef DEBUGGING
| #define ENTER   \
| STMT_START {\
| push_scope();   \
| DEBUG_l(WITH_THR(deb(ENTERscope %ld at %s:%d\n,  \
 ^
| PL_scopestack_ix, __FILE__, __LINE__)));\
| } STMT_END
| #define LEAVE   \
| STMT_START {\
| DEBUG_l(WITH_THR(deb(LEAVE scope %ld at %s:%d\n,  \
| PL_scopestack_ix, __FILE__, __LINE__)));\
| pop_scope();\
| } STMT_END
| #else
| #define ENTER push_scope()
| #define LEAVE pop_scope()
| #endif

-- 
Christian naddy Weisgerber  na...@mips.rhein-neckar.de
  See another pointless homepage at URL:http://home.pages.de/~naddy/.



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: Current hangs when dump is run?

[Christian Weisgerber]

Taavi Talvik [EMAIL PROTECTED] wrote:

 Current seems to hangs, when amanda tries to run dump.
 This appeared approximately 2 weeks ago, and is present in
 yesterdays current also.

Not for me. I made the world yesterday, and this morning's backup
(with dump) ran fine.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message