Re: octave-forge on FreeBSD 7.0
On Mon, Nov 19, 2007 at 01:24:30PM +0900, Maho NAKATA wrote:
Dear portmgr@ and Stephen
Portmgr@:
Stephen Montgomery-Smith [EMAIL PROTECTED]
reported that applying following patch will unbreak
for FBSD7. Could you please approve my commit?
Index: Makefile
===
RCS file: /home/pcvs/ports/math/octave-forge/Makefile,v
retrieving revision 1.19
diff -u -r1.19 Makefile
--- Makefile1 Oct 2007 09:34:23 - 1.19
+++ Makefile19 Nov 2007 04:22:31 -
@@ -36,9 +36,7 @@
.include bsd.port.pre.mk
.if ${OSVERSION} = 700042
-.if ${ARCH} == amd64 || ${ARCH} == sparc64
-BROKEN=Does not compile with GCC 4.2
-.endif
+USE_GCC= 3.4
.endif
GNU_HOST= ${ARCH}-portbld-freebsd${OSREL}
cvs diff: Diffing files
Approved.
-erwin
pgp8Qebhv95fZ.pgp
Description: PGP signature
Re: ports modifying system setups
On 11/18/07, Edwin Groothuis [EMAIL PROTECTED] wrote:
On Sun, Nov 18, 2007 at 08:17:36PM -0500, Chuck Robey wrote:
activate the port, and if so, the port would add a line of the form
'portname_enable=YES', and this would make your new port operate.
Well, it seems from what I see of my new system, that this is no longer
the case. I could understand (and approve of) ports not being allowed
to modify any /etc/contents, but howcome ports can't use this rather
obvious workaround?
I don't recall this behavior at all, I think you're confused with
the messages which ports print at the end of the install-phase which
say Add 'foo_enable=YES' to your /etc/rc.conf to enable this
port.
Edwin is correct that ports never had this behavior when they were
converted to the rc_ng startup script style, they always required the
system administrator to set the appropriate rc variable in
/etc/rc.conf.
Before rc_ng some scripts would automatically start on a reboot, while
others required copying the *.sh{-dist,-default,...} startup script to
one without the extentsion, as well as setting the execute bit.
This is probably what you are remembering.
Scot
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Current unassigned ports problem reports
Current FreeBSD problem reports The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. Critical problems S Tracker Resp. Description f ports/117270[UPDATE] net/asterisk-addons to 1.4.4 1 problem total. Serious problems S Tracker Resp. Description o ports/106369vpnd caused kernel panic with ppp mode o ports/106372vpnd can't run with slip mode f ports/108077www/linux-flashplugin9 crashes linux-firefox f ports/108413net/vnc does not works. f ports/112385sysutils/lookupd on Kernel 64 f ports/112921x11-wm/Beryl not loading focus and keybinding settings f ports/113144print/ghostscript-gnu dumps core with several output d f ports/115818Executable clash between databases/grass and ruby gems f ports/116378xorg 7.3 on -stable breaks math/scilab f ports/116385net/vnc using vnc.so crashes Xorg 7.3 when remote comp f ports/116586net/isc-dhcp3-server does not work when compiled with o ports/116611devel/p5-gearmand - rename to devel/p5-Gearman-Server f ports/116753multimedia/MPlayer crashes after playing *.flv on 7.0- f ports/116777The math/scilab port fails in demos-signal-bode. f ports/116778security/nmap ping-scan misses some hosts f ports/116949security/vpnc: Some Cisco Concentrators refuse Connect o ports/117025multimedia/pwcbsd: Pwcbsd-1.4.0 + New USBStack not wor o ports/117119new port: emulators/dboxfe, a front-end to DosBox conf f ports/117128security/ipsec-tools racoon.sh fails with /var on mfs o ports/117144sysutils/nut : ACL with IPv6 address rejected o ports/117145[PATCH] math/dislin - update to 9.2 f ports/117196Port net/asterisk-addons 1.4.2 fails to compile f ports/117686print/fontforge : extract fails when building with NOP o ports/117689[update] games/ftjava o ports/117792new version of sysutils/Kgtk port o ports/117882mail/prayer needs update f ports/117886ports: net/nss_ldap 257 size mismatch from source PADL o ports/117942net/redir: fix core dump on redir f ports/117956HP LaserJet 1022 not working after upgrade to print/HP o ports/117985ftp/jftpgw: has incorrect startup script o ports/118031update net/smb4k to latest version o ports/118072update databases/slony1 to latest o ports/118077fix broken port: editors/nvi-devel broken since gcc-4. 33 problems total. Non-critical problems S Tracker Resp. Description f ports/101166bittorrent-curses only works under English locales. o ports/107354net/icmpinfo: icmpinfo -vvv does not recocnize any ICM a ports/107447[patch] devel/sdl12 - Add devel/directfb support f ports/107937jailed net/isc-dhcp3-server wouldn't run with an immut f ports/111399print/ghostscript-gpl: ghostscript-gpl WITH_FT_BRIDGE f ports/111456[UPDATE] finance/pfpro updated distinfo f ports/112887net/nxserver 1.4.0_1 fails to compile after upgrading f ports/113423Update for ports net/freenx to version 0.6.0 f ports/114127net/vnc - vnc.so installed to bad location f ports/114825pam module security/pam_abl not working s ports/115216ADA devel/florist exit_process program doesn't compile s ports/115217
Re: FreeBSD Port: pecl-APC-3.0.14
Ok. I'll update after ports freeze. Regards Oliver Schonrock wrote: Hi Hopefully a useful reminder... http://pecl.php.net/package/APC/3.0.15 has been out for a couple of months and contains significant bug fixes over 3.0.14. I have hacked the current port with the following: [EMAIL PROTECTED] diff -u distinfo distinfo.orig --- distinfoMon Nov 19 12:15:00 2007 +++ distinfo.orig Mon Nov 19 12:14:09 2007 @@ -1,3 +1,3 @@ -MD5 (PECL/APC-3.0.15.tgz) = fa15eac040221728f3aaeaf9595de6e1 -SHA256 (PECL/APC-3.0.15.tgz) = 1c475a84d12db2a45f1489a48f375d77854ae2c1d6626db3e812ccc04461911a -SIZE (PECL/APC-3.0.15.tgz) = 112056 +MD5 (PECL/APC-3.0.14.tgz) = 0f452f936239b6107d3e2e5cda4f4bda +SHA256 (PECL/APC-3.0.14.tgz) = f05195d163983a8f36336e622e6008bfecd4643d7c5613a6e4a8b07ed735e050 +SIZE (PECL/APC-3.0.14.tgz) = 108511 [EMAIL PROTECTED] diff -u Makefile Makefile.orig --- MakefileMon Nov 19 12:15:21 2007 +++ Makefile.orig Mon Nov 19 12:15:18 2007 @@ -6,7 +6,7 @@ # PORTNAME= APC -DISTVERSION= 3.0.15 +DISTVERSION= 3.0.14 CATEGORIES=www MASTER_SITES= http://pecl.php.net/get/ PKGNAMEPREFIX= pecl- and it seems to compile, install and run just fine on a heavily loaded production machine. If you could update the port, that would really help us roll this out. Thanks Oliver -- Marcus Alves Grando marcus(at)sbh.eng.br | Personal mnag(at)FreeBSD.org | FreeBSD.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Port: pecl-APC-3.0.14
Hi Hopefully a useful reminder... http://pecl.php.net/package/APC/3.0.15 has been out for a couple of months and contains significant bug fixes over 3.0.14. I have hacked the current port with the following: [EMAIL PROTECTED] diff -u distinfo distinfo.orig --- distinfoMon Nov 19 12:15:00 2007 +++ distinfo.orig Mon Nov 19 12:14:09 2007 @@ -1,3 +1,3 @@ -MD5 (PECL/APC-3.0.15.tgz) = fa15eac040221728f3aaeaf9595de6e1 -SHA256 (PECL/APC-3.0.15.tgz) = 1c475a84d12db2a45f1489a48f375d77854ae2c1d6626db3e812ccc04461911a -SIZE (PECL/APC-3.0.15.tgz) = 112056 +MD5 (PECL/APC-3.0.14.tgz) = 0f452f936239b6107d3e2e5cda4f4bda +SHA256 (PECL/APC-3.0.14.tgz) = f05195d163983a8f36336e622e6008bfecd4643d7c5613a6e4a8b07ed735e050 +SIZE (PECL/APC-3.0.14.tgz) = 108511 [EMAIL PROTECTED] diff -u Makefile Makefile.orig --- MakefileMon Nov 19 12:15:21 2007 +++ Makefile.orig Mon Nov 19 12:15:18 2007 @@ -6,7 +6,7 @@ # PORTNAME= APC -DISTVERSION= 3.0.15 +DISTVERSION= 3.0.14 CATEGORIES=www MASTER_SITES= http://pecl.php.net/get/ PKGNAMEPREFIX= pecl- and it seems to compile, install and run just fine on a heavily loaded production machine. If you could update the port, that would really help us roll this out. Thanks Oliver ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Here we go again: mplayer 1.0 rc2, please test
And another one, http://www.rrr.de/~riggs/mplayer/m20071119.tar.bz2 is mostly identical to yesterday's version, but contains Eugene's patch to enable AMR audio codec support. I believe we can send-pr this version unless nobody discovers showstoppers. Riggs ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Porting Linux Kernel modules to FreeBSD
Hi, Are there good documents/websites which discuss about porting kernel level software from Linux to FreeBSD ? On the other note, Linux has a type called wait_queue_head_t. How do I port this stuff on FreeBSD ? What is the equivalent ? -- Regards, Bubble ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Porting Linux Kernel modules to FreeBSD
2007/11/19, Bubble Reading [EMAIL PROTECTED]: Hi, Are there good documents/websites which discuss about porting kernel level software from Linux to FreeBSD ? On the other note, Linux has a type called wait_queue_head_t. How do I port this stuff on FreeBSD ? What is the equivalent ? There is a devel/linux-kmod-compat port which provides the base layer for multimedia/linux-ov511-kmod and multimedia/linux-gspca-kmod (both are webcam drivers). Maybe that helps. Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) It won't fit on the line. -- me, 2001 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Porting Linux Kernel modules to FreeBSD
Hi! Thanks. Any other ideas ? I could not get much help from that port as I am using FreeBSD v6.2.0. On 11/19/07, Rene Ladan [EMAIL PROTECTED] wrote: 2007/11/19, Bubble Reading [EMAIL PROTECTED]: Hi, Are there good documents/websites which discuss about porting kernel level software from Linux to FreeBSD ? On the other note, Linux has a type called wait_queue_head_t. How do I port this stuff on FreeBSD ? What is the equivalent ? There is a devel/linux-kmod-compat port which provides the base layer for multimedia/linux-ov511-kmod and multimedia/linux-gspca-kmod (both are webcam drivers). Maybe that helps. Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) It won't fit on the line. -- me, 2001 -- Regards, Bubble ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Porting Linux Kernel modules to FreeBSD
Bubble Reading wrote: Hi, Are there good documents/websites which discuss about porting kernel level software from Linux to FreeBSD ? This mailing list is about porting user-level applications, you might have better luck with the hackers@ and current@ mailing lists as they are both much more kernel-oriented. On the other note, Linux has a type called wait_queue_head_t. How do I port this stuff on FreeBSD ? What is the equivalent ? I don't know the Linux KPI but by the sound if it, some of these pointers might help you: http://www.freebsd.org/cgi/man.cgi?query=taskqueue http://www.freebsd.org/cgi/man.cgi?query=callout http://www.freebsd.org/cgi/man.cgi?query=queue signature.asc Description: OpenPGP digital signature
XING ağıma davet
Merhaba, Sizi XING çevreme davet etmek isterim! Kararlar sözkonusu olduğunda ilişkiler gittikçe daha çok önem kazanıyor. XING üzerinden ilişkileri güncel tutmak, geliştirmek ve onlardan yararlanmak çok kolay. İlişkilerim arasında sizi de görebilirsem memnun olurum. Candan selamlar MUSTAFA MESUT NEBİOĞLU --- MUSTAFA MESUT NEBİOĞLU sizi XING platformundaki ağına davet ediyor: http://www.xing.com/go/inv/13745620.e3f898 Artık XING davetiyesi almak istemiyorum: http://www.xing.com/go/opt_out_invite/U2FsdGVkX1-BpW59uwIFFcLiZ5plJ5nQMriJ_jHhECupTZtWJO5I3Q ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports modifying system setups
Naram Qashat wrote: Also a good thing to point out is that portupgrade can be configured to automatically start or stop a port's daemon via it's /usr/local/etc/rc.d script, which still relies on having the appropriate line in /etc/rc.conf to tell the rc.d script to run, but it is helpful for upgrading ports which have daemons so they can be shut down and then started again after the upgrade is complete. Not sure I understand what you mean here. I *think* I remember that ports (quoite a while back) did not require any patching of rc.conf at all, just coding in /usr/local/etc/rc.d. Nowadays, there are required lines in rc.conf which fire sections of rc.d, but apparently (and i do approve of this) the /etc/rc.conf can't be touched. I guess I don't understand why not have the entire startup code in rc.d, and merely have rc source in rc.d after it's finished with rc.conf. I just took a good long look at portupgrade, I didn't see any option like you're talking about. You understand, there is no reason that ports couldn't do what I'm asking about. They aren't written to do this (at least, several different daemon-ports that I've installed all required manual patching of rc.conf). This isn't just my own interpretation, because the ports themselves hint to the user that they should patch rc.conf to get the port working as a daemon. I'm just saying that ports should be written to handle this themselves, and not to require manual patching to get this done. One reason would be users (non-technical ones) who install a particular port as a dependency, and thus never even see the comments about what they should do to get things working. I can't see any reason NOT to do this, and good reason why it should be done. Naram Qashat Chuck Robey wrote: I was wondering why ports apparently aren't allowed an obvious freedom, that of being able to set themselves to run as daemons. A greate long time past, I seem to remember that there used to be a file /usr/local/etc/rc.local, which (if it existed) would be automatically sourced in at the end of rc.conf. Ports which built daemons were allowed (well, actually, expected) to ask the user if they wished to activate the port, and if so, the port would add a line of the form 'portname_enable=YES', and this would make your new port operate. Well, it seems from what I see of my new system, that this is no longer the case. I could understand (and approve of) ports not being allowed to modify any /etc/contents, but howcome ports can't use this rather obvious workaround? I'm pretty sure this used to be allowed... and it seems like a good policy to me, from the number of non-technical folks who now run FreeBSD. I just wanted to know why its not anymore. __ _ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports modifying system setups
In the pkgtools.conf file that portupgrade installs, there's two sections,
BEFOREINSTALL and AFTERINSTALL. In BEFOREINSTALL, you could put the following
in to make it try to stop the service if there's an rc script for the port:
'*' = proc { |origin| cmd_stop_rc(origin) }
And almost the same thing for AFTERINSTALL, except cmd_start_rc instead of
cmd_stop_rc. And as long as the line for that service is in /etc/rc.conf, it'll
start or stop via the rc script. It even says that in the comments of
pkgtools.conf.
Naram Qashat
Chuck Robey wrote:
Naram Qashat wrote:
Also a good thing to point out is that portupgrade can be configured
to automatically start or stop a port's daemon via it's
/usr/local/etc/rc.d script, which still relies on having the
appropriate line in /etc/rc.conf to tell the rc.d script to run, but
it is helpful for upgrading ports which have daemons so they can be
shut down and then started again after the upgrade is complete.
Not sure I understand what you mean here. I *think* I remember that
ports (quoite a while back) did not require any patching of rc.conf at
all, just coding in /usr/local/etc/rc.d. Nowadays, there are required
lines in rc.conf which fire sections of rc.d, but apparently (and i do
approve of this) the /etc/rc.conf can't be touched. I guess I don't
understand why not have the entire startup code in rc.d, and merely have
rc source in rc.d after it's finished with rc.conf.
I just took a good long look at portupgrade, I didn't see any option
like you're talking about. You understand, there is no reason that
ports couldn't do what I'm asking about. They aren't written to do this
(at least, several different daemon-ports that I've installed all
required manual patching of rc.conf). This isn't just my own
interpretation, because the ports themselves hint to the user that they
should patch rc.conf to get the port working as a daemon.
I'm just saying that ports should be written to handle this themselves,
and not to require manual patching to get this done. One reason would
be users (non-technical ones) who install a particular port as a
dependency, and thus never even see the comments about what they should
do to get things working. I can't see any reason NOT to do this, and
good reason why it should be done.
Naram Qashat
Chuck Robey wrote:
I was wondering why ports apparently aren't allowed an obvious
freedom, that of being able to set themselves to run as daemons. A
greate long time past, I seem to remember that there used to be a
file /usr/local/etc/rc.local, which (if it existed) would be
automatically sourced in at the end of rc.conf. Ports which built
daemons were allowed (well, actually, expected) to ask the user if
they wished to activate the port, and if so, the port would add a
line of the form 'portname_enable=YES', and this would make your
new port operate. Well, it seems from what I see of my new system,
that this is no longer the case. I could understand (and approve of)
ports not being allowed to modify any /etc/contents, but howcome
ports can't use this rather obvious workaround?
I'm pretty sure this used to be allowed... and it seems like a good
policy to me, from the number of non-technical folks who now run
FreeBSD. I just wanted to know why its not anymore.
__
_
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports modifying system setups
Edwin Groothuis wrote: On Sun, Nov 18, 2007 at 08:17:36PM -0500, Chuck Robey wrote: activate the port, and if so, the port would add a line of the form 'portname_enable=YES', and this would make your new port operate. Well, it seems from what I see of my new system, that this is no longer the case. I could understand (and approve of) ports not being allowed to modify any /etc/contents, but howcome ports can't use this rather obvious workaround? I don't recall this behaviour at all, I think you're confused with the messages which ports print at the end of the install-phase which say Add 'foo_enable=YES' to your /etc/rc.conf to enable this port. Edwin Hmm. I remember this behavioour, but I can't find any example of it now. I need to go look up into my old cdroms (they're around here somewheres, I just need to go unearth them, way back to 1.0). Until I can prove this, I guess I will withdraw it, but I do remember this behavior. Ports, a long time back, used to do all the install steps that they reasonably could do. Couldn't do all the setups for things like dovecot, which has too many options, but even there, an attempt was made to change the conf file to something closer to a FreeBSD standard. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports modifying system setups
Scot Hetzel wrote:
On 11/18/07, Edwin Groothuis [EMAIL PROTECTED] wrote:
On Sun, Nov 18, 2007 at 08:17:36PM -0500, Chuck Robey wrote:
activate the port, and if so, the port would add a line of the form
'portname_enable=YES', and this would make your new port operate.
Well, it seems from what I see of my new system, that this is no longer
the case. I could understand (and approve of) ports not being allowed
to modify any /etc/contents, but howcome ports can't use this rather
obvious workaround?
I don't recall this behavior at all, I think you're confused with
the messages which ports print at the end of the install-phase which
say Add 'foo_enable=YES' to your /etc/rc.conf to enable this
port.
Edwin is correct that ports never had this behavior when they were
converted to the rc_ng startup script style, they always required the
system administrator to set the appropriate rc variable in
/etc/rc.conf.
I remember the behavior, but not sure how far back it was. I was using
FreeBSD before rc_ng, so it could have been a _long_ time back.
Before rc_ng some scripts would automatically start on a reboot, while
others required copying the *.sh{-dist,-default,...} startup script to
one without the extentsion, as well as setting the execute bit.
This is probably what you are remembering.
Scot
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports modifying system setups
Naram Qashat wrote:
In the pkgtools.conf file that portupgrade installs, there's two
sections, BEFOREINSTALL and AFTERINSTALL. In BEFOREINSTALL, you could
put the following in to make it try to stop the service if there's an rc
script for the port:
'*' = proc { |origin| cmd_stop_rc(origin) }
And almost the same thing for AFTERINSTALL, except cmd_start_rc instead
of cmd_stop_rc. And as long as the line for that service is in
/etc/rc.conf, it'll start or stop via the rc script. It even says that
in the comments of pkgtools.conf.
Ah, you misunderstood me. I was never saying, or meaning, that ports
could not do it, I was saying they did not do it, no one I have seen
implemented that behavior. Yes, you're certainly right, they can,
they've had the ability all along.
Naram Qashat
Chuck Robey wrote:
Naram Qashat wrote:
Also a good thing to point out is that portupgrade can be configured
to automatically start or stop a port's daemon via it's
/usr/local/etc/rc.d script, which still relies on having the
appropriate line in /etc/rc.conf to tell the rc.d script to run, but
it is helpful for upgrading ports which have daemons so they can be
shut down and then started again after the upgrade is complete.
Not sure I understand what you mean here. I *think* I remember that
ports (quoite a while back) did not require any patching of rc.conf at
all, just coding in /usr/local/etc/rc.d. Nowadays, there are required
lines in rc.conf which fire sections of rc.d, but apparently (and i do
approve of this) the /etc/rc.conf can't be touched. I guess I don't
understand why not have the entire startup code in rc.d, and merely
have rc source in rc.d after it's finished with rc.conf.
I just took a good long look at portupgrade, I didn't see any option
like you're talking about. You understand, there is no reason that
ports couldn't do what I'm asking about. They aren't written to do
this (at least, several different daemon-ports that I've installed
all required manual patching of rc.conf). This isn't just my own
interpretation, because the ports themselves hint to the user that
they should patch rc.conf to get the port working as a daemon.
I'm just saying that ports should be written to handle this
themselves, and not to require manual patching to get this done. One
reason would be users (non-technical ones) who install a particular
port as a dependency, and thus never even see the comments about what
they should do to get things working. I can't see any reason NOT to
do this, and good reason why it should be done.
Naram Qashat
Chuck Robey wrote:
I was wondering why ports apparently aren't allowed an obvious
freedom, that of being able to set themselves to run as daemons. A
greate long time past, I seem to remember that there used to be a
file /usr/local/etc/rc.local, which (if it existed) would be
automatically sourced in at the end of rc.conf. Ports which built
daemons were allowed (well, actually, expected) to ask the user if
they wished to activate the port, and if so, the port would add a
line of the form 'portname_enable=YES', and this would make your
new port operate. Well, it seems from what I see of my new system,
that this is no longer the case. I could understand (and approve
of) ports not being allowed to modify any /etc/contents, but howcome
ports can't use this rather obvious workaround?
I'm pretty sure this used to be allowed... and it seems like a good
policy to me, from the number of non-technical folks who now run
FreeBSD. I just wanted to know why its not anymore.
__
_
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to
[EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Xephyr on freebsd...
Hello, I was wondering if there is a port (that I can't seem to find), or one in the making of Xephyr (Xnest next generation?). If not... has anyone tried and had any luck with grabbing the sources from git and building it? Care to comment on pitfalls? -- Regards, Eric signature.asc Description: OpenPGP digital signature
Package Building in the Large
I have been toying with a variety of package building methods lately. My latest effort involves looking into the Third Party Release Engineering documented here: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng-packages/index.html. Where do I start if I am looking for package building tools that the FreeBSD project uses for burning onto ROMs? Is ports/Tools/scripts/release the right place? The dates on the files there seem stale. What I am trying to do is to build 30 or so packages including the big ones like X, kde, gnome, plus all of their dependencies on a build host and then use pkg_add on various machines. I have had a variety of difficulties with all of the methods I have used thus far (portmaster, portupgrade, homegrown). Thanks, Jason C. Wells ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
who do I report this to?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Who do I report the following issue to (it falls into at least 3 camps)? If I am downloading a torrent in deluge 0.5.6.2_1 *AND* am logged into gmail (*WITH* a chat open) my network connection looses about 90% of it's capacity (for all applications), re(4) with the following: rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto After some experimenting this problem *only* occurs under the above conditions. Addtional info: gnome 2.20.1 nv driver (latest) Xorg 7.3 FreeBSD monster 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Thu Nov 15 19:17:50 EST 2007 [EMAIL PROTECTED]:/usr/obj/FreeBSD/FreeBSD-current/src/sys/MONSTER amd64 Buildworld done at the same time as buildkernelCopyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #1: Thu Nov 15 19:17:50 EST 2007 [EMAIL PROTECTED]:/usr/obj/FreeBSD/FreeBSD-current/src/sys/MONSTER Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz (3005.68-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6fb Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3fdSSE3,RSVD2,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2800SYSCALL,LM AMD Features2=0x1LAHF Cores per package: 2 usable memory = 4281409536 (4083 MB) avail memory = 4127895552 (3936 MB) ACPI APIC Table: 052107 APIC1013 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: 052107 RSDT1013 on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, dff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - 86, should be 79 [20070320] est0: Enhanced SpeedStep Frequency Control on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 92a092a0600092a device_attach: est0 attach returned 6 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 92a092a0600092a device_attach: est1 attach returned 6 p4tcc1: CPU Frequency Thermal Control on cpu1 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 uhci0: UHCI (generic) USB controller port 0xcc00-0xcc1f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: UHCI (generic) USB controller port 0xc880-0xc89f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: UHCI (generic) USB controller on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xfcdffc00-0xfcdf irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: EHCI (generic) USB 2.0 controller on ehci0 usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb2 uhub2: 4 ports with 4 removable, self powered pcm0: Intel 82801I High Definition Audio Controller mem 0xfcdf8000-0xfcdfbfff irq 22 at device 27.0 on pci0 pcm0: [ITHREAD] pcib2: ACPI PCI-PCI bridge irq 17 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge irq 17 at device 28.4 on pci0 pci3: ACPI PCI bus on pcib3 atapci0: Marvell 88SX6121 SATA300 controller port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfceffc00-0xfcef irq 16 at device 0.0 on pci3 atapci0: [ITHREAD] ata2: ATA channel 0 on atapci0 ata2: [ITHREAD] pcib4: ACPI PCI-PCI bridge irq 16 at device 28.5 on pci0 pci4: ACPI PCI bus on pcib4 re0: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xe800-0xe8ff mem 0xfcfff000-0xfcff irq 17 at device 0.0 on pci4 re0: Using 2 MSI messages miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus0
Total Ports System Failure
All of a sudden, my entire ports system is out-of-whack. Trying to make/portupgrade anything fails. For example, here is the output of installing audio/faad: -- begin -- # portupgrade audio/faad --- Upgrading 'faad2-2.6,1' to 'faad2-2.6_1,1' (audio/faad) --- Building '/usr/ports/audio/faad' === Cleaning for faad2-2.6_1,1 === Extracting for faad2-2.6_1,1 = MD5 Checksum OK for faad2-2.6.tar.gz. = SHA256 Checksum OK for faad2-2.6.tar.gz. === Patching for faad2-2.6_1,1 === Converting DOS text files to UNIX text files === Applying FreeBSD patches for faad2-2.6_1,1 === faad2-2.6_1,1 depends on executable: gmake - found === faad2-2.6_1,1 depends on file: /usr/local/bin/automake-1.5 - found === faad2-2.6_1,1 depends on file: /usr/local/bin/autoconf-2.61 - found === faad2-2.6_1,1 depends on file: /usr/local/bin/libtool - found === Configuring for faad2-2.6_1,1 /bin/mkdir -p /usr/ports/audio/faad/work/faad2/plugins/bmp --- Backing up the old version --- Uninstalling the old version --- Deinstalling 'faad2-2.6,1' --- Preserving /usr/local/lib/libfaad.so.0 as /usr/local/lib/compat/pkg/libfaad.so.0 pkg_delete: package 'faad2-2.6,1' is required by these other packages and may not be deinstalled (but I'll delete it anyway): ffmpeg-2007.10.04_1 gnash-0.8.1 vlc-0.8.6.c_5,2 [Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 713 packages found (-1 +0) (...) done] --- Installing the new version via the port gmake: Makefile: No such file or directory gmake: *** No rule to make target `Makefile'. Stop. === Running ldconfig /sbin/ldconfig -m /usr/local/lib *** Error code 2 === Registering installation for faad2-2.6_1,1 pkg_create: pkg_perform: unable to open contents file '/usr/ports/audio/faad/work/.PLIST.mktmp' for input *** Error code 2 2 errors *** Error code 2 1 error ** Command failed [exit code 2]: /usr/bin/script -qa /tmp/portupgrade.9286.0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=faad2-2.6,1 UPGRADE_PORT_VER=2.6,1 make reinstall --- Restoring the old version pkg_add: package faad2-2.6_1,1 has no origin recorded ** Fix the installation problem and try again. [Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 715 packages found (-0 +2) .. done] ** Listing the failed packages (*:skipped / !:failed) ! audio/faad (faad2-2.6,1) (install error) --- Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed ** Could not clean up temporary directory: Directory not empty - /var/tmp/portupgradee4EOJEQa -- end -- And here is for archivers/arj: -- start -- # portinstall arj [Gathering depends for archivers/arj . done] --- Installing 'arj-3.10.22_1' from a port (archivers/arj) --- Building '/usr/ports/archivers/arj' === Cleaning for arj-3.10.22_1 === Extracting for arj-3.10.22_1 = MD5 Checksum OK for arj-3.10.22.tar.gz. = SHA256 Checksum OK for arj-3.10.22.tar.gz. === Patching for arj-3.10.22_1 === arj-3.10.22_1 depends on executable: gmake - found === arj-3.10.22_1 depends on file: /usr/local/bin/autoconf-2.61 - found === Configuring for arj-3.10.22_1 --- Installing the new version via the port gmake: GNUmakefile: No such file or directory gmake: *** No rule to make target `GNUmakefile'. Stop. cd /usr/ports/archivers/arj/work/arj-3.10.22/doc install -o root -g wheel -m 444 COPYING debug.txt /usr/local/share/doc/arj *** Error code 2 cd /usr/ports/archivers/arj/work/arj-3.10.22/resource/en install -o root -g wheel -m 444 arjl.txt arjs.txt history.txt readme.txt unix.txt /usr/local/share/doc/arj 1 error *** Error code 2 1 error ** Command failed [exit code 2]: /usr/bin/script -qa /tmp/portinstall.6164.0 env make reinstall ** Fix the installation problem and try again. ** Listing the failed packages (*:skipped / !:failed) ! archivers/arj (install error) --- Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed -- end -- It seems like I have to go into the port directory and do make do-configure, etc. manually. In addition, trying to upgrade jdk results in Do you agree to the above license terms? [yes or no] being written over and over. Plus, in doing a make config, the dialog box on the blue background is set in the top-left corner, non-functions (keypresses show up a cyan text beneath it in a black row), and has to be interrupted with ^C. I though I might've added something to /etc/make.conf to cause this, but removing that file had no effect. The only out-of-the-ordinary thing that happend was a power failure in the middle of upgrading a bunch of ports a day or so ago. I was asleep so I don't know at what point. Seems like that was the point after which everything broke. The last portsnap I did was a few seconds ago. The uname is FreeBSD Pavilion 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #1: Mon Oct 29 14:34:26 PDT 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYSMP i386 ___ freebsd-ports@freebsd.org mailing list
