Re: /var/www is depracated, which directory to use?

On Sat, Oct 31, 2009 at 06:46:42PM +0200, Holger Levsen wrote:

> On Samstag, 31. Oktober 2009, sean finney wrote:
> > if it's regenerable, then i'd say /var/cache/munin/something is the
> > right place, and if isn't /var/lib/munin/something.  if you seperate
> > the things that the user might want to configure (css, etc), where's
> > the problem[1]?

> that it's butt ugly and work for no gain? plus, seperating is not supported 
> upstream, so it will need patching for no gain...

> i'm absolutly not convinced this is the right solution. 

I think that the right solution is to not have web apps in our archive
unless they can be made to conform with policy's requirements.  If a web app
isn't going to comply with the FHS, that's fine - but that web app doesn't
need to be in the Debian archive.

If you think it's "butt ugly" for your web app package to behave in a manner
consistent with all the other packages in the archive, we clearly have
different views when it comes to aesthetics.

--

-- 
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 Developer                                    http://www.debian.org/
slangasek <at> ubuntu.com                                     vorlon <at> debian.org

Re: Clarify rationale for ‘debian/rules’ shebang line

> | === modified file 'policy.sgml'
> | --- policy.sgml 2009-10-21 20:49:37 +0000
> | +++ policy.sgml 2009-10-31 00:59:18 +0000
> | @@ -1725,7 +1725,10 @@
> |         <p>
> |           It must start with the line <tt>#!/usr/bin/make -f</tt>,

[Tollef Fog Heen]
> This should probably also be changed to allow «#! /usr/bin/make -f»
> too.  There's no reason to mandate one particular style of hashbangs.

Why not?  Honestly, it's no more arbitrary than the restriction we
already have.  If the VDR people can live with having to use
#!/usr/bin/make -f instead of their trivial wrapper, you can live with
the inability to use a space after the #!.

The VDR people already said the _only_ behavior difference with their
wrapper script happens if you pass a magic nonstandard environment
variable.  That's the sort of thing you can't do by accident, only if
you're following specific instructions.  By forbidding this, what
problem are we solving?  Seems purely aesthetic to me.  Just like
whether or not to put a space after #!.

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org

Re: Lintian based autorejects

Stefano Zacchiroli wrote:

> Can you please consider changing the above naming?

FWIW the actual reject messages are very clear and do not use these
terms (which I've changed in Git anyway, pending merge). Thanks.

Regards,

--

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby <at> debian.org
       `-

AMD64 build issues

Dear all,

recently I found out that the only arch where texworks is not build
is amd64 (the -2 debian release of texworks).

Looking into the buildd I see that *several* packages are hanging there
in the queue since up to 8(!) days.

Is that a problem on the buildd, can someone restart the queue there,
or whatever has to be done to get it working again?

See
https://buildd.debian.org/~luk/status/architecture.php?suite=&a=amd64&buildd=buildd_amd64-excelsior

Thanks

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining                                        Associate Professor
JAIST Japan Advanced Institute of Science and Technology   preining <at> jaist.ac.jp
Vienna University of Technology                               preining <at> logic.at
Debian Developer (Debian TeX Task Force)                    preining <at> debian.org
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
POPCASTLE (n.)
Something drawn or modelled by a small child which you are supposed to
know what it is.
			--- Douglas Adams, The Meaning of Liff

Bug#553582: ITP: libapache-session-ldap-perl -- LDAP Backend for Apache::Session system

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard <x.guimard <at> free.fr>

* Package name    : libapache-session-ldap-perl
  Version         : 0.2
  Upstream Author : Xavier Guimard <x.guimard <at> free.fr>
* URL             : http://search.cpan.org/~guimard/Apache-Session-LDAP-0.02/
* License         : Artistic | GPL2
  Programming Lang: Perl
  Description     : LDAP Backend for Apache::Session system

LDAP directory is a very fast system to provide a session storage system for CGIs especially when session
are read more than written. This backend has been written for Lemonldap::NG web-sso system.

Re: Lintian based autorejects

On Tue, Oct 27, 2009 at 03:06:07PM +0100, Joerg Jaspert wrote:
> The second category is named "error" and the tags listed can not be
> overridden. Those are tags corresponding to packaging errors serious
> enough to mark a package unfit for the archive and should never happen.
> In fact, most of the tags listed do not appear in our archive
> currently, the few packages listed below should be easily fixable with
> their next upload.

> We will provide a static url for the list of tags soon, for now you can
> look at them using [1].

> There are multiple files in [2] showing you the packages affected,
> together with the tags they hit.

> [1] http://ftp-master.debian.org/~joerg/lintian/lintian.tags
> [2] http://ftp-master.debian.org/~joerg/lintian/

Since I'm not familiar with most of these lintian errors by name, I've run
the list of fatal errors through lintian-info with the following script:

$ wget -O - -q http://ftp-master.debian.org/~joerg/lintian/lintian.tags \
| sed -e'1,/error:$/d; s/^[[:space:]]\+-/E: ftp-master:/' | lintian-info

I'd recommend that others do likewise, to get an appropriately large set of
eyeballs on this change.

Some problems I find with this list:

E: ftp-master: wrong-file-owner-uid-or-gid
N:

Re: Lintian based autorejects

>  getting around to filing bugs on policy MUST violations and others that
>  make the package too buggy to be in Debian

Wow, time goes so fast, it is already the season for attempting to delay the
release!

--

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Distro baseada en DEBIAN====Distribuicion basada en DEBIAN === Distro Based DEBIAN

Re: Lintian based autorejects

* Steve Langasek <vorlon <at> debian.org> [091101 11:23]:
> Some problems I find with this list:

I think some of those complaints show a general disagreement about
what aims Debian has. Are we here to gain for quality or is allowing
the maximum amount of (free) software the primary goal?

> E: ftp-master: copyright-lists-upstream-authors-with-dh_make-boilerplate
> [...]
>
> This one has been mentioned previously in the thread.  Yes, it's a blemish
> in the package to list "Upstream Author(s)", but the lintian maintainers
> have correctly marked this as being of "normal" severity.  We should not be
> blocking packages from the archive for such low-severity issues; please drop
> this check.

I think a suggestion that a bug filed about this should be "normal" and
rejecting a package targeted at unstable or experimental with this can
be fully compatible.
Already having a problem with that in the archive is no problem (and
there is no reason to stall testing migration because of it). But why
should we allow a new version of this package uploaded? Even in case of
an NMU its no effort at all to fix it.

> E: ftp-master: section-is-dh_make-template
> [...]
>
> Sections in source packages have minimal impact; the section that matters is
> the one specified in the archive override.  There's no reason that the
> invalid default value given by dh_make should result in a package being
> rejected, when arbitrary other values for the field would not.  Please drop
> this check.

Again, even if it has no big impact, why should we allow it? It's not
hard to find (lintian will tell it), and not at all hard to fix.

> E: ftp-master: executable-in-usr-share-doc
> [...]
>
> Clearly a bug, but just as clearly not anything that breaks the package to
> the point of making it unsuitable for the archive.  Please drop.

Again, what is the advantage of dropping it? As files in /usr/share/doc
should not be needed for the package to function (otherwise it is an
even more serious bug), the biggest possible cost for the maintainer to
fix this is a single rebuild.

	Bernhard R. Link