| Message ID | 20200414152528.20758-1-matthew.weber@rockwellcollins.com |
|---|---|
| Headers | show |
| Series | Bump of SElinux related libs/tools to 3.0 | expand |
On Tue, 14 Apr 2020 10:25:20 -0500 Matt Weber <matthew.weber@rockwellcollins.com> wrote: > - Switches to using the date (i.e. 20191204) abased release tagging > for better alignment with https://release-monitoring.org/project/01717/ > > - Added selinux-python which was missed in the v2 of this bump by > Adam (http://patchwork.ozlabs.org/project/buildroot/list/?series=156673) I am not sure I like the change to using the single big tarball with everything included, and then have each individual package build its own sub-directory. They ship individual tarballs, it seems a lot better to use that. Is the only benefit of that change the fact that it will match with what release monitoring says ? Even Fedora, who is the original project using release-monitoring uses the real version numbers for SELinux: $ rpm -qa | grep libselinux libselinux-utils-2.9-5.fc31.x86_64 libselinux-2.9-5.fc31.i686 libselinux-devel-2.9-5.fc31.x86_64 libselinux-2.9-5.fc31.x86_64 So to me, it seems like we should instead change the versions reported by release-monitoring.org instead. Best regards, Thomas
Thomas, On Tue, Apr 14, 2020 at 11:25 AM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > On Tue, 14 Apr 2020 10:25:20 -0500 > Matt Weber <matthew.weber@rockwellcollins.com> wrote: > > > - Switches to using the date (i.e. 20191204) abased release tagging > > for better alignment with https://release-monitoring.org/project/01717/ > > > > - Added selinux-python which was missed in the v2 of this bump by > > Adam (http://patchwork.ozlabs.org/project/buildroot/list/?series=156673) > > I am not sure I like the change to using the single big tarball with > everything included, and then have each individual package build its > own sub-directory. They ship individual tarballs, it seems a lot better > to use that. > > Is the only benefit of that change the fact that it will match with > what release monitoring says ? Correct. If we do stay with the x.y instead, I think it still makes sense to use the $(LIBSELINUX_VERION) across all those packages as the bumps should always be the same version for those 7 packages. > > Even Fedora, who is the original project using release-monitoring uses > the real version numbers for SELinux: > > $ rpm -qa | grep libselinux > libselinux-utils-2.9-5.fc31.x86_64 > libselinux-2.9-5.fc31.i686 > libselinux-devel-2.9-5.fc31.x86_64 > libselinux-2.9-5.fc31.x86_64 > > So to me, it seems like we should instead change the versions reported > by release-monitoring.org instead. Is there a way to reorder the versions on release monitoring instead? As it just happens the dates end up at the top of the list https://release-monitoring.org/project/01717/ Matt
Hello, +Yann, Arnout, Adam. On Tue, 14 Apr 2020 12:20:40 -0500 Matthew Weber <matthew.weber@collins.com> wrote: > > Is the only benefit of that change the fact that it will match with > > what release monitoring says ? > > Correct. If we do stay with the x.y instead, I think it still makes > sense to use the $(LIBSELINUX_VERION) across all those packages as the > bumps should always be the same version for those 7 packages. I never remember what are the rules to share a package <pkg>_VERSION variable with other packages. For example for mesa3d/mesa3d-headers, we do not share the version information, we duplicate it: # Not possible to directly refer to mesa3d variables, because of # first/second expansion trickery... MESA3D_HEADERS_VERSION = 20.0.4 But in protobuf/python-protobuf: # When bumping this package, make sure to also verify if the # python-protobuf package still works, as they share the same # version/site variables. PROTOBUF_VERSION = 3.11.4 PYTHON_PROTOBUF_VERSION = $(PROTOBUF_VERSION) PYTHON_PROTOBUF_SOURCE = protobuf-python-$(PYTHON_PROTOBUF_VERSION).tar.gz PYTHON_PROTOBUF_SITE = $(PROTOBUF_SITE) Here we share the version number. Yann, Arnout, could you re-explain this ? :-) > > So to me, it seems like we should instead change the versions reported > > by release-monitoring.org instead. > > Is there a way to reorder the versions on release monitoring instead? > As it just happens the dates end up at the top of the list > https://release-monitoring.org/project/01717/ I have filled in a bug report at https://github.com/fedora-infra/anitya/issues/897 about this. I *believe* that with the current description of the project, only semantic versions should be displayed, because a prefix of libselinux- for the tags is specified. So it should filter the tags that have the form libselinux-<something>, and extract the <something>. The other versions that are there might date back from when this was not specified, and need to be purged. Overall, I'll mark your series as Changes Requested. I would suggest to bump to 3.0, without sharing the version for now, so that we can get the 3.0 version bump merged soon. Thanks! Thomas
On 15/04/2020 07:43, Thomas Petazzoni wrote: > Hello, > > +Yann, Arnout, Adam. > > On Tue, 14 Apr 2020 12:20:40 -0500 > Matthew Weber <matthew.weber@collins.com> wrote: > >>> Is the only benefit of that change the fact that it will match with >>> what release monitoring says ? >> >> Correct. If we do stay with the x.y instead, I think it still makes >> sense to use the $(LIBSELINUX_VERION) across all those packages as the >> bumps should always be the same version for those 7 packages. > > I never remember what are the rules to share a package <pkg>_VERSION > variable with other packages. You can only do that if it's included from a place that guarantees the ordering, like e.g. for qt5: package/qt5/qt5.mk sets the version and *then* include's package/qt5/qt5base/qt5base.mk. In any other case, it should be duplicated. > For example for mesa3d/mesa3d-headers, we > do not share the version information, we duplicate it: > > # Not possible to directly refer to mesa3d variables, because of > # first/second expansion trickery... > MESA3D_HEADERS_VERSION = 20.0.4 > > But in protobuf/python-protobuf: > > # When bumping this package, make sure to also verify if the > # python-protobuf package still works, as they share the same > # version/site variables. > PROTOBUF_VERSION = 3.11.4 > > PYTHON_PROTOBUF_VERSION = $(PROTOBUF_VERSION) This *accidentally* works because we sort the included files in the top-level Makefile and protobuf < python-protobuf. It's a pretty dangerous thing to do though. > PYTHON_PROTOBUF_SOURCE = protobuf-python-$(PYTHON_PROTOBUF_VERSION).tar.gz > PYTHON_PROTOBUF_SITE = $(PROTOBUF_SITE) > > Here we share the version number. > > Yann, Arnout, could you re-explain this ? :-) > >>> So to me, it seems like we should instead change the versions reported >>> by release-monitoring.org instead. >> >> Is there a way to reorder the versions on release monitoring instead? >> As it just happens the dates end up at the top of the list >> https://release-monitoring.org/project/01717/ > > I have filled in a bug report at > https://github.com/fedora-infra/anitya/issues/897 about this. I > *believe* that with the current description of the project, only > semantic versions should be displayed, because a prefix of libselinux- > for the tags is specified. So it should filter the tags that have the > form libselinux-<something>, and extract the <something>. The other > versions that are there might date back from when this was not > specified, and need to be purged. > > Overall, I'll mark your series as Changes Requested. I would suggest to > bump to 3.0, without sharing the version for now, so that we can get > the 3.0 version bump merged soon. Ack, no sharing of versions please. Note that I have a vague idea of how we may be able to share versions (+ some other features). It is currently not possible because the _VERSION is used (indirectly) in some rules and conditions in the expansion of inner-generic-package. So my idea was to delay expansion of inner-generic-package until after all the packages have been included. This would also make it possible, for instance, to override a package version in a br2_external, and indeed modify any package variable in the external. And it would also make it possible to limit the expansion to just what is specified in PACKAGES, which would speed up the `make` invocation significantly (I estimate a factor of two). Regards, Arnout
Arnout, Thomas, All, On 2020-04-15 09:40 +0200, Arnout Vandecappelle spake thusly: > On 15/04/2020 07:43, Thomas Petazzoni wrote: > > On Tue, 14 Apr 2020 12:20:40 -0500 > > I never remember what are the rules to share a package <pkg>_VERSION > > variable with other packages. > You can only do that if it's included from a place that guarantees the > ordering, like e.g. for qt5: package/qt5/qt5.mk sets the version and *then* > include's package/qt5/qt5base/qt5base.mk. > In any other case, it should be duplicated. Yep. > > For example for mesa3d/mesa3d-headers, we > > do not share the version information, we duplicate it: > > > > # Not possible to directly refer to mesa3d variables, because of > > # first/second expansion trickery... > > MESA3D_HEADERS_VERSION = 20.0.4 > > > > But in protobuf/python-protobuf: > > > > # When bumping this package, make sure to also verify if the > > # python-protobuf package still works, as they share the same > > # version/site variables. > > PROTOBUF_VERSION = 3.11.4 > > > > PYTHON_PROTOBUF_VERSION = $(PROTOBUF_VERSION) > > This *accidentally* works because we sort the included files in the top-level > Makefile and protobuf < python-protobuf. It's a pretty dangerous thing to do though. Agreed. This should be fixed so that the version is duplicated, like is done for mesa3d. [--SNIP--] > > Overall, I'll mark your series as Changes Requested. I would suggest to > > bump to 3.0, without sharing the version for now, so that we can get > > the 3.0 version bump merged soon. > Ack, no sharing of versions please. Agreed. > Note that I have a vague idea of how we may be able to share versions (+ some > other features). It is currently not possible because the _VERSION is used > (indirectly) in some rules and conditions in the expansion of > inner-generic-package. So my idea was to delay expansion of > inner-generic-package until after all the packages have been included. This > would also make it possible, for instance, to override a package version in a > br2_external, and indeed modify any package variable in the external. And it > would also make it possible to limit the expansion to just what is specified in > PACKAGES, which would speed up the `make` invocation significantly (I estimate a > factor of two). When I had implemeted that years ago as a proof-of-concept, the speedup was not that noticeable in the end. The issue is that you can't easily just expand enabled packages, because then you'd miss on some variables that are defined by the target variant, but used by the host variant. Allowing for that would require carefully choosing what variables get defined early, and which would get postponed. And typically, for VERSION, you want it to be evaluated late, so it can be overriden in a br2-external. And since the hsopt vairant inherits its version from the taget variant, you still have to evaluate the target variant first. So basically, no speedup... But maybe I missed something... Regards, Yann E. MORIN.
- Switches to using the date (i.e. 20191204) abased release tagging for better alignment with https://release-monitoring.org/project/01717/ - Added selinux-python which was missed in the v2 of this bump by Adam (http://patchwork.ozlabs.org/project/buildroot/list/?series=156673) Tested with the following reduced configuration for legal info and build. BR2_aarch64=y BR2_TOOLCHAIN_EXTERNAL=y BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.16.7" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/aarch64-virt/linux.config" BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y BR2_PACKAGE_POLICYCOREUTILS=y BR2_PACKAGE_RESTORECOND=y BR2_PACKAGE_SELINUX_PYTHON=y BR2_PACKAGE_SELINUX_PYTHON_AUDIT2ALLOW=y BR2_PACKAGE_SETOOLS=y BR2_TARGET_ROOTFS_EXT2=y # BR2_TARGET_ROOTFS_TAR is not set Adam Duskett (7): package/libselinux: bump version to 3.0 package/libsemanage: bump version to 3.0 package/libsepol: bump version to 3.0 package/policycoreutils: bump version to 3.0 package/restorecond: bump version to 3.0 package/semodule-utils: bump version to 3.0 package/checkpolicy: bump version to 3.0 Matt Weber (1): package/selinux-python: bump to version 3.0 package/checkpolicy/checkpolicy.hash | 9 +- package/checkpolicy/checkpolicy.mk | 8 +- package/libselinux/0001-fix-musl-build.patch | 22 +- ...-and-rely-on-the-installed-file-nam.patch} | 14 +- ...ng-against-musl-and-uclibc-libraries.patch | 32 +++ ...ython-distutils-to-install-SELinux-p.patch | 207 ------------------ ...-t-pass-bogus-I-and-L-to-python-setu.patch | 34 --- package/libselinux/libselinux.hash | 9 +- package/libselinux/libselinux.mk | 29 +-- package/libsemanage/libsemanage.hash | 5 +- package/libsemanage/libsemanage.mk | 20 +- .../libsepol/0001-support-static-only.patch | 6 +- package/libsepol/Config.in | 3 +- package/libsepol/libsepol.hash | 9 +- package/libsepol/libsepol.mk | 8 +- ...-all-paths-that-use-an-absolute-path.patch | 6 +- .../0002-Add-PREFIX-to-host-paths.patch | 12 +- package/policycoreutils/policycoreutils.hash | 7 +- package/policycoreutils/policycoreutils.mk | 8 +- package/restorecond/restorecond.hash | 9 +- package/restorecond/restorecond.mk | 8 +- package/selinux-python/selinux-python.hash | 9 +- package/selinux-python/selinux-python.mk | 8 +- package/semodule-utils/semodule-utils.hash | 9 +- package/semodule-utils/semodule-utils.mk | 8 +- 25 files changed, 146 insertions(+), 353 deletions(-) rename package/libselinux/{0006-Do-not-use-PYCEXT-and-rely-on-the-installed-file-nam.patch => 0002-Do-not-use-PYCEXT-and-rely-on-the-installed-file-nam.patch} (89%) create mode 100644 package/libselinux/0003-fix-building-against-musl-and-uclibc-libraries.patch delete mode 100644 package/libselinux/0003-libselinux-Use-Python-distutils-to-install-SELinux-p.patch delete mode 100644 package/libselinux/0004-src-Makefile-don-t-pass-bogus-I-and-L-to-python-setu.patch