Pidgin lässt mich nicht mehr rein

beavisbee

Member of Honour
Weiß jemand was mit Pidgin oder mit ICQ los ist?

Ich fühl mich gerade so ausgesperrt....

Immer wenn ich mich einloggen will kommt die Meldung
[ICQ-Nr.] deaktiviert
Die Client-Version, die Sie nutzen ist zu alt. Bitte updaten Sie unter http://pidgin.im/

Pidgin-Version: 2.4.2 (also eigentlich aktuell)

Die Seite pidgin.im ist auch nicht zu erreichen... :-(


hat vieleicht jemand selbige Probleme?
 
S

sw33tlull4by

Guest
Jep.
Allerdings mit Kopete.
AOL glaubt mal wieder es seit witzig X(
 

beavisbee

Member of Honour
hab ja fast so die Vermutung, dass sie Clients, die nicht von ihnen sind, (also != ICQ / AIM) aussperren wollen
*verschwörung-vermut* ;)

und dass die Pidgin-Seite nicht funktioniert ist dann vieleicht das Resultat, weil alle gleichzeitig drauf gehen, um zu sehen, ob es eine neue Version gibt... :(
 

Heinzelotto

New member
jep, das gleiche, bei mir gings noch, zum testen habe ich mich jetzt ausgeloggt und jetzt kann ich mich nicht mehr einloggen...
Mieser Zug von denen, die alternativen ICQ-Clients auszusperren.

edit @ beavisbee:
genau, aber ich glaube eher, die wollen nicht nur alle außer icq/aim, sondern alle außer icq6/aim aussperren...
 
S

sw33tlull4by

Guest
Es muesste einen alternativen Client geben welcher sich als ICQ-Client ausgeben kann.
Gibt es evtl schon einen solchen alternativen Client?
mfg

sw33t
 

bitmuncher

Senior-Nerd
Das Problem gab es doch mit ICQ schon öfter. Mies daran ist lediglich, dass ICQ nicht vorher Bescheid gibt, wenn Änderungen am Protokoll gemacht werden. Bisher hatten die freien Clients jedenfalls immer nach wenigen Tagen ein Update draussen. However... wer braucht schon ICQ. ;)

Nachtrag: Pidgin aus dem SVN soll wohl funktionieren.
 
S

sw33tlull4by

Guest
. However... wer braucht schon ICQ. Augenzwinkern
stimmt wohl,
aber 90%all meiner bekannten benutzen ICQ,also bin ich gezwungen da mitzumachen,den konvertieren kann ich die nicht, schon zu oft versucht.
 

justj

Member of Honour
Ich habe das gleiche Problem mit Adium auf meinem Mac. Bei Apfeltalk.de flippen die User reihenweise aus, weil ihre IMs nicht mehr laufen ;-)
 

xeno

Moderator
Mitarbeiter
farhaven hat mir grad den patch für pidgin gezeigt. einzige änderung:

Code:
-       0x010a, \
+       0x010b, \

dazu sagt man am besten mal nichts.

kompletter patch:

Code:
#
# old_revision [dba36543cdde6db127857b0edfdc3ad1969bbd39]
#
# patch "libpurple/protocols/oscar/oscar.h"
#  from [a40e3332eade975c73e344e17bd06d4b99cae751]
#    to [7853a27f5f8735092ebefef567aaeeccad2a057c]
#
============================================================
--- libpurple/protocols/oscar/oscar.h   a40e3332eade975c73e344e17bd06d4b99cae751
+++ libpurple/protocols/oscar/oscar.h   7853a27f5f8735092ebefef567aaeeccad2a057c
@@ -301,7 +301,7 @@ struct _ClientInfo

 #define CLIENTINFO_PURPLE_ICQ { \
        "Purple/" VERSION, \
-       0x010a, \
+       0x010b, \
        0x0014, 0x0034, \
        0x0000, 0x0bb8, \
        0x0000043d, \
 

farhaven

New member
Und für alle, die pidgin.im nicht mehr erreichen können, gibts pidgin-2.4.2.tar.bz2 hier mal gemirrort.

Wenn nach dem ersten Starten vom gepatchten Pidgin immer noch die Meldung von wegen "Client zu alt" kommt, dann solltet ihr euren ICQ Account im Menü Accounts deaktivieren und danach wieder aktivieren.
 
S

sw33tlull4by

Guest
weiss der Geier wiso aber kopete laeuft wieder.
und das ganz ohne update.
mfg

sw33t
 

Andifr

New member
Ich hab für alle Ubuntuuser grad ne Lösung gefunden:

Code:
echo "deb http://ppa.launchpad.net/nicolai-spohrer/ubuntu hardy main" | sudo tee -a /etc/apt/sources.list
Code:
sudo apt-get update
Code:
sudo apt-get install pidgin

Quelle: Ubuntuusers

Lg, Andi
 

odigo

Member of Honour
Kleiner Statusbericht:
Ich habs endlich geschafft auf die News-Seite von Pidgin (http://planet.pidgin.im/) zu kommen, aber da steht nichts über das aktuelle Problem oder ich habs überlesen. Die Seite schaut aber auch etwas merkwürdig aus (falsche Uhrzeiten der Beiträge). Mal schauen wie es morgen ausschaut, Bin mal gespannt was wirklich los war. Im Moment komm ich immer noch nicht rein. Zum Glück muss ich morgen in der Arbeit Trillian benutzen. So far.

Hier noch noch im Spoiler weil lang die letzte Newsnachricht (haben nichts mit dem Thema zu tun):
July 01, 2008 01:11 AM by Ethan Blanton

While you probably can't call the Pidgin developers wild-eyed radicals (heck, a fair number of us don't use any software projects started after about 1998 with any regularity), we do have the tendency, from time to time, to shake up the Pidgin UI in a quest for improvement. Unfortunately, these genuine quests for improvement are almost always accompanied by a rich cacophony of "I hate the new <whatever>!". There are also often responses which are more useful and coherent, but this article is not about those responses.

Our standard response to such exclamations is to ask the user to specify what, in particular, they liked about the old behavior and don't like about the new behavior, and why. This seems pretty reasonable to us, but often it elicits responses like "I just like what I like", or "why should I have to justify my tastes?". Unfortunately, such responses are far more common than one might expect. The problem with this sort of attitude is that it nearly completely precludes any possibility of actual progress, and largely just so that the user in question does not have to give back to the community which provided Pidgin for their use in the first place.

Not everyone is a programmer, and we know that. Another standard response (and, again, a reasonable one) is indeed "patches welcome", but we realize and respect that not every user is prepared to take us up on that offer. For those who aren't, describing how changes to Pidgin have affected work flow and usability in some level of detail is a great way to give back to an open source community. Such feedback allows us to learn from our mistakes (as well as our successes) and improve our "product" -- and in a way which is just about guaranteed to be positive for the user taking the time to help out! Of course, we cannot promise to accommodate every work flow or implement every user's favorite feature, but we certainly can take those work flows and features we are aware of into account as we move forward.

Often, while we as Pidgin developers and contributors are engaged in trying to fix behaviors which have proven to be unpopular, users will request (a term which I use as a euphemism, as "demand" is normally more accurate) that an option be added to Pidgin which allows both the new and old behaviors as alternates. Leaving aside the fact that often the new behavior really is broken, and needs to be fixed regardless, this is a disingenuous suggestion. In a recent (on-going, at the time of this writing) debate regarding changes in the behavior of input area sizing on IM windows, I wrote an email which said the following about this:

Options are expensive.

Each individual option may be simple or trivial, but they add up. Options to do with UI behavior are particularly expensive, due to their frequent interactions with the vagaries of UI toolkit behaviors, etc.

This expense takes the form, mostly, of subtle bugs and extra programmer effort. We have had numerous examples of options which appear to be simple on the surface causing numerous bugs and undesirable behaviors. A recent and memorable example of this was the option for persistent conversations -- I think we all agree that the ability to have conversations "open" without an open window is one which is appreciated by many users, but this seemingly simple feature has caused quite an avalanche of small and not-so-small bugs. In fact, there is speculation that the one pixel high input area which some people are seeing stems from this very option.

Anyone who tells you that options are not expensive is either not a programmer, or has never worked on a large program. It is true that orthogonal options in a clean code base can be implemented with little cost in many circumstances, but even the most forward-thinking and competent programmers will be blind-sided by subtle interactions on occasion, especially when throwing third-party libraries and code into the mix.

So, if options are an avenue of last resort, we're left with three other immediate choices in the face of an unpopular (honestly, usually this means "unpopular to a minority", but try convincing a FOSS user holding a minority opinion that he or she does not represent the Gospel truth, some time) development decision: revert the change to previous behavior, keep the new behavior unchanged, or figure out what is wrong with the change and forge an even better solution which satisfies all parties. Again, from the email previously quoted, I said the following on this subject:

Progress is good.

The question is not whether Pidgin can remain exactly the same forever (it obviously can), but whether we want it to. This should be particularly understandable in the world of open source software, where people consider a project which has not released in as little as a few months "abandoned" and ripe for discard. We want to make Pidgin better, we want to make it easier to use, and we want to make it more pleasant to use. This means that statements like "I want the old behavior back", with no justification, are not useful to us. On the other hand, explaining WHY you want the old behavior back, and what precisely it is about the old behavior which makes Pidgin better and more useful to you, allows us to improve our software. It may be (as many users have found in the past) that the old behavior isn't really what you want, it simply afforded some particular functionality which the new behavior has lost. If that functionality can be identified, we might even be able to provide it in a superior way which you find more pleasant and useful to use.

The feature currently under debate is a great example of this. We have had a couple of users who have explained why they need large input areas, and the circumstances under which this functionality is useful to them. We have more or less agreed (I believe) that the new behavior is not sufficient for all use cases, and we do intend to improve it. Using the "why" we have heard from some users, we will hopefully be able to do so in a way which cleanly adds the new functionality while preserving their requirements.

Reverting to old behavior should be seen as a last-ditch effort which is giving up on an attempt to make Pidgin better. It might be the right choice, but the change was made for a reason -- in this case, many people like and want input areas which automatically resize. Numerous iChat and Adium users, for example, have specifically asked about this behavior in the past.

So there it is; we want to avoid options except where options are truly the right choice, and we want to be able to make progress in improving Pidgin, even when those improvements cause behavior to depart from previously established norms in significant ways. In order to accomplish this, we need help -- as Pidgin developers, we use Pidgin in only a limited number of work flows and situations. Input from users with differing habits and expectations gives us a broader perspective, and allows us to improve Pidgin for everyone. A lot of our best ideas and UI changes over the years have been inspired by comments by users, comparisons to other IM clients or software packages, and even third-party contributions in the form of patches or code.

All pleas to the betterment of Pidgin aside, defending assertions of goodness and badness is simply the right thing to do. Beyond even that, it is a reasonable bar for developers to apply to users when judging whether their opinions and commentary are worthy of time and effort. While it is true, as discussed above, that not all software users are software programmers, all software users should, with some application of effort, be able to express their opinions about features and changes in a clear and logical fashion. While some Free Software users seem to think that their right to use and modify software extends to a right to have software modified for them (we have taken to calling this Free Software User Entitlement Syndrome), the fact of the matter is that Free Software is a privilege, not a right. (Lest anyone become upset with this, note that I do not mean that the rights granted by, e.g., the GNU Copyleft are not rights; bear with me.) This is because that software must be created by someone, and that someone has every right to create the software they wish to create. Once that software is created and released, every Free Software user has the right to use it in all of the glory allowed and guaranteed by its licensing, but the choice to create rests with those who have the ability and inclination. Not surprisingly, those with the ability and inclination to create Free Software may choose to spend their valuable time assisting users who give back. This is not only more rewarding than helping users who issue nothing but demands, but it seems (at least to me, and to some other Free Software developers) to produce a better product. Changes made with an eye to existing and articulated use cases are guaranteed to help at least the person who articulated the use case, for example.

Consider the issue to be similar to democracy. If you didn't vote in the election, you can't complain about the results. If you are unwilling to provide useful input to the developers of the software you use, then you forfeit any right to ask for changes. The difference between useful input and an impudent demand is nothing but justification, clear explanations, and logical argument. This is not to say that every FOSS developer you approach is beholden to implement any suggestion which you take the time to defend, but said developer certainly can be expected to at least consider your suggestion fairly if you put in some effort. Remember, at the end of the day, it is the developers' sweat and effort that go into the software, so the buck stops there.
Help us help you
July 01, 2008 01:11 AM by Ethan Blanton

Alles sehr merkwürdig.

Gruß odigo
 
Oben