[Freeipa-devel] Karma Requests for pki-core-10.3.5-7 and pki-console-10.3.5-2

[Matthew Harmsen]

*The following updated candidate builds of pki-core 10.3.5 and 
pki-console 10.3.5 were generated:*


 * *Fedora 24*
 o *pki-core-10.3.5-7.fc24
   *
 o *pki-console-10.3.5-2.fc24
   
   *
 * *Fedora 25*
 o *pki-core-10.3.5-7.fc25
   *
 o *pki-console-10.3.5-2.fc25
   
   *
 * *Fedora 26*
 o *pki-core-10.3.5-7.fc26 (still working on build issues
   encountered on rawhide)*
 o *pki-console-10.3.5-2.fc26
   *

*Additionally, the CentOS 7 COPR EPEL Builds of Dogtag 10.3.3 were also 
updated:*


 * 
*https://copr.fedorainfracloud.org/coprs/g/pki/epel-7.3/repo/epel-7/group_pki-epel-7.3-epel-7.repo*
   



   [group_pki-epel-7.3]
   name=Copr repo for epel-7.3 owned by @pki
   
baseurl=https://copr-be.cloud.fedoraproject.org/results/@pki/epel-7.3/epel-7-$basearch/
   type=rpm-md
   skip_if_unavailable=True
   gpgcheck=1
   
gpgkey=https://copr-be.cloud.fedoraproject.org/results/@pki/epel-7.3/pubkey.gpg
   repo_gpgcheck=0
   enabled=1
   enabled_metadata=1

*These builds address the following PKI tickets:*

 * PKI TRAC Ticket #1527 - TPS Enrollment always goes to "ca1" (cfu)
   
 * PKI TRAC Ticket #1664 - [BUG] Add ability to disallow TPS to enroll
   a single user on multiple tokens. (jmagne)
   
 * PKI TRAC Ticket #2463 - Troubleshooting improvements (edewata)
   
 o potentially more to come in future releases
 * PKI TRAC Ticket #2466 - two-step externally-signed CA installation
   fails due to missing AuthorityID (ftweedal)
   
 * PKI TRAC Ticket #2475 - Multiple host authority entries created
   (ftweedal) 
 * PKI TRAC Ticket #2476 - Dogtag Miscellaneous Minor Changes (edewata)
   
 o potentially more to come in future releases
 * PKI TRAC Ticket #2478 - pkispawn fails as it is not able to find
   openssl as a dependency package (mharmsen)
   
 * PKI TRAC Ticket #2483 - Unable to read an encrypted email using
   renewed tokens (jmagne) 
 * PKI TRAC Ticket #2496 - Cert/Key recovery is successful when the
   cert serial number and key id on the ldap user mismatches (cfu)
   
 * PKI TRAC Ticket #2497 - KRA installation failed against
   externally-signed CA with partial certificate chain (edewata)
   
 * PKI TRAC Ticket #2505 - Fix packaging duplicates of classes in
   multiple jar files (edewata) 

*Please provide Karma for the following builds:*

 * *Fedora 24*
 o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-76fae7b25f
   pki-core-10.3.5-7.fc24
   *
 o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-a9e6c42783
   pki-console-10.3.5-2.fc24
   *
 * *Fedora 25*
 o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-3496056579
   pki-core-10.3.5-7.fc25*
 o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-70b3b8b697
   pki-console-10.3.5-2.fc25
   
   *

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#152][opened] Fix warnings reported by pylint in rawhide

[martbab]

   URL: https://github.com/freeipa/freeipa/pull/152
Author: martbab
 Title: #152: Fix warnings reported by pylint in rawhide
Action: opened

PR body:
"""
https://fedorahosted.org/freeipa/ticket/6391
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/152/head:pr152
git checkout pr152
From e3cb2e3d6f261913cfd9967f0c452a14dc38b8c1 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Tue, 11 Oct 2016 17:10:50 +0200
Subject: [PATCH 1/2] remove trailing newlines form python modules

pylint-1.6.4-1.fc26.noarch reports these, hence they should be fixed in order
to build FreeIPA with this version

https://fedorahosted.org/freeipa/ticket/6391
---
 checks/check-ra.py   | 1 -
 doc/examples/examples.py | 2 --
 install/tools/ipa-otptoken-import| 1 -
 ipalib/request.py| 1 -
 ipapython/log_manager.py | 2 --
 ipaserver/install/ipa_kra_install.py | 1 -
 ipaserver/plugins/batch.py   | 1 -
 ipaserver/plugins/delegation.py  | 1 -
 ipaserver/plugins/group.py   | 1 -
 ipaserver/plugins/hbacrule.py| 1 -
 ipaserver/plugins/hbacsvc.py | 1 -
 ipaserver/plugins/hbacsvcgroup.py| 1 -
 ipaserver/plugins/hostgroup.py   | 1 -
 ipaserver/plugins/idrange.py | 2 --
 ipaserver/plugins/passwd.py  | 1 -
 ipaserver/plugins/pkinit.py  | 1 -
 ipaserver/plugins/realmdomains.py| 1 -
 ipaserver/plugins/role.py| 1 -
 ipaserver/plugins/selfservice.py | 1 -
 ipaserver/plugins/selinuxusermap.py  | 1 -
 ipaserver/plugins/sudocmd.py | 1 -
 ipaserver/plugins/sudocmdgroup.py| 1 -
 ipaserver/plugins/trust.py   | 1 -
 ipatests/test_xmlrpc/test_hbactest_plugin.py | 1 -
 24 files changed, 27 deletions(-)

diff --git a/checks/check-ra.py b/checks/check-ra.py
index 6942804..63a53a2 100755
--- a/checks/check-ra.py
+++ b/checks/check-ra.py
@@ -128,4 +128,3 @@ def assert_equal(trial, reference):
 assert_equal(unrevoke_result,
  {'unrevoked' : True
   })
-
diff --git a/doc/examples/examples.py b/doc/examples/examples.py
index 3389230..35ebd82 100644
--- a/doc/examples/examples.py
+++ b/doc/examples/examples.py
@@ -438,5 +438,3 @@ def execute(self, *args, **options):
 # authors from doing all the dirty work. Let's take a look at them.
 
 # COMING SOON: baseldap.py classes, extending existing plugins, etc.
-
-
diff --git a/install/tools/ipa-otptoken-import b/install/tools/ipa-otptoken-import
index d6ae247..3309c33 100755
--- a/install/tools/ipa-otptoken-import
+++ b/install/tools/ipa-otptoken-import
@@ -21,4 +21,3 @@
 from ipaserver.install.ipa_otptoken_import import OTPTokenImport
 
 OTPTokenImport.run_cli()
-
diff --git a/ipalib/request.py b/ipalib/request.py
index d851ba8..5e5f019 100644
--- a/ipalib/request.py
+++ b/ipalib/request.py
@@ -77,4 +77,3 @@ def destroy_context():
 if isinstance(value, Connection):
 value.disconnect()
 context.__dict__.clear()
-
diff --git a/ipapython/log_manager.py b/ipapython/log_manager.py
index 0ab7a22..e24fed6 100644
--- a/ipapython/log_manager.py
+++ b/ipapython/log_manager.py
@@ -1556,5 +1556,3 @@ class name. All name components are dot seperated. Thus if the
 setattr(who, method, getattr(logger, method))
 
 return logger
-
-
diff --git a/ipaserver/install/ipa_kra_install.py b/ipaserver/install/ipa_kra_install.py
index 9cb5f0f..8801e30 100644
--- a/ipaserver/install/ipa_kra_install.py
+++ b/ipaserver/install/ipa_kra_install.py
@@ -226,4 +226,3 @@ def run(self):
 except:
 self.log.error(dedent(self.FAIL_MESSAGE))
 raise
-
diff --git a/ipaserver/plugins/batch.py b/ipaserver/plugins/batch.py
index b0c89ec..7a9930b 100644
--- a/ipaserver/plugins/batch.py
+++ b/ipaserver/plugins/batch.py
@@ -154,4 +154,3 @@ def execute(self, methods=None, **options):
 )
 results.append(result)
 return dict(count=len(results) , results=results)
-
diff --git a/ipaserver/plugins/delegation.py b/ipaserver/plugins/delegation.py
index 28a8f30..1e9665b 100644
--- a/ipaserver/plugins/delegation.py
+++ b/ipaserver/plugins/delegation.py
@@ -217,4 +217,3 @@ def execute(self, aciname, **kw):
 result=result,
 value=pkey_to_value(aciname, kw),
 )
-
diff --git a/ipaserver/plugins/group.py b/ipaserver/plugins/group.py
index f48a985..67a264a 100644
--- a/ipaserver/plugins/group.py
+++ b/ipaserver/plugins/group.py
@@ -689,4 +689,3 @@ def execute(self, *keys, **options):
 result=True,
 value=pkey_to_value(keys[0], options),
 )
-
diff --git a/ipaserver/plugins/hbacrule.py b/ipaserver/plugins/hbacrule.py
index 7d3e485..60e5e60 100644

[Freeipa-devel] [freeipa PR#132][comment] Draft for a new setup.py (WIP)

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/132
Title: #132: Draft for a new setup.py (WIP)

mbasti-rh commented:
"""
I cannot reinstall packages using your commits

```
dnf reinstall .rpm
...
Error: Transaction check error:
  file /usr/lib/python2.7/site-packages/ipalib-4.4.90-py2.7.egg-info from 
install of python2-ipalib-4.4.90-0.fc24.noarch conflicts with file from package 
python2-ipalib-4.4.90-0.fc24.noarch
  file /usr/lib/python2.7/site-packages/ipaplatform-4.4.90-py2.7.egg-info from 
install of python2-ipalib-4.4.90-0.fc24.noarch conflicts with file from package 
python2-ipalib-4.4.90-0.fc24.noarch
  file /usr/lib/python2.7/site-packages/ipapython-4.4.90-py2.7.egg-info from 
install of python2-ipalib-4.4.90-0.fc24.noarch conflicts with file from package 
python2-ipalib-4.4.90-0.fc24.noarch
  file /usr/lib/python2.7/site-packages/ipaclient-4.4.90-py2.7.egg-info from 
install of python2-ipaclient-4.4.90-0.fc24.noarch conflicts with file from 
package python2-ipaclient-4.4.90-0.fc24.noarch
  file /usr/lib/python3.5/site-packages/ipalib-4.4.90-py3.5.egg-info from 
install of python3-ipalib-4.4.90-0.fc24.noarch conflicts with file from package 
python3-ipalib-4.4.90-0.fc24.noarch
  file /usr/lib/python3.5/site-packages/ipaplatform-4.4.90-py3.5.egg-info from 
install of python3-ipalib-4.4.90-0.fc24.noarch conflicts with file from package 
python3-ipalib-4.4.90-0.fc24.noarch
  file /usr/lib/python3.5/site-packages/ipapython-4.4.90-py3.5.egg-info from 
install of python3-ipalib-4.4.90-0.fc24.noarch conflicts with file from package 
python3-ipalib-4.4.90-0.fc24.noarch
  file /usr/lib/python3.5/site-packages/ipaclient-4.4.90-py3.5.egg-info from 
install of python3-ipaclient-4.4.90-0.fc24.noarch conflicts with file from 
package python3-ipaclient-4.4.90-0.fc24.noarch
  file /usr/lib/python3.5/site-packages/ipatests-4.4.90-py3.5.egg-info from 
install of python3-ipatests-4.4.90-0.fc24.noarch conflicts with file from 
package python3-ipatests-4.4.90-0.fc24.noarch
  file /usr/lib/python2.7/site-packages/ipatests-4.4.90-py2.7.egg-info from 
install of python2-ipatests-4.4.90-0.fc24.noarch conflicts with file from 
package python2-ipatests-4.4.90-0.fc24.noarch

```
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/132#issuecomment-252978511
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#146][+pushed] WebUI: fix API Browser menu label

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/146
Title: #146: WebUI: fix API Browser menu label

Label: +pushed
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#146][comment] WebUI: fix API Browser menu label

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/146
Title: #146: WebUI: fix API Browser menu label

mbasti-rh commented:
"""
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/28c7644980186f50ee007cd5c2f2edcf103eb942
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/146#issuecomment-252950758
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#146][closed] WebUI: fix API Browser menu label

[mbasti-rh]

   URL: https://github.com/freeipa/freeipa/pull/146
Author: pvomacka
 Title: #146: WebUI: fix API Browser menu label
Action: closed

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/146/head:pr146
git checkout pr146
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#146][+ack] WebUI: fix API Browser menu label

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/146
Title: #146: WebUI: fix API Browser menu label

Label: +ack
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#140][edited] Tests: Fix cert revocation tests

[mbasti-rh]

   URL: https://github.com/freeipa/freeipa/pull/140
Author: mirielka
 Title: #140: Tests: Fix cert revocation tests
Action: edited

 Changed field: title
Original value:
"""
Tests: Remove invalid certplugin tests
"""

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#136][comment] Fix KRA install tests

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/136
Title: #136: Fix KRA install tests

mbasti-rh commented:
"""
Self NACK, I should not remove tests, I have to fix tasks.py to install replica 
properly with KRA, because we actually support --setup-kra option
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/136#issuecomment-252943729
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#133][comment] Tests: print what was expected from exceptions and callables in xmlrpc_tests

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/133
Title: #133: Tests: print what was expected from exceptions and callables in 
xmlrpc_tests

mbasti-rh commented:
"""
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/8683cbf1242230fff8cd94da8aa27b27e9307535
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/133#issuecomment-252941044
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#133][+pushed] Tests: print what was expected from exceptions and callables in xmlrpc_tests

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/133
Title: #133: Tests: print what was expected from exceptions and callables in 
xmlrpc_tests

Label: +pushed
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#133][closed] Tests: print what was expected from exceptions and callables in xmlrpc_tests

[mbasti-rh]

   URL: https://github.com/freeipa/freeipa/pull/133
Author: pspacek
 Title: #133: Tests: print what was expected from exceptions and callables in 
xmlrpc_tests
Action: closed

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/133/head:pr133
git checkout pr133
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#133][+ack] Tests: print what was expected from exceptions and callables in xmlrpc_tests

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/133
Title: #133: Tests: print what was expected from exceptions and callables in 
xmlrpc_tests

Label: +ack
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#144][+pushed] Pylint: remove unused values - the last part

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/144
Title: #144: Pylint: remove unused values - the last part

Label: +pushed
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#144][closed] Pylint: remove unused values - the last part

[mbasti-rh]

   URL: https://github.com/freeipa/freeipa/pull/144
Author: mbasti-rh
 Title: #144: Pylint: remove unused values - the last part
Action: closed

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/144/head:pr144
git checkout pr144
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#144][comment] Pylint: remove unused values - the last part

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/144
Title: #144: Pylint: remove unused values - the last part

mbasti-rh commented:
"""
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/49b29591aa979560068449b78fd547915420ff08
https://fedorahosted.org/freeipa/changeset/4628522c532c6df0295308e5f749989c2536caa6
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/144#issuecomment-252940396
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#134][closed] DNS URI support

[mbasti-rh]

   URL: https://github.com/freeipa/freeipa/pull/134
Author: pspacek
 Title: #134: DNS URI support
Action: closed

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/134/head:pr134
git checkout pr134
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#134][+pushed] DNS URI support

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/134
Title: #134: DNS URI support

Label: +pushed
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#134][comment] DNS URI support

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/134
Title: #134: DNS URI support

mbasti-rh commented:
"""
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/f363dfbeed7aeba51d694a60b29389d94c7bda44
https://fedorahosted.org/freeipa/changeset/bf96b80200c3e8d1795a913db4e0222ea558e609
https://fedorahosted.org/freeipa/changeset/51af7a15981eca753dfbda133cc557d0512f6e95
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/134#issuecomment-252939875
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#134][+ack] DNS URI support

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/134
Title: #134: DNS URI support

Label: +ack
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Feature branches for sub-team efforts

[Alexander Bokovoy]

On ti, 11 loka 2016, Petr Vobornik wrote:

On 10/11/2016 03:50 PM, Alexander Bokovoy wrote:

On ti, 11 loka 2016, Petr Vobornik wrote:

Hi List,

we discussed locally a proposal about creating a feature branch for each
sub-team effort in our main git. Currently it would be for the 4 ongoing
refactoring efforts + Simo's work

Why?
It will allow each developer to create a pull request against the
feature branch and thus it will enable iterative development by multiple
devs without affecting other sub-teams. When the feature(refactoring) is
finished, the branch would be rebased on master and merged there. Note:
rebases can be done as needed - e.g. when other subteam finishes its
work.

Concerns:
1. Upstream git repo would be full of such branches.
- This can be mitigated by deleting the feature branches when their are
released or merged(up to discussion)

Don't put them in the upstream git repo. Let people decide where they
want to have them -- all Fedora contributors have access to
fedorapeople.org git hosting and there is github one button click
('Clone') away from the github mirror.

It is not a problem to keep a separate git branch published this way.



It is not a matter of making the code public. That can be done easily as
you write. Other alternative is own branch in GitHub fork.


May be I misunderstand you -- if you just want people to propose merge
requests on github with pre-defined names, then that's just fine.



Basically it's all about review.

Example use case: More than 1 devs are working on a same big effort.
This effort will probably consists of 10s of commits. The big effort is
divided into smaller ones which can be implemented and reviewed
separately. In our previous mode, the sub task would be merged to master
it is reviewed and ACKed. But now we cannot do that. We want to merge
the whole big task at once when it is finishes and tested.

One dev could probably have a branch on personal fork of FreeIPA on
GitHub which would work as the feature branch. Other team members would
create pull requests against it.

In such case we would loose mail notifications and would have to extend
our tooling because ipatool can use only one upstream on push.

So I still think this is not a problem. If people can agree which git
repo clone will be primary one and submit merge requests against it,
then there is no problem in having that git repo's branch to be
submitted as the pull request against the main git repo. This way you'll
get all the changes seen at the pull request sync time.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Feature branches for sub-team efforts

[Petr Vobornik]

On 10/11/2016 03:50 PM, Alexander Bokovoy wrote:
> On ti, 11 loka 2016, Petr Vobornik wrote:
>> Hi List,
>>
>> we discussed locally a proposal about creating a feature branch for each
>> sub-team effort in our main git. Currently it would be for the 4 ongoing
>> refactoring efforts + Simo's work
>>
>> Why?
>> It will allow each developer to create a pull request against the
>> feature branch and thus it will enable iterative development by multiple
>> devs without affecting other sub-teams. When the feature(refactoring) is
>> finished, the branch would be rebased on master and merged there. Note:
>> rebases can be done as needed - e.g. when other subteam finishes its
>> work.
>>
>> Concerns:
>> 1. Upstream git repo would be full of such branches.
>> - This can be mitigated by deleting the feature branches when their are
>> released or merged(up to discussion)
> Don't put them in the upstream git repo. Let people decide where they
> want to have them -- all Fedora contributors have access to
> fedorapeople.org git hosting and there is github one button click
> ('Clone') away from the github mirror.
> 
> It is not a problem to keep a separate git branch published this way.
> 

It is not a matter of making the code public. That can be done easily as
you write. Other alternative is own branch in GitHub fork.

> May be I misunderstand you -- if you just want people to propose merge
> requests on github with pre-defined names, then that's just fine.
> 

Basically it's all about review.

Example use case: More than 1 devs are working on a same big effort.
This effort will probably consists of 10s of commits. The big effort is
divided into smaller ones which can be implemented and reviewed
separately. In our previous mode, the sub task would be merged to master
it is reviewed and ACKed. But now we cannot do that. We want to merge
the whole big task at once when it is finishes and tested.

One dev could probably have a branch on personal fork of FreeIPA on
GitHub which would work as the feature branch. Other team members would
create pull requests against it.

In such case we would loose mail notifications and would have to extend
our tooling because ipatool can use only one upstream on push.

Pre-defined names for PRs is a good idea - we could easily see what
effort the pull request is related to.
-- 
Petr Vobornik

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#144][+ack] Pylint: remove unused values - the last part

[pvomacka]

  URL: https://github.com/freeipa/freeipa/pull/144
Title: #144: Pylint: remove unused values - the last part

Label: +ack
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#144][comment] Pylint: remove unused values - the last part

[pvomacka]

  URL: https://github.com/freeipa/freeipa/pull/144
Title: #144: Pylint: remove unused values - the last part

pvomacka commented:
"""
ACK.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/144#issuecomment-252929696
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Build system refactoring - design document

[Petr Spacek]

On 11.10.2016 15:47, Petr Vobornik wrote:
> On 10/07/2016 11:56 AM, Petr Spacek wrote:
>> Dear FreeIPA developers and packagers,
>>
>> you can find first version of the Build system refactoring design document 
>> on:
>> http://www.freeipa.org/page/V4/Build_system_refactoring
>>
>> If you do not care about implementation details, please be so kind and 
>> quickly
>> scan through chapter
>> http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management
>>
>> I'm not an FreeIPA packager so I might miss some important thing which needs
>> to be configurable.
>>
>>
>> Also, I would appreciate ideas how to handle build versioning:
>> http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning
>>
>> My main questions are:
>> * What is triggering IPA upgrade?
>> * Would it be sufficient to bump release in RPM? (I mean - theoretically.
>> Could the code be modified to detect this?)
>>
>> Here I'm trying to avoid unnecessary rebuilds caused by changes to
>> IPA_VENDOR_VERSION during each build.
>>
>>
>> Timo, what can I do to help you with packaging for Ubuntu/Debian?
>>
>> Dream big, even wild ideas are welcome!
>>
> 
> I'd like to add one use case which is a prerequisite for "packager":
> release engineer.
> 
> Currently, IPA is released by running
>   $ make IPA_VERSION_IS_GIT_SNAPSHOT=no rpms
> 
> Then tarball is copied from dist/sources to freeipa.org
> 
> http://www.freeipa.org/page/Release#Building_the_sources
> 
> With current code, it may be done only with:
>  $ make tarball
> 
> But it probably wasn't tested much so I'd not rely on it.
> 
> What I'd like to see:
> 
> Release engineer:
>  $ make dist
>  $ # copy tarball
> 
> Packager:
>  $ ./configure [--options]
>  $ make install
> 
> I think that this workflow is implied by "Automake: Standard Targets"
> but IMHO it should be specified in the design explicitly because it is a
> change in our process.

Fine with me. Please formulate your requirements to user stories and add them 
to:
http://www.freeipa.org/page/V4/Build_system_refactoring#User_stories

I will look at them after that.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#138][comment] Fix ipa-cacert-manage man page

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/138
Title: #138: Fix ipa-cacert-manage man page

mbasti-rh commented:
"""
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/eb75578cbb2447fc2fafb8a79d8500b27e3edff0
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/138#issuecomment-252925331
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#138][+pushed] Fix ipa-cacert-manage man page

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/138
Title: #138: Fix ipa-cacert-manage man page

Label: +pushed
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#138][closed] Fix ipa-cacert-manage man page

[mbasti-rh]

   URL: https://github.com/freeipa/freeipa/pull/138
Author: flo-renaud
 Title: #138: Fix ipa-cacert-manage man page
Action: closed

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/138/head:pr138
git checkout pr138
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#141][closed] Tests: Fix failing test_ipalib/test_parameters

[mbasti-rh]

   URL: https://github.com/freeipa/freeipa/pull/141
Author: mirielka
 Title: #141: Tests: Fix failing test_ipalib/test_parameters
Action: closed

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/141/head:pr141
git checkout pr141
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#141][+pushed] Tests: Fix failing test_ipalib/test_parameters

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/141
Title: #141: Tests: Fix failing test_ipalib/test_parameters

Label: +pushed
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#141][comment] Tests: Fix failing test_ipalib/test_parameters

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/141
Title: #141: Tests: Fix failing test_ipalib/test_parameters

mbasti-rh commented:
"""
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/c3e3130a35f05348405701731ec2d5b85a772997
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/141#issuecomment-252922588
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Feature branches for sub-team efforts

[Alexander Bokovoy]

On ti, 11 loka 2016, Petr Vobornik wrote:

Hi List,

we discussed locally a proposal about creating a feature branch for each
sub-team effort in our main git. Currently it would be for the 4 ongoing
refactoring efforts + Simo's work

Why?
It will allow each developer to create a pull request against the
feature branch and thus it will enable iterative development by multiple
devs without affecting other sub-teams. When the feature(refactoring) is
finished, the branch would be rebased on master and merged there. Note:
rebases can be done as needed - e.g. when other subteam finishes its work.

Concerns:
1. Upstream git repo would be full of such branches.
- This can be mitigated by deleting the feature branches when their are
released or merged(up to discussion)

Don't put them in the upstream git repo. Let people decide where they
want to have them -- all Fedora contributors have access to
fedorapeople.org git hosting and there is github one button click
('Clone') away from the github mirror.

It is not a problem to keep a separate git branch published this way.

May be I misunderstand you -- if you just want people to propose merge
requests on github with pre-defined names, then that's just fine.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#151][opened] Make httpd publish its CA certificate on DL1

[stlaz]

   URL: https://github.com/freeipa/freeipa/pull/151
Author: stlaz
 Title: #151: Make httpd publish its CA certificate on DL1
Action: opened

PR body:
"""
httpd did not publish its certificate on DL1 which could
cause issues during client installation in a rare corner
case where there would be no way of getting the certificate
but from a HTTP instance.

https://fedorahosted.org/freeipa/ticket/6393
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/151/head:pr151
git checkout pr151
From 1386e6c721eff6beb951c680044dfc3fd1421af7 Mon Sep 17 00:00:00 2001
From: Stanislav Laznicka 
Date: Tue, 11 Oct 2016 15:48:47 +0200
Subject: [PATCH] Make httpd publish its CA certificate on DL1

httpd did not publish its certificate on DL1 which could
cause issues during client installation in a rare corner
case where there would be no way of getting the certificate
but from a HTTP instance.

https://fedorahosted.org/freeipa/ticket/6393
---
 ipaserver/install/httpinstance.py | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/ipaserver/install/httpinstance.py b/ipaserver/install/httpinstance.py
index 7914f4c..da46f4d 100644
--- a/ipaserver/install/httpinstance.py
+++ b/ipaserver/install/httpinstance.py
@@ -175,8 +175,7 @@ def create_instance(self, realm, fqdn, domain_name, dm_password=None,
 self.step("importing CA certificates from LDAP", self.__import_ca_certs)
 if autoconfig:
 self.step("setting up browser autoconfig", self.__setup_autoconfig)
-if not self.promote:
-self.step("publish CA cert", self.__publish_ca_cert)
+self.step("publish CA cert", self.__publish_ca_cert)
 self.step("clean up any existing httpd ccache", self.remove_httpd_ccache)
 self.step("configuring SELinux for httpd", self.configure_selinux_for_httpd)
 if not self.is_kdcproxy_configured():
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Build system refactoring - design document

[Petr Vobornik]

On 10/07/2016 11:56 AM, Petr Spacek wrote:
> Dear FreeIPA developers and packagers,
> 
> you can find first version of the Build system refactoring design document on:
> http://www.freeipa.org/page/V4/Build_system_refactoring
> 
> If you do not care about implementation details, please be so kind and quickly
> scan through chapter
> http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management
> 
> I'm not an FreeIPA packager so I might miss some important thing which needs
> to be configurable.
> 
> 
> Also, I would appreciate ideas how to handle build versioning:
> http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning
> 
> My main questions are:
> * What is triggering IPA upgrade?
> * Would it be sufficient to bump release in RPM? (I mean - theoretically.
> Could the code be modified to detect this?)
> 
> Here I'm trying to avoid unnecessary rebuilds caused by changes to
> IPA_VENDOR_VERSION during each build.
> 
> 
> Timo, what can I do to help you with packaging for Ubuntu/Debian?
> 
> Dream big, even wild ideas are welcome!
> 

I'd like to add one use case which is a prerequisite for "packager":
release engineer.

Currently, IPA is released by running
  $ make IPA_VERSION_IS_GIT_SNAPSHOT=no rpms

Then tarball is copied from dist/sources to freeipa.org

http://www.freeipa.org/page/Release#Building_the_sources

With current code, it may be done only with:
 $ make tarball

But it probably wasn't tested much so I'd not rely on it.

What I'd like to see:

Release engineer:
 $ make dist
 $ # copy tarball

Packager:
 $ ./configure [--options]
 $ make install

I think that this workflow is implied by "Automake: Standard Targets"
but IMHO it should be specified in the design explicitly because it is a
change in our process.

-- 
Petr Vobornik

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#150][closed] Fix compatibility with python-dns 1.15.0

[mbasti-rh]

   URL: https://github.com/freeipa/freeipa/pull/150
Author: pspacek
 Title: #150: Fix compatibility with python-dns 1.15.0
Action: closed

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/150/head:pr150
git checkout pr150
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#150][comment] Fix compatibility with python-dns 1.15.0

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/150
Title: #150: Fix compatibility with python-dns 1.15.0

mbasti-rh commented:
"""
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/8e02652e7c889ce7d32b592b5235917a0f519503
ipa-4-4:
https://fedorahosted.org/freeipa/changeset/82bc75fe63acef482e9c59969ba352759ee48fa3
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/150#issuecomment-252921049
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#150][+pushed] Fix compatibility with python-dns 1.15.0

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/150
Title: #150: Fix compatibility with python-dns 1.15.0

Label: +pushed
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#150][+ack] Fix compatibility with python-dns 1.15.0

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/150
Title: #150: Fix compatibility with python-dns 1.15.0

Label: +ack
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Feature branches for sub-team efforts

[Jan Cholasta]

Hi,

On 11.10.2016 15:11, Petr Vobornik wrote:

Hi List,

we discussed locally a proposal about creating a feature branch for each
sub-team effort in our main git. Currently it would be for the 4 ongoing
refactoring efforts + Simo's work

Why?
It will allow each developer to create a pull request against the
feature branch and thus it will enable iterative development by multiple
devs without affecting other sub-teams. When the feature(refactoring) is
finished, the branch would be rebased on master and merged there. Note:
rebases can be done as needed - e.g. when other subteam finishes its work.


+1



Concerns:
1. Upstream git repo would be full of such branches.
- This can be mitigated by deleting the feature branches when their are
released or merged(up to discussion)


Personally I would just keep them there, but I don't really care.



2. Too big traffic on a list.
- IMO we actually want it - progress will be visible to others


+1




Naming:
I propose:
  refactoring-XXX
  feature-XXX


I would be perfectly fine with just XXX, but again I don't really care.



Thoughts? Anyone against?



Honza

--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] Feature branches for sub-team efforts

[Petr Vobornik]

Hi List,

we discussed locally a proposal about creating a feature branch for each
sub-team effort in our main git. Currently it would be for the 4 ongoing
refactoring efforts + Simo's work

Why?
It will allow each developer to create a pull request against the
feature branch and thus it will enable iterative development by multiple
devs without affecting other sub-teams. When the feature(refactoring) is
finished, the branch would be rebased on master and merged there. Note:
rebases can be done as needed - e.g. when other subteam finishes its work.

Concerns:
1. Upstream git repo would be full of such branches.
- This can be mitigated by deleting the feature branches when their are
released or merged(up to discussion)

2. Too big traffic on a list.
- IMO we actually want it - progress will be visible to others


Naming:
I propose:
  refactoring-XXX
  feature-XXX

Thoughts? Anyone against?
-- 
Petr Vobornik

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates

[Sumit Bose]

On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote:
> Hi,
> 
> I've started to write a SSSD design page about enhancing the current
> mapping of certificates to users and how to select/match a suitable
> certificate if multiple certificates are on a Smartcard.
> 
> My currently thoughts and idea and be found at
> https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates
> and for your convenience below as well.
> 
> Comments and suggestions are welcome. Please let me know about concerns,
> alternatives and missing use-cases/user-stories.
> 
> bye,
> Sumit
> 

Hi,

Rob, Fraser, Alexander, thank you for your comments. I think both the
issuer specific matching and the OID in the SUBJECT matching are good
ideas. I updated the design page accordingly. The changes can be shown
with
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff=9_version=6

The updated version can be found below as well. Of course more comments and
suggestions are still very welcome.

bye,
Sumit

= Matching and Mapping Certificates =

Related ticket(s):
 * http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping

=== Problem statement ===
 Mapping 
Currently it is required that a certificate used for authentication is either 
stored in the LDAP user entry or in a matching override. This might not always 
be applicable and other ways are needed to relate a user with a certificate.

 Matching 
Even if SSSD will support multiple certificates on a Smartcard in the context 
of https://fedorahosted.org/sssd/ticket/3050 it might be necessary to restrict 
(or relax) the current certificate selection in certain environments. 

=== Use cases ===
 Mapping 
In some environments it might not be possible or would cause unwanted effort to 
add certificates to the LDAP entry of the users to allow Smartcard based 
authentication. Reasons might be:
* Certificates/Smartcards are issued externally
* LDAP schema extension is not possible or not allowed

 Matching 
A user might have multiple certificate on a Smartcard which are suitable for 
authentication. But on some host in the environment only certificates from a 
specific CA (while all other CAs are trusted as well) or with some special 
extension should be valid for login.

=== Overview of the solution ===
To match a certificate a language/syntax has to be defined which allows to 
reference items from the certificate and compare the values with the expected 
data. To map the certificates to a user the language/syntax should allow to 
relate certificate items with LDAP attributes so that the value(s) from the 
certificate item can be used in a LDAP search filter.


=== Implementation details ===
 Matching 
The pkinit plugin of MIT Kerberos must find a suitable certificate from a 
Smartcard as well and has defined the following syntax (see the 
pkinit_cert_match section of the krb5.conf man page or 
http://web.mit.edu/Kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html for 
details). The main components are

* regular-expression
* regular-expression
* regular-expression
* extended-key-usage-list
* key-usage-list

and can be grouped together with a prefixed '&&' (and) or '`||`' (or) operator 
('&&' is the default). If multiple rules are given they are iterated with the 
order in the config file as long as a rule matches exactly one certificate.

'''Question: MIT Kerberos use case-sensitive matching and POSIX Extended 
Regular Expression syntax, shall we do the same?'''

While  and  are (imo) already quite flexible I can see some 
potential extensions for the other components.

 and  in MIT Kerberos only accept certain string values related to 
some allowed values in those field as defined in 
https://www.ietf.org/rfc/rfc3280.txt . The selection is basically determined by 
what is supported on server side of the pkinit plugin of MIT Kerberos. Since we 
plan to extend pkinit and support local authentication without pkinit as well I 
would suggest to allow OID strings for those components as well (the comparison 
is done on the OID level nonetheless).

The  component in MIT Kerberos only checks the otherName SAN component for 
the id-pkinit-san OID as defined in https://www.ietf.org/rfc/rfc4556.txt or the 
szOID_NT_PRINCIPAL_NAME OID as mentioned in 
https://support.microsoft.com/en-us/kb/287547. While this is sufficient for the 
default pkinit user case of MIT Kerberos I would suggest to extend this 
component by allowing to specific an OID with 

= Issuer specific matching =
Although the MIT Kerberos rules allow to select the issuer of a certificate 
there are use cases where a more specific selection is needed. E.g. if there 
are some default matching rules for all issuers and some other issuer specific 
rules where the default rules should not apply. To make this possible with the 
above scheme the default rules must have an  clause which matches all 
but the issuer with 

[Freeipa-devel] [freeipa PR#150][opened] Fix compatibility with python-dns 1.15.0

[pspacek]

   URL: https://github.com/freeipa/freeipa/pull/150
Author: pspacek
 Title: #150: Fix compatibility with python-dns 1.15.0
Action: opened

PR body:
"""
From https://github.com/rthalley/dnspython/issues/214:
The FreeIPA code is directly invoking the TXT RR constructor instread
of calling dns.rdata.from_text(), which is how dnspython would like you
to do this kind of thing.

https://fedorahosted.org/freeipa/ticket/6390
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/150/head:pr150
git checkout pr150
From 587fcca4995e944b6fb8783605ade9f9065c352f Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Tue, 11 Oct 2016 12:09:17 +0200
Subject: [PATCH] Fix compatibility with python-dns 1.15.0

From https://github.com/rthalley/dnspython/issues/214:
The FreeIPA code is directly invoking the TXT RR constructor instread
of calling dns.rdata.from_text(), which is how dnspython would like you
to do this kind of thing.

https://fedorahosted.org/freeipa/ticket/6390
---
 ipaserver/dns_data_management.py | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/ipaserver/dns_data_management.py b/ipaserver/dns_data_management.py
index 48717c7..d4dc42e 100644
--- a/ipaserver/dns_data_management.py
+++ b/ipaserver/dns_data_management.py
@@ -8,13 +8,12 @@
 
 from collections import defaultdict
 from dns import (
+rdata,
 rdataclass,
 rdatatype,
 zone,
 )
 from dns.exception import DNSException
-from dns.rdtypes.IN.SRV import SRV
-from dns.rdtypes.ANY.TXT import TXT
 
 from time import sleep, time
 
@@ -115,12 +114,11 @@ def __add_srv_records(
 suffix = self.domain_abs
 
 for name, port in rname_port_map:
-rd = SRV(
+rd = rdata.from_text(
 rdataclass.IN, rdatatype.SRV,
-priority,
-weight,
-port,
-hostname.make_absolute()
+'{0} {1} {2} {3}'.format(
+priority, weight, port, hostname.make_absolute()
+)
 )
 
 r_name = name.derelativize(suffix)
@@ -158,7 +156,8 @@ def __add_kerberos_txt_rec(self, zone_obj):
 # FIXME: with external DNS, this should generate records for all
 # realmdomains
 r_name = DNSName('_kerberos') + self.domain_abs
-rd = TXT(rdataclass.IN, rdatatype.TXT, [self.api_instance.env.realm])
+rd = rdata.from_text(rdataclass.IN, rdatatype.TXT,
+ self.api_instance.env.realm)
 rdataset = zone_obj.get_rdataset(
 r_name, rdatatype.TXT, create=True
 )
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#148][synchronized] Unaccessible variable self.attrs in Tracker

[gkaihorodova]

   URL: https://github.com/freeipa/freeipa/pull/148
Author: gkaihorodova
 Title: #148: Unaccessible variable self.attrs in Tracker
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/148/head:pr148
git checkout pr148
From 298e1a136c6a430e8deaa558a946ba51874ffd95 Mon Sep 17 00:00:00 2001
From: Ganna Kaihorodova 
Date: Mon, 10 Oct 2016 14:00:51 +0200
Subject: [PATCH] Unaccessible variable self.attrs in Tracker

In tracker, 'self.attrs' variable is created and filled in track_create method.
Some objects are not created but still require access to this variable.
Created 'self.attrs' variable in init

https://fedorahosted.org/freeipa/ticket/6125
---
 ipatests/test_xmlrpc/tracker/base.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ipatests/test_xmlrpc/tracker/base.py b/ipatests/test_xmlrpc/tracker/base.py
index a2b7406..aa88e6b 100644
--- a/ipatests/test_xmlrpc/tracker/base.py
+++ b/ipatests/test_xmlrpc/tracker/base.py
@@ -76,6 +76,7 @@ def __init__(self, default_version=None):
 self.api = api
 self.default_version = default_version or API_VERSION
 self._dn = None
+self.attrs = {}
 
 self.exists = False
 
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#141][+ack] Tests: Fix failing test_ipalib/test_parameters

[martbab]

  URL: https://github.com/freeipa/freeipa/pull/141
Title: #141: Tests: Fix failing test_ipalib/test_parameters

Label: +ack
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#140][synchronized] Tests: Remove invalid certplugin tests

[mirielka]

   URL: https://github.com/freeipa/freeipa/pull/140
Author: mirielka
 Title: #140: Tests: Remove invalid certplugin tests
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/140/head:pr140
git checkout pr140
From b6afcc5b56f471b06fdd64a0c1e0d996b4a07f08 Mon Sep 17 00:00:00 2001
From: Lenka Doudova 
Date: Thu, 6 Oct 2016 08:51:03 +0200
Subject: [PATCH 1/2] Tests: Remove invalid certplugin tests

A bunch of certplugin tests were testing number of revoked certificates with
various revocation reasons. Since existence of revoked certificates often
depends on other parts of IdM than IPA, it is not really valid to check their
presence unless creation of revoked certificate is intentionally tested.

https://fedorahosted.org/freeipa/ticket/6349
---
 ipatests/test_xmlrpc/test_cert_plugin.py | 75 +---
 1 file changed, 1 insertion(+), 74 deletions(-)

diff --git a/ipatests/test_xmlrpc/test_cert_plugin.py b/ipatests/test_xmlrpc/test_cert_plugin.py
index 4537002..e527886 100644
--- a/ipatests/test_xmlrpc/test_cert_plugin.py
+++ b/ipatests/test_xmlrpc/test_cert_plugin.py
@@ -292,80 +292,7 @@ def test_0006_find_this_short_host_exact(self):
 res = api.Command['cert_find'](subject=self.short, exactly=True)
 assert 'count' in res and res['count'] == 0
 
-def test_0007_find_revocation_reason_0(self):
-"""
-Find all certificates with revocation reason 0
-"""
-res = api.Command['cert_find'](revocation_reason=0)
-assert 'count' in res and res['count'] == 0
-
-def test_0008_find_revocation_reason_1(self):
-"""
-Find all certificates with revocation reason 1
-"""
-res = api.Command['cert_find'](revocation_reason=1)
-assert 'count' in res and res['count'] == 0
-
-def test_0009_find_revocation_reason_2(self):
-"""
-Find all certificates with revocation reason 2
-"""
-res = api.Command['cert_find'](revocation_reason=2)
-assert 'count' in res and res['count'] == 0
-
-def test_0010_find_revocation_reason_3(self):
-"""
-Find all certificates with revocation reason 3
-"""
-res = api.Command['cert_find'](revocation_reason=3)
-assert 'count' in res and res['count'] == 0
-
-def test_0011_find_revocation_reason_4(self):
-"""
-Find all certificates with revocation reason 4
-
-There is no way to know in advance how many revoked certificates
-we'll have but in the context of make-test we'll have at least one.
-"""
-res = api.Command['cert_find'](revocation_reason=4)
-assert 'count' in res and res['count'] >= 1
-
-def test_0012_find_revocation_reason_5(self):
-"""
-Find all certificates with revocation reason 5
-"""
-res = api.Command['cert_find'](revocation_reason=5)
-assert 'count' in res and res['count'] == 0
-
-def test_0013_find_revocation_reason_6(self):
-"""
-Find all certificates with revocation reason 6
-"""
-res = api.Command['cert_find'](revocation_reason=6)
-assert 'count' in res and res['count'] == 0
-
-# There is no revocation reason #7
-
-def test_0014_find_revocation_reason_8(self):
-"""
-Find all certificates with revocation reason 8
-"""
-res = api.Command['cert_find'](revocation_reason=8)
-assert 'count' in res and res['count'] == 0
-
-def test_0015_find_revocation_reason_9(self):
-"""
-Find all certificates with revocation reason 9
-"""
-res = api.Command['cert_find'](revocation_reason=9)
-assert 'count' in res and res['count'] == 0
-
-def test_0016_find_revocation_reason_10(self):
-"""
-Find all certificates with revocation reason 10
-"""
-res = api.Command['cert_find'](revocation_reason=10)
-assert 'count' in res and res['count'] == 0
+# tests 0007 to 0016 removed
 
 def test_0017_find_by_issuedon(self):
 """

From 0232ec23bcbc23c4cccdeef1dc20e75839c5832c Mon Sep 17 00:00:00 2001
From: Lenka Doudova 
Date: Tue, 11 Oct 2016 11:33:16 +0200
Subject: [PATCH 2/2] Tests: Certificate revocation

Providing tests for certificate revocation to replace deleted tests from
test_cert_find.

https://fedorahosted.org/freeipa/ticket/6349
---
 ipatests/test_xmlrpc/test_cert_plugin.py | 80 ++--
 1 file changed, 75 insertions(+), 5 deletions(-)

diff --git a/ipatests/test_xmlrpc/test_cert_plugin.py b/ipatests/test_xmlrpc/test_cert_plugin.py
index e527886..cb5175d 100644
--- a/ipatests/test_xmlrpc/test_cert_plugin.py
+++ b/ipatests/test_xmlrpc/test_cert_plugin.py
@@ -78,12 +78,11 @@ def is_db_configured():
 # running as the lite-server.
 
 
-@pytest.mark.tier1
-class 

Re: [Freeipa-devel] Build system refactoring - design document

[Alexander Bokovoy]

On ti, 11 loka 2016, Petr Spacek wrote:

On 11.10.2016 10:04, Jan Cholasta wrote:

On 11.10.2016 09:36, Petr Spacek wrote:

On 11.10.2016 09:00, Jan Cholasta wrote:

Hi,

On 7.10.2016 11:56, Petr Spacek wrote:

Dear FreeIPA developers and packagers,

you can find first version of the Build system refactoring design document
on:
http://www.freeipa.org/page/V4/Build_system_refactoring

If you do not care about implementation details, please be so kind and
quickly
scan through chapter
http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management

I'm not an FreeIPA packager so I might miss some important thing which needs
to be configurable.


1) There should be a --with-python switch to select the version of Python to
use in our command line tools and/or during build. The default would be
"python", i.e. the default Python interpreter found in the path.


Okay. Can we pick some descriptive name?

--with-default-python
or
--with--python?

I think that it would be confusing if we had just
--with-python
--with-python2
--with-python3


If the default values are "python", "python2", "python3" respectively, I don't


These need to be full paths. I hope that some autoconf detection logic will
help with autodetection.



think it would be confusing, since most of the time you only need to specify
--with-python, if anything.


Okay, let me be explicit: It *is* confusing for me. Would you be okay with
--with-default-python ?



Do we even need --with-python2 and --with-python3? I think they would only
make sense if you had multiple Python minor versions installed and wanted to
make packages for all of them.


AFAIK autoconf-style is to provide these for options where path to external
binary is needed. I would like to keep these conventions to avoid NIH syndrome
in the new build system.

Also, --without-python2/--without-python3 is needed anyway to disable this
part of build on systems without Python X version. I want to keep this
explicit (as with any other optional part of the build).

Why so complex? Allow --with-python to be specified multiple times and
enable all python versions that resolve through --with-python specified 
executables:

 --with-python=/bin/python2 --with-python=/bin/python3

would enable both Python 2 and Python 3. Specifying none will enable
default version found on the system. Specifying one will enable
explicitly only one.


--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Build system refactoring - design document

[Petr Spacek]

On 11.10.2016 10:04, Jan Cholasta wrote:
> On 11.10.2016 09:36, Petr Spacek wrote:
>> On 11.10.2016 09:00, Jan Cholasta wrote:
>>> Hi,
>>>
>>> On 7.10.2016 11:56, Petr Spacek wrote:
 Dear FreeIPA developers and packagers,

 you can find first version of the Build system refactoring design document
 on:
 http://www.freeipa.org/page/V4/Build_system_refactoring

 If you do not care about implementation details, please be so kind and
 quickly
 scan through chapter
 http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management

 I'm not an FreeIPA packager so I might miss some important thing which 
 needs
 to be configurable.
>>>
>>> 1) There should be a --with-python switch to select the version of Python to
>>> use in our command line tools and/or during build. The default would be
>>> "python", i.e. the default Python interpreter found in the path.
>>
>> Okay. Can we pick some descriptive name?
>>
>> --with-default-python
>> or
>> --with--python?
>>
>> I think that it would be confusing if we had just
>> --with-python
>> --with-python2
>> --with-python3
> 
> If the default values are "python", "python2", "python3" respectively, I don't

These need to be full paths. I hope that some autoconf detection logic will
help with autodetection.


> think it would be confusing, since most of the time you only need to specify
> --with-python, if anything.

Okay, let me be explicit: It *is* confusing for me. Would you be okay with
--with-default-python ?


> Do we even need --with-python2 and --with-python3? I think they would only
> make sense if you had multiple Python minor versions installed and wanted to
> make packages for all of them.

AFAIK autoconf-style is to provide these for options where path to external
binary is needed. I would like to keep these conventions to avoid NIH syndrome
in the new build system.

Also, --without-python2/--without-python3 is needed anyway to disable this
part of build on systems without Python X version. I want to keep this
explicit (as with any other optional part of the build).


>> Besides that, I would make --with-default-python to accept either "2" or "3"
>> (and thus use path specified by --with-python? option).
>>
>>
>>
>>> 2) There is --with-pylint, --with-jslint, but no --with-po-validate.
>>
>> Let me clarify: I plan to use --with for things which have paths or other
>> parameters, --enable for booleans.
> 
> I see, that was not clear to me, I confused the two.
> 
>>
>> Where po-validate belongs? AFAIK target validate-po in install/po/Makefile is
>> calling script ../../ipatests/i18n.py which is in IPA source tree anyway.
>>
>> Do you want to have a --enable/--disable switch for these PO checks?
> 
> Not really.
> 
>>
>>
>>> 3) I would prefer that if pylint (or jslint or python-polib) is not 
>>> installed
>>> the build would fail instead of silently skipping the lint. Let it be a 
>>> wilful
>>> decision of the packager whether to run the lint or not.
>>
>> Yes, that is my intent. It will not skip anything automatically.
> 
> Right.
> 
>>
>>
>>
>>> 4) It is explicitly stated that I can turn off features using
>>> --without-feature. But how do I disable building server components?
>>
>> I've added explicit mention of --disable-feature:
>> http://www.freeipa.org/index.php?title=V4%2FBuild_system_refactoring=revision=14311=14310
>>
> 
> Thanks.
> 
>>
>>
 Also, I would appreciate ideas how to handle build versioning:
 http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning

 My main questions are:
 * What is triggering IPA upgrade?
 * Would it be sufficient to bump release in RPM? (I mean - theoretically.
 Could the code be modified to detect this?)

 Here I'm trying to avoid unnecessary rebuilds caused by changes to
 IPA_VENDOR_VERSION during each build.
>>>
>>> How exactly is IPA_VENDOR_VERSION causing unnecessary rebuilds? I can see it
>>> is written only to ipapython/version.py:
>>>
>>> $ git grep -E '\bIPA_VENDOR_VERSION\b'
>>> Makefile:IPA_VENDOR_VERSION=$(IPA_VERSION)$(IPA_VENDOR_VERSION_SUFFIX)
>>> Makefile:   sed -i -e "s:__VENDOR_VERSION__:$(IPA_VENDOR_VERSION):"
>>> ipapython/version.py
>>
>> My bad, I should write 'IPA*VERSION*'.
>>
>> Especially unconditional write to version.m4 is problematic but unconditional
>> writes to other files slows things as well, just not that much.
> 
> Could this be worked around by writing into a temporary file, comparing it
> with the real file and mv'ing the temporary file over the real file only if
> the differ?

Right now IPA_VERSION_IS_GIT_SNAPSHOT is always appends timestamp to the
string so the move would happen always ...

This is why I'm trying to understand where the versions are used and if they
really have to change at every (devel) build.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to 

[Freeipa-devel] [freeipa PR#117][synchronized] Make ipa-replica-install run in interactive mode

[stlaz]

   URL: https://github.com/freeipa/freeipa/pull/117
Author: stlaz
 Title: #117: Make ipa-replica-install run in interactive mode
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/117/head:pr117
git checkout pr117
From 314bc73b81f7d6bc2f1b8f4a08af8a93e33d4228 Mon Sep 17 00:00:00 2001
From: Stanislav Laznicka 
Date: Mon, 26 Sep 2016 12:43:24 +0200
Subject: [PATCH] replicainstall: run in interactive mode

Tweaks to replica installation to support interactive mode:
 - modified man to better document what actually happens
 - added principal/password prompt for unattended mode
   of ipa-replica-install if no credentials are set
 - made ipa-client-install run in interactive mode during
   replica promotion if it is itself not run in unattended mode

https://fedorahosted.org/freeipa/ticket/6068
---
 install/tools/man/ipa-replica-install.1|   4 +-
 ipaserver/install/server/replicainstall.py | 115 +++--
 2 files changed, 78 insertions(+), 41 deletions(-)

diff --git a/install/tools/man/ipa-replica-install.1 b/install/tools/man/ipa-replica-install.1
index af37b07..f94098d 100644
--- a/install/tools/man/ipa-replica-install.1
+++ b/install/tools/man/ipa-replica-install.1
@@ -49,7 +49,7 @@ A replica should only be installed on the same or higher version of IPA on the r
 The user principal which will be used to promote the client to the replica and enroll the client itself, if necessary.
 .TP
 \fB\-w\fR, \fB\-\-admin\-password\fR
-The Kerberos password for the given principal.
+The Kerberos password for the given principal. If no principal is supplied with \-\-principal, "admin" is assumed.
 
 .SS "DOMAIN LEVEL 1 CLIENT ENROLLMENT OPTIONS"
 To install client and promote it to replica using a host keytab or One Time Password, the host needs to be a member of ipaservers group. This requires to create a host entry and add it to the host group prior replica installation.
@@ -58,7 +58,7 @@ To install client and promote it to replica using a host keytab or One Time Pass
 
 .TP
 \fB\-p\fR \fIPASSWORD\fR, \fB\-\-password\fR=\fIPASSWORD\fR
-One Time Password for joining a machine to the IPA realm.
+One Time Password for joining a machine to the IPA realm. If the \-\-principal option is used, this is assumed a password for that principal.
 .TP
 \fB\-k\fR, \fB\-\-keytab\fR
 Path to host keytab.
diff --git a/ipaserver/install/server/replicainstall.py b/ipaserver/install/server/replicainstall.py
index 7effda7..3a10907 100644
--- a/ipaserver/install/server/replicainstall.py
+++ b/ipaserver/install/server/replicainstall.py
@@ -14,6 +14,7 @@
 import shutil
 import socket
 import tempfile
+import getpass
 
 import six
 
@@ -918,46 +919,50 @@ def install(installer):
 
 
 def ensure_enrolled(installer):
-# Call client install script
-service.print_msg("Configuring client side components")
+# Prepare options for the installer script
+args = [paths.IPA_CLIENT_INSTALL, "--no-ntp"]
+nolog = ()
+
+if installer.unattended:
+args.append("--unattended")
+if installer.domain_name:
+args.extend(["--domain", installer.domain_name])
+if installer.server:
+args.extend(["--server", installer.server])
+if installer.realm_name:
+args.extend(["--realm", installer.realm_name])
+if installer.host_name:
+args.extend(["--hostname", installer.host_name])
+if installer.password:
+args.extend(["--password", installer.password])
+else:
+if installer.admin_password:
+# Always set principal if password was set explicitly.
+# This is the behaviour from domain level 0 so we're keeping it
+args.extend(["--principal", installer.principal or "admin"])
+nolog = (installer.admin_password, )
+args.extend(["--password", installer.admin_password])
+if installer.keytab:
+args.extend(["--keytab", installer.keytab])
+
+if installer.no_dns_sshfp:
+args.append("--no-dns-sshfp")
+if installer.ssh_trust_dns:
+args.append("--ssh-trust-dns")
+if installer.no_ssh:
+args.append("--no-ssh")
+if installer.no_sshd:
+args.append("--no-sshd")
+if installer.mkhomedir:
+args.append("--mkhomedir")
+
 try:
+service.print_msg("Configuring client side components")
+# Set _enrollment_performed to True so that any mess left behind in
+# case of an enrollment failure gets cleaned
 installer._enrollment_performed = True
-
-args = [paths.IPA_CLIENT_INSTALL, "--unattended", "--no-ntp"]
-stdin = None
-
-if installer.domain_name:
-args.extend(["--domain", installer.domain_name])
-if installer.server:
-args.extend(["--server", installer.server])
-if installer.realm_name:
-args.extend(["--realm", installer.realm_name])
-

Re: [Freeipa-devel] Build system refactoring - design document

[Jan Cholasta]

On 11.10.2016 09:36, Petr Spacek wrote:

On 11.10.2016 09:00, Jan Cholasta wrote:

Hi,

On 7.10.2016 11:56, Petr Spacek wrote:

Dear FreeIPA developers and packagers,

you can find first version of the Build system refactoring design document on:
http://www.freeipa.org/page/V4/Build_system_refactoring

If you do not care about implementation details, please be so kind and quickly
scan through chapter
http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management

I'm not an FreeIPA packager so I might miss some important thing which needs
to be configurable.


1) There should be a --with-python switch to select the version of Python to
use in our command line tools and/or during build. The default would be
"python", i.e. the default Python interpreter found in the path.


Okay. Can we pick some descriptive name?

--with-default-python
or
--with--python?

I think that it would be confusing if we had just
--with-python
--with-python2
--with-python3


If the default values are "python", "python2", "python3" respectively, I 
don't think it would be confusing, since most of the time you only need 
to specify --with-python, if anything.


Do we even need --with-python2 and --with-python3? I think they would 
only make sense if you had multiple Python minor versions installed and 
wanted to make packages for all of them.





Besides that, I would make --with-default-python to accept either "2" or "3"
(and thus use path specified by --with-python? option).




2) There is --with-pylint, --with-jslint, but no --with-po-validate.


Let me clarify: I plan to use --with for things which have paths or other
parameters, --enable for booleans.


I see, that was not clear to me, I confused the two.



Where po-validate belongs? AFAIK target validate-po in install/po/Makefile is
calling script ../../ipatests/i18n.py which is in IPA source tree anyway.

Do you want to have a --enable/--disable switch for these PO checks?


Not really.





3) I would prefer that if pylint (or jslint or python-polib) is not installed
the build would fail instead of silently skipping the lint. Let it be a wilful
decision of the packager whether to run the lint or not.


Yes, that is my intent. It will not skip anything automatically.


Right.






4) It is explicitly stated that I can turn off features using
--without-feature. But how do I disable building server components?


I've added explicit mention of --disable-feature:
http://www.freeipa.org/index.php?title=V4%2FBuild_system_refactoring=revision=14311=14310


Thanks.





Also, I would appreciate ideas how to handle build versioning:
http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning

My main questions are:
* What is triggering IPA upgrade?
* Would it be sufficient to bump release in RPM? (I mean - theoretically.
Could the code be modified to detect this?)

Here I'm trying to avoid unnecessary rebuilds caused by changes to
IPA_VENDOR_VERSION during each build.


How exactly is IPA_VENDOR_VERSION causing unnecessary rebuilds? I can see it
is written only to ipapython/version.py:

$ git grep -E '\bIPA_VENDOR_VERSION\b'
Makefile:IPA_VENDOR_VERSION=$(IPA_VERSION)$(IPA_VENDOR_VERSION_SUFFIX)
Makefile:   sed -i -e "s:__VENDOR_VERSION__:$(IPA_VENDOR_VERSION):"
ipapython/version.py


My bad, I should write 'IPA*VERSION*'.

Especially unconditional write to version.m4 is problematic but unconditional
writes to other files slows things as well, just not that much.


Could this be worked around by writing into a temporary file, comparing 
it with the real file and mv'ing the temporary file over the real file 
only if the differ?


--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Build system refactoring - design document

[Alexander Bokovoy]

On ti, 11 loka 2016, Petr Spacek wrote:

On 11.10.2016 09:00, Jan Cholasta wrote:

Hi,

On 7.10.2016 11:56, Petr Spacek wrote:

Dear FreeIPA developers and packagers,

you can find first version of the Build system refactoring design document on:
http://www.freeipa.org/page/V4/Build_system_refactoring

If you do not care about implementation details, please be so kind and quickly
scan through chapter
http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management

I'm not an FreeIPA packager so I might miss some important thing which needs
to be configurable.


1) There should be a --with-python switch to select the version of Python to
use in our command line tools and/or during build. The default would be
"python", i.e. the default Python interpreter found in the path.


Okay. Can we pick some descriptive name?

--with-default-python
or
--with--python?

I think that it would be confusing if we had just
--with-python
--with-python2
--with-python3

--with-python=/path/to/python.binary is enough. We have the same in
Samba where a secondary build against another python interpreter is
regulated with '--extra-python' pointing to the Python's executable.



Besides that, I would make --with-default-python to accept either "2" or "3"
(and thus use path specified by --with-python? option).

I don't think we need --with-default-python=2|3 at all. Once you have a
Python binary, you can discover the flavor in the code:
$ python -c 'import sys; print sys.version_info.major'
2


--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Build system refactoring - design document

[Petr Spacek]

On 11.10.2016 09:00, Jan Cholasta wrote:
> Hi,
> 
> On 7.10.2016 11:56, Petr Spacek wrote:
>> Dear FreeIPA developers and packagers,
>>
>> you can find first version of the Build system refactoring design document 
>> on:
>> http://www.freeipa.org/page/V4/Build_system_refactoring
>>
>> If you do not care about implementation details, please be so kind and 
>> quickly
>> scan through chapter
>> http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management
>>
>> I'm not an FreeIPA packager so I might miss some important thing which needs
>> to be configurable.
> 
> 1) There should be a --with-python switch to select the version of Python to
> use in our command line tools and/or during build. The default would be
> "python", i.e. the default Python interpreter found in the path.

Okay. Can we pick some descriptive name?

--with-default-python
or
--with--python?

I think that it would be confusing if we had just
--with-python
--with-python2
--with-python3


Besides that, I would make --with-default-python to accept either "2" or "3"
(and thus use path specified by --with-python? option).



> 2) There is --with-pylint, --with-jslint, but no --with-po-validate.

Let me clarify: I plan to use --with for things which have paths or other
parameters, --enable for booleans.

Where po-validate belongs? AFAIK target validate-po in install/po/Makefile is
calling script ../../ipatests/i18n.py which is in IPA source tree anyway.

Do you want to have a --enable/--disable switch for these PO checks?


> 3) I would prefer that if pylint (or jslint or python-polib) is not installed
> the build would fail instead of silently skipping the lint. Let it be a wilful
> decision of the packager whether to run the lint or not.

Yes, that is my intent. It will not skip anything automatically.



> 4) It is explicitly stated that I can turn off features using
> --without-feature. But how do I disable building server components?

I've added explicit mention of --disable-feature:
http://www.freeipa.org/index.php?title=V4%2FBuild_system_refactoring=revision=14311=14310


>> Also, I would appreciate ideas how to handle build versioning:
>> http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning
>>
>> My main questions are:
>> * What is triggering IPA upgrade?
>> * Would it be sufficient to bump release in RPM? (I mean - theoretically.
>> Could the code be modified to detect this?)
>>
>> Here I'm trying to avoid unnecessary rebuilds caused by changes to
>> IPA_VENDOR_VERSION during each build.
> 
> How exactly is IPA_VENDOR_VERSION causing unnecessary rebuilds? I can see it
> is written only to ipapython/version.py:
> 
> $ git grep -E '\bIPA_VENDOR_VERSION\b'
> Makefile:IPA_VENDOR_VERSION=$(IPA_VERSION)$(IPA_VENDOR_VERSION_SUFFIX)
> Makefile:   sed -i -e "s:__VENDOR_VERSION__:$(IPA_VENDOR_VERSION):"
> ipapython/version.py

My bad, I should write 'IPA*VERSION*'.

Especially unconditional write to version.m4 is problematic but unconditional
writes to other files slows things as well, just not that much.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#142][synchronized] CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling

[dkupka]

   URL: https://github.com/freeipa/freeipa/pull/142
Author: dkupka
 Title: #142: CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper 
(un)pickling
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/142/head:pr142
git checkout pr142
From b9c50b264a8a9d6f2f2f342a896defb1c36e6a60 Mon Sep 17 00:00:00 2001
From: David Kupka 
Date: Thu, 6 Oct 2016 13:31:52 +0200
Subject: [PATCH] UnsafeIPAddress: Implement __(g|s)etstate__ and to ensure
 proper (un)pickling

Missing attributes in instance created by pickle.load cause AttributeError in
second part of ipa-server-install --external-ca.

https://fedorahosted.org/freeipa/ticket/6385
---
 ipapython/ipautil.py | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py
index 41544a1..2cffe24 100644
--- a/ipapython/ipautil.py
+++ b/ipapython/ipautil.py
@@ -127,6 +127,17 @@ def __init__(self, addr):
 super(UnsafeIPAddress, self).__init__(addr,
   flags=self.netaddr_ip_flags)
 
+def __getstate__(self):
+state = {
+'_net': self._net,
+'super_state': super(UnsafeIPAddress, self).__getstate__(),
+}
+return state
+
+def __setstate__(self, state):
+super(UnsafeIPAddress, self).__setstate__(state.pop('super_state'))
+self._net = state['_net']
+
 
 class CheckedIPAddress(UnsafeIPAddress):
 """IPv4 or IPv6 address with additional constraints.
@@ -142,6 +153,7 @@ def __init__(self, addr, match_local=False, parse_netmask=True,
 
 if isinstance(addr, CheckedIPAddress):
 self.prefixlen = addr.prefixlen
+self._net = addr._net
 return
 
 if not parse_netmask and self._net:
@@ -205,6 +217,17 @@ def __init__(self, addr, match_local=False, parse_netmask=True,
 
 self.prefixlen = self._net.prefixlen
 
+def __getstate__(self):
+state = {
+'prefixlen': self.prefixlen,
+'super_state': super(CheckedIPAddress, self).__getstate__(),
+}
+return state
+
+def __setstate__(self, state):
+super(CheckedIPAddress, self).__setstate__(state.pop('super_state'))
+self.prefixlen = state['prefixlen']
+
 def is_network_addr(self):
 return self == self._net.network
 
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Build system refactoring - design document

[Jan Cholasta]

Hi,

On 7.10.2016 11:56, Petr Spacek wrote:

Dear FreeIPA developers and packagers,

you can find first version of the Build system refactoring design document on:
http://www.freeipa.org/page/V4/Build_system_refactoring

If you do not care about implementation details, please be so kind and quickly
scan through chapter
http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management

I'm not an FreeIPA packager so I might miss some important thing which needs
to be configurable.


1) There should be a --with-python switch to select the version of 
Python to use in our command line tools and/or during build. The default 
would be "python", i.e. the default Python interpreter found in the path.


2) There is --with-pylint, --with-jslint, but no --with-po-validate.

3) I would prefer that if pylint (or jslint or python-polib) is not 
installed the build would fail instead of silently skipping the lint. 
Let it be a wilful decision of the packager whether to run the lint or not.


4) It is explicitly stated that I can turn off features using 
--without-feature. But how do I disable building server components?





Also, I would appreciate ideas how to handle build versioning:
http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning

My main questions are:
* What is triggering IPA upgrade?
* Would it be sufficient to bump release in RPM? (I mean - theoretically.
Could the code be modified to detect this?)

Here I'm trying to avoid unnecessary rebuilds caused by changes to
IPA_VENDOR_VERSION during each build.


How exactly is IPA_VENDOR_VERSION causing unnecessary rebuilds? I can 
see it is written only to ipapython/version.py:


$ git grep -E '\bIPA_VENDOR_VERSION\b'
Makefile:IPA_VENDOR_VERSION=$(IPA_VERSION)$(IPA_VENDOR_VERSION_SUFFIX)
Makefile:   sed -i -e "s:__VENDOR_VERSION__:$(IPA_VENDOR_VERSION):" 
ipapython/version.py


Honza

--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#148][comment] Unaccessible variable self.attrs in Tracker

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/148
Title: #148: Unaccessible variable self.attrs in Tracker

mbasti-rh commented:
"""
You can check last step in this howto 
http://www.freeipa.org/page/Pull_request_on_Github
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/148#issuecomment-252827639
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#148][reopened] Unaccessible variable self.attrs in Tracker

[stlaz]

   URL: https://github.com/freeipa/freeipa/pull/148
Author: gkaihorodova
 Title: #148: Unaccessible variable self.attrs in Tracker
Action: reopened

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/148/head:pr148
git checkout pr148
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#149][comment] Tests: Unaccessible variable self.attrs in Tracker

[stlaz]

  URL: https://github.com/freeipa/freeipa/pull/149
Title: #149: Tests: Unaccessible variable self.attrs in Tracker

stlaz commented:
"""
Please fix this in the original PR, it will be a nice training for you ;)
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/149#issuecomment-252822977
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#149][+rejected] Tests: Unaccessible variable self.attrs in Tracker

[stlaz]

  URL: https://github.com/freeipa/freeipa/pull/149
Title: #149: Tests: Unaccessible variable self.attrs in Tracker

Label: +rejected
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#148][comment] Unaccessible variable self.attrs in Tracker

[stlaz]

  URL: https://github.com/freeipa/freeipa/pull/148
Title: #148: Unaccessible variable self.attrs in Tracker

stlaz commented:
"""
That's not how pull requests work. You should change the commit and force push 
it to the branch instead.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/148#issuecomment-252822061
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code