The Nvidia Jetson TK1 is an SBC with Nvidia Tegra K1 SoC (quad-core Cortex-A15, 32-bit ARMv7). I have openSUSE running on the Jetson TK1, but KVM is currently not usable as the CPUs are not booted in HYP mode. Thierry Reding of Nvidia has some work-in-progress for U-Boot and upstream kernel that I would like to test.

Work towards release of Weblate 2.3, the roadmap is in the issue tracker: <https://github.com/nijel/weblate/milestones/2.3>

The goal is to use the work from the debug-early GCC branch to generate better debug information for LTO compiled objects, especially with regarding to language specifics like classes and templates. This has now been achieved and openSUSE Factory

Objective

The openSUSE plymouth theme presently lacks a nice graphical screen to inform

The libvirt qemu hypervisor driver has long supported protecting disk devices from concurrent use via libvirt's lock manager interface. Xen used to support the same functionality in the old xend toolstack, but dropped support in the new libxl toolstack. The Xen community decided, rightly so, that this functionality is best provided by a higher-level management tool, e.g. libvirt. This project aims to provide integration between libvirt's lock manager and the libxl hypervisor driver, essentially reintroducing support for disk device protection in the Xen management stack.

Due to the newly appointed PM of SLERT 11 SP4, I would like to try out the SLERT 11 SP3 to experience the REAL TIME features so that I can talk and share the knowledge to team and other people Due to SLERT11 Alpha 2 image set at 28 April, I would like to take a chance at hackweek to try build the image because I never did any similar before.

Have a look at the library implementation and its API. I'm just curious about the library implementation. If things goes nicely I may use it to implement cbr support for http://gfxprim.ucw.cz later.

Some customers are still stuck in a world of 32bit. On ARM64, we have two options for those poor folks: 1) Run applications in the legacy ARMv7 instruction set

posixovl is a FUSE based successor of the old UMSDOS. It has a goal to provide POSIX file system functionality on top of vfat. Its code is nice and well written, but its feature set is not complete yet. It just supports: POSIX modes and user/group, hard and symbolic links, device nodes and named pipes. Much more can be done:

Create a user interface useable with a see through head mounted display. The display was created from some Chinese video glasses and has a low resolution (320x240) which requires a optimized user interface that also is useful when using it hands free. The existing Head mounted display: https://jamballa.wordpress.com/2015/01/26/steampunked-hmd-1st-iteration/

Our books are also available as regular software packages such as 'sles-manuals_en'. There is a semi-private script that I use to generate the requisites (fetch the old version from the BS, tar the XML sources with daps, update .spec and .changes, etc.) and to submit the results to the BS.

DRBD refers to block devices designed as a building block to form high availability (HA) clusters.Also possible to combine multiple devices driver for Linux(MD) and the network block device(NBD) to achieve similar functionality. DRBD is done by mirroring a whole block device via an assigned network. DRBD can be understood as network based raid-1. Only two nodes are supported in 8.4.x. For the drbd9(dev in RC phase), multiple nodes can be supported as well. Diving into it and do hacks.

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...

I have an IRC tab open in pidgin and an adjacent XMPP tab; the latter one displayed with focus. When a new XMPP tab opens in background (with a message incoming), the IRC tab steals the focus but not the display. It brings annoying situations when I sometimes send something accidentally to the IRC instead of XMPP, not noticing that I don't have focus. Wanna hunt and fix this bug.

We from the public cloud dev team regularly upload generic and product images to be available in public cloud systems like Amazon EC2, Google Compute Engine or Microsoft Azure. The task of uploading stuff there is not only about having the tools it's also about having the right environment which provides account credentials as well as access to the image when they are built in the buildservice. Also the location from where the upload happens can make a difference in performance. Therefore a framework to combine all this into a more clean process should be developed. The basic parts of the project consists of:

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.

A frame work for automatically analysis the result of the performance test. The tool can be used manully as well as used throught openAPI.

The zypprepo was written around 3 years ago, and was based on the yumrepo built-in type/provider. Nowadays zypprepo misses a lot of functionality, which will be automatically inherited if it gets rewritten to be in sync with the current code of yumrepo (as also discussed in its issues #5 and #9). If time permits, solving issue #4 would be also really useful.

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

Ionic + AngularJS + Node.js (http://ionicframework.com/) staff.suse.de: demo

Record two songs by the end of the week.

As a part of this hackweek, I'd like to take a look at Clojure and use it to solve as many problems as possible from the project euler.

Create packages for SLES 12 s390x in obs. The problem is, that we do not have the native build power on our s390x system.

Write an Android app for children between 5 and 7 years. The app contains a story that the child can read and interact with.

<p> The user space interface of evdev is pretty generic. All hardware abstraction is done in the kernel driver, device properties are mapped to a set of generic properties. The properties can be queried thru a generic interface only very few parameters are set from user space. In user space the evdev API is used by Xorg's evdev driver and libinput.

I think AppArmor is a great tool to add an additional layer of security without much effort. While it is normally easy to create a profile for a simple server program it is much more complex in case of desktop applications. The most vulnerable desktop application is the browser so it would be great to have an AppArmor profile for it.

The docker way of updating containers is to build a new image with the updated binaries and files, which creates a security concern. The docker way is not anymore running "zypper update" in the containment but to update the whole image in the image registry (hub docker if we are talking about public registry) and then pull the image update from there, stop the outdated containments and replace them by starting new containments based on the new image.

OBS source services can currenlty run on the developer workstation and some of them also on the OBS server side. The goal of this project is to allow everybody running source services as part of their build job. Therefore we will introduce a new "buildtime" mode. The OBS server will pull in the needed service packages and run them before calling rpmbuild or friends.

We will have a series of short lightning talks to present what we have accomplished at Hack Week 12. In Nürnberg this will happen on Friday 17th Apr at 12:30 as part of the lunch session in the all-hands area. Lunch is served at 12:00, so you have a bit of time to settle in and satisfy your immediate needs before we go into presentation mode. If you would like to tell a bit about what you did at Hack Week 12, please leave a comment (preferably with a link to your projects), and I'll add you to the schedule.