Re: RFS: uncrustify (updated package) (second try)
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)
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)
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
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/package 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
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]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397939: Lintian: outdated-autotools-helper-file
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
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
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
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)
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
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
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
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
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]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian: outdated-autotools-helper-file
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
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
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
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
-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)
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)
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)
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.
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
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
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
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
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
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
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
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
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-- rr+++ y+ END GEEK CODE BLOCK
RFS: gliese (updated package)
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
* 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
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
the Debian build system certaily should be an acceptable way of
RFS: vamp-plugin-sdk -- audio analysis and feature extraction plugins
-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
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)
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
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
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.
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
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
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
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
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-- rr+++ y+ END GEEK CODE BLOCK
