Bug#642282: ITP: libapache2-mod-socket-policy-server -- libapache2-mod-socket-policy-server is an Apache2 module for serving Adobe socket policies.

2011-09-20 Thread Daniel Kauffman 
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
  Programming Lang: C
  Description : An Apache2 module for serving Adobe socket policies.

libapache2-mod-socket-policy-server is an Apache2 module for
serving Adobe socket policies.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110921041704.14967.51357.reportbug@localhost

Bug#642268: ITP: quickfix -- FIX protocol library

2011-09-20 Thread Roberto C. Sanchez 
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/ advertising clause
  Programming Lang: C
  Description : FIX protocol library

 The Financial Information eXchange (FIX) Protocol is a message standard
 developed to facilitate the electronic exchange of information related to
 securities transactions. It is intended for use between trading partners
 wishing to automate communications.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJOeRdyAAoJECzXeF7dp7IPWtoQAJnFkCrE4+/yic+ZGhfg/zC6
rIe6UceVmq+XMTfShM5lhp+UfRGL8DTc9g/gEoklnBfXh8hA3UdSJ8+w2Y5dfI77
M1Gm+jmklRXwD4bPrmns8s+3TNfLpCQzBG3p2guM5Cu6tfxgJJl9uaBZbUCJxYWa
0BfkszCbC74xuwcC5+JNvsmmefXxrw+4OZzBNJD2vXac0TP1mubpm6kTQpYakkYB
SvFnz0MJVat9OKOj7RBr/XOzrkTMbtVfD5r3resF/ZQZ4H6/FIwmRcPYLVrGF9KK
GbG+GaabxPTZPr66SYQTS/OaFoMDXCgGu/xg1qgwzFcligffImIa9+aVMP6pFMQC
QBRAf5Gn05LfLHLfAQl9hXDUxST83jdS2YC0h6uQyKiYZP9uQ5Q/lIe9u/KStOnc
Bg2oLk/Ufpv94J6hgbiT0Zbmex6acunzGHBp5kBQxx00+hV5Wy3K7lrRjEOjhOQF
wldh6YVYIp0fGh7B2VGRs5jRyNb4t6nOSyBe4DZvDcSMpnKAtc7Vv60tFpkduME9
EvmX7xE+0FezhbNCp7FVHqA/JVZXDb+FtLMgoBYS0gvJdrJRWkZESR+0JLBPTnbK
oiRdruVyRpwr4JcDaE7snOexPEPKc+GA90IET2+3T312+RutPuvDGmh/gp7LdO7i
VqIc/IzbUBNbL2M9ztPQ
=IpZH
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110920224528.18686.47344.report...@miami.connexer.com

Re: packages under the AGPL-3 license

2011-09-20 Thread Russ Allbery 
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 licenses not
>> already listed there, and the best case for inclusion, is the MPL 1.1
>> at 740 packages.  The next closest contender would be the CDDL at 219
>> packages.

> Probably many people of the Mozilla extension maintainers team would
> love to see the MPL-1.1 in common-licenses.

There's oodles of discussion at:

http://bugs.debian.org/487201

My impression is that the consensus may be shifting, but there are various
things that make it a less appealing inclusion candidate than it might
appear at first glance, such as the fact that it's a third and (by Debian)
deprecated choice of alternative license for most packages that reference
it, the iceweasel debian/copyright file (and those packages that copied
its handling) doesn't bother to include a copy inline because of that, and
it's a disliked (albeit DFSG-free) license within Debian.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877h5228lj@windlord.stanford.edu

Re: packages under the AGPL-3 license

2011-09-20 Thread Russ Allbery 
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 probably should
>> not have accepted into common-licenses.

> Thanks for this prompt feedback.

> ... and gosh, I didn't imagine AGPL share was so low in the Debian
> archive. (Countering bad gut feelings is what data are useful for!)

Yes, indeed.  :)  I supported adding the GFDL 1.3 to common-licenses on
the basis of a similar gut feeling, and it's still sitting there at only
79 packages.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87boue28ry@windlord.stanford.edu

Re: Bug#642198: ITP: r8168 -- dkms source for the r8168 network driver

2011-09-20 Thread Andreas Beckmann 
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. This driver claims 
>> 10ec:8168, which is also taken by the in-kernel r8169.ko module. 
> [...]
> 
> Agree, this should not be added to the archive.

OK, that's fine. I don't really care.

Andreas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e7901d4.40...@abeckmann.de

Re: packages under the AGPL-3 license

2011-09-20 Thread Benjamin Drung 
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 there, and the best case for inclusion, is the MPL 1.1 at
> 740 packages.  The next closest contender would be the CDDL at 219
> packages.

Probably many people of the Mozilla extension maintainers team would
love to see the MPL-1.1 in common-licenses.

-- 
Benjamin Drung
Debian & Ubuntu Developer


signature.asc
Description: This is a digitally signed message part

Re: packages under the AGPL-3 license

2011-09-20 Thread Russ Allbery 
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 many consumers for it, yet.

> The data referenced by that buglog are 15 months old. Although I doubt
> they've changed enough to overtake the minimum threshold, it would be
> nice to re-evaluate them.  For one thing, the growth rate might give
> insights about the future "market share" of the license.

> TBH, AGPL is likely to become a popular license. Having maintainers
> include it verbatim in packages nowadays, to factor it out a few years
> from now, doesn't seem like a useful exercise...

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 probably should not have
accepted into common-licenses.

Due to a combination of a limitation of the Lintian lab format and the
file system on lintian.d.o, the Lintian lab is not currently complete, but
I can get partial information.  I updated the license check script in the
Policy tools directory and ran it against the current Lintian lab.  It
shows 31 packages in the archive covered by the AGPL version 3, which is
of course far, far too few to even be thinking about common-licenses at
this point.

Here's the complete statistics for the licenses that the tools script
knows how to search for.  The restriction to 31,998 packages is because
we've hit the link count maximum for an ext3 directory.

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 there, and the best case for inclusion, is the MPL 1.1 at
740 packages.  The next closest contender would be the CDDL at 219
packages.

AGPL 3   31
Apache 2.0 1474
Artistic   2776
Artistic 2.0 50
BSD (common-licenses)   569
CC-BY 3.068
CC-BY-SA 3.0133
CDDL219
CeCILL   20
CeCILL-B 11
CeCILL-C 20
GFDL (any)  939
GFDL (symlink)  395
GFDL 1.2550
GFDL 1.3 79
GPL (any) 21496
GPL (symlink)  8326
GPL 1  2159
GPL 2 10821
GPL 3  3785
LGPL (any) 7977
LGPL (symlink) 2134
LGPL 2 5689
LGPL 2.1   4084
LGPL 3  947
LaTeX PPL   181
LaTeX PPL (any) 131
LaTeX PPL 1.3c  120
MPL 1.1 740
SIL OFL 1.0  16
SIL OFL 1.1  88

Total number of packages: 31998

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sjnq29eq@windlord.stanford.edu

Re: alternative dependency ordering - with respect of packages in main

2011-09-20 Thread Paul Wise 
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 virtual one.
>
> But that doesn't specify a 'must' (or even 'should').

Well, obviously there would be a package foo in main too so this would
not be violated. I should have included such a package in my example.

> What I'm concerned
> about is if someone has already added contrib or non-free to their apt
> sources for the purpose of providing some software essential to their
> needs, by not specifying which dependency is preferable here, the user
> will arbitrarily end up with a free or non-free 'foo' which may or may
> not be what they want. Though arguably, if they wanted only the
> "essential" stuff from contrib/non-free, they could use pinning to
> ensure that's all they take.

In my intended case I believe they always end up with foo from main,
only if they choose foo-contrib will they get it, which is how I think
it should be. main should not reference packages from contrib/non-free
in any way.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6HCX=2g5vm9kc5qptsxot_fmi81eey2bj+moduhycp...@mail.gmail.com

Re: alternative dependency ordering - with respect of packages in main

2011-09-20 Thread Stefano Zacchiroli 
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
argument is that we should make choice of non-free software an explicit
action of Debian users, rather than an implicit/automated one.

Most of our package manager frontends — including the default one — walk
dependency formulae left to right, preferring the first alternative if
it is satisfiable. That means that a user installing a package with a
dependency like the first form above will install foo-contrib without
necessarily knowing they are doing so.

I understand it can be argued that users enabling contrib/non-free have
decided to opt-in for non-free software. But I still don't think such a
system-wide should be taken as a wildcard to install contrib/non-free
packages without user consent.

If there were a way to fix a system-wide dependency solving preference
that would favor main packages by default, unless explicitly customized
by the sysadm, the first form might be (more) acceptable. I don't think
it is acceptable without it.

Just my 0.02€,
Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

packages under the AGPL-3 license

2011-09-20 Thread Ritesh Raj Sarraf 
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 proceed.

lintian reports error, E: python-configshell:
copyright-should-refer-to-common-license-file-for-gpl, for which I've
filed a bug report.


PS: Please CC me in replies.

[1] http://linux-iscsi.org/wiki/Main_Page

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System




signature.asc
Description: OpenPGP digital signature

Re: alternative dependency ordering - with respect of packages in main

2011-09-20 Thread Roger Leigh 
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 of main as alternative
> > dependency and a package in main offer basic functionality for the
> > package to still be able to work.
> > 
> >  I know that the buildd system likes to pull in the first package in
> > such an alternative dependency chain.  And now I start to wonder:
> 
> That being said, it might be that having a predictable set of build
> dependencies on the buildds is not wanted anymore?

I'm fairly certain that we do want predictability and consistency.

> >  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?
> 
> Personally I think we should stay with a predictable set of build
> dependencies on the buildds (only have them look at the first
> alternative) and we should stay with having a package in main as the
> first alternative of a build dependency of a package in main.

Just to comment on the build dependencies: first-only alternatives
are only implemented for Build-Depends and Build-Depends-Indep
(for all resolvers).  They get stripped when computing the set of
packages to install.

Alternatives in regular package Depends are delegated to
apt-get/aptitude, and what is installed will depend upon what is
available and installable.  For packages being build for main, the
contrib and non-free archives should not be available, so such
alternatives should not be considered.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110920181701.gq3...@codelibre.net

Re: alternative dependency ordering - with respect of packages in main

2011-09-20 Thread Jonas Smedegaard 
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 package outside of main as 
> > alternative dependency and a package in main offer basic 
> > functionality for the package to still be able to work.

I am frankly surprised this behaviour is considered policy-compliant!


> >  Is it allowed for a package in main to have a package _outside_ of 
> > main as first component of an alternative dependency?  The package 
> > in question is extremely unlikely to ever be used as Build-Depends, 
> > so this is of a more general question.
> 
> Strictly speaking having an alternative dependency outside main is 
> already bending the rules very far. The only reason I see why an 
> alternative outside main is allowed, is that one could easily do 
> something similar when using Provides.

I don't find it similar:

Setting "Depends:" or "Recommends" means the package in main encourages 
the use of material outside of main.

Setting "Provides:" means the package outside of main encourages the use 
of material outside of main.



Regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Bug#642244: ITP: libtie-simple-perl -- Tie made easy

2011-09-20 Thread Dominique Dumont 

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-Simple/
* License : Perl like
  Programming Lang: Perl
  Description : unknown

This package provides the Perl module Tie::Simple. This module adds to
tie function the ability to quickly create new types of tie objects
without creating a complete class. It does so in such a way as to try and
make the programmers life easier when it comes to single-use ties that I find
myself wanting to use from time-to-time.

The Tie::Simple module is actually a front-end to other classes which really
do all the work once tied, but this package does the dwimming to
automatically figure out what you're trying to do.

This package is a build dependency of libsdl-perl

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/


signature.asc
Description: This is a digitally signed message part.

Re: alternative dependency ordering - with respect of packages in main

2011-09-20 Thread Luk Claes 
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 package in main offer basic functionality for the
> package to still be able to work.
> 
>  I know that the buildd system likes to pull in the first package in
> such an alternative dependency chain.  And now I start to wonder:

The reason the buildd system only looks at the first alternative is to
have a predictable set of build dependencies. The same is true for
having the first alternative being in main as otherwise it might depend
on the config of the buildd whether it will install the dependency in
main or another one.

That being said, it might be that having a predictable set of build
dependencies on the buildds is not wanted anymore?

>  Is it allowed for a package in main to have a package _outside_ of main
> as first component of an alternative dependency?  The package in
> question is extremely unlikely to ever be used as Build-Depends, so this
> is of a more general question.

Strictly speaking having an alternative dependency outside main is
already bending the rules very far. The only reason I see why an
alternative outside main is allowed, is that one could easily do
something similar when using Provides.

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

Personally I think we should stay with a predictable set of build
dependencies on the buildds (only have them look at the first
alternative) and we should stay with having a package in main as the
first alternative of a build dependency of a package in main.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e78d037.3090...@debian.org

Fast track learning of ExtJS - Exclusive Training Online

2011-09-20 Thread Sulabh J 
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";  
target="_blank">  
ExtJS Live Introductory Session for  
Beginners Limited Seats Left for  
this Weekend Batch !href="http://www.ezdia.com/ma/extjs-training-live.php?utm_source=sj";  
target="_blank">Book Your Seat Now >> Please join us for this  
60-minute walk-through of proven unconventional  
ExtJS Training  
about how it works, to work on and make widgets in  
Extjs. This "Online" session is scheduled  
for a 60-minute presentation with an additional 45 minutes at the end for  
any questions. Presented by Imran khan Mohammed style="font-size: 130%; color: rgb(192, 0, 0);">Saturday, September 24  
& 25, 2011 10:30 AM - 12:30 AM PST The session will  
cover:   Introduction to Object Oriented  
JavaScript High performance, customizable UI  
widgetsWell designed and extensible Component model  
An intuitive, easy to use API Let us know what else  
are you looking for in this training ... Mail me  
at mailto:sulab...@ezdia.com";  
target="_blank">sulabh.j@ezdia.com  
Few words about the Presenter : Our presenter (Imran) is  
seasoned ExtJS expert with hands on  
expertise in Web 2.0 & eCommerce based platforms and brings proven  
record with small startups to fortune 500 clients. You may find additional  
information about his profile at: href="http://in.linkedin.com/in/mohammedimrankhan";  
target="_blank">http://in.linkedin.com/in/mohammedimrankhan  
Mark the date and time into your calendar now! We look forward to  
meeting you! eZdia Inc. Arena Place One 7322 Southwest FWY,  
Suite 1100 Houston, TX 77074

Re: How to coordinate a DVD burn program with udev ?

2011-09-20 Thread Thomas Schmitt 
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 events than wodim.
  (Watched by: udevadm monitor --kernel )

- udev patience is between 4 and 7 seconds.
  4 seconds and a kernel event can trigger link vanishing even if the
  tray was already loaded. 7 seconds and kernel event happen only if
  the tray had to be loaded and thus the xorriso run needed long enough.
  Program "eject" does not run that long and causes no vanishing.
  Possibly it does not block out udev, anyway.

An accordingly odd workaround in libburn looks like:

  fd = open("/dev/sr0", O_RDWR | O_EXCL | O_NDELAY);
  if (fd >= 0) {
  close(fd);
  usleep(200);
  fd = open("/dev/sr0", O_RDWR | O_EXCL | O_NDELAY);
  }

instead of simply

  fd = open("/dev/sr0", O_RDWR | O_EXCL | O_NDELAY);

O_EXCL on /dev/sr0 is supposed to block out any other open() which
uses O_EXCL itself. (Not a POSIX feature.)
It might be a decisive ingredient for the mess, but it is the only
halfways reliable means to coordinate burn programs so that they
do not use the same drive.

It is still unclear why wodim's open() triggers much fewer kernel
events than the one of libburn.
But above workaround has a similar effect.

After triggering a kernel event with my workaround once, the probability
gets significantly lower for kernel events to be caused by old libburn. 
But it is still not 0.

---

I would still like to discuss the unpredictability of kernel events
and the harsh reaction of udev on inaccessible drives.
The workaround is actually a race condition. It might break with the
next change in kernel or udev.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/98760873814254@192.168.2.69

Re: Bug#642198: ITP: r8168 -- dkms source for the r8168 network driver

2011-09-20 Thread Ben Hutchings 
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 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#2
> > * License : GPL2+
> >   Programming Lang: C
> >   Description : dkms source for the r8168 network driver
> > 
> >  r8168 is the Linux device driver released for RealTek RTL8168B/8111B,
> >  RTL8168C/8111C, RTL8168CP/8111CP, RTL8168D/8111D, and RTL8168DP/8111DP, and
> >  RTK8168E/8111E Gigabit Ethernet controllers with PCI-Express interface.
> >  .
> >  This driver should only used for devices not yet supported by the in-kernel
> >  driver r8169.
> 
> 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. This driver claims 
> 10ec:8168, which is also taken by the in-kernel r8169.ko module. 
[...]

Agree, this should not be added to the archive.

If people are in a hurry to get new support for new devices, we can
cherry-pick later upstream changes to r8169.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: Bug#642198: ITP: r8168 -- dkms source for the r8168 network driver

2011-09-20 Thread Stefan Lippers-Hollmann 
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/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false#2
> * License : GPL2+
>   Programming Lang: C
>   Description : dkms source for the r8168 network driver
> 
>  r8168 is the Linux device driver released for RealTek RTL8168B/8111B,
>  RTL8168C/8111C, RTL8168CP/8111CP, RTL8168D/8111D, and RTL8168DP/8111DP, and
>  RTK8168E/8111E Gigabit Ethernet controllers with PCI-Express interface.
>  .
>  This driver should only used for devices not yet supported by the in-kernel
>  driver r8169.

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. This driver claims 
10ec:8168, which is also taken by the in-kernel r8169.ko module. 

Upstream, all r8168 devices are (or will be) supported by the r8169.ko
module (r8168.ko doesn't exist in the kernel) and RealTek recently 
started to participate in developing r8169.ko mainline. Which means the
overlap will only increase from kernel version to kernel version in 
unstable, even if you'd restrict this package to squeeze (and it's not 
likely that a completely new packages would be accepted for upcoming 
point releases) the package would conflict with the kernel team's 
efforts to backport support for newer devices[1], as those also 
backport support for newer devices in stable.

Please also consider that systems using both onboard PCIe r8168 and 
additional PCI r8169 cards are not an uncommon situation, which is not
possible using this proposed driver.

>  This package provides the dkms source code for the r8168 kernel modules.
>  Kernel source or headers are required to compile these modules.
> 
> I just came along this in #debian last week, helping someone to get this
> module built and installed (upstream build system does not work properly
> on kernel 3.x) because the in-kernel module r8169 did not support his
> NIC.

Is this driver really needed with kernel 3.0, what about 3.1~rc in 
experimental? If it's still missing, looking at net-next[2] it might be
easier to backport a small patch adding support for the affected device
than dealing with conflicting modules both claiming the same device IDs.

from 2.6.39 to 3.0, r8169.ko gained support for:
- RTL8168E/RTL8111E

and learned about new chipset variants for:
- RTL8105
- RTL8168DP

from 3.0 to 3.1~rc, r8169.ko gained support for:
- RTL8111E-VL

and learned about new cards like:
- D-Link DGE-530T rev C1 (DLG10028C)

For even longer, r8169.ko supports (looking at 3.1~rc):
- 3 different RTL8168b/8111b variants
- 4 RTL8168c/8111c variants
- 3 RTL8168cp/8111cp variants
- 2 RTL8168d/8111 variants
- 3 RTL8168dp/8111dp variants
- 2 RTL8168e/8111e variants 

…which doesn't leave much of r8168.ko uncovered.

> I did this package just as a first experiment with dkms, the module
> builds fine with squeeze and sid kernels. I don't have the hardware to
> actually test it. So if someone who actually needs it wants to take over
> maintainership, he is welcome.

Regards
Stefan Lippers-Hollmann

[1] http://lists.debian.org/debian-kernel/2011/09/msg00540.html
[2] git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
git://github.com/davem330/net-next.git (temporarily)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201109201423.29489.s@gmx.de

Re: alternative dependency ordering - with respect of packages in main

2011-09-20 Thread Ben Armstrong 
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
 satisfy a particular dependency on a virtual package, list the real
 package as an alternative before the virtual one.

But that doesn't specify a 'must' (or even 'should'). What I'm concerned
about is if someone has already added contrib or non-free to their apt
sources for the purpose of providing some software essential to their
needs, by not specifying which dependency is preferable here, the user
will arbitrarily end up with a free or non-free 'foo' which may or may
not be what they want. Though arguably, if they wanted only the
"essential" stuff from contrib/non-free, they could use pinning to
ensure that's all they take.

Ben


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e788132.2050...@sanctuary.nslug.ns.ca

Bug#642208: ITP: opengtl -- Set of library for using transformation algorithms

2011-09-20 Thread Jan Kriho 
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 transformation algorithms


The Graphics Transformation Languages is a set of library 
for using and integrating transformation algorithms (such as 
filter or color conversion) in graphics applications. 
 
The goal is to provide the tools, languages and libraries to 
create generic transformation for graphics. Those 
transformations could then be used by different programs 
(Krita, GIMP, CinePaint, GEGL…).



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201109201357.41612.erbur...@gmail.com

Re: alternative dependency ordering - with respect of packages in main

2011-09-20 Thread Paul Wise 
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

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6gmiezzzyb3t0zbp-mtf1xyrdvglmarb2pmkcyncix...@mail.gmail.com

Re: alternative dependency ordering - with respect of packages in main

2011-09-20 Thread Kai Wasserbäch 
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 main offer basic functionality for the
> package to still be able to work.
> 
>  I know that the buildd system likes to pull in the first package in
> such an alternative dependency chain.  And now I start to wonder:
> 
>  Is it allowed for a package in main to have a package _outside_ of main
> as first component of an alternative dependency?  The package in
> question is extremely unlikely to ever be used as Build-Depends, so this
> is of a more general question.

I'd say – from a technical viewpoint – it should be ok, because the buildds (for
main) just shouldn't offer the possibility to install something from outside of
main. Though I must admit, that I've no idea, whether this is enforced by the
buildds or not (I would hope so, because, otherwise we might end up with
Policy-broken builds anyway, in case the main B-D isn't satisfiable at build
time, while the non-main is).

>  What also might be used as argument is the social contract, DFSG #4:
> "Our priorities are our users and free software" -- it can be argued
> that we don't put the priority on free software in such a case.
> 
>  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?

Ideologically I'd vote for the latter, just to make sure people can rely on
getting the free/open/libre installation on default, even if they might need
contrib or non-free in some places. If you want/need (maybe add a README.Debian,
explaining the differences) the contrib/non-free functionality, you can manually
install that.

Kind regards,
Kai Wasserbäch



-- 

E-Mail: cu...@debian.org
IRC: Curan
Jabber: dri...@debianforum.de
URL: http://wiki.debian.org/C%C3%B9ran
GnuPG: 0xE1DE59D2  0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2



signature.asc
Description: OpenPGP digital signature

Re: Depends: logrotate (forever and ever and ever)

2011-09-20 Thread Vincent Danjean 
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 for lintian to add a
check.

  Regards,
Vincent


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e787a0b.1010...@free.fr

Re: Could the multiarch wiki page be explicit about pkgconfig files?

2011-09-20 Thread Vincent Danjean 
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-crosswrapper uses:
triplet=`basename $0 | sed -e 's:-pkg-config::'`
PKG_CONFIG_LIBDIR=/usr/${triplet}/lib/pkgconfig pkg-config $@
  So, here, triplet is not multiarchdir.

It has been suggested is this thread that
/usr/lib//pkgconfig/ should be used. In this case, triplet is
*not* multiarchdir. So /usr/share/pkg-config-crosswrapper needs to be fixed.

> |   So, how pkg-config (and other tools) does the  ->
> |  translation? Is it hard-coded?
> 
> $(dpkg-architecture -qDEB_BUILD_MULTIARCH) at build time, as you can see
> in the rules file.

dpkg-architecture can convert Debian arch to triplet (DEB_HOST_GNU_TYPE)
and multiarchdir (DEB_HOST_MULTIARCH)

  Is there an easy way to convert triplet to multiarchdir ? (which is
what is needed for pkg-config-crosswrapper)

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e78792f.7070...@free.fr

alternative dependency ordering - with respect of packages in main

2011-09-20 Thread Gerfried Fuchs 
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 be able to work.

 I know that the buildd system likes to pull in the first package in
such an alternative dependency chain.  And now I start to wonder:

 Is it allowed for a package in main to have a package _outside_ of main
as first component of an alternative dependency?  The package in
question is extremely unlikely to ever be used as Build-Depends, so this
is of a more general question.

 What also might be used as argument is the social contract, DFSG #4:
"Our priorities are our users and free software" -- it can be argued
that we don't put the priority on free software in such a case.

 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?

 Thanks for answering to the short strawpoll,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110920111237.ga24...@anguilla.debian.or.at

Re: common CLI conventions?

2011-09-20 Thread Andrew O. Shadura 
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 -- most probably won't make anyone unhappy.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#642198: ITP: r8168 -- dkms source for the r8168 network driver

2011-09-20 Thread Andreas Beckmann 
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#2
* License : GPL2+
  Programming Lang: C
  Description : dkms source for the r8168 network driver

 r8168 is the Linux device driver released for RealTek RTL8168B/8111B,
 RTL8168C/8111C, RTL8168CP/8111CP, RTL8168D/8111D, and RTL8168DP/8111DP, and
 RTK8168E/8111E Gigabit Ethernet controllers with PCI-Express interface.
 .
 This driver should only used for devices not yet supported by the in-kernel
 driver r8169.
 .
 This package provides the dkms source code for the r8168 kernel modules.
 Kernel source or headers are required to compile these modules.

I just came along this in #debian last week, helping someone to get this
module built and installed (upstream build system does not work properly
on kernel 3.x) because the in-kernel module r8169 did not support his
NIC.

I did this package just as a first experiment with dkms, the module
builds fine with squeeze and sid kernels. I don't have the hardware to
actually test it. So if someone who actually needs it wants to take over
maintainership, he is welcome.

Andreas



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110920084647.2061.97568.reportbug@calzone.localnet

Re: common CLI conventions?

2011-09-20 Thread Lars Wirzenius 
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 interface convention
in Debian, and most of the unpopular ones, too. There's no consistency
across programs, and we basically just accept whatever upstream uses,
unless that has serious problems. Just being different from everything
else is not a serious problem, it's just bad taste.

(I'd love for us to mandate GNU command line parsing, but it's not
realistic.)

-- 
Freedom-based blog/wiki/web hosting: http://www.branchable.com/


signature.asc
Description: Digital signature

Re: common CLI conventions?

2011-09-20 Thread Neil Williams 
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, all
compiled languages, all toolkits and all software no matter how long
ago it was written? No.

IMHO it is far, far too late to worry about standardising such things
because 90% of the other command line tools in existence depend on the
particular idiosyncratic implementations of other tools. That is one
migration which is truly not worth the pain.

If this was really an issue, it should have been sorted out when GNU
really was new.

It doesn't even hold that tools in a similar space operate with the
same conventions. About the best you can hope for is that the same
developers use the same mechanisms with most of the software they write
when using the same language because programmers are lazy. Switch from
perl to shell or C to python and all that vanishes. It is just a
pointless waste of effort to make them consistent when the underlying
tools are not consistent, the language/library implementations are not
consistent and the particular software itself has different
requirements to the tools it uses itself.

>   One more issue is that some commands implement GNU long options
>   with a particular flaw that --option=ARGUMENT is /not/ accepted
>   as synonymous to --option ARGUMENT, which makes it impossible to
>   use the following short form:

Other commands don't use either a space or equality operator, e.g.
dpkg-buildpackage uses -aarmel but the chances of changing that now are
zero. Too many tools and scripts rely on the current mechanisms.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpJjTpkxcOlD.pgp
Description: PGP signature

Re: common CLI conventions?

2011-09-20 Thread Thibaut Paumard 
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.





-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e784199.3070...@free.fr