Habe eben noch ein Slackwarepaket für das heute erschienene wine 2.22 (Entwicklerversion) gebaut. Download-Link
wine 2.20 und CrossOver Beta 5
Hallo zusammen,
es gibt einige kleine Neuigkeiten:
- Heute habe ich auf meinem sogenannten librerig-PC mal wieder ein Slackwarepaket von wine-2.20 gebaut aber nicht veröffentlicht, da hier im Wohnheim einige Uploadports im Netzwerk gesperrt sind, die ich dafür benötigen würde.
- Paint Shop Pro 2018 wurde mit CrossOver 17 Beta 5 getestet aber der Versuch war leider nicht erfolgreich: Es wird über unzureichende JavaScript-Privilegien gemeckert so dass die Installation garnicht startet.
- Bericht über diese Thematik ist bei Codeweavers eingereicht, jedoch handelt es sich nicht um eine “supported App” wo in Bugfällen nachgebessert wird. Wäre aber schön wenn sich CodeWeavers um die Corelinstaller kümmern würde, da ich kein CreativeCloud-Abo von Adobe mit monatlichen Gebühren möchte.
Wünsche ein schönes Wochenende!
CrossOver 17 in der Betaphase – Omniscient Rang geknackt!
Als Teilnehmer der “closed betas” von CrossOver nehme ich aktuell an der Betaphase für CrossOver 17 teil, wobei das fertige Produkt in den kommenden Wochen erscheinen wird.
Weiterhin wurde das deutsche Sprachpaket der Software vervollständigt und CrossOver 17 wird somit komplett auf Deutsch verfügbar sein.
Codeweavers, die Firma hinter CrossOver bietet bei den Tests ein sogenanntes Gamificationsystem an, wobei man Erfahrungspunkte für abgegebene Reports, Kommentare, Screenshots etc. sammeln kann. Insbesondere bei den Betareports kann man ganz gut Experiencepoints abräumen und so gelang es mir, den Rang des:
Omniscient Mystical Exalted Nigh-invincible Supreme Raging Atomic Dragon Turbo Chief Senior Advocate
Bericht von der odoo-Präsentation im Novotel, Hannover
Ich hatte ja in diesem Blog angekündigt, dass ich am Freitag den 20. Januar 2017 eine odoo-Präsentation im Novotel, Hannover besucht habe. Hier folgt ein kurzer Bericht über die Veranstaltung.
I. About odoo / Über odoo
- 32 languages
- 308 employees
- 700 partners
- 1000 installations
- 2 million users
II Odoo Value Proposition
In Folge wird die Integration von Front- und Backend angesprochen: Als Beispiel wurde eine Bestellung, die über die Webseite herein kommt genommen und dass eine Rechnung daraus erstellt wird. Gleichzeitig wird ein Fokus auf Benutzerfreundlichkeit gelegt, das das Arbeiten angenehm macht, während tradionelle ERPs eher für Reportingaufgaben und das Management ausgelegt sind. Odoo möchte gleichzeitig die Verwaltung einer Firma bei gleichzeitiger Benutzerfreundlichkeit realisieren.
III Odoo 10 Demo and Overview (Odoo 10 Demo und Überblick)
IV Questions and Answers
Release- und Developmentbranches in Wine und CrossOver
Kürzlich erschien im offiziellen CodeWeavers-Blog eine Erläuterung, wie wine und CrossOver zusammen hängen. Mit der Erlaubnis von Josh DuBois habe ich diesen Artikel übersetzt:
Hier bei CodeWeavers fragen die Kunden oft wie CrossOver hergestellt wird. Wir bekommen Anfragen, die von ziemlich einfach bis extrem technisch reichen. Beteiligte und neugierige Nutzer sind unter den Freuden, dass wir unser Produkt auf einem Open-Source Projekt basieren.
Jetzt wo CrossOver 16.2 erscheint, denke ich, dass es eine gute Zeit ist, darüber zu sprechen wie wir Entwicklungs- und Releasezweige für CrossOver verwalten. Im Spektrum dieser Dinge, die man über Wine sagen könnte, ist dieses Thema nur bedingt technisch. Es ist eine häufige Frage von unseren Benutzern, sowohl in unseren Webforen und in unserem Livesupport-Kanal.
Grundlegend: CrossOvers Fähigkeit, Windowsanwendungen laufen zu lassen kommt aus Wine. Wine ist ein Open-Source Softwareprojekt mit einer über zwanzigjähigen Geschichte. Der interessante Teil, unsere internen Sourcecode Zweige zu verwalten ist, wie diese mit Wine integriert werden. Um unseren Releasezyklus zu verstehen, muss man Wines Entwicklungszyklus verstehen.
Der Entwicklungszyklus von wine
Wines Haupt git-repository befindet sich unter
git://source.winehq.org/git/wine.git
Mitwirkende schicken täglich Patches an wine und jeden Tage committet Alexandre Juillard, unser furchloser Leiter, akzeptierte Patchen in Wine’s Hauptrepository. Hier bei CodeWeavers ist unser grundlegender Arbeitsprozess, dass unsere eigenen Wineentwickler ihre Arbeit an wine über den regulären Einreichungsprozess einbringen (und hoffen, dass es akzeptiert wird!). Standardmäßig geht also der Code, den wir scheiben zuerst in das Open Source Repository bevor es in unsere eigenen git-Zweige kommt.
Wine erfährt alle zwei Woche eine nummerierte Entwicklungsveröffentlichung, zu wechselnden Freitagen. Diese Veröffentlichungen erhalten ein Tag und werden gebaut und weit in der Open Source Gemeinschaft verwendet. Es wird keine Magie bei den Entwicklungsversionen angewendet – keine speziellen Tests werden durchgeführt und keine Meilensteine für diese Entwicklung erreicht. Es sind einfach und praktisch nummerierte Schnappschüsse der Wine-Entwicklung innerhalb regulärer Zeitintervalle.
Bei CodeWeavers nennen wir unseren Haupt-git-Zweig den ‘crossover’ Zweig. Sofort nach jeder Wineentwicklungsveröffentlichung verbindet Alexandre Wine’s Hauptzweig in unseren internen CrossOver Zweig. So bekommen wir neue Arbeit von Upstream in die Codebasis, die wir nutzen um CrossOver zu bauen. Dies bedeutet, dass für unseren “Standardprozess” ist der zweiwöchige Winemerge das erste Mal einem bestimmten Teil von Wineentwicklungsarbeit – selbst Arbeit von unseren eigenen Entwicklern – unser internes Quellenrepository betritt. [1]
Entwicklungsveröffentlichungen sind spannend, da sie all die neuesten Änderungen beinhalten. Allerdings bedeutet diese Spannung, dass sie instabil sein können. Um dies zu verwalten, ist es nicht überraschend, dass wir einen Releasezweig verwenden.
Release-Zweige
Wir veröffentlichen eine Major-Version von CrossOver einmal im Jahr, irgendwann im Herbst. Etwa zwei Monate vor unserem Veröffentlichungsdatum machen wir einen neuen Zweig basierend auf unserem “crossover” Hauptzweig. Dieser Zweig widmet sich unserer kommenden Veröffentlichung. Unsere Releasezweige starten ihr Leben somit wie es jede Entwicklungsveröffentlichung von Wine tun würde – einfach ein Schnappschuss der Wineentwicklung, die zu einem bestimmten Zeitpunkt gemacht wird.
Wir machen unsere Releasezweige stabiler indem wir durchgehend testen. Wir testen, testen und testen, beheben Bugs und testen noch mehr. Wir testen einige Wochen bei uns und starten eine Beta wobei über zweihundert engagierte Betatester auf CrossOver herumhammern und Probleme berichten. Am Ende unserer Betyzyklen wurde der Code zuverlässiger und vorhersehbar.
Normalerweise machen wir keine weiteren Merges von Wine entlang eines Major-Releases von CrossOver. Somit kann man sagen, üblicherweise hat eine bestimmte Version von CrossOver immer die Version von Wine, die sie hatte, als wir zuerst den Releasezweig von Wine für diese Version erstellten.
Natürlich beheben wir Bugs während der Lebenszeit einer Version aber wir halten diese Behebungen gezielt so dass wir bezüglich ihrer Sicherheit sicher sein können.
Einige Veröffentlichungen sind außergewöhnlich und wir manchen gelegentlich eine vollständige Einbeziehung zwischen Major-Releases. Dies passiert selten. CrossOver 16.2 ist eine dieser Ereignisse! Dies macht es etwas zu einem besonderen Fall. Wenn wir wirklich einen wine-Merge machen, tendieren wir dazu, eine weitere Runde von Betatests zu machen (obwohl diese etwas kürzer als die erste sind).
Hacks
Wine hat sehr hohe Standards bezüglich welches Code in das Masterrepository kommt. Als kommerzielles Produkt weichen CrossOvers Bedürfnisse oft aus pragmatischen Gründen ab. Normalerweise bedeutet dies, dass ein Entwickler ein Problem sieht und kann sagen, dass die elegante Lösung einige Monate Arbeit braucht oder höchst destabilisierend wirkt. Dann bitte ich um eine Lösung, die in der Praxis funktioniert, selbst wenn sie unsauber ist oder das Problem nur in begrenzter Weise löst. Wine wird im Allgemeinen solche Lösungen nicht akzeptieren aber diese verbessern die Lage für unsere Kunde. Wir halten diese Lösungen in unserem eigenen Sourcerepository und nennen diese “Hacks”.
Hacks sind ein Problem, da sie dafür sorgen, dass unsere Quellen von Wines Masterrepository abweichen. Dies macht das Leben für Alexander schwierig denn es ist schwierig Wines Master-Sourcecode in unseren Zweig zu integrieren wenn es Unterschiede dieser Art gibt. Die Unterschiede, die durch unsere “Hacks” entstehen verursachen Konflikte während der Zusammenführung und Alexandre muss jederzeit um diese herumarbeiten wenn eine neue Zusammenführung gemacht wird. Dies ist anstrendend, fehleranfällig und unangenehm.
Aus diesen Gründen war es so, dass wir es vorzogen unsere Hacks in Releasezweig zu bringen. Wir fingen bei CrossOver 16 damit an von unserem Haupt “crossover” Zweig zu branchen und dann zogen wir sofort alle Hacks aus CrossOver 15 herein. Auf diese Art versuchten wir, Hacks in unserem Master ‘crossover’ Zweig zu verhinden in dem Alexandre alle zwei Wochen Merges macht. Die Vermeidung von Hacks auf diesem Zweig machte sein Leben einfacher (und verhinderte eine potentielle Fehlerquelle).
Es gab jedoch Probleme mit diesem Ansatz. Hacks tendierten dazu, von einer Veröffentlichung zur nächsten, zu verschwinden. Somit könnten wir einen Bug mit einem Hack von CrossOver 15 beheben aber wenn wir vergessen würden, den Hack auf unser neues CrossOver 16 anzuwenden, würde der Bug wieder auftreten. Ebenso bedeutete es, dass wir gewisse Windowsprogramme mit unserem Haupt ‘crossover’ Zweig nicht testen konnten, da manche von diesen Hacks zur Funktion benötigten (und diese Hacks waren nur in Releasezweigen vorhanden). Diese Dinge konnten ohne Tests lange Zeit bestehen und wir könnten die Fehlfunktionen nur innerhalb eines Betazyklus für eine neue Veröffentlichung feststellen. Aus diesen Gründen begannen wir fast alle unsere Hacks im crossover Masterbranch zu halten. Dies macht es schwieriger, die zweiwöchigen Merges zu machen aber verhindert andere Probleme.
Trotzdem gibt es immer noch Ausnahmen. Einige “hacks” oder diffs vom upstream wine, sind tatsächlich enorme Massen an Arbeit, die in Hunderte von individuellen Patches enden und viele, viele Datein berühren. Momentan ist der “Command Stream” von wine3d das Hauptbeispiel für einen so großen “Hack”. Es ist nicht realistisch so etwas in unserem Master ‘crossover’ Zweig zu halten da Merges danach wirklich zu schwierig wären, um diese alle zwei Wochen durchzuführen. Somit liegt so etwas nur in den Releasezweigen und wird von einem Releasezweig auf den nächsten bei jedem Zyklus portiert. Es ist schwer und insbesondere mit dem Command Strem versuchen wir, dies upstream zu bringen damit wir diesen nicht mehr weiter verwalten müssen. Zum Glück tendieren wir dazu nicht zu viele solcher enormen “Hacks” zu einem bestimmten Zeitpunkt zu haben. Wenn dies der Fall ist, kann dies Dinge enorm kompliziert oder teuer machen. Somit versuchen wir den Rahmen unserer “Hacks” klein zu halten oder sie upstream zu bringen.
Zusammenfassung
Grundlegendes:
- CrossOver hat eine Version von Wine für jedes Majorrelease mit seltenen aber wichtigen Ausnahmen. Wir testen diese Versionen rigoros um diese zu stabilisieren.
- Unser allgemeiner Arbeitsprozess ist, dass Entwickler Patches an Upstream Wine senden bevor diese unsere interne Repositories erreichen. Somit ist die meiste unserer Arbeit öffentlich verfügbar bevor wir diese selbst nutzen. (Natürlich finden wir einen Weg dies zu bekommen wenn wir in Eile sind und es schnell gehen muss)
- Benutzer mit Privilegien unsere Nightly Builds zu nutzen werden feststellen, dass ein Winemerge alle zwei Wochen stattfindet, da die Nightly Builds im Allgemeinen von unserem Haupt ‘crossover’ Zweig kommen. Diese Build werden den wine3d Command Stream nicht enthalten.
Wenn dich Wine interessiert, kannst Du www.winehq.org besuchen oder den Quelltext unter
git://source.winehq.org/git/wine.git
auschecken… und es selbst bauen. Patches sind Willkommen!
1. Natürlich brauchen wir mache Dinge manchmal schneller und lassen nicht zu, dass unser ‘Standard-Arbeitsprozess’ uns zurückhält. Wenn wir in Eile für eine bestimmte Arbeit sind, können wir uns immer die Rosinen heraus suchen oder es direkt an wenden.
Über Josh DuBois
Josh DuBois ist ein Ingenieur und Produktmanager für CrossOver.
Umlautproblem bei osCommerce-Deutsch behoben
Ein Item, welches lange auf meiner ToDo-Liste stand, kann nun endlich entfernt werden: Es handelt sich um die Problematik, dass bei meinem Fork von osCommerce, basierend auf dem Projekt oscommerce-deutsch.de die Umlaute nicht richtig dekodiert wurden.
Beispielsweise wurden in den vorgegebenen Artikeln die Kategorie “Mäuse” und “Neue Produkte im März” der Umlaut “ä” nicht richtig dekodiert. Dieses Problem hatten wohl schon ein paar andere Leute vorher und ich bin auf einige Codezeilen aufmerksam geworden, die ich letztendlich in mein Repository auf github.com eingepflegt habe. (Link zum commit)
Weiterhin habe ich einige Formatierungsfehler in den Terms & Conditions entfernt, so dass diese nun etwas genauer dargestellt werden. Beispielsweise wurde ein überflüssiges <LI></LI>-Element entfernt, welches einen leeren Bulletpoint erzeugt.
Ebenso wurde das Produktbild zu Unreal Tournament im Shop ausgetauscht, welches nun in einer besseren Qualität vorliegt aber immer noch etwas groß ist.
Happy hacking und schönes Wochenende!
Slackware Paketbau
Auf meinem freien Software PC mit Trisquel 7 liefen viele meiner WLAN-Sticks nicht, da zwingend eine proprietäre Firmware vorausgesetzt wird, diese im Linux-libre-Kernel nicht mitgeliefert wird.
Ich habe daraufhin mich entschlossen, zu einem meiner stillen Favoriten, der Slackware-Distribution zurück zu kehren und mich heute ein wenig mit dem Paketbau wieder beschäftigt.
Insgesamt konnte ich folgende Pakete bauen, die ich nun auch der Allgemeinheit zum Download für 64-Bit Systeme anbiete:
- lyx-2.2.2 – ein LaTeX-Editor, den ich zum Kompilieren von libdsk benötigt habe.
- libdsk – eine Bibliothek zum Lesen von Schneider CPC-Floppydisks.
- xcpc – ein Amstad CPC-Emulator.
- Penguin Command – ein Missile Command Klon.
Viel Spaß damit!
Meine neuen freien ERP-Projekte
Letzten Freitag habe ich eine Präsentation des ERP-Systems odoo besucht und bin schwer beeindruckt. Organisiert wurde diese Veranstaltung in Zusammenarbeit mit den hannoveraner Firmen ecoservice und IFE GmbH.
Ich entschloss mich, schon etwas vor der Veranstaltung dort zu sein und nach einem kleinen Imbiss bei meinem Lieblingsgriechen Iridion kam ich dann schließlich im Vier-Sterne-Hotel Novotel an.
Natürlich durfte der Laptop nicht fehlen und ein Stuhl aus der vorderen Sitzreihe wurde dann prompt als Laptopunterlage umfunktioniert. Insgesamt habe ich drei Seiten an Notizen gemacht, die ich in einem separaten Blogartikel präsentieren werde damit auch Leute, die nicht an der Veranstaltung teilnehmen konnten, einen Eindruck bekommen, um was es bei odoo geht.
Ansonsten habe ich mich die Tage etwas mit IBM DB2 beschäftigt. IBM hat sich wieder im Rahmen der CeBIT großzügig gezeigt und einen Full-Event-Pass geschickt. Hier ein großes Danke an Ginnis Team!
Meine Pläne sind, SQL Ledger auf DB2 zu portieren: Ich weiss, dass dies einige Konsequenzen für den freien Softwarestack hat auf dem DB2 basiert. Das nehme ich vorerst in Kauf.
IBM bietet mit der DB2 Express-C eine kostenlose und unbeschränkte Version ihres Datenbankservers an. Allerdings wird der Sourcecode von DB2 Express-C nicht veröffentlicht.
Warum mache ich das?
Ich bin ziemlich von IBMs Technologien beeindruckt, insbesondere vom Supercomputer Watson, den POWER-Servern, Notes, Bluemix sowie der Analytics-Sparte. Meine Initiative dient dazu, sich IBM etwas anzunähern.
Die Anstrengungen, SQL Ledger auf DB2 zu portieren, dürften überschaubar sein. SQL Ledger kann durch die Programmierung in Perl ein Modul namens DBI verwenden, welches eine Verbindungsschnittstelle zu verschiedenen Datenbankservern im Backend aufbauen kann. Laut des Gründers von SQL Ledger dürfte es reichen, den Connect-String und die Konfigurationsdatei anzupassen.
Voraussichtlich wird es dann auch wieder etwas Aktivität in meinem github-Repository mit einem speziellen SQL Ledger-Fork geben.
Ansonsten habe ich für meinen eeepc-Laptop ein neues Netzteil gekauft und das Aufladen der Batterie funktioniert nun auch wieder. Allerdings scheint der eeepc bei der Installation eines Linuxbetriebssystems doch etwas zu zicken, da sich der Computer während der Installation von Trisquel Mini und Lubuntu (Alternate ISO) in der Mitte der Installation aufhing. Weiterhin habe ich eine Netzwerkinstallation von openSUSE i586 mit den Netzwerkinstallationsmedien versucht. Aber auch dies hat leider nicht geklappt, da nach Laden des Installationssystems eine Inkompatibilität mit dem Bootmedium monierte. (Installation system does not match your boot medium, Sorry, this will not work.)
Besuch des univention Summits 2017 in Bremen
Hallo zusammen,
ich habe mich eben für den univention Summit in Bremen angemeldet und werde im Hotel 7things dort übernachten. Insbesondere werde ich dort den IT an Schulen Track besuchen.
Frohes neues Jahr! – Aktuelle Hacks mit GNUcash und ebay
Ich wünsche den Lesern dieses Blogs erst einmal etwas verspätet ein Frohes Neues Jahr.
Ich selbst habe die letzten Tage damit verbracht, mir GNUcash nochmals anzuschauen und bin insbesondere auf einige YouTube-Videos von einem YouTuber namens “Test IT” aufmerksam geworden, der sich mit Haushaltssoftware beschäftigt.
Inspiriert durch die Onlinebanking-Funktion von GNUcash habe ich ebenfalls versucht, mit GNUcash eine Verbindung mit meiner Bank, Sparkasse Gifhorn-Wolfsburg, eine HBCI-Verbindung aufzubauen.
Mir ist dabei aufgefallen, dass die Server-URLs noch nicht im Programm eingetragen waren. Also habe ich die Online Banking Hotline angerufen, die mir diese Informationen dann auch sehr schnell per Email zusendete.
Diese Konfigurationsdaten habe ich anschließend per Mail an die GNUcash-Mailingliste weitergeleitet. Mal schauen ob sie mit diesen Daten etwas anfangen können und diese in das Hauptprogramm integrieren.
Ansonsten habe ich mich auch etwas mit ebay beschäftigt und festgestellt, dass sowohl Perl als auch Postgres von ebay offiziell unterstützt werden. Mittlerweile bin ich nun im ebay-Developerprogramm in der Hoffnung, mein Warenwirtschaftssystem “SQL Ledger” an diesen Marktplatz anbinden zu können.