Re: [gentoo-dev] [PATCH] Add heptapod to remote-id list

2020-08-26 Thread Michał Górny
On Thu, 2020-08-27 at 02:15 +0300, Azamat H. Hackimov wrote:
> Heptapod ( is open-source hosting based on
> GitLab for Mercurial repositories.

Please update the XML Schema as well.

Best regards,
Michał Górny

Description: This is a digitally signed message part

[gentoo-dev] [PATCH] Add heptapod to remote-id list

2020-08-26 Thread Azamat H. Hackimov
Heptapod ( is open-source hosting based on
GitLab for Mercurial repositories.

Signed-off-by: Azamat H. Hackimov 
 metadata.dtd | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/metadata.dtd b/metadata.dtd
index d02c5ac..7c07089 100644
--- a/metadata.dtd
+++ b/metadata.dtd
@@ -54,7 +54,7 @@

[gentoo-dev] Improving warnings on packages.g.o

2020-08-26 Thread Max Magorsch
Hi all,

Good news regarding packages.g.o!

While the new packages.g.o version went into production some time ago,
this also led to some false warnings about outdated package versions.
This is because we currently take information about outdated package
versions from, which are not always accurate.

To avoid these false warnings it's now possible to filter the repology
checks. To do so, there is a new git repository called
soko-metadata[0]. The repository contains a folder called repology,
which in turn contains three files:

1) ignored-repositories: You can add repositories that should be
globally ignored for the repology checks for *all* packages. E.g.
Windows only repositories as appget might be disabled globally here.

2) ignored-categories: You can disable the repology check for whole
categories here. The check will be disabled for all packages in this

3) ignored-packages: You can either disable the repology check for a
single package here (e.g. sys-auth/pambase), or disable a repository
for the repology check for a single package here using atom::repo
(e.g.: net-misc/dropbox::void_x86_64). The later option is especially
useful if another distribution creates a non-standard version for a
single package and all versions of other distributions are marked as
outdated because of this (as in the case of dropbox and void linux).

The soko-metadata repository is writable by all devs, so that all
package maintainers are welcome to contribute to reduce the number of
false warnings.



Re: [gentoo-dev] Packages up for grabs: app-portage/ufed, dev-libs/ustr, dev-libs/aws-...

2020-08-26 Thread Jonas Stein

I saw several reactions from you in tickets and mails; I answered in

I did not want to "kick out out" but I had the impression that you can
no longer maintain the packages as explained.

Hope to see many contributions from you soon.
If you have questions about how to fix your mail in bugzilla, do not
hesitate to ask on IRC.

I also saw, that you fixed now many tickets. Cool.


Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-26 Thread Adam Feldman
On 8/18/20 8:05 AM, Joonas Niilola wrote:
> Hey,
> some of you may already have seen the new page,
> and the new maintainer pages in it,
> If you open a maintainer page,
> you can see a tab called "pull requests" there,
> with description saying:
> "If you also like to help the Gentoo project, you can consider sending a
> Pull Request via GitHub.
> Before doing so, you might want to take a look at the wiki page."
> I'm suggesting of adding a new metadata flag to our Wiki's
> User:/Project: page which then prints a message to this page saying
> whether the maintainer (be it project or user), "accepts" or "deals
> with" Github contributions. The wording can be a bit better, but it'd be
> there to **notify** our **contributors** whether their time and effort
> will most likely be wasted making a pull request for this particular
> maintainer.
> This note would then be displayed in every package the maintainer is
> assigned to,
> I'd imagine a simple switch in Wiki could do it. No need to add anything
> to ::gentoo repo. The switch can be visible in User:/Project: page, but
> it doesn't have to. Unspecified metadata flag would print something like
> "This maintainer hasn't specified whether they handle Github pull
> requests. If you wish to help using Github, please also open a bug prior
> to that and link your pull request commit to that bug (add link to
> glep-66 here)". Or just default it to "No."
> Note that the bug text could always be displayed nevertheless, since
> that is still the main channel to communicate with maintainers.
> It's undeniable we get a lot of pull requests and unfortunate that many
> are left without any attention to rot.
> I think this would serve both parties - devs and contributors, with
> little to no cost.
> -- juippis

Personally, I'd rather see a generic package maintenance tags.
"Accepts Github PRs"
"Accepts any contribution freely"
"Accepts project member contributions"
"Accepts contributions after contact/N Week timeout"
"Accepts no contributions"
or similar

Most of my packages fall within projects that keep synchronized with
external overlays/repositories and it drives me absolutely bonkers when
someone edits my packages (contrary to Gentoo official policy) without
speaking to me first so that I can ensure the changes are replicated.
So I'd welcome something that pushes further standardization of that
preexisting policy.  Allow devs to specify when they are OK with
relaxing the existing policy, but keep it in force for those who want
and/or need it.


Adam Feldman
Gentoo Developer

Description: OpenPGP digital signature

[gentoo-dev] [PATCH] git-r3: fetch pullrequest refs on mirror clone type

2020-08-26 Thread fepitre
Signed-off-by: Frédéric Pierret (fepitre) 
 eclass/git-r3.eclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index 6c75d11218c..cda7ac161e9 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -683,6 +683,8 @@ git-r3_fetch() {
# notes in case something needs them
+   # pullrequest refs are useful for 
testing incoming changes
+   "+refs/pull/*/head:refs/pull/*"
# and HEAD in case we need the default 
# (we keep it in refs/git-r3 since 
otherwise --prune interferes)

[gentoo-dev] Last rites: dev-libs/hsa-ext-rocr

2020-08-26 Thread Marek Szuba
# Marek Szuba  (2020-08-26)
# ROCm has had open-source OpenCL image support since 3.3, and since 3.7
# it no longer attempts to use the proprietary library even when it is
# present. Last but not least, upstream no longer publishes this.
# Removal in 30 days. Bug #739066.


Description: OpenPGP digital signature