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.
The first thing one should do when resolving a bug is to find out, whether that bug wasn't encountered and perhaps even fixed before. Using our internal Bugzilla's search, that can be long and painful task. I don't know if I'm querying it wrong, or if the problem is the amount of bugs (> 1M and growing quickly), or the number of users, or simply the Bugzilla itself. Also another problem is that some bugs have wrong metadata, which makes the efforts to narrow the search a bit harder.
There are many tasks necessary to do since PID 1 is started by kernel before the system can do any useful work. And those tasks ideally run as parallel as possible. Unfortunately, sometimes the dependencies and ordering can get wrong resulting into race conditions or deadlocks.
The goal of this project is to document in detail what happens when and explain the dependencies so it could be used as a reference when someone runs into a problem with their boot task.
We have quite some projects on openSUSE and os-autoinst organizations that are using travis-ci.org for testing their code. As travis-ci is using an ubuntu VM (or container) there are quite some things we can't test - or test by using SUSE containers within ubuntu VMs.
During hackweek I want to evaluate the github API for CI services and try to marry it with openqa.opensuse.org - I'll need a web service that does the tracking, but I'm optimistic that it can be done in a week.
over 4 years
9 hacker ♥️.
Has no hacker:
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.