Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - maf

76
Entwicklung [ Development ] / Wie kommen die Versionsnummern zustande?
« on: November 07, 2014, 21:42:42 »
Quote
Meine Hauptkriterien für Versionsnummern wären vermutlich, dass eine Änderung der Quellen (Upstream oder native) und eine Änderung der Paketierung (Revision) stets zu einer neuen, "höheren" Versionsnummer führt, damit ein eindeutiges Verfahren für Upgrades umgesetzt werden kann
Das ist bereits jetzt der Fall. Oder ist Dir nen Paket aufgefallen, wo das nicht so ist (mal abgesehen vom python-gobject-2)?
Zumindest erkenne ich noch nicht, wie das in den Makefiles umgesetzt ist. Aber das kann sehr wohl daran liegen, dass ich die nicht gut genug verstehe.

Mein Verständnis ist bislang: Von welchen Quellpaketen (Ubuntu oder Raspbian) ein MLD Paket abhängt, steht in der Variablen deps. Die Versionsnummer des MLD Pakets wird aber nicht zwangsläufig aus der Versionsnummer der Quellpakete abgeleitet (bei mehreren wäre das auch bestimmt nicht trivial). Die MLD Module nutzten stattdessen unterschiedliche Verfahren, um eine Versionsnummer festzulegen. Meine Vermutung: Immer dann, wenn ein MLD Paket von (mindestens einem) Quellpaket abhängt, seine Versionsnummer aber statisch festgelegt wird, kann sich der Inhalt des Pakets ändern ohne dass sich seine Versionsnummer ändert. Aber auch wenn die Versionsnummer berechnet wird, ist das noch keine Garantie, dass alle Änderungen bei Quellpaketen berücksichtigt werden.

Viel hängt natürlich davon ab, was "abhängig" bedeutet. Ich stelle mir darunter vor, dass Dateien aus dem Quellpaket in das MLD Paket übernommen werden. Vielleicht stimmt das ja so pauschal garnicht.

Ich habe ein Skript 'check-versions' angehängt, das versucht, aufgrund der Einträge in den Makefiles Module zu identifzieren, die Probleme mit der Versionsnummer haben könnten. Das sind derzeit insbesondere Module die Abhängigkeiten definieren und keine Quelle (src_rule, src_url) definieren und ihre Version nicht berechnen.

Für diese Module werden dann ihre Versionsnummern und die Versionsnummer des Quellpakets (soweit verfügbar) ausgegeben. Es werden sicherlich viele Module dabei sein, bei denen Du, Claus, oder andere Entwickler sofort sagen: Da ist alles in Ordnung. Und andere Module, die vielleicht ein Problem haben könnten, werden durchs Raster fallen. Die aktuellen Heuristiken sind mit Sicherheit fehlerhaft. Meine Hoffnung ist auch nur, dass wir anhand des Skripts besser diskutieren können, wie die Vergabe von Versionsnummern funktioniert. Deshalb habe ich es recht großzügig kommentiert. Und vielleicht können wir es in ein paar Iterationszyklen so verbessern, das es weniger Fehler produziert.

Das Skript muss im Verzeichnis der Entwicklungsumgebung aufgerufen werden oder dieses Verzeichnis als Argument übergeben bekommen. Für jedes problematische Modul wird eine Zeile ausgeben. In der letzen Spalte steht entweder die Version des Quellpakets gleichen Namens oder, falls das nicht existiert aber das Paket genau eine 'dep' hat, dessen Versionsnummer (mit angehängtem Fragezeichen), andernfalls nur ein Fragezeichen.

Code: [Select]
#! /bin/bash

# try to identify those modules that might have version number that
# does not change when the version of the underlying sofware changes

# modules this script does not identify (but should)
# - vdr-plugin-streamdev-client

# optional arguments
# - base directory of development environment

# setup
base=${1:-.}
release_version=4.0.1
case $(uname -m) in
x86)    release_arch=32;;
x86_64) release_arch=64;;
armv6l) release_arch=rpi;;
*)      echo $(basename $0): unknown architecture; exit 1;;
esac
release=${release_version}-${release_arch}
packages=/tmp/mld_packages_${release}

# retrieve release package list if not available
if [ ! -f $packages.vers ]; then
# determine architecture
# download package list
pkg_url=http://www.minidvblinux.de/download/${release}/files/base/Packages.gz
rm -f $packages $packages.gz
wget -qO $packages.gz $pkg_url
        gunzip $packages.gz
# parse package list
awk '/^Package: / { package=$2 }
     /^Version: / { version=$2 }
             /^$/         { print package ": " version }
    ' $packages > $packages.vers
fi

# determine version of a package if available
pkg_version () {
name=$1

candidate=$(LANGUAGE=C apt-cache policy $name | awk '/Candidate/ { print $2 }')
        if [ -n "$candidate" ] && [ "$candidate" != "(none)" ]; then
echo ${candidate%-*}
fi
}

# loop over modules to identiy potential version problems
find "$base" -mindepth 2 -maxdepth 2 -name Makefile -print | while read file; do
# don't look at libs
test $(dirname $file) == "$base/libs" && continue
# skip modules that don't use deps
        grep -qE '^deps +:?=' $file || continue
# skip modules that define a source
grep -qE '^src_(rule|url) +:?=' $file && continue
# skip modules that define version_of
grep -qE '^version_of +:?=' $file && continue
# skip modules that compute version or latest_version unless using the python version
grep -E '^(latest_)?version +:?= \$\(shell' $file | grep -qv python && continue

# identify module
        module=${file%/Makefile}
module=${module##*/}

# determine MLD package version
mld_version=$(awk '/^'$module':/ { print $2 }' $packages.vers)
        mld_version=${mld_version%-*}

# determine source package version
source_version=$(pkg_version $module)
# guess version from single dep
if [ -z "$source_version" ] && [ $(awk '/^deps / { print NF }' $file) == "3" ]; then
dep=$(awk '/^deps / { print $3 }' $file)
source_version=$(pkg_version $dep)"?"
fi
# give up
if [ -z "$source_version" ]; then
source_version=?
fi

# report findings
        echo $module: $mld_version - $source_version
done

Quote
Bei MLD-eigenen Paketen vertehe ich das [...]. Aber es sind ziemlich viele Pakete dabei (nfs-*, diverse vdr-plugin-*, ...) die auch "nur" eine 0 als Versionsnummer haben und indirekt oder direkt auf externer Software basieren.
Ja, da besteht noch ein wenig Nachbesserungs Bedarf. Wenn Du magst, kannst Du gerne mal alle (oder erst mal einige exemplarische) Pakete raussuchen, bei denen das Deiner Meinung nach geändert werden sollte.
Vielleicht liefert check-versions ja irgendwann nutzbare Ergebnisse :).

Quote
Wünschenswert schiene mir außerdem, dass es für einen Entwickler möglich ist, eigene Paketversionen zu erstellen (lokale Revision), die zwischen der aktuellen und der nächsten "offiziellen" Version liegen. Das klappt z.B. bei Debian recht gut.
Wie setzt Debian das denn um? Kannst Du nen Beispiel geben, für ne Versionsnummer des offiziellen Paketes und ner lokalen Version?
Die genaue Beschreibung, wie Versionsnummer in Debian aufgebaut sind, liefert natürlich nur das Debian Policy Manual. Meine Kurzfassung: Die Versionsnummer besteht aus der Version der zugrundeliegenden Software (Upstream) und der Debian Revision. Beide sind durch ein "-" voneinander getrennt. Die Revision wird jedesmal erhöht, wenn eine Änderung bei der Paketerstellung vorgenommen wird. Wenn ich eine eigene Änderungen an einem Debian vornehme, modifiziere ich die Revision. Statt der Versionsnummer des offiziellen Pakets 47.11-3 erhält mein Paket dann z.B. die Version 47.11-3maf1. Wenn die nächste offizielle Version 47.11-4 freigegeben wird, ist sie höher als meine. Nach diesem Schema werden z.B. auch die Versionsnummern für Sicherheits-Updates vergeben, wenn sich die Version gepackten Software nicht ändert.

Ich hoffe das war nun nicht zu verwirrend. Andernfalls werde ich Dir nen kleines Beispiel geben.
Die Erklärung war sehr hilfreich. Danke! Und trotzdem: Ein Beispiel wäre toll  ;).

Bei den libs-Paketen habe ich zugegebenermaßen den Verdacht, dass eigentlich kein Zusammenhang zwischen den Versionen der Quell-Bibliotheken und der Versionsnummer des Bibliothekspakets besteht. Vielleicht geht das ja auch überhaupt nicht. Aber meine Erfahrung beim Erstellen eines einzigen Pakets in einer frischen Entwicklungsumgebung verstehe ich mittlerweile so, dass dabei Bibliothekspakete erstellt werden (von denen dann auch Abhängigkeiten bestehen können), die vielleicht neuere Dateien enthalten als das gleichnamige Paket aus dem offiziellen Repository, aber eine kleinere Versionsnummer haben, weil sie aufgrund der Erfordernisse dieses speziellen Erstellungsprozesses weniger Teilbibliotheken enthalten.

Falls das zutrifft, dann liefert eine Änderung an einem einzelnen Paket nur dann ein Ergebnis, das konsistent mit dem Rest von MLD ist, wenn man das Paket in einer Entwicklungsumgebung erstellt, in der die anderen Pakete schon enthalten und erstellt worden sind. Ist das wirklich so?

Gruß,
Malte

77
Ja:
Code: [Select]
mld1> irw
175 0 KEY_MODE devinput
^C

Und plötzlich funktioniert die Taste auch im VDR! Ich versteh's nicht. Ich könnte schwören, dass ich nichts mehr am System oder der Konfiguration geändert habe, bevor ich den Rechner jetzt wieder gestartet habe, um Deine Frage zu beantworten. Eigentlich ist es sogar die Konfiguration, die ich von Anfang an hatte.

Aber das kann natürlich nicht sein. Peinlich. Ich bitte um Entschuldigung.

Bleibt als "Trost" nur, dass bei mir weiterhin irrecord nicht funktioniert und /etc/init.d/lirc stop nicht die Prozesse beendet, die /etc/init.d/lirc start startet. Aber ich sollte mich wohl lieber für eine Weile zurückhalten mit Problemberichten :).

Malte


78
Hallo,

ich benutze MLD 4.0.1 auf einem Raspberry Pi. Leider will es mir nicht gelingen, meine Fernbedienung so einzurichten, dass ich die Tonspur umschalten kann.

Meine Fernbedienung ist eine Medion X10 mit USB Empfänger wie auf dem linken Bild auf dieser Seite. Meine Konfiguration für LIRC ist
Code: [Select]
mld1> grep -i lirc /etc/rc.config
# Lirc Aufruf Argumente
LIRC_ARGS=""
# Lirc modul to use
LIRC_MODUL="atilibusb"
LIRC_KEYMAP=""
Zusätzlich zu lirc habe ich lircd2uinput installiert; dadurch kommt es nicht mehr zu Dopplungen beim Tastendruck (siehe die Erklärung zum Bug bei Verwendung von --uinput).

Als lircd.conf benutze ich aus den vielen, die mit MLD kamen, die Konfiguration für eine Medion X10, Remote P/N:   20016398, von Dirk Aust. Der funktioniert auch für viele Standardtasten prima (Pfeile, Ziffern, Kanalwechsel, Lautstärke, ...). Aber die Taste für den Wechsel der Tonspur will nicht funktionieren. Wenn ich sie drücke passiert - nichts.

Die zugehörigen Einträge in den Konfigurationsdateien /etc/lircd.conf und /etc/vdr/remote.conf sind
Code: [Select]
mld1> grep -i mode /etc/lircd.conf /etc/vdr/remote.conf
/etc/lircd.conf:  KEY_MODE                 0xDB06                    #  Was: MUSIC
/etc/vdr/remote.conf:LIRC.Audio         KEY_MODE

Leider weiß ich nicht, ob 0xDB06 wirklich stimmt. Aber wenn ich versuche, mit irrecord eine eigene Konfiguration zu erstellen, komme ich nur bis
Code: [Select]
Hold down an arbitrary button.
.................................irrecord: gap not found, can't continue
Lediglich die Zahl der Punkte variiert zwischen den Versuchen :)

Dass die Taste funktioniert, habe ich aber mit mode2 verifiziert:
Code: [Select]
mld1> mode2 -r -d /dev/lirc0
code: 0x14db060000
^C

Vermutlich übersehe ich etwas ganz Einfaches. Könnte mir bitte jemand weiterhelfen?

Danke,
Malte

79
Hallo,

ich erhalte jetzt in der gleichen VM mit einer frischen Entwicklungsumgebung nach dem Vorspann aus clone, checkout_all und update keine Aufforderungen für add-apt-repository mehr, aber zwischen den Paketnamen noch ein paar unerwartete Zeilen:
Code: [Select]
malte@lubuntu_vb:~/mld2/MLD$ make deps
subversion cvs squashfs-tools ... ir-keytable Set up your local git
---------------------
The given name and email will be shown in the git log file.
Please enter your full name: Please enter your email address: -e



        Iso: base:


            initramfs:
              Build initramfs...
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for perl... /usr/bin/perl
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for ranlib... ranlib
checking for xmlto... :
configure: creating ./config.status
config.status: creating Makefile
config.status: creating templates/Makefile
config.status: creating perl/Makefile
config.status: creating doc/Makefile
config.status: creating exec/Makefile
config.status: creating exec/ipconfig/Makefile
config.status: creating exec/nfsmount/Makefile
config.status: creating man/Makefile
config.status: creating doc/yaird.xml
config.status: creating include/config.h
config.status: executing depfiles commands
Das für opkg benötigtes Ubuntu Paket libgpgme11-dev fehlt.
Das für opkg benötigtes Ubuntu Paket autoconf fehlt.
Sie können es durch folgende Eingabe installieren:
sudo apt-get install libgpgme11-dev autoconf libboost-program-options-dev libboost-thread-dev ... libgl1-mesa-dri virtualbox-guest-x11
Anm.: Die ... stehen jeweils für die Paketnamen, die ich gelöscht habe.

Malte

80
Raspberry PI / Problem mit lircd2uinput und python-gobject-2
« on: November 05, 2014, 13:09:18 »
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!

81
Hi,

nach meinen Aufzeichnungen habe ich (in einer frisch aufgesetzten VM mit Lubuntu Trusty) folgendes gemacht:
Code: [Select]
malte@lubuntu_vb:~/mld$ git clone http://minidvblinux.de/git-4/MLD.git MLD
...
malte@lubuntu_vb:~/mld/MLD$ mkdir logs
malte@lubuntu_vb:~/mld/MLD$ make checkout_all 2>&1 | tee logs/checkout_all.log
...
malte@lubuntu_vb:~/mld/MLD$ sudo apt-get update
...
malte@lubuntu_vb:~/mld/MLD$ sudo apt-get install $(make deps) 2>&1 | tee logs/install_deps.log
You must first add a ppa repository before you can install ffmpeg:
sudo add-apt-repository ppa:samrog131/ppa && sudo apt-get update

You must first add a ppa repository before you can build midori:
sudo add-apt-repository ppa:midori/ppa && sudo apt-get update

You must first add a repository, before you can install plexhometheater:
sudo add-apt-repository 'ppa:plexapp/plexht' && sudo apt-get update && sudo apt-get install plexhometheater

You must first add a repository, before you can install plexmediaserver:
sudo add-apt-repository 'deb http://plex.r.worldssl.net/PlexMediaServer/ubuntu-repo lucid main' && sudo apt-get update && sudo apt-get install plex-archive-keyring && sudo apt-get update

You must first add a repository, before you can install plexmediaserver:
sudo add-apt-repository 'deb http://plex.r.worldssl.net/PlexMediaServer/ubuntu-repo lucid main' && sudo apt-get update && sudo apt-get install plex-archive-keyring && sudo apt-get update

You must first add a repository, before you can install plexmediaserver:
sudo add-apt-repository 'deb http://plex.r.worldssl.net/PlexMediaServer/ubuntu-repo lucid main' && sudo apt-get update && sudo apt-get install plex-archive-keyring && sudo apt-get update

You must first add a repository, before you can install plexmediaserver:
sudo add-apt-repository 'deb http://plex.r.worldssl.net/PlexMediaServer/ubuntu-repo lucid main' && sudo apt-get update && sudo apt-get install plex-archive-keyring && sudo apt-get update

You must run a command, after you install libdvdread4:
sudo /usr/share/doc/libdvdread4/install-css.sh

You must first add a ppa repository before you can install ffmpeg:
sudo add-apt-repository ppa:samrog131/ppa && sudo apt-get update

You must first add a ppa repository before you can install ffmpeg:
sudo add-apt-repository ppa:samrog131/ppa && sudo apt-get update

You must first add a ppa repository before you can build vdr-plugin-satip:
sudo add-apt-repository ppa:costamagnagianfranco/ettercap-stable-backports && sudo apt-get update

You must first add a ppa repository before you can install ffmpeg:
sudo add-apt-repository ppa:samrog131/ppa && sudo apt-get update

You must first add a ppa repository before you can install xbmc:
sudo add-apt-repository ppa:team-xbmc/ppa && sudo apt-get update

E: Befehlszeilenoption --------------------- konnte nicht ausgewertet werden.
Anm.: In der Ausgabe von 'apt-get install $(make deps)' habe ich ich doppelte Leerzeilen gelöscht.

Die in den Meldungen genannten Archive waren über Einträge in /etc/apt/sources.list.d/* verfügbar. Installiert war keines der Pakete aus diesen Archiven.

Malte

82
Raspberry PI / Problem mit lircd2uinput und python-gobject-2
« on: November 04, 2014, 22:33:58 »
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

83
Entwicklung [ Development ] / Wie kommen die Versionsnummern zustande?
« on: November 04, 2014, 22:20:53 »
Hallo Claus,

vielen Dank für Deine ausführliche Antwort! Vielleicht erklären sich unsere jeweiligen Sichtweisen auf die Versionsnummern aus unterschiedlichen Blickwinkeln. Du hast siehst die gesamte Distribution, die sich aus unterschiedlichen Quellen speist. Ich habe mehr meine Erfahrungen mit Debian-Paketen und -Versionsnummern im Bezug zu Paketentwicklung und -aktualisierung im Hinterkopf. Und ich weiß noch sehr wenig über MLD. Ich bitte deshalb lieber im Vorhinein um Nachsicht, falls ich mal zu keck oder gar anmaßend klingen sollte.

Ich war die letzten zwei Wochen im Urlaub, weshalb ich auf Deine Fragen nicht antworten konnte. Da es hier um tiefergreifende Interna der MLD geht, (und ich mir das System ausgedacht habe) konnten die anderen Entwickler Dir da auch keine tiefergehenden Antworten liefern.
Das geht natürlich garnicht. Da ist wohl ab jetzt eine strikte Urlaubssperre unausweichlich ;). Nein, im Ernst: Umso dankbarer bin ich natürlich, dass Du dich jetzt meiner (und all der anderen) Fragen angenommen hast. Ich hoffe, die Erholung hält eine Weile vor!

- die statisch festgelegten Versionsnummern rühren größtenteils noch aus früheren MLD Versionen, wo es noch keinerlei Bezug zwischen Debian (Ubuntu/Raspian) Paketen und MLD Paketen gab. Die Verwendung der Debian Versionsnummer per dpkg habe ich erst mit der MLD-4 eingeführt. Bei der MLD-3 und früher wurde bestenfalls, wie von Dir bereits entdeckt, die Versionsnummer eines enthaltenen Tools genommen.
Ah, verstehe. Die Projektgeschichte hatte ich nicht im Blick.

Meine Hauptkriterien für Versionsnummern wären vermutlich, dass eine Änderung der Quellen (Upstream oder native) und eine Änderung der Paketierung (Revision) stets zu einer neuen, "höheren" Versionsnummer führt, damit ein eindeutiges Verfahren für Upgrades umgesetzt werden kann. Wünschenswert schiene mir außerdem, dass es für einen Entwickler möglich ist, eigene Paketversionen zu erstellen (lokale Revision), die zwischen der aktuellen und der nächsten "offiziellen" Version liegen. Das klappt z.B. bei Debian recht gut. Bei MLD bin ich mir nicht so sicher. Aber vielleicht passt so ein Ansatz ja auch nicht so gut zu Deinen Vorstellungen, wie MLD funktioniert. Damit kenne ich mich - wie schon eingeräumt - (noch) nicht so gut aus.

- Bei den python Paketen wurde die im Paket enthaltene Python Version (2.7) verwendet. Mir war nicht bewusst, das dies zu Problemen führen könnte. Es wäre aber sicher geschickter hier die volle Version 2.7.3 zu verwenden. Woher Du die 2.28.6-10 bezogen hast, ist mir allerdings nicht klar.
Dieses Teilthema würde ich gerne in den parallelen Thread zu python-gobject-2 auslagern.

- Reine MLD Pakete die auf keinen externen Quellen beruhen verwenden die Versionsnummer 0, da es ja nichts gibt, was eine andere Versionsnummer rechtfertigen würde
Bei MLD-eigenen Paketen vertehe ich das (obwohl 1 vielleicht etwas selbstbewusster klänge als 0  :)). Aber es sind ziemlich viele Pakete dabei (nfs-*, diverse vdr-plugin-*, ...) die auch "nur" eine 0 als Versionsnummer haben und indirekt oder direkt auf externer Software basieren.

- die package_version in den libs Paketen ist nen Sonderfall. Da die libs nur das enthalten, was benötigt wird, und alles andere was sonst noch in den korrespondierenden Debian Paketen enthalten ist weg lassen, brauchen wir hier eine Versionsnummer die erhöt wird, wenn das Paket weitere Libraries hinzubekommt. Zu beachten ist, das diese Pakete komplett zur Compilezeit erstellt werden, und nicht im MLD repository enthalten sind. Da es fast nie vorkommt, dass in einem libs Paket enthaltene libraries entfernt oder durch andere ersetzt werden, funktioniert diese Zählung recht brauchbar. Probleme können allerdings auftreten, wenn ein solches Paket auf einem anderem devel PC gebaut wird, und dort andere libs enthält, die im offiziellen Paket fehlen. Dann muss das Paket manuell auf dem MLD PC eingespielt werden, da dann ja die versionsnummer kleiner sein kann.
Da verstehe ich leider noch vieles nicht. Z.B.: Die libs Pakete sind nicht im Repository enthalten? In einem libs Paket sind mehrere Bibliotheken? Kannst Du mir noch etwas auf die Sprünge helfen? Sonst muss ich mich durch die Makefiles wühlen. Bisher weiß ich eigentlich nur, dass ich ein Paket (python-gobject-2) erstellt habe und ziemlich viele Bibliothekspakete automatisch erstellt wurden ;). Warum mein selbstgebautes libc-Paket eine kleinere Versionsnummer hat als das ältere offizielle, habe ich leider noch nicht verstanden. Sollten die internen Mechanismen das nicht verhindern?

Schönen Gruß
Malte

84
Entwicklung [ Development ] / Wie kommen die Versionsnummern zustande?
« on: November 03, 2014, 22:15:36 »
Hallo skippy,

danke für Deine Ermunterung! Allerdings: Ich habe ja nicht nur meine Erkenntnisse zusammengefasst, sondern auch einige Fragen gestellt, auf die ich bislang leider keine Antwort erhalten habe. In meinem zweiten Thread, in dem es um Probleme beim Erstellen des Moduls python-gobject-2 geht, ist es genauso. Auf etwas mehr Unterstützung hatte schon gehofft.

Ungeachtet dessen möchte ich meinem ursprünglichen Beitrag noch in einem Punkt ergänzen. Für die Ermittlung der Version des Pakets für eine Bibliothek wird in libs/Makefile.libs
Code: [Select]
package_version := $(shell find template -type l | wc -l)
benutzt, also die Anzahl der Verweise im Unterverzeichnis template des Bibliotheksprojektes. Die Idee dahinter verstehe ich noch nicht. Beim Bau des Moduls python-object-2 hatte das bei mir jedenfalls den Effekt, dass mein Paket libc die Versionsnummer 2.13-10 erhielt, obwohl auf dem Zielrechner schon 2.13-11 installiert ist.

85
Raspberry PI / Problem mit lircd2uinput und python-gobject-2
« on: November 03, 2014, 21:41:26 »
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.

86
Mittlerweile weiß ich zumindest ein bisschen mehr darüber, wie die Versionsnummern zustande kommen. Fast alles dazu findet sich in Makefile.default und natürlich in den Makefiles der einzelnen Module. Hier sind meine "Erkenntnisse" als Beitrag zur Diskussion oder gar Dokumentation. Alle Angaben hier beziehen sich auf MLD 4.0.1 für den Raspberry Pi. Für Fehler und Missverständniss möchte ich mich schon im Voraus entschuldigen :-)

Die Versionsnummer wird aus vier Komponenten gebildet:
Code: [Select]
VERSION = $(version_prefix)$(version)$(version_suffix)-$(package_version)Wenn das Modul eine Abhängigkeit besitzt, kann auch die noch in die Versionsnummer eingehen:
Code: [Select]
package_version := $(package_version)_$(depends_version)
Die Variablen version_prefix und version_suffix werden kaum benutzt; derzeit nur von drei bzw. zwei Modulen.

Die Variable package_version ist so etwas wie die Revision in Debian. Allerdings wird sie i.d.R. automatisch gesetzt, und zwar auf die Anzahl der Git Commits im Projekt.

Die Variable version hat standardmäßig den Wert 0. In 59 Modulen wird ihr ein anderer, fester Wert zugewiesen. Erstaunlicherweise ziemlich oft 0 :-). Problematisch ist aus meiner Sicht, dass dieser Wert oft recht willkürlich oder veraltet scheint. Insbesondere dann, wenn man ihn mit der Versionsnummer des zugrundeliegenden Raspbian-Pakets vergleicht (z.B. dbus oder python3).

In 50 Modulen wird eine Version ermittelt. Zum Beispiel dadurch, dass das Modul ein Programm verpackt, das beim Aufruf seine Version liefert. Oder durch einen Aufruf von dpkg, der die Version des zugrundliegenden Raspbian Pakets liefert. Nicht verstanden habe ich, warum alle Python Module (python-*) die Python Versionsnummer (hier: 2.7) benutzen und nicht die Versionsnummer des zugrundeliegenden Pakets. Das bereitet mir z.B. Problem beim Upgrade von python-gobject-2.

In 64 Modulen schließlich werden die Variablen src_url bzw. src_rule gesetzt. Dann kann die aktuelle Version aus dem Quellarchiv abgeleitet werden.

Ein echtes Äquivalent für die Revision in Debian habe ich bislang nicht gefunden. Benutzt man version_suffix, dann landet dessen Wert in der Mitte der Versionsnummer. Die Anzahl der Commits im eigenen Repositoy kollidiert im Zweifel mit dem entsprechenden Wert in der Quelle.

Ich bin ja noch ganz neu in der MLD Entwicklung. Deshalb mag ich manches falsch verstanden haben. Doch zunächst einmal war ich überrascht, weil mir die Versionsnummern nicht sehr aussagekräftig schienen. Ich hatte eigentlich erwartet, dass sie stets eine Kombination aus der Versionsnummer des zugrundeliegenden Raspbian Pakets oder der Modulequelle (natürlich mit der Ausnahme MLD-eigener Module) und einer MLD-internen Zählung sein würden. Im Moment hätte ich die Befürchtung, dass Upgrades nicht immer richtig funktionieren.


87
Raspberry PI / Problem mit lircd2uinput und python-gobject-2
« on: October 31, 2014, 19:31:31 »
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...

88
Hallo,

beim Einrichten einer Fernbedienung bin ich auf Schwierigkeiten mit dem Paket python-gobject-2 gestoßen. Um denen auf den Grund zu gehen, habe ich unter Raspbian Wheezy eine Entwicklungsumgebung eingerichtet und - nach einer Änderung im Makefile - das Paket neu gebaut.

Nun habe ich zwei Fragen zur Version des so erstellten Pakets:
  • Das MLD-Paket hat die Version 2.7-3. Wo kommt diese Versionsnummer her? Die aktuelle Version des Pakets in Raspbian ist 2.28.6-10.
  • Wie kann ich eine eigene Revision angeben, also z.B. 2.7-3maf1?

Danke,
Malte

89
Hallo MegaX,

habe folgendes Ticket erstellt: http://minidvblinux.de/bug/view.php?id=134

Gruß, Malte

90
Hallo MegaX,

ja, das habe ich auch so verstanden.

Mir geht es jetzt darum, dass nach meinem Eindruck die Meldungen auch dann angezeigt werden, wenn das benötigte Repository bereits eingebunden ist. Für mich war das bei der ersten Benutzung der Entwicklungsumgebung ziemlich verwirrend, denn ich dachte zunächst, es handele sich um Fehlermeldungen.

Malte