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 +-+ misc/freeswitch-scripts-devel | 1.2.3 | 1.2.19 +-+ net/freeswitch-curl-devel | 1.2.3 | 1.2.19 +-+ net/freeswitch-insideout-devel | 1.2.3 | 1.2.19 +-+ net/freeswitch-sbc-devel| 1.2.3 | 1.2.19 +-+ net/freeswitch-vanilla-devel| 1.2.3 | 1.2.19 +-+ www/quixote | 2.7 | 2.8 +-+ 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 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
Tr: mutt port broken with SLANG option [was mutt ports broke portupgrade]
Hello Udo,
I just committed a quick fix for this problem.
Could you please check it?
Thanks.
Le mer 5 fév 14 à 2:31:35 +0100, Bryan Drewery bdrew...@freebsd.org
écrivait :
On 2/4/2014 5:24 PM, Albert Shih wrote:
hi all,
mutt ports broke portuprade in the last update
[root@ /root]# portupgrade --all
[Reading data from pkg(8) ... - 886 packages found - done]
[Updating the portsdb format:dbm_hash in /usr/ports ... - 24579 port
entries found
.1000.2000.3000.4000.5000.6000.7000.8000.9000.1.11000.12000.13000.14000.15000.16000.17000.18000.19000.2.21000.22000.23000.24000.
. done]
Makefile, line 441: Unassociated shell command @${ECHO}
= ${PKGMESSAGE}
Makefile, line 442: Unassociated shell command @${ECHO} You have
installed ${PORTNAME} with SLANG support. ${PKGMESSAGE}
Makefile, line 443: Unassociated shell command @${ECHO} This may work
for a color terminal only when defining ${PKGMESSAGE}
Makefile, line 444: Unassociated shell command @${ECHO} COLORTERM=yes
and COLORFGBG=\color1;color2\ in your ${PKGMESSAGE}
Makefile, line 445: Unassociated shell command @${ECHO} environment.
${PKGMESSAGE}
Makefile, line 446: Unassociated shell command @${ECHO}
= ${PKGMESSAGE}
make: fatal errors encountered -- cannot continue
** Makefile possibly broken: mail/mutt:
** Please report this to the maintainer for mail/mutt
/usr/local/sbin/portupgrade:1580:in `get_pkgname': Makefile broken
(MakefileBrokenError)
from /usr/local/sbin/portupgrade:642:in `block (4 levels) in main'
from /usr/local/sbin/portupgrade:626:in `each'
from /usr/local/sbin/portupgrade:626:in `block (3 levels) in main'
from /usr/local/sbin/portupgrade:599:in `catch'
from /usr/local/sbin/portupgrade:599:in `block (2 levels) in main'
from /usr/local/lib/ruby/2.0/optparse.rb:1408:in `call'
from /usr/local/lib/ruby/2.0/optparse.rb:1408:in `block (2 levels)
in parse_in_order'
from /usr/local/lib/ruby/2.0/optparse.rb:1403:in `catch'
from /usr/local/lib/ruby/2.0/optparse.rb:1403:in `block in
parse_in_order'
from /usr/local/lib/ruby/2.0/optparse.rb:1351:in `catch'
from /usr/local/lib/ruby/2.0/optparse.rb:1351:in `parse_in_order'
from /usr/local/lib/ruby/2.0/optparse.rb:1345:in `order!'
from /usr/local/lib/ruby/2.0/optparse.rb:1337:in `order'
from /usr/local/sbin/portupgrade:576:in `block in main'
from /usr/local/lib/ruby/2.0/optparse.rb:885:in `initialize'
from /usr/local/sbin/portupgrade:237:in `new'
from /usr/local/sbin/portupgrade:237:in `main'
from /usr/local/sbin/portupgrade:2371:in `main'
Regards.
JAS
It's more than just portupgrade, the port is broken when you select the
SLANG option.
This block of code needs some help. The ECHO lines used to be in
post-install but are now orphaned, and the PKGMESSAGE seems orphaned
too, I can't find the actual file.
.if ${PORT_OPTIONS:MSLANG}
PKGMESSAGE= ${WRKDIR}/pkg-message
@${ECHO} =
${PKGMESSAGE}
@${ECHO} You have installed ${PORTNAME} with SLANG support.
${PKGMESSAGE}
@${ECHO} This may work for a color terminal only when defining
${PKGMESSAGE}
@${ECHO} COLORTERM=yes and COLORFGBG=\color1;color2\ in your
${PKGMESSAGE}
@${ECHO} environment. ${PKGMESSAGE}
@${ECHO} =
${PKGMESSAGE}
.endif
--
Regards,
Bryan Drewery
--
Th. Thomas.
pgpDHvlxoDN6N.pgp
Description: PGP signature
Re: databases/mysql56-client build failure on 9.2-STABLE i386
Greg Rivers ha scritto: The recent update from mysql56-client-5.6.15 to mysql56-client-5.6.16 fails to build on 9.2-STABLE i386. It builds fine on amd64 (both 9.2-STABLE and 10.0-STABLE). Unable to reproduce, it builds fine also on my 9.2-i386 poudriere jail. -- Alex Dupre ___ 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: databases/mysql56-client build failure on 9.2-STABLE i386
On 5/02/2014 3:47 AM, Greg Rivers wrote: The recent update from mysql56-client-5.6.15 to mysql56-client-5.6.16 fails to build on 9.2-STABLE i386. It builds fine on amd64 (both 9.2-STABLE and 10.0-STABLE). Here's the error: ... [ 10%] Built target yassl Scanning dependencies of target taocrypt [ 11%] Building CXX object extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/aes.cpp.o [ 11%] Building CXX object extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/aestables.cpp.o [ 12%] Building CXX object extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/algebra.cpp.o [ 12%] Building CXX object extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/arc4.cpp.o [ 12%] Building CXX object extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/asn.cpp.o [ 13%] Building CXX object extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/coding.cpp.o [ 13%] Building CXX object extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/des.cpp.o [ 13%] Building CXX object extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/dh.cpp.o [ 14%] Building CXX object extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/dsa.cpp.o [ 14%] Building CXX object extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/file.cpp.o [ 15%] Building CXX object extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/hash.cpp.o [ 15%] Building CXX object extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/integer.cpp.o /usr/ports/databases/mysql56-client/work/mysql-5.6.16/extra/yassl/taocrypt/src/integer.cpp: In function 'void TaoCrypt::P4_Mul(long long int __vector__*, const long long int __vector__*, const long long int __vector__*)': /usr/ports/databases/mysql56-client/work/mysql-5.6.16/extra/yassl/taocrypt/src/integer.cpp:1712: note: use -flax-vector-conversions to permit conversions between vectors with differing element types or numbers of subparts /usr/ports/databases/mysql56-client/work/mysql-5.6.16/extra/yassl/taocrypt/src/integer.cpp:1712: error: cannot convert 'int __vector__' to 'long long int __vector__' for argument '1' to 'long long int __vector__ __builtin_ia32_psrlqi128(long long int __vector__, int)' /usr/ports/databases/mysql56-client/work/mysql-5.6.16/extra/yassl/taocrypt/src/integer.cpp:1713: error: cannot convert 'int __vector__' to 'long long int __vector__' for argument '1' to 'long long int __vector__ __builtin_ia32_psrlqi128(long long int __vector__, int)' /usr/ports/databases/mysql56-client/work/mysql-5.6.16/extra/yassl/taocrypt/src/integer.cpp: At global scope: /usr/ports/databases/mysql56-client/work/mysql-5.6.16/extra/yassl/taocrypt/src/integer.cpp:1132: warning: 'TaoCrypt::s_RunAtStartupSetPentiumFunctionPointers' defined but not used *** [extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/integer.cpp.o] Error code 1 1 error *** [extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/all] Error code 2 1 error *** [all] Error code 2 1 error === Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** [do-build] Error code 1 Stop in /usr/ports/databases/mysql56-client. Is this a simple matter to fix, or should I open a PR? Greg, I too have built mysql-client using portmaster on an i386 machine, see -rw-r--r-- 1 root wheel11M Feb 3 13:14 /usr/packages/PRESCOTT/All/mysql56-client-5.6.16.tbz I've discovered that on a particularly busy build server, I've had to sprinkly MAKE_JOBS_UNSAFE=yes for 18 of the 135 ports requiring customisation. I don't think a PR is necessary, until you've used what the Makefile recommends. Regards, Dewayne. ___ 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
multimedia/phonon build fails
Seeing this when I try to build: Generating moc_statesvalidator_p.cpp [ 3%] Built target phonon_automoc Scanning dependencies of target phonon make: don't know how to make /usr/local/lib/qt4/libQtDeclarative.so. Stop *** Error code 2 1 error *** Error code 2 1 error === Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop in /usr/ports/multimedia/phonon. *** Error code 1 Stop in /usr/ports/multimedia/phonon. This is on a FreeBSD 8.x machine. Any help would be appreciated! ___ 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
Problem compiling Squid 3.x + TP_PF (FreeBSD 10)
Hello, i have a problem trying to install Squid 3.3 or Squid 3.2 from ports as a transparent proxy on a fresh installed FreeBSD 10 box. I have the whole system sources at /usr/src In the configure phase i got this error: --- configure: choosing user-specified net I/O API kqueue configure: Using kqueue for the IO loop. checking if setresuid is actually implemented... yes checking for constant CMSG_SPACE... no checking if strnstr is well implemented... no checking if va_copy is implemented... yes checking if __va_copy is implemented... yes configure: IPF-based transparent proxying enabled: no configure: error: PF-based transparent proxy requested but needed header not found === Script configure failed unexpectedly. Please report the problem to tms...@freebsd.org [maintainer] and attach the /usr/ports/www/squid33/work/squid-3.3.11/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 Stop. make[1]: stopped in /usr/ports/www/squid33 *** Error code 1 Stop. make: stopped in /usr/ports/www/squid33 - Any idea? Thanks signature.asc Description: OpenPGP digital signature
Adobe Flash update
Hi, A bbc news item reports that Adobe has released an emergency update to the flash player. http://www.bbc.co.uk/news/technology-26045740 . I haven't found any other information however there is a version bump on Adobe's download page to linux-f10-flashplugin-11.2r202.336. I downloaded install_flash_player_11_linux.i386.tar.gz and untarred it then: # cd /usr/ports/www/linux-f10-flashplugin11/ # make extract # cp -v ~chrisw/temp/flashplugin/libflashplayer.so /usr/ports/www/linux-f10-flashplugin11/work/ # cp -v ~chrisw/temp/flashplugin/readme.txt /usr/ports/www/linux-f10-flashplugin11/work/ cp -v ~chrisw/temp/flashplugin/usr/lib/kde4/kcm_adobe_flash_player.so /usr/ports/www/linux-f10-flashplugin11/work/usr/lib/kde4/kcm_adobe_flash_player.so # pkg delete linux-f10-flashplugin-11.2r202.335 # vi Makefile [ change version number to 336 ] # make install # pkg info -x flash linux-f10-flashplugin-11.2r202.336 And it seems to be working in firefox and opera. I can't find any other information about this so called emergency update, is the fact that there is a new version sufficient to request an update to the port? thanks 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: Samba to web
On 02/01/14 04:58, Anton Afanasyev wrote: Why not simply set up a web server with the same auth settings as in Samba? I though about this, but would rather use a dedicated tool. ... and you may end up having to maintain two sets of settings, This is exaclty what I'd like to avoid. That said, if you do end up using one of the solutions you mentioned (or similar), it would be great if you could provide some details (perf, your number of users, typical load, etc). I still have no figures, since the server is not yet in production; however user base will be very small and (I guess) the use of this tool very occasional. bye Thanks av. ___ 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: Adobe Flash update
On Wed, Feb 5, 2014 at 10:04 AM, Chris Whitehouse cwhi...@onetel.com wrote: Hi, And it seems to be working in firefox and opera. I can't find any other information about this so called emergency update, is the fact that there is a new version sufficient to request an update to the port? The last adobe security report I see was issued on 2014-02-04: http://helpx.adobe.com/security/products/flash-player/apsb14-04.html I'll update flash to .336. Thanks for the email. -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams ___ 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: Tr: mutt port broken with SLANG option [was mutt ports broke portupgrade]
Hi Thierry,
thanks a lot for that, I'm of cause completely OK with it.
Udo
On Wed, Feb 05, 2014 at 10:09:51 +0100, Thierry Thomas wrote:
Hello Udo,
I just committed a quick fix for this problem.
Could you please check it?
Thanks.
Le mer 5 fév 14 à 2:31:35 +0100, Bryan Drewery bdrew...@freebsd.org
écrivait :
On 2/4/2014 5:24 PM, Albert Shih wrote:
hi all,
mutt ports broke portuprade in the last update
[root@ /root]# portupgrade --all
[Reading data from pkg(8) ... - 886 packages found - done]
[Updating the portsdb format:dbm_hash in /usr/ports ... - 24579 port
entries found
.1000.2000.3000.4000.5000.6000.7000.8000.9000.1.11000.12000.13000.14000.15000.16000.17000.18000.19000.2.21000.22000.23000.24000.
. done]
Makefile, line 441: Unassociated shell command @${ECHO}
= ${PKGMESSAGE}
Makefile, line 442: Unassociated shell command @${ECHO} You have
installed ${PORTNAME} with SLANG support. ${PKGMESSAGE}
Makefile, line 443: Unassociated shell command @${ECHO} This may work
for a color terminal only when defining ${PKGMESSAGE}
Makefile, line 444: Unassociated shell command @${ECHO} COLORTERM=yes
and COLORFGBG=\color1;color2\ in your ${PKGMESSAGE}
Makefile, line 445: Unassociated shell command @${ECHO} environment.
${PKGMESSAGE}
Makefile, line 446: Unassociated shell command @${ECHO}
= ${PKGMESSAGE}
make: fatal errors encountered -- cannot continue
** Makefile possibly broken: mail/mutt:
** Please report this to the maintainer for mail/mutt
/usr/local/sbin/portupgrade:1580:in `get_pkgname': Makefile broken
(MakefileBrokenError)
from /usr/local/sbin/portupgrade:642:in `block (4 levels) in main'
from /usr/local/sbin/portupgrade:626:in `each'
from /usr/local/sbin/portupgrade:626:in `block (3 levels) in main'
from /usr/local/sbin/portupgrade:599:in `catch'
from /usr/local/sbin/portupgrade:599:in `block (2 levels) in main'
from /usr/local/lib/ruby/2.0/optparse.rb:1408:in `call'
from /usr/local/lib/ruby/2.0/optparse.rb:1408:in `block (2
levels) in parse_in_order'
from /usr/local/lib/ruby/2.0/optparse.rb:1403:in `catch'
from /usr/local/lib/ruby/2.0/optparse.rb:1403:in `block in
parse_in_order'
from /usr/local/lib/ruby/2.0/optparse.rb:1351:in `catch'
from /usr/local/lib/ruby/2.0/optparse.rb:1351:in `parse_in_order'
from /usr/local/lib/ruby/2.0/optparse.rb:1345:in `order!'
from /usr/local/lib/ruby/2.0/optparse.rb:1337:in `order'
from /usr/local/sbin/portupgrade:576:in `block in main'
from /usr/local/lib/ruby/2.0/optparse.rb:885:in `initialize'
from /usr/local/sbin/portupgrade:237:in `new'
from /usr/local/sbin/portupgrade:237:in `main'
from /usr/local/sbin/portupgrade:2371:in `main'
Regards.
JAS
It's more than just portupgrade, the port is broken when you select the
SLANG option.
This block of code needs some help. The ECHO lines used to be in
post-install but are now orphaned, and the PKGMESSAGE seems orphaned
too, I can't find the actual file.
.if ${PORT_OPTIONS:MSLANG}
PKGMESSAGE= ${WRKDIR}/pkg-message
@${ECHO} =
${PKGMESSAGE}
@${ECHO} You have installed ${PORTNAME} with SLANG support.
${PKGMESSAGE}
@${ECHO} This may work for a color terminal only when defining
${PKGMESSAGE}
@${ECHO} COLORTERM=yes and COLORFGBG=\color1;color2\ in your
${PKGMESSAGE}
@${ECHO} environment. ${PKGMESSAGE}
@${ECHO} =
${PKGMESSAGE}
.endif
--
Regards,
Bryan Drewery
--
Th. Thomas.
___
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: Adobe Flash update
On 05/02/2014 15:56, Eitan Adler wrote: On Wed, Feb 5, 2014 at 10:04 AM, Chris Whitehouse cwhi...@onetel.com wrote: Hi, And it seems to be working in firefox and opera. I can't find any other information about this so called emergency update, is the fact that there is a new version sufficient to request an update to the port? The last adobe security report I see was issued on 2014-02-04: http://helpx.adobe.com/security/products/flash-player/apsb14-04.html I'll update flash to .336. Thanks for the email. Thanks. 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: Sage update
On 02/05/2014 12:29 AM, Daniel Smith wrote: I just tested it on my box. It gets a lot further, but crashes when building scipy-0.12.0.p1. The only message in the log is a line indicating that the spkg-install script failed on a line reading python setup.py setup I'm currently working on digging through that file to see if I can figure out more, but I won't be able to do much before tomorrow, I'm afraid. I've attached the log file for details. I and one other person got the same error. I did try the patch /usr/ports/devel/scons/files/patch-engine-SCons-compat-_scons_subprocess.py, but it didn't help at all. If you type make again, I find that sage tries skipping the packages it failed to build in favor of other packages. In this manner, you can find that matplotlib-1.2.1 fails to build in exactly the same way. ___ 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 compiling Squid 3.x + TP_PF (FreeBSD 10)
On Wed, Feb 5, 2014 at 5:15 AM, Enrique Ayesta Perojo eaye...@portugalete.uned.es wrote: Hello, i have a problem trying to install Squid 3.3 or Squid 3.2 from ports as a transparent proxy on a fresh installed FreeBSD 10 box. I have the whole system sources at /usr/src In the configure phase i got this error: --- configure: choosing user-specified net I/O API kqueue configure: Using kqueue for the IO loop. checking if setresuid is actually implemented... yes checking for constant CMSG_SPACE... no checking if strnstr is well implemented... no checking if va_copy is implemented... yes checking if __va_copy is implemented... yes configure: IPF-based transparent proxying enabled: no configure: error: PF-based transparent proxy requested but needed header not found === Script configure failed unexpectedly. Please report the problem to tms...@freebsd.org [maintainer] and attach the /usr/ports/www/squid33/work/squid-3.3.11/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 Stop. make[1]: stopped in /usr/ports/www/squid33 *** Error code 1 Stop. make: stopped in /usr/ports/www/squid33 - Let's see. The instructions said to notify tms...@freebsd.org. I don't see any indication that you did so. They also say to attach the config.log file. I see no attached file. While it is possible that someone other than the maintainer of the port could help, without the log file, it's pretty unlikely. Please try again after reading and following what appear to be the clear instructions supplied in the error message. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: r341435: deletion of graphics/fotoxx
Am 28.01.2014 17:55, schrieb Rainer Hurling:
Am 28.01.2014 15:10, schrieb Baptiste Daroussin:
On Tue, Jan 28, 2014 at 03:07:46PM +0100, Rainer Hurling wrote:
Am 28.01.2014 13:48 (UTC+1) schrieb Dag-Erling Smørgrav:
Dag-Erling Smørgrav d...@des.no writes:
Actually, the file *is* 2696168 bytes long. With the following patch,
fetch(1) will still hang getting the last 1018 bytes, but the file will
be complete and the download will be successful.
Completely fixed (no hang, no missing data) in head@261230.
Wow, many thanks for the fix!
After rebuilding 11.0-CURRENT, I can confirm that fetch now is able to
load fotoxx-14.01.1.tar.gz as expected.
Eventually some of the fetch failures listed in the ports PR database
also depended on this behaviour before the fix?
Many thanks again. Now there is a real chance of an updated
graphics/fotoxx port :)
Can you update the patch for the PR to the 14.01.1 version while here maybe
you
want to add yourself as a maintainer :)
Hi Bapt,
I tried to create an update to version 14.01.1. What I did, was:
- update to version 14.01.1
- new mastersite; 2nd mastersites contents has to be updated
- unbreak the port
- modernize LIB_DEPENDS
- support STAGE_DIR
- strip bin/fotoxx
- correct usage of desktop-file-utils
- update URL in pkg-descr
- update pkg-plist
Known problems or TODOs:
- libexecinfo.so.1 is found in system and from port. No idea, which one
is the correct one to use (depending on OS version?).
- fotoxx now uses /proc for file operations. This was changed by the
author after version 11.03.
The updated port builds and installs fine for me (11.0-CURRENT).
Portlint complains about usage of .if ${PORT_OPTIONS:MDOCS} to wrap
installation of files into /usr/local/share/doc). Is this relevant and
what is necessary to consider it?
The diff is attached. I did not file a PR, because I think the usage of
/proc should be solved before. At runtime, the program is not fully
usable, because many functions try to get their info from /proc/...
I am not sure, if I am the right person to maintain the port. My skills
are very low (I am not a programmer, only an interested scientist ...)
and their are many things I do not fully understand.
Any help is really appreciated.
Greetings,
Rainer
regards,
Bapt
What do you think: Would it be better to put my draft of a patch and the
remarks from my precedent mail into an existing (PR 177643) or new PR to
not lose it?
All of us are very busy and there are many other things with much higher
priority to do ...
Looking forward to any answer.
Greetings,
Rainer
___
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: r341435: deletion of graphics/fotoxx
On Wed, Feb 05, 2014 at 07:10:01PM +0100, Rainer Hurling wrote:
Am 28.01.2014 17:55, schrieb Rainer Hurling:
Am 28.01.2014 15:10, schrieb Baptiste Daroussin:
On Tue, Jan 28, 2014 at 03:07:46PM +0100, Rainer Hurling wrote:
Am 28.01.2014 13:48 (UTC+1) schrieb Dag-Erling Smørgrav:
Dag-Erling Smørgrav d...@des.no writes:
Actually, the file *is* 2696168 bytes long. With the following patch,
fetch(1) will still hang getting the last 1018 bytes, but the file will
be complete and the download will be successful.
Completely fixed (no hang, no missing data) in head@261230.
Wow, many thanks for the fix!
After rebuilding 11.0-CURRENT, I can confirm that fetch now is able to
load fotoxx-14.01.1.tar.gz as expected.
Eventually some of the fetch failures listed in the ports PR database
also depended on this behaviour before the fix?
Many thanks again. Now there is a real chance of an updated
graphics/fotoxx port :)
Can you update the patch for the PR to the 14.01.1 version while here
maybe you
want to add yourself as a maintainer :)
Hi Bapt,
I tried to create an update to version 14.01.1. What I did, was:
- update to version 14.01.1
- new mastersite; 2nd mastersites contents has to be updated
- unbreak the port
- modernize LIB_DEPENDS
- support STAGE_DIR
- strip bin/fotoxx
- correct usage of desktop-file-utils
- update URL in pkg-descr
- update pkg-plist
Known problems or TODOs:
- libexecinfo.so.1 is found in system and from port. No idea, which one
is the correct one to use (depending on OS version?).
- fotoxx now uses /proc for file operations. This was changed by the
author after version 11.03.
The updated port builds and installs fine for me (11.0-CURRENT).
Portlint complains about usage of .if ${PORT_OPTIONS:MDOCS} to wrap
installation of files into /usr/local/share/doc). Is this relevant and
what is necessary to consider it?
The diff is attached. I did not file a PR, because I think the usage of
/proc should be solved before. At runtime, the program is not fully
usable, because many functions try to get their info from /proc/...
I am not sure, if I am the right person to maintain the port. My skills
are very low (I am not a programmer, only an interested scientist ...)
and their are many things I do not fully understand.
Any help is really appreciated.
Greetings,
Rainer
regards,
Bapt
What do you think: Would it be better to put my draft of a patch and the
remarks from my precedent mail into an existing (PR 177643) or new PR to
not lose it?
All of us are very busy and there are many other things with much higher
priority to do ...
Looking forward to any answer.
Greetings,
Rainer
Please followup on the same PR
regards,
Bapt
pgpoP88exhVT0.pgp
Description: PGP signature
graphics/rawtherapee: r342622 crashes on HEAD
Many thanks for the update of graphics/rawtherapee, r342622. This program is really important for photographers. It builds and installs just fine on recent HEAD amd64, but unfortunately it crashes immediately, when started. I tried to build rawtherapee and some of its dependencies with WITH_DEBUG=yes and then to have a look with gdb, but with only little luck. Obviously there is a problem with DWARF(?) and many libs without debug symbols? # gdb rawtherapee [..SNIP..] This GDB was configured as amd64-marcel-freebsd...Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/bin/rawtherapee] [..SNIP..] (gdb) r Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/lib/gcc48/libgcc_s.so.1] [..SNIP..] [New LWP 101478] [New Thread 4ec06400 (LWP 101478/rawtherapee)] Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/lib/gcc48/libgcc_s.so.1] [..SNIP..] Terminating due to uncaught exception 0x4fe78700 of type Glib::ConvertError Program received signal SIGABRT, Aborted. [Switching to Thread 4ec06400 (LWP 101478/rawtherapee)] 0x48b847ba in thr_kill () from /lib/libc.so.7 (gdb) bt full #0 0x48b847ba in thr_kill () from /lib/libc.so.7 No symbol table info available. #1 0x48c3b029 in abort () from /lib/libc.so.7 No symbol table info available. #2 0x484d37da in __cxa_rethrow () from /lib/libcxxrt.so.1 No symbol table info available. #3 0x423aa8f8 in Glib::ConvertError::throw_func () from /usr/local/lib/libglibmm-2.4.so.1 No symbol table info available. #4 0x423baa0f in Glib::Error::throw_exception () from /usr/local/lib/libglibmm-2.4.so.1 No symbol table info available. #5 0x423c60b4 in Glib::operator () from /usr/local/lib/libglibmm-2.4.so.1 No symbol table info available. #6 0x0064fce7 in ?? () No symbol table info available. #7 0x00fa7c00 in ?? () No symbol table info available. #8 0x7fffbae0 in ?? () No symbol table info available. #9 0x7fffbc00 in ?? () No symbol table info available. #10 0x0064f765 in ?? () No symbol table info available. #11 0x7fffbb00 in ?? () No symbol table info available. #12 0x00b8f988 in ?? () No symbol table info available. #13 0x00fa7c00 in ?? () No symbol table info available. #14 0x7fffbd70 in ?? () No symbol table info available. #15 0x00f853b8 in ?? () No symbol table info available. #16 0x00f85490 in ?? () No symbol table info available. #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 No symbol table info available. #18 0x in ?? () No symbol table info available. I know, that this output is only of little help. But I could need some advise what to do next to get more info. Any help is really appreciated. Thanks in advance, Rainer Hurling ___ 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: graphics/rawtherapee: r342622 crashes on HEAD
Am 05.02.2014 20:46, schrieb Rainer Hurling: Many thanks for the update of graphics/rawtherapee, r342622. This program is really important for photographers. It builds and installs just fine on recent HEAD amd64, but unfortunately it crashes immediately, when started. Rainer, I don't see the crash on FreeBSD 10.0-RELEASE amd64 and 9.2-RELEASE amd64 - those are versions I tried and where I could successfully open a Sony ARW file and click a few UI items. Note sure what 11 changed that it would break. I tried to build rawtherapee and some of its dependencies with WITH_DEBUG=yes and then to have a look with gdb, but with only little luck. Obviously there is a problem with DWARF(?) and many libs without debug symbols? It's rather that the base /usr/bin/gdb cannot deal with the newer debug symbol formats... # gdb rawtherapee [..SNIP..] This GDB was configured as amd64-marcel-freebsd...Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/bin/rawtherapee] [..SNIP..] ...do you have more luck with gdb built from the ports collection (devel/gdb), which is version 7.6.2, as opposed to the base system gdb 6.1.1? Also, if you recompile rawtherapee without the highly aggressive compiler flags, does that help? I saw warnings about undefined behaviour in aggressive loop optimization, not sure if those are the culprit. If they are, we might need to tune down optimization a bit. Thanks. Cheers, Matthias ___ 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: graphics/rawtherapee: r342622 crashes on HEAD
On 05 Feb 2014, at 20:46, Rainer Hurling rhur...@gwdg.de wrote: Many thanks for the update of graphics/rawtherapee, r342622. This program is really important for photographers. It builds and installs just fine on recent HEAD amd64, but unfortunately it crashes immediately, when started. I tried to build rawtherapee and some of its dependencies with WITH_DEBUG=yes and then to have a look with gdb, but with only little luck. Obviously there is a problem with DWARF(?) and many libs without debug symbols? It looks like you have built the port with gcc 4.8, which defaults to DWARF4 format. Our gdb in base is too old to understand this format, so just install devel/gdb76 instead. # gdb rawtherapee ... #3 0x423aa8f8 in Glib::ConvertError::throw_func () from /usr/local/lib/libglibmm-2.4.so.1 No symbol table info available. #4 0x423baa0f in Glib::Error::throw_exception () from /usr/local/lib/libglibmm-2.4.so.1 No symbol table info available. #5 0x423c60b4 in Glib::operator () from /usr/local/lib/libglibmm-2.4.so.1 Looks like that operator encountered something it cannot handle, so it throws an exception, and nobody seems to catch it. But more information from a backtrace in gdb 7.6 could possibly help. ... #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 Hmm, is this a ports version of libc++? I was not aware Baptiste had already committed this? :) -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 05.02.2014 21:08, schrieb Dimitry Andric: #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 Hmm, is this a ports version of libc++? I was not aware Baptiste had already committed this? :) Yes, it is (as a build requisite, but apparently remained installed on the destination machine), because we need to match the libraries that the requisites use (Glibmm for one). I have given up on compiling RawTherapee with clang++ for now, and use GCC 4.8 on all systems. RawTherapee is somewhat demanding, especially at higher optimization level, and kills the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with internal compiler errors. Since GCC 4.8 worked for me, I did not bother to send Gerald the details. We may want to retry with clang if we've got the next clang version. Feel free to use Rawtherapee as compiler system test ;) signature.asc Description: OpenPGP digital signature
Re: r341435: deletion of graphics/fotoxx
Am 05.02.2014 20:36, schrieb Baptiste Daroussin:
On Wed, Feb 05, 2014 at 07:10:01PM +0100, Rainer Hurling wrote:
Am 28.01.2014 17:55, schrieb Rainer Hurling:
Am 28.01.2014 15:10, schrieb Baptiste Daroussin:
On Tue, Jan 28, 2014 at 03:07:46PM +0100, Rainer Hurling wrote:
Am 28.01.2014 13:48 (UTC+1) schrieb Dag-Erling Smørgrav:
Dag-Erling Smørgrav d...@des.no writes:
Actually, the file *is* 2696168 bytes long. With the following patch,
fetch(1) will still hang getting the last 1018 bytes, but the file will
be complete and the download will be successful.
Completely fixed (no hang, no missing data) in head@261230.
Wow, many thanks for the fix!
After rebuilding 11.0-CURRENT, I can confirm that fetch now is able to
load fotoxx-14.01.1.tar.gz as expected.
Eventually some of the fetch failures listed in the ports PR database
also depended on this behaviour before the fix?
Many thanks again. Now there is a real chance of an updated
graphics/fotoxx port :)
Can you update the patch for the PR to the 14.01.1 version while here
maybe you
want to add yourself as a maintainer :)
Hi Bapt,
I tried to create an update to version 14.01.1. What I did, was:
- update to version 14.01.1
- new mastersite; 2nd mastersites contents has to be updated
- unbreak the port
- modernize LIB_DEPENDS
- support STAGE_DIR
- strip bin/fotoxx
- correct usage of desktop-file-utils
- update URL in pkg-descr
- update pkg-plist
Known problems or TODOs:
- libexecinfo.so.1 is found in system and from port. No idea, which one
is the correct one to use (depending on OS version?).
- fotoxx now uses /proc for file operations. This was changed by the
author after version 11.03.
The updated port builds and installs fine for me (11.0-CURRENT).
Portlint complains about usage of .if ${PORT_OPTIONS:MDOCS} to wrap
installation of files into /usr/local/share/doc). Is this relevant and
what is necessary to consider it?
The diff is attached. I did not file a PR, because I think the usage of
/proc should be solved before. At runtime, the program is not fully
usable, because many functions try to get their info from /proc/...
I am not sure, if I am the right person to maintain the port. My skills
are very low (I am not a programmer, only an interested scientist ...)
and their are many things I do not fully understand.
Any help is really appreciated.
Greetings,
Rainer
regards,
Bapt
What do you think: Would it be better to put my draft of a patch and the
remarks from my precedent mail into an existing (PR 177643) or new PR to
not lose it?
All of us are very busy and there are many other things with much higher
priority to do ...
Looking forward to any answer.
Greetings,
Rainer
Please followup on the same PR
Thanks for answering. I attached the patch to PR ports/177643 with some
info around it.
Regards,
Rainer
regards,
Bapt
___
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
[QAT] r342699: 4x leftovers, 56x success
- Stage support - Build ID: 20140205134600-27713 Job owner: m...@freebsd.org Buildtime: 7 hours Enddate: Wed, 05 Feb 2014 20:40:57 GMT Revision: r342699 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=342699 - Port:audio/espeak 1.47.11 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270788/espeak-1.47.11.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270789/espeak-1.47.11.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270790/espeak-1.47.11.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270791/espeak-1.47.11.log - Port:devel/oniguruma4 4.7.1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270792/oniguruma4-4.7.1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270793/oniguruma4-4.7.1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270794/oniguruma4-4.7.1.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270795/oniguruma4-4.7.1.log - Port:devel/p5-Class-Accessor-Lvalue 0.11 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270796/p5-Class-Accessor-Lvalue-0.11.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270797/p5-Class-Accessor-Lvalue-0.11.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270798/p5-Class-Accessor-Lvalue-0.11.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270799/p5-Class-Accessor-Lvalue-0.11.log - Port:devel/p5-Data-TreeDumper 0.40_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270800/p5-Data-TreeDumper-0.40_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270801/p5-Data-TreeDumper-0.40_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270802/p5-Data-TreeDumper-0.40_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270803/p5-Data-TreeDumper-0.40_1.log - Port:devel/p5-Log-Dispatchouli 2.006 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270804/p5-Log-Dispatchouli-2.006.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270805/p5-Log-Dispatchouli-2.006.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270806/p5-Log-Dispatchouli-2.006.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270807/p5-Log-Dispatchouli-2.006.log - Port:devel/p5-MooseX-Types-Perl 0.101341 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270808/p5-MooseX-Types-Perl-0.101341.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140205134600-27713-270809/p5-MooseX-Types-Perl-0.101341.log
Re: graphics/rawtherapee: r342622 crashes on HEAD
Hi Matthias,
thanks for answering.
Am 05.02.2014 21:03, schrieb Matthias Andree:
Am 05.02.2014 20:46, schrieb Rainer Hurling:
Many thanks for the update of graphics/rawtherapee, r342622. This
program is really important for photographers.
It builds and installs just fine on recent HEAD amd64, but unfortunately
it crashes immediately, when started.
Rainer,
I don't see the crash on FreeBSD 10.0-RELEASE amd64 and 9.2-RELEASE
amd64 - those are versions I tried and where I could successfully open a
Sony ARW file and click a few UI items. Note sure what 11 changed that
it would break.
I tried to build rawtherapee and some of its dependencies with
WITH_DEBUG=yes and then to have a look with gdb, but with only little
luck. Obviously there is a problem with DWARF(?) and many libs without
debug symbols?
It's rather that the base /usr/bin/gdb cannot deal with the newer debug
symbol formats...
# gdb rawtherapee
[..SNIP..]
This GDB was configured as amd64-marcel-freebsd...Dwarf Error: wrong
version in compilation unit header (is 4, should be 2) [in module
/usr/local/bin/rawtherapee]
[..SNIP..]
...do you have more luck with gdb built from the ports collection
(devel/gdb), which is version 7.6.2, as opposed to the base system gdb
6.1.1?
Okay, here it comes. RawTherapee from before, with newer gdb:
#gdb762 rawtherapee
GNU gdb (GDB) 7.6.2 [GDB v7.6.2 for FreeBSD]
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-portbld-freebsd11.0.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/local/bin/rawtherapee...done.
(gdb) r
Starting program: /usr/local/bin/rawtherapee
[New LWP 100312]
[New Thread 4ec06400 (LWP 100312)]
Terminating due to uncaught exception 0x4fe78700 of type Glib::ConvertError
Program received signal SIGABRT, Aborted.
[Switching to Thread 4ec06400 (LWP 100312)]
0x48b847ba in thr_kill () from /lib/libc.so.7
(gdb) bt full
#0 0x48b847ba in thr_kill () from /lib/libc.so.7
No symbol table info available.
#1 0x48c3b029 in abort () from /lib/libc.so.7
No symbol table info available.
#2 0x484d37da in ?? () from /lib/libcxxrt.so.1
No symbol table info available.
#3 0x423aa8f8 in Glib::ConvertError::throw_func(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1
No symbol table info available.
#4 0x423baa0f in Glib::Error::throw_exception(_GError*) () from
/usr/local/lib/libglibmm-2.4.so.1
No symbol table info available.
#5 0x423c60b4 in
Glib::operator(std::__1::basic_ostreamwchar_t,
std::__1::char_traitswchar_t , Glib::ustring const) () from
/usr/local/lib/libglibmm-2.4.so.1
No symbol table info available.
#6 0x0064fce7 in
Glib::ustring::FormatStream::streamGlib::ustring (this=0x7fffbae0,
value=...) at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1057
No locals.
#7 0x0064f765 in Glib::ustring::formatGlib::ustring, char [9]
(a1=..., a2=...) at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1145
buf = {stream_ =
{std::__1::basic_ostreamwchar_t, std::__1::char_traitswchar_t
= {std::__1::basic_ioswchar_t, std::__1::char_traitswchar_t =
{std::__1::ios_base = {No data fields}, __tie_ = 0x0,
__fill_ = -1}, _vptr.basic_ostream = 0xf853b8 vtable
for std::__1::basic_ostringstreamwchar_t,
std::__1::char_traitswchar_t, std::__1::allocatorwchar_t +24},
__sb_ = {std::__1::basic_streambufwchar_t,
std::__1::char_traitswchar_t = {
_vptr.basic_streambuf = 0xf85490 vtable for
std::__1::basic_stringbufwchar_t, std::__1::char_traitswchar_t,
std::__1::allocatorwchar_t +16, __loc_ = {static none = 0,
static collate = 1, static ctype = 2, static monetary
= 8, static numeric = 16, static time = 32, static messages = 4, static
all = 63, __locale_ = 0x484c0ee0}, __binp_ = 0x0,
__ninp_ = 0x0, __einp_ = 0x0, __bout_ = 0x7fffbb2c
L, __nout_ = 0x7fffbb2c L, __eout_ = 0x7fffbb3c L},
__str_ = {std::__1::__basic_string_commontrue = {No
data fields},
__r_ =
{std::__1::__libcpp_compressed_pair_impstd::__1::basic_stringwchar_t,
std::__1::char_traitswchar_t, std::__1::allocatorwchar_t ::__rep,
std::__1::allocatorwchar_t, 2u = {std::__1::allocatorwchar_t =
{No data fields}, __first_ = {{__l = {__cap_ = 8, __size_ = 0, __data_
= 0x0}, __s = {{__size_ = 8 '\b', __lx = 8 L'\b\000\000\000'},
__data_ = L'\000' repeats 16 times}, __r =
{__words = {8, 0, 0}, No data fields}, static npos =
18446744073709551615}, __hm_ = 0x7fffbb2c L, __mode_ = 16}}}
#8 0x0064c798 in RTImage::setPaths (opt=...) at
Making WebRTC available for FreeBSD
https://plus.google.com/110946378055202199166/posts/8iTsSCatk4x The process has been started : http://forums.freebsd.org/viewtopic.php?f=39t=44691 Dependencies needed- referenced in howto and webrtc dependencies: libbrlapi from brltty. Benefits: Native client and sever side of WebRTC applications for FreeBSD and possibly other BSDs. Eliminated dependency for Linuixlator based applications thus cutting down on hardware resource use. Eliminated need for other simulated and emulated programs to run Skype or other voice-and-video binaries. I.e. Wine, VirtualBox, qemu, et cetera, et al. Since it is known that Sony's PS4 uses FreeBSD as the basis for its OS, WebRTC could be implemented as a native application on the platform/console thus allowing users to communicater in real time while gaming. Why am I proposing this? 1. Adrian Chadd asked on Google+ and nowhere else. I decided to bring his proposal to the public and attempt an initial starting phase. 2. Users would not be limited to having only a few selected operating systems at their disposal. Developers could easily communicate with each other. 3. Real time sharing/viewing of conventions. This would give the community another window into the development of FreeBSD. 4. Companies such as IxSystems and Sony would be able to contact develoers while simultaneously working on a FreeBSD/FreeBSD_based system. 5. FreeBSD developers would be able to give feedback on the development of WebRTC sources. Being that I am limited on resources, is it possible that others could take over what was started? ___ 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: graphics/rawtherapee: r342622 crashes on HEAD
On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote: Am 05.02.2014 21:08, schrieb Dimitry Andric: #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 Hmm, is this a ports version of libc++? I was not aware Baptiste had already committed this? :) Yes, it is (as a build requisite, but apparently remained installed on the destination machine), because we need to match the libraries that the requisites use (Glibmm for one). I have given up on compiling RawTherapee with clang++ for now, and use GCC 4.8 on all systems. RawTherapee is somewhat demanding, especially at higher optimization level, and kills the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with internal compiler errors. Since GCC 4.8 worked for me, I did not bother to send Gerald the details. We may want to retry with clang if we've got the next clang version. Feel free to use Rawtherapee as compiler system test ;) try with something like this in libmap.conf libc++.so.1 /usr/local/lib/libc++.so.1 If that fixes the problem, then a rpath with /usr/local/lib should be set while building the port regards, Bapt pgpKFNMduTtRB.pgp Description: PGP signature
Re: Making WebRTC available for FreeBSD
Hey guys, not sure what this refers to. The G+ post talks about porting the gtalk plugin to freeBSD. WebRTC is an effort in the opposite direction (no plugins needed). Afaik there is a Chromium build for freeBSD that should support WebRTC (unless it's disabled at build). Niklas On Wed, Feb 5, 2014 at 1:14 PM, Joe Nosay superbisq...@gmail.com wrote: https://plus.google.com/110946378055202199166/posts/8iTsSCatk4x The process has been started : http://forums.freebsd.org/viewtopic.php?f=39t=44691 Dependencies needed- referenced in howto and webrtc dependencies: libbrlapi from brltty. Benefits: Native client and sever side of WebRTC applications for FreeBSD and possibly other BSDs. Eliminated dependency for Linuixlator based applications thus cutting down on hardware resource use. Eliminated need for other simulated and emulated programs to run Skype or other voice-and-video binaries. I.e. Wine, VirtualBox, qemu, et cetera, et al. Since it is known that Sony's PS4 uses FreeBSD as the basis for its OS, WebRTC could be implemented as a native application on the platform/console thus allowing users to communicater in real time while gaming. Why am I proposing this? 1. Adrian Chadd asked on Google+ and nowhere else. I decided to bring his proposal to the public and attempt an initial starting phase. 2. Users would not be limited to having only a few selected operating systems at their disposal. Developers could easily communicate with each other. 3. Real time sharing/viewing of conventions. This would give the community another window into the development of FreeBSD. 4. Companies such as IxSystems and Sony would be able to contact develoers while simultaneously working on a FreeBSD/FreeBSD_based system. 5. FreeBSD developers would be able to give feedback on the development of WebRTC sources. Being that I am limited on resources, is it possible that others could take over what was started? ___ 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: Making WebRTC available for FreeBSD
https://code.google.com/p/chromium/codesearch#search/q=enable_webrtcsq=package:chromiumtype=cs On Wed, Feb 5, 2014 at 1:33 PM, Joe Nosay superbisq...@gmail.com wrote: On Wed, Feb 5, 2014 at 4:27 PM, Niklas Enbom niklas.en...@webrtc.orgwrote: Hey guys, not sure what this refers to. The G+ post talks about porting the gtalk plugin to freeBSD. WebRTC is an effort in the opposite direction (no plugins needed). Afaik there is a Chromium build for freeBSD that should support WebRTC (unless it's disabled at build). Niklas On Wed, Feb 5, 2014 at 1:14 PM, Joe Nosay superbisq...@gmail.com wrote: https://plus.google.com/110946378055202199166/posts/8iTsSCatk4x The process has been started : http://forums.freebsd.org/viewtopic.php?f=39t=44691 Dependencies needed- referenced in howto and webrtc dependencies: libbrlapi from brltty. Benefits: Native client and sever side of WebRTC applications for FreeBSD and possibly other BSDs. Eliminated dependency for Linuixlator based applications thus cutting down on hardware resource use. Eliminated need for other simulated and emulated programs to run Skype or other voice-and-video binaries. I.e. Wine, VirtualBox, qemu, et cetera, et al. Since it is known that Sony's PS4 uses FreeBSD as the basis for its OS, WebRTC could be implemented as a native application on the platform/console thus allowing users to communicater in real time while gaming. Why am I proposing this? 1. Adrian Chadd asked on Google+ and nowhere else. I decided to bring his proposal to the public and attempt an initial starting phase. 2. Users would not be limited to having only a few selected operating systems at their disposal. Developers could easily communicate with each other. 3. Real time sharing/viewing of conventions. This would give the community another window into the development of FreeBSD. 4. Companies such as IxSystems and Sony would be able to contact develoers while simultaneously working on a FreeBSD/FreeBSD_based system. 5. FreeBSD developers would be able to give feedback on the development of WebRTC sources. Being that I am limited on resources, is it possible that others could take over what was started? How is it implemented at build time? ___ 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: Making WebRTC available for FreeBSD
On Wed, Feb 5, 2014 at 10:27 PM, Niklas Enbom niklas.en...@webrtc.org wrote: Hey guys, not sure what this refers to. The G+ post talks about porting the gtalk plugin to freeBSD. WebRTC is an effort in the opposite direction (no plugins needed). Afaik there is a Chromium build for freeBSD that should support WebRTC (unless it's disabled at build). Niklas WebRTC on FreeBSD YES YES YES!!! =) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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-Ports-Announce] Time to bid farewell to the old pkg_ tools
Matthew Seaman wrote: On 03/02/2014 21:24, Julian H. Stacey wrote: be beneficial in a very short amount of time. Even if you prefer to compile from source, =20 I use source, rarely if ever use packages, (except pkg_delete to remove old broken dependencies). No opinion which scrips are better.= =20 =20 you will still reap the benefits of the modern packaging system. =20 In 10.0 FreeBSD `reaped the benefit` of a default new horrible registry that smells like Microsoft with quasi binary local.sqlite needing special tools. (Yes I know there's an export function.) =20 For 2 decade we've poured scorn on Microsoft its opaque easily damaged hard to access registry, lauded how with FreeBSD we can examine manipulate repair our text based equivalent with any number of personal choice text tools, now FreeSBD is burdened by this horrible Microsoft style registry. You're being absurd. Immediately personal criticism is a poor way to start convincing. ports/ is not just for package addicts. I never install packages, but only build install from ports/. sqlite junk obstructs /var/db/pkg being accessed by find grep to debug breaking ports builds. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with . Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ 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
More fun (and work) for porters (DARPA projects)
Hi all, DARPA recently released a catalog of 60 projects funded by the institution. Quite a few of them are Python-based and some are focused on handling large amounts of data. ¿Is it possible/interesting to add this projects to the WantedPorts page[2]? Regards [1] https://wiki.freebsd.org/WantedPorts [2] http://www.darpa.mil/OpenCatalog/index.html ___ 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-Ports-Announce] Time to bid farewell to the old pkg_ tools
- Original Message - From: Julian H. Stacey j...@berklix.com Immediately personal criticism is a poor way to start convincing. ports/ is not just for package addicts. I never install packages, but only build install from ports/. sqlite junk obstructs /var/db/pkg being accessed by find grep to debug breaking ports builds. We also maintain all our machines from in house built ports but I must say in the 10 years I've never used find / grep on /var/db/pkg to debug breaking port builds. Everyone works differently, so we may be unique here, but surely if the tools still exist to determine the issue e.g. sqlite queries, along side the clear advantages the new storage brings, I'm not sure what the issue is? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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-Ports-Announce] Time to bid farewell to the old pkg_ tools
ports/ is not just for package addicts. I never install packages, but only build install from ports/. sqlite junk obstructs /var/db/pkg being accessed by find grep to debug breaking ports builds. As someone who has advocated the use of sqlite to replace the old database in the filesystem several years before it has been implemented by the new package system, i can only conclude, like Matthew that you are being absurd. The old package system was total crap, incredibly slow and using system resources in absurd ways. Sqlite obstructs nothing, you have to spend a couple of minutes learning the basic SQL queries, which is no more difficult that learning obtuse find and grep options. Moreover i have hard time believing one needs to dissect the package system (beyond reading the output of pkg info) to debug a port build. One surely needs some knowledge of make, C, perhaps C++ which is vastly more difficult than figuring how to extract the content of the sqlite database. Finally i confess i am a package addict. Insisting that people use packages is the best way to ensure that the ports can indeed be built and that the result works. I have spent too many hours editing C files and makefiles in the past in the hope of getting something to build, now i want that it just works, like it does with the likes of Debian, etc. I am very grateful to Baptiste, Matthew and al. to the excellent job they have done, finally FreeBSD has a decent infrastructure for external software. The new package system is fast, efficient, and very importantly lists all the things it will do before doing them (like Debian apt), which allows to avoid ruining a working system, a very common occurrence in the old package system. So it does most of the things that i thought were necessary to come to parity with apt, and is light years ahead of the old system. -- Michel Talon ta...@lpthe.jussieu.fr smime.p7s Description: S/MIME cryptographic signature
Re: graphics/rawtherapee: r342622 crashes on HEAD
Hi Rainer,
this is more useful as a backtrace in itself, but I don't know how to
make heads or tails of it; the interesting parts appear to be in frames
#5 (meaning that you might need to reinstall glibmm WITH_DEBUG=yes) and
#8/#9 (where the whole call chain starts).
I can say that rawtherapee starts properly for me on 9.2-RELEASE and
10.0-RELEASE amd64 (the former has packages built from source, the
latter uses binary packages installed with pkg upgrade), even with
aggressive optimization.
Unfortunately, I do not have the time to debug highly complex ports on
any STABLE/UNSTABLE/HEAD tree. My ports work is limited to what I can do
on -RELEASE.
So I propose to
1. first trying the libc++.so mapping that Baptiste Daroussin has
proposed, and if that does not help,
2. hack the Makefile to use only -O for optimization and then see in the
frames #9/#8 if the string passed down is properly initialized, and in
frame #5 what data arrives and why glibmm fails to convert it.
Also make sure that all requisites of rawtherapee are up to date, there
have been many changes to a few of the requisites lately.
Okay, here it comes. RawTherapee from before, with newer gdb:
Terminating due to uncaught exception 0x4fe78700 of type Glib::ConvertError
Program received signal SIGABRT, Aborted.
...
No symbol table info available.
#3 0x423aa8f8 in Glib::ConvertError::throw_func(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1
No symbol table info available.
#4 0x423baa0f in Glib::Error::throw_exception(_GError*) () from
/usr/local/lib/libglibmm-2.4.so.1
No symbol table info available.
#5 0x423c60b4 in
Glib::operator(std::__1::basic_ostreamwchar_t,
std::__1::char_traitswchar_t , Glib::ustring const) () from
/usr/local/lib/libglibmm-2.4.so.1
No symbol table info available.
#6 0x0064fce7 in
Glib::ustring::FormatStream::streamGlib::ustring (this=0x7fffbae0,
value=...) at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1057
No locals.
#7 0x0064f765 in Glib::ustring::formatGlib::ustring, char [9]
(a1=..., a2=...) at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1145
buf = {stream_ =
{std::__1::basic_ostreamwchar_t, std::__1::char_traitswchar_t
= {std::__1::basic_ioswchar_t, std::__1::char_traitswchar_t =
{std::__1::ios_base = {No data fields}, __tie_ = 0x0,
__fill_ = -1}, _vptr.basic_ostream = 0xf853b8 vtable
for std::__1::basic_ostringstreamwchar_t,
std::__1::char_traitswchar_t, std::__1::allocatorwchar_t +24},
__sb_ = {std::__1::basic_streambufwchar_t,
std::__1::char_traitswchar_t = {
_vptr.basic_streambuf = 0xf85490 vtable for
std::__1::basic_stringbufwchar_t, std::__1::char_traitswchar_t,
std::__1::allocatorwchar_t +16, __loc_ = {static none = 0,
static collate = 1, static ctype = 2, static monetary
= 8, static numeric = 16, static time = 32, static messages = 4, static
all = 63, __locale_ = 0x484c0ee0}, __binp_ = 0x0,
__ninp_ = 0x0, __einp_ = 0x0, __bout_ = 0x7fffbb2c
L, __nout_ = 0x7fffbb2c L, __eout_ = 0x7fffbb3c L},
__str_ = {std::__1::__basic_string_commontrue = {No
data fields},
__r_ =
{std::__1::__libcpp_compressed_pair_impstd::__1::basic_stringwchar_t,
std::__1::char_traitswchar_t, std::__1::allocatorwchar_t ::__rep,
std::__1::allocatorwchar_t, 2u = {std::__1::allocatorwchar_t =
{No data fields}, __first_ = {{__l = {__cap_ = 8, __size_ = 0, __data_
= 0x0}, __s = {{__size_ = 8 '\b', __lx = 8 L'\b\000\000\000'},
__data_ = L'\000' repeats 16 times}, __r =
{__words = {8, 0, 0}, No data fields}, static npos =
18446744073709551615}, __hm_ = 0x7fffbb2c L, __mode_ = 16}}}
#8 0x0064c798 in RTImage::setPaths (opt=...) at
/usr/ports/graphics/rawtherapee/work/rawtherapee-4.0.12/rtgui/rtimage.cc:101
configFilename = {static npos = 18446744073709551615, string_ =
{std::__1::__basic_string_commontrue = {No data fields},
__r_ =
{std::__1::__libcpp_compressed_pair_impstd::__1::basic_stringchar,
std::__1::char_traitschar, std::__1::allocatorchar ::__rep,
std::__1::allocatorchar, 2u = {std::__1::allocatorchar = {No
data fields}, __first_ = {{__l = {__cap_ = 0, __size_ = 0, __data_ =
0x0}, __s = {{__size_ = 0 '\000', __lx = 0 '\000'}, __data_ = '\000'
repeats 22 times}, __r = {__words = {0,
0, 0}, No data fields}, static npos =
18446744073709551615}}
keyFile = {Glib::KeyFile = {gobject_ = 0x4ec15d80,
owns_gobject_ = true}, No data fields}
hasKeyFile = true
#9 0x00696aaf in main (argc=1, argv=0x7fffd6d0) at
/usr/ports/graphics/rawtherapee/work/rawtherapee-4.0.12/rtgui/main.cc:239
m = incomplete type
icon_path = {static npos = 18446744073709551615, string_ =
{std::__1::__basic_string_commontrue = {No data fields},
__r_ =
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
Am 05.02.2014 23:02, schrieb Julian H. Stacey: Matthew Seaman wrote: On 03/02/2014 21:24, Julian H. Stacey wrote: be beneficial in a very short amount of time. Even if you prefer to compile from source, =20 I use source, rarely if ever use packages, (except pkg_delete to remove old broken dependencies). No opinion which scrips are better.= =20 =20 you will still reap the benefits of the modern packaging system. =20 In 10.0 FreeBSD `reaped the benefit` of a default new horrible registry that smells like Microsoft with quasi binary local.sqlite needing special tools. (Yes I know there's an export function.) =20 For 2 decade we've poured scorn on Microsoft its opaque easily damaged hard to access registry, lauded how with FreeBSD we can examine manipulate repair our text based equivalent with any number of personal choice text tools, now FreeSBD is burdened by this horrible Microsoft style registry. You're being absurd. Immediately personal criticism is a poor way to start convincing. ports/ is not just for package addicts. I never install packages, but only build install from ports/. sqlite junk obstructs /var/db/pkg being accessed by find grep to debug breaking ports builds. While I have wanted a few of the pkg options to be 100% compatible with the pkg_info options, I never felt the need to dig around in the package system innards other than to debug goofups that originated in the package system itself. Especially not to debug breaking port builds. portmaster has made things quite easy when dealing with source builds. ___ 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: r341435: deletion of graphics/fotoxx
Am 05.02.2014 21:39, schrieb Rainer Hurling: Thanks for answering. I attached the patch to PR ports/177643 with some info around it. Please also add your changes to files/ (add the -r to diff next time) to the PR so I can tackle it. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Wed, Feb 5, 2014 at 2:52 PM, Matthias Andree matthias.and...@gmx.dewrote: Am 05.02.2014 23:02, schrieb Julian H. Stacey: Matthew Seaman wrote: On 03/02/2014 21:24, Julian H. Stacey wrote: be beneficial in a very short amount of time. Even if you prefer to compile from source, =20 I use source, rarely if ever use packages, (except pkg_delete to remove old broken dependencies). No opinion which scrips are better.= =20 =20 you will still reap the benefits of the modern packaging system. =20 In 10.0 FreeBSD `reaped the benefit` of a default new horrible registry that smells like Microsoft with quasi binary local.sqlite needing special tools. (Yes I know there's an export function.) =20 For 2 decade we've poured scorn on Microsoft its opaque easily damaged hard to access registry, lauded how with FreeBSD we can examine manipulate repair our text based equivalent with any number of personal choice text tools, now FreeSBD is burdened by this horrible Microsoft style registry. You're being absurd. Immediately personal criticism is a poor way to start convincing. ports/ is not just for package addicts. I never install packages, but only build install from ports/. sqlite junk obstructs /var/db/pkg being accessed by find grep to debug breaking ports builds. While I have wanted a few of the pkg options to be 100% compatible with the pkg_info options, I never felt the need to dig around in the package system innards other than to debug goofups that originated in the package system itself. Especially not to debug breaking port builds. portmaster has made things quite easy when dealing with source builds. While I think this discussion is getting a bit emotional, I would like to point out a few things that some posters may not know. 1. The ports/packages system is not total crap. In fact, at the time jkh started it, it was far superior to any tool available. 2. sqlite and mysql were not available at the time it was written. If there had been a solid, properly licensed RDBMS, I strongly suspect it would have been used. 3. While the system has evolved a great deal since it came to FreeBSD about 20 years ago (just a rough guess), it was really in need of an overhaul. Anyone who has used apt knows just how creaky is has become. (Not that I am crazy about apt. I find that it has some very unpleasant issues. I think pkgng is clearly superior.) 4. I will also miss the ASCII pkgdb. I will either live without it or write a small script to pull the relevant data out of the db and create a limited db that contains the data I need for my scripts that it. (I would only need to fill in a few fields and most scripts can be placed by pkg commands which are very flexible and powerful. pkg does a LOT more than the old pkg_ system. Of course, you will have to actually read limited documentation and the pkg help. (Far more complete than the last time I looked at the documentation.) I have long advocated for using the simplest, lowest overhead DB that will o the job and use flat ASCII DBs often. Too many developers seem to think that Oracle or is always the right answer for any DB and I'm sure Larry agrees. but really doing the ports/packages system write simply goes beyond what an ASCII DB is suited for. sqlite look like a very good fit for the job. 5. The introduction of pkgng could have really been handled better and that probably increased the negative feelings about it. It was also a bit before it was really ready. It still lacks a few features I feel are quite important, but they were also missing from the old system. On the whole, bapt and company have done a remarkable job that was really needed. It goes way beyond what any other package system I have seen can do. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: databases/mysql56-client build failure on 9.2-STABLE i386
On Wed, 5 Feb 2014, Alex Dupre wrote: Unable to reproduce, it builds fine also on my 9.2-i386 poudriere jail. Thanks for checking Alex, I must have a local issue then. I'll dig harder. On Wed, 5 Feb 2014, Dewayne Geraghty wrote: I too have built mysql-client using portmaster on an i386 machine, see -rw-r--r-- 1 root wheel11M Feb 3 13:14 /usr/packages/PRESCOTT/All/mysql56-client-5.6.16.tbz I've discovered that on a particularly busy build server, I've had to sprinkly MAKE_JOBS_UNSAFE=yes for 18 of the 135 ports requiring customisation. I don't think a PR is necessary, until you've used what the Makefile recommends. Thanks for your suggestion Dewayne. But I get the same result with or without MAKE_JOBS_UNSAFE=yes. -- 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
Re: r341435: deletion of graphics/fotoxx
Am 05.02.2014 23:55 (UTC+1) schrieb Matthias Andree: Am 05.02.2014 21:39, schrieb Rainer Hurling: Thanks for answering. I attached the patch to PR ports/177643 with some info around it. Please also add your changes to files/ (add the -r to diff next time) to the PR so I can tackle it. Should be done now. Sorry for this. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin: On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote: Am 05.02.2014 21:08, schrieb Dimitry Andric: #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 Hmm, is this a ports version of libc++? I was not aware Baptiste had already committed this? :) Yes, it is (as a build requisite, but apparently remained installed on the destination machine), because we need to match the libraries that the requisites use (Glibmm for one). I have given up on compiling RawTherapee with clang++ for now, and use GCC 4.8 on all systems. RawTherapee is somewhat demanding, especially at higher optimization level, and kills the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with internal compiler errors. Since GCC 4.8 worked for me, I did not bother to send Gerald the details. We may want to retry with clang if we've got the next clang version. Feel free to use Rawtherapee as compiler system test ;) try with something like this in libmap.conf libc++.so.1 /usr/local/lib/libc++.so.1 If that fixes the problem, then a rpath with /usr/local/lib should be set while building the port Hmm, I am not very familiar with libmapping. After adding it to /etc/libmap.conf I get #rawtherapee Shared object /usr/local/lib/libc++.so.1 not found, required by rawtherapee Thanks for the tip, Rainer regards, Bapt ___ 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-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 05/02/2014 23:57, Kevin Oberman wrote: 1. The ports/packages system is not total crap. In fact, at the time jkh started it, it was far superior to any tool available. When I first encountered the ports, way back in 1998 or so, I was completely mind-blown that something so fantastic could exist. Yes, it was revolutionary at the time and right where FreeBSD should be -- leading the rest of the world with great innovations. However, things have changed in the last 16 years. Development of the ports as a global concept has been resting on its laurels a bit, and the rest of the world has caught up, and indeed overtaken. Partly that was due to the mindset of seeing binary packages as a second-class thing; partly due to the old pkg_tools not providing the scope to implement innovative features; partly due to pkg_tools being part of the FreeBSD base, so impossible to update over reasonable timescales due to the requirement to support older RELEASE branches. pkg(8) addresses those problems, and I hope will do so for at least the next decade. 5. The introduction of pkgng could have really been handled better and that probably increased the negative feelings about it. It was also a bit before it was really ready. It still lacks a few features I feel are quite important, but they were also missing from the old system. I don't think it's possible to make a change of this magnitude without upsetting anyone. We have been getting a lot of feedack on the lines of 'Wow! This is great. When can we have feature XYZ?' to which we frequently have to reply that XYZ can't be implemented without breaking compatibility with pkg_tools. Like sub-packages. I'd be interested to hear what features you think are missing. We will implement anything (eventually...) that there is demand for and that is technically feasible, and that fits with the overall concept of what we think a packaging system should do. There's a number of ideas in the github issue list already (usually tagged with 'longterm' or 'thinking') and we are happy for people to add to that, or to discuss ideas -- the freebsd-pkg@ list is a good place for that. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matt...@infracaninophile.co.uk signature.asc Description: OpenPGP digital signature
Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 06.02.2014 07:03 (UTC+1) schrieb Rainer Hurling: Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin: On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote: Am 05.02.2014 21:08, schrieb Dimitry Andric: #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 Hmm, is this a ports version of libc++? I was not aware Baptiste had already committed this? :) Yes, it is (as a build requisite, but apparently remained installed on the destination machine), because we need to match the libraries that the requisites use (Glibmm for one). I have given up on compiling RawTherapee with clang++ for now, and use GCC 4.8 on all systems. RawTherapee is somewhat demanding, especially at higher optimization level, and kills the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with internal compiler errors. Since GCC 4.8 worked for me, I did not bother to send Gerald the details. We may want to retry with clang if we've got the next clang version. Feel free to use Rawtherapee as compiler system test ;) try with something like this in libmap.conf libc++.so.1 /usr/local/lib/libc++.so.1 If that fixes the problem, then a rpath with /usr/local/lib should be set while building the port Hmm, I am not very familiar with libmapping. After adding it to /etc/libmap.conf I get #rawtherapee Shared object /usr/local/lib/libc++.so.1 not found, required by rawtherapee I just recognized, that in my CURRENT boxes in base their are two versions of libc++: #ll /usr/lib/libc++.so* -r--r--r-- 1 root wheel -134 3 Aug 22:33:00 2013 /usr/lib/libc++.so -r--r--r-- 1 root wheel - 768248 4 Feb 18:08:00 2014 /usr/lib/libc++.so.1 Shouldn't libc++.so be a link to libc++.so.1 or at least also come from the newest built? Thanks for the tip, Rainer regards, Bapt ___ 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: graphics/rawtherapee: r342622 crashes on HEAD
On 06 Feb 2014, at 07:48, Rainer Hurling rhur...@gwdg.de wrote: ... I just recognized, that in my CURRENT boxes in base their are two versions of libc++: #ll /usr/lib/libc++.so* -r--r--r-- 1 root wheel -134 3 Aug 22:33:00 2013 /usr/lib/libc++.so -r--r--r-- 1 root wheel - 768248 4 Feb 18:08:00 2014 /usr/lib/libc++.so.1 Shouldn't libc++.so be a link to libc++.so.1 or at least also come from the newest built? No, libc++.so is a linker script, similar to libc.so: $ cat /usr/lib/libc++.so /* $FreeBSD: head/lib/libc++/libc++.ldscript 253917 2013-08-03 16:23:43Z dim $ */ GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so ) -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Wed, Feb 5, 2014 at 10:45 PM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 05/02/2014 23:57, Kevin Oberman wrote: 1. The ports/packages system is not total crap. In fact, at the time jkh started it, it was far superior to any tool available. When I first encountered the ports, way back in 1998 or so, I was completely mind-blown that something so fantastic could exist. Yes, it was revolutionary at the time and right where FreeBSD should be -- leading the rest of the world with great innovations. However, things have changed in the last 16 years. Development of the ports as a global concept has been resting on its laurels a bit, and the rest of the world has caught up, and indeed overtaken. Partly that was due to the mindset of seeing binary packages as a second-class thing; partly due to the old pkg_tools not providing the scope to implement innovative features; partly due to pkg_tools being part of the FreeBSD base, so impossible to update over reasonable timescales due to the requirement to support older RELEASE branches. pkg(8) addresses those problems, and I hope will do so for at least the next decade. 5. The introduction of pkgng could have really been handled better and that probably increased the negative feelings about it. It was also a bit before it was really ready. It still lacks a few features I feel are quite important, but they were also missing from the old system. I don't think it's possible to make a change of this magnitude without upsetting anyone. We have been getting a lot of feedack on the lines of 'Wow! This is great. When can we have feature XYZ?' to which we frequently have to reply that XYZ can't be implemented without breaking compatibility with pkg_tools. Like sub-packages. I'd be interested to hear what features you think are missing. We will implement anything (eventually...) that there is demand for and that is technically feasible, and that fits with the overall concept of what we think a packaging system should do. There's a number of ideas in the github issue list already (usually tagged with 'longterm' or 'thinking') and we are happy for people to add to that, or to discuss ideas -- the freebsd-pkg@ list is a good place for that. One BIG one that I know is being worked is the capability to mix packages and ports effectively. If you use poudriere, you can roll your own packages with custom options and maintain things pretty reasonably, but for a single system (or two), this is a bit of overkill. As things stand, this is a real pain to use customized ports and packages from the standard FreeBSD distributions. I'm waiting with great excitement for this to appear, though I have no idea if it is near or far. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/rawtherapee: r342622 crashes on HEAD
On Thu, Feb 06, 2014 at 07:03:22AM +0100, Rainer Hurling wrote: Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin: On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote: Am 05.02.2014 21:08, schrieb Dimitry Andric: #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 Hmm, is this a ports version of libc++? I was not aware Baptiste had already committed this? :) Yes, it is (as a build requisite, but apparently remained installed on the destination machine), because we need to match the libraries that the requisites use (Glibmm for one). I have given up on compiling RawTherapee with clang++ for now, and use GCC 4.8 on all systems. RawTherapee is somewhat demanding, especially at higher optimization level, and kills the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with internal compiler errors. Since GCC 4.8 worked for me, I did not bother to send Gerald the details. We may want to retry with clang if we've got the next clang version. Feel free to use Rawtherapee as compiler system test ;) try with something like this in libmap.conf libc++.so.1 /usr/local/lib/libc++.so.1 If that fixes the problem, then a rpath with /usr/local/lib should be set while building the port Hmm, I am not very familiar with libmapping. After adding it to /etc/libmap.conf I get #rawtherapee Shared object /usr/local/lib/libc++.so.1 not found, required by rawtherapee Thanks for the tip, Rainer regards, Bapt try reinstalling devel/libc++ and keeping the libmap.conf entry, that should do the trick as it was a build only dep it may have been removed. just remove the line from libmap.conf before reinstalling devel/libc++ and readd it once it is installed. Bapt pgpPWuUeEwfNP.pgp Description: PGP signature
[SOLVED] databases/mysql56-client build failure on 9.2-STABLE i386
I isolated the problem to a single line in /etc/make.conf: CPUTYPE?=prescott Unsetting CPUTYPE allows mysql56-client to build successfully. mysql56-server also fails to build when CPUTYPE is set. No other ports installed on this host are adversely affected. FWIW, previous versions of mysql56 built fine with CPUTYPE set. -- Greg Rivers ___ 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
