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
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
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
>
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
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
> Just 'git commit --amen' to update the timestamp [...]
Thanks Michał, that did the trick.
-Ralph
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
* 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
...@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
* 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
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
* 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
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
* 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
* 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
* 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
* 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
* Michael Orlitzky:
> There are still some easy bugs open. Your turn =)
Give it some time. ;-) Thank you for all your work, Michael.
-Ralph
* 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
* 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
* 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
* 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
* 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
* 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
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
* 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
* Mike Gilbert:
> Looks like you grabbed the ID from Arch?
Indeed, Arch Linux uses 333 as well.
-Ralph
As suggested by Michael Orlitzky, I am submitting my patches to create
a group and user 'amavis' according to GLEP 81 for review.
-Ralph
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
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
* Michał Górny:
> Unmaintained. Ancient.
First release of vixie-cron: 1987. Cronie: 2007. Damn, this makes me
feel old. :-/
-Ralph
* 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
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
* 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
* 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
> 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
* 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
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
* 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
* 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
* 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
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
* 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/6de44bcdfb6766fedddc45eede
* 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
* Ralph Seichter:
> I did [...]
Actually I did not. You wrote "pull request", I only read "pull". :-P
-Ralph
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
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
* 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
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
* 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
* 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
Package www-servers/automx2 has now been moved to net-mail/automx2.
-Ralph
* 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
* 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
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
55 matches
Mail list logo
