[pkg-xmule] Re: neues Upstream-Release für xMule und Revision 1.9.5-2

[David Schmitt]

On Wednesday 23 March 2005 14:33, Daniel Leidert wrote:
> Am Mittwoch, den 23.03.2005, 13:16 +0100 schrieb David Schmitt:
> > On Tuesday 22 March 2005 16:57, Daniel Leidert wrote:
> > > Hallo David,
> > >
> > > Da du dich leider noch nicht auf der xMule-Mailing-Liste eingetragen
> > > hast, schreibe ich dir das per PM und CC an Noèl.
> >
> > Habe ich jetzt gemacht.
> >
> > > xMule hat eine neues Release veröffentlicht (1.10.0). Die Arbeiten =
an
> > > der xMule-Paket-Revision 1.9.5-2 sind eigentlich abgeschlossen. Ich
> > > will in den nächsten Minuten nur noch eine Man-Page für ed2k.xmul=
e-2.0
> > > einfügen. Danach würde ich gerne alles taggen, bevor ich die Arbe=
it an
> > > dem neuen Release aufnehme. Mein Problem ist, dass ich nicht DD bin u=
nd
> > > daher auch nicht meinen Namen unter den Changelog-Eintrag setzen kann.
> >
> > Das ist so nicht ganz korrekt. Der Name unter dem Changelog Eintrag hat
> > nur wenig mit dem Uploader/Maintainer zu tun.
>
> Ähm, ich würde das Gegenteil behaupten wollen. Lintian wird sich
> beschweren, wenn das Paket nicht mit einer NMU-Revision versehen ist und
> der Name im Changelog-Eintrag vom Namen im Maintainer-Feld in
> debian/control abweicht. 

Achso. Wie wäre es mit so:

xmule (1.9.5-2) UNRELEASED; urgency=medium

  Daniel Leidert:
  * ...

 -- xMule Package Maintainers <pkg-xmule-...

Mit der Mailingliste als Maintainer und Noèl weiterhin als uploader? Das Paket 
muss dann eh mit Noèls Schlüssel signiert sein.

> Lintian wird noch eine weitere Warnung melden, 
> da /usr/bin/ed2k keine Man-page hat. Das würde ich aber gerne mit den
> aMule-Maintainern regeln, so dass die gleich noch ein dpkg-divert für
> ed2k.1.gz machen (mit dem Binary funktioniert das ja ganz gut). Dann
> kann die Manpage auf ed2k.xmule umgeschrieben werden und Lintian dürfte
> keine weiteren Warnungen melden. Das ist in jedem Fall ein Punkt, der
> möglichst vor dem Release einen xMule 1.10.0er Pakets zu tun wäre.

Wäre praktisch.

> > > Allerdings habe ich starke Skrupel einfach deinen Namen unter diesen
> > > Eintrag zu setzen. Folgendes wäre möglich. Ich verändere den
> > > Changelog-Eintrag zu einem NMU 1.9.5-1.1 und tagge es danach
> > > entprechend mit debian_version_1_9_5-1_1. Danach beginne ich mit xMule
> > > 1.10.0 und lade sie Quellen hoch.
> >
> > Ja, wenn 1.10 wirklich ein offizielles stabiles Upstream release ist,
> > sollten wir schauen, dass wir es noch in sarge reinkriegen.
>
> Prinzipiell ACK, aber JFTP: 1.10.0 sollte sich nicht allzu sehr von
> 1.9.5 unterscheiden. Das Problem, dass xMule sich nicht mit Servern
> verbinden kann, die lugdunum in einer aktuellen Version laufen haben,
> wird sich ebenfalls nicht damit lösen (wenn ich die Ankündigung von T=
ed
> richtig verstanden habe).

Ja, ich hab's mir auch durchgelesen. Schade eigentlich :(

> >  Das 1.9.5er hat ja so seine Probleme...
>
> 1.9.5-1 musste Probleme haben, da ja die Variablen PACKAGE_* durch die
> config.h aus dem libcrypto++5.2-Paket redefiniert wurden. Das kann AFAIK
> einige kritische Fehler verursachen. 

Komisch, ich hab's gerade mit einem up-to-date cvs gebaut und immer noch 
Warnungen wegen dem PACKAGE_* Zeug bekommen.

> Über 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301033 bin ich
> allerdings ein wenig erstaunt. Das Problem sollte eigentlich nicht mehr
> in der 1.9.5 vorkommen.

Mir ist der xmule (vom CVS) gerade wieder mit 

xmule: pthread_mutex_lock.c:78: __pthread_mutex_lock: Assertion 
`mutex->__data.__owner == 0' failed.

gestorben. :( der Backtrace ist komplett in wx/GTK/glibc code. Keine Ahnung 
was da passiert.

Gleich darauf hab' ich eine SEGV gefangen:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1224844544 (LWP 17426)]
0xb7b1e6fc in wxEvtHandler::ProcessPendingEvents ()
   from /usr/lib/libwx_gtk-2.4.so.0
(gdb) bt full
#0  0xb7b1e6fc in wxEvtHandler::ProcessPendingEvents ()
   from /usr/lib/libwx_gtk-2.4.so.0
No symbol table info available.
#1  0xb7ade721 in wxAppBase::ProcessPendingEvents ()
   from /usr/lib/libwx_gtk-2.4.so.0
No symbol table info available.
#2  0xb7a7c454 in wxWakeUpIdle () from /usr/lib/libwx_gtk-2.4.so.0
No symbol table info available.

Auch nicht besser. Da dürfte irgendwas die Eventqueue ruinieren :(


MfG David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15