There is now bunch of yast devtools but the most of them are obsolete or useful only for ycp developement, which is now dead. It is also mixture of tools to build package, develop single package and new yast meta for doing changes on all modules developed by yast team.
So goal is
During the YCP Killer project, Y2R didn't translate most YCP operators and builtins into equivalent Ruby constructs but into library calls. This was necessary to preserve behavior in various edge-case situations, mostly when nil was passed around. The resulting code is often long and hard to work with.
Example from SlideShow.rb:
ruby-ui was a hackweek project with jreidinger to make libyui (YaST text/graphical engine) usable from pure-ruby without going through YCP.
We experimented a bit extreme trying to make the usage of SLIM templates possible. It kind of worked.
almost 4 years
1 hackers ♥️.
Has no hacker:
Twopence is (will be) a remote execution engine for tests, able to run tests in virtual machines and real hardware through various means of communication : virtio for KVM / QEmu, ssh on top of libssh, serial lines. This library can be called from shell and ruby wrappers.
While it is already functional (and used), it still needs polishing, stabilizing, and extending. It is also planned to integrate it with Pennyworth (project Machinery) and let it go fully Open Source.
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:
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
Write a simple command line tool for getting the open pull request from github and put it into a trello card. The tool should periodically update a list of pull request.
In addition it would be great to have a connection between the trello card and github pull request.
The base version for uselessd is systemd-208, which is the version used in 13.1. Let's try if a direct substitution of the binaries works and watch out for the problems.
Expected result of the project is to have a working package with "Conflicts: systemd" and "Provides: systemd". The goal is not to fix all problems, a stripped down system with uselessd is considered a good achievement. Anything more complicated could build on top of this.
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).
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.
Moses is a statistical machine translation system that allows you to automatically train translation models for any language pair. Intention of the project is to tune up existing software, where a glimpse shows that majority of time is consumed by memory allocation, dynamic casting and other calculation non-related stuff. I would like to inspect many techniques (like perf profiling, GCC LTO, GCC profile-guided optimization, code refactoring, OpenTuner, etc.) which may bring really significant performance gain. Moreover, it would be really beneficial to come up with a cookbook that can be used by folk in general. If possible, I would like to create a step-by-step performance improvement graphs.
Starting with CUPS 1.6 things have changed considerably. Clients are no longer discovering broadcasted printers anymore. Distributions (e.g. Debian) has backported the original protocol into cups-daemon package but this doesn't seem to work either on my laptop. I would like to look and try to understand what the hack is going on here.
The outcome should be my understanding of the change and how to configure CUPs to behave reasonably again.
I'm in SUSE for about a month and as a fresh graduate I had to learn a lot of stuff during this period. And there is a bunch of other things I will have to learn of course. Therefore I would like to use Hackweek to deepen my knowledge of various tools, processes, techniques or other packagers related stuff. However it would be quite a pity to hold the acquired information just to myself. So I would like to keep the result of my learning for further usage either by enhancing the Innerweb wiki, the public openSUSE wiki or by creating new wiki for packagers' purposes.
Who can utilize this knowledge base? Newly employed packagers to learn important things quickly. Current packagers to share interesting techniques or hacks among them. Or just whoever else wants to quickly understand certain packagers' process or tool.
Maybe this is something we already know but I haven't found it. But found it really cool how Debian can be installed easily from Windows machines. Just have a look at http://goodbye-microsoft.com/
I have learned that our installation CD already can install OpenSUSE from Windows based systems so I think this shouldn't that hard to move this to we based installation.
over 4 years
1 hackers ♥️.
Has no hacker:
Continue development of generic job server in haskell with primary focus on continuous integration and later possibly as support tool for data analysis in semantic file storage server, software configuration engine, etc
Project hosted at https://github.com/yaccz/yac-build-server
Currently there is an internal OpenStack instance (cloud.suse.de). Most of the images there are outdated so it's common that everybody just uploads a new image.
Would be nice to have a tool which updates at least the most common images (SLE11&12, openSUSE, CentOS, Ubuntu, Debian, Fedora) automatically once a day. So ater spawning a new VM, there would be no need to first update (and maybe reboot) the machine or upload a new image before you can start to work.
over 4 years
3 hacker ♥️.
Has no hacker:
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.
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 ;-) ).
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.
My hobby project is about using Lego mindstorms to turn a lathe / turning machine into a CNC.
One missing piece is the "CAM" part that takes a 3D model and produces gcode that determines the tool-path.
The aim of the project is to create a stupid interpreter to evaluate arithmetic expressions and functions.
I have been reading a lot about Haskell and creating a stupid interpreter is a nice way to get started.
over 4 years
4 hacker ♥️.
Has no hacker:
As we know, we have ABC notation or GNU Lilypond for music staff.
It takes ASCII as input and generates music scores and even MIDI format, which is very convenient for people to type music in computer.
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
I'm trying to write a static analyzer for Lua programming language. And I've ready done some parts, say, lexer/parser/AST/types...etc.
The challenge part at present, is to write comment-based type annotation, for later type-inference. I plan to implement it in a week. I've spent years on this area. Hope I'm lucky in hackweek.
Writing code is wonderful, but it gets its real value, when it's released and shipped to the world. You know the mantra: "Release early, release often".
Releasing code is not hard, but it involves a lot of details, and you want to get them right, because a release is this public statement "Hey, it's done, it works, you can use it." and you can't take a release back, once it's out there. To help with releases there are tons of release scripts which try to automate things. But they usually are quite fragile in case something goes wrong and a pain to test and maintain.
With rust 1.9 released, it should be possible to from now on bootstrap rustc from the previous version of rustc (so 1.10 can be built using 1.9 etc.). This means that it should now be possible to create a rustc package which no longer needs binary snapshots to build, meaning that we might even be able to submit rustc for inclusion in openSUSE Tumbleweed.
This is the first goal.
YaST code organization is a mess at many levels (files location, namespaces, code dependencies...). Recently we created this gist to put some of the issues on the table
Many YaST developers will be at openSUSE Conference, that overlaps with Hackweek. The plan is to lock them all in a room with a blackboard and reach agreements on how the code should be organized in the future. Then use Hackweek to iron the details, document everything in some kind of style guide and, if time permits, even do some experiments about how to adapt the existing code to the new conventions.
"GNU Hyperbole is an open, efficient, programmable information management and hypertext system for GNU Emacs." (<https://www.gnu.org/software/hyperbole/>)
I used it quite some years ago. The last weeks it was a topic on the Emacs mailing list.
Every packager encounters boring manual tasks every once in a while and these tasks can most probably be automated to some extent. During Hackweek I aim to try and identify such cases in various packagers' workflow and consider creating a tool that would make these tasks easier. Also, I would like to find out whether there is a demand for such tool. In that case, this Hackweek project will turn into a long-term task I plan to keep working on.
Flatpak (previously known as xdg-app) is a bundle system, based on ostree, to easily make available applications bundle to users. Currently, flatpack is available on openSUSE Tumbleweed but we don't ship any runtime based on openSUSE (freedesktop or GNOME runtime).
Also, it could be interesting to generate flatpak bundle directly from OBS, if possible, using either available packages or directly application sourcecode.
Elixir is a Ruby-ish dialect of Erlang with meta-programming capabilities, this is my first project using it: pedro . The idea is to create a task manager that would organize tasks (jobs) and manage them in projects. It will be running locally, remotely or both in multi-node setup, will provide CLI, have web UI relying on http and websockets.
It makes use of erlang OTP, web framework phoenix that is inspired by rails. Author of elixir and main contributor to phoenix is Jose Valim, he's also the author of devise rubygem and former contributor to rails.
AngularJS, Websockets, REST APIs for mobile apps, one-time links for emails — what’s the topmost complexity all those things share in common?
It’s authentication. Authentication typically means sessions, and sessions are simply ubiquitous state for our stateless-by-design web.
There are several popular ways of controlling home automation with voice today. Amazon Echo and Google Home both allow users to control lights, speakers, etc. with a simple voice command.
For this project, I want to replicate some of the simple voice commands supported by projects like those, but in a way that does all processing from within the local network, and doesn't upload any voice clips to a server outside the home. There's something that feels a little uncomfortable about Amazon or Google having the ability to listen in on all conversations, so I'm trying to eliminate that while still being able to turn my lights on or off by voice.
The ESP8266 is an interesting little device that has been around for a while. It has the potential to support some interesting IoT applications. There is Ardunio core support for this device <https://github.com/esp8266/Arduino> and a rich set of libraries to help developers get started.
The plan is to gather ideas about how SUSE can become a more integral part of the local tech community scene (in PRG, NUE, or other locations).
As a person who has been involved in educating women about tech for some time, I am thinking of introductory workshops and meetups, aimed not necessarily only at female audience.
TL;DR Use convolution to find type candidates, then solve system of equations to refine the result.
You are given a set of memory regions. And set of types (structures) that can possibly be present in the regions.
Currently we use openQA for the the YaST integration tests. It runs YaST in a VM and controls it via emulating keyboard input. The result is checked by comparing the screenshots.
This approach has several disadvantages:
In general plan for YaST is to use ruby only in future. So goal of this project is to move it forward and replace more parts with ruby.
Current ideas is to replace binary y2base with ruby script, which allows easier integration with ruby tools and more important it solve some issues with embedding ruby, as it will be then first citizen.
Since there is no real documentation about openQA's lib/ functions I wanted to kill two birds with one stone and write a parser in perl that extracts all function names (and maybe preceding comments) in said directory and improve my perl knowledge by doing this.
In the YaST team we use quite a lot of external or internal services like GitHub, Travis, Jenkins, Open Build Service, Bugzilla, Trello,... It is too difficult and time consuming to track all those tools and get an overview what is OK, what failed and what actions should we take to resolve the problems.
almost 2 years
7 hacker ♥️.
Has no hacker:
An introduction from minetest website: " Minetest is a near-infinite-world block sandbox game and a game engine, inspired by InfiniMiner, Minecraft, and the like. Minetest is available natively for Windows, OS X, GNU/Linux, Android, and FreeBSD. It is Free/Libre and Open Source Software, released under the LGPL 2.1 or later. "
In short, MineTest is a Free and Open Source re-implementation of MineCraft, but it provide many flexible features compare MineCraft. It's not only a game but also a framework for developers to extend so to make their own worlds.
Most of design is done still with a embarrassing amount of data. Having released software for decades, we still don't know exactly what module is the most used, what workflows the customers are following, where do customers fail. It is all guesses and opinions.
The idea of this project is to research:
almost 2 years
4 hacker ♥️.
Has no hacker:
Over the years I have stumbled upon various Android projects where I needed a feature and wasn't able to implement it because I had no idea about Android development.
Downloading an SDK by hand and setting it up one time on a computer always seemed like a waste of time to me. I prefer writing a package once or writing config files ones and then can use them everywhere later. This put me off for quite a while.
almost 4 years
3 hacker ♥️.
Has no hacker:
The plan is to start working towards a rewrite of xdg-utils in python, focusing on the really bad bits such as dealing with desktop files and mime handling.
In this hackweek, I want to split python-xdg into multiple libraries such as python-mime and python-desktop file and prepare them to be used in helper binaries to handle some of the more complex tasks currently done in shell.
There are mobile payment apps which allow you to pay via QR code. But I couldn't find any app that would work on desktop e.g. via special URI. So here's my idea:
Create a universal URI scheme for payments that can launch a handler app (just like mailto: URIs can open your e-mail client). This app could then send wire transfer instructions to your bank account via public internet banking API (if your bank has one). The app would also have a server-side e-shop module for payment processing which would allow instant checkout (if you bank supports instant wire transfers to the e-shop's bank account).
Pology is a Python library and collection of command-line tools for in-depth processing of PO files, the translation file format of the GNU Gettext software translation system.
Pology functionality ranges from precision operations on individual PO messages, to cross-file operations on large collections of PO files.
The Gameshell is a small game console based on AllWinner R16 (Cortex-A7, IIRC the same CPU that the RPi2). Currently is supporting Debian, and some community member ported ArchLinux on it.
The goal of the project is to port the openSUSE MicroOS distribution into the device, providing a transactional upgrade process for a canonical IoT architecture. In the process I expect to learn about ARM7, uBoot and some kernel hacking.
transactional-update, the application to update read-only systems such as openSUSE MicroOS and openSUSE Kubic and the Transactional Server installations of openSUSE Leap, openSUSE Tumbleweed and SUSE Linux Enterprise Server, evolved from a POC to a fully fledged solution - and is currently completely written in Bash. This has been working really well in the past, but is gradually reaching its limits, especially when thinking about supporting additional file systems or ports to other Linux distributions - yes, we have a huge interest in other distributions adopting our technology.
A C++ version would simplify those abstractions, but would it also make maintenance of the complete application easier? Check that as part of a POC and refresh C++ knowledge on the way there.
For a very long time, I have been planning to play with Crystal as possible substitute/complement for Ruby. With that goal, I have isolated a very small subset of the Ruby project I know the best (yast-storage-ng) and I want to migrate that subset to Crystal to get a general feeling about the language. See the repository with the experiment already in progress.
There is no evil plan to migrate YaST to Crystal. This is just done in the Hack Week spirit of "what if". But if more people join maybe we could get this to an state in which some benchmarks can be executed to check what's the real gain in speed and memory consumption using Crystal instead of Ruby (note: speed and memory are not the only goals of the migration).
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.