Re: Pristine source from upstream VCS repository

[Manoj Srivastava]

On Thu, Mar 05 2009, Russ Allbery wrote:

> Ben Finney  writes:
>
>> It's been brought to my attention that this approach actually conflicts
>> with the above section of policy.
>>
>> Am I right in thinking that the ‘get-orig-source’ target should ignore
>> the version strings in ‘debian/changelog’, and should instead get
>> whatever version is the latest available from upstream?
>
> I think the way that you're using it is more useful (and possible) than
> doing what an exact reading of the current text would indicate, and I do
> the same thing that you're doing.
>

However, as written, the wording does suggest that the latest
 version  is what will be acquired, and any shift in meaning will make
 currently conforming packages buggy. 

> http://bugs.debian.org/466550 is somewhat related.
>
> For packages with non-trivial rules to generate the upstream source
> tarball used with Debian, it's very difficult or impossible to write a
> future-proofed version of that cdoe that will work with arbitrary future
> versions from upstream.  However, documenting the method used to generate
> the *current* version will let people modify that target as needed to
> package future versions.

I beg to differ. It would be hard for me to assure that any rule
 run which looks at the debian/changelog version will actually work at
 any time in the future.

I have upstreams that ship released software tarballs that match
 a pattern I can feed uscan; but older versions are often purged from
 the site quickly. I can, then, use  the pattern to download the latest
 version (perhaps using uscan), and then unpack it, rm -rf the debian
 directory, and repack it, preserving the version number, without much
 hassle.

Given that at least one version of the software is guaranteed to
 exist, I can craft a generic get-orig0source rule that will work -- but
 if I pay attention to the versoin, the rule will fail just days or
 weeks after upload.

Making people remove a generic get-orig-source that actually
 gets the latest source package from upstream by making it violate the
 new version of policy would not be a good thing, in my opinion,
 Silenty reverting the original meaning of the target, without a
 transition plan, instead of creating a new target with the new meaning
 is not usually how Debian policy used to work.

I am wondering which is of more use to the end users as well: I
 can always get the sources of the package I have already on my disk
 from Debian, but getting the latest munged source seems more useful to
 me.


manoj
-- 
You may have heard that a dean is to faculty as a hydrant is to a
dog. Alfred Kahn
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Accelerated video cards and non-free firmware

[Marco d'Itri]

On Mar 10, Ben Hutchings  wrote:

> The firmware used for 3D acceleration in the r128 (ATI Rage 128), radeon
> (ATI Radeon) and mga (Matrox G200/G400/G550) drivers is non-free and
> will be moved from the linux-image packages into a new firmware-linux
> package starting with Linux 2.6.29.
Do you know about any 3D card having a free firmware? Because I know
none.
The difference is that these cards do not waste on-board flash for it
and have it uploaded by the host.

> The free drivers for Intel and Nvidia graphics hardware should support
> 3D acceleration without the need for non-free firmware.  I'm not sure
I am quite sure that this is not correct.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: inetd's status in Debian

[Marco d'Itri]

On Mar 10, Luk Claes  wrote:

> Btw, lots of packages are depending on update-inetd while it's
> guaranteed to be available when depending on inet-superserver.
Indeed, this is broken. IIRC some helpful soul started reporting "bugs"
asking to depend on update-inetd too...

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: inetd's status in Debian

[Thijs Kinkhorst]

On moandei 9 Maart 2009, Pierre Habouzit wrote:
> Just looking at the packages requiring an inet superserver, you'll see that
> it's probably that nowadays users don't need a superserver at all[0].
>
> I'm wondering if making super servers become optionnal wouldn't be a worthy
> goal for squeeze.

Yes, I think it would make sense to make them priority optional. Currently the 
standard installation does not include any active services so inetd just 
lingers around doing nothing. Demoting it to optional will do the right 
thing, installing a super server just in time: when you're also installing 
some package depending on it.


cheers,
Thijs


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

Re: Accelerated video cards and non-free firmware

[James Collier]

On Tue, 2009-03-10 at 08:46 +0100, Marco d'Itri wrote:
> On Mar 10, Ben Hutchings  wrote:
> 
> > The firmware used for 3D acceleration in the r128 (ATI Rage 128), radeon
> > (ATI Radeon) and mga (Matrox G200/G400/G550) drivers is non-free and
> > will be moved from the linux-image packages into a new firmware-linux
> > package starting with Linux 2.6.29.
> Do you know about any 3D card having a free firmware? Because I know
> none.
> The difference is that these cards do not waste on-board flash for it
> and have it uploaded by the host.
> 
> > The free drivers for Intel and Nvidia graphics hardware should support
> > 3D acceleration without the need for non-free firmware.  I'm not sure
> I am quite sure that this is not correct.

Indeed it is not correct.
I can't speak for ATI(AMD) or Intel (I believe Intels are free but
unsure about 3D).
I can, however, speak for Nvidia. There is a long history of
non-cooperation between NVidia and the Free Software community.
Currently there is a Free implementation of a driver for NVidia cards
called "nv"[1] which only supports rendering 2D. However the
"Nouveau"[2] is a Free implementation for 3D support for some cards.

[1]: http://xorg.freedesktop.org/wiki/nv
[2]: http://nouveau.freedesktop.org/wiki/


---
/***
*INTERESTING FACT: *
* GNU/Linux is a state of the art, fully featured Operating System *
* with your freedom bundled inside. Boasting lightning fast*
* startup times; intrinsic security designed from the start;   *
* amazing eye candy and 3D effects; thousands of people all around *
* the world working on such things as documentation and code every day.*
* Best of all it's free.   *
* Value your freedom?  *
* Visit fsf.org & badvista.org *
***/ 

My System: Description: Ubuntu 8.04.2 
Release: 8.04 
GNU/Linux 2.6.24-23-generic i686 
My website: https://launchpad.net/~james-collier412
   www.morerowdy.blogspot.com
Public key available from: http://keyserver.ubuntu.com:11371/ 
Free Software Foundation Associate Member #6883 
Become an associate member yourself:
http://www.fsf.org/jf?referrer=6883 

Started: Tue Mar 10 18:54:50 EST 2009


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

Bug#518958: ITP: screen-profiles -- a set of useful profiles and a profile-switcher for GNU screen

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, kirkl...@ubuntu.com

* Package name: screen-profiles
  Version : 1.36
  Upstream Author : Dustin Kirkland 
* URL or Web page : http://launchpad.net/screen-profiles
* License : GNU GPLv3
  Description : a set of useful profiles and a profile-switcher for GNU 
screen

 screen-profiles includes a set of profiles for the GNU screen window manager.
 These profiles are quite useful on server machines which are not running
 a graphical desktop.  The 'screen' command provides a number of advanced
 features are not necessarily exposed in the default profile.  These profiles
 provide features such as status bars, clocks, notifiers (reboot-required,
 updates-available), etc.  The profile-switcher allows users to quickly switch
 their .screenrc to any of the available profiles.
 .
 update-notifier-common provides a more efficient and standard mechanism for
 calculating the number of updates available in the status panel.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Accelerated video cards and non-free firmware

[Marco d'Itri]

On Mar 10, James Collier  wrote:

> Currently there is a Free implementation of a driver for NVidia cards
This is not relevant, we are not discussing drivers.

> /***
Please try to keep your .signature to a sensible size.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: inetd's status in Debian

[Francesco P. Lovergine]

On Tue, Mar 10, 2009 at 08:44:06AM +0100, Marco d'Itri wrote:
> On Mar 10, Luk Claes  wrote:
> 
> > Btw, lots of packages are depending on update-inetd while it's
> > guaranteed to be available when depending on inet-superserver.
> Indeed, this is broken. IIRC some helpful soul started reporting "bugs"
> asking to depend on update-inetd too...
> 

That remembers me a point: maybe it makes sense having a debhelper
dh_ script to manage automagically the call to update-inetd when available
or eventually warn the user to install update-inetd and update 
inetd/xinetd configuration manually, when update-inetd is NOT available.
That would avoid to depend on update-inetd or inet-superserver at all
Having a snippet of code like that replicated for every package is pointless.
Also, update-inetd is a very partial solution for managing superserver
configurations, but that's another problem...

-- 
Francesco P. Lovergine


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: changes in pam: automatic configuration of PAM modules

[Michael Biebl]

Steve Langasek wrote:
> Dear developers,
> 
> I'm happy to announce that with the latest upload of pam to unstable, we at
> last have an interface that allows both automatic and interactive
> configuration of system authentication, using that staple of the Debian
> system, debconf.
> 

Very nice work!

[..]
> 
> As a result of the prototyping work done on this within Ubuntu, patches are
> already available for several module packages (libpam-krb5, libpam-ldap,
> libpam-smbpass, ecryptfs-utils, libpam-ck-connector) which I will work on
> submitting to the Debian maintainers over the next week or so.  If

I have updated the libpam-ck-connector with todays upload of 0.3.0-1 and
included the patch from Ubuntu. So you can cross me of this list ;-)

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: To the aqualung NMUer....

[Jon Dowland]

On Mon, Mar 09, 2009 at 02:26:08PM -0700, Don Armstrong wrote:
> Just to underline here, you need to send the diff for the NMU to the bug(s)
> that you are fixing in the NMU *before* uploading the NMU.

The developers reference is not clear on this point and should perhaps be
clarified. It lists the requirement to upload the NMU  patch in the same bullet
point as the "upload your package" action-item, but after the "upload your
package" sentence.




-- 
Jon Dowland


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: changes in pam: automatic configuration of PAM modules

[Michael Biebl]

Steve Langasek wrote:
> As a result of the prototyping work done on this within Ubuntu, patches are
> already available for several module packages (libpam-krb5, libpam-ldap,
> libpam-smbpass, ecryptfs-utils, libpam-ck-connector) which I will work on
> submitting to the Debian maintainers over the next week or so.  If

Could this also be used to automatically setup gnome-keyring?

Cheers,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: To the aqualung NMUer....

[Simon Huggins]

On Mon, Mar 09, 2009 at 10:10:13PM +0100, Adeodato Simó wrote:
>   1. Don't spam devel to contact just one person.

For reference, who-uploads from devscripts is useful for working out who
NMU'd something.

Simon

-- 
... "Be wewy wewy careful. There be dragons here." -- Linus Torvalds


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: To the aqualung NMUer....

[Adam Cécile (Le_Vert)]

Simon Huggins a écrit :

On Mon, Mar 09, 2009 at 10:10:13PM +0100, Adeodato Simó wrote:
  

  1. Don't spam devel to contact just one person.



For reference, who-uploads from devscripts is useful for working out who
NMU'd something.

Simon

  

I bet it won't work for a package in dak ;)

Adam.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: To the aqualung NMUer....

[Adeodato Simó]

* "Adam Cécile (Le_Vert)" [Tue, 10 Mar 2009 15:42:43 +0100]:

> I bet it won't work for a package in dak ;)

http://incoming.debian.org
http://packages.qa.debian.org/aqualung

And, FFS, the ACCEPTED mail you get has you *and* the uploader in the
To: line.

-- 
- Are you sure we're good?
- Always.
-- Rory and Lorelai


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: To the aqualung NMUer....

[Clint Adams]

On Mon, Mar 09, 2009 at 02:22:34PM -0700, Don Armstrong wrote:
> This would definetly be useful, as it would help someone from wasting
> time preparing the NMU in the first place, but it certainly doesn't
> excuse making NMUs without notifying the maintainer beforehand.

If the maintainer can't be bothered to respond to a bug report, the
maintainer doesn't deserve any kind of notification.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: To the aqualung NMUer....

[Adam Cécile (Le_Vert)]

Adeodato Simó a écrit :

* "Adam Cécile (Le_Vert)" [Tue, 10 Mar 2009 15:42:43 +0100]:

  

I bet it won't work for a package in dak ;)



http://incoming.debian.org
http://packages.qa.debian.org/aqualung
  

It didn't appear neither on incoming nor on pts.

And, FFS, the ACCEPTED mail you get has you *and* the uploader in the
To: line.
  
Well... I still can't explain why I missed that, but that's definitely 
the right information.
Beware of small resolution of netbooks' screens that may hide some parts 
of the mails you get...


Imho, it's better to submit a quick reply to the bug saying you intend 
to prepare a NMU.
Maintainer may start working on a package without replying to the bug 
first, advicing him about an incoming NMU may avoid having the work done 
twice. That's my opinion, but I agree, it's always better to "ack" the 
bug first.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: To the aqualung NMUer....

[Matthew Johnson]

On Tue Mar 10 14:45, Clint Adams wrote:
> On Mon, Mar 09, 2009 at 02:22:34PM -0700, Don Armstrong wrote:
> > This would definetly be useful, as it would help someone from wasting
> > time preparing the NMU in the first place, but it certainly doesn't
> > excuse making NMUs without notifying the maintainer beforehand.
> 
> If the maintainer can't be bothered to respond to a bug report, the
> maintainer doesn't deserve any kind of notification.
 
Wrong, on so many levels. Ignoring the fact that two wrongs don't make a
right...

We have individual maintainership and whether that is good or bad it
means the maintainer can assume by default that he's the only person
working on the package and making uploads. We have exceptions to this,
which is good, but they are _exceptions_ and therefore need
notification.

Yes, the maintainer should respond to the bug report and yes he* should
mark the bug as pending, but forgetting this step in no means justifies
an NMUer doing the same.

NMUs should _always_ be posted to the bug log _before_ upload and
ideally before any work is done. That should be an absolute requirement
and I will vote against any proposal which doesn't require this.

If you want to be nice, you should give the maintainer time to respond
before doing this and file patches etc (as suggested in the dev ref...),
but for things which are 0day NMUable that's obviously not
always practical.

Matt


* insert pronoun as required
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Bug#519118: ITP: libcommons-java-java -- common java library used to support other developments

[gregor herrmann]

Package: wnpp
Severity: wishlist
Owner: gregor herrmann 


* Package name: libcommons-java-java
  Version : 1.5.5
  Upstream Author : TiongHiang Lee
* URL : http://onemind-commons.sourceforge.net/commons-java/
* License : LPGL-2.1+
  Programming Lang: Java
  Description : common java library used to support other developments

 The commons-java contains java utilities and mini-frameworks that are created
 to support other developments. It contains the following packages:
 .
   * org.onemind.commons.java.criterion - for representing logical constraints
   * org.onemind.commons.java.datastructure - some datastructure classes
   * org.onemind.commons.java.event - event/event firer interface and a simple
 listener list implementation
   * org.onemind.commons.java.html.css - css attribute constants for css
 related programming, and a simple css generation framework
   * org.onemind.commons.java.io - FileUtils
   * org.onemind.commons.java.lang - Null, Enum, ConfigurationException and
 ReflectUtils
   * org.onemind.commons.java.servlet - ServletUtils
   * org.onemind.commons.java.sql - sql metadata representation, sql type
 mapper and utils
   * org.onemind.commons.java.util - more utilities classes
   * org.onemind.commons.java.xml - utilities for xml parsing


(This package is needed by JabRef 2.4, cf. #497897).

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'experimental'), 
(500, 'testing'), (500, 'stable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#519121: ITP: libcommons-invoke-java -- Java invocation framework library

[gregor herrmann]

Package: wnpp
Severity: wishlist
Owner: gregor herrmann 


* Package name: libcommons-invoke-java
  Version : 1.1.0 [0]
  Upstream Author : TiongHiang Lee
* URL : http://onemind-commons.sourceforge.net/commons-invoke/
* License : LGPL-2.1+
  Programming Lang: Java
  Description : Java invocation framework library

 The commons-invoke framework is a complimentary framework to the
 reflection. While reflection allow discovery/invocation of the java
 object through JVM kernel, the invocation framework allows
 programmatic help for method lookup and invocation.

(This package is needed by JabRef 2.4, cf. #497897)

[0] The source is actually taken from CVS:
cvs -d 
:pserver:anonym...@onemind-commons.cvs.sourceforge.net:/cvsroot/onemind-commons 
export commons-invoke

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'experimental'), 
(500, 'testing'), (500, 'stable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#519122: ITP: libjxp-java -- Java template engine/script processor

[gregor herrmann]

Package: wnpp
Severity: wishlist
Owner: gregor herrmann 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: libjxp-java
  Version : 1.6.1
  Upstream Author : TiongHiang Lee
* URL : http://jxp.sourceforge.net/
* License : LGPL-2.1+
  Programming Lang: Java
  Description : Java template engine/script processor

 Jxp (Java scripted page) is a script-processor that process JSP-like files.
 It contains a parser to parse the script file into an abstract syntax tree
 and a tree processor (JxpProcessor) that will process the syntax tree to
 execute the code using reflection API to produce output. The main uses of Jxp
 are:
 .
   * as a script language engine to increase flexibility in the user
 application
   * as a template engine to produce dynamic text output
 .
 Some of the main features of Jxp include:
 .
   * Java as script/template language. Why learn another one? ;)
   * Run JSP-like code outside of servlet container
   * support common java language 1.4 constructs (partial 1.5 syntax support
 on jdk 1.4)
   * support common JSP constructs including import directive, declaration, EL
 etc (taglib not supported, yet)
   * practical template sources management framework
   * support caching of parsed syntax tree to eliminate reparse of template
   * a servlet implementation to enable web-scripting
   * extensible processing context for defining built-in function on the
 scripts

(This package is needed by JabRef 2.4, cf. #497897)

- -- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'experimental'), 
(500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

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

iEYEARECAAYFAkm2ih0ACgkQOzKYnQDzz+RbqgCaA3/fX/fI9iWm7xxdjBtyoEqN
nd8AoM8k/E0BLOB6PQPymmrcG9JzsyXJ
=k+BX
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#519124: ITP: libjpf-java -- Java Plugin Framework: plug-in infrastructure library for Java projects

[gregor herrmann]

Package: wnpp
Severity: wishlist
Owner: gregor herrmann 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: libjpf-java
  Version : 1.5.1
  Upstream Author : Dmitry Olshansky
* URL : http://jpf.sourceforge.net/
* License : LGPL-2.1+
  Programming Lang: Java
  Description : Java Plugin Framework: plug-in infrastructure library for 
Java projects

 JPF provides a runtime engine that dynamically discovers and loads
 "plug-ins". A plug-in is a structured component that describes itself to JPF
 using a "manifest". JPF maintains a registry of available plug-ins and the
 functions they provide (via extension points and extensions).
 .
 One major goal of JPF is that the application (and its end-user) should not
 pay any memory or performance penalty for plug-ins that are installed, but
 not used. Plug-ins are added to the registry at application start-up or
 while the application is running but they are not loaded until they are
 called.

(This package is needed by JabRef 2.4, cf. #497897)

- -- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'experimental'), 
(500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

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

iEYEARECAAYFAkm2izUACgkQOzKYnQDzz+TrWACfTJZ9wBHbk5m3WrMbkPeFGSOO
0qcAniXMUXi8kFyXAnb9iWSwxMYKfqN7
=JL+r
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#519125: ITP: libjpfcodegen-java -- tool for generating classes from JPF plug-ins

[gregor herrmann]

Package: wnpp
Severity: wishlist
Owner: gregor herrmann 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: libjpfcodegen-java
  Version : 0.4
  Upstream Author : Christopher Oezbek
* URL : http://page.mi.fu-berlin.de/oezbek/jpf/ [0]
* License : LGPL-3
  Programming Lang: Java
  Description : tool for generating classes from JPF plug-ins

 JPF Code Generator is a handy little tool that generates classes for
 accessing the attributes and extensions of JPF plug-ins from plugin.xml   
 files. This has the advantage of providing a strongly typed access to the  
 plug-in and simplyfies working with plug-ins.

[0] The code is supposed to be at
http://forge.spline.inf.fu-berlin.de/projects/jpfcodegen/ which gives
a 404 at the moment; but it's also in SVN under
https://jabref.svn.sourceforge.net/svnroot/jabref/tags/jpfcodegen-0.4

(This package is needed by JabRef 2.4, cf. #497897)

- -- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'experimental'), 
(500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

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

iEYEARECAAYFAkm2jE8ACgkQOzKYnQDzz+QrSQCfaUHOgy6fhrGWTZD1LP5rQdca
jwUAoILwHfOoL6Tej/GPAwQWtLfT/Lpv
=Iw/b
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

MPI binaries location

[Jean Parpaillon]

Hi,
I'm currently packaging hpcc (HPC Challenge Benchmark). Several binary 
packages will be available, each one with different mpi implementations. Is 
there a preferred place to put mpi binaries ? I've seen that each mpi 
implementation has it's own bin/lib/share/include/etc hierarchy into 
/usr/lib/

Should I put the binaries into it ?


Regards,
-- 
Jean Parpaillon - Kerlabs
Engineer
Bâtiment Germanium
80 avenue des buttes de Coësmes
35700 Rennes - France
Tel.: +33 6 80 332 73 85
http://www.kerlabs.com/


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

Re: changes in pam: automatic configuration of PAM modules

[Steve Langasek]

On Tue, Mar 10, 2009 at 01:42:11PM +0100, Michael Biebl wrote:
> Steve Langasek wrote:
> > As a result of the prototyping work done on this within Ubuntu, patches are
> > already available for several module packages (libpam-krb5, libpam-ldap,
> > libpam-smbpass, ecryptfs-utils, libpam-ck-connector) which I will work on
> > submitting to the Debian maintainers over the next week or so.  If

> Could this also be used to automatically setup gnome-keyring?

Probably not, because gnome-keyring's PAM module isn't generally applicable
and shouldn't be used for all services.  You probably only want this module
used by gdm, gnome-screensaver, and maybe a handful of others - you don't
want the module triggering on every POP connection, web authentication, etc.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: changes in pam: automatic configuration of PAM modules

[Michal Čihař]

Dne Tue, 10 Mar 2009 09:50:52 -0700
Steve Langasek  napsal(a):

> On Tue, Mar 10, 2009 at 01:42:11PM +0100, Michael Biebl wrote:
> > Steve Langasek wrote:
> > > As a result of the prototyping work done on this within Ubuntu, patches 
> > > are
> > > already available for several module packages (libpam-krb5, libpam-ldap,
> > > libpam-smbpass, ecryptfs-utils, libpam-ck-connector) which I will work on
> > > submitting to the Debian maintainers over the next week or so.  If
> 
> > Could this also be used to automatically setup gnome-keyring?
> 
> Probably not, because gnome-keyring's PAM module isn't generally applicable
> and shouldn't be used for all services.  You probably only want this module
> used by gdm, gnome-screensaver, and maybe a handful of others - you don't
> want the module triggering on every POP connection, web authentication, etc.

On the other side Gnome keyring is usually used on desktop and most
people do not run much servers which authenticate against PAM there.
I've always used gnome-keyring from common PAM configuration and never
had problems with that.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Bug#519143: ITP: ros -- a flexible robot operating system

[Uwe Hermann]

Package: wnpp
Severity: wishlist
Owner: Uwe Hermann 

* Package name: ros
  Version : 0.4
  Upstream Author : Willow Garage developers (http://www.willowgarage.com)
* URL : http://pr.willowgarage.com/wiki/ROS
* License : BSD
  Programming Lang: C, C++, Python
  Description : a flexible robot operating system

ROS is a robot operating system. It provides the services you
would expect from an operating system, including hardware abstraction,
low-level device control, implementation of commonly-used functionality,
message-passing between processes, and package management.



ROS is the base robot OS, there are many external modules/plugins which
will be packaged separately.

Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#519118: ITP: libcommons-java-java -- common java library used to support other developments

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

gregor herrmann wrote:
> * Package name: libcommons-java-java
>   Version : 1.5.5
>   Upstream Author : TiongHiang Lee
> * URL : http://onemind-commons.sourceforge.net/commons-java/

The libcommons-foo-java package names usually refer to Apache Commons. I 
think it could be confusing to use the same naming convention for other 
packages unrelated to Apache. How about "onemind-commons-foo" for the source 
package and "libonemind-commons-foo-java" for the binary?

Cheers,

Marcus

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

iEYEARECAAYFAkm2otkACgkQXjXn6TzcAQlb9wCdHrpiykiGhKXzhW40qDPNmpg5
+XMAn24I3QYIdtBTsgynMCRsTAildMvU
=zmhE
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: changes in pam: automatic configuration of PAM modules

[Josselin Mouette]

Le mardi 10 mars 2009 à 09:50 -0700, Steve Langasek a écrit :
> Probably not, because gnome-keyring's PAM module isn't generally applicable
> and shouldn't be used for all services.  You probably only want this module
> used by gdm, gnome-screensaver, and maybe a handful of others - you don't
> want the module triggering on every POP connection, web authentication, etc.

And since it’s an optional module, it works fine this by only setting it
up for gdm and gnome-screensaver.

However, the password stanza is applicable to all password services, so
that’s where the new configuration system will be needed.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: To the aqualung NMUer....

[Don Armstrong]

On Tue, 10 Mar 2009, Jon Dowland wrote:
> On Mon, Mar 09, 2009 at 02:26:08PM -0700, Don Armstrong wrote:
> > Just to underline here, you need to send the diff for the NMU to the bug(s)
> > that you are fixing in the NMU *before* uploading the NMU.
> 
> The developers reference is not clear on this point and should
> perhaps be clarified. It lists the requirement to upload the NMU
> patch in the same bullet point as the "upload your package"
> action-item, but after the "upload your package" sentence.

Yes, but this happens after the two notifications to the maintainer.
In the case of 0 day NMUs or uploads to delayed, these can be
collapsed into a single mail with the diff for the NMU attached.

That said, I'll try to remember to prepare and suggest a patch to
clarify this.


Don Armstrong

-- 
Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly).
 -- Matt Welsh

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#518752: update-exim4.conf: line 38: $@: unbound variable

[Andreas Metzler]

clone 518752 -1
reassign -1 bash
found -1 4.0-1
retitle -1 set -u should not error on "${@:+}" if there are no args
thanks

On 2009-03-08 Alban browaeys  wrote:
> >From \amethyst on freenode #bash  (Neil Moore) :
> <\amethyst> it is a bug I think
> <\amethyst> that you still get the error even with $...@-foo}
> <\amethyst> but $...@+"$@"}  probably shouldn't error out
> <\amethyst> since ${foo+bar}  does not
> <\amethyst> or ${foo+"$foo"}

> I believe this should be cloned to bash (kept here too because the
> current $@ is to be fixed either way).
> Please tell me if you want me to do it. I ll refresh my memories of the
> bts and proceed.

Thanks for the heads-up. Cloning.
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#519118: ITP: libcommons-java-java -- common java library used to support other developments

[gregor herrmann]

On Tue, 10 Mar 2009 18:26:49 +0100, Marcus Better wrote:

> > * Package name: libcommons-java-java
> >   Version : 1.5.5
> >   Upstream Author : TiongHiang Lee
> > * URL : http://onemind-commons.sourceforge.net/commons-java/
> 
> The libcommons-foo-java package names usually refer to Apache Commons. I 
> think it could be confusing to use the same naming convention for other 
> packages unrelated to Apache. How about "onemind-commons-foo" for the source 
> package and "libonemind-commons-foo-java" for the binary?

Good point, thanks a lot!

Cheers,
gregor 
-- 
 .''`.   Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: U2: Wild Honey


signature.asc
Description: Digital signature

Bug#519175: RFH: proftpd-dfsg

[Francesco P. Lovergine]

Package: wnpp
Severity: normal

With the release of 1.3.2 of proftpd is finally in place prxs and the whole 
infrastructure
for building third-parties modules. I know currently at least about 30 
different modules
available as non-core and some of them are sometimes requested by users. 
See http://castaglia.org/proftpd/#Modules for the list of them.

My idea is having new separate packages for add-on modules ready for squeeze 
and maintained by a little team of weakly connected people, in order to stay in 
sync with
patches, modules and core. Note that proftpd requires generally a good
deal of contributed patches to be in shape for the release. A decent
knowledge of its various configuration options and inners is mandatory.

In order to have an idea of the level of dedication required, prospective
helpers can consult the past 12 years of changelog.Debian, then contact
me.

Cheers

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#519184: ITP: gribapi -- GRIB decoding/encoding software library

[Enrico Zini]

Package: wnpp
Severity: wishlist
Owner: Enrico Zini 

* Package name: gribapi
  Version : 1.7.0
  Upstream Author : Enrico Fucile 
* URL : http://www.ecmwf.int/products/data/software/grib_api.html
* License : LGPLv3
  Programming Lang: C
  Description : GRIB decoding/encoding software library

 The ECMWF GRIB API is an application program interface accessible from
 C and FORTRAN programs developed for encoding and decoding WMO FM-92
 GRIB edition 1 and edition 2 messages.
 .
 ECMWF is the European Centre for Medium-Range Weather Forecasts.

I have already done most of the packaging at:
http://git.debian.org/?p=collab-maint/gribapi.git;a=summary

I have one thing of which I am unsure: upstream does not yet build
shared libraries, but the interface is rather stable and I patch the
sources so that the Debian package does provide them.  The issue is
about the libtool versioning: at the moment I picked 0:0:0 so that
anything upstream may choose in the future will likely be higher;
however, are there better ways to address this?

Other issues left to solve are nothing more than maybe writing a manpage
or two with help2man.


Ciao,

Enrico

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: MPI binaries location

[Geoff Jacobs]

Jean Parpaillon wrote:
> Hi,
> I'm currently packaging hpcc (HPC Challenge Benchmark). Several binary 
> packages will be available, each one with different mpi implementations. Is 
> there a preferred place to put mpi binaries ? I've seen that each mpi 
> implementation has it's own bin/lib/share/include/etc hierarchy into 
> /usr/lib/
> 
> Should I put the binaries into it ?
> 
> 
> Regards,

Generally, a standalone issue of (for example) MPICH will put elements
in /usr/include, /usr/lib, /usr/bin, etc. On one-off servers where I
want multiple libraries available, everything is prefixed into a custom
directory under /usr/local (/usr/local/mpich-1.2.7, for example). At
first I used a homebrew script to switch between each, but this is now
possible using a more polished program. See http://modules.sf.net for
more. Note that this approach is important for cases where different
compilers are used. This is not a stipulated requirement in your note.

The prebuilt deb packages for OpenMPI, LAM, and MPICH are patched to
label the build scripts differently (mpicc becomes mpicc.lam) and
install the libraries and headers in subdirectories as well. Further
management is performed using the alternatives process. Perhaps such a
method would work for what you intend.

-- 
Geoffrey D. Jacobs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [luabind] Naming library with proper SONAME

[Roberto C . Sánchez]

[My apologies in advance for the cross-posting.]

On Tue, Mar 10, 2009 at 10:42:36AM +0100, Daniel Wallin wrote:
> Roberto C. Sánchez wrote:
> >>
> > So, I've been trying to build the Debian package with the latest from
> > the 0.8 branch on github.  It seems like the SONAME thing is not
> > completely resolved.  I am seeing this after building:
> > 
> > robe...@miami:~/src/luabind-upstream$ objdump -p 
> > ./bin/gcc-4.3.2/debug/libluabindd.so.0.8.0 |grep SONAME
> >   SONAME  libluabindd.so.0.8.0
> 
> Yes, that's the expected result, isn't it? The reasoning was that it's
> too difficult to have ABI-compatibility, so we just use the complete
> version number as the SONAME. "bjam install" will create the unversioned
> symlink.
> 

I am curious as to what people generally think of how the libluabind
SONAME will be going forward.  I know that certain packages (like
libssl) have the complete version in the SONAME, but I can't imagine
that this is a really good idea.  Is this a showstopper for having
libluabind in Debian, or just for a stable release?  Is this
discouraged, but otherwise permissible?

I've looked in the Debian library packaging guide and it does not say
one way or the other.

I'd appreciate any insights and/or comments.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: inetd's status in Debian

[Pierre Habouzit]

On Tue, Mar 10, 2009 at 06:39:23AM +, Steve Langasek wrote:
> On Tue, Mar 10, 2009 at 07:31:35AM +0100, Luk Claes wrote:
> > Steve Langasek wrote:
> > > On Mon, Mar 09, 2009 at 08:06:16PM +0100, Pierre Habouzit wrote:
> 
> > >> I'm wondering if making super servers become optionnal wouldn't be a 
> > >> worthy
> > >> goal for squeeze.
> 
> > > Why?  If it ain't broke, don't fix it.  Having a superserver installed 
> > > isn't
> > > broken.  Why should every daemon have to implement connection handling 
> > > when
> > > they can offload that to the inetd?
> 
> > > Demoting inetd from standard to optional seems to me like a reasonable
> > > release goal; that doesn't require patching lots of upstream code that 
> > > works
> > > just fine the way it is already.  In fact, AFAICS it doesn't require
> > > patching any of our packages.
> 
> > Right, isn't that the proposal: demote inetd and update-inetd to
> > optional/extra?
> 
> Perhaps I misunderstood, but I read this as a proposal to make /use/ of
> inetd optional for the packages that currently depend on it.

That's probably because of my broken english because what luk and you
said was what I proposed: demote inetd to extra/optionnal instead of
standard. It could make space on the CDs to more useful stuff e.g.
-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org


pgpC6sOyHTM36.pgp
Description: PGP signature

Re: Accelerated video cards and non-free firmware

[Ben Hutchings]

On Tue, 2009-03-10 at 08:46 +0100, Marco d'Itri wrote:
> On Mar 10, Ben Hutchings  wrote:
> 
> > The firmware used for 3D acceleration in the r128 (ATI Rage 128), radeon
> > (ATI Radeon) and mga (Matrox G200/G400/G550) drivers is non-free and
> > will be moved from the linux-image packages into a new firmware-linux
> > package starting with Linux 2.6.29.
> Do you know about any 3D card having a free firmware? Because I know
> none.
> The difference is that these cards do not waste on-board flash for it
> and have it uploaded by the host.
[...]

Yes, that's what I meant.

Ben.



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

Bug#519205: ITP: swap-cwm -- RDF/XML and RDF/N3 semantic web data processor

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: swap-cwm
  Version : 1.2.1
  Upstream Author : Tim Berners-Lee 
* URL : http://www.w3.org/2000/10/swap
* License : W3C-Software 20021231
  Programming Lang: Python
  Description : RDF/XML and RDF/N3 semantic web data processor

Cwm (pronounced coom) is a general-purpose data processor for the 
semantic web, somewhat like sed, awk, etc. for text files or XSLT for 
XML. It is a forward chaining reasoner which can be used for querying, 
checking, transforming and filtering information. Its core language is 
RDF, extended to include rules, and it uses RDF/XML or RDF/N3 
(Notation3) serializations as required. 


Due to a name clash with calmwm, the binary "cwm" will be renamed
"swap-cwm". SWAP is the underlying Python library, also provided by this
source package.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: inetd's status in Debian

[Roger Leigh]

On Mon, Mar 09, 2009 at 08:06:16PM +0100, Pierre Habouzit wrote:
> Most machines nowadays have enough memory, and most daemons provide a
> standalone mode (I mean who configures apache as an inetd service ?).

> Just looking at the packages requiring an inet superserver, you'll see that
> it's probably that nowadays users don't need a superserver at all[0].
> 
> I'm wondering if making super servers become optionnal wouldn't be a worthy
> goal for squeeze.

I agree with this goal.  One major lack in our current inetd support is
for services which should run on IPv6 (tcp6 and udp6).  While the
current default inetd (openbsd-inetd) can support IPv6, in practice
no maintainer scripts are actually adding tcp6/udp6 lines to inetd.conf
in addition to tcp/udp lines.  Additionally, not all inetds support
IPv6, so adding these lines will break some inetds.

While packages requiring inetd support will of course need to keep
inetd around, it would be nice if packages offering both inetd and
standalone operation could drop inetd support in favour of standalone
operation only (since starting up the server every time for e.g.
apache and even services like proftpd is less efficient than just
having the dæmon sleep when not in use).


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.


signature.asc
Description: Digital signature

Re: Support of new source packages in squeeze

[Raphael Geissert]

James Westby wrote:
[...]
> 
> I was just wondering if you had considered what a solution might look
> like. It seems like adding a new watch file format that has multiple
> lines would work quite nicely for uscan.
> 

That's already possible, the problem is that it doesn't consider multiple
sources, i.e., it just takes (probably the latest, if multiple) the URI
which provides the greater version and reports that one, and downloads the
final URI if it is requested to do so.

E.g.

version=3
http://sf.net/foo/bar-(.+)\.tar\.gz
http://foo.tld/downloads.html files/bar-(.+)\.tar\.gz

Cheers,
Raphael Geissert



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: inetd's status in Debian

[Lars Wirzenius]

ke, 2009-03-11 kello 00:00 +, Roger Leigh kirjoitti:
> Additionally, not all inetds support
> IPv6, so adding these lines will break some inetds.

Should we consider lack of IPv6 support as a bug?

Ah yes, it's been a release goal since etch.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org