[gentoo-dev] Package up for grabs: dev-python/mpi4py
Hi, The following package is looking for a new maintainer: dev-python/mpi4py The package is pretty specialistic, and would use a dedicated maintainer who knows MPI. Its only revdeps are sci-*/ packages. It has two bugs open, one of them a test failure. It is pending a version bump. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port
Hi Yixun, On 2021/8/12 17:55, Yixun Lan wrote: > HI Xuerui: > > This must be a *HUGE* project and gonna put lots of effort in to it! > So, first, good luck to you with all my best wishes!~ Thanks for your kindness! > > On 00:39 Thu 12 Aug , WANG Xuerui wrote: >> Hi everyone, >> >> I'm your average Gentoo user who obviously thought his sleeping time is more >> than enough, and just decided to start porting Gentoo to LoongArch. As this >> is such a niche architecture with no upstreamed support so far, I'm posting >> this to announce my intent and gather advice on how to best push this. >> >> I'll first give some background material to help people gain context, then >> describe my porting plan. This is going to be a bit long; apologizes for >> that. >> >> >> Note: I'm not affiliated with Loongson in any way; I'm just doing this in my >> spare time (once meant for some quality sleep). >> >> >> ## A bit of introduction on the LoongArch >> >> LoongArch, as its name implies, is the brand-new ISA developed by the >> Loongson Corporation, incompatible with MIPS which was implemented by >> all previous Loongson processors. Currently only the base ISA specification >> is publicly available; it has fixed-length 32-bit instructions, vastly more >> instruction formats (39 distinct formats in the base ISA alone!), and its >> instruction semantics mostly resemble RISC-V, with a bit of MIPS R6 here and >> there. It is capable of 64-bit operations, obviously. >> >> ISA documentation: https://github.com/loongson/LoongArch-Documentation >> ELF psABI draft: https://github.com/loongson/LoongArch-Documentation/pull/3 >> >> The draft ABI is undergoing fierce review, and is subject to change, >> especially the relocation types. Other parts like the register >> convention and >> data layout is unlikely to change much, though. >> >> There is little code upstreamed for basic software (GNU toolchain, QEMU, >> Linux and the like), but many are open-sourced already. Nevertheless, the >> code quality is still very much inferior, and much of it is obviously based >> on respective MIPS support. There is continuous debate inside and outside >> Loongson on this matter, too. >> > Didn't do any investigation, but if I read correctly, also see here [1] > > The fundamental pieces of softwares are open-sourced but *NOT* yet upstreamed > So, I'd say, let's wait till it's actually accepted by upstream, > before pushing to downsteam (Gentoo here). Sure, you're free to send > a pull-request for review/comment, but collect peices under your own overlay > would be a good idea ( in my humble opition ). Sure; that's basic etiquette. However there are some parts that definitely need upstreaming, otherwise complexity could explode; for example, the multilib_env function and tc-ninja_magic_to_arch function. Without fixing multilib_env we could only use the "default" ABI, and without adapting tc-ninja_magic_to_arch even linux-headers is unable to build. If we don't touch the upstream repo, a full fork is needed, and that's going to be painful. Additionally, I've already seen adaptations for experimental arches in repo; so I thought upstreaming these minimal bits would be acceptable. If that's deemed too early (and I totally understand the reasoning behind that), doing work in forks is okay from my side.
Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs
On Thu, 2021-08-12 at 13:17 -0700, Matt Turner wrote: > On Thu, Aug 12, 2021 at 5:53 AM Michał Górny wrote: > > > > Hello, everyone. > > > > TL;DR: I'd like to propose that stabilizations are done via blockers of > > security bugs instead of security bugs themselves, i.e. as any other > > stabilizations. > > > > > > Right now we're often performing security-related stabilizations via > > security bugs. This has a few problems, that are: > > > > 1. Stabilization-related activity causes unnecessary mail to the widely > > subscribed security alias. That is, subscribed people get notified of > > package list changes, NATTkA results, every arch doing its work. > > However, in reality the security team only cares about stabilization > > being started, stalled or finished -- and for that, getting the usual > > 'dependent bug added/closed' mail should be sufficient. > > > > 2. NATTkA has no good way of distinguishing irrelevant security bugs > > from security bugs where something went wrong (and NATTkA doesn't use > > persistent state by design). The most important problem is that -- > > unlike regular stablereqs -- security bugs aren't supposed to be closed > > after stabilization. It can't really distinguish a security bug 'left > > open' from a security bug with incorrect package list. > > > > 3. Proxied maintainers without editbugs can't actually CC arches on > > security bugs since the bugs are assigned to security@. > > > > > > To resolve these problems going forward and establish consistent > > behavior in the future, I'd like to propose to disable 'package list' > > fields on security bugs and instead expect regular stabilization bugs to > > be used (and made block the security bugs) for stabilizations. While I > > understand that filing additional bugs might be cumbersome for some > > people, I don't think it's such a herculean effort to outweigh > > the problems solved. > > > > In the end, consistency is a good thing and we've introduced a dedicated > > stabilization category to reduce the spread of stabilization bugs all > > around the place. > > I love this. > > It sounds (from IRC) like you're on board with the idea of having > nattka add kw:security to appropriate stabilization bugs. > > Could nattka also do something to the security@-assigned but itself to > indicate that all security-supported architecture have been handled? > Something like leaving a comment or fiddling with the security > whiteboard. Yeah, this shouldn't be a problem. However, I would prefer if 'security supported' architectures were defined somewhere reasonably standard, rather than hardcoded in nattka. > > It would be nice to be able to resolve the security@-assigned but > before non-security-supported architectures are handled. > > To do that, I think we'd want to change what's required for the "clean > up" step. Since today the "clean up" step is dropping the vulnerable > package versions from the tree, it is dependent on > non-security-supported architectures completing the stabilization bug. > I think we'd like to break that dependence. > > I suggest that we redefine the "clean up" step to be: drop > security-supported architectures' keywords from vulnerable versions. > That would allow the security@-assigned bug to be resolved before > non-security-supported architectures are finished with stabilization. > To be honest, this sounds like doubling the effort for little benefit. After all, removing the old version of the package doesn't resolve any problems on the end user systems -- upgrading does, and upgrading usually happens entirely independently of whether we've cleaned up or not. Maybe it'd easier to release GLSAs before cleanup happens? We can always go the dekeywording way if arch teams are actually slacking. -- Best regards, Michał Górny
[gentoo-dev] [PATCH v2 4/4] metadata/install-qa-check.d: add check for missing tmpfiles_process call
From: Georgy Yakovlev
See:
https://archives.gentoo.org/gentoo-dev/message/7bdfdc9a7560fd07436defd0253af0b8
Signed-off-by: Georgy Yakovlev
Signed-off-by: Sam James
---
metadata/install-qa-check.d/60tmpfiles-paths | 34 ++--
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/metadata/install-qa-check.d/60tmpfiles-paths
b/metadata/install-qa-check.d/60tmpfiles-paths
index 81286de584a2..aa666dfb7ce5 100644
--- a/metadata/install-qa-check.d/60tmpfiles-paths
+++ b/metadata/install-qa-check.d/60tmpfiles-paths
@@ -3,11 +3,14 @@
# QA check: ensure that packages installing tmpfiles configuration inherit the
eclass
# Maintainer: Sam James
+# Maintainer: Georgy Yakovlev
# Implements two checks:
# 1) Installation to /etc/tmpfiles.d (which is a user-customization location);
# 2) Installation of any tmpfiles to /usr/lib/tmpfiles.d without inheriting
the eclass
-#(needed for tmpfiles_process in pkg_postinst)
+#(needed for tmpfiles_process in pkg_postinst);
+# 3) Check for installation of tmpfiles without calling tmpfiles_process in
+#pkg_postinst.
tmpfiles_check() {
# Check 1
# Scan image for files in /etc/tmpfiles.d which is a forbidden location
@@ -17,30 +20,41 @@ tmpfiles_check() {
shopt -u nullglob
if [[ ${#files[@]} -gt 0 ]]; then
- eqawarn "QA Notice: files installed to /etc/tmpfiles.d"
- eqawarn "tmpfiles configuration files must be installed by
ebuilds /usr/lib/tmpfiles.d!"
+ eqawarn "QA Notice: files installed to /etc/tmpfiles.d found"
+ eqawarn "tmpfiles configuration files supplied by ebuilds must
be installed to /usr/lib/tmpfiles.d"
fi
# Check 2
# We're now going to check for whether we install files to
/usr/lib/tmpfiles.d without
# inheriting the eclass (weak catch for ebuilds not calling
tmpfiles_process in pkg_postinst)
- # No need to carry on if we're inheriting the eclass
- if has tmpfiles ${INHERITED} ; then
- return
- fi
-
# It's okay for some packages to do this because of circular
dependencies and such
# See:
https://archives.gentoo.org/gentoo-dev/message/0a96793036a4fdd9ac311a46950d7e7b
# TODO: Standardize some way of allowing ebuilds to opt-out of checks
like this
local package=${CATEGORY}/${PN}
+
if [[ ${package} == "sys-apps/systemd" || ${package} == "sys-libs/pam"
]] ; then
return
fi
if [[ -d "${ED}"/usr/lib/tmpfiles.d/ ]] ; then
- eqawarn "QA Notice: package is installing tmpfiles without
inheriting tmpfiles.eclass!"
- eqawarn "Packages must inherit tmpfiles.eclass then call
tmpfiles_process in pkg_postinst."
+ if ! has tmpfiles ${INHERITED} ; then
+ eqawarn "QA Notice: package is installing tmpfiles
without inheriting tmpfiles.eclass!"
+ eqawarn "Packages must inherit tmpfiles.eclass then
call tmpfiles_process in pkg_postinst."
+ return
+ fi
+
+ # Check 3
+ # Check whether we're installing tmpfiles without explicitly
+ # calling tmpfiles_process in pkg_postinst, but we have
inherited
+ # the eclass.
+ # Small risk of false positives if called indirectly.
+ # See:
https://archives.gentoo.org/gentoo-dev/message/7bdfdc9a7560fd07436defd0253af0b8
+ local pkg_postinst_body="$(declare -fp pkg_postinst 2>&1)"
+ if [[ ! ${pkg_postinst_body} == *tmpfiles_process* ]] ; then
+ eqawarn "QA Notice: package is installing tmpfiles
without calling"
+ eqawarn "tmpfiles_process in pkg_postinst phase"
+ fi
fi
}
--
2.32.0
[gentoo-dev] [PATCH v2 3/4] metadata/install-qa-check.d: add exemptions for some packages wrt inherit
Both sys-apps/systemd and sys-libs/pam need to install some files
to these directories without inheriting the eclass.
For future work, we should have a standardised way on opting
out of installed files QA checks, but other QA checks are
already suffering from this issue.
See:
https://archives.gentoo.org/gentoo-dev/message/0a96793036a4fdd9ac311a46950d7e7b
Signed-off-by: Sam James
---
metadata/install-qa-check.d/60tmpfiles-paths | 8
1 file changed, 8 insertions(+)
diff --git a/metadata/install-qa-check.d/60tmpfiles-paths
b/metadata/install-qa-check.d/60tmpfiles-paths
index 5ef56885ebe7..81286de584a2 100644
--- a/metadata/install-qa-check.d/60tmpfiles-paths
+++ b/metadata/install-qa-check.d/60tmpfiles-paths
@@ -30,6 +30,14 @@ tmpfiles_check() {
return
fi
+ # It's okay for some packages to do this because of circular
dependencies and such
+ # See:
https://archives.gentoo.org/gentoo-dev/message/0a96793036a4fdd9ac311a46950d7e7b
+ # TODO: Standardize some way of allowing ebuilds to opt-out of checks
like this
+ local package=${CATEGORY}/${PN}
+ if [[ ${package} == "sys-apps/systemd" || ${package} == "sys-libs/pam"
]] ; then
+ return
+ fi
+
if [[ -d "${ED}"/usr/lib/tmpfiles.d/ ]] ; then
eqawarn "QA Notice: package is installing tmpfiles without
inheriting tmpfiles.eclass!"
eqawarn "Packages must inherit tmpfiles.eclass then call
tmpfiles_process in pkg_postinst."
--
2.32.0
[gentoo-dev] [PATCH v2 2/4] metadata/install-qa-check.d: only trigger on tmpfiles in forbidden location
It's okay to use "keepdir" on /etc/tmpfiles.d.
See:
https://archives.gentoo.org/gentoo-dev/message/50558b55dc34f37b238807fc4759640d
Signed-off-by: Sam James
---
metadata/install-qa-check.d/60tmpfiles-paths | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/metadata/install-qa-check.d/60tmpfiles-paths
b/metadata/install-qa-check.d/60tmpfiles-paths
index ed0bdbff8cd5..5ef56885ebe7 100644
--- a/metadata/install-qa-check.d/60tmpfiles-paths
+++ b/metadata/install-qa-check.d/60tmpfiles-paths
@@ -11,7 +11,12 @@
tmpfiles_check() {
# Check 1
# Scan image for files in /etc/tmpfiles.d which is a forbidden location
- if [[ -d "${ED}"/etc/tmpfiles.d/ ]] ; then
+ # (We use this glob to avoid triggering on keepdir)
+ shopt -s nullglob
+ local files=( "${ED}"/etc/tmpfiles.d/*.conf )
+ shopt -u nullglob
+
+ if [[ ${#files[@]} -gt 0 ]]; then
eqawarn "QA Notice: files installed to /etc/tmpfiles.d"
eqawarn "tmpfiles configuration files must be installed by
ebuilds /usr/lib/tmpfiles.d!"
fi
--
2.32.0
[gentoo-dev] [PATCH v2 1/4] metadata/install-qa-check.d: add 60tmpfiles-path QA check
This adds two tmpfiles related QA checks:
1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which
is a forbidden (user-configuration) location;
2) Check whether packages inherit tmpfiles.eclass if they're
installing files to /usr/lib/tmpfiles.d.
(This helps to catch packages not calling tmpfiles_process
in pkg_postinst).
Signed-off-by: Sam James
---
metadata/install-qa-check.d/60tmpfiles-paths | 37
1 file changed, 37 insertions(+)
create mode 100644 metadata/install-qa-check.d/60tmpfiles-paths
diff --git a/metadata/install-qa-check.d/60tmpfiles-paths
b/metadata/install-qa-check.d/60tmpfiles-paths
new file mode 100644
index ..ed0bdbff8cd5
--- /dev/null
+++ b/metadata/install-qa-check.d/60tmpfiles-paths
@@ -0,0 +1,37 @@
+# Copyright 2021 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# QA check: ensure that packages installing tmpfiles configuration inherit the
eclass
+# Maintainer: Sam James
+
+# Implements two checks:
+# 1) Installation to /etc/tmpfiles.d (which is a user-customization location);
+# 2) Installation of any tmpfiles to /usr/lib/tmpfiles.d without inheriting
the eclass
+#(needed for tmpfiles_process in pkg_postinst)
+tmpfiles_check() {
+ # Check 1
+ # Scan image for files in /etc/tmpfiles.d which is a forbidden location
+ if [[ -d "${ED}"/etc/tmpfiles.d/ ]] ; then
+ eqawarn "QA Notice: files installed to /etc/tmpfiles.d"
+ eqawarn "tmpfiles configuration files must be installed by
ebuilds /usr/lib/tmpfiles.d!"
+ fi
+
+ # Check 2
+ # We're now going to check for whether we install files to
/usr/lib/tmpfiles.d without
+ # inheriting the eclass (weak catch for ebuilds not calling
tmpfiles_process in pkg_postinst)
+
+ # No need to carry on if we're inheriting the eclass
+ if has tmpfiles ${INHERITED} ; then
+ return
+ fi
+
+ if [[ -d "${ED}"/usr/lib/tmpfiles.d/ ]] ; then
+ eqawarn "QA Notice: package is installing tmpfiles without
inheriting tmpfiles.eclass!"
+ eqawarn "Packages must inherit tmpfiles.eclass then call
tmpfiles_process in pkg_postinst."
+ fi
+}
+
+tmpfiles_check
+: # guarantee successful exit
+
+# vim:ft=sh
--
2.32.0
Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs
> On 12 Aug 2021, at 16:17, Agostino Sarubbo wrote: > > On giovedì 12 agosto 2021 14:53:33 CEST Michał Górny wrote: >> To resolve these problems going forward and establish consistent >> behavior in the future, I'd like to propose to disable 'package list' >> fields on security bugs and instead expect regular stabilization bugs to >> be used (and made block the security bugs) for stabilizations. While I >> understand that filing additional bugs might be cumbersome for some >> people, I don't think it's such a herculean effort to outweigh >> the problems solved. > > I think it is a good idea but the stabilization bug that blocks the security > bug should at least have something (bugzilla KEYWORD?) to facilitate the > search of the security stabilization. > Atm we look for bugs with assignee = security@ and cc = arch@ > This is my primary concern and as long as we use e.g. the SECURITY keyword, I'm happy. From #gentoo-dev: [22:34:36] <@sam_> ago: I was wondering if I could just detect by blockers but I think SECURITY blocker is simpler and requires less code/handling overall, so WFM [22:35:25] <@ago> yeah I'm a _little_ bit unsure about the extra work of filing new bugs, but I suspect It's going to be worth it because of less special casing for everybody involved (and not having to explain why security bugs are different to newbies, proxied-maints, ...). best, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH 0/1] remove the legasy musl profiles
> On 12 Aug 2021, at 23:35, William Hubbs wrote: > > I spoke with several people on the #gentoo-hardened channel and no one > knows of any place where these profiles are being used. > > I'll apply this patch early on Aug 16 UTC if no one objects. > I should've thought about this earlier, but ask in #gentoo-releng too to see if they can check spec files for any mention. I'd ping blueness too. > William Hubbs (1): > profiles/hardened: remove the legasy musl profiles s/legasy/legacy/. Could you also do a CI run on GitHub or something to make sure it doesn't break the tree? Simply pushing a branch will work and I can create the pull request. You can run it manually but it's more of a pain: https://github.com/mgorny/repo-mirror-ci/tree/master/gentoo-ci. best, sam signature.asc Description: Message signed with OpenPGP
[gentoo-dev] [PATCH 1/1] profiles/hardened: remove the legasy musl profiles
Signed-off-by: William Hubbs
---
profiles/hardened/linux/musl/eapi | 1 -
profiles/hardened/linux/musl/make.defaults | 5 -
profiles/hardened/linux/musl/mips/eapi | 1 -
profiles/hardened/linux/musl/mips/mipsel/eapi | 1 -
profiles/hardened/linux/musl/mips/mipsel/parent | 2 --
profiles/hardened/linux/musl/mips/parent| 2 --
profiles/hardened/linux/musl/package.use.mask | 6 --
profiles/hardened/linux/musl/use.force | 8
profiles/hardened/linux/musl/use.mask | 17 -
profiles/profiles.desc | 2 --
10 files changed, 45 deletions(-)
delete mode 100644 profiles/hardened/linux/musl/eapi
delete mode 100644 profiles/hardened/linux/musl/make.defaults
delete mode 100644 profiles/hardened/linux/musl/mips/eapi
delete mode 100644 profiles/hardened/linux/musl/mips/mipsel/eapi
delete mode 100644 profiles/hardened/linux/musl/mips/mipsel/parent
delete mode 100644 profiles/hardened/linux/musl/mips/parent
delete mode 100644 profiles/hardened/linux/musl/package.use.mask
delete mode 100644 profiles/hardened/linux/musl/use.force
delete mode 100644 profiles/hardened/linux/musl/use.mask
diff --git a/profiles/hardened/linux/musl/eapi
b/profiles/hardened/linux/musl/eapi
deleted file mode 100644
index 7ed6ff82de6..000
--- a/profiles/hardened/linux/musl/eapi
+++ /dev/null
@@ -1 +0,0 @@
-5
diff --git a/profiles/hardened/linux/musl/make.defaults
b/profiles/hardened/linux/musl/make.defaults
deleted file mode 100644
index 1212f635f54..000
--- a/profiles/hardened/linux/musl/make.defaults
+++ /dev/null
@@ -1,5 +0,0 @@
-# Copyright 1999-2017 Gentoo Foundation.
-# Distributed under the terms of the GNU General Public License v2
-
-USE="${USE} hardened pic -jit -orc"
-BOOTSTRAP_USE="${BOOTSTRAP_USE} hardened pic -jit -orc"
diff --git a/profiles/hardened/linux/musl/mips/eapi
b/profiles/hardened/linux/musl/mips/eapi
deleted file mode 100644
index 7ed6ff82de6..000
--- a/profiles/hardened/linux/musl/mips/eapi
+++ /dev/null
@@ -1 +0,0 @@
-5
diff --git a/profiles/hardened/linux/musl/mips/mipsel/eapi
b/profiles/hardened/linux/musl/mips/mipsel/eapi
deleted file mode 100644
index 7ed6ff82de6..000
--- a/profiles/hardened/linux/musl/mips/mipsel/eapi
+++ /dev/null
@@ -1 +0,0 @@
-5
diff --git a/profiles/hardened/linux/musl/mips/mipsel/parent
b/profiles/hardened/linux/musl/mips/mipsel/parent
deleted file mode 100644
index c3e31b29715..000
--- a/profiles/hardened/linux/musl/mips/mipsel/parent
+++ /dev/null
@@ -1,2 +0,0 @@
-../../../../../default/linux/musl/mips/mipsel
-..
diff --git a/profiles/hardened/linux/musl/mips/parent
b/profiles/hardened/linux/musl/mips/parent
deleted file mode 100644
index 506bb45139d..000
--- a/profiles/hardened/linux/musl/mips/parent
+++ /dev/null
@@ -1,2 +0,0 @@
-../../../../default/linux/musl/mips
-..
diff --git a/profiles/hardened/linux/musl/package.use.mask
b/profiles/hardened/linux/musl/package.use.mask
deleted file mode 100644
index ce38400b406..000
--- a/profiles/hardened/linux/musl/package.use.mask
+++ /dev/null
@@ -1,6 +0,0 @@
-# Copyright 1999-2015 Gentoo Foundation.
-# Distributed under the terms of the GNU General Public License v2
-
-# Matthias Maier (2017-05-11)
-# masked in base, unmask for hardened/musl/
-sys-devel/gcc -pie
diff --git a/profiles/hardened/linux/musl/use.force
b/profiles/hardened/linux/musl/use.force
deleted file mode 100644
index e2d7cf05ec5..000
--- a/profiles/hardened/linux/musl/use.force
+++ /dev/null
@@ -1,8 +0,0 @@
-# Copyright 1999-2013 Gentoo Foundation.
-# Distributed under the terms of the GNU General Public License v2
-
-elibc_musl
-
-# Make sure people don't accidentally turn of ssp/pie in important packages.
-pie
-ssp
diff --git a/profiles/hardened/linux/musl/use.mask
b/profiles/hardened/linux/musl/use.mask
deleted file mode 100644
index b851b043ca0..000
--- a/profiles/hardened/linux/musl/use.mask
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2015 Gentoo Foundation.
-# Distributed under the terms of the GNU General Public License v2
-
--elibc_musl
-elibc_uclibc
-elibc_glibc
-
--hardened
-
-# precompiled headers are not compat with ASLR.
-pch
-
-# prelink is masked for hardened
-prelink
-
-# profile are incompatible when linking with pie
-profile
diff --git a/profiles/profiles.desc b/profiles/profiles.desc
index e7e19692b5d..c02a0d23c6c 100644
--- a/profiles/profiles.desc
+++ b/profiles/profiles.desc
@@ -254,9 +254,7 @@ arm default/linux/arm/17.0/musl/armv7a/hardened
exp
arm64 default/linux/arm64/17.0/musl exp
arm64 default/linux/arm64/17.0/musl/hardened exp
mips default/linux/musl/mips exp
-mips hardened/linux/musl/mipsexp
mips default/linux/musl/mips/mipsel exp
-mip
[gentoo-dev] [PATCH 0/1] remove the legasy musl profiles
I spoke with several people on the #gentoo-hardened channel and no one knows of any place where these profiles are being used. I'll apply this patch early on Aug 16 UTC if no one objects. William Hubbs (1): profiles/hardened: remove the legasy musl profiles profiles/hardened/linux/musl/eapi | 1 - profiles/hardened/linux/musl/make.defaults | 5 - profiles/hardened/linux/musl/mips/eapi | 1 - profiles/hardened/linux/musl/mips/mipsel/eapi | 1 - profiles/hardened/linux/musl/mips/mipsel/parent | 2 -- profiles/hardened/linux/musl/mips/parent| 2 -- profiles/hardened/linux/musl/package.use.mask | 6 -- profiles/hardened/linux/musl/use.force | 8 profiles/hardened/linux/musl/use.mask | 17 - profiles/profiles.desc | 2 -- 10 files changed, 45 deletions(-) delete mode 100644 profiles/hardened/linux/musl/eapi delete mode 100644 profiles/hardened/linux/musl/make.defaults delete mode 100644 profiles/hardened/linux/musl/mips/eapi delete mode 100644 profiles/hardened/linux/musl/mips/mipsel/eapi delete mode 100644 profiles/hardened/linux/musl/mips/mipsel/parent delete mode 100644 profiles/hardened/linux/musl/mips/parent delete mode 100644 profiles/hardened/linux/musl/package.use.mask delete mode 100644 profiles/hardened/linux/musl/use.force delete mode 100644 profiles/hardened/linux/musl/use.mask -- 2.31.1
Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs
On Thu, Aug 12, 2021 at 5:53 AM Michał Górny wrote: > > Hello, everyone. > > TL;DR: I'd like to propose that stabilizations are done via blockers of > security bugs instead of security bugs themselves, i.e. as any other > stabilizations. > > > Right now we're often performing security-related stabilizations via > security bugs. This has a few problems, that are: > > 1. Stabilization-related activity causes unnecessary mail to the widely > subscribed security alias. That is, subscribed people get notified of > package list changes, NATTkA results, every arch doing its work. > However, in reality the security team only cares about stabilization > being started, stalled or finished -- and for that, getting the usual > 'dependent bug added/closed' mail should be sufficient. > > 2. NATTkA has no good way of distinguishing irrelevant security bugs > from security bugs where something went wrong (and NATTkA doesn't use > persistent state by design). The most important problem is that -- > unlike regular stablereqs -- security bugs aren't supposed to be closed > after stabilization. It can't really distinguish a security bug 'left > open' from a security bug with incorrect package list. > > 3. Proxied maintainers without editbugs can't actually CC arches on > security bugs since the bugs are assigned to security@. > > > To resolve these problems going forward and establish consistent > behavior in the future, I'd like to propose to disable 'package list' > fields on security bugs and instead expect regular stabilization bugs to > be used (and made block the security bugs) for stabilizations. While I > understand that filing additional bugs might be cumbersome for some > people, I don't think it's such a herculean effort to outweigh > the problems solved. > > In the end, consistency is a good thing and we've introduced a dedicated > stabilization category to reduce the spread of stabilization bugs all > around the place. I love this. It sounds (from IRC) like you're on board with the idea of having nattka add kw:security to appropriate stabilization bugs. Could nattka also do something to the security@-assigned but itself to indicate that all security-supported architecture have been handled? Something like leaving a comment or fiddling with the security whiteboard. It would be nice to be able to resolve the security@-assigned but before non-security-supported architectures are handled. To do that, I think we'd want to change what's required for the "clean up" step. Since today the "clean up" step is dropping the vulnerable package versions from the tree, it is dependent on non-security-supported architectures completing the stabilization bug. I think we'd like to break that dependence. I suggest that we redefine the "clean up" step to be: drop security-supported architectures' keywords from vulnerable versions. That would allow the security@-assigned bug to be resolved before non-security-supported architectures are finished with stabilization.
Re: [gentoo-dev] [PATCH 2/3] qmail.eclass: remove magic to query root group
On Thu, 2021-08-12 at 17:22 +0200, Rolf Eike Beer wrote: > The default owner is root:root anyway. > This is only true of you don't call insopts earlier with some other value. I see "insopts -o root -g qmail -m 700" in there so you might want to double check.
Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs
On Thu, Aug 12, 2021 at 05:17:36PM +0200, Agostino Sarubbo wrote: > I think it is a good idea but the stabilization bug that blocks the security > bug should at least have something (bugzilla KEYWORD?) to facilitate the > search of the security stabilization. > Atm we look for bugs with assignee = security@ and cc = arch@ We already have a mostly unused kw:SECURITY, maybe it could be given some actual use. But well, these still need people to actually set it. -- ionen signature.asc Description: PGP signature
[gentoo-dev] [PATCH 3/3] qmail.eclass: simplify is_prime()
The previous algorithm would scan for all primes for a given number, which
takes needlessly long.
Signed-off-by: Rolf Eike Beer
---
eclass/qmail.eclass | 51 +++---
eclass/tests/qmail.sh | 52 +++
2 files changed, 70 insertions(+), 33 deletions(-)
create mode 100755 eclass/tests/qmail.sh
diff --git a/eclass/qmail.eclass b/eclass/qmail.eclass
index 40130a502cb..9f644dd74c8 100644
--- a/eclass/qmail.eclass
+++ b/eclass/qmail.eclass
@@ -29,46 +29,31 @@ GENQMAIL_S="${WORKDIR}"/genqmail-${GENQMAIL_PV}
QMAIL_SPP_F=qmail-spp-${QMAIL_SPP_PV}.tar.gz
QMAIL_SPP_S="${WORKDIR}"/qmail-spp-${QMAIL_SPP_PV}
-# @FUNCTION: primes
-# @USAGE:
+# @FUNCTION: is_prime
+# @USAGE:
# @DESCRIPTION:
-# Prints a list of primes between min and max inclusive
-# Note: this functions gets very slow when used with large numbers.
-primes() {
- local min=${1} max=${2}
- local result= primelist=2 i p
+# Checks wether a number is a valid prime number for queue split
+is_prime() {
+ local number=${1} i
+
+ if [[ ${number} -lt 7 ]]; then
+ # too small
+ return 1
+ fi
- [[ ${min} -le 2 ]] && result="${result} 2"
+ if [[ $[number % 2] == 0 ]]; then
+ return 1
+ fi
- for ((i = 3; i <= max; i += 2))
+ # let i run up to the square root of number
+ for ((i = 3; i * i <= number; i += 2))
do
- for p in ${primelist}
- do
- [[ $[i % p] == 0 || $[p * p] -gt ${i} ]] && \
- break
- done
- if [[ $[i % p] != 0 ]]
- then
- primelist="${primelist} ${i}"
- [[ ${i} -ge ${min} ]] && \
- result="${result} ${i}"
+ if [[ $[number % i ] == 0 ]]; then
+ return 1
fi
done
- echo ${result}
-}
-
-# @FUNCTION: is_prima
-# @USAGE:
-# @DESCRIPTION:
-# Checks wether a number is a prime number
-is_prime() {
- local number=${1} i
- for i in $(primes ${number} ${number})
- do
- [[ ${i} == ${number} ]] && return 0
- done
- return 1
+ return 0
}
dospp() {
diff --git a/eclass/tests/qmail.sh b/eclass/tests/qmail.sh
new file mode 100755
index 000..3520ed2a9d5
--- /dev/null
+++ b/eclass/tests/qmail.sh
@@ -0,0 +1,52 @@
+#!/bin/bash
+# Copyright 2020-2021 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+source tests-common.sh
+
+inherit qmail
+
+# some numbers are blocked because they are to small even if prime
+test_low_numbers() {
+ tbegin "low numbers"
+
+ for i in $(seq 0 6); do
+ if is_prime ${i}; then
+ return tend 1 "${i} badly accepted"
+ fi
+ done
+
+ tend 0
+}
+
+# test a given number for being prime
+check_prime_number() {
+ # use factor from coreutils to count the factors
+ if [[ $(factor $1 | cut -d: -f2 | wc -w) == 1 ]]; then
+ return $(is_prime $1)
+ else
+ return $(is_prime $1 && false || true)
+ fi
+}
+
+test_primes() {
+ tbegin "factorizations from ${1} to ${2}"
+
+ for i in $(seq ${1:?} ${2:?}); do
+ if ! check_prime_number $i; then
+ tend 1 "${i} returned bad factorization"
+ return 1
+ fi
+ done
+
+ tend 0
+}
+
+test_low_numbers
+test_primes 7 99
+for i in $(seq 100 100 1000); do
+ test_primes $i $((i + 99))
+done
+
+texit
--
2.26.2
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 3/5] qmail.eclass: simplify is_prime()
Am Donnerstag, 12. August 2021, 13:25:09 CEST schrieb Ulrich Mueller:
> > On Thu, 12 Aug 2021, Rolf Eike Beer wrote:
> > -# @FUNCTION: primes
> > -# @USAGE:
> > +# @FUNCTION: is_prime
> > +# @USAGE:
> >
> > # @DESCRIPTION:
> > -# Prints a list of primes between min and max inclusive
> > -# Note: this functions gets very slow when used with large numbers.
> > -primes() {
> > - local min=${1} max=${2}
> > - local result= primelist=2 i p
> > +# Checks wether a number is a valid prime number for queue split
> > +is_prime() {
> > + local number=${1} i
> > +
> > + if [[ ${number} < 7 ]]; then
> > + # too small
> > + return 0
> > + fi
>
> So e.g. all numbers between 100 and 699 qualify as primes? I doubt that
> this is what was intended. :)
Nope.
> This function asks for a unit test in eclass/tests/.
Indeed, that would uncover that it had to be "return 1" above.
The eclass guide at https://devmanual.gentoo.org/eclass-writing/index.html
doesn't mention these tests with any words, not even how to run them.
Eike
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] [PATCH 2/3] qmail.eclass: remove magic to query root group
The default owner is root:root anyway. This also fixes
qmail_supervise_install_one() when called from outside of qmail_src_install().
Signed-off-by: Rolf Eike Beer
---
eclass/qmail.eclass | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/eclass/qmail.eclass b/eclass/qmail.eclass
index 6b04cbf7792..40130a502cb 100644
--- a/eclass/qmail.eclass
+++ b/eclass/qmail.eclass
@@ -73,7 +73,7 @@ is_prime() {
dospp() {
insinto "${QMAIL_HOME}"/plugins/
- insopts -o root -g "${GROUP_ROOT}" -m 0755
+ insopts -m 0755
newins $1 ${2:-$(basename $1)}
}
@@ -86,8 +86,8 @@ dosupervise() {
local runfile=${2:-${service}} logfile=${3:-${service}-log}
[[ -z "${service}" ]] && die "no service given"
- insopts -o root -g "${GROUP_ROOT}" -m 0755
- diropts -o root -g "${GROUP_ROOT}" -m 0755
+ insopts -m 0755
+ diropts -m 0755
dodir ${SUPERVISE_DIR}/${service}{,/log}
fperms +t ${SUPERVISE_DIR}/${service}{,/log}
@@ -192,12 +192,12 @@ qmail_base_install() {
qmail_config_install() {
einfo "Installing stock configuration files"
insinto "${QMAIL_HOME}"/control
- insopts -o root -g "${GROUP_ROOT}" -m 644
+ insopts -m 644
doins "${GENQMAIL_S}"/control/{conf-*,defaultdelivery}
einfo "Installing configuration sanity checker and launcher"
insinto "${QMAIL_HOME}"/bin
- insopts -o root -g "${GROUP_ROOT}" -m 644
+ insopts -m 644
doins "${GENQMAIL_S}"/control/qmail-config-system
declare -F qmail_config_install_hook >/dev/null && \
@@ -254,9 +254,9 @@ qmail_maildir_install() {
done
einfo "Setting up default maildirs in the account skeleton"
- diropts -o root -g "${GROUP_ROOT}" -m 755
+ diropts -m 755
insinto /etc/skel
- insopts -o root -g "${GROUP_ROOT}" -m 644
+ insopts -m 644
newins "${GENQMAIL_S}"/control/defaultdelivery .qmail.sample
"${MAILDIRMAKE}" "${D}"/etc/skel/.maildir
keepdir /etc/skel/.maildir/{cur,new,tmp}
@@ -268,7 +268,7 @@ qmail_maildir_install() {
qmail_tcprules_install() {
dodir "${TCPRULES_DIR}"
insinto "${TCPRULES_DIR}"
- insopts -o root -g "${GROUP_ROOT}" -m 0644
+ insopts -m 0644
doins "${GENQMAIL_S}"/tcprules/Makefile.qmail
doins "${GENQMAIL_S}"/tcprules/tcp.qmail-*
use ssl && use pop3 || rm -f "${D}${TCPRULES_DIR}"/tcp.qmail-pop3sd
@@ -276,7 +276,7 @@ qmail_tcprules_install() {
qmail_supervise_install_one() {
dosupervise ${1}
- diropts -o qmaill -g "${GROUP_ROOT}" -m 755
+ diropts -o qmaill -g root -m 755
keepdir /var/log/qmail/${1}
}
@@ -301,7 +301,7 @@ qmail_supervise_install() {
qmail_spp_install() {
einfo "Installing qmail-spp configuration files"
insinto "${QMAIL_HOME}"/control/
- insopts -o root -g "${GROUP_ROOT}" -m 0644
+ insopts -m 0644
doins "${GENQMAIL_S}"/spp/smtpplugins
einfo "Installing qmail-spp plugins"
@@ -321,16 +321,16 @@ qmail_ssl_install() {
einfo "Installing SSL Certificate creation script"
insinto "${QMAIL_HOME}"/control
- insopts -o root -g "${GROUP_ROOT}" -m 0644
+ insopts -m 0644
doins "${GENQMAIL_S}"/ssl/servercert.cnf
insinto "${QMAIL_HOME}"/bin
- insopts -o root -g "${GROUP_ROOT}" -m 0755
+ insopts -m 0755
doins "${GENQMAIL_S}"/ssl/mkservercert
einfo "Installing RSA key generation cronjob"
insinto /etc/${CRON_FOLDER}
- insopts -o root -g "${GROUP_ROOT}" -m 0755
+ insopts -m 0755
doins "${GENQMAIL_S}"/ssl/qmail-genrsacert.sh
keepdir "${QMAIL_HOME}"/control/tlshosts
@@ -340,7 +340,6 @@ qmail_ssl_install() {
}
qmail_src_install() {
- export GROUP_ROOT="$(id -gn root)"
qmail_base_install
qmail_config_install
qmail_man_install
--
2.26.2
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs
On giovedì 12 agosto 2021 14:53:33 CEST Michał Górny wrote: > To resolve these problems going forward and establish consistent > behavior in the future, I'd like to propose to disable 'package list' > fields on security bugs and instead expect regular stabilization bugs to > be used (and made block the security bugs) for stabilizations. While I > understand that filing additional bugs might be cumbersome for some > people, I don't think it's such a herculean effort to outweigh > the problems solved. I think it is a good idea but the stabilization bug that blocks the security bug should at least have something (bugzilla KEYWORD?) to facilitate the search of the security stabilization. Atm we look for bugs with assignee = security@ and cc = arch@ Agostino
[gentoo-dev] Re: [RFC] Decoupling stabilization from security bugs
On Thu, Aug 12, 2021 at 02:53:33PM +0200, Michał Górny wrote: > Hello, everyone. > > TL;DR: I'd like to propose that stabilizations are done via blockers of > security bugs instead of security bugs themselves, i.e. as any other > stabilizations. > > > Right now we're often performing security-related stabilizations via > security bugs. This has a few problems, that are: > > WDYT? I welcome this change. Let's do it. -Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs
The benefits definitely seem to outweigh the added work here, sounds good to me! signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 2/3] qmail.eclass: hardcode root group
Am Donnerstag, 12. August 2021, 13:13:23 CEST schrieb Ulrich Mueller:
> > On Thu, 12 Aug 2021, Rolf Eike Beer wrote:
> > dospp() {
> >
> > insinto "${QMAIL_HOME}"/plugins/
> >
> > - insopts -o root -g "${GROUP_ROOT}" -m 0755
> > + insopts -o root -g root -m 0755
>
> install defaults to root anyway, so why are explicit -o and -g needed
> here? (Same applies below, of course.)
I suspected that, but at the end I was just following bad examples:
git grep 'insopts\s\+.*-[og]\s\+root'
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] [RFC] Decoupling stabilization from security bugs
Hello, everyone. TL;DR: I'd like to propose that stabilizations are done via blockers of security bugs instead of security bugs themselves, i.e. as any other stabilizations. Right now we're often performing security-related stabilizations via security bugs. This has a few problems, that are: 1. Stabilization-related activity causes unnecessary mail to the widely subscribed security alias. That is, subscribed people get notified of package list changes, NATTkA results, every arch doing its work. However, in reality the security team only cares about stabilization being started, stalled or finished -- and for that, getting the usual 'dependent bug added/closed' mail should be sufficient. 2. NATTkA has no good way of distinguishing irrelevant security bugs from security bugs where something went wrong (and NATTkA doesn't use persistent state by design). The most important problem is that -- unlike regular stablereqs -- security bugs aren't supposed to be closed after stabilization. It can't really distinguish a security bug 'left open' from a security bug with incorrect package list. 3. Proxied maintainers without editbugs can't actually CC arches on security bugs since the bugs are assigned to security@. To resolve these problems going forward and establish consistent behavior in the future, I'd like to propose to disable 'package list' fields on security bugs and instead expect regular stabilization bugs to be used (and made block the security bugs) for stabilizations. While I understand that filing additional bugs might be cumbersome for some people, I don't think it's such a herculean effort to outweigh the problems solved. In the end, consistency is a good thing and we've introduced a dedicated stabilization category to reduce the spread of stabilization bugs all around the place. WDYT? -- Best regards, Michał Górny
[gentoo-dev] Lastrite app-crypt/WiRouterKeyRec
# Agostino Sarubbo (2021-08-12) # Latest release 2012, not anymore useful for current routers # Removal in ~30 days. app-crypt/WiRouterKeyRec Agostino
Re: [gentoo-dev] [PATCH 3/5] qmail.eclass: simplify is_prime()
> On Thu, 12 Aug 2021, Rolf Eike Beer wrote:
> -# @FUNCTION: primes
> -# @USAGE:
> +# @FUNCTION: is_prime
> +# @USAGE:
> # @DESCRIPTION:
> -# Prints a list of primes between min and max inclusive
> -# Note: this functions gets very slow when used with large numbers.
> -primes() {
> - local min=${1} max=${2}
> - local result= primelist=2 i p
> +# Checks wether a number is a valid prime number for queue split
> +is_prime() {
> + local number=${1} i
> +
> + if [[ ${number} < 7 ]]; then
> + # too small
> + return 0
> + fi
So e.g. all numbers between 100 and 699 qualify as primes? I doubt that
this is what was intended. :)
>
> - [[ ${min} -le 2 ]] && result="${result} 2"
> + if [[ $[number % 2] == 0 ]]; then
> + return 1
> + fi
>
> - for ((i = 3; i <= max; i += 2))
> + # let i run up to the square root of number
> + for ((i = 3; i * i <= number; i += 2))
> do
> - for p in ${primelist}
> - do
> - [[ $[i % p] == 0 || $[p * p] -gt ${i} ]] && \
> - break
> - done
> - if [[ $[i % p] != 0 ]]
> - then
> - primelist="${primelist} ${i}"
> - [[ ${i} -ge ${min} ]] && \
> - result="${result} ${i}"
> + if [[ $[number % i ] == 0 ]]; then
> + return 1
> fi
> done
>
> - echo ${result}
> -}
This function asks for a unit test in eclass/tests/.
Ulrich
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH 3/3] chromium-2.eclass: enable EAPI 8
> On Wed, 11 Aug 2021, Stephan Hartmann wrote:
> case ${EAPI} in
> - 7) ;;
> + 7|8) ;;
> *) die "EAPI=${EAPI:-0} is not supported" ;;
Nitpick: Add "${ECLASS}: " at the beginning of the die message.
> esac
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH 2/3] qmail.eclass: hardcode root group
> On Thu, 12 Aug 2021, Rolf Eike Beer wrote:
> dospp() {
> insinto "${QMAIL_HOME}"/plugins/
> - insopts -o root -g "${GROUP_ROOT}" -m 0755
> + insopts -o root -g root -m 0755
install defaults to root anyway, so why are explicit -o and -g needed
here? (Same applies below, of course.)
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH v2] python-utils-r1.eclass: Handle deselect/ignore in epytest
Support (potentially global-scope) EPYTEST_DESELECT and EPYTEST_IGNORE
arrays to conveniently deselect/skip tests. This effectively replaces
local hacks such as:
epytest ${deselect[@]/#/--deselect }
Signed-off-by: Michał Górny
---
eclass/python-utils-r1.eclass | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index b104b6694ac3..356ace6a6851 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1244,11 +1244,30 @@ build_sphinx() {
HTML_DOCS+=( "${dir}/_build/html/." )
}
+# @VARIABLE: EPYTEST_DESELECT
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Specifies an array of tests to be deselected via pytest's --deselect
+# parameter, when calling epytest. The list can include file paths,
+# specific test functions or parametrized test invocations.
+#
+# Note that the listed files will still be subject to collection,
+# i.e. modules imported in global scope will need to be available.
+# If this is undesirable, EPYTEST_IGNORE can be used instead.
+
+# @VARIABLE: EPYTEST_IGNORE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Specifies an array of paths to be ignored via pytest's --ignore
+# parameter, when calling epytest. The listed files will be entirely
+# skipped from test collection.
+
# @FUNCTION: epytest
# @USAGE: [...]
# @DESCRIPTION:
-# Run pytest, passing the standard set of pytest options, followed
-# by user-specified options.
+# Run pytest, passing the standard set of pytest options, then
+# --deselect and --ignore options based on EPYTEST_DESELECT
+# and EPYTEST_IGNORE, then user-specified options.
#
# This command dies on failure and respects nonfatal.
epytest() {
@@ -1268,6 +1287,13 @@ epytest() {
# for end users, as it tends to fail on new warnings from deps
-Wdefault
)
+ local x
+ for x in "${EPYTEST_DESELECT[@]}"; do
+ args+=( --deselect "${x}" )
+ done
+ for x in "${EPYTEST_IGNORE[@]}"; do
+ args+=( --ignore "${x}" )
+ done
set -- "${EPYTHON}" -m pytest "${args[@]}" "${@}"
echo "${@}" >&2
--
2.32.0
Re: [gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port
HI Xuerui: This must be a *HUGE* project and gonna put lots of effort in to it! So, first, good luck to you with all my best wishes!~ On 00:39 Thu 12 Aug , WANG Xuerui wrote: > Hi everyone, > > I'm your average Gentoo user who obviously thought his sleeping time is more > than enough, and just decided to start porting Gentoo to LoongArch. As this > is such a niche architecture with no upstreamed support so far, I'm posting > this to announce my intent and gather advice on how to best push this. > > I'll first give some background material to help people gain context, then > describe my porting plan. This is going to be a bit long; apologizes for > that. > > > Note: I'm not affiliated with Loongson in any way; I'm just doing this in my > spare time (once meant for some quality sleep). > > > ## A bit of introduction on the LoongArch > > LoongArch, as its name implies, is the brand-new ISA developed by the > Loongson Corporation, incompatible with MIPS which was implemented by > all previous Loongson processors. Currently only the base ISA specification > is publicly available; it has fixed-length 32-bit instructions, vastly more > instruction formats (39 distinct formats in the base ISA alone!), and its > instruction semantics mostly resemble RISC-V, with a bit of MIPS R6 here and > there. It is capable of 64-bit operations, obviously. > > ISA documentation: https://github.com/loongson/LoongArch-Documentation > ELF psABI draft: https://github.com/loongson/LoongArch-Documentation/pull/3 > > The draft ABI is undergoing fierce review, and is subject to change, > especially the relocation types. Other parts like the register > convention and > data layout is unlikely to change much, though. > > There is little code upstreamed for basic software (GNU toolchain, QEMU, > Linux and the like), but many are open-sourced already. Nevertheless, the > code quality is still very much inferior, and much of it is obviously based > on respective MIPS support. There is continuous debate inside and outside > Loongson on this matter, too. > Didn't do any investigation, but if I read correctly, also see here [1] The fundamental pieces of softwares are open-sourced but *NOT* yet upstreamed So, I'd say, let's wait till it's actually accepted by upstream, before pushing to downsteam (Gentoo here). Sure, you're free to send a pull-request for review/comment, but collect peices under your own overlay would be a good idea ( in my humble opition ). > Kernel ABI and glibc code seems to be inspired by RISC-V, but still some > parts show MIPS heritage. The kernel bits are being reviewed on the > linux-arch > mailing list. > > All of the projects above can be accessed at https://github.com/loongson. > > Loongson 3A5000 is the first LoongArch CPU; the Lemote A2101 board with this > CPU can be bought in China for ~4000 CNY already. > > > ## Gentoo porting plans > > I'm planning to take ARCH=loongarch for the port; and support the LP64 ABI > first. I'd like to support both LP64 and ILP32 ABIs, but that's not a > priority. > start with LP64 would be good idea, so same as RISC-V here. > The ABI flag might be named "ABI_LOONGARCH" but that's IMO a bit long (pun > semi-intended); ARCH=loong and ABI_LOONG might be better, I'm open to > suggestions. > > Because much of the ABI and even some toolchain internals are going through > VERY fierce debate and rework, obviously the port will remain experimental > for a long time. Some minimal support should get in tree though; doing so > would ease a lot of pain for experimentation. I already hacked my way to > generate working crossdev toolchains, and is halfway towards a rootfs with > working Python (and Portage). I've already independently ported strace, and > plan to do the same to libffi in the coming days which would give me Python. > > I'll do all work in my own loongson-overlay first, and upstream these when > appropriate. Eventually I hope to have working crossdev, qemu-user emulation > and proper catalyst support. > > sounds a good plan, first start with making cross compiling work, then try to populate a mini rootfs (kernel, glibc, base system), then python, portage > And that's about all; the message is getting long! Your opinions are > welcome, > and thanks again for following along. > > [1] https://github.com/gentoo/portage/pull/740#issuecomment-895021854 -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
[gentoo-dev] [PATCH 3/5] qmail.eclass: simplify is_prime()
The previous algorithm would scan for all primes for a given number, which
takes needlessly long.
Signed-off-by: Rolf Eike Beer
---
eclass/qmail.eclass | 51 -
1 file changed, 18 insertions(+), 33 deletions(-)
diff --git a/eclass/qmail.eclass b/eclass/qmail.eclass
index 6ed026a1d9d..6ea27249c63 100644
--- a/eclass/qmail.eclass
+++ b/eclass/qmail.eclass
@@ -29,46 +29,31 @@ GENQMAIL_S="${WORKDIR}"/genqmail-${GENQMAIL_PV}
QMAIL_SPP_F=qmail-spp-${QMAIL_SPP_PV}.tar.gz
QMAIL_SPP_S="${WORKDIR}"/qmail-spp-${QMAIL_SPP_PV}
-# @FUNCTION: primes
-# @USAGE:
+# @FUNCTION: is_prime
+# @USAGE:
# @DESCRIPTION:
-# Prints a list of primes between min and max inclusive
-# Note: this functions gets very slow when used with large numbers.
-primes() {
- local min=${1} max=${2}
- local result= primelist=2 i p
+# Checks wether a number is a valid prime number for queue split
+is_prime() {
+ local number=${1} i
+
+ if [[ ${number} < 7 ]]; then
+ # too small
+ return 0
+ fi
- [[ ${min} -le 2 ]] && result="${result} 2"
+ if [[ $[number % 2] == 0 ]]; then
+ return 1
+ fi
- for ((i = 3; i <= max; i += 2))
+ # let i run up to the square root of number
+ for ((i = 3; i * i <= number; i += 2))
do
- for p in ${primelist}
- do
- [[ $[i % p] == 0 || $[p * p] -gt ${i} ]] && \
- break
- done
- if [[ $[i % p] != 0 ]]
- then
- primelist="${primelist} ${i}"
- [[ ${i} -ge ${min} ]] && \
- result="${result} ${i}"
+ if [[ $[number % i ] == 0 ]]; then
+ return 1
fi
done
- echo ${result}
-}
-
-# @FUNCTION: is_prima
-# @USAGE:
-# @DESCRIPTION:
-# Checks wether a number is a prime number
-is_prime() {
- local number=${1} i
- for i in $(primes ${number} ${number})
- do
- [[ ${i} == ${number} ]] && return 0
- done
- return 1
+ return 0
}
dospp() {
--
2.26.2
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] [PATCH 2/3] qmail.eclass: hardcode root group
This also fixes qmail_supervise_install_one when called from outside of
qmail_src_install.
Signed-off-by: Rolf Eike Beer
---
eclass/qmail.eclass | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/eclass/qmail.eclass b/eclass/qmail.eclass
index 6b04cbf7792..6ed026a1d9d 100644
--- a/eclass/qmail.eclass
+++ b/eclass/qmail.eclass
@@ -73,7 +73,7 @@ is_prime() {
dospp() {
insinto "${QMAIL_HOME}"/plugins/
- insopts -o root -g "${GROUP_ROOT}" -m 0755
+ insopts -o root -g root -m 0755
newins $1 ${2:-$(basename $1)}
}
@@ -86,8 +86,8 @@ dosupervise() {
local runfile=${2:-${service}} logfile=${3:-${service}-log}
[[ -z "${service}" ]] && die "no service given"
- insopts -o root -g "${GROUP_ROOT}" -m 0755
- diropts -o root -g "${GROUP_ROOT}" -m 0755
+ insopts -o root -g root -m 0755
+ diropts -o root -g root -m 0755
dodir ${SUPERVISE_DIR}/${service}{,/log}
fperms +t ${SUPERVISE_DIR}/${service}{,/log}
@@ -192,12 +192,12 @@ qmail_base_install() {
qmail_config_install() {
einfo "Installing stock configuration files"
insinto "${QMAIL_HOME}"/control
- insopts -o root -g "${GROUP_ROOT}" -m 644
+ insopts -o root -g root -m 644
doins "${GENQMAIL_S}"/control/{conf-*,defaultdelivery}
einfo "Installing configuration sanity checker and launcher"
insinto "${QMAIL_HOME}"/bin
- insopts -o root -g "${GROUP_ROOT}" -m 644
+ insopts -o root -g root -m 644
doins "${GENQMAIL_S}"/control/qmail-config-system
declare -F qmail_config_install_hook >/dev/null && \
@@ -254,9 +254,9 @@ qmail_maildir_install() {
done
einfo "Setting up default maildirs in the account skeleton"
- diropts -o root -g "${GROUP_ROOT}" -m 755
+ diropts -o root -g root -m 755
insinto /etc/skel
- insopts -o root -g "${GROUP_ROOT}" -m 644
+ insopts -o root -g root -m 644
newins "${GENQMAIL_S}"/control/defaultdelivery .qmail.sample
"${MAILDIRMAKE}" "${D}"/etc/skel/.maildir
keepdir /etc/skel/.maildir/{cur,new,tmp}
@@ -268,7 +268,7 @@ qmail_maildir_install() {
qmail_tcprules_install() {
dodir "${TCPRULES_DIR}"
insinto "${TCPRULES_DIR}"
- insopts -o root -g "${GROUP_ROOT}" -m 0644
+ insopts -o root -g root -m 0644
doins "${GENQMAIL_S}"/tcprules/Makefile.qmail
doins "${GENQMAIL_S}"/tcprules/tcp.qmail-*
use ssl && use pop3 || rm -f "${D}${TCPRULES_DIR}"/tcp.qmail-pop3sd
@@ -276,7 +276,7 @@ qmail_tcprules_install() {
qmail_supervise_install_one() {
dosupervise ${1}
- diropts -o qmaill -g "${GROUP_ROOT}" -m 755
+ diropts -o qmaill -g root -m 755
keepdir /var/log/qmail/${1}
}
@@ -301,7 +301,7 @@ qmail_supervise_install() {
qmail_spp_install() {
einfo "Installing qmail-spp configuration files"
insinto "${QMAIL_HOME}"/control/
- insopts -o root -g "${GROUP_ROOT}" -m 0644
+ insopts -o root -g root -m 0644
doins "${GENQMAIL_S}"/spp/smtpplugins
einfo "Installing qmail-spp plugins"
@@ -321,16 +321,16 @@ qmail_ssl_install() {
einfo "Installing SSL Certificate creation script"
insinto "${QMAIL_HOME}"/control
- insopts -o root -g "${GROUP_ROOT}" -m 0644
+ insopts -o root -g root -m 0644
doins "${GENQMAIL_S}"/ssl/servercert.cnf
insinto "${QMAIL_HOME}"/bin
- insopts -o root -g "${GROUP_ROOT}" -m 0755
+ insopts -o root -g root -m 0755
doins "${GENQMAIL_S}"/ssl/mkservercert
einfo "Installing RSA key generation cronjob"
insinto /etc/${CRON_FOLDER}
- insopts -o root -g "${GROUP_ROOT}" -m 0755
+ insopts -o root -g root -m 0755
doins "${GENQMAIL_S}"/ssl/qmail-genrsacert.sh
keepdir "${QMAIL_HOME}"/control/tlshosts
@@ -340,7 +340,6 @@ qmail_ssl_install() {
}
qmail_src_install() {
- export GROUP_ROOT="$(id -gn root)"
qmail_base_install
qmail_config_install
qmail_man_install
--
2.26.2
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] [PATCH 1/3] qmail.eclass: support EAPI 8
Signed-off-by: Rolf Eike Beer
---
eclass/qmail.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/qmail.eclass b/eclass/qmail.eclass
index 76c612f026f..6b04cbf7792 100644
--- a/eclass/qmail.eclass
+++ b/eclass/qmail.eclass
@@ -4,11 +4,11 @@
# @ECLASS: qmail.eclass
# @MAINTAINER:
# Rolf Eike Beer
-# @SUPPORTED_EAPIS: 6 7
+# @SUPPORTED_EAPIS: 7 8
# @BLURB: common qmail functions
case ${EAPI:-0} in
- [67]) ;;
+ [78]) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
--
2.26.2
signature.asc
Description: This is a digitally signed message part.
