[maf]

Hallo,

mein System ist ein Raspberry Pi B mit MLD-4.0.1-rpi_rpi-client_2014.09.02-74.tgz und aktuellen Updates.

Als MLD-Neuling habe ich versucht, eine Medion X10 Fernbedienung einzurichten, und bin dabei auf ein Problem mit lircd2uinput und python-gobject gestoßen. So scheint es mir zumindest 

In der yaVDR Anleitung für Fernbedienungen findet sich der Hinweis, dass bei der Option --uinput für lircd doppelte Tastendrücke am Eventgerät ankommen. Weil ich das Problem zumindest bei manchen Tasten hatte, habe ich versucht, lircd2uinput zu installieren, das auch yaVDR als Abhilfe benutzt. Gemäß /etc/init.d/lirc wird dieses Skript in MLD benutzt, falls es verfügbar ist. Danach funktionierte die Fernbedienung allerdings garnicht mehr.

Es stellte sich heraus, dass lircd2uinput nicht lief, weil das Python-Modul gobject nicht verfügbar war. Bei der Installation von lircd2uinput (ein Protokoll hat gkd-berlin schon hier gepostet) tauchen zwei Version von python-gobject-2 auf: 2.7-3 und 2.28.6-1. Letzere (aus oldlibs) ist zum Schluss installiert, enthält aber kaum Dateien. Nach einem manuellen Downgrade auf 2.7-3 (aus libs), das deutlich mehr Dateien enthält, lief lircd2uinput allerdings immer noch nicht. Das liegt daran, dass das Paket in /usr/lib/python2.7/dist-packages/gobject/ drei Verweise auf Dateien im nicht existierenden Verzeichnis /usr/share/pyshared/gobject/ enthält (constants.py, __init__.py und propertyhelper.py).

Meine Fragen an die Profis deshalb:
 - Wozu wird python-gobject-2 2.28.6-1 benötigt?
 - Wo finden sich die fehlenden Dateien für python-gobject-2 2.7-3 (in Debian sind sie in python-gobject-2 enthalten...)?
 - Hat einer von Euch lircd2uinput im Einsatz?
Und die Bonusfrage:
 - Welche lircd.conf benutzt Ihr für die Medion X10 RF Fernbedienung?

Gruß
Malte

[maf]

Ich habe mittlerweile eine Entwicklungsumgebung unter Raspbian aufgesetzt, um mir das Modul python-gobject-2 genauer ansehen zu können. Ergebnis meiner Bemühungen sind ein Vorschlag für eine Änderung am Projekt und ein Probleme beim Upgrade auf die neue Version des Pakets. Zum Rücksprung der Versionsnummer von 2.28.6-1 auf 2.7-3 habe ich einen anderen Thread gestartet.

Wie schon berichtet, gibt es derzeit in MLD 4.0.1 zwei Versionen von python-gobject-2. Beide sind m.E. kaputt. Version 2.28.6-1 enthält fast keine Dateien. Version 2.7-3 deutlich mehr, aber auch hier fehlen noch einige. Das lässt sich korrigieren, indem man im Makefile des Projekts das Ziel $(data) neu definiert, z.B. so:

Code: [Select]

$(data): $(data_tree)
        dpkg -L $(deps) | grep "/usr/share/pyshared\|python$(version)" | while read file; do \
                test -d "$$file" && mkdir -p "$@$$file"; \
                test ! -d "$$file" && mkdir -p $$(dirname "$@$$file") \
                                   && cp -d "$$file" "$@$$file"; \
        done

Mit dieser Definition habe ich ein neues Paket gebaut. Es lässt sich aber nicht installieren:

Code: [Select]

mld1> opkg --force-downgrade install python-gobject-2_2.7.maf1-3.opk
Create a snapshot of '/mnt/root/@root' in '/mnt/root/2014-10-31 16:39'
Downgrading python-gobject-2 from 2.28.6-1 to 2.7.maf1-3 on root.
Not selecting libglib2.0-0 2.33.12 as installing it would break existing dependencies.
Not selecting libglib2.0-0 2.33.12 as installing it would break existing dependencies.
Not selecting libpcre3 8.30 as installing it would break existing dependencies.
Not selecting libpcre3 8.30 as installing it would break existing dependencies.
Not selecting libgcc1 4.7.2 as installing it would break existing dependencies.
Not selecting libgcc1 4.7.2 as installing it would break existing dependencies.
Collected errors:
 * pkg_hash_fetch_best_installation_candidate: Packages for libglib2.0-0 found, but incompatible with the architectures configured
 * pkg_hash_fetch_best_installation_candidate: Packages for libglib2.0-0 found, but incompatible with the architectures configured
 * pkg_hash_fetch_best_installation_candidate: Packages for libpcre3 found, but incompatible with the architectures configured
 * pkg_hash_fetch_best_installation_candidate: Packages for libpcre3 found, but incompatible with the architectures configured
 * pkg_hash_fetch_best_installation_candidate: Packages for libgcc1 found, but incompatible with the architectures configured
 * pkg_hash_fetch_best_installation_candidate: Packages for libgcc1 found, but incompatible with the architectures configured
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for python-gobject-2:
 *      raspi-copies-and-fills (>= 0.4-1) *     libglib2.0-0 (>= 2.40.0-5) *   libpcre3 (>= 8.31-1) *   libgcc1 (>= 4.8.2-1) *

Dieser Fehler wurde im Forum bereits diskutiert, u.a. hier. Wenn ich die Diskussion recht verstehe, dann handelt es sich letztlich um ein Problem in opkg. Mir ist aber leider noch nicht klar, was ich tun muss, um es zu umgehen...

[maf]

Ok. Wieder ein bisschen weitergekommen. Aber auch wieder Fragen. Vielleicht erbarmt sich ja doch mal einer und hat einen Tipp...

Zum einen habe ich habe ich die Berechnung der Versionsnummer für python-gobject-2 so verändert, dass meine neues Paket den beiden alten beim Upgrade vorgezogen wird:

Code: [Select]

version := $(shell dpkg-query -W -f='$${Version}' python-gobject-2 | sed -r 's/-[^-]+$$//')
package_revision := maf1
Für die Revision war eine Änderung in Makefile.default erforderlich:

Code: [Select]

# Version des Modules
ifeq ($(package_version),)
  package_version := $(shell test -e .git && git describe 2>/dev/null | cut -d- -f2)
  ifeq ($(package_version),)
    package_version = 0
  endif
  package_version := $(package_version)$(package_revision)
endif

Zum andern wurde mir klar, dass ich auch die Pakete für Python und diverse Bibliotheken in mein Repository einstellen sollte, die zusammen mit python-gobject-2 automatisch erstellt worden waren. Damit wäre nun folgende Installation möglich:

Code: [Select]

mld1> opkg --noaction install python-gobject-2
Create a snapshot of '/mnt/root/@root' in '/mnt/root/2014-11-01 21:49'
Installing python-gobject-2 (2.28.6-3maf1) on root.
Downloading http://mld.maf.lan/maf/4.0.1-rpi/files/base/python-gobject-2_2.28.6-3maf1.opk.
Not selecting libc6 2.13 as installing it would break existing dependencies.
Not selecting libglib2.0-0 2.33.12 as installing it would break existing dependencies.
Not selecting libglib2.0-0 2.33.12 as installing it would break existing dependencies.
Not selecting libpcre3 8.30 as installing it would break existing dependencies.
Not selecting libpcre3 8.30 as installing it would break existing dependencies.
Not selecting libc6 2.13 as installing it would break existing dependencies.
Not selecting libc6 2.13 as installing it would break existing dependencies.
Not selecting libgcc1 4.7.2 as installing it would break existing dependencies.
Not selecting libgcc1 4.7.2 as installing it would break existing dependencies.
Not selecting libc6 2.13 as installing it would break existing dependencies.
Not selecting libc6 2.13 as installing it would break existing dependencies.
Not selecting libpcre3 8.30 as installing it would break existing dependencies.
Not selecting libpcre3 8.30 as installing it would break existing dependencies.
Not selecting libgcc1 4.7.2 as installing it would break existing dependencies.
Not selecting libgcc1 4.7.2 as installing it would break existing dependencies.
Installing raspi-copies-and-fills (0.4-1) on root.
Downloading http://mld.maf.lan/maf/4.0.1-rpi/files/libs/raspi-copies-and-fills_0.4-1.opk.
Not selecting libc6 2.13 as installing it would break existing dependencies.
Upgrading libglib2.0-0 from 2.33.12-5 to 2.40.0-5 on root.
Downloading http://mld.maf.lan/maf/4.0.1-rpi/files/libs/libglib2.0-0_2.40.0-5.opk.
Not selecting libpcre3 8.30 as installing it would break existing dependencies.
Not selecting libc6 2.13 as installing it would break existing dependencies.
Not selecting libgcc1 4.7.2 as installing it would break existing dependencies.
Installing raspi-copies-and-fills (0.4-1) on root.
Not selecting libc6 2.13 as installing it would break existing dependencies.
Upgrading libpcre3 from 8.30-2 to 8.31-1 on root.
Downloading http://mld.maf.lan/maf/4.0.1-rpi/files/libs/libpcre3_8.31-1.opk.
Not selecting libc6 2.13 as installing it would break existing dependencies.
Installing raspi-copies-and-fills (0.4-1) on root.
Not selecting libc6 2.13 as installing it would break existing dependencies.
Upgrading libgcc1 from 4.7.2-1 to 4.8.2-1 on root.
Downloading http://mld.maf.lan/maf/4.0.1-rpi/files/libs/libgcc1_4.8.2-1.opk.
Not selecting libc6 2.13 as installing it would break existing dependencies.
Installing raspi-copies-and-fills (0.4-1) on root.
Not selecting libc6 2.13 as installing it would break existing dependencies.
Upgrading libpcre3 from 8.30-2 to 8.31-1 on root.
Not selecting libc6 2.13 as installing it would break existing dependencies.
Breaking circular dependency on libpcre3 for raspi-copies-and-fills.
Upgrading libgcc1 from 4.7.2-1 to 4.8.2-1 on root.
Not selecting libc6 2.13 as installing it would break existing dependencies.
Breaking circular dependency on libgcc1 for raspi-copies-and-fills.

Kommt dabei nun trotz der vielen Meldungen ein konsistentes System heraus? Obwohl sie eher "pessimistisch" klingen, wäre letztlich libc6 die einzige Bibliothek, die nicht installiert würde. Das liegt m.E. daran, dass das neu erstellte Paket die Version 2.13-10 hat, während die (lt. Timestamp bereits am 02.09.) installierte Version "schon" 2.13-11 ist. Über meine Versuche, die Prinzipien der Vergabe von Versionsnummern zu verstehen, berichte ich in einem anderen Thread.

[clausmuus]

Hi,

Danke für den Hinweis mit den python-gobject-2Paket. Es soll natürlich nur eines der Beiden Pakete geben. das 2.28'er Paket wurde fälschlicherweise automatisch erstellt. Die Ursache ist mir aber nicht klar. Ich hab's wieder entsorgt. Der Fehler mit den fehlenden Dateien (bzw. tote Links) dürfte auf nen update des zugrunde liegende Debian Paketes beruhen, bei dem ein wenig was umsortiert wurde. Ich hab das Makefile korrigiert (in Anlehnung an Deinen Vorschlag).
Bei der Versionsnummer für das Paket habe ich bewusst die Versionsnummer der enthaltenen python Version gewählt, um nicht den Überblick zu verlieren, wozu das gehört, wenn später eventuell auf python 3 umgestelt werden soll. die .28 im zugrundeliegenden debian Paket dürfte am ehesten unserer MLD Versionsnummer (am Ende) entsprechen.
Es gibt nun also wieder auch für den RPI ein funktionierendes gobjekt Paket.

Claus

[maf]

Hallo Claus,

danke für Deine Antwort und die prompt erstellte neue Paketversion!

Doch auch ohne mein eigenes Repository und nach einem 'opkg update' wird mir neben Deiner neuen immer noch eine Version 2.28.6-1 von python-gobject-2 angezeigt:

Code: [Select]

mld1> opkg info python-gobject-2
Package: python-gobject-2
Version: 2.7-4
Depends: python, libglib2.0-0 (>= 2.33.12-5), libc6 (>= 2.13-11), libffi5 (>= 3.0.10-1), libpcre3 (>= 8.30-2), libgcc1 (>= 4.7.2-1), zlib1g (>= 1.2.7-1), libselinux1 (>= 2.1.9-1)
Status: unknown ok not-installed
Section: libs
Architecture: armv6l
Maintainer: TEAM <team@minidvblinux.de>
Size: 178462
Filename: python-gobject-2_2.7-4.opk
Description:

Package: python-gobject-2
Version: 2.28.6-1
Depends: libglib2.0-0 (>= 2.33.12-5), libc6 (>= 2.13-11), libffi5 (>= 3.0.10-1), libpcre3 (>= 8.30-2), libgcc1 (>= 4.7.2-1)
Status: unknown ok not-installed
Section: oldlibs
Architecture: armv6l
Size: 5898
Filename: python-gobject-2_2.28.6-1.opk
Was mache ich da falsch?

Mit Deinen Konzept für die Vergabe von Versionsnummern von Python-Paketen kann ich mich zugegebenermaßen noch nicht so recht anfreunden. Bergen Versionsnummern wie die für python-gobject-2 nicht die Gefahr, dass sie sich überhaupt nicht ändern auch wenn die zugrundeliegende Software eine gänzlich neue Version ist?

Ließe sich die Frage ob ein Paket zu Python 2.x oder 3.x passt auch über seine Abhängigkeiten lösen? In Debian kann man beides parallel installieren, weil die Pakete unterschiedliche Namen haben. In MLD würde es vermutlich ausreichen, wenn Du entscheidest, welche Version von Python Du hineinnimmst. Und zu der passen dann die abhängigen Pakete.

Schönen Gruß
Malte

[clausmuus]

Hi,

ich hatte vergessen das falsche gobject Paket zu löschen. Ich hatte nur die Quelle für das Paket entfernt Das sollte nun aber behoben sein.

Dein Hinweis bezüglich der Versionsnummer ist natürlich richtig. Ich hatte mir das nicht genau genug angeschaut, und so übersehen, das die python 3 pakete ja immer ne 3 im Namen haben. Ich werde also die Versionsnummern der python Pakete überarbeiten. Du findest das im Bugtracker unter http://www.minidvblinux.de/bug/view.php?id=135

Claus

[maf]

ich hatte vergessen das falsche gobject Paket zu löschen. Ich hatte nur die Quelle für das Paket entfernt Das sollte nun aber behoben sein.

Yep, jetzt ist alles gut . Danke!