RE: EFI stack update sponsor
> -----Original Message-----
> From: Steve McIntyre [mailto:firstname.lastname@example.org]
> Sent: Thursday, September 1, 2016 11:22 AM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: email@example.com; firstname.lastname@example.org
> Subject: Re: EFI stack update sponsor
> On Thu, Sep 01, 2016 at 03:01:02PM +0100, Steve McIntyre wrote:
> >On Wed, Aug 31, 2016 at 04:30:22PM +0000, Mario_Limonciello@Dell.com
> >>Recently lots of pieces of the EFI stack have had updates.
> >>I've staged a variety of updates on the various git repositories on the
> debian branch.
> >>efivar: 27-1
> I've added you as an uploader, signed and uploaded. Jared: I've also
> checked and added the Debian/0.23-2 signed tag for you. </prod>
> Also: *please* make sure that you keep the "upstream" branch updated too
> on git.d.o
> >>efibootmgr: 13-1
Yes, will make sure in the future.
> Same comments again.
> >>fwupdate: 8-1
> Again, please updats "upstream". Also, from lintian:
> W: fwupdate: systemd-service-file-missing-install-key
I missed that (I have lintian 2.5.43 on my box not 2.5.46).
That's actually intended that there isn't an Install key, it is called by
postinst for Debian, but can be one off done otherwise.
I've added an override for it.
> I've not uploaded yet - I'll see what you want to do first.
> >>fwupd: 0.7.3-1
> You've made changes beyond what's in the changelog - what exactly
> would you like uploading?
Sorry for that confusion. There was a report that s390x was failing the
test suite on Fedora. Since it wasn't uploaded yet in Debian I figured
may as well slip those fixes in as well.
I double checked that everything that should be in the changelog is now.
I also resolve the same lintian error on the fwupd services (intended there
> Also, looking further. I see a build-dep on libsmbios but that's only
> available for some arches (i386 amd64 ia64 lpia all). There's an
> upstream commit "trivial: Do not require libsmbios-devel on ARM" which
> suggests it's optional - could you update accordingly please?
> It would be helpful if you made things clearer on all the packages, in
> fact. A common workflow for a lot of Debian teams is to set the target
> release part of the changelog entry to "UNRELEASED" instead of
> "unstable" to make it clear that things aren't ready for
> release/upload, then as the *very* last thing before upload change
> that to "unstable".
OK, I'll switch over to this workflow for these packages as well going
forward. I didn't make the changes for the current versions to have
unstable -> UNRELEASED -> unstable, but going forward I will for