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