Re: RFS: uncrustify (updated package) (second try)

[Patrick Winnertz]

Am Montag, 11. Februar 2008 22:18:43 schrieb Johann Rudloff:
> Am Sonntag, den 10.02.2008, 21:39 +0100 schrieb Patrick Winnertz:
> >  - remove config.{sub|guess} in clean target
> >  - you forgot to mention in changelog that you added a Homepage tag to
> > debian/control
> >  - you forgot to mention that you removed autotools-dev as Build-Dep
> >  - you forgot to mention that you changed the manpage
>
> Thank you for your help!
> I added the missing changelog entries.
> But when I remove the part in the clean target which copies new versions
> of config.{sub,guess} (I hope this was what you meant.) I get lintian
> errors about these files being out of date.
Just rm -f them in the clean target with nothing else. This should work

Greetings
Winnie



-- 
 .''`.   Patrick Winnertz <[EMAIL PROTECTED]>
:  :' :  GNU/Linux Debian Developer
`. `'`   http://www.der-winnie.de http://people.skolelinux.org/~winnie
  `-  Debian - when you have better things to do than fixing systems


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

Re: RFS: syslog-summary (updated and adopted package)

[David Paleino]

Il giorno Thu, 7 Feb 2008 10:57:06 +0100
David Paleino <[EMAIL PROTECTED]> ha scritto:

> Dear mentors,
> 
> I am looking for a sponsor for the new version 1.13 of the package
> "syslog-summary", which I'm also adopting (ITA: #455005).
> 
> It builds these binary packages:
> syslog-summary - summarize the contents of a syslog log file
>  This program summarizes the contents of a log file written by syslog,
>  by displaying each unique (except for the time) line once, and also
>  the number of times such a line occurs in the input. The lines are
>  displayed in the order they occur in the input.
>  .
>  It is also possible to define some "ignore rules" using regular
>  expressions.
> 
> The package is lintian (from unstable) clean.
> 
> The upload would fix the bugs: 266423, 416154 (and the ITA mentioned above)
>
> The package can be found on mentors.debian.net:
> - dget
> http://mentors.debian.net/debian/pool/main/s/syslog-summary/syslog-summary_1.13.dsc

Yet another ping :)

David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

RFS: mailscanner (updated package)

[Simon Walter]

Dear mentors,

I am looking for a sponsor for the new version 4.65.3-1
of my package "mailscanner".

It builds these binary packages:
mailscanner - email gateway for virus scanning, spam and phishing detection

The package appears to be lintian clean.

The upload would fix these bugs: 412883, 425861, 429954, 432881, 435998, 
449140, 454381

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/m/mailscanner
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/m/mailscanner/mailscanner_4.65.3-1.dsc

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

Kind regards
 Simon Walter


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

Re: Config files which are writable by www-data

[Roland Gruber (LAM)]

Hi Russ,

Russ Allbery schrieb:
> No, you're not allowed to reference /usr/share/doc from maintainer
> scripts.  dpkg may be modified to not install /usr/share/doc at all.  You
> should ship them in /usr/share/ and add a symlink in
> /usr/share/doc if desired.
> 
> See Policy 12.3.

thanks for the clarification. I thought 12.3 was talking about runtime
dependencies.
So I will install the files in /usr/share/l-a-m.


-- 

Best regards

Roland Gruber


LDAP Account Manager
http://lam.sourceforge.net



signature.asc
Description: OpenPGP digital signature

Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Russ Allbery]

Bas Wijnen <[EMAIL PROTECTED]> writes:

> I suggest to mandate "remove all generated files in the clean target"
> (formulated in a way which includes "generated by upstream", not only
> "generated by the build target), which implies "rebuild everything in
> the build target".

[...]

> I'd like to hear why this exception is so important for people.  Or
> better yet, I'd like to hear that everyone agrees with me, so we can
> make this change and finally to the Right Thing. :-)

It may be less common now, but for many years it was quite common for
upstreams to use very specific versions of autotools, which means that if
Debian had dropped the specific autoconf in question, it wasn't easy to
regenerate the files.  Now, that may be a problem for other reasons since
as you point out it means we don't really have horribly usable source, but
that's the most common practical concern, I think.

Always re-running autoconf and automake would increase the number of
FTBFS's that we'd need to fix.  (Probably for the greater good of free
software, but.)

Also, it's not always easy to figure out which files are generated in
order to remove them, but that's probably programmatically fixable.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Bas Wijnen]

On Mon, Feb 11, 2008 at 09:21:29AM -0800, Russ Allbery wrote:
> Bas Wijnen <[EMAIL PROTECTED]> writes:
> 
> > I suggest to mandate "remove all generated files in the clean target"
> > (formulated in a way which includes "generated by upstream", not only
> > "generated by the build target), which implies "rebuild everything in
> > the build target".
> 
> [...]
> 
> > I'd like to hear why this exception is so important for people.  Or
> > better yet, I'd like to hear that everyone agrees with me, so we can
> > make this change and finally to the Right Thing. :-)
> 
> It may be less common now, but for many years it was quite common for
> upstreams to use very specific versions of autotools, which means that if
> Debian had dropped the specific autoconf in question, it wasn't easy to
> regenerate the files.  Now, that may be a problem for other reasons since
> as you point out it means we don't really have horribly usable source, but
> that's the most common practical concern, I think.

Oh, I didn't know that.  IMO that would mean the package should really
be in contrib, because we're missing a build dependency in main then
(not used, but AFAIK using pre-built files is not an acceptable way to
avoid getting in contrib in such a situation).

Anyway, I don't think that is still a reason for not running autotools
nowadays, so it's just historical background. :-)

> Always re-running autoconf and automake would increase the number of
> FTBFS's that we'd need to fix.

Not really.  It would lead to many bugs that packages aren't following
policy.  Especially if we start with should and later (possibly) upgrade
it to must, I think it is workable.  In particular because these bugs
don't actually stop a package from being built.  I would be very happy
with consensus that the autotools _should_ be run during build.  The
implementation of actually doing it in all packages may take a while, I
don't have a problem with that.

Unless of course you are talking about cdbs.  When that changes to
running autotools, it likely needs to know if there are extra arguments.
That may indeed result in FTBFSs for many packages which use it (because
they may need, but don't provide, the arguments).  But it's good when
they're fixed as well. :-)

> (Probably for the greater good of free software, but.)

Yes, IMO it's one of those situations where Debian should do what's
Right, not what's Easy (similar to what I wrote about the /bin/sh
bash->dash move on -policy today).

> Also, it's not always easy to figure out which files are generated in
> order to remove them, but that's probably programmatically fixable.

That's in principle a problem for the maintainer to solve, and
secundarily for lintian.  If things can be automated, that may be nice,
but it is not required.  Once policy mandates to remove generated files
in the clean target, it's up to the maintainer to do it.  And if the
maintainer makes a mistake and forgets to remove a file, that's not a
big problem (it would be a bug with this change in policy, but only a
minor one, IMO).

At this moment however, I don't think there is consensus yet that it is
always better to remove all generated files, including
autotools-generated stuff, in the clean target.  After that happens, we
can think about how to implement it in the archive.  Slowly, I would
suggest. :-)  Because it is a good thing if we do this Right, but we
shouldn't break half the archive for it. ;-)

Thanks,
Bas

-- 
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: RFC: Howto exclude config.sub and config.guess updates from .diff.gz

[Cyril Brulebois]

On 11/02/2008, David Paleino wrote:
> Not true:
> [Snip unrelated logic stuff.]

Yes, true. Functionally, you want foo => bar. Check (assuming here foo
is absent):
,
| [EMAIL PROTECTED]:~$ [ ! -f foo ] && echo "Doing bar 1"
| Doing bar 1
| [EMAIL PROTECTED]:~$ [ -f foo ]   && echo "Doing bar 2"
| [EMAIL PROTECTED]:~$ [ ! ! -f foo ] || echo "Doing bar 1"
| Doing bar 1
| [EMAIL PROTECTED]:~$ [ ! -f foo  ]  || echo "Doing bar 2"
| [EMAIL PROTECTED]:~$
`

Now, moving that to a Makefile:
,
| #!/usr/bin/make -f
|
| and:
|   [ ! -f foo ] && echo "Doing bar 1"
|   [ -f foo ]   && echo "Doing bar 2"
|
| or:
|   [ ! ! -f foo ] || echo "Doing bar 1"
|   [ ! -f foo  ]  || echo "Doing bar 2"
`

You now get:
,
| [EMAIL PROTECTED]:~$ make or
| [ ! ! -f foo ] || echo "Doing bar 1"
| Doing bar 1
| [ ! -f foo  ]  || echo "Doing bar 2"
| [EMAIL PROTECTED]:~$ make and
| [ ! -f foo ] && echo "Doing bar 1"
| Doing bar 1
| [ -f foo ]   && echo "Doing bar 2"
| make: *** [and] Erreur 1
`


> but I can't understand why it couldn't suggest something like:
>
> [ -f Makefile ] && $(MAKE) distclean
>
> which triggers the same result (at least in bash -- that's why I'm
> supposing that "&&" needs to be escaped somehow in Makefiles).

Explained already in my first mail, and in extenso by Justin.

-- 
Cyril Brulebois


pgpy7kq0QwpEG.pgp
Description: PGP signature

Re: RFC: Howto exclude config.sub and config.guess updates from .diff.gz

[David Paleino]

Il giorno Mon, 11 Feb 2008 10:55:04 -0500
Justin Pryzby <[EMAIL PROTECTED]> ha scritto:

> A set -e shell script doesn't terminate if a nonzero return value is a
> part of a conditional/test.  However in a makefile, the exit status of
> the shell can be nonzero even if it was a due to a test "failing", so
> you have to use [ ! ] || and not the more readable [ ] &&, since the sh
> -c '' will still exit 1.  For the same reason, you need to explicitly
> exit 0 at the end of some scripts:
> 
> for a
> do
>   [...]
>   [ ] && foo
> done
> 
> # Necessary due to the test
> exit 0

Thank you for the clear explanation :)

David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: RFC: Exclude config.sub and config.guess from

[Justin Pryzby]

On Mon, Feb 11, 2008 at 04:42:34PM +0100, David Paleino wrote:
> Il giorno Mon, 11 Feb 2008 15:19:08 +0100 Daniel Leidert <[EMAIL PROTECTED]> 
> ha scritto:
> 
> > Copy the config.* scripts after the clean target has been called (e.g.
> > in the config.status target) then they are simply not part of the
> > diff.gz. Of course they would be after a second build run. If you care
> > and if you want to avoid this: preserve the original config.* scripts
> > and put them back in the clean-target. This increases the whole
> > debian/rules file for around 4 lines.
> > 
> > This *is* much more easier than any other suggestion I read in this
> > thread.

> [1] I know that using "[ ! test ] || ..." is pretty awkward, but it
> didn't work with "[ test ] &&". Maybe "&&" should be escaped somehow?
> I don't really know.
A set -e shell script doesn't terminate if a nonzero return value is a
part of a conditional/test.  However in a makefile, the exit status of
the shell can be nonzero even if it was a due to a test "failing", so
you have to use [ ! ] || and not the more readable [ ] &&, since the sh
-c '' will still exit 1.  For the same reason, you need to explicitly
exit 0 at the end of some scripts:

for a
do
[...]
[ ] && foo
done

# Necessary due to the test
exit 0

Justin


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

RFS: tcpser (updated package) (try 2)

[Peter Collingbourne]

Dear mentors,

I am looking for a sponsor for my updated package "tcpser".

* Package name: tcpser
  Version : 1.0rc12-1
  Upstream Author : Jim Brain <[EMAIL PROTECTED]>
* URL : http://www.jbrain.com/pub/linux/serial
* License : GPL
  Section : net

It builds these binary packages:
tcpser - emulate a Hayes compatible modem

The package is lintian/pbuilder clean, except for a
source-contains-svn-control-dir warning which I have been advised
to ignore.

The package can be found in the collab-maint bzr repository at:
bzr co http://bzr.debian.org/collab-maint/tcpser/unstable/ tcpser

You can also get the dsc from
dget http://www.doc.ic.ac.uk/~pcc03/tmp/debian/tcpser_1.0rc12-1.dsc

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

Thanks,
-- 
Peter


signature.asc
Description: Digital signature

Re: RFC: Howto exclude config.sub and config.guess updates from .diff.gz

[David Paleino]

Il giorno Mon, 11 Feb 2008 16:50:33 +0100
Cyril Brulebois <[EMAIL PROTECTED]> ha scritto:

> On 11/02/2008, David Paleino wrote:
> > This seems to me more hackish than it should; is there a cleaner way
> > to do it (maybe I'm just complicating myself and don't see The Easy
> > Way [1])?
> 
> You could have a look at how cdbs does it, which might help.

I'll do it, thanks.

> > [1] I know that using "[ ! test ] || ..." is pretty awkward, but it
> > didn't work with "[ test ] &&". Maybe "&&" should be escaped
> > somehow? I don't really know.
> 
> That's simple, compare:
>   [ foo ] && bar
>   [ ! foo ] || bar
> 
> If foo, then bar, and success.
> If not foo, then not bar, and failure. Here is your problem.
>
> The foo/bar relationship is the same, but not the return code, which
> is problematic in a Makefile, since it introduces a failure, thus make
> stops (see lintian about ignoring the errors in the clean target).

Not true:

$ touch foo
$ [ -f foo ] && true   (1)
$ echo $?
0
$ [ ! -f foo ] || true (2)
$ echo $?
0 
$

Those relationships are:

(1) (true) and (true) == true
(2) (false) or (true) == true

And the lintian warning suggests:

[ ! -f Makefile ] || $(MAKE) distclean

but I can't understand why it couldn't suggest something like:

[ -f Makefile ] && $(MAKE) distclean

which triggers the same result (at least in bash -- that's why I'm supposing
that "&&" needs to be escaped somehow in Makefiles).

Regards,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: RFC: Exclude config.sub and config.guess from

[Cyril Brulebois]

On 11/02/2008, David Paleino wrote:
> This seems to me more hackish than it should; is there a cleaner way
> to do it (maybe I'm just complicating myself and don't see The Easy
> Way [1])?

You could have a look at how cdbs does it, which might help.

> [1] I know that using "[ ! test ] || ..." is pretty awkward, but it
> didn't work with "[ test ] &&". Maybe "&&" should be escaped
> somehow? I don't really know.

That's simple, compare:
  [ foo ] && bar
  [ ! foo ] || bar

If foo, then bar, and success.
If not foo, then not bar, and failure. Here is your problem.

The foo/bar relationship is the same, but not the return code, which
is problematic in a Makefile, since it introduces a failure, thus make
stops (see lintian about ignoring the errors in the clean target).

Cheers,

-- 
Cyril Brulebois


pgpK2yQJ1P7Md.pgp
Description: PGP signature

Re: RFC: Howto exclude config.sub and config.guess updates from .diff.gz

[David Paleino]

Il giorno Mon, 11 Feb 2008 15:23:46 +0100
Daniel Leidert <[EMAIL PROTECTED]> ha scritto:

> Sorry, I broke the subject with my last post. I wanted to adjust it, but
> forgot finish the subject line. Really sorry.

...and I read this post a second later having sent my reply. Please fix the
subject on yours :)

David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Russ Allbery]

Bas Wijnen <[EMAIL PROTECTED]> writes:
> On Mon, Feb 11, 2008 at 09:21:29AM -0800, Russ Allbery wrote:

>> Always re-running autoconf and automake would increase the number of
>> FTBFS's that we'd need to fix.

> Not really.

No, really, I promise it will.  :)  Each time we upgrade autoconf, it will
break a bunch of packages that were doing things that weren't supported.

Now, those really were bugs and should be fixed.  But turning them into
FTBFS bugs does escalate the severity quite a bit.

> It would lead to many bugs that packages aren't following policy.
> Especially if we start with should and later (possibly) upgrade it to
> must, I think it is workable.  In particular because these bugs don't
> actually stop a package from being built.  I would be very happy with
> consensus that the autotools _should_ be run during build.  The
> implementation of actually doing it in all packages may take a while, I
> don't have a problem with that.

Well, I don't do it for mine right now because it takes a long time and
feels kind of pointless, but I'm happy to go along with any consensus.
But that part isn't so much the concern.

> Yes, IMO it's one of those situations where Debian should do what's
> Right, not what's Easy (similar to what I wrote about the /bin/sh
> bash->dash move on -policy today).

I am generally in favor of that, but I also don't have the free time to
volunteer for the release team, who ends up bearing the brunt of us doing
the right thing in this area, so, y'know, easy for me to say.  :)

> That's in principle a problem for the maintainer to solve, and
> secundarily for lintian.

Well, yeah, but it would still be nice to provide some help.

> At this moment however, I don't think there is consensus yet that it is
> always better to remove all generated files, including
> autotools-generated stuff, in the clean target.  After that happens, we
> can think about how to implement it in the archive.  Slowly, I would
> suggest. :-) Because it is a good thing if we do this Right, but we
> shouldn't break half the archive for it. ;-)

Yup.  :)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Lintian: outdated-autotools-helper-file

[Daniel Leidert]

Am Montag, den 11.02.2008, 14:17 +0100 schrieb Daniel Leidert:
> Am Montag, den 11.02.2008, 10:54 +0100 schrieb David Paleino:
> > Il giorno Mon, 11 Feb 2008 10:53:48 +0100
> > Bas Wijnen <[EMAIL PROTECTED]> ha scritto:
> > 
> > > I suggest to mandate "remove all generated files in the clean target"
> > > (formulated in a way which includes "generated by upstream", not only
> > > "generated by the build target), which implies "rebuild everything in
> > > the build target".
> > 
> > I fully agree with you here: the build target should also build Makefile.in
> > from Makefile.am, for example. Thus we clean *.in, *.sub, *.guess, in the 
> > clean
> > target.
> 
> The files you mention belong to the maintainer-clean target. To remove
> them in the debian/rules clean target you would often have to repackage
> the source tarball, which often includes patching, because many
> autotools-based build environments do not fully implement
> maintainer-clean. Otherwise you would need to duplicate maintainer-clean
> in the debian/rules clean target (good luck with large source archives,
> maybe including even sub-projects!). You further need to build depend on
> the whole autotools chain + additional tools like gnome-doc-utils or
> intltool or 

I even forgot some point: The scripts (often: autogen.sh) to (re-)create
the build environment are normally only part of the upstream VCS but are
not shipped with the source tarball. So even if the project fully
implemented maintainer-clean, you would need to copy this file from the
upstream VCS or write it yourself to recreate the build environment. But
these scripts are sometimes more complicated than a simple call to
autoheader, aclocal, autoconf and automake.

I think the idea to use the pure VCS source without any
autotools-generated file creates much more issues than it maybe solves.

Regards, Daniel


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

Re: Lintian: outdated-autotools-helper-file

[David Paleino]

Il giorno Mon, 11 Feb 2008 14:17:54 +0100
Daniel Leidert <[EMAIL PROTECTED]> ha scritto:

> We simply copy config.sub and config.guess into the build directory for
> some years now and I never observed any problem with this.
> 
> I'm really wondering why you want to make the situation complicated?

And if the config.{sub,guess} copied are different from those provided
upstream, isn't this difference going to pollute the .diff.gz? I'd like to take
the .diff.gz the most clean possible; i.e. only keep debian/ in it.

Kindly,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Henrique de Moraes Holschuh]

On Mon, 11 Feb 2008, Kapil Hari Paranjape wrote:
> Note that if the upstream's auto-generated files are deleted during
> the clean target, then the source *must* be re-packaged to avoid
> needless clutter in the .diff.gz which is of a "negative" nature.

Not so.  Deletions are ignored.  Ever tried it?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: RFS: python-twitter

[Piotr Ożarowski]

Hi Mauro,

I've changed your package a little bit (fixed lintian error, etc., see
attachment).

Please take a look and disagree if you don't like my changes.

[Mauro Lizaur, 11.02.2008]
> Btw, i added a few lines to install the examples in /usr/bin (one of
> them is a mini client)

manpages are missing
(lintian warns about it, please check `lintian -i package.changes` output)
-- 
http://people.debian.org/~piotr/sponsor.txt


python-twitter.diff.gz
Description: application/gunzip


pgpkSZmwuJiDk.pgp
Description: PGP signature

Re: Help with watch file -- pre-release upstream versions

[Székelyi Szabolcs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Leo "costela" Antunes wrote:
> Székelyi Szabolcs wrote:
>> What's the usual way of handling "preX" upstream version numbers in
>> watch files? I'm having trouble because uscan considers 1.0pre3 newer
>> than 1.0.
>
> Perhaps mangling the upstream version to use the tilde ("~") as a
> separator? But I don't really know if uscan even recognizes it...

Thanks to all, it works this way.

- --
cc


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

iD8DBQFHsL0XGJRwVVqzMkMRAq/jAJ9FhO+irUtptNuuepW4AxBrgeAD2gCdEOxq
zS0+5kZ1owexjkXz6qqAG/Q=
=QW7T
-END PGP SIGNATURE-


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

Re: RFS: uncrustify (updated package) (second try)

[Johann Rudloff]

Am Sonntag, den 10.02.2008, 21:39 +0100 schrieb Patrick Winnertz:
>  - remove config.{sub|guess} in clean target
>  - you forgot to mention in changelog that you added a Homepage tag to 
> debian/control
>  - you forgot to mention that you removed autotools-dev as Build-Dep
>  - you forgot to mention that you changed the manpage

Thank you for your help!
I added the missing changelog entries.
But when I remove the part in the clean target which copies new versions
of config.{sub,guess} (I hope this was what you meant.) I get lintian
errors about these files being out of date.

So what's best to do?
What I can read out of autotools-dev/README.Debian.gz, best practice
would be to readd autotools-dev as build-dep and leave the copying part
in debian/rules.

Johann Rudloff


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

Re: RFS: debian-builder (updated package)

[Deepak Tripathi]

Hi Neil,

Yes you are absolutely right that how many Debain should handle it. As
per my knowledge  i have good understanding of debian build process
that is why i have adopted this package.
Yes i do understand that maintaining an build packages is much harder
then other and i have tried to start that because i want to do.

I have knowledge of other packages like apt ,quilt which you were
taking about But my main purpose of to take a package in always good
shape.

I really do understand that your Debian System knowledge will be much
better then mine  and if you think that there are good build packages
are available and we don't need this  .I will go ahead then raise a
request for removing from Debian .(or if you want you can raise it ).

Need mode guidance to learn from mentors.
kind to see your mail soon.


Thanks
Deepak Tripathi



On 2/10/08, Neil Williams <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-02-10 at 02:35 +0530, Deepak Tripathi wrote:
> > On Feb 9, 2008 11:58 PM, Neil Williams <[EMAIL PROTECTED]> wrote:
> > On Sat, 09 Feb 2008 15:26:48 +0530
> > Deepak Tripathi <[EMAIL PROTECTED]> wrote:
> >
> > > Dear mentors,
> > >
> > > I am looking for a sponsor for the new version 1.8
> > > of my package "debian-builder".
> > >
> > > It builds these binary packages:
> > > debian-builder - Rebuild Debian packages from source code
> >
> >
> > Why is this worth having in Debian? (What's wrong with apt-get
> > -b or
> > the half-dozen other ways of building a source package?)
> > Hi ,
> > Nothing is wrong with apt-get -b "BUT"   It is not designed to enhance
> > your installation
> >  by producing optimized binaries, however this may be achieved  with
> > the aid of companion packages such as 'pentium-builder' or
> > 'athlon-builder'.
> >  The prime purpose of this package is to ease the testing of  compiler
> > patches such as the Stack Smashing Protection patch  available from
> > IBM.
>
> Please post the long description - this sounds like a very specialised
> package that should indicate this in the description if not in the
> package name.
>
> debian-builder appears to be far too generic - there would be no reason
> to rebuild more than a few packages with such a tool IMHO.
>
> >
> > How many more (vanity) build systems must we have
> > there are many and besically it depends how the community uses them,.
>
> No, it is how many Debian should support. There is a great deal of
> controversy about build systems right now and you have not yet given any
> convincing evidence of why this one should be added.
>
> The problem with all build systems is that they start out as "useful for
> a few problems" but soon they are adopted for packages outside that
> remit which then depend on them and from which maintainers do not want
> to move.
>
> What is the role for this package with regard to packages to be uploaded
> to Debian? What differences does your build system introduce that would
> cause the binaries to differ from those inspected by the security team?
> Why not simply use quilt or some other patch system and an existing
> build tool - script it in shell if necessary.
>
> Are you aware of the issues with introducing a new build tool? What are
> your answers for the problems currently being discussed in Debian around
> such build tools, patch systems and source package changes with regard
> to your package?
>
> A build tool is not an ordinary package. You need to work a lot harder
> (now and forever more) to show that you can maintain this package "in
> the round" and improve it to meet future changes as-yet-unknown.
>
> I'd be surprised if this is achievable without being part of the
> upstream team for this package.
>
> --
>
>
> Neil Williams
> =
> http://www.data-freedom.org/
> http://www.nosoftwarepatents.com/
> http://www.linux.codehelp.co.uk/
>
>
>


-- 
Deepak Tripathi
E3 71V3 8Y C063 (We Live By Code)
http://deepkatripathi.blogspot.com


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

RFS: yale (updated package)

[Francisco García]

Dear mentors,

I am looking for a sponsor for the new version 1.0-13
of my package "yale".

It builds these binary packages:
yale   - Stellar data set from the Yale Bright Star Catalog

Long Description:
 These data come from the [Yale] Bright Star Catalog, 5th Rev. Ed.
 (preliminary), Hoffleit and Warren, 1991. It contains all
 the stars with apparent magnitude brighter than +6.5.  
 .
 This stellar data set may viewed with the StarPlot program available from
 Debian, but can be used with other astronomical software.


The package appears to be lintian clean.

The upload would fix these bugs: 464434

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/non-free/y/yale
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/non-free/y/yale/yale_1.0-13.dsc

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

Kind regards
 Francisco Manuel Garcia Claramonte


-- 
Francisco M. García Claramonte <[EMAIL PROTECTED]>
GPG: public key ID 556ABA51


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Re: Long descriptions in RFS emails.

[Richard Hecker]

Ben Finney wrote:

Neil Williams <[EMAIL PROTECTED]> writes:

  

On Mon, 2008-02-11 at 08:37 +1100, Ben Finney wrote:


A good policy except that I'd recommend you respond to at least
some of them to say *why* you think they're worth ignoring.
  

Those who take some time over the preparation of packages and show
some level of effort in at least applying the principles of the FAQ
deserve my support and as I have limited time, I therefore choose to
prioritise my support to those who take the time to do the work.



A reasonable position. Well, thanks for making your policies available
for reference by others, and for keeping them up to date.

  

And while Ben has a good point, I think there will be others who
respond to some of these newcomers.  I appreciate the policy
Neil has espoused and will likely point out to others that a
lurker like me expects them to consider it.  I do not sponsor
many packages, but before I seriously take a look at one I use
these 'best practices' from my fellow developers as a guideline.
Hopefully the newcomers will remember that there is no obligation
to become a sponsor and therefore it is in their best interest to
do the homework that makes it easier to look at their package.

Richard


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

Re: RFC: Howto exclude config.sub and config.guess updates from .diff.gz

[David Paleino]

Il giorno Mon, 11 Feb 2008 17:36:03 +0100
Cyril Brulebois <[EMAIL PROTECTED]> ha scritto:

> On 11/02/2008, David Paleino wrote:
> > Not true:
> > [Snip unrelated logic stuff.]

I can't understand how what I wrote is "unrelated", but let's go on.

> [..]
> 
> Now, moving that to a Makefile:
> ,
> | #!/usr/bin/make -f
> |
> | and:
> | [ ! -f foo ] && echo "Doing bar 1"
> | [ -f foo ]   && echo "Doing bar 2"
> |
> | or:
> | [ ! ! -f foo ] || echo "Doing bar 1"
> | [ ! -f foo  ]  || echo "Doing bar 2"
> `
> 
> You now get:
> ,
> | [EMAIL PROTECTED]:~$ make or
> | [ ! ! -f foo ] || echo "Doing bar 1"
> | Doing bar 1
> | [ ! -f foo  ]  || echo "Doing bar 2"
> | [EMAIL PROTECTED]:~$ make and
> | [ ! -f foo ] && echo "Doing bar 1"
> | Doing bar 1
> | [ -f foo ]   && echo "Doing bar 2"
> | make: *** [and] Erreur 1
> `

Thank you.

> > but I can't understand why it couldn't suggest something like:
> >
> > [ -f Makefile ] && $(MAKE) distclean
> >
> > which triggers the same result (at least in bash -- that's why I'm
> > supposing that "&&" needs to be escaped somehow in Makefiles).
> 
> Explained already in my first mail, and in extenso by Justin.

I couldn't get your explanation before, thanks to Justin for extending it.

Thanks,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Bas Wijnen]

On Mon, Feb 11, 2008 at 03:19:36PM -0800, Russ Allbery wrote:
> Bas Wijnen <[EMAIL PROTECTED]> writes:
> > On Mon, Feb 11, 2008 at 09:21:29AM -0800, Russ Allbery wrote:
> 
> >> Always re-running autoconf and automake would increase the number of
> >> FTBFS's that we'd need to fix.
> 
> > Not really.
> 
> No, really, I promise it will.  :)  Each time we upgrade autoconf, it will
> break a bunch of packages that were doing things that weren't supported.

Ah, that is a point.  But that should not be the case if the packages
build-depend on the right version, or is it still a problem?  I know
automake in particular changes a lot between versions, but that's why I
always build-depend on a version (such as "automake1.10").  That's
recommended as well AFAIK.  So the problem of removing old versions of
automake (such as automake1.8 at the moment) gets bigger, but it
shouldn't make it FTBFS bugs most of the time.

> > Yes, IMO it's one of those situations where Debian should do what's
> > Right, not what's Easy (similar to what I wrote about the /bin/sh
> > bash->dash move on -policy today).
> 
> I am generally in favor of that, but I also don't have the free time to
> volunteer for the release team, who ends up bearing the brunt of us doing
> the right thing in this area, so, y'know, easy for me to say.  :)

I'm happy to report bugs and provide patches for many packages if that
helps doing this properly.

> > That's in principle a problem for the maintainer to solve, and
> > secundarily for lintian.
> 
> Well, yeah, but it would still be nice to provide some help.

Sure. :-)

Thanks,
Bas

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

RFC: Exclude config.sub and config.guess from

[Daniel Leidert]

Am Montag, den 11.02.2008, 14:45 +0100 schrieb David Paleino:
> Il giorno Mon, 11 Feb 2008 14:17:54 +0100
> Daniel Leidert <[EMAIL PROTECTED]> ha scritto:
> 
> > We simply copy config.sub and config.guess into the build directory for
> > some years now and I never observed any problem with this.
> > 
> > I'm really wondering why you want to make the situation complicated?
> 
> And if the config.{sub,guess} copied are different from those provided
> upstream, isn't this difference going to pollute the .diff.gz? I'd like to 
> take
> the .diff.gz the most clean possible; i.e. only keep debian/ in it.

I fully agree. But you already have a possibility to achieve this:

Copy the config.* scripts after the clean target has been called (e.g.
in the config.status target) then they are simply not part of the
diff.gz. Of course they would be after a second build run. If you care
and if you want to avoid this: preserve the original config.* scripts
and put them back in the clean-target. This increases the whole
debian/rules file for around 4 lines.

This *is* much more easier than any other suggestion I read in this
thread.

A possible alternative could be to exclude config.sub and config.guess
creating the .diff(.gz). But this can lead to problems, if you patched
one of these files. IIRC I saw this during the introduction of
kfreebsd-i386, but I'm not sure.

Regards, Daniel


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

Re: Lintian: outdated-autotools-helper-file

[Daniel Leidert]

Am Montag, den 11.02.2008, 10:54 +0100 schrieb David Paleino:
> Il giorno Mon, 11 Feb 2008 10:53:48 +0100
> Bas Wijnen <[EMAIL PROTECTED]> ha scritto:
> 
> > I suggest to mandate "remove all generated files in the clean target"
> > (formulated in a way which includes "generated by upstream", not only
> > "generated by the build target), which implies "rebuild everything in
> > the build target".
> 
> I fully agree with you here: the build target should also build Makefile.in
> from Makefile.am, for example. Thus we clean *.in, *.sub, *.guess, in the 
> clean
> target.

The files you mention belong to the maintainer-clean target. To remove
them in the debian/rules clean target you would often have to repackage
the source tarball, which often includes patching, because many
autotools-based build environments do not fully implement
maintainer-clean. Otherwise you would need to duplicate maintainer-clean
in the debian/rules clean target (good luck with large source archives,
maybe including even sub-projects!). You further need to build depend on
the whole autotools chain + additional tools like gnome-doc-utils or
intltool or 

We simply copy config.sub and config.guess into the build directory for
some years now and I never observed any problem with this.

I'm really wondering why you want to make the situation complicated?

> And, as a sidenote, I've just faced this. I patched a Makefile.am, and wasn't
> seeing any result.

This project very probably used the AM_MAINTAINER_MODE macro. Enable the
maintainer-mode with --enable-maintainer-mode.

> I also had to patch Makefile.in. That's non-sense to me.

Why do you patch Makefile.am? It just makes sense, when you manipulate
or change macros (e.g. make libraries convenience libraries). If you
just change a path or if you want to remove a binary from
installation ... then simply patch Makefile.in directly. There is often
no reason to patch Makefile.am.

Regards, Daniel


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

Re: RFS: QA Upload -- mma - Musical Midi Accompaniment generator

[Margarita Manterola]

On Feb 10, 2008 11:57 PM, Barry deFreese <[EMAIL PROTECTED]> wrote:

> Just an upload to set QA to maintainer and bring standards, et al up to
> date.  Package should really probably be removed but we can see if
> someone adopts it first I suppose.
>
> http://mentors.debian.net/debian/pool/main/m/mma/mma_0.12-2.dsc
>
>  MMA creates midi tracks for a soloist to perform over from a user
>  supplied file containing chords and MMA directives.

Sponsored.

-- 
Besos,
Marga


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

Re: Lintian: outdated-autotools-helper-file

[Bas Wijnen]

On Mon, Feb 11, 2008 at 05:40:58PM +0530, Kapil Hari Paranjape wrote:
> On Mon, 11 Feb 2008, Bas Wijnen wrote:
> > I suggest to mandate "remove all generated files in the clean target"
> > (formulated in a way which includes "generated by upstream", not only
> > "generated by the build target), which implies "rebuild everything in
> > the build target".
>
> It is a good idea if one can use .orig.tar.gz to be the same as the
> upstream .tar.gz whenever it is DFSG-free to do so.

Yes, I agree with that, but it seems unrelated.

> Note that if the upstream's auto-generated files are deleted during
> the clean target, then the source *must* be re-packaged to avoid
> needless clutter in the .diff.gz which is of a "negative" nature.

Not at all.  Firstly, policy only allows repackaging of the upstream
tarball when really needed (to remove non-free contents, or because it's
not in .tar.gz format), and even when you do it, you must not make more
changes than really needed.  It is unacceptable to repackage just to
avoid cluttering the diff.gz, or even to avoid it by making changes to
an already (for good reasons) repackaged tarball.

Secondly, when the clean target removes all generated files, they are
ignored when generating the diff.gz, so it doesn't actually clutter it.
It does produce some warnings during make clean, but those are not a
problem IMO.

Thanks,
Bas

-- 
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: Lintian: outdated-autotools-helper-file

[Kapil Hari Paranjape]

On Mon, 11 Feb 2008, Bas Wijnen wrote:
> I suggest to mandate "remove all generated files in the clean target"
> (formulated in a way which includes "generated by upstream", not only
> "generated by the build target), which implies "rebuild everything in
> the build target".
> 
> With the current wording it is allowed to use shipped built files from
> the upstream tarball, as long as the source is present.  It is even
> allowed to ship the build results (uuencoded, for example) in the
> diff.gz and use those.  I suppose we all agree that this is unacceptable
> for normal build results.
> 
> Now reread the previous paragraph while thinking of Makefile.in instead
> of "normal build results".  It is common practice to do exactly that:
> ship and use pre-built versions, or even ship them in the diff.gz (which
> then gets huge).  Makefile.am is only present as source-file, but it
> isn't used at all during the build.  Any changes the user makes will not
> be noticed by the build system.
> 
> I'd like to hear why this exception is so important for people.  Or
> better yet, I'd like to hear that everyone agrees with me, so we can
> make this change and finally to the Right Thing. :-)

It is a good idea if one can use .orig.tar.gz to be the same as the
upstream .tar.gz whenever it is DFSG-free to do so.

One reason is that it becomes easier to verify that the .orig.tar.gz
is the same --- has the same GPG signature, MD5SUM etc.

Another reason (which is the same reason in disguise!) is that it is
easier to see exactly what Debian is changing in the upstream source.

Note that if the upstream's auto-generated files are deleted during
the clean target, then the source *must* be re-packaged to avoid
needless clutter in the .diff.gz which is of a "negative" nature.

So all such source must come with a "get-orig-source" target and a
README.Debian-source which explains the changes made.

Regards,

Kapil.
--


signature.asc
Description: Digital signature

Re: RFS: python-twitter

[Mauro Lizaur]

On Feb 11, 2008 8:11 PM, Piotr Ożarowski <[EMAIL PROTECTED]> wrote:
> Hi Mauro,
>
> I've changed your package a little bit (fixed lintian error, etc., see
> attachment).
>
> Please take a look and disagree if you don't like my changes.
>
> [Mauro Lizaur, 11.02.2008]
> > Btw, i added a few lines to install the examples in /usr/bin (one of
> > them is a mini client)
>
> manpages are missing
> (lintian warns about it, please check `lintian -i package.changes` output)
>

Hi Piotr,
i've just uploaded python-twitter to mentors again[0], i applied all
the changes file, and added the manpages, i build a package and tested
it using pbuilder and everything went ok.
Though i saw a couple of things that may be are a bad thing:
- I got this 'linda' warning:
W: python-twitter; 3.7.3 is a newer Standards-Version.
but the value on the Standards-Version field in the debian/control is 3.7.3

- When i built the package using -S -sa i got a 'lintian' warning
about not having a Description field on the .changes file(which is
true), but when i built this very same package not using pbuilder i
got no warnings and the Description field appears on the .changes
file.

- And last but not least, may be both manpages could be improved a
little bit more, i'll wait for your opinion about them.

[0] 
http://mentors.debian.net/debian/pool/main/p/python-twitter/python-twitter_0.5-1.dsc

Thanks,
Mauro
-- 
BEGIN GEEK CODE BLOCK
Version: 3.12
GCM/O d->dpu$ s-:- a-->a+++$ C+++
LU P+ L++ E W+++ N !o K w O !M !V
PS+ PE Y+ PGP t 5– X R tv++ b- DI D++ G+ e
h!>h-- r>r+++ y+
END GEEK CODE BLOCK

RFS: gliese (updated package)

[Francisco García]

Dear mentors,

I am looking for a sponsor for the new version 1.1-14
of my package "gliese".

It builds these binary packages:
gliese - Stellar data set from the Third Catalogue of Nearby Stars

Long Description:
 This package provides a star catalog which contains approximately
 3800 star records including the known stars nearer to Earth than 
 approximately 80 light-years, taken from the Third Catalogue of Nearby
 Stars (preliminary edition), Gliese and Jahreiss, 1991.
 .
 This stellar data set may be viewed with the StarPlot program available
 from Debian, but can be used with other astronomical software.



The package appears to be lintian clean.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/non-free/g/gliese
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/non-free/g/gliese/gliese_1.1-14.dsc

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

Kind regards
 Francisco Manuel Garcia Claramonte


-- 
Francisco M. García Claramonte <[EMAIL PROTECTED]>
GPG: public key ID 556ABA51


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Re: RFC: Exclude config.sub and config.guess from

[Bernhard R. Link]

* Daniel Leidert <[EMAIL PROTECTED]> [080211 15:21]:
> If you care
> and if you want to avoid this: preserve the original config.* scripts
> and put them back in the clean-target. This increases the whole
> debian/rules file for around 4 lines.

much easier: just delete in the clean target and put there at the
beginning of the configuring target.

Hochachtungsvoll,
Bernhard R. Link


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

Re: Lintian: outdated-autotools-helper-file

[Bas Wijnen]

On Mon, Feb 11, 2008 at 02:17:54PM +0100, Daniel Leidert wrote:
> Am Montag, den 11.02.2008, 10:54 +0100 schrieb David Paleino:
> > Il giorno Mon, 11 Feb 2008 10:53:48 +0100
> > Bas Wijnen <[EMAIL PROTECTED]> ha scritto:
> > 
> > > I suggest to mandate "remove all generated files in the clean target"
> > > (formulated in a way which includes "generated by upstream", not only
> > > "generated by the build target), which implies "rebuild everything in
> > > the build target".
> > 
> > I fully agree with you here: the build target should also build Makefile.in
> > from Makefile.am, for example. Thus we clean *.in, *.sub, *.guess, in the 
> > clean
> > target.
> 
> The files you mention belong to the maintainer-clean target.

Most of them, yes.  In my Makefile.ams I have an "autoclean" target,
which really removes everything.  Some things are installed by autotools
with the intention that you turn them into source files (INSTALL for
example).  I want those removed as well, because they aren't source
files on my system.

> To remove them in the debian/rules clean target you would often have
> to repackage the source tarball,

What gave you that idea?  What sort of change do you expect to need that
can't be done in the diff.gz?

> which often includes patching, because many autotools-based build
> environments do not fully implement maintainer-clean.

Except for packages where I am upstream, I don't think I know any
packages which have a proper autoclean target.  Indeed, in such a case
Debian should do it by itself.  Not that it's very hard.  It's simply a
matter of:

AUTOJUNK = list of files to potentially remove
ifneq ($(wildcard ${AUTOJUNK},))
rm -r $(wildcard ${AUTOJUNK},)
endif

Or, if you're lazy, you can just use rm -rf.  I prefer this method,
because -f hides more errors than just "file doesn't exist".

> Otherwise you would need to duplicate maintainer-clean in the
> debian/rules clean target (good luck with large source archives, maybe
> including even sub-projects!).

Your package plus its build-depends must contain the full source of
whatever is built.  The source of every single generated file _must_
already be in your package anyway.  If you can give an example of a
package which would need extra source files to build everything in it,
then please file a bug against it.

> You further need to build depend on the whole autotools chain +
> additional tools like gnome-doc-utils or intltool or 

Not a big problem, and also very reasonable: if someone wants to build
this package from source, she does indeed need all those packages.  If
a user wants to make changes to the source, those packages are needed
anyway to get those changes reflected in the package.

As a good example you can have a look at gnujump.  I could have just
called configure and make.  But I decided to run autotools during build.
I found that it needed autoconf-archive, plus an argument to the
autoconf invocation, to make it compile.  If I would not have
regenerated configure during the build process, it would have been
easier for me.  But when users would try to build the package from real
source, they would find that they couldn't.  And they would need to find
out why.  I think it is a Good Thing(tm) if Debian's build scripts can
be used as documentation for how a package can be built from source.

> We simply copy config.sub and config.guess into the build directory for
> some years now and I never observed any problem with this.

The mail you replied to was about such a problem, you even quoted it.  I
just told you about a problem with gnujump.  The whole reason we're
having this discussion is because there are problems with the current
approaches.

You are saying "Building from source means we need dependencies, and you
have to figure out how to build the program, and there are lots of
problems in general.  Let's just use pre-built files instead."

This is of course entirely true.  It is also true for every other
generated file.  Why not pre-compile bash, put it in the diff.gz
uuencoded, and let debian/rules just uudecode it?  It makes things much
easier, you don't get nasty build failures, and you don't need many
build-dependencies.

Let's for the moment ignore the architecture-specific problems of that
approach.  I hope you agree with me that it still isn't an acceptable
way to package bash?  Why do you want to allow it for
autotools-generated files?

> I'm really wondering why you want to make the situation complicated?

The "complication" that I'm adding is that I want to build things from
source.  AFAIK that is something everyone agrees on as a Good Thing.
Only for some reason there is an exception for autotools.

> > And, as a sidenote, I've just faced this. I patched a Makefile.am,
> > and wasn't seeing any result.
> 
> This project very probably used the AM_MAINTAINER_MODE macro. Enable the
> maintainer-mode with --enable-maintainer-mode.

You can't easily do that when using the Debian build system.  And using

RFS: vamp-plugin-sdk -- audio analysis and feature extraction plugins

[Székelyi Szabolcs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear mentors,

I am looking for a sponsor for my package "vamp-plugin-sdk".

* Package name: vamp-plugin-sdk
  Version : 1.1b-1
  Upstream Author : Chris Cannam <[EMAIL PROTECTED]>
* URL : http://www.vamp-plugins.org/
* License : BSD
  Section : sound

Vamp is an audio processing plugin system for plugins that extract
descriptive information from audio data - typically referred to as audio
analysis plugins or audio feature extraction plugins.

Just like an audio effects plugin (such as a VST), a Vamp plugin is a
binary module that can be loaded up by a host application and fed audio
data. However, unlike an effects plugin, a Vamp plugin outputs not
processed audio but some sort of symbolic information. Typical things
that a Vamp plugin might calculate include the locations of moments such
as note onset times, visual representations of the audio such as
histograms, or curve data such as power or fundamental frequency.

Hosts using Vamp plugins include Audacity and Sonic Visualiser.

Although this package is not very useful by itself, I have a packaged
Sonic Visualiser ready for upload, which Build-Depends on
vamp-plugin-sdk, so Vamp has to make it through before I can send RFS
for it.

It builds these binary packages:
libvamp-hostsdk2 - helper library for Vamp hosts written in C++
libvamp-sdk1 - helper library for Vamp plugins written in C++
vamp-examples - example Vamp plugins and host
vamp-plugin-sdk - audio analysis and feature extraction plugins (SDK)

The package appears to be lintian and pbuilder clean.

The upload would fix these bugs: 463754

The package can be found on mentors.debian.net:
- - URL: http://mentors.debian.net/debian/pool/main/v/vamp-plugin-sdk
- - Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- - dget
http://mentors.debian.net/debian/pool/main/v/vamp-plugin-sdk/vamp-plugin-sdk_1.1b-1.dsc

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

Kind regards,
- --
cc

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

iD8DBQFHsOEsGJRwVVqzMkMRAkxyAJ4kawwdx549dQkQGVKdJxaTUjgVDACfbyy5
9KhGTwbYfM08vWmOB/laSq0=
=BQzp
-END PGP SIGNATURE-


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

Re: Lintian: outdated-autotools-helper-file

[Kapil Hari Paranjape]

Hello,

On Mon, 11 Feb 2008, Bas Wijnen wrote:
> Secondly, when the clean target removes all generated files, they are
> ignored when generating the diff.gz, so it doesn't actually clutter it.
> It does produce some warnings during make clean, but those are not a
> problem IMO.

Oops. I'd forgotten this aspect --- "files which have been
deleted from the .orig.tar.gz do not show up in .diff.gz"

So my "reason" for running a "proper" clean is not valid and
objection is withdrawn!

Regards,

Kapil.
--



signature.asc
Description: Digital signature

Re: Copyright question (BSD with advertisement clause)

[Charles Plessy]

Le Sat, Feb 09, 2008 at 01:26:55PM -0500, Joey Hess a écrit :
> Riku Voipio wrote:
> > I think the short term solution to this dilemma is to compile a list
> > of attributions needed to be included in advertizment material.
> > Also a list should be compiled attributions needed n documentation
> > (such as libjpeg's). Obviously most distributors/boob writers will
> > not notice such lists, but that's a different problem...
> 
> Most writers don't have to worry about it, it's not as if we advertise
> Debian as "Debian.. now with Thomas G. Lane's JPEG support and OpenSSL".
> The advertisement clause tries to not allow those specific attributions
> to be used in advertisements; it does NOT require that advertisements
> contain any specific list of citations.

Actually, this is true for libjpeg and false for openssl and other
programs using similar BSD-related clauses.

libjpeg:
 Permission is NOT granted for the use of any IJG author's name or
 company name in advertising or publicity relating to this software or
 products derived from it.  This software may be referred to only as
 "the Independent JPEG Group's software".

openssl:
 All advertising materials mentioning features or use of this
 software must display the following acknowledgment: "This product
 includes software developed by the OpenSSL Project for use in the
 OpenSSL Toolkit. (http://www.openssl.org/)"

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


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

Re: Lintian: outdated-autotools-helper-file

[Bas Wijnen]

On Sun, Feb 10, 2008 at 03:48:20PM -0800, Russ Allbery wrote:
> Raphael Geissert <[EMAIL PROTECTED]> writes:
> 
> > Quoting the Debian Policy, section 4.9 Main building script:
> > debian/rules[1]
> >
> >> clean
> >> 
> >> This must undo any effects that the build and binary targets may
> >> have had, except that it should leave alone any output files
> >> created in the parent directory by a run of a binary target.  
> >
> > So according to the policy the clean target must put the original
> > files back on place.
> 
> This Policy dictate as written is pretty widely ignored and (IMO) is
> somewhat hard to defend in several of its implications.  We haven't
> figured out what to say instead, but deleting the files is fairly
> common right now.
> 
> See http://bugs.debian.org/397939 for some additional discussion.

Thank you for this link.  I would like to add a suggestion as a
solution.  IMO the important thing is, as stated by Bill, that "clean"
and "clean; binary; clean" should result in the same tree.  From the log
it seems that people agree that this implies either creating a huge
diff.gz, or running autotools in the clean target.

This is not true if you simply build the whole package from source.
That is, run autotools during build, remove all generated files,
including Makefile.in, configure, etc, in the clean target.

For some reason many people seem to think that the whole package must be
built from source, except for configure and Makefile.in.  I still don't
understand what the idea behind this exception is.  Especially when it
leads to unwanted concequences (unreadable diff.gzs, for example), I
don't think it is a good idea to hold on to the idea that running
autotools is not part of building the package.

Apart from that, this discussion is about users making changes to the
source and compiling a package with those changes in it.  When not
running autotools during build, that doesn't work if the user changes
Makefile.am or configure.ac.  Yet another undesirable effect of this
strange exception to "build everything from source".

I suggest to mandate "remove all generated files in the clean target"
(formulated in a way which includes "generated by upstream", not only
"generated by the build target), which implies "rebuild everything in
the build target".

With the current wording it is allowed to use shipped built files from
the upstream tarball, as long as the source is present.  It is even
allowed to ship the build results (uuencoded, for example) in the
diff.gz and use those.  I suppose we all agree that this is unacceptable
for normal build results.

Now reread the previous paragraph while thinking of Makefile.in instead
of "normal build results".  It is common practice to do exactly that:
ship and use pre-built versions, or even ship them in the diff.gz (which
then gets huge).  Makefile.am is only present as source-file, but it
isn't used at all during the build.  Any changes the user makes will not
be noticed by the build system.

I'd like to hear why this exception is so important for people.  Or
better yet, I'd like to hear that everyone agrees with me, so we can
make this change and finally to the Right Thing. :-)

Thanks,
Bas

-- 
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: RFC: Howto exclude config.sub and config.guess updates from .diff.gz

[Daniel Leidert]

Sorry, I broke the subject with my last post. I wanted to adjust it, but
forgot finish the subject line. Really sorry.

Regards, Daniel


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

Re: Long descriptions in RFS emails.

[Neil Williams]

On Sun, 2008-02-10 at 23:25 -0500, Andres Mejia wrote:
> On Sunday 10 February 2008 10:13:50 am Neil Williams wrote:
> > Just a note for everyone - I will now ignore any RFS that does not
> > include the long description for the package.
> >
> > It doesn't matter how many times you "ping", without a long description
> > posted to *this* list, I will no longer waste time either asking for one
> > or reviewing your package and your RFS is likely to be deleted without
> > any further action.
> >
> > http://people.debian.org/~codehelp/#sponsor
> 
> I actually thought anything that's not part of the template would be 
> considered cruft, thus I avoided adding anything extra to any RFS I sent.

This is from my own sponsoring page and directly quotes the FAQ:

> Note, this section from the Debian Mentors FAQ:
> 
> Your message to -mentors is like an ad for your package. It's likely 
> to be the only thing that prospective sponsors will judge your package on. 
> You can have all the extra URLs you like in there where sponsors can get more 
> information, but unless your initial message piques their interest, they'll 
> never look at them.
> 
> So, tell us what exactly your package does, and why it should be in 
> Debian. 
> If there is already a program that does a similar thing, say why your one is 
> better. Put a little "hot spice" in there to hold people's interest. in other 
> words, think like an advertising executive. Just remember to wash the 
> slime off afterward. " 

I don't see why anyone would read that and think that an *advert* would
be deemed appealing if it contained nothing but the location, price and
name of the product.

Ad agencies spend billions on background, context and other information
to make the raw data more appealing.

Are you an automaton or a potential maintainer?

Can you be more than just a "join-the-dots" script bot???

Recent RFS emails could easily have been created with a trivial shell
script and I find that insulting.

The FAQ tells maintainers to add to the template - why is it the fault
of the template when the maintainer ignores that instruction?

> Perhaps it's best to include where the description and other information 
> should go. I'm thinking something like: 

No. It simply means that potential maintainers must show evidence that
they can think for themselves and do more than just slavishly follow a
template.

I'd hate to think what kind of bug reports would result from the
attitude that templates are sufficient without any comment.


-- 

Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



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

Re: Help with watch file -- pre-release upstream versions

[Daniel Leidert]

Am Montag, den 11.02.2008, 02:23 +0100 schrieb Székelyi Szabolcs:

> What's the usual way of handling "preX" upstream version numbers in
> watch files? I'm having trouble because uscan considers 1.0pre3 newer
> than 1.0.

IMO you have two options:

1) Ignore the pre-versions by a rule like

http://domain.tld/foobar-([\d.]+)\.tar\.gz

if you are not going to package pre-releases. This will exclude all
versions including a "pre" term after the version number.

2) Use a uversionsmnagle:

opts=uversinmangle=s/pre/~pre/ \
  http://domain.tld/foobar-(.+)\.tar\.gz

Regards, Daniel

Re: Lintian: outdated-autotools-helper-file

[David Paleino]

Il giorno Mon, 11 Feb 2008 10:53:48 +0100
Bas Wijnen <[EMAIL PROTECTED]> ha scritto:

> I suggest to mandate "remove all generated files in the clean target"
> (formulated in a way which includes "generated by upstream", not only
> "generated by the build target), which implies "rebuild everything in
> the build target".

I fully agree with you here: the build target should also build Makefile.in
from Makefile.am, for example. Thus we clean *.in, *.sub, *.guess, in the clean
target.

> Now reread the previous paragraph while thinking of Makefile.in instead
> of "normal build results".  It is common practice to do exactly that:
> ship and use pre-built versions, or even ship them in the diff.gz (which
> then gets huge).  Makefile.am is only present as source-file, but it
> isn't used at all during the build.  Any changes the user makes will not
> be noticed by the build system.

See what I wrote just above :)

And, as a sidenote, I've just faced this. I patched a Makefile.am, and wasn't
seeing any result. I also had to patch Makefile.in. That's non-sense to me.

Kindly,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: RFC: Exclude config.sub and config.guess from

[David Paleino]

Il giorno Mon, 11 Feb 2008 15:19:08 +0100
Daniel Leidert <[EMAIL PROTECTED]> ha scritto:

> Copy the config.* scripts after the clean target has been called (e.g.
> in the config.status target) then they are simply not part of the
> diff.gz. Of course they would be after a second build run. If you care
> and if you want to avoid this: preserve the original config.* scripts
> and put them back in the clean-target. This increases the whole
> debian/rules file for around 4 lines.
> 
> This *is* much more easier than any other suggestion I read in this
> thread.

Well, I tried to do that in one of my packages:

---8<---
configure:
[ ! -f $(CURDIR)/config.sub ] || \
mv $(CURDIR)/config.sub $(CURDIR)/config.sub.backup
[ ! -f $(CURDIR)/config.guess ] || \
mv $(CURDIR)/config.guess $(CURDIR)/config.guess.backup
[ ! -r /usr/share/misc/config.sub ] || \
cp /usr/share/misc/config.sub $(CURDIR)/
[ ! -r /usr/share/misc/config.guess ] || \
cp /usr/share/misc/config.guess $(CURDIR)/

./configure --host=...

...

clean:
dh_testdir
...
[ ! -f $(CURDIR)/config.sub.backup ] || \
mv $(CURDIR)/config.sub.backup $(CURDIR)/config.sub
[ ! -f $(CURDIR)/config.guess.backup ] || \
mv $(CURDIR)/config.guess.backup $(CURDIR)/config.guess
--->8---

This seems to me more hackish than it should; is there a cleaner way to do it
(maybe I'm just complicating myself and don't see The Easy Way [1])?


Cheers,
David

[1] I know that using "[ ! test ] || ..." is pretty awkward, but it didn't work
with "[ test ] &&". Maybe "&&" should be escaped somehow? I don't really know.

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: RFS: python-twitter

[Mauro Lizaur]

On Feb 11, 2008 8:11 PM, Piotr Ożarowski <[EMAIL PROTECTED]> wrote:
> Hi Mauro,
>
> I've changed your package a little bit (fixed lintian error, etc., see
> attachment).
>
> Please take a look and disagree if you don't like my changes.
>
> [Mauro Lizaur, 11.02.2008]
> > Btw, i added a few lines to install the examples in /usr/bin (one of
> > them is a mini client)
>
> manpages are missing
> (lintian warns about it, please check `lintian -i package.changes` output)
>

Hi Piotr,
may i ask which was the lintian error? i executed lintan -i -I and it
was clean :/
All the changes you made are fine for me, there are only two thing
that i would change:
- the url in the homepage field, shouldn't be there the project url?
- instead of using 'cp' to install the examples, i'll use 'install -m 755'
I totally forgot about the manpages of the examples script, i'll add
them now (actually, by the time you'll be reading this both manpages
will be added)

Thank a lot,
Mauro

-- 
BEGIN GEEK CODE BLOCK
Version: 3.12
GCM/O d->dpu$ s-:- a-->a+++$ C+++
LU P+ L++ E W+++ N !o K w O !M !V
PS+ PE Y+ PGP t 5– X R tv++ b- DI D++ G+ e
h!>h-- r>r+++ y+
END GEEK CODE BLOCK