[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH] Support for "hardware burn-in" stage



Spam detection software, running on the system "recolte.poivron.org", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
the administrator of that system for details.

Content preview:  On Fri, Feb 08, 2008 at 03:05:27PM +0000, Chris Lamb wrote:
   > This series of patches enhances cpuburn to support a hardware burn-in stage
   > in D-I. > [â?¦] > Obviously, this should not be part of the main install
   process (!), but > as an optional component. > [â?¦] > My patch is in three
   parts: > > 1. Updates cpuburn packaging to be more accomodating to another
   binary > package. > 2. Moves all patches from the .diff.gz to debian/patches
   and quilt. [...] 

Content analysis details:   (5.6 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 4.5 HELO_LOCALHOST         HELO_LOCALHOST
 1.9 DATE_IN_PAST_06_12     Date: is 6 to 12 hours before Received: date
-0.8 AWL                    AWL: From: address is in the auto white-list

The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam.  If you wish to view
it, it may be safer to save it to a file and open it with an editor.

--- Begin Message ---
On Fri, Feb 08, 2008 at 03:05:27PM +0000, Chris Lamb wrote:
> This series of patches enhances cpuburn to support a hardware burn-in stage
> in D-I.
> […]
> Obviously, this should not be part of the main install process (!), but
> as an optional component.
> […]
> My patch is in three parts:
> 
>  1. Updates cpuburn packaging to be more accomodating to another binary
>     package.
>  2. Moves all patches from the .diff.gz to debian/patches and quilt.

As far as I have understood from this thread your are not the maintainer
of cpuburn.  IMHO, packaging practices are tightly related to maintainers
habits and tools and this kind of changes are likely to make the whole
patch rejected…

>  3. Adds the cpuburn-udeb package (the interesting bit)
> […]
> +Package: cpuburn-udeb
> +XC-Package-Type: udeb
> +XB-Installer-Menu-Item: 2600

I agree with most of the other remarks I have seen on this list so far.
Meanwhile, I would advocate to split cpuburn-udeb and the actual stress
test component of the installer.

Chris' proposal would gives us the same situation as ppp-udeb.
There would be some code depending highly on how d-i is working as a
whole (its components might change along the development) which would
not be easily modifiable by the d-i team.

The removal of "ifconfig" made me aware of this situation for ppp-udeb,
and I think it would be better if we could avoid it in the future.  It
would also enable Chris' to maintain the installer component without
having to bother Aurélien everytime he would like to improve the stress
test without touching cpuburn.

About the possibility to preseed the stress test, if we really think
that we should support it, I think the safest way to implement it would
be to never load the component by default.

"modules=stress-test" will have to be given on the command line or
in the preseeding file.  The best position in the menu in this case
would be after loading additional modules.

We loose the possibility to have the option near "Verify CD" but in my
own experience, in case of faulty hardware, the installation never
completed.  d-i can be seen as a good hardware test for the average
user.  :D

(BTW: I'd like to write some patches to the split PPPoE configuration
stage out of ppp-udeb, but that's only part of my pet TODO list,
currently.)

Cheers,
-- 
Jérémy Bobbio                        .''`. 
lunar@debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-   

Attachment: signature.asc
Description: Digital signature


--- End Message ---

Reply to: