Home Home > Desktop > Xfce
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for the ‘XFCE’ Category

Highlights of YaST development sprint 31

February 20th, 2017 by

As we announced in the previous report, our 31th Scrum sprint was slightly shorter than the usual ones. But you would never say so looking to this blog post. We have a lot of things to talk you about!

Teaching the installer self-update to be a better citizen

As you may know, YaST includes a nice feature which allows the installer to update itself in order to solve bugs in the installation media. This mechanism has been included in SUSE Linux Enterprise 12 SP2, although it’s not enabled by default (you need to pass an extra option selfupdate=1 to make it work).

So after getting some feedback, we’re working toward fixing some usability problems. The first of them is that, in some situations, the self-update mechanism is too intrusive.

Consider the following scenario: you’re installing a system behind a firewall which prevents the machine to connect to the outside network. As the SUSE Customer Center will be unreachable, YaST complains about not being able to get the list of repositories for the self-update. And, after that, you get another complain because the fallback repository is not accessible. Two error messages and 2 timeouts.

And the situation could be even worse if you don’t have access to a DNS server (add another error message).

So after some discussion we’ve decided to show such errors only if the user has specified SMT or a custom self-update repository (which is also possible). In any other case, the error is logged and the self-update is skipped completely.

You can find further information in our Self-Update Use Cases and Error Handling document.

During upcoming sprints, we’ll keep working on making the self-update feature great!

Configuring workers during CaaSP installation

While CaaSP release approaches, our team is still working hard to satisfy the new requirements. Thankfully, YaST is a pretty flexible tool and it allows us to change a lot of things.

For CaaSP installation, YaST features a one-dialog installation screen. During this sprint, configuration of the Worker role has been implemented, including validation of the entered URL and writing the value to the installed system. You can check the animated screenshot for details.

The CaaSP worker configuration

New desktop selection screen in openSUSE installer

The world of Linux desktop environments change relatively quick, with new options popping-up and some projects being abandoned. Thanks to the openSUSE’s community of packagers we have a lot of these new desktop environments available on the openSUSE distributions. But the status of those packages for openSUSE is also subject to changes: some desktop environments are poorly maintained while others have a strong and active group of packagers and maintainer behind.

The YaST Team does not have enough overview and time to watch all these desktop environment and evaluate which one is ready or not for being in the installer’s desktop selection screen. So the openSUSE Release Team decided to replace this dialog with something a bit more generic but still useful for newcomers.

They asked the YaST Team to come up with a new dialog featuring the two openSUSE main desktops (KDE Plasma and GNOME) and allowing the easy selection of other environments without reworking the dialog in the future. The goal of that new dialog was to replace the existing one you can see in the following screenshot.

The old desktop selection screen

We decided the new dialog should rely on patterns for several reasons. The main one is that the set of patterns is under the close control of the openSUSE community, which looks more closely than us to the desktop environments and their integration into the distribution. Moreover, each pattern specifies its own icon and description that can be somehow re-used by the installer.

We also took the opportunity to merge this almost empty and outdated dialog with the new one.

The old additional repositories screen

Addons are no longer produced for openSUSE, so only the second checkbox made any sense nowadays. Moreover, the functionality of that second checkbox directly influence the available selection of patterns, so it made more sense to merge everything in a single screen that keeping an extra step in the installation just to accommodate a checkbox.

So we sent a proposal for the new dialog to the opensuse-factory mailing list and, after implementing many of the ideas discussed there (like better wording or using a button instead of a checkbox for the online repositories), this is the new dialog that replaces the two ones mentioned above.

The new desktop selection dialog

Selecting “custom” will take the users to the already existing patterns selection screen. Just in case you don’t remember how that screen looks like, you can check this image.

The patterns selection screen

If these screenshots are not enough to make your mind about the change, you can check the following animation, in which KDE Plasma is initially chosen to be changed at a later point (going back in the workflow) to LXQt.

Desktop selection animation

It will take some time before the changes hit the Tumbleweed installer, since they obviously have a non-trivial impact on the openQA tests, that will need some adaptation.

We would like to thank everybody that contributed to this new feature by providing feedback and suggestions through the mailing list. Once again, the openSUSE community has proved to be simply awesome!

Storage reimplementation: improved handling of logical partitions

Our reimplementation of the storage layer keeps getting improvements here and there. With the base x86 case working, we are now implementing the tricky parts, like the partitions renumbering that takes place when dealing with logical partitions in a MBR style partition table.

With GPT partition tables or with primary partitions in a MBR partition table, the partition gets a number (like sda1) when it’s created and keeps that number for its whole lifetime. But logical partition gets constantly renumbered when other partitions are created and destroyed. We need to know in advance what device name every partition will get in order to configure everything beforehand and only commit the changes to the disk when the user clicks in the “install” (during the installation process) or “commit” (if running the expert partitioner).

Now, libstorage-ng is able to simulate in memory the re-numbering process, so we can calculate all the settings related to partitioning (like the configuration of the bootloader) before really touching the disk.

Making kdump work in CaaSP

When you enable the Kernel Crash Dump (kdump), you probably expect that you will get a kind of core dump, like you do for regular processes. What you might not expect is an automatic reboot. That is a nice bonus. If you are tired of waiting for an actual kernel crash, you can test your kdump setup by triggering a crash yourself. Just run this as root:

echo c > /proc/sysrq-trigger

The way kdump works is by allocating some extra memory at boot time and putting a second kernel+initrd there. When the main kernel realizes it is crashing, it transfers control (by kexec) to the other one, which has only one purpose, to dump the memory of the crashed kernel.

In the upcoming Containers as a Service Platform, kdump was not working because the root filesystem is read-only there and we were not able to create the kdump initrd. We fixed it by creating it just after the RPMs are installed, when the FS is still read-write.

Fixes for Snapper in CaaSP

Kdump was not the only component affected by the fact of having a read-only filesystem in CaaSP. Snapper was also running into problems when trying to execute the rollback and cleanup operations. Now the problems are fixed. While working on that we did enough interesting findings to deserve a separate blog entry. So you can expect a new entry in the Snapper.io blog soon.

Snapshot-related improvements in the expert partitioner

While we work on the new storage system, we are still taking care and improving the current one that will continue to be shipped with SLE12-SP3, SUSE CaaSP and openSUSE Leap 42.3. During this sprint we introduced a couple of usability improvements in the expert partitioner related to Btrfs subvolumes.

First of all, we moved the “Enable Snapshots” checkbox that was pretty much hidden in the “Subvolume Handling” dialog to the place where it really belongs – below the selector of the file-system type.

New location for enabling snapshots

In addition, we added the warning you can see in the screenshot below for users enabling snapshots in a potentially problematic setup.

Warning for snapshots in a small partition

Bring back the beta warning on CaaSP

And talking about warnings, we improved the CaaSP installation dialog to show the Alpha/Beta product warning at the beginning. After changing the CaaSP installation to use the all-in-one dialog described in our previous post, this feature was lost as it is part of the initial EULA dialog. Now it is back and the users should now properly see the current product status.

The CaaSP alpha/beta warning pop-up

Storage reimplementation: encrypted LVM proposal

Back to our storage layer reimplementation, the new system is now able to propose a setup with encrypted LVM. Since some sprints ago, we were already able to propose a partition-based and a LVM setup. That means the new proposal is now feature-pair with the old one, with the only exceptions of Btrfs sub-volumes (that shouldn’t be a big challenge) and s/390 storage (that is still not properly managed by the underlying libstorage-ng).

The bright part is that the new code is written with re-usability in mind, which means implementing an encrypted partition-based proposal (with no LVM) would be trivial. The new code is 100% covered by automatic unit tests and scores to the top in all the automatic quality checkers we have run (like Rubycritics, CodeClimate, and Rubocop).

So now we are prepared for whatever the future brings, having lost no single feature in the way.

Storage reimplementation: prototype if the UI for the proposal settings

The next challenge is to make the power of that new storage proposal available to the users through the user interface. In the previous post we presented the document describing the general ideas we wanted to discuss with UX experts.

It’s our pleasure to announce we met the experts and we very easily reached an agreement on how the user interaction should be. During this sprint we already implemented a prototype of the future proposal settings wizard that is, as usual, included in our testing ISO.

Now that we have solid foundations, it’s very likely that the following sprint will result in the fully working wizard, with almost-final wording and design.

Support for CaaSP added to the AutoYaST integration tests

While fixing a problem with AutoYaST and CaaSP, we decided to extend our AutoYaST integration testing tool to support CaaSP. But, as a side effect, we also made some additional improvements that were long overdue (like improving the procedure to download ISOs, reducing timeouts, etc.).

Now, our internal Jenkins instance takes care of running AutoYaST integration tests for the development version of CaaSP (as it already does for SLE 12 SP2).

Services manager moved to first auto-installation stage

AutoYaST allows to define a set of services to be enabled/disabled in the installed system, applying this configuration during the 2nd stage (after the first reboot).

Unfortunately, this approach won’t work for CaaSP because, in that case, the 2nd stage won’t be available. For that reason, during this sprint, we have adapted AutoYaST to write services configuration during 1st stage.

As usual, not only CaaSP, but other future (open)SUSE versions will benefit of this change.

Faster YaST installation when the release notes cannot be downloaded

Sometimes a very small simple change in a program makes a very noticeable impact in its everyday use. That’s the case of a fix implemented during this sprint. YaST usually re-tries to download the distribution release notes several times if the first attempt was unsuccessful. Although that’s correct from a general point of view, there are cases in which retrying makes no sense and only delays the installation. We have now added failed DNS resolution to that list of cases, which should result in a noticeable faster installation in many scenarios.

Moreover, in the case of AutoYaST we now skip downloading the release notes completely. Downloading them don’t make us much sense in the kind of unattended scenarios handled by AutoYaST and skipping this step and all the possible associated problems result in a more robust process.

Better continuous integration for Libyui

In the previous sprint we switched to Docker at Travis so we could build and test our packages in the native openSUSE system instead of the default Ubuntu. This sprint we did the same change also for the Libyui library which implements the UI part of YaST.

Originally we could not build the Libyui packages at Travis as either the required build dependencies were missing or were present at a very old unusable version. With this switch we can easily use the latest packages from openSUSE Tumbleweed and thus enable Travis builds for all Libyui packages.

See you after Hack Week!

As already mentioned, this week is Hack Week 15! So our Scrum process will be on hold for some days. That doesn’t necessarily mean the YaST development will stall. Since there are quite some YaST-related projects in the Hack Week page, you can expect YaST to simply go in unexpected directions. 🙂

And remember Hack Week is not a SUSE internal initiative, we are open to collaboration from anybody within or outside the company. So jump in and have fun with us!

Proprietary AMD/ATI Catalyst fglrx rpms new release 15.11 (15.300.1025-1)

December 6th, 2015 by

Time to get an update for fglrx: the new release has been build for 13.1, 13.2, Leap 42.1, and tumbleweed 20151201

Tumbleweed beware : broken Xorg

It seems since the release, that a number of report of broken xorg with gdm, ssdm and so… segfaulting

You can still use the previous version hanging on the server. But I doubt it would work better

As soon, with Sebastian Siebert we have a patch for, I will republish a new build

Informations & bugreport Sebastian’s blog or lizards.o.o

The proposed drivers support kernel up to version 4.4

AMD release note available

Sebastien Siebert making script

Sebastian Siebert posts about fglrx

If you have any problems with the driver, don’t be afraid to report to Sebastian (German and English bugreports are gladly accepted).
he will try, as far as I am able to reproduce the bug. Together with the necessary system information, he will go directly to the right place at AMD to have the bug fixed in the next driver release.
Thank you very much, Sebastian.

See below what to do in case of troubles.

Or you can also ping him on irc (freespacer)

Debugging troubles

I recommend in case of trouble the use of his script which can collect the whole informations needed to help you. then you just have to issue a simple commande in console to collect all informations, you can review them, and finally transmit them.
Check the website to get the latest.

su -c 'sh makerpm-amd-15.11.sh -ur'
The system report 'amd-report.txt' was generated.                                                                                                          [ OK ]
Do you want to read the system report 'amd-report.txt' now? yes/no [y/n]: y
Are you sure to upload the above-named system report to sprunge.us? yes/no [y/n]: y

The report was uploaded to sprunge.us.
   The link is:  http://sprunge.us/eMEB

Copy paste the link in the comment zone of Sebastian post

All proudly distributed by openSUSE powered server and sponsored by Ioda-Net Sàrl

Banana Pi M2 running openSUSE Tumbleweed

December 3rd, 2015 by

Following up from my earlier post about openSUSE LTSP on Banana Pi, Nora Lee from the manufacturer of the board got in touch with me and sent me a couple of their new boards- Banana Pi M2, runs on A31s quad-core CPU and has 1G RAM, powerful enough to run openSUSE Tumbleweed with Xfce Desktop.

Here is how you can get openSUSE running on Banana Pi M2.

* Download the image

* Extract the archive to get openSUSE-Tumbleweed-Bpi-M2-Xfce.img

* Dump openSUSE-Tumbleweed-Bpi-M2-Xfce.img on to a SD card
(dd if=/path/to/openSUSE-Tumbleweed-Bpi-M2-Xfce.img of=/dev/sdX bs=4M; sync #replace /dev/sdX with your actual SD card device)

*  In case you have a bigger SD card, use yast2 disk(partitioner) to “expand” the second partition. You can use yast’s package manager to install more software. The default password for root is linux, you may want to change that first thing after booting.

I am unable to get sound on this hardware, probably their kernel is missing sound related modules, if you figure out how to get sound working drop me a line so I can include it in next release.Everything else(wifi, hdmi out, USB ports etc) works well enough.

AMD Catalyst 15.3 Beta for openSUSE – new makerpm-amd-script is available

April 8th, 2015 by

AMD has released the new AMD Catalyst 15.3 Beta. They have not yet released a public beta driver for all other distributions. It is currently available for Ubuntu. *sigh* So, it is a bit hard work to implement this in the makerpm-amd-script to replace the latest AMD Catalyst 14.12 with AMD Catalyst 15.3 Beta. So do not confused if the script downloads the AMD Catalyst 14.12. 🙂

Unfortunately there is no release notes from AMD. This update can solve the issue with PowerXpress but I can not really verified this because lack of such hardware.

Another side note I have implemented a workaround in the script to get the driver works with the GNOME Displaymanager + GNOME. It is a little cruel hack but it works for the moment. Thanks to the user that they posted the article in my blog. 😉

For GNOME user with gdm: Execute the following command as root after the installation of the AMD driver and before restart the machine:
sh makerpm-amd-15.3-beta.sh --install-gdm-fix
If you update the AMD driver, so the workaround does not work anymore. It is important that you do not delete the file /amd_xversion and is needed for the workaround.

To revert the changes:
sh makerpm-amd-15.3-beta.sh --uninstall-gdm-fix

Before I forget it: All user from openSUSE Tumbleweed can also install the driver. But remember, Tumbleweed is under heavy development. I can not guarantee that the driver works in the future yet.

Downloads:

Installation guide (English):
http://en.opensuse.org/SDB:AMD_fglrx#Building_the_rpm_yourself

The above named installation guide is only for the stable driver but you can adapt it for the beta driver.

Bruno Friedmann will build the new RPM packages in the fglrx repository. Stay tune!

If you find any issue with the driver. Don’t hesitate to contact me. I am in contact with AMD and can forward your issue to the right place. Feedback are welcome.

A report of your system is very helpful beside your feedback. You can generate it with the script:
su -c 'sh makerpm-amd-15.3-beta.sh -ur'

Have a lot of fun!

Sebastian
openSUSE member / Official AMD Packaging Script Maintainer for openSUSE

German Blog: openSUSE – proprietären Grafik-Treiber AMD Catalyst 15.3 Beta als RPM installieren

New Proprietary AMD/ATI Catalyst omega fglrx 14.12 (14.501.1003-1) rpm released

December 13th, 2014 by

Hey Christmas time around! AMD give us a new version of fglrx, and Sebastian Siebert just release his script yesterday night.
So I’ve prepared the new version available for openSUSE 11.4, 12.1, 12.2, 12.3, 13.1, 13.2 and Tumbleweed.
Sebastian’s script contain a special patch for supporting kernel up to 3.17 and 3.18 version.
I should also share Sebastian’s surprize about the fact that this version didn’t got a beta/rc cycle….

I hope this release will give better results for all of you who own an apu (especially the recent one), and also fix a number of issue with the hybrid chipset intel cpu/amd gpu embedded.

See below how to report issue on Sebastian blog.

It will be the last build for all openSUSE version below 13.1 (except if patches are needed).
In January 12.3 support will definitively end. But I will let the drivers as is so you can still use them in case of.

Installation / update

Please refer to the wiki page SDB:AMD_fgrlx

New packaging schema

The driver is now splitted into different rpm that all need to be installed. Normally the necessary Require field is there and should happen automatically.

My advise is to check if you have them all installed.

for 32 bits

zypper install fglrx_xpic fglrx_core fglrx_graphics fglrx_amdcccle fglrx_opencl

for 64 bits

zypper install fglrx64_xpic fglrx64_core fglrx64_graphics fglrx64_amdcccle fglrx64_opencl

A notice for Tumbleweed users

The new release has now its package correctly named, previously they were called SUSEFACTORY, with the new version the package will contain SUSETUMBLEWEED in their name

openSUSE 12.3 on Android

May 9th, 2013 by

Here is a new image for your armv7l powered phone or tablet(any recent dual core device should work), you can get openSUSE 12.3 XFCE running on it without the need for repartition, formats, bootloader hacks or sacrificing your nicely running latest android on it. What you need is rooted device with busybox, Android VNC and terminal app installed and 4GB free space on sdcard(internal or external).

Instructions to run it are same as mentioned earlier. In addition to those you can also use LinuxonAndroid app with patched bootscript.sh. Replace /data/data/com.zpwebsites.linuxonandroid/files/bootscript.sh on your device with the patched one and follow the directions shown here(last 3 images):

openSUSE on android

openSUSE on phones/tablets

February 20th, 2013 by

Thanks to the fantastic work by openSUSE Arm team, you can get full desktop on your armv7l powered phone or tablet(any recent dual core devices should work), without the need for repartition, formats, bootloader hacks or sacrificing your nicely running latest android on it. What you need is rooted device with busybox, Android VNC and terminal app installed and 4GB free space on sdcard(internal or external).
(more…)

ATI/AMD catalyst fglrx legacy updated to new 13.1 version

January 24th, 2013 by

Proprietary AMD/ATI Catalyst fglrx legacy 13.1 (8.97.100.7-1) rpm released

Notice

This release concern only radeon HD2xxx to HD4xxx owners

The published Catalyst fglrx rpm version support openSUSE version from 11.4 to 12.3 (new repository) and also Tumbleweed (thus also kernel 3.8x series).
For testing with the next openSUSE 12.3 just use the new openSUSE_12.3 repo

The release note

Feedback

Sebastian Siebert will publish an article today, and he’s looking for feedback about the patches included to make it working on 12.3, so don’t hesitate to get in touch with him

Comments:

As I didn’t have a gpu card of this series, I can’t test it before publishing the rpm like for normal fglrx. If someone has a spare hd2xxx or hd4xxx, Could he(she) contact me?

Have fun!

Proprietary AMD/ATI Catalyst fglrx 13.1 (9.012-1) rpm released

January 21st, 2013 by

Proprietary AMD/ATI Catalyst fglrx 13.1 (9.012-1) rpm released

Sorry this article should have been published Saturday, but some trouble (error in a updated module) locked me outside of lizards), Thanks to Matthew to have fix it in the meantime

fglrx 13.1 amd-ccc & fgl_glxgears

fglrx 13.1 amd-ccc & fgl_glxgears

Notice

This release concern only owners of radeon HD5xxx or above.
For older gpu, the fglrx-legacy is still 12.6, and thus didn’t work with Kernel 3.6, 3.7, 3.8
SDB:AMD_fgrlx_legacy
Beware of that fact, and prefer the free open-source radeon driver which came out of the box from your openSUSE distribution.

Release note about 13.1

This Catalyst fglrx version support openSUSE version from 11.4 to 12.3 (new repository) and also Tumbleweed (thus also kernel 3.8x series).
For testing with the next openSUSE 12.3 just use the new openSUSE_12.3 repo

Release Note

A release note is available on AMD website

Fixed issues

    [368958]: Driver release version is added to GL_VERSION
    [367282]: Bblank VGA display after resume from suspend
    [367245]: X crash for AMD PowerXpress™ A+I High-Performance mode on Ubuntu 12.10
    [366820] Performance of Valve Linux games
    [366805]: Segmentation fault when exit QtOpenGL applications such as AMD CodeXL
    [366425]: Xserver getting exit upon resume from suspend on RHEL 5.8
    [364107]: VariBright not working when change AMD PowerPlay™ settings in AMD Catalust Control Center:LE
    [363638]: VariBright doesn’t work after resume from suspend on “Trinity” platform
    [350759]: Flickering cursor when run some full-screen OpenGL games with CrossFire enabled
    [347895]: OpenGL performance on “Southern Islands” ASICs
    [344996]: 16 re-frames doesn’t work for H.264 @Level 5.1
    [337240]: Corruption when resize the Konsole window
    [304016]: One display goes black after changing from multi-display desktop from single independent

Sebastien Siebert making script

Sebastian Siebert post about 13.1

If you have any problems with the driver, don’t be afraid to report to Sebastian (German and English bugreports are gladly accepted).
he will try, as far as I am able to reproduce the bug. Together with the necessary system information, he will go directly to the right place at AMD to have the bug fixed in the next driver release.
Thank you very much, Sebastian.

See below what to do in case of troubles.

Or you can also ping him on irc (freespacer)

fglrx & 3d effects kde 4.9.5 on openSUSE 12.2

fglrx & 3d effects kde 4.9.5 on openSUSE 12.2


(more…)

AMD/ATI fglrx 8.951 Catalyst 12.3 rpms available for openSUSE 12.2, 12.1, 11.4, 11.3

March 30th, 2012 by

Those informations are obsolete now : please consult //lizards.opensuse.org/?p=8888

AMD/ATI Catalyst 12.3 / fglrx 8.951 rpms are available

Quick Résumé about 12.3

AMD rename their installer, So Sebastian did the same for his script.

I will just copy/google translate/paste here the comment made by Sebastian Siebert on his blog :

amd ccc and fgl_glgears running

The packaging script was updated because I have a compile error when building a kernel module fglrx in the kernel 3.2.8+ and 3.3+. Due to the very tight time window, the patches could no longer be incorporated into AMD Catalyst 12.3. Only in the upcoming AMD Catalyst 12.4, the patches from me for openSUSE will be available. AMD Catalyst 12.5 they will be officially included for all other distributions. Yes, with the makerpm-amd script made for you, I can despatch on very simple, convenient and quick patches or missing useful extensions via the script packaging update. Who need to wait months.
Driver support now AMD Radeon HD 7950, HD 7970, HD 7990

See more at Sebastian’s blog.
Don’t be shy, you can leave there the result of test in english too 😀
or ask in forums, irc and ping freespacer.
See below what to do in case of troubles.

The rpms version 8.951 are available from Friday March 30th.

(more…)