I started using Emacs in 1995, and since then I have been carrying a .emacs that by now has a lot of accumulated crap. It is such an old configuration that it didn't even use the modern convention of ~/.emacs.d/init.el (and it looks like a newer Emacs version will allow .config/emacs as per the XDG standard... at last).

I have wanted to change my Emacs configuration for some time, and give it all the pretty and modern toys.

The things that matter the most to me:

• Not have a random dumpster in ~/.emacs if possible.
• Pretty colors.
• Magit.
• Rust-mode or whatever the new thing is for rust-analyzer and the Language Server.

After looking at several examples of configurations that mention use-package as a unified way of loading packages and configuring them, I found this configuration which is extremely well documented. The author does literate programming with org-mode and elisp — something which I'm casually interested in, but not just now — but that way everything ends up very well explained and easy to read.

I extracted bits of that configuration and ended up with the following.

Everything in ~/.emacs/init.el and with use-package

;; Initialize package system

(require 'package)

(setq package-archives
      '(("org"     .       "https://orgmode.org/elpa/")
        ("gnu"     .       "https://elpa.gnu.org/packages/")
        ("melpa"   .       "https://melpa.org/packages/")))

(package-initialize)
;(package-refresh-contents)

;; Use-package for civilized configuration

(unless (package-installed-p 'use-package)
  (package-install 'use-package))
(require 'use-package)

(setq use-package-always-ensure t)

~/.emacs.d/custom.el for M-x customize stuff

;; Set customization data in a specific file, without littering
;; my init files.

(setq custom-file "~/.emacs.d/custom.el")
(load custom-file)

Which-key to get hints when typing command prefixes

;; Make it easier to discover key shortcuts

(use-package which-key
  :diminish
  :config
  (which-key-mode)
  (which-key-setup-side-window-bottom)
  (setq which-key-idle-delay 0.1))

Don't pollute the modeline with common modes

;; Do not show some common modes in the modeline, to save space

(use-package diminish
  :defer 5
  :config
  (diminish 'org-indent-mode))

Magit to use git in a civilized fashion

;; Magit

(use-package magit
  :config
  (global-set-key (kbd "C-x g") 'magit-status))

Move between windows with Shift-arrows

;; Let me switch windows with shift-arrows instead of "C-x o" all the time
(windmove-default-keybindings)

Pretty colors

I was using solarized-dark but I like this one even better:

;; Pretty colors

(use-package flatland-theme
  :config
  (custom-theme-set-faces 'flatland
   '(show-paren-match ((t (:background "dark gray" :foreground "black" :weight bold))))
   '(show-paren-mismatch ((t (:background "firebrick" :foreground "orange" :weight bold))))))

Nyan cat instead of scrollbars

;; Nyan cat instead of scrollbar
;; scroll-bar-mode is turned off in custom.el

(use-package nyan-mode
  :config
  (nyan-mode 1))

Move buffers to adjacent windows

;; Move buffers between windows

(use-package buffer-move
  :config
  (global-set-key (kbd "<C-S-up>")     'buf-move-up)
  (global-set-key (kbd "<C-S-down>")   'buf-move-down)
  (global-set-key (kbd "<C-S-left>")   'buf-move-left)
  (global-set-key (kbd "<C-S-right>")  'buf-move-right))

Change buffer names for files with the same name

;; Note that ‘uniquify’ is builtin.
(require 'uniquify)
(setq uniquify-separator "/"               ;; The separator in buffer names.
      uniquify-buffer-name-style 'forward) ;; names/in/this/style

Helm to auto-complete in grand style

(use-package helm
 :diminish
 :init (helm-mode t)
 :bind (("M-x"     . helm-M-x)
        ("C-x C-f" . helm-find-files)
        ("C-x b"   . helm-mini)     ;; See buffers & recent files; more useful.
        ("C-x r b" . helm-filtered-bookmarks)
        ("C-x C-r" . helm-recentf)  ;; Search for recently edited files
        ("C-c i"   . helm-imenu)
        ("C-h a"   . helm-apropos)
        ;; Look at what was cut recently & paste it in.
        ("M-y" . helm-show-kill-ring)

        :map helm-map
        ;; We can list ‘actions’ on the currently selected item by C-z.
        ("C-z" . helm-select-action)
        ;; Let's keep tab-completetion anyhow.
        ("TAB"   . helm-execute-persistent-action)
        ("<tab>" . helm-execute-persistent-action)))

Ripgrep to search in grand style

;; Ripgrep

(use-package rg
  :config
  (global-set-key (kbd "M-s g") 'rg)
  (global-set-key (kbd "M-s d") 'rg-dwim))

(use-package helm-rg)

Rust mode and Language Server

Now that RLS is in the process of being deprecated, it's getting substituted with rust-analyzer. Also, rust-mode goes away in favor of rustic.

;; Rustic, LSP

(use-package flycheck)

(use-package rustic)

(use-package lsp-ui)

(use-package helm-lsp
  :config
  (define-key lsp-mode-map [remap xref-find-apropos] #'helm-lsp-workspace-symbol))

Performatively not get distracted

;;; Show a notification when compilation finishes

(setq compilation-finish-functions
      (append compilation-finish-functions
          '(fmq-compilation-finish)))

(defun fmq-compilation-finish (buffer status)
  (when (not (member mode-name '("Grep" "rg")))
    (call-process "notify-send" nil nil nil
          "-t" "0"
          "-i" "emacs"
          "Compilation finished in Emacs"
          status)))

Stuff from custom.el

The interesting bits here are making LSP work; everything else is preferences.

(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(column-number-mode t)
 '(custom-safe-themes
   (quote
    ("2540689fd0bc5d74c4682764ff6c94057ba8061a98be5dd21116bf7bf301acfb" "bffa9739ce0752a37d9b1eee78fc00ba159748f50dc328af4be661484848e476" "0fffa9669425ff140ff2ae8568c7719705ef33b7a927a0ba7c5e2ffcfac09b75" "2809bcb77ad21312897b541134981282dc455ccd7c14d74cc333b6e549b824f3" default)))
 '(delete-selection-mode nil)
 '(lsp-rust-analyzer-display-chaining-hints t)
 '(lsp-rust-analyzer-display-parameter-hints nil)
 '(lsp-rust-analyzer-macro-expansion-method (quote rustic-analyzer-macro-expand))
 '(lsp-rust-analyzer-server-command (quote ("/home/federico/.cargo/bin/rust-analyzer")))
 '(lsp-rust-analyzer-server-display-inlay-hints nil)
 '(lsp-rust-full-docs t)
 '(lsp-rust-server (quote rust-analyzer))
 '(lsp-ui-doc-alignment (quote window))
 '(lsp-ui-doc-position (quote top))
 '(lsp-ui-sideline-enable nil)
 '(menu-bar-mode nil)
 '(package-selected-packages
   (quote
    (helm-lsp lsp-ui lsp-mode flycheck rustic rg helm-rg ripgrep helm-projectile helm buffer-move nyan-mode flatland-black-theme flatland-theme afternoon-theme spacemacs-theme solarized-theme magit diminish which-key use-package)))
 '(rustic-lsp-server (quote rust-analyzer))
 '(scroll-bar-mode nil)
 '(scroll-step 0)
 '(tool-bar-mode nil))
(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 )

Results

I am very happy with rustic / rust-analyzer and the Language Server. Having documentation on each thing when one moves the cursor around code is something that I never thought would work well in Emacs. I haven't decided if I love M-x lsp-rust-analyzer-inlay-hints-mode or if it drives me nuts; it shows you the names of function arguments and inferred types among the code. I suppose I'll turn it off and on as needed.

Some days ago, before using helm, I had projectile-mode to work with git checkouts and I was quite liking it. I haven't found how to configure helm-projectile to work; I'll have to keep experimenting.

Dear Tumbleweed users and hackers,

The last week was filled with success. The major change was surely the removal of python2-FOO modules from the distro. Not exactly all are gone yet (packages that fail to build do also not change the published modules), but we went form 2564 (Snapshot 0417) modules down to 203 (0422). But of course, that’s not all that has happened. After all, we released 6 snapshots in the last week (0415, 0416, 0417, 0419, 0421 and 0422).

The noteworthy changes therein were:

• Python2 removal (modules; keep in mind: interpreter, python2-pip and python2-setuptools stick around a bit longer for the users to consume)
• Mozilla Thunderbird 68.7.0
• KDE Frameworks 5.69.0
• Systemd 245
• util-linux 2.35.1
• Linux kernel 5.6.4
• Poppler 0.87.0
• VLC 3.0.9.2
• Sudo 1.9.0rc2 (see announcement mail)

Many things that were in stagings last week are still there, but are getting closer to be shipped:

• GNOME 3.36.1 (Snapshot 0423+)
• KDE Applications 20.04
• Guile 3.0.2: breaks gnutls’ test suite on i586
• Qt 5.15.0 (currently beta3 is staged)
• Switch from Ruby 2.6 to 2.7 (some preparations/fixes are coming by regularly)
• GCC 10 as the default compiler

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