[Freeipa-devel] [PATCH] 6 - Dogtag DRM -IPA plugin

[Ade Lee]

I have not addressed Rob's comments here yet, but will do so in a later
patch.  We are most likely a couple weeks or so away from landing these
patches and we can work on rejiggering/squashing them then.

To help folks review the patches without getting merge issues, and so
that I don't have to worry about rebases until we get closer to the time
we want to commit these patches, I have exposed a repo with the patches
committed so reviewers can pull the patches, or start to work with them.

This is what Endi did to pull my patches:

$ git remote add vakwetu git://fedorapeople.org/home/fedora/vakwetu/public_git/freeipa.git
$ git checkout -b alee_0414_drm_add vakwetu/alee_0414_drm_add

Note that there is a change which I am currently designing to provide a
top level baseDN which will affect these patches.

Ade

On Thu, 2014-05-29 at 11:15 -0400, Rob Crittenden wrote:
> Petr Viktorin wrote:
> > On 05/28/2014 08:48 AM, Fraser Tweedale wrote:
> >> On Tue, May 27, 2014 at 05:57:40PM -0400, Ade Lee wrote:
> >>> There have been a couple of changes in the Dogtag interface, that
> >>> require some changes in the IPA patches.  Also, I had to add back a
> >>> function in order to rebase to the latest IPA code.
> >>>
> >>> Most are the patches are as before, attached to this email by default.
> >>>
> >>> The latest Dogtag 10.2 build with the relevant changes needed to work
> >>> with these patches is at:
> >>> http://copr.fedoraproject.org/coprs/vakwetu/dogtag/
> >>>
> >>> Ade
> >>>
> >>
> >> ACK.
> >>
> >> ipa-server-install worked fine for me, and the formatting changes
> >> seem good.  Patch 0003 did not apply cleanly on master (due to minor
> >> conflict in 71c6d2f:installutils.py); an updated patch 0003 is
> >> attached.
> > 
> > Hello,
> > If you do a rebase, could you attach all the patches again?
> > I don't have the Git objects that result from the original patch, so
> > `git am` fails on the later patches:
> > 
> > $ git am -3 *.patch
> > Applying: Add a DRM to IPA
> > Applying: Added ipa-drm-install
> > Applying: Fix various pep 8 issues and comments from review
> > Applying: Added nolog to pkispawn and some additional fixes from review.
> > Applying: Added dogtag plugin for DRM
> > Applying: set drm to not install by default with ipa-server-install
> > Applying: Allow ipa-replica-install to be used for installing replicas
> > error: invalid object 100755 0385a823baa971b0e08d1d93d7409b7a7716e33b
> > for 'install/tools/ipa-replica-install'
> > fatal: git-write-tree: error building trees
> > Repository lacks necessary blobs to fall back on 3-way merge.
> > Cannot fall back to three-way merge.
> > Patch failed at 0007 Allow ipa-replica-install to be used for installing
> > replicas
> > The copy of the patch that failed is found in:
> >    /home/pviktori/freeipa/.git/rebase-apply/patch
> > When you have resolved this problem, run "git am --continue".
> > If you prefer to skip this patch, run "git am --skip" instead.
> > To restore the original branch and stop patching, run "git am --abort".
> > 
> 
> I needed to rebase patche 9 as well as it contained a duplicate
> function, check_entropy. No need to rebase it again yet as we have to
> wait to push these until after a future branch anyway.
> 
> Speaking of patch 9, it appears to be all formatting and spelling fixes,
> not all related to the DRM. Patch 4 does similar work. If we're going to
> commit these all separately anyway, is it worthwhile to combine these
> two? Something (or someone) is mighty picky about thru vs through too :-)
> 
> The DRM patches should all have a ticket referenced. At a minimum the
> first one (0002 in this case).
> 
> I think 0007 can be rebased into an existing patch unless we want to
> record in history that the default stance changed.
> 
> Found a place that needs a change. The script
> install/restart_scripts/renew_ca_cert handles fixing the trust on the
> audit cert after renewal. This needs to update the DRM audit cert trust
> as well. Be aware that Honza is making significant changes to this area.
> 
> Otherwise looks ok to me. I'm not super-firm on squashing some of the
> patches, I just don't know what historical benefit might be gained from
> keeping them separate.
> 
> rob
> 
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel