Bug#508413: Please remove remaining CERNLIB packages from Sid
reassign 508413 ftp.debian.org retitle 508413 RM: cernlib -- RoM; orphaned, dead upstream reassign 508495 ftp.debian.org retitle 508495 RM: paw -- RoM: orphaned, buggy, dead upstream reassign 508496 ftp.debian.org retitle 508496 RM: geant321 -- RoM: orphaned, dead upstream reassign 508498 ftp.debian.org retitle 508498 RM: mclibs -- RoM: orphaned, dead upstream thanks Hi, I know it seems a bit contradictory to have a RoM: orphaned title on these bug reports. Please read RoM as request of former maintainer if you like. I am of the opinion that the various CERNLIB packages are essentially unmaintainable and should be removed from Sid instead of continuing to be dead weight there. No one has completed the job of adopting them (though there were a couple people who had some initial interest, in CC) after more than two years spent orphaned, nor attempted to fix any bug reports for them for over a year. They were already purged from Squeeze prior to its release. Any remaining users really ought to switch to some other software, as upstream has been completely dead for five years now. (I would suggest ROOT, but tragically that seems to be no longer maintained within Debian either, and I wish I had the free time to do something about that.) I regret that it was not possible for CERNLIB to go into Squeeze to provide additional time for users to transition away, but maybe it's for the best. For more info, please see: [1] http://lists.debian.org/debian-science/2008/09/msg00028.html [2] http://bugs.debian.org/508413 [the cernlib RFA bug] Thanks and best regards, -- Kevin B. McCarty kmcca...@gmail.com WWW: http://www.starplot.org/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590717: geant321: new upstream available geant4
Hello Andres, I am well aware of Geant4 ;-) It is not a drop-in replacement for GEANT 3.21 (indeed, it differs in every way but the name). Strictly speaking you should have filed this request for Geant4 as an RFP (Request for Packaging) bug against the wnpp pseudo-package, but it wouldn't have done any good; please see below. There are unofficial Debian packages of Geant4 available (originally authored by me, now maintained by others). Please see: http://wiki.debian.org/DebianScience/Geant4 http://lcg-heppkg.web.cern.ch/lcg-heppkg/debian/index.html Official packages are not currently possible because Geant4 has a dependency on CLHEP, whose upstream never properly licensed it, so that CLHEP is undistributable except by permission of the authors (despite numerous requests over the years). best regards, -- Kevin B. McCarty kmcca...@gmail.com WWW: http://www.starplot.org/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552905: A couple bug reports in Paw and Mn_Fit
I've orphaned these packages and am afraid I have no time to look into these FTBFS bugs. Francois, if you are intending to pick up paw and/or mn-fit, you might want to check into them (bugs 552905 against paw and 552852 against mn-fit). Seems like a recent change in libc headers has broken some things? best regards, -- Kevin B. McCarty kmcca...@gmail.com WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549244: O: viewglob -- A graphical display of directories referenced at the shell prompt
Package: wnpp Severity: normal Orphaning my remaining packages. -- Kevin B. McCarty kmcca...@gmail.com WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549245: O: feynmf -- set of LaTeX macros for creating Feynman diagrams
Package: wnpp Severity: normal Orphaning my remaining packages. -- Kevin B. McCarty kmcca...@gmail.com WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507429: [cfortran] any news
On Tue, Mar 24, 2009 at 5:43 AM, Bastien ROUCARIES bastien.roucar...@enseeiht.fr wrote: Package: cfortran Version: 4.4-13 Any news of this bug ? No real news, sorry. Next time I make a cfortran upload I'll do something about it. I don't really agree with the patch since (1) it adds mention if a Debian-specific directory in the header file itself (instead of just in the documentation) and (2) it says that the words in all-caps (THIS FILE IS PROPERTY ... CFORTRAN.H PACKAGE) are a license, which I do not believe is the case (as per my email of December 1). Most likely I'll just stick the LGPL boilerplate and the original (non-free) license in its entirety into the .h file. Any objection to that? -- Kevin B. McCarty kmcca...@gmail.com WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515632: Seems fixed in lenny-proposed-updates
Hi folks, This bug seems to be fixed in ROOT Debian packages 5.18.00-2.3~lenny1, in lenny-proposed-updates. If you would like to test, the package of root-system-common is already available from here: deb http://ftp.us.debian.org/debian lenny-proposed-updates main Fix should go into the next point release of Lenny. -- Kevin B. McCarty kmcca...@gmail.com WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508495: RFA: paw -- Physics Analysis Workstation - a graphical analysis program
Package: wnpp Severity: normal RFA'ing paw along with Cernlib, please see #508413 for details. -- Kevin B. McCarty kmcca...@gmail.com WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508501: RFA: mn-fit -- interactive analysis package for fitting data and histograms
Package: wnpp Severity: normal RFA'ing Mn_Fit along with Cernlib, please see #508413 for details. -- Kevin B. McCarty kmcca...@gmail.com WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508499: RFA: mclibs -- [Physics] CERNLIB Monte Carlo libraries
Package: wnpp Severity: normal RFA'ing mclibs along with Cernlib, please see #508413 for details. -- Kevin B. McCarty kmcca...@gmail.com WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- Kevin B. McCarty kmcca...@gmail.com WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- Kevin B. McCarty kmcca...@gmail.com WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508500: RFA: cfortran -- Header file permitting Fortran routines to be called in C/C++
Package: wnpp Severity: normal RFA'ing cfortran along with Cernlib, please see #508413 for details. -- Kevin B. McCarty kmcca...@gmail.com WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508496: RFA: geant321 -- [Physics] Particle detector description and simulation tool
Package: wnpp Severity: normal RFA'ing GEANT 3.21 along with Cernlib, please see #508413 for details. -- Kevin B. McCarty kmcca...@gmail.com WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- Kevin B. McCarty kmcca...@gmail.com WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508498: Cross-referencing CERNLIB RFA bugs
The following CERNLIB-related source packages are now officially up for adoption. For those that have any interest in CERNLIB in Debian, refer to [1] and [2] for more information and for my future intentions with regards to any of these packages that are not adopted by the release of Squeeze. Please do not adopt one of these packages unless you are also willing to adopt all of its direct and indirect dependencies in the following list, and please read [1] THOROUGHLY before doing so. [1] http://lists.debian.org/debian-science/2008/09/msg00028.html [2] http://bugs.debian.org/508413 [the cernlib RFA bug] - == depends upon: mn-fit - paw geant321 - paw paw - cernlib mclibs - cernlib cernlib - cfortran RFA bugs are at: cernlib: http://bugs.debian.org/508413 paw: http://bugs.debian.org/508495 geant321: http://bugs.debian.org/508496 mclibs: http://bugs.debian.org/508498 cfortran: http://bugs.debian.org/508500 mn-fit: http://bugs.debian.org/508501 -- Kevin B. McCarty kmcca...@gmail.com WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508413: RFA: cernlib -- CERNLIB data analysis suite
Package: wnpp Severity: normal Hello, [CC'ed to Fedora CERNLIB maintainer and to debian-science] I intended to submit this RFA a while ago and was finally prodded into action by the discussion on debian-devel over libgtk1.2. As previously mentioned on debian-science at [1], I am not interested in maintaining CERNLIB and related software into the indefinite future. Its upstream is dead and it is questionable whether it will even be possible to keep it operational or even compilable as the build tools and infrastructure of Debian continue to evolve. Please refer to [1] for details if you are interested in taking over the package. [1] http://lists.debian.org/debian-science/2008/09/msg00028.html As an update to that email, I received one offer of help (by private email) on September 15, a week after my posting to debian-science, but I did not hear any more from this person after I replied to that email. As promised, I will continue to do as best I can with limited time to maintain CERNLIB and friends through the release of Squeeze. Hence this bug is only a request for adoption for now. If no one else takes over the package by the Squeeze release, I will request its removal from Sid immediately afterwards as no longer maintainable, and Debian users will have until the end of Squeeze security support (most likely 6 to 12 months after the release of Squeeze + 1) to migrate to other software. I'll take this opportunity to suggest ROOT (Debian package root-system). CERNLIB (PAW, GEANT 3.21, Monte Carlo library) users should consider this email their first warning. As far as I know, Debian and Fedora are the only organizations left that offer any sort of official support whatsoever for CERNLIB. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#507429: GPL or LGPL?
Hi Steve, Steve Cotton wrote: The patch says GPL, but the long story and package copyright say LGPL. The latter are correct, upstream gave permission to use it under LGPL. Actually, upstream specifically said Library GPL which I interpret to mean LGPL 2 in particular, not 2.1 (Lesser GPL). -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507429: [cfortran] Licence in header file is not up to date!
retitle 507429 Licence should probably be incorporated in header file severity 507429 normal thanks Bastien, Thank you for pointing this out. I am not sure I agree that this is a bug. The cfortran.h file says (as you quoted): Bastien ROUCARIES wrote: [from cfortran.h] THIS FILE IS PROPERTY OF BURKHARD BUROW. IF YOU ARE USING THIS FILE YOU SHOULD ALSO HAVE ACCESS TO CFORTRAN.DOC WHICH PROVIDES TERMS FOR USING, MODIFYING, COPYING AND DISTRIBUTING THE CFORTRAN.H PACKAGE. That's all. To the best of my knowledge (IANAL) this just gives the name of the copyright holder (PROPERTY OF BURKHARD BUROW), and says that the license can be found elsewhere. I do not think the above statement is any sort of license because it specifically mentions that the terms for use, modification, copying, and distribution (all of which would be defined by a license) are in cfortran.doc. If you refer to cfortran.doc at /usr/share/doc/cfortran/cfortran.doc.gz you can see that the license at the bottom of that file has been patched in Debian to mention the LGPL: THIS PACKAGE, I.E. CFORTRAN.H, THIS DOCUMENT, AND THE CFORTRAN.H EXAMPLE PROGRAMS ARE PROPERTY OF THE AUTHOR WHO RESERVES ALL RIGHTS. THIS PACKAGE AND THE CODE IT PRODUCES MAY BE FREELY DISTRIBUTED WITHOUT FEES, SUBJECT (AT YOUR CHOICE) EITHER TO THE GNU LIBRARY GENERAL PUBLIC LICENSE AT http://www.gnu.org/licenses/lgpl.html OR TO THE FOLLOWING RESTRICTIONS: [snip non-free original license] It is probably worth clarifying the text of cfortran.h (and further clarifying the text of cfortran.doc) but I don't think that merits an RC severity. So, downgrading. If you (or others) disagree, your comments are welcome of course. -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507527: Is libmpeg3-dev dependency necessary?
Package: libdirectfb-dev Version: 1.0.1-11 Severity: wishlist Hi, It seems that in Lenny and Sid there exists the following dependency chain: libgtk2.0-dev - libcairo2-dev - libdirectfb-dev - libmpeg3-dev So as a result of installing a widget toolkit development library, one ends up with an MPEG video decoding library? This is a little odd. Is there any way to lower the Depends of libdirectfb-dev on libmpeg3-dev to Recommends or Suggests? I'm filing this wishlist bug against libdirectfb-dev since this dependency is the one in the chain that looks most dubious to me (as a third party with little knowledge of most of these libraries other than GTK+). But feel free to reassign against someone else in the chain. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491530: Announce of the upcoming NMU for the cernlib package
Christian Perrier wrote: Dear maintainer of cernlib and Debian translators, Some days ago, I sent a notice to the maintainer of the cernlib Debian package, mentioning the status of at least one old po-debconf translation update in the BTS. I announced the intent to build and possibly upload a non-maintainer upload for this package in order to fix this long-time pending localization bug as well as all other pending translations. The package maintainer agreed for the NMU or did not respond in two weeks, so I will proceed with the NMU. Christian, I don't recall seeing your email, but I have no time to take care of this at the moment anyway. Feel free to go ahead and NMU, although I don't know that there is time for the update to make it into lenny (I was planning to do a cleanup upload after lenny release anyway). best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#489886: cfortran bug seems to be in the example code
severity 489886 minor tags 489886 - help retitle 489886 cfortran: invalid strcpy in example code snippet fd/fd.c thanks Hi Jean-Guillaume, first, sorry for taking so long to get back to you. As best I can tell after making a detailed inspection, the bug you reported at http://bugs.debian.org/489886 seems to be a problem in the cfortran example code snippet fd/fd.c, not in the cfortran.h header itself. I'm therefore retitling the bug appropriately and downgrading the severity to minor. If you have more examples showing a problem in cfortran.h itself I'll be happy to reconsider. I ran gcc as you did, plus an additional -save-temps option, on fd.c, cleaned up the resulting preprocessed file a little bit, and added some more debugging printf's. From that I deciphered what's happening: The original string ii, happy , has 12 bytes including the trailing zero byte. It gets passed into FORTRAN together with the string length (11). In FORTRAN subroutine fd(), the contents of the string are changed to birthdaybut the address of the string is the same. This address and the same string length is then passed into the cfortran-generated C function cdcfort_, which mallocs an array of size 11+1 == 12 and copies in the other string's contents (deleting trailing spaces). cdcfort_() passes the newly malloced string into the cd() function. cd() then tries to strcpy the string to you 12345678, length 16 bytes, into it. This is the real problem. For whatever reason, there is no crash until the call to free(), which detects corrupted memory. (Valgrind detects the error where it first happens.) If I add four more spaces at the end of the definition of ii in main(), there is no crash and valgrind does not complain. So to summarize, if this piece of example code ever worked, it only did so by accident. I can add four more spaces in ii to prevent the crash, but I don't know what the original pedagogical intent of the example program was, so I can't necessarily make it work how it was supposed to. Burkhard, do you happen to remember what the intended output was? best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#493345: lowering severity of root-system FTBFS on unsupported platform
package root-system severity 493345 important thanks Hi, On behalf of the maintainer, I'm reducing the severity of the FTBFS bug for root-system on sparc to important. Failures to build are not release-critical when the package has never previously built on the architecture in question and that architecture is unsupported upstream. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#489886: cfortran: examples/fd fails to execute = free(): invalid next size
package cfortran tags 489886 + help thanks Thanks for submitting this as a formal bug report. I will try to take a look into it when I next have some free time. As that may possibly be a while in coming, I'm tagging this bug help and others are very welcome to provide patches or NMU. (Note, I'll forward your earlier personal email containing the test cases to this bug report also.) best regards, - Kevin jgp wrote: Package: cfortran Version: 4.4-12 Severity: important -- System Information: Debian Release: lenny/sid Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash cfortran depends on no packages. Versions of packages cfortran recommends: ii gcc [c-compiler] 4:4.3.1-1 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.6-7The GNU C compiler ii gcc-4.2 [c-compiler] 4.2.4-2+b1 The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.1-2The GNU C compiler ii gfortran [fortran-compiler] 4:4.3.1-1 The GNU Fortran 95 compiler -- no debconf information --- ll total 24 -rwxr-xr-x 1 jg jg 11602 2008-07-08 18:12 exe lrwxrwxrwx 1 jg jg36 2008-07-08 18:10 fd - /usr/share/doc/cfortran/examples/fd/ lrwxrwxrwx 1 jg jg 7 2008-07-08 18:11 0c.c - fd/fd.c lrwxrwxrwx 1 jg jg 9 2008-07-08 18:12 0f.f - fd/fd_f.f -rw-r--r-- 1 jg jg 2528 2008-07-08 18:12 0f.o gfortran -g -I/usr/include -c 0f.f gcc -g -Df2cFortran -o exe -I/usr/include 0c.c 0f.o ./exe cd: had string argument:birthday. *** glibc detected *** ./exe: free(): invalid next size (fast): 0x0804a008 *** === Backtrace: = /lib/i686/cmov/libc.so.6[0xb7e088f5] /lib/i686/cmov/libc.so.6(cfree+0x90)[0xb7e0c360] ../exe[0x80488be] ../exe[0x80489f1] ../exe[0x804892f] /lib/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7db3450] ../exe[0x8048451] === Memory map: 08048000-08049000 r-xp 03:06 4187131 /home/jg/hpc/fortran/cfortran.h/exe 08049000-0804a000 rw-p 03:06 4187131 /home/jg/hpc/fortran/cfortran.h/exe 0804a000-0806b000 rw-p 0804a000 00:00 0 [heap] b7c0-b7c21000 rw-p b7c0 00:00 0 b7c21000-b7d0 ---p b7c21000 00:00 0 b7d9c000-b7d9d000 rw-p b7d9c000 00:00 0 b7d9d000-b7ee5000 r-xp 03:03 517150 /lib/i686/cmov/libc-2.7.so b7ee5000-b7ee6000 r--p 00148000 03:03 517150 /lib/i686/cmov/libc-2.7.so b7ee6000-b7ee8000 rw-p 00149000 03:03 517150 /lib/i686/cmov/libc-2.7.so b7ee8000-b7eeb000 rw-p b7ee8000 00:00 0 b7ef-b7efc000 r-xp 03:03 161942 /lib/libgcc_s.so.1 b7efc000-b7efd000 rw-p b000 03:03 161942 /lib/libgcc_s.so.1 b7efd000-b7f0 rw-p b7efd000 00:00 0 b7f0-b7f1a000 r-xp 03:03 679952 /lib/ld-2.7.so b7f1a000-b7f1c000 rw-p 00019000 03:03 679952 /lib/ld-2.7.so bf8bf000-bf8d4000 rw-p bffeb000 00:00 0 [stack] e000-f000 r-xp 00:00 0 [vdso] Aborted /etc/debian_version lenny/sid dpkg -l cfortran Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=-=-== ii cfortran 4.4-12 Header file permitting Fortran routines to be called in C/C++ -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487935: re-opening this
package root-system reopen 487935 found 487935 5.18.00-2 severity 487935 important thanks Hi, I evidently erred in assuming that the support for s390 was complete in ROOT 5.18.00-2 and adding a closes for this bug to Christian's changelog entry before building/uploading for him. I am re-opening this bug, and I'm sorry for my mistake. I am, however, downgrading it from serious to important. FTBFSes on architectures unsupported by a package (i.e. on which it has never previously built) are not RC, please refer to http://release.debian.org/lenny/rc_policy.txt (point 4). best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#451510: is this legal?
Christian Holm Christensen wrote: I attach the license file that accompanies the TTF files from the ROOT FTP site (faithfully put in /usr/share/doc/ttf-root-installer by that package). If this satisfy you guys, I think we should close the bug. I'm in agreement. By the way, why is this discussion going to 451510? Shouldn't it be going to 425201 (in CC), which is the one that should be closed (or downgraded to wishlist) now? best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#487319: possible check for perl problem in Debian testing distribution
Hi again Steffen, Kevin B. McCarty wrote: ed_0.7-1_i386.deb inn_1.7.2q-35_i386.deb java-gcj-compat-plugin_1.0.78-1_i386.deb lib64ncurses5-dev_5.6+20080614-1_i386.deb libbz2-dev_1.0.5-0.1_i386.deb libncurses5-dev_5.6+20080614-1_i386.deb libncursesw5-dev_5.6+20080614-1_i386.deb libvolume-id-dev_0.114-2_i386.deb Here are the remainder of the i386 and all packages that contain absolute symlinks but do not include md5sums in the debian control information: module-init-tools_3.4-1_i386.deb ncurses-base_5.6+20080614-1_all.deb smartlist_3.15-20_i386.deb latex2html_2002-2-1-20050114-6_all.deb [N.B. latex2html is in non-free, all the rest are in main] I hope this information proves useful! best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#451510: is this legal?
Hi, At a quick glance, I can't see that ttf-root-installer is doing anything that msttcorefonts does not do, aside from grabbing a different version of the fonts from a different URL. FTP-masters seem not to have been critically opposed to ttf-root-installer. Whether ROOT upstream is legally permitted to make the older MS fonts available in the tar.gz form is unknown to me, but I would hope they would have checked into this. (Fons?) In any case, the Debian package is nothing more than an installer, so to the best of my knowledge (IANAL), any legal liability for this distribution would fall on ROOT upstream and not on Debian. Christian Holm wrote: The fonts distributed from the ROOT FTP server are very old - some 8+ years or so, while the fonts of the msttcorefonts package are updated versions of these. The time-stamp on the files on the ROOT ftp server are corfonts.exe 1998-11-26 00:00:00 ttf_fonts.tar.gz 2001-04-20 00:00:00 The font packages on sourceforge all have timestamps from 2002 or later. I worry that these (older) fonts may come from before MS started distributing them under a quasi-permissive license. Does anyone know the date for that offhand? Or whether MS specified that the msttcorefonts license applies to all versions of the fonts, or only to the specific versions they released under it? I tend to think that ROOT should be fixed upstream to either work with the current versions of MS fonts, or (even better) to use whatever true-type fonts are installed on the system. But obviously there isn't enough time for that to be implemented before the Lenny freeze. So given the choice, if there is any legal ambiguity it is probably best just to get rid of the ttf-root-installer binary package for now. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#487319: possible check for perl problem in Debian testing distribution
Kevin B. McCarty wrote: Hi, I'm running a script now but it may not be done soon since it needs to go through every package (no shortcut with Depends etc.) It may not be the most efficient way to do things since I typed it up really fast. In case I botched the script, I'm also attaching it so you can take a look at it and double check my results (which I'll email you when it's done, maybe tomorrow). Change the top of the script to your desired mirror and arch(es). The script got through libx or so before stopping for some reason ... here's the list of packages (i386 and all, only in main) detected up to this point alphabetically: ed_0.7-1_i386.deb inn_1.7.2q-35_i386.deb java-gcj-compat-plugin_1.0.78-1_i386.deb lib64ncurses5-dev_5.6+20080614-1_i386.deb libbz2-dev_1.0.5-0.1_i386.deb libncurses5-dev_5.6+20080614-1_i386.deb libncursesw5-dev_5.6+20080614-1_i386.deb libvolume-id-dev_0.114-2_i386.deb Now off to figure out how to restart it without starting from scratch... -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487319: possible check for perl problem in Debian testing distribution
Steffen Joeris wrote: On Sun, 22 Jun 2008 07:43:16 pm Kevin B. McCarty wrote: Hi, On Sun, Jun 22, 2008 at 3:48 AM, Steffen Joeris [EMAIL PROTECTED] wrote: Hi Kevin I talked to dato and he recommended to talk to you. At the moment, the perl bug[0] probably affects a few packages in debian testing. It would now be good to find out how many packages are affected, so we could prepare an advisory. The fixed perl packages should migrate to testing soon, otherwise I have a DTSA ready. Now, I was wondering, if you have the time and energy to check, how many packages are affected. Some instructions (especially point 3+4) can be found here[1]. Hi, I'm running a script now but it may not be done soon since it needs to go through every package (no shortcut with Depends etc.) It may not be the most efficient way to do things since I typed it up really fast. In case I botched the script, I'm also attaching it so you can take a look at it and double check my results (which I'll email you when it's done, maybe tomorrow). Change the top of the script to your desired mirror and arch(es). best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 find-nomd5-abssymlinks.sh Description: application/shellscript signature.asc Description: OpenPGP digital signature
Bug#486145: lintian: Please downgrade depends-on-obsolete-package to warning for alternative OR'ed dependencies
Package: lintian Version: 1.24.0 Severity: wishlist Hi, The Lintian build-depends-on-obsolete-package and depends-on-obsolete-package checks are useful. But they make it harder to write debian/control to be backport-friendly, that is in such a way that only a rebuild on an Etch system with satisfied build-deps (rather than editing debian/control) is required when backporting. This is because Lintian checks even alternative packages in OR'ed dependencies. For instance, if bar is a known obsolete package, then the following in debian/control: (Build-)Depends: foo | bar will trigger a Lintian error. It would be preferable for the severity in this case to be only a warning instead of an error. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#481247: Found another example of this bug; setting severity to serious
package file
severity 481247 serious
thanks
Hi Daniel,
I have found another example of a shared library, this one in my
unofficial Geant4 packages, that is affected by bug #481247 in file.
See: http://people.debian.org/~kmccarty/libG4detector-4.9.so.5
wisteria (sid)[1]:~% file libG4detector-4.9.so.5
libG4detector-4.9.so.5: Linux/i386 core file, dynamically linked, not stripped
Given that I've now found two independent examples in only two source
packages that I'm working on, this bug no longer seems to be an unlikely
one-time occurrence, and may very well have already affected software in
the official Debian archive. (Fortunately I have not found any examples
in my own /lib or /usr/lib directories, but that is far from a complete
sample of the archive.)
Mis-detecting a shared library as a core file causes at least the
following problems that are in violation of Policy:
* dh_strip ignores the shared library in question, causing it to be
unstripped in the .deb.
* dh_shlibdeps ignores the shared library in question, causing its
${shlibs:Depends} package dependencies to never be substituted
into the .deb's control information.
Also, Lintian produces spurious errors, for instance:
libroot-ruby5.18: pkg-has-shlibs-control-file-but-no-actual-shared-libs
libgeant4-4.9-5: unused-shlib-entry-in-control-file libG4detector-4.9 5
instead of the real errors (no dependency info, unstripped binaries)
that it *should* be finding.
Because the bug can cause Policy violations in packages unrelated to
file, and it is in addition blocking me from uploading the root-system
package that I am sponsoring, I am raising the severity to serious.
best regards,
--
Kevin B. McCarty [EMAIL PROTECTED]
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751
signature.asc
Description: OpenPGP digital signature
Bug#482102: qa.debian.org: intelligent listing of debian/patches, git/quilt v3 format packages, etc
Lucas Nussbaum wrote: patches.debian.org == Objective: Provide simple place to learn about Debian-specific patches, for upstream, users and other DDs. Features: browsing patches, downloading them, tracking status of patches. Split .diff.gz to extract patches for: - each quilt/dpatch/simple-patchsys patch Hi Lucas, Sean, I just wanted to mention a potential gotcha to consider with dpatch -- note that it allows patch files to be arbitrary scripts. So if a dpatch file begins with a shebang line that doesn't include the string dpatch, it should probably just be shown by the patch browsing system as a normal text file without patch-style formatting. (Or even with special formatting for the most common scripting languages -- sh, perl, python, etc. -- if not too much trouble.) Of course it's possible that I am the only person that uses this obscure dpatch feature (I have some scripts to move source code files around during the patch step -- yes, they honor both the -patch and -unpatch flags). So maybe it's easiest not to worry about it too much. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#483596: RM: wmakerconf-data -- RoM/RoQA; now generated by wmakerconf source package
Package: ftp.debian.org Dear FTP masters, I recently uploaded wmakerconf 2.12-1 on behalf of QA. (I am a previous maintainer and previous upstream of the package. Even though I orphaned it -- in both capacities -- a while ago, I thought it would nevertheless be useful to get the latest upstream version into Debian). It has now transitioned into testing. For historical reasons, prior to the 2.12-1 upload, the wmakerconf and wmakerconf-data binary .debs were generated from separate source packages (of the same respective names). This is no longer the case. As of wmakerconf 2.12-1, the wmakerconf-data .deb now comes from the wmakerconf source package. Therefore the wmakerconf-data source package is now superfluous. Please remove it (version 0.90.0.0-3) from Sid and Lenny. Please take care *NOT* to remove version 2.12-1 of the wmakerconf-data binary package. Thanks and best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#481247: ping re: file bug #481247
Hi Daniel, I just want to make sure I did not somehow miss an email from you about this bug (#481247). I remember you said you were going to make a proposed fix for it available when you had a chance. Thanks and best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#481231: RM: maxdb-7.5.00/stable -- ROST; Unfixable security bug, upstream went non-free
Package: release.debian.org Severity: important Dear Stable Release Managers, as discussed on debian-release [1] and acked by Security Team [2], please remove source package maxdb-7.5.00 and related packages (listed below) from Etch. Maxdb has a serious security bug [3,4] which is basically unfixable according to the erstwhile maintainer [5], and has already been removed from Sid [5]. No support from upstream is expected as they took the package closed-source. [1] http://lists.debian.org/debian-release/2008/05/msg00136.html [2] http://lists.debian.org/debian-release/2008/05/msg00234.html [3] http://bugs.debian.org/461444 [4] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0244 [5] http://bugs.debian.org/461456 The following source packages have dependencies on maxdb and should also be removed from Etch (as has already occurred in Sid). (Numbers in parentheses are the bug number for the removal request from Sid.) libdbd-maxdb-perl (#461479) php-maxdb (#461480) The following source packages have no reason to be shipped in Etch once maxdb is removed, so they should also probably be removed: maxdb-doc (#461481) maxdb-buildtools (#461482) libsapdbc-java (#461483) Thanks and best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#481247: file: thinks shared library is a core file (regression since Etch)
Package: file Version: 4.24-2 Severity: normal Hi, The file from Sid thinks that this file: http://people.debian.org/~kmccarty/libRuby.so.5.18 is this: Linux/i386 core file of '/', dynamically linked, not stripped when in fact it is actually a normal (unstripped) i386 shared library. The version of file in Etch (4.17-5etch3) gets it right: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped Please fix -- this mis-detection causes dh_strip to skip over this file (which is built as part of a Debian package I am sponsoring -- the maintainer is in X-Debbugs-CC), and also causes Lintian to output a spurious error on it. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-6-k7 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages file depends on: ii libc6 2.7-11 GNU C Library: Shared ii libmagic1 4.24-2 File type determination file recommends no packages. -- no debconf information Thanks and best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#481093: sysklogd: tries to create symlink in directory that doesn't exist when in chroot
Package: sysklogd Version: 1.5-3 Severity: normal Hi, On upgrading sysklogd and klogd from 1.5-2 to 1.5-3 inside a Sid chroot, I get the following: Setting up klogd (1.5-3) ... Installing new version of config file /etc/init.d/klogd ... Stopping kernel log daemon... failed! Starting kernel log daemon ln: creating symbolic link `/lib/init/rw/sendsigs.omit.d/klogd': No such file or directory Setting up sysklogd (1.5-3) ... Installing new version of config file /etc/init.d/sysklogd ... Stopping system log daemon... failed! Starting system log daemon ln: creating symbolic link `/lib/init/rw/sendsigs.omit.d/sysklogd': No such file or directory The only thing responsible for creating the sendsigs.omit.d directory is apparently /etc/init.d/mountkernfs.sh, which of course is not run from within the chroot. Would it be possible for the sysklogd and klogd postinsts to try to create this directory if it does not already exist, before creating symlinks inside it, in order to account for the possibility that they are running inside a chroot? I'll clone this bug against klogd as soon as I get a bug number back, since it applies to both binary packages. Thanks and best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#466513: More information requested about your wmakerconf bug
Hi, I am planning to make a QA upload of wmakerconf in Debian, and I would like some more information about the bug you submitted for it at http://bugs.debian.org/466513 and http://bugs.debian.org/468390 in order that I may try to fix it. (I assume those two bug reports are for the same problem with the program, is that correct?) First, please let me know whether you can still trigger this bug. Unfortunately the backtrace supplied in your bug report does not really have enough information. Could you please let me know what you were doing with WMakerConf at the time it crashed? Be as specific as you can. Also, is there anything unusual about your system configuration or your Window Maker setup that might be unexpected by WMakerConf? Please be sure to send your reply directly to the bug's dedicated email address at [EMAIL PROTECTED] . Thanks and best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#290352: wmakerconf orphaned again
Hi, The prospective adopter of wmakerconf, Herbert P. Fortes Neto, has contacted me (I am a previous maintainer and upstream of the package) privately and told me that he no longer has interest in maintaining it. He did already make a new upstream release, version 2.12, which is not yet in Debian. In the interests of including the fixes from that version into the next Debian release, I plan to make an upload of wmakerconf 2.12 on behalf of QA. (Note that I am not re-adopting the package however.) Although it has not been updated since September 2006, I do not think this package should be removed from Debian at this time. The popcon figures are quite high (inst: 801, vote: 143, recent: 36) and as far as I know the package works fine. I'll try to look into #466513/#468390 and get more info from the submitter before making the upload of 2.12. (Submitter of those bugs appears to be running Ubuntu so I'm not sure why the reports found their way to the Debian BTS.) best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#479595: dictionaries-common: invalid dirhandle warning messages on install
Package: dictionaries-common Version: 0.98.5 Severity: normal Hi, During an upgrade of my sid chroot, dictionaries-common 0.98.5 was pulled in by myspell-en-us (which was pulled in by libhunspell-1.2, which was pulled in by iceweasel). The dictionaries-common package was not previously installed. The following messages were printed from the postinst script: Setting up dictionaries-common (0.98.5) ... readdir() attempted on invalid dirhandle DIR at /usr/share/perl5/Debian/DictionariesCommon.pm line 143, STDIN line 2. closedir() attempted on invalid dirhandle DIR at /usr/share/perl5/Debian/DictionariesCommon.pm line 144, STDIN line 2. readdir() attempted on invalid dirhandle DIR at /usr/share/perl5/Debian/DictionariesCommon.pm line 143, STDIN line 2. closedir() attempted on invalid dirhandle DIR at /usr/share/perl5/Debian/DictionariesCommon.pm line 144, STDIN line 2. readdir() attempted on invalid dirhandle DIR at /usr/share/perl5/Debian/DictionariesCommon.pm line 143. closedir() attempted on invalid dirhandle DIR at /usr/share/perl5/Debian/DictionariesCommon.pm line 144. Updating OpenOffice.org's dictionary list... done. It's possible that the warnings have something to do with the upgrade to perl 5.10, as the dictionaries-common postinst was run after perl 5.10.0-9 preinst and unpacking, but before perl postinst. If the warnings are in fact merely cosmetic and nothing to worry about, feel free to downgrade this bug to minor. Please let me know if you need more info like dpkg.log, etc. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#448094: dh_icons supported file types
Hi debhelper maintainer, I was led to this bug (#448094) after discovering that a call to dh_icons inserted into the build of my package, which has an XPM-format icon, does not generate a postinst calling update-icon-caches. Please consider this email as another request asking for a bugfix, for whatever that may be worth. Just in case it's helpful to mention, the source code gtk/updateiconcache.c (in gtk+2.0 source package) for gtk-update-icon-cache, of which update-icon-caches is a wrapper, specifically tests for files ending with the extensions .png .svg .xpm and .icon. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#476427: gfortran-4.3: Please include patch for PR35662 to fix problem on mips(el)
Package: gfortran-4.3
Severity: important
Tags: patch
Hi gcc-4.3 maintainers,
Could you please include the patch fixing gfortran PR35662 [1] available
from [2]? This issue is likely to break a fairly large amount of
FORTRAN code that has been compiled with optimization level -O1 or
greater with gfortran-4.3 on mips and mipsel.
[1] http://gcc.gnu.org/PR35662
[2] http://gcc.gnu.org/viewcvs?root=gccview=revrev=134352
(I apologize for not requesting this earlier, but the patch from gcc
upstream was not available until today.)
Release team: if such a release of gcc-4.3 is prepared, is there any
possibility of getting it into Lenny?
If it is possible to include this patch in a version of gfortran-4.3
that can be included in Lenny, then I will request bin-NMUs on mips and
mipsel for all packages containing libraries or binaries that both
(a) are linked against libgfortran.so.3 and (b) appear to use sincos{,f,l}.
I will post the list of packages that appear to be affected by PR35662
later today in a follow-up message to [EMAIL PROTECTED]
best regards,
--
Kevin B. McCarty [EMAIL PROTECTED]
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751
signature.asc
Description: OpenPGP digital signature
Bug#476427: [PR35662]
P.S. Regarding #476427, it would be nice to bump the libgfortran3 shlibdeps to libgfortran3 (= [version where this bug gets fixed]), at least on mips(el), so that it is possible to have a script determine (without searching buildd logs) which packages have already been compiled there with the fixed gfortran-4.3. Of course, feel free to ignore this request, since it's just an it would be nice if ... best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#475266: vim: folding support for mbox format would be nice
Package: vim
Version: 1:7.1.291-1
Severity: wishlist
Tags: patch
Hi,
I've been using vim to read debian-private archives on master. I like
its syntax highlighting but have continually been annoyed that (a) I
have to page-down through obvious spam, and (b) I have to view all of
the headers to each mail message, most of which are completely
uninteresting.
I can't believe this doesn't exist already, but I can't find any plugin
to implement folding for mbox format files. So I wrote one, see
attached fold-mail.vim. This folds mbox format files at two levels:
1) individual messages, and 2) the headers for each message. Author and
subject of the message are displayed in the folding text at both levels.
You may want to integrate into ftplugin/mail.vim. I wrote this as a
quick hack in a couple hours, based only on ftplugin/debchangelog.vim
and the online Vim documentation, so you may also want to do a sanity
check on it first :-)
best regards,
--
Kevin B. McCarty [EMAIL PROTECTED]
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751
if exists(g:mail_fold_enable)
setlocal foldmethod=expr
setlocal foldexpr=GetMboxFold(v:lnum)
setlocal foldtext=GetMboxFoldText()
endif
{{{1 folding
function! s:getAuthor(zonestart, zoneend) return author name if present,
otherwise just email address
let linepos = a:zonestart
while linepos = a:zoneend
let line = getline(linepos)
if line =~# '^From: '
if line =~ '^From: [^ ][^]* '
return substitute(line, '^From: []\?\([^ ][^]*[^]\)[]\? .*',
'\1', '')
else
return substitute(line, '^From: \(.*\)', '\1', '')
endif
endif
let linepos += 1
endwhile
return '[unknown author]'
endfunction
function! s:getSubject(zonestart, zoneend)
let linepos = a:zonestart
while linepos = a:zoneend
let line = getline(linepos)
if line =~# '^Subject: '
return substitute(line, '^Subject: \(.*\)', '\1', '')
endif
let linepos += 1
endwhile
return '[no subject]'
endfunction
function! GetMboxFoldText()
if v:folddashes == '-' whole mail msg folded:
show number of lines as well as author subject
let text = substitute(foldtext(), '^\([-+0-9 ]\+lines: \).*', '\1', '') .
s:getAuthor(v:foldstart, v:foldend)
while strlen(text) 36
let text = text . ' '
endwhile
if strlen(text) 36
let text = text[0 : 35]
endif
else only headers folded, use full available space to show author subject
let text = '+-- ' . s:getAuthor(v:foldstart, v:foldend)
endif
return text . ' -- ' . s:getSubject(v:foldstart, v:foldend) . ' '
endfunction
function! GetMboxFold(lnum)
let line = getline(a:lnum)
if line =~# '^From '
return '1' beginning of a message
endif
if line =~ '^[-a-zA-Z0-9]\+: '
if a:lnum 0 getline(a:lnum - 1) =~# '^From '
return '2' beginning of header block
else
return '='
endif
endif
if a:lnum 0 line =~ '^$'
return '2'
else
return '='
endif
endfunction
}}}
signature.asc
Description: OpenPGP digital signature
Bug#475300: vim: slight tweak to detection of mail format files
Package: vim Version: 1:7.1.291-1 Severity: minor Tags: patch Hi, I find that vim's detection of mbox (filetype mail) files for syntax coloring, etc. doesn't work when they are generated by Mozilla Thunderbird, the reason being that in the From line preceding each message, Thunderbird apparently puts a - rather than an email address. Example header line in debian-private archive: From [EMAIL PROTECTED] Tue Apr 01 09:36:16 2008 Example header line in my local mailbox generated by Icedove: From - Wed Jan 02 08:44:14 2008 The attached, very minor patch to /usr/share/vim/vim71/scripts.vim allows vim to also realize that Thunderbird's idiosyncratic headers signal a file in mbox format. Side note: This is not included in the patch, but also maybe =~ on the line changed by the diff should be changed to =~# since to the best of my knowledge, the From is case-sensitive. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 --- scripts.vim.orig 2008-04-09 14:08:05.0 -0700 +++ scripts.vim 2008-04-09 14:09:29.0 -0700 @@ -168,7 +168,7 @@ set ft=zsh ELM Mail files - elseif s:line1 =~ '^From [a-zA-Z][a-zA-Z_0-9\.=-]*\(@[^ ]*\)\= .*[12][09]\d\d$' + elseif s:line1 =~ '^From \([a-zA-Z][a-zA-Z_0-9\.=-]*\(@[^ ]*\)\=\|-\) .*[12][09]\d\d$' set ft=mail Mason signature.asc Description: OpenPGP digital signature
Bug#475266: bug-fixed version of fold-mail.vim
Slightly bugfixed version of fold-mail.vim attached, use this one as a
starting point rather than the original.
This one doesn't try to do folding if the mbox file doesn't start with a
From header. Also it deals correctly with blank header fields that
have no space immediately after the header name (like Subject: rather
than Subject: ) and accounts for line numbers in Vim starting at 1
(not 0).
In case a license statement is necessary: I hereby release the attached
file fold-mail.vim to the public domain.
best regards,
--
Kevin B. McCarty [EMAIL PROTECTED]
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751
if exists(g:mail_fold_enable)
setlocal foldmethod=expr
disable folding if there is no From header (presumably only one
mail message in the file)
setlocal foldexpr=getline(1)=~#'^From\ '?GetMboxFold(v:lnum):'0'
setlocal foldtext=GetMboxFoldText()
endif
{{{1 folding
function! s:getAuthor(zonestart, zoneend) return author name if present,
otherwise just email address
let linepos = a:zonestart
while linepos = a:zoneend
let line = getline(linepos)
if line =~# '^From: '
if line =~ '^From: [^ ][^]* '
return substitute(line, '^From: []\?\([^ ][^]*[^]\)[]\? .*',
'\1', '')
else
return substitute(line, '^From: \(.*\)', '\1', '')
endif
endif
let linepos += 1
endwhile
return '[unknown author]'
endfunction
function! s:getSubject(zonestart, zoneend)
let linepos = a:zonestart
while linepos = a:zoneend
let line = getline(linepos)
if line =~# '^Subject: '
return substitute(line, '^Subject: \(.*\)', '\1', '')
endif
let linepos += 1
endwhile
return '[no subject]'
endfunction
function! GetMboxFoldText()
if v:folddashes == '-' whole mail msg folded:
show number of lines as well as author subject
let text = substitute(foldtext(), '^\([-+0-9 ]\+lines: \).*', '\1', '') .
s:getAuthor(v:foldstart, v:foldend)
while strlen(text) 36
let text = text . ' '
endwhile
if strlen(text) 36
let text = text[0 : 34] . ''
endif
else only headers folded, use full available space to show author subject
let text = '+--- ' . s:getAuthor(v:foldstart, v:foldend)
endif
return text . ' - ' . s:getSubject(v:foldstart, v:foldend) . ' '
endfunction
function! GetMboxFold(lnum)
let line = getline(a:lnum)
if line =~# '^From '
return '1' beginning of a message
endif
if line =~ '^[-a-zA-Z0-9]\+:'
if a:lnum 1 getline(a:lnum - 1) =~# '^From '
return '2' beginning of header block
else
return '='
endif
endif
if a:lnum 1 line =~ '^$'
return '2'
endif
return '='
endfunction
silent! foldopen!unfold the entry the cursor is on (usually the first one)
}}}
signature.asc
Description: OpenPGP digital signature
Bug#475266: third iteration
Third iteration of mbox folding: take into account that header field
names (Subject, From) are case-insensitive, and allow tab(s) as well as
space(s) to follow them.
Sorry for all the noise, this should be the final version.
best regards,
--
Kevin B. McCarty [EMAIL PROTECTED]
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751
if exists(g:mail_fold_enable)
setlocal foldmethod=expr
disable folding if there is no From header (presumably only one
mail message in the file)
setlocal foldexpr=getline(1)=~#'^From\ '?GetMboxFold(v:lnum):'0'
setlocal foldtext=GetMboxFoldText()
endif
{{{1 folding
function! s:getAuthor(zonestart, zoneend) return author name if present,
otherwise just email address
let linepos = a:zonestart
while linepos = a:zoneend
let line = getline(linepos)
if line =~? '^From:\s'
if line =~? '^From:\s\+[^]*\s\+'
return substitute(line, '^[^:]*:\s\+[]\?\([^]*[^]\)[]\?\s\+.*',
'\1', '')
else
return substitute(line, '^[^:]*:\s\+\(.*\)', '\1', '')
endif
endif
let linepos += 1
endwhile
return '[unknown author]'
endfunction
function! s:getSubject(zonestart, zoneend)
let linepos = a:zonestart
while linepos = a:zoneend
let line = getline(linepos)
if line =~? '^Subject:\s'
return substitute(line, '^[^:]*:\s\+\(.*\)', '\1', '')
endif
let linepos += 1
endwhile
return '[no subject]'
endfunction
function! GetMboxFoldText()
if v:folddashes == '-' whole mail msg folded:
show number of lines as well as author subject
let text = substitute(foldtext(), '^\([-+0-9 ]\+lines: \).*', '\1', '') .
s:getAuthor(v:foldstart, v:foldend)
while strlen(text) 36
let text = text . ' '
endwhile
if strlen(text) 36
let text = text[0 : 34] . ''
endif
else only headers folded, use full available space to show author subject
let text = '+--- ' . s:getAuthor(v:foldstart, v:foldend)
endif
return text . ' - ' . s:getSubject(v:foldstart, v:foldend) . ' '
endfunction
function! GetMboxFold(lnum)
let line = getline(a:lnum)
if line =~# '^From '
return '1' beginning of a message
endif
if line =~ '^[-a-zA-Z0-9]\+:'
if a:lnum 1 getline(a:lnum - 1) =~# '^From '
return '2' beginning of header block
else
return '='
endif
endif
if a:lnum 1 line =~ '^$'
return '2'
endif
return '='
endfunction
silent! foldopen!unfold the entry the cursor is on (usually the first one)
}}}
signature.asc
Description: OpenPGP digital signature
Bug#290350: Still need a sponsor for wmakerconf?
Hi Herbert, Noticed that there isn't yet an upload of wmakerconf 2.12 into Debian, and then I saw your message at bug #290350 that you can't get ahold of your planned sponsor. Do you still need a sponsor for package upload? I have a little free time these days, so I'd be happy to sponsor it. I don't use Window Maker anymore so I couldn't do much user testing of the package, though. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#466791: still reproducible with gfortran-4.3 4.3.0~rc2-1
Hi, for the record, #466791 is still reproducible with gfortran-4.3 version 4.3.0~rc2-1. (I can't test 4.3.0-1 as it isn't yet installed on agnesi.d.o) I will submit this bug upstream very soon. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#466911: still reproducible with gfortran-4.3 4.3.0-1
Hi, for the record, #466911 and #466948 are still reproducible with gfortran-4.3 version 4.3.0-1. I will submit bugs upstream for these very soon. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#466791: reported #466791 upstream
I've submitted this bug report, #466791, upstream at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35079 as a follow-up comment to an arm ICE bug that appeared to be similar or identical. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#466911: reported #466911 upstream
I've submitted this bug report, #466911, upstream at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35658 and subscribed [EMAIL PROTECTED] to the bug in Bugzilla. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#466948: reported #466948 upstream
I've submitted this bug report, #466948, upstream at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659 and subscribed [EMAIL PROTECTED] to the bug in Bugzilla. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471039: The kxterm package is missing a .desktop file
Hi Cesare, Cesare Tirabassi wrote: Package: kxterm Version: 2006.dfsg.2-11 Severity: wishlist Usertags: origin-ubuntu hardy Hi, In Ubuntu, following a request from an user (see https://bugs.launchpad.net/ubuntu/+source/cernlib/+bug/36382) we have added a .desktop file to the kxterm package. Would it be possible to have this also in your package? We will be grateful as this would ease future syncs. I paste the validated .desktop file to this email (can also provide a patch if you prefer). I'm not convinced that it actually makes sense for kxterm to have a desktop file, since to the best of my knowledge kxterm is only meant to be called from other programs (in particular, paw++ and user-built applications using the GEANT3 library/framework) and not directly by the user. (An argument could hence be made that the kxterm binary belongs somewhere other than /usr/bin, but putting it outside of $PATH would make things difficult for the programs that want to use it.) I also removed the Debian menu file for kxterm as of cernlib 2006.dfsg.2-6, for the same reason. Would you happen to know if the person who submitted the desktop file had a reason for it other than every GUI app should have a desktop file ? If there is a use case for someone starting kxterm from the GUI or command line with no parent application driving it, I'll be happy to add it, but I'm not aware of one right now. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#470784: fontconfig-config: Could downgrade Depends on TTF fonts to Recommends?
Package: fontconfig-config Version: 2.5.0-2 Severity: wishlist Hi, Currently fontconfig-config has a Depends on ttf-dejavu | (various other TTF font packages). Would it be possible to downgrade that to a Recommends? The Depends results in ttf-dejavu-core + ttf-dejavu-extra + defoma being pulled in (8.5 MB total) via indirect dependencies on buildds and in pbuilder, which is unneeded and wastes bandwidth, buildd time, etc. Since Recommends are now installed by default by both apt-get and aptitude (not sure about dselect, but how many people still use it?) this change shouldn't cause much trouble for users. Anyway, feel free to close the bug if you disagree. Thanks for considering. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#466948: Acknowledgement (gfortran-4.3: miscompiled code with -O2 on ia64)
Turns out the culprit (mis-compiled file at -O2 on ia64) was tlsc.F. Test case saved at http://people.debian.org/~kmccarty/tlsc-test-case.tar.gz (note, the files libkernlib.a, libkerngent.a, and test.o in the tarball are compiled on ia64 from CERNLIB source code, which is GPL; it is available from the Debian source package of cernlib version 2006.dfsg.2-10) I saved files tlsc.f, tlsc.s and tlsc.o into subdirectories of the test case for three different combinations of compile flags: -O2 (causes miscompiled code) in obj-fail subdir -O0 (seems fine) -O2 -funroll-loops (seems fine) both in obj-success subdir. Also the output of the test case, saved as output.txt in each subdir. The presence or absence of -fno-automatic (I omitted it in all three cases) appears to make no difference. Again, I'll try to find time to submit this upstream. -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466911: gfortran-4.3: (regression) bad interaction on ia64 between -funroll-loops -fno-automatic -O2 and common block variable
Package: gfortran-4.3 Version: 4.3-20080202-1 Severity: normal Hi, In porting CERNLIB to gfortran, I've found an apparent gfortran compiler bug that results in incorrect code on ia64 (Itanium) with the compiler flags -funroll-loops -fno-automatic -O2 (or higher), possibly due to a bad interaction between these flags and a common block variable used in a computed GO TO statement of the form GO TO (1,2,3,4), L. The bug ONLY occurs in gfortran-4.3 -- I have tested that it does NOT happen in gfortran-4.1 (4.1.2-19), gfortran-4.2 (4.2.3-1), or g77-3.4 (3.4.6-6). Please see the complete test case I've provided at http://people.debian.org/~kmccarty/ia64-gfortran-test-fail.tar.gz Notes on the test case: 1) The code that gets mis-compiled is in c201s.F (this can be verified by building c201s.F with -O0 and building all the rest with -funroll-loops -fno-automatic -O2, then linking and running the test program c201test) 2) If *any* of the compiler flags are changed (remove -funroll-loops, remove -fno-automatic, or lower the optimization to -O1) the code is built OK. 3) I have put the output of gfortran-4.3 on ia64 (files c201s.f, c201s.s, and c201s.o) for various compiler flag combinations in subdirectories in the test case tarball. Also the output of the test program when run, in the file output.txt in each subdirectory. (Subdirectories are named first after whether the test succeeds, and second after the specific compiler flags used.) 4) I believe the problem is that the variable L in common block FLABEL is not seen as having the correct value (should be 1, is set to that value in c201m.F prior to any call of C201S) within c201s.F. 5) If I make any tweak to L in c201s.F, the bug disappears. (Argh, heisenbug!) For instance, any of the following tweaks individually causes the test program to succeed: a) changing L to a local variable initialized to the value 1 at the top of c201s.F b) setting L=1 at the top of c201s.F (keeping it in the common block) c) printing the value of L to stdout at the top of c201s.F with a WRITE statement d) printing the literal string 'L=n' to stdout (n being one of 1,2,3,4) immediately after each label that the first GO TO jumps to (i.e. the value of L is not even directly read from). Hence I was not able to simplify the test case any, unfortunately. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#466948: gfortran-4.3: miscompiled code with -O2 on ia64
Package: gfortran-4.3 Version: 4.3-20080202-1 Severity: normal Hi Matthias, sorry to pester you with yet another one of these! I'll just make this one a brief placeholder, so that the issue has a Debian bug number and so that I remember to report it upstream later. There is apparently an additional miscompilation of CERNLIB code, either in the library or the test suite, on ia64 with gfortran-4.3 at optimization level -O2 or higher. (Oddly, compiling with -O2 -funroll-loops does not expose the problem, which is why it wasn't noticed earlier.) Anyway, the problem can be seen at the build log for CERNLIB 2006.dfsg.2-10, see [1] and search in the log for the text Routine TTLPAC about 60% of the way down. I've verified that this occurs on ia64 with gfortran-4.3 versions 4.3-20080202-1 and 4.3-20080219-1. [1] http://buildd.debian.org/build.php?pkg=cernlibver=2006.dfsg.2-10arch=ia64 I'll try to create another self-contained test for this problem when I send all these gfortran bug reports to upstream. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#466791: gfortran-4.3: ICE on arm with -O1 -funroll-loops
Package: gfortran-4.3 Version: 4.3-20080202-1 Severity: normal Hi gcc maintainers, In transitioning CERNLIB to gfortran, I've uncovered an ICE [1] that occurs on arm when gfortran-4.3 is called with -funroll-loops and -O1 or higher. (If -funroll-loops is not given, gfortran succeeds on arm even at -O3.) I put together a self-contained test case from the CERNLIB source files at [2] for your convenience. The tarball there already includes the intermediate .f and .s files generated by the failing command on an arm machine (agnesi.debian.org). [1] http://buildd.debian.org/fetch.cgi?pkg=cernlibver=2006.dfsg.2-9arch=armstamp=1203539055 [2] http://people.debian.org/~kmccarty/arm-ICE-test.tar.gz best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#463474: lintian: Please check doc-base Section field for allowed values
Hi Robert, Robert Luberda wrote: Hi, On Thu, 31 Jan 2008, Russ Allbery wrote: Kevin B. McCarty [EMAIL PROTECTED] writes: Somehow I must have completely missed that discussion. Thank you for the pointer. I guess what happens next is in the hands of doc-base maintainer then? That would be my preference. If he says that we'll continue using the menu categories, I'm happy to change lintian accordingly. It would be great if lintian could check the doc-base files sections. Nevertheless we need to improve the doc-base section hierarchy first to make it better fit to documentation needs. I don't think it should be strictly bound to the menu's one. I gave my proposal at http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=37;bug=109431 (which isn't perfect though), and since nobody objected I'm going to implement it in doc-base soon. I don't see sections Science/Data Analysis or Science/Physics in your list of new fields at that message. Could you please include them as valid fields if they weren't already going to be? Should I be pro-active and change Apps/Science to Science/Physics in my physics-related doc-base files with my next uploads to unstable, or would it be better to wait a bit more? best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463474: lintian: Please check doc-base Section field for allowed values
Package: lintian Version: 1.23.42 Severity: wishlist Hi lintian maintainers, According to the instructions shipped with the doc-base package, file /usr/share/doc/doc-base/doc-base.txt.gz , paragraph 2.3.2.1, the Section field in a doc-base file should use the Debian menu sections: _Section_ Section where the document belongs; this should follow the sections outlined in chapter 3.5 of Debian Menu Policy, which can be found in the /usr/share/doc/menu/html (file:///usr/share/doc/menu/html/ch3.html#s3.5) directory. Required field. Since the allowed menu sections have recently changed (and lintian now thoughtfully checks for this), it stands to reason that maintainers should also be reminded to change the Section fields in their doc-base files, ideally with the transition being completed pre-Lenny. Therefore, would it be possible to have Lintian run the same check on doc-base file Section fields as it does on menu file section fields? I know that this would certainly help me out! X-Debbugs-CC'ed to the doc-base maintainer in case he wants to comment. Note, if it was *not* the intention to have doc-base follow the menu policy transition, please reassign this bug to doc-base and retitle to doc-base: should explicitly list allowed values for Section field. As an aside, I have a further doc-base question: are all doc-base-using programs currently able to handle spaces within the newly defined set of section fields such as Applications/File Management ? best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#463474: lintian: Please check doc-base Section field for allowed values
Russ Allbery wrote: Kevin B. McCarty [EMAIL PROTECTED] writes: X-Debbugs-CC'ed to the doc-base maintainer in case he wants to comment. Note, if it was *not* the intention to have doc-base follow the menu policy transition, please reassign this bug to doc-base and retitle to doc-base: should explicitly list allowed values for Section field. The main reason why I didn't do this is that there was a lot of controversy and discussion on debian-devel about using the menu categories for doc-base recently, and I was wondering if that would reach some other conclusion. Somehow I must have completely missed that discussion. Thank you for the pointer. I guess what happens next is in the hands of doc-base maintainer then? best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460795: spacechart re: gnome 1.2 removal
Hi Francisco, Pierre, for what it's worth, the last time I contacted spacechart upstream, Miguel Coca miguel AT cocabarrionuevo.com about the deprecation of gnome 1.2, this was his reply: http://lists.alioth.debian.org/pipermail/stardata-common-devel/2006-March/000161.html So unless someone else takes over as spacechart upstream (it won't be me; I'm already upstream for starplot) and can port it to Gnome 2, it sounds as though the Debian package will unfortunately have to be removed. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#427507: ... also lenny bitmap ...
Hi, it's now been 228 days since this wishlist bug (requesting an etch bitmap splash screen for lilo) has been submitted. In the meantime, the testing distribution is now lenny ... if this bug is ever acted upon, please also consider adding a lenny.bmp to lilo package. Thanks and best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#457151: Please reconsider closure of # 457151 -- it affects gfortran transition
Riku Voipio wrote: On Sun, Jan 13, 2008 at 12:44:21PM -0800, Kevin B. McCarty wrote: 7) If dpkg was reverted not to re-order Build-Depends, I could force refblas3gf to be installed first, satisfying the dependency of lapack3gf on atlas3gf-base | refblas3gf | libblas.so.3gf and preventing the attempted installation of non-existent atlas3gf-base. I think lapack3gf depending directly on atlas3gf-base is the root of the problem. I would suggest moving atlas3gf-base dependency to recommends. Thus atlas3gf-base will be pulled onto enduser installations but not on buildd's (where recommends are not installed). I guess this dependency is caused by the shlibs file of refblas3gf being set to atlas3gf-base | refblas3gf | libblas.so.3gf. But if someone installs lapack3-dev, without specifically also requesting ATLAS, IMO it is most likely that they only want refblas3-dev and refblas3gf to be installed. (Otherwise the person would only have installed the ATLAS packages without worrying about the lapack3 packages.) Camm, do you think it would be possible to fine-tune the dependencies of lapack3-dev and lapack3gf so that they ask for refblas3-dev (respectively, refblas3gf) *before* atlas3-base-dev (respectively, atlas3gf-base) ? The former is trivial. Since I think the latter comes from the shlibs file of refblas3gf, I'm not sure how best to implement it. Maybe use an shlibs.local file in the lapack3 source package? So then lapack3-dev would have: Depends: refblas3-dev (= gfortran-transition-version) | atlas3-base-dev (= gfortran-transition-version) | libblas-3gf.so Obviously, substitute in the relevant version numbers for gfortran-transition-version. Also I'm not sure that I got the name of the virtual package right, but you get the idea. Note, the versioning of the dependencies should be added to the lapack3-dev package in any case, even if they aren't re-ordered; currently (at least on my machine) pbuilder is pulling in the version of atlas3-base-dev that hasn't transitioned yet, which is wrong! And lapack3gf would have: Depends: refblas3gf | atlas3gf-base | libblas.so.3gf If this can be done, please consider my objection to the closure of #457151 to be withdrawn. Camm, is it possible? best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#457151: Please reconsider closure of # 457151 -- it affects gfortran transition
Dear dpkg maintainers,
Let me present to you a situation caused by the change to dpkg-dev to
install Build-Depends in alphabetical order:
1) atlas3-base-dev package provides an alternative version of
liblapack.so and libblas.so to the packages refblas3-dev and lapack3-dev
2) Maintainer of those packages (Camm Maguire, in CC) has the runtime
library package lapack3 Depend on atlas3-base | refblas3 | libblas.so.3
3) Up till now, it's been possible for a package (for instance, my
package Cernlib) that build-depends on these -dev packages to make sure
the runtime library package atlas3-base doesn't get installed, by use
of Build-Depends: refblas3-dev, lapack3-dev. The rationale at the
time was just that atlas3-base{,-dev} are larger, so take longer to
download and unpack, causing more wear and tear on buildds.
4) Now that dpkg re-orders Build-Depends, atlas3-base always ends up
installed since lapack3-dev comes alphabetically before refblas3-dev.
5) Until recently this was just an annoyance. But now that we are going
through the gfortran - g77 transition, lapack3 and refblas3 (runtime
libs) have been renamed to lapack3gf and refblas3gf. ATLAS has not yet
transitioned, so there is not yet an atlas3gf-base package existing.
But (in anticipation of it) lapack3gf already Depends on atlas3gf-base
| refblas3gf | libblas.so.3gf.
6) As a result, the version of Cernlib I just uploaded to experimental
for the purpose of furthering the gfortran transition FTBFSes on all
arches due to unsatisfied dependencies:
http://experimental.debian.net/build.php?pkg=cernlib
7) If dpkg was reverted not to re-order Build-Depends, I could force
refblas3gf to be installed first, satisfying the dependency of lapack3gf
on atlas3gf-base | refblas3gf | libblas.so.3gf and preventing the
attempted installation of non-existent atlas3gf-base.
8) If dpkg is not reverted, I fear that the progress of the gfortran
transition will come to a halt until ATLAS can be made to transition
(which due to technical difficulties could possibly be a long time in
coming).
So please reconsider the closing of this bug.
best regards,
--
Kevin B. McCarty [EMAIL PROTECTED]
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751
signature.asc
Description: OpenPGP digital signature
Bug#457151: Please reconsider closure of # 457151 -- it affects gfortran transition
Kevin B. McCarty wrote: 5) Until recently this was just an annoyance. But now that we are going through the gfortran - g77 transition, lapack3 and refblas3 (runtime Typing too fast; of course I meant g77 - gfortran transition sorry for the confusion, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#460015: gfortran-doc: could be updated to depend on gfortran-4.2-doc
Nikita V. Youshchenko [EMAIL PROTECTED] wrote: Since this is related to gcc-dco-non-dfsg infrastructure, I think this should be postponed until FDL docs in gcc is resolved. Which will probably happen only when gcc-4.3 enters unstable. Do you mean to imply that gcc 4.3 documentation will be licensed under something other than GFDL? If so, that's great news! Would you happen to have a link to somewhere I can read more about this? best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454572: cernlib: General update after the debconf review process
Hi Christian, Christian Perrier wrote: The attached tarball contains: - debian/changelog with the list of changes - debian/control with rewrites of packages' descriptions - debian/templates with all the rewritten templates file(s) - debian/po/*.po with all PO files (existing ones and new ones) As said, please use *at least* the PO files as provided here, preferrably over those sent by translators in their bug reports. All of them have been checked and reformatted. In some cases, formatting errors have been corrected. Understood, thank you. For what it's worth, I have made some additional small tweaks to the suggested rewrite of the debian/control file. (Some of them were needed due to changes in library package names necessitated by the gfortran transition.) Due to these tweaks, the line wrapping in debian/control long descriptions may also be different from what you sent me. I hope this is not a problem. It is now safe to upload a new package version with these changes. Please notify me of your intents with regards to this. I plan to upload a new cernlib package, version 2006.dfsg.2-6, to experimental, implementing the gfortran transition for this source package, that also includes the l10n changes. The upload will happen by the end of this week, unless there are unforeseen problems with the package's test suite failing to work when compiled with gfortran. Again, thank you for all your work. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#460015: gfortran-doc: could be updated to depend on gfortran-4.2-doc
Package: gfortran-doc Version: 4:4.1.1.nf3 Severity: wishlist Hi, The version of gfortran-doc currently in Sid depends on the real package gfortran-4.1-doc. Since gfortran in Sid depends on gfortran-4.2, shouldn't gfortran-doc be similarly updated to depend on gfortran-4.2-doc ? best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#457829: cernlib: [INTL:eu] debconf templates bsaqye translation
Christian Perrier wrote: The n tilde for Aitor Ibanez name in the header was encoded in ISO-8859-1 while the rest of the file is UTF-8. That made the file invalid. Corrected file attached. ACK, thanks. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454572: cernlib: [debconf_rewrite] Debconf templates and debian/control review
Hi Christian, for what it's worth, I don't have any important objections to the diff for cernlib control file. I did feel that this revised text sounded a little odd: This metapackage provides the header files and static libraries needed by developers using the Cern libraries and not specifically interested in high energy physics. But I can live with it if you and others feel it is an improvement over the original. (For reference, this was the original: This metapackage provides the header files and static libraries likely to be wanted by developers using the Cern libraries who are not interested specifically in high energy physics.) best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#454572: cernlib: [debconf_rewrite] Debconf templates and debian/control review
Hi Christian, Christian Perrier wrote: Dear Debian maintainer, On Monday, November 19, 2007, I notified you of the beginning of a review process concerning debconf templates for cernlib. The debian-l10n-english contributors have now reviewed these templates, and the proposed changes are attached to this bug report. Please review the suggested changes are suggested, and if you have any objections, let me know in the next 3 days. Please try to avoid uploading cernlib with these changes right now. I have a procedural question -- should I take responsibility for closing this bug, #454572 (as well as all the others that will be submitted for the updated translations) in the next cernlib changelog entry once the changes and updated translations are all integrated? Or is that something that you or others in the Smith Project intend to do? I also have a request. Looking through the diff submitted against the cernlib control file, there are a lot of lines in which the only thing that has changed is whitespace (usually from 2 spaces to 1 space following the end of a sentence) or the word wrapping. In addition to a unified diff, could you also please send me the recommended changes to debian/control in wdiff format so I can see the substantive differences more easily? On my first skim through the diff I have one minor change: the package short descriptions were all changed to Cernlib data analysis tool - something package specific That should be tools plural or maybe suite, as you and others think best. I'll await a wdiff before making more remarks on the debian/control changes (unless you inform me that no wdiff will be available for whatever reason). One final question -- will the Smith Project also be reviewing debian/control files for source packages with no debconf templates? Thanks and best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#448207: lintian: please check for gfortran gf in package names
Marc 'HE' Brockschmidt wrote: It would be nice if Lintian could be made aware that the gf suffix is being used in the names of runtime library packages that have been rebuilt with gfortran instead of g77 (refer to: http://lists.debian.org/debian-toolchain/2007/07/msg0.html ) Is there something in the binary that can be used to determine if it's build with gfortran? One or more of these maybe? ldd $binary | grep -q libgfortran.so objdump -x $binary | grep NEEDED | grep -q libgfortran.so nm -D $binary | grep -q _gfortran best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449433: Should a package supply libgfortran.so and libgfortranbegin.a in /usr/lib?
Package: gfortran-4.2 Version: 4.2.2-3 Severity: minor Hi Matthias et al., Prompted by a couple emails [1] to the ROOT devel list, I'm curious as to why no package in Sid seems to provide a libgfortran.so symlink [without the soversion] nor libgfortranbegin.a directly in /usr/lib. This makes it difficult to link a program with the main routine written in FORTRAN using g++ or gcc as the driver for ld. Currently one needs to add -L/usr/lib/gcc/i486-linux-gnu/4.2 to the linking command before supplying -lgfortran -lgfortranbegin . [1] I'll supply a link to the thread when it becomes available on the web archive of roottalk. Is this an oversight, or a deliberate design decision? Not knowing which, I couldn't decide on the severity of this bug, so I set it to minor. In Etch there was a libgfortran1-dev package that did supply these files (and was depended upon by gfortran-4.1), but nothing equivalent exists in Sid. thanks and best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449433: roottalk links
I wrote: Prompted by a couple emails [1] to the ROOT devel list, I'm curious as to why no package in Sid seems to provide a libgfortran.so symlink [without the soversion] nor libgfortranbegin.a directly in /usr/lib. This makes it difficult to link a program with the main routine written in FORTRAN using g++ or gcc as the driver for ld. Currently one needs to add -L/usr/lib/gcc/i486-linux-gnu/4.2 to the linking command before supplying -lgfortran -lgfortranbegin . [1] I'll supply a link to the thread when it becomes available on the web archive of roottalk. And here are the promised links to the relevant threads: http://root.cern.ch/root/roottalk/roottalk07/1147.html http://root.cern.ch/root/roottalk/roottalk07/1150.html In the meantime, ROOT upstream has decided in svn trunk [2] to utilize gfortran -print-file-name=libgfortran.so gfortran -print-file-name=libgfortranbegin.a to get the paths to gfortran libraries, which I've verified should do The Right Thing (TM) on a Sid system. So this bug is now more academic (at least from the point of view of ROOT) than a real problem -- feel free to close if you wish, or not. [2] http://root.cern.ch/viewcvs/trunk/config/Makefile.linux?r1=20172r2=20658 best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448207: lintian: please check for gfortran gf in package names
Package: lintian Version: 1.23.36 Severity: wishlist Hi, in the process of converting my packages for gfortran transition, I find: W: libgraflib1gf: package-name-doesnt-match-sonames libgraflib1 and lots more errors like these. It would be nice if Lintian could be made aware that the gf suffix is being used in the names of runtime library packages that have been rebuilt with gfortran instead of g77 (refer to: http://lists.debian.org/debian-toolchain/2007/07/msg0.html ) E.g., libpacklib1 - libpacklib1gf but the soname remains libpacklib.so.1. Possible? Thanks and best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440755: Should fortran dependency be gfortran not g77?
Drew Parsons wrote: Package: paw Version: 1:2.14.04.dfsg.2-1 Severity: normal paw has a dependency on g77. As far as I can see g77 is now (under gcc4 or gcc4.2) deprecated in favour of gfortran. Should paw's dependency therefore be upgraded to gfortran rather than g77? Yes, this will be part of the g77 - gfortran transition currently under way. I am waiting on the upload of the transitioned blas, lapack and atlas packages to unstable. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424276: Any news on mysqlclient -dev RC bug?
Hi, Any progress on RC bug #424276? It is over a month old :-( I ask because I am the sponsor for a package (root-system) that FTBFS'es because of it. There are other bugs in root-system we'd like to fix, but there is little point in us doing an upload before this problem of libmysqlclient15-dev is solved. Thanks, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429439: please build against gfortran instead of g77
Kamaraju Kusumanchi wrote: Package: geant321 Version: 1:3.21.14.dfsg-5 Severity: normal --- Please enter the report below this line. --- geant321 currently uses g77 as the fortran compiler. However, g77 is no longer maintained. Instead gfortran is the currently maintained fortran compiler in gcc. It would be nice if geant321 can be built against gfortran instead of g77. Hi, Do you use Geant 3.21 at all? If so, you can (in theory, at least) do a test build of a local copy against gfortran by including gfortran in the environment variable $DEB_BUILD_OPTIONS. Please let me know whether the libraries still work properly after doing so, and installing the resulting .debs. I am worried about possible ABI conflicts caused by building geant321 against gfortran while the underlying stack of libraries (down to libblas and liblapack) are still built with g77. It is also not clear to me whether a soname change will be needed. N.B, you may first need to edit /usr/bin/cernlib in order to change -lg2c to -lgfortran on one line of that script. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425257: root-system_5.15.07-4(hppa/experimental): FTBFS: architecture not supported
Hi Christian and others, Christian Holm Christensen wrote: Kevin, you have any idea how to proceed on this? Fons, I send you this report too, so you can say what you think. We can probably expect more of these kind of errors, since ROOT hasn't been tested on all `exotic' Linux platforms. I hope Frank answered all that you need regarding hppa? I am no minor arch expert unfortunately. I can provide a list by endianness and bit size -- little-endian, 32-bit: i386, s390, mipsel, arm big-endian, 32-bit:powerpc, armeb [*], m68k, sparc, mips, hppa little-endian, 64-bit: amd64, ia64, alpha big-endian, 64-bit:powerpc64 [*], s390x [*], sparc64 [*] [*] = experimental or not yet fully supported (e.g. there are 64-bit kernels for sparc64 machines but most provided packages have a 32-bit userland) Oh, and another question, I looked at the amd64 build logs (I know this is slightly off topic, but anyways), and towards the end it said g++ -O2 -pipe -Wall -m64 -fPIC -Iinclude -DR__HAVE_CONFIG -pthread -I/usr/include/mysql -DUSEPCH -include precompile.h -o mysql/src/TMySQLServer.o -c mysql/src/TMySQLServer.cxx In file included from mysql/src/TMySQLServer.cxx:23: /usr/include/mysql/my_global.h:353:24: error: asm/atomic.h: No such file or directory make[1]: *** [mysql/src/TMySQLServer.o] Error 1 rm utils/src/rootcint_tmp.cxx utils/src/RStl_tmp.cxx make[1]: Leaving directory `/build/buildd/root-system-5.15.07' make: *** [build-arch-stamp] Error 2 For some reason, the MySQL header includes `asm/atomic.h' which for some reason isn't available. I realise that this is a problem with MySQL on that platform, but what to do about it? Looks like this has already been filed as #424276 against libmysqlclient15-dev, so in principle you don't need to do anything but wait until the bug is fixed there. (It is serious so should be resolved soon.) I see ia64 fails because gfortran is not available, and g77 should be used instead. I guess a Build-Depends like gfortran [!ia64] | g77 [ia64] | fortran-compiler would do the trick? Not sure what you mean. Checking the ia64 log, the gfortran package (and gfortran-4.1) do get installed, and in the ROOT configure script, it finds gfortran. However, the failing line in the ia64 log is: g77 -O2 -o hbook/src/hntvar2.o -c hbook/src/hntvar2.f make[1]: g77: Command not found make[1]: *** [hbook/src/hntvar2.o] Error 127 and this is preceded, immediately after configure runs, by: # Add here commands to compile the arch part of the package. /usr/bin/make ASTEPETAG= XROOTDETAG= UNURANETAG= make[1]: g77: Command not found make[1]: Entering directory `/build/buildd/root-system-5.15.07' make[1]: g77: Command not found make[1]: g77: Command not found so for some reason it is trying to use g77 *anyway* even though the configure script found gfortran. That is probably what should be fixed (or alternately you could switch it to use g77 on all arches?) I should also exclude root-plugin-hbook on kfreebsd-amd64. Yes... best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425257: root-system_5.15.07-4(hppa/experimental): FTBFS: architecture not supported
I wrote: I can provide a list by endianness and bit size -- little-endian, 32-bit: i386, s390, mipsel, arm big-endian, 32-bit:powerpc, armeb [*], m68k, sparc, mips, hppa little-endian, 64-bit: amd64, ia64, alpha big-endian, 64-bit:powerpc64 [*], s390x [*], sparc64 [*] oops, my apologies, s390 should be filed under BIG-endian, 32-bit. -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423223: lintian: Please add directory name sanity check for orig.tar.gz
Package: lintian Severity: wishlist Hi Lintian maintainers, Would it be possible to add a severity warning check on the orig.tar.gz or tar.gz to make sure that the directory inside the tarball has a sane name? Specifically it should be named with one of the forms sourcepkg-upstream_version sourcepkg-upstream_version.orig [latter is probably not OK for Debian-specific tar.gz] where upstream_version is the version given in the most recent debian/changelog entry, with the epoch and Debian release stripped. The convention is documented as a should in Developers' Reference 6.7.8. This check would have saved me from #416008 ;-) best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423140: More uninitialized value excitement in dpkg-genchanges
Some more uninitialized value complaints, this time in dpkg-genchanges: dpkg-source: building paw in paw_2.14.04.dfsg.2-1.dsc dpkg-genchanges -S Use of uninitialized value in pattern match (m//) at /usr/bin/dpkg-genchanges line 236, CDATA line 158. Use of uninitialized value in hash element at /usr/bin/dpkg-genchanges line 242, CDATA line 158. [etc.] best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423229: lintian: false positive for manpage-for-non-x11-binary-in-wrong-directory
Package: lintian
Version: 1.23.30
Tags: patch
Hi,
Lintian has a false positive for
manpage-for-non-x11-binary-in-wrong-directory on my package paw as a
result of a binary having X11 in its name:
benjo2 (sid)[28]:~/Debian/PAW% lintian -i paw_2.14.04.dfsg.2-1_i386.changes
E: paw: manpage-for-non-x11-binary-in-wrong-directory usr/bin/pawX11
usr/share/man/man1/pawX11.1.gz
N:
N: Manual pages for binaries that are not located in /usr/X11R6/bin
N: should not be installed below /usr/X11R6/man, but below
N: /usr/share/man.
N:
N: Note that moving a binary into /usr/X11R6/bin is almost never the
N: proper solution for this problem; move the manual page instead.
N:
I'm attaching a trivial patch against lintian-1.23.30/checks/manpages
which may or may not be right, since my Perl is not so good. The patch
does prevent the false positive, and Lintian was still able to pick up
on a manpage that I deliberately installed to usr/X11R6/man/man1 in a
test .deb.
Instead of applying my patch, however, it actually might make more sense
to remove this check completely. Since installing to /usr/X11R6 is now
a no-no anyway, this check seems to be superseded by
package-installs-file-to-usr-x11r6.
best regards,
--
Kevin B. McCarty [EMAIL PROTECTED] Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
--- manpages.orig 2007-04-26 22:44:46.0 -0400
+++ manpages2007-05-10 14:02:08.0 -0400
@@ -338,7 +338,8 @@
} else {
for my $manp_info (@{$manpage{$f}}) {
# no. manpage in X11?
- if ($manp_info-{file} =~ m/X11/) {
+ if ($manp_info-{file} =~ m/\/X11\// ||
+ $manp_info-{file} =~ m/\/X11R6\//) {
tag manpage-for-non-x11-binary-in-wrong-directory,
$binary{$f} $manp_info-{file};
} else {
# ok.
Bug#423223: lintian: Please add directory name sanity check for orig.tar.gz
Russ Allbery wrote: Kevin B McCarty [EMAIL PROTECTED] writes: The convention is documented as a should in Developers' Reference 6.7.8. To the contrary, devref 6.7.8 makes it clear that one should NOT do this. You should use the virgin upstream source tarball, with whatever directory name they ship with. dpkg copes, and you should not repackage upstream just to change the directory name. *If* the source is repackaged, *then* you should use the .orig convention, but lintian has no way of knowing whether the source is repackaged or not. Hmm, OK, maybe lintian could make this check only if the package's version number includes .dfsg or .ds or the diff.gz includes debian/README.Debian-source ? Those seem to me to be sufficient (though not necessary) conditions to determine that the source was repackaged. (Unless upstream for some reason used .dfsg or .ds in their own versioning scheme.) I guess this could be a bit complicated, though, so feel free to tag this bug wontfix or close it. This check would have saved me from #416008 ;-) That's not really a bug. That's not a supported way of unpacking a Debian package. Debian packages should be unpacked with dpkg-source or with a program that performs the same operations. Since you're repackaging the upstream source anyway, you can certainly fix it if you so choose, but there's no need to do so. OK, thank you for the clarification. I've been redoing the orig.tar.gz files for the affected packages even if it isn't a real bug, just to make things cleaner. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423136: apt-move: built against experimental libgcc1 and libstdc++6
Package: apt-move Version: 4.2.27-1 Severity: serious Hi, apt-move is currently uninstallable in unstable (at least on i386) since it depends on libgcc1 (= 1:4.2-20070208) and libstdc++6 (= 4.2-20070208). Maybe it was by accident built against gcc 4.2 on the maintainer's machine? If so, a bin-NMU should suffice to fix it, assuming it's bin-NMU safe. regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423136: apt-move: built against experimental libgcc1 and libstdc++6
Chuan-kai Lin wrote: On Wed, May 09, 2007 at 10:05:04PM -0700, Kevin B. McCarty wrote: apt-move is currently uninstallable in unstable (at least on i386) since it depends on libgcc1 (= 1:4.2-20070208) and libstdc++6 (= 4.2-20070208). Maybe it was by accident built against gcc 4.2 on the maintainer's machine? If so, a bin-NMU should suffice to fix it, assuming it's bin-NMU safe. Good catch -- it never occurred me to check that before uploading the i386 binary. I can probably whip up an unstable chroot environment and rebuild the package this weekend, but a bin-NMU is also quite welcome. Release team, would you have any objection to scheduling a bin-NMU for apt-move on i386? best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423140: update-alternatives: lots of uninitialized value error messages
Package: dpkg Version: 1.14.2 Hi, My latest upgrade in sid provoked lots of update-alternatives errors (or maybe just warnings?) from nano and gij-4.1 maintainer scripts. These probably pertain to dpkg 1.14.2, since the output of the upgrade (done with aptitude) shows Setting up dpkg (1.14.2) ... before any of the errors. For what it's worth, the previous version of dpkg from which I upgraded was 1.13.25. Maybe this is related to the following change in dpkg 1.14.0? * Make all perl scripts use strict and warnings, to ease catching errors. Here are the messages. To summarize, the problematic lines in /usr/sbin/update-alternatives seem to be lines 461, 595, 717 and 718. The messages seem wordy but harmless; at least, the alternatives set up for the nano and gij-4.1 packages still look OK. For nano (upgraded from version 2.0.4-1) Setting up nano (2.0.6-1) ... Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in string eq at /usr/sbin/update-alternatives line 595. Use of uninitialized value in string eq at /usr/sbin/update-alternatives line 595. Use of uninitialized value in string eq at /usr/sbin/update-alternatives line 595. Use of uninitialized value in string eq at /usr/sbin/update-alternatives line 595. Use of uninitialized value in string eq at /usr/sbin/update-alternatives line 595. Use of uninitialized value in string eq at /usr/sbin/update-alternatives line 595. Use of uninitialized value in string eq at /usr/sbin/update-alternatives line 595. Use of uninitialized value in string eq at /usr/sbin/update-alternatives line 595. Use of uninitialized value in string eq at /usr/sbin/update-alternatives line 595. Use of uninitialized value in string eq at /usr/sbin/update-alternatives line 595. For gij-4.1 (upgraded from version 4.1.2-4) Setting up gij-4.1 (4.1.2-6) ... Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty
Bug#421985: FTBFS: /usr/bin/ld: cannot find -lXbae
Martin Michlmayr wrote: Package: paw Version: 1:2.14.04-7 Severity: serious This package fails to build in unstable: Automatic build of paw_1:2.14.04-7 on em64t by sbuild/amd64 0.53 .. gcc clip.c gcc matrix.c gcc version.c make[4]: Leaving directory `/build/tbm/paw-2.14.04/build/paw_motif/xbae' rebuild shared library libpawlib-lesstif.so.2.2005 in /paw_motif Wed May 2 04:16:02 CEST 2007 /usr/bin/ld: cannot find -lXbae collect2: ld returned 1 exit status make[3]: *** [libpawlib-lesstif.so.2.2005] Error 1 make[3]: Leaving directory `/build/tbm/paw-2.14.04/build/paw_motif' Will be fixed when I re-upload the paw source package currently in experimental into unstable. Note, this may take a little while since I also realized in the meantime that Paw needs a soversion bump on one of the libraries. thanks and best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372655: Ditto for #372655 (viewcvs broken in Etch)
Add me to the list of people affected by this bug. IMO either viewcvs in Etch should be patched in stable to work appropriately, or it should be removed from stable. Personally, I switched back to CVSWeb, which interestingly enough works fine with the current version of CVS in Etch. regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420384: [dch] Python warnings about uninitialized values
Package: devscripts Version: 2.10.3 Severity: minor Hi, dch in sid has started to emit some apparently minor warnings: benjo2 (sid)[3]:~/Debian/CERNLIB/cernlib-2006.dfsg.2% dch Use of uninitialized value in concatenation (.) or string at /usr/bin/dch line 191. Use of uninitialized value in string ne at /usr/bin/dch line 213. I unfortunately don't know how long it has been like this, since this is immediately following the first upgrade I've done in my Sid chroot for a few weeks. regards, -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-k7 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages devscripts depends on: ii debianutils 2.18 Miscellaneous utilities specific t ii dpkg-dev 1.13.25package building tools for Debian ii libc6 2.5-2 GNU C Library: Shared libraries ii perl 5.8.8-7Larry Wall's Practical Extraction ii sed 4.1.5-1The GNU sed stream editor Versions of packages devscripts recommends: ii fakeroot 1.7Gives a fake root environment -- no debconf information -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416008: cernlib-base-dev: cernlib-debian.mk typos - as _ in directory name in orig.tar.gz
Package: cernlib-base-dev Version: 2006.dfsg-1 Angelo Graziosi wrote: I have observed that when one unpacks 'cernlib_2006.dfsg.orig.tar.gz' it contains the directory cernlib_2006.dfsg.orig, but 'cernlib_2006.dfsg-1.diff.gz' refers to cernlib-2006.dfsg. This causes that gunzip -c cernlib_2006.dfsg-1.diff.gz | patch -p0 results in a new directory cernlib-2006.dfsg out of cernlib_2006.dfsg.orig. I think that cernlib_2006.dfsg.orig should be changed in cernlib-2006.dfsg.orig before packaging into cernlib_2006.dfsg.orig.tar.gz, or not ? You are correct, the directory in the orig.tar.gz should be cernlib-2006.dfsg.orig with a hyphen rather than an underscore. My error. I will make sure this gets fixed before the packages are moved out of experimental. Submitting this to the BTS so I don't forget. (This problem is also the case for the paw and mclibs source packages in experimental, since the typo originated in the cernlib-debian.mk shipped in cernlib-base-dev. I will rebuild them all with versions 2006.dfsg.2-1, or 1:2.14.04.dfsg.2-1 in the case of paw.) Thanks and best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415738: [john] FTBFS on mipsel
Package: john Version: 1.6-40.1 Severity: serious Tags: help Three build attempts of my NMU of john failed on the rem mipsel buildd: http://buildd.debian.org/build.php?pkg=johnver=1.6-40.1arch=mipselfile=log However, it has been possible to build this source package (at least on Etch) on mipsel without a problem: http://lists.debian.org/debian-mips/2007/03/msg00022.html Note that my NMU did not change any of the source code of the package, only the maintainer scripts and debian/control. That is, something that successfully built before on mipsel is no longer working. (This package was already not a candidate for Etch, so it unfortunately looks like it will not be part of the Etch release at this point anyway.) I really have no idea what the problem could be so I'll tag this as help. -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415738: Acknowledgement ([john] FTBFS on mipsel)
For what it's worth, I have been able to build both john 1.6-40 and 1.6-40.1 with no troubles in the sid chroot of vaughan.debian.org. So I can't reproduce this bug on the only mipsel machine to which I have access. However, I don't intend to upload this package, as it must also be possible to build on the regular and security buildds! regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Bug#375850: Planning to go ahead with NMU tomorrow morning
Justin Pryzby wrote:
On Tue, Mar 13, 2007 at 11:25:27PM -0700, Kevin B. McCarty wrote:
Hi Justin,
Not having heard from you yet, since there is now a new urgency
resulting from the latest release announcement [0], I am planning to go
ahead and NMU the RC bugs in john tomorrow morning (also wishlist
#412797, gl.po for debconf, while I am at it). I hope that you don't mind!
[0] http://lists.debian.org/debian-devel-announce/2007/03/msg00012.html
Hi Kevin,
This is probably for the best. Thanks.
OK, I am uploading the NMU (diff since 1.6-40 attached) immediately.
Thank you for your work in putting the patch together!
best regards,
--
Kevin B. McCarty [EMAIL PROTECTED] Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
diff -ur john-1.6.old/debian/README john-1.6/debian/README
--- john-1.6.old/debian/README 2007-03-14 17:26:41.0 -0400
+++ john-1.6/debian/README 2007-03-14 13:11:44.388616615 -0400
@@ -8,7 +8,7 @@
and run until either all passwords were found or it wasn't able to
crack them.
- So starting with this version of the package (1.6.19) the new cronjob
+ So starting with version 1.6-19 of the package, the new cronjob
is a lot more flexible. The system administrator will now be able to
define when to start the cronjob and how long it should run daily. The
cronjob will then be automatically stopped after that time and the
@@ -18,17 +18,12 @@
of the password file, you need to remove the file
/var/lib/john/restore.
- The package ugrade already installed the new cronjob and offered to
- remove the old cronjob. In case that you let the package upgrade remove
- the old cronjob, you now need to edit the file /etc/cron.d/john to
- define at which time the cronjob shall be started and at which time it
+ The package upgrade already installed the new cronjob and removed the
+ old one. If you want the new cronjob to run, you must uncomment the
+ active lines from /etc/cron.d/john; you might also modify it to
+ change at which time the cronjob shall be started and at which time it
should be stopped.
- In case that you didn't allow the package upgrade to remove the old
- cronjob, you will need to remove the file /etc/cron.daily/john
- manually. You can then also edit the file /etc/cron.d/john as described
- in the paragraph above.
-
The new cronjob will only be started after you edited /etc/cron.d/john.
If you don't edit the file, the cronjob will not be started and you can
run john from the command line.
diff -ur john-1.6.old/debian/changelog john-1.6/debian/changelog
--- john-1.6.old/debian/changelog 2007-03-14 17:26:41.0 -0400
+++ john-1.6/debian/changelog 2007-03-14 17:06:55.879739617 -0400
@@ -1,3 +1,29 @@
+john (1.6-40.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * High-urgency for RC bugfix.
+ * The following bug fixes are mostly cherry-picked from an omnibus patch
+by Justin Pryzby [EMAIL PROTECTED]:
+ * Complete rewrite of maintainer scripts to neither remove nor edit
+conffiles (Closes: #375850)
+ - the debconf settings are not necessary for package operation,
+ so just don't use debconf, and remove debconf-related files from
+ debian directory (incidentally closes: #412797)
+ - preserves settings in preinst, rather than moving conffiles to
+ foo.old
+ - do the conffile relocation in preinst (not postinst, which
+ inhibits dpkg diffs when they should be displayed)
+ - the cronjob in /etc/cron.d does nothing if the executable isn't
+ +x, so doesn't need to be commented out on uninstallation
+ - minor edits to debian/README to reflect these changes
+ * Set /var/run/john to mode 0700 in postinst configure unless a
+dpkg-statoverride exists (Closes: #403855)
+ * On uninstallation, remove restore file from /var/lib, not /usr/share;
+and do so in postrm remove, not prerm remove. On upgrade, if restore
+file exists in /usr/share but not in /var/lib, move it in postinst.
+
+ -- Kevin B. McCarty [EMAIL PROTECTED] Wed, 14 Mar 2007 17:06:16 -0400
+
john (1.6-40) unstable; urgency=low
* debian/control: updated my e-mail address.
Only in john-1.6.old/debian: config
diff -ur john-1.6.old/debian/control john-1.6/debian/control
--- john-1.6.old/debian/control 2007-03-14 17:26:41.0 -0400
+++ john-1.6/debian/control 2007-03-14 13:03:53.676373234 -0400
@@ -4,11 +4,11 @@
Maintainer: Guilherme de S. Pastore [EMAIL PROTECTED]
Uploaders: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED]
Standards-Version: 3.6.2
-Build-Depends: cdbs, debhelper (= 4.1.16), po-debconf
+Build-Depends: cdbs, debhelper (= 4.1.16)
Package: john
Architecture: any
-Depends: ${shlibs:Depends}, dpkg (= 1.10.16), debconf | debconf-2.0
+Depends: ${shlibs:Depends}, dpkg (= 1.10.16)
Suggests: wenglish | wordlist
Description: active password cracking tool
john, mostly
Bug#375850: Planning to go ahead with NMU tomorrow morning
Hi Justin, Not having heard from you yet, since there is now a new urgency resulting from the latest release announcement [0], I am planning to go ahead and NMU the RC bugs in john tomorrow morning (also wishlist #412797, gl.po for debconf, while I am at it). I hope that you don't mind! [0] http://lists.debian.org/debian-devel-announce/2007/03/msg00012.html best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Bug#414534: ITP: sucrack -- multithreaded su bruteforcer
* Package name: sucrack Version : 1.1 Upstream Author : Nico Leidecker [EMAIL PROTECTED] * URL : http://www.leidecker.info/ * License : GPL Programming Lang: C Description : multithreaded su bruteforcer sucrack is a multithreaded Linux/UNIX tool for cracking local user accounts via wordlist bruteforcing su What advantages does this tool have over John the Ripper (Debian package john)? best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403855: Please NMU john
Hi Justin, Please consider NMU-ing john, since there has been no maintainer response to your emails with patches for 375850 and 403855 from December, 2.5 months ago. It would be very useful to have this package in Etch (I use it on my cluster to test that my users have reasonable passwords), especially since it was already present in Sarge. I note that the primary maintainer (G. Pastore) is listed at http://wiki.debian.org/LowThresholdNmu . If you are not currently a DD (I am sorry not to know; I find it hard to keep track of who has gotten through NM yet), tell me where to find your .dsc et al for the NMU, and I will sponsor the upload. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Bug#403855: Please NMU john
Justin Pryzby wrote: Hi Kevin, I'm not yet a DD, but really should return to my NM application.. Thanks for the sponsorhip offer; I too think it's an important application. (Though, I'm told that people often feel threatened when their terrible passwords are shown to be such, since they're often also using the same one to access other things too). I'll try to prepare a formal nmu patch tonight. Otherwise (or in advance thereof) feel free to upload with the patch. I will wait for you to put together the NMU if that's OK with you. Since you went to the trouble of working out patches for these bugs, I feel your name ought to be on the changelog entry for proper credit. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412006: dvidvi: Please Replace texlive-extra-utils ( 2005.dfsg.2-12)
Package: dvidvi Version: 1.0-8etch1 Severity: important Hello, On upgrading texlive in Sid, which no longer provides a dvidvi binary and now Recommends the dvidvi package instead, I got the following: Selecting previously deselected package dvidvi. Unpacking dvidvi (from .../dvidvi_1.0-8etch1_i386.deb) ... dpkg: error processing /var/cache/apt/archives/dvidvi_1.0-8etch1_i386.deb (--unpack): trying to overwrite `/usr/bin/dvidvi', which is also in package texlive-extra-utils This happens because at the time dvidvi was unpacked, the older version of texlive-extra-utils was still installed. This is the companion bug to #411537. The issue could be worked around if dvidvi had a line like Replaces: texlive-extra-utils ( 2005.dfsg.2-12) in its control file. If this fix could be targeted for etch-proposed-updates (e.g. version number 1.0-8etch2) and if that version of dvidvi, and version 2005.dfsg.2-12 of texlive-bin, make it into Etch, then it will be possible to upgrade texlive-extra-utils from earlier versions of Sid or Etch with no troubles. (Severity important rather than RC, since this issue won't affect people upgrading to Etch or Sid from Sarge where there are no texlive packages. X-Debbug-CC'ed to release and tex-maint teams.) -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-3-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages dvidvi depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries dvidvi recommends no packages. -- no debconf information best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366355: #366355: Bad pixmaps in some cases here, too
Hi, I was browsing debian-x archives and came across mention of this bug, and realized I just saw the garbled pixmap form of it a few days ago... Xavier Bestel wrote: FWIW I think it's with the X libs in sarge, because I often have troubles when I ssh -X from a RedHat box to my sarge box, then to my sid box. So the sid X server isn't involved here. My problems are sometimes X errors, but more often wrong pixmaps, i.e. some GTK widgets are displaying the wrong icon, or some random portion of another pixmap. On Friday (I think) I was sitting at an AMD64 workstation running Debian/etch, logged in with ssh -X to an x86 workstation running Debian/sarge. Running Thunderbird on the Sarge machine (i.e. X server on amd64/etch, client on i386/sarge), the Thunderbird icons were all garbled, as were the displays of any image attachments in the email viewer. Peculiarly enough, running Firefox over the same connection experienced no such problems: both web browser images and icons were fine. Also, double-clicking the attachment icons for attached images in Thunderbird pops up the images in an ImageMagick display window, where they looked fine also. I didn't try Thunderbird again to see if the problem was intermittent there. Unfortunately I am now across the country from both machines in question, so this email is probably not much more use to you than a me, too... I can send the XF86Config-4 and xorg.conf files for both machines if that would be of any use. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
