date:20090312

On Wed, Mar 11, 2009 at 10:13:51AM -0500, Manoj Srivastava wrote:
 This is what diferentiates is from uscan; indeed, I use uscan in
  the cases where I provide the target, The target unpacks the
  raw upstream source, munges it (by, say, removing a subdir which has
  non-dfsg stuff, or removes the debian dir, applies patches, or whatever
  other processing is required.

 There is no need to do this for the current version; the mungeds
  sources already are an apt-get source away.

For several packages I (co)maintain where I have to munge the upstream
tarball, the standard procedure (inherited from past maintainers) is:

 - increment the version number in the debian packaging
 - call the get-orig-source target

I think it's perfectly reasonable to want the get-orig-source target to give
you a *specified* version of an upstream tarball, rather than the *newest*
version of an upstream tarball.  Packaging a new upstream version doesn't
necessarily mean packaging the latest that uscan can find.

It's also useful for third parties to be able to easily examine the
provenance of specific Debian tarballs.  A get-orig-source target provides a
much more concise description of the Debian changes than examining the diff
between the two tarballs.

So I certainly agree that uscan doesn't obsolete the get-orig-source target,
but I disagree that it's not useful to have such a target generate a tarball
for the 'current' upstream version.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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

Re: libpoppler3 missing in unstable

2009-03-12 Thread Josselin Mouette

Le jeudi 12 mars 2009 à 10:08 +0200, Riku Voipio a écrit :
 Perhaps it should be assumed by default that soname transitions require
 source changes, _unless_ proven otherwise. And proving is really simple -
 just try recompiling all reverse dependencies against the new library.

Are you volunteering to do this work in the future for other library
transitions?

-- 
 .''`.  Debian 5.0 Lenny has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Breaking /emul/ia32-linux for squeeze

Clint Adams sch...@debian.org writes:

 It may be time to change packages installing files to
 /emul/ia32-linux (which violates the FHS) to use
 /usr/lib32 instead.

NO NO NO NO NO NO NO NO.

It is high time to change to the multiarch dir. For that gcc needs to
be fixed first so compiling 32bit code does not break. Transitioning
to /usr/lib32 will just needlessly break systems.

 I believe the affected packages are

 fakechroot
 fakeroot
 gnu-efi
 ia32-libs
 ia32-libs-gtk
 lib32asound2
 lib32asound2-dev
 lib32bz2-1.0
 lib32bz2-dev
 lib32ffi5
 lib32ffi-dev
 lib32gcc1
 lib32gfortran2
 lib32gfortran3
 lib32gomp1
 lib32icu38
 lib32icu-dev
 lib32mudflap0
 lib32ncurses5
 lib32ncurses5-dev
 lib32ncursesw5
 lib32ncursesw5-dev
 lib32nss-mdns
 lib32objc2
 lib32readline5
 lib32readline5-dev
 lib32stdc++6
 lib32stdc++6-4.1-dbg
 lib32stdc++6-4.2-dbg
 lib32stdc++6-4.2-dbg
 lib32stdc++6-4.3-dbg
 lib32z1
 lib32z1-dev
 libc6-dev-i386
 libc6-i386

ia32-* from ia32-apt-get, which potentially includes every single
  library package in debian. Although only ia32-apt-get needs to be
  changed.

 glibc will need to change first, and the remaining
 packages will be broken until they are changed as well.

And every package would need a Pre-Depends on the new libc6. *shiver*

MfG
Goswin


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

Re: Breaking /emul/ia32-linux for squeeze

Steve Langasek vor...@debian.org writes:

 On Wed, Mar 11, 2009 at 10:50:23PM +, Clint Adams wrote:
 On Wed, Mar 11, 2009 at 11:16:47PM +0100, Tollef Fog Heen wrote:
  Could we pretty please use the multiarch paths here if we start moving
  stuff around?  We're going to need to patch gcc/binutils if we're to
  compile stuff against those paths anyway.

 By multiarch paths, you mean /usr/lib/i386-linux/ in this case?
 I'm fine with doing that and changing both /usr/lib32 and /emul/ia32-linux
 to be symlinks thither for the time being.

 I think we're probably better off reserving /usr/lib/i386-linux for future
 use for the time being, but will defer to Tollef if he thinks this is
 reasonable to start using here.

/usr/lib/i486-linux-gnu, the full and correct tripplet. Debian has
switched from i386 to i486 some time ago.

The only argument against using it already is that then later libfoo
on i386 needs Replaces: lib32foo for multiarch.

Well, and that gcc still doesn't look there for libraries when linking.

MfG
Goswin


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

Re: best practice for updating inetd.conf with a user-chosen port?

2009-03-12 Thread Francesco P. Lovergine

On Wed, Mar 11, 2009 at 04:56:20PM +0100, Giacomo A. Catenazzi wrote:
 how to had new services in /etc/services database?

 ciao
   cate

Asking netbase maintainer(s)? Just read /etc/services about that.

-- 
Francesco P. Lovergine


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

Re: Breaking /emul/ia32-linux for squeeze

Steve Langasek vor...@debian.org writes:

 On Wed, Mar 11, 2009 at 11:16:47PM +0100, Tollef Fog Heen wrote:
 ]] Clint Adams 

 | It may be time to change packages installing files to
 | /emul/ia32-linux (which violates the FHS) to use
 | /usr/lib32 instead.

 Could we pretty please use the multiarch paths here if we start moving
 stuff around?  We're going to need to patch gcc/binutils if we're to
 compile stuff against those paths anyway.

 What transitional issues is that going to cause us if and when multiarch
 becomes generally available, if biarch packages start using the path now?

libfoo i386 then needs Replaces: lib32foo. But it already needs
Conflicts: lib32foo I think so there isn't really any harm done.

MfG
Goswin


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

Re: Proposal: virtual package + alternative: x-keyboard

Neil Williams codeh...@debian.org writes:

 However, there is another issue here - if the device is multi-user,
 most login managers cannot cope with a touchscreen keyboard. gpe-login
 is one that can, gdm cannot.

 Having touchscreen keyboard support in X is good as long as the user
 can log into their X environment first.
 ;-)

Recommends/Suggests?

That would hint to having a meta package instead of a virtual one.

MfG
Goswin


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

Bug#519407: ITP: hpcc -- HPC Challenge Benchmark

2009-03-12 Thread Jean Parpaillon

Package: wnpp
Severity: wishlist
Owner: Jean Parpaillon jean.parpail...@kerlabs.com


* Package name: hpcc
  Version : 1.3.1
  Upstream Author : HPC Challenge team h...@cs.utk.edu
* URL : http://icl.cs.utk.edu/hpcc/
* License : BSD
  Programming Lang: C, mpi
  Description : HPC Challenge Benchmark

 This is a suite of benchmarks that measure performance of CPU, memory
 subsytem and the interconnect.
 
 In essence, HPC Challenge consists of a number of subbenchmarks each
 of which tests different aspect of the system.
 
 hpcc binaries are available in a variety of configuration/
 optimization, called arch.


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)



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

Bug#519411: ITP: python-django-formfieldset -- fieldset rendering for Django forms

2009-03-12 Thread Daniel Watkins

Package: wnpp
Severity: wishlist
Owner: Daniel Watkins dan...@daniel-watkins.co.uk

* Package name: python-django-formfieldset
  Version : 0+git20090312-f07320dd
  Upstream Author : Atamert Ölçgen mu...@muhuk.com
* URL : http://github.com/muhuk/django-formfieldset/tree/master
* License : BSD
  Programming Lang: Python
  Description : fieldset rendering for Django forms

Provides a mix-in class for Forms within the Django web framework, which gives
fieldset functionality similar to ModelAdmin and shorthand rendering functions
for forms with fieldsets without overriding anything within the Django Form
class itself.



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

Re: best practice for updating inetd.conf with a user-chosen port?

2009-03-12 Thread Giacomo A. Catenazzi


Francesco P. Lovergine wrote:

On Wed, Mar 11, 2009 at 04:56:20PM +0100, Giacomo A. Catenazzi wrote:

how to had new services in /etc/services database?


Asking netbase maintainer(s)? Just read /etc/services about that.


Hmm. Reading your and dato answers, it seems I wrote wrongly my mail.

The question (still in subject) was how to have admin-chosen
ports for some services. The first proposal was to dynamically change
port in inetd configuration.

I proposed to move the dynamic port in the /etc/services level, not
necessary modifying such file, but in a way accessible to getservbyname(3).

But now I'm not sure about:
- if it is a good thing to have admin choosed ports
- if /etc/services level is the right thing to do.

ciao
cate




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

Bug#519413: ITP: bosh -- browse output of processes

2009-03-12 Thread Salvatore Bonaccorso

Package: wnpp
Severity: wishlist
Owner: Salvatore Bonaccorso salvatore.bonacco...@gmail.com

* Package name: bosh
  Version : 0.5
  Upstream Author : Alex Sisson alexsis...@gmail.com
* URL : http://bosh.sourceforge.net/
* License : GPL
  Programming Lang: C
  Description : browse output of processes

bosh stands for browsable output shell. This is a bit of a misnomer
because it isn't really a shell. What is does is store the output of a
specified program in a buffer, and provides a simple curses interface
to browse this buffer. Actions can be configured which can make use of
the contents of the currently selected line.

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



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

Re: libpoppler3 missing in unstable

2009-03-12 Thread Norbert Preining

Hi Josselin,

On Do, 12 Mär 2009, Josselin Mouette wrote:
 Are you volunteering to do this work in the future for other library
 transitions?

No need. If you (the devs of poppler) just warn rdepends on imminent
upload and send a pre-version for testing we can react. Fixing poppler
patches did become more and more easy, but this one took more time
because of the removal of xpdfVersion var.

Anyway, it is settled now, new version of texlive in sid, so let us
close this case.

Best wishes

Norbert

---
Dr. Norbert Preining prein...@logic.atVienna University of Technology
Debian Developer prein...@debian.org Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
`If there's anything more important than my ego around, I
want it caught and shot now.'
 --- Zaphod.
 --- Douglas Adams, The Hitchhikers Guide to the Galaxy


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

Re: libpoppler3 missing in unstable

2009-03-12 Thread Dirk Eddelbuettel


On 11 March 2009 at 15:35, Norbert Preining wrote:
| On Mi, 11 M r 2009, Dirk Eddelbuettel wrote:
|   but I DO care about the fact that Debian unstable as a whole is FTBFS
|  
|  which I don't find too acceptable.  Now, stuff happens, Norbert is on it, 
and
|  hopefully this will be over soon.
| 
| texlive-bin 2007.dfsg.2-5 with a fixed patch (that unfortunately needs
| pkg-config for finding the version of the poppler library) is uploaded.

Much appreciated!!

Dirk (whose build attempt is now blocked by libcairo2 requiring a rebuild for
libdirectfb-1.2-0 -- can't win :-/ )

-- 
Three out of two people have difficulties with fractions.


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

Bug#518927: Software that bundles old dtoa.c

2009-03-12 Thread Diego E. 'Flameeyes'

A not-so-quick scan through the Gentoo source tree, pointed at the
following software as containing the old dtoa.c file (checked against
the word1 define):

Mozilla-derived software (nspr, xulrunner (1.8 and 1.9), seamonkey,
thunderbird, sunbird, nvu), Ruby (1.8 and 1.9), Qt 4.5, kdelibs 3.5,
VirtualBox 2.1, WebKit GTK, Mono 2.2, Poly/ML 5.2.1

The fact that they _contain_ the source file does not mean they build
it, and even if they built it, it does not mean it is susceptible to
this problem: some software, like Ruby and VirtualBox, build with
-fno-strict-aliasing enabled by default.

The scan isn't entirely over yet though, I'm still missing some
X11-related packages and the whole of XFCE.

-- 
Diego Flameeyes Pettenò
http://blog.flameeyes.eu/



signature.asc
Description: This is a digitally signed message part

Re: best practice for updating inetd.conf with a user-chosen port?

2009-03-12 Thread Holger Levsen

Hi,

On Donnerstag, 12. März 2009, Giacomo A. Catenazzi wrote:
 But now I'm not sure about:
 - if it is a good thing to have admin choosed ports

I dont think so and I guess I'm not alone and thats why there is no best 
practice to do that. The only (typo of) package where I can think off where 
this is sensible as default, is one which sets up a hidden service.

What kind of daemon are you packaging?


regards,
Holger


signature.asc
Description: This is a digitally signed message part.

toolame: remove from unstable, update in stable

2009-03-12 Thread Fabian Greffrath


Dear -release,
[CC'ing pkg-multimedia-maintainers as the current toolame maintainers,
pkg-mythtv-maintainers as the current twolame maintainers and
debian-devel for general discussion ;) ]

I am going to request the removal of the toolame package from unstable
and testing in the short term. toolame hasn't seen a release in six
years, it is dead upstream, it has bugs and is superseded by its
successor twolame (yes, there's a t_o_olame and a t_w_olame). People
should really be using twolame instead, as it has an active upstream,
has its bugs fixed and provides a shared library that is already used
by projects such as gstreamer and audacity.

However, I think the toolame package in stable may stay both for the
convenience of our users and because it's not *that* bad after all. I
have prepared a  package targeted at Lenny that fixes two portability
bugs and some minor lintian warnings. It can be found at mentors.d.n
[1], the debdiff is attached to this mail. Please tell me if or under
which restrictions it is OK to upload it to stable or s-p-u.

My general question regarding the removal of toolame is: Should we
provide a transition and if yes... how? I consider the following 
methods to deal with this issue:

1. Remove the toolame package from unstable and testing. End of story.
2. Provide an empty toolame package that depends on twolame.
3a. Provide a wrapper in the toolame package that calls the twolame
binary with the same command line options (or some translations 
respectively). toolame and twolame are command line compatible except 
for some very exotic flags.

3b. The twolame source creates a toolame package that contains the
above mentioned wrapper script.
4. Make the twolame package provide toolame, so that at least the few 
recommends on the toolame package can be satisfied.

5. What else can you imagine/recommend...?

Thank you very much for your suggestions.

Cheers,
Fabian


[1] http://mentors.debian.net/debian/pool/main/t/toolame/toolame_02l-7.dsc

--
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax: +49 (0)234 / 32-14227
E-Mail:  greffr...@leat.ruhr-uni-bochum.de

diff -u toolame-02l/debian/rules toolame-02l/debian/rules
--- toolame-02l/debian/rules
+++ toolame-02l/debian/rules
@@ -3,6 +3,8 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+include /usr/share/quilt/quilt.make
+
 CFLAGS = -Wall -g
 
 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
@@ -11,7 +13,7 @@
 	CFLAGS += -O2
 endif
 
-build: build-stamp
+build: $(QUILT_STAMPFN) build-stamp
 build-stamp:
 	dh_testdir
 
@@ -20,14 +22,14 @@
 
 	touch build-stamp
 
-clean:
+clean: unpatch
 	dh_testdir
 	dh_testroot
 	rm -f build-stamp
 
 	# Cleaning package
-	-$(MAKE) clean
-	rm -rf toolame
+	[ ! -f Makefile ] || $(MAKE) clean
+	rm -f toolame
 
 	dh_clean
 
diff -u toolame-02l/debian/changelog toolame-02l/debian/changelog
--- toolame-02l/debian/changelog
+++ toolame-02l/debian/changelog
@@ -1,3 +1,23 @@
+toolame (02l-7) unstable; urgency=low
+
+  * debian/control:
++ Added Build-Depends on quilt.
++ Bumped Standards-Version to 3.8.0.
++ Removed the XS- prefix from the Vcs-Svn and Vcs-Browser fields.
++ Added Homepage field and removed it from the package description.
++ Fixed binary-control-field-duplicates-source field. 
+  * debian/rules:
++ Included quilt for patch management.
++ Fixed debian-rules-ignores-make-clean-error.
+  * debian/patches/01-WAV-header-read-incorrectly-on-64-bit-platforms.patch:
++ New patch to fix usage of unsigned long on 64-bit little-endian
+  platforms (Closes: #504308). Thanks Christian Grigis gl...@grigri.org!
+  * debian/patches/02-initialize-header-padding-field-before-parsing-arguments.patch:
++ New patch to initialize the 1-bit 'header-padding' field before parsing
+  the arguments. Thanks Christian Grigis gl...@grigri.org!
+
+ -- Fabian Greffrath fab...@debian-unofficial.org  Wed, 11 Mar 2009 12:53:11 +0100
+
 toolame (02l-6) unstable; urgency=low
 
   [ Sam Hocevar ]
diff -u toolame-02l/debian/control toolame-02l/debian/control
--- toolame-02l/debian/control
+++ toolame-02l/debian/control
@@ -3,13 +3,13 @@
 Priority: optional
 Maintainer: Debian multimedia packages maintainers pkg-multimedia-maintain...@lists.alioth.debian.org
 Uploaders: Fabian Greffrath fab...@debian-unofficial.org, Sam Hocevar (Debian packages) sam+...@zoy.org
-Build-Depends: debhelper (= 5)
-Standards-Version: 3.7.2
-XS-Vcs-Svn: svn://svn.debian.org/pkg-multimedia/unstable/toolame
-XS-Vcs-Browser: http://svn.debian.org/wsvn/pkg-multimedia/unstable/toolame/
+Build-Depends: debhelper (= 5), quilt
+Standards-Version: 3.8.0
+Vcs-Svn: svn://svn.debian.org/pkg-multimedia/unstable/toolame
+Vcs-Browser: http://svn.debian.org/wsvn/pkg-multimedia/unstable/toolame/
+Homepage: http://toolame.sourceforge.net/
 
 Package: toolame

Re: Bug#466550: Pristine source from upstream VCS repository

2009-03-12 Thread Gunnar Wolf

Steve Langasek dijo [Thu, Mar 12, 2009 at 02:05:42AM -0700]:
 I think it's perfectly reasonable to want the get-orig-source target to give
 you a *specified* version of an upstream tarball, rather than the *newest*
 version of an upstream tarball.  Packaging a new upstream version doesn't
 necessarily mean packaging the latest that uscan can find.
 
 It's also useful for third parties to be able to easily examine the
 provenance of specific Debian tarballs.  A get-orig-source target provides a
 much more concise description of the Debian changes than examining the diff
 between the two tarballs.
 
 So I certainly agree that uscan doesn't obsolete the get-orig-source target,
 but I disagree that it's not useful to have such a target generate a tarball
 for the 'current' upstream version.

Good point you have here - But (and I know it is not being discussed
yet, maybe you want to teleport this thread a couple of years into the
future) I feel this should clearly be an optional target, and the
canonical location for orig.tar.gz files should still be our archive -
Down the other road lies Gentoo's BSD ports' madness, where an
upstream site restructure means packages become unreachable and
insta-FTBFS. 

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Re: Proposal: virtual package + alternative: x-keyboard

2009-03-12 Thread Yaroslav Halchenko

Primary reason why I raised it appeared when I tried hackable1
Debian-based distribution for freerunner. X server was hardcoded to use
/usr/bin/xkbd for a keyboard which comes up whenever user presses AUX
button. There were no easy way to alternate the input method. So for qwo
package I just suggested to symlink xkbd - qwo.  Having alternates for
it would have resolved the problem.

since in this case custom x-server is relying on its presence, depends
on x-keyboard should be for that custom package of X. and since it is X
which takes care about raising the keyboard, it should be ok even for
login screens (although on the phones usually it is a single-user
environment, so no need for login/session management per se)

On Thu, 12 Mar 2009, Goswin von Brederlow wrote:

 Neil Williams codeh...@debian.org writes:

  However, there is another issue here - if the device is multi-user,
  most login managers cannot cope with a touchscreen keyboard. gpe-login
  is one that can, gdm cannot.

  Having touchscreen keyboard support in X is good as long as the user
  can log into their X environment first.
  ;-)

 Recommends/Suggests?

 That would hint to having a meta package instead of a virtual one.

 MfG
 Goswin
-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-1412 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik


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

Re: best practice for updating inetd.conf with a user-chosen port?

2009-03-12 Thread Eric Cooper

On Thu, Mar 12, 2009 at 02:13:12PM +0100, Holger Levsen wrote:
 On Donnerstag, 12. März 2009, Giacomo A. Catenazzi wrote:
  But now I'm not sure about:
  - if it is a good thing to have admin choosed ports
 
 I dont think so and I guess I'm not alone and thats why there is no best 
 practice to do that. The only (typo of) package where I can think off where 
 this is sensible as default, is one which sets up a hidden service.
 
 What kind of daemon are you packaging?

I'm packaging approx, which for compatibility with apt-proxy defaults
to port  (not in /etc/services).  That was fine when approx, like
apt-proxy, was run as a standalone daemon from an initscript.  But I
just changed it to run (only) from inetd, hence this thread.

Regarding the other thread in -devel about the future of inetd: in my
case I found it very sensible to jettison all the code for opening
sockets, binding ports, handling IPv6, handling tcp-wrappers,
daemonizing processes, etc.  and punt it to inetd.  Since apt clients
keep their connections open for many multiple, the performance hit is
negligible.

-- 
Eric Cooper e c c @ c m u . e d u


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

Re: Bug#466550: Pristine source from upstream VCS repository

On Thu, Mar 12 2009, Steve Langasek wrote:

 On Wed, Mar 11, 2009 at 10:13:51AM -0500, Manoj Srivastava wrote:
 This is what diferentiates is from uscan; indeed, I use uscan in
  the cases where I provide the target, The target unpacks the
  raw upstream source, munges it (by, say, removing a subdir which has
  non-dfsg stuff, or removes the debian dir, applies patches, or whatever
  other processing is required.

 There is no need to do this for the current version; the mungeds
  sources already are an apt-get source away.

 For several packages I (co)maintain where I have to munge the upstream
 tarball, the standard procedure (inherited from past maintainers) is:

  - increment the version number in the debian packaging
  - call the get-orig-source target

 I think it's perfectly reasonable to want the get-orig-source target
 to give you a *specified* version of an upstream tarball, rather than
 the *newest* version of an upstream tarball.  Packaging a new upstream
 version doesn't necessarily mean packaging the latest that uscan can
 find.

Fair enough. But that is not the semantics of the target
 currently: get-orig-source is defined right now to get the  /latest/
 source, and while it is reasonable to have both behaviours, it is not
 necessary to expect both from the same target.

To recap:
 1) apt-get source is enough to get the latest Debian source from the
archive (and whet for older sources)
 2) In the absence of munging, uscan, with a watch and watch-current
files, is adequate to get either the latest or a specific version
from upstream
 3) It is reasonable to get the latest, or a specific version, from
upstream, and munge it.

So, for case 3: get-orig-source has been defined to get the
 latest sources (with munging, if needed). If we want to get a specific
 version, we can:
  a. over-load get-orig-source to take a version number, some how,
 through an env variable, perhaps
  b. create a brand new target, which looks at the env variable, and
 falls back to the version in the changelog.

I think case a is harder from a policy creation perspective,
 since it should not outlaw currently conforming implementations. The
 new target method can be deployed, tested in the wild, and then made
 into policy when the kinks have been ironed out.

manoj
-- 
Writing is turning one's worst moments into money. J.P. Donleavy
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Breaking /emul/ia32-linux for squeeze

On Thu, Mar 12, 2009 at 11:03:06AM +0100, Goswin von Brederlow wrote:

  What transitional issues is that going to cause us if and when multiarch
  becomes generally available, if biarch packages start using the path now?

 libfoo i386 then needs Replaces: lib32foo. But it already needs
 Conflicts: lib32foo I think so there isn't really any harm done.

No, currently there isn't anything else that would require adding such a
conflict.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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

Re: Bug#519339: ITP: tmux -- an alternative to screen, licensed under 3-BSD

2009-03-12 Thread William Pitcock

On Wed, 2009-03-11 at 23:56 +0100, Karl Ferdinand Ebert wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Karl Ferdinand Ebert kfeb...@gmail.com
 
 * Package name: tmux
   Version : 0.7
   Upstream Author : Nicholas Marriott n...@users.sf.net
 * URL : http://sf.net/projects/tmux
 * License : BSD
   Programming Lang: C
   Description : an alternative to screen, licensed under 3-BSD
 
 tmux enables a number of terminals (or windows) to be accessed and
  controlled from a single terminal. tmux runs as a server-client system.
  A server is created automatically when necessary and holds a number of
  sessions, each of which may have a number of windows linked to it.
  Any number of clients may connect to a session, or the server may be
  controlled by issuing commands with tmux. Communication takes place
  through a socket, by default placed in /tmp.

What does this have over screen, other than being BSD licensed?

The design of tmux seems less secure, too.

William


signature.asc
Description: This is a digitally signed message part

Re: Bug#466550: Pristine source from upstream VCS repository

Gunnar Wolf gw...@gwolf.org writes:

 Good point you have here - But (and I know it is not being discussed
 yet, maybe you want to teleport this thread a couple of years into the
 future) I feel this should clearly be an optional target, and the
 canonical location for orig.tar.gz files should still be our archive -
 Down the other road lies Gentoo's BSD ports' madness, where an upstream
 site restructure means packages become unreachable and insta-FTBFS.

I certainly agree with this.  I'm not sure if anyone was proposing using
get-orig-source instead of the archive for revisions of the same upstream
version, but I definitely agree that the Debian archive is the canonical
source.

I personally use the same technique that Steve uses for the packages that
I maintain that need to be repacked, and I'm having a failure of
imagination for how I could do it the way that Manoj describes.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


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

Re: Bug#466550: Pristine source from upstream VCS repository

On Thu, Mar 12 2009, Russ Allbery wrote:

 I personally use the same technique that Steve uses for the packages that
 I maintain that need to be repacked, and I'm having a failure of
 imagination for how I could do it the way that Manoj describes.

Hmm. Let me see if I can elucidate. Here is my work flow.

 a) Run a upstream version check from cron, which mails me if there are
new upstream versions of something I have.
 b) If there is a new upstream version, cd checked out dir
1. No munging required: use uscan --rename --verbose to get the
   latest source.
2. Munging needed. Run get-orig-source to get the latest upstream
   source via uscan; and munge it as needed to create the
   orig.tar.gz file
 c) Proceed as per:

http://www.golden-gryphon.com/blog/manoj/blog/2009/02/25/A_day_in_the_life_of_a_Debian_hacker/

Is this so very different from what people do? Some times I  do
 not package every upstream version, if they are coming in rapid
 succession, or if I find some version unfit for Debian -- but in any
 case, the majority of the time I want to package the very latest
 upstream version.


manoj
-- 
The world is coming to an end.  Please log off. Bob Irwin
(bir...@ficc.ferranti.com)
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug#466550: Pristine source from upstream VCS repository

Manoj Srivastava sriva...@debian.org writes:

  a) Run a upstream version check from cron, which mails me if there are
 new upstream versions of something I have.
  b) If there is a new upstream version, cd checked out dir
 1. No munging required: use uscan --rename --verbose to get the
latest source.
 2. Munging needed. Run get-orig-source to get the latest upstream
source via uscan; and munge it as needed to create the
orig.tar.gz file

Oh, okay, so your get-orig-source target would internally use uscan.  How
do you tell from that what tarball it downloaded for an automated target?
Would you parse the output of uscan somehow?

  c) Proceed as per:
 
 http://www.golden-gryphon.com/blog/manoj/blog/2009/02/25/A_day_in_the_life_of_a_Debian_hacker/

 Is this so very different from what people do? Some times I do
  not package every upstream version, if they are coming in rapid
  succession, or if I find some version unfit for Debian -- but in any
  case, the majority of the time I want to package the very latest
  upstream version.

I never use uscan --download; I always download the new upstream source
myself using wget or a web browser or FTP client.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


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

Re: best practice for updating inetd.conf with a user-chosen port?

Eric Cooper e...@cmu.edu writes:

 Regarding the other thread in -devel about the future of inetd: in my
 case I found it very sensible to jettison all the code for opening
 sockets, binding ports, handling IPv6, handling tcp-wrappers,
 daemonizing processes, etc.  and punt it to inetd.  Since apt clients
 keep their connections open for many multiple, the performance hit is
 negligible.

Yeah, I disagree with the idea that inetd is a bad choice for new
programs.  Writing a standalone daemon requires a fair bit of networking
knowledge and work, particularly if you also want to support IPv6, and
inetd can already do all that for you.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


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

Re: New Security Team Members

2009-03-12 Thread Raphael Faria

Congratulation  for Nico and Steffen.

Can i ask how they started to work and develop with security? My dream is to
become an security developer/professional.


2009/3/11 Joey Schulze j...@infodrom.org

 We're glad to announce the addition of Nico Golde and Steffen Joeris
 as full members of the security team.  Both developers have worked on
 testing-security before and are extending their work to the old and
 current stable releases of Debian GNU/Linux.

 Regards,

Joey

 --
 GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto

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

 iD8DBQFJt9RwW5ql+IAeqTIRAhZcAJ9RK2CDLe1z8lCu/b2qa1z5BVsV0wCgh7WD
 5/fWDrZRJH/lScsDgLt68zI=
 =VnXd
 -END PGP SIGNATURE-




-- 
Raphael Ottoni S M de Faria


There is no spoon...

  ,   ,
 / \
((__-^^-,-^^-__))
 `-_---' `---_-'
  `--|o` 'o|--'
 \  `  /
  ): :(
  :o_o:
   -

Re: About the current state of the Yum package in Lenny

2009-03-12 Thread Thomas Goirand

Hi,

I'm sorry that it took us so much time to make a working yum package,
but we were quite overloaded with our work, taking over all the
customers of another web hosting company (taking all our time doing
support). Anyway, I could today take the time to upload a working
version of yum. Here it is:

ftp://ftp.gplhost.com/debian/dists/lenny/main/source/yum_3.2.21-1~gplhost1.dsc

I guess you could notice that this is a newer upstream version. Please
let me know if you think this would be an acceptable replacement to be
sent in lenny proposed updates. At least, I'd be happy if somebody could
NMU it to SID or experimental, so there's at least something working
available in the archive.

Also, I would be very happy if some other people could TEST this version
and confirm that it's now working. According to us, and our needs
(bootstrap a CentOS from network), it is, but we didn't run extended
testings.

Thomas Goirand


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

Re: debhelper = 7.2.3, doc-base, and lintian

2009-03-12 Thread Jay Berkenbilt


 I just built a new version of one of my packages, and I got some lintian
 errors like this:

 E: qpdf: prerm-does-not-call-installdocs usr/share/doc-base/qpdf-manual

 Upgrading to Lintian 2.2.7 should fix this problem.  debhelper is correct.

  + [RA] Explicit install-docs calls are no longer needed since doc-base
registration is done with triggers.  (Closes: #518801)

To those who pointed out that my lintian was out of date, thanks.
Sorry for the noise on this.  I don't know how I could have missed
that.  I must have updated my chroot and not updated my regular
system.  Or maybe I got caught in a window with my local mirror.  Oh
well.  Time to clean and reconnect my brain cables.

-- 
Jay Berkenbilt q...@debian.org


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

Re: Bug#466550: Pristine source from upstream VCS repository

2009-03-12 Thread Bernd Zeimetz

Hi,

 The best way to get the exact sources for the current version
  probably should be a  new watch file (watch-current) which has a static
  version number in the regexp, but can use all the other facilities f
  uscan -- wild carded directory, looking thoiugh an index.html page for
  a matching href, and so on.

No, please don't just add another watch file just for the sake of it, using
these files is more or less like living in the last century. People are able to
get the current source from the Debian pool, if that is not enough for them,
they should be old enough to be able to click on the upstream homepage link in
the package's description and get the source.

A lot of people, including myself, prefer to pull form the upstream vcs
directly, and work on top of that, using git for example. Using uscan to
retrieve the exact version is often impossible, as it's not trivial to get a
tarball from a specific upstream branch, tag or ref.

I think the way Debian should go is to tell people that they should clone the
developer's git ([.. insert your favourite dvcs here ...]) repository and work
with it, probably requiring to explain how working with the repository works,
which branches are used for what, and so on. At least that would fit *todays*
way of handling packages, at least for a lot of people.

Cheers,

Bernd

-- 
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79


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

Re: Breaking /emul/ia32-linux for squeeze

Steve Langasek vor...@debian.org writes:

 On Thu, Mar 12, 2009 at 11:03:06AM +0100, Goswin von Brederlow wrote:

  What transitional issues is that going to cause us if and when multiarch
  becomes generally available, if biarch packages start using the path now?

 libfoo i386 then needs Replaces: lib32foo. But it already needs
 Conflicts: lib32foo I think so there isn't really any harm done.

 No, currently there isn't anything else that would require adding such a
 conflict.

When dpkg supports multiarch then you could have libfoo (i386) and
lib32foo installed at the same time. That would mean that you have
(possibly) 2 different versions of  the same library installed. ld.so
would then prefer one over the other resulting in either packages
depending on lib32foo or package depending on libfoo (i386) to use the
wrong library. A package with Depends: libfoo (= 1.2-3) could
suddenly get libfoo 1.1-1 (from lib32foo) and crash.

So to make sure there is only one package providing a specific library
for an arch the lib32foo and libfoo (i386) packages have to conflict.

MfG
Goswin


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

Re: Bug#466550: Pristine source from upstream VCS repository

2009-03-12 Thread Bernd Zeimetz

Manoj Srivastava wrote:
  a) Run a upstream version check from cron, which mails me if there are
 new upstream versions of something I have.

What happens if your watch file breaks? Do you check upstream announcements
manually, too?

  b) If there is a new upstream version, cd checked out dir
 1. No munging required: use uscan --rename --verbose to get the
latest source.
 2. Munging needed. Run get-orig-source to get the latest upstream
source via uscan; and munge it as needed to create the
orig.tar.gz file
  c) Proceed as per:
 
 http://www.golden-gryphon.com/blog/manoj/blog/2009/02/25/A_day_in_the_life_of_a_Debian_hacker/
 
 Is this so very different from what people do? 

Depends on the package, for the really easy ones I works as described above
probably (didn't read the webpage, though), but as soon as 'munging' or
get-orig-source is needed, I prefer to pull from upstream's repository directly.
Makes live much more easy.

For those cases where a git pull is not enough, I've setup cronjobs which pull
from upstream and push into the according branches in my git, usually named
upstream-svn/upstream-cvs or similar.


Bernd

-- 
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79


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

Re: best practice for updating inetd.conf with a user-chosen port?

Giacomo A. Catenazzi c...@debian.org writes:

 Francesco P. Lovergine wrote:
 On Wed, Mar 11, 2009 at 04:56:20PM +0100, Giacomo A. Catenazzi wrote:
 how to had new services in /etc/services database?

 Asking netbase maintainer(s)? Just read /etc/services about that.

 Hmm. Reading your and dato answers, it seems I wrote wrongly my mail.

 The question (still in subject) was how to have admin-chosen
 ports for some services. The first proposal was to dynamically change
 port in inetd configuration.

 I proposed to move the dynamic port in the /etc/services level, not
 necessary modifying such file, but in a way accessible to getservbyname(3).

 But now I'm not sure about:
 - if it is a good thing to have admin choosed ports

Many people run services on non standard ports to avoid password and
vulnerability scanners. The kind that repedatly tries to lock into
your sshd with stupid user/pass combos.

 - if /etc/services level is the right thing to do.

 ciao
   cate

I don't think you can do this through /etc/services. Say I want my
proftpd to run on port 2121 so I change ftp to 2121. Now suddenly
applications would look for ftp.debian.org on port 2121.

MfG
Goswin


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

Re: Bug#466550: Pristine source from upstream VCS repository

Bernd Zeimetz be...@bzed.de writes:

 No, please don't just add another watch file just for the sake of it,
 using these files is more or less like living in the last
 century. People are able to get the current source from the Debian pool,
 if that is not enough for them, they should be old enough to be able to
 click on the upstream homepage link in the package's description and get
 the source.

 A lot of people, including myself, prefer to pull form the upstream vcs
 directly, and work on top of that, using git for example. Using uscan to
 retrieve the exact version is often impossible, as it's not trivial to
 get a tarball from a specific upstream branch, tag or ref.

 I think the way Debian should go is to tell people that they should
 clone the developer's git ([.. insert your favourite dvcs here ...])
 repository and work with it, probably requiring to explain how working
 with the repository works, which branches are used for what, and so
 on. At least that would fit *todays* way of handling packages, at least
 for a lot of people.

Hm, I think I disagree with most of this.

First, I think this new habit (which you don't mention directly but
somewhat allude to) of not making stable formal releases is a very bad one
and I would strongly encourage any of my upstreams to not go down that
path.  The difference may be more psychological than technical, but it's
important to assign a version number on something and push it out the door
and declare it released.  Otherwise, projects have a strong tendency to
drift into perpetual development mode, where it's a crap-shoot whether any
given feature will be working at the moment and often it's quite difficult
to find a point in time when everything is stabilized.  I have one
upstream that does this just use the VCS thing and in practice it's
incredibly obnoxious for trying to get their software into Debian.

If there are stable upstream releases, I think that's what the Debian
packaging should be based on.  If you also want to use Git remotes to
track the upstream revision control repository so that you have more
fine-grained metadata, that's great, but I think a lot of clarity and
reproducibility is gained by having upstream release a tarball and by
basing the Debian package on exactly that tarball.  There's a lot to be
said for a clear export and externalization from the VCS that everyone can
synchronize with, regardless of tools.

On the topic of finding the current upstream release, I definitely don't
agree with the idea that the home page link solves this problem.  Some
upstreams have extremely bizarre release processes, poor home pages, no
real home page at all, or make it difficult to figure out just where the
source is at.  Having a watch file that embeds all of the packager's
existing knowledge about how to find the upstream release is very
valuable.

Also, I think you're underestimating the utility of being able to find
exactly the tarball that was used for generating a given Debian package.
It allows independent verification of the package in the archive (useful
in some security scenarios), and it's very important for package
sponsorship where one should not trust the orig.tar.gz provided by the
sponsoree unless you already know the sponsoree well.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


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

Re: Breaking /emul/ia32-linux for squeeze

On Thu, Mar 12, 2009 at 08:52:04PM +0100, Goswin von Brederlow wrote:
 Steve Langasek vor...@debian.org writes:

  On Thu, Mar 12, 2009 at 11:03:06AM +0100, Goswin von Brederlow wrote:

   What transitional issues is that going to cause us if and when multiarch
   becomes generally available, if biarch packages start using the path now?

  libfoo i386 then needs Replaces: lib32foo. But it already needs
  Conflicts: lib32foo I think so there isn't really any harm done.

  No, currently there isn't anything else that would require adding such a
  conflict.

 When dpkg supports multiarch then you could have libfoo (i386) and
 lib32foo installed at the same time. That would mean that you have
 (possibly) 2 different versions of  the same library installed. ld.so
 would then prefer one over the other resulting in either packages
 depending on lib32foo or package depending on libfoo (i386) to use the
 wrong library. A package with Depends: libfoo (= 1.2-3) could
 suddenly get libfoo 1.1-1 (from lib32foo) and crash.

 So to make sure there is only one package providing a specific library
 for an arch the lib32foo and libfoo (i386) packages have to conflict.

That's an arbitrary new requirement that TTBOMK has never previously been
discussed in the context of multiarch.

I think it has always been assumed that:

- multiarch will supersede all previous biarch implementations
- multiarch will be before biarch in the search path

Taken together, this guarantees the newer libs would always be found before
the older libs, so there's no need to do extra special-casing for those libs
that were previously available in biarch form.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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

Re: Bug#466550: Pristine source from upstream VCS repository

On Thu, Mar 12, 2009 at 12:38:24PM -0500, Manoj Srivastava wrote:

 Is this so very different from what people do? Some times I  do
  not package every upstream version, if they are coming in rapid
  succession, or if I find some version unfit for Debian -- but in any
  case, the majority of the time I want to package the very latest
  upstream version.

The difference is having a get-orig-source that works for the majority
case (I want to package the very latest), instead of working for all cases
(I want to package upstream version $x, which may or may not be the latest).

I don't see a good way to fit uupdate in with VCS-based packaging, so at
some point you have to manually increment the version number in
debian/changelog to point to the new upstream version you want, yes?  In
that case, it makes sense to me to do this once, then use the changelog
information to pull in the correct upstream tarball via the get-orig-source
target.

(N.B.: I say it makes sense to me, but in practice the packages I've
inherited hardcode the version to pull in debian/rules rather than parsing
the changelog.  I consider this a minor bug that I just haven't gotten
around to fixing.)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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

Re: Bug#466550: Pristine source from upstream VCS repository

2009-03-12 Thread Bill Allombert

On Thu, Mar 12, 2009 at 09:59:50AM -0700, Russ Allbery wrote:
 I personally use the same technique that Steve uses for the packages that
 I maintain that need to be repacked, and I'm having a failure of
 imagination for how I could do it the way that Manoj describes.

I use versionned for packages which upstream source is not versionned
(no tarball and no VCS).
In that case debian/get-orig-source download what is needed,
build the tarball and version it with the current date.
A checksum is used to check whether it is any different from the
previous version.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


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

Re: Bug#466550: Pristine source from upstream VCS repository

Steve Langasek vor...@debian.org writes:

 (N.B.: I say it makes sense to me, but in practice the packages I've
 inherited hardcode the version to pull in debian/rules rather than
 parsing the changelog.  I consider this a minor bug that I just haven't
 gotten around to fixing.)

I got into the habit of doing it that way because for some of my packages
there isn't a clear mapping between the Debian version and the upstream
version.  (Tildes may have to be added, for example, and dfsg removed.)  I
ended up doing it the same way everywhere, although I agree that for
simpler cases it would be better to use debian/changelog.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


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

Re: [luabind] Naming library with proper SONAME

2009-03-12 Thread Adeodato Simó

* Roberto C. Sánchez [Tue, 10 Mar 2009 18:30:19 -0400]:

 I am curious as to what people generally think of how the libluabind
 SONAME will be going forward.  I know that certain packages (like
 libssl) have the complete version in the SONAME, but I can't imagine
 that this is a really good idea.  Is this a showstopper for having
 libluabind in Debian, or just for a stable release?  Is this
 discouraged, but otherwise permissible?

It’s certainly not desirable. Do you have an estimation of how many
reverse dependencies libluabind will have? Goswin’s remark about API
compatibility is also an important one.

Cheers,

-- 
- Are you sure we're good?
- Always.
-- Rory and Lorelai


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

Re: Hai să traducem http://www.debian.org/ intl/l10n/po-debconf/ro

2009-03-12 Thread Eddy Petrișor

d olariu a scris:
 Salve, Eddy.
 
 Nu am reuşit sa ajung pe pagina respectivă cu XX (eroare 404), ca să îmi

Era normal să nu fie, XX era o metodă de a spune orice pagină de
acolo; există câte o pagină pentru fiecare limbă în care există
traducere în Debian.

 dau seama cam cât timp (not money) mi-ar putea lua traducerea ei la
 standardele mele de calitate. Dacă poţi să-mi trimiţi un fisier ..rtf,
 .odt, .txt am să încerc să fac traducerea ASAP.
 
 Am ajuns însă pe pagina cu RO şi estimez că-mi va lua maxim 3 ore
 (inclusiv să-ti trimit e-mailul). Era fain daca era ceva gen
 RO.WIKIPEDIA.ORG!!!

Nu înțeleg. În ce sens gen ro.wikipedia.org ? Să poți să traduci online?

 Cheers,

 P.S. - Einstein nu a înţeles pericolul armelor cu explozie nucleară, aşa
 cum a făcut-o Teller

De aceea imaginația e mai importantă decât cunoștințele.

-- 
Regards,
EddyP
=
Imagination is more important than knowledge A.Einstein



signature.asc
Description: OpenPGP digital signature

Re: sudo pbuilder build - error

2009-03-12 Thread Chow Loong Jin

On Thu, 2009-03-12 at 20:18 +0100, Jaromír Mikeš wrote:
  Od: Jonathan Wiltshire deb...@jwiltshire.org.uk
 
  On Thu, Mar 12, 2009 at 07:40:42PM +0100, Jaromír Mikeš wrote:
   /usr/bin/install: cannot create regular file `/usr/bin/jkmeter': 
   Permission
   denied
  
  At a guess, the upstream build process isn't taking any notice of your
  DESTDIR. But if you can put the source somewhere visible, it will be much
  easier
  to advise.
 
 In attachment is my debianized source ...
 
 regards 
 
 mira
You'll have to patch source/Makefile to give it DESTDIR support.
-- 
Chow Loong Jin


signature.asc
Description: This is a digitally signed message part

Re: [un peu HS] inflation de la taille des paquets (et/ou de /usr) en 5 ans

2009-03-12 Thread JP Bochet (jeep)

 
 A = Aurelien 

Le(On) Thu, 12 Mar 2009 09:07:24 +0100,
Aurelien  écrivait(wrote) :

   A Salut,
Bonsoir,

   A Bon, c'est peut-être un peu trollesque, jen'en sais rien, mais
   A n'étant pas sur le net le vendredi (!), je poste aujourd'hui.

Bah, on y arrive ! ;)

   A Ca fait plusieurs fois que les upgrades que je lance sur ma
   A machine (en SID) s'arrêtent faute de place sur la partition
   A /usr.  Ca ne me pose pas particulièrement de problème, je
   A trouve des moyens pour m'en sortir, mais elle fait quand même
   A 4Go.

Je te confirme que chez moi (moyennant qq exclude de /usr/local et
/usr/src qui font bien 10G à eux deux) /usr tourne autour de ~ 5G
Sans gnome, ni KDE.
Mais Xemacs, Oo, ardour, le Gimp, AMP, blackbox, etc... comme toi.
real troll
[non, ici c'est 'amule' depuis qu'il existe, avant c'était MlDonkey]
/real troll

Je pense qu'on doit pouvoir, sans trop de difficultés ramener /usr à
moins de 3G, après un peu de boulot.
Mais il est sûr que plus ça va, moins l'install *par défaut* est
économe avec les octets (surtout avec les gnome-* et/ou K*).

Difficile d'essayer d'attirer à *tous prix* (donc, celui-là) les
ouine-users et satisfaire les écolo-geeks en mm temps ! ;)
Mais il y a une certaine logique, puisque le geek pourra tjrs faire
son ch'ti ménage, voire se faire son install 'alamano' et, du coup,
bouffer *beaucoup moins* de place.

Là où c'est dur, c'est pour l'écolo-newbie ...

L'avantage de Debian, c'est quand même que c'est tellement souple et
'apt*'/'dpkg' tellement bien foutus, qu'on peut faire à peu près ce
qu'on veut au niveau paquets.

Sinon ... ahem ... il te reste LFS, hein !? :)

[...]
   A Donc, je me demandais : comment se fait-il que la taille de
   A /usr ait autant augmenté (plus de traduction des docs et plus
   A de docs qu'avant, augmentant de fait /usr/share ?...), et

En utilisant 'xdiskusage' tu peux connaître très finement
l'utilisation des partoches (ne pas hésiter à cliquer dans les 
« cases » pour descendre en profondeur) ; ça pourra te permettre de
voir ce qui -- chez toi -- prend « trop » de place et le virer, le
cas échéant.

Personellement je ne sais plus m'en passer depuis que je l'ai
découvert un jour où, comme toi, je me suis retrouvé avec une
partoche saturée sans comprendre comment/pourquoi.

   A surtout est-ce que c'est légitime ?  Je sais que les disques

Tu pourras mieux en décider quand tu sauras exactement qui utilise
combien, je pense.

   A actuellement sont beaucoup plus gros, mais je suis un
   A inconditionnel du recyclage et de l'économie de moyens quand

\o/

   A c'est possible, et donc, je trouve ça un peu chiant de galérer
   A à utiliser un vieux disque 20 ou 30 Go parce que /usr prend
   A minimum 5Go -et peut-être faut que je prévois plus), que /tmp
   A doit être gros vu ce que je fais, et que /var doit être gros
   A aussi si je suis en SID.

Je vois pas le rapport, tu parles du cache d'apt ?
Si oui, un 'apt-get autoclean' régulièrement et un '... clean' de
temps en temps devrait faire l'affaire.
Et un peu de ménage dans les logs.
Moyennant quoi ta partoche /var ne devrait pas dépasser 500M.

[...]
   A Bonne journée.  Aurélien

Bonne soirée/nuit.

Bon, vendredi dans *deux* heures ... tant pis, j'envois *PAF* ! ;)

Jeep.
-- 
Aimer, c'est jouir, tandis que ce n'est pas jouir que d'être aimé.
-+- Aristote -+-


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

Re: Problemas como arquivos java

2009-03-12 Thread Jean Silva


Veja:

http://javafree.uol.com.br/viewtopic.jbb?t=868743


--- Em qui, 12/3/09, Welisson welissont...@ig.com.br escreveu:

 De: Welisson welissont...@ig.com.br
 Assunto: Problemas como arquivos java
 Para: debian-user-portugu...@lists.debian.org
 Data: Quinta-feira, 12 de Março de 2009, 10:24
 Boa tarde a todos.
 
 
 Gostaria de um help do pessoal. preciso abrir o arquivo de
 recibo da receita
 que salvei e ele é em jrprint, porem não consigo
 visualizar ele.
 Qual aplicação para esse arquivo ser aberto e lido.


  Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com


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

Re: [luabind] Naming library with proper SONAME

2009-03-12 Thread Roberto C . Sánchez

On Thu, Mar 12, 2009 at 10:18:59PM +0100, Adeodato Simó wrote:
 * Roberto C. Sánchez [Tue, 10 Mar 2009 18:30:19 -0400]:
 
  I am curious as to what people generally think of how the libluabind
  SONAME will be going forward.  I know that certain packages (like
  libssl) have the complete version in the SONAME, but I can't imagine
  that this is a really good idea.  Is this a showstopper for having
  libluabind in Debian, or just for a stable release?  Is this
  discouraged, but otherwise permissible?
 
 It’s certainly not desirable. Do you have an estimation of how many
 reverse dependencies libluabind will have? Goswin’s remark about API
 compatibility is also an important one.
 
Currently, none of the luabind packages have reverse dependencies
(except for stuff like libluabind-dbg depending on libluabind0).

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Bug#519339: ITP: tmux -- an alternative to screen, licensed under 3-BSD

2009-03-12 Thread Karl Ferdinand Ebert

Am Thursday 12 March 2009 11:13:00 schrieb Guus Sliepen:
 On Wed, Mar 11, 2009 at 11:56:01PM +0100, Karl Ferdinand Ebert wrote:
  * Package name: tmux
Description : an alternative to screen, licensed under 3-BSD

 The short description should stand on its own, not reference other
 software. You can mention this package's relation with screen in the long
 description. You also should not mention its license in the long or short
 description, that's what the copyright file is for. The short description
 should probably just be terminal multiplexer.

The short description had been terminal multiplexer from the first packaging 
attempts but I did not know it had to be the line in the bug report. The long 
description is extended with details from the FAQ:

* How is tmux different from GNU screen? What else does it offer?

tmux offers several advantages over screen:

- a clearly-defined client-server model: windows are independent entities 
which
  may be attached simultaneously to multiple sessions and viewed from multiple
  clients (terminals), as well as moved freely between sessions within the 
same
  tmux server;
- a consistent, well-documented command interface, with the same syntax
  whether used interactively, as a key binding, or from the shell;
- easily scriptable from the shell;
- multiple paste buffers;
- choice of vim or emacs key layouts;
- an option to limit the window size;
- a more usable status line syntax, with the ability to display the first line
  of output of a specific command;
- a cleaner, modern, easily extended, BSD-licensed codebase.

From Williams' email:
 What does this have over screen, other than being BSD licensed?

answered above.
 The design of tmux seems less secure, too.

In which way is it less secure? 
My first contact with this package was on a OpenBSD mallinglist, as I followed 
those discussions some developers where involved.
(I do not mean it is more secure by that but I appreciate their code in 
general)


Regards,


Ferdinand


signature.asc
Description: This is a digitally signed message part.

Re: [luabind] Naming library with proper SONAME

2009-03-12 Thread Adeodato Simó

* Roberto C. Sánchez [Thu, 12 Mar 2009 17:34:20 -0400]:

  It’s certainly not desirable. Do you have an estimation of how many
  reverse dependencies libluabind will have? Goswin’s remark about API
  compatibility is also an important one.

 Currently, none of the luabind packages have reverse dependencies
 (except for stuff like libluabind-dbg depending on libluabind0).

Yes, but I asked about an *estimation* of how many there *will* be.

-- 
- Are you sure we're good?
- Always.
-- Rory and Lorelai


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

Re: [luabind] Naming library with proper SONAME

2009-03-12 Thread Roberto C . Sánchez

On Thu, Mar 12, 2009 at 10:39:37PM +0100, Adeodato Simó wrote:
 * Roberto C. Sánchez [Thu, 12 Mar 2009 17:34:20 -0400]:
 
   It’s certainly not desirable. Do you have an estimation of how many
   reverse dependencies libluabind will have? Goswin’s remark about API
   compatibility is also an important one.
 
  Currently, none of the luabind packages have reverse dependencies
  (except for stuff like libluabind-dbg depending on libluabind0).
 
 Yes, but I asked about an *estimation* of how many there *will* be.
 
Good question.  I do not know, but I would be surprised if it were more
than a handful (10 at most).

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: RFS: tmux (updated package)

2009-03-12 Thread Karl Ferdinand Ebert

Hi,

Am Thursday 12 March 2009 07:37:11 schrieb Kapil Hari Paranjape:
 Hello,

 On Wed, 11 Mar 2009, Karl Ferdinand Ebert wrote:
  I am looking for a sponsor for the new version 0.7-1
  of my package tmux.

 Here are some comments:
 - add FAQ to docs
 - add CHANGES file as upstream changelog
 - ITP bug will be closed by the first upload not the first packaging
 attempt So the Closes should come in the topmost changelog entry.
 - some licenses are BSD 3-clause some are BSD-2 and others are of the type
   included in the debian/copyright file
 - include NOTES file in docs
 - include examples in docs

all added and long description extended by suggestions.


  The package appears to be lintian clean.

 Not so! :-(
 There are Lintian errors in your manpage (hyphen used as minus sign).

corrected. I was using linitian from stable, therefore I did not recognized 
these errors. 
 The report is attached.

 Regards,

 Kapil.
 --

thanks.

--
Ferdinand


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

Re: Lenovo laptop - Type Control D to Continue

2009-03-12 Thread Preston Boyington

Sebastian Günther wrote:
 * Jimmy Johnson (field.engin...@gmail.com) [12.03.09 15:18]:
 Hey Guy's I have Lenovo laptop, new Lenny install and I'm having to 
 type control+d to continue boot, I looked at dmesg and I can't make 
 what the problem is, so I post and maybe someone can figure the problem.

 If more info is needed let me know. :)

 At what point do you have to type Crtl-d?
 
 Is there any output before or after on the console?
 

stab in the dark
if by chance you see the login screen and then it craps out to the point
where it asks for you to type Ctrl-D then check your video driver.  I
had this happen with a friend's Nvidia card driver.  It was odd because
once he did the Ctrl-D it would go right in to his desktop.  He had
upgraded the system and didn't recompile his video driver which was
downloaded from Nvidia's site.

may not be your particular issue, but is an example of what it could be.

good luck.

Preston

-- 
Arrant Drivel - really, it's just trash...
http://www.arrantdrivel.com/

Where the road takes me - a highwaymans perspective
http://www.prestonboyington.com/


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

Re: suEXEC witch mod_userdir

2009-03-12 Thread Michael Loftis




--On March 13, 2009 4:11:28 AM +0800 Thomas Goirand tho...@goirand.fr 
wrote:



By the way, I'd like to find a nice way to build a Perl environment in a
chroot (I don't need anything else but perl), and for that, I'm quite
stuck. Best would be a minimal environment that allows to use CPAN to
add some modules. I often end up copying a WAY too much things, and I'd
like to know if any of you know a good way to have something really
minimal, and setup in a nicely (clean) way.


I always use debootstrap.  Problem with CPAN is it requires building so... 
apt-get installing build-essentials ... but you'll often need -dev stuff.




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

Re: Spiele für Linux

2009-03-12 Thread Manfred Rebentisch

Ich antworte mir mal selbst, um euch allen zu antworten. Ich finde das toll, 
wieviele Hinweise und Links ihr genannt habt. Ich werde mir das mit meinen 
Kindern angucken und alles ausprobieren, was denen gefällt.

HERZLICHEN DANK!


Manfred


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

Re: Bug#519339: ITP: tmux -- an alternative to screen, licensed under 3-BSD

2009-03-12 Thread Steve Kemp

On Thu Mar 12, 2009 at 22:37:41 +0100, Karl Ferdinand Ebert wrote:

 - a more usable status line syntax, with the ability to display the first line
   of output of a specific command;

  That is also possible in GNU Screen.

 - a cleaner, modern, easily extended, BSD-licensed codebase.

  That would be a nice bonus.  Frankly the GNU Screen codebase
 is very messy.  (I've worked with it a fair bit.)

  The design of tmux seems less secure, too.

 In which way is it less secure?

  I've not looked at this at all -  but the idea of shared sockets
 in /tmp which I recall from a previous message in the thread jumped out
 at me as being a recipe for symlink attacks, if nothing else.

Steve
-- 
Try out tscreen - My fork of GNU Screen:
http://www.steve.org.uk/Software/tscreen


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

Re: Bug#519339: ITP: tmux -- an alternative to screen, licensed under 3-BSD

2009-03-12 Thread Guus Sliepen

On Thu, Mar 12, 2009 at 10:37:41PM +0100, Karl Ferdinand Ebert wrote:

  The short description should stand on its own, not reference other
  software.
 
 The short description had been terminal multiplexer from the first 
 packaging 
 attempts but I did not know it had to be the line in the bug report.

The title of the ITP is OK.

 description is extended with details from the FAQ:
 
 * How is tmux different from GNU screen? What else does it offer?
 
 tmux offers several advantages over screen:
 
 - a clearly-defined client-server model: windows are independent entities 
 which
   may be attached simultaneously to multiple sessions and viewed from multiple
   clients (terminals), as well as moved freely between sessions within the 
 same tmux server;

I do not really see anything here that screen can't do... 

 - a consistent, well-documented command interface, with the same syntax
   whether used interactively, as a key binding, or from the shell;

This is something screen also has.

 - easily scriptable from the shell;

You can also script screen from the shell.

 - multiple paste buffers;

Screen has a single so-called pastebuffer but allows you to easily move it to
and from registers or named files, effectively giving you multiple paste
buffers.

 - choice of vim or emacs key layouts;

Screen has both vi and emacs style bindings, some work concurrently.

 - an option to limit the window size;

Also something screen can do.

 - a more usable status line syntax, with the ability to display the first line
   of output of a specific command;

I don't know about that.

 - a cleaner, modern, easily extended, BSD-licensed codebase.

That is not an important feature for binary packages of course, but you can
mention this.

Almost all of these advantages over screen are features shared with screen.
Maybe some of them are a bit easier to use in tmux, but that is all as far is I
can see. I would therefore not mention these things in the long description.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen g...@debian.org


signature.asc
Description: Digital signature

Re: Bug#519339: ITP: tmux -- an alternative to screen, licensed under 3-BSD

2009-03-12 Thread Carsten Hey

On Thu, Mar 12, 2009 at 11:17:02PM +0100, Guus Sliepen wrote:
 On Thu, Mar 12, 2009 at 10:37:41PM +0100, Karl Ferdinand Ebert wrote:
  - a clearly-defined client-server model: windows are independent
  entities which may be attached simultaneously to multiple sessions
  and viewed from multiple clients (terminals), as well as moved
  freely between sessions within the same tmux server;

 I do not really see anything here that screen can't do...

GNU screen can't move one window from one session to another or attach
one window to two session.


Regards,
Carsten


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

Re: Bug#466550: Pristine source from upstream VCS repository

On 12-Mar-2009, Gunnar Wolf wrote:
 I feel this should clearly be an optional target, and the canonical
 location for orig.tar.gz files should still be our archive

Yes to both. Thanks for making this explicit in the discussion.

-- 
 \  “Reichel's Law: A body on vacation tends to remain on vacation |
  `\unless acted upon by an outside force.” —Carol Reichel |
_o__)  |
Ben Finney b...@benfinney.id.au


signature.asc
Description: Digital signature

Bug#519465: ITP: nlog -- simple and flexible logging library for the CLI

2009-03-12 Thread Mirco Bauer

Package: wnpp
Severity: wishlist
Owner: Mirco Bauer mee...@debian.org

* Package name: nlog
  Version : 1.0
  Upstream Author : Jaroslaw Kowalski j...@jkowalski.net and others
* URL : http://www.nlog-project.org/
* License : BSD
  Programming Lang: C#
  Description : simple and flexible logging library for the CLI

NLog is a logging library for the Common Language Infrastructure (CLI)
designed with simplicity and flexibility in mind. With NLog you can process
diagnostic messages emitted from any CLI language, augment them with
contextual information, format them according to your preference and send
them to one or more targets.

The API (application programming interface) is similar to other logging APIs
such as log4xxx, so porting your application is very easy. The configuration
is designed to be very simple. NLog uses a routing table which is very
readable and maintainable.

(this library is needed by the monsoon package which I am also preparing)

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



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

Re: Bug#466550: Pristine source from upstream VCS repository

On Thu, Mar 12 2009, Russ Allbery wrote:

Manoj Srivastava sriva...@debian.org writes:

a) Run a upstream version check from cron, which mails me if there are
new upstream versions of something I have.
b) If there is a new upstream version, cd checked out dir
1. No munging required: use uscan --rename --verbose to get the
latest source.
2. Munging needed. Run get-orig-source to get the latest upstream
source via uscan; and munge it as needed to create the
orig.tar.gz file

Oh, okay, so your get-orig-source target would internally use uscan.

It _could_ use uscan. it does not have to be limited to it.

How do you tell from that what tarball it downloaded for an automated
target? Would you parse the output of uscan somehow?

I just glob for the same pattern as in the watch file, and use
the last in the lexical sorting, I suppose one could use dpkg
--compare-versions if one were paranoid enough, and heck, use shell
sort on the orig tar balls discovered :P

c) Proceed as per:

http://www.golden-gryphon.com/blog/manoj/blog/2009/02/25/A_day_in_the_life_of_a_Debian_hacker/
Is this so very different from what people do? Some times I do
not package every upstream version, if they are coming in rapid
succession, or if I find some version unfit for Debian -- but in any
case, the majority of the time I want to package the very latest
upstream version.

I never use uscan --download; I always download the new upstream source
myself using wget or a web browser or FTP client.

But this is not about our individual work-flows -- it is about
policy trying hard not to proscrive the work flows _any_ of us use. If
it turns out there are two sets of processes people follow, I would
much rather have two mechanisms, with two different sets of semantics,
rather than have us select one in policy.

I am beginning to think this whole target is too immature to
actually be in policy; we are still doing design discussions of this
feature.

manoj
--
The real problem with hunting elephants is carrying the decoys.
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

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

Re: Bug#466550: Pristine source from upstream VCS repository

On Thu, Mar 12 2009, Bernd Zeimetz wrote:

 Manoj Srivastava wrote:
  a) Run a upstream version check from cron, which mails me if there are
 new upstream versions of something I have.

 What happens if your watch file breaks? Do you check upstream announcements
 manually, too?

While my personal work habits are interesting, they might not be
 wholly on topic for -policy et al. Yes, I do try and keep up with the
 upstream for my packages.  Is this relevant to the issue at hand?

manoj
-- 
Keep a diary and one day it'll keep you. Mae West
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug#466550: Pristine source from upstream VCS repository

On 12-Mar-2009, Manoj Srivastava wrote:
 To recap:
  1) apt-get source is enough to get the latest Debian source from the
 archive (and whet for older sources)

I presume you mean ‘wget’ here. (Apart from ‘apt-get source’, is there
another tool that is *solely* focussed on getting the Debian source
for a package by name?)

  2) In the absence of munging, uscan, with a watch and watch-current
 files, is adequate to get either the latest or a specific version
 from upstream

It's more limited than “in the absence of munging”. None of my
packages currently need munging, but there are some that upstream
doesn't *have* a tarball release for the code I want to package. Those
are the cases that led me to ‘get-orig-source’ in the first place,
since obviously ‘uscan’ can't handle those.

I would re-state this instead as: In the presence of upstream tarball
releases, which don't need munging, at the versions which need to be
packaged, ‘uscan’ is adequate for getting the original source archive.

  3) It is reasonable to get the latest, or a specific version, from
 upstream, and munge it.

Yes.

-- 
 \“With Lisp or Forth, a master programmer has unlimited power |
  `\ and expressiveness. With Python, even a regular guy can reach |
_o__)   for the stars.” —Raymond Hettinger |
Ben Finney b...@benfinney.id.au


signature.asc
Description: Digital signature

Re: Bug#466550: Pristine source from upstream VCS repository

Hi,
 
 [Moving this away from the BTS]

On Thu, Mar 12 2009, Steve Langasek wrote:

 On Thu, Mar 12, 2009 at 12:38:24PM -0500, Manoj Srivastava wrote:

 Is this so very different from what people do? Some times I  do
  not package every upstream version, if they are coming in rapid
  succession, or if I find some version unfit for Debian -- but in any
  case, the majority of the time I want to package the very latest
  upstream version.

 The difference is having a get-orig-source that works for the majority
 case (I want to package the very latest), instead of working for all
 cases (I want to package upstream version $x, which may or may not be
 the latest).

How do you propose that one specifies get and munge the latest
 source when one might not know a priori what the version number might
 be? The interface spec of this target that works for all cases is not
 very clear to me. Does a missing verion mean I want the latest? Or that
 I want to use the version in the Changelog? I had imagined that he
 current language in policy that says get the /latest/ was at least
 unambiguous on this, but I seem to have been in error.

Does it make sense to have more than one target? Should it be a
 target in rules, as opposed to a script in ./debian? The advantage of a
 separate script is hat it is easy to check if the script exists
 (whether or not a Make target exists is hard to determine), and it is
 easier to communicate options to a script.

I can see that we can have get-orig-source-latest and
 get-orig-source-current scripts in ./debian, and would prefer that to
 overloading a single make target, with all the hassles of assing
 arguments in env variables.

manoj
-- 
Bye Bye PDP 10
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug#466550: Pristine source from upstream VCS repository

On 12-Mar-2009, Russ Allbery wrote:
 Manoj Srivastava sriva...@debian.org writes:
 
   b) If there is a new upstream version, cd checked out dir
  1. No munging required: use uscan --rename --verbose to get the
 latest source.
  2. Munging needed. Run get-orig-source to get the latest upstream
 source via uscan; and munge it as needed to create the
 orig.tar.gz file
 
 Oh, okay, so your get-orig-source target would internally use uscan.
 How do you tell from that what tarball it downloaded for an
 automated target? Would you parse the output of uscan somehow?

Also, what do you do for the cases where upstream doesn't have a
tarbal (either none at all, or the code you want isn't yet available
as a tarball)?

Or do you (Manoj) not have any upstream packages making original
source available as anything but tarball releases?

 I never use uscan --download; I always download the new upstream
 source myself using wget or a web browser or FTP client.

Why is that? Is there some downside to using ‘uscan --download’? I
would have thought it best to use the automated tool where possible,
if for no other reason than to make sure the automated process will
get the same source you're working with.

-- 
 \ “I was born by Caesarian section. But not so you'd notice. It's |
  `\ just that when I leave a house, I go out through the window.” |
_o__)   —Steven Wright |
Ben Finney b...@benfinney.id.au


signature.asc
Description: Digital signature

Re: Bug#466550: Pristine source from upstream VCS repository

Ben Finney b...@benfinney.id.au writes:
 On 12-Mar-2009, Russ Allbery wrote:

 I never use uscan --download; I always download the new upstream source
 myself using wget or a web browser or FTP client.

 Why is that? Is there some downside to using ‘uscan --download’? I would
 have thought it best to use the automated tool where possible, if for no
 other reason than to make sure the automated process will get the same
 source you're working with.

I just personally have never needed it and never found it particularly
useful or interesting.  Getting the right upstream tarball is the least of
the things that I do around packaging new upstream source.  I'm often
packaging new upstream test releases or packaging something in advance of
it being available from upstream's web site, I look through the web site
for restructuring or other information that I need to be aware of, etc.

As Manoj says, this is more about personal workflow than really about what
Policy can talk about.  I guess that I find the current Policy definition
of get-orig-source rather uninteresting and wouldn't bother to implement
something that exactly follows what's there.  I *do* find it useful to
automate the process of stripping an upstream tarball of non-DFSG bits,
and when I first started doing Debian packaging, the examples I looked at
used get-orig-source to do that.  So that's what I started doing as well.

I'm open to the idea that this really isn't the best way of handling it
and we should standardize something other than get-orig-source as the way
of stripping an upstream tarball (such as, for instance, a script in the
debian/ directory that you run on the upstream source tarball, however you
obtained it).  I would rather not have only textual descriptions of what
to do.  It's nice to have it automated and to be able to look at a simple
shell script to see *exactly* what transformations are applied.

But I'm not sure I'd ever personally use a target that downloads the
current upstream source and tries to apply the stripping process that
worked with the last release I packaged, all as one atomic step.  It
doesn't fit my workflow.  (I of course have no objections to standardizing
a way of doing that for people who have different workflows than mine, or
restoring get-orig-source as the correct way of doing that and changing
all my targets to be something else.)

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


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

Re: Bug#466550: Pristine source from upstream VCS repository

On 12-Mar-2009, Bernd Zeimetz wrote:
 Hi,
 
  The best way to get the exact sources for the current
  version probably should be a  new watch file
  (watch-current) which has a static version number in the
  regexp

I don't see why this file would be needed, since a watchfile
specifying ‘debian’ as the version already has this effect (according
to the ‘uscan(1)’ manpage).

So I agree with this:

 No, please don't just add another watch file just for the sake of
 it,

but not for Bernd's reasons.

 using these files is more or less like living in the last century.

Given that we need to support tarballs from upstream for the
forseeable future, the existing ‘debian/watch’ files seem a good
solution for that limited scope.

 People are able to get the current source from the Debian pool, if
 that is not enough for them

There are many reasons to want to verify the Debian source package
against the original source archive; for example, security checks,
licensing checks, checking for packaging mistakes, etc.

 they should be old enough

This is rather condescending and judgemental; let's not dismiss as
childish the requirement to do something, without understanding the
reasons first.

 to be able to click on the upstream homepage link in the package's
 description and get the source.

The upstream home page for many packages makes it ridiculously
difficult to get to the original source archive. Some don't have the
original source discoverable from the home page; some don't even have
a home page.

Part of our job as package maintainers is to be an interface between
Debian users and upstream developers; getting the original source as
used by Debian surely counts, since many users want to develop the
package further. If we have to deal with that task more than once, we
should find ways to automate it both for ourselves and our users.

-- 
 \   “I don't care to belong to a club that accepts people like me |
  `\as members.” —Groucho Marx |
_o__)  |
Ben Finney b...@benfinney.id.au


signature.asc
Description: Digital signature

Re: New Security Team Members

2009-03-12 Thread Steffen Joeris

Hi Raphael

 Can i ask how they started to work and develop with security? My dream is
 to become an security developer/professional.

All the neccessary documentation to start with is here[0]. It is most 
important that we keep our security tracker[1] up to date, evaluate the 
issues and fix them accordingly (preferrably with the maintianer's help).
Once you've read through the documentation, feel free to email me in private. 
I am sure that there are tasks you could start helping us out with.

Cheers
Steffen

[0]: http://testing-security.debian.net/

[1]: http://security-tracker.debian.net/tracker/


signature.asc
Description: This is a digitally signed message part.

Re: RFS: tmux (updated package)

Karl Ferdinand Ebert ferdi1...@gmx.de writes:

 Hi,
 
 Am Thursday 12 March 2009 07:37:11 schrieb Kapil Hari Paranjape:
  On Wed, 11 Mar 2009, Karl Ferdinand Ebert wrote:
   The package appears to be lintian clean.
 
  Not so! :-(
  There are Lintian errors in your manpage (hyphen used as minus sign).
 
 corrected. I was using linitian from stable, therefore I did not
 recognized these errors.

If you upload the package targeted to ‘unstable’, you must build and
check it in an environment that is the latest ‘unstable’. See the
‘pbuilder’ package which can make this easier.

-- 
 \  “Better not take a dog on the space shuttle, because if he |
  `\   sticks his head out when you're coming home his face might burn |
_o__)up.” —Jack Handey |
Ben Finney


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

Lists had the hiccups

2009-03-12 Thread David Moreno

Hi,

During a small period of time during this afternoon, a few bounces from
other lists were received on -devel. We are aware of it and it has already
been fixed. If you happen to detect some unsual behavior on other lists
(there shouldn't be, but still), feel free to drop by #debian-lists on
IRC and let us know (or filing against lists.debian.org).

Imagine a fancy whale here held by birds, with a few swirls floating
around.

David.

In case of personal replies, CCme directly as I'm not subscribed to -devel.


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

Re: Bug#466550: Pristine source from upstream VCS repository

On Thu, Mar 12, 2009 at 06:48:32PM -0500, Manoj Srivastava wrote:
  Is this so very different from what people do? Some times I  do
   not package every upstream version, if they are coming in rapid
   succession, or if I find some version unfit for Debian -- but in any
   case, the majority of the time I want to package the very latest
   upstream version.

  The difference is having a get-orig-source that works for the majority
  case (I want to package the very latest), instead of working for all
  cases (I want to package upstream version $x, which may or may not be
  the latest).

 How do you propose that one specifies get and munge the latest
  source when one might not know a priori what the version number might
  be? The interface spec of this target that works for all cases is not
  very clear to me. Does a missing verion mean I want the latest? Or that
  I want to use the version in the Changelog? I had imagined that he
  current language in policy that says get the /latest/ was at least
  unambiguous on this, but I seem to have been in error.

Oh, I think the existing language is perfectly unambiguous, I'm just saying
that the behavior described doesn't seem to be what most/many maintainers
want in practice, with the result that many packages implement
get-orig-source targets that don't comply with this part of policy.

As for how to specify get and munge the latest source - for my purposes,
it's sufficient to do this by using out-of-band information about what new
upstream versions are available, update debian/changelog (which has to be
done anyway), and then call the debian/rules target.  But if grab whatever
the latest version is is also a common workflow, then perhaps a
standardized make variable?  e.g., './debian/rules get-orig-source
version=latest', './debian/rules get-orig-source version=2.3.9', etc.

OTOH, I'm not sure both of these cases need to be standardized in Policy,
either.  Certainly, the variation in semantics today means that none of
these targets are particularly useful to third-party developers without
first inspecting the debian/rules directly; and if the goal is to have
something that third parties can rely on, I'm reasonably convinced that the
grab the version matching debian/changelog approach is the one that's more
broadly useful - because it's the one that matches my own workflow, because
it's the one that I've seen others implement, and because it's the one I can
think of a use case for in a QA/NMU context.

But if it's useful to have both, I could be persuaded to provide a sample
implementation that can pull either from the changelog or from uscan as
described above.

 Does it make sense to have more than one target? Should it be a
  target in rules, as opposed to a script in ./debian? The advantage of a
  separate script is that it is easy to check if the script exists
  (whether or not a Make target exists is hard to determine), and it is
  easier to communicate options to a script.

I personally have a pretty strong preference for this being done in
debian/rules rather than as a new script in debian/.  I find my debian/
directories become cluttered enough with stuff not standardized in Policy,
without adding new Policy requirements to them. :)

 I can see that we can have get-orig-source-latest and
  get-orig-source-current scripts in ./debian, and would prefer that to
  overloading a single make target, with all the hassles of passing
  arguments in env variables.

I think that's inelegant because it implies code duplication between the
scripts, one script calling the other, or both scripts including code from a
third file.  A debian/rules target (or two) can avoid all of these issues.

On Thu, Mar 12, 2009 at 10:31:07AM -0500, Manoj Srivastava wrote:

 To recap:
  1) apt-get source is enough to get the latest Debian source from the
 archive (and whet for older sources)
  2) In the absence of munging, uscan, with a watch and watch-current
 files, is adequate to get either the latest or a specific version
 from upstream
  3) It is reasonable to get the latest, or a specific version, from
 upstream, and munge it.

 So, for case 3: get-orig-source has been defined to get the
  latest sources (with munging, if needed). If we want to get a specific
  version, we can:
   a. over-load get-orig-source to take a version number, some how,
  through an env variable, perhaps
   b. create a brand new target, which looks at the env variable, and
  falls back to the version in the changelog.

 I think case a is harder from a policy creation perspective,
  since it should not outlaw currently conforming implementations. The
  new target method can be deployed, tested in the wild, and then made
  into policy when the kinks have been ironed out.

I think it might be instructive to find out how many packages in the archive
actually have conformant get-orig-source targets.  If the number is small, a

Accepted hesiod 3.0.2-19 (source i386)

2009-03-12 Thread Karl Ramm

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 12 Mar 2009 01:08:20 -0400
Source: hesiod
Binary: hesiod libhesiod0 libhesiod-dev
Architecture: source i386
Version: 3.0.2-19
Distribution: unstable
Urgency: low
Maintainer: Karl Ramm k...@debian.org
Changed-By: Karl Ramm k...@debian.org
Description: 
 hesiod - Project Athena's DNS-based directory service - utilities
 libhesiod-dev - Project Athena's DNS-based directory service - development 
files
 libhesiod0 - Project Athena's DNS-based directory service - libraries
Closes: 321530 394024 394066 396429 396715 398575 404411 412660 420364 426175 
427051 435876 439696 452495 453298 453329 453375 453375 453649 454644 454696 
41 41 455966 456361 456361 456406 456510 468304 470930 492065 512866
Changes: 
 hesiod (3.0.2-19) unstable; urgency=low
 .
   * Acknowledge NMUs.
   * Only fiddle with hesiod.conf at the configuration stage.  Closes: #435876
   * Set the debconf priority for rhs to low; Closes: #321530
 Automatically deal with perhaps the one case ever where the obvious
 default is wrong.
   * JA debconf translation, thanks to Hideki Yamane.  Closes: #512866
 .
 hesiod (3.0.2-18.3) unstable; urgency=low
 .
   * Non-maintainer upload.
   * Fix pending l10n issues. Debconf translations:
 - Swedish. Closes: #492065
 .
 hesiod (3.0.2-18.2) unstable; urgency=low
 .
   * Non-maintainer upload to fix longstanding l10n issues
   * Debconf templates and debian/control reviewed by the debian-l10n-
 english team as part of the Smith review project. Closes: #452495
   * [Debconf translation updates]
 - Basque. Closes: #453298
 - Galician. Closes: #453329, #412660
 - Vietnamese. Closes: #453375
 - Finnish. Closes: #453649
 - Italian. Closes: #454644
 - French. Closes: #454696
 - Czech. Closes: #41
 - Russian. Closes: #455966
 - Portuguese. Closes: #456361, #420364, #439696
 - Norwegian Bokmål. Closes: #456406
 - Portuguese. Closes: #456361
 - Italian. Closes: #456510
 - Vietnamese. Closes: #453375, #427051
 - Czech. Closes: #41
 - Spanish. Closes: #426175
 - Dutch. Closes: #468304
 - Brazilian Portuguese. Closes: #470930
   * [Lintian] Set debhelper compatibility in debian/compat
   * [Lintian] No longer ignoer errors from make distclean
   * [Lintian] Move libhesiod-dev to libdevel section
 .
 hesiod (3.0.2-18.1) unstable; urgency=low
 .
   * Non-maintainer upload to fix longstanding l10n issues
   * Debconf templates translations updates:
 - Portuguese. Closes: #394024
 - French. Closes: #394066
 - German. Closes: #396429
 - Czech. Closes: #396715
 - Basque. Closes: #398575
 - Russian. Closes: #404411
Checksums-Sha1: 
 e283a0872b81669699f6a194b60529c674743a7e 1603 hesiod_3.0.2-19.dsc
 7d8bdd49dc033634fc5a74fc99870fd119d8e65f 121967 hesiod_3.0.2-19.diff.gz
 d4fa6bd67b2c54ebf011b8bbd574872dca16cda9 5538 hesiod_3.0.2-19_i386.deb
 101704305926e0734ecfab73c9a8c1c633e59deb 22804 libhesiod0_3.0.2-19_i386.deb
 491b4193cef6931f06c72d35efad60d8bbf649bb 14628 libhesiod-dev_3.0.2-19_i386.deb
Checksums-Sha256: 
 7f147889a5138c5ecfe4b92725fa9f00d1b9456853b0ae21250515d83ce36da7 1603 
hesiod_3.0.2-19.dsc
 9c4dd9be6c4739ed2a4f5c8c7e8faca5e47c1a4d117075120700ab9ada0eeed2 121967 
hesiod_3.0.2-19.diff.gz
 728599fc4da8fc56066c1bda976dc36588fb2803ec237f146c835f8ae5ef5c99 5538 
hesiod_3.0.2-19_i386.deb
 3453dcb6acd103fcafdbd95f073b00441e7d111af83adb7077df6acb857a7fb3 22804 
libhesiod0_3.0.2-19_i386.deb
 6fcec8f88deb91c1ee47cd7a4c4e1fb1df048e1ddb0cfcb841d4737200c4e4ed 14628 
libhesiod-dev_3.0.2-19_i386.deb
Files: 
 67461a2fc3a91b2ec8663fa97fd7aca6 1603 libs extra hesiod_3.0.2-19.dsc
 3a7fdbad4581d2f07fd4cc4e6dcc4caf 121967 libs extra hesiod_3.0.2-19.diff.gz
 8a8c5cd7fb12d27e8a5fc712c2cb9039 5538 utils extra hesiod_3.0.2-19_i386.deb
 d2da3a865a1b061b8f12d355fd281509 22804 libs extra libhesiod0_3.0.2-19_i386.deb
 0952aa3d501ee1cf4f6ed68927b96b07 14628 libdevel extra 
libhesiod-dev_3.0.2-19_i386.deb

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

iQIcBAEBAgAGBQJJuKH6AAoJELItdz86KScoFrwP/1YGILNNlERJUc2DyL7VkTuB
lnSyjm5iQREpT3B2ikgMxdLR+iNLIBfOf1cOW8Q+Z01IrwIrWV3cG5v6Vsgv6OVV
XTxvaE6MP5rjPbxtNrw1badwnIkgIsPLm7ur2cMxPLgoxtiuttjAdCpQdHtB+bf9
WxYyi1LQ0aKs802wFnNPcRQWWp8FJfB/sBaITx9Fx0KhhpJdmd1rSwzR22jeYMhx
vjf1Pna5HwC5rdafarLPhVFcxcgqHjIHhmj/cXDPtnA29ic1+CWWL1kcWPae+wcB
gbvBnx2TQL345qkEmUTu+EqI/ed/OVG46TWENylRCHZkDOg415ND3tq340vmskh3
L5fam8V6lcLIUJrLypEyuGk0p2O+LlWnTiEJaYMtHgBnAgSDLeN8Sii9GNsh04Ba
sEV8SZd42vOowgwQZdm0v7R9CBd379HYJMCaCcFkQp/3ELqALw49dFIxFB2YBC/H
V6UV7sA/2g+Lxw5MhILXj7A+wyqXN9s8M8G/CpgB+8xLUeI8/LwOmlTkQXgcWVGV
Wm7QeVRDufUwtc/844NCWshQuWHALz+MzE3R5cjdDojH6E+RiaCbzoDXNFTMnyY2
/9cmkvB02FxsGBOj2fGZlo0NzY5OSBjmtzoLQd1CnkNen09vOWzfWc9sRdDs9Szq
FQU8XKoRFtDVIkCfd+aU
=WD67
-END PGP SIGNATURE-


Accepted:
hesiod_3.0.2-19.diff.gz
  to pool/main/h/hesiod/hesiod_3.0.2-19.diff.gz
hesiod_3.0.2-19.dsc
  to

Accepted writer2latex 0.5.0.2-3 (source all)

2009-03-12 Thread Rene Engelhard

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 03 Mar 2009 02:46:26 +0100
Source: writer2latex
Binary: writer2latex writer2latex-manual libwriter2latex-java-doc 
libwriter2latex-java openoffice.org-writer2latex openoffice.org-writer2xhtml
Architecture: source all
Version: 0.5.0.2-3
Distribution: unstable
Urgency: high
Maintainer: Debian OpenOffice Team debian-openoff...@lists.debian.org
Changed-By: Rene Engelhard r...@debian.org
Description: 
 libwriter2latex-java - OpenOffice.org Writer/Calc to LaTeX/XHTML converter -- 
library
 libwriter2latex-java-doc - OpenOffice.org Writer/Calc to LaTeX/XHTML converter 
-- javadoc
 openoffice.org-writer2latex - Writer/Calc to LaTeX converter extension for 
OpenOffice.org
 openoffice.org-writer2xhtml - Writer/Calc to XHTML converter extension for 
OpenOffice.org
 writer2latex - OpenOffice.org Writer/Calc to LaTeX/XHTML converter
 writer2latex-manual - OpenOffice.org Writer/Calc to LaTeX/XHTML converter -- 
manual
Changes: 
 writer2latex (0.5.0.2-3) unstable; urgency=high
 .
   * $ORIGIN - $OOO_BASE_DIR
Checksums-Sha1: 
 09374e592468edf031cadefd61d91d92fb0c64b5 1374 writer2latex_0.5.0.2-3.dsc
 26ec0a6198791eeae9da870073cf5d1cd172f740 5594 writer2latex_0.5.0.2-3.diff.gz
 e6cfc45d3c3c35a1eee665937b8e5f852c70dea3 65548 writer2latex_0.5.0.2-3_all.deb
 f7f783145f17308b83b15be0cc645cf1ac0eefbf 660682 
writer2latex-manual_0.5.0.2-3_all.deb
 4012e4121ae92a16e99ab8c1b394e24047525f3c 293330 
libwriter2latex-java-doc_0.5.0.2-3_all.deb
 246f1b49234d7d92aa1f00d96353247690a3985e 365630 
libwriter2latex-java_0.5.0.2-3_all.deb
 2bdd62fb631a6e4d5fa23befd85f1e5578a9f454 382120 
openoffice.org-writer2latex_0.5.0.2-3_all.deb
 b72f18cc069de70b12b04fad82e45a43e071237a 381758 
openoffice.org-writer2xhtml_0.5.0.2-3_all.deb
Checksums-Sha256: 
 f4ea0d36f1708293e9c66a53d0c823eab187804902cc01f7b7f2c66c50ee0722 1374 
writer2latex_0.5.0.2-3.dsc
 e8ceeae92237ec16d6cd90e802f3f5c3f76d86f366d5ea9096ae58d7fea41e21 5594 
writer2latex_0.5.0.2-3.diff.gz
 b2ac0f80d8633e5d0309659ad096d2b6d7c2f26adc7d652559ef63d0539f027a 65548 
writer2latex_0.5.0.2-3_all.deb
 2096b7a70da0e39df987952c24efb90942af54eb91108d44fed1f5020a50780a 660682 
writer2latex-manual_0.5.0.2-3_all.deb
 b54669776a2893d3f124de4d98a79b252e04fab71f5b337c6b51fcf8538699a5 293330 
libwriter2latex-java-doc_0.5.0.2-3_all.deb
 d7c7559b6a3666034d0b88f6a03281df83ec056c8cd7c0d39d0a000bf3fb4fc2 365630 
libwriter2latex-java_0.5.0.2-3_all.deb
 0fdc5beef317dc79bcde81f874d91e0f371bf2de1154bf9bbe763650cf78af95 382120 
openoffice.org-writer2latex_0.5.0.2-3_all.deb
 8106ab237df35c68f204c0d82c98c4dd5894bab7ec905545904b6eaa0d976860 381758 
openoffice.org-writer2xhtml_0.5.0.2-3_all.deb
Files: 
 70828359283273c677c417c34e053089 1374 text optional writer2latex_0.5.0.2-3.dsc
 294bbcc9b0807f8d4cfbec5b7bf0a3d7 5594 text optional 
writer2latex_0.5.0.2-3.diff.gz
 de92ffedf8265edc146a7ba10196c863 65548 text optional 
writer2latex_0.5.0.2-3_all.deb
 58dada2013c4784989fe7db9eee281de 660682 doc optional 
writer2latex-manual_0.5.0.2-3_all.deb
 017d42e03cf9c78fd71d00f0b66d5474 293330 doc optional 
libwriter2latex-java-doc_0.5.0.2-3_all.deb
 0f7d6cd915c0a799863157d96cf8bfdd 365630 text optional 
libwriter2latex-java_0.5.0.2-3_all.deb
 c2b9e8eacf1c2ce87a520dc14a3be1d0 382120 text optional 
openoffice.org-writer2latex_0.5.0.2-3_all.deb
 41d7a1d80a7ed3f40f96c08ffea40ce2 381758 text optional 
openoffice.org-writer2xhtml_0.5.0.2-3_all.deb

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

iD8DBQFJuLvx+FmQsCSK63MRAgu9AJ96WXPHgfLHWCUgDqFOLaoTOX7cCwCdEDer
OKwT2/UdTSlevlfcql0n+ow=
=S+FH
-END PGP SIGNATURE-


Accepted:
libwriter2latex-java-doc_0.5.0.2-3_all.deb
  to pool/main/w/writer2latex/libwriter2latex-java-doc_0.5.0.2-3_all.deb
libwriter2latex-java_0.5.0.2-3_all.deb
  to pool/main/w/writer2latex/libwriter2latex-java_0.5.0.2-3_all.deb
openoffice.org-writer2latex_0.5.0.2-3_all.deb
  to pool/main/w/writer2latex/openoffice.org-writer2latex_0.5.0.2-3_all.deb
openoffice.org-writer2xhtml_0.5.0.2-3_all.deb
  to pool/main/w/writer2latex/openoffice.org-writer2xhtml_0.5.0.2-3_all.deb
writer2latex-manual_0.5.0.2-3_all.deb
  to pool/main/w/writer2latex/writer2latex-manual_0.5.0.2-3_all.deb
writer2latex_0.5.0.2-3.diff.gz
  to pool/main/w/writer2latex/writer2latex_0.5.0.2-3.diff.gz
writer2latex_0.5.0.2-3.dsc
  to pool/main/w/writer2latex/writer2latex_0.5.0.2-3.dsc
writer2latex_0.5.0.2-3_all.deb
  to pool/main/w/writer2latex/writer2latex_0.5.0.2-3_all.deb


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

Accepted ooo-build-extensions 3.0.0.9+r14588-3 (source all)

2009-03-12 Thread Rene Engelhard

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 03 Mar 2009 08:40:56 +0100
Source: ooo-build-extensions
Binary: openoffice.org-coooder
Architecture: source all
Version: 3.0.0.9+r14588-3
Distribution: unstable
Urgency: low
Maintainer: Debian OpenOffice Team debian-openoff...@lists.debian.org
Changed-By: Rene Engelhard r...@debian.org
Description: 
 openoffice.org-coooder - syntax highlighting extension for OpenOffice.org
Changes: 
 ooo-build-extensions (3.0.0.9+r14588-3) unstable; urgency=low
 .
   * $ORIGIN - $OOO_BASE_DIR
   * fix FTBFS (specify regmerge path)
Checksums-Sha1: 
 e359a3963698d1c8d48310eca8f6ab808ac50d90 1268 
ooo-build-extensions_3.0.0.9+r14588-3.dsc
 d2eadc0358bd1d9e9345c6fe466bfec16b217828 3963 
ooo-build-extensions_3.0.0.9+r14588-3.diff.gz
 69da32c71680d7649e24f73c9d5bc4fd1fd72791 384338 
openoffice.org-coooder_1.1.1+ooo-build3.0.0.9+r14588-3_all.deb
Checksums-Sha256: 
 8ad0f705b52f6a55d231ed6b781b2af5bf7050c335d293cbf26e6f5d2a58b4df 1268 
ooo-build-extensions_3.0.0.9+r14588-3.dsc
 dcdd597c2b1f4794e436ab178d1a473c4458e22de605bafc75a03c56fc8e0d9f 3963 
ooo-build-extensions_3.0.0.9+r14588-3.diff.gz
 e95ac53c42c82fa88137e5f998f984b7fa80c462f80c0349f7007d40ad6662b2 384338 
openoffice.org-coooder_1.1.1+ooo-build3.0.0.9+r14588-3_all.deb
Files: 
 2184157c5a38e8be6dec8d58ae309e13 1268 misc optional 
ooo-build-extensions_3.0.0.9+r14588-3.dsc
 2ce11e6011fb4ab8ade54a2a66f14a3d 3963 misc optional 
ooo-build-extensions_3.0.0.9+r14588-3.diff.gz
 22c0f56330292490f0ed27f68c7c9ae5 384338 misc optional 
openoffice.org-coooder_1.1.1+ooo-build3.0.0.9+r14588-3_all.deb

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

iD8DBQFJuLv6+FmQsCSK63MRAphSAJ42cstzLom4WiwAS0RyWvP57+Hw/ACeNL7E
I0lxRmWUu2YwAuZVz2tJQUo=
=4xy/
-END PGP SIGNATURE-


Accepted:
ooo-build-extensions_3.0.0.9+r14588-3.diff.gz
  to 
pool/main/o/ooo-build-extensions/ooo-build-extensions_3.0.0.9+r14588-3.diff.gz
ooo-build-extensions_3.0.0.9+r14588-3.dsc
  to pool/main/o/ooo-build-extensions/ooo-build-extensions_3.0.0.9+r14588-3.dsc
openoffice.org-coooder_1.1.1+ooo-build3.0.0.9+r14588-3_all.deb
  to 
pool/main/o/ooo-build-extensions/openoffice.org-coooder_1.1.1+ooo-build3.0.0.9+r14588-3_all.deb


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

Accepted citadel 7.42-1 (source all amd64)

2009-03-12 Thread Michael Meskes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 23 Feb 2009 10:16:39 +0100
Source: citadel
Binary: citadel-server citadel-suite citadel-common citadel-mta citadel-client 
citadel-doc
Architecture: source amd64 all
Version: 7.42-1
Distribution: unstable
Urgency: low
Maintainer: Debian Citadel Team pkg-citadel-de...@lists.alioth.debian.org
Changed-By: Michael Meskes mes...@debian.org
Description: 
 citadel-client - complete and feature-rich groupware server (command line 
client)
 citadel-common - complete and feature-rich groupware server
 citadel-doc - complete and feature-rich groupware server (documentation)
 citadel-mta - complete and feature-rich groupware server (mail transport agent)
 citadel-server - complete and feature-rich groupware server
 citadel-suite - complete and feature-rich groupware server; metapackage for 
full 
Closes: 516853 518216 518272 518317 518323 518658 518990 519302
Changes: 
 citadel (7.42-1) unstable; urgency=low
 .
   * New upstream version.
   * Removed config files generated by citadel, closes: #516853
   * Updated Portuguese debconf translation, closes: #518216
   * Updated French debconf translation, closes: #518317
   * Updated Vietnamese debconf translation, closes: #518272
   * Updated Swedish debconf translation, closes: #518323
   * Updated Finish debconf translation, closes: #518658
   * Updated Czech debconf translation, closes: #518990
   * Updated Russian debconf translation, closes: #519302
Checksums-Sha1: 
 0354391a4cc60900e6f20ec2373ec94844d8f3e9 1382 citadel_7.42-1.dsc
 a92a63121b19c528f61d101320b8af2ede072152 809545 citadel_7.42.orig.tar.gz
 fc704ee161da02beed4aff9c8fa80d10eeabe1d1 26785 citadel_7.42-1.diff.gz
 3d2b4c2fbaaace4f1c1ed0c2e85c0fcddc420107 371848 citadel-server_7.42-1_amd64.deb
 16ba1cd44f594689aa16752d7ae92058e38b3d1e 17596 citadel-mta_7.42-1_amd64.deb
 980939bd3d40f50434edd0d4c6286e0b40d7f8ee 127622 citadel-client_7.42-1_amd64.deb
 489300b78e2bf304f0bd6a29838f521311cebb54 8936 citadel-suite_7.42-1_all.deb
 a6e3398369f1e06107a4fa6944e9aa039bf613e2 9078 citadel-common_7.42-1_all.deb
 6640fc7ee1e959b5035c5cebe2f06f3e3cb24694 97206 citadel-doc_7.42-1_all.deb
Checksums-Sha256: 
 81559a033e5f9a703edb65ab7c2201140fa71fa5af7ab20263cc4b60856f7a48 1382 
citadel_7.42-1.dsc
 6cee31a25d613c31ffb0d898b77adee3ff67180d0075445afbbc644ca1c496dc 809545 
citadel_7.42.orig.tar.gz
 3fb4396422a67ef2ff2a631b3c84386b58bd4fc990b52e0fc5fbb206d5663034 26785 
citadel_7.42-1.diff.gz
 d62d7173af206b2991ead34601d3864aff43df25c3232cfa8410e9c1d6e7791c 371848 
citadel-server_7.42-1_amd64.deb
 10c2f6aa32eef1c8e58e0353ebbc2778eb2c38fed70edbc4a5787c538bbb7048 17596 
citadel-mta_7.42-1_amd64.deb
 b0ae54c1455690de6346d45d127d627252ed5d010991f2d70e6f819a59ddb457 127622 
citadel-client_7.42-1_amd64.deb
 2f84f6f2216ed7b36ece3cbb487872738fb7ad1d1cc211222a3bf76f84fabb64 8936 
citadel-suite_7.42-1_all.deb
 fc8fd5d6afbad674dea3a894d79034ff2023fb9ea0910819eb7253feced3 9078 
citadel-common_7.42-1_all.deb
 6c8d552e453c3e432d76c7140d2d02ed1c8dde76793d5202ff4baffd534bb523 97206 
citadel-doc_7.42-1_all.deb
Files: 
 c340b8c3ff117e7781b3323896b9fcdc 1382 mail extra citadel_7.42-1.dsc
 e272adad20218737c1bd5fa746f042f1 809545 mail extra citadel_7.42.orig.tar.gz
 705f33097b8212ba7094186f975996d8 26785 mail extra citadel_7.42-1.diff.gz
 8d2fd2e217f889c12a696b79e2659c57 371848 mail extra 
citadel-server_7.42-1_amd64.deb
 b1571bdc9a9e418e6596f909c0ec8f17 17596 mail extra citadel-mta_7.42-1_amd64.deb
 89e6ed24961f09f4fca7f1fdc0203b8c 127622 mail extra 
citadel-client_7.42-1_amd64.deb
 a2822e2a3e0066f3527d6478e014fb5a 8936 mail extra citadel-suite_7.42-1_all.deb
 c43d0eba487000ecaf75b11cfa6bf08a 9078 mail extra citadel-common_7.42-1_all.deb
 2bf4cfd2bfb4114c29be4560fdd6b942 97206 doc extra citadel-doc_7.42-1_all.deb

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

iD8DBQFJuMvCVkEm8inxm9ERAplFAJ4qUSYzeWvFwMCtWXi87ETVuG84BwCfVyCI
RbxXZcfCF15yKQdAJqzekL4=
=Wniz
-END PGP SIGNATURE-


Accepted:
citadel-client_7.42-1_amd64.deb
  to pool/main/c/citadel/citadel-client_7.42-1_amd64.deb
citadel-common_7.42-1_all.deb
  to pool/main/c/citadel/citadel-common_7.42-1_all.deb
citadel-doc_7.42-1_all.deb
  to pool/main/c/citadel/citadel-doc_7.42-1_all.deb
citadel-mta_7.42-1_amd64.deb
  to pool/main/c/citadel/citadel-mta_7.42-1_amd64.deb
citadel-server_7.42-1_amd64.deb
  to pool/main/c/citadel/citadel-server_7.42-1_amd64.deb
citadel-suite_7.42-1_all.deb
  to pool/main/c/citadel/citadel-suite_7.42-1_all.deb
citadel_7.42-1.diff.gz
  to pool/main/c/citadel/citadel_7.42-1.diff.gz
citadel_7.42-1.dsc
  to pool/main/c/citadel/citadel_7.42-1.dsc
citadel_7.42.orig.tar.gz
  to pool/main/c/citadel/citadel_7.42.orig.tar.gz


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

Accepted lustre 1.6.6-2 (source all i386)

2009-03-12 Thread Patrick Winnertz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 12 Mar 2009 08:36:44 +0100
Source: lustre
Binary: linux-patch-lustre lustre-source lustre-utils lustre-tests liblustre 
lustre-dev
Architecture: source all i386
Version: 1.6.6-2
Distribution: unstable
Urgency: low
Maintainer: Debian Lustre Packaging team 
pkg-lustre-maintain...@lists.alioth.debian.org
Changed-By: Patrick Winnertz win...@debian.org
Description: 
 liblustre  - Runtime library for Lustre filesystem utilities
 linux-patch-lustre - Linux kernel patch for the Lustre Filesystem
 lustre-dev - Development files for the Lustre filesystem
 lustre-source - source for Lustre filesystem client kernel modules
 lustre-tests - Test suite for the Lustre filesystem
 lustre-utils - Userspace utilities for the Lustre filesystem
Closes: 508078 514351
Changes: 
 lustre (1.6.6-2) unstable; urgency=low
 .
   * [7e86dbb] Add fiemap 2.6.18 patch from 1.6.5.1
   * [07ca9b0] Moved .populate = ll_populate (vm_operations_struct) into
 !HAVE_VM_OP_FAULT
   * [129dd3d] Move LPROCFS_ENTRY_WRITE and LPROCFS_ENTRY_EXIT out of
 #ifdef in lprocfs_status.h (Closes: #514351)
   * [5182d5a] Added configure check for blk_cleanup_queue which replaced
 blk_put_queue in 2.6.25-rc4 (Closes: 508078)
   * [82b2128] Bumped build-dep on debhelper to 6.0.7 as we're using
 dh_lintian which is available in the toolchain since 6.07.
Checksums-Sha1: 
 0aa222041b2d3c81356c84bbf3253e4686a6284f 1476 lustre_1.6.6-2.dsc
 68ba68cc91b5dd00f11f8797b4ccc82954934676 4789509 lustre_1.6.6.orig.tar.gz
 0ae9215d4a8b9bacddc7c949807e822add754ab6 91083 lustre_1.6.6-2.diff.gz
 ac23aa2ae646c7b10c0444310beb78d3c2b342b1 471810 
linux-patch-lustre_1.6.6-2_all.deb
 c9705a5adf2ff2ae56ed1c8eba29027d0b7ca4c9 3308556 lustre-source_1.6.6-2_all.deb
 bac157476680cca8a6486bbadd69b0e09e197489 578030 lustre-utils_1.6.6-2_i386.deb
 18a77547f98bff0ea86309da2e5336c902970b7b 393336 lustre-tests_1.6.6-2_i386.deb
 755a26e12eaf817a3ba36ec9fae495af954de472 4619554 lustre-dev_1.6.6-2_i386.deb
 9d56298b9b3cf1c0d4fe722fc633ebe6a88d985c 681536 liblustre_1.6.6-2_i386.deb
Checksums-Sha256: 
 2ab89233951f58b50342f7c851d6e52ae5cec64db4d9fbc0e11849f80fa8b094 1476 
lustre_1.6.6-2.dsc
 a31507f905b3b5bff43f8821436d39dd431ab34aafc13add7a1f5ca2691c7c3a 4789509 
lustre_1.6.6.orig.tar.gz
 d2eeab85828a415afd2eb8ef84e88537aec690c1bef642cfaa248f88ee5bb3ad 91083 
lustre_1.6.6-2.diff.gz
 39894f9f8aa6030d8922d8f90e1d2ca5c7b5036d53b894bb97b304c0fdf53161 471810 
linux-patch-lustre_1.6.6-2_all.deb
 dc1ed8cecf94ffd9428d25dfe3157c8e912056e636f2ca3dd33a5a69ab4ce960 3308556 
lustre-source_1.6.6-2_all.deb
 de3a3c2860b475044f96392e4b17db69b53881a1676c22592f8c20e311d6444b 578030 
lustre-utils_1.6.6-2_i386.deb
 15ee1ef21931b77c2a562613ee443f620791dbe8acc21702d67c477d80ded435 393336 
lustre-tests_1.6.6-2_i386.deb
 d65e1729d4a39f33086e37dbc9ba50d06f374dea24ab7e5167e566061099d701 4619554 
lustre-dev_1.6.6-2_i386.deb
 9afc06b4032075aed026a78337b34178eeff56eac00c6a5e01a2d94a98cfd699 681536 
liblustre_1.6.6-2_i386.deb
Files: 
 ea9ed148261a11686faca178ecf14784 1476 admin optional lustre_1.6.6-2.dsc
 936fd7a2e0a6b59ccde5805c3c7c8f6c 4789509 admin optional 
lustre_1.6.6.orig.tar.gz
 684cdc42f14e860342ecfd3f671bfbaa 91083 admin optional lustre_1.6.6-2.diff.gz
 35978a7158c9e223fa4c7068b2943714 471810 devel optional 
linux-patch-lustre_1.6.6-2_all.deb
 37c1dde300372ac167b39e32644bc499 3308556 admin optional 
lustre-source_1.6.6-2_all.deb
 147828f64783dc332073ccce291bcfd8 578030 utils optional 
lustre-utils_1.6.6-2_i386.deb
 7960973c77b3ff5f286a49ad85f08b85 393336 admin optional 
lustre-tests_1.6.6-2_i386.deb
 157e571be02d81723240216fbab67f26 4619554 libdevel optional 
lustre-dev_1.6.6-2_i386.deb
 7bf38534ab9e4556034e2b6ae7ecdaed 681536 otherosfs optional 
liblustre_1.6.6-2_i386.deb

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

iEYEARECAAYFAkm4xF0ACgkQzgm26bkTFDoX2QCg1MmmxNqXetsx/qflp6gh+w2G
QtQAn0a3528mp+CqY4K+Q8H/fJte4tR2
=gYqz
-END PGP SIGNATURE-


Accepted:
liblustre_1.6.6-2_i386.deb
  to pool/main/l/lustre/liblustre_1.6.6-2_i386.deb
linux-patch-lustre_1.6.6-2_all.deb
  to pool/main/l/lustre/linux-patch-lustre_1.6.6-2_all.deb
lustre-dev_1.6.6-2_i386.deb
  to pool/main/l/lustre/lustre-dev_1.6.6-2_i386.deb
lustre-source_1.6.6-2_all.deb
  to pool/main/l/lustre/lustre-source_1.6.6-2_all.deb
lustre-tests_1.6.6-2_i386.deb
  to pool/main/l/lustre/lustre-tests_1.6.6-2_i386.deb
lustre-utils_1.6.6-2_i386.deb
  to pool/main/l/lustre/lustre-utils_1.6.6-2_i386.deb
lustre_1.6.6-2.diff.gz
  to pool/main/l/lustre/lustre_1.6.6-2.diff.gz
lustre_1.6.6-2.dsc
  to pool/main/l/lustre/lustre_1.6.6-2.dsc


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

Accepted webcit 7.42-dfsg-1 (source amd64)

2009-03-12 Thread Michael Meskes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 03 Mar 2009 12:44:02 +0100
Source: webcit
Binary: citadel-webcit
Architecture: source amd64
Version: 7.42-dfsg-1
Distribution: unstable
Urgency: high
Maintainer: Debian Citadel Team pkg-citadel-de...@lists.alioth.debian.org
Changed-By: Michael Meskes mes...@debian.org
Description: 
 citadel-webcit - web-based frontend to Citadel groupware server
Closes: 51273 517579 518328 518663 518918 518991 519176 519303
Changes: 
 webcit (7.42-dfsg-1) unstable; urgency=high
 .
   * New upstream version, closes: #517579
   * Updated versioned dependencies.
   * We have to keep urgency high because 7.38b-dfsg-2 didn't migrate to
 testing.
   * Changed watch file to account for an additional letter in the version
 number if present.
   * Create static.local directory under /var/lib/citadel-webcit for local
 installation of themes etc.
   * Reworked debconf setup.
   * Improved debconf template by incorporating ideas from Christian Perrier
 bubu...@debian.org.
   * Updated Vietnamese debconf translation, closes: #51273
   * Updated Swedish debconf translation, closes: #518328
   * Updated Finish debconf translation, closes: #518663
   * Updated French debconf translation, closes: #518918
   * Updated Czech debconf translation, closes: #518991
   * Updated Italian debconf translation, closes: #519176
   * Updated Russian debconf translation, closes: #519303
Checksums-Sha1: 
 f6cd7efec1a4198256f2e675646beaf2adac9ef6 1253 webcit_7.42-dfsg-1.dsc
 b6bc33e9c561aee0f61b3bc560231ed43f401f44 1714061 webcit_7.42-dfsg.orig.tar.gz
 a9c0f191ca8a6bc306cd702893488179fc61a854 17846 webcit_7.42-dfsg-1.diff.gz
 ea4a7dea045bf2f150827e15d12efc9e9b13983d 642148 
citadel-webcit_7.42-dfsg-1_amd64.deb
Checksums-Sha256: 
 d7be99f9b79f6b7fbfd5772dd6facd434a486bf958ff774e57eb9ea23e22b1cc 1253 
webcit_7.42-dfsg-1.dsc
 eb43294f3fcad2472f8c658740c6badac0496650be3fee979dc237ba84392f3f 1714061 
webcit_7.42-dfsg.orig.tar.gz
 5a5688c67e893a99a5a521ded36eab5fbfdd48b50cc95837993e98edc3a3ac31 17846 
webcit_7.42-dfsg-1.diff.gz
 ae4aea7f188570e47ee31b880a97ffd10b047fbf6d324f2b7a16385497634bf3 642148 
citadel-webcit_7.42-dfsg-1_amd64.deb
Files: 
 037320b4c0f30d3a1b4486e13409d9be 1253 web extra webcit_7.42-dfsg-1.dsc
 3fdc8ac9f7ea32cc23baa95e20a6f76c 1714061 web extra webcit_7.42-dfsg.orig.tar.gz
 767e54130d59a7de9064423a86343381 17846 web extra webcit_7.42-dfsg-1.diff.gz
 75b5648a63283bc9c290f7d4d7b586fa 642148 web extra 
citadel-webcit_7.42-dfsg-1_amd64.deb

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

iD8DBQFJuMq7VkEm8inxm9ERArktAJ9TtPz2o96QqFXP6TVoEVZ3AFhSJwCcCxN+
ckdbLu228/DGhchN9op2QvE=
=Won1
-END PGP SIGNATURE-


Accepted:
citadel-webcit_7.42-dfsg-1_amd64.deb
  to pool/main/w/webcit/citadel-webcit_7.42-dfsg-1_amd64.deb
webcit_7.42-dfsg-1.diff.gz
  to pool/main/w/webcit/webcit_7.42-dfsg-1.diff.gz
webcit_7.42-dfsg-1.dsc
  to pool/main/w/webcit/webcit_7.42-dfsg-1.dsc
webcit_7.42-dfsg.orig.tar.gz
  to pool/main/w/webcit/webcit_7.42-dfsg.orig.tar.gz


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

Accepted glibc 2.9-5 (source all amd64)

2009-03-12 Thread Aurelien Jarno

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 12 Mar 2009 00:13:02 +0100
Source: glibc
Binary: glibc-doc glibc-source locales locales-all nscd libc6 libc6-dev 
libc6-dbg libc6-prof libc6-pic libc6-udeb libc6.1 libc6.1-dev libc6.1-dbg 
libc6.1-prof libc6.1-pic libc6.1-udeb libc0.3 libc0.3-dev libc0.3-dbg 
libc0.3-prof libc0.3-pic libc0.3-udeb libc0.1 libc0.1-dev libc0.1-dbg 
libc0.1-prof libc0.1-pic libc0.1-udeb libc6-i386 libc6-dev-i386 libc6-sparc64 
libc6-dev-sparc64 libc6-s390x libc6-dev-s390x libc6-amd64 libc6-dev-amd64 
libc6-powerpc libc6-dev-powerpc libc6-ppc64 libc6-dev-ppc64 libc6-mipsn32 
libc6-dev-mipsn32 libc6-mips64 libc6-dev-mips64 libc0.1-i386 libc0.1-dev-i386 
libc6-sparcv9b libc6-i686 libc6-xen libc0.1-i686 libc6.1-alphaev67 
libnss-dns-udeb libnss-files-udeb
Architecture: source all amd64
Version: 2.9-5
Distribution: unstable
Urgency: low
Maintainer: Aurelien Jarno aure...@debian.org
Changed-By: Aurelien Jarno aure...@debian.org
Description: 
 glibc-doc  - GNU C Library: Documentation
 glibc-source - GNU C Library: sources
 libc0.1- GNU C Library: Shared libraries
 libc0.1-dbg - GNU C Library: detached debugging symbols
 libc0.1-dev - GNU C Library: Development Libraries and Header Files
 libc0.1-dev-i386 - GNU C Library: 32bit development libraries for AMD64
 libc0.1-i386 - GNU C Library: 32bit shared libraries for AMD64
 libc0.1-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc0.1-pic - GNU C Library: PIC archive library
 libc0.1-prof - GNU C Library: Profiling Libraries
 libc0.1-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libc0.3- GNU C Library: Shared libraries
 libc0.3-dbg - GNU C Library: detached debugging symbols
 libc0.3-dev - GNU C Library: Development Libraries and Header Files
 libc0.3-pic - GNU C Library: PIC archive library
 libc0.3-prof - GNU C Library: Profiling Libraries
 libc0.3-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libc6  - GNU C Library: Shared libraries
 libc6-amd64 - GNU C Library: 64bit Shared libraries for AMD64
 libc6-dbg  - GNU C Library: detached debugging symbols
 libc6-dev  - GNU C Library: Development Libraries and Header Files
 libc6-dev-amd64 - GNU C Library: 64bit Development Libraries for AMD64
 libc6-dev-i386 - GNU C Library: 32bit development libraries for AMD64
 libc6-dev-mips64 - GNU C Library: 64bit Development Libraries for MIPS64
 libc6-dev-mipsn32 - GNU C Library: n32 Development Libraries for MIPS64
 libc6-dev-powerpc - GNU C Library: 32bit powerpc development libraries for 
ppc64
 libc6-dev-ppc64 - GNU C Library: 64bit Development Libraries for PowerPC64
 libc6-dev-s390x - GNU C Library: 64bit Development Libraries for IBM zSeries
 libc6-dev-sparc64 - GNU C Library: 64bit Development Libraries for UltraSPARC
 libc6-i386 - GNU C Library: 32bit shared libraries for AMD64
 libc6-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc6-mips64 - GNU C Library: 64bit Shared libraries for MIPS64
 libc6-mipsn32 - GNU C Library: n32 Shared libraries for MIPS64
 libc6-pic  - GNU C Library: PIC archive library
 libc6-powerpc - GNU C Library: 32bit powerpc shared libraries for ppc64
 libc6-ppc64 - GNU C Library: 64bit Shared libraries for PowerPC64
 libc6-prof - GNU C Library: Profiling Libraries
 libc6-s390x - GNU C Library: 64bit Shared libraries for IBM zSeries
 libc6-sparc64 - GNU C Library: 64bit Shared libraries for UltraSPARC
 libc6-sparcv9b - GNU C Library: Shared libraries [v9b optimized]
 libc6-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libc6-xen  - GNU C Library: Shared libraries [Xen version]
 libc6.1- GNU C Library: Shared libraries
 libc6.1-alphaev67 - GNU C Library: Shared libraries (EV67 optimized)
 libc6.1-dbg - GNU C Library: detached debugging symbols
 libc6.1-dev - GNU C Library: Development Libraries and Header Files
 libc6.1-pic - GNU C Library: PIC archive library
 libc6.1-prof - GNU C Library: Profiling Libraries
 libc6.1-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libnss-dns-udeb - GNU C Library: NSS helper for DNS - udeb (udeb)
 libnss-files-udeb - GNU C Library: NSS helper for files - udeb (udeb)
 locales- GNU C Library: National Language (locale) data [support]
 locales-all - GNU C Library: Precompiled locale data
 nscd   - GNU C Library: Name Service Cache Daemon
Closes: 172123 517386 517795 517884 518394
Changes: 
 glibc (2.9-5) unstable; urgency=low
 .
   [ Clint Adams ]
   * Change first day of the week in ru_UA locale to Monday.  closes:
 #517386.
 .
   [ Aurelien Jarno ]
   * testsuite-checking/expected-results-i486-linux-gnu-libc,
 testsuite-checking/expected-results-i686-linux-i686: remove
 testgrp.out from the ignore list, it was due to a misconfiguration
 of the build daemon.
   * debhelper.in/libc.{preinst,postint}: bump the version triggering the
 restart of NSS related services to 2.9-5.
   * debhelper.in/libc.postint: change cupsys into cups.
   * script.in/nsscheck.sh: convert

Accepted libcatalyst-manual-perl 5.7019-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 12 Mar 2009 10:16:06 +0100
Source: libcatalyst-manual-perl
Binary: libcatalyst-manual-perl
Architecture: source all
Version: 5.7019-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: Krzysztof Krzyżaniak (eloy) e...@debian.org
Description: 
 libcatalyst-manual-perl - The Catalyst developer's manual
Changes: 
 libcatalyst-manual-perl (5.7019-1) unstable; urgency=low
 .
   * New upstream release
   * debian/control: Standards-Version updated to 3.8.1 (no changes)
Checksums-Sha1: 
 e0deaa83cb50ed4036e9896058e51e3315e89cb1 1414 
libcatalyst-manual-perl_5.7019-1.dsc
 b7dc584fb8bf7f03aaa549fad5ffe606f75b4d5c 159857 
libcatalyst-manual-perl_5.7019.orig.tar.gz
 f3f07ebec568df5d09448282ba916362840873b9 2572 
libcatalyst-manual-perl_5.7019-1.diff.gz
 0b879237527eb5ff2975fad4001aeaee97941153 345676 
libcatalyst-manual-perl_5.7019-1_all.deb
Checksums-Sha256: 
 3fdc6fd713fa7d1b077993510ffb344f2bb4561dc98f00449c6ddcf914d5416b 1414 
libcatalyst-manual-perl_5.7019-1.dsc
 e22641e4de9355aa2edd676ab1f6029952bf896e908927bfe43ec6daaa8c3aa7 159857 
libcatalyst-manual-perl_5.7019.orig.tar.gz
 33d8c8a178d534fb88909d661607a26d2cefa5f27bdc81a00a4485951c143bee 2572 
libcatalyst-manual-perl_5.7019-1.diff.gz
 cf7027951c57c5896c2689f75dea5a03b287c80d5d9b2625e8b67cb0ec54dd70 345676 
libcatalyst-manual-perl_5.7019-1_all.deb
Files: 
 bba037318231a7586a44482eae3a73eb 1414 non-free/perl optional 
libcatalyst-manual-perl_5.7019-1.dsc
 96c27af188fa888c3b6a1365f4e74ef0 159857 non-free/perl optional 
libcatalyst-manual-perl_5.7019.orig.tar.gz
 9c09c9a33320223ed1d9aa8c2027f353 2572 non-free/perl optional 
libcatalyst-manual-perl_5.7019-1.diff.gz
 8bf628a73b95f3db9f08374c5eb5c688 345676 non-free/perl optional 
libcatalyst-manual-perl_5.7019-1_all.deb

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

iEYEARECAAYFAkm41WkACgkQy+HP4f7iC8tjXwCghm0ACl2pVbmZ5O2vf8y6sH8g
ZpcAoID4SOSiomKX+SAn1OcU0aS4irXg
=VwS5
-END PGP SIGNATURE-


Accepted:
libcatalyst-manual-perl_5.7019-1.diff.gz
  to 
pool/non-free/libc/libcatalyst-manual-perl/libcatalyst-manual-perl_5.7019-1.diff.gz
libcatalyst-manual-perl_5.7019-1.dsc
  to 
pool/non-free/libc/libcatalyst-manual-perl/libcatalyst-manual-perl_5.7019-1.dsc
libcatalyst-manual-perl_5.7019-1_all.deb
  to 
pool/non-free/libc/libcatalyst-manual-perl/libcatalyst-manual-perl_5.7019-1_all.deb
libcatalyst-manual-perl_5.7019.orig.tar.gz
  to 
pool/non-free/libc/libcatalyst-manual-perl/libcatalyst-manual-perl_5.7019.orig.tar.gz


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

Accepted krank 0.7+dfsg1-8 (source all)

2009-03-12 Thread Dmitry E. Oboukhov

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 12 Mar 2009 10:32:28 +0300
Source: krank
Binary: krank
Architecture: source all
Version: 0.7+dfsg1-8
Distribution: unstable
Urgency: low
Maintainer: Dmitry E. Oboukhov un...@debian.org
Changed-By: Dmitry E. Oboukhov un...@debian.org
Description: 
 krank  - is a game of dexterity where you match stones together
Closes: 519279
Changes: 
 krank (0.7+dfsg1-8) unstable; urgency=low
 .
   * Fixed watch, closes: #519279.
   * imagemagik has been moved from Build-depends to Build-depends-indep.
Checksums-Sha1: 
 e43588aaa67d6ed8c37e8c5e0f096d6b088e1fa0 1177 krank_0.7+dfsg1-8.dsc
 91052bbedb72340b87ccba08d3fd52056deb68dc 7516 krank_0.7+dfsg1-8.diff.gz
 0ae3456ef70d42b7ec30b3e7dd2a4ca2c29fd0b8 59998388 krank_0.7+dfsg1-8_all.deb
Checksums-Sha256: 
 a57423aceb72d9f342dec4bed531e6c548fe56a193c79191f075fb231db899c3 1177 
krank_0.7+dfsg1-8.dsc
 060d9ef235f951884972283050ca035d0b3e6fdcbef654df08dc362281e67fa8 7516 
krank_0.7+dfsg1-8.diff.gz
 73d5877748e680f4a4bfab10209b2b967694e145274d9ce593c29cabbd5339a2 59998388 
krank_0.7+dfsg1-8_all.deb
Files: 
 e7e00c7e50f68731e642bf31138e03c4 1177 games extra krank_0.7+dfsg1-8.dsc
 6f11a36c37e9919f38684c44418dd980 7516 games extra krank_0.7+dfsg1-8.diff.gz
 c5b1504a139069c684ee44465afec8cf 59998388 games extra krank_0.7+dfsg1-8_all.deb

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

iEYEARECAAYFAkm4wNAACgkQq4wAz/jiZTdYSACfRpwlCJkE5aH0aRcI0GdyuFx1
e5UAniwyKUUT+cqKoww6eJXyg4umrI2d
=AGi5
-END PGP SIGNATURE-


Accepted:
krank_0.7+dfsg1-8.diff.gz
  to pool/main/k/krank/krank_0.7+dfsg1-8.diff.gz
krank_0.7+dfsg1-8.dsc
  to pool/main/k/krank/krank_0.7+dfsg1-8.dsc
krank_0.7+dfsg1-8_all.deb
  to pool/main/k/krank/krank_0.7+dfsg1-8_all.deb


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

Accepted libipc-sharelite-perl 0.17-1 (source i386)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 12 Mar 2009 10:36:48 +0100
Source: libipc-sharelite-perl
Binary: libipc-sharelite-perl
Architecture: source i386
Version: 0.17-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: Krzysztof Krzyżaniak (eloy) e...@debian.org
Description: 
 libipc-sharelite-perl - Perl module that provides a simple interface to shared 
memory
Changes: 
 libipc-sharelite-perl (0.17-1) unstable; urgency=low
 .
   [ Krzysztof Krzyżaniak (eloy) ]
   * New upstream release
   * debian/control: Added me to Uploaders, Standards-Version updated to 3.8.1
 (no changes), debhelper dependency updated to = 7
   * debian/rules: use debhelper7 simple example
   * Old_changes_in_diffgz.patch still disabled
 .
   [ Martín Ferrari ]
   * Updating my email address
 .
   [ gregor herrmann ]
   * debian/control: Changed: Switched Vcs-Browser field to ViewSVN
 (source stanza).
   * debian/control: Added: ${misc:Depends} to Depends: field.
Checksums-Sha1: 
 c7ce681e2277018ac5919261c75f9bb72c39eef7 1441 libipc-sharelite-perl_0.17-1.dsc
 f59ee1862ea86a7b1dccaf3b5225e86e31cbe959 22875 
libipc-sharelite-perl_0.17.orig.tar.gz
 dd3eddcd7784d174c50ef641415a659743bcb3b6 4310 
libipc-sharelite-perl_0.17-1.diff.gz
 2fedfe2344e40e9bd1bc01a579b271a6ece20e91 27780 
libipc-sharelite-perl_0.17-1_i386.deb
Checksums-Sha256: 
 33b8209cc19fc4b11139e7afb9658293583aa418c01d58fc9a7d32c31a3fcde4 1441 
libipc-sharelite-perl_0.17-1.dsc
 14d406b91da96d6521d0d1a82d22a306274765226b86b0a56e7ffddcf96ae7bf 22875 
libipc-sharelite-perl_0.17.orig.tar.gz
 3b3d3de6e27ee902ba23e1ce899f81e58d8228b39451ce18c976d3dc6ddb 4310 
libipc-sharelite-perl_0.17-1.diff.gz
 efce51ff2fcd80fcae40a3a157104a0f7a5217125cb7ebe6a91ff728b652015e 27780 
libipc-sharelite-perl_0.17-1_i386.deb
Files: 
 9492162b7229f9f046e5eadc0838b58a 1441 perl optional 
libipc-sharelite-perl_0.17-1.dsc
 54c7aa08dc065b6c946c48491d33450d 22875 perl optional 
libipc-sharelite-perl_0.17.orig.tar.gz
 43cc883fc306f1dd1ae6f91e950f8d3b 4310 perl optional 
libipc-sharelite-perl_0.17-1.diff.gz
 b48a7624cbd764ec5712deae33f4dc3e 27780 perl optional 
libipc-sharelite-perl_0.17-1_i386.deb

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

iEYEARECAAYFAkm43FoACgkQy+HP4f7iC8vncgCeLFZB/ZLG/efNQkHN9rIT0aYN
m94AnjEY32qpwzof5zSR9KeLtP25llAs
=3AgT
-END PGP SIGNATURE-


Accepted:
libipc-sharelite-perl_0.17-1.diff.gz
  to pool/main/libi/libipc-sharelite-perl/libipc-sharelite-perl_0.17-1.diff.gz
libipc-sharelite-perl_0.17-1.dsc
  to pool/main/libi/libipc-sharelite-perl/libipc-sharelite-perl_0.17-1.dsc
libipc-sharelite-perl_0.17-1_i386.deb
  to pool/main/libi/libipc-sharelite-perl/libipc-sharelite-perl_0.17-1_i386.deb
libipc-sharelite-perl_0.17.orig.tar.gz
  to pool/main/libi/libipc-sharelite-perl/libipc-sharelite-perl_0.17.orig.tar.gz


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

Accepted popa3d 1.0.2-5 (source i386)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 12 Mar 2009 11:06:22 +0100
Source: popa3d
Binary: popa3d
Architecture: source i386
Version: 1.0.2-5
Distribution: unstable
Urgency: low
Maintainer: Krzysztof Krzyżaniak (eloy) e...@debian.org
Changed-By: Krzysztof Krzyżaniak (eloy) e...@debian.org
Description: 
 popa3d - A tiny POP3 daemon, designed with security as the primary goal
Closes: 505811
Changes: 
 popa3d (1.0.2-5) unstable; urgency=low
 .
   * Italian translation of templates file was added (closes: #505811)
 Thanks to Luca Monducci luca...@tiscali.it
   * debian/control: Standards-Version updated to 3.8.1 (no changes), debhelper
 dependency updated to = 7
   * Updated debian/copyright file
   * Fix lintian warnings
Checksums-Sha1: 
 16656d1eef60e2effd06fcda8a9153e6871dfa55 960 popa3d_1.0.2-5.dsc
 47d03fe8fac14cc502a7ca3a337bb44296b5fd1b 11565 popa3d_1.0.2-5.diff.gz
 a21ece4cc9a644553c1f35efc5283c61612868b1 32488 popa3d_1.0.2-5_i386.deb
Checksums-Sha256: 
 53569d25d8ea1307d73660f2530bc1e08da43e343b168e0a12fd58dacb5f3abc 960 
popa3d_1.0.2-5.dsc
 2253b8e2a27fbecbe39d82b24bfbc24af8835f96ee4b0ddc5a70bd45f034ee30 11565 
popa3d_1.0.2-5.diff.gz
 32aa3c37553fc008e4e7952d138d8220b5c3959ab8eae18aa14f2781c1a74396 32488 
popa3d_1.0.2-5_i386.deb
Files: 
 5b69d0d493617244db652598f0faf6bc 960 mail extra popa3d_1.0.2-5.dsc
 4e61de08950e69d7f435c9d5d9da5ce3 11565 mail extra popa3d_1.0.2-5.diff.gz
 6648372383dd70041b9db5696a0c4b70 32488 mail extra popa3d_1.0.2-5_i386.deb

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

iEYEARECAAYFAkm45C0ACgkQy+HP4f7iC8v8LQCfa/sC/PMr7FSlmdQVScOWnA8h
p4gAoKL0MNw1bnVtkMDwMdg1NOUga1bG
=weX6
-END PGP SIGNATURE-


Accepted:
popa3d_1.0.2-5.diff.gz
  to pool/main/p/popa3d/popa3d_1.0.2-5.diff.gz
popa3d_1.0.2-5.dsc
  to pool/main/p/popa3d/popa3d_1.0.2-5.dsc
popa3d_1.0.2-5_i386.deb
  to pool/main/p/popa3d/popa3d_1.0.2-5_i386.deb


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

Accepted haskell-zlib 0.5.0.0-2 (source all amd64)

2009-03-12 Thread Marco Túlio Gontijo e Silva

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Wed, 11 Mar 2009 18:47:59 -0300
Source: haskell-zlib
Binary: libghc6-zlib-dev libghc6-zlib-prof haskell-zlib-doc
Architecture: source all amd64
Version: 0.5.0.0-2
Distribution: unstable
Urgency: low
Maintainer: Marco Túlio Gontijo e Silva mar...@holoscopio.com
Changed-By: Marco Túlio Gontijo e Silva mar...@holoscopio.com
Description: 
 haskell-zlib-doc - Compression and decompression in the gzip and zlib formats; 
docum
 libghc6-zlib-dev - Compression and decompression in the gzip and zlib formats
 libghc6-zlib-prof - Compression and decompression in the gzip and zlib 
formats; profi
Closes: 519261
Changes: 
 haskell-zlib (0.5.0.0-2) unstable; urgency=low
 .
   * debian/control: Depend on zlibg1-dev.  Thanks to Trent W. Buck
 trentb...@gmail.com.  Closes: #519261.
Checksums-Sha1: 
 5319303cbdc1821e5e77e612afe2057293e1c418 1306 haskell-zlib_0.5.0.0-2.dsc
 30d10317e661767928dc93f2788a2d537fb3d89f 4524 haskell-zlib_0.5.0.0-2.diff.gz
 59d3f282133bdd4dc3176423c99f8ffd1939b758 49762 
haskell-zlib-doc_0.5.0.0-2_all.deb
 6e334bf6130257378ee04653d2b901749c7d9fb6 61482 
libghc6-zlib-dev_0.5.0.0-2_amd64.deb
 52a6e163cc72234aa4e8790ae02bfefd0798334a 59992 
libghc6-zlib-prof_0.5.0.0-2_amd64.deb
Checksums-Sha256: 
 1aa949133cc1452048d591288c42718dd0d8303c6f7898d50d179e90d3e96ba6 1306 
haskell-zlib_0.5.0.0-2.dsc
 ae6f97297f22ad0ac419d1ed303a21c913637af8b4359db1540e0858f919c215 4524 
haskell-zlib_0.5.0.0-2.diff.gz
 9f1a748f962137681f237e9d1c3575a1a34227f59a4df6a628c9eb99ad8211e5 49762 
haskell-zlib-doc_0.5.0.0-2_all.deb
 a2a0c8e9fdc3b3b88bb15985b94352d848f01ef7b39490b549d0e6bd0a37baa3 61482 
libghc6-zlib-dev_0.5.0.0-2_amd64.deb
 85065255b7a858446de6a4ce7a2ca9500124ecbfcd680fd0c197e5bf2628e54d 59992 
libghc6-zlib-prof_0.5.0.0-2_amd64.deb
Files: 
 4c406c3a0ef16bf4b42fa8c83784c7a2 1306 libdevel optional 
haskell-zlib_0.5.0.0-2.dsc
 f9ade45d4442471552054b4ad5ff9c51 4524 libdevel optional 
haskell-zlib_0.5.0.0-2.diff.gz
 f549fdcf26c94ddcefe30e2e14f5ea7b 49762 doc optional 
haskell-zlib-doc_0.5.0.0-2_all.deb
 96bdb773d0cbb772d9640440a832c7ce 61482 libdevel optional 
libghc6-zlib-dev_0.5.0.0-2_amd64.deb
 64b40e0f979d562d4aedcf76de450d66 59992 libdevel optional 
libghc6-zlib-prof_0.5.0.0-2_amd64.deb

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

iEYEARECAAYFAkm438oACgkQ9ijrk0dDIGy+RwCgkQIME5eTHfctiANbkhYNgCVi
MHUAoJtuNRrkitWqPdwyZLPJd/jvp57n
=YUoI
-END PGP SIGNATURE-


Accepted:
haskell-zlib-doc_0.5.0.0-2_all.deb
  to pool/main/h/haskell-zlib/haskell-zlib-doc_0.5.0.0-2_all.deb
haskell-zlib_0.5.0.0-2.diff.gz
  to pool/main/h/haskell-zlib/haskell-zlib_0.5.0.0-2.diff.gz
haskell-zlib_0.5.0.0-2.dsc
  to pool/main/h/haskell-zlib/haskell-zlib_0.5.0.0-2.dsc
libghc6-zlib-dev_0.5.0.0-2_amd64.deb
  to pool/main/h/haskell-zlib/libghc6-zlib-dev_0.5.0.0-2_amd64.deb
libghc6-zlib-prof_0.5.0.0-2_amd64.deb
  to pool/main/h/haskell-zlib/libghc6-zlib-prof_0.5.0.0-2_amd64.deb


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

Accepted deluge 1.1.4+dfsg-2 (source all)

2009-03-12 Thread Cristian Greco

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 12 Mar 2009 09:51:32 +0100
Source: deluge
Binary: deluge-core deluge-common deluge-console deluge-webui deluge 
deluge-torrent
Architecture: source all
Version: 1.1.4+dfsg-2
Distribution: unstable
Urgency: low
Maintainer: Cristian Greco cristian.deb...@gmail.com
Changed-By: Cristian Greco cristian.deb...@gmail.com
Description: 
 deluge - bittorrent client written in Python/PyGTK (GTK+ UI)
 deluge-common - bittorrent client written in Python/PyGTK (UIs common data 
files)
 deluge-console - bittorrent client written in Python/PyGTK (console UI)
 deluge-core - bittorrent client written in Python/PyGTK (daemon)
 deluge-torrent - bittorrent client written in Python/PyGTK (transitional 
package)
 deluge-webui - bittorrent client written in Python/PyGTK (web UI)
Closes: 519042
Changes: 
 deluge (1.1.4+dfsg-2) unstable; urgency=low
 .
   * debian/patches: new patch 20-fix-config-files-backup.dpatch pulled from
 upstream svn should fix a problem with config files (Closes: #519042).
   * debian/control: bump up Standards-Version to 3.8.1 (no changes required).
Checksums-Sha1: 
 3a127d45afb7e398e64123a98a0ef359c9b32d92 1248 deluge_1.1.4+dfsg-2.dsc
 f9f6145dc391e11942c3f023bef45d8c32c080bb 19065 deluge_1.1.4+dfsg-2.diff.gz
 2ee5f57a787051c57117c6184b7c9ce48b99a2c6 1293804 
deluge-core_1.1.4+dfsg-2_all.deb
 1dd8eedfe88ee0f17d363bd321f38ee5ed6a0356 187528 
deluge-common_1.1.4+dfsg-2_all.deb
 a552457e203c17de5838253950f6a546b375be93 32242 
deluge-console_1.1.4+dfsg-2_all.deb
 1cb5dc6ce967952834359dca803e31f89c2d5e1c 308460 
deluge-webui_1.1.4+dfsg-2_all.deb
 a45722f50e9eab36097b2b967e76c933dc62cf45 250044 deluge_1.1.4+dfsg-2_all.deb
 cf5da0ee9724bda28a629fca31440b8e9700a64a 23380 
deluge-torrent_1.1.4+dfsg-2_all.deb
Checksums-Sha256: 
 f95ef3d4e143f5086eb7b9b9b518e26338f1b37053e80f0ec0bf8b008986afd7 1248 
deluge_1.1.4+dfsg-2.dsc
 01e2fafc00ee55f76fd4b5b6dca4e03a090970abc7b51ff1d61cf5624293d2eb 19065 
deluge_1.1.4+dfsg-2.diff.gz
 16ba9847da863927c719d536a1dc40c4efeabd88ab24cfc9a76ba88ba39b86e7 1293804 
deluge-core_1.1.4+dfsg-2_all.deb
 7b32e2202712a03c38e514d6d88b63a68ef49127cd71cacc1e16bb44a33d113a 187528 
deluge-common_1.1.4+dfsg-2_all.deb
 d08e02232b518047f939badd136a2cb45f57324c806fab372fd356ba78b558f9 32242 
deluge-console_1.1.4+dfsg-2_all.deb
 9268207c5295243af652ab398a8f9bfb7bb7e2e0ebad490e06981bd208bbb6e6 308460 
deluge-webui_1.1.4+dfsg-2_all.deb
 75409dfc936933e852bba6c54d98afa597e32e364f49428df64c4293593befd1 250044 
deluge_1.1.4+dfsg-2_all.deb
 0d2f3f64407154222dee320078c319eb2fe22ef54d7194e30b8931b10e68a001 23380 
deluge-torrent_1.1.4+dfsg-2_all.deb
Files: 
 71367dd37bbddf3f06d97a74f76cf69f 1248 net optional deluge_1.1.4+dfsg-2.dsc
 daf27f065e2e14786809e7c9ebf8f511 19065 net optional deluge_1.1.4+dfsg-2.diff.gz
 6babbb52ae055bdb125de5d9cf5ef0f1 1293804 net optional 
deluge-core_1.1.4+dfsg-2_all.deb
 08c98e74d0aca765bce78bb112b7530f 187528 net optional 
deluge-common_1.1.4+dfsg-2_all.deb
 325f94d867e2dc77bab34cc365be2c4a 32242 net optional 
deluge-console_1.1.4+dfsg-2_all.deb
 772999f8ef85f89fbb3a42592d0970a9 308460 net optional 
deluge-webui_1.1.4+dfsg-2_all.deb
 1e6941fddb1eff7d112752d5b8646b88 250044 net optional 
deluge_1.1.4+dfsg-2_all.deb
 d3d56ec9fc7af7fc94e9c9262960d495 23380 net optional 
deluge-torrent_1.1.4+dfsg-2_all.deb

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

iEYEARECAAYFAkm43YQACgkQ3DVS6DbnVgRbzgCgn11Yk7uN+l+Gl0IEidtQ2BJZ
2REAoIxw/1RL+H3IKXO5u2tFZkvgpAn/
=wrsM
-END PGP SIGNATURE-


Accepted:
deluge-common_1.1.4+dfsg-2_all.deb
  to pool/main/d/deluge/deluge-common_1.1.4+dfsg-2_all.deb
deluge-console_1.1.4+dfsg-2_all.deb
  to pool/main/d/deluge/deluge-console_1.1.4+dfsg-2_all.deb
deluge-core_1.1.4+dfsg-2_all.deb
  to pool/main/d/deluge/deluge-core_1.1.4+dfsg-2_all.deb
deluge-torrent_1.1.4+dfsg-2_all.deb
  to pool/main/d/deluge/deluge-torrent_1.1.4+dfsg-2_all.deb
deluge-webui_1.1.4+dfsg-2_all.deb
  to pool/main/d/deluge/deluge-webui_1.1.4+dfsg-2_all.deb
deluge_1.1.4+dfsg-2.diff.gz
  to pool/main/d/deluge/deluge_1.1.4+dfsg-2.diff.gz
deluge_1.1.4+dfsg-2.dsc
  to pool/main/d/deluge/deluge_1.1.4+dfsg-2.dsc
deluge_1.1.4+dfsg-2_all.deb
  to pool/main/d/deluge/deluge_1.1.4+dfsg-2_all.deb


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

Accepted dctrl2xml 0.14 (source all)

2009-03-12 Thread Frank S. Thomas

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 12 Mar 2009 11:07:43 +0100
Source: dctrl2xml
Binary: dctrl2xml
Architecture: source all
Version: 0.14
Distribution: unstable
Urgency: low
Maintainer: Frank S. Thomas f...@debian.org
Changed-By: Frank S. Thomas f...@debian.org
Description: 
 dctrl2xml  - Debian control data to XML converter
Changes: 
 dctrl2xml (0.14) unstable; urgency=low
 .
   * debian/control:
 - Added ${misc:Depends} to Depends to appease Lintian.
 - Bumped Standards-Version from 3.8.0 to 3.8.1, no changes required.
Checksums-Sha1: 
 e5a2b438f91df3b9a5dcbf364b1ab9abe25d926c 914 dctrl2xml_0.14.dsc
 e30ce7be7e05fd237ab7998fe431f9b467f3ba90 22451 dctrl2xml_0.14.tar.gz
 db9404af4880b176ae6fda1d257f294208eaa05c 11572 dctrl2xml_0.14_all.deb
Checksums-Sha256: 
 3dbabd18b71dc387dcb5e40821c7b1f29b8eb92551ca1e75a88021e7f47177d2 914 
dctrl2xml_0.14.dsc
 b8cd181d54fdbb38a894a9f0f518473bc4fa3c20f922e3d5aedc6949a5199495 22451 
dctrl2xml_0.14.tar.gz
 c449d678e52aa700487f25b87b36bf1c77c144b80f331ff5b6b14e0d6e4dd33e 11572 
dctrl2xml_0.14_all.deb
Files: 
 bb8448faeb78303d33ac5aac211a3586 914 utils optional dctrl2xml_0.14.dsc
 eb1a8b68d6a96dc76adab66cc38e92c0 22451 utils optional dctrl2xml_0.14.tar.gz
 3df301ef547ff76aeb51741d3664e4cd 11572 utils optional dctrl2xml_0.14_all.deb

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

iEYEARECAAYFAkm44GAACgkQft6HNdxCZClJggCeIWHt7dErw46rPj/K1VQrY6bI
TkAAnRG90OKtJwYqGAliD5mV5JW6nj+v
=1PvU
-END PGP SIGNATURE-


Accepted:
dctrl2xml_0.14.dsc
  to pool/main/d/dctrl2xml/dctrl2xml_0.14.dsc
dctrl2xml_0.14.tar.gz
  to pool/main/d/dctrl2xml/dctrl2xml_0.14.tar.gz
dctrl2xml_0.14_all.deb
  to pool/main/d/dctrl2xml/dctrl2xml_0.14_all.deb


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

Accepted libpar-perl 0.991-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 12 Mar 2009 11:02:12 +0100
Source: libpar-perl
Binary: libpar-perl
Architecture: source all
Version: 0.991-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: Krzysztof Krzyżaniak (eloy) e...@debian.org
Description: 
 libpar-perl - Perl Archive Toolkit
Changes: 
 libpar-perl (0.991-1) unstable; urgency=low
 .
   * New upstream release
Checksums-Sha1: 
 0044abb6d730f016f258ec0ffba0f5ca462b781d 1725 libpar-perl_0.991-1.dsc
 bfbd0e0b7c4c8523d85d342f8b825d18c28e3aea 79228 libpar-perl_0.991.orig.tar.gz
 8ccdef7c42d13d982cfde815ab975c4f86cc1ae9 3900 libpar-perl_0.991-1.diff.gz
 6d191be9ab6c5ff687961f347940f917c1e9aeda 98520 libpar-perl_0.991-1_all.deb
Checksums-Sha256: 
 901199af804b2ad1d7dbb40ffb5f59817b16d3310fbecee73e40d242e91cbdfb 1725 
libpar-perl_0.991-1.dsc
 f3c7861801f230544f702e27027e658d3910b74d8fdee14c1df84f5fa0f95ba3 79228 
libpar-perl_0.991.orig.tar.gz
 7b47fb2662fade64ae258dca88f30ed069276108454dc7bfefbe375482640157 3900 
libpar-perl_0.991-1.diff.gz
 dbe29920f9ff0b2e61d7e080fa1d810b6d3e98b36f50ee1179df27451bb4e844 98520 
libpar-perl_0.991-1_all.deb
Files: 
 9bb57a2cbe81a73d94fe776b0faac8a1 1725 perl optional libpar-perl_0.991-1.dsc
 5f2b339df004374b6e604d79f891371d 79228 perl optional 
libpar-perl_0.991.orig.tar.gz
 cce94483494cce88fa494d913508eb72 3900 perl optional libpar-perl_0.991-1.diff.gz
 424c2ee68e826d7e28d0ed634b35a32d 98520 perl optional 
libpar-perl_0.991-1_all.deb

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

iEYEARECAAYFAkm44a0ACgkQy+HP4f7iC8sW1gCcDbkN+xi1NtU4WPfKgufyHgit
7EcAnRTh3CB/EC44gMFNsxzUZe2OK2sD
=1fnj
-END PGP SIGNATURE-


Accepted:
libpar-perl_0.991-1.diff.gz
  to pool/main/libp/libpar-perl/libpar-perl_0.991-1.diff.gz
libpar-perl_0.991-1.dsc
  to pool/main/libp/libpar-perl/libpar-perl_0.991-1.dsc
libpar-perl_0.991-1_all.deb
  to pool/main/libp/libpar-perl/libpar-perl_0.991-1_all.deb
libpar-perl_0.991.orig.tar.gz
  to pool/main/libp/libpar-perl/libpar-perl_0.991.orig.tar.gz


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

Accepted haskell-terminfo 0.3.0.1-1 (source all amd64)

2009-03-12 Thread Marco Túlio Gontijo e Silva

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 26 Feb 2009 11:03:40 -0300
Source: haskell-terminfo
Binary: libghc6-terminfo-dev libghc6-terminfo-prof libghc6-terminfo-doc
Architecture: source all amd64
Version: 0.3.0.1-1
Distribution: unstable
Urgency: low
Maintainer: Marco Túlio Gontijo e Silva mar...@holoscopio.com
Changed-By: Marco Túlio Gontijo e Silva mar...@holoscopio.com
Description: 
 libghc6-terminfo-dev - Haskell bindings to the terminfo library
 libghc6-terminfo-doc - Haskell bindings to the terminfo library; documentation
 libghc6-terminfo-prof - Haskell bindings to the terminfo library; profiling 
libraries
Changes: 
 haskell-terminfo (0.3.0.1-1) unstable; urgency=low
 .
   * New upstream version.
   * New maintainer e-mail address.
   * Use haskell-devscripts.
   * debian/control: Use debian Vcs.
   * debian/copyright: New packaging license: CC0.
   * debian/watch: Correct syntax.
Checksums-Sha1: 
 44e98c983a1543f7365ffeeabf0ce6c8a02b151f 1340 haskell-terminfo_0.3.0.1-1.dsc
 899584100c189a419a756abaf6c420aa3669fe33 38884 
haskell-terminfo_0.3.0.1.orig.tar.gz
 24fa0be2738cc018cb7a588124ba95ee5ebe6d72 4659 
haskell-terminfo_0.3.0.1-1.diff.gz
 fd93b5805da8839416d9563414c3c74a23e335fd 34104 
libghc6-terminfo-doc_0.3.0.1-1_all.deb
 2947a8d9331c22abb5eee5f5f9062f8bb7752ca8 73366 
libghc6-terminfo-dev_0.3.0.1-1_amd64.deb
 07a360117873bc9c70d48b9a75c6084672193b32 70810 
libghc6-terminfo-prof_0.3.0.1-1_amd64.deb
Checksums-Sha256: 
 357d91ccf7da0ec61461db964d9577b2b9c18462e75e87b908382ef41f026e74 1340 
haskell-terminfo_0.3.0.1-1.dsc
 96a3dabc8bc59c68f22af803dd346cd7927afb4c4f80837cbccdced3e3be74bd 38884 
haskell-terminfo_0.3.0.1.orig.tar.gz
 db45144ff18322ff1ab74007527c2d56aa933a600c0a48db6122fd16105bdffe 4659 
haskell-terminfo_0.3.0.1-1.diff.gz
 2476d04dcb07445834c59cabf2300b15794e9b1ce8eeea51f735a271a39e9468 34104 
libghc6-terminfo-doc_0.3.0.1-1_all.deb
 161fb37a7d738457fcf57902b5478bca6d434a98b17aef427b5871e0d00b93d7 73366 
libghc6-terminfo-dev_0.3.0.1-1_amd64.deb
 261dcce30d8be3d9e77ac26e499566e3490f34b51e989f75e0895620e0b95a5f 70810 
libghc6-terminfo-prof_0.3.0.1-1_amd64.deb
Files: 
 f8ad7128f5d3a761b5933711ab560ae5 1340 libdevel optional 
haskell-terminfo_0.3.0.1-1.dsc
 171bcac20bbad0ecaec54759f1fbde4b 38884 libdevel optional 
haskell-terminfo_0.3.0.1.orig.tar.gz
 ba85be1e098574e683a7bf4b0c8337d9 4659 libdevel optional 
haskell-terminfo_0.3.0.1-1.diff.gz
 bb5e6399f4138a257206363b345d320e 34104 doc optional 
libghc6-terminfo-doc_0.3.0.1-1_all.deb
 9a80e1d0b9d333118111648d4b8a71f3 73366 libdevel optional 
libghc6-terminfo-dev_0.3.0.1-1_amd64.deb
 03f0468096f8e3b6c26cf6a5e4a09947 70810 libdevel optional 
libghc6-terminfo-prof_0.3.0.1-1_amd64.deb

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

iEYEARECAAYFAkm44JAACgkQ9ijrk0dDIGwyQwCgko/WYVedRS2JgXseJwjiF5Pt
epEAoMbwUQjPQUhfTit9Unela1pOEFps
=bSih
-END PGP SIGNATURE-


Accepted:
haskell-terminfo_0.3.0.1-1.diff.gz
  to pool/main/h/haskell-terminfo/haskell-terminfo_0.3.0.1-1.diff.gz
haskell-terminfo_0.3.0.1-1.dsc
  to pool/main/h/haskell-terminfo/haskell-terminfo_0.3.0.1-1.dsc
haskell-terminfo_0.3.0.1.orig.tar.gz
  to pool/main/h/haskell-terminfo/haskell-terminfo_0.3.0.1.orig.tar.gz
libghc6-terminfo-dev_0.3.0.1-1_amd64.deb
  to pool/main/h/haskell-terminfo/libghc6-terminfo-dev_0.3.0.1-1_amd64.deb
libghc6-terminfo-doc_0.3.0.1-1_all.deb
  to pool/main/h/haskell-terminfo/libghc6-terminfo-doc_0.3.0.1-1_all.deb
libghc6-terminfo-prof_0.3.0.1-1_amd64.deb
  to pool/main/h/haskell-terminfo/libghc6-terminfo-prof_0.3.0.1-1_amd64.deb


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

Accepted groff 1.18.1.1-22 (source i386)

2009-03-12 Thread Colin Watson

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 12 Mar 2009 10:48:01 +
Source: groff
Binary: groff-base groff
Architecture: source i386
Version: 1.18.1.1-22
Distribution: unstable
Urgency: low
Maintainer: Colin Watson cjwat...@debian.org
Changed-By: Colin Watson cjwat...@debian.org
Description: 
 groff  - GNU troff text-formatting system
 groff-base - GNU troff text-formatting system (base system components)
Closes: 519367
Changes: 
 groff (1.18.1.1-22) unstable; urgency=low
 .
   * Fix bug number for groffer fix in previous changelog entry.
   * If the ascii8 device is used, pass through the input encoding even if
 LC_CTYPE=C (closes: #519367).
   * Build-depend on and recommend ghostscript rather than the obsolete
 package gs.
Checksums-Sha1: 
 5fe0ccff35de62736c7df64a85f838b7e31ac18f 1190 groff_1.18.1.1-22.dsc
 5e020c26a4e20e96df2e266831c04637beb0da08 136360 groff_1.18.1.1-22.diff.gz
 e7887620c5d239b028c3e5265e1bf719beafa1e8 848542 groff-base_1.18.1.1-22_i386.deb
 56240d92bbf68fe5f27107f5b72f9c2dfe3a77de 1911976 groff_1.18.1.1-22_i386.deb
Checksums-Sha256: 
 7818d64c205896812836d2110d065adcf2d2e0cbacd31353c360122d3aae8a73 1190 
groff_1.18.1.1-22.dsc
 85a3d5d98384fff78804770d7011f77d8de0cbc6ead47e54ebc7ff3827e0e111 136360 
groff_1.18.1.1-22.diff.gz
 cbed06ee274f481b5d554d509ad6e6188dfb78398b58dfc3d2de526fa822cf10 848542 
groff-base_1.18.1.1-22_i386.deb
 fced72c14d54929a82baeb2ca4c0f74eb36271a7b77644cf72e2a9970b2a 1911976 
groff_1.18.1.1-22_i386.deb
Files: 
 d77b9858e3e417941a847291212f23bd 1190 text important groff_1.18.1.1-22.dsc
 6caa44146652f59705cb0ef8d1c72c25 136360 text important 
groff_1.18.1.1-22.diff.gz
 84e2d0a7c123f179495dc7247a9a8626 848542 text important 
groff-base_1.18.1.1-22_i386.deb
 a81412ff2f576b6df1a12dae7c988aca 1911976 text optional 
groff_1.18.1.1-22_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Colin Watson cjwat...@debian.org -- Debian developer

iD8DBQFJuOm49t0zAhD6TNERAjIhAJ9HiJ1o6RLsATQEjj/iNdcXsjPZygCeNKKg
2Px1FlLQObO97eDeg4CwJhI=
=I7st
-END PGP SIGNATURE-


Accepted:
groff-base_1.18.1.1-22_i386.deb
  to pool/main/g/groff/groff-base_1.18.1.1-22_i386.deb
groff_1.18.1.1-22.diff.gz
  to pool/main/g/groff/groff_1.18.1.1-22.diff.gz
groff_1.18.1.1-22.dsc
  to pool/main/g/groff/groff_1.18.1.1-22.dsc
groff_1.18.1.1-22_i386.deb
  to pool/main/g/groff/groff_1.18.1.1-22_i386.deb


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

Accepted libcatalyst-view-tt-perl 0.29-1 (source all)