Created attachment 453556 [details] Xorg.0.log Xorg crash while startup.
Created attachment 453558 [details] emerge --info
Most likely one of the autorebuilds of x11-drivers/xf86-* failed because of xorg-server changes, so the intel driver didn't get autorebuilt. I don't think there's any specific bug to fix here, just need to fix the other blockers of 599976 so that emerge doesn't die before it gets to xf86-video-intel
I look closer and build xorg-server cause only rebuild of xf86-input-*, after manual rebuild xf86-video-intel xorg-server start works.
One of your xf86-input-* rebuilds died before xf86-video-intel was able to rebuild. Known bug 599938 on xf86-input-keyboard may have caused this, for example. There already is a slot operator dep for xf86-video-intel, so it *does* autorebuild. Do you have any evidence to the contrary? I don't mean to sound argumentative, but I've seen this exact same scenario play out on 2 different systems already, the keyboard driver bug killed the whole emerge so the scheduled rebuild for intel never happened.
Rebuild of xf86-input-keyboard have failed, but on list of item to emerge was only: xorg-server, xorg-drivers, and xf86-input-*, but there wasn't xf86-video-intel.
Can you attach the emerge list which shows this?
FYI all these x11-drivers/ packages inherit the same xorg-2 eclass which adds RDEPEND="x11-base/xorg-server:=" and this is what triggers the rebuilds on xorg-server's upgrade
Created attachment 453564 [details] list of packages to rebuild
I think I see what happened here-- with your VIDEO_CARDS setting and the new changes on xorg-drivers-1.19, xf86-video-intel is no longer required, it's an orphaned dependency. It will be removed on next depclean, then xorg will switch to the modesetting driver which will work.
Before update xorg-drivers have only intel flag, new xorg-drivers have intel and i965 flags, but I think xf86-video-intel should be autorebuild anyway because of intel flag.
With VIDEO_CARDS="intel i965" that driver is no longer required, you should allow depclean to remove it. Since it's no longer in the dep list, it won't get rebuilt. This is one reason it's so important to depclean after upgrades, as emerge suggests.
(In reply to lekto from comment #10) > Before update xorg-drivers have only intel flag, new xorg-drivers have intel > and i965 flags, but I think xf86-video-intel should be autorebuild anyway > because of intel flag. Beginning with xorg-drivers-1.19.0, modesetting (part of xorg-server) became the default driver for VIDEO_CARDS="i965" leaving xf86-video-intel to become an orphan to be depcleaned. For most users this will be transparent, UNLESS you specifically have intel in an xorg.conf or xorg.conf.d/*.conf file as the graphics driver. You may still do "emerge xf86-video-intel" to both rebuild it and add it to world if you choose. Otherwise change the conf.d file to use "modesetting" instead of "intel" as the driver and allow the xf86-video-intel to be depcleaned. @x11 team. Not sure if you want a news item for this as it will be for customized configurations.
(In reply to Brian Evans from comment #12) > @x11 team. Not sure if you want a news item for this as it will be for > customized configurations. Yes, I think that is a good idea.
(In reply to Brian Evans from comment #12) > For most users this will be transparent, UNLESS you specifically have intel > in an xorg.conf or xorg.conf.d/*.conf file as the graphics driver. After remove xf86-video-intel xorg start complaining about lack of intel module, then I comment line in xorg.conf.d and looks like everything start working. Thanks.
Let's leave this open for now. I would like to investigate what happens when you upgrade to 1.19.0 and xf86-video-intel becomes orphaned. If it isn't automatically rebuilt as a result of being orphaned, that's pretty unfortunate.
A subslot rebuild unfortunately doesn't happen for packages which are no longer dependencies of @world. But that is not a problem, as portage advises users after @world upgrade already to run emerge --depclean, which will remove any such packages. So I suggest doing nothing here.
I'll leave this up to x11 team to decide whether to close it, but this really shouldn't be a blocker for xorg-server-1.19, this orphan non-rebuild problem has nothing to do with that version bump specifically, it could happen on any of them
*** Bug 612992 has been marked as a duplicate of this bug. ***
Yep, doesn't seem like there's anything we can do. :\