Bacula 3.0.1
Hi, According to the bacula website, version 3.0.1 has been released in April 09, but the current FreeBSD port version is 3.0.0. Is there a plan to bring the port up to date? Thanks, Nicki ___ 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: pthreads = no Bacula encryption on FreeBSD Release 7
Dan Langille wrote: This is to warn you that Bacula will probably not be able to be compiled and run with encryption on Release 7 of FreeBSD. This is because the version of pthreads in that release has pthread_t defined as a structure, which is incompatible with OpenSSL. The proper solution here would probably be for bacula to use the newer CRYPTO_THREADID features of OpenSSL, which do not have this restriction. The API is described at http://www.openssl.org/docs/crypto/threads.html Unfortunately these are only available with a recent OpenSSL source - and not with the version that is included in the FreeBSD 7 base system. Ciao, Johan pgpbcfGLXPGYT.pgp Description: PGP signature
Re: pthreads = no Bacula encryption on FreeBSD Release 7
Johan van Selst wrote:
Dan Langille wrote:
This is to warn you that Bacula will probably not be able to be
compiled and run with encryption on Release 7 of FreeBSD. This is
because the version of pthreads in that release has pthread_t defined as
a structure, which is incompatible with OpenSSL.
The proper solution here would probably be for bacula to use the newer
CRYPTO_THREADID features of OpenSSL, which do not have this restriction.
The API is described at http://www.openssl.org/docs/crypto/threads.html
Unfortunately these are only available with a recent OpenSSL source -
and not with the version that is included in the FreeBSD 7 base system.
CRYPTO_THREADID is not in any released version of OpenSSL yet, even the
current release 0.9.8k available now as the security/openssl port. That
functionality is due with OpenSSL 1.0.0 which will be coming out Real
Soon Now. I'm not sure what the plans are for the next FreeBSD 7.x or
8.x releases, but given OpenSSL 1.0.0 is available at the time I'd hope
they could ship with that.
Which simply means that on RELENG_7_{0,1,2} it will be obligatory to use
OpenSSL from ports with Bacula versions after 3.0.0.[*] So you'ld just
need something like this in the bacula-{client,server} Makefiles:
.if ${OSVERSION} = 70 ${OSVERSION} = 702000
USE_OPENSSL_PORTS= yes
.endif
This assumes that the bacula project does make use of CRYPTO_THREADID,
and hopefully can be persuaded not to make an incompatible change before
the OpenSSL updates eventually do come out.
Cheers,
Matthew
[*] What about supported FreeBSD 6.x versions?
--
Dr Matthew J Seaman MA, D.Phil. Flat 3
7 Priory Courtyard
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW, UK
signature.asc
Description: OpenPGP digital signature
Re: Bacula 3.0.1
I have no plans. Time is still very tight post-BSDCan. Sorry. -- Dan Langille http://langille.org/ On Jun 22, 2009, at 4:47 AM, Nicki de Wet ni...@astcape.co.za wrote: Hi, According to the bacula website, version 3.0.1 has been released in April 09, but the current FreeBSD port version is 3.0.0. Is there a plan to bring the port up to date? Thanks, Nicki ___ 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 o ports/135911[MAINTAINER] security/gpgme: Update to version 1.2.0 o ports/135910[maintainer-update] Port www/zope311 o ports/135909comms/mgetty port defaults to non-existant serial port o ports/135905[MAINTAINER] net-mgmt/zabbix: update to 1.6.5 o ports/135904[MAINTAINER] net-mgmt/zabbix-agent: update to 1.6.5 o ports/135903Update port: multimedia/cx88 Add support for CX23885/7 o ports/135886New port: net-p2p/vhcp Verlihub control panel f ports/135867net-im/gajim 0.12.3: wrong $path in bin file f ports/135831[MAINTAINER] java/sqlitejdbc: update to 056 f ports/135719[patch] multimedia/mplayer: Fix segfaults when playing o ports/135709[NEW PORT] www/gallery3 f ports/135703Updated port databases/slony1 f ports/135694[PATCH] palm/pilot-link: Unbreak on 8-CURRENT o ports/135664[PATCH]: bsd.ldap.mk: Detect flavour of installed open f ports/135660Update net/jicmp to 1.0.10 f ports/135656Update devel/p5-Class-Gomor to 1.0.2 o ports/135652[PATCH] www/gforge: Removed BROKEN. Take maintainershi s ports/135544[patch]net-im/qwit suffers from twitpocalypse f ports/135541[PATCH] math/p5-NetCDF cannot load module with netcdf- o ports/135508New port: databases/py-postgresql, Python3.x adapter f f ports/135442mkntfs from sysutils/ntfsprogs don't seems to work o ports/135322Port graphics/linux_dri has incorrect packaging list c f ports/135311mail/dovecot-antispam must be rebuilt if dovecot is up f ports/135300update for ports/www/webcheck o ports/135019sysutils/bubblemon-dockapp 1.46_6 memory usage meter i f ports/135018Port multimedia/vlc fails to compile when WITHOUT_X11= f ports/134945[UPDATE] update sysutils/linux-megacli f ports/134770lang/spidermonkey misses installation of some header f f ports/134743devel/Monotone and pthreaded dependencies o ports/134711mail/postfix - repocopy of (old) postfix to postfix25 f ports/134639devel/boost can't be made with parameteres -DWITH_PYT s ports/134485net-mgmt/trafd 3.0.2.1 doesn't collect traffic o ports/134474deskutils/wmpinboard segfaults on startup o ports/134443[NEW PORT] multimedia/2ManDVD: Create your own video d s ports/134347mail/spamd: spamlogd's whitelist expiration period is f ports/134271mail/popd POP3 server dies handling messages with very f ports/134264audio/cmus - segmentation fault with ogg files o ports/134112[MAINTAINER] net/asterisk16-addons: update to 1.6.1.0 o ports/133928New Port: multimedia/gdialog, A Project X addon to rea o ports/133822New port for cad/linux-eagle5 (Eagle 5.5.0) o ports/133563security/cfs rc script needs mntudp option on 8-CURR f ports/133451www/plone3 build fails. Plone3 needs python-2.4 but li o ports/133421[NEW PORT] java/eclipse-xsd: EMF-XSD Runtime f ports/133344net/nss_ldap fails to compile if world was installed w o ports/133303lang/visualworks cannot load Jun because of lacking TG o ports/133254[bsd.fpc.mk] don't display bogus message for fpc-using o ports/133068New port: audio/linux-genpuid f ports/133031ports/net/igmpproxy must be at least 2 Vif's where on o ports/132786New port: sysutils/sispmctl Utility for controlling a o ports/132607security/denyhosts: command_interpreter warnings in /v o ports/132391multimedia/mplayer does not work with pulseaudio o ports/131580port databases/frontbase upgraded to version 4.2.9 o ports/131526lang/cmucl: CMUCL for FreeBSD 7 s ports/131218www/privoxy+ipv6: /etc/rc: WARNING: run_rc_command: ca p ports/130779[PATCH] emulators/dosbox enable directserial passthrou o ports/130719www/nspluginwrapper installs plugins in the old direct o ports/130715New Port:devel/binutils-2.19 o ports/130675[NEW PORT] devel/ocfpcsc: Open Card Framework to PC/SC o ports/130541new port: net/isc-dhcp41-server f ports/130209www/typo3 upgrade removes configuration f ports/129677/usr/ports/sysutils/aaccli Bad system call: 12 (core d o ports/129478
Re: vim ports broken.
matt donovan kitchet...@gmail.com wrote: On Fri, Jun 19, 2009 at 5:37 AM, Albert Shih albert.s...@obspm.fr wrote: I think the vim ports is broken. Nope not broken just takes a long time to grab that patch since it pulls from FreeBSD ftp localdistfiles mirror under obrien The port *is* broken: # fetch ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/obrien/7.2.041% fetch: ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/obrien/7.2.041%: Bad Request # as fetch cannot handle % correctly. -- No Swen today, my love has gone away My mailbox stands for lorn, a symbol of the dawn ___ 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
Removed port OPTIONS linger in /var/db/ports/.../options
Hello all! I was surprised to see, when trying to update lang/ruby18 today, that the to-be-installed package would be named ruby +nopthreads-1.8.7.160_3,1, rather than the expected ruby-1.8.7.160_3,1. Checked out the port's Makefile, and indeed this name is now set when WITHOUT_PTHREADS is defined. Righto, no worries. I hadn't defined WITHOUT_PTHREADS though... Or at least, didn't think I had! make config for lang/ruby18 didn't even show such an option. /var/db/ports/ruby/options, however, did, left over from a while back: # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for ruby-1.8.7.72_1,1 _OPTIONS_READ=ruby-1.8.7.72_1,1 WITHOUT_PTHREADS=true WITHOUT_ONIGURUMA=true WITHOUT_GCPATCH=true WITH_IPV6=true WITHOUT_RDOC=true WITHOUT_DEBUG=true I must admit, I thought that when options were added or removed, the OPTIONS dialogue was redisplayed automatically, but it seems this is only when options are added (consistent with what seems to be implied in http://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html). So, to get to my point: Would it be a good thing for unknown options in ports' options files to be removed automatically during the make (or somewhere else?)? Would it be better to redisplay ports' OPTIONS dialogues both on addition and on removal of OPTIONS? Should I just shut up? I don't really want to clear all ports options before each portmaster / portupgrade run, but for now I'm inclined to to reduce the risks of having weird and wonderful options set. In case it matters, this is what I ended up with in /var/db/ports/ruby/options after a make config, not changing options but selecting OK (note the ruby+nopthreads bits): # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for ruby+nopthreads-1.8.7.160_3,1 _OPTIONS_READ=ruby+nopthreads-1.8.7.160_3,1 WITHOUT_ONIGURUMA=true WITH_IPV6=true WITHOUT_RDOC=true WITHOUT_DEBUG=true -- Nick Withers email: n...@nickwithers.com Web: http://www.nickwithers.com Mobile: +61 414 397 446 ___ 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
built with OLD dependency, take 2
Hello, I am not sure where to ask this question so I am going to start here, if this is not the correct place any direction to where I should as would be appreciated. I have 2 Freebsd 7.2p1 fresh installs. I have installed a number of ports while trying to configure them to their final configuration (everything installed is from ports). Weekly I cvsup my ports and run portmanager -u. On both of these boxes I now have a missing port and ones listed as being built with an OLD dependency. Box 1: snip of portmanager -u: 00020 have:cyrus-sasl-2.1.23 /security/cyrus-sasl2 CURRENT 00023 have:openldap-sasl-server-2.4.16_1 /net/openldap24-server CURRENT 00025 have:postfix-2.6.2_1,1 /mail/postfix built with OLD dependency: openldap-client-2.4.16 00027 :openldap-client-2.4.16 /net/openldap24-client MISSING 00034 have:openldap-sasl-client-2.4.16 /net/openldap24-sasl-client CURRENT skipping postfix-2.6.2_1,1 /mail/postfix until dependency openldap-client-2.4.16 updated skipping openldap-client-2.4.16 /net/openldap24-client marked IGNORE reason: conflicts with another installed port Box 2: snip of portmanager -u: 00024 have:openldap-sasl-server-2.4.16_1 /net/openldap24-server CURRENT 00031 have:apache-2.2.11_7 /www/apache22 built with OLD dependency: openldap-client-2.4.16 00032 :openldap-client-2.4.16 /net/openldap24-client MISSING 00033 have:php5-5.2.9 /lang/php5CURRENT 00035 have:php5-ldap-5.2.9 /net/php5-ldap built with OLD dependency: openldap-client-2.4.16 00042 have:phpldapadmin-1.1.0.7,1 /net/phpldapadmin CURRENT 00050 have:openldap-sasl-client-2.4.16 /net/openldap24-sasl-client CURRENT skipping apache-2.2.11_7 /www/apache22 until dependency openldap-client-2.4.16 updated skipping openldap-client-2.4.16 /net/openldap24-client marked IGNORE reason: conflicts with another installed port skipping php5-ldap-5.2.9 /net/php5-ldap until dependency openldap-client-2.4.16 updated postfix is built with openldap but not sasl2 apache is built with ldap and authnz_ldap On both of the boxes the offender seems to be openldap-client-2.4.16. I installed the sasl-server version of openldap which in turn installed the openldap-sasl-client. I am not sure why postfix, apache22 and php5-ldap are having a problem with the sasl vs non sasl versions. I think that the sasl client and the regular client write to the same place though they conflict with each other. Is there a way to resolve this? Thank you, Peter ___ 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: vim ports broken.
Helmut Schneider wrote: matt donovan kitchet...@gmail.com wrote: On Fri, Jun 19, 2009 at 5:37 AM, Albert Shih albert.s...@obspm.fr wrote: I think the vim ports is broken. Nope not broken just takes a long time to grab that patch since it pulls from FreeBSD ftp localdistfiles mirror under obrien The port *is* broken: # fetch ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/obrien/7.2.041% fetch: ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/obrien/7.2.041%: Bad Request # as fetch cannot handle % correctly. sure it can, it just needs '' around the url. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Senior Sys Admin- RideCharge, Inc. http://ridecharge.com Contractor - PositiveEnergyUSA http://positiveenergyusa.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. ___ 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: The mistake of blender-2.49
On, Tue Jun 16, 2009, Wayne Huang wrote: I update my ports in Jun. [...] but, when I download the blender-2.49.tar.gz I found the distinfo is fault. (my url of blender is http://download.blender.org/source/blender-2.49.tar.gz) the md5 code,sha256 code and size of the source file is all fault. I don't know where can I report this,so I send the letter for you. Sorry for the delayed response. 2.49a is out and currently tested by me. So the port will be updated within the next few days. Thanks for the patience. Regards Marcus pgpL81W0OIF9b.pgp Description: PGP signature
Re: porting: Linux to Freebsd
Am 08.06.2009, 21:15 Uhr, schrieb Peter Jeremy
peterjer...@optushome.com.au:
On 2009-Jun-08 11:33:27 -0400, Robert Huff roberth...@rcn.com wrote:
Alexander Leidinger writes:
Right: I re-ran under bash, and got the same problems.
Looking at configure.ac, I see:
AC_PATH_PROG(YACC,byacc,no)
if test x$YACC == xno
This should be a =, not a ==.
Same result.
Relevant bit is:
for ac_remove_CFLAG in -O1 -O2 -O3 ; do
CFLAGS=${CFLAGS//${ac_remove_CFLAG}/}
CPPFLAGS=${CPPFLAGS//${ac_remove_CFLAG}/}
CXXFLAGS=${CXXFLAGS//${ac_remove_CFLAG}/}
done
Quick try:
CFLAGS=`echo $CFLAGS | sed -e 's:-O[123]::g'`
No change here either.
Obvious question but if you edited configure.ac, you did remember to
rerun autoconf afterwards didn't you? Can you post the configure
script?
Note that your problems with configure do not surprise me. Despite
claims otherwise, it appears to have been designed (using the word
very loosely) as a tool to impede application portability.
I beg to differ on impede. It's a tool, as you're writing, and as such,
it can only be as powerful as its operator. Programmers using non-portable
shell code are subverting the tool, not using it.
Operating systems also have their share there. For instance, all too many
FreeBSD system header files are _not_ standalone, but have undocumented
dependencies on other headers, even if that runs counter to IEEE Std.
1003.1 (aka Single Unix Specification or POSIX). While such bugs are
easily fixed, it's often hard for the learning porter to do...
So rather than spraying non-helpful comments over the thread (if you have
issues with autoconf, file bug reports or contribute to make autoconf - or
another tool you deem more suitable - better).
--
Matthias Andree
___
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: Removed port OPTIONS linger in /var/db/ports/.../options
Nick Withers wrote: Hello all! I was surprised to see, when trying to update lang/ruby18 today, that the to-be-installed package would be named ruby +nopthreads-1.8.7.160_3,1, rather than the expected ruby-1.8.7.160_3,1. Checked out the port's Makefile, and indeed this name is now set when WITHOUT_PTHREADS is defined. Righto, no worries. I hadn't defined WITHOUT_PTHREADS though... Or at least, didn't think I had! make config for lang/ruby18 didn't even show such an option. /var/db/ports/ruby/options, however, did, left over from a while back: # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for ruby-1.8.7.72_1,1 _OPTIONS_READ=ruby-1.8.7.72_1,1 WITHOUT_PTHREADS=true WITHOUT_ONIGURUMA=true WITHOUT_GCPATCH=true WITH_IPV6=true WITHOUT_RDOC=true WITHOUT_DEBUG=true I must admit, I thought that when options were added or removed, the OPTIONS dialogue was redisplayed automatically, but it seems this is only when options are added (consistent with what seems to be implied in http://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html). If that's accurate then it's a bug, although IME the cases where an option is removed are few and far between. I don't really want to clear all ports options before each portmaster / portupgrade run You don't need to clear them all with portmaster, you can use the --force-config option which will run 'make config' for each port but preserve the choices you've already made. There is also the --check-port-dbdir option if you want to clear out options files for ports you're no longer using. hth, Doug -- This .signature sanitized for your protection ___ 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: vim ports broken.
On Mon, Jun 22, 2009 at 4:58 PM, Philip M. Golluccipgollu...@p6m7g8.com wrote: Helmut Schneider wrote: matt donovan kitchet...@gmail.com wrote: On Fri, Jun 19, 2009 at 5:37 AM, Albert Shih albert.s...@obspm.fr wrote: I think the vim ports is broken. Nope not broken just takes a long time to grab that patch since it pulls from FreeBSD ftp localdistfiles mirror under obrien The port *is* broken: # fetch ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/obrien/7.2.041% fetch: ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/obrien/7.2.041%: Bad Request # as fetch cannot handle % correctly. sure it can, it just needs '' around the url. The distinfo file is wrong. Edit it and put the correct data for that patch: MD5 (vim/7.2.041) = 66bde35426c09d9c666e23215f9a19c9 SHA256 (vim/7.2.041) = 524aa9aeb9f8729fb91289f40a4c5fecf5d0d07d3655c4a38a65abc98f7cd71b SIZE (vim/7.2.041) = 22993 Be warned that your mail agent (or mine) may break the second line after the equal sign. David, could you please commit this fix? -- My preferred quotation of Robert Louis Stevenson is You cannot make an omelette without breaking eggs. Not because I like the omelettes, but because I like the sound of eggs being broken. ___ 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: Removed port OPTIONS linger in /var/db/ports/.../options
On Mon, 2009-06-22 at 15:37 -0700, Doug Barton wrote: Nick Withers wrote: Hello all! I was surprised to see, when trying to update lang/ruby18 today, that the to-be-installed package would be named ruby +nopthreads-1.8.7.160_3,1, rather than the expected ruby-1.8.7.160_3,1. Checked out the port's Makefile, and indeed this name is now set when WITHOUT_PTHREADS is defined. Righto, no worries. I hadn't defined WITHOUT_PTHREADS though... Or at least, didn't think I had! make config for lang/ruby18 didn't even show such an option. /var/db/ports/ruby/options, however, did, left over from a while back: # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for ruby-1.8.7.72_1,1 _OPTIONS_READ=ruby-1.8.7.72_1,1 WITHOUT_PTHREADS=true WITHOUT_ONIGURUMA=true WITHOUT_GCPATCH=true WITH_IPV6=true WITHOUT_RDOC=true WITHOUT_DEBUG=true I must admit, I thought that when options were added or removed, the OPTIONS dialogue was redisplayed automatically, but it seems this is only when options are added (consistent with what seems to be implied in http://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html). If that's accurate then it's a bug, although IME the cases where an option is removed are few and far between. It'd be handy if I were to file a PR, then? This'd be the first time I've knowingly hit the problem. I don't really want to clear all ports options before each portmaster / portupgrade run You don't need to clear them all with portmaster, you can use the --force-config option which will run 'make config' for each port but preserve the choices you've already made. Good point (I'd have to make sure to select OK rather than Cancel too, but that's pretty easy!). I update my ports pretty regularly (daily or more frequently, often enough) and with a thousand-odd ports on a couple of desktop machines, --force-config (or portupgrade's -C / --config)'s gonna get old pretty quick! There is also the --check-port-dbdir option if you want to clear out options files for ports you're no longer using. That's a nifty one I wasn't aware of, cheers. hth, Doug -- Nick Withers email: n...@nickwithers.com Web: http://www.nickwithers.com Mobile: +61 414 397 446 ___ 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: [RFC] New category proposal, i18n
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On June 19, 2009 10:20:18 am Thomas Abthorpe wrote: snip It was my original thought to use localization as the category nane (and certainly something I would still hear arguments for), localization *is* l10n. While simply using internationalization seems misleading, the use of i18n carries a more direct conveyance. I posted an email to freebsd-i18n@ yesterday after posted this original message. I asked interested parties to weigh in on the matter. snip This thread seems to have gone cold, so I am trying to breath a little more life into it. I have received a lot of positive feedback off line. I found this great article at the W3.org website, http://www.w3.org/International/questions/qa-i18n To paraphrase a couple of key points Localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale). ... Internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language. To have localization, you need internationalization, so from this, I stand by my original proposal of i18n. Thomas - -- Thomas Abthorpe | FreeBSD Committer tabtho...@freebsd.org | http://people.freebsd.org/~tabthorpe -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpAGE8ACgkQ5Gm/jNBp8qCXcgCfTxGr2dCRez6kIUO7E/qW6Eh2 z4sAni0skY5TK/DUnTkP4PCtmRJUr303 =MA7+ -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: vim ports broken.
On Mon, Jun 22, 2009 at 6:23 PM, Carlos A. M. dos Santos unixma...@gmail.com wrote: On Mon, Jun 22, 2009 at 4:58 PM, Philip M. Golluccipgollu...@p6m7g8.com wrote: Helmut Schneider wrote: matt donovan kitchet...@gmail.com wrote: On Fri, Jun 19, 2009 at 5:37 AM, Albert Shih albert.s...@obspm.fr wrote: I think the vim ports is broken. Nope not broken just takes a long time to grab that patch since it pulls from FreeBSD ftp localdistfiles mirror under obrien The port *is* broken: # fetch ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/obrien/7.2.041% fetch: ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/obrien/7.2.041%: Bad Request # as fetch cannot handle % correctly. sure it can, it just needs '' around the url. The distinfo file is wrong. Edit it and put the correct data for that patch: MD5 (vim/7.2.041) = 66bde35426c09d9c666e23215f9a19c9 SHA256 (vim/7.2.041) = 524aa9aeb9f8729fb91289f40a4c5fecf5d0d07d3655c4a38a65abc98f7cd71b SIZE (vim/7.2.041) = 22993 Be warned that your mail agent (or mine) may break the second line after the equal sign. David, could you please commit this fix? -- My preferred quotation of Robert Louis Stevenson is You cannot make an omelette without breaking eggs. Not because I like the omelettes, but because I like the sound of eggs being broken. ___ 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 have had no problem grabbing the patch from the local-distfiles. just takes a very long time of course though to get to the right mirror ___ 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: [RFC] New category proposal, i18n
Thomas Abthorpe wrote: To have localization, you need internationalization, so from this, I stand by my original proposal of i18n. I have no objection to your reasoning, but continue to object to the specific string. If you're going to go down this road then internationalization would be the better choice. Doug -- This .signature sanitized for your protection ___ 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: [REPOST] problem upgrading perl
On Thu, 18 Jun 2009 11:42:51 -0700 Doug Barton do...@freebsd.org wrote: Jim Trigg wrote: Actually, he was suggesting changing from perl\* to perl-\* so it would only match the perl port. FYI, the \* at the end is not needed, 'portmaster perl-' will work just fine. Unfortunately, that won't work as there is at least one other port that will match that -- net/p5-perl-ldap (portname perl-ldap). It's generally a good idea to check your facts before posting to the list. Since the glob code goes by the directory names in /var/db/pkg, and since the prefix will be there in the directory name, this won't be an issue. In any case, I updated the instructions for this, and the other portmaster examples in /usr/ports/UPDATING a couple days ago so hopefully no one else will stumble over this. Thank you for doing that. Unfortunately, it might have been more appropriate to have simply replaced that note with another that cautions anyone attempting the perl upgrade that the upgrade has not been fully tested against all ports that may list the new perl as a build dependency. It should also warn that portmaster is *NOT* a good tool to use for this upgrade, even if the note shows how to attempt it. Using the specific port name for perl when restarting the upgrade process, I was able to resume for a short time. However, portmaster has two design problems that apply here. The first is that if portmaster encounters a port that fails to build properly, it stops cold, rather than continuing to build other ports that do build correctly, summarizing the build errors at the end. This means that each time an error occurs, it requires a manual restart (after the error has been corrected) that will run only until the next error is encountered. The second design problem is that the -R option, which is supposed to avoid rebuilding ports that have already been successfully rebuilt, nevertheless rebuilds the specified dependency port--in this case, perl-threaded-5.10.0_3--*every single time* without checking to see whether it was already successfully built. This is terribly time-consuming and wasteful. One might argue that the command says to rebuild the port specified, but there really needs to be some way to tell it not to do so. Back to the problems with the builds...a half dozen or more port rebuild failures were correctable by simply entering the failed port's directory, doing a make deinstall make reinstall, and then returning to restart (again) portmaster, which then, of course, began by rebuilding perl another time (sigh). Full testing of the perl upgrade should have made this process unnecessary, it seems to me. Eventually, though, I encountered a problem with a port called misc/gnome-icon-theme-2.26.0_1. (I do not use and haven't knowingly installed gnome, so I really don't know why this port was installed in the first place. OTOH, I also have a strong suspicion that it can't simply be eliminated either.) The rebuilding of this port aborted thusly: === Installing for gnome-icon-theme-2.26.0_1 === Generating temporary packing list === Checking if misc/gnome-icon-theme already installed Making install in 8x8 gmake[1]: Entering directory `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8' Making install in emblems gmake[2]: Entering directory `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8/emblems' gmake[3]: Entering directory `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8/emblems' gmake[3]: Nothing to be done for `install-exec-am'. test -z /usr/local/share/icons/gnome/8x8/emblems || ../.././install-sh -c -d /usr/local/share/icons/gnome/8x8/emblems install -o root -g wheel -m 444 'emblem-default.png' '/usr/local/share/icons/gnome/8x8/emblems/emblem-default.png' install -o root -g wheel -m 444 'emblem-new.png' '/usr/local/share/icons/gnome/8x8/emblems/emblem-new.png' install -o root -g wheel -m 444 'emblem-readonly.png' '/usr/local/share/icons/gnome/8x8/emblems/emblem-readonly.png' install -o root -g wheel -m 444 'emblem-symbolic-link.png' '/usr/local/share/icons/gnome/8x8/emblems/emblem-symbolic-link.png' install -o root -g wheel -m 444 'emblem-unreadable.png' '/usr/local/share/icons/gnome/8x8/emblems/emblem-unreadable.png' (cd /usr/local/share/icons/gnome/8x8 /usr/local/libexec/icon-name-mapping -c emblems) Can't locate XML/Simple.pm in @INC (@INC contains: /usr/local/lib/perl5/5.10.0/BSDPAN /usr/local/lib/perl5/site_perl/5.10.0/mach /usr/local/lib/perl5/site_perl/5.10.0 /usr/local/lib/perl5/5.10.0/mach /usr/local/lib/perl5/5.10.0 .) at /usr/local/libexec/icon-name-mapping line 12. BEGIN failed--compilation aborted at /usr/local/libexec/icon-name-mapping line 12. gmake[3]: *** [install-data-local] Error 2 gmake[3]: Leaving directory `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8/emblems' gmake[2]: *** [install-am] Error 2 gmake[2]: Leaving directory
port naming question
One of the ports I maintain (allegro) has three branches 4.2.* == main branch 4.3.* == development branch 4.9.* == the future 5.0 1) I want to make a 4.9 port - but the version number isn't yet 5.0. Is it appropriate to call the port allegro5 and just use the 4.9 version number for now? 2) How do I tell portscout to ignore 4.9.* in the allegro-devel branch? -- Eitan Adler Security is increased by designing for the way humans actually behave. -Jakob Nielsen ___ 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
Xorg 7.4, hald dbus when upgrading via packages
Hi, with reference to this http://forums.freebsd.org/showthread.php?t=694 I have a machine which got upgraded since the FreeBSD 6.1 days to 6.4 via the ports and never got XOrg 7.4 running because i never got hald and dbus properly installed. Just by chance, I saw that both hald and dbus are not put into place. After compiling the respective ports by hand, deinstalling the packages and reinstalling the ports, hald and dbus appeared to be in the proper place and working. Since then, I have Xorg 7.4 working with hal support. Erich ___ 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 naming question
Eitan Adler wrote: One of the ports I maintain (allegro) has three branches 4.2.* == main branch 4.3.* == development branch 4.9.* == the future 5.0 1) I want to make a 4.9 port - but the version number isn't yet 5.0. Is it appropriate to call the port allegro5 and just use the 4.9 version number for now? 2) How do I tell portscout to ignore 4.9.* in the allegro-devel branch? here's a typical one port-devel 4.9/5.0 port4.3 portX 4.2 where X is some combinat of integers describe the legacy line. (i.e. net-mgmt/net-snmp) PORTSCOUT= limit:^4.3 Don't forget CONFLICTS... ___ 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: [REPOST] problem upgrading perl
В Mon, 22 Jun 2009 21:12:17 -0500 (CDT) Scott Bennett benn...@cs.niu.edu пишет: SB On Thu, 18 Jun 2009 11:42:51 -0700 Doug Barton SB do...@freebsd.org wrote: SB Jim Trigg wrote: SB Actually, he was suggesting changing from perl\* to perl-\* so SB it would only match the perl port. SB SB FYI, the \* at the end is not needed, 'portmaster perl-' will work SB just fine. SB SB Unfortunately, that won't work as there is at SB least one other port that will match that -- net/p5-perl-ldap SB (portname perl-ldap). SB SB It's generally a good idea to check your facts before posting to SB the list. Since the glob code goes by the directory names SB in /var/db/pkg, and since the prefix will be there in the SB directory name, this won't be an issue. SB SB In any case, I updated the instructions for this, and the other SB portmaster examples in /usr/ports/UPDATING a couple days ago so SB hopefully no one else will stumble over this. SB SB Thank you for doing that. Unfortunately, it might have been SB more appropriate to have simply replaced that note with another SB that cautions anyone attempting the perl upgrade that the upgrade SB has not been fully tested against all ports that may list the new SB perl as a build dependency. It should also warn that portmaster is SB *NOT* a good tool to use for this upgrade, even if the note shows SB how to attempt it. Using the specific port name for perl when SB restarting the upgrade process, I was able to resume for a short SB time. However, portmaster has two design problems that apply SB here. The first is that if portmaster encounters a port that fails SB to build properly, it stops cold, rather than continuing to build SB other ports that do build correctly, summarizing the build errors SB at the end. This means that each time an error occurs, it requires SB a manual restart (after the error has been corrected) that will run SB only until the next error is encountered. The second design problem SB is that the -R option, which is supposed to avoid rebuilding ports SB that have already been successfully rebuilt, nevertheless rebuilds SB the specified dependency port--in this case, SB perl-threaded-5.10.0_3--*every single time* without checking to see SB whether it was already successfully built. This is terribly SB time-consuming and wasteful. One might argue that the command says SB to rebuild the port specified, but there really needs to be some SB way to tell it not to do so. Back to the problems with the SB builds...a half dozen or more port rebuild failures were SB correctable by simply entering the failed port's directory, doing a SB make deinstall make reinstall, and then returning to restart SB (again) portmaster, which then, of course, began by rebuilding perl SB another time (sigh). Full testing of the perl upgrade should have SB made this process unnecessary, it seems to me. Eventually, though, SB I encountered a problem with a port called SB misc/gnome-icon-theme-2.26.0_1. (I do not use and haven't SB knowingly installed gnome, so I really don't know why this port was SB installed in the first place. OTOH, I also have a strong suspicion SB that it can't simply be eliminated either.) The rebuilding of this SB port aborted thusly: SB SB === Installing for gnome-icon-theme-2.26.0_1 SB === Generating temporary packing list SB === Checking if misc/gnome-icon-theme already installed SB Making install in 8x8 SB gmake[1]: Entering directory SB `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8' SB Making install in emblems gmake[2]: Entering directory SB `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8/emblems' SB gmake[3]: Entering directory SB `/usr/ports/misc/gnome-icon-theme/work/gnome-icon-theme-2.26.0/8x8/emblems' SB gmake[3]: Nothing to be done for `install-exec-am'. test -z SB /usr/local/share/icons/gnome/8x8/emblems || ../.././install-sh -c SB -d /usr/local/share/icons/gnome/8x8/emblems install -o root -g SB wheel -m 444 'emblem-default.png' SB '/usr/local/share/icons/gnome/8x8/emblems/emblem-default.png' SB install -o root -g wheel -m 444 'emblem-new.png' SB '/usr/local/share/icons/gnome/8x8/emblems/emblem-new.png' install SB -o root -g wheel -m 444 'emblem-readonly.png' SB '/usr/local/share/icons/gnome/8x8/emblems/emblem-readonly.png' SB install -o root -g wheel -m 444 'emblem-symbolic-link.png' SB '/usr/local/share/icons/gnome/8x8/emblems/emblem-symbolic-link.png' SB install -o root -g wheel -m 444 'emblem-unreadable.png' SB '/usr/local/share/icons/gnome/8x8/emblems/emblem-unreadable.png' (cd /usr/local/share/icons/gnome/8x8 SB /usr/local/libexec/icon-name-mapping -c emblems) Can't locate SB XML/Simple.pm in @INC (@INC SB contains: /usr/local/lib/perl5/5.10.0/BSDPAN /usr/local/lib/perl5/site_perl/5.10.0/mach /usr/local/lib/perl5/site_perl/5.10.0 /usr/ local/lib/perl5/5.10.0/mach /usr/local/lib/perl5/5.10.0 .) that's answer on you question. just reinstall p5-XML-Simple SB at
