Re: Sources of dak ?

[Joerg Jaspert]

On 11278 March 1977, Roger Leigh wrote:

>> http://ftp-master.debian.org/bzr/
> Why isn't this on bzr.debian.org?

Why should it be there?

Its in /srv/ftp.debian.org on the ftp-master host, *the* central place
for all ftpmaster related things.

-- 
bye Joerg
SUSE = Soll Unix Sein, Eigentlich.


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

Re: debconf best practices: how to ask for a password?

[Brian May]

> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:

Joey> Francois Marier wrote:
>> Now the problem (see bug #462658) is that if you ever put a non-empty
>> password there, then, you can no longer get rid of it after
>> dpkg-reconfiguring the package.  debconf seems to be ignoring empty 
password
>> fields and still returns the previous value.

Joey> This is a deficiency in debconf's UIs for prompting for password. 
Since
Joey> there's generally no sane way to display the old password as the 
default
Joey> and allow users to change it or delete the password entirely, debconf
Joey> instead displays no password, and if the user enters nothing, assumes
Joey> they meant to enter the old password unchanged.

This is really confusing UI. To me, as a user, it would appear there
is no way of reusing the old password, and it would appear that
pushing enter will result in the password being truncated. In fact
this is what probably would happen if the system has forgotten the
password entered for some reason (maybe it was never entered via
debconf before).

In the past I have almost filled bug reports against certain packages
because I have had to reenter the passwords on every upgrade, even
though it already knows the details. There is no way for a user to
know if debconf has an old password on record or not.

Can you replace the password with stars? This way you can see if there
is a password or not, and you get visual feedback when entering a
password that it is being received too (another issue I have had in
the past; not sure why it confused me so much now).
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: How to cope with patches sanely

[Ben Finney]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Lars Wirzenius <[EMAIL PROTECTED]> writes:
> 
> > In other words: dpkg-source must unpack sources that can be
> > directly edited and then dpkg-buildpackage will build a new,
> > modified package that can be uploaded.
> > [...]
> 
> This work flow simply doesn't work with our current source package
> format and a patch management system. Requiring this to work *with
> the current source package format* essentially means outlawing using
> patch management systems to manage Debian packages. That's why this
> proposal is controversial.

Yes. However, I entirely agree with Lars's proposed requirement that
the described workflow should work on every Debian source package.

So, either an improved source package format is contrived (and
implemented, and tested, and adopted, and becomes reliable) to allow
the above workflow with (some subset of) patch management schemes, or
people should use VCSen instead of patch management schemes.

IANADD.

-- 
 \"Pinky, are you pondering what I'm pondering?" "Wuh, I think |
  `\   so, Brain, but will they let the Cranberry Dutchess stay in the |
_o__)  Lincoln Bedroom?"  -- _Pinky and The Brain_ |
Ben Finney


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

Bug#463069: ITP: refcard -- printable reference card for the Debian system

[W. Borgert]

Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert" <[EMAIL PROTECTED]>

Package name: refcard
Version : 3.2
Upstream Author : W. Martin Borgert <[EMAIL PROTECTED]>
URL : http://people.debian.org/~debacle/refcard/
License : GPL-3
Programming Lang: XML (docbook-xsl, FO)
Description : printable reference card for the Debian system

The Debian GNU/Linux reference card provides new users help with
the most important commands. Basic knowledge of computers,
files, directories and the command line is required, however.
The package contains printable PDF files in multiple languages.



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

Re: Bug#463002: ITP: doomsday -- GPL licensed engine for classic doom, heretic, hexen and strife which provides updated 3d graphics and network gameplay

[Jon Dowland]

Hello,

On Mon, Jan 28, 2008 at 03:09:33PM -0500, Hash C. Borger wrote:
> * Package name: doomsday
>   Version : 1.9.0-beta5.2
>   Upstream Author : Jaakko Keränen <[EMAIL PROTECTED]>
> * URL : http://www.example.org/

?

Jamie Jones was working on doomsday packages, see
 for an old ITP (which was
opened originally by a third person entirely). He's also
part of the upstream team (I believe), although the URLs
for the packages seem to all be broken. It would be worth
trying to contact him and see if he's still got those on
the go.

We maintain a handful of doom packages in the debian games
team - see  for information
on the team. I wrote some packaging guidelines for
doom-related packages that I would ask you stuck to: the
current development version of these is at
.

If there's something in the doom packaging guidelines you
disagree with, please let us know :-) They're designed to
make sure all the doom packages play together nicely.

> * License : GPL
>   Programming Lang: C++
>   Description : GPL licensed engine for classic doom, heretic, hexen and 
> strife which provides updated 3d graphics and network gameplay

I'd suggest dropping heretic and hexen from the description
since the source for those bits is not distributable. I
think the strife implementation is from-scratch, however
the unavailability of free game data would mean that would
have to go into contrib.

How are you planning on dicing up the binaries?
 

-- 
Jon Dowland


signature.asc
Description: Digital signature

Re: debconf best practices: how to ask for a password?

[Adam Borowski]

On Tue, Jan 29, 2008 at 08:38:53PM +1100, Brian May wrote:
> > "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
> Joey> Francois Marier wrote:
> >> Now the problem (see bug #462658) is that if you ever put a non-empty
> >> password there, then, you can no longer get rid of it after
> >> dpkg-reconfiguring the package.  debconf seems to be ignoring empty 
> password
> >> fields and still returns the previous value.
> 
> Joey> This is a deficiency in debconf's UIs for prompting for password. 
> Since
> Joey> there's generally no sane way to display the old password as the 
> default
> Joey> and allow users to change it or delete the password entirely, 
> debconf
> Joey> instead displays no password, and if the user enters nothing, 
> assumes
> Joey> they meant to enter the old password unchanged.
> 
> This is really confusing UI. To me, as a user, it would appear there
> is no way of reusing the old password, and it would appear that
> pushing enter will result in the password being truncated. In fact
> this is what probably would happen if the system has forgotten the
> password entered for some reason (maybe it was never entered via
> debconf before).

What about this:
if there's a non-empty password, present the user with a magic value (8
stars, one star, "[old password]", etc).  If the debconf dialog returns the
magic value, keep the password unchanged.  If it's anything else (including
an empty value), use whatever is provided.

As long as no one tries to set the password to the magic value, this should
do the trick.


In an unrelated note, I have several users who haven't changed their
passwords after I set it to "Leave it empty".  Hey, it was them who said it
should be that way in the first place :p

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

${shlibs:Depends} results libfamin0 or libfam0?

[Andrew Lee]

Dear folks,

I am working on pcmanfm package. It has build-depends on 'libgamin-dev',
but somehow the binaries packages depends on 'libfam0'.

I checked 'libgamin-dev' depends on 'libgamin0', but I don't know why
the binaries packages are not depend on 'libgamin0'?

Both libfam0 and libgamin0 package provides libfam0, so libfam0 might be
correct dependency,

But upstream author is not recommended to use libfam0 with this package,
does anyone know what do to with this situation?

And I also found and libgamin0 package contains:
/usr/lib/libfam.so.0.0.0
/usr/lib/libgamin-1.so.0.1.9
/usr/lib/libfam.so.0
/usr/lib/libgamin-1.so.0

Not sure if this confused ${shlibs:Depends}?

PS. Also cc this to libgamin0 and libfam0 maintainers.

-Andrew


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

Re: How to cope with patches sanely

[Cyril Brulebois]

On 29/01/2008, Daniel Leidert wrote:
> svn-buildpackage is not a framework to create or edit patches. So how
> should it compare to quilt? It "merges" the contents of the
> .orig.tar.gz with the content in SVN and then it builds the package by
> using dpkg-buildpackage/debuild/pbuilder/pdebuild/sbuild/whatever.

From what you've described, it looks like you use dpatch to fetch the
content of the tarball and work on it. That is: sparing a “tar” call.

> Because I don't want to store the whole source in a VCS just to be
> able to maintain a package collaboratively. So quilt should be able to
> do the same for me dpatch does or it is not an alternative. I do not
> consider putting the whole source under VCS as an alternative - it
> increases space needs of the VCS and the checkout size - simply a
> waste of time and resources. Upstream normally has its own VCS to
> store the history of files. Why should we do this on e.g. svn.d.o too?
> If I want to have a look at the history of the file, I can take a look
> into upstreams VCS.

I'm only keeping debian/ under $VCS (svn for pkg-{games,python}, git for
all others) and I only have to invoke tar. uscan is my friend (and
probably later pristine-tar to get any version of the upstream tarball
easily).

Just call tar to extract the tarball, work on your patches using your
preferred patch management system, commit your patches in $VCS and
you're done.

> Yes, I like the debian/-only layout svn-buildpackage offers.

Me too… although you don't need *-buildpackage at all to achieve that.
tar is very sufficient.

-- 
Cyril Brulebois


pgp5U8emGfE2o.pgp
Description: PGP signature

Re: ${shlibs:Depends} results libfamin0 or libfam0?

[Colin Watson]

On Tue, Jan 29, 2008 at 06:30:47PM +0800, Andrew Lee wrote:
> I am working on pcmanfm package. It has build-depends on 'libgamin-dev',
> but somehow the binaries packages depends on 'libfam0'.
> 
> I checked 'libgamin-dev' depends on 'libgamin0', but I don't know why
> the binaries packages are not depend on 'libgamin0'?

You should find your answer in /var/lib/dpkg/info/libgamin0.shlibs. If
your binary (as in the ELF binary, as reported by ldd) links against
libfam, the package will end up with a dependency on libfam0; if your
binary links against libgamin-1, the package will end up with a
dependency on libgamin0.

> But upstream author is not recommended to use libfam0 with this package,
> does anyone know what do to with this situation?

If you want to force libgamin0, link against libgamin-1 explicitly.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: ${shlibs:Depends} results libfamin0 or libfam0?

[Marvin Renich]

* Andrew Lee <[EMAIL PROTECTED]> [080129 06:09]:
> Dear folks,
> 
> I am working on pcmanfm package. It has build-depends on 'libgamin-dev',
> but somehow the binaries packages depends on 'libfam0'.
> 
> I checked 'libgamin-dev' depends on 'libgamin0', but I don't know why
> the binaries packages are not depend on 'libgamin0'?
> 
> Both libfam0 and libgamin0 package provides libfam0, so libfam0 might be
> correct dependency,
> 
> But upstream author is not recommended to use libfam0 with this package,
> does anyone know what do to with this situation?
> 
> And I also found and libgamin0 package contains:
> /usr/lib/libfam.so.0.0.0
> /usr/lib/libgamin-1.so.0.1.9
> /usr/lib/libfam.so.0
> /usr/lib/libgamin-1.so.0
> 
> Not sure if this confused ${shlibs:Depends}?
> 
> PS. Also cc this to libgamin0 and libfam0 maintainers.
> 
> -Andrew
> 

As libgamin0 Conflicts, Replaces, and Provides libfam0, then unless
pcmanfm _requires_ some functionality that libgamin0 provides that
libfam0 does not, depending on libfam0 rather than libgamin0 looks
correct to me.

What is the reason upstream discourages using fam?  Is it just because
he thinks gamin is a better file monitoring package or is there a
stronger technical reason?  Does pcmanfm work with fam, but not quite as
well as with gamin?  If so, the the "Depends: gamin" should probably be
"Depends: gamin | fam".

However, apachetop switched from "Depends: gamin | fam" to "Depends:
gamin" and doodled switched from "Depends: fam" to "Depends: gamin".
Both of these packages are maintained by Daniel Baumann (cc'ed to bring
this thread to his attention, though I think he reads this list).

Daniel, what was the reasoning for these changes?  Also, most of the
dependencies on fam are Recommends or Suggests.  If a package depends on
libfam0, can't the Depends: gamin (or fam) be relaxed to a Recommends?

...Marvin


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

Re: How to cope with patches sanely

[David Nusinow]

On Tue, Jan 29, 2008 at 02:09:29PM +0100, Daniel Leidert wrote:
> > And to answer the original question, sure, quilt can handle it; as well as
> > any patch management system can handle the fact that the things you're
> > applying the patches against are external to the VCS and require rain dances
> > of one sort or another to facilitate patch editing.
> 
> http://www.wgdd.de/?p=25 is some sort of "rain dance"? Oh well, are you
> kidding me? All I want to know is, if quilt can do the same. Then I will
> give it a try. If it cannot handle this design, well then it's not an
> alternative for me. Why should I mirror the upstream VCS and blow up
> svn.d.o or my own VCS servers?

That link is fairly complicated in comparison to any scheme I've ever used,
so yes, I'd personally say that Steve's characterization is accurate. Many
of us just have to clone/checkout the sources as you would any other and
start working.

At any rate, the quilt scripting does not have any special hooks to grab
external .orig.tar.gz's. This should be trivial to script if you really
want it, but doesn't svn-buildpackage or whatever it is people are using
these days to do this sort of thing provide a way to get it anyhow?  Why do
you need quilt to do it for you?

 - David Nusinow


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

ITP: basic256 -- Educational BASIC programming environment for children

[Ryan Kavanagh]

Package: wnpp
Severity: wishlist
Owner: Ryan Kavanagh <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: basic256
  Version : 0.9.2
  Upstream Author : Ian Larsen <[EMAIL PROTECTED]>
* URL : http://kidbasic.sourceforge.net/
* License : GPL
  Programming Lang: LEX, Qt, FLACC
  Description : Educational BASIC programming environment for children

 BASIC-256 is an easy to use version of BASIC designed to teach young 
children
 the basics of computer programming. It uses traditional control 
structures

 like gosub, for/next, and goto, which helps kids easily see how program
 flow-control  works. It has a built-in graphics mode which lets them draw
 pictures on screen  in minutes, and a set of detailed, easy-to-follow
 tutorials that introduce programming concepts through fun exercises.



- -- System Information:
Debian Release: lenny/sid
  APT prefers hardy-updates
  APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 
'hardy')

Architecture: i386 (i686)

Kernel: Linux 2.6.24-4-generic (SMP w/1 CPU core)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

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

iQIVAwUBR58iK4r19KKMGstXAQJbyw//b6DZxMkxiFKqKOuOwL7LT3e13LjsU/QK
/qQmmeEeMiHPAA0aCbWKLT1VRrYoB4MJu9sHux0B1829zqwaw09CbW9I+mb715hi
gumS/iFR2VblTrjetyU7Z3Bf7ovovuqFwP17eRWjqwOgjlJCXtVPC7ebJaa50dm3
5m4fwTp0IUohcItqQJtBl6+Ly4QzjI8C075RNP0NPTFnLuE2gJh71eX1eWAi9GDh
1wt76Yb/NE1SyNPi2VR5+9RzLOPLvdhONHT/WGpRYFr8pJUiB4nhbgxJJ4Z1iHAz
RChcu2swCRfhDibtKBHsYVmsLmbfnHT4RZ4TF9l5xnGr+ml8+nU0MGNrfx3YvcQT
3q8WuqiX8O/1YGHaEGHlOnQ2MtrpCg0U+9R9PnPMBHUNvFnK8ZXwsMFwG4lYMUNA
fgpFLGF0LN5WlImnrc0FVjNsjPAQQSBBvt46bYsisJak7Ryt4kscThvG5lyn9Fr3
y64RjabfiJU3TcRvHhGpqomQpQD8CmvfOPymcBmC7OCGpggdqFlz5IVT88ztT9d2
7YI1pualZqLLNM6mDORyxajmhXsWQxD4A0dEC4yp0NZilfVT3gFgojW7oXEeHCWx
K/hC0tUX4MJPpODVzgOB/0hK6MNUMAabUdSGMMcWYArj4FRxLPhEwTrkUhmWgMNK
e8EZuNUjuCM=
=ZPEy
-END PGP SIGNATURE-


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

Re: How to cope with patches sanely

[Frank Lichtenheld]

On Mon, Jan 28, 2008 at 05:45:24PM -0800, Russ Allbery wrote:
> Clint Adams <[EMAIL PROTECTED]> writes:
> > I agree with Lars that we should move toward requiring it to work.
[...]
> I just don't know what's involved in finally deciding on something like
> this and making it happen.  We've been having this discussion for years,
> and so far we've not made a lot of forward progress.  :/

Because nobody sat down and wrote some fucking code for it...

IME discussing code always works better than discussing specifications.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Re: How to cope with patches sanely

[sean finney]

hi,

On Tuesday 29 January 2008 02:38:07 pm David Nusinow wrote:
> At any rate, the quilt scripting does not have any special hooks to grab
> external .orig.tar.gz's. This should be trivial to script if you really
> want it, but doesn't svn-buildpackage or whatever it is people are using
> these days to do this sort of thing provide a way to get it anyhow?  Why do
> you need quilt to do it for you?

the thing you want is /usr/share/svn-buildpackage/contrib/svn-do.  i 
personally have it moved into $PATH and use it for my quilt-and-svn-using 
packages, such as php, and it works quite nicely.

i'd argue that's it's somewhat backwards to expect a patch management system 
like dpatch or quilt to perform this task, and really it should be the 
responsibility of the vcs or vcs-wrapper tools.


sean


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

Re: How to cope with patches sanely

[Daniel Leidert]

Am Dienstag, den 29.01.2008, 08:38 -0500 schrieb David Nusinow:
> On Tue, Jan 29, 2008 at 02:09:29PM +0100, Daniel Leidert wrote:
> > > And to answer the original question, sure, quilt can handle it; as well as
> > > any patch management system can handle the fact that the things you're
> > > applying the patches against are external to the VCS and require rain 
> > > dances
> > > of one sort or another to facilitate patch editing.
> > 
> > http://www.wgdd.de/?p=25 is some sort of "rain dance"? Oh well, are you
> > kidding me? All I want to know is, if quilt can do the same. Then I will
> > give it a try. If it cannot handle this design, well then it's not an
> > alternative for me. Why should I mirror the upstream VCS and blow up
> > svn.d.o or my own VCS servers?
> 
> That link is fairly complicated in comparison to any scheme I've ever used,

I don't know the needs of X.org package maintenance.

> so yes, I'd personally say that Steve's characterization is accurate.

Ok, so JFTR: I do not agree to Steves characterization.

> Many
> of us just have to clone/checkout the sources as you would any other and
> start working.

There is not much difference. You just need a proper dpatch setup ad
the .orig.tar.gz. I don't think, the latter is a problem for package
maintainers. And about the proper dpatch setup: Well, I blogged about
how to set a general path to the .orig.tar.gz. The definition of
PACKAGENAME and UPSTREAMVERSION was necessary, because the dpatch
scripts determined these variables too late, so I had to set them
earlier (in the config file). If the situation changed, the whole config
file would look like this (for me):

  .dpatch.conf 
/
conf_origtargzpath="/usr/local/src/packages/${PACKAGENAME}"
\__


Defining a legal variable in a config file is a "rain dance"?

> At any rate, the quilt scripting does not have any special hooks to grab
> external .orig.tar.gz's. This should be trivial to script if you really
> want it, but doesn't svn-buildpackage or whatever it is people are using
> these days to do this sort of thing provide a way to get it anyhow?

svn-buildpackage is not a framework to create or edit patches. So how
should it compare to quilt? It "merges" the contents of the .orig.tar.gz
with the content in SVN and then it builds the package by using
dpkg-buildpackage/debuild/pbuilder/pdebuild/sbuild/whatever.

> Why do you need quilt to do it for you?

Because I don't want to store the whole source in a VCS just to be able
to maintain a package collaboratively. So quilt should be able to do the
same for me dpatch does or it is not an alternative. I do not consider
putting the whole source under VCS as an alternative - it increases
space needs of the VCS and the checkout size - simply a waste of time
and resources. Upstream normally has its own VCS to store the history of
files. Why should we do this on e.g. svn.d.o too? If I want to have a
look at the history of the file, I can take a look into upstreams VCS.

Yes, I like the debian/-only layout svn-buildpackage offers.

Regards, Daniel


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

Re: Standard to indicate repacking in version numbers?

[Felipe Sateler]

Russ Allbery wrote:


> I don't see any reason not to put it in debian/copyright no matter how
> long it is.  It's not like the length of a text explanation, even if
> complex, is going to be a serious problem.
> 
> However, ideally the steps should be *automated* and put into debian/rules
> get-orig-source, in which case you don't have to give detailed steps in
> either location and can simply refer to the automated procedure in
> debian/rules get-orig-source, which if used by the maintainer also has the
> benefit of being tested.

While get-orig-source gives the steps used to repack it, it does not give the
rationale behind those steps. A text explanation of why you repacked is still
necessary. 


-- 

  Felipe Sateler


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

Re: How to cope with patches sanely

[Josselin Mouette]

Le mardi 29 janvier 2008 à 14:09 +0100, Daniel Leidert a écrit :
> http://www.wgdd.de/?p=25 is some sort of "rain dance"? Oh well, are you
> kidding me? All I want to know is, if quilt can do the same. Then I will
> give it a try. If it cannot handle this design, well then it's not an
> alternative for me. Why should I mirror the upstream VCS and blow up
> svn.d.o or my own VCS servers?

The easiest way I found to manage quilt patches with SVN in
mergeWithUpstream mode is to extract the tarball in a temporary
directory and to link the debian/ directory from the SVN repository. All
modifications made to the quilt series are then done directly in the
checkout. Of course, this is easily scriptable.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


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

Re: How to cope with patches sanely

[Daniel Leidert]

Am Montag, den 28.01.2008, 16:44 -0800 schrieb Steve Langasek: 
> On Mon, Jan 28, 2008 at 07:26:41PM -0500, David Nusinow wrote:
> > On Mon, Jan 28, 2008 at 04:54:47PM +0100, Daniel Leidert wrote:

[standardize on quilt?] 
> > > A question that comes up again and again is, if quilt can handle
> > > debian-only VCS layouts? Is it able to handle this layout?
> 
> > What exactly is a debian-only VCS layout? Just the debian directory?

Yes. I normally use svn-buildpackage in mergeWithUpstream mode and
prefer to not put the complete source under VCS and instead put it into
the build-directory. dpatch can easily handle this design and I can
create and edit patches from my VCS, even if it does not contain the ?MB
source of the package.

> Yes.
> 
> And to answer the original question, sure, quilt can handle it; as well as
> any patch management system can handle the fact that the things you're
> applying the patches against are external to the VCS and require rain dances
> of one sort or another to facilitate patch editing.

http://www.wgdd.de/?p=25 is some sort of "rain dance"? Oh well, are you
kidding me? All I want to know is, if quilt can do the same. Then I will
give it a try. If it cannot handle this design, well then it's not an
alternative for me. Why should I mirror the upstream VCS and blow up
svn.d.o or my own VCS servers?

Daniel


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

Re: How to cope with patches sanely

[Raphael Hertzog]

On Mon, 28 Jan 2008, Russ Allbery wrote:
> > I agree with Lars that we should move toward requiring it to work.
> 
> What I'd like to see is a Debian source package format that supports
> essentially quilt metadata -- in other words, a series file and a set of
> patches.  It's a very minor addition to the current format, and I think
> it's very close to the intention of wig&pen.
> 
> With that source package format, everyone using quilt or simple-patchsys
> can trivially satisfy this requirement, and most uses of dpatch are
> similarly trivial.  It doesn't provide all of the power of a git or bzr
> package format, but it's a lot easier to implement and I would hope easier
> to get consensus on.
> 
> I just don't know what's involved in finally deciding on something like
> this and making it happen.  We've been having this discussion for years,
> and so far we've not made a lot of forward progress.  :/

I just need a clear concept that I can try to implement.

Some questions/problems:

1/ it seems that we agree that patches should be applied by default
during unpack of the source archive. This means that dpkg-source might
want to know which patches are currently applied (or we could get strange
results while building the package with patches unapplied)... do we use
the same format than quilt for that (.pc directory AFAIK)?

2/ What should happen in Lars' scenario ? I suggest that dpkg compares the
tree with the theoretical tree (orig+patches) and creates one patch more
that it adds at the end of the patch serie. It would be auto-named
"debian-upload-" (so that it can be auto-replaced if the same
package is built several times in a row during tests for example). 
(We could maybe even have some mechanism so that NMU uploads do not change
the -debian_.tar.gz but instead push the changes affecting the
debian directory in that auto-generated patch too)

This shouldn't be too difficult to implement. The interesting part is
also providing support to generate that patch series using a VCS.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: How to cope with patches sanely

[Raphael Hertzog]

On Tue, 29 Jan 2008, Russ Allbery wrote:
> I wouldn't worry about any metadata at all; dpkg-source would just apply
> all the patches in the series file (or, really, we could just script a
> conversion from quilt to wig&pen by appending arbitrary numbers to the
> patches based on the series file and omitting patches not listed in
> series).
> 
> If someone wants to work on the tree with quilt, then rather than using
> dpkg-source -x they should use dpkg-quilt-unpack or some similar script
> yet to be written that would create a series file, stick the patches in
> debian/patches or some other likely location, and untar only the virgin
> tarball.

This seems less than ideal to me. If we want to avoid proliferation of patch
management system, I'd rather integrate some of those functionalities in
dpkg-dev proper. IMO we need at least some building blocks (API?) so that
VCS-based package management tools can easily integrate (new) patches in
the Debian source package (or define the whole patch series for that
matter).

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: Introducing security hardening features for Lenny

[Pierre Habouzit]

On Tue, Jan 29, 2008 at 09:48:43PM +, William Pitcock wrote:
> On Tue, 2008-01-29 at 22:37 +0100, Pierre Habouzit wrote:
> > On Tue, Jan 29, 2008 at 09:16:24PM +, Moritz Muehlenhoff wrote:
> > > Fortify Source
> > > ==
> > > 
> > > This feature adds validation for internal C functions such as strcpy
> > > for buffer sizes known during compile time. While vulnerabilities in
> > > the functions it protects have become uncommon in high-profile apps,
> > > it will be useful for fringe packages we have in the archive.
> > > 
> > > This feature is present in glibc since version 2.5, and is enabled
> > > through the use of "-D_FORTIFY_SOURCE=2" and "-O2" or higher.
> > > 
> > 
> >   Well, -D_FORTIFY_SOURCE=2 is a severe performance loss in many
> > applications, and I wouldn't recommend activating it by default. =1 has
> > not the drawback with that regard though, but is less useful security
> > wise (though it catch many programmatic issues, and full archive rebuild
> > with -D_FORTIFY_SOURCE=1 would be worthwile independently of this).
> > 
> 
> Out of curiosity, what applications in particular does
> -D_FORTIFY_SOURCE=2 cause issues in? It may be worthwhile to profile
> this feature and correct it's behaviour if the performance loss is that
> big of a deal.

  Basically any application that uses memcpy/memmove and some other
common  functions heavily.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpAAJDLbEy4p.pgp
Description: PGP signature

Re: How to cope with patches sanely

[Russ Allbery]

Raphael Hertzog <[EMAIL PROTECTED]> writes:

> This seems less than ideal to me. If we want to avoid proliferation of
> patch management system, I'd rather integrate some of those
> functionalities in dpkg-dev proper. IMO we need at least some building
> blocks (API?) so that VCS-based package management tools can easily
> integrate (new) patches in the Debian source package (or define the
> whole patch series for that matter).

Well, assuming that you're not anticipating people would use tools in
dpkg-dev instead of a patch management system, we're talking about
defining an export format that can be generated from a given patch
management system or VCS.  Ideally, the results should be importable into
a patch management system (including a different one than the originator
started with).  Importing into a VCS doesn't make a lot of sense beyond
the obvious (each patch as a separate commit); if you want to use the full
VCS, you really want to just clone the upstream repository.

So, we need a bijective translation that doesn't lose information, but I
don't see dpkg-dev filling the role of the patch management system
itself.  In other words, I should be able to go to a quilt-managed tree of
source and patches to a Debian source package and back again, but I don't
expect to have tools in dpkg-dev that do the equivalent of quilt import or
quilt edit or quilt fold.

Either using a source format that consists of the original tarball, a set
of patches, and a series file, or a source format that consists of the
original tarball and a set of numbered patches should work for this.  It's
pretty trivial to write a tool that converts to and from quilt format for
either of those layouts, and to work on that source without using quilt at
all.

The tricky part, as you mention, is what to do with modifications made
without a patch system on top of a source package that uses patches.  I
think you've already described the obvious thing to do: take all the
additional modifications and turn them into another patch, placed at the
end of the patch series.  The trick is finding the additional
modifications.  If you have the original source package, you can always
use the brute force approach, but it probably would be better to stash
enough information so that one can reconstruct the original patched tree
and diff.

Note that the quilt format may not be a reasonable way of storing that
information.  quilt essentially stores, for each applied patch, a backup
of every file affected by that patch before the patch was applied in the
.pc directory.  That means that quilt doesn't have enough information to
build a patch out of new modifications unless you tell quilt which files
you're going to edit so that it can stash a backup file that it can diff
later.  If you aren't going to tell some system which files you're editing
before you edit them, you need to either keep the original source tarball
plus patches around to rebuild the original tree or otherwise keep a copy
of the original unpacked tree in its entirety.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#462975: ITP: kde4-style-qtcurve -- This is a set of widget styles for KDE4 based apps

[Fathi Boudra]

Have you contacted kde-style-qtcurve maintainer ?
Maybe he planned to continue to maintain kde-style-qtcurve also for KDE4 ...

cheers,

Fathi


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

Re: Sources of dak ?

[Raphael Hertzog]

Hello,

On Mon, 28 Jan 2008, Roger Leigh wrote:
> On Sun, Jan 27, 2008 at 09:08:44AM +0100, Martin Zobel-Helas wrote:
> > http://ftp-master.debian.org/bzr/
> 
> Why isn't this on bzr.debian.org?

Probably for the same reason that DSA tools are not on bzr.debian.org
either (but on db.debian.org). It limits the risk of compromission since
ftp-master is restricted (while alioth is a widely used machine).

And since bzr is a distributed VCS, it's not a big problem.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: Correct spelling/capitalisation of project names

[Russ Allbery]

Andrew Vaughan <[EMAIL PROTECTED]> writes:
> On Monday 21 January 2008 07:45, Russ Allbery wrote:

>> glib is a regular English word, so I'll leave that one off in fear of
>> false positives.  I now have the rest.

> Whilst glib is an English word, it's not a word that's likely to be used
> in package descriptions.

True, and there are none currently.  Maybe I'll go ahead and add it
anyway.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: List of packages defining a RPATH on amd64 (differs from i386/lintian.d.o)

[Filippo Giunchedi]

On Mon, Jan 07, 2008 at 10:02:17PM -0600, Raphael Geissert wrote:
> Filippo Giunchedi <[EMAIL PROTECTED]>
>bluez-cups (U)
>bluez-utils (U)

fixed in unstable

>libbtctl4 (U)
>python-libbtctl (U)
> 
> Filippo Giunchedi <[EMAIL PROTECTED]>
>gnome-bluetooth (U)
>libgnomebt0 (U)

will fix in the next upload

thanks,
filippo
--
Filippo Giunchedi - http://esaurito.net
PGP key: 0x6B79D401
random quote follows:

It's not that I'm afraid to die, I just don't want to be there
when it happens.
-- Woody Allen


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

Re: Correct spelling/capitalisation of project names

[Andrew Vaughan]

On Monday 21 January 2008 07:45, Russ Allbery wrote:
> Josselin Mouette <[EMAIL PROTECTED]> writes:
> > Le mercredi 09 janvier 2008 à 11:19 +0100, Stefano Zacchiroli a écrit :
> >> Regarding the list above I would guess that what you want is something
> >> like the following:
> >>
> >> * glib -> GLib
> >
> >   * Glib -> GLib
>
> glib is a regular English word, so I'll leave that one off in fear of
> false positives.  I now have the rest.
Whilst glib is an English word, it's not a word that's likely to be used in 
package descriptions.  

Andrew

Re: electronics-menu REJECTED (discussion)

[Andrew Vaughan]

[Sorry for the late reply]
On Wednesday 16 January 2008 08:18, Hamish Moffatt wrote:
> >>
> >> It appears that the Technical menu should include at least;
> >> - Science
> >> - Engineering
> >> - Math
> >> - HamRadio
> >> - Electronics
[snip]
> I thought that Science fit under Technical, if the offer was for
> one additional main menu. However it's clearly big enough to have its
> own main menu (there are lots of Science sub-categories in the
> standard).
>
> Math is an interesting case in that it's obviously a science, yet the
> tools are also used in engineering and also education. Hence your point
> about different user views. (On the other hand, putting everything under
> Technical helps too :)).
>
As a user technical seems awkward and unintuitive to me.  I would rather it 
was called Science and Engineering.  

Andrew V


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

Re: Standard to indicate repacking in version numbers?

[Russ Allbery]

Felipe Sateler <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:

>> However, ideally the steps should be *automated* and put into
>> debian/rules get-orig-source, in which case you don't have to give
>> detailed steps in either location and can simply refer to the automated
>> procedure in debian/rules get-orig-source, which if used by the
>> maintainer also has the benefit of being tested.

> While get-orig-source gives the steps used to repack it, it does not
> give the rationale behind those steps. A text explanation of why you
> repacked is still necessary.

Sure.  And that should go into debian/copyright, IMO.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: How to cope with patches sanely

[Russ Allbery]

Raphael Hertzog <[EMAIL PROTECTED]> writes:

> 1/ it seems that we agree that patches should be applied by default
> during unpack of the source archive. This means that dpkg-source might
> want to know which patches are currently applied (or we could get
> strange results while building the package with patches unapplied)... do
> we use the same format than quilt for that (.pc directory AFAIK)?

It would be ideal for quilt users, but I don't think it's necessary.
We're going to need to script the conversion from a quilt-managed tree to
a Debian source package and vice versa anyway, so I wouldn't put a lot of
effort into making dpkg-source produce a quilt tree.

I wouldn't worry about any metadata at all; dpkg-source would just apply
all the patches in the series file (or, really, we could just script a
conversion from quilt to wig&pen by appending arbitrary numbers to the
patches based on the series file and omitting patches not listed in
series).

If someone wants to work on the tree with quilt, then rather than using
dpkg-source -x they should use dpkg-quilt-unpack or some similar script
yet to be written that would create a series file, stick the patches in
debian/patches or some other likely location, and untar only the virgin
tarball.

> 2/ What should happen in Lars' scenario ? I suggest that dpkg compares
> the tree with the theoretical tree (orig+patches) and creates one patch
> more that it adds at the end of the patch serie. It would be auto-named
> "debian-upload-" (so that it can be auto-replaced if the same
> package is built several times in a row during tests for example).  (We
> could maybe even have some mechanism so that NMU uploads do not change
> the -debian_.tar.gz but instead push the changes affecting
> the debian directory in that auto-generated patch too)

That sounds perfect.

> This shouldn't be too difficult to implement. The interesting part is
> also providing support to generate that patch series using a VCS.

I can conceptually see how to do it with git given a set of feature
branches and an ordering, so it should be possible to work through.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Introducing security hardening features for Lenny

[Pierre Habouzit]

On Tue, Jan 29, 2008 at 09:16:24PM +, Moritz Muehlenhoff wrote:
> Fortify Source
> ==
> 
> This feature adds validation for internal C functions such as strcpy
> for buffer sizes known during compile time. While vulnerabilities in
> the functions it protects have become uncommon in high-profile apps,
> it will be useful for fringe packages we have in the archive.
> 
> This feature is present in glibc since version 2.5, and is enabled
> through the use of "-D_FORTIFY_SOURCE=2" and "-O2" or higher.
> 

  Well, -D_FORTIFY_SOURCE=2 is a severe performance loss in many
applications, and I wouldn't recommend activating it by default. =1 has
not the drawback with that regard though, but is less useful security
wise (though it catch many programmatic issues, and full archive rebuild
with -D_FORTIFY_SOURCE=1 would be worthwile independently of this).



pgp9nVbroP9o8.pgp
Description: PGP signature

Re: Introducing security hardening features for Lenny

[John Goerzen]

On Tue January 29 2008 3:16:24 pm Moritz Muehlenhoff wrote:

> Scope of this proposal
> ==
>
> The target for Lenny is to enable these features in all applications
> with potential security impact, specifically:
>
> - Your application is written in C / C++
> - If your package was subject to a DSA in the recent years
> - If your package parses files from untrusted sources
> - If your package communicates over a network

I am very glad to see what you have been proposing so far.  This is a great 
start.

However, I am concerned that is appears to be limited in scope to packages 
that:

 * Are written in C or C++

 * Can have hardening achieved through technical changes to the build process

I think it is important to remember that other languages can have security 
problems too, perhaps just as easy as these (shell).  Also there seems to be 
a bloat recently of the number of daemons running on the average Debian 
system.  It seems to be just about impossible to have a desktop with sid 
without having avahi, dbus, hal, etc, etc, etc. running.  How secure do we 
feel about all of this?  I notice, for instance, that the latest cups 
requires avahi.  Can we build it without that and install it without that by 
default for those that don't need it, to eliminate Yet Another Daemon?


-- John


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

Re: Introducing security hardening features for Lenny

[William Pitcock]

On Tue, 2008-01-29 at 22:37 +0100, Pierre Habouzit wrote:
> On Tue, Jan 29, 2008 at 09:16:24PM +, Moritz Muehlenhoff wrote:
> > Fortify Source
> > ==
> > 
> > This feature adds validation for internal C functions such as strcpy
> > for buffer sizes known during compile time. While vulnerabilities in
> > the functions it protects have become uncommon in high-profile apps,
> > it will be useful for fringe packages we have in the archive.
> > 
> > This feature is present in glibc since version 2.5, and is enabled
> > through the use of "-D_FORTIFY_SOURCE=2" and "-O2" or higher.
> > 
> 
>   Well, -D_FORTIFY_SOURCE=2 is a severe performance loss in many
> applications, and I wouldn't recommend activating it by default. =1 has
> not the drawback with that regard though, but is less useful security
> wise (though it catch many programmatic issues, and full archive rebuild
> with -D_FORTIFY_SOURCE=1 would be worthwile independently of this).
> 

Out of curiosity, what applications in particular does
-D_FORTIFY_SOURCE=2 cause issues in? It may be worthwhile to profile
this feature and correct it's behaviour if the performance loss is that
big of a deal.

William


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

Re: Introducing security hardening features for Lenny

[Moritz Muehlenhoff]

Pierre Habouzit wrote:
>> Fortify Source
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>=20
>> This feature adds validation for internal C functions such as strcpy
>> for buffer sizes known during compile time. While vulnerabilities in
>> the functions it protects have become uncommon in high-profile apps,
>> it will be useful for fringe packages we have in the archive.
>>=20
>> This feature is present in glibc since version 2.5, and is enabled
>> through the use of "-D_FORTIFY_SOURCE=3D2" and "-O2" or higher.
>>=20
>
>   Well, -D_FORTIFY_SOURCE=3D2 is a severe performance loss in many
> applications, and I wouldn't recommend activating it by default. =3D1 has
> not the drawback with that regard though, but is less useful security
> wise (though it catch many programmatic issues, and full archive rebuild
> with -D_FORTIFY_SOURCE=3D1 would be worthwile independently of this).

There are certainly performance trade-offs involved and the final
selection of features will depend on the testing of the respective
maintainers (testing should be eased by hardening-wrapper).

hardening-wrapper makes it simple to enable/disable selective single
features, if anyone wants to run specific benchmarks on the overhead,
please post them to the Wiki.

We're mostly trying to bootstrap a discussion here, the details on
how to put this into effect archive-wide will depend heavily on the
toolchain configuration proposal by Matthias Klose. Maybe "classes"
of security-sensitivity of applications can be defined, which specify
a set of selected options.

Cheers,
Moritz


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

Bug#463167: ITP: dsyslog -- a dumb syslog

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock <[EMAIL PROTECTED]>

Hi,

I am writing a syslog daemon called dsyslog. Why you ask? Because none 
of the other syslogd's were designed in the way that I would like, so I 
figured I would do it myself.

* Package name: dsyslog
  Version : 0.1.0
  Upstream Author : William Pitcock <[EMAIL PROTECTED]>
* URL : http://nenolod.net/dsyslog
* License : ISC (BSD-like)
  Programming Lang: C
  Description : a dumb syslog
 dsyslog is a dumb, yet advanced syslog daemon, which supports infinite
 rules and expandability through it's purely modular design. The default
 configuration is a drop in replacement for syslogd.

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

Kernel: Linux 2.6.22-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: Introducing security hardening features for Lenny

[sean finney]

hi moritz,

On Tuesday 29 January 2008 10:16:24 pm Moritz Muehlenhoff wrote:
> A group of people have been working on introducing advanced security
> hardening features into our archive:
> http://alioth.debian.org/projects/hardening/
>
> We recommend to activate the following features in individual packages
> for now and discuss how to enable them system-wide later. (Matthias
> Klose proposed a mechanism in debian-devel, which could be used for
> it: http://lists.debian.org/debian-devel/2007/12/msg00090.html).
>
> Some maintainers have already pro-actively enabled these features,
> e.g. in the sendmail and openssh packages, but we're heading for
> full archive coverage now.

i guess you're aware of the discussions going on with ubuntu-devel as well?

https://lists.ubuntu.com/archives/ubuntu-devel/2008-January/024958.html

(and further posts where some implementation details are debated)

I have to repeat the question that tfheen asked on that list... why 
DEB_BUILD_HARDENING=1, and not DEB_BUILD_OPTS=hardening (thus the same as 
nostrip,noopt,etc).

otherwise, bravo for the effort!


sean


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

Re: Introducing security hardening features for Lenny

[Thomas Bushnell BSG]

On Tue, 2008-01-29 at 23:31 +0100, Moritz Muehlenhoff wrote:
> Pierre Habouzit wrote:
> There are certainly performance trade-offs involved and the final
> selection of features will depend on the testing of the respective
> maintainers (testing should be eased by hardening-wrapper).

What bothers me is that this kind of analysis should have preceded your
announcement.

I think that hardening is extremely important, but it is not the only
important thing.  It would be very helpful if your team would consider
thinking about the tradeoffs, describing them so people can make some
judgments.  But that's not what you did: you instead posted a note,
designed to sound as official as possible, asking every maintainer to
add these flags.

That's not right!  We should instead discuss it.

> We're mostly trying to bootstrap a discussion here, the details on
> how to put this into effect archive-wide will depend heavily on the
> toolchain configuration proposal by Matthias Klose. Maybe "classes"
> of security-sensitivity of applications can be defined, which specify
> a set of selected options.

For my money, you blew it.  You don't bootstrap a discussion by
presenting a pseudo-official email like the one you posted.  But we can
get back to that discussion: cancel the email by saying "whoops, we're
not ready yet" and then having the discussion first.

Thomas



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

Re: Introducing security hardening features for Lenny

[Pierre Habouzit]

On Tue, Jan 29, 2008 at 10:31:48PM +, Moritz Muehlenhoff wrote:
> There are certainly performance trade-offs involved and the final
> selection of features will depend on the testing of the respective
> maintainers (testing should be eased by hardening-wrapper).

  I understand. To be fair, I'm worried in the implications of the SSP,
FORTITY_SOURCES and PIE proposals. Others looks fine, but those three
may have very important performance issues embedded.

* SSP has a cost proportional to the number of calls an application
  performs (If I'm correct), which in CPU intensive tasks may become an
  issue.
* FORTITY_SOURCES=2 checks memcpy and memmove, though other functions it
  checks should just not be used and applications beeing too slow
  because of them should just be shot down.
* PIE is just IMHO not an option on x86 :/

  Though probably someone should come up with some benchmarks. The usual
culprits (multimedia libraries, html renderers, xml processors, …) all
provide easily deployed bench, and before we go any further I'd like to
see some numbers.

  If it's say less than a percent, okay I'm all for it. If we have more
than 10% performance losses because of that, then we implicitely ask our
users to sometimes buy faster machines (I know many people having
installations where their multimedia player eats 80% CPU while decoding
a film because they run it on old hardware, we may just kill this kind
of use, and I would be sorry).

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpmkWRVZqdd3.pgp
Description: PGP signature

Re: Introducing security hardening features for Lenny

[Yves-Alexis Perez]

On mar, 2008-01-29 at 15:47 -0600, John Goerzen wrote:
> I notice, for instance, that the latest cups 
> requires avahi.  Can we build it without that and install it without
> that by 
> default for those that don't need it, to eliminate Yet Another Daemon?

You do know that it depends on the lib, not the daemon?
-- 
Yves-Alexis


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

The 30 most popular packages missing in Debian

[Petter Reinholdtsen]

One of the lists from popcon.debian.org I find most interesting, is
the list of popular packages currently missing in Debian,
http://popcon.debian.org/unknown/by_vote>.  I understand it to
list the packages our users would love to find in Debian, but which
are currently missing.  Some are missing because we can't legally
distribute them, others are missing because no-one is willing to
maintain them in the Debian repositories, while others again are
obsolete and used to be part of Debian.

This is the top 30 list, sorted by vote (aka include files
read/executed last week):

#rank nameinst  vote   old recent no-files
1 skype   5678  3020  2273   380 5
2 acroread-debian-files   4151  2585  1144   421 1
3 opera   3817  2267  1204   341 5
4 lame7859  2045  5125   686 3
5 transcode   5025  1859  2158  1007 1
6 realplayer  3077  1679  1140   18276
7 virtualbox  2032  1458   374   198 2
8 mencoder6064  1432  3678   951 3
9 mjpegtools  5491  1234  3600   656 1
10emerald 2241  1079   820   342 0
11dvdrip  2386   791  1351   242 2
12libnl1-pre8 1390   782 0 9   599
13avidemux2471   657  1008   804 2
14mythtv-backend   824   656   12642 0
15libevent-execflow-perl  2570   625  1709   234 2
16beryl-manager   1369   592   71163 3
17nxserver 834   578   1933924
18beryl-core  1604   570   96469 1
19adobereader-enu  762   537   16162 2
20nxclient1259   500   655   100 4
21pine 944   487   42928 0
22w32codecs   9231   466   578   118  8069
23googleearth 1078   461   53680 1
24mythtv-frontend  998   433   419   146 0
25subtitleripper  2091   431  1416   243 1
26fusion-icon  849   421   184   244 0
27linux-image-2.6.22-2-6863842   406  32958655
28sun-j2sdk1.5 824   406   35757 4
29gtk2-ex-formfactory-perl2585   397  1939   247 2
30anyevent-perl   2581   393  1906   279 3

I wish all the packages we could distribute on this list was included
in Debian.  I believe it would make the life of our users a little
easier.

Package related to Multimedia, PDF and 3D stuff seem to be popular
while missing in Debian. :)

Happy hacking,
-- 
Petter Reinholdtsen
One of the popularity-contest maintainers


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

Re: Introducing security hardening features for Lenny

[Moritz Muehlenhoff]

Thomas Bushnell BSG wrote:
> For my money, you blew it.  You don't bootstrap a discussion by
> presenting a pseudo-official email like the one you posted.  But we can
> get back to that discussion: cancel the email by saying "whoops, we're
> not ready yet" and then having the discussion first.

Of course we've discussed this in depth internally before before
proposing it and there was no intention to make it sound "official".
There is no need to become aggressive.

To resolve potential confusions I've sent a clarifying followup.

Cheers,
Moritz





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

Re: The 30 most popular packages missing in Debian

[Sebastian Pipping]

* Would non-free be an option to all or some of them?
  Do we have binary only packages in Debian?

* A mapping to current ITPs might be interesting.
  (Integration into http://wnpp.debian.net/)



Sebastian


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

Re: Introducing security hardening features for Lenny

[Moritz Muehlenhoff]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Moritz Muehlenhoff wrote:

> The Debian archive is the biggest of all distributions and although
> there's security support for all security issues being found, there's
> still room for improvement and a need for increased resilience against
> flaws not yet discovered.
>
> A group of people have been working on introducing advanced security
> hardening features into our archive:
> http://alioth.debian.org/projects/hardening/
>
> We recommend to activate the following features in individual packages
> for now and discuss how to enable them system-wide later. (Matthias
> Klose proposed a mechanism in debian-devel, which could be used for
> it: http://lists.debian.org/debian-devel/2007/12/msg00090.html).

Concern was voiced that this proposal may sound like a call to maintainers
to enable all these features directly. This was not our intention. At this
point we mostly want to introduce the available solutions. Whether there
will be an archive-wide global pre-selection of features and with which
features will of course depend on the testing of the respective maintainers
and discussions on debian-devel. Please participate in the discussion
if you're intested in that matter.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHn7KTXm3vHE4uyloRAommAJwKyNlc4B/+Gkc8SsY4EuIoP3WzAACeN4XL
Tych5TntCEobLJH+fKttpiI=
=l7DO
-END PGP SIGNATURE-


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

Re: Introducing security hardening features for Lenny

[Thomas Bushnell BSG]

On Wed, 2008-01-30 at 00:21 +0100, Moritz Muehlenhoff wrote:
> Thomas Bushnell BSG wrote:
> > For my money, you blew it.  You don't bootstrap a discussion by
> > presenting a pseudo-official email like the one you posted.  But we can
> > get back to that discussion: cancel the email by saying "whoops, we're
> > not ready yet" and then having the discussion first.
> 
> Of course we've discussed this in depth internally before before
> proposing it and there was no intention to make it sound "official".
> There is no need to become aggressive.

I'm sorry for my tone.

I know that it was discussed internally; but what I mean is that it
needs to be discussed externally as the next step, long before it
becomes the expected practice.

If there were not important trade-offs, then it wouldn't matter, but the
problem is that some of these options do impose significant costs.

Thomas



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

Re: Introducing security hardening features for Lenny

[brian m. carlson]

On Tue, Jan 29, 2008 at 11:45:32PM +0100, Pierre Habouzit wrote:

On Tue, Jan 29, 2008 at 10:31:48PM +, Moritz Muehlenhoff wrote:

There are certainly performance trade-offs involved and the final
selection of features will depend on the testing of the respective
maintainers (testing should be eased by hardening-wrapper).


 I understand. To be fair, I'm worried in the implications of the SSP,
FORTITY_SOURCES and PIE proposals. Others looks fine, but those three
may have very important performance issues embedded.

* PIE is just IMHO not an option on x86 :/


If you use shared libraries, you already have this performance hit, and 
if you want to use %ebx in non-PIC code, you have to save and restore it 
around each shared-library function call.  Also note that x86 has other 
problems (namely the 387) that make it unsuitable as a serious 
architecture.



 Though probably someone should come up with some benchmarks. The usual
culprits (multimedia libraries, html renderers, xml processors, …) all
provide easily deployed bench, and before we go any further I'd like to
see some numbers.


And now for some numbers, on an amd64 machine (/proc/cpuinfo at [0]), 
crypto code with heavy optimization in a shared library.  All object 
files (including for the executable) are compiled with -fPIC, because 
I'm lazy.


Performance without protection:

MD4: 335544320 bytes in 0.745s (429.667 MiB/s)
MD5: 335544320 bytes in 1.055s (303.452 MiB/s)
RMD160: 335544320 bytes in 1.757s (182.169 MiB/s)
SHA1: 335544320 bytes in 1.801s (177.693 MiB/s)
SHA256: 335544320 bytes in 3.519s (90.928 MiB/s)

With -fstack-protector only:

MD4: 335544320 bytes in 0.748s (427.999 MiB/s)
MD5: 335544320 bytes in 1.056s (302.979 MiB/s)
RMD160: 335544320 bytes in 1.751s (182.744 MiB/s)
SHA1: 335544320 bytes in 1.804s (177.348 MiB/s)
SHA256: 335544320 bytes in 3.515s (91.028 MiB/s)

With -D_FORTIFY_SOURCE=2 only:

MD4: 335544320 bytes in 0.745s (429.670 MiB/s)
MD5: 335544320 bytes in 1.053s (303.846 MiB/s)
RMD160: 335544320 bytes in 1.756s (182.225 MiB/s)
SHA1: 335544320 bytes in 1.794s (178.330 MiB/s)
SHA256: 335544320 bytes in 3.514s (91.057 MiB/s)

With -fPIE -pie only:

MD4: 335544320 bytes in 0.741s (431.703 MiB/s)
MD5: 335544320 bytes in 1.052s (304.173 MiB/s)
RMD160: 335544320 bytes in 1.755s (182.381 MiB/s)
SHA1: 335544320 bytes in 1.797s (178.104 MiB/s)
SHA256: 335544320 bytes in 3.517s (90.996 MiB/s)

With all three features:

MD4: 335544320 bytes in 0.744s (429.978 MiB/s)
MD5: 335544320 bytes in 1.058s (302.479 MiB/s)
RMD160: 335544320 bytes in 1.758s (182.071 MiB/s)
SHA1: 335544320 bytes in 1.793s (178.471 MiB/s)
SHA256: 335544320 bytes in 3.520s (90.896 MiB/s)

In conclusion, there is no appreciable performance hit on any algorithm.  
Note that these are all hash algorithms, but they all make heavy use of 
memcpy, and are extremely CPU-intensive.


Code available upon request.

[0] https://crustytoothpaste.ath.cx/machines/lakeview

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

wnpp.debian.net sources released, security review wanted, plans for the future

[Sebastian Pipping]

Hello!


-- wnpp.debian.net sources
The source code running http://wnpp.debian.net/ is now
hosted in the subversion repository of collab-qa.
The current license is GPL 2 or later, the code
requires PHP >=5 and MySQL >=4.1 to run.

   http://svn.debian.org/viewsvn/collab-qa/

(As the concrete location in there might change I
didn't make the link more precise.)


-- Security review wanted
As I usually code C++ and not PHP/MySQL my current
code probably has security issues. As this code
is running on a publicly accessible machine I
depend on the kindness of its users and
your security reviews.

If you spot a vulnerability in that code please
drop me a private mail about it. Thank you!


-- Plans for the future
* As I learned today popcon also reports about
  programs not coming from Debian packages.
  That information might be useful for
  extra motivation on RFP/ITP bugs.

* The Soap interface is still being queried for
  single bug's data. It has to be checked
  if querying several bugs at once makes a
  difference. I expect it to.

* There is interest in a feed on security-related
  bugs, mentioned by a Gentoo friend of mine.
  This task can be solved with a fork or a clever
  modularization of the current wnpp code.
  The latter would be cool of course.


Please contact me if you feel you can help with any
of these tasks.



Sebastian


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

linux-kernel-headers???

[Cyril Jaquier]

Hi all,

I'm new to Debian so sorry for this newbie question ;)

Why do not the linux-source-2.6.* packages provide linux-kernel-headers?

Regards,

Cyril Jaquier

P.S. Please, do not forget to CC me because I am not subscribed to the list.


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

Re: linux-kernel-headers???

[brian m. carlson]

On Wed, Jan 30, 2008 at 12:44:17AM +0100, Cyril Jaquier wrote:

Why do not the linux-source-2.6.* packages provide linux-kernel-headers?


First of all, linux-kernel-headers has been replaced by linux-libc-dev.  
But either way, the answer is the same: those packages install them in 
/usr/include, which is unpacked and accessible to any program being 
compiled.  linux-source-2.6.* (AFAIK) is not unpacked by default, and 
even when it is unpacked, the headers are not accessible under 
/usr/include.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Introducing security hardening features for Lenny

[Kees Cook]

On Tue, Jan 29, 2008 at 11:45:32PM +0100, Pierre Habouzit wrote:
> * SSP has a cost proportional to the number of calls an application
>   performs (If I'm correct), which in CPU intensive tasks may become an
>   issue.

In testing I've done, this is trivial overhead.  Note that the extra code
is only generated for functions with >8 byte of stack.
(-fstack-protector-all is for doing _all_ functions, which doesn't make
any sense.)

> * FORTITY_SOURCES=2 checks memcpy and memmove, though other functions it
>   checks should just not be used and applications beeing too slow
>   because of them should just be shot down.

I still haven't found a comprehensive list of what -D_FORTIFY_SOURCE
does, and at which levels various features are enabled.  I've dug up
various bits and pieces, but I'd love to see a pointer to good
documentation.  Without that, I suspect attempting to develop a
reasonable test workload is bound to miss certain things.

> * PIE is just IMHO not an option on x86 :/

I disagree here -- the bulk of applications tend to use shared libraries,
and those are all PIC.  I have a hard time believing that adding the
same relocation overhead for the main program is an issue.  Of course,
without numbers, we're all just waving our arms.  :)

>   Though probably someone should come up with some benchmarks. The usual
> culprits (multimedia libraries, html renderers, xml processors, …) all
> provide easily deployed bench, and before we go any further I'd like to
> see some numbers.

Does anyone have any good test harnesses we can try this on?  I'd be
more than happy to run them on some modern hardware.

-Kees

-- 
Kees Cook


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

Re: Introducing security hardening features for Lenny

[Kees Cook]

On Tue, Jan 29, 2008 at 11:17:37PM +0100, sean finney wrote:
> On Tuesday 29 January 2008 10:16:24 pm Moritz Muehlenhoff wrote:
> > A group of people have been working on introducing advanced security
> > hardening features into our archive:
> > http://alioth.debian.org/projects/hardening/
> >
> i guess you're aware of the discussions going on with ubuntu-devel as well?
> 
>   https://lists.ubuntu.com/archives/ubuntu-devel/2008-January/024958.html
>   
> (and further posts where some implementation details are debated)

In trying to not duplicate effort, I've been working both in Debian and
Ubuntu to help get these options enabled globally.

> I have to repeat the question that tfheen asked on that list... why 
> DEB_BUILD_HARDENING=1, and not DEB_BUILD_OPTS=hardening (thus the same as 
> nostrip,noopt,etc).

I'm all for making it as easy as possible to enable the flags.  (Like I
said in the other thread: patches welcome.)  I'd probably want it to be
"nohardening", making compiles hardened by default.  :)

-Kees

-- 
Kees Cook


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

Re: Bug#463167: ITP: dsyslog -- a dumb syslog

[William Pitcock]

Hi,

On Tue, 2008-01-29 at 18:54 -0600, Ron Johnson wrote:
> >  dsyslog is a dumb, yet advanced syslog daemon, which supports
> infinite
> >  rules and expandability through it's purely modular design. The
> default
> >  configuration is a drop in replacement for syslogd.
> 
> What's so dumb about that?

It's not that it's actually dumb, it's like how git is called the
"stupid content tracker" by it's documentation. It's intended to be a
joke.

William


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

control file Replaces: question

[William Francis]

I want to manage the config files for several other packages centrally 
in one package that I'm going to maintain. According to the package 
maintainers guide, section 7.5.1 [1] , this is entirely possible and 
perfectly reasonable via the Replaces: option in the control file.  My 
question is, how do I use the Replaces: option to take ownership of just 
one file and not have it delete the entire package? Also, can I make my 
config package Depend: on the package that I'm going to replace the 
config file of, or does it need to be installed first for this to work?


thanks,

Will


[1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.5.1


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

Re: control file Replaces: question

[Russ Allbery]

William Francis <[EMAIL PROTECTED]> writes:

> I want to manage the config files for several other packages centrally
> in one package that I'm going to maintain. According to the package
> maintainers guide, section 7.5.1 [1] , this is entirely possible and
> perfectly reasonable via the Replaces: option in the control file.

That's not what that Policy section is talking about.  It's specifically
covering the case when you have a newer package that's taking over files
from an older package.

The problem with doing this with a package that's not giving up ownership
of those files is that when you upgrade the package whose configuration
files you overwrote, it will ( error out / take the configuration files
back ) depending on how exactly dpkg tackles this problem.  I'm not sure
which will happen, but either way it isn't what you want.

If you really need to do this, you will need to divert the configuration
files with dpkg-divert.  However, you really don't want to do this.
Rather than managing configuration files with a package, you really want
to use something like Puppet or Cfengine to manage configuration.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

List of packages shipping shell scripts with bashisms + MBF proposal

[Raphael Geissert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello everybody,

[Please only reply to -devel]

I just completed an archive wide check on amd64/all packages by searching
for shell scripts in /bin:/usr/bin:/sbin:/usr/sbin:/etc/init.d:/usr/share
and checking them with checkbashisms from devscripts 2.10.13.

The pourpose of this check was to help and ease the dash as /bin/sh release
goal/transition.

The current number of affected packages based on the scan is 249.
The results of this check may (and as confirmed in some packages) contain
false positives, and of course it isn't an absolute list (there are several
other bashisms that aren't detected, e.g. #462173).

Since there's a release goal which is to default /bin/sh to dash I'd like to
do a MBF on the packages. It would be a manual MBF because there are many
false positives which I wouldn't want to be reported.

Besides providing this list so people can start fixing those bashisms I now
ask if there are any objections on starting to MBF based on the test
results. Of course any other kind of feedback is more than welcome.

The full scan results are available as a compressed tarball[1], where
each .deb file is a plain text file containing the output of checkbashisms.

[1]http://alioth.debian.org/~atomo64-guest/bashisms-amd64-0.1.tar.gz

Kind regards,
Raphael Geissert


Daniel Leidert (dale) <[EMAIL PROTECTED]>
   docbook2x (U)

Guenter Geiger (Debian/GNU) <[EMAIL PROTECTED]>
   wavesurfer

Gregory Colpart (evolix) <[EMAIL PROTECTED]>
   pppoeconf

Stefan Hornburg (Racke) <[EMAIL PROTECTED]>
   courier-pop
   courier-pop-ssl
   sqwebmail

Eric Schwartz (Skif) <[EMAIL PROTECTED]>
   libyaz2-dev

Stefan Alfredsson <[EMAIL PROTECTED]>
   monit

Thomas Anders <[EMAIL PROTECTED]>
   libsnmp-base (U)

Micah Anderson <[EMAIL PROTECTED]>
   rkhunter

Hakan Ardo <[EMAIL PROTECTED]>
   gcc-avr

Ben Armstrong <[EMAIL PROTECTED]>
   tuxpaint

Richard Atterer <[EMAIL PROTECTED]>
   jigdo-file

Khalid Aziz <[EMAIL PROTECTED]>
   kexec-tools

Mathieu Baeumler <[EMAIL PROTECTED]>
   blackbox (U)

Paul Bame <[EMAIL PROTECTED]>
   pmccabe

Denis Barbier <[EMAIL PROTECTED]>
   kbd (U)

Andreas Barth <[EMAIL PROTECTED]>
   netpbm
   pppoe

Mirco Bauer <[EMAIL PROTECTED]>
   beagle (U)
   mono-1.0-devel (U)

Daniel Baumann <[EMAIL PROTECTED]>
   expect-dev
   gnulib
   gnunet-client (U)
   live-initramfs (U)
   virtualbox-ose (U)
   wmii

Ian Beckwith <[EMAIL PROTECTED]>
   surfraw (U)

Luca Bedogni <[EMAIL PROTECTED]>
   foo2zjs (U)

Hilko Bengen <[EMAIL PROTECTED]>
   virtualbox-ose (U)

Felix Berger <[EMAIL PROTECTED]>
   phpix (U)

Marco Bertorello <[EMAIL PROTECTED]>
   powernowd

Marcus Better <[EMAIL PROTECTED]>
   tomcat5.5 (U)

Sylvain Beucler <[EMAIL PROTECTED]>
   page-crunch

Rene van Bevern <[EMAIL PROTECTED]>
   cl-launch (U)

Darren Blaber <[EMAIL PROTECTED]>
   atheme-services (U)

Julien BLACHE <[EMAIL PROTECTED]>
   openser (U)

Eduard Bloch <[EMAIL PROTECTED]>
   encfs
   mono-1.0-devel (U)

Achim Bohnet <[EMAIL PROTECTED]>
   kdebluetooth (U)

W. Borgert <[EMAIL PROTECTED]>
   docbook2x (U)

Dmitry Borodaenko <[EMAIL PROTECTED]>
   samizdat

Fathi Boudra <[EMAIL PROTECTED]>
   kdebluetooth (U)

Fathi Boudra <[EMAIL PROTECTED]>
   kdesdk-scripts (U)

Nicholas Breen <[EMAIL PROTECTED]>
   jigl

Adrian Bridgett <[EMAIL PROTECTED]>
   xmcd

Thomas Bushnell, BSG <[EMAIL PROTECTED]>
   gnucash
   jacal
   slib

Bruno Barrera C. <[EMAIL PROTECTED]>
   blackbox

Paul Cager <[EMAIL PROTECTED]>
   maven2 (U)

Hubert Chan <[EMAIL PROTECTED]>
   noweb

Hubert Chathi <[EMAIL PROTECTED]>
   gnustep-common (U)
   gnustep-make-ogo (U)

Pierre Chifflier <[EMAIL PROTECTED]>
   nufw

Volker Christian <[EMAIL PROTECTED]>
   synce-serial

Dennis L. Clark <[EMAIL PROTECTED]>
   bnetd

Isaac Clerencia <[EMAIL PROTECTED]>
   kexi (U)

David Cobac <[EMAIL PROTECTED]>
   page-crunch (U)

David Coe <[EMAIL PROTECTED]>
   ispell

Console utilities maintainers <[EMAIL PROTECTED]>
   kbd

Julien Cristau <[EMAIL PROTECTED]>
   ocaml-mode (U)

Luis Rodrigo Gallardo Cruz <[EMAIL PROTECTED]>
   sawfish

Maximiliano Curia <[EMAIL PROTECTED]>
   tkman

Tim Cutts <[EMAIL PROTECTED]>
   tkcvs

Julien Danjou <[EMAIL PROTECTED]>
   rebuildd

Debian allegro packages maintainers
<[EMAIL PROTECTED]>
   allegro-examples
   libalogg-dev

Debian ALSA Maintainers <[EMAIL PROTECTED]>
   ld10k1

Debian CLI Applications Team <[EMAIL PROTECTED]>
   beagle

Debian Cryptsetup Team <[EMAIL PROTECTED]>
   cryptsetup

Debian Cyrus SASL Team
<[EMAIL PROTECTED]>
   sasl2-bin

Debian Foo2zjs Maintainers <[EMAIL PROTECTED]>
   foo2zjs

Debian GCC Maintainers <[EMAIL PROTECTED]>
   gcc-3.3
   gcc-3.4
   gcc-4.1

Debian GIS Project <[EMAIL PROTECTED]>
   gpsdrive-scripts

Debian GNOME Maintainers <[EMAIL PROTECTED]>
   gtranslator (U)

Debian GNUstep maintainers <[EMAIL PROTECTED]>
   gnustep-common
   gnustep-make-ogo

Debian Hamradio Maintainers <[EMAIL PROTECTED]>
   ax25-tools
   hf

Debian Hebrew Packaging Team <[E

Re: List of packages shipping shell scripts with bashisms + MBF proposal

[Paul Wise]

On Jan 30, 2008 10:58 AM, Raphael Geissert <[EMAIL PROTECTED]> wrote:

> I just completed an archive wide check on amd64/all packages by searching
> for shell scripts in /bin:/usr/bin:/sbin:/usr/sbin:/etc/init.d:/usr/share
> and checking them with checkbashisms from devscripts 2.10.13.

Has there been any bashisms checks on maintainer scripts (postinst/etc)?

I really really think we need a way to integrate these myriad QA
checks into the PTS and DDPO and the page I proposed in #461898.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: electronics-menu REJECTED (discussion)

[Charles Plessy]

Le Wed, Jan 30, 2008 at 05:24:50AM +1100, Andrew Vaughan a écrit :
> >
> As a user technical seems awkward and unintuitive to me.  I would rather it 
> was called Science and Engineering.  

 [Since the question is not… technical, let's transfer this part of the
 discussion on [EMAIL PROTECTED]

Hi all,

there has been a debate on debian-devel on how we could name a
FreeDesktop menu that would contain applications related to science,
techniques, engeneering, maths, and electronics.

Please see the following page for reference:
http://wiki.debian.org/ExtraMenus

It would be great to reach a consensus on the name, if the idea that
proposing a single entry instead of two or three is accepted.

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


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

Re: wnpp.debian.net sources released, security review wanted, plans for the future

[Paul Wise]

On Jan 30, 2008 9:25 AM, Sebastian Pipping <[EMAIL PROTECTED]> wrote:

> -- wnpp.debian.net sources

Be nice if that wasn't just a redirect domain.

> The source code running http://wnpp.debian.net/ is now
> hosted in the subversion repository of collab-qa.

Excellent.

> -- Security review wanted
> As I usually code C++ and not PHP/MySQL my current
> code probably has security issues. As this code
> is running on a publicly accessible machine I
> depend on the kindness of its users and
> your security reviews.

Might want to also ask on debian-security (list or IRC)

> * There is interest in a feed on security-related
>bugs, mentioned by a Gentoo friend of mine.
>This task can be solved with a fork or a clever
>modularization of the current wnpp code.
>The latter would be cool of course.

Security related info for Debian is maintained here:

http://security-tracker.debian.net/

Not sure what you had in mind for a "feed". If you mean RDF/RSS of
DSAs, there are two here:

http://www.debian.org/security/

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: List of packages shipping shell scripts with bashisms + MBF proposal

[Raphael Geissert]

Cyril Brulebois wrote:

> On 30/01/2008, Paul Wise wrote:
>> Has there been any bashisms checks on maintainer scripts (postinst/etc)?
> 
> There's already:
>  
http://lintian.debian.org/reports/Tpossible-bashism-in-maintainer-script.html

And as for debian/rules Lucas Nussbaum rebuilt the archive with dash
as /bin/sh :)

> 
> Cheers,
> 

Cheers,
Raphael Geissert


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

Re: List of packages shipping shell scripts with bashisms + MBF proposal

[Cyril Brulebois]

On 30/01/2008, Paul Wise wrote:
> Has there been any bashisms checks on maintainer scripts (postinst/etc)?

There's already:
  http://lintian.debian.org/reports/Tpossible-bashism-in-maintainer-script.html

Cheers,

-- 
Cyril Brulebois


pgpu6gpae1W7J.pgp
Description: PGP signature

Re: List of packages shipping shell scripts with bashisms + MBF proposal

[Raphael Geissert]

Paul Wise wrote:
> 
> I really really think we need a way to integrate these myriad QA
> checks into the PTS and DDPO and the page I proposed in #461898.
> 

I'm going to generate a BDB with the information from the lintian test on
amd64 as soon as I find some time for it and somewhere to place it :)

P.D. how is mole used by the way?

Cheers,
Raphael Geissert


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

Re: The 30 most popular packages missing in Debian

[Joe Smith]

"Sebastian Pipping" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

* Would non-free be an option to all or some of them?
  Do we have binary only packages in Debian?


My understanding is that it is possible to have binary-only packages in 
non-free,
although I really don't know anything about that. I usually try to avoid 
things from non-free that are not at the very minimum semi-free. (A.K.A, I 
can have the source, make changes, destribute them, etc, but there are some 
conditions limiting my freedoms that just manage to fall on the wrong side 
of the DFSGs, [for example GFDL manuals with invarient sections]). 




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

Re: Introducing security hardening features for Lenny

[John Goerzen]

On Tuesday 29 January 2008 4:31:51 pm Yves-Alexis Perez wrote:
> On mar, 2008-01-29 at 15:47 -0600, John Goerzen wrote:
> > I notice, for instance, that the latest cups
> > requires avahi.  Can we build it without that and install it without
> > that by
> > default for those that don't need it, to eliminate Yet Another Daemon?
>
> You do know that it depends on the lib, not the daemon?
> --
> Yves-Alexis

It wound up pulling in the daemon on my box.  Though it could be that the 
daemon was already installed because kde required it, and upgrading cups 
required the upgraded lib, and the daemon wouldn't work with the upgraded 
lib, so it too had to be upgraded... I didn't track that one all the way 
back.

(I think it's broken that KDE requires it too)


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

Re: Bug#463167: ITP: dsyslog -- a dumb syslog

[Robert Collins]

On Tue, 2008-01-29 at 19:07 -0600, William Pitcock wrote:
> Hi,
> 
> On Tue, 2008-01-29 at 18:54 -0600, Ron Johnson wrote:
> > >  dsyslog is a dumb, yet advanced syslog daemon, which supports
> > infinite
> > >  rules and expandability through it's purely modular design. The
> > default
> > >  configuration is a drop in replacement for syslogd.
> > 
> > What's so dumb about that?
> 
> It's not that it's actually dumb, it's like how git is called the
> "stupid content tracker" by it's documentation. It's intended to be a
> joke.

Users are very good at missing these jokes.

-Rob
-- 
GPG key available at: .


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

Re: Introducing security hardening features for Lenny

[Yves-Alexis Perez]

On mar, 2008-01-29 at 21:31 -0600, John Goerzen wrote:
> It wound up pulling in the daemon on my box.  Though it could be that
> the 
> daemon was already installed because kde required it, and upgrading
> cups 
> required the upgraded lib, and the daemon wouldn't work with the
> upgraded 
> lib, so it too had to be upgraded... I didn't track that one all the
> way 
> back.

Did you try to remove it?
> 
> (I think it's broken that KDE requires it too)

Think “Recommends”.
-- 
Yves-Alexis


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

Re: Bug#463167: ITP: dsyslog -- a dumb syslog

[William Pitcock]

Hi,

On Wed, 2008-01-30 at 16:22 +1100, Robert Collins wrote:
> On Tue, 2008-01-29 at 19:07 -0600, William Pitcock wrote:
> > Hi,
> > 
> > On Tue, 2008-01-29 at 18:54 -0600, Ron Johnson wrote:
> > > >  dsyslog is a dumb, yet advanced syslog daemon, which supports
> > > infinite
> > > >  rules and expandability through it's purely modular design. The
> > > default
> > > >  configuration is a drop in replacement for syslogd.
> > > 
> > > What's so dumb about that?
> > 
> > It's not that it's actually dumb, it's like how git is called the
> > "stupid content tracker" by it's documentation. It's intended to be a
> > joke.
> 
> Users are very good at missing these jokes.
> 
> -Rob

Yes, I hadn't thought of that. I'll just refer to it as a "an advanced
and powerful syslog daemon" in the short description then.

(on another note, dsyslog is now complete enough that it has replaced
the syslogd on my desktop.)

William


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

Re: Bug#463167: ITP: dsyslog -- a dumb syslog

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/29/08 23:22, Robert Collins wrote:
> On Tue, 2008-01-29 at 19:07 -0600, William Pitcock wrote:
>> Hi,
>>
>> On Tue, 2008-01-29 at 18:54 -0600, Ron Johnson wrote:
  dsyslog is a dumb, yet advanced syslog daemon, which supports
>>> infinite
  rules and expandability through it's purely modular design. The
>>> default
  configuration is a drop in replacement for syslogd.
>>> What's so dumb about that?
>> It's not that it's actually dumb, it's like how git is called the
>> "stupid content tracker" by it's documentation. It's intended to be a
>> joke.
> 
> Users are very good at missing these jokes.

Especially when there are valid computer-terminology uses of the
adjective /dumb/.

- --
Ron Johnson, Jr.
Jefferson LA  USA

"I'm not a vegetarian because I love animals, I'm a vegetarian
because I hate vegetables!"
unknown
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHoBqdS9HxQb37XmcRAoY4AKDft0nlyDqj7+sqEv3Ao5FBsP+KMwCcCyPF
Q++xZl2ecunG3rydqa43myQ=
=+ath
-END PGP SIGNATURE-


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

Re: The 30 most popular packages missing in Debian

[Andrew M.A. Cater]

On Tue, Jan 29, 2008 at 11:57:25PM +0100, Petter Reinholdtsen wrote:
> 
> One of the lists from popcon.debian.org I find most interesting, is
> the list of popular packages currently missing in Debian,
> http://popcon.debian.org/unknown/by_vote>.  I understand it to
> list the packages our users would love to find in Debian, but which
> are currently missing.  Some are missing because we can't legally
> distribute them, others are missing because no-one is willing to
> maintain them in the Debian repositories, while others again are
> obsolete and used to be part of Debian.
> 
Let's reiterate some of the reasons (unfortunately still valid).

> This is the top 30 list, sorted by vote (aka include files
> read/executed last week):
> 
> #rank nameinst  vote   old recent no-files
> 1 skype   5678  3020  2273   380 5
> 2 acroread-debian-files   4151  2585  1144   421 1
Adobe licence - we can't distribute with "other" PDF writing software 
IIRC

> 3 opera   3817  2267  1204   341 5
> 4 lame7859  2045  5125   686 3
> 5 transcode   5025  1859  2158  1007 1
Lame/transcode - codecs issue?

> 6 realplayer  3077  1679  1140   18276
> 7 virtualbox  2032  1458   374   198 2
In sid, at least in part IIRC
> 8 mencoder6064  1432  3678   951 3
> 9 mjpegtools  5491  1234  3600   656 1
> 10emerald 2241  1079   820   342 0
> 11dvdrip  2386   791  1351   242 2
> 12libnl1-pre8 1390   782 0 9   599
> 13avidemux2471   657  1008   804 2
> 14mythtv-backend   824   656   12642 0
> 15libevent-execflow-perl  2570   625  1709   234 2
> 16beryl-manager   1369   592   71163 3
> 17nxserver 834   578   1933924
NX - Hard to package - someone's been trying for ever :)

> 18beryl-core  1604   570   96469 1
> 19adobereader-enu  762   537   16162 2
see above for Adobe
> 20nxclient1259   500   655   100 4
> 21pine 944   487   42928 0
Ignore it - move to alpine
> 22w32codecs   9231   466   578   118  8069
> 23googleearth 1078   461   53680 1
> 24mythtv-frontend  998   433   419   146 0
> 25subtitleripper  2091   431  1416   243 1
> 26fusion-icon  849   421   184   244 0
> 27linux-image-2.6.22-2-6863842   406  32958655
It's there in testing/unstable
> 28sun-j2sdk1.5 824   406   35757 4
Wrong Java licence - packaged before Sun went "free": I think only
Java 7 will be fully free IIRC
> 29gtk2-ex-formfactory-perl2585   397  1939   247 2
> 30anyevent-perl   2581   393  1906   279 3
> 
> I wish all the packages we could distribute on this list was included
> in Debian.  I believe it would make the life of our users a little
> easier.
> 
Situation getting better.
> Package related to Multimedia, PDF and 3D stuff seem to be popular
> while missing in Debian. :)
> 
Don't always blame Debian - blame upstream licensing and control for 
some of it.

Andy



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

Re: Introducing security hardening features for Lenny

[David Baron]

On Tuesday 29 January 2008, Moritz Muehlenhoff wrote:
> The Debian archive is the biggest of all distributions and although
> there's security support for all security issues being found, there's
> still room for improvement and a need for increased resilience against
> flaws not yet discovered.
>
> A group of people have been working on introducing advanced security
> hardening features into our archive:
> http://alioth.debian.org/projects/hardening/
>
> We recommend to activate the following features in individual packages
> for now and discuss how to enable them system-wide later. (Matthias
> Klose proposed a mechanism in debian-devel, which could be used for
> it: http://lists.debian.org/debian-devel/2007/12/msg00090.html).
>
> Some maintainers have already pro-actively enabled these features,
> e.g. in the sendmail and openssh packages, but we're heading for
> full archive coverage now.
>
>
> There are two general classes of enhancements we'd like to apply to
> Debian:
>
> 1. Tool chain features preventing the exploitation of some
> vulnerability classes
>
> Stack protector
> ===
>
> For a general introduction please see Wikipedia:
> http://en.wikipedia.org/wiki/Stack-smashing_protection
>
> This is relatively straight-forward. While it only addresses classic
> stack buffer overflows, we still have a lot of poorly-reviewed
> special case legacy code in our archive, so this will still be useful
> in practice.
>
> It's included in stock GCC since 4.1 onwards, so people would only
> need to add the compile flags to their packages.
>
> If there are packages which don't work with stack protection, it
> can be overridden with a compile flag. (We would need a lintian
> test to catch these, so that maintainers rather fix bugs in their
> packages than circumventing it with disabling SSP.)
>
> To enable, make sure that "-fstack-protector" ends up in the compiler
> flags.
>
>
> Fortify Source
> ==
>
> This feature adds validation for internal C functions such as strcpy
> for buffer sizes known during compile time. While vulnerabilities in
> the functions it protects have become uncommon in high-profile apps,
> it will be useful for fringe packages we have in the archive.
>
> This feature is present in glibc since version 2.5, and is enabled
> through the use of "-D_FORTIFY_SOURCE=2" and "-O2" or higher.
>
> Format warnings
> ===
>
> For a general introduction please see Wikipedia:
> http://en.wikipedia.org/wiki/Format_string_attack
>
> This feature adds a higher level of warning reporting for functions using
> format strings.  To enable, add "-Wformat" and "-Wformat-security" flags,
> and pay attention to compile-time warnings.
>
>
>
> 2. Tool chain features enhancing the effectiveness of Address Space
> Layout Randomization, which raises the bar for successful exploitation
> of vulnerabilities.
>
> For a general introduction please see Wikipedia:
> http://en.wikipedia.org/wiki/Address_space_layout_randomization
>
> relro
> =
>
> This feature marks certain sections of the executable memory space
> read-only after the linker has finished its work.  It serves as a
> measure against GOT overwrites, which can make exploits more difficult.
>
> This is enabled via "-Wl,zrelro".
>
>
> Position Independent Executables
> 
>
> Currently, modern kernels randomize the location of mmap and stack
> allocation, but the text segment (and subsequent brk memory) is always
> in the same place.  In kernels that support text ASLR, programs compiled
> for PIE will gain full position randomization.  This has some known
> problems on our more exotic archs, specifically hppa and m68k. These
> tool chains should be patched, so that enabling PIE is a NOP instead of
> forcing every maintainer to jump through hoops.
>
> The flag -fPIE is very similar to -fPIC, but it applies to objects linked
> to form the final executable binary.  PIE is enabled by passing "-fPIE" to
> all object builds, and passing "-pie" to the final link.
>
>
> Experimental wrapper package
> 
>
> An experimental wrapper has been written, which is available in unstable:
> http://packages.qa.debian.org/h/hardening-wrapper.html
> It contains basic usage information.
>
> You can use it to test compilation w/o much overhead. Lucas Nussbaum made
> a complete archive rebuild and about 700 packages failed to build, mostly
> due to problems with PIE:
> http://people.debian.org/~lucas/logs/2007/11/26.hardening/00lists/
>
> Once you've verified that your package builds and runs correctly, you
> should add the necessary compiler/linker flags to your package's build
> system.
>
> Once a distribution-wide way to add these flags is defined, you can switch
> your package to it.
>
>
>
> Scope of this proposal
> ==
>
> The target for Lenny is to enable these features in all applications
> with potential security impact, specifically:
>
> - Your application is written in

Re: The 30 most popular packages missing in Debian

[Petter Reinholdtsen]

[Sebastian Pipping]
> * Would non-free be an option to all or some of them?
>   Do we have binary only packages in Debian?

Yes.  The issue is more that very few package maintainers in Debian
want to maintain non-free packages.

> * A mapping to current ITPs might be interesting.
>   (Integration into http://wnpp.debian.net/)

I agree.  But that would require real work, and not just cut-n-paste,
so I leave that as an exercise for the reader. :)

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: Wrong Architecture for openhackware

[Guillem Jover]

tags 339870 wontfix
thanks

Hi,

On Sat, 2008-01-12 at 18:47:53 +0100, Roland Stigge wrote:
> Debian Bug Tracking System wrote:
> >* Error out if the toolchain used to build is not powerpc-linux-gnu.
> >  (Closes: #322300, #339870)
> 
> Again, I don't agree here (backed by p2): The package is wrong if it
> asserts that it's "Architecture: all". It contains powerpc specific
> stuff and can only be built on (i.e. for) that architecture. Therefore,
> it should be "Architecture: powerpc".

The only relevant part here is that it provides ppc binaries, the fact
that it needs a ppc toolchain is not, I'd say, it's an arch:all package
after all. Take vgabios as a similar example, it can be built anywhere
(because it uses bcc and bin86), it's an arch:all package that provides
i386 binaries, but yet it cannot be used on real i386 hardware, so
making it arch:any would make it a bit useless, you could only use it
under i386 to emulate i386 systems.

Also those are firmwares, you will not be able to run them directly on
your host system anyway, they either might need to be installed in a
BIOS/PROM/whatever or used inside an emulator, so I don't think they
are in the same situation as normal binaries.

Yes, ideally, to be pedantically correct, we would either have
powerpc (or other) cross-toolchains on the archive, or we'd have
Multiarch support and the package could be arch:powerpc and would be
possible to install on other arches. But this is not possible right
now, so consider this wontfix.

Other packages in a similar situation are proll, openbios-sparc,
bochsbios and vgabios (there might be others).

> Workarounds like an error on wrong toolchain architecture are wrong
> (there is an error anyway if you try to build on !powerpc).

That error is too late, and this one at least explains why it's
failing.

regards,
guillem


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

Re: The 30 most popular packages missing in Debian

[sean finney]

hi,

jftr:

On Tuesday 29 January 2008 11:57:25 pm Petter Reinholdtsen wrote:

> 10emerald 2241  1079   820   342 0

i may end up packaging this as part of the desktop-bling subproject in 
pkg-xorg.


> 26fusion-icon  849   421   184   244 0

there's an initial version of this package awaiting sponsorship in 
mentors.debian.net.  I also plan on either sponsoring or adopting or 
incorporating into an existing package this package in the next couple 
weeks... 

maybe that'll shorten your list a little :)

sean


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

Re: Dezabonare

[Lucia Geogia]

Vreau dezabonare

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


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

Re: Dezabonare

[Lucia Geogia]

Vreau dezabonare

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


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