# ls -al mkvm* *.patch
-rwxr-xr-x 1 cseader users 2965 Jan  4 21:11 mkvmwmods+patch.sh        
-rwxr-xr-x 1 cseader users 1457 Sep 26 15:47 mkvmwmods.sh
-rw-r--r-- 1 cseader users  650 Jan  4 19:16 vmmon-hostif.patch        
-rw-r--r-- 1 cseader users  650 Jan  4 21:21 vmnet-userif.patch

# ./mkvmwmods+patch.sh                                                

Say we have a robot with a USB connection and command documentation. The only thing missing is knowing how to send a command over USB. Let's learn the basic concepts needed for that.

Installing the Library

We'll use the pyusb Python library. On openSUSE we install it from the main RPM repository:

sudo zypper install python-usb

On other systems we can use the pip tool:

pip install --user pyusb

Navigating USB Concepts

To send a command, we need an Endpoint. To get to the endpoint we need to descend down the hierarchy of

1. Device
2. Configuration
3. Interface
4. Alternate setting
5. Endpoint

First we import the library.

#!/usr/bin/env python2

import usb.core

The device is identified with a vendor:product pair included in lsusb output.

Bus 002 Device 043: ID 0694:0005 Lego Group

VENDOR_LEGO = 0x0694
PRODUCT_EV3 = 5
device = usb.core.find(idVendor=VENDOR_LEGO, idProduct=PRODUCT_EV3)

A Device may have multiple Configurations, and only one can be active at a time. Most devices have only one. Supporting multiple Configurations is reportedly useful for offering more/less features when more/less power is available. EV3 has only one configuration.

configuration = device.get_active_configuration()

A physical Device may have multiple Interfaces active at a time. A typical example is a scanner-printer combo. An Interface may have multiple Alternate Settings. They are kind of like Configurations, but easier to switch. I don't quite understand this, but they say that if you need Isochronous Endpoints (read: audio or video), you must go to a non-primary Alternate Setting. Anyway, EV3 has only one Interface with one Setting.

INTERFACE_EV3 = 0
SETTING_EV3 = 0
interface = configuration[(INTERFACE_EV3, SETTING_EV3)]

An Interface will typically have multiple Endpoints. The Endpoint 0 is reserved for control functions by the USB standard so we need to use Endpoint 1 here.

The standard distinguishes between input and output endpoints, as well as four transfer types, differing in latency and reliability. The nice thing is that the Python library nicely allows to abstract all that away (unlike cough Ruby cough) and we simply say to write to a non-control Endpoint.

ENDPOINT_EV3 = 1
endpoint = interface[ENDPOINT_EV3]

# make the robot beep
command = '\x0F\x00\x01\x00\x80\x00\x00\x94\x01\x81\x02\x82\xE8\x03\x82\xE8\x03'
endpoint.write(command)

Other than Robots?

Robots are great fun but unfortunately they do not come bundled with every computer. Do you know of a device that we could use for demonstration purposes? Everyone has a USB keyboard and mouse but I guess the OS will claim them for input and not let you play.

What Next

• PyUSB
• PyUSB tutorial
• USB in a nutshell goes deeper, and is aimed more at firmware developers for the devices, but still is much shorter than the 650 page USB 2.0 specification
• EV3 documentation at Mindstorms Downloads

The Full Script

I was nominated to run for the openSUSE Board, and finally decided to run ;-)

I use openSUSE since years (actually it was still „SuSE Linux“ with lowercase „u“ back then), started annoying people in bugzilla, err, started betatesting in the 9.2 beta phase. Since then, I reported more than 1200 bugs. Later, OBS ruined my bugzilla statistics by introducing the option to send a SR ;-)

More recently, I helped in fighting the wiki spam, which also means I‘m admin on the english wiki since then, and had some fun[tm] with the current server admin. I‘m one of the founding members of the Heroes team (thanks to Sarah for getting the right people together at oSC16!) Currently, I work on the base server setup (using salt) for our new infrastructure and updating the wiki to an up-to-date MediaWiki version.

You can find me on several mailinglists and on IRC, and of course I still scare people in bugzilla. I‘m also a regular visitor and speaker at the openSUSE Conference, and visit other conferences as time permits.

Besides openSUSE, I work on AppArmor and PostfixAdmin – both upstream and as packager. Also, I‘m admin on several webservers (all running with Leap).

My day job has nothing to do with computers. I produce something you can drink that is named after a software we ship in openSUSE ;-)

Oh, and I collect funny quotes from various mailinglists, IRC, bugzilla etc. that then end up as random signatures under my mails, so be careful what you write ;-)

Issues I can see

• You probably know „DRY“, so – see the next paragraph

Aims/Goals

• speed! We have too many issues hanging around for too long, and that‘s annoying for people who suffer from them. Especially small things should (and can!) be solved quickly.

• clear responsibilities! Part of the speed problem is that it‘s sometimes hard to find out who can fix something, and hunting down people takes time.

• don‘t talk (too much) – do it! Sometimes we need to discuss things, but often just doing them works best. Obviously I can‘t do everything alone, so I want to encourage people to help whereever they can. „I don‘t have knownledge how to do this“ doesn‘t count – for example, updating a wiki page or reporting a bug isn‘t hard ;-) and typically people really start to report bugs once they understand that this gives them the right to complain (quoting Pascal Bleser: „Always file a bug: if it‘s not in Bugzilla, then it‘s not there“)

• longer days! Maybe I should move to Bajor – I heard they have 26 hour days there, which would solve some of my time problems ;-))

Why you should vote for me?

• I tend to kick people to ensure they work faster and fix things. This is your chance to kick me!

• Help me to find out if I can get the thing in the (non-random) signature of this blog post done!

Things I‘ll never do:

• use a stable release on my main computer – Tumbleweed is just too good ;-)

• open a bugreport if fxing it and sending a SR is faster

• be too serious – hey, our motto is „Have a lot of fun...“ ;-)

• drink beer ;-) (sorry, not even openSUSE beer)

Contact Details:

• Mail: anything @cboltz.de - or use my IRC nick @opensuse.org
• IRC: cboltz
• http://blog.cboltz.de (some more posts would be nice, but then you wouldn‘t believe the „don‘t talk – do it!“ ;-)
• https://connect.opensuse.org/pg/profile/cboltz
• https://en.opensuse.org/user:cboltz

I wish all candidates good luck, hope that we‘ll see lots of voters – and wish everybody all the best for 2017!

PS: Non-random signature (yes, I know it's unusual for a blog post to have a signature at all, so this will stay a rare exception) – and while I have serious doubts about the second paragraph, I‘m very sure about the first ;-)

--
If you run for the Board this year and get elected, I can see my sanity would be doomed
But in a good way ;)
[Richard Brown]

250 Ok: queued as F117E148DE4

poll myacc via shellservername.tld with proto imap:
    plugin "ssh -C %h bin/imapd" auth ssh;
    user seife there is seife here options keep stripcr
    folders Mail/inbox Mail/s3e-spam Mail/thirdfolder
    mda "/usr/bin/procmail -f %F -d %T"

fetchmail && mailsync myacc

:0fw: spamassassin.lock
* < 1048576
| $HOME/perl/bin/spamassassin

kiwi has long been the one standard way of building images in openSUSE, but even though there exist extensive writings on how to use it, for many it is still an arcane thing better left to the Great Magicians.

Thus, I started to use a simpler alternative image building method, named altimagebuild when I built our first working Raspberry Pi images in 2013 and now I re-used that to build x86_64 VM images at
https://build.opensuse.org/package/show/home:bmwiedemann/altimagebuild
after I found out that it even works in OBS, including publishing the result to our mirror infrastructure.
It is still in rpm format because of how it is produced, so you have to use unrpm to get to the image file.

This method uses 3 parts.

• a .spec file that lists packages to be pulled into the image
• a mkrootfs.sh that converts the build system into the future root filesystem you want
• a mkimage.sh that converts the rootfs into a filesystem image

The good thing about it is that you do not need specialized external tools, because everything is hard-coded in the scripts.
And the bad thing about it is that everything is hard-coded in the scripts, so it is hard to share general improvements over a wider range of images.

In the current version, it builds cloud-enabled partitionless images (which is nice for VMs because you can just use resize2fs to get a larger filesystem and if you later want to access your VM’s data from outside, you simply use mount -o loop)
But it can build anything you want.

To make your own build, do osc checkout home:bmwiedemann/altimagebuild && cd $_ && osc build openSUSE_Leap_42.2

So what images would you want to build?

adb shell \ 

  dd if=/dev/zero \

  of=/dev/block/platform/msm_sdcc.1/by-name/misc