The openSUSE Kubic team is proud to announce that as of yesterday, our Kubic distribution has become a Certified Kubernetes Distribution! Notably, it is the first open source Kubernetes distribution to be certified using the CRI-O container runtime!

What is Kubernetes Certification?

Container technologies in general, and Kubernetes in particular, are becoming increasingly common and widely adopted by enthusiasts, developers, and companies across the globe. A large ecosystem of software and solutions is evolving around these technologies. More and more developers are thinking “Cloud Native” and producing their software in containers first, often targeting Kubernetes as their intended platform for orchestrating those containers. And put bluntly, they want their software to work.

But Kubernetes isn’t like some other software with this sort of broad adoption. Even though it’s being used in scenarios large and small, from small developer labs to large production infrastructure systems, Kubernetes is still a fast-moving project, with new versions appearing very often and a support lifespan shorter than other similar projects. This presents real challenges for people who want to download, deploy and run Kubernetes clusters and know they can run the things they want on top of it.

When you consider the fast moving codebase and the diverse range of solutions providing or integrating with Kubernetes, that is a lot of moving parts provided by a lot of people. That can feel risky to some people, and lead to doubt that something built for Kubernetes today might not work tomorrow.

Thankfully, this a problem the Cloud Native Computing Foundation (CNCF) is tackling. The CNCF helps to build a community around open source container software, and established the Kubernetes Software Conformance Certification to further that goal. Certified Kubernetes solutions are validated by the CNCF. They check that versions, APIs, and such are all correct, present, and working as expected so users and developers can be assured their Kubernetes-based solutions will work with ease, now and into the future.

Why Certify Kubic?

The openSUSE Project has a long history of tackling the problem of distributing fast-moving software.

Tumbleweed and Kubic are simultaneously both two of the fastest and most stable rolling release distributions available.

With the Open Build Service and openQA we have an established pipeline that guarantees we only release software when it is built and tested both collectively and reproducibly.

Our experience with btrfs and snapper means that even in the event of an unwanted (or heaven forbid, broken) change to a system, users can immediately rollback to a system state that works the way they want it to.

With Transactional Updates, we ensure that no change ever happens to a running system. This futher guarantees that any rollback can return a system to a clean state in a single atomic operation.

In Kubic, we leverage all of this to build an excellent container operating system, providing users with the latest versions of exciting new tools like Podman, CRI-O, Buildah, and (of course) Kubernetes.

We’re keeping up with all of those fast moving upstream projects, often releasing our packages within days or sometimes even hours of an upstream release.

But we’re careful not to put users at risk, releasing Kubic in sync with the larger openSUSE Tumbleweed distribution, sharing the same test and release pipeline, so we can be sure if either distribution makes changes that breaks the other, neither ships anything to users.

So we’ve solved all the problems with fast moving software, so why certify? 😉

Well, as much as it pains me to write this, no matter how great we are with code review, building, testing and releasing we’re never going to catch everything. Even if we did, at the end of the day, all we can really say is “we do awesome stuff, trust us”

And when you consider how we work in openSUSE, things can seem even more complicated to newcomers.
We’re not like other open source projects with a corporate backer holding the reigns and tightly controlling what we do.

openSUSE is a truly open source community project where anyone and everyone can contribute, taking what we’re doing in Kubic, and directly changing it to fit what they want to see.

These contributions are on an equal playing field, with SUSE and other Sponsors of openSUSE having to contribute in just the same way as any other community member.

And we want more contributions. We will keep Kubic open and welcoming to whatever crazy (or smart, or crazy-smart) ideas you might have for our container distribution.

But we also want everyone else to know that whatever we end up doing, people can rely on Kubic to get stuff done.

By certifying Kubic with the CNCF, there is now an impartial third party who has looked over what we do, checked what we’re distributing, checked our documentation, and conferred to us their seal of approval.

So, to everyone who has contributed to Kubic so far and made this possible, THANK YOU.

To all of the upstream projects without whom Kubic wouldn’t have anything to distribute and get certified, THANK YOU and see you soon on your issue trackers and pull request queues.

And to anyone and everyone else, THANK YOU, and we hope you have a lot of fun downloading, using, and hopefully contributing back our window into the container world.

Weblate 3.4 has been released today. The most visible new feature are guided translation component setup or performance improvements, but there are several other improvements as well.

Full list of changes:

• Added support for XLIFF placeholders.
• Celery can now utilize multiple task queues.
• Added support for renaming and moving projects and components.
• Include chars counts in reports.
• Added guided adding of translation components with automatic detection of translation files.
• Customizable merge commit messages for Git.
• Added visual indication of component alerts in navigation.
• Improved performance of loading translation files.
• New addon to squash commits prior to push.
• Improved displaying of translation changes.
• Changed default merge style to rebase and made that configurable.
• Better handle private use subtags in language code.
• Improved performance of fulltext index updates.
• Extended file upload API to support more parameters.

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. Weblate is also being used on https://hosted.weblate.org/ as official translating service for phpMyAdmin, OsmAnd, Turris, 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.

Filed under: Debian English SUSE Weblate

Here at SUSE we heavily use Open Build Service, and often while collaborating on a project (In my case, openQA) one has to add a new package as a dependency from time to time, or has to do a backport for an older SLE or openSUSE Leap release

It boils down to the following steps, in this case I wanted to change the project to build against SUSE:SLE-12-SPX:Update instead of SUSE:SLE-12-SPX:GM which is a build target that will get the updates while the GM doesn’t, all this, because I wanted to add openvswitch to the project, so that we could use new features in our openQA deployments.

To do this, after setting up the obs account, it boils down to:

1- Branch your project 2- Link your packages 2- Modify the project metadata if needed 3- Modify the project config if errors related to multiple choices appear (PostgreSQL will be there for sure!) 4- Grab a cup of coffee/tea/water and do some reading while waiting for the build

# Branch the project
osc branch devel:openQA:SLE-12

# Link the new package
osc linkpac openSUSE:Factory  openvswitch
# More and more packages will say that their dependencies cannot be resolved, this is
# you might spend some time here adding bunch of dependencies :)
osc linkpac openSUSE:Factory  dpdk devel:openQA:SLE-12
osc linkpac openSUSE:Factory  python-six devel:openQA:SLE-12

By this point you might get error messages on the webUI stating that:

$a_package: have choice for $conflicting_package needed by $a_package: $options

As an example, it might happen that you see postgres-server there, having postgres96-server and postgres94-server as $options, you’ve got to choose your destiny!.

When you find this, it’s time to edit the project configuration:

# Since
osc meta prjconf devel:openQA:SLE-12 -e
# An editor will open and you will be able to change stuff
# Remember that you need write permissions on the project!
...
Prefer: postgresql96-devel
Prefer: postgresql96-server
Prefer: python-dateutil
...

Modify the project metadata to use :Updates instead of :GM, and change architectures if you need to do so.

# same as before: An editor will open, and you will be able to edit stuff
 osc meta prjconf devel:openQA:SLE-12 -e
  <repository name="SLE_12_SP4">
    <path project="SUSE:SLE-12-SP4:Update" repository="standard"/>
     <arch>x86_64</arch>
    <arch>aarch64</arch>
    <arch>ppc64le</arch>
  </repository>

After this, a project rebuild will take place, sit down and give some more reading :)

The horror

You happen to update your system (In my case, I use Tumbleweed or Gentoo) and there’s new version of Perl, at some point there’s the realization that you’re using local::lib, and the pain unfolds: A shell is started, and you find a dreaded:

Cwd.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xdb80080)

Which means: that the module (Cwd in this case) is not compatible (Because it’s an XS module) with your current version of perl, installed on your system: Likely it was compiled for a previous version, leadin to those binaries mismatching

Don’t panic!

In the past, I used to reinstall my full local::lib directory, however after hanging out and asking few questions on #toolchain on irc.perl.org, I got to write (or rather hack, an ugly hack) a quick perl script to walk the local::lib packages that were installed already, only looking at the specified directory… it worked well, gave me the list of what I needed so I could reinstall later, however Grinnz pointed me to his perl-migrate-modules script, to which after chatting a bit, he added the from switch, which allows people to reinstall all the modules that were present in an old local::lib directory:

The light

# Migrate modules from an old (inactive) local::lib directory
$ perl-migrate-modules --from ~/perl5-old/lib/perl5 /usr/bin/perl

Hope you find it useful :)

At work I mostly program in Ruby, but our system (YaST) has a C/C++ part
too. So I get to debug C crashes infrequently enough to forget some
tricks. Here I write them down for the next time.

1. Contents and tl;dr

• $ ulimit -c unlimited so that a core dump is saved
• $ sudo coredumpctl dump -o core so that it is saved to a file
• $ gdb -c core is wrong, gdb program core is right
• (gdb) info sh mylib
• (gdb) select a stack frame before querying variables or macros
• $ CFLAGS="-g3 ..." for debugging macros

1. (Un)helpful crash dump

When Ruby crashes, it produces a very verbose dump of information. It is not
much helpful in our case:

$ rake run[fail]
/sbin/yast2 src/clients/fail.rb
/usr/lib64/ruby/vendor_ruby/2.5.0/yast/yast.rb:204: [BUG] Segmentation fault at 0x0000000000000008
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux-gnu]

-- Control frame information -----------------------------------------------
c:0011 p:---- s:0066 e:000065 CFUNC  :call_yast_function
c:0010 p:0061 s:0058 e:000057 BLOCK  /usr/lib64/ruby/vendor_ruby/2.5.0/yast/yast.rb:204 [FINISH]
c:0009 p:0023 s:0054 e:000053 METHOD /local/home-mvidner/svn/yast/samba-server/src/clients/fail.rb:5
[...]
c:0002 p:0489 s:0011 E:000c18 EVAL   /usr/lib/YaST2/bin/y2start:58 [FINISH]
c:0001 p:0000 s:0003 E:001300 (none) [FINISH]

-- Ruby level backtrace information ----------------------------------------
/usr/lib/YaST2/bin/y2start:58:in `<main>'
/usr/lib64/ruby/vendor_ruby/2.5.0/yast/wfm.rb:195:in `CallFunction'
[...]
/usr/lib64/ruby/vendor_ruby/2.5.0/yast/yast.rb:204:in `call_yast_function'

-- Machine register context ------------------------------------------------
 RIP: 0x00007fa423bf9677 RBP: 0x00007fff30f5ff20 RSP: 0x00007fff30f5fe10
[...]
 R14: 0x00007fff30f5ff48 R15: 0x00007fff30f5fe10 EFL: 0x0000000000010202

-- C level backtrace information -------------------------------------------
/usr/lib64/libruby2.5.so.2.5(rb_print_backtrace+0x15) [0x7fa428543f15]
/usr/lib64/libruby2.5.so.2.5(0x1c814c) [0x7fa42854414c]
/usr/lib64/libruby2.5.so.2.5(0x93e44) [0x7fa42840fe44]
/usr/lib64/libruby2.5.so.2.5(0x158eb2) [0x7fa4284d4eb2]
/lib64/libc.so.6(0x7fa427ff8160) [0x7fa427ff8160]
/usr/lib64/YaST2/plugin/libpy2lang0_ruby.so(_ZN5YRuby9callInnerENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_7YCPList8constPtrI4TypeS8_E+0x4c7) [0x7fa423bf9677]
[...]
/usr/bin/ruby.ruby2.5(_start+0x2a) [0x40086a]

-- Other runtime information -----------------------------------------------

* Loaded script: /usr/lib/YaST2/bin/y2start

* Loaded features:

    0 enumerator.so
    1 thread.rb
    2 rational.so
    3 complex.so
    4 /usr/lib64/ruby/2.5.0/x86_64-linux-gnu/enc/encdb.so
[...]
   87 /usr/lib64/ruby/vendor_ruby/2.5.0/yast/y2start_helpers.rb
   88 /local/home-mvidner/svn/yast/samba-server/src/modules/Fail.rb

* Process memory map:

00400000-00401000 r-xp 00000000 08:01 7766                               /usr/bin/ruby.ruby2.5
[...]
7fa42363b000-7fa42365c000 r--s 00000000 08:01 6998                       /usr/lib64/YaST2/plugin/libpy2lang_ruby.so
[...]
7fa428a5f000-7fa428a60000 rw-p 00026000 08:01 1310795                    /lib64/ld-2.26.so
7fa428a60000-7fa428a61000 rw-p 00000000 00:00 0 
7fff30767000-7fff30f66000 rw-p 00000000 00:00 0                          [stack]
7fff30ff1000-7fff30ff4000 r--p 00000000 00:00 0                          [vvar]
7fff30ff4000-7fff30ff6000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html

/sbin/yast2: line 455: 25102 Aborted                 (core dumped) $ybindir/y2start $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS

1. "(core dumped)" is lying

It means to say: Per /usr/lib/sysctl.d/50-coredump.conf the core has been sent
to /usr/lib/systemd/systemd-coredump which obeyed "ulimit -c 0" and did not
save it.
So let's

• use the ulimit -c unlimited command (bash shell builtin, actually)
• Let it crash again
• sudo coredumpctl dump -o core

Also note that without the dump subcommand, the core dump will be deleted
after a day. (Why?)

(To avoid systemd-coredump, you can use
sudo /usr/sbin/sysctl kernel.core_pattern="core.%p"; thanks lslezak)

1. gdb -c core is not useful without the executable

When we do that, the backtrace is very unhelpful:

(gdb) bt
#0  0x00007eff7d0140e0 in ?? ()
#1  0x0000000000000400 in ?? ()
#2  0xffffffffffffffff in ?? ()
#3  0xffffffffffffffff in ?? ()
#4  0xffffffffffffffff in ?? ()
#5  0xffffffffffffffff in ?? ()
#6  0xffffffffffffffff in ?? ()
#7  0xffffffffffffffff in ?? ()
#8  0xffffffffffffffff in ?? ()
#9  0xffffffffffffffff in ?? ()
#10 0xffffffffffffffff in ?? ()
#11 0xffffffffffffffff in ?? ()
#12 0xffffffffffffffff in ?? ()
#13 0xffffffffffffffff in ?? ()
#14 0x0000000000000000 in ?? ()

For some reason, gdb will not load the executable file even though it is named
in the core file. Do it by hand:

1. gdb program core

$ gdb /usr/bin/ruby.ruby2.5 core

[... lots of text that we'll get back to in the next section ...]
(gdb) bt
#0  0x00007eff7d0140e0 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007eff7d01579f in __GI_abort () at abort.c:100
#2  0x00007eff7d42be51 in die () at error.c:552
#3  0x00007eff7d42be51 in rb_bug_context (ctx=ctx@entry=0xcebac0, fmt=fmt@entry=0x7eff7d5925c4 "Segmentation fault at %p") at error.c:582
#4  0x00007eff7d4f0eb2 in sigsegv (sig=11, info=0xcebbf0, ctx=0xcebac0) at signal.c:928
#5  0x00007eff7d014160 in <signal handler called> () at /lib64/libc.so.6
#6  0x00007eff78c15677 in YRuby::callInner(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, YCPList, constPtr<Type, Type>) () at /usr/lib64/YaST2/plugin/libpy2lang_ruby.so
#7  0x00007eff78c19d80 in Y2RubyFunction::evaluateCall() () at /usr/lib64/YaST2/plugin/libpy2lang_ruby.so

Note that the frames 0 to 4 show the source code locations (file name and line
number) as well as the argument names and values. It's because gdb has found
the debugging information for glibc and the Ruby library:

(gdb) info sh libc
From                To                  Syms Read   Shared Object Library
0x00007eff7cffe770  0x00007eff7d14365c  Yes         /lib64/libc.so.6
0x00007eff7c981cd0  0x00007eff7c9895e8  Yes         /lib64/libcrypt.so.1
0x00007eff73c256f0  0x00007eff73c27007  Yes (*)     /usr/lib64/libcap.so.2
0x00007eff6972ca10  0x00007eff69731b65  Yes         /usr/lib64/qt5/plugins/platforminputcontexts/libcomposeplatforminputcontextplugin.so
(*): Shared library is missing debugging information.
(gdb) info sh ruby
From                To                  Syms Read   Shared Object Library
0x00007eff7d3c73c0  0x00007eff7d566ea8  Yes         /usr/lib64/libruby2.5.so.2.5
0x00007eff7c433850  0x00007eff7c4344c0  Yes (*)     /usr/lib64/ruby/2.5.0/x86_64-linux-gnu/enc/encdb.so
[...]
0x00007eff7b9ec2c0  0x00007eff7b9f4cb0  Yes (*)     /usr/lib64/ruby/vendor_ruby/2.5.0/x86_64-linux-gnu/yastx.so
0x00007eff78c0fc00  0x00007eff78c1e740  Yes (*)     /usr/lib64/YaST2/plugin/libpy2lang_ruby.so
0x00007eff789f82a0  0x00007eff78a001a5  Yes (*)     /usr/lib64/ruby/vendor_ruby/2.5.0/x86_64-linux-gnu/yast/builtinx.so
(*): Shared library is missing debugging information.

info sh is short for info sharedlibrary. If you omit the library name filter, the
length of the list will easily obscure the "(*)" footnote.

1. Add debuginfo

On openSUSE (and SUSE Linux Enterprise), the debugging symbols are in separate
RPM packages:

zypper in yast2-ruby-bindings-debug{info,source}

Or take the hint from the gdb message that we omitted in the previous section:

Missing separate debuginfo for /usr/lib64/YaST2/plugin/libpy2lang_ruby.so
Try: zypper install -C "debuginfo(build-id)=8c6a1d943255c6f935e029140e75b49b1b7c22fb"

After restarting gdb:

(gdb) bt
[...]
#5  0x00007eff7d014160 in <signal handler called> () at /lib64/libc.so.6
#6  0x00007eff78c15677 in rb_array_len (a=8) at /usr/include/ruby-2.5.0/ruby/ruby.h:2057
#7  0x00007eff78c15677 in YRuby::callInner(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, YCPList, constPtr<Type, Type>) (this=this@entry=0xfefcc0, module_name=..., function=..., argList=..., wanted_result_type=...) at /usr/src/debug/yast2-ruby-bindings-4.0.6-lp150.1.1.x86_64/src/binary/YRuby.cc:220
[...]

In frame #6, rb_array_len (a=8), is the a argument equal to nil?
Let's check:

(gdb) p Qnil
No symbol "Qnil" in current context.

That's misleading! Although Qnil is defined in a header, and you've been
taught to prefer static const int to macros because of macros being
"global", they are in fact not as much global as for gdb to see them now. We
have to select a frame to have a context of a compilation unit.

(gdb) f 6
#6  rb_array_len (a=8) at /usr/include/ruby-2.5.0/ruby/ruby.h:2057
2057        return (RBASIC(a)->flags & RARRAY_EMBED_FLAG) ?
(gdb) p Qnil
No symbol "Qnil" in current context.

WTF?! Well, having debugging information loaded is not enough, the debuginfo
must have an elevated level that includes the macros.

1. Debuginfo with macros

Instead of the -g flag to gcc, I had to specify -g3 in CFLAGS and
rebuild and reinstall. After that, finally:

(gdb) f 6
#6  rb_array_len (a=8) at /usr/include/ruby-2.5.0/ruby/ruby.h:2057
2057        return (RBASIC(a)->flags & RARRAY_EMBED_FLAG) ?
(gdb) p Qnil
$1 = 8
(gdb) f 7
#7  YRuby::callInner (this=this@entry=0xfefcc0, module_name=..., function=..., argList=..., wanted_result_type=...) at /usr/src/debug/yast2-ruby-bindings-4.0.6-lp150.1.1.x86_64/src/binary/YRuby.cc:220
220         VALUE backtrace = RARRAY_LEN(trace)>0 ? rb_ary_entry(trace, 0) : rb_str_new2("Unknown");

So a = 8 and Qnil is 8, so we have confirmed that the trace array being
nil is causing the crash.

(For the record, this is bsc#1119690.)