Re: Updating CUPS
Jerry je...@seibercom.net schrieb: The ports latest version of CUPS is 1.5.4; however version 1.7.0 has been out since 10/24/13. Is there any possibility that the latest version will make it into the ports system soon? Thanks! -- Jerry ___ 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 Careful with what you are asking for, have you checked the upstream change logs? 1.6 already broke some aspects of compatibility massively w.r.t. distributed printing or differing CUPS versions in your LAN. ___ 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: Resolving circular dependencies
Hi,
On Sun, 22 Dec 2013 08:51:53 -0600
Scot Hetzel swhet...@gmail.com said:
swhetzel The best way to solve this would be to create 3 ports that would
swhetzel create the appropriate gssapi mech:
swhetzel security/cyrus-sasl2-mech-gssapi-base - Kerberos Support from
swhetzel /usr/lib/libkrb5.a
swhetzel security/cyrus-sasl2-mech-gssapi-krb5 (slave port)
swhetzel security/cyrus-sasl2-mech-gssapi-hemidal (slave port)
swhetzel That way you could use Poudriere to build these 4 ports (cyrus-sasl2,
swhetzel openldap24-sasl-client, krb5 and cyrus-sasl2-mech-gssapi-krb5).
swhetzel Now if someone could sit down and code these mech ports. ;-)
I'll do it later.
Sincerely,
--
Hajimu UMEMOTO
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
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: Build/install failure of devel/subversion
On Tue, Dec 24, 2013 at 3:11 AM, Thomas Mueller mueller6...@bellsouth.net wrote: Then I won't have to boot the NetBSD-current amd64 16 GB USB stick every time I want to update the src (stable-10 and HEAD), ports and doc trees. Scot Hetzel responded: Stable-10 and HEAD has svnlite, so you won't need to install the subversion port to update/download src, ports or doc trees. I am sort of put off by lite versions in general, even have WITHOUT_SVNLITE=yes in /etc/src.conf . I'd put WITHOUT_SENDMAIL=yes in /etc/src.conf as well but am attracted by having certs in /etc/mail. I originally partitioned hard disk using gdisk on a USB 2.0 stick installation of FreeBSD 9.2_STABLE. This installation includes subversion from ports, but then I found re(4) didn't work with Ethernet on new motherboard. I just had a thought, now that I have wi-fi working, Hiro 50191 USB adapter with rsu(4). Maybe I could chroot to FreeBSD 9.2-STABLE on USB stick after doing a null mount of /usr/src (also ports and doc) and establishing Internet connection? Presumably this would then use rsu(4) driver which is only on FreeBSD 10-stable and HEAD and not in GENERIC kernel config? Tom ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: enlightenment-0.17.5,2
24.12.2013 16:34, Peter wrote: Hello, I'm testing E17 under the PCBSD10 (based on FreeBSD 10.0-BETA3) on my laptop. I'm really disappointed by the degradation of some modules (I'm comparing with 0.16.999.65643 I use on my workstation, under PCBSD 9.1). I would like to know the port status and feature plans - if I must migrate to another WM. The principal problems I observed in 0.17.5 : - composite does not work (or not compiled) WFM on 9.2 and ^/stable/10. I only takes to load the module. -- Sphinx of black quartz, judge my vow. ___ 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 +-+ www/p5-CGI-Application-Plugin-Stream| 2.10| 2.11 +-+ 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
Re: Resolving circular dependencies
Hi,
On Wed, 25 Dec 2013 18:18:08 +0900
Hajimu UMEMOTO u...@freebsd.org said:
On Sun, 22 Dec 2013 08:51:53 -0600
Scot Hetzel swhet...@gmail.com said:
swhetzel The best way to solve this would be to create 3 ports that would
swhetzel create the appropriate gssapi mech:
swhetzel security/cyrus-sasl2-mech-gssapi-base - Kerberos Support from
swhetzel /usr/lib/libkrb5.a
swhetzel security/cyrus-sasl2-mech-gssapi-krb5 (slave port)
swhetzel security/cyrus-sasl2-mech-gssapi-hemidal (slave port)
swhetzel That way you could use Poudriere to build these 4 ports (cyrus-sasl2,
swhetzel openldap24-sasl-client, krb5 and cyrus-sasl2-mech-gssapi-krb5).
swhetzel Now if someone could sit down and code these mech ports. ;-)
ume I'll do it later.
I've just committed it. Please give it a try.
Sincerely,
--
Hajimu UMEMOTO
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
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: Resolving circular dependencies
On 26/12/2013 5:10 AM, Hajimu UMEMOTO wrote:
Hi,
On Wed, 25 Dec 2013 18:18:08 +0900
Hajimu UMEMOTO u...@freebsd.org said:
On Sun, 22 Dec 2013 08:51:53 -0600
Scot Hetzel swhet...@gmail.com said:
swhetzel The best way to solve this would be to create 3 ports that would
swhetzel create the appropriate gssapi mech:
swhetzel security/cyrus-sasl2-mech-gssapi-base - Kerberos Support from
swhetzel /usr/lib/libkrb5.a
swhetzel security/cyrus-sasl2-mech-gssapi-krb5 (slave port)
swhetzel security/cyrus-sasl2-mech-gssapi-hemidal (slave port)
swhetzel That way you could use Poudriere to build these 4 ports
(cyrus-sasl2,
swhetzel openldap24-sasl-client, krb5 and cyrus-sasl2-mech-gssapi-krb5).
swhetzel Now if someone could sit down and code these mech ports. ;-)
ume I'll do it later.
I've just committed it. Please give it a try.
Sincerely,
--
Hajimu UMEMOTO
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
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
Would it be possible to include some documentation in
/usr/ports/UPDATING regarding the removal of gssapi from cyrus-sasl2 and
the creation of the security/cyrus-sasl2-gssapi port; as it will
surprise some. A cursory review of the
security/cyrus-sasl2-gssapi/Makefile seems to create
lib/sasl2/libgssapiv2.*
lib/sasl2/libgs2.*
files, so adding security/cyrus-sasl2-gssapi into the routine build
sequence shouldn't be too dramatic a change.
It will be nice to remove the long-standing workaround of the openssl,
heimdal (without_ldap), openldapX-sasl-client, heimdal resolution loop.
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
Re: Resolving circular dependencies
On 12/25/13, 13:10, Hajimu UMEMOTO wrote: I've just committed it. Please give it a try. Hi Ume, Thank you! I noticed a typo in the new Makefile for cyrus-sasl2-gssapi. On line 60, MIT_LIB_DEPENDS is set to libkrb5support.0 instead of libkrb5support.so.0. Once I fixed this, I was able to build everything I need, and the proper libraries appear to have been built: [Dec 25 23:08 ~/packaging] rhea% tar tJf /poudriere/data/packages/92amd64-default/All/cyrus-sasl-gssapi-2.1.26.txz +COMPACT_MANIFEST +MANIFEST +MTREE_DIRS /usr/pkg/lib/sasl2/libgssapiv2.a /usr/pkg/lib/sasl2/libgssapiv2.la /usr/pkg/lib/sasl2/libgssapiv2.so /usr/pkg/lib/sasl2/libgssapiv2.so.3 /usr/pkg/share/licenses/cyrus-sasl-gssapi-2.1.26/catalog.mk /usr/pkg/share/licenses/cyrus-sasl-gssapi-2.1.26/LICENSE /usr/pkg/share/licenses/cyrus-sasl-gssapi-2.1.26/BSD4CLAUSE /usr/pkg/share/licenses/cyrus-sasl-gssapi-2.1.26/ /usr/pkg/share/licenses/ 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
WITHOUT_NLS is deprecated use NLS option instead
Tonight I'm seeing this during ports builds: /!\ WARNING /!\ WITHOUT_NLS is deprecated use NLS option instead This is silly. I traced the message to bsd.sanity.mk, which has similar silliness for many other longstanding make.conf options. If y'all are clever enough to create silly warning messages deprecating options that have been in use longer than most of you have been part of the project, you're also clever enough to make compatibility shims to cause WITHOUT_FOO to do whatever the equivalent behavior is for whatever the options framework looks like this week. Please fix this. Thanks, Doug ___ 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
shells/bash-static fails to package/deinstall cleanly
The problem is that the bash.1 and bashbugs.1 man pages do not get compressed, and therefore the package fails. If I add a MAN1 variable to the Makefile with those pages listed, it works. Doug ___ 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
dns/bind* ports overwriting conf files
While looking at the UPDATING entry for the bdb mess (more on that later) I happened to see this: 20131209: AFFECTS: users of dns/bind96, dns/bind98 and bind99 on FreeBSD 10.0 AUTHOR: er...@freebsd.org Bind versions before 9.6.3.2.ESV.R10_2, 9.8.6_2, and 9.9.4_2 on FreeBSD 10.0 will replace named.conf on upgrade. Make sure to backup any local changes before upgrading to the _2 versions. This is not Ok. FreeBSD ports are NEVER supposed to blindly overwrite config files. Please fix this so that it confirms to over a decade of policy that FreeBSD ports users should be able to safely depend on. Doug ___ 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: WITHOUT_NLS is deprecated use NLS option instead
On Wed, 2013-12-25 at 21:56 -0800, Doug Barton wrote: Tonight I'm seeing this during ports builds: /!\ WARNING /!\ WITHOUT_NLS is deprecated use NLS option instead This is silly. I traced the message to bsd.sanity.mk, which has similar silliness for many other longstanding make.conf options. If y'all are clever enough to create silly warning messages deprecating options that have been in use longer than most of you have been part of the project, you're also clever enough to make compatibility shims to cause WITHOUT_FOO to do whatever the equivalent behavior is for whatever the options framework looks like this week. Please fix this. Thanks, Doug «The longer I live, Dorian, the more keenly I feel that whatever was good enough for our fathers is not good enough for us.» Sorry, but I have a quite opposite view. Making both variants work means chaos. More variants means more complication. ___ 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: WITHOUT_NLS is deprecated use NLS option instead
On 12/25/2013 10:51 PM, clutton wrote: Sorry, but I have a quite opposite view. Making both variants work means chaos. More variants means more complication. if options for nls mean no || WITHOUT_NLS; then This is not chaos. It's called backwards compatibility, which is a critical part of every mature software project. OTOH, forcing users to jump through stupid hoops to change configurations which have worked for over a decade is a sign of the inmates running the asylum. Doug ___ 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
Berkeley DB cleanup has apparently broken ports where no db is currently installed
I saw the DEPRECATED notice for my old faithful bdb 4.7, and read the UPDATING entry related to the pending bdb purge. My first thought was That's a total waste of effort, with likely disastrous consequences. I'm all for removing broken/unused ports. Some of you may recall that I made a non-trivial contribution to those efforts when I was a committer. However the older versions of bdb are neither unused, nor broken. To make matters worse, newer versions require fairly extensive manual intervention in order to make them work with older dbs. This is the primary reason that a mass cleanup like this has never been done in the past. The amount of work to maintain the old ports is near-zero, since they don't get updates often, if at all. Whereas the amount of pain this is going to cause users is extensive. In other words this is a worst case cost/benefit ratio. To add insult to injury the status quo seems to be that if you do not already have a version of bdb installed, the ports tree will fail. The only thing I have using it atm is p5-FreeBSD-Portindex. So I uninstalled it, and its dependencies, and figured that with a clean system the ports tree would just do the right thing and install whatever version will be supported. Instead, the build failed when trying to install databases/p5-BerkeleyDB. It has USE_BDB=47+, but that doesn't work because it tries to install 47, which fails with the DEPRECATED warning. Does anyone actually test this stuff before they commit it? Meanwhile, IF (and IMO that's still a big IF) there is some good reason to do the purge of old bdb versions then leaving only 5 and 6 behind is not the right way to go. There should be at least one 4.x version left in, if for no other reason than to avoid having to go with the oracle versions. Personally I would choose 4.7 for that, but reasonable arguments can be made to include 4.8 instead. Either way, leaving behind just the 5 and 6 versions is a bad idea. Doug ___ 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
www/rubygem-passenger: link error on 10.0-PRERELEASE r259862M
Hi, I try to re-install the www/rubygem-passenger by the portmaster tool after I upgraded to 10.0, and got error like below: It produced 4 warnings at first: c++ -Iext -D_REENTRANT -I/usr/local/include -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wpointer-arith -Wwrite-strings -Wno-long-long -Wno-missing-field-initializers -Wno-ambiguous-member-template -fcommon -fvisibility=hidden -DVISIBILITY_ATTRIBUTE_SUPPORTED -g -DHAVE_ACCEPT4 -DHAS_SFENCE -DHAS_LFENCE -DPASSENGER_DEBUG -DBOOST_DISABLE_ASSERTS -std=gnu++11 -DHAS_UNORDERED_MAP -o buildout/common/libboost_oxt/boost/thread.o -c ext/boost/libs/thread/src/pthread/thread.cpp In file included from ext/boost/libs/thread/src/pthread/thread.cpp:30: ext/boost/libs/thread/src/pthread/./timeconv.inl:51:13: warning: unused function 'to_time' [-Wunused-function] inline void to_time(int milliseconds, timespec ts) ^ ext/boost/libs/thread/src/pthread/./timeconv.inl:71:13: warning: unused function 'to_timespec_duration' [-Wunused-function] inline void to_timespec_duration(const boost::xtime xt, timespec ts) ^ ext/boost/libs/thread/src/pthread/./timeconv.inl:104:13: warning: unused function 'to_duration' [-Wunused-function] inline void to_duration(boost::xtime xt, int milliseconds) ^ ext/boost/libs/thread/src/pthread/./timeconv.inl:126:13: warning: unused function 'to_microduration' [-Wunused-function] inline void to_microduration(boost::xtime xt, int microseconds) ^ 4 warnings generated. Then ran into a link error: c++ -o buildout/agents/PassengerHelperAgent.o -Iext -Iext/common -I/usr/local/include -Wno-ambiguous-member-template -I/usr/local/include -D_REENTRANT -I/usr/local/include -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wpointer-arith -Wwrite-strings -Wno-long-long -Wno-missing-field-initializers -Wno-ambiguous-member-template -fcommon -fvisibility=hidden -DVISIBILITY_ATTRIBUTE_SUPPORTED -g -DHAVE_ACCEPT4 -DHAS_SFENCE -DHAS_LFENCE -DPASSENGER_DEBUG -DBOOST_DISABLE_ASSERTS -std=gnu++11 -DHAS_UNORDERED_MAP -c ext/common/agents/HelperAgent/Main.cpp c++ buildout/agents/PassengerHelperAgent.o -o buildout/agents/PassengerHelperAgent buildout/common/libpassenger_common/Logging.o buildout/common/libpassenger_common/Exceptions.o buildout/common/libpassenger_common/Utils/SystemTime.o buildout/common/libpassenger_common/Utils/StrIntUtils.o buildout/common/libpassenger_common/Utils/IOUtils.o buildout/common/libpassenger_common/Utils.o buildout/common/libpassenger_common/Utils/Base64.o buildout/common/libpassenger_common/Utils/CachedFileStat.o buildout/common/libpassenger_common/Utils/LargeFiles.o buildout/common/libpassenger_common/ApplicationPool2/Implementation.o buildout/common/libpassenger_common/ApplicationPool2/AppTypes.o buildout/common/libpassenger_common/AgentsBase.o buildout/common/libpassenger_common/Utils/MD5.o buildout/common/libpassenger_common/Utils/fib.o buildout/common/libpassenger_common/Utils/jsoncpp.o buildout/common/libboost_oxt.a -L/usr/local/lib -lev -L/usr/local/lib -leio -pthread -lrt buildout/agents/PassengerHelperAgent.o: In function `_ZNK5boost13function_base6targetIDnEEPKT_v': /usr/local/lib/ruby/gems/2.0/gems/passenger-4.0.29/ext/boost/function/function_base.hpp:670: undefined reference to `_ZTIDn' c++: error: linker command failed with exit code 1 (use -v to see invocation) rake aborted! Command failed with status (1): [c++ buildout/agents/PassengerHelperAgent.o -o buildout/agents/PassengerHelperAgent buildout/common/libpassenger_common/Logging.o buildout/common/libpassenger_common/Exceptions.o buildout/common/libpassenger_common/Utils/SystemTime.o buildout/common/libpassenger_common/Utils/StrIntUtils.o buildout/common/libpassenger_common/Utils/IOUtils.o buildout/common/libpassenger_common/Utils.o buildout/common/libpassenger_common/Utils/Base64.o buildout/common/libpassenger_common/Utils/CachedFileStat.o buildout/common/libpassenger_common/Utils/LargeFiles.o buildout/common/libpassenger_common/ApplicationPool2/Implementation.o buildout/common/libpassenger_common/ApplicationPool2/AppTypes.o buildout/common/libpassenger_common/AgentsBase.o buildout/common/libpassenger_common/Utils/MD5.o buildout/common/libpassenger_common/Utils/fib.o buildout/common/libpassenger_common/Utils/jsoncpp.o buildout/common/libboost_oxt.a -L/usr/local/lib -lev -L/usr/local/lib -leio -pthread -lrt ] Tasks: TOP = nginx = nginx_without_native_support = buildout/agents/PassengerHelperAgent (See full trace by running task with --trace) *** Error code 1 Stop. make[1]: stopped in /usr/ports/www/rubygem-passenger *** Error code 1 Stop. make: stopped in /usr/ports/www/rubygem-passenger === Installation of rubygem-passenger-4.0.29 (www/rubygem-passenger) failed === Aborting update === Killing background jobs Terminated === You can restart from the point of failure with this command line: portmaster flags www/rubygem-passenger === Exiting I reinstalled below ports and the error
Multiple 'make describe' errors
Some of these have been around a while, but all of them make me wonder how much testing is going on with all the mass changes lately: /usr/ports/Mk/bsd.port.mk, line 6756: Inconsistent operator for check-makefile make: fatal errors encountered -- cannot continue cache-init: /usr/ports/chinese/cwtexttf Error. make: bad exit status -- 256 /usr/ports/Mk/bsd.port.mk, line 6756: Inconsistent operator for check-makefile make: fatal errors encountered -- cannot continue cache-init: /usr/ports/chinese/fireflyttf Error. make: bad exit status -- 256 /usr/ports/Mk/bsd.port.mk, line 6756: Inconsistent operator for check-makefile make: fatal errors encountered -- cannot continue cache-init: /usr/ports/chinese/CNS11643-font Error. make: bad exit status -- 256 /usr/ports/Mk/bsd.port.mk, line 6756: Inconsistent operator for check-makefile make: fatal errors encountered -- cannot continue cache-init: /usr/ports/chinese/moettf Error. make: bad exit status -- 256 /usr/ports/Mk/bsd.port.mk, line 6756: Inconsistent operator for check-makefile make: fatal errors encountered -- cannot continue cache-init: /usr/ports/chinese/CJKUnifonts Error. make: bad exit status -- 256 /usr/ports/Mk/bsd.port.mk, line 6756: Inconsistent operator for check-makefile make: fatal errors encountered -- cannot continue cache-init: /usr/ports/chinese/opendesktop-fonts Error. make: bad exit status -- 256 /usr/ports/Mk/bsd.port.mk, line 6756: Inconsistent operator for check-makefile make: fatal errors encountered -- cannot continue cache-init: /usr/ports/chinese/arphicttf Error. make: bad exit status -- 256 /usr/ports/Mk/bsd.port.mk, line 6756: Inconsistent operator for check-makefile make: fatal errors encountered -- cannot continue cache-init: /usr/ports/vietnamese/urwvn Error. make: bad exit status -- 256 /usr/ports/Mk/bsd.port.mk, line 6756: Inconsistent operator for check-makefile make: fatal errors encountered -- cannot continue cache-init: /usr/ports/vietnamese/vietunicode-hannom Error. make: bad exit status -- 256 /usr/ports/Mk/bsd.port.mk, line 6756: Inconsistent operator for check-makefile make: fatal errors encountered -- cannot continue cache-init: /usr/ports/vietnamese/vietunicode-trichlor Error. make: bad exit status -- 256 /usr/ports/Mk/bsd.port.mk, line 6756: Inconsistent operator for check-makefile make: fatal errors encountered -- cannot continue cache-init: /usr/ports/vietnamese/vietunicode-web1 Error. make: bad exit status -- 256 ___ 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
Too frequent/poorly tested bsd.port.mk commits, and general uselessness of p5-FreeBSD-Portindex
I have used Matthew's p5-FreeBSD-Portindex for several years. In the past it was a very valuable tool that allowed me to keep an INDEX up to date relative to changes in the ports tree in seconds or minutes, instead of having to do 'make index' every time. However the utility of the solution is dependent on a couple of things, including that bsd.port.mk does not change often. Over the last year or so however the changes to bsd.port.mk, which used to be well tested and batched together, are now coming fast and furious. To make matters worse, the commits are often poorly tested, which leads to several commits related to the same issue in one week. Obviously that's bad for the project generally, but I'm more concerned about whether or not it's going to be useful to stick with p5-FreeBSD-Portindex going forward. Speaking of p5-FreeBSD-Portindex generally, I'm wondering what Matthew's plans are for it? For some time now running 'cache-update -f svn-up,options' has caused errors related to WARNING unknown options file that seem to have to do with the recent changes to the /var/db/ports/category_portname convention. Is an update planned to handle this? Also, I just tried running cache-init with bdb 5, which seemed to succeed, but running portindex generated a lot of suspicious errors. I'll try again after reinstalling bdb 4.7, but I'm wondering if this is a known issue. Doug ___ 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: shells/bash-static fails to package/deinstall cleanly
On Wed, 2013-12-25 at 22:06 -0800, Doug Barton wrote: The problem is that the bash.1 and bashbugs.1 man pages do not get compressed, and therefore the package fails. If I add a MAN1 variable to the Makefile with those pages listed, it works. Doug From https://wiki.freebsd.org/ports/StageDir MAN*/MANLANG/MLINKS now useless manpage compression/uncompression is now automatically handled by the framework if you use stagedir. Take a look at my port: multimedia/ffmpegthumbnailer I believe I did it right :) ___ 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: shells/bash-static fails to package/deinstall cleanly
Please don't remove people from the CC line. I copied the maintainer on purpose. On 12/25/2013 11:40 PM, clutton wrote: On Wed, 2013-12-25 at 22:06 -0800, Doug Barton wrote: The problem is that the bash.1 and bashbugs.1 man pages do not get compressed, and therefore the package fails. If I add a MAN1 variable to the Makefile with those pages listed, it works. Doug From https://wiki.freebsd.org/ports/StageDir MAN*/MANLANG/MLINKS now useless manpage compression/uncompression is now automatically handled by the framework if you use stagedir. ... and yet, that's not what happened here. Hence the problem report. Take a look at my port: multimedia/ffmpegthumbnailer I believe I did it right :) It's not my port, which is why I CCed the maintainer. Doug ___ 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
