Bug#291631: cmp/diff/etc. lack PT_GNU_STACK header
On Mon, 24 Jan 2005, Bill Allombert wrote: On Mon, Jan 24, 2005 at 01:25:44PM +0100, Santiago Vila wrote: On Mon, 24 Jan 2005, Jeroen van Wolffelaar wrote: Yes, I understand that, and I mostly agree. Now please write a lintian warning for PT_GNU_STACK. Mass bug filing me even before a lintian warning exists is not polite. As far as I can see, this is the _only_ bug report by Greg Norris on the PT_GNU_STACK issue! How can it be a mass bug filling ? Because many of the packages I maintain are also built on woody. Also, if you use woody to build your packages, you will use lintian woody, so whatever warning is added to sid lintian will not reach you. Given that, lintian warning checking for packages not built on sid is likely to be useless. Not exactly. There are lintian reports available at lintian.debian.org. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#291631: cmp/diff/etc. lack PT_GNU_STACK header
Santiago Vila wrote: On Mon, 24 Jan 2005, Bill Allombert wrote: As far as I can see, this is the _only_ bug report by Greg Norris on the PT_GNU_STACK issue! How can it be a mass bug filling ? Because many of the packages I maintain are also built on woody. Is there any good reason for that? -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Who needs computer imagery when you've got Brian Blessed? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#268377: Bug#291939: Support for arch aliases
On Mon, Jan 24, 2005 at 03:50:17PM +0100, Goswin von Brederlow wrote: Guillem Jover [EMAIL PROTECTED] writes: On another thread, Goswin von Brederlow wrote: Could we automatically define some @linux@ or @any-i386@ variables the same way shlidbs or other substitutions work? That's exactly what my patch tries to do, but extending the recognised normal arches with some aliases that get expaned and normalized to normal debian archtitectures, the ones the binary tools can and know how to handle. Except you are also changing the syntax for the control file. That is all I see as a negative for this. Well to fix this in a proper way we have to do _some_ changes, mine is the solution with less impact and minimal changes, only a little portion of the archive will change. Robert's implies changing the whole archive to the new syntax. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Only good sOftware here helot
Don't be like that...:) There is only one place with good soft around in the net - want to know where it is ? instant here ! There is no instinct like that of the heart. Hey man internet is a good thing - i found a site ocassionally today with good soft packeges and with very reasonable prices ...so i even saved for new games after this take a look.. http://www.geocities.com/josue_powers_10/ It is not I who become addicted, it is my body. Get newest software packages for half a price that Why just looking at 1000 sites for cheap s0ft price ? - the right place is just a click away work I love her too, but our neuroses just don't match.Equality of opportunity is an equal opportunity to prove unequal talents.If love is the answer, could you please rephrase the question? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291631: cmp/diff/etc. lack PT_GNU_STACK header
On Sun, Jan 23, 2005 at 10:29:12PM +0100, Jeroen van Wolffelaar wrote: Greg: Ease of adding, and potentional negative benefits would be very nice to have, and if it's going to be in policy, for lintian a way to check for it. Purpose: PT_GNU_STACK is used to mark binaries which require an executable stack. This allows security systems, such as SELinux of grsecurity, to enable same only when required. Ease of adding: Recent versions of gcc (3.3.x) add PT_GNU_STACK by default, so pretty much anything compiled under sarge or later will pick it up automatically. It can be disabled by either the compiler or linker if necessary. Negative effects: None that I'm aware of, at least with gcc 3.3.5. I understand that earlier versions (dunno which ones, specifically) were sometimes too optimistic when determining whether or not an executable stack was required. I'm not sure how lintian might go about checking for this... I can only say that `execstack -q' and `objdump -p' will both show this information. I'll do some looking, and see if I can find anything more concrete. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#268377: Bug#291939: Support for arch aliases
On Mon, Jan 24, 2005 at 11:45:24AM +0100, Goswin von Brederlow wrote: type-handling already does all you ever want. Except: - its not in build-essential - its not integrated into dpkg or the build system So it may be fine, it doesn't actually do anything useful. If a pre-existing program that was integrated into dpkg and/or the buildds was working, we wouldn't have this problem. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer csmall at : enc.com.au ieee.org debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
