Hi Laurent,
On Sat, Dec 15, 2012 at 01:32:07PM +0100, Laurent Bigonville wrote:
> > On 2012-12-14 14:15, Laurent Bigonville wrote:
> > > The changes are quite big (changes to the build system),
> >
> > ...which make it already unsuitable for Wheezy.
> >
> > > but the package
> > > is pretty trivial (one arch all package) and it's easy to see
> > > unwanted
> > > changes (which I don't see).
> > >
> > > selinux-basics (0.5.1) UNRELEASED; urgency=low
> > >
> > > * Switch to dpkg-source 3.0 (native) format
> >
> > not acceptable [1]
> >
> > > * Switch to dh sequence and dh_python2
> >
> > not acceptable [1]
>
> There is no usage of a python helper ATM, is that better?
That not the point. The freeze policy doesn't accept this kind of change for
wheezy. If you include this change, the release team will simply reject your
package.
> > > * debian/control:
> > > - Bump Standards-Version to 3.9.3 (no further changes)
> > > - Add ${misc:Depends} to the dependencies
> > > - Update Vcs-* fields
> > > - Add X-Python-Version field
> > > - Put under the Debian SELinux team maintenance
> >
> > not acceptable [1]
> >
> > > * Remove udev rules, legacy ptys are not enabled in the kernel
> > > since squeeze
> > > (Closes: #622563)
> >
> > severity important for an optional package and could be done through
> > unstable [1], so just about OK on its own
>
> Surprisingly this is the only change here I was not 100% confident
> that would not cause a regression for /some/ users using a custom
> kernel (aka people that are compiling with the CONFIG_LEGACY_PTYS
> flag)..
The original bug report asked for the udev rule to be moved to a different
location. If you think the rule is still needed, you can do that instead of
removing it.
> > > * tests/21_pam.py: Fix detection whether selinux pam module is
> > > called from
> > > login service (Closes: #531660)
> >
> > not an RC bug.
>
> The 1/3 of the package functionality is made of tests to troubleshoot
> selinux installation and this is probably one of the most important
> test to be sure that the user will be running in the correct context.
If the bug severity is to low, increase it and explain why. If you do, the fix
might be acceptable.
> > > * Fix python 2.6 deprecations in several tests, thanks to Robert
> > > Bihlmeyer
> > > for the patches (Closes: #585354, #654608)
> >
> > not RC bugs.
>
> Well that should be RC then, I get a complain about the script not
> working no later than this morning. Isn't python >= 2.6 support
> mandatory for wheezy?
Again, if it is really an important issue, increase the severity and document
it.
> > > * Add debian/gbp.conf file
> >
> > not acceptable [1]
>
> This is only metadata for git-buildpackage, no functional changes,
> really who cares?
The release team.
> > > * tests/21_pam.py: Fix path of the pam service file
> >
> > could be RC, if only there was a bug to reference
>
> No user ever saw that the test was not working or bother to report.
Well, if you saw it, file a bug yourself (with appropriate severity).
> > > * tests/02_verify_slash_selinux.py: Add support
> > > for /sys/fs/selinux directory
> >
> > unlikely to be RC
>
> /sys/fs/selinux is the new location since wheezy for the securefs
> mountpoint, so yes I guess we want that.
Only if it fixes an important bug.
> > > * debian/selinux-basics.postinst: Only run update-grub if a
> > > configuration
> > > has been modified
> >
> > highly unlikely to be RC.
>
> Indeed that was just cosmetic.
Just remove this change.
> You might be tempted to RM this package from testing, just be aware
> that it (unfortunately) also contains an initscript that is doing
> relabeling during boot. Removing it would probably causes more troubles
> to people that would like to use selinux than doing any good.
Noone is asking for this package to be removed from wheezy. You still have
every opportunity to get your fixes included in wheezy.
> In the light of these new information, would anybody please advise me
> what would be accepted (which was more or less the point of this bug
> in the first place)?
First of all, read the freeze policy (you probably did that by now):
http://release.debian.org/wheezy/freeze_policy.html
All changes that are not directly related to fixing important bugs should wait
till after the release (or go into experimental, as you did with your upload
this morning). Don't try to get those into wheezy, because it will make it
more likely that all your changes will be rejected.
Create a package with only changes for important bugs. Document these changes
verbosely:
- Make sure there is a bug report which explains the problem and the severity.
If there is a bug report, you can increase the severity if the impact of the
problem is big enough. Explain this in the bug report. If there is no bug
report, file one yourself.
- Document the changes verbosely in the changelog, with reference to the bug
report (you did this already for most issues).
If you do this, I'm sure the release team will consider your request.
Cheers,
Ivo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
