Accepted elfutils 0.131-1 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 15 Dec 2007 20:31:14 +0100
Source: elfutils
Binary: libasm-dev libdw-dev elfutils libelf1 libasm1 libelf-dev libebl-dev
Architecture: source amd64
Version: 0.131-1
Distribution: unstable
Urgency: low
Maintainer: Kurt Roeckx [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 elfutils   - collection of utilities to handle ELF objects
 libasm-dev - libasm development libraries and header files
 libasm1- library with a programmable assembler interface
 libdw-dev  - library that provides access to the DWARF debug information
 libebl-dev - static library providing higher-level ELF access functionality
 libelf-dev - libelf1 development libraries and header files
 libelf1- library to read and write ELF files
Closes: 452428 455878
Changes: 
 elfutils (0.131-1) unstable; urgency=low
 .
   * New usptream version. (Closes: #455878)
 - ebl_core_note() changed function arguments.
 - libelf: Add functions: gelf_getauxv(), gelf_update_auxv(),
   gelf_getnote(), elf_getdata_rawchunk().
   removed gelf_rawchunk(), gelf_freechunk()
 - Changed some types from off_t to off64_t.  The library
   was always build with LFS, so it's just a correction of the types.
   * merge patches
   * arm, hppa and mips backend: Use dwarf_attr_integrate() instead of
 dwarf_attr(), and dwarf_hasattr_integrate() instead of dwarf_hasattr().
   * Add patch from Aurelien Jarno [EMAIL PROTECTED] to support
 GNU/kFreeBSD  (Closes: #452428)
Files: 
 be545fc4d1b22d8db934c0918893700e 752 libs optional elfutils_0.131-1.dsc
 f7963fba80c6f74cd6c4990d2a76d121 1412328 libs optional 
elfutils_0.131.orig.tar.gz
 3e375ac7eb12995895e86e2f161a934c 225562 libs optional elfutils_0.131-1.diff.gz
 fba193e55cc50f052a499ded1413aa94 660674 utils optional 
elfutils_0.131-1_amd64.deb
 f8f61af04add4d2c19d7630c346736d0 42540 libs optional libelf1_0.131-1_amd64.deb
 6883eebdb5cbd97c9e768ab1aa963d7c 59944 libdevel optional 
libelf-dev_0.131-1_amd64.deb
 e301fd5af69d3da831b9e03750028cd5 71400 libdevel optional 
libebl-dev_0.131-1_amd64.deb
 079ddfbd3cf1bf02cb19d269992d4049 96970 libdevel optional 
libdw-dev_0.131-1_amd64.deb
 d340aed84e0bca5b35992f20cf37520e 20592 libs optional libasm1_0.131-1_amd64.deb
 c14e34e39ad116c179ff89681683f5c4 23316 libdevel optional 
libasm-dev_0.131-1_amd64.deb

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

iD8DBQFHZDY9QdwckHJElwsRAvLRAKCVwotc6sVRiWlujBOd5BOcS9G7/wCgv1y5
Z9b4q1SGCDcnOzJgKB00v28=
=Yvwm
-END PGP SIGNATURE-


Accepted:
elfutils_0.131-1.diff.gz
  to pool/main/e/elfutils/elfutils_0.131-1.diff.gz
elfutils_0.131-1.dsc
  to pool/main/e/elfutils/elfutils_0.131-1.dsc
elfutils_0.131-1_amd64.deb
  to pool/main/e/elfutils/elfutils_0.131-1_amd64.deb
elfutils_0.131.orig.tar.gz
  to pool/main/e/elfutils/elfutils_0.131.orig.tar.gz
libasm-dev_0.131-1_amd64.deb
  to pool/main/e/elfutils/libasm-dev_0.131-1_amd64.deb
libasm1_0.131-1_amd64.deb
  to pool/main/e/elfutils/libasm1_0.131-1_amd64.deb
libdw-dev_0.131-1_amd64.deb
  to pool/main/e/elfutils/libdw-dev_0.131-1_amd64.deb
libebl-dev_0.131-1_amd64.deb
  to pool/main/e/elfutils/libebl-dev_0.131-1_amd64.deb
libelf-dev_0.131-1_amd64.deb
  to pool/main/e/elfutils/libelf-dev_0.131-1_amd64.deb
libelf1_0.131-1_amd64.deb
  to pool/main/e/elfutils/libelf1_0.131-1_amd64.deb


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

Re: -Wl,--as-needed considered possibly harmful

[Kurt Roeckx]

On Sun, Dec 09, 2007 at 07:23:00PM +0100, Josselin Mouette wrote:
 Hi,
 
 Le dimanche 09 décembre 2007 à 19:11 +0100, Bernhard R. Link a écrit :
  Just curing the symptoms instead of the problems will not help to get
  there any sooner.
 
 What if there is no problem?
 
 For example, pkg-config --libs gtk+-x11-2.0 will return, among others,
 -lglib-2.0 and -lm. And this is perfectly intentional. The former is
 here because you can assume glib functions are available when doing
 #include gtk/gtk.h. The latter is here because some macros need math
 functions. Still, many binaries using it don't need glib, and most of
 them don't need libm. There is nothing that can be done to avoid that,
 the only way is a check that removes the dependency if it isn't actually
 needed.

I can't seem to find any example of a macro calling a math functions?
I also can't find any header that includes math.h.  I do see
that libgtk-x11-2.0.so uses symbols from libm, like log10, atan2, sin,
cos, tan, pow, ceil.  But I can't find anything in the header files
that would use them.

It's gdk-pixbuf-2.0.pc and cairo.pc that have -lm in them.

Anyway, I think it is bad style to use macro's in public header
files that call functions from another library.  It's also easy
to replace them with real functions.  If there are such functions
being called I suggest you replace them.

What might be harder is avoiding the includes from other libraries
because you use types from the other library.  It would be great
if you didn't have to do that, and there are some ways to avoid that.


Kurt


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

Re: -Wl,--as-needed considered possibly harmful

[Kurt Roeckx]

On Mon, Dec 10, 2007 at 12:45:46AM +0300, Nikita V. Youshchenko wrote:
  Ok, let's consider another very simple case:
  libshout allows to perform streaming of speex, vorbis, and theora formats.
  
  Hence, when asking for the libs to link with, you got -lspeex and -ltheora
  since it's needed to cover all build cases.
  
  However, most of the applications don't need to link against theora and
  speex.
 
 Doesn't libshout reference symbols from libspeex and libtheora?
 
 If it does, resulting binary must be linked against both these libraries.

Where binary means libshout, yes.  The application does not
directly use libspeex and libtheora so should not have any undefined
symbols that are defined in either libspeex or libtheora.

 Unresolved symbols within binaries are really bad, because they will once
 be unexpectedly called (e.g. in some init or deinit or error-handling), and
 binary will crash, leaving user data unsaved.
 
 If it does not, then what for -lspeex and -ltheora are in the script output?

That is only useful for linking to a static version of libshout.


Kurt


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

Re: Injecting versions of build-deps in the deps

[Kurt Roeckx]

On Sun, Dec 02, 2007 at 05:11:52PM +0100, Loïc Minier wrote:
 
  An example would be package foobar3 build-depending on libfoo3 (=
  2.10.2).  When built against libfoo3 2.12.0-2 which provides a symbols
  file, the resulting binaries need symbols from libfoo3 (= 2.8.7) (as
  the symbols file say), the new system injects a dep on libfoo3 =
  max(2.10.2, 2.8.7) == 2.10.2.
If libfoo3 only provides shlibs and no symbol file and the shlibs
  claim a dep on libfoo3 (= 2.10), the system would inject a dep on
  libfoo3 = max(2.10.2, 2.10) == 2.10.2.

So you would need to build-depend on both libfoo-dev and libfoo3?


Kurt


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

Accepted libtool 1.5.24-2 (source all amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 27 Nov 2007 20:39:34 +0100
Source: libtool
Binary: libtool-doc libltdl3 libtool libltdl3-dev
Architecture: source amd64 all
Version: 1.5.24-2
Distribution: unstable
Urgency: low
Maintainer: Kurt Roeckx [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libltdl3   - A system independent dlopen wrapper for GNU libtool
 libltdl3-dev - A system independent dlopen wrapper for GNU libtool
 libtool- Generic library support script
 libtool-doc - Generic library support script
Closes: 441751
Changes: 
 libtool (1.5.24-2) unstable; urgency=low
 .
   * armel doesn't support fortran77, so disable it. (Closes: #441751)
   * Disable java on arm since it's unavailable.
Files: 
 a9ae2c1de6ed926594aa10ac8f5decf6 768 devel optional libtool_1.5.24-2.dsc
 6795d1c3449697ac9122827ca5843af3 13811 devel optional libtool_1.5.24-2.diff.gz
 86f81b75d7dd08cef6be81375c5dede7 348830 doc optional 
libtool-doc_1.5.24-2_all.deb
 29dee25ba22f6983b1d3f2a7dedc6f53 338372 devel optional 
libtool_1.5.24-2_amd64.deb
 b3e8f0f47bb7a9be5d35e394592ce743 176974 libs optional 
libltdl3_1.5.24-2_amd64.deb
 8e6b36a1be5945dbefcebf9312abc530 368618 libdevel optional 
libltdl3-dev_1.5.24-2_amd64.deb

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

iD8DBQFHTH88QdwckHJElwsRAhQkAKCzhpTMlzMCXIrkmNXO2UEZOreWEACg0D2j
mT09emONu2NbBi/B7KUAcak=
=d77H
-END PGP SIGNATURE-


Accepted:
libltdl3-dev_1.5.24-2_amd64.deb
  to pool/main/libt/libtool/libltdl3-dev_1.5.24-2_amd64.deb
libltdl3_1.5.24-2_amd64.deb
  to pool/main/libt/libtool/libltdl3_1.5.24-2_amd64.deb
libtool-doc_1.5.24-2_all.deb
  to pool/main/libt/libtool/libtool-doc_1.5.24-2_all.deb
libtool_1.5.24-2.diff.gz
  to pool/main/libt/libtool/libtool_1.5.24-2.diff.gz
libtool_1.5.24-2.dsc
  to pool/main/libt/libtool/libtool_1.5.24-2.dsc
libtool_1.5.24-2_amd64.deb
  to pool/main/libt/libtool/libtool_1.5.24-2_amd64.deb


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

Re: Early adopters of symbol based dependencies needed

[Kurt Roeckx]

On Tue, Nov 20, 2007 at 01:20:33PM -0500, Joey Hess wrote:
 Raphael Hertzog wrote:
  With debhelper 5.0.61, dh_makeshlibs will also call dpkg-gensymbols if it
  finds debian/package.symbols (or debian/package.symbols.arch). So
  for packages using debhelper, the only thing to do is to drop the right
  symbol file(s) at the right place and add build-depends on dpkg-dev (= 
  1.14.9)
  and debhelper (= 5.0.61).
 
 I suppose you'd also want to stop passing -V to dh_makeshlibs,
 since the symbol versioning should take care of setting the version.
 -V without any parameters is evil anyway.
 
 Although, what happens if a package is built against the library on
 a buildd that doesn't have the new dpkg-dev yet? It would generate a
 wrong unversioned dependency in this case.

I think dpkg-shlibdeps uses the symbols files if they're present, and 
the shlibs files if they're not.  So I would keep maintaining the -V
like you do now.  But at some point I'd like to remove it.


Kurt


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

Re: buildds: Authentication warning overridden.

[Kurt Roeckx]

On Sun, Nov 11, 2007 at 09:24:12AM -0800, Steve Langasek wrote:
 On Sun, Nov 11, 2007 at 01:27:14PM +0100, Florian Weimer wrote:
  * Wouter Verhelst:
 
   That's inevitable because http://incoming.debian.org is not signed; The
   update frequency of that repository (which is available only to buildd
   hosts by IP and/or password protection) makes that impossible -- or at
   least that's what I understood; you may want to check with ftp-masters
   for the full story.
 
  In this case, HTTPS should be used to download the packages, together
  with proper certificate validation.  This has got the added benefit that
  passwords aren't sent in the clear (well, unless an error occurs, but
  this is a separate issue).
 
 I believe the Packages file is only exposed over ssh

It's received over http.  The only thing ssh is used for is talking
to wanna-build.


Kurt


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

Accepted openssl 0.9.8g-3 (source i386)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 04 Nov 2007 21:49:00 +0100
Source: openssl
Binary: libssl-dev openssl libssl0.9.8-dbg libcrypto0.9.8-udeb libssl0.9.8
Architecture: source i386
Version: 0.9.8g-3
Distribution: unstable
Urgency: low
Maintainer: Debian OpenSSL Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libcrypto0.9.8-udeb - crypto shared library - udeb (udeb)
 libssl-dev - SSL development libraries, header files and documentation
 libssl0.9.8 - SSL shared libraries
 libssl0.9.8-dbg - Symbol tables for libssl and libcrypto
 openssl- Secure Socket Layer (SSL) binary and related cryptographic tools
Closes: 449200
Changes: 
 openssl (0.9.8g-3) unstable; urgency=low
 .
   * aes-586.pl: push %ebx on the stack before we put some things on the
 stack and call a function, giving AES_decrypt() wrong values to work
 with.  (Closes: #449200)
Files: 
 b00ebffc998068afe5df8f58f731bc54 797 utils optional openssl_0.9.8g-3.dsc
 24c7aa406a2bbe9f2db88ab6a518ffe4 49873 utils optional openssl_0.9.8g-3.diff.gz
 7d8800fa2cf196bfca6440ce2bffe499 1023332 utils optional 
openssl_0.9.8g-3_i386.deb
 471a2751719193377eab5159a229b1e4 2880648 libs important 
libssl0.9.8_0.9.8g-3_i386.deb
 da653fd8ae9b0f8c1f952867886ac1ad 577162 debian-installer optional 
libcrypto0.9.8-udeb_0.9.8g-3_i386.udeb
 874899213e1a1efd69fc73be3d9530dd 2079900 libdevel optional 
libssl-dev_0.9.8g-3_i386.deb
 01b0b541e7fbc15773cfd71ed67b8f4c 5359544 libdevel extra 
libssl0.9.8-dbg_0.9.8g-3_i386.deb
Package-Type: udeb

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

iD8DBQFHLjcjQdwckHJElwsRAuc6AKCqhgwRispnLIgyzMCDsV2GcqL4bQCeJBc6
ZwzfF18jrw/07YIkkG8ejVY=
=eJx4
-END PGP SIGNATURE-


Accepted:
libcrypto0.9.8-udeb_0.9.8g-3_i386.udeb
  to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8g-3_i386.udeb
libssl-dev_0.9.8g-3_i386.deb
  to pool/main/o/openssl/libssl-dev_0.9.8g-3_i386.deb
libssl0.9.8-dbg_0.9.8g-3_i386.deb
  to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8g-3_i386.deb
libssl0.9.8_0.9.8g-3_i386.deb
  to pool/main/o/openssl/libssl0.9.8_0.9.8g-3_i386.deb
openssl_0.9.8g-3.diff.gz
  to pool/main/o/openssl/openssl_0.9.8g-3.diff.gz
openssl_0.9.8g-3.dsc
  to pool/main/o/openssl/openssl_0.9.8g-3.dsc
openssl_0.9.8g-3_i386.deb
  to pool/main/o/openssl/openssl_0.9.8g-3_i386.deb


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

Re: Long-term mass bug filing for crossbuild support

[Kurt Roeckx]

On Tue, Nov 06, 2007 at 10:50:51PM +0100, Mike Hommey wrote:
  AFAIK there's nothing to be fixed here.  If you specify both --build and
  --host, autoconf sees this as a request for cross-compiling.  Of course,
  invoking the native compiler as a cross-compiler should /generally/ give the
  same results as invoking it as gcc, so it's entirely possible that it
  doesn't cause problems on your packages.
 
 The autoconf documentation says only if you enter both and they're
 different will it enter cross compiling mode.
 
 FWIW, the dh_make samples set both.

And it also has a bug against it to be changed:
http://bugs.debian.org/423707


Kurt


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

Re: Consistent handling of the DEB_BUILD_OPTIONS

[Kurt Roeckx]

On Tue, Nov 06, 2007 at 05:49:11PM +0200, Riku Voipio wrote:
 
 As I see what Neil wrote, nocheck (I prefer this over notest) affects
 only testsuite. As for *handling* packages that run compiled code during
 build.. well that's the reason why scratchbox was invented :)

I'm confused about how this all works.

As I see it, there are a few ways to do cross compiling:
- The old way were you set up cross toolchain, and you tell
  configure you want to cross build by adding --host to it's
  arguments.  This will change a few things in what configure does,
  like setting CC differently, not running AC_RUN_IFELSE but use
  some default instead.
- Emulate the cpu and pretend everything really is the host cpu.
  There is no need to call configure with --host.  We can't detect
  that we're doing a cross build.

In the first case it makes sense not to run the testsuite for things
that need to run on the host cpu. In the second case we can run it,
and I think we should.

From what I get from the description of scratchbox, it's doing the
second thing without actually emulating everything.  From what I get
it uses a cross toolchain on the real cpu and the rest is emulated.
I think I've been told that we can't detect that we're cross building
by looking at dpkg-architecture.  So I have to wonder why you don't want
to run the testsuite in that case.


Kurt


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

Re: Mandatory support for -nocheck in DEB_BUILD_OPTIONS

[Kurt Roeckx]

On Tue, Nov 06, 2007 at 05:47:17PM +, Neil Williams wrote:
 
 Making the last stage optional means that -nocheck achieves nothing,
 IMHO. If the maintainer chooses to allow 'make check' during the build,
 I believe that Policy should stipulate that the maintainer must ensure
 that 'make check' can be skipped when appropriate. I use make check in
 some of my own packages, it is useful on things like the autobuilders.
 However, if Debian is ever to cross-build successfully, EVERY test
 suite that executes compiled code MUST be skipped when cross-building.
 The simplest way to do that is to specify that cross-building must
 pass -nocheck in DEB_BUILD_OPTIONS and that all packages must obey
 -nocheck.

Atleast some packages now don't run the testsuite when
DEB_BUILD_GNU_TYPE != DEB_HOST_GNU_TYPE.

Are there any other reasons why testsuites shouldn't be run?


Kurt


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

Accepted openssl 0.9.8g-2 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 03 Nov 2007 13:25:45 +0100
Source: openssl
Binary: libssl-dev openssl libssl0.9.8-dbg libcrypto0.9.8-udeb libssl0.9.8
Architecture: source amd64
Version: 0.9.8g-2
Distribution: unstable
Urgency: low
Maintainer: Debian OpenSSL Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libcrypto0.9.8-udeb - crypto shared library - udeb (udeb)
 libssl-dev - SSL development libraries, header files and documentation
 libssl0.9.8 - SSL shared libraries
 libssl0.9.8-dbg - Symbol tables for libssl and libcrypto
 openssl- Secure Socket Layer (SSL) binary and related cryptographic tools
Closes: 424362 428051 430583
Changes: 
 openssl (0.9.8g-2) unstable; urgency=low
 .
   * Avoid text relocations on i386 caused by the assembler versions:
 - x86unix.pl: Create a function_begin_B_static to create a
   static/local assembler function.
 - aes-586.pl: Use the function_begin_B_static for _x86_AES_decrypt
   so that it doesn't get exported and doesn't have any (text) relocations.
 - aes-586.pl: Set up ebx to point to the GOT and call AES_set_encrypt_key
   via the PLT to avoid a relocation.
 - x86unix.pl: Call the init function via the PLT, avoiding a relocation
   in case of a PIC object.
 - cbc.pl: Call functions via the PLT.
 - desboth.pl: Call DES_encrypt2 via the PLT.
   * CA.sh should use the v3_ca extention when called with -newca
 (Closes: #428051)
   * Use -Wa,--noexecstack for all arches in Debian.  (Closes: #430583)
   * Convert the failure message when services fail restart to a debconf
 message.
   * To restart a service, just restart, instead of stop and start.
 Hopefully fixes #444946
   * Also remove igetest from the test dir in the clean target.
 (Closes: #424362)
Files: 
 68379f70665b036cf4cd6a89941f166a 797 utils optional openssl_0.9.8g-2.dsc
 bfa67b04cd668daa4b47f7d7304e5ea8 50227 utils optional openssl_0.9.8g-2.diff.gz
 16d28e8cc406df30ca76956c3c7b4e13 1027930 utils optional 
openssl_0.9.8g-2_amd64.deb
 03ecfd134567509c844da83d5a25dee4 943886 libs important 
libssl0.9.8_0.9.8g-2_amd64.deb
 6ecb8f2e7d9eff0f00e09bcfb67d21c7 617344 debian-installer optional 
libcrypto0.9.8-udeb_0.9.8g-2_amd64.udeb
 11c1a1fdcd2b94b25c74bad56b734542 2200534 libdevel optional 
libssl-dev_0.9.8g-2_amd64.deb
 d54a65cd25563b28592263672654d375 1608774 libdevel extra 
libssl0.9.8-dbg_0.9.8g-2_amd64.deb
Package-Type: udeb

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

iD8DBQFHLIAdQdwckHJElwsRAr59AJwO9VeHd53JpxTxuOBnP1ITPJfwWwCg44RH
4VOj/i3zplT0Q4zy1NyOvhw=
=ZXOR
-END PGP SIGNATURE-


Accepted:
libcrypto0.9.8-udeb_0.9.8g-2_amd64.udeb
  to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8g-2_amd64.udeb
libssl-dev_0.9.8g-2_amd64.deb
  to pool/main/o/openssl/libssl-dev_0.9.8g-2_amd64.deb
libssl0.9.8-dbg_0.9.8g-2_amd64.deb
  to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8g-2_amd64.deb
libssl0.9.8_0.9.8g-2_amd64.deb
  to pool/main/o/openssl/libssl0.9.8_0.9.8g-2_amd64.deb
openssl_0.9.8g-2.diff.gz
  to pool/main/o/openssl/openssl_0.9.8g-2.diff.gz
openssl_0.9.8g-2.dsc
  to pool/main/o/openssl/openssl_0.9.8g-2.dsc
openssl_0.9.8g-2_amd64.deb
  to pool/main/o/openssl/openssl_0.9.8g-2_amd64.deb


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

Accepted ntp 1:4.2.4p4+dfsg-2 (source all amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 23 Oct 2007 18:39:47 +0200
Source: ntp
Binary: ntp-doc ntpdate ntp
Architecture: source all amd64
Version: 1:4.2.4p4+dfsg-2
Distribution: unstable
Urgency: low
Maintainer: Debian NTP Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 ntp- Network Time Protocol daemon and utility programs
 ntp-doc- Network Time Protocol documentation
 ntpdate- client for setting system time from NTP servers
Closes: 446710 446711 447431
Changes: 
 ntp (1:4.2.4p4+dfsg-2) unstable; urgency=low
 .
   * Disable checking of openssl library version.
 (Closes: #446710, #446711, #447431)
 Patch from Steve Langasek [EMAIL PROTECTED]
Files: 
 5d93e19eb59cc74d185ffb5d8ae2 936 net optional ntp_4.2.4p4+dfsg-2.dsc
 6745f7bb76a09a3544df5ce51b3c6e1a 278510 net optional ntp_4.2.4p4+dfsg-2.diff.gz
 75c00359ef0e6b1160a4b5cedc442a91 928676 doc optional 
ntp-doc_4.2.4p4+dfsg-2_all.deb
 6d96dbc62d5abf91f11dff46a5fa 477646 net optional 
ntp_4.2.4p4+dfsg-2_amd64.deb
 6d8511596209a6ca086ca33c13da8c6e 62180 net optional 
ntpdate_4.2.4p4+dfsg-2_amd64.deb

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

iD8DBQFHHilvQdwckHJElwsRAiwzAKCUdHiyHvNGJ1FRjSNf3cNkGBi3AwCfV0WC
8s3aoo09j7JVC+C2Nn3/LHE=
=WJ4e
-END PGP SIGNATURE-


Accepted:
ntp-doc_4.2.4p4+dfsg-2_all.deb
  to pool/main/n/ntp/ntp-doc_4.2.4p4+dfsg-2_all.deb
ntp_4.2.4p4+dfsg-2.diff.gz
  to pool/main/n/ntp/ntp_4.2.4p4+dfsg-2.diff.gz
ntp_4.2.4p4+dfsg-2.dsc
  to pool/main/n/ntp/ntp_4.2.4p4+dfsg-2.dsc
ntp_4.2.4p4+dfsg-2_amd64.deb
  to pool/main/n/ntp/ntp_4.2.4p4+dfsg-2_amd64.deb
ntpdate_4.2.4p4+dfsg-2_amd64.deb
  to pool/main/n/ntp/ntpdate_4.2.4p4+dfsg-2_amd64.deb


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

Accepted openssl 0.9.8g-1 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 20 Oct 2007 12:47:10 +0200
Source: openssl
Binary: libssl-dev openssl libssl0.9.8-dbg libcrypto0.9.8-udeb libssl0.9.8
Architecture: source amd64
Version: 0.9.8g-1
Distribution: unstable
Urgency: low
Maintainer: Debian OpenSSL Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libcrypto0.9.8-udeb - crypto shared library - udeb (udeb)
 libssl-dev - SSL development libraries, header files and documentation
 libssl0.9.8 - SSL shared libraries
 libssl0.9.8-dbg - Symbol tables for libssl and libcrypto
 openssl- Secure Socket Layer (SSL) binary and related cryptographic tools
Changes: 
 openssl (0.9.8g-1) unstable; urgency=low
 .
   * New upstream release
 - Fixes version number not to say it's a development version.
Files: 
 1321e570fa9518fd6c1ab1485417fe47 797 utils optional openssl_0.9.8g-1.dsc
 acf70a16359bf3658bdfb74bda1c4419 3354792 utils optional 
openssl_0.9.8g.orig.tar.gz
 f8ab285f845ddbfd62c9c07f7b6478ee 47968 utils optional openssl_0.9.8g-1.diff.gz
 57a374dcd009ff251f3281d3497c0172 1027520 utils optional 
openssl_0.9.8g-1_amd64.deb
 4e432c3d4ff84fa3c8f62b04133131c8 943542 libs important 
libssl0.9.8_0.9.8g-1_amd64.deb
 1700e2ebf29593c22551d10e81e29ad6 617338 debian-installer optional 
libcrypto0.9.8-udeb_0.9.8g-1_amd64.udeb
 f3fdb77780bb3809001dd447c75b0f36 2200060 libdevel optional 
libssl-dev_0.9.8g-1_amd64.deb
 3a5c624b1e6490a5cc7843246ed2fcdf 1608380 libdevel extra 
libssl0.9.8-dbg_0.9.8g-1_amd64.deb
Package-Type: udeb

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

iD8DBQFHGfckQdwckHJElwsRAmOGAKDY8nxj91yFx4UntjM8ZMOo0iCusgCeJUmQ
oH8S8a/vSn5soQ8LeWiYwkA=
=wAO3
-END PGP SIGNATURE-


Accepted:
libcrypto0.9.8-udeb_0.9.8g-1_amd64.udeb
  to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8g-1_amd64.udeb
libssl-dev_0.9.8g-1_amd64.deb
  to pool/main/o/openssl/libssl-dev_0.9.8g-1_amd64.deb
libssl0.9.8-dbg_0.9.8g-1_amd64.deb
  to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8g-1_amd64.deb
libssl0.9.8_0.9.8g-1_amd64.deb
  to pool/main/o/openssl/libssl0.9.8_0.9.8g-1_amd64.deb
openssl_0.9.8g-1.diff.gz
  to pool/main/o/openssl/openssl_0.9.8g-1.diff.gz
openssl_0.9.8g-1.dsc
  to pool/main/o/openssl/openssl_0.9.8g-1.dsc
openssl_0.9.8g-1_amd64.deb
  to pool/main/o/openssl/openssl_0.9.8g-1_amd64.deb
openssl_0.9.8g.orig.tar.gz
  to pool/main/o/openssl/openssl_0.9.8g.orig.tar.gz


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

Re: Bits from the Testing Security team

[Kurt Roeckx]

On Wed, Oct 17, 2007 at 03:00:55PM +0100, Ian Jackson wrote:
   Indeed on modern multicore systems running the decompression in a
   separate process allows it to be run on a separate CPU, in parallel to
   the other processing done by dpkg proper.  So it might be faster.
  
   (I haven't done any benchmarking but I think these conclusions are
   pretty obvious.)
 
  What I think running it in a separate process does it creating 2 pipes
  you don't need.  You can just do everything in the local memory of 1
  process.
 
  Anyway, like you said, someone needs to do benchmarks to see if either
  solution is faster than the other.  I'm not convinced either way.
 
 The overhead (cpu cost) of reading or writing the contents of the .deb
 a few times through some pipes is irrelevant compared to both the cpu
 cost of decompressing it and of course the cpu cost of processing each
 file during installation.

Ian,

You were saying that by having 2 processes (or threads) you might gain
something.  I'm saying that by doing it with 2 processes you also
create a new overhead which might or might not be bigger than what you
gain.  In either case, I think it's unlikely that you'll notice such a
change.

If you want to take advantages of multiple core, it's properly more
likely that you can gain something with spreading the decompression
itself over multiple cores.  You could for instance have several dpkg
subprocesses extracting a different .deb at the same time.  But I'm
not conviced this is going to gain you anything either.

  On Tue, Oct 16, 2007 at 02:34:36PM +0100, Ian Jackson wrote:
   Having dpkg invoke the decompresser as a separate program provides
   several IMO important advantages.  It simplifies the code in dpkg, and
   it greatly simplifies the management of cross-version compatibility
   and multiple optional decompression schemes (including experimental
   ones), by decoupling dpkg from the decompressers.
  
  I see no reason why we can't have both available.
 
 dpkg has to be compiled one way in the distribution.
 
 And if there is no good reason to have the decompressors bound in then
 having that facility wired into the code is just extra complexity to
 no useful purpose.

If there is an advantage to use a library instead of doing it with an
external program, it makes sense to do it.  But not everything you want
to use might have a library which you can use, so it would make sense
to atleast have the option to decompress with an external program.


Kurt


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

Re: Bits from the Testing Security team

[Kurt Roeckx]

On Tue, Oct 16, 2007 at 02:34:36PM +0100, Ian Jackson wrote:
 Nico Golde writes (Re: Bits from the Testing Security team):
  quoting Adam Heath from #debian-devel:
 
 Thanks for passing that on.
 
  2007-10-15 18:07 eigood dpkg's configure has an option for using
shared libraries or static linking
  2007-10-15 18:08 eigood for gzip, it can do a static library link,
a dynamic library link, or a  runtime
fork/exec of gzip
  2007-10-15 18:08 eigood afaicr, when I did the patch
  2007-10-15 18:10 eigood the real reason, is dpkg used to only
fork/exec gzip
  2007-10-15 18:11 eigood for efficiency, I gave it an option to
link to zlib
 
 This reason doesn't make sense because it's not more efficient.  It
 saves about two fork/execs per package, which is not a significant
 part of dpkg's execution cost.
 
 Indeed on modern multicore systems running the decompression in a
 separate process allows it to be run on a separate CPU, in parallel to
 the other processing done by dpkg proper.  So it might be faster.
 
 (I haven't done any benchmarking but I think these conclusions are
 pretty obvious.)

Decompression is typicly something that is i/o bound, not cpu bound.
What I think running it in a separate process does it creating 2 pipes
you don't need.  You can just do everything in the local memory of 1
process.

Anyway, like you said, someone needs to do benchmarks to see if either
solution is faster than the other.  I'm not convinced either way.

 Having dpkg invoke the decompresser as a separate program provides
 several IMO important advantages.  It simplifies the code in dpkg, and
 it greatly simplifies the management of cross-version compatibility
 and multiple optional decompression schemes (including experimental
 ones), by decoupling dpkg from the decompressers.

I see no reason why we can't have both available.


Kurt


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

Re: Bits from the Testing Security team

[Kurt Roeckx]

On Mon, Oct 15, 2007 at 08:48:02PM +0200, Nico Golde wrote:
 Hi Ian,
 * Ian Jackson [EMAIL PROTECTED] [2007-10-15 19:59]:
  Nico Golde writes (Re: Bits from the Testing Security team):
   Yes, dpkg for example links statically against libbz2 and zlib just to 
   pick a famous example.
  
  IMO this is a mistake, and I hope it will be reversed soon ...
 
 quoting Adam Heath from #debian-devel:
 2007-10-15 18:07 eigood dpkg's configure has an option for using shared 
 libraries or static linking
 2007-10-15 18:08 eigood for gzip, it can do a static library link, a 
 dynamic library link, or a  runtime fork/exec of gzip
 2007-10-15 18:08 eigood afaicr, when I did the patch
 2007-10-15 18:10 eigood the real reason, is dpkg used to only fork/exec gzip
 2007-10-15 18:11 eigood for efficiency, I gave it an option to link to zlib
 2007-10-15 18:11 eigood however, I didn't want to introduce another 
 dependency into the base system
 2007-10-15 18:11 eigood so I made it link statically

Current priority required pacakges having a (pre) depends on zlib1g:
- util-linux

Priority important:
- gnupg
- gpgv
- libgnutls13
- libopencdk10
- libopencdk8
- libssl0.9.8
- man-db

Standard:
- libmagic1
- openssh-client
- pciutils
- w3m

I don't think you'll add much to base.


Kurt


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

Re: Bits from the Testing Security team

[Kurt Roeckx]

On Mon, Oct 15, 2007 at 09:08:06PM +0200, Kurt Roeckx wrote:
 On Mon, Oct 15, 2007 at 08:48:02PM +0200, Nico Golde wrote:
  Hi Ian,
  * Ian Jackson [EMAIL PROTECTED] [2007-10-15 19:59]:
   Nico Golde writes (Re: Bits from the Testing Security team):
Yes, dpkg for example links statically against libbz2 and zlib just to 
pick a famous example.
   
   IMO this is a mistake, and I hope it will be reversed soon ...
  
  quoting Adam Heath from #debian-devel:
  2007-10-15 18:07 eigood dpkg's configure has an option for using shared 
  libraries or static linking
  2007-10-15 18:08 eigood for gzip, it can do a static library link, a 
  dynamic library link, or a  runtime fork/exec of gzip
  2007-10-15 18:08 eigood afaicr, when I did the patch
  2007-10-15 18:10 eigood the real reason, is dpkg used to only fork/exec 
  gzip
  2007-10-15 18:11 eigood for efficiency, I gave it an option to link to 
  zlib
  2007-10-15 18:11 eigood however, I didn't want to introduce another 
  dependency into the base system
  2007-10-15 18:11 eigood so I made it link statically
 
 Current priority required pacakges having a (pre) depends on zlib1g:
 - util-linux
 
 Priority important:
 - gnupg
 - gpgv
 - libgnutls13
 - libopencdk10
 - libopencdk8
 - libssl0.9.8
 - man-db
 
 Standard:
 - libmagic1
 - openssh-client
 - pciutils
 - w3m

The same for libbz2-1.0 only returns gnupg.


Kurt


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

Accepted openssl 0.9.8f-1 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 13 Oct 2007 00:47:22 +0200
Source: openssl
Binary: libssl-dev openssl libssl0.9.8-dbg libcrypto0.9.8-udeb libssl0.9.8
Architecture: source amd64
Version: 0.9.8f-1
Distribution: unstable
Urgency: low
Maintainer: Debian OpenSSL Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libcrypto0.9.8-udeb - crypto shared library - udeb (udeb)
 libssl-dev - SSL development libraries, header files and documentation
 libssl0.9.8 - SSL shared libraries
 libssl0.9.8-dbg - Symbol tables for libssl and libcrypto
 openssl- Secure Socket Layer (SSL) binary and related cryptographic tools
Closes: 335703 408686 426774 426988 439737 440723 444258 445095
Changes: 
 openssl (0.9.8f-1) unstable; urgency=low
 .
   * New upstream release
 - Fixes DTLS issues, also fixes CVE-2007-4995 (Closes: #335703, #439737)
 - Proper inclusion of opensslconf.h in pq_compat.h (Closes: #408686)
 - New function SSL_set_SSL_CTX: bump shlibs.
   * Remove build dependency on gcc  4.2
   * Remove the openssl preinst, it looks like a workaround
 for a change in 0.9.2b where config files got moved.  (Closes: #445095)
   * Update debconf translations:
 - Vietnamese (Closes: #426988)
 - Danish (Closes: #426774)
 - Slovak (Closes: #440723)
 - Finnish (Closes: #444258)
Files: 
 6d216c373ff21f9239407851b5faaaf2 797 utils optional openssl_0.9.8f-1.dsc
 114bf908eb1b293d11d3e6b18a09269f 3357445 utils optional 
openssl_0.9.8f.orig.tar.gz
 f69938c70356de25886125dc1f87fc97 47975 utils optional openssl_0.9.8f-1.diff.gz
 0cb007d80740b4d96ab46f2f551d1edf 1027504 utils optional 
openssl_0.9.8f-1_amd64.deb
 4907f12545d6c10af7245472e4d140d0 943574 libs important 
libssl0.9.8_0.9.8f-1_amd64.deb
 d2fbf60a41ade8c5a48e3a8d801d876d 617338 debian-installer optional 
libcrypto0.9.8-udeb_0.9.8f-1_amd64.udeb
 462b4316165ce2866f2ad1f02c7d9792 2199552 libdevel optional 
libssl-dev_0.9.8f-1_amd64.deb
 da8737008d42db56e938d9bb737a666f 1608278 libdevel extra 
libssl0.9.8-dbg_0.9.8f-1_amd64.deb
Package-Type: udeb

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

iD8DBQFHESHBQdwckHJElwsRAqbiAKDbfWIq/iL0lgSCtvHhGvwucYZNfQCgl8pm
CiNhKey4lY2l66tJkFK9JFI=
=pByb
-END PGP SIGNATURE-


Accepted:
libcrypto0.9.8-udeb_0.9.8f-1_amd64.udeb
  to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8f-1_amd64.udeb
libssl-dev_0.9.8f-1_amd64.deb
  to pool/main/o/openssl/libssl-dev_0.9.8f-1_amd64.deb
libssl0.9.8-dbg_0.9.8f-1_amd64.deb
  to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8f-1_amd64.deb
libssl0.9.8_0.9.8f-1_amd64.deb
  to pool/main/o/openssl/libssl0.9.8_0.9.8f-1_amd64.deb
openssl_0.9.8f-1.diff.gz
  to pool/main/o/openssl/openssl_0.9.8f-1.diff.gz
openssl_0.9.8f-1.dsc
  to pool/main/o/openssl/openssl_0.9.8f-1.dsc
openssl_0.9.8f-1_amd64.deb
  to pool/main/o/openssl/openssl_0.9.8f-1_amd64.deb
openssl_0.9.8f.orig.tar.gz
  to pool/main/o/openssl/openssl_0.9.8f.orig.tar.gz


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

Re: Bits from the listmasters

[Kurt Roeckx]

On Tue, Oct 09, 2007 at 01:44:47PM +0200, Martin Zobel-Helas wrote:
 How to help listmasters against spam
 
 
* If you notice a spam in the list archives, press the 'Report As
  Spam'-Button.

I don't see such a button on the list archives.  I only see it
on the BTS.

* Report spam that gets to you through our filters to
  [EMAIL PROTECTED]

What should we do with spam send to the BTS that then gets forwarded
to some list?  I think this only happens with pseudo packages, and a
few others like apt and glibc.  Do we report it twice?

Will spam that was send to the list be removed from the archives?


Kurt


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

Bug#446030: RFA: kbd -- Linux console font and keytable utilities

[Kurt Roeckx]

On Wed, Oct 10, 2007 at 02:10:37AM +0300, Anton Zinoviev wrote:
 Package: wnpp
 Severity: normal
 
 [Please add me to your CC list.]
 
 I request an adopter for the kbd package.
 
 Actually it was never my intention to maintain kbd, but its
 maintainer was the group Console utilities maintainers and it seems
 currently I am the only member of this group... :)

Is there a reason to still keep kbd around?  Is there something in
kbd that console-tools doesn't do?


Kurt




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

Re: Conflicting bsdmainutils and bsdutils on mipsel and sparc auto-builders

[Kurt Roeckx]

On Tue, Oct 02, 2007 at 10:41:08AM +0200, Andreas Tille wrote:
 Hi,

 I'm wondering how to cope with the following problem: The auto-building
 of the wordnet package failed on mipsel and sparc with:

 ...
 Unpacking bsdmainutils (from .../bsdmainutils_6.1.7_sparc.deb) ...
 dpkg: error processing 
 /home/buildd/build/chroot-unstable/var/cache/apt/archives/bsdmainutils_6.1.7_sparc.deb
  
 (--unpack):
  trying to overwrite `/usr/bin/col', which is also in package bsdutils
 ...
 Errors were encountered while processing:

The problem is that the dpkg used on the host system is still sarge,
which doesn't probably take the Replaces into account depending on the
order of install.


Kurt


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

Accepted openssl 0.9.8e-9 (source i386 amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 28 Sep 2007 19:47:33 +0200
Source: openssl
Binary: libssl-dev openssl libssl0.9.8-dbg libcrypto0.9.8-udeb libssl0.9.8
Architecture: amd64 i386 source 
Version: 0.9.8e-9
Distribution: unstable
Urgency: high
Maintainer: Debian OpenSSL Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libcrypto0.9.8-udeb - crypto shared library - udeb (udeb)
 libssl-dev - SSL development libraries, header files and documentation
 libssl0.9.8 - SSL shared libraries
 libssl0.9.8-dbg - Symbol tables for libssl and libcrypto
 openssl- Secure Socket Layer (SSL) binary and related cryptographic tools
Closes: 35
Changes: 
 openssl (0.9.8e-9) unstable; urgency=high
 .
   * CVE-2007-5135: Fix off by one error in SSL_get_shared_ciphers().
 (Closes: #35)
   * Add postgresql-8.2 to the list of services to check.
Files: 
 0764261c16a61aa7f272cf99273923dd 2070734 libdevel optional 
libssl-dev_0.9.8e-9_i386.deb
 22fdfe4cc8457f3741a7074ea5e50c11 2191446 libdevel optional 
libssl-dev_0.9.8e-9_amd64.deb
 232f3723ef010dab5c59f182b7052076 2861502 libs important 
libssl0.9.8_0.9.8e-9_i386.deb
 49bb013a2b9623caa72dd87f3c55494c 813 utils optional openssl_0.9.8e-9.dsc
 535fa172e2f4262ef27d902834383c62 1599292 libdevel extra 
libssl0.9.8-dbg_0.9.8e-9_amd64.deb
 64ea4f2386e95cfc0e3773b980a215d5 935928 libs important 
libssl0.9.8_0.9.8e-9_amd64.deb
 9c416998e19cadcab7691e178a5f5000 50621 utils optional openssl_0.9.8e-9.diff.gz
 be86cd043acfc06a0062a7bd5c912d01 1022092 utils optional 
openssl_0.9.8e-9_amd64.deb
 ca76a5dd03790c03ef0d21916671f5f1 614818 debian-installer optional 
libcrypto0.9.8-udeb_0.9.8e-9_amd64.udeb
 d5942cea1174c8f132971521987ba6c9 5330906 libdevel extra 
libssl0.9.8-dbg_0.9.8e-9_i386.deb
 de16bd8e496e1b09c5c78e96d11bda5b 573908 debian-installer optional 
libcrypto0.9.8-udeb_0.9.8e-9_i386.udeb
 feb63df1e62b0c4413bbcb68fab1ff7c 1016498 utils optional 
openssl_0.9.8e-9_i386.deb

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

iD8DBQFG/VftQdwckHJElwsRAkIhAKConnaEmssUPQc8Z+2dI6+tbz0KLwCgx0rv
6Y8EzVWOLWE6g0ClhP9FViA=
=E7wp
-END PGP SIGNATURE-


Accepted:
libcrypto0.9.8-udeb_0.9.8e-9_amd64.udeb
  to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8e-9_amd64.udeb
libcrypto0.9.8-udeb_0.9.8e-9_i386.udeb
  to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8e-9_i386.udeb
libssl-dev_0.9.8e-9_amd64.deb
  to pool/main/o/openssl/libssl-dev_0.9.8e-9_amd64.deb
libssl-dev_0.9.8e-9_i386.deb
  to pool/main/o/openssl/libssl-dev_0.9.8e-9_i386.deb
libssl0.9.8-dbg_0.9.8e-9_amd64.deb
  to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8e-9_amd64.deb
libssl0.9.8-dbg_0.9.8e-9_i386.deb
  to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8e-9_i386.deb
libssl0.9.8_0.9.8e-9_amd64.deb
  to pool/main/o/openssl/libssl0.9.8_0.9.8e-9_amd64.deb
libssl0.9.8_0.9.8e-9_i386.deb
  to pool/main/o/openssl/libssl0.9.8_0.9.8e-9_i386.deb
openssl_0.9.8e-9.diff.gz
  to pool/main/o/openssl/openssl_0.9.8e-9.diff.gz
openssl_0.9.8e-9.dsc
  to pool/main/o/openssl/openssl_0.9.8e-9.dsc
openssl_0.9.8e-9_amd64.deb
  to pool/main/o/openssl/openssl_0.9.8e-9_amd64.deb
openssl_0.9.8e-9_i386.deb
  to pool/main/o/openssl/openssl_0.9.8e-9_i386.deb


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

Re: volatile.debian.org: Does Debian still support it?

[Kurt Roeckx]

On Tue, Sep 25, 2007 at 05:36:03PM +0200, Piotr Roszatycki wrote:
 It's not about one timezone. The new release refresh all available
 timezones. The whole package was synced with the latest Olson
 database.

It would be good if you fixed #416206, and used tzdata yourself.  So
that we only need to update 1 package in volatile.


Kurt


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

Re: volatile.debian.org: Does Debian still support it?

[Kurt Roeckx]

On Tue, Sep 25, 2007 at 09:48:19PM +0200, Piotr Roszatycki wrote:
 It is almost impossible.
 
 The DateTime::TimeZone is pure Perl library and can't use binary data
 from tzdata package. In fact, this library can be used on systems
 without libc6 and tzdata at all! You wrongly assume that tzdata
 package is more important than libdatetime-timezone-perl package. It
 can be true only for glibc based systems.
 
 Even tzdata package is compiled from the source data - the same data
 which is used for refreshing libdatetime-timezone-perl!

That it can be used on other systems that don't have tzdata doesn't mean
it shouldn't try and use tzdata if it's available on Debian.

The binary data in the tzdata should be easy to parse.  See
man tzfile(5).

 2007/9/25, Kurt Roeckx [EMAIL PROTECTED]:
  On Tue, Sep 25, 2007 at 05:36:03PM +0200, Piotr Roszatycki wrote:
   It's not about one timezone. The new release refresh all available
   timezones. The whole package was synced with the latest Olson
   database.
 
  It would be good if you fixed #416206, and used tzdata yourself.  So
  that we only need to update 1 package in volatile.
 
 
  Kurt
 
 
 
 
 -- 
  .''`.Piotr Roszatycki
 : :' :mailto:[EMAIL PROTECTED]
 `. `' mailto:[EMAIL PROTECTED]
   `-
 
 
 -- 
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
 


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

Re: US mirror troubles

[Kurt Roeckx]

On Thu, Sep 06, 2007 at 09:24:24AM -0400, Johan Kullstam wrote:
 
 Using host from bind9-host,
 $ host http.us.debian.org
 http.us.debian.org has address 128.101.240.212
 http.us.debian.org has address 204.152.191.7
 http.us.debian.org has address 35.9.37.225
 http.us.debian.org has address 64.50.238.52
 
 And if you repeat the command, you will see the DNS doing round-robin
 returning the addresses in various orders.  This seems great.
 
 However, libc6 resolv+ (I think - can someone confirm who is to
 blame?) goes out of its way to *sort* the list by IP number and thus
 thwarts the round-robin.  Aptitude (and wget, c) *always* choose
 35.9.37.225.  This server must be getting beat like a red-headed
 stepchild since *all* the debian update/upgrade trying
 http.us.debian.org go there.


See http://bugs.debian.org/438179


Kurt


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

Re: US mirror troubles

[Kurt Roeckx]

On Thu, Sep 06, 2007 at 04:19:51PM -0400, Joey Hess wrote:
 Kurt Roeckx wrote:
  See http://bugs.debian.org/438179
 
 This bug was closed by adding a config option. Why wasn't it cloned to
 all the network clients (apt, ntp, etc) that exhibit undesirable
 behavior due to this change in glibc? Perhaps because the list is too
 long for anyone to enumerate it.

I opened an upstream bug report with ntp.  But I would rather see the
default get changed.  I think there are just too many
people/applications that assume a certain behaviour that's different
then what we have now.


Kurt


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

Accepted openssl 0.9.8e-7 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 02 Sep 2007 16:15:18 +0200
Source: openssl
Binary: libssl-dev openssl libssl0.9.8-dbg libcrypto0.9.8-udeb libssl0.9.8
Architecture: source amd64
Version: 0.9.8e-7
Distribution: unstable
Urgency: low
Maintainer: Debian OpenSSL Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libcrypto0.9.8-udeb - crypto shared library - udeb (udeb)
 libssl-dev - SSL development libraries, header files and documentation
 libssl0.9.8 - SSL shared libraries
 libssl0.9.8-dbg - Symbol tables for libssl and libcrypto
 openssl- Secure Socket Layer (SSL) binary and related cryptographic tools
Closes: 429740
Changes: 
 openssl (0.9.8e-7) unstable; urgency=low
 .
   * Fix problems with gcc-4.2 (Closes: #429740)
   * Stop using -Bsymbolic to create the shared library.
   * Make x86_64cpuid.pl use PIC.
Files: 
 c41d66bd63f76f11f8c3fcf93c0de71b 797 utils optional openssl_0.9.8e-7.dsc
 d006684c2256390dcbf02efec63cabd7 49927 utils optional openssl_0.9.8e-7.diff.gz
 7cfda8c7141a0b91033df55ca0df4de4 1021914 utils optional 
openssl_0.9.8e-7_amd64.deb
 d028cd6958df7dccd81f138df97d0975 935642 libs important 
libssl0.9.8_0.9.8e-7_amd64.deb
 5e6bb2ca24f347e02e1b04e038e4e71c 614728 debian-installer optional 
libcrypto0.9.8-udeb_0.9.8e-7_amd64.udeb
 c56050dbb7e4af8b7e4be8bf2cdded41 2190796 libdevel optional 
libssl-dev_0.9.8e-7_amd64.deb
 aad0cd770a22476029950d2c495234d9 1599088 libdevel extra 
libssl0.9.8-dbg_0.9.8e-7_amd64.deb
Package-Type: udeb

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

iD8DBQFG2s3MQdwckHJElwsRAs3BAKC62FAwTsFR/0VH3iE5I7wYSuS0CACfTu5C
KAsiN6IAOCicfInMi6qKqiE=
=jjj0
-END PGP SIGNATURE-


Accepted:
libcrypto0.9.8-udeb_0.9.8e-7_amd64.udeb
  to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8e-7_amd64.udeb
libssl-dev_0.9.8e-7_amd64.deb
  to pool/main/o/openssl/libssl-dev_0.9.8e-7_amd64.deb
libssl0.9.8-dbg_0.9.8e-7_amd64.deb
  to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8e-7_amd64.deb
libssl0.9.8_0.9.8e-7_amd64.deb
  to pool/main/o/openssl/libssl0.9.8_0.9.8e-7_amd64.deb
openssl_0.9.8e-7.diff.gz
  to pool/main/o/openssl/openssl_0.9.8e-7.diff.gz
openssl_0.9.8e-7.dsc
  to pool/main/o/openssl/openssl_0.9.8e-7.dsc
openssl_0.9.8e-7_amd64.deb
  to pool/main/o/openssl/openssl_0.9.8e-7_amd64.deb


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

Accepted openssl 0.9.8e-8 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 02 Sep 2007 18:12:11 +0200
Source: openssl
Binary: libssl-dev openssl libssl0.9.8-dbg libcrypto0.9.8-udeb libssl0.9.8
Architecture: source amd64
Version: 0.9.8e-8
Distribution: unstable
Urgency: low
Maintainer: Debian OpenSSL Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libcrypto0.9.8-udeb - crypto shared library - udeb (udeb)
 libssl-dev - SSL development libraries, header files and documentation
 libssl0.9.8 - SSL shared libraries
 libssl0.9.8-dbg - Symbol tables for libssl and libcrypto
 openssl- Secure Socket Layer (SSL) binary and related cryptographic tools
Closes: 429740
Changes: 
 openssl (0.9.8e-8) unstable; urgency=low
 .
   * Fix another case of the if this code is reached, the program will abort
 (Closes: #429740)
   * Temporary force to build with gcc = 4.2
Files: 
 1e67e8229033457bf5eff4f9e5a4ca00 813 utils optional openssl_0.9.8e-8.dsc
 cc9435f3d9807578e98cc1bd1507 50155 utils optional openssl_0.9.8e-8.diff.gz
 ff20a8fa28328f7bc97041b7fea109f2 1022080 utils optional 
openssl_0.9.8e-8_amd64.deb
 6b288361443ce2fba2d04498d040f11a 935792 libs important 
libssl0.9.8_0.9.8e-8_amd64.deb
 2cc2916e0ae53870f5654a02b3d7f4ce 614830 debian-installer optional 
libcrypto0.9.8-udeb_0.9.8e-8_amd64.udeb
 2dab5687cac442716d64e9a688730db2 2191360 libdevel optional 
libssl-dev_0.9.8e-8_amd64.deb
 34ffe11d960ac34185718f4649a1268c 1599302 libdevel extra 
libssl0.9.8-dbg_0.9.8e-8_amd64.deb
Package-Type: udeb

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

iD8DBQFG2u8dQdwckHJElwsRAtW1AJ9e1bUWO53nAtgTTn8cmWbQWy3yQwCfVwpE
7aOFPaG95X5rOHFhg+W5Stw=
=rmND
-END PGP SIGNATURE-


Accepted:
libcrypto0.9.8-udeb_0.9.8e-8_amd64.udeb
  to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8e-8_amd64.udeb
libssl-dev_0.9.8e-8_amd64.deb
  to pool/main/o/openssl/libssl-dev_0.9.8e-8_amd64.deb
libssl0.9.8-dbg_0.9.8e-8_amd64.deb
  to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8e-8_amd64.deb
libssl0.9.8_0.9.8e-8_amd64.deb
  to pool/main/o/openssl/libssl0.9.8_0.9.8e-8_amd64.deb
openssl_0.9.8e-8.diff.gz
  to pool/main/o/openssl/openssl_0.9.8e-8.diff.gz
openssl_0.9.8e-8.dsc
  to pool/main/o/openssl/openssl_0.9.8e-8.dsc
openssl_0.9.8e-8_amd64.deb
  to pool/main/o/openssl/openssl_0.9.8e-8_amd64.deb


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

Re: Dependencies on shared libs, news and difference between archs

[Kurt Roeckx]

On Wed, Aug 22, 2007 at 03:19:02PM +0200, Raphael Hertzog wrote:
 Hi,
 
 2/ Second example, libconfig0 has a supplementary symbols
[...]
 _PROCEDURE_LINKAGE_TABLE_ on sparc and alpha. I don't know where it comes 
 from.
 Is this a internal symbols that I missed?

http://www.cygwin.com/ml/binutils/2004-05/msg00577.html seems to suggest
that only sparc and alpha want the PLT as a symbol.

 On powerpc it has _SDA_BASE_ and _SDA2_BASE_. Same question as above.

The Small Data Areas (SDA) seems to be ppc specific, and is mentioned in
the elfspec_ppc.pdf.  It's about data that can be access with 16 bit
offset.

 On amd64 it has lost the _DYNAMIC symbol. Same question as above.

It seems this can be hidden:
http://sourceware.org/ml/binutils/2005-08/msg00190.html

amd64 built this package only in 2006, the rest did in 2003.  I'm
guessing building this again will remove it on other arches.

 Quick googling led me to believe that I can/should exclude all those. If
 someone can confirm, it would be great.

I agree.


Kurt


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

Re: proposed release goal: DEBIAN/md5sums for all packages

[Kurt Roeckx]

On Sat, Aug 18, 2007 at 03:13:32AM +0200, Sven Mueller wrote:
 
 He doesn't give any information _why_ this complicates packaging that
 much, while his decision imposes additional work and complexity on
 others (be it the exception in lintian and probably linda or the
 difference between dpkg -L and the contents of the md5sums file, which
 makes integrity checking a bit harder).
 
 IMHO, packages (.deb) should only include files which are either listed
 in conffiles or in md5sums.
 
 The hash files in aspell/ispell/wordlist packages (for example*:
 aspell-en, idutch) are neither conffiles nor in md5sums. They are said
 to be arch-dependend and if I understand the aspell-en debian/rules
 correctly, they are shipped as empty files. I don't see why they
 couldn't just be created empty by the postinst before building the hash
 tables. I especially don't see how that complicates packaging.

The aspell-autobuildhash / ispell-autobuildhash manpage says create an
empty .compat, or one with 0 in it.  I guess most people just create the
empty one.  This file is then used to decide if the hash file needs to be
(re-)created or not.

Reading the manpage again I see:
   This
   empty file will be overwritten when the real hash is created, but will
   make the hash be removed at package removal without any magic being
   done in the postrm and will also help to keep track about which package
   owns that file.

I guess that's the more complicated part.


Kurt


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

Re: proposed release goal: DEBIAN/md5sums for all packages

[Kurt Roeckx]

On Fri, Aug 17, 2007 at 10:12:07AM -0700, Russ Allbery wrote:
 Lars Wirzenius [EMAIL PROTECTED] writes:
 
  It strikes me that if we want to make it policy, having dpkg generate
  the checksums upon creating the .deb would be the simplest and best way
  to do it. This way we wouldn't have to change packages to do it, and if
  we ever want to change the format (sha1 as well as md5?) there's only
  one place to change it.
 
 Some packages (aspell and ispell packages in particular) ship files that
 they then modify in maintainer scripts and intentionally exclude them from
 the md5sums file for that reason.  lintian has special code to deal with
 this case.  A replacement in dpkg would either need to cope with this or
 decide that those packages can no longer take that approach and have to
 solve whatever problem they're solving in some other way.  (I don't know
 what problem this is solving.)

As I understand it, it's so that debsums doesn't complain about that
files changes.


Kurt


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

Re: proposed release goal: DEBIAN/md5sums for all packages

[Kurt Roeckx]

On Fri, Aug 17, 2007 at 11:25:38AM -0700, Russ Allbery wrote:
 
  Some packages (aspell and ispell packages in particular) ship files
  that they then modify in maintainer scripts and intentionally exclude
  them from the md5sums file for that reason.  lintian has special code
  to deal with this case.  A replacement in dpkg would either need to
  cope with this or decide that those packages can no longer take that
  approach and have to solve whatever problem they're solving in some
  other way.  (I don't know what problem this is solving.)
 
  As I understand it, it's so that debsums doesn't complain about that
  files changes.
 
 Right... I meant more what problem they had that they were solving by
 installing a file in /var as part of the package and then modifying it
 later.  (It always struck me as odd, but I presume they have good reasons
 for doing things that way.)

The hash file, which is architecture dependend, is created on install.
This is the only file in the package that is architecture dependend.

Anyway, there is a policy file about this in:
/usr/share/doc/dictionaries-common-dev/dsdt-policy.txt.gz


Kurt


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

Re: proposed release goal: DEBIAN/md5sums for all packages

[Kurt Roeckx]

On Sat, Aug 18, 2007 at 01:27:45AM +0200, Sven Mueller wrote:
  The hash file, which is architecture dependend, is created on install.
  This is the only file in the package that is architecture dependend.
 
 If it is created on install, why is it in the packages filelist in the
 first place? Other packages also generate (supposedly architecture
 dependend) files during postinst, without shipping a placeholder in the
 .deb - so what is the reason why [ia]spell does that?

I wasn't at all involved with writing this policy.  So, I'll have to
guess.

 Uhm, also: I couldn't find any such example in the [ia]spell packages
 themselves nor in wamerican, myspell-de-de, ispell-de-de so perhaps
 (some of) those packages used to do that sort of stuff, but refrain from
 doing so now?

Policy doesn't say you have to do this.  It's just one of the options.

examples are things like:
aspell-en
ipolish
aspell-pl
idutch
apsell-nl


Kurt


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

Accepted openssl 0.9.8e-6 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 15 Aug 2007 19:49:54 +0200
Source: openssl
Binary: libssl-dev openssl libssl0.9.8-dbg libcrypto0.9.8-udeb libssl0.9.8
Architecture: source amd64
Version: 0.9.8e-6
Distribution: unstable
Urgency: high
Maintainer: Debian OpenSSL Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libcrypto0.9.8-udeb - crypto shared library - udeb (udeb)
 libssl-dev - SSL development libraries, header files and documentation
 libssl0.9.8 - SSL shared libraries
 libssl0.9.8-dbg - Symbol tables for libssl and libcrypto
 openssl- Secure Socket Layer (SSL) binary and related cryptographic tools
Closes: 438142
Changes: 
 openssl (0.9.8e-6) unstable; urgency=high
 .
   * Add fix for CVE-2007-3108 (Closes: #438142)
Files: 
 e64b54ca284a70c19e7d5b586cb22678 797 utils optional openssl_0.9.8e-6.dsc
 89e0b5f311fb8742f04c0f5627495d05 47824 utils optional openssl_0.9.8e-6.diff.gz
 bce8d9d9f66bbbc39d11092bd9f51d82 108 utils optional 
openssl_0.9.8e-6_amd64.deb
 6142a7cf39939efc0cc8d82300f05150 921810 libs important 
libssl0.9.8_0.9.8e-6_amd64.deb
 c188d7e118e4388287353399ec066a55 603610 debian-installer optional 
libcrypto0.9.8-udeb_0.9.8e-6_amd64.udeb
 843d1fdb5748eac1f2c0bba30e66d3a1 2196396 libdevel optional 
libssl-dev_0.9.8e-6_amd64.deb
 d1e3d15a438c6dd728f2946aed54ae13 1639256 libdevel extra 
libssl0.9.8-dbg_0.9.8e-6_amd64.deb
Package-Type: udeb

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

iD8DBQFGwz/JQdwckHJElwsRAh9nAJ0YcpzdeDHDJsOUitz6L4ikt9qX+wCfTIFd
bFFaks7m9PVdY3GhV1ghWzo=
=FyOM
-END PGP SIGNATURE-


Accepted:
libcrypto0.9.8-udeb_0.9.8e-6_amd64.udeb
  to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8e-6_amd64.udeb
libssl-dev_0.9.8e-6_amd64.deb
  to pool/main/o/openssl/libssl-dev_0.9.8e-6_amd64.deb
libssl0.9.8-dbg_0.9.8e-6_amd64.deb
  to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8e-6_amd64.deb
libssl0.9.8_0.9.8e-6_amd64.deb
  to pool/main/o/openssl/libssl0.9.8_0.9.8e-6_amd64.deb
openssl_0.9.8e-6.diff.gz
  to pool/main/o/openssl/openssl_0.9.8e-6.diff.gz
openssl_0.9.8e-6.dsc
  to pool/main/o/openssl/openssl_0.9.8e-6.dsc
openssl_0.9.8e-6_amd64.deb
  to pool/main/o/openssl/openssl_0.9.8e-6_amd64.deb


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

Accepted ntp 1:4.2.4p3+dfsg-1 (source all amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon, 13 Aug 2007 15:58:08 +
Source: ntp
Binary: ntp-doc ntpdate ntp
Architecture: source all amd64
Version: 1:4.2.4p3+dfsg-1
Distribution: unstable
Urgency: low
Maintainer: Debian NTP Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 ntp- Network Time Protocol daemon and utility programs
 ntp-doc- Network Time Protocol documentation
 ntpdate- client for setting system time from NTP servers
Closes: 427634 427981 428241
Changes: 
 ntp (1:4.2.4p3+dfsg-1) unstable; urgency=low
 .
   [ Kurt Roeckx ]
   * New upstream release
 .
   [ Peter Eisentraut ]
   * Removed mentions of -d and -D options from ntpd and ntpq man pages
 (closes: #427634, #428241)
   * Added reference from ntpdate man page to ntpdate-debian
 (closes: #427981)
Files: 
 c937862f7d98a8225a7b3b905c40de5f 912 net optional ntp_4.2.4p3+dfsg-1.dsc
 4120c8811d638c819b24c8b4d95e5312 2837801 net optional 
ntp_4.2.4p3+dfsg.orig.tar.gz
 a54262c52b1f9f08d6770cbaa27e80bc 277741 net optional ntp_4.2.4p3+dfsg-1.diff.gz
 1e69068ea1c7f9c0b8dc78fcfbc55f58 928478 doc optional 
ntp-doc_4.2.4p3+dfsg-1_all.deb
 36207612534ba006e76757ca4abbec25 477498 net optional 
ntp_4.2.4p3+dfsg-1_amd64.deb
 70cce17a3ded890f218d279292c2b01d 62018 net optional 
ntpdate_4.2.4p3+dfsg-1_amd64.deb

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

iD8DBQFGwIHSQdwckHJElwsRAmYgAKDOWc6I9tE67Qo1NVQw4b3B3aO1GwCfbEz5
jW3CYYc1T+wngMAY3Uno2L8=
=twiR
-END PGP SIGNATURE-


Accepted:
ntp-doc_4.2.4p3+dfsg-1_all.deb
  to pool/main/n/ntp/ntp-doc_4.2.4p3+dfsg-1_all.deb
ntp_4.2.4p3+dfsg-1.diff.gz
  to pool/main/n/ntp/ntp_4.2.4p3+dfsg-1.diff.gz
ntp_4.2.4p3+dfsg-1.dsc
  to pool/main/n/ntp/ntp_4.2.4p3+dfsg-1.dsc
ntp_4.2.4p3+dfsg-1_amd64.deb
  to pool/main/n/ntp/ntp_4.2.4p3+dfsg-1_amd64.deb
ntp_4.2.4p3+dfsg.orig.tar.gz
  to pool/main/n/ntp/ntp_4.2.4p3+dfsg.orig.tar.gz
ntpdate_4.2.4p3+dfsg-1_amd64.deb
  to pool/main/n/ntp/ntpdate_4.2.4p3+dfsg-1_amd64.deb


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

Re: Build the Debian Reference Card

[Kurt Roeckx]

On Tue, Jul 24, 2007 at 05:53:37PM +0200, Daniel Leidert wrote:
 Am Dienstag, den 24.07.2007, 14:13 +0100 schrieb Neil Williams:
  On Tue, 24 Jul 2007 13:33:04 +0100 (BST)
  Paul Cager [EMAIL PROTECTED] wrote:
  
   Hi,
   
   Has anyone any advice on how to build the Reference Card[1] from source?
   
   I have removed the --nonet from the xsltproc call 
  
  I use xsltproc in a number of build situations and removing --nonet is
  NOT a solution!
 
 It is, if the stylesheets are not installed locally or if there is no
 catalog entry. Both are possible, because the necessary package had been
 removed from Debian. The OP was right to remove this option, if he
 observed the error:

Note that it is not acceptable for a package in main to rely on something
that is not in main.  When building something for main (using xsltproc),
you should always make sure that it's using things from main, and not
some random version somewhere on internet.

This doesn't seem to be a package that's in main, but it's probably
still a good idea to use --nonet, so you can actually get consitent
results over time.


Kurt


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

Accepted libtool 1.5.24-1 (source all amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 11 Jul 2007 20:18:34 +0200
Source: libtool
Binary: libtool-doc libltdl3 libtool libltdl3-dev
Architecture: source amd64 all
Version: 1.5.24-1
Distribution: unstable
Urgency: low
Maintainer: Kurt Roeckx [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libltdl3   - A system independent dlopen wrapper for GNU libtool
 libltdl3-dev - A system independent dlopen wrapper for GNU libtool
 libtool- Generic library support script
 libtool-doc - Generic library support script
Closes: 348558 407079 430973 432139
Changes: 
 libtool (1.5.24-1) unstable; urgency=low
 .
   * New upstream release (Closes: #432139):
 - Remove kbsd patch, merged upstream
 - Support -export-symbols on hurd (Closes: #430973)
 - Support -Wl,--version-script on hurd (Closes: #407079)
 - Support multiple libs with the same name (Closes: #348558)
   * Change patch system from dpatch to quilt.
   * Use gcj on all arches execpt hurd
   * Switch to automake1.10
   * Change Standards-Version to 3.7.2.2, no changes required.
   * Change DH_COMPAT to a debian/compat file with 4 in it.
Files: 
 8f2572ea067a327d48bf49b74c2d92db 714 devel optional libtool_1.5.24-1.dsc
 d0071c890101fcf4f2be8934a37841b0 2919557 devel optional 
libtool_1.5.24.orig.tar.gz
 23009975ac72a0f9c42bb48bb231adf1 13721 devel optional libtool_1.5.24-1.diff.gz
 4e59969b96caa42e380e7ee49c87b850 348206 doc optional 
libtool-doc_1.5.24-1_all.deb
 9462f77c575a6ee8f46ce2fb04159d57 338290 devel optional 
libtool_1.5.24-1_amd64.deb
 f67c166e57dc434108cb092e3f5b9dc8 176906 libs optional 
libltdl3_1.5.24-1_amd64.deb
 cd8f3f5c5a66300a67ae161734c378a6 368596 libdevel optional 
libltdl3-dev_1.5.24-1_amd64.deb

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

iD8DBQFGlTVEQdwckHJElwsRArhSAJ9o55r2wjLxSjYxhyQFOzVTFZfBRgCeJki2
IUApPjzL8/p7vzUrrpS9wjE=
=rAv1
-END PGP SIGNATURE-


Accepted:
libltdl3-dev_1.5.24-1_amd64.deb
  to pool/main/libt/libtool/libltdl3-dev_1.5.24-1_amd64.deb
libltdl3_1.5.24-1_amd64.deb
  to pool/main/libt/libtool/libltdl3_1.5.24-1_amd64.deb
libtool-doc_1.5.24-1_all.deb
  to pool/main/libt/libtool/libtool-doc_1.5.24-1_all.deb
libtool_1.5.24-1.diff.gz
  to pool/main/libt/libtool/libtool_1.5.24-1.diff.gz
libtool_1.5.24-1.dsc
  to pool/main/libt/libtool/libtool_1.5.24-1.dsc
libtool_1.5.24-1_amd64.deb
  to pool/main/libt/libtool/libtool_1.5.24-1_amd64.deb
libtool_1.5.24.orig.tar.gz
  to pool/main/libt/libtool/libtool_1.5.24.orig.tar.gz


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

Accepted elfutils 0.128-1 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 08 Jul 2007 19:28:46 +
Source: elfutils
Binary: libasm-dev libdw-dev elfutils libelf1 libasm1 libelf-dev libebl-dev
Architecture: source amd64
Version: 0.128-1
Distribution: unstable
Urgency: low
Maintainer: Kurt Roeckx [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 elfutils   - collection of utilities to handle ELF objects
 libasm-dev - libasm development libraries and header files
 libasm1- library with a programmable assembler interface
 libdw-dev  - library that provides access to the DWARF debug information
 libebl-dev - static library providing higher-level ELF access functionality
 libelf-dev - libelf1 development libraries and header files
 libelf1- library to read and write ELF files
Closes: 404054 431455
Changes: 
 elfutils (0.128-1) unstable; urgency=low
 .
   * New upstream release:
 Remove patch alpha_backend_regs.diff, upstream implemented
 it themself (with the aliases for the register names).
   * Make libasm-dev conflict with libelfsh0-dev again, the 0.123-3 change
 got lost.  (Closes: #404054)
   * First cast main to an intptr_t before casting it to a 64 bit int.
 Directly casting from a pointer to 64 bit int gives a warning
 on 32 bit systems (with gcc-4.2).  (Closes: #431455)
   * Also check for /proc/$$.
Files: 
 c198c82748dcef15408868ffca07ba2d 752 libs optional elfutils_0.128-1.dsc
 4da87e49616101ec256e313218c421ef 1343313 libs optional 
elfutils_0.128.orig.tar.gz
 1d466a7004c5d43e1448797deb7fd315 175469 libs optional elfutils_0.128-1.diff.gz
 bc1757022831dc72093ff7b291887ec3 607346 utils optional 
elfutils_0.128-1_amd64.deb
 45560fda9bfdfee4cf8871a5c2734ba6 41334 libs optional libelf1_0.128-1_amd64.deb
 2126aa3387a20e799f06d4197c85362c 58444 libdevel optional 
libelf-dev_0.128-1_amd64.deb
 4375cafeb16b398d8b44913b05210b92 65426 libdevel optional 
libebl-dev_0.128-1_amd64.deb
 9efb1f3a0a270f16b725eec269a26146 86984 libdevel optional 
libdw-dev_0.128-1_amd64.deb
 56a5f06836844d7224dceb39fc9206ce 20192 libs optional libasm1_0.128-1_amd64.deb
 7dc93d530ef39a0f0f0b34407c966c41 22924 libdevel optional 
libasm-dev_0.128-1_amd64.deb

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

iD8DBQFGlAZFQdwckHJElwsRAs4tAJ9dbj8LU76Xs0C40ZEDyeNWIVx5rwCg1/0A
3rOIwnLOtrS437eFQJqSAe8=
=TOMn
-END PGP SIGNATURE-


Accepted:
elfutils_0.128-1.diff.gz
  to pool/main/e/elfutils/elfutils_0.128-1.diff.gz
elfutils_0.128-1.dsc
  to pool/main/e/elfutils/elfutils_0.128-1.dsc
elfutils_0.128-1_amd64.deb
  to pool/main/e/elfutils/elfutils_0.128-1_amd64.deb
elfutils_0.128.orig.tar.gz
  to pool/main/e/elfutils/elfutils_0.128.orig.tar.gz
libasm-dev_0.128-1_amd64.deb
  to pool/main/e/elfutils/libasm-dev_0.128-1_amd64.deb
libasm1_0.128-1_amd64.deb
  to pool/main/e/elfutils/libasm1_0.128-1_amd64.deb
libdw-dev_0.128-1_amd64.deb
  to pool/main/e/elfutils/libdw-dev_0.128-1_amd64.deb
libebl-dev_0.128-1_amd64.deb
  to pool/main/e/elfutils/libebl-dev_0.128-1_amd64.deb
libelf-dev_0.128-1_amd64.deb
  to pool/main/e/elfutils/libelf-dev_0.128-1_amd64.deb
libelf1_0.128-1_amd64.deb
  to pool/main/e/elfutils/libelf1_0.128-1_amd64.deb


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

Re: transition of packages into testing

[Kurt Roeckx]

On Thu, Jun 21, 2007 at 11:29:32PM +0300, Lars Wirzenius wrote:
 
 Another criterion is that it's built on all the architectures the
 previous version in testing is built on. It seems it's missing builds on
  ^^^

That should be unstable.

Anyway, the list of reasons why it doesn't migrate is at:
http://www.debian.org/devel/testing


Kurt


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

Re: Archive rebuild with improved dpkg-shlibdeps

[Kurt Roeckx]

On Thu, Jun 21, 2007 at 09:59:53AM +0100, Raphael Hertzog wrote:
 Hello,
 
 Lucas just rebuilt the archive with my new dpkg-shlibdeps and the symbols
 file that I provided him
 (http://people.debian.org/~hertzog/symbols.tar.bz2) and that I
 auto-generated.
 
 The resulting Packages file is here:
 http://people.debian.org/~hertzog/Packages.gz (it contains only
 binary-i386 and not the binary-all packages).
 
 The build logs of this rebuild are available on gluck:
 http://people.debian.org/~lucas/logs/2007/06/19/sym/
 
 You can check the build log of your packages and maybe you'll see warnings
 like those:
 dpkg-shlibdeps: warning: debian/a2ps/usr/bin/fixnt shouldn't be linked with 
 libpaper.so.1 ( it uses none of its symbols).
 - you could fix the build process so that it doesn't include -lpaper
 
 ace-of-penguins_1.2-8_sid32.buildlog:dpkg-shlibdeps: warning: Symbol [EMAIL 
 PROTECTED] used by debian/ace-of-penguins/usr/lib/libcards.so.1.0.0 found in 
 none of the libraries.  
 - here's you have the opposite problem, this library uses symbols from
 another library without being linked with it. You need to the appropriate
 -l flag (in this case -lX11).

This seems to do simular things as checklib
(http://rerun.lefant.net/checklib/), which gives simular warnings and
errors.

It could be useful to compare those results.


Kurt


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

Re: Dependencies on shared libs, take 2

[Kurt Roeckx]

On Wed, Jun 06, 2007 at 07:55:28PM +0200, Julien Cristau wrote:
 On Wed, Jun  6, 2007 at 17:50:26 +, Oleg Verych wrote:
 
  Just as better alternative IMHO, please consider using `eu-readelf -ds`
  from elfutils.
 
 elfutils isn't build-essential. binutils is, and does the job, so it's
 better IMHO isn't a particularly compelling reason to make all packages
 build-depend on a new package.

So use readelf (from binutils)?


Kurt


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

Re: Intention to drop sparc32 support for Lenny

[Kurt Roeckx]

On Mon, May 21, 2007 at 09:58:00AM -0700, Joe Buck wrote:
 On Mon, May 21, 2007 at 12:00:24PM +0200, Frans Pop wrote:
  The sparc32 port has been struggling for some time. Last month Jurij 
  Smakov, currently the most active Debian Sparc porter, raised the question 
  if support sparc32 should be dropped for Lenny [1].
 
 Fine, as long as you provide 32-bit as well as 64-bit userland.  Otherwise
 many programs will pay a substantial performance penalty, as pointer-heavy
 programs double their memory and I/O requirements (and Sparc doesn't get
 any compensating benefit the way x86-64 does from extra registers in
 64-bit mode).

I think it's going to stay 32 bit userland, just a 64 bit kernel,
and maybe some selected 64 bit libraries and programs.


Kurt


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

Re: [Help] AMD64 specific bug on libblitz0 (#424644)

[Kurt Roeckx]

On Fri, May 18, 2007 at 10:31:52AM +0200, Andreas Metzler wrote:
 On 2007-05-18 Andreas Tille [EMAIL PROTECTED] wrote:
  I would like to ask kindly for support regarding bug #424644 because
  I do not own any amd64 and thus feel unable to solve this problem.
 
  Any hints / patches?
 
 http://lists.debian.org/debian-devel/2007/05/msg00340.html

I can not reproduce the probem in unstable.  I do have the problem when
using the version from unstable in etch.  And libblitz0 is only in
unstable.

It's using a gnu hash section.  There are alot of things that don't
properly seem to be handeling it yet.  gcc was changed to use both the
old hash and the gnu hash to avoid such problems.


Kurt


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

Accepted elfutils 0.127-4 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 18 May 2007 13:41:35 +0200
Source: elfutils
Binary: libasm-dev libdw-dev elfutils libelf1 libasm1 libelf-dev libebl-dev
Architecture: source amd64
Version: 0.127-4
Distribution: unstable
Urgency: low
Maintainer: Kurt Roeckx [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 elfutils   - collection of utilities to handle ELF objects
 libasm-dev - libasm development libraries and header files
 libasm1- library with a programmable assembler interface
 libdw-dev  - library that provides access to the DWARF debug information
 libebl-dev - static library providing higher-level ELF access functionality
 libelf-dev - libelf1 development libraries and header files
 libelf1- library to read and write ELF files
Closes: 424548
Changes: 
 elfutils (0.127-4) unstable; urgency=low
 .
   * Use the gnu_inline attribute for inline functions so it build with
 gcc-4.2.  (Closes: #424548)
   * Add check for maps and auxv file in the proc dir to try and debug
 the sparc build failure.
Files: 
 6b5525ce010c046c349189d3cdea914e 752 libs optional elfutils_0.127-4.dsc
 c25b0ba70e89c18f53f52a415c5012a8 266976 libs optional elfutils_0.127-4.diff.gz
 927bb4427b32435128cadc47ec28acc2 528828 utils optional 
elfutils_0.127-4_amd64.deb
 608de752db42241cbcaf864679e34ba9 40612 libs optional libelf1_0.127-4_amd64.deb
 0b8178d2dfab062663521963b2608100 58106 libdevel optional 
libelf-dev_0.127-4_amd64.deb
 db812994e6722112fa95d2361dc175df 64630 libdevel optional 
libebl-dev_0.127-4_amd64.deb
 d1c8ee805252db445ec9713dbe6c09b8 86454 libdevel optional 
libdw-dev_0.127-4_amd64.deb
 bbd748ca81f839f72e87be5300e24573 19690 libs optional libasm1_0.127-4_amd64.deb
 df6549321e8b5fb9a0481047354e4fe6 22598 libdevel optional 
libasm-dev_0.127-4_amd64.deb

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

iD8DBQFGTZXlQdwckHJElwsRAmlhAJ9Cu8faoNjVmEt1WPIy+OkSZO0lywCgtBln
ZnssC0XMIfqWNVu4qb2hi8Q=
=nFNq
-END PGP SIGNATURE-


Accepted:
elfutils_0.127-4.diff.gz
  to pool/main/e/elfutils/elfutils_0.127-4.diff.gz
elfutils_0.127-4.dsc
  to pool/main/e/elfutils/elfutils_0.127-4.dsc
elfutils_0.127-4_amd64.deb
  to pool/main/e/elfutils/elfutils_0.127-4_amd64.deb
libasm-dev_0.127-4_amd64.deb
  to pool/main/e/elfutils/libasm-dev_0.127-4_amd64.deb
libasm1_0.127-4_amd64.deb
  to pool/main/e/elfutils/libasm1_0.127-4_amd64.deb
libdw-dev_0.127-4_amd64.deb
  to pool/main/e/elfutils/libdw-dev_0.127-4_amd64.deb
libebl-dev_0.127-4_amd64.deb
  to pool/main/e/elfutils/libebl-dev_0.127-4_amd64.deb
libelf-dev_0.127-4_amd64.deb
  to pool/main/e/elfutils/libelf-dev_0.127-4_amd64.deb
libelf1_0.127-4_amd64.deb
  to pool/main/e/elfutils/libelf1_0.127-4_amd64.deb


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

Re: Bug#424844: ITP: ircservices -- Nick/channel/other services for IRC networks

[Kurt Roeckx]

On Thu, May 17, 2007 at 01:04:21PM +0100, Tim Retout wrote:
 On Thu, 2007-05-17 at 13:41 +0200, Kurt Roeckx wrote:
 Several, according to the table at:
 http://www.ircservices.za.net/download/testing/docs/2.html#1
 
 I've tested with ircd-hybrid, but it should also do ircd-ircu and
 ircd-irc2. It might work with oftc-hybrid, if it's a close enough fork
 of ircd-hybrid, but I'm not sure.
 
 That leaves dancer-ircd, ngircd and rageircd, with which I assume it
 doesn't work.

ircd-irc2 is not on that list.  It does mention the 2.8 version, but
2.9, 2.10 and specially 2.11 have different server-server protocols.
The current 2.11 now refuses to talk to anything that doesn't claim it
supports 2.11, and we removed most of the backward compatibility code.

It's unlikely that it'll work with it if it's not mentioned.


Kurt


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

Accepted openssl 0.9.8e-5 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 15 May 2007 17:21:08 +
Source: openssl
Binary: libssl-dev openssl libssl0.9.8-dbg libcrypto0.9.8-udeb libssl0.9.8
Architecture: source amd64
Version: 0.9.8e-5
Distribution: unstable
Urgency: low
Maintainer: Debian OpenSSL Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libcrypto0.9.8-udeb - crypto shared library - udeb (udeb)
 libssl-dev - SSL development libraries, header files and documentation
 libssl0.9.8 - SSL shared libraries
 libssl0.9.8-dbg - Symbol tables for libssl and libcrypto
 openssl- Secure Socket Layer (SSL) binary and related cryptographic tools
Closes: 418584 418669 418670 418671 418679 418755 418768 418784 418785 419608 
419915 419959 420429 420461 420482 420833 420925 420986 421032 421336 421708 
422270
Changes: 
 openssl (0.9.8e-5) unstable; urgency=low
 .
   [ Christian Perrier ]
   * Debconf templates proofread and slightly rewritten by
 the debian-l10n-english team as part of the Smith Review Project.
 Closes: #418584
   * Debconf templates translations:
 - Arabic. Closes: #418669
 - Russian. Closes: #418670
 - Galician. Closes: #418671
 - Swedish. Closes: #418679
 - Korean. Closes: #418755
 - Czech. Closes: #418768
 - Basque. Closes: #418784
 - German. Closes: #418785
 - Traditional Chinese. Closes: #419915
 - Brazilian Portuguese. Closes: #419959
 - French. Closes: #420429
 - Italian. Closes: #420461
 - Japanese. Closes: #420482
 - Catalan. Closes: #420833
 - Dutch. Closes: #420925
 - Malayalam. Closes: #420986
 - Portuguese. Closes: #421032
 - Romanian. Closes: #421708
 .
   [ Kurt Roeckx ]
   * Remove the Provides for the udeb. Patch from Frans Pop. (Closes: #419608)
   * Updated Spanish debconf template.  (Closes: #421336)
   * Do the header changes, changing those defines into real functions,
 and bump the shlibs to match.
   * Update Japanese debconf translation.  (Closes: #422270)
Files: 
 9716a7d6316faff347264b2bda5ca06b 797 utils optional openssl_0.9.8e-5.dsc
 4e13fe6deac69939f1273dd26c758337 46634 utils optional openssl_0.9.8e-5.diff.gz
 d7cf481264ed3040c06bc237f6f5f8c9 1020050 utils optional 
openssl_0.9.8e-5_amd64.deb
 5b32a27a5374fbed1621c59fefb52a75 909138 libs important 
libssl0.9.8_0.9.8e-5_amd64.deb
 899368769078ed26292fc5d4525280c8 593160 debian-installer optional 
libcrypto0.9.8-udeb_0.9.8e-5_amd64.udeb
 44f25bc55108d76eab5476ce85942224 2196546 libdevel optional 
libssl-dev_0.9.8e-5_amd64.deb
 406e52b1839675fe7582715ff80ecbe3 1648518 libdevel extra 
libssl0.9.8-dbg_0.9.8e-5_amd64.deb
Package-Type: udeb

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

iD8DBQFGSe6iQdwckHJElwsRAsZYAJ0RMGTRPLG1/uihjMrMKZYjXGoZvQCg3XrG
w+AOu2QhiTgN9v7gV2SyH8E=
=C+xZ
-END PGP SIGNATURE-


Accepted:
libcrypto0.9.8-udeb_0.9.8e-5_amd64.udeb
  to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8e-5_amd64.udeb
libssl-dev_0.9.8e-5_amd64.deb
  to pool/main/o/openssl/libssl-dev_0.9.8e-5_amd64.deb
libssl0.9.8-dbg_0.9.8e-5_amd64.deb
  to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8e-5_amd64.deb
libssl0.9.8_0.9.8e-5_amd64.deb
  to pool/main/o/openssl/libssl0.9.8_0.9.8e-5_amd64.deb
openssl_0.9.8e-5.diff.gz
  to pool/main/o/openssl/openssl_0.9.8e-5.diff.gz
openssl_0.9.8e-5.dsc
  to pool/main/o/openssl/openssl_0.9.8e-5.dsc
openssl_0.9.8e-5_amd64.deb
  to pool/main/o/openssl/openssl_0.9.8e-5_amd64.deb


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

Accepted elfutils 0.127-2 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 May 2007 18:12:01 +0200
Source: elfutils
Binary: libasm-dev libdw-dev elfutils libelf1 libasm1 libelf-dev libebl-dev
Architecture: source amd64
Version: 0.127-2
Distribution: unstable
Urgency: low
Maintainer: Kurt Roeckx [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 elfutils   - collection of utilities to handle ELF objects
 libasm-dev - libasm development libraries and header files
 libasm1- library with a programmable assembler interface
 libdw-dev  - library that provides access to the DWARF debug information
 libebl-dev - static library providing higher-level ELF access functionality
 libelf-dev - libelf1 development libraries and header files
 libelf1- library to read and write ELF files
Closes: 393812 404091
Changes: 
 elfutils (0.127-2) unstable; urgency=low
 .
   * Remove duplicate initialization of DT_PLTRELSZ in elflint.
 (Closes: #393812)
   * Only using posix_fadvise() when we have POSIX_FADV_SEQUENTIAL since
 some arches like kFreeBSD don't support it.  (Closes: #404091)
   * Fix unalligned accesses on IA64.  Added patch unalligned.diff.
Files: 
 616bfa5d6d90323e9d9beecda1fdb160 752 libs optional elfutils_0.127-2.dsc
 5aac07113037bd9bdeb28fde01f07793 267186 libs optional elfutils_0.127-2.diff.gz
 f1e310f9cd3491752a155ae9b8b1dc91 528680 utils optional 
elfutils_0.127-2_amd64.deb
 0bb6f38189d51f093a994effa3b9128d 40446 libs optional libelf1_0.127-2_amd64.deb
 77b278d9877d52dcbd88ae76f430bab9 57924 libdevel optional 
libelf-dev_0.127-2_amd64.deb
 556d140b3b597098c3f81663d3796736 64472 libdevel optional 
libebl-dev_0.127-2_amd64.deb
 35c6c5d50412952d51821a2c3dc0ad6f 86276 libdevel optional 
libdw-dev_0.127-2_amd64.deb
 148964cbe2c748b1b7a4172195d533f0 19530 libs optional libasm1_0.127-2_amd64.deb
 2efd1429338778352e14195c0e693a30 22430 libdevel optional 
libasm-dev_0.127-2_amd64.deb

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

iD8DBQFGRzv2QdwckHJElwsRAvy+AJsFJ0W47Ad6IZxGeUJmebNUS55XFwCfcbWf
bx8KKy6GqiWAh3VZbZvOXIk=
=J8U8
-END PGP SIGNATURE-


Accepted:
elfutils_0.127-2.diff.gz
  to pool/main/e/elfutils/elfutils_0.127-2.diff.gz
elfutils_0.127-2.dsc
  to pool/main/e/elfutils/elfutils_0.127-2.dsc
elfutils_0.127-2_amd64.deb
  to pool/main/e/elfutils/elfutils_0.127-2_amd64.deb
libasm-dev_0.127-2_amd64.deb
  to pool/main/e/elfutils/libasm-dev_0.127-2_amd64.deb
libasm1_0.127-2_amd64.deb
  to pool/main/e/elfutils/libasm1_0.127-2_amd64.deb
libdw-dev_0.127-2_amd64.deb
  to pool/main/e/elfutils/libdw-dev_0.127-2_amd64.deb
libebl-dev_0.127-2_amd64.deb
  to pool/main/e/elfutils/libebl-dev_0.127-2_amd64.deb
libelf-dev_0.127-2_amd64.deb
  to pool/main/e/elfutils/libelf-dev_0.127-2_amd64.deb
libelf1_0.127-2_amd64.deb
  to pool/main/e/elfutils/libelf1_0.127-2_amd64.deb


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

Accepted elfutils 0.127-3 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 13 May 2007 22:48:57 +0200
Source: elfutils
Binary: libasm-dev libdw-dev elfutils libelf1 libasm1 libelf-dev libebl-dev
Architecture: source amd64
Version: 0.127-3
Distribution: unstable
Urgency: low
Maintainer: Kurt Roeckx [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 elfutils   - collection of utilities to handle ELF objects
 libasm-dev - libasm development libraries and header files
 libasm1- library with a programmable assembler interface
 libdw-dev  - library that provides access to the DWARF debug information
 libebl-dev - static library providing higher-level ELF access functionality
 libelf-dev - libelf1 development libraries and header files
 libelf1- library to read and write ELF files
Changes: 
 elfutils (0.127-3) unstable; urgency=low
 .
   * Update unaligned patch to also work when we're using -O2.
Files: 
 5933a7ec5d7082cb5c85b68e652b557c 752 libs optional elfutils_0.127-3.dsc
 79c0c70c004a07fe30d5b2154b9128b0 265344 libs optional elfutils_0.127-3.diff.gz
 25fb1d077db3e2118d7358afe0ab4fc1 528720 utils optional 
elfutils_0.127-3_amd64.deb
 17be6e6f36196752e51c556a1a672654 40486 libs optional libelf1_0.127-3_amd64.deb
 35eddc4eabdd7106efc2284f9542187b 57964 libdevel optional 
libelf-dev_0.127-3_amd64.deb
 a3aaf7ab2dff6246501fa8e5a16258da 64510 libdevel optional 
libebl-dev_0.127-3_amd64.deb
 82632330a9174143435cbb0eb82deaa9 86296 libdevel optional 
libdw-dev_0.127-3_amd64.deb
 4fc2f0c6e4df6660c673cc3f2e4bd8f2 19560 libs optional libasm1_0.127-3_amd64.deb
 3d45782c73a5df84112046972de3f681 22450 libdevel optional 
libasm-dev_0.127-3_amd64.deb

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

iD8DBQFGR3vdQdwckHJElwsRAmU4AJ46l8dbd2+FNVNE1PmKQ+6bx2ywNwCg09Gq
UhdrehOCXcEXbjeZbZXOmDM=
=OCtg
-END PGP SIGNATURE-


Accepted:
elfutils_0.127-3.diff.gz
  to pool/main/e/elfutils/elfutils_0.127-3.diff.gz
elfutils_0.127-3.dsc
  to pool/main/e/elfutils/elfutils_0.127-3.dsc
elfutils_0.127-3_amd64.deb
  to pool/main/e/elfutils/elfutils_0.127-3_amd64.deb
libasm-dev_0.127-3_amd64.deb
  to pool/main/e/elfutils/libasm-dev_0.127-3_amd64.deb
libasm1_0.127-3_amd64.deb
  to pool/main/e/elfutils/libasm1_0.127-3_amd64.deb
libdw-dev_0.127-3_amd64.deb
  to pool/main/e/elfutils/libdw-dev_0.127-3_amd64.deb
libebl-dev_0.127-3_amd64.deb
  to pool/main/e/elfutils/libebl-dev_0.127-3_amd64.deb
libelf-dev_0.127-3_amd64.deb
  to pool/main/e/elfutils/libelf-dev_0.127-3_amd64.deb
libelf1_0.127-3_amd64.deb
  to pool/main/e/elfutils/libelf1_0.127-3_amd64.deb


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

Re: Mandatory -dbg packages for libraries?

[Kurt Roeckx]

On Mon, May 07, 2007 at 01:02:17PM +0200, Wouter Verhelst wrote:
 On Mon, Apr 23, 2007 at 12:32:37AM +0200, Kurt Roeckx wrote:
  On Sun, Apr 22, 2007 at 11:15:36PM +0100, Roger Leigh wrote:
   
   If there are concerns over archive size, why don't we drop all static
   .a libraries at the same time.  Given that in Debian we typically
   always link dynamically, is there a need for .a libraries in all but a
   handful of cases?
  
  Dropping most .a libraries is something I agree with.  I see no reason
  why we should have them for most of the libraries.
 
 As a courtesy to our users. Statically linked programs are slightly
 faster (since they don't need to do PLT lookups, so they spare a jump on
 every function call to a shared object). For people for whom performance
 is critical, providing .a libraries is a good idea.

I agree that for some things it might be useful for have static
libraries, but in most cases they're not.


Kurt


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

Re: Bug#422423: ITP: libtool-cvs -- Generic library support script - CVS snapshot

[Kurt Roeckx]

On Mon, May 07, 2007 at 06:18:57PM +0200, Piotr Roszatycki wrote:
 2007/5/7, Florian Weimer [EMAIL PROTECTED]:
 * Mike Hommey:
 
  Why not package this as libtool and upload to experimental ?
 
 It would be impossible to build-depend on it.  This may or may not be
 a good thing.
 
 I think the including libtool from cvs snapshot to the unstable
 distribution might be good for its development process. More people
 will use it and then more people will report the bugs.
 
 Nevertheless, I'm uloading the packages as libtool/experimental. My
 packages are located at http://people.debian.org/~dexter/libtool/

Please use a version of 1.9.  It's not because upstream now calls this
2.1a that it won't be released as 2.0.


Kurt


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

Re: Bug#422423: ITP: libtool-cvs -- Generic library support script - CVS snapshot

[Kurt Roeckx]

On Sun, May 06, 2007 at 11:06:44AM +0200, Piotr Roszatycki wrote:
   Version : 2.1a (2007-04-10)
   Upstream Author : [EMAIL PROTECTED]
  * URL : http://www.gnu.org/software/libtool/
  * License : GPL
   Programming Lang: Shell
   Description : Generic library support script - CVS snapshot
 
 Why not package this as libtool and upload to experimental ?
 
 Mike
 
 Look at the libtool's website:
 
 Stable Release: 1.5.22
 Development Release of Stable Branch:  1.5.23b
 Daily CVS Snapshot of Stable Branch: 1.5.23c
 Development Release:  1.9f
 Daily CVS Snapshot: 2.1a
 
 Tell me, which version should go to experimental branch? I think the
 daily CVS snapshot should be packaged as separate package.

The 2-0 branch didn't see any commit for ages.  Everything is
happening in head, so 2.1a.  I have no idea if they ever plan to release
2.0.


Kurt


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

Accepted elfutils 0.127-1 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat,  5 May 2007 15:59:46 +0200
Source: elfutils
Binary: libasm-dev libdw-dev elfutils libelf1 libasm1 libelf-dev libebl-dev
Architecture: source amd64
Version: 0.127-1
Distribution: unstable
Urgency: low
Maintainer: Kurt Roeckx [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 elfutils   - collection of utilities to handle ELF objects
 libasm-dev - libasm development libraries and header files
 libasm1- library with a programmable assembler interface
 libdw-dev  - library that provides access to the DWARF debug information
 libebl-dev - static library providing higher-level ELF access functionality
 libelf-dev - libelf1 development libraries and header files
 libelf1- library to read and write ELF files
Changes: 
 elfutils (0.127-1) unstable; urgency=low
 .
   * New upstream release:
 Remove patches applied upstream: fix-testsuite.diff, maintainer_mode.diff,
 fix-distclean-to-really-distclean.diff, sparc_retval-backend.diff,
 elflint-alpha.diff, fix-readelf.diff, fix-alignment-sparc.diff,
 native-pid.diff, unalligned-endian.diff
   * register_name() got replaced by register_info().  Update backends
 to add dwarf type and number of bits info for those backends:
 alpha, arm, hppa, mips
   * Added redhat-strip-copy-symtab.diff patch.  Inlucde
 testfile16.symtab.bz2 and testfile16.symtab.debug.bz2 test files.
 Add sharutils to build-depends for uudecode.
   * Updated redhat-portability.diff: Now includes fix-mipsel-ftbfs.diff
 so remove it.
   * Add various types to elf.h
   * Update watch file to use a different url.
Files: 
 a694265b4651c629a392eee88d03 752 libs optional elfutils_0.127-1.dsc
 905411e1deda0aee17ae99dbdeaf7506 1247883 libs optional 
elfutils_0.127.orig.tar.gz
 bce6f19b187d10d68418dae0ef7a8279 263388 libs optional elfutils_0.127-1.diff.gz
 78e38da17bf653b76acdbfb1dcc15b70 528486 utils optional 
elfutils_0.127-1_amd64.deb
 a2c50a82a37a64c15671bd3117f00e97 40254 libs optional libelf1_0.127-1_amd64.deb
 d954e7e2e086006314035ddf47b2fb15 57806 libdevel optional 
libelf-dev_0.127-1_amd64.deb
 e01ad2f5e5cde31760963010d63d8a9d 64286 libdevel optional 
libebl-dev_0.127-1_amd64.deb
 8c4ffdd3bf664aa3497dc9d1bcee4315 86098 libdevel optional 
libdw-dev_0.127-1_amd64.deb
 4f148a8caa21ea23a157571ef3d1b8d9 19332 libs optional libasm1_0.127-1_amd64.deb
 01432d4f48c3697f3f201ca5f272cd3b 22230 libdevel optional 
libasm-dev_0.127-1_amd64.deb

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

iD8DBQFGPKWHQdwckHJElwsRAt/sAJ45lwuLUoT2aYIH2l8YfuF9emrC3wCfSAKX
J0BjvXzLfxT8CLqqxHEI3XI=
=GGb6
-END PGP SIGNATURE-


Accepted:
elfutils_0.127-1.diff.gz
  to pool/main/e/elfutils/elfutils_0.127-1.diff.gz
elfutils_0.127-1.dsc
  to pool/main/e/elfutils/elfutils_0.127-1.dsc
elfutils_0.127-1_amd64.deb
  to pool/main/e/elfutils/elfutils_0.127-1_amd64.deb
elfutils_0.127.orig.tar.gz
  to pool/main/e/elfutils/elfutils_0.127.orig.tar.gz
libasm-dev_0.127-1_amd64.deb
  to pool/main/e/elfutils/libasm-dev_0.127-1_amd64.deb
libasm1_0.127-1_amd64.deb
  to pool/main/e/elfutils/libasm1_0.127-1_amd64.deb
libdw-dev_0.127-1_amd64.deb
  to pool/main/e/elfutils/libdw-dev_0.127-1_amd64.deb
libebl-dev_0.127-1_amd64.deb
  to pool/main/e/elfutils/libebl-dev_0.127-1_amd64.deb
libelf-dev_0.127-1_amd64.deb
  to pool/main/e/elfutils/libelf-dev_0.127-1_amd64.deb
libelf1_0.127-1_amd64.deb
  to pool/main/e/elfutils/libelf1_0.127-1_amd64.deb


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

Re: Bug#388701: Why Beryl has just four packages?

[Kurt Roeckx]

On Wed, Feb 14, 2007 at 11:55:30AM -0500, Shawn Starr wrote:
 On Wednesday 14 February 2007 00:27, Anibal Avelar wrote:
  Hi. I see you have in queue NEW three packages: beryl-plugins,
  beryl-settings and emerald [1] and not ready (yet) beryl.
 
 Firstly,  the beryl packages were REJECTED because of license issues. 
 Upstream 
 is working with me on resolving the non-free/license issues that remain these 
 will be fixed for the 0.2.0 stable release of Beryl  (coming soon).

From their homepage:
Mar 14: 0.2.0 Released

But they also already have 0.2.1 versions available.


Kurt


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

Re: Mandatory -dbg packages for libraries?

[Kurt Roeckx]

On Sun, Apr 22, 2007 at 04:40:45PM -0500, Steve Greenland wrote:
 On 22-Apr-07, 16:22 (CDT), Robert Collins [EMAIL PROTECTED] wrote: 
  
  Because segfaults are often not easily reproduced. Having the ability to
  analyse a crash that occured when the user did not have the -dbg
  packages installed is not possible unless you have the original symbols
  the compiler created.
 
 That's an argument in favor of making the base library package built
 with debug symbols and then stripped[1], not of requiring -dbg packages.

Maybe you should take a look at what dh_strip and -dbg packages do.  It
strips the debug symbols and puts it in a seperate file that's put in
/usr/lib/debug.  You put those files with debug symbols only in the -dbg
package.

This means that you can just install the -dbg package and gdb will
automaticly pick up the debug symbols, without needing to rebuild
anything.


See objcopy's --only-keep-debug and --add-gnu-debuglink options.
(It's also in strip's manpage)


Kurt


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

Re: Mandatory -dbg packages for libraries?

[Kurt Roeckx]

On Sun, Apr 22, 2007 at 11:15:36PM +0100, Roger Leigh wrote:
 
 If there are concerns over archive size, why don't we drop all static
 .a libraries at the same time.  Given that in Debian we typically
 always link dynamically, is there a need for .a libraries in all but a
 handful of cases?

Dropping most .a libraries is something I agree with.  I see no reason
why we should have them for most of the libraries.


Kurt


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

Re: Linux/Debian documentation suggestion

[Kurt Roeckx]

On Tue, Apr 17, 2007 at 05:10:20PM -0500, Steve Greenland wrote:
 
  *If I want or need command xxzz, which packages can give me that?
 
 You'll need to explore the packages website.

You mean the search page on packages.debian.org called
Search the contents of packages?  Which just like apt-file is an
interface to the Contents files that is on the ftp site?


Kurt


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

Re: The number of etch installations is rocketing...

[Kurt Roeckx]

On Thu, Apr 12, 2007 at 09:24:38PM +0200, Robert Millan wrote:
 On Thu, Apr 12, 2007 at 01:49:19PM +0200, Petter Reinholdtsen wrote:
  
  Actually, I've considered adding hardware reporting to popcon, using a
  separate question (or more options, not sure which), and hardware
  reports do not need to be sent as often as package usage.  Such
  report-once setting should report the output of lsmod, lspci,
  dmidecode, lsusb etc, to allow us to know what hardware is in use out
  there.
 
 I would be very interested in an i386-only feature to report wether the CPU
 is 64-bit capable (I have code in win32-loader with this functionality).
 
 I'm not sure how this would fit in your client/server protocol, but I can
 easily grab the code from win32-loader and integrate it if you tell me.

You can also see this by looking at /proc/cpuinfo looking for lm in
flags.


Kurt


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

Re: Not-so-mass bug filing for the patented IDEA algorithm

[Kurt Roeckx]

On Tue, Apr 10, 2007 at 03:01:41PM +0200, Florian Weimer wrote:
 * Neil Williams:
 
  Which are the offending libraries?
 
 Botan, Crypto++, BouncyCastle, a few Perl-related packages.

Openssl's README.Debian contains:
Some algorithms used in the library are covered by patents.  As
a result, the following algorithms in libcrypto have been disabled:
- RC5
- MDC2
- IDEA

(See bug #65368)

As far as I understand, they have been disabled because at that time,
it seems we only cared about using those, not about distributing them.


Kurt


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

Re: many rejects (Re: Second call for votes for the debian project leader election 2007)

[Kurt Roeckx]

On Thu, Mar 29, 2007 at 10:00:19AM +0200, Michal ?iha? wrote:
 Hi
  
  __ gpg --homedir=.  --keyring debian-keyring.gpg --keyring 
  debian-keyring.pgp --with-colons --list-keys 0x05C78623
  pub:-:1024:17:DC3552E836E75604:2004-01-10:::-:Michal ?x8ciha?x99 [EMAIL 
  PROTECTED]::scESC:
[...]
  
  See? Don't sign with a key that is not in the debian keyring
   yet.

DC3552E836E75604 seems to be in the keyring to me.

 I really don't get which key is not there. I signed with my same key,
 which worked for unencrypted voting and which worked on previous GR
 vote. I was really not able to decode what went wrong from message I
 got, it seems to complain about missing secret key for my key, which
 is okay. Does encrypt to self break voting?

If you encrypt to yourself, how is the voting system supposed to decrypt
it?

You also encrypted to the key that was generated for this vote, which
looks good.  Did you encrypt it twice or something?


Kurt


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

Re: Unable to upload pacakge

[Kurt Roeckx]

On Wed, Mar 28, 2007 at 10:14:46AM +0100, Cai Qian wrote:
 Hi,
 
 I tried to upload pacakge to anonymous ftp master through passive FTP
 method. However, I have always got the following error,

Check that you uploaded the binaries in binary mode and not in text
mode.  I think I got that (confusing) error message too because of it.


Kurt


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

Accepted openssl 0.9.8e-4 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 10 Mar 2007 17:11:46 +
Source: openssl
Binary: libssl-dev openssl libssl0.9.8-dbg libcrypto0.9.8-udeb libssl0.9.8
Architecture: source amd64
Version: 0.9.8e-4
Distribution: unstable
Urgency: low
Maintainer: Debian OpenSSL Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libcrypto0.9.8-udeb - crypto shared library - udeb (udeb)
 libssl-dev - SSL development libraries, header files and documentation
 libssl0.9.8 - SSL shared libraries
 libssl0.9.8-dbg - Symbol tables for libssl and libcrypt
 openssl- Secure Socket Layer (SSL) binary and related cryptographic tools
Closes: 414283
Changes: 
 openssl (0.9.8e-4) unstable; urgency=low
 .
   * openssl should depend on libssl0.9.8 0.9.8e-1 since it
 uses some of the defines that changed to functions.
 Other things build against libssl or libcrypto shouldn't
 have this problem since they use the old headers.
 (Closes: #414283)
Files: 
 a0b0929a8fcbd0b449ebfcf97e08a638 797 utils optional openssl_0.9.8e-4.dsc
 26d28d5706201be447da652dbbff488f 44265 utils optional openssl_0.9.8e-4.diff.gz
 d9bbb42711eb5a8b8ff04e67234c84a9 1008548 utils optional 
openssl_0.9.8e-4_amd64.deb
 b5efbd5b617177eb45cf5b09d0231775 896292 libs important 
libssl0.9.8_0.9.8e-4_amd64.deb
 c05afeb0e5bd440b9a510a1d97ddfe06 582070 debian-installer optional 
libcrypto0.9.8-udeb_0.9.8e-4_amd64.udeb
 ce80e993867d598a58ea5d0acb6d19aa 2187852 libdevel optional 
libssl-dev_0.9.8e-4_amd64.deb
 69683176ab63db963b4230e6dd4ab61b 1658822 libdevel extra 
libssl0.9.8-dbg_0.9.8e-4_amd64.deb
Package-Type: udeb

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

iD8DBQFF8uodQdwckHJElwsRAiF1AKCd4EQsDAH44sid11EEqMS30TFn/gCg5v/N
hNXv1WEv83OxrOkG3llNELI=
=5mh+
-END PGP SIGNATURE-


Accepted:
libcrypto0.9.8-udeb_0.9.8e-4_amd64.udeb
  to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8e-4_amd64.udeb
libssl-dev_0.9.8e-4_amd64.deb
  to pool/main/o/openssl/libssl-dev_0.9.8e-4_amd64.deb
libssl0.9.8-dbg_0.9.8e-4_amd64.deb
  to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8e-4_amd64.deb
libssl0.9.8_0.9.8e-4_amd64.deb
  to pool/main/o/openssl/libssl0.9.8_0.9.8e-4_amd64.deb
openssl_0.9.8e-4.diff.gz
  to pool/main/o/openssl/openssl_0.9.8e-4.diff.gz
openssl_0.9.8e-4.dsc
  to pool/main/o/openssl/openssl_0.9.8e-4.dsc
openssl_0.9.8e-4_amd64.deb
  to pool/main/o/openssl/openssl_0.9.8e-4_amd64.deb


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

Accepted openntpd 3.9p1-4 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon,  5 Mar 2007 18:40:48 +0100
Source: openntpd
Binary: openntpd
Architecture: source amd64
Version: 3.9p1-4
Distribution: unstable
Urgency: low
Maintainer: Kurt Roeckx [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 openntpd   - OpenBSD NTP daemon
Closes: 392250
Changes: 
 openntpd (3.9p1-4) unstable; urgency=low
 .
   * Reconnect after an EINVAL to make it work with dynamic IP
 addresses.  (Closes: #392250)
Files: 
 56711491da76d1f6cd6e54519f1eb318 609 net optional openntpd_3.9p1-4.dsc
 5164543d0bfd187de93360042b194bc3 6376 net optional openntpd_3.9p1-4.diff.gz
 a66296a237a1edb0428d72fd650995a4 44894 net optional openntpd_3.9p1-4_amd64.deb

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

iD8DBQFF7Fp+QdwckHJElwsRAv8rAJ4+HVNafPInNK93AXdQi2ei9IJD5gCcCF2W
B2fetYBoZ8CR9JANpJb92Ms=
=ILZt
-END PGP SIGNATURE-


Accepted:
openntpd_3.9p1-4.diff.gz
  to pool/main/o/openntpd/openntpd_3.9p1-4.diff.gz
openntpd_3.9p1-4.dsc
  to pool/main/o/openntpd/openntpd_3.9p1-4.dsc
openntpd_3.9p1-4_amd64.deb
  to pool/main/o/openntpd/openntpd_3.9p1-4_amd64.deb


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

Accepted ntp 1:4.2.2.p4+dfsg-2 (source all amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun,  4 Mar 2007 13:01:11 +
Source: ntp
Binary: ntp-simple ntp-refclock ntp-doc ntpdate ntp
Architecture: source all amd64
Version: 1:4.2.2.p4+dfsg-2
Distribution: unstable
Urgency: low
Maintainer: Debian NTP Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 ntp- Network Time Protocol daemon and utility programs
 ntp-doc- Network Time Protocol documentation
 ntp-refclock - transition package
 ntp-simple - transition package
 ntpdate- client for setting system time from NTP servers
Closes: 385334 401847 410383 411200 411809
Changes: 
 ntp (1:4.2.2.p4+dfsg-2) unstable; urgency=low
 .
   [ Peter Eisentraut ]
   * Removed obsolete logcheck entry
   * Improved formatting and fixed random whitespace in cron job
 .
   [ Kurt Roeckx ]
   * Set a default restriction list for ipv6 too. (Closes: #411809)
   * Stop using dhcp provided servers on release and stop.  Thanks
 to Torne [EMAIL PROTECTED] (Closes: #411200)
   * Don't use the nomodify option for localhost.  Modification
 is only allowed when authenticated, so having the nomodify
 option doesn't buy us anything.  It just prevents the resolver
 slave process who does authenticate itself from properly working
 (Closes: #385334, #401847)
   * Make sure that we disable ntp-server for everybody. (Closes: #410383)
Files: 
 c904652d2db412248b4d27f8799c25fe 888 net optional ntp_4.2.2.p4+dfsg-2.dsc
 9bc93802cbe1855374e4bcc90512b14c 175039 net optional 
ntp_4.2.2.p4+dfsg-2.diff.gz
 991c56fbe344f78dd9e01dbaf1c03b11 903892 doc optional 
ntp-doc_4.2.2.p4+dfsg-2_all.deb
 4dd3141f26f1fb186c0f58f821cb145d 28216 net optional 
ntp-simple_4.2.2.p4+dfsg-2_all.deb
 564a433f4302b06cafc902a809f4c0b0 28220 net optional 
ntp-refclock_4.2.2.p4+dfsg-2_all.deb
 23f6a3dead915c5ce7486e674989ba7b 356564 net optional 
ntp_4.2.2.p4+dfsg-2_amd64.deb
 0f21fff0ca0f9e86e745d5263a4a49cd 61180 net optional 
ntpdate_4.2.2.p4+dfsg-2_amd64.deb

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

iD8DBQFF6sRqQdwckHJElwsRAvwZAJ9CuxB/faVl+GqAWTp6rtA5PwkHPwCglwIr
5SJmHVCUuakEss8esFE9uLQ=
=m3sX
-END PGP SIGNATURE-


Accepted:
ntp-doc_4.2.2.p4+dfsg-2_all.deb
  to pool/main/n/ntp/ntp-doc_4.2.2.p4+dfsg-2_all.deb
ntp-refclock_4.2.2.p4+dfsg-2_all.deb
  to pool/main/n/ntp/ntp-refclock_4.2.2.p4+dfsg-2_all.deb
ntp-simple_4.2.2.p4+dfsg-2_all.deb
  to pool/main/n/ntp/ntp-simple_4.2.2.p4+dfsg-2_all.deb
ntp_4.2.2.p4+dfsg-2.diff.gz
  to pool/main/n/ntp/ntp_4.2.2.p4+dfsg-2.diff.gz
ntp_4.2.2.p4+dfsg-2.dsc
  to pool/main/n/ntp/ntp_4.2.2.p4+dfsg-2.dsc
ntp_4.2.2.p4+dfsg-2_amd64.deb
  to pool/main/n/ntp/ntp_4.2.2.p4+dfsg-2_amd64.deb
ntpdate_4.2.2.p4+dfsg-2_amd64.deb
  to pool/main/n/ntp/ntpdate_4.2.2.p4+dfsg-2_amd64.deb


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

Accepted openssl 0.9.8e-3 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun,  4 Mar 2007 23:22:51 +
Source: openssl
Binary: libssl-dev openssl libssl0.9.8-dbg libcrypto0.9.8-udeb libssl0.9.8
Architecture: source amd64
Version: 0.9.8e-3
Distribution: unstable
Urgency: low
Maintainer: Debian OpenSSL Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libcrypto0.9.8-udeb - crypto shared library - udeb (udeb)
 libssl-dev - SSL development libraries, header files and documentation
 libssl0.9.8 - SSL shared libraries
 libssl0.9.8-dbg - Symbol tables for libssl and libcrypt
 openssl- Secure Socket Layer (SSL) binary and related cryptographic tools
Closes: 391188 412979
Changes: 
 openssl (0.9.8e-3) unstable; urgency=low
 .
   * Add nagios-nrpe-server to the list of services to be checked
 (Closes: #391188)
   * EVP_CIPHER_CTX_key_length() should return the set key length in the
 EVP_CIPHER_CTX structure which may not be the same as the underlying
 cipher key length for variable length ciphers.
 From upstream CVS.  (Closes: #412979)
Files: 
 5ce874d82677f18c77dc1d41b60ce933 797 utils optional openssl_0.9.8e-3.dsc
 2766c3531454cefa264081a6d4a5d189 44153 utils optional openssl_0.9.8e-3.diff.gz
 c4111a29124cbadca45bf42c1958f5c8 1008444 utils optional 
openssl_0.9.8e-3_amd64.deb
 7f1dea74b94141f4daa0c5375f0d59f7 896186 libs important 
libssl0.9.8_0.9.8e-3_amd64.deb
 8fd4f8b0cfb62fae5c2c9aa0cfcd0a5c 582070 debian-installer optional 
libcrypto0.9.8-udeb_0.9.8e-3_amd64.udeb
 cb5faa5bf7ffe649b7ab6158737c9c2e 2187330 libdevel optional 
libssl-dev_0.9.8e-3_amd64.deb
 3b232036a4c44e81787c5f854f5eb610 1658694 libdevel extra 
libssl0.9.8-dbg_0.9.8e-3_amd64.deb
Package-Type: udeb

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

iD8DBQFF61dHQdwckHJElwsRAhnnAJ42KPtWRt8q3caopkfv7UCKGD7t6QCgh4e6
bwZsv+TwQtwBtwD+aYo2NXM=
=1hlM
-END PGP SIGNATURE-


Accepted:
libcrypto0.9.8-udeb_0.9.8e-3_amd64.udeb
  to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8e-3_amd64.udeb
libssl-dev_0.9.8e-3_amd64.deb
  to pool/main/o/openssl/libssl-dev_0.9.8e-3_amd64.deb
libssl0.9.8-dbg_0.9.8e-3_amd64.deb
  to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8e-3_amd64.deb
libssl0.9.8_0.9.8e-3_amd64.deb
  to pool/main/o/openssl/libssl0.9.8_0.9.8e-3_amd64.deb
openssl_0.9.8e-3.diff.gz
  to pool/main/o/openssl/openssl_0.9.8e-3.diff.gz
openssl_0.9.8e-3.dsc
  to pool/main/o/openssl/openssl_0.9.8e-3.dsc
openssl_0.9.8e-3_amd64.deb
  to pool/main/o/openssl/openssl_0.9.8e-3_amd64.deb


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

Re: Looking for a temporary account on Alpha

[Kurt Roeckx]

On Sun, Feb 25, 2007 at 09:33:08PM +0100, Frank B. Brokken wrote:
 Dear Steve Langasek, you wrote:
 
   The intention here is to use size_t in situations where the value is known
   to be non-negative.
  
  I don't see any reason why you should use size_t for that instead of
  unsigned int.  size_t is intended for use in describing the size of objects
  in memory, not just for anything you know should be non-negative.
 
 Hm, well, your observation is interesting, but I'm not convinced:
 
 https://www.securecoding.cert.org/confluence/display/seccode/INT01-A.+Use+size_t+for+all+integer+values+representing+the+size+of+an+object
 
[...]

They're all talking about sizes and arrays and things like that.  Things
were you run into problems because for instance your index can't represent
all the values it needs too.

Anyway, the problem is that it's not always using size_t.  You can't go
and use an int in one fuction, and then use a size_t in another function
for the same thing, and hope that you don't run into problems.

The compiler probably generated a warning or error about the type
mismatch.  And then it was ignored by explictly casting it so the types
match.  You should be careful when doing casts, and that wasn't a good
place to do one.


Kurt


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

Accepted openssl 0.9.8e-1 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 25 Feb 2007 18:06:28 +
Source: openssl
Binary: libssl-dev openssl libssl0.9.8-dbg libcrypto0.9.8-udeb libssl0.9.8
Architecture: source amd64
Version: 0.9.8e-1
Distribution: unstable
Urgency: low
Maintainer: Debian OpenSSL Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libcrypto0.9.8-udeb - crypto shared library - udeb (udeb)
 libssl-dev - SSL development libraries, header files and documentation
 libssl0.9.8 - SSL shared libraries
 libssl0.9.8-dbg - Symbol tables for libssl and libcrypt
 openssl- Secure Socket Layer (SSL) binary and related cryptographic tools
Closes: 221689 391191 407196 408157 408902 412326
Changes: 
 openssl (0.9.8e-1) unstable; urgency=low
 .
   * New upstream release
 - Inludes security fixes for CVE-2006-2937, CVE-2006-2940,
   CVE-2006-3738, CVE-2006-4343 (Closes: #408902)
 - s_client now properly works with SMTP.  Also added support
   for IMAP.  (closes: #221689)
   * Add clamav-freshclam and clamav-daemon to the list of service that
 need to be restarted.  (Closes: #391191)
   * Add armel support.  Thanks to Guillem Jover [EMAIL PROTECTED]
 for the patch.  (Closes: #407196)
   * Add Portuguese translations.  Thanks to Carlos Lisboa.  (Closes: 408157)
   * Add Norwegian translations.  Thanks to Bjørn Steensrud
 [EMAIL PROTECTED] (Closes: #412326)
Files: 
 df7a4e74409a8ece1ce78f0bd3839a17 797 utils optional openssl_0.9.8e-1.dsc
 3a7ff24f6ea5cd711984722ad654b927 3341665 utils optional 
openssl_0.9.8e.orig.tar.gz
 bd466dd1d8e3350c37b984ff73d7742e 41485 utils optional openssl_0.9.8e-1.diff.gz
 2a38196c6a3e494f77ac5fa442e8b5db 1008276 utils optional 
openssl_0.9.8e-1_amd64.deb
 9f6eff6c56748a073aa142bc3cd68bf8 895970 libs important 
libssl0.9.8_0.9.8e-1_amd64.deb
 413b44d7bfb44d2ebf3728a94a7d64e7 582072 debian-installer optional 
libcrypto0.9.8-udeb_0.9.8e-1_amd64.udeb
 2a58f10e3b30f08ebebd69286180767c 2187276 libdevel optional 
libssl-dev_0.9.8e-1_amd64.deb
 eeb0f0876b340c87faafc1d2375a3078 1658498 libdevel extra 
libssl0.9.8-dbg_0.9.8e-1_amd64.deb
Package-Type: udeb

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

iD8DBQFF4dJMQdwckHJElwsRAkk4AKDIpLu2q7fnG2Aa8hUW2y/o6xm1OgCgqd1j
8GtEq8BnMq1Uiqg3IdlVhiI=
=kCeB
-END PGP SIGNATURE-


Accepted:
libcrypto0.9.8-udeb_0.9.8e-1_amd64.udeb
  to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8e-1_amd64.udeb
libssl-dev_0.9.8e-1_amd64.deb
  to pool/main/o/openssl/libssl-dev_0.9.8e-1_amd64.deb
libssl0.9.8-dbg_0.9.8e-1_amd64.deb
  to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8e-1_amd64.deb
libssl0.9.8_0.9.8e-1_amd64.deb
  to pool/main/o/openssl/libssl0.9.8_0.9.8e-1_amd64.deb
openssl_0.9.8e-1.diff.gz
  to pool/main/o/openssl/openssl_0.9.8e-1.diff.gz
openssl_0.9.8e-1.dsc
  to pool/main/o/openssl/openssl_0.9.8e-1.dsc
openssl_0.9.8e-1_amd64.deb
  to pool/main/o/openssl/openssl_0.9.8e-1_amd64.deb
openssl_0.9.8e.orig.tar.gz
  to pool/main/o/openssl/openssl_0.9.8e.orig.tar.gz


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

Accepted openssl 0.9.8e-2 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 25 Feb 2007 19:19:19 +
Source: openssl
Binary: libssl-dev openssl libssl0.9.8-dbg libcrypto0.9.8-udeb libssl0.9.8
Architecture: source amd64
Version: 0.9.8e-2
Distribution: unstable
Urgency: low
Maintainer: Debian OpenSSL Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libcrypto0.9.8-udeb - crypto shared library - udeb (udeb)
 libssl-dev - SSL development libraries, header files and documentation
 libssl0.9.8 - SSL shared libraries
 libssl0.9.8-dbg - Symbol tables for libssl and libcrypt
 openssl- Secure Socket Layer (SSL) binary and related cryptographic tools
Changes: 
 openssl (0.9.8e-2) unstable; urgency=low
 .
   * Undo include changes that change defines into real functions,
 but keep the new functions in the library.
Files: 
 337d2ad76c9b59ff4c54f937331d7df4 797 utils optional openssl_0.9.8e-2.dsc
 01ad0d4180089dfd2c82d029681d1796 44290 utils optional openssl_0.9.8e-2.diff.gz
 534e8a525192d0a313bc286e11910db0 1008322 utils optional 
openssl_0.9.8e-2_amd64.deb
 4f6dda5e158f20625855c2748b406bde 896036 libs important 
libssl0.9.8_0.9.8e-2_amd64.deb
 f1f99902de3eeb1bee486bb70ba9d2d1 582072 debian-installer optional 
libcrypto0.9.8-udeb_0.9.8e-2_amd64.udeb
 a28fa39d94ed5f9031a6589dc59cfe8a 2187236 libdevel optional 
libssl-dev_0.9.8e-2_amd64.deb
 c61b71864006dc467da6fbe5fe9e26f1 1658538 libdevel extra 
libssl0.9.8-dbg_0.9.8e-2_amd64.deb
Package-Type: udeb

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

iD8DBQFF4esqQdwckHJElwsRArQnAKDNAZzpRJDLR75o8EOiYoRSkIVeTACgyHEb
J32Ers42tRLa5bPb6b5Sls8=
=hgrD
-END PGP SIGNATURE-


Accepted:
libcrypto0.9.8-udeb_0.9.8e-2_amd64.udeb
  to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8e-2_amd64.udeb
libssl-dev_0.9.8e-2_amd64.deb
  to pool/main/o/openssl/libssl-dev_0.9.8e-2_amd64.deb
libssl0.9.8-dbg_0.9.8e-2_amd64.deb
  to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8e-2_amd64.deb
libssl0.9.8_0.9.8e-2_amd64.deb
  to pool/main/o/openssl/libssl0.9.8_0.9.8e-2_amd64.deb
openssl_0.9.8e-2.diff.gz
  to pool/main/o/openssl/openssl_0.9.8e-2.diff.gz
openssl_0.9.8e-2.dsc
  to pool/main/o/openssl/openssl_0.9.8e-2.dsc
openssl_0.9.8e-2_amd64.deb
  to pool/main/o/openssl/openssl_0.9.8e-2_amd64.deb


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

Accepted libid3tag 0.15.1b-10 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 20 Jan 2007 16:57:31 +
Source: libid3tag
Binary: libid3tag0-dev libid3tag0
Architecture: source amd64
Version: 0.15.1b-10
Distribution: unstable
Urgency: low
Maintainer: Mad Maintainers [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libid3tag0 - ID3 tag reading library from the MAD project
 libid3tag0-dev - ID3 tag reading library from the MAD project
Changes: 
 libid3tag (0.15.1b-10) unstable; urgency=low
 .
   * Reupload with the the CVS directories.
Files: 
 cf658c09541ad39fd964a028d15cc37b 771 sound optional libid3tag_0.15.1b-10.dsc
 95d9f2df29cc1461ea25448c357ed4fc 6245 sound optional 
libid3tag_0.15.1b-10.diff.gz
 afcdcc1c676f78c7eb32392597624148 40394 libs optional 
libid3tag0_0.15.1b-10_amd64.deb
 58011803363b62220a181349b74ff957 46962 libdevel optional 
libid3tag0-dev_0.15.1b-10_amd64.deb

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

iD8DBQFFskq9QdwckHJElwsRAo3/AJwITumJACoFKwYlcUFW0RFFrwvCBQCgr1WG
bd5kjN9qw2kCCThMXQggCrE=
=/LOy
-END PGP SIGNATURE-


Accepted:
libid3tag0-dev_0.15.1b-10_amd64.deb
  to pool/main/libi/libid3tag/libid3tag0-dev_0.15.1b-10_amd64.deb
libid3tag0_0.15.1b-10_amd64.deb
  to pool/main/libi/libid3tag/libid3tag0_0.15.1b-10_amd64.deb
libid3tag_0.15.1b-10.diff.gz
  to pool/main/libi/libid3tag/libid3tag_0.15.1b-10.diff.gz
libid3tag_0.15.1b-10.dsc
  to pool/main/libi/libid3tag/libid3tag_0.15.1b-10.dsc


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

Accepted libid3tag 0.15.1b-9 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun, 14 Jan 2007 14:46:12 +
Source: libid3tag
Binary: libid3tag0-dev libid3tag0
Architecture: source amd64
Version: 0.15.1b-9
Distribution: unstable
Urgency: high
Maintainer: Mad Maintainers [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libid3tag0 - ID3 tag reading library from the MAD project
 libid3tag0-dev - ID3 tag reading library from the MAD project
Closes: 405801
Changes: 
 libid3tag (0.15.1b-9) unstable; urgency=high
 .
   * Handle unknown/invalid encodings in id3_compat_fixup().
 id3_parse_string() returns NULL in that case and then we got
 a segfault in id3_ucs4_length().  (Closes: #405801)
 Thanks to Andreas Henriksson [EMAIL PROTECTED]
Files: 
 450e2cef5ac9ed30499ec96b8dc44c27 769 sound optional libid3tag_0.15.1b-9.dsc
 456ddeb9cbb86b4cc9d91aa63df385f9 6542 sound optional 
libid3tag_0.15.1b-9.diff.gz
 61dd28f88dcbb69bcd2fc30de7e92465 40356 libs optional 
libid3tag0_0.15.1b-9_amd64.deb
 e280ff9dd6bc58b187ba9ccab14036b7 46894 libdevel optional 
libid3tag0-dev_0.15.1b-9_amd64.deb

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

iD8DBQFFqkTpQdwckHJElwsRAoYVAKCSCWdbQ6fc++VzM6AiygeyTO5/SwCdEI8D
XjlQKFisU1sMPWzEtG56DsY=
=IgBh
-END PGP SIGNATURE-


Accepted:
libid3tag0-dev_0.15.1b-9_amd64.deb
  to pool/main/libi/libid3tag/libid3tag0-dev_0.15.1b-9_amd64.deb
libid3tag0_0.15.1b-9_amd64.deb
  to pool/main/libi/libid3tag/libid3tag0_0.15.1b-9_amd64.deb
libid3tag_0.15.1b-9.diff.gz
  to pool/main/libi/libid3tag/libid3tag_0.15.1b-9.diff.gz
libid3tag_0.15.1b-9.dsc
  to pool/main/libi/libid3tag/libid3tag_0.15.1b-9.dsc


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

Re: Etch Software RAID Upgrade Trouble Suggested Installer Improvements

[Kurt Roeckx]

On Sat, Jan 06, 2007 at 10:56:33PM -0500, Roberto C. Sanchez wrote:
 On Sun, Jan 07, 2007 at 01:25:31PM +1100, Russell Coker wrote:
  On Saturday 06 January 2007 18:35, Claus Fischer 
  [EMAIL PROTECTED] wrote:
   1. Rescue mode needs MD devices
  
  The rescue mode of the installer needs a step
  to activate MD devices. Currently, only the plain
  disk partitions are visible; that's no help.
  
  Sounds like a reasonable request.  Filed a bug report?
  
  Note that it has to be an optional measure.
  
 Well, at the least it should scan for partitions marked as a RAID and
 prompt the user whether or not to start the set.

You basicly have to start the software raid configuration tool, and then
press finish.  After that it will see the drives.  I've filed a bug
about this some time ago:
http://bugs.debian.org/391474


Kurt


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

Re: Not depending on shlibs because of plugins?

[Kurt Roeckx]

On Fri, Jan 05, 2007 at 05:37:56PM +0100, Christoph Berg wrote:
 Hi,
 
 I'm packaging a database wrapper library (http://oss.devit.com/yada/).
 Its purpose is to provide one single API to a program and let the user
 configure if the database used is actually postgres/mysql/sqlite. The
 actual interfacing with the databases is done by .so plugins that are
 dlopened at run time.
 
 Currently my package will depend on all of the database libs:
 
 | Depends: [...], libmysqlclient15off (= 5.0.24-2), libpq4 (= 8.1.4), 
 libsqlite3-0 (= 3.3.8)

From the subject, I seem to understand that those are added by shlibs?
This seems to suggest that something in the package is linked to all the
libraries, and I don't see how you could remove it.

If it was only using dlopen(), you probably had to add those depends by
hand, which seem to be error prone to get the right versions.

If it's using dlopen(), you probably want to depend on the -dev packages,
unless you want to hardcode the complete name of the library instead of
the soname.  It probably already breaks if they're not installed.


Kurt


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

Re: Not depending on shlibs because of plugins?

[Kurt Roeckx]

On Fri, Jan 05, 2007 at 06:44:49PM +0100, Kurt Roeckx wrote:
 If it's using dlopen(), you probably want to depend on the -dev packages,
 unless you want to hardcode the complete name of the library instead of
 the soname.  It probably already breaks if they're not installed.

Of course soname is wrong there, I mean just the name of the library.


kurt


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

Re: Can ftpmasters do ONE SIMPLE THING?

[Kurt Roeckx]

On Sun, Dec 31, 2006 at 09:17:06AM -0500, Nathanael Nerode wrote:
 Namely, fix bug #224469.  It's really trivial and it's been waiting
 for over three years now.  This is just STUPID.
 
 Next DPL election, I want to see someone running on the platform of
 adding an extra ftpmaster *whether or not the current ftpmasters
 like it*.  Someone who will get simple stuff like this DONE.

Afaik, it can't be removed from unstable before oldstable is removed
from the main archive.


Kurt


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

Re: Explications needed...

[Kurt Roeckx]

On Fri, Dec 29, 2006 at 11:20:30AM +0100, Josselin Mouette wrote:
 An arm buildd maintainer not reading [EMAIL PROTECTED] is simply not
 doing his job as buildd maintainer. You can't pretend to be the one
 handling builds for the whole archive while not following discussions
 around problems specific to this architecture.

I think you're confusing the buildd admin with the porters.  I expect
porters to read the [EMAIL PROTECTED] list, I don't expect
the same from the buildd admin.

The buildd admin's job is getting packages built, while the porter's is
to deal with architecture specific issues.

The buildd admins aren't always also porters for that arch.  But I
think it would be a good thing that (some) porters also see all the
buildd logs.  That way they know alot faster about problems the port
might have.


Kurt


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

Accepted elfutils 0.123-3 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 21 Dec 2006 13:07:17 +0100
Source: elfutils
Binary: libasm-dev libdw-dev elfutils libelf1 libasm1 libelf-dev libebl-dev
Architecture: source amd64
Version: 0.123-3
Distribution: unstable
Urgency: low
Maintainer: Kurt Roeckx [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 elfutils   - collection of utilities to handle ELF objects
 libasm-dev - libasm development libraries and header files
 libasm1- library with a programmable assembler interface
 libdw-dev  - library that provides access to the DWARF debug information
 libebl-dev - static library providing higher-level ELF access functionality
 libelf-dev - libelf1 development libraries and header files
 libelf1- library to read and write ELF files
Closes: 404054
Changes: 
 elfutils (0.123-3) unstable; urgency=low
 .
   * Make libasm-dev conflict with libelfsh0-dev.  libelfsh0-dev.
 also ships an libasm.a on i386.  (Closes: #404054)
Files: 
 ccd795e2907abc64405c361d3d51e34a 741 libs optional elfutils_0.123-3.dsc
 36838391960237a21a538a822c9f6cc9 158826 libs optional elfutils_0.123-3.diff.gz
 c94d0ed8ec2c157bc34c7cbe59579281 499660 utils optional 
elfutils_0.123-3_amd64.deb
 d4ae1a5813f6de806ae643505012d591 39712 libs optional libelf1_0.123-3_amd64.deb
 4e5b64e10c5d111a2e5a4296619357ed 57092 libdevel optional 
libelf-dev_0.123-3_amd64.deb
 b32904ff74cce4510b8a10775190d715 62052 libdevel optional 
libebl-dev_0.123-3_amd64.deb
 1bcbc8dec2463a36c20e730ac218624d 83534 libdevel optional 
libdw-dev_0.123-3_amd64.deb
 aca71d4e05b9a9588811f18208bc0599 18842 libs optional libasm1_0.123-3_amd64.deb
 5d14c392c7210053e427f33177ee57cc 21616 libdevel optional 
libasm-dev_0.123-3_amd64.deb

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

iD8DBQFFinuIQdwckHJElwsRAig8AKC+/A4DUKR4z852Vl/JX06L6inLggCdF1mL
0RGNTpUND4XtwELDBX5d0Kk=
=LRSC
-END PGP SIGNATURE-


Accepted:
elfutils_0.123-3.diff.gz
  to pool/main/e/elfutils/elfutils_0.123-3.diff.gz
elfutils_0.123-3.dsc
  to pool/main/e/elfutils/elfutils_0.123-3.dsc
elfutils_0.123-3_amd64.deb
  to pool/main/e/elfutils/elfutils_0.123-3_amd64.deb
libasm-dev_0.123-3_amd64.deb
  to pool/main/e/elfutils/libasm-dev_0.123-3_amd64.deb
libasm1_0.123-3_amd64.deb
  to pool/main/e/elfutils/libasm1_0.123-3_amd64.deb
libdw-dev_0.123-3_amd64.deb
  to pool/main/e/elfutils/libdw-dev_0.123-3_amd64.deb
libebl-dev_0.123-3_amd64.deb
  to pool/main/e/elfutils/libebl-dev_0.123-3_amd64.deb
libelf-dev_0.123-3_amd64.deb
  to pool/main/e/elfutils/libelf-dev_0.123-3_amd64.deb
libelf1_0.123-3_amd64.deb
  to pool/main/e/elfutils/libelf1_0.123-3_amd64.deb


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

Re: Name of a binary package according to sonames

[Kurt Roeckx]

On Sun, Dec 17, 2006 at 06:07:18PM -0400, Jose Luis Rivas Contreras wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 I'm maintaining libtorrent package, this source builds 2 binaries,
 libtorrent-rakshasa (is libtorrent9 last version in debian archive) and
 libtorrent-rakshasa-dev (is libtorrent9 last version in debian archive),
 I get this warning from lintian when I build the package.
 
 Now running lintian...
 W: libtorrent-rakshasa: package-name-doesnt-match-sonames libtorrent10
 Finished running lintian.
 
 The version I'm building is libtorrent-0.11.0 so I don't think I should
 call the binary libtorrent10.

Please check the real soname with objdump -p libtorrent-0.11.0 |grep
SONAME


Kurt


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

Bug#403619: RFP: languagetool -- rule-based language checker

[Kurt Roeckx]

Package: wnpp
Severity: wishlist

Package name: languagetool
Version: 0.8.6
Upstream Author: Daniel Naber (naber at danielnaber de)
URL: http://www.danielnaber.de/languagetool
License: Mostly LGPL, also some BSD, Creative Commons Attribution ShareAlike 2.0
Description: A rule-based language checker

This is a rule-based language checker for which a rule is defined.
It can detect errors that a simple spell checker cannot detect e.g.
mixing up there/their, no/now etc. It can also detect a limited
amount of grammar mistakes.

It currently has support for English, German, Polish, and Dutch, and
limited support for French, Spanish, and Italian.

It can be used standalone, as plugin for openoffice.org, with LyX,
in java applications and as standalone web server.


I think this would be a useful thing to have in Debian, since we
currently don't seem to have something simular.  But I have no
intention to package this myself.


Kurt



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

Re: Name of a binary package according to sonames

[Kurt Roeckx]

On Mon, Dec 18, 2006 at 11:14:33AM -0400, Jose Luis Rivas Contreras wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
  On Sun, Dec 17, 2006 at 06:07:18PM -0400, Jose Luis Rivas Contreras wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  I'm maintaining libtorrent package, this source builds 2 binaries,
  libtorrent-rakshasa (is libtorrent9 last version in debian archive) and
  libtorrent-rakshasa-dev (is libtorrent9 last version in debian archive),
  I get this warning from lintian when I build the package.
 
  Now running lintian...
  W: libtorrent-rakshasa: package-name-doesnt-match-sonames libtorrent10
  Finished running lintian.
 
  The version I'm building is libtorrent-0.11.0 so I don't think I should
  call the binary libtorrent10.
  
  Please check the real soname with objdump -p libtorrent-0.11.0 |grep
  SONAME
 
 The real soname is libtorrent.so.10
 
 So, should I name it libtorrent10?

Either the soname should be libtorrent.so.11, or you might 
want to rename libtorrent-0.11.0 to libtorrent-0.10.0 or something.

If the soname really is and should be libtorrent.so.10, you want to name
it libtorrent-rakshasa10 or something.  But it should have the 10 in it.

From what I understand there are 2 incompatible libtorrent packages, so
you want to reflect that in the name of the package.


Kurt


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

Re: Name of a binary package according to sonames

[Kurt Roeckx]

On Mon, Dec 18, 2006 at 12:09:13PM -0400, Jose Luis Rivas Contreras wrote:
 
  The version I'm building is libtorrent-0.11.0 so I don't think I should
  call the binary libtorrent10.
  Please check the real soname with objdump -p libtorrent-0.11.0 |grep
  SONAME
  The real soname is libtorrent.so.10
 
  So, should I name it libtorrent10?
  
  Either the soname should be libtorrent.so.11, or you might 
  want to rename libtorrent-0.11.0 to libtorrent-0.10.0 or something.
 
 I can't that version already pass...

If the soname is set to libtorrent.so.10, it means applications will
start to look for a file called /usr/lib/libtorrent.so.10.  That will
probably be a symlink in your case to libtorrent-0.11.0, which looks
rather confusing to me.

In libtorrent9 you have a file called /usr/lib/libtorrent.so.9.  But
there doesn't seem to be a file named libtorrent-0.9.0.so or something,
so I'm a little confused what changed.


Kurt


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

Re: Name of a binary package according to sonames

[Kurt Roeckx]

On Mon, Dec 18, 2006 at 12:52:40PM -0400, Jose Luis Rivas Contreras wrote:
  If the soname is set to libtorrent.so.10, it means applications will
  start to look for a file called /usr/lib/libtorrent.so.10.  That will
  probably be a symlink in your case to libtorrent-0.11.0, which looks
  rather confusing to me.
  
  In libtorrent9 you have a file called /usr/lib/libtorrent.so.9.  But
  there doesn't seem to be a file named libtorrent-0.9.0.so or something,
  so I'm a little confused what changed.
 
 No, there's only libtorrent.so.10  libtorrent.so.10.0.0 in my build
 (libtorrent-0.11.0)

So, your source package is libtorrent version is 0.11.0, which has a
binary package libtorrent10-rakshasa with a library called
libtorrent.so.10, and also has that soname.  

That all looks good.

 I'm more confused since I renamed the package to libtorrent10-rakshasa
 and libtorrent-rakshasa10 and lintian keeps giving me the warning...

I think in this case you can probably ignore the warning.

Do you conflict with the -dev package of the other libtorrent package?
You'll both want to have a /usr/lib/libtorrent.so, so you should
conflict.

You probably now don't have a conflict with other library package now,
but at some point this might happen.  And I think this should be
avoided.

I think either one or both should really change the name of the library
itself, to avoid all confusion, and also make them not conflict.  For
instance, you could name it librakshasatorrent (or librtorrent).

The ideal solution would be that there really was only 1 libtorrent
package, and that both current of them worked on 1 library.


Kurt


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

Accepted openssl 0.9.8c-4 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 30 Nov 2006 20:57:46 +
Source: openssl
Binary: libssl-dev openssl libssl0.9.8-dbg libcrypto0.9.8-udeb libssl0.9.8
Architecture: source amd64
Version: 0.9.8c-4
Distribution: unstable
Urgency: low
Maintainer: Debian OpenSSL Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libcrypto0.9.8-udeb - crypto shared library - udeb (udeb)
 libssl-dev - SSL development libraries, header files and documentation
 libssl0.9.8 - SSL shared libraries
 libssl0.9.8-dbg - Symbol tables for libssl and libcrypt
 openssl- Secure Socket Layer (SSL) binary and related cryptographic tools
Closes: 387089 388108 393507 397151 400221
Changes: 
 openssl (0.9.8c-4) unstable; urgency=low
 .
   * Add German debconf translation.  Thanks to
 Johannes Starosta [EMAIL PROTECTED] (Closes: #388108)
   * Make c_rehash look for both .pem and .crt files.  Also make it support
 files in DER format.  Patch by Yauheni Kaliuta [EMAIL PROTECTED]
 (Closes: #387089)
   * Use  instead of  to check a flag in the X509 policy checking.
 Patch from upstream cvs.  (Closes: #397151)
   * Also restart slapd for security updates (Closes: #400221)
   * Add Romanian debconf translation.  Thanks to
 stan ioan-eugen [EMAIL PROTECTED] (Closes: #393507)
Files: 
 68a883140f22fff39efff32db08faf02 797 utils optional openssl_0.9.8c-4.dsc
 17aec47103a7fa329b285fe2785cb04d 43893 utils optional openssl_0.9.8c-4.diff.gz
 e00e196bb5d79a9e94ed7940e1189dd3 1004830 utils optional 
openssl_0.9.8c-4_amd64.deb
 9759ebab2406f5d3177c5d587dfb6854 890182 libs important 
libssl0.9.8_0.9.8c-4_amd64.deb
 a66e743548d15619dd9c01f0b2d72c59 580044 debian-installer optional 
libcrypto0.9.8-udeb_0.9.8c-4_amd64.udeb
 e82560644b9d2d3a264bc49b139766b0 2179208 libdevel optional 
libssl-dev_0.9.8c-4_amd64.deb
 5b0d10735c8928a55748bb3f5e843d41 1653862 libdevel extra 
libssl0.9.8-dbg_0.9.8c-4_amd64.deb
Package-Type: udeb

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

iD8DBQFFb1TVQdwckHJElwsRAiO+AKC3HQ5NrA/o9HbkEve1ABTClXAPvwCfYe/x
6V2NkAMyXV2aClFlBiLXXE4=
=d2cS
-END PGP SIGNATURE-


Accepted:
libcrypto0.9.8-udeb_0.9.8c-4_amd64.udeb
  to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8c-4_amd64.udeb
libssl-dev_0.9.8c-4_amd64.deb
  to pool/main/o/openssl/libssl-dev_0.9.8c-4_amd64.deb
libssl0.9.8-dbg_0.9.8c-4_amd64.deb
  to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8c-4_amd64.deb
libssl0.9.8_0.9.8c-4_amd64.deb
  to pool/main/o/openssl/libssl0.9.8_0.9.8c-4_amd64.deb
openssl_0.9.8c-4.diff.gz
  to pool/main/o/openssl/openssl_0.9.8c-4.diff.gz
openssl_0.9.8c-4.dsc
  to pool/main/o/openssl/openssl_0.9.8c-4.dsc
openssl_0.9.8c-4_amd64.deb
  to pool/main/o/openssl/openssl_0.9.8c-4_amd64.deb


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

Re: Debian Archive Automatic Signing Key (4.0/etch)?

[Kurt Roeckx]

On Tue, Nov 21, 2006 at 04:50:29PM -0600, Peter Samuelson wrote:
 
 [Martin Zobel-Helas]
  gpg --recv-keys A70DAF536070D3A1  (gpg --export -a A70DAF536070D3A1 | 
  apt-key add -)
 
 Uh, don't forget the part about verifying that the key is actually
 signed by the ftpmasters.  Skipping that step pretty much defeats the
 entire point.
 
   gpg --list-sigs A70DAF536070D3A1

Try gpg --check-sigs A70DAF536070D3A1 instead.


Kurt


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

Re: base-files: please ship /etc/networks and include link-local 169.254.0.0 to it

[Kurt Roeckx]

On Sun, Nov 19, 2006 at 09:05:08PM +0100, Marco d'Itri wrote:
 On Nov 19, Russ Allbery [EMAIL PROTECTED] wrote:
 
   I'd like to receive comments about:
   - shipping /etc/networks in netbase
   - adding 169.254.0.0 to it
  The second makes sense to me.
 I am not sure. For a start, I would need to add *all* /24 in the
 link-local networks space since /etc/networks comes from a pre-CIDR
 world.
 And I am not sure about which modern software still uses the file.

In the classful/pre-CIDR world, 169.254.0.0 would be a class B,
and so be a /16.


Kurt


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

Re: flock() and sendmail

[Kurt Roeckx]

On Thu, Nov 16, 2006 at 11:24:34AM -0800, Richard A Nelson wrote:
 On Thu, 16 Nov 2006, John Kelly wrote:
 
 I don't need NFS with sendmail.  Surely flock() is not *still* broken
 in 2.6 kernels?
 
 I doubt that flock is *still* broken - that was quite some time ago...

From the flock manpage:
NOTES
   flock(2) does not lock files over NFS.  Use fcntl(2) instead: that does
   work over NFS, given a sufficiently  recent  version  of  Linux  and  a
   server which supports locking.

The reason flock() doesn't work over NFS probably has to do with
that flock() and fcntl() locks don't interact with each other.

 **  NOTE: Override HASFLOCK as you will but, as of 1.99.6, mixed-style
 **  file locking is no longer allowed.  In particular, make sure
 **  your DBM library and sendmail are both using either flock(2)
 **  *or* fcntl(2) file locking, but not both.
 
 This, indeed, is the important part !  DB has changed alot, and now
 has its own locking system, and whatever it uses to lock the entire
 DB is what should be used by its callers.
 
 Has DB changed from fcntl to flock ?
 Are you trying to access the sendmail databases from another
 program that has differing locking conventions ?
 
 You fail to provide any hints as to on why fcntl which is used instead
 of flock is causing you grief.

If sendmail is using libdb, I don't see why sendmail would need to
use fcntl() or flock() on any libdb file.  It's an internal problem
of libdb how it should do it's locking before it updates the database.

However, sendmail might want to make sure that it's only updating it
once, and can do this is various ways.

As long as sendmail properly uses libdb, I don't see why there should
be any problem at all.


Anyway, from the linux/Documentation/locks.txt file:
1.2.1 Typical Problems - Sendmail
-
Because sendmail was unable to use the old flock() emulation, many sendmail
installations use fcntl() instead of flock(). This is true of Slackware 3.0
for example. This gave rise to some other subtle problems if sendmail was
configured to rebuild the alias file. Sendmail tried to lock the aliases.dir
file with fcntl() at the same time as the GDBM routines tried to lock this
file with flock(). With pre 1.3.96 kernels this could result in deadlocks that,
over time, or under a very heavy mail load, would eventually cause the kernel
to lock solid with deadlocked processes.



Kurt


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

Re: flock() and sendmail

[Kurt Roeckx]

On Fri, Nov 17, 2006 at 06:27:13PM +, John Kelly wrote:
 On Fri, 17 Nov 2006 19:09:33 +0100, Kurt Roeckx [EMAIL PROTECTED]
 wrote:
 
 Anyway, from the linux/Documentation/locks.txt file:
 1.2.1 Typical Problems - Sendmail
 -
 Because sendmail was unable to use the old flock() emulation
 
 I believe flock() *emulation* is no longer used in 2.6 kernels.

flock was changed to not use emulation in 1.3.x and the old flock
emulation has been removed in 2.1.x, according to the same
doc.

 installations use fcntl() instead of flock(). This is true of Slackware 3.0
 for example. This gave rise to some other subtle problems if sendmail was
 configured to rebuild the alias file. Sendmail tried to lock the aliases.dir
 file with fcntl() at the same time as the GDBM routines tried to lock this
 file with flock(). With pre 1.3.96 kernels this could result in deadlocks 
 that,
 over time, or under a very heavy mail load, would eventually cause the kernel
 to lock solid with deadlocked processes.
 
 Then I have to wonder why sendmail is still configured to use fcntl()
 when running on linux.  Sounds like the modern kernel implementation
 of flock() would be better.

I have to wonder why sendmail needs to use fcntl() or flock() at all to
lock the database.

I don't see why flock() would be better, it's just different.  fcntl()
is a standardised and can do more than flock().  I actually see no good
reason to want to use flock() over fcntl().

Also note that this deadlock was caused by the flock() emulation.


Kurt


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

Re: flock() and sendmail

[Kurt Roeckx]

On Fri, Nov 17, 2006 at 07:03:00PM +, John Kelly wrote:
 On Fri, 17 Nov 2006 19:54:13 +0100, Kurt Roeckx [EMAIL PROTECTED]
 wrote:
 
 I actually see no good reason to want to use flock() over fcntl().
 
 
 Maybe because the fcntl()
 
 interface follows the completely stupid semantics of System V and
 IEEE Std 1003.1-1988 (``POSIX.1'') that require that all locks associated
 with a file for a given process are removed when any file descriptor for
 that file is closed by that process.  This semantic means that applica-
 tions must be aware of any files that a subroutine library may access.
 For example if an application for updating the password file locks the
 password file database while making the update, and then calls
 getpwnam(3) to retrieve a record, the lock will be lost because
 getpwnam(3) opens, reads, and closes the password database.  The database

I think this is a rather bad example.  If you lock a file and then
use something other than read() or write() that might access it, you're
very likely having problems.


Kurt


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

Re: RFC: behaviour of bts show command with new BTS default behaviour

[Kurt Roeckx]

On Sun, Nov 12, 2006 at 03:50:46AM -0800, Don Armstrong wrote:
 On Sun, 12 Nov 2006, Kurt Roeckx wrote:
  When using bts show package or going to
  http://bugs.debian.org/package; we get that behaviour, and I find
  both of them annoying.
 
 I switched the default to appending dist=untable because it actually
 tells you which bugs affect unstable; it's far more informative than
 merely categorizing based on whether a bug has been closed. If you
 know you want something else, you really should be using the precise
 url that you want.

So, the default is basicly for the maintainer of the package, so they can
see what bugs they need to fix in unstable?

Users on the other hand might be more interested in the bugs affecting
stable (or testing).  It seems more logical to just lists all bugs for
them.


Kurt


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

Re: RFC: behaviour of bts show command with new BTS default behaviour

[Kurt Roeckx]

On Sun, Nov 12, 2006 at 01:02:06AM +, Julian Gilbey wrote:
 Hi all!
 
 Thinking of changing the default behaviour of the devscripts bts show
 (aka bts bugs) command, and want to ask for opinions before I do so.
[...]
 It now resolves to:
 
 http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=package;dist=unstable

When using bts show package or going to
http://bugs.debian.org/package; we get that behaviour, and I find both
of them annoying.

Some other thing it does now is that if I file a bug against a package
before the bts knows about it, it shows up as in other versions or
something.

I think the default of the bts when going to
http://bugs.debian.org/package should change back to the old behaviour,
and you shouldn't change the bts command.

Some other behaviour of the BTS I'm annoyed about is the order in which
it shows bugs without a way for me to show them in the order I want.
I've actually filed a bug about that: #356270


Kurt


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

Re: RFC: behaviour of bts show command with new BTS default behaviour

[Kurt Roeckx]

On Sun, Nov 12, 2006 at 03:50:46AM -0800, Don Armstrong wrote:
  Some other thing it does now is that if I file a bug against a
  package before the bts knows about it, it shows up as in other
  versions or something.
 
 You should be hard pressed to be able to actually install packages
 before the BTS has learned about the version unless you're filing bugs
 on packages which you've built yourself. [Far more likely that the
 version the bug is filed against is wrong.]

As buildd admin, I can file bugs at the moment I get the buildd log, and
so can other buildd admins and people who get the logs.

At that time, the bts will not know about that version yet, but it does
exists.

This is also very simular to packages that just get out of NEW.


Kurt


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

Re: ca-certificates symlinks out of /etc

[Kurt Roeckx]

On Sat, Nov 04, 2006 at 12:52:03PM +0100, Joey Schulze wrote:
 
 Maybe one improvement would be to reduce the number of links in this
 directory to one per certificate.  Currently for each certificate
 provided by ca-certificates the certificate has a link to /usr/share/..
 and the hash has a link to the other link.  Wouldn't it be possible to
 only create the hash link as a symbolic link to /usr/share/...?

I'm not sure the current c_rehash supports that.  People (or scripts)
may want to run c_rehash on /etc/ssl/certs, at which point it would
remove the hash links, and you have nothing left.

We need something that says those certificates should be in
/etc/ssl/certs, and I don't think the hash symlinks work for that.


Kurt


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

Re: ca-certificates symlinks out of /etc

[Kurt Roeckx]

On Sat, Nov 04, 2006 at 02:30:54PM +0100, Joey Schulze wrote:
 Kurt Roeckx wrote:
  On Sat, Nov 04, 2006 at 12:52:03PM +0100, Joey Schulze wrote:
   
   Maybe one improvement would be to reduce the number of links in this
   directory to one per certificate.  Currently for each certificate
   provided by ca-certificates the certificate has a link to /usr/share/..
   and the hash has a link to the other link.  Wouldn't it be possible to
   only create the hash link as a symbolic link to /usr/share/...?
  
  I'm not sure the current c_rehash supports that.  People (or scripts)
  may want to run c_rehash on /etc/ssl/certs, at which point it would
  remove the hash links, and you have nothing left.
 
 Are the hashes recalculated randomly?  Which programs do that?
 (since I was left with a missing hash several times, at least
 I don't seem to have such a program installed)

It seems there is an update-ca-certificates, which has a config file
(/etc/ca-certificates.conf) that says which certificates should be
enabled.

It runs c_rehash at the end of it, to regenerate the hashes.


Kurt


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

Re: Lots of (easily recognisible) spam sent to the BTS today

[Kurt Roeckx]

On Mon, Oct 30, 2006 at 01:36:56PM -0800, Blars Blarson wrote:
 In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
 On Sun, 29 Oct 2006 16:02:41 -0800, Blars Blarson [EMAIL PROTECTED]
 wrote:
 We have a SA rule for this run now, but sending such hints to
 [EMAIL PROTECTED] will get them seen much faster than debian-devel that I'm
 more than a week behind in reading.
 
 So you really want to be manually informed about spam runs against the
 BTS? Don't you notice unusual activity in some rrd-based monitoring
 system?
 
 If you have an idea for a new spamassassin rule that will get a
 current spam run without triggering on non-spam, send it to
 [EMAIL PROTECTED]  Unfortunatly, much spam is now using anti-bayes tecniques
 and is hard to catch without also getting non-spam.
 
 I do see each message with a SA score = -1, but at times I've been
 days behind slogging through them.

Does that mean that we shouldn't report spam we see in the BTS?  If I
now see spam going to a bugreport of mine, I always go and press the
this bug log contains spam.  Should I just not bother with it?


Kurt


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

Re: First draft of review of policy must usage

[Kurt Roeckx]

On Wed, Oct 25, 2006 at 01:03:11AM -0500, Manoj Srivastava wrote:
 Next, I removed clauses that said that all the requirements of
  policy must be met  for a package to be in main or contrib; we know
  that is not true.
 
 I have replaced some uses of the word must when it was
  intended to be non-normative with alternate and equivalent wording,
  which makes it easier to grep for must.  This still needs to be
  done for should (which I often replace with 'ought to').

So, you changes some things from must to needs, because we don't
consider them RC anymore.  But then also remove the requirement 
to comply with the policy for us to distribute it?

I think you're trying to do the same thing twice.  I don't think we
should remove the requirement to comply with all the requirements.

 @@ -986,7 +891,7 @@
 particular version of that package.footnote
  p
Essential is defined as the minimal set of functionality
 -  that must be available and usable on the system even
 +  that have to be available and usable on the system even
when packages are in an unconfigured (but unpacked)
state.  This is needed to avoid unresolvable dependency
loops on upgrade.  If packages add unnecessary

Why do you downgrade this?  Maybe this should be reworded though.

This seems to be the only place in the policy that says that an
essential package must have all it's functionality when it's in an
unpackaged state.  I think that should atleast be moved to the part
about essential (3.8) instead of a footnote about Dependencies.


 @@ -1931,7 +1848,7 @@
  
   p
 The ttbuild/tt, ttbinary/tt and
 -   ttclean/tt targets must be invoked with the current
 +   ttclean/tt targets need to be invoked with the current
 directory being the package's top-level directory.
   /p
  

I don't see why you want to change that.  I think packages rely on it
that it's called with a proper current working directory.

 @@ -3195,8 +3112,8 @@
  p
Additionally, packages interacting with users using
ttdebconf/tt in the prgnpostinst/prgn script should
 -  install a prgnconfig/prgn script  in the control area,
 -  see ref id=maintscriptprompt for details.
 +  usually install a prgnconfig/prgn script in the control
 +  area, see ref id=maintscriptprompt for details.
  /p
  
   p

You seem to have changed should to should usually, and I don't
see what the real difference is.

p
 - Packages involving shared libraries should be split up into
 + Packages involving shared libraries ought to be split up into
   several binary packages. This section mostly deals with how
   this separation is to be accomplished; rules for files within
 - the shared library packages are in ref id=libraries instead.
 + the shared library packages are in ref id=libraries
 + instead.
/p
  
sect id=sharedlibs-runtime

I think the should there was good.

 @@ -4722,7 +4640,7 @@
  
   p
 If a package contains a binary or library which links to a
 -   shared library, we must ensure that when the package is
 +   shared library, we have to ensure that when the package is
 installed on the system, all of the libraries needed are
 also installed.  This requirement led to the creation of the
 ttshlibs/tt system, which is very simple in its design:

I have no idea why you want to change that.  If it's linked to a shared
library, it really needs that library and won't work without it.  So
this should be a must.

Also, if you really want to change that, you might want to change the
This requirement too.

 @@ -4748,7 +4666,7 @@
 determined by calling prgnldd/prgn, but now
 prgnobjdump/prgn is used to do this.  The only
 change this makes to package building is that
 -   prgndpkg-shlibdeps/prgn must also be run on shared
 +   prgndpkg-shlibdeps/prgn also has to be run on shared
 libraries, whereas in the past this was unnecessary.
 The rest of this footnote explains the advantage that
 this method gives.

It really must be run on it, or things will break.

 @@ -4865,7 +4783,7 @@
   determine whether ttfoo-prog/tt's library
   dependencies are satisfied by any of the libraries
   provided by ttlibfoo2/tt.  For this reason,
 - prgndpkg-shlibdeps/prgn must only be run once
 + prgndpkg-shlibdeps/prgn has to be run only once
   all of the individual binary packages'
   ttshlibs/tt files have been installed into the
   build directory.

If you remove that requirement, I think you need to another one.
foo-runtime really needs to have a dependency on libfoo2, one way or
another.

 @@ 

Re: First draft of review of policy must usage

[Kurt Roeckx]

On Wed, Oct 25, 2006 at 01:49:03PM -0500, Manoj Srivastava wrote:
 p
  -   Packages involving shared libraries should be split up into
  +   Packages involving shared libraries ought to be split up into
  several binary packages. This section mostly deals with how
  this separation is to be accomplished; rules for files within
  -   the shared library packages are in ref id=libraries instead.
  +   the shared library packages are in ref id=libraries
  +   instead.
 /p
   
 sect id=sharedlibs-runtime
 
  I think the should there was good.
 
 This is something I want to discuss further. Consider the case
  where there is a package with a set of, say, 20 binaries with a lot
  of common code, and upstream decided to abstract it out into a shared
  lib. This is a shred lib used by anyone else, and it is changing
  rapidly enough that there is the equivalent of a soname change on
  every upload. There is no interest in supporting older versions, or
  even having multiple versions of that lib. In this case, either we
  can make packaging that software hard (since moving the lib out of
  /usr/lib etc may involve some work), or we allow some packages to
  include share libs in the package.
 
 I don't know which way one should lean, so I decided to go the
  route of fewer bugs.

If it's not supposed to be used by an other package, it should be moved
to /usr/lib/package/.  If it doesn't contain any other libraries in
/usr/lib, it shouldn't provide a -dev package.  So there really isn't a
need for a seperate lib package either.

Anyway, that's why it says should in the first place, and I don't see
why it needs to be changed.


Kurt


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

Re: Missing days?

[Kurt Roeckx]

On Tue, Oct 17, 2006 at 02:34:11PM +, Sune Vuorela wrote:
 Hi!
 
 I have started to wonder a bit about 'missing days' - a thing that is
 especially importaint now when we are heading for a total freeze.
 
 From http://packages.qa.debian.org/u/udev.html:
 Too young, only 1 of 10 days old
 [2006-10-15] Accepted 0.100-2.1 in unstable (low) 

I got:
Date: Sun, 15 Oct 2006 10:02:15 -0700

Which is before the dinstall run on the 15th.  A few hours later
dinstall runs.  Yet a few hour later britney runs and sees it for
the first time.  At that point, it's 0 days old.

Than 24 hours later, britney runs again, and it's 1 day old.

In about 10 hours, britney will run again, and it will become 2 days
old.

 But here:
 http://packages.qa.debian.org/k/kwin-style-crystal.html
 Too young, only 1 of 10 days old
 [2006-10-13] Accepted 1.0.2-1 in unstable (low)

Date: Fri, 13 Oct 2006 14:48:15 -0700

Which is a few hours after the dinstall run on the 13th.  A few hours
later when britney runs, it doesn't see it yet.  Britney only sees it
more than 24h after it was uploaded.  So it's 2 days old now.


Kurt


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

Accepted tar 1.15.91-2.1 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 14 Oct 2006 13:06:37 +
Source: tar
Binary: tar
Architecture: source amd64
Version: 1.15.91-2.1
Distribution: unstable
Urgency: low
Maintainer: Bdale Garbee [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 tar- GNU tar
Closes: 377330 379393
Changes: 
 tar (1.15.91-2.1) unstable; urgency=low
 .
   * Non-maintainer upload.
   * Make incremental restore work again.  (Closes: #377330, #379393)
 Patch provided by Vladimir Suplin [EMAIL PROTECTED]
Files: 
 70f4318db8acde0db3729387f5316282 582 utils required tar_1.15.91-2.1.dsc
 19dbcfdbd68caa58ce2e69f8da11d643 16468 utils required tar_1.15.91-2.1.diff.gz
 8bf3d560c3581cf5062b318ba2931f9d 611244 utils required 
tar_1.15.91-2.1_amd64.deb

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

iD8DBQFFMOSGQdwckHJElwsRAsR0AKC0V6DQh0evhMQzmjUmGuS+SjjwBQCg4h93
7CQOdG8hDwyiByV3C9X6V58=
=R3Y8
-END PGP SIGNATURE-


Accepted:
tar_1.15.91-2.1.diff.gz
  to pool/main/t/tar/tar_1.15.91-2.1.diff.gz
tar_1.15.91-2.1.dsc
  to pool/main/t/tar/tar_1.15.91-2.1.dsc
tar_1.15.91-2.1_amd64.deb
  to pool/main/t/tar/tar_1.15.91-2.1_amd64.deb


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

Re: Build failure: cannot find -lglib-2.0

[Kurt Roeckx]

On Fri, Oct 13, 2006 at 11:40:04AM +0100, Martin Michlmayr wrote:
 A number of packages currently fail to build with:
 /usr/bin/ld: cannot find -lglib-2.0
 
 Can someone please investigate whether this is a bug in those packages
 or some underlying problem and file bugs.  I've put some buid logs at
 http://people.debian.org/~tbm/logs/glib.bz2

That would be QtCore.pc having -lglib-2.0 in it.  They all have
libqt4-dev installed.

I'll file a bug.


Kurt


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

Accepted openssl097 0.9.7k-3 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon,  2 Oct 2006 16:09:11 +
Source: openssl097
Binary: libssl0.9.7-dbg libssl0.9.7
Architecture: source amd64
Version: 0.9.7k-3
Distribution: unstable
Urgency: high
Maintainer: Debian OpenSSL Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libssl0.9.7 - SSL shared libraries
 libssl0.9.7-dbg - Symbol tables for libssl and libcrypt
Changes: 
 openssl097 (0.9.7k-3) unstable; urgency=high
 .
   * Fix patch for CVE-2006-2940, it left ctx unintiliased.
Files: 
 1c3b2f3d87442c8e310b3ccab95e6831 755 utils optional openssl097_0.9.7k-3.dsc
 8fc3d3dd4a04ff224704047cf62e02ab 31348 utils optional 
openssl097_0.9.7k-3.diff.gz
 eac2da63d7cb6fb3b2900fd03e2f6853 754362 oldlibs extra 
libssl0.9.7_0.9.7k-3_amd64.deb
 a037d04e31cd7e0a9e185380568e3455 1325864 libdevel extra 
libssl0.9.7-dbg_0.9.7k-3_amd64.deb

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

iD8DBQFFIT18QdwckHJElwsRAuj8AJ0fkSSlaR7+EeID3wwbh6PkAIDlkwCgxHVz
RIG/7QthHDKqQGFYB5/SzmY=
=dGOo
-END PGP SIGNATURE-


Accepted:
libssl0.9.7-dbg_0.9.7k-3_amd64.deb
  to pool/main/o/openssl097/libssl0.9.7-dbg_0.9.7k-3_amd64.deb
libssl0.9.7_0.9.7k-3_amd64.deb
  to pool/main/o/openssl097/libssl0.9.7_0.9.7k-3_amd64.deb
openssl097_0.9.7k-3.diff.gz
  to pool/main/o/openssl097/openssl097_0.9.7k-3.diff.gz
openssl097_0.9.7k-3.dsc
  to pool/main/o/openssl097/openssl097_0.9.7k-3.dsc


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

Accepted openssl 0.9.8c-3 (source amd64)

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon,  2 Oct 2006 18:05:00 +0200
Source: openssl
Binary: libssl-dev openssl libssl0.9.8-dbg libcrypto0.9.8-udeb libssl0.9.8
Architecture: source amd64
Version: 0.9.8c-3
Distribution: unstable
Urgency: low
Maintainer: Debian OpenSSL Team [EMAIL PROTECTED]
Changed-By: Kurt Roeckx [EMAIL PROTECTED]
Description: 
 libcrypto0.9.8-udeb - crypto shared library - udeb (udeb)
 libssl-dev - SSL development libraries, header files and documentation
 libssl0.9.8 - SSL shared libraries
 libssl0.9.8-dbg - Symbol tables for libssl and libcrypt
 openssl- Secure Socket Layer (SSL) binary and related cryptographic tools
Changes: 
 openssl (0.9.8c-3) unstable; urgency=low
 .
   * Fix patch for CVE-2006-2940, it left ctx unintiliased.
Files: 
 e5de2efd966e4ca8099a5b52c637d81a 797 utils optional openssl_0.9.8c-3.dsc
 b07e1d623745f24e8b4b330ef69ff77f 41920 utils optional openssl_0.9.8c-3.diff.gz
 0879e7492d1234d412ea384fe89259f4 1004536 utils optional 
openssl_0.9.8c-3_amd64.deb
 e7eb335259eb0c1db20043f95c5e99fc 889154 libs important 
libssl0.9.8_0.9.8c-3_amd64.deb
 4cc46086038949c54f62574d69b829ca 580070 debian-installer optional 
libcrypto0.9.8-udeb_0.9.8c-3_amd64.udeb
 59b2e9313b4d005a8af472bc75f3552f 2178952 libdevel optional 
libssl-dev_0.9.8c-3_amd64.deb
 99f1aa0de0fefd800ce03a1faa44fec4 1653590 libdevel extra 
libssl0.9.8-dbg_0.9.8c-3_amd64.deb
Package-Type: udeb

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

iD8DBQFFITu9QdwckHJElwsRAvncAKCmt0wMEpKcyLPjU0g4u6NL1vGDvgCgsqp9
TV46L3gTnVGL/W+u2++YEXo=
=wFet
-END PGP SIGNATURE-


Accepted:
libcrypto0.9.8-udeb_0.9.8c-3_amd64.udeb
  to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8c-3_amd64.udeb
libssl-dev_0.9.8c-3_amd64.deb
  to pool/main/o/openssl/libssl-dev_0.9.8c-3_amd64.deb
libssl0.9.8-dbg_0.9.8c-3_amd64.deb
  to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8c-3_amd64.deb
libssl0.9.8_0.9.8c-3_amd64.deb
  to pool/main/o/openssl/libssl0.9.8_0.9.8c-3_amd64.deb
openssl_0.9.8c-3.diff.gz
  to pool/main/o/openssl/openssl_0.9.8c-3.diff.gz
openssl_0.9.8c-3.dsc
  to pool/main/o/openssl/openssl_0.9.8c-3.dsc
openssl_0.9.8c-3_amd64.deb
  to pool/main/o/openssl/openssl_0.9.8c-3_amd64.deb


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