Bug#724660: libnetcdf-dev: netcdf.mod has been generated with gfortran-4.7 while 4.8 is default
Package: libnetcdf-dev Version: 1:4.1.3-6+b1 Severity: normal usr/include/netcdf.mod file has been created by gfortran-4.7 while now default version in SID is 4.8. It is currently not possible to compile a Fortran program calling use netcdf with default gfortran command. Is it possible to recompile the package libnetcdf-dev ? Thanks, Damien. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701274: Issue with NetCDF
Hello, NetCDF is currently compiled with gfortran 4.7, so ETSF_IO should be compiled with the same compiler. What do you suggest: - recompile netcdf with current gfortran (i.e. 4.8) but need to recompile also all package depending on NetCDF fortran. - force gfortran 4.7 in ETSF_IO build dependencies and change when NetCDF is recompiled. This has been debated already on the science mailing list, but I didn't remember that a consensus was reached. Regards, Damien. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714297: Unicode-data is not in UTF8
Hello, In fact, with respect to my previous email, the fact that the Perl script is not working is because the package unicode-data is in version 6.1 while this script is made for 6.2… Indeed, before 6.1 (included), NameLists.txt was in iso8859-1, and the Perl script was iconving it to UTF8 before generating the .h for gucharmap. But since Unicode version 6.2, the NameLists.txt file is in UTF8, so the Perl script has the conversion deactivated. I suggest to upload a new unicode-data package with 6.2 version, or to reactivate the conversion in the Perl script (and to deactivate later when unicode-data will be upgraded). What do you think ? Damien. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618168: Gfortran module issue
Hello, It seems to me that the issue comes from the fact that NetCDF has been compiled with gfortran 4.4 (current version of /usr/include/netcdf.mod from libnetcdf-dev) while current gfortran compiler is 4.6. So when the configure of ETSF_IO tries to compile a test from NetCDF written in Fortran, it fails because of the NetCDF module being not-usable. This small code doesn't compile currently in Debian: program foo use netcdf call nf90_open(toto.nc) end program foo gives : caliste@coriandre:~/tmp$ gfortran -I /usr/include -c toto.f90 toto.f90:3.12: use netcdf 1 Fatal Error: Wrong module version '0' (expected '6') for file 'netcdf.mod' opened at (1) While with gfortran-4.4: caliste@coriandre:~/tmp$ gfortran-4.4 -I /usr/include -c toto.f90 toto.f90:3.12: use netcdf 1 toto.f90:5.27: call nf90_open(toto.nc) 2 Error: 'nf90_open' at (1) has a type, which is not consistent with the CALL at (2) The module file is correctly understood and raise a comoilation accordingly. The solution would be to force gfortran 4.4 for ETSF_IO but it's not clean. The other solution would be to rebuild automatically every package that exposes a Fortran module file at each gfortran update. Damien. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576968: libnetcdf-dev: netcdf.mod has been generated with gfortran-4.3 while 4.4 is default
Package: libnetcdf-dev Version: 1:3.6.3-1 Severity: normal /usr/include/netcdf.mod file has been created by gfortran-4.3 while now default version in SID is 4.4. So compiling the test program below with gfortran command fails : program test use netcdf write(*,*) hi end program etst toto.f90 cali...@coriandre:~/tmp$ gfortran-4.3 -I /usr/include -c toto.f90 cali...@coriandre:~/tmp$ gfortran -I /usr/include -c toto.f90 toto.f90:2.13: use netcdf 1 Fatal Error: Parse error when checking module version for file 'netcdf.mod' opened at (1) So, is it possible to recompile the package libnetcdf-dev with latest gfortran ? -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libnetcdf-dev depends on: ii libnetcdf41:3.6.3-1 An interface for scientific data a libnetcdf-dev recommends no packages. Versions of packages libnetcdf-dev suggests: ii netcdf-bin1:3.6.3-1 Programs for reading and writing N pn netcdf-docnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556517: FTBFS with binutils-gold
Hello, I've checked this, installing binutils-gold, and it seems to me that this does not affect the 3.5.0-2 version. The building of the objects for V_Sim have been separated into two parts, one core, compiled as libv_sim.so and one GUI part, compiled as libgui.a and linked with the main object visu_main.o to create the executable. The libgui.a contains many functions from GTK/GLIB/GObject..., some GL functions and some mathematical ones. All the associated -l are already present. The libv_sim.so itself contains many things and in particular some X routines, but it seems that the creation of the .so does not require to specify the missing -lX11, does it ? Can you confirm that this bug does not apply to version = 3.5 ? Thanks, Damien. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556517: FTBFS with binutils-gold
Hello, Ok, I'm sorry for the previous post. It seems that I made a mistake in the manipulation, the usual compilation of the package (configure make) didn't raise any problem at link, thus my reply. But in reality, compiling a Debian package from it with dpkg-buildpackage, raise the issue. So I correct it in the configure.ac to add -lX11 when required. I've submitted a new bug correction version, including this one, and ask to close the bug in the changelog. It should work now (hope so). Damien. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#492980: v-sim: V_Sim crashes on exporting a picture
Hello, Le 30/07/2008, Ferdinand Rissner [EMAIL PROTECTED] a écrit : Can you confirm that the workaround reported in this bug report works for you ? Yes, I can confirm that! Exporting to all formats provided works fine now. This bug has been also triggered by the glxpixmap demo file of mesa, as reported in this thread: http://bugs.freedesktop.org/show_bug.cgi?id=9200 Exporting to pixmap is not implemented with hardware acceleration and the software should handle this by itself, see: http://bugs.freedesktop.org/show_bug.cgi?id=11162 I will correct this in V_Sim, wait for a patch... Damien. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492869: [Pkg-scicomp-devel] Bug#492869: Bug#492869: [paraview] saving topng kills paraview
Hello, On Tue, 29 Jul 2008 19:53:06 +0200, Ondrej Certik [EMAIL PROTECTED] wrote: Let's leave this bug open, because clearly there is a stupid bug somewhere, even though it doesn't seem to be a bug in paraview. This bug seems to be related in general to the drawing of GL commands into pixmaps. It seems to me that without this AIGLX at False, the example of GtkGlExt which exports into a pixmap crash also (as my own GL code to do it). See for instance http://mail.gnome.org/archives/gtkglext-list/2007-March/msg0.html It was encountered a long time ago (since 2006) but I don't know to who make a clear bug report for it to be fixed. Damien. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492869: [Pkg-scicomp-devel] Bug#492869: Bug#492869: [paraview] saving topng kills paraview
Hello, On Wed, 30 Jul 2008 11:25:15 +0200, Ondrej Certik [EMAIL PROTECTED] wrote: Some debian package that the GtkGlExt example depends on? Since you know more about the bug, you can probably guess better than I. In fact, I don't use any package with GtkGlExt, I just used it when I encountered the bug in my own program to test if I was doing something wrong with OpenGL. If you could report it, it'd be awesome, it's a really annoying bug. Looking a bit here and there, I've found this reported bug that looks the same: [EMAIL PROTECTED] and some information was available in bug [EMAIL PROTECTED] (last message): maybe pixmap context is not available depending on the hardware/setting. I try to find a machine with a non-NVidia card and GLX 1.3 to test. Damien. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476094: retry option add default values to command-line passed ones
Package: nfs-common
Version: 1:1.1.2-2
Severity: minor
When I invoke mount.nfs with the retry option, I'm surprised that the
retry duration will be the amount of time I gave *plus* the default
duration. This is not what is written in the nfs man page, quote:
'The number of minutes that the mount(8) command retries
an NFS mount operation [...] If this option is not specified, the
default value for foreground mounts is 2 minutes'.
But typing:
'date mount.nfs server:/foo /mnt -o retry=2 -v' returns:
'Mon Apr 14 14:50:44 CEST 2008
mount.nfs: timeout set for Mon Apr 14 14:54:44 2008'
and not timeout set for 14:52:44...
When looking in the source file, it happens that default duration is
always added. Is this on purpose? If true, it should be specified in
the man page. If not, I attach a patch to take the command line values
when available.
Thanks,
Damien.--- nfs-utils-1.1.2.orig/utils/mount/stropts.c
+++ nfs-utils-1.1.2/utils/mount/stropts.c
@@ -538,10 +538,11 @@
time_t timeout = time(NULL);
char *retry;
- timeout += 60 * 2; /* default: 2 minutes */
retry = po_get(options, retry);
if (retry)
timeout += 60 * atoi(retry);
+ else
+ timeout += 60 * 2; /* default: 2 minutes */
if (verbose)
printf(_(%s: timeout set for %s),
@@ -615,10 +616,11 @@
time_t timeout = time(NULL);
char *retry;
- timeout += 60 * 1; /* default: 10,000 minutes */
retry = po_get(options, retry);
if (retry)
timeout += 60 * atoi(retry);
+ else
+ timeout += 60 * 1; /* default: 10,000 minutes */
for (;;) {
if (sleep(secs))
Bug#445367: Failing vol_id for some USB keys
Package: udev
Version: 0.114-2
Because of this bug, udev does not create the /dev entries (sda and
sda1) for my USB key (a Creative Muvo 128Mo). I solved it (see the end
of the mail) for my configuration. But here is the description of what
happen.
I log in a console to see kernel messages and also run udev with log in
'debug' mode instead of 'err'. After the key has been plugged, the
kernel send the usual messages about a new usb peripheral and report
that it will be named sda and has one partition sda1. All udev stuff is
working and the genuine entries are created in /dev (the entry by-path,
by-label...) until it comes to run 'vol_id --export /dev/sda'. Here the
kernel raise a problem of I/O access on block 256000 and the key is
removed by the kernel because of I/O errors. Finally, udev being aware
of this removal, delete the sda entry of /dev.
I stopped udev (/etc/init.d/udev stop), unplugged my key and replug it.
I create the nodes by hand ('mknod sda b 8 0' and 'mknod sda1 b 8 1')
and was able to mount the sda1 partition and read it correctly. Then, I
try to run '/lib/udev/vol_id --export /dev/sda' and it fails as in the
udev scripts, making the kernel rejecting my key. By the way, it works
perfectly on sda1.
I looked in the /etc/udev/rules.d/z25_persistent.rules and vol_id is
called once at the end. I added then:
KERNEL==sd*[!0-9], SYSFS{removable}==1,
GOTO=persistent_storage_end
just after the line:
KERNEL==hd*[!0-9], SYSFS{removable}==1,
GOTO=persistent_storage_end
May I suggest to include this line in the official udev script if
vol_id is indeed made for scanning partition only?
So with the additional line, it works for me. But you may be interested
in finding why vol_id makes the kernel reject my key. If so please send
me instructions on what to do or what information you may need. I test
it for different kernels (2.6.18 and 2.6.21) and the behaviour was the
same, always related to vol_id from udev.
Best regards,
Damien.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
