Committing ${name}_limits patches for the rc files of various databases
Hello,
A few weeks ago I discovered a regression caused by the standardization
of the mechanism used to limit daemons resources with limits(1). This
feature was introduced in r328331[1]. Basically, it defines that
limits(1) could be controlled via rc.conf(5) using ${name}_limits
variables as defined in rc.subr(5).
Unfortunately, many database rc scripts have already used ${name}_limits
variables with incompatible semantics. This is why I worked with some
FreeBSD committers and developers on a set of patch for those affected
databases. Thanks to their reviews and testing effort I was able to
open an issue on Bugzilla for every affected database port and provide a
few revisions of patchs for each of them.
Some of the patches were already incorporated into the ports tree, but
many of them are still waiting to be committed. Recently, an update to
database/mongodb36 was committed[2], which not only does not solve the
problem of the mongodb36 daemon to be broken on FreeBSD 12.0-CURRENT but
also introduces parts of my old patches, which were marked obsolete[3].
I am deeply concerned about the whole situation and after a few weeks of
waiting I decided to step forward and bring community's attention.
The meta issue with all the ports listed is available here[4]. It has
got links to all the other issues and patch with a proposed UPDATING
entry.
I understand that there a lot of work to be done for committers in every
corner of the FreeBSD system. If anyone, however, would like to mentor
me and help me commit those changes into our ports tree then I am 100%
eager to get started. I'd really appreciate it. :)
Cheers & happy hacking,
Mateusz Piotrowski
[1]: https://svnweb.freebsd.org/base?view=revision&revision=r328331
[2]: https://svnweb.freebsd.org/ports?view=revision&revision=467897
[3]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226907#c11
[4]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227205
___
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: Changing PHP default version from 5.6 to 7.2 timeframe?
[Default] On Thu, 19 Apr 2018 16:48:40 +0200, Kurt Jaeger wrote: >Hi! > >> It appears that there is some work going on to prepare to switch >> the default PHP version from 5.6 to an actively supported version. > >Yes. > >> What is the approximate timeframe for that change, if any? > >I don't know. > >> Should I jump and change the default version for my installs? I'm >> running the usual suspects like WordPress, MediaWiki, phpMyAdmin. > >Yes, and please report if you find problems 8-} We need more >testers 8-) The install process isn't(!!) very nice to aged brains, but now that I have it installed it seems to work okay under 11.1R. The selection of default modules seems to have been made by someone who isn't setting up a FAMP server. Because of the diversity of uses there probably shouldn't be any extensions installed by default, but *all* of them should be on the menu rather than having to hunt any of them down. And I haven't used the "replacement" for mcrypt yet, and suspect that it's not actually in any way a drop-in replacement, but there's probably nothing to be done about that now. > >> Looking at the supported versions page, I would expect the change be made to >> 7.2. Is that correct? > >I'm not involved in the decision, but I've heard from problems >with typo3 and php7.2. ___ 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: Committing ${name}_limits patches for the rc files of various databases
On 04/21, Mateusz Piotrowski wrote:
> Hello,
>
> A few weeks ago I discovered a regression caused by the standardization
> of the mechanism used to limit daemons resources with limits(1). This
> feature was introduced in r328331[1]. Basically, it defines that
> limits(1) could be controlled via rc.conf(5) using ${name}_limits
> variables as defined in rc.subr(5).
>
> Unfortunately, many database rc scripts have already used ${name}_limits
> variables with incompatible semantics. This is why I worked with some
> FreeBSD committers and developers on a set of patch for those affected
> databases. Thanks to their reviews and testing effort I was able to
> open an issue on Bugzilla for every affected database port and provide a
> few revisions of patchs for each of them.
>
> Some of the patches were already incorporated into the ports tree, but
> many of them are still waiting to be committed. Recently, an update to
> database/mongodb36 was committed[2], which not only does not solve the
> problem of the mongodb36 daemon to be broken on FreeBSD 12.0-CURRENT but
> also introduces parts of my old patches, which were marked obsolete[3].
Please contact maintainer and resolve these issues. I didn't see any
objections and proposals from you in this PR.
signature.asc
Description: PGP signature
Re: Committing ${name}_limits patches for the rc files of various databases
Hi!
On Sat, 21 Apr 2018 20:44:05 +0200
Kirill Ponomarev wrote:
>On 04/21, Mateusz Piotrowski wrote:
>> Some of the patches were already incorporated into the ports tree,
>> but many of them are still waiting to be committed. Recently, an
>> update to database/mongodb36 was committed[2], which not only does
>> not solve the problem of the mongodb36 daemon to be broken on
>> FreeBSD 12.0-CURRENT but also introduces parts of my old patches,
>> which were marked obsolete[3].
>
>Please contact maintainer and resolve these issues.
Thanks for reaching out :)
I will contact the maintainer. It looks like the maintainer integrated
an old ${name}_limits patch locally and then submitted only a part of it
when submitting the upgrade to 3.6.4[1].
>I didn't see any objections and proposals from you in this PR.
True, I could have act quicker. Actually, I didn't look into the patch
back when it was submitted because I thought that it is just an update
(which leaves the ${name}_limits issue unresolved as it wasn't mentioned
anywhere in the issue). I'll pay more attention next time.
Regards,
Mateusz Piotrowski
[1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227636
___
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"
portsnap not honoring WORKDIR and PORTSDIR?
Is portsnap supposed to honor WORKDIR and PORTSDIR? These are defined in /etc/portsnap.conf, and it's not clear to me whether they are honored only via the .conf file or whether they are supposed to be honored from the environment as well. They appear to not be honored from the environment, and I'm wondering whether that is deliberate or an oversight that should be corrected. Thanks, Gary ___ 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: portsnap not honoring WORKDIR and PORTSDIR?
On Sat, 21 Apr 2018 16:49:13 -0600
Gary Aitken wrote:
> Is portsnap supposed to honor WORKDIR and PORTSDIR?
>
> These are defined in /etc/portsnap.conf, and it's not clear to me
> whether they are honored only via the .conf file or whether they
> are supposed to be honored from the environment as well.
>
> They appear to not be honored from the environment, and I'm wondering
> whether that is deliberate or an oversight that should be corrected.
>
It's deliberate:
# Initialize parameters to null, just in case they're
# set in the environment.
init_params() {
KEYPRINT=""
EXTRACTPATH=""
WORKDIR=""
PORTSDIR=""
...
___
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"
