Bug#1072524: systemd: On a debian trixie, after upgrading systemd to latest version the system fails to reboot.

2024-06-04 Thread Christophe Trophime
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.

2024-06-03 Thread Christophe Trophime
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

2023-09-01 Thread Christophe Trophime

- 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

2023-08-31 Thread Christophe Trophime


- 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

2023-08-01 Thread Christophe Trophime
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

2022-03-25 Thread Christophe Trophime

- 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

2022-03-25 Thread Christophe Trophime

> 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

2022-03-25 Thread Christophe Trophime
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

2022-03-12 Thread Christophe Trophime
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

2022-01-18 Thread Christophe Trophime
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

2021-12-14 Thread Christophe Trophime
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

2021-12-10 Thread Christophe Trophime
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

2020-12-08 Thread Christophe Trophime
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

2020-10-22 Thread Christophe Trophime
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

2020-04-20 Thread Christophe Trophime

This bug may be merged with #9538327

Sorry for the duplicate.



Bug#958329: charliecloud: user+mount is not supported

2020-04-20 Thread Christophe Trophime
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

2020-04-20 Thread Christophe Trophime
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

2020-03-04 Thread Christophe Trophime
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

2020-01-13 Thread Christophe Trophime
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

2020-01-13 Thread Christophe Trophime
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

2019-12-16 Thread Christophe Trophime
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

2019-12-13 Thread Christophe Trophime
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

2019-12-06 Thread Christophe Trophime
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?

2019-09-03 Thread Christophe Trophime
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

2019-03-29 Thread Christophe Trophime
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

2018-08-17 Thread Christophe Trophime
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

2018-04-09 Thread Christophe Trophime
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

2017-03-24 Thread Christophe Trophime
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

2016-09-13 Thread Christophe Trophime
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

2016-09-12 Thread Christophe Trophime
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

2015-11-22 Thread Christophe Trophime




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

2015-10-29 Thread Christophe Trophime
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::list const& 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

2015-09-04 Thread Christophe Trophime
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

2014-01-28 Thread Christophe Trophime

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

2013-12-17 Thread Christophe Trophime

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

2013-12-04 Thread Christophe Trophime

 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

2013-11-07 Thread Christophe Trophime

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

2013-05-19 Thread Christophe Trophime
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

2012-06-30 Thread Christophe Trophime

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

2012-06-30 Thread Christophe Trophime

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

2012-06-16 Thread Christophe Trophime

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

2012-05-17 Thread Christophe Trophime

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

2012-01-06 Thread Christophe Trophime
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

2011-10-25 Thread christophe . trophime
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

2011-06-28 Thread Christophe Trophime
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

2011-06-21 Thread Christophe Trophime

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

2011-03-14 Thread Christophe Trophime
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

2011-01-20 Thread Christophe Trophime
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

2011-01-14 Thread Christophe Trophime

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

2010-11-12 Thread Christophe Trophime

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

2010-03-24 Thread Christophe Trophime


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

2009-12-16 Thread Christophe Trophime
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

2009-11-17 Thread Christophe Trophime
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