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 .''`. [EMAIL PROTECTED] : :Ⓐ : # apt-get install anarchism `. `'` `-
signature.asc
Description: Digital signature
--- End Message ---
