Zeroconf/Bonjour/Avahi is a very interesting technique that targets at freeing users of services from tedious IP-based network configuration by automatic-distributed address-assigning, name-assigning and service discovery/browsing. It's named officially as zeroconf, Bonjour is the implementation in OS X, iOS and Windows, while Avahi is for Unix-like system. However, while Bonjour is popular and widely used in Apple products, few users take advantage of Avahi in Linux world and the number of applications that do integrate Avahi are still just a few and this feature is not often used.

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

Build Service needs an openid. Imagine following case:

The Problem: many bugs filed for openSUSE go to the screening-team by default and often remain there for weeks, so that developers (who would be interested in analyzing or fixing these bugs) do not learn about them. However, the screening process is a hard one

In order to build a community around crowbar, our cloud installer, we need to get this running on openSUSE as well. So let's find some time to move the packaging of crowbar from the ibs to the obs! In the end, there should be working packages in

In short, give second breath to http://hall.suse.de/bugs/defects.cgi. Long version: Create a generated page reflecting SUSE organizational structure and containing links to useful generated Bugzilla queries and charts like:

Talking to people, getting the information about what had happened in the SUSE history, bringing all together to kind of a chronicle. Let's give it a try :-)

Once again, the SUSE band is coming together to make music and we're planning a party this time round!!! We have a band name :-)

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>

In https://github.com/SUSE-Cloud/automation/ we already have mkcloud, which can setup a whole SUSE Cloud on a single host for testing. However, it would be cool, if (instead of a single machine) we could use cloud.suse.de with its capability to add extra networks as requested. This can be pretty easy, as much of the mkcloud code is about making libvirt do the right thing

using perl's Inline::Python module, it should be possible to define openQA test modules in python instead of perl.

I want to create devel project for cryptocurrencies/mining tools/blockchain related stuff, fill it with packages and submit at least some of them to Tumbleweed. Lets go on as Standa took care of creating network:cryptocurrencies

A lot of openSUSE bugs are filed with plenty details but without a specific assignee so often many days are lost between filing and a developer seeing the report. Instead of training a neuronal network to do artificial intelligence, this project focuses on the integration of how we can make useful proposals of assignments. It will probably use perl regexps for the start.

There is always something to do if you run the infrastructure for such a big project like openSUSE.... Our Admin wiki currently lists over 80 machines - and while we already "salted" some of them, there is always room for improvement and room to learn something new just by making your hands dirty and diving into the administrator role for a machine.

CephFS is awesome, but without a VPN it's not safe to be routed over the internet, and it lacks client support on many platforms. The Linux Kernel Library allows for the linux kernel to be built as a cross-platform user-space library and integrated into a regular Android, Windows, macOS, etc. application. This project combines CephFS, LKL and wireguard, and sprinkles some io-uring on top. My objectives are:

SUSE is using OBS as a build system and openQA for automated testing purposes. The goal of the study is to find out the strengths and weaknesses of these systems and compare them to other open source alternatives in a structured way.

I have been known to talk anybody I held presentations with into using odpdown. That was always a little awkward, since it started off with pip install odpdown, rather than zypper install odpdown. I want to fix this awkwardness and package odpdown properly so it can be installed as a RPM package. I'll also include the auxiliary infrastructure I've added around it over the years (various Makefiles and scripts for generating transcripts from comments) to the package so others can benefit from that stuff, too.

The idea is to hack os-autoinst-distri-opensuse infrastucture and explore design patterns that can fit. The end point of this is to restructure the framework in such a way that the main-common.pm is more efficient, functional and readable.

Create a prototype of an agent on kvm hosts to control the distributen of master / worker nodes between different kvm hosts. No central control plane should be used - the main design goal should be: as simple as possible :-)

There's a long standing request to extend the output of dmidecode to something that would be machine-readable. Something like an XML or JSON-based format. Unfortunately this can't be implemented right now because the output of dmidecode is generated by open-coded printfs as the DMI table is being parsed, with no intermediate structures nor temporary buffers. While implementing a machine-parseable output is out of scope for a single hack week, let's remember that even the longest journey starts with a single footstep. I would like to try and rewrite the 5200 lines of code of dmidecode in such a way that printing the output would be somewhat separated from parsing the DMI table and done by a limited set of dedicated functions. Alternative output formats could later hook into such functions.

https://gitlab.com/JanZerebecki/transparency-log-watcher Trillian is used for Reproducible Source, Build and Certificate Transparency. So it could be used to log the input to OBS and the build results and make zypper check it before installing an rpm. But currently clients wouldn't detect if the log shows them a different version than anyone else. See if there is a way so this can be detected.

Let's pick some old classic game, reverse engineer the data formats and game rules and write an open source engine for it from scratch. Some games from 1990s are simple enough that we could have a playable prototype by the end of the week. Write which games you'd like to hack on in the comments. Don't forget to check e.g. on Open Source Game Clones, Github and SourceForge whether the game is ported already.

Project Description

Since it has been near impossible to collaborate with other musicians at SUSE during the pandemic, I was considering an alternative music project for this Hackweek with any musicians at SUSE who might be willing to join.

Project Description

codename: opensuse-redir-cache