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

[milomak]

No. Read the news item: https://www.gentoo.org/support/news-ite ... -init.html

Your nvidia-drivers blocker is unrelated to this thread.

yes the nvidia stuff was fluff

i was talking to the packages mentioned in that release. i realise it is unstable and so this type of thing thing can happen. and i am quite frankly happy to deal with such.

it just seems that given such a change, there would be more collaboration that the nvidia package is not the block

Code: Select all

Calculating dependencies... done!
[ebuild  N     ] gui-libs/display-manager-init-1.0-r2::gentoo  0 KiB
[blocks B      ] <=sys-apps/sysvinit-2.98 ("<=sys-apps/sysvinit-2.98" is blocking gui-libs/display-manager-init-1.0-r2)
[blocks B      ] <=x11-apps/xinit-1.4.1 ("<=x11-apps/xinit-1.4.1" is blocking gui-libs/display-manager-init-1.0-r2)
[blocks B      ] <=x11-base/xorg-server-1.20.10 ("<=x11-base/xorg-server-1.20.10" is blocking gui-libs/display-manager-init-1.0-r2)

Total: 1 package (1 new), Size of downloads: 0 KiB
Conflict: 3 blocks (3 unsatisfied)

and again let me highlight i understand working with unstable and how such things happen. i just think in this specific situation it may not have been handled as well as it could be. but no harm from my side.

[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

Code: Select all

Calculating dependencies... done!
[ebuild  N     ] gui-libs/display-manager-init-1.0-r3::gentoo  0 KiB
[blocks B      ] <=x11-apps/xinit-1.4.1 ("<=x11-apps/xinit-1.4.1" is blocking gui-libs/display-manager-init-1.0-r3)
[blocks B      ] <=sys-apps/sysvinit-2.98 ("<=sys-apps/sysvinit-2.98" is blocking gui-libs/display-manager-init-1.0-r3)
[blocks B      ] <=x11-base/xorg-server-1.20.10 ("<=x11-base/xorg-server-1.20.10" is blocking gui-libs/display-manager-init-1.0-r3)

note the package versions doing the blocking. the very ones stated in the enews.

note what i am able to install

Code: Select all

# eix gui-libs/display-manager-init
* gui-libs/display-manager-init
     Available versions:  (~)1.0-r3
     Homepage:            https://wiki.gentoo.org/wiki/Project:X11
     Description:         RC init files for starting display and login managers

i've had to mask it to be able to update this system

[figueroa]

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

The news item is out-of-date again. When is this going to happen for stable users?

[Anon-E-moose]

Code: Select all

Calculating dependencies... done!
[ebuild  N     ] gui-libs/display-manager-init-1.0-r3::gentoo  0 KiB
[blocks B      ] <=x11-apps/xinit-1.4.1 ("<=x11-apps/xinit-1.4.1" is blocking gui-libs/display-manager-init-1.0-r3)
[blocks B      ] <=sys-apps/sysvinit-2.98 ("<=sys-apps/sysvinit-2.98" is blocking gui-libs/display-manager-init-1.0-r3)
[blocks B      ] <=x11-base/xorg-server-1.20.10 ("<=x11-base/xorg-server-1.20.10" is blocking gui-libs/display-manager-init-1.0-r3)

Lets state things this way.

If you want to emerge gui-libs/display-manager-init-1.0-r3 then xinit installed version must be above xinit-1.4.1 and the same for the other two.

This is from the ebuild itself

Code: Select all

RDEPEND="
    sys-apps/gentoo-functions
    !<=sys-apps/sysvinit-2.98
    !<=x11-apps/xinit-1.4.1
    !<=x11-base/xorg-server-1.20.10
    !=x11-base/xorg-server-1.20.10-r2
"

This ebuild will not install if the ! conditions are violated, this means that every package that's blocking must meet that criteria.
The 4 packages with the ! must be in package.accept or you must set ~ globally.
This has nothing to do with display manager being in accept.

[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.

[figueroa]

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

Code: Select all

$ emerge -p display-manager-init

These are the packages that would be merged, in order:

Calculating dependencies  
... done!
[ebuild  N    ~] gui-libs/display-manager-init-1.0-r3 
[blocks B      ] =x11-base/xorg-server-1.20.10-r2 ("=x11-base/xorg-server-1.20.10-r2" is blocking gui-libs/display-manager-init-1.0-r3)
[blocks B      ] <=x11-apps/xinit-1.4.1 ("<=x11-apps/xinit-1.4.1" is blocking gui-libs/display-manager-init-1.0-r3)
[blocks B      ] <=sys-apps/sysvinit-2.98 ("<=sys-apps/sysvinit-2.98" is blocking gui-libs/display-manager-init-1.0-r3)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (x11-base/xorg-server-1.20.10-r2:0/1.20.10::gentoo, installed) pulled in by
    x11-base/xorg-server required by @selected 

  (gui-libs/display-manager-init-1.0-r3:0/0::gentoo, ebuild scheduled for merge) pulled in by
    display-manager-init


For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

https://wiki.gentoo.org/wiki/Handbook:X86/Working/Portage#Blocked_packages

Herer is what I put in /etc/portage/package.accept_keywords

Code: Select all

gui-libs/display-manager-init ~amd64
x11-apps/xinit ~amd64
x11-base/xorg-server ~amd64
sys-apps/sysvinit ~amd64

Code: Select all

$ emerge -s xorg-server
  
[ Results for search key : xorg-server ]
Searching...

*  x11-base/xorg-server
      Latest version available: 1.20.10-r3
      Latest version installed: 1.20.10-r2
      Size of files: 6,160 KiB
      Homepage:      https://www.x.org/wiki/ https://gitlab.freedesktop.org/xorg/xserver/xorg-server
      Description:   X.Org X servers
      License:       MIT

*  x11-apps/xinit
      Latest version available: 1.4.1-r1
      Latest version installed: 1.4.1
      Size of files: 173 KiB
      Homepage:      https://www.x.org/wiki/ https://gitlab.freedesktop.org/xorg/app/xinit
      Description:   X Window System initializer
      License:       MIT GPL-2

*  sys-apps/sysvinit
      Latest version available: 2.99
      Latest version installed: 2.97
      Size of files: 124 KiB
      Homepage:      https://savannah.nongnu.org/projects/sysvinit
      Description:   /sbin/init - parent of all processes
      License:       GPL-2

Code: Select all

$ emerge -1p xorg-server

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ~] gui-libs/display-manager-init-1.0-r3 
[ebuild     U ~] x11-base/xorg-server-1.20.10-r3 [1.20.10-r2]
[blocks b      ] =x11-base/xorg-server-1.20.10-r2 ("=x11-base/xorg-server-1.20.10-r2" is blocking gui-libs/display-manager-init-1.0-r3)
[blocks B      ] <=x11-apps/xinit-1.4.1 ("<=x11-apps/xinit-1.4.1" is blocking gui-libs/display-manager-init-1.0-r3)
[blocks B      ] <=sys-apps/sysvinit-2.98 ("<=sys-apps/sysvinit-2.98" is blocking gui-libs/display-manager-init-1.0-r3)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (x11-apps/xinit-1.4.1:0/0::gentoo, installed) pulled in by
    >=x11-apps/xinit-1.3.3-r1 required by (x11-base/xorg-server-1.20.10-r3:0/1.20.10::gentoo, ebuild scheduled for merge) USE="elogind ipv6 udev xorg xvfb -debug -dmx -doc -kdrive (-libressl) -minimal (-selinux) -suid -systemd -unwind -wayland -xcsecurity -xephyr -xnest" ABI_X86="(64)"

  (gui-libs/display-manager-init-1.0-r3:0/0::gentoo, ebuild scheduled for merge) pulled in by
    gui-libs/display-manager-init required by (x11-base/xorg-server-1.20.10-r3:0/1.20.10::gentoo, ebuild scheduled for merge) USE="elogind ipv6 udev xorg xvfb -debug -dmx -doc -kdrive (-libressl) -minimal (-selinux) -suid -systemd -unwind -wayland -xcsecurity -xephyr -xnest" ABI_X86="(64)"

  (sys-apps/sysvinit-2.97:0/0::gentoo, installed) pulled in by
    >=sys-apps/sysvinit-2.86-r6[selinux?] (>=sys-apps/sysvinit-2.86-r6) required by (sys-apps/openrc-0.42.1-r1:0/0::gentoo, installed) USE="ncurses netifrc pam (split-usr) unicode -audit -bash -debug -newnet (-prefix) (-selinux) -static-libs -sysv-utils" ABI_X86="(64)"


For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

https://wiki.gentoo.org/wiki/Handbook:X86/Working/Portage#Blocked_packages

Code: Select all

$ emerge -p display-manager-init

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ~] gui-libs/display-manager-init-1.0-r3 
[blocks B      ] <=x11-apps/xinit-1.4.1 ("<=x11-apps/xinit-1.4.1" is blocking gui-libs/display-manager-init-1.0-r3)
[blocks B      ] =x11-base/xorg-server-1.20.10-r2 ("=x11-base/xorg-server-1.20.10-r2" is blocking gui-libs/display-manager-init-1.0-r3)
[blocks B      ] <=sys-apps/sysvinit-2.98 ("<=sys-apps/sysvinit-2.98" is blocking gui-libs/display-manager-init-1.0-r3)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (gui-libs/display-manager-init-1.0-r3:0/0::gentoo, ebuild scheduled for merge) pulled in by
    display-manager-init

  (x11-base/xorg-server-1.20.10-r2:0/1.20.10::gentoo, installed) pulled in by
    x11-base/xorg-server required by @selected 


For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

https://wiki.gentoo.org/wiki/Handbook:X86/Working/Portage#Blocked_packages

But, if I now try to update, it will go -- but I'm not interested in putting that much in ~amd64. I want to be bog stable.

Code: Select all

$ emerge -uDU @world -p

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U ~] sys-apps/sysvinit-2.99 [2.97]
[ebuild     U ~] x11-apps/xinit-1.4.1-r1 [1.4.1]
[ebuild  N    ~] gui-libs/display-manager-init-1.0-r3 
[ebuild     U ~] x11-base/xorg-server-1.20.10-r3 [1.20.10-r2]
[blocks b      ] =x11-base/xorg-server-1.20.10-r2 ("=x11-base/xorg-server-1.20.10-r2" is blocking gui-libs/display-manager-init-1.0-r3)

[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]

Code: Select all

~ $ eix -e xinit
[I] x11-apps/xinit
     Available versions:  1.4.1{tbz2} ~1.4.1-r1 {twm}
     Installed versions:  1.4.1{tbz2}(06:44:04 PM 03/23/2020)(-twm)

When did you last emerge --sync? Your installed packages are out of the tree. I sync'd yesterday.

Emerge --sync, emerge -auvND #world and when all isw stelled, try again for the new ebuild. $5 to your favorite on-line charity says the blockers will be gone.

[figueroa]

When did you last emerge --sync?

If you are asking me, I synced this morning at 6 am EST and updated around noon. All four of the packages are ~amd64. Maybe tomorrow. I'm waiting for these things to be stable.

Code: Select all

$ eix -e xinit
[I] x11-apps/xinit
     Available versions:  1.4.1 {twm}
     Installed versions:  1.4.1(01:42:06 PM 07/20/2019)(-twm)
     Homepage:            https://www.x.org/wiki/ https://gitlab.freedesktop.org/xorg/app/xinit
     Description:         X Window System initializer

[Tony0945]

When did you last emerge --sync?

If you are asking me, ...

No, milomak, who had the hard blocker because of < xinit-1.4.1

[asturm]

Herer is what I put in /etc/portage/package.accept_keywords

Code: Select all

gui-libs/display-manager-init ~amd64
x11-apps/xinit ~amd64
x11-base/xorg-server ~amd64
sys-apps/sysvinit ~amd64

...

Code: Select all

$ emerge -1p xorg-server

...

Code: Select all

$ emerge -p display-manager-init

Didn't exactly this topic come up already in this thread and I told you that you couldn't update 4 packages by giving emerge only one of them to do? Btw news item was giving you the list with version atoms, why didn't you copy that? Its purpose was exactly that you would not unnecessarily get any future ~arch version as update.

[figueroa]

Didn't exactly this topic come up already in this thread and I told you that you couldn't update 4 packages by giving emerge only one of them to do?

Actually, no, not in so many words. (OK, maybe you did, a month or so ago, and that's a lot of time for things to change.)

Btw news item was giving you the list with version atoms, why didn't you copy that? Its purpose was exactly that you would not unnecessarily get any future ~arch version as update.

The versions of some of the ebuilds in the news item were already out-of-date. I was doing those pretend emerges to probe versions. Since there have been no further announcements, I was waiting for the on or about March 2nd stabilization.

The package is now in ~arch and will be available to stable users starting with 2nd March 2021.

I'm trying to not be caught by surprise.

[asturm]

The versions of some of the ebuilds in the news item were already out-of-date.

No they're not.

News item provides a copy-pasteable list.

[figueroa]

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

Code: Select all

~sys-apps/sysvinit-2.98
~x11-apps/xinit-1.4.1
~x11-base/xorg-server-1.20.10
~gui-libs/display-manager-init-1.0

I've never seen such a thing. Is this documented somewhere? I'm only familiar with the "=exact-ebuild-version ~amd64" format.

What it give me is:

Code: Select all

$ emerge -uDU @world -p

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U ~] sys-apps/sysvinit-2.98-r1 [2.97]
[ebuild     U ~] x11-apps/xinit-1.4.1-r1 [1.4.1]
[ebuild  N    ~] gui-libs/display-manager-init-1.0-r3 
[ebuild     U ~] x11-base/xorg-server-1.20.10-r3 [1.20.10-r2]

That's obviously not the exact same versions as I put in /etc/portage/package.accept_keywords.

If I use the following format:

Code: Select all

=gui-libs/display-manager-init-1.0 ~amd64
=x11-apps/xinit-1.4.1 ~amd64
=x11-base/xorg-server-1.20.10 ~amd64
=sys-apps/sysvinit-2.98 ~amd64

I don't get anything.

I've learned something new, though I don't understand how that format, i.e. "~x11-apps/xinit-1.4.1" is supposed to work and actually gives me "[ebuild U ~] x11-apps/xinit-1.4.1-r1 [1.4.1]". I don't see it reading through "man portage" or "man emerge" so feel free to rub my nose in it.

[asturm]

Code: Select all

$ emerge -uDU @world -p

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U ~] sys-apps/sysvinit-2.98-r1 [2.97]
[ebuild     U ~] x11-apps/xinit-1.4.1-r1 [1.4.1]
[ebuild  N    ~] gui-libs/display-manager-init-1.0-r3 
[ebuild     U ~] x11-base/xorg-server-1.20.10-r3 [1.20.10-r2]

That's obviously not the exact same versions as I put in /etc/portage/package.accept_keywords.

They are the same versions, but they aren't the same revisions. '~' will unmask all future revisions (which are downstream-only modifications) pinned down to that specific version.

https://wiki.gentoo.org/wiki/Knowledge_ ... onal_notes

[figueroa]

asturm: Thank you for the clarification, and especially the reference.

[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:

Code: Select all

	~sys-apps/sysvinit-2.98
	~x11-apps/xinit-1.4.1
	~x11-base/xorg-server-1.20.10
	~gui-libs/display-manager-init-1.0

did "emerge -uDU @world"

dispatch-conf showed that the settings from xdm were not migrated from xdm to display-manager-init, so I edited the settings (to lightdm).

Then, logged out to the lightdm login prompt, and CTL/ALT/F1 to log in as root and "/etc/init.d/xdm stop" followed by "etc /init.d/display-manager start" went flawlessly.

I'm migrated. Follow me.

The news item IMPLIES this whole process was to be automatic on March 2, so maybe just display-manager-init was to become stable then, but the dependencies did not. It could have been less confusing.

By trial and error (and looking at KEYWORDS in /var/db/repos/gentoo/~) on this date (3/23) for amd64, what's needed is:

Code: Select all

=sys-apps/sysvinit-2.98-r1 ~amd64
=x11-apps/xinit-1.4.1-r1 ~amd64
=x11-base/xorg-server-1.20.10-r3 ~amd64
=gui-libs/display-manager-init-1.0-r3 ~amd64

[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.

The news item IMPLIES this whole process was to be automatic on March 2

Setting dates in news items was never a good idea.

[figueroa]

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.

You are absolutely right (missing keyword). I shouldn't have done this at the end of my day. I edited my message above.

Yes, I'm being OCD with keyword specificity. I'm pretending I have some control.

The news item IMPLIES this whole process was to be automatic on March 2

Setting dates in news items was never a good idea.

[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]

Attempted to install gui-libs/display-manager-init but find there are no stable versions. Added to accept_keywords, only to find blockers.

You probably get the blockers because you have mixed keywords then.

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

It isn't stable. It has ~* keyword. If there's a mention of it being stable, its wrong.