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
signature.asc
Description: OpenPGP digital signature
