Re: [Freeipa-devel] JSON problems (the woes of binary data)
John Dennis wrote: The Problem: I've been looking at the encoding exception which is being thrown when you click on the "Services" menu item in our current implementation. By default we seem to be using JSON as our RPC mechanism. The exception is being thrown when the JSON encoder hits a certificate. Recall that we store certificates in LDAP as binary data and in our implementation we distinguish binary data from text by Python object type, text is *always* a unicode object and binary data is *always* a str object. However in Python 2.x str objects are believed to be text and are subject to encoding/decoding in many parts of the Python world. Unlike XML-RPC JSON does *not* have a binary type. In JSON there are *only* unicode strings. So what is happening is that that when the JSON encoder sees our certificate data in a str object it says "str objects are text and we have to produce a UTF-8 unicode encoding from that str object". There's the problem! It's completely nonsensical to try and encode binary to to UTF-8. The right way to handle this is to encode the binary data to base64 ASCII text and then hand it to JSON. FWIW our XML-RPC handler does this already because XML-RPC knows about binary data and elects to encode/decode it to base64 as it's marshaled and unmarshaled. But JSON can't do this during marhasling and unmarshaling because the JSON protocol has no concept of binary data. The python JSON encoder class does give us the option to hook into the encoder and check if the object is a str object and then base64 encode. But that doesn't help us at the opposite end. How would we know when unmarshaling that a given string is supposed to be base64 decoded back into binary data? We could prepend a special string and hope that string never gets used by normal text (yuck). Keeping a list of what needs base64 decoding is not an option within JSON because at the time of decoding we have no information available about the context of the JSON objects. That means if we want to use JSON we really should push the base64 encode/decode to the parts of the code which have a priori knowledge about the objects they're pushing through the command interface. This would mean any command which passes a certificate should base64 encode it prior to sending it and base64 decode after it come back from a command result. Actually it would be preferable to use PEM encoding, and by the way, the whole reason why PEM encodings for certificates was developed was exactly for this scenario: transporting a certificate through a text based interchange mechanism! Possible Solutions: --- As I see it we have these options in front of us for how to deal with this problem: * Drop support for JSON, only use XML-RPC * Once we read a certificate from LDAP immediately convert it to PEM format. Adopt the convention that anytime we exchange certificates it will be in PEM format. Only convert from PEM format when the target demands binary (e.g. storing it in LDAP, passing it to a library expecting DER encoded data, etc.). * Come up with some hacky protocol on top of JSON which signals "this string is really binary" and check for it on every JSON encode/decode and cross our fingers no one tries to send a legitimate string which would trigger the encode/decode. Question: Are certificates the one and only example of binary data we exchange? Recommendation: --- My personal recommendation is we adopt the convention that certificates are always PEM encoded. We've already run into many problems trying to deduce what format a certificate is (e.g. binary, base64, PEM) I think it would be good if we just put a stake in the ground and said "certificates are always PEM encoded" and be done with all these problems we keep having with the data type of certificates. This is what the directory server console does, which allows you to copy/paste CA certs, cert requests, cert request responses, etc. directly in the UI, and easily convert that pem/ascii format to other formats. As an aside I'm also skeptical of the robustness of allowing binary data at all in our implementation. Trying to support binary data has been nothing but a headache and a source of many many bugs. Do we really need it? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] JSON problems (the woes of binary data)
On Fri, 2010-02-26 at 15:59 -0500, John Dennis wrote:
> The Problem:
>
>
> I've been looking at the encoding exception which is being thrown when
> you click on the "Services" menu item in our current implementation. By
> default we seem to be using JSON as our RPC mechanism. The exception is
> being thrown when the JSON encoder hits a certificate. Recall that we
> store certificates in LDAP as binary data and in our implementation we
> distinguish binary data from text by Python object type, text is
> *always* a unicode object and binary data is *always* a str object.
> However in Python 2.x str objects are believed to be text and are
> subject to encoding/decoding in many parts of the Python world.
The CLI communicates to the server over XML-RPC, but the webUI
communicates to the server over JSON-RPC. Dealing with JSON on the web
client is fast and easy, XML difficult and slow.
> Unlike XML-RPC JSON does *not* have a binary type. In JSON there are
> *only* unicode strings. So what is happening is that that when the JSON
> encoder sees our certificate data in a str object it says "str objects
> are text and we have to produce a UTF-8 unicode encoding from that str
> object". There's the problem! It's completely nonsensical to try and
> encode binary to to UTF-8.
Yeah, I do wish JSON had a binary literal type. This is obviously a bug
in my JSON-RPC code, but also an issue we need to solve for the UI.
When we send binary to the webUI, what is our intent? I think that
displaying it as base64 encoded text is not generally what the user
wants. I think displaying a link that will allow them to download the
file is generally a better idea. Perhaps the Param should indicate how
it should be handled in the webUI.
> The right way to handle this is to encode the binary data to base64
> ASCII text and then hand it to JSON. FWIW our XML-RPC handler does this
> already because XML-RPC knows about binary data and elects to
> encode/decode it to base64 as it's marshaled and unmarshaled. But JSON
> can't do this during marhasling and unmarshaling because the JSON
> protocol has no concept of binary data.
>
> The python JSON encoder class does give us the option to hook into the
> encoder and check if the object is a str object and then base64 encode.
> But that doesn't help us at the opposite end. How would we know when
> unmarshaling that a given string is supposed to be base64 decoded back
> into binary data? We could prepend a special string and hope that string
> never gets used by normal text (yuck). Keeping a list of what needs
> base64 decoding is not an option within JSON because at the time of
> decoding we have no information available about the context of the JSON
> objects.
I think sending it as a dict with a special key, something like:
{'__base64__': b64encode(my_str)}
> That means if we want to use JSON we really should push the base64
> encode/decode to the parts of the code which have a priori knowledge
> about the objects they're pushing through the command interface. This
> would mean any command which passes a certificate should base64 encode
> it prior to sending it and base64 decode after it come back from a
> command result. Actually it would be preferable to use PEM encoding, and
> by the way, the whole reason why PEM encodings for certificates was
> developed was exactly for this scenario: transporting a certificate
> through a text based interchange mechanism!
>
> Possible Solutions:
> ---
>
> As I see it we have these options in front of us for how to deal with
> this problem:
>
> * Drop support for JSON, only use XML-RPC
We can't do this and keep the flexibility we need in the UI. Also,
there is a strong trend to use JSON over XML lately (RPC or otherwise),
so I think we do ourselves a disservice by dropping the JSON-RPC.
> * Once we read a certificate from LDAP immediately convert it to PEM
> format. Adopt the convention that anytime we exchange certificates it
> will be in PEM format. Only convert from PEM format when the target
> demands binary (e.g. storing it in LDAP, passing it to a library
> expecting DER encoded data, etc.).
>
> * Come up with some hacky protocol on top of JSON which signals "this
> string is really binary" and check for it on every JSON encode/decode
> and cross our fingers no one tries to send a legitimate string which
> would trigger the encode/decode.
>
> Question: Are certificates the one and only example of binary data we
> exchange?
At this time, I believe so. But it would be nice to have a plan for how
do deal with this in the future for other binary data.
> Recommendation:
> ---
>
> My personal recommendation is we adopt the convention that certificates
> are always PEM encoded. We've already run into many problems trying to
> deduce what format a certificate is (e.g. binary, base64, PEM) I think
> it would be good if we just put a stake in the gro
Re: [Freeipa-devel] commit policy for translations (.po files)
Simo Sorce wrote: > On Fri, 26 Feb 2010 13:19:47 -0500 > John Dennis wrote: > > >> I'd like to propose that for translations (e.g. .po files) we skip >> the review process on the patch and just push them to master. >> Realistically few of us will be able to verify whether the string >> translations are correct or not. >> > > +1 we do the same for sssd > > Simo. > > I agree too. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. --- 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
Re: [Freeipa-devel] commit policy for translations (.po files)
On Fri, 26 Feb 2010 13:19:47 -0500 John Dennis wrote: > I'd like to propose that for translations (e.g. .po files) we skip > the review process on the patch and just push them to master. > Realistically few of us will be able to verify whether the string > translations are correct or not. +1 we do the same for sssd 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] JSON problems (the woes of binary data)
On Fri, 26 Feb 2010 15:59:53 -0500 John Dennis wrote: > My personal recommendation is we adopt the convention that > certificates are always PEM encoded. +1 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] JSON problems (the woes of binary data)
John Dennis wrote: > The Problem: > > > I've been looking at the encoding exception which is being thrown when > you click on the "Services" menu item in our current implementation. > By default we seem to be using JSON as our RPC mechanism. The > exception is being thrown when the JSON encoder hits a certificate. > Recall that we store certificates in LDAP as binary data and in our > implementation we distinguish binary data from text by Python object > type, text is *always* a unicode object and binary data is *always* a > str object. However in Python 2.x str objects are believed to be text > and are subject to encoding/decoding in many parts of the Python world. > > Unlike XML-RPC JSON does *not* have a binary type. In JSON there are > *only* unicode strings. So what is happening is that that when the > JSON encoder sees our certificate data in a str object it says "str > objects are text and we have to produce a UTF-8 unicode encoding from > that str object". There's the problem! It's completely nonsensical to > try and encode binary to to UTF-8. > > The right way to handle this is to encode the binary data to base64 > ASCII text and then hand it to JSON. FWIW our XML-RPC handler does > this already because XML-RPC knows about binary data and elects to > encode/decode it to base64 as it's marshaled and unmarshaled. But JSON > can't do this during marhasling and unmarshaling because the JSON > protocol has no concept of binary data. > > The python JSON encoder class does give us the option to hook into the > encoder and check if the object is a str object and then base64 > encode. But that doesn't help us at the opposite end. How would we > know when unmarshaling that a given string is supposed to be base64 > decoded back into binary data? We could prepend a special string and > hope that string never gets used by normal text (yuck). Keeping a list > of what needs base64 decoding is not an option within JSON because at > the time of decoding we have no information available about the > context of the JSON objects. > > That means if we want to use JSON we really should push the base64 > encode/decode to the parts of the code which have a priori knowledge > about the objects they're pushing through the command interface. This > would mean any command which passes a certificate should base64 encode > it prior to sending it and base64 decode after it come back from a > command result. Actually it would be preferable to use PEM encoding, > and by the way, the whole reason why PEM encodings for certificates > was developed was exactly for this scenario: transporting a > certificate through a text based interchange mechanism! > > Possible Solutions: > --- > > As I see it we have these options in front of us for how to deal with > this problem: > > * Drop support for JSON, only use XML-RPC > > * Once we read a certificate from LDAP immediately convert it to PEM > format. Adopt the convention that anytime we exchange certificates it > will be in PEM format. Only convert from PEM format when the target > demands binary (e.g. storing it in LDAP, passing it to a library > expecting DER encoded data, etc.). > > * Come up with some hacky protocol on top of JSON which signals "this > string is really binary" and check for it on every JSON encode/decode > and cross our fingers no one tries to send a legitimate string which > would trigger the encode/decode. > > Question: Are certificates the one and only example of binary data we > exchange? > > Recommendation: > --- > > My personal recommendation is we adopt the convention that > certificates are always PEM encoded. We've already run into many > problems trying to deduce what format a certificate is (e.g. binary, > base64, PEM) I think it would be good if we just put a stake in the > ground and said "certificates are always PEM encoded" and be done with > all these problems we keep having with the data type of certificates. > > As an aside I'm also skeptical of the robustness of allowing binary > data at all in our implementation. Trying to support binary data has > been nothing but a headache and a source of many many bugs. Do we > really need it? > Yeah, a good Friday afternoon problem to solve... +1 to your recommendations, though I am not a specialist, but suggestion seems logical. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. --- 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] JSON problems (the woes of binary data)
The Problem: I've been looking at the encoding exception which is being thrown when you click on the "Services" menu item in our current implementation. By default we seem to be using JSON as our RPC mechanism. The exception is being thrown when the JSON encoder hits a certificate. Recall that we store certificates in LDAP as binary data and in our implementation we distinguish binary data from text by Python object type, text is *always* a unicode object and binary data is *always* a str object. However in Python 2.x str objects are believed to be text and are subject to encoding/decoding in many parts of the Python world. Unlike XML-RPC JSON does *not* have a binary type. In JSON there are *only* unicode strings. So what is happening is that that when the JSON encoder sees our certificate data in a str object it says "str objects are text and we have to produce a UTF-8 unicode encoding from that str object". There's the problem! It's completely nonsensical to try and encode binary to to UTF-8. The right way to handle this is to encode the binary data to base64 ASCII text and then hand it to JSON. FWIW our XML-RPC handler does this already because XML-RPC knows about binary data and elects to encode/decode it to base64 as it's marshaled and unmarshaled. But JSON can't do this during marhasling and unmarshaling because the JSON protocol has no concept of binary data. The python JSON encoder class does give us the option to hook into the encoder and check if the object is a str object and then base64 encode. But that doesn't help us at the opposite end. How would we know when unmarshaling that a given string is supposed to be base64 decoded back into binary data? We could prepend a special string and hope that string never gets used by normal text (yuck). Keeping a list of what needs base64 decoding is not an option within JSON because at the time of decoding we have no information available about the context of the JSON objects. That means if we want to use JSON we really should push the base64 encode/decode to the parts of the code which have a priori knowledge about the objects they're pushing through the command interface. This would mean any command which passes a certificate should base64 encode it prior to sending it and base64 decode after it come back from a command result. Actually it would be preferable to use PEM encoding, and by the way, the whole reason why PEM encodings for certificates was developed was exactly for this scenario: transporting a certificate through a text based interchange mechanism! Possible Solutions: --- As I see it we have these options in front of us for how to deal with this problem: * Drop support for JSON, only use XML-RPC * Once we read a certificate from LDAP immediately convert it to PEM format. Adopt the convention that anytime we exchange certificates it will be in PEM format. Only convert from PEM format when the target demands binary (e.g. storing it in LDAP, passing it to a library expecting DER encoded data, etc.). * Come up with some hacky protocol on top of JSON which signals "this string is really binary" and check for it on every JSON encode/decode and cross our fingers no one tries to send a legitimate string which would trigger the encode/decode. Question: Are certificates the one and only example of binary data we exchange? Recommendation: --- My personal recommendation is we adopt the convention that certificates are always PEM encoded. We've already run into many problems trying to deduce what format a certificate is (e.g. binary, base64, PEM) I think it would be good if we just put a stake in the ground and said "certificates are always PEM encoded" and be done with all these problems we keep having with the data type of certificates. As an aside I'm also skeptical of the robustness of allowing binary data at all in our implementation. Trying to support binary data has been nothing but a headache and a source of many many bugs. Do we really need it? -- 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
Re: [Freeipa-devel] commit policy for translations (.po files)
On Fri, 2010-02-26 at 13:19 -0500, John Dennis wrote: > I'd like to propose that for translations (e.g. .po files) we skip the > review process on the patch and just push them to master. Realistically > few of us will be able to verify whether the string translations are > correct or not. +1. Whoever pushes it can just make sure it isn't touching anything code related and push the patch. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] commit policy for translations (.po files)
I'd like to propose that for translations (e.g. .po files) we skip the review process on the patch and just push them to master. Realistically few of us will be able to verify whether the string translations are correct or not. -- 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] More Kannada translations
More Kannada translations Current translation status: ipa.pot has 133 messages. There are 6 po translation files. bn_IN:14/133 10.5% 106 po untranslated, 13 missing, 119 untranslated es: 133/133 100.0%0 po untranslated,0 missing,0 untranslated id: 107/133 80.5% 13 po untranslated, 13 missing, 26 untranslated kn: 133/133 100.0%0 po untranslated,0 missing,0 untranslated pl: 133/133 100.0%0 po untranslated,0 missing,0 untranslated ru: 120/133 90.2%0 po untranslated, 13 missing, 13 untranslated -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ >From 4bad89e6adae4c7e7369c5d73db3e042c9b98f6e Mon Sep 17 00:00:00 2001 From: John Dennis Date: Fri, 26 Feb 2010 12:58:37 -0500 Subject: [PATCH] More Kannada translations Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit --- install/po/kn.po | 269 -- 1 files changed, 138 insertions(+), 131 deletions(-) diff --git a/install/po/kn.po b/install/po/kn.po index 0710f23..433ea18 100644 --- a/install/po/kn.po +++ b/install/po/kn.po @@ -2,13 +2,13 @@ # Copyright (C) 2010 Red Hat # This file is distributed under the same license as the PACKAGE package. # gundachandru , 2010. -# +# msgid "" msgstr "" "Project-Id-Version: ipa\n" "Report-Msgid-Bugs-To: https://hosted.fedoraproject.org/projects/freeipa/newticket\n"; "POT-Creation-Date: 2010-02-15 14:55-0500\n" -"PO-Revision-Date: 2010-02-14 22:37+0530\n" +"PO-Revision-Date: 2010-02-26 23:05+0530\n" "Last-Translator: gundachandru \n" "Language-Team: Kannada \n" "MIME-Version: 1.0\n" @@ -107,542 +107,549 @@ msgstr "%(values)r ನಲà³à²²à²¿ à²à²à²¦à³ à²à²à²¿à²°à²²à³à²¬à³à²à³" #: ../../ipalib/cli.py:505 #, python-format msgid "Enter %(label)s again to verify: " -msgstr "ಮತà³à²¤à³à²®à³à²®à³ ಪರಿಶà³à²²à²¿à²¸à²²à³ %(label)s à²à²à²à²°à³ ಮಾಡಿ" +msgstr "ಮತà³à²¤à³à²®à³à²®à³ ಪರಿಶà³à²²à²¿à²¸à²²à³ %(label)s à²à²à²à²°à³ ಮಾಡಿ:" #: ../../ipalib/cli.py:509 msgid "Passwords do not match!" -msgstr "" +msgstr "à²à³à²ªà³à²¤à²ªà²¦à²à²³à³ ಹà³à²à²¦à²¾à²£à²¿à²à³à²¯à²¾à²à³à²¤à³à²¤à²¿à²²à³à²²!" #: ../../ipalib/cli.py:514 msgid "Cancelled." -msgstr "" +msgstr "ರದà³à²¦à³à²à³à²³à²¿à²¸à²²à²¾à²à²¿à²¦à³." #: ../../ipalib/frontend.py:377 msgid "Results are truncated, try a more specific search" -msgstr "" +msgstr "ಫಲಿತಾà²à²¶à²à²³à³ à²à²¤à³à²¤à²°à²¿à²¸à²²à³à²ªà²à³à²à²¿à²µà³, ಹà³à²à³à²à³à²¹à³ ನಿರà³à²¦à²¿à²·à³à²à²µà²¾à²¦ ಶà³à²§à²¨à³ ಪà³à²°à²¯à²¤à³à²¨à²¿à²¸à²¿" #: ../../ipalib/errors.py:297 #, python-format msgid "%(cver)s client incompatible with %(sver)s server at %(server)r" -msgstr "" +msgstr "%(server)r ನಲà³à²²à²¿ à²à³à²²à³à²à²à³ %(cver)s ಸರà³à²µà²°à³â %(sver)s ನà³à²à²¦à²¿à²à³ ಹà³à²à²¦à²¿à²à³à²¯à²¾à²à³à²¤à³à²¤à²¿à²²à³à²²" #: ../../ipalib/errors.py:315 #, python-format msgid "unknown error %(code)d from %(server)s: %(error)s" -msgstr "" +msgstr "%(server)s ಸರà³à²µà²°à³âನಿà²à²¦ ಠà²à³à²à²¾à²¤ ದà³à²· %(code)d: %(error)s" #: ../../ipalib/errors.py:331 msgid "an internal error has occurred" -msgstr "" +msgstr "à²à²à²¤à²°à²¿à² ದà³à²· à²à²à²à²¾à²à²¿à²¦à³" #: ../../ipalib/errors.py:353 #, python-format msgid "an internal error has occurred on server at %(server)r" -msgstr "" +msgstr "%(server)r ನಲà³à²²à²¿ ಸರà³à²µà²°à³âನಲà³à²²à²¿ à²à²à²¤à²°à²¿à² ದà³à²· à²à²à²à²¾à²à²¿à²¦à³" #: ../../ipalib/errors.py:369 #, python-format msgid "unknown command %(name)r" -msgstr "" +msgstr "ಠà²à³à²à²¾à²¤ à²à²à³à²à³(à²à²®à³à²¯à²¾à²à²¡à³) %(name)r " -#: ../../ipalib/errors.py:386 ../../ipalib/errors.py:411 +#: ../../ipalib/errors.py:386 +#: ../../ipalib/errors.py:411 #, python-format msgid "error on server %(server)r: %(error)s" -msgstr "" +msgstr "%(server)r ಸರà³à²µà²°à³âನಲà³à²²à²¿ ದà³à²·: %(error)s" #: ../../ipalib/errors.py:402 #, python-format msgid "cannot connect to %(uri)r: %(error)s" -msgstr "" +msgstr "%(uri)r à²à³ ಸà²à²ªà²°à³à²à²¿à²¸à²²à³ à²à²à³à²¤à³à²¤à²¿à²²à³à²²: %(error)s" #: ../../ipalib/errors.py:420 #, python-format msgid "Invalid JSON-RPC request: %(error)s" -msgstr "" +msgstr "ಠಸಿà²à²§à³à²µà²¾à²¦ JSON-RPC ಬà³à²¡à²¿à²à³: %(error)s" #: ../../ipalib/errors.py:448 #, python-format msgid "Kerberos error: %(major)s/%(minor)s" -msgstr "" +msgstr "Kerberos ದà³à²·: %(major)s/%(minor)s" #: ../../ipalib/errors.py:465 msgid "did not receive Kerberos credentials" -msgstr "" +msgstr "Kerberos ಯà³à²à³à²¯à²¤à²¾à²ªà²¤à³à²°à²à²³à²¨à³à²¨à³ ಪಡà³à²¦à²¿à²²à³à²²" #: ../../ipalib/errors.py:481 #, python-format msgid "Service %(service)r not found in Kerberos database" -msgstr "" +msgstr "Kerberos ಡà³à²à²¾à²¬à³à²¸à³
[Freeipa-devel] [Transifex] File submitted via email to FreeIPA | master
Hello freeipa, this is Transifex at http://www.transifex.net. The following attached files were submitted to FreeIPA | master by gundachandru Please, visit Transifex at http://www.transifex.net/projects/p/freeipa/c/master/ in order to see the component page. Thank you, Transifex # Kannada translations for ipa-server package. # Copyright (C) 2010 Red Hat # This file is distributed under the same license as the PACKAGE package. # gundachandru , 2010. # msgid "" msgstr "" "Project-Id-Version: ipa\n" "Report-Msgid-Bugs-To: https://hosted.fedoraproject.org/projects/freeipa/newticket\n"; "POT-Creation-Date: 2010-02-15 14:55-0500\n" "PO-Revision-Date: 2010-02-26 23:05+0530\n" "Last-Translator: gundachandru \n" "Language-Team: Kannada \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" #: ../../ipalib/parameters.py:224 msgid "incorrect type" msgstr "ಸರಿಯಲ್ಲದ ಬಗೆ" #: ../../ipalib/parameters.py:227 msgid "Only one value is allowed" msgstr "ಕೇವಲ ಒಂದು ಬೆಲೆ ಮಾತ್ರ ಅನುಮೋದಿಸಲಾಗಿದೆ" #: ../../ipalib/parameters.py:791 msgid "must be True or False" msgstr "ನಿಜ (True) ಅಥವಾ ಸುಳ್ಳು (False) ಆಗಿರಲೇಬೇಕು" #: ../../ipalib/parameters.py:892 msgid "must be an integer" msgstr "ಇನ್ಟೀಜರ್ ಆಗಿರಲೇಬೇಕು" #: ../../ipalib/parameters.py:943 #, python-format msgid "must be at least %(minvalue)d" msgstr "ಕನಿಷ್ಠವಾಗಿ %(minvalue)d ಆಗಿರಲೇಬೇಕು" #: ../../ipalib/parameters.py:953 #, python-format msgid "can be at most %(maxvalue)d" msgstr "ಗರಿಷ್ಠವಾಗಿ %(maxvalue)d ಆಗಿರಬಹುದು" #: ../../ipalib/parameters.py:963 msgid "must be a decimal number" msgstr "ದಶಾಂಶ ಸಂಖ್ಯೆ ಆಗಿರಲೇಬೇಕು" #: ../../ipalib/parameters.py:985 #, python-format msgid "must be at least %(minvalue)f" msgstr "ಕನಿಷ್ಠವಾಗಿ %(minvalue)f ಆಗಿರಲೇಬೇಕು" #: ../../ipalib/parameters.py:995 #, python-format msgid "can be at most %(maxvalue)f" msgstr "ಗರಿಷ್ಠವಾಗಿ %(maxvalue)f ಆಗಿರಬಹುದು" #: ../../ipalib/parameters.py:1055 #, python-format msgid "must match pattern \"%(pattern)s\"" msgstr "ನಮೂನೆ \"%(pattern)s\" ಹೊಂದಾಣಿಕೆಯಾಗಲೇಬೇಕು" #: ../../ipalib/parameters.py:1073 msgid "must be binary data" msgstr "ಬೈನರಿ ಡಾಟಾ ಆಗಿರಲೇಬೇಕು" #: ../../ipalib/parameters.py:1088 #, python-format msgid "must be at least %(minlength)d bytes" msgstr "ಕನಿಷ್ಠವಾಗಿ %(minlength)d ಬೈಟ್ಸ್ ಆಗಿರಲೇಬೇಕು" #: ../../ipalib/parameters.py:1098 #, python-format msgid "can be at most %(maxlength)d bytes" msgstr "ಗರಿಷ್ಠವಾಗಿ %(maxlength)d ಬೈಟ್ಸ್ ಆಗಿರಬಹುದು" #: ../../ipalib/parameters.py:1108 #, python-format msgid "must be exactly %(length)d bytes" msgstr "ನಿಖರವಾಗಿ %(length)d ಬೈಟ್ಸ್ ಆಗಿರಲೇಬೇಕು" #: ../../ipalib/parameters.py:1126 msgid "must be Unicode text" msgstr "ಯುನಿಕೋಡ್ ಪಠ್ಯ ಆಗಿರಲೇಬೇಕು" #: ../../ipalib/parameters.py:1156 #, python-format msgid "must be at least %(minlength)d characters" msgstr "ಕನಿಷ್ಠವಾಗಿ %(minlength)d ಅಕ್ಷರಗಳು ಇರಲೇಬೇಕು" #: ../../ipalib/parameters.py:1166 #, python-format msgid "can be at most %(maxlength)d characters" msgstr "ಗರಿಷ್ಠವಾಗಿ %(maxlength)d ಅಕ್ಷರಗಳು ಇರಬಹುದು" #: ../../ipalib/parameters.py:1176 #, python-format msgid "must be exactly %(length)d characters" msgstr "ನಿಖರವಾಗಿ %(length)d ಅಕ್ಷರಗಳು ಇರಲೇಬೇಕು" #: ../../ipalib/parameters.py:1215 #, python-format msgid "must be one of %(values)r" msgstr "%(values)r ನಲ್ಲಿ ಒಂದು ಆಗಿರಲೇಬೇಕು" #: ../../ipalib/cli.py:505 #, python-format msgid "Enter %(label)s again to verify: " msgstr "ಮತ್ತೊಮ್ಮೆ ಪರಿಶೀಲಿಸಲು %(label)s ಎಂಟರ್ ಮಾಡಿ:" #: ../../ipalib/cli.py:509 msgid "Passwords do not match!" msgstr "ಗುಪ್ತಪದಗಳು ಹೊಂದಾಣಿಕೆಯಾಗುತ್ತಿಲ್ಲ!" #: ../../ipalib/cli.py:514 msgid "Cancelled." msgstr "ರದ್ದುಗೊಳಿಸಲಾಗಿದೆ." #: ../../ipalib/frontend.py:377 msgid "Results are truncated, try a more specific search" msgstr "ಫಲಿತಾಂಶಗಳು ಕತ್ತರಿಸಲ್ಪಟ್ಟಿವೆ, ಹೆಚ್ಚ್ಹು ನಿರ್ದಿಷ್ಟವಾದ ಶೋಧನೆ ಪ್ರಯತ್ನಿಸಿ" #: ../../ipalib/errors.py:297 #, python-format msgid "%(cver)s client incompatible with %(sver)s server at %(server)r" msgstr "%(server)r ನಲ್ಲಿ ಕ್ಲೈಂಟ್ %(cver)s ಸರ್ವರ್ %(sver)s ನೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತಿಲ್ಲ" #: ../../ipalib/errors.py:315 #, python-format msgid "unknown error %(code)d from %(server)s: %(error)s" msgstr "%(server)s ಸರ್ವರ್ನಿಂದ ಅಜ್ಞಾತ ದೋಷ %(code)d: %(error)s" #: ../../ipalib/errors.py:331 msgid "an internal error has occurred" msgstr "ಆಂತರಿಕ ದೋಷ ಉಂಟಾಗಿದೆ" #: ../../ipalib/errors.py:353 #, python-format msgid "an internal error has occurred on server at %(server)r" msgstr "%(server)r ನಲ್ಲಿ ಸರ್ವರ್ನಲ್ಲಿ ಆಂತರಿಕ ದೋಷ ಉಂಟಾಗಿದೆ" #: ../../ipalib/errors.py:369 #, python-format msgid "unknown command %(name)r" msgstr "ಅಜ್ಞಾತ ಆಜ್ಞೆ(ಕಮ್ಯಾಂಡ್) %(name)r " #: ../../ipalib/errors.py:386 #: ../../ipalib/errors.py:411 #, python-format msgid "error on server %(server)r: %(error)s" msgstr "%(server)r ಸರ್ವರ್ನಲ್ಲಿ ದೋಷ: %(error)s" #: ../../ipalib/errors.py:402 #, python-format msgid "cannot connect to %(uri)r: %(error)s" msgstr "%(uri)r ಗೆ ಸಂಪರ್ಕಿಸಲು ಆಗುತ್ತಿಲ್ಲ: %(error)s" #: ../../ipalib/errors.py:420 #, python-format msgid "Invalid JSON-RPC request: %(error)s" msgstr "ಅಸಿಂಧುವಾದ JSON-RPC ಬೇಡಿಕೆ: %(error)s"
Re: [Freeipa-devel] [PATCH] 387 fix test failures
Pavel Zůna wrote: Rob Crittenden wrote: This fixes the failures in the Env due to switching to unicode internally. Now that --all works this also adds the dn to the output in the XML-RPC tests. rob ack. Pavel pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 387 fix test failures
Pavel Zůna wrote: Rob Crittenden wrote: This fixes the failures in the Env due to switching to unicode internally. Now that --all works this also adds the dn to the output in the XML-RPC tests. rob ack. Pavel pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add more Spanish translations
John Dennis wrote: Add more Spanish translations: Current translation status: ipa.pot has 133 messages. There are 6 po translation files. bn_IN:14/133 10.5% 106 po untranslated, 13 missing, 119 untranslated es: 124/133 93.2%9 po untranslated,0 missing,9 untranslated id: 107/133 80.5% 13 po untranslated, 13 missing, 26 untranslated kn: 20/133 15.0% 113 po untranslated,0 missing, 113 untranslated pl: 133/133 100.0%0 po untranslated,0 missing,0 untranslated ru: 120/133 90.2%0 po untranslated, 13 missing, 13 untranslated ack, pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 385 don't try to revoke revoked certs
John Dennis wrote: On 02/19/2010 01:33 PM, Rob Crittenden wrote: Check the status of a certificate before trying to revoke it. We get an error thrown when we revoke a revoked cert that is difficult to distinguish between a real error and "this is already revoked". Conditional ACK. Please try to remember to localize all labels. That's a 1 line change so it falls into the "make the fix & commit" category. Fixed. At the time I did this patch GetText was not a valid data type for labels. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 392 retrieve schema using kerberos credentials
Retrieve the LDAP schema using kerberos credentials. This is required so we can disable anonymous access in 389-ds. rob freeipa-392-bind.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
