Bug#675005: src:xshisen: maintainer address bounces
Hi! Ansgar Burchardt wrote: > Package: xshisen > Version: 1:1.51-3.2 > Severity: serious > > The maintainer address for xshisen bounces: > I made a new package updating my email address as well as acknowledging NMUs some months ago: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668148 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543136: Requested for Removal
Hi Lucas, Thanks for the report. I've requested this package to be removed (dead upstream.) -- Zak B. Elep -- 1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D I like the idea of 256 bits, though: 32 for the (Unicode) character leaves room for 224 Bucky bits, which ought to be enough for anyone. -- Roland Hutchinson, in alt.folklore.computers signature.asc Description: This is a digitally signed message part
Bug#392894: Tagging #360950
package robotour tags 360950 help moreinfo unreproducible tags 392894 help moreinfo unreproducible thanks I've `forwarded' this to upstream[0]. I hope they can help. [0] http://robocom-forum.rrobek.de/phpBB2/viewtopic.php?p=251#251 Cheers, Zakame -- Zak B. Elep [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392894: robotour: Freezes when pressing Start.
Hi Charles! =) On 10/14/06, Charles Plessy <[EMAIL PROTECTED]> wrote: When I started robotour from the command line and pressed "Start" without doing something else before, the programm froze, and froze my window system (fluxbox). I had to log to the computer via ssh and kill robotour to unfreeze fluxbox. [...] Hmmm, I do remember running robotour some weeks ago and experiencing the same; thanks for telling me about it. :) On some cases, robotour manages to send a popup saying "fatal error: 17 - No robots specified." before freezing. Also, the freezing of the window system does not allways happen. The freeze of robotour is however completely reproducible. I also reproduced the bug on a separate i386 machine. I suspect that this bug may have something to do with WxWidgets; can you provide me with a backtrace for both ppc and i386? Thanks again! =) Cheers, Zakame -- Zak B. Elep || http://zakame.spunge.org [EMAIL PROTECTED] || [EMAIL PROTECTED] || [EMAIL PROTECTED] 1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378198: robotour: FTBFS: error: X11/Xlib.h: No such file or directory
Hi Julien! =) On 7/15/06, Julien Cristau <[EMAIL PROTECTED]> wrote: (robotour should depend on libgl1-mesa-dev instead of xlibmesa-gl-dev, though) 3.2.1-3 already does depend on libgl1-mesa-dev in response to correctly depending on Xorg libraries, so libx11-dev is really needed. Anyhow this is actually an old behavior, it should have been fixed back before mentors relaunched, but well, that's life :/ I'll expedite the release of 3.2.1-3 as soon as possible; I would prefer fixing #360950 first... -- Zak B. Elep || http://zakame.spunge.org [EMAIL PROTECTED] || [EMAIL PROTECTED] 1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378198: robotour: FTBFS: error: X11/Xlib.h: No such file or directory
Hi Julien! (and gregor, who also confirmed the fix! =) On 7/14/06, Julien Danjou <[EMAIL PROTECTED]> wrote: There was a problem while autobuilding your package: > Automatic build of robotour_3.2.1-2 on avidan by sbuild/i386 0.48 > Build started at 20060714-0105 > ** [...] > In file included from /usr/include/wx-2.6/wx/gtk/glcanvas.h:24, > from /usr/include/wx-2.6/wx/glcanvas.h:26, > from robwxgl.h:26, > from robwxvis.cpp:32: > /usr/include/GL/glx.h:38:22: error: X11/Xlib.h: No such file or directory > /usr/include/GL/glx.h:39:23: error: X11/Xutil.h: No such file or directory Thanks for the bug; this has been fixed in 3.2.1-3 that I'll be uploading to mentors.d.n again (it was already there, but there were no sponsors available at the time, until mentors relaunched.) Can I ask you to sponsor for me? :) Thanks in advance! Cheers, Zakame -- Zak B. Elep || http://zakame.spunge.org [EMAIL PROTECTED] || [EMAIL PROTECTED] 1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#368681: cvs: does not flag conflicted copies anymore
Hi again! =) On 5/30/06, Steve McIntyre <[EMAIL PROTECTED]> wrote: Just a heads-up; things are not as simple as I'd hoped. I've spent several hours today trying to get old behaviour back, and so far it's not working... Indeed =( I've been held back by today's power blackout (I just got back on now,) but I was looking into this last night, and grepping the ./src/ChangeLog following the clues as included in your links reveals this (its coincidence to my birthday is purely coincidental ;): 2005-09-22 Derek Price <[EMAIL PROTECTED]> * classify.c (Classify_File): If a file had a conflict and the timestamp hasn't changed, it still has a conflict. Add comment about how T_MODIFIED could later turn out to have conflict markers and why it should not be checked in this function. * client.c (send_fileproc): Don't send contents for files known to have conflicts unless this is for `cvs diff'. * commit.c (check_fileproc): T_CONFLICT should be handled like T_MODIFIED, since force could be requested. Simplify logic since T_CONFLICT can now be trusted. * rcs.c (RCS_Checkout): Comment noexec behavior in header block. * server.c (serve_unchanged, serve_is_modified): Handle conflicts. * status.c (status_fileproc): Trust T_CONFLICT to simplify. * subr.c (file_has_conflict): Removed. * subr.h (file_has_conflict): Remove proto. * update.c (update_fileproc): Trust T_CONFLICT. (RegisterMerge): New function factored from... (merge_file, join_file): ...these two functions. * vers_ts.c (time_stamp_server): Handle = conflict timestamps in server entdata. * sanity.sh (files-12): Account for slight behavior improvement. (status, conflicts, mwrap): Account for corrected behavior. (join-readonly-conflict-10): Correct comment. (binfiles-con1b): New test for correct behavior. * classify.c (Classify_File): Consolidate redundant conditionals. Thoughts? Also, would convincing upstream to undo this be feasible? It seems that we're not the only ones complaining... Cheers, Zakame -- Zak B. Elep || http://zakame.spunge.org [EMAIL PROTECTED] || [EMAIL PROTECTED] 1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#368681: cvs: does not flag conflicted copies anymore
Hi all! =) On 5/25/06, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: Can we have a warning in place until then? Of course this bug should be warning enough (given the severity), but not everyone uses apt-listbugs... I'm already on the trail to see if reversing this works... If so, we can expect a -3 stomping this RC out in the shortest time :D I do suppose however, that still putting the warning in would be nice, especially for folks expecting the _new_ behavior (could be wrogn though)... Cheers, Zakame -- Zak B. Elep || http://zakame.spunge.org [EMAIL PROTECTED] || [EMAIL PROTECTED] 1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D
Bug#367888: FTBFS: ‘LIB_DIR’ was not declared in this scope
package xshisen tags 367888 + fixed pending thanks Hi Martin! =) On 5/19/06, Martin Michlmayr <[EMAIL PROTECTED]> wrote: Which is strange because -DLIB_DIR is there but I can reproduce this, so it seems real. > Automatic build of xshisen_1.51-1-2 on bilbao by sbuild/sparc 85 ... > g++ -c -g -Wall -O2 -DNO_GLOBAL_HIGHSCORE -I -DLIB_DIR=\"/usr/share/games/xshisen\" -DDAT_DIR=\"/var/games\" -DHAVE_CONFIG_H main.C -o main.o Thanks for the bug, it's my first RC :D. Hmmm, looking at the line above, I see the `-I' flag there, and it shouldn't be just a blank (or, guessing at g++'s behavior, it swallows up the -D flags...) I have solved it by manually defining x-includes and x-libraries upon running `./configure'. The fix is now in the new 1:1.51-2 package at mentors[0] which also really fixes the strange versioning bug of this package. [0] http://mentors.debian.net/debian/pool/main/x/xshisen/xshisen_1.51-2.dsc As I am not yet authorized to upload directly to the archives, I am also sending this to Marga Manterola who did the last sponsored upload for 1.51-1-2. Thanks for the heads-up! =) Cheers, Zakame -- Zak B. Elep || http://zakame.spunge.org [EMAIL PROTECTED] || [EMAIL PROTECTED] 1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D
Bug#340852: gpsd: FTBFS: undefined reference to `floor'
package gpsd tags 340852 patch thanks control ;) I've fixed this in my merge of gpsd for Ubuntu. Attached is the (rather trivial) fix, though I suspect that a better solution would be to notify upstream of this problem and modify ./Makefile.am and update the autotools infrastructure accordingly. Cheers, Zakame -- Zak B. Elep || http://zakame.spunge.org [EMAIL PROTECTED] || [EMAIL PROTECTED] 1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D diff -u gpsd-2.30/debian/rules gpsd-2.30/debian/rules --- gpsd-2.30/debian/rules +++ gpsd-2.30/debian/rules @@ -51,7 +51,7 @@ dh_testdir # Add here commands to compile the package. - $(MAKE) + $(MAKE) LDFLAGS="$(LDFLAGS) -lm" touch build-stamp
