Re: [gentoo-dev] Packages up for grabs
> media-sound/apulse I'm using this one, can take.
Re: [gentoo-dev] [RFC] Gentoo Asahi Project
28.12.2023 18:49, Mart Raudsepp пишет: > Hello! > > I have created the Gentoo Asahi Project to organize the enablement of > Apple Silicon Mac machines in Gentoo via the main ::gentoo tree as much > as possible. > New approaches for the install process are also going to be a topic. > > Wiki page: https://wiki.gentoo.org/wiki/Project:Asahi > > > > Mart > Hi! Gentoo already can be installed there using Prefix. Does this project instead replace macOS on the machine completely?
Re: [gentoo-dev] Update on 23.0 profiles
30.11.2023 12:27, Andreas K. Huettel пишет: >> 1. The [4]/[5] probably should list full domain name rather than g.o > Yes, but the wiki does not allow full links into itself. Will be fixed > in the final news item. > >> 2. According to 23.0_update_table, my non-systemd >> default/linux/amd64/17.1/desktop/plasma should now be >> default/linux/amd64/23.0/split-usr/desktop/plasma. > Correct. > >> But that name looks >> like merged-usr is now considered "better" than split-usr, as it has to >> be specifically mentioned in the profile name. > I'd prefer "more standard", "more common", "more usual" ... > > It'll definitely soon be the configuration where software is (globally) > more tested, independent of what Gentoo does. (if that is not already the > case now...) > >> Therefore I probably should migrate to merged-usr. > You can migrate after the profile upgrade, but you don't have to. > No hurry. > >> But the only instruction how to do that >> assumes systemd. > https://wiki.gentoo.org/wiki/Merge-usr Thanks, I was only following links in the news item. > Doesn't mention systemd anywhere. I'll update this page a bit > mentioning the new naming scheme in 23.0, and link it in the news item. It kinda does. Because there's no non-systemd merged-usr plasma profile in 17. Only in 23. So, I cannot migrate to merged-usr before switch to 23. Perhaps mention in the news item (or in the profiles table) that "after migrating to 23 profile you gain an option to migrate to merged-usr if you wish"? > >> And there's no plasma profile with merged-usr but >> without systemd anyway... except that there is: >> default/linux/amd64/23.0/desktop/plasma, it's just not mentioned in the >> table. > It's fairly simple: > * In 17.x, every systemd split-usr profile has a corresponding merged-usr > profile > * In 23.0, every split-usr profile has a corresponding merged-usr profile > > Cheers -a > > > -- > PD Dr. Andreas K. Huettel > Institute for Experimental and Applied Physics > University of Regensburg > 93040 Regensburg > Germany > > tel. +49 151 241 67748 (mobile) > tel. +49 941 943 1618 (office) > e-mail andreas.huet...@ur.de > https://www.akhuettel.de/ > https://www.akhuettel.de/group/ > >
Re: [gentoo-dev] Update on 23.0 profiles
25.11.2023 23:27, Andreas K. Huettel пишет: > Hi all, > > here's a brief update on the upcoming 23.0 profiles. > > * All planned features are implemented (but not necessarily tested). >https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_profile_transition > > * A draft upgrade document exists. >https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions > > Unless something important comes up over the next 7 days (and I mean you, > worthy mailing list readers :), I consider the feature set now frozen. > > Which means, in a week we can start testing this in earnest. The > next step will be to create "exp" profile entries, migrate seeds, and > start up stage builds on all arches (in parallel to the existing builds > and for now not linked on the webpages yet). > > Cheers, > Andreas > 1. The [4]/[5] probably should list full domain name rather than g.o 2. According to 23.0_update_table, my non-systemd default/linux/amd64/17.1/desktop/plasma should now be default/linux/amd64/23.0/split-usr/desktop/plasma. But that name looks like merged-usr is now considered "better" than split-usr, as it has to be specifically mentioned in the profile name. Therefore I probably should migrate to merged-usr. But the only instruction how to do that assumes systemd. And there's no plasma profile with merged-usr but without systemd anyway... except that there is: default/linux/amd64/23.0/desktop/plasma, it's just not mentioned in the table.
Re: [gentoo-dev] last rites: sys-fs/eudev
15.09.2023 16:10, orbea пишет:
On Fri, 15 Sep 2023 01:19:22 +0200
Arsen Arsenović wrote:
"Eddie Chapman" writes:
Not aiming this at you personally but this argument has been made
more than once in this thread and I personally don't think it
carries any weight, because it can be levelled at anyone who raises
an issue about anything. If you don't like it, then just go and
roll your own.
::gentoo is supposed to be a coherent set of packages provided by
Gentoo developers, with a reasonable scope. eudev no longer fits
into the 'coherent' part of that definition, and there are zero
advantages to it over systemd-utils[udev].
The _only_ difference between a sys-fs/eudev::eudev and
sys-fs/eudev::gentoo package that would exist if the former were to be
made into an overlay is that Gentoo developers would be responsible
for the latter. There are no Gentoo developers interested in being
responsible for the latter (AFAIK), and there is no tangible benefit
to the latter for any Gentoo developer to latch onto.
Seeing as there is at least half a dozen people seemingly interested
in maintaining eudev, why not just form an overlay? This way,
virtual/{,lib}udev doesn't get polluted with implementations which
don't fullfil the definition of a virtual provider in ::gentoo, nor
with use-flag hacks, but users which wish to use eudev still have
access to it, and upstream eudev gets half a dozen potential
contributors, which are needed, _badly_. At risk of repeating
myself, I'd like to point out again that the only viable approach for
eudev upstream to take is to re-fork systemd and find a viable way to
stay up-to-date, while fixing up incompatibilities with musl. I've
made proposals a few years ago and restated them in this thread.
What incompatibilities with musl? I am using musl-1.2.4 with eudev and
there do not seem to be any issues in that regard.
I also don't see any musl specific issues reported upstream or for
Gentoo. Am I missing something?
Arsen meant incompatibilities of systemd-udev, not of eudev [1]. No idea
what's the current state of udev upstream is though. Alpine uses musl,
that's one of reasons why they are interested in eudev.
[1] See
https://gitweb.gentoo.org/proj/eudev.git/commit/?id=f559dc96f4105f605272defac9276ef9cb6f5dc6
Of course I know I (and anyone else) can do that. So then what's the
point of discussing anything then?
Just because an argument is widely applicable does not make it
invalid.
Note that this argument is seldom the first resort, since, as you
note, it's not overly productive. Indeed, it was not the first
resort here. sys-fs/eudev has long overstayed the original removal
plan.
What's the point of having a big tree with hundreds of packages? Why
not have a very minimal tree instead and let everyone go and run
multiple independent repos so we can all do what we want? Then we
wouldn't have any discussion about what to include and what not. In
fact maybe that's not a bad idea.
I'm not sure how to fit this within the context of the thread.
Have a lovely evening.
--
Best regards,
Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
13.09.2023 03:52, Eli Schwartz пишет:
On 9/12/23 10:26 PM, Michał Górny wrote:
On Tue, 2023-09-12 at 22:07 -0400, Eli Schwartz wrote:
On 9/12/23 3:56 PM, Ulrich Mueller wrote:
On Tue, 12 Sep 2023, Eli Schwartz wrote:
+ mkdir -p "${BUILD_DIR}" || die
+ local -x
DIST_EXTRA_CONFIG="${BUILD_DIR}/extra-setup.cfg"
+ cat > "${DIST_EXTRA_CONFIG}" <<-EOF
+ [build]
+ build_base = ${BUILD_DIR}/build
+
+ [build_ext]
+ parallel = ${jobs}
+ EOF
"|| die" should also be added for the cat command.
Redirecting output to a file in a directory you have just guaranteed to
exist cannot fail.
Eh, you make me prove you wrong:
# cat > dupa <<-EOF
blahblah
EOF
cat: write error: No space left on device
ಠ_ಠ
Is portage generally expected to successfully complete (including
internal metadata write stages) when its workdir drive runs out of space
partway through?
This is a race with the user - the user could delete some files from
disk just in time for metadata to successfully be written
--
Best regards,
Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] New bootstrap-prefix global USE-flag and patch to llvm.eclass
13.09.2023 07:22, Sam James пишет:
Fabian Groffen writes:
[[PGP Signed Part:Undecided]]
On 12-09-2023 20:32:19 +0100, Alexey Sokolov wrote:
Bug: https://bugs.gentoo.org/758167
Full PR is at https://github.com/gentoo/gentoo/pull/32730
Several LLVM packages require this early return, otherwise they fail to
build on Darwin. I'll also need this USE-flag for
sys-devel/clang-common, to distinguish between stage2 and stage3 of
bootstrap-prefix.sh to configure clang differently.
--
Best regards,
Alexey "DarthGandalf" Sokolov
From de2bd1abc3e5c7607413633d132c604c6a801802 Mon Sep 17 00:00:00 2001
From: Alexey Sokolov
Date: Mon, 11 Sep 2023 23:26:49 +0100
Subject: [PATCH] llvm.eclass: add global USE flag bootstrap-prefix
Mask it everywhere except for prefix profiles
Without this, stage2's LLVM packages fail to build.
Bug: https://bugs.gentoo.org/758167
Signed-off-by: Alexey Sokolov
---
eclass/llvm.eclass| 7 +++
profiles/base/use.mask| 4
profiles/features/prefix/use.mask | 4
profiles/use.desc | 1 +
4 files changed, 16 insertions(+)
diff --git a/eclass/llvm.eclass b/eclass/llvm.eclass
index 8198650aad9a7..87c2cedb3a376 100644
--- a/eclass/llvm.eclass
+++ b/eclass/llvm.eclass
@@ -64,6 +64,8 @@ esac
if [[ ! ${_LLVM_ECLASS} ]]; then
_LLVM_ECLASS=1
+IUSE="bootstrap-prefix"
+
# make sure that the versions installing straight into /usr/bin
# are uninstalled
DEPEND="!!sys-devel/llvm:0"
@@ -242,6 +244,11 @@ llvm_fix_tool_path() {
llvm_pkg_setup() {
debug-print-function ${FUNCNAME} "${@}"
+ if use bootstrap-prefix; then
+ # AppleClang has unparseable version numbers, but it's
irrelevant anyway
+ return
+ fi
+
I might misunderstand this, but is this USE-flag supposed to be set only
during bootstrap, e.g. when host-provided Clang is used? If so, would
it be possible to use has_version or something instead?
Another option is something I think we've done in the past - check
for use prefix and then some extra env var we set in the bootstrap
script.
Somehow I haven't thought about using extra env var, will try that, thanks.
We'll still need the USE-flag for sys-devel/clang-common because it will
install different content with and without it, but that can be limited
to a single package.
I think I'd prefer either your idea or the one I just mention
to a USE, but I don't think I feel very strongly between any of it.
(but given mgorny isn't keen on the USE in the PR at
https://github.com/gentoo/gentoo/pull/32730,
that's a vote against it)
Thanks,
Fabian
--
Best regards,
Alexey "DarthGandalf" Sokolov
[gentoo-dev] New bootstrap-prefix global USE-flag and patch to llvm.eclass
Bug: https://bugs.gentoo.org/758167
Full PR is at https://github.com/gentoo/gentoo/pull/32730
Several LLVM packages require this early return, otherwise they fail to
build on Darwin. I'll also need this USE-flag for
sys-devel/clang-common, to distinguish between stage2 and stage3 of
bootstrap-prefix.sh to configure clang differently.
--
Best regards,
Alexey "DarthGandalf" SokolovFrom de2bd1abc3e5c7607413633d132c604c6a801802 Mon Sep 17 00:00:00 2001
From: Alexey Sokolov
Date: Mon, 11 Sep 2023 23:26:49 +0100
Subject: [PATCH] llvm.eclass: add global USE flag bootstrap-prefix
Mask it everywhere except for prefix profiles
Without this, stage2's LLVM packages fail to build.
Bug: https://bugs.gentoo.org/758167
Signed-off-by: Alexey Sokolov
---
eclass/llvm.eclass| 7 +++
profiles/base/use.mask| 4
profiles/features/prefix/use.mask | 4
profiles/use.desc | 1 +
4 files changed, 16 insertions(+)
diff --git a/eclass/llvm.eclass b/eclass/llvm.eclass
index 8198650aad9a7..87c2cedb3a376 100644
--- a/eclass/llvm.eclass
+++ b/eclass/llvm.eclass
@@ -64,6 +64,8 @@ esac
if [[ ! ${_LLVM_ECLASS} ]]; then
_LLVM_ECLASS=1
+IUSE="bootstrap-prefix"
+
# make sure that the versions installing straight into /usr/bin
# are uninstalled
DEPEND="!!sys-devel/llvm:0"
@@ -242,6 +244,11 @@ llvm_fix_tool_path() {
llvm_pkg_setup() {
debug-print-function ${FUNCNAME} "${@}"
+ if use bootstrap-prefix; then
+ # AppleClang has unparseable version numbers, but it's irrelevant anyway
+ return
+ fi
+
if [[ ${MERGE_TYPE} != binary ]]; then
LLVM_SLOT=$(get_llvm_slot "${LLVM_MAX_SLOT}")
diff --git a/profiles/base/use.mask b/profiles/base/use.mask
index 1d4f5b92865df..cc86fde21097a 100644
--- a/profiles/base/use.mask
+++ b/profiles/base/use.mask
@@ -8,6 +8,10 @@
# eudev is masked for removal
eudev
+# Alexey Sokolov (2023-09-11)
+# Only needed during bootstrap of prefix
+bootstrap-prefix
+
# David Seifert (2023-09-09)
# EOL upstream in 2 months, causes major headaches for OpenSSL 1.1
# masking. Removal on 2023-10-09.
diff --git a/profiles/features/prefix/use.mask b/profiles/features/prefix/use.mask
index 482ce57f04485..1f43ca23fd101 100644
--- a/profiles/features/prefix/use.mask
+++ b/profiles/features/prefix/use.mask
@@ -4,6 +4,10 @@
# prefix USE flag should always be unmasked in prefix profiles
-prefix
+# Alexey Sokolov (2023-09-11)
+# Allow bootstrapping the prefix
+-bootstrap-prefix
+
# USE flags inherited by the base/use.defaults file that shouldn't be in Prefix
gpm
diff --git a/profiles/use.desc b/profiles/use.desc
index 6034f3bf6fc31..37c64f43759da 100644
--- a/profiles/use.desc
+++ b/profiles/use.desc
@@ -29,6 +29,7 @@ big-endian - Big-endian toolchain support
bindist - Flag to enable or disable options for prebuilt (GRP) packages (eg. due to licensing issues)
blas - Add support for the virtual/blas numerical library
bluetooth - Enable Bluetooth Support
+bootstrap-prefix - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for bootstrapping Gentoo Prefix
branding - Enable Gentoo specific branding
build - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of bootstrapping [make stage1]
bzip2 - Use the bzlib compression library
Re: [gentoo-dev] last rites: sys-fs/eudev
11.09.2023 22:35, Sam James пишет: Alexey Sokolov writes: 11.09.2023 22:21, Sam James пишет: orbea writes: On Mon, 11 Sep 2023 21:31:30 +0100 Sam James wrote: Dale writes: orbea wrote: On Mon, 11 Sep 2023 17:29:47 +0200 "Andreas K. Huettel" wrote: Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea: Upstream is maintained still. https://github.com/eudev-project/eudev No, it's not. Based on what? It has several commits this year and is currently working on both of my systems. Is there something specific showing why its not maintained? . On the link above it says this: On 2021-08-20 Gentoo decided to abandon eudev and a new project was established on 2021-09-14 by Alpine, Devuan and Gentoo contributors (alphabetical order). It seems to have a upstream that is active but no one is maintaining it on Gentoo. Basically, it needs a Gentoo maintainer now. It would seem given the time span that no one wants to take it. Like others, I use it but didn't know it wasn't maintained anymore. I hope someone will step up but if not, looks like we have to use udev. No, see the linked bugs. Someone has to actually make it compatible with the tags API which software is starting to use. I think its only a matter of time. https://github.com/eudev-project/eudev/pull/253 I'll apply the patch and test the builds if it helps, but I don't know about testing the runtime functionality of libgudev. Someone has to then bother reviewing it, merging it, releasing it, and ideally updating eudev for other stuff like this. Of course. Just like any other PR to any other project :) What's your point? I don't know what you mean. My point is none of that has been happening. I see, ok. I would agree with you, however, the author of that PR is a member of eudev org, so I wouldn't say it's dead just yet. Also note that the PR is a hack rather than a full implementation of the functionality anyway, which may lead to runtime misbehaviour. And that's fine for programs which don't make use of the new API. and? Someone has to actually check that? -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] last rites: sys-fs/eudev
11.09.2023 22:21, Sam James пишет: orbea writes: On Mon, 11 Sep 2023 21:31:30 +0100 Sam James wrote: Dale writes: orbea wrote: On Mon, 11 Sep 2023 17:29:47 +0200 "Andreas K. Huettel" wrote: Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea: Upstream is maintained still. https://github.com/eudev-project/eudev No, it's not. Based on what? It has several commits this year and is currently working on both of my systems. Is there something specific showing why its not maintained? . On the link above it says this: On 2021-08-20 Gentoo decided to abandon eudev and a new project was established on 2021-09-14 by Alpine, Devuan and Gentoo contributors (alphabetical order). It seems to have a upstream that is active but no one is maintaining it on Gentoo. Basically, it needs a Gentoo maintainer now. It would seem given the time span that no one wants to take it. Like others, I use it but didn't know it wasn't maintained anymore. I hope someone will step up but if not, looks like we have to use udev. No, see the linked bugs. Someone has to actually make it compatible with the tags API which software is starting to use. I think its only a matter of time. https://github.com/eudev-project/eudev/pull/253 I'll apply the patch and test the builds if it helps, but I don't know about testing the runtime functionality of libgudev. Someone has to then bother reviewing it, merging it, releasing it, and ideally updating eudev for other stuff like this. Of course. Just like any other PR to any other project :) What's your point? Also note that the PR is a hack rather than a full implementation of the functionality anyway, which may lead to runtime misbehaviour. And that's fine for programs which don't make use of the new API. libgudev is an interesting case here because it just exposes the API as GObject, including to various scripting languages; it doesn't use it by itself, some other program might do it through libgudev -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] games-emulation/jgemu keywording request
11.09.2023 21:31, orbea пишет: On Mon, 11 Sep 2023 16:21:43 -0400 Mike Gilbert wrote: On Mon, Sep 11, 2023 at 4:11 PM orbea wrote: On Mon, 11 Sep 2023 20:38:48 +0100 Sam James wrote: orbea writes: On Mon, 11 Sep 2023 19:18:45 +0100 Sam James wrote: orbea writes: Hi, Several months ago I made this issue for keywording the games-emulation/jgemu meta package which is a collection of minimal emulators for the command-line games-emulation/jgrf frontend with a focus on accuracy. You've not populated the package list and no arches are CC'd, but we don't keyword things for no reason either on (very) niche arches. Please select a reasonable set of architectures. https://bugs.gentoo.org/891201 Apologies, I wasn't aware I needed to do that and in retrospect I should of thought of it. Just to be clear you mean add an issue for each issue and then use them as blockers for the games-emulation/jgemu issue? No, one bug is okay if you populate the package list field in Bugzilla. Just keep in mind that keywording isn't the same as upstreaam CI either and we generally want to only keyword on arches where someone is likely to use it. Apologies, I now understand what you meant... The goal is to hopefully entice real world testers on systems that jgemu may be used. This is not something a CI would be able to accomplish. This is not an appropriate use of Gentoo arch testing. We keyword things based on user demand, not to satisfy the urges of upstream developers. Its a common occurrence that upstreams refuse to consider distros and leave them hanging, but I honestly did not expect the inverse where the distro is unwilling while the upstream is End users are already able to attempt building any package on any architecture by adding that package and its deps to /etc/portage/package.accept_keywords as ** Users who wish to contribute as CI to jgemu can do so already. Users who do not wish, won't do that even with the keyword. -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Last Rites: net-irc/kvirc
08.05.2023 17:57, Matt Turner пишет: # Matt Turner (2023-05-08) # Package is unmaintained and appears quite dead (e.g. SSL certificate for the # homepage expired in 2021). Only version is a snapshot from 2021. No Python # 3.11 support. Depends on app-text/enchant:0. Hi, I'm upstream. Kvirc doesn't actually require enchant:0, it just works with either enchant:0 or enchant:2. In fact, if enchant:2 is installed, it already uses it, despite the dependency. The ebuild should probably patch out the fallback to enchant:0 and just depend on enchant:2. Python 3.11 also works, but the ebuild is outdated. Re SSL cert, it's a valid concern. I'll try to figure out what happened there. Re snapshot from 2021, perhaps it's time to release a new version. We have latest commit in 2022, can at least update the ebuild to use that one. I'll take maintainership and update the ebuild, temporarily moving homepage to http:// and fixing the issues above. # Bug #905955. Removal on 2023-06-08 net-irc/kvirc -- Best regards, Alexey "DarthGandalf" Sokolov
[gentoo-dev] Last rites: dev-libs/qtcompress
# Alexey Sokolov (2023-02-23) # No revdeps left. Bug #745234 # Removal in 30 days. dev-libs/qtcompress -- Best regards, Alexey "DarthGandalf" Sokolov
[gentoo-dev] Last rites: dev-libs/qtcompress
# Alexey Sokolov (2023-02-23) # No revdeps left. Bug #745234 # Removal in 30 days. dev-libs/qtcompress -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Various packages up for grabs (avahi, curl, fcron, tor...)
acct-group/fcron acct-user/fcron sys-process/fcron I can proxy-take this -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] [PATCH] distutils-r1.eclass: support nonfatal in test
06.01.2023 00:03, Anna пишет:
On 2023-01-05 23:55, alexey+gen...@asokolov.org wrote:
From: Alexey Sokolov
if [[ ${?} -ne 0 ]]; then
- die "Tests failed with ${EPYTHON}"
+ die -n "Tests failed with ${EPYTHON}"
I don't think "nonfatal" should be used with tests. Any valid use cases
for that?
src_test() {
virtx distutils-r1_src_test
}
If the test fails with "die", Xvfb keeps running forever; but it's
cleaned up correctly with die -n
--
Best regards,
Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] [PATCH] 2022-12-24-alternatives-introduction: add news item
Russian translation attached +Sergey to see any obvious mistakes 24.12.2022 11:34, Sam James пишет: Bug: https://bugs.gentoo.org/886247 Bug: https://bugs.gentoo.org/886017 Signed-off-by: Sam James --- ...022-12-24-alternatives-introduction.en.txt | 92 +++ 1 file changed, 92 insertions(+) create mode 100644 2022-12-24-alternatives-introduction/2022-12-24-alternatives-introduction.en.txt diff --git a/2022-12-24-alternatives-introduction/2022-12-24-alternatives-introduction.en.txt b/2022-12-24-alternatives-introduction/2022-12-24-alternatives-introduction.en.txt new file mode 100644 index 000..841e07a --- /dev/null +++ b/2022-12-24-alternatives-introduction/2022-12-24-alternatives-introduction.en.txt @@ -0,0 +1,92 @@ +Title: Introduction of app-alternatives ebuilds +Author: Sam James +Posted: 2022-12-24 +Revision: 1 +News-Item-Format: 2.0 + +Gentoo is introducing a new category of ebuilds called 'app-alternatives' +to handle cases where a symlink for a common binary may want to be switched +between different packages by a user. + +Traditionally, eselect was used for this, and while eselect still has its +place, it's unsuitable for cases like /bin/awk and /bin/sh because it +prevents immutable system directories and (more importantly +from a package management perspective) relies on orphaned symlinks which +means no package owns /bin/awk, /bin/sh, etc. This is not reliable and +can lead to dead symlinks (or no symlink at all) in some edge cases [0]. + +Systems will be more robust and desired system configuration +can be achieved using the package manager rather than manual steps outside of it. + +The initial list of packages which support alternatives is as follows: +- app-alternatives/awk +- app-alternatives/bzip2 +- app-alternatives/bc +- app-alternatives/cpio +- app-alternatives/gzip +- app-alternatives/lex +- app-alternatives/sh +- app-alternatives/tar +- app-alternatives/yacc + +The stabilization of these new ebuilds and packages depending +on them is ongoing in bug 886017 [1]. + +## Per-upgrade requirements + +The default configuration on Gentoo systems is FEATURES="protect-owned" +which works similarly to FEATURES="collision-protect" but it allows +collisions between orphaned files. In this case, a one-off collision +occurs as the app-alternatives/ ebuilds begin to claim once-orphaned +symlinks. + +A similar issue occurred during the libxcrypt migration where users +had upgrades interrupted by using the older, more aggressive +FEATURES="collision-protect". + +It is recommended that users alter their configuration to +remove references to 'collision-protect' in FEATURES and instead either +explicitly enable 'protect-owned' in FEATURES or rely on the default +(equivalent). It is also acceptable to simply disable collision-protect +temporarily for the purposes of this news item. + +WARNING: Users with collision-protect enabled must disable FEATURES="collision-protect" +in /etc/portage/make.conf by removing it or setting FEATURES="-collision-protect" +if they have enabled it. collision-protect detects collisions between files including +orphaned files where no package owns the file. + +## Migrating + +To migrate your system, a standard world upgrade will suffice: +1. # emerge --sync +2. # emerge -a -uvDU @world (or other similar standard world upgrade command) + +## Configuration + +Users who are not interested in using different implementations for +various tools listed above can ignore this section. + +No configuration should be required by default, but users may wish +to configure the new app-alternatives/ ebuilds to their tastes as they +used to do via e.g. eselect-sh and eselect-awk. + +Going forward, /etc/portage/package.use will be used for this purpose. + +Users should review the USE flags available for the various app-alternatives +ebuilds like app-alternatives/sh and adjust their configuration as desired. + +For example, to have /usr/bin/gzip be provided by app-arch/pigz for automatic +parallelization of 'gzip', one would have the following in /etc/portage/package.use: +``` +# https://wiki.gentoo.org/wiki/Gzip#Parallelization +# Make /usr/bin/gzip be a symlink to pigz for a speedup in compression +app-alternatives/gzip -reference pigz +``` + +## Further reading + +For more details, please see the technical documentation on the wiki [2]. + +[0] https://wiki.gentoo.org/wiki/Project:Base/Alternatives#Why.3F +[1] https://bugs.gentoo.org/886017 +[2] https://wiki.gentoo.org/wiki/Project:Base/Alternatives -- Best regards, Alexey "DarthGandalf" Sokolov From eadf8d50a52876068cfbe17f8c4c0d2ce226edc7 Mon Sep 17 00:00:00 2001 From: Alexey Sokolov Date: Tue, 27 Dec 2022 12:51:25 + Subject: [PATCH] 2022-12-27-alternatives-introduction: add Ru translation Signed-off-by: Alexey Sokolov --- ...022-12-27-alternatives-introduction.ru.txt | 98 +++ 1 file changed, 98 insertions(+) create
Re: [gentoo-dev] [PATCH] linux-info.eclass: getfilevar: pass 'need-compiler=' to make
29.11.2022 22:14, James Le Cuirot пишет:
On Tue, 2022-11-29 at 13:55 -0500, Mike Gilbert wrote:
This avoids some unnecessary Makefile logic and gives a nice speed up.
Before the change, linux-info_pkg_setup takes 11 to 15 seconds on my
AMD Phenom II. After, it takes 3 to 4 seconds.
Signed-off-by: Mike Gilbert
---
eclass/linux-info.eclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index fc125b0d751..3e64cb9457a 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -238,7 +238,9 @@ getfilevar() {
# Pass dot-config=0 to avoid the config check in kernels prior
to 5.4.
[[ ${EAPI:-0} == [0123] ]] && nonfatal() { "$@"; }
echo -e "e:\\n\\t@echo \$(${1})\\ninclude ${basefname}" | \
- nonfatal emake -C "${basedname}" --no-print-directory
M="${T}" dot-config=0 need-config= ${BUILD_FIXES} -s -f - 2>/dev/null
+ nonfatal emake -C "${basedname}" --no-print-directory
M="${T}" \
+ dot-config=0 need-config= need-compiler= \
+ ${BUILD_FIXES} -s -f - 2>/dev/null
ARCH=${myARCH}
fi
I'm confused. Breaking up the line makes it faster?
It adds need-compiler= which was not there, but yeah, this is somewhat
hidden in breaking the line
--
Best regards,
Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
23.11.2022 16:45, Ulrich Mueller пишет: On Wed, 23 Nov 2022, Michael Orlitzky wrote: The main reason the new category is distasteful to me is because it's *so close* to being a virtual. For one, having these packages be virtuals would make them somewhat self-explanatory to end users. If we're collectively willing to overlook the "no files" bit, are there any other reasons to avoid using virtual/ ? They have a nonempty installation image and at least one phase function, therefore they're not virtuals. IIRC there are also some optimisations for the virtual category in Portage as well as in our QA tools which rely on this. However, I tend to agree that the category should be named app-meta rather than sys-meta, because chances are that non-system packages will also make use of it. Ulrich Since these packages manage symlinks, make it app-symlink? -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Last rites: media-libs/libvisual*, media-sound/lingot, media-sound/retrovol, media-sound/umix
19.11.2022 11:02, Michał Górny пишет: # Michał Górny (2022-11-19) # Packages with reported failures and no maintainer activity. # # media-sound/lingot: bug #699808, last bumped in 2018 # media-sound/retrovol: bug #624136, last bumped in 2013, homepage dead # media-sound/umix: bug #726076, last release in 2003 (!) # media-libs/libvisual*: bug #840514, last bumped in 2006 # # Removal on 2022-12-19. media-libs/libvisual media-plugins/gst-plugins-libvisual media-plugins/libvisual-plugins media-plugins/libvisual-projectm media-sound/lingot I've sent https://github.com/gentoo/gentoo/pull/28337 to bump lingot and take maintainership media-sound/retrovol media-sound/umix -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Looking for co-maintainers for number of packages
07.07.2022 11:27, Martin Kletzander пишет: On Sun, Jul 03, 2022 at 09:03:04PM -0700, Georgy Yakovlev wrote: I've been rather busy lately and can't keep up with all of my packages. There are pending bumps, some bugs, but nothing too crazy or hard. So I'm looking for someone to co-maintain (or even take over if you insist) the following packages: Noob question, I would have to be a Gentoo developer/maintainer to help with that, am I right? Don't worry, proxied maintainers can easily (co-)maintain packages too. * app-shells/fish Responsive upstream, not very frequent releases, cmake. Requires some attention on non-x86 as arch bugs are rather frequent. But nothing too crazy. Since I do not have any experience with official maintainership I would hesitate to commit to anything I am not a user of, but I do use fish and keep an eye on releases a bit (which I would do more, of course). [...] PS. Huge bonus if you can test packages not only on x86_64. Ofc I can help with some gotchas in packages and have no plans on abandoning those completely, but realistically I'm not doing enough to keep those properly maintained at the moment. I can test that every now and then and even fix some possible issues, hopefully. Let me know if I can be of help or whether I should rather go through proxy maintainers or another route. It's possible for a particular developer to be the proxy, and it's possible for p-m project to be proxies for the proxied maintainers. Have a nice day, Martin -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: Prefer "rm -rf build" over "setup.py clean -a"
09.04.2022 17:37, Michał Górny пишет:
Prefer using "rm -rf build" directly over "setup.py clean -a". This
has three advantages:
1. It is much faster.
2. It works on packages that have broken "setup.py clean",
e.g. dev-python/pydantic.
3. It works on packages that block "setup.py clean" and tell you to use
"git clean" (sic!), e.g. dev-python/scipy.
This is a potentially (but unlikely) breaking change, so do it
conditionally to GPEP517_TESTING.
Signed-off-by: Michał Górny
---
eclass/distutils-r1.eclass | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index de891215e688..e6b0ab5e0e32 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1090,7 +1090,11 @@ distutils_pep517_install() {
# clean the build tree; otherwise we may end up with PyPy3
# extensions duplicated into CPython dists
if [[ ${DISTUTILS_USE_PEP517:-setuptools} == setuptools ]]; then
- esetup.py clean -a
+ if [[ ${GPEP517_TESTING} ]]; then
+ rm -rf build || die
+ else
+ esetup.py clean -a
+ fi
fi
}
rm -r build || die
-f makes it not fail, which makes ||die useless
--
Best regards,
Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] [RFC] [News Item] Qt 5.15.3 version bump with binary path changes
27.03.2022 08:57, Andreas Sturmlechner пишет: Title: Qt 5.15.3 version bump with binary path changes Author: Andreas Sturmlechner Posted: 2022-03-27 Revision: 1 News-Item-Format: 2.0 Add Display-If-Installed: qt? Up until Qt 5.15.2 we were using qtchooser to provide unversioned links to Qt binaries in PATH, like qmake, moc, qmljs etc. Starting with 5.15.3 such links will be installed by each respective Qt package and '5'-version-suffixed, e.g. qmake becomes qmake5, qml becomes qml5 etc., mirroring Qt6. If you develop with Qt5 and rely on unversioned binaries for your workflow, dev-qt/qtchooser as a tool for quickly switching between multiple Qt installations (e.g. Qt3, Qt4 and Qt5) can still be manually installed. The 'default' Qt version in PATH is then controlled via config in /etc/xdg/qtchooser. Otherwise, dev-qt/qtchooser will be slated for cleanup on your next emerge -- depclean run. Russian translation follows Title: Новая версия Qt 5.15.3 меняет имена исполняемых файлов Author: Andreas Sturmlechner Translator: Alexey Sokolov Posted: 2022-03-27 Revision: 1 News-Item-Format: 2.0 В версиях Qt по 5.15.2 мы использовали qtchooser, чтобы устанавливать исполняемые файлы Qt в PATH без номера версии, такие как qmake, moc, qmljs и т.д. Начиная с версии 5.15.3 эти файлы будут установлены самим соответствующим пакетом Qt и будут заканчиваться на "5": например, qmake станет qmake5, qml станет qml5 и т.д., так же, как это делает Qt 6. Если вы используете Qt5 при разработке, и ваш рабочий процесс зависит от этих файлов без версии, вы всё ещё можете установить dev-qt/qtchooser — инструмент для быстрого переключения между различными установленными Qt (например, Qt3, Qt4, Qt5). В таком случае версия Qt в PATH по умолчанию настраивается в /etc/xdg/qtchooser. В противном случае dev-qt/qtchooser будет удалён при следующем запуске emerge --depclean. -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Feature request: auto-CC for bugs modified via commit tags
25.01.2022 17:33, Sam James пишет: On 25 Jan 2022, at 17:00, Michael Orlitzky wrote: Can I request that Bug: and Closes: tags in our commits automatically CC the committer on the bug that is modified? Use case: I often fix (sci-*) bugs that I'm not CCed on, and a user will leave a comment like "it still crashes on x86" that I never see. Of course, I could manually CC myself on every bug. But that will send everyone an extra email, and is forgettable. Plus, avoiding the manual step is kind of the point of the automation, right? One potential downside is that the commit author could wind up CCed twice via an alias, but that could be solved with a sufficiently clever implementation. Or disregarded if it's not too much of a problem in practice; the bugs will usually be closed, after all. I'd quite like this as I do a fair amount of drive-bys. Yes please. There were a few cases where I broke something when trying to fix something and didn't notice the report. Thanks for bringing it up. Best, sam -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage
I do sometimes run into OOM during emerge, but for a different reason:
when firefox and webengine are built in parallel. And I'm using tmpfs
for portage. These packages store lots of data in the build directory.
Decreasing -j of a single package may or may not help in this case.
The filled tmpfs issue becomes more severe if I have tests enabled,
because ctest has different behavior from make/ninja, and I use -j with
combination with -l: make and ninja run at least one job to ensure some
progress, while ctest does nothing when the load average is too high,
and while it's doing nothing, the portage cannot finish the build and
therefore cleanup the build dir from RAM.
Neither of these are exactly relevant to this patch, tbh.
04.01.2022 22:58, Sam James пишет:
Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the
amount of RAM available (uses amount declared as needed
in the ebuild). Typically should be ~2GB per job.
Bug: https://bugs.gentoo.org/570534
Signed-off-by: Sam James
---
eclass/check-reqs.eclass | 42 +---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass
index 2130e2e349141..8c4adc8b4f121 100644
--- a/eclass/check-reqs.eclass
+++ b/eclass/check-reqs.eclass
@@ -43,6 +43,8 @@ case ${EAPI} in
*) die "${ECLASS}: EAPI=${EAPI:-0} is not supported" ;;
esac
+inherit multiprocessing
+
EXPORT_FUNCTIONS pkg_pretend pkg_setup
if [[ ! ${_CHECK_REQS_ECLASS} ]]; then
@@ -53,6 +55,13 @@ _CHECK_REQS_ECLASS=1
# @DESCRIPTION:
# How much RAM is needed? Eg.: CHECKREQS_MEMORY=15M
+# @ECLASS-VARIABLE: CHECKREQS_MEMORY_MANGLE_JOBS
+# @USER_VARIABLE
+# @DESCRIPTION:
+# Allow packages to reduce the number of multiprocessing (e.g. make, ninja)
jobs
+# to lower memory usage.
+: ${CHECKREQS_MEMORY_MANGLE_JOBS=yes}
+
# @ECLASS-VARIABLE: CHECKREQS_DISK_BUILD
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -346,9 +355,36 @@ _check-reqs_memory() {
eend 0
else
eend 1
- _check-reqs_unsatisfied \
- ${size} \
- "RAM"
+
+ # Has the user allowed us to mangle their MAKEOPTS?
+ if [[ ${CHECKREQS_MEMORY_MANGLE_JOBS} == "yes" ]] ; then
+ local jobs=$(makeopts_jobs)
+
+ local
estimated_max_memory=$((${actual_memory}/$(_check-reqs_get_kibibytes 1G)))
+ if [[ $((jobs*2)) -gt ${estimated_max_memory}
]] ; then
+ # Number of jobs exceeds RAM/2GB, so
clamp it.
+ local
new_jobs=$(($(_check-reqs_get_number ${estimated_max_memory}G)*10/20))
+
+ # This might _still_ be too big on
small machines. Give up in such cases.
+ # (Users can still set the do nothing
variable which is independent of this.)
+ if [[ $((new_jobs*2)) -gt
${estimated_max_memory} ]] ; then
+ _check-reqs_unsatisfied \
+ ${size} \
+ "RAM"
+ else
+ # The clamped jobs seem to be
enough to satisfy the check-reqs requirement from the ebuild.
+ ewarn "Clamping MAKEOPTS jobs to
-j${new_jobs} to reduce memory usage"
+ ewarn "Compiler jobs may use around
~2GB each: https://wiki.gentoo.org/wiki/MAKEOPTS;
+ ewarn "To disable this, set
CHECKREQS_MEMORY_MANGLE_JOBS=no."
+
+ MAKEOPTS+=" -j${new_jobs}"
+ fi
+ fi
+ else
+ _check-reqs_unsatisfied \
+ ${size} \
+ "RAM"
+ fi
fi
else
eend 1
--
Best regards,
Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Last rites: media-sound/clementine
07.12.2021 06:29, Zoltan Puskas пишет: On Tue, Dec 07, 2021 at 07:11:23AM +0100, Lars Wendler wrote: On Mon, 6 Dec 2021 23:56:10 + Alexey Sokolov wrote: 24.11.2021 11:33, Lars Wendler пишет: No real development since Q1 2020. Last release from 2016. Users should switch over to media-sound/strawberry which is an actively developed fork. Masked for removal in 30 days. I've tried strawberry, but it's unusable [1]. At least until bugs are fixed, can it be unmasked? I can take maintainership if needed. [1] https://github.com/strawberrymusicplayer/strawberry/issues/849 Saying that it's "unusable" is quite a misleading claim when in fact only keyboard shortcuts do not work... -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Not to fan the flames (ok, maybe a little bit), but web radio support is also rather limited in Strawberry if we are being completely honest (i.e. awful user experience). I'm saying this as a person who has transitioned away from clementine quite some time ago. Cheers, Zoltan Lars, can you merge https://github.com/gentoo/gentoo/pull/23209 ? -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Last rites: media-sound/clementine
07.12.2021 06:11, Lars Wendler пишет: On Mon, 6 Dec 2021 23:56:10 + Alexey Sokolov wrote: 24.11.2021 11:33, Lars Wendler пишет: No real development since Q1 2020. Last release from 2016. Users should switch over to media-sound/strawberry which is an actively developed fork. Masked for removal in 30 days. I've tried strawberry, but it's unusable [1]. At least until bugs are fixed, can it be unmasked? I can take maintainership if needed. [1] https://github.com/strawberrymusicplayer/strawberry/issues/849 Saying that it's "unusable" is quite a misleading claim when in fact only keyboard shortcuts do not work... I'm sorry, but how am I supposed to use a media player which doesn't let me start/stop the playback? This is a clear regression from clementine which has this basic functionality. -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Last rites: media-sound/clementine
24.11.2021 11:33, Lars Wendler пишет: No real development since Q1 2020. Last release from 2016. Users should switch over to media-sound/strawberry which is an actively developed fork. Masked for removal in 30 days. I've tried strawberry, but it's unusable [1]. At least until bugs are fixed, can it be unmasked? I can take maintainership if needed. [1] https://github.com/strawberrymusicplayer/strawberry/issues/849 -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] [PATCH 0/1] ecm.eclass: set KDE_DEBUG=1 for ecm_src_test
20.10.2021 09:40, James Beddek пишет: > As part of transitioning to using Clang as my system compiler, I have been > running tests on most > packages to determine if they still properly function. However, this has > introduced a problem where > some KDE package tests segfault. > Unfortunately, this launches DrKonqi in the virtx display to display a > backtrace. > > This results in the test phase hanging as DrKonqi is presumably waiting for > user input. > See below for an instance of a test phase hanging as seen through `top -b -c > -n 1 -u portage`: > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND > 3441869 portage 30 102360 1560 1400 S 0.0 0.0 0:00.00 > [kde-apps/ark-21.08.2] sandbox /usr/lib/portage/python3.9/ebuild.sh test > 3441870 portage 30 10 12896 7688 3592 S 0.0 0.0 0:00.01 > /bin/bash /usr/lib/portage/python3.9/ebuild.sh test > 3441886 portage 30 10 13036 6296 2064 S 0.0 0.0 0:00.01 > /bin/bash /usr/lib/portage/python3.9/ebuild.sh test > 3441908 portage 30 10 150436 59128 44836 S 0.0 0.1 0:00.03 > /usr/bin/Xvfb :16 -screen 0 1280x1024x24 +extension RANDR > 3441936 portage 30 10 55000 15512 13416 S 0.0 0.0 0:00.02 ctest > -j 16 --test-load 999 > 3441938 portage 30 10 487364 58044 46480 T 0.0 0.1 0:00.20 > /var/tmp/portage/kde-apps/ark-21.08.2/work/ark-21.08.2_build/bin/addtoarchivetest > 3442262 portage 30 109176 2336 1600 S 0.0 0.0 0:00.00 > dbus-launch --autolaunch 8d4328e526b647a5a2e029d1e0814ba6 --binary-syntax > --close-stderr > 3442279 portage 30 109460 4180 3408 S 0.0 0.0 0:00.00 > /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 > --session > 3444712 portage 30 10 350068 94032 78820 S 0.0 0.1 0:00.15 > /usr/lib64/libexec/drkonqi --platform xcb --display :16 --appname > addtoarchivetest > ___ > > As far as I can tell, without sending SIGKILL to the test being traced > (addtoarchivetest in this instance), the test phase never exits. > > KDE provides a variable, KDE_DEBUG [1], which when set disables the DrKonqi > crash handler. > Using this results in the tests segfaulting and the test phase simply > failing, rather than hanging. Do crashes of other (non-ecm) tests trigger DrKonqi too? What's the reason to add this variable only to ecm.eclass? > > Most of the crashing tests are a result of kde-frameworks/kjs being built > with Clang. > I have opened a bug report about this on bugs.kde.org [2]. > > Hopefully this is an acceptable solution. I have submitted a corresponding > GitHub PR [3]. > Cheers > > [1]: > https://userbase.kde.org/KDE_System_Administration/Environment_Variables#KDE_DEBUG > [2]: https://bugs.kde.org/show_bug.cgi?id=444003#c5 > [3]: https://github.com/gentoo/gentoo/pull/22643 > > James Beddek (1): > ecm.eclass: set KDE_DEBUG=1 for ecm_src_test > > eclass/ecm.eclass | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
03.10.2021 07:58, Fabian Groffen пишет: > > FWIW, I like this one. Perhaps even with lowercase > > make[4]: leaving directory src > q* soname lacks version > e* failed to die > For me this reads as some kind of censorship to remove profanities from the output; and my mind is trying to reconstruct what profanity it was... -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] News Item for uClibc-ng deprecation
17.08.2021 12:40, Anthony G. Basile пишет: > Hi everyone, > > Can I get feedback on the following news item? (BTW, thanks soap) > > Title: uClibc-ng retirement on 2023/01/01 > Author: Anthony G. Basile > Posted: 2021-08-15 > Revision: 1 > News-Item-Format: 2.0 > Display-If-Profile: default/linux/uclibc/* > > uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021, > noone has volunteered to step up maintenance or expressed interest in > the uClibc-ng profiles. With this announcement we last-rite the "uclibc" > profiles, which will be removed on 2023/01/01. For parties interested in 2023-01-01 please. > an alternative libc, consider moving to musl, which is supported. > > Gentoo continues to wholeheartedly support musl and is focusing its > efforts in that area. > > Resources: > - https://wiki.gentoo.org/wiki/Project:Hardened_musl > - https://gitweb.gentoo.org/proj/musl.git/ (overlay for patches) > - #gentoo-hardened (IRC channel on irc.libera.chat) for support and > discussion > > -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] [PATCH v2] 2021-08-01-tcpd-disabled: Remove USE=tcpd from make.defaults
29.07.2021 21:40, David Seifert пишет: > Signed-off-by: David Seifert > --- > .../2021-08-01-tcpd-disabled.en.txt | 68 +++ > 1 file changed, 68 insertions(+) > create mode 100644 2021-08-01-tcpd-disabled/2021-08-01-tcpd-disabled.en.txt > > diff --git a/2021-08-01-tcpd-disabled/2021-08-01-tcpd-disabled.en.txt > b/2021-08-01-tcpd-disabled/2021-08-01-tcpd-disabled.en.txt > new file mode 100644 > index 000..977be80 > --- /dev/null > +++ b/2021-08-01-tcpd-disabled/2021-08-01-tcpd-disabled.en.txt > @@ -0,0 +1,68 @@ > +Title: USE=tcpd no longer globally enabled > +Author: David Seifert > +Posted: 2021-08-01 > +Revision: 1 > +News-Item-Format: 2.0 > +Display-If-Profile: default/linux/* > +Display-If-Installed: net-analyzer/argus-clients[tcpd] > +Display-If-Installed: net-ftp/proftpd[tcpd] > +Display-If-Installed: app-admin/conserver[tcpd] > +Display-If-Installed: app-admin/prelude-manager[tcpd] > +Display-If-Installed: app-admin/qpage[tcpd] > +Display-If-Installed: app-admin/syslog-ng[tcpd] > +Display-If-Installed: app-backup/bacula[tcpd] > +Display-If-Installed: app-backup/bareos[tcpd] > +Display-If-Installed: app-misc/mosquitto[tcpd] > +Display-If-Installed: dev-libs/yaz[tcpd] > +Display-If-Installed: gnome-base/gdm[tcpd] > +Display-If-Installed: mail-mta/exim[tcpd] > +Display-If-Installed: mail-mta/sendmail[tcpd] > +Display-If-Installed: media-sound/pulseaudio[tcpd] > +Display-If-Installed: net-analyzer/argus[tcpd] > +Display-If-Installed: net-analyzer/net-snmp[tcpd] > +Display-If-Installed: net-analyzer/nrpe[tcpd] > +Display-If-Installed: net-analyzer/nsca[tcpd] > +Display-If-Installed: net-analyzer/rrdtool[tcpd] > +Display-If-Installed: net-fs/netatalk[tcpd] > +Display-If-Installed: net-fs/nfs-utils[tcpd] > +Display-If-Installed: net-ftp/atftp[tcpd] > +Display-If-Installed: net-ftp/tftp-hpa[tcpd] > +Display-If-Installed: net-ftp/vsftpd[tcpd] > +Display-If-Installed: net-irc/ngircd[tcpd] > +Display-If-Installed: net-mail/cyrus-imapd[tcpd] > +Display-If-Installed: net-mail/dovecot[tcpd] > +Display-If-Installed: net-mail/mailutils[tcpd] > +Display-If-Installed: net-mail/tpop3d[tcpd] > +Display-If-Installed: net-misc/apt-cacher-ng[tcpd] > +Display-If-Installed: net-misc/ser2net[tcpd] > +Display-If-Installed: net-misc/socat[tcpd] > +Display-If-Installed: net-misc/sslh[tcpd] > +Display-If-Installed: net-misc/stunnel[tcpd] > +Display-If-Installed: net-misc/usbip[tcpd] > +Display-If-Installed: net-nds/openldap[tcpd] > +Display-If-Installed: net-nds/rpcbind[tcpd] > +Display-If-Installed: net-nds/tac_plus[tcpd] > +Display-If-Installed: net-proxy/dante[tcpd] > +Display-If-Installed: net-vpn/ocserv[tcpd] > +Display-If-Installed: net-vpn/pptpd[tcpd] > +Display-If-Installed: sci-libs/dcmtk[tcpd] > +Display-If-Installed: sys-apps/linux-misc-apps[tcpd] > +Display-If-Installed: sys-apps/xinetd[tcpd] > +Display-If-Installed: sys-fs/quota[tcpd] > +Display-If-Installed: sys-power/nut[tcpd] > + > +On 2021-11-01, we will remove USE="tcpd" from the globally default > +enabled USE flags (bug #805077). USE="tcpd" usually enables Please make the bug a full bug URL; such short form can be very surprising for someone not familiar with gentoo development > +sys-apps/tcp-wrappers for an ad hoc firewall based on /etc/hosts.allow > +and /etc/hosts.deny. > + > +The Base System project has come to the conclusion that 24 years after > +the last upstream release, tcp-wrappers is not suitable for a default > +configuration in 2021 anymore. Other distributions have completely > +removed support at this point. We strongly recommend you switch to more > +modern packet filters, such as BPF, nftables, or iptables. If you rely > +on tcp-wrappers, you can re-enable the flag, see > + > + https://wiki.gentoo.org/wiki//etc/portage/package.use > + > +for package-specific ways to re-enable tcp-wrappers. > -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Guarantees of unstable architectures
26.07.2021 17:23, Marek Szuba пишет: > Dear everyone, > > During the open-floor part of this month's Council meeting I asked > whether there is any official policy regarding what is or is not > guaranteed for hardware architectures we do not consider stable in > Gentoo. For reference, according to the current version of > profiles/arches.desc (commit 7bdebec50c44c0222bf76334c34926b593e94dd4, > dated 2021-04-05) this means: alpha, ia64, m68k, mips, riscv, s390, > and all Prefix arches. Only the non-RAP one (amd64-linux etc). The prefix installation on amd64 now supports using stable amd64 keyword: https://bugs.gentoo.org/759424 > > As it turns out, we do not in fact have any such policy. On the other > hand, during my time as a Gentoo developer I have heard from other > developers a fairly wide range of opinions on the subject - from > insisting on clean QA results, passing tests etc. regardless of whether > an arch is stable or not to assuming we guarantee nothing for unstable > arches. > > Anyway, it has been decided that it makes sense to discuss this on the > mailing list before making it a Council matter. Therefore - what do you > all think here? > -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] [PATCH 3/3] 2021-07-21-libxcrypt-migration: new news item for libxcrypt migration changes
Instead of removing the translation, can it be updated? Here's the new text to append: Обратите внимание: если последний раз вы меняли пароль до ~2008 года, он может использовать в /etc/shadow слабую хэш-функцию, такую как md5crypt. При этом дефект в PAM [0][1] может помешать вам войти в систему. Мы рекомендуем вам сменить пароль, чтобы он использовал современные хэши. Данный дефект был исправлен в новой версии PAM, добавленной в дерево. В некоторых случаях Portage может попытаться пересобрать некоторые пакеты в неправильном порядке [2]. Если какой-то пакет не собирается, попробуйте сначала обновить libcrypt и libxcrypt: # emerge -v1 virtual/libcrypt sys-libs/libxcrypt А затем продолжите обновление системы с помощью опции Portage "--keep-going=y". Дополнительные сведения и советы можно найти здесь: * https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation * https://bugs.gentoo.org/699422 [0] https://bugs.gentoo.org/802267 [1] https://bugs.gentoo.org/802807 [2] https://bugs.gentoo.org/802210 20.07.2021 22:32, Sam James пишет: > Bug: https://bugs.gentoo.org/699422 > Signed-off-by: Sam James > --- > .../2021-06-30-libxcrypt-migration.ru.txt | 47 --- > .../2021-07-21-libxcrypt-migration.en.txt | 4 +- > 2 files changed, 2 insertions(+), 49 deletions(-) > delete mode 100644 > 2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt > rename 2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.en.txt > => 2021-07-21-libxcrypt-migration/2021-07-21-libxcrypt-migration.en.txt (98%) > > diff --git > a/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt > b/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt > deleted file mode 100644 > index d52db11..000 > --- a/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt > +++ /dev/null > @@ -1,47 +0,0 @@ > -Title: Миграция в ~arch с glibc[crypt] на libxcrypt > -Author: Andreas K. Hüttel > -Author: Sam James > -Translator: Alexey Sokolov > -Posted: 2021-06-30 > -Revision: 1 > -News-Item-Format: 2.0 > - > -Реализация библиотеки libcrypt.so в glibc давно устарела и скоро > -будет удалена. > - > -Прочие дистрибутивы годы назад уже переключились на внешнюю > -реализацию под названием libxcrypt. Мы решили последовать их примеру > -и тоже переключиться на libxcrypt. Вначале изменения затронут системы > -на ~arch. > - > -Это будет обычное обновление, и, скорее всего, вам не нужно будет > -предпринимать никаких действий, и проблем возникнуть не должно. > - > -Однако, мы рекомендуем сперва *полностью* обновить систему. > -Это стандартная рекомендация, но в этом конкретном случае > -более простой граф зависимостей поможет portage вычислить > -порядок обновлений. > - > -Так что, чтобы упростить процесс обновления, пожалуйста, > -обновите систему сейчас, до начала самой миграции. > - > -Для пользователей ~arch изменение произойдёт 14 июля 2021, > -пользователи стабильной ветки перейдут на libxcrypt позже. > - > -Если по какой-либо причине вы *не* хотите пока переходить > -на libxcrypt (всего лишь отлагая неизбежное), выполните > -следующие действия: > -* размаскируйте и включите USE-флаг crypt пакета sys-libs/glibc > -* замаскируйте USE-флаг system пакета sys-libs/libxcrypt > -* замаскируйте >=virtual/libcrypt-2 > - > -Если вы хотите перейти на libxcrypt уже, точная процедура > -описана в wiki (см. ниже), но суть такая: > -* принудительно выключите USE-флаг crypt пакета sys-libs/glibc > -* размаскируйте USE-флаги system и, если требуется, split-usr > - пакета sys-libs/libxcrypt > -* размаскируйте ~virtual/libcrypt-2 > - > -Дополнительные сведения можно найти здесь: > -* https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation > -* https://bugs.gentoo.org/699422 > diff --git > a/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.en.txt > b/2021-07-21-libxcrypt-migration/2021-07-21-libxcrypt-migration.en.txt > similarity index 98% > rename from > 2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.en.txt > rename to 2021-07-21-libxcrypt-migration/2021-07-21-libxcrypt-migration.en.txt > index fb16a29..1a9ea96 100644 > --- a/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.en.txt > +++ b/2021-07-21-libxcrypt-migration/2021-07-21-libxcrypt-migration.en.txt > @@ -1,8 +1,8 @@ > Title: migrating from glibc[crypt] to libxcrypt in ~arch > Author: Andreas K. Hüttel > Author: Sam James > -Posted: 2021-06-30 > -Revision: 2 > +Posted: 2021-07-21 > +Revision: 1 > News-Item-Format: 2.0 > > The implementation of libcrypt.so within glibc has been deprecated > -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] [PATCH] Add 2021-06-30-libxcrypt-migration
Hi, Russian translation attached. >From eba38cc083c51fe6e1325920a8c976b8ae697a1e Mon Sep 17 00:00:00 2001 From: Alexey Sokolov Date: Thu, 1 Jul 2021 23:49:22 +0100 Subject: [PATCH] Translate libxcrypt news to Russian Bug: https://bugs.gentoo.org/699422 Signed-off-by: Alexey Sokolov --- .../2021-06-30-libxcrypt-migration.ru.txt | 47 +++ 1 file changed, 47 insertions(+) create mode 100644 2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt diff --git a/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt b/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt new file mode 100644 index 000..d52db11 --- /dev/null +++ b/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.ru.txt @@ -0,0 +1,47 @@ +Title: Миграция в ~arch с glibc[crypt] на libxcrypt +Author: Andreas K. Hüttel +Author: Sam James +Translator: Alexey Sokolov +Posted: 2021-06-30 +Revision: 1 +News-Item-Format: 2.0 + +Реализация библиотеки libcrypt.so в glibc давно устарела и скоро +будет удалена. + +Прочие дистрибутивы годы назад уже переключились на внешнюю +реализацию под названием libxcrypt. Мы решили последовать их примеру +и тоже переключиться на libxcrypt. Вначале изменения затронут системы +на ~arch. + +Это будет обычное обновление, и, скорее всего, вам не нужно будет +предпринимать никаких действий, и проблем возникнуть не должно. + +Однако, мы рекомендуем сперва *полностью* обновить систему. +Это стандартная рекомендация, но в этом конкретном случае +более простой граф зависимостей поможет portage вычислить +порядок обновлений. + +Так что, чтобы упростить процесс обновления, пожалуйста, +обновите систему сейчас, до начала самой миграции. + +Для пользователей ~arch изменение произойдёт 14 июля 2021, +пользователи стабильной ветки перейдут на libxcrypt позже. + +Если по какой-либо причине вы *не* хотите пока переходить +на libxcrypt (всего лишь отлагая неизбежное), выполните +следующие действия: +* размаскируйте и включите USE-флаг crypt пакета sys-libs/glibc +* замаскируйте USE-флаг system пакета sys-libs/libxcrypt +* замаскируйте >=virtual/libcrypt-2 + +Если вы хотите перейти на libxcrypt уже, точная процедура +описана в wiki (см. ниже), но суть такая: +* принудительно выключите USE-флаг crypt пакета sys-libs/glibc +* размаскируйте USE-флаги system и, если требуется, split-usr + пакета sys-libs/libxcrypt +* размаскируйте ~virtual/libcrypt-2 + +Дополнительные сведения можно найти здесь: +* https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation +* https://bugs.gentoo.org/699422 -- 2.31.1
Re: [gentoo-dev] Declare the type of source
Hi 28.06.2021 14:00, Agostino Sarubbo пишет: > Hello all, > > long story short: > > when there is a major change (new gcc, new libc, and so on), tinderbox takes > a > lot of time to test the entire tree. > > Let's do a practical example: > A new version of sys-devel/gcc is added to the tree. > > There is no way to know how much packages compiles C/C++ code, so the easiest > way is compile the entire tree. > > Instead, imagine that each ebuild declares a variable called SOURCETYPE ( or > similar, or in metadata.xml if you prefer ) and with a tool like equery/eix > we > are able to get the list of all packages that compiles C code. > > The same thing applies to other languages like python, ruby, go and so on > where compile the dev-$language category covers a lot of packages, but there > will be always other ebuilds that uses $language in other categories. > > What do you think? > > Agostino > > I can easily imagine a scenario where some pure perl package would fail tests because one of indirect dependencies was compiled with clang instead of gcc. -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Packages up for grabs
> dev-cpp/yaml-cpp I'll take this -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] [PATCH news v3] Add Python 3.9 news item
Oops, I thought I did that. Fixed. чт, 6 мая 2021 г. в 07:57, Michał Górny : > > On Thu, 2021-05-06 at 01:13 +0100, Alexey Sokolov wrote: > > Here's the Russian version > > > > Could you include a copyright signoff, please? This is pretty major > work. > > -- > Best regards, > Michał Górny > > > From 1bd30ecd61096a683f71533669c539d42b655bfe Mon Sep 17 00:00:00 2001 From: Alexey Sokolov Date: Thu, 6 May 2021 01:05:38 +0100 Subject: [PATCH] Translate python3-9 to Ru Signed-off-by: Alexey Sokolov --- .../2021-05-05-python3-9.ru.txt | 113 ++ 1 file changed, 113 insertions(+) create mode 100644 2021-05-05-python3-9/2021-05-05-python3-9.ru.txt diff --git a/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt b/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt new file mode 100644 index 000..cfef9d4 --- /dev/null +++ b/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt @@ -0,0 +1,113 @@ +Title: Python 3.9 станет питоном по умолчанию 2021-06-01 +Author: Michał Górny +Translator: Alexey Sokolov +Posted: 2021-05-05 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/python:3.7 +Display-If-Installed: dev-lang/python:3.8 + +1 июня 2021 года мы собираемся переключить Python по умолчанию на системах +Gentoo с версии 3.8 на версию 3.9. Если вы не меняли значения PYTHON_TARGETS и +PYTHON_SINGLE_TARGET, изменение затронет систему сразу: пакетный менеджер +попытается применить изменение при следующем обновлении системы. + +Если же вы изменили эти значения, предпочитаете более безопасный подход, или +при обновлении возникли проблемы, продолжайте читать. + +Пожалуйста, обратите внимание, что метод обновления по умолчанию переключает +пакеты на новую версию питона, когда они пересобираются. Это означает, что для +пересборки пакета все зависимые пакеты должны уже поддерживать новую версию, и +некоторые программы временно могут не находить свои зависимости во время +обновления (однако, скорее всего, уже запущенные программы будут в порядке). + +Если PYTHON_TARGETS или PYTHON_SINGLE_TARGET объявлены в вашем make.conf, +пожалуйста, удалите их оттуда, потому что они будут конфликтовать с показанными +далее кусками из package.use. Мы не рекомендуем использовать make.conf для +этих переменных, поскольку они мешают применяться значениям по умолчанию для +пакетов, где это необходимо. В этой новости мы подразумеваем, что вы +используете /etc/portage/package.use или его эквивалент для вашего пакетного +менеджера. + +У вас есть выбор из следующих вариантов: + +1. Если вы хотите, чтобы питон обновлялся сам, вы можете удалить объявленные + PYTHON_TARGETS и PYTHON_SINGLE_TARGET. Когда значения по умолчанию + изменятся, пакетный менеджер должен сам всё обновить. Но если возникнут + проблемы, вам всё равно может прийтись запустить команды обновления. + +2. Если вы хотите пока отложить обновление, вы можете явно указать старые + значения в package.use. + +3. Если вы хотите обновиться раньше, вы можете явно указать новые значения и + запустить команды обновления. + +4. Если вы хотите более безопасный подход, у которого меньше шансов поломать + пакеты во время обновления, вы можете произвести последовательность шагов, + описанных далее. + +5. Наконец, вы можете произвольным образом комбинировать значения + PYTHON_TARGETS и PYTHON_SINGLE_TARGET. + + +Откладывание обновления +=== +Чтобы отложить обновление, явно укажите старые значения: + +*/* PYTHON_TARGETS: -* python3_8 +*/* PYTHON_SINGLE_TARGET: -* python3_8 + +Это заставит систему использовать Python 3.8 и предотвратит будущие обновления. +Однако, такое решение сойдёт только на несколько месяцев; когда-нибудь вам +всё-таки нужно будет обновиться. + + +Принудительное обновление += +Чтобы обновиться до Python 3.9 раньше, явно укажите новые значения: + +*/* PYTHON_TARGETS: -* python3_9 +*/* PYTHON_SINGLE_TARGET: -* python3_9 + +При этом важно не забыть удалить эти строки после смены значений по умолчанию, +иначе они помешают будущим автоматическим обновлениям до следующих версий +питона. + + +Процедура безопасного обновления + +Более безопасный подход такой: сначала добавляется в систему поддержка Python +3.9, а затем удаляется Python 3.8. Однако, все затронутые пакеты будут +пересобраны дважды, и это заметно дольше. + +Сначала включите и Python 3.8, и Python 3.9 и запустите команды обновления: + +*/* PYTHON_TARGETS: -* python3_8 python3_9 +*/* PYTHON_SINGLE_TARGET: -* python3_8 + +Затем замените PYTHON_SINGLE_TARGET и ещё раз запустите команды: + +*/* PYTHON_TARGETS: -* python3_8 python3_9 +*/* PYTHON_SINGLE_TARGET: -* python3_9 + +Наконец, вот окончательная версия, и не забудьте запустить команды: + +*/* PYTHON_TARGETS: -* python3_9 +*/* PYTHON_SINGLE_TARGET: -* python3_9 + +После смены значений по умолчанию вы можете удалить эти настройки. Или же вы
Re: [gentoo-dev] [PATCH news v3] Add Python 3.9 news item
Here's the Russian version пн, 3 мая 2021 г. в 21:35, Sam James : > > > > > On 3 May 2021, at 21:18, Michał Górny wrote: > > > > On Mon, 2021-05-03 at 19:06 +0100, Sam James wrote: > >> [snip] > > > > I want to avoid it on the top, so people don't do it prematurely before > > reading their options. > > > > Good point - and I can’t complain, given I partly made that comment earlier ;) > > LGTM then. > > > -- > > Best regards, > > Michał Górny > From 757517fe67e353f44a8739237a552726ae7c221f Mon Sep 17 00:00:00 2001 From: Alexey Sokolov Date: Thu, 6 May 2021 01:05:38 +0100 Subject: [PATCH] Translate python3-9 to Ru --- .../2021-05-05-python3-9.ru.txt | 113 ++ 1 file changed, 113 insertions(+) create mode 100644 2021-05-05-python3-9/2021-05-05-python3-9.ru.txt diff --git a/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt b/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt new file mode 100644 index 000..cfef9d4 --- /dev/null +++ b/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt @@ -0,0 +1,113 @@ +Title: Python 3.9 станет питоном по умолчанию 2021-06-01 +Author: Michał Górny +Translator: Alexey Sokolov +Posted: 2021-05-05 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/python:3.7 +Display-If-Installed: dev-lang/python:3.8 + +1 июня 2021 года мы собираемся переключить Python по умолчанию на системах +Gentoo с версии 3.8 на версию 3.9. Если вы не меняли значения PYTHON_TARGETS и +PYTHON_SINGLE_TARGET, изменение затронет систему сразу: пакетный менеджер +попытается применить изменение при следующем обновлении системы. + +Если же вы изменили эти значения, предпочитаете более безопасный подход, или +при обновлении возникли проблемы, продолжайте читать. + +Пожалуйста, обратите внимание, что метод обновления по умолчанию переключает +пакеты на новую версию питона, когда они пересобираются. Это означает, что для +пересборки пакета все зависимые пакеты должны уже поддерживать новую версию, и +некоторые программы временно могут не находить свои зависимости во время +обновления (однако, скорее всего, уже запущенные программы будут в порядке). + +Если PYTHON_TARGETS или PYTHON_SINGLE_TARGET объявлены в вашем make.conf, +пожалуйста, удалите их оттуда, потому что они будут конфликтовать с показанными +далее кусками из package.use. Мы не рекомендуем использовать make.conf для +этих переменных, поскольку они мешают применяться значениям по умолчанию для +пакетов, где это необходимо. В этой новости мы подразумеваем, что вы +используете /etc/portage/package.use или его эквивалент для вашего пакетного +менеджера. + +У вас есть выбор из следующих вариантов: + +1. Если вы хотите, чтобы питон обновлялся сам, вы можете удалить объявленные + PYTHON_TARGETS и PYTHON_SINGLE_TARGET. Когда значения по умолчанию + изменятся, пакетный менеджер должен сам всё обновить. Но если возникнут + проблемы, вам всё равно может прийтись запустить команды обновления. + +2. Если вы хотите пока отложить обновление, вы можете явно указать старые + значения в package.use. + +3. Если вы хотите обновиться раньше, вы можете явно указать новые значения и + запустить команды обновления. + +4. Если вы хотите более безопасный подход, у которого меньше шансов поломать + пакеты во время обновления, вы можете произвести последовательность шагов, + описанных далее. + +5. Наконец, вы можете произвольным образом комбинировать значения + PYTHON_TARGETS и PYTHON_SINGLE_TARGET. + + +Откладывание обновления +=== +Чтобы отложить обновление, явно укажите старые значения: + +*/* PYTHON_TARGETS: -* python3_8 +*/* PYTHON_SINGLE_TARGET: -* python3_8 + +Это заставит систему использовать Python 3.8 и предотвратит будущие обновления. +Однако, такое решение сойдёт только на несколько месяцев; когда-нибудь вам +всё-таки нужно будет обновиться. + + +Принудительное обновление += +Чтобы обновиться до Python 3.9 раньше, явно укажите новые значения: + +*/* PYTHON_TARGETS: -* python3_9 +*/* PYTHON_SINGLE_TARGET: -* python3_9 + +При этом важно не забыть удалить эти строки после смены значений по умолчанию, +иначе они помешают будущим автоматическим обновлениям до следующих версий +питона. + + +Процедура безопасного обновления + +Более безопасный подход такой: сначала добавляется в систему поддержка Python +3.9, а затем удаляется Python 3.8. Однако, все затронутые пакеты будут +пересобраны дважды, и это заметно дольше. + +Сначала включите и Python 3.8, и Python 3.9 и запустите команды обновления: + +*/* PYTHON_TARGETS: -* python3_8 python3_9 +*/* PYTHON_SINGLE_TARGET: -* python3_8 + +Затем замените PYTHON_SINGLE_TARGET и ещё раз запустите команды: + +*/* PYTHON_TARGETS: -* python3_8 python3_9 +*/* PYTHON_SINGLE_TARGET: -* python3_9 + +Наконец, вот окончательная версия, и не забудьте запустить команды: +
Re: [gentoo-dev] [News item review] V2 Chromium access to Google services
Hi, Russian translation follows.
Title: Доступ браузера Chromium к сервисам Google
Author: Stephan Hartmann
Translator: Alexey Sokolov
Posted: 2021-03-09
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: www-client/chromium
С 15 марта 2021 команда Google Chrome ограничит доступ к Google API и службам,
зарезервированным для использования самим Google. Это означает, что
пользователи больше не смогут войти в учётную запись Google и потому у них не
будет доступа к, например, Chrome Sync.
Поэтому нам приходится удалить из www-client/chromium Client ID и ключи. Мы уже
удалили их из =www-client/chromium-89.0.4389.82, остальные версии будут
обновлены в ближайшем будущем.
Если вам нужен доступ к этим API, вам нужно либо перейти на
www-client/google-chrome{-beta,-unstable}, либо установить ваши собственные
ключи [1], что, однако, предназначено только для разработки. Инструкцию по
созданию и использованию собственных ключей можно найти здесь [2].
[1]
https://groups.google.com/a/chromium.org/g/chromium-dev/c/jgy5pcJ7np8/m/p3j_4b6vBQAJ
[2] https://www.chromium.org/developers/how-tos/api-keys
пн, 8 мар. 2021 г. в 19:01, Stephan Hartmann :
>
> Hi,
>
> updated based on previous suggestions.
>
> ```
> Title: Chromium access to Google services
> Author: Stephan Hartmann
> Content-Type: text/plain
> Posted: 2021-03-09
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: www-client/chromium
>
> Starting March 15th, 2021 Google Chrome Team will restrict access to
> Google APIs and services that are reserved for Google use only. This
> means that users are no longer able to login into their Google Accounts
> which disables access to for example Chrome Sync.
>
> As a consequence we have to remove Client ID and secret from all
> www-client/chromium ebuilds. This change has already been done for
> =www-client/chromium-89.0.4389.82. Other versions will be updated
> shortly.
>
> If you need one of the Google use only APIs, then you either have to
> switch to www-client/google-chrome{-beta,-unstable} or setup your own
> keys [1]. However, the latter is only intended for development.
> Documentation on how to generate and use own keys can be found in [2].
>
> [1]
> https://groups.google.com/a/chromium.org/g/chromium-dev/c/jgy5pcJ7np8/m/p3j_4b6vBQAJ
> [2] https://www.chromium.org/developers/how-tos/api-keys
> ```
>
> Best regards,
>
> Stephan
>
Re: [gentoo-dev] feature request: packages.gentoo.org
Hi There is a Packages component at https://bugs.gentoo.org/enter_bug.cgi?product=Websites for reports like this пт, 12 февр. 2021 г. в 07:10, Jaco Kroon : > > Hi, > > Firstly: I was aware of packages.gentoo.org - but only really discovered it > in the week - THANK YOU VERY MUCH FOR THIS. > > Not sure whether this is the best place for my request, so if not, please > feel free to bat me in the right direction. > > https://packages.gentoo.org/packages/net-misc/asterisk (example) refers. > > I'm the (proxy) maintainer. > > The above URL merely states: > > It seems that version 18.2.0 is available upstream, while the latest version > in the Gentoo tree is 16.15.1. > > This is correct. Just looking a little down, it's noted there are two > versions currently in tree: > > 16.15.1-r2 : 0 > 13.38.1-r2 : 0 > > What's not indicated, there are subslots (13 and 16 respectively). > > eshowkw (app-portage/gentoolkit) shows: > > Keywords for net-misc/asterisk: > | | u | > | a a p s a r | n | > | m r h p p s l i i m m | e u s| r > | d a m p p c a x 3 p a s 6 i | a s l| e > | 6 r 6 p p 6 r 8 9 h 6 c 8 p | p e o| p > | 4 m 4 a c 4 c 6 0 a 4 v k s | i d t| o > --+-+--+--- >13.38.1-r2 | + ~ ~ o ~ ~ o + o o o o o o | 7 o 0/13 | gentoo > --+-+--+--- > [I]16.15.1-r2 | ~ ~ ~ o ~ ~ o ~ o o o o o o | 7 o 0/16 | gentoo > > Which is currently as intended (yea, I'm behind the times - stable and > working in this case over bleeding edge - and nobody other than me is yet > pushing me to stable /16, although I have a bug request to package 18 which I > intend to start work on today hopefully since I'm working on asterisk stuff > for business purposes today anyway). > > 13 is security only release now, and 16 and 18 are the primary branches where > 16 is more intended as stable and more fluctuations on 18 still (which > precludes me from using it for our company just yet). > > Point being, it would be great if packages.gentoo.org could indicate that in > above cases as follows: > > 18.2.0 is available, which is correct, and desired, but if it could also > indicate that for the 16 branch there is currently a version of 16.16.0 > available, and for 13 things are up to date. > > Would be useful too to indicate that certain branches (eg, 17 in the asterisk > case will not be packaged due to being primarily development branches, or at > the very least, will not be considered for stabling) > > In other words, guessing I'm looking for some form of "branched versions" > support here. > > I know security already has some work around subslots as it was the sec team > that requested me to add subslots to net-misc/asterisk. > > And yes ... looks like repology does have a few issues around branches too: > https://repology.org/project/asterisk/cves?version=13.38.1 > > So I would completely understand if it's not possible to deal with this. As > per > https://archives.gentoo.org/gentoo-dev/message/b793f4da5a5b5e20a063ea431500a820 > there are certain configs that can go into > https://gitweb.gentoo.org/sites/soko-metadata.git/ - however, not being a > core developer, I don't have (nor am I requesting) access here. May I > suggest that in-package metadata (ie, metadata.xml, or even inside the > ebuilds) might be a better location for some of this configuration if > possible, and if it makes sense? For me the advantage is that as a PM I can > submit the required information via PR. > > A description of the branch structure may be more suitable here anyway, > because that way other tools can leverage it too? > > Then again, perhaps just looking at the subslots as already available is good > enough, in the case of the packages I work on this would indeed be adequate, > but it may not be for other packages. > > Looking at repology.org itself, I'm not sure my request is trivial, and I'm > not going to ask tons of effort be put into this, but perhaps an interesting > challenge for someone at some point. > > Kind Regards, > Jaco
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
ср, 10 февр. 2021 г. в 01:16, Tim Harder : > > On 2021-02-09 Tue 17:51, Benda Xu wrote: > > I am wondering how useable pkgcore is on alpha, hppa, etc. Maybe it's > > time for us to plan for a Gentoo without essential Python dependency. > > Just to keep misinformation down, pkgcore currently has nothing to do > with rust as it's implemented in python due to basically being deemed > portage-ng when it forked ~15 years ago. It previously did have some > extensions written in C which have mostly been removed in the current > day from CPython catching up in a number of areas. > > That being said, alternative languages and related support has been > looked at for a number of reasons/features and development could move in > that direction, but hasn't yet in a public fashion. > > Tim > Another far-fetched option is to compile CPython to WebAssembly+WASI [1] (even if CPython itself will require Rust in future), and run it on the non-Rust-supported architecture via an interpreter [2]. If this works at all, bootstrap will probably be not trivial. And such version of interpreted python may need to be added to PYTHON_TARGETS to enable testing of this on more usual architectures like amd64. [1] https://wasi.dev/ [2] https://github.com/wasm3/wasm3
Re: [gentoo-dev] New project: binhost
ср, 10 февр. 2021 г. в 19:12, Rich Freeman : > > On Wed, Feb 10, 2021 at 12:57 PM Andreas K. Hüttel > wrote: > > > > * what portage features are still needed or need improvements (e.g. binpkg > > signing and verification) > > * how should hosting look like > > Some ideas for portage enhancements: > > 1. Ability to fetch binary packages from some kind of repo. > 2. Ability to have multiple binary packages co-exist in a repo (local > or remote) with different build attributes (arch, USE, CFLAGS, > DEPENDS, whatever). > 3. Ability to pick the most appropriate binary packages to use based > on user preferences (with a mix of hard and soft preferences). > > One idea I've had around how #2-3 might be implemented is: > 1. Binary packages already contain data on how they were built (USE > flags, dependencies, etc). Place this in a file using a deterministic > sorting/etc order so that two builds with the same settings will have > the same results. > 2. Generate a hash of the file contents - this can go in the filename > so that the file can co-exist with other files, and be located > assuming you have a full matching set of metadata. > 3. Start dropping attributes from the file based on a list of > priorities and generate additional hashes. Create symlinked files to > the original file using these hashes (overwriting or not existing > symlinks based on policy). This allows the binary package to be found > using either an exact set of attributes or a subset of higher-priority > attributes. This is analogous to shared object symlinking. > 4. The package manager will look for a binary package first using the > user's full config, and then by dropping optional elements of the > config (so maybe it does the search without CFLAGs, then without USE > flags). Eventually it aborts based on user prefs (maybe the user only > wants an exact match, or is willing to accept alternate CFLAGs but not > USE flags, or maybe anything for the arch is selected. A related idea: if user could specify which USE-flags are mandatory to be set, which USE flags are mandatory to be not set, and which can be either way, it's easier to find the matching binary package with less constraints, where only some flags match. > 5. As always the final selected binary package still gets evaluated > like any other binary package to ensure it is usable. > > Such a system can identify whether a potentially usable file exists > using only filename, cutting down on fetching. In the interests of > avoiding useless fetches we would only carry step 3 reasonably far - > packages would have to match based on architecture and any dynamic > linking requirements. So we wouldn't generate hashes that didn't > include at least those minimums, and the package manager wouldn't > search for them. > > Obviously you could do more (if you have 5 combinations of use flags, > look for the set that matches most closely). That couldn't be done > using hashes alone in an efficient way. You could have a small > manifest file alongside the binary package that could be fetched > separately if the package manager wants to narrow things down and > fetch a few of those to narrow it down further. > > Or you could skip the hash searching and just fetch all the manifests > for a particular package/arch and just search all of those, but that > is more data to transfer just to do a query. A metadata cache of some > kind of might be another solution. Content hashes would probably > still be useful just to allow co-existence of alternate builds. > > -- > Rich >
Re: [gentoo-dev] [News item review v2] Python preference to follow PYTHON_TARGETS
вс, 24 янв. 2021 г. в 12:59, Michał Górny : > > Here's v2 with extra 'tl;dr' instructions in first para: > > ``` > Title: Python preference to follow PYTHON_TARGETS > Author: Michał Górny > Posted: 2021-01-24 > Revision: 1 > News-Item-Format: 2.0 > > On 2021-02-01 stable users will switch to a new method of updating > the preferred Python versions that employs the configuration update > mechanism in order to follow PYTHON_TARGETS. We will also deprecate > and stop installing app-eselect/eselect-python by default. If you wish > to use the newest Python version present in your PYTHON_TARGETS, you > only have to accept configuration changes. If you wish need > to customize the behavior, read on. typo: wish need > > Since 2017, /usr/bin/python and the related non-versioned symlinks > are wrapped through dev-lang/python-exec. The list of preferred Python > implementations is stored in /etc/python-exec/python-exec.conf and/or > per-program /etc/python-exec/.conf configuration files. > To preserve backwards compatibility, app-eselect/eselect-python remained > a wrapper that updated this file. > > However, this mechanism alone has proven inconvenient to end users who > had to update python-exec.conf whenever the default PYTHON_TARGETS > changed. Thanks to the fallback logic, this was not a major problem > for software installed via Gentoo packages that always ensure that > a supported implementation is used. However, users have reported that > whenever the preference for /usr/bin/python mismatched their > PYTHON_TARGETS, their custom scripts would break due to unsatisfied > dependencies. This does not follow the principle of least surprise. > > For this reason, we have decided to change the default python-exec > configuration to match PYTHON_TARGETS by default, in the eclass > preference order, that is from the newest CPython version to oldest, > with alternative Python implementations coming afterwards. This change > will be propagated via the configuration protection mechanism whenever > dev-lang/python-exec-conf is installed or rebuilt due to PYTHON_TARGETS > changes. This will permit the users to interactively confirm > the updates. > > If the new default is not correct for you, please use your preferred > configuration update tool to discard or edit the new configuration file. > > Furthermore, dev-lang/python will no longer attempt to automatically > update the Python interpreter preference, or pull in eselect-python > automatically. If you wish to continue using it, please install it > manually to ensure that it is not unmerged. Perhaps add the "emerge" command here, to avoid users to actually *manually* installing it? That is, not via the ebuild. The Russian translation follows. Should I post it as a separate file somewhere? Title: Предпочтения Python будут следовать PYTHON_TARGETS 1 февраля 2021 пользователи стабильной ветки перейдут на новый метод обновления предпочтительной версии Python, который будет использовать значение переменной PYTHON_TARGETS и применять механизм обновления конфигураций. Также мы объявляем app-eselect/eselect-python устаревшим и по умолчанию перестанем его устанавливать. Если вы хотите использовать самую новую версию Python из указанных в PYTHON_TARGETS, вам надо только принять изменения конфигурации. Если же вам нужно настроить индивидуальное поведение, продолжайте читать. С 2017 года /usr/bin/python и тому подобные символические ссылки без версии являются обёртками с помощью dev-lang/python-exec. Список предпочтительных реализаций Python хранится в /etc/python-exec/python-exec.conf и/или в /etc/python-exec/<программа>.conf для программ с конфигурацией не по умолчанию. Для обратной совместимости app-eselect/eselect-python остался обёрткой, которая обновляла этот файл. Однако сам по себе этот механизм оказался неудобен пользователям, которым теперь приходилось обновлять python-exec.conf каждый раз, когда менялась переменная PYTHON_TARGETS. Благодаря логике запасных вариантов это не было большой проблемой для программ, установленных из репозитория Gentoo, т.к. они гарантируют использование поддерживаемой реализации Python. Но пользователи сообщали, что, когда предпочтение для /usr/bin/python не совпадало с их PYTHON_TARGETS, из-за неудовлетворённых зависимостей ломались пользовательские программы, что противоречит принципу наименьшего удивления. Поэтому мы решили изменить стандартную настройку python-exec, теперь она будет совпадать с PYTHON_TARGETS в порядке предпочтения, используемым eclass'ом: сначала все CPython, начиная с новейшей версии и заканчивая старейшей, затем другие реализации Python. Это изменение будет установлено в систему с помощью механизма защиты конфигураций каждый раз при установке или пересборке dev-lang/python-exec-conf из-за изменения PYTHON_TARGETS. При этом у пользователей будет возможность интерактивно подтвердить данные изменения. Если новые настройки вам не подходят, пожалуйста, используйте ваш любимый инструмент обновления
Re: [gentoo-dev] ml project created
Hi, that wiki page says it just got deleted, by you вт, 12 янв. 2021 г. в 19:24, Alfredo Tupone : > > As I have interest on lot of ebuild on dev-ml, and most of them are not > managed by any project, I have created a project to handle them. > > I have build https://wiki.gentoo.org/wiki/Project:Ml tring to revive > an old ml project. > > Any comments? > > Alfredo >
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
вт, 29 дек. 2020 г. в 13:33, David Seifert :
>
> On Tue, 2020-12-29 at 13:21 +, Peter Stuge wrote:
> > Michał Górny wrote:
> > > > 2. Install them into different prefixes (eg /usr/lib/openssl +
> > > > /usr/lib/libressl and have the linker link to a specific version,
> > > > /usr/include/{openssl,libressl} too).
> > >
> > > For the record, this is something I've been wondering about for a
> > > long
> > > time. However, there are two problems with that: a small one
> > > and a huge one.
> > >
> > > The small problem is that this requires a lot of additional
> > > downstream
> > > work. I mean, you have to explicitly support the choice in ebuilds,
> > > and this means making things even harder for newcomers.
> >
> > pkg-config/pkgconf and .pc files can help with this part, taking care
> > of all abstraction if/when downstream uses a libressl.pc.
>
> As we have learned from the ncurses[tinfo] debacle, 80% of build systems
> don't use the .pc files, and just guess "-lssl" flags and a bunch of
> include dirs. Hence, this boils down to patching a mountain of build
> systems again, which while being the ultimately correct way, is a pipe
> dream.
If it's the ultimately correct way, such patches can be sent upstream,
regardless of whether libressl stays.
>
> > > The big problem is that (unless I'm mistaken) we won't be able to
> > > load
> > > LibreSSL and OpenSSL to the same executable. So we'd actually have
> > > to
> > > enforce that the whole link chain links to the same SSL provider,
> > > and effectively land pretty close to where we are now.
> >
> > I'd suggest investigating whether symbol versioning could help with
> > this,
> > or if the only way forward would indeed be to require some symbol
> > mangling/rewriting.
>
> While this sounds like a theoretical solution, it isn't tractable
> because
> 1. We're inventing our own ABI that is incompatible with everyone else's
> 2. We'd have to maintain a huge swamp of downstream patches
> 3. ABI can still break even with perfect symbol versioning
>
>
Re: [gentoo-dev] Applying for package maintenance
15.11.2020 10:10, Ivan J. пишет: > Greetings. I am wondering what is the process to apply for maintaining a > package in the portage tree that has a "mainainer-needed" entry? More > specifically, I would like to maintain www-client/surf. > Please see https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
10.11.2020 08:55, Fabian Groffen пишет: > On 09-11-2020 19:38:28 +0000, Alexey Sokolov wrote: >> Hi Fabian >> I tried to migrate my prefix to 17.1, and there are issues. >> >> 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an >> error "/usr/lib is a real directory! was the migration done already?" > > I think unsymlink-lib doesn't have Prefix support, but in addition, > what unsymlink-lib is trying to achieve, is not a thing perhaps on > Prefix. > > A prefix system (at least all of mine) doesn't have libXX or lib/XX > (a.k.a. multilib) directories. The /usr-split was long ago removed, > and thus what we have is: > > lib -> usr/lib > > Now, SYMLINK_LIB=no seems to split into lib and lib64, but lib64 does > not exist on Prefix systems. > > Since Prefix is non-multilib by design*, I wonder if unsymlink-lib is > necessary in the best case, but going to break the Prefix system in the > worst case. > > What instructed you to perform the migration? Was it the news-item? I > don't think it should apply for Prefix profiles, and perhaps we should > be happy the tool won't work. It was the big scary warning about the deprecation whenever I run emerge. It contains list of steps. > * non-multilib is a decision dating back a decade or so, which means > effectively any Prefix install you encounter should be non-multilib > > >> 2) $ unsymlink-lib --root ~/gentoo --migrate --pretend >> usage: unsymlink-lib [-h] [-p] [--root ROOT] [--analyze] [--migrate] >> [--rollback] [--finish] [--force-rollback] >> [--resume-finish] [-P PREFIX] [--hardlink] >> unsymlink-lib: error: Requested action requires root privileges >> >> Well, I worked it around by adding "is_root = True" to unsymlink-lib > > Did it do anything to your system like creating a lib64 directory? Does > anything work (because I have doubts on whether your system can still > find the libs in there now). Yes. Attaching logs. > >> >> 3) Step 9 (Rebuild gcc) fails: >> configure:4372: checking whether the C compiler works >> >> >> >> configure:4394: x86_64-pc-linux-gnu-gccconftest.c >&5 >> >> >> >> /home/user/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/as: >> error while loading shared libraries: >> libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so: cannot open shared > > Something like this I was suspecting. Can you still rollback? If you > can, I'd try that and hope it restores your system in working order. Yeah, don't worry, this is my ebuild-testing chroot. I just did "lxc restore". -- Best regards, Alexey "DarthGandalf" Sokolov Analyzing files installed into lib & lib64... directories that will be moved to /home/user/gentoo/lib/: (+ 0 files) directories whose contents will be split between /home/user/gentoo/lib/ and /home/user/gentoo/lib64/: orphan dirs/files (not owned by any package) that will be moved to /home/user/gentoo/lib/: gentoo modprobe.d systemd orphan dirs/files (not owned by any package) that will be kept in /home/user/gentoo/lib64/: ld-2.31.so ld-linux-x86-64.so.2 libBrokenLocale-2.31.so libBrokenLocale.so.1 libSegFault.so libanl-2.31.so libanl.so.1 libc-2.31.so libc.so.6 libcrypt-2.31.so libcrypt.so.1 libdl-2.31.so libdl.so.2 libkmod.so.2 libkmod.so.2.3.5 libm-2.31.so libm.so.6 libmemusage.so libmvec-2.31.so libmvec.so.1 libnsl-2.31.so libnsl.so.1 libnss_compat-2.31.so libnss_compat.so.2 libnss_db-2.31.so libnss_db.so.2 libnss_dns-2.31.so libnss_dns.so.2 libnss_files-2.31.so libnss_files.so.2 libnss_hesiod-2.31.so libnss_hesiod.so.2 libpcprofile.so libpthread-2.31.so libpthread.so.0 libresolv-2.31.so libresolv.so.2 librt-2.31.so librt.so.1 libthread_db-1.0.so libthread_db.so.1 libutil-2.31.so libutil.so.1 directories that will be moved to /home/user/gentoo/usr/lib/: (+ 0 files) directories whose contents will be split between /home/user/gentoo/usr/lib/ and /home/user/gentoo/usr/lib64/: orphan dirs/files (not owned by any package) that will be moved to /home/user/gentoo/usr/lib/: Mcrt1.o Scrt1.o audit binutils cmake crt1.o crti.o crtn.o debug engines-1.1 gawk gcc gconv gcrt1.o gettext glibc-2.31 help2man libffi misc perl5 pkgconfig portage python-exec python3.7 systemd terminfo tmpfiles.d xml2Conf.sh orphan dirs/files (not owned by any package) that will be kept in /home/user/gentoo/usr/lib64/: libBrokenLocale.a libBrokenLocale.so libacl.so libacl.so.1 libacl.so.1.1.2253 libanl.a libanl.so libasprintf.so libasprintf.so.0 libasprintf.so.0.0.0 libassuan.so libassuan.so.0 libassuan.so.0.8.3 libattr.so libattr.so.1 l
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
07.11.2020 12:56, Fabian Groffen пишет: > On 07-11-2020 11:42:44 +0000, Alexey Sokolov wrote: >> 22.10.2020 20:16, Andreas K. Hüttel пишет: >>> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny: >>>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote: >>>>> Users frequently are choosing the wrong profile versions in new installs >>>>> and accidentally downgrading to 17.0 with some saying they see it first. >>>>> >>>>> A simple reordering could help new installs. >>> >>> Independent of this useful change, it's probably time to deprecate the >>> amd64 >>> 17.0 profiles! >>> >> >> Prefix bootstrap script still makes new installations to use it > > This should be solved with > > b0445c0a8dd6d2f792c5bb088b154aca53868353 > a9c478dc881ee18fefc7342da994b00e60eaad8e > > on gentoo.git and > > 0d7f6b6eb00d0f51f35019846b8f79048b30be93 > > on prefix.git. > > Thanks, > Fabian > > Hi Fabian I tried to migrate my prefix to 17.1, and there are issues. 1) unsymlink-lib requires "--root ~/gentoo" and otherwise produces an error "/usr/lib is a real directory! was the migration done already?" 2) $ unsymlink-lib --root ~/gentoo --migrate --pretend usage: unsymlink-lib [-h] [-p] [--root ROOT] [--analyze] [--migrate] [--rollback] [--finish] [--force-rollback] [--resume-finish] [-P PREFIX] [--hardlink] unsymlink-lib: error: Requested action requires root privileges Well, I worked it around by adding "is_root = True" to unsymlink-lib 3) Step 9 (Rebuild gcc) fails: configure:4372: checking whether the C compiler works configure:4394: x86_64-pc-linux-gnu-gccconftest.c >&5 /home/user/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/as: error while loading shared libraries: libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so: cannot open shared object file: No such file or directory configure:4398: $? = 1 configure:4436: result: no The file exists: $ find ~ -name libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so /home/user/gentoo/usr/lib/binutils/x86_64-pc-linux-gnu/2.34/libopcodes-2.34.0.gentoo-sys-devel-binutils-st.so -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
07.11.2020 14:39, Andreas K. Huettel пишет: > > > On November 7, 2020 1:42:44 PM GMT+02:00, Alexey Sokolov > wrote: >> 22.10.2020 20:16, Andreas K. Hüttel пишет: >>> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny: >>>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote: >>>>> Users frequently are choosing the wrong profile versions in new >> installs >>>>> and accidentally downgrading to 17.0 with some saying they see it >> first. >>>>> >>>>> A simple reordering could help new installs. >>> >>> Independent of this useful change, it's probably time to deprecate >> the amd64 >>> 17.0 profiles! >>> >> >> Prefix bootstrap script still makes new installations to use it > > Meh. Time to change that then... > Nah, Fabian has just fixed it (in another reply to my message in this thread) -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
22.10.2020 20:16, Andreas K. Hüttel пишет: > Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny: >> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote: >>> Users frequently are choosing the wrong profile versions in new installs >>> and accidentally downgrading to 17.0 with some saying they see it first. >>> >>> A simple reordering could help new installs. > > Independent of this useful change, it's probably time to deprecate the amd64 > 17.0 profiles! > Prefix bootstrap script still makes new installations to use it -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
04.11.2020 19:10, Marty E. Plummer пишет:
> On Tue, Nov 03, 2020 at 07:13:32AM +0200, Joonas Niilola wrote:
>> Hey,
>>
> <-snip->
> Just my 2c, One of the major reasons I use gentoo is the ability to use
> live ebuilds relatively easily. One has the equivalent in arch linux in
> the form of ${pkgname}-${vcs} aur packages but keeping them up to date
> is quite annoying.
>>
>> -- juippis
>>
>
What you're describing is live ebuilds, and I agree they are useful.
Joonas was talking about packages which have *only* live ebuilds, and no
other versions, and not even snapshots.
--
Best regards,
Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init
> > What happens if I ignore this news item and do nothing? > > > > If you ignore this news item and upgrade your packages without installing > display-manager-init, you will no longer have an 'xdm' init script and you > will > not get a gui on boot. > Then please state that clearly in the text. Now it looks like a request to test some new feature, with no particular benefit for the user. Especially as it does say "test"
Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init
сб, 17 окт. 2020 г. в 23:05, Aisha Tammy : > > Hi, > I'm attaching the news item for the upcoming display-manager-init changes > > Thanks, > Aisha > > --- > > Title: New OpenRC Display Manager Initializer Scripts > Author: Aisha Tammy > Posted: 2020-10-17 > Revision: 1 > News-Item-Format: 2.0 This will be shown even if no xdm was installed? > > There has been a refactoring of the old 'xdm' init script and its > requirements from various packages into an independent package: > > gui-libs/display-manager-init > > This package provides the 'display-manager' startup script for > handling your chosen display manager, without being dependent on > Xorg server. > > To update to the new DM init scripts, you need to manually add the > package in your @world set: > > emerge -vuDU gui-libs/display-manager-init > > To start using the new init scripts, change the DISPLAYMANAGER > variable in the /etc/conf.d/display-manager to your preferred DM: > > DISPLAYMANAGER="gdm" > > To test the newly installed scripts, you can try to switch to > 'display-manager' on the running computer. > Run the following commands in a tty to test your current install: > > rc-service xdm stop > rc-service display-manager start > > If the test succeeds, you can remove the old xdm startup script > and add display-manager to the default runlevel: > > rc-update del xdm default > rc-update add display-manager default > > Reboot your computer to perform a final test and check to see > that your chosen display manager has started. What happens if I ignore this news item and do nothing?
Re: [gentoo-dev] [PATCH 5/5] dev-python/miniupnpc: Use verify-sig.eclass
вт, 6 окт. 2020 г. в 10:59, Michał Górny :
>
> Signed-off-by: Michał Górny
> ---
> dev-python/miniupnpc/Manifest | 1 +
> dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild | 11 +++
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/dev-python/miniupnpc/Manifest b/dev-python/miniupnpc/Manifest
> index 955881a8af5a..5341c95b6ff0 100644
> --- a/dev-python/miniupnpc/Manifest
> +++ b/dev-python/miniupnpc/Manifest
> @@ -1 +1,2 @@
> DIST miniupnpc-2.1.20191224.tar.gz 94740 BLAKE2B
> 85c0b3eb678685bc7192dbee9440ec5f5be80cbac4d6a4e0a6473662c66f05ef512322cd535a142ffe16d3099a86f78ea70645a7eb2979c373e7a486aeab0cd5
> SHA512
> d362f914ce9177c1bc46f1f3ae59069c61c0c9c1b6ea7e78003d6b46445d3550835ffc541c2649b5fbc997d035357b461148edb3648135f33d0ce98b54961917
> +DIST miniupnpc-2.1.20191224.tar.gz.sig 543 BLAKE2B
> ddbde04faa7bce62fdbb5b555bda9dc9ff69f09cc97442049adc787a03ec91824f14cdddaef6e577cf8d08fa96202fc792333b8dab7e6e8c30847fa9302a35d0
> SHA512
> b8885d2002259c95ede7ab57aaf82db83c2bd7ace3d0986179efac4245ffd42161049e0167a9ac1ff18de6c8df4d39356f0fb6aa6dada7523a238b4db4838887
> diff --git a/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild
> b/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild
> index 5e1d489b2e1e..e42aadd90e0d 100644
> --- a/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild
> +++ b/dev-python/miniupnpc/miniupnpc-2.1.20191224.ebuild
> @@ -5,11 +5,12 @@ EAPI=7
>
> PYTHON_COMPAT=( python3_{6,7,8} pypy3 )
>
> -inherit distutils-r1
> +inherit distutils-r1 verify-sig
>
> DESCRIPTION="Python bindings for UPnP client library"
> HOMEPAGE="http://miniupnp.free.fr/;
> -SRC_URI="http://miniupnp.free.fr/files/${P}.tar.gz;
> +SRC_URI="http://miniupnp.free.fr/files/${P}.tar.gz
> + verify-sig? ( http://miniupnp.free.fr/files/${P}.tar.gz.sig )"
>
> LICENSE="BSD"
> SLOT="0"
> @@ -17,8 +18,10 @@ KEYWORDS="amd64 ppc ppc64 x86"
> IUSE=""
>
> RDEPEND=">=net-libs/miniupnpc-${PV}:0="
> -DEPEND="${RDEPEND}
> - dev-python/setuptools[${PYTHON_USEDEP}]"
> +DEPEND="${RDEPEND}"
> +BDEPEND="verify-sig? ( app-crypt/openpgp-keys-miniupnp )"
> +
> +VERIFY_SIG_OPENPGP_KEY_PATH=/usr/share/openpgp-keys/miniupnp.asc
Shouldn't this be prefixed with ${BROOT}? (preferably, in the eclass)
>
> PATCHES=(
> "${FILESDIR}"/miniupnpc-2.0.20171102-shared-lib.patch
> --
> 2.28.0
>
>
Re: [gentoo-dev] Please port your packages to Python 3.8
вт, 1 сент. 2020 г. в 13:06, Rich Freeman : > > On Tue, Sep 1, 2020 at 7:02 AM Michał Górny wrote: > > > > QA reports provide a list [2] and a graph [3] of packages needing > > porting. > > These lists would be far more useful if they actually listed the > maintainer(s) of each package. Then devs could just grep to discover > if any of their packages need fixing. > > Otherwise I fear that you're just going to run into the same issue as > last time - most devs will just wait until you take the time to do > this and file bugs. > I would also like a warning shown in p.g.o if the package is in one of these qa lists
Re: [gentoo-dev] [PATCH] acct-*.eclass: Create sysusers.d files
As this doesn't depend on architecture, why /lib and not /share?
сб, 29 авг. 2020 г. в 20:53, Michał Górny :
>
> Thanks to David Michael for the initial patch and upstream fixes.
>
> Signed-off-by: Michał Górny
> ---
> eclass/acct-group.eclass | 16 +++-
> eclass/acct-user.eclass | 16 +++-
> 2 files changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
> index 5550e4a2fb10..dc1562974870 100644
> --- a/eclass/acct-group.eclass
> +++ b/eclass/acct-group.eclass
> @@ -80,7 +80,7 @@ S=${WORKDIR}
>
>
> # << Phase functions >>
> -EXPORT_FUNCTIONS pkg_pretend pkg_preinst
> +EXPORT_FUNCTIONS pkg_pretend src_install pkg_preinst
>
> # @FUNCTION: acct-group_pkg_pretend
> # @DESCRIPTION:
> @@ -116,6 +116,20 @@ acct-group_pkg_pretend() {
> fi
> }
>
> +# @FUNCTION: acct-group_src_install
> +# @DESCRIPTION:
> +# Installs sysusers.d file for the group.
> +acct-group_src_install() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + insinto /usr/lib/sysusers.d
> + newins - ${CATEGORY}-${ACCT_GROUP_NAME}.conf < <(
> + printf "g\t%q\t%q\n" \
> + "${ACCT_GROUP_NAME}" \
> + "${ACCT_GROUP_ID/#-*/-}"
> + )
> +}
> +
> # @FUNCTION: acct-group_pkg_preinst
> # @DESCRIPTION:
> # Creates the group if it does not exist yet.
> diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> index e82f3c56dbbe..f9772c3cb111 100644
> --- a/eclass/acct-user.eclass
> +++ b/eclass/acct-user.eclass
> @@ -312,7 +312,7 @@ acct-user_pkg_pretend() {
> # @FUNCTION: acct-user_src_install
> # @DESCRIPTION:
> # Installs a keep-file into the user's home directory to ensure it is
> -# owned by the package.
> +# owned by the package, and sysusers.d file.
> acct-user_src_install() {
> debug-print-function ${FUNCNAME} "${@}"
>
> @@ -321,6 +321,20 @@ acct-user_src_install() {
> # created yet
> keepdir "${ACCT_USER_HOME}"
> fi
> +
> + insinto /usr/lib/sysusers.d
> + newins - ${CATEGORY}-${ACCT_USER_NAME}.conf < <(
> + printf "u\t%q\t%q\t%q\t%q\t%q\n" \
> + "${ACCT_USER_NAME}" \
> + "${ACCT_USER_ID/#-*/-}:${ACCT_USER_GROUPS[0]}" \
> + "${DESCRIPTION//[:,=]/;}" \
> + "${ACCT_USER_HOME}" \
> + "${ACCT_USER_SHELL/#-*/-}"
> + if [[ ${#ACCT_USER_GROUPS[@]} -gt 1 ]]; then
> + printf "m\t${ACCT_USER_NAME}\t%q\n" \
> + "${ACCT_USER_GROUPS[@]:1}"
> + fi
> + )
> }
>
> # @FUNCTION: acct-user_pkg_preinst
> --
> 2.28.0
>
>
Re: [gentoo-dev] RFC: packages.g.o: new features available
It's great, thanks! I was confused at first at two different buttons "Pull requests", one showing them inline, one going to github, and two different buttons "Bugs", one showing them inline, one going to bugzilla. Sources of data seem to be inconsistent: https://i.imgur.com/PM138E2.png Well, to be fair, the new ebuild was just pushed. Another comment, unrelated to the new features: RESTRICT="test? (test)" probably shouldn't trigger the T symbol the same way as RESTRICT="test" does. ср, 8 июл. 2020 г. в 03:58, Max Magorsch : > > Hi all, > > I am glad to announce further progress at packages.gentoo.org (pgo in > the following). Compared to previous work during the last months, > which mostly addressed the back end, the new changes are rather > comprehensive. That's why I am looking forward to feedback here. > > So the tl;dr is that the new pgo version now displays: > - dependencies > - reverse dependencies > - pkgcheck results > - repology.org data > - github pull requests > - stabilization bugs > - keywording bugs > - security bugs > - general bugs > for each package. > > Additionally, there are new sites for all package maintainers, that is: > - Gentoo Projects (e.g. pyt...@gentoo.org) > - Gentoo Developers (e.g. la...@gentoo.org > - Proxied Maintainers (e.g. la...@the-cow.de) > > The maintainer's sites contain: > - all packages of the maintainer > - all outdated packages (according to repology) > - all related pull requests > - all related bugs (general, keywording and stabilization) > - all security bugs > - the changelog of all maintained packages > You will find the new sites under the 'Maintainers' tab. > > The overall appearance of the site has also slightly changed to > display all of the new information. > > Currently, the new version is deployed to: > > https://packagestest.gentoo.org/ > > Everyone is welcome to take a look around and tell me whether you > consider the new information as useful for your workflow and/or what > you would still change. > > I'm looking forward to your feedback. > > -M >
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
вс, 7 июн. 2020 г. в 09:10, Pacho Ramos : > > > I think this is the list of completely unmaintained packages now (indeed most > of > them, around 100) :) > > x11-misc/shutter I'm updating this one right now
Re: [gentoo-dev] Package up for grabs: dev-cpp/asio
вт, 2 июн. 2020 г. в 02:27, Stefan Strogin : > > Hi, > > I don't use dev-cpp/asio or any of its reverse dependencies any longer. > > CC to mysql-bugs, because sys-cluster/galera depends on dev-cpp/asio. > Hi. I can take it unless someone else wants to.
