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#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#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-rc-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-rc-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-rc-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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



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-rc-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]