Re: Long descriptions in RFS emails.
On 11/02/2008, Andres Mejia wrote: Perhaps it's best to include where the description and other information should go. I'm thinking something like: […] The package appears to be lintian clean. I'd like not to see this in a template anymore. And rather a “State of the package with the latest lintian version available (in unstable):”, reminding people that this is not just a sentence to copy over, and that one has to actually run lintian… The upload would fix these bugs: XX . . . Maybe suggesting to include a description and/or the severity of the bugs might help spot “important” uploads. http://mentors.debian.net/debian/pool/main/p/package/package_version.dsc That URL is IMHO very sufficient. Reason: This is a new upstream. It fixes a security issue that allowed this and that. etc. . . . That might be a nice summary instead of just a list of bugs, titles, severities as I proposed above, but the idea is just the same. Cheers, -- Cyril Brulebois pgpCX1ODeUXnL.pgp Description: PGP signature
RFS: ustr (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.0.3-2 of my package ustr. It builds these binary packages: libustr-1.0-1 - Micro string library: shared library libustr-1.0-1-dbg - Micro string library: debugging symbols libustr-dev - Micro string library: development stuff libustr-doc - Micro string library: documentation Description: ustr (Micro string library) is a string API for C. It has tiny overhead over just plain strdup(), is much safer, is easier to use, is faster for many operations, can be used with read-only or automatically allocated data. You don't even need to link to the library to use it (so there are no dependencies). Upstream author: James Antill Homepage: http://www.and.org/ustr/ This library is the requisite for latest libsemanage, the library of the SELinux code suite. Ustr is packaged using CDBS. Package was rebuild using pbuilder. Lintian v1.23.43 on ustr_1.0.3-2_i386.changes reports nothing. Vcs-Browser: http://git.debian.org/?p=users/zito-guest/pkg-ustr.git Vcs-Git: git://git.debian.org/~zito-guest/pkg-ustr.git The upload would fix an important bug 465005 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465005 - bashism in the utility script ustr-import. It also cleans manpages a bit. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/u/ustr - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/u/ustr/ustr_1.0.3-2.dsc I would be glad if someone uploaded this package for me. Kind regards -- Václav Ovsík (Zito) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: falconpl package (ITP:Bug#460591); source package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I have uploaded the package as currently proposed and accepted in Ubuntu, debianized where relevant. The source is at: http://www.falconpl.org/downloads/0.8.8/falconpl_0.8.8-1.diff.gz http://www.falconpl.org/downloads/0.8.8/falconpl_0.8.8-1.dsc http://www.falconpl.org/downloads/0.8.8/falconpl_0.8.8-1_source.changes http://www.falconpl.org/downloads/0.8.8/falconpl_0.8.8.orig.tar.gz The checks performed by Ubuntu maintainers have been quite extensive and deep, and the package should be ready as is; so, I am requesting a sponsor to forward the package in Debian too. Bests, Giancarlo Niccolai. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHses15nwsoBIDC4YRAiRSAJ4g7JMoQNpHXlJzNLdQ7vW7zrQZswCbBTt2 BWbOyR/AyFG8rPVbH1xuebk= =xdxC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: python-twitter
[Mauro Lizaur, 11.02.2008] may i ask which was the lintian error? i executed lintan -i -I and it was clean :/ it was about missing python package in Build-Depends (a bug in lintian - fixed already) 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? I moved one of the links from long description to this field (apparently wrong one) - instead of using 'cp' to install the examples, i'll use 'install -m 755' install is better, yes (it was cp before my changes, I only updated paths) - 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 ignore it - 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. cannot reproduce it with `dpkg-buildpackage -S -sa`, I'm not building source only packages though, so you can ignore this one as well - And last but not least, may be both manpages could be improved a little bit more, i'll wait for your opinion about them. looks good One more thing before I upload it: please clarify copyright holder issue - the one in sources and in debian/copyright doesn't match (a hint: I was checking 3 other packages before yours today, join DPMT and your packages will get automatically a higher priority :) -- http://people.debian.org/~piotr/sponsor.txt pgp5ANg7hf7ao.pgp Description: PGP signature
Re: RFS: falconpl package (ITP:Bug#460591); source package
Feb 13, 2008 3:53 AM, Giancarlo Niccolai [EMAIL PROTECTED] wrote: The checks performed by Ubuntu maintainers have been quite extensive and deep, and the package should be ready as is; so, I am requesting a sponsor to forward the package in Debian too. I was intrigued by this claim, so here is a review of just the diff.gz: Package descriptions do not need to reference which platforms it is ported to, especially since Debian doesn't yet have GNU/ReactOS or GNU/Darwin ports yet. Package descriptions need some work, please read the developers reference: http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-debian-control debian/rules handles nostrip instead of letting dh_strip do it CFLAGS doesn't look like it is being passed to the upstream build system Shouldn't you be using dh_testroot instead of that weird checkroot thing? If not, the clean target should depend on checkroot. Several files have no newlines at the end. Doesn't close any ITP bug in the changelog. The contents of debian/falconpl-dev.manpages shouldn't be nessecary, just put them in debian/falconpl-dev.install. dh_installman is only for manual pages not installed by the upstream build system. Useless comments extra space in debian/watch Which licence is the Falcon Programming Language License derived from? It looks kind of familiar. License proliferation is bad, it would be nice if you chose another one. If you don't want to do that please get the debian-legal list to review it. debian/copyright references /usr/share/common-licenses twice, one correctly, one incorrectly. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [CDBS] adding commands to the checking target.
Le Tue, Feb 12, 2008 at 03:11:05PM +, Neil Williams a écrit : If the tests are disabled, you won't know if some tests fail on different architectures. The whole point of make check if ensuring that the build works in environments other than the build machine. What about simply limiting the scale of the tests - e.g. if the upstream code uses a randomized input in a loop, maybe upstream could be patched to support a configurable number of cycles in each test routine. if ... DEB_MAKE_CHECK_TARGET = check else DEB_MAKE_CHECK_TARGET = endif Hi Neil, Thanks a lot for the help. I have disabled the tests on arm m68k s390 because they are not so fast, and on mips mipsel hppa because the buildds for these arches are not keeping up. Anyway, I do not expect any user on these architectures. I am all open to enable the tests if one can prove me wrong with a message from a real user (the package name is primer3). 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: [CDBS] adding commands to the checking target.
On 13/02/2008, Charles Plessy wrote: I have disabled the tests on arm m68k s390 because they are not so fast, and on mips mipsel hppa because the buildds for these arches are not keeping up. That won't help your package get faster on the top of the queue. And this doesn't seem to be a valid reason at all to skip the test on some archs. Anyway, you know that m68k isn't taken into account for testing migration, right? Anyway, I do not expect any user on these architectures. How is that a reason? I'd suggest not second-guessing users, and anyway, that can help spot arch-specific troubles (like in the kernel, ISTR hppa troubles detected at buildtime), or underlying bugs that might not be detected on other platforms by the testsuite, but ready-to-bite anyway. I am all open to enable the tests if one can prove me wrong with a message from a real user (the package name is primer3). And that user would be reading -mentors? I'd rather enable the tests on all architectures, except on those where you *might* have a *real* reason not to (I don't know, maybe you might want to disable the testsuite because an item of the toolchain is currently buggy and would make your package FTBFS?). Current statuses of various architectures aren't a reason to do so. -- Cyril Brulebois pgpZzqgAMssjw.pgp Description: PGP signature
Re: Config files which are writable by www-data
On Sun, Feb 10, 2008 at 01:20:14PM +0100, Roland Gruber wrote: but when I copy the files at install time (postinst) then /usr/share/doc should be no problem? If the administrator deletes the files in /usr/share/doc afterwards then my application will have no problems. I got a similiar situation. If the program is going to read-in the files, even as templates, put them into /usr/share/packaganame If they are just examples and the admin can copy and edit them then /usr/share/doc/packagename/examples is where they should go. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 http://www.enc.com.au/ csmall at : enc.com.au http://www.debian.org/ Debian GNU/Linux, software should be Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to set BTS tags nicely
On Tue, Feb 12, 2008 at 02:47:10PM +0100, David Paleino wrote: To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] I do the same except BCC so if anyone replies they don't spammed by the BTS complaining about their reply being commands it doesn't understand. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 http://www.enc.com.au/ csmall at : enc.com.au http://www.debian.org/ Debian GNU/Linux, software should be Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: python-twitter
On Feb 12, 2008 9:28 PM, Piotr Ożarowski [EMAIL PROTECTED] wrote: One more thing before I upload it: please clarify copyright holder issue - the one in sources and in debian/copyright doesn't match Added the email of the author and Google as a copyright holder too. I hope this is ok, if not, just tell me. (a hint: I was checking 3 other packages before yours today, join DPMT and your packages will get automatically a higher priority :) I sent a request to join to the DPMT :) Do i need to add the Uploaders field to debian/control? Btw, eventually i'll see how to upload the debian/ dir to the svn repositories too. http://mentors.debian.net/debian/pool/main/p/python-twitter/python-twitter_0.5-1.dsc Regards, 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
Re: Help with watch file -- versions based on different libraries
Hello, On Wed, 13 Feb 2008, I wrote: I've been trying to write a watch file for flpsed. First of all sorry for hijacking the thread. Secondly, it is amazing how writing down one's problem makes it clear how to solve it! As far as I can see the author's logic for this somewhat bizarre numbering is the hope that by the time 0.5.x needs enough revisions to cross 0.6, everyone will be using fltk2.x anyway. Given this logic, I suppose the natural choice for the watch file would be to use 0.5.* as the pattern that needs to be matched! Thanks anyway. Regards, Kapil. -- signature.asc Description: Digital signature
Skipping tests on some arches.
Le Wed, Feb 13, 2008 at 02:40:02AM +0100, Cyril Brulebois a écrit : I'd rather enable the tests on all architectures Well, no problem for me. One of the reasons why I disabled the tests in the past was that I asked the question and I was advised to do so. Last time, the tests have taken: 1h05 on sparc, 37 min on mipsel, 39 min on mips, 37 min on powerpc, 19 min on hppa, 6 min on amd64… Not a big deal, except of course if everybody makes test like this. In popcon, there are 26 mips users, and primer3 is used by 0.1 % of the Debian users. I still think that it is useless to wait for mips users to have primer3 build before letting bug fixes to primer3 migrate to testing, but as you noted, that it is a different story. If the persons who care about the Debian ports do not mind my package eating their CPUs, I'll happily re-enable the tests everywhere. 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]
Help with watch file -- versions based on different libraries
Hello, I've been trying to write a watch file for flpsed. The upstream home page is at http://www.ecademix.com/JohannesHofmann/flpsed.html This lists two versions of flpsed based on which version of the library fltk is being used. Since Debian only has fltk1.1.x at the moment, I can package only flpsed 0.5.0. However, any watch file I can cook up prefers 0.6.0 to this version. As far as I can see the author's logic for this somewhat bizarre numbering is the hope that by the time 0.5.x needs enough revisions to cross 0.6, everyone will be using fltk2.x anyway. Any solutions? Regards, Kapil. -- signature.asc Description: Digital signature
Re: RFS: meritous 1.2-2
On Tue, 2008-02-12 at 22:19 +0100, Alexander Schmehl wrote: Hi! * D. Moonfire [EMAIL PROTECTED] [080212 20:24]: Salutations, after getting `meritous` packaged, someone kindly found a few bugs which I've patched, sent upstream, but I figured getting them out as soon as reasonable would be a Good Thing(tm) being that one of them causes the game to crash on the first boss fight. :) [EMAIL PROTECTED]:/tmp/meritous-1.2$ head -n3 debian/changelog meritous (1.2-2) UNRELEASED; urgency=low * NOT RELEASED YET It wasn't released yet, so I left that in. :) Took it out. And since you install a desktop file, you should call dh_desktop, too. I saw that it was being ignored (`man dh_desktop` says it is ignored if there is no mime associated with it), but easily enough to put in. Done. Hmmm... any why is the icon not in the desktop file? Didn't think I needed to. I had the Icon= field and Gnome seems to find it without a problem, so I thought it was the acceptable use. I also used the 'egoboo' package to see how I set it up (putting the icon in pixmaps, etc). Thank you for looking at it. I updated it, same link. http://mfgames.com/debian/dists/unstable/main/source/meritous_1.2-2.dsc Cheers, Dylan signature.asc Description: This is a digitally signed message part
RFS: meritous 1.2-2
Salutations, after getting `meritous` packaged, someone kindly found a few bugs which I've patched, sent upstream, but I figured getting them out as soon as reasonable would be a Good Thing(tm) being that one of them causes the game to crash on the first boss fight. :) .dsc: http://mfgames.com/debian/dists/unstable/main/source/meritous_1.2-2.dsc SVN: http://mfgames.com/svn/debian/meritous/ apt-get repositories: deb http://mfgames.com/debian unstable main deb-src http://mfgames.com/debian unstable main I think that's all I need to include. Thank you kindly, Dylan signature.asc Description: This is a digitally signed message part
Re: RFS: uncrustify (updated package) (second try)
Hi,
reading the thread Lintian: outdated-autotools-helper-file on this
list, I think I now found the right way(TM) to handle config.{sub,guess}
files:
The two files are removed (using rm -f) in the clean target, but then
the source package would generate a Lintian error as in the above
mentioned thread. (I also think, missing config.* would prevent
cross-building.)
So the two files are copied into the source tree from /usr/share/misc/
just before calling ./configure. Now the package build-depends on
autotools-dev again.
The updated package can be found on Debian mentors:
- URL: http://mentors.debian.net/debian/pool/main/u/uncrustify
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/u/uncrustify/uncrustify_0.43-1.dsc
Bye,
Johann Rudloff
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Skipping tests on some arches.
On 13/02/2008, Charles Plessy wrote: 1h05 on sparc, 37 min on mipsel, 39 min on mips, 37 min on powerpc, 19 min on hppa, 6 min on amd64… What about *relative* numbers, e.g. what % of the time is spent in the build itself (gcc and friends), and what % of the time is spent in the testsuite? Anyway, (almost) less than 1 hour everywhere isn't what I call time-consuming from a buildd point of view. Not a big deal, except of course if everybody makes test like this. More tests, less bugs. In popcon, there are 26 mips users, and primer3 is used by 0.1 % of the Debian users. Popcon is no absolute knowledge. Anyway, 25+ users is far from negligible AFAICT. Remember popcon can be disabled for various reasons (e.g. privacy). I also seem to recall having heard of mips (but I might be mistaken) clusters being used for specialized research in related areas (but I'm not used to this domain, just reading the description of the package). I still think that it is useless to wait for mips users to have primer3 build before letting bug fixes to primer3 migrate to testing, but as you noted, that it is a different story. Indeed, that's nothing related here, and you've been already heavily discussing the buildd redundancy matter elsewhere… If the persons who care about the Debian ports do not mind my package eating their CPUs, I'll happily re-enable the tests everywhere. Less than 3/4 hour isn't what I call eating CPU. Go and see how many *hours* are spent in some packages. Again, I'd rather see buildd being used as much as possible to catch problems at build time than letting bugs pass through and bite users at runtime, which is always a PITA to debug. YMMV. -- Cyril Brulebois pgpwdLKzcWCwG.pgp Description: PGP signature
Re: RFS: meritous 1.2-2
Hi! * D. Moonfire [EMAIL PROTECTED] [080212 20:24]: Salutations, after getting `meritous` packaged, someone kindly found a few bugs which I've patched, sent upstream, but I figured getting them out as soon as reasonable would be a Good Thing(tm) being that one of them causes the game to crash on the first boss fight. :) [EMAIL PROTECTED]:/tmp/meritous-1.2$ head -n3 debian/changelog meritous (1.2-2) UNRELEASED; urgency=low * NOT RELEASED YET And since you install a desktop file, you should call dh_desktop, too. Hmmm... any why is the icon not in the desktop file? Yours sincerely, Alexander -- http://learn.to/quote/ http://www.catb.org/~esr/faqs/smart-questions.html signature.asc Description: Digital 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. From a QA point of view it would be nice that we can actually test the archive with a new version. We could warn in advance which packages have a problem. We can track which still have the problem, and so on. This would of course assume that it either gets uploaded to experimental, or that it's not the default version in unstable. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to set BTS tags nicely
On Tue, 12 Feb 2008, Henrique de Moraes Holschuh wrote: On Tue, 12 Feb 2008, David Paleino wrote: I usually do: To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Better change that cc to bcc. That way, spammers (and people) replying to your mail will not hammer the poor control bot. It's no big deal if people send mail improperly to control; it deals with it fairly sanely. Don Armstrong -- ou could say to the Universe this is not /fair/. And the Universe would say: Oh it isn't? Sorry. -- Terry Pratchett _Soul Music_ p357 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Tests that take more than ten times build time.
Re-salut Cyril, Le Wed, Feb 13, 2008 at 03:30:24AM +0100, Cyril Brulebois a écrit : What about *relative* numbers, e.g. what % of the time is spent in the build itself (gcc and friends), and what % of the time is spent in the testsuite? Anyway, (almost) less than 1 hour everywhere isn't what I call time-consuming from a buildd point of view. Test time on arch (build time) 1h05 on sparc (3 min), 37 min on mipsel (2 min), 39 min on mips (3 min), 37 min on powerpc (2 min), 19 min on hppa (2 min), 6 min on amd64 (1 min)… Of course, if this is an exception, there is no need to argue. But in the Debian-Med packaging team, we have a few package whose tests are not yet enabled (bioperl, emboss,...); I do not know if it would be wise to do so systematically if they have a similar pattern of CPU usage... Or maybe in the end it would be the role of the port responsibles to micromanage this? Popcon is no absolute knowledge. Anyway, 25+ users is far from negligible AFAICT. Sure, but we are talking og 0.1 % of 25+ users. So if for one popcon report there are 10 instalations, it still makes only 0.25 user. And this includes the persons who downoladed the package but are not using it. Bonne journée, -- 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: How to set BTS tags nicely
On Tue, 12 Feb 2008, David Paleino wrote: I usually do: To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Better change that cc to bcc. That way, spammers (and people) replying to your mail will not hammer the poor control bot. -- 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: signed mails to control@ (was: How to set BTS tags nicely)
Hi David, * David Paleino [EMAIL PROTECTED] [2008-02-12 15:10]: Il giorno Tue, 12 Feb 2008 14:53:21 +0100 Nico Golde [EMAIL PROTECTED] ha scritto: * David Paleino [EMAIL PROTECTED] [2008-02-12 14:50]: [...] I usually sign all my emails -- but when I include commands to the BTS I cannot do that, as the GPG header is confusing the server. So, this is how you would do it. I add more to the original question: is it possible to send GPG-signed mails to [EMAIL PROTECTED] What problems did you experience? Cause I sign all my mails no matter if they go to the control address or not and never had any problem with that. To be honest, last time I tried sending a signed mail to control@ was something like a year ago. Something may have changed since then, since I've just made a test mail (see #455005). But I've also changed something: now I send my GPG signature as PGP/MIME, before I was sending it as PGP/Inline. I bet that control@ can't handle PGP/Inline signed messages. Yes this seems to be the reason then :) Cheers Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html pgpXnTiaIpfnt.pgp Description: PGP signature
[CDBS] adding commands to the checking target.
Dear mentors, I am using CDBS for a package, in particular because it gives the support of the nocheck option for free, but in addition I want to disable by default the checks for some arches, because they take 20 min on an iMac G5… To add things to the clean rule, one would have to write something like this: clean:: instruction to be added. However, I have not found anything for the checks. Does anybody know? The code I would like to add is: ifeq (,$(filter $(DEB_HOST_ARCH_CPU),$(SKIP_TEST_CPUS))) @echo Fast-cpu arch detected, performing checks. else @echo Slow-cpu arch detected, skipping checks.t DEB_BUILD_OPTIONS += nocheck endif (at this point, it may be obvious to some of you that I am not comfortable with the syntax of variable comparisons in makefiles, because it would of course be better to have a simple if slow arch, then nocheck) 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: signed mails to control@ (was: How to set BTS tags nicely)
Il giorno Tue, 12 Feb 2008 14:53:21 +0100 Nico Golde [EMAIL PROTECTED] ha scritto: Hi David, Hi Nico, * David Paleino [EMAIL PROTECTED] [2008-02-12 14:50]: [...] I usually sign all my emails -- but when I include commands to the BTS I cannot do that, as the GPG header is confusing the server. So, this is how you would do it. I add more to the original question: is it possible to send GPG-signed mails to [EMAIL PROTECTED] What problems did you experience? Cause I sign all my mails no matter if they go to the control address or not and never had any problem with that. To be honest, last time I tried sending a signed mail to control@ was something like a year ago. Something may have changed since then, since I've just made a test mail (see #455005). But I've also changed something: now I send my GPG signature as PGP/MIME, before I was sending it as PGP/Inline. I bet that control@ can't handle PGP/Inline signed messages. 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: How to set BTS tags nicely
Le 12 févr. 08 à 14:47, David Paleino a écrit : Il giorno Tue, 12 Feb 2008 14:35:46 +0100 Thibaut Paumard [EMAIL PROTECTED] ha scritto: Sometimes, I want to send new information to a bug report and set tags or otherwise modify the bug at the same time (for instance, but not only, sending a patch and setting the patch tag). I have tried setting a pseudo-header in my e-mail to bug- id@bugs.debian.org to no avail. It seems I must send two separate e- mails, one with the information to bug-id@ and the other with the commands to [EMAIL PROTECTED] I usually do: To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] ... Thanks, I guess I could have figured that out :-) Does what I want (display the modifications to the bug report as well as the information that goes with them). Never had a problem with signed e-mails to [EMAIL PROTECTED] Best regards, Thibaut. PGP.sig Description: Ceci est une signature électronique PGP
Re: How to set BTS tags nicely
Il giorno Tue, 12 Feb 2008 14:35:46 +0100 Thibaut Paumard [EMAIL PROTECTED] ha scritto: Hi, Hi, There is a trivial question I've been asking myself for some time, and I guess it will be best abswered here. Sometimes, I want to send new information to a bug report and set tags or otherwise modify the bug at the same time (for instance, but not only, sending a patch and setting the patch tag). I have tried setting a pseudo-header in my e-mail to bug- id@bugs.debian.org to no avail. It seems I must send two separate e- mails, one with the information to bug-id@ and the other with the commands to [EMAIL PROTECTED] Is it really how I should do, or is there a more correct way to proceed? I usually do: To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] ... tags nn +patch moreinfo unreproducible blah blah blah thanks Hi, the bug you reported [..] I usually sign all my emails -- but when I include commands to the BTS I cannot do that, as the GPG header is confusing the server. So, this is how you would do it. I add more to the original question: is it possible to send GPG-signed mails to [EMAIL PROTECTED] Cheers, 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: [CDBS] adding commands to the checking target.
On Tue, 2008-02-12 at 23:37 +0900, Charles Plessy wrote: I am using CDBS for a package, in particular because it gives the support of the nocheck option for free, but in addition I want to disable by default the checks for some arches, because they take 20 min on an iMac G5… If the tests are disabled, you won't know if some tests fail on different architectures. The whole point of make check if ensuring that the build works in environments other than the build machine. What about simply limiting the scale of the tests - e.g. if the upstream code uses a randomized input in a loop, maybe upstream could be patched to support a configurable number of cycles in each test routine. ifeq (,$(filter $(DEB_HOST_ARCH_CPU),$(SKIP_TEST_CPUS))) @echo Fast-cpu arch detected, performing checks. else @echo Slow-cpu arch detected, skipping checks.t DEB_BUILD_OPTIONS += nocheck endif if ... DEB_MAKE_CHECK_TARGET = check else DEB_MAKE_CHECK_TARGET = endif -- 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
How to set BTS tags nicely
Hi, There is a trivial question I've been asking myself for some time, and I guess it will be best abswered here. Sometimes, I want to send new information to a bug report and set tags or otherwise modify the bug at the same time (for instance, but not only, sending a patch and setting the patch tag). I have tried setting a pseudo-header in my e-mail to bug- id@bugs.debian.org to no avail. It seems I must send two separate e- mails, one with the information to bug-id@ and the other with the commands to [EMAIL PROTECTED] Is it really how I should do, or is there a more correct way to proceed? Greetings, Thibaut. PGP.sig Description: Ceci est une signature électronique PGP
Re: RFC: Howto exclude config.sub and config.guess updates from .diff.gz
Am Montag, den 11.02.2008, 19:48 +0100 schrieb 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. This had been suggested earlier in this thread: http://lists.debian.org/debian-mentors/2008/02/msg00220.html http://lists.debian.org/debian-mentors/2008/02/msg00225.html Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITR: ustr (updated package)
On Tue, Feb 12, 2008 at 11:02:40AM +, Neil Williams wrote: On Tue, 2008-02-12 at 10:43 +0100, Václav Ovsík wrote: Dear mentors, I am looking for a sponsor for the new version 1.0.3-2 of my package ustr. It builds these binary packages: libustr-1.0-1 - Micro string library: shared library libustr-1.0-1-dbg - Micro string library: debugging symbols libustr-dev - Micro string library: development stuff Micro string library: development headers would be preferable. Should be discussed further. This package contains besides header files C source files too. Ustr is not ordinary library. The ustr code can be completely included into users code (using ustr-import utility). There is no dependency in this mode of use. I decided for development stuff because of this. libustr-doc - Micro string library: documentation Description: ustr (Micro string library) is a string API for C. It has tiny overhead over just plain strdup(), is much safer, is easier to use, is faster for many operations, can be used with read-only or automatically allocated data. You don't even need to link to the library to use it (so there are no dependencies). Good, that's the kind of RFS I like to see - just one thing missing, this is an existing package: http://packages.qa.debian.org/u/ustr.html Thanks, next time ;) That can be inferred from the bug fix description but the knowledge of whether this is a new package (with an ITP) or an existing package is very useful to a potential sponsor so it is as well to put it in a prominent place in the RFS. The subject indicates this, but link can be useful, ok. Upstream author: James Antill Homepage: http://www.and.org/ustr/ This library is the requisite for latest libsemanage, the library of the SELinux code suite. ... and already in Debian. (this is the most natural place for the missing comment to appear). Yes. Latest package libsemanage 2.0.9-1 uses it already. sid:~# apt-cache rdepends libustr-1.0-1 libustr-1.0-1 Reverse Depends: libsemanage1 python-semanage libustr-dev libustr-1.0-1-dbg libsemanage1-dev libsemanage1 ... I'll review it this week. (Bit busy with Emdebian today). Thanks for suggestions. Cheers -- Zito -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITR: ustr (update for existing package)
On Tue, 2008-02-12 at 12:07 +0100, Patrick Schoenfeld wrote: Hey Neil, On Tue, Feb 12, 2008 at 11:02:40AM +, Neil Williams wrote: Good, that's the kind of RFS I like to see - just one thing missing, this is an existing package: http://packages.qa.debian.org/u/ustr.html just a quick note (and question): He indicated that this package isn't new, by using the updated package subject. Shouldn't this be suffice? I'd say not quite. (updated package) can refer to an ITP that has been partially reviewed, re-uploaded to mentors and is awaiting further review before the first upload to Debian. It's getting a bit like splitting hairs from here on but I suppose the full answer would be to use: RFS: $package (updated NEW package) RFS: $package (updated existing package) or (update for existing package) -- 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: ITR: ustr (updated package)
Hi Dne Tue, 12 Feb 2008 11:02:40 + Neil Williams [EMAIL PROTECTED] napsal(a): That can be inferred from the bug fix description but the knowledge of whether this is a new package (with an ITP) or an existing package is very useful to a potential sponsor so it is as well to put it in a prominent place in the RFS. Have you read subject? :-) -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: ITR: ustr (updated package)
On Tue, 2008-02-12 at 10:43 +0100, Václav Ovsík wrote: Dear mentors, I am looking for a sponsor for the new version 1.0.3-2 of my package ustr. It builds these binary packages: libustr-1.0-1 - Micro string library: shared library libustr-1.0-1-dbg - Micro string library: debugging symbols libustr-dev - Micro string library: development stuff Micro string library: development headers would be preferable. libustr-doc - Micro string library: documentation Description: ustr (Micro string library) is a string API for C. It has tiny overhead over just plain strdup(), is much safer, is easier to use, is faster for many operations, can be used with read-only or automatically allocated data. You don't even need to link to the library to use it (so there are no dependencies). Good, that's the kind of RFS I like to see - just one thing missing, this is an existing package: http://packages.qa.debian.org/u/ustr.html That can be inferred from the bug fix description but the knowledge of whether this is a new package (with an ITP) or an existing package is very useful to a potential sponsor so it is as well to put it in a prominent place in the RFS. Upstream author: James Antill Homepage: http://www.and.org/ustr/ This library is the requisite for latest libsemanage, the library of the SELinux code suite. ... and already in Debian. (this is the most natural place for the missing comment to appear). Ustr is packaged using CDBS. Package was rebuild using pbuilder. Lintian v1.23.43 on ustr_1.0.3-2_i386.changes reports nothing. Vcs-Browser: http://git.debian.org/?p=users/zito-guest/pkg-ustr.git Vcs-Git: git://git.debian.org/~zito-guest/pkg-ustr.git The upload would fix an important bug 465005 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465005 - bashism in the utility script ustr-import. It also cleans manpages a bit. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/u/ustr - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/u/ustr/ustr_1.0.3-2.dsc I would be glad if someone uploaded this package for me. I'll review it this week. (Bit busy with Emdebian today). -- 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: ITR: ustr (updated package)
Hey Neil, On Tue, Feb 12, 2008 at 11:02:40AM +, Neil Williams wrote: Good, that's the kind of RFS I like to see - just one thing missing, this is an existing package: http://packages.qa.debian.org/u/ustr.html just a quick note (and question): He indicated that this package isn't new, by using the updated package subject. Shouldn't this be suffice? Best Regards, Patrick signature.asc Description: Digital signature
signed mails to control@ (was: How to set BTS tags nicely)
Hi David, * David Paleino [EMAIL PROTECTED] [2008-02-12 14:50]: [...] I usually sign all my emails -- but when I include commands to the BTS I cannot do that, as the GPG header is confusing the server. So, this is how you would do it. I add more to the original question: is it possible to send GPG-signed mails to [EMAIL PROTECTED] What problems did you experience? Cause I sign all my mails no matter if they go to the control address or not and never had any problem with that. Kind regards Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html pgp6OvTygScaw.pgp Description: PGP signature
