eselect news - 2021-01-30-display-manager-init

[milomak]

[asturm]

Again, read the news item. It tells you exactly what list of packages to add to package.accept_keywords.

[milomak]

i'm really not sure where we are missing each other where you don't see what i was saying surely in building a new path like this much closer collaboration is needed

as i said on a few occasions i am running unstable

[figueroa]

[Anon-E-moose]

[asturm]

That's the puzzling bit - on an ~arch system all those versions are lining up anyway. So either there was some local mask in place or a different blocker affecting one of the listed packages, ideally to be trouble shooted in a new thread.

[Anon-E-moose]

If unsure whether there is something local, then something like grep -rE "xinit|sysvinit|xorg-server" /etc/portage would show it.

I'd also check to make sure it's really an ~arch system vs an arch system with some ~ packages, but that an end user check.


Edit to add: although if anything is causing a chain effect block it's likely to be something like nvidia drivers.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[figueroa]

I'm stable amd64 and up-to-date. Here is what I get:

[GDH-gentoo]

Yeah, all those packages have to be upgraded in the same emerge command to avoid blockers.

emerge -a1 xinit xorg-server sysvinit after modifying /etc/portage/package.accept_keywords works as well.

[Tony0945]

[figueroa]

[Tony0945]

[asturm]

[figueroa]

[asturm]

[figueroa]

Honestly, I had no idea that format would actually work. I thought it was cryptic shorthand:

[asturm]

[figueroa]

asturm: Thank you for the clarification, and especially the reference.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi

[Hu]

asturm addressed the way the package atom is written. As an addendum since people seem to be caught by the other side of it: if there are no keywords specified, then there is an implied keyword of ~ARCH, where ARCH is whatever architecture you are on. This makes for a nice shorthand if you want to allow testing from your own architecture, but not bring in testing packages from other architectures. This is useful when working with packages where some versions may be completely unkeyworded for your architecture, but available in testing for other architectures, and you want to wait until someone declares them ready for testing on your architecture. It's also convenient because it makes the news items more portable. The same instructions apply to everyone, regardless of their architecture.

[figueroa]

EDITED 3/24/2021 0947 EDT -- correcting my incorrect assumptions.

I got tired of waiting for this whole transition to become stable for amd64. I added to /etc/portage/package.accept_keywords:

[asturm]

I'm not sure what the purpose of this keyword list change is yet again, but gui-libs/display-manager-init is missing in it. Don't rely on trial and error when there is no need for that.

[figueroa]

[wfdawson]

I'm scanning this thread only and may have missed important details, but...

Brand new Gentoo VM instance. Fully synced. Installed Xfce, Slim. Read https://wiki.gentoo.org/wiki/Display_manager about XDM being deprecated. Attempted to install gui-libs/display-manager-init but find there are no stable versions. Added to accept_keywords, only to find blockers. News article or no, this is a fully unacceptable situation. Incidentally, XDM emerges without any of these nonsensical issues.

gui-libs/display-manager-init is clearly not ready to be called "stable" in any sane interpretation of the word.

[asturm]

The XDM *package* was never involved in that matter.

display-manager-init still doesn't have stable keywords (at least on major arches), that is correct. But it is entirely possible to emerge it, you just need to read through the news item.

[Zucca]