The Python framework web2py is pretty powerful when it comes to automagical form and data handling. A quite common use case in an application is the need to manage a business object that might have many relations to some other business object, e.g. one package might consist of many components. If you use one database table for each object there are at least two approaches to create a many-to-many relation in web2py.
After the last weekly update of my Sabayon Notebook I encountered a high CPU load of one core caused by syslog-ng. The process was literally flooding /var/log/messages and within a couple of minutes tens of Megabyte accumulated. logrotate did not help. The messages were months old, it appeared as syslog-ng would be processing old logs from somewhere else.
I knew that journald was active too, complementing syslog-ng I thought. Some ddg searches later I stumbled over a Gentoo bug report confirming my issue.
Instead of masking syslog-ng-3.6.1 I headed to #sabayon and asked around. Someone explicitly mentioned that syslog-ng is likely pulling logs from journald.
I ended up editing /etc/syslog-ng/syslog-ng.conf and replacing the default source src:
Das Foto auf der elektronischen Gesundheitskarte (eGK) verletzte laut einer Entscheidung des Bundessozialgerichts in Kassel nicht das Recht auf informationelle Selbstbestimmung.
Die weitere Begründung lässt einen ungläubig die Augen reiben:
[...] Das Recht schützt bereits die betroffenen Daten vor unbefugtem Zugriff Dritter und vor missbräuchlicher Nutzung. Dass die Datensicherheit faktisch unzulänglich ist, lässt sich zudem zur Zeit nicht feststellen: Die Telematikinfrastruktur ist noch im Teststadium. – Pressemitteilung des BSG
One of my machines is a Lenovo T420s running on Sabayon Linux in a dual monitor setup with discrete graphics set up in the BIOS. The latest sabayon-weekly update (installed on 22.10.2014) shipped the nvidia-drivers-340.46, afterwards the graphics setup was messed up: The second monitor was not recognized anymore while Xorg continued to handle the desktop as usual, i.e. expanded over two displays. Even after a reboot with detached monitor I just saw a background pattern on my integrated display where I should have a login box.
I tried a couple of approaches to fix this behaviour:
Tried to downgrade the drivers to the previously installed version 340.32 by masking nvidia-drivers-340.46 and nvidia-userspace-340.46. I could not go back to that version with Entropy, instead it installed 304.123. That version broke my Xorg completely with lots of slow flickering indicating a couple of tries to initialize the graphics adapter, eventually leading to a crashed Xorg startup.
Removed/modified/replaced /etc/X11/xorg.conf with previously working configurations and tried tips from various forums.
I noticed that in xrandr the second monitor was detected as attached. I was just not able to configure it at all using nvidia-settings. That one was quite persistent in just offering me two display labeled with some Lenovo name.
Eventually I decided to get rid of the proprietary Nvidia drivers and give Nouveau another try. I had tried Nouveau a couple of years ago and at that time I had trouble to get it up and running. Nouveau has since evolved and I was able to restore my graphics setup to a working state:
$ sudo equo install nouveau
Checked available OpenGL implementations:
$ sudo eselect opengl list
Available OpenGL implementations:
 nvidia *
Set the OpenGL implementation to xorg-x11:
$ sudo eselect opengl set 2
Commented out the blacklisted nouveau in /etc/modprobe.d/blacklist.conf.
Moved /etc/X11/xorg.conf temporarily to have a fresh Xorg startup.
One note: Step (4) is critical. I did not check the blacklisting and was wondering why Xorg was only using 1024x768 and the control center display settings in Gnome were just showing an “unknown monitor”. Sabayon seems to blacklist nouveau by default.