Re: gnome crashes after today upgrade

2018-02-06 Thread Peter Hutterer 
On Wed, Feb 07, 2018 at 02:12:52PM +1000, Peter Hutterer wrote:
> xkeyboard-config-2.23.1-1.fc28 is building and seems to fix the issue
> https://koji.fedoraproject.org/koji/taskinfo?taskID=24771380

First build failed, successful one is:
https://koji.fedoraproject.org/koji/taskinfo?taskID=24772701

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: gnome crashes after today upgrade

2018-02-06 Thread Peter Hutterer 
On Wed, Feb 07, 2018 at 12:42:54AM +, Tomasz Kłoczko wrote:
> On 6 February 2018 at 19:33, Bruno Wolff III  wrote:
> 
> > On Fri, Feb 02, 2018 at 20:35:25 +,
> >  Tomasz Kłoczko  wrote:
> >
> >> Hi,
> >>
> >> Looks like today updates are trashing gnome almost completely.
> >> gdm-x-session cannot setup XKB mapping. gnome-shell is core dumping ..
> >>
> >> "journalctl -xe" output is in attachment.
> >>
> >
> > If this is rawhide, you might try downgrading m17n-db* . On one machine
> > the latest version is causing lots of applications to crash. On other
> > machines it doesn't happen and I don't know what the difference is. I'm
> > hoping the gcc8 rebuild will fix things when it happens. Right now I don't
> > have much for the maintainer to go on to try to fix things.
> >
> 
> m17n-db has nothing to do with xkb.
> I've done something different.
> I found that m17n-db is only required by m17n-lib package and m17n-lib is
> required only by ibus-m17n, and nothing requires ibus-m17n.
> So I've removed all those three packages and after logout-> loging (under
> gnome or Xfce; both under X11) still gdm has been failing with *exactly*
> the same error messages.
> 
> xkb is about keyboard mappings withing working X11 server.
> 
> Nevertheless just found what is causing tose xkb errors.
> I've installed xorg-x11-xkb-extras to have the access to setxkbmap command
> and on executing:
> 
> [tkloczko@domek ~]$ setxkbmap -v pl
> Warning! Multiple definitions of keyboard layout
>  Using command line, ignoring X server
> Trying to build keymap using the following components:
> keycodes:   evdev+aliases(qwerty)
> types:  complete
> compat: complete
> symbols:pc+pl+inet(evdev)
> geometry:   pc(pc105)
> Error loading new keyboard description
> [tkloczko@domek ~]$ strace -e trace=file setxkbmap -v pl
> execve("/usr/bin/setxkbmap", ["setxkbmap", "-v", "pl"], 0x7ffcce6b2830 /*
> 46 vars */) = 0
> access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or
> directory)
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libxkbfile.so.1", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libX11.so.6", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libxcb.so.1", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libXau.so.6", O_RDONLY|O_CLOEXEC) = 3
> access("/run/user/1000/gdm/Xauthority", R_OK) = 0
> openat(AT_FDCWD, "/run/user/1000/gdm/Xauthority", O_RDONLY) = 4
> Warning! Multiple definitions of keyboard layout
>  Using command line, ignoring X server
> openat(AT_FDCWD, "./rules/evdev-C.lst", O_RDONLY) = -1 ENOENT (No such file
> or directory)
> openat(AT_FDCWD, "./rules/evdev.lst", O_RDONLY) = -1 ENOENT (No such file
> or directory)
> openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev-C.lst", O_RDONLY) = -1
> ENOENT (No such file or directory)
> openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev.lst", O_RDONLY) = 4
> openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev-C", O_RDONLY) = -1 ENOENT
> (No such file or directory)
> openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev", O_RDONLY) = 4
> 
> Next was rpm query:
> 
> [tkloczko@domek ~]$ rpm -qif /usr/share/X11/xkb/rules/evdev
> Name: xkeyboard-config
> Version : 2.23
> Release : 1.fc28
> Architecture: noarch
> Install Date: Fri 02 Feb 2018 03:10:22 GMT
> Group   : Unspecified
> Size: 5804719
> License : MIT
> Signature   : RSA/SHA256, Wed 31 Jan 2018 09:07:03 GMT, Key ID
> e08e7e629db62fb1
> Source RPM  : xkeyboard-config-2.23-1.fc28.src.rpm
> Build Date  : Wed 31 Jan 2018 09:06:48 GMT   HERE 
> Build Host  : buildvm-ppc64le-15.ppc.fedoraproject.org
> Relocations : (not relocatable)
> Packager: Fedora Project
> Vendor  : Fedora Project
> URL : http://www.freedesktop.org/wiki/Software/XKeyboardConfig
> Summary : X Keyboard Extension configuration data
> Description :
> This package contains configuration data used by the X Keyboard Extension
> (XKB),
> which allows selection of keyboard layouts when using a graphical interface..
> 
> As long as upgrade 2.23 has been done around the time when mine problems
> with xkb started I've downloaded xkeyboard-config-2.22 from f27 and after
> downgrade:
> 
> [tkloczko@domek ~]$ setxkbmap -v pl
> Warning! Multiple definitions of keyboard layout
>  Using command line, ignoring X server
> Trying to build keymap using the following components:
> keycodes:   evdev+aliases(qwerty)
> types:  complete
> compat: complete
> symbols:pc+pl+inet(evdev)
> geometry:   pc(pc105)
> [tkloczko@domek ~]$ łóćźęśźż
> 
> So I'm able now to enter Polish characters :)
> 
> So looks like at least something is wrong with xkeyboard-config-2.23.

yep, thanks, there was a typo in the polish layout. Was fixed upstream, I
just don't use that layout very often ;)

xkeyboard-c

Re: gnome crashes after today upgrade

2018-02-06 Thread Tomasz Kłoczko 
On 6 February 2018 at 19:33, Bruno Wolff III  wrote:

> On Fri, Feb 02, 2018 at 20:35:25 +,
>  Tomasz Kłoczko  wrote:
>
>> Hi,
>>
>> Looks like today updates are trashing gnome almost completely.
>> gdm-x-session cannot setup XKB mapping. gnome-shell is core dumping ..
>>
>> "journalctl -xe" output is in attachment.
>>
>
> If this is rawhide, you might try downgrading m17n-db* . On one machine
> the latest version is causing lots of applications to crash. On other
> machines it doesn't happen and I don't know what the difference is. I'm
> hoping the gcc8 rebuild will fix things when it happens. Right now I don't
> have much for the maintainer to go on to try to fix things.
>

m17n-db has nothing to do with xkb.
I've done something different.
I found that m17n-db is only required by m17n-lib package and m17n-lib is
required only by ibus-m17n, and nothing requires ibus-m17n.
So I've removed all those three packages and after logout-> loging (under
gnome or Xfce; both under X11) still gdm has been failing with *exactly*
the same error messages.

xkb is about keyboard mappings withing working X11 server.

Nevertheless just found what is causing tose xkb errors.
I've installed xorg-x11-xkb-extras to have the access to setxkbmap command
and on executing:

[tkloczko@domek ~]$ setxkbmap -v pl
Warning! Multiple definitions of keyboard layout
 Using command line, ignoring X server
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:  complete
compat: complete
symbols:pc+pl+inet(evdev)
geometry:   pc(pc105)
Error loading new keyboard description
[tkloczko@domek ~]$ strace -e trace=file setxkbmap -v pl
execve("/usr/bin/setxkbmap", ["setxkbmap", "-v", "pl"], 0x7ffcce6b2830 /*
46 vars */) = 0
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or
directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libxkbfile.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libX11.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libxcb.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libXau.so.6", O_RDONLY|O_CLOEXEC) = 3
access("/run/user/1000/gdm/Xauthority", R_OK) = 0
openat(AT_FDCWD, "/run/user/1000/gdm/Xauthority", O_RDONLY) = 4
Warning! Multiple definitions of keyboard layout
 Using command line, ignoring X server
openat(AT_FDCWD, "./rules/evdev-C.lst", O_RDONLY) = -1 ENOENT (No such file
or directory)
openat(AT_FDCWD, "./rules/evdev.lst", O_RDONLY) = -1 ENOENT (No such file
or directory)
openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev-C.lst", O_RDONLY) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev.lst", O_RDONLY) = 4
openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev-C", O_RDONLY) = -1 ENOENT
(No such file or directory)
openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev", O_RDONLY) = 4

Next was rpm query:

[tkloczko@domek ~]$ rpm -qif /usr/share/X11/xkb/rules/evdev
Name: xkeyboard-config
Version : 2.23
Release : 1.fc28
Architecture: noarch
Install Date: Fri 02 Feb 2018 03:10:22 GMT
Group   : Unspecified
Size: 5804719
License : MIT
Signature   : RSA/SHA256, Wed 31 Jan 2018 09:07:03 GMT, Key ID
e08e7e629db62fb1
Source RPM  : xkeyboard-config-2.23-1.fc28.src.rpm
Build Date  : Wed 31 Jan 2018 09:06:48 GMT   HERE 
Build Host  : buildvm-ppc64le-15.ppc.fedoraproject.org
Relocations : (not relocatable)
Packager: Fedora Project
Vendor  : Fedora Project
URL : http://www.freedesktop.org/wiki/Software/XKeyboardConfig
Summary : X Keyboard Extension configuration data
Description :
This package contains configuration data used by the X Keyboard Extension
(XKB),
which allows selection of keyboard layouts when using a graphical interface.

As long as upgrade 2.23 has been done around the time when mine problems
with xkb started I've downloaded xkeyboard-config-2.22 from f27 and after
downgrade:

[tkloczko@domek ~]$ setxkbmap -v pl
Warning! Multiple definitions of keyboard layout
 Using command line, ignoring X server
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:  complete
compat: complete
symbols:pc+pl+inet(evdev)
geometry:   pc(pc105)
[tkloczko@domek ~]$ łóćźęśźż

So I'm able now to enter Polish characters :)

So looks like at least something is wrong with xkeyboard-config-2.23.
If no one will try to check what has been changed in 2.23 tomorrow will
continue investigation (at the moment have no time to raise ticket).

A .. BTW: looks like m17n-{db,lib} and ibus-m17n are not needed and
everything is working perfectly fine (doesn't matter am I using us, gb or
pl xkb mapping).

Another conclusion: I think that using xkbcomp compile text definition to
binary file and use those binary files is a bit

Re: gnome crashes after today upgrade

2018-02-06 Thread Bruno Wolff III 

On Fri, Feb 02, 2018 at 20:35:25 +,
 Tomasz Kłoczko  wrote:

Hi,

Looks like today updates are trashing gnome almost completely.
gdm-x-session cannot setup XKB mapping. gnome-shell is core dumping ..

"journalctl -xe" output is in attachment.


If this is rawhide, you might try downgrading m17n-db* . On one machine 
the latest version is causing lots of applications to crash. On other 
machines it doesn't happen and I don't know what the difference is. 
I'm hoping the gcc8 rebuild will fix things when it happens. Right now I 
don't have much for the maintainer to go on to try to fix things.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: gnome crashes after today upgrade

2018-02-06 Thread Tomasz Kłoczko 
On 6 February 2018 at 11:48, Sam Varshavchik  wrote:
[..]

> Never had xfce4-notifyd crash on me. Not sure what mission-control is. I
> have chrome running on my Ubuntu laptop, also XFCE desktop, never had it
> crash either.
>

Thiis process is part of the telepathy-mission-control package. It crashed
when I've been trying to use polari Gnome IRC client under xfce.
Looks like this crach has nothing to do with xfce per se, however xfce4-notifyd
looks like it is part of of te xfce.

More details about this process crashes:

Feb 06 10:41:23 domek xfce4-notifyd[23486]: malloc_consolidate(): invalid
chunk size
Feb 06 10:41:29 domek systemd[1]: Started Process Core Dump (PID 30009/UID
0).
-- Subject: Unit systemd-coredump@4-30009-0.service has finished start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit systemd-coredump@4-30009-0.service has finished starting up.
-- 
-- The start-up result is RESULT.
Feb 06 10:41:32 domek systemd[5399]: xfce4-notifyd.service: Main process
exited, code=dumped, status=6/ABRT
Feb 06 10:41:36 domek dbus-daemon[5457]: [session uid=1000 pid=5457]
Activating via systemd: service name='org.freedesktop.Notifications'
unit='xfce4-notifyd.service' requested by ':1.42' (uid=1000 pid=5534
comm="/usr/share/skypeforlinux/skypeforlinux --executed-")
Feb 06 10:41:32 domek systemd[5399]: xfce4-notifyd.service: Failed with
result 'core-dump'.
Feb 06 10:41:36 domek systemd[5399]: Starting XFCE notifications service...
-- Subject: Unit UNIT has begun start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit UNIT has begun starting up.

And gdb stack back trace:

Core was generated by `/usr/lib64/xfce4/notifyd/xfce4-notifyd'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50   return ret;
[Current thread is 1 (Thread 0x7f1b8aa59a80 (LWP 23486))]
(gdb) bt
#0  0x7f1b871f0f6b in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f1b871db591 in __GI_abort () at abort.c:79
#2  0x7f1b87233cab in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7f1b8733d95e "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x7f1b8723a1dc in malloc_printerr (str=str@entry=0x7f1b8733f208
"malloc_consolidate(): invalid chunk size") at malloc.c:5353
#4  0x7f1b8723a4da in malloc_consolidate (av=av@entry=0x7f1b87573c40
) at malloc.c:
#5  0x7f1b8723d0a0 in _int_malloc (av=av@entry=0x7f1b87573c40
, bytes=bytes@entry=1352) at malloc.c:3706
#6  0x7f1b8723f5f2 in __libc_calloc (n=n@entry=1,
elem_size=elem_size@entry=1352) at malloc.c:3439
#7  0x7f1b877e9511 in g_malloc0 (n_bytes=n_bytes@entry=1352) at
gmem.c:124
#8  0x7f1b89844ea3 in _gtk_css_lookup_new (relevant=relevant@entry=0x0)
at gtkcsslookup.c:32
#9  0x7f1b898596b3 in gtk_css_static_style_new_compute
(provider=0x7f1b6c00e900, matcher=matcher@entry=0x7fffcfbfff40,
parent=parent@entry=0x0)
at gtkcssstaticstyle.c:183
#10 0x7f1b898475b4 in gtk_css_node_create_style (cssnode=0x5640f830aaa0
[GtkCssWidgetNode]) at gtkcssnode.c:371
#11 0x7f1b898475b4 in gtk_css_node_real_update_style
(cssnode=0x5640f830aaa0 [GtkCssWidgetNode], change=135, timestamp=0,
style=0x5640f813a040 [GtkCssStaticStyle]) at gtkcssnode.c:425
#12 0x7f1b898463a4 in gtk_css_node_ensure_style
(cssnode=cssnode@entry=0x5640f830aaa0
[GtkCssWidgetNode], current_time=0) at gtkcssnode.c:1007
#13 0x7f1b898465b6 in gtk_css_node_ensure_style
(current_time=, cssnode=0x5640f830aaa0 [GtkCssWidgetNode])
at gtkcssnode.c:992
#14 0x7f1b898465b6 in gtk_css_node_get_style (cssnode=0x5640f830aaa0
[GtkCssWidgetNode]) at gtkcssnode.c:1033
#15 0x7f1b899a890b in gtk_style_context_lookup_style
(context=0x5640f8172f90 [GtkStyleContext]) at gtkstylecontext.c:493
#16 0x7f1b899a890b in _gtk_style_context_peek_style_property
(context=context@entry=0x5640f8172f90 [GtkStyleContext],
widget_type=94837039369344, pspec=0x7f1b680041e0 [GParamDouble]) at
gtkstylecontext.c:1635
#17 0x7f1b89a5320c in gtk_widget_style_get_valist
(widget=widget@entry=0x5640f81242f0
[XfceNotifyWindow],
first_property_name=first_property_name@entry=0x5640f674cd35
"padding", var_args=var_args@entry=0x7fffcfc00160) at gtkwidget.c:13248
#18 0x7f1b89a53598 in gtk_widget_style_get (widget=0x5640f81242f0
[XfceNotifyWindow],
first_property_name=first_property_name@entry=0x5640f674cd35
"padding")
at gtkwidget.c:13286
#19 0x5640f67493cd in xfce_notify_window_init (window=0x5640f81242f0
[XfceNotifyWindow]) at xfce4-notifyd/xfce-notify-window.c:227
#20 0x7f1b87ae22c5 in g_type_create_instance (type=94837039369344) at
gtype.c:1866
#21 0x7f1b87ac2518 in g_object_new_internal
(class=class@entry=0x5640f8112820,
params=params@entry=0x7fffcfc00570, n_params=n_params@entry=1) at
gobject.c:1797
#22 0x7f1b87ac445e in g_object_new_valist (object_type=,
first_pro

Re: gnome crashes after today upgrade

2018-02-06 Thread Sam Varshavchik 

Tomasz Kłoczko writes:

-- after only 3-4h on m primary desktop I've been able to collect descent  
number of core files




# ls -la /var/lib/systemd/coredump/*
-rw-r-+ 1 root root 1628938240 Feb  6 03:28  
/var/lib/systemd/coredump/core.chrome. 
1000.9b34b2ba89514d86a302484519bf2a53.14303.151788763700
-rw-r-+ 1 root root   37933056 Feb  6 04:10  
/var/lib/systemd/coredump/core.mission-control. 
1000.ad37f99486c24da58887b80804c84322.9243.151789023300


-rw-r-+ 1 root root   28282880 Feb  6 03:34  
/var/lib/systemd/coredump/core.xfce4-notifyd. 
1000.ad37f99486c24da58887b80804c84322.2398.151788803900


-rw-r-+ 1 root root   32505856 Feb  6 04:27  
/var/lib/systemd/coredump/core.xfce4-notifyd. 
1000.ad37f99486c24da58887b80804c84322.5645.151789125800


Never had xfce4-notifyd crash on me. Not sure what mission-control is. I  
have chrome running on my Ubuntu laptop, also XFCE desktop, never had it  
crash either.




pgp7XJSqwqUAh.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: gnome crashes after today upgrade

2018-02-05 Thread Tomasz Kłoczko 
On 4 February 2018 at 01:51, Sam Varshavchik  wrote:

> Tomasz Kłoczko writes:
>
> On 3 February 2018 at 22:55, Richard Shaw > com>hobbes1...@gmail.com> wrote:
>>
>>Any news on the cause? I'm waiting to update until this is figured
>> out...
>>
>> Still don't see any update about the issue.
>> It is really pain in the a*s that Linux still has no good support to
>> handle
>>
>
> One option that's available to you is to switch to another desktop. No
> issues here, whatsoever, on my XFCE desktop.
>
> I replaced Gnome with XFCE on all my desktops a number of years ago, and
> haven't looked back.
>

I gave the chance for xfce and here are some my conclusions:
- Pros:
-- much lower memory consumption. Difference is about 1.2GB less RAM. On
one of my laptops with only 8GB RAM it makes really big difference

- Cons:
-- after only 3-4h on m primary desktop I've been able to collect descent
number of core files

# ls -la /var/lib/systemd/coredump/*
-rw-r-+ 1 root root 1628938240 Feb  6 03:28
/var/lib/systemd/coredump/core.chrome.1000.9b34b2ba89514d86a302484519bf2a53.14303.151788763700
-rw-r-+ 1 root root   37933056 Feb  6 04:10
/var/lib/systemd/coredump/core.mission-control.1000.ad37f99486c24da58887b80804c84322.9243.151789023300
-rw-r-+ 1 root root   28282880 Feb  6 03:34
/var/lib/systemd/coredump/core.xfce4-notifyd.1000.ad37f99486c24da58887b80804c84322.2398.151788803900
-rw-r-+ 1 root root   32505856 Feb  6 04:27
/var/lib/systemd/coredump/core.xfce4-notifyd.1000.ad37f99486c24da58887b80804c84322.5645.151789125800

and only this does not look good :/
Chrome as usually is affected by memory leaks which are causing that on
some web pages suddenly some chrome process suddenly puffs and crashes by
passing max memory limit. Of course this issue has nothing to do with xfce.
Other cores may be caused by the same cause(s) which is(are) now affecting
Gnome desktop.

-- xfce needs a lot of work
--- base @Xfce kickstart group drags a lot of dependencies which are not
essential. It wold be IMO good to create something @Xfce-minimal group
--- I've installed xfce by choosing initially set of packages and I've anup
on desktop without window manage so it wold be good to add to one of the
core xfce package "Require: windowmanager" and add to all packages
"Provides: windowmanager" if xfce can be used without xfwm4 or add straight
Requires: xfwm4
My my minimal set of xfce packages:

libxfce4ui
libxfce4util
xfce4-appfinder
xfce4-notifyd
xfce4-panel
xfce4-power-manager
xfce4-screenshooter
xfce4-session
xfce4-session-engines
xfce4-settings
xfce4-taskmanager
xfce4-terminal
xfce4-xkb-plugin
xfce-polkit
xfconf
xfdesktop
xfwm4

I'm opened on any suggestions about what more could be added to such set :)

-- trying to launch any gnome application still is affected by already
discussed in this thread issues.
--- it is not possible to tart working wit xfce desktop because during
first time xfce start it is necessary to answer on few questions. I thing
that it is generally wrong strategy because everything should start with
some default settings. Whatever someone will like/dislike still is possible
to customize later.
--- I think that it wold be really good to prepare initial default desktop
layout to mimic default Gnome desktop. This wold make migration from Gnome
to xfce much smoother.

-- I thing that using xfce4 in many packages should be replaced by just
xfce This will make future transitions to next major version easier. I see
that already some number of xfce packages is not using this "4" in package
names.

- Other:
Looks like changing xkb keyboard layout which started with crashing
gnome-shell under gome is not caused by gnome-shell but by gdm issue. from
logs:

Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: (**) Option
"xkb_layout" "pl,gb,us"
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: (**) Option
"xkb_variant" ",,"
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: syntax error: line
500 of pl
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: The XKEYBOARD
keymap compiler (xkbcomp) reports:
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: > Error:
Error interpreting include file "pl"
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: >
 Exiting
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: >
 Abandoning symbols file "default"
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: Errors from xkbcomp
are not fatal to the X server
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: (EE) Error loading
keymap /tmp/server-0.xkm
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: (EE) XKB: Failed to
load keymap. Loading default keymap instead.

Cannot find which one xkb map is used in above case. After uncompressing
/lib/kbd/keymaps/xkb/pl.map.gz I see that this file has only 199 lines so
this error message must be about some other (text?) file. So Still I cannot
change keyboard layout to pl :/

kloczek
-- 
Tomasz Kłocz

Re: gnome crashes after today upgrade

2018-02-05 Thread Chris Murphy 
On Sat, Feb 3, 2018 at 5:53 PM, Tomasz Kłoczko  wrote:
> On 3 February 2018 at 22:55, Richard Shaw  wrote:
>>
>> Any news on the cause? I'm waiting to update until this is figured out...
>
>
> Still don't see any update about the issue.
> It is really pain in the a*s that Linux still has no good support to handle
> such cases like it is on for example on Solaris where is possible to
> generate using zfs snapshots and cloning separated BEs (boot environments)
> on each upgrade or even new package install which adds to grub menu new boot
> entry which allows preserve 100% state from before any packages operations.

It's not a Linux limitation, the infrastructure is there. SUSE has had
state preserving rollbacks for several years. Their Btrfs patches for
GRUB, which I think are now upstream so we might also have them,
discover Btrfs snapshots made by snapper before and after every
package change, and build menu entries for each snapshot. Pick one,
and you get a read only one time rollback to the chosen snapshot.

Fedora repo does have both snapper and a dnf snapper plugin that'll
take snapshots of rootfs before any dnf update, and it's possible to
use snapper to rollback - I've only ever done it with a Btrfs rootfs
but I think snapper also supports LVM thinly provisioned volumes and
snapshots. The gotcha compared to what SUSE folks are doing is, on
Fedora it's possible (likely) to get a disconnect between the kernels
located in /boot vs the modules installed on the rolledback rootfs,
because /boot is not snapshot along with rootfs on Fedora since
they're separate file systems. So that'll inevitably snare things
unless you manually 'cp -a --reflink' copy the latest modules dir from
a current tree into a rolledback tree. And the reason for this is the
Fedora installer enforces /boot being on a plain ext4 or XFS volume,
it can't be on Btrfs due to a now 6+ year old grubby bug that causes
grubby to not update grub.cfg if /boot is a Btrfs subvolume.


> Just checked a bit dnf documentation and seems that dnf supports rollback
> operation. However as long as Fedora repo holds only latest versions of the
> each package I'm only curious how it is handled as rpm no longer supports
> repackage and rollback operations (?).

I've never tried doing rollbacks from dnf itself. If I need to
rollback, I just pick one I'm doing to rollback to, update the fstab
inside that snapshot to reflect the correct snapshot/subvolume name
used by the subvol= mount option, reboot, and then I manually edit the
boot entry's rootflags=subvol= parameter to reflect the name of the
snapshot I want to boot. Done, I've rolled back.

Of course you've just rolled back everything except home. So even your
journal log is rolledback on Fedora since it's located in the root
subvolume, whereas on SUSE they've got one of the longest fstabs
mankind has imagined, in order to carve out with a scalpel exactly
what is and is not subject to rollbacks.


>
> Can someone share some details how to use dnf rollback and/or is it now
> supported by Fedora rawhide?
> Issues like this one with crashing gnome may happen always an no one should
> be bashing anyone for such faults as rawhide is devel by definition however
> details about how system needs to be prepared to handle rollback using dnf
> are quite important.

I'm seeing it in Fedora 27.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: gnome crashes after today upgrade

2018-02-04 Thread Tomasz Kłoczko 
On 4 February 2018 at 07:00, Samuel Sieb  wrote:

> On 02/02/2018 12:55 PM, Chris Murphy wrote:
>
>> Yeah I'm getting a bunch of clutter messages as well as many lines of
>> gnome shell desktop related stack traces. But there is nothing listed
>> by coredumpctl, or abrt.
>>
>>
>> Feb 02 13:51:31 f27h.localdomain org.gnome.Shell.desktop[1612]: ==
>> Stack trace for context 0x557b7ae9d000 ==
>>
>
> The gnome shell related stack traces have been going for a while. They're
> really annoying, but not fatal.  However, there is an issue with the Places
> menu extension that cause gnome shell to crash when a USB device is plugged
> in and also other situations.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1538493


In my case it is not necessary to do anything around USB.
Actually they are fatal.
Setting keyboard mapping is not working at all (I'm using as primary Polish
programmer kbd mapping).
Polari IRC client is not able to communicate with shell and by this is
completely useless (after joining channels after |1 min everything
disconnects from iRC server).
Whole desktop initiates incredibly slow (about maybe even 10 times longer
than it was before).
Every 10-20 min shell is dying completely and until it will be not
restarted it is not possible to do anything.

Just started tracing files operations using "strace -fe trace=file -p
" and found that gnome-shell is trying to stat() directories which it
shouldn't be trying to stat()

[pid 25382] stat("/usr/share/pixmaps/gnome", 0x7ffe80cddd40) = -1 ENOENT
(No such file or directory)
[pid 25382] stat("/usr/local/share/pixmaps/gnome", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/share/icons/gnome", {st_mode=S_IFDIR|0755,
st_size=140, ...}) = 0
[pid 25382] stat("/usr/local/share/icons/gnome", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/home/tkloczko/.icons/gnome", 0x7ffe80cddd40) = -1 ENOENT
(No such file or directory)
[pid 25382] stat("/home/tkloczko/.local/share/icons/gnome", 0x7ffe80cddd40)
= -1 ENOENT (No such file or directory)
[pid 25382] stat("/home/tkloczko/.local/share/icons/Adwaita",
0x7ffe80cddd40) = -1 ENOENT (No such file or directory)
[pid 25382] stat("/home/tkloczko/.icons/Adwaita", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/local/share/icons/Adwaita", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/share/icons/Adwaita", {st_mode=S_IFDIR|0755,
st_size=222, ...}) = 0
[pid 25382] stat("/usr/local/share/pixmaps/Adwaita", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/share/pixmaps/Adwaita", 0x7ffe80cddd40) = -1 ENOENT
(No such file or directory)
[pid 25382] stat("/home/tkloczko/.local/share/icons/hicolor",
{st_mode=S_IFDIR|0700, st_size=58, ...}) = 0
[pid 25382] stat("/home/tkloczko/.icons/hicolor", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/local/share/icons/hicolor", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/share/icons/hicolor", {st_mode=S_IFDIR|0755,
st_size=270, ...}) = 0
[pid 25382] stat("/usr/local/share/pixmaps/hicolor", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/share/pixmaps/hicolor", 0x7ffe80cddd40) = -1 ENOENT
(No such file or directory)
[pid 25382] stat("/home/tkloczko/.local/share/icons",
{st_mode=S_IFDIR|0700, st_size=14, ...}) = 0
[pid 25382] stat("/home/tkloczko/.icons", 0x7ffe80cddd40) = -1 ENOENT (No
such file or directory)
[pid 25382] stat("/usr/local/share/icons", 0x7ffe80cddd40) = -1 ENOENT (No
such file or directory)
[pid 25382] stat("/usr/share/icons", {st_mode=S_IFDIR|0755, st_size=120,
...}) = 0
[pid 25382] stat("/usr/local/share/pixmaps", 0x7ffe80cddd40) = -1 ENOENT
(No such file or directory)
[pid 25382] stat("/usr/share/pixmaps", {st_mode=S_IFDIR|0755, st_size=944,
...}) = 0
[pid 25382] openat(AT_FDCWD, "/proc/self/stat", O_RDONLY) = 25
[pid 25382] openat(AT_FDCWD, "/proc/self/stat", O_RDONLY) = 25
[pid 25382] stat("/home/tkloczko/.local/share/sounds",
{st_mode=S_IFDIR|0700, st_size=0, ...}) = 0
[pid 25382] stat("/usr/local/share/sounds", 0x7ffe80cde5e0) = -1 ENOENT (No
such file or directory)
[pid 25382] stat("/usr/share/sounds", {st_mode=S_IFDIR|0755, st_size=86,
...}) = 0

Of course above is not a cause of current crashes but it would be good to
patch gnome-shell or some gnome libraries which are trying to search cross
some of above directories. and
Looks like gnome-shell is doing sequence of those stats regularly (why?)

Just checked what has been changed on my system at 31 Jan and I found:

# rpm -qa --qf "%{INSTALLTIME:date} %{NAME}\n" | grep "31 Jan 2018" | grep
-v debuginfo | sort -k 7 | grep g
Wed 31 Jan 2018 23:34:25 GMT compat-gdbm
Wed 31 Jan 2018 23:13:41 GMT dbus-glib
Wed 31 Jan 2018 23:28:13 GMT dbus-glib-devel
Wed 31 Jan 2018 23:15:20 GMT gdbm
Wed 31 Jan 2018 23:13:31 GMT gjs<< here
Wed 31 Jan 2018 23:28:34 GMT gjs-deve

Re: gnome crashes after today upgrade

2018-02-03 Thread Samuel Sieb 

On 02/02/2018 12:55 PM, Chris Murphy wrote:

Yeah I'm getting a bunch of clutter messages as well as many lines of
gnome shell desktop related stack traces. But there is nothing listed
by coredumpctl, or abrt.


Feb 02 13:51:31 f27h.localdomain org.gnome.Shell.desktop[1612]: ==
Stack trace for context 0x557b7ae9d000 ==


The gnome shell related stack traces have been going for a while. 
They're really annoying, but not fatal.  However, there is an issue with 
the Places menu extension that cause gnome shell to crash when a USB 
device is plugged in and also other situations.


https://bugzilla.redhat.com/show_bug.cgi?id=1538493
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: gnome crashes after today upgrade

2018-02-03 Thread Sam Varshavchik 

Tomasz Kłoczko writes:

On 3 February 2018 at 22:55, Richard Shaw  
hobbes1...@gmail.com> wrote:


   Any news on the cause? I'm waiting to update until this is figured out...

Still don't see any update about the issue.
It is really pain in the a*s that Linux still has no good support to handle


One option that's available to you is to switch to another desktop. No  
issues here, whatsoever, on my XFCE desktop.


I replaced Gnome with XFCE on all my desktops a number of years ago, and  
haven't looked back.


pgpUl344AnHyE.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: gnome crashes after today upgrade

2018-02-03 Thread Tomasz Kłoczko 
On 3 February 2018 at 22:55, Richard Shaw  wrote:

> Any news on the cause? I'm waiting to update until this is figured out...
>

Still don't see any update about the issue.
It is really pain in the a*s that Linux still has no good support to handle
such cases like it is on for example on Solaris where is possible to
generate using zfs snapshots and cloning separated BEs (boot environments)
on each upgrade or even new package install which adds to grub menu new
boot entry which allows preserve 100% state from before any packages
operations.
Just checked a bit dnf documentation and seems that dnf supports rollback
operation. However as long as Fedora repo holds only latest versions of the
each package I'm only curious how it is handled as rpm no longer supports
repackage and rollback operations (?).

Can someone share some details how to use dnf rollback and/or is it now
supported by Fedora rawhide?
Issues like this one with crashing gnome may happen always an no one should
be bashing anyone for such faults as rawhide is devel by definition however
details about how system needs to be prepared to handle rollback using dnf
are quite important.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: gnome crashes after today upgrade

2018-02-03 Thread Richard Shaw 
Any news on the cause? I'm waiting to update until this is figured out...

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: gnome crashes after today upgrade

2018-02-02 Thread Chris Murphy 
Yeah I'm getting a bunch of clutter messages as well as many lines of
gnome shell desktop related stack traces. But there is nothing listed
by coredumpctl, or abrt.


Feb 02 13:51:31 f27h.localdomain org.gnome.Shell.desktop[1612]: ==
Stack trace for context 0x557b7ae9d000 ==
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

gnome crashes after today upgrade

2018-02-02 Thread Tomasz Kłoczko 
Hi,

Looks like today updates are trashing gnome almost completely.
gdm-x-session cannot setup XKB mapping. gnome-shell is core dumping ..

"journalctl -xe" output is in attachment.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *


log.txt.gz
Description: GNU Zip compressed data
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org