Re: [Freeipa-devel] [PATCH] 531 Fix license in some Web UI files
On 12/06/2013 05:10 PM, Simo Sorce wrote: On Fri, 2013-12-06 at 14:19 +0100, Petr Vobornik wrote: Modified web ui files had incorrect GPLv2 headers instead of GPLv3 ones. All of the affected code is of FreeIPA origin. Ack. Simo. Pushed to master: b6540e88d88470f6566507e442f521214c5a74dc ipa-3-3: 2877f5d8a11ebdd32c2007b26facab2073cf48ad -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0330 - Add comment about last change to VERSION
On 12/05/2013 01:37 PM, Petr Viktorin wrote: Consider this scenario: - Nathaniel submits RADIUS patches that update the API version (from 2.69 to 2.70) - I have ACI patches that also bump the version (from 2.69 to 2.70) - Nathaniel's patches gets accepted - I rebase my ACI patches onto master. Git thinks that the 2.69-2.70 change is already done, so it leaves VERSION unchanged. I can solve this locally by telling Git to not merge VERSION automatically, but I think it would be helpful to add a unique comment to each change so that everyone gets a conflict cases like this. Do you agree? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Makes sense to me. I'd just add a comment so that the purpose of the last change comment is also obvious for the new developer perusing the VERSION file. Maybe something along the lines of: IPA_API_VERSION_MAJOR=2 IPA_API_VERSION_MINOR=70 +# Update the last change entry to enforce conflict on merging two independent branches into master. +# Last change: npmccallum - RADIUS support -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 439 Allow kernel keyring CCACHE when supported
On 12/06/2013 03:00 PM, Simo Sorce wrote: On Fri, 2013-12-06 at 13:42 +0100, Martin Kosek wrote: On 12/02/2013 05:20 PM, Alexander Bokovoy wrote: On Mon, 02 Dec 2013, Martin Kosek wrote: On 12/02/2013 04:05 PM, Petr Viktorin wrote: On 12/02/2013 03:42 PM, Simo Sorce wrote: On Mon, 2013-12-02 at 14:51 +0100, Petr Viktorin wrote: On 12/02/2013 02:01 PM, Martin Kosek wrote: On 12/02/2013 01:58 PM, Petr Viktorin wrote: On 11/29/2013 01:48 PM, Martin Kosek wrote: On 11/19/2013 12:35 PM, Petr Viktorin wrote: On 11/05/2013 07:22 PM, Martin Kosek wrote: Server and client installer should allow kernel keyring ccache when supported. How do I enable the kernel keyring? On f20 I get this: 2013-11-19T11:28:07Z DEBUG Starting external process 2013-11-19T11:28:07Z DEBUG args=keyctl get_persistent @s 0 2013-11-19T11:28:07Z DEBUG Process finished, return code=1 2013-11-19T11:28:07Z DEBUG stdout= 2013-11-19T11:28:07Z DEBUG stderr=keyctl_get_persistent: Key has been revoked It should be enabled out of the box. But there were some initial issues with persistent keyring in the first versions of kernel with a support, hopefully this was just a fluke which disappeared. This is what I see on my F20 with kernel-3.11.9-300.fc20.x86_64: # keyctl get_persistent @s 0 637466038 With kernel-3.11.10-300.fc20.x86_64, I get an error again: $ keyctl get_persistent @s 0 keyctl_get_persistent: Key has been revoked Not sure if it is a typo, but you won't surely get a root's keyring as a non-root user... It is just a typo, but it looks like you got me on the right track. keyctl apparently needs a real root login: $ sudo keyctl get_persistent @s 0 keyctl_get_persistent: Key has been revoked $ sudo su # keyctl get_persistent @s 0 keyctl_get_persistent: Key has been revoked # exit $ sudo su - Last login: Mon Dec 2 14:09:36 CET 2013 on pts/1 # keyctl get_persistent @s 0 968622527 # logout Please use sudo -i to get an interactive 'login' shell. Unsurprisingly, when ipa-server-install is run from sudo, it complains that the key is unsupported. From a root login all is OK. Is that expected? You should run ipa-server-install using a login shell I think. Should we open a bug to detect this and fail ? It's always worked with just sudo for me. So yes, if it's required I think we should enforce it. Simo or Alexander, is there some way to find that out in a clean way? I mean if we are in an interactive login shell. Ideally, please also file a bug with this information :) Interactive or login? These two are different a bit. There is no general way because not all shells implement common approach to detect this. For example, echo $- | grep -q i would work in a Bourne-style shell for interactive shell shopt -q login_shell would give you a login shell detector in bash but test $options[LOGIN] = on would work for login shell in zsh, similarly INTERACTIVE index would give you state of interactive shell. I meant login shell - so that we do not have problems with checking the get_persistent keyctl command. I still do not fully understand the keyctl behavior, it is working on my kernel-3.11.9-300.fc20.x86_64 even with plain sudo: $ sudo keyctl get_persistent @s 0 I think the previous behavior was cause by the improper selinux handling in the kernel, and is fixed in the latest kernel. There is indeed no reason why get_persistent shouldn't work for non-login shell unless selinux policy explicitly disallows it for sudo like programs. Anyway, any opinions on this particular patch? I'd prefer to get it in soon and file enhancement ticket for the login terminal detection, if needed. I do not have any objections. Simo. ACK, pushed to * master: 9677308caa78ed722570aea32f21334b8c27bad3 * ipa-3-3: 5b2ce3c5a57e8193ee1c6d23c4e79c3b2b62cb05 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0330 - Add comment about last change to VERSION
On 12/09/2013 12:08 PM, Tomas Babej wrote: On 12/05/2013 01:37 PM, Petr Viktorin wrote: Consider this scenario: - Nathaniel submits RADIUS patches that update the API version (from 2.69 to 2.70) - I have ACI patches that also bump the version (from 2.69 to 2.70) - Nathaniel's patches gets accepted - I rebase my ACI patches onto master. Git thinks that the 2.69-2.70 change is already done, so it leaves VERSION unchanged. I can solve this locally by telling Git to not merge VERSION automatically, but I think it would be helpful to add a unique comment to each change so that everyone gets a conflict cases like this. Do you agree? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Makes sense to me. I'd just add a comment so that the purpose of the last change comment is also obvious for the new developer perusing the VERSION file. Maybe something along the lines of: IPA_API_VERSION_MAJOR=2 IPA_API_VERSION_MINOR=70 +# Update the last change entry to enforce conflict on merging two independent branches into master. +# Last change: npmccallum - RADIUS support I spoke with Petr offline, to me it would make bigger sense if we just forbid automatic merging of this line on the git server side (if possible) instead of adding other arbitrary work to our development process. IIRC, Petr3 said it should be possible to do. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] libtool --finish warnings in build log
Hello, I saw that build of FreeIPA produces several strange warnings: libtool: install: warning: remember to run `libtool --finish /usr/lib64/krb5/plugins/kdb' libtool: install: warning: remember to run `libtool --finish /usr/lib64/dirsrv/plugins' libtool: install: warning: remember to run `libtool --finish /usr/lib64/dirsrv/plugins' libtool: install: warning: remember to run `libtool --finish /usr/lib64/samba/pdb' As Lukas Slebodnik told me, this is because we install our libraries (plugins) to an uncommon directory. Can/Should we do something about it? If this is OK, can we maybe add some flag to avoid these warnings? Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] libtool --finish warnings in build log
On Mon, 09 Dec 2013, Martin Kosek wrote: Hello, I saw that build of FreeIPA produces several strange warnings: libtool: install: warning: remember to run `libtool --finish /usr/lib64/krb5/plugins/kdb' libtool: install: warning: remember to run `libtool --finish /usr/lib64/dirsrv/plugins' libtool: install: warning: remember to run `libtool --finish /usr/lib64/dirsrv/plugins' libtool: install: warning: remember to run `libtool --finish /usr/lib64/samba/pdb' As Lukas Slebodnik told me, this is because we install our libraries (plugins) to an uncommon directory. Can/Should we do something about it? If this is OK, can we maybe add some flag to avoid these warnings? We can simply ignore them since 'libtool --finish' would in addition to --installupdate .la files which will anyway be removed and never appear in the resulting RPM package. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0134] ipa-client-install: Always pass hostname to the ipa-join
On 11/26/2013 03:37 PM, Tomas Babej wrote: Hi, The ipa-client-install script and ipa-join use different methods of resolving the hostname, the former uses gethostbyaddr() call, while the latter reads the uinfo.nodename. This can result ipa-client-install failures in case of broken PTR records. https://fedorahosted.org/freeipa/ticket/4027 This fixed the issue for me. At least ipa-client-install and ipa-join will now use the same hostname and not give strange errors. ACK. Pushed to master, ipa-3-3. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0330 - Add comment about last change to VERSION
On Mon, 2013-12-09 at 12:39 +0100, Martin Kosek wrote: On 12/09/2013 12:08 PM, Tomas Babej wrote: On 12/05/2013 01:37 PM, Petr Viktorin wrote: Consider this scenario: - Nathaniel submits RADIUS patches that update the API version (from 2.69 to 2.70) - I have ACI patches that also bump the version (from 2.69 to 2.70) - Nathaniel's patches gets accepted - I rebase my ACI patches onto master. Git thinks that the 2.69-2.70 change is already done, so it leaves VERSION unchanged. I can solve this locally by telling Git to not merge VERSION automatically, but I think it would be helpful to add a unique comment to each change so that everyone gets a conflict cases like this. Do you agree? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Makes sense to me. I'd just add a comment so that the purpose of the last change comment is also obvious for the new developer perusing the VERSION file. Maybe something along the lines of: IPA_API_VERSION_MAJOR=2 IPA_API_VERSION_MINOR=70 +# Update the last change entry to enforce conflict on merging two independent branches into master. +# Last change: npmccallum - RADIUS support I spoke with Petr offline, to me it would make bigger sense if we just forbid automatic merging of this line on the git server side (if possible) instead of adding other arbitrary work to our development process. IIRC, Petr3 said it should be possible to do. Except it may not fix the issue, if someone does a rebase on his machine and resubmit a patch to the list w/o noticing the change was effectively dropped. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0330 - Add comment about last change to VERSION
On 12/09/2013 02:50 PM, Martin Kosek wrote: On 12/09/2013 02:35 PM, Simo Sorce wrote: On Mon, 2013-12-09 at 12:39 +0100, Martin Kosek wrote: On 12/09/2013 12:08 PM, Tomas Babej wrote: On 12/05/2013 01:37 PM, Petr Viktorin wrote: Consider this scenario: - Nathaniel submits RADIUS patches that update the API version (from 2.69 to 2.70) - I have ACI patches that also bump the version (from 2.69 to 2.70) - Nathaniel's patches gets accepted - I rebase my ACI patches onto master. Git thinks that the 2.69-2.70 change is already done, so it leaves VERSION unchanged. I can solve this locally by telling Git to not merge VERSION automatically, but I think it would be helpful to add a unique comment to each change so that everyone gets a conflict cases like this. Do you agree? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Makes sense to me. I'd just add a comment so that the purpose of the last change comment is also obvious for the new developer perusing the VERSION file. Maybe something along the lines of: IPA_API_VERSION_MAJOR=2 IPA_API_VERSION_MINOR=70 +# Update the last change entry to enforce conflict on merging two independent branches into master. +# Last change: npmccallum - RADIUS support I don't think this is necessary, IMO Last change: is enough as instructions. I spoke with Petr offline, to me it would make bigger sense if we just forbid automatic merging of this line on the git server side (if possible) instead of adding other arbitrary work to our development process. IIRC, Petr3 said it should be possible to do. Except it may not fix the issue, if someone does a rebase on his machine and resubmit a patch to the list w/o noticing the change was effectively dropped. Simo. I thought that the point of the anti-merge protection is to prevent git merging tools to prevent automatic rebase of this particular line and force manual merging, i.e. force increasing the number. When the file is equal on both sides of the merge, Git just uses the common file, and doesn't consider it for merging. So unfortunately, git attributes won't work here; there needs to be another change in the file. I did say otherwise, sorry for that. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 441 Consolidate .gitignore entries
Clean up the .gitignore file: - Remove no longer used .gitignore entries, like .bzr files - Do not repeat autotools generated files over and over again - Whitelist existent Makefiles in the repository - Better separate the .gitignore entries === When porting Jan's patches downstream, I had hard time merging changes to /Makefile in the repository as it was stated in .gitignore which made git (and me) suffer. I fixed that by whitelisting this one. Unfortunately, when I saw other entries in .gitignore I could not resist and refactored the file to make it (hopefully) simpler and easier to maintain. Martin From db6309ad7117ea397f82c4394b995c0116674332 Mon Sep 17 00:00:00 2001 From: Martin Kosek mko...@redhat.com Date: Mon, 9 Dec 2013 17:36:07 +0100 Subject: [PATCH] Consolidate .gitignore entries Clean up the .gitignore file: - Remove no longer used .gitignore entries, like .bzr files - Do not repeat autotools generated files over and over again - Whitelist existent Makefiles in the repository - Better separate the .gitignore entries --- .bzrignore | 2 - .gitignore | 140 ++--- 2 files changed, 59 insertions(+), 83 deletions(-) delete mode 100644 .bzrignore diff --git a/.bzrignore b/.bzrignore deleted file mode 100644 index 3d1eb87418ef1023620a265b8f7cdeff21a30741.. --- a/.bzrignore +++ /dev/null @@ -1,2 +0,0 @@ -.git -freeipa2-dev-doc diff --git a/.gitignore b/.gitignore index 96c151a192e9ee890d1e9e45ae32a2bba06704c0..db213497202fc1ba904d3fc1b9ccea2ec5be3068 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ +# In-tree build files configure config.h config.h.in @@ -9,86 +10,63 @@ Makefile.in *.lo *.log *.o -*.pyc *.trs -.bzr -freeipa2-dev-doc -build -dist/ -RELEASE -daemons/AUTHORS -daemons/COPYING -daemons/ChangeLog -daemons/INSTALL -daemons/NEWS -daemons/README -daemons/aclocal.m4 -daemons/autom4te.cache/ -daemons/config.guess -daemons/config.log -daemons/config.status -daemons/config.sub -daemons/depcomp -daemons/install-sh -daemons/ipa-otpd/ipa-otpd -daemons/ipa-otpd/ipa-otpd.socket -daemons/ipa-otpd/ipa-otpd@.service -daemons/ipa-version.h -daemons/libtool -daemons/ltmain.sh -daemons/missing -daemons/stamp-h1 -daemons/test-driver -install/AUTHORS -install/COPYING -install/ChangeLog -install/INSTALL -install/NEWS -install/README -install/aclocal.m4 -install/autom4te.cache/ -install/config.log -install/config.status -install/install-sh -install/missing -install/stamp-h1 -install/po/test.po -install/po/test_locale/xh_ZA/LC_MESSAGES/ipa.mo -install/ui/release -install/ui/src/dojo -install/ui/src/build -install/ui/src/libs/loader.js -install/ui/src/plugins -ipa-client/COPYING -ipa-client/ChangeLog -ipa-client/INSTALL -ipa-client/aclocal.m4 -ipa-client/autom4te.cache/ -ipa-client/config.guess -ipa-client/config.log -ipa-client/config.status -ipa-client/config.sub -ipa-client/depcomp -ipa-client/install-sh -ipa-client/ipa-client.spec -ipa-client/ipa-getkeytab -ipa-client/ipa-join -ipa-client/ipa-rmkeytab -ipa-client/libtool -ipa-client/ltmain.sh -ipa-client/missing -ipa-client/py-compile -ipa-client/stamp-h1 -ipa-client/version.m4 -ipatests/test_xmlrpc/service.crt -ipatests/man/aclocal.m4 -ipatests/man/autom4te.cache/ -ipatests/man/config.status -ipatests/man/install-sh -ipatests/man/missing -freeipa.spec -ipapython/setup.py -ipapython/version.py version.m4 -ipapython/services.py -ipatests/setup.py +aclocal.m4 +autom4te.cache/ +config.guess +config.log +config.status +config.sub +depcomp +install-sh +ltmain.sh +missing +stamp-h1 +libtool +build/ + +# Python compilation +*.pyc +py-compile + +# Developer documentation +freeipa2-dev-doc +~/doc/guide/Makefile + +# Root directory +/freeipa.spec +!/Makefile +/dist/ +/RELEASE + +# Subdirectories +/daemons/ipa-otpd/ipa-otpd +/daemons/ipa-otpd/ipa-otpd.socket +/daemons/ipa-otpd/ipa-otpd@.service +/daemons/ipa-version.h +/daemons/test-driver + +/install/po/test.po +/install/po/test_locale/xh_ZA/LC_MESSAGES/ipa.mo +!/install/ui/doc/Makefile.in +/install/ui/release +/install/ui/src/dojo +/install/ui/src/build +/install/ui/src/libs/loader.js +/install/ui/src/plugins +!/install/ui/doc/Makefile + +/ipa-client/ipa-client.spec +/ipa-client/ipa-getkeytab +/ipa-client/ipa-join +/ipa-client/ipa-rmkeytab + +/ipatests/test_xmlrpc/service.crt +/ipatests/setup.py + +/ipapython/setup.py +/ipapython/version.py +/ipapython/services.py +!/ipapython/Makefile +!/ipapython/py_default_encoding/Makefile -- 1.8.3.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
