Re: RFS: pingus (updated package)

2007-09-24 Thread Bas Wijnen
Hi,

I'm taking a look at this.  An extra note/feature request for the
mentors template: please write what has changed with respect to the
previous version.

Thanks,
Bas

On Mon, Sep 24, 2007 at 12:39:33AM +0100, Marco Rodrigues wrote:
 Dear mentors,
 
 I am looking for a sponsor for the new version 0.7.1-1
 of my package pingus.
 
 It builds these binary packages:
 pingus - Free Lemmings(TM) clone
 pingus-data - Data files for pingus, a free Lemmings(TM) clone
 
 The package appears to be lintian clean.
 
 The package can be found on mentors.debian.net:
 - URL: http://mentors.debian.net/debian/pool/main/p/pingus
 - Source repository: deb-src http://mentors.debian.net/debian unstable main
 contrib non-free
 - dget http://mentors.debian.net/debian/pool/main/p/pingus/pingus_0.7.1-1.dsc
 
 I would be glad if someone uploaded this package for me.
 
 -- 
 Marco Rodrigues
 
 http://Marco.Tondela.org
 
 
 -- 
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
 

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature


RFS: daloRADIUS - Advanced RADIUS Web Management Application

2007-09-24 Thread liran tal
Dear mentors,

I am looking for a sponsor for my package daloradius.

* Package name: daloradius
  Version : 0.9.3
  Upstream Author : Liran Tal [EMAIL PROTECTED]
* URL : http://sourceforge.net/projects/daloradius
* License : GPL
  Section : admin

It builds these binary packages:
daloradius - An advanced RADIUS web management

The package appears to be lintian clean.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/d/daloradius
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/d/daloradius/daloradius_0.9.3.dsc

I would be glad if someone uploaded this package for me.


Kind regards
Liran Tal


Re: RFS: pingus (updated package)

2007-09-24 Thread Bas Wijnen
Hi,

Here's a list of things I found in the package:

- The second '*' in debian/changelog is indented incorrectly.

- About XS-DM-Upload-Allowed: I almost don't dare to say it, but I'd
  like to have it added again. ;-)  Perhaps it's better to wait until
  Miriam is back from her break, and leave it as it is for now. :-)

- in debian/rules, there is (in the clean target) -scons -c.  This
  looks like -$(MAKE) clean, for which there is a lintian warning.
  What can go wrong with cleaning?  It is unlikely you want to ignore
  all possible errors.  Some construct similar to
  test ! -e Makefile || $(MAKE) clean might be appropriate here as
  well (testing for the specific thing you want to ignore, and normally
  abort on any other error).

- in debian/rules, in the binary-arch target there is a commented-out
  line with dh_makeshlibs.  This is fine if you expect the package to
  make shared libraries in the (near) future, but I don't think that is
  the case?  If it will not be used, it's just confusing and should be
  removed.

- You are breaking the Build-Depends line (which is fine), but it still
  doesn't fit on an 80 column display.

- The homepage is probably better mentioned such that it can be found by
  parsers.  The old way is to have   Homepage: http://...; in the
  long description(s).  The new way (which isn't supported by
  everything yet) is to use Homepage: http://...; in the first
  paragraph of debian/control.  For now, it is probably best to do both.
  Note that the new way triggers a lintian warning about an unknown
  field, but you can ignore that (and IMO you don't need an override;
  this is something that should be fixed in lintian, overrides are for
  unusual situations that give false positives, but are so rare that
  lintian doesn't need to be changed to avoid them).

- There is a lintian override installed, which isn't documented in the
  changelog.  Why is it needed?  (In other words, what rare situation do
  you have here, which warrants an override instead of a lintian bug?)

- During build, it reports: * XInput support: disabled.  Is that
  intentional?  Do we miss input devices such as game pads because of
  this?

- Upstream switched on the official build flag.  You don't switch it
  off.  I expect that to be correct, but want to be sure you know.

A pretty long list, but none of them are big problems. :-)

Thanks,
Bas

On Mon, Sep 24, 2007 at 12:39:33AM +0100, Marco Rodrigues wrote:
 Dear mentors,
 
 I am looking for a sponsor for the new version 0.7.1-1
 of my package pingus.
 
 It builds these binary packages:
 pingus - Free Lemmings(TM) clone
 pingus-data - Data files for pingus, a free Lemmings(TM) clone
 
 The package appears to be lintian clean.
 
 The package can be found on mentors.debian.net:
 - URL: http://mentors.debian.net/debian/pool/main/p/pingus
 - Source repository: deb-src http://mentors.debian.net/debian unstable main
 contrib non-free
 - dget http://mentors.debian.net/debian/pool/main/p/pingus/pingus_0.7.1-1.dsc
 
 I would be glad if someone uploaded this package for me.
 
 -- 
 Marco Rodrigues
 
 http://Marco.Tondela.org
 
 
 -- 
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
 

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature


Re: RFS: php-apc -- APC module for php

2007-09-24 Thread Joerg Jaspert
On 11150 March 1977, Gregory Colpart wrote:

  * there is a problem with PHP licence version 3.0
 http://lists.debian.org/debian-legal/2005/08/msg00190.html should give
 you more details.
 You probably want to contact the authors.

 Yes, AFAIK the best solution is that you contact authors and ask
 to upgrade to version 3.0.1, or better: convince them to switch
 to standard license like BSD or (L)GPL.

PHP license 3.0.1 is no way out, *unless* the php package is from the php group
itself. Relicensing to a sane license, like LGPL or BSD is, which are
roughly the same (in spirit, not words).

-- 
bye Joerg
andreasj Also diese neuen Spam-Mails muten an wie Blog-Posts von Clint Adams
andreasj irgendwie ist es eine Geschichte, aber ich versteh sie nicht


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: How to start porting to a new ARCHITECTURE?

2007-09-24 Thread Shachar Shemesh
David Given wrote:
 You've got two major tasks ahead of you:

 - - port gcc

 - - port the kernel

 - - cross-compile a basic userland
   
Nobody expects the Spanish inquisition.

Actually, there is one more major headache, which is porting a boot
loader. Probably uBoot or something similar. Memory needs to be set up
so it can be accessed by the kernel, the kernel (and initrd) pulled from
the flash, and flow passed into it.

If the system uses hardware controllers that exist elsewhere, the kernel
port may be easier than that. It may be that the system has an ethernet
controller that is already supported under Linux. Of course, the startup
code and everything else under the arch directory will still need to
be handled, but at least as far as the drivers are concerned, some work
may be saved.

Shachar


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: RFS: daloRADIUS - Advanced RADIUS Web Management Application

2007-09-24 Thread Christoph Haas
On Mon, Sep 24, 2007 at 09:56:57AM +0200, liran tal wrote:
 I am looking for a sponsor for my package daloradius.
 
 * Package name: daloradius
   Version : 0.9.3
   Upstream Author : Liran Tal  [EMAIL PROTECTED]
 * URL : http://sourceforge.net/projects/daloradius

This URL is not mentioned in debian/copyright and/or debian/control.

 * License : GPL

The debian/copyright needs more love. Add the dates of copyright.
Compare the file to the copyright file of other packages.

   Section : admin
 
 It builds these binary packages:
 daloradius - An advanced RADIUS web management
 
 The package appears to be lintian clean.
 
 The package can be found on mentors.debian.net:
 - URL: http://mentors.debian.net/debian/pool/main/d/daloradius
 - Source repository: deb-src http://mentors.debian.net/debian unstable main
 contrib non-free
 - dget http://mentors.debian.net/debian/pool/main/d/daloradius/
 daloradius_0.9.3.dsc

The package just contains the usr directory from the upstream tarball.

You also built your package as a native package (no orig.tar.gz +
diff.gz).

Please give the package some more love. Creating Debian packages is
unfortunately non-trivial. Since you are also the upstream I suggest you
ask a fellow Debian developer to create the package for you. Or file a
WNPP bug to find someone to create a package (`reportbug wnpp`).

 Christoph


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



RFS: grun -- GTK based Run dialog [delayed-7 NMU]

2007-09-24 Thread Luis Rodrigo Gallardo Cruz
Dear mentors,

I am looking for a sponsor for a 7 days delayed NMU of package grun.

The upload would fix these bugs: 438704

This is a long standing (but recently reported, sadly) bug that has
just become grave, because with gtk 2.12 it now results on inmediate
segfaults when using grun. The package's maintainer has not
responded to the bug report at all since the original report a month
ago, nor since the severity upgrade, last friday.

The package is not lintian clean, because I have not changed anything
beyond what's neeeded to patch this bug.

The interdiff between 0.9.2-14 and 0.9.2-14.1 is a little larger than
the minimal patch, because the package's build system updates
config.{sub,guess} automatically on creating the source package.
The true patch can be found in the bug log, or by removing those two
files from the interdiff.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/g/grun
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/g/grun/grun_0.9.2-14.1.dsc

It builds these binary packages:
grun   - GTK based Run dialog

I would be glad if someone uploaded this package to the delayed-7
queue for me.

Thank you,
-- 
Rodrigo Gallardo
GPG-Fingerprint: 7C81 E60C 442E 8FBC D975  2F49 0199 8318 ADC9 BC28


signature.asc
Description: Digital signature


Re: speed of COW directory copying: XFS 20x slower than ext3

2007-09-24 Thread Junichi Uekawa
Hi,

 We just discovered, that mounting XFS partition with:
 
 sudo mount -o nobarrier /dev/sda2 /mnt/p1
 
 speeds things up on all machines. The reason is, that the option -o
 barrier was added by default to all kernels = 2.6.17, so dakol has
 nobarrier, all the others have barrier. By mounting with nobarrier,
 the cp and rm times are 5s on the first run and around 1.7s on
 subsequent runs. That's much better for XFS.


This is very interesting.

I have so far only tested cowdancer with ext3. Profiling and
optimizing code is done only for ext3.

I'm not quite sure how widespread other filesystems are, but it would
be interesting to see how they can be optimized better wrt cowdancer
usage.


regards,
junichi
-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Removing transition stuff in debhelper scripts after which time?

2007-09-24 Thread Daniel Leidert
Hi,

Today I stumbled over the question: After which time should transition
stuff be removed from the debhelper scripts. In this special case I'm
talking about install-sgmlcatalog calls in (e.g.) postinst scripts. Adam
Di Carlo announced the depreciation of install-sgmlcatalogs in 2001.
However, almost all related docbook* packages still contain this stuff.
So I'm wondering, how long one should wait before such obsolete stuff
can be removed? I mean, there is no requirement to support updates from
e.g. Woody to Lenny, right? I checked the Debian Social Contract and the
Policy manuals, but didn't find an information related to this topic.
Maybe I overlooked it?

Regards, Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Removing transition stuff in debhelper scripts after which time?

2007-09-24 Thread Matthew Palmer
On Tue, Sep 25, 2007 at 04:46:43AM +0200, Daniel Leidert wrote:
 Today I stumbled over the question: After which time should transition
 stuff be removed from the debhelper scripts. In this special case I'm
 talking about install-sgmlcatalog calls in (e.g.) postinst scripts. Adam
 Di Carlo announced the depreciation of install-sgmlcatalogs in 2001.
 However, almost all related docbook* packages still contain this stuff.
 So I'm wondering, how long one should wait before such obsolete stuff
 can be removed? I mean, there is no requirement to support updates from
 e.g. Woody to Lenny, right? I checked the Debian Social Contract and the
 Policy manuals, but didn't find an information related to this topic.
 Maybe I overlooked it?

I'm not sure where it's defined, but we don't support upgrades to anything
other than the next release.  So, unless it's needed to upgrade from an Etch
system, it doesn't need to be in new releases of the package uploaded to
unstable as of now.

Now, that being said, it's often helpful (for backporting, for instance) to
keep a bit more history in the scripts, but supporting woody is going a
little overboard -- upgrading from Sarge would be absolute limit for me.

- Matt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Removing transition stuff in debhelper scripts after which time?

2007-09-24 Thread Justin Pryzby
On Tue, Sep 25, 2007 at 04:46:43AM +0200, Daniel Leidert wrote:
 Hi,
 
 Today I stumbled over the question: After which time should transition
 stuff be removed from the debhelper scripts. In this special case I'm
 talking about install-sgmlcatalog calls in (e.g.) postinst scripts. Adam
 Di Carlo announced the depreciation of install-sgmlcatalogs in 2001.
 However, almost all related docbook* packages still contain this stuff.
 So I'm wondering, how long one should wait before such obsolete stuff
 can be removed? I mean, there is no requirement to support updates from
 e.g. Woody to Lenny, right? I checked the Debian Social Contract and the
 Policy manuals, but didn't find an information related to this topic.
 Maybe I overlooked it?
You can drop such things in uploads to unstable after they're included
in a stable release.  Upgrades across releases are not tested and are
officially not supported though AFAIK the reasons are largely
undocumented.  I think it's roughly the same situation as for
downgrades:

 . maintainer scripts may not support things; this is basically so
   maintainers are allowed to drop support for ancient things and not
   have unmanagably large and difficult to test, unmaintanble cruft;
 . Package control file; including in particular the dependency
   fields: Conflicts, Depends, Provides (?), Pre-Depend plus Replaces.
   Dependencies on versions earlier than [old]stable are often
   dropped.  It's only unfortunate that control files afaik still
   don't support comments to document why the versions and things were
   there with which to being.
 . The package itself; eg. it might contain logic to upgrade the
   format of its datafiles but not for every historic version and bugs
   therein.

Justin

References

[0] http://lists.debian.org/debian-mentors/2007/01/msg00241.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]