openSUSE lacks useable cross-compilers to glibc systems. This is the attempt to provide those, most important a cross-compiler for arm/aarch64.

Look once again on Xperia Tablet Z and try to have there openSUSE running natively as alternative operating system. I'm able to work on that only during my vacations or hackweeks so

Non-Android Linux can already be booted on several devices that are based on CPUs from Allwinner, such as the A10 and A13, but support for the newer A23 is still incomplete. I want to use this Hackweek to work with the folks of the sunxi and Lima projects (http://linux-sunxi.org/, http://limadriver.org/) to get Linux up and running on an A23 based tablet.

Create a single node installation of OpenStack with the OpenSUSE OpenStack Quickstart scripts for 64 bit ARM (aarch64).

Learn ceph architecture and try to deploy a ceph cluster.

The virtualization team's automated testing has a long history. It was born in the old Novell Integration Test framework. The virtualization lab ran an instance of this framework for many years. Over time, those who knew the framework left the company, taking their knowledge and leaving little documentation behind. As our testing needs increased, we found the old framework insufficient, but saw little value in improving it given the available open source CI frameworks. Before burying ourselves in SLE12 development, we took some time to move our automated tests under control of a Jenkins instance running in our lab. Tests were configured to run when new packages landed in our SLE12 devel project, ensuring our queued SLE12 submissions were continuously tested. But more is needed.

openSUSE 13.2 is taking shape on ARM, but we need to make sure we smoothen its edges to make an actual release out of it. The goal of this project is to make sure all devices we should run on actually work and that the last few packages necessary for productive use of ARM devices work properly on 13.2.

Implement improved ftrace infrastructure for PPC64LE (goal 1), s390x (goal 2), ARM64 (goal 3) that is able to support kGraft and doesn't have a performance impact. PPC64LE has an experimental (untested) patch by Dinar Valeev already, s390x works, but has a 10% performance impact on the system, ARM64 is entirely untouched.

Pebble smartwatch is a nice gadget I own and I'd like to start playing with it at the code level. One goal would be to create a SUSECon / conference application for it, allowing to choose which talks I will attend and make sure the watch will notify me in advance a session will begin.

zypper is magic

A number of experiments suggest that it may be feasible to run zypper from an openSUSE 'live' media against a 'foreign' RPM based OS installation (eg. CentOS) and then 'zypper dup' to openSUSE

www.opensuse.org is the single most accessed page in the SUSE/openSUSE universe. With 1.5 million visits per month it generates 2.5 million page views and has around 500 people on the page at any given time. Yet it's one of the oldest, crufty pages we have! It doesn't concentrate on what it should do: Tell people about the distro so they download it. It's design is 5 years old, it's not mobile, it's not accessible. There is absolutely no interactive, engaging content at all and the technology used goes as far as a shell script/cron to update dynamic content.

The new SUSE Floor is nearly done. The core functionality is already implemented and only some basic features are left.<br> <br>

Some customers are still stuck in a world of 32bit. On ARM64, we have two options for those poor folks: 1) Run applications in the legacy ARMv7 instruction set

Today OpenQA mostly runs on virtual machines, but it can get really tricky to find bugs triggered by real hardware. There are only few interfaces required to interact with a machine though: 1) HDMI<br>

I previously created a semi-auto test script() for MOK. The script controls the QEMU virtual machine a pre-setup image and performs two simple test cases. It's tedious to setup the images for every SLE and openSUSE. My goal is to write a script to automatically set up the virtual machines and images and do a full test. I would also like to set up a test for weekly-built OVMF. openQA might be a good reference. () https://github.com/lcp/mok-autotest

VNC protocol transfers key symbols (= basically characters), not key codes (= "coordinates" on keyboard). Therefore pressing the same keys may result in sending different commands over VNC depending on the keyboard layout and state of modifiers on the client side. The server however can not directly send the key symbol to the application, it must instead find or create key code that will translate to that symbol and send that. This is hard to implement correctly and there was already several bugs about it.

Get openSUSE running in parallel to Android on a regular and rooted Android Smartphone. On top of this try to get a graphical desktop running using Xvnc available for Android.

Create a user interface useable with a see through head mounted display. The display was created from some Chinese video glasses and has a low resolution (320x240) which requires a optimized user interface that also is useful when using it hands free. The existing Head mounted display: https://jamballa.wordpress.com/2015/01/26/steampunked-hmd-1st-iteration/

In order to have complete cloud experience on Power platform it needs some missing pieces to be available: * SLEShammer image (SLE11-> SLE12)

Currently, the usual way to communicate with VM instances in the cloud from outside is ssh. This is okay for most uses, but a) does not work when you mess up with the guest's ability to network and b) requires a free floating IP. I wonder if, for qemu/kvm instances, it would be possible to use virtio-serial possibilities : from the guest, it is seen as a serial port, and from the outside, it is seen as a UNIX socket, or as something else. It is fast, as it does not go through virtualization and device drivers.

Apache Maven is a build tool used by many Java projects, which is incompatible with OBS in that it tries to download binary dependencies from the Internet. Several people have in the past years tried to somehow bootstrap Maven and failed. My new proposed approach is a Maven, patched to obtain packages from a filesystem location, and packages with .jar based -bootstrap.spec variant plus source-based build for properly modeling dependencies in OBS. Unlike the SUSE Manager team's work I am trying to rebuild those .jars from sources. Where necessary I am patching dependency versions to the latest sources/jars packaged.

Needing to learn git, I thought it would be a good time to clean up the code and create a git project for it.

In previous Hackweeks, we've gone to warp speed in our virtualization CI testing through: - Porting libvirt-tck to SUSE environments

Create packages for SLES 12 s390x in obs. The problem is, that we do not have the native build power on our s390x system.

Or at least, test as many of them as possible.

Working remotely has many advantages, but you sometimes lack some infrastructure. Specially if you use several computers or you share space with other SUSE co-workers. We are 3 Susers in Gran Canaria and we plan to share an office. So we have bought a Cubietruck, a tiny device with minimum power consumption, an ARM processor, a SATA interface and a Gigabit ethernet. The plan is to come-up with a set of recipes to configure such device to:

The idea would be to create a qt5/kde5 based utility that can use local raw images as well as download a list of sources from a remote site. The idea is to provide a user interface that can be used by any user as well as a user interface that can be used in kiosk mode for booths so that a visitor can put a usb pendrive in any usb slot, select the image he/she wants to write to it and get it written in parallel to other usb memories. https://github.com/openSUSE/imagewriter seems to be abandoned, so probably part of the backend will be reused and the user interface will be rewritten from scratch, but anyway this will be reconsidered at the first task in the project.

The software is a rails app with an Angular.js frontend using the gphoto2 library to trigger a Nikon D60 camera. Features: take pictures, browse pictures, automatic upload to a gallery (tumblr, flickr, owncloud), qr code for download,

Create a USB device that, when configured and connected, exposes one or more Ceph RBD images for use as USB storage, allowing for: * Ceph storage consumption by almost any system with a USB port

Tronsmart has a Rockchip rk3368 based set-top-box [1]. I want to use it as a arm64 based workstation running openSUSE.

Since my Orange Pi board just arrived, I will play with it. This includes:

COLO or Coarse Grain Lock Stepping is an High Availability solution that builds on top of Remus, 1. investigate Xen COLO implemention and try to play with it.

Packman reduction

Last time I checked QEMU lacked support for >= z10 processors. Thus one cannot run SLE12 and newer in a virtual machine on non-s390x host. I'd like to improve the situation during Hackweeks.

To make OpenQA work with real ARM devices, we need to control * Reset

Hikey is a development board with HiSilicon Kirin 620 eight-core ARM Cortex-A53 64-bit SoC. The original firmware is based on Tianocore EDK II, and I'd like to port coreboot to this board. Challenges:

This project aims for enabling FCoE over virtio-net. With that we should be able to run FCoE within a KVM guest, and finally have a 'real' FC host in a KVM guest. This should enable 'real' FC testing, like link failure, multipath operations etc.

The idea behind the project comes from recent work on integration of OpenDayLight with Suse OpenStack Cloud 6/7. The goal for this Hackweek project is to realize a demonstrable NFV use-case on Suse OpenStack Cloud with as much reduced manual orchestration as possible. The use-case to consider is to run a Service Function Chain(SFC) with basic Network functions like Firewall/QoS that run as services on JeOS Guests on SUSE OpenStack Cloud (SOC).

The support for Orange PI PC in mainline kernel has advanced a bit, so now it should be possible to build openSUSE image that has at least serial support with kernel 4.6 and usb support with 4.7. I will investigate this.

The Nokia N900 is a versatile phone/tablet/mini-computer. While its specs are outdated by today's standards, it's still hard to find something equivalently useful to hack on-the-go. Most of it's drivers are already upstream, with just a few components missing:

The openSUSE build service could build hundreds of packages in parallel but in practice serial package dependencies prevent that.

Goal

Try nfc device to control RPi

This was a short 2-hour fun project. I wrote a small execution module for Salt that takes a text string and a mode ("status", "warning", "error") as input and uses the Sense Hat's Python API to display the text on the Sense Hat's 8x8 RGB LED matrix display.

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.

Current virtualization requirements mainly come from fate, and I haven't got chance to try freely many features of qemu/libvirt. So I will try to play it.

Most large workloads such as SAP HANA require special, highly optimized configuration to run in a virtual machine. Virtual resources such as memory and CPU must be carefully configured to ensure optimum performance of the virtual machine workload. Default VM configuration created by tools such as virt-install are not optimized and often result in poor performance of large workloads due to memory access latencies and incorrect/incomplete information available to the VM's task scheduler. Currently, users deploying large workloads must manually optimize virtual CPU and memory resources, which can be error-prone and if not done properly can actually degrade performance. This project aims to create a tool that can produce suggested vCPU and vNUMA configuration based on a VM configuration template and capabilities of the target virtual machine host. E.g. something along the lines of

There seems to be an overall consensus that the ioctl interface used by ethtool is a poor design as it's inflexible, error prone and notoriously hard to extend. It should clearly be replaced by netlink and obsoleted. Unfortunately not much actual work has been done in that direction until this project started. The project started in Hackweek 16 (fall 2017) and has been worked on since, both in Hackweek 17-19 and outside. First two parts of kernel implementation are in mainline since 5.6-rc1, first part of userspace implementation (ethtool utility) has been submitted to upstream at the end of Hackweek 19 (2020-02-16).

Back in the day, I enjoyed coding on 8 bit machines, mostly MSX. There is now a Kickstarted project to create a successor machine with some new features: hardware sprites, hardware scrolling, better sound, integrated SD/MMC IO and an ESP8266 for networking. I will be spending HackWeek 0x10 exploring these new features via Z80 assembly.

SUSE Manager can do some virtual machines management, but needs a lot to be complete. This project is about investigating more on that topic.

I use my Raspberry Pi 3B as a router. I have seen this crash: * [34502.095007] Internal error: Oops: 96000004 [#1] SMP

Description

Play with raspberry pi to get high availability through load balancing and containers.

Trimatik MC is an older heating control from Viessmann. It has no supported digital interface for remote access, but I found at least two ways to get access to sensor data like various temperatures and state of relay contacts. One way is to use the so called remote control the other use the clock timer. This project will use the latter way, because the hardware adaption is much easier and and all four timer channels could be controlled as well. Remote access will be done via an ESP32, which emulates the clock timer and gets/pushes data via WIFI. Current prototype is able is able to monitor traffic between the original clock timer and the heating control.

Minnowboard is the platform for UEFI development and supports UEFI capsule update since 0.99, and we are supposed to be able to test the feature with fwupd. However, there is no capsule file in fwupd.org or the official firmware download site. Besides, the Minnowboard firmware source in the current edk2/edk2-platforms git couldn't build due to the recent change of directories. My goal is to rebase the Minnowboard build system to the current git master and create a working up-to-date firmware. Signing the firmware properly would be a plus so that we can apply a private repo in fwupd.org for the development or QA testing.

I want to get an openSUSE based image working on Samsung DEX: https://www.linuxondex.com/

Well the see of openSUSE Infrastructure has been unrest and need our attention. I would like to invite you for this cruise trip.

I have noticed that explaining HA cluster concepts to non technical people is not easy (my parents for example hehe). In order to improve that I would like to create a more visual project using raspberry pi-s.

1.Test to burn the opensuse kernel on Raspberry Pi and make it working. 2. Try to use Raspberry Pi to control some sensors.

RISC-V is an open ISA (Instruction Set Architecture) based on RISC architecture. It's originated from UC Berkeley and it's attracting more attention in recent years because of its full open architecture so every developer has opportunities to get involved in application processor design or apply it into different applications, such as IoT, Robotics, ... etc. Any topic about RISC-V is welcome, here are some topics you might be interested in:

We kinda need more flexible PXE in Prague office, UEFI would also not hurt - so lets check what we can do to make it better. EDIT (ggherdovich):

We already tried to improve the Jangouts data model in the past and, although we made quite some progress, we did not finish it. I've been playing a bit with React and Redux lately, and I would like now to try a different approach replacing Angular with that combo. Using Vue.js might be another option too. Of course, we are not going to rewrite Jangouts in just one week, but let's see how far we can go. By the way, the redesign branch contains some interesting stuff from one of the GSoC that we should consider.

PXEAT (stand for PXE Administration Tool) is a tool to easily deploy and manage PXE service. It's NOT a tool for automatic deployment. It can enable user to add their own PXE items by themselves, but of course, very limited for security reasons. The tool will be developed with the light-weight framework - flask, as well as a sqlite database.

The idea is about an easy way to allow users to make upgrades (e.g.: changing from one major version like 15.0 to version 15.1) using a GUI and as easy as they can in Ubuntu. Something like a notification with a button to perform the upgrade with just one-click, instead of having to deal with the terminal, that frights some new users and gives them the sensation of an outdated system.

Make a final attempt to implement a graphical user interface for grub2 (gfxboot2).

It's quite some work, unfortunately. Here's what's done so far:

The idea is to explore the technologies and the various components to realize some AI to predict pitfalls in source code which can potentially generate run-time misbehaviours. The potential area where this idea could have positive implications are:

The Goal is... to connect all the sources of information from our houses to the lighting system to produce a dynamic home environment where information is streamed to the users through a noninvasive and disrupted channel and, this way, avoiding a chain of human micro mental interruptions, like the ones that we have during all day produced by the mobile apps notifications and/or wall panels sounds or blinks and that causes anxiety, stress, and human disconnection.

The monitoring in our internal infrastructure needs some love and attention. I want to spent some time during this hack week on the monitoring by fixing old checks, implementing new checks and making sure that those are configured and installed via configuration management. Checks I have in mind for instance are:

Stream Radio device - It is built with Raspberry Pi Zero WH

Goal is to implement a rados backend in drivers/nvme/target. That will allow the NVMe target implementation to directly access Rados objects (ie export RADOS objects as namespaces), allowing third-party applications and/or OS to use NVMe-over-Fabrics to access a ceph cluster.

The goal is to create a set of YAML files describing L3 supported products with all metadata we need to store there - and a JS presentation layer automatically showing this data in several forms, one of them will be a part of our L3 documentation. Technology: HandleBars.js or similar, plus some YAML technology

Sorbet is a gradual type checker for Ruby. Ruby is a dynamic language, which is great for reducing overhead for small

This is a task to update current WSL-Launcher (which can be already buildt in OBS) with latest-greatest upstream code https://github.com/Microsoft/WSL-DistroLauncher Fork of fabian's project (initial work to get it working):

I would like to set up a small backup server on my spare hardware What I have:

This project aims to run VMs in a CaaSP 4 cluster using kubevirt and a libvirt+qemu container (aka compute container) based on SLES15 SP1/2. Compute containers based on openSUSE Leap15.1 and SLES15 SP1 already available in registry.opensuse.org and registry.suse.com respectively. VMs can be deployed to the cluster but there are several functional problems that need investigating, e.g. accessing the VM's serial and VNC consoles, proper network access, etc.

With the approach of kernel 5.6 SGI Octanes are supported with builtin IO components. What's missing for a graphics workstation is a driver for the graphics card. There is already a not upstreamed framebuffer driver for Impact graphic cards. Since there will be no new framebuffer driver accepted upstream, the goal of this project is to convert the existing frame buffer driver to a DRM driver and make it ready to be sent upstream.

I got a Raspberry pi 4 not long ago, I'd like to install openSUSE Leap 15.2(Alpha) on it, and set up hass - Home Assistant, a open source home automation assistant on rpi4, then have some fun with it! Update: hassio dropped py3.6 support in Dec 2019, since Leap 15.2 stays with python 3.6 rather that python 3.7, I've to use Tumbleweed instead.

I'd like a way to have a device on my desk which lights up to indicate that I have something I should be paying attention to. Initially, I'd like this to be for Office365 calendar events and GitHub mentions, but ideally it should support arbitrary messages. The plan is to assign specific colors (ideally "patterns" consisting of a sequence of colors and time) to specific message types. I have a handful of raspberry Pi Zeroes, a couple of OLEDs, a strand of individually-addressable RGB LEDs, a power supply, and some misc electronics (like the 3.3-5v logic level shifter necessary for the 5v LED strand). I'm thinking Python is probably the way to go for the software. I'm hoping OpenSUSE actually works on the Pi zero. :D If not, there's an ESP32 with a built-in display and a few Pi 3s laying around barely used, maybe one of them will work.

Whether it's building a newer, upstream UBoot, EDK II, or merely a SLE based rootfs, I want to make this platform a realistic possibility for desktop, digital signage, labs, etc.

The project aims to port openSUSE to the ROCKPro64. The ROCKPro64 is the most powerful Single Board Computer released by Pine64. It is powered by a Rockchip RK3399 Hexa-Core (dual ARM Cortex A72 and quad ARM Cortex A53) 64-Bit Processor with a MALI T-860 Quad-Core GPU.

Avahi is (among others) a domain names auto-configuration system for Linux compatible with Bonjour. The project is to dig into avahi source code to modernize it if possible and fix bugs.

The USB controller (Via Labs 805 XHCI) on the RPi4 sits behind a PCIe bus which has no drivers at the moment in u-boot. After implementing it, we'll also have to make sure the USB HID is correctly connected with UEFI routines.

For years we have been discussing the idea to modularize SUSE Manager. This would enable developers to create their own extensions to SUSE Manager without needing to touch the core repository. There are several frameworks that could be helping in that direction. The goal here is to create a Proof of Concept with the virtualization features moved into an add-on.

Overview

uMEC (aka MicroMEC, or Micro-MEC) is a project under the Akraino Edge umbrella. SUSE joined in 2019 and together with partners we managed to create the 1st prototype infrastructure.

Project Description

In the past year we've found ourselves in the middle of a pandemic, we merged two awesome companies together, and we have completely changed the trajectory of SUSE and Rancher. This project is intended to transfer knowledge of SUSE to Rancher and Rancher to SUSE for those who may be challenged with time and resources to try new things. This gives us a chance to explore other uses for Kubernetes all while taking advantage of older equipment (for use as workers) we may have to spare.

Before Cavium switched to ARM64 CPUs they developed quite powerful MIPS based SOCs. The current upstream Linux kernel already supports some Octeon SOCs, but not the latest versions. Goal of this Hack Week project is to use the latest Cavium SDK to update the Linux kernel code to let it running on CN23XX network cards.