Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 21/08/2012 00:21, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 12:09:46AM +0300, Vitaly Magerya wrote: Baptiste Daroussin b...@freebsd.org wrote: Please [...] ask question about pkgng [...] What would be the best practice of mixing ports with packages? The use case I have in mind is compiling Xorg ports locally WITH_NEW_XORG and WITH_KMS, and using packages from pkgbeta.freebsd.org for everything else. Is there some mixture of pkg and portmaster flags that allows this kind of setup? ___ 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 There is no best practice for that unfortunatly, (as actually) the best for you is maybe to build your own pkgng repostories? http://wiki.freebsd.org/PkgPrimer#Using_poudriere for example? We are open to suggestion here :) At the moment, it is about as tricky as mixing locally compiled ports with pkg_tools packages: ie. it might work, or it might leave you a quivering, sobbing mess lost in a pit of dark despair. One thing that should help is a proposal to record metadata like the SVN revision number of the ports tree used to build repository packages into the repository catalogue (repo.sqlite), so users can in principle check out the same revision locally to build their own ports. Unfortunately no one has written that yet, and its probably too late for it to make it into release-1.0. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: [CFT] TexLive port
On 20/08/2012 10:16, Denny Lin wrote: On Mon, Aug 20, 2012 at 09:51:02AM +0200, Dominic Fandrey wrote: On 12/08/2012 10:12, Dominic Fandrey wrote: On 31/07/2012 00:48, Dominic Fandrey wrote: I have a well working TexLive 2012 port, intended to be a replacement for teTex. ... Because a lot of things depend on a working TeX install I'd like to have some volunteers in a week. Here we go: http://www.home.hs-karlsruhe.de/~fado1011/texlive/ I'm about ready now. I just need to complete the CONFLICTS. Clearly just anything with teTeX in the name isn't enough. I think I need help figuring this out. Or at least a recommendation. Should I go ahead with a PR and just add ports as people report problems? Sorry, I must have missed this part in my previous email. The CONFLICTS you have should cover everything. I'm just speculating that the transition would have been smoother if the teTeX ports were deleted in one go before replacing them with portmaster. Maybe I need to add texlive conflicts to teTeX and its ilk. I also want to add a texlive-asymptote port. But only after texlive is out there. I already tested the build, but there are some dependencies I want to add OPTIONS for and that's nothing I want to inflict on the texlive-base. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 07:05:49AM +0100, Matthew Seaman wrote: On 21/08/2012 00:21, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 12:09:46AM +0300, Vitaly Magerya wrote: Baptiste Daroussin b...@freebsd.org wrote: Please [...] ask question about pkgng [...] What would be the best practice of mixing ports with packages? The use case I have in mind is compiling Xorg ports locally WITH_NEW_XORG and WITH_KMS, and using packages from pkgbeta.freebsd.org for everything else. Is there some mixture of pkg and portmaster flags that allows this kind of setup? ___ 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 There is no best practice for that unfortunatly, (as actually) the best for you is maybe to build your own pkgng repostories? http://wiki.freebsd.org/PkgPrimer#Using_poudriere for example? We are open to suggestion here :) At the moment, it is about as tricky as mixing locally compiled ports with pkg_tools packages: ie. it might work, or it might leave you a quivering, sobbing mess lost in a pit of dark despair. One thing that should help is a proposal to record metadata like the SVN revision number of the ports tree used to build repository packages into the repository catalogue (repo.sqlite), so users can in principle check out the same revision locally to build their own ports. Unfortunately no one has written that yet, and its probably too late for it to make it into release-1.0. yes but it should definitly find its way to 1.1! regards, Bapt pgppErHxBkzUn.pgp Description: PGP signature
Attempting to fetch pkgconf-0.8.7.tar.bz2, Couldn't fetch it
Hi Is anyone else seeing this problem? /Leslie = Attempting to fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/pkgconf-0.8.7.tar.bz2 fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/pkgconf-0.8.7.tar.bz2: File unavailable (e.g., file not found, no access) = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles// and try again. *** Error code 1 ___ 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: Attempting to fetch pkgconf-0.8.7.tar.bz2, Couldn't fetch it
El Martes, 21 de Agosto de 2012 10:03, Leslie Jensen escribió: Hi Is anyone else seeing this problem? /Leslie = Attempting to fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/pkgconf-0.8.7.tar.bz2 fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/pkgconf-0.8.7.tar.bz2: File unavailable (e.g., file not found, no access) = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles// and try again. *** Error code 1 Hi, Yes, i have the same problem ___ 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/teamspeak_client broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=teamspeak_client portname: cad/feappv broken because: size mismatch build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.7.20120810200026/feappv-3.1.log (_Aug__6_16:25:29_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=feappv 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: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.9.20120802074109/simpleagenda-0.42.log (_Aug__3_22:06:24_UTC_2012) 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:
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.20120820105642/gdam-0.942_9.log (_Aug_21_02:41:04_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/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/feappv broken because: size mismatch build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.7.20120810200026/feappv-3.1.log (_Aug__6_16:25:29_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=feappv portname: cad/meshlab broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/i386-errorlogs/e.8.20120730062936/meshlab-1.3.0.log (_Jul_31_05:31:08_UTC_2012) 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
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: www/linux-f10-flashplugin10 forbidden because: insecure version - use flashplugin11 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=linux-f10-flashplugin10 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
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: databases/libudbc description:Openlink UDBC SDK maintainer: po...@freebsd.org deprecated because: Does not fetch and no vendor support anymore expiration date:2012-08-12 build errors: http://pointyhat.FreeBSD.org/errorlogs/i386-errorlogs/e.7.20120731073932/libudbc-4.1.log (_Aug__2_00:21:36_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=libudbc 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
pkgng, textproc/p5-XML-SAX-Expat: Syntax error: { unexpected (expecting then)
# cd /usr/ports/textproc/p5-XML-SAX-Expat
# make deinstall make reinstall
=== Deinstalling for textproc/p5-XML-SAX-Expat
=== Deinstalling p5-XML-SAX-Expat-0.40
The following packages will be deinstalled:
p5-XML-SAX-Expat-0.40
The deinstallation will free 22 kB
Deinstalling p5-XML-SAX-Expat-0.40...p5-XML-SAX-Expat-0.40 is required by:
p5-XML-Simple-2.20 icon-naming-utils-0.8.90, deleting anyway
Syntax error: { unexpected (expecting then)
pkg: DEINSTALL script failed
*** [deinstall] Error code 3
Stop in /usr/ports/textproc/p5-XML-SAX-Expat.
# pkg -vvv
version: 1.0-rc6
abi: freebsd:10:ia64:64
db dir: /var/db/pkg
cache dir: /var/cache/pkg
ports dir: /usr/ports
Log into syslog: yes
Assume always yes: no
Handle rc scripts: no
Track shlibs: no
Automatic dependency tracking: no
Custom keywords directory: none
Developer mode: no
Repository: ftp://ftp.freebsd.org/pub/pkgng
#
# uname -a
FreeBSD mech-cluster241.men.bris.ac.uk 10.0-CURRENT FreeBSD 10.0-CURRENT #6
r237134: Mon Jun 18 09:02:17 BST 2012
r...@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV ia64
#
___
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
Happy Birthday FreeBSD ports
Hi, Today, 18 years ago the first version of Mk/bsd.port.mk was committed to CVS. From the CVS log: # cvs log -r1.1 Mk/bsd.port.mk Working file: Mk/bsd.port.mk head: 1.738 [...] description: revision 1.1 date: 1994/08/21 13:12:57; author: jkh; state: Exp; Commit my new ports make macros. Still not 100% complete yet by any means but fairly usable at this stage. Submitted by: jkh A couple of minutes later the first ports were committed: editors/emacs editors/jove shells/bash From the CVS log: # cvs log -r1.1.1.1 editors/jove/Makefile Working file: editors/jove/Makefile head: 1.23 [...] description: revision 1.1.1.1 date: 1994/08/21 13:19:28; author: jkh; state: Exp; lines: +0 -0 The start of the 2.0 ports collection. No sup repository yet, but I'll make one when I wake up again.. :) Submitted by: jkh This means that (at least in some countries) the ports tree is grown-up now. Happy Birthday! Beat (on behalf of portmgr@) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng, textproc/p5-XML-SAX-Expat: Syntax error: { unexpected (expecting then)
On 21 August 2012 09:47, Anton Shterenlikht me...@bristol.ac.uk wrote:
# cd /usr/ports/textproc/p5-XML-SAX-Expat
# make deinstall make reinstall
=== Deinstalling for textproc/p5-XML-SAX-Expat
=== Deinstalling p5-XML-SAX-Expat-0.40
The following packages will be deinstalled:
p5-XML-SAX-Expat-0.40
The deinstallation will free 22 kB
Deinstalling p5-XML-SAX-Expat-0.40...p5-XML-SAX-Expat-0.40 is required by:
p5-XML-Simple-2.20 icon-naming-utils-0.8.90, deleting anyway
Syntax error: { unexpected (expecting then)
pkg: DEINSTALL script failed
*** [deinstall] Error code 3
Stop in /usr/ports/textproc/p5-XML-SAX-Expat.
# pkg -vvv
version: 1.0-rc6
abi: freebsd:10:ia64:64
db dir: /var/db/pkg
cache dir: /var/cache/pkg
ports dir: /usr/ports
Log into syslog: yes
Assume always yes: no
Handle rc scripts: no
Track shlibs: no
Automatic dependency tracking: no
Custom keywords directory: none
Developer mode: no
Repository: ftp://ftp.freebsd.org/pub/pkgng
#
How long have you had this installed?
Steve Wills [1] fixed the pkg-deinstall script yesterday, but
evidently you still have an older version.
If pkg delete hasn't removed it, try pkg delete -f, then reinstall.
Chris
[1]
http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/p5-XML-SAX-Expat/pkg-deinstall
___
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
raptor: should there be a note in UPDATING?
I just had a problem building liblrdf. The cause was raptor-1 was still installed. Checking UPDATING shows nothing that mentions raptor after the KDE update last November. Does there need to a note in UPDATING to uninstall raptor? ___ 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: pkg(ng)/portupgrade-devel: does not respect setting of USE_GCC= 4.6+
On Mon, Aug 20, 2012 at 10:39 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: I'm pretty sure, that the last time I updated port math/fftw3 I wanted option OpenMP enabled so I declared USE_GCC=4.6+ in make.conf. Later, also working!, I excluded all these user definitions into an external file called ports.conf located in /usr/local/etc (I like this clean separation of OS and user messes ;-) ). Suddenly it doesn't work anymore. There were changes in several Mk files located in /usr/ports/Mk. Beware! Even if you will be able to force gcc-4.6 to be used and thus obtain OpenMP-3.1 at the compilation stage, the libgomp.so.1, which will be used at run-time, will be OpenMP-3.0 from the base gcc-4.2 (/usr/lib/libgomp.so.1 on my FreeBSD-8.0 system). Also, as a bonus, you may be exposed to ancient bugs from the gcc-4.2 openmp implementation. For me, personally, it is memory leak as described in http://gcc.gnu.org/ml/gcc/2009-05/msg00427.html Fixed in gcc-4.3, but gcc-4.3 never was nor will be in base. Thus... For obtain the proper openmp you will either limit yourself to openmp-3.0 from gcc-4.2 and workaround known bugs, or make a black magic dance for override and unsteal the libgomp (e.g. using libmap.conf) and have maintenance problem every time when gcc version changes (and, therefore, changes the directory name, where gcc libraries live). -- Andrew W. Nosenko andrew.w.nose...@gmail.com ___ 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: Attempting to fetch pkgconf-0.8.7.tar.bz2, Couldn't fetch it
On Tue, Aug 21, 2012 at 10:23:11AM +0200, Enrique Ayesta Perojo wrote: El Martes, 21 de Agosto de 2012 10:03, Leslie Jensen escribió: Hi Is anyone else seeing this problem? /Leslie = Attempting to fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/pkgconf-0.8.7.tar.bz2 fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/pkgconf-0.8.7.tar.bz2: File unavailable (e.g., file not found, no access) = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles// and try again. *** Error code 1 Hi, Yes, i have the same problem ___ 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 I just added a mirror to solve the problem. regards, Bapt pgpv4yrVfiLav.pgp Description: PGP signature
Re: Attempting to fetch pkgconf-0.8.7.tar.bz2, Couldn't fetch it
El Martes, 21 de Agosto de 2012 11:55, Baptiste Daroussin escribió: I just added a mirror to solve the problem. regards, Bapt Thanks, it works now ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
2012/8/21 Baptiste Daroussin b...@freebsd.org: On Tue, Aug 21, 2012 at 12:09:46AM +0300, Vitaly Magerya wrote: What would be the best practice of mixing ports with packages? There is no best practice for that unfortunatly, (as actually) the best for you is maybe to build your own pkgng repostories? http://wiki.freebsd.org/PkgPrimer#Using_poudriere for example? So, to make it really clear, one should *not* test, try or use pkgng if he wants to continue using ports without setting up a repository ? I did not find a big warning on the wiki. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 21 August 2012 11:37, Olivier Smedts oliv...@gid0.org wrote: 2012/8/21 Baptiste Daroussin b...@freebsd.org: On Tue, Aug 21, 2012 at 12:09:46AM +0300, Vitaly Magerya wrote: What would be the best practice of mixing ports with packages? There is no best practice for that unfortunatly, (as actually) the best for you is maybe to build your own pkgng repostories? http://wiki.freebsd.org/PkgPrimer#Using_poudriere for example? So, to make it really clear, one should *not* test, try or use pkgng if he wants to continue using ports without setting up a repository ? I did not find a big warning on the wiki. You can of course use pkgng with ports-- nothing has changed in that respect; putting WITH_PKGNG=yes into /etc/make.conf makes the ports tree work just fine. It has never been recommended to use packages and ports together. 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: pkgng, textproc/p5-XML-SAX-Expat: Syntax error: { unexpected (expecting then)
From utis...@gmail.com Tue Aug 21 11:32:50 2012
On 21 August 2012 09:47, Anton Shterenlikht me...@bristol.ac.uk wrote:
# cd /usr/ports/textproc/p5-XML-SAX-Expat
# make deinstall make reinstall
=== Deinstalling for textproc/p5-XML-SAX-Expat
=== Deinstalling p5-XML-SAX-Expat-0.40
The following packages will be deinstalled:
p5-XML-SAX-Expat-0.40
The deinstallation will free 22 kB
Deinstalling p5-XML-SAX-Expat-0.40...p5-XML-SAX-Expat-0.40 is
required by: p5-XML-Simple-2.20 icon-naming-utils-0.8.90, deleting anyway
Syntax error: { unexpected (expecting then)
pkg: DEINSTALL script failed
*** [deinstall] Error code 3
Stop in /usr/ports/textproc/p5-XML-SAX-Expat.
# pkg -vvv
version: 1.0-rc6
abi: freebsd:10:ia64:64
db dir: /var/db/pkg
cache dir: /var/cache/pkg
ports dir: /usr/ports
Log into syslog: yes
Assume always yes: no
Handle rc scripts: no
Track shlibs: no
Automatic dependency tracking: no
Custom keywords directory: none
Developer mode: no
Repository: ftp://ftp.freebsd.org/pub/pkgng
#
How long have you had this installed?
Steve Wills [1] fixed the pkg-deinstall script yesterday, but
evidently you still have an older version.
If pkg delete hasn't removed it, try pkg delete -f, then reinstall.
Chris
[1]
http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/p5-XML-SAX-Expat/pkg-deinstall
# svn status -v /usr/ports/textproc/p5-XML-SAX-Expat/pkg-*inst*
302837 302833 swills
/usr/ports/textproc/p5-XML-SAX-Expat/pkg-deinstall
302837 302833 swills
/usr/ports/textproc/p5-XML-SAX-Expat/pkg-install
# pkg delete -f p5-XML-SAX-Expat
The following packages will be deinstalled:
p5-XML-SAX-Expat-0.40
The deinstallation will free 22 kB
Proceed with deinstalling packages [y/N]: y
Deinstalling p5-XML-SAX-Expat-0.40...p5-XML-SAX-Expat-0.40 is required by:
p5-XML-Simple-2.20 icon-naming-utils-0.8.90, deleting anyway
Syntax error: { unexpected (expecting then)
pkg: DEINSTALL script failed
#
Thanks
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: pkgng, textproc/p5-XML-SAX-Expat: Syntax error: { unexpected (expecting then)
on 21/08/2012 12:08 Chris Rees said the following:
On 21 August 2012 09:47, Anton Shterenlikht me...@bristol.ac.uk wrote:
# cd /usr/ports/textproc/p5-XML-SAX-Expat
# make deinstall make reinstall
=== Deinstalling for textproc/p5-XML-SAX-Expat
=== Deinstalling p5-XML-SAX-Expat-0.40
The following packages will be deinstalled:
p5-XML-SAX-Expat-0.40
The deinstallation will free 22 kB
Deinstalling p5-XML-SAX-Expat-0.40...p5-XML-SAX-Expat-0.40 is required by:
p5-XML-Simple-2.20 icon-naming-utils-0.8.90, deleting anyway
Syntax error: { unexpected (expecting then)
pkg: DEINSTALL script failed
*** [deinstall] Error code 3
Stop in /usr/ports/textproc/p5-XML-SAX-Expat.
# pkg -vvv
version: 1.0-rc6
abi: freebsd:10:ia64:64
db dir: /var/db/pkg
cache dir: /var/cache/pkg
ports dir: /usr/ports
Log into syslog: yes
Assume always yes: no
Handle rc scripts: no
Track shlibs: no
Automatic dependency tracking: no
Custom keywords directory: none
Developer mode: no
Repository: ftp://ftp.freebsd.org/pub/pkgng
#
How long have you had this installed?
Steve Wills [1] fixed the pkg-deinstall script yesterday, but
evidently you still have an older version.
Right, but it's hard to upgrade to the new version without deinstalling the old
version, isn't it? :-)
If pkg delete hasn't removed it, try pkg delete -f, then reinstall.
pkg delete -f won't help (as already shown in the original message).
Instead, as Baptiste advised me:
cd /usr/ports/textproc/p5-XML-SAX-Expat
make install FORCE_PKG_REGISTER=1
In the case of pkgng the above command should do the right thing in this case
(in-place upgrade).
[1]
http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/p5-XML-SAX-Expat/pkg-deinstall
--
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: pkgng, textproc/p5-XML-SAX-Expat: Syntax error: { unexpected (expecting then)
On 21 August 2012 12:04, Anton Shterenlikht me...@bristol.ac.uk wrote:
From utis...@gmail.com Tue Aug 21 11:32:50 2012
On 21 August 2012 09:47, Anton Shterenlikht me...@bristol.ac.uk
wrote:
# cd /usr/ports/textproc/p5-XML-SAX-Expat
# make deinstall make reinstall
=== Deinstalling for textproc/p5-XML-SAX-Expat
=== Deinstalling p5-XML-SAX-Expat-0.40
The following packages will be deinstalled:
p5-XML-SAX-Expat-0.40
The deinstallation will free 22 kB
Deinstalling p5-XML-SAX-Expat-0.40...p5-XML-SAX-Expat-0.40 is
required by: p5-XML-Simple-2.20 icon-naming-utils-0.8.90, deleting anyway
Syntax error: { unexpected (expecting then)
pkg: DEINSTALL script failed
*** [deinstall] Error code 3
Stop in /usr/ports/textproc/p5-XML-SAX-Expat.
# pkg -vvv
version: 1.0-rc6
abi: freebsd:10:ia64:64
db dir: /var/db/pkg
cache dir: /var/cache/pkg
ports dir: /usr/ports
Log into syslog: yes
Assume always yes: no
Handle rc scripts: no
Track shlibs: no
Automatic dependency tracking: no
Custom keywords directory: none
Developer mode: no
Repository: ftp://ftp.freebsd.org/pub/pkgng
#
How long have you had this installed?
Steve Wills [1] fixed the pkg-deinstall script yesterday, but
evidently you still have an older version.
If pkg delete hasn't removed it, try pkg delete -f, then reinstall.
Chris
[1]
http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/p5-XML-SAX-Expat/pkg-deinstall
# svn status -v /usr/ports/textproc/p5-XML-SAX-Expat/pkg-*inst*
302837 302833 swills
/usr/ports/textproc/p5-XML-SAX-Expat/pkg-deinstall
302837 302833 swills
/usr/ports/textproc/p5-XML-SAX-Expat/pkg-install
# pkg delete -f p5-XML-SAX-Expat
The following packages will be deinstalled:
p5-XML-SAX-Expat-0.40
The deinstallation will free 22 kB
Proceed with deinstalling packages [y/N]: y
Deinstalling p5-XML-SAX-Expat-0.40...p5-XML-SAX-Expat-0.40 is required by:
p5-XML-Simple-2.20 icon-naming-utils-0.8.90, deleting anyway
Syntax error: { unexpected (expecting then)
pkg: DEINSTALL script failed
#
Hm, bapt was talking about this earlier in IRC... I think if you make
-DFORCE_PKG_REGISTER -C /usr/ports/textproc/p5-XML-SAX-Expat install
clean you should be just fine.
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: pkgng, textproc/p5-XML-SAX-Expat: Syntax error: { unexpected (expecting then)
On 21 August 2012 12:07, Andriy Gapon a...@freebsd.org wrote:
on 21/08/2012 12:08 Chris Rees said the following:
On 21 August 2012 09:47, Anton Shterenlikht me...@bristol.ac.uk wrote:
# cd /usr/ports/textproc/p5-XML-SAX-Expat
# make deinstall make reinstall
=== Deinstalling for textproc/p5-XML-SAX-Expat
=== Deinstalling p5-XML-SAX-Expat-0.40
The following packages will be deinstalled:
p5-XML-SAX-Expat-0.40
The deinstallation will free 22 kB
Deinstalling p5-XML-SAX-Expat-0.40...p5-XML-SAX-Expat-0.40 is required by:
p5-XML-Simple-2.20 icon-naming-utils-0.8.90, deleting anyway
Syntax error: { unexpected (expecting then)
pkg: DEINSTALL script failed
*** [deinstall] Error code 3
Stop in /usr/ports/textproc/p5-XML-SAX-Expat.
# pkg -vvv
version: 1.0-rc6
abi: freebsd:10:ia64:64
db dir: /var/db/pkg
cache dir: /var/cache/pkg
ports dir: /usr/ports
Log into syslog: yes
Assume always yes: no
Handle rc scripts: no
Track shlibs: no
Automatic dependency tracking: no
Custom keywords directory: none
Developer mode: no
Repository: ftp://ftp.freebsd.org/pub/pkgng
#
How long have you had this installed?
Steve Wills [1] fixed the pkg-deinstall script yesterday, but
evidently you still have an older version.
Right, but it's hard to upgrade to the new version without deinstalling the
old
version, isn't it? :-)
D'oh, I forgot that make deinstall using pkg delete -f. Sorry.
If pkg delete hasn't removed it, try pkg delete -f, then reinstall.
pkg delete -f won't help (as already shown in the original message).
Instead, as Baptiste advised me:
cd /usr/ports/textproc/p5-XML-SAX-Expat
make install FORCE_PKG_REGISTER=1
In the case of pkgng the above command should do the right thing in this case
(in-place upgrade).
Glad to see I remembered it correctly in my next message.
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: pkgng, textproc/p5-XML-SAX-Expat: Syntax error: { unexpected (expecting then)
From utis...@gmail.com Tue Aug 21 12:10:39 2012 Instead, as Baptiste advised me: cd /usr/ports/textproc/p5-XML-SAX-Expat make install FORCE_PKG_REGISTER=1 In the case of pkgng the above command should do the right thing in this case (in-place upgrade). Glad to see I remembered it correctly in my next message. Chris yes, this worked fine, thank you 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: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 12:37:26PM +0200, Olivier Smedts wrote: 2012/8/21 Baptiste Daroussin b...@freebsd.org: On Tue, Aug 21, 2012 at 12:09:46AM +0300, Vitaly Magerya wrote: What would be the best practice of mixing ports with packages? There is no best practice for that unfortunatly, (as actually) the best for you is maybe to build your own pkgng repostories? http://wiki.freebsd.org/PkgPrimer#Using_poudriere for example? So, to make it really clear, one should *not* test, try or use pkgng if he wants to continue using ports without setting up a repository ? I did not find a big warning on the wiki. to be clear you can continue to use your system with pkgng the same way you used to use it before with pkg_install. regards, Bapt pgpy8en8NIUJ7.pgp Description: PGP signature
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
Hi Baptise, On Mon, Aug 20, 2012 at 09:43:13PM +0200, Baptiste Daroussin wrote: Since 1.0-rc6 release, everything looks ready for a final release of 1.0, I'll give more details on the release commit bit :) this is planned for 30th august 2012. Current was supposed to switch to pkgng by default today, it has been delayed until the nvidia-driver is fixed with pkgng. Thanksfully kwm@ and danfe@ has been working on this, and the situation should be fixed pretty soon. Please continue testing pkgng and reporting bugs, if you are new comers do not hesitate to ask question about pkgng so that we can improve documentation: The usual links about pkgng: - http://wiki.freebsd.org/pkgng - http://wiki.freebsd.org/PkgPrimer - https://github.com/pkgng/pkgng/blob/master/FAQ.md - http://people.freebsd.org/~bapt/pres-pkgng-bsdcan.pdf - http://www.youtube.com/watch?v=4Hxq7AHZ27I First thank you and all who have worked to make this first release of pkgng. This is a great milestone in FreeBSD history. Supposedly, pkgng will stay opt-in for RELENG_9 and will be the default (opt-out?) on RELENG_10. During the upgrade from the old branch to the new one, how do we ensure users will perform the required step (basically, run pkg2ng) to switch their pkg database to pkgng? Will it be a note in src/UPDATING and as well in the release notes? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 03:26:43PM +0200, Jeremie Le Hen wrote: Hi Baptise, On Mon, Aug 20, 2012 at 09:43:13PM +0200, Baptiste Daroussin wrote: Since 1.0-rc6 release, everything looks ready for a final release of 1.0, I'll give more details on the release commit bit :) this is planned for 30th august 2012. Current was supposed to switch to pkgng by default today, it has been delayed until the nvidia-driver is fixed with pkgng. Thanksfully kwm@ and danfe@ has been working on this, and the situation should be fixed pretty soon. Please continue testing pkgng and reporting bugs, if you are new comers do not hesitate to ask question about pkgng so that we can improve documentation: The usual links about pkgng: - http://wiki.freebsd.org/pkgng - http://wiki.freebsd.org/PkgPrimer - https://github.com/pkgng/pkgng/blob/master/FAQ.md - http://people.freebsd.org/~bapt/pres-pkgng-bsdcan.pdf - http://www.youtube.com/watch?v=4Hxq7AHZ27I First thank you and all who have worked to make this first release of pkgng. This is a great milestone in FreeBSD history. Supposedly, pkgng will stay opt-in for RELENG_9 and will be the default (opt-out?) on RELENG_10. During the upgrade from the old branch to the new one, how do we ensure users will perform the required step (basically, run pkg2ng) to switch their pkg database to pkgng? Will it be a note in src/UPDATING and as well in the release notes? Yes there will be a note in UPDATING, I'm also pondering modifying pkg_* tools to that they show up an advetisement about pkg_install being deprecated. I would also like to just remove pkg_* tools from RELENG_10 if that fits the schedule. regards, Bapt pgprE0wBGH62B.pgp Description: PGP signature
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 08/21/12 17:04, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 07:05:49AM +0100, Matthew Seaman wrote: On 21/08/2012 00:21, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 12:09:46AM +0300, Vitaly Magerya wrote: Baptiste Daroussin b...@freebsd.org wrote: Please [...] ask question about pkgng [...] What would be the best practice of mixing ports with packages? The use case I have in mind is compiling Xorg ports locally WITH_NEW_XORG and WITH_KMS, and using packages from pkgbeta.freebsd.org for everything else. Is there some mixture of pkg and portmaster flags that allows this kind of setup? ___ 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 There is no best practice for that unfortunatly, (as actually) the best for you is maybe to build your own pkgng repostories? http://wiki.freebsd.org/PkgPrimer#Using_poudriere for example? We are open to suggestion here :) At the moment, it is about as tricky as mixing locally compiled ports with pkg_tools packages: ie. it might work, or it might leave you a quivering, sobbing mess lost in a pit of dark despair. One thing that should help is a proposal to record metadata like the SVN revision number of the ports tree used to build repository packages into the repository catalogue (repo.sqlite), so users can in principle check out the same revision locally to build their own ports. Unfortunately no one has written that yet, and its probably too late for it to make it into release-1.0. yes but it should definitly find its way to 1.1! Agreed, though ultimately we want to move to making mixing of ports pkgs idiot-proof - something I suspect we're in better shape to do with pkgng. As a recently minted roadtester of pkgng and wanting to do the same as Vitaly without setting up Poudriere, I had to reverse engineer the ports tree svn revision to make sure I could mix and match from pkgbeta and stuff I built locally via ports with WITH_NEW_XORG and WITH_KMS. This becomes more annoying to manage going forward. So far I'm enjoying my pkgng experience for the most part and wish to thank all those involved in getting it to this stage. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 5:45 PM, Lawrence Stewart lstew...@freebsd.org wrote: On 08/21/12 17:04, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 07:05:49AM +0100, Matthew Seaman wrote: On 21/08/2012 00:21, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 12:09:46AM +0300, Vitaly Magerya wrote: Baptiste Daroussin b...@freebsd.org wrote: Please [...] ask question about pkgng [...] What would be the best practice of mixing ports with packages? The use case I have in mind is compiling Xorg ports locally WITH_NEW_XORG and WITH_KMS, and using packages from pkgbeta.freebsd.org for everything else. Is there some mixture of pkg and portmaster flags that allows this kind of setup? ___ 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 There is no best practice for that unfortunatly, (as actually) the best for you is maybe to build your own pkgng repostories? http://wiki.freebsd.org/PkgPrimer#Using_poudriere for example? We are open to suggestion here :) At the moment, it is about as tricky as mixing locally compiled ports with pkg_tools packages: ie. it might work, or it might leave you a quivering, sobbing mess lost in a pit of dark despair. One thing that should help is a proposal to record metadata like the SVN revision number of the ports tree used to build repository packages into the repository catalogue (repo.sqlite), so users can in principle check out the same revision locally to build their own ports. Unfortunately no one has written that yet, and its probably too late for it to make it into release-1.0. yes but it should definitly find its way to 1.1! Agreed, though ultimately we want to move to making mixing of ports pkgs idiot-proof - something I suspect we're in better shape to do with pkgng. As a recently minted roadtester of pkgng and wanting to do the same as Vitaly without setting up Poudriere, I had to reverse engineer the ports tree svn revision to make sure I could mix and match from pkgbeta and stuff I built locally via ports with WITH_NEW_XORG and WITH_KMS. This becomes more annoying to manage going forward. So far I'm enjoying my pkgng experience for the most part and wish to thank all those involved in getting it to this stage. Cheers, Lawrence What would be needed is a mechanism to query a package repository for a package with both name and options used to compile the package. Let's say you have a port installed that requires another port but that other port must be compiled with a certain option turned on. The packaging system should be able to tell if the package available from the remote repository satisfies the requirements or not. The current system accepts any version of the package because it only looks at the package name. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 6:26 PM, Kimmo Paasiala kpaas...@gmail.com wrote: On Tue, Aug 21, 2012 at 5:45 PM, Lawrence Stewart lstew...@freebsd.org wrote: On 08/21/12 17:04, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 07:05:49AM +0100, Matthew Seaman wrote: On 21/08/2012 00:21, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 12:09:46AM +0300, Vitaly Magerya wrote: Baptiste Daroussin b...@freebsd.org wrote: Please [...] ask question about pkgng [...] What would be the best practice of mixing ports with packages? The use case I have in mind is compiling Xorg ports locally WITH_NEW_XORG and WITH_KMS, and using packages from pkgbeta.freebsd.org for everything else. Is there some mixture of pkg and portmaster flags that allows this kind of setup? ___ 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 There is no best practice for that unfortunatly, (as actually) the best for you is maybe to build your own pkgng repostories? http://wiki.freebsd.org/PkgPrimer#Using_poudriere for example? We are open to suggestion here :) At the moment, it is about as tricky as mixing locally compiled ports with pkg_tools packages: ie. it might work, or it might leave you a quivering, sobbing mess lost in a pit of dark despair. One thing that should help is a proposal to record metadata like the SVN revision number of the ports tree used to build repository packages into the repository catalogue (repo.sqlite), so users can in principle check out the same revision locally to build their own ports. Unfortunately no one has written that yet, and its probably too late for it to make it into release-1.0. yes but it should definitly find its way to 1.1! Agreed, though ultimately we want to move to making mixing of ports pkgs idiot-proof - something I suspect we're in better shape to do with pkgng. As a recently minted roadtester of pkgng and wanting to do the same as Vitaly without setting up Poudriere, I had to reverse engineer the ports tree svn revision to make sure I could mix and match from pkgbeta and stuff I built locally via ports with WITH_NEW_XORG and WITH_KMS. This becomes more annoying to manage going forward. So far I'm enjoying my pkgng experience for the most part and wish to thank all those involved in getting it to this stage. Cheers, Lawrence What would be needed is a mechanism to query a package repository for a package with both name and options used to compile the package. Let's say you have a port installed that requires another port but that other port must be compiled with a certain option turned on. The packaging system should be able to tell if the package available from the remote repository satisfies the requirements or not. The current system accepts any version of the package because it only looks at the package name. By 'any version' I mean 'a package with any combination of options' of course, bad wording. -Kimmo ___ 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: pkg(ng)/portupgrade-devel: does not respect setting of USE_GCC= 4.6+
Am 08/21/12 11:25, schrieb Andrew W. Nosenko: On Mon, Aug 20, 2012 at 10:39 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: I'm pretty sure, that the last time I updated port math/fftw3 I wanted option OpenMP enabled so I declared USE_GCC=4.6+ in make.conf. Later, also working!, I excluded all these user definitions into an external file called ports.conf located in /usr/local/etc (I like this clean separation of OS and user messes ;-) ). Suddenly it doesn't work anymore. There were changes in several Mk files located in /usr/ports/Mk. Beware! Even if you will be able to force gcc-4.6 to be used and thus obtain OpenMP-3.1 at the compilation stage, the libgomp.so.1, which will be used at run-time, will be OpenMP-3.0 from the base gcc-4.2 (/usr/lib/libgomp.so.1 on my FreeBSD-8.0 system). Also, as a bonus, Shouldn't that be /usr/local/lib/gcc46/libgomp.so.1 then? If not, then using a modern and fast compiler like gcc 4.6/4.7 or even 4.8 for OMP is useless on FreeBSD (I use FreeBSD 9.1-PRE and 10.0-CURRENT). you may be exposed to ancient bugs from the gcc-4.2 openmp implementation. For me, personally, it is memory leak as described in http://gcc.gnu.org/ml/gcc/2009-05/msg00427.html Fixed in gcc-4.3, but gcc-4.3 never was nor will be in base. Thus... For obtain the proper openmp you will either limit yourself to openmp-3.0 from gcc-4.2 and workaround known bugs, or make a black magic dance for override and unsteal the libgomp (e.g. using libmap.conf) and have maintenance problem every time when gcc version changes (and, therefore, changes the directory name, where gcc libraries live). Well, I see, here comes the black magic in refering eventually to /usr/local/lib/gcc46/libgomp.so.1. I'm confused now! I try avoiding the lagcy and outdated gcc 4.2. Unfortunatelly, CLANG doesn't support OpenMP (yet), and it is not clear when OpenMP will ever make in in due time into it. I thought, and this seems to be a big mistake and misunderstanding of mine, that USE_GCC=4.6+ will circumvent any problems and even relocated the library paths for compiled software using OpenMP. We use lots of modelling software based upon OpenMP. That would imply if still using USE_GCC=4.6+ to provide OpenMP support will reel in the outdated libgomp.so.1 from the legacy gcc4.2? this is a very bad outlook ... signature.asc Description: OpenPGP digital signature
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 8/21/2012 6:46 AM, Baptiste Daroussin wrote: I would also like to just remove pkg_* tools from RELENG_10 if that fits the schedule. Um, no? Until pkg becomes mandatory (which can't happen for several years) the pkg_* tools can't be removed altogether. What _would_ be useful is what should have been done many years ago when it was first suggested: Move the pkg_* tools to ports. It's too late for 9.1 already, but if you made that change today in HEAD, and after 9.1 (but before 8.4) you MFC it to stable/[89], then you could theoretically make pkg mandatory after 9.1 EOLs. To make my point more clear, the ports tree has to support the last release to ship with pkg_* tools in the base throughout its lifetime. To do anything else would be be a massive POLA violation. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 11:17:36AM -0700, Doug Barton wrote: On 8/21/2012 6:46 AM, Baptiste Daroussin wrote: I would also like to just remove pkg_* tools from RELENG_10 if that fits the schedule. Um, no? Until pkg becomes mandatory (which can't happen for several years) the pkg_* tools can't be removed altogether. What _would_ be useful is what should have been done many years ago when it was first suggested: Move the pkg_* tools to ports. It's too late for 9.1 already, but if you made that change today in HEAD, and after 9.1 (but before 8.4) you MFC it to stable/[89], then you could theoretically make pkg mandatory after 9.1 EOLs. To make my point more clear, the ports tree has to support the last release to ship with pkg_* tools in the base throughout its lifetime. To do anything else would be be a massive POLA violation. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) that is what I meant of course, sorry if I badly said it at first Bapt pgpu5pCBh5GW0.pgp Description: PGP signature
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 11:17 AM, Doug Barton do...@freebsd.org wrote: On 8/21/2012 6:46 AM, Baptiste Daroussin wrote: I would also like to just remove pkg_* tools from RELENG_10 if that fits the schedule. Um, no? ... What _would_ be useful is what should have been done many years ago when it was first suggested: Move the pkg_* tools to ports. It already exists -- it's just out of date / crufty: $ make describe pkg_install-20090902|/usr/ports/ports-mgmt/pkg_install|/usr/local|FreeBSD -STABLE version of the package tools|/usr/ports/ports-mgmt/pkg_install/pkg-descr|port...@freebsd.org|ports-mgmt||http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/pkg_install/ It's too late for 9.1 already, but if you made that change today in HEAD, and after 9.1 (but before 8.4) you MFC it to stable/[89], then you could theoretically make pkg mandatory after 9.1 EOLs. To make my point more clear, the ports tree has to support the last release to ship with pkg_* tools in the base throughout its lifetime. To do anything else would be be a massive POLA violation. Agreed. Thanks, -Garrett ___ 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
Something wrong with mirror.irssi.org? (Was: Re: svn commit: r302888 - head/irc/irssi-devel)
On Tue, 21 Aug 2012 18:48:59 + (UTC), Beat Gaetzi wrote:
Author: beat
Date: Tue Aug 21 18:48:59 2012
New Revision: 302888
URL: http://svn.freebsd.org/changeset/ports/302888
Log:
- Mark BROKEN: size mismatch
fetch: http://mirror.irssi.org/snapshots/irssi-20120624.tar.gz:
size mismatch: expected 1331265, actual 1331625
Reported by: pointyhat
Modified:
head/irc/irssi-devel/Makefile
Modified: head/irc/irssi-devel/Makefile
==
--- head/irc/irssi-devel/Makefile Tue Aug 21 18:46:31 2012
(r302887)
+++ head/irc/irssi-devel/Makefile Tue Aug 21 18:48:59 2012
(r302888)
@@ -16,6 +16,8 @@ COMMENT= A modular IRC client with many
LIB_DEPENDS= glib-2.0:${PORTSDIR}/devel/glib20
+BROKEN=size mismatch
+
CONFLICTS=irssi-0.8*
GNU_CONFIGURE=yes
I've filed this as 170541, but it looks like filesize changes every now
and then (something wrong with mirror.irssi.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: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 8/21/2012 11:47 AM, Garrett Cooper wrote: On Tue, Aug 21, 2012 at 11:17 AM, Doug Barton do...@freebsd.org wrote: On 8/21/2012 6:46 AM, Baptiste Daroussin wrote: I would also like to just remove pkg_* tools from RELENG_10 if that fits the schedule. Um, no? ... What _would_ be useful is what should have been done many years ago when it was first suggested: Move the pkg_* tools to ports. It already exists -- it's just out of date / crufty: Right ... I was using move as shorthand for several different ideas, including but not limited to the latest version of the code itself, robust support for the code going forward, the primary supported way of using pkg_*, etc. All of these ideas have been discussed in the past, so I was hoping to avoid having to re-discuss them. :) It's too late for 9.1 already, but if you made that change today in HEAD, and after 9.1 (but before 8.4) you MFC it to stable/[89], then you could theoretically make pkg mandatory after 9.1 EOLs. To make my point more clear, the ports tree has to support the last release to ship with pkg_* tools in the base throughout its lifetime. To do anything else would be be a massive POLA violation. Agreed. Great (and I saw Baptiste's response on this as well). Glad to hear that we're on the same page about something at least. :) -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 11:47:36AM -0700, Garrett Cooper wrote: On Tue, Aug 21, 2012 at 11:17 AM, Doug Barton do...@freebsd.org wrote: On 8/21/2012 6:46 AM, Baptiste Daroussin wrote: I would also like to just remove pkg_* tools from RELENG_10 if that fits the schedule. Um, no? ... What _would_ be useful is what should have been done many years ago when it was first suggested: Move the pkg_* tools to ports. It already exists -- it's just out of date / crufty: $ make describe pkg_install-20090902|/usr/ports/ports-mgmt/pkg_install|/usr/local|FreeBSD -STABLE version of the package tools|/usr/ports/ports-mgmt/pkg_install/pkg-descr|port...@freebsd.org|ports-mgmt||http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/pkg_install/ It's too late for 9.1 already, but if you made that change today in HEAD, and after 9.1 (but before 8.4) you MFC it to stable/[89], then you could theoretically make pkg mandatory after 9.1 EOLs. To make my point more clear, the ports tree has to support the last release to ship with pkg_* tools in the base throughout its lifetime. To do anything else would be be a massive POLA violation. Agreed. Thanks, -Garrett Let's rephrase the plan: 1/ if it fits the schedule: get rid of pkg_* tools in current to be able to have a fully pkgng only 10-RELEASE 2/ switch 9.2 (the ports tree) to pkgng (but keep pkg_* tools maybe drop them, but that is to be discussed to avoid POLA 3/ do the same for 8 once all of our supported release are fully pkgng aware and all the pkg_* release are EOLed, drop support for pkg_* tools from the ports tree. regards, Bapt pgppZLkb3vyvU.pgp Description: PGP signature
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 8/21/2012 12:05 PM, Baptiste Daroussin wrote: 1/ if it fits the schedule: get rid of pkg_* tools in current to be able to have a fully pkgng only 10-RELEASE I think it would fit better with historic precedents to make pkg optional (but default on) in 10, and mandatory in 11. As stated before, I'm fine with removing pkg_* tools from 10 if there is robust support for them in the ports tree. I know you're excited about this project, but let's not lose sight of how big a change this is, and how important ports are to the project. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 12:38:04PM -0700, Doug Barton wrote: On 8/21/2012 12:05 PM, Baptiste Daroussin wrote: 1/ if it fits the schedule: get rid of pkg_* tools in current to be able to have a fully pkgng only 10-RELEASE I think it would fit better with historic precedents to make pkg optional (but default on) in 10, and mandatory in 11. As stated before, I'm fine with removing pkg_* tools from 10 if there is robust support for them in the ports tree. I know you're excited about this project, but let's not lose sight of how big a change this is, and how important ports are to the project. That was what if it fits the schedule was about. regards, Bapt pgprmJFWctomi.pgp Description: PGP signature
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 8/21/2012 12:42 PM, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 12:38:04PM -0700, Doug Barton wrote: On 8/21/2012 12:05 PM, Baptiste Daroussin wrote: 1/ if it fits the schedule: get rid of pkg_* tools in current to be able to have a fully pkgng only 10-RELEASE I think it would fit better with historic precedents to make pkg optional (but default on) in 10, and mandatory in 11. As stated before, I'm fine with removing pkg_* tools from 10 if there is robust support for them in the ports tree. I know you're excited about this project, but let's not lose sight of how big a change this is, and how important ports are to the project. That was what if it fits the schedule was about. I think what I'm trying to say, ever so politely, is that what you're suggesting isn't even an option, so it shouldn't be discussed. -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Aug 21, 2012, at 1:51 PM, Doug Barton wrote: On 8/21/2012 12:42 PM, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 12:38:04PM -0700, Doug Barton wrote: On 8/21/2012 12:05 PM, Baptiste Daroussin wrote: 1/ if it fits the schedule: get rid of pkg_* tools in current to be able to have a fully pkgng only 10-RELEASE I think it would fit better with historic precedents to make pkg optional (but default on) in 10, and mandatory in 11. As stated before, I'm fine with removing pkg_* tools from 10 if there is robust support for them in the ports tree. I know you're excited about this project, but let's not lose sight of how big a change this is, and how important ports are to the project. That was what if it fits the schedule was about. I think what I'm trying to say, ever so politely, is that what you're suggesting isn't even an option, so it shouldn't be discussed. If you are fine with removing them if there's robust support, how can you also be suggesting that it is impossible and shouldn't be talked about? Personally, I think we should handle this the same way that other replacement tools have been done, which is close to what Baptiste has proposed. If the new tools are totally awesome, we have replaced old tools. If the new tools are good, but don't cover the older users, we develop along size. If they are lame, but somehow get committed anyway, we take 18 years to replace them with bsdinstall. Warner ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 8/21/2012 1:08 PM, Warner Losh wrote: On Aug 21, 2012, at 1:51 PM, Doug Barton wrote: On 8/21/2012 12:42 PM, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 12:38:04PM -0700, Doug Barton wrote: On 8/21/2012 12:05 PM, Baptiste Daroussin wrote: 1/ if it fits the schedule: get rid of pkg_* tools in current to be able to have a fully pkgng only 10-RELEASE I think it would fit better with historic precedents to make pkg optional (but default on) in 10, and mandatory in 11. As stated before, I'm fine with removing pkg_* tools from 10 if there is robust support for them in the ports tree. I know you're excited about this project, but let's not lose sight of how big a change this is, and how important ports are to the project. That was what if it fits the schedule was about. I think what I'm trying to say, ever so politely, is that what you're suggesting isn't even an option, so it shouldn't be discussed. If you are fine with removing them if there's robust support, how can you also be suggesting that it is impossible and shouldn't be talked about? Those address different parts of the problem. Making pkg mandatory in 10 is different from where the old pkg_* tools end up. The command line tools are just the tip of the iceberg, there are a lot of interactions behind the scenes. Personally, I think we should handle this the same way that other replacement tools have been done, which is close to what Baptiste has proposed. If the new tools are totally awesome, we have replaced old tools. I don't think we have ever done a complete replacement of major infrastructure in one release. The traditional model has been to deprecate in one release, remove in the next. And in this case, it doesn't matter how awesome the new tools are, they are a MAJOR paradigm shift for how users interact with ports, and we are going to have a lot of users who take years to transition their installed base. No matter how much we may want to move fast on this, it just isn't going to be possible. If the new tools are good, but don't cover the older users, we develop along size. Yes, this is precisely what I'm saying. Sorry if I wasn't clear. -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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
liblrdf
On FreeBSD 9.0 Release I got: portmaster -a === Gathering distinfo list for installed ports === Starting check of installed ports for available updates === Launching child to update liblrdf-0.4.0_2 to liblrdf-0.5.0 === All liblrdf-0.4.0_2 (1/1) === Currently installed version: liblrdf-0.4.0_2 === Port directory: /usr/ports/textproc/liblrdf === Launching 'make checksum' for textproc/liblrdf in background === No options to configure === Gathering dependency list for textproc/liblrdf from ports === Initial dependency check complete for textproc/liblrdf === Returning to update check of installed ports === Launching child to update p5-Socket-2.005 to p5-Socket-2.006 === All p5-Socket-2.005 (2/2) === Currently installed version: p5-Socket-2.005 === Port directory: /usr/ports/net/p5-Socket === Launching 'make checksum' for net/p5-Socket in background === No options to configure === Gathering dependency list for net/p5-Socket from ports === Initial dependency check complete for net/p5-Socket === Returning to update check of installed ports === All (2) === The following actions will be taken if you choose to proceed: Upgrade liblrdf-0.4.0_2 to liblrdf-0.5.0 Upgrade p5-Socket-2.005 to p5-Socket-2.006 === Proceed? y/n [y] y === Starting build for ports that need updating === === Launching child to install textproc/liblrdf === All textproc/liblrdf (1/2) === Currently installed version: liblrdf-0.4.0_2 === Port directory: /usr/ports/textproc/liblrdf === Starting check for build dependencies === Gathering dependency list for textproc/liblrdf from ports === Dependency check complete for textproc/liblrdf === All liblrdf-0.4.0_2 (1/2) === Cleaning for liblrdf-0.5.0 === Extracting for liblrdf-0.5.0 = SHA256 Checksum OK for liblrdf-0.5.0.tar.gz. === Patching for liblrdf-0.5.0 === liblrdf-0.5.0 depends on file: /usr/local/include/ladspa.h - found === liblrdf-0.5.0 depends on file: /usr/local/bin/automake-1.12 - found === liblrdf-0.5.0 depends on file: /usr/local/bin/autoconf-2.69 - found === liblrdf-0.5.0 depends on package: libtool=2.4 - found === liblrdf-0.5.0 depends on shared library: raptor2 - found === Configuring for liblrdf-0.5.0 /usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG /usr/local/share/aclocal/smpeg.m4:13: run info Automake 'Extending aclocal' /usr/local/share/aclocal/smpeg.m4:13: or see http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal libtoolize: putting auxiliary files in `.'. libtoolize: linking file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: linking file `m4/libtool.m4' libtoolize: linking file `m4/ltoptions.m4' libtoolize: linking file `m4/ltsugar.m4' libtoolize: linking file `m4/ltversion.m4' libtoolize: linking file `m4/lt~obsolete.m4' configure.ac:16: installing './config.guess' configure.ac:16: installing './config.sub' configure.ac:5: installing './install-sh' configure.ac:5: installing './missing' examples/Makefile.am: installing './depcomp' checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gawk... (cached) gawk checking for gcc... cc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of cc... gcc3 checking how to run the C preprocessor... cpp checking whether ln -s works... yes checking whether make sets $(MAKE)... (cached) yes checking build system type... i386-portbld-freebsd9.0 checking host system type... i386-portbld-freebsd9.0 checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by cc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking the maximum length of command line arguments... (cached) 262144 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... no checking how to convert i386-portbld-freebsd9.0 file names to i386-portbld- freebsd9.0 format... func_convert_file_noop checking how to convert i386-portbld-freebsd9.0 file names to toolchain format... func_convert_file_noop checking for
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 1:15 PM, Doug Barton do...@freebsd.org wrote: On 8/21/2012 1:08 PM, Warner Losh wrote: On Aug 21, 2012, at 1:51 PM, Doug Barton wrote: On 8/21/2012 12:42 PM, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 12:38:04PM -0700, Doug Barton wrote: On 8/21/2012 12:05 PM, Baptiste Daroussin wrote: 1/ if it fits the schedule: get rid of pkg_* tools in current to be able to have a fully pkgng only 10-RELEASE I think it would fit better with historic precedents to make pkg optional (but default on) in 10, and mandatory in 11. As stated before, I'm fine with removing pkg_* tools from 10 if there is robust support for them in the ports tree. I know you're excited about this project, but let's not lose sight of how big a change this is, and how important ports are to the project. That was what if it fits the schedule was about. I think what I'm trying to say, ever so politely, is that what you're suggesting isn't even an option, so it shouldn't be discussed. If you are fine with removing them if there's robust support, how can you also be suggesting that it is impossible and shouldn't be talked about? Those address different parts of the problem. Making pkg mandatory in 10 is different from where the old pkg_* tools end up. The command line tools are just the tip of the iceberg, there are a lot of interactions behind the scenes. Personally, I think we should handle this the same way that other replacement tools have been done, which is close to what Baptiste has proposed. If the new tools are totally awesome, we have replaced old tools. I don't think we have ever done a complete replacement of major infrastructure in one release. The traditional model has been to deprecate in one release, remove in the next. And in this case, it doesn't matter how awesome the new tools are, they are a MAJOR paradigm shift for how users interact with ports, and we are going to have a lot of users who take years to transition their installed base. No matter how much we may want to move fast on this, it just isn't going to be possible. What Doug mentioned (and I don't think was really considered, but is valid) would break people that use pkg_* outside of ports. I know of at least two instances where this would be the case (one case that uses pkg_* directly, and another case that uses libpkg from pkg_* 0-o...). I know it's delaying the inevitable (pkg_* is going to go away), but we shouldn't count our chickens before they've hatched as far as how pkgng needs to be used and how things might change. The optional in 8/9/10, mandatory in 11 proposal seems very sane and it allows people to get things worked out properly without too many headaches. Thanks! -Garrett ___ 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: raptor: should there be a note in UPDATING?
Robert Backhaus rob...@robbak.com writes: I just had a problem building liblrdf. The cause was raptor-1 was still installed. Checking UPDATING shows nothing that mentions raptor after the KDE update last November. Does there need to a note in UPDATING to uninstall raptor? It seems more appropriate to fix the port: according to the build log posted in 201208211544.18566.lum...@gmail.com (the other liblrdf thread), -I/usr/local/include is being passed before -I/usr/local/include/raptor2, and it is likely that the source code #includes raptor.h, which is installed by both raptor and raptor2 (albeit into different directories). Someone (TM) should check whether the first include is really necessary, or if the code can't include raptor2/raptor.h, or if -I/usr/local/include/raptor2 can't be passed before -I/usr/local/include. ___ 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: liblrdf
ajtiM lum...@gmail.com writes: === make failed for textproc/liblrdf === Aborting update === Update for textproc/liblrdf failed === Aborting update Please see the other thread about the same issue. ___ 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: raptor: should there be a note in UPDATING?
Raphael Kubo da Costa rak...@freebsd.org writes:
Someone (TM) should check whether the first include is really necessary,
or if the code can't include raptor2/raptor.h, or if
-I/usr/local/include/raptor2 can't be passed before
-I/usr/local/include.
Everything built fine without the {CPP,LD}FLAGS additions here. I'm
tempted to commit that change, but wonder if it will end up breaking
some weird setup...
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, 21 Aug 2012, Doug Barton wrote: I don't think we have ever done a complete replacement of major infrastructure in one release. You mean like sysinstall can be used as an installer on 9 that would do something meaningful with the current infrastructure we provide? -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: Port Request - FrontAccounting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Everyone,
Thanks for all of this info. regarding the port changes that should
be done. I haven't played with the port system in a while so I'm
definitely a bit rusty and I'm sure there have been many changes
(Hence the Apache 2.0 bit... :o!) Anyhow, I had to skip town for a few
days for something EXTREMELY important (golf...) but I will try to get
this fixed and submitted within the next few days.
Thanks again,
Janky Jay, III
On 08/19/2012 04:00 PM, Paul Pathiakis wrote:
My thanks to all of you on this. :-)
P.
*From:* Chris Rees utis...@gmail.com
*To:* Alan Hicks ahi...@p-o.co.uk *Cc:* Janketh Jay
jan...@unfs.us; po...@freebsd.org po...@freebsd.org; Paul
Pathiakis pathia...@yahoo.com *Sent:* Sunday, August 19, 2012
11:06 AM *Subject:* Re: Port Request - FrontAccounting
On 19 August 2012 11:28, Alan Hicks ahi...@p-o.co.uk
mailto:ahi...@p-o.co.uk wrote:
Hi
On 19/08/2012 03:46, Janketh Jay wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
Or not. It appears the attachment was lost. You can download
the .tar.gz file from the following URL:
http://www.purplehat.org/downloads/frontaccounting/frontaccounting-2.3.11-fbsd-port.tar.gz
Extract to ${PORTSDIR}/www and let me know if anything needs to be
changed and/or adjusted
On 08/18/2012 08:42 PM, Janketh Jay wrote:
Hi,
On 08/18/2012 11:53 AM, Paul Pathiakis wrote:
Hi,
This is probably the best competitor to QuickBooks out
there. People can rave about the benefits of GnuCash and
Kmymoney. I've used both and they both lack. This doesn't.
I've also got a pretty good bit of Accounting in my
background. This should definitely be a port.
No, I don't have time. I'm busy trying to build Atlantis
Services and putting FreeBSD and PCBSD into the mainstream.
This is one of those things that will be necessary.
Paul Pathiakis
I've attached a port (in tar.gz form) which is the
FrontAccounting port for FreeBSD. I've tested it a few times
and it seems to work perfectly fine. If someone wants to test
this before I submit, that would be great. Otherwise, I'll
submit some time tomorrow.
Thanks for porting, install works well.
On de-installing before running the install wizard there are
unable to delete errors for www/frontaccounting/config_db.php
www/frontaccounting/config.default.php
Yup, the plist has the correct @unexec and @exec lines, but of
course the @exec lines only apply if installing from a package.
For installation from the port;
post-install: .for conf in config%.php config_db%.php ${CP} -np
${PREFIX}/www/frontaccounting/${conf:S,%,.default} \
${PREFIX}/www/frontaccounting/${conf:S,%,,} .endfor
will do nicely.
After a full install including the web install wizard there are
delete errors for
'/usr/local/www/frontaccounting/config.default.php' doesn't
exist '/usr/local/www/frontaccounting/tmp'
'/usr/local/www/frontaccounting/lang'
'/usr/local/www/frontaccounting/company/0/js_cache'
'/usr/local/www/frontaccounting/company/0'
'/usr/local/www/frontaccounting/company'
'/usr/local/www/frontaccounting'
Perhaps @dirrmtry might be of help
Also unable to build a package as cannot find config_db.php
Trying the usual portmaster reinstall fails to create a backup
package and so has to prompt to ignore the error, the reinstall
succeeds successfully.
Should be a great addition to the ports, Alan
I think these errors can mostly be traced to the missing Makefile
lines :)
Nice job! CC me on your PR.
Chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlA0QycACgkQGK3MsUbJZn5E7wCcDjAUI0AeWeCSaet0iYVtYluT
8OkAni3vzJs1mpfYBSgGHyPM89UwRRwg
=BjyB
-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
FreeBSD Port: ports-mgmt/porttools - Update to work with svn
Hi,
I did a quick hack to make porttools work with svn. It's far from perfect, but
it makes port submit work for me. It's available here:
http://meatwad.mouf.net/~steve/porttools_svn.diff
and attached. If anyone wants to finish it up, that'd be cool.
Steve
--- /usr/local/share/porttools/cmd_commit 2012-08-21 21:56:45.062006082
-0400
+++ /usr/local/share/porttools/cmd_commit.orig 2012-08-21 21:51:52.437009531
-0400
@@ -28,7 +28,7 @@
#
# cmd_commit
# Module for port(1)
-# SUMMARY: commit a port into the FreeBSD Ports SVN Repository
+# SUMMARY: commit a port into the FreeBSD Ports CVS Repository
#
# $Id: cmd_commit.in,v 1.2 2009/09/09 19:58:30 skolobov Exp $
#
@@ -93,7 +93,7 @@
echo === Pre-commit portlint check
FLAGS=-C
[ ${MODE} = new ] FLAGS=${FLAGS} -N
-PL_SVN_IGNORE='^\d+$|^pr-patch$|^svn-msg$' \
+PL_CVS_IGNORE='^\d+$|^pr-patch$|^cvs-msg$' \
portlint ${FLAGS}
if [ $? -ne 0 ]
then
@@ -107,15 +107,15 @@
then
${PORTSDIR}/Tools/scripts/addport -d `pwd` -u ${FREEFALL_USERNAME}
else
- # Initialize SVN environment
- PSVN=${PORTSDIR}/Tools/scripts/psvn
+ # Initialize CVS environment
+ PCVS=cvs -d ${FREEFALL_USERNAME}@pcvs.FreeBSD.org:/home/pcvs
# Make sure we are working with up-to-date version
- echo === Pre-commit SVN update
- ${PSVN} update
+ echo === Pre-commit CVS update
+ ${PCVS} update
- # See if SVN message already exists, and use that for commit log
- MSG=svn-msg
+ # See if CVS message already exists, and use that for commit log
+ MSG=cvs-msg
FLAGS=
if [ -e ${MSG} ]
then
@@ -127,16 +127,16 @@
echo '='
cat ${MSG}
echo '='
- read -p Is the SVN message above correct? (y/n) ANSWER
+ read -p Is the CVS message above correct? (y/n) ANSWER
[ ${ANSWER} = y ] break
${VISUAL:-vi} ${MSG}
done
fi
# Commit the port update
echo === Committing port update
- ${PSVN} commit ${FLAGS}
+ ${PCVS} commit ${FLAGS}
- # Remove SVN message file only if commit was successful
+ # Remove CVS message file only if commit was successful
[ $? -eq 0 -a -e ${MSG} ] rm ${MSG}
fi
--- /usr/local/share/porttools/cmd_diff 2012-08-21 21:57:52.520007848 -0400
+++ /usr/local/share/porttools/cmd_diff.orig2012-08-21 21:51:52.443006550
-0400
@@ -48,8 +48,8 @@
Usage: port diff [-h] [-d diff mode]
-h - Display this usage summary
-d diff mode - Select diff generation mode:
- SVN - against SVN
- SVNauto - against SVN, no svn add/delete required
+ CVS - against CVS
+ CVSauto - against CVS, no cvs add/delete required
dir - against Ports tree in dir
pattern - against original port in pwdpattern
EOF
--- /usr/local/share/porttools/cmd_submit 2012-08-21 21:59:42.875411346
-0400
+++ /usr/local/share/porttools/cmd_submit.orig 2012-08-21 21:51:52.449007838
-0400
@@ -53,8 +53,8 @@
change - changing a port
update - updating a port to newer version
-d diff mode - Select diff generation mode:
- SVN - against SVN
- SVNauto - against SVN, no svn add/delete required
+ CVS - against CVS
+ CVSauto - against CVS, no cvs add/delete required
dir - against Ports tree in dir
pattern - against original port in pwdpattern
-s severity - Set PR's severity to severity
@@ -163,7 +163,7 @@
# util_diff will set
# - PORTBASENAME if PORTNAME != port's directory name
-# - DIFF_TYPE to SVN, SVNauto, ports, or suffix
+# - DIFF_TYPE to CVS, CVSauto, ports, or suffix
PORTBASENAME=
DIFF_TYPE=
@@ -183,12 +183,12 @@
else
cat ${TEMPROOT}/.portlint.out
echo Error validating port
- if [ $DIFF_MODE = SVNauto ]
+ if [ $DIFF_MODE = CVSauto ]
then
grep ^FATAL: ${TEMPROOT}/.portlint.out
${TEMPROOT}/.portlint.fatal
- if ! egrep -qv '^FATAL:[[:space:]]+(file .+ not in
SVN|SVN file .+ missing)' ${TEMPROOT}/.portlint.fatal
+ if ! egrep -qv '^FATAL:[[:space:]]+(file .+ not in
CVS|CVS file .+ missing)' ${TEMPROOT}/.portlint.fatal
then
- echo All fatal portlint errors are SVN errors,
+ echo All fatal portlint errors are CVS errors,
echo consider using portlint without the -c
flag or
echo use 'port submit -L' if all portlint
messages are
Re: FreeBSD Port: ports-mgmt/porttools - Update to work with svn
On Tue, Aug 21, 2012 at 10:35 PM, Steve Wills swi...@freebsd.org wrote: Hi, I did a quick hack to make porttools work with svn. It's far from perfect, but it makes port submit work for me. It's available here: http://meatwad.mouf.net/~steve/porttools_svn.diff It looks like the diff might be reversed ___ 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: ports-mgmt/porttools - Update to work with svn
Yes, sorry, see attached. URL updated...
Steve
On Aug 21, 2012, at 10:41 PM, Steven Kreuzer wrote:
On Tue, Aug 21, 2012 at 10:35 PM, Steve Wills swi...@freebsd.org wrote:
Hi,
I did a quick hack to make porttools work with svn. It's far from perfect,
but it makes port submit work for me. It's available here:
http://meatwad.mouf.net/~steve/porttools_svn.diff
It looks like the diff might be reversed
___
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
--- /usr/local/share/porttools/cmd_commit 2012-08-21 21:56:45.062006082
-0400
+++ /usr/local/share/porttools/cmd_commit.orig 2012-08-21 21:51:52.437009531
-0400
@@ -28,7 +28,7 @@
#
# cmd_commit
# Module for port(1)
-# SUMMARY: commit a port into the FreeBSD Ports SVN Repository
+# SUMMARY: commit a port into the FreeBSD Ports CVS Repository
#
# $Id: cmd_commit.in,v 1.2 2009/09/09 19:58:30 skolobov Exp $
#
@@ -93,7 +93,7 @@
echo === Pre-commit portlint check
FLAGS=-C
[ ${MODE} = new ] FLAGS=${FLAGS} -N
-PL_SVN_IGNORE='^\d+$|^pr-patch$|^svn-msg$' \
+PL_CVS_IGNORE='^\d+$|^pr-patch$|^cvs-msg$' \
portlint ${FLAGS}
if [ $? -ne 0 ]
then
@@ -107,15 +107,15 @@
then
${PORTSDIR}/Tools/scripts/addport -d `pwd` -u ${FREEFALL_USERNAME}
else
- # Initialize SVN environment
- PSVN=${PORTSDIR}/Tools/scripts/psvn
+ # Initialize CVS environment
+ PCVS=cvs -d ${FREEFALL_USERNAME}@pcvs.FreeBSD.org:/home/pcvs
# Make sure we are working with up-to-date version
- echo === Pre-commit SVN update
- ${PSVN} update
+ echo === Pre-commit CVS update
+ ${PCVS} update
- # See if SVN message already exists, and use that for commit log
- MSG=svn-msg
+ # See if CVS message already exists, and use that for commit log
+ MSG=cvs-msg
FLAGS=
if [ -e ${MSG} ]
then
@@ -127,16 +127,16 @@
echo '='
cat ${MSG}
echo '='
- read -p Is the SVN message above correct? (y/n) ANSWER
+ read -p Is the CVS message above correct? (y/n) ANSWER
[ ${ANSWER} = y ] break
${VISUAL:-vi} ${MSG}
done
fi
# Commit the port update
echo === Committing port update
- ${PSVN} commit ${FLAGS}
+ ${PCVS} commit ${FLAGS}
- # Remove SVN message file only if commit was successful
+ # Remove CVS message file only if commit was successful
[ $? -eq 0 -a -e ${MSG} ] rm ${MSG}
fi
--- /usr/local/share/porttools/cmd_diff 2012-08-21 21:57:52.520007848 -0400
+++ /usr/local/share/porttools/cmd_diff.orig2012-08-21 21:51:52.443006550
-0400
@@ -48,8 +48,8 @@
Usage: port diff [-h] [-d diff mode]
-h - Display this usage summary
-d diff mode - Select diff generation mode:
- SVN - against SVN
- SVNauto - against SVN, no svn add/delete required
+ CVS - against CVS
+ CVSauto - against CVS, no cvs add/delete required
dir - against Ports tree in dir
pattern - against original port in pwdpattern
EOF
--- /usr/local/share/porttools/cmd_submit 2012-08-21 21:59:42.875411346
-0400
+++ /usr/local/share/porttools/cmd_submit.orig 2012-08-21 21:51:52.449007838
-0400
@@ -53,8 +53,8 @@
change - changing a port
update - updating a port to newer version
-d diff mode - Select diff generation mode:
- SVN - against SVN
- SVNauto - against SVN, no svn add/delete required
+ CVS - against CVS
+ CVSauto - against CVS, no cvs add/delete required
dir - against Ports tree in dir
pattern - against original port in pwdpattern
-s severity - Set PR's severity to severity
@@ -163,7 +163,7 @@
# util_diff will set
# - PORTBASENAME if PORTNAME != port's directory name
-# - DIFF_TYPE to SVN, SVNauto, ports, or suffix
+# - DIFF_TYPE to CVS, CVSauto, ports, or suffix
PORTBASENAME=
DIFF_TYPE=
@@ -183,12 +183,12 @@
else
cat ${TEMPROOT}/.portlint.out
echo Error validating port
- if [ $DIFF_MODE = SVNauto ]
+ if [ $DIFF_MODE = CVSauto ]
then
grep ^FATAL: ${TEMPROOT}/.portlint.out
${TEMPROOT}/.portlint.fatal
- if ! egrep -qv '^FATAL:[[:space:]]+(file .+ not in
SVN|SVN file .+ missing)' ${TEMPROOT}/.portlint.fatal
+ if ! egrep -qv '^FATAL:[[:space:]]+(file .+ not in
CVS|CVS file .+ missing)' ${TEMPROOT}/.portlint.fatal
