Discussion:
Paket aus Fremdquellen installieren
Matthias Taube
2018-10-16 19:45:27 UTC
Permalink
Hi,

für einen Drucker (Brother HL-2030) habe ich die .deb Pakete mit den
Treibern von der Webseite des Herstellers installiert.

Wie vom Hersteller empfohlen mit
dpkg -i --force-all brhl2030lpr-2.0.1-1.i386.deb
dpkg -i --force-all cupswrapperHL2030-2.0.1-2.i386.deb
zeus:/home/mati/filserv/daten/reise# aptitude safe-upgrade --full-resolver
cupswrapperhl2030:i386 : Hängt ab von: libc6:i386 (>= 2.2.5) which is a virtual package and is not provided by any available package
brhl2030lpr:i386 : Hängt ab von: libc6:i386 (>= 2.2.5) which is a virtual package and is not provided by any available package
1) brhl2030lpr:i386 [2.0.1-1 (now)]
2) cupswrapperhl2030:i386 [2.0.1-2 (now)]
Der Drucker scheint auf dem System mit diesen Treibern zu funktionieren.
Kann ich der Aptitude (bzw. dpkg) Paketverwaltung manuell mitteilen,
dass diese beiden Pakete zwar installiert sind, aber bei der Prüfung auf
Abhängigkeiten etc. ignoriert werden sollen?

mfg
Matthias
Hilmar Preuße
2018-10-16 20:09:16 UTC
Permalink
On 16.10.2018 21:45, Matthias Taube wrote:

Moin,
Post by Matthias Taube
für einen Drucker (Brother HL-2030) habe ich die .deb Pakete mit den
Treibern von der Webseite des Herstellers installiert.
Wie vom Hersteller empfohlen mit
dpkg -i --force-all  brhl2030lpr-2.0.1-1.i386.deb
dpkg -i --force-all  cupswrapperHL2030-2.0.1-2.i386.deb
<snip>
Post by Matthias Taube
Der Drucker scheint auf dem System mit diesen Treibern zu funktionieren.
Kann ich der Aptitude (bzw. dpkg) Paketverwaltung manuell mitteilen,
dass diese beiden Pakete zwar installiert sind, aber bei der Prüfung auf
Abhängigkeiten etc. ignoriert werden sollen?
Nun, in beiden Paketen sind ELF-Binaries drin, die i386 sind und
demzufolge gegen libc6:i386 gelinkt sind. Ich würde also vorsichtshalber
auf die Paketverwaltung hören und das Paket installieren.

Wieso der Hersteller --force empfiehlt, entzieht sich meiner Kenntnis.

Hilmar
--
#206401 http://counter.li.org
Ulf Volmer
2018-10-16 21:29:06 UTC
Permalink
Post by Matthias Taube
für einen Drucker (Brother HL-2030) habe ich die .deb Pakete mit den
Treibern von der Webseite des Herstellers installiert.
Wie vom Hersteller empfohlen mit
dpkg -i --force-all  brhl2030lpr-2.0.1-1.i386.deb
dpkg -i --force-all  cupswrapperHL2030-2.0.1-2.i386.deb
Oh je. Ich vermute, Du bist auf Stretch mit amd64 unterwegs?

Da läßt sich
Post by Matthias Taube
cupswrapperhl2030:i386 : Hängt ab von: libc6:i386 (>= 2.2.5) which
nicht auflösen, da das libc6- Paket nur für amd64 verfügbar ist.
Multiarch hilft hier auch nicht. Auf einem echten Stretch i386
läßt sich das Paket installieren, auch ohne --force-all.

Ich würde aber im Zweifel davon abraten, zu versuchen ein Paket von 2007
auf einem aktuellen System ans Laufen zu bekommen.

Schau Dich besser nach einem Drucker mit richtigem (Opensource)- Support
um, da besteht die Hoffnung, dass das auch langfristig gepflegt wird.

Viele Grüße
Ulf
Robert Stephan
2018-10-16 22:48:48 UTC
Permalink
Nun, hier lÀuft schon lÀnger ein Brother MFC L2720DW ohne Probleme mit Buster/
Sid.
Die libc6-i386:amd64 brauchts aber, sonst will der nicht.


Robert

SchlÌßel ID= 6E9BF134
Fingerprint=68C1 F1BC C3E0 EA52 0CE7 FB95 7E1B 7D60 6E9B F134
Ich wÃŒrde aber im Zweifel davon abraten, zu versuchen ein Paket von 2007
auf einem aktuellen System ans Laufen zu bekommen.
Schau Dich besser nach einem Drucker mit richtigem (Opensource)- Support
um, da besteht die Hoffnung, dass das auch langfristig gepflegt wird.
Ulf Volmer
2018-10-17 10:30:39 UTC
Permalink
Nun, hier läuft schon länger ein Brother MFC L2720DW ohne Probleme mit Buster/
Sid.
Die libc6-i386:amd64 brauchts aber, sonst will der nicht.
Du hast aber einen deutlich neueren Drucker und mutmaßlich auch einen
neueren Treiber.

Viele Grüße
Ulf
Hans-Georg Bork
2018-10-17 12:52:38 UTC
Permalink
Moin,
Post by Ulf Volmer
Oh je. Ich vermute, Du bist auf Stretch mit amd64 unterwegs?
Da läßt sich
cupswrapperhl2030:i386 : Hängt ab von: libc6:i386 (>= 2.2.5) which
nicht auflösen, da das libc6- Paket nur für amd64 verfügbar ist.
??? libc6-i386 existiert für stretch/amd64. Siehe
https://packages.debian.org/stretch/libc6-i386
Sollte das die Abhängigkeit nicht auflösen?

Ich nutze hier einen alten DCP 145C mit nem i386 Treiber von 2003 ...

Gruß
-- hgb
Sven Hartge
2018-10-17 14:48:22 UTC
Permalink
Post by Hans-Georg Bork
Post by Ulf Volmer
Oh je. Ich vermute, Du bist auf Stretch mit amd64 unterwegs?
Da läßt sich
cupswrapperhl2030:i386 : Hängt ab von: libc6:i386 (>= 2.2.5) which
nicht auflösen, da das libc6- Paket nur für amd64 verfügbar ist.
??? libc6-i386 existiert für stretch/amd64. Siehe
https://packages.debian.org/stretch/libc6-i386
Sollte das die Abhängigkeit nicht auflösen?
Nein, weil die Abhängigkeit auf "libc6:i386" besteht.

Was du brauchst ist

dpkg --add-architecture i386
apt update
apt install -f
(oder apt install libc6:i386)

S°
--
Sigmentation fault. Core dumped.
Ulf Volmer
2018-10-17 14:57:42 UTC
Permalink
Post by Sven Hartge
Nein, weil die Abhängigkeit auf "libc6:i386" besteht.
Was du brauchst ist
dpkg --add-architecture i386
apt update
apt install -f
(oder apt install libc6:i386)
Multiarch hilft an dieser Stelle nicht:

***@deb9-x1:~# dpkg --add-architecture i386
***@deb9-x1:~# apt install libc6:i386
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package libc6:i386 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
libdb1-compat tzdata

E: Package 'libc6:i386' has no installation candidate

Viele Grüße
Ulf
Hans-Georg Bork
2018-10-17 15:02:33 UTC
Permalink
Post by Ulf Volmer
Post by Sven Hartge
Nein, weil die Abhängigkeit auf "libc6:i386" besteht.
Was du brauchst ist
dpkg --add-architecture i386
apt update
apt install -f
(oder apt install libc6:i386)
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package libc6:i386 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
libdb1-compat tzdata
E: Package 'libc6:i386' has no installation candidate
Irgendwas begreife ich nicht.
https://packages.debian.org/stretch/i386/libc6/download ist doch da ...
oder ist auch das wieder etwas anderes?

Gruß
-- hgb
Stefan Baur
2018-10-17 15:30:22 UTC
Permalink
Post by Hans-Georg Bork
Irgendwas begreife ich nicht.
https://packages.debian.org/stretch/i386/libc6/download ist doch da ...
oder ist auch das wieder etwas anderes?
Also mein Verständnis aus den bisherigen Antworten in diesem Thread:

libc6-i386:amd64 ist das, was Du installieren solltest, wenn Du auf
amd64 mit Multiarch eine für i386 gebaute libc6 brauchst.

Das hilft, dass das Programm läuft, was libc6:i386 erwartet, wenn Du es
installiert bekommst (z.B. per dpkg --force, oder weil es gar kein Paket
ist).

Das hilft aber nicht, dass dpkg, apt, usw. eine Abhängigkeit als
aufgelöst betrachten, denn libc6-i386:amd64 != libc6:i386 - es ist
einfach ein anderer Name, und Computer sind dumm.

Du müsstest also wahrscheinlich das Paket auspacken, die Abhängigkeit
entfernen/ändern, es dann erneut packen, und diese Version dann
installieren, damit dpkg, apt, usw. Ruhe geben.

Gruß
Stefan
Sven Hartge
2018-10-17 15:38:50 UTC
Permalink
Post by Stefan Baur
Post by Hans-Georg Bork
Irgendwas begreife ich nicht.
https://packages.debian.org/stretch/i386/libc6/download ist doch da ...
oder ist auch das wieder etwas anderes?
Leider nur zu 25% richtig verstanden.
Post by Stefan Baur
libc6-i386:amd64 ist das, was Du installieren solltest, wenn Du auf
amd64 mit Multiarch eine für i386 gebaute libc6 brauchst.
Nein.
Post by Stefan Baur
Das hilft, dass das Programm läuft, was libc6:i386 erwartet, wenn Du es
installiert bekommst (z.B. per dpkg --force, oder weil es gar kein Paket
ist).
libc6-i386:amd64 ist ein Überbleibsel aus der Vor-Multiarch-Zeit. IIRC
wurde dieses Paket von den LSB-Meta-Paketen benötigt.
Post by Stefan Baur
Das hilft aber nicht, dass dpkg, apt, usw. eine Abhängigkeit als
aufgelöst betrachten, denn libc6-i386:amd64 != libc6:i386 - es ist
einfach ein anderer Name, und Computer sind dumm.
Richtig.
Post by Stefan Baur
Du müsstest also wahrscheinlich das Paket auspacken, die Abhängigkeit
entfernen/ändern, es dann erneut packen, und diese Version dann
installieren, damit dpkg, apt, usw. Ruhe geben.
Um Gottes willen, nein.

Das richtige Vorgehen wurde von mir an anderer Stelle beschrieben.

S°
--
Sigmentation fault. Core dumped.
Sven Hartge
2018-10-17 15:35:54 UTC
Permalink
Post by Sven Hartge
Nein, weil die Abhängigkeit auf "libc6:i386" besteht.
Was du brauchst ist
dpkg --add-architecture i386
apt update
apt install -f
(oder apt install libc6:i386)
Du hast "apt update" vergessen. Was meinst du wohl, warum ich das dazu
schreibe, hmm?

S°
--
Sigmentation fault. Core dumped.
Ulf Volmer
2018-10-17 15:59:03 UTC
Permalink
Post by Sven Hartge
Du hast "apt update" vergessen. Was meinst du wohl, warum ich das dazu
schreibe, hmm?
OK, dann passt es, ja.

Viele Grüße
Ulf
Matthias Taube
2018-10-17 18:09:41 UTC
Permalink
Post by Sven Hartge
Was du brauchst ist
dpkg --add-architecture i386
apt update
apt install -f
(oder apt install libc6:i386)
Ich habe nun wie empfohlen
Post by Sven Hartge
dpkg --add-architecture i386> aptitude update
aptitude safe-upgrade
eingegeben und nach
Post by Sven Hartge
Auflösen der Abhängigkeiten ...
gcc-6-base:i386{a} libc6:i386{a} libgcc1:i386{a}
libssh-4 libssh-gcrypt-4
funktioniert nun alles.

Vielen Dank.
mfg
Matthias
Ulf Volmer
2018-10-17 14:54:02 UTC
Permalink
Post by Hans-Georg Bork
Post by Ulf Volmer
Oh je. Ich vermute, Du bist auf Stretch mit amd64 unterwegs?
Da läßt sich
cupswrapperhl2030:i386 : Hängt ab von: libc6:i386 (>= 2.2.5) which
nicht auflösen, da das libc6- Paket nur für amd64 verfügbar ist.
??? libc6-i386 existiert für stretch/amd64. Siehe
https://packages.debian.org/stretch/libc6-i386
Sollte das die Abhängigkeit nicht auflösen?
Nicht im Sinne des Paketmanagements.
libc6:i386 ist nunmal nicht das gleiche wie libc6-i386.

Ich denke, die genannten Paket sind für uralte Debian/Ubuntu
Versionen gebaut werden. Darum auch die zweilhaften Hinweise
des Herstellers.

Viele Grüße
Ulf
Matthias Taube
2018-10-17 18:15:33 UTC
Permalink
Post by Ulf Volmer
Ich würde aber im Zweifel davon abraten, zu versuchen ein Paket von 2007
auf einem aktuellen System ans Laufen zu bekommen.
Schau Dich besser nach einem Drucker mit richtigem (Opensource)- Support
um, da besteht die Hoffnung, dass das auch langfristig gepflegt wird.
Der Hinweis mag generell richtig sein, aber wenn der eigene (private)
Drucker kaputt ist und der Arbeitgeber sagt ... Kannst den alten Drucker
im Keller haben, wenn Du die orginalverpackten Tonerkassetten gleich
mitnimmst ...
dann probiert man es halt mal, bevor man über eine Neubeschaffung nachdenkt.

Gibt es eigentlich irgendwo eine Liste, welche Drucker/Scanner ohne
Fremdsoftware auf einem Debian-Stable laufen?

LG
Matthias
Helge Reimer
2018-10-17 18:28:52 UTC
Permalink
Post by Matthias Taube
Gibt es eigentlich irgendwo eine Liste, welche Drucker/Scanner ohne
Fremdsoftware auf einem Debian-Stable laufen?
Für Drucker kenne ich folgendes.

http://www.openprinting.org/drivers
http://www.openprinting.org/printers
http://gimp-print.sourceforge.net/p_Supported_Printers.php
--
Gruß
Helge
Helge Reimer
2018-10-17 16:46:35 UTC
Permalink
Post by Matthias Taube
für einen Drucker (Brother HL-2030) habe ich die .deb Pakete mit den
Treibern von der Webseite des Herstellers installiert.
Warum eigentlich?
Bis vor knapp 2 Jahren hatte ich auch diesen Drucker und die Treiber hat
'printer-driver-gutenprint' mitgebracht, wenn ich mich recht erinnere.
--
Gruß
Helge
Matthias Taube
2018-10-17 18:05:27 UTC
Permalink
Post by Helge Reimer
Post by Matthias Taube
für einen Drucker (Brother HL-2030) habe ich die .deb Pakete mit den
Treibern von der Webseite des Herstellers installiert.
Warum eigentlich?
Bis vor knapp 2 Jahren hatte ich auch diesen Drucker und die Treiber hat
'printer-driver-gutenprint' mitgebracht, wenn ich mich recht erinnere.
Weil ich keinen anderen Treiber gefunden habe. printer-driver-gutenprint
ist installiert, hilft aber nicht.

Mein System ist
Post by Helge Reimer
Linux zeus 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/Linux
Ich habe nun wie empfohlen
Post by Helge Reimer
dpkg --add-architecture i386
aptitude update
aptitude safe-upgrade
eingegeben und nach
Post by Helge Reimer
Auflösen der Abhängigkeiten ...
gcc-6-base:i386{a} libc6:i386{a} libgcc1:i386{a}
libssh-4 libssh-gcrypt-4
funktioniert nun alles.

Vielen Dank.
mfg
Matthias
Helge Reimer
2018-10-17 18:10:16 UTC
Permalink
Post by Matthias Taube
Weil ich keinen anderen Treiber gefunden habe. printer-driver-gutenprint
ist installiert, hilft aber nicht.
In Gutenprint ist dann wohl nur ein Treiber für den hl-2060. Der geht aber
auch.
Dann war es wohl so, dass man noch 'foomatic' braucht.
Post by Matthias Taube
funktioniert nun alles.
Na dann.
--
Gruß
Helge
Sebastian Suchanek
2018-10-17 18:37:27 UTC
Permalink
On Tue, 16 Oct 2018 21:45:27 +0200, Matthias Taube
Post by Matthias Taube
Wie vom Hersteller empfohlen mit
dpkg -i --force-all brhl2030lpr-2.0.1-1.i386.deb
dpkg -i --force-all cupswrapperHL2030-2.0.1-2.i386.deb
Ich rate dringend davon ab, deb-Pakete aus Fremdquellen zu
installieren.
Naja, machmal geht's halt nicht anders. Mein W-LAN Hier[tm] zum Beispiel
läuf seit Kurzem mit Ubiquiti-Unifi-Zeugs, wobei der Controller als
Software auf meinem Debian Heimserver läuft. Für den Unifi-Controller
stellt Ubiquiti immerhin ein "richtiges" Repository für Debian zur
Verfügung, aber für den Video-Controller für Ubiquiti Webcams (habe ich
(noch) nicht im Einsatz, hatte aber schon 'mal darüber nachgedacht)
scheint es nur eine .deb-Datei zum Download zu geben.
Diese Anleitung ("--force-all" ist der größte Hammer,
den dpkg zur Verfügung hat, ich brauche das alle fünf Jahre mal und
meist ist das System vorher schon kaputt) stärkt meinen Eindruck.
In diesem konkreten Fall gebe ich Dir allerdings Recht.


Tschüs,

Sebastian
Sebastian Suchanek
2018-10-18 17:43:01 UTC
Permalink
On Wed, 17 Oct 2018 20:37:27 +0200, Sebastian Suchanek
Post by Sebastian Suchanek
On Tue, 16 Oct 2018 21:45:27 +0200, Matthias Taube
Post by Matthias Taube
Wie vom Hersteller empfohlen mit
dpkg -i --force-all brhl2030lpr-2.0.1-1.i386.deb
dpkg -i --force-all cupswrapperHL2030-2.0.1-2.i386.deb
Ich rate dringend davon ab, deb-Pakete aus Fremdquellen zu
installieren.
Naja, machmal geht's halt nicht anders. Mein W-LAN Hier[tm] zum Beispiel
läuf seit Kurzem mit Ubiquiti-Unifi-Zeugs, wobei der Controller als
Software auf meinem Debian Heimserver läuft. Für den Unifi-Controller
stellt Ubiquiti immerhin ein "richtiges" Repository für Debian zur
Verfügung, aber für den Video-Controller für Ubiquiti Webcams (habe ich
(noch) nicht im Einsatz, hatte aber schon 'mal darüber nachgedacht)
scheint es nur eine .deb-Datei zum Download zu geben.
Den Ubiquiti-Controller hab ich auch aus dem Fremd-Repository
installiert, allerdings habe ich mir das Paket vorher angeschaut, und
die betroffene VM macht _nur_ den Ubiquiti-Controller.
[...]
OK, Virtualisierung wäre hier auch noch eine Möglichkeit gewesen - ich
hab's bei mir halt direkt auf die Kiste geschmissen.

Auch wenn's jetzt etwas OT wird: Hast Du konkrete Erfahrungswerte damit,
wie sich so eine VM auf die Systemlast des Hosts und damit auch auf
dessen Stromverbrauch auswirkt? Immerhin will bei so etwas nicht nur die
Virtualisierungs-Host-Software, sondern auch noch ein vollwertiges
Betriebssystem pro VM "durchgefüttert" werden...

Wie schon gesagt steht die Kiste bei mir zu Hause und da sie 24/7 läuft,
habe ich sie im Rahmen des Möglichen und Praktikablen auf einen geringen
Stromverbrauch getrimmt. (Im Idle-Betrieb, worin sie sich de facto die
meiste Zeit befindet.)


Tschüs,

Sebastian
Michael Wagner
2018-10-19 08:29:20 UTC
Permalink
Ich hab auch schon ein Herstellerpaket gesehen, das in seinem
Maintainerscript erstmal die libc gegen eine ältere Version getauscht
hat, und zwar mit cp, auf dass das Paketmanagement das bloß nicht
mitbekommt.
Ich hab letztens im Rahmen eines Projekts 'kerio connect' auf einem
Debian stable installiert, das mal schnell die sources.list um den
Eintrag testing erweitert hat. Wenn man da nicht aufpasst auf einem
Produktivsystem, kann das echt ins Auge gehen.

Michael
--
Grüß' mir das Meer, * Golden es schäumt',
Ob es auch träumet? * Tief ist das Meer.
(Friederike Kempner)
Alexander Reichle-Schmehl
2018-10-19 11:59:22 UTC
Permalink
Ich hab auch schon ein Herstellerpaket gesehen, das in seinem
Maintainerscript erstmal die libc gegen eine ältere Version getauscht
hat, und zwar mit cp, auf dass das Paketmanagement das bloß nicht
mitbekommt.
Und dann noch einen dpkg trigger, der die libc wieder durch die eigene
alte Version setzt, wenn sie durch die Paketverwaltung ersetzt wird?

Sorry, es ist Freitag ;-)

Lesen Sie weiter auf narkive:
Loading...