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, em
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 pos
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 c
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:
> 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
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 overr
-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
> 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
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 shel
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? an
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:
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
> /usr/share/l
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 pat
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:
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:
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 mail
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 -
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 co
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
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: http:/
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 le
21 matches
Mail list logo
