Lately the necessary patches to get rudimentary support for the Mediatek chromebook with a mainline kernel got posted. There are some hacks and I'll work on some good solution to get graphics go, at least.

I'm planning to do some research about RV32E which has only 16 GPRs, but riscv-pk doesn't have RV32E support so that the RV32E aware GCC (https://github.com/kito-cheng/riscv-gcc/tree/riscv-next) cannot build riscv-pk. I'm going to study how the proxy kernel works so that I can do some modification to let it support RV32E.

A week of learning, improving and playing with some of the relatively new front-end stacks and patterns.

since i am learning golang, i will make some contributions for the upstream project we used already @suse

DAPS, the "DocBook Authoring and Publishing Suite" provides a tool set for easy creation and publication of DocBook sources on Linux. DAPS lets you create HTML (incl. webhelp), PDF, EPUB, man pages, and other formats with a single command. DAPS is used and developed by the SUSE documentation team and hosted on https://opensuse.github.io/daps/ .

Mottainai - Task/Job/Build Server for everyone!

Functionality

Aim of this project is to create scenarios for manual deployment using limited feature set of mkcloud. Useful for situations when full mkcloud deployment is broken. It would help qam-cloud team a big time. We can reuse the result later in automation.

When doing the backport, I sometimes spend some time to check if the commit comes from a patch series and list all commits of a patch series. So I'd like to create a tool for doing this quickly.

I planned to write a GUI for mokutil since I started the project. I guess now it's time to do that.

This is a UEFI only device where openSUSE does not boot, hanging after loading the kernel and the initramfs even disabling secure boot.

First part is to support automated builds on git pushes also with gitlab, similar to what we do already with github.com. This means OBS would get notificated in a save way to refetch sources and start build on each commit.

The idea is getting a general knowledge of how QT Linguist works, and help FET with some translations.

We have a known defect exists in Staging Project process, according to the staging project design(in-ring/non-ring), the requests of a application stack can be dispatched to letter staging and adi staging both, in case the request staged in adi staging relies the request staged in letter staging which may causes sometimes the request in adi staging will not be checked-in at the same round, this leads that application stack have different version in TW and those package had request left in adi staging may does not work well as version unmatched to other library. We see this issue happened on Qt5 stack; KDE Applications, etc. For example: a Qt5 stack update, libqt5-qtbase will be staged in a letter staging however libqt5-qtwebview will be staged in a adi staging, once libqt5-qtbase be accepted that libqt5-qtwebview won't be accept in the same round due to it can not be built before libqt5-qtbase merged to Factory but after - 2-phase update. Therefore we need a way to handle those cases to reduce the gap between Letter staging and ADI staging.

The theory behind the partitioning proposal of yast2-storage-ng is that all possible distributions of partitions in the disk are evaluated and the best one, according to this criteria, is chosen. But I have found several examples in which is hard believe that the result is actually the optimal distribution of partitions.

• Setup Tensorflow on OpenSUSE 42.3
• Look for a way to package it

SLE Engineering have a large flatscreen in the shared space just outside of Thorsten Kukuk and Stefan Behlert's office

I will implement the ReaR upstream issue https://github.com/rear/rear/issues/1399

Currently I am using openSUSE Leap 42.2 as base system on the laptop where I do my daily work (Dell Latitude E7470). As a YaST developer my system is a bit broken (as you may guess) and updates are not possible. So it is time to start from scratch. The idea is to adopt some user friendly system for security copies, migrate to Tumbleweed, make extensible usage of virtual machines and try to stay the base system as clean as possible.

Crystal [1] is a new language with a syntax heavily inspired by Ruby, but with statically type check and compiled! Its motto is "Fast as C, slick as Ruby", so good reason to start looking at it.

YaST dumps quite information to its own log file (placed at /var/log/YaST2/y2log). That info is very useful to understand and discover what is happening when an issue appears. All YaST modules write into this log file, and the brand new yast2-storage-ng is not an exception. Some improvements are necessary regarding to the logging of this new module:

We got a couple of GSoC projects around Jangouts this year:

Let's dust off our Amigas, hook up our mice and joysticks, and see what elegant software and hardware could do back in the 80s and 90s!