Re: mutt 1.5 much slower than mutt 1.4
On Wed, Jul 25, 2012 at 12:51:57AM -0400, Jason Hellenthal wrote:
> On Tue, Jul 24, 2012 at 06:18:43PM +0100, Anton Shterenlikht wrote:
> > mail/mutt is much slower on my amd64 and ia64
> > -current boxes after it was updated from 1.4
> > to 1.5. Each keystroke takes few seconds to
> > act. Below is my mutt 1.5 config:
> >
> > ===> The following configuration options are available for mutt-1.5.21:
> > MUTT_ASPELL=off: Enable aspell support
> > MUTT_COMPRESSED_FOLDERS=on: Enable compressed folders
> > MUTT_CYRUS_SASL2=off: Enable SASL2 authentication
> > MUTT_DEBUG=off: Enable debugging capabilities
> > MUTT_FLOCK=off: Enable flock() usage
> > MUTT_GPGME=off: Enable gpgme interface
> > MUTT_GREETING_PATCH=off: Enable greeting
> > MUTT_HTML=on: Enable HTML documentation
> > MUTT_ICONV=on: Enable iconv support
> > MUTT_IDN=off: Enable idn support
> > MUTT_IFDEF_PATCH=off: Enable ifdef feature
> > MUTT_IMAP_HEADER_CACHE=on: Enable imap header cache
> > MUTT_ISPELL=off: Enable ispell support
> > MUTT_LOCALES_FIX=off: Enable locales fix
> > MUTT_MAILBOX_MANPAGES=on: Install mbox.5/mmdf.5 manpages
> > MUTT_MAILDIR_HEADER_CACHE=off: Enable maildir header cache
> > MUTT_MAILDIR_MTIME_PATCH=off: Enable Maildir mtime patch
> > MUTT_MBOX_HOOK_PATCH=off: Enable enhanced mbox-hook
> > MUTT_NCURSES=on: Enable ncurses support
> > MUTT_NCURSES_PORT=off: Use ncurses from port
> > MUTT_NNTP=off: Enable news reader
> > MUTT_PARENT_CHILD_MATCH_PATCH=off: Enable parent/child match
> > MUTT_QUOTE_PATCH=on: Enable extended quoting
> > MUTT_REVERSE_REPLY_PATCH=off: Enable reverse_reply
> > MUTT_SGMLFORMAT=on: Enable sgml support
> > MUTT_SIDEBAR_PATCH=off: Enable sidebar
> > MUTT_SIGNATURE_MENU=off: Enable signature menu
> > MUTT_SLANG=off: Enable slang support
> > MUTT_SMIME_OUTLOOK_COMPAT=on: SMIME outlook compatible
> > MUTT_SMTP=off: Enable SMTP relay support
> > MUTT_TRASH_PATCH=off: Enable trash folder support
> > MUTT_XML=off: Use XML tools for docu
> > ===> Use 'make config' to modify these settings
> > BUZI#
> >
> > Anybody else is seeing this behaviour?
>
> No I can't say that I am. I have been using it since it stepped its way
> into mail/mutt-devel
>
> >
> > Any advice?
>
> Willing to post your muttrc ?
There are ~50 aliases, and then
# Setup
#
my_hdr From: me...@bristol.ac.uk
set envelope_from
# mailboxes
set record=+sent
set postponed=+postponed
set mbox=+received
unset save_empty
# behaviour, avoid unnecessary questions
unset confirmappend
set write_bcc = no
set delete = yes
set abort_nosubject = no
set move= yes
set print = ask-no
#set arrow_cursor=yes
set edit_headers=yes
#**
# wrapping
#
# wrap the lines at the word ends
set smart_wrap = yes
# put "+" at the beginning of wrapped lines
#set markers= yes
# leave 0 free space when wrapping
#set wrap = 0
#**
#set editor="vi"
set ispell ="aspell -c"
set print_command="fold -s -w77 | lpr"
#set print_command="fold -s -w77 | head -n 59 | lpr"
#set print_command="fold -s -w75 | pr -F | lpr -Ptext"
#set print_command="fold -s -w75 | pr -F | lpr"
set signature=$HOME/work/signature
# forward icluding attachments
set mime_forward=ask-yes
set forward_decode=no
# urlview
macro index \cb |urlview\n
macro pager \cb |urlview\n
# date and time
set date_format="!%a, %b %d, %Y at %I:%M:%S%p %Z"
set index_format="%3C %Z %{%b %d} %-15.15L (%4l) %s"
# mailing lists
#
lists freebsd-questions questions \
freebsd-current freebsd-ia64 freebsd-doc \
fort...@gcc.gnu.org
subscribe freebsd-questions questions \
freebsd-current freebsd-ia64 freebsd-doc \
fort...@gcc.gnu.org
# colours
color indicator black white
color index brightwhite black "~h freebsd-current "
color index brightyellowblack "~h freebsd-doc "
color index brightyellowred "~h freebsd-gecko "
color index brightwhite cyan"~h freebsd-hackers "
color index brightred black "~h freebsd-ia64 "
color index brightblue red "~h freebsd-mobile "
color index brightmagenta black "~h freebsd-ports "
color index brightgreen black "~h freebsd-questions "
color index black green "~h freebsd-scsi "
color index brightwhite red "~h freebsd-security "
color index brightcyan black "~h freebsd-sparc "
color index brightblue black "~h freebsd-standards "
color index black magenta "~h freebsd-toolchain "
color index black cyan"~h freebsd-wireless "
color index black yellow "~h freebsd-x11 "
color index brightwhite bl
Re: mutt 1.5 much slower than mutt 1.4
On Tue, Jul 24, 2012 at 11:00:39PM +0200, Matthias Andree wrote: > Am 24.07.2012 19:18, schrieb Anton Shterenlikht: > > mail/mutt is much slower on my amd64 and ia64 > > -current boxes after it was updated from 1.4 > > to 1.5. Each keystroke takes few seconds to > > act. Below is my mutt 1.5 config: > ... > > > Anybody else is seeing this behaviour? > > Not here≥ on amd64 9-stable -- which may have little relevance for > 10-current. > > > Any advice? > > Any chance to figure out what mutt is doing, like with truss or similar? I'll need to read up on this. > > Is debugging turned on; was mutt built WITH_DEBUG=yes? yes, I just rebuilt with this set. > > Is the lag CPU-bound (near 100% CPU) and if yes, in system or in user > space, or is the lag IO-bound (near 100% wait)? This is on ia64 r237134 For example, when I type "mutt", then "c" and choose a folder, I get: -- Mutt: Directory [~/Mail], File mask: !^\.[^.] Sorting mailbox... which goes for over 50 sec. At the same time I see in top: PIDUIDTHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 92075 1001 1 220 24248K 21384K biowr 0 0:02 3.08% mutt The same on quitting "q" (about 40 sec): PIDUIDTHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 92075 1001 1 210 24248K 21384K biowr 1 0:03 2.20% mutt > > Can you verify the header cache databases, or move them away just for > the sake of the experiment? sorry, I don't know what you mean here. > > Does it help if you "make clean" before building world? This has cured > strance effects on occasions in -STABLE (RELENG_[6-9]) branches for me. Well, I might do this later, if no other clue emerges. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: mutt 1.5 much slower than mutt 1.4
On Tue, Jul 24, 2012 at 11:00:39PM +0200, Matthias Andree wrote: > Am 24.07.2012 19:18, schrieb Anton Shterenlikht: > > mail/mutt is much slower on my amd64 and ia64 > > -current boxes after it was updated from 1.4 > > to 1.5. Each keystroke takes few seconds to > > act. Below is my mutt 1.5 config: > ... > > > Anybody else is seeing this behaviour? > > Not here≥ on amd64 9-stable -- which may have little relevance for > 10-current. > > > Any advice? > > Any chance to figure out what mutt is doing, like with truss or similar? This is the trace when I try to open a folder (> 1MB): http://seis.bris.ac.uk/~mexas/mutt.truss.open.folder I also see that I might be using old libraries: # ldd /usr/local/bin/mutt /usr/local/bin/mutt: libncursesw.so.8 => /lib/libncursesw.so.8 (0x1202f6000) libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x1203aa000) libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x1203ca000) libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x1203e4000) libhx509.so.11 => /usr/lib/libhx509.so.11 (0x1204c6000) libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x12055) libcrypto.so.6 => /lib/libcrypto.so.6 (0x120562000) libasn1.so.11 => /usr/lib/libasn1.so.11 (0x120812000) libwind.so.11 => /usr/lib/libwind.so.11 (0x120918000) libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x120952000) libroken.so.11 => /usr/lib/libroken.so.11 (0x120968000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x120996000) libssl.so.6 => /usr/lib/libssl.so.6 (0x1209d) libz.so.6 => /lib/libz.so.6 (0x120a72000) libintl.so.9 => /usr/local/lib/libintl.so.9 (0x120aaa000) libthr.so.3 => /lib/libthr.so.3 (0x120acc000) libc.so.7 => /lib/libc.so.7 (0x120b1a000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x120dca000) # make -C /usr/src check-old-libs >>> Checking for old libraries /lib/libcrypto.so.6 /usr/lib/libssl.so.6 # I probably need to do make-delete-old, and then rebuild mail/mutt again. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: CFT: New mplayer / mencoder snapshot
Thomas Zander: > New tarball is available for download: > http://bsdistfiles.googlecode.com/files/m20120724.tar.bz2 Using the default options, this mplayer works on 7.4-STABLE/amd64 for all my media. No regressions. (And lavcac3enc is still broken. No improvement there either.) I don't use mencoder. -- Christian "naddy" Weisgerber na...@mips.inka.de ___ 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"
fetchmail can't find python?
While rebuilding fetchmail again, I noticed this line in configure logs: configure: WARNING: Disabling fetchmailconf: python 2.0 or greater not found I've got python all right: # pkg info -xo python python27-2.7.3_3: lang/python27 # So what does this mean? In case it matters, this is on # uname -a FreeBSD mech-cluster241.men.bris.ac.uk 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r237134: Mon Jun 18 09:02:17 BST 2012 r...@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV ia64 # Thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: fetchmail can't find python?
On Wed, 25 Jul 2012 12:40:50 +0100 Anton Shterenlikht articulated: > While rebuilding fetchmail again, I noticed this line > in configure logs: > > configure: WARNING: Disabling fetchmailconf: python 2.0 or greater > not found > > I've got python all right: > > # pkg info -xo python > python27-2.7.3_3: lang/python27 > # > > So what does this mean? > > In case it matters, this is on > > # uname -a > FreeBSD mech-cluster241.men.bris.ac.uk 10.0-CURRENT FreeBSD > 10.0-CURRENT #6 r237134: Mon Jun 18 09:02:17 BST 2012 > r...@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV ia64 # I had a similar problem with "ruby", obviously with another program recently. I simply did an R&R of the port and now everything works fine. I have found over the years that certain programs just seem to disappear for no apparent reason and usually at the most in-opportunistic times. By the way, does "which python" reveal anything? -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ The English have no respect for their language, and will not teach their children to speak it. George Bernard Shaw signature.asc Description: PGP signature
Re: Cannot upgrade kde-baseapps-4.7.4_1 to 4.8.4
sindrome writes: > Linking CXX executable dolphin > ../../lib/libdolphinprivate.so.5.0.1: undefined reference to > `KVersionControlPlugin2::staticMetaObject' For posterity: we've also been contacted in the kde@ mailing list [1], and are currently tracking it there. It may be the case that the OP did not follow UPDATING, as there's a dangling /usr/local/lib/libkonq.so which should not be present and is being wrongfully picked up. [1] http://article.gmane.org/gmane.comp.kde.freebsd/21894 ___ 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: Cannot upgrade kdesdk-4.7.4_1 to 4.8.4
sindrome writes: > Trying to upgrade kdesdk-4.7.4_1 to 4.8.4 and running into the > following error. Anyone have an idea? This seems to come from the same libkonq problems which are currently blocking your kde4-baseapps upgrade. ___ 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: [CFT] editors/emacs to 24.1
ash...@freebsd.org (Ashish SHUKLA) writes: > Any feedback would be greatly appreciated. It seems to be running fine here, I've now even switched to GTK3 (I wonder if there should be an error message if one selected more than one GUI option). Gnus from git with the new Emacs also seems to be running fine. ___ 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: fetchmail can't find python?
On Wed, 25 Jul 2012 12:40:50 +0100
Anton Shterenlikht articulated:
> While rebuilding fetchmail again, I noticed this line
> in configure logs:
>=20
> configure: WARNING: Disabling fetchmailconf: python 2.0 or greater
> not found
>=20
> I've got python all right:
>=20
> # pkg info -xo python
> python27-2.7.3_3: lang/python27
> #=20
>=20
> So what does this mean?
>=20
> In case it matters, this is on=20
>=20
> # uname -a
> FreeBSD mech-cluster241.men.bris.ac.uk 10.0-CURRENT FreeBSD
> 10.0-CURRENT #6 r237134: Mon Jun 18 09:02:17 BST 2012
> r...@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV ia64
#=20
I had a similar problem with "ruby", obviously with another program
recently. I simply did an R&R of the port and now everything works fine.
I have found over the years that certain programs just seem to disappear
for no apparent reason and usually at the most in-opportunistic times.
By the way, does "which python" reveal anything?
What's R&R? rock-n-roll?..
Anyway:
# cat /usr/local/bin/fetchmailconf
#!/bin/sh
#
# Wrapper for the real fetchmailconf. Checks whether Python and Tkinter are
# installed, and runs the real fetchmailconf or alerts the user, as appropriate.
#
# $FreeBSD: head/mail/fetchmail/files/fetchmailconf 300896 2012-07-14 13:54:48Z
beat $
LOCALBASE=/usr/local
if [ -x $LOCALBASE/bin/python ] ; then
PYTHON_VERSION=python$(${LOCALBASE}/bin/python -c 'import sys; print
sys.version[:3]' 2>/dev/null)
if [ -e ${LOCALBASE}/lib/${PYTHON_VERSION}/site-packages/_tkinter.so ];
then
exec ${LOCALBASE}/libexec/fetchmailconf.py "$@"
fi
fi
cat
Re: fetchmail can't find python?
___ 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: [CFT] editors/emacs to 24.1
On Wednesday, July 25, 2012 11:39:07 Raphael Kubo da Costa wrote: > It seems to be running fine here, I've now even switched to GTK3 (I > wonder if there should be an error message if one selected more than one > GUI option). The GUI options use OPTIONS_SINGLE, so the port will error out if more than one GUI option is selected. Jason ___ 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: fetchmail can't find python?
It's harmless; just the fetchmail port working around the configure script so that the proper PYTHON_VERSION is pulled in, rather than whatever the configure script finds. If you've got the 'x11' option enabled for the port, fetchmailconf will be built and installed regardless of that warning. If you've got the 'x11' option disabled, that's why fetchmailconf isn't being built. Best regards. ~crh On 2012-07-25, Anton Shterenlikht wrote: > While rebuilding fetchmail again, I noticed this line > in configure logs: > > configure: WARNING: Disabling fetchmailconf: python 2.0 or greater not found > > I've got python all right: > > # pkg info -xo python > python27-2.7.3_3: lang/python27 > # > > So what does this mean? > > In case it matters, this is on > > # uname -a > FreeBSD mech-cluster241.men.bris.ac.uk 10.0-CURRENT FreeBSD 10.0-CURRENT #6 > r237134: Mon Jun 18 09:02:17 BST 2012 > r...@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV ia64 > # pgpH6rZ8jbNZp.pgp Description: PGP signature
Question about new options framework (regression?)
Hi, What is the proper way to temporarily change an option on the command line or within a script? For example, I have a script that builds both dynamic and static zsh binaries, without user intervention. With the old options system, the script set "WITH_ZSH_STATIC=true" when building the port. With the new options framework, that doesn't work aymore. Is there a variable that can be set to override what's read from the options file? If there is none, this feels like a regression. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[HEADS UP] FreeBSD 9.1 ports feature freeze
The FreeBSD 9.1 schedule has been published, http://www.freebsd.org/releases/9.1R/schedule.html. Historically we have done a Feature Freeze at RC1, we are going to try do it with RC2 this time, tentatively scheduled for August 3, subject to schedule slippage. At the time the the Release Engineering team announces RC2 is ready, we will then enforce "Feature Safe" commits only. This means no sweeping changes will be allowed, see http://www.freebsd.org/portmgr/implementation.html#sweeping_changes Once portmgr@ is satisfied that the requisite packages are built to ship with FreeBSD 9.1, the ports tree will be re-opened for business. Thomas on behalf of portmgr http://blogs.freebsdish.org/portmgr/2012/07/25/freebsd-9-1-ports-feature-freeze/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD Port: bash-4.2.28
Hello obrien, Any plans to update bash-4.2.28 up to patch level 037? I see we still are on patch level 028. Regards, Michael Zoon ___ 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: Question about new options framework (regression?)
On Wed, Jul 25, 2012 at 05:11:18PM +0200, Oliver Fromme wrote: > Hi, > > What is the proper way to temporarily change an option on > the command line or within a script? > > For example, I have a script that builds both dynamic and > static zsh binaries, without user intervention. With the > old options system, the script set "WITH_ZSH_STATIC=true" > when building the port. With the new options framework, > that doesn't work aymore. > > Is there a variable that can be set to override what's read > from the options file? If there is none, this feels like a > regression. > > Best regards >Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- > chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > One Unix to rule them all, One Resolver to find them, > One IP to bring them all and in the zone to bind them. > ___ > 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" Examples: cd /usr/ports/zsh/shells $ make showconfig ===> The following configuration options are available for zsh-5.0.0: DEBUG=off: Install debug symbols DOCS=on: Build and install the documentation GDBM=off: Enable GDBM support (GPL) MAILDIR=on: Enable support for Maildirs in MAIL(PATH) MEM=off: Enable zsh-mem options MULTIBYTE=on: multibyte character support PCRE=off: Use Perl Compatible Regular Expressions SECURE_FREE=on: Enable zsh-secure-free STATIC=off: Build static executable/libraries ===> Use 'make config' to modify these settings $ OPTIONS_SET="STATIC" make showconfig ===> The following configuration options are available for zsh-5.0.0: DEBUG=off: Install debug symbols DOCS=on: Build and install the documentation GDBM=off: Enable GDBM support (GPL) MAILDIR=on: Enable support for Maildirs in MAIL(PATH) MEM=off: Enable zsh-mem options MULTIBYTE=on: multibyte character support PCRE=off: Use Perl Compatible Regular Expressions SECURE_FREE=on: Enable zsh-secure-free STATIC=on: Build static executable/libraries ===> Use 'make config' to modify these settings $ zsh_SET="STATIC" make showconfig ===> The following configuration options are available for zsh-5.0.0: DEBUG=off: Install debug symbols DOCS=on: Build and install the documentation GDBM=off: Enable GDBM support (GPL) MAILDIR=on: Enable support for Maildirs in MAIL(PATH) MEM=off: Enable zsh-mem options MULTIBYTE=on: multibyte character support PCRE=off: Use Perl Compatible Regular Expressions SECURE_FREE=on: Enable zsh-secure-free STATIC=on: Build static executable/libraries ===> Use 'make config' to modify these settings $ OPTIONS_OVERRIDE="STATIC" make showconfig ===> The following configuration options are available for zsh-5.0.0: DEBUG=off: Install debug symbols DOCS=off: Build and install the documentation GDBM=off: Enable GDBM support (GPL) MAILDIR=off: Enable support for Maildirs in MAIL(PATH) MEM=off: Enable zsh-mem options MULTIBYTE=off: multibyte character support PCRE=off: Use Perl Compatible Regular Expressions SECURE_FREE=off: Enable zsh-secure-free STATIC=on: Build static executable/libraries ===> Use 'make config' to modify these settings OPTIONS_SET and zsh_SET are the two normal way of setting options in make.conf. OPTIONS_SET being global and zsh_SET being specific. With both make sure to either not have them in make.conf of have them define with ?= or += Be careful that they can be changed by OPTIONS_UNSET and zsh_UNSET from make.conf if any on the other hand OPTIONS_OVERRIDE will deactivate all options setting what ever the defaults are, what the saved configuration can be etc. and run the make command with just the options defined in it activated regards, Bapt pgpN5PIYvsRzl.pgp Description: PGP signature
Re: Question about new options framework (regression?)
Baptiste Daroussin wrote: > On Wed, Jul 25, 2012 at 05:11:18PM +0200, Oliver Fromme wrote: > > What is the proper way to temporarily change an option on > > the command line or within a script? > > > > For example, I have a script that builds both dynamic and > > static zsh binaries, without user intervention. With the > > old options system, the script set "WITH_ZSH_STATIC=true" > > when building the port. With the new options framework, > > that doesn't work aymore. > > > > Is there a variable that can be set to override what's read > > from the options file? If there is none, this feels like a > > regression. > > $ OPTIONS_SET="STATIC" make showconfig > ===> The following configuration options are available for zsh-5.0.0: > DEBUG=off: Install debug symbols > DOCS=on: Build and install the documentation > GDBM=off: Enable GDBM support (GPL) > MAILDIR=on: Enable support for Maildirs in MAIL(PATH) > MEM=off: Enable zsh-mem options > MULTIBYTE=on: multibyte character support > PCRE=off: Use Perl Compatible Regular Expressions > SECURE_FREE=on: Enable zsh-secure-free > STATIC=on: Build static executable/libraries > ===> Use 'make config' to modify these settings I'm afraid it doesn't work for me: $ OPTIONS_SET="STATIC" make showconfig ===> The following configuration options are available for zsh-5.0.0: DEBUG=off: Install debug symbols DOCS=on: Build and install the documentation GDBM=off: Enable GDBM support (GPL) MAILDIR=on: Enable support for Maildirs in MAIL(PATH) MEM=on: Enable zsh-mem options MULTIBYTE=on: multibyte character support PCRE=off: Use Perl Compatible Regular Expressions SECURE_FREE=on: Enable zsh-secure-free STATIC=off: Build static executable/libraries ===> Use 'make config' to modify these settings I also tried the other settings you suggested, and none of them works. It's always overridden by the settings that are stored in $PORT_DBDIR. With the old framework, I could override $PORT_DBDIR with "WITH_ZSH_STATIC=true" ... Can't this be done with the new framework, too? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Passwords are like underwear. You don't share them, you don't hang them on your monitor or under your keyboard, you don't email them, or put them on a web site, and you must change them very often. ___ 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: Question about new options framework (regression?)
On Wed, Jul 25, 2012 at 07:09:48PM +0200, Oliver Fromme wrote: > Baptiste Daroussin wrote: > > On Wed, Jul 25, 2012 at 05:11:18PM +0200, Oliver Fromme wrote: > > > What is the proper way to temporarily change an option on > > > the command line or within a script? > > I also tried the other settings you suggested, and none > of them works. It's always overridden by the settings > that are stored in $PORT_DBDIR. > > With the old framework, I could override $PORT_DBDIR with > "WITH_ZSH_STATIC=true" ... Can't this be done with the > new framework, too? This is because you already have a save configuration made out of make config you can still override PORT_DBDIR to make sure this configuration is not read PORT_DBDIR=/dev/null OPTIONS_SET="STATIC" make .. regards, Bapt pgpmsPmWC9CvF.pgp Description: PGP signature
Re: Question about new options framework (regression?)
Baptiste Daroussin wrote: > On Wed, Jul 25, 2012 at 07:09:48PM +0200, Oliver Fromme wrote: > > Baptiste Daroussin wrote: > > > On Wed, Jul 25, 2012 at 05:11:18PM +0200, Oliver Fromme wrote: > > > > What is the proper way to temporarily change an option on > > > > the command line or within a script? > > > > I also tried the other settings you suggested, and none > > of them works. It's always overridden by the settings > > that are stored in $PORT_DBDIR. > > > > With the old framework, I could override $PORT_DBDIR with > > "WITH_ZSH_STATIC=true" ... Can't this be done with the > > new framework, too? > > This is because you already have a save configuration made out of make > config > > you can still override PORT_DBDIR to make sure this configuration is > not read > PORT_DBDIR=/dev/null OPTIONS_SET="STATIC" make .. But I *do* want to use the saved configuration: It enables the MEM option, and maybe other things in the future. I only want to override *one* option -- the STATIC option. The others should be taken from the saved configuration in the options file. Well, of course, my script could try to parse the options file, construct appropriate OPTIONS_SET and OPTIONS_UNSET strings, and then add STATIC. But I hoped that there still is a simple way to override single settings from the options file ... I have to say it's a little annoying that I have to jump through hoops to achieve something that was rather trivial to do before. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." -- RFC 1925 ___ 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: Question about new options framework (regression?)
On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme wrote: > Baptiste Daroussin wrote: > > On Wed, Jul 25, 2012 at 05:11:18PM +0200, Oliver Fromme wrote: > > > What is the proper way to temporarily change an option on > > > the command line or within a script? > > > > > > For example, I have a script that builds both dynamic and > > > static zsh binaries, without user intervention. With the > > > old options system, the script set "WITH_ZSH_STATIC=true" > > > when building the port. With the new options framework, > > > that doesn't work aymore. > > > > > > Is there a variable that can be set to override what's read > > > from the options file? If there is none, this feels like a > > > regression. > > > > $ OPTIONS_SET="STATIC" make showconfig > > ===> The following configuration options are available for zsh-5.0.0: > > DEBUG=off: Install debug symbols > > DOCS=on: Build and install the documentation > > GDBM=off: Enable GDBM support (GPL) > > MAILDIR=on: Enable support for Maildirs in MAIL(PATH) > > MEM=off: Enable zsh-mem options > > MULTIBYTE=on: multibyte character support > > PCRE=off: Use Perl Compatible Regular Expressions > > SECURE_FREE=on: Enable zsh-secure-free > > STATIC=on: Build static executable/libraries > > ===> Use 'make config' to modify these settings > > I'm afraid it doesn't work for me: > > $ OPTIONS_SET="STATIC" make showconfig > ===> The following configuration options are available for zsh-5.0.0: > DEBUG=off: Install debug symbols > DOCS=on: Build and install the documentation > GDBM=off: Enable GDBM support (GPL) > MAILDIR=on: Enable support for Maildirs in MAIL(PATH) > MEM=on: Enable zsh-mem options > MULTIBYTE=on: multibyte character support > PCRE=off: Use Perl Compatible Regular Expressions > SECURE_FREE=on: Enable zsh-secure-free > STATIC=off: Build static executable/libraries > ===> Use 'make config' to modify these settings > > I also tried the other settings you suggested, and none > of them works. It's always overridden by the settings > that are stored in $PORT_DBDIR. > > With the old framework, I could override $PORT_DBDIR with > "WITH_ZSH_STATIC=true" ... Can't this be done with the > new framework, too? > Reading thru the Mk/bsd.options.mk, it seems you should be able to do: $ WITH_STATIC=true make showconfig And it might override the saved settings from the OPTIONSFILE. Scot ___ 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: bash-4.2.28
On 07/25/2012 08:03, Michael wrote: > Hello obrien, > > > > Any plans to update bash-4.2.28 up to patch level 037? Is there a specific bug fixed that you're interested in? -- Change is hard. ___ 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: Question about new options framework (regression?)
On 2012-07-25 20:18, Scot Hetzel wrote: > On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme > wrote: >> >> I also tried the other settings you suggested, and none >> of them works. It's always overridden by the settings >> that are stored in $PORT_DBDIR. >> >> With the old framework, I could override $PORT_DBDIR with >> "WITH_ZSH_STATIC=true" ... Can't this be done with the >> new framework, too? >> > Reading thru the Mk/bsd.options.mk, it seems you should be able to do: > > $ WITH_STATIC=true make showconfig > > And it might override the saved settings from the OPTIONSFILE. No, this will not work. $ make showconfig | grep STATIC STATIC=off: Build static executable/libraries $ make -V LDFLAGS -L/usr/local/lib -rpath=/usr/lib:/usr/local/lib $ make -V LDFLAGS WITH_STATIC=true -L/usr/local/lib -rpath=/usr/lib:/usr/local/lib Expected result: -L/usr/local/lib -rpath=/usr/lib:/usr/local/lib -static Seems we will see more such issues with slave ports since they cannot overwrite the optionsfile (maybe a fake target in the slave with make rmconfig can be a solution ;) For me this is a regression which was already discussed on this list ( optionsng and tinderbox? ) I also ask with a simple example and got no answers ( options NG and slave/sub ports ) ___ 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: Question about new options framework (regression?)
On 2012-07-25 20:18, Scot Hetzel wrote:
> On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme
> wrote:
The following diff will restore the old behavior so make.conf and command
params have priority.
(Place the make.conf part after the OPTIONS_FILE_SET part)
Until now I cannot see why the OPTIONS file should always win.
Index: bsd.options.mk
===
--- bsd.options.mk (revision 301530)
+++ bsd.options.mk (working copy)
@@ -173,17 +173,6 @@
. include "${OPTIONSFILE}.local"
. endif
-### convert WITH and WITHOUT found in make.conf or reloaded from old
optionsfile
-.for opt in ${ALL_OPTIONS}
-.if defined(WITH_${opt})
-PORT_OPTIONS+= ${opt}
-PORT_OPTIONS:= ${PORT_OPTIONS:O:u}
-.endif
-.if defined(WITHOUT_${opt})
-PORT_OPTIONS:= ${PORT_OPTIONS:N${opt}}
-.endif
-.endfor
-
## Finish by using the options set by the port config dialog, if any
. for opt in ${OPTIONS_FILE_SET}
.if !empty(COMPLETE_OPTIONS_LIST:M${opt})
@@ -199,6 +188,17 @@
.endif
+### convert WITH and WITHOUT found in make.conf or reloaded from old
optionsfile
+.for opt in ${ALL_OPTIONS}
+.if defined(WITH_${opt})
+PORT_OPTIONS+= ${opt}
+PORT_OPTIONS:= ${PORT_OPTIONS:O:u}
+.endif
+.if defined(WITHOUT_${opt})
+PORT_OPTIONS:= ${PORT_OPTIONS:N${opt}}
+.endif
+.endfor
+
## Now some compatibility
.if empty(PORT_OPTIONS:MDOCS)
NOPORTDOCS=yes
___
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: fetchmail can't find python?
On Wed, 25 Jul 2012 15:55:28 +0100 (BST) Anton Shterenlikht articulated: On Wed, 25 Jul 2012 12:40:50 +0100 >Anton Shterenlikht articulated: > >> While rebuilding fetchmail again, I noticed this line >> in configure logs: >>=20 >> configure: WARNING: Disabling fetchmailconf: python 2.0 or >> greater not found >>=20 >> I've got python all right: >>=20 >> # pkg info -xo python >> python27-2.7.3_3: lang/python27 >> #=20 >>=20 >> So what does this mean? >>=20 >> In case it matters, this is on=20 >>=20 >> # uname -a >> FreeBSD mech-cluster241.men.bris.ac.uk 10.0-CURRENT FreeBSD >> 10.0-CURRENT #6 r237134: Mon Jun 18 09:02:17 BST 2012 >> r...@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV >> ia64 #=20 > > I had a similar problem with "ruby", obviously with another > program recently. I simply did an R&R of the port and now everything > works fine. I have found over the years that certain programs just > seem to disappear for no apparent reason and usually at the most > in-opportunistic times. > > By the way, does "which python" reveal anything? > > What's R&R? rock-n-roll?.. Removal & re-instillation. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ 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: bash-4.2.28
On Wed, 25 Jul 2012 11:14:25 -0700 Doug Barton articulated: > On 07/25/2012 08:03, Michael wrote: > > Hello obrien, > > > > Any plans to update bash-4.2.28 up to patch level 037? > > Is there a specific bug fixed that you're interested in? The short answer would be what the hell difference does that make? The OP just wanted to know if the port was going to be updated to include the newly released patches. The long answer is that he is interested in getting the official patches to correct known problems with Bash. Who's business is it what problem, real or potential that the OP is looking to correct or prevent? Actually, the OP would be better served contacting the port maintainer . Unlike Postfix that updates in virtually real time, there is usually quite a lag between the time Bash issues a patch and the time it makes it into the ports system. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ 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: Question about new options framework (regression?)
On Wed, Jul 25, 2012 at 11:24:27PM +0200, Olli Hauer wrote: > On 2012-07-25 20:18, Scot Hetzel wrote: > > On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme > > wrote: > > The following diff will restore the old behavior so make.conf and command > params have priority. > (Place the make.conf part after the OPTIONS_FILE_SET part) > > Until now I cannot see why the OPTIONS file should always win. > because the priority goes to global to specific and the most specific is the options file. if most people want the options file to not have the final priority, why not, can others spread their opinion here? regards, Bapt pgpjD7S7tTSwt.pgp Description: PGP signature
Re: Question about new options framework (regression?)
On 2012-07-26 00:57, Baptiste Daroussin wrote: > On Wed, Jul 25, 2012 at 11:24:27PM +0200, Olli Hauer wrote: >> On 2012-07-25 20:18, Scot Hetzel wrote: >>> On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme >>> wrote: >> >> The following diff will restore the old behavior so make.conf and command >> params have priority. >> (Place the make.conf part after the OPTIONS_FILE_SET part) >> >> Until now I cannot see why the OPTIONS file should always win. >> > > because the priority goes to global to specific and the most specific is the > options file. > > if most people want the options file to not have the final priority, why not, > can others spread their opinion here? > The power of make.conf was to specify / overwrite a dedicated behavior (same like src.conf) globally or per directory regardless what is defined in options. A valid use case was given with shell/zsh. Say someone don't want to have DB-A in the network (because of the license ...) and set global without DB-A and use DB-B instead, once there is an options file you loose. I have make.conf in svn and from there it is deployed to all systems to make sure they end up as specified, defining PORT_DBDIR=/dev/null is not handy. Again, how would you overwrite from a slave an option which was set once before with make config on the master port? (with working example please) Additional I suspect a command arg is more specific then a option which was set once. -- Regards, olli ___ 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] LibreOffice build issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-25 03:12:21 -0400, Andriy Gapon wrote: > on 25/07/2012 00:29 Jung-uk Kim said the following: >> On 2012-07-23 16:55:50 -0400, Andriy Gapon wrote: >>> on 23/07/2012 23:49 Jung-uk Kim said the following: >>>> On 2012-07-23 16:34:34 -0400, Andriy Gapon wrote: >>>>> Just a note: yesterday I built the port using GCC 4.6 and >>>>> external cppunit also built with GCC 4.6 (in fact almost >>>>> all of my ports are built with that compiler). I did not >>>>> run into any problems whatsoever. >>>> >>>>> I am a little bit saddened that GCC46 option was thrown >>>>> out. >>>> >>>> We can re-add it but it makes the Makefile little too >>>> complicated. :-( >> >>> Here is what I used: >>> http://people.freebsd.org/~avg/libreoffice-Makefile.txt But of >>> course I have my own version of bsd.gcc.mk which allows >>> WITH_GCC=gcc46 in make.conf to do the right thing (mostly). >> >> Can you please tell me your FreeBSD version? Was it stable/9? >> FYI, I wasn't able to build it sanely on head. :-( > > It's the head: FreeBSD 10.0-CURRENT r236503. I guess you had installed OpenSSL from ports. ;-) Now I am able to build it with GCC 4.6: http://people.freebsd.org/~jkim/libreoffice-20120725.tar.bz2 Basically, bsd.openssl.mk adds -rpath=/usr/lib:/usr/local/lib to LDFLAGS first, then bsd.gcc.mk adds -Wl,-rpath=/usr/local/lib/gcc46 to it later. Before: % make -V LDFLAGS -rpath=/usr/lib:/usr/local/lib % make -V LDFLAGS USE_OPENSSL_BASE=yes -rpath=/usr/lib:/usr/local/lib % make -V LDFLAGS USE_OPENSSL_PORT=yes -rpath=/usr/local/lib % make -V LDFLAGS USE_OPENSSL_BASE=yes WITH_GCC=yes -rpath=/usr/lib:/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc46 % make -V LDFLAGS USE_OPENSSL_PORT=yes WITH_GCC=yes -rpath=/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc46 For WITH_GCC case, I just defined OPENSSL_LDFLAGS as "-rpath=/usr/local/lib/gcc46". After: % make -V LDFLAGS -rpath=/usr/lib:/usr/local/lib % make -V LDFLAGS USE_OPENSSL_BASE=yes -rpath=/usr/lib:/usr/local/lib % make -V LDFLAGS USE_OPENSSL_PORT=yes -rpath=/usr/local/lib % make -V LDFLAGS USE_OPENSSL_BASE=yes WITH_GCC=yes -rpath=/usr/local/lib/gcc46 -rpath=/usr/lib:/usr/local/lib - -Wl,-rpath=/usr/local/lib/gcc46 % make -V LDFLAGS USE_OPENSSL_PORT=yes WITH_GCC=yes -rpath=/usr/local/lib/gcc46 -rpath=/usr/local/lib - -Wl,-rpath=/usr/local/lib/gcc46 It's ugly but it's good enough for now. Please note this is really a bug in bsd.openssl.mk (and/or bsd.port.mk depending on how you look at it). It shouldn't have added /usr/lib in the first place. It is only needed for OPENSSL_PORT case and just /usr/local/lib itself. Also, bsd.gcc.mk had to be included before all bsd.foo.mk, whatever touches rpath. Cheers, Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAQj+8ACgkQmlay1b9qnVOZJgCgnHZ89oYEhzrMIEgWxKQvXxII ttUAn1pqGJFEUajZRjsqF3fDe3TFmnPe =uyRb -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: Question about new options framework (regression?)
On 25 July 2012 15:57, Baptiste Daroussin wrote: > On Wed, Jul 25, 2012 at 11:24:27PM +0200, Olli Hauer wrote: >> On 2012-07-25 20:18, Scot Hetzel wrote: >> > On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme >> > wrote: >> >> The following diff will restore the old behavior so make.conf and command >> params have priority. >> (Place the make.conf part after the OPTIONS_FILE_SET part) >> >> Until now I cannot see why the OPTIONS file should always win. >> > > because the priority goes to global to specific and the most specific is the > options file. > > if most people want the options file to not have the final priority, why not, > can others spread their opinion here? An option specified on the command line is more specific and should have priority over saved values or configuration files. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Question about new options framework (regression?)
On Wed, Jul 25, 2012 at 07:40:56PM -0700, Eitan Adler wrote: > On 25 July 2012 15:57, Baptiste Daroussin wrote: > > On Wed, Jul 25, 2012 at 11:24:27PM +0200, Olli Hauer wrote: > >> On 2012-07-25 20:18, Scot Hetzel wrote: > >> > On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme > >> > wrote: > >> > >> The following diff will restore the old behavior so make.conf and command > >> params have priority. > >> (Place the make.conf part after the OPTIONS_FILE_SET part) > >> > >> Until now I cannot see why the OPTIONS file should always win. > >> > > > > because the priority goes to global to specific and the most specific is the > > options file. > > > > if most people want the options file to not have the final priority, why > > not, > > can others spread their opinion here? > > An option specified on the command line is more specific and should > have priority over saved values or configuration files. > > -- > Eitan Adler You can already do that: OPTIONSFILE=/my/path/to/options make config regards, Bapt pgpjzSaqYN9o0.pgp Description: PGP signature
Re: Question about new options framework (regression?)
On 25 July 2012 21:55, Baptiste Daroussin wrote: > You can already do that: > OPTIONSFILE=/my/path/to/options make config You can't set specific options on the command line without putting all of them into a file? -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Question about new options framework (regression?)
On 2012-07-26 06:55, Baptiste Daroussin wrote: > On Wed, Jul 25, 2012 at 07:40:56PM -0700, Eitan Adler wrote: >> On 25 July 2012 15:57, Baptiste Daroussin wrote: >>> On Wed, Jul 25, 2012 at 11:24:27PM +0200, Olli Hauer wrote: On 2012-07-25 20:18, Scot Hetzel wrote: > On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme > wrote: The following diff will restore the old behavior so make.conf and command params have priority. (Place the make.conf part after the OPTIONS_FILE_SET part) Until now I cannot see why the OPTIONS file should always win. >>> >>> because the priority goes to global to specific and the most specific is the >>> options file. >>> >>> if most people want the options file to not have the final priority, why >>> not, >>> can others spread their opinion here? >> >> An option specified on the command line is more specific and should >> have priority over saved values or configuration files. >> >> -- >> Eitan Adler > > You can already do that: > OPTIONSFILE=/my/path/to/options make config > Are you kidding? > because the priority goes to global to specific and the most specific is the > options file. I suspect no one wants to maintain different option files. As shown options file is not the most specific one, it's the command arg. ___ 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: Question about new options framework (regression?)
On Thu, Jul 26, 2012 at 07:22:24AM +0200, Olli Hauer wrote: > On 2012-07-26 06:55, Baptiste Daroussin wrote: > > On Wed, Jul 25, 2012 at 07:40:56PM -0700, Eitan Adler wrote: > >> On 25 July 2012 15:57, Baptiste Daroussin wrote: > >>> On Wed, Jul 25, 2012 at 11:24:27PM +0200, Olli Hauer wrote: > On 2012-07-25 20:18, Scot Hetzel wrote: > > On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme > > wrote: > > The following diff will restore the old behavior so make.conf and > command params have priority. > (Place the make.conf part after the OPTIONS_FILE_SET part) > > Until now I cannot see why the OPTIONS file should always win. > > >>> > >>> because the priority goes to global to specific and the most specific is > >>> the > >>> options file. > >>> > >>> if most people want the options file to not have the final priority, why > >>> not, > >>> can others spread their opinion here? > >> > >> An option specified on the command line is more specific and should > >> have priority over saved values or configuration files. > >> > >> -- > >> Eitan Adler > > > > You can already do that: > > OPTIONSFILE=/my/path/to/options make config > > > > Are you kidding? Sorry I misunderstood Eitan mail :) > > > because the priority goes to global to specific and the most specific is > > the options file. > > I suspect no one wants to maintain different option files. > As shown options file is not the most specific one, it's the command arg. pgpUBfT9lAIxN.pgp Description: PGP signature
[HEADSUP] devel/pkgconfig is gone, long live devel/pkgconf
Hi all, We have two problems with devel/pkg-config, the first one is hopefully now solved, the second one is in the slow way to be solved. Let's first start with the first one: 1/ since 0.26 devel/pkg-config expects pkg-config and glib2 to be present to be able to built, and glib2 also depends on pkg-config, this prevent bootstrapping pkg-config and thus prevented us from upgrading devel/pkg-config to a newer version than 0.25. Hopefully some people decided to work on viable alternative, one of them being devel/pkgconf, which already have the feature set from 0.27 and is in active developpement. We just switched devel/pkg-config to devel/pkgconf for that reason (see UPDATING for instructions) Now the second problem. 2/ USE_GNOME= pkgconfig macro was the most used macro to pkg-config support to your port, problem is that macro pushed both run and build dependency. Which in most cases was wrong. More than that lots of ports do not even care about pkg-config because they do depend on glib20 or xproto which run depend on it. so fixing/changing USE_GNOME= pkgconfig cannot be done in one shot, too much impact. We introduced a new macro deprecating USE_GOME= pkgconfig: USE_PKGCONFIG which can take the following arguments: - yes (equivalent to build) - build - run - both So maintainers please convert your ports to using this macro, please be really careful while converting your ports that no ports rely on your ports having a run depends on pkg-config. (this will break package building on pointyhat and any package building for binary only users!) Please also check that if your ports actually needs pkgconfig or not and if it needs it explicitly add the dependency what ever the ports you depends on are having has a dependency. regards, Bapt pgpMiB8Pmj0Ci.pgp Description: PGP signature
Re: [HEADSUP] devel/pkgconfig is gone, long live devel/pkgconf
On Thu, Jul 26, 2012 at 9:12 AM, Baptiste Daroussin wrote: > Hi all, > > We have two problems with devel/pkg-config, the first one is hopefully now > solved, the second one is in the slow way to be solved. > > Let's first start with the first one: > > 1/ since 0.26 devel/pkg-config expects pkg-config and glib2 to be present to > be > able to built, and glib2 also depends on pkg-config, this prevent > bootstrapping > pkg-config and thus prevented us from upgrading devel/pkg-config to a newer > version than 0.25. > > Hopefully some people decided to work on viable alternative, one of them being > devel/pkgconf, which already have the feature set from 0.27 and is in active > developpement. > > We just switched devel/pkg-config to devel/pkgconf for that reason (see > UPDATING for instructions) > > Now the second problem. > > 2/ USE_GNOME= pkgconfig macro was the most used macro to pkg-config support to > your port, problem is that macro pushed both run and build dependency. Which > in > most cases was wrong. > > More than that lots of ports do not even care about pkg-config because they do > depend on glib20 or xproto which run depend on it. so fixing/changing > USE_GNOME= > pkgconfig cannot be done in one shot, too much impact. > > We introduced a new macro deprecating USE_GOME= pkgconfig: > USE_PKGCONFIG which can take the following arguments: > - yes (equivalent to build) > - build > - run > - both > > So maintainers please convert your ports to using this macro, please be really > careful while converting your ports that no ports rely on your ports having a > run depends on pkg-config. (this will break package building on pointyhat and > any package building for binary only users!) > > Please also check that if your ports actually needs pkgconfig or not and if it > needs it explicitly add the dependency what ever the ports you depends on are > having has a dependency. > > regards, > Bapt Bapt, You may have noticed this already but the Makefile for devel/pkgconfig is broken, it contains the same lines twice. Thank for the good work, Kimmo ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADSUP] devel/pkgconfig is gone, long live devel/pkgconf
On Thu, Jul 26, 2012 at 9:24 AM, Kimmo Paasiala wrote: > On Thu, Jul 26, 2012 at 9:12 AM, Baptiste Daroussin wrote: >> Hi all, >> >> We have two problems with devel/pkg-config, the first one is hopefully now >> solved, the second one is in the slow way to be solved. >> >> Let's first start with the first one: >> >> 1/ since 0.26 devel/pkg-config expects pkg-config and glib2 to be present to >> be >> able to built, and glib2 also depends on pkg-config, this prevent >> bootstrapping >> pkg-config and thus prevented us from upgrading devel/pkg-config to a newer >> version than 0.25. >> >> Hopefully some people decided to work on viable alternative, one of them >> being >> devel/pkgconf, which already have the feature set from 0.27 and is in active >> developpement. >> >> We just switched devel/pkg-config to devel/pkgconf for that reason (see >> UPDATING for instructions) >> >> Now the second problem. >> >> 2/ USE_GNOME= pkgconfig macro was the most used macro to pkg-config support >> to >> your port, problem is that macro pushed both run and build dependency. Which >> in >> most cases was wrong. >> >> More than that lots of ports do not even care about pkg-config because they >> do >> depend on glib20 or xproto which run depend on it. so fixing/changing >> USE_GNOME= >> pkgconfig cannot be done in one shot, too much impact. >> >> We introduced a new macro deprecating USE_GOME= pkgconfig: >> USE_PKGCONFIG which can take the following arguments: >> - yes (equivalent to build) >> - build >> - run >> - both >> >> So maintainers please convert your ports to using this macro, please be >> really >> careful while converting your ports that no ports rely on your ports having a >> run depends on pkg-config. (this will break package building on pointyhat and >> any package building for binary only users!) >> >> Please also check that if your ports actually needs pkgconfig or not and if >> it >> needs it explicitly add the dependency what ever the ports you depends on are >> having has a dependency. >> >> regards, >> Bapt > > Bapt, > > You may have noticed this already but the Makefile for devel/pkgconfig > is broken, it contains the same lines twice. > > Thank for the good work, > > Kimmo Sorry, I meant of course the Makefile of the new devel/pkgconf :) ___ 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: [HEADSUP] devel/pkgconfig is gone, long live devel/pkgconf
On 07/25/2012 23:26, Kimmo Paasiala wrote: > Sorry, I meant of course the Makefile of the new devel/pkgconf :) Actually every file in the port was duplicated. I just fixed it since this is a pretty important thing to NOT have broken. -- Change is hard. ___ 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: [HEADSUP] devel/pkgconfig is gone, long live devel/pkgconf
On 07/25/2012 11:12 PM, Baptiste Daroussin wrote: We just switched devel/pkg-config to devel/pkgconf for that reason (see UPDATING for instructions) The content of the files in the new pkgconf port are "doubled up". http://svnweb.freebsd.org/ports/head/devel/pkgconf/Makefile?revision=301539&view=markup -- Russell A. Jackson Network Analyst California State University, Bakersfield ___ 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"
