Bug#429441: ITP: lemonldap-ng -- lemonldap-ng is a Perl web single-sign-on system usable as Apache module

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard <[EMAIL PROTECTED]>


* Package name: lemonldap-ng
  Version : x.y.z
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : lemonldap-ng is a Perl web single-sign-on system usable as 
Apache module

(Include the long description here.)
Lemonldap::NG is a modular web-sso system based on Apache::Session::*
modules. It manages both authentication and authorization.
Authentication can be based on ldap, SSL or CAS. Authorizations are
evaluated using regular expressions associated with Perl boolean
expressions on LDAP attributes. The packages are available here:

  deb http://lemonldap.objectweb.org/NG/debian testing/
  deb-src http://lemonldap.objectweb.org/NG/debian testing/

The Home project is here:
http://wiki.lemonldap.objectweb.org/xwiki/bin/view/NG/Presentation

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable'), (600, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-4-xen-686 (SMP w/1 CPU core)
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash


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

Can we require build-arch/indep targets for lenny?

[Goswin von Brederlow]

Hi,

I would like to gather up some momentum for a policy change. Namely
that the build-arch/indep targets in debian/rules become required
instead of being optional.

The reason for this is that dpkg-buildpackage can't reliable detect
the existance of the build-arch/indep targets and must call 'build'
instead. This forces every source to compile both architecture
specific and architecture independent code on all buildds and
increases the Build-Depends of packages a lot.


Current status:

I asked Lucas Nussbaum to rebuild all of debian with dpkg-buildpackage
patched to call 'build-arch'. Here is the result:

7326 packages rebuilt (all packages not Architecture:all)
1727 built successfully
5463 failed to build with a "no rule to make" error.
136 failed for other reasons (unsat builddeps, etc)

That means that only about 25% of debian package have a build-arch
target. So there is still a long way to got.



Possible upgrade paths:

1) Change policy now making 75% of package RC buggy instantly.

   This sounds horrible but the fix is trivial and there is still a
   long time to lenny to fix it.

2) Enforce the target for all new uploads and change policy once we
   exceed XX%.

   The unstable/experimental buildds could be patched to call
   'build-arch' instead of build making any upload without
   'build-arch' FTBFS. The security buildds would be left
   as is so nothing old breaks.

3) Require 'build-arch/indep' with Standards-Version x.y.z

   Every source has a Standards-Version entry. dpkg-buildpackage could
   call 'build-arch' if the standards version is new enough and fall
   back to 'build' for older versions.

The options can be combined for maximum effect.


How to fix your own package:

The minimal change to debian/rules would be to replace 'build:' with
'build%:'. But that doesn't always work (e.g. not with cdbs).

The next smallest change is to add 'build-%: build' to
debian/rules. That always works.

If you actualy have different things to build for arch and indep then
you are missing the benefits though with the above solutions. If you
have such a case then the recommended way in policy is the right
solution. Create 'build-arch' and 'build-indep' targets with the
respective build rules and have 'build' depend on both.

If you don't then you can also create 'build-arch' and 'build-indep'
targets that depend on 'build' if you don't like the pattern matching
'build-%' above.

MfG
Goswin


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

Re: Dependencies on shared libs, take 2

[Raphael Hertzog]

Hi,

On Mon, 18 Jun 2007, Josselin Mouette wrote:
> Le dimanche 17 juin 2007 à 15:00 +0100, Raphael Hertzog a écrit :
> > - we have different levels of check that can make dpkg-gensymbols fail
> >   (with option -c). By default level 1 is activated, it will fail
> >   if some symbols disappeared. Level 2 will also fail if new symbols are
> >   introduced without prior update of the debian/symbols file. Level 3 and 4
> >   introduce additional checks about new/disappearing libraries in the
> >   package.
> 
> I still don't understand why you insist on making level 1 the default.
> The symbols file *must* be updated when new symbols or libraries are
> introduced, which means level at least 3 must be the default.

The generated file is updated... and the file in the source package
doesn't need to be updated so often. Additionnaly you can avoid having to
rebuild once knowing that it will fail... let the build update the
generated file, get the diff from the build log and commit it in your
repository so that it will be used for the next upload.

If your build is rather large, it can make sense. 

That said maybe the ordering of checks need to adapted so that for example
a library that disappear also result in a failed build by default. I have
no firm opinion on that. But I believe that the addition of a symbol or
the addition of new lib doesn't have to generate a failure directly. Of
course, the build log will still give a diff because there's a difference
between what's provided and what's generated. And that diff can be
extracted and applied later on.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Dependencies on shared libs, take 2

[Mike Hommey]

On Mon, Jun 18, 2007 at 09:50:48AM +0100, Raphael Hertzog <[EMAIL PROTECTED]> 
wrote:
> Hi,
> 
> On Mon, 18 Jun 2007, Josselin Mouette wrote:
> > Le dimanche 17 juin 2007 à 15:00 +0100, Raphael Hertzog a écrit :
> > > - we have different levels of check that can make dpkg-gensymbols fail
> > >   (with option -c). By default level 1 is activated, it will fail
> > >   if some symbols disappeared. Level 2 will also fail if new symbols are
> > >   introduced without prior update of the debian/symbols file. Level 3 and 
> > > 4
> > >   introduce additional checks about new/disappearing libraries in the
> > >   package.
> > 
> > I still don't understand why you insist on making level 1 the default.
> > The symbols file *must* be updated when new symbols or libraries are
> > introduced, which means level at least 3 must be the default.
> 
> The generated file is updated... and the file in the source package
> doesn't need to be updated so often. Additionnaly you can avoid having to
> rebuild once knowing that it will fail... let the build update the
> generated file, get the diff from the build log and commit it in your
> repository so that it will be used for the next upload.
> 
> If your build is rather large, it can make sense. 

No, it doesn't. Files in the debian/ directory should not be modified
during the build. The correct file should already be in the .diff.gz.

Mike


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

Re: Dependencies on shared libs, take 2

[Raphael Hertzog]

On Mon, 18 Jun 2007, Mike Hommey wrote:
> > The generated file is updated... and the file in the source package
> > doesn't need to be updated so often. Additionnaly you can avoid having to
> > rebuild once knowing that it will fail... let the build update the
> > generated file, get the diff from the build log and commit it in your
> > repository so that it will be used for the next upload.
> > 
> > If your build is rather large, it can make sense. 
> 
> No, it doesn't. Files in the debian/ directory should not be modified
> during the build. The correct file should already be in the .diff.gz.

The file in debian is *not* updated, that's precisely the point of this
discussion. Joss wants the maintainer to update it beforehand, I let the
maintainer update it after its final build but it will then be used only
for the next upload of course. (The file in debian is not auto-updated
during the build in any case)

The file in in the binary package (debian//DEBIAN/symbols) is
however generated at build time (and has thus updated symbol information).

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Dependencies on shared libs, take 2

[Goswin von Brederlow]

Raphael Hertzog <[EMAIL PROTECTED]> writes:

> On Mon, 18 Jun 2007, Mike Hommey wrote:
>> > The generated file is updated... and the file in the source package
>> > doesn't need to be updated so often. Additionnaly you can avoid having to
>> > rebuild once knowing that it will fail... let the build update the
>> > generated file, get the diff from the build log and commit it in your
>> > repository so that it will be used for the next upload.
>> > 
>> > If your build is rather large, it can make sense. 
>> 
>> No, it doesn't. Files in the debian/ directory should not be modified
>> during the build. The correct file should already be in the .diff.gz.
>
> The file in debian is *not* updated, that's precisely the point of this
> discussion. Joss wants the maintainer to update it beforehand, I let the
> maintainer update it after its final build but it will then be used only
> for the next upload of course. (The file in debian is not auto-updated
> during the build in any case)
>
> The file in in the binary package (debian//DEBIAN/symbols) is
> however generated at build time (and has thus updated symbol information).
>
> Cheers,

Wouldn't that result in packages build against an outdated symbols
file?

MfG
Goswin


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

Re: Dependencies on shared libs, take 2

[Mike Hommey]

On Mon, Jun 18, 2007 at 10:08:36AM +0100, Raphael Hertzog <[EMAIL PROTECTED]> 
wrote:
> On Mon, 18 Jun 2007, Mike Hommey wrote:
> > > The generated file is updated... and the file in the source package
> > > doesn't need to be updated so often. Additionnaly you can avoid having to
> > > rebuild once knowing that it will fail... let the build update the
> > > generated file, get the diff from the build log and commit it in your
> > > repository so that it will be used for the next upload.
> > > 
> > > If your build is rather large, it can make sense. 
> > 
> > No, it doesn't. Files in the debian/ directory should not be modified
> > during the build. The correct file should already be in the .diff.gz.
> 
> The file in debian is *not* updated, that's precisely the point of this
> discussion. Joss wants the maintainer to update it beforehand, I let the
> maintainer update it after its final build but it will then be used only
> for the next upload of course. (The file in debian is not auto-updated
> during the build in any case)
> 
> The file in in the binary package (debian//DEBIAN/symbols) is
> however generated at build time (and has thus updated symbol information).

It's even worse. You're acting as if you were modifying debian/symbols
without modifying it, saying it's fine because you didn't modify it...

Mike


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

Re: APT 0.7 for sid

[Reinhard Tartler]

Moritz Muehlenhoff <[EMAIL PROTECTED]> writes:

> Michael Vogt wrote:
>> unattended-upgrades comes with a default configuration that will only
>> apply security updates (but it can be configured in any way people
>> want) and it will do some careful checking to not upgrade packages
>> that require manual intervention bia conffile prompts. It will also
>> check that a security update does not bring in a new package from a
>> non-security source, not break the cache and offer logging/mail of
>> the changes to the administrator. It is designed to integrate nicely
>> with update-notifier and the apt cronjob.
>
> Unattended security upgrades are not supported; while we can typically fix
> security problems w/o requiring manual user interaction, we cannot
> guarantee it all cases. The user needs to read the DSA.

As already said elsewhere in this thread, that's exactly the point of
"unattended-upgrades": It detects if manual user interaction is
required, and will not upgrade the package in this case.

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


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

Re: Dependencies on shared libs, take 2

[Loïc Minier]

On Mon, Jun 18, 2007, Mike Hommey wrote:
> It's even worse. You're acting as if you were modifying debian/symbols
> without modifying it, saying it's fine because you didn't modify it...

 I think this is fine; the resulting "symbols" file can make strict
 assumptions.

 You don't expect dh_makeshlibs to make your build fail, even if you
 might forgot excluding some new plugin dir for example.  In the same
 way, dpkg-gensymbols will generate a symbols file based on your earlier
 instructions and will do something safe for symbols which are not
 covered by your instructions.

-- 
Loïc Minier


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

Re: APT 0.7 for sid

[Loïc Minier]

On Mon, Jun 18, 2007, Reinhard Tartler wrote:
> As already said elsewhere in this thread, that's exactly the point of
> "unattended-upgrades": It detects if manual user interaction is
> required, and will not upgrade the package in this case.

 There might be some manual steps involved.  For example, "Users of
 $some_config_option should manually check whether some wiki pages have
 the word hulabula in them".

 I personally wish unattended-upgrades would still be able to do the
 job in all other cases though: perhaps the security advisories could be
 tagged to indicate manual intervention is needed?

-- 
Loïc Minier


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

Re: Dependencies on shared libs, take 2

[Raphael Hertzog]

On Mon, 18 Jun 2007, Goswin von Brederlow wrote:
> > The file in debian is *not* updated, that's precisely the point of this
> > discussion. Joss wants the maintainer to update it beforehand, I let the
> > maintainer update it after its final build but it will then be used only
> > for the next upload of course. (The file in debian is not auto-updated
> > during the build in any case)
> >
> > The file in in the binary package (debian//DEBIAN/symbols) is
> > however generated at build time (and has thus updated symbol information).
> 
> Wouldn't that result in packages build against an outdated symbols
> file?

And what's the supposed problem with that?

The only problem that it can generate is that the maintainer forgets to
update the symbol file from time to time and thus symbols are marked
as appearing in a later version than the version where they were really
introduced.

Really not a big deal and certainly not the source of any major problem.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Dependencies on shared libs, take 2

[Raphael Hertzog]

On Mon, 18 Jun 2007, Mike Hommey wrote:
> It's even worse. You're acting as if you were modifying debian/symbols
> without modifying it, saying it's fine because you didn't modify it...

I have full control on the kind of changes that I allow in the
generated symbols file compared to the provided file. I don't see any
problem here.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Dependencies on shared libs, take 2

[Andreas Barth]

* Raphael Hertzog ([EMAIL PROTECTED]) [070618 11:36]:
> On Mon, 18 Jun 2007, Mike Hommey wrote:
> > > The generated file is updated... and the file in the source package
> > > doesn't need to be updated so often. Additionnaly you can avoid having to
> > > rebuild once knowing that it will fail... let the build update the
> > > generated file, get the diff from the build log and commit it in your
> > > repository so that it will be used for the next upload.
> > > 
> > > If your build is rather large, it can make sense. 
> > 
> > No, it doesn't. Files in the debian/ directory should not be modified
> > during the build. The correct file should already be in the .diff.gz.
> 
> The file in debian is *not* updated, that's precisely the point of this
> discussion. Joss wants the maintainer to update it beforehand, I let the
> maintainer update it after its final build but it will then be used only
> for the next upload of course. (The file in debian is not auto-updated
> during the build in any case)

But that is *wrong* in my opinion. Please make sure that the source
package contains all the information it needs, at least for libraries.

> The file in in the binary package (debian//DEBIAN/symbols) is
> however generated at build time (and has thus updated symbol information).

If it is not part of the source package, it is not guranteed to be
updated with the next build either.



Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Dependencies on shared libs, take 2

[Andreas Barth]

* Loïc Minier ([EMAIL PROTECTED]) [070618 12:04]:
> On Mon, Jun 18, 2007, Mike Hommey wrote:
> > It's even worse. You're acting as if you were modifying debian/symbols
> > without modifying it, saying it's fine because you didn't modify it...
> 
>  I think this is fine; the resulting "symbols" file can make strict
>  assumptions.
> 
>  You don't expect dh_makeshlibs to make your build fail, even if you
>  might forgot excluding some new plugin dir for example.  In the same
>  way, dpkg-gensymbols will generate a symbols file based on your earlier
>  instructions and will do something safe for symbols which are not
>  covered by your instructions.

I just fear we will loose most of the advantages if the developers are
not reminded the hard way to fix stuff. Of course, we can still live
with it - appropriate warnings in lintian and convincing maintainers of
core packages probably will fix that anyways.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Dependencies on shared libs, take 2

[Goswin von Brederlow]

Raphael Hertzog <[EMAIL PROTECTED]> writes:

> On Mon, 18 Jun 2007, Goswin von Brederlow wrote:
>> > The file in debian is *not* updated, that's precisely the point of this
>> > discussion. Joss wants the maintainer to update it beforehand, I let the
>> > maintainer update it after its final build but it will then be used only
>> > for the next upload of course. (The file in debian is not auto-updated
>> > during the build in any case)
>> >
>> > The file in in the binary package (debian//DEBIAN/symbols) is
>> > however generated at build time (and has thus updated symbol information).
>> 
>> Wouldn't that result in packages build against an outdated symbols
>> file?
>
> And what's the supposed problem with that?
>
> The only problem that it can generate is that the maintainer forgets to
> update the symbol file from time to time and thus symbols are marked
> as appearing in a later version than the version where they were really
> introduced.
>
> Really not a big deal and certainly not the source of any major problem.
>
> Cheers,

What if the source uses one of those symbols not yet in the symbols
file?

MfG
Goswin


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

Re: APT 0.7 for sid

[Matt Zimmerman]

On Sun, Jun 17, 2007 at 03:51:15PM -0400, Joe Smith wrote:
> "Michael Vogt" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
>> - automatic removal of unused dependencies moved into libapt so that
>>  applications like synaptic, python-apt, update-manger etc directly
>>  benefit from it. A HUGE thanks to Daniel Burrows (one of my personal
>>  heros) for his work on this feature.
>>
>
> Quick question: this feature is basically the moving of the dependency 
> tracking of aptitude to libapt?

Yes.  It is not quite the same implementation, but libapt now provides
similar functionality.

-- 
 - mdz


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

Re: Handling of (inactive) Debian Accounts

[Stefano Zacchiroli]

On Wed, May 23, 2007 at 11:09:53AM +0200, Stefano Zacchiroli wrote:
> Hi DAMs,
>   I'm wondering what actually happened with this, so flow of questions
> follows :)

Hi DAMs, ping again on this.

Can we have some numbers about at least how many mails have been sent in
the first WaT run, if any?  Also a simple "yes we did the WaT" or "no we
haven't yet" would be appreciated.


Many thanks in advance and again for the neat proposal.
Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Dependencies on shared libs, take 2

[Josselin Mouette]

Le lundi 18 juin 2007 à 10:08 +0100, Raphael Hertzog a écrit :
> The file in debian is *not* updated, that's precisely the point of this
> discussion. Joss wants the maintainer to update it beforehand, I let the
> maintainer update it after its final build but it will then be used only
> for the next upload of course.

And this is utterly *WRONG*. This doesn't work for co-maintained
packages. This doesn't work with NMUs. This doesn't work for people who
develop on several machines without always synchronising them. All the
information needed to build a package should be in the diff.gz, not on
the maintainer's disk.

The only sane way to do is to *never* alter the symbols file provided by
the maintainer, but to fail and suggest the maintainer how to update it.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Can we require build-arch/indep targets for lenny?

[Florent Rougon]

Hi,

Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

> I would like to gather up some momentum for a policy change. Namely
> that the build-arch/indep targets in debian/rules become required
> instead of being optional.

FWIW, I think that would be a good thing (I remember a discussion with
you on -mentors on Build-Depends v.s. Build-Depends-Indep whose outcome
was that the real problem was that build-arch and build-indep are
optional).

-- 
Florent


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

Re: Can we require build-arch/indep targets for lenny?

[Thomas Viehmann]

Goswin von Brederlow wrote:

I would like to gather up some momentum for a policy change. Namely
that the build-arch/indep targets in debian/rules become required
instead of being optional.

Wouldn't looking for the output
  make: *** No rule to make target `build-arch'.  Stop.
and then defaulting to make build be an option?


Possible upgrade paths:

4) Make build-arch/indep recommended and have lintian issue a warning.

Kind regards

T.
--
Thomas Viehmann, http://thomas.viehmann.net/


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

Adrian Bridgett, second try

[Peter Holm]

Hi,
Just received following:
[...]
Hi. This is the qmail-send program at mail.gmx.net.
I'm afraid I wasn't able to deliver your message to the following 
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<[EMAIL PROTECTED]>:
70.103.162.29_does_not_like_recipient./Remote_host_said:_550_user_account_locked/Giving_up_on_70.103.162.29./
[...]

a) How can I contact Adrian now?
b) Why do you state an invalid adress for the maintainer, even if the 
program is in the testing branch? 

 With kind regards,
 Peter Holm


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

Re: Can we require build-arch/indep targets for lenny?

[Daniel Schepler]

On Monday 18 June 2007 04:30:55 am Goswin von Brederlow wrote:
> Hi,
>
> I would like to gather up some momentum for a policy change. Namely
> that the build-arch/indep targets in debian/rules become required
> instead of being optional.
>
> The reason for this is that dpkg-buildpackage can't reliable detect
> the existance of the build-arch/indep targets and must call 'build'
> instead. This forces every source to compile both architecture
> specific and architecture independent code on all buildds and
> increases the Build-Depends of packages a lot.

How about instead requiring something like: the build-arch target must return 
successfully or with a status of 2 (the standard make error status 
for "target not found"), and in the latter case the build target must return 
successfully.  That is, if Build-Depends but not necessarily 
Build-Depends-Indep are installed, the shell snippet

  debian/rules build-arch || (test $? -eq 2 && debian/rules build)

must work and exit with a status of 0.

This would make it possible for dpkg-buildpackage -B to be reliable while 
allowing most (or even all?) of the current packages to stay as they are 
until maintainers can add the recommended build-arch target.
-- 
Daniel Schepler


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

Bug#429514: ITP: openoffice.org-ctl-he -- Turns on OO.org CTL support, and sets Hebrew as the default CTL locale

[Lior Kaplan]

Package: wnpp
Severity: wishlist
Owner: Lior Kaplan <[EMAIL PROTECTED]>

* Package name: openoffice.org-ctl-he
  Version : 1.0
  Upstream Author : Lior Kaplan <[EMAIL PROTECTED]>
* URL : 
svn://svn.debian.org/svn/debian-hebrew/pkg/openoffice.org-ctl-he
* License : Public Domain
  Programming Lang: none
  Description : Turns on CTL support & sets Hebrew as the default CTL locale

This package installs an OO.org extention which turns on CTL support, and sets
Hebrew as the default language.

The user can overright these setting by changning them in the tools -> options
-> language settings menu.

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

Kernel: Linux 2.6.21-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


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

Bug#429524: ITP: louie -- Python signal dispatching mechanism

[Loïc Minier]

Package: wnpp
Severity: wishlist
Owner: Loic Minier <[EMAIL PROTECTED]>

* Package name: louie
  Version : 1.1
  Upstream Author : Patrick K. O'Brien and contributors <[EMAIL PROTECTED]>
* URL : http://pylouie.org/
* License : BSD
  Programming Lang: Python
  Description : Python signal dispatching mechanism

 Louie provides Python programmers with a straightforward way to
 dispatch signals between objects in a wide variety of contexts. It is
 based on PyDispatcher, which in turn was based on a highly-rated recipe
 in the Python Cookbook.

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

Kernel: Linux 2.6.22-rc4-686 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
Loïc Minier

Re: Adrian Bridgett, second try

[Christoph Berg]

Re: Peter Holm 2007-06-18 <[EMAIL PROTECTED]>
> b) Why do you state an invalid adress for the maintainer, even if the 
> program is in the testing branch? 

That's what listed in the package.

As it looks, Adrian's packages should probably all be orphaned, the
address has been bouncing since at least January.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Bug#429547: ITP: dominoblast -- physics-based driving/demolition game

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz <[EMAIL PROTECTED]>


* Package name: dominoblast
  Version : 0.1
  Upstream Author : Chris Lord <[EMAIL PROTECTED]>
  Upstream Author : Heather Packer <[EMAIL PROTECTED]>
* URL : http://chrislord.net/blog/Software/my-lost-dog.essay
* License : GPL 
  Programming Lang: C
  Description : physics-based driving/demolition game

Domino Blast is a hybrid driving and destruction game with a children's
toys theme, in which you drive a toy car among buildings made of domino
tiles.

The game-play is simplistic, yet satisfying; similar to the satisfaction
gained from watching a tumbling Jenga tower, except the objective is to
tumble the tower, rather than slowly deconstruct it. As the game
progresses, levels become more dense and the buildings that inhabit them
become larger and more complex. The goal of the game is to wreak as much
havoc as possible, within a time limit.


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

Re: Can we require build-arch/indep targets for lenny?

[Wouter Verhelst]

On Mon, Jun 18, 2007 at 04:40:26PM +0200, Thomas Viehmann wrote:
> Goswin von Brederlow wrote:
> >I would like to gather up some momentum for a policy change. Namely
> >that the build-arch/indep targets in debian/rules become required
> >instead of being optional.
> Wouldn't looking for the output
>   make: *** No rule to make target `build-arch'.  Stop.
> and then defaulting to make build be an option?

make: *** Er is geen regel om 'build-arch' te maken.  Gestopt.

Yes, you can use LC_ALL=C, but some people do strange things to their
environment. The point is that parsing output that isn't meant for
machine consumption is usually a bad idea.

OTOH, this is trivial:

build-indep: build
build-arch: build
build:
foo
bar
baz

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: Can we require build-arch/indep targets for lenny?

[Wouter Verhelst]

On Mon, Jun 18, 2007 at 12:25:38PM -0400, Daniel Schepler wrote:
> How about instead requiring something like: the build-arch target must return 
> successfully or with a status of 2 (the standard make error status 
> for "target not found"), and in the latter case the build target must return 
> successfully.  That is, if Build-Depends but not necessarily 
> Build-Depends-Indep are installed, the shell snippet
> 
>   debian/rules build-arch || (test $? -eq 2 && debian/rules build)
> 
> must work and exit with a status of 0.
> 
> This would make it possible for dpkg-buildpackage -B to be reliable while 
> allowing most (or even all?) of the current packages to stay as they are 
> until maintainers can add the recommended build-arch target.

That has been tried, but it didn't work for some reason.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: GSASL Maintainer Missing in Action?

[Jorge Salamero Sanz]

On Thursday 14 June 2007 04:20:53 [EMAIL PROTECTED] wrote:
> Two weeks ago I've sent an email no Yvan, asking if he was still
> interested in maintaining those packages. Both have newer upstream
> versions. There is a bug with a patch for libgsasl7 that was not
> answered by Yvan. It is dated as of last December. libgasl7 and libntlm0
> were last uploaded in March 2006 and June 2006, respectively. I've sent
> another message to Yvan on Monday.

i also sent him a mail more than a week ago without reply. i'd like to see 
this lib updated on debian and i could help if you are looking for 
co-maintainers.

regards.


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

Re: Can we require build-arch/indep targets for lenny?

[Bill Allombert]

On Mon, Jun 18, 2007 at 10:30:55AM +0200, Goswin von Brederlow wrote:
> Hi,
> 
> I would like to gather up some momentum for a policy change. Namely
> that the build-arch/indep targets in debian/rules become required
> instead of being optional.
> 
> The reason for this is that dpkg-buildpackage can't reliable detect
> the existance of the build-arch/indep targets and must call 'build'
> instead. This forces every source to compile both architecture
> specific and architecture independent code on all buildds and
> increases the Build-Depends of packages a lot.

I suggest anyone reread the bug log for #218893 that give a
full account of the problem before commenting.

My preference is for the dpkg maintainers to apply the patch in the
buglog #229357, or at least reply to it.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

One vs. many -src packages for my project?

[Christian Convey]

I have an odd packaging situation, and was hoping someone could tell
me the best practice for this situation...

I've been asked to take an existing project and package it for use
with APT.  The project consists of many libraries and applications.

I was thinking to produce a different source package for each library
and application.

My concern is that our makefiles are hierarchial: each library and app
has its own makefile, but those makefiles pull in some "utility"
makefiles at the higher level:

myproj/make-functions1.mk
myproj/make-functions2.mk
myproj/Makefile <-- just calls 'make' on each subdirectory's makefile
myproj/libraryA/Makefile  <-- uses ../make-functions{1,2}.mk
myproj/libraryB/Makefile  <-- uses ../make-functions{1,2}.mk
myproj/appC/Makefile   <-- uses ../make-functions{1,2}.mk

So there's some overlap: both "libraryA-src.deb" and
"libraryB-src.deb" need to have "make-funtions{1,2}.mk" installed as
well.

I could create Yet Another Source Package, "myproject-common-src.deb",
that contains *only* those files that are in common.  I.e., it would
only contain "make-functions{1,2}.mk" and perhaps the top-level
Makefile.  Then package like "libraryA-src.deb" could have a package
dependency on myproject-common-src.deb.

Is this just too goofy of an approach?  Should I bit the bullet and
make the whole entire project contains just three packages?
(myproject.deb, myproject-dev.deb, and myproject-src.deb) ?

Thanks,
Christian


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

Re: Dependencies on shared libs, take 2

[Steve Langasek]

On Mon, Jun 18, 2007 at 12:01:23PM +0200, Loïc Minier wrote:
> On Mon, Jun 18, 2007, Mike Hommey wrote:
> > It's even worse. You're acting as if you were modifying debian/symbols
> > without modifying it, saying it's fine because you didn't modify it...

>  I think this is fine; the resulting "symbols" file can make strict
>  assumptions.

>  You don't expect dh_makeshlibs to make your build fail, even if you
>  might forgot excluding some new plugin dir for example.

I do.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/

Bug#429573: ITP: libacpi -- general purpose ACPI library

[Nico Golde]

Package: wnpp
Severity: wishlist
Owner: Nico Golde <[EMAIL PROTECTED]>

* Package name: libacpi
  Version : 0.1
  Upstream Author : Nico Golde <[EMAIL PROTECTED]>
* URL : http://www.ngolde.de/libacpi.html
* License : MIT/X
  Programming Lang: C
  Description : general purpose ACPI library

 libacpi is a general purpose shared library for programs gathering ACPI data 
on Linux.
 It implements thermal zones, battery information, fan information and AC 
states.

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

Kernel: Linux 2.6.20-1-686 (SMP w/1 CPU core)
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

-- 
Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


signature.asc
Description: Digital signature

Bug#429570: ITP: libws-commons-util-java -- Common utilities from the Apache Web Services Project

[Vladimír Lapáček]

Package: wnpp
Severity: wishlist
Owner: "Vladimír Lapáček" <[EMAIL PROTECTED]>

* Package name: libws-commons-util-java
  Version : 1.0.1
  Upstream Author : Jochen Wiedmann <[EMAIL PROTECTED]>
* URL : http://apache.osuosl.org/ws/commons/util/
* License : Apache License 2.0
  Programming Lang: Java
  Description : Common utilities from the Apache Web Services Project

 This is a small collection of utility classes, that allow high
 performance XML processing based on SAX.


-- System Information:
Debian Release: lenny/sid
  APT prefers gutsy
  APT policy: (500, 'gutsy')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-6-generic (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#429583: ITP: dtc -- PowerPC kernel device tree compiler

[Marc Leeman]

Package: wnpp
Severity: wishlist
Owner: Marc Leeman <[EMAIL PROTECTED]>

* Package name: dtc
  Version : 20070523
  Upstream Author : Jon Loeliger
* URL : git://www.jdl.com/software/dtc.git
* License : GPL
  Programming Lang: C
  Description : PowerPC kernel device tree compiler

  dtc basically takes a device-tree in a given format and outputs a
  device-tree in another format.


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

Kernel: Linux 2.6.21 (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


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

Re: One vs. many -src packages for my project?

[Frank Lichtenheld]

On Mon, Jun 18, 2007 at 04:28:09PM -0400, Christian Convey wrote:
> I could create Yet Another Source Package, "myproject-common-src.deb",
> that contains *only* those files that are in common.  I.e., it would
> only contain "make-functions{1,2}.mk" and perhaps the top-level
> Makefile.  Then package like "libraryA-src.deb" could have a package
> dependency on myproject-common-src.deb.

You could also just copy the file to the different source packages
when releasing the source, no? Or are they so big and are there so
many packages that will use them?

> Is this just too goofy of an approach?  Should I bit the bullet and
> make the whole entire project contains just three packages?
> (myproject.deb, myproject-dev.deb, and myproject-src.deb) ?

The biggest problem of this approach (IMHO) is that you only can
update them all at once. You need to increase the version number of
every binary package built from the source even though only one of
them might really have been changed. So it is generally a good idea
to modularize ones source packages (see e.g. X.org)

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Re: One vs. many -src packages for my project?

[Christian Convey]

On 6/18/07, Frank Lichtenheld <[EMAIL PROTECTED]> wrote:

On Mon, Jun 18, 2007 at 04:28:09PM -0400, Christian Convey wrote:
> I could create Yet Another Source Package, "myproject-common-src.deb",
> that contains *only* those files that are in common.  I.e., it would
> only contain "make-functions{1,2}.mk" and perhaps the top-level
> Makefile.  Then package like "libraryA-src.deb" could have a package
> dependency on myproject-common-src.deb.

You could also just copy the file to the different source packages
when releasing the source, no? Or are they so big and are there so
many packages that will use them?


I'm not dealing with very big sets of files at all.  But they're
broken out into 21 libraries and 18 application programs.  So if I
package them separately it's a whole lot of writing of control files,
changelogs, etc.

Are you suggesting that each subproject (libraryA, libraryB, etc.)
has, in its own source directory, a clone of the file
"make-functions{1,2}.mk" ?

I guess that would be somewhat OK, but it makes me a little
uncomfortable to clone files like that.  I wouldn't want to do that in
my own svn repository, because I don't want to maintain multiple
copies of what should be an identical file.

I guess I could keep just one copy in svn, and have my debian
packaging scripts copy it out to each subdirectory just prior to
packaging.  But then I'd also have to, at packaging time, modify each
sub-project's Makefile so that it looked for make-functions1.mk in the
current directory rather than the parent directory.  So now I'm
starting to look at a build process for my packaged source code that's
a little different than the process for building the code when I get
it right out of svn.  And that seems kind of like a bad idea.



> Is this just too goofy of an approach?  Should I bit the bullet and
> make the whole entire project contains just three packages?
> (myproject.deb, myproject-dev.deb, and myproject-src.deb) ?

The biggest problem of this approach (IMHO) is that you only can
update them all at once. You need to increase the version number of
every binary package built from the source even though only one of
them might really have been changed. So it is generally a good idea
to modularize ones source packages (see e.g. X.org)



My thinking was, "If there's not much overhead associated with having
a bunch of little packages, then do it, because it offers independent
versioning.  Otherwise just lump them all together in a big package."


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

Re: Using standardized SI prefixes

[Ben Finney]

Bastian Venthur <[EMAIL PROTECTED]> writes:

> I suggest that we prepare a wikipage on wiki.debian.org with a
> friendly formulated bugreport template. After this template is
> mature enough, we can start writing wishlist bugreports on packages
> making wrong use SI prefixes (e.g. write KB but mean KiB) asking
> them to consider to switch to binary prefixes instead.

Done, http://wiki.debian.org/ConsistentUnitPrefixes>. Please
modify the bug report as needed; currently I think it may be a bit too
wordy, but lack the skill to pare it down without losing necessary
explanation or examples.

> We should not urge to use either binary prefixes or SI prefixes
> consistently in all packages! Instead we should urge to use the
> prefixes *correctly*. When 1k means 1000 Bytes, it is OK to use it
> -- when it means 1024 they, should make the switch to binary
> prefixes.

Agreed, this is the approach I've taken in the bug report.

-- 
 \ "I have had a perfectly wonderful evening, but this wasn't it." |
  `\   -- Groucho Marx |
_o__)  |
Ben Finney


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

Bug#429610: ITP: gbrowse -- The Generic Genome Browser from GMOD

[Charles Plessy]

Package: wnpp
Severity: wishlist
Owner: Charles Plessy <[EMAIL PROTECTED]>

  Package name: gbrowse
  Version : 1.68
  Upstream Author : Lincoln Stein & the GMOD team ([EMAIL PROTECTED])
  URL : http://www.gmod.org/wiki/index.php/GBrowse
  License : Same as Perl, plus additional clauses (see below)
  Programming Lang: Perl
  Description : The Generic Genome Browser from GMOD

 The Generic Genome Browser is a combination of database and interactive Web
 page for manipulating and displaying annotations on genomes. Some of its
 features:
  * Simultaneous bird's eye and detailed views of the genome.
  * Scroll, zoom, center.
  * Attach arbitrary URLs to any annotation.
  * Order and appearance of tracks are customizable by administrator and 
end-user.
  * Search by annotation ID, name, or comment.
  * Supports third party annotation using GFF formats.
  * Settings persist across sessions.
  * DNA and GFF dumps.
  * Connectivity to different databases, including BioSQL and Chado.
  * Multi-language support.
  * Third-party feature loading.
  * Customizable plug-in architecture (e.g. run BLAST, dump & import many 
formats,
find oligonucleotides, design primers, create restriction maps, edit 
features)
 .
  Homepage: http://www.gmod.org/wiki/index.php/GBrowse

I have made a draft package for my own use at work and uploaded it in
Debian-Med's SVN. (http://svn.debian.org/wsvn/debian-med/trunk/packages/gbrowse)
Gbrowse needs bioperl 1.5.2 which is not yet available in Debian (work in
progress...) Moreover, I have a few older ITPs to finish first. But if you are
interested in Gbrowse, please contact me in private: I can change my 
priorities.


Full DISCLAIMER file:

-

The Generic Genome Browser package and all associated files are
Copyright (c) 2002 Cold Spring Harbor Laboratory and University of
California, Berkeley.

This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.  See the Artistic License file
in the main Perl distribution for specific terms and conditions of
use.  In addition, the following disclaimers apply:

CSHL makes no representations whatsoever as to the SOFTWARE contained
herein.  It is experimental in nature and is provided WITHOUT WARRANTY
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE OR ANY OTHER
WARRANTY, EXPRESS OR IMPLIED.  CSHL MAKES NO REPRESENTATION OR
WARRANTY THAT THE USE OF THIS SOFTWARE WILL NOT INFRINGE ANY PATENT OR
OTHER PROPRIETARY RIGHT.

By downloading this SOFTWARE, your Institution hereby indemnifies CSHL
against any loss, claim, damage or liability, of whatsoever kind or
nature, which may arise from your Institution's respective use,
handling or storage of the SOFTWARE.

If publications result from research using this SOFTWARE, we ask that
CSHL and University of California, Berkeley be acknowledged and/or
credit be given to CSHL/Berkeley scientists, as scientifically
appropriate.

-

Unfortunately, the indemnification clause makes gbrowse incompatible with the
GPL. Is it possible to recursively explore the dependancy graph of gbrowse to
check that there is no GPL-only program in in ? In the long term, maybe Debtags
could be useful for this...


-- Charles Plessy


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-4-486
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)


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

Odd dh_strip failure with some packages

[Russ Allbery]

Reviewing the latest lintian findings, there are a surprising number of
packages with unstripped binaries, including some that are using debhelper
and dh_strip.  See:

http://lintian.debian.org/reports/Tunstripped-binary-or-object.html

Looking at build logs on i386, the common problem for many seems to be
variations of:

dh_strip
strip: unable to copy file 
'debian/libwebauth-perl/usr/lib/perl5/auto/WebAuth/WebAuth.so' reason: 
Permission denied

I can't duplicate this with a build under cowbuilder with fakeroot, but
that may not be horribly surprising.

Spot-checking several packages with this issue, they all seem to have been
auto-built on ninsei (in some cases, years ago), which makes me think this
may be a very long-standing problem with that particular buildd.  I'm not
sure who to contact, though (or how to find that out).

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

lintian.debian.org updated to lintian 1.23.31

[Russ Allbery]

After one false start (I thought it was hung, but there was a quadratic
search in one of the checks that's now been fixed), lintian.debian.org
output has been updated to lintian 1.23.31.  This should eliminate quite a
few false positives.

It's a bit behind the current archives at the moment since it just
finished a complete run, and the statistics about change in counts are
bogus (since they were against an aborted run), but that should clear up
after the next daily run.

I was surprised at this new statistic:

Overridden tags:10724

That's a lot of overrides.  I know that a fair number of those are for
library package naming and related issues, but that's still a *lot* of
overrides.  If you have any overrides in your package that you think
represent a bug (even a wishlist bug) in lintian, please do file that bug.
You should not have to add an override unless the long description for
that lintian tag specifically says to override the tag if the described
circumstances don't apply to your package.

Also, a general reminder: If you have any overrides, periodically run
lintian --show-overrides and see if they're actually being used.  A lot of
false positives have been fixed over the years.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Using standardized SI prefixes

[Ivan Jager]

On Sat, 16 Jun 2007, Wesley J. Landaker wrote:


On Saturday 16 June 2007 04:43:53 Josselin Mouette wrote:

Le vendredi 15 juin 2007 ?? 17:36 -0400, Ivan Jager a ??crit :

Yes. Any time the unit is bytes. There is even a standard for it.


I must have missed that one. Could you point us to this standard?


I too would love to see that standard.


Ok, so it appears to be deprecated, but it does exist.

October 30, 1986 ANSI/IEEE Std 1084-1986 IEEE Standard Glossary of 
Mathematics of Computing Terminology.


http://ieeexplore.ieee.org/iel1/2485/1030/00026589.pdf?isnumber=1030&prod=&arnumber=26589&arSt=&ared=&arAuthor=

"kilo (K). (1) A prefix indicating one thousand. (2) In statements 
involving size of computer storage, a prefix indicating 2^10, or 1024."


"mega (M). (1) A prefix indicating one million. (2) In statements 
involving size of computer storage, a prefix indicating 2^20, or 
1,048,576."


Apparently back then giga wasn't ever applied to computer storage. :)

Ivan

Bug#429618: ITP: xcalib -- Tiny monitor calibration loader for Xorg

[Jorge Salamero Sanz]

Package: wnpp
Severity: wishlist
Owner: Jorge Salamero Sanz <[EMAIL PROTECTED]>
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: xcalib
  Version : 0.6
  Upstream Author : Stefan Döhla 
* URL : http://www.etg.e-technik.uni-erlangen.de/web/doe/xcalib/
* License : GPL
  Programming Lang: C
  Description : Tiny monitor calibration loader for Xorg

 A tiny monitor calibration loader for Xorg. It loads 'vcgt'-tag of
 ICC profiles to the X-server to calibrate your display.

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

Kernel: Linux 2.6.21.5-mactel (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Re: Odd dh_strip failure with some packages

[Marc 'HE' Brockschmidt]

Russ Allbery <[EMAIL PROTECTED]> writes:
> Looking at build logs on i386, the common problem for many seems to be
> variations of:
>
> dh_strip
> strip: unable to copy file 
> 'debian/libwebauth-perl/usr/lib/perl5/auto/WebAuth/WebAuth.so' reason: 
> Permission denied
>
> I can't duplicate this with a build under cowbuilder with fakeroot, but
> that may not be horribly surprising.

This is a known problem with XFS (which is used as FS on the i386
buildd) [1] - usually switching the order of the dh_fixperms and
dh_strip calls helps.

Marc

Footnotes: 
[1]  I think it was something about not stripping the file is not +x or
 something
-- 
BOFH #250:
Program load too heavy for processor to lift.


pgpKcaFySZfXO.pgp
Description: PGP signature