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

Those working remotely or managing a distributed team know it: face time is invaluable. The former openSUSE team has been using http://sqwiggle.com to keep in touch and Google hangout to hold a stand up meeting every morning. We like the Sqwiggle approach. Although the last updates have made it worse, the concept of having a peep to your colleagues' desks to know if they are there (even if they are working hard or just talking to someone) and the possibility of starting a video conversation just clicking on the face shot can do a lot in reducing distances (and in killing the temptation of working naked for home-officers).

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 :-)

Investigate the good way to put sikuli into openqa. 1. review current status of sikuli project

We have some internal systems for videoconferencing like Big Blue Button or OpenMeetings. But in my experience none of them can compare to Google Hangouts, which is still the best free (as in free beer) alternative for videoconferencing with integrated screen sharing. While implementing an alternative to Sqwiggle on previous hackweek, I discovered Janus, a lightweight WebRTC gateway that proved to be a quite capable tool to implement video applications.

A new Puppet Master will be set up for the openSUSE and public SUSE infrastructure. We will need to move the puppet code from the old server to a new Gitlab instance, deploy it to the new box with r10k, and perform syntax, validation and RSpec testing through ci.opensuse.org

During the last CSM workshop we identified the need to have a good way to share the images we use for testing. We have documented the requirements and the current status in this wiki page (we even have a diagram). So analysis is done... it's time for action. The solution should be relatively easy to implement using our portfolio of solutions. Coordinating all the potential users should be easier during Hackweek, specially since I'll be in Nuremberg (and I can physically chase most people ;-) ).

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 goal of openQA is "test as a QA engineer". But openQA has no ears - all we can test for are DTMF sounds. And even those are very bad. So my hackweek project is to do research on how to do proper sound verification. The keys are proper normalization of the volume and the sample rate.

We are right now testing a patch to Janus that will hopefully give us the stability we were missing in http://jangouts.suse.de. As a consequence, it's reasonable to expect a wider usage of Jangouts inside the company. Thus, I want to share maintainership of Jangouts as much as possible. The more developers know how to fix errors and implement features, the better. We already have a roadmap for the next two versions (0.4.0 and 0.5.0) but I don't want to spend my whole hackweek implementing those features in isolation. I would rather follow a workshop approach to welcome new contributors within the company (or outside, of course), so we get the stuff done and fix the single point of failure for the same price.

Right now, every time a new team wants a new room in our Jangouts instance, they have to ping me and I have to manually create the room. That means: * Adding some lines to the corresponding config file

The current Jangouts UI is limiting us when thinking about adding new features. Some examples: * This (using the whole thumbnail to pin a participant) was implemented, but the result is far from optimal (I have not even deployed it in production).

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.

I'm using Conversations (XMPP+OMEMO) as an encrypted IM solution. Since a lot of groups organizing them self using WhatsApp, it's hard to stay away from it.

After an internal call for help to take over software.opensuse.org deployment, I spend some time studying the code in order to find out what would it mean to take it over. The main reason was a PR from the community that has not been merged, and deployment depending on internal SUSE employees.

Quite a big part of openQA is testing the installation of SUSE products. All of them are installed by YaST. So a big quantity of problems found during openQA testruns are YaST problems. To find out what has gone wrong during installation YaST developers need to download the tarball containing the logs, unpack it and find the y2log among many other log files. That makes it quite complicated to just have a quick view on a problem.

Hackweek 18 Update

What Has Been Done During HackWeek 18

There is a running gag built into openQA called interactive mode. It goes like this: "if you need the interactive mode, it's broken". The reason: the so called interactive mode is a collection of hacks - in theory making it possible to update needles in a running test. But in fact it's a UI desaster that almost never works. So the goal of this hackweek project is to get rid of it - and instead build a real control from the webui into the backend allowing tests to be written on the fly including needle creation/updates. Easy as that.

Motivation / Problem

Right now, our QA team tests YaST with OpenQA very much based on keyboard shortcuts: Set the keyboard focus to the "User Name" input field with Alt-U, enter a user name, [Tab] to get to the next field, enter more text, finally Alt-N to activate the "Next" button.

The idea is to create a bootable medium (eg. pendrive) that allows: * Selection of either SLES, Leap or Tumbleweed.

Yes this project is yet another project for creating a Suse Manager clone. The motivation for that comes mainly from my need for a simple suse manager that i can easily run at home without the massive overhead involved in suse manager setup. Also since i mainly need to manage opensuse machines most of which are tumbleweed, suse managers repository model does not really work well in that case.

YaST dumps quite information to its own log file (placed at /var/log/YaST2/y2log). That info is very useful to understand and discover what is happening when an issue appears. All YaST modules write into this log file, and the brand new yast2-storage-ng is not an exception. Some improvements are necessary regarding to the logging of this new module: * Libstorage-ng is the C++ library powering the rewrite of the YaST storage stack. For using libstorage-ng from yast2-storage-ng in a more Ruby-like way, we created a wrapper that provides several features like automatic downcasting. But the current downcasting mechanism used by the wrapper causes libstorage-ng to introduce a lot of noise in the YaST logs. It would be nice to reduce that noise.

Let's use the Hackweek to improve Ruby, the programming language I use every day. It is while using a language when you can realised that things that need/can to be improved, so there are many things that only Ruby developers can raise up. Also, getting involved in the development of Ruby will help to get a better understanding of how it works. So I will take my ideas/concerns to the Ruby community and implement some of the them in the code of the Ruby core. Ruby features and bugs are tracked in https://bugs.ruby-lang.org/projects/ruby-trunk/issues

A good way of getting to know a new programming language is... writing some code. So although there are some good IRC bouncers, like ZNC, we want to write another one just for learning. But why an IRC bouncer? Because it is not rocket science, but it implies network communication (acting as client and as server at the same time), handling concurrent connections... in a few words: it sounds fun.

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:

Motivation: "Make Jangouts Great Again!!"

Mozilla's DeepSpeech project[1] is using TensorFlow and some paper from Baidu to make an open source speech to text system, based on deep learning (TensorFlow). The current project allow the training for own local datasets, but also there is a pre-trained model that can be used during the development. The goal of the project is:

Idea is create applet with same functionality which provided by network-manager applet . Gather more detailed requirements is part of fun :)

Right now, during the (open)SUSE installation process, the changes to be performed on the storage devices are presented as a list of actions such as: * Resize ntfs partition /dev/sda1 by 100 GiB

As we have grown in our remote and non official office at Gran Canaria we had to rent another space. This new office is almost empty and we need a little bit of love to improve the sensation of relax and commodity while we do what we love most. The main target of this project is to kickstart the decoration process, creating a minimum plan of what we want to achieve and step the first steps :smile:

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

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.

Project Description

I started developing Loggee as a CLI to interact with Board Game Geek and it's API. I wanted to have an easy way to see my games and log my plays in the site, and as a bonus, learn more of the functional programming language Elixir.

Project Description

Do you need to record podcasts or interviews remotely?

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

Let's write a decent replacement for software-o-o. We want to choose the right technologies for the project, as technologies and missing volunteers is where we failed this time.

Project Description

SUSE IT needs help from fellow geekos with release engineering skills to define the requirements, process, infrastructure, and tools for building an openSUSE-based distribution bundled with SUSE IT-supported application stack. The resulting OS build will be offered as a standard distribution for new SUSE employees in addition to the existing Operating System library.

Project Description

The main goal is to enable the use of plain dm-crypt (as btrfs makes LVM2 unnecessary overhead) and a separate ephemeral key for the swap partition.

Project Description

The ultimate goal is to create agama live image that is really small iso and with minimal memory requirements. It provides just agama CLI and remote connection to web server. So no embedded browser.

Project Description

software.opensuse.org is a web-service part of openSUSE project which give users can search and download RPM packages from openSUSE Build Service, it has capability to mark package is released from the official distributions as a official release package, or get the package from a unsupported project, like EOL'ed distribution and/or user's personal project. I'd like dig into software-o-o source code, try to fix some known issues, like the search result from Leap 15.5 and Leap 15.4 official project has not recognized to be an official release package and are listed in unsupported projects.

Project Description

Research about the integration of Ironic in Uyuni for automating provisioning of bare metal machines.

Initially, the Agama D-Bus service was written 100% in Ruby. For many things, it relies on YaST, so it makes sense to use the same language. It was great to have something working quickly, but it also had some drawbacks. The main problem is that, as YaST is not thread-safe, we separated the service into different processes (storage, software, localization, etc.). The system became most responsive but at the cost of eating a lot of RAM.

Moving to Rust