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

16
Ansonsten schreib doch mal dein Patch hier rein, oder schick uns den zu. Dann schauen wir es uns an.

Ich habe meinen Patch in einem eigenen Thread zur Diskussion gestellt.

17
Entwicklung [ Development ] / Patch für Plugin svdrpservice
« on: June 19, 2019, 12:28:12 »
Vor einem guten Jahr habe ich über Probleme im OSD bei der Kommunikation zwischen Client und Server berichtet. Zum Beispiel ließ sich ein Timer auf dem Server nicht (de)aktivieren. Damals ging es noch um MLD 5.0. Doch nach dem Wechsel zu MLD 5.3 musste ich feststellen, das die Probleme weiterhin bestehen.

Zunächst dachte ich, es läge am Plugin remotetimers. Mittlerweile weiß ich, dass das Plugin svdrpservice den Fehler verursacht. Damit betrifft er viele Plugins auf dem Client, die mit dem Server kommunizieren, und dürfte auch für MLD 5.4 interessant sein, in dem wegen des Wechsels zu VDR 2.4.0 das Plugin remotetimers nicht mehr benötigt wird.

Ursache der Kommunikationsprobleme ist, dass der Server recht zügig die SVDRP-Verbindung beendet, wenn der Client sich nicht mehr meldet, und dem Client eine entsprechende Nachricht schickt. Der Client ignoriert jedoch den Timeout und hält fälscherweise die Nachricht des Servers (bzw. deren Reply Code) für die Antwort auf seine nächste Anfrage, ohne diese überhaupt abgeschickt zu haben.

Mit folgendem Patch server-timeout.patch habe ich das Problem für mich gelöst:
Code: [Select]
--- a/connection.c
+++ b/connection.c
@@ -192,7 +192,7 @@
        if (!Cmd)
                return false;

-       if (Reconnect && !file.IsOpen())
+       if (Reconnect && (!file.IsOpen() || ReceivedTimeout()))
                Open();
        if (!file.IsOpen()) {
                esyslog("svdrpservice: unable to send command to %s. Socket is closed", serverIp);
@@ -240,6 +240,18 @@
        return 0;
 }

+bool cSvdrpConnection::ReceivedTimeout() {
+       if (file.Ready() && ReadLine(0)) {
+               long int code = ::strtol(buffer, NULL, 10);
+               if (code != 221) {
+                        esyslog("svdrpservice: unexpected message from %s: '%s'", serverIp, buffer);
+               }
+               file.Close();
+               return true;
+       }
+       return false;
+}
+
 bool cSvdrpConnection::ReadLine(int TimeoutMs) {
        if (!file.IsOpen())
                return false;
--- a/connection.h
+++ b/connection.h
@@ -26,6 +26,7 @@
                bool            shared;

                int             Connect();
+               bool            ReceivedTimeout();
                bool            ReadLine(int TimeoutMs);
        public:
                cSvdrpConnection(const char *ServerIp, unsigned short ServerPort, bool Shared);

Ich würde mich freuen, wenn das MLD Team den Patch testen und im Erfolgsfall eine neue Version des Plugins für MLD 5.3 (und MLD 5.4) bereitstellen könnte

18
Wenn Du die Sourcen des Plugins mit eincheckst, dann müssen da drin bereits alle Patches angewendet sein. Wenn Du trotzdem Patches dazu packst, dann dient das lediglich der Dokumentation.
Normalerweise checken wir die Sourcen nicht mit ein. Das wird nur bei einigen wenigen Plugins gemacht, bei denen die Sourcen nicht zuverlässig verfügbar sind, oder nicht unter einer festen URL abrufbar sind.

Verstanden. Dann habe ich bei vdr-plugin-svdrpservice einfach nur "Pech gehabt", ein Plugin mit eingecheckten Sourcen zu erwischen.

19
Ich habe nun doch Docker auf einem Raspberry Pi 3 unter Raspbian Stretch benutzt, um eine Enwicklungsumgebung für MLD 5.3 aufzubauen. Dazu benutze ich drei Dateien. Mit raspbian-jessie.Dockerfile wird ein Image für Jessie erstellt:
Code: [Select]
FROM arm32v7/debian:jessie
MAINTAINER MLD Team <team@minidvblinux.de>

ARG DEBIAN_FRONTEND=noninteractive

# Add Raspbian repositories
RUN apt-get update \
 && apt-get install -y wget \
 && wget -O - -q https://archive.raspbian.org/raspbian.public.key | apt-key add - \
 && echo 'deb http://raspbian.raspberrypi.org/raspbian/ jessie main' \
    > /etc/apt/sources.list.d/raspbian.list \
 && wget -O - -q https://archive.raspberrypi.org/debian/raspberrypi.gpg.key | apt-key add - \
 && echo 'deb http://archive.raspberrypi.org/debian/ jessie main ui' \
    >> /etc/apt/sources.list.d/raspbian.list

# Update and upgrade
RUN apt-get update \
 && apt-get dist-upgrade -y

Mit mld53-rpi.Dockerfile wird basierend auf dem Image mit Jessie ein Image für eine Entwicklungsumgebung für MLD 5.3 erstellt:
Code: [Select]
FROM maf/raspbian:jessie
MAINTAINER MLD Team <team@minidvblinux.de>

ARG DEBIAN_FRONTEND=noninteractive

# Update und benötigte Pakete installieren
RUN apt-get update \
 && apt-get dist-upgrade -y \
 && apt-get install -y \
    make git-core software-properties-common locales locales-all g++

# MLD Pakete holen und auf Version 5.3 umstellen
COPY Makefile.adjust /tmp/Makefile.adjust
RUN git clone http://minidvblinux.de/git-5/MLD.git MLD \
 && cd MLD \
 && echo ".SILENT:\nCLASS = stable" > Makefile.config \
 && git checkout 5.3 \
 && cat /tmp/Makefile.adjust >> Makefile.git \
 && rm /tmp/Makefile.adjust \
 && make checkout_base \
 && make adjust_version_all

# Abhängigkeiten der MLD Pakete installieren
RUN cd MLD \
 && apt-get install -y $(make deps)

# Platz freigeben
RUN apt-get autoremove -y \
 && apt-get autoclean -y

In das Image für MLD 5.3 geht noch die Datei Makefile.adjust ein:
Code: [Select]

# Version aller Module an Version von MLD anpassen
adjust_version_all:
        ls | while read package; do \
                if [ -e "$$package/.git" ]; then \
                        echo -e "$(color_green)$$package$(color_reset)"; \
                        $(MAKE) adjust_version name=$$package; \
                fi; \
        done

# Version eines Moduls an Version von MLD anpassen
adjust_version:
        if [ -e "$(name)/.git" ]; then \
                git -C $(name) rm --force --cached --ignore-unmatch .gitignore; \
                git -C $(name) checkout --force $$(git -C $(name) rev-list -n 1 --first-parent --before=$$(git log -1 --format='%at') master) &>/dev/null; \
        else \
                echo -e "$(color_red)unknown package $(name)$(color_reset)"; \
        fi
Die beiden Ziele in diesem Makefile werden an Makefile.git angefügt. Mit
Code: [Select]
make checkout_all; make adjust_version_all bzw.
Code: [Select]
make checkout name=PACKAGENAME; make adjust_version name=PACKAGENAME können dann alle oder ein einzelnes Paket auf den Versionsstand von MLD 5.3 zurückgesetzt werden. Dazu wird das letzte Commit eines Pakets vor dem aktuellen Commit von MLD ausgecheckt.

20
Danke für Deine Hinweise.

Die Regel in Makefile.plugin sieht eigentlich vielversprechend aus:
Code: [Select]
src/$(pluginname)-%:
        if [ -n "$(src_url)" ]; then \
                $(MAKE) -f ../Makefile.getfile file=src/$(name).tgz version=$(version) url='$(src_url)'; \
        else \
                $(MAKE) -f ../Makefile.getfile file=src/$(name).tgz version=$(version) rule='$(src_rule)'; \
        fi
        rm -rf $@ $@-src
        mkdir -p $@-src
        tar xf src/$(name).tgz -C $@-src
        mv $@-src/* $@
        rm -r $@-src
        ln -fns $(@F) src/$(pluginname)
        $(MAKE) patch src_path=$@ src_name=_$(pluginname)_
Aber das Verzeichnis src/$(pluginname)-% wird bereits im Zuge von 'make checkout' angelegt, die Regel deshalb nie angewandt.

Ich habe es deshalb mit
Code: [Select]
make patch src_path=$PWD/src/PACKAGENAME-PACKAGEVERSIONversucht. Das funktioniert zwar, sieht aber nicht wie die "richtige" Lösung aus.

Ich suche also immer noch nach allgemeingültigen Vorgehensweise: Wie kann man dafür sorgen, dass ein Patch, den man nach dem 'make checkout' in das Verzeichnis src kopiert, beim Erstellen des Pakets angewandt wird?

21
Danke

22
Ich habe einen Patch, den ich zuvor unter yaVDR für ein Plugin erstellt hatte, in das Unterverzeichnis src des Pakets kopiert, das ich erstellen möchte. Der Name der Patch-Datei enthält den Namen des Pakets und endet mit '.patch'. Bei
Code: [Select]
cd PACKAGENAME; make allein wird der Patch allerdings nicht angewandt. Auch bei
Code: [Select]
cd PACKAGENAME; make patch nicht. Was muss ich tun, damit ein Patch bei der Paketerstellung angewandt wird?

23
Es wird zwar (per Voreinstellung) Dein Benutzername zur Versionsnummer hinzugefügt, jedoch kannst Du die Versionsnummer nicht direkt beeinflussen.
Ein Commit würde ich gerne erst ausführen, wenn ich meinen Patch getestet habe.

Ich habe zwar irgendwo gelesen, dass beim ersten Aufruf von make ein paar Daten wie z.B. der Name und Email-Adresse abgefragt würden, doch ist das nie passiert.

Was genau willst Du damit bezwecken?
Ich würde gerne eine eindeutige Versionsnummer vergeben, die das lokale Paket leicht als meine eigene Version erkennbar macht, "größer" ist als die aktuelle offizielle Version und "kleiner" als die nächste offizielle Version.

Wenn Du und ich unabhängig voneinander durch jeweils ein Commit eine Änderung an einem Paket vornähmen, erhielten sie beide dieselbe Versionsnummer, auch wenn es sich um unterschiedliche Versionen handelte, falls es nur nach der Anzahl der Commits geht.

Nachtrag: ich habe gerade erst bemerkt, dass das lokal erstellte Paket eine andere Version hat (vdr-plugin-svdrpservice_1.0.0-7+2.2.0.213.8+root_armhf) als das im Repository (1.0.0-7+2.2.0.213.8). Für Tests reicht das natürlich.

24
Kann ich auch irgendwie einen eigenen Zusatz, z.B. "+maf1", in der Versionsnummer unterbringe?

25
Hallo,

was muss ich tun, um in einer Entwicklungsumgebung für MLD 5.3 eine lokale Versionsnummer (im Debian-Jargon eigentlich eine neue Revision) für meine eigene Variante eines Pakets zu vergeben?

Danke, maf

26
Wie kann ich herausfinden, welche Pakete (Tools, Bibliotheken) über den Standardumfang von Raspbian hinaus für einen kompletten Build erforderlich sind?

Würde
Code: [Select]
make checkout_all
make deps
eine vollständige Liste liefern?

27
Ich habe mich entschieden, mein Glück mit der "vereinfachten" Prozedur auf einem RPi unter Raspbian Jessie zu versuchen. Und ich will gerne berichten, ob das funktioniert hat.

Eine Frage noch vorab: Wie groß sollte die SD-Karte sein, wenn ich für alle Fälle - d.h. einen kompletten Build - gewappnet sein will? Reichen 32 GB? Oder reichen sogar16 GB?

28
Der letzte Vorschlag dürfte der vielversprechendste sein.
Sind denn aus Deiner Sicht die einzelnen Aufrufe von make in Ordnung, oder habe ich was ausgelassen?

Allerdings glaube ich nicht, dass Du für Debian Jessie aalle Pakete in den passenden Versionen bekommst. Da gab esja inzwischen auch diverse Updates die Möglichwerweise nicht mehr MLD-5.3 kompatibel sind.
Ich vermute, Du meinst Raspbian Jessie? Was die Versionen betrifft: Mit Kompatibilitätsproblemen hast Du sicherlich mehr Erfahrung als ich. Ich hätte gehofft, dass es keine Schwierigkeiten geben sollte, solange ich "nur" Programme oder Bibliotheken erstelle, die Shared Libraries benutzen. Unter Debian zumindest habe ich noch nie Konflikte erlebt zwischen "alten" Programmen, die Bestandteil der Distribution (wie Jessie) waren, und "neuen" Programmen, die ich kurz vor Ende der Lebensdauer der Distribution erstellt habe. Was könnte Deiner Erfahrung nach schief gehen?

Warum willst Du überhaupt die 5.3 nehmen und nicht die 5.4?
Mein Server läuft unter Debian Stretch, d.h. mit VDR 2.2.0. Auf einem Client mit MLD 5.4 hätte ich kein Plugin remotetimers mehr zur Verfügung. Und noch scheue ich davor zurück, eTobis Pakete für VDR 2.4.0 zu installieren. Denn dann müsste ich eine ganze Reihe von Plugins neu bauen und hoffen, das sie auch mit VDR 2.4.0 kompatibel sind.

29
Danke für die Erklärung.

Wenn ich Dich richtig verstehe, habe ich keine realistische Chance, ein einzelnes Paket zu erstellen. Wäre dann folgende Vorgehensweise erfolgversprechend, um einen Patch für eine Paket für MLD 5.3 zu testen:
  • RPi mit Raspbian Jessie aufsetzen,
  • Entwicklungsumgebung aufsetzen und initialisieren wie in Einführung in den Bau der MLD 5.4 beschrieben, allerdings wo angebracht 5.4 durch 5.3 ersetzen,
  • make checkout_all
  • in allen Git-Repositorys die letzte Version auschecken, die vor dem Commit für MLD 5.3 eingecheckt wurde,
  • meinen Patch im fraglichen Paket ablegen,
  • nochmal apt-get install -y $(make deps)?
  • make all
  • (sehr geduldig sein)

Sollte ich es noch einmal mit Docker versuchen wollen, dann statt der beiden ersten Schritte oben
  • unter Raspbian ein Docker Image von arm32v7/debian:jessie ableiten,
  • Entwicklungsumgebung aufsetzen und initialisieren wie in Einführung in den Bau der MLD 5.4 beschrieben, allerdings wo angebracht 5.4 durch 5.3 ersetzen,
  • Raspbian-spezifische Paketquellen wie im Forum beschrieben und zugehörige Schlüssel für APT ergänzen,
  • zusätzliche Pakete installieren, zumindest soweit bislang bekannt (wget, g++, gnupg, ...),

Wie lange dürfte es auf einem RPi 3 dauern, alle Pakete zu erstellen?

Oder ist doch eine Vereinfachung möglich, z.B.:
  • (Entwicklungsumgebung einrichten wie oben),
  • make all (nach dem checkout_base, d.h. nur für bereits vorhandenen Pakete)
  • checkout für vdr und das eine Plugin
  • meinen Patch im Plugin-Paket ablegen,
  • nochmal apt-get install -y $(make deps)?
  • make all
  • (etwas weniger geduldig sein)

30
Ok, wer lesen kann, ist klar im Vorteil...

Mittlerweile weiß ich, dass ich beim checkout den Namen des Pakets als Parameter angeben muss:
Code: [Select]
root@1d8928adab15:/MLD# make checkout name=vdr-plugin-svdrpservice
Cloning into 'vdr-plugin-svdrpservice'...

Leider läuft beim nächsten Schritt noch etwas schief:
Code: [Select]
root@1d8928adab15:/MLD# cd vdr-plugin-svdrpservice/
root@1d8928adab15:/MLD/vdr-plugin-svdrpservice# make
Makefile:1: ../vdr/Makefile.plugin: No such file or directory
make: *** No rule to make target '../vdr/Makefile.plugin'.  Stop.

Also zunächst
Code: [Select]
root@1d8928adab15:/MLD# make checkout name=vdr
Cloning into 'vdr'...

Beim erneuten make im Verzeichnes des Plugins fehlen zunächst wget
Code: [Select]
root@1d8928adab15:/MLD/vdr-plugin-svdrpservice# make
/bin/sh: 1: wget: not found
/bin/sh: 1: wget: not found
/bin/sh: 1: wget: not found
/bin/sh: 4: wget: not found
../Makefile.getfile:18: recipe for target 'src/vdr.bz2' failed
make[2]: *** [src/vdr.bz2] Error 1
Makefile:47: recipe for target 'src/vdr.bz2' failed
make[1]: *** [src/vdr.bz2] Error 2
../vdr/Makefile.plugin:59: recipe for target '../vdr/src/vdr/config.h' failed
make: *** [../vdr/src/vdr/config.h] Error 2
und dann g++
Code: [Select]
root@1d8928adab15:/MLD/vdr-plugin-svdrpservice# make
--2019-06-11 12:22:02--  ftp://ftp.tvdr.de/vdr/vdr-2.4.0.tar.bz2
           => '/root/.cache/mld//vdr-2.4.0.bz2'
Resolving ftp.tvdr.de (ftp.tvdr.de)... 88.198.76.220
Connecting to ftp.tvdr.de (ftp.tvdr.de)|88.198.76.220|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD (1) /vdr ... done.
==> SIZE vdr-2.4.0.tar.bz2 ... 939441
==> PASV ... done.    ==> RETR vdr-2.4.0.tar.bz2 ... done.
Length: 939441 (917K) (unauthoritative)

vdr-2.4.0.tar.bz2   100%[===================>] 917.42K  4.59MB/s    in 0.2s

2019-06-11 12:22:03 (4.59 MB/s) - '/root/.cache/mld//vdr-2.4.0.bz2' saved [939441]
...
  vdr-plugin-svdrpservice:
Failed to open '../../../vdr.pc': No such file or directory
No package '../../../vdr.pc' found
Failed to open '../../../vdr.pc': No such file or directory
No package '../../../vdr.pc' found
Failed to open '../../../vdr.pc': No such file or directory
No package '../../../vdr.pc' found
Failed to open '../../../vdr.pc': No such file or directory
No package '../../../vdr.pc' found
Failed to open '../../../vdr.pc': No such file or directory
No package '../../../vdr.pc' found
Failed to open '../../../vdr.pc': No such file or directory
No package '../../../vdr.pc' found
Failed to open '../../../vdr.pc': No such file or directory
No package '../../../vdr.pc' found
/bin/sh: 1: g++: not found
Failed to open '../../../vdr.pc': No such file or directory
No package '../../../vdr.pc' found
Failed to open '../../../vdr.pc': No such file or directory
No package '../../../vdr.pc' found
Package freetype2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `freetype2.pc'
to the PKG_CONFIG_PATH environment variable
No package 'freetype2' found
Package fontconfig was not found in the pkg-config search path.
Perhaps you should add the directory containing `fontconfig.pc'
to the PKG_CONFIG_PATH environment variable
No package 'fontconfig' found
/bin/sh: 1: g++: not found
make[3]: *** Deleting file '.dependencies'

*** Plugin svdrpservice:
/bin/sh: 1: g++: not found
make[4]: g++: Command not found
Makefile:74: recipe for target 'svdrpservice.o' failed
make[4]: *** [svdrpservice.o] Error 127

*** failed plugins: svdrpservice

Makefile:229: recipe for target 'plugins' failed
make[3]: *** [plugins] Error 1
../vdr/Makefile.plugin:49: recipe for target 'src/svdrpservice/libvdr-svdrpservice.so' failed
make[2]: *** [src/svdrpservice/libvdr-svdrpservice.so] Error 2
grep: ../broken_packages.lst: No such file or directory

Mit wget und g++:
Code: [Select]
root@1d8928adab15:/MLD/vdr-plugin-svdrpservice# make
  vdr-plugin-svdrpservice:
Package freetype2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `freetype2.pc'
to the PKG_CONFIG_PATH environment variable
No package 'freetype2' found
Package fontconfig was not found in the pkg-config search path.
Perhaps you should add the directory containing `fontconfig.pc'
to the PKG_CONFIG_PATH environment variable
No package 'fontconfig' found
font.c:19:10: error: #include expects "FILENAME" or <FILENAME>
 #include FT_FREETYPE_H
          ^~~~~~~~~~~~~
make[3]: *** Deleting file '.dependencies'

*** Plugin svdrpservice:
po/it_IT.po:8: warning: header field 'Language' still has the initial default value
po/sk_SK.po:7: warning: header field 'Language' still has the initial default value
po/de_DE.po:8: warning: header field 'Language' still has the initial default value
find: '../vdr/src/vdr/locale': No such file or directory
    Build package: vdr-plugin-svdrpservice
Das für vdr benötigtes Debian Paket libjpeg-dev fehlt.
Das für vdr benötigtes Debian Paket libcap-dev fehlt.
Das für vdr benötigtes Debian Paket libfontconfig1-dev fehlt.
Das für vdr benötigtes Debian Paket libtinyxml-dev fehlt.
Das für vdr benötigtes Debian Paket libglibmm-2.4-dev fehlt.
Sie können es durch folgende Eingabe installieren:
sudo apt-get install libjpeg-dev libcap-dev libfontconfig1-dev libtinyxml-dev libglibmm-2.4-dev

../Makefile.tools:688: recipe for target 'dep' failed
make[5]: *** [dep] Error 1
        Build vdr-plugin-svdrpservice...
          Füge Abhängigkeit hinzu: libstdc++6
            Benötigt von: /data/usr/lib/vdr/libvdr-svdrpservice.so.2.4.0
          Create lib package libstdc++6
          Add lib /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 to package libstdc++6
          Füge Abhängigkeit hinzu: libc6
            Benötigt von: /data/usr/lib/vdr/libvdr-svdrpservice.so.2.4.0
          Create lib package libc6
          Add lib /lib/arm-linux-gnueabihf/libm.so.6 to package libc6
          Füge Abhängigkeit hinzu: libgcc1
            Benötigt von: /data/usr/lib/vdr/libvdr-svdrpservice.so.2.4.0
          Create lib package libgcc1
          Add lib /lib/arm-linux-gnueabihf/libgcc_s.so.1 to package libgcc1
          Add lib /lib/arm-linux-gnueabihf/libc.so.6 to package libc6
        libstdc++6:
          Build package: libstdc++6
          Füge Abhängigkeit hinzu: libc6
            Benötigt von: /data/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22
          Füge Abhängigkeit hinzu: libgcc1
            Benötigt von: /data/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22
        libc6:
          Build package: libc6
        libgcc1:
          Build package: libgcc1
          Füge Abhängigkeit hinzu: libc6
            Benötigt von: /data/lib/arm-linux-gnueabihf/libgcc_s.so.1

Ergebnis:
Code: [Select]
root@1d8928adab15:/MLD/vdr-plugin-svdrpservice# ls -l
total 32
-rw-r--r-- 1 root root  109 Jun 11 12:08 Makefile
-rw-r--r-- 1 root root   74 Jun 11 12:20 Makefile.version
drwxr-xr-x 2 root root 4096 Jun 11 12:08 control
-rw-r--r-- 1 root root   29 Jun 11 12:26 depends
drwxr-xr-x 4 root root 4096 Jun 11 12:26 package
lrwxrwxrwx 1 root root   69 Jun 11 12:26 package.deb -> ../.packages/vdr-plugin-svdrpservice_1.0.0-7+2.4.0.218+root_armhf.deb
drwxr-xr-x 3 root root 4096 Jun 11 12:08 src
drwxr-xr-x 4 root root 4096 Jun 11 12:08 template

Darf ich denn trotz all der Warnungen und Fehlermeldungen, der fehlenden Bibliotheken und Verzeichnisse dem Paket vertrauen?

Aber vor allem: Da habe ich ja offensichtlich ein Plugin für VDR 2.4.0 gebaut. Und in MLD 5.3 läuft doch VDR 2.2.0, oder?

Die Entwicklungsumgebung ist auf Stand 5.3:
Code: [Select]
root@1d8928adab15:/MLD# git status
HEAD detached at 5.3
nothing to commit, working tree clean

Trotzdem wurde für vdr beim make das Archiv für Version 2.4.0 heruntergeladen. Wie kann ich erreichen, dass das Archiv für Version 2.2.0 heruntergeladen wird?