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 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 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 >Sent: Sep 12, 2009 2:23 AM >To: Kenneth , 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 >>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 Коньков Евгений > Здравствуйте, 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 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 Коньков Евгений >> Здравствуйте, 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 Коньков Евгений > Здравствуйте, Adam. > > Вы писали 12 сентября 2009 г., 19:18:28: > > AVM> 2009/9/12 Коньков Евгений > > >> Здравствуйте, 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 Seaman 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 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 > >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 */ >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