Re: [gentoo-dev] Various packages up for grabs (avahi, curl, fcron, tor...)
La 28.01.2023 22:11, Michał Górny a scris: Hi, Per blueness' request, some of his packages are now looking for a new maintainer. The affected packages are: acct-group/at acct-group/avahi acct-group/avahi-autoipd acct-group/axtls acct-group/bitflu acct-group/cron acct-group/fcron acct-group/monkeyd acct-group/netdev acct-group/stubby acct-group/stunnel acct-group/thttpd acct-group/tor acct-group/varnish acct-user/at acct-user/avahi acct-user/avahi-autoipd acct-user/axtls acct-user/bitflu acct-user/cron acct-user/fcron acct-user/monkeyd acct-user/stubby acct-user/stunnel acct-user/thttpd acct-user/tor acct-user/varnish app-benchmarks/libc-bench app-crypt/libscrypt app-crypt/md5deep app-doc/halibut app-forensics/unhide app-shells/squirrelsh app-text/xapian-omega dev-libs/libcgroup dev-libs/libelf dev-libs/libgpiod dev-libs/xapian dev-libs/xapian-bindings dev-perl/Search-Xapian dev-python/pyqt-distutils dev-util/gperf dev-util/plan9port games-misc/sound-of-sorting net-analyzer/2ping net-dns/avahi net-dns/c-ares net-dns/getdns net-firewall/xtables-addons net-libs/axtls net-libs/libnatpmp net-libs/mbedtls net-libs/stem net-misc/arpd net-misc/curl net-misc/ipv6calc net-misc/nat-traverse net-misc/ntpsec net-misc/nyx net-misc/stunnel net-p2p/bitflu net-proxy/torsocks net-vpn/tor sec-keys/openpgp-keys-danielstenberg sec-keys/openpgp-keys-tor sys-apps/agedu sys-devel/ct-ng sys-fs/encfs sys-fs/f2fs-tools I use both encfs and f2fs, I can take care of them. I clicked the wrong reply button yesterday. I'll add myself co-maintainer to both. sys-process/at sys-process/cronbase sys-process/fcron virtual/cron virtual/libelf www-servers/monkeyd www-servers/varnish Regards, Viorel
Re: [gentoo-dev] dev-python/ package naming policy?
On Sun, 2023-01-29 at 02:15 +0300, Torokhov Sergey wrote:
> As for replacing dot (".") with hyphen ("-") I have PyPi package
> "FoBiS.py" that is packaged in ::guru just as "FoBiS" as I wasn't sure
> is it worth to store ".py" suffix while github repo of this project is
> just "FoBiS". So there could be a problem if package named "fobis"
> will appear in PyPi.
Thanks for this example. This is actually a perfect case that makes you
really, really think about dropping ".py" and a perfect explanation why
we should keep it, even if it makes the package name look "unnatural".
--
Best regards,
Michał Górny
Re: [gentoo-dev] Various packages up for grabs (avahi, curl, fcron, tor...)
Hi, I'll take the following as proxy-maintainer (for now): acct-user/at acct-group/at sys-process/at sys-fs/encfs Related PRs: https://github.com/gentoo/gentoo/pull/29325 https://github.com/gentoo/gentoo/pull/29326 Cheers, Zoltan
Re: [gentoo-dev] Various packages up for grabs (avahi, curl, fcron, tor...)
> On 28 Jan 2023, at 20:24, Michał Górny wrote: > > On Sat, 2023-01-28 at 21:18 +0100, Michał Górny wrote: >> On Sat, 2023-01-28 at 21:11 +0100, Michał Górny wrote: >>> Hi, >>> >>> Per blueness' request, some of his packages are now looking for a new >>> maintainer. The affected packages are: >>> >> >> Also packages that were left without a proxy: >> >> dev-libs/libbase58 >> net-misc/bfgminer >> > > Two more, forgive my incompetence: > [..] > net-libs/libmicrohttpd > I've put back the proxied maint for libmicrohttpd w/ proxy-maint@. signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] Various packages up for grabs (avahi, curl, fcron, tor...)
> On 28 Jan 2023, at 20:11, Michał Górny wrote: > > Hi, > > Per blueness' request, some of his packages are now looking for a new > maintainer. The affected packages are: > > > dev-util/gperf > net-misc/curl > sys-fs/f2fs-tools > sys-process/cronbase > virtual/cron Taken for base-system@. Co-maint welcome for all but especially for gperf+curl+f2fs-tools. Please add yourself too! > virtual/libelf Taken for toolchain@. Best, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] dev-python/ package naming policy?
The similar names in PyPi is a real problem for users when trying to find associated packages. It's also could be a security issue for them with malicious packages named like popular packages. So in ::guru I try to save package naming even if it's too CamelCase.As for replacing dot (".") with hyphen ("-") I have PyPi package "FoBiS.py" that is packaged in ::guru just as "FoBiS" as I wasn't sure is it worth to store ".py" suffix while github repo of this project is just "FoBiS". So there could be a problem if package named "fobis" will appear in PyPi.28.01.2023, 19:38, "Michał Górny" :Hi, everyone.TL;DR: I'd like to propose naming dev-python/* packages following PyPInames whenever possible, case-preserving, with modifications only whennecessary to match PN rules.So far the naming in dev-python/* hasn't been exactly consistent. Myself I've been mostly following "whatever's the easiest" policy whichgenerally meant following GitHub project names whenever we fetched fromthere.This mostly made sense so far, as I've been thinking of dev-python/primarily in terms of dependencies of other packages. However, it'sbeen pointed out that this makes it hard for people to find packagesthey're looking for.The vast majority of packages in dev-python/ are also published on PyPI[1]. They can afterwards be installed using tools such as pip, orspecified as dependencies of other projects — using their PyPI namesin every case.On top of that, it is not unknown for multiple packages with verysimilar names to coexis, say "foo", "pyfoo" and "python-foo". When GHproject names come into the picture, this can get even more ambiguous. Don't even get me started about developers pushing duplicate packagesbecause they didn't find the existing instance.To improve consistency and make packages easier to find, I'd like topropose going forward that when packages are published on PyPI, we usetheir official PyPI names. This also means preserving the case forthe few packages that use CamelCase names and similar.Some modifications will be necessary. For example, it is legal for PyPIpackage names to include dot (".") — we normally translate that to ahyphen ("-"). We may also have use cases for creating multiple Gentoopackages from the same PyPI package (see e.g. dev-python/ensurepip-*). Then, there are of course Python packages that aren't published on PyPI.Still, I think as a general rule of thumb this would make sense. WDYT?[1] https://pypi.org/-- Best regards,Michał Górny
Re: [gentoo-dev] dev-python/ package naming policy?
On 28/01/2023 17.38, Michał Górny wrote: To improve consistency and make packages easier to find, I'd like to propose going forward that when packages are published on PyPI, we use their official PyPI names. This also means preserving the case for the few packages that use CamelCase names and similar. Consistency is generally a good thing. So +1 FTR, I think this should probably be applied in general in such situations, and not just for the Python ecosystem. - Flow
Re: [gentoo-dev] dev-python/ package naming policy?
> On Sat, 28 Jan 2023, Andrew Ammerlaan wrote: > Each of these is a different package. The package you usually want is > GitPython, but if we would name it gitpython or git-python, things > would get very confusing very quickly. In fact, this package was > renamed precisely to avoid this confusion in [1]. This is not the only > case where there are very similarly named packages on pypi. By having > a 1 to 1 mapping between names in pypi and names in ::gentoo we avoid > this confusion. Looking at mgorny's list, you cannot have an 1 to 1 mapping anyway, because that would result in invalid PN names. signature.asc Description: PGP signature
Re: [gentoo-dev] Various packages up for grabs (avahi, curl, fcron, tor...)
On Sat, 2023-01-28 at 21:18 +0100, Michał Górny wrote: > On Sat, 2023-01-28 at 21:11 +0100, Michał Górny wrote: > > Hi, > > > > Per blueness' request, some of his packages are now looking for a new > > maintainer. The affected packages are: > > > > Also packages that were left without a proxy: > > dev-libs/libbase58 > net-misc/bfgminer > Two more, forgive my incompetence: app-backup/spideroak-bin net-libs/libmicrohttpd -- Best regards, Michał Górny
Re: [gentoo-dev] Various packages up for grabs (avahi, curl, fcron, tor...)
On Sat, 2023-01-28 at 21:11 +0100, Michał Górny wrote: > Hi, > > Per blueness' request, some of his packages are now looking for a new > maintainer. The affected packages are: > Also packages that were left without a proxy: dev-libs/libbase58 net-misc/bfgminer -- Best regards, Michał Górny
[gentoo-dev] Various packages up for grabs (avahi, curl, fcron, tor...)
Hi, Per blueness' request, some of his packages are now looking for a new maintainer. The affected packages are: acct-group/at acct-group/avahi acct-group/avahi-autoipd acct-group/axtls acct-group/bitflu acct-group/cron acct-group/fcron acct-group/monkeyd acct-group/netdev acct-group/stubby acct-group/stunnel acct-group/thttpd acct-group/tor acct-group/varnish acct-user/at acct-user/avahi acct-user/avahi-autoipd acct-user/axtls acct-user/bitflu acct-user/cron acct-user/fcron acct-user/monkeyd acct-user/stubby acct-user/stunnel acct-user/thttpd acct-user/tor acct-user/varnish app-benchmarks/libc-bench app-crypt/libscrypt app-crypt/md5deep app-doc/halibut app-forensics/unhide app-shells/squirrelsh app-text/xapian-omega dev-libs/libcgroup dev-libs/libelf dev-libs/libgpiod dev-libs/xapian dev-libs/xapian-bindings dev-perl/Search-Xapian dev-python/pyqt-distutils dev-util/gperf dev-util/plan9port games-misc/sound-of-sorting net-analyzer/2ping net-dns/avahi net-dns/c-ares net-dns/getdns net-firewall/xtables-addons net-libs/axtls net-libs/libnatpmp net-libs/mbedtls net-libs/stem net-misc/arpd net-misc/curl net-misc/ipv6calc net-misc/nat-traverse net-misc/ntpsec net-misc/nyx net-misc/stunnel net-p2p/bitflu net-proxy/torsocks net-vpn/tor sec-keys/openpgp-keys-danielstenberg sec-keys/openpgp-keys-tor sys-apps/agedu sys-devel/ct-ng sys-fs/encfs sys-fs/f2fs-tools sys-process/at sys-process/cronbase sys-process/fcron virtual/cron virtual/libelf www-servers/monkeyd www-servers/varnish -- Best regards, Michał Górny
Re: [gentoo-dev] dev-python/ package naming policy?
On Sat, 2023-01-28 at 22:15 +0500, Anna (cybertailor) Vyalkova wrote:
> I'd prefer if PyPI names are guidelines, not a strict policy. I don't
> like CamelCase and separators other than dash ("-") :P
>
> Also I don't like when packages are named "dev-python/python-foo"
> instead of just "dev-python/foo".
>
So instead you claim "foo" and block adding actual "foo" later?
--
Best regards,
Michał Górny
[gentoo-dev] [PATCH] waf-utils.eclass: enable parallel install
This gives a nice speedup to net-fs/samba, which (re)links several
hundred files in its install phase.
Bug: https://bugs.gentoo.org/715542
Signed-off-by: Mike Gilbert
---
eclass/waf-utils.eclass | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/eclass/waf-utils.eclass b/eclass/waf-utils.eclass
index 1be02bbea3c..e72676d0656 100644
--- a/eclass/waf-utils.eclass
+++ b/eclass/waf-utils.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: waf-utils.eclass
@@ -138,8 +138,9 @@ waf-utils_src_install() {
export PYTHONHASHSEED=1
- echo "\"${WAF_BINARY}\" --jobs=1 --destdir=\"${D}\" ${*} install"
- "${WAF_BINARY}" --jobs=1 --destdir="${D}" "${@}" install || die "Make
install failed"
+ local jobs="--jobs=$(makeopts_jobs)"
+ echo "\"${WAF_BINARY}\" ${jobs} --destdir=\"${D}\" ${*} install"
+ "${WAF_BINARY}" ${jobs} --destdir="${D}" "${@}" install || die "Make
install failed"
# Manual document installation
einstalldocs
--
2.39.0
[gentoo-dev] Re: Last rites: app-admin/gkrellm & plugins
[ This has been posted on Gentoo User, but in case it hasn't been seen by discussants at Gentoo Dev, here it is. It seems clear upstream isn't dead, simply quiet ] On 1/28/23 05:35, Peter Humphrey wrote: > I'm actually the one who first heard that the original maintainer had died. > I had written to him about some support issue, and got a belated reply > from his brother. Upstream is not dead at all, > the activity level is just fairly low. > I tried to post to -dev, but my message never got through, > not sure if it's because I'm not a dev or made some other error in sending. > The homepage is at htttps://gkrellm.srcbox.net > with source at https://git.srcbox.net/gkrellm/gkrellm. > The main problem is that is still uses gtk+2. > They do have an open issue about that, > but most of the discussion has been on why it would be so hard to upgrade. > There is apparently a lot of fairly low-level graphics stuff going on > and Bill himself (the original maintainer) > said something like the conversion to gkt+3 would be difficult, > but to go to gtk+4 would essentially be a re-write. > Jack -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] dev-python/ package naming policy?
On 2023-01-28 19:02, Ulrich Mueller wrote: > > On Sat, 28 Jan 2023, Michał Górny wrote: > >> However, it's been pointed out that this makes it hard for people to > >> find packages they're looking for. > > I don't understand this argument. Why would all-lowercase make finding a > package harder? It doesn't. `eix` search is case-insensitive.
Re: [gentoo-dev] dev-python/ package naming policy?
On 28/01/2023 19:02, Ulrich Mueller wrote: On Sat, 28 Jan 2023, Michał Górny wrote: However, it's been pointed out that this makes it hard for people to find packages they're looking for. I don't understand this argument. Why would all-lowercase make finding a package harder? Here's an example, on pypi we have packages: - git-python - python-git - GitPython - git-py Each of these is a different package. The package you usually want is GitPython, but if we would name it gitpython or git-python, things would get very confusing very quickly. In fact, this package was renamed precisely to avoid this confusion in [1]. This is not the only case where there are very similarly named packages on pypi. By having a 1 to 1 mapping between names in pypi and names in ::gentoo we avoid this confusion. Best regards, Andrew [1] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0dec450a90c7490f11df7e69cd9c6709c099285c
Re: [gentoo-dev] dev-python/ package naming policy?
> On Sat, 28 Jan 2023, Michał Górny wrote: > Based on existing remote-id entries, the following package names are > mismatched (PN on left, PyPI name on right). Note that some of the IDs > could be wrong, particularly because PyPI "autocorrects" - vs _. Are there any rules by which upstream use of upper vs lower case can be predicted? On first glance they look completely random, which is exactly the reason why we have an all-lowercase policy for PN. >> However, it's been pointed out that this makes it hard for people to >> find packages they're looking for. I don't understand this argument. Why would all-lowercase make finding a package harder? signature.asc Description: PGP signature
Re: [gentoo-dev] dev-python/ package naming policy?
On Sat, Jan 28, 2023 at 05:38:05PM +0100, Michał Górny wrote:
> Hi, everyone.
>
> TL;DR: I'd like to propose naming dev-python/* packages following PyPI
> names whenever possible, case-preserving, with modifications only when
> necessary to match PN rules.
>
>
> So far the naming in dev-python/* hasn't been exactly consistent.
> Myself I've been mostly following "whatever's the easiest" policy which
> generally meant following GitHub project names whenever we fetched from
> there.
>
> This mostly made sense so far, as I've been thinking of dev-python/
> primarily in terms of dependencies of other packages. However, it's
> been pointed out that this makes it hard for people to find packages
> they're looking for.
>
> The vast majority of packages in dev-python/ are also published on PyPI
> [1]. They can afterwards be installed using tools such as pip, or
> specified as dependencies of other projects — using their PyPI names
> in every case.
>
> On top of that, it is not unknown for multiple packages with very
> similar names to coexis, say "foo", "pyfoo" and "python-foo". When GH
> project names come into the picture, this can get even more ambiguous.
> Don't even get me started about developers pushing duplicate packages
> because they didn't find the existing instance.
>
>
> To improve consistency and make packages easier to find, I'd like to
> propose going forward that when packages are published on PyPI, we use
> their official PyPI names. This also means preserving the case for
> the few packages that use CamelCase names and similar.
>
> Some modifications will be necessary. For example, it is legal for PyPI
> package names to include dot (".") — we normally translate that to a
> hyphen ("-"). We may also have use cases for creating multiple Gentoo
> packages from the same PyPI package (see e.g. dev-python/ensurepip-*).
> Then, there are of course Python packages that aren't published on PyPI.
>
> Still, I think as a general rule of thumb this would make sense. WDYT?
Just to say I'm all for it. As much as I don't like some of the
pypi^H^H^H^HPyPi^HI names and mismatches from the "typical" style
used in the tree, it's a small price to pay for consistency within
this large group of packages.
>
>
> [1] https://pypi.org/
--
ionen
signature.asc
Description: PGP signature
Re: [gentoo-dev] dev-python/ package naming policy?
I'd prefer if PyPI names are guidelines, not a strict policy. I don't
like CamelCase and separators other than dash ("-") :P
Also I don't like when packages are named "dev-python/python-foo"
instead of just "dev-python/foo".
Re: [gentoo-dev] dev-python/ package naming policy?
On Sat, 2023-01-28 at 17:38 +0100, Michał Górny wrote: > TL;DR: I'd like to propose naming dev-python/* packages following PyPI > names whenever possible, case-preserving, with modifications only when > necessary to match PN rules. Based on existing remote-id entries, the following package names are mismatched (PN on left, PyPI name on right). Note that some of the IDs could be wrong, particularly because PyPI "autocorrects" - vs _. aiohttp-cors | aiohttp_cors anyqt | AnyQt automat | Automat aws-xray-sdk-python | aws-xray-sdk blake3-py | blake3 boolean-py| boolean.py bottleneck| Bottleneck cachecontrol | CacheControl cangjie | CangJie cerberus | Cerberus certifi | certifi-system-store chameleon | Chameleon charset_normalizer| charset-normalizer cheetah3 | Cheetah3 cherrypy | CherryPy cjkwrap | CJKwrap cli_helpers | cli-helpers collective-checkdocs | collective.checkdocs configupdater | ConfigUpdater cx_Freeze | cx-Freeze cython| Cython deprecated| Deprecated discogs-client| python3-discogs-client django| Django django_polymorphic| django-polymorphic dogpile-cache | dogpile.cache easyprocess | EasyProcess editorconfig-core-py | EditorConfig elasticsearch-py | elasticsearch7 ensurepip-pip | pip ensurepip-setuptools | setuptools ensurepip-wheels | pip et_xmlfile| et-xmlfile eyeD3 | eyed3 flask-api | Flask-API flask-babel | Flask-Babel flask-compress| Flask-Compress flask-cors| Flask-Cors flask-debug | Flask-Debug flask-gravatar| Flask-Gravatar flask-htmlmin | Flask-HTMLmin flask-login | Flask-Login flask | Flask flask-migrate | Flask-Migrate flask-paranoid| Flask-Paranoid flask-script | Flask-Script flask-sphinx-themes | Flask-Sphinx-Themes flit_core | flit-core flit_scm | flit-scm flufl-lock| flufl.lock genshi| Genshi github3 | github3.py gmpy | gmpy2 google-reauth-python | google-reauth hcloud-python | hcloud imapclient| IMAPClient importlib_metadata| importlib-metadata importlib_resources | importlib-resources indexed_gzip | indexed-gzip jack-client | JACK-Client jaraco-classes| jaraco.classes jaraco-collections| jaraco.collections jaraco-context| jaraco.context jaraco-envs | jaraco.envs jaraco-functools | jaraco.functools jaraco-itertools | jaraco.itertools jaraco-logging| jaraco.logging jaraco-path | jaraco.path jaraco-stream | jaraco.stream jaraco-test | jaraco.test jaraco-text | jaraco.text jinja | Jinja2 js2py | Js2Py jschema_to_python | jschema-to-python jupyter_client| jupyter-client jupyter_console | jupyter-console jupyter_core | jupyter-core jupyter_events| jupyter-events jupyter_kernel_test | jupyter-kernel-test jupyterlab_pygments | jupyterlab-pygments jupyterlab_server | jupyterlab-server jupyter_packaging | jupyter-packaging jupyter_server_mathjax| jupyter-server-mathjax jupyter_server| jupyter-server keyrings-alt | keyrings.alt keystoneauth | keystoneauth1 libcloud
[gentoo-dev] dev-python/ package naming policy?
Hi, everyone.
TL;DR: I'd like to propose naming dev-python/* packages following PyPI
names whenever possible, case-preserving, with modifications only when
necessary to match PN rules.
So far the naming in dev-python/* hasn't been exactly consistent.
Myself I've been mostly following "whatever's the easiest" policy which
generally meant following GitHub project names whenever we fetched from
there.
This mostly made sense so far, as I've been thinking of dev-python/
primarily in terms of dependencies of other packages. However, it's
been pointed out that this makes it hard for people to find packages
they're looking for.
The vast majority of packages in dev-python/ are also published on PyPI
[1]. They can afterwards be installed using tools such as pip, or
specified as dependencies of other projects — using their PyPI names
in every case.
On top of that, it is not unknown for multiple packages with very
similar names to coexis, say "foo", "pyfoo" and "python-foo". When GH
project names come into the picture, this can get even more ambiguous.
Don't even get me started about developers pushing duplicate packages
because they didn't find the existing instance.
To improve consistency and make packages easier to find, I'd like to
propose going forward that when packages are published on PyPI, we use
their official PyPI names. This also means preserving the case for
the few packages that use CamelCase names and similar.
Some modifications will be necessary. For example, it is legal for PyPI
package names to include dot (".") — we normally translate that to a
hyphen ("-"). We may also have use cases for creating multiple Gentoo
packages from the same PyPI package (see e.g. dev-python/ensurepip-*).
Then, there are of course Python packages that aren't published on PyPI.
Still, I think as a general rule of thumb this would make sense. WDYT?
[1] https://pypi.org/
--
Best regards,
Michał Górny
[gentoo-dev] [PATCH] rocm.eclass: support RDNA3 GPU for >=5.4, remove <5
ROCm libraries with version <5 are cleaned up, remove version 4 support
for rocm.eclass.
RDNA3 has initial support in ROCm libraries starting from 5.4 releases.
Enable gfx110* amdgpu_targets in rocm.eclass and add corresponding
description.
Tried =sci-libs/rocBLAS-5.4.2, can compile successfully with
amdgpu_targets_gfx1100 (but not tested on real GPU).
rocBLAS-5.4.2.ebuild is in https://github.com/gentoo/gentoo/pull/29319
The github PR for this patch is at
https://github.com/gentoo/gentoo/pull/29320
Closes: https://bugs.gentoo.org/891499
Signed-off-by: Yiyang Wu
---
eclass/rocm.eclass| 13 +++--
profiles/desc/amdgpu_targets.desc | 5 -
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/eclass/rocm.eclass b/eclass/rocm.eclass
index cf7a18b70ad2..b78dfea1cc31 100644
--- a/eclass/rocm.eclass
+++ b/eclass/rocm.eclass
@@ -1,4 +1,4 @@
-# Copyright 2022 Gentoo Authors
+# Copyright 2022-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: rocm.eclass
@@ -138,17 +138,18 @@ _rocm_set_globals() {
# may help. Gentoo have patches to enable gfx1031 as well.
local unofficial_amdgpu_targets official_amdgpu_targets
case ${ROCM_VERSION} in
- 4.*)
+ 5.[0-3].*)
unofficial_amdgpu_targets=(
- gfx803 gfx900 gfx1010 gfx1011 gfx1012 gfx1030
+ gfx803 gfx900 gfx1010 gfx1011 gfx1012 gfx1031
)
official_amdgpu_targets=(
- gfx906 gfx908
+ gfx906 gfx908 gfx90a gfx1030
)
;;
- 5.*)
+ 5.*|)
unofficial_amdgpu_targets=(
- gfx803 gfx900 gfx1010 gfx1011 gfx1012 gfx1031
+ gfx803 gfx900 gfx1010 gfx1011 gfx1012
+ gfx1031 gfx1100 gfx1101 gfx1102
)
official_amdgpu_targets=(
gfx906 gfx908 gfx90a gfx1030
diff --git a/profiles/desc/amdgpu_targets.desc
b/profiles/desc/amdgpu_targets.desc
index 66a9a7a85935..9c5739e9d9a4 100644
--- a/profiles/desc/amdgpu_targets.desc
+++ b/profiles/desc/amdgpu_targets.desc
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors.
+# Copyright 1999-2023 Gentoo Authors.
# Distributed under the terms of the GNU General Public License v2
# Reference:
@@ -15,3 +15,6 @@ gfx1011 - RDNA GPU, codename navi12, including Radeon Pro
5600M/V520
gfx1012 - RDNA GPU, codename navi14, including Radeon RX
5500XT/5500/5500M/5500XTB/5300/5300M, Radeon Pro 5500XT/5500M/5300/5300M,
Radeon Pro W5500X/W5500/W5500M/W5300M
gfx1030 - RDNA2 GPU, codename navi21/sienna cichlid, including Radeon RX
6950XT/6900XT/6800XT/6800, Radeon Pro W6800
gfx1031 - RDNA2 GPU, codename navi22/navy flounder, including Radeon RX
6750XT/6700XT/6800M/6700M
+gfx1100 - RDNA3 GPU, codename navi31/plum bonito, including Radeon RX
7900XTX/7900XT
+gfx1101 - RDNA3 GPU, codename navi32
+gfx1102 - RDNA3 GPU, codename navi33
--
2.39.0
[gentoo-dev] desktop.eclass: allow 1024 as a size for icons
Hello,
As discussed in https://bugs.gentoo.org/888635 , 1024x1024 icons are
starting to be deployed in some apps as they start to be used in MacOSX
environment. Some weeks ago I needed to skip their installation for
net-im/rocketchat-desktop-bin and I saw that net-analyzer/wireshark is
workarounding the problem by manually installing them without
desktop.eclass helpers.
I would then simply add 1024 to the list of allowed sizes too
Thanks
diff --git a/desktop.eclass~ b/desktop.eclass
index aa1b9ac..ea5c84c 100644
--- a/desktop.eclass~
+++ b/desktop.eclass
@@ -311,7 +311,7 @@ _iconins() {
size=${2}
fi
case ${size} in
- 16|22|24|32|36|48|64|72|96|128|192|256|512)
+
16|22|24|32|36|48|64|72|96|128|192|256|512|1024)
size=${size}x${size};;
symbolic|scalable)
;;
@@ -369,7 +369,7 @@ _iconins() {
#!!! must specify to install into /usr/share/icons/... !!!
#size of the icon, like 48 or 48x48
#supported icon sizes are:
-#16 22 24 32 36 48 64 72 96 128 192 256 512 scalable
+#16 22 24 32 36 48 64 72 96 128 192 256 512 1024 scalable
# -c, --context
#defaults to "apps"
# -t, --theme
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Last rites: media-libs/ilmbase
# Bernd Waibel (2023-01-28) # Possible security issues, obsolete. Use OpenEXR-3 / Imath instead. # No revdeps and consumers left in ::gentoo # Removal in 30 days. Bug #892375 media-libs/ilmbase -BEGIN PGP SIGNATURE- iQGTBAEBCgB9FiEExIg3+Emk70nqAQ2ybb4K1Uo7McYFAmJOvDBfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM0 ODgzN0Y4NDlBNEVGNDlFQTAxMERCMjZEQkUwQUQ1NEEzQjMxQzYACgkQbb4K1Uo7 McbyjggA40un5MrP8DyyVmJXRUTSrxNHbCFck/7vCRHuHfync2bCFYk3JqvfFcu3 D5ms7sH+3ZBxGgUtCG7LwWOQZ89pSkQFXPCu+4Pb0LlVgz6x+lFyGNXdT1g4RyXu 1TzqQlok5gOmlxJ+aK+C6CmzN7e+0Mfe8lGHVLfcukzjlCglochavIXuiG7KNiTB 4rUSeVLJ6OaLkeqYQ4EYrhU8gkiA8nsH4TqXWxmB6cFhfy0e1wOGlkK31Q9jmmZp R4qpRF2QwH7CAKlIW9TT8fZ0kw06UVoGosm8lxMA2wQ2WycTnPp7kbRaTvdENEqb UggCF7hh2g7Y6LSh33f2l6TNlxH0tA== =G4KG -END PGP SIGNATURE-
[gentoo-dev] Last rites: dev-ruby/ruby_gntp
# Hans de Graaff (2023-01-28) # No upstream releases since 2010. No longer maintained # upstream. ruby27-only package. Masked for removal on 2023-02-27. dev-ruby/ruby_gntp signature.asc Description: This is a digitally signed message part
