Re: Python 3.3 don't build
Le 21/05/2013 ? 08:54:37+0400, Ruslan Makhmatkhanov a écrit Hi, Albert Shih wrote on 19.05.2013 20:29: Hi all Just report the /usr/ports/lang/python33 don't build on FreeBSD 9.1-STABLE #3 r250807: Sun May 19 17:48:52 CEST 2013 all other ports are up2date. Here the output : Regards. I was only able to reproduce it once, but then the breakage is mystically disappeared. It was reported, that BSD pmake may be a culprit, so the port was just changed to use GNU make. Please update your ports tree and try again. I confirm everything work now. Thanks a lot Regards. JAS -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71 xmpp: j...@obspm.fr Heure local/Local time: mar 21 mai 2013 09:01:46 CEST ___ 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
TeXLive build error on poudriere (Was: [patch included] teTeX and TeXLive)
Hiroki Sato h...@freebsd.org wrote in 20130519.070840.2265196291393572686@allbsd.org: hr Christopher J. Ruwe c...@cruwe.de wrote hr in 20130518025801.0659b...@dijkstra.cruwe.de: hr hr cj I have included the patches, they are rather trivial, although, I hr cj think, dirty. I have also included a complete logfile of a failed hr cj build for tex-formats. hr hr Where is the log file? hr hr What I need to investigate here is a build+install log for hr print/texlive-base on your environment. Running texconfig rehash in hr pre-install just hides your error and makes another problem. I committed a fix in r318651. Please try it if you got a build error when using poudriere. -- Hiroki pgpmCTt3BkeDv.pgp Description: PGP 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: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9.20130507083303.pointyhat/mp3towav-bundle-0.4.1_2.log (May 9 08:20:25 UTC 2013) overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=mp3towav-bundle portname: audio/mpg123.el broken because: fails to fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=mpg123.el 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: databases/msql broken because: Broken on FreeBSD 9+ build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=msql portname: databases/sqlrelay broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=sqlrelay 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/libopensync-plugin-vformat-devel broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutilsportname=libopensync-plugin-vformat-devel portname: deskutils/msynctool-devel broken because: fails to build with recent libopensync build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutilsportname=msynctool-devel portname: deskutils/simpleagenda broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutilsportname=simpleagenda portname: devel/arm-rtems-gcc broken because: many issues; see https://www.rtems.org/bugzilla/show_bug.cgi?id=2099 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=arm-rtems-gcc portname: devel/arm-rtems-gdb broken because: many issues; see https://www.rtems.org/bugzilla/show_bug.cgi?id=2099 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=arm-rtems-gdb portname: devel/dsss broken because: does not build build errors: none. overview:
FreeBSD 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: accessibility/yasr broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=accessibilityportname=yasr portname: audio/gdam broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=gdam portname: audio/mp3towav-bundle broken because: fails to build build errors: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9.20130507083303.pointyhat/mp3towav-bundle-0.4.1_2.log (May 9 08:20:25 UTC 2013) overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=mp3towav-bundle portname: audio/mpg123.el broken because: fails to fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=mpg123.el portname: benchmarks/polygraph31 broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=benchmarksportname=polygraph31 portname: biology/dotter broken because: checksum mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=dotter portname: cad/salome-geom broken because: fails to build build errors: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9.20130507083303.pointyhat/salome-geom-5.1.4_6.log (May 9 08:24:06 UTC 2013) overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=salome-geom portname: cad/salome-med broken because: Fails to fetch build errors: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9.20130507083303.pointyhat/salome-med-5.1.4_6.log (May 9 07:48:05 UTC 2013) overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=salome-med portname: cad/salome-yacs broken because: fails to build build errors: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9.20130507083303.pointyhat/salome-yacs-5.1.4_4.log (May 9 09:36:23 UTC 2013) overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=salome-yacs 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/cxterm broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=cxterm 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: comms/hso-kmod broken because: does not build with USB2, please try comms/uhso-kmod instead build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=commsportname=hso-kmod
FreeBSD ports which are currently marked forbidden
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users about ports that are marked as forbidden in their Makefiles. Often, these ports are so marked due to security concerns, such as known exploits. An overview of each port, including errors seen on the build farm, is included below. portname: graphics/linux-tiff forbidden because: Vulnerable since 2004-10-13, http://portaudit.freebsd.org/8816bf3a-7929-11df-bcce-0018f3e2eb82.html build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=linux-tiff portname: security/sudosh3 forbidden because: Secunia Advisory SA38292, ISS X-Force sudosh-replay-bo (55903), replay() function buffer overflow. build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=securityportname=sudosh3 portname: x11-toolkits/linux-pango forbidden because: Vulnerable since 2009-05-13, http://portaudit.freebsd.org/4b172278-3f46-11de-becb-001cc0377035.html build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkitsportname=linux-pango ___ 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
Tcl/Tk default version is 8.6
Hello, just a short heads-up to inform you that as of r318663, the default version of Tcl/Tk used in the ports tree is 8.6. Best, -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpp3teESn_Me.pgp Description: PGP signature
Re: Python 3.3 don't build
On Tue, 21 May 2013 09:03:01 +0200 Albert Shih albert.s...@obspm.fr wrote: Le 21/05/2013 ? 08:54:37+0400, Ruslan Makhmatkhanov a écrit Hi, Albert Shih wrote on 19.05.2013 20:29: Hi all Just report the /usr/ports/lang/python33 don't build on FreeBSD 9.1-STABLE #3 r250807: Sun May 19 17:48:52 CEST 2013 all other ports are up2date. Here the output : Regards. I was only able to reproduce it once, but then the breakage is mystically disappeared. It was reported, that BSD pmake may be a culprit, so the port was just changed to use GNU make. Please update your ports tree and try again. I confirm everything work now. Thanks a lot Regards. JAS I had the same problem yesterday in a clean jail: cd /usr/ports/devel/python33 make install It stopped with lots of error messages, I was too tired to care and just ran make install once again and then it worked. (no update of ports tree or any other action in between). Worth investigating? -- 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
[QAT] r318679: 4x leftovers
Update to 0.96. Changes:http://search.cpan.org/dist/Imager/Changes - Build ID: 20130521114600-6515 Job owner: to...@freebsd.org Buildtime: 7 minutes Enddate: Tue, 21 May 2013 11:52:53 GMT Revision: r318679 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=318679 - Port:graphics/p5-Imager 0.96 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~to...@freebsd.org/20130521114600-6515-141228/p5-Imager-0.96.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~to...@freebsd.org/20130521114600-6515-141229/p5-Imager-0.96.log Buildgroup: 8.3-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~to...@freebsd.org/20130521114600-6515-141230/p5-Imager-0.96.log Buildgroup: 8.3-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~to...@freebsd.org/20130521114600-6515-141231/p5-Imager-0.96.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20130521114600-6515 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
Ports with duplicate LATEST_LINKs
Dear port maintainers, The following list includes ports maintained by you that have duplicate LATEST_LINK values. They should either be modified to use a unique LATEST_LINK or suppressed using NO_LATEST_LINK, to avoid overwriting each other in the packages/Latest directory. If your ports conflict with ports maintained by another person, please coordinate your efforts with them. Thanks, Erwin Annoying Reminder Guy III Lansing LATEST_LINK PORTNAME MAINTAINER == pear-phing devel/pear-phing m...@freebsd.org pear-phing devel/php5-phing po...@freebsd.org Total: 2 ports ___ 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 +-+ graphics/py-gd | 0.56| 0.58 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt If wish to stop receiving portscout reminders, please contact portsc...@portscout.freebsd.org Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: collectd-4.10.4_7
Hello, I'm testing your patch for libmodbus. Unfortunatelly there is many changes between 2.x and current 3.x version of libmodbus. So evene enabling modbus plugin to collectd4 there is problem with configure script. So this should be modified by collectd project - i.e. modbus_new_tcp which replaces modbus_init_tcp from previous libmodbus version. Currently I'll make a PR for new version of collectd4 port. I think I will finish in some days. Greetings, -- Krzysztof Stryjek UNIX administrator/Juniper Networks Specialist email: wtp (at) bsdserwis (dot) com http://www.linkedin.com/in/KrzysztofStryjek GPG fingerprint: 8BD7 40CE 8994 0BBE CE6C 91CD 1292 8959 DC61 0E76 In theory, there is no difference between theory and practice. In practice, there is. ___ 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: Can't build devel/qt4-corelib any more -- help?
known issue, set USE_GCC=any in the qt4-corelib Makefile and it will builds On May 20, 2013, at 9:54 AM, David Wolfskill da...@catwhisker.org wrote: On a system running: FreeBSD 9.1-STABLE #80 r250806: Sun May 19 04:54:21 PDT 2013 i386, I was performing my usual weekly update/refresh -- at this point, portmaster -ad --index. Other ports updated OK; other systems (including my laptop, which I update more frequently) were OK. First pass through, I saw the message: In file included from ../../include/QtCore/qatomic_arch.h:1, from ../../include/QtCore/../../src/corelib/thread/qbasicatomic .h:227, from ../../include/QtCore/qbasicatomic.h:1, from ../../include/QtCore/../../src/corelib/thread/qatomic.h:46 , from ../../include/QtCore/qatomic.h:1, from ../../include/QtCore/../../src/corelib/tools/qbytearray.h: 45, from ../../include/QtCore/qbytearray.h:1, from ../../include/QtCore/../../src/corelib/kernel/qobject.h:49 , from ../../include/QtCore/qobject.h:1, from ../../include/QtCore/../../src/corelib/thread/qthread.h:45 , from ../../include/QtCore/qthread.h:1, from ../../include/QtCore/private/../../../src/corelib/thread/q thread_p.h:58, from ../../include/QtCore/private/qthread_p.h:1, from global/qglobal.cpp:52: ../../include/QtCore/../../src/corelib/arch/qatomic_arch.h:96:4: error: #error Qt has not been ported to this architecture which I found a bit discouraging -- checking archives, there was a reason it looked a bit familiar. :-( However, as far as I can tell, I've been good about reviewing the ports/UPDATING instructions and using portmaster -r when that's mentioned. and the previous update was a week ago: FreeBSD 9.1-STABLE #79 r250556: Sun May 12 05:14:12 PDT 2013. On the off-chance that icu, pcre, or libffi had a missed update, I tried portmaster -r for each in turn, and proceeded OK up to qt4-corelib-4.8.4_1, which choked died -- e.g.: ... You have already accepted the terms of the license. rm -f endiantest.o rm -f *~ core *.core rm -f endiantest rm -f Makefile rm -f endiantest.o rm -f *~ core *.core rm -f endiantest rm -f Makefile cp: /common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/src/ 3rdparty/webkit/Source/WebKit/qt/qt_webkit_version.pri: No such file or directory ln: /common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/include/QtCore/qconfig.h: File exists ln: /common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/include/Qt/qconfig.h: File exists This target is using the GNU C++ compiler (/usr/local/share/qt4/mkspecs/freebsd-g++). ... [and things degrade further beyond this point] So I thoiught that maybe somehow the prior installation of qt4-corelib was interfering with the attempt, so after running portmaster --check-depends (after which yet another attempt to portmaster devel/qt4-corelib still failed), I ran pkg_delete -f qt4-corelib-4.8.4_1 and tried portmaster devel/qt4-corelib again .. which *still* failed. The log may be seen at http://www.catwhisker.org/~david/FreeBSD/qt4_log.txt. What do I need to do to get devel/qt4-corelib installed on this system? Thanks. (No need to Cc: me; I'm subscribed to ports@.) Peace, david -- David H. Wolfskillda...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. +-oOO--(_)--OOo-+ With best Regards, Martin Wilke (miwi_(at)_FreeBSD.org) Mess with the Best, Die like the Rest ___ 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
[CFT] Installing multiple Rubygem port versions from the same directory
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greetings,
A while back, I started working on ports for the vagrant
(http://www.vagrantup.com/) and veewee
(https://github.com/jedi4ever/veewee) tools. At the time, vagrant was
packaged as a Ruby gem with a variety of other gem dependencies. Some
of the dependencies were already in the ports tree, but they were the
wrong versions.
Gem dependency lists are often very specific regarding acceptable
versions, and the ports tree had a couple of examples of gems that were
duplicated so that different major versions could be used as
dependencies for other ports (e.g. devel/rubygem-json and
devel/rubygem-json146).
I have been working on a way to install any version of a gem from a
single ports tree directory, as well as install multiple simultaneous
versions of the same gem. I'd like to offer my patches for review,
comments and testing, and you can find them here:
http://people.freebsd.org/~glarkin/diffs/usr-ports-Mk-rubygem-versions.diff
http://people.freebsd.org/~glarkin/diffs/usr-ports-devel-rubygem-port-examples.diff
Both diffs were generated against r318392. The first one patches
Mk/bsd.ruby.mk and creates Mk/bsd.rubygem-versions.mk. The second one
patches devel/rubygem-childprocess and devel/rubygem-ffi to show how the
new multi-version support works.
One of the key features in bsd.rubygem-versions.mk is that it creates
additional version-specific targets like install-1.3.4,
clean-3.0.19, etc., based on the list of versions for each gem.
Here is the process for adding multi-version support to a gem port:
cd /usr/ports/devel/rubygem-foobar
mkdir -p files # Or svn mkdir files, if it doesn't exist
make gem-versions # Creates the version list helper files
#
# Fix *_DEPENDS in Makefile, if necessary (see below)
#
make install-0.0.6 clean-0.0.6
make install-1.4.5 clean-1.4.5
make install-0.9 clean-0.9
#
# etc...
Since each gem version may need a different dependency list, I added
version-specific *_DEPENDS support like so:
# Using the examples from above:
RUN_DEPENDS006+=
rubygem-quux123=1.2.3:${PORTSDIR}/devel/rubygem-quux:install-1.2.3 \
rubygem-bar0019=0.0.999:${PORTSDIR}/devel/rubygem-bar:install-0.0.19
#
RUN_DEPENDS09+=
rubygem-quux1210=1.2.3:${PORTSDIR}/devel/rubygem-quux:install-1.2.10 \
rubygem-quux1210=1.2.999:${PORTSDIR}/devel/rubygem-quux:install-1.2.10 \
rubygem-bar0019=0.0.999:${PORTSDIR}/devel/rubygem-bar:install-0.0.19
#
RUN_DEPENDS145+=
rubygem-quux23=2.3.999:${PORTSDIR}/devel/rubygem-quux:install-2.3.10 \
rubygem-bar0019=0.0.999:${PORTSDIR}/devel/rubygem-bar:install-0.0.19 \
rubygem-null222=1.0.3:${PORTSDIR}/devel/rubygem-null:install-2.2.2
In the first example, the quux gem must be at least version 1.2.3 and
that one is installed. If version 4.0.10 were available, that would be
acceptable as well. The bar gem version must be = 0.0.1 and 0.1 (cf:
http://docs.rubygems.org/read/chapter/16#page74). Since there is no
~ operator in our depends system yet, I'm manually approximating it
here by testing against and upper version of 0.0.999 and counting on the
port maintainer to call the proper install target for the dependency.
In the second example, quux has a slightly more complex version
requirement, namely =1.2.3, ~1.2. Any version of quux at least
1.2.3 and less than 1.3 is acceptable.
In the last example, the null gem must be at least version 1.0.3, but
there is no upper bound. The port maintainer has decided to install
version 2.2.2, which may or may not be the most recent one.
I look forward to your feedback,
Greg
- --
Greg Larkin
http://www.FreeBSD.org/ - The Power To Serve
http://www.sourcehosting.net/ - Ready. Set. Code.
http://twitter.com/cpucycle/ - Follow you, follow me
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlGbnW4ACgkQ0sRouByUApAJeACcDLLdzpNuGH4KYikgzB0+VW78
ekYAn3orS0K7MemO1RKYINUEs5G9fKcp
=nc9B
-END PGP SIGNATURE-
___
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] Installing multiple Rubygem port versions from the same directory
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/21/13 12:14 PM, Greg Larkin wrote:
Greetings,
A while back, I started working on ports for the vagrant
(http://www.vagrantup.com/) and veewee
(https://github.com/jedi4ever/veewee) tools. At the time, vagrant
was packaged as a Ruby gem with a variety of other gem
dependencies. Some of the dependencies were already in the ports
tree, but they were the wrong versions.
Gem dependency lists are often very specific regarding acceptable
versions, and the ports tree had a couple of examples of gems that
were duplicated so that different major versions could be used as
dependencies for other ports (e.g. devel/rubygem-json and
devel/rubygem-json146).
I have been working on a way to install any version of a gem from
a single ports tree directory, as well as install multiple
simultaneous versions of the same gem. I'd like to offer my
patches for review, comments and testing, and you can find them
here:
http://people.freebsd.org/~glarkin/diffs/usr-ports-Mk-rubygem-versions.diff
http://people.freebsd.org/~glarkin/diffs/usr-ports-devel-rubygem-port-examples.diff
Both diffs were generated against r318392. The first one patches
Mk/bsd.ruby.mk and creates Mk/bsd.rubygem-versions.mk. The second
one patches devel/rubygem-childprocess and devel/rubygem-ffi to
show how the new multi-version support works.
One of the key features in bsd.rubygem-versions.mk is that it
creates additional version-specific targets like install-1.3.4,
clean-3.0.19, etc., based on the list of versions for each gem.
Here is the process for adding multi-version support to a gem
port:
cd /usr/ports/devel/rubygem-foobar mkdir -p files # Or svn
mkdir files, if it doesn't exist make gem-versions # Creates the
version list helper files # # Fix *_DEPENDS in Makefile, if
necessary (see below) # make install-0.0.6 clean-0.0.6 make
install-1.4.5 clean-1.4.5 make install-0.9 clean-0.9 # # etc...
Since each gem version may need a different dependency list, I
added version-specific *_DEPENDS support like so:
# Using the examples from above: RUN_DEPENDS006+=
rubygem-quux123=1.2.3:${PORTSDIR}/devel/rubygem-quux:install-1.2.3
\
rubygem-bar0019=0.0.999:${PORTSDIR}/devel/rubygem-bar:install-0.0.19
#
RUN_DEPENDS09+=
rubygem-quux1210=1.2.3:${PORTSDIR}/devel/rubygem-quux:install-1.2.10
\
rubygem-quux1210=1.2.999:${PORTSDIR}/devel/rubygem-quux:install-1.2.10
\
rubygem-bar0019=0.0.999:${PORTSDIR}/devel/rubygem-bar:install-0.0.19
#
RUN_DEPENDS145+=
rubygem-quux23=2.3.999:${PORTSDIR}/devel/rubygem-quux:install-2.3.10
\
rubygem-bar0019=0.0.999:${PORTSDIR}/devel/rubygem-bar:install-0.0.19
\
rubygem-null222=1.0.3:${PORTSDIR}/devel/rubygem-null:install-2.2.2
In the first example, the quux gem must be at least version 1.2.3
and that one is installed. If version 4.0.10 were available, that
would be acceptable as well. The bar gem version must be = 0.0.1
and 0.1 (cf: http://docs.rubygems.org/read/chapter/16#page74).
Since there is no ~ operator in our depends system yet, I'm
manually approximating it here by testing against and upper version
of 0.0.999 and counting on the port maintainer to call the proper
install target for the dependency.
In the second example, quux has a slightly more complex version
requirement, namely =1.2.3, ~1.2. Any version of quux at
least 1.2.3 and less than 1.3 is acceptable.
In the last example, the null gem must be at least version 1.0.3,
but there is no upper bound. The port maintainer has decided to
install version 2.2.2, which may or may not be the most recent
one.
I look forward to your feedback, Greg
And I forgot a rather key command in the description above. It should
read:
cd /usr/ports/devel/rubygem-foobar
mkdir -p files # Or svn mkdir files, if it doesn't exist
make gem-versions # Creates the version list helper files
make makesum-all# Update the distinfo file with all versions
Regards,
Greg
- --
Greg Larkin
http://www.FreeBSD.org/ - The Power To Serve
http://www.sourcehosting.net/ - Ready. Set. Code.
http://twitter.com/cpucycle/ - Follow you, follow me
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlGbnm4ACgkQ0sRouByUApCetQCfRkLnluBzOzT51zPtQ7HuevGT
XXMAn2sETR7A7kKbbCu/+Jik2EYzcznG
=PzWW
-END PGP SIGNATURE-
___
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: Can't build devel/qt4-corelib any more -- help?
On Tue, May 21, 2013 at 10:53:14PM +0800, Martin Wilke wrote:
known issue, set USE_GCC=any in the qt4-corelib Makefile and it will builds
...
Thank you for that, but I still see a failure:
dwolf-bsd(9.1-S)[15] cd /usr/ports/
dwolf-bsd(9.1-S)[16] svn info
Path: .
Working Copy Root Path: /common/ports
URL: file:///volume/opensource/FreeBSD/svn-ports-mirror/head
Repository Root: file:///volume/opensource/FreeBSD/svn-ports-mirror
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 318654
Node Kind: directory
Schedule: normal
Last Changed Author: hrs
Last Changed Rev: 318654
Last Changed Date: 2013-05-21 01:02:48 -0700 (Tue, 21 May 2013)
dwolf-bsd(9.1-S)[17] svn diff devel/qt4-corelib/Makefile
Index: devel/qt4-corelib/Makefile
===
--- devel/qt4-corelib/Makefile (revision 318654)
+++ devel/qt4-corelib/Makefile (working copy)
@@ -13,6 +13,7 @@
LIB_DEPENDS= icui18n:${PORTSDIR}/devel/icu
USES= pkgconfig
+USE_GCC= any
USE_GNOME= _glib20
USE_QT4= qmake_build moc_build
QT_NONSTANDARD=yes
dwolf-bsd(9.1-S)[18]
New log is in http://www.catwhisker.org/~david/FreeBSD/qt4_GCC_any_log.txt.
Salient excerpt:
root@dwolf-bsd:/var/tmp # portmaster devel/qt4-corelib^M
0;portmaster: devel/qt4-corelib^G
=== Port directory: /usr/ports/devel/qt4-corelib
=== Gathering distinfo list for installed ports
=== Launching 'make checksum' for devel/qt4-corelib in background
=== No options to configure
=== Gathering dependency list for devel/qt4-corelib from ports
=== Initial dependency check complete for devel/qt4-corelib
0;portmaster: devel/qt4-corelib^G
...
You have already accepted the terms of the license.
rm -f endiantest.o
rm -f *~ core *.core
rm -f endiantest
rm -f Makefile
rm -f endiantest.o
rm -f *~ core *.core
rm -f endiantest
rm -f Makefile
cp:
/common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/src/3rdparty/webkit/Source/WebKit/qt/qt_webkit_version.pri:
No such file or directory
ln:
/common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/include/QtCore/qconfig.h:
File exists
ln:
/common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/include/Qt/qconfig.h:
File exists
This target is using the GNU C++ compiler
(/usr/local/share/qt4/mkspecs/freebsd-g++).
...
Finding project files. Please wait...
WARNING:
/common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/src/src.pro:13:
Unable to find file for inclusion tools/tools.pro
WARNING:
/common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/src/corelib/global/global.pri:39:
Unable to find file for inclusion ../../../tools/shared/symbian/epocroot.pri
WARNING:
/common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/projects.pro:46:
Unable to find file for inclusion doc/doc.pri
...
Reading
/common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/demos
WARNING:
/common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/src/src.pro:13:
Unable to find file for inclusion tools/tools.pro
WARNING:
/common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/src/corelib/global/global.pri:39:
Unable to find file for inclusion ../../../tools/shared/symbian/epocroot.pri
WARNING:
/common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/projects.pro:46:
Unable to find file for inclusion doc/doc.pri
211 projects found.
Creating makefiles. Please wait...
...
Qt is now configured for building. Just run 'make'.
Once everything is built, you must run 'make install'.
Qt will be installed into /usr/local
To reconfigure, run 'make confclean' and 'configure'.
/usr/bin/sed -i.bak -e
's|/usr/local/lib/qt4/pkgconfig|/usr/local/libdata/pkgconfig|g' -e
's|.*$(QMAKE).*||g'
/common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/src/corelib/Makefile
/usr/bin/sed -i.bak -E -e
's|-L.[^[:space:]]*qt-x11-opensource.[^[:space:]]*lib||g' -E -e
's|(.*location=).*moc|\1/usr/local/bin/moc-qt4|g' -E -e
's|(.*location=).*uic|\1/usr/local/bin/uic-qt4|g'
/common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/lib/pkgconfig/QtCore.pc
=== Building for qt4-corelib-4.8.4_2
...
/common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/bin/moc
-DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -D
QT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER
-DQT_USE_ICU -DHB_EXPORT=Q_CORE_EXPORT -DGNU_LIBICONV -DQT_NO_DEBUG
-DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2
-DQT_HAVE_SSE3 -DQT_HAVE_SSSE3 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE
-I/common/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../include
-I../../include/QtCore -I.rcc/release-shared -Iglobal
-I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4
-I.moc/release-shared -I/common/local/include/qt4
broken llvm-devel on HEAD - DISTVERSION= 3.4.r${SVN_REV}
Hi! current llvm-devel failed to build under FreeBSD 10-HEAD: llvm[2]: Compiling SemaStmt.cpp for Release build llvm[2]: Compiling Tools.cpp for Release build Tools.cpp: In member function 'virtual void clang::driver::tools::Clang::ConstructJob(clang::driver::Compilation, const clang::driver::JobAction, const clang::driver::InputInfo, const clang::driver::InputInfoList, const clang::driver::ArgList, const char*) const': Tools.cpp:2040: error: expected unqualified-id before numeric constant Tools.cpp:2064: error: lvalue required as left operand of assignment Tools.cpp:2068: error: lvalue required as left operand of assignment Tools.cpp:2086: error: lvalue required as left operand of assignment Tools.cpp:2088: error: lvalue required as left operand of assignment gmake[2]: *** [/usr/ports/lang/clang-devel/work/llvm-3.4.r181598/tools/clang/lib/Driver/Release/Tools.o] Error 1 gmake[2]: Leaving directory `/usr/ports/lang/clang-devel/work/llvm-3.4.r181598/tools/clang/lib/Driver' gmake[1]: *** [Driver/.makeall] Error 2 gmake[1]: *** Waiting for unfinished jobs llvm[2]: Compiling SemaStmtAsm.cpp for Release build llvm[2]: Compiling SemaStmtAttr.cpp for Release build llvm[2]: Compiling SemaTemplate.cpp for Release build llvm[2]: Compiling SemaTemplateDeduction.cpp for Release build ___ 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
[HEADSUP] flex/lex updated to 2.5.37 (from flex.sourceforge.net)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please note flex/lex was updated to 2.5.37 from flex.sourceforge.net and __FreeBSD_version was bumped to 133. FYI, I added couple of compatibility shims (just enough to build the previous source trees) but it is not 100% compatible with the old version. OTOH, this version is far more popular and third-party sources often require this version. Most importantly, NetBSD, DragonFly BSD, and Mac OS X already adopted it for the same reason. Cheers! Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRm9MgAAoJECXpabHZMqHOhZAH/i8lZJofJNGuUOzRGZSspbYY TWwsno5S4VJDDIljO8ORAnu0oXPAbVZ1366f7TTYi258sQ0xSoUDnOoibJXQRnTI 8JaXDf3U33rGVuGNBe2Ge78TzMS895z9B+lW9UPrV3IIg0OPgCoS+SE77jb24vP0 J9vqkJgUUOWVOX9VLIH3ZRIJeSQk0PyrXpaV8v/dlw2G15gbvSZ1n99CGnVL53uZ kbHq+4F6Sre+YL/+5ZFwQk81itGdhIDPYhk5eytt9nvB/LKp+AQyiJO/+pOSF/C/ +TU9QAQ4cecIevORczygFtBD3HR41LLF9YpCd3s2vvUJtrSJX+KN4b+4cZf3SrI= =bH9U -END PGP SIGNATURE- ___ 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: [HEADSUP] flex/lex updated to 2.5.37 (from flex.sourceforge.net)
On Tue, May 21, 2013 at 04:03:44PM -0400, Jung-uk Kim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please note flex/lex was updated to 2.5.37 from flex.sourceforge.net and __FreeBSD_version was bumped to 133. FYI, I added couple of compatibility shims (just enough to build the previous source trees) but it is not 100% compatible with the old version. OTOH, this version is far more popular and third-party sources often require this version. Most importantly, NetBSD, DragonFly BSD, and Mac OS X already adopted it for the same reason. Cheers! Jung-uk Kim Thank you for you work on this. One of the important addition this brings to us, is that along with byacc you can now write reentrant parsers in base system. regards, Bapt pgpItAa54G7M7.pgp Description: PGP signature
Re: Python 3.3 don't build
Am 21.05.2013 13:31, schrieb Michael Gmelin: I had the same problem yesterday in a clean jail: cd /usr/ports/devel/python33 make install It stopped with lots of error messages, I was too tired to care and just ran make install once again and then it worked. (no update of ports tree or any other action in between). That might hint to a missing dependency in the makefiles with parallel builds, or otherwise race conditions that jeopardize the build... however, if the switch to gmake fixes it, chances are that pmake pulls more environment in than gmake would; I've fixed such an issue before, in lang/lua. Such an issue might then be sensitive to /etc/make.conf contents (which would explain why it works for some). Worth investigating? If some can spend that time, that would certainly be most appreciated, just make sure to check with rm@ first ___ 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: [HEADSUP] flex/lex updated to 2.5.37 (from flex.sourceforge.net)
On 5/21/2013 22:03, Jung-uk Kim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please note flex/lex was updated to 2.5.37 from flex.sourceforge.net and __FreeBSD_version was bumped to 133. FYI, I added couple of compatibility shims (just enough to build the previous source trees) but it is not 100% compatible with the old version. OTOH, this version is far more popular and third-party sources often require this version. Most importantly, NetBSD, DragonFly BSD, and Mac OS X already adopted it for the same reason. Cheers! Jung-uk Kim Hi Jung-uk Kim, I brought flex 2.5.37 into DragonFly and yes, it caused quite a few ports to break. However, in many cases I added patches to dports to restore their building. The first place people should check when trying to fix breakage is dports in case that I already came up with a fix. Regards, John ___ 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: [HEADSUP] flex/lex updated to 2.5.37 (from flex.sourceforge.net)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-05-21 16:30:48 -0400, John Marino wrote: On 5/21/2013 22:03, Jung-uk Kim wrote: Please note flex/lex was updated to 2.5.37 from flex.sourceforge.net and __FreeBSD_version was bumped to 133. FYI, I added couple of compatibility shims (just enough to build the previous source trees) but it is not 100% compatible with the old version. OTOH, this version is far more popular and third-party sources often require this version. Most importantly, NetBSD, DragonFly BSD, and Mac OS X already adopted it for the same reason. Cheers! Jung-uk Kim Hi Jung-uk Kim, I brought flex 2.5.37 into DragonFly and yes, it caused quite a few ports to break. However, in many cases I added patches to dports to restore their building. The first place people should check when trying to fix breakage is dports in case that I already came up with a fix. Can you please explain the most common incompatibilities you experienced from dports? FYI, I have added these two shims for FreeBSD: http://svnweb.freebsd.org/changeset/base/250877 http://svnweb.freebsd.org/changeset/base/250878 With these two shims, I was able to build older FreeBSD source trees just fine. Without them, I needed patches like this: http://svnweb.freebsd.org/changeset/base/250227 Thanks! Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRm+GvAAoJECXpabHZMqHO4aYH/jG1EKLeYMYHWjsESOPibyrX ahmIX/uwlKAXHXvhsgRr7kMZqJ0FtjPaK7X1/w4QgFpSwRD6SCBrY2sNAjOvQEoy p+UIIbDd306tagAW3BYoRy+L4ZQXPl39fsZCLo0LGCA4FLCAFT0ss7DBXV55ZqqY kGyXghnXIlr+XGA2YV5ZJJP9mOjvBCHMM6mvNtPSkpnAv0GuL2SbtmJeEtNAuqKk VQWO6BR/C6BhSxLo3tVPSEkOd0CF5ePD5zDPfPLNRlviR41OOzuS4o+w1hr3lzHu 4HJM4UoujlwBAl9017aUwEy7GNhvmzu9T7Q1OrRaTboZRmpMJ+ItCg1QgvBm+zE= =KvCt -END PGP SIGNATURE- ___ 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: [HEADSUP] flex/lex updated to 2.5.37 (from flex.sourceforge.net)
On 5/21/2013 23:05, Jung-uk Kim wrote: Can you please explain the most common incompatibilities you experienced from dports? FYI, I have added these two shims for FreeBSD: http://svnweb.freebsd.org/changeset/base/250877 http://svnweb.freebsd.org/changeset/base/250878 With these two shims, I was able to build older FreeBSD source trees just fine. Without them, I needed patches like this: http://svnweb.freebsd.org/changeset/base/250227 Yes, we had serious circular dependency issues because M4 was updated at the same time, and they require each other to build. In the end, not only did we make the same sort of changes seen in your r250227, we also had to pregenerate one of the M4 source files to break the circular dependency. After that it was possible to built older trees with the new M4/Flex. But we didn't add the shims. You're going to find additional problems beyond those shims. Such as: - YY_PROTO no longer defined - yyleng data type redefined from int to size_t - yyget_leng now predefined - yylineno is now predefined - upstream patches needed for non-trivial fixes etc. John ___ 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: [HEADSUP] flex/lex updated to 2.5.37 (from flex.sourceforge.net)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-05-21 18:11:23 -0400, John Marino wrote: On 5/21/2013 23:05, Jung-uk Kim wrote: Can you please explain the most common incompatibilities you experienced from dports? FYI, I have added these two shims for FreeBSD: http://svnweb.freebsd.org/changeset/base/250877 http://svnweb.freebsd.org/changeset/base/250878 With these two shims, I was able to build older FreeBSD source trees just fine. Without them, I needed patches like this: http://svnweb.freebsd.org/changeset/base/250227 Yes, we had serious circular dependency issues because M4 was updated at the same time, and they require each other to build. In the end, not only did we make the same sort of changes seen in your r250227, we also had to pregenerate one of the M4 source files to break the circular dependency. After that it was possible to built older trees with the new M4/Flex. But we didn't add the shims. AFAICT, we don't have this problem. :-) You're going to find additional problems beyond those shims. Such as: - YY_PROTO no longer defined - yyleng data type redefined from int to size_t - yyget_leng now predefined - yylineno is now predefined - upstream patches needed for non-trivial fixes etc. Thanks for the pointers! Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRm/Z3AAoJECXpabHZMqHOYXQH/ip0El+o+MmX3rAnBhj4MPhg WUHJ4z8NRoBqC/oe+/m8fJH99Mt3dvByIu85Zfxsek/03F309do2+LI9yY7kurlH YKX4H/wLuZn6hnN3/wxxJ3J6vRNUcnG/w5WaDUqKauOZsKPuHR63EPz8E5K2mvSo sgVwS9x+aRnxDneSKWpmUOpW6wTqRtDQY6jXDueLN/Zkf325cahXth5BhMNYWJlj KZBsYxMfmn00qNMgWsjFkRzWvtdctG6wRu8ewvhzY3R78yLlRIbI9M2JYN6SNYns CR6uK7bVfAUsQ5iCHM8PIJOZbyBiHlppJk9kZEuY1dWN6OMR9sZ0hyxs2n/CncM= =vJn4 -END PGP SIGNATURE- ___ 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
notmuch-0.15.2 mutt integration
Howdy, I added an option for mutt integration to the notmuch port via notmuch-mutt. I've attached a tarball of all the modifications, but here is a list of modified files: Makefile pkg-plist files/patch-notmuch-mutt Here are some references for more information: notmuch-mutt: http://notmuchmail.org/notmuch-mutt/ simple integration: https://upsilon.cc/~zack/blog/posts/2011/01/how_to_use_Notmuch_with_Mutt/mutt-notmuch.1.html - Kyle notmuch-0.15.2.tar.gz Description: Binary data pgpdVOCBIIB2x.pgp Description: PGP signature
x11/kdelibs4 build fails
Is any one else having a problem[1] building kdelibs4 since the update to KDE 4.10.3? I'm seeing the same error on three different machines. Any clues how to fix? [1] http://mail.kde.org/pipermail/kde-freebsd/2013-May/015369.html -- Greg Rivers ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Firefox 21.0 Crash
In message 997344171-1369083778-cardhu_decombobulator_blackberry.rim.net-10 735 04366-@b17.c23.bise6.blackberry, Cy Schubert writes: Hi, I'm experiencing firefox crashes since updating to 21.0. It works properly fo llowing the restore of my ~/.mozilla directory however subsequently it crashe s on start-up or shortly thereafter. Googling firefox 21.0 crash brings up fo ur or five hits at the Mozilla support forums site, so this may need to be es calated to our upline (I'd open a PR but I'm away from my computer at the mom ent). Can our Gecko team bring this up with our upline? A couple of data points. I can reproduce this at will on two laptop computers . However, exporting DISPLAY on a server downstairs and running it from there works. Sometimes it will die due to an XCB error while other times it's due to multiple segfaults. I think this should be brought to the attention of our upline. Please cc me at cy.schub...@komquats.com (or c...@freebsd.org) as I don't norma lly use my Blackberry (gmail account) for FreeBSD related emails. Thanks. It appears building with clang-devel produces a stable firefox binary. It may yet prove me wrong and start causing me trouble later but at the moment this seems to be the fix. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: Firefox 21.0 Crash
In message 201305220036.r4m0aip4020...@slippy.cwsent.com, Cy Schubert writes: In message 997344171-1369083778-cardhu_decombobulator_blackberry.rim.net-10 735 04366-@b17.c23.bise6.blackberry, Cy Schubert writes: Hi, I'm experiencing firefox crashes since updating to 21.0. It works properly fo llowing the restore of my ~/.mozilla directory however subsequently it cras he s on start-up or shortly thereafter. Googling firefox 21.0 crash brings up fo ur or five hits at the Mozilla support forums site, so this may need to be es calated to our upline (I'd open a PR but I'm away from my computer at the m om ent). Can our Gecko team bring this up with our upline? A couple of data points. I can reproduce this at will on two laptop compute rs . However, exporting DISPLAY on a server downstairs and running it from the re works. Sometimes it will die due to an XCB error while other times it's du e to multiple segfaults. I think this should be brought to the attention of o ur upline. Please cc me at cy.schub...@komquats.com (or c...@freebsd.org) as I don't nor ma lly use my Blackberry (gmail account) for FreeBSD related emails. Thanks. It appears building with clang-devel produces a stable firefox binary. It may yet prove me wrong and start causing me trouble later but at the moment this seems to be the fix. I spoke to soon. After restarting it for the fourth time it's crashing again. I suspect it corrupts its chrome after a while. Need to dig a bit further when I get the time. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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-tex mailling list
Hi, JFYI, freebsd-tex mailing list[*] has been created for discussing TeX related ports. If you are interested in porting and/or have questions about TeX and its applications on FreeBSD, please subscribe it. [*] http://lists.freebsd.org/mailman/listinfo/freebsd-tex -- Hiroki pgpc7NvU7WAPK.pgp Description: PGP signature
Re: Plans for making MAKE_JOBS_SAFE the default?
Hi, Since we are back on normal rolling packages update for stable and I got pointyhat-west up to do some testing, I would like to move on with this case. I just wonder if someone already has a patch to make it as default, else I will have a look at it within this week. - Martin On Mar 15, 2013, at 9:18 AM, Martin Wilke miwi.free...@gmail.com wrote: I added Alexey here because he had asked for the same since few weeks ago. Yes we are able to do exp-runs now. But to be honest the ports tree is in general in bad stat, our priority for the moment is to fix the ports tree to get a good package set for the 8.4 release. After we are done with this we will definitely come back to this issue. I'd like to ask you once again to have a bit patience. We are doing our best to serve every request as much as possible. Also I'd like to remind you our back log is getting pretty long too. Thanks for your understanding. - Martin on behalf of portmgr +-oOO--(_)--OOo-+ With best Regards, Martin Wilke (miwi_(at)_FreeBSD.org) Mess with the Best, Die like the Rest On Mar 15, 2013, at 8:44 AM, Eitan Adler li...@eitanadler.com wrote: My proposal: - start an exp-run with FORCE_MAKE_JOBS set - mark all new failures with MAKE_JOBS_UNSAFE - flip the default right after the 9.1 release. Now that we seem to have exp-run support again it is time to re-raise this issue. Can we please have an exp-run, mark all the failures, and then flip the switch? This may have to be done recursively, but most of the major blockers have already been marked. -- 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 ___ 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 +-oOO--(_)--OOo-+ With best Regards, Martin Wilke (miwi_(at)_FreeBSD.org) Mess with the Best, Die like the Rest ___ 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
