[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#990990: unblock: libcgroup/2.0



On 7/12/21 2:51 PM, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: unblock
> 
> Background:
> https://www.debian.org/releases/testing/amd64/release-notes/ch-information.en.html#openstack-cgroups
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959022#66
> 
> I noticed a version of libcgroup with support for control groups v2
> is now in experimental.
> 
> Given then known problems with the libcgroup currently in bullseye
> (it only works when booting with special kernel parameters),
> this bug is a question to the release team and the OpenStack
> maintainer whether updating libcgroup in bullseye to the version
> currently in experimental might be the smaller evil compared
> to the current release notes approach.
> 
> 
> Complete diffstat compared to the version in testing:
>  223 files changed, 73421 insertions(+), 34626 deletions(-)
> Diff of debian/ is attached.
> 
> The new version adds autopkgtests, but they aren't currently run:
>   SKIP Test requires machine-level isolation but testbed does not provide that
> 
> No new bugs are reported in the BTS.
> 
> Tnd the debdiff of debian/ looks sane, except for a 12 -> 13 dh compat
> bump that is revertable if requested.
> 
> Both libcgroup1.symbols and abidiff of the shared library look sane.
> 
> There are new libraries (libcgset and libcgroupfortesting) that are unused.
> They lack .so symlinks in libcgroup-dev, which is an easily fixable bug.
> 
> The only package currently linked with libcgroup1 in bullseye
> is clsync (OpenStack uses cgroup-tools), debdiff and diffoscope
> find no code changes when rebuilding with libcgroup from experimental.
> 

Hi,

I very much would prefer if libcgroup/2.0 could be in Bullseye, and
avoid having to set these kernel parameters at boot time. It's even more
annoying because Debian probably will be the only distro in the world to
have the bad combination of component mandating these kernel parameters,
making it the least convenient platform to run cgroups v1.

So yeah, by all means, let's get things fixed!

Cheers,

Thomas Goirand (zigo)


Reply to: