Debian incoming in die sources.list(.d/incoming.list) einbinden

[michaa7]

Wie binde ich debian incoming in die sources.list(.d/incoming.list) ein?

Für den 6.0 Kernel gibt es nun einen gepatchte Version des nvidia470 drivers, die auch mit diesem Kernel tuen soll. Das würde ich gerne ausprobieren. Dazu könnte ich natürlich alle Pakete hier *manuell* herunterladen :

https://incoming.debian.org/debian-buil ... tesla-470/

Das sollte jedoch mit apt bequemer gehen (und bei einem pinning von "1" auch keine Probleme bereiten, wie es das so ja auch mit "experimental" nicht tut).

Nur wie lautet dann die zu verwendende Zeile für incoming?

[JTH]

Verrät dir die Seite selbst:

Most Debian suites have an equivalent buildd-SUITE available under the debian-buildd directory. These can be used in the normal way via apt's sources.list. For example:

deb https://incoming.debian.org/debian-buildd buildd-unstable main contrib non-free

Nachtrag: Und hier gibts die Liste mit Distributionen, die du statt buildd-unstable benutzen kannst, wenn was anderes als Sid/unstable passender ist: Index of /debian-buildd/dists.

[michaa7]

1. Danke! Heruntergeladen , modul baut ohne Fehler mit 6.0 kernel und bootet erfolgreich zur graphischen Anmeldung mit X.

2. Ich bin etwas irritiert. Eben schreibe ich noch von wegen "experimental" gepinnt auf "1". Nun wollte ich das gleiche für incoming tun ... und stelle fest dass es bei mir keine /etc/apt/preferences.d/foo (mehr) gibt. Ich bin mir sicher dass ich seinerzeit (vor Jahren!!!) "experimental" auf "1" gepinnt habe ... nur, hat sich am pinning etwas geändert?

Viel wichtiger, warum bekomme ich ohne (auffindbares) pinning nicht bei jedem d-u alle möglichen Pakete aus "experimental" (Gott sei Dank) in mein System gedrückt, andererseits fischt "apt install nvidia-tesla-470-driver" (ohne jedes -t incoming" oder "=<version>" o.ä.) die neueste Version des drivers aus incoming (vielmehr aus buildd-unstable) heraus. Es funktioniert also *ohne pinning* alles so wie es soll, aber warum?

[JTH]

[…] Es funktioniert also *ohne pinning* alles so wie es soll, aber warum?

Ganz einfach: Die Debian-Entwickler denken mit experimental hat von Haus aus immer Priorität 1 (bedeutet kein automatisches Installieren und auch keine Upgrade von dort). Du müsstest es aktiv auf eine höhere Priorität setzen, wenn du das wolltest (sehr blöde Idee natürlich).

Kannst ja mal bei dir nachgucken, wenn du experimental ohne Pinning in der sources.list hast:

Code: Alles auswählen

apt-cache policy | grep -A2 experimental/

sollte jeweils eine 1 am Zeilenanfang haben.


Technischer Hintergrund:
Die Release-Datei für experimental im Repository enthält:

NotAutomatic: yes

Und das bewirkt, wenn es nicht mit ButAutomaticUpgrades: yes kombiniert ist, eben eine vorgegebene Priorität von 1:

Code: Alles auswählen

Assign:

priority 1
    to the versions coming from archives which in their Release files
    are marked as "NotAutomatic: yes" but not as "ButAutomaticUpgrades:
    yes" like the Debian experimental archive, as well as versions that
    are not phased on this systems.

[michaa7]

Wie schön ist Linux ....
.... wenn man sich auskennt

...
Kannst ja mal bei dir nachgucken, wenn du experimental ohne Pinning in der sources.list hast:

Code: Alles auswählen

apt-cache policy | grep -A2 experimental/

sollte jeweils eine 1 am Zeilenanfang haben.
...

jupp!

Mache ich das für buildd-unstable (incoming)

Code: Alles auswählen

$ apt-cache policy | grep -A2 buildd-unstable/
 500 http://incoming.debian.org/debian-buildd buildd-unstable/non-free i386 Packages
     release o=Debian,a=buildd-unstable,n=buildd-sid,l=Debian,c=non-free,b=i386
     origin neutower
     ...

erhalte ich "500".

Will man das wirklich für incoming?

Ich wollte jetzt das Paket aus incoming sofort ausprobieren weil ich (u.a.) den entsprechenden bugreport abgesetzt hatte und möglichst schnell sehen wollte ob das auch bei mir das Problem löst. Aber ob ich generell alle incoming Pakete ziehen will, da bin ich mir nicht so sicher. Kanns ja wieder auskommentieren (was ich aber auch nicht will) oder pinnen (was ich wohl tuen werde)

maschaun wie das nun funktioniert ...

Danke für deine Erklärungen. Is aber auch einfach wenn man weiß wie's geht

[JTH]

Will man das wirklich für incoming?

Auf nem richtigen, benutzten Rechner sicher nicht. Aber das Repo ist auch nicht wirklich für den Endbenutzer gedacht. Hab hier gerade das erste mal davon gehört

This is incoming.debian.org, […] It is primarily for the use of the Debian buildd-network but is publically available.

Mache ich das für buildd-unstable (incoming) […] erhalte ich "500".

Ja, die Release-Datei dort hat nicht den gleichen NotAutomatic-Eintrag wie in experimental.

Kanns ja wieder auskommentieren (was ich aber auch nicht will) oder pinnen (was ich wohl tuen werde)

Solltest du machen. Und wer Experimental und die Pakete direkt vom Buildserver benutzen will …

… weiß wie's geht

[michaa7]

Hab mal folgendes gemacht, das sollte eigentlich klappen:

/etc/apt/preferences

Code: Alles auswählen

Package: *
Pin: release a=buildd-unstable
Pin-Priority: 1

Wenn ich richtig verstehe was ich da zusammengepinnt habe wird hier nur etwas gezogen wenn ich
"-t buildd-unstable" mit angebe ?

Code: Alles auswählen

$ apt-cache policy | grep -A2 buildd-unstable/
   1 http://incoming.debian.org/debian-buildd buildd-unstable/non-free i386 Packages
     release o=Debian,a=buildd-unstable,n=buildd-sid,l=Debian,c=non-free,b=i386
...

Stimmt wohl so.

Danke nochmals ... für's feedback