Re: [gentoo-catalyst] Re: Catalyst pull request

[Brian Dolbec <dolsen@gentoo.org>]

On Thu, 30 Jan 2014 08:46:11 -0800
"W. Trevor King" <wking@tremily.us> wrote:

> 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.

There isn't going to be any real development work in the stable 2.X
branch.  Just bug fixes until 3.0 is ready for release.  So, it won't
prove very useful in general.  Plus I'm ready to commit the one in
pending for the main development branch.

> 
> > > 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.


How about just a general kernel_opts field in the spec

ie.   kernel_opts: panic=30 foo=bar

That makes it possible to add more than just a panic= to the
commandline while still being simple for catalyst.  It is just one
variable.  The help comment above it in the example spec can list the
options recommended.

> 
> > >> > 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 ;).

Yes, if this is to go into the stable branch. It should be done
properly.

> 
> > >> > 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
> 

If you could address the above issues, I think the rest of the team
would approve the changes for the 2.X branch.  I can also add them to
the pending branch queue for merge into master.  I have done very
little to the kernel code areas, so there should be few to no conflicts
with the rewrite changes.

Brian Dolbec