Re: should -dev libraries depending on other -dev packages?

On Wed, 2009-05-13 at 08:06 +0200, Josselin Mouette wrote: > Le mercredi 13 mai 2009 à 11:23 +1000, Brian May a écrit : > > Is this still considered to be a libtool issue? > > Yes, but instead of dropping the .la entirely, I’d recommend to simply > purge it from the dependency libs. > See /usr/sha

Re: should -dev libraries depending on other -dev packages?

Le mercredi 13 mai 2009 à 11:23 +1000, Brian May a écrit : > Is this still considered to be a libtool issue? Yes, but instead of dropping the .la entirely, I’d recommend to simply purge it from the dependency libs. See /usr/share/gnome-pkg-tools/1/rules/clean-la.mk for a way to do it. If the pkg-

Bug#528461: ITP: silverstripe -- a flexible open source Content Management System

Package: wnpp Severity: wishlist Owner: Andrew Mitchell * Package name: silverstripe Version : 2.3.1 Upstream Author : Silverstripe Limited * URL : http://www.silverstripe.org/ * License : BSD Programming Lang: PHP Description : a flexible open source

Re: should -dev libraries depending on other -dev packages?

On Wed, May 13, 2009 at 11:23:59AM +1000, Brian May wrote: > I raised this issue before: > > > > I was told no, I should not add the depends, this is a libtool issue > that is getting fixed: > >

should -dev libraries depending on other -dev packages?

I raised this issue before: I was told no, I should not add the depends, this is a libtool issue that is getting fixed: I was also told no, I should not drop the .la files:

Re: FYI: permission with rsync on people.debian.org

Osamu Aoki writes: > Hi, > > When my usual web page updates failed, I was checking my ethernet > connection ... I wondered why ... Here is the reason: > > I might have missed some announcment, ... but it seems rsync on > people.debian.org creates directories and files with 700 permission. > This

Bug#528436: ITP: xmlm -- OCaml xml manipulation module

Package: wnpp Severity: wishlist Owner: Romain Beauxis * Package name: xmlm Version : 1.0.1 Upstream Author : Daniel C. Bünzli * URL : http://erratique.ch/software/xmlm * License : BSD Programming Lang: OCaml Description : OCaml xml manipulation module

package not avaliable

Could you tell me, why package nvidia-kernel-legacy-173xx-173.14.18 is not avaliable. I use graphic card GeForce FX 5200 and can't install drivers for it. Thanks. Razumovsky Pavel.

Re: realtime kernel for Debian

Uwe Kleine-König wrote: Hello, I was wondering about how far are we with implementing a RT kernel in Debian... Some progress here? Would be nice. The patch I created that "fits" on Debian's vanilla kernel creates conflicts on the sources with the Debian patches. I hope to be able to c

Re: Bug#528061: ITP: obexd -- OBEX client and server

Zitat von Filippo Giunchedi : On Sun, May 10, 2009 at 09:15:19PM +0200, Hendrik Sattler wrote: > The obexd is an attempt to unify all current OBEX based servers for No, it isn't. It's another implementation. Implementation of OBEX client and server as a D-Bus service providing high-level

Re: Environment variables, debian/rules and dpkg-buildpackage

Raphael Hertzog writes: > On Tue, 12 May 2009, Russ Allbery wrote: >> Why would you want to disable all hardening instead of filtering out >> the flag that breaks the package? > Because no-one has identified the precise flag that breaks the package? Then filter out the ones that might cause the

Re: Environment variables, debian/rules and dpkg-buildpackage

Steve Langasek writes: > Robert Collins' suggestion in <1241989292.8026.20.ca...@lifeless-64> > seems like a good approach for this, then (modulo the syntax bits, and > putting the tool in the dpkg-* namespace instead of debhelper's > namespace). I like this idea on first glance. It matches wha

Re: Environment variables, debian/rules and dpkg-buildpackage

"Giacomo A. Catenazzi" writes: > Could maintainer do a sensible choice of CFLAGS? I don't think so. > The flags are too much dependent on architecture then the theoretical > meaning. Well, maintainers are doing so now and have been since pretty much the beginning of the packaging format, so clea

Re: Bug#528061: ITP: obexd -- OBEX client and server

On Sun, May 10, 2009 at 09:15:19PM +0200, Hendrik Sattler wrote: > > The obexd is an attempt to unify all current OBEX based servers for > > No, it isn't. It's another implementation. Implementation of OBEX client and server as a D-Bus service providing high-level functionality. sounds better?

Re: Possible mass bug filing: non-doc packages recommending doc packages

I demand that Travis Crump may or may not have written... [snip] > Popcon suggests only 8% of users are on dial-up [based on package ppp and > 'votes'] Use of ppp does not imply use of dial-up. -- | Darren Salt | linux at youmustbejoking | nr. Ashington, | Toon | Debian GNU/Linux | or ds

Re: Environment variables, debian/rules and dpkg-buildpackage

On Tue, 12 May 2009, Russ Allbery wrote: > > The fact that we can filter out some default flags doesn't make it a > > better approach IMO. If you just want to disable hardening for your > > package, it would be a pain to have to filter out a possibly evolving > > list of default flags. > > Why wou

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

On 2009-05-09 22:20:47 -0700, Steve Langasek wrote: > According to popcon, only about 68% of Debian users have exim4 > installed, and 18% have postfix installed. I don't think that's much > of a lead for exim4, considering most of the exim4 installs are > probably due solely to its status as a defa

FYI: permission with rsync on people.debian.org

Hi, When my usual web page updates failed, I was checking my ethernet connection ... I wondered why ... Here is the reason: I might have missed some announcment, ... but it seems rsync on people.debian.org creates directories and files with 700 permission. This is new behavior. If you are synch

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

On Fri, May 08, 2009 at 08:23:33AM +0100, Neil Williams wrote: > At which point, I begin to wonder if 'cron' and 'at' > cannot simply be told to use a log file if no MTA exists. > Alternatively, create a dummy-mta that converts MTA > requests into log files without all the mail headers. Log files

Bug#528335: ITP: xbattbar-acpi -- very light application that shows the current (laptop) battery status in the X window environment

Package: wnpp Severity: wishlist Owner: ghiggio * Package name: xbattbar-acpi Version : 1.2.0 Upstream Author : Matteo Marchesotti * URL : http://www.senzanome.org/xbattbar-acpi/ * License : GPL Programming Lang: C Description : very light application

Re: Environment variables, debian/rules and dpkg-buildpackage

On Mon, May 11, 2009 at 10:01:14AM -0700, Russ Allbery wrote: > If they're built by the program, then anyone who wants to properly build > the software, even if they don't want to go all the way to the package, > will need to use the program, since people will write debian/rules such > that it assu

Re: Environment variables, debian/rules and dpkg-buildpackage

On Tue, May 12, 2009 at 10:12:20AM +0200, Giacomo A. Catenazzi wrote: > Steve Langasek wrote: >> On Sun, May 10, 2009 at 11:41:30PM -0500, Manoj Srivastava wrote: >>> The only builds Debian supports are not just the buildd ones. As >>> members of the free software community, we should also

Re: Environment variables, debian/rules and dpkg-buildpackage

Russ Allbery wrote: "Giacomo A. Catenazzi" writes: Manoj Srivastava wrote: The only builds Debian supports are not just the buildd ones. As members of the free software community, we should also cater to end users building, tweaking, and rebuilding our software. You are a very s

Re: deprecating /usr as a standalone filesystem?

Manoj Srivastava writes: > On Mon, May 11 2009, Goswin von Brederlow wrote: > >> Henrique de Moraes Holschuh writes: >> >>> On Mon, 11 May 2009, Goswin von Brederlow wrote: > A separate /usr *is* the way to go if you don't want any writes in > that filesystem 99.9% of the time (i.e. wh

Re: Environment variables, debian/rules and dpkg-buildpackage

Steve Langasek wrote: On Sun, May 10, 2009 at 11:41:30PM -0500, Manoj Srivastava wrote: The only builds Debian supports are not just the buildd ones. As members of the free software community, we should also cater to end users building, tweaking, and rebuilding our software. The only

Re: Environment variables, debian/rules and dpkg-buildpackage

On Sun, May 10, 2009 at 11:41:30PM -0500, Manoj Srivastava wrote: > The only builds Debian supports are not just the buildd ones. As > members of the free software community, we should also cater to end > users building, tweaking, and rebuilding our software. The only builds Debian suppo

Re: Environment variables, debian/rules and dpkg-buildpackage

On Sun, May 10, 2009 at 11:30:43PM -0500, Manoj Srivastava wrote: > > I'm really surprised to see this approach getting traction. To me, > > this seems like a significant, unprecedented departure from the kinds > > of interfaces we've mandated in Policy in the past (i.e., environment > > variables

Re: Environment variables, debian/rules and dpkg-buildpackage

Raphael Hertzog writes: > On Mon, 11 May 2009, Russ Allbery wrote: >> That seems orthogonal. Either way, you have to get most package >> maintainers to modify their packages and test to be sure that you can >> change the default build flags. Either way, the results of that >> change will produc

Re: Environment variables, debian/rules and dpkg-buildpackage

On Mon, 11 May 2009, Russ Allbery wrote: > Raphael Hertzog writes: > > On Mon, 11 May 2009, Russ Allbery wrote: > > >> I still think Build-Options-Supported is fundamentally the wrong way > >> to implement that. You have to modify every package to add it > >> anyway, in which case you can just a