Thibaut,

John Goerzen forwarded your idea to me.

You can actually implement this on top of the current libarchive
code quite efficiently. Use the low-level archive_write_open()
call and provide your own callbacks that just count the write
requests. Then go through and write the archive as usual,
except skip the write_data() part (for tar and cpio formats,
libarchive will automatically pad the entry with NUL bytes).

This may sound slow, but it's really not. One of the libarchive
unit tests use this approach to "write" 1TB archives in just a couple
of seconds. (Thist test checks libarchive's handling of very large
archives with very large entries.) Look at test_tar_large.c
for the details of how this particular test works. (test_tar_large.c
actually does more than just count the data, but it should
give you the general idea.)

This will work very well with all of the tar and cpio formats.
It won't work well with some other formats where the length
does actually depend on the data.

Cheers,

Package: digikam
Version: 2:0.10.0~beta1-1
Severity: serious
Tags: experimental

digkam 0.10.0 should be kept out of testing & unstable(?) until final
release ~ 20 Dec 08:

http://www.digikam.org/drupal/about/releaseplan

digiKam 0.10.0 Release Plan (KDE4)

2008-07-07: Beta 1
2008-07-31: Beta 2
2008-08-23: Beta 3
2008-09-13: Beta 4
2008-10-11: Beta 5
2008-11-01: Beta 6
2008-11-29: Release candidate 1 (i18n freeze)
2008-11-13: Release candidate 2
2008-12-20: Final release

Mark

# Automatically generated email from bts, devscripts version 2.10.35
# via tagpending
#
# digikam (2:0.10.0~beta1-2) UNRELEASED; urgency=low
#
# * Include usr/share/kde4 in digikam.install
# - Digikam (experimental) doesn't work at all (Closes: #491458)
# * Cleanup Depends:/ Recommends:/ COnflicts:
# - please remove the recommand line that mostly recommaneds kde3
# pakcakge (Closes: #491741)
#

package digikam digikam-dbg showfoto
tags 491458 + pending
tags 491741 + pending

Package: general
Severity: wishlist

TEST, excuses me

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

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

On Fri, Aug 08, 2008 at 12:21:46AM +0200, Santiago Garcia Mantinan wrote:

Using alternatives would definitely be a good idea.

I guess, it would be great to if there's any
other mechanism in Firefox/Iceweazel to select which plugin is in charge
of flash, so that it may be configured on user's side (but the two
systems may coexist).

Voting for alternatives, as a user ;-)

Package: at
Version: 3.1.10.1

In truth, I'm not certain whether this is an at bug, or a lsb-base,
bug, but with the current version of lsb-base (3.2-19), a call to
"/etc/init.d/atd stop" results in "Termination".

I looked around (in start-stop-daemon.c) and atd's scripts, and it
looks like the termination is because, at least when atd isn't
running, start-stop-daemon ends up picking the calling /etc/init.d/atd
script to kill.

I looked at the diff of /lib/lsb/init-functions against 3.2-13, and it
does look like the definition of killproc has changed in a possibly
relevant way. However, I hadn't yet determined if this was a bug in
lsb-base, or if atd just needed to change the way it was trying to
stop the daemon.

Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Doug Larrick wrote:

Package: xscreensaver
Version: 5.05-3
Severity: normal

After upgrading to 5.05, xscreensaver ignores my second X screen. I'm
running an old style dual head setup, so I have :0.0 and :0.1. With 5.03
xscreensaver was watching input on both screens, and would start a
screensaver on both. With 5.05 (and actually also 5.06), it ignores
:0.1, although it says it is running:

---SNIP---
squisher@alucardo:~/src/xscreensaver-5.06/driver$ xscreensaver
xscreensaver: 22:52:56: already running on display :0.1 (window 0x4600002)
from process 30648 (squisher@alucardo).
squisher@alucardo:~/src/xscreensaver-5.06/driver$ echo $DISPLAY
:0.1
squisher@alucardo:~/src/xscreensaver-5.06/driver$
---SNAP---

Some extra info:

tags 493372 patch
thanks

Hi

Upstream just commited a fix for this issue, which edits the $username
parameter. Patch for owl-dms unstable version is attached.
Please consider including this patch and upload with high urgency to unstable
and email the release team for a freeze exception.

Cheers
Steffen

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

iEYEABECAAYFAkib0UwACgkQ62zWxYk/rQdNFgCdHnTVU1yhA/alJi49MZQL969Y
ZFEAoI5VubCdkmWPAMKMUaFUE4SNVeJ6
=/Z1T
-----END PGP SIGNATURE-----