We had a problem with our dbus socket: ExecStartPost pointed to /bin/systemctl causing that command to fail. After a remerge it now looks OK:
andromeda ~ # cat /usr/lib/systemd/user/dbus.socket [Unit] Description=D-Bus User Message Bus Socket [Socket] ListenStream=%t/bus ExecStartPost=-/usr/bin/systemctl --user set-environment DBUS_SESSION_BUS_ADDRESS=unix:path=%t/bus [Install] WantedBy=sockets.target Also=dbus.service On Tue, Mar 20, 2018 at 9:23 AM, Joost Ruis <joost.r...@sabayon.org> wrote: > Just for reference, > > ============================== > this is the service file we produce now: > ============================== > > [Unit] > Description=Simple Desktop Display Manager > Documentation=man:sddm(1) man:sddm.conf(5) > Conflicts=getty@tty1.service > After=systemd-user-sessions.service systemd-logind.service > > [Service] > ExecStart=/usr/bin/sddm > Restart=always > StandardOutput=syslog > BusName=org.freedesktop.DisplayManager > > [Install] > Alias=display-manager.service > > ==================================== > This is the service file as shipped on Archlinux: > ==================================== > > [Unit] > Description=Simple Desktop Display Manager > Documentation=man:sddm(1) man:sddm.conf(5) > Conflicts=getty@tty1.service > After=systemd-user-sessions.service getty@tty1.service > plymouth-quit.service > > [Service] > ExecStart=/usr/bin/sddm > Restart=always > > [Install] > Alias=display-manager.service > > ==================================== > > So what is the real difference and let's assume the archlinux file is > correct. > > On Arch they also instruct to start after getty@tty1.service (I would > assume setting it in Conflicts would be enough) > On Arch they don't define BusName=org.freedesktop.DisplayManager. > On Arch doesn't define StandardOutput. (souldn't affect our issue) > > > On Tue, Mar 20, 2018 at 1:34 AM, Jerrod Frost <darks...@sabayonlinux.org> > wrote: > >> 3.19.18 KDE-dev.iso >> >> SDDM is still broken, now in a different way. SDDM doesn't even load on >> the live disc on its own anymore. >> >> dubs.socket: Failed at step EXEC Spawning /bin/systemctl: no such file or >> directory >> >> what did we change to get this ^^^^^ >> >> after starting sddm manually, everything appears fine, but thats because >> the race condition didn't occur. >> and konqueror also appears to be having some strange delimma. open it up, >> do a google search, press alt+F4 to close. try to open it back up... NOPE. >> konqueror[3534]: QCommandLineParser: argument list cannot be empty, it >> should contain at least the executable name >> >> to test again, I performed a >> killall konqueror >> konqueror >> ALT+F4 >> (terminal still in use. Konqueror is still running!) >> Open another terminal >> konqueror >> _IceTransSocketUNIXConnect: Cannot connect to non-local host sabayon >> _IceTransSocketUNIXConnect: Cannot connect to non-local host sabayon >> Qt: Session management error: Could not open network socket >> >> OK, what happens if I just close using the window's close button? >> Same thing. >> What about Ctrl+Q (quit) >> Same issue! >> What if its not on the live disc? >> Same issue. >> >> My advice? ditch konqueror. its a terrible web browser. we have chrome, >> then we also have firefox available for install. Nothing I can think of >> depends on konqueror. >> >> On Sun, Mar 11, 2018 at 8:18 PM Jerrod Frost <darks...@sabayonlinux.org> >> wrote: >> >>> Its testing in general. I don't just test raw images. If I see something >>> or hear complaints, I test, and file a bug where necessary. >>> the idea is we're testing all the time, not just ISOs during/after >>> freeze. >>> >>> On Sun, Mar 11, 2018 at 5:56 PM Joost Ruis <joost.r...@sabayon.org> >>> wrote: >>> >>>> obs-studio isn't part of the images. What does this have to do with >>>> image testing? >>>> >>>> On Sun, Mar 11, 2018 at 8:11 PM, Jerrod Frost < >>>> darks...@sabayonlinux.org> wrote: >>>> >>>>> As far as testing is concerned, we're testing all the time. We aren't >>>>> just testing right before or after a freeze :) . I get complaints in >>>>> single >>>>> packages every once in a while and we submit bugzilla bugs to have >>>>> packages >>>>> recompiled or upgraded. I've even gone upstream before if the ebuild >>>>> needed >>>>> updated in portage. obs-studio is a perfect example of this. I requested >>>>> the 21.0.2 revision which fixed some audio glitches and tested just >>>>> bumping >>>>> the build name/version of the ebuild which worked fine. when confirmed >>>>> they >>>>> quickly updated the ebuild in portage and we now have 21.0.2 in entropy as >>>>> well :) >>>>> >>>>> Right now, we're fairly stable. I wanted to perform a final test after >>>>> freeze to confirm there were no strange quirks that were missed that would >>>>> impact the OOTB experience for our users. we have 1 week (till end of day >>>>> saturday) to finish testing and stamp approval for release. >>>>> >>>>> On Fri, Mar 9, 2018 at 5:36 PM Sławomir Nizio < >>>>> slawomir.ni...@sabayon.org> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> We've been talking on IRC and figured some pieces of information >>>>>> related >>>>>> to actions might be missing here. >>>>>> >>>>>> So, >>>>>> >>>>>> Has testing started? >>>>>> How is it going? >>>>>> Is it blocked by anything? Are you waiting for someone or something? >>>>>> Is there help needed with something? >>>>>> >>>>>> Let's have it straight where's the ball now. :) >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >> >> >> > > > >
