Re: Vim and Vim-lite ports broken options
On Mon, Jul 01, 2013 at 08:10:08AM +0200, Baptiste Daroussin wrote: > I have fixed vim-lite so that its default options are sane again. I saw you mesg me on IRC, but not sure you saw my "Thank you." I'd appreicate it if folks reporting issues would first make sure they have r315730. -- -- David (obr...@freebsd.org) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The vim port needs a refresh
On Fri, May 24, 2013 at 05:23:18PM -0400, Kenta Suzumoto wrote: > - It fetches almost 700 patches from what seems like a dial-up > connection in AUSTRALIA. > You might as well be downloading a 1080p movie from a rock in the north > pole, because that's about how fast it is. > This can be very easily avoided by putting all the patches into a > single tarball Please take this up with the Vim folks. I agree the time it takes to fetch the number of patches are very anonying. I've perodically asked for an update of the distfiles to include the patches to date. Please join in asking for this of the Vim developers. But I believe vim.org is a very reliable offical distribution source and I do not want to get in the middle of their distribution methods. > P.S. we're now at 7.3.1011 - the port could use a normal update as > well. I agree. Now that we have have all the releases we've had in flight out the door, new packages sets built; and finally I can use pkgNG I am doing an update. -- -- David (obr...@freebsd.org) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The vim port needs a refresh
On Sat, May 25, 2013 at 09:50:50AM +0100, Chris Rees wrote: > For years, people have been begging him to get over his fear of > OPTIONS, and he sits in the way of progress against almost everyone's > wishes. It's funny -- it's not just my fear of options -- every FreeBSD using co-worker I talk to frequently about OPTIONS do not like them either. -- -- David (obr...@freebsd.org) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Updating "Bash"
On Thu, Jan 03, 2013 at 08:32:49AM -0500, Jerry wrote: > Bash is currently at Bash-Release: 4.2, patch level 42. The port's > version is only at patch level 37, which was released on 16-Jul-2012. > This is an important port and since the freeze is over with, I was > wondering if this port will be updated? It will be once the dust settles over the 9.1 release. -- -- David ___ 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: Can't get gvim working
On Sat, Aug 04, 2012 at 03:12:32PM -0700, Doug Barton wrote: > David, what do you think of the attached? Hi Doug, Thank you for asking. I'm OK with it. You've seem to have made this apply as narrowly as possible. Committed as r302687. Sorry I haven't committed it sooner. Vim patches have been coming out pretty fast and I haven't looked at such issues until the subversion conversion and I could get a Port update committed. -- -- David (obr...@freebsd.org) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: bash-4.2.28
On Fri, Aug 03, 2012 at 01:17:44PM -0500, Bryan Drewery wrote: > On 8/3/2012 12:52 PM, David O'Brien wrote: > > On Mon, Jul 30, 2012 at 04:17:57PM -0500, Bryan Drewery wrote: > >> On 7/25/2012 10:03 AM, Michael wrote: > >>> Any plans to update bash-4.2.28 up to patch level 037? > >>> I see we still are on patch level 028. > > > > The Bash patches did not apply cleanly. > > Works here. Simply bumping PATCHLEVEL did not lead to a buildable port. As you know xpatch-colonbreakswords did not apply cleanly. I had not committed an update as I was researching what I thought the best fix was. -- -- David (obr...@freebsd.org) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: bash-4.2.28
On Mon, Jul 30, 2012 at 04:17:57PM -0500, Bryan Drewery wrote: > On 7/25/2012 10:03 AM, Michael wrote: > > Any plans to update bash-4.2.28 up to patch level 037? > > I see we still are on patch level 028. The Bash patches did not apply cleanly. > I've submitted a patch to update to 37. > It's attached to the PR ports/170283: I'll take a look. 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: Updating Bash
On Thu, Nov 17, 2011 at 12:04:47PM -0500, Jerry wrote: > I understand that there seems to be some reluctance to updating the > "shells/bash" port until after the release of FreeBSD-9.0 at some > future date. I am not sure I understand the reasoning behind this > logic. If there is a problem with the newer version of Bash, currently > 4.1.11 in ports with version 4.2.x currently available and the soon to > be released version of 4.3 on the horizon; wouldn't it make more sense > to find out if there is in fact a problem with this shell version prior > to the release of FreeBSD-9.0? No, I do not think it would not make more sense. I really do not fully follow your argument. FreeBSD 9.0 is now in the Release Candidate stage. That means release is imminent. How long do you think it would take to determine if version 4.2 was suitable for burning on the 9.0-RELEASE DVD? If the community does not find any issues with 4.2 (either due to the code itself, or interactions with dependency ports and how we build things in /usr/ports) within say... 5 days -- does that really mean major problems won't be discovered in 10 days? Or the day after the 9.0-RELEASE ISO images are posted? To better help me understand your point of view, can you explain your immediate need for version 4.2 vs. 4.1.11? What feature or bug fix have you identified as majorly affecting you? > Bash is a commonly used shell and I cannot see what the goal of ^^ an extremely > abstaining from updating it now is? It would certainly seem that if > waiting for FBSD-9.0's release and subsequently finding out that the > newer version of Bash fails would compound fixing the problem. What problem would be compounded? And how would it be compounded? If the Bash using community truly wants version 4.2 in FreeBSD 9.0-RELEASE I am willing to do the upgrade now -- but there needs to be a super majority calling for its upgrade. [Or a directive from Portsmgr] -- -- David (obr...@freebsd.org) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: shells/bash 4.1 -> 4.2
On Sun, Nov 06, 2011 at 08:11:58PM -0500, Jason Hellenthal wrote: > Are there any plans to update this port to 4.2 yet ? Not until FreeBSD 9.0-RELEASE is done. Bash is *way* too widely used to chance a problem with a new version. -- -- David (obr...@freebsd.org) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ICAL fails to build
On Sat, Jul 02, 2011 at 12:12:46AM -0500, Scot Hetzel wrote:
> The port is only looking for tcl8.4.
[...]
> But you have tcl8.5 installed
I don't know why this port build is looking for tcl8.5.
Did some global switch from 8.4->8.5 miss something for the iCal port?
> to
> USE_TK=YES
> GNU_CONFIGURE=yes
> CONFIGURE_ARGS= --with-tclconfig=${TCL_LIBDIR} \
> --with-tclhdir=${TCL_INCLUDEDIR} \
> --with-tclsh=${TCLSH} \
> --with-tkconfig=${TK_LIBDIR} \
> --with-tkhdir=${TK_INCLUDEDIR}
I have no problem with iCal depending on 8.5 instead of 8.4.
If a PR is submitted, the first committed to see it should feel free to
commit the patch. [provided the build works ;-)]
--
-- David (obr...@freebsd.org)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: vim-lite-7.3.121
On Wed, Mar 23, 2011 at 11:13:45PM -0400, Niek Dekker wrote: > Using the "syntax on" command in .vimrc. When opening a php file in Vim, > a lot of errors are being displayed. The errors are caused by line > continuation characters in /usr/local/share/vim/vim73/syntax/php.vim. Hi I really don't know anything about PHP. Can you point out the line number (and line content) of an example of this in /usr/local/share/vim/vim73/syntax/php.vim? I found /usr/local/share/doc/antiword/antiword.php on my system and am assuming it is an OK example of a PHP file. Syntax colouring works OK with Vim 7.3.121 (non-lite). Have you tried the non-lite build? > Somehow, in FreeBSD Vim does not seem to recognize the line continuation > character and complains about it, resulting in errors when opening a > syntax file containing these characters. > > What is the solution to this, if you know any? So that I know what to look at, can you also send the error messages you are seeing (and any required file(s) to reproduce the issue? -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" ___ 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: OPTIONS
On Wed, Oct 06, 2010 at 12:01:48PM +0300, Andrew W. Nosenko wrote:
> On Wed, Oct 6, 2010 at 11:40, David O'Brien wrote:
> > On Tue, Oct 05, 2010 at 11:34:52AM -0700, David O'Brien (@FreeBSD) wrote:
> >> > 2010/10/3 Matthew Seaman :
> >> > > In fact, you might just as well write a small HTML form, display it
> >> > > using lynx or w3c or some other text mode browser[*], and then have the
> >> > > form action feed into a CGI program that outputs a small Makefile with
> >> > > appropriate variable definitions in it.
> >>
> >> I like this statement -- as it shows just how complex this will get when
> >> taken to its natural conclusion.
> >
> > This is also how ridiculous things can get:
> >
> > curl 7.21.1 now offers me:
> > ? ?[X] WERROR ? ? ? Treat compilation warnings as errors
> >
> > ? ?Can the port maintainer really not decide if that should just be
> > ? ?turned off or turned on for FreeBSD?!?
>
> I wonder why -Werror even ever considered to be turned "on" at all.
\AOL{me too}
I mean building with "-Werror" sounds like goodness -- of course I
want it.
But why is the maintainer offering me a choice?
What is the likelihood of the port not building with -Werror?
Does he know of versions of FreeBSD where the port will not build
with -Werror? Hum.. maybe I don't want -Werror. But then why didn't
the the maintainer just decide we would all not build with -Werror?
Given we are just building and installing Curl, what do we expect
users to do choose WERROR and get a build break with -Werror?
They aren't developing the next version of Curl. Can they submit a
FreeBSD PR and expect the maintainer will quickly add a patch to the
port to fix the warning(s)? Or will the response be
"Well, don't do that."? In which case just turning off -Werror for
all seems a better thing to do.
--
-- David (obr...@freebsd.org)
Q: Because it reverses the logical flow of conversation.
A: Why is top-posting (putting a reply at the top of the message) frowned upon?
Let's not play "Jeopardy-style quoting"
___
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: OPTIONS (was: editors/vim installs to /)
On Wed, Oct 06, 2010 at 02:12:18PM +0200, David DEMELIER wrote:
> 2010/10/5 David O'Brien :
> > On Sun, Oct 03, 2010 at 10:22:46AM +0200, David DEMELIER wrote:
> >> 2010/10/2 David O'Brien :
> >> > 2. With the way OPTIONS handling is done, there isn't a way for me
> >> > to query if I built with the defaults or not.
> >> > Thus leading to every port I manually install looking like it was
> >> > customized just because /var/db/ports/${PORTNAME} exists. ??Thus
> >> > implying I can no longer install the pre-build package.
> >>
> >> make rmconfig ?
> >
> > I think you've missed my point.
> >
> > That does not tell me if I, in the past, made a decision that did not
> > like the maintainer's defaults, or if I just wanted to extract the
> > sources so I could read the license or figure out what the OPTIONS knobs
> > were about, etc..
>
> I understood, you prefere a file like make.conf or ports.conf to see
> which options/knob is defined, isn't it ?
That is true - but doesn't isn't really what's behind #2 above.
In this case, I really want to now which packages are OK to upgrade using
'portupgrade -PP' (or portmaster) -- to quickly do upgrades using the
pre-built packages Portmgr spends a lot of time making available to us.
I use a script that looks for a non-zero byte /var/db/ports/$PKG/options
or any $PKG knobs in /etc/make.conf. If either is found, then
'portupgrade -PP', else just 'portupgrade'.
This is where things like 'make extract' cause a problem - since one
cannot even extract without going thru OPTIONS dialog.
--
-- David (obr...@freebsd.org)
Q: Because it reverses the logical flow of conversation.
A: Why is top-posting (putting a reply at the top of the message) frowned upon?
Let's not play "Jeopardy-style quoting"
___
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: OPTIONS
On Tue, Oct 05, 2010 at 11:34:52AM -0700, David O'Brien (@FreeBSD) wrote: > > 2010/10/3 Matthew Seaman : > > > In fact, you might just as well write a small HTML form, display it > > > using lynx or w3c or some other text mode browser[*], and then have the > > > form action feed into a CGI program that outputs a small Makefile with > > > appropriate variable definitions in it. > > I like this statement -- as it shows just how complex this will get when > taken to its natural conclusion. This is also how ridiculous things can get: curl 7.21.1 now offers me: [X] WERROR Treat compilation warnings as errors Can the port maintainer really not decide if that should just be turned off or turned on for FreeBSD?!? Do *I* really need to think about this one? But of course it doesn't offer me turning on NOPORTDOCS or NOPORTEXAMPLES, which would be useful. [I don't think any ports do...] cscope 15.7a offers me: [ ] XCSCOPE Install (X)Emacs package Do we really need to be bothered with OPTIONS to avoid installing an 87K .el file?!? -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" ___ 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: OPTIONS
On Tue, Oct 05, 2010 at 10:43:19PM +0400, Anonymous wrote: > David DEMELIER writes: > > I agree with this inconsistency, I think with a little of work OPTIONS > > framework should be to follow KNOB to enable an option if it's already > > defined by the user. This would be great for people that use > > WITHOUT_GNOME, WITHOUT_X11 and so on. I think it's possible to do it. > > I think Chris solved this one in the thread > http://docs.freebsd.org/cgi/mid.cgi?4C476F69.1060200 Unless this was also submitted as a PR -- I doubt it will ever get in. -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" ___ 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: OPTIONS
On Sun, Oct 03, 2010 at 11:45:01AM +0200, David DEMELIER wrote: > 2010/10/3 Matthew Seaman : > > On 03/10/2010 09:22:46, David DEMELIER wrote: > >> I agree. As I said in 4, OPTIONS should follow the defined knob in > >> make.conf. But for not boolean knobs there is something we can also > >> do, spawn a little textbox to define an option with a string. > >> [X] WITH_X foo bar > >> [ ] WITH_Y foo bar baz > >> [fr_FR en_GB] LANGS to be build > >> > >> Here pressing enter on LANGS would spawn a little textbox that can be > >> fulfilled by the user. The little problem is how to tell to OPTIONS > >> that it's not a boolean entry. > > > > And the rest? ??Pursuing this idea through to its logical conclusion, > > you'ld end up implementing radio buttons, text entry boxes, drop down > > lists -- all the normal bits used in html forms. > > Don't you like this? sysinstall was made with dialog. And folks hate that. jkh wanted to move the TurboC text-GUI library, but we never did. Accelerators are one of the things that dialog seems to not handle very well. In fact our OPTIONS suggest they are supported, but hitting "N" when building ports/misc/mc-light does not deselect NLS. > > In fact, you might just as well write a small HTML form, display it > > using lynx or w3c or some other text mode browser[*], and then have the > > form action feed into a CGI program that outputs a small Makefile with > > appropriate variable definitions in it. I like this statement -- as it shows just how complex this will get when taken to its natural conclusion. -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" ___ 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: OPTIONS (was: editors/vim installs to /)
On Sun, Oct 03, 2010 at 10:22:46AM +0200, David DEMELIER wrote:
> 2010/10/2 David O'Brien :
> > 2. With the way OPTIONS handling is done, there isn't a way for me
> > to query if I built with the defaults or not.
> > Thus leading to every port I manually install looking like it was
> > customized just because /var/db/ports/${PORTNAME} exists. ??Thus
> > implying I can no longer install the pre-build package.
>
> make rmconfig ?
I think you've missed my point.
That does not tell me if I, in the past, made a decision that did not
like the maintainer's defaults, or if I just wanted to extract the
sources so I could read the license or figure out what the OPTIONS knobs
were about, etc..
> The best thing to do is switch totally to a way to configure a port
> and remove the other one.
Only if folks agree on what the best way to configure a port is.
I spoke with some co-workers last week, and OPTIONS weren't very
popular with them. They also stated some of the the issues I listed.
> I think we should try to upgrade the options
> framework with what I said at 4. and 3. It's possible but we need some
> work.
Even without forcing all ports to go in one direction for configuration,
this would be a Good Thing to do. Hopefully someone with interest will
submit some patches.
--
-- David (obr...@freebsd.org)
Q: Because it reverses the logical flow of conversation.
A: Why is top-posting (putting a reply at the top of the message) frowned upon?
Let's not play "Jeopardy-style quoting"
___
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: editors/vim installs to /
On Sat, Oct 02, 2010 at 04:38:34AM -0700, Rob Farmer wrote: > On Fri, Oct 1, 2010 at 23:02, David O'Brien wrote: > > For gtk1, I have 13 packages that require it. ?For gtk2, I have 49 > > packages that require it. ?So I agree their are significantly more ports > > that depend on gtk2 -- and thus little way to avoid having it installed > > on one's system. > > > > Thoughts? > > In my experience, unless you choose one of the minimalist window > managers and are very selective about what you install, GTK 2 might as > well be part of X. Ok, I've gone ahead and changed the default GUI to gtk2. > I personally like Ade's suggestion, since it makes a gui opt-in for an > application that functions perfectly well without one. This may be a good approach to take -- but I didn't see a need to not change the default GUI for now. -- -- David (obr...@freebsd.org) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: editors/vim installs to /
On Fri, Oct 01, 2010 at 11:02:01PM -0700, David O'Brien wrote: > On Fri, Sep 17, 2010 at 05:38:21PM -0700, Rob Farmer wrote: > > However, I still think it would benefit everyone if the maintainer > > could provide an explanation for some of the current behavior and > > would at least be open to discussion about changing it. The biggest > > problem here, IMHO, is not the OPTIONS issue, but rather the use of > > GTK 1 as the default. > > I have commented on GTK2 (explained) in the past. Oh, I forgot to mention that I don't find the Vim gtk2 icons near as intuitive as the gtk1 ones. And I really take the mswin'ifcation of UNIX (gtk2 refers to "folder", where gtk1 calls the things "directory") And most of all I totally cannot stand the GNOME dumbass reversal of umpteen years of UNIX ordering of [OK] vs. [Cancel] boxes. The GNOME folks have now created major inconstancy in the ordering of the various applications I run depending on if it is a basic Motif, KDE, or GNOME toolkit consumer. The ordering inconstancy has caused my muscle memory to choose the wrong thing (loosing data). -- -- David (obr...@freebsd.org) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: editors/vim installs to /
On Fri, Sep 17, 2010 at 05:38:21PM -0700, Rob Farmer wrote:
> However, I still think it would benefit everyone if the maintainer
> could provide an explanation for some of the current behavior and
> would at least be open to discussion about changing it. The biggest
> problem here, IMHO, is not the OPTIONS issue, but rather the use of
> GTK 1 as the default.
I have commented on GTK2 (explained) in the past.
It is the kitchen sink that gtk2 brings in vs. gtk1. On my desktop
gtk2 requires 64 other packages. gtk1 requires 20.
I guess its time to take another survey. Is Vim one of the few last
gtk1 consumers?
For gtk1, I have 13 packages that require it. For gtk2, I have 49
packages that require it. So I agree their are significantly more ports
that depend on gtk2 -- and thus little way to avoid having it installed
on one's system.
> I think either defaulting to GTK 2 or just making vim a
> console application would eliminate most of these complaints.
Index: Makefile
===
RCS file: /home/pcvs/ports/editors/vim/Makefile,v
retrieving revision 1.362
diff -u -p -u -1 -r1.362 Makefile
--- Makefile2 Oct 2010 01:55:08 - 1.362
+++ Makefile2 Oct 2010 06:00:34 -
@@ -40,3 +43,3 @@ SLAVEDIRS=editors/vim-lite
-CONFLICTS= vim6* vim*-lite
+CONFLICTS= vim6* vim*-lite vim*-gtk1 vim*-gnome
MAKE_JOBS_SAFE=yes
@@ -126,4 +129,4 @@ MAKE_ARGS+= CONF_OPT_TCL="--enable-tclin
# for now default the GUI to the GTK+ one
-. if !defined(WITH_X11_ONLY) && !defined(WITH_ATHENA) && !defined(WITH_MOTIF)
&& !defined(WITH_GNOME) && !defined(WITH_GTK) && !defined(WITH_GTK2)
-WITH_GTK= yes
+. if !defined(WITH_X11_ONLY) && !defined(WITH_ATHENA) && !defined(WITH_MOTIF)
&& !defined(WITH_GNOME) && !defined(WITH_GTK1) && !defined(WITH_GTK2)
+WITH_GTK2= yes
. endif
@@ -132,3 +135,3 @@ WITH_GTK= yes
MAKE_ARGS+=CONF_OPT_GUI="--enable-gui=athena" ${I18N}
-. elif defined(WITH_GTK)
+. elif defined(WITH_GTK1)
USE_GNOME= gtk12
@@ -137,5 +140,5 @@ MAKE_ARGS+= X_LIBS="$(X_LIBS) -lXt"
USE_XORG+= xt
+PKGNAMESUFFIX= -gtk1
. elif defined(WITH_GTK2)
USE_GNOME= gtk20
-PKGNAMESUFFIX= -gtk2
MAKE_ARGS+=CONF_OPT_GUI="--enable-gui=gtk2 --with-gtk-prefix=${LOCALBASE}"
${I18N}
@@ -257,2 +260,8 @@ show-options:
+.if defined(WITH_GTK)
+.BEGIN:
+ @${ECHO_CMD} "WITH_GTK has been renamed WITH_GTK1."
+ @exit 1
+.endif
+
cklatest:
Thoughts?
--
-- David(obr...@nuxi.org)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
OPTIONS (was: editors/vim installs to /)
On Sun, Sep 19, 2010 at 10:24:59AM +0200, David DEMELIER wrote:
> What is "sufficiently clean" ? I wonder what is not clean in the
> options framework, so please tell me then we still can clean it?
When the Ports Collection was invented, ports maintainers were to
choose a reasonable set of configuration for the FreeBSD community
and have the port build that way.
Today we have ports that seem to expose every single option to GNU
configure and giving the user a puzzling choice of too many things.
Often the explanations are nothing more than restating the option
name and the user is left wondering what is X? What does Y mean?
How do I know if I really want Z or not? Why is threading so often
an OPTION and not just the default? Why do I have to go read the
packages README and INSTALLING to figure out the caveats of say
enabling threading? Or what the other list of things are and their
caveats?
1. One should not have to deal with the OPTIONS dialog just to
'make extract' if one wants to check the license or otherwise
investigate a port before deciding to install it.
2. With the way OPTIONS handling is done, there isn't a way for me
to query if I built with the defaults or not.
Thus leading to every port I manually install looking like it was
customized just because /var/db/ports/${PORTNAME} exists. Thus
implying I can no longer install the pre-build package.
3. OPTIONS are limited to only checkbox YES/NO settings.
Why can I not set PREFIX thru the OPTIONS framework and have it come
from /var/db/ports/${PORTNAME}/options on the 2nd and later builds?
Even the boolean NOPORTDOCS isn't available thru OPTIONS.
Thus it is an inconsistent way to configure a port.
4. When I build misc/mc-light and have "WITHOUT_NLS=yes" in
/etc/make.conf, why does the OPTIONS dialog offer me
"[X] NLS Enable gettext support" instead of defaulting the
dialog to unchecked?
5. One cannot opt-out of OPTIONS.
WITHOUT_OPTIONS does not work to just get the defaults while skipping
the OPTIONS dialog. Note, setting BATCH does a lot more than just
make OPTIONS non-interactive (for some ports it stops other
non-OPTIONS interaction with the user that one should see). Thus
there is no way to get an uninterrupted default build of something.
6. One cannot opt-in/opt-out on a per-port basis.
WITH[OUT]_${PORTNAME}_OPTIONS and ${PORTNAME}_WITH[OUT]_OPTIONS
should be supported to control the OPTIONS dialog just when
building ${PORTNAME}.
7. Setting ${PORTNAME}_WITH[OUT]_ (or
WITH[OUT]_${PORTNAME}_) should set
WITH[OUT]_ just when building ${PORTNAME}.
So that folks who don't want to be interrupted with OPTIONS every
time there is an update to the list can hardcode their choices in
/etc/make.conf.
8. OPTIONS make a mess in the typescript file from
'script typescript make', and the choices are totally unreadable vs.
'script typescript make -DWITH_FOO -WITHOUT_BAR'.
--
-- David (obr...@freebsd.org)
Q: Because it reverses the logical flow of conversation.
A: Why is top-posting (putting a reply at the top of the message) frowned upon?
Let's not play "Jeopardy-style quoting"
___
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: editors/vim installs to /
On Fri, Sep 17, 2010 at 09:21:46PM +0200, David DEMELIER wrote:
> I'm writing the rewrite of the port to update vim to 7.3 and with a
> real OPTIONS framework and remove the stupid WITH_VIM_OPTIONS KNOB
> that doesn't work. The problem is that David doesn't like clean things
> and I think he won't commit it because it won't be enough complicated.
No I won't commit it - I do like clean things I don't find OPTIONS to be
sufficiently clean. So please don't waste your time and mine. If you
have improvements (other than removing WITH_VIM_OPTIONS), please do send
those in.
BTW, here is one patch I am considering:
Index: options
===
RCS file: /home/ncvs/ports/editors/vim/options,v
retrieving revision 1.4
diff -u -p -r1.4 options
--- options 29 Dec 2009 08:46:57 - 1.4
+++ options 18 Sep 2010 22:37:14 -
@@ -13,3 +13,25 @@ OPTIONS= PERL "Enable Perl interpreter"
GTK2 "GTK2 GUI" off \
GNOME "Gnome1 GUI" off \
MOTIF "Motif GUI" off \
+
+pretty-print-options:
+ @${ECHO_CMD} " Vim Options ==="
+ @${ECHO_CMD} "Features:"
+ @${ECHO_CMD} " Define WITH_LITE to build the \"lite\" version."
+ @${ECHO_CMD} " Define WITH_CSCOPE to build with cscope support."
+ @${ECHO_CMD} " Define EXUBERANT_CTAGS to use exctags."
+ @${ECHO_CMD} " Define WITH_PERL to build with Perl support."
+ @${ECHO_CMD} " Define WITH_PYTHON to build with Python support."
+ @${ECHO_CMD} " Define WITH_RUBY to build with Ruby support."
+ @${ECHO_CMD} " Define WITH_TCL to build with TCL support."
+ @${ECHO_CMD}
+ @${ECHO_CMD} "Graphical User Interface (GUI):"
+ @${ECHO_CMD} " Define WITHOUT_X11 to build without GUI support."
+ @${ECHO_CMD} " Define X11_ONLY to build curses-only Vim, but with
basic X11 support."
+ @${ECHO_CMD} " Define XTERM_SAVE to restore xterm screen after exit."
+ @${ECHO_CMD} " Define WITH_ATHENA to build with Athena support."
+ @${ECHO_CMD} " Define WITH_MOTIF to build with Motif support."
+ @${ECHO_CMD} " Define WITH_GTK to build with GTK support (default)."
+ @${ECHO_CMD} " Define WITH_GTK2 to build with GTK2 support."
+ @${ECHO_CMD} " Define WITH_GNOME to build with Gnome support."
+ @${ECHO_CMD} "=="
--
-- David (obr...@freebsd.org)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[PATCH] enable MAKE_JOBS_SAFE for Vim build
This patch allows me to build Vim in parallel.
Give it a try if you're interested. Please let me know if you are
UNABLE to build with this patch applied.
[I only need to know of failures, thanks.]
--
-- David (obr...@freebsd.org)
Index: Makefile
===
RCS file: /home/pcvs/ports/editors/vim/Makefile,v
retrieving revision 1.356
diff -u -p -r1.356 Makefile
--- Makefile9 Sep 2010 06:06:28 - 1.356
+++ Makefile9 Sep 2010 07:48:48 -
@@ -39,7 +39,7 @@ SLAVEDIRS=editors/vim-lite
.endif
CONFLICTS= vim6* vim*-lite
-MAKE_JOBS_UNSAFE= yes
+MAKE_JOBS_SAFE=yes
USE_BZIP2= yes
DIST_SUBDIR= vim
WRKSRC=${WRKDIR}/vim${PORTVERSION:C/\.[0-9]*$//:S/.//g}/src
@@ -195,6 +195,9 @@ post-patch:
${REINPLACE_CMD} -e 's,ctags -R \.,${CTAGS_CMD},g')
pre-configure:
+ # Fix dependency misspelling so that 'make -j#' will work.
+ @${REINPLACE_CMD} -e 's|\./auto/osdef\.h|auto/osdef.h|g' \
+ ${WRKSRC}/Makefile
@(cd ${WRKSRC} ; ${MAKE} distclean)
@${REINPLACE_CMD} -e ' \
s|\$$gtk_config_prefix/bin/gtk-config|\$${GTK_CONFIG}|g; \
@@ -207,6 +210,9 @@ pre-configure:
${WRKSRC}/feature.h
.endif
+post-configure:
+ @(cd ${WRKSRC} ; ${MAKE} scratch config)
+
# Clean up junk files to keep them from being installed.
pre-install:
@${FIND} ${WRKSRC:H} -type f -name '*.orig' -delete
___
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"
Missing packages for 9-current
$ ftp://FreeBSD.ISC.org/pub/FreeBSD/ports/amd64/packages-9-current/ ftp> ls 229 Entering Extended Passive Mode (|||48484|). 150 Here comes the directory listing. 226 Directory send OK. ftp> This has broken 'pkg_add -r'. Does anyone know when there will be 9-CURRENT packages again? -- -- David (obr...@freebsd.org) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[PATCH] upgrade Bash port to version 4.1.
Hi Folks,
Bash 4.1 seems stable enough at PL5 to replace version 4.0 in
'/usr/ports/shells/bash'.
Does anyone feel that we need a "shells/bash40" port?
(please just let me know if you feel we do, not if you feel we don't)
The patch below is the upgrade to 4.1. It works on the workstation
undermydesk, but maybe not the one underyourdesk. Please let me know
in the next few days if you will have trouble with the updated Bash port.
thanks,
--
-- David (obr...@freebsd.org)
Index: Makefile
===
RCS file: /home/ncvs/ports/shells/bash/Makefile,v
retrieving revision 1.118
diff -u -p -r1.118 Makefile
--- Makefile14 Nov 2009 12:05:54 - 1.118
+++ Makefile9 Apr 2010 15:43:31 -
@@ -7,8 +7,8 @@
#
PORTNAME= bash
-PATCHLEVEL=35
-PORTVERSION= 4.0.${PATCHLEVEL:S/^0//g}
+PATCHLEVEL=5
+PORTVERSION= 4.1.${PATCHLEVEL:S/^0//g}
PORTREVISION?= 0
CATEGORIES=shells
MASTER_SITES= ${MASTER_SITE_GNU:S/$/:bash/} \
Index: distinfo
===
RCS file: /home/ncvs/ports/shells/bash/distinfo,v
retrieving revision 1.45
diff -u -p -r1.45 distinfo
--- distinfo14 Nov 2009 12:05:54 - 1.45
+++ distinfo9 Apr 2010 15:43:45 -
@@ -1,110 +1,20 @@
-MD5 (bash/bash-4.0.tar.gz) = a90a1b5a6db4838483f05438e05e8eb9
-SHA256 (bash/bash-4.0.tar.gz) =
9793d394f640a95030c77d5ac989724afe196921956db741bcaf141801c50518
-SIZE (bash/bash-4.0.tar.gz) = 6230779
-MD5 (bash/bash40-001) = bc7f4762443939bd7dccb42370f0d932
-SHA256 (bash/bash40-001) =
e3b514204e5da7bf1aecf7d0981514b2367d4b529da6d4a45d09dc29e2f0031b
-SIZE (bash/bash40-001) = 5156
-MD5 (bash/bash40-002) = c2a4a4786a83ed4ec366c6a8924369a2
-SHA256 (bash/bash40-002) =
495117e566019b9cb0ab49504945b30cdda6e5b59597e43e18eae1f06b1d5cf4
-SIZE (bash/bash40-002) = 1220
-MD5 (bash/bash40-003) = 22e8a824eddba21a8fce10d7984c2aba
-SHA256 (bash/bash40-003) =
e300c40611b1e3775b7d1fb73bd770ad19973c22d7016d126af3304bae797bd8
-SIZE (bash/bash40-003) = 1749
-MD5 (bash/bash40-004) = ed7cbced8c7c964323265522369a37a2
-SHA256 (bash/bash40-004) =
4b03ed1f8aea99dec4ab3ba930bd126c6b7dbaeebf219e21ce3aa6274c52d2ae
-SIZE (bash/bash40-004) = 1347
-MD5 (bash/bash40-005) = 8ed86b7d31423d71ecf3148251d63512
-SHA256 (bash/bash40-005) =
420658c026916610a07d40b71eb70f6674b78c3b3da10384c7535c15b3309450
-SIZE (bash/bash40-005) = 2021
-MD5 (bash/bash40-006) = 5f447338cb98ff156cabf1fd9879d5f3
-SHA256 (bash/bash40-006) =
c78762520f3da5f39319c3143f9eb4f4ca3351a6306cf94b7c42b3b2844d82e4
-SIZE (bash/bash40-006) = 1133
-MD5 (bash/bash40-007) = 96e946cb66a4ca186cba1da44f1ee163
-SHA256 (bash/bash40-007) =
558d559e24d15a9eedb42951f4706839322c644791d20c11ca5e958cfc0e616d
-SIZE (bash/bash40-007) = 6920
-MD5 (bash/bash40-008) = d3eb7b6f00d525e032478c33f51d46a8
-SHA256 (bash/bash40-008) =
87db24c00f83db7bdeab585dfecc76cc6ce6fd9269fce0ac7197771f3005d8fc
-SIZE (bash/bash40-008) = 1196
-MD5 (bash/bash40-009) = 340601c997ce569532417a7ae92248b8
-SHA256 (bash/bash40-009) =
0047c240617a4aa633bb699f93a4fa9caf77051f2bb85fc2e9c6c899d1df7e2b
-SIZE (bash/bash40-009) = 1821
-MD5 (bash/bash40-010) = 0bd5ab96d514ffb1afbb8c7984b15146
-SHA256 (bash/bash40-010) =
f2416f6b45ff3d9a315e41b3da023eb727f53e7dd6e8a07e88d1f2a005ee4816
-SIZE (bash/bash40-010) = 2152
-MD5 (bash/bash40-011) = 32cb20f339a20e1e9fb37a5d18f18fca
-SHA256 (bash/bash40-011) =
ffc81429efe88958356684c27a914d832c1cacb16ca6881192832ee3a18354d4
-SIZE (bash/bash40-011) = 1383
-MD5 (bash/bash40-012) = 33fd9e93d30a17988c19554ef26d56e0
-SHA256 (bash/bash40-012) =
b2c4d6e9c12a8695bc177798b9857b9dbc85a035ad83fce401e668a2de1183f3
-SIZE (bash/bash40-012) = 1459
-MD5 (bash/bash40-013) = a266b42df5e9ed7e8818a8b00d50e00b
-SHA256 (bash/bash40-013) =
760ccaf9d1f3be5d81e6bc1f8201820b42a2cdcd2a561cb0fb021b4c241e4c3a
-SIZE (bash/bash40-013) = 4629
-MD5 (bash/bash40-014) = 86cac78f191a32cd1404f11264eb9b2a
-SHA256 (bash/bash40-014) =
13edc4c691768672f680b4f266bdd1c12e7b247349eba4d30d0bd923cca1c39a
-SIZE (bash/bash40-014) = 3709
-MD5 (bash/bash40-015) = bb41963d030bc61a20e8185367b337c5
-SHA256 (bash/bash40-015) =
7ba0e2bedf54c80b58e0f471e7372c539e5a43d55eb3f1881f5b8fb649758814
-SIZE (bash/bash40-015) = 1914
-MD5 (bash/bash40-016) = f75455048a086528971252fd979b8755
-SHA256 (bash/bash40-016) =
8f3a936e928fe78ae10df109d226f79207a5418a7eded376e880fe57a571d519
-SIZE (bash/bash40-016) = 3032
-MD5 (bash/bash40-017) = 34b2cd57271a452f4a26b39d77ff908f
-SHA256 (bash/bash40-017) =
2bee2afe6339b034e3a8d88bfbf922f6f4704abf0fb56041fa693075f530f021
-SIZE (bash/bash40-017) = 1496
-MD5 (bash/bash40-018) = 99318eed8dcc05e10a14ae27043f175d
-SHA256 (bash/bash40-018) =
1db3bb8db0e386be938ce3ca9d3aff10edee57e696dec353fb134960ddc0e631
-SIZE (bash/bash40-018) = 2614
-MD5 (bash/bash40-019) = af3b9aaeadc71a5007bec2b98c751cde
-SHA256 (bash/bash40-019) =
5049948f077090c02286445a441cf8efa3
[PATCH] upgrade shells/bash 4.0 to patchlevel 28
There are some new patches to Bash 4.0. Here is the patch I plan to
commit to the port - but I wanted to let it have some "beta testing"
first.
If you have a moment and are a Bash user, please give this a try.
I only need to know if the new patchlevel causes grief.
I'm not looking for 1,000 "it works" responces. ;-)
-- David
Index: Makefile
===
RCS file: /home/pcvs/ports/shells/bash/Makefile,v
retrieving revision 1.114
diff -u -p -r1.114 Makefile
--- Makefile18 May 2009 18:44:32 - 1.114
+++ Makefile29 Jul 2009 06:36:06 -
@@ -7,7 +7,7 @@
#
PORTNAME= bash
-PATCHLEVEL=24
+PATCHLEVEL=28
PORTVERSION= 4.0.${PATCHLEVEL:S/^0//g}
PORTREVISION?= 0
CATEGORIES=shells
Index: distinfo
===
RCS file: /home/pcvs/ports/shells/bash/distinfo,v
retrieving revision 1.43
diff -u -p -r1.43 distinfo
--- distinfo18 May 2009 18:44:33 - 1.43
+++ distinfo29 Jul 2009 06:36:06 -
@@ -73,5 +73,17 @@ SIZE (bash/bash40-023) = 2148
MD5 (bash/bash40-024) = 82ba5fc9eb780eb57d8b7628a17b7d74
SHA256 (bash/bash40-024) =
a59ebac47efe31b951e1732e4223cc725b2748c331bec98248355c5ac53717ab
SIZE (bash/bash40-024) = 3049
+MD5 (bash/bash40-025) = b26f9007ac4eef5c378f1abcb8959025
+SHA256 (bash/bash40-025) =
f77900d636033474bc15d39c4948515fdfe718164ea668edd64d8d4d5a8f6a08
+SIZE (bash/bash40-025) = 3435
+MD5 (bash/bash40-026) = 83bc844c82d0a30740e8d91a8238bfa9
+SHA256 (bash/bash40-026) =
a9bdf4409c6625561884be58026a52ccb47600407f3d5b8d0889f0585040f6cb
+SIZE (bash/bash40-026) = 1433
+MD5 (bash/bash40-027) = a41c187f05ecab07389c18acc91214c6
+SHA256 (bash/bash40-027) =
f65dc26bb1bacc8a66610cd5f6f2b8e70be8d8c4e397e7a5ad6f3306224b77f2
+SIZE (bash/bash40-027) = 2010
+MD5 (bash/bash40-028) = fcc367e6471267d2e397257e703b817d
+SHA256 (bash/bash40-028) =
5b222cbaf3ab1c1d9b4c5956a0e28cad49660f5746af08efe174e7b474022d1a
+SIZE (bash/bash40-028) = 5567
MD5 (bash/FAQ) = IGNORE
SHA256 (bash/FAQ) = IGNORE
___
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: MAKE_JOBS_UNSAFE+= shells/bash, textproc/ispell
On Mon, May 04, 2009 at 08:06:45PM -0400, Philip M. Gollucci wrote: > David O'Brien wrote: >> On Fri, May 01, 2009 at 05:08:28PM -0400, Philip M. Gollucci wrote: >>> shells/bash is only failing about 2.5/8 >>> textproc/ispell is only about 2/8 >> Hi Philip, >> I'm sorry - I really don't know what this means. > > The recent parrallel make functionality pav@ added to MK/bsd.port.mk. > shells/bash is not parallel safe as it is. > Setting > MAKE_JOBS_UNSAFE=yes > notes this and allows you to set FORCE_MAKE_JOBS=yes in /etc/make.conf > and not have shells/bash fail. I was under the impression that MAKE_JOBS_UNSAFE was the default and one had to explicity put MAKE_JOBS_SAFE=yes in a port. Pav Lucistnik writes: As you might have noticed on the commit list, I have committed support for internally parallelized builds, ie. setting -jX make argument. It's opt-in, so if you want your port to make use of this feature, you will need to put MAKE_JOBS_SAFE=yes into it's Makefile. I will add MAKE_JOBS_UNSAFE=yes to the port. > I was saying that it really is a RACE condition, and not just buggy make vs > gmake code i.e. (cd x; do y) .. It only doesn't work 2.5 out of every 8 > times. Ah! -- -- David (obr...@freebsd.org) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: MAKE_JOBS_UNSAFE+= shells/bash, textproc/ispell
On Fri, May 01, 2009 at 05:08:28PM -0400, Philip M. Gollucci wrote: > shells/bash is only failing about 2.5/8 > textproc/ispell is only about 2/8 Hi Philip, I'm sorry - I really don't know what this means. -- -- David (obr...@freebsd.org) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problem with Bash-4 and $(command) syntax
On Fri, Mar 13, 2009 at 02:59:50AM -0700, GESBBB wrote: > Until a fix has been put in place, I would suggest that a notice be > placed in UPDATING that Bash-4 is not completely functional and its use > is not recommended. Better yet, maybe the port should just be marked > "BROKEN", since it clearly is. I personally would never have installed > it had I been aware of the problems it is causing.? IMHO, it should > have been tested more completely before being released into the ports > system. I have to weigh all the screams of 'I want the newest Bash 4.0 *NOW*' with testing. I didn't see the issue of $() as my .bashrc and scripts are too old and just use ``. -- -- David (obr...@freebsd.org) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: shells/bash-4.0 port horribly broken
On Thu, Mar 12, 2009 at 12:48:09PM +0100, Stefan Bethke wrote: >> The update still remains broken: >> [r...@portjail ~]$ echo $(uname) >> -bash: command substitution: line 25: syntax error near unexpected token >> `)' >> -bash: command substitution: line 25: `uname)' > > I also find this rather annoying. I believe that a rather large percentage > of people use bash as their default shell, so moving from 3.2 to 4.0 should > have been preceded by a headsup or an entry in UPDATING. I didn't have issues with my ~/.bashrc when I updated from 3.2 to 4.0 so I didn't notice this issue. (guess I'm too old school and use "`"'s). -- -- David (obr...@freebsd.org) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[PATCH] upgrade shells/bash to version 4.0
I need to get shells/bash repocopied before I can commit this.
But I wanted to let folks play with the upgrade if they wanted to.
Index: Makefile
===
RCS file: /home/ncvs/ports/shells/bash/Makefile,v
retrieving revision 1.105
diff -u -p -r1.105 Makefile
--- Makefile25 Jan 2009 20:39:54 - 1.105
+++ Makefile8 Mar 2009 09:09:08 -
@@ -7,9 +7,9 @@
#
PORTNAME= bash
-PATCHLEVEL=48
-PORTVERSION= 3.2.${PATCHLEVEL:S/^0//g}
-PORTREVISION?= 1
+PATCHLEVEL=0
+PORTVERSION= 4.0.${PATCHLEVEL:S/^0//g}
+PORTREVISION?= 0
CATEGORIES=shells
MASTER_SITES= ${MASTER_SITE_GNU:S/$/:bash/} \
ftp://ftp.cwru.edu/pub/%SUBDIR%/:faq
@@ -22,9 +22,9 @@ EXTRACT_ONLY= ${DISTNAME}${EXTRACT_SUFX
PATCH_SITES= ${MASTER_SITE_GNU} \
ftp://ftp.cwru.edu/pub/%SUBDIR%/
PATCH_SITE_SUBDIR= ${PORTNAME}/${DISTNAME}-patches/
-PATCHFILES!= /usr/bin/jot -s " " -w \
- ${PORTNAME}${PORTVERSION:R:S/.//g}-%03d \
- ${PATCHLEVEL} 1 ${PATCHLEVEL}
+#PATCHFILES!= /usr/bin/jot -s " " -w \
+# ${PORTNAME}${PORTVERSION:R:S/.//g}-%03d \
+# ${PATCHLEVEL} 1 ${PATCHLEVEL}
MAINTAINER=obr...@freebsd.org
COMMENT= The GNU Project's Bourne Again SHell
Index: distinfo
===
RCS file: /home/ncvs/ports/shells/bash/distinfo,v
retrieving revision 1.39
diff -u -p -r1.39 distinfo
--- distinfo2 Jan 2009 09:30:29 - 1.39
+++ distinfo2 Mar 2009 00:24:11 -
@@ -1,149 +1,5 @@
-MD5 (bash/bash-3.2.tar.gz) = 00bfa16d58e034e3c2aa27f390390d30
-SHA256 (bash/bash-3.2.tar.gz) =
26c99025b59e30779300b68adb764f824974d267a4d7cc1b347d14a2393f9fb4
-SIZE (bash/bash-3.2.tar.gz) = 2529838
-MD5 (bash/bash32-001) = d8e10c754f477e3f3a581af566b89301
-SHA256 (bash/bash32-001) =
beda60ce6186fafa36cd0a98db9ced42cff68daee4342cca73167fb0f2f43eaa
-SIZE (bash/bash32-001) = 1539
-MD5 (bash/bash32-002) = d38a5288b2f0ea6c9ac76b66cc74ef7d
-SHA256 (bash/bash32-002) =
a0ca49a3c47678ad074c990bdc871fcec680749b7f04f2def6527f04c589c40a
-SIZE (bash/bash32-002) = 1524
-MD5 (bash/bash32-003) = 0b90d37911827d8cb95f3b4353cc225e
-SHA256 (bash/bash32-003) =
7ec9e5e7e402e43b12bfd3a9237f4f171029fc7f58e59335abf3ccb455a5a84d
-SIZE (bash/bash32-003) = 4599
-MD5 (bash/bash32-004) = 8062f3a59631f58d78b180d83759b68a
-SHA256 (bash/bash32-004) =
3de0938673637089c3b0f0f355de377bb2be2d3fca68053dda267ca11b5998f2
-SIZE (bash/bash32-004) = 2585
-MD5 (bash/bash32-005) = 585b5943fadf0875ced243b245adde58
-SHA256 (bash/bash32-005) =
e7fecdecb12320cd6fe9aca83fab1828b76aeb5313b991883764cb9139d845b7
-SIZE (bash/bash32-005) = 5910
-MD5 (bash/bash32-006) = 1d5732e01ea938aeed42f3def131fa4d
-SHA256 (bash/bash32-006) =
8f14f81ced32bc057bc10abf6842f4a5ac172816631f2b87a5a3be4f01c0847d
-SIZE (bash/bash32-006) = 1298
-MD5 (bash/bash32-007) = dcd0cc5d801607827f7c851e72b0eabc
-SHA256 (bash/bash32-007) =
6863a712e5a68eccfb77162a9f947ffd80af648f0124c38f795ebba2be12eff8
-SIZE (bash/bash32-007) = 1375
-MD5 (bash/bash32-008) = bb3c7dd11198c0ab93d0e960bebf6256
-SHA256 (bash/bash32-008) =
ccf303b4d199d89d5efc659235f8a645376e86d294260dda4becbb61ec06667b
-SIZE (bash/bash32-008) = 1302
-MD5 (bash/bash32-009) = 434a6f29b0ca5f1ab784b2437ae8eaed
-SHA256 (bash/bash32-009) =
ef30c579419106b4b4a2d0064ef7e57ceee6cdf657f4ccd7b89c8e4fd70560d8
-SIZE (bash/bash32-009) = 1882
-MD5 (bash/bash32-010) = 2efff04dd246fcf63bd4b99f77c9a081
-SHA256 (bash/bash32-010) =
bb7df9fefe88d62ee371353edf62402a667cffba6ea202aa1c8b220308a0c612
-SIZE (bash/bash32-010) = 6293
-MD5 (bash/bash32-011) = 1dd104342f6920dfaf5efb3131e922e0
-SHA256 (bash/bash32-011) =
85bf656cfc49b1447b061341a4b1cb93ba89a41d8d1699a65aa971d1853ba472
-SIZE (bash/bash32-011) = 4776
-MD5 (bash/bash32-012) = 4f24b696ab78bdfae4f9cb7eb59b835d
-SHA256 (bash/bash32-012) =
45ef4ad98f2f218aa3acec15842ae1b833769c1dbe2f90c9bba00bbe4949fc43
-SIZE (bash/bash32-012) = 2555
-MD5 (bash/bash32-013) = 7c40addbf1187a26ae1c8373ed383442
-SHA256 (bash/bash32-013) =
9fbf893c383f45d25e5bc5c9eae8d2b349521f288945b3bd21c781784b81f693
-SIZE (bash/bash32-013) = 1852
-MD5 (bash/bash32-014) = 28e88c9f8679e99ac590d4a4a8227c56
-SHA256 (bash/bash32-014) =
62bb1a4d70f6f7938ca70a6aa7fe6f4b377ab5f450c7756b22b41de3bbd98ed6
-SIZE (bash/bash32-014) = 8141
-MD5 (bash/bash32-015) = 7c17d29675bd0d49470f162774385f80
-SHA256 (bash/bash32-015) =
de40425e83628eb7431f39340ac09b42b5fcf484a565352851961b3e917d8771
-SIZE (bash/bash32-015) = 2293
-MD5 (bash/bash32-016) = a1edaa98b4449fe2205fa75448b7b105
-SHA256 (bash/bash32-016) =
7abf66bbba3ebd6b6428190f3ebca59abdc0bfa3957f1a725489de7391c2d9f1
-SIZE (bash/bash32-016) = 1620
-MD5 (bash/bash32-017) = 889ed119bbf9d363660b9a0127f35efa
-SHA256 (bash/bash32-017) =
951aa
Ports .ko installation directory
Do we have a standard for where .ko modules should be installed? I've found the sysutils/pmap port to be pretty cool - I almost think we should bring it into the base system. Anyway, it installs into /boot/kernel (unless MODULES_WITH_WORLD is defined), which to me is just wrong. What if I've named mine /boot/foo? Its perfectly reasonable. /boot/ is for a kernel build. Looking around it seems most (all other?) ports install into /boot/modules. I really don't like the inconsistency - if I have to reinstall all my Ports .ko's after installing a new kernel than so be it. But it should be the case for all - not making it so I have to remember to do it for only one or two. Not being sure what the vast majority of Ports maintainers/developers use, I wanted to check if /boot/modules was our de-facto standard or something else. thanks, -- -- David ([EMAIL PROTECTED]) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: new wiki page: State of Packages on Sparc64
On Sat, Jan 05, 2008 at 12:57:27PM -0800, Stephen Hurd wrote: > In debugging it though, it seems that gdb doesn't support thread debugging > on sparc64 which is causing some problems... is this due to the lack of > TLS? Nope. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Patch 7.1.126 and patch 7.1.186 fo VIM
On Sat, Jan 05, 2008 at 07:08:57PM -0500, Derek Tattersall wrote: > Patch 7.1.186 to vim-7.1 is dependent on changes made in patch 7.1.126. > However, 7.1.126 will not apply cleanly to the tree in vim-7.1.tar.bz2, > as the file gui_w48.c is not in that archive. Conversation on the > vim-use list at Google shows Bram Moolenaar is willing to make special > patch as 7.1.126ne. This will probably cause some changes to be made to > the vim Makefile. Is this the right way to correct this problem? Good enough I guess. As long as it doens't happen often, as I have to specical case the patch name as I generate them using a 'jot' 1-liner. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: configure editors/vim
On Sun, Sep 16, 2007 at 01:33:26PM +1000, Peter Jeremy wrote: > On Sat, Sep 15, 2007 at 09:33:44AM +0200, Markus Hitter wrote: > > Time to fix your system? It doesn't happen on my 6.2-RELEASE. I'm > > running ports stuff as root. > > It won't happen when you run things as root, only when you run as an > ordinary user. I don't see it in 6.2 either. It only seems to affect > -current for me. And I think it only affects some shells - I use zsh. > > I think I first saw this around the middle of last year. I think that is about the time I started seeing it. I'm using Bash [of course]. -- -- David ([EMAIL PROTECTED]) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vim-script ports
On Fri, Sep 14, 2007 at 09:00:58PM +0400, Andrew Pantyukhin wrote: > On Wed, Oct 18, 2006 at 10:29:05AM +0400, Andrew Pantyukhin wrote: > > Any particular reason for no vim scripts in ports? > > I'm gonna make some, if there's no secret taboo. > > Better late than never :-) For the past two days I've been > playing with some vim scripts. Here's a pre-alpha version of It all cool with me. :-) Vi[m] rules!! -- -- David ([EMAIL PROTECTED]) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: configure editors/vim
On Sat, Sep 15, 2007 at 09:33:44AM +0200, Markus Hitter wrote: > >Brownie ports for someone that can explain why this always happens > >for me > >with ports that have OPTIONS: > > > >bash$ make > >cd /usr/ports/editors/vim && make config; > >===> Switching to root credentials to create /var/db/ports/vim > >Password: > >===> Returning to user credentials > >[3]+ Stopped WITH_OPTIONS=1 make > > Time to fix your system? It doesn't happen on my 6.2-RELEASE. I'm > running ports stuff as root. Tell me how and I will. :-) Of course when I do 'make clean install' as root, I'm not asked by the ports system to su to root. But when one does as a normal user, one is - by the system in /usr/ports/Mk. -- -- David ([EMAIL PROTECTED]) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: configure editors/vim
On Thu, Sep 13, 2007 at 06:00:02PM +0200, Martin Tournoij wrote:
> > As vim port have no configuration options, it can't be configured
> > easyly through 'make config'. I'm too lazy for digging Makefile for
> > options every time I compile new version of vim, I added
> > configuration options to Makefile. I'm new to FreeBSD, also to it's
> > Ports, so maybe I don't see the reasons, these options aren't in the
> > Makefile, but maybe they should be there. Anyway, I attach my
> > change, maybe it will be acceptable to have it's way to ports. And if
> > not, maybe it will help for someone else too :)
Hum.. if there is some demand for OPTIONS feature, what do folks think
about this patch?
Brownie ports for someone that can explain why this always happens for me
with ports that have OPTIONS:
bash$ make
cd /usr/ports/editors/vim && make config;
===> Switching to root credentials to create /var/db/ports/vim
Password:
===> Returning to user credentials
[3]+ Stopped WITH_OPTIONS=1 make
Index: Makefile
===
RCS file: /home/pcvs/ports/editors/vim/Makefile,v
retrieving revision 1.305
diff -u -p -r1.305 Makefile
--- Makefile11 Sep 2007 19:22:31 - 1.305
+++ Makefile15 Sep 2007 02:05:41 -
@@ -29,6 +29,10 @@ COMMENT?=Vi "workalike", with many addi
SLAVEDIRS= editors/vim-lite
+.if defined(WITH_OPTIONS) || defined(WITH_VIM_OPTIONS)
+.include "${.CURDIR}/options"
+.endif
+
.if defined(PACKAGE_BUILDING) && !defined(LITE)
#WITH_TCL= yes
WITH_PERL= yes
Index: options
===
RCS file: options
diff -N options
--- /dev/null 1 Jan 1970 00:00:00 -
+++ options 15 Sep 2007 02:05:41 -
@@ -0,0 +1,10 @@
+OPTIONS= PERL "Enable Perl interpreter" off \
+ PYTHON "Enable Python interpreter" off \
+ RUBY "Enable Ruby interpreter" off \
+ CSCOPE "Enable cscope" off \
+ EXUBERANT_CTAGS "Use exctags instead of ctags" off \
+ ATHENA "Athena GUI" off \
+ GTK2 "GTK2 GUI" off \
+ GNOME "Gnome1 GUI" off \
+ MOTIF "Motif GUI" off \
+ XTERM_SAVE "" off
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: configure editors/vim
On Thu, Sep 13, 2007 at 06:00:02PM +0200, Martin Tournoij wrote: > On Thu 13 Sep 2007 14:09, Gergely S???nta wrote: > > Hi! I'm a developer using gvim with it's tagging through exctags > > (somehow ctags never worked for me). As vim port have no > > configuration options, it can't be configured easyly through 'make > > config'. I'm too lazy for digging Makefile for options every time I > > compile new version of vim, I added configuration options to > > Makefile. I'm new to FreeBSD, also to it's Ports, so maybe I don't > > see the reasons, these options aren't in the Makefile, but maybe they > > should be there. Anyway, I attach my change, maybe it will be > > acceptable to have it's way to ports. And if not, maybe it will help > > for someone else too :) .. > > +OPTIONS= PERL "Enable Perl interpreter" off \ I appreciate a patch being sent in. But, sorry no - I am one of those that do not care for our current OPTIONS implementation. Note that I don't believe the build options have changed for Vim for the past 4 years. I simply put them in /etc/make.conf once, and I have them for all my Vim builds. Patches that make it easier to document the WITH_ knobs are appreciated. -- -- David ([EMAIL PROTECTED]) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
