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 +-+ mail/milter-manager | 2.0.4 | 2.0.5 +-+ misc/floatator | 0.2.1 | 0.7.0 +-+ www/pound | 2.6 | 2.7e +-+ 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
Re: www/webkit-gtk3 build broken on FreeBSD 8.4 and general c++ library conflicts
On 3 Dec, Don Lewis wrote: When attempting to build webkit-gtk3 on FreeBSD 8.4, it fails like this: CXXLDPrograms/LLIntOffsetsExtractor /usr/local/lib/libc++.so.1: undefined reference to `iswalpha_l' /usr/local/lib/libc++.so.1: undefined reference to `wctob_l' /usr/local/lib/libc++.so.1: undefined reference to `snprintf_l' /usr/local/lib/libc++.so.1: undefined reference to `iswprint_l' /usr/local/lib/libc++.so.1: undefined reference to `iswlower_l' /usr/local/lib/libc++.so.1: undefined reference to `mbrtowc_l' /usr/local/lib/libc++.so.1: undefined reference to `towlower_l' /usr/local/lib/libc++.so.1: undefined reference to `mbsrtowcs_l' /usr/local/lib/libc++.so.1: undefined reference to `tolower_l' /usr/local/lib/libc++.so.1: undefined reference to `iswxdigit_l' /usr/local/lib/libc++.so.1: undefined reference to `strxfrm_l' /usr/local/lib/libc++.so.1: undefined reference to `strftime_l' /usr/local/lib/libc++.so.1: undefined reference to `toupper_l' /usr/local/lib/libc++.so.1: undefined reference to `isxdigit_l' /usr/local/lib/libc++.so.1: undefined reference to `wcsxfrm_l' /usr/local/lib/libc++.so.1: undefined reference to `__mb_cur_max_l' /usr/local/lib/libc++.so.1: undefined reference to `newlocale' /usr/local/lib/libc++.so.1: undefined reference to `iswdigit_l' /usr/local/lib/libc++.so.1: undefined reference to `iswctype_l' /usr/local/lib/libc++.so.1: undefined reference to `mbrlen_l' /usr/local/lib/libc++.so.1: undefined reference to `btowc_l' /usr/local/lib/libc++.so.1: undefined reference to `wcrtomb_l' /usr/local/lib/libc++.so.1: undefined reference to `mbsnrtowcs_l' /usr/local/lib/libc++.so.1: undefined reference to `iswcntrl_l' /usr/local/lib/libc++.so.1: undefined reference to `localeconv_l' /usr/local/lib/libc++.so.1: undefined reference to `asprintf_l' /usr/local/lib/libc++.so.1: undefined reference to `mbtowc_l' /usr/local/lib/libc++.so.1: undefined reference to `strcoll_l' /usr/local/lib/libc++.so.1: undefined reference to `iswpunct_l' /usr/local/lib/libc++.so.1: undefined reference to `iswspace_l' /usr/local/lib/libc++.so.1: undefined reference to `towupper_l' /usr/local/lib/libc++.so.1: undefined reference to `iswupper_l' /usr/local/lib/libc++.so.1: undefined reference to `wcsnrtombs_l' /usr/local/lib/libc++.so.1: undefined reference to `freelocale' /usr/local/lib/libc++.so.1: undefined reference to `isdigit_l' /usr/local/lib/libc++.so.1: undefined reference to `wcscoll_l' /usr/local/lib/libc++.so.1: undefined reference to `sscanf_l' clang: error: linker command failed with exit code 1 (use -v to see invocation) GNUmakefile:40531: recipe for target 'Programs/LLIntOffsetsExtractor' failed gmake: *** [Programs/LLIntOffsetsExtractor] Error 1 *** Error code 1 Stop in /usr/ports/www/webkit-gtk3. which indicates that trying to use the ports version of libc++ is now pretty much a lost cause on FreeBSD 8.4. The webkit-gtk3 port tests OSVERSION and forces the use of clang and libc++ from ports if it thinks that the system doesn't have clang in base (and gets it wrong on newer systems that are configured to build base with gcc instead of clang). The Makefile hackery for this has the following comment: # We need clang + libc++ or gcc 4.7+. gcc has libstdc++ conflict between # gcc port and base. This originates from icu I'm assuming that this is supposed to mean that gcc 4.7+ won't work because it will drag in the matching version of libstdc++ from the gcc port, which will conflict with the version of libstdc++ from base that icu is linked against, because icu is always built with the compiler from base. If so, I don't see how this could possibly work by using clang and libc++ from ports because any binary that gets linked to both libc++ and libstdc++ is pretty much guaranteed to croak when executed. It seems to be that webkit-gtk3 needs to be compiled with gcc 4.7+, at least on FreeBSD 8.4. Clang might be another a possibility on FreeBSD 9.x if its libc has the necessary symbols. To avoid the c++ library conflict, icu needs to be compiled with the same compiler and c++ library as webkit-gtk3. Any other ports that depend on either of these two ports will also need to use the same same compiler and c++ library *and* any c++ dependencies of these ports will also need to do the same, and so forth. Maybe the cleanest thing to do is avoid using c++ (GCC) 4.2.1 when building any (nontrivial?) ports and force the use of a compiler from ports instead. It looks like my suspicion is correct about consumers of webkit-gtk3 getting liked with both c++ libraries is correct. I ran and interactive poudriere testport -o devel/seed with a 9.3-RELEASE jail and got the following list of shared libraries being used by the seed executable in the jail: # ldd /usr/local/bin/seed /usr/local/bin/seed: libgthread-2.0.so.0 = /usr/local/lib/libgthread-2.0.so.0 (0x80081b000) libglib-2.0.so.0 =
Re: misc/mc pending bugfix to #194627 and no maintainer to apply it
Hi! There is a broken patch in the misc/mc port named patch-lib__tty__win.c. Committed. -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
pkg fails on assertion
Hello I have problem with pkg during packages update #pkg --version 1.4.0.beta2 #pkg upgrade Updating pcbsd-major repository catalogue... pcbsd-major repository is up-to-date. Updating pcbsd-sysrel repository catalogue... pcbsd-sysrel repository is up-to-date. All repositories are up-to-date. Checking for upgrades (1355 candidates)... done Processing candidates (1355 candidates)... done Checking integrity...Assertion failed: (pkgdb_ensure_loaded(j-db, p2, PKG_LOAD_FILES|PKG_LOAD_DIRS) == EPKG_OK), function pkg_conflicts_need_conflict, file pkg_jobs_conflicts.c, line 211. Child process pid=66300 terminated abnormally: Abort trap OS is FreeBSD (PC-BSD) 10.1 Packages was downloaded previously (about 1Gb, many packages). If you need to see something else please let me know. -- Best regards, Yuri Momotyuk ___ 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: Tomcat7: Unable to stop process (unlike tomcat6)
After i slept on this I remembered the rc.d system offers a force
option.
root@illidan.local:~# /usr/local/etc/rc.d/tomcat7 forcestop, seems to
work.
Thanks.
On 2014-12-08 06:09 PM, Mike Jakubik wrote:
Hello,
I've Noticed that the rc.d script for tomcat7 has changed from version
6. In tomcat6 a function called tomcat_stop() would force kill after a
certain timeout, this no longer happens in tomcat7 and sometimes we
are unable to stop it using the rc.d script, it just sits there
waiting for PID.
In tomcat6 we had:
tomcat_stop() {
rc_pid=$(tomcat_check_pidfile $pidfile)
if [ -z $rc_pid ]; then
[ -n $rc_fast ] return 0
echo ${name} not running? (check $pidfile).
return 1
fi
echo Stopping ${name}.
${java_command} stop
tomcat_wait_max_for_pid
${tomcat%%TOMCAT_VERSION%%_stop_timeout} ${rc_pid}
kill -KILL ${rc_pid} 2 /dev/null echo Killed.
rm -f ${pidfile}
}
This function is no longer available in the version 7 rc.d script, is
there any way it can be modified to function like in version 6?
Thank you.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to
freebsd-ports-unsubscr...@freebsd.org
___
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
Next Perl update, and plans beyond…
Hello there, In a few days, I'll be changing the way Perl works wrt compiled modules it produces. The current patch[1] is on our code review tool. Right now, we have: $ readelf -d /usr/local/lib/perl5/5.18/mach/CORE/libperl.so|grep SONAME 0x000e (SONAME) Library soname: [libperl.so.5.18] $ That is, libperl.so has a name, and it is versionned, and the version will change if you have 5.16 or 5.20. If your libperl.so does not have a SONAME, you don't have an up-to-date Perl. Which is good, because if some app is linked with libperl.so, it has: # readelf -d /usr/local/bin/vim|grep perl 0x0001 (NEEDED) Shared library: [libperl.so.5.18] 0x000f (RPATH) Library rpath: [/usr/local/lib:/usr/local/lib/perl5/5.18/mach/CORE] 0x001d (RUNPATH)Library runpath: [/usr/local/lib:/usr/local/lib/perl5/5.18/mach/CORE] So if you change your Perl version, pkg will know it has to upgrade vim too because a NEEDED shlib changed. Now, for Perl modules, it's not like that, it reads like this: $ readelf -d /usr/local/lib/perl5/site_perl/mach/5.18/auto/DateTime/DateTime.so|grep perl $ So what the patch[1] does, is force linking with libperl.so.x.yy. After the patch, a compiled Perl module will look like this: $ readelf -d /usr/local/lib/perl5/site_perl/mach/5.18/auto/DateTime/DateTime.so | grep perl 0x0001 (NEEDED) Shared library: [libperl.so.5.18] 0x000f (RPATH) Library rpath: [/usr/local/lib/perl5/5.18/mach/CORE] 0x001d (RUNPATH)Library runpath: [/usr/local/lib/perl5/5.18/mach/CORE] $ So pkg will detect it needs to be reinstalled when the Perl version change. As for the plans beyond that I was talking about in the subject, there will be a Perl 5.22 released next May, (and 5.24 the May after that,) when that happens, I'll change the default Perl to be 5.20, and deprecate 5.18 which won't, then, be supported. Sometime at the end of the summer, like sometime September, I'll change the default Perl to 5.22 and try to keep it that way, that is, a new Perl goes in in May, and gets to be the default in September. 1: https://reviews.freebsd.org/D1241 -- Mathieu Arnold pgpP731b6yU9P.pgp Description: PGP signature
Re: Next Perl update, and plans beyo nd…
On Tue, 9 Dec 2014 17:30:39 +0100 Mathieu Arnold m...@freebsd.org wrote Hello there, In a few days, I'll be changing the way Perl works wrt compiled modules it produces. The current patch[1] is on our code review tool. Right now, we have: $ readelf -d /usr/local/lib/perl5/5.18/mach/CORE/libperl.so|grep SONAME 0x000e (SONAME) Library soname: [libperl.so.5.18] $ That is, libperl.so has a name, and it is versionned, and the version will change if you have 5.16 or 5.20. If your libperl.so does not have a SONAME, you don't have an up-to-date Perl. Which is good, because if some app is linked with libperl.so, it has: # readelf -d /usr/local/bin/vim|grep perl 0x0001 (NEEDED) Shared library: [libperl.so.5.18] 0x000f (RPATH) Library rpath: [/usr/local/lib:/usr/local/lib/perl5/5.18/mach/CORE] 0x001d (RUNPATH)Library runpath: [/usr/local/lib:/usr/local/lib/perl5/5.18/mach/CORE] So if you change your Perl version, pkg will know it has to upgrade vim too because a NEEDED shlib changed. Now, for Perl modules, it's not like that, it reads like this: $ readelf -d /usr/local/lib/perl5/site_perl/mach/5.18/auto/DateTime/DateTime.so|grep perl $ So what the patch[1] does, is force linking with libperl.so.x.yy. After the patch, a compiled Perl module will look like this: $ readelf -d /usr/local/lib/perl5/site_perl/mach/5.18/auto/DateTime/DateTime.so | grep perl 0x0001 (NEEDED) Shared library: [libperl.so.5.18] 0x000f (RPATH) Library rpath: [/usr/local/lib/perl5/5.18/mach/CORE] 0x001d (RUNPATH) Library runpath: [/usr/local/lib/perl5/5.18/mach/CORE] $ Apologies if I seem a bit obtuse. But as I read this, it appears that Perl modules go from being text based (DateTime.pm) to becoming compiled? I *must* be missing something obvious. --Chris So pkg will detect it needs to be reinstalled when the Perl version change. As for the plans beyond that I was talking about in the subject, there will be a Perl 5.22 released next May, (and 5.24 the May after that,) when that happens, I'll change the default Perl to be 5.20, and deprecate 5.18 which won't, then, be supported. Sometime at the end of the summer, like sometime September, I'll change the default Perl to 5.22 and try to keep it that way, that is, a new Perl goes in in May, and gets to be the default in September. 1: https://reviews.freebsd.org/D1241 -- Mathieu Arnold ___ 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: Tomcat7: Unable to stop process (unlike tomcat6)
Unfortunately after actually trying this, it does not work, forcestop or
faststop does absolutely nothing different than stop. Shouldnt these
options be properly utilized? It seems to me that the rc.d script for
tomcat7 is a step backwards from tomcat6.
Thanks.
On 2014-12-09 09:50 AM, Mike Jakubik wrote:
After i slept on this I remembered the rc.d system offers a force
option.
root@illidan.local:~# /usr/local/etc/rc.d/tomcat7 forcestop, seems to
work.
Thanks.
On 2014-12-08 06:09 PM, Mike Jakubik wrote:
Hello,
I've Noticed that the rc.d script for tomcat7 has changed from version
6. In tomcat6 a function called tomcat_stop() would force kill after a
certain timeout, this no longer happens in tomcat7 and sometimes we
are unable to stop it using the rc.d script, it just sits there
waiting for PID.
In tomcat6 we had:
tomcat_stop() {
rc_pid=$(tomcat_check_pidfile $pidfile)
if [ -z $rc_pid ]; then
[ -n $rc_fast ] return 0
echo ${name} not running? (check $pidfile).
return 1
fi
echo Stopping ${name}.
${java_command} stop
tomcat_wait_max_for_pid
${tomcat%%TOMCAT_VERSION%%_stop_timeout} ${rc_pid}
kill -KILL ${rc_pid} 2 /dev/null echo Killed.
rm -f ${pidfile}
}
This function is no longer available in the version 7 rc.d script, is
there any way it can be modified to function like in version 6?
Thank you.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to
freebsd-ports-unsubscr...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to
freebsd-ports-unsubscr...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Tomcat7: Unable to stop process (unlike tomcat6)
Hi! Unfortunately after actually trying this, it does not work, forcestop or faststop does absolutely nothing different than stop. Shouldnt these options be properly utilized? It seems to me that the rc.d script for tomcat7 is a step backwards from tomcat6. Can you generate a problem report via bugzilla, so that someone can look into this ? -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ 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: Next Perl update, and plans beyo nd…
+--On 9 décembre 2014 08:53:13 -0800 Chris H bsd-li...@bsdforge.com wrote: | $ readelf -d | /usr/local/lib/perl5/site_perl/mach/5.18/auto/DateTime/DateTime.so|grep | perl $ | | So what the patch[1] does, is force linking with libperl.so.x.yy. After | the patch, a compiled Perl module will look like this: | | $ readelf -d | /usr/local/lib/perl5/site_perl/mach/5.18/auto/DateTime/DateTime.so | grep | perl 0x0001 (NEEDED) Shared library: | [libperl.so.5.18] 0x000f (RPATH) Library rpath: | [/usr/local/lib/perl5/5.18/mach/CORE] 0x001d (RUNPATH) | Library runpath: [/usr/local/lib/perl5/5.18/mach/CORE] $ | Apologies if I seem a bit obtuse. But as I read this, it appears | that Perl modules go from being text based (DateTime.pm) to becoming | compiled? | I *must* be missing something obvious. Huhu, yes, DateTime.so is already compiled: $ readelf -d /usr/local/lib/perl5/site_perl/mach/5.18/auto/DateTime/DateTime.so Dynamic section at offset 0x3d70 contains 21 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libc.so.7] 0x000c (INIT) 0x958 0x000d (FINI) 0x3878 0x0004 (HASH) 0x158 0x6ef5 (GNU_HASH) 0x218 0x0005 (STRTAB) 0x518 0x0006 (SYMTAB) 0x260 0x000a (STRSZ) 446 (bytes) 0x000b (SYMENT) 24 (bytes) 0x0003 (PLTGOT) 0x203f28 0x0002 (PLTRELSZ) 384 (bytes) 0x0014 (PLTREL) REAL 0x0017 (JMPREL) 0x7d8 0x0007 (REAL) 0x730 0x0008 (RELASZ) 168 (bytes) 0x0009 (RELAENT)24 (bytes) 0x6ffe (VERNEED)0x710 0x6fff (VERNEEDNUM) 1 0x6ff0 (VERSYM) 0x6d6 0x6ff9 (RELACOUNT) 2 0x (NULL) 0x0 But it's not linked with libperl.so right now. -- Mathieu Arnold ___ 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: Re: Next Perl update, and plans beyo nd…
On Tue, 09 Dec 2014 18:02:23 +0100 Mathieu Arnold m...@freebsd.org wrote +--On 9 décembre 2014 08:53:13 -0800 Chris H bsd-li...@bsdforge.com wrote: | $ readelf -d | /usr/local/lib/perl5/site_perl/mach/5.18/auto/DateTime/DateTime.so|grep | perl $ | | So what the patch[1] does, is force linking with libperl.so.x.yy. After | the patch, a compiled Perl module will look like this: | | $ readelf -d | /usr/local/lib/perl5/site_perl/mach/5.18/auto/DateTime/DateTime.so | grep | perl 0x0001 (NEEDED) Shared library: | [libperl.so.5.18] 0x000f (RPATH) Library rpath: | [/usr/local/lib/perl5/5.18/mach/CORE] 0x001d (RUNPATH) | Library runpath: [/usr/local/lib/perl5/5.18/mach/CORE] $ | Apologies if I seem a bit obtuse. But as I read this, it appears | that Perl modules go from being text based (DateTime.pm) to becoming | compiled? | I *must* be missing something obvious. Huhu, yes, DateTime.so is already compiled: $ readelf -d /usr/local/lib/perl5/site_perl/mach/5.18/auto/DateTime/DateTime.so Dynamic section at offset 0x3d70 contains 21 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libc.so.7] 0x000c (INIT) 0x958 0x000d (FINI) 0x3878 0x0004 (HASH) 0x158 0x6ef5 (GNU_HASH) 0x218 0x0005 (STRTAB) 0x518 0x0006 (SYMTAB) 0x260 0x000a (STRSZ) 446 (bytes) 0x000b (SYMENT) 24 (bytes) 0x0003 (PLTGOT) 0x203f28 0x0002 (PLTRELSZ) 384 (bytes) 0x0014 (PLTREL) REAL 0x0017 (JMPREL) 0x7d8 0x0007 (REAL) 0x730 0x0008 (RELASZ) 168 (bytes) 0x0009 (RELAENT)24 (bytes) 0x6ffe (VERNEED)0x710 0x6fff (VERNEEDNUM) 1 0x6ff0 (VERSYM) 0x6d6 0x6ff9 (RELACOUNT) 2 0x (NULL) 0x0 But it's not linked with libperl.so right now. Ugh. Sorry. I *clearly* didn't think it through. I didn't examine the paths close enough. Of *course* the libs are there. Again, sorry, and thank you very much for taking the time to reply. --Chris -- Mathieu Arnold ___ 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
[HEADS UP] CentOS 6.6 is now the default Linux base.
Since ports revision 374417, the FreeBSD portstree defaults to CentOS 6.6 for purposes of Linux emulation. Fedora 10 has served well in the last five years, but long since gone End of Life upstream. The CentOS 6 series will be supported until November 2020, this should give us enough time to keep its point releases up to date. I've added an entry to today's UPDATING that documents how to change to CentOS 6.6 if you have not done that yet, as well as how to keep using Fedora 10. Please report any issues encountered in the process via Bugzilla and to the emulation@ mailing list. Best regards, -xmj -- Johannes Meixner| FreeBSD Committer x...@freebsd.org| http://people.freebsd.org/~xmj pgpHypU3JrDs4.pgp Description: PGP signature
The futuire of 'interpreter-based threads' in perl
Mathieu Arnold wrote in another thread: Next Perl update, and plans beyond... As for the plans beyond that I was talking about in the subject, there will be a Perl 5.22 released next May, (and 5.24 the May after that,) when that happens, I'll change the default Perl to be 5.20, and deprecate 5.18 which won't, then, be supported. Sometime at the end of the summer, like sometime September, I'll change the default Perl to 5.22 and try to keep it that way, that is, a new Perl goes in in May, and gets to be the default in September. That reminds me of a question I have been brewing for some time now. As far as I can tell, all four lang/perl5.* ports have by default option THREADS (Build threaded perl) enabled by default. Don't remember when it became a default in ports, must have been at least a year ago. Which is very nice. I got accustomed to it, at our site we have developed a couple of in-house applications that make good use of perl ithreads. In some cases these interpreter threads save a lot of complexity (like managing a herd of cooperating processes, message passing queueing). The price is a potentially somewhat larger memory footprint (multiple interpreters) and a due care needed when one has to deal with shared variables, locks and queues. All in all, this feature can be very valuable. But now, just as we have started depending on it, the perl docs say (perl5200delta, ): Interpreter-based threads are now discouraged The interpreter-based threads provided by Perl are not the fast, lightweight system for multitasking that one might expect or hope for. Threads are implemented in a way that make them easy to misuse. Few people know how to use them correctly or will be able to provide help. The use of interpreter-based threads in perl is officially discouraged. I don't buy arguments 'makes them easy to misuse' and 'few people know how to use them correctly'. Yes, multithreading has its share if implications that require more careful design. But at the same time for certain near-real time applications it can be a very valuable tool. I wonder if FreeBSD has any say in this perl developers decision. And if not, what are the plans to keep compatibility with existing multithreaded applications without being locked down to some stale version of perl. Mark ___ 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
After Update today: No origin available for eigen~pkg-renamed~3FCF-3.2.2
On several CURRENT and 10.1-boxes with today's ports tree update, I run into a very strange problem with a non-responsive, non-updatable portstree, with errors like === Gathering distinfo list for installed ports === Starting check of installed ports for available updates === No origin available for eigen~pkg-renamed~3FCF-3.2.2 === Cannot continue === Aborting update This -renamed~3FCF-3.2.2 extension occurs on many ports and in UPDATING, there is no mark that should give me a hint ... pgpULK6SxSOvA.pgp Description: OpenPGP digital signature
Re: The futuire of 'interpreter-based threads' in perl
Hi! I wonder if FreeBSD has any say in this perl developers decision. Probably not much. Have you raised this issue on the relevant perl mailing lists ? And if not, what are the plans to keep compatibility with existing multithreaded applications without being locked down to some stale version of perl. In the long run, it will ask too much from the FreeBSD community to support a feature that the language developers themselves chose to no longer support. So please communicate the issue to the language developers. P.S.: I'm a perl guy, but your problem description looks like go might be a solution ? -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ 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: The futuire of 'interpreter-based threads' in perl
On Tue, 09 Dec 2014 21:03:04 +0100 Mark Martinec mark.martinec+free...@ijs.si wrote Mathieu Arnold wrote in another thread: Next Perl update, and plans beyond... As for the plans beyond that I was talking about in the subject, there will be a Perl 5.22 released next May, (and 5.24 the May after that,) when that happens, I'll change the default Perl to be 5.20, and deprecate 5.18 which won't, then, be supported. Sometime at the end of the summer, like sometime September, I'll change the default Perl to 5.22 and try to keep it that way, that is, a new Perl goes in in May, and gets to be the default in September. That reminds me of a question I have been brewing for some time now. As far as I can tell, all four lang/perl5.* ports have by default option THREADS (Build threaded perl) enabled by default. Don't remember when it became a default in ports, must have been at least a year ago. Which is very nice. I got accustomed to it, at our site we have developed a couple of in-house applications that make good use of perl ithreads. In some cases these interpreter threads save a lot of complexity (like managing a herd of cooperating processes, message passing queueing). The price is a potentially somewhat larger memory footprint (multiple interpreters) and a due care needed when one has to deal with shared variables, locks and queues. All in all, this feature can be very valuable. But now, just as we have started depending on it, the perl docs say (perl5200delta, ): Interpreter-based threads are now discouraged The interpreter-based threads provided by Perl are not the fast, lightweight system for multitasking that one might expect or hope for. Threads are implemented in a way that make them easy to misuse. Few people know how to use them correctly or will be able to provide help. The use of interpreter-based threads in perl is officially discouraged. I don't buy arguments 'makes them easy to misuse' and 'few people know how to use them correctly'. Yes, multithreading has its share if implications that require more careful design. But at the same time for certain near-real time applications it can be a very valuable tool. I wonder if FreeBSD has any say in this perl developers decision. And if not, what are the plans to keep compatibility with existing multithreaded applications without being locked down to some stale version of perl. I agree with Perl. In fact wheel manufacturers should take their lead; We are going to discontinue the creation, and distribution of wheels. We have found that it is far too easy for people to abuse wheels. They put them on cars, and hit other cars, or other people. They drink too much, and use them to drive around in cars with them... Don't you just *love* the Perl Police. C'mon already. This is just nonsense. They haven't made many friends in the past either. Many simply write modules to overcome such removals. In fact, I created Perl::Police, with the intention of it being a collection/collaboration effort to combine all of the silliness that comes out of such decisions to remove such valuable resources from Perl. It might be a bit trickier adding threads back in via a module. About the easiest way I can imagine, would be to create a module that requires everything from base, along with the addition of threads. But that ends up just being another Perl version/branch. So probably won't help here. But I couldn't help but chime in. I *sincerely* hope threads don't get removed. Thanks for the heads up, Mark. --Chris Mark ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Any tool known to demangle special chars in MS tree path names ?
Kevin Oberman wrote: On Mon, Dec 8, 2014 at 8:18 AM, Julian H. Stacey j...@berklix.com wrote: Hi ports@ Is there a utility in ports/ to automatically clean disgusting path names in big trees one acquires from Microsoft users ? Trees with in both directories filenames, masses of meta characters such as as ' ` . * | \ space ( accents high parity bit national extensions eg german umlauts) etc. It's known: tr exists, find has -X xargs has -0 One can delimit path names on command line, One could reinvent the wheel, writing improving a scarey shell script (that would probably break while debugging trash some data) But I'm looking for something better, that probably already exists, that will permanently clean trees, to no longer need to delimit various utilities against nasty names, each time tree is accessed. Either: An existing tool (preferably C) one can run automatically to forcibly rename dirs files in a Unix friendly manner ? Or if none exists I'll write a C program to run from find. If so, I'll probably just map nasty chars inc. any high bit parity (accents umlauts other noise) to eg 0xAB expansion. ( I dont care about national accents char sets. ) PS Assume files are big, copying not viable, rename/mv via link unlink best. Any tools (URLs) known ? Or should I write my own ? Cheers, Julian Around decade or so ago I was looking for a tool to clean up all of the Microsoft special characters in web pages. I found demoroniser, a public domain tool written by John Walker. As is, it does not meet your needs, but goes a long way in the right direction. It expects to work with files, not directory trees, but modifying to would be quite trivial, mostly wrapping it in a recursive loop that uses opendir, readdir, and closedir to walk the tree and feed it the directory names. (No, I am not volunteering.) Most notably, it is written in Perl, not C. Perl is now very of of fashion. In any case, it is available at: http://www.fourmilab.ch/webtools/demoroniser/ -- Kevin Oberman, Network Engineer, Retired Thanks Kevin, I re-read man tr, cludged 2 shells notes, which forced what I needed: http://www.berklix.com/~jhs/bin/.sh/tonoquotes Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with . Interleave reply paragraphs like a play script. 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
Re: The future of 'interpreter-based threads' in perl
MM I wonder if FreeBSD has any say in this perl developers decision. Kurt Jaeger wrote: Probably not much. Have you raised this issue on the relevant perl mailing lists ? I tried to subscribe to the perl5-porters mailing list ( http://lists.perl.org/list/perl5-porters.html ), twice. I do receive a confirmation request from a mailing list manager, to which I reply (or visit the provided customized link), but then nothing happens, it gets ignored. No idea why the ezmlm does not like my email address, despite it promptly sending a challenge/confirmation request there. ( yes I did check out mailer logs and content filter :) MM And if not, what are the plans to keep compatibility with existing MM multithreaded applications without being locked down to some MM stale version of perl. Kurt Jaeger wrote: In the long run, it will ask too much from the FreeBSD community to support a feature that the language developers themselves chose to no longer support. So please communicate the issue to the language developers. P.S.: I'm a perl guy, but your problem description looks like go might be a solution ? It it were a larger project, then yes, go is nice, or perhaps even erlang. But when one has most of the necessary infrastructure already comfortably developed/coded in perl, which just needs a bit of extra functionality in decoupling few relatively straightforward I/O and processing tasks, it's hard to justify adopting a new language and starting afresh. Perl has a well established stay in FreeBSD ports (even with a nice coexistence with CPAN), which young and/or more esoteric languages may lack. Mark 2014-12-09 Mark Martinec wrote: [...] That reminds me of a question I have been brewing for some time now. As far as I can tell, all four lang/perl5.* ports have by default option THREADS (Build threaded perl) enabled by default. Don't remember when it became a default in ports, must have been at least a year ago. Which is very nice. I got accustomed to it, at our site we have developed a couple of in-house applications that make good use of perl ithreads. In some cases these interpreter threads save a lot of complexity (like managing a herd of cooperating processes, message passing queueing). The price is a potentially somewhat larger memory footprint (multiple interpreters) and a due care needed when one has to deal with shared variables, locks and queues. All in all, this feature can be very valuable. But now, just as we have started depending on it, the perl docs say (perl5200delta, ): Interpreter-based threads are now discouraged The interpreter-based threads provided by Perl are not the fast, lightweight system for multitasking that one might expect or hope for. Threads are implemented in a way that make them easy to misuse. Few people know how to use them correctly or will be able to provide help. The use of interpreter-based threads in perl is officially discouraged. I don't buy arguments 'makes them easy to misuse' and 'few people know how to use them correctly'. Yes, multithreading has its share if implications that require more careful design. But at the same time for certain near-real time applications it can be a very valuable tool. I wonder if FreeBSD has any say in this perl developers decision. And if not, what are the plans to keep compatibility with existing multithreaded applications without being locked down to some stale version of perl. I agree with Perl. In fact wheel manufacturers should take their lead; We are going to discontinue the creation, and distribution of wheels. We have found that it is far too easy for people to abuse wheels. They put them on cars, and hit other cars, or other people. They drink too much, and use them to drive around in cars with them... 2014-12-09 21:41, Chris H wrote: Don't you just *love* the Perl Police. C'mon already. This is just nonsense. They haven't made many friends in the past either. Many simply write modules to overcome such removals. In fact, I created Perl::Police, with the intention of it being a collection/collaboration effort to combine all of the silliness that comes out of such decisions to remove such valuable resources from Perl. It might be a bit trickier adding threads back in via a module. About the easiest way I can imagine, would be to create a module that requires everything from base, along with the addition of threads. But that ends up just being another Perl version/branch. So probably won't help here. But I couldn't help but chime in. I *sincerely* hope threads don't get removed. Thanks for the heads up, Mark. --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
poudriere ports -u, divide by zero
I'm assuming this is just a superficial bug in the output. Possibly related: I have pkg-1.4.0 installed. # poudriere ports -u [00:00:00] Updating portstree default Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching snapshot tag from ec2-ap-southeast-2.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Updating from Wed Dec 10 09:57:21 AEDT 2014 to Wed Dec 10 11:26:11 AEDT 2014. Fetching 3 metadata patches.. done. Applying metadata patches... done. Fetching 0 metadata files... done. Fetching 0 patches. dc: divide by zero dc: divide by zero (0/0) 0.00% done. done. Applying patches... done. Fetching 0 new ports or files... done. Ports tree is already up to date. ___ 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: After Update today: No origin available for eigen~pkg-renamed~3FCF-3.2.2
On 09/12/2014 20:27, O. Hartmann wrote: On several CURRENT and 10.1-boxes with today's ports tree update, I run into a very strange problem with a non-responsive, non-updatable portstree, with errors like === Gathering distinfo list for installed ports === Starting check of installed ports for available updates === No origin available for eigen~pkg-renamed~3FCF-3.2.2 === Cannot continue === Aborting update This -renamed~3FCF-3.2.2 extension occurs on many ports and in UPDATING, there is no mark that should give me a hint ... This happens when you have multiple ports installed with the same port name. As the port name has now become the unique key in the package system, packages with duplicate names have had an arbitrary string appended to their names to distinguish them and allow pkg to upgrade it's database schema. This duplicated names problem shouldn't occur in an up-to-date ports tree, and we expected it to be a very rare occurrence in general. I don't know why portmaster is complaining about not being able to find the package origin -- that's still stored in the package database and won't have been modified at all. You should be able to see them by: pkg info -ox '~pkg-renamed~' To fix the problem, probably the best approach would be to judiciously delete and reinstall those renamed packages you want to keep, and delete the rest. Ideally you should find that those ports now have distinct names. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
