Re: New experimental gimp 2.8.2 port
Matthieu Volat wrote: I've been continuing to maintain my gimp 2.8 experimental ports, more rigorously checking pkg-plist files and updating to 2.8.2 (well, just incrementing the version number in the Makefile). For those who are interested, until gimp 2.8 is properly imported in the port tree, I've put everything on a github repo: https://github.com/mazhe/gimp28_ports Along a script to update the dependancies and gimp itself. Still missing are the help ports, and a script to revert to the standard versions, I'll check that ASAP. For the record it works fine for me, and doesn't even break any of other applications that depend on the updated libraries. Why isn't this all in the ports tree though? ___ 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 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/libnjb broken because: incomplete plist build errors: http://pointyhat.FreeBSD.org/errorlogs/i386-errorlogs/e.7.20120816063236/libnjb-2.2.7_3.log (_Aug_18_17:45:45_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=libnjb 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/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/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 broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.9.20120710033447/lua50-posix-5.0.log (_Apr__6_15:35:56_UTC_2012) 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: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.8.20120829134031/gdam-0.942_9.log (_Aug_30_20:48:56_UTC_2012) 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/libnjb broken because: incomplete plist build errors: http://pointyhat.FreeBSD.org/errorlogs/i386-errorlogs/e.7.20120816063236/libnjb-2.2.7_3.log (_Aug_18_17:45:45_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=libnjb 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/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: http://portsmon.FreeBSD.org/portoverview.py?category=commsportname=uticom portname: databases/adstudio broken because: incomplete plist 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: 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: devel/libgetline description:A small, portable, and easy to use command line library maintainer: po...@freebsd.org deprecated because: Upstream disapear and distfile is no more available expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=libgetline portname: graphics/linux-cairo description:Linux cairo binary maintainer: po...@freebsd.org deprecated because: expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=linux-cairo portname: graphics/linux-gdk-pixbuf description:Linux version of the graphic library for GTK+ maintainer: po...@freebsd.org deprecated because: expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=linux-gdk-pixbuf portname: java/sun-wtk description:Sun J2ME Wireless Toolkit maintainer: po...@freebsd.org status: IGNORE deprecated because: no more public distfiles, merged with Java ME SDK 3.0 upstream expiration date:2013-01-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=javaportname=sun-wtk portname: www/linuxpluginwrapper description:A wrapper allowing use of linux-plugins with native
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: 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: 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
update to devel/apr-1.4.6.1.4.1_1 requires then subversion rebuild
=== Upgrade of apr-ipv6-devrandom-1.4.5.1.3.12_1 to apr-1.4.6.1.4.1_1 succeeded # svn status /usrp Shared object libaprutil-1.so.3 not found, required by svn Perhaps subversion version should be bumped too? Anton ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[HEADS-UP] Announcing the end of port CVS
The development of FreeBSD ports is done in Subversion nowadays.
For the sake of compatibility a Subversion to CVS exporter is
in place which has some limitations. For CVSup mirroring cvsup
based on Ezm3 is used which breaks regularly especially on amd64
and with Clang and becomes more and more unmaintainable.
For those reasons by February 28th 2013 the FreeBSD ports tree will
no longer be exported to CVS. Therefore ports tree updates via CVS
or CVSup will no longer available after that date. All users who use
CVS or CVSup to update the ports tree are encouraged to switch to
portsnap(8) [1] or for users which need more control over their ports
collection checkout use Subversion directly:
% svn co https://svn0.us-west.FreeBSD.org/ports/head /usr/ports
and update a checked out repository using:
% cd /usr/ports svn update
Advanced users, or larger sites, might consider setting up a local
svn mirror. Both for people doing direct checkouts and for people
wanting to use a local mirror, they can access one of the public
subversion servers [2].
How to set up a Subversion mirror using svnsync(1) is described in
the FreeBSD Committers Guide [3]. Initial seeds to set up a svnsync
mirror are provided on the FreeBSD FTP mirror sites under
/pub/FreeBSD/development/subversion/.
Binary packages for pkg_install are still provided via the FTP mirror
network. There is also pkgng which is a feature rich replacement tool
for pkg_install available in the ports tree under ports/ports-mgmt/pkg.
Packages for pkgng are available on pkg.FreeBSD.org.
To use pkg.FreeBSD.org at least pkgng 1.0 RC6 is needed and can be
enabled in pkg.conf like this (where ${ABI} is dependent on your
system):
PACKAGESITE : http://pkg.freebsd.org/${ABI}/latest
SRV_MIRRORS : YES
With pkgng 1.0 SRV_MIRRORS is enabled by default and no longer needs
to be set explicitly. If pkgng prior to 1.0 RC6 is used
http://pkgbeta.FreeBSD.org can be used as packagesite instead.
Please keep im mind that the pkgng infrastructure is still considered
as beta. More information about pkgng can be found at
http://wiki.FreeBSD.org/pkgng and https://github.com/pkgng/pkgng.
Beat, on behalf of portmgr@
[1] http://www.FreeBSD.org/doc/handbook/updating-upgrading-portsnap.html
[2] http://www.FreeBSD.org/doc/handbook/mirrors-svn.html
[3]
http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html
___
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: [HEADS-UP] Announcing the end of port CVS
On 07/09/2012 14:36, Beat Gaetzi wrote: For those reasons by February 28th 2013 the FreeBSD ports tree will no longer be exported to CVS. Therefore ports tree updates via CVS or CVSup will no longer available after that date. All users who use CVS or CVSup to update the ports tree are encouraged to switch to portsnap(8) [1] or for users which need more control over their ports collection checkout use Subversion directly: I'm assuming that CVSup also covers csup? Will csup be removed from base? signature.asc Description: OpenPGP digital signature
Re: [HEADS-UP] Announcing the end of port CVS
On 09/07/12 13:18, Ivan Voras wrote: On 07/09/2012 14:36, Beat Gaetzi wrote: For those reasons by February 28th 2013 the FreeBSD ports tree will no longer be exported to CVS. Therefore ports tree updates via CVS or CVSup will no longer available after that date. All users who use CVS or CVSup to update the ports tree are encouraged to switch to portsnap(8) [1] or for users which need more control over their ports collection checkout use Subversion directly: I'm assuming that CVSup also covers csup? Yes, csup for ports is also covered. Beat ___ 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: [HEADS-UP] Announcing the end of port CVS
On 7 Sep 2012 12:20, Ivan Voras ivo...@freebsd.org wrote: On 07/09/2012 14:36, Beat Gaetzi wrote: For those reasons by February 28th 2013 the FreeBSD ports tree will no longer be exported to CVS. Therefore ports tree updates via CVS or CVSup will no longer available after that date. All users who use CVS or CVSup to update the ports tree are encouraged to switch to portsnap(8) [1] or for users which need more control over their ports collection checkout use Subversion directly: I'm assuming that CVSup also covers csup? Will csup be removed from base? Src still uses csup, so not quite yet methinks. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADS-UP] Announcing the end of port CVS
On Fri, Sep 07, 2012 at 11:53:47AM +0100, Jamie Paul Griffin wrote: ... Can I just ask something about changing over to use sv - should I delete the entire /usr/ports tree before I use : svn co https://svn0.us-west.FreeBSD.org/ports/head /usr/ports You might want to consider saving away /usr/ports/distfiles and/or /usr/ports/packages first, but (basically): yes. (I made this transition myself not all thta long ago.) ... Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpQyZlu8hI2j.pgp Description: PGP signature
Re: [FreeBSD-Announce] Announcing the end of port CVS
Moved discussion to freebsd-ports... - Original Message - From: Beat Gaetzi b...@freebsd.org portsnap also doesn't appear to provide feature compatibility with csup, specifically it states in the man page that it deletes unknown files and restore modified files to their unmodified state. This makes maintaining custom patches very hard. Is there an option to disable this behaviour? You can blacklist custom ports with a REFUSE line in portsnap.conf or use a Subversion checkout to maintain your local modifications. Is there no way to tell it not to delete unknown files so we don't have to add addional steps to the workflow flow of adding additional patches to local port builds? I appreciate things must move forward but this seems like a step backwards in terms of functionality :( Also where is the local mirrors list for portsnap as I can't find anything like the mirrors list for cvsup e.g. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html#CVSUP-MIRRORS Mirrors for portsnap are selected using geolocation: http://www.daemonology.net/blog/2012-05-20-portsnap-geolocation.html Not wishing to be a pain but its often the case that simple geolocation fails to be optimal due to load network paths etc, is there a list of the available sites so we can test and use the best mirror for us? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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
remove groff from base?
textproc/groff is more up to date and more complete than the src version, for obvious reasons. I use groff for document preparation, so need the ports version. I don't mind having the two versions, just have to remember to use -M man switch, or set the PATH accordingly. However, I wonder, with all the talk about some tools better kept in ports rather than in base (e.g. pkg), is it perhaps better to remove groff from base completely? The bsdinstall (I haven't used it yet myself, haven't done a fresh install for a while) could still offer to install the man pages, but warn the user that textproc/groff must be installed. On the other hand, groff depends directly on 29 other ports, so maybe it's a lot to ask from a user - if something is wrong with the ports tree, the user might end up with no man pages, which is bad. Anyway, for me, the more tools are moved to ports - the better. I happen to use mostly older, slower boxes, so buildworld time is an issue. Anton ___ 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: [HEADS-UP] Announcing the end of port CVS
From owner-freebsd-po...@freebsd.org Fri Sep 7 13:04:28 2012 svn co https://svn0.us-west.FreeBSD.org/ports/head /usr/ports I've got svn://svn.freebsd.org/ports/head Is that no nonger valid? Seems to work though. Anton ___ 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: [HEADS-UP] Announcing the end of port CVS
Hi! Can I just ask something about changing over to use sv - should I delete the entire /usr/ports tree before I use : svn co https://svn0.us-west.FreeBSD.org/ports/head /usr/ports You might want to consider saving away /usr/ports/distfiles and/or /usr/ports/packages first, but (basically): yes. What happens, if one does: svn update and then adds some files to distfiles/ and then does some svn update again. Will the distfiles be deleted ? Ignored ? ... ? -- p...@opsec.eu+49 171 3101372 8 years to go ! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADS-UP] Announcing the end of port CVS
On 7 September 2012 08:16, Kurt Jaeger li...@opsec.eu wrote: What happens, if one does: svn update and then adds some files to distfiles/ and then does some svn update again. Will the distfiles be deleted ? Ignored ? ... ? ignored. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: remove groff from base?
On 07-09-2012 13:04, Anton Shterenlikht wrote: However, I wonder, with all the talk about some tools better kept in ports rather than in base (e.g. pkg), is it perhaps better to remove groff from base completely? We've been discussing replacing groff with mdocml for quite some time. Check the FreeBSD wiki for more details. -- Joel ___ 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: [HEADS-UP] Announcing the end of port CVS
,--- Beat Gaetzi (Fri, 07 Sep 2012 14:36:32 +0200) * | All users who use CVS or CVSup to update the ports tree are | encouraged to switch to portsnap(8) [1] or for users which need more | control over their ports collection checkout use Subversion directly I just switched to 'svn'-ports on an existing system. The question: When I install the base system on a new machine, where do I get 'svn' for the first ports tree fetch? 'svn' is not becoming a part of 'base', right? I know I can copy it from one of my existing systems but what's the official vision for this first step? portsnap? Also, with 'csup' I could exclude a large part of the ports tree from updates with my 'csup.conf file, e.g.: # ports-vietnamese I assume this is no longer possible, right? -- Alex -- alex-goncha...@comcast.net -- ___ 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: [HEADS-UP] Announcing the end of port CVS
On 7 September 2012 08:30, Alex Goncharov alex-goncha...@comcast.net wrote: I know I can copy it from one of my existing systems but what's the official vision for this first step? portsnap? pkg or portsnap. I assume this is no longer possible, right? It is possible to do with portsnap REFUSE lines. It is also possible to do with judicious use of svn --depth arguments. In either case this was never an officially supported configuration. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADS-UP] Announcing the end of port CVS
On Fri, 7 Sep 2012 08:23:16 -0400 Eitan Adler li...@eitanadler.com wrote: On 7 September 2012 08:16, Kurt Jaeger li...@opsec.eu wrote: What happens, if one does: svn update and then adds some files to distfiles/ and then does some svn update again. Will the distfiles be deleted ? Ignored ? ... ? ignored. what about svn st[atus] ?:) -- wbr, tiger ___ 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: [HEADS-UP] Announcing the end of port CVS
On 7 September 2012 08:43, Sergey V. Dyatko sergey.dya...@gmail.com wrote: On Fri, 7 Sep 2012 08:23:16 -0400 Eitan Adler li...@eitanadler.com wrote: what about svn st[atus] ?:) svn update and svn status are different. I'd suggest you try this one for yourself. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [FreeBSD-Announce] Announcing the end of port CVS
on 07/09/2012 14:57 Steven Hartland said the following: Is there no way to tell it not to delete unknown files so we don't have to add addional steps to the workflow flow of adding additional patches to local port builds? I would hazard a recommendation to use something like git-svn / svk /etc if you are going to have local ports development on top of the official tree. There is a git clone of ports on github. -- Andriy Gapon ___ 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-Announce] Announcing the end of port CVS
Dnia 2012-09-07, o godz. 12:57:42
Steven Hartland kill...@multiplay.co.uk napisał(a):
Is there no way to tell it not to delete unknown files so we
don't have to add addional steps to the workflow flow of adding
additional patches to local port builds?
I appreciate things must move forward but this seems like a step
backwards in terms of functionality :(
I`m using portsnap for some time now and wanted to have my /usr/ports
untouched but also I have my own patches for some of the software that
I use. I have come up with not ideal but simple solution, my make.conf
contains something like this:
.if ${.CURDIR:M/usr/ports/*}
LOCALPATCHDIR= /home/corn/patches
. if exists(${LOCALPATCHDIR}/${.CURDIR:T})
LOCAL_PATCHES!= find ${LOCALPATCHDIR}/${.CURDIR:T} -type f
EXTRA_PATCHES+= ${LOCAL_PATCHES}
. endif
.endif
LOCALPATCHDIR contains folders with names of ports I want to patch
which hold my patches inside them.
Be aware that this will break when you want to patch port that shares
name with some other port but different category. This situation is
rare but it could happen.
This inconvenience could probably be easily fixed when UNIQUENAME work
will be committed to the ports tree, but I'm not sure when this will be.
--
pozdrawiam / with regards
Paweł Pękala
___
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: [HEADS-UP] Announcing the end of port CVS
On Fri, 7 Sep 2012, Beat Gaetzi wrote: The development of FreeBSD ports is done in Subversion nowadays. For the sake of compatibility a Subversion to CVS exporter is in place which has some limitations. For CVSup mirroring cvsup based on Ezm3 is used which breaks regularly especially on amd64 and with Clang and becomes more and more unmaintainable. What exactly is the motivation again for moving from things which work like cvsup and gcc to things that are broken or lame like subversion and clang? -- Lars Eighner http://www.larseighner.com/index.html 8800 N IH35 APT 1191 AUSTIN TX 78753-5266 ___ 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-Announce] Announcing the end of port CVS
On 7 Sep 2012 15:39, Pawel Pekala pa...@freebsd.org wrote:
Dnia 2012-09-07, o godz. 12:57:42
Steven Hartland kill...@multiplay.co.uk napisał(a):
Is there no way to tell it not to delete unknown files so we
don't have to add addional steps to the workflow flow of adding
additional patches to local port builds?
I appreciate things must move forward but this seems like a step
backwards in terms of functionality :(
I`m using portsnap for some time now and wanted to have my /usr/ports
untouched but also I have my own patches for some of the software that
I use. I have come up with not ideal but simple solution, my make.conf
contains something like this:
.if ${.CURDIR:M/usr/ports/*}
LOCALPATCHDIR= /home/corn/patches
. if exists(${LOCALPATCHDIR}/${.CURDIR:T})
LOCAL_PATCHES!= find ${LOCALPATCHDIR}/${.CURDIR:T} -type f
EXTRA_PATCHES+= ${LOCAL_PATCHES}
. endif
.endif
LOCALPATCHDIR contains folders with names of ports I want to patch
which hold my patches inside them.
Be aware that this will break when you want to patch port that shares
name with some other port but different category. This situation is
rare but it could happen.
This inconvenience could probably be easily fixed when UNIQUENAME work
will be committed to the ports tree, but I'm not sure when this will be.
Well, as long as they don't collide with any files named, I'm pretty sure
svn will ignore them, and even merge changes (eg to Makefiles)
Chris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
pkg.c broke 561 pkg.c: In function 'pkg_adddep': on stable/8
Thought I would let you know... This seems to have broken the build... === libpkg (all) Warning: Object directory not changed from original /exports/pkgng/libpkg cc -O2 -pipe -march=native -DHAVE_GRUTILS -std=c99 -I/exports/pkgng/libpkg -I/exports/pkgng/libpkg/../external/sqlite -I/exports/pkgng/libpkg/../external/libyaml/include -I/exports/pkgng/libpkg/../external/uthash -DPREFIX=\/usr/local\ -g -O0 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c pkg.c cc1: warnings being treated as errors pkg.c: In function 'pkg_adddep': pkg.c:561: warning: cast discards qualifiers from pointer target type *** Error code 1 Stop in /exports/pkgng/libpkg. *** Error code 1 Stop in /exports/pkgng. # git log -p commit 657802f7eef98f2aa3b4a77ec52bfc39e5792afc Author: Baptiste Daroussin b...@freebsd.org Date: Thu Sep 6 19:49:34 2012 +0200 -- - (2^(N-1)) JJH48-ARIN ___ 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
