Re: Why do we not mark vulnerable ports DEPRECATED?
On 08/29/2011 23:25, Mark Linimon wrote: > So, the right answer may be "it depends". I think my point is, it shouldn't. If a port is important/popular than it will be quickly fixed. If not, it goes away. Everyone wins. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Why do we not mark vulnerable ports DEPRECATED?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/30/11 01:17, Doug Barton wrote: > On 08/29/2011 23:25, Mark Linimon wrote: >> So, the right answer may be "it depends". > > I think my point is, it shouldn't. If a port is important/popular > than it will be quickly fixed. If not, it goes away. Everyone > wins. Personally I do support this idea. By the way vuxml is essentially a BROKEN if portaudit is installed. Perhaps we should have that in base system or the build cluster? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOXKFYAAoJEATO+BI/yjfBwkYH/2hDRqHEHztCDybJ4pE6u682 tURpASOWJgxkFn0xT1GF0VL9iwULWbboPdKVhWWPKAZiOWezJbepPeQv4Lcvbqqs GB28I6DPyRIDES1eqAVJ9RbjP8LgUCTMBu2LU8YCkB1Zrbg9fXD5I0amEXaDTVoc vBPM2uiWjx49/vgBRjSYKo2KG4MxOAt0PS+SlxXD5eeNodJmMLq8ipL6nA0ptA03 /l8ymf5wbNIWTmBm98CY1bIzxtVb1zcvkHPZRe4fPPXCFElrh6qCou09XJxoWg3P sTaf6kIpCxTcPsKCdAipo5OvcnXh66Kn4hlKpvc3mKwYr5jMN69d9KqSaLw0HM4= =02aU -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: Ports system quality
Chad Perrin wrote: >Of course, your goal is apparently to >convince me that yours are the "correct" priorities. Indeed i think having the correct priorities is essential when choosing between different options, and i am sincerely convinced that my choices are shared by a lot more people than yours. For example, having "less bloat" in the system doesn't even appear in the radar of most people. I value much more that hardware is supported, that installation and upgrade are easy, troubleless. Like everyone else i am irritated by some developments in the Ubuntu experience, for example the parallel booting stuff, which doesn't work well (but that people would like to imitate in FreeBSD), but all those problems remain minor. A few days ago i went to a store to buy a new laptop, i went with two CDROMs, an Ubuntu one and a FreeBSD one. Guess which of the two supported the network controllers in the laptops i tried? -- Michel TALON ___ 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: Why do we not mark vulnerable ports DEPRECATED?
Doug Barton wrote: > I'm doing some updates and came across mail/postfix-policyd-spf which > relies on mail/libspf2-10. The latter had a vuxml entry added on > 2008-10-27. So my question is, why has mail/libspf2-10 been allowed to > remain in the tree vulnerable for almost 3 years? > > Wouldn't it make more sense to mark vulnerable ports DEPRECATED > immediately with a short expiration? When they get fixed they get > un-deprecated. If they don't, they get removed. Can someone explain why > this would be a bad idea? Many vulnerabilities are only an issue for certain program configurations, for example most Firefox vulnerabilities seem to require JavaScript being enabled for a site or connection controlled by the attacker. I haven't checked what the problems with mail/libspf2-10 are (or were), but I don't think all vulnerabilities should be treated the same. In my opinion having a vuxml entry is sufficient, the rest is up to the user. I agree with Xin Li's suggestion that it may make sense to import portaudit to make sure the user is actually aware of the entry, though. Fabian signature.asc Description: PGP signature
Re: Ports system quality
On 30 Aug 2011 10:15, "Michel Talon" wrote: > > Chad Perrin wrote: > > >Of course, your goal is apparently to > >convince me that yours are the "correct" priorities. > > Indeed i think having the correct priorities is essential when choosing > between different options, and i am sincerely convinced that my choices > are shared by a lot more people than yours. For example, having "less > bloat" in the system doesn't even appear in the radar of most people. > I value much more that hardware is supported, that installation and > upgrade are easy, troubleless. Like everyone else i am irritated by > some developments in the Ubuntu experience, for example the parallel > booting stuff, which doesn't work well (but that people would like to > imitate in FreeBSD), but all those problems remain minor. A few days ago > i went to a store to buy a new laptop, i went with two CDROMs, an Ubuntu > one and a FreeBSD one. Guess which of the two supported the network > controllers in the laptops i tried? > Did you deliberately pick the laptops with strange network controllers, or just use an old version of FreeBSD? Which version did you use? Chris ___ 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: Problems building devel/gobject-introspection
On 2011-Aug-29 13:45:34 +0400, Ruslan Mahmatkhanov wrote: >Peter Jeremy wrote on 29.08.2011 07:29: >> Turns out that my python was dodgy. ... >And did you realize what python option had triggered that? I'm curious >since i'm wasn't able to reproduce it here. For me it looks like >upstream bug dealing with unicode() vs str() output, since errors like >that you provide in original message may be fixed by `setenv LANG C` in >most of cases. I've done some experiments but have not been able to reproduce the problem - which is annoying. I agree it looks locale-related but I don't have any locale-related variables set. -- Peter Jeremy pgp5C4GiQcKwS.pgp Description: PGP signature
Re: OPTIONS framework bug vs. SSL issues
Am 28.08.2011 22:42, schrieb Doug Barton:
> On 8/28/2011 10:46 AM, Sahil Tandon wrote:
>> On Sun, 2011-08-28 at 19:41:02 +0200, Matthias Andree wrote:
>>
>>> just a brain flash: bsd.port.mk currently re-prompts OPTIONS if
>>> they've changed, for instance, through addition.
>>>
>>> Should we change this feature in b.p.mk so that it also re-prompt the
>>> user when the defaults have changed?
>
> The way that (for example) portmaster works now is that if the user has
> already answered the questions for that port they don't get the dialog
> again unless a knob has been added or deleted. Personally I would find
> it surprising to be presented with the dialog again if there were no
> changes to the set of options. I wouldn't see a change in defaults in
> this case since my answers are already going to be filled in.
>
> For this specific case I probably would have changed the language of the
> gnutls option to make it clear that it needs to be un-selected, and
> added a no-op OPTION to make sure that users saw the dialog.
Euhm, while workable I don't like that approach. And I conclude that
the way the OPTIONS system currently works has a serious shortcoming, in
that it does not report changed defaults to the user.
Basically in this situation ("default changed") we'd need to:
1. present the options form again
2. mention to the user that the default has changed
3. let him choose.
What might help in the longer term is having sort of tree/four-state
options, with "user-set to off" "user-set to on", "user does not care"
and/or "user said go with whatever the default is".
Arguably we might have wanted to kill the OPTIONS on cups* altogether,
and waive the BROKEN tag this time
Dirk, do we have any hints that the CUPS-refuses-GNUTLS will be resolved
in the foreseeable future? If not, can we just bite the bullet and
remove the OPTIONS and force OpenSSL builds even though it might cause
license concerns deeper down the dependency tree?
___
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: Ports system quality
On Tue, Aug 30, 2011 at 11:13:58AM +0200, Michel Talon wrote: > i went to a store to buy a new laptop, i went with two CDROMs, an Ubuntu > one and a FreeBSD one. Guess which of the two supported the network > controllers in the laptops i tried? And guess which of them ran binary blobs. ___ 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: Libreoffice plan
On 24/08/2011 12:13, Baptiste Daroussin wrote: libreoffice as openoffice are difficult ports to maintain, to not hesitate to join the office@ team to help, test, discuss about the office related task. Not volunteering but just wanted to thank you - I really couldn't use FreeBSD on any desktop without OOo/LO! ___ 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 framework bug vs. SSL issues
On Mon, Aug 29, 2011 at 11:40:25AM +0200, Matthias Andree wrote:
> Euhm, while workable I don't like that approach. And I conclude that
> the way the OPTIONS system currently works has a serious shortcoming, in
> that it does not report changed defaults to the user.
>
> Basically in this situation ("default changed") we'd need to:
>
> 1. present the options form again
> 2. mention to the user that the default has changed
> 3. let him choose.
I don't think that this is the right way to go. You are forcing
the user to rethink his past decision(s). Why would I want to do this?
The user decided to go a specific path by initially choosing a
specific set of OPTIONs. We *must* assume that the user had good
reasons to do so. We should *not* assume the user has no idea what
he's doing and needs to be guided. The latter would make make the
update process just more complicated.
To me the Ports System is mainly for expert users. Most of them will
track changes and test (port/software) updates before installing
this update on important systems.
Bye
- Frank
___
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: cvs commit: ports/mail/procmail Makefile
Am 30.08.2011 10:23, schrieb Sunpoet Po-Chuan Hsieh: > sunpoet 2011-08-30 08:23:18 UTC > > FreeBSD ports repository > > Modified files: > mail/procmailMakefile > Log: > - Take maintainership > > Revision ChangesPath > 1.60 +1 -1 ports/mail/procmail/Makefile I was just about to grab the port, deprecate and set two months expiration date. Now that you're maintaining it I seek you to please let this unmaintained unclean code from our FreeBSD ports world and deprecate it. The code is unmaintainable, hasn't seen maintenance in a decade, is hard to use properly because of its fall-through "error handling" (actually nonhandling) behaviour, and should finally disappear. Please add DEPRECATED= use mail/maildrop instead EXPIRATION_DATE=2011-10-31 maildrop (courier's filtering agent) has been around for nearly as long and works well. Thank you. Best, Matthias ___ 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 framework bug vs. SSL issues
Am 30.08.2011 12:28, schrieb Frank Wall:
> On Mon, Aug 29, 2011 at 11:40:25AM +0200, Matthias Andree wrote:
>> Euhm, while workable I don't like that approach. And I conclude that
>> the way the OPTIONS system currently works has a serious shortcoming, in
>> that it does not report changed defaults to the user.
>>
>> Basically in this situation ("default changed") we'd need to:
>>
>> 1. present the options form again
>> 2. mention to the user that the default has changed
>> 3. let him choose.
>
> I don't think that this is the right way to go. You are forcing
> the user to rethink his past decision(s). Why would I want to do this?
Because you must, the former default configuration, even if you've
acknowledged it as an informed decision you've made, no longer works.
> The user decided to go a specific path by initially choosing a
> specific set of OPTIONs. We *must* assume that the user had good
> reasons to do so. We should *not* assume the user has no idea what
> he's doing and needs to be guided. The latter would make make the
> update process just more complicated.
The point is, most users just agree to the defaults, and in that
situation, there is reason to re-prompt.
One might argue that we don't need to reprompt if the new default
matches the old configuration, but the OPTIONS framework currently
doesn't know "user set this deliberately" or "user just stuck to the
defaults".
___
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: cvs commit: ports/mail/procmail Makefile
Hi! > > Modified files: > > mail/procmailMakefile [...] > Now that you're maintaining it I seek you to please let this > unmaintained unclean code from our FreeBSD ports world and deprecate it. [...] > maildrop (courier's filtering agent) has been around for nearly as long > and works well. - Can maildrop be used with other MTAs like exim ? - Can it use the 700+ lines long .procmailrc I have running in a criticial application or do I have to migrate that ? Thanks! -- p...@opsec.eu+49 171 3101372 9 years to go ! ___ 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: cvs commit: ports/mail/procmail Makefile
Matthias Andree wrote on 30.08.2011 15:06: Am 30.08.2011 10:23, schrieb Sunpoet Po-Chuan Hsieh: sunpoet 2011-08-30 08:23:18 UTC FreeBSD ports repository Modified files: mail/procmailMakefile Log: - Take maintainership Revision ChangesPath 1.60 +1 -1 ports/mail/procmail/Makefile I was just about to grab the port, deprecate and set two months expiration date. Now that you're maintaining it I seek you to please let this unmaintained unclean code from our FreeBSD ports world and deprecate it. The code is unmaintainable, hasn't seen maintenance in a decade, is hard to use properly because of its fall-through "error handling" (actually nonhandling) behaviour, and should finally disappear. Please add DEPRECATED= use mail/maildrop instead EXPIRATION_DATE=2011-10-31 or mail/getmail maildrop (courier's filtering agent) has been around for nearly as long and works well. Thank you. Best, Matthias -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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: cvs commit: ports/mail/procmail Makefile
Am 30.08.2011 13:11, schrieb Kurt Jaeger:
> Hi!
>
>>> Modified files:
>>> mail/procmailMakefile
> [...]
>> Now that you're maintaining it I seek you to please let this
>> unmaintained unclean code from our FreeBSD ports world and deprecate it.
> [...]
>> maildrop (courier's filtering agent) has been around for nearly as long
>> and works well.
>
> - Can maildrop be used with other MTAs like exim ?
Yes.
> - Can it use the 700+ lines long .procmailrc I have running
> in a criticial application or do I have to migrate that ?
You'd have to migrate that.
On the other hand, a 700+ line long .procmailrc "in a critical
application" is usually a mistake in itself already and always was,
unless you're one of the few who has a recipe like
:0e
{
EXITCODE=75
HOST
}
after each and every single recipe that can fail in some way (most
importantly, delivering recipes).
Few people know it's necessary, as it's not explicitly documented, but
just working around documented fall-through behaviour -- and as a side
effect it voids the "else"-style recipes.
Beyond that, there are pending bug fixes that never made it into a
release, check the 3.23pre announcement at
Bottom line: the sooner we get rid from procmail the better.
___
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: cvs commit: ports/mail/procmail Makefile
On Tue, Aug 30, 2011 at 01:11:52PM +0200, Kurt Jaeger wrote: > - Can it use the 700+ lines long .procmailrc I have running > in a criticial application or do I have to migrate that ? I would suggest to migrate to something new. While searching for a procmail replacement myself, I've even found a script to migrate procmail rules to SIEVE instructions: http://www.dovecot.org/tools/procmail2sieve.pl Bye - Frank ___ 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: cvs commit: ports/mail/procmail Makefile
[maildrop] > > - Can it use the 700+ lines long .procmailrc I have running > > in a criticial application or do I have to migrate that ? > > You'd have to migrate that. That's what I assumed. > Bottom line: the sooner we get rid from procmail the better. There are many other applications that have issues, as well. It's already a lot of work just to keep up with the bug-de-jour and the upgrade-de-jour and doing it all in parallel does not scale very well. Therefore, one has to choose what one can work on. If the fbsd ports drop procmail, it will just add more on my plate that I have to do myself. Similar to many other apps and ports and you-name-it. While I dislike bitrot like anyone else, I have an issue with the dropping of ports in general, because that will not scale. I'm aware, that the other approach (keeping everything) does not scale either. I've read the recent mail flood on ports etc. I maintain approx. 200 boxes, so I know the issues at hand, but right now, I can't offer solutions. It's just not looking good either way. -- p...@opsec.eu+49 171 3101372 9 years to go ! ___ 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 framework bug vs. SSL issues
Matthias Andree writes: > > The user decided to go a specific path by initially choosing a > > specific set of OPTIONs. We *must* assume that the user had good > > reasons to do so. We should *not* assume the user has no idea what > > he's doing and needs to be guided. The latter would make make the > > update process just more complicated. > > The point is, most users just agree to the defaults, Which makes me one of "most users". I'll even confess to occasionally changing OPTIONS (during initial installation) more-or-less on a whim, usually but not always of the "of course this should have IPv6/threads/xml enabled" variety. (Which may remove me from "most". :-) > > and in that > situation, there is reason to re-prompt. Agreed. An alternative - which might not be much less work - would be simple notification, e.g. "The default build options for port foo/bar have changed.". > One might argue that we don't need to reprompt if the new default > matches the old configuration, but the OPTIONS framework > currently doesn't know "user set this deliberately" or "user just > stuck to the defaults". Reprompting/notifying will be a pain. The alternative is users whose expected installation differs from reality. Robert Huff ___ 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"
Python min version bumped from 2.4+ to 2.5+
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Martin, I have a question about a commit you made in February 2011: http://www.freshports.org/commit.php?message_id=201102250750.p1p7ofdg016...@repoman.freebsd.org&files=yes Part of the commit changed: USE_PYTHON= 2.4+ to USE_PYTHON= 2.5+ Was there a specific reason for doing so? I am running various tinderbox builds to check on port usage of the USE_PYTHON variable, and I noticed that devel/py-setuptools no longer builds if Python 2.4 is selected. I'd like to restore that capability, but before I send a PR, I wanted to check with you first. Thank you, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/cpucycle/ - Follow you, follow me -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5c4BUACgkQ0sRouByUApDZKwCeMcUjlshPkFhNZrTQtQ1+Ywyu bNQAnjkkk0Sf1ntQXawhiMyhamPz0haz =aOJw -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: Python min version bumped from 2.4+ to 2.5+
Greg Larkin wrote on 30.08.2011 17:05: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Martin, I have a question about a commit you made in February 2011: http://www.freshports.org/commit.php?message_id=201102250750.p1p7ofdg016...@repoman.freebsd.org&files=yes Part of the commit changed: USE_PYTHON= 2.4+ to USE_PYTHON= 2.5+ Was there a specific reason for doing so? I am running various tinderbox builds to check on port usage of the USE_PYTHON variable, and I noticed that devel/py-setuptools no longer builds if Python 2.4 is selected. I'd like to restore that capability, but before I send a PR, I wanted to check with you first. Thank you, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/cpucycle/ - Follow you, follow me I'm sorry for sail in, but i think that the reason is that python24 is reached it's EOL long time ago. Actually the only supported python releases atm according to python.org are - 2.7.2 and 3.2.1, and developers highly encourages the users to move to this versions. 2.5 and 2.6 are in security-fix-only mode, there will be no ANY releases for this branches after October 2011 and October 2013 respectively, while 2.4 does not get security-fixes even. There is also this answer from Martin in this pr: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/155526: python24 goes to the end of month, this port is on the todo for removal -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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"
mail/popper, mail/premail and mail/miltergreylist maintainership
Hi, I'd like to take maintainership of following unmaintained now ports: mail/popper mail/miltergreylist mail/milter-greylist-devel mail/premail -- Mikhail m.tsatse...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python min version bumped from 2.4+ to 2.5+
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/30/11 9:38 AM, Ruslan Mahmatkhanov wrote: > Greg Larkin wrote on 30.08.2011 17:05: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi Martin, >> >> I have a question about a commit you made in February 2011: >> http://www.freshports.org/commit.php?message_id=201102250750.p1p7ofdg016...@repoman.freebsd.org&files=yes >> >> >> Part of the commit changed: >> >> USE_PYTHON=2.4+ >> >> to >> >> USE_PYTHON=2.5+ >> >> Was there a specific reason for doing so? I am running various >> tinderbox builds to check on port usage of the USE_PYTHON variable, and >> I noticed that devel/py-setuptools no longer builds if Python 2.4 is >> selected. >> >> I'd like to restore that capability, but before I send a PR, I wanted to >> check with you first. >> >> Thank you, >> Greg >> - -- >> Greg Larkin >> >> http://www.FreeBSD.org/ - The Power To Serve >> http://www.sourcehosting.net/ - Ready. Set. Code. >> http://twitter.com/cpucycle/ - Follow you, follow me > > I'm sorry for sail in, but i think that the reason is that python24 is > reached it's EOL long time ago. Actually the only supported python > releases atm according to python.org are - 2.7.2 and 3.2.1, and > developers highly encourages the users to move to this versions. > > 2.5 and 2.6 are in security-fix-only mode, there will be no ANY releases > for this branches after October 2011 and October 2013 respectively, > while 2.4 does not get security-fixes even. > > There is also this answer from Martin in this pr: > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/155526: > > python24 goes to the end of month, this port is on the todo for removal > Hi Ruslan, Ok, thank you for the explanation. Shall I mark python24 for removal from the tree or file a PR for python@ to do it? FYI, I have been running tinderbox builds with PYTHON_VERSION and PYTHON_DEFAULT_VERSION set to python2.4, python2.5, etc. to find out if ports with USE_PYTHON=yes need to be constrained a bit more. I figured that python2.4 was supported since it was still in the tree and wasn't marked for removal yet, but I admin that I didn't check python.org for confirmation. Regards, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/cpucycle/ - Follow you, follow me -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5c7B4ACgkQ0sRouByUApAZOQCcC0YgAzDxDj78I9u35+H53fur be8AmQFjWrGJ/xmjYpPp6ZkKB+ejDfq9 =tK4y -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: Python min version bumped from 2.4+ to 2.5+
Greg Larkin wrote on 30.08.2011 17:56: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/30/11 9:38 AM, Ruslan Mahmatkhanov wrote: Greg Larkin wrote on 30.08.2011 17:05: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Martin, I have a question about a commit you made in February 2011: http://www.freshports.org/commit.php?message_id=201102250750.p1p7ofdg016...@repoman.freebsd.org&files=yes Part of the commit changed: USE_PYTHON=2.4+ to USE_PYTHON=2.5+ Was there a specific reason for doing so? I am running various tinderbox builds to check on port usage of the USE_PYTHON variable, and I noticed that devel/py-setuptools no longer builds if Python 2.4 is selected. I'd like to restore that capability, but before I send a PR, I wanted to check with you first. Thank you, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/cpucycle/ - Follow you, follow me I'm sorry for sail in, but i think that the reason is that python24 is reached it's EOL long time ago. Actually the only supported python releases atm according to python.org are - 2.7.2 and 3.2.1, and developers highly encourages the users to move to this versions. 2.5 and 2.6 are in security-fix-only mode, there will be no ANY releases for this branches after October 2011 and October 2013 respectively, while 2.4 does not get security-fixes even. There is also this answer from Martin in this pr: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/155526: python24 goes to the end of month, this port is on the todo for removal Hi Ruslan, Hi Greg Ok, thank you for the explanation. Shall I mark python24 for removal from the tree or file a PR for python@ to do it? It's not so easy actually, since we have many ports in the tree that still depend on 2.4 (notably all that zope/plone stuff) and i believe it was the reason why python24 still not be removed in the first place. I do some work about eliminating python24 usage in the tree (yesterdays py-pysqlite2x stuff - one of it), but it's not that fast. I also working on porting zope2.13/plone4 (that supports python 2.6 and 2.7) and i'm planing to finish it this weekend after proper testing. After that we can deprecate/remove existing zope/plone (not longer supported upstream). FYI, I have been running tinderbox builds with PYTHON_VERSION and PYTHON_DEFAULT_VERSION set to python2.4, python2.5, etc. to find out if ports with USE_PYTHON=yes need to be constrained a bit more. Yes, there is a lot of work. We have USE_PYTHON with bogus values like 1.5+, 1.6+, 2.0+ etc :). And most of python ports will not work with python3x so they should be constrained with -2.7 too. I figured that python2.4 was supported since it was still in the tree and wasn't marked for removal yet, but I admin that I didn't check python.org for confirmation. As i already stated, i believe it's still there because there is dependent ports. And as far i know in linux world noone shipping python24 this days. Even RHEL/CentOS finally switched to 2.6.5 in their 6.x branches. Regards, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/cpucycle/ - Follow you, follow me -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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: cvs commit: ports/mail/procmail Makefile
On Tue, 30 Aug 2011, Matthias Andree wrote: Am 30.08.2011 10:23, schrieb Sunpoet Po-Chuan Hsieh: sunpoet 2011-08-30 08:23:18 UTC FreeBSD ports repository Modified files: mail/procmailMakefile Log: - Take maintainership Revision ChangesPath 1.60 +1 -1 ports/mail/procmail/Makefile I was just about to grab the port, deprecate and set two months expiration date. Now that you're maintaining it I seek you to please let this unmaintained unclean code from our FreeBSD ports world and deprecate it. The code is unmaintainable, hasn't seen maintenance in a decade, is hard to use properly because of its fall-through "error handling" (actually nonhandling) behaviour, and should finally disappear. Please add DEPRECATED= use mail/maildrop instead EXPIRATION_DATE=2011-10-31 Even if there was a drop-in replacement, that seems way too early to let people get it deployed. Some initial searching shows that maildrop is a functional replacement and can be used with sendmail's local_procmail feature, but the rules are different. There could be other functionality which users depend on, like formail, which a replacement might not have. For now, a pkg-message for mail/procmail that suggests alternates, and why, would give users some time to prepare. ___ 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: cvs commit: ports/mail/procmail Makefile
Matthias Andree wrote: > Am 30.08.2011 10:23, schrieb Sunpoet Po-Chuan Hsieh: > > sunpoet 2011-08-30 08:23:18 UTC > > > > FreeBSD ports repository > > > > Modified files: > > mail/procmailMakefile > > Log: > > - Take maintainership > > > > Revision ChangesPath > > 1.60 +1 -1 ports/mail/procmail/Makefile > > I was just about to grab the port, deprecate and set two months > expiration date. Sorry No, it would be most irresponsible to consider a timeout of 2 months ! Procmail has been compiling regularly, working fine & vitaly necessary here for a decade. If one were considering to toss out such a vital tool, one should give a warning of a release or 2. (*) > Now that you're maintaining it I seek you to please let this > unmaintained unclean code from our FreeBSD ports world and deprecate it. Sunpoet please ignore Matthias ! Take your time. > The code is unmaintainable, hasn't seen maintenance in a decade, > is hard to use properly because of its fall-through "error handling" > (actually nonhandling) behaviour, It's not hard to use, Read the manual & learn. Examples http://www.berklix.com/~jhs/dots/.procmailrc http://www.berklix.com/~jhs/dots/.procmailrc.lists more in: http://www.berklix.com/~jhs/dots/ > and should finally disappear. No > Please add > > DEPRECATED= use mail/maildrop instead No, > EXPIRATION_DATE= 2011-10-31 (*) Irresponsible lack of warning ! Lots of users of releases dont even read ports@ ( Reminds me of the Hitch Hikers Guide episode where the vogons come to destroy the earth, & claim due warning was lodged in Alpha Centauri ;-) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ 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: Ports system quality
On Tue, Aug 30, 2011 at 11:13:58AM +0200, Michel Talon wrote: > Chad Perrin wrote: > > > >Of course, your goal is apparently to > >convince me that yours are the "correct" priorities. > > Indeed i think having the correct priorities is essential when choosing > between different options, and i am sincerely convinced that my choices > are shared by a lot more people than yours. You're right that having the "correct" priorities is good. You're probably right that more people have your OS preference priorities than I do. Popularity doesn't mean something is "correct", though, and popularity of particular priorities for OS choice doesn't mean a given OS project should emulate those priorities. Would you suggest that every high-quality steakhouse in the United States should emulate the food preparation policies of McDonald's? The world needs an OS that serves the preferences FreeBSD serves so much better than Ubuntu, because the fact that a set of priorities favoring Ubuntu is more popular is not synonymous with the notion that it's ubiquitous. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpFAnTxlCcIv.pgp Description: PGP signature
Re: Why do we not mark vulnerable ports DEPRECATED?
On Mon, Aug 29, 2011 at 10:48:31PM -0700, Doug Barton wrote: > I'm doing some updates and came across mail/postfix-policyd-spf which > relies on mail/libspf2-10. The latter had a vuxml entry added on > 2008-10-27. So my question is, why has mail/libspf2-10 been allowed to > remain in the tree vulnerable for almost 3 years? > > Wouldn't it make more sense to mark vulnerable ports DEPRECATED > immediately with a short expiration? When they get fixed they get > un-deprecated. If they don't, they get removed. Can someone explain why > this would be a bad idea? Might that not interfere with the process of getting a new maintainer for a popular port when its previous maintainer has been lax (or hit by a bus)? -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgphdRX2NJxzy.pgp Description: PGP signature
Re: mail/popper, mail/premail and mail/miltergreylist maintainership
Am 30.08.2011 15:04, schrieb Mikhail Tsatsenko: > I'd like to take maintainership of following unmaintained now ports: > mail/popper > mail/miltergreylist > mail/milter-greylist-devel > mail/premail Hi Mikhail, thanks for volunteering! You are now the maintainer of these four ports (actually the 2nd ist mail/milter-greylist). Best regards, Matthias ___ 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: cvs commit: ports/mail/procmail Makefile
Am 30.08.2011 14:27, schrieb Kurt Jaeger: > [maildrop] >>> - Can it use the 700+ lines long .procmailrc I have running >>> in a criticial application or do I have to migrate that ? >> >> You'd have to migrate that. > > That's what I assumed. > >> Bottom line: the sooner we get rid from procmail the better. > > There are many other applications that have issues, as well. > > It's already a lot of work just to keep up with the bug-de-jour > and the upgrade-de-jour and doing it all in parallel does > not scale very well. > > Therefore, one has to choose what one can work on. > > If the fbsd ports drop procmail, it will just add more on > my plate that I have to do myself. Similar to many other > apps and ports and you-name-it. > > While I dislike bitrot like anyone else, I have an issue with > the dropping of ports in general, because that will not scale. I understand that keeping unchanging software can sometimes be necessary, if you're working around its quirks. At the same time I'd like to discourage new installations of dead software so that it disappears over time, rather than haunt fresh systems. How about if we added a new tag "OBSOLESCENT" or so that permits building the software only if it's already installed but refuses new installations? Of course there could be a switch to override that, like TRYBROKEN that can override BROKEN= tags. I'm not sure if it's feasible for packages (but OBSOLESCENT could imply "do not package") but for ports it would be possible. ___ 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: cvs commit: ports/mail/procmail Makefile
On the procmail depracation topic, Warren Block wrote: > Some initial searching shows that maildrop is a functional replacement > and can be used with sendmail's local_procmail feature, but the rules > are different. There could be other functionality which users depend > on, like formail, which a replacement might not have. maildrop comes with reformail. It, too, has different options than procmail, but by and large it fits the bill. > For now, a pkg-message for mail/procmail that suggests alternates, and > why, would give users some time to prepare. OK. Good suggestion. Thank you. Best regards, Matthias ___ 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: cvs commit: ports/mail/procmail Makefile
Am 30.08.2011 17:24, schrieb Julian H. Stacey: > Matthias Andree wrote: >> Am 30.08.2011 10:23, schrieb Sunpoet Po-Chuan Hsieh: >>> sunpoet 2011-08-30 08:23:18 UTC >>> >>> FreeBSD ports repository >>> >>> Modified files: >>> mail/procmailMakefile >>> Log: >>> - Take maintainership >>> >>> Revision ChangesPath >>> 1.60 +1 -1 ports/mail/procmail/Makefile >> >> I was just about to grab the port, deprecate and set two months >> expiration date. > > Sorry No, it would be most irresponsible to consider a timeout of > 2 months ! Procmail has been compiling regularly, working fine & > vitaly necessary here for a decade. If one were considering to > toss out such a vital tool, one should give a warning of a release or 2. (*) It should have been tossed out half a decade ago, but if people feel it's so hard to migrate away from it we should extend the period. But we should really deprecate dead software. > It's not hard to use, Read the manual & learn. Examples > http://www.berklix.com/~jhs/dots/.procmailrc WARNING - DO NOT USE THOSE. Essentially all those examples have no error handling for delivering recipes (see my earlier post in this thread for a remedy that limits usefulness of some recipes), but the all-too-typical problem that in temporary disk-full condition, mail can end up anywhere, because procmail silently proceeds to the next recipe after the previous one has failed. And that's extactly the reason why procmail must die. I don't mean to disrupt existing installations, but I do mean to discourage new ones. >> DEPRECATED= use mail/maildrop instead > > No, > >> EXPIRATION_DATE= 2011-10-31 > > (*) > Irresponsible lack of warning ! No need, we can bump the PORTREVISION so it appears on the users' radars. > Lots of users of releases dont even read ports@ > ( Reminds me of the Hitch Hikers Guide episode where the vogons > come to destroy the earth, & claim due warning was lodged in Alpha Centauri > ;-) We're not trying to build an Intergalactic Expressway through Earth though, but my goal is to prevent nasty surprises. Once you have the necessary error handling in place in your .procmailrc, a .mailfilter file of equal usefulness in maildrop is shorter and more concise. ___ 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: Time to remove the GNUTLS option in the print/cups-client port
> ... the US > patent system has become horribly broken in practice. The world's > biggest patent-holders that actually produce anything pretty much all > agree that the system is horribly broken, and mostly collect patents for > defensive use. Not just USA but Europe too, etc. A European Patent Office examiner morosely & sarcasticly speculated that big patent holders might drive lorries (trucks) of patents up to weigh bridges, approach competitors & say eg "We have seven tons, if you have over 6 lets cross licence" Examiners are under time pressure to grant by default unless they can quickly find a reason not to. Politicians of leading countries see a future of increasingly sellling intangible exports, so want more patents, not less. International free software groups have no rich lobby groups, so ignored. Sat 17th Sept in 600+ cities round the world, is a chance for free software movements not just to promote Linux & BSD etc, but also to address software patents - see FSF & FSFE logos among BSD & Penguins etc on http://softwarefreedomday.org/ Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ 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: Time to remove the GNUTLS option in the print/cups-client port
Could we please change the Subject line to match the content now? mcl ___ 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: cvs commit: ports/mail/procmail Makefile
Quoth Matthias Andree on Tuesday, 30 August 2011: > Am 30.08.2011 14:27, schrieb Kurt Jaeger: > > [maildrop] > >>> - Can it use the 700+ lines long .procmailrc I have running > >>> in a criticial application or do I have to migrate that ? > >> > >> You'd have to migrate that. > > > > That's what I assumed. > > > >> Bottom line: the sooner we get rid from procmail the better. > > > > There are many other applications that have issues, as well. > > > > It's already a lot of work just to keep up with the bug-de-jour > > and the upgrade-de-jour and doing it all in parallel does > > not scale very well. > > > > Therefore, one has to choose what one can work on. > > > > If the fbsd ports drop procmail, it will just add more on > > my plate that I have to do myself. Similar to many other > > apps and ports and you-name-it. > > > > While I dislike bitrot like anyone else, I have an issue with > > the dropping of ports in general, because that will not scale. > > I understand that keeping unchanging software can sometimes be > necessary, if you're working around its quirks. > > At the same time I'd like to discourage new installations of dead > software so that it disappears over time, rather than haunt fresh systems. > > > How about if we added a new tag "OBSOLESCENT" or so that permits > building the software only if it's already installed but refuses new > installations? Of course there could be a switch to override that, like > TRYBROKEN that can override BROKEN= tags. > > I'm not sure if it's feasible for packages (but OBSOLESCENT could imply > "do not package") but for ports it would be possible. I like this idea. But please call it OBSOLETE, instead of OBSOLESCENT. Gratuitous suffixes are as much of a bane to the language as obsolete software is to an OS. -- .O. | Sterling (Chip) Camden | http://camdensoftware.com ..O | sterl...@camdensoftware.com | http://chipsquips.com OOO | 2048R/D6DBAF91 | http://chipstips.com pgph1uXuK2Lrq.pgp Description: PGP signature
Re: cvs commit: ports/mail/procmail Makefile
On Tue, Aug 30, 2011 at 05:57:10PM +0200, Matthias Andree wrote: > How about if we added a new tag "OBSOLESCENT" or so that permits > building the software only if it's already installed but refuses new > installations? Right now if you set DEPRECATED you'll get a warning. Shouldn't that be sufficient without introducing a new mechanism that enforces a policy? mcl ___ 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: openvpn-2.2.1
Hi, I noticed a problem with rc script for openvpn-2.2.1 on recent FreeBSD 8-STABLE (Aug 13 20:33:31 CEST 2011). It failed to restart if I have the following in rc.conf openvpn_bp_office_if="tap bridge" # service openvpn_bp_office restart Stopping openvpn_bp_office. Waiting for PIDS: 75580. kldload: can't load if_bridge: File exists /usr/local/etc/rc.d/openvpn_bp_office: WARNING: Could not load bridge module. /usr/local/etc/rc.d/openvpn_bp_office: WARNING: failed precmd routine for openvpn_bp_office The problem is, that if_bridge.ko is already loaded, but the kldload routine in rc script will not detect it, because if_bridge has not debug.if_bridge_debug sysctl entry. (older version of rc script works fine with kldstat -m if_bridge) So I have a question - why the rc script is not using required_modules variable from /etc/rc.subr which is there exactly for this purpose? Miroslav Lachman ___ 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: openvpn-2.2.1
Am 30.08.2011 18:40, schrieb Miroslav Lachman: > Hi, > > I noticed a problem with rc script for openvpn-2.2.1 on recent FreeBSD > 8-STABLE (Aug 13 20:33:31 CEST 2011). > It failed to restart if I have the following in rc.conf > > openvpn_bp_office_if="tap bridge" > > > # service openvpn_bp_office restart > Stopping openvpn_bp_office. > Waiting for PIDS: 75580. > kldload: can't load if_bridge: File exists > /usr/local/etc/rc.d/openvpn_bp_office: WARNING: Could not load bridge > module. > /usr/local/etc/rc.d/openvpn_bp_office: WARNING: failed precmd routine > for openvpn_bp_office > > The problem is, that if_bridge.ko is already loaded, but the kldload > routine in rc script will not detect it, because if_bridge has not > debug.if_bridge_debug sysctl entry. (older version of rc script works > fine with kldstat -m if_bridge) > > So I have a question - why the rc script is not using required_modules > variable from /etc/rc.subr which is there exactly for this purpose? Miroslav, thanks for your required_modules suggestion. The script dates back to 2005, when required_modules didn't exist (it was merged to a stable version in August 2007). I have fixed the openvpn20 and openvpn ports. Revisions 2.2.1_1 and 2.0.9_2 (respectively) have the fix. Thanks for the report and suggestion! Best regards, Matthias ___ 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: cvs commit: ports/mail/procmail Makefile
On 30 August 2011 17:39, Mark Linimon wrote: > On Tue, Aug 30, 2011 at 05:57:10PM +0200, Matthias Andree wrote: >> How about if we added a new tag "OBSOLESCENT" or so that permits >> building the software only if it's already installed but refuses new >> installations? > > Right now if you set DEPRECATED you'll get a warning. Shouldn't > that be sufficient without introducing a new mechanism that enforces > a policy? +1 I agree-- isn't that what DEPRECATED is for?? Chris ___ 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: firefox 6: mercurial seems to be missing as dependency
When updating firefox to the latest version (from ports) it complained
about hg not being found. Apparently a dependency to mercurial is
missing. I haven't checked why, installing it resolved it.
Can you please show us exact error message for further investigation?
Turns out this is an (almost) non-issue. make ends with some errors as
shown below.
I assumed it was needed for the build, and installed it. However it is
not a build error,
which I took it for, Firefox is build correctly and installs fine
without Mercurial, it just
shows some errors.
Regards,
Jeroen
gmake[4]: Leaving directory
`/usr/ports/www/firefox/work/mozilla-release/browser/app'
gmake[3]: Leaving directory
`/usr/ports/www/firefox/work/mozilla-release/browser'
gmake[2]: Leaving directory `/usr/ports/www/firefox/work/mozilla-release'
gmake tools_tier_app
gmake[2]: Entering directory `/usr/ports/www/firefox/work/mozilla-release'
hg: not found
tools_tier_app
gmake[3]: Entering directory `/usr/ports/www/firefox/work/mozilla-release'
gmake[3]: `extensions/Makefile' is up to date.
gmake[3]: `browser/branding/official/Makefile' is up to date.
[]
gmake[6]: Nothing to be done for `tools'.
gmake[6]: Leaving directory
`/usr/ports/www/firefox/work/mozilla-release/browser/components/migration/src'
gmake[5]: Leaving directory
`/usr/ports/www/firefox/work/mozilla-release/browser/components/migration'
gmake[5]: Entering directory
`/usr/ports/www/firefox/work/mozilla-release/browser/components/build'
gmake[5]: Nothing to be done for `tools'.
gmake[5]: Leaving directory
`/usr/ports/www/firefox/work/mozilla-release/browser/components/build'
gmake[4]: Leaving directory
`/usr/ports/www/firefox/work/mozilla-release/browser/components'
hg: not found
gmake[4]: Entering directory
`/usr/ports/www/firefox/work/mozilla-release/browser/app'
gmake[5]: Entering directory
`/usr/ports/www/firefox/work/mozilla-release/browser/app/profile/extensions'
gmake[6]: Entering directory
`/usr/ports/www/firefox/work/mozilla-release/browser/app/profile/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}'
gmake[6]: Nothing to be done for `tools'.
gmake[6]: Leaving directory
`/usr/ports/www/firefox/work/mozilla-release/browser/app/profile/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}'
gmake[5]: Leaving directory
`/usr/ports/www/firefox/work/mozilla-release/browser/app/profile/extensions'
gmake[4]: Leaving directory
`/usr/ports/www/firefox/work/mozilla-release/browser/app'
gmake[3]: Leaving directory
`/usr/ports/www/firefox/work/mozilla-release/browser'
gmake[2]: Leaving directory `/usr/ports/www/firefox/work/mozilla-release'
gmake[1]: Leaving directory `/usr/ports/www/firefox/work/mozilla-release'
if test -d ./dist/bin ; then touch ./dist/bin/.purgecaches ; fi
hg: not found
sed: /usr/ports/www/firefox/work/mozilla-release/build/unix/*.pc: No
such file or directory
___
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: cvs commit: ports/mail/procmail Makefile
Am 30.08.2011 19:29, schrieb Chris Rees: > On 30 August 2011 17:39, Mark Linimon wrote: >> On Tue, Aug 30, 2011 at 05:57:10PM +0200, Matthias Andree wrote: >>> How about if we added a new tag "OBSOLESCENT" or so that permits >>> building the software only if it's already installed but refuses new >>> installations? >> >> Right now if you set DEPRECATED you'll get a warning. Shouldn't >> that be sufficient without introducing a new mechanism that enforces >> a policy? > > +1 > > I agree-- isn't that what DEPRECATED is for?? It only warns, it does not prevent fresh installs on systems that don't have the same port/package already installed. ___ 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: cvs commit: ports/mail/procmail Makefile
On Tue, Aug 30, 2011 at 07:44:12PM +0200, Matthias Andree wrote: > It only warns, it does not prevent fresh installs on systems that don't > have the same port/package already installed. "code, not policy" ... ? mcl ___ 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: cvs commit: ports/mail/procmail Makefile
Am 30.08.2011 19:57, schrieb Mark Linimon: > On Tue, Aug 30, 2011 at 07:44:12PM +0200, Matthias Andree wrote: >> It only warns, it does not prevent fresh installs on systems that don't >> have the same port/package already installed. > > "code, not policy" ... ? Well... is _is_ policy and meant as such. We make decisions for ports users all the time, and this is no exception. ___ 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: Time to remove the GNUTLS option in the print/cups-client port
On Tue, 30 Aug 2011 11:24:43 -0500 Mark Linimon articulated: > Could we please change the Subject line to match the content now? That would probably not be the best idea. All things considered, the new posts may well end up threaded along with the older posts. Starting a entirely new post would be a better solution. -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ Actors will happen even in the best-regulated families. ___ 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: Why do we not mark vulnerable ports DEPRECATED?
On 08/30/2011 08:29, Chad Perrin wrote: > On Mon, Aug 29, 2011 at 10:48:31PM -0700, Doug Barton wrote: >> I'm doing some updates and came across mail/postfix-policyd-spf which >> relies on mail/libspf2-10. The latter had a vuxml entry added on >> 2008-10-27. So my question is, why has mail/libspf2-10 been allowed to >> remain in the tree vulnerable for almost 3 years? >> >> Wouldn't it make more sense to mark vulnerable ports DEPRECATED >> immediately with a short expiration? When they get fixed they get >> un-deprecated. If they don't, they get removed. Can someone explain why >> this would be a bad idea? > > Might that not interfere with the process of getting a new maintainer for > a popular port when its previous maintainer has been lax (or hit by a > bus)? Sorry if I'm being dense, but I'm not seeing the connection. Can you elaborate? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: openvpn-2.2.1
Matthias Andree wrote: Am 30.08.2011 18:40, schrieb Miroslav Lachman: Hi, [...] So I have a question - why the rc script is not using required_modules variable from /etc/rc.subr which is there exactly for this purpose? Miroslav, thanks for your required_modules suggestion. The script dates back to 2005, when required_modules didn't exist (it was merged to a stable version in August 2007). I have fixed the openvpn20 and openvpn ports. Revisions 2.2.1_1 and 2.0.9_2 (respectively) have the fix. Thanks for the report and suggestion! Thank you for your quick response and fix of the issue! Miroslav Lachman ___ 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: cvs commit: ports/mail/procmail Makefile
On Tue, 30 Aug 2011, Matthias Andree wrote: Am 30.08.2011 19:57, schrieb Mark Linimon: On Tue, Aug 30, 2011 at 07:44:12PM +0200, Matthias Andree wrote: It only warns, it does not prevent fresh installs on systems that don't have the same port/package already installed. "code, not policy" ... ? Well... is _is_ policy and meant as such. We make decisions for ports users all the time, and this is no exception. If procmail has no ongoing security issues and it compiles and installs with no problems what's the reasoning behind removing it from the ports tree? As far as I can see the reasoning advocated at this time is that procmail hasn't been in active development since 2001. Shouldn't that be seen as a sign of stability. I'm not a software developer so maybe I'm missing something obvious about this situation. Feel free to educate/convice me that I should make the effort to switch from procmail to maildrop. I've been using procmail now for 16 years and I'm very happy with it's performance. Moving to maildrop would be a significant amount of effort for both me and my users. Ted Hatfield ___ 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: Python min version bumped from 2.4+ to 2.5+
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/30/11 10:26 AM, Ruslan Mahmatkhanov wrote: > Greg Larkin wrote on 30.08.2011 17:56: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 8/30/11 9:38 AM, Ruslan Mahmatkhanov wrote: >>> Greg Larkin wrote on 30.08.2011 17:05: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Martin, I have a question about a commit you made in February 2011: http://www.freshports.org/commit.php?message_id=201102250750.p1p7ofdg016...@repoman.freebsd.org&files=yes Part of the commit changed: USE_PYTHON=2.4+ to USE_PYTHON=2.5+ Was there a specific reason for doing so? I am running various tinderbox builds to check on port usage of the USE_PYTHON variable, and I noticed that devel/py-setuptools no longer builds if Python 2.4 is selected. I'd like to restore that capability, but before I send a PR, I wanted to check with you first. Thank you, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/cpucycle/ - Follow you, follow me >>> >>> I'm sorry for sail in, but i think that the reason is that python24 is >>> reached it's EOL long time ago. Actually the only supported python >>> releases atm according to python.org are - 2.7.2 and 3.2.1, and >>> developers highly encourages the users to move to this versions. >>> >>> 2.5 and 2.6 are in security-fix-only mode, there will be no ANY releases >>> for this branches after October 2011 and October 2013 respectively, >>> while 2.4 does not get security-fixes even. >>> >>> There is also this answer from Martin in this pr: >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/155526: >>> >>> python24 goes to the end of month, this port is on the todo for removal >>> >> >> Hi Ruslan, > > Hi Greg > >> >> Ok, thank you for the explanation. Shall I mark python24 for removal >> from the tree or file a PR for python@ to do it? > > It's not so easy actually, since we have many ports in the tree that > still depend on 2.4 (notably all that zope/plone stuff) and i believe it > was the reason why python24 still not be removed in the first place. > I do some work about eliminating python24 usage in the tree (yesterdays > py-pysqlite2x stuff - one of it), but it's not that fast. I also working > on porting zope2.13/plone4 (that supports python 2.6 and 2.7) and i'm > planing to finish it this weekend after proper testing. After that we > can deprecate/remove existing zope/plone (not longer supported upstream). Ok, it's a bigger job than I realized! > >> >> FYI, I have been running tinderbox builds with PYTHON_VERSION and >> PYTHON_DEFAULT_VERSION set to python2.4, python2.5, etc. to find out if >> ports with USE_PYTHON=yes need to be constrained a bit more. > > Yes, there is a lot of work. We have USE_PYTHON with bogus values like > 1.5+, 1.6+, 2.0+ etc :). And most of python ports will not work with > python3x so they should be constrained with -2.7 too. Do you think it's helpful then to run these builds with different Python versions enforced? I thought that getting the version ranges in the USE_PYTHON variable tightened up might help reduce the number of folks who run into build problems. I would like to do the same thing with Perl, GCC, and others. > >> I figured that python2.4 was supported since it was still in the tree >> and wasn't marked for removal yet, but I admin that I didn't check >> python.org for confirmation. > > As i already stated, i believe it's still there because there is > dependent ports. And as far i know in linux world noone shipping > python24 this days. Even RHEL/CentOS finally switched to 2.6.5 in their > 6.x branches. > >> >> Regards, >> Greg >> - -- >> Greg Larkin >> >> http://www.FreeBSD.org/ - The Power To Serve >> http://www.sourcehosting.net/ - Ready. Set. Code. >> http://twitter.com/cpucycle/ - Follow you, follow me > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5dQvsACgkQ0sRouByUApDH2wCgjulXl1vUHOGO4ubs4rZKLTlQ kMMAoLKBSArHGQkCT75iBQuLUQmsDuXb =i3ak -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: Python min version bumped from 2.4+ to 2.5+
Greg Larkin wrote on 31.08.2011 00:07: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/30/11 10:26 AM, Ruslan Mahmatkhanov wrote: Greg Larkin wrote on 30.08.2011 17:56: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/30/11 9:38 AM, Ruslan Mahmatkhanov wrote: Greg Larkin wrote on 30.08.2011 17:05: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Martin, I have a question about a commit you made in February 2011: http://www.freshports.org/commit.php?message_id=201102250750.p1p7ofdg016...@repoman.freebsd.org&files=yes Part of the commit changed: USE_PYTHON=2.4+ to USE_PYTHON=2.5+ Was there a specific reason for doing so? I am running various tinderbox builds to check on port usage of the USE_PYTHON variable, and I noticed that devel/py-setuptools no longer builds if Python 2.4 is selected. I'd like to restore that capability, but before I send a PR, I wanted to check with you first. Thank you, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/cpucycle/ - Follow you, follow me I'm sorry for sail in, but i think that the reason is that python24 is reached it's EOL long time ago. Actually the only supported python releases atm according to python.org are - 2.7.2 and 3.2.1, and developers highly encourages the users to move to this versions. 2.5 and 2.6 are in security-fix-only mode, there will be no ANY releases for this branches after October 2011 and October 2013 respectively, while 2.4 does not get security-fixes even. There is also this answer from Martin in this pr: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/155526: python24 goes to the end of month, this port is on the todo for removal Hi Ruslan, Hi Greg Ok, thank you for the explanation. Shall I mark python24 for removal from the tree or file a PR for python@ to do it? It's not so easy actually, since we have many ports in the tree that still depend on 2.4 (notably all that zope/plone stuff) and i believe it was the reason why python24 still not be removed in the first place. I do some work about eliminating python24 usage in the tree (yesterdays py-pysqlite2x stuff - one of it), but it's not that fast. I also working on porting zope2.13/plone4 (that supports python 2.6 and 2.7) and i'm planing to finish it this weekend after proper testing. After that we can deprecate/remove existing zope/plone (not longer supported upstream). Ok, it's a bigger job than I realized! FYI, I have been running tinderbox builds with PYTHON_VERSION and PYTHON_DEFAULT_VERSION set to python2.4, python2.5, etc. to find out if ports with USE_PYTHON=yes need to be constrained a bit more. Yes, there is a lot of work. We have USE_PYTHON with bogus values like 1.5+, 1.6+, 2.0+ etc :). And most of python ports will not work with python3x so they should be constrained with -2.7 too. Do you think it's helpful then to run these builds with different Python versions enforced? I thought that getting the version ranges in the USE_PYTHON variable tightened up might help reduce the number of folks who run into build problems. I would like to do the same thing with Perl, GCC, and others. I, personally, believe that this almost can't help to identify version-specific problems, since commonly there is almost no build problems on different python versions (it's rarely when setup.py actually checking which python version it was run with). The problems arises on runtime stage, when apps starting to import modules, that may not exist in this particular python version or that installed by missing dependencies, etc. Such problems may be identified only with manual checking/greping/app docs reading. But this is just my point. You'd better to ask Martin - he is committer that skilled with python stuff in ports, and i'm not proper person to take responsibility for decisions like that :). I just can to sound my point on this. However, it definitely will help to identify gcc version-specific build problems. I figured that python2.4 was supported since it was still in the tree and wasn't marked for removal yet, but I admin that I didn't check python.org for confirmation. As i already stated, i believe it's still there because there is dependent ports. And as far i know in linux world noone shipping python24 this days. Even RHEL/CentOS finally switched to 2.6.5 in their 6.x branches. Regards, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/cpucycle/ - Follow you, follow me -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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"
gimp-gmic-plugin unbreak (Was: Re: libnotify)
Koop Mast wrote on 24.08.2011 16:20: On Wed, 2011-08-24 at 14:45 +0400, Ruslan Mahmatkhanov wrote: ajtiM wrote on 24.08.2011 14:38: Stop in /usr/ports/graphics/gimp-gmic-plugin. *** Error code 1 Stop in /usr/ports/graphics/gimp-gmic-plugin. ===>>> make failed for graphics/gimp-gmic-plugin ===>>> Aborting update Too bad. I did not deal with recent updates yet, so i'll try to realize what is wrong some time later this week. This build failure seems to be caused by the recent opencv update to 2.3.1. -Koop I just disabled OpenCV completely for now to unbreak the port: http://www.freebsd.org/cgi/query-pr.cgi?pr=160321 Anybody with free hands - please, commit. -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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: Why do we not mark vulnerable ports DEPRECATED?
On Tue, Aug 30, 2011 at 11:55:25AM -0700, Doug Barton wrote: > On 08/30/2011 08:29, Chad Perrin wrote: > > > > Might that not interfere with the process of getting a new maintainer for > > a popular port when its previous maintainer has been lax (or hit by a > > bus)? > > Sorry if I'm being dense, but I'm not seeing the connection. Can you > elaborate? I'll put it another way: Wouldn't it be easier for a new maintainer to pick up maintenance of a port if (s)he doesn't have to start over from scratch? -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpFstKgGCRTW.pgp Description: PGP signature
Re: Why do we not mark vulnerable ports DEPRECATED?
On 30 Aug 2011 22:13, "Chad Perrin" wrote: > > On Tue, Aug 30, 2011 at 11:55:25AM -0700, Doug Barton wrote: > > On 08/30/2011 08:29, Chad Perrin wrote: > > > > > > Might that not interfere with the process of getting a new maintainer for > > > a popular port when its previous maintainer has been lax (or hit by a > > > bus)? > > > > Sorry if I'm being dense, but I'm not seeing the connection. Can you > > elaborate? > > I'll put it another way: > > Wouldn't it be easier for a new maintainer to pick up maintenance of a > port if (s)he doesn't have to start over from scratch? > That's what the cvs Attic is for. Stuff doesn't disappear! Chris ___ 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: cvs commit: ports/mail/procmail Makefile
On Tuesday 30 August 2011 11:01:18 Ted Hatfield wrote: > On Tue, 30 Aug 2011, Matthias Andree wrote: > > Am 30.08.2011 19:57, schrieb Mark Linimon: > >> On Tue, Aug 30, 2011 at 07:44:12PM +0200, Matthias Andree wrote: > >>> It only warns, it does not prevent fresh installs on systems that don't > >>> have the same port/package already installed. > >> > >> "code, not policy" ... ? > > > > Well... is _is_ policy and meant as such. We make decisions for ports > > users all the time, and this is no exception. > > If procmail has no ongoing security issues and it compiles and installs > with no problems what's the reasoning behind removing it from the ports > tree? > > As far as I can see the reasoning advocated at this time is that > procmail hasn't been in active development since 2001. Shouldn't that > be seen as a sign of stability. > > I'm not a software developer so maybe I'm missing something obvious > about this situation. Feel free to educate/convice me that I should > make the effort to switch from procmail to maildrop. > > I've been using procmail now for 16 years and I'm very happy with it's > performance. Moving to maildrop would be a significant amount of effort > for both me and my users. > > Ted Hatfield I second that, I also have it installed in several places and haven't had any problems. I don't want to have to move to another app just because someone feels like deprecating a mature port. I think the old addage "if it ain't broke" applies here. Beech -- --- Beech Rintoul - FreeBSD Developer - be...@freebsd.org /"\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://people.freebsd.org/~beech X - NO Word docs in e-mail | Skype: akbeech / \ - http://www.FreeBSD.org/releases/8.2R/announce.html --- signature.asc Description: This is a digitally signed message part.
Re: cvs commit: ports/mail/procmail Makefile
Matthias Andree wrote: > I understand that keeping unchanging software can sometimes be > necessary, if you're working around its quirks. > > At the same time I'd like to discourage new installations of dead > software so that it disappears over time, rather than haunt fresh > systems. > > How about if we added a new tag "OBSOLESCENT" or so that permits > building the software only if it's already installed but refuses > new installations? Of course there could be a switch to override > that, like TRYBROKEN that can override BROKEN= tags. > > I'm not sure if it's feasible for packages (but OBSOLESCENT could > imply "do not package") but for ports it would be possible. +1. This would also address the python 2.4 problem mentioned in another thread. BTW (if it is not already being done) it would be good for the -recursive targets to check for BROKEN, FORBIDDEN, OBSOLESCENT, (others?) in the dependencies _before_ starting the actual work, since the presence of a problematic dependency may well affect the user's decision to install/build/whatever the leaf port. ___ 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"
editors/zim
Forwarding to ports@, which seems more likely to yield an answer to this particular inquiry than questions@ Please keep the OP, who is probably not subscribed to ports@, in the Cc: list. Date: Tue, 30 Aug 2011 13:52:12 +0100 From: Chris Whitehouse To: User Questions Subject: editors/zim Hi, I have a problem with Zim which I wrote to the author about he replied and said; "I'm afraid version 0.29 is no longer supported. This was the last version in the Perl branch, since we moved to Python there have been already 10 more releases. So please try the latest version (0.52)." Are there any plans to bump it to Python and a recent release? I emailed the maintainer a while back but got no response. thanks Chris ___ 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"
(maintainer question) Possible bug in cvs: cvs diff -uN: -N switch being ignored (disappearing, actually)
Odd little problem here I'm noticing with cvs. When I do a "cvs diff -uN", for some reason the -N switch is being ignored. It vanishes completely in the header of the resulting output. I've been trying to rename one of my patch files to conform to portlint's recommendations, but unless I can get -N to work properly, this is a no-go. Whether I add 'cvs diff -uN' to my .cvsrc, or explicitly add it at the command line, makes no difference. For instance: [root@serene /usr/ports/net-p2p/lopster]# cvs diff -uN cvs diff: Diffing . Index: Makefile === RCS file: /home/ncvs/ports/net-p2p/lopster/Makefile,v retrieving revision 1.44 diff -u -r1.44 Makefile ^ |__ What happened to -N? [snip remainder of diff output] Incidentally, this problem started before I upgraded two days ago from 9.0-BETA1 to 9.0-BETA1, so it's not OS version-related. Any idea what could be causing this and how to correct it? Is this a bug in cvs? Should I send-pr it? Thanks! -- Conrad J. Sabatier conr...@cox.net ___ 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: Python min version bumped from 2.4+ to 2.5+
In fact if use use_python=yes default is 27 we cant set python24 for removal yet because we have fix first all zope stuff. Am back to the game after Holiday Sent from my iPhone On Aug 30, 2011, at 21:56, Greg Larkin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 8/30/11 9:38 AM, Ruslan Mahmatkhanov wrote: >> Greg Larkin wrote on 30.08.2011 17:05: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Hi Martin, >>> >>> I have a question about a commit you made in February 2011: >>> http://www.freshports.org/commit.php?message_id=201102250750.p1p7ofdg016...@repoman.freebsd.org&files=yes >>> >>> >>> Part of the commit changed: >>> >>> USE_PYTHON=2.4+ >>> >>> to >>> >>> USE_PYTHON=2.5+ >>> >>> Was there a specific reason for doing so? I am running various >>> tinderbox builds to check on port usage of the USE_PYTHON variable, and >>> I noticed that devel/py-setuptools no longer builds if Python 2.4 is >>> selected. >>> >>> I'd like to restore that capability, but before I send a PR, I wanted to >>> check with you first. >>> >>> Thank you, >>> Greg >>> - -- >>> Greg Larkin >>> >>> http://www.FreeBSD.org/ - The Power To Serve >>> http://www.sourcehosting.net/ - Ready. Set. Code. >>> http://twitter.com/cpucycle/ - Follow you, follow me >> >> I'm sorry for sail in, but i think that the reason is that python24 is >> reached it's EOL long time ago. Actually the only supported python >> releases atm according to python.org are - 2.7.2 and 3.2.1, and >> developers highly encourages the users to move to this versions. >> >> 2.5 and 2.6 are in security-fix-only mode, there will be no ANY releases >> for this branches after October 2011 and October 2013 respectively, >> while 2.4 does not get security-fixes even. >> >> There is also this answer from Martin in this pr: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/155526: >> >> python24 goes to the end of month, this port is on the todo for removal >> > > Hi Ruslan, > > Ok, thank you for the explanation. Shall I mark python24 for removal > from the tree or file a PR for python@ to do it? > > FYI, I have been running tinderbox builds with PYTHON_VERSION and > PYTHON_DEFAULT_VERSION set to python2.4, python2.5, etc. to find out if > ports with USE_PYTHON=yes need to be constrained a bit more. > > I figured that python2.4 was supported since it was still in the tree > and wasn't marked for removal yet, but I admin that I didn't check > python.org for confirmation. > > Regards, > Greg > - -- > Greg Larkin > > http://www.FreeBSD.org/ - The Power To Serve > http://www.sourcehosting.net/ - Ready. Set. Code. > http://twitter.com/cpucycle/ - Follow you, follow me > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk5c7B4ACgkQ0sRouByUApAZOQCcC0YgAzDxDj78I9u35+H53fur > be8AmQFjWrGJ/xmjYpPp6ZkKB+ejDfq9 > =tK4y > -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: (maintainer question) Possible bug in cvs: cvs diff -uN: -N switch being ignored (disappearing, actually)
On Tue, 30 Aug 2011 19:51:14 -0500 "Conrad J. Sabatier" wrote: > Incidentally, this problem started before I upgraded two days ago from > 9.0-BETA1 to 9.0-BETA1, so it's not OS version-related. ^ |__ Errr, I meant "BETA2, of course :-) -- Conrad J. Sabatier conr...@cox.net ___ 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: cvs commit: ports/mail/procmail Makefile
On Tue, 30 Aug 2011 18:06:15 +0200
Matthias Andree wrote:
> Once you have the necessary error handling in place in
> your .procmailrc, a .mailfilter file of equal usefulness in maildrop
> is shorter and more concise.
1. In the context of a FreeBSD port, there is absolutely nothing wrong
with mail/procmail as it stands. That is to say, it compiles and runs
on all supported OS releases and architectures.
2. I'd hazard a guess that procmail is used (with or without a view to
it's "interesting" view of error handling) on a large number of
systems. Whilst there have been recent, shall we say, discussions, on
the viability of the ports tree, one should not expect to be punched
into a nearby wall when attempting to lose such a piece of software
when the issues, such as they are, are with the software itself, not
the port.
3. Particularly when there's no magic tool to convert all
the .procmailrc's out there to mail/whizzy-new-thing.
4. Assuming for a minute that y'all are just on a deprecation kick,
there's considerably more interesting low-hanging fruit. gtk1, qt3,
kde3, gnome1, etc.. etc..
5. Don't make me put RUN_DEPENDS= procmail:${PORTSDIR}/mail/procmail
somewhere in the bowels of autotools ;)
#3 is the important point. If you do want to send mail/procmail to the
great bitbucket in the sky, then please provide that magic tool. I'm
sure lots of folks will be willing to test it for you.
-aDe
___
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"
