Bug#918375: Docker SIGSEGV

2020-06-06 Thread Pini 
Hi,

On Sat, 5 Jan 2019 17:48:31 +0100 Vincent Smeets
 wrote:
> Hallo,
> 
> I want to add that I don't know how to reproduce the SIGSEGV. It
> happends when I am developing containers, but also during my breaks
> (screenlock). Testing a solution will be difficult.
> 
> Here are todays SIGSEGVs:
> 
> vincent@PC-Vincent:~$ sudo journalctl -b0 | grep SIGSEGV
> jan 05 10:36:18 PC-Vincent dockerd[954]: [signal SIGSEGV: segmentation
> violation code=0x1 addr=0x0 pc=0x564a9d3a2158]
> jan 05 11:13:36 PC-Vincent dockerd[18723]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x555897453158]
> jan 05 12:00:59 PC-Vincent dockerd[32147]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x560bac7a1158]
> jan 05 12:42:33 PC-Vincent dockerd[14174]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x559c2e092158]
> jan 05 13:12:36 PC-Vincent dockerd[29099]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x564e8f238158]
> jan 05 13:42:40 PC-Vincent dockerd[4024]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x56084fc6a158]
> jan 05 14:12:43 PC-Vincent dockerd[13242]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x89727158]
> jan 05 14:42:46 PC-Vincent dockerd[23871]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x55acb4c17158]
> jan 05 15:12:50 PC-Vincent dockerd[30296]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x5599f09e7158]
> jan 05 15:42:53 PC-Vincent dockerd[4545]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x55593e7e2158]
> jan 05 16:12:56 PC-Vincent dockerd[9021]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x5630b39d9158]
> jan 05 16:43:00 PC-Vincent dockerd[13117]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x55f1fe291158]
> jan 05 17:13:03 PC-Vincent dockerd[17369]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x556626f84158]
> jan 05 17:43:06 PC-Vincent dockerd[22316]: [signal SIGSEGV:
> segmentation violation code=0x1 addr=0x0 pc=0x55bc4ddbc158]
> vincent@PC-Vincent:~$

Same pattern here. I've migrated for testing purpose standalone compose
mode containers to a single node swarm, and the docker service now
segfaults every 30 minutes with:

juin 06 21:30:34 serveur dockerd[10190]: panic: runtime error: invalid
memory address or nil pointer dereference
juin 06 21:30:34 serveur dockerd[10190]: [signal SIGSEGV: segmentation
violation code=0x1 addr=0x0 pc=0x55fc93504388]
juin 06 21:30:34 serveur dockerd[10190]: goroutine 1358 [running]:
juin 06 21:30:34 serveur dockerd[10190]:
github.com/armon/go-radix.recursiveWalk(0x0, 0xc003805e08, 0x55fc946a8900)
juin 06 21:30:34 serveur dockerd[10190]:
/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/armon/go-radix/radix.go:519
+0x28
juin 06 21:30:34 serveur dockerd[10190]:
github.com/armon/go-radix.recursiveWalk(0xc004ec8f90, 0xc003805e08,
0xc003805c00)
juin 06 21:30:34 serveur dockerd[10190]:
/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/armon/go-radix/radix.go:525
+0x7a
juin 06 21:30:34 serveur dockerd[10190]:
github.com/armon/go-radix.recursiveWalk(0xc003379e30, 0xc003805e08,
0xc003805c00)
juin 06 21:30:34 serveur dockerd[10190]:
/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/armon/go-radix/radix.go:525
+0x7a
juin 06 21:30:34 serveur dockerd[10190]:
github.com/armon/go-radix.recursiveWalk(0xc004ec8750, 0xc003805e08, 0x19)
juin 06 21:30:34 serveur dockerd[10190]:
/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/armon/go-radix/radix.go:525
+0x7a
juin 06 21:30:34 serveur dockerd[10190]:
github.com/armon/go-radix.(*Tree).WalkPrefix(0xc0055ab620, 0xc0062ebaa0,
0x1a, 0xc003805e08)
juin 06 21:30:34 serveur dockerd[10190]:
/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/armon/go-radix/radix.go:473
+0xdb
juin 06 21:30:34 serveur dockerd[10190]:
github.com/docker/libnetwork/networkdb.(*NetworkDB).reapTableEntries(0xc005308c60)
juin 06 21:30:34 serveur dockerd[10190]:
/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/docker/libnetwork/networkdb/cluster.go:396
+0x3c5
juin 06 21:30:34 serveur dockerd[10190]:
github.com/docker/libnetwork/networkdb.(*NetworkDB).reapState(0xc005308c60)
juin 06 21:30:34 serveur dockerd[10190]:
/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/docker/libnetwork/networkdb/cluster.go:362
+0x2d
juin 06 21:30:34 serveur dockerd[10190]:
github.com/docker/libnetwork/networkdb.(*NetworkDB).reapState-fm()
juin 06 21:30:34 serveur dockerd[10190]:
/build/docker.io-X5uIDh/docker.io-18.09.1+dfsg1/.gopath/src/github.com/docker/libnetwork/networkdb/cluster.go:170
+0x2c
juin 06 21:30:34 serveur dockerd[10190]:
github.com/docker/libnetwork/networkdb.(*NetworkDB).triggerFunc(0xc005308c60,
0x12a05f200, 0xc000cbd1a0, 0xc002703e60)
juin 06 21:30:34 serveur dockerd[10190]:

Bug#917788: libmedc11: Overwrites a file from libmedc1v5

2019-01-05 Thread pini 
On Sat, 5 Jan 2019 21:53:13 +0100 Gilles Filippini  wrote:
> On Sat, 5 Jan 2019 17:23:11 +0100 Mattia Rizzolo  wrote:
> > Control: reopen -1
> > 
> > On Wed, Jan 02, 2019 at 12:45:08AM +0100, Andreas Beckmann wrote:
> > > On Sun, 30 Dec 2018 09:21:03 -0600 Kurt Kremitzki  
> > > wrote:
> > > > I was just about to open a bug on this same issue. It's actually present
> > > > in both libmed11 and libmedc11. Instead of Conflicts, they both need
> > > > Breaks + Replaces, see Policy 7.6 [1] or #906110 [2] for a similar
> > > 
> > > In this special case, you probably need to add
> > >   Breaks+Replaces: libmed1v5 (>= 4)
> > > respectively
> > >   Breaks+Replaces: libmedc1v5 (>= 4)
> > > since the versions before 4 should not have any file conflicts.
> > 
> > Actually, I think Breaks+Replaces is wrong here.
> > 
> > Breaks+Replaces allow for silent replacing of the old package, but here
> > you need to forcefully remove it, which is what you'd use Conflicts for.
> > As a data point, that what we usually use when renaming packages during
> > ABI breaks like what has been done for #916881.
> 
> I agree that Conflicts suits better regarding the need to forcibly
> remove libmed1v5 / libmedc1v5 (= 4.0.0+repack-1).
> 
> > Incidentally, I think that would also cover the just openend #918372,
> > as with a Conflicts the libgmsh3 package from testing woudln't be
> > installable, so it would force an upgrade to the version in unstable,
> > making the test pass.
> 
> Here I'm not sure. I think the problem is that libmed1v5 and libmedc1v5
> from the broken med-fichier 4.0.0+repack-1 are still present into
> unstable. Is there a way to have them removed?

Oh, looking at cruft-report [1] I see that syrthes-tools still dépends on 
libmedc1v5, preventing the removal :
* source package med-fichier version 4.0.0+repack-6 no longer builds
  binary package(s): libmed1v5 libmedc1v5
  on amd64,arm64,armel,armhf,hurd-i386,i386,mips,mips64el,mipsel,ppc64el,s390x
  - suggested command:
dak rm -m "[auto-cruft] NBS (no longer built by med-fichier)" -s unstable 
-a amd64,arm64,armel,armhf,hurd-i386,i386,mips,mips64el,mipsel,ppc64el,s390x -p 
-R -b libmed1v5 libmedc1v5
  - broken Depends:
syrthes: syrthes-tools [amd64 arm64 armel armhf hurd-i386 i386 mips 
mips64el mipsel ppc64el]

[1] http://ftp-master.debian.org/cruft-report-daily.txt

I'm going to fix that.

Thanks,

_g.

Bug#914748: ant: Fail when installed along with usrmerge and invoked via /bin/ant

2018-11-27 Thread pini 
On Mon, 26 Nov 2018 23:54:06 +0100 Emmanuel Bourg  wrote:
> Control: severity -1 normal
> 
> Le 26/11/2018 à 23:38, Gilles Filippini a écrit :
> 
> > To me this is RC because it makes opencv FTBFS on some official buildd
> > machines. No opinion at all about usrmerge.
> 
> My understanding is that usrmerge is optional at this point and the
> builders are going to be reverted to non usrmerged. For this reason I'm
> lowering the severity.
> 
> 
> > In any case the scriplet replaced by the patch is buggy.
> > How about pushing this patch upstream?
> 
> The patch looks good to me, thanks a lot. Do you know if readlink is
> commonly available on other Unix platforms?

I don't know. In case it's not, it's easy to test and fallback on the
removed snippet.

_g.

Bug#853351: comet-ms: ftbfs with GCC-7

2017-10-16 Thread pini 
Control: tags -1 + patch

Hi,

On Tue, 31 Jan 2017 09:30:22 + Matthias Klose  wrote:
> Package: src:comet-ms
> Version: 2014022-3
> Severity: normal
> Tags: sid buster
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-7
> 
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
> 
> The package fails to build in a test rebuild on at least amd64 with
> gcc-7/g++-7, but succeeds to build with gcc-6/g++-6. The
> severity of this report may be raised before the buster release.
> There is no need to fix this issue in time for the stretch release.
> 
> The full build log can be found at:
> http://people.debian.org/~doko/logs/gcc7-20170126/comet-ms_2014022-3_unstable_gcc7.log
> The last lines of the build log are at the end of this report.
> 
> To build with GCC 7, either set CC=gcc-7 CXX=g++-7 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
> 
>   apt-get -t=experimental install g++ 
> 
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped symbols in Debian symbols files.
> For other C/C++ related build failures see the porting guide at
> http://gcc.gnu.org/gcc-7/porting_to.html
> 
> [...]
> dpkg-source: info: applying fix-format-security-gcc-warnings.patch
> dpkg-source: info: applying 
> fix-makefiles-to-handle-lib-debian-way-of-doing-things.patch
> dpkg-source: info: building comet-ms using existing 
> ./comet-ms_2014022.orig.tar.gz
> dpkg-source: info: building comet-ms in comet-ms_2014022-3.debian.tar.xz
> dpkg-source: info: building comet-ms in comet-ms_2014022-3.dsc
>  debian/rules build
> dh build
>dh_testdir
>dh_update_autotools_config
>dh_auto_configure
>debian/rules override_dh_auto_build
> make[1]: Entering directory '/<>'
> docbook-to-man debian/comet-ms.sgml > debian/comet-ms.1
> /usr/bin/onsgmls:debian/comet-ms.sgml:89:12:E: end tag for "PARA" omitted, 
> but OMITTAG NO was specified
> /usr/bin/onsgmls:debian/comet-ms.sgml:87:4: start tag was here
> /usr/bin/onsgmls:debian/comet-ms.sgml:89:12: open elements: REFENTRY 
> REFSECT1[1] PARA[1] (#PCDATA[1])
> dh_quilt_patch
>   quilt --quiltrc /dev/null push -a || test $? = 2
> File series fully applied, ends at patch 
> fix-makefiles-to-handle-lib-debian-way-of-doing-things.patch
> make 
> make[2]: Entering directory '/<>'
> g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -Wall 
> -Wformat-security -Wextra -Wno-char-subscripts -D_LARGEFILE_SOURCE 
> -D_FILE_OFFSET_BITS=64 -DGCC -I/usr/include/libmstoolkit -ICometSearch -L. 
> Comet.cpp -c
> In file included from CometSearch/Common.h:39:0,
>  from Comet.cpp:18:
> /usr/include/libmstoolkit/MSReader.h:85:80: error: invalid conversion from 
> 'char' to 'char*' [-fpermissive]
>void writeFile(const char* c, MSFileFormat ff, MSObject& m, char* 
> sha1Report='\0');

Patch proposal for libmstoolkit attached.

Thanks,

_g.
diff -Nru libmstoolkit-77.0.0/debian/changelog 
libmstoolkit-77.0.0/debian/changelog
--- libmstoolkit-77.0.0/debian/changelog2015-01-13 10:25:07.0 
+0100
+++ libmstoolkit-77.0.0/debian/changelog2017-10-11 18:45:22.0 
+0200
@@ -1,3 +1,10 @@
+libmstoolkit (77.0.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch gcc-7.patch: fix FTBFS with GCC-7 (closes: #853351)
+
+ -- Gilles Filippini   Wed, 11 Oct 2017 18:45:22 +0200
+
 libmstoolkit (77.0.0-1) unstable; urgency=medium
 
   * New upstream version;
diff -Nru libmstoolkit-77.0.0/debian/patches/gcc-7.patch 
libmstoolkit-77.0.0/debian/patches/gcc-7.patch
--- libmstoolkit-77.0.0/debian/patches/gcc-7.patch  1970-01-01 
01:00:00.0 +0100
+++ libmstoolkit-77.0.0/debian/patches/gcc-7.patch  2017-10-11 
18:45:22.0 +0200
@@ -0,0 +1,26 @@
+Index: libmstoolkit/include/MSReader.h
+===
+--- libmstoolkit.orig/include/MSReader.h
 libmstoolkit/include/MSReader.h
+@@ -82,7 +82,7 @@ class MSReader {
+   void setPrecisionInt(int i);
+   void setPrecisionMZ(int i);
+   void writeFile(const char* c, bool text, MSObject& m);
+-  void writeFile(const char* c, MSFileFormat ff, MSObject& m, char* 
sha1Report='\0');
++  void writeFile(const char* c, MSFileFormat ff, MSObject& m, char* 
sha1Report=NULL);
+ 
+   bool readMSTFile(const char* c, bool text, Spectrum& s, int scNum=0);
+   bool readMZPFile(const char* c, Spectrum& s, int scNum=0);
+Index: libmstoolkit/src/MSToolkit/MSReader.cpp
+===
+--- libmstoolkit.orig/src/MSToolkit/MSReader.cpp

Bug#846735: libsis-jhdf5-java: FTBFS: Test failures

2016-12-04 Thread pini 
Control: forcemerge 842815 -1


Hi,

On Sat, 3 Dec 2016 08:43:11 +0100 Lucas Nussbaum  wrote:
> Source: libsis-jhdf5-java
> Version: 14.12.6-1
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20161202 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > [Utils]   Directory test-output/junitreports exists: true
> > [Utils] Attempting to create 
> > test-output/junitreports/TEST-ch.systemsx.cisd.hdf5.h5ar.UtilsTest.xml
> > [Utils]   Directory test-output/junitreports exists: true
> > [Utils] Attempting to create 
> > test-output/junitreports/TEST-ch.systemsx.cisd.hdf5.io.HDF5DataSetRandomAccessFileTest.xml
> > [Utils]   Directory test-output/junitreports exists: true
> > [Utils] Attempting to create 
> > test-output/junitreports/TEST-ch.systemsx.cisd.hdf5.h5ar.ArchivingStrategyTest.xml
> > [Utils]   Directory test-output/junitreports exists: true
> > [TestNG] Time taken by org.testng.reporters.JUnitReportReporter@6f75e721: 
> > 68 ms
> > [Utils] Attempting to create test-output/testng-failed.xml
> > [Utils]   Directory test-output exists: true
> > [Utils] Attempting to create 
> > /<>/test-output/All/testng-failed.xml
> > [Utils]   Directory /<>/test-output/All exists: true
> > [TestNG] Time taken by [FailedReporter passed=0 failed=0 skipped=0]: 18 ms
> > [TestNG] Time taken by org.testng.reporters.XMLReporter@41a4555e: 48 ms
> > [TestNG] Time taken by org.testng.reporters.jq.Main@1175e2db: 82 ms
> > debian/rules:46: recipe for target 'override_dh_auto_test' failed

This is #842815.

Thanks,

_g.

Bug#842815: Re-opening: Please support HDF5 1.10

2016-12-04 Thread pini 
Hi,

On Wed, 23 Nov 2016 08:06:27 +0100 Andreas Tille 
wrote:
> Hi Bernd,
> 
> On Wed, Nov 23, 2016 at 06:54:21AM +0100, Bernd Rinn wrote:
> > the migration of JHDF5 to HDF5 1.10 is ongoing and mostly depend on me
> > having a block of time I can spend on it. Your analysis of the work that
> > needs to be done is right from what I can see. The plan is to switch to
> > using the JNI library from the HDF group wherever possible (it may still
> > be necessary to have a small JNI library though as some calls appear to
> > be missing).
> 
> Thanks for your feedback.
>  
> > I will keep you updated.
> 
> This would be very helpful.  Just to let you know:  If you want to have
> JHDF5 distributed with the next stable Debian release the deadline for a
> fix would be about Christmas since there is a freeze at 5.1.2017 and the
> package needs 10 days from beeing uploaded to make it into the pool
> called "testing" where all release candidates are residing.
> 
> Kind regards and thanks for your cooperation

The hdf5 package now in Debian experimental builds the java wrapper
library shipped with hdf5-1.10: libhdf5-java, libhdf5-jni.

Thanks,

_g.

Bug#779482: severity of 779482 is grave

2015-10-29 Thread pini 
Control: tag -1 pending

Hi,

On Sat, 17 Oct 2015 14:12:26 +0200 Gilles Filippini  wrote:
> The release 2.3.2-1 in experimental was finally tested on a baremetal
> ppc64el machine, and it works [1]. Many thanks to Frédéric Bonnard.
> 
> [1] 

Release 2.3.2-3~exp4 in experimental was successfully tested on powerpc,
ppc64el, and s390x porter boxes.

Tony, can I upload to unstable? I'll then upload libjogl2-java and scilab.

Thanks,

_g.

Bug#798652: scilab: scilab doesn't work on ppc64el: could not find the Java configuration for the model <>

2015-10-04 Thread pini 
Control: block -1 by 779482

On Sun, 04 Oct 2015 00:43:53 +0200 Gilles Filippini  wrote:
> On Fri, 11 Sep 2015 16:40:40 +0200 Sylvestre Ledru
>  wrote:
> > Jogl has to be updated too. I think there is a familiar patch for another 
> > arch. 
> 
> No, this is gluegen2. And looking at the source I fail to see any
> ppc64el support. Then, is there still a point for scilab to build on
> ppc64el?

Actually this is #779482 [1].

[1] 

_g.

Bug#729767: H5detect failed to run on mips64el

2014-09-04 Thread pini 
Hi,

Does this failure still occur with release 1.8.13 in unstable?
If so an access to a porterbox would be appreciated.

Thanks,

_g.

YunQiang Su a écrit , Le 17/11/2013 02:40:
 Package: hdf5
 Version: 1.8.11-5
 
 I try to build hdf5 on mips64el, while H5detect failed to build.
 If you need to use porterbox, please contact with me.
 
 syq@thor ./debian/build/src/H5detect
 
  ~/hdf5/hdf5-1.8.11
 /* Generated automatically by H5detect -- do not edit */
 
 
 
 /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
  * Copyright by The HDF Group.   *
  * Copyright by the Board of Trustees of the University of Illinois. *
  * All rights reserved.  *
  *   *
  * This file is part of HDF5.  The full HDF5 copyright notice, including *
  * terms governing use, modification, and redistribution, is contained in*
  * the files COPYING and Copyright.html.  COPYING can be found at the root   *
  * of the source code distribution tree; Copyright.html can be found at the  *
  * root level of an installed copy of the electronic HDF5 document set and   *
  * is linked from the top-level documents page.  It can also be found at *
  * http://hdfgroup.org/HDF5/doc/Copyright.html.  If you do not have  *
  * access to either file, you may request a copy from h...@hdfgroup.org. *
  * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
  *
  * Created:Nov 17, 2013
  *syq@thor
  *
  * Purpose:This machine-generated source code contains
  *information about the various integer and
  *floating point numeric formats found on this
  *architecture.  The parameters below should be
  *checked carefully and errors reported to the
  *HDF5 maintainer.
  *
  *Each of the numeric formats listed below are
  *printed from most significant bit to least
  *significant bit even though the actual bytes
  *might be stored in a different order in
  *memory. The integers above each binary byte
  *indicate the relative order of the bytes in
  *memory; little-endian machines have
  *decreasing numbers while big-endian machines
  *have increasing numbers.
  *
  *The fields of the numbers are printed as
  *letters with `S' for the mantissa sign bit,
  *`M' for the mantissa magnitude, and `E' for
  *the exponent.  The exponent has an associated
  *bias which can be subtracted to find the
  *true exponent.The radix point is assumed
  *to be before the first `M' bit. Any bit
  *of a floating-point value not falling into one
  *of these categories is printed as a question
  *mark.  Bits of integer types are printed as
  *`I' for 2's complement and `U' for magnitude.
  *
  *If the most significant bit of the normalized
  *mantissa (always a `1' except for `0.0') is
  *not stored then an `implicit=yes' appears
  *under the field description.  In thie case,
  *the radix point is still assumed to be
  *before the first `M' but after the implicit
  *bit.
  *
  * Modifications:
  *
  *DO NOT MAKE MODIFICATIONS TO THIS FILE!
  *It was generated by code in `H5detect.c'.
  *
  *-
  */
 
 [1]8971 illegal hardware instruction  ./debian/build/src/H5detect
 syq@thor gdb ./debian/build/src/H5detect
 
  ~/hdf5/hdf5-1.8.11
 GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1)
 Copyright (C) 2013 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show copying
 and show warranty for details.
 This GDB was configured as mips64el-linux-gnuabi64.
 For bug reporting instructions, please see:
 http://www.gnu.org/software/gdb/bugs/...
 Reading symbols from
 /home/syq/hdf5/hdf5-1.8.11/debian/build/src/H5detect...done.
 (gdb) r
 Starting program: /home/syq/hdf5/hdf5-1.8.11/./debian/build/src/H5detect
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library
 /lib/mips64el-linux-gnuabi64/libthread_db.so.1.
 
 Program received signal SIGBUS, Bus error.
 0x00fff7f8defc in raise () from 
 /lib/mips64el-linux-gnuabi64/libpthread.so.0
 (gdb) backtrace
 #0  0x00fff7f8defc in raise () from
 /lib/mips64el-linux-gnuabi64/libpthread.so.0
 #1  0x00012000220c in verify_signal_handlers
 (signum=signum@entry=10,

Bug#759929: shouldn't libhdf5.so still be avail and managed via alternatives

2014-09-02 Thread pini 
Control: unblock -1 by 759794

On Sun, 31 Aug 2014 13:39:27 +0200 Gilles Filippini p...@debian.org wrote:
 Control: block -1 by 759794
 
 Gilles Filippini a écrit , Le 31/08/2014 12:59:
  Gilles Filippini a écrit , Le 31/08/2014 11:04:
  Hi Yaroslav,
 
  Yaroslav Halchenko a écrit , Le 31/08/2014 02:17:
  both ants and nifti2dicom (and probably others) recent FTBFS are due to
  recentish upload of hdf5 1.8.13+docs-8  which was previously only in
  experimental after its big RF in (1.8.13+docs-1) which stopped providing
  '/usr/lib/x86_64-linux-gnu/libhdf5.so' but provides separate builds for
  each flavor:
 
  /usr/lib/x86_64-linux-gnu/hdf5/mpich/libhdf5.so libhdf5-mpich-dev 
  [amd64]
  /usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5.so   libhdf5-openmpi-dev 
  [amd64]
  /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.solibhdf5-dev [amd64] 
 
  Gilles, I wondered, shouldn't there still be a
  /usr/lib/x86_64-linux-gnu/libhdf*.so* managed via alternatives, e.g. like
  blas/atlas do it?
 
  I didn't spot ants as a rdep oh hdf5. I'll have a look.
  About nifti2dicom, my previous tests reported no FTBFS after binNMUing
  vtk6. I'll have a look as well.
  
  It seems the FindITK.cmake macro reports the wrong path for hdf5
  libraries. Still investigating...
 
 It needs insighttoolkit4 beeing binNMUed. This is blocked by #759794
 
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759794

insighttoolkit4 was binNMUed for amd64. ants and nifti2dicom shouldn't
FTBFS anymore.

Thanks,

_g.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#759663: [pkg-octave/master] Disable java on mips.

2014-08-29 Thread pini 
On Fri, 29 Aug 2014 20:40:34 + =?utf-8?q?S=C3=A9bastien_Villemot?= 
sebast...@debian.org wrote:
 tag 759663 pending
 thanks
 
 Date: Fri Aug 29 22:38:31 2014 +0200
 Author: Sébastien Villemot sebast...@debian.org
 Commit ID: 4f87d1af82a202c3b142fa50fdb756bf65fa7b3b
 Commit URL: 
 http://anonscm.debian.org/gitweb/?p=pkg-octave/octave.git;a=commitdiff;h=4f87d1af82a202c3b142fa50fdb756bf65fa7b3b
 Patch URL: 
 http://anonscm.debian.org/gitweb/?p=pkg-octave/octave.git;a=commitdiff_plain;h=4f87d1af82a202c3b142fa50fdb756bf65fa7b3b
 
 Disable java on mips.
 
 Closes: #759663

Looking at the patch - IIUIC - it misses the change below in debian/control.

Thanks,

_g.


diff -Nru octave-3.8.2/debian/control octave-3.8.2/debian/control
--- octave-3.8.2/debian/control 2014-08-13 20:14:38.0 +
+++ octave-3.8.2/debian/control 2014-08-29 18:20:42.0 +
@@ -24,7 +24,7 @@
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, texinfo, octave-common (= 
${source:Version}),
  liboctave2 (= ${binary:Version}),
- default-jre-headless [!armhf !hurd-i386 !kfreebsd-amd64 
!kfreebsd-i386 !mipsel !sparc]
+ default-jre-headless [!armhf !hurd-i386 !kfreebsd-amd64 
!kfreebsd-i386 !mips !mipsel !sparc]
 Recommends: gnuplot-x11 | gnuplot-qt, libopenblas-base | libatlas3-base,
  pstoedit
 Suggests: octave-info,


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755167: fixed in cmor 2.9.1-4

2014-07-26 Thread pini 
reopen 755167
thanks

Alastair McKinstry a écrit , Le 25/07/2014 09:18:
 Source: cmor
 Source-Version: 2.9.1-4
 
 We believe that the bug you reported is fixed in the latest version of
 cmor, which is due to be installed in the Debian FTP archive.
 
 A summary of the changes between this version and the previous one is
 attached.
 
 Thank you for reporting the bug, which will now be closed.  If you
 have further comments please address them to 755...@bugs.debian.org,
 and the maintainer will reopen the bug report if appropriate.
 
 Debian distribution maintenance software
 pp.
 Alastair McKinstry mckins...@debian.org (supplier of updated cmor package)
 
 (This message was generated automatically at their request; if you
 believe that there is a problem with it please contact the archive
 administrators by mailing ftpmas...@ftp-master.debian.org)
 
 
 Format: 1.8
 Date: Thu, 24 Jul 2014 19:05:11 +0100
 Source: cmor
 Binary: libcmor2 libcmor-dev python-cmor
 Architecture: source amd64
 Version: 2.9.1-4
 Distribution: unstable
 Urgency: medium
 Maintainer: Alastair McKinstry mckins...@debian.org
 Changed-By: Alastair McKinstry mckins...@debian.org
 Description:
  libcmor-dev - Development files for Climate Model Output Rewriter
  libcmor2   - Climate Model Output Rewriter library
  python-cmor - Python interface to CMOR
 Closes: 754640 755167
 Changes:
  cmor (2.9.1-4) unstable; urgency=medium
  .
* Make additional flags  and pkgs a requirement for ppc64el only.
  Closes: #755167, #754640.
[snip]

I not sure that this change is correct. If I read correctly this
part of debian/rules:

ifeq ($(BUILD_ARCH_CPU), ppc64el)
NCLDFLAGS:=-lhdf5 -lm -lcurl $(NETCDF_LIBS) -lz -lidn -lrtmp -lgcrypt \
 -lgnutls -lgssapi_krb5 -llber -lldap_r -lgpg-error -ltasn1 
-lp11-kit \
 -lk5crypto -lkrb5support -lsasl2 -lkeyutils -lsqlite3
endif

%:
dh $@ --with python2

override_dh_auto_configure:
autoreconf -fiv
ln -sf  /usr/share/misc/config.sub
dh_auto_configure -- --disable-color --enable-verbose-test  --with-uuid 
--without-python \
UUIDLDFLAGS=-lossp-uuid UUIDFLAGS=-I/usr/include/ossp 
SZLIBFLAGS=nosz \
EXTRA_NCLDFLAGS=$(EXTRA_NCLDFLAGS) \
CFLAGS=$(CFLAGS) LDFLAGS=$(LDFLAGS)

then:
* why is NCLDFLAGS set for arch ppc64el only?
* I think the line EXTRA_NCLDFLAGS=$(EXTRA_NCLDFLAGS)
  should read EXTRA_NCLDFLAGS=$(NCLDFLAGS), or the NCLDFLAGS variable
  define above is useless.

Thanks in advance,

_g.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#638001: [maven-debian-helper] mh_resolve_dependencies could avoid to search POMs provided by this package

2014-05-13 Thread pini 
severity 638001 normal
thanks

Hi,

Giovanni Mascellani a écrit , Le 16/08/2011 15:23:
 Package: maven-debian-helper
 Version: 1.4.3
 Severity: minor
 
 Hi.
 
 A package of mine (msv) provide more than one POM file, some of which
 depend on each other. When compiling, mh_resolve_dependencies tries to
 locate to which package belong the dependencies listed in POM files and
 does so even for artifacts that are already provided by the package that
 is currently compiling.
 
 This behavior shown in the attached build log for msv:
 mh_resolve_dependencies executes dpkg --search to find artifacts that
 are provided by the package. This does not lead to build failures are
 bad packages, but makes the compilation longer than required, so it
 would be nice to fix it.

Raising severity because this broken behavior leads to incomplete
Depends fields: for each pom.xml file mh_resolve_dependencies will
abort at the first unresolved dependency.

Cheers,

_g.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732202: libhdf5-openmpi-dev: pathways for mpi.h not picked up with the linked include mpi.h

2013-12-24 Thread pini 

Hi,

Marc J. Driftmeyer a écrit , Le 15/12/2013 17:00:

Package: libhdf5-openmpi-dev
Version: 1.8.11-5
Severity: normal

Dear Maintainer,

I installed libhdf5-openmpi-dev to build against Field3D GPU stack and wanting 
to build for parallel switched from hdf5 serial to hdf5 openmpi.

Result:

mpi.h not found.

Solution:

Edit H5public.h to change the following:

#include mpi.h

to

#include openmpi/mpi.h

Not sure if this is a proper workaround, but I can cleanly build Field3D now.


How about using CC=mpicc CXX=mpicxx instead?

Thanks,

_g.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#715959: [Mayhem] Bug report on hdf5-tools: gif2h5 crashes with exit status 139

2013-12-24 Thread pini 

Hi,

Alexandre Rebert a écrit , Le 10/07/2013 21:07:

Package: hdf5-tools
Version: 1.8.10-patch1-1
Severity: normal
User: may...@forallsecure.com
Usertags: mayhem

gif2h5 crashes with exit status 139. We confirmed the crash by
re-running it in a fresh debian unstable installation.

The attachment [1] contains a testcase (under ./crash) crashing the
program. It ensures that you can easily reproduce the bug. Additionally,
under ./crash_info/, we include more information about the crash such as
a core dump, the dmesg generated by the crash, and its output.

Regards,
The Mayhem Team (Alexandre Rebert, Thanassis Avgerinos, Sang Kil Cha, David 
Brumley, Manuel Egele)
Cylab, Carnegie Mellon University

[1] 
http://www.forallsecure.com/bug-reports/44229785e52406a1153f91ea5e404ea14fe736af/full_report


I fail to find a valid GIF file in your archive. This makes it difficult 
for me to understand the problem. Would you mind providing an actual GIF 
file?


Thanks in advance,

_g.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#704652: RFP: git-subtree -- subtree merge/split tool from git/contrib/subtree

2013-09-30 Thread pini 
Hi Jonathan,

Any news on this topic?
Thanks in advance,

_g.

Jonathan Nieder a écrit , Le 04/04/2013 06:04:
 Source: git
 Version: 1:1.8.2-1
 Severity: wishlist
 Control: submitter -1 Thom Hastings tghasti...@gmail.com
 
 Hi Thom,
 
 Thom Hastings wrote:
 
 any idea when the latest git will be put into the experimental branch for
 amd64? i need it to do git subtrees
 
 Debian experimental currently has git 1.8.2, which is the latest
 released version.  It doesn't install git-subtree to $PATH, though,
 and I suppose it should.  Filing a bug as a reminder.
 
 Thanks for writing,
 Jonathan
 
 
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#674821: Re: Bug#674821: xserver-xorg-input-tslib: undefined symbol: xf86XInputSetScreen reported when X loads tslib_drv.so

2013-05-06 Thread pini 
Hi,

Gianluigi Tiesi a écrit , Le 08/12/2012 04:57:
 On 12/05/12 01:24, Gianluigi Tiesi wrote:
 Package: xf86-input-tslib
 Followup-For: Bug #674821

 I've tested by commenting out the call and works without problems, to
 be sure I've instead
 made a patch using the code that was removed from xorg, so teorically
 it should behave like
 in xorg 1.11

 I've not directly tested the effect of the patch, but it should be ok,
 I'll report results asap

 Regards
 
 Hi, I've just tested the patch and it works fine for me, it would be
 nice to have the package in wheezy but I don't known exactly the policy

This patch isn't enough anymore to build for Jessie.
Please consider using the source package from Ubuntu [1] which solves
all the Xorg API changes related FTBSs so far.

[1] https://launchpad.net/ubuntu/+source/xf86-input-tslib/0.0.6-7build3

Many thanks in advance,

_g


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#625789: Bug #625789: dpkg-source: --extend-diff-ignore doesn't work as expected

2011-05-05 Thread pini 
Gilles Filippini a écrit , Le -10/01/-28163 20:59:
 Trying not to include .gitignore into my source package using a
 debian/source/local-options file with:
  extend-diff-ignore = '\.gitignore'
 
 It doesn't work:
  $ DIST=sid git-buildpackage --git-builder=git-pbuilder --git-ignore-new
  (...)
   dpkg-source -i(?:^|/)\.git(attributes)?(?:$|/.*$) -I.git -b 
 xf86-video-glamo-0.0.0+20100630.git16af3c00
  dpkg-source: info: using options from 
 xf86-video-glamo-0.0.0+20100630.git16af3c00/debian/source/local-options: 
 --extend-diff-ignore=\.gitignore
  dpkg-source: warning: no source format specified in debian/source/format, 
 see dpkg-source(1)
  dpkg-source: info: using source format `1.0'
  dpkg-source: info: building xf86-video-glamo using existing 
 xf86-video-glamo_0.0.0+20100630.git16af3c00.orig.tar.gz
  dpkg-source: info: building xf86-video-glamo in 
 xf86-video-glamo_0.0.0+20100630.git16af3c00-3.diff.gz
  dpkg-source: warning: the diff modifies the following upstream files: 
   .gitignore
  dpkg-source: info: use the '3.0 (quilt)' format to have separate and 
 documented changes to upstream files, see dpkg-source(1)
  dpkg-source: info: building xf86-video-glamo in 
 xf86-video-glamo_0.0.0+20100630.git16af3c00-3.dsc
   dpkg-genchanges -S 
 ../xf86-video-glamo_0.0.0+20100630.git16af3c00-3_source.changes
 
 It doesn't work from the command line either:
  $ rm xf86-video-glamo-0.0.0+20100630.git16af3c00/debian/source/local-options 
  $ dpkg-source -i'(?:^|/)\.git(attributes)?(?:$|/.*$)' 
 --extend-diff-ignore='\.gitignore' -I.git -b 
 xf86-video-glamo-0.0.0+20100630.git16af3c00/
  dpkg-source: avertissement: aucun format source indiqué dans 
 debian/source/format, voir dpkg-source(1)
  dpkg-source: info: utilisation du format source « 1.0 »
  dpkg-source: info: construction de xf86-video-glamo à partir de 
 xf86-video-glamo_0.0.0+20100630.git16af3c00.orig.tar.gz
  dpkg-source: info: construction de xf86-video-glamo dans 
 xf86-video-glamo_0.0.0+20100630.git16af3c00-3.diff.gz
  dpkg-source: avertissement: le fichier de différences modifie les fichiers 
 amont suivants : 
   .gitignore
  dpkg-source: info: choisissez le format « 3.0 (quilt) » pour utiliser des 
 modifications séparées et documentées dans les sources amont, voir 
 dpkg-source(1)
  dpkg-source: info: construction de xf86-video-glamo dans 
 xf86-video-glamo_0.0.0+20100630.git16af3c00-3.dsc
 
 But forcing everything into one diff-ignore regex does work:
  $ dpkg-source -i'(?:^|/)\.git(attributes)?(?:$|/.*$)|\.gitignore' -I.git -b 
 xf86-video-glamo-0.0.0+20100630.git16af3c00/
  dpkg-source: avertissement: aucun format source indiqué dans 
 debian/source/format, voir dpkg-source(1)
  dpkg-source: info: utilisation du format source « 1.0 »
  dpkg-source: info: construction de xf86-video-glamo à partir de 
 xf86-video-glamo_0.0.0+20100630.git16af3c00.orig.tar.gz
  dpkg-source: info: construction de xf86-video-glamo dans 
 xf86-video-glamo_0.0.0+20100630.git16af3c00-3.diff.gz
  dpkg-source: info: construction de xf86-video-glamo dans 
 xf86-video-glamo_0.0.0+20100630.git16af3c00-3.dsc

The attached patch appears to solve my problem, with
--extend-diff-ignore specified either from the command line or from a
debian/source/[local-]options file.

Rationals are:
* options from the command line should be interpreted first
* then should come options from debian/source/options
* and finally options from debian/source/local-options
* --extend-diff-ignore should actually extend diff-ignore instead of the
default diff-ignore regex.

Please consider including it.

Thanks,

_g.
--- /usr/bin/dpkg-source	2011-04-16 03:54:49.0 +0200
+++ ./dpkg-source	2011-05-06 01:41:43.0 +0200
@@ -113,7 +113,7 @@
 	options = qr/^--(?:format=|unapply-patches$|abort-on-upstream-changes$)/,
 	local-options = qr/^--format=/,
 };
-foreach my $filename (local-options, options) {
+foreach my $filename (options, local-options) {
 	my $conf = Dpkg::Conf-new();
 	my $optfile = File::Spec-catfile($dir, debian, source, $filename);
 	next unless -f $optfile;
@@ -122,7 +122,7 @@
 	if (@$conf) {
 	info(_g(using options from %s: %s), $optfile, join( , @$conf))
 		unless $options{'opmode'} eq --print-format;
-	unshift @options, @$conf;
+	push @options, @$conf;
 	}
 }
 }
@@ -157,7 +157,11 @@
 } elsif (m/^-(?:i|-diff-ignore(?:$|=))(.*)$/) {
 $options{'diff_ignore_regexp'} = $1 ? $1 : $Dpkg::Source::Package::diff_ignore_default_regexp;
 } elsif (m/^--extend-diff-ignore=(.+)$/) {
-	$Dpkg::Source::Package::diff_ignore_default_regexp .= |$1;
+if ($options{'diff_ignore_regexp'}) {
+$options{'diff_ignore_regexp'} .= |$1;
+} else {
+$options{'diff_ignore_regexp'} = $Dpkg::Source::Package::diff_ignore_default_regexp . |$1;
+}
 } elsif (m/^-(?:I|-tar-ignore=)(.+)$/) {
 push @{$options{'tar_ignore'}}, $1;
 } elsif (m/^-(?:I|-tar-ignore)$/) {

Bug#561280: libgps19: libgps_unpack never exits, eating 80+% cpu with a never ending loop

2009-12-15 Thread Pini 
Package: libgps19
Version: 2.90-2
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I'm bitten by a libgps19 bug which makes it fall into a never ending loop 
inside libgps_unpack. This bug has been confirmed on IRC by upstream and is 
fixed in latest SVN.

I set the severity to serious since:
* it breaks at least navit
* the bug is fixed upstream
- - I propose to keep this version away from testing and to wait for the next 
one. We shouldn't wait too long.

Thanks,

_Gilles.



- -- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libgps19 depends on:
ii  libc6 2.10.2-2   GNU C Library: Shared libraries
ii  libgcc1   1:4.4.2-3  GCC support library
ii  libstdc++64.4.2-3The GNU Standard C++ Library v3

libgps19 recommends no packages.

libgps19 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBCAAGBQJLKALOAAoJEO/obGx//s+Dx+UH/3a+YsZNiAbzDuKF0dwJI6yM
qdbOL5AvD22VreVRxNLIKe5KdRSS8YzUWMZzzrW5LaKoCnF3eAkDo+tQyoPvim1t
GW8OeAhb+ejCBcu0ltUTw38MUg7s9M5ztMesos9WvquXtv1vtErH2CVT7hn+axaX
UpHw3tHugoSH8swb4JuWROEO8u1H5gF9SaPEPGeMoi4n+DV9jmWw1etXy77kqJjG
WrxaTBlFzg97JMJh8l6huPt7DGL5lOFDKsEEOHMlB7IOfhXmAuPjj+cdrWH55ETk
kleh5abM0rayXHMz8QSbNkKkeUaCA3w1AT7SnMZ+8GUKfaDhlsbC2UDuwOKdGfk=
=ZAUS
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#560694: debian-maintainers: Please remove Gilles Filippini as a Debian Maintainer

2009-12-11 Thread Pini 
Package: debian-maintainers
Version: 1.64
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I'm now a DD. Please remove my key from the Debian Maintainers keyring. Jetring 
changeset attached.

Thanks in advance.

_Gilles.


- -- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBCAAGBQJLIko9AAoJEO/obGx//s+DQAkH/0o+0yKneYJxnaW1QtIfPkjY
0RNEE3HiC1Bl+DeUW7MYA00bBQUblQzjwfYAxtyvG7sMW4qILQSEilErlvCo/zWW
Yk8/c3qXCZaviB6ZYVxAVERkHoja5vy5wB6wn7Rrin6jSLPMi0FRgkuEIbiTY6Dw
o1R1oynVHE53zT8+IHbowINvTuCmzulCErZD0Y7umtzAQoPurtC/60Gw+k2mfvjz
qWvCSEFwH4H9tcKd/t3sFuu/ZQZnkTKc/I7wIJPphlIcptYI2UWEcOUNXmjJwaWB
cxjk4PhQIdgUPOznR3CLzZUuOKzjNH9Tj1PyCGnL0WLYJfTiTCI6+pCcjNPkiGQ=
=0QRf
-END PGP SIGNATURE-
Comment: Remove Gilles Filippini gilles.filipp...@free.fr as a Debian 
Maintainer
Date: Fri, 11 Dec 2009 13:55:29 +0100
Action: delete-key EFE86C6C7FFECF83
Data: y

Bug#527841: Re: Bug#527841: [navit] split configuration file

2009-09-28 Thread pini 
tags 527841 + wontfix
thanks

Hi,

Gilles Filippini a écrit :
 Jocelyn Delalande a écrit :
 Configuration file (/etc/navit/navit.xml) is far too large (4425 lines)
 to be edited by humanoids. Who cares about the color of a can bin while
 he just wants to enable his GPS device in navit ?

 So I think navit.xml should be splitted, *at least* for styles (called
 layout). Here is a proposal :

 etc/
 `-- navit
|-- layouts
|   |-- bike.xml
|   |-- car-dark.xml
|   |-- car.xml
|   `-- t...@h.xml
|-- mapsets
|   |-- garmin.xml
|   |-- openstreetmap.xml
|   `-- reiserplanner.xml
|-- navit.xml
`-- vehicleprofiles
|-- bike.xml
|-- car.xml
|-- horse.xml
`-- pedestrian.xml

 It gives navit.xml  200 lines.
 Inclusions can be done using xi:include directives.

 What do you think about it ?
 
 Good idea, but it's more related to upstream dev than to debian
 packaging. Navit is still a young app and navit.xml is expected to
 evolve significantly in the future.
 Anyway, I've forwerded your request to upstream:


Upstream has closed the ticket[0] with a /won't fix/ answer:
 It has been discussed once more, and navit.xml will be kept as it is for
 now. Some day it should be written from the gui and splitting it up will
 make that quite hard.

 Until then, the file can be split for your own convenience (multiple maps,
 multiple OSD, easier upgrading) using xi:include.

Tagging /wontfix/ as well.

Thanks,

_Gilles.

[0] http://trac.navit-project.org/ticket/373



signature.asc
Description: OpenPGP digital signature

Bug#521037: courier: patch proposal

2009-09-23 Thread pini 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

tags 521037 + patch
thanks

Hi,

The problem is that maildrop and courier-base, which both provide an
alternative for /usr/share/man/man5/maildir.courier.5.gz, don't name
it the same way:
* courier:  maildir.5
* maildrop: maildir.5.gz

BTW same goes for maildirquota.7.gz.

IMHO which one is right is not real big deal here, while I'd prefer
the maildrop's way. Please find below a patch proposal in this respect.

Thanks,

_Gilles.

diff -u courier-0.61.2/debian/courier-base.prerm 
courier-0.61.2/debian/courier-base.prerm
- --- courier-0.61.2/debian/courier-base.prerm
+++ courier-0.61.2/debian/courier-base.prerm
@@ -21,8 +21,8 @@
   for binary in maildirmake deliverquota makedat; do
   update-alternatives --remove $binary /usr/bin/$binary.courier
   done
- -  update-alternatives --remove maildir.5 
/usr/share/man/man5/maildir.courier.5.gz
- -  update-alternatives --remove maildirquota.7 
/usr/share/man/man7/maildirquota.courier.7.gz
+  update-alternatives --remove maildir.5.gz 
/usr/share/man/man5/maildir.courier.5.gz
+  update-alternatives --remove maildirquota.7.gz 
/usr/share/man/man7/maildirquota.courier.7.gz
 fi
 
 #DEBHELPER#
diff -u courier-0.61.2/debian/courier-base.postinst 
courier-0.61.2/debian/courier-base.postinst
- --- courier-0.61.2/debian/courier-base.postinst
+++ courier-0.61.2/debian/courier-base.postinst
@@ -25,12 +25,12 @@
update-alternatives --install /usr/bin/deliverquota deliverquota 
/usr/bin/deliverquota.courier 10 \
   --slave /usr/share/man/man8/deliverquota.8.gz 
deliverquota.8.gz /usr/share/man/man8/deliverquota.courier.8.gz
# alternative for maildir
- - update-alternatives --install /usr/share/man/man5/maildir.5.gz 
maildir.5 /usr/share/man/man5/maildir.courier.5.gz 5
+   update-alternatives --install /usr/share/man/man5/maildir.5.gz 
maildir.5.gz /usr/share/man/man5/maildir.courier.5.gz 5
# alternative for maildirmake
 update-alternatives --install /usr/bin/maildirmake maildirmake 
/usr/bin/maildirmake.courier 5 \
   --slave /usr/share/man/man1/maildirmake.1.gz 
maildirmake.1.gz /usr/share/man/man1/maildirmake.courier.1.gz
# alternative for maildirquota
- - update-alternatives --install /usr/share/man/man7/maildirquota.7.gz 
maildirquota.7 /usr/share/man/man7/maildirquota.courier.7.gz 5
+   update-alternatives --install /usr/share/man/man7/maildirquota.7.gz 
maildirquota.7.gz /usr/share/man/man7/maildirquota.courier.7.gz 5
# alternative for makedat
update-alternatives --install /usr/bin/makedat makedat 
/usr/bin/makedat.courier 5 --slave /usr/share/man/man1/makedat.1.gz 
makedat.1.gz /usr/share/man/man1/makedat.courier.1.gz
 fi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAEBCAAGBQJKugytAAoJEO/obGx//s+DyLkH/3L4Juzyl2yRq7QGbIxCb638
Yn0oRqd8IvBe6Jf10INwFDmTfB+96M2vIWxQIj0nruWoI8K8eBh1l37bZGdMdXl1
ClNkoVKtG+uHvIcizNY8MoMuVGD3HWszkjmuaLPq9K995QxvHk5VBesoK5DreH9X
VtcOBvQN90NZRaI/4Soo2LLTTeFUH0ThJxffMmlFdeQGj0lFtoTerS/MuZsTxXE6
RvWdguGN0aBfwKCmaiLDn4+Szn0uzAT4X1clX+EfL3fKt12ZkZALpSyZPUcqZZBK
8I7T8h8f3403UOXUiOa5ojRtI2AgS0F5D5PruwEHnvUfyfK9Wq1JLks9JpKIcyM=
=NLEQ
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548116: developers-reference: Section 3.7 - insert a reminder to retire from teams

2009-09-23 Thread Pini 
Package: developers-reference
Version: 3.4.3
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Section 3.7 of Developers' Reference lists the steps to retire from
the Debian project.

I suggest to insert, in second position into this list, a reminder to
retire from Debian teams as well.

Please find attached the corresponding patch.

Thanks,

_Gilles.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAEBCAAGBQJKupXyAAoJEO/obGx//s+D7+IH/i5Sq4/F0ztHEZmH9vX7XNS7
G7j1JBroPglrzwLIoFMSRUdU1MVA0QoyqRAlYe8fowjay5vjn8bd/3xPTM8clUMB
9+zmGo0wdmW5Xre1ZcfoY8smkaWIrzcgDmoghOzTRAztRWc/Y/9W98ufwW3/cWbk
MYweBCOmRqyx/9NctyQSQp4Ds9nfbts8t2QdBFp784h7w3fGTYe3TTCtZmmO/bvr
lVq6KXJnRJ01MMsae6WPaYa+y2l9Zvbr5/17nR6uNrHAgyLziB1YMM8x+LRfln2F
94mjy3hNQ8hCBVMILjTd+3kn9gSKUu+SkN2dSh7bmydFZS9PoDhYGSqpazU94Fk=
=qPt2
-END PGP SIGNATURE-
diff -Nru developers-reference-3.4.3/developer-duties.dbk developers-reference-3.4.3/developer-duties.dbk
--- developers-reference-3.4.3/developer-duties.dbk	2009-06-24 18:01:42.0 +0200
+++ developers-reference-3.4.3/developer-duties.dbk	2009-09-23 22:40:03.0 +0200
@@ -202,6 +202,11 @@
 /listitem
 listitem
 para
+Retire from the Debian teams you're member of.
+/para
+/listitem
+listitem
+para
 Send an gpg-signed email about why you are leaving the project to
 emaildebian-private@lists-host;/email.
 /para

Bug#534767: [navit] Not possible to enter GPS coordinates

2009-06-29 Thread pini 
Hi,

Michael Stapelberg a écrit :
 Package: navit
 Severity: normal
 
 Many events provide you with the GPS coordinates. It is _by far_ easier to
 copypaste GPS coordinates than to lookup street/name and hope that navit (or
 any other software in that respect) correctly maps street/name to their
 position.
 
 There seems to be no possibility to enter GPS coordinates into navit or at
 least it is sufficiently well hidden so that users will never use it. Please
 enlighten me on how to do it or implement it if it’s not possible at the
 moment.

Request forwarded upstream.
Actually there was a ticket opened for this feature already[1].

Thanks,

_Gilles.

[1] http://trac.navit-project.org/ticket/198



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532382: debian-maintainers: DM application for Gilles Filippini

2009-06-08 Thread Pini 
Package: debian-maintainers
Version: 1.59
Severity: normal

Hi,

Please add me gilles Filippini gilles.filipp...@free.fr to the debian 
maintainers keyring.
Changeset attached.

Thanks in advance,

_Gilles.
Comment: Add Gilles Filippini gilles.filipp...@free.fr as a Debian Maintainer
Date: Tue, 09 Jun 2009 00:33:15 +0200
Action: import
Recommended-By: 
  Erik Schanze er...@debian.org
  Bernd Zeimetz b...@debian.org
Agreement: 
  http://lists.debian.org/debian-newmaint/2009/06/msg00016.html
Advocates: 
  http://lists.debian.org/debian-newmaint/2009/06/msg00024.html
  http://lists.debian.org/debian-newmaint/2009/06/msg00017.html
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1.4.9 (GNU/Linux)
  
  mQENBEodEFABCACzPp/Veq9REEcswZBugoAAFi/1MFHPTHV9iZmnz6YOmjPwupYo
  gaAKntpqArCM72LOf+1XSbWVf300nzvus+bmGLXECUuCtjZmIuWraMZMaqSZE5yd
  pFjf2BQ5rPDSSIWgLQpn6Or4OOcoa4QNPnLr2yzx2yIAd/be2ke9Xwq9f+5moRb/
  JGM6IDtXvJnmelglNLtWW+T+aLMk4VU0TSVmqdf4e90SyGjCkTKltLOP4vv/J9Uh
  /0uIwx6Kb9RQqmJh+uDGpEQFeDfHsZEqK6yL0Jhfby2OdS9m/s6O+849YVY1wGLQ
  scgLu+ynlBZDykX6kFdPmScY/49tpf/Rl1ENABEBAAG0K0dpbGxlcyBGaWxpcHBp
  bmkgPGdpbGxlcy5maWxpcHBpbmlAZnJlZS5mcj6JAUAEEwECACoCGw8CHgECF4AC
  GQEFCwkIBwMFFQoJCAsFFgIDAQAFAkosQvYFCQHwZaUACgkQ7+hsbH/+z4N3Ugf+
  KQp5FojCWRgqwFVAEqlQkkwZobCWnaxl1trtrbUhpFzG8wIBWtZeBzRhgjMZGG4X
  y3ADFyRim0482waQEk/AM2g0R8DoBlXX/9lY1szBH5mB8OtpDvOd5sZ0eiedydeb
  vNw3+Hrj+6sEM75e7XzvyOGRIAe0H9qb2A3cCQEwrh3wpHIFL8SSe+O4+b13hOF4
  Pow5UkcH353yM5WBpXp6Dr3oQO0T3/YtMkudHb+nri8ryn5ZqudBA8yqHFCjc23P
  o9nAQVCE78dxzaOT8Qq/dQ3nEjK8ysvfNAv6Kz5MHNQNlnEd7tS/IDfezNsZMwyy
  gpulvaxCm+Hn6femHG51MohGBBARAgAGBQJKHScCAAoJEDbj7vwNg8xpEe4An2Gc
  tQUMf+3ambvI4R+h6g08dagAAJ9iqLbnMZOML0WaYyQDR7NonKDsAYhGBBARAgAG
  BQJKIj4XAAoJEK0pWuHXX4UzrpEAnR+rkoh0CWttobLLPs3UricYnbmRAJsE72bV
  US3Pzu1SRURRBqOJYvmR4A==
  =S+jw
  -END PGP PUBLIC KEY BLOCK-

Bug#531902: ITP: syrthes -- Transient thermal simulations in complex solid geometries

2009-06-04 Thread Pini 
Package: wnpp
Severity: wishlist
Owner: Pini gilles.filipp...@free.fr

* Package name: syrthes
  Version : 3.4.2
  Upstream Author : EDF RD syrthes-supp...@edf.fr
* URL : http://rd.edf.com/syrthes
* License : GPL
  Programming Lang: Fortran, C
  Description : Transient thermal simulations in complex solid geometries

SYRTHES is a general purpose thermal software developed at EDF RD which
models conduction and radiation heat transfers in complex geometries.
..
SYRTHES can be used coupled with the computational fluid dynamics (CFD)
Code_Saturne.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#527841: Re: Bug#527841: [navit] split configuration file

2009-05-22 Thread pini 
Gilles Filippini a écrit :
 Anyway, I've forwerded your request to upstream:

Here is the link:
http://trac.navit-project.org/ticket/373

_Gilles.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#526984: shapelib: Please update the source package to upstream CVS

2009-05-04 Thread Pini 
Package: shapelib
Version: 1.2.10-4.1
Severity: wishlist

Hi,

The shapelib release currently in Debian is 6 years old: it was released
by upstream on 07/04/2003.

Since then, upstream CVS has been evolving with some enhancements. I
include below the CVS logs for 2008.

Anonymous upstream CVS access:
 CVSROOT=:pserver:cvsa...@cvs.maptools.org:/cvs/maptools/cvsroot
 The module name is shapelib.

Please update the source package to the lastest CVS snapshot.

Thanks in advance.

_Gilles.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

--- CVS logs for 2008 ---

revision 1.65
date: 2008-11-12 16:39:50 +0100;  author: fwarmerdam;  state: Exp;  lines: +3 
-0;
improve safety in face of buggy .shp file.

revision 1.64
date: 2008-11-12 15:28:15 +0100;  author: fwarmerdam;  state: Exp;  lines: +7 
-1;
DBFCreateField() now works on files with records

revision 1.63
date: 2008-11-11 18:47:10 +0100;  author: fwarmerdam;  state: Exp;  lines: +5 
-0;
added DBFDeleteField() function

revision 1.62
date: 2008-03-14 06:25:32 +0100;  author: fwarmerdam;  state: Exp;  lines: +5 
-0;
Correct crash on buggy geometries (gdal #2218)

revision 1.61
date: 2008-01-16 21:05:12 +0100;  author: bram;  state: Exp;  lines: +9 -0;
Add file hooks that accept UTF-8 encoded filenames on some platforms.  Use 
SASetupUtf8Hooks
 tosetup the hooks and check SHPAPI_UTF8_HOOKS for its availability.  
Currently, this
 is only available on the Windows platform that decodes the UTF-8 filenames to 
wide
 character strings and feeds them to _wfopen and _wremove.

revision 1.60
date: 2008-01-10 17:35:31 +0100;  author: fwarmerdam;  state: Exp;  lines: +5 
-0;
avoid _ prefix on #defined symbols (bug 1840)

revision 1.59
date: 2008-01-03 18:48:02 +0100;  author: bram;  state: Exp;  lines: +27 -0;
in DBFCreate, use default code page LDID/87 (= 0x57, ANSI)
instead of LDID/3.  This seems to be the same as what ESRI
would be doing by default.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#451561: Re: Bug#451561: Navit

2009-02-13 Thread pini 
Hi,

Bernd Zeimetz a écrit :
 Hi,
 
 the (not finished) packaging is available at
 http://git.debian.org/?p=collab-maint/navit.git;a=summary
 
 We need to decide in how many sub-packages the package should be
 splitted, and so on...
 
 Patches are welcome :)

I've been unofficially debian packaging Navit for the OpenMoko
FreeRunner since late December 2008.
I started from the Carsten Wolff's eee packages available on the
yet-another-geek repository[0]

While there's still a lot of work before attempting an upload to
unstable, I think my package is now in good shape enough to be shared.
So here it is, on my repository[1].

I really want to see Navit in Debian and I intend to continue my work
about it.

May we share our works using the git repo you've pointed above, or do
you prefer I take over this ITP?

Please tell me.

Thank in advance,

-- Gilles.

[0]
http://www.yet-another-geek.org/5-Introducing-my-eeePC-package-repository.html
[1] deb-src http://pini.free.fr/debian unstable main



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#489966: dupload: upload of .changes file results in a 0 sized file

2008-07-08 Thread Pini 
Package: dupload
Version: 2.6.4
Severity: grave
Justification: renders package unusable

Hello,

I recently tried to upload a new release of my nted package to
mentors.debian.net. While the upload didn't report any error my package
won't appear on mentors.debian.net.

I tried several times, using this command line:
$ dupload -f -t mentors debian/dists/unstable/nted_0.26.1-1_i386.changes

No error reported. I finaly decided to have a look at the FTP server.
And I saw that all my package files but the .changes were present there.
The .changes was in the oldchanges directory with size = 0.

I then tried to upload the .changes file with a different name using
FTP. It appeared with the correct size. Then I renamed it to its correct
name (nted_0.26.1-1_i386.changes) and my package was suddenly
proccessed.

I suggest to slightly modify dupload so that the .changes file is first
uploaded with its name changed (say: .changes.tmp) and renamed
afterward. This to ensure the complete upload before starting the
processing.

Thanks in advance.

Gilles.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dupload depends on:
ii  perl  5.10.0-11  Larry Wall's Practical Extraction 
ii  perl-modules [libnet-perl]5.10.0-11  Core Perl modules

Versions of packages dupload recommends:
ii  openssh-client1:4.7p1-12 secure shell client, an rlogin/rsh

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#444673: ITP: nted -- A new musical score editor for Linux

2007-09-30 Thread Pini 
Package: wnpp
Severity: wishlist
Owner: Pini [EMAIL PROTECTED]

* Package name: nted
  Version : 0.6.1
  Upstream Author : Jan Anders [EMAIL PROTECTED]
* URL : 
http://vsr.informatik.tu-chemnitz.de/~jan/noteedit/noteedit.html
* License : GPL
  Programming Lang: C++
  Description : A WYSIWYG musical score editor for Linux

NtED is a musical score editor for Linux. It intends to be really
WYSIWYG (what you see on the screen is exactly what you get on printer output).
..
Features:
- Distribution of the musical symbols on pages and systems
- Up to 4 voices per staff
- N-tuplets 1  N  14
- Direct replay, whereby: Configurable music instruments per staff
- Export midi
- Export PostScript
- Antialiasing 
..
NtED is a promising young app under heavy developpement.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#436276: Problem still annoying - Workaround

2007-09-22 Thread pini 

Hello,

I've had the same problem here on etch amd64.
As mentionned just above, FileZilla runs fine after closing the error 
message. But this is still annoying for our users.
As a quick and dirty workaround I've added this line to /etc/environment 
to get rid of the error:


FZ_FZSFTP=/usr/bin/fzsftp

--
_gilles.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]