The idea is to port client module of libvirt(x86) to android-arm. Currently, The project only plans to supoort kvm.
The project includes a dynamically linked library and a management user interface(virsh).
one of the top features a distribution must always ship in a working state is wireless. Yet we have no way to test it in an automated way. To be able to do that via openQA we need qemu to emulate a wireless adapter. Whether it's emulating existing hardware or implements some virtio device that only works on Linux doesn't matter.
almost 4 years
2 hacker ♥️.
Has no hacker:
Currently the last working images for ARMv7/v8 are openSUSE 12.3 based. Since then a lot of new features and regressions have been introduced, so it is time to refresh the appliances based on 13.1 and make them work.
over 4 years
8 hacker ♥️.
Has no hacker:
Aarch64 was added into UEFI spec recently, and the patches already landed into edk2. The goal of this project is to make an UEFI image to run on the Foundation Model and package Aarch64 edk2 in OBS, so that everyone can just download the latest image and play it.
over 4 years
1 hackers ♥️.
Has no hacker:
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.
The UEFI image for QEMU/AArch64 is available in the openSUSE build service now. However, there is no openSUSE image for that setup. This project is to make openSUSE run on QEMU/AArch64 + UEFI and this may be useful for the openQA in the future.
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.
Sometimes a user might want to build her own kernel instead of using the provided binary, for various reasons. This means creating own .config and maintaining it through kernel version bumps, which often results in running "make oldconfig" and mostly holding down the enter button to accept upstream defaults.
What I envision instead is a way to say where I want my own config to deviate from the distro default (as provided by e.g. kernel-stable on openSUSE), and only those options will override the distro default configuration. This distro default configuration is always updated for new upstream releases, so there should be no need to (manually or automatically) accept new upstream defaults, thus less risk of producing a broken kernel, as e.g. any new kernel options will be configured in the distro kernel so that they work with the distro itself (while upstream defaults might not be safe or desired).
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.
A broad range of ARMv7-A boards have been enabled in openSUSE already. I would like to complement my experiences by bringing up Linux on an ARMv7-M board, the STM32F429I discovery board, featuring a Cortex-M4 and 8 MB SDRAM.
As first step I would build and deploy an image based on instructions from the Internet, using downstream U-Boot and kernel and known-working binary arm-uclinuxeabi compiler toolchain. As preparation I have already packaged the genromfs tool.
Octopuses have many ARMs, so we should definitely allow them to run on them too!
Today, we don't have working Ceph packages for AArch64, but already solid interest from customers asking us about it. It would be great to be able to give them something to play with.
over 4 years
5 hacker ♥️.
Has no hacker:
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:
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.
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.
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.
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,
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 python3-kiwi rewrite of kiwi is progressing is far enough to try converting the openSUSE ARM appliances to make use of it. The goal of the project is to build appliances with python3-kiwi and test them to see that they work fine and then switch over if it seems benificial.
over 4 years
3 hacker ♥️.
Has no hacker:
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.
Following Tizen and other internal initiatives, to have Factory complete or partially compiled with Address Sanitizer and give it openQA a try to "fuzz" it, looking for memory management issues:
over 4 years
3 hacker ♥️.
Has no hacker:
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.
Patches for supporting SGI Octanes are floating around since ages. The latest version is against v4.10. I've talked to Ralf Baechle (MIPS kernel maintainer) and he is willing to take patches from me... so I have to provide them... and this what this project is for:-)
The only Mediatek "hacker" board available is from 96 Boards . Unfortunately up to now there is nearly no mainline support.
Idea would be to improve this situation. The idea would be to get the pin-controller merged first and then hopefully most of the other stuff can be just added (fingers crossed...)
almost 4 years
3 hacker ♥️.
Has no hacker:
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).
The Khadas VIM (http://khadas.com/vim/) is an arm64 DIY Set-Top-Box based on Amlogic P212 reference board that use S905X SoC.
As Odroid-C2 (based on S905 SoC) is in the mainline U-boot, it should be possible to adapt it for the Khadas VIM (of course a lot of work are needed!).
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.
With the teres-1  laptop we have a first arm64 device we could use as end-users. Much work to run mainline kernel + u-boot was done already. But power consumption of the laptop is not optimal (~2 hours of battery life time).
The idea is to support cpufreq for the A64 SoC upstream, which would enable the teres-1, pine64 and pinebook to run more power efficient. up to now it seems nobody is working on the driver .
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.
The mhvtl tape library emulation package was originally based on the scsi_debug kernel driver, but has long since grown more complicated, with the mhvtl,ko kernel module now passing almost all SCSI commands to user-level daemons via a clunky device interface. It does this with an out-of-band driver, since the design is so bad it would never be accepted upstream.
And with the 4.20 kernel release, it has broken yet again, which is par for the course with out of band drivers.
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.
TensorFlow makes it easy for beginners and experts to create machine learning models for desktop, mobile, web, and cloud. But from installation guide to best practice there're rarely cases mentioned tensorflow on OpenSUSE. So OpenSUSE needs to be introduced to tensorflow community.
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.
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 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.
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.
py-spy is a python profiler (similar to pyflame (which is unmaintained)). The profiler can be used to create profiling data for running processes.
This might be useful to find bottlenecks in OpenStack services.
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:
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.
In order to see the SPD (detailed memory information) data, the user currently has to manually load the needed kernel driver. Which driver to load depends on the memory type. Depending on the driver user, the devices may even have to be instantiated manually and this is a non-trivial multi-step task. Plus you need to be root to do it.
I would like to attempt to automatize all this at least in the most common and simple cases like Intel x86 desktop. The idea would be to figure out the memory type and the I2C address of the SPD EEPROMs based on DMI data. If the DMI data is of good quality then it should be possible to automatically figure out which driver to use and to instantiate the devices at boot time.
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
The goal of this project is to get an overview of the state-of-the-art technology on training and deploying machine learning projects with kubernetes and apply that to a SUSE CaaSP cluster.
With that in mind, we will train and deploy a model for summarizing github issues:
As we know, hardware accelerator is more and more important to AI/Machine Learning today, FPGA also comes to the front line beside with GPU. It is really helpful to understand its mechanism before deploying in a cloud environment.
I will go back to on my AC620 board, A Cyclone IV FPGA, and It has been a while since last time. As part of my FPGA virtualization Project, I will continue work on some simulation, refresh my verilog skill.
There are attempts to solve some kernel deadlock with using lockless printk ringbuffer. The proposed implementation is pretty complex (6 stages, 6 write and 6 read barriers, two buffers, entries linked via list, ...)
I have a idea how to make it easier with tracking the state and sequence number in one atomic variable. It might allow to remove the lists and many barriers. It is possible that it will just not work. Let's see.
Following trademark and licensing issues with Grafana, explore the possibility of debranding Grafana and use that in SUSE Manager (and maybe others)
Products are available from GitLab: https://gitlab.suse.de/susana
Install and test SUSE's Raspberry Pi distro on a Raspberry Pi 3 Model B. Explore the practical uses of stuffing a Linux distro on a bitty little single-board computer. Kiosk, digital signs, media server, gaming platform, digital photo frame, network attached storage...what is this little gadget good for?
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.
Following the work started in the last hackweek, Improve OBS service scripts, I will try to migrate current service script for workers to systemd unit, and at the same time, try to get rid of the sysv code.
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.
Modern Lustre supports compelling features like snapshots but it requires OSDs to use ZFS in order to implement it. Since ZFS and Linux licensing is incompatible, it's not really a supportable solution.
This project has an aim to implement Lustre OSDs using Btrfs underneath them, leveraging the btrfs feature set to enable the features that ZFS-based OSDs provide now in a supportable way.
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.
French ISP Free is providing a xDSL / Fiber modem, which includes a lot of features, including integrated NAS support and, more recently, allowing to run your own VMs (https://dev.freebox.fr/blog/?p=5450 sorry, in french)
Those VMs needs to run as aarch64 guests and might requires some adaptions for easy install with the modem webUI (cloud-init support, etc).
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.