Re: Feedback on wanted port: obskurator
Thanks for your feedback but unfortunately the result is the same even if I
provide the prototype for printf in the source file.
Frederic
Frederic Culot frede...@culot.org wrote:
Following the links on the ports tasks wiki page I found
'obskurator' to be a wanted port ... so I gave it a try
and report about it here.
obskurator is supposed to obfuscate source code by changing
variable names ...
I believe the software itself is unusable and should not be
added to the ports tree in its current state. Indeed, I wrote a
simple code to test the resulting obfuscated program generated
by obskurator and it would not compile.
Here is my test code:
-
#include stdio.h
int my_int1;
int
main (void)
{
char *my_txt1 = Hello world;
printf (first var: %d\n, my_int1);
printf (second var: %s\n, my_txt1);
return 0;
}
-
and obskurator transformed it into the following:
-
#include stdio.h
int my_int1;
int
main (void)
{
char *x1 = Hello world;
x2 (first var: %d\n, my_int1);
x2 (second var: %s\n, x1);
return 0;
}
-
That is obskurator believed printf(3) was a user-defined variable
and replaced it with 'x2', which makes the resulting program
impossible to compile.
Does it by any chance work properly if you provide the prototype
for printf in the source file, instead of depending on the one
that should be provided by the #included header file? If it does,
a possible w/a might be to run the program through CPP first, and
then through obskurator.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
textproc/soprano linking problem
I wanted to switch to the new k3b-kde4. I ran through a couple of problems, most of them ports not accepting spaces in CC, but there's a soprano issue I don't get through to: Linking CXX executable sopranod cd /usr/obj/mobileKamikaze.norad/amd64/usr/ports/textproc/soprano/work/soprano-2.4.4/server /usr/local/bin/cmake -E cmake_link_script CMakeFiles/sopranod.dir/link.txt --verbose=1 /usr/bin/c++ -O2 -pipe -march=nocona -fno-strict-aliasing -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-check-new -fno-common -fvisibility=hidden -fvisibility-inlines-hidden CMakeFiles/sopranod.dir/sopranod.cpp.o CMakeFiles/sopranod.dir/sopranodcore.cpp.o CMakeFiles/sopranod.dir/lockfile.cpp.o -o sopranod ../soprano/libsoprano.so.4.3.0 libsopranoserver.so.1.2.0 ../index/libsopranoindex.so.1.1.0 /usr/local/lib/qt4/libQtNetwork.so /usr/local/lib/qt4/libQtDBus.so ../soprano/libsoprano.so.4.3.0 /usr/local/lib/qt4/libQtCore.so -pthread /usr/local/lib/libclucene.so -Wl,-rpath,/usr/obj/mobileKamikaze.norad/amd64/usr/ports/textproc/soprano/work/soprano-2.4.4/soprano:/usr/obj/mobileKamikaze.norad/amd64/usr/ports/textproc/soprano/work/soprano-2.4.4/server:/usr/obj/mobileKamikaze.norad/amd64/usr/ports/textproc/soprano/work/soprano-2.4.4/index:/usr/local/lib/qt4:/usr/local/lib: CMakeFiles/sopranod.dir/sopranod.cpp.o(.text+0x33): In function `usage()': : undefined reference to `Soprano::versionString()' CMakeFiles/sopranod.dir/sopranodcore.cpp.o(.gnu.linkonce.r._ZTV12SopranodCore+0xb0): undefined reference to `Soprano::Error::ErrorCache::lastError() const' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::ErrorCache::ErrorCache()' libsopranoserver.so.1.2.0: undefined reference to `Soprano::BindingSet::insert(QString const, Soprano::Node const)' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::Locator::line() const' libsopranoserver.so.1.2.0: undefined reference to `Soprano::BindingSet::~BindingSet()' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::Error::toParserError() const' libsopranoserver.so.1.2.0: undefined reference to `typeinfo for Soprano::Error::ErrorCache' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::Locator::Locator(int, int, int, QString const)' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Query::queryLanguageFromString(QString const)' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::Error::Error(QString const, int)' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::ErrorCache::setError(Soprano::Error::Error const) const' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::Error::operator=(Soprano::Error::Error const)' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::Error::~Error()' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::Locator::fileName() const' libsopranoserver.so.1.2.0: undefined reference to `Soprano::BindingSet::BindingSet()' libsopranoserver.so.1.2.0: undefined reference to `Soprano::BindingSet::operator[](int) const' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::Error::message() const' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::Locator::~Locator()' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::ParserError::locator() const' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::ErrorCache::~ErrorCache()' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::ParserError::ParserError(Soprano::Error::Locator const, QString const, int)' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::Error::code() const' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::Locator::operator=(Soprano::Error::Locator const)' libsopranoserver.so.1.2.0: undefined reference to `Soprano::BindingSet::bindingNames() const' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::Error::Error()' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::ErrorCache::setError(QString const, int) const' libsopranoserver.so.1.2.0: undefined reference to `Soprano::BindingSet::count() const' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::Locator::column() const' libsopranoserver.so.1.2.0: undefined reference to `Soprano::BindingSet::operator=(Soprano::BindingSet const)' libsopranoserver.so.1.2.0: undefined reference to `Soprano::BindingSet::operator[](QString) const' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::Locator::Locator()' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::ParserError::~ParserError()' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::Error::isParserError() const' libsopranoserver.so.1.2.0: undefined reference to `Soprano::Error::Error::Error(Soprano::Error::Error const)'
Re: It's annoying when something other than rsyncd listens on tco/873
I would prefer this approach: amd.conf has the option preferred_amq_port to specify the listening port. Don't know about ypbind. It is not just rsyncd that can get disturbed. Grabbing arbitrary port without consulting /etc/services and the startup scripts is a bad idea for any service. bindresvport() is at the bottom of the problem and there seems to be no readily available workaround. There is a portreserve tool in debian to avoid such situation. Don't know if we have an equivalent in FreeBSD. Regards, Jyoti On 16 August 2010 11:19, David Wolfskill da...@catwhisker.org wrote: My build machine is noisy generates heat, so I leave it powered off when it's not actively in use. As a consequence, it gets rebooted rather often. It is configured to run rsyncd(8) so I can update my laptop's local mirror of the FreeBSD SVN repository. A couple of mornings ago, I woke up, ready to start my daily builds (on the laptop build machine), but noticed that the SVN mirror on the laptop hadn't been updated. Eventually, I discovered that the reason was that amd(8) [on the build machine] was listening on 873/tcp, which is the port for rsync. I restarted amd(8); it happened to get other ports, so I restarted rsyncd(8), and was able to perfomr the mirroring. Mind, that was the first time since around February that I've had a problem with using rsyncd(8) in this fashion. Since then, I've become a bit ... sensitized to the issue, so a quick sockstat -4l immediately after powering it on helps avoid ths sort of thing. So this evening, such a check showed that ypbind(8) was listening on 873/tcp. The most straightforward way to make this a non-issue (it seems to me) would be to start rsyncd(8) before other services that grab arbitrary ports; however, the start-up script for rsyncd s[ecifies: # PROVIDE: rsyncd # REQUIRE: LOGIN # BEFORE: securelevel # KEYWORD: shutdown and both amd ypbind specify # BEFORE: DAEMON so that approach doesn't seem to quite work out. (I note that I recently stopped tracking stable/7 on the build machine, so I now boot into stable/8; perhaps something changed between stable/7 and stable/8 that inicreases the probability of such an unfortunate collsion.) Also, rsyncd(8) doesn't appear to consider this a condition worthy of note -- at least, I wasn't able to find any whines, and the daemon was still running. Anyone have suggestions for avoiding a recurrence (vs. working around the coiindition should one occur)? Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Current unassigned ports problem reports
(Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .) 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. S Tracker Resp. Description o ports/149704plugins doesn't work in eclipse-3.5.2_1 o ports/149702add missing fix in previous change o ports/149701patch to update net/radiator port from version 3.17.1 o ports/149698Update port: devel/p5-ParseTemplate o ports/149696New port: editors/wordgrinder, a simple Unicode-aware o ports/149691new port: japanese/tegaki-zinnia-japanese o ports/149690new port: japanese/tegaki-recognize o ports/149687new port: japanese/zinnia-tomoe o ports/149685new port: japanese/zinnia o ports/149682New port:net/gogonet_c gogoCLIENT offers IPv6 connecti o ports/149680[MAINTAINER] print/fontforge: Chase freetype2 update o ports/149674[patch] sysutils/fusefs-kmod: ftruncate() sycall on FU o ports/149669Update port: print/latex-biblatex update to 0.9b o ports/149667New port: print/latex-logreq automation of LaTeX workf o ports/149659math/scilab crashing when run demos f ports/149651Update port: devel/p5-Module-Manifest o ports/149634New Port: devel/p5-indirect o ports/149627[patch] net-p2p/amule2: fix for geoip and for a gd war f ports/149616[PATCH] textproc/ibus: update to 1.3.7 o ports/149613New port: devel/htable Lightweight implementation of h o ports/149601New port: games/gargoyle - a multiplatform interacti o ports/149582[Maintainer] www/squid31: unbreak SSL on IPv4-only sys f ports/149575Update for port: www/cherokee f ports/149565Update port: converters/igbinary o ports/149564patch for various games/ adding appropriate LICENSEs t a ports/149561mail/p5-Mail-SpamAssassin Test suite fails with perl 5 o ports/149507security/libprelude missing configure option o ports/149496new port: print/gnome-specimen f ports/149493[PATCH] www/typo3: update to 4.3.5 f ports/149473[maintainer update] devel/lamson unbreak f ports/149361Update port: security/nettle o ports/149358[MANTAINER UPDATE] net-mgmt/nagiosgraph to 1.4.3 o ports/149352ports/slim: default config has './' (dot-slash) in pat o ports/149349Update www/rt38 from 3.8.6 to 3.8.8 to match upstream o ports/149348New port: net/wowzamediaserver o ports/149327new port: www/cas, high-performance MVC framework for o ports/149320New port: textproc/simplexml is C++ XML parser and val f ports/149305Small security fix and transcoding profile fix to net/ o ports/149236[PATCH] www/typo3: update to 4.3.4 o ports/149196[PATCH] chinese/zh-ibus-chewing: update to 1.3.6.20100 o ports/149160New port: devel/rubygem-unicode - unicode string manip o ports/149147emulators/wine can't launch fullscreen DirectX applica o ports/149095[NEW PORT] lang/rakudo-star A useful, usable, early o ports/149069new port: sysutils/hfsexplorer HFSExplorer read Mac-fo o ports/149040new port: sysutils/pcpustat, Per-CPU usage statistics o ports/149020sysutils/dvdisaster Inappropriate ioctl for device wit o ports/148994New port: net/netperfmeter, a network performance mete o ports/148993[patch] net-im/echat: respect STRIP, don't override -O o ports/148973Maintainer update: java/jgraphx and unbreak fetch o ports/148967[patch] [smallfix] sysutils/bacula-server files/patch- f ports/148965[PATCH] net/freeradius2: add option UDPFROMTO f ports/148950Please upgrade www/grails to 1.3.3 o ports/148937[PATCH] print/cups-samba: improve installation message f ports/148925[PATCH] net/nss_ldap: Use $SUB_FILES instead of invoki f ports/148919graphics/mapnik not longer broken o ports/148914net-mgmt/mrtg 2.16.2 cannot run with perl 5.12.1 o ports/148901New port: sysutils/gdisk o ports/148855New port: www/rubygem-domainatrix (URL/domain parser) f ports/148841net/nss_ldapd not removed or added to MOVED o ports/148828[NEW PORT] net/py26-eventlet: Concurrent networking li o ports/148821[NEW PORT] security/ccsrch: Is a tool that searches fo f ports/148804graphics/gdal - Thread support broken o ports/148790[MAINTAINER] net-mgmt/zabbix-frontend: fix sqlite usag
Re: Wvdial
I'll see if it's within my capabilities. Chris Sorry for top-posting, Android won't let me quote, but K-9 can't yet do threading. On 16 Aug 2010 02:22, Mark Linimon lini...@lonesome.com wrote: On Sun, Aug 15, 2010 at 04:11:09PM +, John Sherman wrote: If Wvdial is returned to FreeBSD 8.0... From a quick check, I can't see where it was ever in FreeBSD in the first place? In any case, the best way to find out about new ports is to subscribe to FreshPorts ( http://www.freshports.org/ ). Other than that, you'll need to write up a shar and use send-pr, good luck :-) mcl ___ freebsd-ports@freebsd.org mailing list http://lists ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: i keep *trying* to move from portupgrade to portmaster
On 8/13/2010 11:51 AM, Freddie Cash wrote: On Fri, Aug 13, 2010 at 8:47 AM, Mike Jakubik mike.jaku...@intertainservices.com wrote: Thanks for the info. Do you think this may be a usefull feature for other users coming from portupgrade though? If there is an option to always rebuild, one would think there would be an opposite option too. I can't speak for Doug as to what gets added to portmaster. However, as a user of portmaster, I would like to say that just because portupgrade (or portmanager, or port-tool-of-the-month) has a specific feature, doesn't mean it absolutely needs to be added to portmaster. Im not saying because its in portupgrade it needs to be in portmaster. I'm simply saying that it's a useful feature for me, and possibly others. It also doesnt make sense to me to have an option to explicitly force rebuilds of ports that don't need an update, but have no option to disable rebuilds. Personally, I can say that in my many years of using port management tools (on firewalls, routers, servers, and desktops), I have never had a need for a feature like this. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: i keep *trying* to move from portupgrade to portmaster
On 12/08/2010 20:11, Anonymous wrote: Dominic Fandrey kamik...@bsdforen.de writes: On 07/08/2010 02:46, Adam Vande More wrote: On Fri, Aug 6, 2010 at 5:11 PM, Doug Barton do...@freebsd.org wrote: On 08/06/2010 15:03, Adam Vande More wrote: for pkg in /var/db/pkg/* ; do pkg_create -b $pkg done You guys are loosing opportunities to boast with your shell one liners # pkg_info -Ea | xargs -n1 pkg_create -b Why do you need xargs(1) when pkg_create(1) supports regexps as well as simple globs? $ pkg_create -b \*# all packages $ pkg_create -xb firefox # only firefox I wasn't aware that pkg_create can create several packages at once, thanks for that! -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
net/asterisk16
Hello. Can you tell me when planed adding asterisk 1.6.2 in ports Freebsd?. I try write to maintainer: sobo...@freebsd.org, but received error: 550 sender or recipient address is wrong Thank you! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: It's annoying when something other than rsyncd listens on tco/873
On 8/15/2010 10:49 PM, David Wolfskill wrote: The most straightforward way to make this a non-issue (it seems to me) would be to start rsyncd(8) before other services that grab arbitrary ports; however, the start-up script for rsyncd s[ecifies: # PROVIDE: rsyncd # REQUIRE: LOGIN # BEFORE: securelevel # KEYWORD: shutdown and both amd ypbind specify # BEFORE: DAEMON so that approach doesn't seem to quite work out. The only way to do this is to edit the rsyncd rc.d script. I realize that this introduces a problem when doing upgrades ... Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: i keep *trying* to move from portupgrade to portmaster
On Mon, Aug 16, 2010 at 6:37 PM, Dominic Fandrey kamik...@bsdforen.de wrote: I wasn't aware that pkg_create can create several packages at once, thanks for that! I'm not quite sure how pkg_create creates a package, but it if does use make package-noinstall be aware that it have a bug that causes the packages to not include rc.d scripts :( -- chs, ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: DEPRECATE and a master/slave port
On 8/13/2010 11:25 AM, Paul Schmehl wrote: I want to DEPRECATE security/barnyard. It's a master port. The slave is security/barnyard-sguil. Is it sufficient to DEPRECATE and EXPIRE the master? Or do I need to do that to the slave as well? The simplest and best way to answer this question is to test it. Make your changes in the master, then go into the slave port and type make. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: i keep *trying* to move from portupgrade to portmaster
On 16/08/2010 22:09, Christer Solskogen wrote: On Mon, Aug 16, 2010 at 6:37 PM, Dominic Fandrey kamik...@bsdforen.de wrote: I wasn't aware that pkg_create can create several packages at once, thanks for that! I'm not quite sure how pkg_create creates a package, but it if does use make package-noinstall be aware that it have a bug that causes the packages to not include rc.d scripts :( No, the bug is in bsd.port.mk and the proposed patch is to rely on pkg_create -b to create the package. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: i keep *trying* to move from portupgrade to portmaster
2010/8/6 Sandra Kachelmann s.kachelm...@googlemail.com: I've been using ports-mgmt/portupgrade pretty much ever since it started to exist. Unfortunately portupgrade seems to be pretty much abandonware so I've been told to move on to portmaster. Despite the very long manpage I can't seem to be able to achieve the following thing with portmaster: $ portupgrade --batch -a If I issue this command I know exactly that I can go out, have a drink, cook some dinner and unlock my workstation the next day and find that everything completed unless a port failed to build. With portmaster I get asked a s*t load of interactive questions, whether I want to delete some package, whether it's really okay to pull in all the dependencies and so on. Can someone spoonfeed me the command I need to issue with portmaster in order to achieve the same thing as with $ portupgrade --batch -a I'm quite late, and won't speak for batch, but here is what I use with portmaster. I switched recently from portupgrade to portmaster and I'm happy with the following command. I was used to portupgrade -a and was disappointed with portmaster -a the first days. # portmaster -adw -x openoffice -a is just like in portupgrade, -d cleans old distfiles without confirmation, -w copies old libraries in /usr/local/lib/compat/pkg/ like portupgrade does, I find this very useful to not break the system. That's less likely to happen with the recent approach of bumping revisions of all dependant ports, but it's safer and I often clean this directory. -x to exclude some ports you don't want to upgrade This is very convenient because, unlike with portupgrade -a, all the config dialogs appear at the beginning (so I don't have to use a batch mode, and never see my upgrade paused on a blue screen after having left the computer for the night), and portmaster prompts you with a list of the actions that will be taken before doing anything. I now know what will be installed in addition of my already present ports. There's also a very practical feature to delete build-deps, but I don't use it because I already have a script which deletes everything but what I explicitely want to keep. Thanks Doug ! Cheers Is that even possible? $ portupgrade --batch -a Thanks in advance! Sandra ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[portmaster] navigation in the man page
Am I the only one who finds it hard to navigate in portmaster(8)? - options are neither sorted alphabetically nor grouped in blocks[1] - too little space between an option and its description - inconsistent in using terms (flags vs. options) - being too verbose about port-related terms[2] - SYNOPSYS makes a spaghetti with one-letter options, long options and comments[3] - DESCRIPTION is too verbose, it should go either to EXAMPLES or to a specific option description[4] in OPTIONS - `-i' option is misleading, portmaster is already quite interactive On the side, I still can't find how to shut up portmaster from asking me about +IGNOREME ports. [1] look at how grouping is done in grep(1) from textproc/gnugrep [2] Like the one below [-R] -r name/glob of port directory in /var/db/pkg Why not use `origin' or `pkg-name' term from pkg_info(1)? WTF is `port directory in /var/db/pkg' ? Only *package* directories lie there. [3] Smth like `portmaster [options] [args...]' is probably enough. There is already EXAMPLES section, no need to duplicate it. [4] I for one read DESCRIPTION only once, when first run the tool and never again. Most of the time I'm more concerned how certain option changes behavior and not interested in general prose. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: DEPRECATE and a master/slave port
--On Monday, August 16, 2010 14:09:29 -0700 Doug Barton do...@freebsd.org wrote: On 8/13/2010 11:25 AM, Paul Schmehl wrote: I want to DEPRECATE security/barnyard. It's a master port. The slave is security/barnyard-sguil. Is it sufficient to DEPRECATE and EXPIRE the master? Or do I need to do that to the slave as well? The simplest and best way to answer this question is to test it. Make your changes in the master, then go into the slave port and type make. Thanks, Doug. That confirms for me that the slave port is deprecated automatically when its master port is deprecated. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Feedback on wanted port: obskurator
On Sun, Aug 15, 2010 at 09:58:12AM +0200, Frederic Culot wrote: As a conclusion I would say that 'obskurator' should be removed from the wanted port page at http://wiki.freebsd.org/AndrewPantyukhin/Ports as it does not manage to generate compilable obfuscated code as it claims to do. I've added a note to the wiki page. I don't want to remove it though, as it is sat's page. -- Shaun Amott // PGP: 0x6B387A9A A foolish consistency is the hobgoblin of little minds. - Ralph Waldo Emerson pgpHg7hc1xcOD.pgp Description: PGP signature
Re: It's annoying when something other than rsyncd listens on tco/873
On Sun, Aug 15, 2010 at 10:49:32PM -0700, David Wolfskill wrote: [... rsyncd(8) port -- 873/tcp -- grabbed by either ypbind or amd before rsynd started, so rsyncd isn't functional -- and doesn't whine about it or terminate] Thanks for the suggestions so far. Unfortunately, I'm finding an actual solution rather elusive still. Some poking around lead me to https://bugzilla.redhat.com/show_bug.cgi?id=103401, which chronicles multipple instantiations of the same kind of problem over a period from 2003-08-29 16:13:45 EDT - 2010-07-21 10:52:43 EDT [so far], with the approach recommended for the RH crowd apparently being to make use of portreserve (http://cyberelk.net/tim/software/portreserve/). Unfortunately, doing that would seem to require modifying startup scripts in the base system, as well, which seems to be a significant barrier. [*] * I haven't actually looked at the code, but from reading the comments in the above-cite bug report, the general idea is: * portreserve is started early, and given a list of ports to reserve. * A service that wants to use one of these reserved ports would have the start/stop scritp modified to invoke portrelease during start and (re-)invoke portreserve for stop. Of course, this only handles controlled stops, and there could be a race condition As it was written for a Linux environment, I'm assuming(!) that the license is not especially attractive for BSD. But as noted above, base system services would need to be modified to invoke it, which rather plays havoc with the otherwise relatively clear distinction (in my mind, anyhow) between base vs. ports. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpA2SY4ALcK1.pgp Description: PGP signature
Re: i keep *trying* to move from portupgrade to portmaster
On 8/16/2010 3:04 PM, Olivier Smedts wrote: I'm quite late, and won't speak for batch, With portmaster 3.0 it should no longer be necessary. The option to stop displaying config menus is now 100% effective. but here is what I use with portmaster. I switched recently from portupgrade to portmaster and I'm happy with the following command. Glad to hear that someone is happy anyway. :) I was used to portupgrade -a and was disappointed with portmaster -a the first days. # portmaster -adw -x openoffice -a is just like in portupgrade, -d cleans old distfiles without confirmation, Depending on what you're doing you might be happier with the option to not not clean distfiles at all, combined with occasional use of the tool to clean up stale distfiles all at once. -w copies old libraries in /usr/local/lib/compat/pkg/ like portupgrade does, I find this very useful to not break the system. That's less likely to happen with the recent approach of bumping revisions of all dependant ports, but it's safer and I often clean this directory. I've toyed with the idea of making this the default, but don't really want to do that until there is a serviceable tool to clean up no-longer-needed libraries in a more or less automated way. Rumor is that $SOMEONE is working on such a tool ... The 2 options above can be added to a portmaster rc file if you're sure you always want to use them. The distfile options can be overridden on the command line even if they are in the rc file. -x to exclude some ports you don't want to upgrade You can also use an +IGNOREME file for this purpose. This is very convenient because, unlike with portupgrade -a, all the config dialogs appear at the beginning (so I don't have to use a batch mode, and never see my upgrade paused on a blue screen after having left the computer for the night), and portmaster prompts you with a list of the actions that will be taken before doing anything. I now know what will be installed in addition of my already present ports. There's also a very practical feature to delete build-deps, but I don't use it because I already have a script which deletes everything but what I explicitely want to keep. Thanks Doug ! Thank you for the kind words. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: It's annoying when something other than rsyncd listens on tco/873
On 08/16/2010 01:49, David Wolfskill wrote: My build machine is noisy generates heat, so I leave it powered off when it's not actively in use. As a consequence, it gets rebooted rather often. It is configured to run rsyncd(8) so I can update my laptop's local mirror of the FreeBSD SVN repository. A couple of mornings ago, I woke up, ready to start my daily builds (on the laptop build machine), but noticed that the SVN mirror on the laptop hadn't been updated. Eventually, I discovered that the reason was that amd(8) [on the build machine] was listening on 873/tcp, which is the port for rsync. I restarted amd(8); it happened to get other ports, so I restarted rsyncd(8), and was able to perfomr the mirroring. Mind, that was the first time since around February that I've had a problem with using rsyncd(8) in this fashion. Since then, I've become a bit ... sensitized to the issue, so a quick sockstat -4l immediately after powering it on helps avoid ths sort of thing. So this evening, such a check showed that ypbind(8) was listening on 873/tcp. The most straightforward way to make this a non-issue (it seems to me) would be to start rsyncd(8) before other services that grab arbitrary ports; however, the start-up script for rsyncd s[ecifies: # PROVIDE: rsyncd # REQUIRE: LOGIN # BEFORE: securelevel # KEYWORD: shutdown and both amd ypbind specify # BEFORE: DAEMON so that approach doesn't seem to quite work out. (I note that I recently stopped tracking stable/7 on the build machine, so I now boot into stable/8; perhaps something changed between stable/7 and stable/8 that inicreases the probability of such an unfortunate collsion.) Also, rsyncd(8) doesn't appear to consider this a condition worthy of note -- at least, I wasn't able to find any whines, and the daemon was still running. Anyone have suggestions for avoiding a recurrence (vs. working around the coiindition should one occur)? I have been at this point once or twice and it always boiled down to rpcbind in my situation on a few NIS+ boxen. The problem that I came across was that /usr/local/etc/rc.d is parsed long after /etc/rc.d contents so adding the BEFORE to the rsync start script would not help or didn't at that time. One thing that comes to mind is that script that Jeremy? posted for waiting for the network a certain period of time before initializing services. Maybe this could also play a role in a situation to have a services script that could be controlled by rc.conf(5) to wait for a service to come up before continuing its own operation. And of course it should continue no matter what in either case but would allow you to introduce possibly needed delays in the rc. Here is a slightly modified version of Jeremy's script that I use. http://bit.ly/cpbrlm Food-4-Thought Regards, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [portmaster] navigation in the man page
It's customary to cc the maintainer of a port when you're commenting on it. Even more so when the maintainer is also the software author. I usually keep up on the lists, but there are times when it falls lower on the priority list so copying me on the message will ensure I can see it in a timely manner. On 08/16/2010 15:31, Anonymous wrote: Am I the only one who finds it hard to navigate in portmaster(8)? Nope. :) You've got great company. I'm in sort of a no-win situation here. Most of what's in the man page now is there as a result of users being confused about something, however now I'm getting complaints that the man page is too long, too hard to read, etc. Since I can't win either way, and since there are an unmanageably large number of options (which makes being succinct almost impossible) I have chosen to more fully document things. That way at least the information is there if the user chooses to search for it. You seem pretty convinced and/or upset about what you wrote below, so consider my response as simply an opportunity for me to present my side of the story, rather than an attempt to change your mind. :) - options are neither sorted alphabetically nor grouped in blocks[1] In the SYNOPSIS section the options are organized in terms of the flags that can be used for regular port operations (Common Flags), then the various ways to specify what port to work on, then the various other options that are also relevant to individual ports, then the package and index options, then the other options that are not related to installs/updates. In the OPTIONS section they are grouped roughly the same way (and roughly in the same order), alphabetically, but with mutually exclusive options grouped together. - too little space between an option and its description Aside from the fact that this just plain sounds snarky, you'll have to take up your concerns with -mdoc. My intention (which I believe I've successfully accomplished) is to use standard markup wherever possible. - inconsistent in using terms (flags vs. options) Again, snarky; but I will take a look at making this usage more consistent. Personally I have always used these terms interchangeably, but I could have been wrong about it all this time. :) - being too verbose about port-related terms[2] [2] Like the one below [-R] -r name/glob of port directory in /var/db/pkg Why not use `origin' or `pkg-name' term from pkg_info(1)? WTF is `port directory in /var/db/pkg' ? Only *package* directories lie there. Well origin is obviously wrong, however my attempt here is to convey the information necessary to users who are not at all familiar with the port system internals. While it may not be the proper shorthand term, anyone who isn't clear about what I mean can easily look in /var/db/pkg, see the names of the directories there, and come to the right conclusion about what they need to specify on the command line. - SYNOPSYS makes a spaghetti with one-letter options, long options and comments[3] [3] Smth like `portmaster [options] [args...]' is probably enough. There is already EXAMPLES section, no need to duplicate it. We'll have to agree to disagree on this one. The descriptions in that section are already as terse as I feel comfortable making them. - DESCRIPTION is too verbose, [4] I for one read DESCRIPTION only once, when first run the tool and never again. Most of the time I'm more concerned how certain option changes behavior and not interested in general prose. Again, I'd love to have it shorter, but this isn't cat we're talking about here. And of course, you're always free to just not read it (you'd be in good company there too). :) OTOH, there have recently been a non-trivial number of users asking me about Can portmaster do $foo? where the answer to their question is already documented in the man page, often in the DESCRIPTION section. Of course, the values of $foo are all different, making it that much harder for me to decide what ought to be cut. I'd also like to point out that IME most people use the search feature of their $PAGER to find specific information about options. - `-i' option is misleading, portmaster is already quite interactive -i interactive update mode -- ask whether to rebuild ports To me that's pretty descriptive. Of course I could make the description more verbose if you like. :) You might have noticed that I re-edited your post a bit to make my replies more meaningful. Feel free to conclude from that that you and I have vastly different communication styles, and therefore we are not likely to reach agreement on what my man page should look like. On the side, I still can't find how to shut up portmaster from asking me about +IGNOREME ports. The design is that if portmaster encounters a port with an +IGNOREME file it will ask you, once and only once, under certain
Re: It's annoying when something other than rsyncd listens on tco/873
On 08/16/2010 17:20, jhell wrote: The problem that I came across was that /usr/local/etc/rc.d is parsed long after /etc/rc.d contents This hasn't been true for a very long time. I first added the code to incorporate the local scripts into the base rcorder almost 5 years ago. so adding the BEFORE to the rsync start script would not help or didn't at that time. You can't add a BEFORE which is earlier than a REQUIRE (one of the many reasons that I dislike BEFORE). Your configuration was probably creating a circular dependency error that you didn't see. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: It's annoying when something other than rsyncd listens on tco/873
On Mon, 16 Aug 2010 20:20:31 -0400 jhell jh...@dataix.net wrote: The problem that I came across was that /usr/local/etc/rc.d is parsed long after /etc/rc.d contents so adding the BEFORE to the rsync start script would not help or didn't at that time. That only matters if you need to sort before the early-late divider and you can't move the divider - it shouldn't be an issue here. I would suggest making a copy of the rc.d script, edit it to give it a different name, and rename the file to match - that way it won't get overwritten and the installed file wont interfere. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/149475: Update port: sysutils/p5-Sys-Filesystem
Synopsis: Update port: sysutils/p5-Sys-Filesystem Responsible-Changed-From-To: freebsd-ports-freebsd-ports-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Aug 17 02:01:19 UTC 2010 Responsible-Changed-Why: Canonicalize assignment. http://www.freebsd.org/cgi/query-pr.cgi?pr=149475 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
portmaster always re-installs some ports
A while back I aborted a recursive update (bad idea, I know now) and must have messed up something in whatever info portmaster uses to decide whether to re-install a port. Now, whenever I use portmaster -a, it re-installs py26-imaging, py26-reportlab and py26-xml. Every time. And it's a re-installation, not an upgrade. I've tried manually uninstalling and then reinstalling these ports, but portmaster still thinks they always need to re-installed . So the manual un-/re-install apparently doesn't fix whatever info it's looking at. I checked the portmaster manpage, but didn't find anything that tells me how to fix my problem. I also took a quick look at the portmaster sourcecode but nothing jumped out at me. Any ideas? It's probably something obvious, but I'm missing it. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster always re-installs some ports
On Mon 16 Aug 2010 at 19:48:23 PDT Charlie Kester wrote: A while back I aborted a recursive update (bad idea, I know now) and must have messed up something in whatever info portmaster uses to decide whether to re-install a port. Now, whenever I use portmaster -a, it re-installs py26-imaging, py26-reportlab and py26-xml. Every time. Correction: every time any other port is upgraded. If all ports are reported as up to date, the three python ports are not re-installed. But if any port is upgraded, the re-install occurs, even if the upgraded port has no dependency relationship with any of the three python ports. And it's a re-installation, not an upgrade. I've tried manually uninstalling and then reinstalling these ports, but portmaster still thinks they always need to re-installed . So the manual un-/re-install apparently doesn't fix whatever info it's looking at. I checked the portmaster manpage, but didn't find anything that tells me how to fix my problem. I also took a quick look at the portmaster sourcecode but nothing jumped out at me. Any ideas? It's probably something obvious, but I'm missing it. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster always re-installs some ports
A while back I aborted a recursive update (bad idea, I know now) and must have messed up something in whatever info portmaster uses to decide whether to re-install a port. Now, whenever I use portmaster -a, it re-installs py26-imaging, py26-reportlab and py26-xml. From portmaster(8): /var/db/pkg/*/PM_UPGRADE_DONE_FLAG Indicates to a subsequent -a, -f, or -r run which includes the -R option that a port has already been rebuilt, so it can be safely ignored if it is up to date. Are there any of the above files left in your PKG_DBDIR (/var/db/pkg, by default)? If so, delete them, and try again. If there aren't, check your ports tree, build environment, local Makefiles (if any) and PKG_DBDIR. If they're okay, then it looks like a bug in portmaster. In that case, you'll have to provide a build transcript so that the problem can be diagnosed. Run portmaster verbosely -- you could use script(1) and execute portmaster via sh -x `which portmaster` ..., for example. b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [portmaster] navigation in the man page
Doug Barton do...@freebsd.org writes: - inconsistent in using terms (flags vs. options) Again, snarky; but I will take a look at making this usage more consistent. Personally I have always used these terms interchangeably, but I could have been wrong about it all this time. :) The average user may not be familiar `flag' and `option' describe same things in the context of running programs from command line. - being too verbose about port-related terms[2] [2] Like the one below [-R] -r name/glob of port directory in /var/db/pkg Why not use `origin' or `pkg-name' term from pkg_info(1)? WTF is `port directory in /var/db/pkg' ? Only *package* directories lie there. Well origin is obviously wrong, however my attempt here is to convey the information necessary to users who are not at all familiar with the port system internals. While it may not be the proper shorthand term, anyone who isn't clear about what I mean can easily look in /var/db/pkg, see the names of the directories there, and come to the right conclusion about what they need to specify on the command line. You can define the meaning of a term in an option description and common terms can be put into DESCRIPTION section. Such terms can be described more verbosely in order to not confuse new users as well as experienced ones. No need to clutter usage line of an option. Besides, without any kind of brackets it's a bit confusing whether those words separated by spaces are treated as several arguments or as one. On the side, I still can't find how to shut up portmaster from asking me about +IGNOREME ports. The design is that if portmaster encounters a port with an +IGNOREME file it will ask you, once and only once, under certain circumstances, if you want to update it. My theory is that the average user is rather likely to put an +IGNOREME file in a port, err, package, errr, directory in /var/db/pkg and subsequently forget that it's there. If portmaster is asking you more than once during the same run about a port with an +IGNOREME file then please report that as a bug (here on the list is fine), with specific instructions on how to reproduce it. Why not add smth like --no-confirm? I'm one of those average users that expects tools to have non-interactive mode, do its best with defaults and fail otherwise. If you really really want portmaster to never prompt you about a port you can create a pattern for it based on what portmaster does with the -x option and put that in your portmaster rc file. PM_EXCL? It's not documented in portmaster(8) nor in sample config. Way to promote reading the code. ;) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster always re-installs some ports
On 08/16/2010 20:07, Charlie Kester wrote: On Mon 16 Aug 2010 at 19:48:23 PDT Charlie Kester wrote: A while back I aborted a recursive update (bad idea, I know now) Well not always, but apparently it was this time. :) and must have messed up something in whatever info portmaster uses to decide whether to re-install a port. Now, whenever I use portmaster -a, it re-installs py26-imaging, py26-reportlab and py26-xml. Every time. Correction: every time any other port is upgraded. If all ports are reported as up to date, the three python ports are not re-installed. But if any port is upgraded, the re-install occurs, even if the upgraded port has no dependency relationship with any of the three python ports. Well that's just wacky. Sorry to hear that you're having this kind of problem. I suggest the following: 1. pkg_delete -f the 3 affected ports 2. Run 'portmaster --check-depends' If it tells you that there are dependencies listed for those 3 ports, but there is no installed version, make note of the port(s) that trigger this message then say yes to the delete the dependency data prompt 4. Run 'portmaster --check-depends' again to make sure everything is fixed now. 5. Run 'portmaster list-of-ports-from-number-2' Make sure you upgrade them all at once just to be safe. Then you should be fine, let me know if that works for you. If it doesn't I can give you some suggestions for more advanced debugging. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [portmaster] navigation in the man page
On 08/16/2010 20:42, Anonymous wrote: Doug Bartondo...@freebsd.org writes: - inconsistent in using terms (flags vs. options) Again, snarky; but I will take a look at making this usage more consistent. Personally I have always used these terms interchangeably, but I could have been wrong about it all this time. :) The average user may not be familiar `flag' and `option' describe same things in the context of running programs from command line. Fair enough. - being too verbose about port-related terms[2] [2] Like the one below [-R] -r name/glob of port directory in /var/db/pkg Why not use `origin' or `pkg-name' term from pkg_info(1)? WTF is `port directory in /var/db/pkg' ? Only *package* directories lie there. Well origin is obviously wrong, however my attempt here is to convey the information necessary to users who are not at all familiar with the port system internals. While it may not be the proper shorthand term, anyone who isn't clear about what I mean can easily look in /var/db/pkg, see the names of the directories there, and come to the right conclusion about what they need to specify on the command line. You can define the meaning of a term in an option description and common terms can be put into DESCRIPTION section. Such terms can be described more verbosely in order to not confuse new users as well as experienced ones. No need to clutter usage line of an option. Thanks, you have neatly defined my dilemma. You want some things in the man page to be less verbose, but you also want some things to be more verbose. Since I can't win, I take my best shot. :) Besides, without any kind of brackets it's a bit confusing whether those words separated by spaces are treated as several arguments or as one. I'll consider this as well. On the side, I still can't find how to shut up portmaster from asking me about +IGNOREME ports. The design is that if portmaster encounters a port with an +IGNOREME file it will ask you, once and only once, under certain circumstances, if you want to update it. My theory is that the average user is rather likely to put an +IGNOREME file in a port, err, package, errr, directory in /var/db/pkg and subsequently forget that it's there. If portmaster is asking you more than once during the same run about a port with an +IGNOREME file then please report that as a bug (here on the list is fine), with specific instructions on how to reproduce it. Why not add smth like --no-confirm? I'm one of those average users No you're not, not even close. You're way ahead of the average user curve, you're not fooling me. :) If you really really want portmaster to never prompt you about a port you can create a pattern for it based on what portmaster does with the -x option and put that in your portmaster rc file. PM_EXCL? It's not documented in portmaster(8) nor in sample config. That's because it's not _intended_ for use in the manner I'm suggesting, but that doesn't mean that it can't be used that way. (In fact, I know of users that already do.) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
