[FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
There comes a time in the life cycle of just about every software package that it has bee re-evaluated, refreshed, deprecated or just retired. It is time that we bid farewell to the old pkg_* software that has been part of FreeBSD since the beginning, and has served us well. After years of development, testing, and playing, pkg(8) has become a suitable replacement. Pkg is the Next Generation package management tool for FreeBSD. It is the replacement for the current pkg_info/pkg_create/pkg_add tools that ports use to register local packages and which provide remote packages. Its main goals are to facilitate remote binary package upgrades. It also works with ports without remote binary packages. Pkg, combined with the quarterly release package sets, enables easy installation and safe upgrades for binary packages. Signed, binary packages are available for all supported FreeBSD releases on the i386 and amd64 platforms from pkg.freebsd.org. Additionally, for those compiling ports from source, pkg's new database format gives more fine-grained querying and management of installed software. New features on the drawing board, like automatic pkg-plist generation, sub-packages, creating multiple packages containing different parts of a port from one build process, and flavours, being able to ask for e.g. a webserver, without directly specifying a specific one, cannot be implemented in the old pkg_* tools and those plans are currently on hold. You are not obligated to switch to binary packages, if you still prefer to compile your own ports, it is a simple matter of installing ports-mgmt/pkg, run pkg2ng, add WITH_PKGNG=yes to your make.conf and use pkg action instead of pkg_action. You can read more about pkgng on the FreeBSD wiki, https://wiki.freebsd.org/pkgng. The decision has been made to allow the old pkg_* software to be EoL'd 6 months from now, at September 1, 2014 in all active FreeBSD branches. Please start testing pkg(8) in your test environments before taking it live, you will find the benefits of full binary updates for your ports to be beneficial in a very short amount of time. Even if you prefer to compile from source, you will still reap the benefits of the modern packaging system. http://blogs.freebsdish.org/portmgr/2014/02/03/time-to-bid-farewell-to-the-old-pkg_-tools/ ___ freebsd-ports-announce@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports-announce To unsubscribe, send any mail to freebsd-ports-announce-unsubscr...@freebsd.org
Re: [Upgrade to FreeBSD10] hplip issue
On 03.02.2014 01:18, Scot Hetzel wrote: On Sat, Feb 1, 2014 at 4:14 AM, David Marec david.ma...@davenulle.org wrote: I don't know why this file was not updated during the hplip installation. [...] if there were any changes to hplip.conf file, it doesn't get removed when the port is uninstalled. And if the file exists, it won't overwrite your changes. Did you customize this file before you re-installed? No. But I guess this file wasn't removed when I requested the deletion of all the ports using 'pkg delete', once FreeBSD was upgraded. But, at that time, the scanning switch was enabled in the file. Does the hplip.conf.sample file have scanner-build=yes? The only difference is the line I set up to fix the issue, after the (re)installation: david:/1local/etc/hpdiff hplip.conf hplip.conf.sample 25c25 scanner-build=yes --- scanner-build=no -- David Marec ___ 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: bsd.apache.mk Malformed conditional when APACHE_VERSION defined
On 2/02/2014 9:51 PM, olli hauer wrote:
On 2014-02-02 10:11, Dewayne Geraghty wrote:
I filed a PR against textproc/htdig which should really be against the
ports systems.
Would someone be kind enough to advise the current method to specify the
apache version. In ports.conf, I currently use
USE_APACHE=22 | APACHE_VERSION=22
to specify the required version of apache for:
textproc/htdig
www/mod_security
lang/php5
I believe this PR
http://www.freebsd.org/cgi/query-pr.cgi?pr=186364
which probably should be routed to the ports system, and not textproc/htdig
The error is:
cd /usr/ports/textproc/htdig make -V UNIQUENAME
/usr/ports/Mk/bsd.apache.mk, line 306: warning: String comparison
operator should be either == or !=
/usr/ports/Mk/bsd.apache.mk, line 306: Malformed conditional
(!empty(_APACHE_VERSION_MINIMUM) (${_APACHE_VERSION}
${_APACHE_VERSION_MINIMUM}))
/usr/ports/Mk/bsd.port.mk, line 6603: if-less endif
make: fatal errors encountered -- cannot continue
which goes away if APACHE_VERSION isn't used, eg.
cd /usr/ports/textproc/htdig make __MAKE_CONF=/dev/null -V UNIQUENAME
htdig
Hi Dewayne,
APACHE_VERSION is a read only variable in case a port needs to know the
installed / default Apache version - do not set this variable!
In case you want to specify a default apache use in etc/make.conf for example
APACHE_PORT=www/apache22
See lines 12 - 25 in Mk/bsd.apache.mk
Olli,
Thank-you for pointing me to the right place. I've removed
APACHE_VERSION=22;
but noted that
PERL_VERSION=5.16.3 | PYTHON_VERSION=python2.7
remain valid, which maintains my confusion.
With the ongoing changes to the ports system, I've also retained this line in
make.conf
DEFAULT_VERSIONS=perl5=5.16 python=2.7 python2=2.7 apache=22
Though I suspect that using the latter is preferred and should be the stable
way of constricting versions?
The last rebuild of all ports occurred on Jan 20, strange that
APACHE_VERSION=22 didn't halt that rebuild cycle, as bsd.apache.mk has been
changed for 2 months... One of life's mysteries.
Regards, Dewayne.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ games/doomsday | 1.12.2 | 1.14.0-build1129 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Current unassigned ports problem reports
(Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .) The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description f ports/186403devel/gdb 7.6.1_1 internal error attaching to process f ports/186402net/delegate can't compile o ports/186399www/shellinabox : Fix issue regarding some keys with F f ports/186386sysutils/logstash on FreeBSD10 does not build due to j o ports/186384[patch] [maintainer update] net/turnserver port upgrad o ports/186381fix sysutils/spindown compile errors with clang o ports/186374[maintainer] audio/teamspeak3-server 3.0.10.1 - 3.0.1 f ports/186372[UPDATE] ports-mgmt/porttools: update to 1.00.2014.02. f ports/186358net/owncloud-csync ocsync binary missing f ports/186355devel/otrs: unnecessary dependency on www/apache22 o ports/186344sysutils/cbsd update to 10.0.2 o ports/186340[MAINTAINER] Update devel/libcidr to 1.2.3 f ports/186339devel/fuel add STAGE support f ports/186337editors/gummi add STAGE support f ports/186335sysutils/scalpel - STAGEify f ports/186332fix install path of the binary in sysutils/xmbmon o ports/186324[NEW PORT] net-p2p/feathercoin o ports/186310update sysutils/procenv to version 0.32 o ports/186308[MAINTAINER] dns/nsd: update to 4.0.1 o ports/186307[MAINTAINER] dns/nsd3: update to 3.2.17 f ports/186301dns/bind10 can not build f ports/186292[PATCH] ports-mgmt/porttools: Add template to cmd_subm o ports/186283[NEW PORT] www/pecl-varnish: Varnish cache extension o ports/186272Incorrect application of CPPFLAGS for games/angband ca o docs/186269 sysutils/qjail: finding typo in qjail-howto(8) f ports/186264[PATCH] missing manual in security/strongswan f ports/186262finance/openerp-server port is non-functional as shipp o ports/186234www/woof: port upgrade to native Python 2.7 compliant o ports/186226[NEW PORT] math/pecl-trader: Trader extension based on f ports/186219net-mgmt/libsmi - Clang / GCC issue f ports/186216[PATCH] japanese/libskk: switch to USE_GNOME=introspec f ports/186197[PATCH] devel/librest: fix gobject-introspection depen f ports/186196[PATCH] converters/gbsdconv: fix depend on gobject-int o ports/186188textproc/xalan-c: MsgFileOutputStream.hpp:106:13: erro f ports/186186textproc/the_silver_searcher: Upgrade port for The Sil f ports/186184audio/teamspeak3-server port broken on freeBSD 10 o ports/186179databases/gtksql 0.4.5 fails make o ports/186172can't install net/poptop with KERNPPP=on f ports/186161print/latex-aa: Maintainer update to fix uncompilabili o ports/186160graphics/ImageMagick does not detect freetype2 properl f ports/186141stage problem with x11-toolkits/tix f ports/186140[PATCH] net/bwping update to 1.7 f ports/186134sysutils/coreutils build, fails due to strip of sh ( o ports/186127net/pimdd remove GCC deps, stagify and fix RAW socket f ports/186103sysutils/cbsd - dangerous and unexpected initializatio o ports/186100net/pload: fix man page installation o ports/186098[MAINTAINER] security/softhsm: [SUMMARIZE CHANGES] o ports/186094A database lib/X11/fonts/local/fonts.alias conflicts i f ports/186091[MAINTAINER UPDATE] net-p2p/bitmessage o ports/186071mail/prayer deprecated dependencies o ports/186065[update] audio/libamrnb and audio/libamrwb f ports/186063[PATCH] www/validator: add 'USES=shebangfix' to adjust o ports/186062[maintainer] [patch] sysutils/ansible : speed up ssh m o ports/186059[PATCH] dns/publicsuffix update to 1.04 o ports/186056New port: databases/cassandra2 The latest stable relea f ports/186054x11-fonts/fira: Download from somewhere else? o ports/186046x11/dgs : fix build with current texinfo f ports/186025[patch] security/tinyca: add support for openssl 1.0.1 f ports/186008[patch] audio/shoutcast update 2.2.1.109 o ports/186001devel/opencl: Upstream changes of the header files by f ports/185982[PATCH] net-im/centerim: fix build on 10.x, staging f ports/185981[PATCH] net-im/centerim-devel: fix build on 10.x, stag f ports/185973mail/mailfront patch - update to
Re: Sage update
On Monday 03 February 2014 02:16:07 Montgomery-Smith, Stephen wrote: On 01/29/2014 07:26 PM, Montgomery-Smith, Stephen wrote: On 01/29/2014 07:00 PM, Montgomery-Smith, Stephen wrote: I have just updated sage to version 6.0. I have also made some changes to help it work with FreeBSD-10, using ideas given to me by Daniel Smith. Since I don't have a fast computer using FreeBSD-10, I would appreciate it if any of you guys could try it out and see if it works. I meant math/sage (for those who don't normally use it.) A few days ago I updated to sage-6.1. But I don't expect it to work any better on FreeBSD-10 than sage-6.0. It stopped early on FreeBSD 10.0-RELEASE (amd64): === Applying FreeBSD patches for sage-6.1 /usr/bin/sed -i.bak 's/$MAKE $gettext/$MAKE PTHREAD_LIBS=-pthread $gettext/' /usr/ports/math/sage/work/sage-6.1/build/pkgs/git/spkg-install === sage-6.1 depends on executable: bash - found === sage-6.1 depends on executable: convert - found === sage-6.1 depends on executable: ffmpeg - found === sage-6.1 depends on file: /usr/local/share/texmf-dist/LICENSE.texmf - found === sage-6.1 depends on executable: mktexlsr - found === sage-6.1 depends on executable: gmake - found === sage-6.1 depends on executable: gcc46 - found === sage-6.1 depends on file: /usr/local/bin/as - found === sage-6.1 depends on file: /usr/local/bin/autoconf-2.69 - found === sage-6.1 depends on shared library: atlas - found === sage-6.1 depends on shared library: lapack - found === sage-6.1 depends on shared library: jpeg - found === sage-6.1 depends on shared library: tk86 - found === Configuring for sage-6.1 === FreeBSD 10 autotools fix applied to /usr/ports/math/sage/work/sage-6.1/build/pkgs/cddlib/patches/autogenerated/aclocal.m4 === FreeBSD 10 autotools fix applied to /usr/ports/math/sage/work/sage-6.1/build/pkgs/cddlib/patches/autogenerated/configure === FreeBSD 10 autotools fix applied to /usr/ports/math/sage/work/sage-6.1/build/pkgs/cddlib/patches/autogenerated/m4/libtool.m4 === FreeBSD 10 autotools fix applied to /usr/ports/math/sage/work/sage-6.1/configure === Building for sage-6.1 gmake[2]: Entering directory `/usr/ports/math/sage/work/sage-6.1' mkdir -p logs cd build \ ../build/pipestatus \ env SAGE_PARALLEL_SPKG_BUILD='' ./install all 21 \ tee -a ../logs/install.log *** ALL ENVIRONMENT VARIABLES BEFORE BUILD: *** .MAKE.LEVEL.ENV=MAKELEVEL ADDR2LINE=/usr/local/bin/addr2line AR=/usr/local/bin/ar ARCH=/usr/local/bin/ar AS=/usr/local/bin/as AUTOCONF=/usr/local/bin/autoconf-2.69 AUTOCONF_DIR=/usr/local/share/autoconf-2.69 AUTOCONF_VERSION=2.69 AUTOHEADER=/usr/local/bin/autoheader-2.69 AUTOIFNAMES=/usr/local/bin/ifnames-2.69 AUTOM4TE=/usr/local/bin/autom4te-2.69 AUTORECONF=/usr/local/bin/autoreconf-2.69 AUTOSCAN=/usr/local/bin/autoscan-2.69 AUTOUPDATE=/usr/local/bin/autoupdate-2.69 BLOCKSIZE=K BSD_INSTALL_DATA=install -o root -g wheel -m 444 BSD_INSTALL_LIB=install -s -o root -g wheel -m 444 BSD_INSTALL_MAN=install -o root -g wheel -m 444 BSD_INSTALL_PROGRAM=install -s -o root -g wheel -m 555 BSD_INSTALL_SCRIPT=install -o root -g wheel -m 555 CC=gcc46 CFLAGS=-pipe -Wl,-rpath=/usr/ports/math/sage/work/sage-6.1/local/lib -Wl,-rpath=/usr/local/lib/gcc46 COLORFGBG=0;15 CONFIG_DONE_SAGE=1 CPP=cpp46 CPPFILT=/usr/local/bin/c++filt CPPFLAGS= CXX=g++46 CXXFLAGS=-pipe -Wl,-rpath=/usr/ports/math/sage/work/sage-6.1/local/lib -Wl,-rpath=/usr/local/lib/gcc46 -Wl,-rpath=/usr/ports/math/sage/work/sage-6.1/local/lib -Wl,-rpath=/usr/local/lib/gcc46 DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus-KBfRYwQL5q,guid=afd63add35fdc424839ac6cb52ee371c DISPLAY=:0 DISPLAY_LIST= DISTDIR=/usr/ports/distfiles/ DI_FILES=/tmp/f-9154-DI-FILES.aBfV0Ix1 DOT_SAGE=/usr/ports/math/sage/work/sage-6.1/tmp/.sage EDITOR=vi F77=gfortran46 FFLAGS=-pipe -Wl,-rpath=/usr/ports/math/sage/work/sage-6.1/local/lib -Wl,-rpath=/usr/local/lib/gcc46 GPROF=/usr/local/bin/gprof GROUP=ajtim GS_LIB=/home/ajtim/.fonts GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/ajtim/.gtkrc-2.0:/usr/home/ajtim/.kde4/share/config/gtkrc-2.0 GTK_RC_FILES=/etc/gtk/gtkrc:/home/ajtim/.gtkrc:/usr/home/ajtim/.kde4/share/config/gtkrc HOME=/root HOST=lumiwa.farms.net HOSTTYPE=FreeBSD IPC_SAVE=/tmp/f-9154-IPC_SAVE.UX4FqcVf KDE_FULL_SESSION=true KDE_MULTIHEAD=false KDE_SESSION_UID=1001 KDE_SESSION_VERSION=4 KONSOLE_DBUS_SERVICE=:1.148 KONSOLE_DBUS_SESSION=/Sessions/1 KONSOLE_DBUS_WINDOW=/Windows/1 KONSOLE_PROFILE_NAME=Shell LANGUAGE= LD=/usr/local/bin/ld LDFLAGS=-Wl,-rpath=/usr/ports/math/sage/work/sage-6.1/local/lib -Wl,-rpath=/usr/local/lib/gcc46 -L/usr/local/lib/gcc46 LIBDIR=/usr/lib LOCALBASE=/usr/local LOCALBASE_COMPAT=/usr/local/lib/compat/pkg LOGNAME=ajtim MACHTYPE=x86_64 MAIL=/var/mail/ajtim MAKE=/usr/bin/make -j8 MAKEFLAGS=w --jobserver-fds=3,4 -j -- SYSTEMVERSION= OSVERSION=1000510 OSREL=10.0 OPSYS=FreeBSD CONFIG_DONE_SAGE=1 ARCH=/usr/local/bin/ar .MAKE.LEVEL.ENV=MAKELEVEL MAKELEVEL=3
Re: [Upgrade to FreeBSD10] hplip issue
On Mon, Feb 3, 2014 at 12:54 AM, David Marec david.ma...@davenulle.org wrote: On 03.02.2014 01:18, Scot Hetzel wrote: On Sat, Feb 1, 2014 at 4:14 AM, David Marec david.ma...@davenulle.org wrote: I don't know why this file was not updated during the hplip installation. [...] if there were any changes to hplip.conf file, it doesn't get removed when the port is uninstalled. And if the file exists, it won't overwrite your changes. Did you customize this file before you re-installed? No. But I guess this file wasn't removed when I requested the deletion of all the ports using 'pkg delete', once FreeBSD was upgraded. But, at that time, the scanning switch was enabled in the file. Does the hplip.conf.sample file have scanner-build=yes? The only difference is the line I set up to fix the issue, after the (re)installation: david:/1local/etc/hpdiff hplip.conf hplip.conf.sample 25c25 scanner-build=yes --- scanner-build=no I checked the work/hplip-3.14.1/hplip.conf file that was generated during the 'make configure' phase and it shows that scanner-build is set to yes when the SCAN option is selected. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[QAT] r342404: 4x leftovers, 12x success
- Stage support - Build ID: 20140203094800-14535 Job owner: m...@freebsd.org Buildtime: 7 hours Enddate: Mon, 03 Feb 2014 17:11:14 GMT Revision: r342404 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=342404 - Port:editors/cooledit 3.17.17_5 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140203094800-14535-269128/cooledit-3.17.17_5.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140203094800-14535-269129/cooledit-3.17.17_5.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140203094800-14535-269130/cooledit-3.17.17_5.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140203094800-14535-269131/cooledit-3.17.17_5.log - Port:editors/pico-alpine 2.00_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140203094800-14535-269132/pico-alpine-2.00_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140203094800-14535-269133/pico-alpine-2.00_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140203094800-14535-269134/pico-alpine-2.00_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140203094800-14535-269135/pico-alpine-2.00_1.log - Port:games/gnugo 3.8 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140203094800-14535-269136/gnugo-3.8.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140203094800-14535-269137/gnugo-3.8.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140203094800-14535-269138/gnugo-3.8.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140203094800-14535-269139/gnugo-3.8.log - Port:math/cln 1.3.2 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140203094800-14535-269140/cln-1.3.2.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140203094800-14535-269141/cln-1.3.2.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140203094800-14535-269142/cln-1.3.2.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140203094800-14535-269143/cln-1.3.2.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140203094800-14535 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[QAT] r342463: 1x leftovers, 3x success
Allow staging as a regular user - Build ID: 20140203181000-36745 Job owner: anto...@freebsd.org Buildtime: 8 minutes Enddate: Mon, 03 Feb 2014 18:17:38 GMT Revision: r342463 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=342463 - Port:sysutils/fusefs-kmod 0.3.9.p1.20080208_11 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~anto...@freebsd.org/20140203181000-36745-269556/fusefs-kmod-0.3.9.p1.20080208_11.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~anto...@freebsd.org/20140203181000-36745-269557/fusefs-kmod-0.3.9.p1.20080208_11.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~anto...@freebsd.org/20140203181000-36745-269558/fusefs-kmod-0.3.9.p1.20080208_11.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~anto...@freebsd.org/20140203181000-36745-269559/fusefs-kmod-0.3.9.p1.20080208_11.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140203181000-36745 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Time to bid farewell to the old pkg_ tools
There comes a time in the life cycle of just about every software package that it has bee re-evaluated, refreshed, deprecated or just retired. It is time that we bid farewell to the old pkg_* software that has been part of FreeBSD since the beginning, and has served us well. After years of development, testing, and playing, pkg(8) has become a suitable replacement. Pkg is the Next Generation package management tool for FreeBSD. It is the replacement for the current pkg_info/pkg_create/pkg_add tools that ports use to register local packages and which provide remote packages. Its main goals are to facilitate remote binary package upgrades. It also works with ports without remote binary packages. Pkg, combined with the quarterly release package sets, enables easy installation and safe upgrades for binary packages. Signed, binary packages are available for all supported FreeBSD releases on the i386 and amd64 platforms from pkg.freebsd.org. Additionally, for those compiling ports from source, pkg's new database format gives more fine-grained querying and management of installed software. New features on the drawing board, like automatic pkg-plist generation, sub-packages, creating multiple packages containing different parts of a port from one build process, and flavours, being able to ask for e.g. a webserver, without directly specifying a specific one, cannot be implemented in the old pkg_* tools and those plans are currently on hold. You are not obligated to switch to binary packages, if you still prefer to compile your own ports, it is a simple matter of installing ports-mgmt/pkg, run pkg2ng, add WITH_PKGNG=yes to your make.conf and use pkg action instead of pkg_action. You can read more about pkgng on the FreeBSD wiki, https://wiki.freebsd.org/pkgng. The decision has been made to allow the old pkg_* software to be EoL'd 6 months from now, at September 1, 2014 in all active FreeBSD branches. Please start testing pkg(8) in your test environments before taking it live, you will find the benefits of full binary updates for your ports to be beneficial in a very short amount of time. Even if you prefer to compile from source, you will still reap the benefits of the modern packaging system. http://blogs.freebsdish.org/portmgr/2014/02/03/time-to-bid-farewell-to-the-old-pkg_-tools/ ___ 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: libncursesw.so linker script syntax error?
On 02/02/14 23:54, Scot Hetzel wrote: Here's libncursesw.so: $ cat /usr/local/lib/libncursesw.so INPUT(libncursesw.so.5 AS_NEEDED(-ltinfow)) I don't get that output when I `cat /usr/local/lib/libncursesw.so`. When I use `file /usr/local/lib/libncursesw.so*` it shows: /usr/local/lib/libncursesw.so: symbolic link to `libncursesw.so.6' /usr/local/lib/libncursesw.so.6: symbolic link to `libncursesw.so.6.0' /usr/local/lib/libncursesw.so.6.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped Try uninstalling the devel/ncurses port again, and check if there are any left over libncurses* files and remove them. Tried that, didn't work. It rebuilds the .so as an ldscript again. Similarly with libncurses.so. What does seem to work is moving aside libncursesw.so and making it a symlink to libncursesw.so.5 (which is in turn a link to .so.5.9). I haven't tested this yet, but my guess is that the 5.9.20131221 update to the ncurses port introduced this. Thanks, ksb ___ 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-Ports-Announce] Time to bid farewell to the old pkg_ tools
be beneficial in a very short amount of time. Even if you prefer to compile from source, I use source, rarely if ever use packages, (except pkg_delete to remove old broken dependencies). No opinion which scrips are better. you will still reap the benefits of the modern packaging system. In 10.0 FreeBSD `reaped the benefit` of a default new horrible registry that smells like Microsoft with quasi binary local.sqlite needing special tools. (Yes I know there's an export function.) For 2 decade we've poured scorn on Microsoft its opaque easily damaged hard to access registry, lauded how with FreeBSD we can examine manipulate repair our text based equivalent with any number of personal choice text tools, now FreeSBD is burdened by this horrible Microsoft style registry. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with . Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ 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
Sendmail authentication warning
Hello. I've got sendmail with authentication: it uses saslauthd, which in turn is configured to use PAM; I'm also using nss_ldap. Authentication works; however I've got my logs filled with messages like: sm-mta[78808]: s0U6haTm078808: AUTH failure (DIGEST-MD5): user not found (-20) SASL(-13): user not found: unable to canonify user and get auxprops, relay=xxx.xxx.xxx.xxx As I said, authentication works, so my guess is saslauthd is first looking into its own database (or something else), then pam/nss is used. Is there any way to avoid this? bye Thanks av. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 03/02/2014 21:24, Julian H. Stacey wrote: be beneficial in a very short amount of time. Even if you prefer to compile from source, I use source, rarely if ever use packages, (except pkg_delete to remove old broken dependencies). No opinion which scrips are better. you will still reap the benefits of the modern packaging system. In 10.0 FreeBSD `reaped the benefit` of a default new horrible registry that smells like Microsoft with quasi binary local.sqlite needing special tools. (Yes I know there's an export function.) For 2 decade we've poured scorn on Microsoft its opaque easily damaged hard to access registry, lauded how with FreeBSD we can examine manipulate repair our text based equivalent with any number of personal choice text tools, now FreeSBD is burdened by this horrible Microsoft style registry. You're being absurd. local.sqlite is nothing like the Microsoft registry[*]. It's a database of all the files etc. that are managed through the ports system. No more, no less. All we have done is replace an unreliable collection of text files -- hard to keep consistent, impossible to update in an atomic fashion and woefully pessimal for certain quite legitimate queries -- with a RDBMS, which quite neatly disposes of those problems. No, it isn't ascii text which you can grep through. It's a set of relational tables, which you can query using SQL. And that is a deal more powerful in many ways than grep, but not so familiar to most; so we've provided a scripting interface in the form pf pkg-query(8). Do you complain because ZFS doesn't have it's configuration data in some ascii text files? How about procstat(8)? Or ld.so(1)/ldconfig(8)? Truth is, unix has always adopted a pragmatic approach to system data and stored it in whatever form would be most effective. In our case, we're pretty clear that a relational database is streaks ahead of a directory tree full of text files. Cheers, Matthew [*] Quite apart from anything else, a corrupt local.sqlite doesn't make one iota of difference to the operational effectiveness of your system. All it means is you've lost track of what port installed what file. -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
My first post that quotes good: Thunderbird rather than the webmail...
[As this one is about to be send, I see that it is a restate/duplicate
of the one
lost in a webmail glitch ... so apologies...]
On 02/03/14 14:38, Matthew Seaman wrote:
On 03/02/2014 21:24, Julian H. Stacey wrote:
be beneficial in a very short amount of time. Even if you prefer to
compile from source,
I use source, rarely if ever use packages, (except pkg_delete
to remove old broken dependencies). No opinion which scrips are better.
you will still reap the benefits of the modern
packaging system.
In 10.0 FreeBSD `reaped the benefit` of a default new horrible
registry that smells like Microsoft with quasi binary local.sqlite
needing special tools. (Yes I know there's an export function.)
For 2 decade we've poured scorn on Microsoft its opaque easily
damaged hard to access registry, lauded how with FreeBSD we can
examine manipulate repair our text based equivalent with any
number of personal choice text tools, now FreeSBD is burdened by
this horrible Microsoft style registry.
You're being absurd. local.sqlite is nothing like the Microsoft
registry[*]. It's a database of all the files etc. that are managed
through the ports system. No more, no less.
... our TEXT based ...
/# find /var/db/pkg -type d -name p5* | xargs -J % find -type f -name
+CONTENTS -exec grep -H 5.12 {} \; | grep pm | gtr -s \/ \n | grep
p5 | sort | uniq | xargs -J % portmaster -d -B -P -i -g % yell || yell
That pipe, corrected ( the working version includes an incrementing |
head -NN | thru hundreds of p5 upgrades, 15-25 at a time,
so easy completion of the upgrade with
only a repeat with the up arrow and a minor edit ,) handily upgraded a
/perl5/ subdirectory to
the default on several installs.
All we have done is replace an unreliable collection of text files --
hard to keep consistent, impossible to update in an atomic fashion and
woefully pessimal for certain quite legitimate queries
A subset of the above pipe?
-- with a RDBMS,
Which a user may be expected to learn
which quite neatly disposes of those problems. No, it isn't ascii text
which you can grep through.
That here is a source of dismay... less creativity in pipes etc...
It's a set of relational tables, which you
can query using SQL.
That here is also a lessening of the fun.
And that is a deal more powerful in many ways than
grep, but not so familiar to most; so we've provided a scripting
interface in the form pf pkg-query(8).
Do you complain because ZFS doesn't have it's configuration data in some
ascii text files? How about procstat(8)? Or ld.so(1)/ldconfig(8)?
Truth is, unix has always adopted a pragmatic approach to system data
and stored it in whatever form would be most effective. In our case,
we're pretty clear that a relational database is streaks ahead of a
directory tree full of text files.
For those reluctant to switch over, maybe a concurrent
/usr/ports/ports-mgmt/pkg_legacy_tools
Maybe even concurrent installs [both package systems, ] , if they are
both tweaked to be co-existable, and each in
parallel improved over time. What if an urgent upgrade to a server
failed in one method, the
other could env -i in , this one env -i out, and the upgrade
proceed apace.
Or a command to test which method would work best of on a specific
upgrade, and that pkg system default (the
other backup) until the next switchover
Can't do that in [ insert other favorite operating system here ]...
Cheers,
Matthew
J. Bouquet
___
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
Massive ports update?
Was there a *huge* update to ports tree tonight between around 00:20 and 06:30 CET? Portsnap just fetched 24720 patches (this is more or less every port I guess), but I can't find anything in http://svnweb.freebsd.org/ports/head/ that would correspond to this. I'm a bit worried. :) signature.asc Description: OpenPGP digital signature
Re: Massive ports update?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2/3/14, 9:59 PM, Nikola Pavlović wrote: Was there a *huge* update to ports tree tonight between around 00:20 and 06:30 CET? Portsnap just fetched 24720 patches (this is more or less every port I guess), but I can't find anything in http://svnweb.freebsd.org/ports/head/ that would correspond to this. I'm a bit worried. :) This may be related to my upgrade operation on the portsnap builder, which happened around UTC midnight, right after a new snap snapshot is taken. I'll do a full tree audit just in case. Cheers, -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJS8IcTAAoJEJW2GBstM+ns5p8P/ithwkITd4lodSXF+fU8BnWC LmQ3i3wav6wpWEaAj9mN0OwrGYhGlxbwLW8uNCk1VjIGmyhf6aD3cjtWNI0ImHq9 GXqgIFpwk/fxTcvKSjkFQ4JPbWwqetUjMfveIxst2Pt8aqjrQfpUzRA61pvUs17m 99NOPxNkGQEqvx2AHqVOGKQHm/JJ+BHPSdSEd2IDKVZMlnXotJ8Jr/ctnZlR8A7d RShG8GTIF8fQ6cki35p9KzKancdjk6YWdiCeMWTIwAOs4iePS2Smmd7h5M3xZ0HV Akk9/6PtX3srcxrPPEhny9A0Ct68DOdSS3LpE51NcjaWkvUq8+foS+rzq4DwjFSu OwXkF/prt4Xma7G6XsdSpCOuwaZs4Ux5PcMtFLkF0gJ6aS1VFfLXQdodHy2AEXtj GRzIPlTrHtyVzqgNMfK41cA9FBpWggoW1ufCzwe5J0X09bWM6ZOiVBpuep9vHibp jhj6hf4itcghOrCqCYrvM8cZmQZRPPU4NyoUElV1YpCz8cGteG5D3pfuLA6QOp/X Dw1ZbnOqrHCqj9QDG0UES16D4sIHQKWK1aOGLEr0AvD2PJBdjoZiChtH/vGGOTGT 4UHa+tN/wNCiesHTWixexFeSmjtBfIH7o8wPwYqgZ64X4FBN0/SH4ykNAIWZ6dmx HDuk70cVLqvmm8rlqDA9 =d5Wd -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Mon, Feb 3, 2014 at 7:23 PM, Jeffrey Bouquet jeffreybouq...@yahoo.comwrote:
My first post that quotes good: Thunderbird rather than the webmail...
[As this one is about to be send, I see that it is a restate/duplicate of
the one
lost in a webmail glitch ... so apologies...]
On 02/03/14 14:38, Matthew Seaman wrote:
On 03/02/2014 21:24, Julian H. Stacey wrote:
be beneficial in a very short amount of time. Even if you prefer to
compile from source,
I use source, rarely if ever use packages, (except pkg_delete
to remove old broken dependencies). No opinion which scrips are better.
you will still reap the benefits of the modern
packaging system.
In 10.0 FreeBSD `reaped the benefit` of a default new horrible
registry that smells like Microsoft with quasi binary local.sqlite
needing special tools. (Yes I know there's an export function.)
For 2 decade we've poured scorn on Microsoft its opaque easily
damaged hard to access registry, lauded how with FreeBSD we can
examine manipulate repair our text based equivalent with any
number of personal choice text tools, now FreeSBD is burdened by
this horrible Microsoft style registry.
You're being absurd. local.sqlite is nothing like the Microsoft
registry[*]. It's a database of all the files etc. that are managed
through the ports system. No more, no less.
... our TEXT based ...
/# find /var/db/pkg -type d -name p5* | xargs -J % find -type f -name
+CONTENTS -exec grep -H 5.12 {} \; | grep pm | gtr -s \/ \n | grep p5
| sort | uniq | xargs -J % portmaster -d -B -P -i -g % yell || yell
That pipe, corrected ( the working version includes an incrementing | head
-NN | thru hundreds of p5 upgrades, 15-25 at a time,
so easy completion of the upgrade with
only a repeat with the up arrow and a minor edit ,) handily upgraded a
/perl5/ subdirectory to
the default on several installs.
All we have done is replace an unreliable collection of text files --
hard to keep consistent, impossible to update in an atomic fashion and
woefully pessimal for certain quite legitimate queries
A subset of the above pipe?
-- with a RDBMS,
Which a user may be expected to learn
which quite neatly disposes of those problems. No, it isn't ascii text
which you can grep through.
That here is a source of dismay... less creativity in pipes etc...
It's a set of relational tables, which you
can query using SQL.
That here is also a lessening of the fun.
And that is a deal more powerful in many ways than
grep, but not so familiar to most; so we've provided a scripting
interface in the form pf pkg-query(8).
Do you complain because ZFS doesn't have it's configuration data in some
ascii text files? How about procstat(8)? Or ld.so(1)/ldconfig(8)?
Truth is, unix has always adopted a pragmatic approach to system data
and stored it in whatever form would be most effective. In our case,
we're pretty clear that a relational database is streaks ahead of a
directory tree full of text files.
For those reluctant to switch over, maybe a concurrent
/usr/ports/ports-mgmt/pkg_legacy_tools
Maybe even concurrent installs [both package systems, ] , if they are both
tweaked to be co-existable, and each in
parallel improved over time. What if an urgent upgrade to a server failed
in one method, the
other could env -i in , this one env -i out, and the upgrade proceed
apace.
Or a command to test which method would work best of on a specific
upgrade, and that pkg system default (the
other backup) until the next switchover
Can't do that in [ insert other favorite operating system here ]...
Cheers,
Matthew
J. Bouquet
For all of us who have scripts already in use that take advantage of the
old pkg database, why not a tool to generate the old db from the new. All
of the data is in the new db... it only needs to be extracted and
formatted. Looks to be easy to do in Perl or Python. Could be written in C,
of course, but that seems like overkill. (And I am not volunteering to do
it as I can't make any promises on when I might get around to it.)
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 04/02/2014 03:23, Jeffrey Bouquet wrote:
/# find /var/db/pkg -type d -name p5* | xargs -J % find -type f -name
+CONTENTS -exec grep -H 5.12 {} \; | grep pm | gtr -s \/ \n | grep
p5 | sort | uniq | xargs -J % portmaster -d -B -P -i -g % yell || yell
That pipe, corrected ( the working version includes an incrementing |
head -NN | thru hundreds of p5 upgrades, 15-25 at a time,
so easy completion of the upgrade with
only a repeat with the up arrow and a minor edit ,) handily upgraded a
/perl5/ subdirectory to
the default on several installs.
Which is a remarkably complicated equivalent to:
pkg set -o perl5.12:perl5.16
pkg install -fR perl5.16
I'm sure though if you really must have fun with pipelines that you
could start with:
pkg query %ro perl5
but working out how to divide that into chunks and feed into portmaster
is up to you.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature
Re: Massive ports update?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, On 2/3/14, 10:22 PM, Xin Li wrote: On 2/3/14, 9:59 PM, Nikola Pavlović wrote: Was there a *huge* update to ports tree tonight between around 00:20 and 06:30 CET? Portsnap just fetched 24720 patches (this is more or less every port I guess), but I can't find anything in http://svnweb.freebsd.org/ports/head/ that would correspond to this. I'm a bit worried. :) This may be related to my upgrade operation on the portsnap builder, which happened around UTC midnight, right after a new snap snapshot is taken. I'll do a full tree audit just in case. I've compared and can now confirm that the portsnap tree matches from a SSH checkout of svn tree. Cheers, -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJS8JLyAAoJEJW2GBstM+nsg30P/2yYn6l2Fj2UCVFZ21Ik6o4c G7pfKRteqyeaBEIk/H+ue4z5qBhccTi0+zYcGyhahUh42P+TIhqroIvw2aD+psNS aAfc9WTZ4z9Q8QhO2zw2hSwG5hHj8jaq+VBmHgAVxD75S+oY5BTTdH81UiVIfROy xTF0Bn5Zz2aNrT7xXQmDIw+tBp4jHW5NRq7aIHtDTZpYB91bh7v/nN6qsxPciCHh cw6s9AzeWZBZuovjU8ZWf5kehkYf+2kmd86NpfpD7wi/ifGzIJvmyOAItUV/J8il PJPLpaR5gQmYU3aQqp/phX6u1j5VbxvVe+xY9xeCLuLA4+iXN587LBnTezNanTQA qqUfbR/MYEh8ghTonbE7lA6be8zywy3Gy6hXPigJAhKEAzTXHC7WTvIuGx8j3LQ2 Jma3PXl+oWCYt7MXho9jechDwrMakLHjtjfRsaEwY3/VPtr17LupPvDogLoNeXBt KbUoFGDsCkN8CrcryqToAFtjAFn6zMNB0Rh5KYDiBYAuCxtRDD961IGRmnRC9YNI CP/UZgX3YvgiXpTWbPwx+3hpt7BmgB2np+BEdO/sE0ae7XpfzjOxzxOHXpHFdHwn zT2eDRGvGlWNNGgghwITYWi7nAd+SuUEI5afTdw0tKH1IYSZmxA2c7Y0t8Q37jbI 0RQEG/Gk8C2UJ+Yf01WV =IQQj -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
