Re: graphics/libfpx: use of bsd.lib.mk and warnings
On Sat, Jul 28, 2012 at 7:59 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: On 28.07.2012 12:25, Thomas Zander wrote: It also causes the port to use clang when setting CC=clang in /etc/src.conf (!) which fails here. What if you use CC?=clang instead? Thanks, This works: CC?=clang CXX?=clang++ CPP?=clang-cpp Best Riggs ___ 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-servers/xorg-server, clang as system compiler
On Sun, Jul 29, 2012 at 8:54 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
On Sat, Jul 28, 2012 at 9:26 PM, Boris Samorodov b...@passap.ru wrote:
Hi All,
I use clang as default system compiler (WITH_CLANG_IS_CC=YES
at /etc/make.conf). The system is i386-current as of yesterday,
fresh ports as of yesterday.
I get this configure error while building x11-servers/xorg-server:
-
[...]
checking for cpp... /usr/bin/cpp
checking if /usr/bin/cpp requires -undef... yes
checking if /usr/bin/cpp requires -traditional... configure: error:
/usr/bin/cpp does not preserve whitespace with or without -traditional. I
don't know what to do.
=== Script configure failed unexpectedly.
-
What should I do? Thanks!
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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
Hi,
Take a look a bug report
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/166373.
While at it, could someone with commit rights find some time to see if
any of the fixes proposed at the PR comments could be committed? It
would be one less nuisance for those who have WITH_CLANG_IS_CC=YES.
This one works for me but I haven't tested it on a system where cpp is
the gcc4.2.1 one:
Index: Makefile
===
--- Makefile(revision 301674)
+++ Makefile(working copy)
@@ -25,11 +25,12 @@
CONFIGURE_ARGS+= --datadir=${PREFIX}/lib \
--without-xmlto \
--disable-specs
-CONFIGURE_ENV+=ac_cv_path_PS2PDF=
+CONFIGURE_ENV+= ac_cv_path=${CPP} ac_cv_path_PS2PDF=
.include ${.CURDIR}/manpages
post-patch:
+ @${REINPLACE_CMD} 's/test.*-traditional.*;/true;/' ${WRKSRC}/configure
@${REINPLACE_CMD} '/^install-data-am:/,/^$$/ \
s/install-specDATA//' ${WRKSRC}/nls/Makefile.in
Regards,
Kimmo Paasiala
___
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: MATE 'base' desktop is ready for anyone to test it.
On Fri, 27 Jul 2012, Jeremy Messenger wrote: Hello all, The MATE base desktop (x11/mate-base) is ready to use and test. ... ... To get it, you will need to grab marcusmerge script from http://www.marcuscom.com/downloads/marcusmerge then run 'sh marcusmerge -m ports-experimental'. Doug Barton responded: This is a great example of where a ports projects/ branch in svn would be very helpful. :) I agree, either projects/, experimental/, wip/ or something like that for a testing branch. NetBSD pkgsrc has a pkgsrc-wip (Work In Progress) branch separate from pkgsrc tree, at pkgsrc-wip.sourceforge.net FreeBSD users could then try out testing/beta versions of ports and give feedback. Tom ___ 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: firefox 14.0.1 and flash
ajtiM lum...@gmail.com writes:
Hi!
On my FreeBSD 9.0 Release, KDE 4.8.4, Firefox 14.0.1 stooped working with
linuxflashplugin 11. There is no problem with Opera.
First, try firefox package and show pkg_info -aE output. Blame pointyhat
tardiness if the package (for 14.0.1) is not available yet.
Second, try to disable dom.ipc.plugins.enabled in about:config.
If it helps try the first attached patch, then remove patch-bug753046
and try the second patch.
If neither helps try collecting debug info
# NSPR_LOG_MODULES output depends on LOGGING option
$ NSPR_LOG_MODULES=plugin:5 firefox -ProfileManager -no-remote
$ NSPR_LOG_MODULES=all:5 NSPR_LOG_FILE=$HOME/nspr.log firefox -P
test-profile -no-remote
$ NPW_DEBUG=1 NPW_LOG=$HOME/npw.log firefox -P test-profile -no-remote
and see how far it got by comparing output with previous version.
Also, QT4 is known to be broken with plugins.
diff --git Mk/bsd.gecko.mk Mk/bsd.gecko.mk
index 5bc445a..c7d6957 100644
--- Mk/bsd.gecko.mk
+++ Mk/bsd.gecko.mk
@@ -559,7 +559,7 @@ cairo_EXTRACT_AFTER_ARGS= --exclude mozilla*/gfx/cairo
dbm_EXTRACT_AFTER_ARGS= --exclude mozilla*/dbm
-event_LIB_DEPENDS= event-2.0:${PORTSDIR}/devel/libevent2
+event_LIB_DEPENDS= event-1.4:${PORTSDIR}/devel/libevent
event_MOZ_OPTIONS= --with-system-libevent=${LOCALBASE}
event_EXTRACT_AFTER_ARGS= --exclude mozilla*/ipc/chromium/src/third_party/libevent
diff --git www/firefox/files/patch-ipc-chromium-Makefile.in www/firefox/files/patch-ipc-chromium-Makefile.in
index bba9d01..d7fb326 100644
--- www/firefox/files/patch-ipc-chromium-Makefile.in
+++ www/firefox/files/patch-ipc-chromium-Makefile.in
@@ -22,7 +22,7 @@
-# message_pump_libevent.cc includes third_party/libevent/event.h,
-# which we put in $(DIST), see export rule below
-LOCAL_INCLUDES += -I$(DIST)
-+LOCAL_INCLUDES += $(filter %/compat, $(MOZ_LIBEVENT_INCLUDES))
++LOCAL_INCLUDES += $(MOZ_LIBEVENT_INCLUDES)
endif # }
vpath %.cc \
diff --git www/firefox/Makefile www/firefox/Makefile
index aefbf2d..5cd78ef 100644
--- www/firefox/Makefile
+++ www/firefox/Makefile
@@ -21,6 +21,7 @@
sqlite3=3.7.11:${PORTSDIR}/databases/sqlite3 \
cairo=1.10.2_1,1:${PORTSDIR}/graphics/cairo \
unzip:${PORTSDIR}/archivers/unzip
+LIB_DEPENDS= execinfo.1:${PORTSDIR}/devel/libexecinfo
CONFLICTS_BUILD= spidermonkey-*
@@ -105,6 +106,9 @@
${FILESDIR}/firefox.desktop.in ${WRKDIR}/${MOZILLA}.desktop
post-patch:
+ @${GREP} -Flr \/proc ${WRKSRC}/ipc/chromium/src/base | ${XARGS} ${REINPLACE_CMD} \
+ -e 's|/proc/self/fd|/dev/fd|' \
+ -e 's|/proc[/]|/compat/linux|'
@${REINPLACE_CMD} -e 's|%%LOCALBASE%%|${LOCALBASE}|g' \
${WRKSRC}/browser/app/nsBrowserApp.cpp
diff --git www/firefox/files/patch-ipc-chromium-src-base-dir_reader_linux.h www/firefox/files/patch-ipc-chromium-src-base-dir_reader_linux.h
deleted file mode 100644
index 3c53d08..000
--- /dev/null
+++ www/firefox/files/patch-ipc-chromium-src-base-dir_reader_linux.h
@@ -0,0 +1,45 @@
+--- ipc/chromium/src/base/dir_reader_linux.h.orig 2011-12-16 21:29:22.0 +0100
ipc/chromium/src/base/dir_reader_linux.h 2011-12-19 21:00:27.0 +0100
+@@ -9,6 +9,7 @@
+ #include errno.h
+ #include fcntl.h
+ #include stdint.h
++#include sys/dirent.h
+ #include sys/syscall.h
+ #include unistd.h
+
+@@ -19,6 +20,8 @@
+
+ namespace base {
+
++#define linux_dirent struct dirent
++#if 0
+ struct linux_dirent {
+ uint64_td_ino;
+ int64_t d_off;
+@@ -26,11 +29,16 @@
+ unsigned char d_type;
+ chard_name[0];
+ };
++#endif
+
+ class DirReaderLinux {
+ public:
+ explicit DirReaderLinux(const char* directory_path)
++#ifdef O_DIRECTORY
+ : fd_(open(directory_path, O_RDONLY | O_DIRECTORY)),
++#else
++ : fd_(open(directory_path, O_RDONLY)),
++#endif
+ offset_(0),
+ size_(0) {
+ memset(buf_, 0, sizeof(buf_));
+@@ -57,7 +65,7 @@
+ if (offset_ != size_)
+ return true;
+
+-const int r = syscall(__NR_getdents64, fd_, buf_, sizeof(buf_));
++const int r = syscall(SYS_getdents, fd_, buf_, sizeof(buf_));
+ if (r == 0)
+ return false;
+ if (r == -1) {
diff --git www/firefox/files/patch-ipc-chromium-src-base-file_util_linux.cc www/firefox/files/patch-ipc-chromium-src-base-file_util_linux.cc
deleted file mode 100644
index 82241b6..000
--- /dev/null
+++ www/firefox/files/patch-ipc-chromium-src-base-file_util_linux.cc
@@ -0,0 +1,11 @@
+--- ipc/chromium/src/base/file_util_linux.cc~
ipc/chromium/src/base/file_util_linux.cc
+@@ -28,7 +29,7 @@ bool GetShmemTempDir(FilePath* path) {
+ #ifdef ANDROID
+ return GetTempDir(path);
+ #else
+- *path = FilePath(/dev/shm);
++ *path = FilePath(/tmp);
+ return true;
+ #endif
+ }
diff --git www/firefox/files/patch-ipc-chromium-src-base-file_util_posix.cc www/firefox/files/patch-ipc-chromium-src-base-file_util_posix.cc
deleted file mode 100644
index 90249bb..000
--- /dev/null
+++
Re: Firefox 14 build broken due to wrong libpng
Eitan Adler li...@eitanadler.com writes:
On 28 July 2012 01:59, Florian Smeets f...@smeets.im wrote:
P.S. We really need a way of depending on ports being built with certain
OPTIONS.
Slave ports.
In this case APNG has both compatible ABI and Mozilla looking into its
security. For stubborn people there is an undocumented way, e.g.
# add to make.conf or Makefile.local
USE_MOZILLA += -png
Slaving away for a library flavor is not in my TODO. Don't forget there
are people against having two versions of the same library in memory.
FWIW, pkgng does track options but there is no *.mk magic to take
advantage of this yet.
$ tar xOf png-1.5.12.txz --include +MANIFEST | fgrep -i opt
options: {APNG: on}
___
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-servers/xorg-server, clang as system compiler
On 2012-07-29 09:47, Kimmo Paasiala wrote: On Sun, Jul 29, 2012 at 8:54 AM, Kimmo Paasiala kpaas...@gmail.com wrote: On Sat, Jul 28, 2012 at 9:26 PM, Boris Samorodov b...@passap.ru wrote: Hi All, I use clang as default system compiler (WITH_CLANG_IS_CC=YES at /etc/make.conf). The system is i386-current as of yesterday, fresh ports as of yesterday. I get this configure error while building x11-servers/xorg-server: - [...] checking for cpp... /usr/bin/cpp checking if /usr/bin/cpp requires -undef... yes checking if /usr/bin/cpp requires -traditional... configure: error: /usr/bin/cpp does not preserve whitespace with or without -traditional. I don't know what to do. === Script configure failed unexpectedly. - What should I do? Thanks! -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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 Hi, Take a look a bug report http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/166373. While at it, could someone with commit rights find some time to see if any of the fixes proposed at the PR comments could be committed? It would be one less nuisance for those who have WITH_CLANG_IS_CC=YES. This one works for me but I haven't tested it on a system where cpp is the gcc4.2.1 one: Check out the experimental xorg tree. There is a fix for this issue there, but more testing would be nice. See http://wiki.freebsd.org/Xorg for details. Regards! -- Niclas Zeising ___ 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: Firefox 14 build broken due to wrong libpng
On 29/07/2012 02:19, Jan Beich wrote:
FWIW, pkgng does track options but there is no *.mk magic to take
advantage of this yet.
$ tar xOf png-1.5.12.txz --include +MANIFEST | fgrep -i opt
options: {APNG: on}
pkg query %Ok %Ov png
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature
Re: FreeBSD Port: bash-4.2.28
On Sat, 28 Jul 2012 16:54:40 -0700 (PDT) Doug Barton articulated: On Wed, 25 Jul 2012, Jerry wrote: On Wed, 25 Jul 2012 11:14:25 -0700 Doug Barton articulated: On 07/25/2012 08:03, Michael wrote: Hello obrien, Any plans to update bash-4.2.28 up to patch level 037? Is there a specific bug fixed that you're interested in? The short answer would be what the hell difference does that make? We don't use that kind of language on the FreeBSD lists. The OP just wanted to know if the port was going to be updated to include the newly released patches. The long answer is that he is interested in getting the official patches to correct known problems with Bash. Who's business is it what problem, real or potential that the OP is looking to correct or prevent? Completely aside from my being thoroughly impressed with your mind-reading abilities, upgrading to the latest/greatest is not always the best strategy. Speaking generally, even things that are (nominally) strictly bug fixes can bring in new problems, and Bash patches are not always strictly bug fixes. First of all, I see you CC'd me AGAIN. Obviously your comprehension skills are rather lax since I have a clearly noted request NOT to be CC'd and have in the past specifically asked you not to do so. I took the time to relay your CC'd message to SpamCop. I know it won't do any good, but it is a feel good thing. Strictly speaking, it is none of your business if bug fixes can bring in or expose new or undiscovered problems. It has been shown throughout history that any advancement can bring with it, its own new set of problems. Should we all abandon the use of electricity because there is a real possibility that someone man get electrified. Kainolophobia can be treated. By the way, do you use bash? if not then what is your problem? If you do, have you read what the patches actually entail? I have. There is also the issue that in FreeBSD we are generally more conservative about upgrading something from a known-stable version. That is a lot about nothing. Postfix is updated in virtual real time. For every port that you can list that is left effectively abandoned for extended periods of time, I can produce one that is updated in a timely fashion. I know, now you want a definition of timely. In my opinion, I believe 30 days is sufficient. That is only a general rule. Obviously, some large and complex ports like KDE or the latest version of Apache would not easily fit into that time constraint. However, the maintainers of those ports, just to name a few, have publically posted regarding their work on the port and what has to be done to make it ready for the ports system. If the Bash maintainer⁽¹⁾ feels that there is a problem with updating Bash at this time, then he needs only to post it. As for my motivations for asking the question, there are at least 2. First, I don't see anything in the latest set of patches that I find particularly exciting, but I'm interested in the OP's perspective. Second, if the OP is actually being affected by one of the things that is patched, I know the maintainer would be interested in that. I am really impressed with the fact that you have not noted anything in the patches that turns you on. I failed to notice any mention in the FreeBSD handbook, or other literature for that matter that stated that patches, etcetera are only deemed worthy if Doug approves of them. Would you please be so kind as to point out to me where that is so noted. The OP specifically inquired about the updating of Bash which is seriously behind in its FreeBSD patch set. He did not ask for your permission. If you have a fear of updating software (I wonder if there is a phobia for that) then don't update yours. I know that in Portmanager and Portupgrade I can specifically exclude ports I do not want to touch. What is so hard to comprehend abut that? The solution is so simple that I fail to grasp why it is beyond your comprehension. The port is simply updated in the port's tree. Then an end user has the option of updating on their machine or not. The KISS principal at its finest. CHOICE, isn't that what open-source software is all about, or is it only applicable when Doug approves of it? Seriously, I really want to know. It readily appears that you are attempting to use Parkinson's Law of Triviality, also known as bikeshedding to legitimize the delay of updating a port sans any concrete proof? Why? What are you so terrified of? If you don't use the port, then it is of no significance to you. If you do and choose not to update it, then that is your business. Again, such a simple decision. Doug, I still use version 1.x of Dovecot. Why you ask -- because I want to. Why didn't I update you inquire -- because I did not want to. However, I am very glad that there is a much improved version 2.x of Dovecot and plan to take it out for a test drive when I have to install a new mail-server, perhaps later this
Re: lang/gcc46 building stuff in $TMPDIR
On Sat, 9 Jun 2012, Doug Barton wrote: Are you saying you actually noticed some leftovers in /tmp, or that there just has been more at certain points in time than you would expect? I finally had time to watch this closely, and found the culprit(s). While building the port creates a lot of files in /tmp (I think it's actually $TMP, not $TMPDIR). A lot of them are *.s files, most of which are small, but one of which grew to over 64M, which is what caused my build to fail. It also creates a variety of other files, including .o, .c, .ld, .le, .zip, etc. The java OPTION also creates some pretty big jar directories, I had one grow to 49M, which didn't crash my build, but might blow up someone with a smaller /tmp. My suggestion would be to create a directory in $WRKDIR and assign $TMP (or whatever the right envar is) to it. That could be done, but has one significant drawback: those of us who have /tmp on fastest storage, and $WRKDIR on slower storage, could lose a lot of speed. Also, while I understand your situation, I am very hesitant to change any defaults given that I have not seen any other user reports, not even upstream. Note: according to the GCC documentation If `TMPDIR' is set, it specifies the directory to use for temporary files. GCC uses temporary files to hold the output of one stage of compilation which is to be used as input to the next stage: for example, the output of the preprocessor, which is the input to the compiler proper. Does it make a difference for you if you set TMPDIR to some location where you have more storage? On Tue, 10 Jul 2012, Doug Barton wrote: Just tried building the latest, same error. Did I misunderstand that something was supposed to be different? I believe lang/gcc47 has seen a split of one large, automatically generated, source file which is what you may have run into. So going for that (and I plan on moving lang/gcc to GCC 4.7 in the not too far future) could be one option. Another might be reducing the amount of parallel building on your system. Finally, you indicated that you also saw Java create a large temporary file. If you want to avoid building Java, the GCC ports have an option to disable Java. Let me actually take this as a trigger to convert this to the new options framework. Gerald ___ 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: lang/gcc46 building stuff in $TMPDIR
On 07/29/2012 13:50, Gerald Pfeifer wrote: On Sat, 9 Jun 2012, Doug Barton wrote: Are you saying you actually noticed some leftovers in /tmp, or that there just has been more at certain points in time than you would expect? I finally had time to watch this closely, and found the culprit(s). While building the port creates a lot of files in /tmp (I think it's actually $TMP, not $TMPDIR). A lot of them are *.s files, most of which are small, but one of which grew to over 64M, which is what caused my build to fail. It also creates a variety of other files, including .o, .c, .ld, .le, .zip, etc. The java OPTION also creates some pretty big jar directories, I had one grow to 49M, which didn't crash my build, but might blow up someone with a smaller /tmp. My suggestion would be to create a directory in $WRKDIR and assign $TMP (or whatever the right envar is) to it. That could be done, but has one significant drawback: those of us who have /tmp on fastest storage, and $WRKDIR on slower storage, could lose a lot of speed. Have you measured that? Also, while I understand your situation, I am very hesitant to change any defaults given that I have not seen any other user reports, not even upstream. It's doubtful that others have a tiny /tmp like I do, but reproducing the problem is trivial. Note: according to the GCC documentation If `TMPDIR' is set, it specifies the directory to use for temporary files. GCC uses temporary files to hold the output of one stage of compilation which is to be used as input to the next stage: for example, the output of the preprocessor, which is the input to the compiler proper. Does it make a difference for you if you set TMPDIR to some location where you have more storage? Obviously. :) On Tue, 10 Jul 2012, Doug Barton wrote: Just tried building the latest, same error. Did I misunderstand that something was supposed to be different? I believe lang/gcc47 has seen a split of one large, automatically generated, source file which is what you may have run into. I haven't gotten into 47 yet. Another might be reducing the amount of parallel building on your system. Finally, you indicated that you also saw Java create a large temporary file. If you want to avoid building Java, the GCC ports have an option to disable Java. Let me actually take this as a trigger to convert this to the new options framework. Reducing functionality to handle build infrastructure problems is not a desirable solution. But thanks for the response in any case. :) Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: lang/gcc rumdependencies?
On Thu, 16 Feb 2012, b. f. wrote:
The main question is why this port (and everythin else with
USE_GCC=4.6+) depend on lang/gcc46 and not lang/gcc. Most port
users dislike building latest gcc snapshot on a weekly basis.
Indeed. But (as discussed before on this list), they don't have to,
if they find this to be a problem: they can remove lang/gcc46 and
replace it with lang/gcc.
You may have noticed that lang/gcc46 has signficiantly slowed down
in it getting updates the last couple of months. That was by design,
since I know a larger number of users is having this as the default
version of GCC.
For ports building clusters and to simplify things for non-expert
users, or users just going for the default, indeed dragging in
lang/gcc by default, not lang/gcc46 (or later lang/gcc47) makes
sense and the patch below should do this.
Feedback welcome!
Maybe it would be good to move current lang/gcc46 to lang/gcc46-devel
and rename lang/gcc to lang/gcc46?
No, because in time lang/gcc will become a stable release of 4.7.x,
and so on ...
Exactly! I _am_ thinking to rename lang/gcc48 to lang/gcc48-devel,
and perhaps do similarly for lang/gcc47 as well. Thoughts?
Gerald
PS. The _GCC_BUILD_DEPENDS assignment below prevents breakage of
some ports. I plan on addressing this in a nicer manner, but prefer
to separate the two changes and proceed with this first change rather
sooner than later.
Index: bsd.gcc.mk
===
--- bsd.gcc.mk (revision 301695)
+++ bsd.gcc.mk (working copy)
@@ -178,29 +178,36 @@
. if ${_USE_GCC} == ${_GCCVERSION_${v}_V}
. if ${OSVERSION} ${_GCCVERSION_${v}_L} || ${OSVERSION}
${_GCCVERSION_${v}_R}
V:=${_GCCVERSION_${v}_V:S/.//}
-_GCC_BUILD_DEPENDS:= gcc${V}
_GCC_PORT_DEPENDS:=gcc${V}
+. if ${_USE_GCC} == ${GCC_DEFAULT_VERSION}
+_GCC_PORT:=gcc
+. else
+_GCC_PORT:=gcc${V}
+. endif
CC:= gcc${V}
CXX:= g++${V}
CPP:= cpp${V}
. if ${_USE_GCC} != 3.4
-CFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
-LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
+CFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_PORT_DEPENDS}
+LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_PORT_DEPENDS}
.if defined (USE_FORTRAN)
.if ${USE_FORTRAN} == yes
-FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
+FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_PORT_DEPENDS}
.endif
.endif
+# The following is for the sakes of some ports which use this without
+# ever telling us; to be fixed.
+_GCC_BUILD_DEPENDS:= ${_GCC_PORT_DEPENDS}
. endif
. endif
. endif
.endfor
.undef V
-.if defined(_GCC_BUILD_DEPENDS)
-BUILD_DEPENDS+=
${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_BUILD_DEPENDS}
+.if defined(_GCC_PORT_DEPENDS)
+BUILD_DEPENDS+=${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_PORT}
. if ${_USE_GCC} != 3.4
-RUN_DEPENDS+= ${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_BUILD_DEPENDS}
+RUN_DEPENDS+= ${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_PORT}
. if ${_USE_GCC} != 4.2
# Later GCC ports already depend on binutils; make sure whatever we
# build leverages this as well.
___
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: FreeBSD Port: bash-4.2.28
Umm ... wow. I'll try to respond substantively below. On 07/29/2012 04:46, Jerry wrote: On Sat, 28 Jul 2012 16:54:40 -0700 (PDT) Doug Barton articulated: Completely aside from my being thoroughly impressed with your mind-reading abilities, upgrading to the latest/greatest is not always the best strategy. Speaking generally, even things that are (nominally) strictly bug fixes can bring in new problems, and Bash patches are not always strictly bug fixes. First of all, I see you CC'd me AGAIN. Obviously your comprehension skills are rather lax since I have a clearly noted request NOT to be CC'd and have in the past specifically asked you not to do so. I made a point of cc'ing you on my last message because I wanted to make sure you saw the bit about not using foul language. I appreciate you respecting that. Meanwhile, yes, you've expressed a preference not to be cc'ed on list mail previously. Rather than trying to rehash the whole discussion, I'll simply repeat the main 2 points: 1. Asking the entire Internet to conform to your whim is not a rational strategy. 2. The FreeBSD mailman implementation allows you to specify only receiving 1 copy of a message that you are cc'ed on. I took the time to relay your CC'd message to SpamCop. I know it won't do any good, but it is a feel good thing. Knock yourself out. :) Strictly speaking, it is none of your business if bug fixes can bring in or expose new or undiscovered problems. You keep repeating this none of your business line as if for some reason I don't have the right to ask the question. This is an open project, we can all ask questions. It has been shown throughout history that any advancement can bring with it, its own new set of problems. Should we all abandon the use of electricity because there is a real possibility that someone man get electrified. Yeah, that's just silly. Before we upgrade something it's useful to ask the question of whether or not the upgrade is qualitatively better or not. Just because something comes down from upstream doesn't mean it's an improvement from our users' perspective. By the way, do you use bash? if not then what is your problem? If you do, have you read what the patches actually entail? I have. I already mentioned that I did review the patches. There is also the issue that in FreeBSD we are generally more conservative about upgrading something from a known-stable version. That is a lot about nothing. Postfix is updated in virtual real time. For every port that you can list that is left effectively abandoned for extended periods of time, I can produce one that is updated in a timely fashion. ... all of which would be totally irrelevant. Maintainers are responsible for deciding whether to update, and is so, when. They are also responsible for making sure that the new version is actually an improvement. For some ports/maintainers these are easy decisions. For others they may take time, and/or the maintainer themselves may have to prioritize the update amongst many other projects. Getting information from the users as to why a particular update may have a higher priority than is obvious at first glance is very valuable to the maintainer. OTOH it does occasionally happen that maintainers don't have time to handle the port in a timely manner, and need to be replaced. In that case, the information about maintainers ignoring important updates is also useful to the community. I'm deleting your whole ad hominem attack because there wasn't anything substantive in there to respond to. Good luck, Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: FreeBSD Port: bash-4.2.28
On Sun, 29 Jul 2012 15:42:38 -0700 Doug Barton articulated: Umm ... wow. I'll try to respond substantively below. On 07/29/2012 04:46, Jerry wrote: On Sat, 28 Jul 2012 16:54:40 -0700 (PDT) Doug Barton articulated: Completely aside from my being thoroughly impressed with your mind-reading abilities, upgrading to the latest/greatest is not always the best strategy. Speaking generally, even things that are (nominally) strictly bug fixes can bring in new problems, and Bash patches are not always strictly bug fixes. First of all, I see you CC'd me AGAIN. Obviously your comprehension skills are rather lax since I have a clearly noted request NOT to be CC'd and have in the past specifically asked you not to do so. I made a point of cc'ing you on my last message because I wanted to make sure you saw the bit about not using foul language. I appreciate you respecting that. First of all, lets make something clear, I have no respect for you. You are like a frigging kid. The only permanent solution is to smash your frigging head in with a bat. Oops, I hope I didn't offend you. Maybe you should CC your mother so she can protect you, you asshole. Meanwhile, yes, you've expressed a preference not to be cc'ed on list mail previously. Rather than trying to rehash the whole discussion, I'll simply repeat the main 2 points: 1. Asking the entire Internet to conform to your whim is not a rational strategy. 2. The FreeBSD mailman implementation allows you to specify only receiving 1 copy of a message that you are cc'ed on. Allow me to respond to that, BULLSHIT. Oh, did I offend you? I never asked the frigging entire Internet to bow down to my will; I simple asked not to be CC'd. Since you, most likely due to your NPD affiliation are unable to honor my simple request, why the frigging hell should I afford yours any traction? You do realize that you do not have to include my name in the CC line don't you? I took the time to relay your CC'd message to SpamCop. I know it won't do any good, but it is a feel good thing. Knock yourself out. :) Strictly speaking, it is none of your business if bug fixes can bring in or expose new or undiscovered problems. You keep repeating this none of your business line as if for some reason I don't have the right to ask the question. This is an open project, we can all ask questions. Ask question yes; stating that any patch or whatever not be instituted because it doesn't meet your standards is repulsive. (NPD strikes again) It has been shown throughout history that any advancement can bring with it, its own new set of problems. Should we all abandon the use of electricity because there is a real possibility that someone man get electrified. Yeah, that's just silly. Before we upgrade something it's useful to ask the question of whether or not the upgrade is qualitatively better or not. Just because something comes down from upstream doesn't mean it's an improvement from our users' perspective. Based upon who's opinion, yours? There is that NPD kicking in again. Lets all bow down to Dough the magnificent. Only he is worthy to judge whether a port is deemed worthy of being updated. I am going to file a PR against this for insertion into the handbook. I know it will never get published, but it just another feel good thing. By the way, do you use bash? if not then what is your problem? If you do, have you read what the patches actually entail? I have. I already mentioned that I did review the patches. There is also the issue that in FreeBSD we are generally more conservative about upgrading something from a known-stable version. That is a lot about nothing. Postfix is updated in virtual real time. For every port that you can list that is left effectively abandoned for extended periods of time, I can produce one that is updated in a timely fashion. ... all of which would be totally irrelevant. Maintainers are responsible for deciding whether to update, and is so, when. They are also responsible for making sure that the new version is actually an improvement. For some ports/maintainers these are easy decisions. For others they may take time, and/or the maintainer themselves may have to prioritize the update amongst many other projects. So why not let the port maintainer express his feeling on this matter? Do you feel he is not capable, or should I say as capable as you of expressing his feelings? Getting information from the users as to why a particular update may have a higher priority than is obvious at first glance is very valuable to the maintainer. So you are proposing that ports only be updated when specifically requested by users? Again, the last Bash update took nearly a year. This one is several months old all ready. If the port is only going to be updated semi-annually, or annually, then it would behoove the maintainer to publicly state so. What is so frigging hard
Re: lang/gcc46
On Tue, 13 Dec 2011, b. f. wrote:
Ahh. I see the issue. I have not looked at bsd.gcc.mk, but it does not
seem like this should be too difficult. Just a matter of the right
person having the time. Would ports specifying gcc46 need to be
touched?
Gerald had planned to do this after the ports tree had been completely
unfrozen. It is likely that only a few dependent ports will have to be
changed. You can make this change now, simply by removing lang/gcc46
and installing lang/gcc, and then rebuilding all dependent ports (this
last step may not be necessary in many cases, but it is better to be
safe).
lang/gcc and lang/gcc46 should be fully compatible, without rebuilds
necessary. Only when lang/gcc is going to move to GCC 4.7 later this
year would I consider that.
Or you can try something like the attached patch, which will fix the
dependency accounting -- but you will then have to replace
_GCC_BUILD_DEPENDS with _GCC_PORT_DEPENDS (the latter will then be a
misnomer) in math/atlas, math/atlas-devel, math/gotoblas, math/R,
net-p2p/eiskaltdcpp-* (and soon perhaps also lang/libobjc2, if it is
altered to use USE_GCC, which seems likely).
Sadly there are a number of ports using _GCC_BUILD_DEPENDS even though
by virtual of its name this is an internal (to bsd.gcc.mk) variable. I
am keeping this for now and will address this in a better manner and
work with the maintainer(s) of affected ports.
For the time being, my patch below is an extended version of what
Brendan shared and addresses (or tries to) issues he mentioned.
Gerald
Index: bsd.gcc.mk
===
--- bsd.gcc.mk (revision 301695)
+++ bsd.gcc.mk (working copy)
@@ -178,29 +178,36 @@
. if ${_USE_GCC} == ${_GCCVERSION_${v}_V}
. if ${OSVERSION} ${_GCCVERSION_${v}_L} || ${OSVERSION}
${_GCCVERSION_${v}_R}
V:=${_GCCVERSION_${v}_V:S/.//}
-_GCC_BUILD_DEPENDS:= gcc${V}
_GCC_PORT_DEPENDS:=gcc${V}
+. if ${_USE_GCC} == ${GCC_DEFAULT_VERSION}
+_GCC_PORT:=gcc
+. else
+_GCC_PORT:=gcc${V}
+. endif
CC:= gcc${V}
CXX:= g++${V}
CPP:= cpp${V}
. if ${_USE_GCC} != 3.4
-CFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
-LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
+CFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_PORT_DEPENDS}
+LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_PORT_DEPENDS}
.if defined (USE_FORTRAN)
.if ${USE_FORTRAN} == yes
-FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
+FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_PORT_DEPENDS}
.endif
.endif
+# The following is for the sakes of some ports which use this without
+# ever telling us; to be fixed.
+_GCC_BUILD_DEPENDS:= ${_GCC_PORT_DEPENDS}
. endif
. endif
. endif
.endfor
.undef V
-.if defined(_GCC_BUILD_DEPENDS)
-BUILD_DEPENDS+=
${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_BUILD_DEPENDS}
+.if defined(_GCC_PORT_DEPENDS)
+BUILD_DEPENDS+=${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_PORT}
. if ${_USE_GCC} != 3.4
-RUN_DEPENDS+= ${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_BUILD_DEPENDS}
+RUN_DEPENDS+= ${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_PORT}
. if ${_USE_GCC} != 4.2
# Later GCC ports already depend on binutils; make sure whatever we
# build leverages this as well.
___
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: lang/gcc46
On 07/29/2012 16:55, Gerald Pfeifer wrote: lang/gcc and lang/gcc46 should be fully compatible, without rebuilds necessary. Only when lang/gcc is going to move to GCC 4.7 later this year would I consider that. IMO this highlights the issue that unversioned instances of ports that really need versioning (like gcc) are a bad idea. It's much better for users to be able to tie their installations to a particular version, and then only update when they need to. The fact that someday in the future users who innocently upgrade lang/gcc will suddenly find that everything relying on libgcc at runtime is now broken pretty much speaks for itself. Perl is the shining example of how the versioning strategy works well, lang/python and lang/php5 are examples of where it's not meeting our users' needs. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: FreeBSD Port: bash-4.2.28
On Sun, Jul 29, 2012 at 4:49 PM, Jerry je...@seibercom.net wrote: On Sun, 29 Jul 2012 15:42:38 -0700 Doug Barton articulated: Umm ... wow. I'll try to respond substantively below. On 07/29/2012 04:46, Jerry wrote: On Sat, 28 Jul 2012 16:54:40 -0700 (PDT) Doug Barton articulated: Completely aside from my being thoroughly impressed with your mind-reading abilities, upgrading to the latest/greatest is not always the best strategy. Speaking generally, even things that are (nominally) strictly bug fixes can bring in new problems, and Bash patches are not always strictly bug fixes. First of all, I see you CC'd me AGAIN. Obviously your comprehension skills are rather lax since I have a clearly noted request NOT to be CC'd and have in the past specifically asked you not to do so. I made a point of cc'ing you on my last message because I wanted to make sure you saw the bit about not using foul language. I appreciate you respecting that. First of all, lets make something clear, I have no respect for you. You are like a frigging kid. The only permanent solution is to smash your frigging head in with a bat. Oops, I hope I didn't offend you. Maybe you should CC your mother so she can protect you, you asshole. Meanwhile, yes, you've expressed a preference not to be cc'ed on list mail previously. Rather than trying to rehash the whole discussion, I'll simply repeat the main 2 points: 1. Asking the entire Internet to conform to your whim is not a rational strategy. 2. The FreeBSD mailman implementation allows you to specify only receiving 1 copy of a message that you are cc'ed on. Allow me to respond to that, BULLSHIT. Oh, did I offend you? I never asked the frigging entire Internet to bow down to my will; I simple asked not to be CC'd. Since you, most likely due to your NPD affiliation are unable to honor my simple request, why the frigging hell should I afford yours any traction? You do realize that you do not have to include my name in the CC line don't you? I took the time to relay your CC'd message to SpamCop. I know it won't do any good, but it is a feel good thing. Knock yourself out. :) Strictly speaking, it is none of your business if bug fixes can bring in or expose new or undiscovered problems. You keep repeating this none of your business line as if for some reason I don't have the right to ask the question. This is an open project, we can all ask questions. Ask question yes; stating that any patch or whatever not be instituted because it doesn't meet your standards is repulsive. (NPD strikes again) It has been shown throughout history that any advancement can bring with it, its own new set of problems. Should we all abandon the use of electricity because there is a real possibility that someone man get electrified. Yeah, that's just silly. Before we upgrade something it's useful to ask the question of whether or not the upgrade is qualitatively better or not. Just because something comes down from upstream doesn't mean it's an improvement from our users' perspective. Based upon who's opinion, yours? There is that NPD kicking in again. Lets all bow down to Dough the magnificent. Only he is worthy to judge whether a port is deemed worthy of being updated. I am going to file a PR against this for insertion into the handbook. I know it will never get published, but it just another feel good thing. By the way, do you use bash? if not then what is your problem? If you do, have you read what the patches actually entail? I have. I already mentioned that I did review the patches. There is also the issue that in FreeBSD we are generally more conservative about upgrading something from a known-stable version. That is a lot about nothing. Postfix is updated in virtual real time. For every port that you can list that is left effectively abandoned for extended periods of time, I can produce one that is updated in a timely fashion. ... all of which would be totally irrelevant. Maintainers are responsible for deciding whether to update, and is so, when. They are also responsible for making sure that the new version is actually an improvement. For some ports/maintainers these are easy decisions. For others they may take time, and/or the maintainer themselves may have to prioritize the update amongst many other projects. So why not let the port maintainer express his feeling on this matter? Do you feel he is not capable, or should I say as capable as you of expressing his feelings? Getting information from the users as to why a particular update may have a higher priority than is obvious at first glance is very valuable to the maintainer. So you are proposing that ports only be updated when specifically requested by users? Again, the last Bash update took nearly a year. This one is several months old all ready. If the port is only going to be updated semi-annually, or annually, then it
Re: FreeBSD Port: bash-4.2.28
Kevin sorry for posting this from your message it had to go somewhere since there was no such great message to reply to. not intended directly toward anyone in general. This thread has turned to nothing but obnoxious dribble of what used to be a simple problem to solve. All of the bash-* patches that were inquired about are important to the user interface and some of them are directly related to most everyone. ESPECIALLY $HOME/ expansiion if I might need to state one. But let me state one thing here Ports is a framework containing lots of development. And justly it should not be judged that a port should not be upgraded because it might introduce new bugs to a stable community. Just because a port is being updated does not neccesarily mean that end-user needs to update their local install. It does mean that if its there it will get more exposure to further fixes... There are several ports which go head - head with the most current release that could stand to not be updated quite so often. So for what its worth Stop pu??y wiping ports! especially when it does not break the ports system itself. All this written from mutt(1) ontop of bash(1) 4.2.37(0)-release since Jul 17! On Sun, Jul 29, 2012 at 06:29:37PM -0700, Kevin Oberman wrote: On Sun, Jul 29, 2012 at 4:49 PM, Jerry je...@seibercom.net wrote: On Sun, 29 Jul 2012 15:42:38 -0700 Doug Barton articulated: Umm ... wow. I'll try to respond substantively below. On 07/29/2012 04:46, Jerry wrote: On Sat, 28 Jul 2012 16:54:40 -0700 (PDT) Doug Barton articulated: Completely aside from my being thoroughly impressed with your mind-reading abilities, upgrading to the latest/greatest is not always the best strategy. Speaking generally, even things that are (nominally) strictly bug fixes can bring in new problems, and Bash patches are not always strictly bug fixes. First of all, I see you CC'd me AGAIN. Obviously your comprehension skills are rather lax since I have a clearly noted request NOT to be CC'd and have in the past specifically asked you not to do so. I made a point of cc'ing you on my last message because I wanted to make sure you saw the bit about not using foul language. I appreciate you respecting that. First of all, lets make something clear, I have no respect for you. You are like a frigging kid. The only permanent solution is to smash your frigging head in with a bat. Oops, I hope I didn't offend you. Maybe you should CC your mother so she can protect you, you asshole. Meanwhile, yes, you've expressed a preference not to be cc'ed on list mail previously. Rather than trying to rehash the whole discussion, I'll simply repeat the main 2 points: 1. Asking the entire Internet to conform to your whim is not a rational strategy. 2. The FreeBSD mailman implementation allows you to specify only receiving 1 copy of a message that you are cc'ed on. Allow me to respond to that, BULLSHIT. Oh, did I offend you? I never asked the frigging entire Internet to bow down to my will; I simple asked not to be CC'd. Since you, most likely due to your NPD affiliation are unable to honor my simple request, why the frigging hell should I afford yours any traction? You do realize that you do not have to include my name in the CC line don't you? I took the time to relay your CC'd message to SpamCop. I know it won't do any good, but it is a feel good thing. Knock yourself out. :) Strictly speaking, it is none of your business if bug fixes can bring in or expose new or undiscovered problems. You keep repeating this none of your business line as if for some reason I don't have the right to ask the question. This is an open project, we can all ask questions. Ask question yes; stating that any patch or whatever not be instituted because it doesn't meet your standards is repulsive. (NPD strikes again) It has been shown throughout history that any advancement can bring with it, its own new set of problems. Should we all abandon the use of electricity because there is a real possibility that someone man get electrified. Yeah, that's just silly. Before we upgrade something it's useful to ask the question of whether or not the upgrade is qualitatively better or not. Just because something comes down from upstream doesn't mean it's an improvement from our users' perspective. Based upon who's opinion, yours? There is that NPD kicking in again. Lets all bow down to Dough the magnificent. Only he is worthy to judge whether a port is deemed worthy of being updated. I am going to file a PR against this for insertion into the handbook. I know it will never get published, but it just another feel good thing. By the way, do you use bash? if not then what is your problem? If you do, have you read what the patches actually entail? I have. I already mentioned that I did review the patches.
Re: [CFT] editors/emacs to 24.1
Hello Ashish; The patches applied successfully and the port installation was also successful, but when I try to run emacs with emacsclient -c, my system becomes semi-unresponsive. I can still hit the power button on my laptop for a clean shutdown but a C-c won't stop emacs and I can't log out of X. My best guess is this is related to the new Intel driver with GEM/KMS (although this has been my first problem after running it for a few months). Running emacsclient -t works fine. If I start emacs with just % emacs, and I don't wait to long, I can kill it with a C-c and the warning/error messages below appear in xterm: % emacs ^C (process:1589): GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit status can't be returned. This is a bug in the program calling g_spawn_sync(); ei ther don't request the exit status, or don't set the SIGCHLD action. (process:1589): GLib-GIO-CRITICAL **: g_dbus_connection_add_filter: assertion `G_IS_DBUS_CONNECTION (connection)' failed I'm on 9.0-STABLE amd64. Please let me know if I can provide any other information. Joseph ___ 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: [CFT] editors/emacs to 24.1
Joseph Mingrone j...@ftfl.ca writes: for a few months). Running emacsclient -t works fine. If I start emacs with just % emacs, and I don't wait to long, I can kill it with a C-c and the warning/error messages below appear in xterm: % emacs ^C (process:1589): GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit status can't be returned. This is a bug in the program calling g_spawn_sync(); ei ther don't request the exit status, or don't set the SIGCHLD action. (process:1589): GLib-GIO-CRITICAL **: g_dbus_connection_add_filter: assertion `G_IS_DBUS_CONNECTION (connection)' failed I don't use emacsclient myself, but I remember having some similar problems (and getting the g_spawn_sync() warning) when building the port (the current version in ports, not 24.1) with SYNC_INPUT=off. ___ 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
