On Thu, Jan 30, 2014 at 09:56:03AM +0100, Guy Martin wrote:
> On 2014-01-30 00:34, W. Trevor King wrote:
> > On Wed, Jan 29, 2014 at 05:24:30PM -0500, Rick "Zero_Chaos" Farina 
> >> On 01/29/2014 10:19 AM, Guy Martin wrote:
> >> > https://github.com/gmsoft-tuxicoman/catalyst/compare/6046e57...gmsoft?expand=1
> >
> > I think 6046e57 is useful, but it's already in pending with
> > 70f7cfcand fcbcea4 [1]…
>
> This patch just make it easier to develop and test with a git
> branch.  I think it's a good addition and will definitely not break
> anything.

Agreed on both counts.  I'm just recommending the older 70f7cfc and
fcbcea4 over 6046e57.

> > I've never used PALO [2], so I'm agnostic on 0f4c970.  I agree
> > with dol-sen's #gentoo-releng comment that it would be better to
> > make this timeout configurable, but since this is code I'll never
> > use, I don't feel very strongly about it ;).
> 
> The timeout will be configurable when booting. The user always has
> the option to change the value. It's just there because when I
> install a box remotely, I can easily panic the kernel (like ctrl-d
> in the netboot) and I have no way to recover the box.

If you can't set this remotely already, I don't expect a user will be
able to change the value remotely either.  You want to set this in
Catalyst instead, so I think it's fair to support users who want to
change (or disable) the timeout in Catalyst too.

> >> > Regarding commit 333808b,
> > 
> > I don't understand the first hunk in 333808b:
> >
> > …
> > 
> > Why create /tmp/kerncache if kerncache is disabled?
> 
> This directory is used later on in the kmerge.sh script for a few files.
> For example you have :
> /tmp/kerncache/${clst_kname}/${clst_kname}-${clst_version_stamp}.EXTRAVERSION
> /tmp/kerncache/${clst_kname}/${clst_kname}-${clst_version_stamp}.USE
> 
> I wasn't sure about the use of these files so I went for the safe
> route to create the directory. A proper fix might simply be to avoid
> creating these files at all if kerncache isn't used.

The proper fix route sounds better to me ;).

> >> > the second hunk adds --selective=n to emerge always merge the
> >> > kernel. When having two kernels in the livecd specs, the first
> >> > build works fine but the second one fails because the sources
> >> > are removed and not reemerged.
> > 
> > I'm not entirely sure how this is supposed to work, but I'm not
> > wild about --selective=n.  Are the two kernels you're adding to
> > the livecd both from the same package?  …
> 
> Yes they are both from gentoo-sources. On hppa we have to compile a
> 32 and a 64bit kernel, provide them both to palo and it'll decide
> which one to boot base on the machine it's booting. Some hppa box
> can boot only 32 or 64 while some can boot both.

Got it, thanks.  I'll poke around and see if I can come up with
something that works and preserves the @world entry.  Can you point me
towards some example spec files for testing?

Thanks,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy