[gentoo-dev] Package up for grabs: media-radio/KochMorse
I no longer use media-radio/KochMorse and have changed the package to "maintainer needed". See https://github.com/gentoo/gentoo/pull/18321 . There are no open Bugzilla issues for this package. -Ralph
Re: [gentoo-dev] Re: Add commit to pull request
* Toralf Förster: > On 6/21/20 6:48 PM, Samuel Bernardo wrote: > >> Is it possible to add the commit to that pull request or I need to >> open a new pull request? > > yes Answering a colloquial "A or B" as a logical disjunction "A ∨ B"... Now that's just teasing. :-) -Ralph
Re: [gentoo-dev] Last rites: app-cdr/sync2d
* Christopher Head: > Not that I care about this specific case, but isn’t the 30-day time > period also meant as a nice long warning time for people [...] Rules and exceptions. I think that shortening the typical 30-day period is acceptable in specific cases, and sync2d is one of them. According to Git history, the ebuild for release 1.3 (released 2007) was imported in August 2015 and no functional changes have been made since then. There were only meta data updates and stabilisations, and it all ended in 2017. sync2d is unmaintained in Gentoo and based on Python 2, which, as we know, was marked for "end of support 2015" which later was extended to January 2020. Upstream had oodles of time to migrate to Python 3 if they wanted to. If (!) any Gentoo users are still using sync2d today, they also had ample time to choose an alternative. From all appearances, sync2d has gone the way of the dodo. Masking will not uninstall the package, and the sooner people can no longer install sync2d without thought, the better, as far as I am concerned. -Ralph
Re: [gentoo-dev] Packages up for grabs: net-mail/notmuch, dev-python/..., erlang related, ...
* aide...@gentoo.org: > net-mail/muchsync > net-mail/notmuch I can take both. I already maintain these two for MacPorts, and I use notmuch daily (as in: right now). -Ralph
Re: [gentoo-dev] Last rites: net-mail/automx
Package www-servers/automx2 has now been moved to net-mail/automx2. -Ralph
Re: [gentoo-dev] Pull request related to the "GLEP81 and /home" discussion
https://github.com/gentoo/gentoo/pull/13265 As requested by David, I have added the proxy-maint team a week ago. Can somebody now please merge the pull request? The CI notes are unrelated. Thank you. -Ralph
Re: [gentoo-dev] Pull request related to the "GLEP81 and /home" discussion
As expected, CI checks complained about me being the sole maintainer of acct-*/amavis. I have therefore added the Antivirus Project, which matches mail-filter/amavisd-new. -Ralph
Re: [gentoo-dev] Pull request related to the "GLEP81 and /home" discussion
* Ulrich Mueller: > You had suggested /var/lib/amavishome in that PR, three months ago. > Is there any reason why this won't work? As far as I understand QA requirements in this matter, it should work, which is why I suggested /var/lib/amavishome as a compromise. I have modified the pull request accordingly. However, now that Michael stepped down, metadata.xml lists only me as maintainer, which does not suffice. -Ralph
[gentoo-dev] Pull request related to the "GLEP81 and /home" discussion
https://github.com/gentoo/gentoo/pull/13265 After following the recent discussion here, I ask that somebody please decide on what to do with this PR, which I opened 2019-10-12. Please either close the pull request, change it to fit QA needs, or merge it as it is. Unless this is decided in a pragmatic fashion in the coming days, I am going to step down as maintainer as well, as Michael already did. Personally, I found the discussion about home directories a prime example of one of the aspects that annoys me greatly about Gentoo. Keeping things "pure" should not stand in the way of getting things done. I have come to prefer a private overlay, because it allows me to avoid "defenders of the faith" to a certain degree. ;-) -Ralph
Re: [gentoo-dev] New acct-* package policy
* Martin Dummer: > A proxy-maintainer (like me) cannot commit or add github pull requests > for https://gitweb.gentoo.org/data/api.git/tree/files/uid-gid.tx We can, actually, using https://github.com/gentoo/api-gentoo-org to create pull requests in the usual manner. These PRs are usually processed significantly quicker than the ebuild-related ones. -Ralph
Re: [gentoo-dev] RFC: acct-{user,group} for milter (438)
* Michael Orlitzky: > I'm sure someone will object to the name acct-user/_milter-regex, but > that would be the easiest option, being the upstream default. Admittedly, _milter-regex makes me wince. It displeases my sense of aesthetics and affects sorting order in acct-*. I'd like to lose the underscore, and I'd be willing to tweak mail-filter/milter-regex to change Gentoo's default to milter-regex as well. "Everybody benefits!" (Markos, The Con of Kos) -Ralph
Re: [gentoo-dev] RFC: acct-{user,group} for milter (438)
> Milter-regex only needs a user to isolate the process and it's single > configuration file (/etc/milter-regex.conf). I forgot to mention: $ ls -l /etc/milter-regex.conf -rw-r--r-- 1 root root 2.3K Dec 14 22:13 /etc/milter-regex.conf Owned by root, world-readable because nothing sensitive is configured, so I see no security risk (from the POV of milter-regex) in regards to this config file. -Ralph
Re: [gentoo-dev] RFC: acct-{user,group} for milter (438)
* Michael Orlitzky: > (a) we still have a dumb security vulnerability, in that these daemons > can modify each others' files That vulnerability has existed as long as the second package came around and re-used the "milter" user, and to my knowledge nothing bad has come of it so far. I have an open PR[1] that the QA checks on GitHub will not allow to pass unless I migrate milter-regex to using acct-* instead of user.eclass, so that is what I did. [1] https://github.com/gentoo/gentoo/pull/13964 > (b) you have to be careful not to do anything in acct-user/milter that > could break someone's opendmarc setup Milter-regex only needs a user to isolate the process and it's single configuration file (/etc/milter-regex.conf). My PR adds acct-user/milter without a home directory, because milter-regex does not need one, nor does it write anything to disk. It is designed to hold everything in memory only. Could that lack of a home directory hurt OpenDMARC? I use OpenDMARC and milter-regex on the same servers and did not run into problems. -Ralph
Re: [gentoo-dev] RFC: acct-{user,group} for milter (438)
* Michael Orlitzky: > I guess we could keep "milter" for only regex-milter, but that has the > disadvantage that it messes with the opendmarc package in the meantime. Of the three packages you mentioned, milter-regex (not regex-milter) is the only one with a name that actually contains "milter". OpenDMARC should never have user a user named milter in the first place, and in the future it should use "opendmarc". Besides, since nobody has claimed group/user "milter" before me, I think this falls under first come, first serve. -Ralph
[gentoo-dev] RFC: acct-{user,group} for milter (438)
The mail-filter/milter-regex ebuild already uses user/group 'milter', and for the currently open bump to version 2.7 I'd like to claim GID/UID 438. I have checked the assignment list[1] and used Notmuch for a full text search of previous mentions of GID/UID 438. From what I can tell, 438 has not been requested before. -Ralph
Re: [gentoo-dev] packages up for grabs
* Tim Harder: > app-backup/duplicity I use duplicity myself and I'm interested in maintaining it, unless rich0 (who is now listed as the sole maintainer) has any objections. -Ralph
Re: [gentoo-dev] Last rites: net-mail/pflogsumm
* Tomas Mozes: > I'll take it: https://github.com/gentoo/gentoo/pull/13567 Thank you for stepping up for this oldie but goodie, Tomas. -Ralph
Re: [gentoo-dev] Change Bugzilla status to IN_PROGRESS when pull request is linked
* Kent Fredric: > If you want the "somebody is working on it", then you can just look at > the comments and linked PR already. After opening a bug, one can of course see all kinds of information. ;-) The nice thing about the status field is that it is usually displayed in bug list overviews, and that one can sort by it. In any case, if this feature is not to everybody's taste, it would need to be made a configurable option. That, I fear, would be too much effort when compared to the benefit the feature brings. /me shrugs -Ralph
Re: [gentoo-dev] Change Bugzilla status to IN_PROGRESS when pull request is linked
* Michał Górny: > Someone linking a pull request to somebody else's package does not > necessarily mean that the latter person is working on it. Personally, I interpret a bug status of IN_PROGRESS as "somebody is working this bug", not "the assignee is working this bug". The latter is not as important to the bug state anyway, don't you think? -Ralph
[gentoo-dev] Change Bugzilla status to IN_PROGRESS when pull request is linked
For convenience, would it be possible to automatically change the status of bugs from (UN)CONFIRMED to IN_PROGRESS when Larry The Cow attaches a pull request? I tend to forget to change the status myself, and perhaps I am not alone in feeling my age in that fashion. ;-) -Ralph
Re: [gentoo-dev] RFC: GID/UID assignment for OpenDKIM (334)
* Ralph Seichter: > I did [...] Actually I did not. You wrote "pull request", I only read "pull". :-P -Ralph
Re: [gentoo-dev] RFC: GID/UID assignment for OpenDKIM (334)
* Michał Górny: >> GID/UID 334 is already taken for OpenDKIM, even though the list has >> unfortunately not yet been updated. > > Submit a pull request to api-gentoo-org ;-). I did, but found that neither uid-git.txt nor https://wiki.gentoo.org/wiki/Project:Quality_Assurance/UID_GID_Assignment list 334 yet. -Ralph
Re: [gentoo-dev] RFC: GID/UID assignment for OpenDKIM (334)
* Ralph Seichter: > I'd like to reserve GID/UID 334 for mail-filter/opendkim (see QA bug > #694638). GID/UID 334 is already taken for OpenDKIM, even though the list has unfortunately not yet been updated. See https://archives.gentoo.org/gentoo-dev/message/6de44bcdfb6766fedddc45eede347e0c and https://github.com/gentoo/gentoo/pull/13029 . -Ralph
[gentoo-dev] RFC: GID/UID assignment for OpenDKIM (334)
I'd like to reserve GID/UID 334 for mail-filter/opendkim (see QA bug #694638). Arch and Fedora apparently don't have reserved IDs for OpenDKIM, and 334 is unclaimed in Gentoo. -Ralph
Re: [gentoo-dev] Last rites: sys-process/vixie-cron
* Michał Górny: > Unmaintained. Ancient. First release of vixie-cron: 1987. Cronie: 2007. Damn, this makes me feel old. :-/ -Ralph
Re: [gentoo-dev] Patch series: User and group for amavisd-new (UID/GID 333)
* Mike Gilbert: > Looks like you grabbed the ID from Arch? Indeed, Arch Linux uses 333 as well. -Ralph
[gentoo-dev] [PATCH 2/2] acct-user/amavis: new user (UID 333)
Signed-off-by: Ralph Seichter --- acct-user/amavis/amavis-0.ebuild | 12 acct-user/amavis/metadata.xml| 12 2 files changed, 24 insertions(+) create mode 100644 acct-user/amavis/amavis-0.ebuild create mode 100644 acct-user/amavis/metadata.xml diff --git a/acct-user/amavis/amavis-0.ebuild b/acct-user/amavis/amavis-0.ebuild new file mode 100644 index 000..8720ccf79bf --- /dev/null +++ b/acct-user/amavis/amavis-0.ebuild @@ -0,0 +1,12 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +ACCT_USER_ID=333 +ACCT_USER_GROUPS=( amavis ) +DESCRIPTION="User for mail-filter/amavisd-new" + +acct-user_add_deps diff --git a/acct-user/amavis/metadata.xml b/acct-user/amavis/metadata.xml new file mode 100644 index 000..68dee4eb504 --- /dev/null +++ b/acct-user/amavis/metadata.xml @@ -0,0 +1,12 @@ + +http://www.gentoo.org/dtd/metadata.dtd;> + + + m...@gentoo.org + Michael Orlitzky + + + gen...@seichter.de + Ralph Seichter + + -- 2.21.0
[gentoo-dev] Patch series: User and group for amavisd-new (UID/GID 333)
As suggested by Michael Orlitzky, I am submitting my patches to create a group and user 'amavis' according to GLEP 81 for review. -Ralph
[gentoo-dev] [PATCH 1/2] acct-group/amavis: new group (GID 333)
Signed-off-by: Ralph Seichter --- acct-group/amavis/amavis-0.ebuild | 9 + acct-group/amavis/metadata.xml| 12 2 files changed, 21 insertions(+) create mode 100644 acct-group/amavis/amavis-0.ebuild create mode 100644 acct-group/amavis/metadata.xml diff --git a/acct-group/amavis/amavis-0.ebuild b/acct-group/amavis/amavis-0.ebuild new file mode 100644 index 000..edfeefae77b --- /dev/null +++ b/acct-group/amavis/amavis-0.ebuild @@ -0,0 +1,9 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +ACCT_GROUP_ID=333 +DESCRIPTION="Group for mail-filter/amavisd-new" diff --git a/acct-group/amavis/metadata.xml b/acct-group/amavis/metadata.xml new file mode 100644 index 000..68dee4eb504 --- /dev/null +++ b/acct-group/amavis/metadata.xml @@ -0,0 +1,12 @@ + +http://www.gentoo.org/dtd/metadata.dtd;> + + + m...@gentoo.org + Michael Orlitzky + + + gen...@seichter.de + Ralph Seichter + + -- 2.21.0
Re: [gentoo-dev] New Python application with multiple new dependencies
* Mike Gilbert: > Speaking on behalf of the python team, we are not particularly keen on > maintaining libraries that are only used by a single package. We have > too many packages to care for already. I agree. I know about the various risks of dynamically installing dependencies, but "pip install X" in virtual environments is very useful nonetheless. Gentoo does not offer an equivalent (I'm not judging, just saying), and it seems to me that is causing the Python team a large amount of work, eating up resources that could be spent elsewhere. > Not everything needs to be handled in an ebuild; often it just > increases the amount of busy work you end up doing. Ebuilds are great when an application needs config files, init scripts, users/groups, and when app A connects to app B (for example, if there is a milter there will also be an MTA calling it). Two of the milters I am using happen to be written in Python. One requires pymilter, so I created a PR introducing a pymilter ebuild. I'd rather avoid that ebuild, because pymilter is an interface to libmilter and of little use of its own, but other apps depend on it. -Ralph
Re: [gentoo-dev] New Python application with multiple new dependencies
* Michał Górny: > I presume you want to proxy-maintain all of those packages. I would want to maintain the "monty" application because it offers functionality useful to me. I'm not particularly keen on maintaining Python ebuilds required as dependencies by only one application. Like everybody else, I have only a finite amount of time I can spend on Gentoo packages. I usually start with a separate venv for Python apps so I can "pip install ..." and make do without ebuilds. -Ralph P.S.: Thanks to you and Brian for your answers.
[gentoo-dev] New Python application with multiple new dependencies
Hi folks, imagine a Python application "monty" with the following requirements listed in setup.py: install_requires=[ 'ham>=1.0', 'spam>=2.0', 'eggs>=1.5' ] If I want to add "monty" as a new Gentoo package, and if none of "ham", "spam" and "eggs" are so far available as Gentoo packages, what is the recommended way of handling this situation? 1. Create one pull request that contains separate commits for adding each of the four Python packages? 2. Create four separate pull requests? 3. Find out there is an eclass I have missed so far which performs the equivalent of "pip install monty" and create an ebuild based on it? 4. None of the above. -Ralph
Re: [gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding
* Michael Orlitzky: > There are still some easy bugs open. Your turn =) Give it some time. ;-) Thank you for all your work, Michael. -Ralph
Re: [gentoo-dev] Re: [gentoo-dev-announce] (Lots of) Packages up for grabs due to net-mail@ project disbanding
* Francisco Blas Izquierdo Riera: > > mail-mta/postfix > > Some of my systems depend on this one so unless eras wants to take > care of it, I can try to do that. I doubt I'll do as good of a job > as he has done so far. All of my systems, and a big part of my business, depend on Postfix. I don't want to start a tug-of-war, but I have been building and using Postfix for roughly ten years now. I'm *certain* I'll do a good job. -Ralph
Re: [gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding
* Michael Orlitzky: > I'd be happy to work on all of that stuff either before or after you > guys take over and get settled in. I'd appreciate you adding all improvements you already have in store. It would be a shame to waste the work you have already done. -Ralph
Re: [gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding
* Aaron Bauman: > Please have a look at bug #629914 as well. Yeah, I've come across the key file permissions issue already. I've added myself as Cc for the bug for now, and I'll have a closer look over the coming days. -Ralph
Re: [gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding
* Michał Górny: > mail-filter/opendkim I can take OpenDKIM if no former team member wants to. > mail-mta/postfix > net-mail/pflogsumm I will gladly take these. Postfix is highly important for me, and the Postfix log summary seems like a natural addition. -Ralph
Re: [gentoo-dev] rfc: cron.* and modern cron implementations
* Toralf Förster: > I'm not 100% but IMO for a desktop this seems works whereas @daily or > @weekly in crontab works only for systems running 24h per day, isn't > it? That depends on what flavour of cron is used (see https://en.wikipedia.org/wiki/Anacron). -Ralph
Re: [gentoo-dev] Upstream build uses "npm install", how to handle this in an ebuild?
* Geaaru: > https://github.com/geaaru/node-ebuilder > > I wrote this tool that try to reduce workload on create ebuilds of all > dependencies of nodejs modules. This looks interesting, I'd like to try it. Alas, I can find neither documentation nor an example ebuild that would help me understand how your tool is meant to be used. BTW, I have asked the NGINX devs about how their build process and Gentoo's requirements could be married. I hope they will respond. -Ralph
Re: [gentoo-dev] Upstream build uses "npm install", how to handle this in an ebuild?
* Michael Orlitzky: > But, you're going to have problems [...] Ugh. Have you ever considered writing children's books? ;-) As some devs may remember, I've had "discussions" because of NGINX Unit before, especially about the way PHP support is implemented and how this differs from the Gentoo way of doing things. Now it seems like adding NodeJS support is becoming another source of joy. Well, thank you for your assessment, Michael. I'm not sure what I am going to do next, and how much time I want to spend with this. -Ralph
[gentoo-dev] Upstream build uses "npm install", how to handle this in an ebuild?
I am trying to add NodeJS support to www-servers/nginx-unit, but the upstream build relies on a working network connection to download dependencies and execute "npm install ..." during the build process. How can this scenario be handled properly in an ebuild? I don't see obvious existing ebuilds that I could use as a guide. Electron seems to perform some npm wizardry, but I don't know what to make of it. -Ralph
Re: [gentoo-dev] Locating "node-gyp" in an ebuild
* Ralph Seichter: > What is the recommended method to locate "node-gyp" in an ebuild? Nevermind. After reinstalling the module, I now have /usr/bin/node-gyp on my system, so node-gyp is available in PATH. -Ralph
[gentoo-dev] Locating "node-gyp" in an ebuild
What is the recommended method to locate "node-gyp" in an ebuild? I don't suppose /usr/lib64/node_modules/npm/bin/node-gyp-bin/node-gyp is a path I can expect to find on every Gentoo system with NodeJS. An eclass for NodeJS has been proposed on this mailing list before, but as far as I can tell no such eclass exists yet? -Ralph
Re: [gentoo-dev] Packages up for grabs from xmw@g.o
* Michał Górny: > Also note that there's a packaging request for media-radio/morse which > seemed relevant (and was assigned to xmw). Different beasts. "kochmorse" is authored by Hannes Matuschek, with a release two months ago. The last release of Eric S. Raymond's "Morse Classic" was about five years ago. -Ralph
Re: [gentoo-dev] Packages up for grabs from xmw@g.o
* Michał Górny: > media-radio/KochMorse That seems interesting, I'll take it. > net-vpn/aiccu Is this still being used? SixXS terminated services on 2017-06-06 (see https://www.sixxs.net/sunset/). -Ralph
Re: [gentoo-dev] Re: mail-filter/milter-regex pull request #10004
* Michael Orlitzky: > It's an open secret that packages maintained by > category-n...@gentoo.org are in reality unmaintained; or are > maintained by one guy (who may or may not be on the alias). As somebody who did not know that, and who was three weeks ago told to contact the Net-Mail team, I find this more than a little annoying. My time is just as valuable as everybody else's, after all. Why not flag packages with "needs maintainer" if the listed team is basically a mirage? When searching for Gentoo packages, I thought that if a team was listed as maintainers it was a sign that the package was well cared for, but from what I hear today that seems to be a misconception on my end. > Looking at the milter-regex history... you're the only person who > cares about it, so I think eventually the proxy maintainers should > just merge the PR barring any technical issues. Several developers stepped up today to help with this PR, for which I am grateful. Thanks to Lars Wendler, Michał Górny and Craig Andrews (in order of appearance) for picking up the ball. Milter-regex has now officially been passed into my and the Proxy Maintainer team's care and the pull request was merged. Standing on the outside looking in, I see a very busy P.M. team. Possibly too busy, as I mentioned before. Is this team bearing more load than others? Should responsibility be redistributed? I don't know the answers, but I can't avoid asking myself these questions. -Ralph
[gentoo-dev] Re: mail-filter/milter-regex pull request #10004
Three weeks ago I sent the message shown below to the Gentoo Net-Mail team. Since I did not receive a reply, I am now asking on this mailing list: What can I do to have the pull request, which I opened six weeks ago, taken care of? Thanks. To: net-m...@gentoo.org From: Ralph Seichter Subject: mail-filter/milter-regex pull request #10004 Message-ID: Date: Wed, 17 Oct 2018 12:29:23 +0200 Hello Net-Mail team, in https://archives.gentoo.org/gentoo-dev/message/e63b7e366f9061149ec9bd02847e7ec0 Virgil Dupras mentioned that I need to proactively pass pull request https://github.com/gentoo/gentoo/pull/10004 along. I'm not certain how this is best done, since I am not allow to assign issues in GitHub, so I am sending you this email. The PR has been reviewed and I made the one (very minor) requested change 19 days ago. I'd appreciate you taking over processing this PR from here. -Ralph P.S.: Please let me know if there is a better way to pass PRs to Gentoo developer teams.
Re: [gentoo-dev] Packages up for grabs: app-benchmarks/wrk, app-misc/gourmet, dev-python/elib-intl, games-misc/doge, net-misc/{httpie,proxytunnel}, sys-block/rts*
* Michał Górny: > The following packages are up for grabs after package reassignment > of inactive developers I'm willing to take care of "net-misc/httpie". -Ralph signature.asc Description: PGP signature
Re: [gentoo-dev] GitHub problems aftermath
> Just 'git commit --amen' to update the timestamp [...] Thanks Michał, that did the trick. -Ralph
[gentoo-dev] GitHub problems aftermath
According to https://status.github.com/ the technical problems have been fixed for a good 12 hours now, but I still have a pull request with the status "QA checks in progress". That message has now been displayed for almost 24 hours. Is there any way for me to restart the QA tests, other than a fresh commit? -Ralph
Re: [gentoo-dev] Is there any way I can help with pull requests?
On 16.10.18 20:25, Virgil Dupras wrote: > Maybe I can try to explain why your 3 PRs [1] are still opened. Thank you, I appreciate that, but let me repeat that my question about helping with PRs was not meant as criticism. > The "skel.ebuild" one is easy: global changes have to be discussed on > gentoo-dev. [...] You'll find that I only mentioned two open PRs of mine, because I took the skel.ebuild PR deliberately out of consideration. The conversation in that PR made it clear that it is a larger issue, to be handled by QA. No surprise there, let it simmer. ;-) > The milter-regex one is, I think, a result of miscommunicating intent. > [...] Someone from that project [2] is going to have merge it, not > zlogene. Ah, that's news to me. Should the PR then be assigned to the Net-Mail project in a publicly visible way? I'd like to see this merged, because it introduces a new milter-regex feature, one which I asked for and the author was kind enough to implement (and I also helped him to test it). > it's completely understandable that you expect a timely response to > your correction, but ultimately, you'll have to nudge someone from > the net-mail project. I had no idea that it is my responsibility to move this PR along. I had naively assumed that once a Proxy Maintainer project member had reviewed it, as it happened here, the process would continue without me unless more changes were asked for later on. Can you please tell me how I best hand this pull request to the Net-Mail team? > Then, we're left with your nginx-unit PR, which is part of the > proxy-maint program. In this case, we have mgorny who doesn't > seem to like your PR. I followed the PHP team's recommendation, as can be seen from the PR conversation and from the underlying Bugzilla report. While I respect Michał Górny's opinion, I understand that he does not have a deciding vote in this case. Michał may not fully agree with what the PHP team recommended, but I was told he's in the Python team. Let me quote from a conversation with Michael Orlitzky here (I have permission): [Michał is] probably just busy. His last comment didn't sound like he was strongly against it. He's probably thinking of it in terms of python (he's on the python team), where things are set up a bit better. With python stuff, PYTHON_TARGETS says what versions of python you want to use with the thing you're building. For example, you would probably use PYTHON_TARGETS if you wanted to support multiple python versions in nginx-unit. In that case, it's fine -- that's what PYTHON_TARGETS is for. We don't have a variable like that for PHP ebuilds. If you install some PHP code and switch to an interpreter that it doesn't work with... sorry, it'll just crash. Fixing that (like python/ruby do it) would be a huge effort and there's just not enough people interested in PHP. A long time ago, though, we needed a variable that let us build *extensions* for specific versions of PHP (this problem is a little easier to solve), aThe PHP team at the time stole the name *_TARGETS from python, even though it's not quite the same thing. Which brings us to why Michal is probably thinking PHP_TARGETS is what you want. It doesn't do the same thing as PYTHON_TARGETS, though. Feel free to quote me on any of this =) Again, I understand and respect that not everybody has the same view on things. I asked for the PHP team's advice, followed it, and if a third party does not agree, it does not bother me much. That's why there are different teams, after all. It is good that Michał Górny communicated his concerns, but he's the only person who spoke up and had no better alternative to offer. The modified ebuild (based on my own original) works fine, and I'd be glad to see this moved along. There was a bug filed for the lack of PHP support, and the PR also bumps the revision to the latest production release, made approx. one month ago. > As I hope to have demonstrated, there is no ill intent or even > negligence in the result that you observe. I had not suspected negligence or malice, but I am grateful for your explanations. I learned more about the process today. Thank you, Virgil. -Ralph
Re: [gentoo-dev] Is there any way I can help with pull requests?
On 13.10.18 20:00, Michał Górny wrote: > For example, in the recent period proxy-maint's backlog didn't really > go beyond 7 days, and we're rather capable of getting through it all. Glancing at my own open pull requests, it looks different (opened 15 and 25 days ago, respectively). That is not meant as criticism; it just seems to me that the team members who process PRs have a lot on their plates. > ~200 open pull requests is a really small number given the size of > Gentoo. You can easily find many projects having 1000-1 open pull > requests. 200 as an absolute number does not sound like too much, but it all depends on how many people process those PRs, and how much time they need to spend doing it. -Ralph
Re: [gentoo-dev] Is there any way I can help with pull requests?
On 13.10.2018 14:57, Thomas Deutschmann wrote: > Looking forward to see your Gentoo developer bug in near future! :-) I've sent an application to the recruiters' email address. We shall see what they think. ;-) -Ralph
Re: [gentoo-dev] Is there any way I can help with pull requests?
On 13.10.18 14:57, Thomas Deutschmann wrote: > Please read https://www.gentoo.org/get-involved/become-developer/ I already did that months ago. ;-) At that time, I was not certain if I had enough spare time to become involved enough to make going through the process of becoming a Gentoo developer worthwhile. I have contributed some PRs, and brought in www-servers/nginx-unit as a new package, for which I am designated proxy maintainer [1]. If there was an experienced team member willing to be my mentor, I'd be willing to take the next steps towards developer status. [1] https://bugs.gentoo.org/661450 -Ralph
[gentoo-dev] Is there any way I can help with pull requests?
Looking at the number of open pull requests (some of them my own), I wonder if Gentoo has become a bit of a victim of its own success as far as contributions are concerned. Is there any way I could help the Gentoo team? Any vacancies that need to be filled, or work that needs to be done? -Ralph
