msgmerge hangs
I've been noticing for a while now in my port builds that /usr/local/bin/msgmerge has a distinct tendency to get hung up, just sitting there spinning its wheels forever. Has anyone else ever seen this behavior, or know what may be causing it and how to correct it? Thanks! -- Conrad J. Sabatier conr...@cox.net ___ 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
Audacious startup error
Suddenly started seeing this recently: $ audacious WARNING: Audacious seems to be already running but is not responding. (audacious:46486): GLib-GObject-WARNING **: gsignal.c:2275: signal `draw' is invalid for instance `0x80d1b4c70' (audacious:46486): GLib-GObject-WARNING **: gsignal.c:2275: signal `draw' is invalid for instance `0x80d1b4ce0' Any clues, anyone? Thanks! -- Conrad J. Sabatier conr...@cox.net ___ 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: Continual error dialogs since upgrading some ports
On Tue, 29 May 2012 16:04:40 +0200 Daniel Nebdal dneb...@gmail.com wrote: On Mon, May 28, 2012 at 12:29 PM, Conrad J. Sabatier conr...@cox.net wrote: Since upgrading a number of ports yesterday, I'm now being hounded continually with error dialogs popping up with the message: An internal system error has occurred A problem that we were not expecting has occurred. Please report this bug in your distribution bugtracker with the error description. The dialog is adorned with that little lifesaver image used by the GNOME help system, as well as a Show details button. Unfortunately, the details provided are a little vague, popping up another dialog showing the same message as the initial dialog, but with a More details dropdown button. More details provides only the following: The backend exited unexpectedly. This is a serious error as the spawned backend did not complete the pending transaction. Nowhere to be seen is any mention of exactly what program is spawning these error dialogs. Anyone ever seen these and/or have any idea where they might be coming from? Thanks! It seems to be a PackageKit thing - do you have a check for new updates-applet running, or something like that? (ref http://forums.freebsd.org/showthread.php?t=23959 ) Hmm, not sure about that. Will have to check. Thanks for the link, though. I'm currently running vtwm, and haven't seen the error, so it's definitely something going on in my GNOME environment. We'll see what I can find out. -- Conrad J. Sabatier conr...@cox.net ___ 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
Continual error dialogs since upgrading some ports
Since upgrading a number of ports yesterday, I'm now being hounded continually with error dialogs popping up with the message: An internal system error has occurred A problem that we were not expecting has occurred. Please report this bug in your distribution bugtracker with the error description. The dialog is adorned with that little lifesaver image used by the GNOME help system, as well as a Show details button. Unfortunately, the details provided are a little vague, popping up another dialog showing the same message as the initial dialog, but with a More details dropdown button. More details provides only the following: The backend exited unexpectedly. This is a serious error as the spawned backend did not complete the pending transaction. Nowhere to be seen is any mention of exactly what program is spawning these error dialogs. Anyone ever seen these and/or have any idea where they might be coming from? Thanks! -- Conrad J. Sabatier conr...@cox.net ___ 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: Problem building cmake
On Tue, May 15, 2012 at 10:11:25PM -0500, Conrad J. Sabatier wrote: On Tue, 15 May 2012 23:32:56 -0300 Raphael Kubo da Costa rak...@freebsd.org wrote: Conrad J. Sabatier conr...@cox.net writes: When did 2.8.8 make it into the ports repo? On May 3rd when I committed it :-) For reference, http://www.freshports.org/devel/cmake. How odd. I csup my local CVS repo regularly, and it hasn't turned up yet. May be time to switch mirrors. Well, another mystery solved. Just discovered that the script I've been running out of cron to update my local CVS repository had a typo in it, and csup wasn't being run at all. Not sure when that occurred exactly, but anyway... No wonder I hadn't seen any new versions of ports in a while. Doh! :-) -- Conrad J. Sabatier conr...@cox.net ___ 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: Problem building cmake
On Tue, 15 May 2012 22:31:09 -0300 Francisco Souza f...@souza.cc wrote: Hi there, I can't install cmake: # make install clean === Building for cmake-2.8.8 [ 2%] Built target cmIML_test [ 6%] Built target cmsys [ 7%] Built target cmsys_c [ 10%] Built target cmzlib [ 10%] Built target cmcompress [ 12%] Built target cmbzip2 [ 13%] Built target cmexpat [ 13%] Built target foo [ 22%] Built target cmForm [ 22%] Built target cmsysTestDynload [ 25%] Built target cmsysTestsCxx [ 25%] Built target cmsysTestProcess [ 26%] Built target cmsysTestSharedForward [ 26%] Built target cmsysTestsC [ 26%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/multi.c.o [ 45%] Built target cmlibarchive [ 46%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/parsedate.c.o [ 46%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/progress.c.o /usr/ports/devel/cmake/work/cmake-2.8.8/Utilities/cmcurl/multi.c:1708: error: expected declaration specifiers or '...' before numeric constant /usr/ports/devel/cmake/work/cmake-2.8.8/Utilities/cmcurl/multi.c:1710: error: conflicting types for 'curl_multi_socket_action' /usr/local/include/curl/multi.h:258: error: previous declaration of 'curl_multi_socket_action' was here *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 1 Stop in /usr/ports/devel/cmake. I'm using FreeBSD 8.3. Does anyone know this error? When did 2.8.8 make it into the ports repo? I'm still showing version 2.8.7 here, and I update my ports tree daily. Did you customize the Makefile yourself to build this later version? -- Conrad J. Sabatier conr...@cox.net ___ 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: Problem building cmake
On Tue, 15 May 2012 23:32:56 -0300 Raphael Kubo da Costa rak...@freebsd.org wrote: Conrad J. Sabatier conr...@cox.net writes: When did 2.8.8 make it into the ports repo? On May 3rd when I committed it :-) For reference, http://www.freshports.org/devel/cmake. How odd. I csup my local CVS repo regularly, and it hasn't turned up yet. May be time to switch mirrors. -- Conrad J. Sabatier conr...@cox.net ___ 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: Computer issues
On Mon, 23 Apr 2012 04:51:26 -0800 (AKDT) rfl...@acsalaska.net wrote: Hi, as some of you might have noticed, I've been absent lately. On a reboot my CPU fan decided to stop working. I should have a replacement computer in one or two weeks. Until then, my access is rather limited and without access to BSD. Have you tried opening up the case and dusting off the fan? This has happened to me before (I nearly had a heart attack when it did!), and after opening up the case and dusting off the fan blades, voila! It started working again. I'm a heavy cigarette smoker, so my computer is hardly in the healthiest environment for it. Periodic cleaning does help, though. YMMV, of course. :-) -- Conrad J. Sabatier conr...@cox.net ___ 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
Is imake broken with current xorg?
I'm seeing the following with any port that uses imake:
imake -DUseInstalled -I/usr/local/lib/X11/config
In file included from Imakefile.c:16:
In file included from /usr/local/lib/X11/config/Imake.tmpl:109:
/usr/local/lib/X11/config/FreeBSD.cf:451:35: error: '#' is not followed
by a macro parameter
#define IncludeMakefile(file) @@# dependencies are in .depend
^
In file included from Imakefile.c:16:
In file included from /usr/local/lib/X11/config/Imake.tmpl:316:
/usr/local/lib/X11/config/Imake.rules:1674:27: error: empty character
constant for flag in ${MAKEFLAGS} ''; do
\ @@\ ^
/usr/local/lib/X11/config/Imake.rules:1897:35: error: '#' is not
followed by a macro parameter
#define IncludeMakefile(file) @@# dependencies are in .depend
^
In file included from Imakefile.c:16:
/usr/local/lib/X11/config/Imake.tmpl:2144:10: fatal error: '
X11 .rules' file not found
#include ProjectRulesFile
^
/usr/local/lib/X11/config/Imake.tmpl:2142:35: note: expanded from:
# define ProjectRulesFile Concat3(,TopLevelProject,.rules)
^
/usr/local/lib/X11/config/Imake.rules:256:23: note: expanded from:
#define Concat3(a,b,c)a/**/b/**/c
^
4 errors generated.
imake: Exit code 1.
Stop.
Looks like imake doesn't play nice with our current xorg?
--
Conrad J. Sabatier
conr...@cox.net
___
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: Unexpected results from make index on a ports tree in a non-standard location,
On Mon, 05 Mar 2012 09:35:51 +
Matthew Seaman m.sea...@infracaninophile.co.uk wrote:
On 04/03/2012 23:28, Conrad J. Sabatier wrote:
Seems a little odd to me, but if that's the case, I guess I'll have
to make some adjustments to mkreadmes.
You could just make all the URL paths in README.html files relative to
the current location. Makes the question of what ${PORTSDIR} is set
to pretty much irrelevant.
Cheers,
Matthew
I've worked it out now. The only place the canonical path is needed is
when searching the index. Anywhere else, the real path is fine to use.
Turned out to be a very simple fix.
I uploaded mkreadmes-1.1.tar.bz2 to Sourceforge yesterday. Still
awaiting the port update's commit. Anyone using this thing really
should get the latest version, even if your ports tree is not in a
non-standard location, as I also added some checking of the index file
to catch any errors in the format of the lines. Two rather important
fixes.
http://sourceforge.net/projects/mkreadmes/files/mkreadmes-1.1.tar.bz2/download
--
Conrad J. Sabatier
conr...@cox.net
___
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: Unexpected results from make index on a ports tree in a non-standard location,
On Mon, 5 Mar 2012 07:16:00 -0600 Conrad J. Sabatier conr...@cox.net wrote: I've worked it out now. The only place the canonical path is needed is when searching the index. Anywhere else, the real path is fine to use. Turned out to be a very simple fix. I uploaded mkreadmes-1.1.tar.bz2 to Sourceforge yesterday. Still awaiting the port update's commit. Anyone using this thing really should get the latest version, even if your ports tree is not in a non-standard location, as I also added some checking of the index file to catch any errors in the format of the lines. Two rather important fixes. http://sourceforge.net/projects/mkreadmes/files/mkreadmes-1.1.tar.bz2/download Missed a bug that crept into the above version, a missing / in category pathnames. Darn it, wouldn't you know? This is what I get for submitting a patch after working all day on a port. :-) Final version, just uploaded to Sourceforge is now version 1.1.1: http://sourceforge.net/projects/mkreadmes/files/mkreadmes-1.1.1.tar.bz2/download Lesson learned. I *will* be more thorough in my testing from now on. :-) Sorry for the inconvenience, folks. Conrad -- Conrad J. Sabatier conr...@cox.net ___ 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
Error in INDEX file
While investigating the cause of sudden crashes this morning in mkreadmes, I discovered that my INDEX-10 file has the following as its first line: make: don't know how to make describe(continuing)|| Is anyone else seeing the same? Is there a general problem with index file creation at this time? Does anyone have a clue as to where the root of the problem may be? -- Conrad J. Sabatier conr...@cox.net ___ 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: Error in INDEX file
On Sun, 4 Mar 2012 13:33:44 -0600 Conrad J. Sabatier conr...@cox.net wrote: While investigating the cause of sudden crashes this morning in mkreadmes, I discovered that my INDEX-10 file has the following as its first line: make: don't know how to make describe(continuing)|| Is anyone else seeing the same? Is there a general problem with index file creation at this time? Does anyone have a clue as to where the root of the problem may be? Nevermind. Apparently, some error occurred during a CVS update of my ports tree, and ports-mgmt/porttools wound up with an empty Makefile, generating the above error message, which wound up in my INDEX-10 file because of the way I was invoking make index in my nightly ports maintenance cron job. Still, it did point up a need for more robustness in mkreadmes, so I suppose it was a fortuitous mistake. :-) -- Conrad J. Sabatier conr...@cox.net ___ 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: Error in INDEX file
On Sun, 4 Mar 2012 19:58:43 + b. f. bf1...@googlemail.com wrote: Conrad J. Sabatier conrads at cox.net wrote: While investigating the cause of sudden crashes this morning in mkreadmes, I discovered that my INDEX-10 file has the following as its first line: make: don't know how to make describe(continuing)|| ports/Tools/scripts/domakedescribe and some of the other scripts in the same directory can help solve such problems. b. Thanks, noted. I tracked it down to an empty port Makefile, probably the result of a cvs update error which I hadn't noticed (hadn't checked my cron logs yet). -- Conrad J. Sabatier conr...@cox.net ___ 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
Unexpected results from make index on a ports tree in a non-standard location,
To test mkreadmes handling of ports trees in non-standard locations, I just did the following: #cd /usr #mv ports /usr/local #cd /usr/local/ports #export PORTSDIR=/usr/local/ports #make index All seemed to proceed normally during the index build, but when I checked the resulting INDEX-10 file, all of the ports' paths were still using /usr/ports, not /usr/local/ports. Did I overlook something, or is there a defect in make index? -- Conrad J. Sabatier conr...@cox.net ___ 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: Unexpected results from make index on a ports tree in a non-standard location,
On Sun, 4 Mar 2012 17:20:36 -0600
Conrad J. Sabatier conr...@cox.net wrote:
To test mkreadmes handling of ports trees in non-standard locations, I
just did the following:
#cd /usr
#mv ports /usr/local
#cd /usr/local/ports
#export PORTSDIR=/usr/local/ports
#make index
All seemed to proceed normally during the index build, but when I
checked the resulting INDEX-10 file, all of the ports' paths were
still using /usr/ports, not /usr/local/ports.
Did I overlook something, or is there a defect in make index?
Ah, I just took a look at Tools/scripts/make_index, and found the
following:
# Save where we are so that we can map all directories formed
# from ${PORTSDIR} to their canonical location '/usr/ports/...'.
chomp($pwd = `pwd`);
# Read each line of output generated by the 'index' target.
while () {
chomp;
s/\015$//;
my @f = split(/\|/);
# Force to canonical form.
$f[1] =~ s!^$pwd!/usr/ports!o;
$f[4] =~ s!^$pwd!/usr/ports!o;
So, I take it, the index file is *supposed* to always map port paths to
/usr/ports, regardless of where the ports tree is actually located?
Seems a little odd to me, but if that's the case, I guess I'll have to
make some adjustments to mkreadmes.
--
Conrad J. Sabatier
conr...@cox.net
___
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: portupgrade - portmaster Rosetta Stone?
On Sat, 3 Mar 2012 07:15:23 -0500 Robert Huff roberth...@rcn.com wrote: Doug Barton writes: On 3/2/2012 11:06 PM, Conrad J. Sabatier wrote: Doug, is there a way to emulate portupgrade's -k (keep going) option, to have the remaining list of ports to be built still continue processing even if one port's build fails? You haven't missed it, the answer is no. It's part of that portmaster can't read minds problem that if something fails, I have no way of knowing if the rest of the updates should stop as a result. But ... isn't this a case where you don't have to read minds? It seems (to me) the user would be saying I understand the risk, and accept responsibility for dealing with the consequences.. At that point, whether thet're right or wrong is not your problem Robert Huff Yes, that's how I feel about it, myself, and it seems to have been the philosophy of the portupgrade author as well. Let the user shoot himself in the foot. :-) -- Conrad J. Sabatier conr...@cox.net ___ 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
How to submit a new port along with its distfile?
I'm ready to submit a new ports-mgmt port for a package I've written, but I need to have the distfile hosted on one of the FreeBSD sites (running an anonymous ftp server on my own machine would violate my ISP's TOS). How does one go about submitting a new port under these conditions? I need to submit both the port itself and the distfile. And should I set MASTER_SITES=LOCAL or MASTER_SITES=FREEBSD_ORG? Sorry, I couldn't find the answer to this one in the Porter's Handbook. Thanks! -- Conrad J. Sabatier conr...@cox.net ___ 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: How to submit a new port along with its distfile?
On Fri, 2 Mar 2012 10:43:38 -0500 Eitan Adler li...@eitanadler.com wrote: On Fri, Mar 2, 2012 at 10:23 AM, Chris Rees utis...@gmail.com wrote: On 2 Mar 2012 13:15, Conrad J. Sabatier conr...@cox.net wrote: I'm ready to submit a new ports-mgmt port for a package I've written, but I need to have the distfile hosted on one of the FreeBSD sites (running an anonymous ftp server on my own machine would violate my ISP's TOS). How does one go about submitting a new port under these conditions? I need to submit both the port itself and the distfile. And should I set MASTER_SITES=LOCAL or MASTER_SITES=FREEBSD_ORG? Sorry, I couldn't find the answer to this one in the Porter's Handbook. Thanks! Normally you need to find someone prepared to host it for you. Why not use a google code project or something like that? You gave me an idea: I put it up on Sourceforge. About to submit the port now. Thanks! -- Conrad J. Sabatier conr...@cox.net ___ 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: How to submit a new port along with its distfile?
On Fri, 2 Mar 2012 11:00:17 -0600 Conrad J. Sabatier conr...@cox.net wrote: On Fri, 2 Mar 2012 10:43:38 -0500 Eitan Adler li...@eitanadler.com wrote: On Fri, Mar 2, 2012 at 10:23 AM, Chris Rees utis...@gmail.com wrote: On 2 Mar 2012 13:15, Conrad J. Sabatier conr...@cox.net wrote: I'm ready to submit a new ports-mgmt port for a package I've written, but I need to have the distfile hosted on one of the FreeBSD sites (running an anonymous ftp server on my own machine would violate my ISP's TOS). How does one go about submitting a new port under these conditions? I need to submit both the port itself and the distfile. And should I set MASTER_SITES=LOCAL or MASTER_SITES=FREEBSD_ORG? Sorry, I couldn't find the answer to this one in the Porter's Handbook. Thanks! Normally you need to find someone prepared to host it for you. Why not use a google code project or something like that? You gave me an idea: I put it up on Sourceforge. About to submit the port now. Thanks! Just thought I'd follow up on this while I'm waiting to have the port reviewed: If anyone's interested, the package is call mkreadmes-1.0. It's a C language version of the port's collection's make readmes (or, if you will, the perl make_readmes script under the Tools directory). I wrote this because I was very dissatisfied with the speed of rebuilding the README.html files after I update my ports tree. This new tool I've written cuts the time down to practically nothing. I can now rebuild all the README.html files for the entire ports tree in less than 30 seconds. Depending on system load, I've actually seen it run in as little as @ 15 seconds. If you want to try it before it becomes an official port, it's already available on Sourceforge right now. It should compile and install very easily on any FreeBSD system, even without the port framework wrapper. The source archive is available at: http://sourceforge.net/projects/mkreadmes/files/mkreadmes-1.0.tar.bz2/download A README file is included in the distribution. Online help is also available via the -h command line option. Please don't hesitate to send me any questions, comments, suggestions, bug reports, etc. Enjoy! -- Conrad J. Sabatier conr...@cox.net ___ 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: portupgrade - portmaster Rosetta Stone?
On Mon, 27 Feb 2012 07:57:02 -0800 Doug Barton do...@freebsd.org wrote: On 02/27/2012 02:18, Olivier Smedts wrote: Now I only need to find a way to ignore the errors when creating a backup package if there was a plist problem That's in the man page. :) Doug, is there a way to emulate portupgrade's -k (keep going) option, to have the remaining list of ports to be built still continue processing even if one port's build fails? I've been trying to figure out how to do this, but it eludes me. -- Conrad J. Sabatier conr...@cox.net ___ 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
[patch] ports/*/Makefile: move missorted SUBDIR lines
Submitter-Id: current-users Originator:Conrad J. Sabatier Organization: Confidential: no Synopsis: [patch] ports/*/Makefile: move missorted SUBDIR lines Severity: non-critical Priority: low Category: ports Class: change-request Release: FreeBSD 10.0-CURRENT amd64 Environment: System: FreeBSD serene.no-ip.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sun Feb 12 19:15:46 CST 2012 conr...@serene.no-ip.org:/usr/obj/usr/src/sys/CUSTOM amd64 Description: A few of the ports categories' Makefiles contain missorted entries. I discovered this while working on a new tool I'm writing in C to speed up the rebuilding of the ports README.html files. Other ports tools or make targets may be affected by this missorting as well. How-To-Repeat: N/A Fix: patch below --- ports-Makefiles.diff begins here --- Index: /usr/ports/audio/Makefile === RCS file: /home/ncvs/ports/audio/Makefile,v retrieving revision 1.1211 diff -u -r1.1211 Makefile --- /usr/ports/audio/Makefile 7 Feb 2012 06:39:52 - 1.1211 +++ /usr/ports/audio/Makefile 23 Feb 2012 07:02:19 - @@ -303,8 +303,8 @@ SUBDIR += icegenerator SUBDIR += ices SUBDIR += ices0 -SUBDIR += id3el SUBDIR += id3ed +SUBDIR += id3el SUBDIR += id3lib SUBDIR += id3mtag SUBDIR += id3ren Index: /usr/ports/devel/Makefile === RCS file: /home/ncvs/ports/devel/Makefile,v retrieving revision 1.4870 diff -u -r1.4870 Makefile --- /usr/ports/devel/Makefile 21 Feb 2012 20:02:35 - 1.4870 +++ /usr/ports/devel/Makefile 23 Feb 2012 07:04:39 - @@ -3780,8 +3780,8 @@ SUBDIR += rubygem-templater SUBDIR += rubygem-test SUBDIR += rubygem-test-unit -SUBDIR += rubygem-thrift SUBDIR += rubygem-thor +SUBDIR += rubygem-thrift SUBDIR += rubygem-tilt SUBDIR += rubygem-tins SUBDIR += rubygem-transactionsimple Index: /usr/ports/japanese/Makefile === RCS file: /home/ncvs/ports/japanese/Makefile,v retrieving revision 1.792 diff -u -r1.792 Makefile --- /usr/ports/japanese/Makefile19 Feb 2012 20:10:02 - 1.792 +++ /usr/ports/japanese/Makefile23 Feb 2012 07:16:29 - @@ -156,8 +156,8 @@ SUBDIR += less SUBDIR += libicq SUBDIR += libjcode -SUBDIR += libslang SUBDIR += libskk +SUBDIR += libslang SUBDIR += libtomoe-gtk SUBDIR += lipsf SUBDIR += lookup Index: /usr/ports/net-im/Makefile === RCS file: /home/ncvs/ports/net-im/Makefile,v retrieving revision 1.164 diff -u -r1.164 Makefile --- /usr/ports/net-im/Makefile 18 Jan 2012 07:43:03 - 1.164 +++ /usr/ports/net-im/Makefile 23 Feb 2012 07:16:00 - @@ -173,10 +173,10 @@ SUBDIR += tkabber-devel SUBDIR += tkabber-plugins SUBDIR += tkabbur -SUBDIR += turpial SUBDIR += tmsnc SUBDIR += trix SUBDIR += ttytter +SUBDIR += turpial SUBDIR += twirssi SUBDIR += twitmail SUBDIR += vacuum-im Index: /usr/ports/net-mgmt/Makefile === RCS file: /home/ncvs/ports/net-mgmt/Makefile,v retrieving revision 1.278 diff -u -r1.278 Makefile --- /usr/ports/net-mgmt/Makefile17 Feb 2012 17:22:20 - 1.278 +++ /usr/ports/net-mgmt/Makefile23 Feb 2012 07:15:19 - @@ -157,8 +157,8 @@ SUBDIR += net-snmp SUBDIR += netams SUBDIR += netams-front -SUBDIR += netdisco-mibs SUBDIR += netdisco +SUBDIR += netdisco-mibs SUBDIR += netleak SUBDIR += netmask SUBDIR += netmond Index: /usr/ports/sysutils/Makefile === RCS file: /home/ncvs/ports/sysutils/Makefile,v retrieving revision 1.1381 diff -u -r1.1381 Makefile --- /usr/ports/sysutils/Makefile16 Feb 2012 18:06:06 - 1.1381 +++ /usr/ports/sysutils/Makefile23 Feb 2012 07:14:36 - @@ -485,8 +485,8 @@ SUBDIR += mapchan SUBDIR += massadmin SUBDIR += mbmon -SUBDIR += mcollective SUBDIR += mcelog +SUBDIR += mcollective SUBDIR += mcron SUBDIR += mcweject SUBDIR += mdcp Index: /usr/ports/www/Makefile === RCS file: /home/ncvs/ports/www/Makefile,v retrieving revision 1.3135 diff -u -r1.3135 Makefile --- /usr/ports/www/Makefile 22 Feb 2012 03:41:01 - 1.3135 +++ /usr/ports/www/Makefile 23 Feb 2012 07:13:26 - @@ -1708,8 +1708,8 @@ SUBDIR += rubygem-typhoeus SUBDIR += rubygem-uglifier SUBDIR += rubygem-unicorn -SUBDIR += rubygem-url_escape SUBDIR += rubygem-url-mount +SUBDIR += rubygem-url_escape SUBDIR
Duplicate INDEX entries of long standing
I've been seeing the following it seems like forever in my nightly scheduled ports tree maintenance script output: Starting rebuild of INDEX-10 at Mon Feb 13 03:52:55 CST 2012 Generating INDEX-10 - please wait..Warning: Duplicate INDEX entry: gdb-insight-6.6 Warning: Duplicate INDEX entry: petsc-mpich-2.3.3.p0_6,1 Done. Rebuild of INDEX-10 completed at Mon Feb 13 04:10:29 CST 2012 Anyone know what's the story with these? And/or how to get rid of them? Are there any plans in the works to remove them from the ports tree, or otherwise fix them? Thanks! -- Conrad J. Sabatier conr...@cox.net ___ 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: Duplicate INDEX entries of long standing
On Mon, 13 Feb 2012 12:39:34 + Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 13/02/2012 11:44, Conrad J. Sabatier wrote: I've been seeing the following it seems like forever in my nightly scheduled ports tree maintenance script output: Starting rebuild of INDEX-10 at Mon Feb 13 03:52:55 CST 2012 Generating INDEX-10 - please wait..Warning: Duplicate INDEX entry: gdb-insight-6.6 Warning: Duplicate INDEX entry: petsc-mpich-2.3.3.p0_6,1 Done. Rebuild of INDEX-10 completed at Mon Feb 13 04:10:29 CST 2012 Anyone know what's the story with these? And/or how to get rid of them? Are there any plans in the works to remove them from the ports tree, or otherwise fix them? Duplicates like this are usually a result of setting variables in /etc/make.conf. This causes the package name of some ports to change, and that can result in pkgname conflicts. The conflict arises when eg. you have a master-slave setup, where the slave port is used to provide a different set of default options. So, for instance one of the packages you highlight is petsc-mpich-2.3.3.p0_6,1 That package would normally be obtained from math/petsc-mpich: # cd math/petsc-mpich # make -V PKGNAME petsc-mpich-2.3.3.p0_6,1 but you can also end up with the same pkg name from math/petsc by setting WITH_MPI: # cd math/petsc # make -DWITH_MPI -V PKGNAME petsc-mpich-2.3.3.p0_6,1 Cheers, Matthew Hmm, you got me looking around for something like that, and I just discovered some files under /usr/local/etc that I had no idea even existed, with names starting with mpi*. Checking them out right now. Thanks, you've definitely got me on track here, I think. -- Conrad J. Sabatier conr...@cox.net ___ 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: BSD make -- Malformed conditional
On Fri, 27 Jan 2012 16:05:37 +
Matthew Seaman m.sea...@infracaninophile.co.uk wrote:
Dear all,
Posting this mostly for the archives, but it's probably relevant to
some people here too.
When hacking on Makefiles, should you wish to match an item in a list,
you might write something like this:
.for item in ${LIST}
.if ${item} == ${THING} # Ooops!
THING_FOUND= 1
.endif
.endfor
This however is a snare and a delusion, and will lead to much weeping
and wailing, and error messages like so:
% make
Makefile, line 7: Malformed conditional (foo == ${THING})
Makefile, line 9: if-less endif
Makefile, line 7: Malformed conditional (bar == ${THING})
Makefile, line 9: if-less endif
Makefile, line 7: Malformed conditional (baz == ${THING})
Makefile, line 9: if-less endif
Makefile, line 7: Malformed conditional (blurfl == ${THING})
Makefile, line 9: if-less endif
make: fatal errors encountered -- cannot continue
Instead you should write your loops like this:
.for item in ${LIST}
.if ${THING} == ${item}
THING_FOUND=1
.endif
.endfor
As the make(1) manual page says on the subject of string comparisons
using == or != :
An expression may also be a numeric or string comparison: in
this case, the left-hand side must be a variable expansion, whereas
the right-hand side can be a constant or a variable expansion.
So it seems that despite appearing and behaving almost exactly like
one, the iterator in a .for loop is not actually a variable as such.
It also means that to match a constant string, you can't just write:
.for item in ${LIST}
.if ${item} == this # Ooops
THIS_FOUND=1
.endif
.endfor
but have to assign the text this to a variable somewhere, and use
the second form.
Yes, you can use ${LIST:Mthis} instead, but using this construct can
be a bit tricky in itself...
% cat Makefile
LIST= foo bar baz blurfl
THING=baz
all:
@echo OK \$${LIST:Mfoo} = ${LIST:Mfoo}
@echo Not OK \$${LIST:M\$${THING}} = ${LIST:M${THING}}
% make
OK ${LIST:Mfoo} = foo
Not OK ${LIST:M${THING}} = }
Cheers,
Matthew
Wow, that is a pretty obscure bit of an oddity, isn't it? How'd you
ever discover that?
Looking at the man page, it seems more than a little misleading, as it
does call the iterator in .for loops a variable (which for all
intents and purposes, I'd say that it is, in fact). One could easily
lose one's marbles trying to debug something like this!
Looks like a bug, smells like a bug to me. Or at least, some *very*
quirky behavior/a serious design flaw that surely wouldn't be missed,
were someone to take the initiative to change it. hint-hint No
language should require you to jump through this sort of torturous,
totally anti-intuitive hoop to accomplish what you want to do. Talk
about your POLA! :-)
--
Conrad J. Sabatier
conr...@cox.net
___
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: BSD make -- Malformed conditional
On Fri, 3 Feb 2012 21:29:15 +
Chris Rees cr...@freebsd.org wrote:
On 3 February 2012 21:20, Conrad J. Sabatier conr...@cox.net wrote:
On Fri, 27 Jan 2012 16:05:37 +
Matthew Seaman m.sea...@infracaninophile.co.uk wrote:
Dear all,
Posting this mostly for the archives, but it's probably relevant to
some people here too.
When hacking on Makefiles, should you wish to match an item in a
list, you might write something like this:
.for item in ${LIST}
.if ${item} == ${THING} # Ooops!
THING_FOUND= 1
.endif
.endfor
This however is a snare and a delusion, and will lead to much
weeping and wailing, and error messages like so:
% make
Makefile, line 7: Malformed conditional (foo == ${THING})
Makefile, line 9: if-less endif
Makefile, line 7: Malformed conditional (bar == ${THING})
Makefile, line 9: if-less endif
Makefile, line 7: Malformed conditional (baz == ${THING})
Makefile, line 9: if-less endif
Makefile, line 7: Malformed conditional (blurfl == ${THING})
Makefile, line 9: if-less endif
make: fatal errors encountered -- cannot continue
Instead you should write your loops like this:
.for item in ${LIST}
.if ${THING} == ${item}
THING_FOUND= 1
.endif
.endfor
As the make(1) manual page says on the subject of string
comparisons using == or != :
An expression may also be a numeric or string comparison: in
this case, the left-hand side must be a variable expansion, whereas
the right-hand side can be a constant or a variable expansion.
So it seems that despite appearing and behaving almost exactly like
one, the iterator in a .for loop is not actually a variable as
such. It also means that to match a constant string, you can't
just write:
.for item in ${LIST}
.if ${item} == this # Ooops
THIS_FOUND=1
.endif
.endfor
but have to assign the text this to a variable somewhere, and use
the second form.
Yes, you can use ${LIST:Mthis} instead, but using this construct
can be a bit tricky in itself...
% cat Makefile
LIST= foo bar baz blurfl
THING= baz
all:
@echo OK \$${LIST:Mfoo} = ${LIST:Mfoo}
@echo Not OK \$${LIST:M\$${THING}} = ${LIST:M${THING}}
% make
OK ${LIST:Mfoo} = foo
Not OK ${LIST:M${THING}} = }
Cheers,
Matthew
Wow, that is a pretty obscure bit of an oddity, isn't it? How'd you
ever discover that?
Looking at the man page, it seems more than a little misleading, as
it does call the iterator in .for loops a variable (which for all
intents and purposes, I'd say that it is, in fact). One could
easily lose one's marbles trying to debug something like this!
Looks like a bug, smells like a bug to me. Or at least, some *very*
quirky behavior/a serious design flaw that surely wouldn't be
missed, were someone to take the initiative to change it.
hint-hint No language should require you to jump through this
sort of torturous, totally anti-intuitive hoop to accomplish what
you want to do. Talk about your POLA! :-)
Judging by the sheer volume of Makefiles out there that quite possibly
rely on this 'bug' for some things, it's not worth fixing ;)
Just think of it as yet another quirk of make.
Chris
Yeah, doggone it. Isn't that so often the case (some anomaly that could
really use changing not being changed because it's already so deeply
entrenched)?
I can just imagine, though, the poor unsuspecting souls who've run
head-on into something like this, never to be seen or heard from again,
until they one day quietly turn up in bathrobe and slippers in places
with names like Sunny Valley or Pleasant Pastures, muttering
endlessly to themselves about l-values and expansions and the like,
while tirelessly performing the Thorazine Shuffle.
Oh, the humanity!
--
Conrad J. Sabatier
conr...@cox.net
___
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: Good source for linux libs
On Thu, 02 Feb 2012 17:03:50 +0100 Dominic Fandrey kamik...@bsdforen.de wrote: I need some linux libraries to throw in with a port of Eagle6. http://www.freebsd.org/cgi/query-pr.cgi?pr=164581 I'm Linux illiterate, does anyone know a good source for all of these: - libpng14.so.14 - libssl.so.1.0.0 - libcrypto.so.1.0.0 - libjpeg.so.8 With good source I mean something that qualifies as a respectable MASTER_SITE like some Linux distro that packs the right versions of the libraries. I'm afraid I might also need a different glibc version, but I'll burn that bridge when I cross it. Check /usr/ports/Mk/bsd.sites.mk for the definitions of all of the Linux repositories used by the ports collection. -- Conrad J. Sabatier conr...@cox.net ___ 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: ImageMagick: tests fail on freebsd 10
On Wed, 11 Jan 2012 11:41:47 +0200 Andriy Gapon a...@freebsd.org wrote: For me the ImageMagick build on FreeBSD 10 amd64 fails at the tests stage. Is anyone else seeing this? A snippet from the build output: make check-TESTS check-local PASS: tests/validate-compare.sh PASS: tests/validate-composite.sh PASS: tests/validate-convert.sh PASS: tests/validate-identify.sh PASS: tests/validate-import.sh PASS: tests/validate-montage.sh PASS: tests/validate-pipe.sh PASS: tests/validate-stream.sh FAIL: tests/validate-formats-in-memory.sh FAIL: tests/validate-formats-on-disk.sh PASS: Magick++/tests/exceptions.sh PASS: Magick++/tests/appendImages.sh FAIL: Magick++/tests/attributes.sh PASS: Magick++/tests/averageImages.sh PASS: Magick++/tests/coalesceImages.sh PASS: Magick++/tests/coderInfo.sh PASS: Magick++/tests/colorHistogram.sh PASS: Magick++/tests/color.sh FAIL: Magick++/tests/montageImages.sh PASS: Magick++/tests/morphImages.sh PASS: Magick++/tests/readWriteBlob.sh PASS: Magick++/tests/readWriteImages.sh PASS: Magick++/demo/analyze.sh PASS: Magick++/demo/button.sh FAIL: Magick++/demo/demo.sh PASS: Magick++/demo/flip.sh PASS: Magick++/demo/gravity.sh PASS: Magick++/demo/piddle.sh PASS: Magick++/demo/shapes.sh PASS: Magick++/demo/zoom_bessel.sh PASS: Magick++/demo/zoom_blackman.sh PASS: Magick++/demo/zoom_box.sh PASS: Magick++/demo/zoom_catrom.sh PASS: Magick++/demo/zoom_cubic.sh PASS: Magick++/demo/zoom_gaussian.sh PASS: Magick++/demo/zoom_hamming.sh PASS: Magick++/demo/zoom_hanning.sh PASS: Magick++/demo/zoom_hermite.sh PASS: Magick++/demo/zoom_lanczos.sh PASS: Magick++/demo/zoom_mitchell.sh PASS: Magick++/demo/zoom_point.sh PASS: Magick++/demo/zoom_quadratic.sh PASS: Magick++/demo/zoom_sample.sh PASS: Magick++/demo/zoom_scale.sh PASS: Magick++/demo/zoom_sinc.sh PASS: Magick++/demo/zoom_triangle.sh PASS: wand/drawtest.sh FAIL: wand/wandtest.sh === 6 of 48 tests failed See ./test-suite.log Some sample errors from e.g. tests/validate-formats-in-memory.log: validate: must specify image size `/var/tmp/magick-dAxdiuDX' @ error/cmyk.c/ReadCMYKImage/142. validate: Bogus sampling factors `' @ error/jpeg.c/JPEGErrorHandler/297. I'm getting something similar under CURRENT (amd64), regardless of which compiler I use (base system gcc, gcc 4.6 or clang), but it's the exceptions test that's failing for me here: = ImageMagick 6.7.4: ./test-suite.log = 1 of 48 tests failed. .. contents:: :depth: 2 FAIL: Magick++/tests/exceptions.sh (exit: 1) Checking for working exceptions (may crash) ... Throwing 'Magick::WarningResourceLimit' exception Successfully caught 'Magick::WarningResourceLimit' exception Throwing library 'Magick::Exception' exception Successfully caught library 'Magick::Exception' exception Bogus catch: Caught exception: exceptions: mutex lock failed (Invalid argument) -- Conrad J. Sabatier conr...@cox.net ___ 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: A new and better way to do make readmes?
[ Sorry to be so late in following up on this; lost track for a while ] On Sat, 28 Jan 2012 16:53:17 + Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 28/01/2012 16:28, Conrad J. Sabatier wrote: rubbing eyes in disbelief Am I understanding you correctly? Are you saying you built 20,000+ port READMEs in only 9 seconds?! How is that possible? Or do you mean 9 seconds for each one? 9 seconds sounds quite reasonable for generating 23000 or so files. It sounds incredible to me! :-) Selective updating isn't going to help because 99.9% of the time is spent in the categories and it only takes a single port update to make a category file obsolete. This is the part I find troubling. It would seem that it should be more work to create an individual port README, with its plucking the appropriate line out of the INDEX-* file and then parsing it into its respective pieces and filling in a template, than to simply string together a list of references to a bunch of already built port READMEs into a category README. What am I not getting here? No -- you're quite right. You could generate the category README.html files entirely from the data in the INDEX. It's not quite as easy as all that, because there aren't entries for each category separately, so you'll have to parse the structure out of all of the paths in the INDEX. Well, the idea I had in mind was that, if all of the individual ports' README.html files already are in place, then it should be trivial to just ls or find them under each category to fill in the category's README.html. No need to reference the INDEX or anything else. Or??? The workaround method I've been running out of cron for the last month or so is: 1) Create a sentinel file under /tmp to use as a timestamp, just before running cvs update on ports (I update my ports tree from a local copy of the CVS repo maintained via csup) 2) After cvs completes, look for any port directories containing updates (check timestamps against the sentinel file) and do a make readme for each one: find $PORTSDIR -type f ! -path */CVS/* -newercm $SENTINEL -depth 3 | xargs dirname | sort -u | xargs -I@ /bin/sh -c cd @ make readme 3) Last, but not least, build the category README.html for any categories with ports containing newly updated README.html files. I have noticed while doing this that, as you mentioned, the category READMEs take considerably longer than the individual ports'. I don't even bother to rebuild the top-level file, since it's basically unchanging anyway. I think the way to speed this up is to have the script generate the category files too. There's no point in bringing in the top-level README since that's already fast. So what's making the category READMEs so slow then? The big problem with performance in all this INDEX and README.html building is that it takes quite a long time relatively to run make(1) within any port or category directory. make(1) has to read in a lot of other files and stat(2) many more[*] -- all of which involves a lot of random-access disk IO, and that's always going to take quite a lot of time. Now, doing 'make readme' in a category directory doesn't just run make in that directory, but also in every port in that category. Popular categories can contain many hundreds of ports. I'm a little rusty on the actual mechanics of make, but shouldn't it be possible to run a single, over-arching make on each category that wouldn't need to spawn a bunch of sub-makes? Maybe I should add README.html generation to my FreeBSD::Portindex stuff. Should be pretty simple -- all the necessary bits are readily available and it is just a matter of formatting it as HTML and printing it out. Maybe? Whaddya mean, maybe? :-) Sounds like it would definitely be worth doing! Cheers, Matthew [*] Running 'make -dA' with maximum debug output is quite enlightening, as is running make under truss(1) Enlightening, perhaps. Sometimes overwhelming, is more like it. :-) -- Conrad J. Sabatier conr...@cox.net ___ 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: A new and better way to do make readmes?
On Sat, 28 Jan 2012 18:44:48 +0100 Torfinn Ingolfsen tin...@gmail.com wrote: Hello, On Sat, Jan 28, 2012 at 3:03 AM, Conrad J. Sabatier conr...@cox.net wrote: I've been thinking for a long time that we need a better way to do make readmes, one that would be properly integrated into our ports Mk infrastructure, to take advantage of make's ability to recognize which files are up-to-date and which really do need rebuilding. I like to make sure my README.html files are all up-to-date after my nightly ports tree update, but with the current scheme, that means either rebuilding *all* of the files in the tree, or (as I'm doing at present) using some sort of kludgey (kludgy?) workaround. So people are actually using the readme files? Are many people using them? I ask because I *never* use them (unless they are used by 'make search'?), I always use freshports.org (BTW, thanks for an excellent service!) when I need to find out anything about a port. Well, in actual practice, it's true, I don't use them a *lot*, but I do use them from time to time when I'm looking for a new port to install for a certain purpose. It's nice to have up-to-date README.html files locally when the need arises. But they sure are expensive to maintain currently. -- Conrad J. Sabatier conr...@cox.net ___ 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: [HEADSUP][CFT] pkgng beta1 is out
On Mon, 30 Jan 2012 13:39:30 +0100 Baptiste Daroussin b...@freebsd.org wrote: Hi, pkgng has just reached the beta phase, and has now found its way to the ports tree (disabled by default). [remainder of announcement snipped for brevity] A feature request: I've long wished that pkg_info -g would set the return value to indicate whether or not a package's plist contained any errors, rather than always returning 0. This would be extremely helpful when using pkg_info in a script. Thanks! -- Conrad J. Sabatier conr...@cox.net ___ 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: A new and better way to do make readmes?
On Thu, 2 Feb 2012 13:25:14 -0800 Jason Helfman jhelf...@e-e.com wrote: On Thu, Feb 02, 2012 at 03:21:37PM -0600, Conrad J. Sabatier thus spake: [snip] The workaround method I've been running out of cron for the last month or so is: 1) Create a sentinel file under /tmp to use as a timestamp, just before running cvs update on ports (I update my ports tree from a local copy of the CVS repo maintained via csup) 2) After cvs completes, look for any port directories containing updates (check timestamps against the sentinel file) and do a make readme for each one: find $PORTSDIR -type f ! -path */CVS/* -newercm $SENTINEL -depth 3 | xargs dirname | sort -u | xargs -I@ /bin/sh -c cd @ make readme 3) Last, but not least, build the category README.html for any categories with ports containing newly updated README.html files. I have noticed while doing this that, as you mentioned, the category READMEs take considerably longer than the individual ports'. I don't even bother to rebuild the top-level file, since it's basically unchanging anyway. [snip] Not to fancy, but I used this when I was updating the readmes to not break. #!/bin/sh cd /usr/ports for i in `make -V SUBDIR |sed s/local//g`; do for p in `make -C $i -V SUBDIR`; do echo $i/$p sudo make -C $i/$p readme ; done; done ~/readmes.log -jgh Interesting. I'll take a look at using that. Thanks! -- Conrad J. Sabatier conr...@cox.net ___ 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: A new and better way to do make readmes?
On Sat, 28 Jan 2012 14:37:34 + RW rwmailli...@googlemail.com wrote: On Fri, 27 Jan 2012 20:03:25 -0600 Conrad J. Sabatier wrote: I've been thinking for a long time that we need a better way to do make readmes, one that would be properly integrated into our ports Mk infrastructure, to take advantage of make's ability to recognize which files are up-to-date and which really do need rebuilding. This wont help and I think there's a better way that will make it up to 700 times faster. When a make readmes is done at the top-level, the top-level and category READMEs are created by make targets and the per port READMEs are created by a perl script in one go from the INDEX-n file. I once timed this and the 64 category READMEs took 2 hours, but the ~20,000 port READMEs only took about 9 seconds. rubbing eyes in disbelief Am I understanding you correctly? Are you saying you built 20,000+ port READMEs in only 9 seconds?! How is that possible? Or do you mean 9 seconds for each one? Selective updating isn't going to help because 99.9% of the time is spent in the categories and it only takes a single port update to make a category file obsolete. This is the part I find troubling. It would seem that it should be more work to create an individual port README, with its plucking the appropriate line out of the INDEX-* file and then parsing it into its respective pieces and filling in a template, than to simply string together a list of references to a bunch of already built port READMEs into a category README. What am I not getting here? I think the way to speed this up is to have the script generate the category files too. There's no point in bringing in the top-level README since that's already fast. So what's making the category READMEs so slow then? I've been toying with the idea of doing this, but have never got around to it. If anyone wants to have a go I think it would be sensible to write it in awk, since perl is no longer in the base system and the existing perl script isn't really complex enough to be worth hanging-on to. Oooo, awk! Been a while since I wrote any sizeable bit of code in it, but I do remember it was rather fun to work with. :-) I'm still not sure I read that paragraph above correctly, though (re: the times). :-) -- Conrad J. Sabatier conr...@cox.net ___ 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
A new and better way to do make readmes?
I've been thinking for a long time that we need a better way to do make readmes, one that would be properly integrated into our ports Mk infrastructure, to take advantage of make's ability to recognize which files are up-to-date and which really do need rebuilding. I like to make sure my README.html files are all up-to-date after my nightly ports tree update, but with the current scheme, that means either rebuilding *all* of the files in the tree, or (as I'm doing at present) using some sort of kludgey (kludgy?) workaround. I haven't actually started working on such an alternative method yet, because I didn't want to dedicate the time to such an effort without first checking to see how well it might be received by portmgr. I realize this might possibly entail a less-than-trivial change to our existing ports Mk infrastructure. Would the overhead incurred in terms of additional dependency lines mean the idea would most likely be nixed right out of the gate? I'd like to think that, if properly implemented, the impact would be negligible, and the potential benefits would make it well worthwhile. Thanks for any feedback, Conrad -- Conrad J. Sabatier conr...@cox.net ___ 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 -o behaves a little strangely (IMHO)
On Tue, 24 Jan 2012 22:01:33 +
Chris Rees cr...@freebsd.org wrote:
On 24 January 2012 20:31, Doug Barton do...@freebsd.org wrote:
On 01/24/2012 06:19, Conrad J. Sabatier wrote:
=== Gathering dependency list for lang/gcc46 from ports
=== Launching child to update gcc-4.4.7.2008 to
gcc-4.4.7.20120117
lang/gcc46 gcc-4.4.7.2008
(What is the preceding line -- with the -- and the similar one
below, supposed to be indicating exactly? If it means what I
think it does, then it seems as if portmaster is misinterpreting
the intention of the -o option)
No, it means that the ports framework is seeing 4.4 as a dependency
of 4.6 for some reason. I've seen that happen in the past when
non-base gcc was in use, but have never had anyone track down the
cause authoritatively. Obviously make.conf is a suspect, but I'm
assuming you already looked there.
Often happens when people stick USE_something into make.conf :)
(don't do that)
Chris
Hmmm, interesting. I do, in fact, have a USE_GCC=4.2+ line
in /etc/make.conf, conditional on ${.CURDIR} for certain ports that
just won't build with clang, which I'm using now as the default.
Doug seems to think, though, that it's something else within the ports
framework's handling of the gcc ports that's tripping up portmaster.
Not sure I even want to begin to try to track that one down. :-)
Anyway, thanks everybody for the feedback.
--
Conrad J. Sabatier
conr...@cox.net
___
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: Port libSwiften Request
On Wed, 25 Jan 2012 01:44:38 -0800 (PST) Jaret Bartsch jaretbart...@yahoo.ca wrote: Hi there. I have recently tried to compile a software, but a port called libSwiften (on linux) is not available for FreeBSD as Swiften or libSwiften. Is it possible the ports team could perhaps include this software in the ports collection? Regards, Jaret Well, if it's portable, then I'm sure somebody here could handle it. Do you have a URL for the source and/or project? What package are you trying to compile yourself? Do you need porting help with that, too? -- Conrad J. Sabatier conr...@cox.net ___ 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 -o behaves a little strangely (IMHO)
The behavior of portmaster with -o new port dir in /usr/ports installed port (as the man page puts it), doesn't seem to be quite what one would expect. While endeavoring to upgrade the already installed lang/gcc44 to lang/gcc46 using the command: portmaster -CK -o lang/gcc46 gcc-4.4.7.2008 (I had already built, but not installed, gcc46, and didn't want any cleaning done before or after, just in case something went wrong) I got some rather unexpected results -- namely that, besides installing gcc46, portmaster wanted to do a normal upgrade of lang/gcc44 within its own directory (from version 4.4.7.2008 to 4.4.7.20120117). Only after adding the -i (interactive) option to the command line and answering the prompts did I get the desired operation, a direct upgrade of gcc44 to gcc46. I'm still in the process of acclimating myself to using portmaster, having used portupgrade for years (yes, I know, I'm a little late to the dance), so please bear with me if I'm coming across as a little dense, but... Is this the intended behavior? It strikes me as a little peculiar, portmaster's wanting to perform an entirely unnecessary (and unrequested) operation (the upgrade of the original port within its own directory). It seems to render the automated performance of this type of third party upgrade impossible. I'm really not grasping the logic of this arrangement. # portmaster -CK -o lang/gcc46 gcc-4.4.7.2008 === Port directory: /usr/ports/lang/gcc46 === Gathering dependency list for lang/gcc46 from ports === Launching child to update gcc-4.4.7.2008 to gcc-4.4.7.20120117 lang/gcc46 gcc-4.4.7.2008 (What is the preceding line -- with the -- and the similar one below, supposed to be indicating exactly? If it means what I think it does, then it seems as if portmaster is misinterpreting the intention of the -o option) === Port directory: /usr/ports/lang/gcc44 === Gathering dependency list for lang/gcc44 from ports === Initial dependency check complete for lang/gcc44 lang/gcc46 gcc-4.4.7.2008 === Continuing initial dependency check for lang/gcc46 === Initial dependency check complete for lang/gcc46 === The following actions will be taken if you choose to proceed: Install lang/gcc46 Upgrade gcc-4.4.7.2008 to gcc-4.4.7.20120117 === Proceed? y/n [y] (answered no here) === If you would like to upgrade or install some, but not all of the above try adding '-i' to the command line. Sign me Confused. :-) -- Conrad J. Sabatier conr...@cox.net ___ 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 -o behaves a little strangely (IMHO)
On Tue, 24 Jan 2012 09:21:05 -0500 Michael Scheidell scheid...@freebsd.org wrote: On 1/24/12 9:19 AM, Conrad J. Sabatier wrote: # portmaster -CK -o lang/gcc46 gcc-4.4.7.2008 what happens with: # portmaster -CK -o lang/gcc46 lang/gcc44 ? Well, since gcc44 is no longer installed, I just tried: portmaster -o lang/gcc47 lang/gcc46 And the actions that started were much more along the lines of what I was expecting. The build of gcc47 is currently underway as I write this. So, it seems it's not a good idea to mix and match port origins with port names in the case of this particular option. Could this be considered a bug? It certainly seems to at least qualify as a quirk, I would say. :-) -- Conrad J. Sabatier conr...@cox.net ___ 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 -o behaves a little strangely (IMHO)
On Tue, 24 Jan 2012 08:57:14 -0800 Kevin Oberman kob6...@gmail.com wrote: On Tue, Jan 24, 2012 at 7:14 AM, Conrad J. Sabatier conr...@cox.net wrote: On Tue, 24 Jan 2012 09:21:05 -0500 Michael Scheidell scheid...@freebsd.org wrote: On 1/24/12 9:19 AM, Conrad J. Sabatier wrote: # portmaster -CK -o lang/gcc46 gcc-4.4.7.2008 what happens with: # portmaster -CK -o lang/gcc46 lang/gcc44 ? Well, since gcc44 is no longer installed, I just tried: portmaster -o lang/gcc47 lang/gcc46 And the actions that started were much more along the lines of what I was expecting. The build of gcc47 is currently underway as I write this. So, it seems it's not a good idea to mix and match port origins with port names in the case of this particular option. Could this be considered a bug? It certainly seems to at least qualify as a quirk, I would say. :-) -- Conrad J. Sabatier conr...@cox.net I wanted to note is that you installed lang/gcc46, the development version of the compiler. It gets updated very frequently and you may want this, but it is probably better for most people to install lang/gcc which is the stable version of gcc-4.6. It gets updated only when a new gcc-4.6 version is released, so it does not get updated nearly so often. Posts that depend on USE_FORTRAN or USE_GCC=4.6+ will both be happy with lang/gcc, though they will pull in the development version if no gcc-4.6 is installed. Yes, I do recall now a lot of talk about 4.6 being subject to frequent change. Slipped my mind there for a bit. :-) I think I will back off to the other version. I mainly was interested in getting up to the minimum version needed to truly support my AMD Phenom 9550 processor (-march=amdfam10) the same way Clang does. Thanks for that info. -- Conrad J. Sabatier conr...@cox.net ___ 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 -o behaves a little strangely (IMHO)
On Tue, 24 Jan 2012 12:31:54 -0800 Doug Barton do...@freebsd.org wrote: On 01/24/2012 06:19, Conrad J. Sabatier wrote: === Gathering dependency list for lang/gcc46 from ports === Launching child to update gcc-4.4.7.2008 to gcc-4.4.7.20120117 lang/gcc46 gcc-4.4.7.2008 (What is the preceding line -- with the -- and the similar one below, supposed to be indicating exactly? If it means what I think it does, then it seems as if portmaster is misinterpreting the intention of the -o option) No, it means that the ports framework is seeing 4.4 as a dependency of 4.6 for some reason. I've seen that happen in the past when non-base gcc was in use, but have never had anyone track down the cause authoritatively. Obviously make.conf is a suspect, but I'm assuming you already looked there. What you probably have to do is pkg_delete -f 4.4, then do the same portmaster -o command but with 'lang/gcc44' as the second argument. Yes, using origin designators in both places worked. Is this an unwritten requirement in the case of the -o option? Anyway, moving merrily along... :-) Thanks! -- Conrad J. Sabatier conr...@cox.net ___ 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
libxfce4ui vs. libxfce4gui: wha'?
I just noticed the announcement for libxfce4ui version 4.9.0 and it got me wondering about something. In the FreeBSD ports collection, we have a libxfce4gui package (note the g up in there), but no libxfce4ui. Are we missing something that we should be available here? Could anyone please explain the difference between these two packages, and possibly why one of them is non-existent in the FreeBSD ports collection? Could this be the reason why I have no Arrange icons item on my desktop menu? Seems I used to have such an item, but after some port upgrades, it just went away, and I've been unable to resurrect it. Thanks for any clues on this! -- Conrad J. Sabatier conr...@cox.net ___ 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: x11/nvidia-{driver, settings, xconfig}: why not the latest available version (290.10)?
On Wed, 28 Dec 2011 15:37:25 -0600 Mark Linimon lini...@lonesome.com wrote: On Sat, Dec 24, 2011 at 04:33:58PM +, Alexey Dokuchaev wrote: On Sat, Dec 24, 2011 at 04:44:04PM +0800, Denise H. G. wrote: 290.10 has some issues on text redrawing as far I experience. I have also been running 290.10 for quite a while. Some apps, especially emacs and gnome-terminal will fail redrawing text areas while, e.g. scrolling. And x11 cursor cannot sometimes be displayed correctly. When I downgrade to 285.09.05, things seem to be OK. Yes, there are existing issues with their latest version, which delaying update of the port. But we'll get there, eventually. ;-) Perhaps an addition to http://wiki.freebsd.org/PortsNotUpgraded is in order? mcl Done! (thanks for the suggestion; first time I've contributed on the wiki). :-) -- Conrad J. Sabatier conr...@cox.net ___ 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: x11/nvidia-{driver, settings, xconfig}: why not the latest available version (290.10)?
On Sat, 24 Dec 2011 01:09:04 -0500 Eitan Adler li...@eitanadler.com wrote: On Sat, Dec 24, 2011 at 1:01 AM, Conrad J. Sabatier conr...@cox.net wrote: On Sat, 24 Dec 2011 04:09:23 + RW rwmailli...@googlemail.com wrote: On Fri, 23 Dec 2011 18:41:42 -0600 Conrad J. Sabatier wrote: As an aside, I've also been wondering for quite a while now why the nvidia-driver port isn't under the x11-drivers category, rather than simply x11. Not awfully important, just curious. :-) x11-drivers wasn't created until the monolithic xorg port was broken-up a few years ago. The nvidia-driver port predates that and it's just not been moved. Interesting. I didn't realize the nvidia-driver port had been around that long. Thanks for clearing up that (slightly) troubling mystery. :-) Also see http://www.freebsd.org/cgi/query-pr.cgi?pr=121930 Ah, thank you for that. Looks like some very sound reasoning. Makes sense to me now. I had a sort of vague notion it might be something along these lines, but danfe stated it very clearly. Cheers, Conrad -- Conrad J. Sabatier conr...@cox.net ___ 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: x11/nvidia-{driver, settings, xconfig}: why not the latest available version (290.10)?
On Sat, 24 Dec 2011 16:44:04 +0800
darc...@gmail.com (Denise H. G.) wrote:
On 2011/12/24 at 08:41, Conrad J. Sabatier conr...@cox.net wrote:
Hi,
Just wondering why the x11/nvidia-{driver,settings,xconfig} ports
have yet to be updated to the latest version (290.10). Are there
any known issues with any of these newer versions that would make
such an upgrade ill-advised?
FWIW, I've been running nvidia-driver version 290.10 since shortly
after it was made available on the Nvidia site, and haven't run
across any issues that can be directly attributed to the driver, at
least, not to the best of my knowledge.
290.10 has some issues on text redrawing as far I experience. I have
also been running 290.10 for quite a while. Some apps, especially
emacs and gnome-terminal will fail redrawing text areas while, e.g.
scrolling. And x11 cursor cannot sometimes be displayed correctly.
When I downgrade to 285.09.05, things seem to be OK.
Hmm. I do see the occasional redraw error, but since I'm constantly
fiddling with the latest bleeding-edge versions of things, including
nearly all of the Xorg-related packages (many parts of which I have
installed even later versions than those in the official FreeBSD
xorg-dev project), as well as much of the area51 KDE, *and* FreeBSD
10-CURRENT, I couldn't say for sure whether these were entirely the
fault of the nvidia driver or maybe the product of a combination of
things.
I may just back off to the earlier version and see what sort of a
difference it makes.
Thanks for the feedback. :-)
--
Conrad J. Sabatier
conr...@cox.net
___
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: x11/nvidia-{driver, settings, xconfig}: why not the latest available version (290.10)?
On Sat, 24 Dec 2011 16:33:58 +
Alexey Dokuchaev da...@freebsd.org wrote:
On Sat, Dec 24, 2011 at 04:44:04PM +0800, Denise H. G. wrote:
On 2011/12/24 at 08:41, Conrad J. Sabatier conr...@cox.net
wrote:
Just wondering why the x11/nvidia-{driver,settings,xconfig} ports
have yet to be updated to the latest version (290.10). Are there
any known issues with any of these newer versions that would make
such an upgrade ill-advised?
FWIW, I've been running nvidia-driver version 290.10 since
shortly after it was made available on the Nvidia site, and
haven't run across any issues that can be directly attributed to
the driver, at least, not to the best of my knowledge.
290.10 has some issues on text redrawing as far I experience. I have
also been running 290.10 for quite a while. Some apps, especially
emacs and gnome-terminal will fail redrawing text areas while, e.g.
scrolling. And x11 cursor cannot sometimes be displayed correctly.
When I downgrade to 285.09.05, things seem to be OK.
Yes, there are existing issues with their latest version, which
delaying update of the port. But we'll get there, eventually. ;-)
As an aside, I've also been wondering for quite a while now why
the nvidia-driver port isn't under the x11-drivers category,
rather than simply x11. Not awfully important, just curious. :-)
Short answer: because it is not just driver in xorg sense. For long
answer, see e.g. this:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/121930
Yes, Eitan directed me to that link yesterday. Makes perfect sense.
Theoretically, I could split the port into driver (kernel + xorg
server parts), libGL and linux compat libs; some GNU/Linux distros do
that. But I really prefer to maintain one port than keeping three or
five in sync. It makes sense if any of these subports could be used
independently, but this is not true at least for now.
Yes, of course. I'm sure the users as well would prefer not to have it
split into more than one port.
Thanks for the great work you've done already on this port. And Merry
Christmas! :-)
--
Conrad J. Sabatier
conr...@cox.net
___
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
x11/nvidia-{driver, settings, xconfig}: why not the latest available version (290.10)?
Hi,
Just wondering why the x11/nvidia-{driver,settings,xconfig} ports have
yet to be updated to the latest version (290.10). Are there any known
issues with any of these newer versions that would make such an upgrade
ill-advised?
FWIW, I've been running nvidia-driver version 290.10 since shortly after
it was made available on the Nvidia site, and haven't run across any
issues that can be directly attributed to the driver, at least, not to
the best of my knowledge.
As an aside, I've also been wondering for quite a while now why the
nvidia-driver port isn't under the x11-drivers category, rather than
simply x11. Not awfully important, just curious. :-)
--
Conrad J. Sabatier
conr...@cox.net
___
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: x11/nvidia-{driver, settings, xconfig}: why not the latest available version (290.10)?
On Sat, 24 Dec 2011 04:09:23 + RW rwmailli...@googlemail.com wrote: On Fri, 23 Dec 2011 18:41:42 -0600 Conrad J. Sabatier wrote: As an aside, I've also been wondering for quite a while now why the nvidia-driver port isn't under the x11-drivers category, rather than simply x11. Not awfully important, just curious. :-) x11-drivers wasn't created until the monolithic xorg port was broken-up a few years ago. The nvidia-driver port predates that and it's just not been moved. Interesting. I didn't realize the nvidia-driver port had been around that long. Thanks for clearing up that (slightly) troubling mystery. :-) -- Conrad J. Sabatier conr...@cox.net ___ 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: x11/xcb-util downgraded?
On Sat, 17 Dec 2011 11:18:04 + Chris Rees cr...@freebsd.org wrote: On 17 December 2011 10:47, Denise H. G. darc...@gmail.com wrote: Hi all With the version bump of x11/xcb-util, some ports seems to be broken. However, after recompiling x11/startup-notification, and all the ports that depend on x11/startup-notification, everything will be OK. And x11/startup-notification needs to be set to depend on x11/xcb-util, whose library is 'xcb-util.0' insead of 'xcb-aux.o'startup-notification Hope this will work. Thanks for reporting-- this problem is known [1] and affects many ports. A 'proper' solution will come soon! Chris Hmm, could this be why my attempt to upgrade claws-mail just now failed with: libtool: link: cannot find the library `/usr/local/lib/libxcb-aux.la' or unhandled argument `/usr/local/lib/libxcb-aux.la' gmake[4]: *** [claws-mail] Error 1 I checked and libxcb-aux.la indeed does not exist, although I did find an old *.so version under /usr/local/lib/compat/pkg. OK, I just rebuilt all of my *xcb* ports after making the suggested changes in x11/startup-notification and, sure enough, claws-mail now compiles successfully. Thanks! -- Conrad J. Sabatier conr...@cox.net ___ 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
pkg_version and portversion: ports version comparison weirdness
Can anyone explain why I'm seeing the following? libX11-1.4.99.1needs updating (index has 1.4.4,1) How is it that version 1.4.99.1 compares as less than 1.4.4,1? Since when is 99 4? Is it the PORTEPOCH in 1.4.4,1 that's throwing a monkey wrench into the works? This makes no sense to me. What is the logic being applied here? -- Conrad J. Sabatier conr...@cox.net ___ 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: pkg_version and portversion: ports version comparison weirdness
On Sun, 18 Dec 2011 10:06:48 -0800 Kevin Oberman kob6...@gmail.com wrote: On Sun, Dec 18, 2011 at 8:43 AM, Conrad J. Sabatier conr...@cox.net wrote: Can anyone explain why I'm seeing the following? libX11-1.4.99.1 needs updating (index has 1.4.4,1) How is it that version 1.4.99.1 compares as less than 1.4.4,1? Since when is 99 4? Is it the PORTEPOCH in 1.4.4,1 that's throwing a monkey wrench into the works? This makes no sense to me. What is the logic being applied here? Yes. When epoch increments it starts the versioning all over. Largest epoch value ALWAYS is considered newer that any smaller epoch value, regardless of the rest of the version number. I suspected that was the case, but wasn't sure exactly how the epoch setting was intended to be used. Epoch is normally used when a port needs to be rolled back to an older version due to a serious problem caused by the newer version. E.g. xcb-utils-3.6 broke a LOT of stuff, so the epoch was bumped to 1 and the version was set back to 3.6. Once a port has an epoch applied, it will never be removed. Ah, OK. Thank you. I had never really understood the meaning of the PORTEPOCH variable. Nice to finally have it explained. Regards, Conrad -- Conrad J. Sabatier conr...@cox.net ___ 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
astro/xephem: make readme failure
Submitter-Id: current-users Originator:Conrad J. Sabatier Organization: Confidential: no Synopsis: astro/xephem: make readme failure Severity: non-critical Priority: low Category: ports Class: sw-bug Release: FreeBSD 9.0-PRERELEASE amd64 Environment: System: FreeBSD serene.no-ip.org 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #0: Tue Dec 6 17:44:31 CST 2011 conr...@serene.no-ip.org:/usr/obj/usr/src/sys/CUSTOM amd64 Description: make readme in $PORTSDIR/astro/xephem fails as follows: root:/usr/ports/astro/xephem# make readme === Creating README.html for xephem-3.7.4_3printf: illegal option -- n usage: printf format [arguments ...] printf: illegal option -- n usage: printf format [arguments ...] printf: illegal option -- n usage: printf format [arguments ...] sed: 1: s|%%WEBSITE%%|*** Error ...: unescaped newline inside substitute pattern *** Error code 1 Stop in /usr/ports/astro/xephem. *** Error code 1 Stop in /usr/ports/astro/xephem. How-To-Repeat: cd /usr/ports/astro/xephem make readme Fix: (unknown) ___ 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
make readmes seems to be broken (again)
I've just noticed recently that make readmes in ports is acting up again (I reported a similar problem several months ago, which did get fixed at the time). Instead of generating a README.html at the top level, category level, and individual packages level, only the top-level and category-level files are being generated. No README.html files are being generated at the individual package level. I saw (and reported) this same behavior about four months ago, and it did, as I said, get fixed back then. No idea why it's suddenly broken again now. Can anyone confirm that it's not just a local problem for me, that it is indeed broken for everyone? Thanks! -- Conrad J. Sabatier conr...@cox.net ___ 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: Can't compile kde4 and kdelibs4 with an uptodate amd64 Releng machine. (
On Mon, 21 Nov 2011 23:19:08 +0100 Olivier Smedts oliv...@gid0.org wrote: 2011/11/21 Conrad J. Sabatier conr...@cox.net: I've been using the (undocumented, at least in /etc/make.conf) CPUTYPE?=native with no problems for quite some time now. Let gcc detect the processor type and generate the appropriate code. Eliminates any guesswork in trying to select the correct setting for CPUTYPE. CPUTYPE=native is not recognized by /usr/share/mk/bsd.cpu.mk (that's the real purpose of CPUTYPE, it does not only change the -march compiler setting). The proper way of doing what you're doing, after numerous tests and researchs, seems to be : CPUTYPE?=core2 (for example, to let /usr/share/mk/bsd.cpu.mk do its job) CFLAGS=-O2 -pipe -march=native (because you want the compiler to detect the cpu it's running on and optimize the code for it) NO_CPU_CFLAGS=yes (because you wanted to force the -march, you don't want another one to be added on the command line) COPTFLAGS=-O2 -pipe -march=native (same thing for kernel CFLAGS) NO_CPU_COPTFLAGS=yes This way, bsd.cpu.mk can set useful MACHINE_CPU for your CPUTYPE, but you let the compiler determine which processor to optimize the code for with the -march. I add NO_CPU_CFLAGS and NO_CPU_COPTFLAGS to be able to specify -march=native in the CFLAGS, cause it's different from CPUTYPE. Now why do I force -march=core2 and don't use -march=native ? Because our base gcc does not use the correct flags on my Core2 CPU if using -march=native : % /usr/bin/gcc -### -march=native md5.c Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] /usr/libexec/cc1 -quiet -D_LONGLONG md5.c -march=core2 -mtune=generic -quiet -dumpbase md5.c -auxbase md5 -o /var/tmp//ccYJKvGN.s /usr/bin/as -Qy -o /var/tmp//ccR6Lu5X.o /var/tmp//ccYJKvGN.s /usr/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib -L/usr/lib /var/tmp//ccR6Lu5X.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o See the -mtune=generic ? Crap ! You don't want that (manpage : Produce code optimized for the most common IA32/AMD64/EM64T processors. If you know the CPU on which your code will run, then you should use the corresponding -mtune option instead of -mtune=generic. But, if you do not know exactly what CPU users of your application will have, then you should use this option.) % /usr/bin/gcc -### -march=core2 md5.c Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] /usr/libexec/cc1 -quiet -D_LONGLONG md5.c -quiet -dumpbase md5.c -march=core2 -auxbase md5 -o /var/tmp//ccL8Bvk4.s /usr/bin/as -Qy -o /var/tmp//ccLrppPo.o /var/tmp//ccL8Bvk4.s /usr/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib -L/usr/lib /var/tmp//ccLrppPo.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o No -mtune=generic. According to the gcc manpage for the x86 arch, -march=core2 is sufficient to have proper values for -mtune, -mcpu... (Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type.) Strange, it seems to just work on my machine (note the -march and -mtune settings): $ /usr/bin/gcc -### -march=native hello.c Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] /usr/libexec/cc1 -quiet -D_LONGLONG hello.c -march=k8 -mtune=k8 -quiet -dumpbase hello.c -auxbase hello -o /tmp/ccAXYamu.s /usr/bin/as -Qy -o /tmp/ccIpMJgw.o /tmp/ccAXYamu.s /usr/bin/ld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib -L/usr/lib /tmp/ccIpMJgw.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o I've never seen any problems with this in src or ports makes, either. I do seem to recall having a look at bsd.cpu.mk a long, long time ago, and it appeared to me that it simply passed any unrecognized CPUTYPE through unchanged, which my experience does seem to bear out. -- Conrad J. Sabatier conr...@cox.net ___ 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: Can't compile kde4 and kdelibs4 with an uptodate amd64 Releng machine. (
On Mon, 21 Nov 2011 17:27:42 +0100 Olivier Smedts oliv...@gid0.org wrote: 2011/11/21 Conrad J. Sabatier conr...@cox.net: On Mon, 21 Nov 2011 07:42:43 -0600 eculp ec...@encontacto.net wrote: I have tried building both from the different ports and even more using portmaster and all stop ate similar locations in kdelabs4. Maybe there is something that I should or could build first. errors follow: kdelibs stops here: Generating kurlnavigator.moc Generating moc_kdiroperatordetailview_p.cpp [ 1%] Built target kfile_automoc Scanning dependencies of target kdeinit_kconf_update_automoc Scanning dependencies of target docbookl10nhelper_automoc [ 1%] Built target kdeinit_kconf_update_automoc [ 1%] Built target docbookl10nhelper_automoc Scanning dependencies of target genshortcutents_automoc Scanning dependencies of target kio_ghelp_automoc [ 1%] Built target genshortcutents_automoc [ 1%] Built target kio_ghelp_automoc Scanning dependencies of target kio_help_automoc Scanning dependencies of target meinproc4_automoc [ 1%] Built target kio_help_automoc [ 1%] Built target meinproc4_automoc Scanning dependencies of target meinproc4_simple_automoc Scanning dependencies of target kio_file_automoc [ 1%] Built target meinproc4_simple_automoc I've got this behavior on the 2 desktop machines I use. kdepimlibs4 stops here: Scanning dependencies of target kimg_pcx_automoc Scanning dependencies of target kimg_pic_automoc [ 1%] Built target kimg_pcx_automoc [ 1%] Built target kimg_pic_automoc Scanning dependencies of target kimg_psd_automoc Scanning dependencies of target kimg_ras_automoc [ 1%] Built target kimg_psd_automoc [ 1%] Built target kimg_ras_automoc Scanning dependencies of target kimg_rgb_automoc Scanning dependencies of target kimg_tga_automoc [ 1%] Built target kimg_rgb_automoc [ 1%] Built target kimg_tga_automoc Scanning dependencies of target kimg_xcf_automoc Scanning dependencies of target kimg_xview_automoc [ 1%] Built target kimg_xview_automoc [ 1%] Built target kimg_xcf_automoc Scanning dependencies of target kdnssd_automoc Scanning dependencies of target krosscore_automoc Generating interpreter.moc Generating script.moc Generating action.moc Generating actioncollection.moc Generating manager.moc [ 1%] Built target krosscore_automoc So where are the errors? There are none in the output you posted. I think there's no error (if it's the same problem as mine). For me, the build process seems to stop/freeze randomly, most often after Built target XXX. It affects only KDE ports, no other qt4-qmake or cmake consumer. No CPU usage. No disk usage. No excessive or changing memory usage... I didn't report it earlier because I don't know how to debug this, and it did not seem to affect other users (until now). OK, I didn't get that point from the original poster. I was looking to see some actual error output. Here is the workaround I painfully used on my 2 desktop machines : # cd /usr/ports/x11/kde4 # make wait for a freeze... ^C # make wait for a freeze... ^C # make ... I maybe had to restart the build one or two hundred times to have a fully installed KDE4. Wow, painful is an understatement here, to say the least. :-) Have you tried using truss or ktrace to see what's going on when these freezes occur? You'll want to be sure to enable tracing descendents of the original make process as well. Ports makes, as you no doubt are aware, spawn numerous processes along the way. truss -f make (or) ktrace -i make See the man pages for other options you may want to use as well. ktrace, in particular, will produce *copious* output. You'll probably want to just do a tail on the generated ktrace.out file: kdump | tail -some number of lines | more I've got this behavior since KDE 4.7.X (4.7.2 and 4.7.3), I had no problems building KDE 4.6.X. I even tried deleting all ports, cleaning /usr/local, tried again. No change. Tried compiling all ports with gcc instead of clang, no change. Forced make jobs UNSAFE, no change. I use FreeBSD 9.0 amd64, system built with clang (are you ?). No, I only use the default system gcc: # gcc -v Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] %cat /etc/make.conf SVN_UPDATE=yes SVN=/usr/local/bin/svn CPUTYPE?=core2 I've been using the (undocumented, at least in /etc/make.conf) CPUTYPE?=native with no problems for quite some time now. Let gcc detect the processor type and generate the appropriate code. Eliminates any guesswork in trying to select the correct setting for CPUTYPE. KERNCONF=CORE CFLAGS=-O2 -pipe -march=core2 -fomit-frame-pointer There's no need to add -march= to CFLAGS, if you're setting CPUTYPE (that's what CPUTYPE is for). NO_CPU_CFLAGS=yes Why are you setting CPUTYPE
Re: cvs checkout ./. csup
On Tue, 15 Nov 2011 10:48:26 +0100
Matthias Apitz g...@unixarea.de wrote:
Since many years I'm fetching or updating /usr/ports with
# cd /usr
# setenv CVSROOT :pserver:anon...@anoncvs.fr.freebsd.org:/home/ncvs
# cvs checkout ports
and later do the updating just with:
# cd /usr/ports
# cvs update
# portupgrade -ai
The FreeBSD handbook describes (or recommends?) using 'csup' for
updating ports tree... What is the advantage (or reason, if any)?
Basically, for doing updates across the network, csup is the preferred
method (for reasons of efficiency and less strain on the server). If
you do need the versioning information provided by CVS (for example, to
create a diff to submit for a ports patch, or simply for convenient
access to the CVS history of a particular file), then you may want to
try the following method:
Use csup to maintain a local copy (default directory /home/ncvs) of the
parts of the CVS repo you need (src, ports, doc, etc.), using a modified
copy of /usr/share/examples/cvsup/cvs-supfile. You'll probably want to
setup a cron job to do this automatically at regular intervals.
Then use cvs to update your /usr/{src,ports,doc} trees from your local
copy of the CVS repo. Note that having a local CVS repo also eliminates the
need to use the pserver access method, if you're updating on the same
machine where the repo resides.
If you decide to do this, you'll need to remove your current working
{src,ports,doc} tree(s) and then do a 'cvs checkout' the first time
to setup the CVS-versioned tree(s). For example:
export CVSROOT=/home/ncvs
cd /usr
rm -rf ports
cvs checkout ports
After having done the initial checkout, you can then use cvs
update (or simply make update) to maintain the tree.
This gives you the best of both worlds: fast, efficient updates across
the network, while still providing access to all the versioning
features of CVS.
Hope this helps. :-)
--
Conrad J. Sabatier
conr...@cox.net
___
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: Update for x11-toolkits/swt-devel failed
On Mon, 24 Oct 2011 08:44:58 -0700 (PDT) Pedro F. Giffuni giffu...@tutopia.com wrote: The problem is that Leslie has webkit installed. There must be some configure flag to disable it but my desktop motherboard toasted so I cant look at it. No, the problem is -- or rather, was -- that the swt-devel package uses a script (build.sh) which automatically detects the presence of webkit and unconditionally includes it in the build, but something elsewhere within the package's build mechanism is broken with respect to webkit. The package in its current state simply doesn't offer any sort of option for the user to easily disable webkit in the build. Eitan just committed the patch I submitted to work around this problem the other day, so update your ports tree and give it another try. I say work around, because all my patch does is unconditionally disable the inclusion of webkit in the build for now. I have yet to dig down deeper and figure out exactly what's causing the breakage. Better than nothing, though, right? :-) -- Conrad J. Sabatier conr...@cox.net ___ 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: Update for x11-toolkits/swt-devel failed
On Sat, 5 Nov 2011 09:54:22 -0700 (PDT) Pedro F. Giffuni giffu...@tutopia.com wrote: Hmm... --- On Sat, 11/5/11, Conrad J. Sabatier wrote: I see.. thanks for working on this. I say work around, because all my patch does is unconditionally disable the inclusion of webkit in the build for now. I have yet to dig down deeper and figure out exactly what's causing the breakage. FWIW, the mozilla option is also broken. I think the best is to update the port to the latest version (3.7.1) and then look to see what is wrong with mozilla and webkit. Pedro. I was digging through the port last night, and have a few ideas on what needs doing, but haven't started yet. May take a little time. -- Conrad J. Sabatier conr...@cox.net ___ 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
portupgrade failure: kde4-4.7.2 -- kde4-4.7.2_1
OK, I know this is just a meta package, and not really essential to my survival, but nonetheless, I'm hitting a brick wall with this one: - -- The following OPTIONAL packages could NOT be located on your system. -- Consider installing them to enable more features from this software. - * Ruby http://www.ruby-lang.org An Interpreted object-oriented scripting language For KLinkStatus example ruby scripts - CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: RUBY_INCLUDE_PATH (ADVANCED) used as include directory in directory /usr/ports/www/kdewebdev4/work/kdewebdev-4.7.2/klinkstatus/src/plugins/scripting/scripts -- Configuring incomplete, errors occurred! *** Error code 1 Stop in /usr/ports/www/kdewebdev4. *** Error code 1 Stop in /usr/ports/www/kdewebdev4. *** Error code 1 Stop in /usr/ports/x11/kde4. *** Error code 1 Stop in /usr/ports/x11/kde4. *** Error code 1 Stop in /usr/ports/x11/kde4. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade2002-98506-i34x5l env RUBY_INCLUDE_PATH=/usr/local/include/ruby-1.9 UPGRADE_TOOL=portupgrade UPGRADE_PORT=kde4-4.7.2 UPGRADE_PORT_VER=4.7.2 make reinstall --- Restoring the old version ** Fix the installation problem and try again. [Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 1482 packages found (-0 +1) . done] ** Listing the failed packages (-:ignored / *:skipped / !:failed) ! x11/kde4 (kde4-4.7.2) (install error) On this last attempt, I tried to force the setting of RUBY_INCLUDE_PATH in the make environment. Made no difference whatsoever. ruby-1.9.2.290_2,1 *is* installed. # grep RUBY /etc/make.conf RUBY_DEFAULT_VER=1.9 RUBY_INCLUDE_PATH=/usr/local/include/ruby-1.9 # uname -a FreeBSD serene.no-ip.org 9.0-RC1 FreeBSD 9.0-RC1 #4: Mon Oct 31 19:06:02 CDT 2011 conr...@serene.no-ip.org:/usr/obj/usr/src/sys/CUSTOM amd64 I'm stumped for the moment. Anybody got a clue to share? -- Conrad J. Sabatier conr...@cox.net ___ 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
ktorrent-4.1.2_1 runtime failure at startup
Something very odd is going on here (whitespace between error messages inserted by me for clarity): $ ktorrent KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work I have no clue whatsoever what *that's* supposed to be about. ktorrent(2481)/KSharedDataCache ensureFileAllocated: This system misses support for posix_fallocate() -- ensure this partition has room for at least 10547296 bytes. This second message in particular is fairly perplexing. posix_fallocate does exist in the C library, I'm fairly certain. I only started seeing this behavior a few days ago, after an update of world/kernel. I've rebuilt ktorrent and many of its dependencies, but to no avail. It seems to be the only app generating this particular error. unnamed app(2480): Communication problem with ktorrent , it probably crashed. Error message was: org.freedesktop.DBus.Error.NoReply : Message did not receive a reply (timeout by message bus) Has anyone else run into anything like this (posix_fallocate) recently? $ uname -a FreeBSD serene.no-ip.org 9.0-RC1 FreeBSD 9.0-RC1 #4: Mon Oct 31 19:06:02 CDT 2011 conr...@serene.no-ip.org:/usr/obj/usr/src/sys/CUSTOM amd64 -- Conrad J. Sabatier conr...@cox.net ___ 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
Disregard original post (was Re: portupgrade failure: kde4-4.7.2 -- kde4-4.7.2_1)
Nevermind. Turning off the KDEWEBDEV option in x11/kde4 allowed the upgrade to succeed (forgot I had turned this on yesterday out of curiosity). I suppose, then, that the subject line of this thread should have been Build failure in www/kdewebdev4 instead. Sorry for the noise. -- Conrad J. Sabatier conr...@cox.net ___ 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: Unable to build swt-devel on systems with webkit-gtk2 installed
On Wed, 2 Nov 2011 15:56:26 -0700 Kevin Oberman kob6...@gmail.com wrote: Looking back in the archive I see several messages about problems building x11-toolkits/swt-devel on systems with webkit-gtk2 installed. All fail with: [exec] cc -shared -s -o libswt-awt-gtk-3659.so swt_awt.o -L/usr/local/diablo-jdk1.6.0/jre/lib/i386 -ljawt [exec] make: don't know how to make make_webkit. Stop Is there any hope of getting this fixed? I'm totally out of my depth to try to figure out what needs to be done. Yes, I grappled with this same problem recently. I finally threw my hands up and used a precompiled package instead (they can be a lifesaver at times). I generally do make a serious effort to work through any issues I encounter with ports before simply surrendering. Often, in the process, some other heretofore hidden problem comes to light, and the effort winds up yielding more than one benefit. Of course, it's hard to shake that nagging feeling when there's clearly something wrong somewhere on your system: if there's a package available for port X, then obviously it was buildable by someone, somewhere, so what the @%! is wrong with *my* machine? :-) -- Conrad J. Sabatier conr...@cox.net ___ 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: Unable to build swt-devel on systems with webkit-gtk2 installed
On Wed, 2 Nov 2011 21:56:27 -0400 Eitan Adler li...@eitanadler.com wrote: On Wed, Nov 2, 2011 at 9:10 PM, Conrad J. Sabatier conr...@cox.net wrote: On Wed, 2 Nov 2011 15:56:26 -0700 Kevin Oberman kob6...@gmail.com wrote: Looking back in the archive I see several messages about problems building x11-toolkits/swt-devel on systems with webkit-gtk2 installed. This is the problem. I don't have the time to investigate. Take a look into the configure script or something similar for a --disable-webkit option. If you email me a patch which fixes the problem I'll commit it. Of course, it's hard to shake that nagging feeling when there's clearly something wrong somewhere on your system: if there's a package available for port X, then obviously it was buildable by someone, somewhere, so what the @%! is wrong with *my* machine? :-) It isn't your machine, but it only affects machines with webkit installed. Automagical dependencies are the bane of packagers ;) Indeed they are. Oh, I missed that thread entirely somehow. Thanks, I'll take a look at that and get back to you later if I come up with a patch. -- Conrad J. Sabatier conr...@cox.net ___ 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
(Repost) Ports missing in their categories' Makefiles (revised list)
Sent this a couple of hours ago, but I haven't seen it on the list yet, so... After removing dead ports (ports dirs with no Makefile or anything else other than maybe a leftover README.html), the final list is: audio/x11amp databases/pgpool-II-30 games/xshisen graphics/tkimg japanese/dvi2tty japanese/plain2 www/linux-opera-devel www/pecl-yaf www/typo345 x11-drivers/xf86-video-intel29 x11-wm/cl-stumpwm -- Conrad J. Sabatier conr...@cox.net ___ 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 missing in their categories' Makefiles (revised list)
On Mon, 31 Oct 2011 19:56:48 -0500 Conrad J. Sabatier conr...@cox.net wrote: OK, the list is actually smaller than I had mentioned earlier. My first list included ports not mentioned in the categories' README.html files as well, which of course, generated a bogus list. Here's the final list I got: [snip] After removing dead ports (ports dirs with no Makefile or anything else other than maybe a leftover README.html), the final list is: audio/x11amp databases/pgpool-II-30 games/xshisen graphics/tkimg japanese/dvi2tty japanese/plain2 www/linux-opera-devel www/pecl-yaf www/typo345 x11-drivers/xf86-video-intel29 x11-wm/cl-stumpwm -- Conrad J. Sabatier conr...@cox.net ___ 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 missing in their categories' Makefiles
On Tue, 1 Nov 2011 01:19:37 -0400 Eitan Adler li...@eitanadler.com wrote: On Mon, Oct 31, 2011 at 8:56 PM, Conrad J. Sabatier conr...@cox.net wrote: OK, the list is actually smaller than I had mentioned earlier. My first list included ports not mentioned in the categories' README.html files as well, which of course, generated a bogus list. Here's the final list I got: Other than dvi2tty none of these ports appear to exist in a recent ports tree. Where are you generating this list from? Really? How odd! I've been csupping the CVS repo, and then CVS updating my local ports tree from that. I'll have to take a closer look at things here. Sorry for the wasted noise, folks. -- Conrad J. Sabatier conr...@cox.net ___ 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 not mentioned in their category's Makefile
On Tue, 1 Nov 2011 08:13:38 +0100 Erwin Lansing er...@freebsd.org wrote: On Mon, Oct 31, 2011 at 08:13:14PM -0400, Eitan Adler wrote: On Mon, Oct 31, 2011 at 7:20 PM, Conrad J. Sabatier conr...@cox.net wrote: I've generated a list of 57 ports that are not mentioned in the Makefiles for their respective categories. Before I do anything more with this information (like submit patches), though, I just wanted to check to see if there's any interest in correcting this. As I mentioned later, the actual list is really roughly half that number, due to bad methodology I was using at first. Please send the list to po...@freebsd.org. Keep in mind that some ports not listed may have been incomplete or aborted repocopies. There is no need to send patches, the fix is easy enough ;) Thanks for doing this and as you mention, this should be cleaned up as those ports won't be in INDEX, readme, build packages, etc. As Eitan mentioned, there are several valid reasons for this, usually as a temporary measure though. Those ports are also mentioned in the logs on pointyhat and occassionally someone from portmgr contacts the maintainers, but if you have some code available I'd be happy to set this up as a weekly reminder to maintainers. Erwin Sure, I'd be glad to. I just used a very simple little quick and dirty script to generate the list, but if you'd like something more elaborate, I'd be glad to expand on it. Would you like the output to include maintainer info, for instance? Anything you specify, I'll try to accommodate. Shell scripting is sort of one of my specialties, you might say. :-) I'd enjoy having a little project to work on here. Being retired these days does have its luxuries. :-) First, though, I need to verify my ports tree is truly up to date. As Eitan and Doug pointed out, I seem to have a bit of lingering cruft from ports that have been removed already. I suspect this may be due to my method of updating the tree via cvs from my local copy of the CVS repo. As part of my nightly ports tree maintenance, I also rebuild all of the README.html files, and I suspect that this is why I still have those lingering directories that should have been deleted, i.e., the -P switch (prune empty directories) has no effect because of the html files still being there. The script I used to generate the list simply (rather simplisticly) looked for directories under each category that weren't listed in that category's Makefile, hence, the erroneous results I posted earlier. Anyway, like I said, if you have any specifics you'd like me to include in this little project, please let me know. I'll be getting to work on it today. Thanks for the interest, and for the replies, everyone. -- Conrad J. Sabatier conr...@cox.net ___ 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 missing in their categories' Makefiles
[resend: sent to Doug, but forgot to include the list] On Mon, 31 Oct 2011 21:11:10 -0700 Doug Barton do...@freebsd.org wrote: Are you sure your ports tree is up to date? The first few ports you listed don't check out ... On 10/31/2011 17:56, Conrad J. Sabatier wrote: OK, the list is actually smaller than I had mentioned earlier. My first list included ports not mentioned in the categories' README.html files as well, which of course, generated a bogus list. Here's the final list I got: astro/weatherget Doesn't seem to exist? OK, you're right about that one. Deleted it from my ports tree just now. audio/x11amp Has CATEGORIES= audio Yes, but what I meant was that the Makefile for ports/audio has no mention of it, so index/readmes builds won't be correct. databases/pgpool-II-30 Has CATEGORIES= databases Likewise here. -- Conrad J. Sabatier conr...@cox.net ___ 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 missing in their categories' Makefiles (revised list)
On Tue, 1 Nov 2011 19:17:06 -0500 Mark Linimon lini...@lonesome.com wrote: Every time we portmgrs start a package run we get a list of these. The command to do so is make checksubdirs. You can run it in either the top-level /usr/ports, or in /usr/ports/category/ . Well, whaddya know? I just learned something new in FreeBSD that I was blissfully unaware of in my 15 years of usage. :-) On a fairly regular basis (but not every time) we prod the people who committed the ports. In most cases, it's a repocopy, where the repocopy is not yet finished (i.e. the new port's Makefile is identical to the old ports', and thus would break INDEX if connected.) Sometimes the commit to the Makefile is just forgotten. These were the ones I saw 20111027: audio/x11amp databases/pgpool-II-30 games/xshisen japanese/dvi2tty japanese/plain2 www/typo345 x11-drivers/xf86-video-intel29 x11-wm/cl-stumpwm I made a few more refinements this afternoon to the little script I had hacked together earlier (and cleaned up my ports tree to eliminate some of the bogus results I had gotten before), and wound up with the following results: x11amp not found in audio/Makefile pgpool-II-30 not found in databases/Makefile xshisen not found in games/Makefile tkimg not found in graphics/Makefile dvi2tty not found in japanese/Makefile plain2 not found in japanese/Makefile linux-opera-devel not found in www/Makefile pecl-yaf not found in www/Makefile typo345 not found in www/Makefile xf86-video-intel29 not found in x11-drivers/Makefile cl-stumpwm not found in x11-wm/Makefile The latter 2 I have asked about and was told we're still working on getting those ports into shape. However, they've been showing up on the list for quite some time now :-/ These must have been new since then: www/linux-opera-devel (committed by acm, no force commit yet) www/pecl-yaf (committed by sunpoet, force commit noted) I don't see this in the repository, or in the Makefile, so I'm confused: graphics/tkimg Yes, this directory contains nothing but a Makefile in my ports tree. No CVS dir or anything else. Not sure how that got that way. root:/usr/ports/graphics# cvs status tkimg cvs status: Examining tkimg cvs status: in directory tkimg: cvs [status aborted]: there is no version here; do 'cvs checkout' first I don't know why you didn't see this next one, it was deleted then brought back by hrs@ but not yet re-added to the Makefile: === games Warning: directory xbat not in SUBDIR A cvs status check on this one shows all files up to date, but... A-ha! I see a small bug in my script. The grep command I've been using found xbat in xbattle. :-) I'm also surprised you didn't see the following, it was a botch in the Makefile, which I have just fixed: === databases Warning: directory p5-KyotoCabinet not in SUBDIR OK, this one slipped by because my script didn't notice the typo in the Makefile (uUBDIR += instead of SUBDIR +=). I was doing a very simple-minded grep for the ports' directory names, which obviously is insufficient. Thanks for taking a look at these. More than welcome. Thanks for calling my attention to these oversights in my script, and for making me aware of the make checksubdirs target. :-) This has been a rather productive day for me. Cleaned up some problems in my ports tree that I wasn't even aware of before, and discovered in the process some further refinements I need to make to the script I was using to check these things. Of course, given that we already have a make target to do the job, my script is a tad redundant. Still, it's been an interesting exercise. :-) -- Conrad J. Sabatier conr...@cox.net ___ 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
Ports not mentioned in their category's Makefile
I've generated a list of 57 ports that are not mentioned in the Makefiles for their respective categories. Before I do anything more with this information (like submit patches), though, I just wanted to check to see if there's any interest in correcting this. For one thing, these omissions cause the README.html files to be incomplete, which alone, I think, warrants fixing this. Thanks for any feedback. -- Conrad J. Sabatier conr...@cox.net ___ 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
Ports missing in their categories' Makefiles
OK, the list is actually smaller than I had mentioned earlier. My first list included ports not mentioned in the categories' README.html files as well, which of course, generated a bogus list. Here's the final list I got: astro/weatherget audio/x11amp databases/pgpool-II-30 devel/boost-pyste devel/gccxml devel/py-myghtyutils devel/py-reverse devel/py-vmaps games/xshisen graphics/gnash-devel graphics/tkimg graphics/tumbler japanese/dvi2tty japanese/plain2 java/java-tutorial lang/smarteiffel net-p2p/transmisson-remote-gui sysutils/syslog-ng1 www/myghty www/linux-f10-flashplugin11 www/tomcat41 www/typo345 x11-drivers/xf86-video-intel29 x11-wm/cl-stumpwm x11-wm/fvwm2-devel -- Conrad J. Sabatier conr...@cox.net ___ 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: Update for x11-toolkits/swt-devel failed
On Thu, 20 Oct 2011 22:25:55 +0200 Leslie Jensen les...@eskk.nu wrote: 2011-10-20 21:37, Pedro Giffuni skrev: Hi leslie; make rmconfig And disable mozilla. Pedro. It was already disabled. I did make deinstall and the make reinstall and got a different error. Please see below. === Building for swt-devel-3.6.2,1 Buildfile: /usr/ports/x11-toolkits/swt-devel/work/build.xml init: build.classes: [javac] /usr/ports/x11-toolkits/swt-devel/work/build.xml:32: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [javac] Compiling 582 source files to /usr/ports/x11-toolkits/swt-devel/work/classes [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. build.nativeLibraries: [exec] make: don't know how to make make_webkit. Stop [exec] Model is amd64 [exec] libgnomeui-2.0 found, compiling SWT program support using GNOME [exec] Cairo found, compiling SWT support for the cairo graphics library. [exec] Using libxul for gecko support [exec] WebKit found, compiling webkit embedded browser support. [exec] libjawt.so found, the SWT/AWT integration library will be compiled. [exec] Building SWT/GTK+ for freebsd amd64 BUILD FAILED /usr/ports/x11-toolkits/swt-devel/work/build.xml:62: exec returned: 2 Total time: 7 seconds *** Error code 1 Stop in /usr/ports/x11-toolkits/swt-devel. *** Error code 1 Stop in /usr/ports/x11-toolkits/swt-devel. *** Error code 1 FWIW, I'm seeing exactly the same thing here, both with and without GECKO enabled. This is on a freshly updated amd64 9.0-RC1. -- Conrad J. Sabatier conr...@cox.net ___ 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: KDE3 de facto EOL, Project Trinity?
On Sun, 9 Oct 2011 07:53:30 -0700 (PDT) Jakub Lach jakub_l...@mailplus.pl wrote: Hello, Judging from latest commits, KDE3 moved swiftly from stall, but usable to explicitly unsupported. However, there are still areas, where KDE3 can't be replaced by newer version. (e.g. I maintain older pc that is mainly used as internet browser, where I installed slimmed subset of KDE3, to somehow make it behave like users would expect. Looking at state of KDE3 now, updating it borders on not worth breaking it.) Of course I understand, that workforce is limited, and everybody who is willing to commit time, will spend it on their pet-project. I'm just saying, that if anyone would like to still maintain a sane, slim subset of KDE3, Project Trinity looks like good starting point. http://trinitydesktop.org/ KDE is-not-exactly my pet-project so don't look at me :) best regards, - Jakub Lach Hmmm, for some strange reason, I just heard a line from that old Elvis Presley song Suspicious Minds in my head: Let's not let a good thing die... :-) -- Conrad J. Sabatier conr...@cox.net ___ 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: environment variables for portupgrade: /etc/make.conf or /usr/local/etc/pkgtools.conf?
On Mon, 3 Oct 2011 07:22:44 + (GMT)
Thomas Mueller mueller6...@bellsouth.net wrote:
But I still want to know where portupgrade gets environment
variables: /etc/make.conf, /usr/local/etc/pkgtools.conf (in
Ruby?), or other.
Tom
Set them in your shell's environment:
export PORTSDIR=/BETA1/usr/ports
export PACKAGES=/usr/packages
--
Conrad J. Sabatier
conr...@cox.net
Do I have to do this for every portupgrade command, or can I put
these environment variable settings in a file, like /etc/make.conf
or /usr/local/etc/pkgtools.conf ?
Put them in the rc file for your shell -- ~/{.bashrc,.shrc,.cshrc}
or ~/.profile.
I left /usr/local/etc/pkgtools.conf in the modified state, modified
lines being
ENV['PORTSDIR'] = '/BETA1/usr/ports'
ENV['PACKAGES'] = '/usr/packages'
# ENV['PORTSDIR'] ||= '/usr/ports'
# ENV['PACKAGES'] ||= ENV['PORTSDIR'] + '/packages'
I suppose I could do a portupgrade with -n flag to see if my setup
looks workable?
Sure, BTW, I think, if you do use the above in your pkgtools.conf, you
probably want to stick to using the same operators (||=) as the
examples. I don't know the ruby language well enough at all to comment
further.
--
Conrad J. Sabatier
conr...@cox.net
___
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: environment variables for portupgrade: /etc/make.conf or /usr/local/etc/pkgtools.conf?
On Sun, 2 Oct 2011 09:35:48 + (GMT) Thomas Mueller mueller6...@bellsouth.net wrote: How do I make environment variables used by portupgrade visible to portupgrade? Portupgrade evidently ignores /etc/make.conf, and editing /usr/local/etc/pkgtools.conf also fails to help. I want portupgrade to recognize PORTSDIR=/BETA1/usr/ports and PACKAGES=/usr/packages but continue to get cd: /usr/ports: No such file or directory cd: /usr/ports/ports-mgmt/portupgrade: No such file or directory when it should be looking for /BETA1/usr/ports I was in directory /BETA1/usr/ports/print/py-reportlab2 ; offending command was portupgrade -o py-reportlab2 py-reportlab | tee portupg.log I think that should have been portupgrade -o print/py-reportlab2 print/py-reportlab | tee portupg.log That failed because print/py-reportlab had already been built and installed, so I had to pkg_delete it, then build py-reportlab2 without portupgrade. Problem arose because py-reportlab2, a dependency of print/hplip, was broken (did not package), and I subsequently built and installed py-reportlab . after a later portsnap fetch update, I decided to go back to print/py-reportlab2 . But I still want to know where portupgrade gets environment variables: /etc/make.conf, /usr/local/etc/pkgtools.conf (in Ruby?), or other. Tom Set them in your shell's environment: export PORTSDIR=/BETA1/usr/ports export PACKAGES=/usr/packages -- Conrad J. Sabatier conr...@cox.net ___ 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: Replacing procmail with maildrop
On Thu, 29 Sep 2011 05:55:24 +1000 andrew clarke m...@ozzmosis.com wrote: Thanks for that. Looks like I'll be migrating across to maildrop in the next week or so :-) Something you may want to add is that if you use Maildir format and have this in ~/.procmailrc: DEFAULT=$HOME/Maildir/ You need the equivalent for maildrop's ~/.mailfilter: DEFAULT=$HOME/Maildir/ Without this, messages that were not filtered (ie. fell through) will be appended to the mbox file, /var/mail/$USER. On a similar note, if you use MH-style mail folders, something like this: DEFAULT=| rcvstore +inbox (with a properly set PATH, of course) Once I actually set about in earnest today to convert my .procmailrc to .mailfilter format, I was amazed how easy it turned out to be. My one remaining little bug-a-boo is with maildrop's logging; it wants to overwrite the log on each invocation instead of appending. Still no clue how to fix that. But otherwise, the transition was really a breeze, and is working just fine. -- Conrad J. Sabatier conr...@cox.net ___ 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: Replacing procmail with maildrop
On Sun, 25 Sep 2011 22:01:13 -0600 (MDT)
Warren Block wbl...@wonkity.com wrote:
Recent discussion here about the desirability of replacing procmail
finally convinced me to switch to maildrop. It turned out to be
relatively painless. I took some notes that may be helpful for
others considering the change:
http://www.wonkity.com/~wblock/docs/html/maildrop.html
Thank you for that! I've been reluctant to switch from procmail to
anything else just yet (although I know I'll have to do so eventually,
if this port is going to be expired), but these tips you've provided
certainly will help.
I'm just wondering, though, if you could offer any advice on how
to convert something like the following procmail recipe I use for my
FreeBSD mailing lists.
I like to store my FreeBSD lists each under a separate MH folder under
$MAILDIR/FreeBSD, so the following recipe strips off everything
outside the angle brackets in the List-Id header (including the
brackets themselves, of course), and then the trailing .freebsd.org
and leading freebsd- and from the actual list name, to derive the
correct folder name.
So, for instance. the list name freebsd-ports.freebsd.org winds up as
the folder name ports.
One problem is, without procmail's formail utility, how to
extract and strip the List-Id header. Does maildrop include a tool
similar to formail? Also, can one define a custom to command, in
order to use the nmh rcvstore command?
I've included only the parts of my .procmailrc needed to provide a
clear picture of what's going on:
# Path to executables from the nmh package
NMH_PATH=/usr/local/libexec/nmh
# Make sure everything we need is here
PATH=/bin:/usr/bin:/usr/local/bin:${NMH_PATH}
# Probably not necessary, but doesn't hurt either
MAILDIR=${HOME}/Mail
SHELL=/bin/sh
# the nmh command to store mail into a folder
STORE=rcvstore
# extension to use for lockfiles
LOCKEXT=.lock
# recipe for FreeBSD lists
:0
* ^List-Id:.*freebsd.org
{
ListId=`formail -c -x List-Id: | \
sed -e 's/^.*//' -e 's/.*$//' \
-e 's/\.freebsd\.org//' \
-e 's/^freebsd-//'`
:0:FreeBSD$LOCKEXT
| $STORE +FreeBSD/${ListId}
}
Thanks in advance for any help!
--
Conrad J. Sabatier
conr...@cox.net
___
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: Replacing procmail with maildrop
On Mon, 26 Sep 2011 03:45:17 -0500 Matthew D. Fuller fulle...@over-yonder.net wrote: On Mon, Sep 26, 2011 at 02:43:50AM -0500 I heard the voice of Conrad J. Sabatier, and lo! it spake thus: I'm just wondering, though, if you could offer any advice on how to convert something like the following procmail recipe I use for my FreeBSD mailing lists. I work off the envelope sender, but you can adapt it. Maildrop gives you subexpression matches. if($RETPATH =~ /^owner-freebsd-([^@]+)/) to $MBOXDIR/f-$MATCH1 (of course, the cvs list ends up having to be special cased) So you'd just match the List-ID header similarly, something like if(/^List-ID: freebsd-([a-z]+).freebsd.org/) to FreeBSD/$MATCH1 (totally untested of course...) OK, I'm starting to get a little better of an idea of what to do. My main concern so far has been the ability to nest a set of commands within a recipe the way procmail allows. I don't want to use the full list name as it appears in the List-Id header, but a simpler, pared down version of it. This was fairly easy to do in procmail; I just have to work out the correct syntax for doing it with maildrop. I see now that the maildrop package includes a formail-like equivalent, reformail, so that's good news. Looks like it won't be all that difficult at all, really, to convert my existing recipes. Will just have to spend some more time familiarizing myself with the maildrop rc file format/syntax and getting used to the differences between it and procmail. Thanks! -- Conrad J. Sabatier conr...@cox.net ___ 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: Replacing procmail with maildrop
On Mon, 26 Sep 2011 03:45:17 -0500 Matthew D. Fuller fulle...@over-yonder.net wrote: On Mon, Sep 26, 2011 at 02:43:50AM -0500 I heard the voice of Conrad J. Sabatier, and lo! it spake thus: I'm just wondering, though, if you could offer any advice on how to convert something like the following procmail recipe I use for my FreeBSD mailing lists. I work off the envelope sender, but you can adapt it. Maildrop gives you subexpression matches. if($RETPATH =~ /^owner-freebsd-([^@]+)/) to $MBOXDIR/f-$MATCH1 (of course, the cvs list ends up having to be special cased) So you'd just match the List-ID header similarly, something like if(/^List-ID: freebsd-([a-z]+).freebsd.org/) to FreeBSD/$MATCH1 (totally untested of course...) Oh, I see now! So the match result on the parenthesized subexpression will, in fact, be exactly what I'm looking for already. No more need to manually strip away all the unwanted stuff with sed, as I was doing for procmail. No need for [re]formail, either. Neat-o! :-) Thanks again. -- Conrad J. Sabatier conr...@cox.net ___ 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: Replacing procmail with maildrop
On Mon, 26 Sep 2011 04:16:01 -0500
Matthew D. Fuller fulle...@over-yonder.net wrote:
On Mon, Sep 26, 2011 at 04:07:31AM -0500 I heard the voice of
Conrad J. Sabatier, and lo! it spake thus:
OK, I'm starting to get a little better of an idea of what to do.
My main concern so far has been the ability to nest a set of
commands within a recipe the way procmail allows.
Well, it's C-like; you can put braces around the body of the if and
have however much you want inside there.
I don't want to use the full list name as it appears in the List-Id
header, but a simpler, pared down version of it. This was fairly
easy to do in procmail; I just have to work out the correct syntax
for doing it with maildrop.
What I had there
if(/^List-ID: freebsd-([a-z]+).freebsd.org/)
to FreeBSD/$MATCH1
should give you (mod bugs in my top-of-my-head'ing of course) the same
sorta result as your
:0
* ^List-Id:.*freebsd.org
{
ListId=`formail -c -x List-Id: | \
sed -e 's/^.*//' -e 's/.*$//' \
-e 's/\.freebsd\.org//' \
-e 's/^freebsd-//'`
:0:FreeBSD$LOCKEXT
| $STORE +FreeBSD/${ListId}
}
in that it winds up in FreeBSD/[the stuff between freebsd- and
.freebsd.org]. Except without forking off a bunch of external
programs, just to pull out a piece of a header :p
Yes, I realized that just moments after my last reply. Somehow
that went right over my head at first. :-)
I like this already! Thanks again.
Conrad
--
Conrad J. Sabatier
conr...@cox.net
___
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
Rarely seen portlint errors
While checking the ports tree for ports which need to have their CPPFLAGS moved out of the CONFIGURE_ENV variable, I noticed a number of errors from the perl interpreter re: the use of uninitialized variables in portlint. In every case, portlint still appears to run to normal completion and produce normal diagnostics, but I thought you may be interested in trying to eliminate the cause of these errors. I've attached a list of the ports where these errors occurred along with their respective error messages, as well as the bash script I was running at the time. Thank you. -- Conrad J. Sabatier conr...@cox.net portlint-errs Description: Binary data find-ports-needing-cppflags-fix Description: Binary data ___ 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 with CPPFLAGS in CONFIGURE_(ARGS|ENV)
On Mon, 19 Sep 2011 08:47:25 -0400 b. f. bf1...@googlemail.com wrote: OK. Just a few more questions: portlint -A issues no warning in the case of CPPFLAGS being added to CONFIGURE_ARGS. Should I concern myself only with CONFIGURE_ENV, or would it be best to modify in either case? Either case. There are slight differences in the handling of variables passed in the environment (as is done by default for CPPFLAGS), and variables passed on the command-line (as is done for variables assigned in CONFIGURE_ARGS), but they are usually unimportant. Most occurrences of CPPFLAGS in CONFIGURE_ARGS are either mistakes or anachronisms. Right, OK. Also, is there any possibility of either CONFIGURE_ENV or CONFIGURE_ARGS being used in some non-standard fashion, i.e., with anything other than a GNU configure script, meaning they should just be left alone? Of course that is possible, although such a usage would probably be rare, if it occurs at all. You should only be concerned about the case when: --HAS_CONFIGURE is defined (note that HAS_CONFIGURE can be implied by other things, like GNU_CONFIGURE, XORG_CAT, USE_AUTOTOOLS, USE_PHPIZE, and USE_PHPEXT); and --the default do-configure target has not been overridden; because that is when CPPFLAGS is passed in the environment to the configure script. See bsd.port.mk. b. Thank you, that was very informative. I'm definitely going to have to scrutinize bsd.port.mk and friends more closely to better my understanding of how these variables are actually handled, to avoid any potential pitfalls. Final tally (as of this writing) of ports flagged by portlint: 1,521. That's only for the CONFIGURE_ENV cases. I think, for now, I'll limit myself to those. The edgier cases may just bog me down too much initially. Once I've succeeded in doing the initial basic cleanup, it will be a little easier to zoom in on the more specialized cases. I'm already somewhat daunted by the sheer number of ports needing attention. Fortunately, though, many of the occurrences are identical (or very nearly so) in format, so it should be possible to devise some automated tools to handle a large number of them. Luckily for me, I'm retired now, and have *lots* of free time. Can't think of a more productive way to spend it than by giving back to the project I've come to know and love over the last 15 years. -- Conrad J. Sabatier conr...@cox.net ___ 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
Ports with CPPFLAGS in CONFIGURE_(ARGS|ENV)
I did a check yesterday to see how many ports in the tree still have CPPFLAGS defined in either the CONFIGURE_ARGS or CONFIGURE_ENV variable. There are still quite a few, I'm afraid. Anyway, I was wondering how best to go about rectifying this (admittedly minor) problem. I don't want to bombard the pr system with a flurry of individual reports/patches, but I'm not sure I want to pester each and every maintainer about this either. So, what would be a good approach? Any suggestions? -- Conrad J. Sabatier conr...@cox.net ___ 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 with CPPFLAGS in CONFIGURE_(ARGS|ENV)
On Sun, 18 Sep 2011 20:04:32 -0400 Eitan Adler li...@eitanadler.com wrote: So, what would be a good approach? Any suggestions? Prepare a patch and get a committer to ask portmgr@ for approval. I volunteer if you need someone. Do you mean one gigantic, monolithic patch that would amend all of them, or a large set of individual patches (last I checked, there were ~1453 ports in need of this sort of revision)? I could go either way, just need to know which would be preferred. Thanks! -- Conrad J. Sabatier conr...@cox.net ___ 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 with CPPFLAGS in CONFIGURE_(ARGS|ENV)
On Sun, 18 Sep 2011 21:38:46 -0400 Eitan Adler li...@eitanadler.com wrote: Do you mean one gigantic, monolithic patch that would amend all of them, or a large set of individual patches (last I checked, there were ~1453 ports in need of this sort of revision)? I could go either way, just need to know which would be preferred. One monolithic patch (preferably generated with cvs diff -Nu) OK. Just a few more questions: portlint -A issues no warning in the case of CPPFLAGS being added to CONFIGURE_ARGS. Should I concern myself only with CONFIGURE_ENV, or would it be best to modify in either case? Also, is there any possibility of either CONFIGURE_ENV or CONFIGURE_ARGS being used in some non-standard fashion, i.e., with anything other than a GNU configure script, meaning they should just be left alone? Just trying to avoid any potential gotchas. Thanks again. -- Conrad J. Sabatier conr...@cox.net ___ 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: Removed ports - looking from the bench
On Sun, 11 Sep 2011 14:35:47 -0600 (MDT) Warren Block wbl...@wonkity.com wrote: If archival of old historical distfiles is needed, that's not really a FreeBSD problem. Start a new project with its own website. Quick, somebody register deadports.org![4] LOL. Love the name! Wonder if it's already taken. :-) -- Conrad J. Sabatier conr...@cox.net ___ 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: deprecated because: Development has ceased??? Maybe development is *complete*
On Sat, 10 Sep 2011 10:40:29 +0400 Ruslan Mahmatkhanov cvs-...@yandex.ru wrote: I think that http://translate.google.com is a best of them :) And there is firefox addons for it. I had to laugh at one of the Spanish translations I got from Microsoft Translator on a site I was using (MT was one of three engines provided on this particular site). The phrase was I'll be right back. Microsoft's translation: I'll be back derecho. (I mean, how lame is *that*?) :-) But if you need local dictionary, take a look at textproc/goldendict, it able to look in both local files, and many online sources like urbandictionary. Thanks for the suggestions. I will take a look at those. -- Conrad J. Sabatier conr...@cox.net ___ 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 deprecations (was: sysutils/cfs)
On Sat, 10 Sep 2011 12:24:33 +0200 Matthias Andree matthias.and...@gmx.de wrote: Am 10.09.2011 07:45, schrieb Conrad J. Sabatier: Frankly, I'm growing increasingly concerned that this push to eliminate ports is getting out of control. I don't much care for the notion that, having invested the time in installing, configuring and tuning a certain set of software packages, suddenly the rug could be pulled out from under me, so to speak, in essence *forcing* me to abandon using certain packages or else deal with maintaining them (in the ports maintainer sense) on my own. The rug is pulled by the upstream maintainers abandoning their software, not by FreeBSD no longer packaging it years after the fact. While I understand the reasoning behind this, I still feel that as long as a package continues to build and run without any known issues, then why be in a rush to drop it? The argument that the ports collection is not a museum is valid to some degree, but if a package is still usable (and useful), then aren't we shooting ourselves in the foot by dropping it? Conrad, (courtesy Cc: after changed subject, please reply to the list) I'd see that as proactive maintenance. If there is no upstream maintainer any more, chances is that one time the port needs code changes to adapt to changes in underlying libraries. For the sake of argument, let's assume this example (I'm not sure if libpng would be a real-world instance of it, I didn't care enough to have a closer look): There are points in time when dead port X using a changed library Y needs code changes, for instance, if library Y in some old unmaintained version is vulnerable, and its fixed versions have a different API. Now, if we tell people soon enough that they may run into that problem, chances are that people never hit the problem, and chances are that people hit the problem soon - and the fewer users of the dead port are forced to make the switch, the better. The open question is, is there a point in marking a point DEPRECATED without giving an expiration date. My personal answer is no because no-one will believe in a DEPRECATED tag without EXPIRATION_DATE and people will be disappointed because they've grown used to custom and practice and I can already see the we told you it was DEPRECATED. The real point is that the FreeBSD ports system can not fill in for the maintainers of discontinued ports. There is a certain pragmatism to as long as it builds, appears to work, and there are no known critical bugs, let's keep it, but it has this organizational drawback that it becomes custom and practice at some time, and ends up hurting more people in the end. Yes, I understand what you're saying, and I don't disagree at all, really. I'm coming to realize that I initially overestimated the extent of this latest round of ports cleanups. It seemed enormous at first, but then, looking back over some of the announcements containing the lists of ports due for deletion, I see now that it's really nowhere near as extensive as my initial impression led me to think. So, basically, I'm cool with what's going on. I did do some checking through the lists one more time last night, and put in a few requests to assume maintainership of some ports that I did think were perhaps being prematurely scheduled for removal, but overall, I have no objections whatsoever to the remainder of the them being dropped, and certainly am not interested in investing the time or effort to see what may need to be done to save them. The majority simply aren't worth it, IMHO. :-) Thanks. I'm glad we do, in fact, see eye-to-eye on this. And as usual, the policy FreeBSD has in place on this matter *is*, in fact, a sane, sensible and practical one. Please excuse me if I did, for a moment, appear to be having a knee-jerk reaction. :-) Take care, Conrad -- Conrad J. Sabatier conr...@cox.net ___ 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: sysutils/cfs
On Thu, 08 Sep 2011 18:54:36 +0200 Matthias Andree mand...@freebsd.org wrote: Am 08.09.2011 13:52, schrieb Matt Burke: I want machines, tools, to do as *I* say not the other way round, whether it's good for me or not. If I wanted nannying and interference, I'd install Ubuntu. No, you'd use a managed installation. Nobody stands there pointing a gun at your head and forces you to uninstall a port that got removed from the ports/ tree. If people could recognize that, it might help get the derailed discussion back on the right track. You fail to take into account the case where a port may need to be reinstalled. An extraordinary effort is required if the port no longer exists in the ports tree. Frankly, I'm growing increasingly concerned that this push to eliminate ports is getting out of control. I don't much care for the notion that, having invested the time in installing, configuring and tuning a certain set of software packages, suddenly the rug could be pulled out from under me, so to speak, in essence *forcing* me to abandon using certain packages or else deal with maintaining them (in the ports maintainer sense) on my own. It feels like this latest ports collection cleanup effort most likely started with the best intentions, but is now fast becoming a runaway locomotive. Please, can we try to maintain the sanity and restraint that FreeBSD has always been known for? -- Conrad J. Sabatier conr...@cox.net ___ 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
deprecated because: Development has ceased??? Maybe development is *complete*
On Wed, 7 Sep 2011 08:33:08 +0200 (CEST) lini...@freebsd.org wrote: portname: german/ksteak description:KDE frontend for steak, an english - german dictionary maintainer: po...@freebsd.org deprecated because: Development has ceased. expiration date:2011-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=germanportname=ksteak portname: german/steak description:An english - german dictionary under the GPL maintainer: po...@freebsd.org deprecated because: Development has ceased. expiration date:2011-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=germanportname=steak Pardon my objection (I know you guys are getting slammed with a lot of complaints lately), but... Development has ceased: Is that really the only reason for removing these two ports? There's really nothing wrong with either of them, to the best of my knowledge, and both are very useful to me in my correspondence with native German speakers. Development has ceased just seems to be insufficient as an *automatic* cause (excuse?) for removing a port, IMHO. Are we saying that once a program has reached a finished, final, stable working state, the developer(s) should be required to continue coming up with ways of modifying it for no good reason other than to avoid being dropped from our ports collection? Viewed from this perspective, doesn't that seem just a tad unreasonable? I mean, it's more like: deprecated because: development is *complete* and needs no further refinement (which is, of course, patently absurd) This really does lead one to wonder just what exactly is motivating the individuals leading the charge in this latest rash of ports removals. I realize many of the people involved in handling the ports collection are seasoned, experienced FreeBSD veterans, but this almost feels as if some new, overly eager intern has just recently been turned loose on the ports collection and, drunk on their newly acquired power, is just madly and capriciously slashing-and-burning with wild abandon. If having a maintainer for these two ports might spare them from the executioner's ax, I'll be happy to add them to my existing list of responsibilities. Thank you. -- Conrad J. Sabatier conr...@cox.net ___ 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: sysutils/cfs
On Thu, 08 Sep 2011 18:54:36 +0200 Matthias Andree mand...@freebsd.org wrote: Am 08.09.2011 13:52, schrieb Matt Burke: What the current FreeBSD policy of actively deleting perfectly usable ports instead of putting a mild hurdle in the way is saying, is that FreeBSD will stop me doing what I may want to do because FreeBSD knows best. The port isn't perfectly usable (because that would mean it's usable in all circumstances for all advertised purposes, which is explicitly not the case in the light of known vulnerabilities). And just how in the world can you verify that *any* port is perfectly usable by your definition? Should we just go ahead and delete every port in the collection then? -- Conrad J. Sabatier conr...@cox.net ___ 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: deprecated because: Development has ceased??? Maybe development is *complete*
On Fri, 09 Sep 2011 19:29:15 +0200 Matthias Andree matthias.and...@gmx.de wrote: Am 09.09.2011 13:15, schrieb Conrad J. Sabatier: On Wed, 7 Sep 2011 08:33:08 +0200 (CEST) lini...@freebsd.org wrote: portname: german/ksteak description:KDE frontend for steak, an english - german dictionary maintainer: po...@freebsd.org deprecated because: Development has ceased. expiration date:2011-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=germanportname=ksteak portname: german/steak description:An english - german dictionary under the GPL maintainer: po...@freebsd.org deprecated because: Development has ceased. expiration date:2011-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=germanportname=steak Pardon my objection (I know you guys are getting slammed with a lot of complaints lately), but... Development has ceased: Is that really the only reason for removing these two ports? There's really nothing wrong with either of them, to the best of my knowledge, and both are very useful to me in my correspondence with native German speakers. Are you willing to fill in as a spare for the original author if users have problem with the port or with the software? Are you willing to keep the software going as the FreeBSD environment, ports libraries, and everything changes? If so, welcome Conrad Sabatier the new maintainer for steak and ksteak. If you're not willing or uncapable of doing that work, then you can complain all you want but won't be heard. Well, I'm certainly willing to do what I can, for as long as I can. I maintain a handful of other ports, so I'm not unfamiliar with ports maintenance. As long as I'm capable of doing so, I'd be glad to. If at some point, some change in the base system or ports renders further maintenance extraordinarly difficult or impossible, well then of course, I would have to relinquish those duties and let these two ports climb the stairs to the Attic. :-) Development has ceased just seems to be insufficient as an *automatic* cause (excuse?) for removing a port, IMHO. Are we saying that once a program has reached a finished, final, stable working state, the developer(s) should be required to continue coming up with ways of modifying it for no good reason other than to avoid being dropped from our ports collection? Viewed from this perspective, doesn't that seem just a tad unreasonable? Software maintenance doesn't mean that the software has to change if there's nothing that needs to change. Leafnode-1 (news/leafnode) barely changes at all these last years, just an occasional fix. However, it's still maintained and if you report a serious bug I - as the upstream author - will fix it. If the author of another package stated that maintenance ceased, that is no longer the case. Any why let port users fall into this pit? They are still able to install from source, but we're no longer offering assistance. Well, I' sure you know that installing from source by hand is often much more difficult than using ports. All sorts of odd little road bumps often crop up that have to be dealt with, and many users simply may not have the necessary skills. This really does lead one to wonder just what exactly is motivating the individuals leading the charge in this latest rash of ports removals. I no capacity to support, as was restated more than once. That whole area still just seems rather fuzzy and grey to me. Opinions as to what constitutes support seem to vary widely. My *personal* feeling is that as long as a port continues to build and run and doesn't require any modifications to other ports in order to do so, and has no known serious vulnerabilities that would render it truly dangerous to use, then we should try to keep it around (yes, even if it means we have to host the distfiles(s) after the original site is gone, which I know many would disagree with). Again, just my personal feelings on the matter. Having dabbled with a number of Linux distributions, I feel very strongly that the ports collection is one of FreeBSD's strongest assets (relative to Linux), and that we should strive to keep it as complete (for lack of a better word) and rich and diverse as possible. If having a maintainer for these two ports might spare them from the executioner's ax, I'll be happy to add them to my existing list of responsibilities. I take it that sooner or later it will be unworkable. steak is no longer available, and ksteak hasn't been ported to KDE4/Qt4. I suppose that Qt3's days are counted, and once that's removed, so will ksteak be even if you can find and hosting the steak sources and possibly fix bugs. Yes, that will no doubt eventually some to pass, but in the meantime... It might prolong the port's life
Re: sysutils/cfs
On Fri, 09 Sep 2011 19:05:49 +0200 Matthias Andree matthias.and...@gmx.de wrote: Am 09.09.2011 11:09, schrieb Conrad J. Sabatier: On Thu, 08 Sep 2011 18:54:36 +0200 Matthias Andree mand...@freebsd.org wrote: No, you'd use a managed installation. Nobody stands there pointing a gun at your head and forces you to uninstall a port that got removed from the ports/ tree. If people could recognize that, it might help get the derailed discussion back on the right track. You fail to take into account the case where a port may need to be reinstalled. An extraordinary effort is required if the port no longer exists in the ports tree. If a port may need to be reinstalled then you failed organize proper backups. Not a valid point here. Not necessarily. A simple bump in library versioning could require ports to be rebuilt. Frankly, I'm growing increasingly concerned that this push to eliminate ports is getting out of control. I don't much care for the notion that, having invested the time in installing, configuring and tuning a certain set of software packages, suddenly the rug could be pulled out from under me, so to speak, in essence *forcing* me to abandon using certain packages or else deal with maintaining them (in the ports maintainer sense) on my own. The rug is pulled by the upstream maintainers abandoning their software, not by FreeBSD no longer packaging it years after the fact. While I understand the reasoning behind this, I still feel that as long as a package continues to build and run without any known issues, then why be in a rush to drop it? The argument that the ports collection is not a museum is valid to some degree, but if a package is still usable (and useful), then aren't we shooting ourselves in the foot by dropping it? -- Conrad J. Sabatier conr...@cox.net ___ 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: MASTER_SITE_SOURCEFORGE: how do *you* handle it? (resolved)
On Sun, 28 Aug 2011 21:05:11 -0500
Conrad J. Sabatier conr...@cox.net wrote:
I'm wondering how other ports maintainers are dealing with their
definitions of MASTER_SITES=, DISTFILES=, DISTNAME=, etc. with regards
to Sourceforge.
In browsing a number of projects recently on Sourceforge, I've noticed
that the paths to project distfiles are now using the element
projects rather than project.
As per the suggestion I got from Rob Farmer rfar...@predatorlabs.net,
I went ahead and downloaded the distfile for the project I'm interested
in, then, from firefox's Downloads list, selected Copy Download
Link:
http://voxel.dl.sourceforge.net/project/scidvspc/source/scid_vs_pc-4.5.tgz
I was rather surprised to see that the actual working link does, in
fact, use the element /project/ rather than /projects/, which I had
mistakenly concluded before from examining the link on the Download
button on the project's page (stupid, I know).
So, it turns out that the following is what works, at least in the case
of this particular port (if not for *all* Sourceforge ports):
MASTER_SITES= SF/${PORTNAME}/source/
Along with defining DISTNAME and EXTRACT_SUFX, due to the non-standard
naming of this particular port's distfile (which, rather annoyingly,
includes underscore characters that aren't present in the project name).
So, the basic rule of thumb, I see now, is Ignore the Download link
on the project page, and check the actual link after downloading.
Wish I had realized this sooner and saved myself a lot of frustration.
Sometimes, you know, you're just too close to something to actually see
what's going on.
Anyway, finally reached a happy ending with this one. Thanks to all
who responded. I hope this information may help someone else who runs
into the same sort of confusion I went through earlier.
--
Conrad J. Sabatier
conr...@cox.net
___
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
Compiling for gtk3
I've been trying to compile pan2 from the master git repository, and am having problems getting a build that will actually run using the --with-gtk3 configure switch. The compilation goes OK, but execution fails with... [conrads@serene ~/build/pan2]$ pan/gui/pan Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported aborting... Abort trap: 6 (core dumped) What's the key to getting an app to work with gtk3? Obviously, I'm missing something here. Thanks. -- Conrad J. Sabatier conr...@cox.net ___ 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: configure options
On Fri, 2 Sep 2011 12:01:29 +0100 Anton Shterenlikht me...@bristol.ac.uk wrote: I'm having problems building www/firefox on ia64. I was advised to: https://bugzilla.mozilla.org/show_bug.cgi?id=683879 --- Comment #3 from Boris Zbarsky (:bz) bzbar...@mit.edu 2011-09-01 10:36:27 PDT --- Do things work if you do use --disable-ipc? -- How should I specify this option within the ports framework? Should it be something like make disable-ipc=yes Anytime you need to tinker with the arguments to a port that uses a GNU configure script, you'll want to add a line to the top-level Makefile, somewhere after any existing CONFIGURE_ARGS definition(s), if any: CONFIGURE_ARGS+=--disable-ipc (Note the use of the += operator. This will ensure that any configure options you add won't replace those already specified in the Makefile, but will be appended to them instead) If you cd to the port's WRKDIR, you can run ./configure --help to see all of the possible options. HTH -- Conrad J. Sabatier conr...@cox.net ___ 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: How to deal with conflict between graphics/libGL and x11/nvidia-driver?
On Thu, 1 Sep 2011 16:45:41 +0200 (CEST) Oliver Fromme o...@lurza.secnetix.de wrote: Conrad J. Sabatier wrote: Does anyone have any suggestions on how to deal with the conflict between the ports libGL and nvidia-driver? Both install their own version of /usr/local/lib/libGL.so.1. Obviously, if you're using the nvidia driver, you need nvidia's version and not libGL's version, but many other ports also depend on libGL. I'm not quite sure how to deal with this so that any portupgrades, etc. won't keep trampling over my nvidia GL libraries. I was going to use an ALT_PKGDEP for portupgrade, but the problem is that libGL also installs some include files that nvidia-driver does not, so that's not a sufficient solution. Maybe it would be helpful to add libGL as a dependency to the nvidia-driver port. That means, when the libGL port is updated, the nvidia-driver port will be rebuilt, too, because it depends on the libGL port, which means that the nvidia-driver's library will always override the one installed by the libGL port. Best regards Oliver Excellent idea! Hadn't thought of that. That also obviates the need for a new AFFECTS variable in ports that was discussed recently by myself and a few others. I'll Cc: this on to the nvidia-driver maintainer. Thanks, Conrad -- Conrad J. Sabatier conr...@cox.net ___ 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: cvs commit: ports/mail/procmail Makefile
On Tue, 30 Aug 2011 17:57:10 +0200 Matthias Andree mand...@freebsd.org wrote: I understand that keeping unchanging software can sometimes be necessary, if you're working around its quirks. At the same time I'd like to discourage new installations of dead software so that it disappears over time, rather than haunt fresh systems. That makes perfect sense, yes. How about if we added a new tag OBSOLESCENT or so that permits building the software only if it's already installed but refuses new installations? Of course there could be a switch to override that, like TRYBROKEN that can override BROKEN= tags. You had me on the edge of my seat for a while there, talking about removing my beloved procmail. Now this suggestion I could easily live with. :-) I'm not sure if it's feasible for packages (but OBSOLESCENT could imply do not package) but for ports it would be possible. I like it. :-) -- Conrad J. Sabatier conr...@cox.net ___ 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: (maintainer question) Possible bug in cvs: cvs diff -uN: -N switch being ignored (disappearing, actually)
On Wed, 31 Aug 2011 09:17:52 +0100
Chris Rees utis...@gmail.com wrote:
On 31 Aug 2011 01:51, Conrad J. Sabatier conr...@cox.net wrote:
Odd little problem here I'm noticing with cvs.
When I do a cvs diff -uN, for some reason the -N switch is being
ignored. It vanishes completely in the header of the resulting
output. I've been trying to rename one of my patch files to
conform to portlint's recommendations, but unless I can get -N to
work properly, this is a no-go. Whether I add 'cvs diff -uN' to
my .cvsrc, or explicitly add it at the command line, makes no
difference.
For instance:
[root@serene /usr/ports/net-p2p/lopster]# cvs diff -uN
cvs diff: Diffing .
Index: Makefile
===
RCS file: /home/ncvs/ports/net-p2p/lopster/Makefile,v
retrieving revision 1.44
diff -u -r1.44 Makefile
^
|__ What happened to -N?
[snip remainder of diff output]
Incidentally, this problem started before I upgraded two days ago
from 9.0-BETA1 to 9.0-BETA1, so it's not OS version-related.
Any idea what could be causing this and how to correct it? Is this
a bug in cvs? Should I send-pr it?
Did you remember to cvs add / rm the files you're adding/removing? Do
you know what -N does?
Chris
Well, I'm using a local copy of the FreeBSD CVS repository which I
maintain via csup (from which I do checkouts/updates
of /usr/{doc,ports,src}, so I don't try to do anything that modifies the
repo, but I do like having it around to check log messages and, in the
case of ports maintenance, to create patches.
If I understand correctly, the -N switch to cvs diff should note if a
file has been removed or a new file added, or am I mistaken? At any
rate, doesn't it seem peculiar that the switch would just be silently
dropped like this?
Anyway, while we're on the subject: since I don't have any commit
privileges (I suppose I could change that on my local copy of the
repo, but I prefer to keep it in a pristine official state), what *is*
the proper way to create a diff/patch that incorporates new files, or
renames/deletes old ones? I understand the add/rm functions, having
used them on my own personal cvs repo that I use for software projects
I'm hacking on, but in dealing with the official repo, some other
approach is needed, I think.
Thanks.
--
Conrad J. Sabatier
conr...@cox.net
___
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: (maintainer question) Possible bug in cvs: cvs diff -uN: -N switch being ignored (disappearing, actually)
On Wed, 31 Aug 2011 03:51:27 -0500 Matthew D. Fuller fulle...@over-yonder.net wrote: On Wed, Aug 31, 2011 at 03:50:04AM -0500 I heard the voice of Conrad J. Sabatier, and lo! it spake thus: [...] so I don't try to do anything that modifies the repo, cvs add doesn't affect the repository, just the working tree state. OK, looks like I had a major misunderstanding going on here. :-) After using cvs add/delete, the diff is coming out as expected now. Sorry for the noise, folks. :-) -- Conrad J. Sabatier conr...@cox.net ___ 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
(maintainer question) Possible bug in cvs: cvs diff -uN: -N switch being ignored (disappearing, actually)
Odd little problem here I'm noticing with cvs. When I do a cvs diff -uN, for some reason the -N switch is being ignored. It vanishes completely in the header of the resulting output. I've been trying to rename one of my patch files to conform to portlint's recommendations, but unless I can get -N to work properly, this is a no-go. Whether I add 'cvs diff -uN' to my .cvsrc, or explicitly add it at the command line, makes no difference. For instance: [root@serene /usr/ports/net-p2p/lopster]# cvs diff -uN cvs diff: Diffing . Index: Makefile === RCS file: /home/ncvs/ports/net-p2p/lopster/Makefile,v retrieving revision 1.44 diff -u -r1.44 Makefile ^ |__ What happened to -N? [snip remainder of diff output] Incidentally, this problem started before I upgraded two days ago from 9.0-BETA1 to 9.0-BETA1, so it's not OS version-related. Any idea what could be causing this and how to correct it? Is this a bug in cvs? Should I send-pr it? Thanks! -- Conrad J. Sabatier conr...@cox.net ___ 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
