Re: [sabayon-dev] Freeze pending

[Sławomir Nizio]

Please confirm the status of this. I suppose package flow can go as
normal now, right?

Re: [sabayon-dev] Freeze pending

[Joost Ruis]

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

Re: [sabayon-dev] Freeze pending

[Joost Ruis]

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 
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 
> 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 
>> 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 >> > 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. :)
>
>



>>>
>>>
>
>
>

Re: [sabayon-dev] Freeze pending

[Jerrod Frost]

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 
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  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 
>> 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. :)


>>>
>>>
>>>
>>
>>

Re: [sabayon-dev] Freeze pending

[Jerrod Frost]

Yes, you're correct. More focused testing occurs before the release. We are
looking for OOTB experience and making sure users don't install fresh with
broken stuff.

On Tue, Mar 13, 2018, 2:34 PM Sławomir Nizio 
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.
>
> Right, although more focused testing is being done prior to the release,
> no? :) (And the question was about that.)
>
>

Re: [sabayon-dev] Freeze pending

[Jerrod Frost]

I'm baffled by this. I just logged in. locked the screen, attempted to
unlock and it fails..
thinking I may have typo'd the password, I login as root at terminal,
change password for user, force unlock-sessions, logout, log back in as
user, lockscreen, same issue!
joost_op: it would be sure nice if we could make the sabayon installers
install packages and even enable the ability to pull updated packages from
the repositories ;D . We could also make a single ISO which lets people
choose their desktop environments and display managers :D
OK, something has broken the KDE screenlocker for fresh installs.. I'll
need to perform another fresh install for a full/proven test, but currently
I'm seeing:
kscreenlocker_greet[7391]: Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
unix_chkpwd[7411]: check pass; user unknown
unix_chkpwd[7412]: check pass; user unknown
unix_chkpwd[7412]: password check failed for user (darksurf)
kcheckpass[7410]: pam_unix(kde:auth): authentication failure; logname=
uid=1000 euid=1000 tty=:0 ruser= rhost= user=darksurf
kcheckpass[7410]: Authentication failure for darksurf (invoked by uid 1000)


Ryuno-Kim located the fix in the forms:
https://forum.sabayon.org/viewtopic.php?f=53=33995

How should we add this fix into the ISO? alter ebuild and rebuild? Curious
as to how we should handle this. We can't release with this bug since it
kills the OOTB experience.

On Sun, Mar 11, 2018 at 8:18 PM Jerrod Frost 
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  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 
>> 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. :)


>>>
>>>
>>>
>>
>>

Re: [sabayon-dev] Freeze pending

[Jerrod Frost]

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  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 
> 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 
>> 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. :)
>>>
>>>
>>
>>
>>
>
>

Re: [sabayon-dev] Freeze pending

[Joost Ruis]

 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 
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 
> 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. :)
>>
>>
>
>
>

Re: [sabayon-dev] Freeze pending

[Jerrod Frost]

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 
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. :)
>
>

Re: [sabayon-dev] Freeze pending

[Sławomir Nizio]

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. :)

Re: [sabayon-dev] Freeze pending

[Jerrod Frost]

I checked the versions in entropy that were installed vs what was in the
portage tree.

On Tue, Mar 6, 2018 at 7:27 AM Joost Ruis  wrote:

> You checked for versions without our overlay attached or what?
>
> On Tue, Mar 6, 2018 at 5:03 AM, Jerrod Frost 
> wrote:
>
>> We need to bump:
>> sys-libs/efivar (currently using .21 which isn't in portage)
>> sys-fs/btrfs-progs (currently using 4.12 which isn't in portage)
>> sys-boot/grub (currently using 2.02_beta3-r1 which isn't in portage)
>> sys-boot/efibootmgr (currently using .12 which isn't in portage)
>> sys-boot/plymouth (not sure what to do here? isn't this eventually going
>> away? Also using 0.8.9 which isn't in portage)
>> sys-apps/systemd (using 233-r3 which isn't in portage. r6 is the minimum.)
>> sys-apps/baselayout (using 2.2-r1, not in portage)
>>
>> x11-drivers/xf86-video-amdgpu-18.0.0 (needs updated, updated ebuild
>> already in portage)
>>
>> https://lists.freedesktop.org/archives/amd-gfx/2018-March/019622.html
>>
>> Some of the packages above aren't what I'd call crucial. Much of this can
>> be updated after install. ISOs are stable enough for freeze.
>>
>> I'd like to see grub, AMDGPU, and btrfs-progs updated before freeze.
>>
>> As for the rest, do we have a plan? I can see the rest being updated
>> later on.
>>
>> -Darksurf
>>
>>
>>
>>
>
>

Re: [sabayon-dev] Freeze pending

[Joost Ruis]

You checked for versions without our overlay attached or what?

On Tue, Mar 6, 2018 at 5:03 AM, Jerrod Frost 
wrote:

> We need to bump:
> sys-libs/efivar (currently using .21 which isn't in portage)
> sys-fs/btrfs-progs (currently using 4.12 which isn't in portage)
> sys-boot/grub (currently using 2.02_beta3-r1 which isn't in portage)
> sys-boot/efibootmgr (currently using .12 which isn't in portage)
> sys-boot/plymouth (not sure what to do here? isn't this eventually going
> away? Also using 0.8.9 which isn't in portage)
> sys-apps/systemd (using 233-r3 which isn't in portage. r6 is the minimum.)
> sys-apps/baselayout (using 2.2-r1, not in portage)
>
> x11-drivers/xf86-video-amdgpu-18.0.0 (needs updated, updated ebuild
> already in portage)
>
> https://lists.freedesktop.org/archives/amd-gfx/2018-March/019622.html
>
> Some of the packages above aren't what I'd call crucial. Much of this can
> be updated after install. ISOs are stable enough for freeze.
>
> I'd like to see grub, AMDGPU, and btrfs-progs updated before freeze.
>
> As for the rest, do we have a plan? I can see the rest being updated later
> on.
>
> -Darksurf
>
>
>
>