-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hendrik Sattler wrote:
> And upcoming kdebluetooth4 uses solid
BTW, is anyone working on that? (The RFP is #491580.)
Cheers,
Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.m
Robert Collins writes:
> 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
Since etch, dpkg has supported architecture wildcards such as "linux-any" and
"any-powerpc", which can, among other things, be used to express Linux-only
build dependencies like this:
Build-Depends: libcap2-dev [linux-any]
instead of one of the previous approaches:
Build-Depends: libcap2-dev |
I haven't read the whole long thread, so perhaps this has been mentioned
by someone else. Python has recently decided to convert their
documentation to reStructuredText [1]. It would make a lot of sense for
Debian to use that de-facto standard (or some subset of it) for text
typesetting in the long
On 2009-05-13, Peter Eisentraut wrote:
> Since etch, dpkg has supported architecture wildcards such as "linux-any" and
> "any-powerpc", which can, among other things, be used to express Linux-only
> build dependencies like this:
Which reminds me: could we please get similar possibilities for th
Peter Eisentraut (13/05/2009):
> The latter two approaches have obvious flaws, but it seems that no one is
> using
> the built-in dpkg approach. Is there anything wrong with it? Are people
> just
> not aware of it?
People might be using the following, which is slightly better than
listing e
Cyril Brulebois (13/05/2009):
> dpkg folks haven't been advocating their use, either.
Ah, Phil just mentioned what I had troubles remembering: the fact that
Build-Depends and Architecture can't be handled in a similar fashion.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Hi,
>>> 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 clean that up
On Wed, 13 May 2009, Morten Kjeldgaard wrote:
I haven't read the whole long thread, so perhaps this has been mentioned
by someone else. Python has recently decided to convert their
documentation to reStructuredText [1]. It would make a lot of sense for
Debian to use that de-facto standard (or so
Package: wnpp
Severity: wishlist
Owner: Jonathan Yu
* Package name: libvideo-fourcc-info-perl
Version : 1.1.5
Upstream Author : Jonathan Yu
* URL : CPAN
* License : PD
Programming Lang: Perl
Description : Retrieve information about a FourCC
--
To
On Tue, May 12 2009, Steve Langasek wrote:
> 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 Po
On Tue, May 12 2009, Goswin von Brederlow wrote:
>> I don't know if there are more blocker. Oh, and /root is a home
>> directory; unless we move that, a read only / would affect root
>> negatively.
>
> How so? Only thing I can think of is the bash history. But it is not
> like we force a read
On Tue, May 12 2009, Steve Langasek wrote:
> 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 p
Hi!
On Wed, 2009-05-13 at 12:50:03 +0300, Peter Eisentraut wrote:
> Since etch, dpkg has supported architecture wildcards such as "linux-any" and
> "any-powerpc", which can, among other things, be used to express Linux-only
> build dependencies like this:
>
> Build-Depends: libcap2-dev [linux-a
Le mercredi 13 mai 2009 à 16:16 +1000, Robert Collins a écrit :
> > If the pkg-config files or the headers still reference libdb, you’ll
> > need it as a dependency anyway, but otherwise, it can be safely removed
> > after you do that.
>
> Are the following two items correct:
> - to link statical
+ Guillem Jover (Wed, 13 May 2009 20:55:00 +0200):
> The wildcards on the binary stanza Architecture fields have also been
> supported since the beginning.
What wildcards? The "linux-any" and "powerpc-any" ones you mean? AFAIK,
Phil was inquiring about good-old Build-Depends expressions like:
On Wed, May 13, 2009 at 08:06:34AM +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 /
Le jeudi 14 mai 2009 à 09:05 +1000, Brian May a écrit :
> > 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 I do that then I will (presumably) break stati
On Thu, May 14, 2009 at 09:05:14AM +1000, Brian May wrote:
> On Wed, May 13, 2009 at 08:06:34AM +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
On Wed, May 13, 2009 at 04:16:57PM +1000, Robert Collins wrote:
> If they are both simultaneously correct then the .la should represent
> this, and be doing the right thing.
> If its not, it may be a libtool platform bug, or possibly [but unlikely]
> we've found a bug in libtools .la format.
> I'
On Wed, 2009-05-13 at 17:08 -0700, Steve Langasek wrote:
>
> > I'd need to check the source, which I don't have time to do
> just-now,
> > but I thought there was provision for static and shared linking
> having
> > different needs.
>
> There is, but libtool itself has a blemish that ensures it w
Manoj Srivastava writes:
> On Tue, May 12 2009, Goswin von Brederlow wrote:
>
>
>>> I don't know if there are more blocker. Oh, and /root is a home
>>> directory; unless we move that, a read only / would affect root
>>> negatively.
>>
>> How so? Only thing I can think of is the bash history.
Package: wnpp
Severity: wishlist
Owner: "Julián Hernández Gómez"
* Package name: python-pyftpdlib
Version : 0.5.1
Upstream Author : Giampaolo Rodola'
* URL : http://code.google.com/p/pyftpdlib/
* License : MIT
Programming Lang: Python
Description : Pyt
Hello Robert,
[ I don't read debian-devel, so please Cc: me on or point me to whatever
I should read; thanks. ]
* Robert Collins wrote on Thu, May 14, 2009 at 02:31:46AM CEST:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419228 is likely
> related.
> as is http://bugs.debian.org/cgi-bin/bug
Hi,
I recently noticed that when I'm packaging software sometimes a
i386.changes file gets created, and sometimes a source.changes file gets
created.
I couldn't find an explanation in the New Maintainer's Guide or in the
Policy Manual. I guess its something to do with the setup or type of the
pac
Malte Forkel wrote:
> Hi,
>
> I recently noticed that when I'm packaging software sometimes a
> i386.changes file gets created, and sometimes a source.changes file gets
> created.
>
> I couldn't find an explanation in the New Maintainer's Guide or in the
> Policy Manual. I guess its something to
Package: wnpp
Severity: wishlist
Owner: Thomas Schmidt
* Package name: python-flickrapi
Version : 1.2
Upstream Author : Sybren A. Stüvel
* URL : http://stuvel.eu/projects/flickrapi
* License : Python license
Programming Lang: Python
Description : Flick
27 matches
Mail list logo
