Debian FTP Masters
2018-Aug-23  17:19 UTC
[Pkg-xen-devel] xen_4.11.1~pre+1.733450b39b-1~exp1_multi.changes REJECTED
xen source: lintian output: 'license-problem-gfdl-invariants stubdom/grub.patches/00cvs invariant part is: with no invariant sections, with the front-cover texts being a gnu manual, and with the back-cover texts as in (a) below', automatically rejected package. xen source: If you have a good reason, you may override this lintian tag. xen-utils-4.11: lintian output: 'statically-linked-binary usr/lib/xen-4.11/boot/xen-shim', automatically rejected package. xen-utils-4.11: If you have a good reason, you may override this lintian tag. binary:libxen-4.11 is NEW. binary:xen-hypervisor-4.11-amd64 is NEW. binary:xen-hypervisor-4.11-arm64 is NEW. binary:xen-hypervisor-4.11-armhf is NEW. binary:xen-hypervisor-common is NEW. binary:xen-utils-4.11 is NEW. binary:xen-hypervisor-common is NEW. binary:xen-hypervisor-4.11-amd64 is NEW. binary:xen-utils-4.11 is NEW. binary:libxen-4.11 is NEW. == Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns.
Ian Jackson
2018-Aug-23  17:59 UTC
[Pkg-xen-devel] xen_4.11.1~pre+1.733450b39b-1~exp1_multi.changes REJECTED
Debian FTP Masters writes
("xen_4.11.1~pre+1.733450b39b-1~exp1_multi.changes
REJECTED"):> xen source: lintian output: 'license-problem-gfdl-invariants
stubdom/grub.patches/00cvs invariant part is: with no invariant sections, with
the front-cover texts being a gnu manual, and with the back-cover texts as in
(a) below', automatically rejected package.
> xen source: If you have a good reason, you may override this lintian tag.
> xen-utils-4.11: lintian output: 'statically-linked-binary
usr/lib/xen-4.11/boot/xen-shim', automatically rejected package.
> xen-utils-4.11: If you have a good reason, you may override this lintian
tag.
I uploaded this despite the gdfl thing because stretch is no better.
Really that should be dealt with upstream.  For now I think it would
be possible to do some violence to the offending file (which is a diff
to an ancient version of grub).
I hadn't appreciated that the shim thing would cause a REJECTion.
That clearly needs to be overridden.
Hans, can you delete the parts of the 00cvs that edit the texinfo
document, and provide a filtered upstream git branch for us to make
the git tarball from ?  We can then rebase onto that.
The patch you use to delete that can probably go upstream.  Or at
least, we can try.
Ian.
-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my
own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Hans van Kranenburg
2018-Aug-23  18:48 UTC
[Pkg-xen-devel] xen_4.11.1~pre+1.733450b39b-1~exp1_multi.changes REJECTED
On 08/23/2018 07:59 PM, Ian Jackson wrote:> Debian FTP Masters writes ("xen_4.11.1~pre+1.733450b39b-1~exp1_multi.changes REJECTED"): >> xen source: lintian output: 'license-problem-gfdl-invariants stubdom/grub.patches/00cvs invariant part is: with no invariant sections, with the front-cover texts being a gnu manual, and with the back-cover texts as in (a) below', automatically rejected package. >> xen source: If you have a good reason, you may override this lintian tag. >> xen-utils-4.11: lintian output: 'statically-linked-binary usr/lib/xen-4.11/boot/xen-shim', automatically rejected package. >> xen-utils-4.11: If you have a good reason, you may override this lintian tag. > > I uploaded this despite the gdfl thing because stretch is no better. > Really that should be dealt with upstream. For now I think it would > be possible to do some violence to the offending file (which is a diff > to an ancient version of grub). > > I hadn't appreciated that the shim thing would cause a REJECTion. > That clearly needs to be overridden.I'll have a look at that.> Hans, can you delete the parts of the 00cvs that edit the texinfo > document, and provide a filtered upstream git branch for us to make > the git tarball from ? We can then rebase onto that.Yes.> The patch you use to delete that can probably go upstream. Or at > least, we can try.Hans