Package a basic, stripped down version of sysvinit for emergency cases, so you can repair a failed system without interference. My goal is not to replace systemd with sysvinit again, but to provide a sysvinit-base package that does not have any dependencies at all and can just be installed on any system. sysvinit will only be used in exception situations by specifying the kernel parameter "init=/sbin/init" or something like that. The package will come with the binary, a minimal inittab and a basic boot script that does only the really needed stuff. Experiment with an extension to have sysvinit execve systemd, so people can boot into their allmighty uber-daemon once the system has been fixed.

The kdump package can now use SMP and multiple targets with constant memory requirements. The goal of this project is to find the optimum parameters for dumping a very large machine (SAP can give me access to 6TB, SGI is able to test with 64 TB).

Read in a crash or oops-style backtrace and access DWARF information to output the current content of the stack and registers in term of symbols, and the the crash commands to dump/pretty print them. In other words, when looking at a crash dump, answer the questions "Which variable is currently stored in $rax? What is the structure of the stack? Which variable is stored at $rsp+16?"

Status at the end of hackweek 10

Each of the core dump upload servers in Europe and USA could be improved if the shell scripts were combined so that the same tasks can be performed on each site, e.g. downloading of all packages needed for crash usage with a specified core dump by allowing for configurable (or even automated) selection of locations to obtain data packages from.

The current approach to having new hardware support and features in SLE kernels it to integrate changes to individual drivers from the mainline kernel back into the SLE kernel. The Linux Kernel Backports project (https://backports.wiki.kernel.org/) in comparison has an approach which consists in adding a shim layer between unmodified mainline drivers and older kernel interfaces. This project has its roots in wireless drivers. It currently supports only a handful of old ethernet adapters. The goal of this hackweek project is to integrate support for the Intel 1Gb pci-express ethernet driver e1000e into the Backports project. This particular driver was chosen because it is widely used and modern while not being exotic.

netfilter.org states that "nftables is the project that aims to replace the existing {ip,ip6,arp,eb}tables framework." The nftables kernel code was merged into the mainline kernel in January 2014. So it's time to get started with the <b>new</b> Linux firewall framework on openSUSE. <ul>

dropwatch is a utility which can help you to see if data is been dropped in linux network stack. The plan is to learn what actually dropwath can do and learn how does dropwatch work? and also learn how to use dropwatch? I'd like to get it working on openSUSE 13.2.

The disassembly in gdb is not ideal. The binding with source code lines is weird (even crash, which does use gdb beneath, does that better), I don't see the jump targets; furthermore, there's a lot more informations hidden in the DWARF2 which may be of some interest - like which code is inlined, or which register/stack address should contain some variable. My goal is to search for a way how to improve that.

Intel Active Management Technology (AMT) is hardware and firmware technology for remote out-of-band management of personal computers, this hackweek I'd like to spend some time to learn how to setup Intel AMT on my workstation and X201 with VNC enabled.

AFAIK, wireshark is the best Linux tool for analyzing network traffic. Primarily intended for Ethernet networks, there is now also support for very different protocols (e.g. USB). Sadly, there is no support for fibre channel, most likely because there is even no infrastructure in the kernel. I doubt I could write the complete stack within just one week. The result should be a clear plan of what needs to be done on each level and a proof-of-concept implementation of at least some parts.

Learn Coccinelle ,we need automatic kernel backporting with Coccinelle.

Look at static code analysis and code coverage for a C++ project, in this case libstorage-bgl-eval. This could include:

SCC doesn't require an email address, so could you automatically generate random keys until one matches and effectively 'steal' SCC licenses from customers?

gdb-kdump (and libkdumpfile) needs a plenty of improvements and tasks to be done. For HackWeek 13, Vlastimil chose to work on SLAB memory support, Petr, amongst other things, reorganized the libkdumpfile code and alnovak begun with libkdumpfile's ppc64 support. Our status in 4/5 of HackWeek 13:

SLAB

I have a few ideas of improvements for the delogo filter included in ffmpeg's libavfilter. As a first step I would like to clean up the code by removing one unneeded option and then removing all the subsequently dead code.

Dochazka is a long-term project to replace the obsolete Attendance & Time Tracking system used by the Prague office since 2007. Dochazka is a complex system consisting of three major components: - RESTful backend App::Dochazka::REST (with lots of help from Web::MREST)

This is about writing a tool to find differences in assembly files generated by gcc. The goal is to find the symbols in a program that have changed by a source code patch. This information can then be used to create and/or verify kGraft patches.

This is the tool I've been working on since HW11 and it needs more work. Actually, there's always something which could be done on it. It is basically an x86 instruction decoder with special emphasis on the kernel and decoding interesting pieces of it in order to help in the development of low-level patching techniques, among others. git repo: https://gitlab.suse.de/bp/x86d

At SUSE LabsConf 2015 we decided to run some sort of automated tests on the SLE and openSUSE kernels after each push to kerncvs.suse.de In order to make this work the kernel has to be build, a initrd and a rootfs image has to be generated for use with qemu, it has to be booted and tests have to be run.

Summary

A software developer, in particular at SUSE, needs a reliable and robust mail client.

L3 bug reproduction often requires becoming the admin for a moment. I'd like to write down some nifty tricks I used to get certain “interesting” system configurations to work.

jikos:~ # tc qdisc show qdisc tbf 10: dev eth0 root refcnt 2 rate 800Mbit burst 131000b lat 1.0ms

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

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.

With all those analyzers for C code we get so much information about our C code. Yet our shell code regularly nukes systems.

Kernel dumps, provided by our customers, are uploaded by Customer Support to ziu.suse.de and shared via NFS to L3 servers at which they're analyzed. This procedure works, but likely has room for improvement. The goal of the project is to understand the workflows and needs of Customer Support, L3 and engineering (Labs) and to implement a system to automate parts of the workflows.

New Development In previous hack weeks, the first few days ended up being wasted on just getting it working. I'm pleased to share that the code quality has improved dramatically since the last hack week and there are now extensive test cases for both unit testing and testing against real vmcores, and we'll use both mypy and pylint (if installed) to perform static analysis. Packages for those are available in openSUSE or as part of the crash-python OBS repo for SLE15. It has been tested with kernels from 3.0 to 5.1.

This will greatly enhance the usefulness of QEMU virtual serial ports, because the Linux kernel interprets a break on the serial console as a SysRq, but there is currently no way to pass this signal over a pseudo-terminal.

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

While DDR4 memory has become quite popular, decode-dimms doesn't know about it and is not able to display any useful information for DDR4 memory modules. I would like decode-dimms to provide the same detailed information about DDR4 memory modules as it does for all older memory types.

During regular L3 work I often don't find enough time to work on the command line disk partitioner parted which I maintain. Changes often directly affect yast-storage(-ng) and libstorage(-ng). @aschnell opens bugs faster than I can solve them. Upstream is often slow and often wants patches differently.

While there are plenty of benchmarks that compare different IO multiplexing techniques such as epoll vs poll/select, there's really nothing out there that particularly measures epoll system call latencies under different scenarios. Design and implement a series of performance benchmarks for this call under the 'perf bench' framework.

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

/media was a very comfortable thing standardized by FHS. After introduction of desktop based udisks mounts, the directory became empty. Paths like /run/media/me/directory or /run/user/1000/gvfs are used nowadays. When used from a terminal, it is very uncomfortable. As mounts are private to users, the old style of /media use cannot be returned back. But with a kernel namespaces feature, it is possible to make private mounts, and each user can see a different contents of /media.

I use the KDevelop IDE whenever I can. At SUSE mostly for reading code while debugging some bug. My plan is to create plugin that will show extra information inline with the code to make it easier to explore foreign code. Examples include showing names of function parameters at call site, elided types of variables (e.g. C++ auto, lambda parameters), comments next to closing brackets etc.

I use the KDevelop IDE whenever I can. At SUSE mostly for reading code while debugging some bug. My plan is to create plugin that will show extra information inline with the code to make it easier to explore foreign code. Examples include showing names of function parameters at call site, elided types of variables (e.g. C++ auto, lambda parameters), comments next to closing brackets etc.

The aim is to replace dump file read routines in makedumpfile with library functions from libkdumpfile. This should enable (among other things) filtering Xen DomU dump files.

RPMlint upstream milestone 2.0 is shaping up but there are still ticket that needs to be tackled to finalize the release and enjoy the freshness of awesome QA on Tumbleweed/SLE16. In this hackweek we plan to look on various problems as described at:

The current crash-setup source is located here. Pretty much is working nicely but it doesn't care for the debug source making it impossible to use the crash> gdb list *<symbol> command right away. This is bug 997558 which should be worked on.

grub2-minimize-config

Replace the config-generating scripts to generate a minimalist grub2 config

Check if it is possible to create a python application to aid autofocus micro adjustment on a DSLR. There are some commercial applications that are capable of that, such as Reikan FoCal (https://www.reikanfocal.com).

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.

Recently, ConnMan got support for iwd and WireGuard. The current support is only a starting point and it needs some more changes in the core code base to support the cool features:

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.

It's not always straightforward to open a core dump originating from customer's environment, since there's a wide variety of versions of all the binaries involved - usual workflow is to install a VM with the SP that the customer is using, enable debuginfo repositories and then follow the buildid hints that gdb is providing. However this sounds like a bit of an overkill. Lately, there has been a debuginfod project announced:

I'm hearing impaired. Where others have no issues following talks or dicussions, I often fail even grasp the bottom line what it's about. I've got hearing aids, but they help only so much. I also have an add-on device for my hearing aids that acts like a bluetooth headset. Unfortunately, making this thing work under my Linux desktop has been an ongoing, frustrating struggle. On the contrary, it works flawlessly with Android devices of different generations, and even with my lowly Gigaset phone. Actually, the thing works better with older kernels/Linux versions than with current TW. While I've little hope to solve the bluetooth audio issues on Linux for good, I hope at least to be able to understand better what's going wrong, and be able to slow down or even stop the deterioration I've observed lately.

Project Description

Do you need to record podcasts or interviews remotely?

Project Description

SUSE dissolved an old warehouse, containing lots and lots of boxes with old SUSE / SuSE / S.u.S.E software. All of those boxes were originally going to be dumped in March 2021, which could be prevented.

Project Description

multipath-tools is in urgent need of better CI, both unit tests and "real world" tests. We a very basic set of unit tests, but the coverage is miserable. Also, there's some minimal github workflow code, which could be improved a lot while I'm learning about github workflows.

Project Description

Grub has limited LUKS2 support in master branch for few months (only PBKDF2, Argon2 is not yet supported). It'd be useful to implement LUKS2 detection in grub-probe in order not have to specify required modules manually.

Project Description

Continue the port of btrfs kernel code to fscontext, started here

Primarily to support Hackweek, but also to gain experience for a potential future corporate use, I like to run the open source Jitsi in a SUSE context and within a setup that is close to what SUSE IT is doing. The service will be built in AWS/EKS within the SUSE E&I space and should be up and running on day 1, but will need love during the 5 Hackweek days to

We currently work on a consistency model for upstream livepatching infrastructure. We use something called a fake signal to speed up a finalization of the patching process. I'll port the implementation to kGraft in SLES which should allow to remove immediate patching since it has recently proved to be problematic...

Upgrade OBS crash to current upstream latest release Base version is the one before current upstream with many of the upstream current

Bisection is a well known method of localizing which commit caused a regression in a code repository. git-bisect is a particularly used tool for this problem in git repositories. However it is often the case that the failure is probabilistic in nature - either because we don't have a reliable reproducer of the failure and thus not reproducing a problem on a particular commit does not mean the problem is not still present there, or because of inherent variability of e.g. performance regressions. Bisection for such failures is problematic as it takes only one false result for the bisection to end up in an unrelated part of code history. So in these cases we usually have to heavily extend runtime of a reproducer or do multiple test runs or multiple bisection runs to minimize a chance of error. The aim of the project is to implement stochastic bisection for git. I.e., a method that will count with the fact that test results at each point of code history have some error rate and provide points in code history to test to find commit in code history that is with high probability introducing the regression in the smallest possible number of tests. Then we can use this method for bisection of performance problems in our performance testing grid Marvin.