This is a feed aggregator that collects what openSUSE contributors are writing in their respective blogs.
To have your blog added to this aggregator, please read the instructions.
Note that you may use those keys with or without pressing the alt key.
We’re very happy to announce that openSUSE has been accepted as a mentoring organization for the Google Summer of Code (GSoC) 2017 edition!
Google Summer of Code is an annual program which awards stipends to university students to write code and learn about open source development in their summer break! Accepted students work with a mentor and become a part of the open source community.
In last year’s edition, Ana Maria worked on a project to improve the schedule of the Open Source Event Manager. We’re proud to announce that Ana Maria will participate as a mentor again. If you’re interested in web development and Ruby on Rails, check out the projects around OSEM.
One of our all-time favorite projects participating in GSoC is YaST. openSUSE’s default setup and configuration tool offers a project about rewriting keyboard management in a proper object-oriented way.
Compared to YaST, Jangouts is still a new project in the openSUSE family. Jangouts (for “Janus Hangouts”) is a solution for videoconferencing based on WebRTC and AngularJS. While Jangouts participated the first time with only one project, we’re happy that this year they offer three new projects.
The application period already started this Monday (March 20), and runs through April 4. Interested students should get in touch with the mentors and the community before starting to write an application proposal. Google will announce accepted students on May 4, and the official coding period will be from May 30 – August 29.
If you’re interested in participating in Google Summer of Code, please visit our openSUSE 101 mentoring website for more information about projects and application.
To make sure you didn’t missed us too much, in our latest blog post we summarized all the YaST-related projects worked during Hack Week 15. But after all the fun, it was time for… more fun! So let’s take a look to what the team has delivered on this first sprint after Hack Week 15.
One of the known limitations of the current installer is that it’s only able to automatically propose an encrypted schema if LVM is used. For historical reasons, if you want to encrypt your root and/or home partitions but not to use LVM, you would need to use the expert partitioner… and hope for the best from the bootloader proposal.
But the new storage stack is here (well, almost here) to make all the old limitations vanish. With our testing ISO it’s already possible to set encryption with just one click for both partition-based and LVM-based proposals. The best possible partition schema is correctly created and everything is encrypted as the user would expect. We even have continuous tests in our internal openQA instance for it.
The part of the installer managing the bootloader installation is still not adapted, which means the resulting system would need some manual fixing of Grub before being able to boot… but that’s something for an upcoming sprint (likely the very next one).
The dialog in SLES-12-SP1 for selecting the add-ons after registering the system was originally designed just for a small list of add-ons. Unfortunately (or fortunately, depending on how you look at it), the number of add-ons grew over the time and it exceeded the original limit for the text mode UI.
The equivalent screen in SLE-12-SP2 is not affected by the problem because it uses a different layout with scrollable list. But the SP1 dialog looks like this.
If you look carefully at the screenshot you will see that the Web and Scripting Module is missing in the list and the
Abort buttons at the bottom are also not displayed.
The fix decreased the size of the
Details widget and allowed displaying more items in each column. Now there is even free space for three more add-ons.
Moreover the dialog is now dynamic and checks the current size of the screen. If there is enough free space then the list is displayed in one column so the labels are not truncated and the
Details widget size is increased back to the original size.
The management of subvolumes is one of those features that make Btrfs rather unique and that need special handling when compared to more traditional file systems. That was indeed one of the several reasons to rewrite
libstorage – Btrfs subvolumes never fully fitted the philosophy and data structures on the old (current)
In this sprint we introduced support for subvolumes in
libstorage-ng from the ground up, taking into consideration …
Last time I wrote about artistic constraints being useful to remain focus and be able to push yourself to the max. In the near future I plan to dive into the new contstraint based layout of gtk4, Emeus. Today I’ll briefly touch on another type of constraint, the Blender object constraint!
So what are they and how are they useful in the context of a GNOME designer? We make quite a few prototypes and one of the things to decide whether a behavior is clear and comprehensible is motion design, particularly transitions. And while we do not use tools directly linked to out stack, it helps to build simple rigs to lower the manual labor required to make sometimes similar motion designs and limit the number of mistakes that can be done. Even simple animations usually consist of many keyframes (defined, non-computed states in time). Defining relationships between objects and createing setups, “rigs”, is a way to create of a sort of working model of the object we are trying to mock up.
Constraints in Blender allow to define certain behaviors of objects in relation to others. Constraints allow you to limit movement of an object to specific ranges (a scrollbar not being able to be dragged outside of its gutter), or to convert certain motion of an object to a different transformation of another (a slider adjusting a horizon of an image, ie. rotating it).
The simplest method of defining relation is through a hierarchy. An object can become a parent of another, and thus all children will inherit movements/transforms of a parent. However there are cases — like interactions of a cursor with other objects — where this relationship is only temporary. Again, constraints help here, in particular the copy location constraint. This is because you can define the influence strength of a constraint. Like everything in Blender, this can also be keyframed, so at some point you can follow the cursor and later disengage this tight relationship. Btw if you ever though you can manualy keyframe two animations manually so they do not slide, think again.
Inverse transform in Blender
Peek, a GIF screencasting app.
As long as one sticks to printing PLA, a printer without heatbed is ok, but for ABS or PETG a heatbed is a must.
The TinyBoy2 bed is actually a heatbed, although the wiring is missing, and a thermistor is required as well. The SMELZI controller board has a PWM controlled MOSFET, which is connected to the „HOT-BED“ socket, so making the bed a heatbed is straightforward.
As the bed is aluminium, soldering anything to it can be tricky, and you need a powerful soldering iron to get the solder to temperature. I ended up using two soldering irons simultaneously, one on each end of the solder blob.
The two wires for the heater go to the larger pads, the thermistor sensing cable has to be connected to the smaller pads. As we are connecting resistors here, direction does not matter.
The wires will be bent all the time while the bed moves in the Y direction, so we need a strain relief or the cables will break after short time of operation.
I drilled a 2.5 mm hole into the red bed bracket/slide and pushed a M3 screw into it. The strain relief is created from a small sheet of plastic, size 10×30. Pick 3 small holes into the plastic, at 5, 15 and 25 mm from the edge. Wrap it around the cables, the holes should line up. After assembling, it should look similar to this:
It is important the cables do not extend beyond the edge of the slide, otherwise the cables will colide with the case.
Dear Tumbleweed users and hackers,
As usual, things keep on moving at a steady pace. Week 11 brought us 5 snapshots (0310, 0311, 0314, 0315 and 0316). There were a few minor hick-ups with the removal of gcc5 which could be sorted out.
The 5 snapshots brought us those noteworthy updates / changes:
It’s great to see this steady incoming of updates, especially also ‘more interesting things than just version updates. Things like python singlespec and the way system users/groups are newly handled are just great examples on how openSUSE moves forward.
Things that are currently being forged:
And I’m sure the hackers and packagers will come up with even more fun stuff.
The TinyBoy2 is a Indiegogo backed 3d printer. On the plus side, it is very small (16×18 cm² desk space), and it does it jobs.
Like a lot of crowd funded projects, there is essentially no after campaign support. The firmware is a hacked version of Marlin 1.1.0-RC3. The code for the firmware which is shipped with the hardware is supplied as a code drop, but there is no changelog, and the diff to the upstream RC3 contains a lot of awkward changes, e.g. changes to the display SPI code, although the TB2 display uses I₂C. The diff between the code drop and RC3 is 53 files changed, 2196 lines removed, 2072 lines added.
As I wanted to update my printer to a recent firmware (RC3 was tagged December 2015) to get all the new features and bugfixes, and also to change the FW behaviour, I started with the current Marlin GIT, and added the necessary changes on top.
The nice part is that current Marlin is completely capable to drive the printer, support is mostly added by creating a suitable Configuration and setting the right pins for steppers, PWM, encoder and so on. The changes have been submitted upstream, or you can just pull the patched tree from my Marlin github repo.
In case you do not want to compile the FW yourself, I have prepared 4 variants: L10/L16, both with and without heatbed support:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bd1af0b14e81c344d5ecac27a7c8ba09aaa96a0c Marlin_TB2_L10_HeatBed.hex fd754b2b9f0ff7271eb53c9cc9f022eee1b247b8 Marlin_TB2_L10.hex f330e4ec2a3fcc32510c15b8f9c776731aa98598 Marlin_TB2_L16_HeatBed.hex cc239598f0fe9ba0ccccb31b007c896c1595dea9 Marlin_TB2_L16.hex -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSwWRWIpJbl0W4DemNvf0o9jP6qUwUCWM3KjQAKCRBvf0o9jP6q U4HkAJ9GOBOmfTw1XUSQlTs745P7qKvO2wCfY/xWHpbGTfzuS7GZLDvTPnEjc7I= =ce7+ -----END PGP SIGNATURE----
Although it is possible to use Arduino to flash the firmware, I consider it much to bloated for the task, and as it uses avrdude behind the curtains, I prefer to call avrdude directly:
Backup shipped FW (sorry, not verified):
avrdude -p m1284p -b 57600 -c arduino -P /dev/ttyUSB0 -U flash:r:Backup.hex:i
Update to new FW:
avrdude -p m1284p -b 57600 -c arduino -P /dev/ttyUSB0 -U flash:w:Marlin.hex
(Update 2017-03-19 18:49 UTC: Added flashing paragraph)
I went to Chemnitzer LinuxTage last weekend. That was a successful open source event.
openSUSE has got a lot of positive feedback. Some people changed from Ubuntu to openSUSE Tumbleweed and are happy.
There was some misunderstanding with the new release development of openSUSE Leap. Some people thought that would be a second rolling release by openSUSE. After explaining that we want to do that only in the development phase for achieving a more stable operating system and we will have a release day every year again, these cusomers have been happy again and like this idea. More stability is a good reason.
invis server had his meeting about their new project openSUSE SMB. One openSUSE customer was interested for this project and I brought him to Stefan. Some booth visitors want to visit our next oSC in Nuremberg.
We had more customers than in the year before. Somtimes guys asked how to change to us and to contribute. Linux beginners wanted to have live CDs. We burned flash drives with Tumbleweed live images for them.
They produce server hardware and storage. Their first award was a low energy server which I won. That‘ s ideal for students like me. The best thing is that this server hardware is supported by openSUSE.
Chemnitzer LinuxTage was a fantasic open source event like every year. Thanks for the sponsoring!
As a founding member of our surf club, I’ve decided to do what what was long overdue and took my second surfing lesson.
I went to a surfschool in Scheveningen at the North Sea, got in touch with an instructor, and after going over the water situation, currents, swell and technique, we went into the water for a good one and a half hours. There was a good swell, and next to the harbour’s pier, we were mostly out of the wind. After building up some skills, like catching waves and paddling into them, I managed to ride out a few waves, onto the beach. Not over a long distance, but at least I didn’t fall for a few seconds, a few times. Pretty good progress. Next try planned on sunday, weather allowing. It’s still the North Sea, and it’s still winter, so things can get nasty…
The water temperature was 9°C, which seems cold. I wore my 7mm full-length suit, 3mm gloves and a 5mm hood. It didn’t feel cold even in my fingertops after getting out of the water, so even in March, the North Sea is already very manageable.
Surfing was great fun, it’s an interesting break from diving in that it’s much more physically active. In diving, you tend to spend as little energy on anything as possible. That means that if you’re a good diver (and in the right conditions), you actually burn very little energy. That means you’re getting cold much quicker. Bodysurfing, on the other hand means that you’re constantly moving through the swell, swimming, paddling, getting up, falling, so you end up burning a lot of energy. The cold splash of water is really welcome then.
As opposed to diving, there is no buddy system in surfing, so you can go surfing on your own (under the right conditions, of course). That makes it a bit more flexible than diving. It also trains different muscle groups, especially arms and shoulders, so it complements diving well.
Waves are awesome. :)
When speaking of virtualisation (container-wise) there are two major alternatives: Docker and LXC. If I were deploying web applications I would probably go for Docker, very easy to set up a Docker file installing nginx, php-fpm, etc and doing a few commands to set it up. Docker is not designed for running full machines, you can basically just start one command, that’s it. On the other hand, LXC, you get full machines with a minimal virtualisation layer providing excellent performance. The disadvantage is that you will use more space/memory for running something similar to full machines.
This site provides a wide selection of ready container images, however the openSUSE image is version 13.2 which is running out of support. I could use that image and upgrade it, however they ran install patterns-openSUSE-minimal_base without –no-recommends so you get all sorts of interesting stuff like Mesa you will not need on a server. So I decided to build my own image. It is quite easy, you will basically just need a tarball of the rootfs and a metadata file. On an openSUSE machine the rootfs can be created very easily, thanks to the –root option of zypper. I created a bash script to create a rootfs.tgz, just run it with the requested tarball as argument, i.e. sh make-container.sh /home/you/rootfs.tgz and you are good to go. The script looks like this
tmpdir=`mktemp -d` echo "Creating tempdir $tmpdir" zypper -n --root $tmpdir ar -G http://ftp.gwdg.de/pub/opensuse/distribution/leap/42.2/repo/oss/ repo-oss zypper -n --root $tmpdir ar -G http://ftp.gwdg.de/pub/opensuse/update/leap/42.2/oss/ repo-update zypper -n --root $tmpdir in --no-recommends patterns-openSUSE-minimal_base iputils net-tools nano timezone cat <<EOF > $tmpdir/etc/sysconfig/network/ifcfg-eth0 STARTMODE='auto' BOOTPROTO='dhcp' EOF cd $tmpdir tar cfzv $1 * rm -rf $tmpdir
Now you have a tarball, you will need a metadata.yaml file:
architecture: "x86_64" creation_date: 1458040200 properties: architecture: "x86_64" description: "openSUSE LEAP 42.2" os: "opensuse" release: "leap42.2"
Now you need to pack the metadata.yaml into metadata.tgz. You can import the image into the lxc host in the following way:
# lxc image import metadata.tgz rootfs.tgz --alias=leap
Now you are ready to spin up an instance of the image
# lxc launch leap machinename # lxc exec machinename bash
That’s it. You need to set the hostname in /etc/hostname, you can use lxd to get networking and NAT.
A driver update (DUD) can of course update a single driver. But if that’s not enough and you need a whole new kernel to run an installation?
There are two parts to solve:
For this it’s important to know which kernel packages you’ll actually need. Typically it will be
kernel-firmware. But older SUSE distributions (SLE 11 comes to mind) had the kernel packages split into
kernel-default-base – you’ll need them both.
To make things confusing, modern SUSE distributions also have
kernel-default-base – but it’s an alternative to
kernel-default. In this case we don’t need it.
If unsure, check
kernel-default. If it contains the actual kernel (e.g.
/boot/vmlinuz) then you don’t need
On some architectures modules are also taken from
xen-kmp-default. If that’s important for you, you can add this package to the kernel list as well.
In fact you can add any number of kernel packages or kmps you like.
In the past, sometimes a different kernel flavor was used. For example PowerPC had
kernel-ppc64 for a while. Simply use the flavor you need.
It’s a good idea to gather all the kernel rpms into a single directory for easier use:
> mkdir k > cp kernel-default.rpm kernel-firmware.rpm k > cp kernel-default-base.rpm k # only if needed # add any kernel-related rpms you need
Then, take your SUSE installation iso and run
> mksusecd --create new.iso \ --kernel k/* -- \ original_dvd1.iso
Note that the
--kernel option accepts a variable number of arguments, so you have to add an isolated
-- to terminate the argument list properly.
The output could look like this:
> mksusecd --create new.iso \ --kernel k/* -- \ SLES-11-SP4-DVD-ppc64-GM-DVD1.iso kernel version: 3.0.101-63-ppc64 --> 3.0.101-94-ppc64 CHRP bootable (ppc64) building: 100% calculating sha1...
The command above will actually get the list of required modules from the old installation iso. If you are missing some driver or the new kernel comes with some additional driver, the module will not be added to the new iso.
But there’s the
--modules option. It will add the listed modules together with any implicitly required modules via module dependencies.
For example, let’s add the
airport wifi-module to our PowerPC iso:
> mksusecd --create new.iso \ --kernel k/* \ --modules airport -- \ SLES-11-SP4-DVD-ppc64-GM-DVD1.iso kernel version: 3.0.101-63-ppc64 --> 3.0.101-94-ppc64 kernel modules added: airport, cfg80211, orinoco CHRP bootable (ppc64) building: 100% calculating sha1...
As you can see, it automatically adds
cfg80211 as well.
This is relatively simple. A driver update can do this:
> mkdud --create foo.dud \ --dist sle11 \ --install repo \ k/*
This creates a driver update for SLE 11 (which also applies to SP4) and the kernel rpms are installed …
During last week I've noticed several interesting posts about challenges being free software maintainer. After being active in open source for 16 years I can share much of the feelings I've read and I can also share my dealings with the things.
First of all let me link some of the other posts on the topic:
I guess everybody involved in in some popular free software project knows it - there is much more work to be done than people behind the project can handle. It really doesn't matter it those are bug reports, support requests, new features or technical debt, it's simply too much of that. If you are the only one behind the project it can feel even more pressing.
There can be several approaches how to deal with that, but you have to choose what you prefer and what is going to work for you and your project. I've used all of the below mentioned approaches on some of the projects, but I don't think there is a silver bullet.
Finding more people
Obviously if you can not cope with the work, let's find more people to do the work. Unfortunately it's not that easy. Sometimes people come by, contribute few patches, but it's not that easy to turn them into regular contributor. You should encourage them to stay and to care about the part of the project they have touched.
With phpMyAdmin we're participating regularly in GSoC (we've only missed last year as we were not chosen by Google that year) and it indeed helps to bring new people on the board. Many of them even stay around your project (currently 3 of 5 phpMyAdmin team members are former GSoC students). But I think this approach really works only for bigger organizations.
You can also motivate people by money. It's way which is not really much used on free software projects, partly because lack of funding (I'll get to that later) and partly because it doesn't necessarily bring long time contributors, just cash hunters. I've been using Bountysource for some of my projects (Weblate and Gammu) and so far it mostly works other way around - if somebody posts bounty on the issue, it means it's quite important for him to get that fixed, so I use that as indication for myself. On attracting new developers it never really worked well, even when I've tried to post bounties to some easy to fix issues, where newbies could learn our code base and get paid for that …
Since openSUSE Tumbleweed has been upgraded to use rpm 4.13 (snapshot 2017033), you keep on seeing the message “warning: Unsupported version of key: V3” whenever you invoke zypper or rpm. Of course this is highly annoying, and you just want to stop it, right?
First, a bit of background:
RPM uses gpg infrastructure to validate package signatures. As is common, this infrastructure is being developed and the various key formats are versioned. As old formats become obsolete and considered insecure, they are no longer being supported by modern tools. This helps to improve security insofar to not give the user a false sense of safety: a key that is insecure is worth as much as no key at all.
So, let’s stop zypper / rpm annoy you with this! If it’s already not going to use the gpg key, we can as well just get rid of it. But HOW!?
First, we need to find out the ID (or IDs) of the key(s) causing it. RPM can be a bit more verbose when asked to be so, and then it gives us some hints:
rpm -vv -qf /etc
And this will reply with something like
ufdio: 1 reads, 18883 total bytes in 0.000006 secs
D: loading keyring from pubkeys in /var/lib/rpm/pubkeys/*.key
D: couldn’t find any keys in /var/lib/rpm/pubkeys/*.key
D: loading keyring from rpmdb
D: opening db environment /var/lib/rpm cdb:private:0x201
D: opening db index /var/lib/rpm/Packages 0x400 mode=0x0
D: locked db index /var/lib/rpm/Packages
D: opening db index /var/lib/rpm/Name nofsync:0x400 mode=0x0
D: read h# 168 Header sanity check: OK
warning: Unsupported version of key: V3
D: read h# 335 Header sanity check: OK
D: added key gpg-pubkey-7e2e3b05-4be037ca to keyring
D: read h# 390 Header sanity check: OK
I highlighted the interesting parts here for your viewing pleasure. 168 actually refers to the internal id in the rpm database of the key it just complained about.
So, let’s find out what key this is:
rpm -q --querybynumber 168
and you get something like gpg-pubkey-7e2e3b05-4be037ca as reply. With this information, you can find out what key it is – just to satisfy your hunger for information. If you believe that the key in question is still in use, you might want to inform its owner.
rpm -qi gpg-pubkey-3d25d3d9-36e12d04
warning: Unsupported version of key: V3
Name : gpg-pubkey
Version : 3d25d3d9
Release : 36e12d04
Install Date: Tue 06 Jul 2010 07:39:17 AM CEST
Group : Public Keys
Size : 0
License : pubkey
Signature : (none)
Source RPM : (none)
Build Date : Tue 06 Jul 2010 07:39:17 AM CEST
Build Host : localhost
Relocations : (not relocatable)
Summary : gpg(SuSE Security Team )
This is indeed an old GPG key – from SUSE. As this machine has been updated using zypper dup for such a long time, it’s no surprise some cruft like this accumulated. That key has long …
Weblate is growing quite well in last months, but sometimes it's development is really driven by people who complain instead of following some roadmap with higher goals. I think it's time to change it at least a little bit. In order to get broader feedback I've sent out short survey to active project owners in Hosted Weblate week ago.
I've decided to target at smaller audience for now, though publicly open survey might follow later (but it's always harder to evaluate feedback across different user groups).
Overall feelings were really positive, most people find Weblate better than other similar services they have used. This is really something I like to hear :-).
But the most important part for me was where users want to see improvements. This somehow matches my expectation that we really should improve the user interface.
We have quite a lot features, which are really hidden in the user interface. Also interface for some of the features is far from being intuitive. This all probably comes from the fact that we really don't have anybody experienced with creating user interfaces right now. It's time to find somebody who will help us. In case you are able to help or know somebody who might be interested in helping, please get in touch. Weblate is free software, but this can still be paid job.
Last part of the survey was focused on some particular features, but the outcome was not as clear as I hoped for as almost all feature group attracted about same attention (with one exception being extending the API, which was not really wanted by most of the users).
Overall I think doing some survey like this is useful and I will certainly repeat it (probably yearly or so), to see where we're moving and what our users want. Having feedback from users is important for every project and this seemed to worked quite well. Anyway if you have further feedback, don't hesitate to use our issue tracker at GitHub or contact me directly.
Weblate 2.12 has been released today, few days behind schedule. It brings improved screenshots management, better search and replace features or improved import. Many of the new features were already announced in previous post, where you can find more details about them.
Full list of changes:
If you are upgrading from older version, please follow our upgrading instructions.
You can find more information about Weblate on https://weblate.org, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with
demo account using
demo password or register your own user. Weblate is also being used on https://hosted.weblate.org/ as official translating service for phpMyAdmin, OsmAnd, Aptoide, FreedomBox, Weblate itself and many other projects.
Should you be looking for hosting of translations for your project, I'm happy to host them for you or help with setting it up on your infrastructure.
Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far! The roadmap for next release is just being prepared, you can influence this by expressing support for individual issues either by comments or by providing bounty for them.
In the Friday keynote of Novell's Brainshare this year they did a highlight on some of the Hackweek v2 projects. Zonker recently joined Novell and did a great job introducing all of the projects. Boyd and I did a demo of Tasque and a bit more.
Boyd and I were so focused on our Brainshare presentation we went off the grid for a day and ignored everything... that was a mistake! On Thursday Guillaume Beland posted his first GNOME Do plugin which happend to be for Tasque.
Had I paid attention to the community on Thursday I would have seen this and shown it as part of our demo on Friday. The plugin is awesome and if you can't tell, I love GNOME Do. Now it's even better!