[Freeipa-devel] [www.transifex.net] Team Creation Requested: Russian
Hello freeipa, this is Transifex at http://www.transifex.net. A translation team for 'Russian' has been required to the 'FreeIPA' project. Please, visit Transifex at http://www.transifex.net/projects/p/freeipa/teams/ in order to manage the teams of the project. For changing how you receive notifications, please go to http://www.transifex.net/notices/. Thank you, Transifex ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 042 Fix ctypes SELinux problem
On Thu, 2010-02-11 at 14:57 -0500, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > Under Fedora12, the httpd SELinux policy causes IPA to bomb when the > > Python `ctypes` module gets imported. The `ctypes` module is used by > > python-pygments, which in turn is used by python-wehjit. > > > > I just made a python-wehjit 0.2.2 bugfix release with a hack to prevent > > wehjit from importing pygments. This also disables the pygments-based > > source code highlighting plugins, but we aren't using those in IPA at > > the moment anyway. > > > > This patch changes the .spec to require python-wehjit >= 0.2.2 and adds > > the pygments disabling hack in ipawebui/__init__.py > > > > Ack. Lets hold off on pushing this until the library gets into the > Fedora update stream. > > rob python-wehjit 0.2.2 has landed in Fedora 11 & 12. Pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] add Polish translation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/11/2010 06:45 PM, John Dennis wrote: > On 02/11/2010 06:36 PM, John Dennis wrote: >> Woo ho! We got our first translation, Polish. > > NAK > > Something got screwed up with the encoding when the patch was sent > through email. I need to figure out what went wrong and resubmit it. > I suggest always sending translation patches as forced base-64 encoded attachments. Sometimes the extended character set gets broken by mailman. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1PK0ACgkQeiVVYja6o6NDDwCgokzquH9kJPfMOsjeaS7SxVqq ReQAnRYaWMkunFHokAl5oq84aqw+8yMS =vIVJ -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] Add default automount location. Auto-create auto.direct in new locations.
This patch replaces deprecated automount entries created after installation with a 'default' automount location with auto.master and auto.direct maps. It also makes the automount plugin create the auto.master and auto.direct maps when a new location is added. Pavel 0001-Add-default-automount-location.-Auto-create-auto.dir.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [www.transifex.net] New Team Added: Russian
Hello freeipa, this is Transifex at http://www.transifex.net. A new translation team called 'Russian' has been added to the 'FreeIPA' project. Please, visit Transifex at http://www.transifex.net/projects/p/freeipa/team/ru/ in order to see this new team. For changing how you receive notifications, please go to http://www.transifex.net/notices/. Thank you, Transifex ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add default automount location. Auto-create auto.direct in new locations.
Pavel Zuna wrote: This patch replaces deprecated automount entries created after installation with a 'default' automount location with auto.master and auto.direct maps. It also makes the automount plugin create the auto.master and auto.direct maps when a new location is added. Pavel ack, pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 377 fix deprecation warning
Fix a deprecation warning importing sha. rob freeipa-377-sha.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 378 allow one-character Param names
Loosen up the variable name restrictions in Params so we can handle the attribute l (localityname). rob freeipa-378-name.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 377 fix deprecation warning
On Fri, 2010-02-12 at 10:56 -0500, Rob Crittenden wrote: > Fix a deprecation warning importing sha. > > rob nack. There is no `sha` attribute in the `hashlib` module; instead, you'll need to use `hashlib.sha1`, like this: try: from hashlib import sha1 as sha except ImportError: from sha import sha I'd like to start consolidating these Python compatibility hacks in the `ipalib.compat` module. But in the case of the `uuid` module, with its funky imports inside of functions, we should probably keep our modifications to a minimum. So I agree with your approach. ack once you fix the import. ;) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 377 fix deprecation warning
On 02/12/2010 02:57 PM, Jason Gerard DeRose wrote: On Fri, 2010-02-12 at 10:56 -0500, Rob Crittenden wrote: Fix a deprecation warning importing sha. rob nack. There is no `sha` attribute in the `hashlib` module; instead, you'll need to use `hashlib.sha1`, like this: try: from hashlib import sha1 as sha except ImportError: from sha import sha I'd like to start consolidating these Python compatibility hacks in the `ipalib.compat` module. But in the case of the `uuid` module, with its funky imports inside of functions, we should probably keep our modifications to a minimum. So I agree with your approach. ack once you fix the import. ;) FWIW, python-nss has: hash_buf (specify any hash algorithm supported my NSS) md5_digest sha1_digest sha256_digest sha512_digest -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 044 Add sha1, md5 to compat
This patch adds `sha1` and `md5` classes to the `compat` module. These
will work in Python 2.4 - 2.5 without raising a `DeprecationWarning`.
>From fc8710cf1371d0b71341ec3cb162e19699090ffb Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Fri, 12 Feb 2010 13:03:14 -0700
Subject: [PATCH] Add sha1, md5 to compat
---
ipalib/compat.py | 38 ++
1 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/ipalib/compat.py b/ipalib/compat.py
index 70f098b..fcf33fd 100644
--- a/ipalib/compat.py
+++ b/ipalib/compat.py
@@ -18,11 +18,14 @@
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
"""
-Abstracts some compatability issues for Python2.4 - Python2.6.
+Abstracts some compatibility issues for Python 2.4 - Python 2.6.
-The ``json`` module was added in Python2.6, which previously was in a seperate
-package and called ``simplejson``. This hack abstracts the difference so you
-can use the ``json`` module generically like this:
+Python 2.6
+==
+
+The ``json`` module was added in Python 2.6, which previously was in an external
+package and called ``simplejson``. The `compat` module abstracts the difference
+so you can use the ``json`` module generically like this:
>>> from compat import json
>>> json.dumps({'hello': 'world'})
@@ -40,6 +43,28 @@ future-proofing here so you can import ``parse_qs()`` generically like this:
For more information, see *What's New in Python 2.6*:
http://docs.python.org/whatsnew/2.6.html
+
+
+Python 2.5
+==
+
+The ``hashlib`` module was added in Python2.5, after which use of the ``sha``
+and ``md5`` modules is deprecated. You can generically import a ``sha1`` class
+from the `compat` module like this:
+
+>>> from compat import sha1
+>>> sha1('hello world').hexdigest()
+'2aae6c35c94fcfb415dbe95f408b9ce91ee846ed'
+
+And generically import an ``md5`` class like this:
+
+>>> from compat import md5
+>>> md5('hello world').hexdigest()
+'5eb63bbbe01eeed093cb22bb8f5acdc3'
+
+For more information, see *What's New in Python 2.5*:
+
+http://python.org/doc/2.5/whatsnew/whatsnew25.html
"""
import sys
@@ -49,3 +74,8 @@ if sys.version_info[:2] >= (2, 6):
else:
import simplejson as json
from cgi import parse_qs
+try:
+from hashlib import sha1, md5
+except ImportError:
+from sha import new as sha1
+from md5 import new as md5
--
1.6.3.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 378 allow one-character Param names
On Fri, 2010-02-12 at 11:03 -0500, Rob Crittenden wrote: > Loosen up the variable name restrictions in Params so we can handle the > attribute l (localityname). > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 379 fix automountlocation-tofiles
The command automountlocation-tofiles hadn't been ported to the new return value format. It should work again. I also added a few labels to make the output more readable. rob freeipa-379-automount.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 377 fix deprecation warning
Jason Gerard DeRose wrote: On Fri, 2010-02-12 at 10:56 -0500, Rob Crittenden wrote: Fix a deprecation warning importing sha. rob nack. There is no `sha` attribute in the `hashlib` module; instead, you'll need to use `hashlib.sha1`, like this: try: from hashlib import sha1 as sha except ImportError: from sha import sha I'd like to start consolidating these Python compatibility hacks in the `ipalib.compat` module. But in the case of the `uuid` module, with its funky imports inside of functions, we should probably keep our modifications to a minimum. So I agree with your approach. ack once you fix the import. ;) Gah, good catch. Fixed and pushed. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 040
Jason Gerard DeRose wrote: This is (knock on wood) a low risk change that adds an Object.label attribute that is exposed through the webUI, cleans up some UI funkiness. I was accidentally making post-alpha changes in the same branch as my error and other string cleanups, which is taking me a bit to sort out, so this is the last patch from me till after the alpha. ack, pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 044 Add sha1, md5 to compat
Jason Gerard DeRose wrote: This patch adds `sha1` and `md5` classes to the `compat` module. These will work in Python 2.4 - 2.5 without raising a `DeprecationWarning`. I wonder if we should import both the name sha and sha1. If we did that we could modify ipauuid to import from compat directly. This would be nicer too because it shortens the diffs from the upstream uuid.py. The reason we have our own local copy is partly due to the fact that uuid.py imports ctypes which is not at all SELinux friendly. That and so we can work on Python 2.4 systems. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 044 Add sha1, md5 to compat
Rob Crittenden wrote: Jason Gerard DeRose wrote: This patch adds `sha1` and `md5` classes to the `compat` module. These will work in Python 2.4 - 2.5 without raising a `DeprecationWarning`. I wonder if we should import both the name sha and sha1. If we did that we could modify ipauuid to import from compat directly. This would be nicer too because it shortens the diffs from the upstream uuid.py. The reason we have our own local copy is partly due to the fact that uuid.py imports ctypes which is not at all SELinux friendly. That and so we can work on Python 2.4 systems. rob Ok, as Jason suggested, we can do something like: from compat import sha1 as sha ack, pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] git patch email issues
I spent the better part of today investigating why we appear to have problems with our patch emails when the contents is are 7-bit ASCII. I'be been through the source code of git-format-patch and git-send-email, refreshed my memory of various RFC's, and have performed a number of experiments. The Details: If an email, or any mime part of an email does *not* specify a Content-Type with a charset parameter then the encoding defaults to 7-bit US-ASCII. That hasn't been a problem in the past because virtually all our patches have been restricted to 7-bit ASCII so we never really noticed the problem. However more recently we been sending files with UTF-8 encoded values and we started to see what appeared to be corruption in the patch. This was most noticeable when the mail passed through Mailman, some versions of which attempt to transcode the email to match the list preferences. Here is what is actually going on: git-format-patch does *not* set the charset when it formats the email. Without a charset specified anybody handling the email according to the RFC's are supposed to treat the body as 7-bit ASCII. Thus patches which contain UTF-8 characters outside the range of 7-bit ASCII will have the potential to be mangled because the content (8-bit UTF-8) does not match the content declaration (7-bit ASCII). You can instruct git-format-patch to add arbitrary email headers. Thus we can force git-format-patch to provide the correct content declaration. This is best done by adding a format parameter to your ~/.gitconfig like this: [format] headers = "Content-Type: text/plain; charset=\"utf-8\"\nContent-Transfer-Encoding: 8bit\n" When you do this the headers at the top of your formatted patch will include: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit While that's a good start *it's not enough* Why? Those extra email headers have to actually make it into the email headers being sent via SMTP. Just because those header lines are sitting in a file which might be attached to the email you're sending is not sufficient. Why? Because the patch being attached becomes part of the email body, the headers in the patch file never make it into the actual SMTP email headers. Sending a patch as an attachment prevents the Content-Type from being inserted into the headers of the email, that's why when we send patches as an attachment they get their UTF-8 content screwed up. So, is there a solution which causes the headers inserted by git-format-patch to become part of the actual email headers? Yes, it's called git-send-email. git-send-email is designed to send a git patch and as such it knows how to parse a patch formatted by git-format-patch. One of the things it does is look for email headers in the git-format-patch file and inserts them into the SMTP headers for the email. What happens when you send a patch as an attachment? This causes the email body to become a collection of mime multiparts. Each mime part *should* have it's own Content-Type declaration. Unfortunately neither "git-send-email --attach" nor Thunderbird when attaching a patch set the charset parameter of the Content-Type declaration for the patch content. Remember the rules of the various RFC's, if the charset parameter is absent the encoding of the content is to be interpreted as 7-bit ASCII. So any of our patches which contain UTF-8 can be mangled because we've violated the rules of email. We sent something which we implicitly declared was 7-bit ASCII but was actually 8-bit UTF-8! I could find no way to make Thunderbird use a specific Content-Type when sending a patch file. git-send-email with the attach option has the Content-Type hardcoded which I consider a bug. Unfortunately I couldn't find a git bug reporting tool to report this bug. If you have git-format-patch add the Content-Type and use git-send-email to send the patch it will be *correct*. Why? Because git-send-email will insert the Content-Type into the SMTP header which will apply to the *entire* email body because there are *no* mime multipart's as there would be if it were an attachment. If you do that not only will the patch be sent correctly, but it will also display correctly in your email reader! But isn't there another way to send the patch without it getting it's charset screwed up? Yes, you can send the patch as binary data (e.g. base64 encoded), which implies it must be an attachment. What happens when you base64 encode the attachment? Basically it means to the mail handling components along the way "keep your grubby hands off, do not try to interpret this". That's both good and bad for us. It's good that the UTF-8 encoded patch makes it through the mail system unscathed, but mail readers have no clue how to properly display it, in fact they won't even try. That means you can't read the patch in your mail reader, you'll have to save it which invokes the base
[Freeipa-devel] [www.transifex.net] Team Creation Requested: Bengali (India)
Hello freeipa, this is Transifex at http://www.transifex.net. A translation team for 'Bengali (India)' has been required to the 'FreeIPA' project. Please, visit Transifex at http://www.transifex.net/projects/p/freeipa/teams/ in order to manage the teams of the project. For changing how you receive notifications, please go to http://www.transifex.net/notices/. Thank you, Transifex ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
