Re: [gentoo-dev] [PATCH] Add heptapod to remote-id list
On Thu, 2020-08-27 at 02:15 +0300, Azamat H. Hackimov wrote: > Heptapod (https://foss.heptapod.net/) is open-source hosting based on > GitLab for Mercurial repositories. > Please update the XML Schema as well. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] Add heptapod to remote-id list
Heptapod (https://foss.heptapod.net/) 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 @@ - + -- 2.26.2
[gentoo-dev] Improving warnings on packages.g.o
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 repology.org, 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 category. 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. -M [0] https://gitweb.gentoo.org/sites/soko-metadata.git/
Re: [gentoo-dev] Packages up for grabs: app-portage/ufed, dev-libs/ustr, dev-libs/aws-...
Hi, I saw several reactions from you in tickets and mails; I answered in https://bugs.gentoo.org/633138#c7 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. -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
On 8/18/20 8:05 AM, Joonas Niilola wrote: > Hey, > > some of you may already have seen the new packages.gentoo.org page, > https://packages.gentoo.org/ > > and the new maintainer pages in it, > https://packages.gentoo.org/maintainers > > If you open a maintainer page, > https://packages.gentoo.org/maintainer/juip...@gentoo.org > > you can see a tab called "pull requests" there, > https://packages.gentoo.org/maintainer/juip...@gentoo.org/pull-requests > > 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, > https://packages.gentoo.org/packages/media-libs/rlottie/pull-requests > > 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. > https://github.com/gentoo/gentoo/pulls > > 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. -- Thanks, Adam Feldman Gentoo Developer np-hard...@gentoo.org 0x671C52F118F89C67 signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH] git-r3: fetch pullrequest refs on mirror clone type
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() {
"+refs/tags/*:refs/tags/*"
# notes in case something needs them
"+refs/notes/*:refs/notes/*"
+ # pullrequest refs are useful for
testing incoming changes
+ "+refs/pull/*/head:refs/pull/*"
# and HEAD in case we need the default
branch
# (we keep it in refs/git-r3 since
otherwise --prune interferes)
"+HEAD:refs/git-r3/HEAD"
--
2.25.4
[gentoo-dev] Last rites: dev-libs/hsa-ext-rocr
# 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. dev-libs/hsa-ext-rocr -- Marecki signature.asc Description: OpenPGP digital signature
