First we will need to populate the conainer 
with an openSUSE base system.
TARGETDIR=$HOME/OBS_CONTAINER/OBSCONTAINER/
SOURCEREPODIR=/etc/zypp/repos.d/
#lazily copy existing *.repos
for f in *.repo
do
sudo cp $SOURCEREPODIR$f $TARGETDIR/$SOURCEREPODIR
done
cd $TARGETDIR
sudo mkdir -p sys proc dev
sudo mount -t proc proc proc/
sudo mount -o bind /sys sys/
sudo mount -o bind /dev dev/
sudo zypper --no-gpg-checks --non-interactive --cache-dir /var/cache/zypp --root $TARGETDIR in --allow-unsigned-rpm --auto-agree-with-licenses filesystem bash permissions coreutils bash-completion cpio coreutils glibc permissions systemd systemd-rpm-macros systemd-presets-branding-openSUSE rpm zypper nano system-group-wheel system-group-hardware system-user-bin system-user-root system-user-nobody sudo systemd-network yast2-network NetworkManager nmcli-dmenu mariadb systemd-container obs-service-obs_scm obs-service-tar_scm

Okay so far so good. The base system is already bootable via nspawn.
We need some set-up of the system before we do it though:
sudo chroot $TARGETDIR /usr/bin/bash -c "systemd-machine-id-setup"
sudo chroot $TARGETDIR /usr/bin/bash -c "ln -sf /etc/machine-id /var/lib/dbus/machine-id"

Now it's time to install OBS itself
sudo zypper --cache-dir /var/cache/zypp --root $TARGETDIR ar https://download.opensuse.org/repositories/OBS:/Server:/Unstable/openSUSE_Factory/OBS:Server:Unstable.repo
sudo zypper --no-gpg-checks --non-interactive --cache-dir /var/cache/zypp --root $TARGETDIR in --allow-unsigned-rpm --replacefiles --auto-agree-with-licenses -t pattern OBS_Server
sudo zypper --no-gpg-checks --non-interactive --cache-dir /var/cache/zypp --root $TARGETDIR in --allow-unsigned-rpm --replacefiles --auto-agree-with-licenses obs-service-set_version obs-service-recompress 

We are now able to boot the systemd container and set-up OBS.
With the same commands you will be able to boot it in the future too.
RUNDIR=$HOME/OBS_CONTAINER/run
sudo systemd-nspawn -D $TARGETDIR -b --resolv-conf=bind-host --capability=all --property="DeviceAllow=/dev/loop-control rwm" --property="DeviceAllow=/dev/loop-* rwm" --property="DeviceAllow=block-loop rwm" --property="DeviceAllow=block-* rwm" --bind="$RUNDIR/obs/:/run/obs" --bind="$RUNDIR/passenger/:/run/passenger/" --bind="$RUNDIR/mysql/:/run/mysql/" --property="DeviceAllow=/dev/port rwm" --property="DeviceAllow=block-blkext rwm" --property="DeviceAllow=char-pts rwm" --property="DeviceAllow=/dev/null rwm" --property="DeviceAllow=/dev/zero rwm" --property="DeviceAllow=/dev/random rwm" --property="DeviceAllow=/dev/urandom rwm"

And since we have not set a root password, but one is expected,
we connect from a different console and start the setup.
Unless you want to customize ports/ip etc. you can leave 
everything at the default from setup-appliance.sh 
sudo machinectl --machine OBSCONTAINER shell
/usr/lib/obs/server/setup-appliance.sh --force #inside the machine

The Corona (Corvid-19) virus has forced a lot of us to work from home. My preferred way of working, is by using openSUSE. Because my company has decided a while ago that Office365 and Microsoft Teams would be the default applications for collaboration, I am able to do so.

Installing Microsoft Teams Preview

The first thing to do is to go to the Microsoft Teams website to download the Teams software package.

Save the RPM file to your computer.

Now open the Dolphin file browser and either press F4 or click on: Control –> Panels –> Terminal.

Now install Teams by using the command:

sudo zypper install teams-versionnumber.x86_64.rpm

First enter your root password. When asked to confirm the installation, type ‘y’ and then press Enter.

After installation, type ‘Teams’ in your launcher to start the Microsoft Teams – Preview application.

You can login by entering your (work) e-mail address and your password and if needed the Two Factor Authentication approval.

My experience

Teams on Linux works very well. Video conferencing also works like a charm. It also works great with SharePoint (for accessing your Teams files), Outlook (for knowing when your next meeting starts), Word, Excel and PowerPoint. Everything works as you would expect.

The Word, Excel, PowerPoint versions are comparable with the browser versions of Office365. So the desktop apps still work a bit better. For instance when creating rich formatted Word documents or when creating visually impressive PowerPoint presentations. But I am able to do minor edits without a problem.

Conclusion

Microsoft Teams on Linux works just as well as the Windows version. And that is one of the biggest compliments that you can give to a Microsoft Office application. The only difference is that you cannot open files in the desktop versions of Word, Excel or PowerPoint. So now we wait for those to come to Linux as well!

Published on: 20 April 2020

We have to use Jupyter notebooks for Machine Learning at our university. Jupyter needs a lot of space on the hard disk and I was able to remember (from vocational school) that we were able to install PHPMyAdmin on a USB stick. You have a transportable web application on this way. I had this goal for Jupyter and the Python environment on Linux.

So I want to give you the installation guide for Jupyter on openSUSE Leap 15.1 (incl. Python) in a virtual environment.
Install the following packages as a foundation:

 sudo zypper install python3-pip python3-devel

After that install the virtual environment with pip3:

sudo pip3 install --upgrade pip
sudo pip3 install virtualenv

Create a project directory for Jupyter in your home directory and mount the external disk/ USB stick there:

sudo mkdir ~/Jupyter
sudo mount /dev/sda1 ~/Jupyter

You have to umount /dev/sda1, if the disk has been mounted automatically in /run/media/ (in my case):

sudo umount /run/media/user/TOSHIBA\ EXT/
sudo mount /dev/sda1 ~/Jupyter

If the external disk is mounted, you can create the virtual environment for Python and Jupyter in the special project directory:

virtualenv ~/Jupyter

Inside, it will install a local version of Python and a local version of pip. We can use this to install and configure an isolated Python environment for Jupyter.
Before we install Jupyter, we need to activate the virtual environment:

source ~/Jupyter/bin/activate

You are ready to install Jupyter into this virtual environment.
You can install Jupyter on the external disk with the following command:

pip install jupyterlab

Call Jupyter via command line inside of the project directory then:

jupyter notebook

That will open your web browser with http://localhost:8888/tree.
Do you need additional packages or Python libraries? You can install them in this project directory, too.
Change to this directory and install them with pip3 (in my case these ML packages):

pip3 install scipy numpy matplotlib sklearn pandas
pip3 install keras tensorflow

Enjoy Jupyter on an external disk.

Here it is! Qactus v2.0.0 has been released
The main focus of this version has been on improving the browser.

New features:

• Improved UI: revamped toolbar, new action toolbars for projects, packages, files and build results, new side bar icons
• Bookmarks: first version for the watchlist
• New package actions: submit, copy, link and properties
• New project action: properties
• MetaConfigEditor (beta): now it is possible to edit a project/package properties such as general info, repository, repository flags, users and groups
• New search widget (Ctrl+F) for BuildLogViewer
• Showing outgoing and declined requests

Miscellaneous bugfixes and «hidden features»

Source code – RPM packages

Contents

Once most of the features that were planned for SUSE 15 SP2 and openSUSE 15.2 are ready, the team is shifting its focus to SP3 and 15.3. Of course, we are still polishing the releases around the corner, so in the summary of this sprint, you can find a mixture of bug fixes, small features, and preparation for the future work. These topics are:

• NCurses installation in old graphic chips
• Booting from Remote Encrypted devices
• Smarter network configuration in Linuxrc with the new try keyword
• Better support for auto-configured devices in S/390 systems
• Researching about how to improve XML YaST’s parser

Coming Back to Haunt Us: NCurses Installation and Old Graphics Chips

Some months ago (for Leap 15.1 / SLE-15 SP1), we started using fbiterm for all NCurses (text-based) installations. We had always used it for certain languages like Chinese, Japanese, Korean that need special support for their fonts, but since there were font-related problems even for other languages, we are now using it in all cases.

This fixed those font-related problems, but it turns out it brought back another issue that seemed long forgotten: poor performance in text mode for specific graphics chips.

Remember the Matrox G200? It was a good choice for Linux systems back years ago. Back many years ago; that GPU had its 20th anniversary in 2018, so it dates back to 1998 (that was when Windows 98 was new). Its graphics performance was… let’s call it quite okay for a budget card even back then.

Well, it turned out that it is still used today by some rack server manufacturers as on-board graphics. Most on-board graphics these days uses Intel GPUs (and they work great), but not all: some indeed use that old Matrox G200.

We had a business customer inquiring why screen redraws while installing their rack servers were so slow with SLE-15 SP1 compared to SLE-15 GA, and that’s the explanation: Those machines have that Matrox G200 on-board graphics, and it doesn’t seem to have the hardware acceleration that would be good to have for a framebuffer console. And with fbiterm you can now really see the difference.

In that setup, you can observe the NCurses library at work in slow motion: You can see how it partially removes text from the cursor position to the end of the line (leaving part of the screen black) and then redraws content from there. It’s not wrong or buggy, it’s just slow. Unbearably slow, like back then having a very slow (4800 baud) terminal connection (remember those?).

So our recommendation for that kind of hardware is: Better not use a framebuffer console. Just leave the machine in plain text mode with 80x25 with the nomodeset boot parameter, or do an SSH installation.

Those old ghosts keep coming back to haunt us, even from back in the very late MS-DOS days. :smile:

Improve Booting from Remote Encrypted Devices

But not all ghosts are that old. We also got the visit of the spirit of the past sprints. In one of our November posts, we explained you how we had addressed the existing problems booting from remote encrypted devices by adding the _netdev option to the fstab and crypttab files for all network-based file systems.

For some months, it looked like the definitive solution. But recently it was reported that, as much as that option indeed pleases systemd, it confuses dracut when it is used in the root file system. Although they say you cannot make everybody happy, we found that adding that option to all file systems except the root one actually seems to be the right solution for both systemd and dracut. The latter does not get confused anymore and turns out the root file system is the only one for which omitting the option is safe for systemd.

With all that, SLE-15-SP2 (and Leap 15.2) should exhibit a pretty solid behavior for all scenarios involving installation on top network disks, encrypted or not. For more technical details, you can check the corresponding pull request.

Let’s try ifcfg in Linuxrc

Linuxrc is a piece of software responsible for booting the installation media. It offers a friendly interface to set up some basic stuff (e.g., the language) and takes care of initializing the hardware and preparing all the stuff that YaST needs to do its magic.

Alternatively to the good looking interface, it provides a really powerful command line too. If you have not done it before, we recommend you to check the Linuxrc wiki page.

One of the things you can set up using the command line is the network, which is really handy when you want to do an installation from a network source.

ifcfg=eth*=192.168.0.2/24 install=http://192.168.0.1/iso

With these settings, Linuxrc configures the first device that matches the eth*. But what happens if you have multiple network interfaces? Is the configured interface the right one to reach the installation media?

To deal with these situations, we have added a try feature to the ifcfg option:

ifcfg=eth*=try,192.168.0.2/24 install=http://192.168.0.1/iso

In this case, Linuxrc tries to find the device which matches the pattern and makes the installation source reachable.

The try keyword works for static configurations as well as for DHCP. When used with DHCP the difference is that the DHCP setup is done for just one device. Without the try keyword, the DHCP configuration is assigned to all devices which match the device pattern. So, if you use:

ifcfg=eth*=try,dhcp

you’ll end up with one DHCP configured device (the one that has a working network connection). On the contrary, omitting the try option will configure via DHCP all the devices matching the given pattern.

You can use any of Linuxrc’s network-aware options as criteria for the try option (install, dud, info, and autoyast). However, you cannot explicitly determine which one will be used if more than one is given. It merely depends on which one is used first by Linuxrc.

Better Support for Auto-Configured Devices in S/390 Systems

A few weeks ago, we announced that we had extended Linuxrc and YaST to play nicely with the new I/O device auto-configuration mechanism on zSeries systems. After gathering some feedback from our S/390 experts, we did some adjustments to the current implementation.

On the one hand, the auto-configuration is now optional. Linuxrc offers a new DeviceAutoConfig that allows the user to indicate whether to apply the configuration. The possible values are 0 (no), 1 (yes) and 2 (ask). The last of those values is the default.

On the other hand, QA detected a problem when AutoYaST tried to configure a device that has been already configured. Apart from solving the issue, we invested some time doing cleaning-up part of the yast2-s390 module.

Improving YaST’s XML Parser

XML is an important language in the YaST world. The best example is the so-called control file, which defines many aspects of the installation process. You can check the control file for openSUSE if you are interested.

YaST implements its own XML parser which is adapted to our needs. For instance, it is able to understand an special config:type attribute which serves as a hint about to interpret the content of the XML tag. If you have used AutoYaST, you know what we are talking about.

<initialize config:type="boolean">true</initialize>

However, it has its own set of problems, especially when it comes to error reporting. For that reason, we have started a new initiative to improve our XML parser. There are some discussions which are taking place in the yast-devel mailing list (like YaST XML Parser and Yast XML parser and strictness). Feel free to join and share your point of view.

Conclusions

To plan for the future, the team has started to do some research about the current status of YaST modules and AutoYaST. You might already have read something about them if you are subscribed to the yast-devel mailing list. If you want to share your point of view, you are welcome to the discussion.

In any case, we plan to present our conclusions during the upcoming weeks. So stay safe and tunned!

Dear Tumbleweed users and hackers,

Two short (work) weeks just passed; The long Easter weekend kept me away from writing last weeks report. So I have to catch up now, covering two weeks worth of snapshots. There were 10 snapshots released in those two week (0401, 0402, 0405, 0407, 0408, 0409, 0410, 0411, 0413 and 0414).

The noteworthy changes were:

• Linux kernel 5.6.0 & 5.6.2
• openSSL 1.1.1f
• Mesa 20.0.4
• MozillaFirefox 74.0.1 & 75.0
• KDE Plasma 5.18.4.1
• Poppler 0.86.1
• GNOME 3.34.5
• GCC 9.3.1
• GNU make 4.3
• LLVM 10
• Ruby 2.7 has been added; but no gems are being built yet

Looks like a long list, but it was spread over two weeks. And some of those changes had been brewing for a long time already. The future changes you can expect are:

• Removal of Python2 (VERY SOON!). We will remove all python2-FOO modules, but keep the python2 interpreter, python2-setuptools and python2-pip around. So people who need to can still base their work on that. This is supposedly happening in Week 17
• KDE Frameworks 5.69.0
• Linux kernel 5.6.4
• Systemd 245
• Poppler 0.87 (for once a painfree update?)
• GNOME 3.36
• KDE Applications 20.04 (RC being tested at the moment)
• Guile 3.0.2: breaks gnutls’ test suite on i586
• Qt 5.15.0 (currently beta3 being tested)
• Switch from Ruby 2.6 to 2.7
• GCC 10 as the default compiler

Hi openSUSE Community,

We have been using Redmine as a ticketing system for a very long time. The previous server had Redmine 2.4.5 from 2014 installed on an old SLE 11 SP4 server.

And finally we have successfully migrated to a newer Redmine version. Currently running Redmine 3.4.12 on a brand new server with Leap 15.1.

This is a long awaited step in a long, long journey. Much time was spent fixing broken plugins, configuration and the database to match the new Redmine version. And we have a new theme to make it look fresh.

Thank you to all people who helped this migration run smoothly.

Estu

Since last Thursday, a total of five openSUSE Tumbleweed snapshots were released.

Each snapshot had about between five to 10 packages updated.

The most recent snapshot, 202000414 has a few libraries updated like libgit2 0.28.5, libva 2.7.0 and libva-gl 2.7.0. Several patches and five Common Vulnerabilities and Exposures security fixes were made to the high performance, multi-platform VNC client and serve tigervnc 1.10.1. Midnight Commander (mc) 4.8.24, which is a text-mode full-screen file manager and visual shell, provided new skins and added yabasic (Yet Another BASIC) syntax highlighting. A minor update to plymouth’s 0.9.5 version removed unused kernel-headers and module-init-tools build dependencies and the xfce4-settings 4.14.3 updated translations and modified the display to allow for the use of a proper fallback configuration on “apply” and “toggle off”. The xfwm4 4.14.1 package, which is the window manager for the Xfce environment, fixed hostnames that were not showing initially when running apps remotely and the update fixed a crash with the Graphics Library that involved high CPU usage without a monitor. The snapshot is currently trending stable at a rating of 93, according to the Tumbleweed snapshot reviewer.

A new major version of the Mozilla Firefox browser was released in snapshot 20200413. The new 75.0 version improves the behavior performance on Linux when clicking on the Address Bar and the Search Bar, which now matches other desktop platforms; a single click selects all without primary selection; a double click selects a word; and a triple click selects all with primary selection. Additionally, Firefox is now available in Flatpak and a CVE memory safety bug for Firefox 75 and Firefox ESR 68.7 were fixed. The btrfsprogs package jumped from version 5.4.1 to version 5.6 and supports new hash algorithms in the 5.5 Linux Kernel; the new version also supports LOGICAL_INO_V2 features in logical-resolve. The new option ‘-o’ helps advanced dedupe tools. The libostree 2020.3 library was update in Tumbleweed from it’s previous 2019.6 verion; nine months of updates bring several newer features and fixes like support for making the /sysroot mount pointread-only upon start, and the error-handling around GPG verification was overhauled. Text editor nano 4.9.2 fixed a crash after undoing an at the end of a leading whitespace. The snapshot is currently trending at a moderate 83 rating on the [Tumbleweed snapshot reviewer](https://review.tumbleweed.boombatower.com/).

Snapshot 20200411 is also trending at an 83 rating and provided less than a half dozen updated packages. GNOME’s gnome-weather 3.34.2 package fixed an unknown temperature and cloud conditions bug when using autolocation. The yast2 4.2.81 version retranslated the wizard help button in the ncurses User Interface. Updates were also made to yast2-packager 4.2.61 and yast2-tune 4.2.3.

The ncurses package was update in the 20200410 snapshot; the new version added a configure option and a check for the GNU Compiler Collection -fvisibility=hidden feature. The snapshot also had an update to gcc9 9.3.1. Peripheral Component Interconnect, USB and vendor identifications were updated in the hwdata 0.334 package. Many incremental improvements and bug fixes were made with the update to libvirt 6.2.0. The new libvirt implements a QEMU 5.0 feature allowing for NVDIMM memory support for pSeries guests, which is done by adding a ‘uuid’ element in the memory XML that can either be provided in the XML or, if omitted, generated automatically. Salt 3000 has arrived in Tumbleweed; the new Salt version removes the date versioning, provides new functions to chroot: apply, sls, and highstate. It also updates slot syntax to support parsing dictionary responses and to append text. The snapshot will likely record a moderate 82 rating on the Tumbleweed snapshot reviewer.

Snapshot 20200409 recorded an 82 rating and provided an update to flatpak 1.6.3, which fixed a regression in the progress calculation for applications using extra-data. User space utility strace 5.6 provided several improvements like the ability to silence specific messages using -e quiet/–quiet qualifier (an alias for the -q option), including those that couldn’t be silenced previously (path resolution messages and “superseded by execve”). Another noteworthy package updated in the snapshot was the update to the LLVM Compiler; llvm10 10.0.0 brings new tools like llvm-ifs, llvm-install-name-tool and llvm-reduce.

In the times of Covid-19 and the people staying at home it is an adventure to get the tools to work from home without missing the benefits of face-to-face meetings.

There are a lot of solutions out in the wild. But one promising solution is Jitsi. Until now we used the instances provided by other people.

But now we are able to introduce:

Our own Jitsi instance

It is based on openSUSE Leap 15.1 and uses docker containers to deploy Jitsi. The current security warnings were also considered, furthermore the setup uses secure LDAP and HTTPS.

You need an openSUSE(community) account to login.

A few remarks about meet.opensuse.org:

• It is a 8 CPU VM with 16 GB of RAM
• This is still a “Beta” system
• We don’t know how Jitsi scales
• We will try to keep the downtimes as low as possible

The plan for the future is to package jitsi for openSUSE and to deploy an instance with packages.

If you find bugs or experience any problems please report to admin@opensuse.org or find me on Freenode with the nick lethliel.

I hope you enjoy it and have fun :-)

Marco