On Sun, Oct 12, 2008 at 05:52:35PM -0400, Will Murnane wrote:
On Sun, Oct 12, 2008 at 07:11, Tzafrir Cohen [EMAIL PROTECTED] wrote:
I maintain the configuration directory under version control. The old
values that lh_config once generated make little sense to me. Many of
them have changed
Tzafrir Cohen wrote:
Why do you run it several times? Shouldn't once be enough?
for the records: due to the fact that some defaults are conditional on
others, you don't get the same in all cases if you run it once compared
to multiple runs.
therefore, lh_config should be called only once if
tags 500740 +pending
thanks
workarounded in git by enforcing lh_config to be run before lh_build.
--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: [EMAIL PROTECTED]
Internet: http://people.panthera-systems.net/~daniel-baumann/
--
To UNSUBSCRIBE,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Oct 12, 2008 at 01:11:38PM +0200, Tzafrir Cohen wrote:
[...]
In my case:
I maintain the configuration directory under version control. The old
values that lh_config once generated make little sense to me. Many of
them have changed over
On Sun, Oct 12, 2008 at 01:26:35PM +0200, Daniel Baumann wrote:
Tzafrir Cohen wrote:
I maintain the configuration directory under version control. The old
values that lh_config once generated make little sense to me. Many of
them have changed over time anyway.
that's manual overriding of
can you *please* show *exactely* how you construct a situation where
this can happen (withouth manual ovveride). also see #490290.
Let me state once again that we are *not* using the lh_config script, but
building the config directory with our own script[1].
Our script does not set all of the
Tzafrir Cohen wrote:
The simplest test case here is running 'lh_build' in an empty directory
(no configuration).
note that this has never been meant to be working; you are always
supposed to run lh_config before lh_build. i'll add a check so that any
helper will fail immediately if there's no
Juliusz Chroboczek wrote:
Let me state once again that we are *not* using the lh_config script, but
building the config directory with our own script[1].
you shall be using lh_config, and anything else is not supported.
Our script does not set all of the LH_* variables, but lets lh_build
Tzafrir Cohen wrote:
I posted a link to patches I posted on the list half a year ago. A quick
glance shows that the problems still stand today.
To reproduce you need to avoid using the default configuration. That is:
assume that a variable is not set at all. Rather, set by
Tzafrir Cohen wrote:
I maintain the configuration directory under version control. The old
values that lh_config once generated make little sense to me. Many of
them have changed over time anyway.
that's manual overriding of variables then.
Or is lh_config the only supported interface? and
tags 500740 +unreproducible
tags 500740 +moreinfo
thanks
Guys,
can you *please* show *exactely* how you construct a situation where
this can happen (withouth manual ovveride). also see #490290.
Regards,
Daniel
--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:
On Sun, Oct 12, 2008 at 12:47:47PM +0200, Daniel Baumann wrote:
Tzafrir Cohen wrote:
I posted a link to patches I posted on the list half a year ago. A quick
glance shows that the problems still stand today.
To reproduce you need to avoid using the default configuration. That is:
On Sun, Oct 12, 2008 at 10:53:29AM +0200, Daniel Baumann wrote:
tags 500740 +unreproducible
tags 500740 +moreinfo
thanks
Guys,
can you *please* show *exactely* how you construct a situation where
this can happen (withouth manual ovveride). also see #490290.
I posted a link to patches I
On Sun, Oct 12, 2008 at 07:11, Tzafrir Cohen [EMAIL PROTECTED] wrote:
I maintain the configuration directory under version control. The old
values that lh_config once generated make little sense to me. Many of
them have changed over time anyway.
For the record, I store a Makefile and a shell
Juliusz Chroboczek wrote:
When LH_UNION_FILESYSTEM and LH_LINUX_PACKAGES are left undefined
how are you *exactely* constructing a situation where they are undefined?
--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: [EMAIL PROTECTED]
Internet:
On Wed, Oct 1, 2008 at 15:44:14 +0200, Daniel Baumann wrote:
Juliusz Chroboczek wrote:
When LH_UNION_FILESYSTEM and LH_LINUX_PACKAGES are left undefined
how are you *exactely* constructing a situation where they are undefined?
We're only defining in config/* the variables for which we
Juliusz Chroboczek (01/10/2008):
When LH_UNION_FILESYSTEM and LH_LINUX_PACKAGES are left undefined,
the build process breaks with
D: Executing: xargs --arg-file=/root/chroot_packages apt-get --yes
install Reading package lists... Done
Building dependency tree... Done
E: Regex
Hi Julien,
On 01/10/2008, Julien Cristau wrote:
When LH_UNION_FILESYSTEM and LH_LINUX_PACKAGES are left undefined
how are you *exactely* constructing a situation where they are undefined?
We're only defining in config/* the variables for which we don't want to
I am confused - what are
Your reports sound all to familiar.
http://lists.alioth.debian.org/pipermail/debian-live-devel/2007-December/002937.html
(1) and (4) has since been fixed. (2)3 and (3) are this bug.
--
Tzafrir Cohen
icq#16849755 jabber:[EMAIL PROTECTED]
+972-50-7952406
Tzafrir Cohen wrote:
Your reports sound all to familiar.
I don't remember seeing this post before. Why didn't you file these as
actual bug reports?
Regards,
--
Chris Lamb, UK [EMAIL PROTECTED]
GPG:
Package: live-helper
Version: 1.0.1-1
Hi,
I'm currently attempting to build a Debian Live-CD and leave most of
the configuration variables undefined. Unfortunately, this doesn't
work -- some of the variables are not defaulted correctly.
When LH_UNION_FILESYSTEM and LH_LINUX_PACKAGES are
21 matches
Mail list logo
