Re: Using Apache ant without base gcc
My guess for easiest way is to create temp dir somewhere in WRKDIR, put there link gcc - system-gcc46 and prepend it to path. 2013/11/22 Alexander Yerenkow yeren...@gmail.com You should take a look at http://ant-contrib.sourceforge.net/compiler.html cc is not there. I'll take a look a bit later, maybe some solution will come up. 2013/11/21 Tassilo Philipp tphil...@potion-studios.com Hi, although I planned to, I didn't have time to look at jogamp-jogl, yet, so I'm sorry, I don't really know what to do here, either... Sorry, ~ Tassilo On Fri, 22 Nov 2013 05:11:56 +1100 Peter Jeremy pe...@rulingia.com wrote: I've tried asking this on -java without any response so I'm trying a wider audience. I am the manintainer for graphics/jogl and the build cluster reports that it's failing on 10-stable and head on both i386 and amd64 because there's no gcc: /wrkdirs/usr/ports/graphics/jogl/work/gluegen/make/build.xml:343: Could not launch gcc: java.io.IOException: Cannot run program gcc (in directory /wrkdirs/usr/ports/graphics/jogl/work/gluegen/build/obj): java.io.IOException: error=2, No such file or directory The compiler is defined as: compiler id=compiler.cfg.freebsd name=gcc /compiler compiler id=compiler.cfg.freebsd.amd64 name=gcc compilerarg value=-fPIC/ /compiler If I add USE_GCC=any to the port Makefile then it still fails because lang/gcc installs 'gcc46', rather than 'gcc'. If I change all the 'gcc' references to 'cc' (which would pick up clang) then it fails with: /tank/obj/usr/ports/graphics/jogl/work/gluegen/make/gluegen-cpptasks.xml:497: cc is not a legal value for this attribute where gluegen-cpptasks.xml:497 has compiler id=compiler.cfg.freebsd name=cc Whilst ant isn't that uncommon in the ports tree, graphics/jogamp-jogl is the only other port I've found that uses ant in this way and it is also failing. I'm a long way from an expert on ant and I've had a rummage around the Internet but haven't found a solution. Can anyone with more ant-foo help? -- Peter Jeremy ___ 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 -- Regards, Alexander Yerenkow -- Regards, Alexander Yerenkow ___ 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] r334520: 3x leftovers, 1x success
- Update MAINTAINER: use canonical format for po...@freebsd.org - Build ID: 20131121203800-20174 Job owner: sunp...@freebsd.org Buildtime: 13 hours Enddate: Fri, 22 Nov 2013 09:37:23 GMT Revision: r334520 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334520 - Port:games/py-mnemosyne 2.2.1,1 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~sunp...@freebsd.org/20131121203800-20174-229848/py27-mnemosyne-2.2.1,1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~sunp...@freebsd.org/20131121203800-20174-229849/py27-mnemosyne-2.2.1,1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~sunp...@freebsd.org/20131121203800-20174-229850/py27-mnemosyne-2.2.1,1.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~sunp...@freebsd.org/20131121203800-20174-229851/py27-mnemosyne-2.2.1,1.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131121203800-20174 redports https://qat.redports.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 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 +-+ devel/papi | 5.2.0 | 5.3.0 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt If wish to stop receiving portscout reminders, please contact portsc...@freebsd.org Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Upgrading Perl... Somebody just shoot me and put me out of my misery!
On Fri, Nov 22, 2013 at 12:25:26AM -0800, Ronald F. Guilmette wrote: pkg_info says that at present I have perl5.14-5.14.4_3 installed. So excuse my french, but why the fuck didn't the command: portupgrade -o lang/perl5.16 -f perl-5.14.\* actually *DO* anything? Wouldn't the pattern perl-5.14.\* fail to match your package perl5.14-5.14.4_3? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[patch] attempt to update net/citrix_ica to 13.0.0, missing symbols
Here is my attempt to update net/citrix_ica to 13.0.0. Unfortunately I ended up with missing symbols: http://people.freebsd.org/~ehaupt/patches/citrix_ica.patch After the installation I used www/nspluginwrapper: $ cd ~/.mozilla/plugins/ $ nspluginwrapper -v -i /usr/local/ICAClient/npica.so Install plugin /usr/local/ICAClient/npica.so into /home/ehaupt/.mozilla/plugins/npwrapper.npica.so $ firefox about:plugins I can see the plugin: http://i.imgur.com/K9gT1t6.png When I'm trying to initiate a citrix session I get: /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin: symbol lookup error: /usr/local/ICAClient/npica.so: undefined symbol: mkstemps *** NSPlugin Wrapper *** ERROR: NPP_NewStream() wait for reply: Connection closed Trying to initiate the session from the console: $ /usr/local/ICAClient/wfica /tmp/launch.ica /usr/local/ICAClient/wfica: symbol lookup error: /usr/local/ICAClient/lib/UIDialogLib.so: undefined symbol: gtk_widget_set_can_default Seems like it's missing linux gnome-utils. Well, this is where I left off. If time permits I might pursue this further but meanwhile if anyone else likes to give it a shoot feel free. Emanuel ___ 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: Upgrading Perl... Somebody just shoot me and put me out of my misery!
+--On 22 novembre 2013 00:25:26 -0800 Ronald F. Guilmette r...@tristatelogic.com wrote: | AUTHOR: m...@freebsd.org Cough, cough, yeah, I mostly wrote that. | portupgrade -o lang/perl5.16 -f perl-5.14.\* At that time, that line was right. Now, after that, the perl packages name which had the same name (all named perl) and were conflicting and were renamed to perl5 for the default perl, that is, 5.16, and perl5.xx for the non default ones, that are 5.12, 5.14 and 5.18. | pkg_info says that at present I have perl5.14-5.14.4_3 installed. So | excuse my french, but why the fuck didn't the command: | |portupgrade -o lang/perl5.16 -f perl-5.14.\* Now, as you can see, your perl is not named perl-5.14 but perl5.14-5.14.4_3, so, you should change that line to : portupgrade -o lang/perl5.16 -f perl5.14-5.14.4_3 I'll commit an update to that 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: Upgrading Perl... Somebody just shoot me and put me out of my misery!
+--On 22 novembre 2013 12:52:26 +0100 Mathieu Arnold m...@mat.cc wrote: | +--On 22 novembre 2013 00:25:26 -0800 Ronald F. Guilmette | r...@tristatelogic.com wrote: || pkg_info says that at present I have perl5.14-5.14.4_3 installed. So || excuse my french, but why the fuck didn't the command: || ||portupgrade -o lang/perl5.16 -f perl-5.14.\* | | portupgrade -o lang/perl5.16 -f perl5.14-5.14.4_3 You should even be able to do the easier : portupgrade -o lang/perl5.16 -f lang/perl5.14 -- 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: Using Apache ant without base gcc
On 22 Nov 2013, at 09:44, Alexander Yerenkow yeren...@gmail.com wrote: You should take a look at http://ant-contrib.sourceforge.net/compiler.html cc is not there. I'll take a look a bit later, maybe some solution will come up. Eh, maybe just use c++ then? -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Upgrading Perl... Somebody just shoot me and put me out of my misery!
I *was* equally setback by this upgrade, but am slowly mostly fixing it on a
build machine to maybe package over to the usual one:
(My quicker pipes have not been working ...)
..
cd /var/db/pkg
gnuls -oSr | grep p5 | head [ increment each time... 10, 20...] | awk
'{print $8 }' xargs -J % find % -type f
-name +MTREE_DIRS -exec /bin/ls -lac {} \;
[ more to the pipe maybe automates the next ...]
...
You'll see ports *since* last upgrading perl and *not since*. Simply type the
older ones into
portmaster -d -B -i -g p5-.. p5-... p5-.
.
I am in a rush on some aspects of this update, so on ones which don't install
use something like...
cd /usr/ports/net/p5-Socket
/bin/rm -rf work
make -DNO_STAGE -DMAKE_JOBS_UNSAFE -DNO_PACKAGE reinstall
YMMV. [ It is quite obviously piecemeal, this method...]
..
Another glitch with this upgrade, every Nth port seemingly wants to revert perl
5.16 5.14 in the process of
install from a package, so I've often
/bin/rm -v /usr/bin/perl
/bin/rm -v /usr/bin/perl5
/bin/rm -v /usr/local/bin/perl
ln -s /usr/local/bin/perl5.16.3 /usr/local/bin/perl
ln -s /usr/local/bin/perl5.16.3 /usr/bin/perl
ln -s /usr/local/bin/perl5.16.3 /usr/bin/perl5
After cntl-c the new failing install-older-perl package *BEFORE* it installs
the older perl *ALSO*
.
If I am wiser next time, and maybe even on this older-perl machine, I'll simply
delete all p5-s after printing them out,
and awk / gtr /xargs the file into portmaster. I expect the workarounds to
still be maybe necc. though.
.
J. Bouquet
Sorry for typos
On Friday, November 22, 2013 3:52 AM, Mathieu Arnold m...@mat.cc wrote:
+--On 22 novembre 2013 00:25:26 -0800 Ronald F. Guilmette
r...@tristatelogic.com wrote:
| AUTHOR: m...@freebsd.org
Cough, cough, yeah, I mostly wrote that.
| portupgrade -o lang/perl5.16 -f perl-5.14.\*
At that time, that line was right. Now, after that, the perl packages name
which had the same name (all named perl) and were conflicting and were
renamed to perl5 for the default perl, that is, 5.16, and perl5.xx for the
non default ones, that are 5.12, 5.14 and 5.18.
| pkg_info says that at present I have perl5.14-5.14.4_3 installed. So
| excuse my french, but why the fuck didn't the command:
|
| portupgrade -o lang/perl5.16 -f perl-5.14.\*
Now, as you can see, your perl is not named perl-5.14 but
perl5.14-5.14.4_3, so, you should change that line to :
portupgrade -o lang/perl5.16 -f perl5.14-5.14.4_3
I'll commit an update to that 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
___
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: DESTDIR support broken?
On 19/11/2013 18:44, Dominic Fandrey wrote: On 18/11/2013 20:28, Kimmo Paasiala wrote: On Mon, Nov 18, 2013 at 10:05 AM, Dominic Fandrey kamik...@bsdforen.de wrote: On 18/11/2013 04:10, Eitan Adler wrote: On Thu, Nov 14, 2013 at 1:00 PM, Dominic Fandrey kamik...@bsdforen.de wrote: # make DESTDIR=/root/tmpdest install === Creating some important subdirectories Are you sure you don't mean make PREFIX=/root/tmpdest/ ? Yes. -- I would expect DESTDIR=/some/path just work for any port. Last commit to bsd.destdir was over a year ago so either it has been broken for a long time or some other more recent commit has broken it. /root/tmpdest is a complete FreeBSD chroot (I did a make installworld distribution DESTDIR=/root/tmpdest right beforehand). I tried several ports, they all exhibit the same failure. The issue is that BSD make (in stable/10) passes set -e to the shell by default. I submitted the details and a fix: http://www.freebsd.org/cgi/query-pr.cgi?pr=184170 -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: DESTDIR support broken?
On 22.11.2013, at 15.17, Peter Pentchev r...@ringlet.net wrote: On Fri, Nov 22, 2013 at 02:02:28PM +0100, Dominic Fandrey wrote: On 19/11/2013 18:44, Dominic Fandrey wrote: On 18/11/2013 20:28, Kimmo Paasiala wrote: On Mon, Nov 18, 2013 at 10:05 AM, Dominic Fandrey kamik...@bsdforen.de wrote: On 18/11/2013 04:10, Eitan Adler wrote: On Thu, Nov 14, 2013 at 1:00 PM, Dominic Fandrey kamik...@bsdforen.de wrote: # make DESTDIR=/root/tmpdest install === Creating some important subdirectories Are you sure you don't mean make PREFIX=/root/tmpdest/ ? Yes. -- I would expect DESTDIR=/some/path just work for any port. Last commit to bsd.destdir was over a year ago so either it has been broken for a long time or some other more recent commit has broken it. /root/tmpdest is a complete FreeBSD chroot (I did a make installworld distribution DESTDIR=/root/tmpdest right beforehand). I tried several ports, they all exhibit the same failure. The issue is that BSD make (in stable/10) passes set -e to the shell by default. I submitted the details and a fix: http://www.freebsd.org/cgi/query-pr.cgi?pr=184170 Hmm, even if this is so, I wonder if there would not be another funny problem later: for ports that actually use staging, bsd.stage.mk tries to pass a DESTDIR of its own to upstream's build system, so the DESTDIR specified on the make(1) command line might not be passed to upstream's build system at all. So bsd.destdir.mk might do its thing, but then bsd.stage.mk would override the DESTDIR setting during the actual build and installation of the upstream sources, so I wonder if anything at all would be installed into the chroot. G'luck, Peter As far as I know the temporary setting of DESTDIR to the stagedir is in effect only during ‘make stage’ so during ‘make install’ your own custom DESTDIR should be respected. -Kimmo signature.asc Description: Message signed with OpenPGP using GPGMail
Re: DESTDIR support broken?
On Fri, Nov 22, 2013 at 02:02:28PM +0100, Dominic Fandrey wrote: On 19/11/2013 18:44, Dominic Fandrey wrote: On 18/11/2013 20:28, Kimmo Paasiala wrote: On Mon, Nov 18, 2013 at 10:05 AM, Dominic Fandrey kamik...@bsdforen.de wrote: On 18/11/2013 04:10, Eitan Adler wrote: On Thu, Nov 14, 2013 at 1:00 PM, Dominic Fandrey kamik...@bsdforen.de wrote: # make DESTDIR=/root/tmpdest install === Creating some important subdirectories Are you sure you don't mean make PREFIX=/root/tmpdest/ ? Yes. -- I would expect DESTDIR=/some/path just work for any port. Last commit to bsd.destdir was over a year ago so either it has been broken for a long time or some other more recent commit has broken it. /root/tmpdest is a complete FreeBSD chroot (I did a make installworld distribution DESTDIR=/root/tmpdest right beforehand). I tried several ports, they all exhibit the same failure. The issue is that BSD make (in stable/10) passes set -e to the shell by default. I submitted the details and a fix: http://www.freebsd.org/cgi/query-pr.cgi?pr=184170 Hmm, even if this is so, I wonder if there would not be another funny problem later: for ports that actually use staging, bsd.stage.mk tries to pass a DESTDIR of its own to upstream's build system, so the DESTDIR specified on the make(1) command line might not be passed to upstream's build system at all. So bsd.destdir.mk might do its thing, but then bsd.stage.mk would override the DESTDIR setting during the actual build and installation of the upstream sources, so I wonder if anything at all would be installed into the chroot. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 If this sentence were in Chinese, it would say something else. signature.asc Description: Digital signature
Re: DESTDIR support broken?
On 22/11/2013 14:17, Peter Pentchev wrote: On Fri, Nov 22, 2013 at 02:02:28PM +0100, Dominic Fandrey wrote: On 19/11/2013 18:44, Dominic Fandrey wrote: On 18/11/2013 20:28, Kimmo Paasiala wrote: On Mon, Nov 18, 2013 at 10:05 AM, Dominic Fandrey kamik...@bsdforen.de wrote: On 18/11/2013 04:10, Eitan Adler wrote: On Thu, Nov 14, 2013 at 1:00 PM, Dominic Fandrey kamik...@bsdforen.de wrote: # make DESTDIR=/root/tmpdest install === Creating some important subdirectories Are you sure you don't mean make PREFIX=/root/tmpdest/ ? Yes. -- I would expect DESTDIR=/some/path just work for any port. Last commit to bsd.destdir was over a year ago so either it has been broken for a long time or some other more recent commit has broken it. /root/tmpdest is a complete FreeBSD chroot (I did a make installworld distribution DESTDIR=/root/tmpdest right beforehand). I tried several ports, they all exhibit the same failure. The issue is that BSD make (in stable/10) passes set -e to the shell by default. I submitted the details and a fix: http://www.freebsd.org/cgi/query-pr.cgi?pr=184170 Hmm, even if this is so, I wonder if there would not be another funny problem later: for ports that actually use staging, ... I tested the fix with a port that I just converted to staging. No problems there. The staging happens on the host system, but the resulting package is correctly installed into DESTDIR. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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/aria2 dependencies lang/llvm33 build error
On Sun 2013-11-17 14:15:02 UTC+0100, Michael Gmelin (free...@grem.de) wrote: www/aria2 1.18.1 requires lang/clang33. Is this really necessary? Previous aria2 versions didn't require clang. I've now had a chance to check the aria2 sources and evidently it now requires C++11 support, which I find surprising, but that's progress I suppose... From a developer's standpoint this makes a lot of sense, since C++11 is more productive and a lot more fun to use. Sounds good. I just wonder about the logic behind doing that for a minor 1.17 - 1.18 release though. I just built sudo successfully on 9.1 using system clang 3.1 and CXX=clang++ CXXFLAGS+=-std=c++11 -stdlib=libc++ Yeah, I have no problem building sudo with clang. The sudo code is all C though, not C++. I upgraded from FreeBSD 8.4-REL to 9.2-REL during the week. Trying to build aria2 with or without the above in /etc/make.conf still results in: checking whether clang++ supports C++11 features by default... no The only place I can get aria2 1.18 to build successfully is under FreeBSD 10.0-BETA(3) (tested in a VM). So that tends to rule out aria2's configure script being broken at least. For the time being I'm using portdowngrade to install aria2 1.17. Not a big deal, and I suspect I'll be upgrading my servers from FreeBSD 9.2 to 10.x sometime early next year, whereby this issue will fix itself... The problem you're facing is probably the lack of libc++, which contains all the C++11 library features. You can use C++11 using the old gcc standard C++ library, but then you won't have access to about 2/3 of the new features which are all implemented in the library. To get those on a system that doesn't ship with clang already you could install devel/libc++. Unfortunately this won't build on older hosts due to the lack of aligned_alloc. While this can be worked around by defining your local aligned_alloc, you'll probably trip over the lack of xlocale(3) support, which is required to build libc++ successfully and first appeared in 9.1. Out of curiosity I tried building devel/libc++ under 9.2 but it failed with: Shared object libz.so.5 not found, required by libLLVM-3.3.so Evidently the fix is to add libz.so.5 libz.so to /etc/libmap.conf. I then point /etc/make.conf to lang/clang33: CC=clang33 CXX=clang++33 CPP=clang++33 -E aria2 1.18's configure still breaks though, darn: checking whether clang++33 supports C++11 features by default... no So basically I see two options for you: - Update to 9.2-RELEASE, 8.4 will be EoL soon anyway FWIW the reason I stuck with 8.4 was because it's EoL in June 2015, whereas 9.2 is EoL in September 2014. http://www.freebsd.org/security/security.html#sup Upgrading from 8.4 to 9.2 was surprisingly painless though, so I'm not as concerned with future upgrades. My main worry was root on ZFS, and whether the pool would be bootable from the newer kernel. It all went swimmingly though. Disk performance seems to have improved a little too which is nice. - Try building aria with a recent gcc instead I've had no success with that either! Thanks for the pointers, though. Regards Andrew ___ 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: DESTDIR support broken?
On 22/11/2013 14:17, Peter Pentchev wrote: On Fri, Nov 22, 2013 at 02:02:28PM +0100, Dominic Fandrey wrote: On 19/11/2013 18:44, Dominic Fandrey wrote: On 18/11/2013 20:28, Kimmo Paasiala wrote: On Mon, Nov 18, 2013 at 10:05 AM, Dominic Fandrey kamik...@bsdforen.de wrote: On 18/11/2013 04:10, Eitan Adler wrote: On Thu, Nov 14, 2013 at 1:00 PM, Dominic Fandrey kamik...@bsdforen.de wrote: # make DESTDIR=/root/tmpdest install === Creating some important subdirectories Are you sure you don't mean make PREFIX=/root/tmpdest/ ? Yes. -- I would expect DESTDIR=/some/path just work for any port. Last commit to bsd.destdir was over a year ago so either it has been broken for a long time or some other more recent commit has broken it. /root/tmpdest is a complete FreeBSD chroot (I did a make installworld distribution DESTDIR=/root/tmpdest right beforehand). I tried several ports, they all exhibit the same failure. The issue is that BSD make (in stable/10) passes set -e to the shell by default. I submitted the details and a fix: http://www.freebsd.org/cgi/query-pr.cgi?pr=184170 Hmm, even if this is so, I wonder if there would not be another funny problem later: for ports that actually use staging, bsd.stage.mk tries to pass a DESTDIR of its own to upstream's build system, so the DESTDIR specified on the make(1) command line might not be passed to upstream's build system at all. So bsd.destdir.mk might do its thing, but then bsd.stage.mk would override the DESTDIR setting during the actual build and installation of the upstream sources, so I wonder if anything at all would be installed into the chroot. bsd.stage.mk sets DESTDIR in MAKE_ARGS, which does not affect the ports infrastructure at all. Instead it is passed to the make run in the WRKSRC by the default do-build and do-install targets. Where it is commonly picked up by build/install systems such as auto-tools generated stuff to install into chroots. This results in the port being installed into STAGEDIR where the ports system the creates a package. And pkg install installs it into the actual DESTDIR. It is not affected by MAKE_ARGS. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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/aria2 dependencies lang/llvm33 build error
On Fri 2013-11-22 15:37:56 UTC+0100, Michael Gmelin (free...@grem.de) wrote: I just built sudo successfully on 9.1 using system clang 3.1 and CXX=clang++ CXXFLAGS+=-std=c++11 -stdlib=libc++ Yeah, I have no problem building sudo with clang. The sudo code is all C though, not C++. Well, that was supposed to be aria2 and not sudo (no idea why I wrote sudo in the first place, probably multitasking when I shouldn't have). A tried it specifically because it didn't build about two weeks earlier due to being incompatible with C++11. So it went straight from not working with C++11 to requiring C++11. Good times :) Ah. Then the obvious question is... How did you get aria2 to build in 9.1 when I can't get it to build in 9.2? ;-) Regards Andrew ___ 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/aria2 dependencies lang/llvm33 build error
On Sat, 23 Nov 2013 01:20:55 +1100 andrew clarke m...@ozzmosis.com wrote: Slightly confused post on my part, sorry ;) On Sun 2013-11-17 14:15:02 UTC+0100, Michael Gmelin (free...@grem.de) wrote: www/aria2 1.18.1 requires lang/clang33. Is this really necessary? Previous aria2 versions didn't require clang. I've now had a chance to check the aria2 sources and evidently it now requires C++11 support, which I find surprising, but that's progress I suppose... From a developer's standpoint this makes a lot of sense, since C++11 is more productive and a lot more fun to use. Sounds good. I just wonder about the logic behind doing that for a minor 1.17 - 1.18 release though. True, that's not a very friendly move. I just built sudo successfully on 9.1 using system clang 3.1 and CXX=clang++ CXXFLAGS+=-std=c++11 -stdlib=libc++ Yeah, I have no problem building sudo with clang. The sudo code is all C though, not C++. Well, that was supposed to be aria2 and not sudo (no idea why I wrote sudo in the first place, probably multitasking when I shouldn't have). A tried it specifically because it didn't build about two weeks earlier due to being incompatible with C++11. So it went straight from not working with C++11 to requiring C++11. Good times :) Upgrading from 8.4 to 9.2 was surprisingly painless though, so I'm not as concerned with future upgrades. My main worry was root on ZFS, and whether the pool would be bootable from the newer kernel. It all went swimmingly though. Disk performance seems to have improved a little too which is nice. Yeah, updates to 9 have been really smooth compared to previous releases (there is nothing like going from 4.11 to 5.3 :D). I have no numbers to support this, but 9.2 feels snappier to me than 9.1 - like something got unstuck. Cheers, Michael -- Michael Gmelin ___ 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/aria2 dependencies lang/llvm33 build error
On Sat, 23 Nov 2013 01:41:25 +1100 andrew clarke m...@ozzmosis.com wrote: On Fri 2013-11-22 15:37:56 UTC+0100, Michael Gmelin (free...@grem.de) wrote: I just built sudo successfully on 9.1 using system clang 3.1 and CXX=clang++ CXXFLAGS+=-std=c++11 -stdlib=libc++ Yeah, I have no problem building sudo with clang. The sudo code is all C though, not C++. Well, that was supposed to be aria2 and not sudo (no idea why I wrote sudo in the first place, probably multitasking when I shouldn't have). A tried it specifically because it didn't build about two weeks earlier due to being incompatible with C++11. So it went straight from not working with C++11 to requiring C++11. Good times :) Ah. Then the obvious question is... How did you get aria2 to build in 9.1 when I can't get it to build in 9.2? ;-) I built 9.1 from source using: WITH_LIBCPLUSPLUS=YES (and later WITH_CLANG_EXTRAS=1) (make buildworld installworld kernel) So I've got libc++. All ports are built using: CC=clang CXX=clang++ CXXFLAGS+= -std=c++11 -stdlib=libc++ CPP=clang-cpp -- Michael Gmelin ___ 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/aria2 dependencies lang/llvm33 build error
On Fri 2013-11-22 15:51:14 UTC+0100, Michael Gmelin (free...@grem.de) wrote: Then the obvious question is... How did you get aria2 to build in 9.1 when I can't get it to build in 9.2? ;-) I built 9.1 from source using: WITH_LIBCPLUSPLUS=YES (and later WITH_CLANG_EXTRAS=1) (make buildworld installworld kernel) So I've got libc++. All ports are built using: CC=clang CXX=clang++ CXXFLAGS+= -std=c++11 -stdlib=libc++ CPP=clang-cpp I see! I'll give that a try if I get some free time, although the effort required seems excessive just to build the latest aria2 . :) Thanks Michael, Regards Andrew ___ 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] r334492: 1x leftovers, 1x depend (depend_package in graphics/gdk-pixbuf2), 2x success
. support STAGE; . use new LIB_DEPENDS syntax; . use native iconv at FreeBSD 9.x; . remove build dependency upon devel/xdg-utils (they install files to PREFIX) and use post-install target to install files to STAGEDIR. - Build ID: 20131121135200-36610 Job owner: b...@freebsd.org Buildtime: 26 hours Enddate: Fri, 22 Nov 2013 16:12:44 GMT Revision: r334492 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334492 - Port:graphics/iccexamin 0.54_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20131121135200-36610-229632/iccexamin-0.54_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~b...@freebsd.org/20131121135200-36610-229633/iccexamin-0.54_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: DEPEND (DEPEND_PACKAGE IN GRAPHICS/GDK-PIXBUF2) Log: https://qat.redports.org//~b...@freebsd.org/20131121135200-36610-229634/gdk-pixbuf2-2.28.2.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20131121135200-36610-229635/iccexamin-0.54_1.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131121135200-36610 redports https://qat.redports.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: CFT: icewm update
Hello. dog@dog:~ uname -a FreeBSD dog 10.0-BETA3 FreeBSD 10.0-BETA3 #0 r258354: Tue Nov 19 22:18:10 EET 2013 root@dog:/usr/obj/usr/src/sys/DOG amd64 Fails with thw following error: dog@dog:~ cd /usr/ports/x11-wm/icewm/ dog@dog:/usr/ports/x11-wm/icewm sudo make clean === Cleaning for icewm-1.3.7_3 dog@dog:/usr/ports/x11-wm/icewm sudo wget http://people.freebsd.org/~eadler/files/icewm-update.diff --2013-11-22 19:53:30-- http://people.freebsd.org/~eadler/files/icewm-update.diff Визначення імені people.freebsd.org (people.freebsd.org)... 8.8.178.141 Connecting to people.freebsd.org (people.freebsd.org)|8.8.178.141|:80... під'єднано. HTTP-запит надіслано, очікуєм відповіді... 200 OK Довжина: 6734 (6,6K) [text/plain] Saving to: 'icewm-update.diff' 100%[] 6 734 --.-K/s in 0,001s 2013-11-22 19:53:30 (9,00 MB/s) - 'icewm-update.diff' saved [6734/6734] dog@dog:/usr/ports/x11-wm/icewm sudo sh -c patch icewm-update.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: Makefile |=== |--- Makefile (revision 333538) |+++ Makefile (working copy) -- Patching file Makefile using Plan A... Hunk #1 succeeded at 2 with fuzz 1. Hunk #2 succeeded at 27. Hunk #3 succeeded at 87. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |Index: distinfo |=== |--- distinfo (revision 333538) |+++ distinfo (working copy) -- Patching file distinfo using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |Index: files/patch-Makefile.in |=== |--- files/patch-Makefile.in (revision 0) |+++ files/patch-Makefile.in (working copy) -- (Creating file files/patch-Makefile.in...) Patching file files/patch-Makefile.in using Plan A... Empty context always matches. Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- | |Property changes on: files/patch-Makefile.in |___ |Added: svn:mime-type |## -0,0 +1 ## |+text/plain |\ No newline at end of property |Added: svn:keywords |## -0,0 +1 ## |+FreeBSD=%H |\ No newline at end of property |Added: fbsd:nokeywords |## -0,0 +1 ## |+yes |\ No newline at end of property |Added: svn:eol-style |## -0,0 +1 ## |+native |\ No newline at end of property |Index: files/patch-src__Makefile.in |=== |--- files/patch-src__Makefile.in (revision 333538) |+++ files/patch-src__Makefile.in (working copy) -- Patching file files/patch-src__Makefile.in using Plan A... Hunk #1 succeeded at 0. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |Index: files/patch-src__aapm.cc |=== |--- files/patch-src__aapm.cc (revision 333538) |+++ files/patch-src__aapm.cc (working copy) -- Patching file files/patch-src__aapm.cc using Plan A... Hunk #1 succeeded at 0. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |Index: files/patch-src__apppstatus.cc |=== |--- files/patch-src__apppstatus.cc (revision 333538) |+++ files/patch-src__apppstatus.cc (working copy) -- Patching file files/patch-src__apppstatus.cc using Plan A... Hunk #1 succeeded at 0. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |Index: files/patch-src__wmapp.h |=== |--- files/patch-src__wmapp.h (revision 0) |+++ files/patch-src__wmapp.h (working copy) -- (Creating file files/patch-src__wmapp.h...) Patching file files/patch-src__wmapp.h using Plan A... Empty context always matches. Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- | |Property changes on: files/patch-src__wmapp.h |___ |Added: fbsd:nokeywords |## -0,0 +1 ## |+yes |\ No newline at end of property |Added: svn:eol-style |## -0,0 +1 ## |+native |\ No newline at end of property |Added: svn:mime-type |## -0,0 +1 ## |+text/plain |\ No newline at end of property
[QAT] r334598: 3x leftovers, 1x depend (depend_package in graphics/gdk-pixbuf2)
Use gcc for now. - Build ID: 20131122150800-1809 Job owner: m...@freebsd.org Buildtime: 3 hours Enddate: Fri, 22 Nov 2013 18:22:03 GMT Revision: r334598 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334598 - Port:cad/kicad-devel r4313_3 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20131122150800-1809-230252/kicad-devel-r4313_3.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20131122150800-1809-230253/kicad-devel-r4313_3.log Buildgroup: 9.2-QAT/amd64 Buildstatus: DEPEND (DEPEND_PACKAGE IN GRAPHICS/GDK-PIXBUF2) Log: https://qat.redports.org//~m...@freebsd.org/20131122150800-1809-230254/gdk-pixbuf2-2.28.2.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20131122150800-1809-230255/kicad-devel-r4313_3.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131122150800-1809 redports https://qat.redports.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
[QAT] r334587: 17x success, 1x leftovers, 6x depend (manpage in misc/help2man), 2x fetch, 6x depend (depend_package in x11/qt4-opengl), 2x depend (depend_package in x11-toolkits/qwt5), 2x plist
- Pass QMAKE_ARGS to qmake Approved by:portmgr (blanket approval) - Build ID: 20131122125604-55205 Job owner: m...@freebsd.org Buildtime: 6 hours Enddate: Fri, 22 Nov 2013 18:31:53 GMT Revision: r334587 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334587 - Port:comms/dabstick-radio 0.96_3 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230156/dabstick-radio-0.96_3.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230157/dabstick-radio-0.96_3.log Buildgroup: 9.2-QAT/amd64 Buildstatus: DEPEND (DEPEND_PACKAGE IN X11-TOOLKITS/QWT5) Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230158/qwt5-5.2.3.log Buildgroup: 9.2-QAT/i386 Buildstatus: DEPEND (MANPAGE IN MISC/HELP2MAN) Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230159/help2man-1.43.3.log - Port:comms/jsdr 4.1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230160/jsdr-4.1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230161/jsdr-4.1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: DEPEND (DEPEND_PACKAGE IN X11-TOOLKITS/QWT5) Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230162/qwt5-5.2.3.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230163/jsdr-4.1.log - Port:graphics/fracplanet 0.4.0_5 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230164/fracplanet-0.4.0_5.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230165/fracplanet-0.4.0_5.log Buildgroup: 9.2-QAT/amd64 Buildstatus: DEPEND (DEPEND_PACKAGE IN X11/QT4-OPENGL) Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230166/qt4-opengl-4.8.5.log Buildgroup: 9.2-QAT/i386 Buildstatus: DEPEND (MANPAGE IN MISC/HELP2MAN) Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230167/help2man-1.43.3.log - Port:multimedia/smplayer 0.8.6 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230168/smplayer-0.8.6.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230169/smplayer-0.8.6.log Buildgroup: 9.2-QAT/amd64 Buildstatus: DEPEND (DEPEND_PACKAGE IN X11/QT4-OPENGL) Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230170/qt4-opengl-4.8.5.log Buildgroup: 9.2-QAT/i386 Buildstatus: DEPEND (MANPAGE IN MISC/HELP2MAN) Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230171/help2man-1.43.3.log - Port:multimedia/smtube 1.8 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230172/smtube-1.8.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230173/smtube-1.8.log Buildgroup: 9.2-QAT/amd64 Buildstatus: DEPEND (DEPEND_PACKAGE IN X11/QT4-OPENGL) Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230174/qt4-opengl-4.8.5.log Buildgroup: 9.2-QAT/i386 Buildstatus: DEPEND (MANPAGE IN MISC/HELP2MAN) Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230175/help2man-1.43.3.log - Port:multimedia/umplayer 0.97_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: PLIST Log: https://qat.redports.org//~m...@freebsd.org/20131122125604-55205-230176/umplayer-0.97_1.log Buildgroup: 8.4-QAT/i386 Buildstatus:
[QAT] r334552: 3x leftovers, 1x success
use GNU_CONFIGURE instead of USE_AUTOTOOLS to force the use of the local libtool script to link the libraries with the correct linker and not with the system linker which breaks linking on FreeBSD 8 as the linker is to old here. - Build ID: 20131122075600-35980 Job owner: oli...@freebsd.org Buildtime: 11 hours Enddate: Fri, 22 Nov 2013 18:56:51 GMT Revision: r334552 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334552 - Port:devel/atlas-devel 0.6.3 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~oli...@freebsd.org/20131122075600-35980-230004/Atlas-devel-0.6.3.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~oli...@freebsd.org/20131122075600-35980-230005/Atlas-devel-0.6.3.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~oli...@freebsd.org/20131122075600-35980-230006/Atlas-devel-0.6.3.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~oli...@freebsd.org/20131122075600-35980-230007/Atlas-devel-0.6.3.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131122075600-35980 redports https://qat.redports.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
Fw: Upgrading Perl... yesterday's AWK improved, working...
Sorry for top-posting... [ other email services are on my todo list (
hushmail, runbox, polarismail, if/when the
email volume here increases... ]
the +MTREE_DIRS pipe can be extended...
... | grep -v v 2 [OMITTING Nov 21 already-updateds] | awk '{print $9}' |
gtr -s \/ \n | grep p5 | xargs -J % portmaster -d -B -i -g %
yell || yell
If one has gnuls, gtr (coreutils?) installed, and still uses
/var/db/pkg/PORTNAME-NUMBER, that pipe (the second part above, the
first below...) just updated at-once 14 of the hundreds of p5 ports as I had
updated the head -115 to head -135 ( approximately).
I expect to copy [1] that !hint to all /lang/ (perl ) (ruby) (python) to use
until pkgng, at which point I hope that someone has posted
a PKG equivalent... or evolved a feature of PKG where it writes its /var/db/pkg
files out again after each operation, so equivalent
pipes can occur.
1.. actually, scrot of this email before sending, so more information included.
( the .jpg to the /lang/ directories...)
On Friday, November 22, 2013 4:17 AM, Jeffrey Bouquet
jeffreybouq...@yahoo.com wrote:
I *was* equally setback by this upgrade, but am slowly mostly fixing it on a
build machine to maybe package over to the usual one:
(My quicker pipes have not been working ...)
..
cd /var/db/pkg
gnuls -oSr | grep p5 | head [ increment each time... 10, 20...] | awk
'{print $8 }' xargs -J % find % -type f
-name +MTREE_DIRS -exec /bin/ls -lac {} \;
[ more to the pipe maybe automates the next ...]
...
You'll see ports *since* last upgrading perl and *not since*. Simply type the
older ones into
portmaster -d -B -i -g p5-.. p5-... p5-.
.
I am in a rush on some aspects of this update, so on ones which don't install
use something like...
cd /usr/ports/net/p5-Socket
/bin/rm -rf work
make -DNO_STAGE -DMAKE_JOBS_UNSAFE -DNO_PACKAGE reinstall
YMMV. [ It is quite obviously piecemeal, this method...]
..
Another glitch with this upgrade, every Nth port seemingly wants to revert perl
5.16 5.14 in the process of
install from a package, so I've often
/bin/rm -v /usr/bin/perl
/bin/rm -v /usr/bin/perl5
/bin/rm -v /usr/local/bin/perl
ln -s /usr/local/bin/perl5.16.3 /usr/local/bin/perl
ln -s /usr/local/bin/perl5.16.3 /usr/bin/perl
ln -s /usr/local/bin/perl5.16.3 /usr/bin/perl5
After cntl-c the new failing install-older-perl package *BEFORE* it installs
the older perl *ALSO*
.
If I am wiser next time, and maybe even on this older-perl machine, I'll simply
delete all p5-s after printing them out,
and awk / gtr /xargs the file into portmaster. I expect the workarounds to
still be maybe necc. though.
.
J. Bouquet
Sorry for typos
On Friday, November 22, 2013 3:52 AM, Mathieu Arnold m...@mat.cc wrote:
+--On 22 novembre 2013 00:25:26 -0800 Ronald F. Guilmette
r...@tristatelogic.com wrote:
| AUTHOR: m...@freebsd.org
Cough, cough, yeah, I mostly wrote that.
| portupgrade -o lang/perl5.16 -f perl-5.14.\*
At that time, that line was right. Now, after that, the perl packages name
which had the same name (all named perl) and were conflicting and were
renamed to perl5 for the default perl, that is, 5.16, and perl5.xx for the
non default ones, that are 5.12, 5.14 and 5.18.
| pkg_info says that at present I have perl5.14-5.14.4_3 installed. So
| excuse my french, but why the fuck didn't the command:
|
| portupgrade -o lang/perl5.16 -f perl-5.14.\*
Now, as you can see, your perl is not named perl-5.14 but
perl5.14-5.14.4_3, so, you should change that line to :
portupgrade -o lang/perl5.16 -f perl5.14-5.14.4_3
I'll commit an update to that 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
___
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
lang/gcc46 leaving directories around (WAS: [QAT] r334234: 3x leftovers, 1x depend_object)
Hi All / Gerald, The following reports indicate that /usr/local/share/info/gcc46 (directory) is being left in the working environment and not properly cleaned up. Since the ports do not create or use anything in that directory I assume this is an issue with the lang/gcc46 port. If this has been fixed, my apologies for the noise. Regards On Thursday, 21 November 2013 20:25:41 Ports-QAT wrote: Add stage support for games/knights-kde4. - Build ID: 20131118181800-45853 Job owner: d...@freebsd.org Buildtime: 3 days Enddate: Thu, 21 Nov 2013 20:25:39 GMT Revision: r334234 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334234 - Port:games/knights-kde4 2.5.0_2 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~d...@freebsd.org/20131118181800-45853-228516/knig hts-2.5.0_2.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~d...@freebsd.org/20131118181800-45853-228517/knig hts-2.5.0_2.log Buildgroup: 9.2-QAT/amd64 Buildstatus: DEPEND_OBJECT Log: https://qat.redports.org//~d...@freebsd.org/20131118181800-45853-228518/knig hts-2.5.0_2.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~d...@freebsd.org/20131118181800-45853-228519/knig hts-2.5.0_2.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131118181800-45853 redports https://qat.redports.org/ signature.asc Description: This is a digitally signed message part.
Re: Upgrading Perl... Somebody just shoot me and put me out of my misery!
In message 0fc91d46cdc4b54132d12...@atuin.in.mat.cc, Mathieu Arnold m...@mat.cc wrote: +--On 22 novembre 2013 00:25:26 -0800 Ronald F. Guilmette r...@tristatelogic.com wrote: | AUTHOR: m...@freebsd.org Cough, cough, yeah, I mostly wrote that. | portupgrade -o lang/perl5.16 -f perl-5.14.\* At that time, that line was right. Now, after that, the perl packages name which had the same name (all named perl) and were conflicting and were renamed to perl5 for the default perl, that is, 5.16, and perl5.xx for the non default ones, that are 5.12, 5.14 and 5.18. OK. I probably need another cup of coffee (to awaken that last dormant set of of brain cells) before I'll really grok the conflict you've just described, but that's OK. For the moment, at least, you've explained it well enough and I understand it well enough to proceed, and to make progress in my quest to upgrade my ports. | pkg_info says that at present I have perl5.14-5.14.4_3 installed. So | excuse my french, but why the fuck didn't the command: | |portupgrade -o lang/perl5.16 -f perl-5.14.\* Now, as you can see, your perl is not named perl-5.14 but perl5.14-5.14.4_3, so, you should change that line to : portupgrade -o lang/perl5.16 -f perl5.14-5.14.4_3 Ah! OK. Thank you VERY much. I have just now begun executing the revised command line that you kindly provided, and I'll keep my fingers crossed. (So far things _do_ seem to be progressing nicely.) Hummm Well, that command *did* already complete, as I was typing this message. And now pkg_info says that I have perl5-5.16.3_3 installed. So that is good. Progress. *However* now when I tried to execute the next step you suggested, i.e.: 2) Reinstall everything that depends on Perl: portupgrade -fr perl Once again *nothing* happened! OK, so I scracthed my head for a bit and then tried it this way: portupgrade -fr perl5 Now *that* *did* do something. In fact that appears to have caused Perl (5.16) to be rebuilt and reinstalled all over again *and* now everything in the universe that depended, directly or indirectly on that appears to also be in the process of rebuilding... which is good, I suppose. Now, one last little thing... The note in the UPDATING file dated 20131120 gives essentially the same instructions as the one dated 20131023, *however* it also contains this: 1) Change the option in lang/perl5.16: make -C /usr/ports/lang/perl5.16 config HUH?? I don't understand this at all. What exactly is the option that we are changing here? And what does it matter to anything? It would be Nice if this were entierly less opaque. Regards, rfg ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: CFT: icewm update
[ it was hard to figure out where your reply was ] On Fri, Nov 22, 2013 at 1:04 PM, Pavlo Greenberg d...@virtual.org.ua wrote: Hello. ** Port marked as IGNORE: x11-wm/icewm: patch does not apply Please unset the MENUFIX option and try the build again. --- Listing the results (+:done / -:ignored / *:skipped / !:failed) - x11-wm/icewm (marked as IGNORE) --- Packages processed: 0 done, 1 ignored, 0 skipped and 0 failed --- Session ended at: Fri, 22 Nov 2013 19:59:59 +0200 (consumed 00:00:03) -- Eitan Adler ___ 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: Porting a software which uses INP_GPIO?
On Thu, 21 Nov 2013 16:21:20 -0500
Lowell Gilbert freebsd-ports-lo...@be-well.ilk.org wrote:
Alexander Leidinger alexan...@leidinger.net writes:
I try to compile a software on FreeBSD which wants to use INP_GPIO,
OUTP_GPIO and some oder *GPIO* things.
A quick googling shows me some raspberry pi sites. Is this something
linux-specific (so that I can forget this software on FreeBSD as
long as we don't gain something similar)?
Searching for gpio in names of ports didn't show a hit and in the
basesystem includes I can't find it either.
GPIO is a way to do pin assignments for a chip package at run-time. I
use it on embedded platforms all the time, but it isn't normally
available on a PC. There's a gpioctl(1) that should be able to set the
a pin for input or output, as those flags indicate, or
programmatically I guess it would be GPIO_PIN_INPUT or
GPIO_PIN_OUTPUT in /usr/include/sys/gpio.h but again, you need to
have the hardware for it.
I have the hardware. Currently it is accessed from an old Laptop with
the Windows-binary of the program. I would like to replace the Laptop
and use a FreeBSD version of the program.
The code in question is:
---snip---
const int banks[4]={18,23,24,25};
[...]
for(i=0;i4;i++)
{
INP_GPIO(banks[i]);
OUT_GPIO(banks[i]);
if(i==bank)
{
GPIO_SET = 1 banks[i]; // enable bank
}
else
{
GPIO_CLR = 1 banks[i];// disable bank
}
}
---snip---
When looking at sys/gpio.h, I have no idea how I shall translate the
above into something FreeBSD understands. Could you please explain how
the above translates into FreeBSD-gpio-speak?
Bye,
Alexander.
--
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: lang/gcc46 leaving directories around (WAS: [QAT] r334234: 3x leftovers, 1x depend_object)
On Fri, 22 Nov 2013, David Naylor wrote: The following reports indicate that /usr/local/share/info/gcc46 (directory) is being left in the working environment and not properly cleaned up. Since the ports do not create or use anything in that directory I assume this is an issue with the lang/gcc46 port. This is _not_ an issue with lang/gcc46, but with the general ports infrastructure that I first reported on October 23rd. Bapt had a first patch a week ago http://people.freebsd.org/~bapt/info-dir.diff This indeed removed the stray info/ directory, but caused the following upon `make deinstall` in my testing: /scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file or directory) and could not create (No such file or directory) /scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file or directory) and could not create (No such file or directory) : I just committed a workaround to lang/gcc46, will work on lang/gcc next, and filed PR ports/184178 to track this on the infrastructure side. Gerald ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[QAT] r334511: 1x depend (depend_package in multimedia/gstreamer1), 27x leftovers, 8x depend (manpage in misc/help2man), 1x depend (ignored: cannot install: gstreamer1 uses the ltverhack and/or ltasne
Update to 1.2.1. Retire celt plugin, it was removed in flavor for the opus plugin. Add new webp, kate and openjpeg plugin. - Build ID: 20131121190801-56953 Job owner: k...@freebsd.org Buildtime: 27 hours Enddate: Fri, 22 Nov 2013 22:34:37 GMT Revision: r334511 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334511 - Port:graphics/gstreamer1-plugins-openjpeg 1.2.1 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229784/gstreamer1-plugins-openjpeg-1.2.1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229785/gstreamer1-plugins-openjpeg-1.2.1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229786/gstreamer1-plugins-openjpeg-1.2.1.log Buildgroup: 9.2-QAT/i386 Buildstatus: DEPEND (MANPAGE IN MISC/HELP2MAN) Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229787/help2man-1.43.3.log - Port:graphics/gstreamer1-plugins-webp 1.2.1 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229788/gstreamer1-plugins-webp-1.2.1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229789/gstreamer1-plugins-webp-1.2.1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: DEPEND (IGNORED: CANNOT INSTALL: GSTREAMER1 USES THE LTVERHACK AND/OR LTASNEEDEDHACK GNOME COMPONENTS BUT DOES NOT USE LIBTOOL IN MULTIMEDIA/GSTREAMER1) Buildgroup: 9.2-QAT/i386 Buildstatus: DEPEND (MANPAGE IN MISC/HELP2MAN) Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229791/help2man-1.43.3.log - Port:multimedia/gstreamer1 1.2.1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229792/gstreamer1-1.2.1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229793/gstreamer1-1.2.1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229794/gstreamer1-1.2.1.log Buildgroup: 9.2-QAT/i386 Buildstatus: DEPEND (MANPAGE IN MISC/HELP2MAN) Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229795/help2man-1.43.3.log - Port:multimedia/gstreamer1-libav 1.2.1 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229796/gstreamer1-libav-1.2.1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229797/gstreamer1-libav-1.2.1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: DEPEND (DEPEND_PACKAGE IN MULTIMEDIA/GSTREAMER1) Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229798/gstreamer1-1.2.1.log Buildgroup: 9.2-QAT/i386 Buildstatus: DEPEND (MANPAGE IN MISC/HELP2MAN) Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229799/help2man-1.43.3.log - Port:multimedia/gstreamer1-plugins 1.2.1 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229800/gstreamer1-plugins-1.2.1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229801/gstreamer1-plugins-1.2.1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229802/gstreamer1-plugins-1.2.1.log Buildgroup: 9.2-QAT/i386 Buildstatus: DEPEND (MANPAGE IN MISC/HELP2MAN) Log: https://qat.redports.org//~k...@freebsd.org/20131121190801-56953-229803/help2man-1.43.3.log - Port:multimedia/gstreamer1-plugins-all 1.0
Re: lang/gcc46 leaving directories around (WAS: [QAT] r334234: 3x leftovers, 1x depend_object)
On Fri, Nov 22, 2013 at 11:05:04PM +0100, Gerald Pfeifer wrote: On Fri, 22 Nov 2013, David Naylor wrote: The following reports indicate that /usr/local/share/info/gcc46 (directory) is being left in the working environment and not properly cleaned up. Since the ports do not create or use anything in that directory I assume this is an issue with the lang/gcc46 port. This is _not_ an issue with lang/gcc46, but with the general ports infrastructure that I first reported on October 23rd. Bapt had a first patch a week ago http://people.freebsd.org/~bapt/info-dir.diff This indeed removed the stray info/ directory, but caused the following upon `make deinstall` in my testing: /scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file or directory) and could not create (No such file or directory) /scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file or directory) and could not create (No such file or directory) : I just committed a workaround to lang/gcc46, will work on lang/gcc next, and filed PR ports/184178 to track this on the infrastructure side. Gerald This should be a definitive fix: http://people.freebsd.org/~bapt/fix-info-subdir.diff Sorry about it. Btw that have shown a bug in pkg 1.2.0 rc1 and prior (not in 1.1.x) I have fix in master and will be in 1.2.0 rc2 Can you test? regards, Bapt pgprgXXRB8Ewq.pgp Description: PGP signature
[QAT] r334619: 1x leftovers, 3x success
Work around ports infrastructure breakage introduced with staging and remove info/gcc46 ourselves. Reported by:QAT, amdmi3, mandree, bf, dbn PR: 184178 - Build ID: 2013110400-1181 Job owner: ger...@freebsd.org Buildtime: 2 hours Enddate: Sat, 23 Nov 2013 00:19:05 GMT Revision: r334619 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334619 - Port:lang/gcc46 4.6.4_1,1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~ger...@freebsd.org/2013110400-1181-230452/gcc-4.6.4_1,1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~ger...@freebsd.org/2013110400-1181-230453/gcc-4.6.4_1,1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~ger...@freebsd.org/2013110400-1181-230454/gcc-4.6.4_1,1.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~ger...@freebsd.org/2013110400-1181-230455/gcc-4.6.4_1,1.log -- Buildarchive URL: https://qat.redports.org/buildarchive/2013110400-1181 redports https://qat.redports.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: [QAT] r334619: 1x leftovers, 3x success
Okay, now I am confused. How can my workaround work for three quadrants
of {8.4,9.2} x {amd64,i386} and fail for just one combination?
Gerald
On Sat, 23 Nov 2013, Ports-QAT wrote:
Work around ports infrastructure breakage introduced with staging and
remove info/gcc46 ourselves.
Reported by: QAT, amdmi3, mandree, bf, dbn
PR: 184178
-
Build ID: 2013110400-1181
Job owner: ger...@freebsd.org
Buildtime: 2 hours
Enddate: Sat, 23 Nov 2013 00:19:05 GMT
Revision: r334619
Repository:
https://svnweb.freebsd.org/ports?view=revisionrevision=334619
-
Port:lang/gcc46 4.6.4_1,1
Buildgroup: 8.4-QAT/amd64
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~ger...@freebsd.org/2013110400-1181-230452/gcc-4.6.4_1,1.log
Buildgroup: 8.4-QAT/i386
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~ger...@freebsd.org/2013110400-1181-230453/gcc-4.6.4_1,1.log
Buildgroup: 9.2-QAT/amd64
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~ger...@freebsd.org/2013110400-1181-230454/gcc-4.6.4_1,1.log
Buildgroup: 9.2-QAT/i386
Buildstatus: LEFTOVERS
Log:
https://qat.redports.org//~ger...@freebsd.org/2013110400-1181-230455/gcc-4.6.4_1,1.log
--
Buildarchive URL: https://qat.redports.org/buildarchive/2013110400-1181
redports https://qat.redports.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: [QAT] r334619: 1x leftovers, 3x success
On Sat, Nov 23, 2013 at 01:26:58AM +0100, Gerald Pfeifer wrote:
Okay, now I am confused. How can my workaround work for three quadrants
of {8.4,9.2} x {amd64,i386} and fail for just one combination?
Probably one of the ports tree which is not up to date
regards,
Bapt
pgpicFeLYx9Jp.pgp
Description: PGP signature
[QAT] r334607: 1x leftovers, 11x success
Use a versioned name for metis4, to help some tools to distinguish it from metis - Build ID: 20131122192601-27942 Job owner: b...@freebsd.org Buildtime: 6 hours Enddate: Sat, 23 Nov 2013 01:25:19 GMT Revision: r334607 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334607 - Port:math/metis 5.1.0 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20131122192601-27942-230404/metis-5.1.0.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20131122192601-27942-230405/metis-5.1.0.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20131122192601-27942-230406/metis-5.1.0.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20131122192601-27942-230407/metis-5.1.0.log - Port:math/metis-edf 4.1.2_4 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20131122192601-27942-230408/metis-edf-4.1.2_4.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20131122192601-27942-230409/metis-edf-4.1.2_4.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20131122192601-27942-230410/metis-edf-4.1.2_4.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~b...@freebsd.org/20131122192601-27942-230411/metis-edf-4.1.2_4.log - Port:math/metis4 4.0.3_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20131122192601-27942-230412/metis4-4.0.3_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20131122192601-27942-230413/metis4-4.0.3_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20131122192601-27942-230414/metis4-4.0.3_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20131122192601-27942-230415/metis4-4.0.3_1.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131122192601-27942 redports https://qat.redports.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
problem with clamav
FreeBSD .rootbsd.net 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r258260M: Sun Nov 17 13:01:19 EST 2013 rootbsd.net:/usr/obj/usr/src/sys/GENERIC amd64 # portupgrade -va --- Session started at: Fri, 22 Nov 2013 20:46:56 -0500 [Reading data from pkg(8) ... - 81 packages found - done] ** Port marked as IGNORE: security/clamav: Unknown version of GCC specified (USE_GCC=any) --- Listing the results (+:done / -:ignored / *:skipped / !:failed) - security/clamav (marked as IGNORE) --- Packages processed: 0 done, 1 ignored, 0 skipped and 0 failed --- Session ended at: Fri, 22 Nov 2013 20:47:00 -0500 (consumed 00:00:03) # pkg info |grep gcc gcc-4.6.4 GNU Compiler Collection 4.6 gcc-ecj-4.5Eclipse Java Compiler used to build GCC Java # pkg info |grep clam clamav-0.98_2 Command line virus scanner written entirely in C Is clamav broken on current? Any suggestions on how to proceed? Thanks in advance. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: lang/gcc46 leaving directories around (WAS: [QAT] r334234: 3x leftovers, 1x depend_object)
On Sat, 23 Nov 2013, Baptiste Daroussin wrote: This should be a definitive fix: http://people.freebsd.org/~bapt/fix-info-subdir.diff : Btw that have shown a bug in pkg 1.2.0 rc1 and prior (not in 1.1.x) I have fix in master and will be in 1.2.0 rc2 Can you test? Yes. I just tested this, and in my environment it seems to work (passing the tests described in the Handbook). ports/184178 when you commit this. :) Thanks, Gerald ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: problem with clamav
On Fri, Nov 22, 2013 at 8:57 PM, AN a...@neu.net wrote: FreeBSD .rootbsd.net 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r258260M: Sun Nov 17 13:01:19 EST 2013 rootbsd.net:/usr/obj/usr/src/sys/GENERIC amd64 # portupgrade -va --- Session started at: Fri, 22 Nov 2013 20:46:56 -0500 [Reading data from pkg(8) ... - 81 packages found - done] ** Port marked as IGNORE: security/clamav: Unknown version of GCC specified (USE_GCC=any) --- Listing the results (+:done / -:ignored / *:skipped / !:failed) - security/clamav (marked as IGNORE) --- Packages processed: 0 done, 1 ignored, 0 skipped and 0 failed --- Session ended at: Fri, 22 Nov 2013 20:47:00 -0500 (consumed 00:00:03) # pkg info |grep gcc gcc-4.6.4 GNU Compiler Collection 4.6 gcc-ecj-4.5Eclipse Java Compiler used to build GCC Java # pkg info |grep clam clamav-0.98_2 Command line virus scanner written entirely in C Is clamav broken on current? Any suggestions on how to proceed? Thanks in advance. The problem wouldn't be with ClamAV, but with the port entry. ClamAV currently doesn't build with clang on 11-CURRENT, but it does indeed work with gcc (I'm building manually from source checked out via git, and am using gcc/g++ 4.6.4 from ports). Maybe the port maintainer has some input. Thanks, Shawn ___ 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] r334603: 46x success, 1x leftovers, 1x depend (depend_package in devel/libgsf), 2x dud, 1x depend_package, 1x depend (depend_package in misc/shared-mime-info)
- Convert to USES=qmake (and other USES while I'm here) - Add state support - Convert LIB_DEPENDS to new style, adjust USE_QT4 components, etc. Approved by:portmgr (blanket approval) - Build ID: 20131122185001-52241 Job owner: m...@freebsd.org Buildtime: 8 hours Enddate: Sat, 23 Nov 2013 03:00:28 GMT Revision: r334603 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334603 - Port:deskutils/qorganizer 3.1_4 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230324/qorganizer-3.1_4.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230325/qorganizer-3.1_4.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230326/qorganizer-3.1_4.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230327/qorganizer-3.1_4.log - Port:deskutils/tuxcards 2.2.1_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230328/tuxcards-2.2.1_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230329/tuxcards-2.2.1_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230330/tuxcards-2.2.1_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230331/tuxcards-2.2.1_1.log - Port:devel/qgit 2.3_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230332/qgit-qt4-2.3_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230333/qgit-qt4-2.3_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230334/qgit-qt4-2.3_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230335/qgit-qt4-2.3_1.log - Port:devel/qprog 0.4_4 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230336/qprog-0.4_4.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230337/qprog-0.4_4.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230338/qprog-0.4_4.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230339/qprog-0.4_4.log - Port:games/kcheckers 0.8.1_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230340/kcheckers-0.8.1_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230341/kcheckers-0.8.1_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230342/kcheckers-0.8.1_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230343/kcheckers-0.8.1_1.log - Port:games/openpref 0.1.3_2 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230344/openpref-0.1.3_2.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20131122185001-52241-230345/openpref-0.1.3_2.log Buildgroup: 9.2-QAT/amd64
[QAT] r334630: 3x leftovers, 1x depend (configure_error in misc/help2man), 1x mtree, 7x success
- Fix and report heap overflow in floating point parsing issue in ruby Security: cc9043cf-7f7a-426e-b2cc-8d1980618113 - Build ID: 20131123031201-22732 Job owner: swi...@freebsd.org Buildtime: 33 minutes Enddate: Sat, 23 Nov 2013 03:44:54 GMT Revision: r334630 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334630 - Port:lang/ruby19 1.9.3.448,1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~swi...@freebsd.org/20131123031201-22732-230492/ruby-1.9.3.484,1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~swi...@freebsd.org/20131123031201-22732-230493/ruby-1.9.3.484,1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~swi...@freebsd.org/20131123031201-22732-230494/ruby-1.9.3.484,1.log Buildgroup: 9.2-QAT/i386 Buildstatus: DEPEND (CONFIGURE_ERROR IN MISC/HELP2MAN) Log: https://qat.redports.org//~swi...@freebsd.org/20131123031201-22732-230495/help2man-1.43.3_1.log - Port:lang/ruby20 2.0.0.195_1,1 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~swi...@freebsd.org/20131123031201-22732-230496/ruby20-2.0.0.353,1.log Buildgroup: 8.4-QAT/i386 Buildstatus: MTREE Log: https://qat.redports.org//~swi...@freebsd.org/20131123031201-22732-230497/ruby20-2.0.0.353,1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~swi...@freebsd.org/20131123031201-22732-230498/ruby20-2.0.0.353,1.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~swi...@freebsd.org/20131123031201-22732-230499/ruby20-2.0.0.353,1.log - Port:security/vuxml 1.1_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~swi...@freebsd.org/20131123031201-22732-230500/vuxml-1.1_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~swi...@freebsd.org/20131123031201-22732-230501/vuxml-1.1_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~swi...@freebsd.org/20131123031201-22732-230502/vuxml-1.1_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~swi...@freebsd.org/20131123031201-22732-230503/vuxml-1.1_1.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131123031201-22732 redports https://qat.redports.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: [QAT] r334619: 1x leftovers, 3x success
Am 23.11.2013 01:27 schrieb Gerald Pfeifer ger...@pfeifer.com:
Okay, now I am confused. How can my workaround work for three quadrants
of {8.4,9.2} x {amd64,i386} and fail for just one combination?
Gerald
On Sat, 23 Nov 2013, Ports-QAT wrote:
Work around ports infrastructure breakage introduced with staging and
remove info/gcc46 ourselves.
Reported by: QAT, amdmi3, mandree, bf, dbn
PR: 184178
-
Build ID: 2013110400-1181
Job owner: ger...@freebsd.org
Buildtime: 2 hours
Enddate: Sat, 23 Nov 2013 00:19:05 GMT
Revision: r334619
Repository:
https://svnweb.freebsd.org/ports?view=revisionrevision=334619
-
Port:lang/gcc46 4.6.4_1,1
Buildgroup: 8.4-QAT/amd64
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~ger...@freebsd.org/2013110400-1181-230452/gcc-4.6.4_1,1.log
Buildgroup: 8.4-QAT/i386
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~ger...@freebsd.org/2013110400-1181-230453/gcc-4.6.4_1,1.log
Buildgroup: 9.2-QAT/amd64
Buildstatus: SUCCESS
Log:
https://qat.redports.org//~ger...@freebsd.org/2013110400-1181-230454/gcc-4.6.4_1,1.log
Buildgroup: 9.2-QAT/i386
Buildstatus: LEFTOVERS
Log:
https://qat.redports.org//~ger...@freebsd.org/2013110400-1181-230455/gcc-4.6.4_1,1.log
--
Buildarchive URL:
https://qat.redports.org/buildarchive/2013110400-1181
redports https://qat.redports.org/
Hm definitely a good question. The job defines an exact revision as stated
on top of the mail and this is what the builder checks out and builds.
Revision: r334619
So no good idea at the moment.
___
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
