Re: ports/171344: pkg_add -r xorg fails for freebsd 9 system
Synopsis: pkg_add -r xorg fails for freebsd 9 system State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Sun Jan 20 00:47:33 UTC 2013 State-Changed-Why: To submitter: has the advice in the Audit-Trail fixed your problem? Responsible-Changed-From-To: freebsd-ports->linimon Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 20 00:47:33 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=171344 ___ 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: building multimedia/vlc with clang on 9.1+
On Sun, Jan 20, 2013 at 12:12:03AM +0100, René Ladan wrote:
> On 19-01-2013 23:53, Juergen Lock wrote:
> > In article <50fb156a.5010...@gmail.com> you write:
> >> On 19-01-2013 22:09, Juergen Lock wrote:
> [...]
>
> >>
> >>> Index: Makefile
> >>> ===
> >>> RCS file: /home/pcvs/ports/multimedia/vlc/Makefile,v
> >>> retrieving revision 1.312
> >>> diff -u -p -r1.312 Makefile
> >>> --- Makefile 12 Jan 2013 20:25:57 - 1.312
> >>> +++ Makefile 19 Jan 2013 20:45:39 -
> >>> @@ -679,9 +679,16 @@ IGNORE= base clang version too old, set
> >>> CONFIGURE_ARGS+=--enable-altivec # VLC's config script doesn't know to
> >>> do this
> >>> .endif
> >>>
> >>> +# prefer clang on 9.1+
> >>> +.if (${OSVERSION} >= 901000) && exists(${DESTDIR}/usr/bin/clang)
> >>
> >> Not sure if this is the proper(TM) way to detect clang.
> >>> +CC= clang
> >>> +CXX= clang++
> >>> +CPP= clang-cpp
> >>> +.else
> >>> .if ${ARCH} == "i386"
> >>> USE_GCC?=4.6+ # sse/3dnow detection on i386 needs newer gcc
> >>
> >> See above, if on e.g. FreeBSD 12 the /usr/bin/clang file gets removed
> >> this makes the port always use GCC 4.6+
> >>
> > Hmm do you think this would happen? We still had /usr/bin/gcc hardlinked
> > to /usr/bin/cc the entire time we used gcc...
> >
> Not really, but it _could_ happen.
>
Well should that happen we can just stop setting CC since clang
will be default anyway...
Juergen
___
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: building multimedia/vlc with clang on 9.1+
On 19-01-2013 23:53, Juergen Lock wrote:
> In article <50fb156a.5010...@gmail.com> you write:
>> On 19-01-2013 22:09, Juergen Lock wrote:
[...]
>>
>>> Index: Makefile
>>> ===
>>> RCS file: /home/pcvs/ports/multimedia/vlc/Makefile,v
>>> retrieving revision 1.312
>>> diff -u -p -r1.312 Makefile
>>> --- Makefile12 Jan 2013 20:25:57 - 1.312
>>> +++ Makefile19 Jan 2013 20:45:39 -
>>> @@ -679,9 +679,16 @@ IGNORE=base clang version too old, set
>>> CONFIGURE_ARGS+=--enable-altivec # VLC's config script doesn't know to do
>>> this
>>> .endif
>>>
>>> +# prefer clang on 9.1+
>>> +.if (${OSVERSION} >= 901000) && exists(${DESTDIR}/usr/bin/clang)
>>
>> Not sure if this is the proper(TM) way to detect clang.
>>> +CC=clang
>>> +CXX= clang++
>>> +CPP= clang-cpp
>>> +.else
>>> .if ${ARCH} == "i386"
>>> USE_GCC?= 4.6+ # sse/3dnow detection on i386 needs newer gcc
>>
>> See above, if on e.g. FreeBSD 12 the /usr/bin/clang file gets removed
>> this makes the port always use GCC 4.6+
>>
> Hmm do you think this would happen? We still had /usr/bin/gcc hardlinked
> to /usr/bin/cc the entire time we used gcc...
>
Not really, but it _could_ happen.
René
___
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: building multimedia/vlc with clang on 9.1+
In article <50fb156a.5010...@gmail.com> you write:
>On 19-01-2013 22:09, Juergen Lock wrote:
>> Hi!
>>
>> As having to depend on gcc 4.6+ on i386 is kindof a waste on 9.1+
>> where we have clang too, and clang might generate better code than
>> the old gcc 4.2.1 in base on amd64 anyway I thought what if we have
>> the vlc port default to using clang on 9.1+ when it's available?
>> So I propse the patch below for testing by anyone on 9.1 or later,
>> also on i386 where I can't test myself, please report any issues
>> or regressions you find.
>>
>I've been running vlc on 10-amd64 with clang for a while now without any
>(serious) problems.
>
>> Index: Makefile
>> ===
>> RCS file: /home/pcvs/ports/multimedia/vlc/Makefile,v
>> retrieving revision 1.312
>> diff -u -p -r1.312 Makefile
>> --- Makefile 12 Jan 2013 20:25:57 - 1.312
>> +++ Makefile 19 Jan 2013 20:45:39 -
>> @@ -679,9 +679,16 @@ IGNORE= base clang version too old, set
>> CONFIGURE_ARGS+=--enable-altivec # VLC's config script doesn't know to do
>> this
>> .endif
>>
>> +# prefer clang on 9.1+
>> +.if (${OSVERSION} >= 901000) && exists(${DESTDIR}/usr/bin/clang)
>
>Not sure if this is the proper(TM) way to detect clang.
>> +CC= clang
>> +CXX=clang++
>> +CPP=clang-cpp
>> +.else
>> .if ${ARCH} == "i386"
>> USE_GCC?= 4.6+ # sse/3dnow detection on i386 needs newer gcc
>
>See above, if on e.g. FreeBSD 12 the /usr/bin/clang file gets removed
>this makes the port always use GCC 4.6+
>
Hmm do you think this would happen? We still had /usr/bin/gcc hardlinked
to /usr/bin/cc the entire time we used gcc...
Hmm,
Juergen
___
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 Grub 2.00
In article you write: >Hi, Hi! > >I would like know if there is any plans add Grub 2.00 to ports (instead of >1.98 currently). There is a PR open where patches have been posted, if you want to test 2.00 you are most welcome: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/170417 Patch against current 1.98 port also here: http://people.freebsd.org/~nox/tmp/grub-2.00-002.patch Thanx! :) Juergen ___ 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: building multimedia/vlc with clang on 9.1+
On 19-01-2013 22:09, Juergen Lock wrote:
> Hi!
>
> As having to depend on gcc 4.6+ on i386 is kindof a waste on 9.1+
> where we have clang too, and clang might generate better code than
> the old gcc 4.2.1 in base on amd64 anyway I thought what if we have
> the vlc port default to using clang on 9.1+ when it's available?
> So I propse the patch below for testing by anyone on 9.1 or later,
> also on i386 where I can't test myself, please report any issues
> or regressions you find.
>
I've been running vlc on 10-amd64 with clang for a while now without any
(serious) problems.
> Index: Makefile
> ===
> RCS file: /home/pcvs/ports/multimedia/vlc/Makefile,v
> retrieving revision 1.312
> diff -u -p -r1.312 Makefile
> --- Makefile 12 Jan 2013 20:25:57 - 1.312
> +++ Makefile 19 Jan 2013 20:45:39 -
> @@ -679,9 +679,16 @@ IGNORE= base clang version too old, set
> CONFIGURE_ARGS+=--enable-altivec # VLC's config script doesn't know to do
> this
> .endif
>
> +# prefer clang on 9.1+
> +.if (${OSVERSION} >= 901000) && exists(${DESTDIR}/usr/bin/clang)
Not sure if this is the proper(TM) way to detect clang.
> +CC= clang
> +CXX= clang++
> +CPP= clang-cpp
> +.else
> .if ${ARCH} == "i386"
> USE_GCC?=4.6+ # sse/3dnow detection on i386 needs newer gcc
See above, if on e.g. FreeBSD 12 the /usr/bin/clang file gets removed
this makes the port always use GCC 4.6+
> .endif
> +.endif
>
> # End OS specific hacks
>
René
___
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: Setting up tinderbox-devel on a pkgng system
On Saturday, 19 January 2013 16:10:38 Alexandr Kovalenko wrote: > On Sat, Jan 19, 2013 at 5:29 AM, David Naylor wrote: > > Another issue is that, by default, the port installs > > databases/p5-DBD-mysql which is not a recognised port. The attached > > patch fixes that [2]. > > I'm not sure where did you get your ports tree from, but it is > perfectly valid port, which also autodetects which version of MySQL is > used. > > http://svnweb.freebsd.org/ports/head/databases/p5-DBD-mysql/ > > > [2] I assumed that databases/p5-DBD-mysqlXY needs to correspond to > > databases/mysqlXY-client (no idea if that is a correct assumption). Apologies if I didn't explain myself properly. The issue is that tindexbox- devel does not recognise databases/p5-DBD-mysql as a valid port. See /usr/local/tinderbox/scripts/lib/db-mysql.sh:27 where it requires a port of format "databases/p5-DBD-mysql[456][0145]" which will not match databases/p5- DBD-mysql. # ls /usr/ports/databases/p5-DBD-mysql[456][0145] /usr/ports/databases/p5-DBD-mysql41: Makefile /usr/ports/databases/p5-DBD-mysql50: Makefile /usr/ports/databases/p5-DBD-mysql51: Makefile /usr/ports/databases/p5-DBD-mysql55: Makefile For clarity, on my system I get, for: # ls /usr/ports/databases/p5-DBD-mysql Makefile distinfo pkg-descr pkg-plist and that tinderbox-devel did install that port originally, until I make the change in the previously attached file. I hope this explains things better. Regards signature.asc Description: This is a digitally signed message part.
CFT: building multimedia/vlc with clang on 9.1+
Hi!
As having to depend on gcc 4.6+ on i386 is kindof a waste on 9.1+
where we have clang too, and clang might generate better code than
the old gcc 4.2.1 in base on amd64 anyway I thought what if we have
the vlc port default to using clang on 9.1+ when it's available?
So I propse the patch below for testing by anyone on 9.1 or later,
also on i386 where I can't test myself, please report any issues
or regressions you find.
Thanx!
Juergen
Index: Makefile
===
RCS file: /home/pcvs/ports/multimedia/vlc/Makefile,v
retrieving revision 1.312
diff -u -p -r1.312 Makefile
--- Makefile12 Jan 2013 20:25:57 - 1.312
+++ Makefile19 Jan 2013 20:45:39 -
@@ -679,9 +679,16 @@ IGNORE=base clang version too old, set
CONFIGURE_ARGS+=--enable-altivec # VLC's config script doesn't know to do this
.endif
+# prefer clang on 9.1+
+.if (${OSVERSION} >= 901000) && exists(${DESTDIR}/usr/bin/clang)
+CC=clang
+CXX= clang++
+CPP= clang-cpp
+.else
.if ${ARCH} == "i386"
USE_GCC?= 4.6+ # sse/3dnow detection on i386 needs newer gcc
.endif
+.endif
# End OS specific hacks
___
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"
www/opera ISSUE Java Plugin missing
Hi, I saw this thread on ports@ archive, and just resolved a similar issue, so FWIW: I have 2 systems, both i386, one 8-STABLE, the other 9-STABLE, where opera could not detect the icedtea-web plugin, but where this plugin could be used without problem by firefox. On both systems, icedtea-web had been build with USE_GCC=4.6. So today, I rebuilt icedtea-web with the standard compiler in the base system, and now the plugin is detected and works OK. I do not know the details of your installation, but a compiler mismatch may be the cause of your problem CBu ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ net/liveMedia | 2012.12.18 | 2013.01.19 +-+ net-p2p/libtorrent-rasterbar-15 | 0.15.9 | 0.16.7 +-+ net-p2p/libtorrent-rasterbar-15-python | 0.15.9 | 0.16.7 +-+ net-p2p/libtorrent-rasterbar-16 | 0.16.4 | 0.16.7 +-+ net-p2p/libtorrent-rasterbar-16-python | 0.16.4 | 0.16.7 +-+ news/newsstar | 1.5.4 | 1.5.5 +-+ science/gromacs | 4.5.5 | 4.6 +-+ x11-toolkits/p5-Wx | 0.97| 0.9916 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt If wish to stop receiving portscout reminders, please contact portsc...@portscout.freebsd.org Thanks. ___ 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: Circular port dependency
On 01/11/13 19:41, George Mitchell wrote:
On 01/11/13 03:22, Gleb Kurtsou wrote:
On (10/01/2013 20:21), George Mitchell wrote:
I grabbed the ports tree as of 308518, the RELEASE_9_1_0 tag.
devel/libtool won't build, because it requires autom4te during the
configure phase. So I put "BUILD_DEPENDS= autom4te:devel/autoconf"
in the Makefile. But autoconf depends on gmake, which depends on
gettext, which depends on libiconv, which depends on libtool.
What to do?
[...]
It turns out that my problem was due to compiling on the Raspberry
Pi, a machine that is slow enough that this post-configure target in
the port's top-level Makefile:
post-configure:
@${FIND} ${WRKSRC} -type f | ${XARGS} ${TOUCH} -f
could end up setting the last write time for config.status earlier than
the last write time for configure, thereby triggering this make rule in
the port's own Makefile:
$(top_builddir)/config.status: $(top_srcdir)/configure
$(CONFIG_STATUS_DEPENDENCIES)
$(SHELL) ./config.status --recheck
It's this "--recheck" that would cause the build to try to run autom4ke,
leading to the circular dependency. So the correct fix is as attached,
guaranteeing that the config.status modification time will always be
later.
I'm not entirely sure why the post-configure rule is there in the first
place, and svnweb.freebsd.org refuses to show me anything in
ports/head/devel below liglogging. I was trying to look at the log
for ports/devel/Makefile to see how the post-configure rule got there,
because simply removing it also appears to make the build succeed. But
I assume it's there for some reason, and this fix seems to be less
antagonistic than removing the whole rule.-- George
--- Makefile.orig 2013-01-10 19:56:02.0 -0500
+++ Makefile2013-01-19 09:44:24.0 -0500
@@ -34,6 +34,6 @@
${WRKSRC}/configure ${WRKSRC}/libltdl/configure
post-configure:
- @${FIND} ${WRKSRC} -type f | ${XARGS} ${TOUCH} -f
+ @${FIND} ${WRKSRC} -type f -name config.status | ${XARGS} ${TOUCH} -f
.include
___
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, bsd.lib.mk and NOPROFILE
Content-Type: text/plain; charset=ISO-8859-1 In message , Chris Rees writes: >> A good grep strategy is to look for files containing "NOPROFILE" and >> "bsd.lib.mk" but they need not be on the same line. Well, qmake includes "bsd.prog.mk"... >I'm running a grep for those two above-- are there any more I've missed? Those were the only ones I ran into... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: Setting up tinderbox-devel on a pkgng system
On Sat, Jan 19, 2013 at 5:29 AM, David Naylor wrote: > Another issue is that, by default, the port installs databases/p5-DBD-mysql > which is not a recognised port. The attached patch fixes that [2]. I'm not sure where did you get your ports tree from, but it is perfectly valid port, which also autodetects which version of MySQL is used. http://svnweb.freebsd.org/ports/head/databases/p5-DBD-mysql/ > [2] I assumed that databases/p5-DBD-mysqlXY needs to correspond to > databases/mysqlXY-client (no idea if that is a correct assumption). ___ 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, bsd.lib.mk and NOPROFILE
On 19 January 2013 01:45, Poul-Henning Kamp wrote: > > I just tried to build a system with -CURRENT from scratch, and it fell over > in graphics/gd because NOPROFILE is now named NO_PROFILE in bsd.lib.mk > > grep(1) tells me that a number of other ports will also have this problem > > It may be appropriate with a bandaid in bsd.lib.mk, which emits a noisy > warning, until all these ports are fixed. > > A good grep strategy is to look for files containing "NOPROFILE" and > "bsd.lib.mk" but they need not be on the same line. The two examples you showed in IRC didn't contain bsd.lib.mk-- but I see no problem in simply changing all the instances of NO(PROFILE|MAN) to NO_\1. We know that a bandaid is effectively a revert of the removal; would be better to simply fix the ports. Only issue is, this doesn't catch ports that use these variables in upstream; an exp-run is required for that... I'm running a grep for those two above-- are there any more I've missed? Chris ___ 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: graphics/hugin
On 18.01.2013 21:56 (UTC+2), Greg Larkin wrote: > On 1/18/13 1:34 PM, Rainer Hurling wrote: >> On 18.01.2013 18:48 (UTC+2), Greg Larkin wrote: >>> On 1/18/13 12:00 PM, Rainer Hurling wrote: On 18.01.2013 08:37 (UTC+2), Vasil Dimov wrote: > On Thu, Jan 17, 2013 at 16:34:59 -0600, ajtiM wrote: >> My system: 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue >> Dec 4 06:55:39 UTC 2012 >> r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >> i386 >> >> clang -v: FreeBSD clang version 3.1 (branches/release_31 >> 156863) 20120523 Target: i386-unknown-freebsd9.0 Thread >> model: posix >> >> I try to update hugin (Chase OpenEXR lib update) with clang >> but I got an error: >> >> >> In file included from >> /usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/vanilla/SimpleAtomicCount.cxx:26: >> >> >>> >> > /usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/../include/zthread/Guard.h:117:9: >>> >> error: void function 'createScope' should not return a >> value [-Wreturn-type] return false; ^ ~ >> /usr/ports/graphics/hugin/work/hugin-2011.4.0/src/foreign/zthread/src/../include/zthread/Guard.h:121:5: >> >> > error: void function 'createScope' should not return a value >> [-Wreturn-type] return true; ^ 2 errors >> generated. *** >> [src/foreign/zthread/src/CMakeFiles/ZThread.dir/AtomicCount.cxx.o] >> >> > Error code 1 > [...] > > Hello, > > Do you have > > CC=clang CXX=clang++ CPP=clang-cpp > > in your environment, e.g. /etc/make.conf ? > > hugin does not seem to compile with clang. I fixed the above > error but a set of another ones spills out. > > Can you try the attached patch which should force it to > compile with gcc and confirm whether it fixes the problem for > you? >>> Hi Vasil, >>> thanks for the patch for Makefile and src/foreign/flann/util/logger.h. Both works nice for me on recent 10.0-CURRENT amd64. >>> With USE_GCC=yes the patch uses lang/gcc46. Isn't USE_GCC=any also sufficient, so we can use systems compiler gcc-4.2.1, if present? >>> Rainer >>> > The clang compilation issues would better be addressed with > the hugin authors. > >>> >>> >>> >>> Hi all, > >> hi Greg, > >>> The build with clang dies inside of the zthread code included in >>> the hugin distro, and I wonder if it would be fixed with the same >>> patch that I committed to the devel/zthread port this week? > >> very nice idea and problably the right one. > >>> Here is the patch file for zthread's Guard.h file: >>> >>> http://svnweb.freebsd.org/ports/head/devel/zthread/files/patch-include__zthread__Guard.h?revision=310556&view=co > >>> >> I just tried your patch on hugin (my patch attached) with clang and >> it builds and installs fine. A quick test using hugin also seems to >> be ok. > >> I did not use your fourth item in patching Guard.h, because it is >> different from yours and should already ok for clang: > >> in zthreads Guard.h:l.494 -if(!isDisabled()) + >> if(!this->isDisabled()) LockingPolicy::destroyScope(*this); > >> in hugins Guard.h:l.494 if(!LockHolder::isDisabled()) >> LockingPolicy::destroyScope(*this); > >> This should be ok within hugins Guard.h. What do you think about >> it? > >> Many thanks, Rainer > >>> >>> Hope that helps, Greg > > Hi Rainer, > > Yes, your patch for Guard.h looks fine, and I think it should be > committed to the hugin port. I just filed PR 175427, hope this is ok. Rainer > Cheers, > Greg ___ 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"
