Martin Loschwitz wrote: > Most of you have probably already noticed it, but i am going to > describe the situation one more time here so it gets stored in an > archive somewhere. > > As of mICQ 0.4.10.1, the source code includes some bits that prevent > mICQ from starting up on Debian boxes in specific (if EXTRAVERSION is > not set to some value at compile time and the username you run the > program with is not 'madkiss'). Upstream is obviously rather annoyed with you, but this seems like a rather childish retaliation on his part. > In fact, at first users think that mICQ is starting up perfectly > normal, but after the client got logged in into the server, it prints > the following message and exits after that: > > You're using the mICQ package provided by Debian. Since the Debian > maintainer is extremely uncooperative, you're adviced to use the > better quality package from micq.org. Simply add the following line to > your /etc/apt/sources.list to track stable versions of mICQ: > deb http://www.micq.org/debian stable main > To track CVS snapshots, add: > deb http://www.micq.org/debian testing main > Source packages may be retrieved similarly. > > This code can be found in file "src/preferences.c" in mICQ source code, > starting at line 114. > > md5sum of the upstream-tarball that contains this version of preferences.c: > c0c84ed9b5df0d9ced060a9eed11d36b micq-0.4.10.1.tgz > > I have to admit that not setting EXTRAVERSION in debian/rules is a > bug, ok, but not setting such an un-important variable (it _is_ > unimportant after all) should not lead to a behaviour like the one > described above. It looks like the only intention behind this code is > to achieve an object lesson effect for the maintainer, in cleartext, > me. No, I don't think I agree that EXTRAVERSION is unimportant. From what Rudiger wrote in the previous thread about mICQ, this value is transmitted to ICQ servers, and is meant to function equivalently to a web browser's User-Agent string. This seems quite sensible to me. If a particular client-side bug is only reproducible with a particular distro's package, then that would be a very good indication that it's caused by something the package maintainer is doing wrong. This is not an excuse for the easter egg, which, as I've already said, I think is quite childish. > In my opinion, with this step, mICQ has proven as dishonorable to be > distributed with Debian anymore (especially since nobody knows what > idea upstream will have as next, maybe it's a very funny 'rm -rf /'?). > Thus, i would like to request removal of the package from > distribution. If you don't want to handle it anymore, a request for adoption might be more suitable. It sounds as though upstream's problem is with you personally, not Debian as a whole, so he might stop putting in little easter eggs like this if the package is maintained by someone he is happier to work with. I don't intend this as a criticism of you personally. But obviously you and Rudiger do not mix well. The easter egg is obnoxious, but I see no indication that mICQ upstream would stoop so low as to do something actively destructive. > Additionally, I suggest to consider to add this piece of software to > the "unable to package" list[1]. I don't see a justification for that. If it were to become clear in the future that upstream intends to keep putting anti-Debian easter eggs in his code no matter who maintains the package or how far backward they're willing to bend to make him happy, then it might be justified, but as of this moment it seems that his issue is with you, not with Debian. Craig
Attachment:
pgp2Uz4IbsCKp.pgp
Description: PGP signature