ports: how to handle 'alternate' dependencies
I'm just learning the guts of how ports work, and wonder: How do ports specify that any one of X, Y, Z would satisfy a dependency. For instance, when I build graphics/jalbum, it says it requires jdk16. I would rather use diablo-jdk16, since I find it faster and it is easier to install. But how would I alter graphics/jalbum to say, essentially, either jdk16 or diablo-jdk16 is required Generally, how to handle the case when a port requires X, but there are multiple implementations of X that can perform the job, and any will suffice? I feel like this issue must come up from time to time, what is the right way to deal with it? I didn't see any mention of this in the porters handbook... Thanks -John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: ports: how to handle 'alternate' dependencies
On Fri, Sep 11, 2009 at 11:06 PM, John W jwde...@gmail.com wrote: I'm just learning the guts of how ports work, and wonder: How do ports specify that any one of X, Y, Z would satisfy a dependency. For instance, when I build graphics/jalbum, it says it requires jdk16. I would rather use diablo-jdk16, since I find it faster and it is easier to install. Whoops - in particular graphics/jalbum has the line: JAVA_VENDOR = bsdjava So it seems that special JAVA_XXX variables are used to solve the problem in this particular case. However, I would still like to know what (if any) general support there is for this kind of problem. -John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
configuring X on the Presario with the 8200M driver
Moving this discussion to freebsd-x11. I have a Presario CQ60 with the NVIDIA 8200M G, and X is working! Here are the steps to get there. Do everything as root: 1) Update your ports to the most recent. Follow the FreeBSD manual, section 4.5 Using the Ports Collection, nuke the contents of /usr/ports, and install a new base using portsnap or cvsup. 2) Install the nvidia-driver. # cd /usr/ports/x11-driver/nvidia-driver # make install clean (I built with options FREEBSD_AGP checked, ACPI checked, LINUX unchecked). 3) You can install 2 more optional tools for configuring the nvidia card settings. I have not used them, but I installed them. # cd /usr/ports/x11-driver/nvidia-settings # make install clean # cd /usr/ports/x11-driver/nvidia-xconfig # make install clean 4) I also installed the fbdev driver from X.Org. # cd /usr/ports/x11-drivers/xf86-video-fbdev # make install clean 5) Add the nvidia driver as a dynamically loaded kernel module. # cd /boot # vi loader.conf (you better know how to use vi to edit) --- add the line nvidia_load=YES --- it is the only line I have in my loader.conf file 6) Reboot the system # reboot 7) If you want to see the version you just installed (your versions may be newer than mine below)... # pkg_info | grep nvidia nvidia-driver-185.18.29 nvidia-settings-190.32 nvidia-xconfig-190.32 # pkg_info | grep fbdev xf86-video-fbdev-0.4.0_2 8) Generate your xorg.conf.new file. # cd /root # Xorg -configure 9) Edit the xorg.conf.new file. # vi xorg.conf.new --- change the lineDriver nv to readDriver nvidia 10) Test the config file. # Xorg -config xorg.conf -retro --- you should get a grey screen and your mouse should work, especially if your mouse worked when installing FreeBSD --- to kill the test, press CTRL-ALT-BKSP 11) If everything worked, move and rename (drop the new extension) the config file to the /etc directory # mv xorg.conf.new /etc/X11/xorg.conf 12) Test again. Log in as another user belonging to the wheel group (or login as root). % startx --- you should get 3 green windows --- you can kill X by clicking on the large window on the left, and typing exit ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: configuring X on the Presario with the 8200M driver
Step 10 should be # Xorg -config xorg.conf.new -retro -Original Message- From: Kenneth kennet...@earthlink.net Sent: Sep 12, 2009 2:12 AM To: freebsd-questions@freebsd.org, freebsd-...@freebsd.org Cc: jules.sto...@gmail.com, ges...@yahoo.com Subject: configuring X on the Presario with the 8200M driver Moving this discussion to freebsd-x11. I have a Presario CQ60 with the NVIDIA 8200M G, and X is working! Here are the steps to get there. Do everything as root: 1) Update your ports to the most recent. Follow the FreeBSD manual, section 4.5 Using the Ports Collection, nuke the contents of /usr/ports, and install a new base using portsnap or cvsup. 2) Install the nvidia-driver. # cd /usr/ports/x11-driver/nvidia-driver # make install clean (I built with options FREEBSD_AGP checked, ACPI checked, LINUX unchecked). 3) You can install 2 more optional tools for configuring the nvidia card settings. I have not used them, but I installed them. # cd /usr/ports/x11-driver/nvidia-settings # make install clean # cd /usr/ports/x11-driver/nvidia-xconfig # make install clean 4) I also installed the fbdev driver from X.Org. # cd /usr/ports/x11-drivers/xf86-video-fbdev # make install clean 5) Add the nvidia driver as a dynamically loaded kernel module. # cd /boot # vi loader.conf (you better know how to use vi to edit) --- add the line nvidia_load=YES --- it is the only line I have in my loader.conf file 6) Reboot the system # reboot 7) If you want to see the version you just installed (your versions may be newer than mine below)... # pkg_info | grep nvidia nvidia-driver-185.18.29 nvidia-settings-190.32 nvidia-xconfig-190.32 # pkg_info | grep fbdev xf86-video-fbdev-0.4.0_2 8) Generate your xorg.conf.new file. # cd /root # Xorg -configure 9) Edit the xorg.conf.new file. # vi xorg.conf.new --- change the lineDriver nv to readDriver nvidia 10) Test the config file. # Xorg -config xorg.conf -retro --- you should get a grey screen and your mouse should work, especially if your mouse worked when installing FreeBSD --- to kill the test, press CTRL-ALT-BKSP 11) If everything worked, move and rename (drop the new extension) the config file to the /etc directory # mv xorg.conf.new /etc/X11/xorg.conf 12) Test again. Log in as another user belonging to the wheel group (or login as root). % startx --- you should get 3 green windows --- you can kill X by clicking on the large window on the left, and typing exit ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: ports: how to handle 'alternate' dependencies
In the last episode (Sep 11), John W said:
I'm just learning the guts of how ports work, and wonder:
How do ports specify that any one of X, Y, Z would satisfy a dependency.
For instance, when I build graphics/jalbum, it says it requires jdk16.
I would rather use diablo-jdk16, since I find it faster and it is
easier to install.
But how would I alter graphics/jalbum to say, essentially, either
jdk16 or diablo-jdk16 is required
Generally, how to handle the case when a port requires X, but there are
multiple implementations of X that can perform the job, and any will
suffice? I feel like this issue must come up from time to time, what is
the right way to deal with it? I didn't see any mention of this in the
porters handbook...
This question might be better asked on the freebsd-ports mailing list...
In your specific case, since you're looking at a java port, you have to
follow the rules in /usr/ports/Mk/bsd.java.mk , which let you specify things
like:
USE_JAVA=YES
JAVA_VERSION=1.6
JAVA_VENDOR=freebsd bsdjava
, to force the use of only Java 1.6 (not 1.5 or 1.7), and only the
source-built or diablo-binary variants.
Many port groups that provide multiple versions of an application either
have special code in bsd.port.mk or have their own bsd.xxx.mk, and they
usually let the port maintainer set WANT_XXX or WITH_XXX variables to prefer
a particular version. See bsd.gecko.mk and bsd.database.mk for some complex
examples.
For the completely general case of two independant ports providing the same
feature your port needs, you can roll your own checks. To prefer the
playmusic port, but use the playwav port if it's already installed:
.if exists(${LOCALBASE}/bin/playwavfile)
RUN_DEPENDS+=playwav:${PORTSDIR}/audio/playwav
.else
RUN_DEPENDS+=playmusic:${PORTSDIR}/audio/playmusic
.endif
You can also get fancy and use OPTIONS to allow the user to pick their
preferred alternative ports, using .if exists checks to pre-select any
already-installed ones.
--
Dan Nelson
dnel...@allantgroup.com
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: ports: how to handle 'alternate' dependencies
John W wrote:
I'm just learning the guts of how ports work, and wonder:
How do ports specify that any one of X, Y, Z would satisfy a dependency.
For instance, when I build graphics/jalbum, it says it requires jdk16.
I would rather use diablo-jdk16, since I find it faster and it is
easier to install.
But how would I alter graphics/jalbum to say, essentially, either
jdk16 or diablo-jdk16 is required
Generally, how to handle the case when a port requires X, but there
are multiple implementations of X that can perform the job, and any
will suffice?
I feel like this issue must come up from time to time, what is the
right way to deal with it?
I didn't see any mention of this in the porters handbook...
This is a quite tricky area. First thing to realise is that a dependency
line like this in a port:
RUN_DEPENDS+= ${LOCALBASE}/sbin/suphp:${PORTSDIR}/www/suphp
says that the port needs ${LOCALBASE}/sbin/suphp in order to run. The
port will be satisfied if there is any executable file of that name in
place -- there's no check that the file belongs to any particular port
or even to any port at all. If the test file is not found, then the
second part of the dependency line just indicates an example of a port
that when installed will provide the dependency.
Now, for most of the dependency lines shown explicitly in port makefiles,
there isn't any ambiguity here: there's only one port available that can
fulfil the dependency. Job done.
Where there are multiple choices, you see two different scenarios:
* Ports with 'devel' variants or multiple release versions, but that
only have a few dependents.
In this case, if you want a non-standard version, simply install
it first, before trying to install the dependent port. This will
work just fine from the point of view of the software operating
correctly, although it can confuse ports management tools, which
have been known to continually try and substitute the listed
dependency.
* Foundation ports -- things like Apache, MySQL, OpenLDAP, autoconf,
Java, perl, python. Here there are hundreds or thousands of possible
dependents. In these cases, typically there will be a special mechanism
for specifying what version(s) can be used with each port, possibly a
corresponding user settable flag for choosing what should be installed,
and frequently a mechanism for feeding back into the ports system what
version /was/ installed.
Lets take perl as an example. Currently there are two, pretty much freely
interchangeable, versions of perl available in the ports:
/usr/ports/lang/perl5.8 --- perl-5.8.9_3
/usr/ports/lang/perl5.10 --- perl-5.10.1
By default, you'll get perl5.8 -- that is, if you install anything with a
dependency on perl and perl was not previously installed and you haven't
made a deliberate choice to install one or the other. However, you can
opt to use perl5.10 simply by installing it -- or more likely, as perl is
pretty fundamental to the system and tends to be installed just about
everywhere by replacing perl5.8 with it. eg:
# portupgrade -o lang/perl5.10 -f perl-5.8.9_3
# portupgrade -x perl-5.10.1 -fr perl-5.10.1
After doing this, any perl-dependent ports you install will happily depend
on perl5.10 and if you build your own INDEX, perl5.10 will appear everywhere
in the dependency listings. The reason is that perl adds text like the
following to /etc/make.conf:
# added by use.perl 2009-09-12 09:04:56
PERL_VERSION=5.10.1
In principle you could add this variable definition to /etc/make.conf before
ever installing perl in order to get the version you want straight away.
This
works because ports that depend on perl generally contain the magic
invocation
like:
USE_PERL= yes
or
PERL_CONFIGURE= yes
which ultimately have the effect of causing /usr/ports/Mk/bsd.perl.mk to
be included and parsed during a make(1) invocation. The PERL_VERSION
variable is examined in there and used to modify various *_DEPENDS lines
amongst other things.
In fact, the majority of the files under /usr/ports/Mk exist to provide this
sort of alternate dependency capability for the sort of commonly used
software packages that the majority of everything else relies upon.
Perl is slightly unusual in that at the moment either of the perl versions
is compatible with any perl dependent ports in the tree. There's not much
perl-5.10 specific code readily available anywhere. More frequently ports
will need a specific version or versions of a dependency, and the typical
mechanisms for specifying that work like the following. The port maintainer
can indicate that a port depends on a popular software system and what
dependency versions are compatible with it by including a USE_FOO variable,
possibly with additional variables to control various behaviours:
c++: invalid conversion from 'int' to 'const char*'
Hello List,
I'm porting a c++ application to FreeBSD. I've got an error:
-
~/work/src/FileChannel.cpp: In member function 'QString
FileChannel::errorString()':
~/work/src/FileChannel.cpp:251: error: invalid conversion from 'int' to 'const
char*'
~/work/src/FileChannel.cpp:251: error: initializing argument 2 of 'char*
strcpy(char*, const char*)'
*** Error code 1
-
A simle patch makes the application to be compiled without errors:
-
--- src/FileChannel.cpp.orig2009-09-12 13:08:28.0 +0400
+++ src/FileChannel.cpp 2009-09-12 13:08:41.0 +0400
@@ -248,7 +248,7 @@
QString FileChannel::errorString()
{
-strcpy(lastErrorString, strerror_r(errno, lastErrorString, 0));
+strcpy(lastErrorString, XXX: Fix me: errno should be here);
return QString(trUtf8(lastErrorString));
}
-
If I understand correctly, an integer value which is returned by
strerror_r() should be converted to const char*.
I have _very_ basic knowledge about c++. Hence my question.
Can someone provide a patch (a proof of concept)? Thanks!
--
WBR, Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone Internet SP
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: linux-pango won't install
On Fri, 11 Sep 2009 23:01:23 -0600 Chad Perrin wrote: If you still want to install the port, you could just add this to the /etc/make.conf file: # Pango .if $(.CURDIR:M*/x11-toolkits/linux-pango) DISABLE_VULNERABILITIES=yes .endif How long has this been broken for 7.2? Considering all the stuff that depends on linux-pango, I'm surprised it hasn't been fixed. It will be broken until someone provide an URL to non-vulnerable RPM package. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: c++: invalid conversion from 'int' to 'const char*'
Boris Samorodov b...@ipt.ru wrote:
I'm porting a c++ application to FreeBSD. I've got an error:
-
~/work/src/FileChannel.cpp: In member function 'QString
FileChannel::errorString()':
~/work/src/FileChannel.cpp:251: error: invalid conversion from 'int' to
'const char*'
~/work/src/FileChannel.cpp:251: error: initializing argument 2 of 'char*
strcpy(char*, const char*)'
*** Error code 1
-
A simle patch makes the application to be compiled without errors:
-
--- src/FileChannel.cpp.orig 2009-09-12 13:08:28.0 +0400
+++ src/FileChannel.cpp 2009-09-12 13:08:41.0 +0400
@@ -248,7 +248,7 @@
QString FileChannel::errorString()
{
-strcpy(lastErrorString, strerror_r(errno, lastErrorString, 0));
+strcpy(lastErrorString, XXX: Fix me: errno should be here);
return QString(trUtf8(lastErrorString));
}
At least to me, this looks like a bug in the program you are porting.
I don't see how this would work on other platforms either, unless
the libc strerror_r() is shadowed which seems unlikely.
I assume someone replaced strerror() with strerror_r() and
missed the differences. The third argument of strerror_r()
being zero looks strange, too.
If I understand correctly, an integer value which is returned by
strerror_r() should be converted to const char*.
I have _very_ basic knowledge about c++. Hence my question.
Can someone provide a patch (a proof of concept)? Thanks!
You could try replacing the strerror_r() call with strerror(errno).
It wouldn't be thread-safe, but should at least work most of the
time.
If the application is threaded, a better fix would be not to use
strcpy() at all. strerror_r() already puts the error description
into the buffer, so there's no need to copy anything. To do this,
you'd still need to fix the third argument, though.
If lastErrorString is an array you could use sizeof(lastErrorString),
if it's a pointer you could look for a malloc() call that allocates
the buffer to figure out the size.
Either way, you should probably report the problem upstream.
Fabian
signature.asc
Description: PGP signature
Re: c++: invalid conversion from 'int' to 'const char*'
On Sat, 12 Sep 2009 12:41:43 +0200 Fabian Keil wrote:
Boris Samorodov b...@ipt.ru wrote:
I'm porting a c++ application to FreeBSD. I've got an error:
-
~/work/src/FileChannel.cpp: In member function 'QString
FileChannel::errorString()':
~/work/src/FileChannel.cpp:251: error: invalid conversion from 'int' to
'const char*'
~/work/src/FileChannel.cpp:251: error: initializing argument 2 of 'char*
strcpy(char*, const char*)'
*** Error code 1
-
A simle patch makes the application to be compiled without errors:
-
--- src/FileChannel.cpp.orig2009-09-12 13:08:28.0 +0400
+++ src/FileChannel.cpp 2009-09-12 13:08:41.0 +0400
@@ -248,7 +248,7 @@
QString FileChannel::errorString()
{
-strcpy(lastErrorString, strerror_r(errno, lastErrorString, 0));
+strcpy(lastErrorString, XXX: Fix me: errno should be here);
return QString(trUtf8(lastErrorString));
}
At least to me, this looks like a bug in the program you are porting.
I don't see how this would work on other platforms either, unless
the libc strerror_r() is shadowed which seems unlikely.
It compiles at linux (with warning though). ;-)
I assume someone replaced strerror() with strerror_r() and
missed the differences. The third argument of strerror_r()
being zero looks strange, too.
If I understand correctly, an integer value which is returned by
strerror_r() should be converted to const char*.
I have _very_ basic knowledge about c++. Hence my question.
Can someone provide a patch (a proof of concept)? Thanks!
You could try replacing the strerror_r() call with strerror(errno).
It wouldn't be thread-safe, but should at least work most of the
time.
Aha, the following patch helps:
-
--- src/FileChannel.cpp.orig2009-09-12 15:09:00.0 +0400
+++ src/FileChannel.cpp 2009-09-12 15:11:23.0 +0400
@@ -248,7 +248,7 @@
QString FileChannel::errorString()
{
-strcpy(lastErrorString, strerror_r(errno, lastErrorString, 0));
+strcpy(lastErrorString, strerror(errno));
return QString(trUtf8(lastErrorString));
}
-
If the application is threaded, a better fix would be not to use
strcpy() at all. strerror_r() already puts the error description
into the buffer, so there's no need to copy anything. To do this,
you'd still need to fix the third argument, though.
If lastErrorString is an array you could use sizeof(lastErrorString),
if it's a pointer you could look for a malloc() call that allocates
the buffer to figure out the size.
Thanks for your suggestions, much appreciated.
Either way, you should probably report the problem upstream.
Yep, it has been already done. The author said he'll fix it at
the next release but he have no time ATM. While I try to create
a port with the current release.
--
WBR, Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone Internet SP
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
where to put `startx` serverargs
hi there, since i don't use ipv6 X produces the following warning when starting up: _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/otaku:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 so i'd to start X this way: `startx -- -nolisten inet6`. i looked through the man pages of startx and xinit but couldn't find where to put the argument -nolisten inet6 so `startx` picks it up automatically. currently i have this extra line in /usr/local/bin/startx: serverargs = -nolisten inet6 but that's just a hack because i couldn't find any information on where to put the serverarg. cheers. alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: configuring X on the Presario with the 8200M driver
OK...I forgot 1 important step before rebooting (step 6 in the sequece below)... 5.5) Edit the /etc/rc.conf file... # vi /etc/rc.conf --- add the following 2 lines hald_enable=YES dbus_enable=YES -Original Message- From: Kenneth kennet...@earthlink.net Sent: Sep 12, 2009 2:23 AM To: Kenneth kennet...@earthlink.net, freebsd-questions@freebsd.org, freebsd-...@freebsd.org Cc: jules.sto...@gmail.com, ges...@yahoo.com Subject: Re: configuring X on the Presario with the 8200M driver Step 10 should be # Xorg -config xorg.conf.new -retro -Original Message- From: Kenneth kennet...@earthlink.net Sent: Sep 12, 2009 2:12 AM To: freebsd-questions@freebsd.org, freebsd-...@freebsd.org Cc: jules.sto...@gmail.com, ges...@yahoo.com Subject: configuring X on the Presario with the 8200M driver Moving this discussion to freebsd-x11. I have a Presario CQ60 with the NVIDIA 8200M G, and X is working! Here are the steps to get there. Do everything as root: 1) Update your ports to the most recent. Follow the FreeBSD manual, section 4.5 Using the Ports Collection, nuke the contents of /usr/ports, and install a new base using portsnap or cvsup. 2) Install the nvidia-driver. # cd /usr/ports/x11-driver/nvidia-driver # make install clean (I built with options FREEBSD_AGP checked, ACPI checked, LINUX unchecked). 3) You can install 2 more optional tools for configuring the nvidia card settings. I have not used them, but I installed them. # cd /usr/ports/x11-driver/nvidia-settings # make install clean # cd /usr/ports/x11-driver/nvidia-xconfig # make install clean 4) I also installed the fbdev driver from X.Org. # cd /usr/ports/x11-drivers/xf86-video-fbdev # make install clean 5) Add the nvidia driver as a dynamically loaded kernel module. # cd /boot # vi loader.conf (you better know how to use vi to edit) --- add the line nvidia_load=YES --- it is the only line I have in my loader.conf file 6) Reboot the system # reboot 7) If you want to see the version you just installed (your versions may be newer than mine below)... # pkg_info | grep nvidia nvidia-driver-185.18.29 nvidia-settings-190.32 nvidia-xconfig-190.32 # pkg_info | grep fbdev xf86-video-fbdev-0.4.0_2 8) Generate your xorg.conf.new file. # cd /root # Xorg -configure 9) Edit the xorg.conf.new file. # vi xorg.conf.new --- change the lineDriver nv to readDriver nvidia 10) Test the config file. # Xorg -config xorg.conf -retro --- you should get a grey screen and your mouse should work, especially if your mouse worked when installing FreeBSD --- to kill the test, press CTRL-ALT-BKSP 11) If everything worked, move and rename (drop the new extension) the config file to the /etc directory # mv xorg.conf.new /etc/X11/xorg.conf 12) Test again. Log in as another user belonging to the wheel group (or login as root). % startx --- you should get 3 green windows --- you can kill X by clicking on the large window on the left, and typing exit ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: reducing size of apache instances
John Almberg wrote: I'm starting to wonder about the Swap info from top... it never changes. It has said the same thing all day, since I've been watching it. Does that make sense? Swap: 2008M Total, 150M Used, 1858M Free, 7% Inuse That looks about normal if your RAM suffices. In that case only memory that hasn't been accessed for more than 24 hours will be moved to the swap space. So after an uptime of 24 hours, if no more apps get started there's no more reason for it to change. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Rule equivalence of pf uRPF check
Hello all, I sent this message to -pf list, but no one answered. I would like to verify my assumptions regarding the way pf's uRPF check works. I'm using a Soekris net5501 board as a firewall; port 0 ($ext_if) is internet uplink, ports 1-3 ($int_if, $mil_if, $vpn_if) are separate lan segments that should not be communicating with one another. Here is the start of my filter section: # Block all traffic by default block log # Broadcast DHCP traffic must be passed before urpf check pass in quick on !$ext_if proto udp from port dhcpc to \ 255.255.255.255 port dhcps # Enable source address spoofing protection block in quick from urpf-failed The question I have is whether the urpf-failed check is equivalent to the following three rules for each of the interfaces (I'm using $int_if as an example here): block in quick on $int_if from !$int_if:network block in quick on !$int_if from $int_if:network block in quick from $int_if The OpenBSD pf faq states that urpf-check is equivalent to the antispoof rules, but the antispoof section lists only the last two rules in my example as being equivalent. So the question is does urpf imply the first rule as well? - Max ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Rule equivalence of pf uRPF check
Maxim Khitrov wrote: block in quick on $int_if from !$int_if:network block in quick on !$int_if from $int_if:network block in quick from $int_if The OpenBSD pf faq states that urpf-check is equivalent to the antispoof rules, but the antispoof section lists only the last two rules in my example as being equivalent. So the question is does urpf imply the first rule as well? Not if uRPF is intended as a general mechanism. What would happen if you applied that on $ext_if (the external interface you connect to the rest of the internet with)? It's perfectly valid for packets from other than directly attached networks to be passed by your firewall -- not doing that would, in fact, completely negate your web browsing experience... Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
How to setup mDNSResponder on FreeBSD?
Hi all I have installed the net/mDNSResponder port on a FreeBSD 7.2 i386 computer. Set to launch the mdnsd on start up (in /etc/rc.conf). Changed hosts line in /etc/nsswitch.conf to hosts: files mdns dns. Rebooted. mDNSIdentify name.local immediately shows the IP address of the other computer but ping name.local shows following message: ping: cannot resolve name.local: Unknown host Its the same for ssh too. Is there anything else to set up in FreeBSD? Appreciate your reply. Sagara ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
System Upgrade
Здравствуйте, Freebsd-questions. Can I do this steps not in single user mode?? # 5. `reboot'(in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `make delete-old' # 9. `mergemaster' (you may wish to use -U or -ai). # 10. `reboot' # 11. `make delete-old-libs' (in case no 3rd party program uses them anymore) I am wanna upgrade remotely -- С уважением, Коньков mailto:kes-...@yandex.ru ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: System Upgrade
2009/9/12 Коньков Евгений kes-...@yandex.ru Здравствуйте, Freebsd-questions. Can I do this steps not in single user mode?? # 5. `reboot'(in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `make delete-old' # 9. `mergemaster' (you may wish to use -U or -ai). # 10. `reboot' # 11. `make delete-old-libs' (in case no 3rd party program uses them anymore) I am wanna upgrade remotely -- С уважением, Коньков mailto:kes-...@yandex.ru Yes, but it's not without risk. Best to turn down any service not absolutely needed eg everything except sshd. In my experience, this works well but YMMV -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Can anyone reproduce this Samba problem?
On Sat, Sep 5, 2009 at 6:12 PM, Karl Vogel vogelke+u...@pobox.com wrote: http://www.theopensourcerer.com/2008/04/17/a-shared-drop-box-using-samba/ has some suggestions that might help. It is a good link - In fact it's what I based my setup on. However, it relies on both 'inherit owner' and 'directory mode' / 'force directory mode' working simultaneously. And on my install, for some reason, that does not work. I can only get one or the other to work. Still not sure if it's a general Samba issue or FreeBSD-specific (or me being dumb somehow). -John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re[2]: System Upgrade
Здравствуйте, Adam. Вы писали 12 сентября 2009 г., 19:18:28: AVM 2009/9/12 Коньков Евгений kes-...@yandex.ru Здравствуйте, Freebsd-questions. Can I do this steps not in single user mode?? # 5. `reboot'(in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `make delete-old' # 9. `mergemaster' (you may wish to use -U or -ai). # 10. `reboot' # 11. `make delete-old-libs' (in case no 3rd party program uses them anymore) I am wanna upgrade remotely -- С уважением, Коньков mailto:kes-...@yandex.ru Yes, but it's not without risk. Best to turn down any service not AVM absolutely needed eg everything except sshd. In my experience, this works AVM well but YMMV YMMV??? -- С уважением, Коньков mailto:kes-...@yandex.ru ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Re[2]: System Upgrade
2009/9/12 Коньков Евгений kes-...@yandex.ru Здравствуйте, Adam. Вы писали 12 сентября 2009 г., 19:18:28: AVM 2009/9/12 Коньков Евгений kes-...@yandex.ru Здравствуйте, Freebsd-questions. Can I do this steps not in single user mode?? # 5. `reboot'(in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `make delete-old' # 9. `mergemaster' (you may wish to use -U or -ai). # 10. `reboot' # 11. `make delete-old-libs' (in case no 3rd party program uses them anymore) I am wanna upgrade remotely -- С уважением, Коньков mailto:kes-...@yandex.ru Yes, but it's not without risk. Best to turn down any service not AVM absolutely needed eg everything except sshd. In my experience, this works AVM well but YMMV YMMV??? The results of you doing this procedure may be different than mine. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Rule equivalence of pf uRPF check
On Sat, Sep 12, 2009 at 9:10 AM, Matthew Seamanm.sea...@infracaninophile.co.uk wrote: Maxim Khitrov wrote: block in quick on $int_if from !$int_if:network block in quick on !$int_if from $int_if:network block in quick from $int_if The OpenBSD pf faq states that urpf-check is equivalent to the antispoof rules, but the antispoof section lists only the last two rules in my example as being equivalent. So the question is does urpf imply the first rule as well? Not if uRPF is intended as a general mechanism. What would happen if you applied that on $ext_if (the external interface you connect to the rest of the internet with)? It's perfectly valid for packets from other than directly attached networks to be passed by your firewall -- not doing that would, in fact, completely negate your web browsing experience... Cheers, Matthew Right, I should have mentioned that I'm only talking about internal interfaces that serve separate 10.x/16 networks. My $int_if network is 10.0/16 and it is not the default route. Under those conditions, would the urpf check block any traffic coming in on $int_if that doesn't come from 10.0/16 network? If not, can you give me an example of what would be allowed? One other related question. Would urpf block a packet arriving on any physical interface that has a source IP of 127.0.0.1 or any other IP assigned to the firewall itself? - Max ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: System Upgrade
YMMV??? The results of you doing this procedure may be different than mine. Your Mileage May Vary A joking reference to advertisements for new cars in the US which are required to provide gas mileage figures, which always turn out to be optimistic and used a little foot note that states this phrase. These days the footnote is a bit more firm: Actual mileage will vary. See http://www.urbandictionary.com/define.php?term=YMMV or Google for more. -- --Jon Radel j...@radel.com smime.p7s Description: S/MIME Cryptographic Signature
Re: c++: invalid conversion from 'int' to 'const char*'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Boris Samorodov wrote:
On Sat, 12 Sep 2009 12:41:43 +0200 Fabian Keil wrote:
Boris Samorodov b...@ipt.ru wrote:
I'm porting a c++ application to FreeBSD. I've got an error:
-
~/work/src/FileChannel.cpp: In member function 'QString
FileChannel::errorString()':
~/work/src/FileChannel.cpp:251: error: invalid conversion from 'int' to
'const char*'
~/work/src/FileChannel.cpp:251: error: initializing argument 2 of 'char*
strcpy(char*, const char*)'
*** Error code 1
-
A simle patch makes the application to be compiled without errors:
-
--- src/FileChannel.cpp.orig2009-09-12 13:08:28.0 +0400
+++ src/FileChannel.cpp 2009-09-12 13:08:41.0 +0400
@@ -248,7 +248,7 @@
QString FileChannel::errorString()
{
-strcpy(lastErrorString, strerror_r(errno, lastErrorString, 0));
+strcpy(lastErrorString, XXX: Fix me: errno should be here);
return QString(trUtf8(lastErrorString));
}
At least to me, this looks like a bug in the program you are porting.
I don't see how this would work on other platforms either, unless
the libc strerror_r() is shadowed which seems unlikely.
It compiles at linux (with warning though). ;-)
I assume someone replaced strerror() with strerror_r() and
missed the differences. The third argument of strerror_r()
being zero looks strange, too.
If I understand correctly, an integer value which is returned by
strerror_r() should be converted to const char*.
I have _very_ basic knowledge about c++. Hence my question.
Can someone provide a patch (a proof of concept)? Thanks!
You could try replacing the strerror_r() call with strerror(errno).
It wouldn't be thread-safe, but should at least work most of the
time.
Aha, the following patch helps:
-
--- src/FileChannel.cpp.orig 2009-09-12 15:09:00.0 +0400
+++ src/FileChannel.cpp 2009-09-12 15:11:23.0 +0400
@@ -248,7 +248,7 @@
QString FileChannel::errorString()
{
-strcpy(lastErrorString, strerror_r(errno, lastErrorString, 0));
+strcpy(lastErrorString, strerror(errno));
return QString(trUtf8(lastErrorString));
}
-
If the application is threaded, a better fix would be not to use
strcpy() at all. strerror_r() already puts the error description
into the buffer, so there's no need to copy anything. To do this,
you'd still need to fix the third argument, though.
If lastErrorString is an array you could use sizeof(lastErrorString),
if it's a pointer you could look for a malloc() call that allocates
the buffer to figure out the size.
Thanks for your suggestions, much appreciated.
Either way, you should probably report the problem upstream.
Yep, it has been already done. The author said he'll fix it at
the next release but he have no time ATM. While I try to create
a port with the current release.
According to the man pages supplied with GNU gcc, this is a GNU extension.
(The following is from a
Linux system, but I suspect it's similar to the gcc port on FreeBSD.)
NAME
strerror, strerror_r - return string describing error number
SYNOPSIS
#include string.h
char *strerror(int errnum);
int strerror_r(int errnum, char *buf, size_t buflen);
/* XSI-compliant */
char *strerror_r(int errnum, char *buf, size_t buflen);
/* GNU-specific */
snip
The XSI-compliant strerror_r() is preferred for portable applications.
It returns the error string in the user-supplied buffer buf of length
buflen.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkqsIq4ACgkQjkAlo11skePOdACfSFAVWlkGskL9lOhzNYdmNAgq
9TYAoJqCRlVdA2rSzv3qXYD0ck6d/hJg
=qsX9
-END PGP SIGNATURE-
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
SciTE anomaly
I'm running FreeBSD 7.2p3, KDE 4.3.1 I added scite port. When I GO (F5), the following ruby program issues an error and fails to work properly: puts Hello, world. What is your name? myname = gets() puts Well, hello there + myname + . Here is the output: ruby hello.rb hello.rb:2:in `gets': Bad file descriptor (Errno::EBADF) from hello.rb:2 Hello, world. What is your name? Exit code: 1 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: linux-pango won't install
On Sat, Sep 12, 2009 at 02:19:22PM +0400, Boris Samorodov wrote: On Fri, 11 Sep 2009 23:01:23 -0600 Chad Perrin wrote: How long has this been broken for 7.2? Considering all the stuff that depends on linux-pango, I'm surprised it hasn't been fixed. It will be broken until someone provide an URL to non-vulnerable RPM package. Daniel Bye's comments seem to indicate that FreeBSD 8.x doesn't have this problem. Did I misunderstand? -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] Quoth Antoine de Saint-Exupery: A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away. pgp3Myhjktquu.pgp Description: PGP signature
