"Sergei Golovan" <[EMAIL PROTECTED]> writes:
> Erlang compiler reads $HOME/.erlang if it exists. It's contents may
> have impact on the package. If the compiler cannot read $HOME it
> reports an ugly error message (though it still works). But an
> additional tool which is used in wings3d crashes i
On 9/10/07, Steve Greenland <[EMAIL PROTECTED]> wrote:
> On 09-Sep-07, 02:26 (CDT), Sergei Golovan <[EMAIL PROTECTED]> wrote:
> > But OK, I'll try to fix the package (setting HOME inside debian/rules
> > should help).
>
> That's fixing a symptom, not the bug. What possible justification is
> there
On 09-Sep-07, 02:26 (CDT), Sergei Golovan <[EMAIL PROTECTED]> wrote:
> On 9/9/07, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > It's a bug in your package. Packages should not rely on anything in $HOME
> > for building, and should definitely not write anything to $HOME, as packages
> > are not su
On Sun, Sep 09, 2007 at 11:26:14AM +0400, Sergei Golovan wrote:
> > > Should this be treated as a bug in buildd configuration or package
> > > maintainers should take into account the possibility of so unusual
> > > HOME behavior?
> > It's a bug in your package. Packages should not rely on anythi
On 9/9/07, Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 09, 2007 at 11:08:19AM +0400, Sergei Golovan wrote:
>
> > One of the packages co-maintained by me FTBFS if HOME environment
> > variable points to an existing inaccessible directory. (See
> > http://buildd.debian.org/fetch.cgi?&pkg=
On Sun, Sep 09, 2007 at 11:08:19AM +0400, Sergei Golovan wrote:
> On 8/28/07, Russ Allbery <[EMAIL PROTECTED]> wrote:
> > I don't have any time to work on this, but it occurred to me reading this
> > that it might be useful for QA purposes to have a version of debuild that
> > *unsanitizes* the en
On Sun, 9 Sep 2007 11:08:19 +0400
"Sergei Golovan" <[EMAIL PROTECTED]> wrote:
> One of the packages co-maintained by me FTBFS if HOME environment
> variable points to an existing inaccessible directory. (See
> http://buildd.debian.org/fetch.cgi?&pkg=wings3d&ver=0.98.36-4&arch=mipsel&stamp=11892516
On 8/28/07, Russ Allbery <[EMAIL PROTECTED]> wrote:
> I don't have any time to work on this, but it occurred to me reading this
> that it might be useful for QA purposes to have a version of debuild that
> *unsanitizes* the environment to test robustness. An evil-debuild that
> sets every problem
On 2007-08-28 12:22 -0700, Russ Allbery wrote:
> I don't have any time to work on this, but it occurred to me
> reading this that it might be useful for QA purposes to have a
> version of debuild that *unsanitizes* the environment to test
> robustness. An evil-debuild that sets every problematic
Jörg Sommer <[EMAIL PROTECTED]> writes:
> If you really suggest to take care of broken environemts, you should
> think about such ugliness:
> % cat Makefile
> # I need this, because /bin/sh is dash at me.
> SHELL=/bin/bash
> clean:
> rm bla
> ls -ld /proc//exe
> % env -i rm='()
Hi,
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> On Tue, 28 Aug 2007 21:15:35 +0300, Riku Voipio <[EMAIL PROTECTED]> said:
>
>>> >> Many packages FTBFS (silently!) if an environment variable TAPE is
>>> >> set.
>>> Perhaps dpkg-buildpackage should unset TAPE...?
>
>> pbuilder and other tools alr
On 2007-08-29 10:58 -0500, John Goerzen wrote:
> On Tue August 28 2007 3:11:20 pm Eduard Bloch wrote:
>
> > Oh, come on. People who put $TAPE into the default environment
> > may also link /dev/null to /dev/hda (or /dev/sda) and complain
> > to the coretutils maintainer because ln isn't unable to
On Wed August 29 2007 2:51:01 pm Mike Hommey wrote:
>
> GNU tar defaults to stdout since version 1.12, released on Apr 26, 1997.
> So it's been more than 10 years that GNU tar has *not* been defaulting to
> a tape device.
I don't think that's accurate. GNU tar's *configure* defaults to stdout.
On Wed, Aug 29, 2007 at 02:38:37PM -0500, John Goerzen <[EMAIL PROTECTED]>
wrote:
> On Wed August 29 2007 1:28:32 pm Steinar H. Gunderson wrote:
> > On Wed, Aug 29, 2007 at 01:20:52PM -0500, John Goerzen wrote:
> > >>> I don't think so. Hasn't tar defaulted to something approximately
> > >>> /dev
On Wed August 29 2007 1:28:32 pm Steinar H. Gunderson wrote:
> On Wed, Aug 29, 2007 at 01:20:52PM -0500, John Goerzen wrote:
> >>> I don't think so. Hasn't tar defaulted to something approximately
> >>> /dev/rmt0 for *YEARS*, not just on Linux but on just about every
> >>> platform, if -f is not g
On Wed, Aug 29, 2007 at 01:20:52PM -0500, John Goerzen wrote:
>>> I don't think so. Hasn't tar defaulted to something approximately
>>> /dev/rmt0 for *YEARS*, not just on Linux but on just about every
>>> platform, if -f is not given?
>> No.
> You cite nothing to back that up, and everything I can
On Wed August 29 2007 12:16:20 pm John H. Robinson, IV wrote:
> Steinar H. Gunderson wrote:
> > On Wed, Aug 29, 2007 at 09:05:05AM -0700, John H. Robinson, IV wrote:
> > >>> I don't think so. Hasn't tar defaulted to something approximately
> > >>> /dev/rmt0 for *YEARS*, not just on Linux but on ju
On Wed August 29 2007 11:00:50 am Steinar H. Gunderson wrote:
> On Wed, Aug 29, 2007 at 10:58:17AM -0500, John Goerzen wrote:
> > I don't think so. Hasn't tar defaulted to something approximately
> > /dev/rmt0 for *YEARS*, not just on Linux but on just about every
> > platform, if -f is not given?
Steinar H. Gunderson wrote:
> On Wed, Aug 29, 2007 at 09:05:05AM -0700, John H. Robinson, IV wrote:
> >>> I don't think so. Hasn't tar defaulted to something approximately
> >>> /dev/rmt0 for *YEARS*, not just on Linux but on just about every platform,
> >>> if -f is not given?
> >> No.
> > tar !=
* Steinar H. Gunderson <[EMAIL PROTECTED]> [070829 18:02]:
> On Wed, Aug 29, 2007 at 10:58:17AM -0500, John Goerzen wrote:
> > I don't think so. Hasn't tar defaulted to something approximately
> > /dev/rmt0 for *YEARS*, not just on Linux but on just about every platform,
> > if -f is not given?
>
ke, 2007-08-29 kello 18:00 +0200, Steinar H. Gunderson kirjoitti:
> On Wed, Aug 29, 2007 at 10:58:17AM -0500, John Goerzen wrote:
> > I don't think so. Hasn't tar defaulted to something approximately
> > /dev/rmt0 for *YEARS*, not just on Linux but on just about every platform,
> > if -f is not gi
On Wed, Aug 29, 2007 at 09:05:05AM -0700, John H. Robinson, IV wrote:
>>> I don't think so. Hasn't tar defaulted to something approximately
>>> /dev/rmt0 for *YEARS*, not just on Linux but on just about every platform,
>>> if -f is not given?
>> No.
> tar != gtar. I think you will find that answer
Steinar H. Gunderson wrote:
> On Wed, Aug 29, 2007 at 10:58:17AM -0500, John Goerzen wrote:
> > I don't think so. Hasn't tar defaulted to something approximately
> > /dev/rmt0 for *YEARS*, not just on Linux but on just about every platform,
> > if -f is not given?
>
> No.
tar != gtar. I think yo
* Joey Hess <[EMAIL PROTECTED]> [070828 23:26]:
> This thread has concentrated on fixing packages, but I would appreciate
> a little insight into why someone might set TAPE in their environment by
> default. Surely if you set it by default, you must realse that you're
> asking any such invocation o
On Wed, Aug 29, 2007 at 10:58:17AM -0500, John Goerzen wrote:
> I don't think so. Hasn't tar defaulted to something approximately
> /dev/rmt0 for *YEARS*, not just on Linux but on just about every platform,
> if -f is not given?
No.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSU
On Tue August 28 2007 3:11:20 pm Eduard Bloch wrote:
> Oh, come on. People who put $TAPE into the default environment may also
> link /dev/null to /dev/hda (or /dev/sda) and complain to the coretutils
> maintainer because ln isn't unable to think for them.
I don't think so. Hasn't tar defaulted
* Riku Voipio <[EMAIL PROTECTED]> [070829 00:22]:
> Why should we force 7000+ source packages clean their environment
> when debuild/pbuilder/sbuild etc will do that anyway? Worse, it's
> not even trivial to clean environment in a Makefile.
Because those source packages are a large amount of code,
On Tue, Aug 28, 2007 at 05:26:09PM -0400, Joey Hess wrote:
> This thread has concentrated on fixing packages, but I would appreciate
> a little insight into why someone might set TAPE in their environment by
> default. Surely if you set it by default, you must realse that you're
> asking any such i
On Wed, Aug 29, 2007 at 12:42:32AM +0200, Torsten Landschoff wrote:
> On Tue, Aug 28, 2007 at 06:54:23PM +0100, Matthew Woodcraft wrote:
> > Bastian Blank <[EMAIL PROTECTED]> wrote:
> > > The manpage of tar does not mention the special handling of a
> > > environment variable named TAPE. Nor does
Joey Hess <[EMAIL PROTECTED]> wrote:
> This thread has concentrated on fixing packages, but I would
> appreciate a little insight into why someone might set TAPE in their
> environment by default. Surely if you set it by default, you must
> realse that you're asking any such invocation of tar to w
On Tue, Aug 28, 2007 at 06:54:23PM +0100, Matthew Woodcraft wrote:
> Bastian Blank <[EMAIL PROTECTED]> wrote:
> > The manpage of tar does not mention the special handling of a
> > environment variable named TAPE. Nor does tar --help.
>
> But, unsurprisingly, the tar manual does (under the --file
Riku Voipio <[EMAIL PROTECTED]> writes:
> Why should we force 7000+ source packages clean their environment when
> debuild/pbuilder/sbuild etc will do that anyway? Worse, it's not even
> trivial to clean environment in a Makefile.
In this particular case, there's no need to clean the environment.
> > That's why we tell people to use pbuilder.
> I think I disagree with the reason given for this advice. What
> is the end goal that we are trying to achieve? Is it to upload binary
> packages that build despite leaving flaws i the build process? Always
> building in pbuilder masks e
Joey Hess <[EMAIL PROTECTED]> writes:
> This thread has concentrated on fixing packages, but I would appreciate
> a little insight into why someone might set TAPE in their environment by
> default. Surely if you set it by default, you must realse that you're
> asking any such invocation of tar to
Harald Dunkel wrote:
> Many packages FTBFS (silently!) if an environment variable TAPE
> is set. That happens if your rules script uses something like
>
> tar -c modules | bzip2 -9 > omfs.tar.bz2
>
> for example. If $TAPE is set, then tar writes to $TAPE instead
> of stdout (possibly corrupti
On Tue, 28 Aug 2007 21:43:00 +0200, Michael Banck <[EMAIL PROTECTED]> said:
> Or we get source-only uploads rolling and always build in a controlled
> environment.
That only helps the binary packages we distribute -- leaving our
source packages full of holes masked by our sterile build
Hi Eduard,
Eduard Bloch wrote:
verify his/her own package. But in this case a central check would be cheap
and easy to implement. Almost zero effort compared to the damage done by
corrupting tapes.
Oh, come on. People who put $TAPE into the default environment may also
link /dev/null to /dev
On Tue, 28 Aug 2007 21:15:35 +0300, Riku Voipio <[EMAIL PROTECTED]> said:
>> >> Many packages FTBFS (silently!) if an environment variable TAPE is
>> >> set.
>> Perhaps dpkg-buildpackage should unset TAPE...?
> pbuilder and other tools already do that when chrooting? Tar's $TAPE
> behaviour fail
#include
* Harald Dunkel [Tue, Aug 28 2007, 01:27:22PM]:
> Hi Bas,
>
> You could write 'tar cfz file.tgz files' instead of 'tar -c -f file.tgz -z
> files'.
No, because the outcome is not the same. It uses pure gzip and usually
people want more gzip (or bzip2) options when using it in a pipe, eg.
* Bastian Blank:
> On Tue, Aug 28, 2007 at 09:39:47AM -0700, John H. Robinson, IV wrote:
>> I assume you mean to make the documentation match the behaivour.
>
> At least.
>
>> Rememer it is a Tape ARchival program.
>
> | -f, --file [HOSTNAME:]F
> | use archive file or device F (default "-", meanin
Michael Banck <[EMAIL PROTECTED]> writes:
> On Tue, Aug 28, 2007 at 12:22:21PM -0700, Russ Allbery wrote:
>> I don't have any time to work on this, but it occurred to me reading
>> this that it might be useful for QA purposes to have a version of
>> debuild that *unsanitizes* the environment to te
On Tue, Aug 28, 2007 at 12:22:21PM -0700, Russ Allbery wrote:
> I don't have any time to work on this, but it occurred to me reading this
> that it might be useful for QA purposes to have a version of debuild that
> *unsanitizes* the environment to test robustness. An evil-debuild that
> sets ever
Adeodato Simó <[EMAIL PROTECTED]> writes:
> * Riku Voipio [Tue, 28 Aug 2007 21:15:35 +0300]:
>> That's why we tell people to use pbuilder.
> FWIW, debuild alone also sanitizes the environment.
I don't have any time to work on this, but it occurred to me reading this
that it might be useful for Q
* Riku Voipio [Tue, 28 Aug 2007 21:15:35 +0300]:
> That's why we tell people to use pbuilder.
FWIW, debuild alone also sanitizes the environment.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at de
On 28/08/07 at 13:49 +0200, Thijs Kinkhorst wrote:
> On Tuesday 28 August 2007 09:36, Bas Zoetekouw wrote:
> > You wrote:
> > > But most people simply don't know that their rules file corrupts
> > > tapes. First thing would be to detect these packages. This could
> > > be done in the autobuild proc
> >> Many packages FTBFS (silently!) if an environment variable TAPE is set.
> Perhaps dpkg-buildpackage should unset TAPE...?
pbuilder and other tools already do that when chrooting? Tar's $TAPE
behaviour fails the principle of least suprise. Tar developers
should reconsider the usability implic
Bastian Blank <[EMAIL PROTECTED]> wrote:
> The manpage of tar does not mention the special handling of a
> environment variable named TAPE. Nor does tar --help.
But, unsurprisingly, the tar manual does (under the --file option).
-M-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
On Tue, Aug 28, 2007 at 09:39:47AM -0700, John H. Robinson, IV wrote:
> I assume you mean to make the documentation match the behaivour.
At least.
> Rememer it is a Tape ARchival program.
| -f, --file [HOSTNAME:]F
| use archive file or device F (default "-", meaning stdin/stdout)
The file is ex
Bastian Blank wrote:
> On Tue, Aug 28, 2007 at 04:44:32PM +0100, Darren Salt wrote:
> > I demand that Bastian Blank may or may not have written...
> > > On Tue, Aug 28, 2007 at 09:08:12AM +0200, Harald Dunkel wrote:
> > >> Many packages FTBFS (silently!) if an environment variable TAPE is set.
> >
On Tue, Aug 28, 2007 at 04:44:32PM +0100, Darren Salt wrote:
> I demand that Bastian Blank may or may not have written...
> > On Tue, Aug 28, 2007 at 09:08:12AM +0200, Harald Dunkel wrote:
> >> Many packages FTBFS (silently!) if an environment variable TAPE is set.
> > The manpage of tar does not m
On Tue, Aug 28, 2007 at 04:44:32PM +0100, Darren Salt wrote:
> Perhaps dpkg-buildpackage should unset TAPE...?
Why should we work around any possibly developer misconfiguration? Or
is there a valid use-case for setting $TAPE these days which makes it
impossible for the developer to unset it thems
I demand that Bastian Blank may or may not have written...
> On Tue, Aug 28, 2007 at 09:08:12AM +0200, Harald Dunkel wrote:
>> Many packages FTBFS (silently!) if an environment variable TAPE is set.
> The manpage of tar does not mention the special handling of a environment
> variable named TAPE.
On Tuesday 28 August 2007 09:36, Bas Zoetekouw wrote:
> You wrote:
> > But most people simply don't know that their rules file corrupts
> > tapes. First thing would be to detect these packages. This could
> > be done in the autobuild procedure done on the debian hosts, e.g.
> > by setting $TAPE to
Hi Bas,
You could write 'tar cfz file.tgz files' instead of 'tar -c -f file.tgz -z
files'.
Seems that looking for a missing '-f' or 'f' would be pretty error-prone and
much more difficult than a simple "test ! -s watchdog.tar" after building
the package.
My point is: We need some central qualit
On 8/28/07, Bastian Blank <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 28, 2007 at 09:08:12AM +0200, Harald Dunkel wrote:
> > Many packages FTBFS (silently!) if an environment variable TAPE
> > is set.
>
> The manpage of tar does not mention the special handling of a
> environment variable named TAPE.
On Tue, Aug 28, 2007 at 09:08:12AM +0200, Harald Dunkel wrote:
> Many packages FTBFS (silently!) if an environment variable TAPE
> is set.
The manpage of tar does not mention the special handling of a
environment variable named TAPE. Nor does tar --help.
Bastian
--
Beam me up, Scotty!
--
To
Hi Harald!
You wrote:
> I am sure you agree that this is a fatal failure in the package.
> It should be
>
> tar cf - modules | bzip2 -9 > omfs.tar.bz2
>
> But most people simply don't know that their rules file corrupts
> tapes. First thing would be to detect these packages. This could
>
Hi folks,
Many packages FTBFS (silently!) if an environment variable TAPE
is set. That happens if your rules script uses something like
tar -c modules | bzip2 -9 > omfs.tar.bz2
for example. If $TAPE is set, then tar writes to $TAPE instead
of stdout (possibly corrupting the tape you had
58 matches
Mail list logo
