Fix for WINE on -CURRENT
Below is a patch to fix WINE for the new ATA driver.
I created this patch based on the ideals from a previous user
who had patched 3 other ports to work with -CURRENT's new ATA
driver.
Could someone familar with the new ATA driver have a look at this
patch to make sure it is correct.
Thanks,
Scot W. Hetzel
Index: Makefile
===
RCS file: /home/ncvs/ports/emulators/wine/Makefile,v
retrieving revision 1.152
diff -u -r1.152 Makefile
--- Makefile27 Oct 2003 06:16:28 - 1.152
+++ Makefile4 Nov 2003 04:20:37 -
@@ -36,8 +36,8 @@
BROKEN="Not supported on systems prior to FreeBSD 4.x"
.endif
-.if ${OSVERSION} >= 501106
-BROKEN="Broken by new ATA driver"
-.endif
-
.if defined(DEBUG)
Index: files/patch-dlls-ntdll-cdrom.c
===
RCS file: files/patch-dlls-ntdll-cdrom.c
diff -N files/patch-dlls-ntdll-cdrom.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ files/patch-dlls-ntdll-cdrom.c 4 Nov 2003 04:46:54 -
@@ -0,0 +1,59 @@
+--- dlls/ntdll/cdrom.c.origTue Oct 7 21:59:22 2003
dlls/ntdll/cdrom.c Mon Nov 3 22:46:11 2003
+@@ -65,8 +65,14 @@
+ #ifdef HAVE_LINUX_UCDROM_H
+ # include
+ #endif
++#ifdef HAVE_SYS_PARAM_H
++# include
++#endif
+ #ifdef HAVE_SYS_CDIO_H
+ # include
++#if __FreeBSD_version > 501105
++# include
++#endif
+ #endif
+ #ifdef HAVE_SYS_SCSIIO_H
+ # include
+@@ -1352,8 +1358,12 @@
+ }
+ #elif defined(__FreeBSD__)
+ {
++#if __FreeBSD_version < 501106
+ struct ioc_read_audio ira;
+-
++#else
++ int bsize = sectSize;
++ int begin;
++#endif
+ switch (raw->TrackMode)
+ {
+ case YellowMode2:
+@@ -1365,12 +1375,27 @@
+ case CDDA:
+ /* 2048 = 2 ** 11 */
+ if (raw->DiskOffset.s.HighPart & ~2047) FIXME("Unsupported value\n");
++#if __FreeBSD_version < 501106
+ ira.address.lba = ((raw->DiskOffset.s.LowPart >> 11) |
+ raw->DiskOffset.s.HighPart << (32 - 11)) - 1;
+ ira.address_format = CD_LBA_FORMAT;
+ ira.nframes = raw->SectorCount;
+ ira.buffer = buffer;
+ io = ioctl(cdrom_cache[dev].fd, CDIOCREADAUDIO, &ira);
++#else
++ if ((io = ioctl(cdrom_cache[dev].fd, CDRIOCSETBLOCKSIZE, &bsize)) == -1) {
++ return CDROM_GetStatusCode(io);
++ }
++ begin = ((raw->DiskOffset.s.LowPart >> 11) | raw->DiskOffset.s.HighPart <<
(32 - 11)) - 1;
++ io = pread(cdrom_cache[dev].fd, buffer, raw->SectorCount*bsize,
begin*bsize);
++ if (io == raw->SectorCount*bsize) {
++ io = 0;
++ } else if (io != -1) {
++ /* We retrieved < raw->SectorCount*bsize */
++ io = 0; /* change to -1, if we are required to return an error */
++ errno = ESPIPE;
++ }
++#endif
+ break;
+ }
+ }
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bug in NSS ?
From: "Scot W. Hetzel" <[EMAIL PROTECTED]> > From: "Alex Deiter" <[EMAIL PROTECTED]> > > >> I have a problem with nss_ldap on FreeBSD. > > >> After tranfer users from /etc/passwd to ldap directories my users > cannot > > >> send a mail via /usr/bin/mail | /usr/sbin/sendmail program: > > > > >What are the contents of the /usr/local/lib/sasl*/Sendmail.conf file? > > >Is pwcheck_method set to saslauthd, or sasldb? > > >If it is set to saslauthd, what flags do you use for it (-a pam or -a > > ldap)? > > > > my /usr/local/lib/sasl2/Sendmail.conf: > > pwcheck_method: auxprop > > auxprop_plugin: sasldb > > > Is the Sendmail.conf file the same as the FreeBSD file on the Solaris 8 > system? > Does sasldblistusers2 on the Solaris 8 system list the test user in the sasldb file? If it does, is their a test user in the FreeBSD sasldb file? > How is saslauthd started on both systems (-a pam, -a sasldb, -a ldap)? > Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bug in NSS ?
From: "Alex Deiter" <[EMAIL PROTECTED]> > >> I have a problem with nss_ldap on FreeBSD. > >> After tranfer users from /etc/passwd to ldap directories my users cannot > >> send a mail via /usr/bin/mail | /usr/sbin/sendmail program: > > >What are the contents of the /usr/local/lib/sasl*/Sendmail.conf file? > >Is pwcheck_method set to saslauthd, or sasldb? > >If it is set to saslauthd, what flags do you use for it (-a pam or -a > ldap)? > > my /usr/local/lib/sasl2/Sendmail.conf: > pwcheck_method: auxprop > auxprop_plugin: sasldb > Is the Sendmail.conf file the same as the FreeBSD file on the Solaris 8 system? How is saslauthd started on both systems (-a pam, -a sasldb, -a ldap)? Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bug in NSS ?
From: "Дейтер Александр Валерьевич" <[EMAIL PROTECTED]> > I have a problem with nss_ldap on FreeBSD. > After tranfer users from /etc/passwd to ldap directories my users cannot > send a mail via /usr/bin/mail | /usr/sbin/sendmail program: > : > Any ideas ? > What are the contents of the /usr/local/lib/sasl*/Sendmail.conf file? Is pwcheck_method set to saslauthd, or sasldb? If it is set to saslauthd, what flags do you use for it (-a pam or -a ldap)? Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Getting -pthread support back into local source tree
From: "Harald Schmalzbauer" <[EMAIL PROTECTED]>
> Scot W. Hetzel wrote:
> > From: "Dan Naumov" <[EMAIL PROTECTED]>
> >
> >>Seeing as -pthread support has been removed from -CURRENT breaking
> >>_LOTS_ of ports, is it possible to "get it back" into a local source
> >>tree ? If so, how ? Thanks in advance.
> >>
> >
> > All you need to do is add:
> >
> > CONFIGURE_ENV+=PTHREAD_LIBS=${PTHREAD_LIBS} \
> >
PTHREAD_CFLAGS=${PTHREAD_CFLAGS}
> >
> > To the port that is broken by having -pthread support removed, then
compile
> > the port.
> >
> > If it still fails to compile, then you'll need to add a sed command to
the
> > port that replaces -pthread with ${PTHREAD_LIBS} and -DTHREAD_SAFE with
> > ${PTHREAD_LIBS} in the configure script or the Makefiles.
>
> Well, that'd fit my skills, but what is for example with the jdk13? I
> have no idea how to fix this one.
>
Add the following to the post-patch target in the jdk13/Makefile:
@${REINPLACE_CMD} -s "s:-pthread:${PTHREAD_LIBS}:g"
${WRKSRC}/common/Defs.gmk
Scot
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Getting -pthread support back into local source tree
From: "Scot W. Hetzel" <[EMAIL PROTECTED]>
> From: "Dan Naumov" <[EMAIL PROTECTED]>
> > Seeing as -pthread support has been removed from -CURRENT breaking
> > _LOTS_ of ports, is it possible to "get it back" into a local source
> > tree ? If so, how ? Thanks in advance.
> >
> All you need to do is add:
>
> CONFIGURE_ENV+=PTHREAD_LIBS=${PTHREAD_LIBS} \
>
PTHREAD_CFLAGS=${PTHREAD_CFLAGS}
>
A better place for the above is to add it to bsd.port.mk where
PTHREAD_{CFLAGS,LIBS} are defined. With the attached patch.
Scot
pthread.patch
Description: Binary data
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Getting -pthread support back into local source tree
From: "Dan Naumov" <[EMAIL PROTECTED]>
> Seeing as -pthread support has been removed from -CURRENT breaking
> _LOTS_ of ports, is it possible to "get it back" into a local source
> tree ? If so, how ? Thanks in advance.
>
All you need to do is add:
CONFIGURE_ENV+=PTHREAD_LIBS=${PTHREAD_LIBS} \
PTHREAD_CFLAGS=${PTHREAD_CFLAGS}
To the port that is broken by having -pthread support removed, then compile
the port.
If it still fails to compile, then you'll need to add a sed command to the
port that replaces -pthread with ${PTHREAD_LIBS} and -DTHREAD_SAFE with
${PTHREAD_LIBS} in the configure script or the Makefiles.
After you have it working, send-pr your patch to gnats and the port
maintainer. This is the only way to get these problems fixed, if the port
maintainer doesn't have time to fix the port to work on -CURRENT.
Scot
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: -pthread deprecated, but when?
From: "Doug Barton" <[EMAIL PROTECTED]>
> On Tue, 9 Sep 2003, Matthias Andree wrote:
> > Doug Barton <[EMAIL PROTECTED]> writes:
> >
> > > @ ${CP} ${WRKSRC}/configure ${WRKSRC}/configure.Patched
> > > @ ${SED} -e 's#-lpthread#${PTHREAD_LIBS}#g' \
> >
> > How about: ${SED} -Ee 's#-l?pthread#${PTHREAD_LIBS}#g' \
> >
> > That's the one necessary to catch -pthread (such as BerkeleyDB) in
> > addition to -lpthread.
>
> You should use whatever is appropriate for your port... I just posted an
> example from one of mine.
>
Also look for PTHREAD_{LIBS/CFLAGS} in your ports configure script. Then
all you need to do is set CONFIGURE_ENV in the ports Makefile:
CONFIGURE_ENV+= PTHREAD_LIBS=${PTHREAD_LIBS} \
PTHREAD_CFLAGS=${PTHREAD_CFLAGS}
That's how I fixed the security/amavisd port in my ports tree.
Scot
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is there a "knob" for devfs rules?
From: "John Reynolds" <[EMAIL PROTECTED]> > Hi all, in debugging /dev/usb* and /dev/ugen* permissions problems so that I > could access my digital camera as a mere-mortal user, I came across this > posting to -questions: > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=1203173+1206388+/usr/local/www/db/text/2003/freebsd-questions/20030622.freebsd-questions > > Indeed what Jesse posted worked like a charm: > > devfs ruleset 10 > devfs rule add path 'ugen*' mode 664 > You would need to add the following to /etc/devfs.rules: [devfsrules_ugen=50] add path 'ugen*' mode 664 Then add to /etc/rc.conf: devfs_system_ruleset="devfsrules_ugen" Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Regarding recent spam on the list
From: "Brandon S. Allbery KF8NH" <[EMAIL PROTECTED]> > On Tue, 2003-08-19 at 18:03, Bill Moran wrote: > > Just curious if anyone knows the origin of all these auto-responses, etc. > > > > I'm seeing a lot of these on every list I'm subscribed to (not all of them > > FreeBSD related) so I was wondering if some Windows trojan is running rampant > > and using these list addresses as return addys? > > It's W32/[EMAIL PROTECTED] It's spreading *fast* > The first day it appeared, I received 8000+ virus and virus warning messages in my inbox. The only way I could stop it from filling my inbox was to change my e-mail address, and place a permanent failure code in the access table for the old address. But, our mail server was still getting a Denial of Service, since it would max out the connections to both our primary and secondary mail servers. Today I believe I have solved the problem. I wrote a couple of scripts, that retrieves the IP address from the maillog for all servers/virus infected systems that are using the old email address. Then I setup IPFW to deny access to port 25 for these IP addresses. So far IPFW is dening access to our mail servers for 30,000 Class C's (/24). Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: dynamic root support now in the tree
From: "Shin-ichi Yoshimoto" <[EMAIL PROTECTED]>
> Subject: Re: HEADS UP: dynamic root support now in the tree,
> On Mon, 18 Aug 2003 04:28:53 +0900, Shin-ichi Yoshimoto wrote:
> > Thanks Gordon. I can save a space :-)
>
> I found another problem in src/Makefile.inc
>
> [snip]
> .if ${TARGET_ARCH} == ${MACHINE_ARCH} && !defined(DISTDIR) && \
> (!defined(DESTDIR) || empty(DESTDIR) || ${DESTDIR} == "/")
> @echo "Checking to see if your booted kernel is fresh enough.."
> ${.OBJDIR}/bin/sh/sh -c \
> 'echo "Testing installed kernel for new sigaction(2)
> syscall"'
> @echo "Seems ok.."
> .endif
> [snip]
>
> ${.OBJDIR}/bin/sh/sh is dynamically-linked if WITH_DYNAMICROOT is
> defined. But sh cannot find /libexec/ld-elf.so.1 before instaling
> /libexec/ld-elf.so.1.
>
> Is this right ?
>
I stumbled accross this problem too. My solution was to copy
/usr/libexec/ld-elf.so.1 to /libexec and then try the "make installworld"
again. We're going to need a solution for those that are going from a
system (4.x, 5.0, 5.1) previous to the WITH_DYNAMIC_ROOT changes.
Scot
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: help! 5.1 doesn't want to start my nic :)
From: "Charlie Schluting" <[EMAIL PROTECTED]> > I ran /etc/rc.d/netif manually, and it said it couldn't find > /etc/network.subr, so I copied that over manually, rebooted, and the > interfaces still didn't start. But, if I run /etc/rc.d/netif manually, > it starts just fine now! Yes, the file has execute permissions for all. > > Anyone know what's up with that? Can anyone give me the rundown on > how/what FreeBSD does at boot time to start the network interface? Maybe > something is supposed to be running that script, but isn't? Another > missing script? > Upon boot up, FreeBSD runs the /etc/rc script. Check that you have the latest rc script by comparing it with the one in /usr/src/etc. diff -u /etc/rc /usr/src/etc/rc There should be no differences between these files. You should also have the following rc* files in the /etc directory: # ls /etc/rc* /etc/rc /etc/rc.firewall6 /etc/rc.sendmail /etc/rc.subr /etc/rc.conf/etc/rc.firewall/etc/rc.resume /etc/rc.shutdown/etc/rc.suspend Also the /etc/rc.d directory should contain 145 scripts. Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: help! 5.1 doesn't do the rc thing?
From: "Charlie Schluting" <[EMAIL PROTECTED]> > OMG. > I did it (the 5.1 update), and it went flawlessly until the reboot. > I read /usr/src/UPDATING! It said that the old rc system was going away, > but it would keep all your old files. > > So anyways, does anyone have a link to info about how the heck I start > stuff in 5.1? > > Most important: > -my lo0 interface doesn't have the 127.0.0.1 address.. it just comes up > with no addy. > -rc.conf didn't get run :( no named, no nothing :( > -my firewall rules (rc.firewall) and sysctl.conf didn't seem to be read. > > Links, hints appreciated. > Do you have an /etc/rc.d directory and is it populated with files? If not, then run run mergemaster to update your /etc. Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] jail NG schript patch for mounting devfs andprocfsautomatically
I just noticed a problem with periodic scripts inside a jail. I'm getting:
Local system status:
tee: /dev/stderr: Operation not supported
Mail in local queue:
tee: /dev/stderr: Operation not supported
Mail in submit queue:
tee: /dev/stderr: Operation not supported
in the periodic daily, weekly, monthly and security reports. But if I mount
the fdescfs on the jail, then these errors go away.
So we need to add the following to the new jail script
jail_start()
{
:
eval jail_devfs=\"\$jail_${_jail}_devfs\"
[ -z ${jail_devfs} ] && jail_devfs="NO":
eval jail_fdescfs=\"\$jail_${_jail}_fdescfs\"
[ -z ${jail_fdescfs} ] && jail_fdescfs="NO"
:
if checkyesno jail_devfs ; then
mount -t devfs dev ${jail_devdir}
if checkyesno jail_fdescfs ; then
mount -t fdescfs fdesc ${jail_devdir}/fd
fi
:
fi
:
}
jail_stop()
{
:
eval jail_devfs=\"\$jail_${_jail}_devfs\"
[ -z ${jail_devfs} ] && jail_devfs="NO":
eval jail_fdescfs=\"\$jail_${_jail}_fdescfs\"
[ -z ${jail_fdescfs} ] && jail_fdescfs="NO"
:
if checkyesno jail_devfs ; then
if [ -d ${jail_devdir} ] ; then
if checkyesno jail_fdescfs; then
umount -f ${jail_devdir}/fd >/dev/null 2>&1
fi
umount -f ${jail_devdir} >/dev/null 2>&1
fi
fi
:
}
The only decsion we need to make is wheter to always mount the fdescfs when
devfs is mounted on the jail, or have a variable to enable mounting of the
fdescfs (jail_*_fdescfs).
Scot
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: JAIL and SSH out?
From: <[EMAIL PROTECTED]> > Is there a way to ssh out from a jail? > > jail$ ssh otherhost > Permission denied, please try again. > Permission denied, please try again. > Permission denied (publickey,password). > jail$ ssh -V > OpenSSH_3.6.1p1 FreeBSD-20030423, SSH protocols 1.5/2.0, OpenSSL 0x0090701f > > jail$ mount > ... > devfs on /10.1.1.1/dev (devfs, local) > ... Yes, you can use ssh to access other systems from a jail. I currently have 4 jails runing on one host and can ssh from any of them. jail -> remote jail -> jailN jail -> host host -> jail remote -> jail Do you have sshd running on 'otherhost'? Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone use WINE at all anywhere?
From: "Julian Elischer" <[EMAIL PROTECTED]> > > Is the re ANYONE that uses wine on -current...? > > for that matter, a -current user that uses wine on 4.x? > I set up wine on current to run D2GS (Diablo II Game Server) using XVFB. I haven't used wine for any other purposes than this. Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] jail NG schript patch for mounting devfs andprocfsautomatically
Below is my current patch to devfs and jail to support the mounting of devfs
and procfs in jails. This patch also allows a jail to specify what devfs
rule to apply to the jail. As well as defining a default jail devfs rule
in /etc/rc.d/devfs.
Scot
Index: etc/defaults/rc.conf
===
RCS file: /home/ncvs/src/etc/defaults/rc.conf,v
retrieving revision 1.182
diff -u -r1.182 rc.conf
--- etc/defaults/rc.conf28 Jul 2003 13:09:00 - 1.182
+++ etc/defaults/rc.conf29 Jul 2003 22:06:08 -
@@ -426,12 +426,35 @@
harvest_ethernet="YES" # Entropy device harvests ethernet randomness
harvest_p_to_p="YES" # Entropy device harvests point-to-point randomness
dmesg_enable="YES" # Save dmesg(8) to /var/run/dmesg.boot
-jail_enable="NO" # Set to NO to disable starting of any jails
-jail_list="" # Space separated list of names of jails
-jail_set_hostname_allow="YES" # Allow root user in a jail to change its hostname
-jail_socket_unixiproute_only="YES" # Route only TCP/IP within a jail
-jail_sysvipc_allow="NO" # Allow SystemV IPC use from within a jail
watchdogd_enable="NO" # Start the software watchdog daemon
+
+##
+### Jail Configuration ###
+##
+devfs_jail_ruleset_enable="NO" # Enable Standard Jail devfs ruleset in
rc.d/devfs
+devfs_jail_ruleset_num="666" # Standard Jail ruleset number
+ # (change if it conflicts with your rulesets)
+
+jail_enable="NO" # Set to NO to disable starting of any jails
+jail_list="" # Space separated list of names of jails
+jail_set_hostname_allow="YES" # Allow root user in a jail to change its
hostname
+jail_socket_unixiproute_only="YES" # Route only TCP/IP within a jail
+jail_sysvipc_allow="NO"# Allow SystemV IPC use from within a
jail
+jail_default_ruleset="666" # Default jail devfs ruleset to apply
+jail_stop_jailer="NO" # Only stop jailer. Requires jail_*_exec be set
+ # to use sysutils/jailer port to start the
jail.
+
+# create an entry for each jail named in jail_list, with these variables
+#
+#jail_example_rootdir="/usr/jail/default" # Jails root directory
+#jail_example_hostname="default.domain.com"# Jails hostname
+#jail_example_ip="192.168.0.10"# Jails IP number
+#jail_example_exec="/bin/sh /etc/rc" # command to execute in jail
+#jail_example_devfs="NO" # mount devfs in jail
+#jail_example_devfs_ruleset="666" # devfs ruleset to apply to jail
+#jail_example_procfs="NO" # mount procfs in jail
+#
+# NOTE: replace 'example' with the jail's name from jail_list
##
### Define source_rc_confs, the mechanism used by /etc/rc.* ##
Index: etc/rc.d/devfs
===
RCS file: /home/ncvs/src/etc/rc.d/devfs,v
retrieving revision 1.5
diff -u -r1.5 devfs
--- etc/rc.d/devfs 6 May 2003 01:10:33 - 1.5
+++ etc/rc.d/devfs 6 May 2003 16:24:39 -
@@ -39,3 +39,21 @@
load_rc_config $name
run_rc_command "$1"
+
+# Standard Jail ruleset
+if checkyesno devfs_jail_ruleset_enable ; then
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} delset
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 100 hide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 200 path ptyp* unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 300 path ttyp* unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 400 path null unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 500 path zero unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 600 path random unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 610 path urandom unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 700 path fd unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 800 path fd/* unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 810 path mdctl unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 900 path stdin unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 910 path stdout unhide
+ /sbin/devfs rule -s ${devfs_jail_ruleset_num} add 920 path stderr unhide
+fi
Index: etc/rc.d/jail
===
RCS file: /home/ncvs/src/etc/rc.d/jail,v
retrieving revision 1.4
diff -u -r1.4 jail
--- etc/rc.d/jail 5 May 2003 15:38:41 - 1.4
+++ etc/rc.d/jail 21 Jun 2003 20:22:44 -
@@ -6,7 +6,7 @@
# PROVIDE: jail
# REQUIRE: LOGIN
Re: [PATCH] jail NG schript patch for mounting devfs andprocfsautomatically
From: "Mike Makonnen" <[EMAIL PROTECTED]> > On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote: > > >Someone, and unfortunately I appear to have lost track of who, had some > > >tweaks to the rcNG scripts to set up some reasonable devfs rules for a > > >jail, and apply them to the devfs mounted in a jail. Otherwise, you risk > > >exposing "undesired" device nodes to the virtual environment. I suspect a > > >search of the -current archives will turn up who, but I think a necessary > > >part of a solution here will be to make sure jails are set up with the > > >right devfs contents. > > > > Sorry, overseen. Sct W. Hetzel was the submitter, but it never becomes > > committed. If could be be so kind, please :-) (of course, not without > > prove it first) > > Yeah, I'll take care of this. I had asked scott to mail me his final > patch so I could commit it, but I never heard back from him. I'll > dig out the revisions from my mail archives and combine the > two. > I thought I had submitted my final patch, the only thing left was what number to use for the default jail devfs rule. We also need a way to load user defined devfs rules. I'll need to re-cvs diff my current devfs and jail scripts, before I'll be able to send them again. Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /etc/rc: WARNING: domainname(1) is not set.
From: "Tom Parquette" <[EMAIL PROTECTED]> > Hi, > I have been getting the message "/etc/rc: WARNING: domainname(1) is not > set" every time I boot one of my machines. > It is a 5.1-CURRENT system but I have not updated since June 15. > Do you have "hostname" set in /etc/rc.conf? Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: src/libexec/tcpd doesn't work correctly with -DPROCESS_OPTIONS
From: "Vincent Poy" <[EMAIL PROTECTED]> > Any ideas? > > According to the inetd man page: TCP Wrappers When given the -w option, inetd will wrap all services specified as ``stream nowait'' or ``dgram'' except for ``internal'' services. If the -W option is given, such ``internal'' services will be wrapped. If both options are given, wrapping for both internal and external services will be enabled. Either wrapping option will cause failed connections to be logged to the ``auth'' syslog facility. Adding the -l flag to the wrap- ping options will include successful connections in the logging to the ``auth'' facility. : When wrapping is enabled, the tcpd daemon is not required, as that func- tionality is builtin. . Also, /etc/defaults/rc.conf shows that inetd_flags has both '-w' and '-W' flags set. If you are using the default flags to inetd, then you don't need to use tcpd to wrap your telnetd session. Did you change your inetd_flags? I just tested the bultin tcp_wrappers in inetd, and had no problem with adding a banner to my ftpd and telnetd daemons without using the tcpd daemon. But, when I changed the service to: ftp stream tcp nowait root/usr/libexec/tcpd ftpd -l and then killed -HUP the inetd process, the inetd process wanted the banner file to be called 'tcpd' instead of 'ftpd'. I also killed inetd, and started it with no flags. But when I connected to the ftpd process, tcpd didn't display the banner (both tcpd and ftpd banner files were installed into the banner directory). So it looks like tcpd is broken when it comes to displaying banners. I suggest you use inetd's builtin TCP Wrappers support, and forget using tcpd. Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: src/libexec/tcpd doesn't work correctly with -DPROCESS_OPTIONS
From: "Scot W. Hetzel" <[EMAIL PROTECTED]> > You only enabled 1/3 of the source to use PROCESS_OPTIONS, you also need to > add the option to libwrap (lib/libwrap) and tcpdchk (src/usr.sbin/tcpdchk). > Small correction, the lib/libwrap/Makefile is setting PROCESS_OPTIONS in it's CFLAGS. The only other file that can use the PROCESS_OPTIONS setting is usr.sbin/tcpdchk. A grep for PROCESS_OPTIONS for libexec/tcpd (in contrib/tcp_wrappers) shows that tcpd.c doesn't use this option. Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: src/libexec/tcpd doesn't work correctly with -DPROCESS_OPTIONS
From: "Vincent Poy" <[EMAIL PROTECTED]> > In -CURRENT, /usr/src/libexec/tcpd, the Makefile doesn't have > -DPROCESS_OPTIONS needed which in hosts_access(5) manpage, allows things > such as banners for the tcp_wrappers to be working. > > So in the /usr/src/libexec/tcpd/Makefile, I added > -DPROCESS_OPTIONS > > CFLAGS+=-DREAL_DAEMON_DIR=\"/usr/libexec\" \ > -DSEVERITY=LOG_INFO -DRFC931_TIMEOUT=10 \ > -DHOSTS_DENY=\"/etc/hosts.deny\" > -DHOSTS_ALLOW=\"/etc/hosts.allow\" \ > -DFACILITY=LOG_DAEMON \ > -DPROCESS_OPTIONS > > However, the -DPROCESS_OPTIONS seems to have no effect after I > replaced the tcpd and restarted inetd. When one telnets, it just goes > to telnetd directly without going through the banners even though it > denies access to those not defined in /etc/hosts.allow: > You only enabled 1/3 of the source to use PROCESS_OPTIONS, you also need to add the option to libwrap (lib/libwrap) and tcpdchk (src/usr.sbin/tcpdchk). Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: p5-GD-1.41 wont build
From: "Christophe Zwecker" <[EMAIL PROTECTED]> > any clue whats going wrong here ? > One of the port-commiters updated the gd 1.x port to gd 2.0.15. This has been backed out as of 8 hours ago. Uninstall gd-2.0.15 and re-cvsup your ports collection. Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
BDECFLAGS being added to CFLAGS and CWARNFLAGS ( was Re: [solved]buildworld error)
From: "Munehiro Matsuda" <[EMAIL PROTECTED]>
> I was having the same compile error, until I commeted out the
> BDECFLAGS definition from /etc/make.conf.
>
> Looking into the problematic Makefiles, I've found that following
> Makefiles do references BDECFLAGS, which matches errors I was getting:
>
> usr.sbin/config/Makefile : CFLAGS+= ${BDECFLAGS}
> usr.sbin/lpr/Makefile.inc: CWARNFLAGS= ${BDECFLAGS}
> usr.sbin/kgzip/Makefile : CFLAGS+= ${BDECFLAGS}
>
> I think these references must be removed.
>
I did a find for BDECFLAGS and it found 5 Makefiles that are adding these
flags to either CFLAGS or CWARNFLAGS.
# cd /usr/src
# find . -type f -exec grep -H "BDECFLAGS" {} +
./sbin/ffsinfo/Makefile:#CFLAGS+=${BDECFLAGS}
./sbin/growfs/Makefile:#CFLAGS+=${BDECFLAGS}
:
./usr.sbin/config/Makefile:CFLAGS+= ${BDECFLAGS}
./usr.sbin/lpr/Makefile.inc:CWARNFLAGS= ${BDECFLAGS}
./usr.sbin/kgzip/Makefile:CFLAGS+= ${BDECFLAGS}
A couple of possible fixes are:
1. removal of BDECFLAGS from the above files
2. Add a .ifdef USE_BDECFLAGS .. .endif, that conditionalizes the use of
BDECFLAGS in the above files.
Scot
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /etc/hosts completely ignored
From: "Roberto Nunnari" <[EMAIL PROTECTED]> > -bash-2.05b# cat /etc/hosts > 127.0.0.1 localhost.noonlights.net localhost > 192.168.1.5 jupiter.noonlights.net jupiter > 192.168.1.5 jupiter.noonlights.net. > 193.5.56.6 www.freebsd.org myfreebsd > > note the wrong IP for www.freebsd.org!! just for testing purposes! > > -bash-2.05b# cat /etc/host.conf > hosts > bind > > > -bash-2.05b# host localhost > Host not found. > > -bash-2.05b# host localhost.noonlights.net > Host not found. > > See? /etc/hosts is completely ignored.. > > If I missed something, I'd be grateful if somebody could > let me know... for I'm new to /etc/nsswitch.conf.. but after > reading the manpage I have no clue left.. just an idea that > is a bug.. > I get the same results on 4-STABLE with the "host" command. Looking at the host man pages, it states host does the lookups using domain servers. host - look up host names using domain server Try ping, telnet, ftp, or ssh, as they should consult the hosts table before checking with a domain servers. Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Adduser difference between 5.0 and earlier versions
I noticed that adduser in 5.0, only allows you to add one user in interactive mode. The previous version of adduser would ask you if you wanted to add another user. Attached is a patch which puts this feature back into adduser. Scot Index: adduser.sh === RCS file: /home/ncvs/src/usr.sbin/adduser/adduser.sh,v retrieving revision 1.3 diff -u -r1.3 adduser.sh --- adduser.sh 3 Dec 2002 05:41:09 - 1.3 +++ adduser.sh 21 Jan 2003 22:35:39 - @@ -870,5 +870,22 @@ fi fi else - input_interactive + while : ; do + input_interactive + echo -n "Add another user? (yes/No): " + read _input + [ -z "$_input" ] && _input="No" + case $_input in + [Yy][Ee][Ss]|[Yy][Ee]|[Yy]) + continue + ;; + [Nn][Oo]|[Nn]) + echo "Goodbye!" + ;; + *) + continue + ;; + esac + break + done fi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel Panic in runq_check
I have a CURRENT system that is panicing on me every couple of days. I have enabled crash dumps in the rc.conf file, but when the system is rebooted, savecore doesn't find any core files on the swap partition. The system has 128M RAM installed, and the swap partion is ~512M. I am using a GENERIC kernel with SMP options enabled (see diff at bottom of message). Is there anything I need to add to the kernel config file to enable dumping of core files? Can I force a core dump when it panics? How? Current# ls /usr/obj/usr/src/srcC/sys/GENERIC-SMP/kernel* /usr/obj/usr/src/srcC/sys/GENERIC-SMP/kernel /usr/obj/usr/src/srcC/sys/GENERIC-SMP/kernel.debug The system was built from sources cvsuped on Dec 4th. I was trying to compile soureces cvsuped from yesterday when the panic occured. FreeBSD Current.westbend.net 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Thu Dec 5 19:11:47 CST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/srcC/sys/GENERIC-SMP i386 cpuid=0; lapic.id= instruction pointer = 0x8:0xc02f3d21 stack pointer = 0x10:0xc8678cdc frame pointer = 0x10:0xc8678cdc code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, Pres 1, def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 12 (idle: cpu 0) kernel: type 30 trap, code = 0 stopped at runq_check+0x21: cmpl $0x1, %eax nm -n /boot/kernel_smp/kernel | grep c02f3d c02f3d00 T runq_check c02f3d30 T runq_choose c02f3dc0 T runq_remove Current# grep dump /etc/rc.conf dumpdev="/dev/da0s1b" # Device name to crashdump to (or NO). dumpdir="/var/crash"# Directory where crash dumps are to be stored savecore_flags="" # Used if dumpdev is enabled above, and present. Current# df Filesystem1K-blocksUsed Avail Capacity Mounted on /dev/da0s1a 516062 121330 35344826% / devfs 1 1 0 100% /dev /dev/da0s1f 5160623232 471546 1% /tmp /dev/da0s1g 2310684 576178 154965227% /usr /dev/da0s1e 516062 123158 35162026% /var Current# disklabel -r /dev/da0s1 # /dev/da0s1: type: SCSI disk: da0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 553 sectors/unit: 924 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 104857604.2BSD 2048 1638489 # (Cyl.0 - 65*) b: 1048576 1048576 swap# (Cyl. 65*- 130*) c: 9240unused0 0 # (Cyl.0 - 553*) e: 1048576 20971524.2BSD 2048 1638489 # (Cyl. 130*- 195*) f: 1048576 31457284.2BSD 2048 1638489 # (Cyl. 195*- 261*) g: 4694620 41943044.2BSD 2048 1638489 # (Cyl. 261*- 553*) Current# dmesg Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Thu Dec 5 19:11:47 CST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/srcC/sys/GENERIC-SMP Preloaded elf kernel "/boot/kernel_smp/kernel" at 0xc067d000. Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P54C (200.46-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x3bf real memory = 134217728 (128 MB) avail memory = 123412480 (117 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 IOAPIC #0 intpin 17 -> irq 10 IOAPIC #0 intpin 18 -> irq 12 IOAPIC #0 intpin 19 -> irq 11 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Intel Pentium detected, installing workaround for F00F bug Initializing GEOMetry subsystem npx0: on motherboard npx0: INT 16 interface Using $PIR table, 6 entries at 0xc00fcdd0 pcib0: at pcibus 0 on motherboard pci0: on pcib0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 9.0 (no driver attached) fxp0: port 0xe400-0xe41f mem 0xd400-0xd40f,0xd410-0xd4100fff irq 12 at device 10.0 on pci0 fxp0: Ethernet address 00:a0:c9:85:b5:ed inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: port 0xe800-0xe8ff mem 0xd4101000-0xd4101fff irq 11 at device 12.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs orm0: at iomem 0xc8000-0xccfff,0xc-0xc7fff on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 irq 1 on at
Re: Upgrade of port audio/id3lib - stdc++ wchar support missing
From: "Kris Kennaway" <[EMAIL PROTECTED]> On Fri, Nov 08, 2002 at 09:54:11AM +0100, Jens Rehsack wrote: > David O'Brien wrote: > >On Thu, Nov 07, 2002 at 07:44:43PM +1100, Tim Robbins wrote: > > > >>You could try the patch I've attached: > >> > >>cd /usr/src > >>zcat c++-wchar.diff.gz | patch > >>cd gnu/lib/libstdc++ > >>make > >>make install > > > > > >Can you ask Kris to try this on the ports cluster before we commit it? > >I wonder how many ports this could break. > > Cause I'm the pain in the neck who asks for this - I'm rebuilding all my > ports today to check if it works with this patch (cvsup of /usr/src > yesterday). > Oops, the ports cluster is finally free to test this patch, but now I > can't seem to find it (only mails that refer to it) :-( Can someone > email it to me again? > Attached is the patch Scot c++-wchar.diff.gz Description: GNU Zip compressed data
RC_NG for local rc scripts
I was looking at how the RC_NG base scripts work, and decide to try changing
a few ports rc scripts to RC_NG. The process was simple enough to convert
the security/cyrus_sasl{,2} (pwcheck.sh, saslauthd{1,}.sh), mail/cyrus_imapd{,2}
(imapd.sh), net/openldap{,2} (slapd.sh) and databases/mysql323-{client,server}
(mysql-client.sh, mysql-server.sh) scripts to RC_NG.
One problem I found with in /etc/rc.subr is that load_rc_config can only get it's
configuration data from /etc/{default/,}rc.conf and /etc/rc.conf.d/*. While
local rc scripts should also be able to get their configuration data from
${prefix}/etc/rc.conf.d/*.
At a minimum a local rc script would be:
> cat example.sh
#!/bin/sh
#
# PROVIDE:
# REQUIRE:
# BEFORE: [start before service]
# KEYWORD: FreeBSD shutdown
#
# NOTE for FreeBSD 5.0+:
# If you want this script to start with the base rc scripts
# copy example.sh-sample to /etc/rc.d/example, otherwise
# copy example.sh-sample to example.sh.
prefix=%%PREFIX%%
if [ -f /etc/rc.subr ]; then
. /etc/rc.subr
name="example"
rcvar`set_rcvar`
command="${prefix}/sbin/${name}"
pidfile="/var/run/${name}.pid"
load_local_rc_config ${name}
run_rc_command ${name}
else
if [ -f ${prefix}/etc/rc.conf.d/${name} ]; then
. ${prefix}/etc/rc.conf.d/${name}
fi
: old startup script
fi
Attached is a patch to /etc/rc.subr, that provides the load_local_rc_config routine.
Ths routine loads the configuration data in the following order:
${prefix}/etc/rc.conf.d/*
/etc/default/rc.conf
/etc/rc.conf
/etc/rc.conf.d/*
This routine also checks the *_enable variable to see if it has been set, if not
then the routine will set it to YES. This is only for compatibilty with the old
local scripts. This check could be removed if compatiblity is not necessary.
Scot Hetzel
Index: rc.subr
===
RCS file: /home/ncvs/src/etc/rc.subr,v
retrieving revision 1.6
diff -u -r1.6 rc.subr
--- rc.subr 12 Sep 2002 17:27:36 - 1.6
+++ rc.subr 3 Oct 2002 18:44:50 -
@@ -833,6 +833,45 @@
}
#
+# load_local_rc_config
+# Source in the configuration file for a given local command.
+#
+# The following globals are used:
+#
+# NameNeeded Purpose
+# -- ---
+# prefix y Base directory that script is located in (i.e
+/usr/local)
+#
+# rcvar y Name of variable used to enable the service. If the
+enable
+# variable is unset, then set it to YES.
+#
+load_local_rc_config()
+{
+ _command=$1
+ if [ -z "$_command" ]; then
+ err 3 "USAGE: load_local_rc_config command"
+ fi
+
+ if [ -f ${prefix}/etc/rc.conf.d/"$_command" ]; then
+debug "Sourcing ${prefix}/etc/rc.conf.d/${_command}"
+. ${prefix}/etc/rc.conf.d/"$_command"
+fi
+
+ # Let either /etc/rc.conf or /etc/rc.conf.d/"$_command"
+ # override ${prefix}/etc/rc.conf.d/"$_command"
+ load_rc_config $_command
+
+ # Used for compatibilty with old behavior of local rc scripts.
+ if [ -n "$rcvar" ]; then
+ eval _value=\$${rcvar}
+ if [ -z "${_value}" ]; then
+ debug "load_local_rc_config: setting ${rcvar} to YES"
+ eval ${rcvar}=YES
+ fi
+ fi
+}
+
+#
# rc_usage commands
# Print a usage string for $0, with `commands' being a list of
# valid commands.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Junk in new gcc include path
From: "Garrett Wollman" <[EMAIL PROTECTED]>
> < said:
>
> > So why does adding "-I/usr/include" to CPPFLAGS cause the compiler to
ignore
> > the headers in /usr/include?
>
> It doesn't -- it just causes the compiler to emit a warning message
> which confuses AC_CHECK_HEADER in some versions of autoconf. (I think
> 2.52 doesn't have this problem, but 2.19 does. I haven't investigated
> this recently, though.)
>
I'll have to remove -I${OPENSSLINC} from the cyrus-sasl configure.in, so
that it will build on current.
Thanks,
Scot
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Junk in new gcc include path
From: "Andrey A. Chernov" <[EMAIL PROTECTED]>
> Does anybody else saw this too?
> I just run 'cc -v hello.c' (printing Hello, world) and see:
> ...
> GNU C version 3.1 [FreeBSD] 20020509 (prerelease)
> (i386-undermydesk-freebsd)
> compiled by GNU C version 2.95.4 20020320 [FreeBSD].
> ignoring nonexistent directory "NONE/include"
> ignoring duplicate directory "/usr/include"
> ...
>
> It seems junk "NONE/include" is in the include path and "/usr/include"
> present there twice. Please fix this thing. Especially if project have
> NONE directory...
>
I'm seeing the "ignoring duplicate directory" problem with the Cyrus-SASL
port when building on current. One of the patches (patch-ab) adds
"-I${OPENSSLINC} -I${OPENSSLINC}/openssl" to the CPPFLAGS. Then when
configure is run it fails to detect the unistd.h and pwd.h header files.
Which causes the compile to fail when building checkpw.c.
checking for getopt.h... no
checking for unistd.h... no
checking for crypt.h... no
checking for pwd.h... no
checking for shadow.h... no
checking for paths.h... no
Removing "-I${OPENSSLINC}" from patch-ab allows the port to find the system
include files in /usr/include.
checking for getopt.h... no
checking for unistd.h... yes
checking for crypt.h... no
checking for pwd.h... yes
checking for shadow.h... no
checking for paths.h... yes
So why does adding "-I/usr/include" to CPPFLAGS cause the compiler to ignore
the headers in /usr/include?
Scot
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Another possible solution for non-sendmail users
From: "Coleman Kane" <[EMAIL PROTECTED]> > Another thing to look at is the /usr/sbin/sendmail -> mailwrapper link that is > produced from installworld. In current it seems to have been linking that, even Stable creates the same links to mailwrapper. > when NO_SENDMAIL=yes in make.conf. Qmail et al. overwrite this with their own > workalike (since /usr/sbin/sendmail is a 'standard' these days) local mailer. > I dunno if -stable has this problem too. > You want to set NO_MAILWRAPPER in make.conf to prevent the linking to mailwrapper. But if you do this, you'll loose the configurablity that mailwrapper provides for alternate MTA's via /etc/mail/mailer.conf. Qmail install shouldn't need to install anything into /usr/[sbin,bin] directories with mailwrapper properly configured (see `man mailer.conf` & 'man mailwrapper'). Mailwrapper was designed so that you didn't need to re-create your links to your personal MTA (in /usr/[bin,sbin], when upgrading FreeBSD. Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Approach to integrate a driver into the kernel [winmodem]
From: "Brandon D. Valentine" <[EMAIL PROTECTED]> > On Thu, 11 Oct 2001, Benjamin Close wrote: > > I've now been using the FreeBSD winmodem driver (Available at: > >http://www.geocities.com/wtnbkysh/) under -current for a few weeks now > >and haven't noticed a single glitch. Whilst I know this is a port of a > >linux drivers and contains a binary only object from Lucent. Is there > >any chance of getting this as part of the FreeBSD kernel? There is a lot > >of people out in laptop land who would welcome this. > > I would think the license probably precludes it from inclusion. If you > want to push for commital you might do well to research a bit about how > Lucent licenses their WinModem driver under Linux, then find out if the > patches at that site you listed are BSD licensed. If your email > contains that info it probably has a better chance of getting attention. > > If the license on the kernel module is incompatible with the base > system, you might be able to get the hooks to support it committed to > FreeBSD and get the kernel modules made installable as a port. > /usr/local/modules anyone? =) > The kernel module has this copy right in it's ltmdmsio.c file: "Copyright (c) 1991 The Regents of the University of California." Upon doing a search for i56lvp578, I located a license for the ltmdmobj.o file (see ltmodem-6.00b4.tar.gz at http://www.heby.de/ltmodem): "Software sources and responsibilities. -- Agere Systems, Inc, (AS herein is a branch of Lucent Technologies, Inc.) AS provides the core Digital Signal Processor (DSP) code supporting the Mars/Apollo chipset used in the compatible modems. Diverse manufacturers incorporate the chips onto diverse modem cards, generally optimizing them for use under MS Windows. AS has NO responsibility for downstream modem functionality under Linux.!! Please do not annoy AS with support queries !! The List [EMAIL PROTECTED] is the only medium for the current support of these modems under Linux. Origins of the ltmodem-5.nn series kits enhancing upon the AS base are described in DOCs/CREDITS. These resources are used at your own risk." I didn't see any other licenses in the ltmodem-6.00b4.tar.gz archive. One of the other sites mentioned that the linux ltmodem driver was GPL'd, but they also complained about the non-availablility of the source for the ltmdmobj.o file, claiming that since the linux ltmodem driver is GPL'd that the ltmdmobj.o file is also and source code should be available for it. My best guess is that the ltmdmobj.o file is the DSP code from Agere Systems, and that Agere Systems holds the copyright on it. We would need verification from Agere Systems ([EMAIL PROTECTED] ?) before including the ltmdmobj.o file. Until the license is clarified, we could make a port for the FreeBSD ltmodem driver. Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: build problem ?
From: "Olivier Cortes" <[EMAIL PROTECTED]> > i cvsuped 20 minutes ago. > > when i try to build (-j 6), it says: > > > i couln't find the exact error point... i have a full make.out (make > -j 6 buildworld) at http://www.deep-ocean.net/~olive/files/make.out if > you want to look at it. > > i know broken builds are frequent under -CURRENT, but i couldn't > figure the source of this one. advises are welcome. > When you have a build failure using -j x (x > 1), you need to restart the build without -j in order to get any meaningful info from the build failure. Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: making sendmail with milter and sasl
From: "Leif Neland" <[EMAIL PROTECTED]> > Can I make make world make sendmail with milter and sasl / smtp auth just by > adding to make.conf? > > If so, how? > Currently, you need to a patch to enable the building and installing of libmilter, libsmutil, and the header files needed to build a Milter daemon. I just sent PR 23811 that contains the patch to enable Milter on both STABLE and CURRENT (minor fuzziness). http://www.freebsd.org/cgi/query-pr.cgi?pr=23811 So after applying the patch, add the following into your make.conf # See security/cyrus-sasl/files/Sendmail.README # SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL -D_FFR_UNSAFE_SASL SENDMAIL_LDFLAGS=-L/usr/local/lib SENDMAIL_LDADD=-lsasl #SENDMAIL_DPADD= # SENDMAIL_MILTER=yes I have also put this patch at: ftp://www.westbend.net/pub/sendmail/milter.patch When you build your milter daemons you can use either a shared (-lmilter) or a static (/usr/lib/libmilter.a) libmilter library. cc -I/usr/include/sendmail -o sample sample.c -lmilter /usr/lib/libsmutil.a -pthread After you build your milter daemons, you will need to create a shell script that will start/stop the milter daemons. This script needs to be placed in PREFIX/etc/rc.milter (see src/lib/libmilter/sample.sh). Scot W. Hetzel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rpc.lockd
From: "Roman Shterenzon" <[EMAIL PROTECTED]> > On Tue, 19 Sep 2000 [EMAIL PROTECTED] wrote: > > Yeah probably should...perhaps suggest it to -docs. Someone (from > > something.edu, perhaps rpi.edu) posted a URL to one of the lists of a > > working but untested rpc.lockd. You might like to try it...if it gets > > enough testing it should make it in for 4.2 (one hopes). > > > > Andrew > > > Thanks, I'm ready to give it a try, does anyone the URL? > I'll search the archives meanwhile. > (Was it ported from NetBSD?) > I kind of remember reading about it on the current mailing list. Current-Users: Has a working rpc.lockd been imported into CURRENT. If it has, is there a possibility of getting it MFC'd to STABLE. Thanks, Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Installkernel
From: "James Johnson" <[EMAIL PROTECTED]> > The method of building and installing a kernel to me seems a bit off.. Both > the buildworld and installworld targets default to GENERIC, yet GENERIC is a > file checked into the -CURRENT CVS repository.. Any changes to this file > will get blown away if whenever you update the sources unless you explicity Your supposed to copy GENERIC to a new name, and then build your kernel with that file. You can change the default kernel to build by specifying: KERNEL= MY-KERNEL in the /etc/make.conf file. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sendmail updated from 8.9.3 to 8.11.0 in -current
From: "Gregory Neil Shapiro" <[EMAIL PROTECTED]> > hetzels> Sendmail 8.11 has the ablity to due secure authentication with > hetzels> mail clients when compiled with Cyrus-SASL. > > hetzels> Will the Cyrus-SASL library be imported to provide this > hetzels> capability? Or at least a make.conf variable. > > My first step in the process was to get sendmail up-to-date. Once it is > MFC'ed to STABLE, I'll look at enhancements. After September 21, I want to > turn on STARTTLS support. I'm not sure about importing SASL -- I might be > convinced to put in Makefile support if it happens to already been > installed via ports. > Makefile support for SASL would be fine. Thanks for bringing in 8.11. Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FrontPage Extensions
From: "Phil Regnauld" <[EMAIL PROTECTED]> > Terry Lambert writes: > > For what it's worth, the FP security issues are very well documented > > by ReadyToRun Software's site (these are the folks who do the UNIX > > ports for Microsoft). > > > > They also keep both BSDI 2.1 and 3.0 binaries available, and they > > know about FreeBSD (it's mentioned in the FAQ as an unsupported > > platform; apparently someone was having problems with the MD5 > > password hashing. Someone who cares should send them mail on how > > to update their FAQ to be more correct, and to raise FreeBSD's > > visibility as a platform -- e.g. what versions to us4e for > > what, install instructions for FreeBSD, etc.). > > FWIW, they now have a native FreeBSD version (FP extensions > SR1, the port needs to be updated BTW) -- works like a charm with minor > changes to one of the port patches. > Yes, there is only a minor change that is needed to the port to get it working with FP 2K SR1. See PR 18581, PR 18788 I did find a problem with fpsrvadm.exe. If you have libcrypt linked to libscrypt, then fpsrvadm.exe creates an invalid MD5 password (I believe the buffer RTR used to hold the password returned from the crypt function is too small for the MD5 passwords). I have informed RTR and they said a fix would be available in the next release. For the time being the port (apache13-fp, or upcomming mod_frontpage) will still need to use the BSDI extentions, and statically compile the apache server with libdescrypt.a on systems where libcrypt is linked to libscrypt. > Caveat: if you misconfigure your VirtualHost in some way, any call > to the FP-patched Apache to that subweb's /_vti_bin/ will make it > (apache) segfault. > > Will debug this if I find time. > I haven't come across this problem. But I do know that it will segfault if you are not using a patched suexec, as the unpatched suexec will not allow fpexe to run. Scot PS. This is off topic for current, so please remove current when replying. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New 64 bit Compiler from SGI
From: "Amancio Hasty" <[EMAIL PROTECTED]> > For those interested , SGI has released their 64 bit > compiler for Intel's Itanium. > > http://oss.sgi.com/projects/Pro64/ > That great, now when does FreeBSD64 come out ;-) Is FreeBSD 64-bit clean as referred to in the below question from the SGI FAQ ( http://oss.sgi.com/projects/Pro64/faq.html )? Q. I have a C program that runs correctly on Linux/IA-32. When I compile it and run it in the NUE environment, I do not get correct answers. Any ideas? A. Is your program 64-bit clean? The Linux/IA-32 programming model uses an ILP32 model. That means that sizeof(int)==sizeof(long)==sizeof(void *) == 32 bits. The Linux/IA-64 programming model used a LP64 model. That means that sizeof(int)==32 bits and sizeof(long)==sizeof(void *)==64 bits. If your program violates the LP64 model you will have problems. This is why the version of gcc in SPEC95 will not work (nor will it ever without modification). Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FBSD4.0-RC3 install
From: "Jordan K. Hubbard" <[EMAIL PROTECTED]> > > This should work now - it just needed some symlinks to be created. > The link to the packages directory is wrong. It is pointing one to many directories back. packages -> ../../../../ports/i386/packages-4-current it should be: packages -> ../../../ports/i386/packages-4-current I also noticed one very small error on the screen for setting up the mouse. It says to choose option 4 to disable the mouse, it should be option 5. Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make.conf on CURRENT question
From: Jeroen Ruigrok/Asmodai <[EMAIL PROTECTED]> > compat22=yes in /etc/make.conf accomplishes a.out support which we need > for netscape support. Correct? > You will also need a.out libraries from XFree86 in order to get Netscape working. > What does compat3x do however? Provide ELF compatibility libraries for > programs written for 3.x? > Yes > Also. Suppose I have an ELF CURRENT box that never ran a.out. > If I want a.out support from a make world I would need to uncomment > compat22=yes in /etc/make.conf, correct in assuming this? > You'll also want to use: make world -DWANT_AOUT=YES to have the a.out libraries built. Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Possible fix for rc.conf
What does everyone think about using this at the end of
/etc/defaults/rc.conf?
for i in ${rc_conf_files}; do
if [ $0 != $i ]; then
if [ -f $i ]; then
. $i
fi
else
echo "Error: $0 isn't allowed to re-load $i."
echo "Error: Please do not copy /etc/defaults/rc.conf to
/etc/rc.conf"
fi
done
If someone does copy the /etc/defaults/rc.conf to /etc/rc.conf, /etc/rc.conf
will not reload it's self, thus it will never get stuck in an endless loop.
Scot
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: how to set the ne2000 pci network card in the config file
From: Chan Yiu Wah > I recently found that my pci network card didn't work for me any more. It > was recognized by the system but I could config it. This didn't happen before > and I didn't why. I had tried to config it as ed1 in my config file. > Then it was probed by the system as ed2 When I tried to config it as ed2 > in the config file. It was probed by the system as ed3. Can anyone tell me > how to solve it. Thanks.c > If you could show us how you were configuring ed[1,2] in your config file we would probably be able to help you. You possibly are using: device ed1 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr This sets up ed1 for a ed* ISA card. Thus when the system probe finds your card, it assigns it as ed2, since PCI devices are automatically assigned to the next ed* interface. You should change you config file so that the device line looks as follows: deviceed1 This will set it up so that the first ed* PCI card found is assigned to the ed1 interface. Scot To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: "make upgrade NOCONFIRM=YES" (Was: Re: Hate to ask, but...aout ->elf ... )
From: The Hermit Hacker > > make upgrade NOCONFIRM=YES > Your source tree must not be fully populated; unable to find upgrade > script > in /usr/src/release/scripts/doupgrade.sh. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > > Just connected to freefall and did a 'cvs checkout' of release, and the > file doesn't appear to exist there either, so it isn't an out of sync > cvsup or anything...*raised eyebrow* > I just read on the STABLE list that the doupgrade.sh file was moved to the tools directory. Scot To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
