Re: usplash-theme-debian uploaded to sid

[Raphael Geissert]

Hi Holger,

Holger Levsen wrote:
[...]
> Today I've uploaded [1 usplash-theme-debian_5] to sid, making it the first
> upload since more than two years. To celebrate this and to make the
> (upcoming) change(s more) visible, I've exchanged the artwork against the
> one
> [2 by Chad Albers]. 

First of all thanks for your work.
Second, while working on optimising the boot process I have found usplash
and splashy (basically any userspace splash screen) to have a high CPU
usage and actually slow down several seconds the boot process.
Has there been any work on making them more efficient?
Are you (and/or whoever maintains the splash packages) aware that sysvrc in
the makefile concurrency mode (which should become the default at some
point in the future) does not handle the splash progress bar API?

I personally think that as the boot process becomes faster there will be
little point in having progress bars in splash screens (and this might be
the part of cause of the high CPU usage, but I'm just guessing that part).

What are the plans for squeeze?

I am preparing some changes to readahead-fedora to cut at least a couple of
seconds more (can be expected in less than two weeks) and even more changes
to speed it up even more. JFTR my laptop gets to the end of rc2 in 16
seconds (and to a ready-to-use password-protected desktop in ~60 seconds,
but I'm working on that too); while it used to take more than 40 seconds
just to get to the end of rc2. 

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


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

opposition against clamav-data in debian volatile

[Török Edvin]

On Tue, Sep 22, 2009 at 14:21, Florian Weimer  wrote:
> * Javier Fernandez-Sanguino:
>
>> This really sounds like there is a "use case" for data-only
>> "packages" that:
>
> Is clamav-data really data-only?  Other AV software ships some sort of
> code even in signature updates (as opposed to engine updates).
>

Yes, the signatures contain only signatures, which are hexadecimal
patterns with wildcards, hashes, and so on. See
http://www.clamav.net/doc/latest/signatures.pdf

For ClamAV 0.96 we have planned support for bytecode signatures, see
http://www.clamav.net/about/roadmap.
This is not directly executable code, but bytecode that is executed by
an interpreter/JIT, and doesn't have access to the system in any way,
it only has access to a restricted set of ClamAV APIs.

Regarding freshclam, there are 2 ways to setup a local mirror,
described here, see the question "I’m running ClamAV on a lot of
clients on my local network. Can I serve the cvd files from a local
server so that each client doesn’t have to download them from your
servers?"
http://www.clamav.net/support/faq/faq-cvd/

Best regards,
--Edwin


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

Re: New upstream version

[Klaus Ethgen]

Hi,

thanks for the hint to debian-mentors. So I add that list and attach the
original mail to that mail. I set also a reply-to for debian-mentors und
myself (I am not subscribed to debian-mentor 'til now). I left also
debian-devel to show where the follow up is going on. (Urgh, NNTP is
that better for discussions than mailing lists!)

Am So den 25. Okt 2009 um  4:27 schrieb Charles Plessy:
> Fist of all, thank you Klaus for proposing your help on dcraw. In 2008, the
> package was in a similar situation, and Steve eventually prepared an update. I
> recommend to the people concerend by the state of dcraw to have a look at the
> following thread on debian-ment...@l.d.o:
> 
> http://lists.debian.org/msgid-search/91f186a80807081226n4d4567feu96daf465fefa...@mail.gmail.com

Hmm.. Fascinating. He did also the same than me by including the
internationalized manpages and locales (which is also lost in the latest
official package by Steve).

However, I put my dcraw package to my ftp server under
ftp://ftp.ethgen.de/pub/debian/pool/ (dcraw_8.98*) for review.

> But on the other hand, I think that the situation could be better if dcraw 
> were
> team-maintained rather than updated once a year. Steve, what do you think 
> about
> this?

You can count for me.

> PS: and of course, this discussion has to move to another list as soon as it
> enters into technical details about packaging issues.

Sure. As I mention I did the x post.

Regards
   Klaus
-- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen 
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: dcraw
Followup-For: Bug #519604
Followup-For: Bug #506705
Followup-For: Bug #523789

I updated dcraw strait forward to version 8.95-0. This can be done in
less than 5 minutes. And even this is not the newest version. The reason
I need that version was that the version in debian doesn't support my
EOS500D.

However, the newer versions support many newer camera models out there.
The update will also close bugs #506705 and #523789.

I am not a debian maintainer, but I can create a NMU and send it to
Steve King (Maintainer of dcraw) for regular upload by you or give it to
another maintainer to load up the NMU if the regular maintainer is to
busy. For that reason I also cc to debian-devel to ask for a regular to
suport the upload.

Regards
   Klaus

Ps. I can also upload the package to my unofficial package repository
but I prefer to have a up-to-date package in debian.
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen 
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQEVAwUBSuME6Z+OKpjRpO3lAQrwywf9H7NJWidnKz74KLBuKJk1OYRaxqcEpRVH
j+sGU5/JkOvKAVpeIZWJcSYlqoim6MUlCGzi8oM9qkXGqRFYbNwmwMMhk+r60Tcm
kiQxMJg3XmCnEd4qkGav8uOQrpr3QGDPGpXvy8VZ8QHmmnuvCyFSQdOoD5ei2wB7
1V9YFl6RFc7WAKo1zpagGRquE/pstJV/8TfkXaQLZuqAAZNTcHIYnXwQ8HzV9UJi
5XSK3ZUWG2asSGcU2QCkrU4uomZrIyBlD3+UzVoRpC3G8uPXzQ1VOuXuxH8oAdVL
orw3XFmyJTQLlucE7SHBIXtAZypRnNKWizKj6KEYMm/Xkz80Xv0BQQ==
=4Mne
-END PGP SIGNATURE-
--- End Message ---


signature.asc
Description: Digital signature

git-buildpackage could use get-orig-source, uscan ?

[Jérémy Lal]

I noticed bzr-buildpackage is able to get upstream tarball
with get-orig-source or uscan, if they exist.
Should git-buildpackage (and others) provide the same feature ?

Regards,
Jérémy Lal


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

Re: git-buildpackage could use get-orig-source, uscan ?

[Eugene V. Lyubimkin]

Jérémy Lal wrote:
> I noticed bzr-buildpackage is able to get upstream tarball
> with get-orig-source or uscan, if they exist.
> Should git-buildpackage (and others) provide the same feature ?
> 
At least for git-buildpackage, mentioning '--pristine-tar' when importing
original tarball works better IMO.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer



signature.asc
Description: OpenPGP digital signature

Re: git-buildpackage could use get-orig-source, uscan ?

[Stefano Zacchiroli]

On Sun, Oct 25, 2009 at 12:12:09PM +0100, Jérémy Lal wrote:
> I noticed bzr-buildpackage is able to get upstream tarball
> with get-orig-source or uscan, if they exist.
> Should git-buildpackage (and others) provide the same feature ?

This should be better debated as a bugreport against git-buildpackage.

FWIW, I second such a feature request, but it is possibly debatable as
some people might want to first import the really pristine upstream
tarball in Git and only then perform the additional mangling; this way
you preserve the mangling history. Of course this has the drawback of
storing in VCS stuff with potential redistribution problem, if that is
the reason for the mangling. So, as I said, it is debatable and gbp
shuold probably support both options.

Can you please file a bug against gbp?

TIA,
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Bug#552323: ITP: libcrypt-saltedhash-perl -- module for handling salted hashes

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libcrypt-saltedhash-perl
  Version : 0.05
  Upstream Author : Sascha Kiefer 
* URL : http://search.cpan.org/dist/Crypt-SaltedHash/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : module for handling salted hashes

 Crypt::SaltedHash is a Perl module that provides an object oriented interface
 to create salted (or seeded) hashes of clear text data. The formalization of
 this concept originates from RFC-3112 and is extended by the use of different
 digital algorithms.

NOTE: I'm packaging this because of a request from a user via email (see below)


-- Forwarded message --
From: Adam Sjøgren 
Date: Sun, Oct 25, 2009 at 8:47 AM
Subject: Crypt::SaltedHash and libcatalyst-modules-perl
To: debian-p...@lists.debian.org


 Hi.


libcatalyst-modules-perl includes
Catalyst::Authentication::Credential::Password,
which - if you use the password_type "salted_has" requires Crypt::SaltedHash.

It would be great if libcatalyst-modules-perl recommended or suggested
the installation of libcrypt-saltedhash-perl - and if Crypt::SaltedHash
was packaged :-)

dh-make-perl builds Crypt::SaltedHash without a hitch.


 Best regards,

--
 "You've got skills you can make it look good                 Adam Sjøgren
 And unbroken from the root to the fruit"               a...@koldfront.dk


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



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

RFH: fluxbox -- Highly configurable and low resource X11 Window manager

[Dmitry E. Oboukhov]

Package: wnpp
Severity: normal

Unfortunately, now I do not have enough time to maintain this package
properly, so help/comaintain would be appreciated.

I adopted fluxbox when it had more than 120 bugs. Now it has 34 bugs,
i think that the most part of them (or of the last of them) is
unreproducible. But I couldn't find time to separate/fix its.

If anybody wants we also could create pkg-fluxbox team :)

--
... mpd is off

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: perl and perl-modules; reflexive dependencies vs. archive bloat

[Peter Samuelson]

[Don Armstrong]
> I actually suggested that perl-modules recommend perl, but that was
> rejected for the reason that perl-modules doesn't do anything useful
> without perl.

You sure?  That surprises me - I would have thought a lot of the
modules in perl-modules only needed perl-base.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


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

Bug#552325: ITP: libsearch-namazu-ruby -- Namazu binding for Ruby language

[TANIGUCHI Takaki]

Package: wnpp
Owner: tak...@debian.org
Severity: wishlist

* Package name: libsearch-namazu-ruby
  Version : 0.1 
  Upstream Author : Tietew 
* URL or Web page :  http://ftp.tietew.jp/pub/ruby/
* License : Ruby | GPL2+
  Description : Namazu binding for Ruby language

 This is an extension library for Ruby to use libnmz which is C library of
 Namazu.



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

Bug#552326: ITP: apron -- An abstract interpretation library

[Samuel Mimram]

Package: wnpp
Severity: wishlist
Owner: Samuel Mimram 

* Package name: apron
  Version : 0.9.10
* URL : http://apron.cri.ensmp.fr/library/
* License : LGPL + GPL
  Programming Lang: C + OCaml
  Description : An abstract interpretation library

 The APRON library is dedicated to the static analysis of the numerical
 variables of a program by Abstract Interpretation. The aim of such an analysis
 is to infer invariants about these variables. It is intended to be a common
 interface to various underlying libraries/abstract domains and to provide
 additional services that can be implemented independently from the underlying
 library/abstract domain.




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

Packages relying on HOME when building

[Guillem Jover]

Hi!

There's some packages which rely on HOME existing and often being
writtable. This is broken behaviour as the package does not have any
businesss verifying if it exists or writting outside of its build dir
(or /tmp).

Some of our buildds try to detect by setting HOME to something like
/non-existent. But then it gets pretty confusing for the maintainers
trying to reproduce those FTBFS (c.f. #544835).

So, I'd propose that any script used to build source should set HOME
to a non existent value. And we should probably ammend policy to state
that no source package should expect a working HOME. If no one opposes
I'll start filing bug reports.

thanks,
guillem


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

Re: defaulting to net.ipv6.bindv6only=1 for squeeze

[Marco d'Itri]

On Oct 25, Russ Allbery  wrote:

> This is really the right solution.  We did this a while back for INN and
> it's cleared up a bunch of complexity and weirdness.  It would be nice if
> we could just get all the applications patched, although I suppose that's
> unrealistic.
This is why I would be satisfied with only having to patch the ones
which do not work with net.ipv6.bindv6only=1.

I welcome more opinions about this issue.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Switch on compiler hardening defaults

[Kees Cook]

Hello,

I would like to propose enabling[1] the GCC hardening patches that Ubuntu
uses[2].  Ubuntu has used it successfully for 1.5 years now (3 releases),
and many of the issues have already been fixed in packages that needed
adjustment[3].  After all this time, use of the hardening-wrapper[4]
package is still very low, so I think the right thing to do is to just fix
this in the compiler and everyone wins.  I'm not suggesting that there
won't be added work to fix problems, but I believe that for Debian the
benefits now out-weigh the risks.

I do not expect to reach consensus with all developers on this, so I'm
not sure who I need to convince to move it forward.  (Perhaps just the
GCC maintainers?)  Regardless, if you agree with this, please speak up.
I think it's very important that this change happens.

My candid commentary and possible trolling...

Arguments for:
- users of Debian become safer (real[5] security vulnerabilities are
  either non-issues or reduced to a DoS).
- security team has less work to do.
- software quality improves by finding subtle bugs (and not just
  packaged software -- anything compiled with the Debian gcc).

Arguments against:
- makes the compiler's behavior different than stock compiler.
Rebuttal: honestly, I don't care -- it seems like such a
  huge win for safety and is easy to debug.  Debian
  already carries plenty of patches anyway -- there
  is no such thing as the "stock compiler".
- makes more work for dealing with warnings.
Rebuttal: those warnings are there for a reason -- they can
  be real security issues, and should be fixed.
- lacks documentation.
Rebuttal: that may have been true a while ago, but I've worked
  hard to document the features and how to handle
  problems.  See [2].  Even the gcc man pages are patched.
- makes running Debian slower.
Rebuttal: no, nothing supports this.  The bulk of _FORTIFY_SOURCE
  is compile-time.  Run-time checks, including those from
  -fstack-protector are just not measurable.  The burden of
  evidence for anyone claiming this is on them.  I'm not
  suggesting we turn on PIE; that option can be a problem.

Inflammatory observation: Debian may be the single remaining major Linux
distribution that does not use the stack protector and _FORTIFY_SOURCE
when building its packages.  I find this embarrassing.  Check[6] for
yourself.

Thanks,

-Kees

[1] http://outflux.net/hardening-for-all.patch
(Note that the gcc hardening does NOT turn on PIE, which has
 measurable performance problems on some architectures.)

[2] https://wiki.ubuntu.com/CompilerFlags

[3] Sampling of bugs I've personally filed:
Closed
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521108
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529074
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479398
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488456
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488457
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497833
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497865
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505734
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505233
Open
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523807
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488460
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488462

[4] http://wiki.debian.org/Hardening

[5] Many vulnerabilities have been blocked in Ubuntu, but I will give one
good example of a remote root vulnerability with functional exploits
in the wild that was a non-issue on versions of Ubuntu with the
hardened compiler defaults:
http://www.debian.org/security/2009/dsa-1833

[6] Are there _chk functions in common binaries?
$ objdump -R /bin/df | grep _chk
00612048 R_X86_64_JUMP_SLOT  __fprintf_chk
00612068 R_X86_64_JUMP_SLOT  __printf_chk
006120c0 R_X86_64_JUMP_SLOT  __memcpy_chk
006121c0 R_X86_64_JUMP_SLOT  __stack_chk_fail
00612220 R_X86_64_JUMP_SLOT  __sprintf_chk
00612230 R_X86_64_JUMP_SLOT  __snprintf_chk


-- 
Kees Cook@debian.org


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

Bug#552366: ITP: ocaml-usb -- OCaml bindings to libusb-1.0

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu" 

* Package name: ocaml-usb
  Version : 0.1
  Upstream Author : Jérémie Dimino 
* URL : http://ocaml-usb.forge.ocamlcore.org
* License : BSD-C3
  Programming Lang: C, OCaml
  Description : OCaml bindings to libusb-1.0

 OCaml-USB is a binding to libusb-1.0, a userspace USB programming
 library. It uses Lwt to ease use of asynchronous IO features of
 libusb-1.0.



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

Re: Switch on compiler hardening defaults

[James Vega]

On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> Arguments against:
> - makes the compiler's behavior different than stock compiler.
> Rebuttal: honestly, I don't care -- it seems like such a
>   huge win for safety and is easy to debug.  Debian
>   already carries plenty of patches anyway -- there
>   is no such thing as the "stock compiler".
> - makes more work for dealing with warnings.
> Rebuttal: those warnings are there for a reason -- they can
>   be real security issues, and should be fixed.
> - lacks documentation.
> Rebuttal: that may have been true a while ago, but I've worked
>   hard to document the features and how to handle
>   problems.  See [2].  Even the gcc man pages are patched.
> - makes running Debian slower.
> Rebuttal: no, nothing supports this.  The bulk of _FORTIFY_SOURCE
>   is compile-time.  Run-time checks, including those from
>   -fstack-protector are just not measurable.  The burden of
>   evidence for anyone claiming this is on them.  I'm not
>   suggesting we turn on PIE; that option can be a problem.

- breaks debugging with gdb.  See
  <1256300822.13273.39.ca...@fsopti579.f-secure.com> on this list and #346409.
  You provided a patch for #346409, but there appears to be issues with it as
  noted in the bug log.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


signature.asc
Description: Digital signature

Re: Switch on compiler hardening defaults

[Ryan Niebur]

On Sun, Oct 25, 2009 at 03:21:01PM -0400, James Vega wrote:
> On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > Arguments against:
> > - makes the compiler's behavior different than stock compiler.
> > Rebuttal: honestly, I don't care -- it seems like such a
> >   huge win for safety and is easy to debug.  Debian
> >   already carries plenty of patches anyway -- there
> >   is no such thing as the "stock compiler".
> > - makes more work for dealing with warnings.
> > Rebuttal: those warnings are there for a reason -- they can
> >   be real security issues, and should be fixed.
> > - lacks documentation.
> > Rebuttal: that may have been true a while ago, but I've worked
> >   hard to document the features and how to handle
> >   problems.  See [2].  Even the gcc man pages are patched.
> > - makes running Debian slower.
> > Rebuttal: no, nothing supports this.  The bulk of _FORTIFY_SOURCE
> >   is compile-time.  Run-time checks, including those from
> >   -fstack-protector are just not measurable.  The burden of
> >   evidence for anyone claiming this is on them.  I'm not
> >   suggesting we turn on PIE; that option can be a problem.
> 
> - breaks debugging with gdb.  See
>   <1256300822.13273.39.ca...@fsopti579.f-secure.com> on this list and #346409.
>   You provided a patch for #346409, but there appears to be issues with it as
>   noted in the bug log.
> 

in the footnotes of Kees's email it said:
(Note that the gcc hardening does NOT turn on PIE, which has
 measurable performance problems on some architectures.)

so this isn't a problem.

-- 
_
Ryan Niebur
ryanrya...@gmail.com


signature.asc
Description: Digital signature

Re: defaulting to net.ipv6.bindv6only=1 for squeeze

[Jarek Kamiński]

On Sat, Oct 24, 2009 at 10:00:01PM +0200, Marco d'Itri wrote:
>> And bindv6only=0 is also not RFC compliant. However, a *lot* of applications
>> that use listening sockets will not work correctly anymore when you change 
>> the
>> default. So it probably is better to make it a release goal that applications

> Can you make a list? I do not think there is a significant number, I
> only know about vmware.

I run this configuration on most of my systems and don't have many
problems. There was some problem with apache, but it's now fixed. Also
java is broken and my bug report got ignored by sun, but it should be
easy patchable (preloading socket() and calling setsockopt(IPV6_V6ONLY)
works for me).

There were also some problems with dovecot listening on either 0.0.0.0,
or [::], but I don't remember details nor know they current state.
I don't remember any problems with vmware, but I don't use it now. Maybe
I was connecting to it only with IPv6.

I'm not sure if I wasn't forced to modify default configuration for
some daemons.

Jarek.


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

Bug#552380: ITP: spacenavd -- daemon for using 3D input devices from 3Dconnexion

[M G Berberich]

Package: wnpp
Severity: wishlist
Owner: M G Berberich 


* Package name: spacenavd
  Version : 0.4
  Upstream Author : John Tsiombikas 
* URL : http://spacenav.sourceforge.net/index.html
* License : GPL
  Programming Lang: C
  Description : daemon for using 3D input devices from 3Dconnexion

Spacenavd is a free daemon which provides a free, compatible
alternative, to the proprietary 3Dconnexion device driver, for
their 3D input devices (called "space navigator", "space pilot",
"space traveller", etc).



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

Bug#552387: ITP: libjsr305-java -- annotations for software defect detection

[Michael Koch]

Package: wnpp
Severity: wishlist
Owner: Michael Koch 

* Package name: libjsr305-java
  Version : 0~svn97
  Upstream Author : Bill Pugh and others.
* URL : http://code.google.com/p/jsr-305/
* License : BSD
  Programming Lang: Java
  Description : annotations for software defect detection

This library provides the implementation of Java Specification Request 305.
This JSR specifies annotations for software defect detection. These
annotations can used to automatically check that methods are working as
expected.

This package is needed to be able to update libgoogle-collections-java to
a newer upstream version.



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

Re: defaulting to net.ipv6.bindv6only=1 for squeeze

[Marco d'Itri]

On Oct 25, Jarek Kami?ski  wrote:

> I run this configuration on most of my systems and don't have many
> problems. There was some problem with apache, but it's now fixed. Also
> java is broken and my bug report got ignored by sun, but it should be
> easy patchable (preloading socket() and calling setsockopt(IPV6_V6ONLY)
> works for me).
http://www.linux.it/~md/software/v6only.tgz
(Also a good teaching example about hijacking system calls!)

And now that Java has been freed I suppose that this bug can be fixed
for good... Can't it?

> There were also some problems with dovecot listening on either 0.0.0.0,
> or [::], but I don't remember details nor know they current state.
Fixed long ago.

> I don't remember any problems with vmware, but I don't use it now. Maybe
> I was connecting to it only with IPv6.
I was referring to vmware server, BTW.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

unused parameters passed to maintainer scripts

[Eugene V. Lyubimkin]

Hello developers,

I've done a small research against maintainer scripts from all binary packages
from sid distribution and discovered that some parameters which are passed to
maintainer scripts are not used at all, specifically:

- in-favour   (prerm, postinst) - for sure;
- removing   (prerm, postinst) - for sure;
-   (postrm) - most probably, checked only a
part so far.

So, the question: how do people think, is a goal to deprecate&remove these
params in dpkg and policy worthy?

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer



signature.asc
Description: OpenPGP digital signature

Re: Switch on compiler hardening defaults

[Marco d'Itri]

On Oct 25, Kees Cook  wrote:

> I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> uses[2].
Seconded.

hardening-wrapper does not looks like a solution to me since it execs
perl for each call to gcc and ld when installed (even when inactive).
And as you noticed, nobody uses it (starting with me).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: unused parameters passed to maintainer scripts

[Guillem Jover]

Hi!

On Mon, 2009-10-26 at 00:12:24 +0200, Eugene V. Lyubimkin wrote:
> I've done a small research against maintainer scripts from all binary packages
> from sid distribution and discovered that some parameters which are passed to
> maintainer scripts are not used at all, specifically:
> 
> - in-favour   (prerm, postinst) - for sure;
> - removing   (prerm, postinst) - for sure;
> -   (postrm) - most probably, checked only a
> part so far.
> 
> So, the question: how do people think, is a goal to deprecate&remove these
> params in dpkg and policy worthy?

What'd be the point of doing that? The maintainer scripts have to be
called anyway for those cases, and the fact that no one uses them now or
in Debian, does not mean there's no use for this information in the
future or in other places.

regards,
guillem


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

Re: Packages relying on HOME when building

[Norbert Preining]

Hi,

On So, 25 Okt 2009, Guillem Jover wrote:
> There's some packages which rely on HOME existing and often being
> writtable. This is broken behaviour as the package does not have any
> businesss verifying if it exists or writting outside of its build dir
> (or /tmp).

I disagree. Some upstream build mechanism simply want to do some
checks. Do we want to force each maintainer to make sure this doesn't
happen and patch it away?

I have been bitten by that with jppy which runs test suites at built time
using scons, and needs to initialize some data there for test building.

I would suggest on the contrary that HOME *will* be set by all scripts
to a newly created empty directory.


Best wishes

Norbert

---
Dr. Norbert PreiningAssociate Professor
JAIST Japan Advanced Institute of Science and Technology   prein...@jaist.ac.jp
Vienna University of Technology   prein...@logic.at
Debian Developer (Debian TeX Task Force)prein...@debian.org
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
WHAPLODE DROVE (n.)
A homicidal golf stroke.
--- Douglas Adams, The Meaning of Liff


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

Re: Packages relying on HOME when building

[Roger Leigh]

On Mon, Oct 26, 2009 at 01:17:12AM +0100, Norbert Preining wrote:
> Hi,
> 
> On So, 25 Okt 2009, Guillem Jover wrote:
> > There's some packages which rely on HOME existing and often being
> > writtable. This is broken behaviour as the package does not have any
> > businesss verifying if it exists or writting outside of its build dir
> > (or /tmp).
> 
> I disagree. Some upstream build mechanism simply want to do some
> checks. Do we want to force each maintainer to make sure this doesn't
> happen and patch it away?

Yes.  No build system has any business poking around in $HOME.  For any
reason.

If I'm building a package, the contents of my $HOME are irrelevant.  Why
should my *personal* configuration and other stuff influence *system*- and
(for upload) *distribution*-wide packaging?  Clearly for consistency and
safety, $HOME use should be forbidden entirely.

> I have been bitten by that with jppy which runs test suites at built time
> using scons, and needs to initialize some data there for test building.

That's clearly broken, any data created during the build (for whatever
purpose) should be within the build tree.  What about consistency between
builds, idempotency and other programs altering stuff during builds?

> I would suggest on the contrary that HOME *will* be set by all scripts
> to a newly created empty directory.

While this would alleviate the problem, it's still just papering over
the brokenness.  IMO we should fail hard in these cases and get the
broken build systems fixed.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: perl and perl-modules; reflexive dependencies vs. archive bloat

[Don Armstrong]

On Sun, 25 Oct 2009, Peter Samuelson wrote:
> [Don Armstrong]
> > I actually suggested that perl-modules recommend perl, but that was
> > rejected for the reason that perl-modules doesn't do anything useful
> > without perl.
> 
> You sure? 

I'm sure that it was the reason given, but I didn't have time to
investigate whether it was true or not.


Don Armstrong

-- 
Fate and Temperament are two words for one and the same concept.
 -- Novalis [Hermann Hesse _Demian_]

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: Switch on compiler hardening defaults

[Russell Coker]

On Monday 26 October 2009 09:22:26 Marco d'Itri wrote:
> > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > uses[2].
> 
> Seconded.

Thirded.


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

Bug#552411: ITP: amrita2 -- a xml/xhtml template library for Ruby

[TANIGUCHI Takaki]

Package: wnpp
Owner: tak...@debian.org
Severity: wishlist

* Package name: amrita2
  Version : 2.0.2
  Upstream Author : Taku Nakajima
* URL or Web page : http://rubyforge.org/projects/amrita2/
* License : Ruby | GPL
  Description :  a xml/xhtml template library for Ruby

 It makes html documents from a template and a model data.
 .
  * The template for amrita2 is a pure html/xhtml document without no
special tag like  or <% .. %>
 .
  * The template can be written by designers using almost any xhtml/xml
Editor.
 .
  * Need no change on Ruby code to change the view of _dynamic_ part
(not only static part) of the template
 .
  * The model data may be standard Ruby data, Hash, Array, String... or
an instance of a classes you made.
 .
  * The output is controlled by _data_ not by logic. So It's easy to
write, test, debug code. (Good for eXtreamPrograming)
 .
 Amrita2 mixes a template and model data up to a html document naturally
 matching the +id+ attribute of XML element to model data.



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

Re: Packages relying on HOME when building

[Manoj Srivastava]

On Sun, Oct 25 2009, Norbert Preining wrote:

> Hi,
>
> On So, 25 Okt 2009, Guillem Jover wrote:
>> There's some packages which rely on HOME existing and often being
>> writtable. This is broken behaviour as the package does not have any
>> businesss verifying if it exists or writting outside of its build dir
>> (or /tmp).
>
> I disagree. Some upstream build mechanism simply want to do some
> checks. Do we w to force each maintainer to make sure this doesn't
> happen and patch it away?

Since these checks seem wrong headed, yes, I would expect a
 debian developer to patch it away. This sounds like what one does to
 make weird upstream build systems sane.

> I would suggest on the contrary that HOME *will* be set by all scripts
> to a newly created empty directory.

Umm, no. This is the wrong thing to do; as members of the free
 software community, we should also cater to our users building our
 software on their machines, and not make them jump through these hoops.

manoj
-- 
After the last of 16 mounting screws has been removed from an access
cover, it will be discovered that the wrong access cover has been
removed.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Packages relying on HOME when building

[Russ Allbery]

Norbert Preining  writes:

> I would suggest on the contrary that HOME *will* be set by all scripts
> to a newly created empty directory.

Why not do that in debian/rules for the few packages that need it?

-- 
Russ Allbery (r...@debian.org)   


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