29 Nov 2015

feedPlanet Gentoo

Luca Barbato: lxc, ipv6 and iproute2

Not so recently I got a soyoustart system since it is provided with an option to install Gentoo out of box.

The machine comes with a single ipv4 and a /64 amount of ipv6 addresses.


I want to use the box to host some of my flask applications (plaid mainly), keep some continuous integration instances for libav and some other experiments with compilers and libraries (such as musl, cparser other).

Since Diego was telling me about lxc I picked it. It is simple, requires not much effort and in Gentoo we have at least some documentation.

Setting up

I followed the documentation provided and it worked quite well up to a point. The btrfs integration works as explained, creating new Gentoo instances just worked, setting up the network… Required some effort.

Network woes

I have just 1 single ipv4 and some ipv6 so why not leveraging them? I decided to partition my /64 and use some, configured the bridge to take ::::1::1 and set up the container configuration like this:

lxc.network.type = veth
lxc.network.link = br0
lxc.network.flags = up
lxc.network.ipv4 =
lxc.network.ipv4.gateway = auto
lxc.network.ipv6 = ::::1::4/80
lxc.network.ipv6.gateway = auto
lxc.network.hwaddr = 02:00:ee:cb:8a:04

But the route to my container wasn't advertised.

Having no idea why I just kept poking around sysctl and iproute2 until I got:

  net.ipv6.conf.all.forwarding = 1
  net.ipv6.conf.eth0.proxy_ndp = 1


ip -6 neigh add proxy ::::1::4 dev eth0

In my container runner script.

I know that at least other people had the problem so here this mini-post.

29 Nov 2015 9:19pm GMT

26 Nov 2015

feedPlanet Gentoo

Andreas K. Hüttel: Grafting history onto your Gentoo git clone

Somehow after a while I got a bit tired that my git checkout of the main Gentoo repository didn't have any real history available. So, here's how I got it back:

(Note, you may want a fast network connection for this.)

$ cd ~/Gentoo/gentoo

$ git fetch https://github.com/gentoo/gentoo-gitmig-20150809-draft.git master:history-20150809-draft

$ echo 56bd759df1d0c750a065b8c845e93d5dfa6b549d 2ebda5cd08db6bdf193adaa6de33239a83a73af0 > .git/info/grafts

And done. :)

Should at some point in the future a new, improved (or "official") conversion of the cvs history become available, here's (untested) what to do:

Once you are happy with the result, you can delete the old local cvs history branch and run "git prune", freeing up the space used by the now obsolete old conversion.

Thanks to rich0 for providing the draft conversion (though inofficial so far) and to everyone else involved.

26 Nov 2015 11:14pm GMT

Alexys Jacob: py3status v2.7

I'm more than two weeks late but I'm very glad to announce the release of py3status v2.7 which features a lot of interesting stuff !

For this release I want to salute the significant work and help of Daniel Foerster (@pydsigner), who discovered and fixed a bug in the event detection loop.

The result is a greatly improved click event detection and bar update speed with a largely reduced CPU consumption and less code !


New modules

Modules enhancements

Thanks !

Once again, thanks to all contributors listed above !

26 Nov 2015 6:52pm GMT

21 Nov 2015

feedPlanet Gentoo

Luca Barbato: Code and Conduct

This is a sort of short list of checklists and few ramblings in the wake of Fosdem's Code of Conduct discussions and the not exactly welcoming statements about how to perceive a Code of Conduct such as this one.

Code of Conduct and OpenSource projects

A Code of Conduct is generally considered a mean to get rid of problematic people (and thus avoid toxic situations). I prefer consider it a mean to welcome people and provide good guidelines to newcomers.

Communities without a code of conduct tend to reject the idea of having one, thinking that a is only needed to solve the above mentioned issue and adding more bureaucracy would just actually give more leeway to macchiavellian ploys.

That is usually a problem since, no matter how good things are now, it takes just few poisonous people to get in an unbearable situation and a you just need one in few selected cases.

If you consider the CoC a shackle or a stick to beat "bad guys" so you do not need it until you see a bad guy, that is naive and utterly wrong: you will end up writing something that excludes people due a quite understandable, but wrong, knee-jerk reaction.

A Code of Conduct should do exactly the opposite, it should embrace people and make easier joining and fit in. It should be the social equivalent of the developer handbook or the coding style guidelines.

As everybody can make a little effort and make sure to send code with spaces between operators everybody can make an effort and not use colorful language. Likewise as people would be more happy to contribute if the codebase they are hacking on is readable so they are more confident in joining the community if the environment is pleasant.

Making an useful Code of Conduct

The Code of Conduct should be a guideline for people that have no idea what the expected behavior, it should be written thinking on how to help people get along not on how to punish who do not like.

People joining the community should consider the Code of Conduct first as a request (and not a demand) to make an effort to get along with the others.


Since I saw quite some long and convoluted wall of text being suggested as THE CODE OF CONDUCT everybody MUST ABIDE TO, here some suggestion on what NOT do.

Good examples

Some CoC I consider good are obviously the ones used in the communities I belong to, Gentoo and Libav, they are really short and to the point.


As I said before no matter how well written a code of conduct is, the only way to really make it useful is if the community as whole helps new (and not so new) people to get along.

The rule of thumb "if somebody feels uncomfortable in a non-technical discussion, once he says, drop it immediately", is ok as long:
* The person uncomfortable speaks up. If you are shy you might ask somebody else to speak up for you, but do not be quiet when it happens and then fill a complaint much later, that is NOT OK.
* The rule is not bent to derail technical discussions. See my post about reviews to at least avoid this pitfall.
* People agree to drop at least some of their cultural biases, otherwise it would end up like walking on eggshells every moment.

Letting situations going unchecked is probably the main issue, newcomers can think it is OK to behave in a certain way if people are behaving such way and nobody stops that, again, not just specific enforcers of some kind, everybody should behave and tell clearly to those not behaving that they are problematic.

Gentoo is a big community so once somebody steps the boundaries gets problematic having a swift reaction, lots of people prefer not to speak up when something happens, so people unwillingly causing the problem are not made aware immediately.

The people then in charge to dish bans have to try to figure out what exactly was wrong and there the cultural biases everybody has might or might not trigger and make the problem harder to address.

Libav is a much smaller community and in general nobody has qualms in saying "please stop" (that is also partially due how the community evolved).

Hopefully this post would help avoid making some mistakes and help people getting along better.

21 Nov 2015 6:54pm GMT

13 Nov 2015

feedPlanet Gentoo

Michał Górny: The Ultimate Guide to EAPI 6

Now that EAPI 6 is Council-approved and pretty close to being deployed, I think it's about time to write up a not-so-short guide to it. It's especially important that EAPI 6 is a bit different from the previous EAPIs. It was not only seen as an opportunity to add new features but also to tidy things up a bit and improve strictness.

If you look into the PMS, you'd see that we'd not only added completely new stuff but also ported a few common eclass functions, in a little cleaner form, and new useful phase functions. Furthermore, we used EAPI 6 as an opportunity to finally increase strictness of Portage in regard to PMS, and ban some long-unwanted eclasses.

Therefore, I'd like to ask you - please don't go hooray-enabling EAPI 6 support in your ebuilds and eclasses. Take a while to think, and do things right. Please think of EAPI 6 as a lifetime opportunity of improving your eclass APIs, as we improved the API provided by Package Managers.

Now, time for a little summary of changes, their implications and a bit of rationale.

Bash upgrade and compatibility setting

The first important change in EAPI 6 is the upgrade to bash-4.2 (the earlier EAPIs required bash-3.2). At a first glance, it just brings a few nice quirks like cleaner fd magic (used by multiprocessing.eclass), case conversion for variables and associative arrays. However, aside to that bash compatibility setting is forced - that could hopefully prevent existing code from breaking in future bash versions.

What does this solve, you ask? For example, it solves the tilde substitution issue:


The above snippet gives the expected result only when executed with bash-4.2 and lower. However, starting with bash-4.3 it performs tilde expansion on right-hand argument of the pattern substitution and puts your home directory in there. You can disable that via backslash-escaping the argument - but then it puts an extra backslash in older bash versions! How frustrating…

Now, if we have BASH_COMPAT fixed by the PM at 4.2, this discrepancy is no longer an issue. Because all supported versions of bash will force the old behavior, you can write the code without any conditionals, workarounds or worrying that it will suddenly break sometime in the future.

failglob in global scope

The second change to ebuild syntax is that filename expansion is now an explicit error in global scope. While this may sound scary at first, it wasn't ever really supported. Note that this doesn't affect phase functions, just the code executed when sourcing the ebuild. This is mostly targeted towards snippets like the following:

inherit python-r1

RDEPEND="$(python_gen_cond_dep 'dev-python/foo[${PYTHON_USEDEP}]' python2*)"

Do you see the problem here? python2* lacks quoting. This usually doesn't cause any issues but if you happened to be in a directory with pythonFOOBAR file while sourcing the ebuild, it would suddenly pick it up and return pretty unexpected results. As a solution, an EAPI=6 ebuild would instantly abort here and require you to quote the pattern.

LC_COLLATE and LC_CTYPE settings

The description for locale settings may seem a little blurry but that's for a reason. The original idea was that the Package Manager would export (pretty much like Paludis does):


to enforce stable sorting and case conversions. Without the former, some locales could cause results of globs such as patch files to apply in different order. Without the latter, some locales could give unexpected results of case changes. In particular, the Turkish tr_TR.UTF-8 locale is only too happy to map lowercase 'i' to uppercase 'İ' (yep, it has a dot above!)

So why is it worded this muddy? Because of our lovely Python and the lot of high quality scripts that are only too happy to interpret read files in the charset corresponding to the current locale, and therefore bail out hard when they don't conform to the ASCII charset implied by the C locale.

So instead of C, we need a C.UTF-8 which hasn't made its way into glibc for… how long exactly? Not to mention the portability. Therefore, we just request a seemingly sane locale, and hope we can work something out. In implementation, the Package Manager will most likely set LC_COLLATE=C directly and complain to the user if his LC_CTYPE does not conform.

Nevertheless, in EAPI 6 you should be able to safely remove your local LC_COLLATE and LC_CTYPE redefinitions, and hopefully also most of those excessive LC_ALL settings.

eapply, eapply_user and src_prepare()

This is probably the most controversial feature of the new EAPI. Those functions are intended as reasonably simple and predictable replacements for the commonly used eutils.eclass beasts, with new default src_prepare() to finish off the long-deprecated base.eclass.

eapply has a few substantial differences from epatch. However, I hope that people will nevertheless decide to abandon the latter, and use the new function, effectively also reducing the use of eutils.eclass. The differences are:

While this may sound like a lot was lost, the function is still quite big and even twice as useful. Most importantly, all patches now apply (or fail) pretty predictably, and if they do fail, you get a clear output.

eapply_user provides user patch support on top of eapply. However, since user patches are a matter of configuration, the PMS really leaves the details to the Package Manager, and doesn't even prohibit it from extending patching beyond eapply. eapply_user is considered obligatory, and can be safely called more than once (applying patches only the first time) to make eclass writing easier.

Both function are used in the default src_prepare() implementation which was inspired by the common implementations shared between multiple eclasses. In particular, it applies patches from the PATCHES variable (array strongly preferred due to ${FILESDIR}) and then user patches. Please note that in some cases, it would be advised to remove src_prepare() from your eclass altogether rather than calling the default from it.

einstalldocs and src_install()

This one's much simpler and accepted in full agreement. It combines two categories of requests created against the documentation install code introduced in EAPI 4. Firstly, it splits the code off default_src_install() so that it can be reused without implicitly calling emake install. Secondly, it solves a number of problems with the original implementation.

So what's the story here? EAPI 4 introduced a very nice src_install() phase which was able to install a few default documentation pieces automatically. That was quite liked, except that it was tightly bound with the default emake install call. As a result, a number of eclasses ended up (still) redefining it, with the most noticeable example of base.eclass having a split phase function for it. But since the eclass was long deprecated already, other eclasses had to copy the code rather than reuse it.

The idea of having a split function arose early during EAPI 6 work. While writing a new function, the issues and requests against the current default were collected and considered. Finally, the new function was given to early Council approval, and committed to eutils.eclass as a backport of the future EAPI 6 function. And as you can see now, it lands in EAPI 6 in exactly the same form, replacing the eutils implementation.

As a reminder, the changes from the original EAPI 4 implementation are:

As a result, the default src_install() implementation differs by the documentation install changes listed above. If you were overriding this phase just to get einstalldocs into it, you can remove it. If you were using einstalldocs from eutils.eclass, you do not have to inherit it anymore. And if you were inlining your own documentation install code, it is a good idea to replace it with standard one in EAPI 6.

get_libdir and econf changes

The next major target for EAPI 6 changes was the econf function, commonly used in src_configure(). Here, two goals were achieved. Firstly, a get_libdir function inspired by multilib.eclass was added. Secondly, --docdir and --htmldir parameters are now passed to configure scripts.

Why would get_libdir be related to econf at all? Well, except for the fact that it's often used in configure script arguments, it pretty much shares the logic used to figure out libdir. So we're not just moving a commonly used eclass function to the EAPI - we're splitting the libdir determination logic off econf, and sharing it with ebuilds.

As for the two new parameters - --docdir and --htmldir - I don't think they really need any comment here.


This one's very controversial as well, and I'd personally prefer not having to introduce it at all. However, without it the developers would still resort to ugly hacks, so better to have a safe alternative. So, what's the background?

Some developers found it quite convenient to do some conditionals in eclasses based on what ends up in IUSE. For example, if the ebuild has IUSE=static-libs, we magically enable code controlling static library build and install. Except for being ugly, this design had two major issues. Firstly, the code checking that was inconsistent and often buggy - some eclasses handled +static-libs, some didn't. Secondly, the specification never mandated IUSE having any sane value throughout phase functions. So the results could have been quite surprising.

EAPI 6 solves both of those issues by providing a standard in_iuse function. All uses implementation-defined magic to check whether the specified flag is listed in the IUSE_EFFECTIVE conceptual variable. This includes not only flags set by ebuilds and eclasses but also implicitly added by profiles - in other words, any flag that is legal to the use function call.

I should note that in_iuse is legal only in phase functions - it is disallowed in global scope (i.e. while IUSE is still subject to changes). Nevertheless, I would heartily recommend avoiding it and using explicit conditional variables instead.

nonfatal die

Did you happen to dislike how some eclass-defined helpers could not be nonfatal properly? That's no longer the case with EAPI 6. The die function has gained a simple -n option which makes it respect nonfatal, and therefore be a no-op when it is in effect.

In other words, you can write helpers like the following:

efoo() {
        foo || die -n "foo failed" || return ${?}

where die would simply return false and continue execution if nonfatal is in effect. Please remember that 'nonfatal die' does not return from the function implicitly. If you need to do so, you need to explicitly call return like in the above snippet.

unpack changes

Now we're past the most interesting changes. For completeness, there were few small requests accepted for the unpack function:

einstall banned, dohtml deprecated

Aside to new features, there are two important removals to be noted. The long-discouraged einstall function has been finally banned, and the dohtml function has been deprecated with the goal of removing it in EAPI 7.

The einstall command was intended as a cheap work-around for build systems that did not support DESTDIR= argument to emake install. Instead, it redefined a number of direct install paths (such as bindir=), passing the staging area path and target directory combined. Sadly, it has often been cause of confusion for new developers who have seen it as the standard install command (in line with econf, emake…).

Over a year ago, I've started tracking uses of einstall on behalf of QA, and noticed that most of the uses were completely unnecessary, either because the build system in question handled DESTDIR= correctly, or had a custom variable serving the same purpose. Furthermore, the function used parameter names matching autoconf while it was intended to deal with custom build systems which may require other variables. Therefore, it was decided that it is better to ban the command and inline the relevant make parameters whenever really unavoidable.

The dohtml function has been the official way of installing HTML documentation for quite a long time. No other command defined by PMS had as many options. Confusingly to some developers, it provided implicit filtering by file suffixes, with additional options to add additional suffixes, replace suffix list, filter by filename, exclude directories and directly alter install path. Moreover, there was yet another enhancement request asking for new suffixes in the default filter.

The Council has agreed with us that the function is overcomplex and confusing, and will be an object of never-ending requests and updates. Most of Gentoo developers have seen it as a way of installing files in the html/ subdirectory of docdir while it did so much more - and potentially confused them by excluding some files. It also resulted in absurd situations like people moving gtk-doc files out of the standard location used by gtk-doc just to match the 'standard' established by the function.

dohtml is officially deprecated since EAPI 6, and is expected to be banned in EAPI 7. The suggested replacement is dodoc which is much simpler, faster and in many cases will work the same (or even better, by restoring the files that were mistakenly missed by dohtml). It is possible that the current dohtml will eventually be moved to an eclass for the ebuilds that require filtering, yet the fate of this idea is unclear yet.

To help with the migration, Portage provides the following quirk (for make.conf or environment):


When run with this, each dohtml invocation will verbosely list all files that were skipped through filtering. A null output indicates that dohtml can be safely replaced by dodoc.

Global-scope helpers banned in Portage

EAPI 6 brings not only the spec changes but also new strictness to Portage. In particular, almost all helper functions are now banned in global scope, as they are banned by PMS and other package managers. What does this imply? Most importantly, toolchain's use of USE=multislot is now officially banned and will no longer work in EAPI 6.

Eclasses banned in EAPI 6

Finally, the changes brought by EAPI 6 will likely result in a number of API changes in multiple eclasses. Moreover, some of the existing eclasses will become completely unnecessary and will be banned.

The most important example here is the base.eclass which was semi-officially deprecated for a long time. In EAPI 6, it is fully replaced by default phase functions and must not be used. Similarly, I've decided to discontinue and ban autotools-utils.eclass and autotools-multilib.eclass, the former serving a similar purpose as base.eclass did in the past and the latter being just a wrapper atop multilib-minimal.eclass.

Aside to that, I've banned a number of eclasses that are deprecated currently, to avoid their use being carried on to the next EAPI.


To summarize all the changes in EAPI 6, let me assemble a check list of tasks that need to be done when updating ebuilds to EAPI 6:

  1. You can update your bash code to use bash-4.2 features, and remove unnecessary conditionals for future-incompatible behavior. It is unlikely that you have any.
  2. Ensure that all patterns that are supposed to be passed as-is to functions are quoted.
  3. Remove unnecessary LC_COLLATE and LC_CTYPE if they only reset it to the C (or POSIX) locale.
  4. If you are using epatch, try hard to replace it with eapply. You may need to pass an explicit -p value.
  5. If you are using epatch_user, you have to replace it with eapply_user. If you are not and you define src_prepare(), you have to add it there.
  6. If you are left with src_prepare() that looks pretty much like the default one, drop it. It is also a good idea to remove unnecessary src_prepare() definitions from eclasses.
  7. If you are using einstalldocs, this function is now part of EAPI. Don't count it as a reason to inherit eutils.eclass. If you are using a similar inline code, it's about time you switch to einstalldocs.
  8. If you are using in_iuse, this function is now part of EAPI and even really legal. Don't count it as a reason to inherit eutils.eclass. In fact, hurry to switch to EAPI 6 to get a predictable behavior!
  9. Check if you are still using anything from eutils.eclass. If you are not, remove the inherit and save a few cycles.
  10. If you are using get_libdir, this function is now part of EAPI. Don't count it as a reason to inherit multilib.eclass. If you are not using anything else from multilib.eclass, remove the inherit.
  11. If you are passing standard --docdir and/or --htmldir to econf, you can remove them. EAPI 6 does that for you.
  12. If you are defining ebuild helpers that should respect nonfatal, you should update appropriate die to use die -n || return. However, please note that it's usually a good idea to use regular die on usage errors, and respect nonfatal only for external errors.
  13. If you are using hacks to support .txz, uppercase archive suffixes like .ZIP or extracting files by absolute or relative paths, you can remove them and use new unpack features.
  14. If you are using einstall, remove it. I'm pretty sure you never really needed it. And if you really did, then you most likely missed some custom prefix option in upstream build system.
  15. If you are using dohtml, consider replacing it with dodoc -r. You can set PORTAGE_DOHTML_WARN_ON_SKIPPED_FILES=yes before doing that, to see if the two will be equivalent.
  16. If you are inheriting base.eclass, autotools-utils.eclass or any of the other banned eclasses, make sure to remove it from your eclasses and ebuilds.

13 Nov 2015 9:13pm GMT

06 Nov 2015

feedPlanet Gentoo

Luca Barbato: Reviews

This spurred from some events happening in Gentoo, since with the move to git we eventually have more reviews and obviously comments over patches can be acceptable (and accepted) depending on a number of factors.

This short post is about communicating effectively.

When reviewing patches

No point in pepper coating

Do not disparage code or, even worse, people. There is no point in being insulting, you add noise to the signal:

You are a moron! This is shit has no place here, do not do again something this stupid.

This is not OK: most people will focus on the insult and the technical argument will be totally lost.

Keep in mind that you want people doing stuff for the project not run away crying.

No point in sugar coating

Do not downplay stupid mistakes that would crash your application (or wipe an operating system) because you think it would hurt the feelings of the contributor.

    rm -fR /usr /local/foo

Is as silly as you like but the impact is HUGE.

This is a tiny mistake, you should not do that again.

No, it isn't tiny it is quite a problem.

Mistakes happen, the review is there to avoid them hitting people, but a modicum of care is needed:
wasting other people's time is still bad.

Point the mistake directly by quoting the line

And use at most 2-3 lines to explain why it is a problem.
If you can't better if you fix that part yourself or move the discussion on a more direct media e.g. IRC.

Be specific

This kind of change is not portable, obscures the code and does not fix the overflow issue at hand:
The expression as whole could still overflow.

Hopefully even the most busy person juggling over 5 different tasks will get it.

Be direct

Do not suggest the use of those non-portable functions again anyway.

No room for interpretation, do not do that.

Avoid clashes

If you and another reviewer disagree, move the discussion on another media, there is NO point in spamming
the review system with countless comments.

When receiving reviews (or waiting for them)

Everybody makes mistakes

YOU included, if the reviewer (or more than one) tells you that your changes are not right, there are good odds you are wrong.

Conversely, the reviewer can make mistakes. Usually is better to move away from the review system and discuss over emails or IRC.

Be nice

There is no point in being confrontational. If you think the reviewer is making a mistake, politely point it out.

If the reviewer is not nice, do not use the same tone to fit in. Even more if you do not like that kind of tone to begin with.

Wait before answering

Do not update your patch or write a reply as soon as you get a notification of a review, more changes might be needed and maybe other reviewers have additional opinions.

Be patient

If a patch is unanswered, ping it maybe once a week, possibly rebasing it if the world changed meanwhile.

Keep in mind that most of your interaction is with other people volunteering their free time and not getting anything out of it as well, sometimes the real-life takes priority =)

06 Nov 2015 5:03pm GMT

05 Nov 2015

feedPlanet Gentoo

Mike Pagano: kdbus not in gentoo-sources

As per upstream developers instructions to Fedora maintainers [1] , kdbus will not be included in any new gentoo-sources genpatches release.

Of course, I will revisit when upstream feels it's ready to be tested in distributions once again.

[1] http://lwn.net/Articles/663062/

05 Nov 2015 11:33pm GMT

20 Oct 2015

feedPlanet Gentoo

Alexys Jacob: uhashring : consistent hashing in python

It's been quite some time since I wanted to use a consistent hashing based distribution of my workload in a quite big cluster at work. So when we finally reached the point where this became critical for some job processing I rushed to find out what python library I could use to implement this easily and efficiently.

I was surprised not to find a clear "winner" for such a library. The more "popular" named hash_ring has a rather unoptimized source code and is dead (old issues, no answer). Some others stepped up since but with no clear interest for contributions and almost no added features for real world applications.

So I packaged the ketama C library and its python binding on my overlay to get intimate with its algorithm. Then I started working on my own pure python library and released uhashring on Pypi and on Gentoo portage !



Not so sure about hash tables and consistent hashing ? Read my consistent hashing 101 explanation attempt !

20 Oct 2015 9:05pm GMT

09 Oct 2015

feedPlanet Gentoo

Nathan Zachary: Amavisd fails to start due to BerkeleyDB, libdb, and db.h


My tech articles-especially Linux ones-are some of the most-viewed on The Z-Issue. If this one has helped you, please consider a small donation to The Parker Fund by using the top widget at the right. Thanks!

Yet again, I had troubles with restarting amavisd after some package updates. You can see about the other problems that I've had with the application in these two previous blog posts: missing SpamAssassin rules causing amavis to fail and start-up failures due to a missing Perl IPv6 module.

This time, the problem was related to the backend database used for Bayes filtering within SpamAssassin, although it wasn't readily clear what the problem was. After updating SpamAssassin, I saw the following message from Portage (Gentoo's package manager):

* You need to configure your database to be able to use Bayes filter
* with database backend, otherwise it will still use (and need) the
* Berkeley DB support.
* Look at the sql/README.bayes file in the documentation directory
* for how to configure it.

At first, I thought that there was a problem with my MariaDB installation, but then I remembered that I'm currently still using BerkeleyDB (BDB) for SpamAssassin.

After trying to stop and restart amavisd, zapping the configuration (which was a problem mentioned in one of my previous posts), manually killing the running amavisd processes, and a few other things, I was still left with a configuration that would cause amavisd to fail on startup:

* Starting amavisd-new ...
Problem in Amavis::DB or Amavis::DB::SNMP code:
BerkeleyDB needs compatible versions of libdb & db.h
you have db.h version 6.0.30 and libdb version 6.0.35
Compilation failed in require at (eval 93) line 20.
BEGIN failed--compilation aborted at (eval 93) line 20. [ !! ]
* ERROR: amavisd failed to start

Out of sheer desperation, I attempted what seemed to be an unlikely fix by recompiling BerkleyDB (via emerge -v dev-perl/BerkeleyDB). Lo and behold, amavis decided to start after that recompilation! It's a bit strange to me that the standard tools like revdep-rebuild and emerge @preserved-rebuild didn't catch this problem.

In any case, third time is a charm with amavisd. Hopefully there won't be any further problems when attempting to reload or restart it.


09 Oct 2015 10:43am GMT

04 Oct 2015

feedPlanet Gentoo

Sebastian Pipping: Keeping Gentoo systems up-to-date / update notification


Frequent updates are important, especially with Gentoo. You probably have seen conflicts that filled several screens and were not trivial to resolve. With frequent updates, handling conflicts becomes a lot easier. Frequent updates also gets you security fixes earlier. I would have done it from the beginning, if something would have reminded me to update. By now, for notifications on available updates I use

Former is a tool by Benedikt Böhm sending e-mails with emerge --pretend output whenever it changes. Latter is a bit of a quick hack by me that sits in the tray and shows an icon if updates are available with the number of updates in a tooltip. It requires a cron job to run something like eix-sync once a day but that's probably a good idea anyway.
Maybe it's something that you want to use too. If you run into bugs, please report them and share your patches if any. GitHub allows attaching text files by now, it may work with patches, too.

I would be curious to hear what other tools you use for being notified of updates on Gentoo. Please leave a comment below.

Best, Sebastian

04 Oct 2015 11:56pm GMT

Chí-Thanh Christopher Nguyễn: Latest Toy: The Orange Pi PC

You may have heard about the latest Raspberry Pi 2 clone: The Orange Pi PC, a device that sells for only $15 yet comes with a quad-core Allwinner H3 and 1 GB RAM. (But don't be fooled - while "open source" is mentioned everywhere on that website, the actual open source situation is still pretty bad).

After my Raspberry Pi started acting up and run very unstable a year ago, this looked like a nice replacement. Thus I decided to order the "Orange Pi PC set 3" including a plastic case and power cable from AliExpress, and will try to get Gentoo running on that device. The manufacturer's Gentoo forum section is all crickets, so I expect to encounter at least some problems.

If you want to see this thing in action, or at least watch me struggling to get Gentoo running, come next weekend (10+11 October 2015) to the Prague Linux Days and visit the Gentoo booth.

04 Oct 2015 2:33pm GMT

02 Oct 2015

feedPlanet Gentoo

Rafael Goncalves Martins: blogc: helper tools

While users may be able to use blogc as is with the help of generic tools, some of these tools are really boring to setup.

With that in mind, I'm trying to develop some simple tools to help the users getting their blogs online. At this point I have two tools ready for usage:

Packages are available for Gentoo, and in my Copr repository for RHEL/CentOS/Fedora.


blogc-git-receiver is a login shell and a git pre-receive hook, that can create git repositories and build/deploy your websites automatically. Users just need to create an user, configure it to use blogc-git-receiver as its login shell, then every time that some authorized user pushes to a repository it will create a local bare repository in the server, if needed, and if the push includes some change to the master branch, it will rebuild your website for you.

blogc-git-receiver tries to be as atomic as possible, building the new version of the website in a separate directory, and using a symlink to point to the most recent version of the website, removing the old version only after a successful new build.

blogc-git-receiver creates a symlink inside the bare git repository, called htdocs, that points to the last successful build. Users just need to make their webservers use this symlink as document root for their virtual host, and make sure that the webserver can follow symlinks.

With this tool, users can create their own PaaS-like environment, using a cheap VPS to host lots of blogs. ;-)

This tool is one of the reasons why I wanted to make blogc as fast as possible, because it will rebuild all the website every time, not just the changes, for the sake of consistency.

This tool is also a good sample code for people interested in understand how a login shell and a git hook works.

Gentoo package is dev-vcs/blogc-git-receiver and RHEL/CentOS/Fedora package is blogc-git-receiver.

Some simple documentation is available at: https://github.com/blogc/blogc-git-receiver


blogc-runserver is a simple HTTP server, that comes with several rules pre-defined, that tries to mimic the way most production servers work when serving static websites. Users just need to point blogc-runserver to the output directory where blogc created its result files.

A simple Makefile rule is able to run your website for testing:

serve: all
        blogc-runserver $(OUTPUT_DIR)

Yeah, it is really that simple! :)

Please keep in mind that this server should not be used in production. It is really simple, and developed for testing purposes.

Gentoo package is www-servers/blogc-runserver and RHEL/CentOS/Fedora package is blogc-runserver.

Some simple documentation is available at: https://github.com/blogc/blogc-runserver

Other tools

I have more ideas of new tools, that I will probably explain in future posts, but if you have ideas of useful tools, please let me know.


02 Oct 2015 3:51am GMT

29 Sep 2015

feedPlanet Gentoo

Paweł Hajdan, Jr.: Gentoo's top-notch user community

One of the best parts of Gentoo for me is the community.

For example, I regularly receive email from people who volunteer to help with testing hard masked www-client/chromium ebuilds. FWIW you don't need to email me or the Gentoo Chromium team - just start testing and filing bugs. On the other hand, I do appreciate when people express interest in helping out.

Another example is helping with getting bugs resolved.

Bug #556812 looked rather mysterious - until Guillaume ZITTA found that "build" is a red herring, and in fact the "tracing" module being imported is a different one (from dev-python/tracing as opposed to chromium sources). It was an unfortunate names collision - once found, quite easy to fix.

In bug #553502 Johan Hovold found we need to require postproc USE flag for libvpx to avoid a crash.

See bug #551666 for some Alexey Dobriyan's gdb magic mostly based on a single line segfault report from dmesg...

These are just a few examples.

By the way, the area where we could use more help is arm architecture support. Some specific bugs where help is wanted are #555702, #545368, #520180, and #483130. Please report whether you can reproduce or not, post emerge --info from your system and the compressed build log in case build fails.

29 Sep 2015 7:39pm GMT

27 Sep 2015

feedPlanet Gentoo

Domen Kožar: Friends sometimes let friends curl to shell

Every now and then (actually quite often), people complain on twitter they're afraid of our simple bash installer for Nix package manager:

$ bash <(curl https://nixos.org/nix/install)

Example (from today):

There are popular blog posts discouraging use of it.

Ask yourself a question, how would package manager install itself? Via another package manager?

If we assume nixos.org is not compromised (which is really hard to detect), using TLS to secure connection and with our simple trick to prevent partial download execution (you haven't read the script yet, right?), what can really go wrong?

It's the most transparent way to see how the package manager can be bootstrapped: read the source, Luke.

If you still have a reason why piping to shell is a bad idea, let me know.

27 Sep 2015 5:50pm GMT

24 Sep 2015

feedPlanet Gentoo

Matthew Thode: OpenStack on Gentoo is awesome

Some may wonder why to run OpenStack on Gentoo, it's akin to running one extremely complex piece of software on another potentially extremely complex operating system.

I propose Gentoo as the most correct operating system to run OpenStack as Gentoo is best prepared to handle some of the complexities that come with OpenStack.

Things Gentoo does well for OpenStack

Future of OpenStack on Gentoo

  1. The Liberty release 15/10/2015
    • Upstream is reversioning the major components of OpenStack, 2015.2.0 will not exist, it will be something like 12.0.0.
    • The reversioning will mean some manual intervention if you wish to use Liberty on Gentoo, namely you will need to mask greater than version 2000 of the major components of OpenStack
  2. More services
    • I will at least add Heat during the next (Liberty) release cycle, possibly more
    • I will investigate readding Horizon, but doubt it'll be easily packagable.
  3. Security
    • I'd like to look into some of the selinux policies that are being developed for some of the services. I know nova/qemu has apparmor support.

Limits of testing

You cannot directly test OpenStack packages by emerging with USE="test" FEATURES="test" because there are interdepenecies that cause loops in the depgraph of portage for the (test) dependencies. You can get around it one way though.

# install only the test deps
emerge --onlydeps --oneshot --with-test-deps sys-cluster/nova
# test and install the actual package
USE="test" FEATURES="test" emerge sys-cluster/nova

24 Sep 2015 5:00am GMT

23 Sep 2015

feedPlanet Gentoo

Alex Legler: Repackaging packages.gentoo.org

Update: The site is now live at packages.gentoo.org!

Gentoo has seen quite some refreshing updates this year: In April, our website was relaunched (twice ;)) and our main package repository is now finally powered by git. There is one service though that sort-of relates to both, but this service has not seen an update in quite some time: Let's talk about packages.gentoo.org.

The fact that we now use git for what was before called gentoo-x86 requires a set of changes to our package website. Several repository URLs are different now, and especially the changelogs that are now taken from git log messages need new code to display properly. As many participants in our website survey a while back have also noted, the time is most ripe for a change of scenery on "pgo".

As having a good package search is one of the most-requested feature for the site, I've built a new site around elasticsearch (which also powers the new Gentoo mailing list archives). It is nearing completion as a minimum viable product, but already available for you to test in a beta state.

So, head over to https://packages.gentoo.org/ https://packagestest.gentoo.org/ and feel free to browse around. Some things are not available yet and the caching has not been fully enabled, so things might take a second to render. I'd be glad to hear your thoughts and ideas on the site-either as a comment here, or if you prefer on freenode in #gentoo-www.

As a sneak peek, here's the site rendered on a small screen in case you don't have your $device handy:


23 Sep 2015 6:59pm GMT