So you got a bunch of different openSUSE 12.2 live isos downloaded, to test them on a real machine you have to either burn them to CD/DVD or create live USB stick. Creating CD/DVD is a total waste after booting it once or twice. Creating bootable USB stick is a better thing to do, however openSUSE Hybrid iso creates USB stick that is not usable for any other purpose and the remaining space is locked till you make another partition, and even then the partition is not available on windows(tm).
openSUSE Conference 2012 – How to build RPMs
September 4th, 2012 by Nelson MarquesDon’t forget to bring your friends!
Editing KIWI configurations with Emacs
August 31st, 2012 by Togan MuftuogluI recently decided to do all my work in emacs and even though the learning speed is a bit slow, I thought I would share what I discoverd regarding editing the KIWI config files. Kiwi has the schema file for the elements and their attributes but unfortunately by default Emacs is unaware of it’s schema location. So first create a schema location file as below and save it.
<locatingRules xmlns="http://thaiopensource.com/ns/locating-rules/1.0">
<transformURI fromPattern="*.xml" toPattern="*.rnc"/>
<uri pattern=”*.kiwi” typeId=”KIWI”/>
<typeId id=”KIWI” uri=”/usr/share/kiwi/modules/KIWISchema.rnc”/>
</locatingRules>
I saved it as $HOME/.emacs.d/data/myschemas.xml. Now add this to your Emac’s init file for autoloading the nxml mode for kiwi files in addition to the xml files
(setq auto-mode-alist
(cons '("\\.\\(xml\\|kiwi\\|xsl\\|rng\\|xhtml\\)\\'" . nxml-mode)
auto-mode-alist))
and add this code for nxml mode to locate the kiwi schema file when you edit a kiwi config file
(eval-after-load 'rng-loc
'(add-to-list 'rng-schema-locating-files (concat user-emacs-directory "data/myschemas.xml")))
Now have fun with Emacs, Kiwi and your openSUSE
Testing LTSP on openSUSE 12.2
August 23rd, 2012 by Jigish Gohilosc2: syntax update
August 16th, 2012 by Marcus HüweHi,
as I already I wrote in an earlier post the last week I worked on implementing osc2’s “request”
command. In order to create a new submit request the user has to run
osc request create --submit api://src_project/src_package api://tgt_project
What’s still needed is a way to specify a revision of the src_package. It isn’t possible
to introduce a “–revision ” option because it’s possible to specify multiple submit
actions for a request (so we can’t distinguish to which –submit action a revision
belongs to).
Finally I implemented darix’ cool idea: simply use a svn-like syntax:
osc request create --submit api://src_project/src_package@rev api://tgt_project
Marcus
[gsoc] osc2 client – summary of week 12
August 15th, 2012 by Marcus HüweHi,
here’s a small summary of the 12th (coding) week. The last week I continued
the work on the new user interface. As a result the “request” command is more
or less implemented. Yesterday I pushed the current code and it’s also possible
to play around with it:
- checkout the code [1]
- cd osc2/osc/cli
- export PYTHONPATH=/path/to/osc2
- python cli.py -h (for more information)
Example:
In order to list a request it is sufficient to run
“python cli.py request api://your_project” (Note: all https requests are
_insecure_ – so far the certificate etc. is not checked).
Some implementation details:
In my last mail/post I described how a new (sub)command can be specified
so I’ll leave out the details here.
In the following I’ll shortly explain how the arguments specified by the
user at the commandline are passed to a function (which does the actual
work – like listing the requests).
class RequestList(CommandDescription, Request):
"""
...
"""
cmd = 'list'
args = 'api://project?/package?'
opt_user = Option('U', 'user', 'list only requests for USER')
func = call(request.list)
As we can see the project and package parameters are optional. After
the parsing process a so called “info” object is returned which encapsulates
the specified arguments. Assume the user runs “request list api://test_prj”
then the info object has the following attributes:
info.apiurl = the default apiurl
info.project = 'test_prj'
info.package = None
The question is how can we pass this data to the request.list function?
A simple (and naive) approach would be to simply pass the “info” object
to the request.list function that is “list” has the following signature
“def list(info)”. As a consequence inside the method we always have to
use “info.project”, “info.package” etc. which is a bit awkward – at least
for parameters which are quite frequently used in the method definition.
So it would be nice if there’s a way to pass frequently used parameters
directly to the method (that is they’re declared as formal parameters
in the method definition) and infrequently used parameters can still be
accessed via the info object. Exactly like this it is currently
implementend in osc2.
So the following signatures would be correct for our example:
def list(project, package, info)
def list(project, package, user)
def list(project, package, user, info)
def list(project, info)
def list(info, project)
def list(project) # using the info object is not mandatory
def list() # quite useless...
...
Invalid signatures:
def list(prj, pkg, info)
def list(foo, info)
...
So it is up to the developer how to define the signature of the
request.list function – it is not completely dictated by osc:)
Marcus
[gsoc] osc2 client – summary of week 11
August 7th, 2012 by Marcus HüweHi,
here’s a small summary of the 11th (coding) week. Last week I worked on
implementing the new commandline interface. While doing so I faced several
“issues”:
-
How to combine argparse and our oscargs url-like syntax?
Basically we have to run our oscargs parser on the result which is
returned by argparse.ArgumentParser’s parse_args method. The problem is
that both parsers have a different “syntax” that is using a naive approach
will lead to some redundancies (we specify the ui twice: one time for
argparse and one time for oscargs). In order to avoid this we need some
“interface” to which the oscargs syntax is passed and which configures
the argparse parser accordingly. -
How to support custom commands?
We also have to provide an “easy” way to specify custom commands.
Additionally it might be handy if existing commands can be enhanced
(either by adding additional options etc. or by adding a new subcommand
etc.). The best would be if the user simply drop his/her plugins in a
specific directory and osc will scan this directory and use the new
plugins/commands. -
Specifying the ui programmatically is somehow confusing/cluttered. It would
be much better if the ui can be specified in a more “declarative” way
without the syntactic “overhead” (well that’s a bit exaggerated) which
is needed to configure the parser. Additionally it would be nice to have
a convenient way to specify a multi line description for a command
(hardcoding the str into the source makes the code “harder” to read).
Finally I ended up with a small DSL which can be used to specify the
ui in a “declarative” way (the initial idea + syntax is taken from the
django framework (see [1])).
Example:
Assume we want to implement a request command which consists (for the
sake of simplicity) of 2 subcommands “list” and “accept”. This can be
specified like the following:
# file: osc/cli/request/ui.py
class Request(CommandDescription, OscCommand):
"""Show and modify requests."""
cmd = 'request'
class RequestList(CommandDescription, Request):
"""List requests.
By default open requests for a specific project or package will be
listed.
Examples:
osc request list api://
osc request list api://project
osc request list api://project/package
"""
cmd = 'list'
args = 'api://project?/package?'
opt_user = Option('U', 'user', 'list only requests for USER')
opt_group = Option('G', 'group', 'list only requests for GROUP')
opt_state = Option('s', 'state', 'list only requests with state STATE',
choices=['new', 'review', 'accepted', 'revoked',
'declined', 'superseded'], action='append')
func = request_list
class RequestAccept(CommandDescription, Request):
"""Accept a specific request.
...
"""
cmd = 'accept'
args = 'api://reqid'
func = request_accept
In order to add the request command it is sufficient to add an
import osc.cli.request.ui
statement to the main cli module. This produces the following output:
marcus@linux:~/osc2/osc/cli> python cli.py request -h
usage: cli.py request [-h] {list,accept} ...
Show and modify requests.
positional arguments:
{list,accept}
list List requests.
accept Accept a specific request.
optional arguments:
-h, --help show this help message and exit
marcus@linux:~/osc2/osc/cli>
and
marcus@linux:~/osc2/osc/cli> python cli.py request list -h
usage: cli.py request list [-h]
[-s {new,review,accepted,revoked,declined,superseded}]
[-G GROUP] [-U USER]
api://project?/package?
List requests.
By default open requests for a specific project or package will be
listed.
Examples:
osc request list api://
osc request list api://project
osc request list api://project/package
positional arguments:
api://project?/package?
optional arguments:
-h, --help show this help message and exit
-s {new,review,accepted,revoked,declined,superseded}, --state {new,review,accepted,revoked,declined,superseded}
list only requests with state STATE
-G GROUP, --group GROUP
list only requests for GROUP
-U USER, --user USER list only requests for USER
marcus@linux:~/osc2/osc/cli>
How does it work?
First of all each class which defines a command or subcommand has to inherit
from class “CommandDescription”. If a subcommand is to be defined it also
has to inherit from the “parent” command (that is in our example “RequestList”
and “RequestAccept” inherit from class “Request” (which in turn inherits from
class “OscCommand” (from this class all toplevel commands have to inherit))).
In short: with the help of the inheritance hierarchy it is possible to define
a command <- subcommand hierarchy.
Note: actually the classes "RequestList" and "RequestAccept" only inherit
from "CommandDescription". The "parent" command base class is only needed
for a "marking" purpose (it is filtered out with the help of a metaclass
when the concrete class is "constructed" – I'll leave out the details for
now and may write a dedicated blogpost about it).
Now the remaining task is to define and implement the commands (note: we will
definitely not finish the project on the "suggested pencils down" date and
use the week until the "firm pencils down" date for coding…).
Marcus
[1] https://docs.djangoproject.com/en/1.4/topics/db/models
Here’s a small example how to modify an existing command:
# plugins/myrequestaccept.py
from osc.cli.description import Option
import osc.cli.request.ui
class MyRequestAccept(osc.cli.request.ui.RequestAccept):
# add a new option
opt_foo = Option('f', 'foo', help='foo option')
This leads to
marcus@linux:~/osc2/osc/cli> python cli.py request accept -h usage: cli.py request accept [-h] [-f FOO] api://reqid positional arguments: api://reqid optional arguments: -h, --help show this help message and exit -f FOO, --foo FOO foo option marcus@linux:~/osc2/osc/cli>
Optimizing a boot time, aka 2 second boot (part 2)
July 31st, 2012 by Michal VyskocilChanges for upcoming openSUSE
As a result of my previous 2 second post I have submitted few changes to openSUSE to be included in a next release.
purge-kernels.servicepatch has been accepted by our brave mkinitrd package maintainer- requested a split of mkinitrd setup script from
splashypackage, so users can freely remove the initrd integration without breaking resume et al - I opened feature 313851 to make NM the default network tool at least for laptops, because this expects a little more changes than add a package to laptop pattern
Run NetworkManager on demand
That is very uncommon user-case for *nix machines, but makes a perfect sense for consumer devices. My Amazon Kindle or today’s smartphone or tables works in the same way – device starts without a network connection and there’s a button or magic tap enabling it. On my laptop I already have such button – it is the Fn+F2 with a antenna symbol printed. This is the rfkill button turns my wlan card on and off.
So what I want is once I turn wifi on, NetworkManager should start and work. With systemd and it’s udev integration this is so simple, that I was not able to find a good howto for it. So here we are with a small howto for udev/systemd newbiew like me.
We need to know a sysfs name of wlan0 – simple find /sys/ -name 'wlan0' will say us all we need. Then udevadm info will tell you more
udevadm info --path=/sys/class/net/wlan0 --attribute-walk | less
...
looking at device '/devices/pci0000:00/0000:00:1c.2/0000:01:00.0/net/wlan0':
KERNEL=="wlan0"
SUBSYSTEM=="net"
DRIVER==""
That is all you need to know how to write a rule will match for all wlan cards.
# cat /etc/udev/rules.d/95-start-nm-on-wlan.rules
SUBSYSTEM=="net", NAME=="wlan?", TAG+="systemd", ACTION=="add", ENV{SYSTEMD_WANTS}="NetworkManager.service"
To explain it – SUBSYSTEM and NAME are taken from previous output and means that following rule matches for all devices in net subsystem named wlan-something. We should append tag systemd, because systemd sees tagged devices only. The ACTION=="add" says the rule will be evaluated only in case device will be added and the last part says to systemd which service should be started.
In case you will want to stop NM, the
SUBSYSTEM=="net", NAME=="wlan?", TAG+="systemd", ACTION=="remove", ENV{SYSTEMD_WANTS}="NetworkManager-stop.service"
# cat /etc/systemd/system/NetworkManager-stop.service [Unit] Description=Stops NetworkManager Conflicts=NetworkManager.service [Service] ExecStart=/bin/true
WLAN cards
For onboard wlan cards following thing won’t work as they appear in a tree from early phase. Unfortunately I’ve found only one way how kernel exports the fact cable is plugged in and that’s changed /sys/class/net/eth0/carrier. But inotify does not work with a quantum-like fs like sysfs is. The trouble is values appears in time of read, but inotify react on writes, which never appear.
How much the removal of getting IP address from boot saved the time?
# systemd-analyze Startup finished in 2719ms (kernel) + 4333ms (userspace) = 7052ms
which is about half of second.
Too much mounts in a parallel
The one thing surprised me was a long time until trivial mounts like debugfs were finished. The reason is that systemd (at least 44, recent version use generator+ .mount units) behaves differently to .mount units and things in /etc/fstab. In the first case, it executes the /bin/mount. Which means a lot of ld, stats, mmap, and the big delay of the system start.
So move things to fstab, or disable the systemd mount unit (I did that for sys-kernel-debug.mount and sys-kernel-security.mount). I already masked the remount-rootfs.mount, which calls /bin/mount -o remount /< only. That seems to me like a barrier for other mount units – iow this will be done as a last one. But who cares with a fast boot we have?
Way more changes
Then the systemd-modules-load.service delay a boot as it block sysinit.service, when basic boot ends. I read strace carefully, but it only load microcode_ctl module, but that took few seconds to be done. Thus I gently masked it.
The next change is backport from Factory package – this reduce the delay caused by all those tty devices to appear. Fortunately this will be part of next openSUSE as it is an upstream patch.
And as a last thing I wrote a simple xdm.service, instead of a big xdm init script. It will definitely need more love, but for me just works 🙂
cat /etc/systemd/system/xdm.service [Unit] Description=X Display Manager After=dbus.socket [Service] Type=simple ExecStart=/usr/bin/xdm -nodaemon Restart=always [Install] WantedBy=graphical.target
Voilà!
#systemd-analyze Startup finished in 2698ms (kernel) + 1513ms (userspace) = 4212ms
Using dracut
Because our brave systemd maintainer, Fréderic Crozat, chooses dracut as his hackweek project, I was curious if dracut can make some gain for me. I installed dracut and rebuilt and installed hardlink from his branches and try to investigate it. I would say the biggest advantage over mkinitrd is that dracut is configurable from command line. This is in a contrast with mkinitrd, where you have mostly no way how to exclude something – at least I did not find anything.
As Fréderic also pointed me, there is a --hostonly switch, which include only things needed for boot of current machine only. For instance dracut module kernel-modules will pull only things needed to mount rootfs (and if usrmount is included, then it will add things for /usr as well). Then I have excluded at least everything I can to have a working initramfs via -o, --nofsck and --strip. And that is the resulting time
# systemd-analyze Startup finished in 726ms (kernel) + 1609ms (initramfs) + 1581ms (userspace) = 3917ms
Disabling way more things
As we are now versed in a looking at diagrams, there are still few ms we can save, even those changes are not sane ;-). The first one follows the NetworkManager.service – now sshd.service delays the boot a lot, because it systemd-update-utmp-level.service waits on it’s finish. So let’s start it on demand
# cat /etc/udev/rules.d/95-start-nm-on-wlan.rules
SUBSYSTEM=="net", NAME=="wlan?", TAG+="systemd", ACTION=="add", ENV{SYSTEMD_WANTS}="NetworkManager.service sshd.service"
and disable it. Then mask all few remaining things – systemd-login.service, systemd-remount-api-vfs.service, systemd-user-session.service and rc-local.service. But only in case you are pretty sure what you are doing, because you might loose an important functionality, especially if you use a DE expected such things.
And that is the last time I will post
# systemd-analyze Startup finished in 726ms (kernel) + 1502ms (initramfs) + 1112ms (userspace) = 3341ms
With a kernel with SATA+ext support builtin, I would reach the two second goal – 1839ms. Of course on a system, which functionality was extremely cut down, but my goal was to boot as fast as possible. In reality, hunting of ms does not makes your feeling better a lot (until you will type systemd-analyze, of course)
This is the diagram of the really fast boot
AMD/ATI Catalyst fglrx & fglrx legacy news
July 31st, 2012 by Bruno FriedmannAMD/ATI Catalyst fglrx & fglrx legacy news
Explanations of Hell
During June, with the version 12.6 (8.980) AMD decide to drop support for legacy radeon chipset from its main fglrx package and drop the time based release cycle.
So now if you are the owner of radeon hd2xxx to hd4xxx chipset family you will have to use the -legacy- version of fglrx, and
consequently if you have a radeon hd5xxx or above, you have to use the standard fglrx driver.
Then start the hell. After getting the new developed script from Sebastian Siebert, I will be able to offer the two versions. Unfortunately the two drivers can’t coexist in the same repository, the legacy drivers wants to install in place of normal one. This imply another limitation, you can’t have two graphics cards with differents generation at the same time.
So I decide to clarify (is that possible? :-)) the mess, and split the drivers in two distinct repositories. I use that excuse to also change the ati (deprecated brand name) and use new names: amd-fglx and amd-fglrx-legacy.
Don’t worry about your exiting installation, I will provide a symlink during the next 6 months at least for the old repositories. But read carefully the rest of the story, and apply any changes needed to your installation to be sure to continue to safely use the right driver.
I also decided to remove any version below 12.4 (8.961) in all repositories, except for openSUSE 11.2.
I need your help to spread those informations around the internet, and be sure that every user that need this driver know where and how to use it right. Tweet FbLike G+ forums, mailing list, private blogs Go now!
Release note about 12.6 and legacy 8.97.100
Both version can handle kernel 3.4 and 3.5
Sebastian Siebert warn us about the state of legacy
AMD catalyst control center and fgl_glxgears
These cards with the unofficial support of openSUSE 12.2 can run in the ideal case, just under 2 more years. However, one must keep in mind that the legacy driver is looked after, while AMD continues and eliminates errors found, but will not add new features. This can mean, among other things, that the next version of GNOME or KDE will not run with its 3D effects, especially when used with a desktop or Tumbleweed extra repository.
If you have any comments, be do on his blog. Don’t be shy, you can leave there the result of test in english too 😀
or ask in forums, irc and ping freespacer.
See below what to do in case of troubles.
12.2 Factory rpms are presently available, use at your own risk, and report bugs in forums and Sebastian blogs.
Anyways, factory and 12.2 should keep their effort on debuging and testing widely the free radeon driver.
[gsoc] osc2 client – summary of week 10
July 30th, 2012 by Marcus HüweHi,
here’s a small summary of the 10th (coding) week. Last week I worked
mostly on the new fetcher code which I finally pushed into the git
repo. Apart from this I did some refactoring here and there.
The todo for this and the next week is to start with the new osc
user interface (that is the client code). As I already wrote in the
proposal the new osc client will be based on python’s argparse module
and the Jinja2 template engine.
Marcus
Advertisement
-
Lizards
Adrian Schröter (12)
Agustin Chavarria (6)
Alessandro de Oliveira Faria (13)
Alex Barrios (12)
Alexander Naumov (10)
Alexander Orlovskyy (3)
Alin M Elena (5)
Andrea Florio (27)
Andreas Jaeger (70)
Andreas Stieger (12)
Andrew Wafaa (31)
Arvin Schnell (9)
Atri Bhattacharya (3)
Bernhard Wiedemann (31)
Bonnie Kurniawan (1)
Bruno Friedmann (98)
Calumma Brevicorne (29)
Carl Fletcher (1)
Christopher Hobbs (17)
Ciaran Farrell (3)
Stephan Kulow (17)
craig gardner (2)
Stephan Barth (2)
Thomas Schmidt (2)
Dinar Valeev (1)
Dirk Mueller (2)
Dmitry Serpokryl (7)
Efstathios Iosifidis (21)
Fabio Mucciante (5)
Federico Lucifredi (9)
Greg Freemyer (1)
Holger Sickenberg (2)
Hubert Mantel (1)
Ilya Chernykh (5)
Ismail Donmez (1)
J. Daniel Schmidt (2)
James Tremblay (7)
Jan Blunck (4)
Jan Loeser (3)
Jan Madsen (1)
Jan-Christoph Bornschlegel (3)
Jan-Simon Möller (20)
Javier Llorente (12)
Jigish Gohil (85)
Jiri Srain (1)
Jiří Suchomel (3)
Johan Kotze (5)
José Oramas M. (6)
Josef Reidinger (16)
Juergen Weigert (1)
Julio Vannini (9)
Dinar Valeev (5)
Kevin "Yeaux" Dupuy (11)
Klaas Freitag (55)
Lars Vogdt (11)
Ludwig Nussel (13)
M. Edwin Zakaria (4)
Marcus Hüwe (39)
Marcus Meissner (2)
Marcus Moeller (3)
Marcus Schaefer (4)
Martin Lasarsch (8)
Martin Mohring (11)
Masim "Vavai" Sugianto (20)
Michael Andres (1)
Michael Löffler (7)
Michal Marek (7)
Michal Vyskocil (12)
Miguel Angel Barajas Hernandez (2)
P Linnell (2)
Nelson Marques (55)
Nenad Latinović (1)
Nikanth Karthikesan (2)
Przemyslaw Bojczuk (1)
Peter Pöml (4)
Petr Gajdos (2)
Petr Mladek (60)
Petr Uzel (5)
Ray Wang (1)
Raymond Wooninck (1)
Ricardo Chung (7)
Ricardo Varas Santana (7)
Richard Bos (11)
Robert Schweikert (16)
Rossana Motta (1)
Rupert Horstkötter (10)
Sascha Manns (66)
saydul akram (3)
Sebastian Siebert (6)
Shawn Dunn (2)
Stanislav Visnovsky (7)
Stefan Haas (1)
Stefan Hundhammer (5)
Stefan Schubert (7)
Steffen Winterfeldt (8)
Suresh Jayaraman (3)
Susanne Oberhauser (3)
Thomas Göttlicher (6)
Thomas Schraitle (26)
Togan Muftuoglu (3)
Tuukka Pasanen (36)
Will Stephenson (22)
YaST Team (90)