gelöst: Synaptic findet Quelle nicht

Für weitere Antworten geschlossen.


Advanced Hacker
Hi, ich hab ein kleines Problem mit Synaptic. Will ich ein Programm installieren sagt mir Synaptic, er findet die Quelle nicht, oder Quelle auf ftp://.....bla bla nicht vorhanden. Mach ich das ganze in einer Konsole mit apt-get install xxxx geht's problemlos. Ich kann auch den Link aus der Fehlermeldung kopieren und per Browser downloaden, funzt einwandfrei. Also an einer falschen Quelle kanns nitt liegen. Hat jemand ne Idee was in Synaptic hakt?

/edit: Vorher hat mir apt Programme 2 oder sogar 3x installiert. Dann kam die Fehlermeldung, das Programme doppelt vorhanden sind, das hab ich bereinigt. Hat apt aber bisher früher nicht gemacht.....???!!!!


Ultimate Guru
Bestätigen kann ich das nicht. Hier läuft synaptic.
Hab leider keine Idee, woran es bei dir haken könnte.


Hallo nollsa,

habe dieses Problem auch. Auch wenn ich über synaptic 'neu laden' betätige. Holt sich apt sich nicht die aktuellen Listen. Habe in 'top' festgestellt, das der Prozess '/usr/lib/apt/methods/ftp' nicht weiterkommt.



Bei mir macht Synaptic auch Probleme!

Wenn ich auf "Neu laden" gehe, wurden vor 2 Tagen noch 6 Adressen abgerufen, das scheint der jetzt zu überspringen!

Bei apt ist mir auch eine Veränderung aufgefallen!

  • Hole:1 1.7/generic release [1323B]
    0% [Logging in] [Logging in] [1 release 0/1323B 0%] [Waiting for headers] [Waitpkgrepo parserelease /var/lib/apt/lists/ftp.heanet.ie_pub_jpackage_1.7_generic_base_release

Vorher hat der die Pakete ohne Probleme geladen, jetzt ist mir dieser Eintrag aufgefallen: /var/lib/apt/lists/



Hallo Leute,

ich glaube ich habe die Lösung gefunden ,, es liegt an der apt version denn ich habe mal über smart eine alte apt installiert und sehe das synaptic wieder Lüpt


Advanced Hacker
Also ich kann mir nicht vorstellen, dass es an der apt-Version liegt. apt funktioniert ja bei mir in der Konsole einwandfrei, ich kann dort alle Pakete, die Synaptic mir ablehnt oder nicht findet ohne Probleme installieren.


Ja, liegt an der neuen apt Version und der neuen apt-libs!

Jetzt verhällt sich apt in der Konsole auch wieder normal!

  • Hole:1 noarch release [471B]

Jetzt klappt auch das aktualisieren der Quellen über Synaptic wieder.


Advanced Hacker
Ich denke wir reden hier etwas an meinem Problem vorbei, Aktualisierung und Installation etc. haben schon immer in der Konsole geklappt, Installation geht über Synaptic nicht, da er die Quelle nicht findet.

@earth81 ein Posting reicht, nimm mal den Rest raus, oder Toni mach du das.



ich glaube nicht das wir über dein Problem vorbei reden !!
aber was ich eher glaube ist das du uns nicht verstehen willst das das Problem an der neuen apt Version liegt,
denn auch bei mir konnte ich mit der neuen apt in der Konsole alles ohne Probleme erledigen ,,
aber was defenetiv nicht ging das war Synaptic das wollte einfach nicht Funktionieren

daraufhin habe ich mal die alte apt inklusive seine libs Installiert und jetzt geht es ohne Probleme


Die funktionierende Version lautet 0.5.15cnc7-5, die neueste Version, die Probleme macht, lautet 0.5.15repomd060302-0suse1000.rb1


Ultimate Guru
? Wo hast du denn die Version überhaupt her?
Bestimmt NICHT aus einem Suse-Repo. Denn wenn ich bei mir schaue:
apt policy apt
  Installiert: 0.5.15cnc7-6
  Kandidat: 0.5.15cnc7-6
 *** 0.5.15cnc7-6 0
        500 SuSE/10.0-i386/base pkglist
        100 RPM Database


Hatte auch eine aehnliche Frage. Also apt und apt-libs von suser-rbos besser nicht uebernehmen?

  • # apt policy apt
    Installiert: 0.5.15cnc7-6
    Kandidat: 0.5.15repomd060302-0.suse1000.rb1
    0.5.15repomd060302-0.suse1000.rb1 0
    1001 SuSE/10.0-i386/suser-rbos pkglist
    *** 0.5.15cnc7-6 0
    1001 SuSE/10.0-i386/base pkglist
    100 RPM Database


Ultimate Guru
von Panu 31.01.2006
Hey folks (is there anybody still here anyway?)

Just when you thought it was finally dead for good, here's a new
EXPERIMENTAL AND UNOFFICIAL new apt-rpm release featuring:
* barebones multilib support hack for x86_64
* support for rpm >= 4.4.3, including Suggests handling

Other changes since 0.5.15cnc7:
* support for negative package pins (eg "anything but this version")
* support for candidate versions for virtual packages 
* Progeny's http redirection and authentication patch added
* fix for segmentation fault in apt-shell virtual package handling
* read-only rpmdb lock taken during initial dependency calculation
instead of exclusive lock
* auto* stuff tweaked to build out of the box on FC 
* some tweaks to python bindings build
* Lua scripts now live in /usr/share/apt/scripts instead
of /usr/lib[64]/apt/scripts

Before you get too excited, the multilib support is hacky and
non-optimal at best. It simply renames apt internally any non-native
packages on 64bit systems "foo" -> "foo.32bit" to avoid the deeper
issues. I'm sure it has bugs, some known (cross-arch obsoletes certainly
wont work correctly etc) and some unknown, but it hasn't trashed my box
yet. Knock wood, and *treat with care*. Do let me know if it works for
you or not.

[root@weasel ~]# uname -m
[root@weasel ~]# apt-get dist-upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
Calculating Upgrade... Done
The following packages will be upgraded
   zlib ( =>
   zlib.32bit ( =>
2 upgraded, 0 newly installed, 0 removed and 0 not upgraded.
[root@weasel ~]# apt-get install
Reading Package Lists... Done
Building Dependency Tree... Done
Selecting for ''
The following extra packages will be installed: ( (
The following NEW packages will be installed: ( (
0 upgraded, 2 newly installed, 0 removed and 0 not upgraded.

The place to get it:

Yeah, I've been bored. Things are just too easy in Python and needed a
bit of challenge for a change ;) I wont make any promises about actively
continuing apt-rpm development but hey, if people still want to use it,
who knows...

        - Panu -

von Richard Boos:
Alright apt lovers,

I received the email below earlier this week:
A word of warning: this is probably the biggest change apt-rpm has seen
since the 0.3.x -> 0.5.x codebase switch, it's an incomplete and very
much work-in-progress version and is sure to contain bugs.

If that didn't scary you away: here's a snapshot of my bleeding edge
branch, now with repomd support (you know the repository metadata which
eg Fedora uses...):
To go with it there's also a patch to add repomd support to synaptic
(currently svn head only, but can and will rediff against latest
released version if people want) in the directory.

I've been using this for updating my own main box for a couple of weeks
now, hasn't eaten it alive but take care. There are various known
caveats and not-implemented-yet things, at least the following from the
top of my head:
- Package and repository checksums are not verified at all: apt uses
md5sums "natively" whereas repomd uses sha1, needs a bit of abstracting
out. Neither are *that* big a deal in practise - rpm wont install a
malformed package (and you probably want to use GPG checker lua-plugin
anyway), and a broken mirror might cause some interesting effects (I
haven't encountered any yet though)
- Not all file dependencies can be solved. Currently only the data in
primary.xml file is processed, and while that already covers most
typical file dependencies, there are at least a few dependencies in FC4
which would need filelists.xml information. Will get to this eventually.
- Repomd.xml is downloaded but not really used for anything yet (see
above the bit about checksums)
- apt-cache doesn't show full dependency information for packages,
another work-in-progress thingy
- It eats gobs of memory and probably leaks quite a bit of it
- Source repositories of repomd type are not yet supported 
- The code is still in middle of heavy reorganization to better support
different repository models without duplicating tons of code

So, it has it's shortcomings but it sure leaves the competition far away
in dust when it comes to speed, even in it's current totally unoptimized
state. :)

Oh and there's a new sources.list entry format for this, as there are no
such things as "sections" in repomd, so it's just
repomd <base url> <distribution>

For example (each entry on a single line of course) for Fedora Core +



I'd like some more eyes on this - when testing, watch out for them
little things like incorrect filesizes, odd looking dependencies and
such. The code will still change quite a bit but those little details
are important to get right already. Note that this also means "native"
apt repositories - that code has seen quite a few changes as well in
this process (and yes, mixing old style rpm repos and repomd is supposed
to work without glitches)

I could of course not let this pass by without creating rpms of it.  They are 
present in the suser-rbos apt component:

They work for regular apt functionality.  I have not tested the repomd 
functionality.  So if you want to live on the edge of suse here is your 
change, test apt repomd support and let's us know how it goes!!!

Richard Bos
Without a home the journey is endless

es geht also nur um die neue Funktionalität ... und wenn es kein neues synaptic gibt welches gegen die neue aptlib gelinkt wird .. PECH.
Also nur updaten wenn man KEIN synaptic nutzen will. Alles Klar ?
Für weitere Antworten geschlossen.