Re: usplash-theme-debian uploaded to sid

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 o

opposition against clamav-data in debian volatile

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

Re: New upstream version

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

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

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

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

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

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

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

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

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

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

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 unreproducib

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

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

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

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

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

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

Packages relying on HOME when building

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

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

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 s

Switch on compiler hardening defaults

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

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

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 t

Re: Switch on compiler hardening defaults

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 >

Re: Switch on compiler hardening defaults

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

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

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 app

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

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 in

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

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

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

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

unused parameters passed to maintainer scripts

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

Re: Switch on compiler hardening defaults

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

Re: unused parameters passed to maintainer scripts

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

Re: Packages relying on HOME when building

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 bu

Re: Packages relying on HOME when building

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 o

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

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

Re: Switch on compiler hardening defaults

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

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

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 I

Re: Packages relying on HOME when building

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 it

Re: Packages relying on HOME when building

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 UNS