Re: SE Linux packages
* Laurent Bigonville <email@example.com> wrote:
> I've put Jon Bernard (the maintainer libcgroup) of in the loop.
> On Wed, 20 Jun 2012 10:21:41 -0400, Russell Coker wrote:
> > On Mon, 25 Jun 2012, "Adam D. Barratt" <firstname.lastname@example.org>
> > wrote:
> > > On Mon, 2012-06-25 at 14:56 +1000, Russell Coker wrote:
> > > > http://packages.qa.debian.org/libc/libcgroup.html
> > > >
> > > > Currently I have a problem though, policycoreutils in testing
> > > > depends on libcgroup1 which isn't in testing.
> > >
> > > Really? Which architecture at you seeing that on? There shouldn't
> > > be any packages in testing which depend on libcgroup1, otherwise it
> > > wouldn't have managed to be removed.
> > >
> > > policycoreutils in unstable does indeed depend on libcgroup1; is
> > > that what you meant?
> > Sorry I made a mistake. I had a system accidentally getting the
> > Unstable version of policycoreutils.
> > But the situation in testing is actually worse in some ways now that
> > I have investigated it properly. /usr/sbin/seunshare is linked
> > against libcgroup1 but somehow the package doesn't depend on it. So
> > you can install the new package and get a binary that won't run!
> > > > According to the above a low priority
> > > > package was uploaded 5 days ago. Is it possible to get it back
> > > > into testing sooner so other packages that depend on it can be
> > > > installed? It's currently impossible to run SE Linux on a system
> > > > that's been upgraded from Squeeze to Testing due to this.
> > >
> > > $ grep-excuses libcgroup
> > > libcgroup (- to 0.38-1)
> > > Maintainer: Jon Bernard
> > > Too young, only 5 of 10 days old
> > > cgroup-bin (i386, amd64, armel, armhf, ia64, mips, mipsel,
> > > powerpc, s390, s390x, sparc) has new bugs! Updating cgroup-bin
> > > introduces new bugs: #618956
> > >
> > > Without a largish britney hammer, it's not going to migrate again
> > > until that bug is sorted out.
> > That bug is old and doesn't seem likely to be fixed soon. A SE Linux
> > system will work well enough without seunshare, should I just remove
> > that program so that policycoreutils can go through?
> This bug is actually fixed, I had a conversation with Jon about that he
> was waiting to be sure no one was complaining before closing the bugs.
> So libcgroup should will more than probably migrate in due time.
Yes, Laurent is correct. The recent upload fixed #618956. I was waiting for some
feedback before closing, but I didn't not know it was holding up the release.
I will close it now.
To summarize the recent upload: Aside from the new version, I've removed the
initscripts that attempt to classify processes into cgroups upon creation. In
theory it seems quite useful, but the implementation causes frustrating
behaviour for many non-trivial configurations. The scripts are still included in
the package, but not installed by default.
If this presents a problem for anyone, please let me know. I can put them back,
but my assertion is that they cause far more problems than they solve.