From: Blibbet <blibbet@gmail.com>
To: chipsec@lists.01.org
Subject: Re: Debian packaging and D-I integration
Date: Mon, 27 Jul 2015 11:46:28 -0700 [thread overview]
Message-ID: <55B67C84.1010202@gmail.com> (raw)
In-Reply-To: <F2C8915217E2664AB33302D7A9ED9C0A22D5BA7D@hasmsx108.ger.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2662 bytes --]
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/
prev parent reply other threads:[~2015-07-27 18:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 17:55 Debian packaging and D-I integration Blibbet
2015-07-27 17:14 ` Loucaides, John
2015-07-27 17:42 ` Arrigo Triulzi
2015-07-27 17:47 ` Blibbet
2015-07-27 17:54 ` Loucaides, John
2015-07-27 18:46 ` Blibbet [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55B67C84.1010202@gmail.com \
--to=blibbet@gmail.com \
--cc=chipsec@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).