[NEW PORT] net-p2p/lidarr: Music collection manager for Usenet and BitTorrent users
Hi all, My apologies if this is not the correct place to post this. Would a committer be available to review this New Port request? portlint and testport are OK. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234233 Regards, Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
* Martin Waschbüsch [190811 00:47]: >> Am 10.08.2019 um 20:18 schrieb Patrick Powell : >> >> Umm this was just the kick in the pants that I needed to switch to PHP 7. >> See https://www.glaver.org/blog/?p=1109 for a desperation 'I need PHP5.6' >> hack which I used during this update. > Thank you, Patrick, > that is a work-around I also came across. It helped me as well. You could also have used the quarterly branch, which keeps software till the end of the quarter. In the case of php 5.6 it would have given you time until March 31st, and would have included version 5.6.40 Wolfgang ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
> Am 10.08.2019 um 20:18 schrieb Patrick Powell : > > Umm this was just the kick in the pants that I needed to switch to PHP 7. > See https://www.glaver.org/blog/?p=1109 for a desperation 'I need PHP5.6' > hack which I used during this update. Thank you, Patrick, that is a work-around I also came across. It helped me as well. > I must say that the update to PHP 7 was relatively painless - there is PHP6 > to PHP7 update support and lots of help/suggestions. I also found an > embarassing amount of bad PHP code during the update process, something > I should have suspected I would find. For my own projects, this is not an issue. I do try to follow the deprecation announcements for php. The issue is one where customers insist (against my explicit advice) to continue to use outdated PHP-based software that is not easily upgraded (and probably should be replaced instead of patched). > Note that the changes suggested by Mr. Glaver seem to be applicable to new > versions of the Ports tree UPDATING and .../.mk files so you can use the > latest Ports tree with the appropriate minor modifications. You can even > generate a > script to apply these updates/mods each time you run 'portsnap'. But I > digress... ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
> Am 10.08.2019 um 12:53 schrieb Carmel NY : > > On Sat, 10 Aug 2019 10:17:44 +0200, Martin Waschbüsch stated: >> Would it not be better to have, say, the last two versions before >> current stable still in ports but with a huge disclaimer saying: use >> at your own risk, etc.? >> >> What do y'all think? >> >> Martin > > If I might be allowed to interpolate, I believe that continuing to > expose obsolete versions of software in the 'ports' system is a bad > Idea. It is enabling the use of software, that for one reason or > another has been superseded by a newer and possibly safer or more > mature version. Following your argument, there should no longer be a port of e.g. gcc48 in the ports tree as that, too, is no longer supported upstream. I am not saying old software should never be retired, but the end of upstream support as the *only* criteron for removal from ports tree does not sound like a good idea to me. > Usually, when a version or application is going to be removed from the > 'ports' system, it is duly noted well in advance. I would recommend > that we set a hard number, say 6 months or one year at max before said > software is removed. That should give even the most procrastinating > user ample time to render his/her system ready for that inevitability. > It they have not accomplished that with the set time frame, they > probably were never serious about doing it. > > Just my 2¢. > > -- > Carmel What happened here was: A port was updated to the last release upstream was going to publish, and *very* shortly afterwards removed from ports because support ended with said release. In the case of PHP 5.6 it was not even the last release. PHP 5.6 was removed from ports before the final upstream release. I think that a fixed time *after* the last upstream release would have been a sensible solution. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
On 2019-08-10 01:17, Martin Waschbüsch wrote: Hi all, At least the last two versions of PHP, 5.6 & 7.0, were removed from ports as soon as (or even shortly before) they were no longer actively maintained upstream. I am unsure what the exact reasoning behind this was, but I do not think it is a good idea moving forward: I suppose it is true that outdated & no longer supported versions of PHP could be seen as a security risk. So far so good. However, if, for whatever reason (and I think there are legitimate ones), I still need to use a now obsolete version of PHP, having them removed from ports effectively makes it harder for me to keep everything else up-to-date. I might have to stick with an old ports revision so I cannot update other packages. If I just keep PHP as is, and update other packages, I cannot easily switch to a new version of FreeBSD itself, because I'd have to go back to an old revision of ports (hopefully working with the OS version I updated to) to compile PHP and then do other packages. Libraries / dependencies may change and break my PHP, etc. So, on top of possible security concerns for the outdated software I use, I basically get an overall less secure / stable system to boot. Now, I am not suggesting we leave every old and outdated PHP version in ports, but why remove a port just days after it received its last security update upstream? (With PHP 5.6 it was actually removed from ports before it got its last update upstream). Would it not be better to have, say, the last two versions before current stable still in ports but with a huge disclaimer saying: use at your own risk, etc.? What do y'all think? Martin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-port Umm this was just the kick in the pants that I needed to switch to PHP 7. See https://www.glaver.org/blog/?p=1109 for a desperation 'I need PHP5.6' hack which I used during this update. I must say that the update to PHP 7 was relatively painless - there is PHP6 to PHP7 update support and lots of help/suggestions. I also found an embarassing amount of bad PHP code during the update process, something I should have suspected I would find. Note that the changes suggested by Mr. Glaver seem to be applicable to new versions of the Ports tree UPDATING and .../.mk files so you can use the latest Ports tree with the appropriate minor modifications. You can even generate a script to apply these updates/mods each time you run 'portsnap'. But I digress... -- Patrick Powell Astart Technologies papow...@astart.com1509 Hollow Ct., Network and System San Diego, CA 92019 Consulting Cell 858-518-7581 FAX 858-751-2435 Web: papowell at astart dot com ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Any alternatives to NONE cipher ssh or bbcp for gigabit+ zfs
I wrote viamillipede exactly for this eventuality. It's a resilient pipe to socket multiplexer for high throughput and can use mulitple l1,l2, l3 network paths. The initial version is in ports at net/viamillipede or you can follow the dev line : https://github.com/agokhale/viamillipede ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
Hi! [...] > Would it not be better to have, say, the last two versions before > current stable still in ports but with a huge disclaimer saying: > use at your own risk, etc.? > > What do y'all think? You make the case for something other systems call backports, basically, keeping stuff in working order in the tree. Backports in other systems need someone to take up stewardship. So, either a group steps forward and takes responsibility to keep them in working order in the generic tree, e.g. by - having a mailing list, e.g. backports@, - and changing the maintainer from ports@ to backports@ - and fixing PRs as they come up Or a group provides their own pkg repo that the normal pkg-user can reference to retrieve those older packages. Both approaches sound possible, but need a non-trivial amount of investment. -- p...@opsec.eu+49 171 3101372One year to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP version retirement
On Sat, 10 Aug 2019 10:17:44 +0200, Martin Waschbüsch stated: >Hi all, > >At least the last two versions of PHP, 5.6 & 7.0, were removed from >ports as soon as (or even shortly before) they were no longer actively >maintained upstream. I am unsure what the exact reasoning behind this >was, but I do not think it is a good idea moving forward: > >I suppose it is true that outdated & no longer supported versions of >PHP could be seen as a security risk. So far so good. > >However, if, for whatever reason (and I think there are legitimate >ones), I still need to use a now obsolete version of PHP, having them >removed from ports effectively makes it harder for me to keep >everything else up-to-date. I might have to stick with an old ports >revision so I cannot update other packages. If I just keep PHP as is, >and update other packages, I cannot easily switch to a new version of >FreeBSD itself, because I'd have to go back to an old revision of >ports (hopefully working with the OS version I updated to) to compile >PHP and then do other packages. Libraries / dependencies may change >and break my PHP, etc. So, on top of possible security concerns for >the outdated software I use, I basically get an overall less secure / >stable system to boot. > >Now, I am not suggesting we leave every old and outdated PHP version >in ports, but why remove a port just days after it received its last >security update upstream? (With PHP 5.6 it was actually removed from >ports before it got its last update upstream). > >Would it not be better to have, say, the last two versions before >current stable still in ports but with a huge disclaimer saying: use >at your own risk, etc.? > >What do y'all think? > >Martin If I might be allowed to interpolate, I believe that continuing to expose obsolete versions of software in the 'ports' system is a bad Idea. It is enabling the use of software, that for one reason or another has been superseded by a newer and possibly safer or more mature version. Usually, when a version or application is going to be removed from the 'ports' system, it is duly noted well in advance. I would recommend that we set a hard number, say 6 months or one year at max before said software is removed. That should give even the most procrastinating user ample time to render his/her system ready for that inevitability. It they have not accomplished that with the set time frame, they probably were never serious about doing it. Just my 2¢. -- Carmel pgpGaPp09iXyS.pgp Description: OpenPGP digital signature
PHP version retirement
Hi all, At least the last two versions of PHP, 5.6 & 7.0, were removed from ports as soon as (or even shortly before) they were no longer actively maintained upstream. I am unsure what the exact reasoning behind this was, but I do not think it is a good idea moving forward: I suppose it is true that outdated & no longer supported versions of PHP could be seen as a security risk. So far so good. However, if, for whatever reason (and I think there are legitimate ones), I still need to use a now obsolete version of PHP, having them removed from ports effectively makes it harder for me to keep everything else up-to-date. I might have to stick with an old ports revision so I cannot update other packages. If I just keep PHP as is, and update other packages, I cannot easily switch to a new version of FreeBSD itself, because I'd have to go back to an old revision of ports (hopefully working with the OS version I updated to) to compile PHP and then do other packages. Libraries / dependencies may change and break my PHP, etc. So, on top of possible security concerns for the outdated software I use, I basically get an overall less secure / stable system to boot. Now, I am not suggesting we leave every old and outdated PHP version in ports, but why remove a port just days after it received its last security update upstream? (With PHP 5.6 it was actually removed from ports before it got its last update upstream). Would it not be better to have, say, the last two versions before current stable still in ports but with a huge disclaimer saying: use at your own risk, etc.? What do y'all think? Martin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
