- openSUSE GNOME

[opensuse-gnome] GNOME:Next - start building 3.21.x
by Bjørn Lie 30 Apr '16

30 Apr '16

Early heads up for the brave people using GNOME:Next. We will start building the next unstable (3.21.x) round shortly, so expect that the ride might become bumpy. So if that is a deal-breaker for you, please switch back to "plain" Tumbleweed, or if you have got to have the latest stable fixes all the time, switch to GNOME:Factory repo instead. //Bjørn - Zaitor on behalf of your friendly GNOME Maintainers. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

2 2

[opensuse-gnome] Option "--geometry" is no longer supported in this version of gnome-terminal.
by Gerald Pfeifer 18 Apr '16

18 Apr '16

A few releases back, GNOME dropped support for restoring the previous desktop when logging in again, a feature that had worked sufficiently well for many years. In consequence we were told to use the like of gnome-terminal --geometry=80x44+880+0 if we wanted to put in place a consistent workspace upon startup. With GNOME 3.20, I am now getting Option "--geometry" is no longer supported in this version of gnome-terminal. I can hardly imagine that this is saving a lot of code or maintenance effort (or increase security). Any chance we can avoid this regression in openSUSE at least? And, how can I know configure my desktop such that it has a couple of terminals of the rigt size in the right location? Gerald -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

2 1

[opensuse-gnome] 3.20: Large window title bars
by Olaf Hering 18 Apr '16

18 Apr '16

The knobs below used to work, until GNOME 3.20 (or whatever is responsible for the large title bars). What needs to be done now to set the title bars to a usable size? Olaf On Fri, Aug 07, Olaf Hering wrote: > Am 07.08.2015 um 10:14 schrieb Gerald Pfeifer: > > "The upstream Gnome designers still force title bars that > > consume too much of my screen height upon me. > > > > In the past I could hack the title_vertical_pad settings in > > /usr/share/themes/Adwaita/metacity-1/metacity-theme-3.xml. > > Now those XML-based schemes seem gone. How can I perform > > such tweaking going forward?" > > > google found me this workaround: > > ~/.config/gtk-3.0/gtk.css > .header-bar.default-decoration { > padding-top: 0px; > padding-bottom: 0px; > } > > .header-bar.default-decoration .button.titlebutton { > padding-top: 0px; > padding-bottom: 0px; > } > > This does not seem to work for the settings window or file explorer. > Maybe because they have this Search icon in the titlebar. > > Olaf -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

3 2

[opensuse-gnome] GNOME 3.20
by Dominique Leuenberger / DimStar 30 Mar '16

30 Mar '16

Hello dear GNOME users, As most of you are well aware, GNOME 3.20 has been released last Wednesday and everybody is eagerly awaiting it to land in Tumbleweed. The current situation is very promising: * All packages are completed * Submission to openSUSE:Factory started around rc1 (3.19.91) and all fallouts have been fixed in time * openQA passed all the tests * All reviews (except two late-arrivals from today) have been completed. So, with this progress, I am pretty condifdent that we can have GNOME 3.20 in the 0330 snapshot. With this stable release being in place I will also enable publishing of GNOME:Factory again - so users of the devel project will receive the update a bit earlier. Hope you enjoy your new GNOME! Dominique

3 2

[opensuse-gnome] drop xchat
by Wolfgang Rosenauer 06 Mar '16

06 Mar '16

Hi, I've been using xchat for ages now. Now I found a bug which was also references in Debian bugtracking and following this I found that 1. xchat has a fork hexchat 2. xchat was dropped from Debian for being unmaintained and hexchat being available as an easy replacement I have switched to hexchat now as it's already in 42.1. Therefore I'm wondering if xchat should be dropped from Factory? Wolfgang -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

4 3

[opensuse-gnome] What's the status of upgrading to GNOME-3.20?
by Roy Mu 04 Mar '16

04 Mar '16

Hi folks! I'm here to learn the status of the plan to upgrade GNOME. Before that, I'd like to share my status and current work. I'm trying to fix bnc#882801, and related patches associated with our plan to upgrade NM, in case we did redundant work nonconforming with upstream. So I have to learn the status of GNOME upgrading. At present, what I concern is the upgrade of NetworkManager-1.0.10 which is the officially recommended for product usage, obviously it requires higher GNOME than our current 3.10. According to LFS(Linux From Scratch), I think higher than GNOME-3.18 is enough. Moreover, the fate#320455 requires a new feature "captive portal handling" introduced since GNOME-3.14. And here're my questions: 1. What's the expected date to upgrade to GNOME-3.20? 2. Do we confirm to take NM-1.0.10, or maybe higher, say, NM-1.2? The later is unstable yet, but if our whole upgrade work lasts more than 6 months, maybe NM-1.2 will be stable at that time. I'm not too eager to pursue the newest package, but it saves our work if I managed to commit some patches to the upstream. I would like to help if any related. Thanks! -- In the beginning was the lambda. God saw it, realized he didn't need anything else, and stopped there. —— 《FP Bible》 -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

2 5

Re: [opensuse-gnome] Running Xorg non-root
by Egbert Eich 26 Feb '16

26 Feb '16

Frederic Crozat writes: > Le mercredi 13 janvier 2016 à 11:01 +0100, Egbert Eich a écrit : > > Frederic Crozat writes: > > > Le mardi 12 janvier 2016 à 23:56 +0100, Egbert Eich a écrit : > > > > > > > > > For what it worth, I've been using the xf86-input-libinput on Leap > > 42.1 > > > for several weeks now and it is working great (setup is a > > trackball, a > > > integrated touchpad on Dell laptop and an external touchpad from > > > Logitech, which can do multi-touch..). > > > > > > > I bet it does for you and will do for Stefan, Michal and me as well. > > All of us have a pretty standard setup. We are not using a > > touchscreen > > or any wacom device ;p > > I'm using a wacom device too ;) Ok ;) > > And libinput doesn't try to handle Wacom devices ATM, so it shouldn't > be a problem. Ok. I sort of expected this. The wacom driver is rather ... sophisticated. > > For touchscreen, we'll rely on people to test with hardware, as > always.. Definitely. I need to find time to look into reproducible test procedures - especially for multitouch. Cheers, Egbert.-- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

2 1

[opensuse-gnome] GNOME:Factory currently publish-disabled
by Dominique Leuenberger / DimStar 19 Feb '16

19 Feb '16

Hi everybody, We just disabled GNOME:Factory from publishing any new packages. The current repo contanis everything that was released with GNOME 3.18.x up to date and is still safe to be worked with. As we're approaching GNOME 3.20, though, we want to move those packages from GNOME:Next forward to GNOME:Factory and soon submit them for Staging integration and openQA testing. This should happen no later than with the release of GNOME 3.19.91 (rc1), so that we can hopefully deliver 3.20 shortly after it has been released. So, for now, if you do you use the repo, there is no change for you: you won't be bombarded with the 'unstable' branch of GNOME. But there won't be new stuff in the repo for a couple days neither. Dominique -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

1 0

[opensuse-gnome] adjust timeout for application response
by Olaf Hering 27 Jan '16

27 Jan '16

If some app does not respond within a certain timeframe a popup occours which offers to either kill the app or continue to wait for its response. If an app runs in valgrind or gdb it will react much slower. How can I increase this timeout? Olaf -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

2 1

[opensuse-gnome] Running Xorg non-root
by Egbert Eich 13 Jan '16

13 Jan '16

Hi Guys, The Gnome team and the team dealing with the hardware pieces of the graphics stack should have a conversation about running X 'non-root'. On openSUSE Tumbleweed gdm is the first DM to run the Xserver without root permissions. An Xserver run as non-root will attempt to acquire permissions for devices from system-logind. Output: ======= Currently, on Tumbleweed, when using 'gdm' as login manager, Xwayland will be started on top of a Wayland Display Server if possible. If the Wayland display server cannot be started, ie. when no suitable driver is around - for instance, when the boot option 'nomodeset' is used, gdm will attempt to start Xorg as user 'gdm'. Once the login succeeds, gdm will start a regular Xserver as the logged in user. At SUSE we still support UMS drivers - including fbdev. In fact, fbdev is part of the fallback strategy we employ: since fbdev uses a VESA mode (which today is set by grub2), this mode will always be available. The UMS driver will fail immediately once the Xserver attempts to load them without root permissions. For the 'fbdev' it depends: this driver only requires access to /dev/fb<N> which allows group access of the 'video' group. Thus the user 'gdm' is able to start it, any other user will fail. This can be fixed by either setting the appropirate file ACLs or using systemd-logind granted access. Setting ACLs for devices is done for DRI devices in /dev/dri/ - it used to be handled by ConsoleKit but is done by uaccess for systemd, today. The bigger challange will be UMS devices. For these the only option I see would be to start them as root or to use a wrapper script to do this (this seems to be the present solution at Debian). The question which remains is, how does GDM know that a wrapper script is required? It would be easy to test for the presence of KMS, however, this will often include cases where fbdev can be used. I'm open to suggestions here ;) - after all, this decision needs to be made in GDM. Input: ====== All evdev input devices are handled by systemd-logind. It remains to check if drivers requiring /dev/input/mouse* or /dev/input/mice need to be equipped with an interface for obtaining the necessary permissions as well. There is one exception among the input drivers: xf86-input-vmmouse. This driver used for guest VMs on VMWare and KVM uses a rather obscure interface - an emulated PIO register. I'm not sure if this device is still supported by KVM, VMWare doesn't strictly require it, however if used, it used to enhance VMWare's capabilities. We may have to drop this driver as I would like to avoid having to use a wrapper for this. So, looking into handling access to /dev/fb<N> and some of the older input devices would be my task. You Gnome folks should consider how to decide when to use a wrapper. For the wrapper code, we should probably cooperate with Debian. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

3 2