On 07/27/2015 10:54 AM, Loucaides, John wrote:
>
>> I'm getting start with private packaging. I'll file an Intent-To-
>> Package bug against Debian shortly.
>
> Wouldn't it make sense to play with it first and *then* file one of these?
> At this point, we're not sure when it'll be ready to submit... or exactly
> what it will be when submitted.

I'll check first, but I was told by a Debian expert that as soon as any
effort is started on packaging a new tool, an ITP bug should be filed,
to notify all concerned parties, to avoid duplication of effort. The bug
report is just notification of an intent-to-package, no changes to any
public repos, not exposing CHIPSEC code in any way. Hopefully, anyone
else also considering Debian packaging of CHIPSEC will also be reading
this list, and find this thread...

>> Changes to D-I (Debian Installer) is a much larger effort, and would be
>> later. I have no idea if D-I team would have an interest in a patch
>> with this kind of feature yet.
>
> True, but it could be done before we'll have a deployable driver
ready, and
> it's likely to have a significant positive impact... kinda like that
> memtest86 idea.

If I can get private packaging for CHIPSEC's current code, it'd IMO be
useful. If nobody has the package except people who read the warning and
have to build it themselves via private source tree (not public
packaging locations), then it's hardly different than people who install
CHIPSEC directly from Github, or via LUV source tree. Anyway, I'm not
kidding about being a newbie at Debian packaging: you'll likely have
ample time to update the driver code to be more deployable before I can
get initial packaging to work. :-(

BTW, there are both BIOS blobs and UEFI Application versions of memtest
apps. And I think there's a new UEFI-centric one on Github somewhere. A
UEFI-specific version of this tool could check UEFI's different kinds of
memory in ways I don't believe that a generic memtest app would be able
to do.  I think installers could offer some more firmware-specific HW/FW
diagnostics than they currently do. And there's also the MemTest module
of TianoCore, that could be offered to sysadmin via UEFI Shell of
UEFI-enabled GRUB/rEFInd. Installers can start to improve UEFI- and
BIOS-based diagnostics today with UEFI Shell, memtests, BITS, FWTS,
...and eventually CHIPSEC. Today, the "ALT Linux Rescue" distro includes
UEFI Shell. Multiple rescue-centric distros include memtest, most are
BIOS-based last time I checked.
http://wiki.phoenix.com/wiki/index.php/EFI_MEMORY_TYPE
https://aur.archlinux.org/packages/memtest86-efi/