Package: wnpp
Severity: wishlist
Owner: Debian Packaging Team
* Package name: libapache2-mod-socket-policy-server
Version : 0.0.1
Copyright : Rock Solid Innovations, LLC
* URL : http://socketpolicyserver.com
* License : Apache License Version 2.0
Progr
Package: wnpp
Severity: wishlist
Owner: "Roberto C. Sanchez"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: quickfix
Version : 1.13.3
Upstream Author : Oren Miller
* URL : http://www.quickfixengine.org/index.html
* License : BSD w/ advertisin
Benjamin Drung writes:
> Am Dienstag, den 20.09.2011, 14:25 -0700 schrieb Russ Allbery:
>> I personally consider 1000 packages to be the appropriate level for
>> considering including something new in common-licenses, but I'm fairly
>> conservative on that front. The closest (by far) of the lice
Stefano Zacchiroli writes:
> On Tue, Sep 20, 2011 at 02:25:49PM -0700, Russ Allbery wrote:
>> Actually, based on the surveys I've done of licensing information, I
>> think it's unlikely that the AGPL will ever become that popular of a
>> license. I doubt it will even pass the GFDL, which we prob
On 2011-09-20 14:30, Ben Hutchings wrote:
> On Tue, 2011-09-20 at 14:23 +0200, Stefan Lippers-Hollmann wrote:
>> Personally speaking I'd assume this package would create much more
>> problems than it would solve, due to the PCI ID overlap with r8169.ko
>> shipped by the kernel packages themselves
Am Dienstag, den 20.09.2011, 14:25 -0700 schrieb Russ Allbery:
> I personally consider 1000 packages to be the appropriate level for
> considering including something new in common-licenses, but I'm fairly
> conservative on that front. The closest (by far) of the licenses not
> already listed ther
Stefano Zacchiroli writes:
> On Wed, Sep 21, 2011 at 01:28:26AM +0530, Ritesh Raj Sarraf wrote:
>> I am working on packaging the LIO tools [1]. The userspace component is
>> licensed under AGPL-3.
>> As per Debian bug #621462, the license is not part of common-licenses
>> because there aren't ma
On Tue, Sep 20, 2011 at 8:04 PM, Ben Armstrong wrote:
> While that neatly sidesteps the issue, 7.5 says:
>
> To specify which of a set of real packages should be the default to
> satisfy a particular dependency on a virtual package, list the real
> package as an alternative before the
On Tue, Sep 20, 2011 at 01:12:37PM +0200, Gerfried Fuchs wrote:
> tl;dr - what do you think, is a "Depends: foo-contrib | foo" acceptable
> for packages in main or should it be "Depends: foo | foo-contrib"
> instead?
I think the first form above ("foo-contrib | foo") is not acceptable. My
argumen
Hello Fellow Devs,
I am working on packaging the LIO tools [1]. The userspace component is
licensed under AGPL-3.
As per Debian bug #621462, the license is not part of common-licenses
because there aren't many consumers for it, yet.
I plan to document the license in the debian/copyright file and
On Tue, Sep 20, 2011 at 07:41:11PM +0200, Luk Claes wrote:
> On 09/20/2011 01:12 PM, Gerfried Fuchs wrote:
> > Policy is clear on packages in main aren't allowed to depend on
> > packages outside of main. Now in a fair amount of cases this has been
> > worked around by having the package outside
On 11-09-20 at 07:41pm, Luk Claes wrote:
> On 09/20/2011 01:12 PM, Gerfried Fuchs wrote:
> > Hi!
>
> Hi
>
> > Policy is clear on packages in main aren't allowed to depend on
> > packages outside of main. Now in a fair amount of cases this has
> > been worked around by having the packa
Package: wnpp
Owner: Dominique Dumont
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libtie-simple-perl
Version : 1.03
Upstream Author : Andrew Sterling Hanenkamp,
* URL : http://search.cpan.org/dist/Tie-Si
On 09/20/2011 01:12 PM, Gerfried Fuchs wrote:
> Hi!
Hi
> Policy is clear on packages in main aren't allowed to depend on
> packages outside of main. Now in a fair amount of cases this has been
> worked around by having the package outside of main as alternative
> dependency and a packag
Dear developers,class="gmail_quote">Thanks a bunch for the interest you have
shown in our Online Trainings. Our trainings are now held every
weekends and sessions are recorded every time. Presenting this
weekend href="http://www.ezdia.com/ma/extjs-training-live.php?utm_source=sj";
tar
Hi,
i managed to work around the problem - at least on my system.
There are at least two oddities involved
- If the kernel events happen, then always on open().
But it is quite unpredictable whether they happen at all.
xorriso and program "eject" have a higher probability to trigger
kernel
On Tue, 2011-09-20 at 14:23 +0200, Stefan Lippers-Hollmann wrote:
> Hi
>
> On Tuesday 20 September 2011, Andreas Beckmann wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Andreas Beckmann
> >
> > * Package name: r8168
> > Version : 8.025.00
> > Upstream Author : Realtek
Hi
On Tuesday 20 September 2011, Andreas Beckmann wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Andreas Beckmann
>
> * Package name: r8168
> Version : 8.025.00
> Upstream Author : Realtek NIC software team
> * URL :
> http://www.realtek.com/downloads/download
On 09/20/2011 08:43 AM, Paul Wise wrote:
> On Tue, Sep 20, 2011 at 7:12 PM, Gerfried Fuchs wrote:
> Package: bar
> Depends: foo
>
> Package: foo-contrib
> Provides: foo
While that neatly sidesteps the issue, 7.5 says:
To specify which of a set of real packages should be the default to
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
--- Please fill out the fields below. ---
Package name: opengtl
Version: 0.9.15.1
Upstream Author: Cyrille Berger
URL: http://opengtl.org
License: LGPL
Description: library for using t
On Tue, Sep 20, 2011 at 7:12 PM, Gerfried Fuchs wrote:
> tl;dr - what do you think, is a "Depends: foo-contrib | foo" acceptable
> for packages in main or should it be "Depends: foo | foo-contrib"
> instead?
I vote:
Package: bar
Depends: foo
Package: foo-contrib
Provides: foo
--
bye,
pabs
h
Dear Gerfried,
Gerfried Fuchs schrieb am 20.09.2011 13:12:
> Policy is clear on packages in main aren't allowed to depend on
> packages outside of main. Now in a fair amount of cases this has been
> worked around by having the package outside of main as alternative
> dependency and a package in m
On 20/09/2011 08:42, Ivan Shmakov wrote:
> Well, there's seems to be a consensus on this issue. What's
> next? Should this thread be summarized into a Wiki page?
> Should the bug reports be filed against the respective packages?
I would say bugs on affected packages and a patch
On 19/09/2011 10:24, Tollef Fog Heen wrote:
> ]] Vincent Danjean
>
> | I already raise (without answer) the question when is not
> | (if I recall correctly, this is the case for the i386
> | Debian architecture).
>
> $triplet really means $multiarchdir in my text.
/usr/share/pkg-config-cros
Hi!
Policy is clear on packages in main aren't allowed to depend on
packages outside of main. Now in a fair amount of cases this has been
worked around by having the package outside of main as alternative
dependency and a package in main offer basic functionality for the
package to still
Hello,
On Tue, 20 Sep 2011 08:43:03 +0100
Lars Wirzenius wrote:
> (I'd love for us to mandate GNU command line parsing, but it's not
> realistic.)
Well, at least we can send patches upstream. I guess that adding
--option=... syntax won't break any existing users, for example, as
well as adding
Package: wnpp
Severity: wishlist
Owner: Andreas Beckmann
* Package name: r8168
Version : 8.025.00
Upstream Author : Realtek NIC software team
* URL :
http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false
On Tue, Sep 20, 2011 at 01:57:54PM +0700, Ivan Shmakov wrote:
> I wonder, is there a kind of reference of the common command
> line interface conventions that the CLI's of the software
> included in Debian should adhere to?
We already have every popular style of command line inte
On Tue, 20 Sep 2011 13:57:54 +0700
Ivan Shmakov wrote:
> I wonder, is there a kind of reference of the common command
> line interface conventions that the CLI's of the software
> included in Debian should adhere to?
One which is possible to support in all interpreted languages
Hi,
Le 20/09/11 08:57, Ivan Shmakov a écrit :
> I wonder, is there a kind of reference of the common command
> line interface conventions that the CLI's of the software
> included in Debian should adhere to?
No. The only requirement is the availability of a manpage.
Regards.
30 matches
Mail list logo
