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/teamspeak_client broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=teamspeak_client 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/hztty broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=hztty portname: databases/adstudio broken because: incomplete plist build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=adstudio 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/xapian-bindings10 broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=xapian-bindings10 portname: deskutils/abacus broken because: crashes on start build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutilsportname=abacus 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/fnccheck broken because: does not link build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.9.20121011194400/fnccheck-3.2.0.log (_Oct_21_00:37:47_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=fnccheck portname: devel/gauche-gaunit broken because: does not package build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=gauche-gaunit portname: devel/gcvs broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=gcvs portname: devel/linux-js broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=linux-js portname: devel/linuxthreads broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=linuxthreads portname: devel/lua-posix broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=lua-posix portname: devel/lua50-posix
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/hydrogen broken because: does not install build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=hydrogen portname: audio/sphinx3 broken because: does not compile build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.7.20121001063541/sphinx3-0.7.log (_Sep_25_17:40:18_UTC_2012) http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.8.20120903060906/sphinx3-0.7.log (_Sep_10_18:56:45_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=sphinx3 portname: audio/teamspeak_client broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=teamspeak_client portname: benchmarks/polygraph31 broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=benchmarksportname=polygraph31 portname: cad/brlcad broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=brlcad portname: cad/meshlab broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.10.20120628171716/meshlab-1.2.3_2.log (_Jul_16_09:33:26_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=meshlab portname: cad/salome-gui broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=salome-gui 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/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 portname: comms/ib-kmod broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=commsportname=ib-kmod portname: comms/uticom broken because: does not compile build errors: none. overview:
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: archivers/bsdar description:BSD-licensed replacement of the ar utility maintainer: po...@freebsd.org status: IGNORE deprecated because: part of the base system expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=bsdar portname: astro/position description:GPS and Moving-Map Applikation maintainer: po...@freebsd.org deprecated because: No more public distfiles expiration date:2012-11-26 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=astroportname=position portname: astro/tangogps description:A comprehencive GPS mapping application maintainer: po...@freebsd.org deprecated because: No more public distfiles expiration date:2012-11-26 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=astroportname=tangogps portname: audio/id3ren description:Mpeg Audio Layer 3 util: rename files, edit tags, search, etc maintainer: po...@freebsd.org deprecated because: No more public distfiles expiration date:2012-11-26 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=id3ren portname: audio/linux-alsa-lib description:The Advanced Linux Sound Architecture libraries maintainer: po...@freebsd.org deprecated because: expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=linux-alsa-lib portname: audio/linux-arts description:Audio system for the KDE integrated X11 desktop (Linux version) maintainer: po...@freebsd.org deprecated because: expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=linux-arts portname: audio/linux-freealut description:A free implementation of OpenAL's ALUT standard (Linux version) maintainer: po...@freebsd.org deprecated because: expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=linux-freealut portname: audio/linux-libmad description:Libmad library (part of MAD project) maintainer: po...@freebsd.org deprecated because: expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=linux-libmad portname: audio/linux-libogg description:Ogg bitstream library (Linux version) maintainer: po...@freebsd.org deprecated because: expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=linux-libogg portname: audio/linux-libvorbis description:Audio compression codec library (Linux version) maintainer: po...@freebsd.org deprecated because: expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=linux-libvorbis portname: audio/linux-openal description:A 3D positional spatialized sound library (Linux version) maintainer: po...@freebsd.org deprecated because: expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=linux-openal portname: audio/timidity description:MIDI to WAV renderer and player maintainer: po...@freebsd.org deprecated because: No more public distfiles expiration date:2012-12-29 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=timidity portname: audio/volumecontrol description:Audio mixer for GNUstep maintainer: po...@freebsd.org deprecated because: No more public distfiles expiration date:2012-11-26 build
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: lang/eperl forbidden because: Vulnerable since 2001-06-21, http://portaudit.freebsd.org/73efb1b7-07ec-11e2-a391-000c29033c32.html build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.7.20101015091133/eperl-2.2.14_3.log.bz2 (_Jul_31_06:17:35_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=langportname=eperl 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: shells/rssh forbidden because: http://www.vuxml.org/freebsd/65b25acc-e63b-11e1-b81c-001b77d09812.html (vulnerability) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=shellsportname=rssh portname: www/opera forbidden because: http://www.opera.com/support/kb/view/1030/ http://www.opera.com/support/kb/view/1031/ http://www.opera.com/support/kb/view/1033/ build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=opera 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
Steam, linux version
Hey guys. Steam is now in Beta for Ubuntu, they provide *.deb file. Do someone working on bringing it to FreeBSD with linux emulation? :) -- Regards, Alexander Yerenkow ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64): I accidentally sent message a second time
Finger slip, I sent a fairly long message on this subject by a finger error that I saw just one or two seconds later. Sorry! Tom ___ 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: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
from David Naylor naylor.b.da...@gmail.com:
Hi List,
# Executive Summary
Over the past years I have been maintaining the wine-fbsd64 port (see
http://mediafire.com/wine_fbsd64 for more). The port itself effectively does
static linking (it bundles all the libraries wine needs) with scripts to
bootstrap the environment to easily use wine from FreeBSD/amd64. There is
also a script to install the i386 nVidia graphic drivers so that wine has
access to nVidia accelerated graphics from FreeBSD/amd64.
I would like to propose this port gets included in the port's collection and
would like to get feedback, your comments please :-).
P.S. I'm not subscribed to the list, so please ensure I'm cc'ed in the
discussion.
# Details of the Port
Please see attached for the actual port.
## Port Preamble
This port is a slave port to emulators/wine(-devel). The master port needed
to be modified (already done):
- to conditionally set USE_LDCONFIG (if USE_LDCONFIG32 was not set)
- to allow the library directory to be changed (see WINELIBDIR)
- to allow configure arguments to be appended
## Port Targets
The port itself does the following in the preamble:
- specifies the pkg(de)install script to handle nVidia driver patching
- overrides ACTUAL-PACKAGE-DEPENDS (all depends are bundled with the port)
- defined the library directory to ${PREFIX}/lib32
- defined the binary directory to ${PREFIX}/bin32
- patches the PLIST to refer to lib32 (not lib)
- defined USE_LDCONFIG32 appropriately
The post-install-script target:
- Installs the files/binbounce file in ${PREFIX}/bin for each ${PREFIX}/bin32
file (hard linked)
- Finds all linked library, copies them to ${PREFIX}/lib32, and added them to
the plist
- Finds all dlopen'ed libraries, copies them to ${PREFIX}/lib32, and added
them to the plist
- Installs the nVidia patch file
- Run the (PRE-|POST-)INSTALL script
The post-package-script (run only if WITH_PKGNG is defined):
- Amends the package so the arch label to 64bit
## Port scripts (in files/)
The binbounce file does the following to transparently fix the environment to
allow seamless running of the wine programs:
- determines the location of the TARGET (follows symbolic links to itself)
- fixes LD_LIBRARY_PATH if in an i386 environment (so lib32, lib32/wine is
found)
- fixes LD_32_LIBRARY_PATH if in an amd64 environment (so lib32, lib32/wine,
/usr/lib32)
- fixes PATH (so bin32 is found)
- passes execution to the counterpart in bin32
The patch-nvidia.sh file does the following:
- Downloads the nVidia distfile for i386 (iff nVidia amd64 driver is
installed)
- Installs the required libraries into ${PREFIX}/lib32
- When run from the install script it does _not_ download the distfile, only
installs the libraries iff the distfiles are already downloaded.
# Shortcomings of the port
The following are shortcomings that I am aware of:
- Can only be compiled in an i386 environment, but the resulting package is
*intended* for amd64 (although works fine in an i386 environment)
- If, somehow, there is a recursive calling of wine programs then
LD_(32_)LIBRARY_PATH and PATH will continue to grow with every iteration.
- The pkgng ports cannot be installed in an i386 environment as they are
labelled for amd64.
# Testing
The ports published on mediafire have been tested by many users. The port
itself works flawlessly however there have been some reports about some flaws
in the 32-bit compatibility layer of the kernel (although I cannot remember
the specifics now).
To produce the package on an amd64 system do the following:
# (cd /usr/ports/emulators/; patch -p0 /path/to/diff)
# make -C /usr/src world DESTDIR=/i386 TARGET=i386
# mount -t devfs devfs /i386/dev
# mkdir /i386/usr/ports
# mount -t nullfs /usr/ports /i386/usr/ports
# chroot make -C /usr/ports/emulators/wine-fbsd64 package WITH_PKGNG=yes
The package wine-fbsd64-1.5.16,1.txz (in pkgng format) will be available from
/usr/ports/packages/All/
# Conclusion
It is based completely off the main port and uses the hack to,
effectively, use static linking (or bundling of libraries). In a
sense it is a complete, yet quite stable and encompassing, hack.
- David ;-)
It would be nice to have wine-fbsd64 as a port, but that might unfortunately
deprive the user of certain flexibility.
Also, nVidia support should be an option, since users with other graphics
cards might have no use for it.
I would really prefer to build the i386 FreeBSD system as a separate part,
including kernel,
since some users, myself included, might want to run an actual FreeBSD i386,
especially on an older computer. So one could build this FreeBSD i386 on a
USB stick or USB hard drive, and then be able to run wine on an i386 system.
Would wine-fbsd64 be a separate port, or would it be wine built on i386, as
the page http://wiki.freebsd.org/Wine suggests? It would be nice to be able
to run Wine
Re: graphics/opencv apparently broken, also out of date
Hallo Tom, ich werde meinen Maintainership für OpenCV fallen lassen. Wer will, kann es updaten - das Hauptproblem sind die abhängigen Ports, viele davon benötigen patches. MfG, Martin -- Martin Matuska FreeBSD committer http://blog.vx.sk Ich verstehe / I understand. Now I wonder what to do with massive ports update as I wait for OpenCV update. Find what ports depend on OpenCV and pigeonhole those for later? I was using gcc, not Clang. I was using all default options except for enabling xine support, whose default was off. Tom ___ 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
Santa Claus, what will bring you?
Do you know what is the glamorest Gift for next Christmas? It is Fashion to donate new creations made in Italy, high quality, hand made and very hard to find! Well, a unique and brilliant idea that transmits to the recipient, the refinement and the true value of the relationship that binds you. These objects dreamed, created and packaged by skilled artisans are a pleasant surprise and a treat for those who receive it! Check it out http://www.PIshopOnline.com to understand what is it . It's nice to know you can make a prestigious gift, unexpected and much appreciated to a special person. Best of luck Elisa Adamoli www.PIshopOnline.com T +39 0376 181 Skype (Elisa-Adamoli) ___ 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: New port cad/fritzing
I had not problems building, but when I run, I get error messages: Dialog: Sorry, we have a problem with the swapping mechanism. Fritzing still works, but you won't be able to change parts properties While loading bin: core parts, a dialog that says Unable to find the following 112 parts, and a list starting with '3234DBDC00PotnetionmetModuleId' at parts/core/basic_poti.fzp' When closing that window (The 'OK' button is unavailable, because it is way off the bottom of the screen), we get printed to the console: 7 times: QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::end: Painter not active, aborted about 42 times: libpng error: PNG file corrupted by ASCII conversion The program then opens, but, as there are no parts, I can't do much. On 7 November 2012 02:58, Sergio de Almeida Lenzi lenzi.ser...@gmail.comwrote: it is a PCB cad, now running on FreeBSD website=http://www.fritzing.org it is in the redports http://redports.org svn co https://svn.redports.org/sergiolenzi/fritzing Can I submit to the FreeBSD community??? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
First, I want to thank the Wine developers for a job/life/sanity saving
piece of code.
I need both 32 and 64 versions. It would be nice if the ports had a
wine-32 and wine-64 just to make
life simple for us non-intensive Ports users. Just a comment.
On 11/07/12 01:45, Thomas Mueller wrote:
from David Naylor naylor.b.da...@gmail.com:
Hi List,
# Executive Summary
Over the past years I have been maintaining the wine-fbsd64 port (see
http://mediafire.com/wine_fbsd64 for more). The port itself effectively does
static linking (it bundles all the libraries wine needs) with scripts to
bootstrap the environment to easily use wine from FreeBSD/amd64. There is
also a script to install the i386 nVidia graphic drivers so that wine has
access to nVidia accelerated graphics from FreeBSD/amd64.
I would like to propose this port gets included in the port's collection and
would like to get feedback, your comments please :-).
P.S. I'm not subscribed to the list, so please ensure I'm cc'ed in the
discussion.
# Details of the Port
Please see attached for the actual port.
## Port Preamble
This port is a slave port to emulators/wine(-devel). The master port needed
to be modified (already done):
- to conditionally set USE_LDCONFIG (if USE_LDCONFIG32 was not set)
- to allow the library directory to be changed (see WINELIBDIR)
- to allow configure arguments to be appended
## Port Targets
The port itself does the following in the preamble:
- specifies the pkg(de)install script to handle nVidia driver patching
- overrides ACTUAL-PACKAGE-DEPENDS (all depends are bundled with the port)
- defined the library directory to ${PREFIX}/lib32
- defined the binary directory to ${PREFIX}/bin32
- patches the PLIST to refer to lib32 (not lib)
- defined USE_LDCONFIG32 appropriately
The post-install-script target:
- Installs the files/binbounce file in ${PREFIX}/bin for each ${PREFIX}/bin32
file (hard linked)
- Finds all linked library, copies them to ${PREFIX}/lib32, and added them to
the plist
- Finds all dlopen'ed libraries, copies them to ${PREFIX}/lib32, and added
them to the plist
- Installs the nVidia patch file
- Run the (PRE-|POST-)INSTALL script
The post-package-script (run only if WITH_PKGNG is defined):
- Amends the package so the arch label to 64bit
## Port scripts (in files/)
The binbounce file does the following to transparently fix the environment to
allow seamless running of the wine programs:
- determines the location of the TARGET (follows symbolic links to itself)
- fixes LD_LIBRARY_PATH if in an i386 environment (so lib32, lib32/wine is
found)
- fixes LD_32_LIBRARY_PATH if in an amd64 environment (so lib32, lib32/wine,
/usr/lib32)
- fixes PATH (so bin32 is found)
- passes execution to the counterpart in bin32
The patch-nvidia.sh file does the following:
- Downloads the nVidia distfile for i386 (iff nVidia amd64 driver is
installed)
- Installs the required libraries into ${PREFIX}/lib32
- When run from the install script it does _not_ download the distfile, only
installs the libraries iff the distfiles are already downloaded.
# Shortcomings of the port
The following are shortcomings that I am aware of:
- Can only be compiled in an i386 environment, but the resulting package is
*intended* for amd64 (although works fine in an i386 environment)
- If, somehow, there is a recursive calling of wine programs then
LD_(32_)LIBRARY_PATH and PATH will continue to grow with every iteration.
- The pkgng ports cannot be installed in an i386 environment as they are
labelled for amd64.
# Testing
The ports published on mediafire have been tested by many users. The port
itself works flawlessly however there have been some reports about some flaws
in the 32-bit compatibility layer of the kernel (although I cannot remember
the specifics now).
To produce the package on an amd64 system do the following:
# (cd /usr/ports/emulators/; patch -p0 /path/to/diff)
# make -C /usr/src world DESTDIR=/i386 TARGET=i386
# mount -t devfs devfs /i386/dev
# mkdir /i386/usr/ports
# mount -t nullfs /usr/ports /i386/usr/ports
# chroot make -C /usr/ports/emulators/wine-fbsd64 package WITH_PKGNG=yes
The package wine-fbsd64-1.5.16,1.txz (in pkgng format) will be available from
/usr/ports/packages/All/
# Conclusion
It is based completely off the main port and uses the hack to,
effectively, use static linking (or bundling of libraries). In a
sense it is a complete, yet quite stable and encompassing, hack.
- David ;-)
It would be nice to have wine-fbsd64 as a port, but that might unfortunately
deprive the user of certain flexibility.
Also, nVidia support should be an option, since users with other graphics
cards might have no use for it.
I would really prefer to build the i386 FreeBSD system as a separate part,
including kernel,
since some users, myself included, might want to run an actual FreeBSD i386,
especially on an older computer. So one could build this FreeBSD i386 on a
USB stick or
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 +-+ deskutils/recoll| 1.17.3 | 1.18.1 +-+ devel/p5-Thread-Queue | 2.12| 3.01 +-+ ftp/yafc| 1.2.0 | 1.2.3 +-+ lang/nickle | 2.76| 2.77 +-+ security/py-tlslite | 0.4.0 | 0.4.3 +-+ www/xist| 3.25| 4.3.1 +-+ x11/xautomation | 1.03| 1.06 +-+ 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
lang/gcc46: .././../gcc-4.6-20121102/gcc/rtl.h:2105:31: error: use of undeclared identifier 'FIRST_PSEUDO_REGISTER', rtx x_initial_regno_reg_rtx[FIRST_PSEUDO_REGISTER];
On one of my FreeBSD 10-CURRENT boxes (FreeBSD 10.0-CURRENT #3 r242674M: Tue Nov 6 22:36:47 CET 2012) I get surprisingly the following error while upgrading the compiler port lang/gcc46. The bos in question is most recent updated kernel/world sources, compiled with CLANG and having CLANG set so far as the default compiler (clang is now cc). The port compiled prior to the switch to CLANG as the default also with CLANG without problem! The couriosity is that I also run two other boxes, also the very same sources for the OS and the most recent updated /usr/ports tree. Those boxes are modern hardware, Sandy-Bridge and Ivy-Bridge, the failing box is Core2Duo, I mention this here since I use -O3 and -march=native in the compiler options on ALL machines and I also compile the sources with option CXXFLAGS= -stdlib=libc++ -std=c++11 set in /etc/src.conf. The shwon below error sounds weird, since the other boxes have compiled the very same day the port lang/gcc has been updated the very same port without problems. Since I spread arounf the boxes my /etc/make.conf and /etc/src.conf for FreeBSD 10.0-CURRENT, I'm very sure that I do not use other flags on the failing system. Any ideas? Regards, Oliver = cc -c -O3 -pipe -fno-strict-aliasing -march=native -march=native -I/usr/local/include -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I.././../gcc-4.6-20121102/gcc -I.././../gcc-4.6-20121102/gcc/build -I.././../gcc-4.6-20121102/gcc/../include -I.././../gcc-4.6-20121102/gcc/../libcpp/include -I/usr/local/include -I.././../gcc-4.6-20121102/gcc/../libdecnumber -I.././../gcc-4.6-20121102/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include \ -o build/genflags.o .././../gcc-4.6-20121102/gcc/genflags.c In file included from .././../gcc-4.6-20121102/gcc/genflags.c:28: .././../gcc-4.6-20121102/gcc/rtl.h:1989:13: warning: ISO C forbids forward references to 'enum' types [-Wpedantic] extern enum reg_class reg_preferred_class (int); ^ .././../gcc-4.6-20121102/gcc/rtl.h:2105:31: error: use of undeclared identifier 'FIRST_PSEUDO_REGISTER' rtx x_initial_regno_reg_rtx[FIRST_PSEUDO_REGISTER]; ^ .././../gcc-4.6-20121102/gcc/rtl.h:2112:31: error: use of undeclared identifier 'FIRST_PSEUDO_REGISTER' rtx x_static_reg_base_value[FIRST_PSEUDO_REGISTER]; ^ 1 warning and 2 errors generated. gmake[2]: *** [build/genflags.o] Error 1 gmake[2]: Leaving directory `/usr/ports/lang/gcc46/work/build/gcc' gmake[1]: *** [all-gcc] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc46/work/build' gmake: *** [all] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/lang/gcc46. *** [build] Error code 1 Stop in /usr/ports/lang/gcc46. signature.asc Description: OpenPGP digital signature
gexiv fails to build on patch issue
FreeBSD alex-laptop.localhost 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 portmaster gexiv2-0.2.1_2 === Currently installed version: gexiv2-0.2.1_2 === Port directory: /usr/ports/graphics/gexiv2 === Gathering distinfo list for installed ports === Launching 'make checksum' for graphics/gexiv2 in background === No options to configure === Gathering dependency list for graphics/gexiv2 from ports === Initial dependency check complete for graphics/gexiv2 === Starting build for graphics/gexiv2 === === All dependencies are up to date === Cleaning for gexiv2-0.4.1 === License GPLv2 accepted by the user === gexiv2-0.4.1 depends on file: /usr/local/sbin/pkg - found === Extracting for gexiv2-0.4.1 = SHA256 Checksum OK for libgexiv2-0.4.1.tar.bz2. === Patching for gexiv2-0.4.1 === Applying FreeBSD patches for gexiv2-0.4.1 2 out of 2 hunks failed--saving rejects to gexiv2/gexiv2-metadata-exif.cpp.rej = Patch patch-exiv2-0.21 failed to apply cleanly. *** Error code 1 Stop in /usr/ports/graphics/gexiv2. === make failed for graphics/gexiv2 === Aborting update Terminated === You can restart from the point of failure with this command line: portmaster flags graphics/gexiv2 -- Yours in Christ, Joseph A Nagy Jr Whoever loves instruction loves knowledge, But he who hates correction is stupid. -- Proverbs 12:1 Emails are not formal business letters, whatever businesses may want. Original content CopyFree (F) under the OWL http://owl.apotheon.org signature.asc Description: OpenPGP digital signature
Re: New port cad/fritzing
Em Qua, 2012-11-07 às 21:37 +1000, Robert Backhaus escreveu: I had not problems building, but when I run, I get error messages: Dialog: Sorry, we have a problem with the swapping mechanism. Fritzing still works, but you won't be able to change parts properties While loading bin: core parts, a dialog that says Unable to find the following 112 parts, and a list starting with '3234DBDC00PotnetionmetModuleId' at parts/core/basic_poti.fzp' When closing that window (The 'OK' button is unavailable, because it is way off the bottom of the screen), we get printed to the console: 7 times: QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::end: Painter not active, aborted about 42 times: libpng error: PNG file corrupted by ASCII conversion The program then opens, but, as there are no parts, I can't do much. Ok.. I will build a system from ground zero (xorg, qt) and will test hope by tomorrow I will have a clue... ___ 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: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
On 7 November 2012 13:57, Patrick Powell papow...@astart.com wrote:
First, I want to thank the Wine developers for a job/life/sanity saving
piece of code.
I need both 32 and 64 versions. It would be nice if the ports had a
wine-32 and wine-64 just to make
life simple for us non-intensive Ports users. Just a comment.
Ports does have a wine-32 port-- it's called emulators/wine. This
will be an *additional* port for amd64.
Chris
On 11/07/12 01:45, Thomas Mueller wrote:
from David Naylor naylor.b.da...@gmail.com:
Hi List,
# Executive Summary
Over the past years I have been maintaining the wine-fbsd64 port (see
http://mediafire.com/wine_fbsd64 for more). The port itself effectively
does
static linking (it bundles all the libraries wine needs) with scripts to
bootstrap the environment to easily use wine from FreeBSD/amd64. There
is
also a script to install the i386 nVidia graphic drivers so that wine has
access to nVidia accelerated graphics from FreeBSD/amd64.
I would like to propose this port gets included in the port's collection
and
would like to get feedback, your comments please :-).
P.S. I'm not subscribed to the list, so please ensure I'm cc'ed in the
discussion.
# Details of the Port
Please see attached for the actual port.
## Port Preamble
This port is a slave port to emulators/wine(-devel). The master port
needed
to be modified (already done):
- to conditionally set USE_LDCONFIG (if USE_LDCONFIG32 was not set)
- to allow the library directory to be changed (see WINELIBDIR)
- to allow configure arguments to be appended
## Port Targets
The port itself does the following in the preamble:
- specifies the pkg(de)install script to handle nVidia driver patching
- overrides ACTUAL-PACKAGE-DEPENDS (all depends are bundled with the
port)
- defined the library directory to ${PREFIX}/lib32
- defined the binary directory to ${PREFIX}/bin32
- patches the PLIST to refer to lib32 (not lib)
- defined USE_LDCONFIG32 appropriately
The post-install-script target:
- Installs the files/binbounce file in ${PREFIX}/bin for each
${PREFIX}/bin32
file (hard linked)
- Finds all linked library, copies them to ${PREFIX}/lib32, and added
them to
the plist
- Finds all dlopen'ed libraries, copies them to ${PREFIX}/lib32, and
added
them to the plist
- Installs the nVidia patch file
- Run the (PRE-|POST-)INSTALL script
The post-package-script (run only if WITH_PKGNG is defined):
- Amends the package so the arch label to 64bit
## Port scripts (in files/)
The binbounce file does the following to transparently fix the
environment to
allow seamless running of the wine programs:
- determines the location of the TARGET (follows symbolic links to
itself)
- fixes LD_LIBRARY_PATH if in an i386 environment (so lib32, lib32/wine
is
found)
- fixes LD_32_LIBRARY_PATH if in an amd64 environment (so lib32,
lib32/wine,
/usr/lib32)
- fixes PATH (so bin32 is found)
- passes execution to the counterpart in bin32
The patch-nvidia.sh file does the following:
- Downloads the nVidia distfile for i386 (iff nVidia amd64 driver is
installed)
- Installs the required libraries into ${PREFIX}/lib32
- When run from the install script it does _not_ download the distfile,
only
installs the libraries iff the distfiles are already downloaded.
# Shortcomings of the port
The following are shortcomings that I am aware of:
- Can only be compiled in an i386 environment, but the resulting
package is
*intended* for amd64 (although works fine in an i386 environment)
- If, somehow, there is a recursive calling of wine programs then
LD_(32_)LIBRARY_PATH and PATH will continue to grow with every iteration.
- The pkgng ports cannot be installed in an i386 environment as they
are
labelled for amd64.
# Testing
The ports published on mediafire have been tested by many users. The
port
itself works flawlessly however there have been some reports about some
flaws
in the 32-bit compatibility layer of the kernel (although I cannot
remember
the specifics now).
To produce the package on an amd64 system do the following:
# (cd /usr/ports/emulators/; patch -p0 /path/to/diff)
# make -C /usr/src world DESTDIR=/i386 TARGET=i386
# mount -t devfs devfs /i386/dev
# mkdir /i386/usr/ports
# mount -t nullfs /usr/ports /i386/usr/ports
# chroot make -C /usr/ports/emulators/wine-fbsd64 package WITH_PKGNG=yes
The package wine-fbsd64-1.5.16,1.txz (in pkgng format) will be available
from
/usr/ports/packages/All/
# Conclusion
It is based completely off the main port and uses the hack to,
effectively, use static linking (or bundling of libraries). In a
sense it is a complete, yet quite stable and encompassing, hack.
- David ;-)
It would be nice to have wine-fbsd64 as a port, but that might
unfortunately
deprive the user of certain flexibility.
Also, nVidia support should be an option, since users with other graphics
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
On Saturday, 3 November 2012 22:47:56 Jan Beich wrote: David Naylor naylor.b.da...@gmail.com writes: The post-package-script (run only if WITH_PKGNG is defined): - Amends the package so the arch label to 64bit WITH_PKGNG is checked too early. The port fails to fix arch on 10.0 without the variable being set explicitly in make.conf. http://svn.freebsd.org/changeset/ports/305637 I am aware of the change for FreeBSD 10 however didn't realise the port failed. Thanks, I'll try find a fix (although that code is the ugliest hack of the port). To produce the package on an amd64 system do the following: # (cd /usr/ports/emulators/; patch -p0 /path/to/diff) # make -C /usr/src world DESTDIR=/i386 TARGET=i386 # mount -t devfs devfs /i386/dev # mkdir /i386/usr/ports # mount -t nullfs /usr/ports /i386/usr/ports # chroot make -C /usr/ports/emulators/wine-fbsd64 package WITH_PKGNG=yes This is probably easier to manage when using poudriere e.g. # poudriere jails -c -j 10i386 -v HEAD -a i386 -m allbsd # patch -Efsp0 -i /path/to/diff -d /poudriere/ports/default/ports/emulators # poudriere bulk -j 10i386 emulators/wine-fbsd64 I will add this to the wiki (when it gets created). Thanks signature.asc Description: This is a digitally signed message part.
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
On Wednesday, 7 November 2012 11:45:11 Thomas Mueller wrote: from David Naylor naylor.b.da...@gmail.com: Hi List, # Executive Summary Over the past years I have been maintaining the wine-fbsd64 port (see http://mediafire.com/wine_fbsd64 for more). The port itself effectively does static linking (it bundles all the libraries wine needs) with scripts to bootstrap the environment to easily use wine from FreeBSD/amd64. There is also a script to install the i386 nVidia graphic drivers so that wine has access to nVidia accelerated graphics from FreeBSD/amd64. I would like to propose this port gets included in the port's collection and would like to get feedback, your comments please :-). P.S. I'm not subscribed to the list, so please ensure I'm cc'ed in the discussion. # Conclusion It is based completely off the main port and uses the hack to, effectively, use static linking (or bundling of libraries). In a sense it is a complete, yet quite stable and encompassing, hack. - David ;-) It would be nice to have wine-fbsd64 as a port, but that might unfortunately deprive the user of certain flexibility. To what flexibility do you refer to? Nothing stops the user from building the port herself and for those who prefer a binary with most options switched on (as is with what I provide) that can still be provided (and possibly in an automated manor via a pkgng repository). Also, nVidia support should be an option, since users with other graphics cards might have no use for it. I think I fail to explain how the nVidia support works: it is a simple script that downloads the corresponding i386 drivers (user land libGL stuff) for the amd64 package. If there is no amd64 package installed it cannot know which i386 version to download, also, when installing it does not download any files, only installing the drivers if the distfile is already available on the system. So, there are three cases (on installation): 1) The user has no amd64 package installed (nothing is done) 2) The user has amd64 package installed but no i386 distfile available (nothing is done) 3) The user has amd64 package installed and i386 distfiles available (user land libGL stuff is extracted and placed in $LOCALBASE/lib32) In case 2, the user is advised to run the script manually to download and install the i386 distfiles. In cases 1, 2 and 3 the user is advised to run the script manually whenever there is a change (or installation) to the amd64 package. I would really prefer to build the i386 FreeBSD system as a separate part, including kernel, since some users, myself included, might want to run an actual FreeBSD i386, especially on an older computer. So one could build this FreeBSD i386 on a USB stick or USB hard drive, and then be able to run wine on an i386 system. I think an easy way to achieve this is to modify the FreeBSD32 compatibility to work similar to the linux compatibility, namely: have a super-imposed shadow file-hierarchy at /compat/i386 (similar to /compat/linux). This way the i386 packages can be installed into /compat/i386 and when called can easily find the correct libraries. Then, create an alias: pkg-i386 = chroot env UNAME_p=i386 UNAME_m=i386 MACHINE=i386 /compat/i386 pkg and with the correct i386 repo specified it is trivial to install i386 programs and with a modified PATH: PATH=$PATH:/compat/i386/usr/local/bin:/compat/i386/usr/local/sbin the programs will integrate seamlessly. However, to my knowledge, there are few ports that are i386 only (such as wine) and maybe it is easier to use a similar hack to the wine-fbsd64 port to cater for the fringe cases??? P.S. I really would like to see FreeBSD be broken into packages and integrated into the ports tree, just my crazy ideas though... Would wine-fbsd64 be a separate port, or would it be wine built on i386, as the page http://wiki.freebsd.org/Wine suggests? It would be nice to be able to run Wine on i386 as well as amd64. The answer is yes to both your questions. It can only be built on i386 but is a separate port. The reason for the separate port is to allow extra stuff to happen so that it can be run on amd64 as well. The package can be run on both i386 and amd64. Regards signature.asc Description: This is a digitally signed message part.
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
On Sunday, 4 November 2012 13:31:46 Chris Rees wrote:
I think this is very interesting... but I'm not 100% convinced the
best place for this is in the ports tree. However, it would improve
visibility for it, with a good IGNORE message.
Ideally, FreeBSD should have an automagical method of supporting i386 packages
on an amd64 system. Please see my reply to Thomas Muller for my thoughts on
this topic.
We have a problem however; we can't include bsd.port.pre.mk in a slave
port.
The solution I can think of is;
post-package-script:
if [ ${PKG_BIN:T} = pkg ]; then \
${XZ_CMD} -dc ${PKGFILE} | \
${SED} -e s/^\(arch: freebsd:.*:x86\):32/\1:64/ | \
${XZ_CMD} ${WRKDIR}/${PKGNAME}.txz; \
${MV} ${WRKDIR}/${PKGNAME}.txz ${PKGFILE}; \
fi
Thanks, I've added that to the port and will test it later :-)
Thanks
signature.asc
Description: This is a digitally signed message part.
Re: Steam, linux version
On 11/7/2012 1:44 AM, Alexander Yerenkow wrote: Hey guys. Steam is now in Beta for Ubuntu, they provide *.deb file. Do someone working on bringing it to FreeBSD with linux emulation? :) That would be fantastic to have!
Re: gexiv fails to build on patch issue
Hi! The patch patch-exiv2-0.21 was integrated upstream and is not needed anymore. You can remove it (/usr/ports/graphics/gexiv2/files/patch-exiv2-0.21) and rebuild. I opened a PR to track this problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=173451 (the link may not be available yet) -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: gexiv fails to build on patch issue
On 11/07/12 14:04, Jean-Sébastien Pédron wrote: Hi! The patch patch-exiv2-0.21 was integrated upstream and is not needed anymore. You can remove it (/usr/ports/graphics/gexiv2/files/patch-exiv2-0.21) and rebuild. I opened a PR to track this problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=173451 (the link may not be available yet) that did the trick. -- Yours in Christ, Joseph A Nagy Jr Whoever loves instruction loves knowledge, But he who hates correction is stupid. -- Proverbs 12:1 Emails are not formal business letters, whatever businesses may want. Original content CopyFree (F) under the OWL http://owl.apotheon.org signature.asc Description: OpenPGP digital signature
Re: trying to build a port for vagrant and failing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 06 Nov 2012 17:58:42 -0500
Greg Larkin glar...@freebsd.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/6/12 4:00 PM, Christopher J. Ruwe wrote:
Currently, I am trying to write up a port for vagrant, a VirtualBox
managment thing (http://vagrantup.com/). I am failing with the
dependencies and would be grateful for some help.
I have
BUILD_DEPENDS=
minitar:${PORTSDIR}/archivers/rubygem-archive-tar-minitar \
RUN_DEPENDS=erubis:${PORTSDIR}/www/rubygem-erubis \
rubygem-childprocess=0.3.1:${PORTSDIR}/devel/rubygem-childprocess
\ rubygem-i18n=0.6.0:${PORTSDIR}/devel/rubygem-i18n \
rubygem-json=1.5.1:${PORTSDIR}/devel/rubygem-json \
rubygem-log4r=1.1.9:${PORTSDIR}/sysutils/rubygem-log4r \
rubygem-net-ssh=2.2.2:${PORTSDIR}/security/rubygem-net-ssh \
rubygem-net-scp=1.0.4:${PORTSDIR}/security/rubygem-net-scp
in the makefile.
From the build log (I am using poudriere for testing) I get
===phase:
run-depends== ===
rubygem-vagrant-1.0.5 depends on executable: erubis - not found
===Verifying install for erubis in
/usr/ports/www/rubygem-erubis === Installing existing package
/usr/ports/packages/All/rubygem-erubis-2.7.0.tbz === Returning
to build of rubygem-vagrant-1.0.5 === rubygem-vagrant-1.0.5
depends on package: rubygem-childprocess=0.3.1 - not found ===
Verifying install for rubygem-childprocess=0.3.1 in
/usr/ports/devel/rubygem-childprocess === Installing existing
package /usr/ports/packages/All/rubygem-childprocess-0.3.5.tbz
=== Returning to build of rubygem-vagrant-1.0.5 ===
rubygem-vagrant-1.0.5 depends on package: rubygem-i18n=0.6.0 -
not found ===Verifying install for rubygem-i18n=0.6.0 in
/usr/ports/devel/rubygem-i18n === Installing existing package
/usr/ports/packages/All/rubygem-i18n-0.6.0,2.tbz === Returning
to build of rubygem-vagrant-1.0.5 === rubygem-vagrant-1.0.5
depends on package: rubygem-json=1.5.1 - not found === Verifying
install for rubygem-json=1.5.1 in /usr/ports/devel/rubygem-json
=== Installing existing package
/usr/ports/packages/All/rubygem-json-1.7.5.tbz === Returning to
build of rubygem-vagrant-1.0.5 === rubygem-vagrant-1.0.5
depends on package: rubygem-log4r=1.1.9 - not found ===
Verifying install for rubygem-log4r=1.1.9 in
/usr/ports/sysutils/rubygem-log4r === Installing existing
package /usr/ports/packages/All/rubygem-log4r-1.1.10.tbz ===
Returning to build of rubygem-vagrant-1.0.5 ===
rubygem-vagrant-1.0.5 depends on package: rubygem-net-ssh=2.2.2 -
not found ===Verifying install for rubygem-net-ssh=2.2.2 in
/usr/ports/security/rubygem-net-ssh === Installing existing
package /usr/ports/packages/All/rubygem-net-ssh-2.1.4,2.tbz ===
Returning to build of rubygem-vagrant-1.0.5 ===
rubygem-vagrant-1.0.5 depends on package: rubygem-net-scp=1.0.4 -
not found ===Verifying install for rubygem-net-scp=1.0.4 in
/usr/ports/security/rubygem-net-scp === Installing existing
package /usr/ports/packages/All/rubygem-net-scp-1.0.4_1.tbz ===
Returning to build of rubygem-vagrant-1.0.5 ===
rubygem-vagrant-1.0.5 depends on file: /usr/local/bin/gem18 - found
=== rubygem-vagrant-1.0.5 depends on file: /usr/local/bin/ruby18
- found
===
So far so good. I noticed that rubygem-net-ssh-2.1.4.2 is supposed
to satisfy =rubygem-net-ssh-2.2.2, which I ignore for the while.
Now, building yields
===phase: install
== === Installing for
rubygem-vagrant-1.0.5 === rubygem-vagrant-1.0.5 depends on
executable: erubis - found === rubygem-vagrant-1.0.5 depends on
package: rubygem-childprocess=0.3.1 - found ===
rubygem-vagrant-1.0.5 depends on package: rubygem-i18n=0.6.0 -
found === rubygem-vagrant-1.0.5 depends on package:
rubygem-json=1.5.1 - found === rubygem-vagrant-1.0.5 depends
on package: rubygem-log4r=1.1.9 - found ===
rubygem-vagrant-1.0.5 depends on package: rubygem-net-ssh=2.2.2 -
found === rubygem-vagrant-1.0.5 depends on package:
rubygem-net-scp=1.0.4 - found === rubygem-vagrant-1.0.5 depends
on file: /usr/local/bin/gem18 - found === rubygem-vagrant-1.0.5
depends on file: /usr/local/bin/ruby18 - found === Generating
temporary packing list === Checking if emulators/rubygem-vagrant
already installed /usr/bin/env /usr/local/bin/gem18 install -l
--no-update-sources --no-ri --install-dir /usr/local/lib/r\
uby/gems/1.8 /usr/ports/distfiles/rubygem/vagrant-1.0.5.gem --
--build-args ERROR: While executing gem ... (Gem::DependencyError)
Unable to resolve dependencies: vagrant requires json (~ 1.5.1),
net-ssh (~ 2.2.2) *** Error code 1
The installation is right about net-ssh (confer above), but
definitely
Re: Steam, linux version
On Wed, 07 Nov 2012 10:46:43 -0800 Mike Carlson m...@bayphoto.com wrote: On 11/7/2012 1:44 AM, Alexander Yerenkow wrote: Hey guys. Steam is now in Beta for Ubuntu, they provide *.deb file. Do someone working on bringing it to FreeBSD with linux emulation? :) That would be fantastic to have! I would expect that you may only get something up and running with the highly experimental and incomplete (it's not rocked science, I have a blog post about adding what's missing) linux_base-c6... if at all. I would expect that it depends upon a more recent glibc than what we have on the default linux_base port. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: tk85 Port Maintenance
On 11/06/12 02:20, Pietro Cerutti wrote:
snip
* I won't comment on the LICENSE stuff, I don't know enough about it
* XFT_DESC
This is already defined in bsd.options.desc.mk. I'd say that
Xft font library is ok as a description.
* LIB_DEPENDS+= Xft:${PORTSDIR}/x11-fonts/libXft
This should really be
USE_XORG+= xft
* LIB_DEPENDS= tcl${SHORT_TK_VER}${THREADS_SUFFIX}:
If you're ok to wait until I get rid of the -thread slave ports,
you don't need to bother about this part of the Makefile
svn checked out, svn diff
http://pastebin.com/kLdUFp9H
--
Yours in Christ,
Joseph A Nagy Jr
Whoever loves instruction loves knowledge, But he who hates correction
is stupid. -- Proverbs 12:1
Emails are not formal business letters, whatever businesses may want.
Original content CopyFree (F) under the OWL http://owl.apotheon.org
signature.asc
Description: OpenPGP digital signature
