Bug#403380: Bug#403879: ffscan filename conflict
Sorry for late reply, and thank you for your advices and works. > > Well, unless it looks like forutil should be removed, > > I think it has the "older" rights. > I'd prefer not to have them conflict, since FORTRAN use is still common > in gromacs's field -- co-installability would be a benefit. Best to > bite the bullet and rename one, I think. > > Since I haven't heard from Taketoshi, I'll rename the binary in gromacs > and document the change appropriately. I'd hate to see either of our > packages miss the etch release by delaying too long. Thanks for your help. I appreciate your work much. -- Taketoshi Sano: <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378840: xcalendar-i18n: pixmap and help file location problem
Hi. on "Wed, 19 Jul 2006 10:09:24 +0100", with "Bug#378840: xcalendar-i18n: pixmap and help file location problem", Matthew Foulkes <[EMAIL PROTECTED]> wrote: > Package: xcalendar-i18n > Version: 4.0.0.i18p1-13.2 > Severity: normal > > When xcalendar starts, the following error messages appear: > > Warning: Cannot convert string "/usr/local/lib/X11/xcalendar/larrow.xbm" to > type Pixmap > Warning: Cannot convert string "/usr/local/lib/X11/xcalendar/rarrow.xbm" to > type Pixmap > Warning: Cannot convert string "/usr/local/lib/X11/xcalendar/quit.xbm" to > type Pixmap > Warning: Cannot convert string "/usr/local/lib/X11/xcalendar/qmark.xbm" to > type Pixmap > > Although xcalendar still works, various buttons and arrows in the user > interface are replaced by text descriptions and the help screen is > unavailable. I checked it on my system, but I can't find this problem. > The pixmap and help files are present in /usr/share/xcalendar, but > xcalendar is looking for them in /usr/local/lib/X11/xcalendar. > > A temporary workaround is to link /usr/share/xcalendar to > /usr/local/lib/X11/xcalendar. Checking by "strings /usr/bin/xcalendar |grep -i local" just outputs "localtime", so xcalendar binary doesn't contain "/usr/local/..." path in it. Maybe conffiles or environment variables affects on your system, I suppose. Won't you please check it by "grep -i map /etc/X11/app-defaults/XCalendar" and by "set |grep -i map" ? Thanks for your help. -- Taketoshi Sano: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#197914: [#197914, #259266, #322791, #342746, #357029] NMU for linuxdoc-tools
Thanks for your help. Please go on to do NMU. In <[EMAIL PROTECTED]>, on "Tue, 9 May 2006 19:26:51 +0200", Agustin Martin <[EMAIL PROTECTED]> wrote: > http://corbu.aq.upm.es/~agmartin/linux/store/debian-linuxdoc-tools/ I've got it and checked it. It seems OK. -- Taketoshi Sano: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#360500: RM: tcltk8.0-ja -- ROQA; uninstallable, obsolete version of tcl/tk
Thank you for your help on packaging work. I admit that package tcltk8.0-ja is too old, and can be removed from Debian safely now. It was only for work-around until the normal tcltk package can handle Japanese text correctly, and now I have checked and make assured that the normal tcl8.4/tk8.4 package work enoughly. So, tcltk8.0-ja can be removed from Debian, and I request that action as the current maintainer. Sorry for late responding. It took some time to check the functionality of Japanese text handling about the current normal tcltk package. Thanks. -- Taketoshi Sano: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346837: intent to upload sponsored NMU to fix xlibs-dev bug
Hi, Justin. > I intend to NMU a fix for this bug sponsored by some member of the QA > group; patch attached. My pbuild result of this patch was clean, and > produced a binary package with expected debdiff output from the most > recent version in sid. Build logs and debdiff output are attached. Thanks for you patch. Please do NMU if you can. > Please note that maintainer uploads are preferred to NMUs! If you are > able to upload, then please do so. Sure, and sorry. It will need other weeks before I can do it. -- Taketoshi Sano: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> pgpUR81CLkhDx.pgp Description: PGP signature
Bug#346652: Thanks (Re: Bug#346652: Intention to NMU)
Hi, Luk. Thank you for your work. I appreciate your help. -- Taketoshi Sano: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> pgp5jINkRq71a.pgp Description: PGP signature
Bug#340902: john: /usr/sbin/mailer does not ignore comments
Hi, Thorsten. In <[EMAIL PROTECTED]>, on "Sat, 26 Nov 2005 21:41:34 +0100", with "john: /usr/sbin/mailer does not ignore comments", Thorsten Gunkel <[EMAIL PROTECTED]> wrote: > I would have found this bug earlier but I assumed that /usr/sbin/mailer would > be a generic mailer and no john related stuff. This was already requested in > bug #114059 by Taketoshi Sano (Cc'ed) and I totally agree with him. Please > talk to > upstream and ask them to rename it to john-mailer or something similar. Sorry that I've purged this package since I received the answer to my report from the maintainer at that time. So I don't know the current status. I've thought that /usr/sbin/mailer is too generic name and it sometimes makes users to mistake it as "normal" mailer, but the script in that package was john specific (at least when I checked it) and just work for john package only (IOW, it doesn't work at all for other purposes), so I think this specific script should have the specific name related to john. Unfortunately the maintainer at that time (the maintainer seems to change now) can't understand my point of view, so I've stopped using that package. I hope the current maintainer can understand the complaint from novice users, as well as expert users. Bye. -- Taketoshi Sano: <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#259938: xpostit: FTBFS with gcc-3.4: conflicting types for 'malloc'
Hi. on "Sat, 29 Oct 2005 02:05:18 +1000", Rob Weir <[EMAIL PROTECTED]> wrote: > This bug has been sitting around in the BTS for a while now, and is now > RC; do you think you'll have time to make a new upload soon? Ah..., sorry, no. Maybe it will need other weeks. I hope to clean up my pending Debian tasks before the end of this year, but if someone can help me by NMU, I'll appreciate it. Thanks. -- Taketoshi Sano: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335511: xpostit: "Show All Notes" does not show anything
Hi. This might be the same as #118332. Maybe you use wmaker as a X window manager, don't you ? If so, this problem depends on a X window manager, and it needs to check the source code of some X window managers to find the cause of the problem. In <[EMAIL PROTECTED]>, on "Mon, 24 Oct 2005 13:43:07 +0200", with "Bug#335511: xpostit: "Show All Notes" does not show anything", Alberto Maurizi <[EMAIL PROTECTED]> wrote: > Package: xpostit > Version: 3.3.1-8 > Severity: grave > Justification: renders package unusable > If I create a note, write some stuff, select "Hide All Notes" > then the "Show All Note" function does not make them to appear > again (they are basically lost if unsaved). The only way to make > them to appear again is to save them, exit xpostit and re-open > it. > > The same if I use "Left Mouse Button + CTRL key". What action do you expect by this key combination ? Is this independent from the specific X window manager ? Tnx -- Taketoshi Sano: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#321998: [NMU] Re: linuxdoc-tools: [sgml2latex] Fails to produce DVI output with teTeX-3.0, always PDF
Thank you Frank for your contribution. I'll check your patch later. -- Taketoshi Sano: <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#175575: [discuss] linuxdoc text backend
Thank you David. Sorry for long absence, I've been very busy for these years. I'll check your report in weeks. -- Taketoshi Sano: <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#250086: extipl: please add amd64 support
Hi. Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Just plain lseek will do. With _FILE_OFFSET_BITS=64 that is all you > need. I don't see the point of using the lseek64 alias. I don't know much about that. My experience told me that libc5 system had llseek, but glibc system don't. And _llseek has just worked on both of them. If you know much about 64bit file access, then please let me know, what point do you see of using "just plain lseek and _FILE_OFFSET_BITS=64". And, I want to know from which version of glibc we can use it safely (or can we use it on libc5 too ?) It will help me to explain this to the upstream. Thanks. -- Taketoshi Sano: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#250086: extipl: please add amd64 support
Hi. Thank you for your attention. with "Re: Bug#250086: extipl: please add amd64 support", Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED]:~% apt-cache show extipl > Package: extipl > Version: 5.04-1.0.0.1.pure64 > Filename: > pool/unstable/main/amd64/e/extipl/extipl_5.04-1.0.0.1.pure64_amd64.deb > Description: Yet Another Boot Selector for IBM-PC compatibles. > Extended-IPL is a boot selector which is upper compatible with > original IBM IPL. This package includes the installer for this > boot code which is written into MBR of your hard disk. > . > With this boot selector, you can select a partition from > all the partitions including the logical partitions as well as > the primary ones in all the BIOS supported disks when booting a PC, > and then it will boot up the OS reside at the selected partition. > installed-size: 24 > ^^^ >'residing on' or 'that resides on' I'll update the description in the next upload. > Is that from your patch or another one? That amd64 package (5.04-1.0.0.1.pure64) may have been created by Christopher L Cheney. changes file for it has the "Changed-By" line. > > Extipl uses syscall5 _llseek on i386 to reach the right sector > > in the hard disk where the boot code is installed in. > > So I'm afraid that it can't work on pure 64bit environment. > > But if any amd64 system can run all i386 32bit code, > > then it might run that _llseek system call too. > > It should not use _llseek on i386 either. The right way is to define > 64bit file operations (LFS) and use the normal lseek (which then uses > 64bit off_t). Maybe. I'll consult it with the upstream later. # When the extipl began to use __llseek on linux, # there are both of libc5 systems and glibc2 systems. # So __llseek was the simplest way at that time, # or it seemed that, at least. # Now I hope that we can use lseek64 on most of linux systems, # can't we ? -- Taketoshi Sano: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#266381: gsfonts-wadalab: FTBFS if not root
Hi. on "Tue, 17 Aug 2004 21:40:17 +0200", Roland Stigge <[EMAIL PROTECTED]> wrote: > trying to build the package in a clean environment (pbuilder chroot), I got: > > = > [...] (snip) > fakeroot debian/rules clean > if [ ! -d ./debian ]; then echo "Wrong place!"; exit 1; fi > if [ "$EUID" != "0" ]; then echo "Must be root!"; exit 1; fi > Must be root! > make: *** [clean] Error 1 > = > > Is this really needed? I think root check is required. I don't know why fakeroot doesn't set $EUID to 0. On my system, using fakeroot sets both of $UID and $EUID to 0. Anyway, I've changed $EUID with $UID, and upload it. Please check and let me know if this can solve the problem. Thanks. -- Taketoshi Sano: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#250086: extipl: please add amd64 support
(This mail is copied to amd64 list) Hi. I'm now working on that package. > > I don't know about amd64. Does extipl fully work on that arch ? > > Your patch seems just to replace "i386" with "amd64 i386" on > > the Architecture field in control file. Is it enough to use > > extipl on amd64 ? extipl need BIOS support. Does all amd64 > > system have the required BIOS support as i386 ? > > I am not certain exactly what extipl needs to work, but the bios on > amd64 systems is essentially the same as i386. On my 2 amd64 systems the > bios looks identical to bios on regular i386 like P4's. Actually, I am > pretty sure that to go into 64bit mode the OS itself has to swith the > processor into that mode, amd64 systems can run i386 code just fine. > That is part of the reason that Debian is pushing towards multiarch > where both i386 and amd64 libraries can be installed on the same system > at the same time (as well as sparc and sparc64, etc). Multiarch > probably won't be completed for 6mo-1yr though due to the amount of > changes to packaging that is needed. Extipl uses syscall5 _llseek on i386 to reach the right sector in the hard disk where the boot code is installed in. So I'm afraid that it can't work on pure 64bit environment. But if any amd64 system can run all i386 32bit code, then it might run that _llseek system call too. > > And, can you work for amd64 support, if any bug report comes > > on amd64 specific feature ? > > There is a debian-amd64 mailing list that you can forward issues that > you are unable to resolve to just as there is for the other archs. OK. I send the copy of this mail to the list. I hope it will work. > > I've experienced many times that "one user claims to do something, > > there must be other users who claim not to do it". So I'm nervous > > now to change the package. > > > > By the way, why this bug is important ? is wishlist not enough ? > > I was told in the past FTBFS on new archs were considered "important" so > that is why I set it as it is. I think that the advice is for "Architecture: any" packages. But anyway, I'll upload the package. Let's see what happens. Bye. -- Taketoshi Sano: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296931: asclassic: postinst use wm-menu-config which is deprecated
Hi, Bill. Thank you for pointing out that bug. > Hello Taketoshi, > > I would like to remove wm-menu-config in etch, but for that I need > packages to stop using it in sarge. Fortunately asclassic is the last > remaining package that use it, so I am eager to get it fixed. > > Do you plan to upload asclassic, or would you prefer I do a NMU to fix > this bug ? I'm trying to fix it up now, so please wait for this week. -- Taketoshi Sano: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
