Bug#1072524: systemd: On a debian trixie, after upgrading systemd to latest version the system fails to reboot.
Indeed, it seems that I have tweeked my debian box for nvidia-docker at the time. In /etc/default/grub: # Add this line for nvidia-docker GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0" Christophe TROPHIME Research Engineer CNRS - LNCMI 25, rue des Martyrs BP 166 38042 GRENOBLE Cedex 9 FRANCE Tel : +33 (0)4 76 88 90 02 Fax : +33 (0) 4 76 88 10 01 Office U 19 M@il : christophe.troph...@lncmi.cnrs.fr - Original Message - > From: "Luca Boccassi" > To: "Christophe Trophime" > Cc: 1072...@bugs.debian.org > Sent: Monday, June 3, 2024 7:33:45 PM > Subject: Re: systemd: On a debian trixie, after upgrading systemd to latest > version the system fails to reboot. > On Mon, 3 Jun 2024 at 18:29, Christophe Trophime > wrote: >> >> Hi, >> could you please just tell what info do you need? > > As already mentioned: did you customize the kernel command line? > Cgroupsv2 has been the default for years > >> - Original Message - >> > From: "Luca Boccassi" >> > To: 1072...@bugs.debian.org >> > Cc: "Christophe Trophime" >> > Sent: Monday, June 3, 2024 6:53:19 PM >> > Subject: Re: systemd: On a debian trixie, after upgrading systemd to latest >> > version the system fails to reboot. >> >> > Control: tags -1 moreinfo >> > >> > On Mon, 03 Jun 2024 18:41:12 +0200 Christophe Trophime >> > wrote: >> >> Package: systemd >> >> Version: 256~rc3 >> >> Severity: important >> >> X-Debbugs-Cc: christophe.troph...@lncmi.cnrs.fr >> >> >> >> Dear Maintainer, >> >> >> >> After upgrading systemd the machine does not reboot. >> >> The error message says: >> >> >> >> systemd freezing execution >> >> refusing to run under cgroup v1, SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 >> >> shall be passed to kernel command line >> >> >> >> >> >> As far as I have understood cgroup v1 is no longer supported. >> >> So I think I have 2 choices: >> >> * add the variable to the kernel starting command line, >> >> * disable cgroup v1 >> >> >> >> The point is that I cannot figure out how to do? >> >> Cannot find how to set the variable, nor how to eventually disable >> >> cgroup v1? >> >> >> >> Which packages may use the cgroup v1 features? >> >> I'm using container tools like docker (nvidia-container), singularity >> > and charliecloud >> >> >> >> Thanks for your help >> >> Best >> >> C >> >> >> >> PS: cannot provide any additional info about my debian trixie host. >> > >> > cgroupsv2 is the default and has been since Bookworm, did you apply >> > some custom kernel command line that disables it? >> > >> > -- >> > Kind regards, > > > Luca Boccassi smime.p7s Description: S/MIME Cryptographic Signature
Bug#1072524: systemd: On a debian trixie, after upgrading systemd to latest version the system fails to reboot.
Package: systemd Version: 256~rc3 Severity: important X-Debbugs-Cc: christophe.troph...@lncmi.cnrs.fr Dear Maintainer, After upgrading systemd the machine does not reboot. The error message says: systemd freezing execution refusing to run under cgroup v1, SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 shall be passed to kernel command line As far as I have understood cgroup v1 is no longer supported. So I think I have 2 choices: * add the variable to the kernel starting command line, * disable cgroup v1 The point is that I cannot figure out how to do? Cannot find how to set the variable, nor how to eventually disable cgroup v1? Which packages may use the cgroup v1 features? I'm using container tools like docker (nvidia-container), singularity and charliecloud Thanks for your help Best C PS: cannot provide any additional info about my debian trixie host.
Bug#1042822: med-fichier: Please upgrade to latest med-fichier version aka 5.0.0
- Original Message - > From: "Gilles Filippini" > To: "Christophe Trophime" , "1042822" > <1042...@bugs.debian.org> > Sent: Thursday, August 31, 2023 7:46:45 PM > Subject: Re: Bug#1042822: med-fichier: Please upgrade to latest med-fichier > version aka 5.0.0 > Christophe Trophime a écrit le 31/08/2023 à 18:57 : >> >> >> ----- Original Message - >>> From: "Gilles Filippini" >>> To: "Christophe Trophime" , >>> 1042...@bugs.debian.org >>> Sent: Thursday, August 31, 2023 6:47:36 PM >>> Subject: Re: Bug#1042822: med-fichier: Please upgrade to latest med-fichier >>> version aka 5.0.0 >> >>> Hi Christophe, >>> >>> Christophe Trophime a écrit le 01/08/2023 à 14:35 : >>>> Source: med-fichier >>>> Version: Please upgrade to 5.0.0 version >>>> Severity: normal >>>> >>>> Dear Maintainer, >>>> >>>> It would be great if med was upgraded to enable use a Salome 9.11 generated >>>> mesh files. >>> >>> Where is it downloadable from? >> >>>From https://www.salome-platform.org/?page_id=2430. >> I take a quick look at the sources. It requires a more recent hdf5 version >> (1.12 >> if I rember correctly). > > This would be unfortunate. I didn't plan to ship HDF5 1.12 because this > release is (or will soon be) retired by the HDF Group: > https://portal.hdfgroup.org/display/support/Downloads Could you check with med-fichier upstream if they support hdf5 1.14 or if it is planned in a near future? > >> I thought that Salome 9.11 was build on top of med 5 but this is not the >> case. >> The upgrade is not urgent.. Maybe we shall contact Salome upstream to now >> when >> they plan to upgrade to med 5 >> before moving on this issue. >> >> Best >> C >> >>> >>> Thx, > >> _g. smime.p7s Description: S/MIME Cryptographic Signature
Bug#1042822: med-fichier: Please upgrade to latest med-fichier version aka 5.0.0
- Original Message - > From: "Gilles Filippini" > To: "Christophe Trophime" , > 1042...@bugs.debian.org > Sent: Thursday, August 31, 2023 6:47:36 PM > Subject: Re: Bug#1042822: med-fichier: Please upgrade to latest med-fichier > version aka 5.0.0 > Hi Christophe, > > Christophe Trophime a écrit le 01/08/2023 à 14:35 : >> Source: med-fichier >> Version: Please upgrade to 5.0.0 version >> Severity: normal >> >> Dear Maintainer, >> >> It would be great if med was upgraded to enable use a Salome 9.11 generated >> mesh files. > > Where is it downloadable from? >From https://www.salome-platform.org/?page_id=2430. I take a quick look at the sources. It requires a more recent hdf5 version (1.12 if I rember correctly). I thought that Salome 9.11 was build on top of med 5 but this is not the case. The upgrade is not urgent.. Maybe we shall contact Salome upstream to now when they plan to upgrade to med 5 before moving on this issue. Best C > > Thx, > _g. smime.p7s Description: S/MIME Cryptographic Signature
Bug#1042822: med-fichier: Please upgrade to latest med-fichier version aka 5.0.0
Source: med-fichier Version: Please upgrade to 5.0.0 version Severity: normal Dear Maintainer, It would be great if med was upgraded to enable use a Salome 9.11 generated mesh files. Best C.
Bug#1008245: update-glx config for nvidia but libegl point to mesa-diverted
- Original Message - > From: "Andreas Beckmann" > To: "Christophe Trophime" > Cc: "1008245" <1008...@bugs.debian.org> > Sent: Friday, March 25, 2022 3:25:48 PM > Subject: Re: Bug#1008245: update-glx config for nvidia but libegl point to > mesa-diverted > On 25/03/2022 12.56, Christophe Trophime wrote: >>> update-glx --display nvidia > > Thanks. > > I'm not sure whether this will yield helpful debug information, but you > could run > > strace --trace=/open eglinfo I attached the output as eglinfo.log > > to get a list of all files opened when running eglinfo. This should at > least show whether nvidia libraries are being tried ... > Indeed it seems that it tried some nvidia libs > > Andreas openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libEGL.so.1", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libGLdispatch.so.0", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/etc/glvnd/egl_vendor.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 openat(AT_FDCWD, "/usr/share/glvnd/egl_vendor.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 openat(AT_FDCWD, "/usr/share/glvnd/egl_vendor.d/10_nvidia.json", O_RDONLY) = 3 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libnvidia-glsi.so.470.103.01", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/etc/egl/egl_external_platform.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/egl/egl_external_platform.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 openat(AT_FDCWD, "/usr/share/egl/egl_external_platform.d/10_nvidia_wayland.json", O_RDONLY) = 3 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libnvidia-egl-wayland.so.1", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libwayland-server.so.0", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libwayland-client.so.0", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libffi.so.8", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libnvidia-eglcore.so.470.103.01", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/home/LNCMI-G/trophime/.nv/nvidia-application-profile-globals-rc", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/home/LNCMI-G/trophime/.nv/nvidia-application-profiles-rc", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/home/LNCMI-G/trophime/.nv/nvidia-application-profiles-rc.d", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/nvidia/nvidia-application-profiles-rc", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/nvidia/nvidia-application-profiles-rc.d/", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/nvidia/nvidia-application-profiles-470.103.01-rc", O_RDONLY) = 3 openat(AT_FDCWD, "/usr/share/nvidia/nvidia-application-profiles-rc", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/proc/self/comm", O_RDONLY) = 3 openat(AT_FDCWD, "/usr/share/glvnd/egl_vendor.d/50_mesa.json", O_RDONLY) = 3 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libgbm.so.1", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libglapi.so.0", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libexpat.so.1", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libX11-xcb.so.1", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libxcb.so.1", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libxcb-xfixes.so.0", O_
Bug#1008245: update-glx config for nvidia but libegl point to mesa-diverted
> On 25/03/2022 09.57, Christophe Trophime wrote: >> Why on earth, glx--libEGL.so.1-x86_64-linux-gnu points to mesa-diverted?? > > MESA and modern NVIDIA drivers (starting after the 418 series) use > libglvnd to provide generic loader libraries libGL.so.1, libEGL.so.1, > ... while MESA and NVIDIA only provide some implementations: > libGLX_${VENDOR}.so.0, libEGL_${VENDOR}.so.0, ... > (NVIDIA still ships GLVND builds of (loader) libGL.so.1 etc., but we use > them from src:libglvnd.) > The name "mesa-diverted" is misleading nowadays since it actually > contains diverted libglvnd libraries ... this won't be fixed, because > once all the NVIDIA drivers predating GLVND usage reach EoL (Tesla 418 > in 03/2022 and legacy 390 in 12/2022), i.e. once there are no longer > NVIDIA-specific libGL.so.1 etc. we can simplify the diversion and > alternatives setup for bookworm, since most things done can now be > solved by libglvnd. > Hi, Andreas thanks for your explanations. This is more clear now. >> Running glxinfo I can confirm that I'm using Nvidia driver (even if >> glx--libGL.so.1-x86_64-linux-gnu points to mesa-diverted). > > As expected. > >> But running eglinfo clearly states that I'm using mesa driver. > > That's the point we need to look into. > > Luca, can you confirm that eglinfo should report something > "NVIDIA-specific" or is that a red herring? > > Christophe, you should have something like these libraries > related to EGL installed: > > ii libegl-mesa0:amd64 21.3.7-1 amd64 > free implementation of the EGL API -- Mesa vendor library > ii libegl-nvidia0:amd64470.103.01-3 amd64 > NVIDIA binary EGL library > ii libegl1:amd64 1.4.0-1 amd64 > Vendor neutral GL dispatch library -- EGL support > ii libnvidia-egl-wayland1:amd641:1.1.9-1.1 amd64 > Wayland EGL External Platform library -- shared library > ii libnvidia-eglcore:amd64 470.103.01-3 amd64 > NVIDIA binary EGL core libraries > ii libwayland-egl1:amd64 1.20.0-1 amd64 > wayland compositor infrastructure - EGL library > ii nvidia-egl-common 470.103.01-3 amd64 > NVIDIA binary EGL driver - common files > ii nvidia-egl-icd:amd64470.103.01-3 amd64 > NVIDIA EGL installable client driver (ICD) > > Please send the configuration of the nvidia alternative, too: > > update-glx --display nvidia > nvidia - auto mode link best version is /usr/lib/nvidia/current link currently points to /usr/lib/nvidia/current link nvidia is /usr/lib/nvidia/nvidia slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0 slave nvidia--libGLESv1_CM_nvidia.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLESv1_CM_nvidia.so.1 slave nvidia--libGLESv2_nvidia.so.2-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLESv2_nvidia.so.2 slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 slave nvidia--libcuda.so-i386-linux-gnu is /usr/lib/i386-linux-gnu/libcuda.so slave nvidia--libcuda.so-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libcuda.so slave nvidia--libcuda.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libcuda.so.1 slave nvidia--libcuda.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libcuda.so.1 slave nvidia--libglxserver_nvidia.so is /usr/lib/nvidia/libglxserver_nvidia.so slave nvidia--libnvcuvid.so-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvcuvid.so slave nvidia--libnvcuvid.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvcuvid.so.1 slave nvidia--libnvidia-cfg.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 slave nvidia--libnvidia-encode.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1 slave nvidia--libnvidia-ml.so-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-ml.so slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1 slave nvidia--libnvidia-ptxjitcompiler.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libnvidia-ptxjitcompiler.so.1 slave nvidia--libnvidia-ptxjitcompiler.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-ptxjitcompiler.so.1 slave nvidia--libvdpau_nvidia.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_nvidia.so.1 slave nvidia--nv-control-dpy is /usr/bin/nv-control-dpy slave nvidia--nvidia-application-profiles-key-documentation is /usr/share/nvidia/nvidia-application-profiles-key-documentation slave nvidia--nvidia-blacklists-nouveau.conf is /etc/nvidia/nvidia-blacklists-nouveau.conf slave
Bug#1008245: update-glx config for nvidia but libegl point to mesa-diverted
Package: update-glx Version: 1.2.1 Severity: normal Dear Maintainer, I've setup my debian Testing to use nvidia driver 470.103.01. The system is setup to use nvidia drive: update-glx --config glx However running update-glx --query glx reports: Name: glx Link: /usr/lib/glx Slaves: glx--libEGL.so.1-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libEGL.so.1 glx--libGL.so.1-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libGL.so.1 glx--libGLESv1_CM.so.1-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1 glx--libGLESv2.so.2-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 glx--libGLX_indirect.so.0-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 glx--libglxserver_nvidia.so /usr/lib/xorg/modules/extensions/libglxserver_nvidia.so glx--libnvidia-cfg.so.1-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libnvidia-cfg.so.1 glx--nvidia-blacklists-nouveau.conf /etc/modprobe.d/nvidia-blacklists-nouveau.conf glx--nvidia-bug-report.sh /usr/bin/nvidia-bug-report.sh glx--nvidia-drm-outputclass.conf /usr/share/X11/xorg.conf.d/nvidia-drm-outputclass.conf glx--nvidia-load.conf /etc/modules-load.d/nvidia.conf glx--nvidia-modprobe.conf /etc/modprobe.d/nvidia.conf glx--nvidia_drv.so /usr/lib/xorg/modules/drivers/nvidia_drv.so Status: auto Best: /usr/lib/nvidia Value: /usr/lib/nvidia Alternative: /usr/lib/mesa-diverted Priority: 5 Slaves: glx--libEGL.so.1-x86_64-linux-gnu /usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1 glx--libGL.so.1-x86_64-linux-gnu /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 glx--libGLESv1_CM.so.1-x86_64-linux-gnu /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1 glx--libGLESv2.so.2-x86_64-linux-gnu /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 glx--libGLX_indirect.so.0-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 Alternative: /usr/lib/nvidia Priority: 100 Slaves: glx--libEGL.so.1-x86_64-linux-gnu /usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1 glx--libGL.so.1-x86_64-linux-gnu /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 glx--libGLESv1_CM.so.1-x86_64-linux-gnu /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1 glx--libGLESv2.so.2-x86_64-linux-gnu /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 glx--libGLX_indirect.so.0-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 glx--libglxserver_nvidia.so /usr/lib/nvidia/libglxserver_nvidia.so glx--libnvidia-cfg.so.1-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 glx--nvidia-blacklists-nouveau.conf /etc/nvidia/nvidia-blacklists-nouveau.conf glx--nvidia-bug-report.sh /usr/lib/nvidia/nvidia-bug-report.sh glx--nvidia-drm-outputclass.conf /etc/nvidia/nvidia-drm-outputclass.conf glx--nvidia-load.conf /etc/nvidia/nvidia-load.conf glx--nvidia-modprobe.conf /etc/nvidia/nvidia-modprobe.conf glx--nvidia_drv.so /usr/lib/nvidia/nvidia_drv.so Why on earth, glx--libEGL.so.1-x86_64-linux-gnu points to mesa-diverted?? Running glxinfo I can confirm that I'm using Nvidia driver (even if glx--libGL.so.1-x86_64-linux-gnu points to mesa-diverted). But running eglinfo clearly states that I'm using mesa driver. I have trouble running singularity container for some paraview app when using --nv for preloading nvidia driver I suspect that my problem is linked with these "wrong" links Can you please confirm or infirm my statements? Best C -- Package-specific info: Diversions: diversion of /usr/lib/aarch64-linux-gnu/libGL.so to /usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1.0.0 to /usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1.0.0 by glx-diversions diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1.7.0 to /usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1.7.0 by glx-diversions diversion of /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so.1.2.0 to /usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv1_CM.so.1.2.0 by glx-diversions diversion of /usr/lib/aarch64-linux-gnu/libGLESv2.so to /usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv2.so by glx-diversions diversion of /usr/lib/aarch64-linux-gnu/libGLESv2.so.2 to
Bug#1007168: paramiko: Paramiko not working with Openssh 8.8p1
Source: paramiko Version: 2.8.1-1 Severity: important Dear Maintainer, Since the upgrade of openssh, paramiko is no working see #1915 issue upstream This problem has been solved with 2.9 paramiko version Could you please upgrade paramiko to at least 2.9 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1003943: netcdf-parallel: wrong path to header in config cmake file
Source: netcdf-parallel Version: 1:4.8.1-2 Severity: normal Dear Maintainer, The config cmake file shipped with this package does not provide a valid directory for netcdf headers. --- netcdf-parallel-4.8.1.orig/netCDFConfig.cmake.in +++ netcdf-parallel-4.8.1/netCDFConfig.cmake.in @@ -6,7 +6,7 @@ set(NetCDFVersion "@PACKAGE_VERSION@") set_and_check(netCDF_INSTALL_PREFIX "@PACKAGE_CMAKE_INSTALL_PREFIX@") -set_and_check(netCDF_INCLUDE_DIR "@PACKAGE_CMAKE_INSTALL_INCLUDEDIR@") +set_and_check(netCDF_INCLUDE_DIR "@PACKAGE_CMAKE_INSTALL_LIBDIR@/netcdf/mpi/include") set_and_check(netCDF_LIB_DIR "@PACKAGE_CMAKE_INSTALL_LIBDIR@") set(netCDF_LIBRARIES netCDF::netcdf) The above patch fixes this issue Best C
Bug#1001694: opencascade: Please upgrade to 7.5.3p1
Source: opencascade Version: 7.5.1+dfsg1-2 Severity: wishlist Dear Maintainer, could you please upgrade to 7.5.3p1? NB: please do not consider using latest release 7.6.0 unless we can install different versions of opencascade side by side. Thanks -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1001464: paraview: enable web support
Package: paraview Version: 5.10.0~rc1-1 Severity: wishlist Dear Maintainer, Could you please enable web support by simply changing DPARAVIEW_ENABLE_WEB to ON in d/rules? I would like to use pywebvue with paraview. Best -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages paraview depends on: ii libavcodec58 7:4.4.1-2+b1 ii libavformat58 7:4.4.1-2+b1 ii libavutil567:4.4.1-2+b1 ii libc6 2.32-5 ii libdouble-conversion3 3.1.5-7 ii libexpat1 2.4.1-3 ii libfreetype6 2.11.0+dfsg-1 ii libgcc-s1 11.2.0-12 ii libgdal29 3.3.3+dfsg-2 ii libgl2ps1.41.4.2+dfsg1-2 ii libglew2.2 2.2.0-4 ii libglx01.3.4-2+b1 ii libhdf5-103-1 1.10.7+repack-4 ii libjpeg62-turbo1:2.1.2-1 ii liblz4-1 1.9.3-2 ii liblzma5 5.2.5-2 ii libnetcdf191:4.8.1-1 ii libopengl0 1.3.4-2+b1 ii libopenmpi34.1.2-1 ii libpdal-base13 2.3.0+ds-2+b1 ii libpng16-161.6.37-3 ii libpython3.9 3.9.9-1 ii libqt5core5a 5.15.2+dfsg-14 ii libqt5gui5 5.15.2+dfsg-14 ii libqt5help55.15.2-5+b1 ii libqt5network5 5.15.2+dfsg-14 ii libqt5widgets5 5.15.2+dfsg-14 ii libstdc++6 11.2.0-12 ii libswscale57:4.4.1-2+b1 ii libtiff5 4.3.0-2 ii libx11-6 2:1.7.2-2+b1 ii libxcursor11:1.2.0-2 ii libxml22.9.12+dfsg-5+b1 ii python3-autobahn 17.10.1+dfsg1-7 ii python3-matplotlib 3.3.4-2 ii python3-mpi4py 3.1.2-2 ii python3-six1.16.0-2 ii python3-twisted20.3.0-7 ii tcl [tclsh]8.6.11+1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages paraview recommends: ii mpi-default-bin 1.14 pn paraview-doc ii python3-paraview [python3-paraview] 5.10.0~rc1-1 Versions of packages paraview suggests: pn h5utils ii hdf5-tools 1.10.7+repack-4 -- no debconf information
Bug#938795: vmtk does not build any more
Hi, maybe rebuilding vtk9 with gdcm support will fix this? By the way, I've noticed that vtk9 is built with gl2ps support whereas paraview is not. Not sure but this may lead to some troubles. Would be great to rebuild paraview with gl2ps also. Best C Christophe TROPHIME Research Engineer CNRS - LNCMI 25, rue des Martyrs BP 166 38042 GRENOBLE Cedex 9 FRANCE Tel : +33 (0)4 76 88 90 02 Fax : +33 (0) 4 76 88 10 01 Office U 19 M@il : christophe.troph...@lncmi.cnrs.fr - Original Message - > From: "Andreas Tille" > To: "Drew Parsons" > Cc: 938...@bugs.debian.org, "debian-science" > , "Johannes Ring" > Sent: Tuesday, December 8, 2020 9:08:12 AM > Subject: Re: vmtk does not build any more > Hi, > > On Tue, Dec 08, 2020 at 04:21:01AM +0800, Drew Parsons wrote: >> First thing to try would be building against vtk9, which Anton recently >> released for us. > > Thanks for the hint but switching to vtk9 leads to cmake errors: > > -- The imported target "vtkgdcmsharpglue" references the file > "/usr/lib/x86_64-linux-gnu/libvtkgdcmsharpglue.so" > but this file does not exist. Possible reasons include: > * The file was deleted, renamed, or moved to another location. > * An install or uninstall procedure did not complete successfully. > * The installation package was faulty and contained > "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake" > but not all the files it references. > > -- The imported target "vtkgdcmJava" references the file > "/usr/lib/x86_64-linux-gnu/jni/libvtkgdcmJava.so" > but this file does not exist. Possible reasons include: > * The file was deleted, renamed, or moved to another location. > * An install or uninstall procedure did not complete successfully. > * The installation package was faulty and contained > "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake" > but not all the files it references. > > -- The imported target "vtkgdcmPython" references the file > "/usr/lib/python/dist-packages/vtkgdcmPython.so" > but this file does not exist. Possible reasons include: > * The file was deleted, renamed, or moved to another location. > * An install or uninstall procedure did not complete successfully. > * The installation package was faulty and contained > "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake" > but not all the files it references. > > -- The imported target "vtkgdcmPythonD" references the file > "/usr/lib/x86_64-linux-gnu/libvtkgdcmPythonD.so.3.0.7" > but this file does not exist. Possible reasons include: > * The file was deleted, renamed, or moved to another location. > * An install or uninstall procedure did not complete successfully. > * The installation package was faulty and contained > "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake" > but not all the files it references. > ... > > > This does not happen with vtk7. But may be it needs ITK5? > > Kind regards > > Andreas. > > -- > http://fam-tille.de
Bug#944030: jinja2-time: FTBFS in unstable
Hi, The patch from arch maintainer fixes the issue See: https://raw.githubusercontent.com/archlinux/svntogit-community/packages/python-jinja-time/trunk/python-jinja-time-0.2.0-arrow_shift.patch Best. On Sat, 2 Nov 2019 18:11:35 -0700 Steve Langasek < steve.langa...@canonical.com> wrote: > Source: jinja2-time > Version: 0.2.0-2 > Severity: serious > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu focal > > Hi Vincent, > > The jinja2-time source package currently fails to build from source in > unstable: > > [...] > tests/test_now.py ..FFF [100%] > > === FAILURES === > test_add_time _ > > environment = > > def test_add_time(environment): > environment.datetime_format = '%a, %d %b %Y %H:%M:%S' > > template = environment.from_string( > "{% now 'utc' + 'hours=2,seconds=30' %}" > ) > > > assert template.render() == "Thu, 10 Dec 2015 01:33:31" > > tests/test_now.py:61: > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > /usr/lib/python3/dist-packages/jinja2/asyncsupport.py:76: in render > return original_render(self, *args, **kwargs) > /usr/lib/python3/dist-packages/jinja2/environment.py:1008: in render > return self.environment.handle_exception(exc_info, True) > /usr/lib/python3/dist-packages/jinja2/environment.py:780: in handle_exception > reraise(exc_type, exc_value, tb) > /usr/lib/python3/dist-packages/jinja2/_compat.py:37: in reraise > raise value.with_traceback(tb) > :1: in top-level template code > ??? > jinja2_time/jinja2_time.py:26: in _datetime > d = d.replace(**replace_params) > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > self = > kwargs = {'hours': 2.0, 'seconds': 30.0}, absolute_kwargs = {}, key = 'hours' > value = 2.0 > > def replace(self, **kwargs): > """ Returns a new :class:`Arrow ` object with attributes updated > according to inputs. > > Use property names to set their value absolutely:: > > >>> import arrow > >>> arw = arrow.utcnow() > >>> arw > > >>> arw.replace(year=2014, month=6) >
Bug#958329: charliecloud: user+mount is not supported
This bug may be merged with #9538327 Sorry for the duplicate.
Bug#958329: charliecloud: user+mount is not supported
Package: charliecloud Version: 0.9.10-1 Severity: normal Dear Maintainer, Trying to run a test example with some mount directory (ie ch-run -h SRC:DST -w ./feelpp-v0.108-focal/ -- pwd) I end up with error like: ch-run[190638]: error (charliecloud.c:553) It makes charliecloud unusable Best C. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages charliecloud depends on: ii debconf [debconf-2.0] 1.5.73 ii libc6 2.30-4 charliecloud recommends no packages. Versions of packages charliecloud suggests: pn charliecloud-doc pn docker.io pn pv -- debconf information: * charliecloud/unpriv_userns_warning:
Bug#958327: charliecloud: cannot use ch-run
Package: charliecloud Version: 0.9.10-1 Severity: normal Dear Maintainer, Trying to run a test example with some mount directory (ie ch-run -h SRC:DST -w ./feelpp-v0.108-focal/ -- pwd) I end up with error like: ch-run[190638]: error (charliecloud.c:553) Same behaviour without -h nor -w options It makes charliecloud unusable Best C. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages charliecloud depends on: ii debconf [debconf-2.0] 1.5.73 ii libc6 2.30-4 charliecloud recommends no packages. Versions of packages charliecloud suggests: pn charliecloud-doc pn docker.io pn pv -- debconf information: * charliecloud/unpriv_userns_warning: Christophe TROPHIME Research Engineer CNRS - LNCMI 25, rue des Martyrs BP 166 38042 GRENOBLE Cedex 9 FRANCE Tel : +33 (0)4 76 88 90 02 Fax : +33 (0) 4 76 88 10 01 Office U 19 M@il : christophe.troph...@lncmi.cnrs.fr
Bug#947569: FTBFS with scons 3.1.2-1
Please find attached a patch for the issue. On Sat, 28 Dec 2019 09:03:44 +0100 =?ISO-8859-1?Q?J=F6rg_Frings-F=FCrst?= wrote: > Source: mongo-cxx-driver-legacy > Version: 1.1.3-3 > Severity: important > Usertags: scons_ftbfs > > > Hello, > > in the context of the change to Python3 also Scons was revised. With > the current version 3.1.2-1 from Experimental the changeover is > finished so far. > > However, an error occurred while building your package. The build log > is attached. > > Please check it and fix the error. > > CU > Jörg > > -- > New: > GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D > GPG key (long) : 09F89F3C8CA1D25D > GPG Key: 8CA1D25D > CAcert Key S/N : 0E:D4:56 > > Old pgp Key: BE581B6E (revoked since 2014-12-31). > > Jörg Frings-Fürst > D-54470 Lieser > > > git: https://jff.email/cgit/ > > Threema: SYR8SJXB > Wire: @joergfringsfuerst > Skype:joergpenguin > Ring: jff > Telegram: @joergfringsfuerst > > > My wish list: > - Please send me a picture from the nature at your home. > Description: TODO: Put a short summary on the line above and replace this paragraph with a longer explanation of this change. Complete the meta-information with other relevant fields (see below for details). To make it easier, the information below has been extracted from the changelog. Adjust it or drop it. . mongo-cxx-driver-legacy (1.1.3-3.1) unstable; urgency=medium . * Non-maintainer upload. * Fix FTBS with python3 (Closes: #947569) Author: Christophe Trophime Bug-Debian: https://bugs.debian.org/947569 --- The information above should follow the Patch Tagging Guidelines, please checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here are templates for supplementary fields that you might want to add: Origin: , Bug: Bug-Debian: https://bugs.debian.org/ Bug-Ubuntu: https://launchpad.net/bugs/ Forwarded: Reviewed-By: Last-Update: 2020-03-04 --- mongo-cxx-driver-legacy-1.1.3.orig/SConstruct +++ mongo-cxx-driver-legacy-1.1.3/SConstruct @@ -13,7 +13,7 @@ import sys import textwrap import types import urllib -import urllib2 +#import urllib2 import buildscripts.utils import buildscripts.docs @@ -389,7 +389,7 @@ SConsignFile(str(sconsDataDir.File('scon def printLocalInfo(): import sys, SCons print( "scons version: " + SCons.__version__ ) -print( "python version: " + " ".join( [ `i` for i in sys.version_info ] ) ) +print( "python version: " + " ".join( [ str(i) for i in sys.version_info ] ) ) printLocalInfo() @@ -931,7 +931,7 @@ if debugBuild: env.Append( CPPDEFINES=["MONGO_DEBUG_BUILD"] ); try: -umask = os.umask(022) +umask = os.umask(0o22) except OSError: pass @@ -1125,7 +1125,7 @@ def doConfigure(myenv): # to make them real errors. cloned.Append(CCFLAGS=['-Werror']) conf = Configure(cloned, help=False, custom_tests = { -'CheckFlag' : lambda(ctx) : CheckFlagTest(ctx, tool, extension, flag) +'CheckFlag' : lambda ctx : CheckFlagTest(ctx, tool, extension, flag) }) available = conf.CheckFlag() conf.Finish() --- mongo-cxx-driver-legacy-1.1.3.orig/site_scons/buildscripts/clang_format.py +++ mongo-cxx-driver-legacy-1.1.3/site_scons/buildscripts/clang_format.py @@ -9,7 +9,7 @@ A script that provides: """ from __future__ import print_function, absolute_import -import Queue +import queue import difflib import itertools import os --- mongo-cxx-driver-legacy-1.1.3.orig/site_scons/buildscripts/lint.py +++ mongo-cxx-driver-legacy-1.1.3/site_scons/buildscripts/lint.py @@ -2,8 +2,8 @@ import sys import codecs -import cpplint -import utils +import buildscripts.cpplint +import buildscripts.utils def run_lint( paths, nudgeOn=False ): --- mongo-cxx-driver-legacy-1.1.3.orig/src/SConscript.client +++ mongo-cxx-driver-legacy-1.1.3/src/SConscript.client @@ -3,7 +3,7 @@ # This SConscript describes build and install rules for the Mongo C++ driver and associated exmaple # programs. import buildscripts.git -import httplib +import http.client import json import os import re @@ -415,7 +415,7 @@ if buildShared: mongoClientPrefixInstalls.append(mongoClientSharedLibPrefixInstall) inst = libEnv.InstallAs(['$INSTALL_DIR/include/' + x for x in clientHeaders], clientHeaders) -libEnv.AddPostAction(inst, Chmod('$TARGET', 0644)) +libEnv.AddPostAction(inst, Chmod('$TARGET', 0o644)) mongoClientPrefixInstalls.append(inst); --- mongo-cxx-driver-legacy-1.1.3.orig/src/mongo/base/generate_error_codes.py +++ mongo-cxx-driver-legacy-1.1.3/src/mongo/base/generate_error_codes.py @@ -112,12 +112,14 @@ def has_missing_error_codes(error_codes, def generate_header(filename, error_codes, error_classes):
Bug#948773: [gmsh] provide a package for private headers
Package: gmsh Version: 4.4.1+ds1-2.2 Severity: normal Could you please add a package for private headers that may be needed for some apps (like Salome)? The private headers can be simply installed using the cmake option: -DENABLE_PRIVATE_API:BOOL=ON Note that this package could be optionally installed just like netgen-headers. Best C.
Bug#948772: [med-fichier] provide mpi and serial package
Package: med-fichier Version: 4.4.1+ds1-2 Severity: normal As latest gmsh package is compiled without mpi support med format is no longer supported in gmsh. It's a kind of regression somehow. It would be great to provide packages for both mpi and serial version of med-fichier just like what is done for hdf5. Best C
Bug#946815: [debootstrap] Add script for future focal fossal Ubuntu
Package: debootstrap Version: 1.0.116 Severity: normal Hi, could you please add scripts for future Ubuntu LTS namely focal fossil? Best Regards C --- System information. --- Architecture: Kernel: Linux 5.3.0-2-amd64 Debian Release: bullseye/sid 500 testing ftp.fr.debian.org --- Package information. --- Depends (Version) | Installed ==-+-=== wget | 1.20.3-1+b2 Recommends (Version) | Installed =-+-=== gnupg | 2.2.17-3 debian-archive-keyring| 2019.1 arch-test (>= 0.11~) | 0.16-2 Suggests(Version) | Installed =-+-=== ubuntu-archive-keyring| 2018.09.18.1-5 squid-deb-proxy-client|
Bug#946680: [hdf5] FTBS with openmpi 4.0.2-4+b1
Package: hdf5 Version: 1.10.4+repack Severity: normal --- System information. --- Architecture: Kernel: Linux 5.3.0-2-amd64 Debian Release: bullseye/sid 500 testing ftp.fr.debian.org When compiling with openmpi 4: .../../../src/H5Smpio.c:1503:9: error: call to 'MPI_Type_extent' declared with attribute error: MPI_Type_extent was removed in MPI-3.0. Use MPI_Type_get_extent instead. 1503 | MPI_Type_extent (old_type, _extent); | ^~~ ../../../src/H5Smpio.c: In function 'H5S_mpio_hyper_type': ../../../src/H5Smpio.c:882:13: error: call to 'MPI_Type_extent' declared with attribute error: MPI_Type_extent was removed in MPI-3.0. Use MPI_Type_get_extent instead. 882 | MPI_Type_extent (inner_type, _extent); | ^~~ make[2]: *** [Makefile:1603: H5Smpio.lo] Error 1 make[2]: Leaving directory '/build/hdf5-1.10.4+repack/debian/build-openmpi/src' make[1]: *** [Makefile:1160: all] Error 2 make[1]: Leaving directory '/build/hdf5-1.10.4+repack/debian/build-openmpi/src' Best c
Bug#945338: libpetsc3.11-dev-examples: postinst uses /usr/share/doc content (Policy 12.3): /usr/share/doc/libpetsc3.11-dev-examples/examples/**/*.py
On Sat, 23 Nov 2019 04:18:43 +0100 Andreas Beckmann wrote: > Package: libpetsc3.11-dev-examples > Version: 3.11.4+dfsg1-3 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > a test with piuparts revealed that your package uses files from > /usr/share/doc in its maintainer scripts which is a violation of > Policy 12.3: "Packages must not require the existence of any files in > /usr/share/doc/ in order to function." > https://www.debian.org/doc/debian-policy/ch-docs.html#additional-documentation > > These files must be moved to /usr/share/$PACKAGE and may be symlinked > from /usr/share/doc/$PACKAGE. > > This piuparts test prevents the installation of (most) files into > /usr/share/doc with 'dpkg --path-exclude=...'. > > From the attached log (scroll to the bottom...): > > Setting up python3 (3.7.5-1) ... > [Errno 2] No such file or directory: '/usr/share/doc/libpetsc3.11-dev-examples/examples/config/cmakegen.py' > [Errno 2] No such file or directory: '/usr/share/doc/libpetsc3.11-dev-examples/examples/config/example_template.py' > [Errno 2] No such file or directory: '/usr/share/doc/libpetsc3.11-dev-examples/examples/config/gmakegen.py' > [Errno 2] No such file or directory: '/usr/share/doc/libpetsc3.11-dev-examples/examples/config/gmakegentest.py' > [Errno 2] No such file or directory: '/usr/share/doc/libpetsc3.11-dev-examples/examples/config/report_tests.py' > [Errno 2] No such file or directory: '/usr/share/doc/libpetsc3.11-dev-examples/examples/config/testparse.py' > [Errno 2] No such file or directory: '/usr/share/doc/libpetsc3.11-dev-examples/examples/src/ksp/ksp/examples/tutorials/ex100.py' > [Errno 2] No such file or directory: '/usr/share/doc/libpetsc3.11-dev-examples/examples/src/ksp/ksp/examples/tutorials/example100.py' > [Errno 2] No such file or directory: '/usr/share/doc/libpetsc3.11-dev-examples/examples/src/ts/examples/tutorials/ex8.py' > [Errno 2] No such file or directory: '/usr/share/doc/libpetsc3.11-dev-examples/examples/src/ts/examples/tutorials/extchem.py' > error running python rtupdate hook libpetsc3.11-dev-examples > dpkg: error processing package python3 (--configure): >installed python3 package post-installation script subprocess returned error exit status 4 > dpkg: dependency problems prevent configuration of libpetsc3.11-dev-examples: >libpetsc3.11-dev-examples depends on python3:any; however: > Package python3 is not configured yet. > > dpkg: error processing package libpetsc3.11-dev-examples (--configure): >dependency problems - leaving unconfigured > Processing triggers for libc-bin (2.29-3) ... > Errors were encountered while processing: >python3 >libpetsc3.11-dev-examples > With this fix, there is no more issue with piuparts. I have checked that the package pestc 3.11 can be installed on Ubuntu Eoan without problem Hope it helps Best C --- petsc-3.11.4+dfsg1/debian/rules 2019-11-11 18:52:48.0 +0100 +++ my-petsc-3.11.4+dfsg1/debian/rules 2019-12-06 10:27:40.251657187 +0100 @@ -292,17 +365,22 @@ override_dh_install: dh_install -p$(PETSC_REAL_PACKAGE) --sourcedir $(PACKAGE_REAL_INSTALL_DIR) $(PETSC_REAL_DIR_PREFIX)/lib/libpetsc_real.so.$(PETSC_VERSION) usr/lib/$(DEB_HOST_MULTIARCH) dh_install -p$(PETSC_REAL_DEV_PACKAGE) --sourcedir $(PACKAGE_REAL_INSTALL_DIR) --autodest --exclude=*html --exclude=conf/uninstall.py --exclude=libpetsc_real.so.$(PETSC_VERSION) --exclude=share/ --exclude=include/petsc/ --exclude=lib/petsc/bin/ usr - + dh_install -p$(PETSC_REAL_DEBUG_PACKAGE) --sourcedir $(PACKAGE_REAL_DEBUG_INSTALL_DIR) --autodest --exclude=*html --exclude=conf/uninstall.py --exclude=share/ --exclude=include/petsc/ --exclude=lib/petsc/bin/ usr - + dh_install -p$(PETSC_COMPLEX_PACKAGE) --sourcedir $(PACKAGE_COMPLEX_INSTALL_DIR) $(PETSC_COMPLEX_DIR_PREFIX)/lib/libpetsc_complex.so.$(PETSC_VERSION) usr/lib/$(DEB_HOST_MULTIARCH) dh_install -p$(PETSC_COMPLEX_DEV_PACKAGE) --sourcedir $(PACKAGE_COMPLEX_INSTALL_DIR) --autodest --exclude=*html --exclude=conf/uninstall.py --exclude=libpetsc_complex.so.$(PETSC_VERSION) --exclude=share/ --exclude=include/petsc/ --exclude=lib/petsc/bin/ usr - + dh_install -p$(PETSC_COMPLEX_DEBUG_PACKAGE) --sourcedir $(PACKAGE_COMPLEX_DEBUG_INSTALL_DIR) --autodest --exclude=*html --exclude=conf/uninstall.py --exclude=share/ --exclude=include/petsc/ --exclude=lib/petsc/bin/ usr - + dh_install -p$(PETSC_DEV_COMMON_PACKAGE) --sourcedir $(PACKAGE_REAL_DEBUG_INSTALL_DIR)/$(PETSC_REAL_DIR_DEBUG_PREFIX) --exclude=share/petsc/examples/ --exclude=share/petsc/datafiles/ share usr/share/petsc/$(PETSC_SONAME_VERSION) dh_install -p$(PETSC_DEV_COMMON_PACKAGE) --sourcedir $(PACKAGE_REAL_DEBUG_INSTALL_DIR)/$(PETSC_REAL_DIR_DEBUG_PREFIX) --exclude=*html include/petsc usr/share/petsc/$(PETSC_SONAME_VERSION)/include dh_install -p$(PETSC_DEV_COMMON_PACKAGE) --sourcedir $(PACKAGE_REAL_DEBUG_INSTALL_DIR)/$(PETSC_REAL_DIR_DEBUG_PREFIX)
Bug#939326: [gmsh] Could you please restore MED support?
Package: gmsh Version: 4.4.1+ds1-2 Severity: normal MED support has been disabled in latest build. This is very annoying. Could we consider restore it? I understand that it implies to rebuild with MPI support since MED is compiled with MPI support. Best C
Bug#925977: [opencascade] update to 7.3.0p3 version
Package: opencascade Version: 7.3.0+dfsg1-5 Severity: normal Could you please update opencascade using the latest branch from opencascade git repository that provides patches for Salome. I mean mostly 7.3.0p2 and 7.3.0p3 Including patches seperatly from the 2 branches would be great. Best C. PS:I've tried to do it without much success There's a lot of warning/error from dpkg-source when I've tried BTW do you how to use debian/source/options # ignore changes on .png .bmp extend-diff-ignore = "(^|/)(.png|.bmp)$" --- System information. --- Architecture: Kernel: Linux 4.19.0-2-amd64 Debian Release: buster/sid 500 testing ftp.fr.debian.org 500 testing euler 500 stretch build.openmodelica.org 500 dataneurodebian.g-node.org 500 buster neurodebian.g-node.org 500 buster download.docker.com 500 any packagecloud.io --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty.
Bug#906324: [scalapack] some tests hang forever when rebuilding against openmpi 3.1
Package: scalapack Version: 2.0.2-7 Severity: important Trying to rebuild scalapack against latest openmpi on buster I had some tests that seems to be hanging forever: ... make[2]: Entering directory '/build/scalapack-2.0.2/build-openmpi' Running tests... /usr/bin/ctest --force-new-ctest-process -j8 Test project /build/scalapack-2.0.2/build-openmpi Start 1: xCbtest Start 2: xFbtest Start 3: spb1tst Start 4: dpb1tst Start 5: cpb1tst Start 6: zpb1tst Start 7: spb2tst Start 8: dpb2tst to reproduce just: DIST=buster pdebuild --- System information. --- Architecture: Kernel: Linux 4.17.0-1-amd64 Debian Release: buster 500 testing ftp.fr.debian.org Christophe TROPHIME Research Engineer CNRS - LNCMI 25, rue des Martyrs BP 166 38042 GRENOBLE Cedex 9 FRANCE Tel : +33 (0)4 76 88 90 02 Fax : +33 (0) 4 76 88 10 01 Office U 19 M@il : christophe.troph...@lncmi.cnrs.fr
Bug#895265: [spherepack] missing headers for C interface
Package: spherepack Version: 3.2-10 Severity: normal Hi, Some headers are required for the C interface to be functional. Something like the one attached that may be shipped in usr/include/spherepack directory. Could you provide such files? Thanks --- System information. --- Architecture: Kernel: Linux 4.15.0-2-amd64 Debian Release: buster/sid 500 testing [ https://mail.lncmi.cnrs.fr/ftp.fr.debian.org | ftp.fr.debian.org ] 500 testing euler 500 stretch download.docker.com 500 data neurodebian.g-node.org 500 buster neurodebian.g-node.org Christophe TROPHIME Research Engineer CNRS - LNCMI 25, rue des Martyrs BP 166 38042 GRENOBLE Cedex 9 FRANCE Tel : +33 (0)4 76 88 90 02 Fax : +33 (0) 4 76 88 10 01 M@il : christophe.troph...@lncmi.cnrs.fr #ifndef __SPHPK_H__ #define __SPHPK_H__ #include #ifdef __cplusplus extern "C" { #endif // shpg.f void FORTRAN_NAME(gaqd)(const int * nlat,double * dtheta,double * dwts,double * DWORK,int * ldwork,int * ier); void FORTRAN_NAME(shagci)(const int * nlat,const int * nlon,float * wshagc,int * lwsha,double * work,int * lwrk,int * ierror); void FORTRAN_NAME(shagc)(const int * nlat,const int * nlon,const int * mode,const int * nt, const float * g,int *idimg,int *jdimg,float * ga,float * gb,int * mdab,int * ndab, float * wshagc,int * lwsha,float * wrk2,int * lwork,int * ierror); void FORTRAN_NAME(shsgci)(const int * nlat,const int * nlon,float * wshsgc,int * lwshs,double * work, int * lwrk,int * ierror); void FORTRAN_NAME(shsgc)(const int * nlat,const int * nlon,const int * mode,const int * nt, float * gh, int * idimg,int * jdimg,const float * ga,const float * gb,int * mdab,int * ndab, float * wshsgc,int * lwshs,float * wrk2,int * lwork,int * ierror); void FORTRAN_NAME(shpgi)(const int * nlat,const int * nlon,const int * isym,int * mtrunc,float * wshp,int * lwshp,int * iwshp,int * liwshp,float * work,int * lwrkint, int *ierror); void FORTRAN_NAME(shpg)(const int * nlat,const int * nlon,const int * isym,int * mtrunc,float * sx,float * sy,int * idp, float * wshp,int * lwshp,int * iwshp,int * liwshp,float * wrk1,int * lwrk1,int * ierror); #ifdef __cplusplus } #endif /* __cplusplus */ #endif /* __SPHPK_H__ */ /* Fortran <--> C/C++ interfacing stuff */ /* $Id: fortran.h,v 1.8 2001/06/09 10:04:54 jthorn Exp $ */ /* this header file is idempotent */ #ifndef FORTRAN_H_SEEN #define FORTRAN_H_SEEN /*/ /* * C/C++ compatability: */ /* * Use this in prototypes like this: extern FORTRAN_FUNCTION void foo(...) * * At present, this is set up to tell a C++ compiler that foo() uses * a C-compatible calling convention. */ #ifdef __cplusplus #define FORTRAN_FUNCTION "C" #else #define FORTRAN_FUNCTION /* empty */ #endif /*/ /* array subscripting offset, i.e. C "arr[k]" is Fortran "arr(k+?)" */ #define FORTRAN_INDEX_ORIGIN 1 /*/ /* C type of Fortran integer/logical variables */ /* also actual integers used for Fortran logical .true. and .false. */ /* * FIXME: these are what I (JT) used on a 32-bit SGI system with the * SGI C and Fortran compilers in 1992-1993; they should be * checked to see if they're still valid for current compilers * and/or for 64-bit systems. */ #if defined(sgi) || defined(SGI) || defined(__sgi__) || defined(__SGI__) #define FORTRAN_INTEGER_IS_INT TRUE typedef int integer; typedef unsigned int logical; #define FORTRAN_LOGICAL_TRUE 1 #define FORTRAN_LOGICAL_FALSE 0 /* see FIXME above for validity of these */ #elif defined(alpha) || defined(ALPHA) || defined(__alpha__) || defined(__ALPHA__) #define FORTRAN_INTEGER_IS_INT TRUE typedef int integer; typedef unsigned int logical; #define FORTRAN_LOGICAL_TRUE 1 #define FORTRAN_LOGICAL_FALSE 0 #elif defined(sun) || defined(SUN) || defined(__sun__) || defined(__SUN__) #define FORTRAN_INTEGER_IS_INT TRUE typedef int integer; typedef unsigned int logical; #define FORTRAN_LOGICAL_TRUE 1 #define FORTRAN_LOGICAL_FALSE 0 #elif defined(cygwin) || defined(CYGWIN) || defined(__cygwin__) || defined(__CYGWIN__) #define FORTRAN_INTEGER_IS_INT TRUE typedef int integer; typedef unsigned int logical; #define FORTRAN_LOGICAL_TRUE 1 #define FORTRAN_LOGICAL_FALSE 0 #elif defined(mingw) || defined(MINGW) || defined(__mingw__) || defined(__MINGW__) #define FORTRAN_INTEGER_IS_INT TRUE typedef int integer; typedef unsigned int logical; #define FORTRAN_LOGICAL_TRUE 1 #define FORTRAN_LOGICAL_FALSE 0 #elif defined(__linux__) && (defined(__i386__) || defined(__x86_64__) ) && defined(__GNUC__) #defin
Bug#858625: [guacamole-server] please add guacctl in guadc package
Package: guacamole-server Version: 0.9.9-2 Severity: normal Hi, it would be great if you could add guacctl bin into guacd package. guacctl is very usefull :) Adding this line into guacd.install : ./bin/guacctl /usr/bin Best C --- System information. --- Architecture: Kernel: Linux 4.9.0-2-amd64 Debian Release: 9.0 500 testing ftp.fr.debian.org 500 testing euler 500 stretch neurodebian.g-node.org 500 data neurodebian.g-node.org --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty. Christophe TROPHIME Research Engineer CNRS - LNCMI 25, rue des Martyrs BP 166 38042 GRENOBLE Cedex 9 FRANCE Tel : +33 (0)4 76 88 90 02 Fax : +33 (0) 4 76 88 10 01 Office U 19 M@il : christophe.troph...@lncmi.cnrs.fr
Bug#837692: [gnupg1] fails to install with gnupg 1.4.20-6
Package: gnupg1 Version: 1.4.21-1 Severity: normal --- Please enter the report below this line. --- To use singularity container, I need to install gnupg, gnupg2 and gnupg1. When trying to install gnupg1 on testing I had the following conflict: sudo apt-get --dry-run install gnupg1 gnupg gnupg2 [sudo] password for xxx: Reading package lists... Done Building dependency tree Reading state information... Done gnupg is already the newest version (1.4.20-6). gnupg2 is already the newest version (2.1.11-7). gnupg2 set to manually installed. Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: gnupg1 : Breaks: gnupg (< 1.4.20-6+exp1) Breaks: gnupg:i386 (< 1.4.20-6+exp1) E: Unable to correct problems, you have held broken packages. --- System information. --- Architecture: amd64 Kernel: Linux 4.6.0-1-amd64 Debian Release: stretch/sid 901 testing euler 900 testing ftp.fr.debian.org 500 stretch neurodebian.g-node.org 500 data neurodebian.g-node.org 1 testing www.deb-multimedia.org --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty.
Bug#837557: [gcc-5] FTBS when trying to rebuild on stretch
Package: gcc-5 Version: 5.4.1-2 Severity: normal --- Please enter the report below this line. --- Trying to backport gcc-5 package on stretch fails: make[5]: Leaving directory '/build/gcc-5-5.4.1/build/x86_64-linux-gnu/libjava' make[4]: Leaving directory '/build/gcc-5-5.4.1/build/x86_64-linux-gnu/libjava' make[3]: Leaving directory '/build/gcc-5-5.4.1/build' make[2]: Leaving directory '/build/gcc-5-5.4.1/build' for i in debug go pkgconfig '*.so' '*.so.*' '*.a' '*.la' '*.o' '*.py' '*.spec'; do \ mv debian/tmp/usr/lib/$i \ debian/tmp/usr/lib/x86_64-linux-gnu/. || true; \ done mv: cannot stat 'debian/tmp/usr/lib/pkgconfig': No such file or directory mv: cannot stat 'debian/tmp/usr/lib/*.py': No such file or directory : # FIXME: the libstdc++ gdb.py file is installed with a wrong name for i in $(find debian/tmp/usr -name libstdc++_pic.a-gdb.py); do \ [ -f $i ] || continue; \ d=$(dirname $i); \ b=$(basename $i); \ t=$(cd $d; echo libstdc++.so.*.*.*)-gdb.py; \ mv $i $d/$t; \ done It seems that path for pkgconfig and *.py are wrong. find debian -name pkgconfig debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig find debian -name \*.py debian/tmp/usr/lib32/libstdc++.so.6.0.21-gdb.py debian/tmp/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21-gdb.py debian/tmp/usr/libx32/libstdc++.so.6.0.21-gdb.py Note that the same problem also appears when trying to backport gcc-6 6.2 on testing Best C --- System information. --- Architecture: amd64 Kernel: Linux 4.6.0-1-amd64 Debian Release: stretch/sid 901 testing euler 900 testing ftp.fr.debian.org 500 stretch neurodebian.g-node.org 500 data neurodebian.g-node.org 1 testing www.deb-multimedia.org --- Package information. --- Depends (Version) | Installed ==-+-== cpp-5 (= 5.4.1-1) | 5.4.1-1 gcc-5-base (= 5.4.1-1) | libcc1-0 (>= 5.4.1-1) | binutils (>= 2.26.1) | libgcc-5-dev (= 5.4.1-1) | libc6 (>= 2.14) | libgcc1 (>= 1:3.0) | libgmp10 (>= 2:5.0.1~) | libisl15 (>= 0.15) | libmpc3 | libmpfr4 (>= 3.1.3) | libstdc++6 (>= 4.1.1) | zlib1g (>= 1:1.1.4) | Recommends (Version) | Installed ==-+- libc6-dev (>= 2.13-5) | 2.23-5 Suggests (Version) | Installed ===-+-=== gcc-5-multilib | 5.4.1-1 gcc-5-doc (>= 5.4.0-6) | gcc-5-locales (>= 5.4.0-6) | 5.4.1-1 libgcc1-dbg (>= 1:5.4.1-1) | 1:6.1.1-11 libgomp1-dbg (>= 5.4.1-1) | 6.1.1-11 libitm1-dbg (>= 5.4.1-1) | 6.1.1-11 libatomic1-dbg (>= 5.4.1-1) | 6.1.1-11 libasan2-dbg (>= 5.4.1-1) | 5.4.1-1 liblsan0-dbg (>= 5.4.1-1) | 6.1.1-11 libtsan0-dbg (>= 5.4.1-1) | 6.1.1-11 libubsan0-dbg (>= 5.4.1-1) | 6.1.1-11 libcilkrts5-dbg (>= 5.4.1-1) | 6.1.1-11 libmpx0-dbg (>= 5.4.1-1) | 5.4.1-1 libquadmath0-dbg (>= 5.4.1-1) | 6.1.1-11
Bug#798003: freeimage: please change FreeImage.h encoding
Christophe TROPHIME Research Engineer CNRS - LNCMI 25, rue des Martyrs BP 166 38042 GRENOBLE Cedex 9 FRANCE Tel : +33 (0)4 76 88 90 02 Fax : +33 (0) 4 76 88 10 01 Office U 19 M@il : christophe.troph...@lncmi.cnrs.fr - Original Message - > From: "Ghislain Vaillant" <ghisv...@gmail.com> > To: 798...@bugs.debian.org > Sent: Sunday, November 22, 2015 3:07:42 PM > Subject: Bug#798003: freeimage: please change FreeImage.h encoding > > Hi Christophe, > > > could you please change the encoding on installed FreeImage.h header? > > The actual encoding is no longer ASCII since you introduced a second > > author "hervé". > > This change may cause some packages to FTBS. > > You meant *upstream* introduced a second author, not us? > > I saw that Fedora is solving the inconsistent encoding by converting all > source files to UTF-8 [1]. Would that solve your problem? > > [1] https://apps.fedoraproject.org/packages/freeimage/ > > > Trying to install salome from source FTBS because of this change. > > The installer tries to recover FreeImage version by using grep > > VERSION in FreeImage.h > > > The non ASCII encoding somehow breaks this as the grep command no > > longer returns the lines including "VERSION". Instead the grep > > command return a message "Binary matches". > > > Changing "hervé" to herve fix the problem. > > Sounds that the version parsing of `salome` is a bit fragile too. In fact it's just made with a simple grep > > Ghis > > -- > debian-science-maintainers mailing list > debian-science-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#803392: boost1.55: still FTBS with g++ 5 on sid and testing
Source: boost1.55 Version: 1.55.0+dfsg-4 Severity: important Dear Maintainer, I've tried to backport latest boost1.55 to stretch (using pdebuild). I ran into some compiling errors: "g++" -ftemplate-depth-300 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-local-typedefs -O3 -finline-functions -Wno- inline -Wall -g -D_FORTIFY_SOURCE=2 -g0 -DBOOST_ALL_NO_LIB=1 -DBOOST_DETAIL_CONTAINER_FWD -DBOOST_FILESYSTEM_NO_DEPRECATED -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"../.." -c -o "../../bin.v2/tools/quickbook/src/gcc-5.2.1/release/debug- symbols-on/link-static/files.o" "src/files.cpp" In file included from ../../boost/functional/hash/hash.hpp:540:0, from ../../boost/functional/hash.hpp:6, from ../../boost/unordered/unordered_map.hpp:20, from ../../boost/unordered_map.hpp:16, from src/files.cpp:12: ../../boost/functional/hash/extensions.hpp:54:33: error: 'template std::size_t boost::hash_value' conflicts with a previous declaration std::size_t hash_value(std::listconst& v); ^ ../../boost/functional/hash/extensions.hpp:52:17: note: previous declaration 'namespace boost { }::hash_value' std::size_t hash_value(std::vector const&); ^ ../../boost/functional/hash/extensions.hpp:54:28: error: reference to 'list' is ambiguous std::size_t hash_value(std::list const& v); ^ In file included from ../../boost/functional/hash/extensions.hpp:17:0, from ../../boost/functional/hash/hash.hpp:540, from ../../boost/functional/hash.hpp:6, from ../../boost/unordered/unordered_map.hpp:20, from ../../boost/unordered_map.hpp:16, from src/files.cpp:12: ../../boost/detail/container_fwd.hpp:139:47: note: candidates are: template class std::list template class list; ^ In file included from /usr/include/c++/5/list:63:0, from ../../boost/filesystem/path_traits.hpp:27, from ../../boost/filesystem/path.hpp:25, from src/files.hpp:15, from src/files.cpp:10: /usr/include/c++/5/bits/stl_list.h:507:11: note: template class std::__cxx11::list class list : protected _List_base<_Tp, _Alloc> ^ In file included from ../../boost/functional/hash/hash.hpp:540:0, from ../../boost/functional/hash.hpp:6, from ../../boost/unordered/unordered_map.hpp:20, from ../../boost/unordered_map.hpp:16, from src/files.cpp:12: ../../boost/functional/hash/extensions.hpp:54:39: error: expected primary- expression before ',' token std::size_t hash_value(std::list const& v); ^ ../../boost/functional/hash/extensions.hpp:54:42: error: expected primary- expression before '>' token std::size_t hash_value(std::list const& v); ^ ../../boost/functional/hash/extensions.hpp:54:44: error: expected primary- expression before 'const' std::size_t hash_value(std::list const& v); ^ ../../boost/functional/hash/extensions.hpp:54:52: error: expression list treated as compound expression in initializer [-fpermissive] std::size_t hash_value(std::list const& v); ^ ../../boost/functional/hash/extensions.hpp:54:17: warning: variable templates only available with -std=c++14 or -std=gnu++14 std::size_t hash_value(std::list const& v); ^ ../../boost/functional/hash/extensions.hpp:85:33: error: 'template std::size_t boost::hash_value' conflicts with a previous declaration std::size_t hash_value(std::list const& v) ^ ../../boost/functional/hash/extensions.hpp:67:17: note: previous declaration 'namespace boost { }::hash_value' std::size_t hash_value(std::complex const&); ^ ../../boost/functional/hash/extensions.hpp:85:28: error: reference to 'list' is ambiguous std::size_t hash_value(std::list const& v) ^ In file included from ../../boost/functional/hash/extensions.hpp:17:0, from ../../boost/functional/hash/hash.hpp:540, from ../../boost/functional/hash.hpp:6, from ../../boost/unordered/unordered_map.hpp:20, from ../../boost/unordered_map.hpp:16, from src/files.cpp:12: ../../boost/detail/container_fwd.hpp:139:47: note: candidates are: template class std::list template class list; ^ In file included from /usr/include/c++/5/list:63:0, from
Bug#798003: freeimage: please change FreeImage.h encoding
Source: freeimage Version: 3.15.4-4.1 Severity: normal Dear Maintainer, could you please change the encoding on installed FreeImage.h header? The actual encoding is no longer ASCII since you introduced a second author "hervé". This change may cause some packages to FTBS. Trying to install salome from source FTBS because of this change. The installer tries to recover FreeImage version by using grep VERSION in FreeImage.h The non ASCII encoding somehow breaks this as the grep command no longer returns the lines including "VERSION". Instead the grep command return a message "Binary matches". Changing "hervé" to herve fix the problem. Best regards C. -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#736916: [tetgen] please upgrade to 1.5.0
On 28 Jan 2014, at 13:18, Anton Gladky gl...@debian.org wrote: Hi Christophe! Good to know, that tetgen has been relicensed! I will try to upload it in the evening. Could, you, please, then have a look at gmsh to enable this feature there? Yes of course I also plan to merge gmsh-tetgen with gmsh as there is no more issue with non-free software. I manage to build gmsh-tetgen with tetgen, netgen 5.1… but I need to patch gush for metis. Then we can complete the merge. Best C PS: could you also take a look at mmg3d an 3d anisotropic meshed that is also used in gmsh and freefrem++ Thanks, Anton 2014-01-28 trophime christophe.troph...@lncmi.cnrs.fr: Package: tetgen Version: 1.5.0-1.1 Severity: wishlist Please upgrade to 1.5.0 Now tetgen is licenced under AGPLv3 I believe that the package could therefore go to contrib You can find a tentative upgrade on Debian Science svn repository Could someone review this package? smime.p7s Description: S/MIME cryptographic signature
Bug#732362: vtk 5.10.1 for jessie
Part of the trouble is that VTK_USE_EXTERNAL option is not fully supported right now by upstream. However we can build paraview on top of vtk (see branch use_external_vtk in paraview.git) There may be a way to install vtk 6.xx libs from paraview that won't clash with any vtk package except python-vtk. From my trials it seems that to get a working paraview-python we must ship a python-vtk package. I can create a new branch on paraview.git to see my progress in that direction if you wish Christophe TROPHIME Research Engineer CNRS - LNCMI 25, rue des Martyrs BP 166 38042 GRENOBLE Cedex 9 FRANCE Tel : +33 (0)4 76 88 90 02 Fax : +33 (0) 4 76 88 10 01 Office U 19 M@il : christophe.troph...@lncmi.cnrs.fr - Mail original - De: Anton Gladky gl...@debian.org À: Dominique Belhachemi domi...@debian.org, Christophe Trophime christophe.troph...@lncmi.cnrs.fr Cc: Mathieu Malaterre ma...@debian.org, 732362 732...@bugs.debian.org Envoyé: Mardi 17 Décembre 2013 14:39:45 Objet: Re: Bug#732362: vtk 5.10.1 for jessie 2013/12/17 Dominique Belhachemi domi...@debian.org: Anton, we might need your help with the paraview package. We need to figure out a way to build against system VTK libraries. This would help avoiding file conflicts and the vtk package would get a better test coverage. Christophe Trophime has done already a job to escape such conflicts. Moreover he proposed to build vtk-binaries from Paraview-source. Looks reasonable... Anton -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731211: aster: new upstream release, work in progress
There's a new stable release of Aster available: 11.4. I am currently working on adapting the current packaging for this release. The build system changed (waf inside now), so this requires a bit of work. I think we should stick to the rpevious way of building aster as warf build are discouraged [1] [1] http://lists.debian.org/debian-devel/2012/02/msg00207.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728995: scotch: gpart binary (interface of gmap) is missing
On 07 Nov 2013, at 18:13, gregory gregory.mou...@imag.fr wrote: Package: scotch Version: 5.1.12b.dfsg-2+b1 Severity: important Dear Maintainer, The man of scotch_gmap cite the gpart program as a simplified interface of gmap. As explained in the man, gpart partition the graph without using a mapping file. The use of gmap requires to understand the mapping model and tools of scotch. But the gpart binary is not included in the scotch package. It may be scotch_gpart.. I had to rename all the scotch executables due to some name clashes but I have forgotten to change the manages accordingly… -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-1-amd64 (SMP w/8 CPU cores) 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 scotch depends on: ii libc6 2.17-93 ii libhwloc5 1.7.2-1 ii libopenmpi1.6 1.6.5-5 ii libscotch-5.1 5.1.12b.dfsg-2+b1 ii zlib1g 1:1.2.8.dfsg-1 scotch recommends no packages. scotch suggests no packages. -- no debconf information -- debian-science-maintainers mailing list debian-science-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers smime.p7s Description: S/MIME cryptographic signature
Bug#708862: gmsh: FTBFS on powerpcspe
Hi, could you also upgrade to 2.7.1? You will find updated patch in Debian science svn gmsh-tetgen for this version. Best C On May 19, 2013, at 11:34 AM, Anton Gladky wrote: tags 708862 +patch +pending thanks Hi Roland, thanks for bugreport and patch! It is committed into VCS and will appear in the next upload. Anton On 05/19/2013 11:18 AM, Debian BTS wrote: Source: gmsh Version: 2.7.0.dfsg-1 Severity: wishlist Tags: patch User: debian-powerpc...@breakpoint.cc Usertags: powerpcspe gmsh FTBFS on powerpcspe[1]: ... /usr/bin/mpicxx -DNO_PARALLEL_THREADS -DNOTCL -DHAVE_NO_OCC_CONFIG_H -DOCCGEOMETRY -DMPICH_SKIP_MPICXX -DOMPI_SKIP_MPICXX -fopenmp -lmpi -fPIC -Wall -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -O2 -g -I/«PKGBUILDDIR»/contrib/onelab -I/«PKGBUILDDIR»/contrib/mpeg_encode/headers -I/«PKGBUILDDIR»/contrib/lbfgs -I/«PKGBUILDDIR»/contrib/DiscreteIntegration -I/«PKGBUILDDIR»/contrib/HighOrderMeshOptimizer -I/«PKGBUILDDIR»/contrib/kbipack -I/«PKGBUILDDIR»/contrib/MathEx -I/«PKGBUILDDIR»/contrib/Chaco/main -I/«PKGBUILDDIR»/contrib/rtree -I/«PKGBUILDDIR»/contrib/voro++/src -I/«PKGBUILDDIR»/contrib/blossom/MATCH -I/«PKGBUILDDIR»/contrib/blossom/concorde97 -I/«PKGBUILDDIR»/contrib/blossom/concorde97/INCLUDE -I/«PKGBUILDDIR»/contrib/Netgen -I/«PKGBUILDDIR»/contrib/Netgen/libsrc/include -I/«PKGBUILDDIR»/contrib/Netgen/nglib -I/«PKGBUILDDIR»/contrib/ bamg -I/ «PKGBUILDDIR»/contrib/bamg/bamglib -I/«PKGBUILDDIR»/contrib/mmg3d/build/sources -I/«PKGBUILDDIR»/contrib/Salome -I/«PKGBUILDDIR»/Common -I/«PKGBUILDDIR»/Fltk -I/«PKGBUILDDIR»/Geo -I/«PKGBUILDDIR»/Graphics -I/«PKGBUILDDIR»/Mesh -I/«PKGBUILDDIR»/Solver -I/«PKGBUILDDIR»/Numeric -I/«PKGBUILDDIR»/Parser -I/«PKGBUILDDIR»/Plugin -I/«PKGBUILDDIR»/Post -I/«PKGBUILDDIR»/Qt -I/usr/include/FL/images -I/usr/include/jpeg -I/usr/include/zlib -I/usr/include/png -I/usr/include/ANN -I/usr/include/gmm -I/usr/include/slepc -I/usr/include/petsc -I/usr/lib/oce-0.9.1/../../include/oce -I/usr/include/mpi -I/«PKGBUILDDIR»/debian/build/Common-Wall -o CMakeFiles/gmsh.dir/Common/GmshMessage.cpp.o -c /«PKGBUILDDIR»/Common/GmshMessage.cpp In file included from /usr/include/slepc/slepc.h:29:0, from /«PKGBUILDDIR»/Common/GmshMessage.cpp:35: /usr/include/slepc/slepcsys.h:33:23: fatal error: slepcconf.h: No such file or directory compilation terminated. make[4]: *** [CMakeFiles/gmsh.dir/Common/GmshMessage.cpp.o] Error 1 ... As for other architectures where gmsh FTBFS with libslepc and libpetsc, this can be worked around by omitting these from Build-Depends:, see attached patch. This patch further fixes a multiarch path in debian/rules to make the package build in current sid. Thanks, Roland [1] http://wiki.debian.org/PowerPCSPEPort -- System Information: Debian Release: 7.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: powerpcspe (ppc) Kernel: Linux 3.9.0-dirty (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash --===2105477895== Content-Type: text/x-diff; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=gmsh.patch --- gmsh-2.7.0.dfsg/debian/control.orig 2013-05-07 09:40:02.0 +0200 +++ gmsh-2.7.0.dfsg/debian/control 2013-05-18 18:50:20.484782969 +0200 @@ -17,8 +17,8 @@ libblas-dev, liblapack-dev, libgl2ps-dev, freeglut3-dev, python-dev (= 2.6.6-3~), swig2.0, chrpath, libann-dev, - libpetsc3.2-dev [!kfreebsd-amd64 !kfreebsd-i386 !armel !armhf !s390x], - libslepc3.2-dev [!kfreebsd-amd64 !kfreebsd-i386 !armel !armhf !s390x], + libpetsc3.2-dev [!kfreebsd-amd64 !kfreebsd-i386 !armel !armhf !powerpcspe !s390x], + libslepc3.2-dev [!kfreebsd-amd64 !kfreebsd-i386 !armel !armhf !powerpcspe !s390x], javahelper, default-jdk Standards-Version: 3.9.4 X-Python-Version: current --- gmsh-2.7.0.dfsg/debian/rules.orig2013-03-15 22:54:57.0 +0100 +++ gmsh-2.7.0.dfsg/debian/rules 2013-05-18 23:15:05.056623369 +0200 @@ -2,6 +2,8 @@ BUILDDIR = $(CURDIR)/debian/build JAVA_HOME=/usr/lib/jvm/default-java +DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) + export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed @@ -19,7 +21,7 @@ extra_flags += \ -DPYTHON_INCLUDE_DIR:PATH=/usr/include/python2.7 \ --DPYTHON_LIBRARY:FILEPATH=/usr/lib/libpython2.7.so \ +-DPYTHON_LIBRARY:FILEPATH=/usr/lib/$(DEB_HOST_MULTIARCH)/libpython2.7.so \ -DENABLE_METIS:BOOL=OFF \
Bug#679617: not working octave bindings
On Jun 30, 2012, at 10:19 AM, Sergey B Kirpichev wrote: Package: octave-nlopt Version: 2.2.4+dfsg-1 Severity: grave This issue was reported in closed ITP bugreport #610623. But after accepting buggy package in Debian --- test script (tutorial example from upstream wiki) fails as before: $ octave -q ./tutorial.m error: invalid use of script /usr/share/octave/site/m/nlopt_optimize.m in index expression error: called from: error: /home/sk/nlopt-test/tutorial.m at line 22, column 24 PS: Test suite (nlopt-test.tgz) was attached to #610623. The issue is fixed in Debian science svn. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679619: not working guile bindings
On Jun 30, 2012, at 10:26 AM, Sergey B Kirpichev wrote: Package: libnlopt-guile0 Version: 2.2.4+dfsg-1 Severity: grave This issue was reported in closed ITP #610623. $ guile ./tutorial.scm ERROR: In procedure dynamic-link: ERROR: file: libnlopt_guile.so, message: file not found Test suite (tutorial examples from upstream wiki, nlopt-test.tgz) was attached to #610623. PS: Why include new package in Debian, if you even not try to test one? The issue is fixed in Debian science svn -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610623: ITP: nlopt -- nonlinear optimization library
On Jun 16, 2012, at 8:01 PM, Sergey B Kirpichev wrote: On Sat, Jun 16, 2012 at 07:02:43PM +0200, Christophe Trophime wrote: the package is building fine. You can find it in debian science svn. 1. Not fine. For me, it just won't build with git-pbuildpackage without --git-ignore-new (due to modifications in source tree). Then, it has ~10 lintian warnings (and more info's). 2. Then, simple copy-paste tests from upstream wiki fail for guile and octave bindings (simple testsuite attached). Packages won't work. I had asked several time for its upload⦠hope to do it by the end of next week. Bad news. It's after freeze. If you like to comantain the package, no problem Howto? :) If you manage to get a better package, you could upload your changes on debian science svn and add your name to maintainers. Thanks nlopt-test.tgz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673221: libdeal.ii-dev: rebuild without libtrilinos
On May 16, 2012, at 8:27 PM, Kevin Mitchell wrote: Package: libdeal.ii-dev Version: 7.1.0-1 Severity: important unfortunately, libtrilinos has been removed due to lack of maintenance [1]. deal.ii should be rebuilt without it. Even before libtrilinos removal, it was rendering deal.ii unusuable [2]. Removing the libtrilinos dependency should fix this issue. [1] http://packages.qa.debian.org/t/trilinos/news/20120515T180350Z.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558452 A updated trillions package for version 10.8.5 could be find in Debian Science svn. As soon as it will be uploaded it will fix this issue. Best C -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654865: petsc: please add shared libraries to debug package
Source: petsc Version: 3.0.0.dfsg-5.1 Severity: wishlist Dear Maintainer, it will be nice to have shared librairies in the debug package as well (if possible) thanks -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/24 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646568: debian-maintainers: Please add Christophe Trophime as a Debian Maintainer
Package: debian-maintainers Severity: normal Please add my key to the DM keyring. See attached jetring changeset. -- System Information: Debian Release: wheezy/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Comment: Add Rico Rommel r...@bierrommel.de as a Debian Maintainer Date: Fri, 29 Jul 2011 17:53:56 +0200 Action: import Recommended-By: Steffen Möller steffen_moel...@gmx.de Agreement: http://lists.debian.org/debian-newmaint/2011/07/msg00034.html Advocates: http://lists.debian.org/debian-newmaint/2011/07/msg00040.html Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.11 (GNU/Linux) mQENBEuBhSIBCADnp/6kjJVraVtQgSV8yV1mJq1auzgwDnTWW4p1P7wFpMJmsE4k XlfeUNwxq8ITMbkObvKIgniwWcxtmC4MvKXAM7aXvhgKVAWEKuoDJ3eitco8xwK4 6fVuEYNeQV9vSxg1RzYO4rhTR8jGSd7ONpIPW0CKznCmisjz8UhTCVrXP7HkYG2G X3AeAau81zJkPQ20EzQCTs+lGxgpvHbD9bi/t3FgE7MIijlhCOYsqetlzPnYKjlo rp1kTPvYAWM6a6hBgy0TkzWoB34ChUQmDlOlKonfH1HuprfU7uJfmKw2mtJ4fqqt daK+6RdyU8SCNU8EXEZm7m6tBmB7MKNvQKW1ABEBAAG0IFJpY28gUm9tbWVsIDxy aWNvQGJpZXJyb21tZWwuZGU+iQE4BBMBAgAiBQJLgYUiAhsDBgsJCAcDAgYVCAIJ CgsEFgIDAQIeAQIXgAAKCRDFgUTlWpuxb/IhB/wJ3yF8qg3xczfdxUrvYA21M+qc z3Wp/xq3oWvKvm7qagqS5skiTzW4oeZ2yiMvjmsZ20tCFc2/AIyPgiz+daHpLbPF Uq9xKzmd/UoMUD2p7f7YjNrrno9H5C2CmXS+r3iTBOfG8293rFCCbpBIX/+jyVuo C4OnrcXTgP+mw6lbsTk3fNrcnGu0UnTI8h+vqSx/CLycVOl/ULNQ0tb92iaFafm1 I4JLBHoP3np1gaGewgh/QSFOSiKWL4xhNwLs3Nfl+e0g2OjJEEkwWRKPOf4Lhj2h ezxbQTLE8dpWNBBydxpiIrQrrewt9k4Bd+yaWjJkp9DSp7hryQ7dea+Z9COziQIc BBABCAAGBQJOJXCQAAoJEKc+AFVVj7jdoUIQAInA6QKMVnq7NeYYT2piwuS3Ekln MgYiWLNx4IFq5/0u2NfMKMEQVYPLhlRxJszHvuA0CuRxbWIlXIXOkiwjWebCjgEx cuKDYzEk/I+k1yKsJvQCBFd7tOgBBakHI5M8F/dRYjEmQHIVRUbsoPN/FLyWyJPH So6qubMfd7fUIGqL8Xefhp2vYucK0i0gne/qROPS5d2sy24jRdWf9NDB2Xi4r/wQ zuaIVH8jtcuAKxhA1l2cHv2RiVv5ZdBXQ8chqYke9Kuv5UtOqvEfFWFf8uJIE+bs Y5c4KHOboI7VB5cHRgXnA2lErxfI+sQMu8sjoPoHvrVKeVWhNpKhtRumCFOxzKIQ p+SNE29uqXzZW+y/OSpl1/BjUwkDcby5bfI+tD5ez3VHs8rut2fCPAnmp/MW8jkO vdkVlh6cn5cfTQqefYklsiZFhOjOdXn7IClvGXPOLhGZQTPcW9h9moJvB9PM6oen 7fz/wKw4pex9lKzO/zDB9alMaWKuSMs2qljDVBZV1Zg2bMUEOZ0SMZA4Rjdskg6E pc45s//UDj32sDyDUxWNrna09rDlVM/L7kftPbrCFCnryoSCguaWBdz1G8lrTi2a uJXW/e2bM+aZ+caOPBx5JD5sc5tMdw8Pba7dBOAZ5rYT2IxHE2lRqAMkWx9TXcUz PECC0kovxDtX1OdKuQENBEuBhSIBCACpnurlg6eViYfPgyPh2ni7Wb1pJ0LwM6ks HIvgUchlvLXK6t5ryXnVMBBf5FX5FHpPvvKzprLXn11Uz6Y49vJm38fEJEHvi6xE QJKmTS2Ehu2AzLf23P9W4yaGoO1+8+WfnNeLEmQo+0X2YqJFeon0zyApYg9Ab3DT Ic8YnbxYiM6sHx7V40XYVJyM79wMbI63wH6DU+WR8gLwY+M5nU91xO/p+lkvfBLO +Svbmtzo9ZaW1eq4hiN9120qZw2nDAhZUvan7iLGUVTq4PnHLZ+dm7zOhuzOKnX0 e57jZ2tFo/eI9L+qpQnGgatFbzjUSE8KCjpIhbmKyglhzg/NavrjABEBAAGJAR8E GAECAAkFAkuBhSICGwwACgkQxYFE5VqbsW+KiggArk0cFhh/+HaOZUQb/GpagWyh JwtCAZ8jGMCHUITPvdz31/wovCWgnUQ+yYNLHA9tRy6eIJkUQkZJ02fqgtCOedLv gf0KsQjXJFMtPmrpg3cD7CVdUv3dBIZVEepx1yyom8tuVkOibsaPs6c0iRfXeK6d GAJr86FiBLpZBP3GUYoAZ9Qmao/xuoAHw8xREiXmZp88UZcUnqgv7YWlpp/7tN6E 1h0KD+Y4A7U/xm8036iVZ1jY0yyq7aGEcuqtCFx/e/K26aeYN94urTwvqNMJpe66 f61P/Czk70zia2h0uB6s/xhfLT2kO2MGF8FN3PE0tuE9S+Nz5oLQkl8jeTRudg== =f80R -END PGP PUBLIC KEY BLOCK-
Bug#631948: med-fichier: please upgrade to 3.0.3
Package: med-fichier Version: 2.3.6-6 Severity: wishlist Please upgrade libmed 3.0.3 It will greatly help the code-aster packaging effort -- System Information: Debian Release: wheezy/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631206: ITP: funcdesigner -- Python module for rapid prototyping of functions with AD
On Jun 21, 2011, at 6:06 PM, Ben Hutchings wrote: On Tue, Jun 21, 2011 at 04:03:09PM +0200, trophime wrote: Package: wnpp Severity: wishlist Owner: trophime christophe.troph...@lncmi.cnrs.fr * Package name: funcdesigner Version : 0.34 Upstream Author : Dmitrey Kroshko dmitrey.kros...@scipy.org * URL : http://openopt.org/ * License : BSD Programming Lang: Python Description : Python module for rapid prototyping of functions with AD What's AD? The description should spell it out. AD stands for Automatic Differentiation. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587854: getdp-sparskit: provided by latest getdp source package
The ITP for getdp-sparskit is no longer needed as we achieve to build a binary package for getdp-sparskit within the latest getdp source package (2.1). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610623: ITP: nlopt -- nonlinear optimization library
Package: wnpp Severity: wishlist Owner: Christophe Trophime christophe.troph...@grenoble.cnrs.fr * Package name: nlopt Version : 2.2.1 Upstream Author : Steven G. Johnson stev...@alum.mit.edu * URL : http://ab-initio.mit.edu/wiki/index.php/NLopt * License : LGPL Programming Lang: C, C++, Python, octave Description : nonlinear optimization library NLopt is a free/open-source library for nonlinear optimization, providing a common interface for a number of different free optimization routines available online as well as original implementations of various other algorithms. Its features include: * Callable from C, C++, Fortran, GNU Octave, Python, GNU Guile, GNU R. * A common interface for many different algorithms * Support for large-scale optimization. * Both global and local optimization algorithms. * Algorithms using function values only (derivative-free) and also algorithms exploiting user-supplied gradients. * Algorithms for unconstrained optimization, bound-constrained optimization, and general nonlinear inequality/equality constraints. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609832: [Pkg-scicomp-devel] Bug#609832: libsundials-cvode1: CVODE is 2.4 when 2.6 has been realeased
On Jan 12, 2011, at 9:55 PM, Guillaume Yziquel wrote: Package: libsundials-cvode1 Version: 2.4.0-1 Severity: wishlist CVODE 2.6 has been released, but packaging in Debian is 2.4 The package has been named after the sundials version. So CVODE should be in version 2.6 even if the version is quoted 2.4. We use the CVODE coming from the sundials 2.4 tarball! Is there a way to check this? Shall we change the version of the sub-libraries in sundials package? Would be nice to upgrade. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (700, 'stable'), (500, 'stable'), (90, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libsundials-cvode1 depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib libsundials-cvode1 recommends no packages. libsundials-cvode1 suggests no packages. -- no debconf information ___ Pkg-scicomp-devel mailing list pkg-scicomp-de...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-scicomp-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603279: libopencascade-foundation-6.3.0: TKjcas lib is missing from package
On Nov 12, 2010, at 3:14 PM, Yorik van Havre wrote: Package: libopencascade-foundation-6.3.0 Version: 6.3.0.dfsg.1-6 Severity: normal Hi there, the libTKjcas-6.3.0.so library is missing from some of the packages (amd64, i386), although it is informed in the package description and appears in some other packages (hppa,kfreebsd). I'm not totally sure what it is used for, but it is needed by pythonOCC, so I suppose it makes sense to be included... I think if I recall correctly in ealier versions that library was included too... Cheers Yorik -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libopencascade-foundation-6.3.0 depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-6 GCC support library ii libstdc++64.4.5-6The GNU Standard C++ Library v3 libopencascade-foundation-6.3.0 recommends no packages. libopencascade-foundation-6.3.0 suggests no packages. -- no debconf information -- debian-science-maintainers mailing list debian-science-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-science-maintainers setup.patch Description: Binary data rules Description: Binary data You can work around this problem. I tried to package pythonOCC 0.4. I had to apply the attached patch to get it installed with the squeeze existing opencascade. I also attached the debian/rules I used to generate the package Best regards C.
Bug#575305: togl: FTBFS on kfreebsd-amd64
On Mar 24, 2010, at 9:15 PM, Cyril Brulebois wrote: Source: togl Version: 1.7-11 Severity: important User: debian-...@lists.debian.org Usertags: kfreebsd Hi, your package FTBFS on kfieebsd-amd64 (while it builds fine on kfreebsd-i386). Build excerpt: | /usr/bin/make -C . | make[1]: Entering directory `/build/buildd-togl_1.7-11-kfreebsd- amd64-5v4gd1/togl-1.7' | cc -pipe -DPACKAGE_NAME=\Togl\ -DPACKAGE_TARNAME=\togl\ - DPACKAGE_VERSION=\1.7\ -DPACKAGE_STRING=\Togl\ 1.7\ - DPACKAGE_BUGREPORT=\\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 - DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 - DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 - DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 - DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 - D_THREAD_SAFE=1 -DTCL_THREADS=1 -D_LARGEFILE64_SOURCE=1 - DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1 -DUSE_TK_STUBS=1 -I/usr/ include/tcl8.5 -I/usr/include/tcl8.5/tk-private/generic -I/usr/ include/tcl8.5/tk-private/unix -g -O2 -g -Wall -O2 -O2 -Wall - Wno-implicit-int -c `echo togl.c` -o togl.o | rm -f libTogl1.7 | o libTogl1.7 togl.o -lX11 -lGL -lXmu -L/usr/lib -ltclstub8.5 -L/ usr/lib -ltkstub8.5 | /bin/bash: o: command not found looks like a build system bug? Maybe because it should be something like: cc -pipe -shared -o libTogl1.7.so togl.o -lX11 -lGL -lXmu -L/usr/lib - ltclstub8.5 -L/usr/lib -ltkstub8.5 | make[1]: [libTogl1.7] Error 127 (ignored) I'm not sure why it's ignored though. | : libTogl1.7 | make[1]: Leaving directory `/build/buildd-togl_1.7-11-kfreebsd- amd64-5v4gd1/togl-1.7' | touch debian/stamp-makefile-build | DEB_MAKE_CHECK_TARGET unset, not running checks | rm -f libTogl1.7.so | cc -shared -Wl,-soname,libTogl.so.1 -lX11 -lGL -lXmu -ltclstub8.5 -ltkstub8.5 -o libTogl.so.1.7 togl.o | /usr/bin/ld: togl.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC | togl.o: could not read symbols: Bad value Probably due to the first issue. | collect2: ld returned 1 exit status | make: *** [build/libtogl1] Error 1 Full build logs: https://buildd.debian.org/status/package.php?p=togl Mraw, KiBi. !DSPAM:22,4baa7400280641683618940! smime.p7s Description: S/MIME cryptographic signature
Bug#561384: Please package ptscotch
Package: scotch Version: 5.1.6-dfsg-1 Severity: wishlist Please package ptscotch the mpi version of scotch It will enable to replace parmetis by ptscotch -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556643: ITP: togl -- a Tk OpenGL widget
Package: wnpp Severity: wishlist Owner: Christophe Trophime christophe.troph...@grenoble.cnrs.fr * Package name: togl Version : 1.7 Upstream Author :Brian Paul br...@mesa3d.org, Benjamin Bederson beder...@cs.umd.edu, Greg Couch gregco...@sourceforge.net * URL : http://togl.sourceforge.net/ * License : non-free, redistribuable Programming Lang: Tcl, Tk Description : a Tk OpenGL widget Togl is a Tk widget for OpenGL rendering. Togl was originally based on OGLTK, written by Benjamin Bederson at the University of New Mexico. Togl's main features are: * unifies Microsoft Windows, X11 (Linux/IRIX/...), and Mac OS X Aqua support * support for requesting stencil, accumulation, alpha buffers, etc. * multiple OpenGL drawing windows * simple stereo rendering support * simple, portable font support * color-index mode support including color allocation functions * overlay plane support * OpenGL extension testing from Tcl * Tcl Extension Architecture (TEA) 3 compliant The license states that Modifications to this software may be copyrighted by their authors and need not follow the licensing terms described here, provided that the new terms are clearly indicated on the first page of each file where they apply.. Does it mean the it is not DFSG? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org