http://lists.debian.org/debian-devel-announce/2013/09/msg00006.html hat geschrieben:Auto-removals
=============
As we announced, we are going to start automatic removals from testing
of some RC buggy packages, to help lower the number of outstanding RC
bugs which affect the jessie release. We would like to emphasise that
we obviously prefer to have fixes for the outstanding RC bugs, and
that (auto)removing packages is only used as a last resort.
Packages which have RC bugs that are present in both testing and
unstable, and which have no recent activity (currently this means no
activity in the last 14 days) will be checked for removal.
If the packages are on the list of "key packages"[KEY-PACKAGES], they
will be excluded from automatic removal. Also packages which have
reverse (build-)dependencies in testing, will currently also be
excluded from automatic removal.
Should your package suffer from an RC bug which needs more time to get
fixed, the specific bug can be temporarily whitelisted. Please file a
bug against release.debian.org with an explanation for the delay;
these exceptions will granted on a case-by-case basis.
For packages which are marked for autoremoval 10 days in a row,
removal hints will be added. These packages will usually be removed
from testing fairly soon after that. You can see if any of your
packages might be candidates for removals at [AUTO-RM-CANDIDIATES].
We activated the auto-removals at the time of this announcement,
however until the 2013-10-15, the usual autoremoval delay of 10 days
will be extended to 15 days, so you have some time to fix any
outstanding issues.
If packages get autoremoved from testing, they can get back in when
the RC bugs are fixed, using the same rules that apply to other
packages. In most cases, this means that the fix can get back into
testing after the usual 10-day waiting period.
Please note that packages which are excluded from automatic removal
could still be manually removed from testing.
We would like to thank Ivo De Decker writing the actual implementation
for finding these auto-removable packages.
Niels, on behalf of the Release Team.
[KEY-PACKAGES]
http://udd.debian.org/cgi-bin/key_packages.yaml.cgi
[AUTO-RM-CANDIDATES]
http://udd.debian.org/cgi-bin/autoremovals.cgi
"dd-list"-like of packages considered for auto removals.
For automatic processing, use
http://udd.debian.org/cgi-bin/autoremovals.yaml.cgi
Automatic removal of packages from testing
Automatic removal of packages from testing
Da bin ich mal gespannt wie sich das auswirkt.
Unix is user-friendly; it's just picky about who its friends are.
Re: Automatic removal of packages from testing
Ich hoffe ja, daß popularity-contest da eine gewisse Tendenz verursacht,... your package ...
"mein" Paket nicht rausfliegen zu lassen.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
- MrGerardCruiz
- Beiträge: 905
- Registriert: 21.08.2013 12:19:35
- Lizenz eigener Beiträge: MIT Lizenz
-
Kontaktdaten:
Re: Automatic removal of packages from testing
Also manchmal fragt man sich echt, was die da machen. Das würde mein halbes System über den Jordan jagen. So langsam überlege ich wirklich mit 13.10 auf Kubuntu zu migrieren.
http://www.curius.de - Ein paar pragmatische Gedanken zu Linux, KDE und Datenschutz
Re: Automatic removal of packages from testing
Dann nutze doch einfach kein Testing. Der Name hat schon seine Bedeutung.
Außerdem frage ich mich, wie dein System so läuft, wenn es zur Hälfte aus kaputten Paketen besteht.
Außerdem frage ich mich, wie dein System so läuft, wenn es zur Hälfte aus kaputten Paketen besteht.
- KBDCALLS
- Moderator
- Beiträge: 22365
- Registriert: 24.12.2003 21:26:55
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Dortmund
-
Kontaktdaten:
Re: Automatic removal of packages from testing
Es ist ja eine Frage der Definition was man als kaputt ansieht.
Was haben Windows und ein Uboot gemeinsam?
Kaum macht man ein Fenster auf, gehen die Probleme los.
EDV ist die Abkürzung für: Ende der Vernunft
Bevor du einen Beitrag postest:
Kaum macht man ein Fenster auf, gehen die Probleme los.
EDV ist die Abkürzung für: Ende der Vernunft
Bevor du einen Beitrag postest:
- Kennst du unsere Verhaltensregeln
- Lange Codezeilen/Logs gehören nach NoPaste, in Deinen Beitrag dann der passende Link dazu.
Re: Automatic removal of packages from testing
Urlaube von mehr als drei Wochen Länge sind also ab nächster Woche für Debian-Maintainer gestrichen?Packages which have RC bugs that are present in both testing and
unstable, and which have no recent activity (currently this means no
activity in the last 14 days) will be checked for removal.
[..]
For packages which are marked for autoremoval 10 days in a row,
removal hints will be added. These packages will usually be removed
from testing fairly soon after that.
xxxterm (718074) würde mir fehlen ... also langfristig ... so ab Jessie-Release.
- MrGerardCruiz
- Beiträge: 905
- Registriert: 21.08.2013 12:19:35
- Lizenz eigener Beiträge: MIT Lizenz
-
Kontaktdaten:
Re: Automatic removal of packages from testing
Nur weil es in den Paketen angeblich RC Bugs gibt, heißt das nicht, dass jeder davon betroffen wäre. Von einem Verlust der Pakete in testing wäre aber jeder betroffen.Radfahrer hat geschrieben:Dann nutze doch einfach kein Testing. Der Name hat schon seine Bedeutung.
Außerdem frage ich mich, wie dein System so läuft, wenn es zur Hälfte aus kaputten Paketen besteht.
http://www.curius.de - Ein paar pragmatische Gedanken zu Linux, KDE und Datenschutz
Re: Automatic removal of packages from testing
Nein, davon wären nur die betroffen, die Testing nutzen. Nicht jeder.
Wie gesagt, wenn man Testing nutzt, muss man wissen, worauf man sich einlässt. Dieser Zweig ist zum Testen da. Deswegen heißt das so. Wer also nicht testen will, Fehler suchen will und Bug-Reports schreiben will, sollte es nicht nutzen. Punkt.
Wie gesagt, wenn man Testing nutzt, muss man wissen, worauf man sich einlässt. Dieser Zweig ist zum Testen da. Deswegen heißt das so. Wer also nicht testen will, Fehler suchen will und Bug-Reports schreiben will, sollte es nicht nutzen. Punkt.
- MrGerardCruiz
- Beiträge: 905
- Registriert: 21.08.2013 12:19:35
- Lizenz eigener Beiträge: MIT Lizenz
-
Kontaktdaten:
Re: Automatic removal of packages from testing
Sinnfragen hast du dir noch nicht gestellt oder? Der Jessie Release ist meilenweit entfernt, welchen positiven Effekt hat das Rauswerfen von Paketen jetzt aus Testing?Radfahrer hat geschrieben:Nein, davon wären nur die betroffen, die Testing nutzen. Nicht jeder.
Wie gesagt, wenn man Testing nutzt, muss man wissen, worauf man sich einlässt. Dieser Zweig ist zum Testen da. Deswegen heißt das so. Wer also nicht testen will, Fehler suchen will und Bug-Reports schreiben will, sollte es nicht nutzen. Punkt.
http://www.curius.de - Ein paar pragmatische Gedanken zu Linux, KDE und Datenschutz
Re: Automatic removal of packages from testing
Vielleicht den, dass die Softwareentwickler mal ein bisschen Gas geben, damit ihr Kram wieder aufgenommen wird? Manche brauchen eben mal einen Tritt in den Hintern.
Und Software die buggy ist und eh nicht richtig gepflegt wird, kann von mir aus auch gerne rausfliegen.
Und Software die buggy ist und eh nicht richtig gepflegt wird, kann von mir aus auch gerne rausfliegen.
-
- Beiträge: 3282
- Registriert: 29.06.2013 17:32:10
- Lizenz eigener Beiträge: GNU General Public License
-
Kontaktdaten:
Re: Automatic removal of packages from testing
Ich finde die Zeiten auch sehr kurz gehalten.hikaru hat geschrieben:Urlaube von mehr als drei Wochen Länge sind also ab nächster Woche für Debian-Maintainer gestrichen?Packages which have RC bugs that are present in both testing and
unstable, and which have no recent activity (currently this means no
activity in the last 14 days) will be checked for removal.
[..]
For packages which are marked for autoremoval 10 days in a row,
removal hints will be added. These packages will usually be removed
from testing fairly soon after that.
xxxterm (718074) würde mir fehlen ... also langfristig ... so ab Jessie-Release.
Ausserdem was heisst fliegen raus? In unstable bleiben die doch erhalten, bis sich jemand drum kümmert? Von dort können die ja ggf. nach Testing gebackported werden (Sollte doch ohne Probleme machbar sein, wenns noch die selbe verbuggte Version ist die vorher auch in Testing war). Und was man hat, sollte man pinnen. Kann apt-listbugs das nicht sogar autom. tun?
Dann wird stable ja mal zu dem was man machmal fälschlicher Weise über stable hört: Frei von Bugs. Anstatt stabile Abhänigkeiten incl. Versionen. Grundsätzlich bin ich davon nicht abgeneigt, nur ob man so ein brauchbares release hinbekommt...
Wirklich ein spannendes Experiment.
(=_=)
Unsere neue Mutter: https://www.nvidia.com/de-de/data-center/a100/
Unsere neue Mutter: https://www.nvidia.com/de-de/data-center/a100/
-
- Beiträge: 3282
- Registriert: 29.06.2013 17:32:10
- Lizenz eigener Beiträge: GNU General Public License
-
Kontaktdaten:
Unkenruf
Hat das eigentlich langfristig gedacht Auswirkungen auf den Lebenszyklus von stable?
Wenn so die RC-Bugs gedrückt werden sollen, könnte man vermuten das in kleineren Intervallen stable Veröffentlichung herauskommen.
Edit: Gibt es eine min. Lebenszeit für stable?
Wenn so die RC-Bugs gedrückt werden sollen, könnte man vermuten das in kleineren Intervallen stable Veröffentlichung herauskommen.
Edit: Gibt es eine min. Lebenszeit für stable?
(=_=)
Unsere neue Mutter: https://www.nvidia.com/de-de/data-center/a100/
Unsere neue Mutter: https://www.nvidia.com/de-de/data-center/a100/
Re: Unkenruf
Das ist wohl auch der Sinn der Sache. Testing so weit wie möglich frei von RC-Bugs zu halten, so dass ein Release schneller über die Bühne geht. Keine monatelangen Freezes mehr, wär sicher wünschenswert.inne hat geschrieben:Hat das eigentlich langfristig gedacht Auswirkungen auf den Lebenszyklus von stable?
Wenn so die RC-Bugs gedrückt werden sollen, könnte man vermuten das in kleineren Intervallen stable Veröffentlichung herauskommen.
Edit: Gibt es eine min. Lebenszeit für stable?
Allerdings heisst das nicht, dass Debian deswegen öfter released wird.
Um Probleme in testing zu vermeiden, empfehle ich unstable in die sources.list aufzunehmen und auf 400 zu pinnen (oder testing 900 und unstable 800?)
MfG Marco - (CC) BY-NC-ND
- bmario
- Beiträge: 1256
- Registriert: 05.09.2007 12:15:47
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Dresden
Re: Automatic removal of packages from testing
Aber euch ist schon bewusst, dass Pakete die nicht mehr im Repository zu finden sind, deswegen nicht gleich bei euch lokal deinstalliert werden?
Nichts zu tun ist viel besser,
als mit viel Mühe nichts zu schaffen. - Laotse
als mit viel Mühe nichts zu schaffen. - Laotse
Re: Automatic removal of packages from testing
Aber was nützt das?
Bei meinem Notebook funktioniert der sis Treiber nicht mehr auch nicht der aus sid.
Als Abhängigkeit wird folgendes angegeben.
dep: xorg-video-abi-8 [hppa]
virtuelles Paket, bereitgestellt durch xserver-xorg-core, xserver-xorg-core-udeb
Egal was ich versucht habe, ich habe den Treiber nicht kompiliert bekommen, weil er auch in sid buggy ist.
Mittlerweile kann ich einige Entscheidungen bei Debian nicht mehr nachvollziehen.
PS: Ich schreibe hier den Text mit dem Notebook, dass ich nach der Definition von Debian in die Tonne hauen kann.Dafür musste ich die Distribution wechseln.
Bei meinem Notebook funktioniert der sis Treiber nicht mehr auch nicht der aus sid.
Als Abhängigkeit wird folgendes angegeben.
dep: xorg-video-abi-8 [hppa]
virtuelles Paket, bereitgestellt durch xserver-xorg-core, xserver-xorg-core-udeb
Egal was ich versucht habe, ich habe den Treiber nicht kompiliert bekommen, weil er auch in sid buggy ist.
Mittlerweile kann ich einige Entscheidungen bei Debian nicht mehr nachvollziehen.
PS: Ich schreibe hier den Text mit dem Notebook, dass ich nach der Definition von Debian in die Tonne hauen kann.Dafür musste ich die Distribution wechseln.
Re: Automatic removal of packages from testing
Was hat debian damit zu tun, dass dieser Treiber kaputt ist? Vermutlich kümmert sich upstream keiner mehr um diesen Exoten. (Bugreport verfasst?)
Unix is user-friendly; it's just picky about who its friends are.
Re: Automatic removal of packages from testing
Gegenfrage : Wieso ist der Treiber nur bei Debian kaputt?
- KBDCALLS
- Moderator
- Beiträge: 22365
- Registriert: 24.12.2003 21:26:55
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Dortmund
-
Kontaktdaten:
Re: Automatic removal of packages from testing
Was haben Windows und ein Uboot gemeinsam?
Kaum macht man ein Fenster auf, gehen die Probleme los.
EDV ist die Abkürzung für: Ende der Vernunft
Bevor du einen Beitrag postest:
Kaum macht man ein Fenster auf, gehen die Probleme los.
EDV ist die Abkürzung für: Ende der Vernunft
Bevor du einen Beitrag postest:
- Kennst du unsere Verhaltensregeln
- Lange Codezeilen/Logs gehören nach NoPaste, in Deinen Beitrag dann der passende Link dazu.
- bmario
- Beiträge: 1256
- Registriert: 05.09.2007 12:15:47
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Dresden
Re: Automatic removal of packages from testing
Gegengegenfrage: Warum willst du den Treiber überhaupt kompilieren, anstatt das fertig kompilierte Paket zu nutzen?Henrikx hat geschrieben:Gegenfrage : Wieso ist der Treiber nur bei Debian kaputt?
Nichts zu tun ist viel besser,
als mit viel Mühe nichts zu schaffen. - Laotse
als mit viel Mühe nichts zu schaffen. - Laotse
Re: Automatic removal of packages from testing
Weil das Paket nicht mehr funktioniert.
Außer VGA war nichts mehr zu machen..
Kompilieren zwecklos, egal ob Source/Abhänigkeiten aus testing oder sid Quellen.
@KBDCALLS
Genau.
z.B in Arch ist 2013-03-10 upgpkg: xf86-video-sis 0.10.7-4 und funktioniert tadellos.
Wieso also nicht bei Debian?
Außer VGA war nichts mehr zu machen..
Kompilieren zwecklos, egal ob Source/Abhänigkeiten aus testing oder sid Quellen.
@KBDCALLS
Genau.
z.B in Arch ist 2013-03-10 upgpkg: xf86-video-sis 0.10.7-4 und funktioniert tadellos.
Wieso also nicht bei Debian?
- Teddybear
- Beiträge: 3163
- Registriert: 07.05.2005 13:52:55
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Altomünster
-
Kontaktdaten:
Re: Automatic removal of packages from testing
Fage doch einfach mal den Maintainer warum da nix neueres nachkommt.Henrikx hat geschrieben:Weil das Paket nicht mehr funktioniert.
Außer VGA war nichts mehr zu machen..
Kompilieren zwecklos, egal ob Source/Abhänigkeiten aus testing oder sid Quellen.
@KBDCALLS
Genau.
z.B in Arch ist 2013-03-10 upgpkg: xf86-video-sis 0.10.7-4 und funktioniert tadellos.
Wieso also nicht bei Debian?
Oder bau dir den 0.10.7 einfach selbst..
Und zu deiner Frage wieso der Kaputt ist: der 0.10.4 der in sid rumdümpelt brauch xorg-video-abi-12, wir sind aber schon bei 14.
Versuchungen sollte man nachgeben. Wer weiß, ob sie wiederkommen!
Oscar Wilde
Mod-Voice / My Voice
Oscar Wilde
Mod-Voice / My Voice
Re: Automatic removal of packages from testing
@Teddybear
Selbst bauen war nicht möglich, bzw. ich bin jedenfalls daran gescheitert.
Wie gesagt, ich habe jetzt Arch aufgezogen und es funktioniert gut.
Fühle mich zwar ein wenig von Debian wie vor die Tür gesetzt, aber was soll es, interessiert eh niemanden.
Ich kann auch nicht der Argumentation folgen, testing ist ein gefährliches System.
Bin seit Jahren auf testing, so was ist mir noch nie passiert.
Arch core läuft ebenfalls sehr zuverlässig.
Sollte sich der bis jetzt positive Eindruck von Arch weiter bestätigen, würde ich alle meine Computer auf Arch umrüsten und fairerweise auch meinen Mod - Status abgeben. Bin z.Z. echt sauer...
Einen Treiber zu entfernen und keinen Ersatz zu liefern, ist einfach nur dreist.
Selbst bauen war nicht möglich, bzw. ich bin jedenfalls daran gescheitert.
Wie gesagt, ich habe jetzt Arch aufgezogen und es funktioniert gut.
Fühle mich zwar ein wenig von Debian wie vor die Tür gesetzt, aber was soll es, interessiert eh niemanden.
Ich kann auch nicht der Argumentation folgen, testing ist ein gefährliches System.
Bin seit Jahren auf testing, so was ist mir noch nie passiert.
Arch core läuft ebenfalls sehr zuverlässig.
Sollte sich der bis jetzt positive Eindruck von Arch weiter bestätigen, würde ich alle meine Computer auf Arch umrüsten und fairerweise auch meinen Mod - Status abgeben. Bin z.Z. echt sauer...
Einen Treiber zu entfernen und keinen Ersatz zu liefern, ist einfach nur dreist.
Re: Automatic removal of packages from testing
Und jetzt hat es Dich doch erwischt.Henrikx hat geschrieben: Ich kann auch nicht der Argumentation folgen, testing ist ein gefährliches System.
Bin seit Jahren auf testing, so was ist mir noch nie passiert.
http://packages.ubuntu.com/xserver-xorg-video-sis
Ab saucy für video-abi-14
Der 0.10.7 wird wohl "upstream-experimental" / "upstream-unstable" getestet.
Solange alternativ sisfb (kernel) + fbdev (xorg)?
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
- KBDCALLS
- Moderator
- Beiträge: 22365
- Registriert: 24.12.2003 21:26:55
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Dortmund
-
Kontaktdaten:
Re: Automatic removal of packages from testing
Henrikx hat geschrieben:Weil das Paket nicht mehr funktioniert.
Außer VGA war nichts mehr zu machen..
Kompilieren zwecklos, egal ob Source/Abhänigkeiten aus testing oder sid Quellen.
@KBDCALLS
Genau.
z.B in Arch ist 2013-03-10 upgpkg: xf86-video-sis 0.10.7-4 und funktioniert tadellos.
Wieso also nicht bei Debian?
Und mal versucht die Originalquellen zu kompilieren ? Ohne das Debiandiff.
Was haben Windows und ein Uboot gemeinsam?
Kaum macht man ein Fenster auf, gehen die Probleme los.
EDV ist die Abkürzung für: Ende der Vernunft
Bevor du einen Beitrag postest:
Kaum macht man ein Fenster auf, gehen die Probleme los.
EDV ist die Abkürzung für: Ende der Vernunft
Bevor du einen Beitrag postest:
- Kennst du unsere Verhaltensregeln
- Lange Codezeilen/Logs gehören nach NoPaste, in Deinen Beitrag dann der passende Link dazu.