On 01/31/2013 02:45 PM, Thomas Goirand wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Thomas Goirand
>
> * Package name: python-statsdpy
> Version : 0.0.10
> Upstream Author : Florian Hines
> * URL : https://github.com/pandemicsyn/statsdpy
> * License : P
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: python-statsdpy
Version : 0.0.10
Upstream Author : Florian Hines
* URL : https://github.com/pandemicsyn/statsdpy
* License : Presumably Apache-2 (currently checking with upstream)
Program
On 30/01/2013 22:23, Игорь Пашев wrote:
> 2013/1/30 Marc Haber :
>> On Wed, 30 Jan 2013 16:25:12 +, Steve McIntyre
>> wrote:
>>> To be fair, it's similar in reverse. Some Debian developers prefer to
>>> _not_ install Ruby *at all*. Given how utterly awful the internals of
>>> the language impl
On Wed, Jan 30, 2013 at 09:21:08PM +, Thorsten Glaser wrote:
> Marc Haber zugschlus.de> writes:
>
> > In my past experience it is the usual case where and upstream and/or
> > its community takes at as a personal offense when a user is not using
> > the latest and greatest software version[1]
hi dd,
i really like the readline in bash - it seems bash is "vi complete" in vi mode.
now, i haven't looked closely, but i think the good vi mode is a patch
on (bash?) readline in debian?
in centos, i can't "df;" and delete up to next semicolon.
but on ubu^H^H^Hdebian, rlwrap uses the vanilla r
Package: wnpp
Severity: wishlist
Owner: "Stephen M. Webb"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: xorg-gtest
Version : 0.7.0
Upstream Author : Peter Hutterer
* URL : http://cgit.freedesktop.org/xorg/test/xorg-gtest/
* License : MIT/X
On 31/01/2013 05:16, Thorsten Glaser wrote:
>> On Wed, Jan 30, 2013 at 11:15 AM, Chow Loong Jin wrote:
>> >
>>> > > Having multiple package managers which don't know about each other on a
> system
>>> > > is evil™ (but in some cases, can be managed properly).
> Meh, it’s evil, period.
>
Well, r
"Lennart Sorensen" writes:
> Absolutely. As a user I have a nice package management system that I
> know how to use and which works well. I don't need another one.
> It is not the job of a language developer to invent yet another bloody
> package distribution and installation system. Just bec
On Wed, Jan 30, 2013 at 09:16:59PM +, Thorsten Glaser wrote:
> Meh, it’s evil, period.
Absolutely. As a user I have a nice package management system that I
know how to use and which works well. I don't need another one.
It is not the job of a language developer to invent yet another bloody
* Jakub Wilk , 2013-01-21, 22:17:
adequate checks quality of installed packages.
can it be used on chroots without being installed in the chroot?
like
adequate --root=/some/chroot mypkg
You can't do that currently, and I'm afraid it won't be easy to
implement.
adequate 0.4 has the --root
2013/1/30 Marc Haber :
> On Wed, 30 Jan 2013 16:25:12 +, Steve McIntyre
> wrote:
>>To be fair, it's similar in reverse. Some Debian developers prefer to
>>_not_ install Ruby *at all*. Given how utterly awful the internals of
>>the language implementation are, I'd happily support dropping Ruby
Russ Allbery debian.org> writes:
> Do you think there's something substantial missing from the existing
> Debian packaging of Perl modules? I'm quite happy with what Debian is
(Oops. Forgot to fix a spelling mistake in the Subject in my
first reply. It’s not Go!) (Hello GMane, no I was *not* to
Thorsten Glaser writes:
> My co-developer (on the MirBSD side) benz has written a script that
> almost automates creation of a port (source package) from/for a CPAN:
> http://www.slideshare.net/bsiegert/painless-perl-ports-with-cpan2port
> (It looks even MacPorts has adopted it!)
> Of course, it
Marc Haber zugschlus.de> writes:
> In my past experience it is the usual case where and upstream and/or
> its community takes at as a personal offense when a user is not using
> the latest and greatest software version[1] and does not understand
I think the Ruby case involved more:
“What, you’r
Paul Wise debian.org> writes:
> On Wed, Jan 30, 2013 at 11:15 AM, Chow Loong Jin wrote:
>
> > Having multiple package managers which don't know about each other on a
system
> > is evil™ (but in some cases, can be managed properly).
Meh, it’s evil, period.
> Some integration between dpkg and d
On Wed, 30 Jan 2013 16:25:12 +, Steve McIntyre
wrote:
>To be fair, it's similar in reverse. Some Debian developers prefer to
>_not_ install Ruby *at all*. Given how utterly awful the internals of
>the language implementation are, I'd happily support dropping Ruby
>from Debian altogether. Maybe
+++ Ian Jackson [2013-01-16 13:50 +]:
> * The concrete syntax in build-depends should not use < > but rather
>reuse the architecture qualification syntax.
I have just been told of a specific reason to avoid using '< >' :
DEP-11 proposes to use '< >' for Component metadata in binary packa
+++ Michael Biebl [2013-01-25 15:31 +0100]:
> Hi,
>
> looking over your proposal, I was missing a few things (sorry if this
> was mentioned in one of the replies, I've only skimmed over the thread).
>
> a/ It's good practice to explicitly enable/disable features via
> configure switches, to have
Marcelo wrote:
>
> This situation gets so messy, that some Ruby developers prefer
> to _not_ install ruby via dpkg at all. And they get mad when
> something in the dependency chain pulls Ruby into the system.
To be fair, it's similar in reverse. Some Debian developers prefer to
_not_ install Ruby
tranquilo.. metele sin lio
esta en el non-free aqui se usa . es el paquete firmware-qlogic
saludos
El 30 de enero de 2013 10:42, andres cespedes escribió:
> Buenos días a tod@s,
>
> Quisiera consultar con todos ustedes si alguno ha llegado a implementar
> Tarjetas HBA QLogic en Debian Stabl
tranquilo.. metele sin lio
esta en el non-free aqui se usa . es el paquete firmware-qlogic
saludos
El 30 de enero de 2013 10:42, andres cespedes escribió:
Buenos días a tod@s,
>
> Quisiera consultar con todos ustedes si alguno ha llegado a implementar
> Tarjetas HBA QLogic en Debian Stable
Hi Hilko,
Hilko Bengen writes:
> I drew a different conclusion from Ian's messages the thread you
> mentioned (see the quotes below). Apparently, one *can* build shared
> libraries using gccgo, but they are not currently usable using dlopen().
> My impression was that this means that regular use
Package: wnpp
Severity: wishlist
Owner: Peter Pentchev
* Package name: stdsyslog
Version : 0.02
Upstream Author : Peter Pentchev
* URL : http://devel.ringlet.net/sysutils/stdsyslog/
* License : BSD-2
Programming Lang: C
Description : tool to log a prog
On Tue, 29 Jan 2013 22:57:03 +0100, Michael Stapelberg
wrote:
>Wouter Verhelst writes:
>> "consistency across multiple platforms" has been claimed as a benefit
>> for allowing "gem update --system" to replace half of the ruby binary
>> package, amongst other things. It wasn't a good argument then
* Wouter Verhelst:
> On Tue, Jan 29, 2013 at 08:25:38AM +0100, Michael Stapelberg wrote:
>> Hi Hilko,
>>
>> Hilko Bengen writes:
>> > This is a pity for those of us who don't really subscribe to "get
>> > everything from github as needed" model of distributing software.
>> Yes, but at the same t
* Michael Stapelberg:
> Hilko Bengen writes:
>> This is a pity for those of us who don't really subscribe to "get
>> everything from github as needed" model of distributing software.
> Yes, but at the same time, it makes Go much more consistent across
> multiple platforms.
Apparently, upstream's
On Wed, Jan 30, 2013 at 09:22:12AM +0100, Michael Stapelberg wrote:
> > 3. Software packages from Apt cannot declare dependencies against
> > language-specific packages, for the same reasons highlighted in
> > #1.
> Irrelevant argument in our case, as outlined earlier in the
> discussion.
On Wed, Jan 30, 2013 at 8:07 PM, Stefano Zacchiroli wrote:
> On Wed, Jan 30, 2013 at 04:52:33PM +0800, Paul Wise wrote:
>> On Tue, Jan 29, 2013 at 7:55 PM, Iustin Pop wrote:
>> > So, take this as an example of another language which doesn't do shared
>> > linking but for which libraries are still p
On Wed, Jan 30, 2013 at 04:52:33PM +0800, Paul Wise wrote:
> On Tue, Jan 29, 2013 at 7:55 PM, Iustin Pop wrote:
> > So, take this as an example of another language which doesn't do shared
> > linking but for which libraries are still packaged in Debian.
FWIW, OCaml is another such example.
> Do a
On 01/30/2013 04:38 PM, Ian Campbell wrote:
> Also, I wonder if it is possible to arrange that having unpacked a git
> format source package that the remotes for debian and upstream are
> already prepopulated in the repo such that "git remotes update" would
> fetch all of the missing history withou
Hi,
Am Mittwoch, den 30.01.2013, 16:52 +0800 schrieb Paul Wise:
> On Tue, Jan 29, 2013 at 7:55 PM, Iustin Pop wrote:
> > I would add one thing here: Haskell/GHC also (currently) doesn't create
> > shared libraries, and instead builds the program statically, but the
> > Debian Haskell group still t
]] Michael Stapelberg
> I am not familiar with the Ruby situation, I only know that many Ruby
> developers seem to be very angry at Debian people. Is there a summary of
> the events that I could read?
Debian's rubygems package installed gems to a directory not in $PATH,
meaning most documentatio
On 01/28/2013 08:59 PM, Gergely Nagy wrote:
> In my opinion, a native package is the wrong choice when your only
> arguments for it is convenience.
>
> That's not a strong argument
To the contrary, I think that convenience of one or another
format is the *only* argument.
What you've listed as
On 01/29/2013 08:29 AM, Russ Allbery wrote:
> Benjamin Drung writes:
>
>> Other distributions gain from your extra work. Image the opposite. You
>> want to package a software that is only available in a downstream
>> distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a
>> non-native f
Le 30/01/2013 09:55, Paul Wise a écrit :
> On Wed, Jan 30, 2013 at 11:15 AM, Chow Loong Jin wrote:
>
>> Having multiple package managers which don't know about each other on a
>> system
>> is evil™ (but in some cases, can be managed properly).
>
> Some integration between dpkg and domain-specifi
On Wed, Jan 30, 2013 at 11:15 AM, Chow Loong Jin wrote:
> Having multiple package managers which don't know about each other on a system
> is evil™ (but in some cases, can be managed properly).
Some integration between dpkg and domain-specific package managers
could be useful. With DEP-11, we cou
On Tue, Jan 29, 2013 at 7:55 PM, Iustin Pop wrote:
> I would add one thing here: Haskell/GHC also (currently) doesn't create
> shared libraries, and instead builds the program statically, but the
> Debian Haskell group still tries to package as best as they can the
> development libraries, for all
On Wed, 2013-01-30 at 17:58 +1100, Joey Hess wrote:
> Julien Cristau wrote:
> > > Maybe I forgot the answer, but at least in terms of git and the dpkg
> > > 3.0 (git) format, why can't we simply make use of shallow cloning?
> >
> > At which point you have lost all the advantages of shipping the
>
Hi Chow,
Chow Loong Jin writes:
> 1. If software that depends on native packages is installed using "go get"
> or whatever other language-specific package manager, e.g. pip for Python
> or
> gem for Ruby is installed, there is no way to declare a dependency on
> those. For example,
39 matches
Mail list logo
