On sam., 2015-11-07 at 14:54 +0000, Ben Hutchings wrote:
> I've given this a quick review and found a few issues:
Thanks!
>
> 1. linux-grsec-{source,support} are included in debian/control but not
> built by debian/rules.real. I think these should be built; the latter
> will be needed to build metapackages as in linux-latest.
Done. Right now the package name is hardcoded in debian/rules.real, I'll see
if there's a way to get it from the configuration somehow (after I get more
info from the #3 and #4 replies).
>
> 2. udebs are included in debian/control but not built, and they should
> not be built. You can fix this by deleting or commenting-out
> debian/installer/{amd64,i386}/kernel-versions
Good point. I'm currently disabling them by
using DEBIAN_KERNEL_DISABLE_INSTALLER when running gencontrol.py. Thanks for
the pointer.
>
> 3. The changes to gencontrol.py and rules.real to disable most arch:all
> packages should depend on configuration, not the source package name.
> They would then be acceptable for inclusion on the master branch.
By “configuration”, I guess you mean stuff in debian/config/featureset-
grsec/defines? Unfortunately some of the stuff I touch in gencontrol.py and
rules.real is not run when featureset is defined, but is more generic than
that.
Or do you mean I would then modify debian/config/defines (and not the one
under the featureset-grsec folder) in src;linux-grsec?
>
> 4. There's no need to remove the templates for packages you don't
> build. However, if you leave them in place, you'll need to override
> do_extra() in gencontrol.py to omit the extra packages dependent on the
> configuration (as for (3)).
Ok, I'll check that. Again, what do you envision as configuration: a “source
package name” in debian/config/defines? Or even a boolean “grsec”? Or more
generic than that, a “build_extra” boolean?
>
> 5. CONFIG_X86_X32 should be disabled, since you've disabled the patch
> to make x32 support dependent on a kernel parameter.
Ok, done.
>
> 6. In debian/patches/features/all/grsec/gen-patch you can use the
> filterdiff -p1 to avoid assuming the path prefix will be 'b/'.
Thanks, done as well.
I've not yet pushed the local changes, I'll wait a bit for the replies.
Regards,
--
Yves-Alexis
Attachment:
signature.asc
Description: This is a digitally signed message part