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

[Neil Williams]

On Wed, 11 Mar 2009 23:38:49 -0400
Yaroslav Halchenko  wrote:

> In the light of having Debian on all kinds of devices with touchscreens
> (tablets/freerunner), I propose to add a virtual package
> 
> x-keyboard
> or may be better
> x-onscreen-keyboard ?

x- infers screen IMHO in the same way as x-terminal-emulator and
x-window-manager, so x-keyboard is preferable.
 
> and a equivalently named alternative
> 
> Packages which I should provide it (there could be more):
> xvkbd
> qwo
> matchbox-keyboard

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.
;-)

I'm not sure how the two issues should be related but if a device has
an x-keyboard package installed, there should be some kind of link to a
login manager that can cope with an x-keyboard. We cannot assume that
all touchscreen or x-keyboard devices are single-user with auto-login
enabled.

> Upon receiving comments and if no objections made I guess I will file a
> butreport against debian-policy to have virtual-package-names-list.txt
> adjusted
> 
> Meanwhile I CCing xvkbd and matchbox-keyboard maintainers to attract
> their attention

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgp1XAHHEMDil.pgp
Description: PGP signature

Re: BDF Considered Harmful?

[Paul Hardy]

On Wed, Mar 11, 2009 at 3:21 PM, Stefano Zacchiroli  wrote:
> On Wed, Mar 11, 2009 at 01:14:03PM +0100, Bill Allombert wrote:
>> I fail to see the difference between a BDF-to-PCF converter and a C compiler
>> that will discard comments from the C source files. Yet we do not generally
>> ship C source code in binary packages.
>
> This is not the right analogy. A C source file by itself cannot be run
> without having been compiled while, AFAICT from the given description,
> a BDF "source" file can be.
>
> A question I have and that hasn't been addressed by the original
> request is: what is the advantage to have BDF files in binary
> packages? Comments and copyright notices don't look like a real
> advantage to me.

The only advantage is in preserving all information if (and only if)
the original font is in BDF format.  It seemed harmless to me if the
savings in size was nonexistent, with both BDF and PCF files gzipped.
Steve Langasek brought up something I hadn't considered, that PCF's
table-based format could be more efficient in general than alternative
font formats.  A BDF font does have to be read serially from beginning
to end; there are no handy table offsets to jump from one glyph to the
next.  That might not be an issue with the speed of modern computers,
especially if the BDF font in question only has on the order of 256
characters.

If it is sufficient to have copyright information in the Debian
copyright file, then so be it.  I was also concerned about other
things that might be dropped.  A BDF file can contain any number of
properties describing the font in the header, for example CAP_HEIGHT
and X_HEIGHT.  Maybe there's no harm in losing this information
through format conversion.  I don't know what all the implications
are.  The list of BDF properties isn't fixed, so bdftopcf is likely to
discard some of such information during conversion.

The bdftopcf utility calls a function in bdfread.c to mainly load
glyph bitmaps, then calls another function to write them out as a PCF
file.  The source code that reads a BDF font contains this
confidence-inspiring comment:

 /* 5/31/89 (ef) -- hack, hack, hack. what *am* I supposed to do with */
 /* 0 width characters? */

I ran into this trying to track down why Unicode combining marks
weren't overlapping preceding characters properly in BDF or PCF
versions of the unifont package; I only got the TrueType version
working.  (Disclaimer: I'm not at home now, and not anywhere near my
Debian system; the above code is something I had on a laptop where I
worked on getting combining marks working.)

So because Debian GNU/Linux properly renders uncompressed BDF fonts if
they are placed in the font directory, I thought I'd ask if it could
make sense to support .bdf.gz font files -- both technically and as
Debian Policy.  I thought that this could simplify installing a BDF
font (by avoiding conversion to PCF) as well as guaranteeing that all
information the font designer included was preserved in the installed
font.


Paul Hardy


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

[Riku Voipio]

On Wed, Mar 11, 2009 at 12:55:52PM +0100, Adeodato Simó wrote:
> The problem is, of course, defining the “well-defined policy”. For most
> libraries an early removal has no big consequences. It would have been
> tempting to have guessed that there wouldn’t be any for poppler either,
> because the fact that decrufting poppler would render texlive uninstallable,
> upon which a lot of packages build-depend on, needs a bit of close looking
> in order to be noticed.

IMHO the root cause here was that the poppler transition required source
changes in the reverse dependencies (such as texlive-bin). Yet, the maintainers
of poppler didn't care to warn maintainers of reverse dependecies nor the
release team that this transition isn't solvable with just binNMU's. This
lead to the transition to take so long that old poppler library got
decrufted.

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.


signature.asc
Description: Digital signature

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

[Steve Langasek]

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

[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

[Goswin von Brederlow]

Clint Adams  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

[Goswin von Brederlow]

Steve Langasek  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?

[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

[Goswin von Brederlow]

Steve Langasek  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

[Goswin von Brederlow]

Neil Williams  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

[Jean Parpaillon]

Package: wnpp
Severity: wishlist
Owner: Jean Parpaillon 


* Package name: hpcc
  Version : 1.3.1
  Upstream Author : HPC Challenge team 
* 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#519408: ITP: lxc -- Linux containers userspace tools

[Guido Trotter]

Package: wnpp
Severity: wishlist
Owner: Guido Trotter 

* Package name: lxc
  Version : 0.6.0
  Upstream Author : IBM Corporation
* URL : http://lxc.sourceforge.net/
* License : LGPL
  Programming Lang: C
  Description : Linux containers userspace tools

This package contains the lxc-* tools which can be used to manage and
debug the container technology included in recent linux kernels. It can
be used to start individual softwares or full systems inside an
insulated area, with not only its own filesystem (chroot) but also
dedicated network interfaces, scheduling, users, etc.

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (1001, 'stable'), (501, 'testing'), (500, 'unstable'), (1, 
'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

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

[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".

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

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

[Daniel Watkins]

Package: wnpp
Severity: wishlist
Owner: Daniel Watkins 

* Package name: python-django-formfieldset
  Version : 0+git20090312-f07320dd
  Upstream Author : Atamert Ölçgen 
* 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?

[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

[Salvatore Bonaccorso]

Package: wnpp
Severity: wishlist
Owner: Salvatore Bonaccorso 

* Package name: bosh
  Version : 0.5
  Upstream Author : Alex Sisson 
* 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

[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 Vienna University of Technology
Debian Developer  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

[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

[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?

[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

[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 !
+  * 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 !
+
+ -- Fabian Greffrath   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 
 Uploaders: Fabian Greffrath , Sam Hocevar (Debian packages) 
-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
-Section: sound
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: MPEG-1 layer 2 audio encoder
@@ -22,2 +21,0 @@
- .
-

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

[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

[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  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?

[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

[Manoj Srivastava]

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

[Steve Langasek]

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

[William Pitcock]

On Wed, 2009-03-11 at 23:56 +0100, Karl Ferdinand Ebert wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Karl Ferdinand Ebert 
> 
> * Package name: tmux
>   Version : 0.7
>   Upstream Author : Nicholas Marriott 
> * 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

[Russ Allbery]

Gunnar Wolf  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)   


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

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

[Russ Allbery]

Manoj Srivastava  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)   


-- 
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?

[Russ Allbery]

Eric Cooper  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)   


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

[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 

> 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

[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

[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 


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

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

[Goswin von Brederlow]

Steve Langasek  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

[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?

[Goswin von Brederlow]

"Giacomo A. Catenazzi"  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

[Russ Allbery]

Bernd Zeimetz  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)   


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

On Thu, Mar 12, 2009 at 08:52:04PM +0100, Goswin von Brederlow wrote:
> Steve Langasek  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

[Steve Langasek]

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

[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. 

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

[Russ Allbery]

Steve Langasek  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)   


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

[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

[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

[Chow Loong Jin]

On Thu, 2009-03-12 at 20:18 +0100, Jaromír Mikeš wrote:
> > Od: Jonathan Wiltshire 
> 
> > 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

[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.

[non, ici c'est 'amule' depuis qu'il existe, avant c'était MlDonkey]


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

[Jean Silva]

Veja:

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


--- Em qui, 12/3/09, Welisson  escreveu:

> De: Welisson 
> 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

[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

[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

[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

[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)

[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

[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?
> 


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 highwayman’s 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

[Michael Loftis]

--On March 13, 2009 4:11:28 AM +0800 Thomas Goirand  
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

[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

[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

[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 


signature.asc
Description: Digital signature

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

[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

[Ben Finney]

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 


signature.asc
Description: Digital signature

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

[Mirco Bauer]

Package: wnpp
Severity: wishlist
Owner: Mirco Bauer 

* Package name: nlog
  Version : 1.0
  Upstream Author : Jaroslaw Kowalski  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

[Manoj Srivastava]

On Thu, Mar 12 2009, Russ Allbery wrote:

> Manoj Srivastava  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    
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]

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

[Ben Finney]

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 


signature.asc
Description: Digital signature

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

[Manoj Srivastava]

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

[Ben Finney]

On 12-Mar-2009, Russ Allbery wrote:
> Manoj Srivastava  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 


signature.asc
Description: Digital signature

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

[Russ Allbery]

Ben Finney  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)   


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

[Ben Finney]

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 


signature.asc
Description: Digital signature

Re: New Security Team Members

[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)

[Ben Finney]

Karl Ferdinand Ebert  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

[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

[Steve Langasek]

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 c

Work-needing packages report for Mar 13, 2009

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 395 (new: 13)
Total number of packages offered up for adoption: 111 (new: 2)
Total number of packages requested help for: 51 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   bookmark-merge (#519353), orphaned yesterday
 Description: Merge bookmarks from Mozilla, Netscape and IE
 Installations reported by Popcon: 78

   canna (#519388), orphaned today
 Description: Japanese input system (server and dictionary)
 Reverse Depends: canna canna-shion canna-utils iiimf-le-canna
   jvim-canna kinput2-canna kinput2-canna-wnn libcanna1g-dev
   ng-cjk-canna scim-canna (4 more omitted)
 Installations reported by Popcon: 2625

   ethstats (#519342), orphaned yesterday
 Description: script that quickly measures network device throughput.
 Installations reported by Popcon: 324

   fish (#518793), orphaned 4 days ago
 Description: a friendly interactive shell
 Reverse Depends: fish-dbg
 Installations reported by Popcon: 344

   fuzz (#519376), orphaned yesterday
 Description: stress-test programs by giving them random input
 Installations reported by Popcon: 54

   postgresql-plruby (#519317), orphaned yesterday
 Description: Ruby procedural language for PostgreSQL
 Installations reported by Popcon: 53

   prips (#519379), orphaned today
 Description: Print IP address on a given range
 Installations reported by Popcon: 125

   tclxml (#519315), orphaned yesterday
 Description: Tcl library for XML parsing
 Installations reported by Popcon: 67

   visual-regexp (#519351), orphaned yesterday
 Description: Interactively debug regular expressions
 Installations reported by Popcon: 131

   wwwstat (#519383), orphaned today
 Description: httpd logfile analysis package
 Installations reported by Popcon: 57

   xmahjongg (#519355), orphaned yesterday
 Description: tile-based solitaire game
 Installations reported by Popcon: 381

   xmeter (#519345), orphaned yesterday
 Description: histogram of data returned by rstat(3)
 Installations reported by Popcon: 51

   yaclc (#519377), orphaned yesterday
 Description: Check the bug closings in a Debian changelog
 Installations reported by Popcon: 32

382 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   postgresql-plruby (#519317), offered yesterday
 Description: Ruby procedural language for PostgreSQL
 Installations reported by Popcon: 53

   s3switch (#519298), offered yesterday
 Description: Manage the output device on S3 Savage chips
 Installations reported by Popcon: 59

109 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] proftpd-dfsg (#519175), requested 2 days ago
 Description: versatile, virtual-hosting FTP daemon
 Reverse Depends: dtc-common proftpd-dev proftpd-mod-ldap
   proftpd-mod-mysql proftpd-mod-odbc proftpd-mod-pgsql
   proftpd-mod-sqlite
 Installations reported by Popcon: 2628

   apache2 (#470795), requested 364 days ago
 Description: Co-maintainer wanted
 Reverse Depends: ampache apache2 apache2-dbg apache2-mpm-event
   apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker
   apache2-prefork-dev apache2-suexec apache2-suexec-custom (155 more
   omitted)
 Installations reported by Popcon: 42170

   ara (#450876), requested 487 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 125

   asymptote (#517342), requested 14 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 214

   athcool (#278442), requested 1598 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 225

   boinc (#511243), requested 63 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc-app-seti boinc-dbg
 Installations reported by Popcon: 1585

   cvs (#354176), requested 1113 days ago
 Description: Concurrent Versions System
 Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta cvsps (12 more
   omitted)
 Installations reported by Popcon: 22536

   dctrl-to