[DSE-Dev] refpolicy for wheezy

[Russell Coker]

On Sun, 10 Jun 2012, Mika Pflüger <debian at mikapflueger.de> wrote:
> Okay, I have prepared the package. You can get the updated version from
> http://git.hemio.de/git/refpolicy-debian or alternatively I can provide
> a .dsc and .debian.tar.gz.
> It would be great if one of you could review it and upload it if you
> agree. Note that I changed the maintainer to the alioth team and moved
> Russel to Uploaders. Is this the correct, Russel?

I have just built it from your source and uploaded it.  I have removed Erich 
and Manoj from the Uploaders line because Manoj hasn't been involved with 
Debian for ages and Erich doesn't seem to have done SE Linux stuff for ages.

Erich is still a member of this group and it doesn't seem like Manoj will be 
returning to Debian.

I don't know why I need to be in the Uploaders line as I'm a member of the 
Alioth group, but I left my name in.

> I diffed the contents of all the resulting binary packages against the
> versions currently in sid/testing and there were some differences:
> 1. Different changelogs (obviously)
> 2. Different gzipped and tarred things (I therefore diffed the untarred
>    and gunzipped files, which were identical)
> 3. One .pyc, where I think shipping it is a bug anyway (filed as
>    #676852)

Sounds like a bug.  Is there a Python expert here who can fix it?

> 4. All compiled policy module packages (.pp) had the same difference in
>    the first few bytes. It turns out this is due to compiling with the
>    newer checkpolicy version now in the archive - When comparing a
>    rebuilt -3 package against the new -4 (instead of the -3 currently
>    in the archive), there are no differences.

Good work!

> 1 and 2 are non-issues, 3 is irrelevant as well, imho. Regarding 4, I
> think we have to live with it - any binNMU of refpolicy or any other
> trivial bug fix that triggers recompilation would result in these
> changes. So if they trigger new obscure bugs (which is rather unlikely,
> I guess it is just the embedded version of the checkpolicy with which it
> was compiled) we want to trigger them now, not later.

The current dependencies for selinux-policy-default are newer versions of 
libraries and utils than are available in Squeeze.  So anyone who does a 
direct upgrade from Squeeze to Wheezy will get the latest Wheezy versions and 
thus these version differences won't prevent loading a Wheezy policy on a 
system that is being upgraded from Squeeze.  One thing I will test soon is 
whether the current policy works with a Squeeze kernel as part of the upgrade 
plan is that every policy will work with the kernel and most of the user-space 
from the previous release.

But the next time one of us updates the policy packages we should change the 
dependencies to include the Wheeze versions just to make things neat.

> Ah, true. Somehow, last time I looked at the process to get an alioth
> account, it was more elaborate. Thanks for the hint, now it was really
> easy - I already applied to join the SELinux team so if you approve the
> application I could actually push the git tree to the url that is now
> referenced by the Vcs-* fields.

I've added you, please do this.  Apart from changing the changelog and control 
files I changed nothing for the new version.

> If you have comments (even without an immediate patch, just some 'I
> think you should look at this again' style comments), please send them I
> will be happy to investigate.

We are currently at the stage in development where any changes that won't 
break things should just be uploaded.  So for any changes to the way the 
patches are managed, dependency updates, etc just upload the package without 
waiting.  We need to just get things done.

It got to this situation mostly because of my lack of time, sorry about that.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/