Verbesserungsvorschläge/Visionen für vdr Ebuild

Hallo,

hier eine Realisierung von emerge-masked, läuft hier seit Jahren Problemlos. (einfach in .bashrc)

alias xmerge='ACCEPT_KEYWORDS="~x86" emerge'

Über die anderen Punkte denke ich noch nach.

gruß thoand

hi,

1. für emerge_masked gibts die /etc/portage/package.keywords! Das ist auch der Weg den wir gehen sollten.
2. Auftrennung, der 2 conf files, hab ich keine Ahnung von, hört sich aber sinnvoll an
3. OK
4. Was für Scripte sind das? Bins gehöre nach /usr/bin oder /usr/sbin, wenn der User nix an den Scripte zu fummeln hat dann evt nach /usr/sbin?! Ob bins im share dir was zu suchen haben weiss ich nicht.

Verbesserungsvorschlag: Mit ner vernünftigen Richtlinie wann und wie können wir die Ebuilds auch "x86" markieren! Muss nur klar sein wann und wie das passiert!

gruss mad

Hi,

zu 1. naja, vielleicht sollte man den User darauf hinweisen wie es geht, ein Script was package.keywords editiert? Fraglich ....
zu 4. in usr/share gehört das definitiv nicht: siehe http://www.pathname.com/fhs/pu…CHITECTUREINDEPENDENTDATA
So ein Binary gehört meines Erachtens nach: http://www.pathname.com/fhs/pu…ESSENTIALSTANDARDSYSTEMBI

gruss mad

ideal wäre wenn portage endlich * könnte, damit man vdrplugin-* in /etc/portage/package.keywords packen kann...

gruß thoand

das ist richtig, mal sehen ob gentoo.org sich rührt.
http://bugs.gentoo.org/show_bug.cgi?id=91708

gruss mad

Hu,

zu 3: ja, sieht gut aus.
zu 5: hm, was muss in die sudousers rein, was für unterschiedliche sachen? Oder immer das Gleiche? Allerdings hab ich auf die schnelle keine Möglichkeit gefunden "visudo" zu scripten!

gruss mad

Hallo,

zu 5. mindestens die Sachen die in /usr/bin/vdrshutdown.sh drin stehen sollten/müssen in der sudoers enthalten sein.
Dann auch gleich per abfrage welcher Bootmanager installiert ist, dem entsprechend die richtigen Sachen eintragen.
Da gibt es Unterschiede zw. Grub und Lilo
Das kann dann als Grundlage genommen werden um darauf z.B. vdrconvert/dvdconvert lauffähig zu machen, welche teilweise auch mit sudo arbeiten.

Zur Frage wann x86 oder ~x86 eingestellt werden sollte/könnte.
Ich möchte mich da nocheinmal wiederholen wie das auf gentoo.org gehandhabt wird.
ebuild's sollten min. 4 Wochen ohne Bugreport sein, die letzte Enscheidung liegt in der Hand des jeweiligen Dev's.

Als gute Grundlage könnte man IMHO zum jetzigen Zeitpunkt sagen dass das vdr-1.3.22.ebuild als stabil anzusehen ist.
Ab der Version 1.3.23 hat KLS schon wieder so viele interne Änderungen vorgenommen das einen Menge Plugins nicht um patcherei herumkommen um lauffähig zu sein.
Also vdr-1.3.22 und die jetzigen lauffähigen plugins x86.
Folgeversionen der Plugins die gepacht werden müssen, ~x86.
Cheers

JörG

Zitat

Original von hd.brummy
Zur Frage wann x86 oder ~x86 eingestellt werden sollte/könnte.
Ich möchte mich da nocheinmal wiederholen wie das auf gentoo.org gehandhabt wird.
ebuild's sollten min. 4 Wochen ohne Bugreport sein, die letzte Enscheidung liegt in der Hand des jeweiligen Dev's.

[...]
Also vdr-1.3.22 und die jetzigen lauffähigen plugins x86.
Folgeversionen der Plugins die gepacht werden müssen, ~x86.

Alles anzeigen

Die Plugins dazu sind aber ein eigenes Thema. Bis jetzt ist die Kontrolle der richtigen Version eher nicht gepflegt worden, denn wenn vdrplugin-xyz-0.3 auf vdr-1.3.21 funkt, aber unter 1.3.22 nicht mehr, sollte aus dem DEPEND=">=media-video/vdr-1.3.21" ein =media-.... im 0.3er ebuild werden. Damit man nicht bei einem vdr-Update ein Plugin verwendet, das für z.B. 22 nicht mehr funkt. Als Beispiel sei hier mal streamdev angegeben. Es gibt ja hier im Board genügend Leute, die posten(meist im Announce-Thread der "neuen vdr-Version", bzw in den "vdr-1.3.xx +Plugins +Patches"-Thread), was alles nimma geht, und dort sollte der ebuild entsprechend angepaßt werden.

@ Sun2Earth

So sehe ich das ja auch, und so steht es ja auch da

[Zitat]
und die jetzigen lauffähigen plugins x86
[/Zitat]

Soll ja auch kein Rundumschlag werden.
Es bedarf da natürlich jeweils der Einzelfall Prüfung.

ich wäre dafür, daß man USE="unicode" unterstützt und dann http://vdrportal.de/board/thread.php?postid=301802 anwendet.

gruß thoand

Zitat

Original von thoand
ich wäre dafür, daß man USE="unicode" unterstützt und dann http://vdrportal.de/board/thread.php?postid=301802 anwendet.

gruß thoand

Ich bin grad dabei ein ebuild für den 1.3.24 zu bauen, wo das dann auch drin ist. Die neuste Version des utf patches (0.0.3) ist eh für den 1.3.24. Ich muss noch die gängigsten plugins testen (vdr-reemerge-plugins läuft gerade). Der vdr selber funktioniert schonmal inkl. Komplettpatch. Wenn alles zu meiner Zufriedenheit läuft werd ich das ganze auf bugs.gentoo.de bereitstellen.

Gruß
Lars

Hallo zusammen,

schön wäre die Funktionalität einens optionalen regelmäßigen Aufwachtimers, der täglich um x Uhr den Rechner startet, damit epg-scan etc. durchgeführt werden kann.
Implementierung bei mir bisher:
Ich prüfe bei mir im shutdown-script, ob der nächste timer erst nach 03:00 Uhr am nächsten Tag liegt. Wenn ja, dann stelle die neue Aufwachzeit mittels nvram-wakeup auf 03:00 Uhr. Um 03:05 starte ich den epg-scan mittels svdrpsend.sh und um 03:15 fährt er ebenfalls mit svdrpsend.sh POWER wieder herunter.

Gruß,
Dieter

EDIT: Aufwachtimer ist das falsche Wort. Besser: regelmäßige Aufwachzeit

Zitat

Wie wäre es mit einem Timer (MDMDFSS 00:03-00:04), auf den ist meist mehr Verlass?

Hi Ronny,

der Timer hat den Nachteil, daß täglich eine Dummy-Aufnahme hinzukommt, die dann irgendwie wieder entsorgt werden muß (z.B. in ein separates Verzeichnis stellen und regelmäßig löschen).
Außerdem fährt der Rechner ja sofort nach der Aufnahme wieder herunter, da keine Benutzerinteraktion stattgefunden hat. Somit ist auch keine Zeit für einen epg-scan. Während die Aufnahme läuft geht kein epg-scan (da ich nur ein 1-Karten-System habe) und danach ist der Rechner wieder aus.
In der von mir vorgeschlagenen Vorgehensweise wartet er, bis der eingestellte timeout für Benutzerinaktivität zuschlägt bzw. bis er - wie ich beschrieben habe - per svdrpsend.sh POWER scriptgesteuert ausgeschaltet wird.
Die von dir beschrieben Lösung hatte ich längere Zeit am Laufen, aber so wie es jetzt ist finde ich es deutlich pflegeleichter.

Gruß,
Dieter