Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 634706 - x11-apps/xinit-1.3.4-r2: can't start xdm daemon because get_options not found (and workaround)
Summary: x11-apps/xinit-1.3.4-r2: can't start xdm daemon because get_options not found...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords:
: 634776 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-10-19 01:51 UTC by jorgicio
Modified: 2017-10-21 18:30 UTC (History)
25 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jorgicio 2017-10-19 01:51:08 UTC
Hi!
Since I upgraded xinit to the 1.3.4-r2 version, it can't run the xdm daemon because some functions cannot be found (such as get_options).

However, I found a workaround to get rid of that.

Just below the line ". /lib/gentoo/functions.sh", add this line:

PATH=$PATH:/lib/rc/bin

because all binaries found on that directory are not symlinks to the openrc binary, but binaries themselves.

Now it works.

I hope it may help anyone.

Reproducible: Always
Comment 1 crocket 2017-10-19 06:03:12 UTC
My workaround was to add

ROOTPATH=$ROOTPATH:/lib64/rc/bin

to /etc/env.d/99local and execute env-update.
Comment 2 Lars Wendler (Polynomial-C) gentoo-dev 2017-10-19 07:19:10 UTC
Or simply source /lib/rc/sh/functions.sh instead of /lib/gentoo/functions.sh inside the startDM.sh script.
Comment 3 jy6x2b32pie9 2017-10-19 07:37:48 UTC
Confirming, it's horrible being unable to login after update.
Comment 4 email200202 2017-10-19 10:15:15 UTC
Same here. 

I tried to downgrade to x11-apps/xinit-1.3.4-r1 but it was removed. I was lucky to have binary package of x11-apps/xinit-1.3.4-r1 and I used it to get KDE working again.

For such critical packages, is it better to leave the previous packages for sometime?
Comment 5 Herbert Wantesh 2017-10-19 11:11:17 UTC
same here.

another workaround is to use the full path /lib64/rc/bin/get_options

please test your changes before you commit them, at least for stable ebuilds
Comment 6 Ivan 2017-10-19 11:59:21 UTC
Want to confirm it as well. Downgrading to x11-apps/xinit-1.3.4-r1 solves issue for me.

Some generic info just to fit the rules:

Portage 2.3.11 (python 3.4.6-final-0, default/linux/amd64/13.0/desktop/plasma, gcc-7.2.0, glibc-2.25-r7, 4.13.8-gentoo x86_64)
=================================================================
System uname: Linux-4.13.8-gentoo-x86_64-Intel-R-_Core-TM-_i5-2500K_CPU_@_3.30GHz-with-gentoo-2.4.1
KiB Mem:    16352632 total,    256972 free
KiB Swap:          0 total,         0 free
Timestamp of repository gentoo: Thu, 19 Oct 2017 10:30:01 +0000
Head commit of repository gentoo: a6ef526c60b1f809f9d008e5ecdba9cb28b795c1
sh bash 4.4_p12
ld GNU ld (Gentoo 2.29.1 p2) 2.29.1
app-shells/bash:          4.4_p12::gentoo
dev-lang/perl:            5.26.1::gentoo
dev-lang/python:          2.7.14::gentoo, 3.4.6::gentoo
dev-util/cmake:           3.9.4::gentoo
dev-util/pkgconfig:       0.29.2::gentoo
sys-apps/baselayout:      2.4.1-r2::gentoo
sys-apps/openrc:          0.33.1::gentoo
sys-apps/sandbox:         2.12::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69-r4::gentoo
sys-devel/automake:       1.15.1-r1::gentoo
sys-devel/binutils:       2.29.1-r1::gentoo
sys-devel/gcc:            5.4.0-r3::gentoo, 6.4.0::gentoo, 7.2.0::gentoo
sys-devel/gcc-config:     1.9.0::gentoo
sys-devel/libtool:        2.4.6-r4::gentoo
sys-devel/make:           4.2.1-r1::gentoo
sys-kernel/linux-headers: 4.13::gentoo (virtual/os-headers)
sys-libs/glibc:           2.25-r7::gentoo
Repositories:
Comment 7 Vincent de Phily 2017-10-19 12:17:51 UTC
Thanks for the workaround (first one worked for me). Lost 3 hours getting out of this mess today. I suggest you get a fix in the tree ASAP, before more people get a black screen at their next reboot.
Comment 8 email200202 2017-10-19 12:44:19 UTC
The new startDM.sh uses /lib/gentoo/functions.sh instead of /etc/init.d/functions.sh which is a link to /lib64/rc/sh/functions.sh

# diff startDM.sh-orig /etc/X11/startDM.sh
2c2
< # Copyright 1999-2011 Gentoo Foundation
---
> # Copyright 1999-2017 Gentoo Foundation
4d3
< # $Id$
10c9,14
< . /etc/init.d/functions.sh
---
> . /lib/gentoo/functions.sh


/lib/gentoo/functions.sh belongs to sys-apps/gentoo-functions package

# equery b /lib/gentoo/functions.sh 
 * Searching for /lib/gentoo/functions.sh ... 
sys-apps/gentoo-functions-0.12 (/lib/gentoo/functions.sh)

and /lib/rc/sh/functions.sh belongs to different package sys-apps/openrc

# equery b /lib/rc/sh/functions.sh 
 * Searching for /lib/rc/sh/functions.sh ... 
sys-apps/openrc-0.33 (/lib64/rc/sh/functions.sh)

The work around fix uses the directory /lib64/rc/bin which belongs to sys-apps/openrc

# equery b /lib64/rc/bin
 * Searching for /lib64/rc/bin ... 
sys-apps/openrc-0.33.1 (/lib64/rc/bin)

It seems to me that the change in startDM and the work around are going in different directions.

Am I missing something?
Comment 9 jorgicio 2017-10-19 13:50:19 UTC
(In reply to Lars Wendler (Polynomial-C) from comment #2)
> Or simply source /lib/rc/sh/functions.sh instead of /lib/gentoo/functions.sh
> inside the startDM.sh script.

Your workaround is better. I did that and it works too.

Thanks.
Comment 10 Lars Wendler (Polynomial-C) gentoo-dev 2017-10-19 15:02:57 UTC
*** Bug 634776 has been marked as a duplicate of this bug. ***
Comment 11 Rafal Kupiec 2017-10-19 15:09:12 UTC
Manually editing /etc/X11/startDM.sh and changing path from /lib/gentoo/functions.sh to /etc/init.d/functions.sh fixed the problem.


Have anyone ever tested this before committing change?!
Why have you removed 1.3.4-r1 from portage tree w/o making sure the only ebuild you left is working?
Comment 12 Larry the Git Cow gentoo-dev 2017-10-19 16:08:42 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9bd33b8105427c8f92ca509c1cf60d0bf67f7aad

commit 9bd33b8105427c8f92ca509c1cf60d0bf67f7aad
Author:     Matt Turner <mattst88@gentoo.org>
AuthorDate: 2017-10-19 16:07:07 +0000
Commit:     Matt Turner <mattst88@gentoo.org>
CommitDate: 2017-10-19 16:07:07 +0000

    x11-apps/xinit: Rev bump to -r3 after previous commit's revert
    
    Closes: https://bugs.gentoo.org/634706
    Package-Manager: Portage-2.3.8, Repoman-2.3.3
    RepoMan-Options: --force

 x11-apps/xinit/{xinit-1.3.4-r2.ebuild => xinit-1.3.4-r3.ebuild} | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
Comment 13 Matt Turner gentoo-dev 2017-10-19 16:14:52 UTC
Okay, here's what happened:

For bug 504140, wizardedit committed a patch to startDM.sh, which is in $FILESDIR and is installed by all versions of xinit (all of which are stable). I wasn't around in the four minutes between him asking for an ack on #gentoo-dev and committing it, so I didn't see it before it was committed, but when I did I noted that it modified files installed so it should have a revbump.

I incorrectly assumed that it actually worked, so I added the -r2 bump straight to stable (so users would get the new change) and dropped the old versions (so that users could not have a version that potentially different on-disk contents).

I have now reverted wizardedit's commit, and made yet another revbump (-r3) which will install the same contents as -r1 did originally.

Very sorry for the trouble.
Comment 14 PeGa! 2017-10-20 03:39:50 UTC
After many attempts I was able to bring up my system by a dirty hack in /etc/X11/startDM.sh

@Matt, I updated xinit:

*  x11-apps/xinit
      Latest version available: 1.3.4-r3
      Latest version installed: 1.3.4-r3

It still doesn't work for me.

This was my workaround:

On line 25:

PATH=$PATH:/lib/rc/bin:/lib/rc/sh

Thanks in advance.
Comment 15 Simon 2017-10-21 15:16:35 UTC
(In reply to Matt Turner from comment #13)
> Okay, here's what happened:
> 
> For bug 504140, wizardedit committed a patch to startDM.sh, which is in
> $FILESDIR and is installed by all versions of xinit (all of which are
> stable). I wasn't around in the four minutes between him asking for an ack
> on #gentoo-dev and committing it, so I didn't see it before it was
> committed, but when I did I noted that it modified files installed so it
> should have a revbump.
> 
> I incorrectly assumed that it actually worked, so I added the -r2 bump
> straight to stable (so users would get the new change) and dropped the old
> versions (so that users could not have a version that potentially different
> on-disk contents).
> 
> I have now reverted wizardedit's commit, and made yet another revbump (-r3)
> which will install the same contents as -r1 did originally.
> 
> Very sorry for the trouble.

Thanks for the info! And no problem, mistakes happen :)

I am wondering what can be done to prevent this in the future?
It seems this change was untested otherwise one would've noticed it doesn't work immediately. Ideally the test would be automated, but a manual test would be a start. Any ideas how to incorporate this?

Related to this, it seems like a review process for these changes is missing and developers can commit changes straight to the gentoo tree, is that correct?
Comment 16 Matt Turner gentoo-dev 2017-10-21 18:30:57 UTC
(In reply to Simon from comment #15)
> (In reply to Matt Turner from comment #13)
> > Okay, here's what happened:
> > 
> > For bug 504140, wizardedit committed a patch to startDM.sh, which is in
> > $FILESDIR and is installed by all versions of xinit (all of which are
> > stable). I wasn't around in the four minutes between him asking for an ack
> > on #gentoo-dev and committing it, so I didn't see it before it was
> > committed, but when I did I noted that it modified files installed so it
> > should have a revbump.
> > 
> > I incorrectly assumed that it actually worked, so I added the -r2 bump
> > straight to stable (so users would get the new change) and dropped the old
> > versions (so that users could not have a version that potentially different
> > on-disk contents).
> > 
> > I have now reverted wizardedit's commit, and made yet another revbump (-r3)
> > which will install the same contents as -r1 did originally.
> > 
> > Very sorry for the trouble.
> 
> Thanks for the info! And no problem, mistakes happen :)
> 
> I am wondering what can be done to prevent this in the future?
> It seems this change was untested otherwise one would've noticed it doesn't
> work immediately. Ideally the test would be automated, but a manual test
> would be a start. Any ideas how to incorporate this?
>
> Related to this, it seems like a review process for these changes is missing
> and developers can commit changes straight to the gentoo tree, is that
> correct?

Yes. It's not a good system. Exherbo has a gerrit instance for review, which seems to be a nice improvement over our workflow.

This problem could have been avoided by waiting a day to push the patch from the time review is requested in order to give people an opportunity to respond (which is what I told wizardedit I'd like to see). There is no substitute for actual testing though.