There is a Perl module that I have been developing. It is now finding its way onto CPAN and the openSUSE Build Service; the process of reaching that goal, however, was a bit tedious -- hence this blog entry which will describe the workflow so I won't have to reinvent the wheel each time I want to do this again.
Read more »

AMD Catalyst 13.12 (fglrx 13.251) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-13.12.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1, 12.2, 12.3, 13.1 sowie bis Kernel 3.13.

[UPDATE 21.03.2014]
Das Packaging Skript für AMD Catalyst wurde aktualisiert und ein Kernel-Patch hinzugefügt. Ab sofort wird Kernel 3.14 unterstützt.
[/UPDATE 21.03.2014]

Nachfolgende Release Notes von AMD zum AMD Catalyst 13.12:

Folgende Probleme sind im Treiber behoben worden:

• [384861]: Ultra slow dota2 fps
• [383176]: System hang when startx after enable Eyefinity
• [383109]: System hang when run Unigine Heaven 4.0
• [382494]: Screen corruption when run C4Engine with GL_ARB_texture_array enabled
• [384193]: Fix the procfs permission issue on kernel 3.10 and later
• [373812]: System hang when run some OpenGL stress test
• [383430]: Glxtest failed with force AA
• [383372]: Fail to launch cairo-dock
• [384509]: glClientWaitSync is waiting even when timeout is 0
• [383573]: AC/DC switching is broken
• [384194]: Tear-Free Desktop sets V-Sync to 30Hz instead of 60Hz
• [385123]: CrossFire aspect observed in CCCLE where it should not
• [385414]: Steam crashes and games hang on a black screen when Force AA is on
• [387027]: Glxtest failed on SLED11 SP3
• [382079]: MARI crash with weird stack
• [387797]: X crash when kill X with Xserver 1.13 and 1.14
• [389431]: Screens are distorted when connecting an external monitor on some PowerXpress platform with Intel Haswell
• [389728]: Segfault after disabling display on re-launch of CCCLE
• [387573]: Soft hang and error observed on BasicDebug sample for OpenCL when run on x86
• [385704]: Black window when run glxgears with TWM
• [376115]: Display corruption when using rotation

Link: AMD Catalyst 13.12 LINUX Driver Release Notes

Rezension zum AMD Catalyst 13.12:
Aus der Release Notes geht hervor, dass der Treiber offiziell bis Kernel 3.11 unterstützt. Mit dem letzten Beta-Treiber konnte man das fglrx-Kernelmodul auch noch für Kernel 3.12 bauen und wäre in diesem Sinne ein kleiner Rückschritt. Leider hat AMD den Vogel abgeschossen und die Folge war, dass das fglrx-Kernelmodul gar nicht erst mit dem Kernel 3.8 oder höher kompiliert. Alle Linux-Distributionen sind von diesem Fehler betroffen.

Außerdem gab es noch weitere Missgeschicke von AMD, dass ich meinen Frust im nicht-öffentlichen AMD-Forum für Beta-Tester freien Lauf ließ, in der auch die AMD-Entwickler mitlesen. AMD hat einfach versäumt, den finalen Treiber vor der Freigabe ordentlich auf einem x-beliebigen Linux-System zu testen. Daher hatte ich auch am Tag des Release keine Lust gehabt, die Fehler von AMD überall noch zu beheben.

Nun ja, ich habe doch den Versuch gewagt und den Treiber soweit zum Laufen gebracht, dass dieser sogar auf dem kommenden Kernel 3.13 läuft. AMD macht echt für einen Paketbetreuer wie mir das Leben schwer. Dabei will ich einfach nur einen Treiber haben, der sich ohne Problem auf openSUSE installieren lässt und auch läuft. Wenn das Qualitätsmanagement von AMD korrekt durchlaufen worden wäre und auch uns Beta-Tester vor dem Release eingebunden hätte, hätte man alle möglichen Fehler gefunden und auch rechtzeitig vor dem Release behoben.

Folgende Steam-Spiele habe ich getestet und arbeiten mit diesem Treiber einwandfrei zusammen:

• Crusader Kings II
• Duke Nukem 3D: Megaton Edition
• Euro Trucker Simulator
• Europa Universalis IV
• Shadow Warrior Classic Redux
• Strike Suit Zero

Leider gibt es mit der CAD-Software EAGLE 6.5.0 noch grafische Darstellungsprobleme. Hier hilft es vorübergehend auf ein anderes Grafiksystem umzuschalten:

./eagle -graphicssystem native

Eine kleine Bitte habe ich: Wenn irgendwelche Probleme mit dem Treiber auftauchen, scheut euch nicht mir zu berichten (Ich nehme deutsche und englische Bugreports gerne entgegen). Ich werde versuchen, soweit es mir möglich ist, den gemeldeten Fehler zu reproduzieren. Zusammen mit den nötigen System-Informationen werde ich mich direkt an die richtige Stelle bei AMD wenden, um den Bug in der nächsten Treiber-Version beheben zu lassen. Danke schön.

Für Benutzer älterer AMD Grafikkarten (Radeon HD Serie 2000 – 4000) wird dringend die Installation dieses Treibers abgeraten. AMD hat einen Legacy-Treiber zur Verfügung gestellt. Mehr Informationen zum Legacy Treiber: http://www.sebastian-siebert.de/2013/01/25/opensuse-amd-catalyst-13-1-legacy-treiber-als-rpm-installieren/

Downloads:

• Skript: makerpm-amd-13.12.sh
• SHA1: makerpm-amd-13.12.sh.sha1

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-amd-Skript

Über das makerpm-amd-Skript

Das Skript makerpm-amd-13.12.sh ist sehr mächtig, robust und läuft vollautomatisch. Der AMD-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:

-b	Nur das RPM-Package bauen (Standard)
-c <type>	Nur X-Server konfigurieren. Monitor-Typ: single = 1 Monitor, dual = 2 Monitore (Wichtig: Nur ausführen, wenn es Probleme mit der Standardkonfiguration des X-Servers auftreten)
-d	Nur den AMD-Installer downloaden
-i	Das RPM-Package bauen und installieren bzw. updaten
-kms <yes|no>	Kernel-Mode-Setting (KMS) aktivieren oder deaktivieren
-nohw	Hardware-Erkennung explizit ausschalten. (z.B. beim Bau in einer VM)
-old2ddriver <yes|no>	den alten 2D-Treiber aktivieren oder deaktivieren
-r|–report	erstellt ein Report und speichert diese in eine Datei namens amd-report.txt
-u|–uninstall	entfernt AMD Catalyst restlos vom System. Zuerst wird das fglrx-Package (falls vorhanden) vom System deinstalliert. Danach werden vorhandene AMD-Dateien und -Verzeichnisse entfernt. Hinweis: Falls das Rebuild-Skript installiert wurde, wird es ebenfalls entfernt und das Initskript /etc/init.d/xdm wiederhergestellt.
-ur|–uploadreport	wie Option –report nur zusätzlich wird der Report auf einem NoPaste-Service sprunge.us hochgeladen und gibt bei Erfolg den Link zurück.
-h	Die Hilfe anzeigen lassen
-V	Version des Skript anzeigen

Hilfe, es funktioniert nicht!

Bitte haltet folgende Regel ein:

1. Bei der Eingabe der Befehle auf mögliche Tippfehler überprüfen.
2. Möglicherweise ist die Lösung für das Problem im Wiki vorhanden.
3. In Kommentaren lesen, ob eine Lösung zu einem Problem bereits existiert.

Wenn keines der o.g. Regel greift, dann könnt ihr mit eurem Anliegen an mich wenden. Damit ich euch helfen kann, müsst ihr erst vorarbeiten. Bitte ladet euch das Skript makerpm-amd-13.12.sh herunter und erstellt einen Report von eurem System in der Konsole:

su -c 'sh makerpm-amd-13.12.sh -ur'

Das Skript lädt das Report auf sprunge.us hoch und gibt anschließend einen Link aus. Diesen Link postet ihr in eurem Kommentar zusammen mit einer Beschreibung zu eurem Problem an mich. Ich werde mir euren Report anschauen und Hilfestellung geben, wo evtl. das Problem liegen könnte.

Feedbacks sind wie immer willkommen.

Recently I decided to update my blog to something that will be less awkward than NanoBlogger I have been using until now. I mean, writing the entries in vim is great, running the nb script is easy, but the turnover to preview it, fix, run the script again etc. is just annoying.

Now I moved my old blog to holesovsky.blogspot.com, which will be much easier for me to handle. With some Perl scripting, I even converted all the old entries here, so that the old blog can really RIP.

Small note to the conversion

When you are using the blogger.com's Import XML feature, and it looks like the import is taking too long (minutes or so), the answer is simple: Your XML was not accepted by blogger.com. I have seen reports of people waiting several hours to import the blog.

Don't wait in such cases - it was just that an error occurred, and the UI has not reported that. Just try to find out what is in the XML that could have caused the import to get stuck - usual suspects are &'s instead of " or OTOH things like &Acaron;, or other less common escapes.

1. I think some people from the openSUSE community has perceived this first mail as a negative criticism to the project and their contributors. Cold analysis based on numbers do not provide a complete picture of the project... but provides a good one, in my opinion. I wrote the below mail/article thinking about a better future, not to revisit a past I am part of. 
2. A summary of the proposals was published in an openSUSE Team blog post. Please read it to get in context. As stated in that article, this first mail/article has as goal to share the motivations behind the later published proposals, trying to open a discussion about our current state that can lead us to agree on a picture we can use as starting point.
3. At the end of the article/mail, I proposed some questions. If you are interested in answering them (I would appreciate it), please:

• Subscribe to the openSUSE-project mailing list. Check how to do it first. 
• Make your comments as a reply of this thread.

Otherwise, in order to keep the debate centralized (for record purposes also), I will post/summarize your answers and comments also in that mailing list.

----------
 


INTRODUCTION/GOALS

• Share a picture as a starting point of discussion.
• Use the discussed picture as a reference to agree on actions we all can/want to execute. 

FIRST STEP: PIECES OF THE PUZZLE

One of the first things we did was digging into numbers that provided us information about the status of the project. Data cannot be the only source to create a complete picture, but it is helpful as first step.

• Alberto Planas talk at oSC13: openSUSE in Numbers[1]
• Alberto Planas' slides from the above talk[2]
• First openSUSE Team blog post: Numbers in openSUSE[3]
• Second openSUSE Team blog post: More on statistics[4]
• Jos post about numbers[5] 

1.- Downloads



2.- UUIDs (installations that update regularly)

• Looking at the number of machines that regularly update against openSUSE repositories (daily, weekly and monthly), we can easily conclude that the situation is very stable. The speed of growth (daily and weekly stats) or decline (monthly) is low.
• What the graph do not show is the acceleration. It has been negative (small in value) for quiet some time now.
• When looking at the architectures, we see that x86_64 is more popular than i586. This behavior is accelerating, as confirmed in the download numbers collected for 12.3
• When looking at the mediums where those installations come from, we clearly see three dominant ones: .iso (dvd version), ftp (net installs) and Live CD.
• There is a relevant detail that Alberto mentioned in his talk. More than half, almost 2/3, of openSUSE installations are not using the last version many weeks after Release date. There is also a significant amount of installations using unmaintained or Evergreen versions.

3.- Factory and Tumbleweed installations/"users"

4.- Contributors to factory and devel projects


5.- Social media and comparison with Fedora


SOLVING THE PUZZLE


ADDING CONTEXT TO THE PICTURE

YaST switched to the GPL license back in 2004, but there were still a lot of obstacles to easy contributions to the project. There was a bunch of changes in the past to improve contribution to the project, like switching from the openSUSE subversion server to GitHub, generating documentation to doc.opensuse.org or having public IRC. But we are not satisfied and do even more steps to make it easy to contribute to YaST.

The most visible action in the last year was the conversion from YCP to Ruby. We found that having a special language just for YaST made some sense in the past, but now becomes useless and makes obstacles for newcomers which must at first learn a language before they can change anything. Ruby is a well known language with a nice ecosystem around including benchmarking, profiling, debugging or testing frameworks. The latest mentioned testing framework is quite important, because good test coverage allows reducing of fear from changes. For tests we chose the well known framework RSpec, so people coming from the Ruby world know it and others find it intuitive.

Related to tests are also continuous integration that tests code after each code change and automatically sends new packages to the devel project and to Factory if needed. We make our CI node publicly visible on the openSUSE CI server, so everyone can see if build succeeded and what is the reason if it failed.

We also decided to help newcomers with a quick introductory documentation. One page recently updated to reflect the current state is about code organization which helps newcomers to orient in current YaST modules. The content is a bit terse and a minority of pages links to some old tutorials and documentation, but we take care to quickly react to questions and suggestions.

Another change is deletion of the internal YaST IRC channel and now all communication happens on the #yast Freenode channel. This change really increases the chance that you catch YaST developers on IRC. Others ways are the YaST mailing list, Bugzilla, GitHub or openSUSE feature tracker.

So let’s start hacking YaST and if you find any obstacle, contact us, so we can remove it.

Hello,

During the past two weeks we have seen ann influx of data, projects and ideas going around through the community. We have engaged in discussing some greater changes for our distribution and community in the search for higher acceptance and performance of our distribution of choice.

The comments on our mailing lists about the possible changes on the horizon make me think that there is a lot being asked of us. While many that participate in openSUSE might think that it is ok to the let the times roll with us as mere spectators, this request for change has become a wake up call for many of us. We may need to gather our strength, voice our opinion, change the status quo of our contributions. If anything, this proposals have stirred many of our minds and revived the passion that makes openSUSE a personal favorite.

Not only the request about changes and realignment have made this happen, but also events and people that participate of the openSUSE community are currently working on making a very successful event for our conference in Dubrovnik, Croatia next April.

The openSUSE Conference is a long-standing event for our members and enthusiasts to meet and gather around common goals and to promote our distribution. It is also an opportunity to showcase much of what we do on our own for the project.
I have involved my self in this organization, providing a few ideas for design and promotion. I hope that the results of this team's efforts are looked upon with gratitude, for while this is not coding, we still do a lot of our work spending countless hours to make this event a success.

Another important event happening at the moment are the openSUSE Board Elections. This time we have a few aspirants for the position running with what they can offer for the rest of the community. It surely shows a higher level of commitment to want to help the project as a whole to move forward for the future.
I humbly ask that if you have not yet cast your vote for this election, that you do so. Your favorite candidates are still waiting for your support and if you feel that this is elections process does not care for what you have to express, think again.

I say this because of the times that we are facing. Think of this because now the industry is exploring more ways that Linux can be present in a massive way for many more people than ever before. This is what has prompted our discussion about the future of openSUSE. SteamOS, for example has just launched with a promising future based on Linux. Many other distributions are now exploring going mobile or be embedded in smaller everyday devices that we will end up using.

Because of the changes in the industry is that I ask that you vote. Help the board at openSUSE hear your particular voice through votes. Let us know what you would like to see happen with openSUSE. Our candidates will thank you deeply.

Thank you!
Andy (anditosan)

For more information click here!

ATSAMD20-XPRO оценочный набор для новой серии микроконтроллеров Atmel ATSAMD20 на ядре Cortex-M0+. Выглядит следующим образом:
Купить в России можно например тут: Дельта Электроника.

Этот пост о том как подключать эту плату в GNU/Linux. Плата снабжена интерфейсом micro-USB для отладки, реализуемым через отдельную микросхему. Atmel называет это «Embedded Debugger», анонсируется наличие виртуального последовательного интерфейса (прикрученного к основному чипу) и собственно средств отладки и программирования.

При подключении появляется устройство:

Bus 001 Device 010: ID 03eb:2111 Atmel Corp.

[13761.329235] usb 1-1.5: New USB device found, idVendor=03eb, idProduct=2111
[13761.329240] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[13761.329242] usb 1-1.5: Product: EDBG CMSIS-DAP
[13761.329245] usb 1-1.5: Manufacturer: Atmel Corp.
[13761.329247] usb 1-1.5: SerialNumber: ATML1873040200000110
[13761.330868] hid-generic 0003:03EB:2111.000A: hiddev0,hidraw3: USB HID v1.11 Device [Atmel Corp. EDBG CMSIS-DAP] on usb-0000:00:1a.0-1.5/input0
[13761.330964] cdc_acm 1-1.5:1.1: ttyACM0: USB ACM device

Устройство, как видно, отдает нам виртуальный последовательный интерфейс на /dev/ttyACM? и интерфейс CMSIS-DAP на /dev/hid*.

В openocd недавно добавили поддержку этого интерфейса. Пока пакеты openocd с поддержкой CMSIS-DAP доступны здесь:

В пакетах есть небольшой баг, связанный с тем, что udev стремится поставить на /dev/hidraw* группу владельца plugdev, которая по-умолчанию в системе не существует и в пакете не создается. openocd будет искать свой devel-project и потом попадет в Factory.

Запускаем и убеждается, что таки оно работает:

> openocd -f /usr/share/openocd/scripts/board/atmel_samd20_xplained_pro.cfg 
Open On-Chip Debugger 0.8.0-dev-snapshot (2013-12-13-18:45)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'cmsis-dap'
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
adapter speed: 500 kHz
adapter_nsrst_delay: 100
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: FW Version = 01.0F.00DB
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : DAP_SWJ Sequence (reset: 50+ '1' followed by 0)
Info : CMSIS-DAP: Interface ready
Info : clock speed 500 kHz
Info : IDCODE 0x0bc11477
Info : at91samd20j18.cpu: hardware has 4 breakpoints, 2 watchpoints

• Инструкция к openocd

That is a great idea. A kids toy and a barcelona souvenir all in one! Those conform the Barcelona skyline and I just bought one for myself as a souvenir since I am moving from Barcelona at the end of the year.

I think this is a very nice and innovative idea designed in Barcelona by mitoi .

這是一篇流水帳，紀錄這幾天來所遭遇到或被問到的輸入法相關問題

1. 關於 gnome 的設定
之前的文章仍有部份有用，但是關於 gnome-settings-daemon 重設 QT_IMMODULE 和 XMODIFIERS 環境變數的問題，
openSUSE 團隊已經用修改 /etc/X11/xim 的方法來迴避此問題，
詳情請參閱 https://bugzilla.novell.com/show_bug.cgi?id=853063
使用者可以依照 bugzilla 中提供的檔案修改 /etc/X11/xim，
或經由 X11:Utilities 套件庫更新 x11-tools

2. gcin 需要更新才能正常使用
如果您需要某些 Ctrl + * 的快速鍵被吃掉了，請到 gcin-tools 設定(在內定輸入法 ...那頁)
將 Ctrl 輸入標點符號取消

如果您發現 gcin-tools 的 「求助」 無法使用，你又很介意這件事的話，
請安裝 M17N 套件庫的 gcin

3. ibus 需要更新才能正常使用
主要是在 Libreoffice 中 on_the_spot 以及和 libreoffice-kde 衝突的問題。

ibus-table-* 無法使用：如果您要使用 ibus-table-* 的相關輸入法，
卻發現到在輸入法設定選項中沒有這些輸入法，
請參考 https://forum.suse.org.cn/viewtopic.php?f=16&t=1848
可能是在某些系統中未在安裝 ibus ibus-table 套件前安裝 python-curses 套件，
這個套件在執行 /usr/lib/ibus/ibus-engine-table 時所需要的
在我的電腦上安裝 python-curses 後，執行

# /usr/lib/ibus/ibus-engine-table -x

然後重新安裝 ibus 和 ibus-table
(這個步驟只是純粹試誤得到的結果，原因不明)，
打算先在 ibus-table 中先加上 python-curses 的相依，看是否會改善
可惜仍未能解決苦主的問題...

4. fcitx 的圖示有點大
參考 https://forum.suse.org.cn/viewtopic.php?f=16&t=1587
和 https://bugzilla.novell.com/show_bug.cgi?id=851983
Marguerite Su 說她要修了，所以你可以等更新

fcitx 在 gnome-terminal 無法輸入的問題，
是因為輸入法環境變數必須在 dbus 啟動前先宣告，
才能影響 gnome-terminal server，你才能在 gnome-terminal client 使用中文輸入
你可以手動修改 /etc/X11/xim.d/fcitx ，
把 export .... 這些環境變數移到 if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then ... 之前，
像這樣這樣：

if ! type -p fcitx > /dev/null 2>&1 ; then


   echo "fcitx is not installed. please run `sudo zypper in fcitx`."

   return 1

fi



export LC_CTYPE=$LANG

export XMODIFIERS="@im=fcitx"

export GTK_IM_MODULE=fcitx

export GTK3_IM_MODULE=fcitx

export QT_IM_SWITCHER=imsw-multi

export QT_IM_MODULE=fcitx



# Avoid relying on autolaunch to improvise D-Bus sessions for each process

if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then

   eval `dbus-launch --sh-syntax --exit-with-session`

fi



fcitx -d



# success:

return 0

或者您也可以從 M17N 更新 fcitx

fcitx 桌面整合
fcitx 在 gnome 和 kde 都有 kimpanel extension (plasmoid)
和桌面環境整合得不錯，建議使用