[QAT] r325091: 4x leftovers
- update to 6.4.0 - remove patches for EOL FreeBSD releases - convert to OPTIONS Changelog: http://nmap.org/changelog.html - Build ID: 20130821045800-58976 Job owner: oha...@freebsd.org Buildtime: 83 minutes Enddate: Wed, 21 Aug 2013 06:20:44 GMT Revision: r325091 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=325091 - Port:security/nmap 6.40 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~oha...@freebsd.org/20130821045800-58976-171740/nmap-6.40.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~oha...@freebsd.org/20130821045800-58976-171741/nmap-6.40.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~oha...@freebsd.org/20130821045800-58976-171742/nmap-6.40.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~oha...@freebsd.org/20130821045800-58976-171743/nmap-6.40.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20130821045800-58976 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: building seamonkey with clang
On Tue, Aug 20, 2013 at 11:05:42PM +0200, Dimitry Andric wrote: On Aug 20, 2013, at 00:54, Cary c...@sdf.org wrote: Several attempts to build the current port of seamonkey on 9.1-release have all failed at the same point. I have rebuilt clang and have no idea what else can be done. Here is the error: Assertion failed: (isaArgument(Val) Unknown live-in to the entry block), function solveBlockValueNonLocal, file /usr/src/lib/clang/libllvmanalysis/../../ ../contrib/llvm/lib/Analysis/LazyValueInfo.cpp, line 605. This is clang 3.1, so meanwhile the assert will most likely have been fixed. Can you try building one of the lang/clang ports, and build the seamonkey port with that instead? -Dimitry Hello Dimitry, At the moment I am using clang-3.3_1 to build the seamonkey port. In three or four hours I will update. Cary -- c...@sdf.org SDF Public Access UNIX System - http://sdf.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
mail/mailman
Greetings, (Tom Judge copied as he owns some of the mailman PRs.) I have recently grabbed maintainership of mail/mailman after Petrik returned it to the pool just so that an important infrastructure port does not go unmaintained (think backup), but I only have an older Linux version of Mailman in production, not a FreeBSD version, and that is not going to change so soon. If there is someone who uses Mailman in production on FreeBSD and has the spare capacity to take on the mail/mailman port, please contact me, I'd be happy to hand over or share maintainership. Best Matthias signature.asc Description: OpenPGP digital signature
FreeBSD unmaintained ports which are currently marked broken
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/mp3towav-bundle broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=mp3towav-bundle portname: biology/dotter broken because: checksum mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=dotter portname: chinese/big5con broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=big5con portname: chinese/bitchx broken because: patch reject build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=bitchx portname: chinese/hztty broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=hztty portname: converters/p5-Unicode-Lite broken because: Overwrites bin/map from converters/p5-Unicode-Map build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=p5-Unicode-Lite portname: databases/grass broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=grass portname: databases/msql broken because: Broken on FreeBSD 9+ build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=msql portname: databases/ruby-interbase broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-interbase portname: deskutils/libopensync-plugin-python-devel broken because: fails to build with recent libopensync build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutilsportname=libopensync-plugin-python-devel portname: deskutils/simpleagenda broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutilsportname=simpleagenda portname: devel/dsss broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=dsss portname: devel/gnustep broken because: gnustep backend dependencies install files into the same place build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=gnustep portname: devel/libYGP broken because: Does not build with recent boost build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=libYGP portname: devel/lua50-dfui broken because: Does not build build errors: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.10.20130313090402.pointyhat/lua50-dfui-0.1.20050901.log (Mar 14 00:26:27 UTC 2013) overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=lua50-dfui portname:
FreeBSD unmaintained ports which are currently scheduled for deletion
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: databases/ruby-interbase description:Ruby interface to Firebird/Interbase library maintainer: po...@freebsd.org status: BROKEN deprecated because: Does not work with Ruby 1.9 expiration date:2013-05-02 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-interbase portname: devel/dsss description:D Shared Software System maintainer: po...@freebsd.org status: BROKEN deprecated because: Depends on expired lang/gdc expiration date:2013-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=dsss portname: devel/g2c description:Glade to C translator maintainer: po...@freebsd.org deprecated because: Not supported upstream anymore expiration date:2013-08-29 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=g2c portname: devel/ppl description:The Parma Polyhedra Library maintainer: po...@freebsd.org status: BROKEN deprecated because: obsolete version; fails to build expiration date:2013-09-21 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ppl portname: devel/rubygem-zoom description:A Ruby binding to the Z39.50 Object-Orientation Model (ZOOM) maintainer: po...@freebsd.org status: BROKEN deprecated because: Does not work with Ruby 1.9 expiration date:2013-05-02 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-zoom portname: games/koth description:Multiplayer tank artillery game similar to Scorched Earth maintainer: po...@freebsd.org deprecated because: Unmaintained expiration date:2013-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=gamesportname=koth portname: multimedia/linux-gspca-kmod description:A port of the linux gspcav1 webcam driver maintainer: po...@freebsd.org status: BROKEN deprecated because: Broken for more than 6 month expiration date:2013-08-27 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimediaportname=linux-gspca-kmod portname: net-im/jabber-pymsn description:Python MSN-Transport for Jabber maintainer: po...@freebsd.org deprecated because: Primary MSN Messenger service terminated 30 APR 2013 expiration date:2013-10-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=jabber-pymsn portname: net-im/p5-Net-MSN description:Net::MSN interface maintainer: po...@freebsd.org deprecated because: Primary MSN Messenger service terminated 30 APR 2013 expiration date:2013-10-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=p5-Net-MSN portname: net-im/py-msnp description:MSN messaging in Python maintainer: po...@freebsd.org deprecated because: Primary MSN Messenger service terminated 30 APR 2013 expiration date:2013-10-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=py-msnp portname: net-im/pymsn description:MSN Connection library maintainer: po...@freebsd.org deprecated because: Primary MSN Messenger service terminated 30 APR 2013 expiration date:2013-10-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=pymsn portname: net/gatekeeper description:GnuGK is GPL Gate Keeper for OhPhone, GnomeMeeting, NetMeeting, and H323 maintainer: po...@freebsd.org deprecated because: Vulnerable for than 2 month expiration date:2013-08-28 build errors: none. overview:
dansguardian poudriere and squid version
I am building www/dansguardian in poudriere, and it always builds
www/squid (squid-2.7.X) as a dependency, even though I have already
built www/squid33 (squid-3.3.x).
I guess it is related to the following Makefile line:
RUN_DEPENDS=${LOCALBASE}/sbin/squid:${PORTSDIR}/www/squid
So, on systems which already have www/squid33 installed, it sees
${LOCALBASE}/sbin/squid and does not build squid27. But in poudriere
there isn't ${LOCALBASE}/sbin/squid so it builds ${PORTSDIR}/www/squid.
I guess I could edit Makefile line like this:
RUN_DEPENDS=${LOCALBASE}/sbin/squid:${PORTSDIR}/www/squid33
to make it work, but it would be overwritten on next revision. Is it
possible to find a solution (e.g. by means of choosing squid version
in configure options) for official port Makefile? Or switch to latest
squid by default?
--
Marko Cupać
___
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: dansguardian poudriere and squid version
On 21/08/2013 09:45, Marko Cupać wrote:
I am building www/dansguardian in poudriere, and it always builds
www/squid (squid-2.7.X) as a dependency, even though I have already
built www/squid33 (squid-3.3.x).
I guess it is related to the following Makefile line:
RUN_DEPENDS=${LOCALBASE}/sbin/squid:${PORTSDIR}/www/squid
So, on systems which already have www/squid33 installed, it sees
${LOCALBASE}/sbin/squid and does not build squid27. But in poudriere
there isn't ${LOCALBASE}/sbin/squid so it builds ${PORTSDIR}/www/squid.
I guess I could edit Makefile line like this:
RUN_DEPENDS=${LOCALBASE}/sbin/squid:${PORTSDIR}/www/squid33
to make it work, but it would be overwritten on next revision. Is it
possible to find a solution (e.g. by means of choosing squid version
in configure options) for official port Makefile? Or switch to latest
squid by default?
This is one of a general class of problems we tend to run into with
compiled pkgs which is a deficiency compared to the way it works when
installing by compiling from ports.
A dependency line like:
RUN_DEPENDS=${LOCALBASE}/sbin/squid:${PORTSDIR}/www/squid
will be satisfied if any file ${LOCALBASE}/sbin/squid exists. The port
name only exists as a hint to the ports system about what to install if
that squid executable is not available.
With pre-compiled pkgs, dependencies are expressed as being on some
other specific package, and this relation is 'baked in' to the pkg.
Unless there is some means of substituting a different dependency
package via the ports system, as there is for eg. emacs or apache or
mysql, then you'ld have to jump through hoops to make pkg produce
packages that will let you mix squid33 with dansguardian.
Two possible approaches:
i) As you suggest, edit the dansguardian Makefile and customize
the RUN_DEPENDS line. Which is probably the easiest solution
overall, but it only applies if you've got your own poudriere setup
or equivalent, and you will have to maintain your own set of
patches to the ports tree
ii) Delete squid33, and install the dansguardian package allowing it to
pull in the other squid package as a dependency. Then use
'pkg set' to override the dependency relationship, and force a
reinstall to get the version of squid you require. (Untested,
but something like this:)
pkg delete squid33
pkg install dansguardian
pkg set -o www/squid:www/squid33
pkg install -Rf www/squid33
You can use a public repo and the default packages from it with
this strategy, but you will likely have to repeat this sort of
process whenever there are updates to packages in that dependency
sub-tree.
Ultimately we are intending to solve this sort of problem by switching
to a general 'REQUIRES / PROVIDES / CONFLICTS' set of dependency
variables[*], and importing a more sophisticated package solver. Work
on that is underway at the moment, but getting it into production is
going to involve some ... interesting ... changes in the ports tree, so
it's not going to happen for quite a while yet.
Cheers,
Matthew
[*] So the dansguardian port would say inter-alia something like:
REQUIRES+= executable:squid
and the various www/squid* ports would have
PROVIDES+= executable:squid
(except that probably won't need to be specified explicitly in the
port Makefile, as it can be inferred from the pkg-plist when a
squid port is installed. Oh, and the actual syntax for PRC
probably won't be anything like that at all)
___
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: building seamonkey with clang
On Wed, Aug 21, 2013 at 06:50:45AM +, Cary wrote: On Tue, Aug 20, 2013 at 11:05:42PM +0200, Dimitry Andric wrote: On Aug 20, 2013, at 00:54, Cary c...@sdf.org wrote: Several attempts to build the current port of seamonkey on 9.1-release have all failed at the same point. I have rebuilt clang and have no idea what else can be done. Here is the error: Assertion failed: (isaArgument(Val) Unknown live-in to the entry block), function solveBlockValueNonLocal, file /usr/src/lib/clang/libllvmanalysis/../../ ../contrib/llvm/lib/Analysis/LazyValueInfo.cpp, line 605. This is clang 3.1, so meanwhile the assert will most likely have been fixed. Can you try building one of the lang/clang ports, and build the seamonkey port with that instead? -Dimitry At the moment I am using clang-3.3_1 to build the seamonkey port. No, I wasn't. Sorry. Trying again. Cary -- c...@sdf.org SDF Public Access UNIX System - http://sdf.org -- c...@sdf.org SDF Public Access UNIX System - http://sdf.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/p5-UI-Dialog | 1.08| 1.09-2 +-+ 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: [patch]Uses/iconv.mk, devel/getext has no libiconv linkage.
On Sun, Aug 18, 2013 at 6:04 PM, Yamaya Takashi yama...@kbh.biglobe.ne.jp wrote: On 2013/08/06 07:54, Boris Samorodov wrote: (CC to the maintainer: gn...@freebsd.org) 05.08.2013 20:13, Yamaya Takashi пишет: Some ports, e.g. devel/glib20, cannot build because devel/gettext has no libiconv linkage. msgfmt cannot handle utf-8 and say invalid multibyte sequence. Patch attached file and rebuild devel/gettext, msgfmt works correctly. Confirmed. The fix works. Thanks! Please commit my patch. It is not only for devel/gettext. It's for some ports which have USES += iconv. This sounds like the underlying problem I have with print/cups-image, as well: It depends on iconv, but fails to add it to LDFLAGS when compiling. -- Daniel Nebdal ___ 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] r325107: 12x leftovers, 8x success
Update to 1.0.9. This is a bug fix release. Changelog: http://lists.freedesktop.org/archives/gstreamer-devel/2013-August/042360.html Enable neon http plugin Switch to new LIB_DEPEND format, use USES=gmake instead of USE_GMAKE Utilize new introspection USE_GNOME component. Allow gstreamer1-libav to play mp3's, note that mad plugin is still prefered if available. - Build ID: 20130821112600-45518 Job owner: k...@freebsd.org Buildtime: 104 minutes Enddate: Wed, 21 Aug 2013 13:10:22 GMT Revision: r325107 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=325107 - Port:multimedia/gstreamer1 1.0.9 Buildgroup: 9.1-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171804/gstreamer1-1.0.9.log Buildgroup: 9.1-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171805/gstreamer1-1.0.9.log Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171806/gstreamer1-1.0.9.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171807/gstreamer1-1.0.9.log - Port:multimedia/gstreamer1-libav 1.0.9 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171808/gstreamer1-libav-1.0.9.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171809/gstreamer1-libav-1.0.9.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171810/gstreamer1-libav-1.0.9.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171811/gstreamer1-libav-1.0.9.log - Port:multimedia/gstreamer1-plugins 1.0.9 Buildgroup: 9.1-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171812/gstreamer1-plugins-1.0.9.log Buildgroup: 9.1-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171813/gstreamer1-plugins-1.0.9.log Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171814/gstreamer1-plugins-1.0.9.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171815/gstreamer1-plugins-1.0.9.log - Port:multimedia/gstreamer1-plugins-bad 1.0.9 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171816/gstreamer1-plugins-bad-1.0.9.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171817/gstreamer1-plugins-bad-1.0.9.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171818/gstreamer1-plugins-bad-1.0.9.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171819/gstreamer1-plugins-bad-1.0.9.log - Port:www/gstreamer1-plugins-neon 1.0.9 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171820/gstreamer1-plugins-neon-1.0.9.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171821/gstreamer1-plugins-neon-1.0.9.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171822/gstreamer1-plugins-neon-1.0.9.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20130821112600-45518-171823/gstreamer1-plugins-neon-1.0.9.log -- Buildarchive URL:
Re: building seamonkey with clang
On Aug 21, 2013, at 13:23, Cary c...@sdf.org wrote: On Wed, Aug 21, 2013 at 06:50:45AM +, Cary wrote: On Tue, Aug 20, 2013 at 11:05:42PM +0200, Dimitry Andric wrote: On Aug 20, 2013, at 00:54, Cary c...@sdf.org wrote: Several attempts to build the current port of seamonkey on 9.1-release have all failed at the same point. I have rebuilt clang and have no idea what else can be done. Here is the error: Assertion failed: (isaArgument(Val) Unknown live-in to the entry block), function solveBlockValueNonLocal, file /usr/src/lib/clang/libllvmanalysis/../../ ../contrib/llvm/lib/Analysis/LazyValueInfo.cpp, line 605. This is clang 3.1, so meanwhile the assert will most likely have been fixed. Can you try building one of the lang/clang ports, and build the seamonkey port with that instead? -Dimitry At the moment I am using clang-3.3_1 to build the seamonkey port. No, I wasn't. Sorry. Trying again. Ok, I will assume a newer clang version will have this problem fixed. Please let us know whether it works for you now. However, out of interest, I would like to determine the exact upstream revision which fixed it. Could you please send me files that clang++ mentioned in your original post (if you still have them): clang++: note: diagnostic msg: /tmp/nsMsgMaildirStore-SbFLtj.ii clang++: note: diagnostic msg: /tmp/nsMsgMaildirStore-SbFLtj.sh I can use these to reproduce the problem locally, without having to duplicate your build environment, and compiling all the mozilla code. -Dimitry ___ 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: pkgng: How fix dependences?
sqlite base of packages /var/dp/pkg/local.sqlite SELECT id FROM packages where name='ImageMagick'; 7900 Query SELECT * FROM deps where package_id=7900; result contain both, gio-fam-backend and glib20 dependencies: devel/gio-fam-backend|gio-fam-backend|2.34.3|7900 devel/glib20|glib|2.36.3|7900 I think to make SQL query to remove the ALL dependencies from the table 'deps' for 'gio-fam-backend' 2013/8/21 Alex V. Petrov alexvpet...@gmail.com I tried to reinstall glib-2 and xorg-server xorg-drivers xorg xf86- but again: pkg check -d [skip] x11-drivers/xf86-input-keyboard has a missing dependency: devel/gio-fam-backend x11-drivers/xf86-input-mouse has a missing dependency: devel/gio-fam-backend x11-drivers/xf86-video-ati has a missing dependency: devel/gio-fam-backend x11-drivers/xf86-video-intel has a missing dependency: devel/gio-fam-backend x11-drivers/xf86-video-mach64 has a missing dependency: devel/gio-fam-backend x11-drivers/xf86-video-nv has a missing dependency: devel/gio-fam-backend x11-drivers/xf86-video-openchrome has a missing dependency: devel/gio-fam-backend x11-drivers/xf86-video-r128 has a missing dependency: devel/gio-fam-backend x11-drivers/xf86-video-radeonhd has a missing dependency: devel/gio-fam-backend x11-drivers/xf86-video-vesa has a missing dependency: devel/gio-fam-backend x11/xorg has a missing dependency: devel/gio-fam-backend x11-drivers/xorg-drivers has a missing dependency: devel/gio-fam-backend x11-servers/xorg-server has a missing dependency: devel/gio-fam-backend [skip] Missing package dependencies were detected. Found 6 issue(s) in total with your package database. pkg: No packages matching 'devel/gio-fam-backend' has been found in the repositories pkg: No packages matching 'java/diablo-jdk16' has been found in the repositories pkg: No packages matching 'lang/tcl-modules' has been found in the repositories pkg: No packages matching 'devel/libkgapi' has been found in the repositories pkg: No packages matching 'x11-toolkits/tk85-thread' has been found in the repositories pkg: No packages matching 'lang/tcl85-thread' has been found in the repositories Unable to find packages for installation. In instaled ports I have 2 glib: glib-1.2.10_13 Some useful routines of C programming (previous stable version) glib-2.36.3Some useful routines of C programming (current stable version) glib-1 need for some ports: pkg info -r glib-1.2.10_13 glib-1.2.10_13: dgs-0.5.9.1_11 gdk-pixbuf-0.22.0_12 GraphicsMagick-1.3.16_1 gtk-1.2.10_22 fpc-gtk1-2.6.2 fpc-fpgtk-2.6.2 fpc-imlib-2.6.2 fpc-gnome1-2.6.2 lazarus-1.0.8 fpc-units-2.6.2 Any ideas? 2013/8/21 Kevin Oberman rkober...@gmail.com On Tue, Aug 20, 2013 at 1:48 AM, Alex V. Petrov alexvpet...@gmail.comwrote: After recomendation (20130731) in ports/UPDATING I have: pkg check -d graphics/ImageMagick has a missing dependency: devel/gio-fam-backend devel/ORBit2 has a missing dependency: devel/gio-fam-backend ports-mgmt/packagekit has a missing dependency: devel/gio-fam-backend editors/spe has a missing dependency: devel/gio-fam-backend databases/akonadi has a missing dependency: devel/gio-fam-backend has a missing dependency: devel/gio-fam-backend [many skipped] I try: pkg set -a -o devel/gio-fam-backend:devel/glib20 -y Result: pkg: sqlite: columns package_id, origin are not unique (pkgdb.c:3605) How can I fix the dependence with portmaster or pkgng? -- - Alex V. Petrov It appears that you failed to follow the instructions in 20130731. Or, it is also possible that you used an outdated version of portmaster that did the wrong thing, too. I don't use pkgng, so it may have introduced other issues. Has glib20 been updated to glib-2.36.3? If so, it now has absorbed all of the functions of gio-fam-backend. and re-installing any ports that depended on gio-fam-backend should do the trick. portmaster graphics/ImageMagick devel/ORBit2 ports-mgmt/packagekit editors/spe databases/akonadi deskutils/alacarte and others that depend on gio-fam-backend. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com -- -- Alex V. Petrov -- -- Alex V. Petrov ___ 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] r325142: 4x leftovers
Add p5-CryptX, crypto toolkit. - Build ID: 20130821144600-57392 Job owner: vani...@freebsd.org Buildtime: 52 minutes Enddate: Wed, 21 Aug 2013 15:38:01 GMT Revision: r325142 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=325142 - Port:security/p5-CryptX 0.012 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~vani...@freebsd.org/20130821144600-57392-171956/p5-CryptX-0.012.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~vani...@freebsd.org/20130821144600-57392-171957/p5-CryptX-0.012.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~vani...@freebsd.org/20130821144600-57392-171958/p5-CryptX-0.012.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~vani...@freebsd.org/20130821144600-57392-171959/p5-CryptX-0.012.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20130821144600-57392 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: [patch]Uses/iconv.mk, devel/getext has no libiconv linkage.
On 2013/08/21 21:33, Daniel Nebdal wrote: On Sun, Aug 18, 2013 at 6:04 PM, Yamaya Takashi yama...@kbh.biglobe.ne.jp wrote: On 2013/08/06 07:54, Boris Samorodov wrote: (CC to the maintainer: gn...@freebsd.org) 05.08.2013 20:13, Yamaya Takashi пишет: Some ports, e.g. devel/glib20, cannot build because devel/gettext has no libiconv linkage. msgfmt cannot handle utf-8 and say invalid multibyte sequence. Patch attached file and rebuild devel/gettext, msgfmt works correctly. Confirmed. The fix works. Thanks! Please commit my patch. It is not only for devel/gettext. It's for some ports which have USES += iconv. This sounds like the underlying problem I have with print/cups-image, as well: It depends on iconv, but fails to add it to LDFLAGS when compiling. Now, no problem. Because base system's iconv was broken, but was repaired at r254080. Discard my patch. ___ 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: building seamonkey with clang
0. Program arguments: /usr/bin/clang++ -cc1 -triple i386-unknown-freebsd9.0 ... sr/local/include -fmodule-cache-path /var/tmp/clang-module-cache -O3 -Wall -Wpoi ... y/work/comm-release/mailnews/local/src/nsMsgMaildirStore.cpp You may be interested to know that source will compile with -O0 (instead of -O3). Dan ___ 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: building seamonkey with clang
On Wed, Aug 21, 2013 at 05:29:28PM +0200, Dimitry Andric wrote: On Aug 21, 2013, at 13:23, Cary c...@sdf.org wrote: On Wed, Aug 21, 2013 at 06:50:45AM +, Cary wrote: On Tue, Aug 20, 2013 at 11:05:42PM +0200, Dimitry Andric wrote: On Aug 20, 2013, at 00:54, Cary c...@sdf.org wrote: Several attempts to build the current port of seamonkey on 9.1-release have all failed at the same point. I have rebuilt clang and have no idea what else can be done. Here is the error: Assertion failed: (isaArgument(Val) Unknown live-in to the entry block), function solveBlockValueNonLocal, file /usr/src/lib/clang/libllvmanalysis/../../ ../contrib/llvm/lib/Analysis/LazyValueInfo.cpp, line 605. This is clang 3.1, so meanwhile the assert will most likely have been fixed. Can you try building one of the lang/clang ports, and build the seamonkey port with that instead? -Dimitry At the moment I am using clang-3.3_1 to build the seamonkey port. No, I wasn't. Sorry. Trying again. Ok, I will assume a newer clang version will have this problem fixed. Please let us know whether it works for you now. However, out of interest, I would like to determine the exact upstream revision which fixed it. Could you please send me files that clang++ mentioned in your original post (if you still have them): clang++: note: diagnostic msg: /tmp/nsMsgMaildirStore-SbFLtj.ii clang++: note: diagnostic msg: /tmp/nsMsgMaildirStore-SbFLtj.sh I can use these to reproduce the problem locally, without having to duplicate your build environment, and compiling all the mozilla code. -Dimitry Still building the port. The files you requested should be available here: http://filebin.ca/sJ7l6KWpOr3/tmp-2.20.tar.gz Thank you for your interest. -- c...@sdf.org SDF Public Access UNIX System - http://sdf.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
We are inviting sellers, buyers brokers to they can assess our know how for private e-trading / without risk.
For some translations, we use and recommend http://translate.google.com / for use the interactivity of the e-mail you must change the option format text towards HTML. If you are seller and want increase your sales placing its products around the world, as also if you are buyer and you want make private purchases in wholesalers markets of worldwide; We are brokers / traders and we are customizing our know how: (1) to operate and manage private negotiations by digital means removing any default risk between parties (seller, buyer broker/s) as also in turn (2) to each purchase / sale in wich we are part as bróker, via our systems of operating leverage we create and we develop their corresponding private market. For more info we invite to read our new proposal Aug-12-2013 (reading time - 5 min / PDF document hosted in the cloud Skydrive / language English Español) http://tiny.cc/V2saleCS If you are broker we appreciate your trust together we are adding best efforts for obtain our assured commissions; Much of our effectiveness depends on the group of people who every day we are adding best efforts, for effective results. Why sellers, buyers brokers choose us: we are innovative, we know how use and adapt new methods to create and develop global private markets; As our commissions / fees are always in exchange of each effective result, via our management customized specifically for each negotiation: always we will establish a secure perimeter, after and only within an secure perimeter without default risk between parties (seller, buyer broker/s) we will plan get each effective result. Basically via our know how, without operative cost (in advance) and only in exchange an commission by each effective result: a) seller has an easy and safe access to global markets, b) buyer has the most innovative and effective protection to make private purchases in wholesalers markets of worldwide and c) us the brokers, in exchange to each effective result we get our assured commissions; We are version 2 point 0 (zero) risk for private trading between: sellers, buyers brokers. Our challenge: for any type of product and/or service be able customize our systems, processes and methods to solely operate safe, fair dependable transactions. In global markets, with the interconnecting by digital means, without leaving your desk and with effective removal of any default risk: sellers, buyers brokers can be part of our transactions fair e-trade; We operate since the retailers transactions of household products such as: appliances, technology, clothing, so on / until wholesalers transactions of industrial products such as: capital goods and commodities (metals stones precious, fuels and derivatives, so on). We invite you to operate via our know how, together we build the future for the private negotiation. For that you can get an prompt response, please contact with this e-mail asjimagn...@hotmail.com / You can also follow us on social networks (last update Aug-12-2013), we thank you for your I LIKE (IL) IN OUR PUBLICATIONS: a) Facebook http://tiny.cc/Magnani_Jorge b) LinkedIN http://tiny.cc/linkedIN_JMagna In waiting for your positive reply, kind regards (As)sessor Jorge Magnani. ___ 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
sysutils/fusefs-ntfs fusefs_enable=YES
The README.FreeBSD file for sysutils/fusefs-ntfs and several howtos suggest adding the line: fusefs_enable=YES to rc.conf, but as far as I can see this doesn't affect anything since the port doesn't install an rc.d file. I would have expected such a file to load the fuse kernel module which I'm having to load myself. Has something fallen off here? Perhaps the README file should just recommend adding fuse_load=YES to loader.conf. ___ 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: sysutils/fusefs-ntfs fusefs_enable=YES
On 21/08/2013 23:39, RW wrote: The README.FreeBSD file for sysutils/fusefs-ntfs and several howtos suggest adding the line: fusefs_enable=YES to rc.conf, but as far as I can see this doesn't affect anything since the port doesn't install an rc.d file. I would have expected such a file to load the fuse kernel module which I'm having to load myself. The file is there. fusefs-kmod -- 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: sysutils/fusefs-ntfs fusefs_enable=YES
On Wed, 21 Aug 2013 23:44:41 +0200 Dominic Fandrey wrote: On 21/08/2013 23:39, RW wrote: The README.FreeBSD file for sysutils/fusefs-ntfs and several howtos suggest adding the line: fusefs_enable=YES to rc.conf, but as far as I can see this doesn't affect anything since the port doesn't install an rc.d file. I would have expected such a file to load the fuse kernel module which I'm having to load myself. The file is there. fusefs-kmod I see what's happened. Earlier in the year,against my better judgement, I move to CURRENT in futile attempt to make intel KMS work. It looks like fuse has been moved into the base system, but /etc/rc.d/ hasn't yet been updated to reflect that. ___ 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
Can't build p5-Encode-Detect
Hello. I'm deploying a fresh box and I'm stuck on the following. # cd /usr/ports/converters/p5-Encode-Detect # make === Fetching all distfiles required by p5-Encode-Detect-1.01 for building === Extracting for p5-Encode-Detect-1.01 = SHA256 Checksum OK for Encode-Detect-1.01.tar.gz. === Patching for p5-Encode-Detect-1.01 === p5-Encode-Detect-1.01 depends on package: p5-ExtUtils-CBuilder=0 - found === p5-Encode-Detect-1.01 depends on file: /usr/local/lib/perl5/site_perl/5.14/Module/Build.pm - found === p5-Encode-Detect-1.01 depends on file: /usr/local/bin/perl5.14.4 - found === Configuring for p5-Encode-Detect-1.01 Warning: ExtUtils::CBuilder not installed or no compiler detected Proceeding with configuration, but compilation may fail during Build Created MYMETA.yml and MYMETA.json Creating new 'Build' script for 'Encode-Detect' version '1.01' === Building for p5-Encode-Detect-1.01 Building Encode-Detect Error: no compiler detected to compile 'src/LangBulgarianModel.cpp'. Aborting *** Error code 45 Stop in /usr/ports/converters/p5-Encode-Detect. Of course p5-ExtUtils-CBuilder is there and it doesn't even give a warning when I build it. # pkg_info|grep p5-Ext p5-ExtUtils-CBuilder-0.2802.05,1 Compile and link C code for Perl modules # perl -v This is perl 5, version 14, subversion 4 (v5.14.4) built for amd64-freebsd ... # uname -a FreeBSD .x 8.3-RELEASE FreeBSD 8.3-RELEASE #0: Mon Apr 9 21:23:18 UTC 2012 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 I tried all the suggestions I could find on the web (including installing p5-IPC-Cmd and rebuilding), but none worked. Any help? bye Thanks av. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: building seamonkey with clang
On Wed, Aug 21, 2013 at 07:20:52PM +0200, Dan Lukes wrote: 0. Program arguments: /usr/bin/clang++ -cc1 -triple i386-unknown-freebsd9.0 ... sr/local/include -fmodule-cache-path /var/tmp/clang-module-cache -O3 -Wall -Wpoi ... y/work/comm-release/mailnews/local/src/nsMsgMaildirStore.cpp You may be interested to know that source will compile with -O0 (instead of -O3). Dan Hello Dan, In order to compile using optimiztion level -O0 instead of -O3 in what way could one change the port's configuration before running make? thanks, Cary -- c...@sdf.org SDF Public Access UNIX System - http://sdf.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: building seamonkey with clang
On Wed, Aug 21, 2013 at 05:29:28PM +0200, Dimitry Andric wrote: On Aug 21, 2013, at 13:23, Cary c...@sdf.org wrote: On Wed, Aug 21, 2013 at 06:50:45AM +, Cary wrote: On Tue, Aug 20, 2013 at 11:05:42PM +0200, Dimitry Andric wrote: On Aug 20, 2013, at 00:54, Cary c...@sdf.org wrote: Several attempts to build the current port of seamonkey on 9.1-release have all failed at the same point. I have rebuilt clang and have no idea what else can be done. Here is the error: Assertion failed: (isaArgument(Val) Unknown live-in to the entry block), function solveBlockValueNonLocal, file /usr/src/lib/clang/libllvmanalysis/../../ ../contrib/llvm/lib/Analysis/LazyValueInfo.cpp, line 605. This is clang 3.1, so meanwhile the assert will most likely have been fixed. Can you try building one of the lang/clang ports, and build the seamonkey port with that instead? -Dimitry At the moment I am using clang-3.3_1 to build the seamonkey port. No, I wasn't. Sorry. Trying again. Ok, I will assume a newer clang version will have this problem fixed. Please let us know whether it works for you now. -Dimitry A progress report using ps(1). root 78977 60.8 7.6 84620 57840 v1 R+5:53PM0:09.26 /usr/local/llvm33/bin/clang -cc1 -triple i386-portbld-freebsd9.1 -emit-obj -disable-free - root 37688 0.0 0.3 8032 2064 v1 I+4:26AM0:00.86 make CONFIG_DONE_SEAMONKEY=1 /usr/ports/www/seamonkey/work/.build_done.seamonkey._usr_loca root 38215 0.0 0.2 9808 1508 v1 I+4:32AM0:00.01 /bin/sh -ec (cd /usr/ports/www/seamonkey/work/comm-release/obj-i386-portbld-freebsd9.1; if root 38216 0.0 0.3 10452 2148 v1 I+4:32AM0:00.11 gmake -f /usr/ports/www/seamonkey/work/comm-release/client.mk -j1 build root 47856 0.0 0.2 10452 1668 v1 I+4:35AM0:00.08 gmake -C . root 47861 0.0 0.2 10452 1752 v1 I+4:35AM0:00.08 gmake -C mozilla default root 49266 0.0 0.2 10452 1744 v1 I+5:37AM0:00.07 gmake tier_platform root 58803 0.0 0.2 10452 1768 v1 I+6:21AM0:00.09 gmake libs_tier_platform root 78903 0.0 0.2 10452 1812 v1 I+5:52PM0:00.06 gmake -C toolkit libs root 78904 0.0 0.2 10452 1864 v1 S+5:52PM0:00.08 gmake -C components libs root 78973 0.0 0.2 10452 1820 v1 S+5:53PM0:00.06 gmake -C diskspacewatcher libs root 78974 0.0 0.2 9808 1576 v1 S+5:53PM0:00.01 /bin/sh /usr/local/bin/clang++33 -o DiskSpaceWatcher.o -c -fvisibility=hidden -DMOZ_GLUE_I root 78976 0.0 4.1 56172 31464 v1 S+5:53PM0:00.07 /usr/local/llvm33/bin/clang++ -o DiskSpaceWatcher.o -c -fvisibility=hidden -DMOZ_GLUE_IN_P cary 78979 0.0 0.2 9636 1436 0 S+5:53PM0:00.01 egrep seamonkey|gmake|clang Previous attempts to build exploded after approximately 12 hours. It seems to have made it a little farther this time. :-) Cary -- c...@sdf.org SDF Public Access UNIX System - http://sdf.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: Searching the port tree with portmaster?
Call it sport (search ports). :)
On 08/16/2013 02:33 AM, Torfinn Ingolfsen wrote:
On Fri, Aug 16, 2013 at 7:35 AM, Sergey V. Dyatko
sergey.dya...@gmail.com wrote:
2 aliases from my .cshrc:
alias search_namemake -C /usr/ports/ search name='\!*'
display=name,path,info
alias search_keymake -C /usr/ports/ search key='\!*'
display=name,path,info
search_[name|key] smthng
And a sh script solution, in case it is of use to someone:
tingo@kg-core1$ pinfo pinfo - find a given port in /usr/ports Use
with 'pinfo xxx', where xxx is the name of the port.
It looks like this:
tingo@kg-core1$ more `which pinfo` #!/bin/sh # @(#)port 1.0
10-nov-2001 T. Ingolfsen / KG4, Norway # # Just a quick hack to
get any easier way to search for ports # NAME=`basename ${0}`
PORTNAME=${1} PORTSDIR=/usr/ports
if [ $1 = ]; then echo ${NAME} - find a given port in
/usr/ports echo Use with '${NAME} xxx', where xxx is the name
of the port. else if [ ! -d ${PORTSDIR} ]; then echo ERROR:
${PORTSDIR} doesn't exist! exit 0 fi cd ${PORTSDIR} make search
name=${PORTNAME} fi (yes, it was originally called port, but at
some point in time it conflicted with a port I installed, thus I
renamed it pinfo) HTH
___
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: Searching the port tree with portmaster?
On Thu, Aug 15, 2013 at 12:44:43AM -0600, LuKreme wrote: Am I missing a search feature in postmaster? If not, how are people finding where a port is to install it (I had a heck of a time finding sudo, for example) I've been using ports-mgmt/pkgsearch for years. You can do regexy searches and get pkg-descr output easily with it, e.g.: $ pkgsearch -d ^sudo$ /usr/ports/security/sudo DESC: This is the CU version of sudo. Sudo is a program designed to allow a sysadmin to give limited root privileges to users and log root activity. The basic philosophy is to give as few privileges as possible but still allow people to get their work done. WWW: http://www.courtesan.com/sudo/ This is also relevant: $ pkgsearch -h usage: pkgsearch [-u][-h][-v][-dis] packname... u update the database d get the description of the package s get the size of the package *not work with -i* i search in packages installeds h show this v show the version The formatting of output from both examples is slightly modified for inclusion in this email. I should probably start picking through ports-mgmt again to see if I can find something that I like as much as pkgsearch in general, but also offers the ability to get port names and paths based on terms found in pkg-descr information. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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: building seamonkey with clang
On Thu, Aug 22, 2013 at 01:16:33AM +, Cary wrote: On Wed, Aug 21, 2013 at 05:29:28PM +0200, Dimitry Andric wrote: On Aug 21, 2013, at 13:23, Cary c...@sdf.org wrote: On Wed, Aug 21, 2013 at 06:50:45AM +, Cary wrote: On Tue, Aug 20, 2013 at 11:05:42PM +0200, Dimitry Andric wrote: On Aug 20, 2013, at 00:54, Cary c...@sdf.org wrote: Several attempts to build the current port of seamonkey on 9.1-release have all failed at the same point. I have rebuilt clang and have no idea what else can be done. Here is the error: Assertion failed: (isaArgument(Val) Unknown live-in to the entry block), function solveBlockValueNonLocal, file /usr/src/lib/clang/libllvmanalysis/../../ ../contrib/llvm/lib/Analysis/LazyValueInfo.cpp, line 605. This is clang 3.1, so meanwhile the assert will most likely have been fixed. Can you try building one of the lang/clang ports, and build the seamonkey port with that instead? -Dimitry At the moment I am using clang-3.3_1 to build the seamonkey port. No, I wasn't. Sorry. Trying again. Ok, I will assume a newer clang version will have this problem fixed. Please let us know whether it works for you now. -Dimitry Previous attempts to build exploded after approximately 12 hours. It seems to have made it a little farther this time. :-) Cary Very nice. The build was successful. The application performs as expected. My previous installation of 2.17 was from a package. The new version seemed to start faster. A relevant bug report was filed last month. http://www.freebsd.org/cgi/query-pr.cgi?pr=180679 Cary -- c...@sdf.org SDF Public Access UNIX System - http://sdf.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
