EvolvisForge

Jenkins und die APT-Repositories Ⅱ

As reported earlier we’ve got some kind of Jenkins/APT integration, with automatically generating as many repositories as a job desires.

News are that the builds host has moved, so the URIs to the repositories have changed. The new syntax is https://ci-something.lan.tarent.de/ for the Jenkins ⇒ “deb https://ci-something-debs.lan.tarent.de/jobname/ distribution suite …” and currently only usable in the company-internal network.

We’ve also got some more magic mksh code to automate the entire process – check the code out from SCM (required, as Jenkins’ svn checkouts are broken), build a Debian source package, NEW! ask cowbuilder to compile it in a clean chroot environment, and call mvndput.sh for APT repository publication. Sample projects are ci-evolvis/virtualscreen (git) and ci-dev/portal-setup (svn). Talk to me if you have any questions.

This allows for a one-line “run a shell command” build step!

Everybody else is, of course, invited to take and re-use our code, and maybe even improve upon it and submit that back. It’s all Open Source, after all.

tl;dr Jenkins Jobs now have integration with cowbuilder. There’s a new script to automate the whole build pipeline. The APT repositories have moved with the recent move.

Evolvis-Wikis und die Suchmaschine

(Dieses Posting wurde ursprünglich im internen Blog veröffentlicht, ist jetzt jedoch hierhin umgezogen. Firmeninterne Information wurde gekürzt, ist aber für Mitarbeiter im Mailinglistenarchiv ersichtlich.)

Neues aus der Adminstube (und vom Evolvis-Team) für unsere Projektmanager:

Im Rahmen der tarent-Suche werden die Wikis indiziert; dies ist natürlich nicht immer gewünscht, auch wenn die Suche nur Mitarbeitern zugänglich ist. Darum gibt es jetzt eine Möglichkeit, pro Projekt das Wiki öffentlich oder privat zu setzen. Im Moment werden nur die Wikis auf evolvis.org und dev.tarent.de indiziert, ab dem 20.06.2011 aber auch auf den Kundenevolvinēs – daher stellt eure Wikis bitte ein!

Wir werden jedes Wochenende den Suchindex leeren und neu aufbauen, das heißt, zukünftige Änderungen von öffentlich auf privat werden erst in der Folgewoche aktiv!

Die Einstellung betrifft den XML-Export, die tarent-Suche und die Sichtbarkeit für nicht eingeloggte Besucher. Wenn ihr die Einsicht eines Wiki vor Mitarbeitern, die keine Projektmitglieder sind, verstecken wollt, müssen wir weiterhin die Rechtefreigaben von Hand anpassen.

Die aktuelle Konfiguration ist wie folgt: [… gekürzt …]

Jenkins und die APT-Repositories

(Dieses Posting wurde ursprünglich im internen Blog veröffentlicht, ist jedoch hierhin umgezogen. Es sind keine sensitiven Informationen enthalten, allerdings können die Links nur im Firmennetz angesteuert werden.)

Neues aus der Adminstube (und vom Evolvis-Team) für unsere Entwickler, die wir, nachdem wir die Projektmanager schon bedient haben, auch nicht zu kurz kommen lassen wollen:

Wenn ihr einen Jenkins-Job habt, der Debian-Pakete (oder für Derivate) erstellt, könnt ihr ab sofort (mindestens) ein Repository pro Job haben, in dem ihr die Pakete „veröffentlichen“ könnt. Diese Repositories werden automatisch signiert, und durch tarent-keyring werden die Signaturen bereits seit Dienstag verteilt, sodaß auch SecureAPT funktioniert.

Im folgenden wird die Arbeitsweise am Beispiel von Saschas WIP-Portalinstaller erklärt.

Ausgangspunkt ist ein Jenkins-Job, in diesem Fall auf dem test-hudson, hier mit dem Namen „portal-setup“, der unter „Build“ den Punkt „Execute shell“ aktiv hat. Hier wird durch diverse Kommandos ein Debian-Paket (Source und Binary) gebaut, das wirklich wichtige hierbei ist folgender Ausschnitt:

cd portal-setup-$pv
dpkg-buildpackage -rfakeroot -us -uc
cd ..
#rm -rf portal-setup-$pv

Der Befehl dpkg-buildpackage übernimmt das Bauen und schmeißt die erstellten Pakete (Source *.dsc und Binaries *.deb) und, ganz wichtig, die *.changes-Datei, ins Elternverzeichnis (daher die cd-Aufrufe). Nun möchte Sascha, daß diese Pakete einfach von Kollegen getestet werden, und ändert daher den Codeschnipsel so ab:

cd portal-setup-$pv
dpkg-buildpackage -rfakeroot -us -uc
cd ..
#rm -rf portal-setup-$uv portal-setup-$pv

/opt/mvn-debs/mvndput.sh portal-setup squeeze main *.changes

Im ersten Teil bleibt alles beim alten, aber ein neuer Befehl ist am Schluß hinzugekommen. Was macht der?

Nun, /opt/mvn-debs/mvndput.sh ist die Magie, die unterhalb des Pfades /opt/mvn-debs ein Debian-Repository mit dem Jobnamen portal-setup anlegt. Wir publizieren Pakete in die „dist“ squeeze, und darin in die „suite“ main. Das ist hier lediglich eine Konvention; normalerweise heißt die dist so wie die Debian-Version (sarge, dapper, etch, hardy, lenny, squeeze, …), für die das Paket gedacht ist, und die suite ist eine Unterkategorie – also zum Beispiel main/contrib/non-free oder main/restricted/universe/multiverse oder wtf/tarent/evolvis (in unserem Adminrepo). Man kann die aber auch frei Schnauze nennen (ich hab zum Beispiel im m68k-Repo eine dist namens „cross“, unterhalb derer eine Cross-Toolchain liegt).

Das letzte Argument ist *.changes, was die Shell für uns expandiert: alle Dateien, die auf „.changes“ enden, werden dort (ASCIIbetisch sortiert) der Reihe nach aufgelistet.

Das Skript prüft nun zunächst die Namen und Dateien auf Plausibilität (es sind schließlich immer nur gewisse Zeichen erlaubt) und schiebt dann vermittels dput ein Release (also eine *.changes + alle drin enthaltenen *.deb + dazugehörige *.dsc, *.diff.gz/*.debian.tgz, *.orig.tar.gz, oder *.tar.gz bei native packages) ins APT-Repository und läßt danach den Index regenerieren und PGP-signieren. dput ist ein schlaues Tool, es schreibt nämlich nach getaner Arbeit eine *.upload-Datei, in welcher dieser Fakt verzeichnet wird, sodaß Pakete auch wenn man den workspace nicht jedes Mal wegschmeißt nur einmalig hochgeladen werden. (Es existiert allerdings hier kein Schutz davor, den workspace zu leeren und ein Paket mit derselben Version aber anderem Inhalt ein zweites Mal hochzuladen. Nur die Systeme, die das installieren wollen, mögen einen dann ggf. nicht mehr so gerne.)

mvndput.sh ruft nun also mvndebri.sh auf, was allerdings mehr macht als nur das Äquivalent von Debians dak oder CentOS’ createrepo. Es erstellt nämlich auch einen Index.

http://test-hudson-debs.bonn.tarent.de/portal-setup/debidx.htm heißt der Gute, und ist eine Auflistung aller Pakete nach dist, suite, Source und Binary im Repository. Weiterhin steht oben nochmal, um welches Repository es sich handelt, und welche dists und suites verfügbar sind. Der Name bildet sich aus „http://“ + Jenkins-Systemname + „-debs.bonn.tarent.de/“ + Jenkins-Jobname + „/debidx.htm“ – wenn man den Dateinamen wegläßt kann man das auch direkt als Verzeichnisstruktur anschauen.

Der Clou: die passende sources.list-Zeile steht auch schon da! (Allerdings muß man die suiten ggf. auf die, die wirklich benötigt werden, reduzieren.)

deb http://test-hudson-debs.bonn.tarent.de/portal-setup squeeze main

Das funktioniert auf allen acht Jenkins-Systemen, allerdings natürlich nur aus dem tarent-Netz heraus – dafür ohne https oder aufwendige Authentifizierung. Einfach so.

Bitte achtet darauf, den Namen des Jenkins-Jobs als erstes Argument zu mvndput.sh zu verwenden, ggf. gefolgt von einer Kennzeichnung, falls ihr mehr als ein Repo pro Job braucht (warum, weiß ich nicht, aber es geht). Da alles als maven-User läuft findet keine Abgrenzung statt.

Wenn ihr Pakete aufräumen möchtet, so loggt euch (als User maven) auf dem entsprechenden Jenkins ein und schaut auf der Verzeichnisebene nach; einen direkten Link gibt’s auch, wenn man das [dir] im tabellarischen Index anklickt, zum Beispiel http://test-hudson-debs.bonn.tarent.de/portal-setup/dists/squeeze/main/Pkgs/portal-setup/, was im Dateisystem dem Verzeichnis /opt/mvn-debs/portal-setup/dists/squeeze/main/Pkgs/portal-setup/ entspricht.

Nachdem ihr händisch Änderungen dort vorgenommen habt, müßt ihr natürlich den Index neu generieren lassen, das geht dann so:

mksh /opt/mvn-debs/mvndebri.sh /opt/mvn-debs portal-setup squeeze

Wenn ihr nicht nur eine dist angefaßt habt, könnt ihr die auch auflisten:

mksh /opt/mvn-debs/mvndebri.sh /opt/mvn-debs portal-setup hardy squeeze

Oder einfach weglassen, dann macht er alle:

mksh /opt/mvn-debs/mvndebri.sh /opt/mvn-debs portal-setup

Das ist dann auch der Unterschied zwischen dists und suites: letztere teilen sich ein Release-File, erstere nicht, nur den XHTML-Index.

So, ich hoffe, ihr findet das so nützlich wie Sascha und so arbeits- und zeitersparend wie ich ☺

PS: Der Code ist mittlerweile auch publiziert. Wer solch ein Szenario noch woanders aufsetzen möchte ist uns herzlich willkommen.

35, a.k.a. it’s time for a blog posting again ☺

Evolvis 4.8.35 has been released this week. This is an amazing upgrade within the 4.8 series of development, to bridge the time gap until such time as the 5.1 series can be used.

As announced earlier, our APT Repository contains packages targetting Debian Lenny (amd64, i386), including side packages and backports needed for a standard EvolvisForge installation, add one of these lines to your /etc/apt/sources.list to use it. These packages might work on Debian squeeze, maybe even *buntu, but will probably have issues with multiarch on Debian unstable.

First the big caveat: support for old-style (Jutta Horstmann) external Wiki instances has been removed, since we migrated all Evolvis installations to use gforge-plugin-mediawiki a while ago already.

Now the big news: bug trackers (old and new) contain several predefined search queries useful for Software Engineering and Quality Assurance. There’s a new standard tracker type called “Funktionsreferenz” (functionality specification) on every newly created project. The Extratabs plugin, backported from 5.1 then enhanced, allows adding arbitrary tabs as link or IFRAME (embedding content) to any project. And the DatePicker component allows easily entering a date, or a date plus time-of-day, using an ECMAscript pop-up while also accepting simple strings, for instance from Lynx users. The format used for displaying dates can be configured in “My Account” between d.m.y, y-m-d and m/d/y; the software accepts all three formats, always, nevertheless. Furthermore, the ECMAscript DatePicker widget is available in a number of languages for all three formats – English, German (Deutsch), Spanish (Español), French (Français), Italian (Italiano), Dutch (Nederlands), Polish (Polsku), Portuguese (Portugues), Romanian (Românesc), Bulgarian (Български), Russian (Русский), Hungarian (Magyar), Norwegian (but I’m not sure if it’s Nynorsk or Bokmål).

Now the small improvements: a robots.txt file is present by default, allowing wget and asking all crawlers to slow down; system administrators may configure it (in gforge.conf) to switch to one disallowing search engine spiders. Newly created Tasks have a default duration of two weeks (standard Scrum timeframe), not one week. /usr/share/gforge/bin/scm-newsubrepo.php supports easily adding new git repositories to a project already using them.

And finally, the most important / visible bug fixes: Sorting tables in Tasks works again, and the search drop-down boxen in Tracker are now sorted. The modify task/tracker forms have more “Submit” buttons and have been slightly rearranged to improve User Experience. “Copy+Close” a task works again. Some links, labels and translations (German only) have been corrected. Project members are now added to the default mailing lists correctly, i.e. to the -discuss group always, to the -commits group if they have SCM Write permissions. Custom Tracker fields of type Checkbox no longer have the “100 None” option. Tasks do not show up on “My Page” several times now, once is enough ;-)

Last but not least, a look at the future: we’re working on our Jenkins Plugin, which we might provide for Evolvis 4.8 if it’s functioning quickly enough. We’re also working on getting Evolvis 5.1 into a usable shape, and porting all Evolvis 4.8 functionality to it. Much has been integrated in the recently released FusionForge 5.1 already. A new functionality to mark bugs as duplicate, followup or having a simple, nontyped relationship to another tracker item is being worked on, as are improvements (new items, better look’n’feel) to the “My Page”. And that’s just the big news.

A German language User’s Guide / Handbook is also being worked on. It’s a Wiki, so feel free to help ☺ (although the licence is CC-BY-NC-SA and thus non-free, sorry for that, but the software itself is GPLv2+). And as usual, there’s a full changelog and you can look at the svn revision log.

We wish you an enjoyable software development and lifecycle management, your tarent solutions GmbH Evolvis Project Team

mksh R40 is out, so what now?

mksh R40 has been released Sunday 12nd June. So, what can you do with The MirBSD Korn Shell?

Have a look at the collection of shell snippets, which admittedly is only the beginning – most scripts don’t make use of the cool new features yet. But they eventually will. The Shell-Toolkit project is definitely worth a visit! (Admittedly not using my most ❦ dear SCM, but with a DVCS, every checkout is a clone, i.e. a backup, and none of the contributors must fear a central repo being taken down, which, for such a loose collection, is desirable.)

How (not to) encode MIME headers

I was just tracking down why some mails seem to have garbled Subjects.

It looked like this in Alpine:
Subject: [BOFH commits] r2040: fix directory struct =?UTF-8?Q?ure=E2=86=B5=20unix?=/mirror/=?UTF-8?Q?=20=E2=86=92=20mirror?=. bonn

The raw header sight was this:
Subject: [BOFH commits] =?utf-8?q?r2040=3A__fix_directory_struct__=3D=3FUT?=
=?utf-8?b?Ri04P1E/dXJlPUUyPTg2PUI1PTIwdW5peD89L21pcnJvci89P1VURi04P1E/?=
=?utf-8?b?PTIwPUUyPTg2PTkyPTIwbWlycm9yPz0uIGJvbm4=?=

Ein Schelm, wer Böses dabei denkt… First suspect was, of course, Mailman – after decoding, this showed the classical signs of a double-encode. (After ruling out general header brokenness, but no, 76 chars is ok.) I thus hand-crafted an eMail with the correct header line and sent that out:
Subject: [BOFH commits] =?utf-8?q?r2040=3A_fix_directory_structure?=
=?utf-8?b?4oa1IHVuaXgvbWlycm9yLyDihpIgbWlycm9yLmJvbm4=?=

Huh? Mailman and Python weren’t the culprit, thus – this is correct mangling. Okay, let’s dive into the Perl code that actually sends out the eMails. To make a long story short, have a look at this, then RFC 2047:
tglase@tglase:~ $ perl -MEncode -e '$subject = "r2040: fix directory structure↵ unix/mirror/ → mirror.bonn"; Encode::from_to($subject, "UTF-8", "MIME-Q"); print "{Subject: ".$subject."}\n";'
{Subject: r2040:=?UTF-8?Q?=20fix=20directory=20struct?=
=?UTF-8?Q?ure=E2=86=B5=20unix?=/mirror/=?UTF-8?Q?=20=E2=86=92=20mirror?=.
bonn}

Amazingly enough, PHP’s mb_encode_mimeheader, despite being talked to trash in the comments on its online documentation, does manage to get it right:
tglase@tglase:~ $ php -r 'mb_internal_encoding("UTF-8");echo "{".mb_encode_mimeheader("Subject: r2040: fix directory structure↵ unix/mirror/ → mirror.bonn", "UTF-8", "Q")."}\n";'
{Subject: r2040: fix directory =?UTF-8?Q?structure=E2=86=B5=20unix/mirror/?=
=?UTF-8?Q?=20=E2=86=92=20mirror=2Ebonn?=}

Wow. Now, the Perl guys I know told me to use Perl’s Mail tools… which are much too high-level though, for all I have and want is the subject string and an RFC 822 header line. I told them I’m not above doing this, and so I did. The 3P languages can really be annoying.

Why’s Perl’s output wrong anyway? I don’t know for sure, but I think the atoms must be separated, so unquoting /mirror/ in the middle, with no spaces around it, are wrong. (Besides, Encode::from_to can’t do the job right anyway, as it misses the name of the header, which is included in the 76 chars allowed for the first line. BAD • Broken As Desdigned.)

Disclaimer: I don’t really know any Perl, I fight my way through PHP and, barely, Python. (But I can code.)

JSON

I’ve pimped the minijson code in EvolvisForge to be a full-blown JSON encoder and decoder (lexer/parser) now. You wouldn’t believe just how much is broken in PHP (its own json_encode handles floats wrong in most locales, and mb_check_encoding doesn’t check the encoding of a multibyte string… at least, unlike Python, PHP manages to get 8bit okay though).

Anyway, thought you want to know. If you ever need a Pure PHP JSON encoder/decoder, you know where to look. It’s 100% my code (although written during dayjob, so the exploitation rights are with tarent GmbH). Current licence is GPLv2+ or AGPLv3+. If you spot any bugs, you know where to report them. I think it should be good though. (Do note that JSON is case-sensitive, so “NULL”, “True” and “\N” or “\U20AC” are not valid, “null”, “true”, “\n” and “\u20AC” or “\u20ac” are.)

I plan to store the “art_cust123” information in the user_prefs table in JSON now, instead of ‘|’-separated values, to avoid problems like these we had with broken database format and subsequent corruption of values, by using a dictionary (JSON Object) instead.

The ECMA 262 standard (ECMAscript and JSON) is freely available, though. JSON is also additionally specified in RFC 4627 which differs slightly (see my notes for details, mostly the goal element).

Administrativa (Evolvis Blogs)

The blogs have been moved from *.blogs.evolvis.org to *.blog.tarent.de to provide proper SSL certificates. This also means that the use of blogs for people who are not employees of tarent GmbH, tarent AG or one of its subsidiaries is currently not available. (If that should become necessary, please contact us.

The feed has moved to http://evolvisforge.blog.tarent.de/feed/ for this blog (similarily to the others), but just in case, you’ll get redirected (although only to the https version, which Planetplanet doesn’t seem to like).

Planet Evolvis will be set up anew using Planet Venus software shortly.

All in all, the Greater Evolvis Platform is undergoing updates and improvements.

Evolvis: git and scm, SOAP WSDL, Jenkins, …

tarent GmbH now offers both git and Subversion as Source Code Management systems in their Evolvis platform.

The scmsvn plugin of EvolvisForge was amended with the scmgit plugin, backported from a newer FusionForge release, while work to upgrade the main forge code to the soon-to-be-released FusionForge is ongoing in parallel. Of course, most features, such as commit mails (in git, they’re really sent out after a “git push” from the developer), are already available for both; others will follow after the code base upgrade for simplicity. Already, git repositories can be used for all regular tasks – although it’s currently not possible to have both git and svn repositories in a project.

During the migration (as well as regular development), many features of Evolvis will show up in regular FusionForge to benefit the broad community of Forge users, courtesy of the Open Source policy of tarent GmbH, who has contracted the FusionForge project leader to improve both projects, following the mantra of “Fairtrade Software”.

Among other changes, the SOAP WSDL has been corrected and is now versioned, and other areas (especially the Tasks and Tracker) have been improved.

There’s a release announcement of the new version at Evolvis, in case you want to know the details.

Finally, an Evolvis developer has set foot not only in the Mediawiki packaging team at Debian but also the Mailman packaging team. Expect many, if not all, improvements to show up there within some time.

Did you know that Hudson is now called Jenkins? This is a change in name only, due to trademark concerns, but rest assured the Evolvis platform will continue to offer Continuous Integration in a usable fashion, no matter the technology behind (there was Continuum, now Hudson, soon Jenkins).

In our evergoing quest to improve the Evolvis platform, we wish you a pleasant user and developer experience!
//The Evolvis team

25 ☺

And again, with a plethora of bugfixes, improvements and new features, EvolvisForge 4.8.3+evolvis25 was released and deployed. Read on for more details! Continue reading 25 ☺